MDE; MDA; Transformaciones y DSLs. Una breve introducci on.

Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth Escuela de ingenier a, Departamento de Inform atica y Sistemas, Maestr a en Ingenier a, Universidad EAFIT-Medell n, Colombia. Programa de Ingenier a de Sistemas y Computaci on, Facultad de Ingenier a, Grupo SINFOCI, Universidad del Quind o, Armenia, Colombia. Marzo 2013

Resumen
Con el avance de la investigaci on acad emica y cient ca se han impulsado diferentes t ecnicas y estrategias en el desarrollo de software. En la d ecada m as reciente se ha incrementado el uso y la aplicaci on del desarrollo de software dirigido por modelos, y a partir de este enfoque se han derivado muchas otras corrientes/vertientes del uso y aplicaci on de los modelos. En este art culo se realiza una breve aproximaci on al enfoque del desarrollo dirigido por modelos, su cobertura, la clasicaci on de las transformaciones para convertir esos modelos en algo f sico (y no et ereo) y la manera c omo esos modelos pueden aportar a la construcci on de un lenguaje de prop osito espec co. Palabras Clave: MDE; MDA; DSL; transformaciones; modelo; metamodelo; CIM (Modelo Independiente de la Computaci on); PIM (Modelo Independiente de Plataforma); PSM (Modelo de Plataforma Espec ca); PIT (Transformaciones Independientes de Plataforma); PST (Transformaciones de Plataforma Espec ca); dominio.

1.

Introducci on

inicial requerido para abordar una soluci on de caracter inform atico. De manera que, obteniendo una abstracci on inicial y plante andola mediante un esquema de modelos se puede conseguir el m aximo del entendimiento del problema (conocimiento del dominio); y as , de la mano de expertos del dominio, analistas de negocio y de sistemas, elicitadores de requisitos, arquitectos de software, dise nadores e implementadores, obtener una soluci on satisfactoria con un esfuerzo reducido, con participaci on independiente de cada uno de los roles y asegurando cumplir con la construcci on de la soluci on planteada a trav es de la abstracci on inicial. En este art culo se presenta una breve introducci on al modelado bajo el contexto de la corriente MDE (secciones 2 y 3); y como los modelos por s solos solo aportan el entendimiento entre las partes y el planteamiento de una soluci on, tambi en se abordan, en este art culo, las coberturas de los modelos para apoyar el proceso de desarrollo de software (secci on 4). En la secci on 5 se presenta una introducci on a las transformaciones (enfoques) de los modelos y la secci on 6 aborda el tema y las caracter sticas de un lenguaje de dominio espec co para tratar la sem antica y sintaxis de los modelos declarados en una soluci on. Finalmente, se presentan las conclusiones de este art culo (secci on 7).

La tendencia actual del desarrollo de software se ha visto impulsada por el uso de modelos y de las abstracciones de los escenarios, en organizaciones y 2. Denici on de MDE situaciones, para obtener de ellos sistemas y aplicativos El modelo constituye la base fundamental de informainform aticos a la medida. Es en este aspecto, en el on sobre la que interact uan los expertos en el domidel modelado, en el que debe concentrarse el esfuerzo ci 1

3 nio del problema y los desarrolladores de software. Por lo tanto es de fundamental importancia que exprese la esencia del problema en forma clara y precisa [16]. En [12] se arma que si se trabaja con modelos, se pueden obtener importantes benecios tanto en la productividad (prestando mayor atenci on, por parte de los desarrolladores, a la soluci on del problema a partir del dominio y no tanto en los detalles t ecnicos), como en la portabilidad (dependiendo de las herramientas de transformaci on usadas) independencia de la plataforma de sistema de software, en la interoperabilidad (haciendo referencia a los brigdes puentes mapeo de elementos entre distintas plataformas y a la independencia de los fabricantes), en el mantenimiento y la documentaci on (esta se mantiene a un alto nivel de abstracci on partiendo desde los modelos conceptual e independiente de plataforma). El marco MDE (ModelDriven Engineering) ayuda a descubrir los elementos de un sistema a partir de la creaci on de modelos enfocados sobre los conceptos de dominio y no tanto sobre los conceptos de inform atica. Uno de los objetivos de MDE es especicar y explicitar los t erminos del negocio en modelos durante todo el proceso de desarrollo de software. A partir de este objetivo, este enfoque est a centrado en el desarrollo de un PIM (Modelo de Plataforma Independiente PIM por sus siglas en ingl es), propiciando que los desarrolladores se enfoquen solo en modelos sin considerar aspectos de implementaci on. Se pueden trabajar independientemente los detalles de las plataformas espec cas. Esto hace que el sistema desarrollado se acerque m as a las necesidades del usuario nal, el cual tendr a mayor funcionalidad en un menor tiempo. Realizar modicaciones sobre los modelos ser a mucho m as r apido y seguro que hacerlo sobre el c odigo nal. MDE, (Model Driven Engineering) es una aproximaci on de desarrollo de software centrado en la generaci on de modelos para describir los elementos de un sistema [23]. MDE es la sigla que se usa en el ambito acad emico investigativo y no ha sido registrada bajo la batuta del Object Group Management (OMG)[18]. Esta sigla, MDE, es usada actualmente por la comunidad investigadora internacional cuando se reeren a ideas relacionadas con la ingenier a de modelos sin centrarse exclusivamente en los est andares y planteamientos de Object Management Group.

PROPUESTA MDA

3.

Propuesta MDA

MDA Model-Driven Architecture es un concepto promovido por OMG (Object Management Group) [17] cuyo prop osito es afrontar el desaf o de la integraci on de aplicaciones y cambios tecnol ogicos. El objetivo de MDA es separar el dise no del sistema tanto de la arquitectura como de las tecnolog as de construcci on facilitando que, dise no y arquitectura, puedan modicarse independientemente. MDA es una arquitectura que proporciona un conjunto de gu as para estructurar especicaciones expresadas como modelos. MDA se enfoca en tres principios: 1. Representaci on directa, centr andose en las ideas y conceptos del dominio del problema y disminuyendo la distancia entre la sem antica del dominio y su representaci on aplicando principios de abstracci on; separando aspectos relevantes del dominio del problema de las decisiones de tecnolog a; 2. Automatizaci on, promoviendo el uso de funcionalidades como el intercambio de modelos, el manejo de metamodelos, la vericaci on de la consistencia y la transformaci on de modelos; y 3. El uso de est andares abiertos, cuyo prop osito es lograr la interoperabilidad de las diversas herramientas y plataformas apoyando al desarrollo de herramientas robustas, como por ejemplo, UML expresado en XML que resulta u til como mecanismo de transformaci on de modelos como, por ejemplo, la tecnolog a XSLT (Extensible Style Language Transformation). Por ser MDD (Model Driven Development) una marca registrada de OMG, la comunidad cient ca utiliza el t ermino MDE para referirse a ideas y conceptos relacionados con la ingenier a basada en modelos, sin centrarse, exclusivamente, en los est andares de OMG. En denitiva, MDD signica lo mismo que MDE, s olo que MDD es una marca registrada, mientras que MDE no. Si habl aramos de medicamentos, MDE ser a el nombre gen erico del medicamento, mientras que MDD ser a una marca comercial, cuyo componente principal es el medicamento MDE [3]. 2

Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth

4.3

4.

Proceso expl cito de Validaci on y Vericaci on (V&V) en 4 MDA COBERTURA DE MODELOS CON MDA Cobertura de Modelos con de dominio que es una de las principales ventajas extra das de MDA. La transformaci on de modelos, con las MDA notaciones PIT y PST, se centra en dos pasos espec cos: 1. Expresar las transformaciones de modelos de una manera independiente de la plataforma; 2. Mapear esta expresi on de la herramienta independiente en una herramienta real (lo que conlleva a la herramienta o tecnolog a espec ca de las expresiones de transformaci on de modelos) Las transformaciones de PIT a PST, visualmente podr an presentarse seg un la gura 1

En [22] se plantean dicultades cotidianas a la hora de utilizar los conceptos de MDA, que pueden hacerse presentes en todas las fases del ciclo de desarrollo, cit andolos: Los modelos se usan solo como documentaci on. Existen vac os entre el modelo y su implementaci on como sistemas resultantes. No hay una mezcla adecuada de modelos. Modelos desconectados y vistas desconectadas de un sistema. No hay transformaci on de modelos. Para mitigar estos problemas en [13] se presenta una cobertura de modelos de MDA que apoyan, desde diversas perspectivas, el proceso de desarrollo de software:

4.1.

Separaci on de Aspectos

[1]. Es una aproximaci on basada en m ultiples vistas. La capacidad de integrar t ecnicas de m ultiples perspectivas como CIM; PIM; PSM. Por ejemplo, para el modelo independiente de la computaci on (CIM), es posible modelar la l ogica del negocio y los requisitos, por los stakeholders (teniendo en cuenta que cada participante trata sus asuntos con su propia apreciaci oninterpretaci on), cada uno desde sus propias perspectivas, proporcionando un modelo separado del sistema m as preciso y claro. Estos puntos de vista son el origen de los asuntos que se modelar an en el Modelo Independiente de la Plataforma (PIM) y en el Modelo de Plataforma Espec ca (PSM). La tendencia de programaci on sobre esta separaci on de aspectos es el enfoque Programaci on Orientada a Aspectos (POA).

Figura 1: Tomado de [4] La primera dimensi on, el eje horizontal, es la usual disposici on de las capas de los modelos de aplicaci on PIM a PSM (de modelo independiente de plataforma a modelo espec co de plataforma) transformaciones de modelos aplicadas en los sucesivos PIM a modelos PSM; en la segunda dimensi on, eje vertical, se presentan las expresiones de transformaci on de modelos a nivel PIT y PST. El proceso de transformaci on de modelos, bajo la ingenier a dirigida por modelos reexivos puede representarse de la siguiente manera: (ver gura 2) La ingenier a dirigida por modelos reexivos se basa en el enfoque Orientado a Objetos y su metamodelo es centrado en UML para denir lenguajes de transformaci on de tipo PIT y PST.

4.2.

Ingenier a dirigida por modelos reexivos

[4]. En la que se aplican las nociones de PIT (transformaciones independientes de plataforma) y PST (transfor- 4.3. Proceso expl cito de Validaci on y maciones de plataforma espec ca). Es importante menVericaci on (V&V) en MDA cionar que las transformaciones de modelos a partir de [14]. Es la propuesta de un proceso gen erico para ser modelos de dominio en modelos de plataforma si son desarrollados en un lenguaje propietario o inestable, pue- usado en MDA para detectar errores e inconsistencias en den perder la capacidad de reutilizaci on de los modelos etapas tempranas del desarrollo, evitando la propagaci on Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth 3

4.4

Desarrollo incremental consistente integrando MDA y Orientaci 4 COBERTURA on a Aspectos DE MODELOS CON MDA En la implementaci on del metamodelo se usan los modelos concretos que denen el sistema en las actividades de validaci on y vericaci on. La realizaci on de esta transformaci on es un metamodelo distinto usado en el PIM origen. El PIMR (resultante) de esta transformaci on es un metamodelo utilizable para realizar las actividades de vericaci on y validaci on. Implementaci on de las propiedades.

Figura 2: Ciclo de Vida del modelo de Transformaci on. Tomado de [4] de estos errores hasta etapas posteriores. Un error en el PIM se arrastra hasta el PSM hasta llegar al c odigo. Si en la etapa de modelado independiente de la plataforma se construyen modelos incompletos, imprecisos o inconsistentes se produce una propagaci on de estos errores al resto de las etapas. La vericaci on intenta mostrar que un modelo satisface una propiedad espec ca. Esta vericaci on puede llevarse formal o informalmente. Las t ecnicas de la vericaci on formal son la demostraci on de teoremas y el model checking. Los algoritmos y el checklist son t ecnicas de la vericaci on informal. La validaci on eval ua si el comportamiento observable del modelo se ajusta a los requisitos. Si los modelos est an basados en UML esta validaci on se realiza por medio de simulaci on de escenarios y casos de uso. Etapas del proceso de vericaci on y validaci on: 1. 2.

4.4.

Desarrollo incremental consistente integrando MDA y Orientaci on a Aspectos

3. 4. 5.

[2]. Entre cada nivel de abstracci on se hallan las transformaciones, otro de los mecanismos claves de MDA y MDD, cuyo prop osito es establecer reglas de transformaci on entre elementos de un modelo de abstracci on fuente hacia otro m as renado o m as abstracto [11]. Todo este proceso puede disminuir su esfuerzo en ciertos requisitos no funcionales, trazabilidad, mantenibilidad, escalabilidad (evoluci on), pues los modelos que especican el sistema se vuelven excesivamente grandes, complejos, provocando dicultad en el mantenimiento, en el reuso [2]. Adem as las transformaciones entre diferentes niveles de abstracci on se vuelven muy complejas, excesivamente grandes y poco reutilizables [5]. Esta propuesta (Desarrollo Incremental consistente integrando MDA y Orientaci on a Aspectos) es que dichos modelos, desde el CIM hasta el PSM, puedan ser desaIdenticar propiedades que deben cumplir los mode- rrollados por diferentes equipos de trabajo de forma descentralizada, concurrente y consistente con un m nimo los construidos. de comunicaci on entre ellos. Propiedades relacionadas con la sem antica est atica El desarrollo de software orientado a Aspectos (DSOA), de los modelos de acuerdo con las reglas de su me- supone un avance hacia la modularizaci on del software. tamodelo. Permite aislar propiedades del sistema cuya especicaci on queda dispersa por el sistema en artefactos (denoPropiedades relacionadas con la sem antica din amica minados aspectos). Aplicando t ecnicas de Separaci on de de los modelos. Aspectos a cada nivel de abstracci on se pueden obtener modelos mejor modularizados, como consecuencia, moPropiedades relacionadas con la consistencia dentro delos m as manejables, con mayor reuso, con mejor mande un modelo o entre modelos. tenibilidad [2]. Propiedades relacionadas con la sem antica concreta del dominio al que pertenecen los modelos. 4.5. Denici on y Descripci on de PIM

[7]. Trata la separaci on de aspectos y requerimientos 6. Especicaci on/implementaci on del metamodelo. Resultado: una representaci on del mismo en un deter- no funcionales; los aspectos de separaci on de plataforma independiente y plataforma espec ca. Indica las partes minado lenguaje. Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth 4

en las que se dene el PIM: contexto, requerimientos, an alisis, dise no del comportamiento.

4.5.3.

5 TRANSFORMACIONES El An alisis PIM

especica la vista interna del sistema usando una vista white box, sin ninguna consideraci on tecnol ogica o de 4.5.1. El contexto del PIM software y se sigue cumpliendo con el principio de sepaon de aspectos. Lo sostiene la especicaci on funcional es el modelo de presentaci on de la vista superior del raci areas de aplicaci on. sistema a desarrollar. Su prop osito es denir claramente del sistema, centrado en el dominio y El Modelo de An alisis se describe y se ve como el modelo el alcance del sistema a desarrollar. El contexto PIM: m as duradero. Est a libre de cualquier plataforma incluso de consideraciones de arquitectura f sica. 1. Introduce el sistema. El Modelo de An alisis incluye tres actividades: 2. Presenta sus objetivos (se tiene el alcance), 1. Mantener las interfaces externas. 3. se describen los principios de negocio que estructu2. Realizar el an alisis de Dominio. ran el sistema. 4. Describe a los actores externos que interact uan con el sistema. 3. Realizar el an alisis de calidad del servicio.

4.5.4. Dise no de Componentes PIM 5. Presenta los servicios de alto nivel requeridos para . Representa una plataforma independiente de la soluinteractuar con el sistema como los comportamienci on expresada en t erminos de componentes de software tos clave del sistema. (componente, interfase, puerto, conector). Esta soluci on 6. Y dene los objetos de negocio. (el c omo) cumple con los requisitos funcionales y no funcionales modelados en el Modelo de An alisis (el qu e) del sistema. 4.5.2. Los Requerimientos PIM El Dise no de Componentes PIM incluye cuatro actividaespecican la vista externa del sistema usando una vis- des: ta black box. Esto es, c omo el sistema est a obligado a actuar cuando es estimulado. Aborda: 1. Partici on del sistema. 1. la construcci on de un modelo de expectativas de los clientes con un vocabulario claro, 2. Realizar el dise no de componentes de frontera (boundaries).

3. Realizar el dise no de los componentes internos. 2. disponer de una descripci on u nica de requisitos para que todos los modelos posteriores puedan ser usa4. Realizar el despliegue de los componentes l ogicos. dos. Por ejemplo, un Modelo de An alisis modela la funcionalidad especicada en el modelo de requeriEsta cobertura de modelos aborda el aspecto de la mientos; un Modelo de Plataforma Espec ca puede transformaci on de modelos indicando un proceso de usar un tipo de Sistema Operativo como se dene transformaci on asistido garantizando la consistencia con en el modelo de requerimientos. modelos de diferentes niveles de abstracci on. El modelo requerimientos est a dado por los requisitos funcionales y los requisitos no funcionales. Los primeros: los servicios; los objetos de negocio; los eventos producidos y consumidos por el sistema y los actores interactuando con el sistema y las funciones que son descritas usando capacidades capabilities (casos de uso). Los requisitos No Funcionales como calidad del servicio (tiempo de respuesta, tolerancia a fallos); calidad del desarrollo (mantenibilidad, reusabilidad, exibilidad y requerimientos espec cos de plataforma).

5.

Transformaciones

Las transformaciones bajo este enfoque (OMG), involucran una especicaci on del metamodelo llamado Meta Object Facility (MOF) [21], un lenguaje de restricciones llamado Object Constraint Language (OCL) [19] y un lenguaje de transformaci on llamado Query/View/Transformation (QVT) [20]. 5

Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth

5.2 Enfoque ModeloaModelo (ModeltoModel) La transformaci on de modelos, por lo general, adopta un enfoque orientado a objetos para la representaci on y manipulaci on del tema de sus modelos. La transformaci on dene la generaci on autom atica de un modelo a partir de otro modelo. Esta denici on es un conjunto de reglas que describen c omo uno o m as artefactos en el modelo origen pueden ser transformados en una o m as construcciones en el modelo destino [10]. Las transformaciones pueden ser: 1. End ogenas: Si est an expresadas en el mismo lenguaje que los modelos. 2. Ex ogenas: No est an expresadas en el mismo lenguaje que los modelos. 3. Verticales: Los lenguajes destino son diferentes entre s .

5 TRANSFORMACIONES su escritura. Jamda, por ejemplo, (herramienta para representar modelos UML) tiene un mecanismo visitador para generar c odigo. 2. Enfoque basado en plantillas (templatebased): la mayor parte de las herramientas disponibles para MDA soportan la generaci on de c odigo sobre este enfoque. Una plantilla, por lo general, consiste en el texto destino que contienen los empalmes(mapeo) del metac odigo para acceder a la informaci on del modelo fuente para realizar la selecci on de c odigo y la expansi on iterativa.

5.2.

Enfoque ModeloaModelo (ModeltoModel)

Estas transformaciones traducen entre el modelo fuente y los modelos de destino, que pueden ser instancias de los metamodelos iguales o diferentes. Todos estos 4. Horizontales: Los lenguajes destino no son diferentes enfoques de apoyo introducen sint actica de variables y entre s . de patrones. Por ejemplo, cuando se va de un diagrama de clases a una implementaci on en EJB, la herramienta (OptimalJ) genera un modelo de componentes intermedio EJB el cual contiene toda la informaci on necesaria para generar todo el c odigo de la clase Java.

Figura 3: Alcance de las transformaciones. Tomado de [15]

Figura 4: Clasicaci on de las transformaciones Modelo aModelo. Presentaci on propia de los autores.

En [6] se exponen aproximaciones de la transformaci on En la gura 4 se presentan las corrientes de este de modelos, particularmente la transformaci on de PMI a enfoque. PSM. Tambi en se mencionan otros mecanismos de transformaci on, en [15], como CWM Common Warehouse 5.1. Enfoque de Modelo a C odigo Metamodel [18] cuya transformaci on se implementa en (ModelTo Code) XSLT (eXtensible Stylesheet Language Transformation), que lo que hace es transformar modelos serializados en Tambi en referenciado como Modeloa Texto. XML usando XMI. Lo que hace esta transformaci on 1. Enfoque VisitorBased: Se trata de un mecanismo es unir elementos del modelo origen con elementos visitante que recorre la representaci on interna de un del modelo destino. Este enfoque conduce r apido a modelo para la generaci on de c odigo muy b asico y implementaciones no mantenibles y a una dicultad en Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth 6

su lectura por su nivel de detalle. En [23] se presentan motores usados para la transformaci on y generadores de modelos.

Figura 5: Herramientas para la transformaci on. Presentaci on propia de los autores. Igualmente, en [23], se referencian los enfoques de la transformaci on de modelos y el n umero de pasos para ejecutar estas transformaciones.

Figura 6: Enfoques de transformaci on de modelos y n umero de pasos en la transformaci on. Adaptado de [23]. Presentaci on propia de los autores. Todas estas transformaciones deben, siempre, obtener un resultado. Bien sea un nuevo modelo, metamodelo, o c odigo del aplicativo para el cual se ha modelado un dominio. Pero ese resultado, m as all a de convertirse en un modelo de mayor (o menor) nivel de abstracci on, debe aportar condiciones u nicas para el dominio modelado. Este aporte de condiciones particulares sobre el dominio est a dado por el DSL (Domain Specic Language).

6.

DSL Domain Specic Language

En [9], DSL se dene como artefacto que toma parte importante en el proceso de mapeo entre un problema de

6 DSL DOMAIN SPECIFIC LANGUAGE dominio y el modelo de implementaci on de ese dominio de soluci on. Un DSL contiene la sintaxis y la sem antica de los conceptos de un modelo en el mismo nivel de abstracci on que el dominio del problema ofrece. Enti endase dominio del problema como los procesos, entidades, restricciones que forman parte de la empresa (organizaci on) que se est a analizando. Es necesario comprender como las diferentes entidades del dominio interact uan entre s y cumplen con sus responsabilidades. Es importante para comprender un dominio de problema compartir un vocabulario com un, nos referimos a conceptualizaciones de t erminos unicados, para expertos del dominio y modeladores, y sobre todo, lo m as importante, hacer f acil la comunicaci on (entendimiento com un). Un DSL debe dar la posibilidad de dise nar las abstracciones que forman parte del dominio. La abstracci on es un proceso cognitivo del cerebro humano que permite centrarnos en los aspectos fundamentales de un tema, haciendo caso omiso de los detalles innecesarios. El DSL diere de un lenguaje de prop osito general porque se encuentra dirigido a un problema (dominio particular) y porque contiene sintaxis y sem antica que los conceptos del modelo en el mismo nivel de abstracci on como el problema tiene. Otra particularidad, descrita en [9], es que el DSL tiene que ser comunicativo con su p ublico y permitir que fragmentos de c odigo sean lo sucientemente expresivos para mapear el proceso de pensamiento del modelador de dominio; como consecuencia de esto se obtiene en el dise no el nivel correcto de sintaxis as como de abstracciones sem anticas para el usuario. Cuando se programa usando DSL quien hace el programa puede centrarse en resolver el problema en cuesti on y no tiene que preocuparse de los detalles en la implementaci on u otros elementos no esenciales del dominio de soluci on; siempre y cuando el DSL tenga el nivel apropiado de abstracci on; en este caso se requiere que la mente humana (modelador) entienda su comportamiento. El DSL, seg un describe [8], es un lenguage de un prop osito determinado, cuya representaci on puede ser gr aca o textual, adaptado a problemas concretos de un dominio. Un DSL gestiona complejidad a trav es de abstracci on organizada, en software existente y/o en literatura t ecnica, en la que participan expertos de un dominio. El DSL es un lenguaje de modelado especializado que se orienta hacia un dominio estrecho (espec co). Entre estos dominios se pueden mencionar i) Verticales: dominio de negocio; telecomunicaciones; nanzas; banca; seguros; etc., y ii) Horizontales, subdividos en Transacciones y T ecnicos: persistencia; interfaces de usuario; telecomunicacio-

Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth

6.2 Templated Generation nes; etc. Tambi en en [8] se aluden las cualidades deseables de un DSL: 1. Expresividad limitada.

CONCLUSIONES

6.2.

Templated Generation

Que es la especicaci on de una m aquina de estados particular. En [8] se dene el t ermino Language Workbench como 2. Integridad conceptual. las herramientas que ayudan a construir DSLs y herramientas de soporte para los mismos DSLs. Estas herra3. Manejabilidad. mientas, languages Workbenchs, permiten el uso de me4. Promoci on de la escritura de c odigo conciso y legi- tamodelos. Estas herramientas se caracterizan por tener ble. los siguientes elementos: 5. Regularidad. 6. Fiablidad. 7. Consistencia con notaciones aceptadas convencionalmente. 1. Esquema de modelo sem antico: se usa en el metamodelo. Por ejemplo, un modelo de datos sin mucho comportamiento. 2. Ambiente de edici on de DSL: permite la escritura de DSLs. 3. Comportamiento del modelo sem antico: dene lo que el script DSL hace por fuera del modelo sem antico. Languages Workbenchs conocidos: Intentional Workbench. MetaEdit. Meta-Programming System (MPS). Xtext. MsSqlServer Modeling Project (Oslo) Clojure.

Un DSL puede ser interno (embebido) o externo, en este caso, se representa en un lenguaje diferente al lenguaje de programaci on principal. Un DSL se traduce, generalmente, en llamadas a bibliotecas de subrutinas. El DSL provee sintaxis (que es gram atica) que es la expresi on de captura legal. Tambi en provee sem antica que es lo que se hace cuando se ejecuta. Los diagramas para su representaci on, usualmente, son m aquinas de estado. A todo este conjunto se le denomina Modelo Sem antico [8]. Este modelo sem antico se acompa na de un analizador (PARSER) que contiene operaciones jer arquicas, estructura de scripts (o tambi en conocido como syntax tree). A toda esta estructura se le conoce como procesador DSL. El modelo sem antico es el mejor lugar para validar comportamiento. Posee dos interfaces: 1. Interface Operacional: que permite usar modelos de (llenado) en el curso del trabajo, y, 2. llenado (population) de interface: que se usa para crear instancias de clases en el modelo.

7.

Conclusiones

El aporte que ha brindado el enfoque dirigido por modelos al desarrollo de software ha sido amplio y actico, en el sentido en que el resultado de esta pr actiEl modelo sem antico es una representaci on del mismo pr ca minimiza el esfuerzo en el desarrollo de productos tema que el DSL describe. Es una librer a o un framework que el DSL rellena. El modelo sem antico aumenta y garantiza la completitud en el entendimiento, tanto del problema como de la soluci on planteada. El esfuerzo exibilidad en el PARSER y en la ejecuci on. del desarrollo puede minimizarse debido a que el equipo En cuanto a la generaci on de c odigo, a partir de un desarrollador se centra en las ideas y conceptos del DSL, se presenta el concepto ModelAward Generation dominio del problema y no en los aspectos de la implementaci on tecnol ogica, cumpliendo as con el principio que posee dos estilos: de Representaci on Directa de la propuesta MDA; de esta manera se presenta un mayor acercamiento a las 6.1. Transformer Generation necesidades del usuario nal. Que es c odigo le do por el modelo sem antico, y, Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth 8

BIBLIOGRAF IA Este enfoque de desarrollo de software dirigido por modelos invita a la separaci on de los mismos; es decir, el dise no del sistema puede separarse de las tecnolog as de construcci on y de la misma arquitectura, aportando como gran ventaja la modicaci on de cada uno de estos modelos de manera separada e independiente. La cobertura de modelos, bajo la propuesta MDA, es un mecanismo de apoyo para el proceso de desarrollo de software. Estas diferentes perspectivas intentan llenar los vac os que se presentan a la hora de manipular y trabajar con modelos. En teor a es f acil iniciar con un modelo, pero a la hora de volver realidad ese modelo pueden presentarse dicultades e inconvenientes que pueden hacer que el resultado esperado no sea lo propuesto en la abstracci on inicial; de manera que, esta cobertura de modelos puede gu ar, en la construcci on del producto software, desde la abstracci on inicial hasta la obtenci on del c odigo nal representado en una tecnolog a espec ca. Esta cobertura de modelos tambi en invita a que los diferentes modelos puedan ser trabajados por diferentes equipos de desarrollo de forma descentralizada, concurrente y con un m nimo de comunicaci on, pero efectiva, entre ellos.

BIBLIOGRAF IA [4] B` ezivin Jean; Farcet Nicolas; J` ez` eque Jean-Marc; Langlois Beno t; Pollet Damien. Reective model driven engineering. In Proceedings of UML 2003, volume 2863 of LNCS, pages 175189. Springer, 2003. [5] Clarke Siobh an; Harrison William; Ossher Harold; Tarr Peri. Subjectoriented design: Towards improved alignment of requirements, design and code. In ObjectOriented Programming Systems, Languages and Applications (OOPSLA), 1999. [6] Czarnecki Krzysztof; Helsen Simon. Classication of model transformation approaches. In OOPSLA03 Workshop on Generative Techniques in the Context of Model Driven Architecture, 2003. [7] Daniel Exertier; Beno t Langlois; Xavier Le Roux. Pim denition and description. In Proceedings First European Workshop on Model Driven Architecture with Emphasis on Industrial Application, pages 17 18, 2004. [8] Fowler Martin. Domain Specic Languages. Addison-Wesley Professional, 2010. [9] Ghosh Debasish. DSLs in ACTION. Manning Publications, 2011.

Las transformaciones son los resultados de construcalez Rub en Antol n. Aplicaci on de ingenier a ciones de modelos iniciales en modelos destinos. Es decir, [10] Gonz dirigida por modelos (mde) en procesos de negocio la generaci on autom atica de un modelo a partir de otro (bpm). Masters thesis, Departamento de Ingenier a modelo. Y ese resultado debe aportar condiciones u nicas Inform atica. Escuela Polit ecnica Superior. Universi(sem antica y sintaxis) para el dominio que inicialmente dad Aut onoma de Madrid, 2008. se model o. [11] IEEE Software. Special issue on modeldriven development. Technical Report 5, IEEE, 2003. [12] Kleppe Anneke. Warmer Jos. Bast Wim. MDA Explained: The Model Driven Architecture: Practice and Promise. Addison Wesley, 2003.

Bibliograf a

[1] Amaya Pablo; Gonz alez Carlos; Murillo Juan M. Separaci on de aspectos en mda: Una aproximaci on basada en m ultiples vistas. In Actas del I Taller sobre opez L. Edna D; Gonz alez G. Mois es; L opez S. Desarrollo Dirigido por Modelos MDA y Aplicacio- [13] L M a ximo; Idu n ate R. Erick L. Proceso de desanes (DSDM04), 2004. rrollo de software mediante herramientas mda. In CISCI 6a Conferencia Iberoamericana en sistemas [2] Amaya Pablo; Gonz alez Carlos; Murillo Juan M. Ascibern etica e inform atica. Departamento de Cienpectmda: Hacia un desarrollo incremental consistencias Computacionales. Centro Nacional de Investite integrando mda y orientado a aspectos. In Actas gaci on y Desarrollo Tecnol ogico (CENIDET). M exidel II Taller sobre Desarrollo Dirigido por Modelos co, 2007. MDA y Aplicaciones (DSDM05), 2005. [14] Lucas Mart nez Francisco Javier; Molina Molina [3] Anacleto Valerio Adri an. Arquitectura dirigida por Fernando; Toval Alvarez Ambrosio. Una propuesta modelos. Revista Code, (31):6064, 2006. de proceso expl cito de v&v en el marco de mda. Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth 9

BIBLIOGRAF IA Grupo de Ingenier a del Software. Departamento de Inform atica y Sistemas. Universidad de Murcia, 157, 2003. [15] Muller Pierre-Alain. Model transformations. an overview. http://www.irisa.fr/triskell/members/pierrealain.muller/teaching/aboutmodeltransfo, 2005. [16] Neil Carlos Gerardo. Arquitectura de software dirigida por modelos - Dise no de un almac en de datos hist oricos en el marco del desarrollo de software dirigido por modelos. PhD thesis, Universidad Nacional de la Plata. Argentina, 2010. [17] OMG. OMG: Model Driven Architecture (MDA)., 2001. Document number ormsc/2001-07-01. (2001). [18] OMG. OMG. Catalog of OMG Modeling and Metadata Specications., 2003. OMG. Catalog of OMG Modeling and Metadata Specications. [19] OMG. OMG. Documents Associated With Object Constraint Language, Version 2.0., 2006. OMG. Documents Associated With Object Constraint Language, Version 2.0. [20] OMG. OMG. Meta Object Facility (MOF) 2.0 Query/View/Transformation, V1.1, 2011. OMG. Meta Object Facility (MOF) 2.0 Query/View/Transformation, V1.1. [21] OMG. OMG: Meta Object Facility (MOF) Version 2.4.1, 2011. Documents Associated With Meta Object Facility (MOF) Version 2.4.1 Release Date: August 2011. [22] Quintero Juan Bernando & Anaya Raquel. Mda y el papel de los modelos en el proceso de desarrollo de software. Revista EIA, (8):131146, 2007. [23] Quintero Juan Bernardo; Duitama Mu noz Jhon Freddy. Reexiones acerca de la adopci on de enfoques centrados en modelos en el desarrollo de software. Ingenier a y Universidad, 15(1):219243, 2011.

BIBLIOGRAF IA

Orozco M Daniel F; Giraldo O William J; Tretz G Helmuth

10