Download Desarrollo de un Modelo Computacional basado en Arquitectura

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
Í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
2.7.3.
Diagrama de Estados ................................................................................................. 29
2
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.3. Desarrollo de Casos de Estudio: ...................................................................................... 76
3
DISCUSIÓN DE RESULTADOS. ............................................................................................... 79
CONCLUSIONES Y RECOMENDACIONES: ............................................................................ 80
BIBLIOGRAFÍA ............................................................................................................................... 81
4
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
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
Ilustración 36 Fig. 36 Instancia de Metamodelo del caso ................................................................. 77
6
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
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
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.
9
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.
10
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
11
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.
12
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.
transformaciones.
Los lenguajes de transformación populares y
[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]
13
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:
14

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
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.
16
 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
 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
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
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
 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
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.
22
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,
23
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
Los modelos creados usando UML pertenecen a este nivel M1.
24
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
Fig. N° 11. Entidades de MOF – Capa M3
25
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
M0 – Instancias
Instancias reales del sistema
EJEMPLOS
Cliente con nombre=“David
Aguilar” y DNI=48491673
M1 – modelo
M2 – Metamodelo
M3 – Meta-metamodelo
Entidades del modelo del
Clase “Cliente” con atributos
sistema
“nombre” y “DNI”
Entidades de un lenguaje de
Entidad “UML Class” del
modelado
metamodelo de UML
Entidades para definir lenguajes
Entidad “MOF Class” de MOF
de modelado
Tabla N° 1. Tabla de las Capas de Modelado
Ilustración 12
Fig. 12. Relación entre las Capas de Modelado
26
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
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
FIG. 15. Modelo de un Caso de Uso.
28
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
tiempos. [6]
29
entre objetos con base en
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.
30
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.
 Presenta las clases del sistema con sus relaciones estructurales.
31
 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
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
Fig. 21. Modelo de un Clase en UML.
33
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
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).
Ejemplo:
35
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
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
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
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.
39

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
 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
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.
42
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
Ilustración 27
Fig.27 Arquitectura de ArcStyler
2.9.2. 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
XMI
Java, C#, C++,
Visual Basic
Struct
Java, C#, C++,
Corba, Visual
Basic 6, Visual
Basic.net
XMI
Together Architect
Tabla.2 Arquitectura de OptimalJ
44
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
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
Ilustración 29
Fig.29 Elementos de la plataforma Java
.
47
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:
48
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

Como valor del fenómeno de transformación se presenta siempre
es
ya que la confianza de éxito es muy alta.
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
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.
50
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.
51
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
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.
53
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, PIMPSM 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
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.
55
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.
56
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
transformación.
57
4.1.6. 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
4.1.7. 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
como
(características)
al
CIM
y
al
PIM
un
como
modelo
la
de
arquitectura
características
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.
4.1.8 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
Cuadro Comparativo:
MODELOS
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
A
B
C





















Especificación
CIM PIM PSM
 

 

  
 

 

 




Transformaciones
CIM-PIM
PIM-PSM PSM-IM





















: 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
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.
4.2. 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.
4.2.1. 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
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.
4.2.2. 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.
4.2.3. 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
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
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.
4.2.3.1.
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
Ilustración 31
Fig. 31 Metamodelo del diagrama de Clases
66
4.2.3.2. 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
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
4.2.4.
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
4.2.5. 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
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
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.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
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
p’ .upper=1 ⇒ (p’ .visibilidad 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’ .visibilidad (p’ .Type.name) ℙ p’ .name ‘ ; ’
) ∙ (p’ = ownedAttributes - {p})
En la regla anterior, se selecciona una asociación en la cual al menos
uno de sus dos extremos tiene como tipo la clase actual. Luego, para
obtener la visibilidad, tipo, nombre y valor por defecto del atributo, se
obtiene el otro extremo de la asociación mediante la especificación p‟
= ownedAttributes - {p}, donde ownedAttributes es el conjunto de
propiedades relacionadas con la asociación.
En esta regla no se consideran las clases de asociación, motivo por el
cual se evalúa inicialmente que la asociación tenga dos extremos.
Regla operaciones propias de la clase: Las operaciones de una
clase se obtienen a partir de la relación entre las metaclases Class y
Operation. El tipo de la operación se obtiene de la relación entre las
metaclases Operation y Type; y los parámetros se obtienen de la
relación entre Operation y Parameter.
Una operación o, instancia de la metaclase Operation, es operación
de la clase c si el atributo Class de o es igual a c. La visibilidad, tipo y
nombre de la operación o está dado por sus atributos visibility, type y
name respectivamente.
Un parámetro ownedParameter, instancia de la metaclase Parameter,
es parámetro de la operación o si el atributo Operation de
ownedParameter es igual a o. El tipo y nombre de ownedParameter
están dados por sus atributos type y name respectivamente.
74
Para todas las operaciones o de c, se selecciona la visibilidad, tipo y
nombre de la operación.
Además, se seleccionan todos los
parámetros de la operación o.
∀c∈Class∀o∈Operation ∙ o.class = c ⇒
(
//visibilidad tipo nombre (parámetros)
o.visibility o.type.name o.name ‘ (‘
∀ownedParameter Parameter ∙ ownedParameter. Operation
=o⇒
//tipo parámetro nombreParámetro
ownedparameter.type.name
ownedparameter.name„)
„})‟
75
{„
4.3. Desarrollo de Casos de Estudio:
Vamos a utilizar un caso de Estudio para la implementación de la
presente investigación se tiene lo siguiente:
Base de Datos: Tienda de productos.
Rubro: Comercio
Lenguaje de Programación: JAVA.
La fuente utilizada por el sistema nos proporcionara el anterior
software de gestión de ventas y compras que tiene la empresa junto
a los requerimientos obtenidos de entrevistas y métodos
complementarios de requerimientos.
Inicialmente, se obtiene la estructura del sistema en código, lo
cual se hace utilizando el diagrama de clases.
Paso 1 Modelado:
Para lograr esto, se utiliza un modelado con la sintaxis del
lenguaje, la cual se completa con los resultados de las reglas
de transformación. En el modelado se combinan elementos
propios del lenguaje y los consecuentes de las reglas de
transformación, estos últimos reemplazados por sus
equivalentes en los modelos UML.
Ilustración 35
Fig. 35 Diagrama de clases de ventas del caso
76
El Modelo para las clases Java es:
Public class $c.name {
//atributos
$p.visibility $.type.name $p.name;
//operaciones
$o.visibility $o.type.name $o.name
($ownedParameter.type.name $ownedParameter.name)
{
//método
}
}
Paso 2: Instancia.
La siguiente figura es la representación del diagrama de
clases como instancia del metamodelo del diagrama de
clases, correspondiente a las clases Pedido y Cliente.
Ilustración 36
Fig. 36 Instancia de Metamodelo del caso
77
Paso 3:
Al aplicar las reglas de transformación para el diagrama de
clases sobre la instancia c3 de la metaclase Class, la cual
hace referencia a la clase Pedido, el código generado para
esta clase, de acuerdo a la plantilla y las relaciones
presentadas en la Tabla1 es:
En la Siguiente tabla veremos cada uno de las operaciones
que hay q usar en cada uno de los casos.
$c.Name
$p.visibility $p.type.name
$p.visibility
$p.type.name($ownedParameter.type.nam
e $ownedParameter.type.name)
Regla Nombre Clase
Regla atributos propios de la
clase
Regla atributos por asociación
Regla operaciones propias de la
clase
Tabla 4.Operaciones del Metamodelo
Después de haber obtenido cada uno de las instancias y las
trasformaciones se coloca en la plantilla
Código en Java de La clase Pedido
Public class Pedido {
//atributos
Private String number;
Private Cliente cliente;
//operaciones
Public void agregarDetalle () {
//método
}
}
78
DISCUSIÓN DE RESULTADOS.
A continuación se hará una serie de datos de tiempo a través de pruebas hechas para
ejecución de tiempo a través de aproximaciones de tiempo.
Según el algoritmo:
Entrada: Diagrama de Clases
Salida: Pseudocódigo del Diagrama de Clases
Primer Paso: Meta Modelado del problema del diagrama de clases en
JAVA……… TA
Segundo
Paso:
Traducir
el
Meta
modelado
por
los
distintas
Operaciones………TB
INICIO
Para cada CLASE de diagrama de clases……………TC
Para cada PARTE DEL METAMODELO DE LA CLASE…. TM
SI CUMPLE LA REGLA
ENTONCES
Tercer Paso: Instanciar en el Meta modelado para
dar su equivalente en Código JAVA. T1
Fin
Fin
FIN
Como el tiempo de a y B son indiferentes para el uso de operaciones entre
metamodelos.
O (T)=MAX(A, B, C*M, 1)
O (T)=O(C*M)
79
La solución que proponemos nos da un resultado exponencial, en siguientes
trabajos se obtendrá información de cómo obtener los tiempos del algoritmo
previamente implementado, por el momento el resultado nos da que es un
algoritmo, el tiempo depende de un producto de cuantas clases se tenga
“O(C)” y dentro de cada clase cuantas partes del metamodelo obtenido se
obtendrá a partir de cada clase generada. “O (M)”.
CONCLUSIONES Y RECOMENDACIONES:
6.1. Conclusiones:
El Presente trabajo habla sobre una propuesta computacional que para la
transformación de diagramas de clases a código fuente a través de
modelados MDA.
Se ha tomado lo mejor de 2 algoritmos “Modelos de Generación Automática
de Código” y “Conceptos PSM y técnicas de Mapeo de PIM a PSM” de cada
uno se han analizado enfocado para extraer las técnicas de transformación y
la forma de modelado de MDA respectivamente para así poder crear una
nueva propuesta que se vino desarrollando en el presente trabajo.
Lo complejo del lenguaje unificado de Modelado UML ha hecho que se
presente una propuesta de metamodelo para la simplificación del proceso.
6.2. Recomendaciones:
Se recomienda el uso de restricciones a cada uno de los modelos dados,
estos se utilizan para saber dónde se originó cada uno de las partes del
diagrama, para poder modelar la consistencia solo así se creara una
herramienta confiable y capaz rehacer cada uno de los errores previos de los
diagramas.
6.1. Trabajos futuros:
En los siguientes trabajo futuro, se pretende desarrollar una herramienta
CASE que incluya el algoritmo generado, los metamodelos comprimidos y las
reglas de transformación.
Como se ve solamente al tener el diagrama de clases uno no peude saber
cómo actúa el sistema y que relación se tenga para poder convertir todo eso a
código. Es por eso que se desea también aplicar lo mismos proceso para los
diversos diagramas complementarios del sistema para UML como el diagrama
de estados, el diagrama de procesos, máquinas de estados, etc.
80
BIBLIOGRAFÍA
[1] Jonathan, ECU RED, ARQUITECTURA DIRIGIDA POR MODELOS Universidad
Central de Ecuador (2009),
[2] ANDRÉS MUÑETÓN, CARLOS M. ZAPATA, FERNANDO ARANGO. REGLAS
PARA LA GENERACIÓN AUTOMÁTICA DE CÓDIGO DEFINIDAS SOBRE
METAMODELOS
SIMPLIFICADOS
DE
LOS
DIAGRAMAS
DE
CLASES,
SECUENCIAS Y MÁQUINA DE ESTADOS DE UML 2.0, DYNA, 267-283. Mayo 05
de 2007, Escuela de Sistemas, Facultad de Minas, Universidad Nacional de
Colombia.
[3] Ing. EDUARDO PERALTA SALINAS, MODELADO DE CLASES UML,
http://users.dcc.uchile.cl/~psalinas/uml/modelo.html
[4] JUAN PABLO GARCIA BENITEZ, MARCO PARA LA TRANSFORMACIÓN DE
MODELOS BASADO EN GRAMÁTICAS DE ATRIBUTOS (Madrid 21 de Junio de
2010).
[5] Rodríguez Vicente, J. (Junio de 2004). Ingeniería de Modelos con MDA. Murcia.
[6] UBALDO JOSÉ BONAPARTE, Proyectos UML Diagramas de clases y
aplicaciones JAVA en NetBeans 6.9.1, Editorial de la Universidad Tecnológica
Nacional – edUTecNe, Facultad Regional Tucumán Universidad Tecnológica
Nacional – U.T.N. Argentina
[7] GERMAN SALAZ, EVALUACIÓN Y MEJORA DE LA CALIDAD DE
LOSPROCESOS DE MODELOS MDA -> ADMPROCESOS DE MODELOS MDA.
ADM BASADOS EN REINGENIERÍA,
[8] Pedro
Antonio
Fernández
Sáez,
UN
ANÁLISIS
CRÍTICO
DE
LA
APROXIMACIÓN MODEL-DRIVEN ARCHITECTURE, Facultad de Informática
Universidad Complutense de Madrid. (2009)
81
[9] Luís Eduardo Agudelo González. MARCO DE REFERENCIA PARA LA
EVALUACIÓN DE HERRAMIENTAS
DE TRANSFORMACIÓN DE MODELOS,
UNIVERSIDAD EAFIT MEDELLÍN 2006.
[10]
JORGE
MARTÍNEZ
LADRÓN
DE
GUEVARA.
FUNDAMENTOS
DE
PROGRAMACIÓN EN JAVA. Editorial EME. ISBN 978-84-96285-36-2. Facultad de
Informática. Universidad Complutense de Madrid.
[11]
HUGO ALBERTO KOFMAN. MODELOS Y SIMULACIONES EN LA
ENSEÑANZA DE LA FISICA. Santiago del Estero 2829, Santa Fe, República
Argentina. Facultad de Ingeniería Química de la universidad Nacional del Litoral.
82