herramienta case para arquitectura ... - dspace.uclv.edu.cu

i

UNIVERSIDAD CENTRAL “MARTA ABREU” DE LAS VILLAS

FACULTAD DE MATEMÁTICA, FÍSICA Y COMPUTACIÓN

CENTRO DE ESTUDIOS DE INFORMÁTICA

Herramienta CASE para Arquitectura Dirigida por Modelos jMDA.

Módulo CIM-PIM. Versión 1.0.

Tesis de Diploma

Licenciatura en Ciencia de la Computación

Autor: Alejandro Ruiz Batista

Tutores: Dr. Rosendo de Jesús Moreno Rodríguez

Dr. Ramiro Pérez Vázquez

Santa Clara, Cuba, 2015

ii

Dictamen

El que suscribe, Alejandro Ruiz Batista, hago constar que el presente trabajo fue realizado en

la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los

estudios de la especialidad de Licenciatura en Ciencia de la Computación autorizando a que el

mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma

parcial como total y que además no podrá ser presentado en eventos ni publicado sin la

autorización de la Universidad.

______________________________

Firma del autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de

la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo

de esta envergadura referido a la temática señalada.

____________________________ _____________________________

Firma del Tutor Firma del Jefe del Seminario de

Programación

iii

RESUMEN

Dentro de los diversos paradigmas y marcos de trabajo de la ingeniería de software se

encuentra uno que ha ganado fuerza en los últimos años: la Arquitectura Dirigida por

Modelos. Concibe el desarrollo a partir de la construcción y transformación de modelos en

diferentes niveles de abstracción. El paradigma MDA global incluye 4 etapas con 3

transformaciones entre ellas; mundialmente es conocido el trabajo realizado sobre los módulos

PIM (Modelo Independiente de la Plataforma), PSM (Modelo Específico de la Plataforma), y

Código (el programa resultante en sí). Por supuesto las transformaciones entre estas etapas

para generar automáticamente la siguiente se han implementado en variados CASE,

generalmente no comerciales, pero con resultados muy específicos. No obstante el verdadero

paradigma incluye una etapa previa CIM (Modelo Independiente de la Computación) y por

supuesto su transformación automatizada hacia el PIM. Esto no ha sido tan investigado, ni

implementado en herramientas CASE, al menos que se conozcan. Es por supuesto un desafío

científico y tecnológico por lo que esta investigación está dirigida a crear un ambiente lógico

de preguntas y respuestas dirigidas, que pueda ser utilizado por un usuario o analista de

sistemas, orientado a dar como resultado, los Actores, Casos de Uso, Clases, Interfaces, y

Actividades lógicas de un futuro sistema de información, y que posibilite a partir de esta

interfaz, generar automáticamente los diagramas indicados en fases PIM.

Palabras Clave: MDA, OMG, CIM, PIM, PSM, Herramientas CASE

iv

ABSTRACT

Inside the diverse paradigms and marks of work of the software engineering it is one that has

won force in the last years: the Directed Architecture for Models (MDA), MDA conceives the

development starting from the construction and transformation of models in different levels of

abstraction. The paradigm global MDA includes four stages with three transformations among

them; worldwide the work carried out on the modules PIM is known (Platform Independent

Model), PSM (Platform Specific Model), and Code (the resulting program in yes). Ofcourse,

the automatically transformations among these stages to generate the following one have been

implemented in varied CASES, generally not commercial, but with very specific results.

Nevertheless, the true paradigm includes a previous stage CIM (Computer Independent

Model) and of course,the automated transformation toward the PIM. It has not been so

investigated, neither implemented in CASES tools; at least that they know each other. It is, of

course, a scientific and technological challenge for what this investigation is directed to create

a logical atmosphere of questions and directed answers that it can be used by any user or

analyst of systems, guided to give as a result, the Actors, Use Cases, Classes, Interfaces, and

logical Activities of a future system of information, and that it facilitates starting from this

interface, to generate the diagrams indicated in phases PIM automatically.

Keywords: MDA, OMG, CIM, PIM, PSM, Tools CASE

v

TABLA DE CONTENIDOS

INTRODUCCIÓN ....................................................................................................................... 1

CAPÍTULO 1. Fundamentos Teóricos sobre MDA ................................................................. 5

1.1 Arquitectura dirigida por modelos (MDA) ................................................................... 5

1.1.1 Conceptos Básicos de MDA .................................................................................. 8

1.1.2 Transformación de Modelos .................................................................................. 9

1.1.3 Herramientas MDA ............................................................................................. 11

1.1.4 Principales ventajas que brinda MDA ................................................................. 15

1.2 UML ............................................................................................................................ 17

1.2.1 Diagramas que brinda UML ................................................................................ 18

1.2.1.1 Los Diagramas de Estructura .............................................................................. 18

1.2.1.2 Los Diagramas de Comportamiento ................................................................... 20

1.3 Versiones anteriores ......................................................................................................... 22

1.4 Conclusiones parciales del capítulo ................................................................................. 22

CAPÍTULO 2. Análisis y Diseño de la Herramienta .............................................................. 24

2.1 Diagramas del Análisis y el Diseño del módulo CIM-PIM de la herramienta CASE

CIM-PIM v1.0 ....................................................................................................................... 24

2.1.1 Diagrama de Casos de Uso del sistema ............................................................... 24

2.1.1.1 Descripción de los casos de uso mediante diagramas de actividades ................. 25

2.1.1.2 Requisitos funcionales ........................................................................................ 26

2.1.1.3 Requisitos no funcionales ................................................................................... 26

2.1.1.4 Diagrama de Actividades detallado del llenar formulario .................................. 27

2.1.2 Diagrama de Clases de la Herramienta por paquete ............................................ 28

2.2 Conclusiones parciales del capítulo ............................................................................ 32

CAPÍTULO 3. Descripción de la Implementación y puesta en práctica de la herramienta ... 33

3.1 Breve descripción del proceso de codificación ........................................................... 33

3.2 Descripción del uso de la Herramienta ....................................................................... 33

ÍNDICE

vi

3.2.1 Ejecución y pantalla de presentación................................................................... 33

3.2.2 Resultados del formulario .................................................................................... 36

3.2.2.1 Diagrama de casos de uso y actores ................................................................... 36

3.2.2.2 Diagrama de clases ............................................................................................. 40

3.2.2.3 Sistema de Información ...................................................................................... 44

3.2.2.4 Sistema de Bases de Datos ................................................................................. 45

3.2.2.5 Interfaz ................................................................................................................ 45

3.2.2.6 Fragmento de código de interés .......................................................................... 49

3.2.2.7 Código del botón guardar ................................................................................... 50

3.3 Conclusiones parciales del capítulo ............................................................................ 52

CONCLUSIONES ..................................................................................................................... 53

RECOMENDACIONES ........................................................................................................... 54

BIBLIOGRAFÍA ....................................................................................................................... 55

vii

LISTA DE FIGURAS

Figura 1.Esquema de la Arquitectura Dirigida por Modelos (MDA).......................................... 5

Figura 2. Consorcio formado por múltiples empresas punteras de la industria informática ....... 6

Figura 3 Evolución del MDA ..................................................................................................... 6

Figura 4.Etapas en el desarrollo de MDA ................................................................................... 8

Figura 5. Ilustra la forma como MDA propone transformar los modelos para partir de un

problema, y llegar a una solución .............................................................................................. 10

Figura 6.Interoperabilidad en MDA mediante puentes ............................................................. 16

Figura 7. Colección de diagramas que brinda la versión 2.0 de UML ...................................... 17

Figura 8. Diagrama de Casos de Uso y Actores del Sistema .................................................... 24

Figura 9.Diagrama de Actividades para la gestión del formulario ............................................ 25

Figura 10. Diagrama de actividades del llenar formulario ........................................................ 27

Figura 11. Diagrama de clases parte 1 ....................................................................................... 28

Figura 12. Diagrama de clases parte 2 ...................................................................................... 29

Figura 13. Diagrama de clases parte 3 ...................................................................................... 30

Figura 14. Página de Inicio de la herramienta ........................................................................... 34

Figura 15 Ventana del Manual de usuario (Ayuda) ................................................................. 35

Figura 16 Ventana del Acerca de ............................................................................................. 35

Figura 17. Definición de las funcionalidades del diagrama de casos de uso............................. 36

Figura 18. Diagrama de casos de uso y actores en caso que estén definidas las funcionalidades

................................................................................................................................................... 37

Figura 19. Diagrama de casos de uso y actores del sistema resultante a diseñar si se tienen

definidas las funcionalidades ..................................................................................................... 38

Figura 20. Establecimiento de los actores del sistema .............................................................. 38

Figura 21. Diagrama de casos de uso y actores en caso que no se tengan definidas las

funcionalidades .......................................................................................................................... 39

Figura 22Diagrama resultante de casos de uso y actores del sistema a diseñar si no se tenían

definidas las funcionalidades ..................................................................................................... 40

ÍNDICE

viii

Figura 23. Creación de las clases .............................................................................................. 41

Figura 24 Confección de los atributos de una tabla................................................................... 41

Figura 25 Confección de los métodos de una tabla ................................................................... 42

Figura 26. Establece las relaciones entre las tablas ................................................................... 42

Figura 27. Diagrama de clases resultante .................................................................................. 43

Figura 28. Sistema de Información ........................................................................................... 44

Figura 29 Sistemas de la información que brinda la herramienta ............................................. 44

Figura 30 Algunos gestores de bases de datos de los más importantes del mundo ................... 45

Figura 31 Selección del gestor de base de datos que brinda la herramienta ............................. 45

Figura 32 Interfaz java ............................................................................................................... 45

Figura 33 Interfaz para una Página Web ................................................................................... 47

Figura 34 Estilos implícitos dentro de la página web ................................................................ 48

Figura 35 Vista de cómo se va a conformar la aplicación ......................................................... 48

ix

LISTA DE TABLAS

Tabla 1. Comparación de herramientas MDA ........................................................................... 13

1

INTRODUCCIÓN

La ingeniería de software es una disciplina que tiene como objetivo crear técnicas y métodos

para desarrollar y mantener software de calidad. Esta ingeniería trata con áreas muy diversas

de la informática y de las ciencias de la computación, tales como construcción de

compiladores, sistemas operativos, o desarrollos Intranet/Internet, abordando todas las fases

del ciclo de vida del desarrollo de cualquier tipo de sistemas de informacióny aplicables a

infinidad de áreas: negocios, investigación científica, medicina, producción, logística, banca,

control de tráfico, meteorología, derecho, Internet, entre otras.

Con el fin de ayudar a la ingeniería de software se han desarrollado una gran variedad de

aplicaciones informáticas conocidas por herramientas CASE “ComputerAided Software

Engineering” o Ingeniería de Software Asistida por Computadoras cuya función es la de

aumentar la productividad en el desarrollo de software reduciendo los costos en términos de

tiempo y dinero. (Franky, 2010)

Dichas herramientas se construyen para seguir determinados paradigmas y principios y nos

sirven para abarcar todo el ciclo de vida de desarrollo del software brindándonos desde la

facilidad de diseñar un proyecto, cálculo de costo hasta la generación de código fuente en

algún lenguaje de programación, detección de errores, documentación, entre otras. Se espera

que una herramienta CASE genérica, sea del tipo que sea, pueda ser capaz de cumplir con

requisitos como: mejorar la productividad en el desarrollo y mantenimiento del software,

aumentar la calidad del software, reducir el tiempo y costo de desarrollo y mantenimiento de

los sistemas informáticos, mejorar la planificación de un proyecto, aumentar la biblioteca de

conocimiento informático de una empresa ayudando a la búsqueda de soluciones para los

requisitos, automatizar el desarrollo de software, la documentación, la generación de código,

las pruebas de errores y la gestión del proyecto, ayudar a la reutilización del software, a la

portabilidad y estandarización de la documentación, gestión global en todas las fases de

desarrollo de software con una misma herramienta y facilitar el uso de todas las metodologías

propias de la ingeniería de software. (Anacleto, 2006)

INTRODUCCIÓN

2

Como instrumento para abordar la alta complejidad arbitraria en el desarrollo de software

surge el paradigma de Desarrollo Dirigido por Modelos (MDD, por sus siglas en inglés). En la

literatura se reconoce la necesidad de utilizar propuestas basadas en MDD para el desarrollo

de sistemas de alta complejidad, debido a la importancia de aumentar el nivel de abstracción

para mejorar la comprensión, comunicación y análisis por los humanos.(Martínez, 2014 )

La Arquitectura Dirigida por Modelos (MDA, por sus siglas en inglés) es una propuesta

brindada por OMG para dar solución a los cambios de negocio y de tecnología. Dentro de los

enfoques que siguen el MDD,MDA es la de mayor relevancia hasta el momento se desarrolla a

partir de tres niveles de abstracción: modelos independientes de la computación (CIM),

modelos independientes de la plataforma (PIM) y modelos específicos de la plataforma

(PSM). La principal dificultad radica en la marcada diferencia entre los conceptos tratados en

los CIM y los PIM. Los CIM ofrecen una vista desde una perspectiva de los involucrados en el

negocio, mientras que los PIM constituyen una vista de los desarrolladores de software. De ahí

que la mayoría de las propuestas MDA comienzan por los PIM.

Paralelamente y desde hace un poco más de tiempo se vienen desarrollando en el mundo

algunas herramientas de apoyo a la ingeniería de software que se adhieren al paradigma MDA

y que cuentan con licencias de software libre; cabe mencionar el proyecto AndroMDA

fundado en el 2003 y GMF de Eclipse, que pueden servir de base al desarrollo de futuras

aplicaciones con similar fin, sin embargo aún no se pueden considerar herramientas puras

MDA pues no incluyen algunas fases y conversiones, o se apoyan en otras herramientas como

MagicDraw(Páez, 2007) para el diagramado (esta herramienta es propietaria).

Además, la industria de software nacional no cuenta con ninguna herramienta de este tipo que

sea de su autoría netamente; por lo que contar con una aplicación de dichas características, que

pueda irse perfeccionando gradualmente pudiera significar un paso más en el desarrollo de

nuestra industria en el orden tanto económico como tecnológico. A partir de esta problemática

es que en el CEI de la UCLV se propuso un Proyecto de Investigación denominado

“Desarrollo de métodos y tecnologías nacionales de Ingeniería de Software aplicadas en el

modelado y desarrollo de Sistemas de Información”, aprobado como Proyecto nacional dentro

del Programa “Desarrollo de la Industria Cubana de Software” auspiciado por el MINCOM.

INTRODUCCIÓN

3

Dentro de este proyecto la tarea “Desarrollo de Herramienta CASE para Arquitectura Dirigida

por Modelos jMDA” es una de las principales y ya desde varios cursos anteriores se han

desarrollado versiones de los módulos PIM-PSM (3 versiones) y PSM-Código (1 versión). Sin

embargo es la primera vez que se acomete el desarrollo del Módulo CIM-PIM, posiblemente

el de mayor necesidad de investigación y desarrollo.

Este planteamiento nos lleva a definir los siguientes objetivos para esta tesis:

Objetivo general:

Crear una versión inicial del módulo CIM-PIM de la herramienta CASE jMDA de la UCLV

estableciendo previamente una secuencia de pasos a tener en cuenta para el desempeño lógico

de una interfaz de preguntas y respuestas, que constituiría el Modelo Independiente de la

Computación (CIM), que pueda conllevar a la generación automática de los Diagramas de

Casos de Uso y Clases al nivel de Modelo Independiente de Plataforma (PIM).

Objetivos específicos:

1. Documentar el estado del arte actual acerca de la Arquitectura Dirigida por Modelos y en

específico lo correspondiente a creación de un CIM y su transformación a PIM.

2. Modelar con ayuda de UML la herramienta a desarrollar.

3. Implementar una versión inicial del módulo CIM-PIM de la herramienta CASE jMDA de

manera que incluya un ambiente lógico de preguntas y respuestas dirigidas, que pueda ser

utilizado por un usuario o analista de sistemas, orientado a dar como resultado, los

Actores, Casos de Uso, Clases e Interfaces de un futuro sistema de información y que

posibilite a partir de esta interfaz, generar automáticamente los diagramas indicados en

fases PIM.

Preguntas de investigación:

1. ¿Cómo hacer ver el proceso de modelo CIM al PIM mediante un ambiente de

preguntas y respuestas?

2. ¿Podrá la secuencia de preguntas y respuestas propuesta conllevar a la generación

automática de los Diagramas de Casos de Uso, Clases y Actividades del modelo CIM

al modelo PIM?

INTRODUCCIÓN

4

3. ¿En qué medida la versión a implementar del módulo CIM-PIM de la herramienta

Case jMDA satisface la necesidad actual del país en el desarrollo de nuestra industria

en el orden tanto económico como tecnológico?

Justificación de la investigación:

La necesidad de contar con una herramienta profesional de origen nacional que implemente el

paradigma MDA superando las limitantes con que cuentan las existentes en la actualidad, ya

sea el pago de una licencia en el caso de las propietarias o limitantes de orden técnico en el

caso de las de código abierto, que imposibilitan el uso o el desempeño de las mismas en

nuestro país para el desarrollo de sistemas de información y otros software con la

productividad requerida.

Estructura de la tesis:

Capítulo 1.Fundamentos Teóricos sobre MDA: Se realiza un estudio del estado actual de la

bibliografía referente a MDA en cuanto a la realización y transformación de modelos, las

herramientas de apoyo y conceptos fundamentales. Se hace énfasis en el análisis de cada uno

de los temas y su aplicación para resolver la problemática de la investigación.

Capítulo 2.Análisis y Diseño de la Herramienta: En este capítulo se realiza el análisis y

diseño de la herramienta CASE que se propone como solución de este trabajo, en base a varios

diagramas UML correspondientes.

Capítulo 3. Descripción de la Implementación y puesta en práctica de la herramienta: En

este capítulo se resaltan las soluciones algorítmicas y computacionales de esta versión del

módulo CIM-PIM de la herramienta jMDA, la cual permite generar los Diagramas de Casos

de Uso, Clases, en el Modelo Independiente de la Plataforma (PIM) para Java.

5

CAPÍTULO 1. Fundamentos Teóricos sobre MDA

En el capítulo se examinan propuestas relacionadas con la problemática estudiada y se

describen conceptos fundamentales. Se comienza con la descripción de los conceptos básicos

del paradigma de arquitectura dirigida por modelos. Luego se analiza lo referente al diseño

arquitectónico y se comprueba que en el contexto MDA se puede abordar como una

transformación de modelos independientes de la computación (CIM) a modelos

independientes de la plataforma (PIM).

1.1 Arquitectura dirigida por modelos (MDA)

Figura 1.Esquema de la Arquitectura Dirigida por Modelos (MDA)

En la actualidad se le presta mayor atención a la reducción de la complejidad arbitraria en el

desarrollo de software y es así como surge el paradigma de Desarrollo Dirigido por Modelos

(MDD).MDD organiza su ciclo de vida a partir de la construcción y transformación de

modelos (preferiblemente automatizada). Con la automatización y el aumento del nivel de

abstracción se pretende reducir la complejidad arbitraria.(Martínez, 2014 )

“El reto que en la actualidad motiva a la comunidad de investigadores y generadores de

tecnología es proponer esquemas de desarrollo en los cuales los modelos, antes que el código,

son los actores centrales del proceso de desarrollo y donde se proveen mecanismos y


6

herramientas de trabajo integradas que asisten al desarrollador en la construcción y

transformación progresivas de modelos hasta llegar a la solución final. Esta corriente de

trabajo, liderada por OMG, se conoce como MDA”.

Figura 2. Consorcio formado por múltiples empresas punteras de la industria informática

Como parte del enfoque que sigue MDD surge por parte de Object Management Group(OMG,

por sus siglas en inglés) la Arquitectura Dirigida por Modelos (MDA) con gran aceptación

dentro de la comunidad de desarrolladores e investigadores de software. Se destaca que MDA

es una propuesta para el desarrollo de sistemas dirigido por modelos porque provee recursos

para que los modelos dirijan el curso del entendimiento, diseño, construcción, despliegue,

mantenimiento y modificación de los sistemas.(OMG, 2003)El objetivo de MDA es brindar un

marco de trabajo que permita que el esfuerzo y recursos invertidos en el proyecto, se

justifiquen al obtenerse un software de calidad, más flexible, mantenible y portable, generando

un valor adicional a las empresas que la implemente.

Figura 3 Evolución del MDA

MDA nos permite el despliegue de aplicaciones empresariales, diseñadas sin dependencias de

plataforma de despliegue y expresado su diseño mediante el uso de UML y otros estándares,

potencialmente en cualquier plataforma existente, abierta o propietaria, como Servicios Web,

.Net,Corba,J2EE, etc.


7

A grandes rasgos, el proceso de desarrollo de software con MDA se puede dividir en cuatros

modelos diferentes pero relacionados entre ellos:

Modelo Independiente de la Computación (CIM): Se centra en los requerimientos y

representa el nivel más alto del modelo de negocios. Usa un lenguaje para modelar

procesos de negocios que no es UML. Cada proceso de negocio interactúa con

trabajadores humanos y/o componentes de máquina; describe solamente aquellas

interacciones que tienen lugar entre los procesos y las responsabilidades de cada

trabajador, sea o no humano. Un objetivo fundamental de CIM es que cualquiera que

pueda comprender el negocio y sus procesos pueda comprender un CIM, ya que éste

evita todo tipo de conocimiento especializado o de sistemas.

Modelo Independiente de la Plataforma (PIM): Es un modelo del sistema de alto

nivel que representa la estructura, funcionalidad y restricciones del sistema sin

relacionarse con una plataforma determinada. Representa el modelo de procesos de

negocio que va a ser implementado. Comúnmente se usa UML o un derivado de él

para describir el PIM. El PIM modela los procesos y la estructuras del sistema, sin

hacer ninguna referencia a la plataforma en la (o las) que será desplegada la aplicación.

Ignora los sistemas operativos, los lenguajes de programación, el hardware y la

topología de red. Suele ser el punto de entrada de todas las herramientas para MDA e,

incluso, de muchos artículos que hablan de MDA, y dejan de lado CIM.

Modelo Específico de Plataforma (PSM): Es un modelo del sistema con detalles

específicos de la plataforma en la que será implementado. Se genera a partir de un

PIM, así que representa el mismo sistema pero a un nivel distinto de abstracción. Se

puede decir que un PSM es un PIM al que se le añaden detalles específicos para ser

implementado en una plataforma determinada. Los PSMs tienen que lidiar

explícitamente con los sistemas operativos, los lenguajes de programación, las

plataformas (CORBA, .NET, Java EE), etc.

Código: Debido a que cada PSM está muy ligado a una tecnología concreta, la

transformación de cada PSM a código se puede realizar automáticamente.


8

Figura 4.Etapas en el desarrollo de MDA

1.1.1 Conceptos Básicos de MDA

Según OMG algunos de los conceptos básicos a tener en cuenta a la hora de ver el paradigma

de MDA son:(OMG, 2003)

Modelo: No es más que la representación de un modelo en forma de texto y/o dibujo,

donde el texto se puede presentar en lenguaje natural o lenguaje de modelado, por

ejemplo UML.

Metamodelado: Consiste en el análisis, construcción y desarrollo de esquemas, reglas,

restricciones, modelos y teorías que se utilizan para el modelado de clases predefinidas

de problemas.

Dirigido por modelos (ModelDriven): Se dice que es dirigido (o guiado) por modelos

porque provee mecanismos que usan modelos para dirigir el curso del diseño, la

construcción, la implementación, la operación, el mantenimiento y la modificación de

una aplicación. Es decir, el proceso depende de los modelos.

Arquitectura: La arquitectura de un sistema es la especificación de las partes y

conectores del sistema, así como las reglas de interacción entre éstas.

Plataforma: Es un conjunto de subsistemas y tecnologías que proveen un conjunto de

funcionalidades que cualquier aplicación soportada por la plataforma puede utilizar,

sin preocupación sobre los detalles de implementación de la misma.(PINEDA, 2008)

Punto de vista: Un punto de vista en un sistema es una técnica de abstracción que

utiliza un conjunto selecto de conceptos arquitecturales y reglas de estructuración, de


9

manera que se enfoque la atención sólo en un problema particular del sistema. MDA

especifica tres puntos de vista sobre un sistema:(ÁLVARO JIMÉNEZ RIELO, 2009)

1. Punto de vista independiente de la computación: este se enfoca en el

ambiente del sistema y los requerimientos del mismo, es decir, la lógica del

negocio. Los detalles de la estructura y el procesamiento del sistema están

escondidos o no han sido determinados.

2. Punto de vista independiente de la plataforma: se enfoca en la operación

del sistema mientras oculta los detalles específicos para cierta plataforma,

es decir, muestra la parte de la implementación que es idéntica de una

plataforma a otra.

3. Punto de vista específico de una plataforma: combina el punto de vista

independiente de la plataforma con el detalle del uso de una plataforma

específica.

Marco de trabajo: Un marco de trabajo o “framework” puede ser visto

genéricamente como un conjunto de procesos y tecnologías que se utilizan para dar

solución a un problema que resulta complejo. En la informática y en especial en el

desarrollo de software es una estructura conceptual y tecnológica de soporte definido,

compuesta por módulos de software concretos, permitiendo organizar y desarrollar

otros proyectos de software de manera más fácil.

1.1.2 Transformación de Modelos

Desde la perspectiva de MDA, la transformación de modelos se sustenta en la definición de las

reglas para convertir un modelo de un nivel de abstracción a otro basándose en lenguajes y

mecanismos estándares, con el propósito de lograr una solución genérica.

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

principales conceptos :

Transformación: generación automática de un modelo objetivo desde un modelo

fuente, de acuerdo con una definición de transformación.


10

Definición de transformación: conjunto de reglas de transformación que juntas

describen cómo un modelo en un lenguaje fuente puede ser transformado en un

modelo en el lenguaje objetivo.

Regla de transformación: descripción de cómo una o varias construcciones

descritas en un lenguaje fuente, pueden ser transformadas en una o varias

construcciones en un lenguaje objetivo.

La transformación de modelos constituye el proceso central en el cual se basa la estrategia

MDA y con el propósito de crear un estándar de transformación OMG, propone un proceso de

estandarización que favorece la representación de propuestas. (Peña, 2012)

Figura 5. Ilustra la forma como MDA propone transformar los modelos para partir de un problema, y llegar a una

solución

Según las transformaciones pueden efectuarse:(Brown, 2004)

PIM a PIM. Esta transformación es utilizada cuando los modelos son mejorados,

filtrados o especializados durante el ciclo de vida de desarrollo sin necesitar ninguna

información dependiente de la plataforma. Una de las formas de mapeo más obvias

es entre los modelos de análisis y el diseño.

PIM a PSM. Esta transformación es utilizada cuando el PIM está lo suficientemente

refinado para ser proyectado a una infraestructura de ejecución. La proyección está

basada en las características de la plataforma utilizada.


11

PSM a PSM. Esta transformación puede requerirse en la implementación y realización

de componentes. Por ejemplo, el empaquetado de un componente se realiza

seleccionando servicios y configuración. Una vez empaquetado, la entrega del

componente puede ser realizada especificando los datos de inicialización, servidores de

instalación, generación y configuración del contenedor, etc. Esta transformación está

ligada al refinamiento de un modelo PSM a un PSM mejorado y más completo.

PSM a PIM. Esta transformación puede ser requerida para abstraer modelos de

implementaciones existentes en una tecnología específica a una independiente de la

plataforma. Este procedimiento es sin duda uno de los más complicados y difícilmente

puede ser automatizado.

PSM a Código. Esta transformación es la última de la cadena y permite generar el

código específico para una plataforma en particular utilizando un PSM. Una vez

mejorados los PSM o actualizados debido al surgimiento de nuevos requerimientos una

transformación de este tipo es necesaria para regenerar el sistema.

El proceso de generación del código puede llegar a aplicar una serie de reglas de

transformación, los cuales generalmente le permiten al desarrollador la elección entre los

distintos patrones que podrán ser aplicados a los modelos para transformarlos en modelos más

complejos o código.

1.1.3 Herramientas MDA

Debido al auge de MDA se han desarrollado herramientas tanto open source como

comerciales que dan soporte parcial o total al enfoque. El soporte para MDA puede darse en

diversas formas, como en la generación de código a partir de modelos y en las

transformaciones de modelos, donde ambas pueden ser implementadas por distintas

herramientas: herramientas de transformación de PIM a PSM, PSM a código, PIM a código,

ajustables y de definición de transformaciones. Las herramientas analizadas que se destacan

debido a su madurez, uso y mayor soporte al enfoque son: ArcStyler,

OptimalJ,AndroMDA,CodagenArchitectyTogetherArchitect. En la tabla 1 se ilustra una

comparativa entre dichas herramientas. Los tipos de herramientas presentadas son de

transformaciones de modelo a modelo (PIM a PSM) y de modelo a código (PIM a código,

PSM a código).(Páez, 2007, Juan Carlos Herrera 2012)


12

El estudio de estas herramientas permite conocer las características de una herramienta MDA,

sus limitaciones actuales y su aplicabilidad, mostrando un panorama de lo que falta mejorar e

implementar en ellas respecto a las transformaciones, definiciones de sus modelos, forma de

construcción y tecnologías (Ej. UML, XMI, MOF,…) que utilizan.

En la tabla 1 se muestran las características que especifican las herramientas con respecto al

soporte de MDA para identificar en qué medida se cubren. Se presentan las características a

evaluar (renglones) y los nombres de las herramientas (columnas). La intersección de un

renglón con una columna es representada con el símbolo “√” o “*”. A continuación se

describen los renglones y símbolos de la tabla 1.(Edna D. LÓPEZ L 2012)

Renglones:

Entrada. Tipo de entrada que admite para desarrollar la aplicación.

Salida. Tipo de lenguaje o plataforma en la cual genera el código.

Estándares. Estándares en que se basa la herramienta.

Soporte de CIM. Creación de modelos independientes de cómputo.

Soporte PIM. Creación de modelos independientes de plataforma.

Soporte PSM. Creación de modelos de plataforma específica.

CIM a PIM. Soporte a transformaciones del modelo independiente de cómputo

al modelo independiente de plataforma.

PIM a PSM. Soporte a transformaciones del modelo independiente de

plataforma al modelo de plataforma específico.

PSM a IM. Soporte a transformaciones del modelo de plataforma específica al

modelo de implementación (Generación de código).

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.


13

Trazabilidad. Implica conocer el elemento origen a partir del cual se ha

generado cualquier elemento del modelo destino.

Símbolos:

La “√” significa que cumple la característica al 100%.

El “*” significa que cumple la característica pero indirectamente.

Cuando se menciona “indirectamente” significa que implícitamente cumple la característica.

Tabla 1. Comparación de herramientas MDA


14

Los diagramas UML que soportan las herramientas es importante conocerlos, debido a quede

ello se podría deducir cuales son los diagramas más utilizados para el desarrollo de

aplicaciones a través del enfoque MDA. Los diagramas de UML que soportan estas

herramientas son: casos de uso, clases, secuencia, colaboración, actividad, máquina de estado,

componentes, objetos, cronometraje, visión general de interacción, estructura compuesta, así

como el diagrama de distribución. La herramienta OptimalJ utiliza todos, excepto los

diagramas de cronometraje, visión general de interacción y estructura de interacción. Arcstyler

no utiliza el diagrama de objetos, cronometraje, visión general de interacción y estructura de

interacción. TogetherArchitect no utiliza los diagramas de máquina de estados, objetos,

cronometraje, estructura compuesta. CodagenArchitect y AndroMDA utilizan los diagramas

de clases, casos de uso y estados. Además AndroMDA usa el diagrama de secuencias y

CodagenArchitect el diagrama de actividad. Los resultados de la tabla 1 se muestran a

continuación:

La mayoría de las herramientas no implementan en su totalidad la especificación

completa de MDA, estas pueden realizar las transformaciones entre los modelos

PIM-PSM, PSM-Código, pero no de CIM-PIM o simplemente realizan las

transformaciones directas de PIM a código (por ejemplo ArcStyler,

CodagenArchitect).

Ninguna de las herramientas tiene soporte a la definición de todos los modelos de

MDA, solamente soportan a PIM y PSM y TogetherArchitect solamente considera

al CIM indirectamente.

La consistencia algunas herramientas la especifican y otras ligeramente la tratan,

además de que es un punto relevante para el enfoque MDA con respecto a las

transformaciones. Las herramientas que cumplen esta característica son ArcStyler,

OptimalJ, CodagenArchitect, las demás herramientas tienen un soporte ligero a esta

característica.

La trazabilidad es un punto relevante y que sólo algunas herramientas la consideran

con mayor empeño, ya que es significativo para la búsqueda y corrección de


15

errores y es uno de los puntos deseable para las transformaciones. Las herramientas

que especifican esta característica son OptimalJ, ArcStyler.

Debido a que la base del estándar MDA son UML, MOF y XMI, es importante que

las herramientas consideren estos estándares para encontrar uniformidad en la

interpretación del enfoque MDA. Las herramientas analizadas que consideran estos

estándares son ArcStyler y OptimalJ.

1.1.4 Principales ventajas que brinda MDA

Según,(OMG, 2003) MDA al separar, por un lado la especificación de las operaciones y datos

de un sistema, y por el otro, los detalles de la plataforma en la que el sistema será construido

brinda las bases para:

Definir un sistema independiente de la plataforma sobre la que se construye.

Definir plataformas sobre las que construir los sistemas.

Elegir una plataforma particular para el sistema.

Transformar la especificación inicial del sistema a la plataforma elegida.

Los principales objetivos de MDA son mejorar la productividad, la portabilidad, la

interoperabilidad y la reutilización de los sistemas.

Productividad: En MDA el foco del desarrollo recae sobre el PIM. Los PSMs se

generan automáticamente (al menos en gran parte) a partir del PIM. Por supuesto,

alguien tiene que definir las transformaciones exactas, lo cual es una tarea

especializada y difícil. Pero una vez implementada la transformación, puede usarse en

muchos desarrollos. Y lo mismo ocurre con la generación de código a partir de los

PSMs. Este enfoque centrado en el PIM aísla los problemas específicos de cada

plataforma y encaja mucho mejor con las necesidades de los usuarios finales, puesto

que se puede añadir funcionalidad con menos esfuerzo. El trabajo recae sobre las

herramientas de transformación, no sobre el desarrollador.

Portabilidad: En MDA, la portabilidad se logra también enfocando el desarrollo sobre

el PIM. Al ser un modelo independiente de cualquier tecnología, todo lo definido en él

es totalmente portable. Otra vez el peso recae sobre las herramientas de


16

transformación, que realizarán automáticamente el paso del PIM al PSM de la

plataforma deseada.

Interoperabilidad: Los PSMs generados a partir de un mismo PIM normalmente

tendrán relaciones, que es lo que en MDA se llama puentes, Figura 6. Normalmente los

distintos PSMs no podrán comunicarse entre ellos directamente, ya que pueden

pertenecer a distintas tecnologías. Este problema lo soluciona MDA generando no solo

los PSMs, sino también los puentes entre ellos. Como es lógico, estos puentes serán

construidos por las herramientas de transformación, que como se ve son uno de los

pilares de MDA.

Figura 6.Interoperabilidad en MDA mediante puentes

Mantenimiento y Documentación: Como ya se ha dicho, a partir del PIM se generan

los PSMs, y a partir de los PSMs se genera el código. Básicamente, el PIM desempeña

el papel de la documentación de alto nivel que se necesita para cualquier sistema

software. Pero la gran diferencia es que el PIM no se abandona tras la codificación.

Los cambios realizados en el sistema se reflejarán en todos los niveles, mediante la

regeneración de los PSMs y del código. Aun así, seguimos necesitando documentación

adicional que no puede expresarse con el PIM, por ejemplo, para justificar las

elecciones hechas para construir el PIM.

Fases de desarrollo: El proceso de desarrollo con MDA, mantiene las fases del

proceso de desarrollo tradicional, solo sufre cambios en la etapa de análisis, diseño y

codificación, pues estos cambios se van a centrar en el PIM que será la base de todo


17

desarrollo y gracias a nuestra herramienta de transformación, al igual que varias de

estas, estos cambios se trasladaran de inmediato al resto de las fases.

1.2 UML

Lenguaje Unificado de Modelado “UnifiedModelingLanguage” o UML, (por sus siglas en

inglés), constituye el lenguaje de modelado para desarrollar sistemas de software más usado

actualmente; está respaldado por el OMG. UML fue diseñado para incorporar las mejores

prácticas actuales en las técnicas de modelado y de ingeniería de software (Neustadt, 2002). Es

un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema, ofreciendo

un estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales

tales como procesos de negocio y funciones del sistema, y aspectos concretos como

expresiones de lenguajes de programación, esquemas de bases de datos y componentes

reutilizables.

Figura 7. Colección de diagramas que brinda la versión 2.0 de UML


18

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para

describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en

el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está

descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar

soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional

o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje

Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización

en un requerimiento. Mientras que, programación estructurada, es una forma de programar

como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene

siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes

orientados a objetos.(Kuznetsov, 2006)

UML ha madurado considerablemente desde UML 1.1. Varias revisiones menores (UML 1.3,

1.4 y 1.5) han corregido defectos y errores de la primera versión de UML. A estas le ha

seguido la revisión mayor UML 2.0 que fue adoptada por el OMG en 2005.

Aunque UML 2.1 nunca fue lanzado como una especificación formal, las versiones 2.1.1 y

2.1.2, aparecieron en 2007, seguidas por UML 2.2 en febrero de 2009. UML 2.3 fue lanzado

oficialmente en mayo de 2010. UML 2.4.1 fue lanzado oficialmente en agosto de 2011. UML

2.5 fue lanzado en octubre de 2012 como una versión "En proceso" y todavía tiene que ser

formalmente liberada.

1.2.1 Diagramas que brinda UML

UML cuenta con varios tipos de diagramas divididos en dos grandes grupos de acuerdo con

sus funcionalidades.

1.2.1.1 Los Diagramas de Estructura

Estos diagramas hacen énfasis en los elementos que deben existir en el sistema de modelado

mostrando como están relacionados los mismos:


19

Diagrama de clases: Es el diagrama más utilizado en el modelado de sistemas

orientados a objetos. Se usa para modelar el vocabulario de un sistema , modelar

colaboraciones simples, y modelar un esquema lógico de base de datos. Se

utiliza para mostrar clases, interfaces, colaboraciones y las relaciones entre todas

ellas. Las relaciones entre clases pueden ser de dependencia,generalizacióno

herencia, y de asociación, las relaciones de asociación deben tener una multiplicidad

para señalar cuantos objetos pueden conectarse a través de una instancia a una

asociación. Hay dos tipos de asociaciones especiales: agregación y composición.

Diagrama de componentes: Debido a que los diagramas de componentes son más

parecidos a los diagramas de casos de usos, éstos son utilizados para modelar la

vista estática y dinámica de un sistema . Muestra la organización y las

dependencias entre un conjunto de componentes. No es necesario que un diagrama

incluya todos los componentes del sistema, normalmente se realizan por partes. Cada

diagrama describe un apartado del sistema.

Diagrama de objetos: Se utilizan para mostrar estructuras de datos y las

interacciones que existen entre objetos en tiempo de ejecución.

Diagrama de estructura compuesta (Introducido a partir de UML 2.0): Muestra la

estructura interna de una clase y las colaboraciones que esta estructura hace

posibles. Esto puede incluir partes internas, puertas mediante las cuales, las partes

interactúan con cada una de las otras o mediante las cuales, instancias de la clase

interactúan con las partes y con el mundo exterior, y conectores entre partes o puertas.

Una estructura compuesta es un conjunto de elementos interconectados que colaboran

en tiempo de ejecución para lograr algún propósito. Cada elemento tiene algún rol

definido en la colaboración. Las entidades de estructura compuesta claves identificadas

en la especificación UML 2.0 son:

Clasificadores estructurados

Partes

Puertas

Conectores

Colaboraciones.


20

Diagrama de despliegue: Se utiliza para modelar la disposición física de los

artefactos software en nodos (usualmente plataforma de hardware). Los elementos

usados por este tipo de diagrama son:

Nodos (representados como un prisma)

Componentes(representados como una caja rectangular con dos

protuberancias del lado izquierdo)

Asociaciones

Diagrama de Artefactos: Muestra los constituyentes físicos de un sistema en la

computadora. Incluyen archivos, bases de datos y colecciones físicas similares a

los bits. Se usan generalmente en conjunción con diagramas de despliegue. Presentan

además las clases y componentes que ellos implementan.

Diagrama de paquetes: Muestra cómo un sistema está dividido en agrupaciones

lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente

un paquete está pensado como un directorio los diagramas de paquetes suministran una

descomposición de la jerarquía lógica de un sistema. Los Paquetes están

normalmente organizados para maximizar la coherencia interna dentro de cada paquete

y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras

sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede

asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el

orden de desarrollo requerido.

1.2.1.2 Los Diagramas de Comportamiento

Son un grupo de diagramas utilizados para mostrar como es el comportamiento llevado a cabo

por el sistema que se modela, las partes del mismo y otros agentes externos.

Diagrama de casos de uso: constituye uno de los diagramas UML utilizado para la

modelación de los aspectos dinámicos de un sistema. Es muy importante en el

modelado del comportamiento de un sistema, subsistema o una clase, mediante sus

componentes que son: casos de uso, actoresy sus relaciones. Esto implica, la

mayoría de las veces, modelar el contexto del sistema, subsistema o clase, o el

modelado de los requisitos de comportamiento de esos elementos.


21

Diagrama de actividades: Muestra el flujo de control entre actividades, por lo que

constituye fundamentalmente un diagrama de flujo, que además puede mostrar

concurrencias y ramas de control . Es utilizado para modelar los aspectos

dinámicos de un sistema, más exactamente, los pasos secuenciales, incluida la

concurrencia, de un proceso computacional. Los diagramas de actividades pueden

utilizarse para visualizar, especificar, construir y documentar la dinámica de una

sociedad de objetos, o también, para modelar el flujo de control de una operación.

Diagrama de estados: Un diagrama de estados muestra una máquina de estado, o

sea, un comportamiento que especifica las secuencias de estados por las que pasa un

objeto durante su vida, en respuesta a eventos, junto con sus respuestas a esos eventos.

Estos diagramas son junto con los diagramas de actividades útiles para modelar la vida

de un objeto, pero a diferencia de estos que muestran el flujo de control entre

actividades ellos lo muestran entre estados. Pueden estar asociados a las clases, casos

de uso o a sistemas completos para visualizar, especificar, construir y documentar la

dinámica de un objeto individual.

Diagramas de Interacción: Los diagramas de interacción son un subgrupo dentro de

los diagramas de comportamiento especializados en el flujo de control y en el flujo

de datos entre los elementos del sistema modelado.

o Diagrama de secuencia: Utilizado para modelar interacciones entre un conjunto

de objetos de una aplicación a través del tiempo. Se modela para cada método de

una clase y contiene detalles de la implementación del escenario que no es más

que una parte del sistema (relación entre los objetos más interesantes) que se

quiere resaltar, así como, de los elementos que lo componen, o sea, objetos y

clases, y de los mensajes que son intercambiados entre los objetos, ordenándolos

temporalmente.

o Diagrama de comunicación (que es una versión simplificada del Diagrama de

colaboración en UML 1.x)

o Diagrama de tiempos (Introducido a partir de UML 2.0)

o Diagrama global de interacciones o Diagrama de vista de interacción

(Introducido a partir de UML 2.0)


22

1.3Versiones anteriores

En la Universidad Central “Marta Abreu” de Las Villas en el año 2010 se ha desarrollado una

herramienta MDA apoyada en UML denominada jMDA, como tesis de opción al título de

Licenciado en Ciencias de la Computación. De dicho software, se han realizado varias

versiones en las primeras versiones, se ha desarrollado por partes, cubriéndose solo 3 veces la

versión de transformación PIM-PSM, aún inconclusa pues solo brinda cobertura para algunos

diagramas UML (Casos de Uso, Clases, Actividades, Interacción, Estado, etc.), finalmente con

una fase de conversión al Modelo Específico de la Plataforma incipiente; además se desarrolló

una versión que incluye la transformación del PSM al código fuente y brinda soporte

solamente para la plataforma java. Nunca se ha realizado nada relacionado con el primer

módulo: la creación de un CIM y su transformación a un PIM inicial, que es fundamental en el

desarrollo del software ya que sienta las bases del mismo. Este módulo es de gran importancia

ya que una vez generado el módulo PIM inicial se tiene una idea bien conformada de cómo va

a quedar el software.

Como se puede apreciar es de gran importancia la creación de una herramienta capaz de

generar de forma automática el PSM inicial, es decir una versión inicial CIM-PIM que pueda

conllevar a la generación automática de los Diagramas de Casos de Uso, Clases y Actividades

al nivel de Modelo Independiente de Plataforma (PIM) a partir del Modelo Independiente de la

Computación (CIM).

1.4Conclusiones parciales del capítulo

El análisis de la literatura permitió conocer el estado actual de MDA, se pudo constatar que:

La adopción de propuestas basadas en MDA en el desarrollo de software causan un

impacto positivo en la productividad, calidad de los sistemas desarrollados, tiempo y

costo de los proyectos de desarrollo.

El diseño arquitectónico en el contexto MDA se corresponde con la transformación de

CIM a PIM. El análisis de las propuestas que abordan esta transformación evidenció

que es un tema que aún está en discusión y que todavía persisten insuficiencias

respecto a:


23

La utilización de lenguajes formales que permitan describir y validar

los CIM antes de ser transformados.

La validación de los modelos generados.

El chequeo de la consistencia entre todos los CIM y PIM.

La falta de herramientas que soporten las propuestas.

24

CAPÍTULO 2. Análisis y Diseño de la Herramienta

En este capítulo se aborda los detalles de la implementación de la versión 1.0 de la

herramienta CASE CIM-PIM. El proceso propuesto como solución a la problemática

planteada en la introducción de esta tesis se expondrá mediante el uso del Lenguaje Unificado

de Modelado (UML) para mostrar los aspectos funcionales, estructurales y de

comportamiento.

2.1 Diagramas del Análisis y el Diseño del módulo CIM-PIM de la herramienta CASE

CIM-PIM v1.0

2.1.1 Diagrama de Casos de Uso del sistema

A continuación se muestra el diagrama de casos de uso del sistema para la construcción de la

herramienta CASE CIM-PIM:

Figura 8. Diagrama de Casos de Uso y Actores del Sistema

Como se ilustra en la figura 8que corresponde con el diagrama de casos de uso y actores del

sistema se tiene un analista que es el que va a interactuar con el software, como se aprecia es

capaz de gestionar un formulario es decir adicionar, eliminar y actualizar. Además es capaz de

crear los formularios que no son más que un ambiente lógico de pregustas y respuestas a llenar

por el mismo, para la obtención de diagramas de casos de uso y clases que ayuden a solucionar

un problema dado.

CAPÍTULO 2.Análisis y diseño de la herramienta

25

2.1.1.1 Descripción de los casos de uso mediante diagramas de actividades

Figura 9.Diagrama de Actividades para la gestión del formulario

Como se ilustra en la figura 9el diagrama de actividades del caso de uso gestión del formulario

donde lo primero es crear un formulario nuevo y posteriormente se pasa a su llenado, pero

durante el proceso puede el analista si lo desea salir del formulario y terminar la aplicación o

puede volver a crear otro formulario nuevo. Una vez llenado puede ocurrir tres situaciones,

que el analista haya cometido un error a lo largo del proceso y quiera revisar el formulario

para corregir el o los errores, qué desee salir y crear uno nuevo y salir por completo del

sistema. Una vez llenado el formulario y limpio de errores se pasa a una pestaña dentro de la

aplicación que le permite ver los resultados obtenidos como son los diagramas de casos de uso


26

y de clases , el gestor de bases de datos a utilizar , el tipo de sistema de información y la

interfaz asociado a una problemática dada.

2.1.1.2 Requisitos funcionales

1. Permitir la generación automatizada de un Modelo Independiente de la Plataforma

(PIM) a partir del Modelo Independiente de Computación (CIM), que contenga los

diagramas casos de uso y clases, correspondiente con los detalles propios de la

plataforma Java.

2. Permitir salvar la información que el usuario determina a través de sus respuestas de

una manera que posibilite su posterior uso o modificación.

2.1.1.3 Requisitos no funcionales

Requerimiento del Hardware: La aplicación necesita para su ejecución una terminal

con al menos 100MB de memoria RAM disponibles para su uso eficiente. Con

microprocesador de la familia Pentium IV o superior. No necesita tarjeta de video

extra.

Requerimiento del Software: Al ser una aplicación Java desarrollada utilizando la

tecnología openJDK puede ser ejecutada sobre cualquier sistema operativo (Windows,

GNU/Linux, Solaris, entre otros) que tenga instalada una versión del JRE compatible

con IcedTea6 versión 1.9.2.

Portabilidad: Presenta alta portabilidad al ser programado en Java, no es necesario

reescribir el código para portarse a otra plataforma, se puede reutilizar en su totalidad.

Costo: Por ser un trabajo desarrollado como parte de un ejercicio académico (Tesis de

Diploma), no tiene un costo directo establecido.


27

2.1.1.4 Diagrama de Actividades detallado del llenar formulario

Figura 10. Diagrama de actividades del llenar formulario

Como se ilustra en la figura 10a la hora del llenado del formulario las preguntas están

agrupadas en pequeños grupos para poder guiar al analista por la herramienta, de tal forma que

no se queden campos vacíos a la hora de llenar el formulario, logrando de esta manera

disminuir en gran medida los errores en el proceso de llenado que es bastante largo y

complejo. Primeramente se pregunta qué tipo de sistema es el que el analista quiere, si uno

tradicional de gestión de datos (Sistema común de bases de datos, con sus tablas y relaciones)

o uno para la toma de decisiones que en este caso lasExtracción, Transformación y Carga

(ETL) pasarían a jugar el rol principal dentro del sistema, ya que ahora estaríamos hablado de

un almacén de datos. Posteriormente se pasa a definir los casos de uso a implementar por el

analista donde se tienen dos opciones, la primera de ellas es para el caso que el analista ya

tenga definidas las funcionalidades que va a tener el nuevo sistema y la segunda para cuando

se tiene definidos los actores pero no las funcionalidades. Después se define con que gestor de

base de datos se va a trabajar, si con MSQL Server o PostgresSQLServer seguidamente se

crean las tablas o entidades en forma de clases con las operaciones y atributos propias de cada

una de ellas. Por último se pregunta al usuario que tipo de interfaz desea para visualizar la


28

nueva aplicación, si una interfaz de formularios estándar programada en java mediante el IDE

NetBeans 8.0 o una página web.

2.1.2 Diagrama de Clases de la Herramienta por paquete

Figura 11. Diagrama de clases parte 1


29



30


El diagrama de clase expuesto en las figuras 11,12 y 13 muestran todas las clases que contiene

el proyecto y sus relaciones. A continuación se explicará los atributos y operaciones más

importantes de cada clase:

El paquete Ayuda tiene una sola clase cuyo nombre es Ayuda, esta clase se creó con

el objetivo de que el usuario tenga un manual, por lo que no tiene atributos, solo

tiene un método público llamado +textoPagina (intpag), al cual se le pasa un entero


31

que es la página actual y su objetivo es poder escribir el contenido del manual de

usuario de forma que tenga un título y un contenido.

El paquete ClasesTree tiene una sola clase que se nombra ProyectTreeNode, esta

se creó con el objetivo de poder usar el trabajo con árbol, por lo que la misma hereda

de la clase DefaultMutableTreeNode para poder establecer una jerarquía en la parte

izquierda de la aplicación donde va el nombre del proyecto. Posee un atributo llamado

proyectName que no es más que el nombre que recibe y las operaciones de Set () y

Get () de dicho atributo, además de un constructor llamado de la misma forma que la

clase.

El paquete ClasesAtrib tiene dos clases la primera de ellas es la clase Método y la

segunda la clase Atributo ambas se crearon con el objetivo de poder visualizar las

clases con los atributos y métodos lo más completos posible. La clase Método tiene

una serie de atributos como el nombre del método, visibilidad, valor de retorno y lista

de parámetros, la visibilidad es el rango de alcance tanto de los atributos como de los

métodos en el programa, es decir si es privado, público o protegido; posee una serie de

operaciones entre las que se encuentra la reprogramación del toString () de gran

ayuda para poder visualizar de forma completa los métodos y tiene un arreglo de

atributos para la hora del pase de parámetro. La clase Atributos tiene como atributos

el nombre, la visibilidad y el tipo de datos; las operaciones más importante son la

reprogramación del toString () para poder visualizar en su totalidad los atributos.

El paquete AplicacionPrincipal tiene dos clases y es el paquete de más importancia

en cuanto a clases ya que esta la clase Principal que es donde se ubica los

componentes visuales y gran parte de la programación, además de controlar todas las

demás clases anteriormente descritas. Consta de una gran variedad de atributos como

son listas, matrices, arreglos, componentes entre otras, en sus operaciones se

encuentra todo el peso del software ya que su esqueleto es la aplicación en sí. La otra

clase que forma parte del paquete se llama Inicio, esta clase es la encargada de la

presentación del software ya que al inicial la aplicación se muestra una foto de la

herramienta y una barra de estado que muestra el porciento que demora iniciando la


32

aplicación, para ello se apoya de tres métodos y dos clases una de ellas controla la

barra de progreso y la otra el tiempo en iniciar la aplicación.

El paquete Utiles está conformado por una sola clase llamada Reporte que es de

gran importancia en la aplicación ya que garantiza que se puedan guardar los

resultados en Excel, para lograr dicho objetivo esta clase está conformada por los

siguientes métodos crearLibro(),guardarHoja(JTabletable, StringnombreTab,

String[] texto), guardaHoja(String[][] table, StringnombreTab),

guardar(),crear(File file).

2.2 Conclusiones parciales del capítulo

En este capítulo se pudo apreciar lo relativo al análisis y diseño del software propuesto. Se

determinó al actor del sistema y los posibles casos de uso que ejecuta el mismo, que

constituyen una representación de los requisitos funcionales, así también se definieron los

requisitos no funcionales y se utilizaron diagramas de actividades para describir a los casos

de uso. Por último se modeló un diagrama de clases que representa el diseño estructural

del software.

33

CAPÍTULO 3. Descripción de la Implementación y puesta en práctica de

la herramienta

En este capítulo se desarrolla la descripción de la solución propuesta donde se resaltan las

soluciones algorítmicas y computacionales de la primera versión de la herramienta CASE

CIM-PIM.

3.1 Breve descripción del proceso de codificación

La primera versión de la herramienta CASE CIM-PIM desarrollada en la presente tesis se

desarrolló usando el lenguaje de programación Java, seleccionado por las facilidades que

brinda al estar respaldado por licencias que permiten su libre distribución, modificación y uso.

Para la codificación se utilizó librerías contenidas en el JDK versión 7 tales como:

swing y awt: Para manipular todos los componentes visuales de la aplicación.

útil: Para trabajar con estructuras de datos necesarias para almacenar y procesar la

información y meta información de los diagramas desarrollados.

io: Para trabajar con fichero texto.

Se usó el entorno integrado de desarrollo NetBeans IDE 8.0 por las facilidades que brinda para

refactorización y chequeo semántico del código.

3.2 Descripción del uso de la Herramienta

3.2.1 Ejecución y pantalla de presentación

La herramienta esta compilada y empaquetada en un .jar. Para su ejecución es necesario tener

instalada en el sistema operativo una Máquina virtual de Java que no es más que una

máquina virtual de proceso nativo, es decir, ejecutable en una plataforma específica, capaz de

interpretar y ejecutar instrucciones expresadas en un código binario especial (el bycode Java).

Esto se logra instalando el JDK en la máquina que desea correr la herramienta, tener en cuenta

CAPÍTULO 3.Descripción de la implementación y

puesta en práctica de la herramienta

34

que una versión vieja del JDK podría traer deficiencias a la hora de interpretar y ejecutar

código por lo que se recomienda un aversión de JDK 7 o mayor.

Una vez instalada la máquina virtual para hacer uso de la aplicación bastara con mandar a

ejecutar con la acción del mouse sobre el fichero .jar.

Figura 14. Página de Inicio de la herramienta

La aplicación cuenta con:

Un menú que contiene dos botones

Archivo -> Nuevo Proyecto, Guardar Proyecto y Cerrar

Ayuda -> Manual de usuario y Acerca de



35

Figura 15 Ventana del Manual de usuario (Ayuda)

Figura 16 Ventana del Acerca de



36

Un árbol en la esquina izquierda:

El árbol está compuesto por dos niveles, muestra en su primer nivel del

nombre del proyecto y en su segundo nivel del formulario a llenar por el

analista.

Un panel en la esquina derecha donde se muestra el formulario a llenar por el analista

y al iniciar la herramienta la pantalla de bienvenida.

3.2.2 Resultados del formulario

Como resultado inicial el formulario dado una serie de preguntas y respuestas la aplicación es

capaz de generar el diagrama de casos de uso y actores del sistema, el diagrama de clases,

como diagramas principales, además también nos brinda información de la base de datos con

la que se va trabajar, del sistema de la información que se desea crear y de la interfaz en la que

el usuario vera los resultados.

3.2.2.1 Diagrama de casos de uso y actores

El diagrama de casos de uso y actores del sistema en la aplicación presenta dos vías de

desarrollo la primera de ellas es:

Si el usuario tiene definido las funcionalidades del Sistema de la Información a crear la

aplicación le pide mediante un cuadro de texto la cantidad de funcionalidades o casos

de uso a definir, una vez definidas dichas funcionalidades se generan los actores del

sistema y se muestra los resultados en forma de tabla.

Figura 17. Definición de las funcionalidades del diagrama de casos de uso

Como se ilustra en la figura 17se muestra un cuadro de texto donde se le asigna la cantidad de

funcionalidades que va a tener el sistema. Si se le asigna un valor que no es válido (cadena,



37

símbolos) el programa lanza un error como este “Debe introducir un valor numérico” y

de esta forma se controla que el valor pasado sea un valor valido.

Figura 18. Diagrama de casos de uso y actores en caso que estén definidas las funcionalidades

Posteriormente se escriben los casos de uso o funcionalidades del sistema y una descripción de

cada uno de los casos. Una vez definidos dichos caso se le asignan los actores del sistema

como se aprecia en la figura 18.



38

Figura 19. Diagrama de casos de uso y actores del sistema resultante a diseñar si se tienen definidas las

funcionalidades

Como se ilustra en la figura 19 en la parte izquierda de la tabla van los actores que se

definieron anteriormente y en la derecha las funcionalidades de cada actor, en caso que un

actor realice más de una funcionalidad dentro del sistema se crea para cada funcionalidad una

fila, como sucede en este caso.

Si no están definidas las funcionalidades del sistema lo primero que aparece es un

cuadro de texto para que el usuario ingrese la cantidad de actores del sistema para

luego poder definir las funcionalidades que va a tener dicho actor o actores en el

sistema. Una vez ingresado los actores se le da al botón generar para poder definir las

funcionalidades del sistema y se muestra el resultado en forma de tabla.

Figura 20. Establecimiento de los actores del sistema

Como se ilustra en la figura 20 se muestra un cuadro de texto donde se le asigna la cantidad de

actores que va a tener el sistema. Si se le asigna un valor que no es válido (cadena, símbolos)

el programa lanza un error como este “Debe introducir un valor numérico” y de esta

forma se controla que el valor pasado sea un valor valido.



39

Figura 21. Diagrama de casos de uso y actores en caso que no se tengan definidas las funcionalidades

Posteriormente se escriben los actores del sistema. Una vez definidos dichos actores se le

asignan las funcionalidades como ilustra la figura 21.



40

Figura 22Diagrama resultante de casos de uso y actores del sistema a diseñar si no se tenían definidas las

funcionalidades

Como se ilustra en la figura 22 en la parte izquierda de la tabla van los actores que se

definieron anteriormente y en la derecha las funcionalidades de cada actor separadas por

coma, en caso que se agregué un actor al sistema simplemente se agrega una nueva fila a dicha

tabla.

3.2.2.2 Diagrama de clases

Para la confesión del diagrama de clases primeramente se le pasa al software la cantidad de

clases a implantar y se oprime el botón ok donde aparece un cuadro para crear la(o las) clases.

Una vez creado se pasa a establecer las relaciones que pueden ser de asociación, composición,

agregación, generalización, dependencia y realización.



41

Figura 23. Creación de las clases

Como se aprecia en la figura 23 se ve cómo es que se crea una tabla en la herramienta, como

se puede apreciar la tabla ,tiene un nombre y tres botones principales el primero de ellos

permite adicionar atributos a la tabla de forma tal que se puede ver tanto la visibilidad, el

nombre y el tipo de dato que posee dicho atributo, el segundo permite adicionar las

operaciones a la tabla, se puede ver la visibilidad, el tipo de dato que devuelve el método y en

el caso que tenga parámetros se aprecia el nombre y el tipo de dato de dichos parámetros.

Figura 24 Confección de los atributos de una tabla

Esta pantalla sale al oprimir el botón “Adicionar Atributos” de la tabla ,como se puede

apreciar en la figura 24 a cada atributo se le pone un nombre, un tipo que no es más que el tipo

de dato del atributo y un modificador que es como se aprecia la visibilidad del mismo.



42

Figura 25 Confección de los métodos de una tabla

Como se aprecia en la figura 25 esta pantalla sale al oprimir el botón “Adicionar Método”

de la tabla. Un método tiene un nombre, un tipo que para el caso de los métodos es diferentes

al de los atributos ya que el tipo significa lo que va a devolver dicho método, un modificado

que funciona igual que el del atributo y por último se le incorporo una tabla para el pase de

parámetro donde es necesario pasarle a cada parámetro el nombre y el tipo.

Figura 26. Establece las relaciones entre las tablas



43

Como se muestra en la figura 26 se tiene en la parte izquierda las tablas creadas por el usuario

y en la parte derecha se tiene una tabla donde se van a establecer las relacione entre tablas,

destacar que en dicha tabla la columna “Relación” es un combo box que ya tiene las

relaciones programadas.

Figura 27. Diagrama de clases resultante

Como resultado del diagrama de clase se tiene en la parte izquierda las clases y en derecha la

tabla con las relaciones entre ellas.



44

3.2.2.3 Sistema de Información

Figura 28. Sistema de Información

La herramienta presenta una interfaz gráfica que le permite al usuario determinar de los

sistemas de información propuestos cual es el más adecuado para dar solución a la

problemática del mismo. La misma consta de dos sistemas de información, el primero de ellos

es el Sistema tradicional de gestión de datoseste no es más que las bases de datos

tradicional y sus relaciones entre tablas el otro es el Sistema para la toma de decisiones

este último se centra en los almacenes de datos y las ETL.

Figura 29 Sistemas de la información que brinda la herramienta



45

3.2.2.4 Sistema de Bases de Datos

Figura 30 Algunos gestores de bases de datos de los más importantes del mundo

La herramienta brinda de los diversos gestores de bases de datos que se aprecian en la figura

30que son de los más importantes a nivel mundial solo dos de ellos, MSQL Server y

PostgresSQL Server con el objetivo de poder establecer conexiones y manipulación de datos

entre la aplicación y la base de datos.

Figura 31 Selección del gestor de base de datos que brinda la herramienta

3.2.2.5 Interfaz

Figura 32 Interfaz java



46

De las tantas interfaz que existen, la herramienta aborda dos de ellas una es la “Páginas

Web” y la otra es “Formularios estándar” estas ultima en el ambiente grafico del lenguaje

de programación java mediante el IDE NetBeans 8.0.A continuación se presentan imágenes de

como la herramienta genera dichos ambientes.

Figura 31 Interfaz de Formulario Estándar en java

En esta interfaz de “Formulario Estándar” en java lo primero que se necesita saber es el

nombre que le desea poner a la aplicación, posteriormente como queda conformado el menú

de la aplicación y por último los colores de los componentes y del texto a utilizar.



47

Figura 33 Interfaz para una Página Web

En la interfaz para “Página Web” al igual que en la anterior figura lo primero es el nombre,

luego se pregunta qué estilo quiere para la página, ahí el usuario es capaz de escoger dos

estilos, el primero de ellos es “Implícito dentro de la página” y el segundo un “CSS”, si

selecciona este último el color de los componentes y texto de la página debe ser configurada

desde un fichero con extensión .css en cambio ,sí se selecciona el primero puede establecer

dicha configuración desde la propia página como muestra la figura 33.Por último se pasan los

nombres de las etiquetas y atributos de cada uno.



48

Figura 34 Estilos implícitos dentro de la página web

Configuración de los estilos dentro de la página donde se define el color de las etiquetas y el

color del texto que se va a utilizar.

Figura 35 Vista de cómo se va a conformar la aplicación



49

3.2.2.6 Fragmento de código de la opción “Adicionar Atributos de una Tabla”

Cuando se solicita hacer un proyecto de Sistema de Información que posee una base de datos,

la información esencial está compuesta por los detalles de las tablas de esa base de datos: su

nombre, y sus atributos. El software que se presenta en este trabajo, solicita a través de su

interfaz estas características. En el desarrollo del programa se aplicaron varios conceptos y

habilidades del lenguaje utilizado. Consideramos que el siguiente fragmento de código

correspondiente a precisar los atributos de una tabla resulta interesante:

if (jTextField2.getText().equals("")

|| ((String) jComboBox4.getSelectedItem()).toString().equals("")

|| ((String) jComboBox5.getSelectedItem()).toString().equals("")) {

JOptionPane.showMessageDialog(null, "Debe llenar todos los campos");

} else {

Atributo a = new Atributo();

a.setName(jTextField2.getText());

a.setType(jComboBox4.getSelectedItem().toString());

if (jComboBox5.getSelectedIndex() == 0) {

a.setVisibility(publicVisibility);

} else if (jComboBox5.getSelectedIndex() == 1) {

a.setVisibility(protectedVisibility);

} else if (jComboBox5.getSelectedIndex() == 2) {

a.setVisibility(privateVisibility);

}

DefaultListModellistModel = (DefaultListModel) jList1.getModel();



50

listModel.addElement(a);

jList1.setModel(list Model);

jTextField2.setText(null);

jDEdit_Atrib.setVisible(false);

}

El fragmento que se expuso anteriormente se corresponde con la acción del botón “Adicionar

Atributo” .En este código lo primero que se hace es chequear que los campos Nombre, Tipo

y Modificador (visibilidad) no estén vacíos, en caso que así fuera notifica que hubo un error

como este “Debe llenar todos los campos”lo cual permite volver a llenar los campos, si no

hubo errores en el llenado de los campos pasa a crear un objeto de la clase “Atributo”

llamado “a” y adiciona a dicho objeto mediantes las operaciones setName(), setType(),

setVisibility()los campos correspondientes, ya que dicha clase tiene redefinido el

toString()para que los campos se muestren de la forma más apropiada y entendible al usuario.

Posteriormente se crea un listModel de tipo DefaultListModelcon el objetivo de adicionar

el objeto “a” a la lista pero como el setModel ()de la lista solo acepta listas no se puede,pero

ellistModel tiene un método llamado addElememt () que si acepta objetos, lo que se hace es

que se le pasa al listModel el objeto “a” con el addElemnt () y después con el setModel ()

se le pasa el listModel a la lista jList1.Por último se limpia el campo “Nombre” y se oculta

la ventana.

3.2.2.7 Opción Guardar

Para poder guardar los resultados que el usuario ha ido introduciendo en la interfaz del

software se determinó usar el tabulador electrónico Excel. En este caso lo primero que se hizo

fue incluir a la biblioteca del proyecto una nueva, llamada jxl.jar, que le permite al programa

poder escribir datos en una tabla Excel. También fue necesario crear una clase llamada

Reporte donde van todas los métodos encargados de manipular dicha biblioteca.



51

Consideramos que este pedazo de código también es interesante y por ello se muestra a

continuación.

try {

Reporte r = new Reporte();

r.crearLibro();

r.guardarHoja(jTActores, "Diagrama de Casos de Uso", null);

r.guardarHoja(jTable6, "Diagrama de Clases", null);

String[] s = {"El nombre de la interfaz a implementar es : " + jLabel46.getText(),

"Colores de la aplicación:",

" Componentes " + jLabel51.getText(),

" Textos " + jLabel52.getText(),

" CSS " + jLabel33.getText()};

r.guardarHoja(jTable11, "Interfaz", s);

String[][] m = new String[2][2];

m[0][0] = jLabel56.getText();




r.guardarHoja(m, "Sistema a implementar");

r.guardar();

} catch (IOException | WriteException e) {



52

JOptionPane.showMessageDialog(this, "Ha ocurrido un error al guardar.\n" +

e.getMessage());

}

En el código expuesto anteriormente lo primero es crear un objeto de la clase “Reporte”,que

es la que contiene los métodos para guarda los resultados, unavez creado dicho objeto se llama

al método crearLibro() este es el encargado de buscar la dirección donde se va aguardar y de

establecer la extensión con que se quiere guardar dichos resultados, que para este caso se

define que la extensión será .xls.Luego se llama al método guardarHoja(JTabletable,

StringnombreTab, String[] texto), al cual se le pasa el nombre de la tabla a guardar, una

cadena que corresponde al nombre que va a tener de la hoja dentro del Excel y por ultimo un

arreglo de cadena para poder posibilitar pasar texto a la tabla en el Excel , en caso que no

tenga texto que guardar se le pasa null a este parámetro. También se llama a un método, que

tiene el mismo nombre que el anterior pero con parámetro diferentes guardarHoja

(String[][] table, StringnombreTab),este se utiliza para insertar el texto en forma de tabla

Excel.

3.3 Conclusiones parciales del capítulo

En este capítulo se trató sobre las características de la aplicación, desde detalles de su

implementación hasta aspectos vinculados con su uso. Además se mostraron ventanas donde

se explica cómo trabajar con la herramienta y se destacaron varios fragmentos de códigos que

se consideran de interés especial por la solución lograda.

Conclusiones

53

CONCLUSIONES

Se logró documentar de manera sintetizada conceptos sobre MDA y sus módulos, en

específico el CIM-PIM, objetivos fundamentales de este trabajo. Se logró hacer una

comparación de diferentes herramientas MDA existentes lo cual nos llevó a precisar la

necesidad de experimentar en esta área.

Se generaron los diagramas de Casos de Uso y de Clase así como la Interfaz que

permiten entender el diseño y funcionamiento del Módulo CIM-PIM de nuestra

herramienta.

Se implementó en Java la versión 1.0 del módulo CIM-PIM de la herramienta jMDA,

que posibilita a analistas y usuarios poseer una herramienta de ayuda para el análisis de

requisitos de sistemas de información, influyendo en una mejor productividad en el

desarrollo de este tipo de software.

Recomendaciones

54

RECOMENDACIONES

Divulgar el resultado de este trabajo en grupos de desarrollo de software,

especialmente en DESOFT, empresa inicialmente coauspiciadora del proyecto de

investigación, y ahora en la UCI, rectora del Programa Nacional de Desarrollos de la

Industria del Software Nacional.

Continuar el desarrollo de la herramienta añadiéndole nuevas funcionalidades y

diagramas aun no contemplados. Más específicamente:

Lograr una mejor representación visual de los diagramas soportados.

Añadirle a los diagramas de clases otros elementos tales como interfaces,

relaciones de implementación, etc.

Añadir diagramas de actividades, tanto para representar la descripción de los

casos de uso, como para describir a manera de seudocódigo operaciones de

clases.

Añadir Diagramas de Estado que representen la interfaz seleccionada.

Lograr que se enfrenten en paralelo el desarrollo de los módulos PIM-PSM y PSM-

Código, para lograr una herramienta completa y de gran impacto.

Bibliografía

55

BIBLIOGRAFÍA

ÁLVARO JIMÉNEZ RIELO, J. M. V. M. 2009. Desarrollo de Editores Gráficos para el

Modelado de Bases de Datos Objeto-Relacionales: SQL2003 y Oracle.

ANACLETO, V. A. 2006. MDA Reusabilidad Orientada al Negocio.

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

Practice And Promise. .

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

EDNA D. LÓPEZ L , M. G. G., MÁXIMO LÓPEZ S Y ERICK L. IDUÑATE R 2012.

Proceso de Desarrollode Software MedianteHerramientas MDA.

FRANKY, M. C. 2010. MDA: Arquitectura Dirigida por Modelos.

JUAN CARLOS HERRERA , A. M. E. I. D. 2012. Una Caracterización de Herramientas

MDA de Código Abierto

KUZNETSOV, M. B. 2006. UML Model Transformation and Its Application to MDA

Technology.

MARTÍNEZ, N. S. 2014 Método para la transformación automatizada de modelos de

procesos de negocio a modelos de componentes para sistemas de gestión empresarial

NEUSTADT, J. A. A. I. 2002. UML and the Unified Process.

OMG 2003. Especificaciones sobre MDA.

PÁEZ, J. B. Q. Y. R. A. D. 2007. Marco de Referencia para la Evaluación de Herramientas

Basadas en MDA.

PEÑA, M. Á. M. 2012. Desarrollo de Herramienta para Arquitectura Dirigida por Modelos

JMDA versión 2.0 Modulo PSM-Código Fuente.

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

herramienta case para arquitectura ... - dspace.uclv.edu.cu

Documents