Desarrollo de un Modelo Computacional basado en Arquitectura Orientada a Modelos para la Transformación de un Diagrama de Clases en Código Fuente Java

Transcripción

1 Escuela Académico Profesional de Informática Facultad de Ciencias Físicas y Matemáticas Universidad Nacional de Trujillo Desarrollo de un Modelo Computacional basado en Arquitectura Orientada a Modelos para la Transformación de un Diagrama de Clases en Código Fuente Java TRABAJO DE GRADUACION INFORME N 3 Díaz Fernández Pedro Pablo Pastor Cruzado Javier Eduardo

2 Índice Lista de Tablas o Cuadros... 5 Lista de Figuras... 6 INTRODUCCION... 7 PLANTEAMIENTO DEL ESTUDIO Realidad Problemática Formulación del Problema Hipótesis Objetivos Objetivo General Objetivos Específicos Justificación del Problema Limitaciones del Estudio MARCO TEÓRICO Modelo Modelo Computacional Arquitectura Orientada a Modelos MDA CIM PIM PSM Transformación en MDA a Código Fuente: Metámodelos: OMG: Capa M0: Instancias Capa M1: Modelo del Sistema Capa M2: Metamodelo Capa M3: Meta-metamodelo Lenguaje Modelado de Proceso UML: Diagrama de Clases Diagrama de Casos de Uso Diagrama de Estados

3 Diagrama de Secuencias Diagrama de Actividades Diagrama de Clases: Clase Relaciones Herramientas de Transformación Herramienta OptimalJ de Compuware Herramienta ArcStyler... Error! Marcador no definido Otras Herramientas: Java MATERIALES Y MÉTODOS Diseño de la Investigación Población y muestra Población Muestra Variables de estudio Variable Dependiente Variable Independiente Factor de Medición de Mejora del Tiempo Técnicas e Instrumentos Técnicas Instrumentos RESULTADOS Análisis de las Modelos de Transformaciones: Análisis Comparativo de los Modelos Referidos: Diseño Modelo Computacional para la Transformación de diagramas: Arquitectura del modelo de Transformación: Definición del Modelo de Transformación: Descripción del Modelo de Transformación: Formalización del Modelo Computacional: Reglas de transformación: Desarrollo de Casos de Estudio:

4 DISCUSIÓN DE RESULTADOS CONCLUSIONES Y RECOMENDACIONES: BIBLIOGRAFÍA

5 Lista de Tablas o Cuadros Tabla 1. Tabla de las Capas de Modelado 25 Tabla.2 Arquitectura de OptimalJ 43 Tabla.3 Tabla comparativa de modelos MDA. 60 Tabla 4.Operaciones del Metamodelo. 78 5

6 Lista de Figuras Ilustración 1 Fig. N 1. Pasos en el desarrollo con MDA Ilustración 2 Fig. N 2. Tecnologías PIM Ilustración 3 Fig. N 3. Ejemplo de PIM Ilustración 4 Fig. N 4. Ejemplo de PSM Ilustración 5 Fig. N 5. Tipos de Modelos según abstracción Ilustración 6 Fig. N 6. Transformación MDA Ilustración 7 Fig. N 7. Funcionalidad en un entorno de desarrollo MDA Ilustración 8 Fig. N 8. Entidades de MOF Capa M Ilustración 9 Fig. N 9. Entidades de MOF Capa M Ilustración 10 Fig. N 10. Entidades de MOF Capa M Ilustración 11 Fig. N 11. Entidades de MOF Capa M Ilustración 12 Fig. 12. Relación entre las Capas de Modelado Ilustración 13 Fig. N 13. Transformaciones de un Modelo UML Ilustración 14 FIG. 14. Modelo de una Clase Ilustración 15 FIG. 15. Modelo de un Caso de Uso Ilustración 16 Fig. 16. Modelo de un Diagrama de estado Ilustración 17 Fig. 17. Modelo de un Diagrama de Secuencia Ilustración 18 Fig. 18. Modelo de un Diagrama de Actividades Ilustración 19 Fig. N 19. Diagrama de Clases Ilustración 20 Fig. 20: Representación Estructural de una Clase Ilustración 21 Fig. 21. Modelo de un Clase en UML Ilustración 22 Fig. 22. Modelo de Herencia de Clases Ilustración 23 Fig. 23. Representación de Agregación de Clases en UML Ilustración 24 Fig. 24. Representación de Asociaciones de Clases en UML Ilustración 25 Fig. 25. Representación de Dependencia de Clases en UML Ilustración 26 Fig.26 ArcStyler Ilustración 27 Fig.27 Arquitectura de ArcStyler Ilustración 28 Fig.28 Plataformas de JAVA Ilustración 29 Fig.29 Elementos de la plataforma Java Ilustración 30 Fig. 30 Arquitectura del Modelado Ilustración 31 Fig. 31 Metamodelo del diagrama de Clases Ilustración 32 Fig. 32 Instancia de una Clase Ilustración 33 Fig. 33 Sintaxis de una clase Ilustración 34 Fig. 34 Relación entre un modelo de usuario y una instancia del metamodelo Ilustración 35 Fig. 35 Diagrama de clases de ventas del caso Ilustración 36 Fig. 36 Instancia de Metamodelo del caso

7 INTRODUCCION En un proceso de desarrollo de software, una de las tareas más relevantes para el éxito de un proyecto de diseño e implementación de un Modelo Computacional es garantizar, de una forma apropiada, la representación y el modelado de los requisitos de usuario. A pesar de la relación estrecha que existe entre el Modelado Estándar de la Plataforma (PSM) y la plataforma, existen diversas causas de inconsistencias que dificultan la generación de código a partir del PSM. Algunas tienen que ver con modelos mal planteados, desarrolladores incapaces de interpretar los modelos, o que no se acogen a estos para generar el código. Actualmente, la interpretación es un problema a la hora de elaborar software por parte de los programadores, esto se produce por la carencia de experiencia y el mal modelamiento de modelos de análisis produciendo confusión y retraso al proceso de elaboración e implementación del software. En este trabajo de investigación se desarrollara un proceso único de fácil comprensión y didáctico de cómo interpretar un modelo de clases a su implementación en código fuente, sin duda lo que se pretende con todo esto es agilizar este proceso, para eso este Proyecto de Investigación utiliza conceptos de MDA, mediante la aplicación de reglas de transformación que establecen una relación unívoca entre los elementos del diagrama y patrones de código, que se ejemplifica en JAVA. 7

8 PLANTEAMIENTO DEL ESTUDIO 1.1. Realidad Problemática A pesar de la relación estrecha que existe entre el PSM y la plataforma, existen diversas causas de inconsistencias que dificultan la generación de código a partir del PSM. Algunas tienen que ver con modelos mal planteados, desarrolladores incapaces de interpretar los modelos, o que no se acogen a estos para generar el código. [2] Se han realizado diversos trabajos tendientes a dictaminar cómo se están viendo afectadas las comunidades de software con la adopción de MDD. En dichas investigaciones se pone en evidencia que, a pesar de las alentadoras fortalezas, existen falencias que deben subsanarse. La compañía de investigación de mercado Forrester Research Inc. (2008) ha realizado estudios en los cuales resalta algunas fortalezas del MDD y afirma que ayuda a las organizaciones de desarrollo a obtener el control de la documentación y otros artefactos existentes, mejora la productividad e, incluso, después de un período de lanzamiento inicial, se hace más fácil para los equipos de desarrollo actualizar y mantener aplicaciones. Todo esto se logra una vez ha sido introducida suficiente información acerca de los tipos de desarrollo y las plataformas en las herramientas MDD, de tal forma que se le permita al usuario desarrollador describir el tipo de detalles que deben aplicarse.[6] En la actualidad, la interpretación es un problema a la hora de elaborar software por parte de los programadores, esto se produce por la carencia de experiencia y el mal modelamiento de modelos de análisis produciendo confusión y retraso al proceso de elaboración e implementación del software, en este trabajo se desarrollara un proceso único de fácil comprensión y didáctico de cómo interpretar un modelo de clases a su implementación en código fuente, sin duda lo que se pretende con todo esto es agilizar este proceso, para eso este Proyecto de Investigación utiliza conceptos de MDA, mediante la aplicación de reglas de transformación que establecen una relación unívoca entre los elementos del diagrama y patrones de código, que se ejemplifica en JAVA. 8

9 Características: Falta de flexibilidad y configuración en el código generado. No uso de plantillas y ficheros de definición de estructuras. Falta de pruebas de código generado (compilación). No hay integración con diferentes lenguajes de programación. Demora en el proceso de transformación del diseño al código Formulación del Problema Considerando lo expresado en la sección anterior, se deduce que es de utilidad diseñar un Modelo Computacional basado en Arquitectura Orientada a Modelos para la Transformación de un Diagrama de Clases en Código Fuente Java. Esto nos lleva al planteamiento del problema: Cómo mejorar la transformación de un diagrama de clases a código fuente Java? 1.3. Hipótesis Un modelo computacional basado en arquitectura orientada a modelos permitirá mejorar la transformación de un diagrama de clases a código fuente java Objetivos Objetivo General Desarrollar un Modelo Computacional basado en Arquitectura Orientada a Modelos para la Transformación de un Diagrama de Clases en Código Fuente Java. 9

10 Objetivos Específicos Realizar una investigación bibliográfica para recolectar datos referentes al tema de investigación. Analizar la información recopilada para determinar el modelo computacional. Reducir el Tiempo y Espacio mediante el modelo de Transformación Justificación del Problema Desde el punto de vista de la Ciencias de la Computación: El Trabajo de Investigación se enfoca en el Área de la Ingeniería de Software y al tema Arquitectura Orientada a Modelos, el cual aporta un modelo computacional que permite: La transformación (Algoritmo) desde un diagrama de clases a código fuente Java. Reducción de tiempo (Análisis algorítmico). Una propuesta de CASE (lower) para pasar del diseño a implementación Limitaciones del Estudio El Modelo está enfocado para los programadores que desean realizar transformaciones de clases a código fuente java, asimismo las personas que se interesen o deseen innovar con este nuevo modelo computacional. 10

11 MARCO TEÓRICO Con el objetivo d mejorar la calidad de imágenes digitales es necesario conocer cuáles son los factores de control de los que depende dicha transformación. Esta investigación está centrada en la Transformación de Diagramas de Clases a Código Fuente Java, basándose en Arquitectura Orientada a Modelos, en donde estudiaremos algunos conceptos básicos para lograr esta meta y analizaremos los diferentes Modelos de Transformación existentes Modelo Es una representación o abstracción de una situación u objeto real, que muestra las relaciones (directas o indirectas) y las interrelaciones de la acción y reacción en términos de causa y efecto. Un modelo es una descripción de todo o parte de un sistema escrito en un lenguaje bien definido. El hecho de que un modelo esté 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. Tipos: Mentales Físicos idealizados Explícitos Físicos Materiales Matemáticos o Deterministas o Estocásticos 11

12 2.2. Modelo Computacional Es un modelo matemático en las ciencias de la computación que requiere extensos recursos computacionales para estudiar el comportamiento de un sistema complejo por medio por medio de la simulación por computadora. El sistema bajo estudio es a menudo un sistema complejo no lineal para el cual las soluciones analíticas simples e intuitivas no están fácilmente disponibles. En lugar de derivar una solución analítica matemática para el problema, la experimentación es hecha con el modelo cambiando los parámetros del sistema en la computadora, y se estudian las diferencias en el resultado de los experimentos Arquitectura Orientada a Modelos MDA Se trata de un framework de desarrollo de software que define una nueva forma de construir software en la que se usan modelos del sistema, a distintos niveles de abstracción, para guiar todo el proceso d desarrollo, desde el análisis y diseño hasta el mantenimiento del sistema y su integración con futuros sistemas. [1] Las principales ventajas de la arquitectura dirigida por modelos en la ingeniería de software con modelos independientes de plataformas son dos: Durante la fase de diseño los desarrolladores no tienen que preocuparse por los detalles y las diferencias entre lenguajes de programación. Se puede transformar un proyecto de un lenguaje a otro. La directiva MDA del Object Management Group (OMG) propone dos tipos de modelos, uno para la fase de análisis y otro para la fase de diseño, este último derivado del primero. [3] Ilustración 1 Fig. N 1. Pasos en el desarrollo con MDA. 12

13 CIM Representa los modelos independientes de la computación (Computationally - Independent Model) que caracterizan el dominio del problema. Este tipo de modelos surge ante todo en procesos de modelado de negocio e idealmente se conciben antes del levantamiento de requisitos para una aplicación particular. Los lenguajes de transformación populares y transformaciones. [1] PIM Es un modelo de sistema que muestra mayormente el proceso de análisis y detalles que generales de la plataforma que será implementado. El modelo de la fase de análisis es el PIM (Platform Independent Model), que es un modelo independiente de la plataforma, lo cual significa que los diagramas que lo componen son vistas del sistema construidas específicamente en términos del dominio. Ilustración 2 Fig. N 2. Tecnologías PIM El PIM es la base para la construcción del modelo de la fase de diseño, que se conoce como PSM (Platform Specific Model), el cual está compuesto por diagramas construidos siguiendo los lineamientos no sólo de estructura y comportamiento del sistema, sino también de una plataforma específica.[1] 13

14 Como podemos ver en la siguiente Figura N 3, muestra un ejemplo de un PIM sencillo con tres clases interrelacionadas. El PIM se modela mediante el diagrama de clases de UML. Ilustración 3 Fig. N 3. Ejemplo de PIM PSM Es un modelo de sistema con detalles específicos de la plataforma en la que será implementado. Se genera a través de un PIM así que representa el mismo sistema pero a distinto nivel de abstracción. Podemos decir que un PSM es un PIM al que se le añaden detalles específicos para ser implementados en otra plataforma. En MDA se utiliza el lenguaje unificado de modelado UML para especificar los modelos. Según OMG, MDA proporciona una solución para los cambios de tecnología. Permitiendo construir aplicaciones independientes dela plataforma e implementarlas en plataformas como CORBA, J2EE o Servicios Web. [1] En la Figura 4 muestra un PSM construido a partir del PIM de la Figura 3, representado también mediante un diagrama de clases UML. Este sencillo ejemplo muestra un posible PSM para la plataforma EJB (Enterprise Java Beans. Ejm. La herramienta Javadoc para Java). Como vemos, en el paso del PIM al PSM se han producido varias transformaciones: 14

15 Se ha añadido el estereotipo <<EJEBEntity>> a cada clase, para indicar que la clase representa un EJB de tipo Entity. Se ha modificado la visibilidad de los atributos del PIM de público a privado. Se han generado métodos públicos de lectura y modificación (get y set) para cada atributo. Ilustración 4 Fig. N 4. Ejemplo de PSM De un mismo PIM pueden generarse varios PSMs; cada uno describiendo el sistema desde una perspectiva diferente. Ilustración 5 Fig. N 5. Tipos de Modelos según abstracción. 15

16 2.4. Transformación en MDA a Código Fuente: Son reglas o secuencia de pasos que permiten relacionar cada instancia del metamodelo, se utilizan para producir desde una meta modelado propuesto por un estándar MDA hacia un Código para la implementación que puede obtenerse a partir de éste. [5] Una definición de transformación o mapping MDA proporciona la especificación de un PIM en un PSM para una plataforma determinada. Tipos: Ilustración 6 Fig. N 6. Transformación MDA Según [5], podemos distinguir dos tipos de definiciones de transformación: Transformaciones de Tipos (Model Type Mapping) Un mapping de tipos especifica un mapping para transformar cualquier modelo construido con tipos del PIM a otro modelo expresado con tipos del PSM. Es decir, a cada tipo de elemento del PIM se le aplica una regla determinada para transformarlo en uno o varios elementos del PSM. En el caso de UML, estas reglas pueden estar asociadas a tipos del metamodelo (clase, atributo, relación, etc) o a nuevos tipos definidos mediante estereotipos. También pueden definirse reglas en función de valores de instancias en el PIM. 16

17 Transformaciones de instancias (Model Instante Mapping) Identifica elementos específicos del PIM que deben ser transformados de una manera particular, dada una plataforma determinada. Esto se puede conseguir mediante marcas. Una marca representa un concepto del PSM, y se aplica a un elemento del PIM para indicar cómo debe ser transformado. Las marcas, al ser específicas de la plataforma, no son parte del PIM. El desarrollador marca el PIM para dirigir o controlar la transformación a una plataforma determinada. Características Deseables de las Transformaciones: Ajustar las transformaciones El requisito principal que debería cumplir toda herramienta de transformación es permitir que el desarrollador tenga cierto control sobre el proceso de transformación. Se puede lograr de varias maneras: Control manual. Condiciones en las transformaciones. Parámetros de transformación. Trazabilidad La trazabilidad implica que pueda conocerse el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino. Es útil para el cambio de nombre de una operación del PSM generada a partir del PIM, el cambio debe reflejarse también 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. 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. 17

18 Consistencia incremental Cuando se genera un modelo destino, este necesita algún trabajo extra, como rellenar el código de una operación o refinar la interfaz de usuario. Si regeneramos de nuevo el modelo destino, debido a cambios en el modelo origen, queremos que el 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 que 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. Bidireccionalidad La bidireccionalidad implica que las transformaciones puedan operar en ambas direcciones. Esta propiedad tiene menor prioridad que las anteriores, a pesar de ser interesante. 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. Transformación de PIM a PSM: La transformación de PIM a PSM puede llevarse a cabo de varias formas: Construyendo manualmente el PSM a partir del PIM. De forma semiautomática, generando un PSM esqueleto que es completado a mano. De forma totalmente automática, generando un PSM completo a partir del PIM. 18

19 Para las transformaciones automáticas se usan herramientas especializadas. Estas herramientas tienen implementados distintos algoritmos para pasar de un tipo de modelo a otro, y suponen uno de los pilares de MDA. Las herramientas de transformación de modelos se verán a continuación: Herramientas de Transformación de PIM a PSM Permiten transformar un PIM de alto nivel en uno o varios PSMs. En la actualidad no hay disponibles muchas herramientas de este tipo, ya alas que existen ofrecen escasa funcionalidad. Herramientas de Transformación de PSM a Código El soporte más popular para MDA lo encontramos en las herramientas que transforman PSM a código. Poseen una definición de transformación integrada que toman un tipo predefinido de modelo de entrada (PSM) y producen otro tipo predefinido como salida (modelo de código). Las herramientas CASE tradicionales siguen este patrón para la generación de código. Muchas de estas herramientas mantienen la relación entre el PSM y el código permitiendo que los cambios realizados en cualquiera de los modelos (PSM y código) se reflejen inmediatamente en el otro. Esto es posible porque el PSM y código están muy cerca el uno del otro, y poseen casi el mismo nivel de abstracción. Herramientas de Transformación de PIM a Código Otro tipo de herramienta es aquella que soporta las dos transformaciones anteriores, de PIM a PSM y de PSM a Código. En ocasiones el usuario simplemente verá una transformación directa de PIM a código, quedando implícito el PSM. La herramienta ArcStyler podría enmarcarse en este grupo, ya que no existe PSM explícito, sino que se usa un PIM con marcas para generar directamente el código. Herramientas de Transformación Ajustables Las herramientas de MDA deberían permitir refinar o ajustar las transformaciones. Normalmente no se permite acceder a las definiciones 19

20 de las transformaciones para ajustarlas a tus propios requisitos. En el mejor de los casos, las herramientas proporcionan sus definiciones de transformaciones en lenguaje de script específicos de la herramienta, y resulta muy engorroso hacer cambios en dichos lenguajes. Mientras no se estandarice un lenguaje de definición de transformaciones, estas seguirán siendo específicas de cada herramienta. Herramientas de Definición de Transformaciones Un último tipo de herramientas lo constituirían aquellas herramientas que nos permiten crear y modificar transformaciones sobre modelos, imprescindibles si necesitamos usar transformaciones distintas a las disponibles en las herramientas. Las únicas herramientas disponibles de este tipo usan lenguajes de script específicos. La complejidad de la definición de transformaciones nos lleva de nuevo a la necesidad de un lenguaje estándar de definición de transformaciones (QTV) y a disponer de herramientas mejor preparadas para esta tarea. Por desgracia, todavía queda algo de tiempo para que esto se convierta en realidad. Otras herramientas Editor de código. Realiza las tareas comunes proporcionadas por un Entorno de Desarrollo Interactivo (IDE), como depuración, compilación y edición de código. Ficheros de código. Aunque podemos considerar el código como un modelo, usualmente se almacena en forma de ficheros de texto; los cuales no son un formato que otras herramientas pueden entender. Se necesitan los siguientes dos elementos: o Analizador gramatical de ficheros de texto, que lea un fichero de texto y almacene el código en forma de modelo en el repositorio de modelos, de manera que otras herramientas lo puedan usar. o Generador de ficheros de texto, que lea el código del repositorio de modelos y produzca un fichero de código basado en texto. 20

21 Repositorio de modelos. Es la base de datos para modelos, donde los modelos se almacenan y se recuperan usando XMI, JMI o IDL. Editor de modelos. Herramienta CASE para construir y modificar modelos. Verificador de modelos. Los modelos usados para la generación de otros modelos deben estar extremadamente bien definidos. Estas herramientas pueden chequear los modelos para comprobar que cumplan unas determinadas reglas y asegurarse así que puedan ser transformados. Editor de definiciones de transformaciones. Para permitir crear y modificar definiciones de transformaciones. Repositorio de definiciones de transformaciones. Para almacenar las definiciones de transformaciones. En la Figura 7 muestra un diagrama que resume la funcionalidad deseable en un entorno completo de desarrollo con MDA. Ilustración 7 Fig. N 7. Funcionalidad en un entorno de desarrollo MDA 21

22 2.5. Metamodelos: Son un mecanismo que permite definir formalmente lenguajes de modelado. Básicamente se trata de modelos para describir otros modelos. Una meta-modelo que define el lenguaje para la siguiente capa, que es la meta modelo Suena complicado, pero la idea es más simple de lo que parece: esta capa consiste de un modelo compacto que sirve de cimentación para el conjunto de la arquitectura. El meta-modelo es común al MOF y a UML, lo que asegura que compartan una base común. El meta-meta-modelo asegura, por ejemplo, que los tipos de datos manejados por el lenguaje de modelado y el servicio MOF sea totalmente compatible. Importancia del meta modelado en MDA: En primer lugar, el meta modelado es importante en MDA porque actúa como mecanismo para definir lenguajes de modelado, de forma que su definición no sea ambigua. Esta no ambigüedad permite que una herramienta pueda leer, escribir y entender modelos como los construidos con UML. Por otro lado, las reglas de transformación, usadas para transformar un modelo en lenguaje A en otro modelo en lenguaje B, usan la meta modelos de los lenguajes A y B para definir las transformaciones OMG: El Object Management Group [OMG] es un consorcio internacional abierto y sin ánimo de lucro de la industria de la informática creada en En él están incluidas cientos de organizaciones dedicadas al desarrollo de software para usuarios finales, especializados en docenas de mercados de negocio diferentes y organizaciones dedicadas a la industria de los computadores.[6] En sus orígenes [Watson 2008], OMG se constituyó para especificar elementos middleware que ayudaran a resolver los problemas de integración entre sistemas de información multiplataforma. 22

23 Con esta idea surgió la especificación de CORBA (Common Object Request Broker Architecture) y otros estándares como el Interface Definition Language (IDL) [OMG 2002], que permite definir las interfaces de los servicios que se van a utilizar en la comunicación entre las distintas plataformas a integrar. Hace casi una década, OMG decidió dar el salto desde una aproximación basada en servicios de integración a una aproximación independiente de la plataforma, que definiera situaciones y aspectos estructurales de la interoperabilidad mediante modelos. Estos modelos independientes de la plataforma podrían ser convertidos, mediante reglas de transformación, a cualquier plataforma específica. Un poco antes, a mediados de los años 90, basándose en un incipiente modelado orientado a objetos, OMG crea el lenguaje de modelado UML que permite representar aspectos dinámicos y estáticos de un sistema de información software. Aplicando UML y MOF (Meta Object Facility), el Meta modelo que define UML, al problema de la creación de modelos independientes de la plataforma, permite la creación de la aproximación MDA. OMG desarrolla estándares de integración para un amplio rango de tecnologías: tiempo real, sistemas empotrados, entre otros y una amplia variedad de industrias diferentes: modelado e integración de negocios, finanzas, administración pública, salud, etc. Arquitectura: OMG usa una arquitectura de cuatro niveles o capas de modelado para sus estándares. En la terminología del OMG estas capas se llaman M0, M1, M2 y M3: Capa M0: Instancias En el nivel M0 están todas las instancias reales del sistema, es decir, los objetos de la aplicación. Aquí no se habla de clases ni atributos, sino de entidades físicas que existen en el sistema. Ejemplo: Supongamos un sistema que debe manejar clientes de un videoclub. En la Figura 8 vemos las entidades que almacenan los datos (nombre, 23

24 dirección y teléfono) de los clientes David Aguilar y Miguel Martínez. Estas entidades son instancias pertenecientes a la capa M Capa M1: Modelo del Sistema Ilustración 8 Fig. N 8. Entidades de MOF Capa M0 Por encima de la capa M0 se sitúa la capa M1, que representa el modelo de un sistema software. Los conceptos del nivel M1 representan categoría de las instancias de M0. Es decir, cada elemento de M0 es una instancia de un elemento de M1. Ejemplo: Como vemos en la Figura 9, en el nivel M1, aparecería la entidad Cliente con los atributos nombre, dirección y teléfono, que representa a todos los clientes de la aplicación. La entidad Articulo, que representa a todos los artículos que pueden alquilarse en el videoclub, también pertenecen al nivel M1. Ilustración 9 Fig. N 9. Entidades de MOF Capa M1 Los modelos creados usando UML pertenecen a este nivel M1. 24

25 Capa M2: Metamodelo Análogamente a como ocurría con M0 y M1, los elementos del nivel M1 son a su vez instancias del nivel M2. Esta capa recibe el nombre de capa de metamodelo. En este nivel aparecerán conceptos como Clase, Atributo o Relación. Ejemplo: La entidad Cliente mostrada en el apartado anterior sería una instancia de la metaclase UML Class del metamodelo de UML que aparece en la Figura 10, junto a la metaclase UML Attribute. Ilustración 10 Fig. N 10. Entidades de MOF Capa M2 El metamodelo de UML estaría situado en este nivel M2 y gracias a él podemos construir modelos de nivel M1 en UML Capa M3: Meta-metamodelo En la misma línea, podemos ver los elementos de M2 como instancias de otra capa superior M3, la capa de meta-modelo. Dentro del OMG, MOF es el lenguaje estándar de la capa M3. Esto supone que todos los metamodelos de la capa M2, por ejemplo, el metamodelo de UML, son instancias de MOF. O lo que es lo mismo, UML se define usando MOF. Ejemplo: La Figura 11 muestra un ejemplo de entidades de la capa M3. La clase de M2 UML Class es una instancia de la clase de M3 MOF Class. Ilustración 11 Fig. N 11. Entidades de MOF Capa M3 25

26 Una visión completa de las capas: La Tabla N 1 muestra la relación entre capas de modelado definidas por el OMG. CAPA CONTENIDOS EJEMPLOS M0 Instancias Instancias reales del sistema Cliente con nombre= David Aguilar y DNI= M1 modelo M2 Metamodelo M3 Meta-metamodelo Entidades del modelo del sistema Entidades de un lenguaje de modelado Entidades para definir lenguajes de modelado Clase Cliente con atributos nombre y DNI Entidad UML Class del metamodelo de UML Entidad MOF Class de MOF Tabla N 1. Tabla de las Capas de Modelado Ilustración 12 Fig. 12. Relación entre las Capas de Modelado 26

27 2.7. Lenguaje Modelado de Proceso UML: Lenguaje Unificado de Modelado (LUM o UML, por sus siglas en inglés, Unified Modeling Language) 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). [6] UML es un lenguaje estándar para visualizar, especificar, construir y documentar los artefactos de un sistema de software. Puede usarse en las diferentes etapas del ciclo de vida del desarrollo y en diferentes tecnologías de implementación. Es independiente del proceso de desarrollo de software. UML está compuesto por diversos elementos gráficos que se combinan para conformar diagramas. Al ser UML un lenguaje, existen reglas para combinar dichos elementos. En conjunto, los diagramas UML brindan diversas perspectivas de un sistema, por ende el modelo. Ahora bien, el modelo UML describe lo que hará el sistema y no como será implementado. [6] Ilustración 13 Fig. N 13. Transformaciones de un Modelo UML 27

28 Diagrama de Clases Los diagramas de clases representan las clases intervinientes en el sistema, destacando con que otras clases se relacionan y como lo hacen. Ilustración 14 FIG. 14. Modelo de una Clase Diagrama de Casos de Uso Describen las acciones de un sistema desde el punto de vista del usuario. Si la finalidad es crear un sistema que pueda ser usado por la gente en general, es importante este diagrama, ya que permite a los desarrolladores (programadores) obtener los requerimientos desde el punto de vista del usuario. [6] Ilustración 15 FIG. 15. Modelo de un Caso de Uso. 28

29 Diagrama de Estados Muestra las transiciones de un objeto en sus cambios de estados. Por ejemplo, una persona es recién nacida, niña, adolecente o adulta. Una lavadora puede estar en las fases de remojo, lavado, enjuague, centrifugado o apagada. Un elevador se puede mover hacia abajo, hacia arriba o estar en esta de reposo. [6] El símbolo de la parte superior indica el estado inicial y el de la parte inferior el estado final (apagado). Ilustración 16 Fig. 16. Modelo de un Diagrama de estado Diagrama de Secuencias Representan información dinámica ya que los objetos interactúan entre si mientras el tiempo transcurre. En definitiva, los diagramas de secuencias, visualizan la mecánica de interacciones entre objetos con base en tiempos. [6] 29

30 Sobre nuestro ejemplo de la lavadora, encontramos los componentes manguera, tambor y drenaje como objetos que interactúan mientras transcurre el tiempo de funcionamiento. Ilustración 17 Fig. 17. Modelo de un Diagrama de Secuencia Diagrama de Actividades En un caso de uso como en el comportamiento de objetos en un sistema, siempre hay actividades que generalmente son secuenciales. 30

31 Sin importar el tiempo, podemos reflejar en el diagrama de actividades, la secuencia de acciones que desarrollan los objetos. [6] Ilustración 18 Fig. 18. Modelo de un Diagrama de Actividades Diagrama de Clases: Son modelos de diseño creado para ver la interactividad de todas las clases del sistema y sus detalles de implementación. Un diagrama de clases es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro. [3] Presenta las siguientes características: Proporciona una visión general de todas las clasificaciones que se encuentran en un sistema. Presenta las clases del sistema con sus relaciones estructurales. 31

32 La herencia de propiedades de otro objeto, conjuntos de operaciones/propiedades que son implementadas para una interfaz gráfica. [4] Un diagrama de clases está compuesto por los siguientes elementos: Clase: atributos, métodos, visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso. Ilustración 19 Fig. N 19. Diagrama de Clases 32

33 Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). En UML, una clase es representada por un rectángulo que posee tres divisiones: En donde: Ilustración 20 Fig. 20: Representación Estructural de una Clase. Zona superior: Contiene el nombre de la Clase. Zona intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public). Zona inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public). Ejemplo: Una cuenta corriente que posee como característica: Ilustración 21 Fig. 21. Modelo de un Clase en UML. 33

34 Atributos y Métodos: Atributos: Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son: Public: Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. Private: Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar). Protected: Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven. Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características: Public: Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. Private: Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar). Protected: Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven. 34

35 Relaciones La Relación es el enlace o interactividad lógica que se le da a cada uno de los Objetos con Otros objetos en un Diagrama de Clases. Cardinalidad de Relaciones: En UML, la Cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser: Uno o muchos: 1..* (1..n) 0 o muchos: 0..* (0..n) Número fijo: m (m denota el número). Herencia: Indica que una subclase hereda los métodos y atributos especificados por una Súper Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Súper Clase (public y protected). Ejemplo: 35

36 Ilustración 22 Fig. 22. Modelo de Herencia de Clases. En la figura 22 se especifica que Auto y Camioneta heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camioneta también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga. Cabe destacar que fuera de este entorno, lo único "visible" es el método Características aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados. [6] Agregación: Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de 36

37 vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento). Ejemplo: Ilustración 23 Fig. 23. Representación de Agregación de Clases en UML. En donde se destaca que: Un almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente. La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina. 37

38 Asociación: La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro. Ejemplo: Ilustración 24 Fig. 24. Representación de Asociaciones de Clases en UML. Un cliente puede tener asociadas muchas Órdenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente. Dependencia o Instalación (uso): Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada. El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana está condicionado a la instanciación proveniente desde el objeto Aplicación): 38

39 Ilustración 25 Fig. 25. Representación de Dependencia de Clases en UML. Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación). [3] 2.9. Herramientas de Transformación Herramienta OptimalJ de Compuware Se trata de un entorno de desarrollo de aplicaciones empresariales que permite generar con rapidez aplicaciones J2EE completas directamente a partir de un modelo de alto nivel (PIM), utilizando patrones para codificar adecuadamente las especificaciones de J2EE y haciendo uso de estándares de MDA. Arquitectura: OptimalJ implementa el framework MDA haciendo uso de tecnologías estándares MOF, UML, XML, WSDL y J2EE. Se distinguen 3 tipos de Modelos: Modelo de Dominio: Modelo de alto nivel que muestra la arquitectura general del sistema. Contiene los PIM de la aplicación. Este Modelo a su vez usa dos tipos de modelos, el Modelo de Clases u el Modelo de Servicios. 39

40 Modelo de Clases: Se definen la estructura de la información con la que se trabaja la aplicación mediante un diagrama de clases UML. Este Modelo es el PIM de la aplicación. Modelo de Servicios: Permite definir vistas sobre las clases definidas en el modelo de clases. Básicamente, la funcionalidad disponible en este modelo consiste en limitar el acceso a las acciones de crear, leer, modificar o eliminar instancias y ocultar la aparición de determinados atributos en la interfaz de la aplicación generada. Modelo de Aplicación: Modelo del sistema desde el punto de vista de una tecnología determinada (J2EE). Contiene los PSM de la aplicación. Modelo de Código: Código de aplicación, generado a partir de modelo de la aplicación. Así mismo, OptimalJ usa 2 tipos de transformaciones entre modelos: Patrones de transformación entre modelos: Patrones de Tecnología: Transforman el Modelo de Dominio (PIM) en el modelo de Aplicación (PSM). Patrones de Implementación: Transforman el modelo de aplicación (PSM) en Código. 40

41 Patrones funcionales para transformaciones dentro de modelos: Patrones de Dominio: Patrones definidos por el usuario que permiten a los desarrolladores capturar, reutilizar y distribuir modelos del dominio. Patrones de Aplicación: Usan el mismo principio que los patones del dominio pero aplicados a modelos de aplicación. Patrones de Código: Patrones de bajo nivel aplicados al Código. Ilustración 26 Fig.26 ArcStyler Error! No se encuentra el origen de la referencia. ArcStyler permite la transformación de modelos a otros modelos, a código fuente y ficheros relacionados con las pruebas y despliegue, así como ficheros de proyecto para editores de código como JBuilder. Las transformaciones en ArcStyler están ligadas a los llamados MDA Cartriedges como una de sus principales características, permitiéndole definir nuestras propias reglas de transformación a modelos. Actualmente existen muchos numerosos MDA-Cartriedges para diferentes arquitecturas o plataformas como J2EE, EJB, NET, aplicaciones web, etc. 41

42 ArcStyler permite definir y administrar potentes transformaciones de modelos y también permite controlar el proceso completo de desarrollo de software mediante múltiples perspectivas integradas dentro de la misma herramienta. ArcStyler integra numerosas herramientas en el mismo entorno de desarrollo, incluidas: o o o o Una completa herramienta de modelado UML. Una Herramienta de ingeniería inversa que transforma ficheros fuente de Java y ficheros JAR y FAR en modelos UML. Un explorador genérico basado en MOF que puede usarse para modelos de cualquier metamodelo. Una herramienta ANT para administrar reglas de construcción y despliegue. Componentes: UML: Software UML que proporciona crear modelos de modelamiento de objetos. MDA Profiles: ArcStyler usa el mecanismo de Perfiles UML descrito en el aparato Perfiles UML para proporcionar extensiones extandares que soportan el modelado de MDA. Los cuales contiene los siguientes elementos: Estereotipos. Tipos de datos. Marcas. MOF y XMI: ArcStyler usa MOF internamente para dar soporte entre otros a UML, XMI y JMI. 42

43 XMI es la parte del estándar MOF que define como representar los modelos de un determinado metamodelo usando XML. De esta manera podemos exportar modelos a otras herramientas con soporte XMI. JMI (Java Metadata Interface): Es un estándar sugerido por Java Community Process (JCP) de SUN. ArcStyler se basa íntegramente en JMI. Es la base común para el acceso a cualquier modelo a través de herramientas. El principal beneficio de esto es que un gran número de repositorios son conformes a JMI, con lo que solo es necesario un pequeño esfuerzo para integrar esos repositorios en ArcStyler. En otras herramientas también basadas en interfaces JMI. Funciones de Transformación de Modelos: Las funciones de transformación que transforman modelos en otros modelos o en código fuente constituyen el núcleo de MDA. Una función de Transformación puede usar uno o más modelos como entrada y producir un modelo de salida. Un tipo especial de Modelo de salida es un conjunto de ficheros de texto que cumplen un conjunto escrito de reglas, por ejemplo la definición sintáctica de un lenguaje de programación. ArcStyler usa los MDA- Cartridges como componentes desplegables que encapsulan una función de transformación 43

44 Ilustración 27 Fig.27 Arquitectura de ArcStyler Otras Herramientas: MODELOS Entrada Lenguaje de Salida Estándares ArcStyler UML TODOS XMI, UML, MOF, JMI OptimalJ XMI V1.1 EN, J2EE XMI, UML, MOF, XML, WSDL, J2EE AndroMDA XMI V1.1 TODOS Struct, NetBeans MDR,ant Mybernate,Velocity, xdoclet y Maven Codogen Architect XMI V1.1, MDD de Rational, Visio, Together Java, C#, C++, Visual Basic Together Architect XMI Java, C#, C++, Corba, Visual Basic 6, Visual Basic.net Struct XMI Tabla.2 Arquitectura de OptimalJ 44

45 2.10. Java Java es toda una tecnología orientada a la programación de software con el cual podemos realizar cualquier tipo de programas. Una de las principales características es su capacidad de que el código fuente funcione sobre cualquier plataforma de software y hardware, es decir, un mismo programa puede ejecutarse en varios sistemas sin tocar el código fuente. Además es un lenguaje orientado a objetos que resuelve los problemas en la complejidad de los sistemas, entre otras. [4] Plataforma de Java: Los programas Java se compilan a un lenguaje intermedio, denominado Bytecode. Este código es interpretado por la máquina virtual de Java del entorno de ejecución (JRE) y así se consigue la portabilidad en distintas plataformas. El JRE es una pieza intermedia entre el código Bytecode y los distintos sistemas operativos existentes en el mercado. Ilustración 28 Fig.28 Plataformas de JAVA 45

46 Un programa Java compilado en Bytecode se puede ejecutar en sistemas operativos como Windows, Linux, Mac Os, Solaris, BlackBerry OS, ios o Android utilizando el entorno de ejecución de Java (JRE) apropiado. Una de las características más importantes de los lenguajes de programación modernos es la portabilidad. Un programa es portable cuando es independiente de la plataforma y puede ejecutarse en cualquier sistema operativo y dispositivo físico. Los programas Java son portables porque se ejecutan e cualquier plataforma. La portabilidad de Java ha contribuido a que muchas empresas hayan desarrollado sus sistemas de comercio electrónico y sus sistemas de información en Internet con Java. El proceso de desarrollo y de mantenimiento de los sistemas resulta menos costoso y las aplicaciones son compatibles con distintos sistemas operativos. La evolución del lenguaje de programación Java ha sido muy rápida. La plataforma de desarrollo de Java, denominada Java Development Kit (JDK), se ha ido ampliando y cada vez incorpora a un número mayor de programadores en todo el mundo. En la realidad Java no solo es un lenguaje de programación, Java es un lenguaje, una plataforma de desarrollo, un entorno de ejecución y un conjunto de librerías para desarrollo de programas sofisticados. Las librerías para desarrollo se denominan Java Application Programming Interface (Java API). La Figura 27 muestra los elementos de la plataforma Java, desde el código fuente, el compilador, el API de Java, los programas compilados en Bytecode y el entorno de ejecución de Java. Este entorno de ejecución (JRE) y la máquina virtual (JVM) permiten que un programa compilado Java se ejecute en distintos sistemas operativos. 46

47 Ilustración 29 Fig.29 Elementos de la plataforma Java. 47

48 MATERIALES Y MÉTODOS 3.1. Diseño de la Investigación Para dicho análisis se aplicara el diseño Pre-Experimental el cual se encuentra representado por el gráfico: Dónde: : Un algoritmo de transformación realizado con arquitectura orientada a modelos. : Grupo de prueba. Medición aplicando Medición sin aplicar a a 3.2. Población y muestra Población Todas las transformaciones existentes de un diagrama de clases a código fuente Java Muestra Para poder conocer la muestra se una población de más de ejemplares de clases se utiliza la siguiente formula: 48

49 Dónde: : Número de elementos de la muestra. Probabilidad con las que se presenta el fenómeno. Valor crítico correspondiente al nivel de confianza elegido; siempre se opera con Margen de error permitido (determinado por el responsable del estudio). Observaciones: El valor de es mayor a clases de las cuales se utilizara la población de muestra infinita. El valor de es ya que la confianza de éxito es muy alta. Como valor del fenómeno de transformación se presenta siempre entonces el valor de es ; este restante, representa aquellas transformaciones en las que no es necesario usar técnicas ya que solamente hay clases unitarias. Pongamos un margen de error del, es común poner ya que se desconoce los resultados esperados. Esto nos da un resultado de muestras de diagrama de clases que hay que tomar para aplicar los métodos de transformación a código fuente Java. 49

50 3.3. Variables de estudio Variable Dependiente Mejorar la transformación de un Diagrama de Clases a Código Fuente Java Variable Independiente Desarrollo de un algoritmo de transformación de diagrama de clases a código fuente Java Factor de Medición de Mejora del Tiempo Disminuir el tiempo de desarrollo, así mismo el grado de complejidad Técnicas e Instrumentos Técnicas El presente trabajo de investigación consistirá en: La investigación bibliográfica de búsqueda de artículos en la web, libros y casos de estudio en relación con el tema de investigación. El análisis sobre los distintos modelos de transformación de diagramas de clases a código fuente java. El diseño del modelo que se realizara a partir del análisis realizado en la fase anterior. La implementación del algoritmo de transformación teniendo en cuenta el modelo realizado. La aplicación de pruebas sobre el modelo computacional. El análisis de mejora de la usabilidad según los resultados obtenidos en las pruebas, y del tiempo de desarrollo del algoritmo. 50

51 Instrumentos Para la recolección de datos utilizaremos los datos producidos a través de técnicas de pruebas del software para los 10 modelos de diagramas de clases; además de la búsqueda de artículos, casos de estudio y libros referentes al tema. 51

52 RESULTADOS 4.1. Análisis de las Modelos de Transformaciones: En este capítulo se analizara los siete modelos que relacionan el estándar MDA con respecto a la transformación de Modelos. Se presentara una comparación con respecto a otros modelos para permitirnos observar las diferencias que tiene cada uno de los modelos con respecto a otros. Los criterios que se utilizaran son los siguientes Diagramas UML. Utiliza diagramas UML para el modelado. Consistencia. Es importante para mantener la información adicional que se requiere para transformar un modelo en otro, de manera que pueda reutilizarse cuando se requiera una modificación o actualización del modelo fuente para volver a realizar su transformación al modelo objetivo. Trazabilidad. Implica conocer el elemento origen a partir del cual se ha generado cualquier elemento del modelo destino. Especificación. Define la información requerida del modelo, para CIM, PIM, PSM o todos. Transformaciones. Soporte a transformaciones entre diferentes niveles de abstracción como: CIM-PIM, PIM-PSM y de PSM-IM (Modelo de Implementación) 52

53 Modelo de Generación Automática de Código: La generación automática de código a partir de modelos ha sido una de las promesas parcialmente cumplidas en el desarrollo de software. La experiencia de las herramientas CASE, aún distante del automatismo absoluto, se complementa con algunos trabajos teóricos que se alejan de los estándares de modelamiento. Se propone reglas para la generación de código a partir de metamodelo de diagramas de clases, secuencias y máquina de estados de UML. Las reglas están definidas en lógica de primer orden, permitiendo una especificación donde se evitan las ambigüedades y la necesidad de aprender un lenguaje de programación específico. Mediante un caso de estudio se representa la aplicación de las reglas de transformación, generando el código fuente de una clase en el lenguaje orientado a objetos Java. Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: Aplica la propiedad automática de consistencia de una manera efectiva, ya que por su uso de la definición metamodelos que utiliza puede saber el diagrama origen (diagrama de clases). Trazabilidad: Por consecuencia de lo anterior también posee la propiedad de trazabilidad. Especificación: Maneja Modelos PIM a PSM, del diagrama de clases al código fuente java. Transformación: La representación de los modelos que utiliza es con los estereotipos de UML teniendo en cuenta los modelos PIM y PSM. Los objetivos que cubre son: lograr una transformación a partir (lógica de un lenguaje formal como el de la lógica de primer orden, y de eso un metamodelo de clases que permita obtener código. 53

54 Modelos reflexivos en MDA: Propone aplicar el enfoque MDA a sí mismo, con las nociones de PIT (Transformaciones Independientes de Plataforma) y PST (Transformaciones de Plataforma Especifica) que dan a MDA dos pasos nuevos en el ciclo de vida de transformaciones de modelos. PIT expresa las transformaciones de modelo de una manera independiente del instrumento (herramienta) y PST marca esta expresión independiente del instrumento sobre un instrumento actual. Cuando se habla de plataformas son entendidas como los instrumentos que permiten la especificación, el diseño y la ejecución de transformaciones. Con el objetivo de transformar de PIM-PIM, PIM- PSM y PSM-PSM se utilizan PIT y PST. Se basa en el enfoque orientado a objetos y toma a UML como un metamodelo que define lenguajes de transformación de tipo PIT y PST. Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: No hay información de la propiedad de consistencia en el modelo dado. Trazabilidad: Como los modelos se enfocan a sí mismos, estos modelos no tienen forma de buscar y solucionar errores al tratar de cambiar el modelo origen ya que es el mismo modelo. Especificación: No Se encontró solo información única referente a un solo modelo. Transformación: La representación de los modelos que utiliza es con modelos de PIM-PIM, PIM-PSM o PSM-PSM. 54

55 Una propuesta de Modelo de V&V en el marco de MDA Presenta un proceso V&V (Validación & Verificación) genérico para ser aplicado en el ámbito de metodologías basadas en MDA o MDD usado para detectar errores e inconsistencias en las etapas tempranas del desarrollo, evitando así la propagación de esos errores a las etapas posteriores, ya que un error en el PIM se arrastra a un PSM hasta llegar al código. Además el proceso sugerido sirve para identificar funciones importantes que deberían cumplir las herramientas de soporte de MDA respecto a realizar modelos correctos por medio de la verificación y validación. Para pasar al modelado del PSM el proceso de verificación y validación debe ser realizado tanto para el análisis de requisitos como para el modelado del PIM. Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: No hay información de la propiedad de consistencia en el modelo dado. Trazabilidad: No posee ninguna propiedad de trazabilidad. Especificación: Se encontró solo información referente a los modelos PIM. Transformación: No se han descubierto un uso de una transformación existente propio en este modelo. Ya que es un modelo de verificación y validación. 55

56 AspectMDA: Modelo de desarrollo incremental consistente integrando MDA y orientación a aspectos Se basa en la idea de especificar diferentes modelos que corresponden con distintos aspectos del sistema (como seguridad, restricciones de tiempo real, ), este integra a MDA, DSOA (Desarrollo de Software Orientado a Aspectos) xlinkit de una forma adecuada y beneficiosa para el MDD. Los objetivos de este artículo son: modelar esos aspectos (artefactoso propiedades de un sistema) por cada equipo de trabajo desde el CIM hasta el PSM con el mínimo de comunicación, verificarla consistencia, mejorar la trazabilidad entre los diferentes niveles de abstracción y controlar el impacto al cambio. De este modo, los niveles MDA se especifican en diferentes facetas de sistema que modela los aspectos y los mantienen separados durante todo el marco (MDA). Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: El modelamiento de aspectos hace que el modelado posea la propiedad de consistencia tanto como la trazabilidad Trazabilidad: La trazabilidad del Modelo se afirma a través de la tecnología orientada a aspectos Especificación: No se especifica en ninguno de los 3 tipos de modelos ya que abarca todos ellos. Transformación: La representación de los modelos que utiliza es con los estereotipos de UML para especificar las vistas de CIM, PIM y PSM. Los objetivos que cubre son: lograr una separación de aspectos (lógica del negocio, requerimientos, ) en el nivel (se utilizan casos de uso) y eliminar los Crosscutting Concerns que aparecen dentro de cada punto de vista que modela el sistema, esto hace que sea posible los 3 niveles de transformación. 56

57 Modelos de descripción de PIM Presenta un enfoque de Ingeniería Dirigida por Modelos (MDE por sus siglas en inglés), que utiliza la visión MDA. El MDE toma en consideración dos aspectos importantes: la separación de aspectos funcionales (ejemplo requerimientos) de los no funcionales (ejemplo calidad) de un sistema y los aspectos de plataforma independiente de los de plataforma específica. Se definen las partes que conforman a un PIM como: Contexto (el alcance del sistema a ser desarrollado), Requerimientos, Análisis (especifica la vista interna del sistema) y Diseño del componente (solución independiente de plataforma expresada en términos de componentes de software). Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: No hay información de la propiedad de consistencia en el modelo dado. Trazabilidad: No hay información de la propiedad de trazabilidad en el modelo dado. Especificación: Se encontró solo información referente a los modelos PIM. Transformación: No se especifica en ninguno de los 3 tipos de transformación. 57

58 Conceptos y técnicas de PSM y Técnicas de mapeo de PIM a PSM Proyectos de MASTER (Model-driven Architecture Instrumentation, Enhancement and Refinement) que es el nombre de un proyecto cuyo objetivo es realizar una revisión de los conceptos de MDA. En el concepto y Técnicas se mencionan las características que debe tener un PSM para ser construido de acuerdo al perfil de la plataforma, librerías, conjunto de reglas, patrones y meta modelos. En las Técnicas de mapeo de PIM a PSM se centra en las transformaciones de PIM a PSM que deben considerar las características de trazabilidad, bidireccionalidad, consistencia y simplicidad (para facilitar las pruebas o verificación en la transformación). Utilizan separación de aspectos para el mapeo de PIM a PSM, refiriéndose a que el PSM aborda tanto cuestiones tecnológicas como de negocios, por lo que se deben separar y a esta separación le llama separación de aspectos, para que la parte del negocio no se disperse en la tecnología, sino que el modelo PIM del negocio se enriquezca de la tecnología. Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: No hay información de la propiedad de consistencia en el modelo dado. Trazabilidad: No hay información de la propiedad de trazabilidad en el modelo dado. Especificación: Se encontró solo información referente a los modelos PIM a PSM. Transformación: La representación de los modelos a través de mapeos hace que utiliza es con los estereotipos de UML para especificar las vistas de, PIM y PSM. 58

59 Enfoque basado en componente orientado a características para la transformación de CIM a PIM Presenta un enfoque de transformaciones de CIM a PIM, considerando al CIM como un modelo de características (características) y al PIM como la arquitectura de software (componentes). Se resuelven parcialmente 2 problemas con respecto a la transformación de CIM a PIM: el seguimiento de CIM a PIM (como los elementos en el CIM pueden ser remontados a elementos en el modelo PIM) y la construcción de PIM basado en CIM (como formar los elementos del PIM en la transformación). Diagramas UML: La diagramación UML está presente en cada uno de los modelos propuestos. Consistencia incremental: No hay información de la propiedad de consistencia en el modelo dado. Trazabilidad: como los elementos en el CIM pueden ser remontados a elementos en el modelo PIM, este cumple con la propiedad de trazabilidad. Especificación: No se encontró información a ningún modelo referente a los modelos. Transformación: Presenta un enfoque de transformaciones de CIM a PIM, considerando al CIM como un modelo de características Análisis Comparativo de los Modelos Referidos: En este capítulo hemos analizado siete modelos que nos representan diversas formas de transformación de diagramas. Todas presentan ventajas y desventajas, debido a eso no podemos decir cuál es la mejor. Si evaluamos las distintas características que tiene cada uno obtendremos la siguiente tabla. 59

60 Cuadro Comparativo: MODELOS A B C Especificación Transformaciones CIM PIM PSM CIM-PIM PIM-PSM PSM-IM Modelos de Generación Automática de Código Modelos Reflexivos basados en MDA Procesos V&V en el marco MDA AspectMDA Modelo basado en PIM Conceptos PSM y técnicas de Mapeo de PIM a PSM Modelo orientado a características a. Diagramas UML b. Consistencia c. Trazabilidad : Significa que cumple las características : No cumple las características : Cumplen las características pero no a totalidad, es decir que tiene deficiencia en ese aspecto. Tabla.3 Tabla comparativa de modelos MDA

61 De lo hablado se obtiene lo siguiente: Que las características de un modelo de Vistas en Ing. Aspectos, trabaja con el modelo de UML tiene una definición de trazabilidad, pero no posee una función de consistencia que permite obtener modificaciones si se ha equivocado u omitido algo del diagrama origen, además solo se puede ir de diagrama independiente a la computadora (CIM) a un diagrama independiente del Modelado (PIM). Los diagramas reflexivos solo en diagramas UML, pero al tener poca validez no ha conseguido ninguna característica importante, dependiendo de la herramienta que utilices este método obtendrá los beneficios. El Proceso V&V detectar errores e inconsistencias en las etapas tempranas del desarrollo, pero no puede regresar a solucionar dichos errores una vez transformado el diagrama. El más estable dicho hasta ahora con una metodología orientada a aspectos este método no se basa en ningún diagrama origen, esto hace que no sea preciso enfocarse en una sola transformación Diseño Modelo Computacional para la Transformación de diagramas: Un Análisis del modelo Computacional (Herramienta) proporciona una especificación de trasformaciones de un PIM en un PSM, en este caso vamos a ir desde el diagrama de clases de un modelado PIM a un Código JAVA PSM. Es decir cada tipo de elementos en la PIM se le aplica una regla predeterminada para transformarlo en uno o varios elementos del PSM. Para eso vamos a utilizar el prototipo del primer modelo junto con los conceptos de PSM y mapeo de datos. La solución propuesta comienza con un enfoque de Metamodelo del Diagrama de Clases con los estándares en UML.

62 Arquitectura del modelo de Transformación: Esta formación se basada en 3 partes: - Realizar procesos mediante modelado con técnicas y propiedades de transformaciones MDA para obtener el metamodelo de diagrama de clases comprimido de UML. - Realizar operaciones de Lógica de Predicados, para ordenar y generalizar el proceso de clasificación y demás elementos que se encuentran en el metamodelo generado. - Instanciar sobre lo anterior a los parámetros para poder generar el código requerido en JAVA. Modelado Instancia Operación Ilustración 30 Fig. 30 Arquitectura del Modelado Modelado: Parte donde el proceso usa una transformación de diagrama de clases a un código intermedio por medio de una meta modelado del diagrama de clases que se mostrara a continuación. Instancia: Es la parte se instancia el diagrama de clases, una vez obtenido ese diagrama se utiliza para poder obtener los datos para ver si cada uno de las operaciones cumple con el modelo dado. 62

63 Operación: Utilizar los diversas Reglas de Transformación definidas del Modelo a cada una de las clases y relaciones de las clases que se tienen en el diagrama original. A través de metamodelos del diagrama de clases Definición del Modelo de Transformación: El Modelo de transformación representa una forma de transformación orientada a MDA que dispone de formas de transformaciones específicas de uso de lenguajes formales como la lógica proposicional para obtener ciertos resultados que luego serán utilizados en un enfoque de transformación en un estándar de MDA Descripción del Modelo de Transformación: El Modelo computacional aporta a extraer distintas características del proceso de MDA combinados con trabajos previos de transformación con lógica de predicados proponiendo una forma de modelado de transformación que aporta nuevo estándares de calidad a los usuarios. La generación automática de código ha sido parte de la historia de la programación. El primer compilador significó el inicio de la carrera en la búsqueda de herramientas para posibilitar la programación de computadores, en un nivel de abstracción cada vez más asequible a la interpretación humana. De esta forma, el ensamblador permitió la transición de los unos y ceros del lenguaje de máquina, a la manipulación de registros mediante operaciones identificadas con palabras de fácil recordación para el programador. A su vez, no siendo suficientemente sencillo de utilizar, el ensamblador dio paso a los lenguajes de alto nivel y por ende a herramientas que permitieron la transformación automática de los programas escritos con estos lenguajes en un programa interpretable por la máquina. 63

64 Adicional a los lenguajes de alto nivel, actualmente los equipos de desarrollo cuentan con lenguajes de modelado, los cuales posibilitan la construcción de modelos que, a diferencia del código, se convierten en herramientas de comunicación de fácil interpretación. Estos lenguajes de modelado son serios candidatos a contribuir en la evolución de la generación de código. UML es el lenguaje de modelado de mayor uso en la actualidad. Con UML es posible modelar los aspectos estáticos y dinámicos de un sistema, y en diferentes niveles de detalle, como puede suceder con MDA y sus modelos PIM y PSM. Ya que el PSM tiene una fuerte relación con la plataforma, puede ser un modelo de considerable utilidad en la generación automática de código a partir de un lenguaje de una abstracción superior, como lo es UML, a los lenguajes de alto nivel de la actualidad. Si se pretende generar código fuente a partir de modelos PSM, entonces tanto el PSM como el código, siendo éste el modelo de la fase de implementación, deben representar el sistema bajo estudio, en sus aspectos estáticos y dinámicos. Adicionalmente, las reglas de transformación de modelo a código deben estar definidas en una especificación que no dé lugar a ambigüedades y deben poder ser programables para su uso. El uso de elementos por fuera del estándar, ocasiona que el equipo de desarrollo dependa únicamente de la herramienta que implemente estos elementos y que se deba adaptar a los cambios sintácticos ocasionados en el lenguaje debido a estas adiciones (la migración a otra herramienta podría implicar la repetición de todos los modelos), lo cual puede complicar la comunicación con los miembros del equipo de desarrollo o miembros externos de apoyo al proyecto. Se propondrán reglas de transformación para PSMs compuestos de diagramas de carácter estructural, como el diagrama de clases. 64

65 Las reglas están definidas sobre el metamodelo de UML, con lo cual se dispone de una estructura abstracta, independiente de cualquier modelo de usuario, y que además ofrece vínculos entre los diferentes diagramas utilizados en la generación de código. Estas reglas se especifican en cálculo de predicados de primer orden (Morgan, 1998), lo que las hace fáciles de entender y suficientemente genéricas para ser programadas y útiles en la generación de código en diferentes lenguajes de programación Metamodelo del diagrama de Clases La Figura presenta el metamodelo comprimido del diagrama de clases de UML. Los elementos más comunes de este diagrama son las clases, con sus atributos y operaciones, y las relaciones entre clases, que incluyen la generalización y la asociación, con las variaciones que ésta puede tener como es la composición y la agregación. 65

66 Ilustración 31 Fig. 31 Metamodelo del diagrama de Clases 66

67 Instancia de un Diagrama de Clases Es importante tener en cuenta los atributos (multiplicidad y rol) de las relaciones entre las metaclases, y así se verá más adelante en las reglas de transformación. Por el momento, es necesario considerar que: 1. Toda instancia de la metaclase Class tiene asociado un conjunto de atributos y otro de operaciones, a los cuales se puede acceder utilizando los atributos de Class ownedattributes y ownedoperations respectivamente. 2. Si una clase es la especialización de otra, la relación entre ambas clases se dará mediante una instancia de la metaclase Generalization. Por la navegabilidad de las relaciones, una clase general (véase rol general en la Figura 2) no puede tener acceso a las clases que la especializan pero, en cambio, las clases especializadas pueden tener acceso a la clase general utilizando los atributos generalization y general de la relación entre instancias del metamodelo así: ClaseGeneral = self.generalization.general Donde self es la clase especializada que desea saber cuál es su clase madre. Si hay más de una clase especializada, la metaclase GeneralizationSet permite identificar el conjunto de clases que hacen parte de una misma generalización. 67

68 El metamodelo de UML no establece una relación de generalización directa entre las meta clases Type y Class, pero se presenta acá como tal, dando a entender que el tipo de un atributo o una operación puede ser una clase. La siguiente Figura presenta una instancia del metamodelo del diagrama de clases. La instancia a1 de la metaclase Association representa la relación entre las clases Customer y Order. Nótese que la asociación no se relaciona directamente con las clases sino con propiedades cuyos tipos son las clases de la relación. Estas propiedades, p5 y p6, equivalen a los roles en el diagrama de clases. Ilustración 32 Fig. 32 Instancia de una Clase 68

69 Formalización del Modelo Computacional: Aquí el código general de como proponer este tema. Pseudocódigo del Problema: A continuación se dará un pseudocódigo que permite realizar este proceso de una manera general. Entrada: Diagrama de Clases Salida: Pseudocódigo del Diagrama de Clases Primer Paso: Meta Modelado del problema del diagrama de clases en JAVA Segundo Paso: Traducir el Meta modelado por los distintas Operaciones INICIO Para cada CLASE de diagrama de clases Para cada PARTE DEL METAMODELO DE LA CLASE SI CUMPLE LA REGLA ENTONCES Tercer Paso: Instanciar en el Meta modelado para dar su equivalente en Código JAVA. Fin Fin FIN 69

70 Reglas de transformación: Utilizando las reglas de transformación de los modelos anteriores se han escogido entre dos modelos, reglas que se acomodan para el proceso de transformación, utilizando la notación de una lógica de primer orden. Las reglas de transformación se definen a partir de las clases. Se presenta una única clase, sin asociaciones con otras clases, considerando que las asociaciones son modificadoras de la definición de las clases que vinculan. [2] Así, la relación de herencia modifica la definición de la clase y una relación de asociación con otra clase implica la aparición de un nuevo atributo en alguna o todas las clases relacionadas. [2] [Abstract] ClassName [::GeneralClassName] visibility name : type multiplicity = default visibility name {parameter-list} : return-type Ilustración 33 Fig. 33 Sintaxis de una clase Cada casilla está compuesta por elementos sintácticos. La primera casilla, por ejemplo, indica que el nombre de una clase tiene un identificador llamado ClassName que puede estar acompañado de la palabra Abstract si la clase es abstracta, y/o del símbolo: seguido del nombre de la clase general de la clase actual, en caso de existir una relación de generalización. [2] Las reglas que permiten obtener, para un diagrama de clases dado, la estructura sintáctica presentada en la figura son las siguientes: 70

71 Regla NombreClase: El atributo name de las instancias de la metaclase Class, será el nombre de la clase. c Class c.name Regla esabstracta: Todas las instancias de la metaclase Class cuyo atributo isabstract sea verdadero, serán clases abstractas. c Class (c.isabstract abstract ) Regla ClaseGeneral: Si la clase c es el extremo specific de una relación de generalización g, entonces c tiene una clase general y esta clase es el extremo general de la generalización g. c Class (( g Generalization g.specific = c) g.general) Regla atributos propios de la clase: Los atributos propios de una clase son aquellos que se obtienen por la relación entre las superclases Class y Property. Una propiedad p, instancia de la metaclase Property, es atributo de una clase c si el atributo Class de p es igual a c. La multiplicidad, visibilidad, tipo y nombre de p están dados por sus atributos upper, visibility, type y name respectivamente. Si la multiplicidad es mayor que 1, la clase c tendrá un conjunto de atributos p. Si la multiplicidad es igual a 1, entonces la clase c tendrá un sólo atributo p. [2] c Class p Property p.class = c ( //si la multiplicidad es 1, el tipo permanece sin cambios 71

72 p.upper=1 (p.visibility p.type.name p.name ; ) //si la multiplicidad es mayor que 1, el tipo es un conjunto de elementos de Type p.upper>1 (p. visibility (p.type.name) P p.name ; ) Regla atributos por asociación: La relación entre las clases Pedido y Cliente indica que la clase Remisión tendrá un atributo de tipo Cliente cuyo nombre es cliente, y de igual forma, la clase Cliente tendrá un atributo de tipo Pedido cuyo nombre es pedido. Sin embargo, nótese en la parte inferior de la Figura, que no hay relación entre la clase de un extremo de la asociación y el atributo del otro extremo. La especificación UML, por lo tanto, no considera ni gráficamente, ni mediante restricciones sobre las clases, la relación acá señalada; por ello, se deben obtener los atributos de una clase derivados de una relación, indirectamente navegando sobre las relaciones entre las instancias que forman la relación. [2] 72

73 Ilustración 34 Fig. 34 Relación entre un modelo de usuario y una instancia del metamodelo Utilizando la relación entre las propiedades y la asociación, es posible obtener para cada clase un atributo cuyo tipo es la clase del extremo contrario. Por ejemplo, el atributo cliente de la clase Pedido se obtendrá a partir de la asociación a y su relación con la propiedad p2 llamada ownedend. Teniendo p2 es posible tener su nombre, tipo (relación Type), visibilidad, y demás elementos requeridos para obtener atributos de una clase. Esto se representa de forma general así: c Class ( a Association ( p a. OwnedAttributes).type = c Ù a. ownedattributes =2) ( //si la multiplicidad es 1, el tipo permanece sin cambios 73