Desarrollo De Herramienta Para Arquitectura Dirigida Por Modelos JMDA Versión 2.0 Modulo PSM-Código Fuente

UNIVERSIDAD CENTRAL “MARTA ABREU” DE LAS VILLAS

FACULTAD MATEMÁTICA FÍSICA Y COMPUTACIÓN

INGENIERÍA INFORMÁTICA

Trabajo de Diploma

Desarrollo de Herramienta para Arquitectura Dirigida por Modelos JMDA versión 2.0 Modulo PSM-Código Fuente

Autor: Miguel Ángel Montiel Peña Tutor: Dr. Rosendo Moreno Rodríguez

Dictamen

Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de Ingeniería Informática, autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.

______

Firma del Autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.

______

Firma del tutor Firma del Jefe de Laboratorio

Pensamiento

“El hombre inteligente no es el que tiene muchas ideas, sino el que sabe sacar provecho de las pocas que tiene.”

Emile Chartier

Dedicatoria

A mi mamá por estar a mi lado en todo momento, a mi padre y hermanos que a pesar de a distancia están presentes.

III

Agradecimientos

A todas las personas que me tendieron la mano, contribuyendo de una u otra forma a la realización de este trabajo. A todas muchas gracias:

A mi tutor Rosendo por su sabiduría, paciencia y comprensión para la realización de este trabajo.

A Víctor, Lester y a Elizabeth por su amistad y apoyo incondicional.

A Ita y Aníbal por estar donde los he necesitado

A todos mis amigos de la vocacional y del aula por los buenos momentos que compartimos y por haber sido mi otra familia durante estos cinco años. A mi familia; por estar junto a mí en los momentos más difíciles

Resumen

En el presente trabajo se hace una descripción acerca de los elementos representativos dentro del marco que aborda el concepto Arquitectura Dirigida por Modelos, la cual representa un nuevo enfoque de trabajo, que juega un papel importante en el proceso de desarrollo de software como un nuevo paradigma de creación de software en el que los modelos guían el proceso de desarrollo.

La tarea más complicada de esta nueva metodología es la transformación entre modelos que se sustenta en la definición de las reglas para convertir un modelo de un nivel de abstracción a otro, basándose en lenguajes y mecanismos estándares.

Estudios previos efectuados sobre las herramientas que soportan esta metodología han demostrado que aún no existe un software que sea puramente MDA. Por lo que en el Centro de Estudios de Informática de la UCLV el Dr. Rosendo Moreno se dio a la tarea de crear una herramienta MDA propia (JMDA), de la cual este trabajo presenta una segunda versión, centrando sus esfuerzos en tratar de establecer la conversión automatizada de una serie de modelos UML desde el nivel específicos de la plataforma (PIM) a generar código fuente, que en este caso se orientó fuese basado en Java.

Abstract

The present work make a description about the representative elements within the frame that takes the concept Model-Driven Architecture , which represents a new focus of work, that play it an important role in the process of software development like a new paradigm of creation of software where the models direct the process of development.

The more complicated task of this new methodology is the transformation between models that it´s held in the definition of the rules to convert a model of a level of abstraction to other, being based on languages and standards mechanisms.

Previous studies made on the tools that support this methodology have proven that not yet software that MDA be purely exists. For that in Studio’s Center of Informatics of the UCLV the Dr. Rosendo Moreno told someone to create a MDA tool (jMDA), the one that this work presents a second version of, centering his efforts in being about UML from the level of the platform specific to establish the conversion automatized of a series of models (PIM) to generate source code, the fact that in this case you got your bearings go based in Java.

Tabla de contenido

Introducción ...... 1 Capítulo 1. Análisis y fundamentación teórica ...... 5 1.1 Antecedentes ...... 5 1.2 Conceptos fundamentales ...... 5 1.3 Arquitectura Dirigida por Modelos ...... 6 1.3.1 ¿Qué es MDA? ...... 7 1.4 Proceso de desarrollo basado en modelos ...... 8 1.5 Modelo de plataforma ...... 11 1.6 Proceso de desarrollo MDA ...... 11 1.6.1 Transformación de Modelos...... 12 1.6.1.1 Definición de Transformación ...... 14 1.6.1.2 Métodos de transformación ...... 16 1.6.1.3 Características deseables de las transformaciones ...... 16 1.6.2 Reúso de modelos...... 19 1.7 Principios de MDA ...... 19 1.8 Estándares utilizados por MDA...... 20 1.8.1 UML ...... 20 1.8.2 Perfiles...... 20 1.8.3 Meta Object Facility (MOF) ...... 21 1.8.4 QVT (Queries/Views/Transformations): ...... 22 1.8.6. XMI...... 22 1.8.7. XSLT...... 23 1.9 Beneficios de MDA ...... 23 1.10 Herramientas CASE tradicionales ...... 24 1.10.1 ArgoUML ...... 24 1.10.2 Rational Rose Enterprise ...... 26 1.10.3 Visual Paradigm ...... 27 1.11 Herramientas CASE que implementan la aproximación MDA ...... 29 1.11.1 AndroMDA ...... 29 1.11.2 OptimalJ: ...... 31 1.11.3 IBM Rational Software Architect (RSA) ...... 33 1.11.4 JMDA v1.0 ...... 35 1.11.5 Valoración ...... 36 1.12 Tecnologías Utilizadas ...... 37 1.12.1 NetBeans IDE ...... 37 1.12.2 XPath: ...... 38

VII

Tabla de contenido

1.13 Conclusiones del capítulo ...... 38 Capítulo 2. Aspectos del análisis, diseño e implementación ...... 39 2.1.1 Requisitos funcionales del sistema ...... 39 2.1.2 Requisitos no funcionales del sistema ...... 39 2.2.1 Casos de Uso y Actores de la Herramienta JMDA versión 2.0 ...... 40 2.2.2 Diagrama de actividades del sistema ...... 42 2.2.3 Diagrama de clases del diseño ...... 42 2.2.4 Diagrama de secuencias para el escenario: Importar archivo XMI ...... 44 2.3 Conclusiones del capítulo ...... 47 Capítulo 3. Descripción de la solución propuesta ...... 48 3.1 Estructura de archivos XMI para el Formato UML: ...... 48 3.2 Descripción de la herramienta...... 50 3.3 Conclusiones de capítulo ...... 53 Conclusiones ...... 54 Recomendaciones ...... 55 Referencias bibliográficas ...... 56 BILBIOGRAFÍA ...... 57

VIII

Índice de figura

Fig 1.1. Definición de modelo ...... 8 Fig 1.2. Roles de Los desarrolladores ...... 12 Fig 1.3. La transformación en el proceso basado en MDA ...... 13 Fig 2.1 DIAGRAMA de casos de uso y actores ...... 40 Fig 4. Diagrama de casos de usos del sistema41 Fig 2.2 DIAGRAMA DE ACTIVIDAD DEL SISTEMA Fig PARA EL CASO DE USO IMPORTAR FIG 2.3 dIAGRAMA DE CLASES DEL DISEÑO ...... 43 Fig 2.4. Diagrama de clases PARA ANALIZAR LA LOGICA DE GENERAR CODIGO ...... 44 FIG2.5 DIAGRAMA DE SECUENCIA PARA ESCENARIO IMPORTAR ARCHIVO XMI ...... 45 FIG 2.6 DIAGRAMA DE ACTIVIDADES PARA GENERAR CODIGO ...... 46 Fig 3.2 ventana importar archivo xmi y ventana de selección ...... 52 Fig 3.3. Contenido del modelo exportado en formato XMI ...... 53

Fig.3.4 Error ...... 53

Índice de tabla

Tabla 1. Comparación de Herramientas CASE ...... 28 Tabla 2. Comparación de Herramientas MDA ...... 35

Introducción

INTRODUCCIÓN

La Informática no es más que la ciencia aplicada que abarca el estudio y aplicación del tratamiento automático de la información, la general utilización por parte de la humanidad de estos avances ha propiciado la disposición de una gran cantidad de recursos humanos y materiales al desarrollo de la industria de la informatización, contribuyendo a la rápida adquisición de conocimientos y de nuevos valores. Desatando a un ritmo continuo e impredecible significativas transformaciones económicas, sociales, culturales e incluso dominando en gran medida nuestra forma de vida. Por lo que la evolución acelerada y la afirmación de la industria software como una forma de economía bastante soluble, no constituyen una sorpresa.

Consecuentemente con la necesidad de encontrar soluciones para obtener productos de calidad de modo rentable y fiable surgen métodos y técnicas para desarrollar y mantener aplicaciones, este conjunto de enfoques se conoce cono Ingeniería de Software. Brindando soporte a la utilización de dichos principios aparecen las Herramientas CASE (acrónimo en inglés de “Computer Aided Software Engineering”, Ingeniería de software Asistida por Computadora), asistiendo en tareas como el diseño del proyecto, implementación de parte del código y la documentación asociada a la implementación.

El modelado es una parte central de todas las actividades que conducen a la producción de buen software, ya que a través del modelado conseguimos visualizar, especificar (estructura y comportamiento de un artefacto), proporcionar plantillas que sean una guían en la construcción del sistema y documentar las decisiones adoptadas por los desarrolladores. El UML (“Unified Modeling Language”, Lenguaje Unificado de Modelado) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (“Object Management Group”).

Los modelos proveen abstracciones de un sistema físico que permiten a los ingenieros analizar el sistema ignorando detalles complejos mientras se enfocan en las partes más relevantes, como puede ser la lógica del negocio. MDA (acrónimo en inglés de “Model Driven Architecture”, Arquitectura Dirigida por Modelos), es una arquitectura que

Introducción

proporciona un conjunto de guías para estructurar especificaciones expresadas como modelos. Conduce al desarrollador a construcción y progresiva transformación de modelos, separando el diseño de la arquitectura brindando un alto nivel de abstracción, permitiendo que el diseño y la arquitectura sean modificados independientemente. La evolución consecuente de los modelos a distintos niveles de abstracción nos conduce hasta un modelo con detalles específicos de la plataforma, PSM (“Plataform Specific Model”, Modelo Específico de la Plataforma), el cual es cercano a la solución del problema, por tal modelo siguiendo la lógica de transformación se podrá producir el código fuente.

Las aplicaciones construidas en la actualidad deben de diseñarse para soportar distintas situaciones independientes de los aspectos funcionales y permitiendo además la reutilización, modificación y la documentación de las mismas.

Ya han sido muchas las plataformas diferentes y demasiadas las necesidades contradictorias, y se hace muy difícil para los desarrolladores acceder a una solución común. Por tanto, un guión más realista es habilitar la coexistencia de los sistemas presentes representándolos por los modelos y transformando estos modelos en otros modelos. El MDA en realidad intenta proporcionar una solución al problema de tal integración. Aunque el marco arquitectónico de OMG está en constante cambio, la idea fundamental es lograr en ambas interoperabilidad y portabilidad.

Continuamente con la evolución de plataformas de desarrollo y la creación de nuevos estándares, la diversificación de herramientas CASE ha tomado lugar, surgiendo al mercado disimiles herramientas como: Rational Rose, Visual Paradigm, herramientas tradicionales propietarias y otras que se adhieren al paradigma MDA como son OptimalJ, AndroMDA e IBM RSA.

La UCLV (Universidad Central “Marta Abreu” de las Villas) es una institución que está estrechamente vinculada con el desarrollo de software, y en dicha entidad como en muchas otras de nuestro país, es necesaria la utilización de programas que permitan visualizar los diferentes diagramas y generar el código fuente. Para aplicar a un marco de trabajo que garantice la especificación completa de un sistema en base a modelos independientes y

Introducción

específicos de una plataforma y tecnología que permitan desarrollar en un ámbito tan cambiante y complejo productos con la calidad y la productividad requeridas.

Planteamiento del Problema:

Es evidente la necesidad de un software autónomo en nuestro país, de apoyo a la ingeniería de software que permita ser usado, copiado, estudiado, cambiado y redistribuido libremente por las instituciones cubanas que desarrollan software. Por lo que anteriormente en la UCLV como proyecto de tesis de grado se desarrolló una primera versión de una herramienta de modelado UML, basada en la metodología MDA, llamada JMDA, bajo la tutela del Dr. Rosendo Moreno. Esta primera versión quedó inconclusa ya que no brinda soporte para algunos diagramas UML y no cuenta con una herramienta de transformación para automatizar la tarea de generar código fuente a partir de los diferentes modelos.

Problema tecnológico:

La necesidad que tiene la Industria Cubana de software de una herramienta de análisis y diseño de software soberana que cumpla con los paradigmas de desarrollo actual, que sea integra y supere así los inconvenientes de algunas herramientas de diseño actuales, como la necesidad del pago de una licencia en el caso de las herramientas propietarias o las limitantes técnicas que poseen otras. Este trabajo tiene correspondencia con una tarea de investigación del Proyecto Territorial “Desarrollo de métodos y tecnologías avanzadas de Ingeniería del Software para el desarrollo de Sistemas de Información”.

Objetivo General:

Desarrollar el módulo que permitirá generar el código fuente a partir de un Modelo Independiente de Plataforma (PSM) como parte de una nueva versión de la herramienta CASE: JMDA, dentro del marco de trabajo denominado MDA.

Objetivos específicos:

1. Hacer un acercamiento sobre el estado actual en que se encuentra MDA (Arquitectura Dirigida por Modelos), las herramientas CASE existentes que utilizan

Introducción

el Marco de Trabajo MDA y estudiar la lógica trasladar a código fuente a partir de modelos. 2. Estudiar el funcionamiento de la herramienta JMDA y establecer una comparación con otras implementadas con el marco de trabajo MDA como AndroMDA. 3. Desarrollar el modelado basado en UML del módulo de la herramienta JMDA para la generación de código a partir del punto de vista PSM. 4. Implementar el módulo de la versión JMDA 2.0 que permita la transformación de forma automática de los modelos específicos de la plataforma a código fuente.

Preguntas de Investigación:

 ¿Cómo elaborar una herramienta que permita generar desde PSM a código fuente?  ¿Cuáles son las bibliotecas y herramientas necesarias para efectuar las tareas y trasformaciones específicas?  ¿Cuál es el mejor lenguaje de almacenamiento necesario?  ¿Cómo realizar la transformación necesaria a código fuente?

Hipótesis:

La nueva versión de la herramienta JMDA, que de soporte nuevos diagramas y permita la transformación de diferentes modelos desde su concepción hasta el código fuente, ayudará a analistas y diseñadores cubanos al perfeccionar las prácticas de desarrollo de aplicaciones de Software basado en modelos UML, incrementando la productividad.

El presente trabajo estará estructurado en los siguientes 3 capítulos:

 Capítulo 1 “Antecedentes y Fundamentación Teórica”: En el mismo se profundiza sobre el estado teórico actual de la metodología MDA.  Capítulo 2 “Modelado de la herramienta JMDA versión 2.0 Módulo PSM-Código”  Capítulo 3. “Implementación y explotación de la herramienta JMDA versión 2.0 Módulo PSM-Código”

Capítulo I. Análisis y fundamentación teórica

CAPÍTULO 1. ANÁLISIS Y FUNDAMENTACIÓN TEÓRICA

En este capítulo será abordado el tema framework MDA, el estado teórico en que se encuentra en el presente, las herramientas que actualmente utilizan esta metodología, estableciendo una comparación entre ellas con el objetivo de que actúe como soporte a la investigación, haciendo hincapié en la generación de código fuente, ya que este es el módulo que se va a implementar en esta tesis.

1.1 ANTECEDENTES El trabajo realizado en esta tesis tiene como antecedente, la problemática planteada en la tesis: “Herramienta jMDA para el desarrollo de Análisis y Diseño en UML en la Arquitectura Dirigida por Modelos” del año 2010, siendo una continuación de la misma. En el trabajo desempeñado en la tesis del 2010 se logró desarrollar una herramienta CASE que era capaz de realizar la modelación de un Modelo Independiente de la Plataforma usando para ello tres tipos de diagramas UML: actividades, casos de uso y clases; logrando convertir el de clases a un Modelo Especifico de una Plataforma con las características de la plataforma Java, cumpliendo así el primer o segundo paso de conversión de modelos planteado por la aproximación MDA, pero careciendo del segundo o tercero que es la generación de código fuente.

1.2 CONCEPTOS FUNDAMENTALES Para un mejor entendimiento del problema es necesario el manejo de diferentes términos:

 “Un Modelo de un sistema es una descripción o especificación de este sistema y su entorno para unos propósitos concretos. Un modelo, a menudo, es presentado como una combinación de gráficos y textos”. (Álvaro Jiménez Rielo, 2009)  Dirigido por Modelos: Se dice que es dirigido o guiado por modelos porque provee mecanismos que usan modelos para dirigir el curso del diseño, la construcción, la implementación, la operación, el mantenimiento y la modificación de una aplicación. Es decir, el proceso depende de los modelos.  “La Arquitectura de un sistema es una especificación de las partes y conectores del sistema y las reglas de interacción de las partes. La Arquitectura Dirigida por

Capítulo I. Análisis y fundamentación teórica

Modelos propone un conjunto de tipos de modelos para ser usados, cómo deben ser preparados estos modelos y las relaciones entre las distintas partes de los modelos.” (Álvaro Jiménez Rielo, 2009)  Vista: Es una representación del sistema desde la perspectiva de un punto de vista determinado.  “Un Punto de Vista de un sistema es una técnica de abstracción que usa un conjunto seleccionado de conceptos arquitectónicos y reglas estructurales con el fin de centrarse en aspectos concretos del sistema.” (Álvaro Jiménez Rielo, 2009).  Plataforma: Es un conjunto de subsistemas y tecnologías que proveen un conjunto de funcionalidades que cualquier aplicación soportada por la plataforma puede utilizar sin preocupación sobre los detalles de implementación de dicha plataforma. (Pineda, 2008)  “La Independencia de la Plataforma es una cualidad que debe poseer un modelo. Esto es la calidad que indica que el modelo es independiente de las características de cualquier plataforma”. (Álvaro Jiménez Rielo, 2009)  Framework (Marco de Trabajo): Define, en términos generales, un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular, que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.

1.3 ARQUITECTURA DIRIGIDA POR MODELOS “El reto que en la actualidad motiva a la comunidad de investigadores y generadores de tecnología es proponer esquemas de desarrollo en los cuales los modelos, antes que el código, son los actores centrales del proceso de desarrollo y donde se proveen mecanismos y herramientas de trabajo integradas que asisten al desarrollador en la construcción y transformación progresivas de modelos hasta llegar a la solución final. Esta corriente de trabajo, liderada por OMG, se conoce como MDA”. (Juan Bernardo Quintero, 2007 )

OMG (acrónimo en inglés de “Object Management Group”), es un consorcio dedicado al establecimiento de estándares de tecnologías orientadas a objetos, integrado por diversas compañías de reconocido nivel y prestigio como: IBM, Apple Computer, Sun Microsystems, Eclipse Foundation, etc. Los estándares de modelado de OMG facilitan un

Capítulo I. Análisis y fundamentación teórica

diseño visual, un desarrollo y un mantenimiento de software potentes, son algunos de estos como UML, XMI, CORBA.

1.3.1 ¿QUÉ ES MDA? MDA (es el acrónimo en inglés de “Model Driven Architecture”, Arquitectura Dirigida por Modelos según sus siglas en español), un concepto promovido y patrocinado por la OMG, que representa una nueva manera de organizar y de administrar arquitecturas empresariales, en el proceso de desarrollo de software.

MDA define un framework para procesar y relacionar modelos de los sistemas de software, proporcionando un conjunto de guías para separar la especificación de un sistema, de la funcionalidad e implementación sobre una plataforma concreta, visualizando distintos niveles de abstracción para guiar el proceso de desarrollo de software desde el análisis hasta el mantenimiento del producto, pretendiendo separar además la especificación de las operaciones y los datos.

Los modelos constituyen el elemento básico en el proceso de desarrollo y mediante su evolución de manera sistemática permite la obtención de una solución, si estos modelos tienen la información suficiente, entonces la aplicación pudiese crearse casi en su totalidad a partir de ellos.

Su objetivo es que la construcción de la aplicación sea realizada de un forma automática donde los aspectos no funcionales como los relacionados con la arquitectura de la aplicación y el soporte de cierta tecnología son ejecutados de forma automática por la computadora, mientras que los aspectos funcionales relacionados con la lógica del negocio van de la mano de los programadores, es decir, los desarrolladores no deben preocuparse por conocer en detalle el funcionamiento de una plataforma en particular.

Según (Anacleto, 2005 a) “Suele escucharse decir que MDA es la evolución natural de UML, ya que tiende a incrementar la cantidad de código generado, a partir de especificaciones detalladas en UML”.

Capítulo I. Análisis y fundamentación teórica

“MDA es sólo un concepto; representa una nueva manera de organizar y de administrar arquitecturas empresariales. Las herramientas que proponen soluciones MDA son aquellas que facilitan la implementación de este concepto.” (Anacleto, 2005 a)

1.4 PROCESO DE DESARROLLO BASADO EN MODELOS Los modelos por definición constituyen una vista simplificada de la realidad. Ellos nos proveen abstracciones de un sistema físico que permiten a los ingenieros analizar el sistema ignorando detalles complejos mientras se enfocan en las partes más relevantes, como puede ser la lógica del negocio. Los modelos pueden ser los precursores de la implementación física del sistema o ser generados de sistemas ya existentes para comprender su funcionamiento.

Este concepto constituye una estrategia básica del desarrollador para entender, especificar y lograr una mejor comprensión del problema. Los modelos son básicamente una vista simplificada de la realidad, establecen una descripción del proyecto, este se representa generalmente como una combinación de dibujos y textos.

FIG 1.1. DEFINICIÓN DE MODELO

El estado actual de esta práctica emplea el Lenguaje de Modelado Unificado o UML (por sus siglas en inglés “Unified Modeling Laguage”) es la principal en la notación del modelado. UML es un lenguaje de símbolos específicamente diseñado para la representación de la estructura y funcionamiento de aplicaciones de software.

La estrategia de modelado como concepto propicia al programador un mayor nivel de abstracción para la comprensión del problema, pero produce una serie de inconvenientes, según (Quintero, 2007):

 “Los modelos se usan solo como documentación. Los modelos no funcionan como un artefacto activo que contribuya en el proceso de desarrollo.”

Capítulo I. Análisis y fundamentación teórica

 “Existen vacíos entre el modelo y la implementación de los sistemas. Los cambios en el modelo no se reflejan en el código y los cambios en el código no se reflejan en los modelos, sólo se genera el código de los modelos la primera vez y nunca se actualiza.”  “No hay una adecuada mezcla de modelos. Vistas desconectadas de un sistema (desconexión horizontal) y grupos de modelos desconectados (desconexión vertical)”.  “No hay transformación de modelos. Pocos lenguajes de transformación populares y pocas herramientas que soporten estas transformaciones”.

Modelos en MDA

Al implementar el marco de trabajo MDA, los modelos dejan de ser utilizados únicamente para la documentación o como guía para la implementación, convirtiéndose en el artefacto principal del proceso de desarrollo, ya que de ellos dependerá en gran parte el éxito del proyecto.

Según la definición de (Anneke Kleppe, 2005) “Un modelo es una definición de un sistema, o de una parte de él, escrita en un lenguaje bien definido. Un lenguaje bien definido es un lenguaje con una sintaxis y semántica bien definida que es adecuado para la interpretación automática por un computador. “

El hecho de que un modelo este escrito en un lenguaje bien definido tiene una gran importancia para MDA, ya que supone que el modelo tiene asociadas una sintaxis y una semántica bien definidas. Esto permite la interpretación automática por parte de transformadores o compiladores de modelos, fundamentales en MDA.

Con MDA los modelos toman un valor fundamental en el proceso de desarrollo, constituyen una estrategia clave para entender y especificar una solución de software, mediante la evolución consecuente de los mismos guiar el proceso para obtener una solución final. Cada modelo produce artefactos que establecen el punto de partida para cada etapa de desarrollo.

Capítulo I. Análisis y fundamentación teórica

El proceso de transformación de los modelos se realiza de una manera asistida y la independencia propuesta por MDA se consigue mediante una catalogación de modelos que permiten especificar el sistema desde diferentes puntos de vista. Todos estos modelos surgen antes del proceso de codificación.

Modelo Independiente de Computación

El modelo CIM (acrónimo en inglés de “Computationally Independent Model”, Modelo Independiente de la Computación) es un modelo que caracteriza el dominio del problema, no muestra detalles de la estructura del sistema y a veces es llamado modelo del dominio del negocio o modelo de la concepción. Se centra en el entorno del sistema surge en el proceso de modelado del negocio. Los detalles de la estructura y procesamiento del sistema no se muestran, o aún no están especificados. Idealmente se concibe antes del levantamiento de requisitos.

Modelo Independiente de la Plataforma

El modelo PIM (acrónimo en inglés de “Platform Independent Model”, Modelos Independientes de la Plataforma): es el que describe la posible solución de software representando la estructura, funcionalidad y restricciones, centrándose en las operaciones, mientras oculta los detalles para una plataforma concreta. Sirven de conexión entre los expertos del negocio y los desarrolladores del sistema. En este punto de vista debe emplearse lenguaje de modelado de propósito general, o bien algún lenguaje específico del área en que se empleará el sistema, pero en ningún caso se emplearán lenguajes específicos de plataformas. Surgen como resultado del análisis y diseño. Es una manera visual y asequible que puede ser mostrada a los usuarios del sistema para ser validados por estos y además permite elaborar una estructura de la solución que puede ser implementada en disimiles plataformas.

Modelo Específico de la Plataforma

El modelo PSM (acrónimo en inglés de “Platform Specific Models”, Modelos Específicos de la Plataforma): es el modelo derivado de la categoría anterior (PIM), especifican el sistema en términos de las construcciones que se van a implementar a la hora de desarrollar. Conteniendo detalles de la plataforma en que será implementado. Es un modelo de sistema

Capítulo I. Análisis y fundamentación teórica

de más bajo nivel y mucho más cercano a la vista del código. Finaliza la especificación de un sistema de computadoras. Un modelo PIM puede generar distintos modelos PSM, en función de las tecnologías utilizadas.

1.5 MODELO DE PLATAFORMA Tal y como plantea (Colsa, 2005) “Un modelo de plataforma expone un conjunto de conceptos técnicos que representan las diferentes formas o partes que conforman un sistema, y los servicios que provee. También expone, para su uso en los modelos específicos de la plataforma, conceptos que explican los diferentes elementos que provee una plataforma para la implementación de una aplicación en un sistema”.

1.6 PROCESO DE DESARROLLO MDA El proceso de desarrollo evoluciona a partir de una serie de estados o etapas, las cuales son:

 Fase 1. Construcción de un Modelo CIM: Modelo que muestra el entorno en el cual operará el próximo sistema software a desarrollar. Puede mostrar diferentes aspectos del negocio donde funcionará la nueva aplicación. “Sin embargo MDA no detalla cómo deben ser los modelos CIM y tampoco describe cómo deben ser transformados a modelos PIM” (Bustelo, 2005).  Fase 2. Construcción de un Modelo PIM: Modelo de alto nivel de abstracción del sistema, describiendo la funcionalidad del mismo. Independiente de cualquier tecnología o plataforma de software.  Fase 3. Transformación del PIM a uno o varios Modelos PSM: Modelo que agrupa los detalles de un PIM, con un nivel abstracción más bajo, describiendo el sistema de acuerdo con una tecnología de implementación determinada.  Fase 4. Generación de código a partir de cada PSM: Debido a que cada PSM está muy ligado a una tecnología concreta, la transformación se realizara de forma automática.

A la luz de este enfoque, surgen nuevos esquemas de trabajo en los que se distinguen los diferentes roles de los participantes del proceso (Figura 2):

Capítulo I. Análisis y fundamentación teórica

FIG 1.2. ROLES DE LOS DESARROLLADORES

 Analista del Negocio: Experto en el dominio del problema. (Modela CIM).  Arquitecto y el Diseñador: Definen propuesta de la solución. (Transformación de CIM a PIM).  Desarrolladores y Probadores: Amplio conocimiento de la tecnología. Implementan el diseño en una plataforma particular. (Transformación de PIM a Código). Luego de ser necesario proceden respectivamente a manipular el código (de ser necesario) y a realizar los test requeridos sobre la aplicación.

1.6.1 TRANSFORMACIÓN DE MODELOS. Desde la perspectiva de MDA, la transformación de modelos se sustenta en la definición de las reglas para convertir un modelo de un nivel de abstracción a otro basándose en lenguajes y mecanismos estándares, con el propósito de lograr una solución genérica.

Tomando como referente la investigación: (Anneke Kleppe, 2005), donde se definen los principales conceptos :

Capítulo I. Análisis y fundamentación teórica

• Transformación: generación automática de un modelo objetivo desde un modelo fuente, de acuerdo con una definición de transformación. • Definición de transformación: conjunto de reglas de transformación que juntas describen cómo un modelo en un lenguaje fuente puede ser transformado en un modelo en el lenguaje objetivo. • Regla de transformación: descripción de cómo una o varias construcciones descritas en un lenguaje fuente, pueden ser transformadas en una o varias construcciones en un lenguaje objetivo.

La transformación de modelos constituye el proceso central en el cual se basa la estrategia MDA y con el propósito de crear un estándar de transformación OMG, propone un proceso de estandarización que favorece la representación de propuestas.

La figura 3 ilustra la forma como MDA propone expresar la solución del problema mediante la evolución consecuente de los modelos, pasando de un nivel de abstracción de otro. La transformación de modelos se sustenta en la definición de las reglas para convertir un modelo de un nivel de abstracción a otro basándose en lenguajes y mecanismos estándares.

FIG 1.3. LA TRANSFORMACIÓN EN EL PROCESO BASADO EN MDA

Las transformaciones pueden efectuarse según (Brown, 2004):

Capítulo I. Análisis y fundamentación teórica

• PIM a PIM. Esta transformación es utilizada cuando los modelos son mejorados, filtrados o especializados durante el ciclo de vida de desarrollo sin necesitar ninguna información dependiente de la plataforma. Una de las formas de mapeo más obvias es entre los modelos de análisis y el diseño. • PIM a PSM. Esta transformación es utilizada cuando el PIM está lo suficientemente refinado para ser proyectado a una infraestructura de ejecución. La proyección está basada en las características de la plataforma utilizada. • PSM a PSM. Esta transformación puede requerirse en la implementación y realización de componentes. Por ejemplo, el empaquetado de un componente se realiza seleccionando servicios y configuración. Una vez empaquetado, la entrega del componente puede ser realizada especificando los datos de inicialización, servidores de instalación, generación y configuración del contenedor, etc. Esta transformación está ligada al refinamiento de un modelo PSM a un PSM mejorado y más completo. • PSM a PIM. Esta transformación puede ser requerida para abstraer modelos de implementaciones existentes en una tecnología específica a una independiente de la plataforma. Este procedimiento es sin duda uno de los más complicados y difícilmente puede ser automatizado. • PSM a Código. Esta transformación es la última de la cadena y permite generar el código específico para una plataforma en particular utilizando un PSM. Una vez mejorados los PSM o actualizados debido al surgimiento de nuevos requerimientos una transformación de este tipo es necesaria para regenerar el sistema.

El proceso de generación del código puede llegar a aplicar una serie de reglas de transformación, los cuales generalmente le permiten al desarrollador la elección entre los distintos patrones que podrán ser aplicados a los modelos para transformarlos en modelos más complejos o código.

1.6.1.1 DEFINICIÓN DE TRANSFORMACIÓN Una definición de transformación o mapeo MDA proporciona la especificación de la transformación entre modelos.

Capítulo I. Análisis y fundamentación teórica

• Una transformación (“mapping”), toma uno o más modelos de entrada y produce un modelo de salida. (Ejemplo: transformación de un modelo UML a su correspondiente en modelo de código en java). • Las reglas de transformación (“mapping rules”) describen cómo hacer la transformación, la transformación completa se considera una función de transformación con muchas reglas de transformación. (Ejemplo: Clase UML se convierte en una clase en java con el mismo nombre).

Según (Rosendo de Jesús Moreno Rodríguez, 2008), existen dos tipos de definiciones de transformación:

• Transformaciones de Tipos (“Model Type Mapping”): • Transformaciones de Instancias (“Model Instante Mapping”):

Tipos de definiciones de transformación:

 Mapeo por tipos: “especifica un mapeo desde un modelo construido usando tipos específicos de un lenguaje origen, para expresar un modelo con tipos específicos en el lenguaje destino” (Juan Bernardo Quintero, 2007 ). Es decir cada tipo de elemento del origen se le aplica una regla determinada para transformarla en uno o varios elementos del destino.  Transformación por metamodelo: Un modelo es construido usando un lenguaje independiente de la plataforma especificado por algún metamodelo. Se hace la transformación de este modelo a un lenguaje específico de la plataforma deseada en algún otro metamodelo. Es decir se transforma de un lenguaje de modelado a otro. Se tiene un lenguaje de modelado fuente que será transformado en un lenguaje de modelado objetivo. Es un mapeo de tipos, donde tanto los tipos del modelo origen como los del destino están especificados a MOF.  Transformación por patrones: Patrones pueden ser utilizados en la especificación del mapeado. El mapeado incluirá entonces patrones y marcas correspondientes a elementos de dichos patrones.

Capítulo I. Análisis y fundamentación teórica

 Transformaciones de instancias: “Se especifican elementos del modelo origen para transformarse de una forma particular, dada la selección de una plataforma específica, en el modelo destino” (Juan Bernardo Quintero, 2007 ). Esto se consigue mediante la utilización de marcas. En un modelo son colocadas una serie de marcas que serán utilizadas para guiar la transformación. Una vez que se tiene el modelo marcado, se aplican reglas de mapeo definidas para una plataforma específica para transformar el PIM en un PSM.

1.6.1.2 MÉTODOS DE TRANSFORMACIÓN Los métodos de transformación que se pueden llevar a cabo las herramientas de transformación pueden combinarlos para conseguir su máxima efectividad, diferentes métodos existentes son:

 Transformaciones manuales: se suelen dar cuando hay que tomar decisiones sobre el diseño durante la fase de desarrollo en función del contexto de una implementación específica.  Transformación de un PIM preparado usando perfiles: se utilizan perfiles UML independientes de la plataforma para preparar modelos PIM, de manera que el modelo preparado se transforme en un modelo PSM. Este tipo de transformaciones requieren que se marque el modelo PIM con marcas del perfil específico de la plataforma.  Transformaciones utilizando patrones y marcas: se realizan mediante mapas de trasformación que incluyen marcas y patrones, de manera que se genere un modelo PIM con las marcas específicas de la plataforma sobre el que se aplica el patrón para generar el modelo PSM.  Transformaciones automáticas: se pueden realizar cuando el modelo PIM proporciona toda la información necesaria para la implementación, por lo que no se necesita ninguna marca ni el uso de perfiles adicionales para generar el código.

1.6.1.3 CARACTERÍSTICAS DESEABLES DE LAS TRANSFORMACIONES Es necesario para lograr un enfoque propuesto por MDA que el proceso de trasformación disponga de una serie de propiedades o características:

Capítulo I. Análisis y fundamentación teórica

1-Ajustar las Trasformaciones: Según MDA es necesario que el programador tenga un cierto control sobre la evolución de las transformaciones. Esto se puede obtener:

 Control Manual: Control directo del programador sobre la transformación. El usuario puede definir manualmente qué elementos del modelo van a ser transformados por qué reglas de transformación. Esta es la solución más flexible, pero es propensa a errores y complica la tarea del desarrollador, por lo que es el método menos utilizado.  Condiciones en las Transformaciones: el desarrollador asigna una condición a cada regla de transformación, la cual describe cuando debe aplicarse la regla. Este enfoque puede combinarse con el control manual. Un ejemplo podría ser: (todas las clases con el estereotipo “persistent” se transforman en “table”.  Parámetros de Transformación: las definiciones de transformaciones pueden parametrizarse para permitir al desarrollador cambiar el “estilo” de las transformaciones. Por ejemplo, cuando se transforma un atributo público en uno privado con métodos get y set, los prefijos exactos (normalmente get y set) podrían definirse como parámetros de la transformación. Otro parámetro típico de la transformación podría ser la longitud de tipos de datos de tamaño indefinido. Por ejemplo, en lugar de transformar un string en el PIM en un VARCHAR (40) en un PSM relacional, podríamos definir la longitud del dato como un parámetro de transformación. Los parámetros de transformación suponen el principal método de control sobre el proceso de transformación. Las marcas vistas en el apartado anterior pueden verse como parámetros de transformación para instancias del modelo.

2. Trazabilidad.

La trazabilidad implica que pueda conocerse el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino.

Dentro del marco de MDA, la trazabilidad es una característica muy útil en muchas situaciones. Supóngase que se cambia el nombre de la una operación en el PSM que ha sido generada directamente a partir del PIM. Sería deseable que ese cambio se reflejase también

Capítulo I. Análisis y fundamentación teórica

en el PIM. Esto no es posible si la herramienta no dispone de un mecanismo para conocer el origen en el PIM de la operación modificada.

La Trazabilidad también es útil en la búsqueda y corrección de errores. Las partes de código erróneas pueden encontrarse buscando los elementos del PIM, que presentan la funcionalidad defectuosa y siguiendo su traza hasta el código.

3. Consistencia Incremental.

Normalmente cuando se genera un modelo destino, éste necesita algún trabajo extra, como rellenar el código de una operación o refinar la interfaz de usuario. Si se regenera de nuevo el modelo destino, debido a cambios en el modelo origen, se quiere que ese trabajo extra se conserve. Esto es lo que se llama consistencia incremental.

Cuando se produce un cambio en el modelo origen, el proceso de transformación sabe qué elementos en el modelo destino necesitan cambiarse también. Un proceso de transformación incremental puede reemplazar los elementos viejos con los nuevos, mientras mantiene la información extra del modelo destino en su sitio. Esto significa que cambios en el modelo origen tienen el mínimo impacto en el modelo destino.

4. Bidireccionalidad.

La bidireccionalidad implica que las transformaciones pueden operar en ambas direcciones. Esta propiedad, aunque interesante, tiene menor prioridad que las anteriores. Las transformaciones bidireccionales pueden lograrse de dos formas:

 Ambas transformaciones se ejecutan de acuerdo con una única definición de transformación.  Una transformación y su inversa se especifican mediante dos definiciones de transformación diferentes.

Es muy complicado definir transformaciones bidireccionales, principalmente porque es muy difícil asegurar que una definición de transformación es la inversa de otra. De hecho, en muchas ocasiones la bidireccionalidad es imposible de conseguir. Por ejemplo, cuando se transforma un modelo de negocio en un modelo relacional, solo se transforma la

Capítulo I. Análisis y fundamentación teórica

información estructural del modelo origen, ignorando toda la información dinámica. Esto hace imposible regenerar el modelo de negocio completo a partir del modelo relacional.

1.6.2 REÚSO DE MODELOS. Es importante el reúso de modelos por parte del grupo de trabajo porque esto disminuye las labores repetitivas, los errores por intervención humana y el tiempo para completar algunas tareas. Es necesario evitar los errores en la confección de modelos iniciales porque el efecto de propagación traería grandes consecuencias a las operaciones de transformación, por lo que es también importante que se puedan hacer cambios de manera inversa.

1.7 PRINCIPIOS DE MDA MDA surge como respuesta a la diversidad de plataformas y tecnologías de desarrollo actuales, debido a la poca interoperabilidad existente y a la acelerada evolución tecnológica que ocasionan que las plataformas sean obsoletas en breve tiempo. Por consiguiente no se tiene un verdadero estándar general en cuanto a sistema operativo, servidores y plataformas de implementación. Lo que dificulta la reutilización de artefactos de software. Por lo que MDA propone estrategias de desarrollo para alcanzar beneficios fundamentales como:

 Representación directa: Esta estrategia presta mayor atención en el dominio del problema que en la tecnología aplicada. Ya que es en el negocio donde se manejan los cambios más relevantes del problema, que influyen considerablemente en el desarrollo y mantenimiento de una solución de software, que las plataformas de desarrollo. Estableciendo una mayor relación entre la semántica del dominio y su representación, logrando diseños certeros permitiendo un nivel de abstracción superior.  Automatización: La automatización de tareas que pueden hacerse mecánicamente y no requieren de la intervención de los programadores induce a un incremento de la velocidad de desarrollo y la reducción de errores. Son funcionalidades que bien no dependen del ingenio del programador como el intercambio de modelos, verificación de consistencia, transformación de modelos, manejo de metamodelos y otras.

Capítulo I. Análisis y fundamentación teórica

 Estándares abiertos: Los estándares permiten la integración de varias herramientas de desarrollo. Ayuda a eliminar la diversidad y permiten la interoperabilidad entre diferentes herramientas de desarrollo con diferentes propósitos. Por ejemplo los estándares UML se deben expresar en XML para la transformación como XSLT.

1.8 ESTÁNDARES UTILIZADOS POR MDA. Como ya se mencionó con anterioridad los estándares en los cuales se soporta MDA tienen como propósito lograr la interoperabilidad entre varias herramientas y plataformas.

1.8.1 UML El lenguaje de modelado unificado (UML, acrónimo en inglés de “Unified Modeling Language”) “es un lenguaje de modelado estándar para la visualización, especificación y documentación de sistemas de software” (Álvaro Jiménez Rielo, 2009). Los modelos de MDA pueden ser especificados usando UML, empleado para la definición de los modelos independientes de la plataforma y los modelos específicos de las plataformas de destino. UML resuelve el problema de la arquitectura, objetos e interacciones entre objetos. Los artefactos capturados en UML (en términos de casos de uso, clases, diagramas de actividad, etc.) pueden ser exportados a otras herramientas del proceso de desarrollo usando XMI.

1.8.2 PERFILES. UML se puede ajustar con la utilización de perfiles, que no es más que un modelo UML con un conjunto de estereotipos, valores etiquetados, restricciones y clases bases predefinidos. Estos conceptos forman parte del mecanismo de extensión UML. Sirven para extender la semántica de los modelos construidos por UML a un dominio específico o a una plataforma particular. Selecciona además un subconjunto de elementos claves de UML para que los no seleccionados no confundan al modelador.

 Estereotipo: Es una distinción de elementos UML que se utiliza para añadir nuevos elementos de modelado se representa así: «estereotipo». Los estereotipos son convertidos en código.  Valores etiquetados: Estos añaden nuevas propiedades, agregando en la especificación a un elemento información: {Etiqueta= Valor1,Valor2}

Capítulo I. Análisis y fundamentación teórica

 Restricciones: Las restricciones se escriben utilizando OCL (Lenguaje de Restricción de Objetos) y que generalmente se utilizan los valores etiquetados para definir las restricciones.

1.8.3 META OBJECT FACILITY (MOF) El OMG plantea una definición de arquitectura de cuatro niveles para la definición de sus estándares, donde existe interrelación entre cada nivel porque cada uno se define como una instancia del anterior. Esta arquitectura se denomina MOF (“Meta ObjectFacility”) que representa el nivel más general y permite la incorporación de nuevos lenguajes de modelados (metamodelos) es para propósitos específicos. Se estructura por diferentes capas:

Capa M3 (Meta-meta-modelo): Corresponde a MOF. Es una especificación que define un lenguaje abstracto para especificar, construir y manejar elementos comunes a cualquier metamodelo.

Capa M2 (Metamodelos): Especifica las entidades de un lenguaje de modelado. Los lenguajes que se han definido como instancias de MOF son: UML, CWM7 y MOF en sí mismo. Adicionalmente se definen metamodelos para otros propósitos como objetos de negocio, flujos de trabajo y modelos de componentes (OMG-MOF, 2003).

Capa M1 (Modelos): Se refiere a los modelos de usuarios que suelen desarrollarse en el momento de construir un sistema de información.

Capa M0 (Instancias). Describe instancias de las entidades propuestas en un modelo de un sistema de información. Es en este nivel en donde pueden usarse los diagramas de objetos como instancias de las clases para verificar que se cumplen las restricciones definidas en el nivel de los modelos (M1).

Aunque MOF abre la posibilidad a partir de la capa M3 adoptar cualquier lenguaje para la especificación de soluciones UML es el lenguaje estándar preestablecido definido en la capa M2 en la cual se pueden especificar los modelo pertenecientes a MDA.

Capítulo I. Análisis y fundamentación teórica

1.8.4 QVT (QUERIES/VIEWS/TRANSFORMATIONS): Es un estándar que está basado en MOF y que pretende establecer un lenguaje para la transformación de modelos (T), un lenguaje para consulta de modelos (Q) y un lenguaje para la definición y generación de vistas (V), que facilite el análisis de modelos desde diferentes perspectivas de los desarrolladores.

El proceso de transformación define los mecanismos y las reglas que conducirán el proceso de transición de un modelo a otro. Este proceso mediante estrategias que utilizan elementos de los modelos, patrones e informaciones de la plataforma en particular en la cual se desarrollará el proyecto de software y toma en cuenta otros elementos, y a partir del estándar QTV se plantea la estrategia de transformación.

1.8.5. Lenguaje de restricciones de objetos (OCL).

El OCL es un lenguaje para especificar restricciones sobre objetos de un modelo UML de forma precisa, dado que existen detalles de la especificación que no pueden expresarse con los modelos UML evitando ambigüedades. Por lo que OCL intenta precisar las pre y post condiciones de cada operación, se pueden escribir en los metamodelos.

a) Invariante: Condición de una clase o interfaz que debe ser satisfecha por todas sus instancias que la implemente. b) Precondición: Condición que debe ser cierta antes de ejecutar una operación de una clase. c) Postcondición: Condición que debe ser cierta después de ejecutar una operación sobre una clase.

1.8.6. XMI. Los XMI (acrónimo en inglés de “XML Metadata Interchange”, Intercambio de metadatos XML).Es un lenguaje utilizado para el intercambio de modelos UML. Es una especificación del OMG definida con el objetivo de facilitar el intercambio de modelos entre herramientas de modelado y repositorios de metadatos basados en la especificación. Es utilizada para el intercambio de modelo entre herramientas CASE y sobre todo las herramientas con un enfoque MDA que permite las funcionalidades, como: edición, verificación y transformación de modelos.

Capítulo I. Análisis y fundamentación teórica

1.8.7. XSLT. Es un modelo de procesamiento de documentos XML que permite un lenguaje para describir reglas de transformación. De esta manera se pueden construir diferentes plantillas que permiten generar documentos recorrer su estructura y realizar transformaciones.

1.9 BENEFICIOS DE MDA Productividad en MDA: el foco del desarrollo recae sobre el PIM. Los PSMs se generan automáticamente a partir del PIM. La definición de las transformaciones exactas es una tarea especializada y difícil, pero una vez implementada la transformación, puede usarse en muchos desarrollos. Lo mismo ocurre con la generación de código a partir de los PSMs. Este enfoque centrado en el PIM aísla los problemas específicos de cada plataforma y encaja mucho mejor con las necesidades de los usuarios finales, puesto que se puede añadir funcionalidad con menos esfuerzo. El trabajo sucio recae sobre las herramientas de transformación, no sobre el desarrollador.

Portabilidad en MDA: la portabilidad se logra también enfocando el desarrollo sobre el PIM. Al ser un modelo independiente de cualquier tecnología, todo lo definido en él es totalmente portable. Otra vez el peso recae sobre las herramientas de transformación, que realizarán de manera automática el paso del PIM al PSM de la plataforma deseada.

Interoperabilidad. Los modelos PSM generados a partir de un mismo PIM normalmente tendrán relaciones, que es lo que en MDA se llama puentes. Normalmente los distintos PSMs no podrán comunicarse entre ellos directamente, ya que pueden pertenecer a distintas tecnologías. Este problema lo soluciona MDA generando no solo los PSMs, sino también los puentes entre ellos. Como es lógico, estos puentes serán construidos por las herramientas de transformación, que como se ve son uno de los pilares de MDA.

Mantenimiento y Documentación. El PIM juega el papel de la documentación de alto nivel que se necesita para cualquier sistema software. Pero la gran diferencia es que el PIM no se abandona tras la codificación. Los cambios realizados en el sistema se reflejarán en todos los niveles, mediante la regeneración de los PSM y del código. Aun así, seguimos necesitando documentación adicional que no puede expresarse con el PIM, por ejemplo, para justificar las elecciones hechas para construir el PIM.

Capítulo I. Análisis y fundamentación teórica

1.10 HERRAMIENTAS CASE TRADICIONALES Las herramienta CASE (acrónimo en inglés de “Computer Aided Software Engineering”) son aplicaciones informáticas destinadas al apoyo del proceso de desarrollo de software. Dichas herramientas suministran soporte automático o semiautomático para los diversos aspectos de la vida del software: diseño del proyecto, creación de la documentación, la detección de errores, implementación automática de gran parte del código de la aplicación según un diseño dado. Aportan ventajas en el proceso de desarrollo aumentando la productividad, reduciendo el costo y tiempo de desarrollo de las mismas.

El desarrollo de las primeras herramientas CASE contribuyó a la creación de nuevos lenguajes gráficos para visualizar, especificar, construir y documentar los sistemas de software: el UML como lenguaje de modelado avanzado en el paradigma orientado a objetos, la integración de nuevas metodología de desarrollo de software como RUP (acrónimo en inglés de “Rational Unified Process).

1.10.1 ARGOUML ArgoUML es una herramienta CASE para el análisis y diseño de aplicaciones que emplea como lenguaje de modelado UML. Proporciona un entorno de diseño orientado al dominio, ofreciendo un soporte cognitivo de diseño orientado a objetos enfocado en las necesidades perceptivas de los diseñadores. Este es una propuesta Open Source programada en JAVA, posibilitando el funcionamiento de esta aplicación en cualquier plataforma que utilice JAVA. Inicialmente fue concebida para realizar el análisis y el diseño en el desarrollo de sistemas orientados a objeto y evolucionó hacia los Sistemas de Información Web y luego se adaptó al desarrollo de software basado en servicios. Aplicación a la que le fue concedida por El Magazine de Desarrollo de Software.

Según Wikipedia: “entrega premios anuales a herramientas de desarrollo de software populares en varias categorías. En 2003 ArgoUML fue una de las finalistas en la categoría Design and Analysis Tools. ArgoUML recibió un premio "runner-up" (revelación), derrotando a muchas herramientas comerciales.”

Esta herramienta permite el trabajo con diferentes lenguajes de almacenamiento y brinda características para la detección y corrección de errores. Los errores detectados reflejarán

Capítulo I. Análisis y fundamentación teórica

decisiones erróneas respecto a estándares o convenciones de código referentes al correcto modelado de los diagramas.

Características Principales:

 Utiliza modelos UML, Zargo, XMI, XML.  Estándares: Utiliza MOF y toma como especificación UML 1.4, OCL.  Genera Código Fuente en: Java, C#, C++, SQL, PHP4 y PHP5.  Permite la importación de código en los lenguajes antes mencionados, el cual es representado en formato de modelo de diagramas para de esta forma llevar a cabo su análisis:  Actividades para el tratamiento de errores:  Detección: De forma automática detecta los errores al ser importado el código fuente o al tomar decisiones en el diseño que no cumplen con los estándares de modelado. Los cuales son informados al usuario por orden de prioridad (High, Medium, Low).  Corrección: Una vez realizada la acción de detección, el usuario puede seleccionar el error enmarcado, del cual brinda una información detallada, incluyendo sugerencias para la corrección del mismo. La cual el usuario decide si la efectúa o no.  Usabilidad: Tiene una interfaz gráfica muy fácil de entender y manejar, es muy intuitiva. El usuario debe participar activamente en la definición de los diferentes modelos y en el tratamiento de errores.  Interoperabilidad: Los modelos UML generados con esta herramienta en formato XMI pueden servir de entrada a otra herramienta, como por ejemplo, AndroMDA.  Extensibilidad: Es un proyecto de código abierto por lo que es permisible la adición de funcionalidades.  A pesar de ser una herramienta CASE bastante completa presenta algunas desventajas: No presenta un botón que permita deshacer los cambios realizados y los modelos no pueden ser en ocasiones reabiertos.

Capítulo I. Análisis y fundamentación teórica

 Ingeniería Inversa: Permite la importación recursiva de código dese un directorio y a partir de este genera un nuevo Modelo.

A pesar de ser una herramienta CASE bastante completa presenta algunas desventajas: No presenta un botón que permita deshacer los cambios realizados y los modelos no pueden ser en ocasiones reabiertos.

 Modelo: UML 1.4,MOf  Estándares: OCL, Perfiles UML.  Interoperabilidad:  Ámbito de aplicación:  Generación de Código Fuente: Java, C#, C++, SQL, PHP4 y PHP5  Integración: AndroMDA  Ingeniería Directa: Permite ingeniería directa (generación de código a partir de los modelos)  Ingeniería Inversa: Permite la importación recursiva de código desde un directorio y a partir de este genera un nuevo Modelo.  Plataformas disponibles: Windows y Linux

1.10.2 RATIONAL ROSE ENTERPRISE Rational Rose es una herramienta emblemática que permite el análisis y diseño de aplicaciones de software, avalada por décadas de éxito en el mercado, perteneciente a la familia de software de IBM Rational Software. Permite el modelado visual de arquitecturas y componentes utilizando UML. Este producto está centrado en la metodología del RUP. Permite crear y refinar estas vistas creando de esta forma un modelo completo que representa el dominio del problema y el sistema de software. Implementa automáticamente el marco de trabajo del código en Java, C++, Ada, Microsoft Visual Basic, Bases de Datos Oracle y SQL Server y además permite crear un nuevo Marco de Trabajo. Chequeo de la sintaxis UML y Generación automática de documentación.

Características Principales:

 Modelo: UML, MOF

Capítulo I. Análisis y fundamentación teórica

 Estándares: Perfiles: Permite definir estereotipos, especificar operaciones y restricciones.  Interoperabilidad: Microsoft Visual Studio, J2EE, etc.  Ámbito de aplicación: Orientados a Objetos, Bases de Datos Oracle, Modelado Web, etc.  Generación de Código Fuente: XML_DTD, Web Modeler, Visual Basic, VC++, Framework Wizard, Data Modeler, ClearCase, CORBA, Apex, Ada, Ansi Converter.  Integración: Dada su integración con Microsoft Visual Studio permite automatizar el proceso de mantenimiento de la consistencia entre un modelo y su implementación.  Ingeniería Directa: Permite ingeniería directa (generación de código a partir de los modelos).  Ingeniería Inversa: Permite ingeniería inversa (crear modelo a partir de código).  Plataformas disponibles: Microsoft Windows.

1.10.3 VISUAL PARADIGM Visual Paradigm es una herramienta CASE de apoyo al desarrollo de programas informáticos, desde la planificación, pasando por el análisis y el diseño, hasta la generación del código fuente de los programas y la documentación. Ofrece un entorno para la creación de diagramas UML, diseño centrado en casos de uso y enfocado al negocio.

Brinda capacidades de ingeniería directa e inversa. Generación de código y despliegue de EJB (Generación de beans para el desarrollo y despliegue de aplicaciones). Importación y exportación de ficheros XMI. Integración con Microsoft Visio.

Características Principales

 Modelo: UML versión 2.1, MOF.  Estándares: XMI, XML. Perfiles: Permite la Utilización de estereotipos, especificar restricciones adicionales y etiquetas para los modelos.  Interoperabilidad: XMI, XML para intercambio de Metadatos, especificación que permite el intercambio de diagramas. Permite además el intercambio mediante la importación y exportación de modelos con Microsoft Word.

Capítulo I. Análisis y fundamentación teórica

 Ámbito de aplicación: Sistemas de Información Web, Orientados a Objetos, Bases de Datos.  Generación de Código Fuente: Java, C#, VB.NET, PHP, ODL, ActionScript, Delphi, Perl, XSD, Python, Objective-C  Integración: Con los principals Java IDEs: Eclipse, JBuilder, NetBEans, JDeveloper, WebLogic Workshop.  Ingeniería Directa: Permite la generación de modelo a código, diagrama a código.  Ingeniería Inversa: Desde diagramas y esquemas XML  Plataformas disponibles: Ofrece soporte para Windows, Linux.

Tabla 1. Comparación de Herramientas CASE Herramientas ArgoUML Rational Rose Visual Paradigm Modelo UML 1.4, MOF UML 1.x, MOF UML 2.1,MOF Estándares OCL, Perfiles UML, Java, C++, Microsoft Visual XMI, XML. Perfiles. XMI, XML Basic, Bases de Datos Oracle Interoperabilidad Modelos en Formato - XMI, XML, XMI Intercambio con Microsoft Word Ámbito de Sistemas de Orientados a Objetos, Bases Sistemas de aplicación Información Web, de Datos Oracle, Modelado Información Web, Orientados a Web Orientados a Objetos, Objetos, Bases de Bases de Datos SQL Datos. Generación de Java, C#, C++, SQL, XML_DTD, Web Modeler, Java, C#,VB.NET, Código Fuente PHP4 y PHP5 VIsual Basic, Version PHP, ODL, Control, VC ++ Version ActionScript, Delphi, Control, TopLink, Data Perl, XSD, Python, Modeler, ClearCase, Objective-C CORBA, Apex, Ada 95, Ansi Converter

Capítulo I. Análisis y fundamentación teórica

Integración AndroMDA Microsoft VisualStudio Eclipse, JBuilder, NetBEans, JDeveloper, WebLogic Workshop. Ingeniería Directa: Sí Sí Sí

Ingeniería Inversa Sí Sí Sí Plataformas Windows y Linux Microsoft Windows Windows y Linux disponibles

Valoración:

Las herramientas CASE tradicionales constituyen una gran ventaja para los analistas de software ya que permiten la visualización del software a implementar y generan parte del código de la aplicación. Algunas utilizan los estándares establecidos por OMG para el intercambio de modelos XMI. Estas herramientas no dan un amplio soporte al refinamiento de modelos, lo cual dificulta la evolución consistente de una solución software en las diferentes fases del proceso de desarrollo.

1.11 HERRAMIENTAS CASE QUE IMPLEMENTAN LA APROXIMACIÓN MDA Dado los grandes beneficios que aporta el marco de trabajo para el desarrollo de software MDA, a pesar de que este todavía en pleno desarrollo, no es sorpresa la aparición de un buen número de herramientas que le dan soporte. Para este estudio hemos seleccionado las herramientas que consideramos que en mayor medida implementan esta metodología y con el fin de servir como soporte a nuestra investigación recurrimos a estudios antes realizados, extrayendo las características que consideramos más relevantes que recogen dichas herramientas y las principales carencias que presentan. Estas herramientas son AndroMDA, OptimalJ, IBM Rational Software Architect (RSA) y la herramienta JMDA v 1.0.

1.11.1 ANDROMDA AndroMDA es un marco de trabajo de código abierto que implementa la metodología MDA. Básicamente este software toma modelos UML en formato XMI producidos por

Capítulo I. Análisis y fundamentación teórica

otras herramientas CASE y los transforman en componentes desplegables para diferentes plataformas de desarrollo (Java, .Net, HTML, PHP).

Emplea una serie de plug-ins (“cartridge” y “translation libraries”, en español cartuchos y librerías de transición) para generar código fuente en disímiles lenguajes de programación. Según (Verónica Bollati, 2008): “Los cartridges son un tipo especial de plug-ins, donde se definen el meta-modelo y las reglas de transformación para transformar elementos del modelo de acuerdo al meta-modelo. En muchos casos, un cartridge puede contener solamente los metamodelos, ya que las reglas de transformación pueden ser manejadas por muchos cartridges y pueden ser contenidas en un cartridge común.”

Incluye un conjunto de cartridge enfocados a los juegos de desarrollo actuales como son Apache Struts, JSF, Spring e Hibernate. Incluye además un juego para desarrollar cartuchos propios (Meta), el cual puede ser personalizado, para construir un generador de código propio. El lenguaje para definir los próximos cartuchos es JAVA.

Es un proyecto de código abierto que cuenta con una comunidad de desarrolladores dedicados a añadir nuevas características, corrección de errores, ayudar a usuarios en la lista de discusiones.

Brinda soporte para UML 2.0 y herramientas basadas en Eclipse EMF, MagicDraw 11.6, RSM). Es capaz de generar código en diferentes lenguajes de programación como JAVA, PHP, .NET, HTML.

Dadas sus características se puede considerar un marco de trabajo para el desarrollo con MDA más que una herramienta en sí misma.

Características Principales:

 Patrones en los modelos MDA: Implementa PIM y PSM. No ofrece soportes a modelos CIM.  Transformaciones entre Modelos: De forma automática, permitiendo transformaciones: o PIM a PSM

Capítulo I. Análisis y fundamentación teórica

o PSM a Código. o PIM a Código.  Ingeniería Inversa: No admite ingeniería inversa  Generación de Código: Es posible generar código en cualquier lenguaje de programación deseado, utilizando el cartridge correspondiente y de no existir el necesario es posible su implementación por parte del usuario.  Estándares:  XMI como lenguaje de entrada almacenamiento y procesamiento de modelos.  MOF OCL y UML 1.4  Interoperabilidad: los modelos generados son almacenados en XMI, permitiendo realizar el intercambio de modelos entre los diferentes niveles.  Extensibilidad: o Apache’s Maven, NetBeans. o Diagramas UML en formato XMI generado por herramienta CASE (ArgoUML y MagicDraw). o Cartuchos para la mayoría de lenguajes de programación. o Nhibernate para asegurar la persistencia de los objetos. o JMI (Interface Metadata de JAVA) o Ant

1.11.2 OPTIMALJ: OptimalJ es un entorno de desarrollo de software para aplicaciones empresariales, esta herramienta implementa el marco de trabajo MDA haciendo uso de los estándares establecidos por OMG. Permitiendo generar aplicaciones en J2EE.

La investigación (J. García Molina, 2007) define los principales modelos que acoge OptimalJ:

 Modelo del Dominio: “Corresponde al PIM de la aplicación y su elemento principal es un modelo de clases del negocio”. Este no presenta detalles dela implementación.  Modelo de la Aplicación: “Se genera automáticamente a partir de un modelo del dominio y está formado por tres modelos: modelo de base de datos, modelo de

Capítulo I. Análisis y fundamentación teórica

interfaz web y modelo EJB.” Contiene detalles de la tecnología implementada J2EE.  Modelo de Código: código de la aplicación, generado a partir de un modelo de la aplicación.

Así mismo (Rosendo de Jesús Moreno Rodríguez, 2008) define dos tipos de patrones de transformación por parte de esta herramienta:

 Patrones de transformación entre modelos: o Patrones de tecnología: transforman el modelo del dominio (PIM) en el modelo de aplicación (PSM). o Patrones de implementación: transforman el modelo de aplicación (PSM) en código.  Patrones funcionales: Para hacer transformaciones dentro de un modelo, constituyen buenas prácticas de programación: o Patrones de dominio: patrones definidos por el usuario que permiten a los desarrolladores capturar, reutilizar y distribuir modelos del dominio. o Patrones de aplicación: Patrones aplicados a los modelos de aplicación. o Patrones de código: patrones de bajo nivel aplicados al código.

A partir un modelo PIM es capaz de derivar varios PSM (representando cada uno una parte del sistema) y de cada PSM se genera el código de determinada plataforma. Utiliza puentes de comunicación entre las distintas piezas tanto a nivel de código como PSM. Niveles de modelos: Permite soporte para PIM del sistema, está representado por el Modelo de Clases, aunque no está totalmente libre de detalles de la plataforma. A partir del PIM confeccionado permite generar tres tipos de PSM que interactúan entre sí mediante puentes de comunicación: con métodos en plataforma EJB, roles de seguridad para la capa web o vistas sobre las tablas del modelo de base de datos.

Principales Características:

 Patrones en los modelos MDA: Implementa los modelos PIM y PSM, no ofrece soporte para CIM.

Capítulo I. Análisis y fundamentación teórica

 Transformaciones de Modelos: De forma automática, permitiendo transformaciones: o PIM-PSM, PSM- código. No permite transformación de un modelo PIM a código. o Permite realizar transformaciones inversas de modelos PSM a PIM.  Ingeniería Inversa: Según el análisis comparativo efectuado por (Juan Bernardo Quintero, 2007) No  Generación de código: Según (Vicente, 2004):”EL código para la lógica del negocio(EJB), base de datos y presentación(Web) pueden generarse de forma automática o todos a la vez”. Como plantea la investigación de (J. García Molina, 2007) hace: “Distinción entre bloques libres y protegidos en el código para impedir la modificación del código generado. Una nueva generación de la aplicación mantiene el código añadido en los bloques libres”.  Estándares: MOF, UML, XMI, XML, WSDL, y J2EE.  Interoperabilidad y tecnologías soportadas: Mediante el API EJB permite la comunicación remota con otras aplicaciones utilizando CORBA.

1.11.3 IBM RATIONAL SOFTWARE ARCHITECT (RSA) IBM Rational Software Architect (RSA) es una herramienta de desarrollo y diseño integrada para arquitectos y desarrolladores de software pertenece a la familia de software IBM Rational Software, la cual posee la funcionalidad del producto antes conocido como Rational Rose, cubre el ciclo de vida del desarrollo basándose en la metodología RUP.

Según en la investigación planteada por (Sáez, 2008/2009): “Tiene integrado un entorno de desarrollo Eclipse que permite refinar el código generado. Dentro de los componentes Eclipse integrados en RSA, el que más estrechamente relacionado está con el modelado es EMF, marco de trabajo que permite generar código eficiente y adaptable desde los propios modelos. Contempla diferentes tecnologías que complementan la manipulación de modelos basados en EMF: GMF y GEF”.

Es fácil de usar posee la capacidad de instalar sin exponer demasiado de la plataforma Eclipse subyacente. Esto le permite configurar un entorno de banco de trabajo que está mucho más optimizado para las actividades de crear y manejar arquitecturas y diseños, a

Capítulo I. Análisis y fundamentación teórica

diferencia de las actividades de desarrollo de código Java o de extensiones Eclipse. Esto es ideal para personas que sólo desean enfocarse en el modelado y no están interesadas en ninguna generación de código o interacción con el código.

Permite generar los modelos o código partiendo de las transformaciones definidas, pero en el caso de que se efectúen modificaciones sobre el resultado de las transformaciones, éstas no se mantendrán si se vuelve a ejecutar la misma. Permite una generación modelo partiendo con el código.

No obstante, la integración que tiene RSA con EMF, permite mantener las modificaciones realizadas sobre el código generado mediante una transformación, a través de los mecanismos que tiene EMF.

Principales Características:

 Patrones en los modelos MDA: Permite transformaciones de modelo a modelo abarcando diferentes lenguajes de programación.  Transformaciones de Modelos: Las transformaciones en RSA se definen mediante la creación de una configuración de la transformación que es una instancia de una transformación, que incluye información que va a utilizar al ejecutarse. Permite un refinamiento de las transformaciones en el sentido de que se pueden elegir los elementos a transformar tanto en la definición de las transformaciones como en el momento de ejecutarlas.  Ingeniería Inversa: Sí  Estándares: Soporta algunos de los estándares definidos por OMG, tales como UML2.2 (Agregando diagramas de tiempo), XMI y OCL. No soporta los estándares MOF, ni QVT.  Interoperabilidad: Mediante formato XMI mediante formato UML 2.1, y mediante ficheros en formato “Ecore” de Eclipse.  Extensibilidad: Plantea la web oficial de IBM, (Steve Arnold, 2011) como principales: “La extensión de Modelado de Implantación ahora soporta arquitecturas Microsoft: Internet Information Services (IIS), marco SQL Server, .NET,

Capítulo I. Análisis y fundamentación teórica

Silverlight, ASP.NET, Windows Communication Format (WCF), Windows Presentation Format (WPF)” . Además de Eclipse.  Generación de Código: Permite generar los modelos o código partiendo de las transformaciones definidas. Visualización de código y soporte de modelado unificado para Java, C# y VB.NET

1.11.4 JMDA V1.0 Herramienta desarrollada en la UCLV en el año 2010, esta primera versión de una herramienta MDA apoyada en UML, que se realiza como tesis de opción al título de ingeniero informático.

Esta primera versión es capaz de realizar utilizando el lenguaje UML, diagramas de clase, casos de uso y actividades que sirven para la modelación del PIM de un proyecto software. Como implementación de MDA está incompleta, ya que carece de la fase de conversión a código fuente a parir del PSM generado. La herramienta tampoco brinda facilidad de exportar el PSM en algún formato como XMI, para luego ser importado con otra aplicación que lo utilice.

Tabla 2. Comparación de Herramientas MDA Herramientas AndroMDA OptimalJ IBM(RSA) JMDA 1.0 Patrones en los  PIM y PSM  PIM y PSM  PIM y PSM PIM modelos MDA  No ofrece  No ofrece  No ofrece soporte para soporte para soporte para CIM CIM CIM Transformación Automáticas: Automáticas: Automáticas: - de Modelos  PIM a PSM.  PIM a PSM  PIM a PSM  PIM a  PIM a código.  PIM a código código. Ingeniería No No Sí - Inversa

Capítulo I. Análisis y fundamentación teórica

Estándares XMI MOF, UML, XMI, XMI, UML2.2, UML MOF OCL y XML, WSDL, y Perfiles(restriccio 1.0 UML 1.4 J2EE. Perfiles nes OCL), No UML implementa MOF Interoperabilida XMI como XMI como XMI como - d lenguaje de lenguaje de entrada lenguaje de entrada y y almacenamiento entrada y almacenamiento almacenamiento Extensibilidad Apache’s Maven, API EJB permite la Eclipse, SQL - NetBeans, comunicación Server, .NET, etc. ArgoUML, remota utilizando MagicDraw, CORBA Generación de Por medio de J2EE Java, C#,C++ , - Código cartridge. En el SQL Server y lenguaje VB.NET seleccionado

1.11.5 VALORACIÓN Estas herramientas no implementan en su totalidad la especificación completa de MDA, ya que no tienen soporte a la definición de todos los modelos, no implementan transformaciones CIM-PIM.

Debido a que la base del estándar MDA son UML, MOF y XMI, es importante que las herramientas consideren estos estándares para encontrar uniformidad en la interpretación de dicho enfoque. Podemos decir que las tres herramientas utilizan dichos XMI como lenguaje de entrada y almacenamiento llamando la atención que RSA haya optado por la estandarización proporcionada por Eclipse, en vez de basarse en los de OMG.

Todas estas herramientas tienen un conjunto de transformaciones definidas, que permiten configurar, pero no deja crear nuevas transformaciones de forma estándar mediante QVT. Utilizan en menor medida los Perfiles UML y las reglas de restricción OCL.

Capítulo I. Análisis y fundamentación teórica

Solo la herramienta RSA permiten una generación de modelo partiendo con el código pero al efectuarse modificaciones sobre el código estas no se ven reflejadas en el modelo. Cabe mencionar que la aplicación OptimalJ hace distinción entre bloques libres y protegidos en el código para impedir su modificación.

Según el plantea la superioridad de OptimalJ sobre AndroMDA en cuanto a soporte para los patrones de modelado y transformación, utilización de perfiles UML, pero sin lugar a dudas la herramienta más robusta, cumple en mayor medida con el marco de trabajo es RSA, superior a todas las herramientas antes mencionadas, con una interoperabilidad sorprendente.

1.12 TECNOLOGÍAS UTILIZADAS La herramienta que se propone en este trabajo está implementada en el lenguaje de programación JAVA, en el Entorno de Desarrollo Integrado (IDE) NetBeans, para el almacenado de los archivos generados por la misma, se crea un directorio en el disco del sistema. A continuación se dará una breve descripción del lenguaje de programación y la herramienta a utilizar.

Esta es una de las principales características por las que se prefirió este lenguaje de programación, que es un lenguaje independiente de la plataforma. Es una ventaja significativa para los desarrolladores de software, pues antes tenían que hacer un programa para cada sistema operativo, por ejemplo Windows, Linux, Apple, etc.

1.12.1 NETBEANS IDE El IDE NetBeans es un entorno de desarrollo integrado, una herramienta para programadores pensada para escribir, compilar, depurar y ejecutar programas. Escrito en JAVA. Existe además un número importante de módulos para extender el IDE NetBeans. El IDE NetBeans es un producto libre y gratuito sin restricciones de uso. NetBeans IDE soporta el desarrollo de todos los tipos de aplicación Java (J2SE, web, EJB y aplicaciones móviles). Entre sus características se encuentra un sistema de proyectos basado en Ant, control de versiones y “refactoring”.

Capítulo I. Análisis y fundamentación teórica

1.12.2 XPATH: Las expresiones XPath son usadas para consultar las expresiones XMI, seleccionar el conjunto de nodos de entrada, para evaluar condiciones y para calcular valores que serán usados en el código de salida.

Se utilizó la Biblioteca javax.xml.xpath que se encuentra en el JDK desde la versión 1.5, para la lectura del xmi.

1.13 CONCLUSIONES DEL CAPÍTULO Como se ha visto en el capítulo, MDA constituye una aproximación joven todavía, que pese a contar con un sinnúmero de implementaciones en herramientas CASE, la gran mayoría son propietarias, factor este que constituye una limitante para nuestro país que muchas veces no puede pagar una licencia de software propietario. La implementación libre de MDA por excelencia (se desconoce si existe otra) es AndroMDA, que cuenta con una gran calidad, además de una comunidad de desarrolladores que continuamente la están perfeccionando, a pesar de esto AndroMDA tiene algunas limitantes que dificultan su uso, como es el caso de que el modelo inicial del sistema se hace en una herramienta CASE externa que permita la exportación de dicho modelo en formato XMI de versión compatible con la que AndroMDA importa, recomendándose para esto herramientas privativas como MagicDraw y Poseidon certificadas por los desarrolladores del proyecto como las ideales aunque no se descartan otras como ArgoUML que también pueden ser usadas. Debido a eso nuestra tesis se enfoca como un esfuerzo por construir una alternativa a AndroMDA y a las herramientas privativas. Se pretende construir una aplicación capaz de cargar e interpretar un archivo XMI donde está contenido el PSM generado por otra aplicación, para generar el equivalente de código fuente.

Capítulo II. Aspectos del análisis, diseño e implementación

CAPÍTULO 2. ASPECTOS DEL ANÁLISIS, DISEÑO E IMPLEMENTACIÓN

En este capítulo se aborda los detalles referentes a la implementación de la herramienta CASE jMDA2.0 referentes a la implementación de código. El proceso propuesto como solución a la problemática planteada en la introducción de esta tesis se expondrá mediante el uso del Lenguaje Unificado de Modelado para mostrar los aspectos funcionales, estructurales y de comportamiento.

2.1.1 REQUISITOS FUNCIONALES DEL SISTEMA

 Permitir importar un PSM contenido en un fichero XMI donde está contenido un diagrama de clases el cual será utilizado para generar código fuente en java.  Permitir mostrar código en pantalla producto de la interpretación del PSM contenido en el XMI.  Permitir la modificación del código mostrado en pantalla en caso que contenga incongruencias o si se desea añadir nuevas funcionalidades.  Permitir salvar código en fichero de extensión .java que pueda ser cargado desde un IDE de java o compilado directamente.

2.1.2 REQUISITOS NO FUNCIONALES DEL SISTEMA  Requerimientos de hardware: Compatible en una PC con microprocesador Pentium IV, como mínimo 512 MB de memoria RAM (en dependencia de sistema operativo).

 Requerimientos de software: Puede funcionar en cualquier sistema operativo (Windows, Linux, entre otros) que tengan instalado una versión de JRE.

 Usabilidad: La herramienta es fácil de usar. Cuenta con una interfaz de usuario intuitiva.

Capítulo II. Aspectos del análisis, diseño e implementación

2.2.1 CASOS DE USO Y ACTORES DE LA HERRAMIENTA JMDA VERSIÓN 2.0

El diagrama de casos de uso representa la forma en que un actor opera con el sistema en desarrollo, además de la forma, tipo y orden en cómo los elementos interactúan. El caso de uso es una operación o tarea específica que ayuda a los desarrolladores de software a trabajar con los usuarios finales del producto, con el objetivo de determinar la forma en que será usado el sistema que se está desarrollando.

A continuación se realiza el análisis y diseño de los casos de uso para esta herramienta y su respectiva descripción. Se define como un único Actor al Desarrollador de Software, el cual se concentra en generar el código de manera automática, y luego de ser necesario completar, este pierde de vista los modelos construidos.

FIG2.1 DIAGRAMA DE CASOS DE USO Y ACTORES

Capítulo II. Aspectos del análisis, diseño e implementación

FIG 4. DIAGRAMA DE CASOS DE USOS DEL SISTEMA

TABLA DESCRIPCION DE CASOS DE USO Caso de USO Descripción Importar PSM en Importar de la Herramienta JMDA un modelo PSM en formato XMI Formato XMI Mostrar Código Mostrar código generado en la pantalla del Programa, al hacer clic en en Pantalla el botón Mostrar Código. Modificar Código Al mostrarse el código en la pantalla el Desarrollador de Software tiene la oportunidad de modificarlo antes de salvarlo. Salvar Código Exporta código generado por la herramienta a un archivo .java

Capítulo II. Aspectos del análisis, diseño e implementación

2.2.2 DIAGRAMA DE ACTIVIDADES DEL SISTEMA

FIG 2.2 DIAGRAMA DE ACTIVIDAD DEL SISTEMA PARA EL CASO DE USO IMPORTAR ARCHIVO XMI

2.2.3 DIAGRAMA DE CLASES DEL DISEÑO Un diagrama de clase representa pare de la estructura del sistema donde se muestran las entidades por las cuales está compuesto un sistema. Siendo utilizados tanto para mostrar lo

Capítulo II. Aspectos del análisis, diseño e implementación

que puede hacer el sistema (análisis), como para mostrar cómo puede ser construido el mismo (diseño).

FIG 2.3 DIAGRAMA DE CLASES DEL DISEÑO

Capítulo II. Aspectos del análisis, diseño e implementación

FIG 2.4. DIAGRAMA DE CLASES PARA ANALIZAR LA LOGICA DE GENERAR CODIGO

Se programó la clase NameSpaceContextModelXMIUML que implementa la interfaz NamespaceContext que contiene los prefijos y lo esquemas del formato XMI y UML.

2.2.4 DIAGRAMA DE SECUENCIAS PARA EL ESCENARIO: IMPORTAR ARCHIVO XMI Los diagramas de secuencia son diagramas de interacción entre los objetos que hacen énfasis en la ordenación temporal de los mensajes y se modelan para cada caso de uso.A continuación se muestra el diagrama de secuencia para el caso de uso Importar Archivo XMI.

Capítulo II. Aspectos del análisis, diseño e implementación

FIG2.5 DIAGRAMA DE SECUENCIA PARA ESCENARIO IMPORTAR ARCHIVO XMI

En la figura se muestra el flujo de control entre los objetos JCGview desde donde se crea un objeto JFileChooser mediante el cual se obtiene el camino del archivo seleccionado (XMI) el cual es utilizado por JCGview para crear un objeto CaptureModel desde donde es comprobada la integralidad del archivo captado. Después de esto habilita el botón Mostrar Código y destruye los objetos creados.

2.2.5 Diagrama de actividades para caso de uso mostrar código.

Capítulo II. Aspectos del análisis, diseño e implementación

FIG 2.6 DIAGRAMA DE ACTIVIDADES PARA GENERAR CODIGO

Capítulo II. Aspectos del análisis, diseño e implementación

2.3 CONCLUSIONES DEL CAPÍTULO En este capítulo se pudo apreciar lo relativo al análisis y diseño del software propuesto. Se determinó al actor del sistema representando además los casos de usos que ejecuta el mismo, que constituyen una representación de los requisitos funcionales, así también se definieron los requisitos no funcionales y se utilizaron diagramas de actividades para describir a los casos de uso. Se modeló un diagrama de clases que representa el diseño estructural del software, resaltando escenarios del software en ejecución mediante diagramas de secuencia y comunicación.

Capítulo III. Descripción de la solución propuesta

CAPÍTULO 3. DESCRIPCIÓN DE LA SOLUCIÓN PROPUESTA

En este capítulo se desarrolla la descripción de la solución propuesta donde se resaltan las soluciones algorítmicas y computacionales de la primera versión de esta herramienta.

La herramienta MDA en su versión 2.0

3.1 ESTRUCTURA DE ARCHIVOS XMI PARA EL FORMATO UML: Este trabajo de curso se concibió como un trabajo paralelo, en el cual otro desarrollador de software realizaría sobre la herramienta JMDA v1.0 el proceso de transformación de los modelos PIM a PSM, conjuntamente se proponía que al estar los diagramas del PSM, a partir de este se pudiera generar un documento XMI con la captura de los elementos utilizados en el diagrama, para de esta manera compartir modelos UML entre diferentes herramientas de modelado. Estos proyectos no pudieron coincidir por lo que en este trabajo se tomó como especificidad los diagramas utilizados por la herramienta ArgoUML, tomando como referencia XMI v 1.2. Como ya se mencionó en el capítulo anterior la herramienta CASE ArgoUML implementa como lenguaje de intercambio XMI 1.2 para diagramas UML v 1.4.

Principales Etiquetas

La siguiente tabla muestra en una las principales etiquetas de un documento XMI en formato UML. En la columna de la izquierda se muestra el nombre de las etiquetas (e), y los atributos(a), mientras que en la columna de la derecha el valor.

Capítulo III. Descripción de la solución propuesta

xml version = '1.0' encoding = 'UTF-8' ?> JMDA 2.o

La primera línea. Con ella deben empezar todos los documentos XMI, ya que es la que indica que lo que la sigue es XML:  versión: indica la versión de XML usada en el documento(Utilizaremos la 1.0)  encoding: la forma en que se ha codificado el documento(Por defecto es UTF-8)

Seguida por la etiqueta raíz: , la, cual engloba todo el documento:

 xmi.version: Indica la versión del formato XMI a utilizar en el documento(utilizaremos 1.0)  xmlns:UML: El namespace utilizado  timestamp: Hora en que fue generado el archivo. Dentro del Nodo Raíz encontraremos dos etiquetas importantes que contendrán el contenido del modelo:

 XMI.header: Contendrá los valores por defecto de la documentación(fecha de ultimo versión, que se construyó con la herramienta JMDA) y del Metamodelo(UML v1.4):

Capítulo III. Descripción de la solución propuesta

La etiqueta UML: Model contiene el modelo en formato UML, con atributos como el id, nombre y si es abstracto etc.

Se le agrega además una etiqueta UML: Namespace.ownedElement que contiene las etiquetas correspondientes para cada clase (UML:Class) y para cada dependencia (UML:Association, generalización).

Tabla 3. Principales atributos de una etiqueta Class de UML Atributos Características id Id para referenciar la clase. name Nombre de la clase. visibility Visibilidad de la clase. isRoot ¿Es raíz? (true or false) isLeaf ¿Es una clase hoja?(es aquella que no puede tener clases que la hereden),en java es final.(true or false) isAbstract Es abstracta.(true or false)

Anidada dentro de la etiqueta clase se encuentran sus características, que pueden ser atributos, operaciones, si hereda de una determinada clase contiene hace una referencia al id de la clase padre id que apunta a etc. Están comprendidas en la etiqueta: .

3.2 DESCRIPCIÓN DE LA HERRAMIENTA. El objetivo de esta herramienta es generar código en JAVA a partir de un PSM, utilizando UML en formato XMI 1.4.

La herramienta implementada muestra un ambiente de trabajo sencillo, lo cual facilita que el usuario tenga un buen desenvolvimiento en la ejecución del programa. Esto brinda la posibilidad de completar esta tarea en un corto período de tiempo.

Posee una barra de menú que contiene:

Capítulo III. Descripción de la solución propuesta

 Importar archivo XMI: Desplegara una ventana con la posibilidad de importar un archivo XMI.  Salvar código: Guarda el código generado del proyecto mostrado en la pantalla, en un archivo .java. Este no será habilitado hasta que el no haya sido importado el archivo, comprobado que su sintaxis sea correcta y mostrado el código generado en la pantalla.  Salir: Salida del sistema.

FIG 3.1 VENTANA PRINCIPAL DE LA HERRAMIENTA JMDA.

Al ser seleccionar el menú “Importar Archivo XMI” mostrara la ventana del mismo nombre donde sera importado el fichero XMI.

Dicha consta con los botones:

• Cancelar: Cerrar la ventana y volver a la principal • Mostrar Codigo en pantalla: El cual sera abilitado cuando sea importado el archivo XMI y sea chequeada que su sintaxis sea correcta y luego generado el Modelo. • Importar: Despliega una ventana de selección donde se elige el fichero XMI a importar.

Al dar click en el botón importar se muestra una ventana de selección donde se elige el fichero XMI a importar. Dicha ventana se le coloco un un filtro para que

Capítulo III. Descripción de la solución propuesta

FIG 3.2 VENTANA IMPORTAR ARCHIVO XMI Y VENTANA DE SELECCIÓN

La siguiente figura muestra dicha ventana al ser importado un archivo determinado con el botón mostrar código en pantalla habilitado y la localización del mismo mostrado en un JTextField.

Capítulo III. Descripción de la solución propuesta

FIG 3.3. CONTENIDO DEL MODELO EXPORTADO EN FORMATO XMI

Si la sintaxis del documento XMI no es correcta, mostrara JOptionPane indicando que el archivo es incorrecto.

FIG.3.4 ERROR

3.3 CONCLUSIONES DE CAPÍTULO En este capítulo se trató sobre las características de la aplicación, desde detalles de su implementación hasta aspectos vinculados con su usabilidad. Se detalla la estructura del XMI que recibe como entrada, cuáles son sus principales etiquetas y la semántica de su sintaxis. Además se mostraron ventanas donde se explica cómo trabajar con la herramienta.

Conclusiones

CONCLUSIONES

1. Se hizo una exhaustiva revisión del estado actual de la aproximación MDA, así como de los estándares y tecnologías relacionados con esta haciendo hincapié en XMI. También se estudió algunas herramientas CASE actuales que permiten la transformación de uno o varios diagramas UML a código fuente y otras herramientas CASE que implementan MDA, para establecer una fuente de conocimiento por donde guiar el desarrollo de la tesis.

2. Se planteó el análisis y diseño en base al lenguaje UML de la herramienta propuesta con la que se pretende dar solución a las problemáticas planteada en esta tesis. Enfocándose en los aspectos estructurales y en escenarios dentro de la misma.

3. Se logró desarrollar el módulo PSM-Código de la segunda versión de la herramienta jMDA, permitiendo a desarrolladores tomar el diagrama de clases de un Modelo Especifico de la Plataforma Java en formato XMI y en base a él generar código fuente, con facilidades para modificarlo en caso de que no se ajuste al código esperado, para después poderlo importar como un archivo de extensión .java.

Recomendaciones

RECOMENDACIONES

1. Divulgar el software para que sea probado por especialistas: analistas de sistemas y desarrolladores.

2. Seguir perfeccionándolo con futuras versiones, donde:

a. Se le añada soporte para otros diagramas UML (como secuencia y comunicación) contenidos en el PSM que recibe como entrada en formato XMI, permitiendo así incrementar la cantidad y calidad de código fuente generado.

b. Admitir otros PSM diferentes y su respectiva generación de código.

c. Estandarizar el archivo XMI que recibe como entrada para hacerlo compatible con otros software de modelado o generado de PSM.

Referencias bibliográficas

REFERENCIAS BIBLIOGRÁFICAS ÁLVARO JIMÉNEZ RIELO, J. M. V. M. 2009. Desarrollo de Editores Gráficos para el Modelado de Bases de Datos Objeto-Relacionales: SQL2003 y Oracle 10g Universidad Rey Juan Carlos.

ANACLETO, V. A. 2005 a. Arquitectura dirigida por modelos.

ANNEKE KLEPPE, J. W. Y. W. B. 2005. MDA Explained – The Model Driven Architecture: Practice And Promise. .

BROWN, A. 2004. An introduction to Model Driven Architectures.

BUSTELO, B. C. P. G. 2005. Desarrollo ágil de software con arquitectura dirigida por modelos.

COLSA, L. E. C. D. 2005. Arquitectura dirigida por modelos para J2ME

J. GARCÍA MOLINA, J. R., M. MENÁRGUEZ, M.J. ORTÍN, J. SÁNCHEZ 2007. Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler

JUAN BERNARDO QUINTERO, R. A. D. P. 2007. Marco de Referencia para la Evaluación de Herramientas Basadas en MDA

JUAN BERNARDO QUINTERO, R. A. D. P. 2007 MDA Y EL PAPEL DE LOS MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE.

PINEDA, C. S. 2008. Un Método de Desarrollo de Hipermedia Dirigidopor Modelos.

QUINTERO, J. B. 2007. MDA Y EL PAPEL DE LOS MODELOS ENEL PROCESO DE DESARROLLO DE SOFTWARE.

ROSENDO DE JESÚS MORENO RODRÍGUEZ 2008. MDA – ARQUITECTURA DIRIGIDA POR MODELOS. Cuba.

SÁEZ, P. A. F. 2008/2009. Un Análisis Crítico de la Aproximación Model-Driven Architecture Universidad Complutense de Madrid.

STEVE ARNOLD. 2011. Qué hay de Nuevo en IBM Rational Software Architect 8.0 [Online]. Available: http://www.ibm.com/developerworks/ssa/views/rational/ [Accessed].

VERÓNICA BOLLATI, J. M. V., BELÉN VELA, ESPERANZA MARCOS 2008. Una revisión de herramientas MDA

VICENTE, J. R. 2004. Ingenieria de Modelos con MDA.

Bibliografía

BILBIOGRAFÍA

RODRÍGUEZ, A. & 2006. Hacia la obtención de Clases de Análisis y Casos de Uso desde modelos de Procesos de Negocio.

ÁLVARO JIMÉNEZ RIELO, J. M. V. M. 2009. Desarrollo de Editores Gráficos para el Modelado de Bases de Datos Objeto-Relacionales: SQL2003 y Oracle 10g Universidad Rey Juan Carlos.

ANACLETO, V. A. 2005 a. Arquitectura dirigida por modelos.

ANNEKE KLEPPE, J. W. Y. W. B. 2005. MDA Explained – The Model Driven Architecture: Practice And Promise. .

BEATRIZ PÉREZ LAMANCHA, P. R. M., IGNACIO GARCÍA-RODRÍGUEZ DE GUZMÁN, MACARIO POLO USAOLA & 2008. Propuesta para pruebas dirigidas por modelos usando el perfil de pruebas de UML 2.0 Universidad de la República de Uruguay

BROWN, A. 2004. An introduction to Model Driven Architectures.

BUSTELO, B. C. P. G. 2005. Desarrollo ágil de software con arquitectura dirigida por modelos.

CÁRCAMO, A. C. 2005. TECNOLOGÍAS MDA (MODEL DRIVEN ARCHITECTURE) PARA EL DESARROLLO DE SOFTWARE

COLSA, L. E. C. D. Arquitectura dirigida por modelos para J2ME

COLSA, L. E. C. D. 2005. Arquitectura dirigida por modelos para J2ME

DAVID COLQUE C., R. V. P. 2006. INTEGRACIÓN DE TECNOLOGÍAS EN UNA PLATAFORMA J2EE DIRIGIDA POR MODELOS.

DELGADO, A. 2009 Desarrollo de Software con enfoque en el Negocio

ENRÍQUEZ, A. M. A. M. 2006. Método de Desarrollo Arquitectónico en Grupo

GIANDINI, R. S. 2007. Un Marco Formal para Transformaciones en la Ingeniería de Software Conducida por Modelos

GONZALO GÉNOVA, M. C. V., MÓNICA MARRERO (ed.) 2008. Sobre la diferencia entre análisis y diseño, y por qué es relevante para la interpretación de los modelos en la Ingeniería Dirigida por Modelos

Bibliografía

J. GARCÍA MOLINA, J. R., M. MENÁRGUEZ, M.J. ORTÍN, J. SÁNCHEZ 2007. Un estudio comparativo de dos herramientas MDA: OptimalJ y ArcStyler JUAN BERNARDO QUINTERO, R. A. D. P. 2007. Marco de Referencia para la Evaluación de Herramientas Basadas en MDA

JUAN BERNARDO QUINTERO, R. A. D. P. 2007 MDA Y EL PAPEL DE LOS MODELOS EN EL PROCESO DE DESARROLLO DE SOFTWARE.

MARTA ZORRILLA, P., BELÉN VELA, PHD. , ESPERANZA MARCOS, PHD. . 2007. Una Aproximación Dirigida por Modelos para Diseñar y Construir Esquemas XML: Un Caso de Estudio

OMG-BP. 2006. OBJECT MANAGEMENT GROUP. Business processes and the OMG [Online]. Available: http://www.omg. [Accessed].

PINEDA, C. S. 2008. Un Método de Desarrollo de Hipermedia Dirigidopor Modelos. QUINTERO, J. B. 2007. MDA Y EL PAPEL DE LOS MODELOS ENEL PROCESO DE DESARROLLO DE SOFTWARE.

RODRÍGUEZ, R. D. J. M. 2009. Aspectos de MDA (Arquitectura Dirigida por Modelos). Cuba.

ROSENDO DE JESÚS MORENO RODRÍGUEZ 2008. MDA – ARQUITECTURA DIRIGIDA POR MODELOS. Cuba.

SÁEZ, P. A. F. 2008/2009. Un Análisis Crítico de la Aproximación Model-Driven Architecture Universidad Complutense de Madrid. SOLEY, R. 2000. Model Driven Architecture

STEVE ARNOLD. 2011. Qué hay de Nuevo en IBM Rational Software Architect 8.0 [Online]. Available: http://www.ibm.com/developerworks/ssa/views/rational/ [Accessed]. SYSTEMS, S. 2007. MDA Overview

VERÓNICA A. BOLLATI, J. M. V., BELÉN VELA Y ESPERANZA MARCOS 2007. Análisis de herramientas MDA. VERÓNICA BOLLATI, J. M. V., BELÉN VELA, ESPERANZA MARCOS 2008. Una revisión de herramientas MDA VIADAN DEVEDZIÉC, D. G. 2006. Model Driven Architecture and Ontology Development.

VICENTE, J. R. 2004. Ingenieria de Modelos con MDA. ZÁRATE, N. A. R. 2007. Un enfoque MDA para el desarrollo de aplicaciones basadas en un modelo de componentes orientados a servicios.

Bibliografía

ZÁRATE, N. A. R. 2007. Un enfoque MDA para el desarrollo de aplicaciones basadas en un modelo de componentes orientados a servicios.