Lenguajes de Descripción Arquitectónica

Lenguajes de Descripción Arquitectónica Parte de la familia Lenguajes para la Ingenieria de Software y la Arquitectura de Software ADL Sistemas Operativos compatibles Windows, Linux y Unix

ADL . 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

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.

Principales Características de los ADL

• 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.

Elementos Arquitectónicos que Modelan los ADL

• 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.

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.

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.

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.