D1 Definir la Arquitectura del Diseño
Entradas :
·
Lista de
Requerimientos No Funcionales
·
Modelo de
Casos de Uso
·
Modelo de
Análisis
·
Descripción
de la Arquitectura ( Vista del Modelo de Análisis)
·
Descripción
de la Arquitectura ( Vista del Modelo de Diseño)
·
Descripción
de la Arquitectura ( Vista del Modelo de Distribución)
Descripción :
En esta
actividad se define la arquitectura general del sistema, especificando las
distintas particiones físicas del mismo, la descomposición lógica en
subsistemas de diseño y la ubicación de cada subsistema en cada partición, así
como la especificación detallada de la infraestructura técnica necesaria para
dar soporte al sistema. El
propósito es bosquejar los Modelos de Diseño y Distribución y su arquitectura
para lo cual se deben identificar distintos objetos como nodos y sus
configuraciones de red, subsistemas y sus interfaces, Clases de Diseño
significativas a la arquitectura y mecanismos de diseño genéricos que manejan
requerimientos comunes.
A través de
esta actividad se consideran distintas posibilidades de reutilización de
componentes, como por ejemplo reusar partes de sistemas similares ó productos
generales de software. Estos son incorporados al Modelo de Diseño. La Descripción de la Arquitectura (Vista del
Modelo de Diseño y Distribución) debe ser mantenida, refinada y modificada en
las sucesivas iteraciones dentro de las Fases correspondientes.
Para realizar
estas tareas, se deben realizar las sub-actividades D1.1- Identificar Nodos y sus configuraciones
de red, D1.2 – Identificar
Subsistemas y sus interfaces, D1.3 –
Identificar clases de Diseño significantes a la Arquitectura y D1.4 – Identificar Mecanismos Genéricos de
Diseño.
Fase Inicial:
El objetivo es
bosquejar el modelo de diseño y desarrollar un primer paso para la vista de la
arquitectura del mismo realizando los
casos de uso como colaboraciones entre clases y subsistemas. Es importante
encontrar interfaces ( y al menos definir alguna de sus operaciones) entre los
subsistemas y clases, las cuales constituyen el corazón de la arquitectura.
también se deben identificar los mecanismos
de diseño genéricos que sean necesarios.
Seleccionando los sistemas de software que serán usados en la capa intermedia.
Si el sistema va a ser desarrollado en nodos, el arquitecto debe diseñar una
versión a pequeña escala del modelo de Distribución, limitada por ejemplo al
cambio de performance de los nodos o a la conexión entre nodos para lo que
contará con la ayuda de los especialistas técnicos. Un prototipo puede ser
parte de los nodos y la interacción entre ellos donde los cambios radican.
Fase de Elaboración:
Se identifican
las capas de la arquitectura (incluyendo los mecanismos genéricos), subsistemas
y sus interfaces, clases del diseño significantes a la arquitectura y
configuraciones de nodos
El Arquitecto
prepara una nueva versión de la vista de la arquitectura del modelo de Diseño y
de la vista del modelo de Distribución, los cuales son incluidos en la
descripción de la arquitectura.
Fase de Construcción:
En la fase de
construcción el Arquitecto no debería sumar subsistema de servicios ni
subsistema de diseño, éstos ya existen en el esqueleto de la línea base de la
arquitectura.
Salidas :
·
Subsistemas
de Diseño ( bosquejo)
·
Interfaces
de Diseño ( bosquejo)
·
Clases de
Diseño ( bosquejo)
·
Modelo de
Distribución ( bosquejo)
·
Descripción
de la Arquitectura ( Vista de los Modelos de Diseño) ( bosquejo)
·
Descripción
de la Arquitectura ( Vista de los Modelos de Distribución) (bosquejo)
Personas
involucradas:
®
Arquitecto
®
Analistas
®
Especialistas
Técnicos
Responsable:
®
Arquitecto
La
división física del sistema se especifica identificando los nodos y las
comunicaciones entre los mismos, con cierta independencia de la infraestructura
que da soporte a cada nodo.
Los aspectos
de las configuraciones de red a tener en cuenta incluyen:
·
nodos
involucrados y sus capacidades en términos de poder de procesamiento y tamaño
de memoria
·
tipo de
conexiones entre los nodos y protocolos de comunicación que serán utilizados
sobre estos
·
características
de las conexiones y protocolos de comunicación como ancho de banda,
disponibilidad y calidad
·
necesidad
de tener capacidad de procesamiento redundante, modos a prueba de fallas,
procesos de migración, mantener backup de datos, y otros.
Conociendo
tanto las posibilidades como las limitaciones de los nodos y sus conexiones, se
podrá incorporar tecnología que facilitará la tarea de distribución del
sistema.
Se
deben tener en cuenta aspectos no funcionales relacionados con:
·
Usuarios:
ubicación, movilidad, concurrencia, número, etc.
·
Datos:
variabilidad, volúmenes, necesidades de consolidación, seguridad, etc.
·
Procesos:
distribución, reutilización, concurrencia, carácter crítico, etc.
Cada
configuración de red debe ser dibujada en diagramas de distribución separados.
Dadas estas configuraciones de red es posible comenzar a pensar sobre como
distribuir la funcionalidad entre las mismas.
Salida :
·
Modelo
de Distribución (bosquejo)
·
Descripción
de la Arquitectura ( vista del Modelo de Distribución)
Personas
Involucradas:
®
Arquitecto
®
Analistas
®
Especialistas
Técnicos
En
esta tarea se divide de forma lógica el sistema en subsistemas de diseño, con
el fin de reducir la complejidad y facilitar el mantenimiento. Se toman como
referencia inicial los subsistemas de análisis especificados en el Análisis. La
división en subsistemas de diseño se puede realizar con una continuidad directa
de los modelos del análisis, o aplicando nuevos criterios de diseño, entre los
que se pueden citar los siguientes:
·
Facilidad
de mantenimiento
·
Reutilización
de elementos del propio sistema o de la instalación
·
Optimización
de recursos (por ejemplo, líneas de comunicaciones)
·
Características
de ejecución (interactivo o por lotes)
·
Funcionalidad
común
·
Aplicación
de mecanismos genéricos de diseño a nivel de arquitectura.
Los
subsistemas resultantes se califican como específicos o de servicio, asignando
cada subsistema al nodo correspondiente.
Los
subsistemas específicos contemplan las funcionalidades propias del sistema,
mientras que los de servicio cubren servicios comunes proporcionando un acceso
transparente a los distintos recursos.
Definir las
dependencias entre los subsistemas:
Las
dependencias entre Subsistemas deben ser definidas si sus contenidos se
relacionan. La dirección de la dependencia debe ser la misma que la de la
relación entre los Subsistemas. Si las dependencias deben especificarse antes
de que el contenido de los Subsistemas sea conocido, se deben considerar las
dependencias entre los Paquetes de Análisis correspondientes a los Subsistemas
de Diseño ya que estas dependencias posiblemente sean similares en el Modelo de
Diseño. Si se usan interfaces entre los Subsistemas, las dependencias deben ser
entre las interfaces y no entre los Subsistemas mismos.
Identificar
Interfaces de los subsistemas:
Las interfaces
que provee un subsistema definen las operaciones que son accesibles desde fuera
del subsistema y son provistas tanto
por clases como por otros Subsistemas dentro del Subsistema.
Para hacer una
identificación inicial, se deben considerar las dependencias entre los
Subsistemas que fueron encontradas anteriormente.
La
identificación de interfaces permite refinar las dependencias entre los
Subsistemas. Se deben identificar también las operaciones que deben ser
definidas por cada interfase, para lo cual se deben diseñar los Casos de Uso en
términos de Subsistemas y sus interfaces como se describe más adelante en la
actividad D2 - Diseñar cada Caso de Uso. Esto
establecerá requerimientos sobre las operaciones que necesitan ser definidas
por las interfaces. Los requerimientos para cada Realización de Casos de Uso de
Diseño son integrados en la interfase.
Salida:
·
Modelo de
Diseño (bosquejo)
Personas
Involucradas:
®
Arquitecto
®
Analistas
Será
suficiente con un bosquejo inicial de las clases más importantes y que son
significantes a la arquitectura ya que en esta actividad solamente deben ser
identificadas.
Identificar Clases de Diseño desde las Clases de Análisis:
Algunas Clases
de Diseño pueden ser bosquejadas inicialmente a partir de las Clases de
Análisis significantes a la arquitectura que fueron encontradas durante el
Análisis. Las relaciones entre estas Clases de Análisis pueden ser usadas para
identificar un conjunto tentativo de relaciones entre las Clases de Diseño
correspondientes.
Identificar
Clases Activas:
Para
identificar las Clases Activas requeridas por el Sistema, se deben considerar
los requerimientos de concurrencia en el sistema como por ejemplo:
·
Requerimientos
de disponibilidad y performance que los distintos actores tienen al interactuar
con el Sistema.
·
La
distribución del Sistema sobre nodos. Los objetos activos deben distribuirse en
distintos nodos, los cuales podrían requerir al menos un objeto activo por cada
nodo y un objeto activo separado para manejar la comunicación entre los mismos.
·
Otros
requerimientos de inicio y finalización del Sistema, de prevención de deadlock
y posposición indefinida, de reconfiguración de nodos y de capacidad de las
conexiones.
Se asignan
como clases activas los objetos usados en diagramas de interacción y éstas a su vez son asignadas a los
procesadores y otros dispositivos.
Cada Clase
Activa es bosquejada considerando el ciclo de vida de sus objetos activos y
cómo deberían comunicarse, sincronizarse y compartir información. Los objetos activos son asignados a los nodos
del Modelo de Distribución. Al asignar los objetos activos a los nodos, es
necesario considerar la capacidad de los nodos, como su procesador y tamaño de
memoria y las características de las conexiones, como su ancho de banda y su
disponibilidad, teniendo en cuenta que el tráfico en la red usualmente tiene un
impacto sustancial en los recursos computacionales requeridos por el Sistema,
lo cual puede tener un fuerte impacto en el Modelo de Diseño.
Para
identificar inicialmente las Clases Activas es posible utilizar los resultados
del Análisis y el Modelo de Distribución como base, y luego mapear las Clases
de Diseño que se correspondan con las del Análisis (o partes de estas) en los
nodos utilizando Clases Activas. Otra forma es utilizar los Subsistemas
identificados previamente y asignar un Subsistema completo a un nodo específico
identificando una Clase Activa a través del Subsistema.
Salida:
·
Modelo de
Diseño (bosquejo)
·
Modelo de
Distribución (bosquejo)
·
Descripción
de la Arquitectura ( vista de los modelos de Diseño y Distribución)
Personas
Involucradas:
®
Analistas
®
Arquitecto
®
Especialistas
Técnicos
En esta etapa se estudian los Requerimientos Especiales
identificados durante el Análisis y se decide como manejarlos dadas las
tecnologías disponibles de diseño e implementación, obteniendo como resultado
un conjunto de mecanismos genéricos de Diseño que pueden ser Clases de Diseño,
colaboraciones o incluso Subsistemas. Se deben identificar también
colaboraciones genéricas que puedan funcionar como patrones y ser usadas por
varias Realizaciones de Casos de Uso de Diseño en el Modelo de Diseño.
Los mecanismos genéricos se definen a partir del estudio
de comportamientos comunes relacionados, generalmente con acceso a los objetos de entidad, control y recuperación de
errores, utilización de recursos comunes y otros.
Los
mecanismos genéricos de diseño son de aplicación tanto en la definición de la
arquitectura del sistema como en el diseño
detallado de los subsistemas específicos y de las capas intermedia y del
sistema.
Salidas :
·
Subsistemas
de Diseño ( bosquejo)
·
Descripción
de la Arquitectura ( Vista de los Modelos de Diseño) ( bosquejo)
·
Descripción
de la Arquitectura ( Vista de los Modelos de Distribución) (bosquejo)
Personas involucradas:
®
Arquitecto
®
Analistas
® Especialistas Técnicos