Universidad Central Marta Abreu de Las Villas. Facultad de Matemática, Física y Computación. Licenciatura en Ciencia de la Computación

Transcripción

1 Universidad Central Marta Abreu de Las Villas Facultad de Matemática, Física y Computación Licenciatura en Ciencia de la Computación TRABAJO DE DIPLOMA Desarrollo de Herramienta para Arquitectura Dirigida por Modelos jmda versión 3.0. Módulo PIM-PSM. Autor: Anibal Hernández Oñoz. Tutor: Dr. Rosendo Moreno Rodríguez. Santa Clara 2013

2 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 del Seminario de Programación

3 Pensamiento Por qué esta magnífica tecnología científica, que ahorra trabajo y nos hace la vida más fácil, nos aporta tan poca felicidad? La repuesta es está, simplemente: porque aún no hemos aprendido a usarla con tino. Albert Einstein I

4 Dedicatoria A mi familia y en especial a mis padres, por su gran amor y por ayudarme a llegar al final de este reto. II

5 Agradecimientos A mis padres por su amor, apoyo, por estar ahí en cada momento que los necesite, por ser mis amigos, mis confidentes y por alentarme durante todo este camino de mi vida, gracias. A mis abuelos queridos por su amor y entrega durante todos mis estudios, gracias. A mi hermano, cuñada y mi gran tesoro mi sobrinita Liana, por su cariño, gracias. A toda mi familia en general por su confianza, amor, dedicación, entrega y contribución; que me brindaron durante todos estos años de lucha, gracias. A mi otra familia de Vueltas que me apoyaron, creyeron en mí y por su incondicionalidad hacia mí, gracias. A todos mis amigos que siempre estuvieron ahí junto a mí en las buenas y en las malas, gracias. A mi tutor Rosendo por su ayuda y contribución, pero sobre todo, por su Paciencia. A todos los que de una forma u otra contribuyeron a la realización de este trabajo y a la culminación de esta etapa de mi vida. III

6 Resumen La Arquitectura Dirigida por Modelos (MDA) es un nuevo enfoque de trabajo que juega un papel importante en el proceso de desarrollo de software. 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 funciones para convertir un modelo de un nivel de abstracción a otro, basándose en lenguajes y mecanismos estándares. Estudios previos sobre las herramientas que soportan esta arquitectura ha demostrado que aún no existe un software completo, puramente MDA y es entonces que en el proyecto de investigación Desarrollo de métodos y tecnologías avanzadas de Ingeniería de Software para el desarrollo de Sistemas de Información del Centro de Estudios de Informática de la UCLV se plantea la tarea de creación de una herramienta MDA propia, dividida en varios módulos. Este trabajo presenta una tercera versión del módulo que permite el diseño gráfico de una serie de diagramas UML en el nivel de Modelo Independiente de la Plataforma (PIM), así como la conversión automatizada; y la creación de los diagramas de Artefacto y Despliegue al nivel de Modelo Específico de una Plataforma (PSM), que en este caso se orientó fuese basado en Java. En este trabajo se muestra además una descripción breve de cómo utilizar esta tercera versión de la herramienta jmda que tiende a simplificar la labor de análisis y el diseño de software. Palabras Claves: Ingeniería del Software, Arquitectura Dirigida por Modelos, Herramienta CASE. IV

7 Abstract The Directed Architecture for Models (MDA) it is a new work focus that plays an important paper in the process of software development. The most complicated task in this new methodology is the transformation among models that it is sustained in the definition of the functions to convert a model of a level of abstraction to other, being based on languages and standard mechanisms. Previous studies on the tools that support this architecture have demonstrated that a complete software doesn't still exist, purely MDA and it is then that in the investigation project "Development of methods and advanced technologies of Engineering of Software for the development of Systems of Information" of the Center of Studies of Computer science of the UCLV it thinks about the task of creation of a tool own MDA, divided in several modules. This work presents a third version of the module that allows the graphic design of a series of diagrams UML in the level of Independent Model of the Platform (PIM), as well as the automated conversion; and the creation of the diagrams of Device and Unfolding at the level of Specific Model of a Platform (PSM) that was guided in this case was based on Java. In this work it is also shown a brief description of how to use this third version of the tool MDA that spreads to simplify the analysis work and the software design. Key Works: Engineering of the Software, Directed Architecture for Models, Tool MARRIES. V

8 Tabla de contenido Introducción:... 1 Capítulo 1. Antecedentes y Fundamentación Teórica Antecedentes Conceptos fundamentales Arquitectura Dirigida por Modelos Aspectos generales y fundamentos de MDA Desarrollo con MDA Transformación entre modelos Intercambio de diagramas Principales ventajas que brinda MDA UML Diagramas que brinda UML Análisis de herramientas CASE con soporte MDA Propietarias Herramientas MDA Opens Source Análisis de la herramienta CASE jmda v1.0 y jmda v2.0: Conclusiones Parciales del capítulo Capítulo 2: Análisis y Diseño de la Herramienta Diagramas del Análisis y el Diseño del módulo PIM-PSM de la herramienta CASE jmda v Diagrama de Casos de Uso del sistema Diagrama de paquete del software Diagrama de clases del software Capítulo 3. Descripción de la Implementación y Uso de la herramienta Breve descripción del proceso de codificación Descripción del uso de la herramienta

9 3.2.1 Ejecución y pantalla de presentación Creación de diagramas con jmda versión Exportación de archivo XMI del Diagrama de clases del PSM Conclusiones Recomendaciones Referencias Bibliográficas Bibliografía... 56

10 Introducción: La ingeniería de software es una disciplina que tiene como objetivo crear técnicas y métodos para desarrollar y mantener software de calidad. Esta ingeniería trata con áreas muy diversas de la informática y de las ciencias de la computación, tales como construcción de compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistemas de información y aplicables a infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca, control de tráfico, meteorología, derecho, Internet, etc. Con el fin de ayudar a la ingeniería de software se han desarrollado una gran variedad de aplicaciones informáticas conocidas por herramientas CASE Computer Aided Software Engineering o Ingeniería de Software Asistida por Computadoras cuya función es la de aumentar la productividad en el desarrollo de software reduciendo los costos en términos de tiempo y dinero. Dichas herramientas se construyen para seguir determinados paradigmas y principios y nos sirven para abarcar todo el ciclo de vida de desarrollo del software brindándonos desde la facilidad de diseñar un proyecto, cálculo de costo hasta la generación de código fuente en algún lenguaje de programación, detección de errores, documentación, entre otras. Se espera que una herramienta CASE genérica, sea del tipo que sea, pueda ser capaz de cumplir con requisitos como: mejorar la productividad en el desarrollo y mantenimiento del software, aumentar la calidad del software, reducir el tiempo y costo de desarrollo y mantenimiento de los sistemas informáticos, mejorar la planificación de un proyecto, aumentar la biblioteca de conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los requisitos, automatizar el desarrollo de software, la documentación, la generación de código, las pruebas de errores y la gestión del proyecto, ayudar a la reutilización del software, a la portabilidad y estandarización de la documentación, gestión global en todas las fases de desarrollo de software con una misma herramienta y facilitar el uso de todas las metodologías propias de la ingeniería de software. Dentro de los diversos paradigmas y marcos de trabajo de la ingeniería de software se encuentra uno que ha ganado fuerza en los últimos años: la Arquitectura Dirigida por Modelos, considerada según algunos autores como una nueva forma de producir software, brindando una solución, según OMG Object Management Group, para los 1

11 Introducción cambios de negocio y de tecnología, permitiendo construir aplicaciones independientes de la plataforma, para después ser llevadas a plataformas tales como JEE,.NET, CORBA, entre otras. Este paradigma usa modelos del sistema que se quiere construir, en distintos niveles de abstracción. MDA pretende separar, por un lado, la especificación de las operaciones y datos de un sistema, y por el otro, los detalles de la plataforma en la que el sistema será construido.(omg, 2003) Planteamiento del problema: En la Universidad Central Marta Abreu de Las Villas en el año 2010 se desarrolló las primeras versiones de una herramienta MDA apoyada en UML llamada jmda, como tesis de opción al título de Licenciado en Ciencias de la Computación. Dicho software, en las primeras versiones, quedó inconcluso pues solo brinda cobertura para unos pocos diagramas UML (Casos de Uso, Clases y Actividades, no completamente), carece de la fase de conversión al Modelo Específico de la Plataforma y de este al código fuente y brinda soporte solamente para la plataforma java. Paralelamente y desde hace un poco más de tiempo se vienen desarrollando en el mundo algunas herramientas de apoyo a la ingeniería de software que se adhieren al paradigma MDA y que cuentan con licencias de software libre; cabe mencionar el proyecto AndroMDA fundado en el 2003 y GMF de Eclipse, que pueden servir de base al desarrollo de futuras aplicaciones con similar fin, sin embargo aún no se pueden considerar herramientas puras MDA pues no incluyen algunas fases y conversiones, o se apoyan en otras herramientas como MagicDraw para el diagramado (esta herramienta es propietaria). Además, la industria de software nacional no cuenta con ninguna herramienta de este tipo que sea de su autoría netamente; por lo que contar con una aplicación de dichas características, que pueda irse perfeccionando gradualmente pudiera significar un paso más en el desarrollo de nuestra industria en el orden tanto económico como tecnológico. Problema tecnológico: La necesidad de contar con una herramienta profesional de origen nacional que implemente el paradigma MDA superando las limitantes con que cuentan las existentes en la actualidad, ya sea el pago de una licencia en el caso de las propietarias o limitantes de orden técnico en el caso de las de código abierto, que imposibilitan el uso o el 2

12 Introducción desempeño de las mismas en nuestro país para el desarrollo de sistemas de información y otros software con la productividad requerida. Este planteamiento nos lleva a definir los siguientes objetivos para esta tesis: Objetivo general: Crear una nueva versión del módulo PIM-PSM de la herramienta CASE jmda de la UCLV añadiéndole soporte con más diagramas UML y perfeccionando los creados en las versiones anteriores en el modelo independiente de plataforma, agregándole los diagramas de modelado arquitectónico al modelo específico de plataforma. Objetivos específicos: 1. Analizar críticamente las herramientas existentes para MDA, en primer lugar las versiones anteriores de jmda así como AndroMDA, GMF entre otras. 2. Modelar con ayuda de UML la herramienta a desarrollar, perfeccionando la arquitectura de la misma. 3. Implementar en Java una nueva versión del módulo PIM-PSM de la herramienta CASE jmda de manera que: en el Modelo Independiente de la Plataforma (PIM) se perfeccionen los diagramas de Casos de uso y Actores, Secuencia, Actividades y Estados. en el Modelo específico de Plataforma (PSM) crear los diagramas de Artefacto y Despliegue. Preguntas técnicas: Cómo perfeccionar el trabajo con los diagramas de UML existentes y como añadir los diagramas de Interacción (Secuencia), Actividad, Estado, Artefacto y Despliegue? Qué posible marco de trabajo para la programación en java se puede utilizar, tal que facilite el proceso de codificación? Cuál metodología de desarrollo ágil pudiera ser más conveniente usar para el desarrollo de la herramienta? La investigación que se desarrolla se sustenta en la siguiente hipótesis: 3

13 Introducción Hipótesis: El perfeccionamiento de la herramienta jmda es un paso de avance al desarrollo de una definitiva herramienta MDA nacional integradora, que posibilitará dar cumplimiento a una de las tareas principales del proyecto de investigación desarrollado, que tiende a brindar una alternativa para la ingeniería de software acorde con las necesidades de productividad de la industria de software cubano. Viabilidad del trabajo: Para el desarrollo del trabajo se cuenta con una base bibliográfica y de desarrollo programático adecuada, así como el tiempo y las herramientas de software y hardware necesarias. Organización de la Tesis: Para una mejor comprensión del presente documento, la estructura del contenido queda conformada de la siguiente manera: Capítulo 1. Antecedentes y Fundamentación Teórica : En el cual se abordan los elementos teórico-conceptuales que sustentan el problema científico y los objetivos. Se hace un profundo estudio del arte donde tenemos en cuenta definiciones, conceptos, estándares, además se fundamenta la selección de tecnologías, herramientas y metodología con las cuales se debe desarrollar el sistema. Los temas fundamentales tratados son MDA, UML, Herramientas CASE, así como la valoración crítica de las versiones precedentes. Capítulo 2: Análisis y Diseño de la Herramienta : En este se realiza el análisis y diseño de la herramienta CASE que se propone como solución de este trabajo, en base a varios diagramas UML correspondientes. Capítulo 3: Descripción de la Implementación y Uso de la herramienta : En el que se resaltan las soluciones algorítmicas y computacionales de esta versión del módulo PIM-PSM de la herramienta jmda, la cual permite modelar los Diagramas de Casos de Uso, Clases, Actividades, Secuencia y Estado en el Modelo Independiente de la Plataforma (PIM), así como el diagrama de Clases, diagrama de Secuencia, diagrama de Actividades, el diagrama de Estado que se genera, y la creación de los diagramas de Artefacto y Despliegue a Modelo Específico de una Plataforma (PSM), para Java. 4

14 Capítulo 1. Antecedentes y Fundamentación Teórica En este capítulo se profundiza en los antecedentes de esta tesis y en la teoría sobre la que se sustenta, o sea, la metodología de Arquitectura Dirigida por Modelos y UML. También se realiza una descripción de algunas de las distintas herramientas CASE que utilizan MDA, tanto libres como propietarias, existentes actualmente. 1.1 Antecedentes El profesor de la disciplina Ingeniería de Software de la Universidad Central Marta Abreu de las Villas el Dr. Rosendo Moreno Rodríguez, tutor de esta tesis, viene trabajando desde hace algunos años en la construcción de una herramienta CASE que implemente el paradigma de Arquitectura Dirigida por Modelos. De su trabajo conjunto con antiguos estudiantes del centro resultó las primeras versiones de la herramienta CASE jmda, capaz de realizar utilizando UML, diagramas casos de uso, de clase y actividades que sirven para la modelación de un proyecto software independiente de la plataforma y luego realizar una transformación del diagrama de clases con la especificación de la plataforma JEE. Dicho software se pretende perfeccionar con esta tesis añadiéndole soportes para los siguientes diagramas de UML: Interacción, Estado, Artefacto y Despliegue. 1.2 Conceptos fundamentales Para lograr un mejor entendimiento se detallan algunos conceptos primarios. Modelo: El modelo de un sistema no es más que la representación de este en forma de texto y /o dibujo, donde el texto se puede presentar en lenguaje natural o lenguaje de modelado, por ejemplo UML. Metamodelado: Consiste en el análisis, construcción y desarrollo de esquemas, reglas, restricciones, modelos y teorías que se utilizan para el modelado de clases predefinidas de problemas. Arquitectura: La arquitectura de un sistema es la especificación de las partes del mismo, las interacciones entre ellas y sus normas de interacción haciendo uso de las conexiones especificadas. (Cuesta M. Albeiros, 2009). 5

15 Capítulo 1 Dirigido por modelos: Se dice que MDA es dirigido por modelos porque usa los modelos para dirigir el ámbito del desarrollo, el diseño, la construcción, el despliegue, la operación, el mantenimiento y la modificación de los sistemas. (S., 2003) Plataforma: Una plataforma es un conjunto de subsistemas y tecnologías que aportan un conjunto coherente de funcionalidades a través de interfaces y determinados patrones de uso, que cualquier aplicación que se construya para esa plataforma puede usar sin preocuparse por los detalles de la implementación o como se lleva a cabo la misma dentro de la plataforma. (Cuesta M. Albeiros, 2009) Marco de trabajo: Un marco de trabajo o framework puede ser visto genéricamente como un conjunto de procesos y tecnologías que se utilizan para dar solución a un problema que resulta complejo. En la informática y en especial en el desarrollo de software es una estructura conceptual y tecnológica de soporte definido, compuesta por módulos de software concretos, permitiendo organizar y desarrollar otros proyectos de software de manera más fácil. 1.3 Arquitectura Dirigida por Modelos Figura 1: El consorcio formado por múltiples empresas punteras de la industria informática es el encargado de mantener estándares y tecnologías tales como UML, CORBA, XMI y MDA. La Arquitectura Dirigida por Modelos, Model Dirven Architecture o simplemente MDA por sus siglas en inglés, es una especificación promovida por el OMG en el año 2000 integrando diferentes estándares y especificaciones definidos por la misma organización con el fin de proveer una solución a los problemas relacionados con los cambios en los modelos de negocio, la tecnología y la adaptación de los sistemas de información a los mismos. La idea principal que subyace en MDA es separar la especificación de la funcionalidad de un sistema software de los detalles sobre cómo se lleva a cabo en una determinada plataforma, de manera que los desarrolladores escriban modelos centrados en la lógica de la aplicación y de forma automática se genere el código con los detalles propios de una plataforma (Franky, 2010). A este nuevo paradigma se le ha denominado Ingeniería de Modelos o Desarrollo Dirigido por 6

16 Capítulo 1 Modelos Model-Driven Development o MDD por sus siglas en inglés, refiriéndose a las actividades que llevan a cabo los desarrolladores utilizando MDA. Según (T. Gardner, 2006) la especificación promovida por OMG se centra en la creación de un marco de trabajo formal donde MDD pueda operar. 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. (Anacleto, 2011) Aspectos generales y fundamentos de MDA Figura 1-2 Esquema de la Arquitectura Dirigida por Modelos () El marco de trabajo que propone la especificación MDA está representado en tres capas, Figura 1-2, donde se muestran las tecnologías, especificaciones y estándares que lo componen según la visión que tiene OMG del mismo, así como el alcance, o sea, los marcos donde se pretende usar para ofrecer soluciones: 1. La capa interna o capa de modelación: está representada por el lenguaje de modelación UML Unified Modeling Language, el más utilizado para este fin; el estándar para la ingeniería dirigida por modelos MOF Meta-Object Facility, diseñado en sus inicios como una arquitectura de metamodelado para definir UML utilizándose también para definir los principios creación y manipulación de modelos y metamodelos usando interfaces CORBA Common Object Request Broker Architecture que describen esas operaciones; y por CWM Common Warehouse Metamodel que define una especificación para el modelado de metadatos para la mayoría de los objetos encontrados en el entorno de un almacén de datos, tales como, objetos relacionales, no relacionales, entre otros. 7

17 Capítulo 1 2. La capa intermedia o capa de herramientas: Representa las tecnologías y plataformas de software implicadas en MDA, tales como las plataformas JAVA, CORBA,.NET y Webs así como la especificación XMI XML Metadata Interchange utilizada para intercambiar diagramas UML entre aplicaciones de modelado. 3. La capa externa o capa de objetivos: Equivale a las ramas o las utilidades hacia donde MDA se orienta, donde MDA puede ser utilizada para solucionar problemas. Podemos encontrar servicios penetrantes, seguridad, transacciones, eventos, directorio, etc. MDA está fundamentada en la arquitectura de cuatro capas propuesta por el OMG. (J. García Molina, 2006). Además según (Booch, 2004) en principios básicos como: la representación directa, para enfocarse más en el dominio del problema que en la tecnología. la automatización de las tareas mecánicas que no requieran de intervención humana. estándares abiertos que posibiliten la interoperabilidad de las herramientas y plataformas Desarrollo con MDA El desarrollo de sistemas de software es una labor que se ha ido complejizando cada vez más con el desarrollo de las nuevas tecnologías. La evolución de los lenguajes, entornos y técnicas de programación provoca que haya que desarrollar los mismos sistemas una y otra vez, que éstos utilicen e integren diferentes tecnologías o que exista una necesidad de comunicación entre sistemas dispares. A todo esto hay que añadirle los continuos cambios en los requerimientos, ya sean impuestos por los usuarios de los sistemas o derivados de los cambios tecnológicos (Schach., 2005). El enfoque de desarrollo de software tradicional debido a sus propias características no es capaz de brindar una solución adecuada a estos casos que se presentan actualmente. El proceso de desarrollo de software con MDA por el contrario se sustenta en la importancia de los modelos. Es así que, MDA propone la definición y uso de modelos a diferentes niveles de abstracción para guiar todo el proceso de desarrollo (análisis, diseño, codificación, mantenimiento y hasta integración), así mismo da la posibilidad de la generación automática de código a partir de los modelos definidos y de las reglas de 8

18 Capítulo 1 transformación entre dichos modelos (Cuesta M. Albeiros, 2009). Los modelos son los siguientes: 1. Modelo Independiente de la Computación Computationally Independent Model (CIM): es un 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. Comparable con los modelos del dominio y/o del negocio del proceso unificado de desarrollo. 2. Modelo Independiente de la Plataforma Platform Independent Model (PIM): es un modelo de alto nivel del sistema independiente de cualquier tecnología o plataforma que permite una abstracción de las características técnicas de las plataformas de despliegue, mostrando las partes que no cambian de las especificaciones del sistema. Si se parte de un CIM entonces el PIM es generado a partir del primero. A partir del PIM se puede generar varios PSM donde se definen el sistema desde puntos de vista diferentes dados por cada PSM. 3. Modelos Específicos de la Plataforma Platform Specific Model (PSM): Es un modelo de más bajo nivel de abstracción que el PIM que describe el sistema de acuerdo con una tecnología de implementación determinada (Cuesta M. Albeiros, 2009). Su generación es automatizada y toma como punto de partida el PIM al que se le realizan transformaciones para generar uno o varios PSMs correspondientes a tecnologías de implementación, proporcionando una independencia entre la capa de negocio y la tecnología empleada. 4. Código: Debido a que cada PSM esta muy ligado a una tecnología concreta, la transformación de cada PSM a código se puede realizar automáticamente. 9

19 Capítulo 1 Figura 1-3: Se ilustra como MDA propone transformar los modelos partiendo de un problema para llegar a una solución para el caso donde se parte del CIM. Cuando se parte de PIM se obvia el CIM y su transformación a PIM. (Juan Bernardo Quintero, 2007) Figura 1-4: Desarrollo de software con MDA(Anneke Kleppe, 2005) con adecuaciones del tutor. En la Figura 1-4, se muestra el ciclo de vida del desarrollo con MDA, que como se aprecia es similar al ciclo de vida del desarrollo tradicional, la diferencia fundamental radica en que la comunicación entre las fases del proceso se hace mediante modelos procesados de forma automática. Además otro aspecto de MDA es que la relación entre estos modelos se establece en dos sentidos, o sea, a partir del PIM se genera el/los PSM(s) y de estos se obtiene el código fuente relativo a cada uno, pero un cambio en el código fuente generado o en un PSM, repercute afectando al PSM o PIM respectivamente, lo que permite iterar en el ciclo de vida de manera indirecta, a partir de una fase superior. Siendo esto muy ventajoso para los programadores que si se les presenta un cambio en los requisitos cuando se está llevando a cabo la fase de codificación solo bastará hacer el cambio pertinente en el código y automáticamente el diseño de alto nivel del sistema se actualiza en base a los nuevos requisitos, sin necesidad de volver atrás y realizarlo manualmente. Los cambios en los procedimientos de negocio o la incorporación de nuevas funcionalidades pueden hacerse de una manera más simple sin tener que hacer cambios en todos los niveles del proyecto. Simplemente se desarrollan los cambios en el PIM, y estos se reflejarán en toda la aplicación, consiguiendo una disminución de trabajo en el equipo de desarrollo, una reducción en 10

20 Capítulo 1 los costos del proyecto y por ende se aumenta la productividad (Cuesta M. Albeiros, 2009). Según el tutor del trabajo un verdadero MDA debería incluir la generación automática del PIM a partir del CIM, de ahí la extensión deseada del proceso Transformación entre modelos Para las transformaciones entre modelos propuestos por MDA, en la actualidad existe un sinnúmero de estándares, marcos de trabajo, herramientas, etc. La siguiente lista tomada de (Juan Bernardo Quintero, 2007) expone algunos de los más conocidos: QVT: El Query/View/Transformations es un estándar para lenguajes de transformación en MDA propuesto por OMG y basado en MOF. JMI: Es un marco de trabajo nombrado como Java Metadata Interface, se basa en MOF y su función es permitir la carga, manipulación y serialización de ficheros XMI posibilitando el intercambio de modelos UML. UML Action Semantics: Incluye lenguajes de acción (AL) para especificar acciones sobre diagramas de estado y operaciones sobre diagramas de clases. GMT: El Generative Modeling Tools es un proyecto de la Fundación Eclipse acerca del desarrollo de software dirigido por Modelos, incluyendo a otros subproyectos como ATL, VIATRA2 y UMLX. VIATRA: Es un ambiente de validación y verificación que significa Visual Automated model TRAnsformation, está basado en transformación de modelos soportado por la herramienta VIATRA2. GReAT: Graphical Rewriting and Transformations, es un enfoque de transformación por grafos con un conjunto de herramientas diseñadas para la rápida especificación e implementación de transformación de modelo a modelo. XDE: El modelador XDE de IBM Rational Rose permite crear modelos UML independientes del lenguaje, además brinda la posibilidad de integración con otros entornos. BOTL: El The Bidirectional Object oriented Transformation Language constituye una notación gráfica precisa, formal y comprensiva, que funde los lenguajes formales con la fortaleza expresiva de las representaciones visuales Intercambio de diagramas Como casi todas las herramientas CASE, las herramientas MDA son capaces de exportar los diferentes diagramas contenidos en el PIM y PSM o importar diagramas 11

21 Capítulo 1 diseñados con otra herramienta CASE que encajen en uno de estos dos modelos haciendo uso de la especificación XMI. El XMI especifica un modelo abierto de intercambio de información que está dirigido para ofrecer a los desarrolladores que usan las herramientas CASE la capacidad de intercambiar información de programación de una forma estandarizada. XMI combina los beneficios del estándar XML para definir, validar y compartir formatos de documentos con los beneficios del lenguaje UML Principales ventajas que brinda MDA Según(OMG, 2003), MDA al separar, por un lado la especificación de las operaciones y datos de un sistema, y por el otro, los detalles de la plataforma en la que el sistema será construido brinda las bases para: Definir un sistema independiente de la plataforma sobre la que se construye. Definir plataformas sobre las que construir los sistemas. Elegir una plataforma particular para el sistema. Transformar la especificación inicial del sistema a la plataforma elegida. Los principales objetivos de MDA son mejorar la productividad, la portabilidad, la interoperabilidad y la reutilización de los sistemas. Productividad: En MDA el foco del desarrollo recae sobre el PIM. Los PSMs se generan automáticamente (al menos en gran parte) a partir del PIM. Por supuesto, alguien tiene que definir las transformaciones exactas, lo cual es una tarea especializada y difícil. Pero una vez implementada la transformación, puede usarse en muchos desarrollos. Y 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 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 automáticamente el paso del PIM al PSM de la plataforma deseada. 12

22 Capítulo 1 Interoperabilidad: Los PSMs generados a partir de un mismo PIM normalmente tendrán relaciones, que es lo que en MDA se llama puentes, Figura 1-5. 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. Figura 1-5 Interoperabilidad en MDA mediante puentes. (Anneke Kleppe, 2005) Mantenimiento y Documentación: Como ya se ha dicho, a partir del PIM se generan los PSMs, y a partir de los PSMs se genera el código. Básicamente, el PIM desempeña 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 PSMs 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. Fases de desarrollo: El proceso de desarrollo con MDA, mantiene las fases del proceso de desarrollo tradicional, solo sufre cambios en la etapa de análisis, diseño y codificación, pues estos cambios se van a centrar en el PIM que será la base de todo desarrollo y gracias a nuestra herramienta de transformación, al igual que varias de estas, estos cambios se trasladaran de inmediato al resto de las fases. 13

23 Capítulo UML Lenguaje Unificado de Modelado Unified Modeling Language o UML, por sus siglas en inglés, constituye el lenguaje de modelado para desarrollar sistemas de software más usado actualmente; está respaldado por el OMG. UML fue diseñado para incorporar las mejores prácticas actuales en las técnicas de modelado y de ingeniería de software (Neustadt, 2002). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema, ofreciendo un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos Diagramas que brinda UML La versión 2.0 de UML cuenta con trece diagramas divididos en tres grupos de acuerdo con sus funcionalidades: Los Diagramas de Estructura: Estos diagramas hacen énfasis en los elementos que deben existir en el sistema de modelado mostrando como están relacionados los mismos: Diagrama de clases: Es el diagrama más utilizado en el modelado de sistemas orientados a objetos. Se usa para modelar el vocabulario de un sistema, 14

24 Capítulo 1 modelar colaboraciones simples, y modelar un esquema lógico de base de datos. Se utiliza para mostrar clases, interfaces, colaboraciones y las relaciones entre todas ellas. Las relaciones entre clases pueden ser de dependencia, generalización o herencia, y de asociación, las relaciones de asociación deben tener una multiplicidad para señalar cuantos objetos pueden conectarse a través de una instancia a una asociación. Hay dos tipos de asociaciones especiales: agregación y composición. A estos también se le suman los siguientes diagramas que no serán abordados por no ser implementados en la versión 2.0 de la herramienta jmda. Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (Introducido a partir de UML 2.0) Diagrama de despliegue Diagrama de paquetes Los Diagramas de Comportamiento: Son un grupo de diagramas utilizados para mostrar como es el comportamiento llevado a cabo por el sistema que se modela, las partes del mismo y otros agentes externos. Diagrama de casos de uso: constituye uno de los diagramas UML utilizado para la modelación de los aspectos dinámicos de un sistema. Es muy importante en el modelado del comportamiento de un sistema, subsistema o una clase, mediante sus componentes que son: casos de uso, actores y sus relaciones. Esto implica, la mayoría de las veces, modelar el contexto del sistema, subsistema o clase, o el modelado de los requisitos de comportamiento de esos elementos. Diagrama de actividades: Muestra el flujo de control entre actividades, por lo que constituye fundamentalmente un diagrama de flujo, que además puede mostrar concurrencias y ramas de control. Es utilizado para modelar los aspectos dinámicos de un sistema, mas exactamente, los pasos secuenciales, incluida la concurrencia, de un proceso computacional. Los diagramas de actividades pueden utilizarse para visualizar, especificar, construir y documentar la dinámica de una sociedad de objetos, o también, para modelar el flujo de control de una operación. 15

25 Capítulo 1 Diagrama de estados: Un diagrama de estados muestra una máquina de estado, o sea, un comportamiento que especifica las secuencias de estados por las que pasa un objeto durante su vida, en respuesta a eventos, junto con sus respuestas a esos eventos. Estos diagramas son junto con los diagramas de actividades útiles para modelar la vida de un objeto, pero a diferencia de estos que muestran el flujo de control entre actividades ellos lo muestran entre estados. Pueden estar asociados a las clases, casos de uso o a sistemas completos para visualizar, especificar, construir y documentar la dinámica de un objeto individual Los Diagramas de Interacción: Los diagramas de interacción son un subgrupo dentro de los diagramas de comportamiento especializados en el flujo de control y en el flujo de datos entre los elementos del sistema modelado. Diagrama de secuencia: Utilizado para modelar interacciones entre un conjunto de objetos de una aplicación a través del tiempo. Se modela para cada método de una clase y contiene detalles de la implementación del escenario que no es más que una parte del sistema (relación entre los objetos más interesantes) que se quiere resaltar, así como, de los elementos que lo componen, o sea, objetos y clases, y de los mensajes que son intercambiados entre los objetos, ordenándolos temporalmente. Diagrama de comunicación (que es una versión simplificada del Diagrama de colaboración en UML 1.x) Diagrama de tiempos (Introducido a partir de UML 2.0) Diagrama global de interacciones o Diagrama de vista de interacción (Introducido a partir de UML 2.0) 1.5 Análisis de herramientas CASE con soporte MDA Propietarias OptimalJ OptimalJ es una herramienta MDA desarrollada por la empresa Compuware, que utiliza MOF para dar soporte a UML y XMI, permitiendo generar aplicaciones JEE completas a través de un Modelo Independiente de la Plataforma. En OptimalJ están presentes los siguientes modelos: 16

26 Capítulo 1 Modelo del Dominio: Modelo que describe el sistema sin detalles de la implementación o sea a un nivel alto de abstracción, es equivalente al PIM y su elemento principal es un modelo de clases del negocio. Modelo de la Aplicación: Constituye el PSM de la aplicación el cual es generado automáticamente a partir del modelo del dominio y se encuentra conformado por el modelo de base de datos, modelo de interfaz web y el modelo EJB. Modelo de Código: El código fuente de la aplicación, generado a partir del modelo de la aplicación Proceso de Desarrollo El proceso de desarrollo con OptimalJ está organizado de la siguiente manera. Se genera automáticamente los PSM de la capa de presentación (web), capa de negocio EJB y base de datos manteniendo la conexión entre las capas (Fig. 1-6). Se distingue los bloques libres y protegidos del código para evitar la modificación del código generado. Una nueva generación de la aplicación mantiene el código generado en los bloques libres. La interfaz web generada proporciona una navegación por defecto para cada objeto de negocio, que permite el mantenimiento de los datos asociados a las clases del Modelo del Dominio. Esa interfaz es muy pobre pero existe la posibilidad de crear un patrón de presentación que se ajuste a unas necesidades concretas, o bien manualmente modificar el código de la aplicación. Figura 1-6: Conexión entre los modelos de OptimalJ (J. García Molina, 2006) ArcStyler ArcStyler está desarrollada por la empresa io-software. Utiliza MOF para soportar estándares como UML y XMI y también JMI (Java Metadata Interface o Interfaz de 17

27 Capítulo 1 Metadatos Java) para acceder al repositorio de modelos. ArcStyler logra la integración de herramientas de modelación (UML) y herramientas de desarrollo (ingeniería inversa, explorador de modelos, construcción y despliegue) con la arquitectura CARAT que permite crear, editar y mantener cartuchos MDA (MDA-Cartridge) para definir transformaciones. También cubre todo el ciclo de vida de un proyecto al brindar herramientas para el modelado del negocio y el de requisitos Características de la arquitectura CARAT Los cartuchos creados utilizando la arquitectura CARAT contienen un conjunto de reglas de transformación y se instalan como un plug-in. Se utiliza el lenguaje de script Jphyton para programarlos, los existentes brindan soporte para las plataformas JEE,.NET, servicios web, etc. También un cartucho se puede definir a partir de otro cartucho permitiendo la llamada herencia de cartuchos Marcas en ArcStyler ArcStyler proporciona los dos modos de anotar un PIM con información específica de la plataforma establecidos por la especificación de MDA, los cuales son: Correspondencia de tipos (Model type mapping) y Correspondencia de instancias (Model instance mapping) Herramientas MDA Opens Source AndroMDA AndroMDA es un framework MDA open source, recibe como entrada un modelo UML en formato XMI, los combina con los plugins de AndroMDA (cartridge y translation libraries) y produce código fuente. Surge en el 2003 como continuación y ampliación del proyecto UML2EJB que tenía como objetivo la generación de código para programar con EJB2.0 (Enterprise JavaBean). Es aprobado en SourceForge también en el 2003 teniendo en su arquitectura algunos cambios significativos para que pueda crecer con el futuro. Las fortalezas de la versión 3.2 de AndroMDA son: Soporte para UML 2.0 y herramientas basadas en Eclipse EMF (MagicDraw 11.6, RSM, etc.). Integración con Maven2. Generación de código para PSM clases de metamodelo. Soporte para el Freemarker template engine. 18

28 Capítulo 1 Generación de código para Java Generics. Mejora en la documentación y nuevos tutoriales. Corrección de errores y pequeñas mejoras. Recibe una retroalimentación de la comunidad de usuarios y documentadores que forma parte del desarrollo del mismo. Incluye un conjunto de cartuchos enfocados a los kits de desarrollo actuales como son Apache Axis, jbpm, Apache Struts, JSF, Spring e Hibernate. Incluye un Kit que permite desarrollar cartuchos generadores de código o personalizar los existentes, el cartucho Meta, con él se puede construir un generador de código empleando una herramienta de UML. La principal desventaja de AndroMDA es que no brinda soporte para la edición directa de UML y pese a ser una herramienta de código libre depende de otras herramientas propietarias (como MagicDraw) para esta función, aunque también es compatible con ArgoUML que si es libre, pero esta herramienta se encuentra en una etapa joven de su ciclo de vida GMF GMF Graphical Modeling Framework es un acrónimo que nombra a un marco de trabajo de Eclipse que constituye una alternativa para la generación de editores gráficos que utilizan MDA, está basado en EMF Eclipse Modeling Framework y GEF Graphical Editing Framework. Con él se pueden crear editores que utilicen el lenguaje UML u otro lenguaje de modelado ya que parte de un metamodelo donde se especifica el lenguaje de modelado que utilizará. Como resultado final se genera un plug-in que añadido a un proyecto de Eclipse permite editar gráficamente el modelo especificado con anterioridad. Está dividido en dos grandes componentes según (Sáez, 2009): GMF Tooling: que es el componente de instrumentación con el que se definen los aspectos de notación y semánticos y también las funcionalidades del editor gráfico, así como la parametrización del generador que se va a encargar de construir el código del mismo y generar el plug-in correspondiente. GMF Runtime: es el encargado de ejecutar el plug-in generado por el GMF Tooling 19

29 Capítulo 1 En la Figura 1-7 se detalla cómo es la arquitectura para el desarrollo basado en GMF. Está compuesta por varios modelos, partiendo de el modelo del dominio, la definición gráfica de los elementos que van a componer el editor y la definición de las herramientas que se asociaran a cada objeto. Con el modelo de mapeo se unifican los tres modelos anteriores para luego ser usado como entrada para la transformación modelo a modelo dando como resultado al modelo generador mediante el cual se genera el código que permite la ejecución del editor. Figura 1-7: Arquitectura del desarrollo basado en GMF (Moreno, 2009) El modelo del dominio se define en base a EMF y establece la información no gráfica gestionada por el editor, o sea es el metamodelo en el cual se va a basar todo el desarrollo. Existen tres formas de conseguirlo: importando un metamodelo Ecore de EMF, mediante el uso del editor estándar de EMF o haciendo uso del propio editor Ecore que esta incorporado en GMF. El modelo de definición gráfica como se dijo anteriormente, se utiliza para definir los elementos gráficos que se van a visualizar con el editor, por ejemplo: figuras, nodos, conexiones, etiquetas, etc. El modelo de definición de herramientas permite definir elementos tales como el cuadro de herramientas, menú principal, la paleta y el resto de acciones que se van a asociar a cada elemento. El modelo de mapeo establece la correlación existente entre los elementos del dominio representado por el diagrama.ecore y los elementos gráficos representados por los diagramas.gmfgraph y.gmftool. El modelo de generación permite definir los detalles de implementación para la fase de generación del código. El resultado final es el antes mencionado plug-in personalizable 20

30 Capítulo 1 y mejorable, mediante el cual los desarrolladores pueden modelar software basándose en un metamodelo concreto. Como se referenció anteriormente el GMF Runtime permite trabajar al desarrollador con el editor gráfico generado. En la siguiente figura se detalla las dependencias entre el editor gráfico generado, el runtime de GMF y los componentes GEF y EMF, todos ellos soportados por la plataforma Eclipse. Figura 1-8: Dependencias de la plataforma GMF (Plante, 2006) En la Figura 1-8 se puede observar que el editor gráfico tiene una dependencia de uso de GMF Runtime ya que este es el encargado de ejecutar el plug-in, además también depende de los modelos de dominio y los componentes gráficos definidos en EMF y GEF respectivamente y todos a su vez dependen de la plataforma Eclipse Ventajas de GMF Permite crear editores gráficos desde cero. Permite al desarrollador centrarse en la lógica de negocio del sistema. Su naturaleza extensible permite crear editores abiertos y la facilidad de ser extendidos por terceros. Define un meta-modelo de notación ampliable para permitir la total separación entre la semántica y la notación. La reutilización de las definiciones gráficas para varios dominios diferentes, gracias a la utilización de varios mapeos separados para enlazar definiciones gráficas y de herramientas y los dominios concretos 21

31 Capítulo 1 Al utilizar GMF para la construcción de editores se aprovecha las características del runtime de este, que son: Expandir o contraer compartimentos de objetos (el compartimento de atributos de una clase por ejemplo). Edición directa de las etiquetas de los objetos sobre el elemento gráfico, sin necesidad de abrir la ventana de propiedades. Asistencia en el modelado mediante menús contextuales. Aparte de definir elementos propios en la paleta de herramientas y de los menús, disponer de elementos comunes de base a todos los editores generados. Proporciona un conjunto de propiedades comunes para figuras y conectores. Proporciona un componente de pre-visualización e impresión. Soporta la utilización del portapapeles del sistema, para operaciones de copiado Desventajas de GMF Dependiente de la arquitectura Eclipse Resumen de las herramientas AndroMDA y GMF. El resumen de las dos herramientas tratadas anteriormente comparándolas a ambas con determinados criterios y destacando sus mayores debilidades como herramientas MDA. Se presenta en la siguiente tabla: Tabla 1-1 Resumen de las herramientas estudiadas y analizadas AndroMDA y GMF AndroMDA GMF Código abierto Si Si Soporte UML 2.0, Freemarker UML 2.0 Template Engine Herramientas necesarias MagicDraw 9.5 y Apache`s Maven Eclipse,EMF Eclipse Modeling Framework y GEF Graphical Editing Framework Integración Marven2 otras Niveles que cubre Implementa los niveles PIM y PSM Ingeniería inversa No No Grado de interacción con Alta Alta el usuario Permite definir CIMs, PIMs y PSMs 22

32 Capítulo 1 Ámbito de Aplicación Debilidades El desarrollo orientado a servicios y SI Web. Depende de otras herramientas propietarias para brindar soporte la edición directa de UML. Al desarrollo de sistemas de propósito general. Dependiente de la arquitectura Eclipse Análisis de la herramienta CASE jmda v1.0 y jmda v2.0: A continuación se expondrá un análisis crítico de la herramienta CASE jmda versión 1.0 y jmda versión 2.0, teniendo en cuenta si cumple con los requisitos funcionales y los no funcionales esperados en una herramienta de su tipo. Es preciso comenzar diciendo que dicha herramienta CASE se puede clasificar por su funcionalidad como un híbrido de editor de UML y soporte de MDA, la conjunción de estos dos aspectos, es muy factible ya que UML es el lenguaje de modelado por excelencia y es absolutamente compatible con MDA. En la mayoría de las herramientas con soporte MDA por lo general se importa como entrada al PIM una representación de diagramas UML en formato XMI. Para la evaluación de los aspectos no funcionales se tendrán en cuenta la escalabilidad, funcionalidad, portabilidad y disponibilidad Valoración como Editor UML e implementación MDA Para realizar la valoración de la herramienta CASE jmda versión 1.0 y jmda versión 2.0 se siguieron una serie de criterios, los primeros realizados a partir del estudio de herramientas profesionales que constituyen editores de UML, como son Visual Paradigm, Rational Rose Enterprise, ArgoUML, etc. Donde se tomaron en cuenta aspectos que comparten en cuanto a su función principal que es la de brindar soporte a dicho lenguaje de modelado. Los demás criterios para la valoración de la herramienta como implementación MDA fueron tomados de (Sáez, 2009) donde fueron utilizados para medir el nivel de profundidad, como implementación MDA, en las herramientas propietarias IBM Rational Software Architect, Borland Together y Sparx Systems Enterprise Architect. 23

33 Capítulo 1 Tabla 1-2: Criterios de evaluación de la herramienta jmda v1.0 como implementación MDA. En el grado de cumplimiento 0 equivale a nada, 1 a muy poco, 2 a casi todo, 3 a todo. Id Propiedad Descripción Grado de cumplimiento (de 0 a 3) A1 Completitud de los 1 diagramas UML brindados A2 Facilidades de representación y modificación B1 Interoperabilidad e integración B2 Acceso a la definición de las transformaciones La herramienta puede importar y exportar información a otras herramientas mediante estándares XMI. Se analiza la utilización de estándares básicos de MDA La herramienta provee de un mecanismo de definición de transformaciones entre modelos y permite al usuario crear nuevas transformaciones o modificar las existentes para satisfacer sus requisitos específicos. Se tiene en cuenta tanto en las transformaciones de modelos como la generación de código B3 Uso de patrones La herramienta aplica o permite aplicar patrones de diseño en la construcción de modelos PIM, PSM o código y pueden definirse otros nuevos o modificar los existentes B4 Control y refinamiento de las transformaciones La aplicación permite la dirección o el control de las transformaciones entre modelos o entre el PSM y el código. Por ejemplo dispone de parámetros en las transformaciones, permite seleccionar los elementos a ser transformados o establecer condiciones para las transformaciones. B5 Trazabilidad Incorpora un mecanismo para seguir el rastro de determinadas transformaciones desde su origen hasta su destino B6 Soporte para regeneración de modelos Presenta soporte para rehacer modelos, por ejemplo, regenerar el PIM a partir de los modelos PSM y viceversa, debe permitir también la conservación de los cambios efectuados manualmente tanto a nivel de modelo como de código

34 Capítulo 1 B7 Verificador de modelos Incluye algún mecanismo para chequear la corrección de modelos incluidos PIM y PSM. 0 Como se puede observar en la Tabla 1-2, la herramienta jmda versión 1.0 esta muy lejos de cumplir con todos los requisitos planteados para una herramienta de su tipo. Ahora bien, la versión 2.0 tiene un poco más de funcionalidades con respecto a la versión 2.0 ya que realiza la transformación del PIM del diagrama de clases al PSM. A continuación veremos en la Tabla 1-3 un resumen donde comparamos las dos primeras versiones en cuanto a los diagramas soportados y funcionalidades. Tabla 1-3 Resumen comparativo entre las dos primeras versiones de jmda. jmda v1.0 jmda v2.0 Diagramas: PIM PSM PIM PSM Actores, casos de Diagrama uso, relación de de Casos asociación y de Usos eliminación. No soportado Nada nuevo No soportado Diagrama de Clase Diagrama de Actividad Diagrama de Estado Diagrama de Secuencia Clases solo con sus atributos, relaciones (asociación, composición, generalización y agregación) y eliminación. Nodo inicio, nodo fin, actividad, bifurcación, relación de asociación y eliminación. No existía No existía No soportado No soportado Multiplicidad e incorporación en la clase de los métodos Camino, horizontal y vertical. Nodo inicial, nodo final, estado, bifurcación y eliminación. Clasificador, mensaje sincrónico y mensaje retorno. Transformación en java No soportado No soportado No soportado Ambas versiones compartían una misma estructura de diseño que consistía en tres paquetes relacionados entre sí; Paquete View, Paquete Shape y Paquete Relation. 25

35 Capítulo Conclusiones Parciales del capítulo Es innegable la importancia de que los equipos o grupos de desarrollo de software cada vez más hagan uso de métodos que permitan incrementar la productividad en el desarrollo de software. Esto es imprescindible además en nuestro país. Uno de estos métodos lo es sin duda la Arquitectura Dirigida por Modelos (MDA). A pesar de los más de diez años de surgimiento de la aproximación MDA y de los avances que se han logrado en la realización de herramientas que la implementen, todavía se puede decir que no existe una herramienta CASE que cumpla en su totalidad todo el proceso de desarrollo planteado por esta aproximación. Se han mostrado algunos ejemplos de herramientas que poseen gran calidad como es el caso de AndroMDA, ArcStyler e IBM Rational Software Architect, entre otras, resaltando sobre todo a las herramientas privativas como las más acertadas, desgraciadamente el costo del pago de una licencia de uso es un lujo que nuestro país no se puede permitir, por lo que constantemente se buscan alternativas en el ámbito del software libre. El proyecto previo de desarrollo no logró avanzar mucho en la creación de una herramienta MDA, pero al menos sirvió de base para demostrar que era factible su creación en nuestro medio. Con esta tesis se pretende dar un paso en la obtención de una alternativa. 26

36 Capítulo 2: Análisis y Diseño de la Herramienta. En este capítulo se aborda los detalles de la implementación de la versión 3.0 de la herramienta CASE jmda. 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 Diagramas del Análisis y el Diseño del módulo PIM-PSM de la herramienta CASE jmda v Diagrama de Casos de Uso del sistema El diagrama de casos de uso del sistema es el siguiente: Figura 2-1: Diagrama de Casos de Uso del sistema para la construcción de la herramienta jmda v

37 Capítulo Descripción de los casos de uso mediante diagramas de actividades Caso de uso: Modelar PIM Figura 2-2: Diagrama de Actividades para la modelación del PIM 28

38 Capítulo 2 Caso de uso: Generar PSM Figura 2-3: Diagrama de Actividades para la generación del PSM Caso de uso: Salvar XMI correspondiente a diagramas de clase del PSM Figura 2-4: Diagrama de Actividades para la salvar XMI. 29

39 Capítulo Requisitos funcionales Dado los casos de uso establecidos en el diagrama de casos de uso podemos establecer los siguientes requisitos funcionales: 1. Permitir realizar el Modelo Independiente de la Plataforma de un sistema en base a diagramas de clases, así como diagramas de casos de uso, actividades, estados y secuencia. 2. Permitir la generación de un Modelo Específico de la Plataforma a partir del modelo independiente anterior, que contenga los diagramas de clases, estados, actividades y secuencia correspondiente con los detalles propios de la plataforma Java; así como modelar los diagramas de artefacto y despliegue en el PSM. 3. Permitir salvar los diagramas de clases del Modelo Especifico de la Plataforma como un modelo XMI para ser importado desde un software que permita su conversión a código fuente en Java Requisitos no funcionales Requerimiento del Hardware: La aplicación necesita para su ejecución una terminal con al menos 100MB de memoria RAM disponibles para su uso eficiente. Con microprocesador de la familia Pentium IV o superior. No necesita tarjeta de video extra. Requerimiento del Software: Al ser una aplicación Java desarrollada utilizando la tecnología openjdk puede ser ejecutada sobre cualquier sistema operativo (Windows, GNU/Linux, Solaris, entre otros) que tenga instalada una versión del JRE compatible con IcedTea6 versión Estabilidad: Se espera que el nivel de fallos de la aplicación no exceda del umbral que imposibilite su correcto desempeño. Portabilidad: Presenta alta portabilidad al ser programado en Java, no es necesario reescribir el código para portarse a otra plataforma, se puede reutilizar en su totalidad. Costo: Por ser un trabajo desarrollado como parte de un ejercicio académico (Tesis de Diploma), no tiene un costo directo establecido. 30

40 Capítulo Diagrama de paquete del software. En este diagrama veremos la nueva estructura que se le incorporo a la herramienta jmda en su versión 3.0; la cual está comprendida en tres niveles esenciales en su diseño. Un primer nivel donde se encuentra las clases del sistema y las clases principales para la representación de los diagramas que se encuentran en el siguiente nivel. En el segundo nivel están todos los diagramas soportados para esta herramienta donde cada paquete en este nivel representa un diagrama en específico viéndose como módulos independientes para un mejor confort y más fácil para futuras modificaciones y un tercer nivel donde tenemos dos paquetes esenciales uno para guardar los diagramas y otro para generar código XMI para cada diagrama. Figura 2-5: Diagrama de Paquete Diagrama de clases del software. Para su comprensión el diagrama de clases se mostrará dividido por paquetes. Donde en cada paquete se mostraran las entidades que lo forman, con sus especificaciones de atributos y métodos, así como las relaciones de herencia o implementación que puedan tener con otras clases e interfaces externas que pertenezcan al JDK de java. En estos 31

41 Capítulo 2 primeros diagramas no se mostraran las relaciones que presentan entre sí las entidades de los paquetes que conforman la herramienta jmda versión Diagrama de clases del paquete AplicaciónPrincipal y del paquete ClasesTree. Estos paquetes AplicaciónPrincipal y ClasesTree contienen las entidades relacionadas con la GUI del sistema. Figura 2-5: Diagrama de Clases para el paquete AplicaciónPrincipal y paquete ClasesTree. Solo se muestran relaciones de herencia e implementación con entidades externas al paquete. 32

42 Capítulo Diagrama de clases del paquete Shape. El paquete Shape contiene la clase principal, para representan a los elementos de los siete diagramas UML exceptuando las relaciones. Figura 2-6: Diagrama de Clases para el paquete Shape y su relación con los distintos tipos de diagramas. Solo se muestran relaciones de herencia e implementación con entidades externas al paquete. 33

43 Capítulo Diagrama de clases del paquete Relations El paquete Relations contiene las clases principales que representan las relaciones que pueden ser establecidas entre las clases principales del paquete Shapes y cada uno de los paquetes de diagramas correspondientes. Figura 2-7: Diagrama de Clases para el paquete Shape. Solo se muestran relaciones de herencia e implementación con entidades externas al paquete. 34

44 Capítulo Diagrama de Actividades de la operación jtree1mouseclicked (e: MouseEvent) Se mostrara con un diagrama de actividades el flujo de control que se lleva a cabo en el método jtree1mouseclicked (e: MouseEvent) de la clase Main.java del paquete AplicaciónPrincipal. Figura 2-8: Diagrama de Actividades para el paquete AplicaciónPrincipal. Solo se muestran relaciones de herencia e implementación con entidades externas al paquete. 35

45 Capítulo Diagrama de Estado del menú El diagrama de estado del menú muestra los estados del menú, donde cada estado corresponde con un componente del menú y las transiciones con el paso de una opción a otra. Figura 2-10: Diagrama de Estados del menú. 36

46 Capítulo Diagrama de Secuencia de una acción interesante El siguiente diagrama de secuencia muestra cómo se comportan los principales objetos que participan en la micro operación Crear Diagrama de Clase Figura 2-11: Diagrama de secuencia cuando se selecciona la opción Crear Diagrama de Clases. 37

47 Capítulo 3. Descripción de la Implementación y Uso de la herramienta. 3.1 Breve descripción del proceso de codificación La tercera versión de la herramienta CASE jmda desarrollada en la presente tesis comparte con las primeras versiones el hecho de haber sido programada usando el lenguaje Java, seleccionado por las facilidades que brinda al estar respaldado por licencias que permiten su libre distribución, modificación y uso. Esta nueva versión se basó en el código de las primeras versión, extendiéndolo y modificándolo en algunos aspectos pero manteniendo el mismo patrón de diseño utilizado en la primera versión. Esto representa el uso del concepto de mantenibilidad y reutilización de la Ingeniería del Software. Para la codificación se utilizó librerías contenidas en el JDK versión 7 tales como: swing y awt: Para manipular todos los componentes visuales de la aplicación. útil: Para trabajar con estructuras de datos necesarias para almacenar y procesar la información y meta información de los diagramas desarrollados. io: Para trabajar con fichero texto. Se usó el entorno integrado de desarrollo NetBeans por las facilidades que brinda para refactorización y chequeo semántico del código. 3.2 Descripción del uso de la herramienta Ejecución y pantalla de presentación La herramienta esta compilada y empaquetada en un.jar. Para su ejecución es necesario tener instalada en el sistema operativo una Máquina virtual Java que no es más que una máquina virtual de proceso nativo, es decir, ejecutable en una plataforma específica, capaz de interpretar y ejecutar instrucciones expresadas en un código binario especial (el bycode Java). Una vez instalada la máquina virtual para hacer uso de la aplicación bastara con mandar a ejecutar con la acción del mouse sobre el fichero.jar. 38

48 Capítulo 3 Figura 3-1: Ventana de inicio de la aplicación. La aplicación cuenta con: Un menú de cuatro botones: Archivo: Contiene el menú Nuevo Proyecto y Cerrar. Diagrama: Contiene el menú Crear Diagrama que a la vez se despliega en los submenúes Diagrama de Secuencia, Diagrama de Estados, Diagrama de Actividades, Diagrama de Clases, Diagrama de Casos de Uso, Diagrama de Artefacto y Diagrama de Despliegue. Además contiene otro menú Guardar Diagrama. Generar: Contiene dos menúes Código Java y XMI. Ayuda: La ayuda contiene el menú Acerca de jmda que al ser seleccionado imprime en pantalla una ventana de información sobre la presente versión de la herramienta. Un árbol de modelo en la esquina izquierda: El árbol muestra en su primer nodo los diagramas construidos en el PIM, dividiéndolos en los cinco tipos de diagramas soportados y en su segundo 39

49 Capítulo 3 nodo los diagramas de clases del PSM generados a partir de los diagramas de clases del PIM, así como los diagramas de Artefacto y Despliegue. Un panel con etiquetas donde se muestran las áreas de construcción de los diagramas Creación de diagramas con jmda versión 3.0 Para la creación de diagramas basta con seleccionar la opción del menú Archivo/Nuevo Proyecto. Luego seleccionar todos aquellos diagramas que se desean crear. Además de que se pueden ir agregando diagramas en la medida que se deseen crear tanto por el menú principal Diagrama/Crear Diagrama de o por el menú secundario seleccionando el diagrama que se desea agregar. También por el árbol de diagramas se puede agregar más diagramas seleccionando el diagrama agregar y pulsando click secundario en Nuevo Diagrama. Figura 3-2: Menú para la selección de los diagramas a crear. A continuación se mostrarán ejemplos de cada uno de los cinco tipos de diagramas que se pueden crear. 40

50 Capítulo Diagrama de secuencia El diagrama de secuencia se añadió en esta versión, se implementó con las facilidades de representación de objetos y sus líneas de vida, así como la representación de las llamadas entre los objetos, los retornos de estos mensajes y la llamada de destrucción entre objetos. Faltaron otras funcionalidades visuales que quedarán para una próxima versión. Figura 3-3. Diagrama de secuencia. 41

51 Capítulo Diagrama de estados El diagrama de estados se añadió en esta versión, se implementó con las facilidades básicas de definición de los estados, con sus acciones, así como las relaciones entre estados (transiciones) con sus acciones. Faltaron por implementar facilidades como: iteración entre estados y la concurrencia. Figura 3-4 Diagrama de Estados del PIM Diagrama de clases El siguiente diagrama de clases del PIM muestra mediante un ejemplo las cuatro relaciones entre clases contempladas en esta versión de la herramienta que son asociación, composición, agregación y generalización, así como la descripción de estas y la multiplicidad. Es bueno destacar que en nuestra herramienta se perfeccionó este tipo de diagramas incluyendo facilidades como establecer distintos tipos de relaciones ausentes en la versión previa (generalizaciones, agregaciones, composiciones, etc.). Además se incluyó la facilidad de insertar la multiplicidad, dirección de la asociación y otras. 42

52 Capítulo 3 Figura 3-5. Diagrama de clases del PIM Como concordancia al diagrama de clases del PIM se genera uno el PSM con características específicas de java, como es la adición del método setter y getter a cada clase de acuerdo con la cantidad de atributos que tenga cada una. Figura 3-6. Diagrama de clases del PSM generado a partir del correspondiente en el PIM. 43

53 Capítulo Diagrama de actividades Los diagramas de actividades cuentan en esta versión con los siguientes elementos: nodo de inicio, actividades, bifurcaciones, barra vertical y horizontal, carreteras, flujos de control y nodos de finalización. En esta versión se mejoró la representación visual del flujo de control. Aquí se incluyeron facilidades como: Figura 3-7. Diagrama de actividades Diagrama de Casos de Uso El diagrama de casos de uso de la versión anterior le faltaba funcionalidades de extend e include; así como el límite del sistema y la generalización. En esta versión se le añadió todo esto. 44

54 Capítulo 3 Figura 3-8. Diagrama de Casos de Uso Diagrama de Artefacto El diagrama de Artefacto en las versiones anterior no se había implementado y en esta versión se logró incorporarlo. El diagrama cuenta con todas sus relaciones brindando un fácil manejo de su estructura. Se le recomienda incorporarle más funcionalidades. Figura 3-9. Diagrama de Artefacto. 45

55 Capítulo Diagrama de Despliegue El diagrama de Despliegue en las versiones anterior tampoco se había implementado y en esta versión se logró incorporarlo también. El diagrama cuenta con todas sus relaciones brindando un fácil manejo de su estructura al igual que el de Artefacto. Se le recomienda incorporarle más funcionalidades, como son los estereotipos. Figura Diagrama de Despliegue. 46

56 Capítulo Exportación de archivo XMI del Diagrama de clases del PSM Como novedad en esta versión se incluye la posibilidad de exportar un tipo de diagrama haciendo uso de las facilidades que brinda XMI para contener metadatos que pueden ser intercambiado entre aplicaciones. En esta versión solamente es exportable a XMI los diagramas de clases del PSM. Para exportarlo solo se debe dar click secundario en el nodo equivalente al diagrama de clases del PSM y seleccionar lo opción Exportar XMI como se muestra en la figura 3-. Figura 3-9.Exportar un XMI de un diagrama de clases del PSM Estructura del XMI Este XMI es una versión modificada de la versión estándar, o sea no cumple con el esquema XML propio de XMI sino que está diseñado exclusivamente para ser importado e interpretado por el módulo PSM-Código creado en el curso anterior y que no tuvo continuación en este, lo cual es recomendable para que el módulo PIM-PSM pueda implementar un XMI estándar importable por herramientas CASE comerciales. No contempla tampoco soporte para las relaciones establecidas entre las clases del diagrama ni información espacial de cómo están distribuidos los elementos del diagrama, solo recoge información de cada una de las entidades tales como su nombre, atributos, métodos y visibilidad. 47