Lenguajes de Descripción de Arquitectura (ADL)

Lenguajes de Descripción de Arquitectura (ADL)

INTRODUCCIÓN

Una vez que el arquitecto de software, tras conocer el requerimiento, se decide a delinear su estrategia y a articular los patrones que se le ofrecen hoy en profusión, se supone que debería expresar las características de su sistema, o en otras palabras, modelarlo, aplicando una convención gráfica o algún lenguaje avanzado de alto nivel de abstracción. A esta altura del desarrollo de la arquitectura de software, podría pensarse que hay abundancia de herramientas de modelado que facilitan la especificación de desarrollos basados en principios arquitectónicos, que dichas herramientas han sido consensuadas y estandarizadas hace tiempo y que son de propósito general, adaptables a soluciones de cualquier mercado vertical y a cualquier estilo arquitectónico. La creencia generalizada sostendría que modelar arquitectónicamente un sistema se asemeja al trabajo de articular un modelo en ambientes ricos en prestaciones gráficas, como es el caso del modelado de tipo CASE o UML, y que el arquitecto puede analizar visualmente el sistema sin sufrir el aprendizaje de una sintaxis especializada. También podría pensarse que los instrumentos incluyen la posibilidad de diseñar modelos correspondientes a proyectos basados en tecnología de internet, Web services o soluciones de integración de plataformas heterogéneas, y que, una vez trazado el modelo, el siguiente paso en el ciclo de vida de la solución se produzca con naturalidad y esté servido por ténicas bien definidas. Como se verá en este documento, la situación es otra, dista de ser clara y es harto más compleja. No existe hasta hoy una definición consensuada y unívoca de ADL, pero comúnmente se acepta que un ADL debe proporcionar un modelo explícito de componentes, conectores y sus respectivas configuraciones. Se estima deseable, además, que un ADL suministre soporte de herramientas para el desarrollo de soluciones basadas en arquitectura y su posterior evolución.

La delimitación categórica de los ADLs es problemática. Ocasionalmente, otras notaciones y formalismos se utilizan como si fueran ADLs para la descripción de arquitecturas. Casos a cuento serían CHAM, UML y Z. Aunque se hará alguna referencia a ellos, cabe puntualizar que no son ADLs en sentido estricto y que, a pesar de los estereotipos históricos (sobre todo en el caso de UML), no se prestan a las mismas tareas que los lenguajes descriptivos de arquitectura, diseñados específicamente para esa finalidad. Aparte de CODE, que es claramente un lenguaje de programación, se excluirá aquí entonces toda referencia a Modechart y PSDL (lenguajes de especificación o prototipado de sistemas de tiempo real), LOTOS (un lenguaje de especificación formal, asociado a entornos de diseño como CADP), ROOM (un lenguaje de modelado de objetos de tiempo real), Demeter (una estrategia de diseño y programación orientada a objetos), Resolve (una técnica matemáticamente fundada para desarrollo de componentes re-utilizables), Larch y Z (lenguajes formales de especificación) por más que todos ellos hayan sido asimilados a ADLs por algunos autores en más de una ocasión. Se hará una excepción con UML, sin embargo. A pesar de no calificar en absoluto como ADL, se ha probado que UML puede utilizarse no tanto como un ADL por derecho propio, sino como metalenguaje para simular otros ADLs, y en particular C2 y Wright [RMR98].

 

CONCLUCIONES

·         Todos los datos son importantes hasta que se demuestre lo contrario.

·         Todo código es inseguro hasta que se demuestre lo contrario.

·         El diseño por contrato usa precondiciones, poscondiciones e invariantes para asegurar que los datos provistos (y el estado del programa como un todo) esta saneado. Esto permite al código documentar todas las hipótesis y hacerlo así seguro.

 

Criterios de definición de un ADL

Los ADLs 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 1992 o 1993, poco después de fundada la propia arquitectura de software como especialidad profesional. La definición más simple es la de Tracz [Wolf97] que define un ADL como una entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y restricciones (constraints). Una de las definiciones más tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe 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
– Composición automática de código aplicativo

Basándose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como requerimientos:

– Abstracción de componentes
– Abstracción de comunicación
– Integridad de comunicación (sólo los componentes que están conectados pueden comunicarse)
– Capacidad de modelar arquitecturas dinámicas
– Composición jerárquica
– Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas)

Tomando como parámetro de referencia a UniCon, Shaw y otros [SDK+95] alegan que un ADL debe exhibir:

– Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones
– Capacidad de modelar conectores con protocolos, aserción de propiedades e implementaciones
– Abstracción y encapsulamiento
– Tipos y verificación de tipos
– Capacidad para integrar herramientas de análisis

Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados explícitamente como entidades de primera clase (lo que dejaría al margen de la lista a dos de ellos al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de composición, abstracción, reusabilidad, configuración, heterogeneidad y análisis, lo que excluiría a todos los lenguajes convencionales de programación y a los MIL.

Componentes

Interfaz
Tipos
Semántica
Restricciones (constraints)
Evolución
Propiedades no funcionales

Conectores

Interfaz
Tipos
Semántica
Restricciones
Evolución
Propiedades no funcionales

Configuraciones arquitectónicas

Comprensibilidad
Composicionalidad
Heterogeneidad
Restricciones
Refinamiento y trazabilidad
Escalabilidad
Evolución
Dinamismo
Propiedades no funcionales

Soporte de herramientas

Especificación activa
Múltiples vistas
Análisis
Refinamiento
Generación de código
Dinamismo

Nótese, en todo caso, que no se trata tanto de aspectos definitorios del concepto de ADL, sino de criterios para la evaluación de los ADLs existentes, o sea de un marco de referencia para la clasificación y comparación de los ADLs. Definiciones:

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 ADLs 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), llamadas a procedimientos, broadcast de eventos, 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 ADLs 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.

Propiedades. Representan información semántica sobre un sistema más allá de su estructura. Distintos ADLs 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, el throughput 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.

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.

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.

Evolución. Los ADLs deberían soportar procesos de evolución permitiendo derivar subtipos a partir de los componentes e implementando refinamiento de sus rasgos. Sólo unos pocos lo hacen efectivamente, dependiendo para ello de lenguajes que ya no son los de diseño arquitectónico sino los de programación. 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.

 

ADLs y Patrones

A primera vista, daría la impresión que la estrategia arquitectónica de Microsoft reposa más en la idea de patrones y prácticas que en lenguajes de descripción de diseño; pero si se examina con más cuidado el concepto de patrones se verá que dichos lenguajes engranan clara y armónicamente en un mismo contexto global. El concepto de patrón fue acuñado por Christopher Alexander entre 1977 y 1979. De allí en más fue enriqueciéndose en una multitud de sentidos, abarcando un conjunto de prácticas para capturar y comunicar la experiencia de los diseñadores expertos, documentar best practices, establecer formas recurrentes de solución de problemas comunes, etcétera.

Las clasificaciones usuales en el campo de los patrones reconocen habitualmente que hay diferentes clases de ellos; por lo común se hace referencia a patrones de análisis, organizacionales, procedurales y de diseño. Esta última categoría tiene que ver con recurrencias específicas de diseño de software y sistemas, formas relativamente fijas de interacción entre componentes, y técnicas relacionadas con familias y estilos. En este sentido, es evidente que los ADLs denotan una clara relación con los patrones de diseño, de los que puede decirse que son una de las formas posibles de notación. Como en el caso de las heurísticas y recetas de Acme, muchas veces esos patrones son explícitos y el ADL opera como una forma regular para expresarlos en la descripción arquitectónica.

La correspondencia entre patrones, ADLs y estilos, sin embargo, no está establecida de una vez y para siempre porque no existe ni una taxonomía uniforme, ni una especificación unívoca que defina taxativamente cuántas clases de patrones y cuántos niveles existen en ingeniería, arquitectura y diseño de software desde que se concibe conceptualmente un sistema hasta que se lo programa. En la percepción de Jørgen Thelin, quien a su vez se funda en la nomenclatura y tipificación de Martin Fowler, por ejemplo, distintos niveles en los proyectos de desarrollo se vincularían con otras tantas clases de patrones: el diseño con patrones de código, el análisis con los patrones de modelos y los estilos arquitectónicos con los patrones de arquitectura [The03]. Pero aunque cada escuela y cada autor organizan la articulación del campo a su manera y se sirve de denominaciones idiosincráticas, sin duda es legítimo plantear una relación entre patrones y lenguajes de descripción de arquitectura y tratar de esclarecerla.

Los ADLs mantienen asimismo una frontera difusa con lo que desde Alexander en adelante se llamaron lenguajes de patrones, que se definen como sistemas de patrones organizados en una estructura o plantilla que orienta su aplicación [Ale79] [AIS+77]. Ambas ideas se consolidaron en una nutrida bibliografía, en la cual la obra de la llamada “Banda de los Cuatro” ha alcanzado una fama legendaria [Gof95]. En algunas contadas ocasiones, los lenguajes de patrones fueron reformulados como ADLs y también viceversa [Shaw96]. Recientemente se ha propuesto un nuevo estilo arquitectónico “de nueva generación”, ABAS (Attribute-Based Architectural Style) [KC99], que explícitamente se propone la convergencia entre la arquitectura de alto nivel expresada en los ADLs y en los estilos con el expertise, las best practices, los building blocks y los patrones decantados en la disciplina de diseño de aplicaciones. Un estudio esencial de Mary Shaw y Paul Clements analiza la compleja influencia de la teoría y la práctica de los patrones sobre los ADLs [SC96]. Estos autores consideran que los ADLs han sido propios de la comunidad de arquitectos de software, mientras que los patrones de diseño y sus respectivos lenguajes han prosperado entre los diseñadores de software, particularmente entre los grupos más ligados a la orientación a objetos. Naturalmente, ambas comunidades se superponen en más de un respecto. En lo que respecta a la relación entre arquitectura y diseño, las discusiones mantenidas en el seno de OOSPLA y en otros foros han consensuado que los diseñadores basados en patrones operan a niveles de abstracción más bajo que el de los arquitectos, pero por encima del propio de los programadores. Por otra parte, Buschmann [BMR+96] ha documentado patrones utilizados como estilos arquitectónicos regidos por ADLs. Shaw y Clements concluyen su análisis alegando que los

ADLs pueden beneficiarse incorporando elementos de tipo análogo a los patrones en las secciones que se refieren a estilos, plantillas y reglas de diseño. A similares conclusiones llegan Robert T. Monroe, Drew Kompanek, Ralph Melton y David Garlan [MKM+96].

Al lado de los ADLs, existen otros recursos para abordar la cuestión de los patrones de diseño. La estrategia arquitectónica de Microsoft contempla niveles de abstracción que hoy en día se resuelven, por ejemplo, mediante Logidex para .Net de LogicLibrary, el cual se encuentra en http://www.logiclibrary.com/logidex.htm. Este es un engine que tipifica más como un software development asset (SDA) que como una entidad semejante a un ADL. Un asset de este tipo incluye componentes, servicios, frameworks, artefactos asociados con el ciclo de vida de un desarrollo de software, patrones de diseño y documentación de best practices. Este paquete en particular es más un producto para desarrolladores arquitectónicamente orientados que para arquitectos que prefieran situarse en una tesitura más abstracta y alejada del código. En futuras versiones de VisualStudio .Net se prevé la incorporación de otros recursos, algunos de ellos construidos en torno de la edición Architect y otros desarrollados por terceras partes. Los ADLs complementan a estos assets y herramientas, lo mismo que lo seguirán haciendo las soluciones de modelado relacionadas con la tradición de UML.

Conclusiones

son muy pocos quienes han oído hablar de estos tópicos, y muchos menos aún quienes poseen alguna experiencia de modelado genuinamente arquitectónico. Por lo general tiende a confundirse este modelado abstracto con el diseño concreto de la solución a través de UML, o con la articulación de patrones. Este es un claro indicador del hecho de que la arquitectura de software no ha sabido comunicar su propia función mediadora entre el requerimiento por un lado y el diseño y la implementación por el otro. El presente estudio ha procurado describir herramientas disponibles para el desempeño de esa función. La idea no ha sido examinar productos concretos de modelado con ADL, sino referir problemáticas formales involucradas en esa clase de representación.

De más está decir que los ADLs son convenientes pero no han demostrado aún ser imprescindibles. Numerosas piezas de software, desde sistemas operativos a aplicaciones de misión crítica, se realizaron echando mano de recursos de diseño ad hoc, o de formalismos incapaces de soportar un round trip evolutivo, expresar un estilo, implementar patrones o generar código. Aunque algunos se perdieron en el camino o quedaron limitados a experiencias en dominios específicos, y aunque en la era de las arquitecturas orientadas a servicios se encuentran en estado de fluidez y transición, los ADLs, nacidos hace más de una década, han llegado para quedarse. La demanda que los ha generado se ha instalado como un tópico permanente de la arquitectura de software, y por eso nos ha parecido útil elaborar este examen.

 

BIBLIOGRAFÍA

http://www.microsoft.com/spanish/msdn/arquitectura/roadmap_arq/lenguaje.mspx

 

 

 

About omaracostacasas

ING SOFTWARE
This entry was posted in Ingenieria de Software. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s