Modulo II ADLs
ADLs
Surgimiento de los ADLs.(Lenguajes De Descripción De Arquitectura). 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.
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.
Lenguajes descriptivos 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. 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. Los ADLs se utilizan, además, para satisfacer requerimientos descriptivos de alto nivel de abstracción que las herramientas basadas en objeto en general y UML en particular no cumplen satisfactoriamente.
Entre las comunidades consagradas al modelado OO y la que patrocina o frecuenta los ADLs (así como entre las que se inclinan por el concepto de estilos arquitectónicos y las que se trabajan en función de patrones) existen relaciones complejas que algunas veces son de complementariedad y otras de antagonismo.
Los ADL que existen actualmente en la industria rondan la cifra de veinticinco; cuatro o cinco de ellos han experimentado dificultades en su desarrollo o no se han impuesto en el mercado de las herramientas de arquitectura.
Todos ellos oscilan entre constituirse como ambientes altamente intuitivos con eventuales interfaces gráficas o presentarse como sistemas rigurosamente formales con profusión de notación simbólica, en la que cada entidad responde a algún teorema.
Alrededor de algunos ADLs se ha establecido una constelación de herramientas de análisis, verificadores de modelos, aplicaciones de generación de código, pársecs, soportes de runtime, etcétera. El campo es complejo, y de la decisión que se tome puede depender el éxito o el fracaso de un proyecto.
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 5 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
Los ADL que existen actualmente en la industria rondan la cifra de veinticinco; cuatro o cinco de ellos han experimentado dificultades en su desarrollo o no se han impuesto en el mercado de las herramientas de arquitectura.
Todos ellos oscilan entre constituirse como ambientes altamente intuitivos con eventuales interfaces gráficas o presentarse como sistemas rigurosamente formales con profusión de notación simbólica, en la que cada entidad responde a algún teorema.
Alrededor de algunos ADLs se ha establecido una constelación de herramientas de análisis, verificadores de modelos, aplicaciones de generación de código, pársecs, soportes de runtime, etcétera. El campo es complejo, y de la decisión que se tome puede depender el éxito o el fracaso de un proyecto.
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 5 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
Principales características de los ADLs.
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: Puespermiten 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.
Criterios de definición de un ADL.
Vestal 1993, 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.
-Soporte de herramientas para modelado, análisis, evaluación y verificación.
-Composición automática de código aplicativo.
-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 alegan que un ADL debe exhibir:
-Abstracción y encapsulamiento.
- Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones.
-Tipos y verificación de tipos.
Capacidad de modelar conectores con protocolos, aserción de propiedades e implementaciones.
-Capacidad para integrar herramientas de análisis .
Interfaces:
Todos los ADLs conocidos soportan la especificación de interfaces para sus componentes. En Acme cada componente puede tener múltiples interfaces. Igual que en Aesop y Wright los puntos de interfaz se llaman puertos (ports). Los puertos pueden definir interfaces tanto simples como complejas, desde una signatura de procedimiento hasta una colección de rutinas a ser invocadas en cierto orden, o un evento de multicast.
Semántica:
Muchos lenguajes de tipo ADL no modelan la semántica de los componentes más allá de sus interfaces. En este sentido, Acme sólo soporta cierta clase de información semántica en listas de propiedades. Estas propiedades no se interpretan, y sólo existen a efectos de documentación.
Estilos:
Acme posee manejo intensivo de familias o estilos. Esta capacidad está construida naturalmente como una jerarquía de propiedades correspondientes a tipos. Acme considera, en efecto, tres clase de tipos: tipos de propiedades, tipos estructurales y estilos. Así como los tipos estructurales representan conjuntos de elementos estructurales, una familia o estilo representa un conjunto de sistemas. Una familia Acme se define especificando tres elementos de juicio: un conjunto de tipos de propiedades y tipos estructurales, un conjunto de restricciones y una estructura por defecto, que prescribe el conjunto mínimo de instancias que debe aparecer en cualquier sistema de la familia. El uso del término “familia” con preferencia a “estilo” recupera una idea de uno de los precursores tempranos de la arquitectura de software, David Parnas.
- Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones.
-Tipos y verificación de tipos.
Capacidad de modelar conectores con protocolos, aserción de propiedades e implementaciones.
-Capacidad para integrar herramientas de análisis .
Elementos De Lenguajes De Descripción De Arquitectura ADLs
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.
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.
Conectores.
Representan interacciones entre componentes. Corresponden a las líneasde 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 participantesen la interacción.
Propiedades:
Representan información semántica sobre un sistema más allá de suestructura. Distintos ADLs ponen énfasis en diferentes clases de propiedades, perotodos tienen alguna forma de definir propiedades no funcionales, o pueden admitirherramientas 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 restriccionesen los valores posibles de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de clientes que se puede conectarsimultáneamente a un servicio.
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 yano son los de diseño arquitectónico sino los de programación.
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.
Propiedades no funcionales: La especificación de estas propiedades es necesaria para simular la conducta de runtime, analizar la conducta de los componentes, imponerrestricciones, mapear implementaciones sobre procesadores determinados, etc.
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.
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.
Conectores.
Representan interacciones entre componentes. Corresponden a las líneasde 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 participantesen la interacción.
Propiedades:
Representan información semántica sobre un sistema más allá de suestructura. Distintos ADLs ponen énfasis en diferentes clases de propiedades, perotodos tienen alguna forma de definir propiedades no funcionales, o pueden admitirherramientas 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 restriccionesen los valores posibles de propiedades o en las configuraciones topológicas admisibles. Por ejemplo, el número de clientes que se puede conectarsimultáneamente a un servicio.
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 yano son los de diseño arquitectónico sino los de programación.
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.
Propiedades no funcionales: La especificación de estas propiedades es necesaria para simular la conducta de runtime, analizar la conducta de los componentes, imponerrestricciones, mapear implementaciones sobre procesadores determinados, etc.
Acme-Armani
Acme: Se define como una herramienta capaz de soportar el mapeo de especificaciones arquitectónicas entre diferentes ADLs, o en otras palabras, como un lenguaje de intercambio de arquitectura. No es entonces un ADL en sentido estricto, aunque la literatura de referencia acostumbra tratarlo como tal. De hecho, posee numerosas prestaciones que también son propias de los ADLs. En su sitio oficial se reconoce que como ADL no es necesariamente apto para cualquier clase de sistemas, al mismo tiempo que se destaca su capacidad de describir con facilidad sistemas “relativamente simples”.
Armani: Se constituyó en un lenguaje de tipo ADL, especializado en la descripción de la estructura de un sistema y su evolución en el tiempo. Es un lenguaje puramente declarativo que describe la estructura del sistema y las restricciones a respetar, pero no hace referencia alguna a la generación del sistema o a la verificación de sus propiedades no funcionales o de consistencia. De alguna manera, la naturaleza de Armani captura también el expertise de los diseñadores, señalando su vinculación con la práctica de los patrones arquitectónicos, en este caso patrones de diseño. Armani se basa en siete entidades para describir las instancias del diseño: componentes, conectores, puertos, roles, sistemas, representaciones y propiedades. Para capturar las experiencias y tipos de elementos de diseño, tipos de propiedades, invariantes de diseño, heurísticas, análisis y estilos arquitectónicos. La sección denotacional de Armani tiene un aire de familia con la sintaxis de cláusulas de Horn en lenguaje Prolog
ACME
Características:
Define 4 tipos dentro de la arquitectura y 7 elementos fundamentales.
Tipos
Acme: Se define como una herramienta capaz de soportar el mapeo de especificaciones arquitectónicas entre diferentes ADLs, o en otras palabras, como un lenguaje de intercambio de arquitectura. No es entonces un ADL en sentido estricto, aunque la literatura de referencia acostumbra tratarlo como tal. De hecho, posee numerosas prestaciones que también son propias de los ADLs. En su sitio oficial se reconoce que como ADL no es necesariamente apto para cualquier clase de sistemas, al mismo tiempo que se destaca su capacidad de describir con facilidad sistemas “relativamente simples”.
Armani: Se constituyó en un lenguaje de tipo ADL, especializado en la descripción de la estructura de un sistema y su evolución en el tiempo. Es un lenguaje puramente declarativo que describe la estructura del sistema y las restricciones a respetar, pero no hace referencia alguna a la generación del sistema o a la verificación de sus propiedades no funcionales o de consistencia. De alguna manera, la naturaleza de Armani captura también el expertise de los diseñadores, señalando su vinculación con la práctica de los patrones arquitectónicos, en este caso patrones de diseño. Armani se basa en siete entidades para describir las instancias del diseño: componentes, conectores, puertos, roles, sistemas, representaciones y propiedades. Para capturar las experiencias y tipos de elementos de diseño, tipos de propiedades, invariantes de diseño, heurísticas, análisis y estilos arquitectónicos. La sección denotacional de Armani tiene un aire de familia con la sintaxis de cláusulas de Horn en lenguaje Prolog
ACME
Características:
- Es útil por su capacidad de soportar el mapeo de especificaciones arquitectónicas entre diferentes ADLs.
- Orientado como un ADL que no es necesariamente apto para cualquier clase de sistemas
- Es reconocido por su facilidad para describir con facilidad sistemas relativamente simples.
Define 4 tipos dentro de la arquitectura y 7 elementos fundamentales.
Tipos
- La estructura: Organización de un sistema en sus partes constituyentes.
- Las propiedades de interés: información que permite razonar sobre el comportamiento local o global, tanto funcional como no funcional
- Las restricciones: lineamientos sobre la posibilidad del cambio en el tiempo.
- Los tipos y estilos.
- Componentes
- Conectores
- SistemasPuertos
- Roles
- Representaciones
- Mapas de representación.
Conectores:
Representan elementos computacionales y almacenamientos de un sistema.
Por ejemplos:
- Acme modela sus conectores como entidades de primera clase los cuales representan interacciones entre componentes.
- Los conectores también tienen interfaces que están definidas por un conjunto de roles.
- Los conectores binarios son los más sencillos.
- El invocador y el invocado de un conector RPC.
- La lectura y la escritura de un conector de tubería
- El remitente y el receptor de un conector de paso de mensajes.
Representan elementos computacionales y almacenamientos de un sistema.
Por ejemplos:
- Servidor de aplicaciones
- Base de datos relacional
- Un componente se define siempre dentro de una familia de componentes.
Interfaces:
Todos los ADLs conocidos soportan la especificación de interfaces para sus componentes. En Acme cada componente puede tener múltiples interfaces. Igual que en Aesop y Wright los puntos de interfaz se llaman puertos (ports). Los puertos pueden definir interfaces tanto simples como complejas, desde una signatura de procedimiento hasta una colección de rutinas a ser invocadas en cierto orden, o un evento de multicast.
Semántica:
Muchos lenguajes de tipo ADL no modelan la semántica de los componentes más allá de sus interfaces. En este sentido, Acme sólo soporta cierta clase de información semántica en listas de propiedades. Estas propiedades no se interpretan, y sólo existen a efectos de documentación.
Estilos:
Acme posee manejo intensivo de familias o estilos. Esta capacidad está construida naturalmente como una jerarquía de propiedades correspondientes a tipos. Acme considera, en efecto, tres clase de tipos: tipos de propiedades, tipos estructurales y estilos. Así como los tipos estructurales representan conjuntos de elementos estructurales, una familia o estilo representa un conjunto de sistemas. Una familia Acme se define especificando tres elementos de juicio: un conjunto de tipos de propiedades y tipos estructurales, un conjunto de restricciones y una estructura por defecto, que prescribe el conjunto mínimo de instancias que debe aparecer en cualquier sistema de la familia. El uso del término “familia” con preferencia a “estilo” recupera una idea de uno de los precursores tempranos de la arquitectura de software, David Parnas.
Aesop
Es una herramienta para construir ambientes de diseño de software basada en principios de arquitectura”. El ambiente de desarrollo de AesopSystem se basa en el estilo de tubería y filtros propio de UNIX.El nombre oficial es Aesop Software Architecture Design Environment Generator. Se ha desarrollado como parte del proyecto ABLE de la Universidad Carnegie Mellon, cuyo objetivo es la exploración de las bases formales de la arquitectura de software, el desarrollo del concepto de estilo arquitectónico y la producción de herramientas útiles a la arquitectura, de las cuales Aesop es precisamente la más relevante.
Estilos
En Aesop, conforme a su naturaleza orientada a objetos, el vocabulario relativo a estilos arquitectónicos se describe mediante la definición de sub-tipos de los tipos arquitectónicos básicos: Componente, Conector, Puerto, Rol, Configuración y Binding.
Interfaces
En Aesop (igual que en ACME y Wright) los puntos de interfaz se llaman puertos (ports).
semántica
Aesop presupone que la semántica de una arquitectura puede ser arbitrariamente distinta para cada estilo. Por lo tanto, no incluye ningún soporte nativo para la descripción de la semántica de un estilo o configuración, sino que apenas presentaunos cuadros vacantes para colocar esa información como comentario. Soporte de lenguajes -Aesop (igual que Darwin) sólo soporta nativamente desarrollosrealizados en C++.
Es una herramienta para construir ambientes de diseño de software basada en principios de arquitectura”. El ambiente de desarrollo de AesopSystem se basa en el estilo de tubería y filtros propio de UNIX.El nombre oficial es Aesop Software Architecture Design Environment Generator. Se ha desarrollado como parte del proyecto ABLE de la Universidad Carnegie Mellon, cuyo objetivo es la exploración de las bases formales de la arquitectura de software, el desarrollo del concepto de estilo arquitectónico y la producción de herramientas útiles a la arquitectura, de las cuales Aesop es precisamente la más relevante.
Estilos
En Aesop, conforme a su naturaleza orientada a objetos, el vocabulario relativo a estilos arquitectónicos se describe mediante la definición de sub-tipos de los tipos arquitectónicos básicos: Componente, Conector, Puerto, Rol, Configuración y Binding.
Interfaces
En Aesop (igual que en ACME y Wright) los puntos de interfaz se llaman puertos (ports).
semántica
Aesop presupone que la semántica de una arquitectura puede ser arbitrariamente distinta para cada estilo. Por lo tanto, no incluye ningún soporte nativo para la descripción de la semántica de un estilo o configuración, sino que apenas presentaunos cuadros vacantes para colocar esa información como comentario. Soporte de lenguajes -Aesop (igual que Darwin) sólo soporta nativamente desarrollosrealizados en C++.
ArTek
ArTek fue desarrollado por Teknowledge. Se lo conoce también como ARDEC/Teknowledge Architecture Description Language. En opinión de Medvidovic no es un genuino ADL, por cuanto la configuración es modelada implícitamente mediante información de interconexión que se distribuye entre la definición de los componentes individuales y los conectores. En este sentido, aunque pueda no ser un ADL en sentido estricto, se le reconoce la capacidad de modelar ciertos aspectos de una arquitectura. De todas maneras, es reconocidamente un lenguaje específico de dominio y siempre fue presentado como un caso testigo de generación de un modelo a partir de una instancia particular de uso.
ArTek fue desarrollado por Teknowledge. Se lo conoce también como ARDEC/Teknowledge Architecture Description Language. En opinión de Medvidovic no es un genuino ADL, por cuanto la configuración es modelada implícitamente mediante información de interconexión que se distribuye entre la definición de los componentes individuales y los conectores. En este sentido, aunque pueda no ser un ADL en sentido estricto, se le reconoce la capacidad de modelar ciertos aspectos de una arquitectura. De todas maneras, es reconocidamente un lenguaje específico de dominio y siempre fue presentado como un caso testigo de generación de un modelo a partir de una instancia particular de uso.
Disponibilidad de plataforma.
Hoy en día ArTek no se encuentra disponible en ningúnsitio y para ninguna plataforma.
Hoy en día ArTek no se encuentra disponible en ningúnsitio y para ninguna plataforma.
ADML
ADML (Architecture Description Markup Language) constituye un intento de estandarizar la descripción de arquitecturas en base a XML. Está siendo promovido desde el año 2000 por The Open Group y fue desarrollado originalmente en MCC. The Open Group ha sido también promotor de The Open Group Architectural Framework (TOGAF). ADML agrega al mundo de los ADLs una forma de representación basada en estándares de la industria, de modo que ésta pueda ser leída por cualquier parser de XML. En ambientes Windows el parser primario y el serializador de XML se instala con Microsoft Internet Explorer de la versión 4 en adelante, y todas las aplicaciones de Office, así como SQL Server, poseen soporte nativo de XML y por lo tanto del lenguaje arquitectónico de markup. El Framework .NET de Microsoft incluye además clases (xmlreader, xmlwriter) que hacen que implementar tratamiento de documentos ADML, xADL, xArch y sus variantes resulte relativamente trivial. En consonancia con la expansión de Internet, ADML permite también definir vínculos con objetos externos a la arquitectura(fundamentación racional, diseños, componentes, etcétera), así como interactuar con diversos repositorios de industria, tales como las especificaciones de OASIS relativas a esquemas para SWIFT, IFX, OFX/OFE, BIPS, OTP, OMF, HL7, RosettaNet o similares.ADML constituye además un tronco del que depende una cantidad de especificaciones más puntuales. Mientras ADML todavía reposaba en DTD (Document Type Definition), una sintaxis de metadata que ahora se estima obsoleta, las especificaciones más nuevas implementan esquemas extensibles de XML. La más relevante tal vez sea xADL (a pronunciar como “zaydal”), desarrollado por la Universidad de California en Irvine, que define XML Schemas para la descripción de familias arquitectónicas, o sea estilos.
ADML (Architecture Description Markup Language) constituye un intento de estandarizar la descripción de arquitecturas en base a XML. Está siendo promovido desde el año 2000 por The Open Group y fue desarrollado originalmente en MCC. The Open Group ha sido también promotor de The Open Group Architectural Framework (TOGAF). ADML agrega al mundo de los ADLs una forma de representación basada en estándares de la industria, de modo que ésta pueda ser leída por cualquier parser de XML. En ambientes Windows el parser primario y el serializador de XML se instala con Microsoft Internet Explorer de la versión 4 en adelante, y todas las aplicaciones de Office, así como SQL Server, poseen soporte nativo de XML y por lo tanto del lenguaje arquitectónico de markup. El Framework .NET de Microsoft incluye además clases (xmlreader, xmlwriter) que hacen que implementar tratamiento de documentos ADML, xADL, xArch y sus variantes resulte relativamente trivial. En consonancia con la expansión de Internet, ADML permite también definir vínculos con objetos externos a la arquitectura(fundamentación racional, diseños, componentes, etcétera), así como interactuar con diversos repositorios de industria, tales como las especificaciones de OASIS relativas a esquemas para SWIFT, IFX, OFX/OFE, BIPS, OTP, OMF, HL7, RosettaNet o similares.ADML constituye además un tronco del que depende una cantidad de especificaciones más puntuales. Mientras ADML todavía reposaba en DTD (Document Type Definition), una sintaxis de metadata que ahora se estima obsoleta, las especificaciones más nuevas implementan esquemas extensibles de XML. La más relevante tal vez sea xADL (a pronunciar como “zaydal”), desarrollado por la Universidad de California en Irvine, que define XML Schemas para la descripción de familias arquitectónicas, o sea estilos.
Comentarios
Publicar un comentario