Published 17 years ago
(updated 13 years ago)
Parte 2. Documentando la Arquitectura de Software
En el número anterior vimos la propuesta de SEI que define tres categorías denomidas tipos de vista. Para concluir con esta propuesta en la figura 1 se muestran los principales conceptos de este enfoque.
Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.Por su parte, el IEEE Software propone el estándar IEEE 1471 que define un conjunto de recomendaciones centradas básicamente en 2 ideas, un marco conceptual para describir arquitecturas, y un conjunto de prácticas a seguir. La descripción de la arquitectura se organiza en un conjunto de vistas, cada vista modela una parte del sistema y satisface uno o más intereses de las personas involucradas. Los distintos intereses se deben considerar durante la construcción del sistema; si alguno de ellos no es considerado en al menos una de las vistas se dice que la descripción de la arquitectura está incompleta.
Cada vista se documenta de acuerdo a un punto de vista (elemento que pude ser reutilizado) determinado, definiendo las notaciones, técnicas y reglas para construir e interpretarla, a su vez, este determina cómo el contenido de una vista satisface uno o más intereses de las personas involucradas. En este marco conceptual, una vista es la instancia de un punto de vista dado. Un conjunto (biblioteca) de puntos de vista es análogo a la guía de estilos que propone el SEI. En la figura 2 se muestra un extracto del marco conceptual del estándar IEEE 1471.
Si se desea que la documentación de la arquitectura cumpla con el estándar, se deben seguir las siguientes prácticas:
• Identificación e información general. En esta práctica se lleva lo relacionado al control de versiones del documento, fecha, histórico de revisiones, estado, contexto del sistema, declaración del alcance, entre otros más.
• Identificación del personal involucrado y sus intereses. Se describen los diversos tipos de personas involucradas en el proyecto. Tales como, administradores, diseñadores, desarrolladores, usuarios, patrocinadores. A su vez, se incluye la diversidad de intereses que la arquitectura debe satisfacer.
• Puntos de vista. Cada de uno de estos debe contener un nombre, personal involucrado, intereses que satisface, lenguaje o técnicas de modelado utilizados durante la construcción de la vista, algún método analítico para analizar de manera cualitativa o cuantitativa los atributos de calidad que satisface el punto de vista, y su justificación.
• Vistas. Cada vista debe tener un identificador, una breve introducción y la representación del sistema con respecto a un punto de vista en particular.
• Consistencia entre vistas. Registra las inconsistencias entre las vistas, así como algún tipo de procedimiento que indique la consistencia entre ellas.
• Justificación. Se debe incluir la justificación del tipo de arquitectura seleccionada, y de los puntos de vista utilizados.
Actualmente, el IEEE e ISO están revisando en conjunto este estándar con el objetivo de tener una versión actualizada en el siguiente año para someterla a votación.
Estos dos últimos enfoques tienen varias similitudes entre sí. Por ejemplo, ambos se centran en las personas involucradas y en sus diversos intereses, ninguno de estos prescribe un número fijo de vistas, los dos enfoques hacen uso de la reutilización de artefactos; uno através de la guía de estilos y el otro por medio de una biblioteca de puntos de vista, en ambos la arquitectura debe estar justificada y los dos enfoques recomiendan el uso de análisis cualitativos o cuantitativos.
Una de las diferencias entre los dos enfoques es la siguiente. En el enfoque del SEI primero se selecciona un conjunto posible de vistas con respecto a las estructuras que están presentes en el sistema a construir, después se validan de acuerdo a un consenso de intereses por parte del personal involucrado, posteriormente se documentan. Por otra parte, el IEEE primero determina los intereses del personal involucrado, después en base a estos se selecciona un conjunto de puntos de vista que los satisfaga, por último se documenta cada una de las vistas basándose en los puntos de vista seleccionados.
Figura 2. Extracto del marco conceptual del estándar IEEE 1471
Conclusión
Uno de los principales beneficios de realizar esta práctica, es el poder efectuar evaluaciones sobre la arquitectura documentada, con el fin de determinar si se están cumpliendo o no los intereses del personal involucrado. Para finalizar, algunos de los puntos que se deben considerar al momento de documentar un arquitectura son:
• Documentar la arquitectura tomando en cuenta las necesidades e intereses de cada persona que forma parte del proyecto.
• Acompañar la documentación de las vistas con un modelo analítico que ayude a predecir el comportamiento de los atributos de calidad.
• UML no es el único lenguaje para documentar la arquitectura. Existen diferentes notaciones y lenguajes para este propósito, por ejemplo, lenguajes para descripción de arquitecturas (ADLs) que describen aspectos particulares de esta.
• Mantener una relación consistente entre las vistas.
• Elaborar plantillas de estilos para promover la reutilización de artefactos dentro de la organización.
• Mantener actualizada la matriz de trazabilidad entre los
requisitos y los elementos de la arquitectura.
• Tener bajo una línea base el documento de la arquitectura.
Referencias
[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE
Software., Los Alamitos, CA, USA, Volume 12, Number 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 ]
[ IEEE Architecture Working Group. “IEEE Standard 1471-2000,
Recommended practice for Architectural Description of Software-
Intensive Systems”. págs 1-23. IEEE, 2000 ]
[ Mary Shaw & David Garlan. “Software Architecture: Perspectives on an Emerging Discipline”. Abril. Prentice Hall. 1996 ]
[ Mark Klein; Rick Kazman & Robert Nord. “Attribute-Based
Architectural Styles”.Software Engineering Institute. Technical Report CMU/SEI-99-TR-22. Carnegie Mellon University. 1999 ]
[ Software Engineering Institute, SEI. “Views and Beyond Architecture Documentation Template” ]
[ sei.cmu.edu/architecture/arch_doc.html ]
[ Rich Hilliard. “ISO/IEC 42010/IEEE 1471: Architectural Description” ]
[ sei.cmu.edu/architecture/IEEE_1471.html ]
[ Omar Gómez. “Evaluando la Arquitectura de Software, métodos de evaluación”. Revista Software Gurú. Año 03 No. 02. 2007 ]
Acerca del Autor
Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software, en el Centro de Investigación en Matemáticas (CIMAT). Actualmente se encuentra trabajando como estudiante de postgrado en el área de Ingeniería del Software Empírica en la Facultad de Informática de la Universidad Politécnica de Madrid. Es miembro del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org
En el número anterior vimos la propuesta de SEI que define tres categorías denomidas tipos de vista. Para concluir con esta propuesta en la figura 1 se muestran los principales conceptos de este enfoque.
Figura 1. Relación de conceptos de la propuesta “vistas y más allá de éstas” del SEI.Por su parte, el IEEE Software propone el estándar IEEE 1471 que define un conjunto de recomendaciones centradas básicamente en 2 ideas, un marco conceptual para describir arquitecturas, y un conjunto de prácticas a seguir. La descripción de la arquitectura se organiza en un conjunto de vistas, cada vista modela una parte del sistema y satisface uno o más intereses de las personas involucradas. Los distintos intereses se deben considerar durante la construcción del sistema; si alguno de ellos no es considerado en al menos una de las vistas se dice que la descripción de la arquitectura está incompleta.
Cada vista se documenta de acuerdo a un punto de vista (elemento que pude ser reutilizado) determinado, definiendo las notaciones, técnicas y reglas para construir e interpretarla, a su vez, este determina cómo el contenido de una vista satisface uno o más intereses de las personas involucradas. En este marco conceptual, una vista es la instancia de un punto de vista dado. Un conjunto (biblioteca) de puntos de vista es análogo a la guía de estilos que propone el SEI. En la figura 2 se muestra un extracto del marco conceptual del estándar IEEE 1471.
Si se desea que la documentación de la arquitectura cumpla con el estándar, se deben seguir las siguientes prácticas:
• Identificación e información general. En esta práctica se lleva lo relacionado al control de versiones del documento, fecha, histórico de revisiones, estado, contexto del sistema, declaración del alcance, entre otros más.
• Identificación del personal involucrado y sus intereses. Se describen los diversos tipos de personas involucradas en el proyecto. Tales como, administradores, diseñadores, desarrolladores, usuarios, patrocinadores. A su vez, se incluye la diversidad de intereses que la arquitectura debe satisfacer.
• Puntos de vista. Cada de uno de estos debe contener un nombre, personal involucrado, intereses que satisface, lenguaje o técnicas de modelado utilizados durante la construcción de la vista, algún método analítico para analizar de manera cualitativa o cuantitativa los atributos de calidad que satisface el punto de vista, y su justificación.
• Vistas. Cada vista debe tener un identificador, una breve introducción y la representación del sistema con respecto a un punto de vista en particular.
• Consistencia entre vistas. Registra las inconsistencias entre las vistas, así como algún tipo de procedimiento que indique la consistencia entre ellas.
• Justificación. Se debe incluir la justificación del tipo de arquitectura seleccionada, y de los puntos de vista utilizados.
Actualmente, el IEEE e ISO están revisando en conjunto este estándar con el objetivo de tener una versión actualizada en el siguiente año para someterla a votación.
Estos dos últimos enfoques tienen varias similitudes entre sí. Por ejemplo, ambos se centran en las personas involucradas y en sus diversos intereses, ninguno de estos prescribe un número fijo de vistas, los dos enfoques hacen uso de la reutilización de artefactos; uno através de la guía de estilos y el otro por medio de una biblioteca de puntos de vista, en ambos la arquitectura debe estar justificada y los dos enfoques recomiendan el uso de análisis cualitativos o cuantitativos.
Una de las diferencias entre los dos enfoques es la siguiente. En el enfoque del SEI primero se selecciona un conjunto posible de vistas con respecto a las estructuras que están presentes en el sistema a construir, después se validan de acuerdo a un consenso de intereses por parte del personal involucrado, posteriormente se documentan. Por otra parte, el IEEE primero determina los intereses del personal involucrado, después en base a estos se selecciona un conjunto de puntos de vista que los satisfaga, por último se documenta cada una de las vistas basándose en los puntos de vista seleccionados.
Figura 2. Extracto del marco conceptual del estándar IEEE 1471
Conclusión
Uno de los principales beneficios de realizar esta práctica, es el poder efectuar evaluaciones sobre la arquitectura documentada, con el fin de determinar si se están cumpliendo o no los intereses del personal involucrado. Para finalizar, algunos de los puntos que se deben considerar al momento de documentar un arquitectura son:
• Documentar la arquitectura tomando en cuenta las necesidades e intereses de cada persona que forma parte del proyecto.
• Acompañar la documentación de las vistas con un modelo analítico que ayude a predecir el comportamiento de los atributos de calidad.
• UML no es el único lenguaje para documentar la arquitectura. Existen diferentes notaciones y lenguajes para este propósito, por ejemplo, lenguajes para descripción de arquitecturas (ADLs) que describen aspectos particulares de esta.
• Mantener una relación consistente entre las vistas.
• Elaborar plantillas de estilos para promover la reutilización de artefactos dentro de la organización.
• Mantener actualizada la matriz de trazabilidad entre los
requisitos y los elementos de la arquitectura.
• Tener bajo una línea base el documento de la arquitectura.
Referencias
[ Philippe Kruchten. “The 4+1 View Model of Architecture”. IEEE
Software., Los Alamitos, CA, USA, Volume 12, Number 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 ]
[ IEEE Architecture Working Group. “IEEE Standard 1471-2000,
Recommended practice for Architectural Description of Software-
Intensive Systems”. págs 1-23. IEEE, 2000 ]
[ Mary Shaw & David Garlan. “Software Architecture: Perspectives on an Emerging Discipline”. Abril. Prentice Hall. 1996 ]
[ Mark Klein; Rick Kazman & Robert Nord. “Attribute-Based
Architectural Styles”.Software Engineering Institute. Technical Report CMU/SEI-99-TR-22. Carnegie Mellon University. 1999 ]
[ Software Engineering Institute, SEI. “Views and Beyond Architecture Documentation Template” ]
[ sei.cmu.edu/architecture/arch_doc.html ]
[ Rich Hilliard. “ISO/IEC 42010/IEEE 1471: Architectural Description” ]
[ sei.cmu.edu/architecture/IEEE_1471.html ]
[ Omar Gómez. “Evaluando la Arquitectura de Software, métodos de evaluación”. Revista Software Gurú. Año 03 No. 02. 2007 ]
Acerca del Autor
Omar Salvador Gómez Gómez obtuvo el grado de Maestro en Ingeniería de Software, en el Centro de Investigación en Matemáticas (CIMAT). Actualmente se encuentra trabajando como estudiante de postgrado en el área de Ingeniería del Software Empírica en la Facultad de Informática de la Universidad Politécnica de Madrid. Es miembro del IEEE Computer Society. Puedes contactarlo en ogomez@ieee.org
- Log in to post comments