La arquitectura
de software describe como un sistema es desconpuesto en componentes
estos componentes son interconectados y la manera en que estos se
comunican e interactuan entre si, varias alternativas para documentar
una arquitectura de software, a traves de un conjunto de vistas cada
vista representa un comportamiento particular del sistema.
VISTA 4+1
El modelo 4+1 se proponen 5 vistas:
1. Vista Logica: Apoya principalmente
los requisitos funcionales, lo que el sistema debe brindar en términos de
servicios a sus usuarios. El sistema se descompone en una serie de
abstracciones primarias, tomadas principalmente del dominio del problema en la
forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción,
encapsulación y herencia. Esta descomposición no solo se hace para potenciar el
análisis funcional sino también sirve para identificar mecanismos y elementos
de diseño comunes a diversas partes del sistema.
2. Vista de Proceso: Se tratan los aspectos de concurrencia y distribución, integridad del
sistema y tolerancia a fallos. Se especifica en cual hilo de control se ejecuta
efectivamente una operación de una clase identificada en la vista lógica. Puede
ser descrita como un conjunto de redes lógicas de procesos que son ejecutados
de una forma independiente y distribuidos a lo largo de varios recursos de
hardware conectados mediante un bus o a una red de datos.
3. Vista de
desarrollo: se centra en la organización real de los módulos de software en el
ambiente de desarrollo. El software se empaqueta en partes pequeñas que pueden
ser bibliotecas o subsistemas que son desarrollados por uno o un grupo de
desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada
una brinda una interfaz estrecha y bien definida hacia las capas superiores.
4. Vista física:
se toma en cuenta los requisitos no funcionales del sistema tales como,
disponibilidad, confiabilidad, desempeño entre otras más. El sistema se ejecuta
sobre varios nodos de procesamiento (hardware). Estos nodos son relacionados
con los elementos identificados de las vistas anteriores. En estas vistas se
especifican varias configuraciones físicas. Por ejemplo una para el desarrollo
y las pruebas o para el despliegue del sistema en plataformas distintas.
5. Vista de
escenarios: Se define una última vista. Propone el uso de un pequeño subconjunto
de escenarios que son instancias de casos de uso. La función de los escenarios
es relacionar las cuatro vistas entre si de esta forma se cuenta con una
perspectiva general del sistema, que ayuda a descubrir nuevos elementos o
validar la arquitectura.
VISTAS
Nord realza las de mayor importación y su
uso. Este estudio se realizó en sistemas industriales como sistemas de procesamiento
de señales e imágenes, sistemas operativos en tiempo real, sistemas de
comunicaciones, sistemas de control de instrumentación. Una vez que las vistas
se han seleccionado y priorizado se inicia su documentación de acuerdo al SEI –Presentación
primaria, catálogo de elementos, diagrama de contexto, guía de variabilidades, antecedentes
de la arquitectura, otra información, paquetes de vista relacionados. Se propusieron
4 vistas:
1. Vista conceptual: se describe el sistema
en términos de sus elementos principales de diseño y las relaciones entre
estos, dentro de un dominio determinado. Esta vista es independiente de las
decisiones de implementación y enfatiza en los protocolos de interacción entre
los elementos de diseño.
2. Vista de módulos: se captura la descomposición
funcional las capas del sistema. El sistema
es descompuesto lógicamente en subsistemas, módulos y unidades abstractas. Cada
capa representa las distintas interfaces de comunicación permitidas entre los módulos.
3. Vista de ejecución: se describe la
estructura dinámica del sistema en términos de sus elementos en tiempo de ejecución.
Por ejemplo se modela las tareas operativas del sistema, procesos, mecanismos
de comunicación y asignación de recursos. Algunos de los aspectos que
consideran en esta vista son el desempeño y el entorno de ejecución.
4. Vista de código: se organiza el código fuente en
directorios, archivos y bibliotecas. Algunos de los aspectos que se incluyen
son, los lenguajes de programación a utilizar, herramientas de desarrollo, la administración
de la configuración y la estructura y organización del proyecto.
TOGAF
TOGAF o Esquema de Arquitectura de Open Group, es un esquema
Arquitectura que proporciona un enfoque para el diseño, planificación,
implementación y gobierno de una arquitectura de información. Sirve para Crear aplicaciones
de misión crítica o core business, Minimizar riesgos de no-entendimiento entre
Negocio y Tecnología, Generación de valor y descubrimiento de oportunidades en
Business Transformación, Describir, documentar y continuar los sistemas y
aplicaciones construidos, uno de los problemas comunes de la industria de TI es
el entendimiento de las necesidades planteadas por los departamentos de negocio
y los departamentos técnicos. Y aporta Reducción de costes, Reducción de
riesgos, Identificación de oportunidades, Flexibilidad y adaptación, Lenguaje
común entre estos dos. Esta arquitectura es modelada por lo general con cuatro
niveles o dimensiones: Negocios, Tecnología (TI), Datos y Aplicaciones.
1. Arquitectura
de Negocios: la cual define la estrategia de negocios, la gobernabilidad, la
estructura y los procesos clave de la organización.
2. Arquitectura
de Aplicaciones: la cual provee un plano para cada uno de los sistemas de
aplicación que se requiere implantar, las interacciones entre estos sistemas y sus
relaciones con los procesos de negocio centrales de la organización.
3. Arquitectura
de Datos: la cual describe la estructura de los datos físicos y lógicos de la
organización, y los recursos de gestión de estos datos.
4. Arquitectura
Tecnológica: la cual describe la estructura de hardware, software y redes
requerida para dar soporte a la implantación de las aplicaciones principales,
de misión crítica, de la organización.
Zachman
Es
un marco de trabajo para Enterprise Architecture. Este framework emplea modelos
y vistas de los diferentes elementos que forman parte de la arquitectura,
contemplando dos dimensiones:
Perspectivas de participantes o modelos
Cuestiones
básicas o puntos de vista.
Para llevar a cabo esta tarea de definición e
implementación de Arquitectura Zachman considera diferentes perfiles, roles y
habilidades que deben participar en el proceso, e incide especialmente en los
problemas de comunicación y entendimiento existentes entre dichos perfiles. Para
conseguir este entendimiento de una forma sencilla e intuitiva, Zachman define
las siguientes cuestiones, que deben ser respondidas por cada perfil para poder
definir de forma completa la Arquitectura: ¿Qué? - ¿Cómo? - ¿Dónde? - ¿Quién? -
¿Cuándo? - ¿Por Qué?, Los beneficios que trae zachman son, Simplicidad: La
definición del framework parte de una única figura que representa las vistas y
capas a tener en cuenta a la hora de definir una arquitectura. Flexibilidad:
deja abiertas las puertas a la interpretación y ejecución de los diferentes
artefactos y actividades a desarrollar y Estandarización y adaptabilidad:
Zachman es más maduro y horizontal que otros, por lo que es un ideal para
establecer bases a las que sumar otras metodologías y marcos de trabajo
ACTIVIDAD 2
REQUERIMIENTOS FUNCIONALES Y
NO FUNCIONALES
El
Proyecto “Sistema de Parqueaderos” se realiza con el fin de proveer el diseño
que permita a la administración de la operación de un edificio de
parqueaderos, considerando las especificaciones dadas en la descripción del
problema.
El
resultado planteado abarcará el análisis y diseño de una solución que de
soporte a los requerimientos para el proceso de negocio del parqueadero. Se definen los requerimientos de software necesarios para
desarrollar una propuesta que soporte las necesidades que se han
identificado.
Requerimientos
Funcionales
-Registrar
Vehículo en parqueadero
Se
requiere registrar el ingreso de un vehículo al parqueadero a un sitio
estándar, según su tipo. Debe haber un sitio disponible para estacionar. El
sistema debe indicar cuál es el sitio disponible asignado para el vehículo.
-Revisar
el estado de ocupación de un piso
Se
requiere que el sistema pueda entregar un listado, que permita notificar si
cada espacio está libre u ocupado, de estar ocupado debe indicar el tiempo que
lleva el vehículo correspondiente.
-Autorizar
salida de un vehículo
Se
requiere que el sistema permita autorizar la salida de un vehículo, para lo
cual debe notificar el sitio, tiempo de parqueo dado su placa y registrar el
valor a cobrar.
Registrar
el parqueo en sitios dobles
Se
requiere registrar el ingreso de 2 vehículos en un sitio de parqueo doble cuando
hay alta demanda de sitios de parqueo en horas pico y se agotaron los sitios. En esos casos el primer -vehículo queda bloqueado.
Reglas de
Negocio:
• El
vehículo bloqueado se identifica con el número del sitio y la letra “A”.
• El
vehículo libre se identifica con el número del sitio y la letra “B”.
• El
sitio de parqueo doble se puede asignar si no está previamente reservado.
• Solo se
autoriza el parqueo del segundo vehículo si éste planea salir antes que el
primer vehículo.
-Autorizar
salida de un vehículo
Se
requiere que el sistema permita autorizar la salida de un vehículo, para lo
cual debe notificar el sitio, tiempo de parqueo dado su placa y registrar el
valor a cobrar.
-Reglas de
Negocio:
• Si es
un sitio de parqueo doble y el vehículo bloqueado desea salir (bien sea por que
sale antes o porque el segundo vehículo no salió a la hora pactada) el sistema
debe notificar al dueño del segundo vehículo, éste tendrá 5 minutos para mover
su vehículo de no hacerlo el sistema cobra una multa de $10.000.oo.
• Cuando
se ha liberado por lo menos el 30% de los sitios estándar y si hay cupos dobles
asignados el sistema debe notificar éste hecho.
• La
tarifa de parqueo se cobra en unidades de 15 minutos. Se cobran las primeras 20
unidades y posteriormente la tarifa es simple.
Obtener
el sitio de parqueo de un vehículo dada su placa
Se
requiere poder consultar el sitio de parqueo de un vehículo dada su placa.
Requerimientos
NO Funcionales
-Distribución
El
sistema debe enviar notificaciones a diferentes sistemas que pueden estar
distribuidos en diferentes ambientes.
El
sistema debe notificar al dueño del segundo vehículo de un sitio de parqueo
doble en caso de que éste esté bloqueando a un primer vehículo.
Cuando se
ha liberado por lo menos el 30% de los sitios estándar y si hay cupos dobles
asignados el sistema debe notificar éste hecho.
-Desempeño
Todas las
operaciones deben ser realizadas en el menor tiempo posible. La complejidad de
las operaciones deben ser Bajas.
-Concurrencia
Diferentes
sistemas de monitoreo pueden acceder a la capa que se está diseñando de manera
concurrente. Se debe asegurar consistencia en la información.
-Persistencia
La
información del sistema debe ser persistente. La configuración del parqueadero
se hace dependiendo del edificio y se configura a traves de un archivo XML
-Modificabilidad
El
formato de carga de la configuración del parqueadero puede cambiar.
ACTIVIDAD 3
FORMATOS
