Herramienta CASE para Arquitectura ... - dspace.uclv.edu.cu
Transcript of 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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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)
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 1. Fundamentos Teóricos sobre 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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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:
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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.
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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)
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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:
CAPÍTULO 1. Fundamentos Teóricos sobre MDA
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
CAPÍTULO 2.Análisis y diseño de la herramienta
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.
CAPÍTULO 2.Análisis y diseño de la herramienta
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
CAPÍTULO 2.Análisis y diseño de la herramienta
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
CAPÍTULO 2.Análisis y diseño de la herramienta
29
Figura 12. Diagrama de clases parte 2
CAPÍTULO 2.Análisis y diseño de la herramienta
30
Figura 13. Diagrama de clases parte 3
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
CAPÍTULO 2.Análisis y diseño de la herramienta
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
CAPÍTULO 2.Análisis y diseño de la herramienta
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
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
35
Figura 15 Ventana del Manual de usuario (Ayuda)
Figura 16 Ventana del Acerca de
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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,
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de 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
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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();
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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();
m[0][1] = jLabel58.getText();
m[1][0] = jLabel57.getText();
m[1][1] = jLabel59.getText();
r.guardarHoja(m, "Sistema a implementar");
r.guardar();
} catch (IOException | WriteException e) {
CAPÍTULO 3.Descripción de la implementación y
puesta en práctica de la herramienta
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.