Lenguajes de Descripción Arquitectónica - Historial de revisiones

Javiermartin jc: Texto reemplazado: «
» por «»

2019-07-06T16:27:17Z

Texto reemplazado: «<div align="justify">» por «»

Cinformpri jc en 14:52 11 oct 2011

2011-10-11T14:52:51Z

Elierjccrdenas3 en 15:48 2 jul 2011

2011-07-02T15:48:56Z

Mostrar los cambios

Enrryjccmg: /* Surgimiento */

2011-06-28T13:58:41Z

‎Surgimiento

Arian.Perez jc en 17:13 30 may 2011

2011-05-30T17:13:25Z

Candelaria2 jc en 14:43 16 may 2011

2011-05-16T14:43:58Z

Elierjccrdenas3 en 15:05 13 may 2011

2011-05-13T15:05:04Z

Elierjccrdenas3 en 18:19 12 may 2011

2011-05-12T18:19:27Z

Elierjccrdenas3 en 18:17 12 may 2011

2011-05-12T18:17:56Z

Elierjccrdenas3 en 18:02 12 may 2011

2011-05-12T18:02:21Z

@@ Línea 22: / Línea 22: @@
 |web=
 }}
-<div align="justify">
 '''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.

@@ Línea 21: / Línea 21: @@
 |premios=
 |web=
-}}'''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.
@@ Línea 42: / Línea 42: @@
 *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.
@@ Línea 72: / Línea 69: @@
 *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.
@@ Línea 82: / Línea 77: @@
 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==
@@ Línea 96: / Línea 90: @@
 *[[LEDA]]
-==Enlaces Externos ==
+==Enlaces externos ==
 * http://www-2.cs.cmu.edu/afs/cs/project/able/www/able.html
@@ Línea 103: / Línea 97: @@
 * http://acme.able.cs.cmu.edu/docs/language_overview.html
 * http://www.dc.uba.ar/people/profesores/nicok/jacal.htm
 == Fuentes ==

@@ Línea 13: / Línea 13: @@
 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.
+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|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.

← Revisión anterior		Revisión del 17:13 30 may 2011
Línea 1:		Línea 1:
−	{{~~Mejorar~~}}	+	{{Normalizar}}

	'''Lenguajes de Descripción Arquitectónica'''		'''Lenguajes de Descripción Arquitectónica'''

← Revisión anterior		Revisión del 14:43 16 may 2011
Línea 1:		Línea 1:
−	~~<div align="justify">~~	+	{{Mejorar}}

	'''Lenguajes de Descripción Arquitectónica'''		'''Lenguajes de Descripción Arquitectónica'''

@@ Línea 1: / Línea 1: @@
 <div align="justify">
-{{Definición
-|nombre=Lenguajes de Descripción Arquitectónica
+'''Lenguajes de Descripción Arquitectónica'''
-|concepto= 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.
+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.
 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, Abstracción, mediante la cual 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, y por último Análisis. Permiten diversas formas de análisis de la arquitectura y de los sistemas desarrollados a partir de ella.
+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.
 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:
@@ Línea 34: / Línea 56: @@
 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.
@@ Línea 61: / Línea 87: @@
 == 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.

@@ Línea 66: / Línea 66: @@
 * 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. “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.

@@ Línea 14: / Línea 14: @@
 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, Abstracción, mediante la cual 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, y por último 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:
-*[[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.
+*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.
-*[[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.
+*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.
 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.
-Para que un lenguaje se considere ADL debe cumplir con otros aspectos los cuales se expresan a continuación:
+*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.
-*[[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.
-*[[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.
-*[[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.
-*[[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.
-*[[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.
@@ Línea 39: / Línea 38: @@
 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.
 ==Enlaces Externos ==
@@ Línea 46: / Línea 57: @@
 * 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