viernes, 20 de octubre de 2017

Arquitectura de software - Parte 3

¡Hola a todos!

Para continuar con la tercera (y penúltima) parte sobre Arquitectura de Software me centraté en la Representación de la Arquitectura y Patrones de Arquitectura.

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.

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 @JarrobaWeb publicado en su blog que explica de forma breve y clara este modelo. 

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 sistema

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

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.

Por ejemplo, algunos atributos de calidad involucradas en las perspectivas suelen ser:
  • 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.

En casos en que el tipo de proyecto y la relación costo-beneficio lo ameriten, podríamos utilizar lenguajes de modelado para describir los aspectos que componen una arquitectura. Por ejemplo: Architecture Description Language (ADL) es un lenguaje informático utilizado para describir la arquitectura de un sistema de software.

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