Tiempo de lectura estimado: 8-9 minutos.
Antes de comenzar, me gustaría recordar que en la parte anterior (parte 2) sobre Arquitectura de Software vimos cómo debería ser nuestro Proceso de definición de la Arquitectura y los distintos Atributos de calidad. Sigamos ahora con los temas Representación y Patrones.
Representación de la arquitectura
La Representación de la arquitectura se basa en los conceptos de Puntos de vista (Viewpoints) y Vistas (Views). La motivación de realizar una representación de la arquitectura basada en estos dos conceptos es que no es posible capturar los aspectos funcionales y propiedades de calidad de un sistema complejo en un modelo simple, comprensible y de valor para todos los stakeholders. Un sistema complejo es más efectivo describirlo utilizando un conjunto de vistas interrelacionadas que lo ilustren colectivamente.
Una view es una representación de uno o más aspectos estructurales de
una arquitectura que ilustra como la arquitectura lleva adelante uno o
más concerns de uno o más stakeholders.
Un viewpoint es una colección de patrones, plantillas y convenciones para la construcción de una vista.
Un viewpoint es una colección de patrones, plantillas y convenciones para la construcción de una vista.
Views
Un modelo de Vistas bastante conocido es el Modelo de Vistas de Arquitectura 4+1 de Kruchten que relaciona la vista lógica, vista de procesos, vista de despliegue y vista física, y la vista “+1” vista de escenario que tiene la función de relacionar las 4 vistas anteriores.El link anterior hace referencia a un post de
Viewpoints
Para ahondar un poco en este punto tomemos como referencia los Viewpoints de Rozanski & Woods del libro Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives.Viewpoint Funcional :: describe los elementos funcionales, sus responsabilidades, interfaces e interacciones
Viewpoint de Información :: describe la forma en la que la arquitectura almacena, manipula, administra y distribuye la información
Viewpoint de Concurrencia :: describe cómo ciertas unidades funcionales pueden ejecutarse concurrentemente y cómo eso se coordina y controla dicha concurrencia
Viewpoint de Desarrollo :: describe los aspectos de interés para aquellos
stakeholders involucrados en la construcción, testing, mantenimiento y
mejora del sistemaViewpoint de Concurrencia :: describe cómo ciertas unidades funcionales pueden ejecutarse concurrentemente y cómo eso se coordina y controla dicha concurrencia
Viewpoint de Despliegue :: describe el ambiente de hardware y el ambiente de ejecución en el cual el sistema será instalado
Viewpoint Operacional :: describe cómo el sistema será operado, administrado y soportado en el entorno de producción
Viewpoint Operacional :: describe cómo el sistema será operado, administrado y soportado en el entorno de producción
Perspectives
Otro concepto importante que aparece en el contexto de la definición de las Viewpoints and View son las Perspectives. Una perspectiva es una colección de actividades, tácticas y guías
utilizadas para asegurar que un sistema exhibe un conjunto determinado
de atributos de calidad que requieren consideración a través de
diferentes vistas de la arquitectura.
- Accesibilidad, Disponibilidad, Usabilidad
- Evolución, Internacionalización, Regulación
- Performance, Escalabilidad, Seguridad
Las perspectivas deberían ser consideradas en diferentes vistas, por ejemplo:
Nivel de aplicabilidad: Baja, Media, Alta |
SAD
Formalmente la arquitectura se debería representar mediante un Software Architecture Document (SAD).
Es un artefacto que provee una vista global de la arquitectura de un sistema y sirve como medio de comunicación entre el arquitecto y el resto del equipo de desarrollo. El link anterior es una referencia a la documentación del "Artefacto: SAD" que define el Rational Unified Process (RUP).
Tan importante como su existencia, es que la descripción debe mantenerse actualizada a lo largo del proyecto ya que su contenido debe reflejar la evolución del sistema. Sin embargo, su tamaño no debe crecer excesivamente, de lo contrario puede resultar una actividad en demasiado costosa.
Otro punto muy importante es mantener la consistencia entre las Views. Partir la representación de la arquitectura en vistas dificulta asegurar la consistencia entre ellas. Sin esta consistencia, probablemente el sistema no funcione apropiadamente, no cumpla con los objetivos de diseño y eventualmente se dificulte su construcción.
Patrones de Arquitectura
Como mencionaba al comienzo, un Patrón de Arquitectura es un concepto que está directamente relacionado con los viewpoints. Por definición, un patrón describe un problema que ocurre una y otra vez en deternimado contexto, y describe a su vez lo más importante de la solución a dicho problema de forma tal que esa solución pueda utilizarse muchas veces, incluso sin siquiera tener que hacerlo siempre de la misma manera.Cuando se define un Patrón de Arquitectura suele generarse la siguiente documentación...
- Contexto:
- Se describe una situación recurrente que da lugar a un problema
- Problema:
- Se define un problema genérico que surge en un determinado contexto
- Se describe el problema principal y sus variantes
- Se enumeran los Atributos de calidad que se deben cumplir
- Solución:
- Se describe con las abstracciones necesarias
- Se definen las responsabilidades y relaciones entre los elementos que la componen
- Se detalla la topología de sus componentes y los mecanismos de interacción entre ellos
- Se identifican los atributos de calidad provistos
Aquí un ejemplo del patrón de arquitectura Broker:
Contexto
Muchos sistemas son construidos en base a un conjunto de sistemas distribuidos entre múltiples servidores. Implementar dichos sistemas es complejo...
- Se debe resolver la interoperabilidad
- ¿cómo se conecta al sistema?
- ¿cómo intercambia información con el sistema?
- Se debe resolver la disponibilidad
- ¿Qué hacer cuando el sistema no está disponible?
Problema
¿Cómo se estructura el software distribuido de forma tal que los usuarios de los servicios (distribuidos) no deban conocer la naturaleza, ni ubicación de los proveedores de servicios, simplificando el cambio dinámico de enlaces entre usuarios y proveedores?
Algunos Atributos de calidad involucrados en este problema son Interoperabilidad, Disponibilidad y Performance.
Solución
Aquí un diagrama de la solución propuesta y luego algunas características de la solución...
- Es posible balancear la carga entre servidores
- Si un servidor no está disponible, se intercambia por otro
- Broker posee conectores específicos para comunicarse con los servidores
- Separa a los usuarios de servicios (clientes) de los proveedores de servicios (servidores) insertando un intermediario (Broker).
- Cuando un cliente necesita un servicio:
- el Cliente consulta al Broker vía una interfaz de servicio
- el Broker reenvía la solicitud del cliente al servidor, quien procesa el pedido
- el resultado del servicio se comunica desde el servidor al Broker, quien retorna el resultado al cliente solicitante.
- El cliente permanece ignorante de la identidad, ubicación y características del servidor.
- Si un servidor no está disponible, el Broker puede dinámicamente remplazarlo por otro servidor equivalente. El único al tanto de este cambio es el Broker.
Beneficios del patrón Broker
- Disponibilidad: se puede reemplazar un servidor por otro de forma dinámica
- Performance: es posible balancear la carga entre la granja de servidores identificando al de menor carga
- Interoperabilidad: puede proveer conectores específicos para la comunicación con los servidores
Desventajas del patrón Broker
- Mayor complejidad del sistema: el Broker debe ser diseñado e implementado, definiendo protocolos para el intercambio de mensajes.
- Agrega un nivel de indirección entre clientes y servidores
- Agrega latencia en la comunicación
- Broker puede ser único punto de falla
- es candidato a recibir ataques de seguridad
- puede ser cuello de botella
Más allá de las ventajas y desventajas, la motivación para el uso de patrones de arquitectura son variadas, por ejemplo, habitualmente se dice que “hay muchas formas de diseñar mal un software y muy pocas para hacerlo bien” y “los patrones de arquitectura son formas probadas de diseñar bien un software”.
Espero les siga resultando interesante la temática y les siga aportando en algo... como dije en la primera entrega, la idea es compartir, difundir y discutir, así que si tienen opiniones y experiencias para plantear, sería interesante que dejaran un comentario al respecto.
La próxima semana será la última parte de esta temática Arquitectura de Software y estaré tratando Arquitecturas Orientadas a Servicios y Evaluaciones de Arquitecturas.
¡Hasta la próxima!
No hay comentarios:
Publicar un comentario