Diseño Arquitectónico

Presentación del tema: "Diseño Arquitectónico"— Transcripción de la presentación:

1 Diseño Arquitectónico
Introducción

2 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. La salida de este proceso de diseño es una descripción de la arquitectura de Software.

3 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. El arquitecto del sistema selecciona un estilo arquitectónico apropiado para los requisitos derivados durante la ingeniería del sistema y el análisis de los requisitos del SW.

4 Introducción ¿Por qué es importante? ¿Cuáles son los pasos?
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. A penas se selecciona una opción se elabora la arquitectura empleando un método de diseño apropiado

5 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? En cada etapa se revisan los productos resultantes del diseño del SW para verificar la claridad, la corrección, el grado en el que se ha completado y su consistencia con los requisitos y entre unos y otros.

6 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. El grado en el cual el edificio cumple con el propósito establecido y en que satisface las necesidades de su propietario.

7 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

8 1.- Arquitectura de SW Estas definiciones destaca el papel de “los componentes del SW” en cualquier representación arquitectónica. En este contexto (arquitectónico), un componente de SW es algo tan simple como un módulo del programa o una clase orientada a objetos, pero también se extiende para incluir BD y middleware que permita configurar una red de clientes y servidores.

9 1.- Arquitectura de SW El diseño de la arquitectura considera el diseño de datos y el diseño arquitectónico. El diseño de datos permite representar el componente de datos de la arquitectura en sistemas convencionales y definiciones de clases (atributos y operaciones de encapsulamiento) de los sistemas orientados a objetos. El diseño arquitectónico se concentra en la representación de la estructura de los componentes del SW, sus propiedades e interacciones.

10 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). Esta definición es importante porque destaca el hecho de que un sistema puede contemplarse desde distintas perspectivas que hacen énfasis en los distintos aspectos del sistema.

11 Aspectos de la Arquitectura de SW
Tipo de Arquitectura Definición Ejemplo de elementos Ejemplo de relaciones 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 Incluye, contiene 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

12 Las 5 Perspectivas de UML
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 Nodos físicos para la probable plataforma de despliegue, los componentes desplegados y los nodos y canales de comunicación entre ellos, utilizando diagramas de despliegue.

13 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

14 1.2 ¿Por qué es importante? El modelo de diseño arquitectónico y los patrones arquitectónicos que contiene son transferibles. Es decir, los estilos y patrones arquitectónicos se aplican al diseño de otros sistemas y representan un conjunto de abstracciones que permiten a los ingenieros de SW describir la arquitectura de maneras predecibles.

15 Diseño de datos

16 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. En algunas situaciones debe diseñarse y construirse una BD específicamente para un nuevo sistema, sin embargo, en otras, se emplean una o más BD existentes.

17 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. El reto consiste en extraer información útil de este entorno de datos, sobretodo cuando la información deseada tiene la funcionalidad cruzada. Para resolver este desafío se ha desarrollado la técnica de minería de datos.

18 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. En cierto sentido, un almacén de datos es una BD grande e independiente que tiene acceso a los datos almacenados en las BD que sirven al conjunto de aplicaciones requeridas en un negocio.

19 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. El diseño de datos comienza durante la creación del modelo de análisis.

20 Estilos Arquitectónicos y patrones

21 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 Los tipos de componentes y sus conectores involucrados 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

22 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

23 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. Modelos semánticos que permiten a un diseñador, mediante el análisis de las propiedades conocidas de las partes que lo integran, comprender las propiedades generales de un sistema.

24 Estilos Arquitectónicos
Estilos de Flujo de Datos Tubería y filtros Estilos Centrados en Datos Arquitecturas de Pizarra o Repositorio Estilos de Llamada y Retorno Model-View-Controller (MVC) Arquitecturas en Capas Arquitecturas Orientadas a Objetos Arquitecturas Basadas en Componentes Estilos de Código Móvil Arquitectura de Máquinas Virtuales Estilos heterogéneos Sistemas de control de procesos Arquitecturas Basadas en Atributos Estilos Peer-to-Peer Arquitecturas Basadas en Eventos Arquitecturas Orientadas a Servicios Arquitecturas Basadas en Recursos

25 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 ). Los patrones se usan junto con un estilo arquitectónico para determinar la forma de la estructura general de un sistema.

26 Breve Taxonomía de Estilos arquitectónicos

27 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. Una variación de este enfoque transforma el depósito en un “pizarrón” que envía notificaciones al SW cliente cuando cambian los datos de interés para el cliente.

28 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.

29 3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos Software cliente Software cliente Almacén de datos (depósito o pizarrón) Software cliente Software cliente Software cliente Software cliente

30 3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura centrada en datos: Ventajas Posibilita la integración de agentes. 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 Problemas de carga a la hora de chequear y vigilar el estado de la pizarra

31 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 Esta diseñado para esperar la entrada de datos con cierta forma y producir su salida (al siguiente filtro) de una forma específica. (no es necesario que el filtro conozca el funcionamiento de los filtros vecinos.

32 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 Tuberías Filtro

33 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 Desventajas No aconsejable para cuando se necesita interactividad Problemas de rendimiento ya que los datos se transmiten en forma completa entre filtros.

34 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.

35 3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura de llamada y retorno: Programa Principal Subprograma controlador Subprograma controlador Subprograma controlador Subprograma de aplicación Subprograma de aplicación Subprograma de aplicación Subprograma de aplicación Subprograma de aplicación Subprograma de aplicación Subprograma de aplicación

36 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

37 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 …!!!pero no lo es en absoluto!!! Efectos colaterales

38 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. En la capa interna los componentes sirven como interfaz con el sistema operativo. Las capas intermedias proporcionan servicios de utilería y de SW de aplicaciones

39 3.1 Una breve taxonomía de estilos arquitectónicos
Módulos Capa de la interfaz de usuario Capa de la Aplicación Capa de Utilerías Capa Central Arquitectura estratificada:

40 3.1 Una breve taxonomía de estilos arquitectónicos
Arquitectura estratificada: Ventajas 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 No todos los sistemas pueden estructurarse en capas A menudo es difícil encontrar la separación en capas adecuadas

41 Patrones arquitectónicos

42 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. Obviamente hay más de un diseño de cocina, pero todo diseño se concebirá dentro del contexto de la “solución” que sugiere el patrón cocina.

43 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). Una aplicación tiene varias maneras de manejar la concurrencia, y cada una se presenta mediante un patrón arquitectónico diferente.

44 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. Otro método sería definir un calendarizador de tareas al nivel de aplicación. Un patrón calendarizador de tareas contiene un conjunto de objetos activos, y cada uno de ellos incluye una operación tic().

45 3.2 Patrones Arquitectónicos
Patrones arquitectónicos representativos: Concurrencia: El calendarizador invoca periódicamente tic() para cada objeto, que luego realiza las funciones que debe realizar antes de regresar el control al mismo calendarizador, que invoca de nuevo la operación tic() para el siguiente objeto concurrente.

46 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. Los valores de todos los atributos del objeto, el estado general de éste y otra información complementaria se almacenan para su aplicación y recuperación posterior.

47 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. Un patrón de persistencia al nivel de la aplicación que construye características de persistencia en la arquitectura de ésta

48 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 El patrón arquitectónico más común establecido para dirigir el problema de la distribución es el corredor. Un corredor actúa como “Intermediario” entre el componente cliente y un componente servidor. El cliente envía un mensaje al corredor (que contiene toda la información apropiada para que se realice la comunicación), el cual completa la conexión. Ej CORBA.

49 Organización y refinamiento

50 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?

51 3.3 Organización y refinamiento
Las siguientes preguntas proporcionan una visión específica del estilo arquitectónico que se ha derivado. 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)? ¿Cómo interactúan los datos y el control dentro del sistema?

52 Diseño Arquitectónico

53 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. Este proceso prosigue de manera iterativa hasta que se obtiene la estructura arquitectónica completa.

54 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. A nivel de diseño arquitectónico, un arquitecto de SW aplica un diseño de contexto arquitectónico (DCA) para modelar de manera en que el SW interactuará con las entidades ubicadas más allá de sus límites.

55 Diagrama de contexto Arquitectónico
Sistemas Superordinados Usadas por Sistema de destino Uses Pares Usan Actores Dependen de Sistemas Subordinados

56 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) Actores: Las entidades (personas, dispositivos) que interactúan con el sistema de destino produciendo o consumiendo información necesaria para el procesamiento de requisitos

57 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 Producto Hogar Seguro Sistema basado en Internet Panel de Control Sistema de destino: Función de seguridad Función de Vigilancia Usa Propietario Usa Usa Sensores Sensores

58 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. Por tanto, el dominio de la aplicación es una fuente para la derivación y el refinamiento de los componentes. Otra fuente es el dominio de la infraestructura.

59 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. La interfaz descrita en el diagrama de contexto de la arquitectura (ver), indica que uno o más componentes especializados procesan los datos que fluyen por la interfaz. En algunos casos (por ejemplo la interfaz gráfica de usuario) debe diseñarse una arquitectura completa de subsistemas con muchos componentes.

60 4.2 Refinamiento de la arquitectura en Componentes
Director Hogar Seguro Manejo de Comunicación Externo … Seguridad Vigilancia Administración De la Casa Interfaz Gráfica De Usuario Interfaz de Internet Procesamiento de panel de control Manejo de detector Procesamiento de Alarma Estructura General de la Arquitectura de Casa Segura con componentes de nivel superior.

61 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. Procesamiento del panel de control: maneja toda la funcionalidad del panel de control. Manejo del detector: coordina el acceso a todos los detectores conectados al sistema. Procesamiento de alarma: Verifica todas las condiciones de alarma y actúa sobre ellas.

62 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). Sin embargo, es importante observar que los detalles de diseño de todos los atributos y las operaciones sólo se especificarían hasta la realización del diseño en el nivel de componentes.

63 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. Esto se logra desarrollando una instancia de la arquitectura. Es decir, la arquitectura se aplica a un problema específico con el propósito de demostrar que la estructura y los componentes son apropiados.

64 4.3 Descripción de la creación de Instancias del Sistema.
Director Hogar Seguro Manejo de Comunicación Externo … Seguridad Interfaz Gráfica De Usuario Interfaz de Internet Procesamiento de panel de control Manejo de detector Procesamiento de Alarma Calendarizador Comunicación telefónica Protocolo de teclado numérico Funciones de Despliegue CP Alarma Sensor

65 Cómo evaluar un diseño Arquitectónico

66 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. Recopilar escenarios: Se desarrolla un conjunto de casos de uso para representar el sistema desde el punto de vista del usuario. Deducir requisitos, restricciones y descripción de entornos: Esta información se requiere como parte de la Ingeniería de requisitos y se usa para asegurarse de que se atiendan todas las preocupaciones de los participantes.

67 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. Evaluar los atributos de calidad al considerar cada atributo de manera aislada: Entre los atributos de calidad para la evaluación del diseño arquitectónico se incluyen confiabilidad, desempeño, seguridad, facilidad de mantenimiento, flexibilidad, facilidad de prueba, portabilidad, facilidad de reutilización e interoperabilidad.

68 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. Analizar las arquitecturas alternas: (desarrolladas en el paso 3) empleando el análisis de sensibilidad aplicado al paso 5.

69 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. Estos 6 pasos representan la primera iteración MACA. Con base en los resultados de los pasos 5 y 6 será posible eliminar algunas opciones arquitectónicas, modificar una o más de las arquitecturas restantes y representarlas con más detalle, y luego aplicar una nueva cuenta con los pasos de MACA.

70 Complejidad de la Arquitectura

71 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: Dependencias compartidas: Que representan relaciones de dependencia entre consumidores que usan el mismo recurso o los productores que producen para los mismos consumidores. Por ejemplo, supóngase dos componentes u y v que se refieren a los mismos datos globales. Entonces existe una relación de dependencia compartida entre u y v.

72 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. Dependencias restringidas: que representan restricciones al flujo relativo de control entre un conjunto de actividades. Por ejemplo, si los dos componentes u y v no pueden ejecutarse al mismo tiempo (exclusión mutua), entonces existe una relación de dependencia restringida entre u y v.

73 5.2 Complejidad Arquitectónica
Las dependencias compartidas y de flujo que señala Zhao son similares al concepto de acoplamiento. Acoplamiento es un concepto importante de diseño que se aplica al nivel de arquitectura y de componentes.

74 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. Hofmann y sus colegas, sugieren que un LDA debe proporcionar al diseñador la capacidad de separar componentes arquitectónicos, de integrar componentes individuales en bloques arquitectónicos mayores y de representar interfaces (mecanismos de conexión) entre los componentes.

75 5.3 Lenguajes de descripción arquitectónica.
Una vez que se hayan establecido las técnicas descriptivas, basadas en el lenguaje para diseño arquitectónico, es más probable que se establezcan los métodos de evaluación efectivos para la arquitectura a medida que el diseño evoluciona.