Principios básicos
En la actualidad, uno de los temas candentes del que se habla dentro de la comunidad de desarrollo de software es el referente a las arquitecturas. Una arquitectura de software describe cómo un sistema se desglosa en componentes, cómo son interconectados y la manera en que se comunican e interactúan entre sí. Tras la definición anterior se pueden formular un par de preguntas: ¿en qué grado cumplimos con ésta definición durante el rol que desempeñamos como arquitecto o diseñador?, o mejor dicho: ¿Qué tan bien documentamos una arquitectura de software?
La finalidad de este artículo es contar con un punto de referencia sobre esta práctica, abordando dos de los enfoques más relevantes que han sido usados para realizar la tarea; también se describe su tendencia actual, y por último se menciona una serie de consideraciones que se deben tener en cuenta al momento de documentar.
Comúnmente una arquitectura de software se documenta a través de un conjunto de vistas, en donde cada una de ellas representa un aspecto o comportamiento particular del sistema. Dos de los artículos de mayor relevancia que abordan el tema del uso de vistas son los de Philippe B. Kruchten y el de Robert L. Nord y compañía. El primero es el más conocido porque la propuesta es parte fundamental de la metodología del Proceso Unificado, que en la actualidad es una de las metodologías que goza de cierto grado de popularidad.
Kruchten propone el uso de cinco vistas:
•Vista lógica. Apoya principalmente los requisitos funcionales, es decir, lo que el sistema debe brindar en términos de servicios a sus usuarios, desglosado en una serie de abstracciones primarias, tomadas principalmente del dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción, encapsulación y herencia. Esta descomposición no sólo enfatiza el análisis funcional, también sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema.
•Vista de procesos. Trata los aspectos de concurrencia y distribución, integridad del sistema, y tolerancia a fallas. También especifica en cuál hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica. Esta vista puede ser descrita como un conjunto de redes lógicas de procesos que son ejecutados de forma independiente, y distribuidos a lo largo de varios recursos de hardware conectados mediante un bus o a una red de datos.
•Vista de desarrollo. Se centra en la organización real de los módulos de software en el ambiente de desarrollo. El software se empaqueta en partes pequeñas que pueden ser bibliotecas o subsistemas creados por un desarrollador o un grupo de ellos, y se organizan en una jerarquía de capas, cada una brinda una interfaz estrecha y bien definida hacia las capas superiores.
•Vista física. Se toma en cuenta los requisitos no funcionales del sistema tales como: disponibilidad, confiabilidad y desempeño, entre otras más; y es ejecutado sobre varios nodos de procesamiento (hardware). Estos nodos son relacionados con los elementos identificados de las vistas anteriores. Aquí se especifican varias configuraciones físicas, por ejemplo: una para el desarrollo y las pruebas, o para el despliegue del sistema en plataformas distintas.
Kruchten define una última vista en la que propone el uso de un pequeño subconjunto de escenarios que son instancias de casos de uso. Su función es relacionar las cuatro vistas entre sí, de esta forma se cuenta con una perspectiva general del sistema, que ayuda a descubrir nuevos elementos o validar la arquitectura.
Por su parte, Nord y compañía realizaron un estudio para conocer en una arquitectura las estructuras que son de mayor importancia, y el uso de éstas. El estudio se efectuó sobre varios sistemas de software de ámbito industrial. Tras el estudio realizado propusieron cuatro categorías o vistas para agrupar las estructuras principales de una arquitectura, estas son:
•Vista conceptual. Se describe el sistema en términos de sus elementos principales de diseño y las relaciones entre ellos dentro de un dominio determinado. Esta vista es independiente de las decisiones de implementación y enfatiza en los protocolos de interacción entre los elementos de diseño.
•Vista de módulos. El sistema se descompone lógicamente en subsistemas, módulos, y unidades abstractas. Cada capa representa las distintas interfaces de comunicación permitidas entre los módulos.
•Vista de ejecución. Se describe la estructura dinámica del sistema en términos de sus elementos en tiempo de ejecución. Por ejemplo, se modela las tareas operativas del sistema, procesos, mecanismos de comunicación y asignación de recursos. Algunos de los aspectos que se consideran en esta vista son: el desempeño y el entorno de ejecución.
•Vista de código. Se organiza el código fuente en directorios, archivos y bibliotecas. Algunos de los aspectos que se incluyen son: los lenguajes de programación a utilizar, herramientas de desarrollo, la administración de la configuración y la estructura y organización del proyecto.
Es común que en la actualidad se utilice alguno de los 2 enfoques antes descritos. Sin embargo, la forma de documentar una arquitectura ha evolucionado significativamente. Ahora la tendencia sobre esta práctica se centra en dos aspectos principales:
• Los arquitectos deben documentar las vistas que sean de mayor utilidad y no ajustarse a un número fijo como lo muestran las propuestas.
• Documentar la arquitectura tomando en cuenta los intereses y necesidades de las personas involucradas en el proyecto, estos intereses se traducen como las cualidades que el sistema resultante debe poseer.
Esta nueva tendencia está respaldada por dos grandes institutos, uno de ellos es el Instituto de Ingeniería del Software (SEI) y el otro es el Instituto de Ingenieros Eléctricos y Electrónicos (IEEE) elaborado por el comité de estándares del IEEE Software. A continuación se describen los dos enfoques.
El SEI en su propuesta define tres categorías denominadas tipos de vista, en las que prácticamente cualquier vista, dependiendo del tipo de información que contenga, puede pertenecer a una de estas categorías. Los tipos de vista pueden ser:
•Vista de módulo. Describe cómo el sistema es estructurado en un conjunto de unidades de código.
•Vista de conectores y componentes. Describe cómo el sistema es estructurado en un conjunto de elementos que están en tiempo de ejecución así como su interacción.
•Vista de asignación. Describe la relación entre las unidades de software y los elementos del entorno como hardware, sistemas de archivos o la organización de los equipos de desarrollo de software.
Es importante señalar que cada tipo de vista viene acompañado de un conjunto predefinido de estilos, así los arquitectos pueden hacer uso de éstos para documentarlas. De acuerdo a Shaw y Garlan, un estilo arquitectónico es una descripción de los elementos, conectores, topología, y un conjunto de restricciones sobre la interacción de los elementos. El uso de estilos promueve la satisfacción de los intereses definidos por parte del personal involucrado en el proyecto.
El SEI recomienda contar con una guía de estilos que contenga entre otros aspectos: la descripción relevante del estilo, elementos, relaciones, propiedades, situaciones en las que no es recomendable aplicarlo, circunstancias en las que se recomienda usarlo, y posibles enfoques analíticos que el arquitecto puede utilizar. Para la elaboración de la guía de estilos se puede tomar como referencia el informe técnico realizado por Mark Klein y Rick Kazman, en el que los autores proponen un marco de trabajo para llevar acabo un razonamiento cualitativo o cuantitativo de los atributos de calidad presentes en un estilo arquitectónico, a través de una serie de ejemplos que describen el uso del marco de trabajo con los atributos de calidad: desempeño, facilidad de modificación y disponibilidad.
La documentación de las vistas se realiza a través de lo que se denomina paquetes de vista. Los paquetes de vista contienen un número reducido de elementos, logrando así una mejor comprensión ya que sólo se muestra un fragmento particular del sistema. De esta manera, una vista se descompone en uno o más paquetes de vista.
Para seleccionar las vistas a documentar, se sigue un procedimiento basado con respecto a las estructuras que se encuentran presentes de manera inherente en el sistema a construir, y en los intereses primarios del personal involucrado. El procedimiento consta de los siguientes pasos:
1) Elaborar una lista de vistas candidatas. En este paso se elabora una tabla con la siguiente información: en las columnas se enumera el conjunto de posibles vistas a documentar, mientras que en las filas se hace con el personal involucrado. En cada una de las celdas se especifica el grado de información que requiere cada una de los participantes en el proyecto, los valores posibles para las celdas pueden ser: requerido a detalle, de manera general o ninguno. Este paso concluye una vez que se han seleccionado las vistas de mayor interés.
2) Combinar las vistas. Posiblemente las vistas elegidas en el paso anterior sean imprácticas de documentar debido al número de vistas seleccionadas, en este paso se reduce la lista de vistas de una manera que pueda ser manejable por el arquitecto. La reducción se lleva acabo combinando varias vistas, de este modo una vista combinada muestra la información nativa de dos o más vistas separadas.
3) Priorizar las vistas. Aquí, el arquitecto debe tener el conjunto mínimo de vistas que satisfacen los intereses del personal involucrado. Después, en conjunto con el administrador del proyecto se procede a priorizar cada una de las vistas resultantes.
Una vez que las vistas se han seleccionado y priorizado, se inicia su documentación. El SEI cuenta con una plantilla que se puede utilizar de referencia para dicho propósito. De acuerdo al SEI, la documentación de una arquitectura debe contener los siguientes apartados:
• Presentación primaria. Muestra los elementos y sus relaciones entre sí, usualmente se representa de manera gráfica.
• Catálogo de elementos. Contiene los detalles de éstos, sus propiedades e interfaces.
• Diagrama de contexto. Muestra la relación entre el sistema o porción de éste y su entorno.
• Guía de variabilidad. Muestra los posibles puntos de variación en caso de que las vistas sean modificadas.
• Antecedentes de la arquitectura. Explica la justificación de la arquitectura así como los supuestos, y los resultados de los análisis realizados.
• Otra información. En esta sección se incluyen prácticas y políticas de la organización.
• Paquetes de vista relacionados. Básicamente, en esta sección se definen las relaciones entre los distintos paquetes de vista.
Para concluir con la propuesta del SEI, en la figura 1 se muestra los principales conceptos de este enfoque.
Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.
En el siguiente número continuaremos con la propuesta del IEEE, así como las propuestas a considerar en la documentación de arquitecturas.
Referencias
[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE Software, Los Alamitos, CA, USA. Vol. 12, No. 6, págs. 42-50. IEEE Computer Society Press. 1995. ]
[ Dilip Soni; Robert L. Nord & Christine Hofmeister. “Software Architecture in Industrial Applications”. ICSE ‘95: Proceedings of the 17th international conference on Software Engineering, New York, NY, USA. págs. 196-207. ACM. 1995. ]
[ Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Robert Nord & Judith Stafford. “Documenting Software Architectures: Views and Beyond”. Addison Wesley Professional. 2002. ]
[ Software Engineering Institute, SEI. “Views and Beyond Architecture Documentation Template”.Template 05 febrero 2006. ]
[ sei.cmu.edu/architecture/rcgh_doc.html ]
[ Omar Gómez. “Evaluando la Arquitectura de Software, Métodos de Evaluación”. Revista Software Gurú. Año 03 No. 02. 2007. ]
- Log in to post comments