Caratula
UNIVERSIDAD TÉCNICA PARTICULAR DE LOJA
La Universidad Católica de Loja
ÁREA TÉCNICA
INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN
TRABAJO DE TITULACIÓN
Identificación, uso y evaluación de herramientas de Model Driven Development (MDD)
Autor: Jumbo Condolo, Juan Efrén
Director: Guamán Coronel, Daniel Alejandro
LOJA – ECUADOR 2021
comunicar públicamente la obra, mientras se reconozca la autoría original, no se utilice con fines comerciales y se permiten obras derivadas, siempre que mantenga la misma licencia al ser divulgada. http://creativecommons.org/licenses/by-nc-sa/4.0/deed.es
2021
Aprobación del director del trabajo de titulación
Loja, 21 de mayo de 2021
Magister
Fernanda Maricela Soto Guerrero.
Coordinadora de carrera de Ingeniería en Sistemas Informáticos y Computación.
Ciudad.
De mi consideración:
El presente trabajo de titulación denominado: Identificación, uso y evaluación de herramientas de Model Driven Development (MDD), realizado por Jumbo Condolo Juan Efrén, ha sido orientado y revisado durante su ejecución, por cuanto se aprueba la presentación del mismo. Así mismo, doy fe que dicho trabajo de titulación ha sido revisado por la herramienta antiplagio institucional.
Particular que comunico para los fines pertinentes.
Atentamente,
f) ____________________________
Daniel Alejandro Guamán Coronel.
C.l: 1103777403
Declaración de autoría y cesión de derechos
“Yo Jumbo Condolo Juan Efrén, declaro y acepto en forma expresa lo siguiente:
• Ser autor(a) del Trabajo de Titulación denominado: Identificación, uso y evaluación de herramientas de Model Driven Development (MDD), específicamente de los contenidos comprendidos en: Capítulo 1. Marco Teórico, Capítulo 2. Herramientas de modelado y Caso de estudio, Capítulo 3. Experimentación de herramientas de metamodelado, Capítulo 4.
Evaluación y resultado de herramientas de metamodelado, Conclusiones y Recomendaciones, siendo Daniel Alejandro Guamán Coronel, director (a) del presente trabajo; y, en tal virtud, eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones judiciales o administrativas, en relación a la propiedad intelectual. Además, ratifico que las ideas, conceptos, procedimientos y resultados vertidos en el presente trabajo investigativo son de mi exclusiva responsabilidad.
• Que mi obra, producto de mis actividades académicas y de investigación, forma parte del patrimonio de la Universidad Técnica Particular de Loja, de conformidad con el artículo 20, literal j), de la Ley Orgánica de Educación Superior; y, artículo 91 del Estatuto Orgánico de la UTPL, que establece: “Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la Universidad”.
• Autorizo a la Universidad Técnica Particular de Loja para que pueda hacer uso de mi obra con fines netamente académicos, ya sea de forma impresa, digital y/o electrónica o por cualquier medio conocido o por conocerse, sirviendo el presente instrumento como la fe de mi completo consentimiento; y, para que sea ingresada al Sistema Nacional de Información de la Educación Superior del Ecuador para su difusión pública, en cumplimiento del artículo 144 de la Ley Orgánica de Educación Superior.
f) ____________________________
Autor: Jumbo Condolo Juan Efrén
Cedula: 1104802440
Dedicatoria
El presente trabajo de titulación lo dedico a mis queridos padres, Juan Segundo Jumbo Maza y Rosa Imelda Condolo Masache, quienes siempre estuvieron incondicionalmente pendientes de todo mi proceso de formación educativa, para llegar a ser un gran profesional, además por haberme forjado la persona que soy en la actualidad, me formaron con reglas y con algunas libertades, pero al final de cuentas, me motivaron constantemente para alcanzar mis anhelos.
Juan Jumbo Condolo
Agradecimiento
Quiero agradecer primeramente a Dios, quien me dio el don de la perseverancia para no rendirme y poder cumplir mis objetivos.
A mis queridos padres Juan e Imelda, quienes con su esfuerzo y sacrificio supieron apoyarme constantemente en este largo proceso.
A mis apreciados hermanos, Hernán, Franklin y Robalino que, con sus consejos, sus palabras de aliento me supieron motivar para no rendirme en buenos y malos momentos que se vivieron en el transcurso de mi carrera universitaria.
A los catedráticos de la UTPL, que con el pasar de los años se convirtieron en un modelo a seguir para poder desarrollarme como un excelente profesional.
A la Universidad Técnica Particular de Loja que me abrió sus puertas para forjarme como mejor persona y buen profesional.
A mi director tesis, Ing. Daniel Guamán, por haberme brindado la oportunidad de recurrir a su capacidad y conocimientos; a la vez guiarme constantemente en todo el proceso de mi proyecto de titulación ya que sin su apoyo no hubiese logrado cumplir con los objetivos de mi proyecto.
Juan Jumbo Condolo
Índice de contenido
Caratula ... I Aprobación del director del trabajo de titulación ... II Declaración de autoría y cesión de derechos ... III Dedicatoria... V Agradecimiento ... VI Índice de contenido ... VII
Resumen ... 1
Abstract ... 2
Introducción ... 3
Justificación ... 4
Capítulo uno ... 6
Marco Teórico ... 6
1.1. Meta Object Facility (MOF) ... 6
1.2. Modelo ... 8
1.3. Metamodelo ... 9
1.4. Meta-metamodelo ... 10
1.5. Model Driven Architecture (MDA) ... 11
1.5.1. Características de MDA ...11
1.5.2. Ventajas y Desventajas de MDA ...12
1.5.3. Elementos de MDA ...14
1.5.4. Model Driven Development (MDD) ...15
1.5.5. Características de MDD ...16
1.5.6. Ventajas y desventajas de MDD ...17
1.5.7. Ciclo de vida de MDD ...18
1.5.8. Beneficios de MDD ...19
1.5.9. Aspectos en los que MDD mejora el proceso...20
1.6. Model Driven Engineering (MDE) ... 21
1.6.1. Características de MDE ...21
1.6.2. Ventajas y Desventajas de MDE ...22
1.7. Lenguajes de Modelado ... 24
1.7.1. Domain Specific Languages (DSL) ...24
1.7.2. Janus Transformation Language (JTL) ...25
1.7.3. UML (Unified Modelling Language) ...26
1.8. Transformaciones ... 28
1.8.1. Model to Model (M2M) ...28
1.8.2. Model to Text (M2T)...28
1.8.3. Text to Model (T2M)...29
Capítulo dos ... 30
Herramientas de Modelado y Análisis de Caso de Estudio... 30
2.1. Introducción ... 30
2.2. Herramientas de modelado ... 30
2.2.1. Eclipse Modeling Framework (EMF) ...30
2.2.2. MoDisco. ...31
2.2.3. ArcStyler ...32
2.2.4. OptimalJ ...32
2.2.5. Codagen Architect ...33
2.2.6. Microsoft DSL Tools ...33
2.3. El ciclo de vida MDD aplicado a un caso de estudio. ... 36
2.3.1. Problemática ...38
2.3.2. Análisis ...40
2.3.3. Análisis para el diseño de los casos de usos ...41
2.3.4. Diseño ...45
2.3.5. Codificación ...47
2.3.6. Testeo ...47
2.3.7. Despliegue ...47
Capítulo tres ... 48
Experimentación de herramientas de metamodelado ... 48
3.1. Proceso de experimentación ... 48
3.2. Eclipse Modeling Framework (EMF) ... 48
3.3. Modelado en EMF ... 50
3.4. Modelo MoDisco ... 59
Capítulo cuatro ... 63
Evaluación y resultado de herramientas de metamodelado ... 63
4.1. Evaluación de Herramientas ... 63
4.2. Resultados de evaluación bajo escenarios de aplicación ... 68
Conclusiones ... 75
Recomendaciones ... 77
Referencias ... 78
Apéndice ... 84
Índice de Tablas Tabla 1 Ventajas y desventajas de Model Driven Development ... 17
Tabla 2. Ventajas y desventajas Model Driven Engineering (MDE) ... 22
Tabla 3 Comparación de herramientas MDD ... 35
Tabla 4 Entregables resultantes. ... 38
Tabla 5 Requerimientos Funcionales ... 40
Tabla 6 Requerimientos No Funcionales ... 41
Tabla 7 Criterios de evaluación ... 63
Tabla 8 Datos generales de las herramientas ... 64
Tabla 9 Criterios de documentación ... 65
Tabla 10 Criterios de madurez ... 65
Tabla 11 Comparativo de características de las herramientas EMF y MoDisco ... 66
Tabla 12: Términos y definiciones. ... 86
Tabla 13: Características de usuario secretario/a. ... 88
Tabla 14: Características de usuario médico... 88
Tabla 15: Requerimiento Funcional RF01 ... 90
Tabla 16: Requerimiento Funcional RF02 ... 90
Tabla 17: Requerimiento Funcional RF03 ... 92
Tabla 18: Requerimiento Funcional RF04 ... 92
Tabla 19: Requerimiento Funcional RF05 ... 93
Tabla 20 Requerimiento Funcional RF06 ... 93
Tabla 21: Requerimiento Funcional RF07 ... 94
Índice de Figuras Figura 1 Niveles MOF ... 7
Figura 2 Representación de Modelo nivel M1 ... 8
Figura 3 Ejemplo de Nivel 1. ... 9
Figura 4 Representación de Metamodelo M2... 10
Figura 5 Representación de Meta-metamodelo M3 ... 11
Figura 6 Model Driven Architecture (MDA) ... 14
Figura 7 Ciclo de vida MDD ... 19
Figura 8 Fases del Ciclo de Vida de MDD ... 37
Figura 9 Caso de uso general cita medica ... 42
Figura 10 Diagrama de Clases Caso de Estudio... 46
Figura 11 Proceso de experimentación EMF ... 49
Figura 12 Selección tipo de clase ... 50
Figura 13 Diagrama de clases de modelo ... 51
Figura 14 Generación de código ... 51
Figura 15 Generación de código. ... 52
Figura 16 Generación de archivo. ... 52
Figura 17 Entidades ... 53
Figura 18 Componentes exportados ... 54
Figura 19 Componentes exportados ... 55
Figura 20 Configuración de la base de datos. ... 55
Figura 21 Configuración estructura de proyecto. ... 57
Figura 22 Interfaz Postman ... 58
Figura 23 Ejecución de POST y GET ... 58
Figura 24 Proceso de experimentación MoDisco ... 59
Figura 25 Distribución de Paquetes de Clases... 60
Figura 26 Tipo de modelos MoDisco ... 60
Figura 27 Parámetros Discovery... 61
Figura 28 Parámetros Discovery... 62
Figura 29 Configuración Parámetros Discovery ... 62
Figura 30 Metamodelo de Clase ... 68
Figura 31 Metamodelo 3 clases relacionadas ... 69
Figura 32 Esquema de la generación del código a partir del metamodelo ... 71
Figura 33 Paquetes requeridos para el despliegue ... 72
Figura 34 Metamodelo con Asociación y Agregación. ... 73
Figura 35 Metamodelo con agregación ... 74
Figura 39 Creación de Proyecto en Eclipse ... 126
Figura 12 Creación de Proyecto en Eclipse ... 126
Figura 13 Creación de Proyecto en Eclipse ... 127
Figura 14 Asignación de nombre del proyecto ... 128
Figura 40 Diseño de diagrama en Eclipse (Metamodelo) ... 129
Figura 41 Generación de código del modelo. ... 130
Figura 42 Propiedades de las clases. ... 130
Figura 43 Identificar tipo de modelo para generar. ... 131
Figura 44 Selección de un modelo para importar. ... 131
Figura 45 Especifique uno o más URI '.ecore' o '.emof' e intente cargarlos ... 132
Figura 46 Especificación del paquete para generación de código... 132
Resumen
El desarrollo dirigido por modelos, (por sus siglas en inglés MDD - Model Diven Development), es un enfoque al desarrollo de software basado en modelos, los mismos que son aplicados en diferentes ámbitos, el presente trabajo de titulación cumple con el objetivo de identificar, usar y evaluar herramientas para desarrollo por medio de modelos, en este documento se presenta un marco teórico haciendo conocer lo más importante del MDD para ello se toma en consideración las ventajas y desventajas, caso de estudio, el ciclo de vida y las transformaciones que realiza.
Particularmente, para la evaluación de las herramientas MDD se ha tomado en consideración dos herramientas EMF (Eclipse Modeling Framework) y MoDisco, con las cuales se puede realizar tanto ingeniería inversa como ingeniería directa, por ende son las herramientas consideras de manera eficiente para hacer este tipo de desarrollo por medio de modelos, es por ello que se trabajó bajo diferentes escenarios de pruebas en las dos herramientas, posterior a esto se evalúa el desempeño, rendimiento y finalmente validar cuál es la más eficiente en cuanto a las métricas planteadas.
Palabras clave: metamodelado, transformaciones de modelos, gestión de desarrollo de software.
Abstract
Model Driven Development, (acronym in English MDD - Model Driven Development), is an approach to the development of software based on models, the same that are applied in different areas, the present degree work is located in identifying, using and evaluating tools for development by through models, this document presents a theoretical framework making known the most important MDD tools for this, the advantages and disadvantages, case study, life cycle and the transformations it carries out are taken into consideration.
In particular, to evaluation of the MDD tools, two tools EMF (Eclipse Modeling Framework) and MoDisco were taken into consideration, with which both reverse engineering and direct engineering can be performed, which is why they are the most likely to do this. type of development through models, that is why we worked under test scenarios in the two tools, after which the performance, performance and validation of which is the most efficient in terms of the proposed metrics are evaluated.
Keywords: metamodeling, transformation, software development management.
Introducción
Hoy en día, la arquitectura de software basada en modelos ha ganado un ambiente muy robusto en la evolutiva rama de la ingeniería de software. Al ser un nuevo modelo de desarrollo ha sembrado intranquilidad en cuanto a su inconstancia y eficacia referente a la metodología tradicional de desarrollo.
El presente Trabajo de Titulación contiene aspectos de investigación y desarrollo de temáticas de ingeniería y arquitectura de software, específicamente en desarrollo de software dirigido por modelos (MDD, por sus siglas en inglés - Model Driven Development), adicional a esto se identifica las diferencias y semejanzas, ventajas y desventajas del MMD en el uso de las herramientas de Microsoft Visual Studio, Java o Eclipse, con ello obtendremos conocimiento relacionados con los conceptos asociados a modelado, uso de buenas prácticas de modelado y frameworks para MDD, con respecto a la evaluación y análisis será necesario identificar las herramientas y aplicarlas a un servicio con la finalidad de identificar los procesos que realizan cada una y poder determinar la mejor herramienta para realizar el modelado del servicio.
Finalmente se conocerá los resultados de la evaluación de estas herramientas: por ejemplo, equilibrar el tiempo y el esfuerzo necesarios para implementar un sistema, integrarse con las aplicaciones y tecnologías existentes y a la vez coordinar múltiples equipos que producen diferentes componentes del servicio implementado.
Justificación
El desarrollo por medio de modelos ha causado bastante interés en los desarrolladores de software porque les ayuda a disminuir los costes y tiempo en el desarrollo de aplicaciones, el presente trabajo tiene como objetivo evaluar ciertas herramientas de MDD mediante un caso de estudio e identificar cuál es la más eficiente en el momento de aplicarla.
MDD se considera una alternativa para el desarrollo por medio de modelos, lo cual hace que este método sea el más apropiado para poder desarrollar y obtener una mejor calidad en el sistema y sobre todo minimiza el costo y el tiempo del desarrollo de las aplicaciones, para ello se define objetivos de los cuales sirven para evaluar el cumplimiento del presente trabajo de titulación, los cuales se detallan a continuación:
General
• Identificar, usar y evaluar herramientas para Model Driven Development (MDD) Específicos.
• Conocer el uso del estándar MOF (Meta-Object Facility)
• Buscar herramientas que permitan llevar a cabo el proceso de MDD.
• Realizar una comparativa de las herramientas y lenguajes que se usan como parte de MDD.
• Identificar un prototipo o caso de estudio para aplicación de MDD y sus conceptos.
• Evaluar el prototipo o caso de estudio desarrollado con MDD y exponer las ventajas y desventajas con respecto al desarrollo usando una metodología tradicional o ágil.
Metodología o estrategia de desarrollo
Como metodología u estrategia se ha tomado en cuenta dos enfoques, el primer enfoque realizará la investigación de las herramientas de modelado y el segundo enfoque del desarrollo, análisis y evaluación de caso de estudio.
Investigación:
• Investigar el fundamento teórico referente al estándar Meta Object Facility (MOF).
• Buscar información referente a herramientas y lenguajes de modelado.
• Investigar el fundamento teórico sobre metodologías de desarrollo MDD y MDA.
• Documentar la parte investigativa y presentará cuadro comparativo de herramientas.
• Definir los criterios para evaluar las herramientas.
Desarrollo:
• Instalar y usar herramientas para el desarrollo de modelos.
• Elaborar la comparativa desde el punto de vista técnico y/o usabilidad de las herramientas y lenguajes de modelado.
• Evaluación del prototipo en base a los criterios definidos.
Estructura del documento.
El presente documento se divide en 4 capítulos los mismo que se detallan a continuación:
En el Capítulo 1, se enfoca en el marco teórico, en la descripción de cada uno de los términos y temas que se tratarán y que se abordarán durante el desarrollo del trabajo de titulación. En el Capítulo 2, se describe cada una de las herramientas que serán evaluadas, para ello también analizamos parte de la arquitectura de un caso de estudio propuesto por el autor. En el Capítulo 3, se describe el proceso de funcionamiento y aplicación de la herramienta de modelado utilizando el caso de estudio propuesto y finalmente en el Capítulo 4 presentaremos los resultados de la evaluación de las herramientas de metamodelado.
Capítulo uno Marco Teórico
Para el desarrollo del presente trabajo de titulación, se hace uso de conceptos fundamentales tales como Meta Object Facility (MOF), Modelo, Metamodelo, Meta- metamodelo, Model Driven Architecture (MDA), Model Driven Development (MDD), Model Driven Engineering (MDE), Lenguajes de Modelado, Domain Specific Languaje (DSL), Janus Transformation Language (JTL), Unidied Modeling Language (UML) y Transformaciones, de cada concepto se expone sus características, ventajas y desventajas. De MDD se expone el ciclo de vida y sus beneficios en el desarrollo basado en modelos.
1.1. Meta Object Facility (MOF)
MOF se define como un conjunto de interfaces estándar las mismas que se pueden utilizar para definir y manipular un conjunto de metamodelos interoperables y sus modelos correspondientes (Object Management Group, 2015). En otra definición se expone que MOF se encuentra ubicada en la capa superior de la arquitectura de 4 capas, que proporciona un meta-meta lenguaje que permite metamodelos en la capa M2 donde se ubica el metamodelo (Pons, 2010).
En la Figura 1 se expone los 4 niveles principales de MOF, entre los que destacan, las instancias (M0), modelo (M1), metamodelo (M2), meta-metamodelo (M3).
Figura 1 Niveles MOF
Nota: La figura 1 representa los 4 niveles que conforman la arquitectura 4 capas que se los define como: M3, M2, M1, M0, adaptado de, Bezivin & Gerbe, 2001
• En base a la Figura 1, el nivel M3, conocido como meta-metamodelo, es el nivel más abstracto, donde se encuentra el MOF, que permite definir meta modelos concretos como el del lenguaje UML.
• En el nivel M2, más conocido como metamodelo, sus elementos que lo conforman son lenguajes de modelado, por ejemplo, UML (Lenguaje Unificado de Modelado). Los conceptos de este nivel son Clase, Atributo, Asociación, los cuales también pueden considerarse como modelo MOF de instancias.
• El nivel M1, se lo conoce como el modelo del sistema. Este incorpora el modelo de un sistema software que representan categorías de las instancias de M0. Lo que quiere decir que cada elemento de M0 es una instancia de un elemento de M1.
• Finalmente, en el nivel M0, se encuentran las instancias que corresponden al sistema o situación real, es decir, los objetos de la aplicación. Este nivel consta de instancias de modelo, estos vienen a ser los valores de datos, objetos de clases instanciadas, tablas de bases de datos, algoritmos instanciados, código XML o definiciones de función.
Una vez que conocemos los niveles MOF, se expone lo referente a los conceptos de modelo y su función dentro del MDD.
1.2. Modelo
Un modelo es “una simplificación de un sistema construido con un objetivo previsto en mente. El modelo debería ser capaz de responder preguntas en lugar del sistema real”
(Martinez, 2013). En otra definición (Pascuas Rengifo, 2017), menciona que un modelo es “una representación de algo, construido y utilizado para un propósito en particular”.
(Aguilar Vera, 2017), define al modelo como "Una representación simplificada de un proceso de software, representada desde una perspectiva específica. Por su naturaleza los modelos son simplificados, por lo tanto; un modelo de procesos de software es una abstracción de un proceso real".
La Figura 2 muestra la representación de un modelo, donde se evidencia que uno o varios modelos son abstraídos para representar un sistema.
Figura 2 Representación de Modelo nivel M1
Nota: Representación de Modelo nivel M1 Adaptado de Overbeek, 2006
1 1..*
<<Represe
Sistema
Modelo
En la Figura 3, se presenta un ejemplo de modelado, donde se identifica la entidad Cliente con los atributos nombre, dirección y teléfono; y la entidad Artículo con los atributos código, título y precio. Dichas entidades y atributos pueden ser modelados mediante un lenguaje de modelado como UML para describir el contenido de la información.
Figura 3
Ejemplo de Nivel 1.
Nota: Se describen las entidades con sus atributos.
Adaptado de Engineering & Science, 2006 1.3. Metamodelo
Un metamodelo es “un modelo de especificación para una clase de SUS (Subject under study) donde cada SUS de la clase es en sí mismo un modelo válido expresado en un determinado lenguaje de modelado” Seidewitz (2003). Un metamodelo “se lo define también como un modelo que describe una clase de modelos” (Basin & Doser, 2006).
En el caso de un metamodelo se describen los posibles modelos que se puede expresar utilizando el lenguaje de modelado. En la Figura 4 se evidencia, como el modelo, que es una instancia del metamodelo se puede representar por un lenguaje, donde el modelo es una simplificación del sistema para luego ser un metamodelo el cual es representado por un lenguaje este puede ser Java.
Figura 4
Representación de Metamodelo Nivel M2
Nota: Adaptado de Engineering & Science, 2006
1.4. Meta-metamodelo
El Meta-metamodelo, correspondiente al nivel M3 dentro de los niveles de MOF se utiliza para especificar los metamodelos. Para (Overbeek, 2006), “Un meta-metamodelo es un metamodelo especializado que describe otros metamodelos. La posición en la jerarquía de modelado define si un metamodelo es un meta-metamodelo.” (Giunchiglia, 2013) “El nivel de meta-metamodelo proporciona la base para las extensiones de metamodelo. El nivel de metamodelo proporciona construcciones para modelar entidades y conceptos de nivel de conocimiento”. En otra definición (Flatscher, 2002) “Los meta-metamodelos representan y especifican metamodelos; es decir, describen cuáles son los ingredientes válidos de un metamodelo”. En la Figura 5, se representa el meta-metamodelo a través de un nivel 3 donde se evidencia que en una clase tiene unas características que vienen hacer los atributos y operaciones y a la vez tienen sus propiedades.
Figura 5
Representación de Metametamodelo Nivel M3
Nota: Adaptado de (Engineering & Science, 2006) 1.5. Model Driven Architecture (MDA)
Model Driven Architecture (MDA, arquitectura dirigida por modelos), se define como un conjunto de estándares emergentes sobre cómo construir un conjunto de modelos, notaciones y reglas de transformación. Además, proporciona una base abierta, independiente del proveedor para la interoperabilidad del sistema a través del uso de estándares de modelado establecidos (OMG, 2019). MDA proporciona pautas para estructurar y organizar de mejor manera la arquitectura para el desarrollo de software; es así que para (Soley & OMG Staff Strategy Gropu, 2000), “MDA proporciona pautas para estructurar las especificaciones del software que se expresan como modelos”. Además, en la guía de MOF (Object Management, 2003) se menciona que “MDA es un enfoque para el desarrollo del sistema, que aumenta el poder de los modelos en ese trabajo”.
1.5.1. Características de MDA
De acuerdo a (Calic, 2008; Quintero & Anaya, 2007) MDA permite definir aplicaciones que pueden ser mantenidas y ofrecer flexibilidad siempre y cuando se tenga en cuenta las siguientes características:
• Implementación: Se puede implementar fácilmente una infraestructura a partir del diseño existente.
• Integración: Es más fácil integrar estándares para el diseño de arquitecturas.
• Mantenibilidad: Es mucho más fácil mantener un sistema debido a que abarca toda la información de la arquitectura.
• Testeo y simulación: Como se hace un desarrollo dirigido por modelos, se puede realizar pruebas haciendo uso de herramientas de especificación.
• Funcionalidad: El MDA especifica un modelo de plataforma y código fuente totalmente ejecutable.
• Interoperabilidad: Proporciona capacidades de interoperabilidad entre diferentes tecnologías.
• Abstracción: El MDA abstrae las aplicaciones de software en un nivel superior a través de modelos visuales.
• Adaptación: Las transformaciones se pueden usar para adaptar un sistema existente a otras plataformas existentes
• Representatividad: La representación de un modelo en MDA debe describirse por un lenguaje que tenga una sintaxis claramente definida.
• Transformaciones: El MDA tiene la noción de transformación del modelo; las transformaciones del modelo aparecen en cualquier nivel.
1.5.2. Ventajas y Desventajas de MDA
Los modelos tienen diferentes beneficios para el desarrollo de software los mismos que pueden ser adaptados a las necesidades o problemas que se puedan presentar, ya que por medio de representaciones o modelamiento describen la estructura del problema. A continuación, se exponen algunas ventajas y desventajas.
Ventajas.
• MDA no tiene un límite en el momento del desarrollo de aplicaciones de software, al contrario, se adapta para el desarrollo de otros modelos de sistemas.
• Los modelos PIM generan parte del código de tal manera que no es necesario tipear demasiado código.
• MDA se relaciona con un sin número de estándares, de los cuales hacemos mención los siguientes:
o Unified Modeling Language (UML), o Meta-Object Facility (MOF),
o eXtensible Markup Language (XML), o XML Metadata Interchange, (XMI)
o Enterprise Distributed Object Computing (EDOC), o el Software Process Engineering Metamodel (SPEM) o Java Metadata Interface (JMI)
o y el Common Warehouse Metamodel (CWM).
• Portabilidad e independencia de la plataforma.
• Aumentar el nivel de abstracción.
• Mayor facilidad de mantenimiento.
• Cada fase de desarrollo puede ser desempeñado por distintos expertos.
Desventajas.
• El modelo pierde su utilidad como representación simplificada si se pretende incluir en él toda la información del sistema.
• Tienen una acción recíproca, la cual permite solo interactuar y representan a ciertos aspectos del sistema en estudio.
• Limitación, el modelo encamina por una sola estructura propuesta.
• Personal, el personal debe tener un conocimiento mínimo para la realización de los modelos
• Capacidad de análisis, El personal que realiza el modelado no comprende el enfoque del problema.
• Funcionalidad, que el modelo no se acople a las necesidades de la situación propuesta.
• Hipótesis, no están bien claros o planteados la hipótesis del problema a resolver.
• Extensión, el Modelo puede ser demasiado extenso, respecto a la aplicación
1.5.3. Elementos de MDA
En la Figura 6 se representa los elementos o estándares establecidos por OMG respecto de MDA (Soley & OMG Staff Strategy Gropu, 2000), entre los que constan UML, MOF y CWM:
Figura 6
Model Driven Architecture (MDA)
Nota: Se presenta los estándares establecidos por la OMG (Soley & OMG Staff Strategy Gropu, 2000)
UML: Unified Modeling Language de OMG ayuda al modelo a especificar, visualizar y documentar modelos de sistemas de software, incluyendo su estructura y diseño, de manera que cumplan con todos estos requisitos. (Siau & Cao, 2011)
MOF: Meta Object Facility, un estándar OMG adoptado (última revisión MOF 1.4) (Engineering & Science, 2006) proporciona un marco de gestión de metadatos y un conjunto de servicios de metadatos para permitir el desarrollo y la interoperabilidad de los sistemas basados en modelos y metadatos.
CMW: Common Warehouse Metamodel facilita el intercambio de metadatos en inteligencia de negocios y de almacenamiento entre herramientas, las plataformas y repositorios de metadatos en entornos distribuidos diversamente (Bézivin, 2005).
1.5.4. Model Driven Development (MDD)
El desarrollo de software dirigido por modelos (en inglés Model Driven software Development, MDD) propone un nuevo mecanismo de construcción de software a través de un proceso guiado por modelos que van desde los más abstractos a los más concretos. Para (Hailpern & Tarr, 2006) “El desarrollo de software dirigido por modelos (MDD) es un enfoque de ingeniería de software que consiste en la aplicación de modelos y tecnologías modelo para elevar el nivel de abstracción en el que los desarrolladores crean y evolucionan software, con el objetivo de simplificar (hacer más fácil) y formalizar (estandarizar, esa automatización es posible) las diversas actividades y tareas que componen el ciclo de vida del software”.
La función principal que cumple el MDD es tratar de minimizar los costos y tiempo de desarrollo de las aplicaciones de software, consecuentemente, son necesarios esfuerzos que conviertan a MDD en una propuesta coherente, para cualquier desarrollo, la misma que es soportada por técnicas y herramientas maduras. Las transformaciones entre modelos requieren de lenguajes específicos para su definición. Estos lenguajes deben tener base formal, por ejemplo, contar con un metamodelo que los sustente, y permitir un tratamiento
automatizado (Pascuas Rengifo, 2017). MDD posee ciertas características que lo identifican las cuales se las presenta a continuación.
1.5.5. Características de MDD
Entre los beneficios que presenta una aplicación que se construye siguiendo un desarrollo de software dirigido por modelos (Martinez, 2013) (Sendall & Kozaczynski, 2003) (Mellor, 2003) estos autores mencionan los siguientes:
• Reutilización: El MDD permite la reimplementación a nivel de dominio en otras tecnologías.
• Optimización: Incrementa la calidad a medida que los modelos se optimizan continuamente.
• Reduce los costos: El MDD tiene un costo más económico debido a que utiliza un modelo automatizado.
• Solución de software: Incrementa la permanencia para dar soluciones de software.
• Facilita el intercambio: Con el MDD los conceptos modelo y notación proporciona un mejor intercambio entre sí.
• Transformación de modelos: Menciona explícitamente en dos de las estrategias principales para la transformación de modelos definidas en la Guía del usuario de MDA.
• Sintaxis: El enfoque MDD se basan en modelos que necesitan ser sintácticamente correctos
• Semántica: Los modelos para aplicar MDD son semánticamente precisos, consistentes entre sí y completos.
• Abstracción: Permite al desarrollo MDD un mayor nivel de abstracción.
• Lenguaje de programación: El MDD utiliza conceptos más cercanos para el dominio del problema, en lugar de lenguajes de programación.
1.5.6. Ventajas y desventajas de MDD
En la Tabla 1, se exponen algunas de las ventajas y desventajas que los autores (Atkinson, Colin; Kühne, 2003) (Selic, 2003) (Sheng & Benatallah, 2005) (Hailpern & Tarr, 2006) (Steffen et al., 2008) (Schaefer, 2010) exponen cuando se trabaja con MDD:
Tabla 1Ventajas y desventajas de Model Driven Development
VENTAJAS DESVENTAJAS
Productividad: El MDD mejora la productividad a corto plazo al aumentar un software primario en términos de funcionalidad.
Establecimiento de un elemento: No existe un principio explícito para juzgar a qué nivel debe residir un elemento en particular.
Sensibilidad: Permite reducir la sensibilidad de los artefactos primarios al cambio.
Conceptos predefinidos: Existe una preferencia por usar la descripción del nivel meta (a veces en forma de estereotipos).
Modelación de conceptos: Facilita extensiones de usuario dinámicas para modelar conceptos, notación de modelo y los modelos creados a partir de ellos
Uso: No presenta un uso formal de los modelos
Asignación predefinida: Permite realizar asignaciones predefinidas asociadas.
Técnica: El MDD presenta un uso informal de las técnicas de modelado
Caracterización: Con el MDD se puede usar modelos para caracterizar por completo un sistema.
Lenguaje: El MDD realiza técnicas de lenguajes inconsecuente
Representación: En el MDD los diagramas pueden reemplazar el código para obtener un mejor modelo.
Herramientas: Los instrumentos que utiliza el MDD deben ser capaces de soportar la automatización de las transformaciones de modelos.
Transformación: El MDD transforma automáticamente los modelos en binarios ejecutables.
Representación intermedia: la herramienta puede exportar el modelo en una forma estándar, típicamente XML.
Lenguaje: El lenguaje de MDD es interpretativo intuitivamente a partir del contexto del sistema.
Combina transformaciones: Permite combinar las transformaciones para formar modelos compuestos.
Manipulación directa del modelo: Las herramientas ofrecen a los usuarios acceso para una representación del modelo interno, y la capacidad de manipular dicha representación.
Nota: En la siguiente tabla se expone las descripciones de Ventajas y desventajas de MDD 1.5.7. Ciclo de vida de MDD
El ciclo de vida muestra los tipos de artefactos que se crean durante el proceso de desarrollo de software, estos modelos son formales, es decir, son modelos que pueden ser comprendidos por equipos de cómputo. Según (Pons, Claudia, Giandini & Pérez, 2010) los modelos son una representación conceptual o física a escala de un proceso o sistema, con la finalidad de analizar su naturaleza, desarrollar o comprobar hipótesis. El MDD asemeja distintos tipos de modelos: modelos con alto nivel de abstracción, según (Pascuas Rengifo, 2015) son modelos que elevan el nivel de desarrollo del software y reducen las diferencias entre los dominios de la tecnología. Entre los tipos de modelos presentamos CIM, PIM y PSM.
• CIM (Computationally Independent Model), presenta los modelos independientes de la computación que caracterizan el dominio del problema.
• PIM (Platform Independent Model), el Modelo Independiente de la Plataforma, representa los modelos que describen una solución de software que no contiene detalles de la plataforma concreta en donde la solución va a ser implementada.
• PSM (Platform Specific Model), el Modelo Especifico de la plataforma son los modelos derivados de la categoría anterior, que contienen detalles de la plataforma o tecnología con que se implementará la solución.
PIM, es trasformado en uno o más PSM’s, lo que se interpreta aquí es que MDD permite especificar para cada plataforma un PSM específico. Esto quiere decir que el principio básico de MDD parte de la transformación entre modelos, para de esta manera los modelos puedan pasar de ser entidades contemplativas a entidades productivas.
En la Figura 7 se identifican las fases principales del ciclo de vida de desarrollo MDD:
Figura 7
Ciclo de vida MDD
Nota: Se hace conocer el ciclo de vida de MDD, tomado de (Pascuas Rengifo, 2017) 1.5.8. Beneficios de MDD
Uno de los beneficios que ofrece MDD, es que, se considera como un nuevo paradigma para el desarrollo de software basado en modelos, como principal elemento del proceso de desarrollo como, por ejemplo, código generado (semi automáticamente a partir de modelos).
MDD es una aproximación al desarrollo de software basado en el modelado del sistema y su generación de código a partir de los modelos. Al hablar de aproximación, este solo ofrece una estrategia general a seguir en el desarrollo de software, pero MDD no define ninguno de los siguientes enunciados: técnicas para utilizar, fases del proceso y guía metodológica.
De esta manera MDD proporciona una mejor optimización de los procesos de desarrollo de software, para ello MDD presenta los siguientes objetivos:
• Analizar de manera conceptual las técnicas de modelado de software
• Estudio, elaboración y formalización de lenguajes para crear modelos de software.
• Catalogación y formalización de mecanismos de transformación entre modelos.
• Definición y formalización de lenguajes para describir transformaciones.
• Implementación de herramientas de software automáticas.
1.5.9. Aspectos en los que MDD mejora el proceso
Para el desarrollo de una aplicación es muy importante tomar en cuenta los aspectos en los que va a mejorar y optimizar los procesos. En el caso de MDD se considera que contribuye a mejorar el proceso de desarrollo de software en los siguientes aspectos:
• Productividad. El desarrollo de software basado en modelos se ha comprobado que mejora la productividad global del proyecto, ya que una de las etapas del desarrollo de un sistema es el diseño y con una buena abstracción de modelamiento se aplican los mismos modelos para desarrollo de software, permitiendo ahorrar el tiempo de codificación y especialmente la etapa de mantenimiento, ya que introducir modificaciones sobre los modelos es mucho más rápido y fácil que hacerlo sobre el código.
• Portabilidad. La transformación de los modelos permite que sea independiente a las tecnologías. Este aspecto es muy relevante ya que, en el transcurso del tiempo, se van presentando nuevas tendencias tecnológicas y los sistemas deben acoplarse a las mismas. MDD hace que sea más fácil la portabilidad, es decir que una vez que se obtiene los modelos estos se los puede transportar a una herramienta que permita trabajar con las tecnologías de la actualidad.
• Re-uso: Después de elaborar los modelos con todas sus características y requerimientos de una manera correcta, se podría decir que es posible usar estos modelos para desarrollar los nuevos sistemas ya sea por partes o de una manera completa.
• Interoperabilidad: En los últimos años el desarrollo exige que los sistemas tengan la característica de interoperabilidad; MDD tiene a su favor esta característica entre sistemas heterogéneos, ya que da paso a la especificación de las conexiones entre las distintas tecnologías.
1.6. Model Driven Engineering (MDE)
El Model-Driven Engineering (MDE) tiene como objetivo hacer que la lógica comercial y la propiedad intelectual sean resistentes a los cambios tecnológicos al cambiar el enfoque del desarrollo de software de la codificación al modelado (Cicchetti et al., 2008). Acorde a (A.
van Deursen et al., 2007) MDE se define “como la unificación de iniciativas que apuntan a mejorar el desarrollo de software mediante el empleo de modelos específicos de alto nivel en la implementación, integración, mantenimiento y prueba de sistemas de software”, En otra definición (Overbeek, 2006) MDE, “Es la colección de todos los enfoques que usan modelos como principio básico para la ingeniería de software”, con estas definiciones se puede concluir que el Model-driven engineering (MDE) es una metodología que permite por medio del uso de modelos mejorar el desarrollo de software, de una manera rápida y con una calidad mejorada.
1.6.1. Características de MDE
Los autores (Favre, 2004) (Whittle, 2014) (Vanderdonckt, 2008) consideran que la ingeniería dirigida por modelos tiene los siguientes beneficios:
• Combina Procesos: Permite combinar procesos y análisis con arquitectura del servicio.
• Dominio: Permite trabajar con lenguajes de dominio específico.
• Complejidad: Reduce la complejidad de las plataformas.
• Corrobora modelos: Permite validar los modelos.
• Integración de herramientas: Integra las herramientas y permite generar diversos artefactos.
• Acelera la automatización: El MDE permite agilizar la automatización y la ejecución teniendo una mayor productividad.
• Lenguaje: MDE se describe en lenguaje natural o, en el mejor de los casos, usando diagramas UML incompletos.
• Espacios tecnológicos: El MDE es un enfoque abierto e integrador que abarca espacios tecnológicos (TS) de una manera uniforme.
• Integración: El MDE crea puentes entre los espacios tecnológicos y en la integración de los cuerpos de conocimiento desarrollado por diferentes comunidades de investigación.
• Interfaz: El MDE describe una interfaz de usuario y los aspectos implicados en ella, a partir de los modelos, se produce una interfaz final.
1.6.2. Ventajas y Desventajas de MDE
En la tabla 1, se exponen algunas de las ventajas y desventajas de MDE propuestas por los autores (Bézivin, 2006) (Whittle et al., 2014) (France & Rumpe, 2007) (Favre, 2004) (Kent, 2002) (Vanderdonckt, 2008).
Tabla 2. Ventajas y desventajas Model Driven Engineering (MDE)
Ventajas Desventajas
Automatización: Los modelos de MDE son lo suficientemente precisos para estar sujetos a la automatización.
Diagramas inconsistentes: Los diagramas que utiliza el MDE para el lenguaje son en la mayoría de las veces inconsistentes.
Procedimiento: El MDE combina procesos y análisis con arquitectura.
Accesibilidad: Desarrollar un modelo MDE no es lo bastante fácil para los desarrolladores.
Domino: Los modelos MDE siguen Complejidad: Es muy difícil entender
paradigmas de modelado específicos del dominio.
cómo se relacionan los conceptos básicos de MDE.
Generación de código: MDE genera códigos que brindan los beneficios, incluida la productividad.
Asignación: Es dificultoso asignar los Espacios Tecnológicos existentes en el MDE.
Arquitectura explícita: MDE facilita la definición de arquitecturas explícitas, especialmente cuando es un esfuerzo inicial.
Megamodelo MDE: En el MDE megamodelo no es totalmente coherente con el texto y proporciona respuestas incorrectas.
Abstracción: Los desarrolladores se encuentran reconociendo fragmentos de código similares que luego se abstraen en una DSL y escribe un generador.
Modelos Incompletos: En algunos casos los modelos desarrollados por MDE son incompletos, por lo que no los describe con precisión.
Arquitectura del sistema: El modelo MDE realiza una separación de preocupaciones, es decir, una división de lo simple y lo complejo, generando una comprensión más profunda.
Estructuración: El MDE puede presentar en algunos casos procedimientos de desarrollo establecidos mal identificado.
Eficiencia: MDE se comercializa como una tecnología que puede hacer las mismas cosas de manera más rápida y económica.
Imprevisibilidad: Es dificultoso entender y controlar cómo las especificaciones están conectadas con la interfaz final del MDE. Por lo tanto, los resultados pueden ser impredecibles.
Creatividad: Los desarrolladores perciben que el MDE restringirá su creatividad ya que automatiza muchas tareas.
Umbral alto: Los diseñadores necesitan aprender un nuevo idioma para expresar las especificaciones de la interfaz de
usuario.
Desarrollo: Los sistemas de MDE pueden evolucionar fácilmente para satisfacer los requisitos de los usuarios en constante evolución.
Falta de propagación de modificaciones: En el modelo MDE es complicada la modificación realizada en un modelo dado sobre los otros modelos.
Nota: Se describen las ventajas y desventajas de Model Driven Engineering 1.7. Lenguajes de Modelado
1.7.1. Domain Specific Languages (DSL)
El DSL según (Jácome, 2013), es “de un propósito determinado, cuya representación puede ser gráfica o textual, adaptado a problemas concretos de un dominio”. En otra definición (Fowler M, 2010), (Arie van Deursen, Klint, & Visser, 2000) DSL es “un lenguaje pequeño, generalmente declarativo, que ofrece un poder expresivo centrado en dominio del problema particular. En muchos casos, los programas DSL se traducen a llamadas a una biblioteca de subrutina común y la DSL se puede ver como un medio para ocultar los detalles de esa biblioteca”. A continuación, se dará a conocer las características de una DSL.
Características.
Los autores (Mernik, 2005) (Karsai, 2014) (Kosar, 2010) exponen algunas de las características de un DSL.
• Generación de código: Genera código de programa en otro programa o ejecutable.
• Diagrama: El lenguaje DSL posee un esquema de visualización más accesible.
• Semántica: El DSL proporciona notación semántica bien definida.
• Accesibilidad: El DSL es más fácil de entender, no solo para los programadores.
• Biblioteca de aplicaciones: Permite combinar con una biblioteca de aplicaciones.
• Dominio: Un DSL ofrece notaciones específicas de dominio apropiadas desde el comienzo.
• Utilización: El uso de una DSL ofrece posibilidades de análisis, verificación, optimización, paralelización y transformación en términos de construcciones DSL.
• Elaboración: El DSL tiene un carácter más declarativo y una semántica de ejecución menos definida en lo que respecta a los detalles de las aplicaciones generadas.
• Sintaxis: El formalismo de especificación de sintaxis de una DSL con un carácter puramente declarativo puede actuar como un lenguaje de entrada para un generador de analizador.
• Idioma: El idioma existente de DSL se usa parcialmente, se extiende y usa especialización.
1.7.2. Janus Transformation Language (JTL)
El Lenguaje de Transformación de Janus (JTL) es un lenguaje de transformación de modelo declarativo específicamente diseñado para admitir la bidireccionalidad y la propagación de cambios. La implementación del lenguaje se basa en la programación del conjunto de respuestas (ASP) (Cicchetti, Antonio; Ruscio, Davide Di; Eramo, Romina;
Pierantonio, 2010). Según (Eramo, Romina; Pierantonio, Alfonso; Rosa, 2014) “JTL es un lenguaje de transformación de modelos basado en restricciones específicamente diseñado para admitir la bidireccionalidad”. Algunas de las características de JTL se mencionan a continuación.
Características
• Mapeo: Permite mapear un modelo en un conjunto de modelos.
• Bidireccionalidad: El lenguaje JTL proporciona soporte a la bidireccionalidad dentro del sistema.
• Semántica: La semántica de JTL asegura que todos los modelos se computen independientemente.
• Modificación: Permite que los modelos objetivos se puedan modificar manualmente.
• Coordinación: JTL se basa en una sintaxis y semántica enriquecida con cuantificadores y coincidencia de patrones que eliminan por completo la necesidad de llamadas recursivas.
• Programación orientada a aspectos: JTL sirve como un poderoso sustituto de la sintaxis de corte de puntos de ASPECTJ
• Programación genérica: Para su uso JTL expresa las condiciones que componen los conceptos, y en particular los conceptos de tipo múltiple.
• Explicativo: JTL tiene la sintaxis y la semántica simples y concisas de la programación lógica para realizar consultas de bases de datos.
• Lenguaje: JTL presenta un conjunto de predicados nativos, con una biblioteca de predicados predefinidos construidos sobre los nativos.
• Programación lógica: JTL presenta construcciones específicas para la manipulación de conjuntos, la cuantificación y otros medios que eliminan gran parte de la necesidad de bucles.
Los autores (Cicchetti, Antonio; Ruscio, Davide Di; Eramo, Romina; Pierantonio, 2010;
Cohen, 2006; Eramo, 2014), mencionan algunos beneficios del Lenguaje de Transformación de Janus que se los menciona a continuación:
1.7.3. UML (Unified Modelling Language)
UML es un lenguaje de modelado con una sintaxis semiformal y semántica. Se define dentro de una arquitectura de metamodelado general de cuatro niveles MOF. Los niveles de modelo y metamodelo son las más relevantes para modelar arquitecturas de software en UML.
La especificación del Object Management Group (OMG) establece que:
“El Lenguaje de modelado unificado (UML) es un lenguaje gráfico para visualizar, especificar, construir y documentar los artefactos de un sistema de software intensivo. El UML ofrece una forma estándar de escribir los planos de un sistema, incluidos aspectos conceptuales como procesos de negocios y las funciones del sistema, así como cosas
concretas, como declaraciones de lenguaje de programación, esquemas de base de datos y componentes de software reutilizables”.
Martin Fowler, en su libro UML Distilled, observa que, aunque UML es un sistema de notación que permite a las personas comunicarse sobre un modelo, se desarrolla a partir de metodologías que también describen los procesos en el desarrollo y uso del modelo. Si bien no hay un solo proceso aceptado, los colaboradores de UML describen enfoques algo similares y, por lo general, se describen junto con tutoriales sobre el propio UML. A continuación, se exponen algunas características de UML.
Características
La aplicación del lenguaje de modelado UML para interpretar los diferentes modelos, presenta las siguientes características:
• Diagramación de comportamiento. Incluye características de comportamiento de un sistema o proceso empresarial. Esto incluye la actividad, la máquina de estado y los diagramas de casos de uso, así como los cuatro diagramas de interacción.
• Diagramas de estructura. Un tipo de diagrama que describe los elementos de una especificación que son independientemente del tiempo. Esto incluye diagramas de clase, estructura compuesta, componente, implementación, objeto y paquete.
• Funcionalidad. Muestra la funcionalidad del sistema desde el punto de vista del usuario.
• Estructura. Muestra la estructura y subestructura del sistema usando objetos.
• Modelo dinámico. Muestra el comportamiento interno del sistema.
• Actores. Un rol que desempeña un usuario con respecto al sistema, incluidos los usuarios humanos y otros sistemas. Por ejemplo, objetos físicos inanimados (por ejemplo, robot);
Un sistema externo que necesita alguna información del sistema actual.
• Caso de uso. Un conjunto de escenarios que describen una interacción entre un usuario y un sistema, incluidas alternativas.
• Límite del sistema. diagrama de rectángulo que representa el límite entre los actores y el sistema.
1.8. Transformaciones
Las transformaciones son el proceso en donde se toma un modelo de entrada y se produce otro modelo como salida. Las transformaciones de modelo a modelo apuntan al refinamiento de los modelos, su refactorización de ingeniería inversa, la aplicación de patrones, la generación de vistas de nuevos modelos (PIM a PIM), las trasformaciones de PIM a PSM o cualquier actividad de ingeniería de modelos que se pueda automatizar. Se describe a continuación las siguientes transformaciones, model to model (M2M), model to text (M2T) y text to model (T2M)
1.8.1. Model to Model (M2M)
Es una técnica independientemente, proporciona un paradigma y lenguaje declarativo o imperativo para especificar transformaciones de modelos. Los lenguajes declarativos describen las relaciones entre variables en términos de reglas o reglas de inferencia, que son las que se presentan a un algoritmo con un motor de inferencia para producir un resultado.
1.8.2. Model to Text (M2T)
Las transformaciones de modelo a texto apuntan a la generación de código o documentación (por ejemplo, Java, XML, HTML). Las técnicas M2T se pueden clasificar en (Pascuas Rengifo et al., 2017)
• Enfoques basados en visitantes; atraviesan la representación interna de un modelo (árbol de sintaxis abstracta) y escriben el código en una secuencia de texto.
• Enfoques basados en plantillas; se basan en la construcción de platillas, que consisten en el texto de destino que contiene segmentos de información de acceso a meta código del modelo de origen.
1.8.3. Text to Model (T2M)
Se utilizan normalmente para ingeniería inversa, por ejemplo, para transformar aplicaciones heredadas en modelos en el caso de la modernización de software basada en modelos, como por ejemplo MoDisco.
Una vez que se han expuesto los conceptos relacionados con MDA, MDD, MDE, lenguajes de transformación o lenguajes de modelado en el capítulo se 2 se muestra la investigación de las herramientas de modelado de las cuales seleccionaremos algunas de ellas para su evaluación.
Capítulo dos
Herramientas de Modelado y Análisis de Caso de Estudio 2.1. Introducción
En el presente capítulo se detallan las herramientas de modelado, funcionamiento y utilización, la mayoría de los desarrolladores de software trabajan con su editor de texto favorito desarrollando aplicaciones donde compilan, realizan cambios, testeo, y sucesivamente hasta que el software se encuentre funcional. Estas herramientas han sido investigadas en diferentes bibliografías, con el propósito de que den soporte a la creación de modelos y transformaciones.
A menudo, se utilizan los métodos de desarrollo de software con una metodología tradicional, sin embargo, esos fundamentos y decisiones de diseño son críticos para el éxito de un producto de programación de largo plazo y de alta calidad. A sí mismo, el propósito de este capítulo es analizar un caso de estudio estructurado para identificar una herramienta de modelado efectiva.
2.2. Herramientas de modelado
Las herramientas MDD se han creado desde el principio con la intención de automatizar el proceso de desarrollo, su función principal es permitir la especificación de sistemas software (para generar código y documentación). Con el tiempo todas las herramientas de modelado han incorporado funcionalidades de generación de código. A continuación, se exponen algunas de las herramientas de modelado que han sido resultado de la investigación para el presente trabajo de titulación: Eclipse Modeling Framework (EMF), MoDisco, ArcStyler, AndroMDA, OptimalJ, Codagen Architect y Microsoft DSL Tools.
2.2.1. Eclipse Modeling Framework (EMF)
Para (Pons, 2010) EMF “es un marco de modelado y una instalación de generación de código para crear herramientas y otras aplicaciones basadas en un modelo de datos estructurados”. A partir de una especificación de modelo descrito en XMI predeterminado y
una API reflexiva muy eficiente la cual manipula genéricamente objetos EMF. EMF proporciona herramientas y soporte de tiempo de ejecución para producir un conjunto de clases Java para el modelo, junto con un conjunto de clases de adaptador que permiten la visualización y la edición del modelo basado en comandos, y un editor básico. Es por ello que se toma como una de las primeras herramientas para realizar un análisis de su funcionamiento y también analizar el proceso de trabajo de la misma y sus resultados.
La creación de metamodelos con EMF y Ecore, representa un centro de la plataforma Eclipse para el desarrollo dirigido por modelos, así mismo permite importar modelos que han sido previamente especificados usando documentos Ecore, donde EMF predispone mecanismos de interoperabilidad con varias herramientas y aplicaciones.
2.2.2. MoDisco.
Según (Bruneli & Bruneli, 2016) MoDisco se ha creado para abordar diferentes tipos de sistemas heredados y para abordar diferentes procesos de ingeniería inversa (basados en modelos) como la migración técnica/funcional, la refactorización, la documentación retroactiva y la garantía de calidad.
Además, MoDisco, brinda un marco extensible para desarrollar herramientas basadas en modelos o desarrollo por modelos para soportar casos de uso de la modernización de software existente:
MoDisco es considerado por el Grupo de Trabajo de Modernización Dirigida por Arquitectura (ADM) de OMG como el proveedor de referencia para implementaciones reales de varios estándares, como: Metamodelo de descubrimiento de conocimiento (KDM), Metamodelo de medición de software (SMM) y Metamodelo abstracto del árbol de sintaxis (ASTM). Además, proporciona un soporte avanzado para las tecnologías Java, JEE y XML, incluidos los metamodelos completos, los descubridores y generadores correspondientes, las personalizaciones, las bibliotecas de consultas, etc.
2.2.3. ArcStyler
Según los autores (Aldrich, Chambers, & Notkin), mencionan que ArcStyler es un sistema basado en uso de cartuchos para realizar la descripción de transformaciones que permite generar aplicaciones de n capas codificadas en java/J2EE y c#/.NET a partir de diagramas UML y la especificación de los procesos del negocio.
Arctyles además permite extender las capacidades de transformación, generando nuevos cartuchos a partir de UML, cuyo objetivo sea cualquier plataforma o lenguaje. Una de las deventajas es que No soporta diagramas de componentes ni diagramas de despliegue, pero admite código propio para la generación de código. ArcStyler de iO-Software es una herramienta MDA que también utiliza MOF para soportar estándares como UML y XMI, además, JMI para el acceso al repositorio de modelos.
Integra herramientas de modelado (UML) y desarrollo (ingeniería inversa, explorador de modelos basado en MOF, construcción y despliegue) con la arquitectura CARAT que permite la creación, edición y mantenimiento de cartuchos MDA (MDA-Cartridge) que definen transformaciones, incluye herramientas relacionadas con el modelado del negocio y el modelado de requisitos por lo que cubre todo el ciclo de vida (Warmer Jos, Kleppe Anneke, 2003).
2.2.4. OptimalJ
Este producto de la compañía Compuware genera aplicaciones J2EE partiendo de los modelos. Implementa completamente la especificación MDA, se encuentra desarrollado en Java, permitiendo que sea portable a cualquier plataforma para su ejecución (Corredera de Colsa Luis Enrique, 2007).
Admite XMI versión 1.1 tanto para la importación de ficheros como para su salida.
OptimalJ es una herramienta MDA que utiliza MOF para soportar estándares como UML y XMI. Se trata de un entorno de desarrollo que permite generar aplicaciones J2EE completas a partir de un PIM.
Del proceso de modelado o desarrollo con OptimalJ se puede destacar:
• Generación automática a partir del PIM de los modelos PSM de la capa de presentación (web), capa de negocio EJB y base de datos, estableciendo la conexión (puentes) entre las tres capas.
• Distinción entre bloques libres y protegidos en el código para impedir la modificación del código generado.
• Interoperabilidad, esta herramienta nos permite exportar e importar modelos vía XMI (especificación para el intercambio de Diagramas) de manera sencilla, en formato de fichero.
2.2.5. Codagen Architect
Según (Aldrich, Chambers, & Notkin) el lenguaje ArchJava está destinado a investigar beneficios y desventajas de una parte relativamente inexplorada del espacio de diseño ADL.
Nuestro enfoque amplía un lenguaje de implementación eficientemente práctico para incorporar características arquitectónicas y hacer cumplir la integridad de la comunicación.
Así mismo menciona que los beneficios clave que esperamos obtener con este enfoque incluyen una mejor comprensión del programa, un razonamiento arquitectónico confiable sobre el código manteniendo la arquitectura y código coherentes a medida que evolucionan alentando a más desarrolladores aprovechar la arquitectura del software.
Para permitir que los programadores describan la arquitectura del software, ArchJava agrega nuevas construcciones de lenguaje para admitir componentes, conexiones y puertos.
2.2.6. Microsoft DSL Tools
Según (Ozg & T., 2007), La visión de modelado de Visual Studio 2005 Team System es cambiar la forma en que los desarrolladores perciben el valor del modelado. Los modelos no deberían ser solo una pieza de documentación que espera quedar desactualizada. Cuando los modelos se consideran artefactos de desarrollo de primera clase, los desarrolladores
escriben código fuente menos convencional debido a las abstracciones de alto nivel que se emplean. Además, otros involucrados en el desarrollo, como analistas de negocios, arquitectos y diseñadores, percibirán que el modelado agrega valor a sus tareas.
Una vez que se ha realizado la búsqueda exploratoria para conocer las herramientas de MDD, en la Tabla 3 se presenta una comparativa de las herramientas y sus lenguajes que usan como parte de MDD para luego seleccionar unas de ellas y realizar las pruebas con los diferentes escenarios tomando en cuenta el prototipo propuesto.
Tabla 3
Comparación de herramientas MDD
HERRAMIENTAS EMF
Eclipse Modeling Framework
MoDisco ArcStyler OptimalJ Codagen
Architec
Microsoft DSL Tools
Entrada UML UML UML XMI XMI UML
Lenguaje de salida Java Java, JEE (Incluye JSP)
Java, .Net Cualquier lenguaje de
programación.
J2EE (Java) Java Visual Basic.
Java.
Estándares XMI, XML, UML XMI, UML, XML XMI, UML, JMI XMI, UML. UML UML, XML.
Soporte CIM X X X
Soporte PIM X X X X X
Soporte PSM X X X X
CIM a PIM
PIM a PSM X X X X
PIM a Código X X X
PSM a Código X X X
Consistencia X
Trazabilidad X X X
Nota: En esta tabla se describen las herramientas con respecto al modelado.
De acuerdo con la Tabla 3 identificamos 6 herramientas en donde las características que se van a evaluar se describen en las filas y los nombres de las herramientas se describen en las columnas.
• Las transformaciones directas de PIM a código, se encuentran en la intersección de una fila y una columna por ejemplo (EMF, ArcStyler y Codagen Architect).
• De las herramientas detalladas ninguna tiene soporte a todos los modelos MDA, solamente soportan PIM y PSM y la única que se considera al CIM (Modelos de Información Común).
• Algunas herramientas especifican la consistencia y otras la definen de manera ligera. Las herramientas que se identifican por esta característica son OptimalJ.
• La trazabilidad es un punto muy importante y solo algunas de las herramientas la consideran con mayor eficiencia ya tiene mucho significado en cuanto a la búsqueda y corrección de errores y cabe recalcar que es un ítem necesario para realizar las transformaciones, dos de las herramientas que posee esta característica son EMF (Eclipse Modeling Framework).
• La base del estándar MDD es UML, MOF y XMI, es prescindible que las herramientas se consideren estos estándares para encontrar uniformidad en la interpretación del enfoque MDD, las herramientas a las cuales se hace mención son EMF y MoDisco.
• Símbolos: La “X” significa que cumple la característica al 100%
2.3. El ciclo de vida MDD aplicado a un caso de estudio.
El ciclo de vida MDD como se mencionó en el fundamento teórico, comprende de las siguientes fases: Requisitos, Análisis, Diseño Automático, Codificación Automática, Testeo Automático y Despliegue. En cada una de las fases se hace uso de un conjunto de actividades y herramientas que soportan el desarrollo de software dirigido por modelos (Ver Figura 8).
