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
2
Índice
Lista de Tablas o Cuadros ... 5
Lista de Figuras ... 6
INTRODUCCION ... 7
PLANTEAMIENTO DEL ESTUDIO ... 8
1.1. Realidad Problemática ... 8
1.2. Formulación del Problema ... 9
1.3. Hipótesis ... 9
1.4. Objetivos ... 9
1.4.1. Objetivo General ... 9
1.4.2. Objetivos Específicos ... 10
1.5. Justificación del Problema ... 10
1.6. Limitaciones del Estudio ... 10
MARCO TEÓRICO ... 11
2.1. Modelo ... 11
2.2. Modelo Computacional ... 12
2.3. Arquitectura Orientada a Modelos – MDA ... 12
2.3.1. CIM ... 13
2.3.2. PIM ... 13
2.3.3. PSM ... 14
2.4. Transformación en MDA a Código Fuente: ... 16
2.5. Metámodelos: ... 22
2.6. OMG: ... 22
2.6.1. Capa M0: Instancias ... 23
2.6.2. Capa M1: Modelo del Sistema ... 24
2.6.3. Capa M2: Metamodelo ... 25
2.6.4. Capa M3: Meta-metamodelo ... 25
2.7. Lenguaje Modelado de Proceso – UML: ... 27
2.7.1. Diagrama de Clases ... 28
2.7.2. Diagrama de Casos de Uso ... 28
3 2.7.4. Diagrama de Secuencias ... 29 2.7.5. Diagrama de Actividades ... 30 2.8. Diagrama de Clases: ... 31 2.8.1. Clase ... 33 2.8.2. Relaciones ... 35 2.9. Herramientas de Transformación ... 39
2.9.1. Herramienta OptimalJ de Compuware ... 39
2.9.2. Herramienta ArcStyler ... ¡Error! Marcador no definido. 2.9.3. Otras Herramientas: ... 44 2.10. Java ... 45 MATERIALES Y MÉTODOS ... 48 3.1. Diseño de la Investigación ... 48 3.2. Población y muestra ... 48 3.2.1. Población ... 48 3.2.2. Muestra ... 48 3.3. Variables de estudio ... 50 3.3.1. Variable Dependiente ... 50 3.3.2. Variable Independiente ... 50
3.3.3. Factor de Medición de Mejora del Tiempo ... 50
3.4. Técnicas e Instrumentos ... 50
3.4.1. Técnicas ... 50
3.4.2. Instrumentos ... 51
RESULTADOS ... 52
4.1. Análisis de las Modelos de Transformaciones: ... 52
4.1.8 Análisis Comparativo de los Modelos Referidos: ... 59
4.2. Diseño Modelo Computacional para la Transformación de diagramas: ... 61
4.2.1. Arquitectura del modelo de Transformación: ... 62
4.2.2. Definición del Modelo de Transformación: ... 63
4.2.3. Descripción del Modelo de Transformación: ... 63
4.2.4. Formalización del Modelo Computacional: ... 69
4.2.5. Reglas de transformación: ... 70
4
DISCUSIÓN DE RESULTADOS. ... 79 CONCLUSIONES Y RECOMENDACIONES: ... 80 BIBLIOGRAFÍA ... 81
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
6
Lista de Figuras
Ilustración 1 Fig. N° 1. Pasos en el desarrollo con MDA. ... 12
Ilustración 2 Fig. N° 2. Tecnologías PIM ... 13
Ilustración 3 Fig. N° 3. Ejemplo de PIM ... 14
Ilustración 4 Fig. N° 4. Ejemplo de PSM ... 15
Ilustración 5 Fig. N° 5. Tipos de Modelos según abstracción. ... 15
Ilustración 6 Fig. N° 6. Transformación MDA ... 16
Ilustración 7 Fig. N° 7. Funcionalidad en un entorno de desarrollo MDA ... 21
Ilustración 8 Fig. N° 8. Entidades de MOF – Capa M0... 24
Ilustración 9 Fig. N° 9. Entidades de MOF – Capa M1... 24
Ilustración 10 Fig. N° 10. Entidades de MOF – Capa M2... 25
Ilustración 11 Fig. N° 11. Entidades de MOF – Capa M3 ... 25
Ilustración 12 Fig. 12. Relación entre las Capas de Modelado ... 26
Ilustración 13 Fig. N° 13. Transformaciones de un Modelo UML ... 27
Ilustración 14 FIG. 14. Modelo de una Clase. ... 28
Ilustración 15 FIG. 15. Modelo de un Caso de Uso. ... 28
Ilustración 16 Fig. 16. Modelo de un Diagrama de estado. ... 29
Ilustración 17 Fig. 17. Modelo de un Diagrama de Secuencia. ... 30
Ilustración 18 Fig. 18. Modelo de un Diagrama de Actividades. ... 31
Ilustración 19 Fig. N° 19. Diagrama de Clases ... 32
Ilustración 20 Fig. 20: Representación Estructural de una Clase. ... 33
Ilustración 21 Fig. 21. Modelo de un Clase en UML. ... 33
Ilustración 22 Fig. 22. Modelo de Herencia de Clases... 36
Ilustración 23 Fig. 23. Representación de Agregación de Clases en UML. ... 37
Ilustración 24 Fig. 24. Representación de Asociaciones de Clases en UML. ... 38
Ilustración 25 Fig. 25. Representación de Dependencia de Clases en UML. ... 39
Ilustración 26 Fig.26 ArcStyler ... 41
Ilustración 27 Fig.27 Arquitectura de ArcStyler ... 44
Ilustración 28 Fig.28 Plataformas de JAVA ... 45
Ilustración 29 Fig.29 Elementos de la plataforma Java ... 47
Ilustración 30 Fig. 30 Arquitectura del Modelado ... 62
Ilustración 31 Fig. 31 Metamodelo del diagrama de Clases ... 66
Ilustración 32 Fig. 32 Instancia de una Clase... 68
Ilustración 33 Fig. 33 Sintaxis de una clase ... 70
Ilustración 34 Fig. 34 Relación entre un modelo de usuario y una instancia del metamodelo ... 73
Ilustración 35 Fig. 35 Diagrama de clases de ventas del caso ... 76
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.
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.
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.
1.2. 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.
1.4. Objetivos
1.4.1. 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.
10
1.4.2. 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.
1.5. 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.
1.6. 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.
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.
2.1.
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
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.
2.3. 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.
13
2.3.1. 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]
2.3.2. 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]
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
2.3.3. 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:
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
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.
Ilustración 6
Fig. N° 6. Transformación MDA
Tipos:
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.
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 transformacionesEl 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.
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.
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
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.
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
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.
2.6. 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 1989. 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.
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:
2.6.1. 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,
24
dirección y teléfono) de los clientes David Aguilar y Miguel Martínez. Estas entidades son instancias pertenecientes a la capa M0.
Ilustración 8
Fig. N° 8. Entidades de MOF – Capa M0
2.6.2. Capa M1: Modelo del Sistema
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
25
2.6.3. 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.
2.6.4. 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
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=48491673
M1 – modelo Entidades del modelo del
sistema
Clase “Cliente” con atributos “nombre” y “DNI”
M2 – Metamodelo Entidades de un lenguaje de
modelado
Entidad “UML Class” del metamodelo de UML
M3 – Meta-metamodelo Entidades para definir lenguajes
de modelado
Entidad “MOF Class” de MOF
Tabla N° 1. Tabla de las Capas de Modelado
Ilustración 12
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
28
2.7.1. 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.
2.7.2. 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
29
2.7.3. 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.
2.7.4. 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]
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.
2.7.5. Diagrama de Actividades
En un caso de uso como en el comportamiento de objetos en un sistema, siempre hay actividades que generalmente son secuenciales.
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.
2.8. 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.
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
33
2.8.1. 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:
Ilustración 20
Fig. 20: Representación Estructural de una Clase. En donde:
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
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.
35
2.8.2. 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).
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
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.
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):
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
2.9.1. 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.
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:
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.
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 Una completa herramienta de modelado UML.
o Una Herramienta de ingeniería inversa que transforma ficheros fuente de Java y ficheros JAR y FAR en modelos UML.
o Un explorador genérico basado en MOF que puede usarse para modelos de cualquier metamodelo.
o 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.
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
44
Ilustración 27
Fig.27 Arquitectura de ArcStyler
2.9.2. Otras Herramientas:
Tabla.2 Arquitectura de OptimalJ
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
Struct
Together Architect XMI Java, C#, C++,
Corba, Visual Basic 6, Visual
Basic.net
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
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.
47
Ilustración 29
Fig.29 Elementos de la plataforma Java
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 a Medición sin aplicar a
3.2. Población y muestra
3.2.1. Población
Todas las transformaciones existentes de un diagrama de clases a código fuente Java.
3.2.2. Muestra
Para poder conocer la muestra se una población de más de 100000 ejemplares de clases se utiliza la siguiente formula:
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.
50
3.3. Variables de estudio
3.3.1. Variable Dependiente
Mejorar la transformación de un Diagrama de Clases a Código Fuente Java.
3.3.2. Variable Independiente
Desarrollo de un algoritmo de transformación de diagrama de clases a código fuente Java.
3.3.3. Factor de Medición de Mejora del Tiempo
Disminuir el tiempo de desarrollo, así mismo el grado de complejidad.
3.4. Técnicas e Instrumentos
3.4.1. 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.
51
3.4.2. 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.
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)
53
4.1.1. 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.
54
4.1.2. 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-PSM y PIM-PSM-PIM-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
55
4.1.3. 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.
56
4.1.4. 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.
57
4.1.5. 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
