Diseño de la Arquitectura

Continuando con nuestro recorrido alrededor del tema de la arquitectura de software, en esta ocasión, nos enfocaremos en la actividad de diseño de la arquitectura.

Diseño y arquitectura
Por extraño que parezca, no existe una definición generalmente aceptada de la palabra “diseño”. Recientemente se ha propuesto la siguiente definición de este concepto:

El diseño es la especificación de un objeto, creado por algún agente, que busca alcanzar ciertos objetivos, en un entorno particular, usando un conjunto de componentes básicos, satisfaciendo un conjunto de requerimientos y sujetándose a ciertas restricciones.

Retomando la definición de arquitectura de software presentada en la primera edición de esta serie de artículos, las correspondencias de los elementos de la definición de diseño con la arquitectura son las siguientes:

• El objeto se refiere a las distintas estructuras (físicas, lógicas, de ejecución) que componen a la arquitectura de software.
• El agente es el (los) arquitecto(s) de software u otros encargados del diseño.
• El entorno se refiere tanto al entorno de uso del sistema, por parte de los usuarios finales, como al entorno en que se desarrolla el sistema.
• Los objetivos son la satisfacción de los requerimientos que influyen a la arquitectura (los drivers) y la estructuración con el fin de guiar el desarrollo.
• Los componentes básicos son los conceptos de diseño a partir de los cuales se construye una arquitectura y que incluyen patrones de diseño y frameworks de tecnologías particulares.
• El conjunto de requerimientos, que se presentaron en la columna anterior, incluyen tanto a los requerimientos funcionales como a los no-funcionales (principalmente los atributos de calidad).
• Las restricciones, que también se discutieron en la columna anterior, son todas aquellas limitaciones impuestas ya sea por el cliente o bien por la organización misma de desarrollo.

Diseño guiado por atributos (ADD)
Existen diversos métodos de diseño de arquitectura de software. Uno que provee una guía para realizar el diseño arquitectural de forma sistémica es el Diseño Guiado por Atributos (Attribute Driven Design o ADD), que a continuación estudiaremos.

Este método recibe como entrada una lista de drivers arquitecturales y produce a su salida una serie de estructuras que conforman al diseño de la arquitectura. Se va aplicando de forma iterativa. Los pasos de ADD son los siguientes:

1. Revisar que se tiene suficiente información sobre los drivers arquitecturales.
2. Elegir un elemento a descomponer.
3. Elegir un sub-conjunto de drivers a satisfacer durante la iteración.
4. Elegir conceptos de diseño para satisfacer los drivers.
5. Aplicar los conceptos de diseño y asignar responsabilidades a los elementos resultantes.
6. Definir interfaces para los elementos resultantes.
7. Verificar la satisfacción de los drivers seleccionados en el paso 3.
8. Repetir los pasos anteriores para elementos que requieran un mayor refinamiento hasta cubrir la mayoría de los drivers.

ADD es un método que sigue un enfoque de “divide y vencerás”; en la primera iteración del diseño, el elemento a descomponer es el sistema en sí (paso 2). En iteraciones subsecuentes, el elemento a descomponer es un sub-elemento resultante de iteraciones previas. Generalmente se considera que el diseño de la arquitectura termina cuando se han tomado decisiones de diseño para satisfacer la mayor parte de los drivers en el tiempo permitido (pasos 7 y 8).

Conceptos de diseño
Al momento de realizar el diseño, el arquitecto dispone de una variedad de conceptos de diseño que le facilitan la creación de las diversas estructuras que conforman a la arquitectura. En el paso 4 del método, se eligen conceptos de diseño. A continuación describimos a qué se refiere esto.

Un concepto básico de diseño son los patrones de diseño, que son soluciones conceptuales a problemas recurrentes de diseño (tanto a nivel arquitectural como a nivel de diseño detallado). Estos patrones se describen en catálogos que explican, entre otras cosas, el contexto del problema, la solución conceptual y las implicaciones de la aplicación de la solución. Los patrones tienen nombres que permiten referirse a ellos de manera sencilla, algunos nombres son “cliente - servidor”, “capas”, “MVC”, “fábrica” u “observador”. Estos nombres dan lugar a un vocabulario de diseño que facilita la comunicación entre diseñadores. Una vez seleccionado un patrón, es necesario adecuarlo al contexto específico del problema (paso 5). Existe una gran cantidad de catálogos de patrones de diseño y un arquitecto experimentado debe conocer una buena cantidad de ellos o, al menos, saber en donde puede encontrarlos.

Otro tipo de concepto de diseño son los frameworks (marcos de trabajo) enfocados a tecnologías específicas. Estos frameworks, a diferencia de los patrones, no son conceptuales sino que son soluciones a nivel de código que se enfocan en resolver problemáticas particulares tales como la persistencia de objetos en bases de datos relacionales (ej. Hibernate), el soporte de aspectos tales como la seguridad y las transacciones (ej. Spring) o los aspectos de presentación (ej. JSF). Generalmente los frameworks son usados como librerías al momento de desarrollar código. Cabe señalar que los frameworks generalmente encapsulan a diversos patrones de diseño. Al igual que con los patrones, el arquitecto debe conocer una variedad de frameworks y saber dónde aplicarlos.

Existen tipos adicionales de conceptos de diseño que pueden ser usados durante el proceso de diseño, ejemplos de ello son las arquitecturas de referencia, que son diseños completos que sirven de punto de partida, o bien los componentes COTS (Commercial Off-the-Shelf), que son aplicaciones completas listas para ser integradas. Ejemplos de COTS incluyen middleware tales como buses de integración de servicios (ESB).

Un ejemplo
Para ejemplificar la aplicación del método ADD, a continuación mostraremos el resultado de algunos de los pasos del proceso para una iteración del diseño de arquitectura usando como base el ejemplo introducido en la columna anterior. Recordando, el ejemplo hacía referencia a la “compañía xyz que se dedica a la comercialización de productos de diversos fabricantes”.

Para este ejemplo, supondremos que ya se tiene suficiente información sobre los drivers (paso 1), que es la primera iteración, que el elemento a descomponer es el sistema entero (paso 2) y que se ha identificado el siguiente sub-conjunto de drivers para la iteración:

• Caso de uso primario: Realizar consultas del catálogo de productos.
• Atributos de calidad: Escenario de modificabilidad relativo a la facilidad para agregar nuevos sistemas externos de fabricantes de productos.
• Restricción: Uso de librerías y herramientas Open Source.

El siguiente paso (4) indica que debemos elegir conceptos de diseño para satisfacer los drivers. Dado que se tienen escenarios de modificabilidad y que se está en una iteración inicial del diseño, en la cuál se busca crear la estructuración de alto nivel del sistema, se elige como concepto de diseño el patrón de “capas”, que permite agrupar responsabilidades generales del sistema. Por otro lado, se elige el concepto de diseño de “módulos” para agrupar funcionalidades a nivel de las distintas capas y soportar el caso de uso elegido. Finalmente, se opta por aplicar el patrón Inversión de Control para conectar los componentes que estarán contenidos en los módulos y facilitar la integración de nuevos módulos. Este patrón se aplica mediante la introducción del framework “Spring”, que es open source.

Posteriormente, en el paso 5 aplicamos los conceptos de diseño y asignamos responsabilidades a los elementos resultantes. La figura 1 muestra un posible resultado inicial de descomposición de la arquitectura. Durante este paso del diseño, además de aplicar los conceptos de diseño, se asignan responsabilidades a los elementos identificados. Ejemplos de asignaciones de responsabilidades serían:

• La capa de integración contendrá el conjunto de elementos que permitirá a la aplicación comunicarse con los diferentes sistemas externos a través de diferentes canales.
• El módulo de InterfazCatálogos contiene los componentes que permiten desplegar las pantallas asociadas al caso de uso de consulta de catálogo de productos.

El siguiente paso (6) consiste en definir interfaces para los elementos resultantes. En iteraciones iniciales, las interfaces entre los elementos no se detallan de forma extensa, sin embargo en iteraciones subsecuentes, dichas interfaces deben documentarse de forma más detallada.

Ahora verificamos la satisfacfción de los drivers seleccionados en el paso 3. El primer nivel de descomposición de la arquitectura cubre los requerimientos de la siguiente forma: la solución incluye módulos que permitirán al usuario realizar las consultas al catálogo de productos, adicionalmente la división en capas favorece la modificabilidad. La selección tecnológica también favorece la modificabilidad y se apega a las restricciones. Ver Figura 1.

Figura 1. Ejemplo de descomposición del sistema.

Conclusión
Dadas las limitaciones de espacio, el ejemplo previo y la estructura resultante son muy simples. Es importante señalar que la estructura mostrada tendría que seguir siendo refinada en iteraciones subsecuentes para satisfacer el conjunto de drivers arquitecturales. Por otro lado, como parte del diseño, tendrían que producirse estructuras adicionales para mostrar aspectos tales como la implantación o la interacción de los componentes en ejecución. En este sentido, hay que recalcar que el diseño de la arquitectura no es solo un diseño de muy “alto nivel” que muchas veces es sinónimo de “poco detallado” ya que éste debe ser tan detallado como se requiera a fin de satisfacer la mayoría de los drivers.

Por último, vale la pena mencionar que la idea de documentar las decisiones que se toman durante las actividades de diseño actualmente está cobrando cada vez más importancia. Esta documentación es importante pues permite que posteriormente se evalúe el diseño además de que permite comprender la toma de decisiones del arquitecto al momento de realizar el mantenimiento del sistema.

Referencias
[1] Ralph, P. y Wand, Y., “A Proposal for a Formal Definition of the Design Concept”, Lecture Notes in Business Information Processing, Vol. 14, pp 103-136, 2009.
[2] Wojcik, R. et Al, “Attribute Driven Design (ADD), Versión 2.0”, CMU/SEI-2006-TR-023, 2006.