Diseno_arquitectonico
75
Departamento de Informática Departamento de Informática Universidad Técnica Federico Santa María Universidad Técnica Federico Santa María Diseño Arquitectónico Diseño Arquitectónico Introducción
-
Upload
alexander-pisquiy -
Category
Documents
-
view
20 -
download
0
description
Diseño arquitectonico de sistemas
Transcript of Diseno_arquitectonico
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.
*
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.
*
