Capítulo 6Diseño Arquitectónico
Introducción
Qué es??
El diseño arquitectónico representa la estructura de datos y los
componentes del programa necesarios para construir un sistema
computacional.
Asume el estilo arquitectónico que tomará el sistema, la estructura
y las propiedades de los componentes que constituyen el sistema y
las interrelaciones entre todos los componentes arquitectónicos del
sistema.
El diseño arquitectónico corresponde al proceso de diseño que
identifica los subsistemas que conforman un sistema y la
infraestructura de control y comunicación.
*
Introducción
Quién lo hace??
Cuando se construyen sistemas grandes y complejos se asigna un
especialista, para los otros trabajos un Ingeniero de SW puede
diseñar los datos y la arquitectura.
El diseñador de BD o de almacén de datos crea la arquitectura de
datos del sistema.
*
Introducción
¿Por qué es importante?
El diseño arquitectónico proporciona una vista general del SW y
asegura que se obtenga lo que se desea.
Nadie trataría hacer una casa sin un plano.
¿Cuáles son los pasos?
El diseño arquitectónico comienza con el diseño de los datos y
luego pasa a la derivación de una o más representaciones de la
estructura arquitectónica del sistema.
Se analizan los estilos o patrones arquitectónicos alternos para
derivar la estructura que amolda mejor a los requisitos del
cliente.
*
Introducción
Cuál es el producto obtenido??
Un modelo que abarca la arquitectura de los datos y la estructura
del programa se crea durante esta etapa del diseño.
Se describen las propiedades de los componentes y sus relaciones
(inherencias).
¿Cómo se puede estar seguro de que lo que he hecho está bien?
*
1.- Arquitectura de SW
La Arquitectura de un sistema es un marco conceptual completo que
describe su forma y estructura ( sus componentes y la manera en que
se integran).
En su analogía con la edificación, La arquitectura es
La manera en que los diversos componentes de un edificio se
integran para formar un todo cohesionado.
La manera en que un edificio se amolda a su ambiente y se combina
con otros edificios vecinos.
*
1.- Arquitectura de SW
La arquitectura del SW es la estructura o las estructuras del
sistema, que incluyen los componentes del SW, las propiedades
visibles externamente de esos componentes y las relaciones entre
ellos.
No es el SW operativo. En cambio, es una representación que permite
que un Ing. De SW:
Analice la efectividad del diseño para cumplir con los requisitos
establecidos.
Considere opciones arquitectónicas en una etapa en que aún resulta
relativamente fácil hacer cambios al diseño
Reduzca los riesgos asociados con la construcción del SW
*
1.- Arquitectura de SW
Estas definiciones destaca el papel de “los componentes del SW” en
cualquier representación arquitectónica.
*
1.- Arquitectura de SW
El diseño de la arquitectura considera el diseño de datos y el
diseño arquitectónico.
*
1.- Arquitectura de SW
La arquitectura de SW es la organización de un sistema en términos
de sus compontes de SW, incluyendo subsistemas y las relaciones e
interacciones entre ellos, y los principios que guían el diseño de
ese sistema de SW. (IEEE).
*
Aspectos de la Arquitectura de SW
Tipo de Arquitectura
Conceptual
Se ocupa de la estructura del modelo de clase estático y de las
conexiones entre los componentes del modelo
Componentes
Conectores
Modular
Describe la forma en que el sistema está dividido en subsistemas o
módulos y cómo se comunican mediante la exportación e importación
de datos
Subsistemas, módulos
Exportaciones, Importaciones
Código
Define cómo está organizado el código del programa en archivos,
directorios y se agrupa en bibliotecas.
Archivos, directorios, bibliotecas
Ejecución
Se centra en los aspectos dinámicos del sistema y en la
comunicación entre componentes cuando se ejecutan las tareas y las
operaciones.
Tareas, líneas, interacciones de objetos
Usos, llamadas
Las 5 Perspectivas de UML
Perspectiva
Explicación
De casos de usos
Los casos de uso importantes del sistema y los escenarios que
describen el comportamiento importante desde el punto de vista de
la arquitectura.
Lógica
Las clases e interfaces importantes de diseño de una estructura de
paquete, con diagramas de estructura compuestos.
Implementación
Decisiones sobre arquitecturas hechas por la implementación en
términos de subsistemas, de componentes y de las relaciones entre
ellos.
De proceso
Una descripción de los procesos (procesos y tareas del sistema
operativo) y de las comunicaciones entre procesos utilizando clases
estereotipadas
De Despliegue
*
1.2 ¿Por qué es importante?
Se han identificado 3 razones claves por las cuales la arquitectura
es importante:
Las representaciones de la arquitectura de SW permiten la
comunicación entre todas las partes (participantes) interesadas en
el desarrollo de un sistema de cómputo.
Destaca las decisiones iniciales relacionadas con el diseño que
tendrán un impacto profundo en todo el trabajo de la ingeniería de
SW que le sigue y, lo que también resulta importante, en el éxito
final del sistema como entidad operacional.
Constituye un modelo relativamente pequeño e intelectualmente
comprensible de cómo está estructurado el sistema y como trabajan
juntos sus componentes
*
1.2 ¿Por qué es importante?
El modelo de diseño arquitectónico y los patrones arquitectónicos
que contiene son transferibles.
*
Diseño de datos
2.- Diseño de datos
La acción de diseño de datos traduce los objetos de datos definidos
en la etapa de análisis, en estructuras globales al nivel de
componentes de SW y, cuando es necesario, una arquitectura de BD al
nivel de aplicación.
*
2.1 Diseño de datos al nivel arquitectónico
La calidad de datos marca la diferencia entre un almacén y un
basurero de datos.
Hoy los negocios grandes y pequeños están inundados de datos.
No resulta poco común que incluso un negocio de tamaño moderado
tenga docenas de BD que sirven a muchas aplicaciones.
*
2.1 Diseño de datos al nivel arquitectónico
Un almacén de datos es un entorno de datos independiente que no
está directamente integrado en las aplicaciones cotidianas, pero
que abarca todos los datos utilizados en un negocio.
*
2.2 Diseño de datos al nivel de componentes
El diseño de datos al nivel de componentes se concentra en la
representación de estructuras de datos a las que se tiene acceso en
forma directa mediante uno o más componentes de SW.
*
Estilos Arquitectónicos y patrones
3.- Estilos y patrones arquitectónicos
Un estilo arquitectónico es una transformación impuesta al diseño
de todo un sistema. El objetivo es establecer una estructura para
todos los componentes del sistema.
Indican
Patrones y restricciones de interconexión o composición entre
ellos
Invariantes del estilo (restricciones)
Asociado a cada estilo hay una serie de propiedades que lo
caracterizan
Determinan sus ventajas e inconvenientes
Condicionan la elección de uno u otro estilo
*
Pedro Francisco Godoy Barrera Metodologías de diseño e
Implantación
El estilo arquitectónico es una plantilla para la
construcción.
Los SW que se construyen también muestran uno o muchos estilos
arquitectónicos.
Estilo arquitectónico Colonial con sala al centro
*
Estilos Arquitectónicos
Cada estilo describe una categoría de sistemas que abarca
Un conjunto de componentes (por ejemplo, una BD, módulos
computacionales) que realizan una función requerida por el
sistema.
Un Conjunto de conectores que permiten la “comunicación,
coordinación y cooperación entre los componentes”
Restricciones que definen cómo se integran los componentes para
formar el sistema.
*
Estilos Arquitectónicos
Tubería y filtros
Model-View-Controller (MVC)
Arquitecturas Basadas en Atributos
3.- Estilos y patrones arquitectónicos
Un patrón arquitectónico, al igual que un estilo, impone una
transformación en el diseño de una arquitectura.
Diferencias entre patrón y estilos
El alcance de un patrón es menor, ya que se concentra en un aspecto
en lugar de hacerlo en toda la arquitectura.
Un patrón impone una regla sobre la arquitectura, pues describe la
manera en que el SW manejará algún aspecto de su funcionalidad al
nivel de la infraestructura (por ejemplo, concurrencia).
Los patrones arquitectónicos tienden a abarcar aspectos específicos
del comportamiento dentro del contexto de la arquitectura (por
ejemplo, como maneja una aplicación en tiempo real la
sincronización o las interrupciones ).
*
Breve Taxonomía de Estilos arquitectónicos
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos:
Un almacén de datos se encuentra en el centro de esta
arquitectura.
Otros componentes tienen acceso a él y cuentan con la opción de
actualizar, agregar, eliminar o por otra parte, modificar los datos
de ese almacén.
El SW cliente tiene acceso a un almacén central. En algunos casos
este es pasivo, es decir, el SW cliente accede a los datos
independiente de cualquier cambio hecho a los datos o a las
acciones de otros SW cliente.
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos:
Una arquitectura centrada en datos promueve la capacidad de
integración, esto significa que es posible cambiar componentes
existentes y agregar nuevos componentes cliente a la arquitectura
sin preocuparse por otros clientes (ya que los componentes clientes
operan en forma independiente).
Además es posible pasar datos entre clientes empleando el mecanismo
del pizarrón, es decir, el componente pizarrón sirve para coordinar
la transferencia de información entre clientes.
Los componentes cliente ejecutan los procesos de manera
independiente.
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos:
Adecuado para la resolución de problemas no deterministas
Se puede resumir el estado de conocimiento en cada momento del
proceso.
Desventajas
Estructura de datos común a todos los agentes
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de flujo de datos:
Esta arquitectura se aplica cuando los datos de entrada se habrán
de transformar en datos de salida mediante una serie de componentes
para el cálculo o la manipulación. Una estructura de tuberías y
filtros.
Tiene un conjunto de componentes denominados filtros, conectados
por tuberías que transmiten datos de un componente al
siguiente.
Cada filtro funciona sin tomar en cuenta si los componentes tienen
flujo ascendente o descendente
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de flujo de datos:
Si el flujo de datos degenera en una sola línea de transformaciones
se denomina procesamiento por lotes secuencial. Esta estructura
acepta un procesamiento por lotes de datos y luego aplica una serie
de componentes secuenciales (filtro) para transformarlos.
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Filtro
Tuberías
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de flujo de datos:
Ventajas
Permite entender el sistema global en términos de la combinación de
componentes
Soporta de buena manera la reutilización
Los filtros son independientes de sus vecinos
Facilidad de mantenimiento y mejora
Facilidad de diagnóstico (rendimiento y Dead-lock)
Soportan la ejecución concurrente
No aconsejable para cuando se necesita interactividad
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de llamada y retorno:
Con esta arquitectura se obtiene una estructura de programa que
resulta relativamente fácil de modificar y cambiar de tamaño.
Existen dos subestilos:
Arquitectura de programa principal/subprograma: Esta estructura de
programa clásica separa la función en una jerarquía de control
donde un programa “principal” invoca a varios componentes de
programa, que a su vez pueden invocar a otros componentes.
Arquitectura de llamada a procedimiento remoto: Los componentes de
una arquitectura de programa principal/subprograma se distribuyen
entre varias computadoras de una red.
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de llamada y retorno:
Programa
Principal
Subprograma
controlador
Subprograma
controlador
Subprograma
controlador
Subprograma
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura Orientada a Objetos:
Los componentes de un sistema encapsulan los datos y las
operaciones que deben aplicarse para manipular los datos. La
comunicación y coordinación entre los componentes se consigue
mediante el paso de mensajes.
Restricciones
Los objetos son responsables de la integridad de sus
representaciones
Dicha representación es ocultada al resto de los objetos
*
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura Orientada a Objetos:
Ventajas
Gracias al invariante de ocultación es posible reemplazar la
implementación sin que afecte a los clientes (“clientes” del
objeto)
Desventajas
Para invocar métodos de un objeto se debe conocer su
identidad
Parece obvio
Efectos colaterales
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura estratificada:
Hay varias capas definidas, cada una de ellas realiza operaciones
que se acercan progresivamente al conjunto de instrucciones de la
máquina.
En la capa externa los componentes sirven a las operaciones de
interfaz del usuario.
*
3.1 Una breve taxonomía de estilos arquitectónicos
Capa Central
Módulos
3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura estratificada:
Facilita la descomposición del problema en varios niveles de
abstracción.
Soporta fácilmente la evolución del sistema, los cambios sólo
afectan a las capas vecinas
Se pueden cambiar las implementaciones respetando las interfaces
con las capas adyacentes
Desventajas
*
Patrones arquitectónicos
3.2 Patrones Arquitectónicos
Si el constructor decide construir una casa con sala al centro sólo
podrá aplicar un estilo arquitectónico.
Los detalles del estilo (nº de chimeneas, fachada de la casa,
colocación de puertas y ventanas) variarán considerablemente, pero
una vez que se ha tomado la decisión de la arquitectura general de
la casa, el estilo se impondrá al diseño.
Los patrones arquitectónicos difieren un poco. Por ejemplo cada
casa emplea un patrón cocina, el cual define la necesidad de
colocar los artículos básicos de cocina, un lavaplatos y posibles
reglas para ubicar cosas relacionadas al flujo de trabajo.
*
3.2 Patrones Arquitectónicos
Cómo ya se indicó, los patrones arquitectónicos para el SW definen
un enfoque específico para el manejo de alguna característica de
comportamiento del sistema.
Patrones arquitectónicos representativos:
Concurrencia: Muchas aplicaciones tienen que manejar varias tareas
de manera tal que simulen paralelismo (es decir, cada vez que un
solo procesador maneja varias tareas “paralelas” o
componentes).
*
3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos:
Concurrencia:
Un enfoque consiste en usar un patrón de manejo de procesos del
sistema operativo que ofrece características integradas del sistema
operativo que permiten la ejecución concurrente de los
componentes.
El patrón también incorpora funcionalidad del sistema operativo que
maneja la comunicación entre los procesos, la calendarización y
otras funciones requeridas para alcanzar la concurrencia.
*
3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos:
Concurrencia:
*
3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos:
Persistencia:
Los datos persisten si sobreviven después de la ejecución del
proceso que los creó.
Los datos persistentes se almacenan en una BD o un archivo.
En un momento posterior, otros procesos tienen la opción de leerlos
o modificarlos.
En los entornos orientados a objetos la idea de un objeto
persistente extiende un poco más el concepto de persistencia.
*
3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos:
Persistencia:
En gral se emplean dos patrones arquitectónicos para lograr la
persistencia
Un patrón de sistema de administración de BD que aplica las
capacidades de almacenamiento y recuperación de un sistema de
administración de BD a la arquitectura de la aplicación.
*
3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos:
Distribución:
El problema de la distribución dirige la manera en que se comunican
entre sí los sistemas, o los componentes de éstos, en un entorno
distribuido.
Este problema incluye dos elementos:
La manera en que las entidades se conectan entre si.
La naturaleza de la comunicación
*
Organización y refinamiento
3.3 Organización y refinamiento
Debido a que el proceso de diseño suele dejar varias opciones
arquitectónicas, es importante establecer un conjunto de criterios
de diseño para evaluar un diseño arquitectónico.
Las siguientes preguntas proporcionan una visión específica del
estilo arquitectónico que se ha derivado.
Control:
¿Cómo se maneja el control dentro de la arquitectura?
¿Existe una jerarquía de control distintiva y, si es así, cuál es
la función de los componentes dentro de esa jerarquía de
control?
¿Cómo transfieren los campos el control dentro del sistema?
¿Cómo se comparte el control de los componentes?
¿Cuál es la topología del control (es decir, cuál es la forma
geométrica que asume el control)?
¿Está sincronizado el control o los componentes operan
asincrónicamente?
*
3.3 Organización y refinamiento
Datos:
¿Cómo se comunican los datos entre los componentes?
¿El flujo de datos es continuo o los objetos de datos se pasan
esporádicamente al sistema?
¿Cuál es el modo de transferencia de los datos (Por ejemplo, los
datos se pasan de un componente a otro o están disponibles
globalmente para compartirse entre los componentes del
sistema)?
¿Existen componentes de datos (por ejemplo un pizarrón o almacén) y
de ser así, cuál es su papel?
¿Cómo interactúan los componentes funcionales con los datos?
¿Los componentes de los datos son pasivos o activos (es decir,
interactúan activamente con otros componentes del sistema)?
*
Diseño Arquitectónico
4 Diseño Arquitectónico
Cuando se empieza el diseño arquitectónico debe ponerse en contexto
el SW que se habrá de desarrollar, es decir, el diseño debe definir
las entidades externas (otros sistemas, otros dispositivos, otras
personas) con las que interactúa el SW y también la naturaleza de
la interacción.
Esta información suele adquirirse del modelo de análisis y toda la
demás información reunida durante la ingeniería de
requisitos.
Una vez que se ha modelado el contexto y que se han descrito todas
las interfaces externas del SW, el diseñador especifica la
estructura del sistema al definir y refinar los componentes del SW
que implementan la arquitectura.
*
4.1 Representación del sistema de contexto
En las etapas anteriores, se señaló que el Ingeniero de sistema
debe modelar el contexto.
Un diagrama de contexto del sistema cumple con este requisito al
representar el flujo de la información dentro y fuera del sistema,
la información del usuario y el procesamiento relevante de
soporte.
*
Diagrama de contexto Arquitectónico
4.1 Representación del sistema de contexto
Tomando como referencia la figura anterior, los sistemas
interactúan con el sistema de destino (si el sistema para el que se
está desarrollando un diseño arquitectónico) se representa
así:
Sistemas Superodinados: los que emplean el sistema de destino como
parte de algún esquema de procesamiento de nivel más elevado.
Sistemas Subordinados: Los que utiliza el sistema de destino y que
proporcionan los datos o el procesamiento necesarios para completar
la funcionalidad del sistema de destino.
Sistemas a nivel de par: Los que interactúan de igual a igual (es
decir, la información la producen o consumen los pares y el sistema
de destino)
*
4.1 Representación del sistema de contexto
Cada una de estas entidades externas se comunica con el sistema de
destino mediante una interfaz (los pequeños rectángulos negros).
volver
Sistema de destino:
Función de seguridad
4.2 Refinamiento de la arquitectura en Componentes
A medida que se refina la arquitectura del SW en componentes, la
estructura del sistema empieza a emerger.
Para elegir estos componentes, el diseñador de la arquitectura
empieza con las clases descrita como parte del modelo de análisis
(Si se elige el enfoque convencional, es posible que los
componentes sean derivados del modelo de flujo de datos).
Estas clases de análisis representan entidades dentro del dominio
de la aplicación (negocio) que deben atenderse dentro de la
arquitectura del SW.
*
4.2 Refinamiento de la arquitectura en Componentes
La arquitectura debe adecuarse a muchos componentes de
infraestructura que habilitan los componentes de la aplicación,
pero que no tienen conexión de negocios con el dominio de la
aplicación.
Por ejemplo: Los componentes de administración de memoria, de
comunicación, de BD y de administración de tareas, suelen
integrarse en la arquitectura de SW.
*
4.2 Refinamiento de la arquitectura en Componentes
Director
…
*
4.2 Refinamiento de la arquitectura en Componentes
Ejemplo de casa segura: Se definirán un conjunto de componentes de
nivel superior que atienden la siguiente funcionalidad.
Administración de comunicación externa: Coordina la comunicación de
la función de seguridad con entidades externas; Por ej: Sistemas de
Internet, notificación externa de alarma.
*
4.2 Refinamiento de la arquitectura en Componentes
Cada uno de estos componentes de nivel superior tendría que
elaborarse iterativamente y luego posicionarse dentro de la
arquitectura general.
Para cada uno se definirían clases de diseño (con los atributos y
las operaciones apropiadas).
*
Pedro Francisco Godoy Barrera Metodologías de diseño e
Implantación
4.3 Descripción de la creación de Instancias del Sistema.
El diseño arquitectónico que se ha modelado hasta este punto es
todavía de un nivel relativamente alto.
Se ha representado el contexto del sistema
Se han definido los arquetipos que indican las abstracciones
importantes dentro del dominio del problema, es evidente la
estructura general del sistema.
Y se han identificado los principales componentes del SW.
Sin embargo, aún se necesita mayor refinamiento.
*
Director
Cómo evaluar un diseño Arquitectónico
*
5.- Evaluación de Diseños Arquitectónicos Alternativos
5.1 Un método de análisis de Compensación para la
Arquitectura.
El instituto de Ingeniería del SW (SEI) ha desarrollado un método
de análisis de compensación para la Arquitectura (MACA) que define
el proceso de evaluación iterativo para las arquitecturas del
SW.
Las siguientes actividades de análisis del diseño se realizan
iterativamente.
*
5.1 Un método de análisis de Compensación para la
Arquitectura.
Describir los estilos/ patrones arquitectónicos: que se han elegido
para dirigir los escenarios y requisitos.
*
5.1 Un método de análisis de Compensación para la
Arquitectura.
Identificar la sensibilidad de los atributos de calidad respecto de
varios atributos arquitectónicos para un estilo arquitectónico
específico: Esto se logra haciendo pequeños cambios en la
arquitectura y determinando la sensibilidad al cambio de un
atributo de calidad, como desempeño. Cualquier atributo al que
afecte significativamente la variación en la arquitectura se
considerará un punto de sensibilidad.
*
5.1 Un método de análisis de Compensación para la
Arquitectura.
El SEI describe este enfoque de la siguiente manera:
Una vez determinados los puntos de sensibilidad arquitectónica se
encuentran los puntos en que se requiere compensación con sólo
identificar los elementos arquitectónicos a los que son sensibles
varios atributos.
Por ejemplo: El desempeño de una arquitectura cliente – servidor
sería muy sensible al número de servidores (el desempeño aumentará,
dentro de cierto rango, al aumentar el número de servidores)… por
tanto, el número de servidores es un punto de compensación para
esta arquitectura.
*
Complejidad de la Arquitectura
5.2 Complejidad Arquitectónica
Una técnica útil para evaluar la complejidad general de una
arquitectura determinada consiste en considerar las dependencias
entre componentes dentro de la arquitectura.
Estas dependencias las orienta la información, el flujo de control,
o ambas, dentro del sistema.
Zhao sugiere 3 tipos de dependencias:
*
5.2 Complejidad Arquitectónica
Zhao sugiere 3 tipos de dependencias:
Dependencias de flujo: que representan las relaciones de
dependencia entre los productores y consumidores de recursos. Por
ejemplo, para dos componentes u y v, si u debe completarse antes de
que el control pase a v (prerrequisito) o si u se comunica con v
mediante parámetros, entonces existe una relación de dependencia de
flujo entre u y v.
*
5.2 Complejidad Arquitectónica
Las dependencias compartidas y de flujo que señala Zhao son
similares al concepto de acoplamiento.
*
5.3 Lenguajes de descripción arquitectónica.
Aunque el arquitecto de SW puede diseñar con notación UML, se
necesitan otras formas de diagramación, y unas cuantas herramientas
relacionadas, para aplicar un enfoque más formal a la
especificación de un diseño arquitectónico.
El Lenguaje de Descripción Arquitectónica (LDA) proporciona una
semántica y una sintaxis para describir una arquitectura del
SW.
*
5.3 Lenguajes de descripción arquitectónica.
*