Diseño Arquitectonico

Diseño de SistemasDiseño de Sistemas

Diseño de la ArquitecturaDiseño de la Arquitectura

Copyright Jorge Alvarado TabacchiCopyright Jorge Alvarado Tabacchi

¿Qué es? (1/2)¿Qué es? (1/2)

El diseño arquitectónico representa la estructura de los datos y de los componentes del programa que se requieren para construir un sistema.

La arquitectura del sw es la estructura o estructuras del sistema, lo que comprende a los componentes del sw, sus propiedades externas visibles y las relaciones entre ellas.


¿Qué es? (2/2)¿Qué es? (2/2)

Es una representación que permite 1) analizar la efectividad del diseño para cumplir los requerimientos establecidos, 2) considerar alternativas arquitectónicas en una etapa en la que hacer cambios en el diseño es relativamente fácil y 3) reducir los riesgos asociados con la construcción del software.

Pone énfasis en el papel de los “componentes del software” en cualquier representación arquitectónica.


¿Porqué es importante la ¿Porqué es importante la arquitectura? arquitectura? Las representaciones de la arquitectura del software

permiten la comunicación entre todas las partes (participantes) interesadas en el desarrollo de un sistema.

La arquitectura resalta las primeras decisiones que tendrán un efecto profundo en todo el trabajo de ingeniería de software.

La arquitectura “constituye un modelo relativamente pequeño y asequible por la vía intelectual sobre cómo está estructurado el sistema y la forma en que sus componentes trabajan juntos”.


Géneros Arquitectónicos (1/3)Géneros Arquitectónicos (1/3)

El género arquitectónico es el que dicta el enfoque específico para la estructura que deba construirse. Implica una categoría específica dentro del dominio general del software. Dentro de cada categoría hay varias subcategorías.

A continuación algunos de los géneros arquitectónicos para sistemas basados en software:– Inteligencia artificial: Sistemas que simulan el conocimiento

humano.– Comerciales y no lucrativos. Para la operación de una empresa– Comunicaciones: Proveen la infraestructura para transferir y

manejar datos


Géneros Arquitectónicos (2/3)Géneros Arquitectónicos (2/3)

– Contenido de autor: Crean o manipulan artefactos de texto o multimedia.

– Dispositivos: Interactúan con el mundo físico a fin de brindar algún servicio puntual a un individuo.

– Entretenimiento y deportes: Administran eventos públicos que proveen una experiencia grupal de entretenimiento.

– Financieros: Proporcionan la infraestructura para transferir y manejar dinero y otros títulos.

– Juegos: Dan una experiencia de entretenimiento a individuos o grupos.

– Gobierno: Dan apoyo a la conducción y operaciones de uns institución pública.


Géneros Arquitectónicos (3/3)Géneros Arquitectónicos (3/3)– Industrial: Simulan o controlan procesos físicos.– Legal: Sistemas que dan apoyo a la industria jurídica.– Médicos: Diagnostican, curan o contribuyen a la investigación

médica.– Militares: Consulta, comunicaciones, comando, control e

inteligencia así como de armas ofensivas y defensivas.– Sistemas operativos: Están inmediatamente instalados en el

hardware para dar servicios de software básico.– Plataformas; Se encuentran el los sistemas operativos para

brindar servicios avanzados.– Científicos. Para hacer investigación científica y aplicada.– Herramientas: Se utilizan para desarrollar otros sistemas.– Transporte: Controlan vehículos acuáticos, terrestres, etc.– Utilidades: Sistemas que interactúan con otro software para

brindar algún servicio.


Estilos de Arquitectura (1/9)Estilos de Arquitectura (1/9)

Arquitecturas centrada en los datos: En el centro de esta arquitectura se halla un almacenamiento de datos al que acceden con frecuencia otros componentes que actualizan, agregan o eliminan los datos. El software cliente suele acceder a los datos en forma independiente de cualquier cambio que éstos sufren o de las acciones del software de otro cliente. Una variante de este enfoque transforma el depósito en un “pizarrón” que envía notificaciones al software cliente cuando hay un cambio en datos de interés del cliente.



Figura 1. Arquitectura centrada en los datosFigura 1. Arquitectura centrada en los datos



Las arquitecturas centradas en los datos promueven la integralidad. Es decir, los componentes del software pueden ser cambiados y agregarse otros nuevos, del cliente, a la arquitectura sin problemas con otros clientes (porque los componentes del cliente operan en forma independiente).



Arquitecturas de flujo de datos: Se aplica cuando los datos de entrada van a transformarse en datos de salida a través de una serie de componentes computacionales o manipuladores. Un patrón de tubo y filtro tiene un conjunto de componentes llamados filtros, conectados por tubos que transmiten datos de un componente al siguiente. Cada filtro trabaja en forma independiente de aquellos componentes que se localizan arriba o abajo del flujo: se diseña para esperar una entrada de datos de cierta forma y produce datos de salida.



Figura 2. Arquitectura de flujo de datosFigura 2. Arquitectura de flujo de datos



Arquitecturas de llamar y regresar: Permite obtener una estructura de programa que es relativamente fácil de modificar y escalar. Dentro de esta categoría existen varios subestilos:– Arquitecturas de programa principal/subprograma. Esta

estructura clásica de programa descompone una jerarquía de control en la que un programa “principal” invoca cierto número de componentes de programa que a su vez invocan a otros. Ver figura

– Arquitecturas de llamada de procedimiento remoto. Los componentes de una arquitectura de programa principal/subprograma están distribuidos a través de computadoras múltiples de una red.



Figura 3. Arquitectura de programa principal/subprogramaFigura 3. Arquitectura de programa principal/subprograma


Estilos de Arquitectura (8/9)Estilos de Arquitectura (8/9) Arquitecturas orientada a objetos: Los

componentes de un sistema incluyen datos y las operaciones que deben aplicarse para manipularlos. La comunicación y coordinación entres los componentes se consigue mediante la transmisión de mensajes.

Arquitecturas en capas. Se define un número de capas diferentes. En la capa externa, los componentes atienden las operaciones de la interfaz de usuario. En la interna, los componentes realizan la interfaz con el sistema operativo. Las capas intermedias proveen servicios de utilerías y funciones de software de aplicación.



Figura 4. Arquitectura en capasFigura 4. Arquitectura en capas


Patrones arquitectónicosPatrones arquitectónicos

Los patrones arquitectónicos se abocan a un problema de aplicación específica dentro de un contexto dado y sujeto a limitaciones y restricciones . El patrón propone una solución arquitectónica que sirve como base para el diseño de la arquitectura.

La mayoría de las aplicaciones caen dentro de un género específico y para éstas son apropiados uno o más estilos de arquitectura, pero dentro de estos estilos se encontrarán una serie de problemas comunes que se abordan mejor con patrones arquitectónicos específicos.


Diseño ArquitectónicoDiseño Arquitectónico

Cuando comienza el diseño arquitectónico, el software que se va a desarrollar debe situarse en contexto, es decir, el diseño debe definir las entidades externas (otros sistemas, dispositivos, personas, etc.) con las que interactúa el software y la naturaleza de dicha interacción.

Una vez que se ha modelado el contexto y descrito todas las interfaces externas del software se identifica un conjunto de arquetipos de arquitectura. Un arquetipo es una abstracción (similar a una clase) que representa un elemento de comportamiento del sistema.


Diseño ArquitectónicoDiseño ArquitectónicoRepresentación del sistema en contexto (1/4)Representación del sistema en contexto (1/4)

Un diagrama de contexto arquitectónico (DCA) se usa para modelar la manera en la que el software interactúa con entidades más allá de su frontera.

En la figura se ilustra la estructura general de un DCA. En ella los sistemas que interactúan con el sistema objetivo (aquel para el que se va a desarrollar un diseño arquitectónico) están representados como sigue:– Sistemas superiores: aquellos que utilizan al sistema

objetivo como parte de algún esquema de procesamiento de alto nivel.



Figura 5Figura 5



– Sistemas subordinados: los que son usados por el sistema objetivo y proveen datos o procesamiento que son necesarios para completar las funciones del sistema objetivo

– Sistemas entre iguales (pares): son los que interactúan sobre una base de igualdad (por ejemplo la información se produce o consume por los iguales y por el sistema objetivo)

– Actores: entidades (personas, dispositivos, etc.) que interactúan con el sistema objetivo mediante la producción o consumo de información que es necesaria para el procesamiento de los requerimientos.

Cada una de estas entidades externas se comunica con el sistema objetivo a través de una interfaz (rectángulos pequeños sombreados).



Figura 6. Ejemplo de DCA para la función de Figura 6. Ejemplo de DCA para la función de seguridad de un sistema CasaSeguraseguridad de un sistema CasaSegura


Diseño ArquitectónicoDiseño ArquitectónicoDefinición de arquetipos (1/3)Definición de arquetipos (1/3)

Un arquetipo es una clase o un patrón que representa una abstracción fundamental de importancia crítica para el diseño de una arquitectura para el sistema objetivo.

La arquitectura del sistema objetivo está compuesta de estos arquetipos, que representan elementos estables de la arquitectura.

En muchos casos los arquetipos se obtienen con el estudio de las clases de análisis.



Figura 7. Relaciones de UML para los arquetipos de la función de seguridad de CasaSegura



Nodo. Representa una colección cohesiva de elementos de entrada y salida de la función de seguridad del hogar. Por ejemplo, un nodo podría comprender 1) varios sensores y 2) varios indicadores de alarma (salida)

Detector. Abstracción que incluye todos los equipos de detección que alimentan con información el sistema objetivo.

Indicador. Abstracción que representa todos los mecanismos (sirena, alarma, luces, etc.) que indican que está ocurriendo una condición de alarma.

Controlador. Abstracción que ilustra el mecanismo que permite armar o desarmar un nodo. Si residen en una red tienen la capacidad de comunicarse entre sí.


Diseño ArquitectónicoDiseño ArquitectónicoRefinamiento hacia los componentesRefinamiento hacia los componentes

Conforme la arquitectura se refina hacia los componentes, comienza a emerger la estructura del sistema. Para elegir los componentes se empieza con las clases descritas en el modelo de requerimientos, que representan entidades dentro del dominio de aplicación (negocio). Otra fuente de obtención y refinamiento de componentes es el dominio de la infraestructura. La arquitectura debe albergar muchas componentes de la infraestructura que hagan posible los componentes de la aplicación. Por ejemplo, los componentes de administración de memoria, de comunicación, de BD, con frecuencia están integrados a la arquitectura de software.



En el ejemplo de la función de seguridad de CasaSegura, debe definirse el conjunto de componentes de alto nivel que se aboque a las funciones siguientes:– Administración de la comunicación externa: coordina la

comunicación de la función de seguridad con entidades externas, tales como otros sistemas basados en internet y la notificación externa de una alarma.

– Procesamiento del panel de control: administra toda la funcionalidad del panel de control.

– Administración de detectores: coordina el acceso a todos los detectores del sistema.

– Procesamiento de alarmas: verifica y actúa todas las condiciones de alarma.



Figura 8. Estructura para los componentes de alto nivelFigura 8. Estructura para los componentes de alto nivel


Diseño ArquitectónicoDiseño ArquitectónicoDescripción de las instancias del sistemaDescripción de las instancias del sistema

A pesar del refinamiento anterior aun está en un nivel relativamente alto. Es necesario más refinamiento (diseño iterativo).

Para lograr ello se diseñan instancias de la arquitectura. Esto significa que la arquitectura se aplica a un problema específico con objeto de demostrar que tanto ella como sus componentes son apropiados.

La figura 9 ilustra instancias de la arquitectura CasaSegura para el sistema de seguridad. Por ejemplo, el componente administración de detectores interactúa con un componente infraestructura programador que implementa la prueba de cada objeto sensor usado por el sistema


Diseño ArquitectónicoDiseño ArquitectónicoDescripción de las instancias del sistemaDescripción de las instancias del sistema

Figura 9. Instancia de la función de seguridadFigura 9. Instancia de la función de seguridad


Mapeo de la Arquitectura con el uso Mapeo de la Arquitectura con el uso de Flujo de Datosde Flujo de Datos

Una técnica de mapeo llamada diseño estructurado se caracteriza con frecuencia como método de diseño orientado al flujo porque provee una transición conveniente de un diagrama de flujo de datos (DFD) a la arquitectura del software.

La transición del flujo de información (DFD) a estructura de programa se consigue como parte de un proceso de seis pasos: 1) se establece el tipo de flujo de información, 2) se indican las fronteras del flujo, 3) se mapea el DFD en la estructura del programa, 4) se define la jerarquía del control, 5) se refina la estructura resultante, y 6) se mejora y elabora la descripción arquitectónica.


Mapeo de TransformaciónMapeo de Transformación

El mapeo de transformación es un conjunto de pasos que permite mapear un DFD con características de flujo de transformación en un estilo arquitectónico específico. Seguimos con el ejemplo de CasaSegura. Un elemento del modelo de análisis es un conjunto de DFD que describen el flujo de información dentro de la función de seguridad. Para mapear estos DFD es una arquitectura de software deben darse los siguientes pasos de diseño:– Paso 1. Revisión del modelo del sistema fundamental. El

modelo del sistema fundamental o diagrama de contexto ilustra la función de seguridad y representa a los productores y consumidores externos de los datos que fluyen hacia dentro y fuera de la función.



Figura 10. Diagrama de flujo de datos de contextoFigura 10. Diagrama de flujo de datos de contexto



Figura 11. Diagrama de flujo de datos de nivel 1Figura 11. Diagrama de flujo de datos de nivel 1



– Paso 2. Revisar y mejorar los diagramas de flujos de datos para el software. La información obtenida del modelo de requerimientos se refina para producir más detalles. En el ejemplo se estudia el DFD de nivel 2 para vigilar sensores (Figura 12) y se obtiene el DFD de nivel (Figura 13). En el nivel 3 cada transformación en el diagrama de flujo de datos presenta una cohesión relativamente grande.



Figura 12. DFD en el nivel 2, Vigilar sensoresFigura 12. DFD en el nivel 2, Vigilar sensores



Figura 13. DFD en el nivel 3, Vigilar sensoresFigura 13. DFD en el nivel 3, Vigilar sensores

Diseño Arquitectonico

Documents

Transcript of Diseño Arquitectonico