Este documento describe los conceptos clave del diseño arquitectónico de sistemas de información. Explica diferentes estilos arquitectónicos como la arquitectura centrada en datos, en capas y distribuida. También cubre temas como la descomposición modular, estilos de control y documentación de la arquitectura.

1. Ingeniería en Sistemas de Información Diseño de Sistemas (3K1)

2. Contenidos de la Unidad 2 Diseño Arquitectónico Organización del Sistema a. Arquitectura centrada en datos b. Arquitectura en capas c. Arquitectura de sistemas distribuidos c.1. Multiprocesador c.2. Cliente/Servidor c.3. Objetos distribuidos c.4. Peer-to-peer c.5. Orientada a servidos d. Arquitecturas de Aplicaciones Modelos de dominio específico Sommerville. Cap. 11 Sommerville. Cap. 12 Sommerville. Cap. 13 B. Descomposición modular y estilos de control Orientada a Objetos Orientada a flujos de funciones Control centralizado Control basado en eventos Sommerville. Sección 11.3

3. Diseño Arquitectónico (Organización del Sistema Ian Sommerville, Cap. 11 Ingeniería en Sistemas de Información

4. Los grandes sistemas se descomponen en subsistemas que proporcionan algún conjunto de servicios relacionados. El Proceso de Diseño que: 1) Identifica estos subsistemas y 2) establece un marco para el control y comunicación entre ellos es el Diseño Arquitectónico . El Proceso de Diseño Arquitectónico está relacionado con establecer un marco estructural básico para identificar los principales componentes de un sistema y las comunicaciones entre estos componentes . Diseño Arquitectónico Introducción

5. Diseño Arquitectónico Ventajas Hay 3 ventajas al diseñar explícitamente y documentar la arquitectura del software: 1. Comunicación con los usuarios. La arquitectura es una presentación de alto nivel del sistema que puede usarse como punto de discusión por varios usuarios. 2. Análisis del sistema. Hacer explícita la arquitectura del sistema, en una etapa temprana, requiere realizar algún análisis. Las decisiones de diseño arquitectónico tienen un gran efecto sobre los requerimientos críticos del sistema: rendimiento, fiabilidad y mantenibilidad.

6. 3. Reutilización a gran escala. Un Modelo de Arquitectura del Sistema es una descripción compacta y manejable de cómo se organiza un sistema y cómo inter-operan sus componentes . La arquitectura del sistema es a menudo la misma para sistemas con requerimientos similares. Por eso pueden soportar reutilización del software a gran escala. Es posible desarrollar arquitecturas en donde la misma arquitectura se usa en varios sistemas relacionados. Diseño Arquitectónico Ventajas

7. El Diseño Arquitectónico fuerza a los diseñadores a considerar aspectos de diseño claves en etapas tempranas del proceso . La Arquitectura del Software sirve como un Plan de Diseño que se usa para negociar los requerimientos del sistema y para estructurar las discusiones con los clientes, desarrolladores y gestores. También es una herramienta esencial para la gestión de la complejidad . La Arquitectura del Software oculta detalles y permite a los diseñadores centrarse en las abstracciones clave del sistema . Diseño Arquitectónico Otras Ventajas

8. La Arquitectura del Sistema afecta al rendimiento , solidez , grado de distribución y mantenibilidad de un Sistema . La estructura elegida para una aplicación puede depender de : 1. Rendimiento. Si el rendimiento es un requerimiento crítico, la arquitectura debería identificar las operaciones críticas en un pequeño número de subsistemas, con tan poca comunicación como sea posible entre los mismos, para priorizar el rendimiento. Diseño Arquitectónico Criterios que lo determinan

9. 2. Protección. Si la protección es un requerimiento crítico, debería usarse una arquitectura estructurada en capas, con los recursos más críticos protegidos en las capas más internas y aplicando una validación de seguridad de alto nivel en tales capas. 3. Seguridad. Si la seguridad es un requerimiento crítico, la arquitectura debe diseñarse para que las operaciones de seguridad se localicen en un único subsistema o en un pequeño número de subsistemas. Esto reduce los costos y los problemas de validación de seguridad. Diseño Arquitectónico Criterios que lo determinan

10. 4. Disponibilidad. Si la disponibilidad es un requerimiento crítico, la arquitectura debería diseñarse para incluir componentes redundantes y que se pueda reemplazar y actualizar componentes, sin detener el sistema. 5. Mantenibilidad. Si la mantenibilidad es un requerimiento crítico, la arquitectura del sistema debe diseñarse usando componentes independientes que puedan modificarse con facilidad. Diseño Arquitectónico Criterios que lo determinan

11. Pueden haber conflictos potenciales entre algunas de estas arquitecturas. Por ejemplo, hay componentes que mejoran el rendimiento, y otros, que mejoran la mantenibilidad. Si ambas propiedades son requerimientos importantes del sistema, entonces debería encontrarse una solución intermedia. Esto puede conseguirse usando diferentes estilos arquitectónicos para diferentes partes del sistema. Diseño Arquitectónico Criterios que lo determinan

12. Acá se solapan los procesos de Análisis y de Diseño Arquitectónico . Idealmente, el Análisis del Sistema no debería incluir ninguna información de Diseño . En la práctica, esto no es así, salvo en sistemas muy pequeños. La descomposición arquitectónica es necesaria para estructurar y organizar la especificación (Análisis). Diseño Arquitectónico Criterios que lo determinan

13. Un Diseño de Subsistemas es una descomposición abstracta de un sistema en componentes, donde cada uno puede ser un sistema importante. Los Diagramas de Bloques se usan para describir diseños de subsistemas, en donde cada caja, en el diagrama, representa un subsistema. Cajas dentro de otras cajas indican que el subsistema se ha descompuesto, a su vez, en otros subsistemas. Las flechas significan que los datos o señales de control pasan de un subsistema a otro, en la dirección de las flechas. Diseño Arquitectónico Diseño de Subsistemas

14. Los Diagramas de Bloques presentan un dibujo de alto nivel de la estructura del sistema , que puede entenderse fácilmente por personas de diferentes disciplinas, implicadas en el proceso de desarrollo. Los Diagramas de cajas y líneas no muestran la naturaleza de las relaciones entre los componentes del sistema ni tampoco las propiedades visibles de los componentes . Sin embargo, es un modelo efectivo para la comunicación con los usuarios del sistema y para la Planificación del Proyecto , porque no muestran los detalles. Diseño Arquitectónico Diagramas de Bloques

15. Los usuarios pueden relacionarlo con el sistema y tener una visión abstracta del mismo. El modelo identifica los subsistemas clave , que deben ser desarrollados de forma independiente, para poder asignar personal al desarrollo de cada uno. Los diagramas de cajas y líneas no deberían ser la única representación arquitectónica usada; aunque puedan resultar muy útiles. Decidir cómo descomponer un sistema en subsistemas es difícil. Diseño Arquitectónico Diagramas de Bloques

16. Los Requerimientos del Sistema son un factor fundamental. Debe diseñarse con una clara correspondencia entre los requerimientos y los subsistemas . Esto significa que, si los requerimientos cambian, este cambio probablemente esté localizado en un único sitio, en vez de estar distribuido entre varios subsistemas. Diseño Arquitectónico Correspondencia de los Subsistemas con los Requerimientos

17. El Diseño Arquitectónico es un proceso creativo , que organiza al sistema para satisfacer sus requerimientos funcionales y no funcionales. Como es un proceso creativo , las actividades del proceso difieren , dependiendo del tipo de sistema a desarrollar, el conocimiento y la experiencia del arquitecto del sistema, y los requerimientos específicos del mismo. Por eso es mejor concebir al Proceso de Diseño Arquitectónico desde una perspectiva de decisión en lugar de una perspectiva de actividades . Diseño Arquitectónico Un Proceso Creativo

18. Durante el Proceso de Diseño Arquitectónico , los diseñadores deben tomar decisiones fundamentales que afectan profundamente al sistema y a su proceso de desarrollo. Los Diseñadores deben responder las siguientes preguntas fundamentales: 1. ¿Hay alguna arquitectura genérica que pueda sirva como “plantilla” para el sistema que se está diseñando? 2. ¿Cómo se distribuirá el sistema entre varios procesadores? Diseño Arquitectónico Un Proceso Creativo

19. 3. ¿Qué estilo o estilos arquitectónicos son apropiados para el sistema? 4. ¿Cuál será la aproximación fundamental para estructurar el sistema? 5. ¿Cómo se descompondrán en módulos las unidades estructurales del sistema? 6. ¿Qué estrategia se usará para controlar el funcionamiento de las unidades del sistema? 7. ¿Cómo se evaluará el diseño arquitectónico? 8. ¿Cómo debería documentarse la arquitectura del sistema? Diseño Arquitectónico Preguntas que debe formularse el Diseñador

20. Si bien cada sistema de software es único, los sistemas, en el mismo dominio de aplicación , suelen tener arquitecturas similares , que reflejan los conceptos fundamentales del dominio. Estas arquitecturas de las aplicaciones pueden ser bastante genéricas, tales como la arquitectura de los sistemas de gestión de información, o pueden ser mucho más específicas. Diseño Arquitectónico Arquitecturas “ plantillas ”

21. Las aplicaciones son aplicaciones construidas sobre una arquitectura base, con variantes que satisfacen los requerimientos específicos del cliente. Cuando se diseña la arquitectura de un sistema, se debe decidir qué tiene en común ese sistema con clases de aplicaciones más amplias, y determinar en qué medida se pueden reutilizar esas arquitecturas. Diseño Arquitectónico Arquitecturas “ plantillas ”

22. Para sistemas embebidos y sistemas diseñados para computadoras personales, se utiliza normalmente un único procesador. Allí no será preciso diseñar una arquitectura distribuida para el sistema. Sin embargo, la mayoría de los sistemas grandes son sistemas distribuidos, donde el software del sistema se distribuye entre muchas computadoras diferentes. La elección de la arquitectura de distribución es una decisión clave que afecta al rendimiento del sistema. Diseño Arquitectónico Distribuir el procesamiento

23. La Arquitectura de un Sistema puede basarse en un Modelo o Estilo Arquitectónico particular. El Estilo Arquitectónico es un patrón de organización de un sistema , como ser: una organización cliente-servidor o una arquitectura por capas . Es importante conocer estos estilos, sus aplicaciones, y sus ventajas e inconvenientes. Sin embargo, las arquitecturas de la mayoría de los sistemas grandes no utilizan un único estilo . Diseño Arquitectónico Estilos Arquitectónicos

24. Pueden diseñarse diferentes partes del sistema utilizando distintos estilos arquitectónicos . En algunos casos, toda la arquitectura del sistema puede ser una arquitectura compuesta , creada mediante la combinación de diferentes estilos arquitectónicos. La noción de un Estilo Arquitectónico incluye las siguientes cuestiones de diseño: Se debe elegir la estructura más adecuada: sea cliente-servidor, o por capas, que permita satisfacer los requerimientos del sistema. Diseño Arquitectónico Estilos Arquitectónicos

25. Para descomponer las unidades del sistema estructural en módulos, hay que decidir la estrategia. Igual para descomponer subsistemas en sus componentes o módulos. En función de ello, podemos implementar diferentes tipos de arquitecturas. Diseño Arquitectónico Descomposición en Módulos

26. La Evaluación de un Diseño Arquitectónico es difícil . La verdadera prueba de una arquitectura consiste en averiguar el grado de satisfacción de sus requerimientos funcionales y no funcionales , lo que ocurre después de que se hubo desarrollado el sistema. Sin embargo, en algunos casos, se puede realizar alguna evaluación comparando el diseño elaborado, con modelos arquitectónicos genéricos o de referencia . Diseño Arquitectónico Evaluación

27. El resultado del Proceso de Diseño Arquitectónico es un Documento de Diseño Arquitectónico . Éste puede incluir varias representaciones gráficas del sistema, junto con texto descriptivo asociado. Debe describir cómo se estructura el sistema en subsistemas , la aproximación adoptada y cómo se estructura cada subsistema en módulos . Una forma posible de documentación es mediante la utilización de “ Modelos Gráficos del Sistema ”, que presentan diferentes perspectivas de la Arquitectura . Diseño Arquitectónico Documentación

28. Los modelos gráficos del sistema pueden ser: 1. Modelo estructural estático : muestra los subsistemas o componentes que han sido desarrollados como unidades separadas. 2. Modelo de proceso dinámico: muestra cómo se organiza el sistema en procesos, en tiempo de ejecución. 3. Modelo de interfaz: define los servicios ofrecidos por cada subsistema a través de su interfaz. 4. Modelos de relaciones: muestra las relaciones (flujo de datos) entre los subsistemas. 5. M odelo de distribución: muestra cómo se distribuyen los subsistemas entre las computadoras. Diseño Arquitectónico Modelos Gráficos del Sistema

29. La Organización de un Sistema refleja la estrategia usada para estructurar dicho sistema. Al principio del Proceso de Diseño Arquitectónico se toman decisiones sobre todo el modelo organizacional de un sistema . La Organización del Sistema puede reflejarse en la estructura de los subsistemas . Estudiaremos tres estilos organizacionales: un estilo de repositorio de datos , un estilo de servicios y servidores compartidos y una máquina abstracta o estilo por capas , en donde el sistema se organiza en un conjunto de capas funcionales . Estos estilos se pueden utilizar juntos o por separado . Diseño Arquitectónico Organización del Sistema

30. Diseño Arquitectónico El Modelo de Repositorio Los subsistemas que forman un sistema deben intercambiar información para poder trabajar, conjuntamente, de forma efectiva . Esto es puede conseguir de dos formas : Todos los datos compartidos se almacenan en una base de datos central a la que puede acceder por todos los subsistemas . Este modelo basado en una base de datos compartida se denomina M odelo de Repositorio .

31. 2. Cada subsistema mantiene su propia base de datos . Los datos se intercambian con otros subsistemas, pasando mensajes entre ellos. Este modelo es adecuado para aplicaciones donde los datos son generados por un subsistema y utilizados por otro. Ejemplos : los sistemas de gestión de información , CAD y herramientas CASE . La mayoría de los sistemas que usan grandes cantidades de datos se organizan alrededor de una base de datos compartida o repositorio . Diseño Arquitectónico El Modelo de Repositorio

32. Ventajas y Desventajas del Modelo Repositorio : 1. Forma eficiente de compartir grandes cantidades de datos . No hay necesidad de transmitir datos explícitamente de un subsistema a otro. 2. Los subsistemas deben estar acordes (compatibilidad) con el modelo de datos del repositorio . Puede ser difícil o imposible integrar nuevos subsistemas si sus modelos de datos no se ajustan al esquema acordado. Diseño Arquitectónico El Modelo de Repositorio

33. 3. Los subsistemas que producen datos no necesitan conocer cómo los otros subsistemas emplean sus datos . 4. La evolución puede ser difícil a medida que se genera mayor volumen de información . Llevar el Repositorio a un nuevo modelo tendrá un costo elevado ; puede ser difícil o aún imposible . La Figura siguiente muestra una arquitectura de herramientas CASE , basada en un Repositorio Compartido: Diseño Arquitectónico Repositorio: Ventajas y Desventajas

34. 5. Las actividades tales como: copias de seguridad, protección, control de acceso y recuperación de errores están centralizadas . Se gestionan a nivel del Repositorio . 6. Sin embargo, diferentes subsistemas pueden tener distintos requerimientos de protección, recuperación y políticas de seguridad . El modelo de repositorio impone una misma política para todos los subsistemas . Diseño Arquitectónico Repositorio: Ventajas y Desventajas

35. 7. El Repositorio facilita compartir recursos . Las nuevas herramientas se integran directamente, ya que son compatibles con el modelo de datos. 8. Es difícil distribuir el Repositorio sobre varias máquinas . Si bien es posible un Repositorio Centralizado Lógicamente , puede haber problemas con la redundancia de datos y las inconsistencias . Diseño Arquitectónico Repositorio: Ventajas y Desventajas

36. Arquitectura de un conjunto de herramientas Case integradas Diseño Arquitectónico El Modelo de Repositorio

37. El Modelo Arquitectónico Cliente-Servidor es un Modelo de Sistema , que se organiza como un conjunto de servicios y servidores asociados , más unos clientes que acceden y usan los servicios . Componentes de este modelo: 1. Un conjunto de servidores que ofrecen servicios a otros subsistemas . Ejemplos : Servidores de Impresoras , que ofrecen servicios de impresión: Servidores de Archivos que ofrecen servicios de gestión de ficheros; y Servidores de Compilación : que ofrecen servicios de compilación de lenguajes de programación, etc. Diseño Arquitectónico Modelo Cliente – Servidor

38. 2. Un conjunto de clientes que llaman a los servicios ofrecidos por los servidores . Son normalmente subsistemas. Pueden haber varias instancias de un programa cliente ejecutándose concurrentemente. 3. Una red que permite a los clientes acceder a estos servicios . Esto no es estrictamente necesario, cuando clientes y servidores se ejecutan sobre una única máquina. En la práctica, la mayoría de los sistemas cliente-servidor se implementan como sistemas distribuidos. Diseño Arquitectónico Cliente – Servidor. Componentes

39. Los clientes pueden conocer los nombres de los servidores disponibles y los servicios que éstos proporcionan . Sin embargo, los servidores no necesitan conocer la identidad de los clientes o cuántos clientes tienen . Los clientes acceden a los servicios proporcionados por un servidor , a través de llamadas a procedimientos remotos usando un protocolo de petición-respuesta . Básicamente, un cliente realiza una petición a un servidor y espera hasta que recibe una respuesta. Diseño Arquitectónico Modelo Cliente – Servidor

40. Arquitectura de un sistema de biblioteca de películas y fotografías: Diseño Arquitectónico Modelo Cliente – Servidor

41. La Figura anterior muestra un ejemplo de un sistema basado en el Modelo Cliente-Servidor . Es un sistema multiusuario, basado en web, para proporcionar una biblioteca de películas y fotografías. Aquí, varios servidores gestionan diferentes tipos de dispositivos. Las secuencias de video deben ser transmitidas rápidamente y en sincronía, pero con baja resolución. Éstas pueden comprimirse en un almacén para que el servidor de vídeo gestione la compresión y descompresión de video en diferentes formatos. Diseño Arquitectónico Modelo Cliente – Servidor

42. Sin embargo, las fotografías deben mantenerse con una alta resolución , por lo que es adecuado mantenerlas en un servidor separado . El catálogo debe manejar gran variedad de peticiones y proporcionar enlaces al sistema de información, con datos sobre las películas y las fotografías. También debe contemplar un sistema de comercio electrónico , para la venta de películas y fotografías. El programa Cliente es simplemente una interfaz de usuario integrada con estos servicios y construida sobre un navegador web. Diseño Arquitectónico Modelo Cliente – Servidor

43. La ventaja más importante del modelo Cliente-Servidor es que es una arquitectura distribuida . Se puede hacer un uso efectivo de los sistemas en red , con muchos procesadores distribuidos . Es fácil añadir un nuevo servidor e integrarlo con el resto del sistema o actualizar los servidores de forma transparente, sin afectar al resto del sistema. Diseño Arquitectónico Modelo Cliente – Servidor

44. El Modelo de Capas (o de Máquina Abstracta ) organiza el sistema en capas , cada una de las cuales proporciona un conjunto de servicios . La aproximación por capas soporta el desarrollo incremental de sistemas . A medida que se desarrolla una capa, algunos de los servicios proporcionados por esa capa pueden estar disponibles para los usuarios. Esta arquitectura soporta bien los cambios y es portable. Diseño Arquitectónico Modelo de Capas

45. Mientras su interfaz permanezca sin cambios, una capa puede reemplazarse por otra capa equivalente. Cuando las interfaces de la capa cambian o se añaden nuevas facilidades a una capa, solamente se ve afectada la capa adyacente. Únicamente las capas más internas deben ser reimplementadas para incorporar las facilidades de un sistema operativo o base de datos diferente. Diseño Arquitectónico Modelo de Capas

46. Ejemplo de un Modelo de Capas: Diseño Arquitectónico Modelo de Capas

47. La Capa de Gestión de Configuraciones es similar a la Capa de Presentación que nos enseñaba Craig Larman . La Capa de Gestión de Objetos almacena información y servicios de gestión (análoga a la Capa de Lógica de Larman ). El sistema se construye sobre una Capa de Base de Datos , para almacenamiento básico de datos y servicios ( gestión de transacciones , recuperación de actualizaciones y control de acceso ). La Base de Datos usa las facilidades del Sistema Operativo subyacente. Diseño Arquitectónico Modelo de Capas

48. Desventaja de este modelo: la estructuración de los sistemas puede resultar difícil . Las capas internas pueden proporcionar facilidades básicas , tales como gestión de archivos , que son requeridas por todos los niveles . Por lo tanto: los servicios requeridos por un usuario del nivel superior pueden tener que « atravesar » las capas adyacentes para acceder a los servicios proporcionados por los niveles inferiores . Esto trastoca el modelo , ya que implica que la capa más externa del sistema no solamente depende de su predecesora inmediata . Diseño Arquitectónico Modelo de Capas

49. El rendimiento puede también ser un problema. Si hay muchas capas, un servicio solicitado desde la capa superior puede tener que ser interpretado varias veces en diferentes capas, antes de ser procesado. Para evitar estos problemas, las aplicaciones tienen que comunicarse directamente con las capas interiores en vez de usar los servicios proporcionados por las capas adyacentes. Diseño Arquitectónico Modelo de Capas