Lenguajes de Descripción Arquitectónica

Lenguajes de Descripción Arquitectónica

Lenguaje descriptivo de modelado arquitectónico de software que se focaliza en la estructura de alto nivel de la aplicación antes que en los detalles de implementación de sus módulos concretos. Su abreviatura es ADL.

Surgimiento

El primer estudio en que aparece la expresión Arquitectura de software(AS) en el sentido que hoy se conoce es el de Dewayne E. Perry y Alexander L. Woolf; que ocurrió en 1992, aunque se venía indagando en el tema desde la década de los 60. En el texto fundacional de la AS, Perry y Woolf establecen el razonamiento sobre estilos de arquitectura como uno de los aspectos fundamentales de la disciplina ya que los estilos conjugan elementos (componentes), conectores, configuraciones y restricciones. Al estipular los conectores como elemento de juicio de primera clase, el concepto de estilo, incidentalmente, se sitúa en un orden de discurso y de método que el modelado orientado a objetos en general y UML en particular no cubren satisfactoriamente. Esto lo confirma unos años más tarde en una presentación, David Garlan, cuando señala deficiencias de UML en relación con lo que podría ser la representación de estilos.

Los ADL se remontan a los lenguajes de interconexión de módulos (MIL) de la década de 1970, pero se han comenzado a desarrollar con su denominación actual a partir de la década de 1990, poco después de fundada la propia arquitectura de software como especialidad profesional. Estos lenguajes surgen por la necesidad de satisfacer los requerimientos descriptivos de alto nivel de abstracción que las herramientas basadas en objeto en general y UML en particular no cumplen satisfactoriamente.

Ya que si es cierto que el modelado orientado a objetos de sistemas basados en componentes posee cierto número de rasgos muy convenientes a la hora de diseñar o al menos describir un sistema. No es menos cierto que la descripción de sistemas basados en componentes presenta también limitaciones serias, casi todas estructurales. Pues solo proporcionan una única forma de interconexión primitiva: la invocación de método, lo cual hace difícil modelar formas de interacción más ricas o diferentes. Además, el soporte de los modelos orientados a objetos para las descripciones jerárquicas es, en el mejor de los casos, débil. Tampoco se soporta la definición de familias de sistemas o estilos; y no hay recurso sintáctico alguno para caracterizar clases de sistemas en términos de las restricciones de diseño que debería observar cada miembro de la familia. Y por último, no brindan soporte formal para caracterizar y analizar propiedades no funcionales, lo que hace difícil razonar sobre propiedades críticas del sistema, tales como performance y robustez.

Sin embargo los ADL permiten modelar una arquitectura mucho antes que se lleve a cabo la programación de las aplicaciones que la componen, analizar su adecuación, determinar sus puntos críticos y eventualmente simular su comportamiento. La mayoría de los ADL existentes han sido de extracción académica, donde ha jugado un papel relevante la Universidad de Carnegie Mellon (CMU), en donde surgen ADL tales como Wright (1994) que es un ADL de propósito general con énfasis en comunicación, Aesop (1994) el cual tiene un propósito general también pero hace énfasis en estilos, UniCon (1995) que reúne características de los dos anteriores ya que hace énfasis en conectores y estilos y Armani(1998) que es un ADL asociado a Acme, los dos primeros creados por David Garlan y el tercero por Mary Shaw quienes son miembros de la facultad de ingeniería de software de dicha universidad y los cuales han brindado significativos aportes al campo de la AS en general y al de los ADL en particular. Ya que fueron ellos quienes en 1994, el cual podría ser considerado como “el año de oro de la Arquitectura de Software”, quienes lanzan el concepto de Lenguajes de Descripción Arquitectónica (ADL), en su libro “Characteristics of Higher Level Languages for Software Architecture”. En el estudio se señalan las alternativas que hasta el momento se poseen para la definición de la AS de un sistema. En primer lugar, a través de la modularización de las herramientas existentes de programación y de los módulos de conexión entre ellas y, en segundo lugar, describir sus diseños usando diagramas informales y frases idiomáticas.

A partir de estas reflexiones, definen un conjunto de regularidades y propiedades específicas, que constituyeron las bases de los ADL(6). Hasta hace pocos años existía relativamente poco consenso respecto a qué es un ADL, cuáles lenguajes de modelado califican como tales y cuáles no, y qué aspectos de la arquitectura se deben modelar con dichos lenguajes. Sin embargo actualmente los ADL son bien conocidos en los estudios universitarios de arquitectura de software(AS), aunque son muy pocos los arquitectos de industria que los utilizan como instrumento en el diseño arquitectónico de sus proyectos a pesar que los ADL difieran sustancialmente de los UML y que cubran necesidades que este último no es capaz de satisfacer.

Viendo la trayectoria que han seguido los lenguajes de descripción arquitectónica desde su surgimiento hasta hoy en día se puede decir que no han logrado abrirse mucho paso en la industria a pesar que la arquitectura de software sigue avanzando, y que queda aun mucho por descubrir e indagar en cuanto a los ADL.

Conceptos y principales elemento de los ADL

Para poder adentrarse en el mundo de los ADL y entenderlos en su totalidad es necesario conocer una serie de conceptos que ayudaran además a un mejor desenvolvimiento y entendimiento de este trabajo. Uno de estos conceptos es el de Arquitectura de software expuesto anteriormente.

Otra definición que debe quedar bien esclarecida es la de ADL, que como todos los componentes de la arquitectura no es rígida ni unívoca sino que está dada por el criterio de diferentes arquitectos según su experiencia o necesidades. Una de estas definiciones (además bastante general) sostiene que un ADL es una entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y restricciones, sin embargo hay ADL que pueden modelar o soportar los siguientes conceptos: Componentes, Conexiones, Composición jerárquica (en la que un componente puede contener una sub-arquitectura completa), Paradigmas de computación, es decir, semánticas, restricciones y propiedades no funcionales, Paradigmas de comunicación, Modelos formales subyacentes, Soporte de herramientas para modelado (análisis, evaluación y verificación) y Composición automática de código aplicativo. Debe quedar claro que no todos los ADL son capaces de soportar estos conceptos, generalmente para soportarlos todos se deben unir más de uno.

Entre las características de estos lenguajes podemos considerar las siguientes:

• Composición: que permiten la representación del sistema como la composición de una serie de partes.
• Configuración y Abstracción: Mediante las cuales se describen los roles o papeles abstractos que juegan los componentes dentro de la arquitectura.
• Flexibilidad: Ya que permiten la definición de nuevas formas de interacción entre componentes.
• Reutilización: Pues permiten la reutilización tanto de los componentes como de la propia arquitectura, Heterogeneidad ya que pueden combinar descripciones heterogéneas.
• Análisis: Permiten diversas formas de análisis de la arquitectura y de los sistemas desarrollados a partir de ella.

Los conceptos que aparecen a continuación se ha decidido tratarlos por separado ya que es necesario que queden bien esclarecidos para un mayor entendimiento y mejor desenvolvimiento del trabajo de diploma, ellos son:

• Componentes: Representan los elementos computacionales primarios de un sistema. Intuitivamente, corresponden a las cajas de las descripciones de caja-y-línea de las arquitecturas de software. Ejemplos típicos serían clientes, servidores, filtros, objetos, pizarras y bases de datos. En la mayoría de los ADL los componentes pueden exponer varias interfaces, las cuales definen puntos de interacción entre un componente y su entorno.
• Conectores: Representan interacciones entre componentes. Corresponden a las líneas de las descripciones de caja-y-línea. Ejemplos típicos podrían ser tuberías (pipes), paso de mensajes, llamadas a procedimientos, protocolos cliente-servidor o conexiones entre una aplicación y un servidor de base de datos. Los conectores también tienen una especie de interfaz que define los roles entre los componentes participantes en la interacción.
• Configuraciones o sistemas: Se constituyen como grafos de componentes y conectores. En los ADL más avanzados la topología del sistema se define independientemente de los componentes y conectores que lo conforman. Los sistemas también pueden ser jerárquicos: componentes y conectores pueden subsumir la representación de lo que en realidad son complejos subsistemas.
• Restricciones: Representan condiciones de diseño que deben acatarse incluso en el caso que el sistema evolucione en el tiempo. Restricciones típicas serían restricciones en los valores posibles de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de clientes que se puede conectar simultáneamente a un servicio.
• Propiedades: Representan información semántica sobre un sistema más allá de su estructura. Distintos ADL ponen énfasis en diferentes clases de propiedades, pero todos tienen alguna forma de definir propiedades no funcionales, o pueden admitir herramientas complementarias para analizarlas y determinar, por ejemplo, la velocidad de transferencia de datos y la latencia probables, o cuestiones de seguridad, escalabilidad, dependencia de bibliotecas o servicios específicos, configuraciones mínimas de hardware y tolerancia a fallas.
• Propiedades no funcionales: La especificación de estas propiedades es necesaria para simular la conducta de runtime, analizar la conducta de los componentes, imponer restricciones, mapear implementaciones sobre procesadores determinados, etcétera.
• Estilos: Representan familias de sistemas, un vocabulario de tipos de elementos de diseño y de reglas para componerlos. Ejemplos clásicos serían las arquitecturas de flujo de datos basados en grafos de tuberías (pipes) y filtros, las arquitecturas de pizarras basadas en un espacio de datos compartido, o los sistemas en capas. Algunos estilos prescriben un framework , un estándar de integración de componentes, patrones arquitectónicos o como se lo quiera llamar. A continuación se mencionan algunos estilos arquitectónicos: Estilos de Flujo de Datos, Estilos Centrados en Datos, Estilos de Llamada y Retorno, Estilos de Código Móvil, Estilos heterogêneos y Estilos Peer-to-Peer.

Cuando se habla de estilos no se pueden olvidar los patrones de arquitectura los cuales están claramente dentro de la disciplina arquitectónica, solapándose con los estilos. Dichos patrones arquitectónicos expresan esquemas de organización estructural fundamentales para los sistemas de software, los cuales con un empaquetado un poco distinto, no son más que estilos y a su vez proporcionan un conjunto de subsistemas predefinidos, especifican sus responsabilidades e incluyen guías y lineamientos para organizar las relaciones entre ellos.

• Dinamismo: Un ADL debe ser capaz de describir arquitecturas dinámicas y cambiantes ya que así permite interpretar los flujos de transformación y adaptabilidad de las mismas.
• Comunicación: El ADL debe comunicar todas las partes de una arquitectura así como definir todas las estructuras de la misma ya sean estáticas o dinámicas las cuales deben ser capaces de identificar los diversos tipos de conectores y componentes. Además la información que proporcionan las descripciones arquitectónicas se debe poder personalizar según el lector actual de la arquitectura.
• Verificación de Propiedades (Análisis y Validación): El ADL debe dar soporte a las tareas de creación de la arquitectura, así como refinamiento y validación de las mismas. Para esto definirá reglas sobre lo que se entiende por una arquitectura completa y consistente.
• Abstracción: El ADL debe ser capaz de proporcionar estructuras del sistema que expresen información arquitectónica y que además enmascare toda la información sobre la implementación que no sea arquitectónica.
• Derivación: El ADL debe proporcionar una base para fomentar la implementación como por ejemplo: la generación rápida de prototipos. Debe permitir la agregación de información fuera de la descripción arquitectónica obtenida con la misma manera que permita que una especificación final del sistema se derive de dicha descripción arquitectónica.
• Alternativas de Implementación: El ADL debe ser capaz de soportar la especificación de familias de implementaciones que satisfagan toda una arquitectura común.

Importancia y aplicación práctica

Los lenguajes de descripción de arquitecturas, ocupan una parte importante del trabajo arquitectónico desde la fundación de la AS. Ya que contando con un ADL, un arquitecto puede razonar sobre las propiedades del sistema con precisión, pero a un nivel de abstracción convenientemente genérico. Algunas de esas propiedades podrían ser, por ejemplo, protocolos de interacción, anchos de banda y latencia, localización del almacenamiento, conformidad con estándares arquitectónicos y previsiones de evolución ulterior del sistema.

Además suministran construcciones para especificar abstracciones arquitectónicas y mecanismos para descomponer un sistema en componentes y conectores, especificando de qué manera estos elementos se combinan para formar configuraciones y definiendo familias de arquitecturas o estilos. Precisamente lo que necesita una arquitectura para tener éxito, y con ella el proyecto de software en sí, ya que un proyecto será bueno en la medida que lo sea su arquitectura.

Todos los ADL existentes tienen un objetivo específico por lo que cada uno tiene su importancia, uno de los que sobresale debido a su importancia es UniCon que se destaca por su capacidad de manejo de métodos de análisis de tiempo real a través de RMA (Rate Monotonic Analysis).

Conociendo la importancia de los ADL, se podría pensar que existe gran número de ellos, y que son utilizados para el modelado de toda arquitectura de software, sin embargo, contrario a lo que se piensa, no existen tantas herramientas de modelado de arquitectura, existen en el mundo alrededor de unos veinte ADL de primera magnitud y quizás una cifra mayor propuestos en ponencias pero que no han resistido el paso del tiempo o que no han encontrado su camino en el mercado.

En la práctica quienes no utilizan UML para diagramar la arquitectura, utilizan diagramas de cajas y líneas, a pesar de sus deficiencias, aunque esto no quiere decir que los ADL no se utilicen, ejemplo de ello es LILEANNA, un ADL (o más estrictamente un MIL) que se utilizó para producir software de navegación de helicópteros. También está MetaH un ADL que modela arquitecturas en los dominios de guía, navegación y control (GN&C) y en el diseño aeronáutico. Pero son muy pocos los que se han utilizado en la práctica, por lo que es misión de este trabajo llevar a la práctica un ADL que supla las necesidades arquitectónicas del proyecto ERP Cuba.

Ejemplos de ADL

• Acme
• Aesop
• Darwin(ADL)
• UniCon
• Wright
• Rapide
• C2
• Jacal
• LEDA

Enlaces Externos

• http://www-2.cs.cmu.edu/afs/cs/project/able/www/able.html
• http://www-2.cs.cmu.edu/afs/cs/project/able/www/wright/index.html
• http://acme.able.cs.cmu.edu/acmeweb/.2009.
• http://acme.able.cs.cmu.edu/docs/language_overview.html
• http://www.dc.uba.ar/people/profesores/nicok/jacal.htm

Fuentes

• Elier Carmenate Valero y Yagnieris Montero Morales, "Selección de un Lenguaje de descripción Arquitectonica para el modelado arquitectónico del proyecto ERP Cuba". Trabajo de Diploma, Universidad de las Ciencias Informáticas(UCI), Junio de 2009.
• Aynur Abdurazik. “Suitability of the UML as an Architecture Description Language with Applications to testing”. Reporte ISE-TR-00-0, George Mason University. Febrero de 2000.
• Bradley Schmerl and David Garlan. AcmeStudio: Supporting Style-Centered Architecture Development (Research Demonstration) In Proceedings of the 26th International Conference on Software Engineering, Edinburgh, Scotland, 23-28 May 2004.
• Christine Hofmeister, Robert Nord y Dilip Soni. “Describing Software Architecture with UML” En Proceedings of the First Working IFIP Conference on Software Architecture, IEEE Computer Society Press, pp. 145-160, San Antonio. Febrero de 1999.
• David Luckham y James Vera. “An Event-Based Architecture Definition Language”. IEEE Transactions on Software Engineering, pp. 717-734, Setiembre de 1995.
• David Garlan. “Software architectures”. Presentación en transparencias, disponible en http://www.sti.uniurb.it/events/sfm03sa/slides/garlan-B.ppt.2000.
• David Garlan, William K. Reinholtz, Bradley Schmerl, Nicholas Sherman and Tony Tseng. Bridging the Gap between Systems Design and Space Systems Software. In Proceedings of the 29th Annual IEEE/NASA Software Engineering Workshop (SEW-29), Greenbelt, MD, 6-7 April 2005.
• David Garlan. Evolution Styles: Formal foundations and tool support for software architecture evolution. Technical report, CMU-CS-08-142, School of Computer Science, Carnegie Mellon University, June 2008.
• Jeff Magee y Jeff Kramer. “Dynamic structure in software architectures”. En Proceedings of the Fourth ACM SIGSOFT Symposium on the Foundations of Software Engineering, pp. 3–14, San Francisco, Octubre de 1996.
• Klaus-Dieter Schewe. “UML: A modern dinosaur? – A critical analysis of the Unified Modelling Language”. En H. Kangassalo, H. Jaakkola y E. Kawaguchi (eds.), Proceedings of the 10th European-Japanese. Conference on Information Modelling and Knowledge Bases, Saariselk, Finlandia, 2000.
• Luckham, D. C. et al. Specification and Analysis of System Architecture using Rapide. IEEE Trans. on Software Engineering, 21(4):336–355. 1995
• Magee, J., Kramer, J., y Giannakopoulou, D. Behaviour Analysis of Software Architectures. En Software Architecture, pp. 35–49. Kluwer Academic Publishers. 1999
• Martin Glinz. “Problems and deficiencies of UML as a requirements specification language”. En Proceedings of the 10th International Workshop of Software Specification and Design (IWSSD-10), pp. 11-22, San Diego, noviembre de 2000.
• Mary Shaw y David Garlan. “Characteristics of Higher-Level Languages for Software Architecture”. Technical Report CMU-CS-94-210, Carnegie Mellon University, Diciembre de 1994.
• Mary Shaw, Robert DeLine, Daniel Klein, Theodore Ross, David Young y Gregory Zelesnik. “Abstractions for Software Architecture and Tools to Support Them”. IEEE Transactions on Software Engineering, pp. 314-335, Abril de 1995.
• Mary Shaw y David Garlan. “Formulations and Formalisms in Software Architecture”. Springer-Verlag, Lecture Notes in Computer Science, Volumen
• RAPIDE Design Team. RAPIDE 1.0 Pattern Language Reference Manual. Program Analysis and Verification Group, Computer Systems lab. Stanford University 1997 .
• Robert Allen. “A formal approach to Software Architecture”. Technical Report, CMU-CS-97-144, 1997.
• Shang-Wen Cheng, David Garlan, Bradley Schmerl and Vahe Poladian. Improving Architecture-Based Self-Adaption Through Resource Prediction. In Software Engineering for Self-Adaptive Systems, Chapter 15, LNCS, 2008. To Appear.