COMPROMISE Herramienta de Análisis de Conformidad

U NIVERSIDAD DE C ASTILLA -L A M ANCHA
E SCUELA S UPERIOR DE I NFORMÁTICA
G RADO EN I NGENIERÍA EN I NFORMÁTICA
T ECNOLOGÍA ESPECÍFICA DE I NGENIERÍA DEL
S OFTWARE
T RABAJO DE F IN DE G RADO
COMPROMISE
Herramienta de Análisis de Conformidad para Procesos
Software
Víctor Parrado López
Diciembre, 2014
U NIVERSIDAD DE C ASTILLA -L A M ANCHA
E SCUELA S UPERIOR DE I NFORMÁTICA
DEPARTAMENTO DE TECNOLOGÍAS Y
SISTEMAS DE INFORMACIÓN
T ECNOLOGÍA ESPECÍFICA DE
I NGENIERÍA DEL S OFTWARE
T RABAJO DE F IN DE G RADO
COMPROMISE
Herramienta de Análisis de Conformidad para Procesos
Software
Autor: Víctor Parrado López
Director: Félix Oscar García Rubio
Diciembre, 2014
©Permission is granted to copy, distribute and/or modify this document under the terms of
the GNU Free Documentation License, Version 1.3 or any later version published by the Free
Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
Texts. A copy of the license is included in the section entitled "GNU Free Documentation
License".
Se permite la copia, distribución y/o modificación de este documento bajo los términos de
la Licencia de Documentación Libre GNU, versión 1.3 o cualquier versión posterior publicada
por la Free Software Foundation; sin secciones invariantes. Una copia de esta licencia esta
incluida en el apéndice titulado «GNU Free Documentation License».
Muchos de los nombres usados por las compañías para diferenciar sus productos y
servicios son reclamados como marcas registradas. Allí donde estos nombres aparezcan
en este documento, y cuando el autor haya sido informado de esas marcas registradas, los
nombres estarán escritos en mayúsculas o como nombres propios.
Víctor Parrado López, 2014
T RIBUNAL :
Presidente:
Vocal :
Secretario:
F ECHA DE DEFENSA :
C ALIFICACIÓN :
P RESIDENTE
VOCAL
S ECRETARIO
Fdo.:
Fdo.:
Fdo.:
Resumen
Actualmente las organizaciones se encuentran en un momento en el que, dada la competencia actual, necesitan desarrollar productos de calidad y a un precio razonable. El ámbito
de la Ingeniería Software no es una excepción y es por eso que la gestión de los procesos de
desarrollo de los productos ha cobrado una importancia notable en los últimos años, dado
que la calidad del producto final depende directamente de la calidad de los procesos de una
organización.
La definición de estos procesos es una tarea imprescindible antes de realizar la gestión
de los mismos y éstos han de cubrir todos los objetivos de negocio de la organización. No
obstante, en el estado globalizado en el que se ve sumida la industria del software y ante la
complejidad y necesidad de homogeneidad en el desarrollo software, es vital que los procesos
estén alineados con los estándares y modelos de referencia de procesos.
Con el fin de facilitar el alineamiento de las organizaciones con los procesos de referencia y asistir de forma automática en su procesamiento, en el presente TFG se desarrolla
la herramienta COMPROMISE. Esta herramienta permite cuantificar el cumplimiento o
conformidad de los procesos de la organización con los estándares de la industria, la realización de transformaciones entre modelos con el fin de proporcionar a los procesos software
la posibilidad de la ejecución y simulación y el análisis de la conformidad para recomendar
aspectos de mejora necesarios para lograr el cumplimiento deseado. Para ello se aplican los
paradigmas de Ingeniería de Procesos y Desarrollo de Software Dirigido por Modelos.
vii
Abstract
Nowadays, organizations stands in a situation in which need to develop quality products
with a reasonable prize due to the current competence. Software engineering field is not an
exception and, therefore the management of develop products have had a remarkable importance in the last years. So, it is determinated that final products are a direct consecuence of its
development process and the final quality of the product depend on the organization processes.
Before managing the processes, it’s essential to define them in order to meet the business organization goals. Nevertheless, in the globalization field, where currently Software
engineering stands, it is essential that processes are fit with industry standards and reference
models of processes. This is important to cover the complexity and the homogeneity needed
in software development.
This TFG has developed the tool COMPROMISE so as to facilitate the alignment of
the organizations with reference processes and provide assistance in automatic processing.
COMPROMISE lets us to quantify the acceptance of the organization processes with industry standards and also, to perform transformations between models. The goal is to provide to
the software processes the execution and simulation possibility and the compliance analyse
in order to recommend us features that still need to improve to get the desired compliance.
For this purpose the models of Model Driven Engineering and Software Process Engineering
pararadigms are applied.
ix
A mis padres, Antonio y Eloísa.
Porque siempre han creído en mi.
A mi hermana Inma.
Porque siempre saca una sonrisa.
A Fátima .
Por sus ánimos continuos e incondicionales,
así todo es más fácil.
A todos, gracias.
Sin vosotros no hubiera sido posible.
“Caballeros, ¿debo recordarles que, mis probabilidades de éxito,
aumentan en cada nuevo intento?”
xi
Agradecimientos
Es muy poco el espacio para expresar mi gratitud a tantas personas que me han acompañado
en este largo camino, que ahora se ve demasiado corto.
Gracias a mis compañeros de clase durante todos estos años, Juanjo, Carlos, Laguna, Alex,
Antonio, Sergio, Rubén, Eloy, Fran. Han sido demasiados los buenos momentos como para
olvidarlos.
Gracias a todos los integrantes del Grupo Alarcos, las cosas aprendidas y las horas compartidas os hacen imprescindibles en estas líneas.
Gracias Félix, director de este trabajo, por su ayuda constante y por darme la oportunidad
de aprender junto a él.
Gracias mis amigos de Manzanares; a Luisma, Arturo, Rincón, Valver, Carlos y Dani.
Decían en Martín Hache que “uno se siente parte de muy poca gente; tu país son tus amigos
y eso sí se extraña” y es en esta etapa que termina cuando me doy cuenta de las verdades
que esta frase encierra. Echando la vista atrás únicamente me acuerdo de buenos momentos.
Gracias por hacer posible este país.
A Fátima, que ha escuchado todos los desvelos de este trabajo y donde únicamente he
encontrado apoyo.
A Inma, mi hermana, que inicia su camino. No dejes que nadie te diga lo que tienes que
hacer.
A mis padres, por todos estos años de apoyo y por enseñar con el ejemplo que la perseverancia nos hace crecer como personas.
A mis abuelos, los que están y los que no.
Gracias a todos. Sin vosotros estas líneas no habrían encontrado la tinta para escribirse.
xiii
Índice general
Agradecimientos
xiii
Índice de figuras
xviii
Índice de tablas
xxi
Índice de listados
xxiii
1
Introducción
1.1 Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Estructura del Documento . . . . . . . . . . . . . . . . . . . . . . . . . .
2
Objetivos del PFC
9
2.1 Objetivos derivados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.2 Funcionalidad General de la Herramienta . . . . . . . . . . . . . . . . . . . 11
2.3 Destrezas a adquirir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3
Estado de la Cuestión
3.1 Procesos Software . . . . . . . . . . . . . . . . . . . .
3.2 Ingeniería de Procesos Software . . . . . . . . . . . .
3.3 SPEM y EPFC . . . . . . . . . . . . . . . . . . . . .
3.3.1 Visión del metamodelo SPEM 2.0 . . . . . . .
3.3.2 Eclipse Process Framework Composer (EPFC)
3.4 Modelos de Referencia y Mejora de Procesos Software
3.4.1 CMMI . . . . . . . . . . . . . . . . . . . . .
3.4.2 ISO/IEC 12207 . . . . . . . . . . . . . . . . .
3.4.3 ISO/IEC 9000 . . . . . . . . . . . . . . . . .
3.4.4 ISO 90003 . . . . . . . . . . . . . . . . . . .
3.5 Armonización . . . . . . . . . . . . . . . . . . . . . .
3.5.1 HFramework . . . . . . . . . . . . . . . . . .
3.5.2 ARMONÍAS-DGS . . . . . . . . . . . . . . .
3.6 Conformidad de Procesos . . . . . . . . . . . . . . . .
3.7 Desarrollo de Software Dirigido por Modelos (DSDM)
3.8 Herramientas relacionadas . . . . . . . . . . . . . . .
4
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
4
6
15
. . . . . . . . . .
16
. . . . . . . . . .
18
. . . . . . . . . .
20
. . . . . . . . . .
24
. . . . . . . . . .
28
. . . . . . . . . . . 31
. . . . . . . . . . . 31
. . . . . . . . . .
32
. . . . . . . . . .
34
. . . . . . . . . .
35
. . . . . . . . . .
35
. . . . . . . . . .
36
. . . . . . . . . . . 37
. . . . . . . . . .
40
. . . . . . . . . .
42
. . . . . . . . . .
48
Método de Trabajo
51
4.1 OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
4.1.2 Roles de OpenUP . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
xv
xvi
ÍNDICE GENERAL
4.1.3
4.1.4
4.2
Proceso Iterativo e Incremental . . . . . . . . . . . . . . . . . .
Flujos Fundamentales de Trabajo Obtenidos para el desarrollo
COMPROMISE. . . . . . . . . . . . . . . . . . . . . . . . . .
Entorno Tecnológico . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 Herramientas de modelado y desarrollo y tecnologías utilizadas
4.2.2 Entorno tecnológico MDA . . . . . . . . . . . . . . . . . . . .
4.2.3 Documentación . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.4 Lenguajes y Librerías utilizadas . . . . . . . . . . . . . . . . .
. . . 57
de
. .
59
. .
60
. .
60
. . . 67
. .
68
. .
70
5
Resultados: Herramienta COMPROMISE
75
5.1 Fase de Inicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
5.1.2 Dominio de la Herramienta . . . . . . . . . . . . . . . . . . . . . . . 77
5.1.3 Modelo de Casos de Uso . . . . . . . . . . . . . . . . . . . . . . .
80
5.1.4 Plan de Iteraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Fase de Elaboración y Construcción . . . . . . . . . . . . . . . . . . . . .
88
5.2.1 Iteración 1: Generador de Modelos UMA a partir de la BBDD de
ARMONÍAS-DGS . . . . . . . . . . . . . . . . . . . . . . . . . .
89
5.2.2 Iteración 2: Carga del Contenido de Método de EPFC a partir de la
BBDD ARMONÍAS-DGS . . . . . . . . . . . . . . . . . . . . . .
92
5.2.3 Iteración 3: Implementación de las funciones para el Análisis de
Conformidad de Procesos . . . . . . . . . . . . . . . . . . . . . .
98
5.2.4 Iteración 4 : Implementación de Módulo de Representación gráfica
de estadísticas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.2.5 Iteración 5: Integración de la capa de Persistencia con COMPROMISE110
5.2.6 Iteración 6: Definir transformación entre los metamodelos UMA y
BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.2.7 Iteración 7: Documentación de la herramienta . . . . . . . . . . . . 122
5.3 Fase de Transición . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.4 Patrones de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
5.4.1 Modelo-Vista-Controlador . . . . . . . . . . . . . . . . . . . . . . 126
5.4.2 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
5.4.3 DAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6
Conclusiones y Propuestas
129
6.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
6.1.1 Propuestas de trabajos futuros . . . . . . . . . . . . . . . . . . . . . 131
6.1.2 Opinión Personal . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Bibliografía
134
A Manual de Instalación
143
B Manual de Usuario
B.1 Registro de Usuario . . . . . . . . . . . . . . .
B.2 Selector de Idioma y Menú de COMPROMISE
B.3 Administración de la herramienta . . . . . . . .
B.4 Cargar Procesos EPFC . . . . . . . . . . . . .
B.5 Compliance Organización . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
145
. 145
. 146
. . 147
. 150
. 153
ÍNDICE GENERAL
B.6
B.7
B.8
B.9
xvii
Generar archivo para MediniQVT . . . . . . . . . . . . . . . . . .
Abrir Medini-QVT y ejecutar transformación . . . . . . . . . . . .
Representación Proceso transformado (BPMN) en BPMN2 Modeler
Ayuda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
. . 157
. . 157
. 158
. 159
C Acrónimos
161
D Glosario
165
E Planificación del TFG
E.1 Planificación Temporal
E.2 Equipo de Trabajo . . .
E.3 Recursos Materiales . .
E.4 Presupuesto . . . . . .
.
.
.
.
169
169
170
170
. 171
F Código Fuente
F.1 Ejemplo clase Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . .
173
173
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Índice de figuras
1.1
1.2
La ciénaga de los estándares y modelos de referencia de la madurez, evaluación y mejora de procesos [57]. . . . . . . . . . . . . . . . . . . . . . . .
Relación entre ARMONIAS-DGS y COMPROMISE . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
Etapas Clave de la Gestión del Proceso Software [57]. . . . . . . . . . . . . 17
Conceptos centrales de SPEM 2.0. [63] . . . . . . . . . . . . . . . . . . . . 21
Usos básicos SPEM 2.0. [63] . . . . . . . . . . . . . . . . . . . . . . . . .
22
Elementos de SPEM 2.0 [63]. . . . . . . . . . . . . . . . . . . . . . . . . .
24
Estructura de paquetes de SPEM 2.0 [57]. . . . . . . . . . . . . . . . . . .
25
Ejemplo gráfico del contenido de método definido con EPFC. . . . . . . . .
29
Jerarquía de los elementos de SPEM 2.0 en la definición de Procesos [57].
30
Definición del proceso con EPFC . . . . . . . . . . . . . . . . . . . . . .
30
Procesos ISO 12207 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Esquema de HFramework [53]. . . . . . . . . . . . . . . . . . . . . . . .
38
Esquema de ARMONÍAS-DGS. [61] . . . . . . . . . . . . . . . . . . . . .
39
Arquitectura de distintos niveles de modelado[38]. . . . . . . . . . . . . .
44
Organización de MDE [38] . . . . . . . . . . . . . . . . . . . . . . . . . .
44
Transformaciones MDA[38] . . . . . . . . . . . . . . . . . . . . . . . . .
46
Arquitectura Conceptual de Transformaciones[38] . . . . . . . . . . . . .
48
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
4.11
4.12
4.13
4.14
4.15
4.16
Ciclo de vida de OpenUP [35] . . . . . . . . . . . . . .
Relaciones del Rol Analista en OpenUP[35] . . . . . . .
Relaciones del Rol Comodín en OpenUP[35] . . . . . .
Relaciones del Rol Arquitecto en OpenUP[35] . . . . . .
Relaciones del Rol Desarrollador en OpenUP[35] . . . .
Relaciones del Rol Project Manager en OpenUP[35] . .
Relaciones del Rol Stakeholder en OpenUP[57] . . . . .
Relaciones del Rol Tester en OpenUP[57] . . . . . . . .
Ciclo de Vida de OpenUP[57] . . . . . . . . . . . . . .
Pantalla Principal Herramienta EPFC . . . . . . . . . .
Atención de una Petición Struts2[10] . . . . . . . . . . .
Ejemplo Aplicación MySQLWorkbench[10] . . . . . . .
Pantalla principal de la Herramienta BPMN Modeler . .
Pantalla principal Eclipse Modelling Framework (EMF)
Vista de ejemplo de la aplicación Medini QVT[10] . . .
Ejemplo de la herramienta TexMaker[10] . . . . . . . .
5.1
5.2
Diagrama general de COMPROMISE . . . . . . . . . . . . . . . . . . . .
Diagrama de Casos de Uso de Administrador de la Herramienta . . . . . .
xix
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
5
.
53
.
54
.
54
.
55
.
56
.
56
.
56
. . 57
.
58
. . 61
.
63
.
64
.
65
. . 67
.
68
.
69
79
80
xx
ÍNDICE DE FIGURAS
5.3
5.4
5.5
5.6
5.7
5.8
5.9
. 81
90
. 91
93
94
94
5.29
5.30
5.31
5.32
Diagrama de casos de uso Gestor de Procesos . . . . . . . . . . . . . . . .
Correspondencias ARMONÍAS-DGS y UMA . . . . . . . . . . . . . . . . .
Diseño de Clases Prueba de Concepto . . . . . . . . . . . . . . . . . . . .
Comparativa de procesos COMPROMISE y EPFC . . . . . . . . . . . . .
Generar Clases con JAXB . . . . . . . . . . . . . . . . . . . . . . . . . .
Jerarquía de Elementos para la definición de Procesos en SPEM 2.0[10] . .
Diagrama de Diseño correspondiente a la obtención de Procesos de la Organización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama General de la Herramienta con Struts2 . . . . . . . . . . . . . .
Estructura General Paquetes COMPROMISE . . . . . . . . . . . . . . . .
Prototipo de Interfaz para la visualización de la conformidad . . . . . . . .
Diagrama clases de análisis para evaluar la Conformidad de Proceso . . .
Diagrama Clases Recomendador . . . . . . . . . . . . . . . . . . . . . . .
Gráfica de Compliance total de la organización. . . . . . . . . . . . . . . .
Ejemplo gráfica Barras de Compliance . . . . . . . . . . . . . . . . . . .
Ejemplo gráfica Área de Compliance . . . . . . . . . . . . . . . . . . . . .
Diagrama de clases de Diseño Generar Informe . . . . . . . . . . . . . . .
Diagrama de clases de Análisis para generar PDF[10] . . . . . . . . . . .
Ejemplo de Proceso definido con EPFC . . . . . . . . . . . . . . . . . . .
Descomposición Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . .
Alta de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diagrama de base de datos de COMPROMISE . . . . . . . . . . . . . . .
Simplificación BBDD Armonias-DGS . . . . . . . . . . . . . . . . . . . .
Selección márgen de aceptación para Proceso . . . . . . . . . . . . . . . .
Menú de Selección COMPROMISE . . . . . . . . . . . . . . . . . . . . .
Diagrama de Análisis para la función de Transformación entre Modelos . .
Ejemplo de estructura deproceso definida con EPFC en la herramienta
BPMN2 Modeler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo proceso BPMN . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iconos de Cambio de Idioma . . . . . . . . . . . . . . . . . . . . . . . . .
Ventana de cambio de rutas de las distintas herramientas . . . . . . . . . .
Esquema del Patrón MVC . . . . . . . . . . . . . . . . . . . . . . . . . .
B.1
B.2
B.3
B.4
B.5
B.6
B.7
B.8
B.9
B.10
B.11
B.12
B.13
B.14
B.15
Vista Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo del Menú en Español . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo del Menú en Inglés . . . . . . . . . . . . . . . . . . . . . . . .
Acceso al menú de administración. . . . . . . . . . . . . . . . . . . . . .
Usuarios registrados en COMPROMISE . . . . . . . . . . . . . . . . . .
Administración de las organizaciones de COMPROMISE. . . . . . . . . .
Selector de Rutas de COMPROMISE . . . . . . . . . . . . . . . . . . . .
Definición de los márgenes de aceptación . . . . . . . . . . . . . . . . .
Selector de aceptación de Conformidad . . . . . . . . . . . . . . . . . .
Menú de Conformidad de Compromise. . . . . . . . . . . . . . . . . . .
Ejecutar EPFC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Composición de Procesos mediante EPFC . . . . . . . . . . . . . . . . .
Crear Delivery Process EPFC . . . . . . . . . . . . . . . . . . . . . . .
Ejecución el Panel Principal de Compromise . . . . . . . . . . . . . . .
Gráfica de Histórico de la Conformidad de Procesos de una Organización
145
. 147
. 147
148
148
148
149
149
150
150
. 151
. 151
152
153
154
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
5.19
5.20
5.21
5.22
5.23
5.24
5.25
5.26
5.27
5.28
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
95
96
. 97
100
100
. 101
102
105
105
106
. 107
110
. 111
. 111
113
114
115
118
119
119
120
123
123
126
ÍNDICE DE FIGURAS
B.16 Gráfico de barras correspondiente a la Conformidad de Proceso . . . . . .
B.17 Roles Relacionados con la Tarea Seleccionada . . . . . . . . . . . . . . .
B.18 Gráfica correspondiente al Compliance de la Organización por Marcos de
Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.19 Menú desplegable para la función Recomendador . . . . . . . . . . . . . .
B.20 Función de generación de Informes PDF . . . . . . . . . . . . . . . . . .
B.21 Ejecución de la Composición del Documento .xmi para el Framework MediniQVT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B.22 Ejecución del Framework MediniQVT . . . . . . . . . . . . . . . . . . . .
B.23 Ejecución de la transformación MediniQVT . . . . . . . . . . . . . . . . .
B.24 Ejecuta el Framework BPMN Modeler . . . . . . . . . . . . . . . . . . . .
B.25 Presentación de Proceso mediante BPMN Modeler . . . . . . . . . . . . .
B.26 Ejecución de la ayuda de Compromise . . . . . . . . . . . . . . . . . . . .
xxi
154
155
155
156
156
. 157
. 157
158
158
159
159
Índice de tablas
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
Roles de la herramienta con sus funcionalidades y componente al que pertenecen.
Iteración 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Iteración 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
82
83
84
84
85
86
87
87
E.1 Planificación Temporal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
E.2 Recursos Hardware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
E.3 Costes por contratación de empleados. . . . . . . . . . . . . . . . . . . . . . 171
xxiii
Índice de listados
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
5.11
5.12
5.13
5.14
5.15
5.16
5.17
5.18
F.1
F.2
Extracto “ActionCargarMethodContent.java” . . . . . . . . . . . . . .
Ejemplo Marshall. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Composición XML. . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo clase Manager. . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Función Recomendador. . . . . . . . . . . . . . . . . . . . . . . .
Código de generación de documentos PDF. . . . . . . . . . . . . . . .
Test salida documento PDF. . . . . . . . . . . . . . . . . . . . . . . . .
Persistencia objeto Proceso. . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo Interceptor. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Nuevo Rol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo de código de la Transformación. . . . . . . . . . . . . . . . .
Introducir el objeto usuario al validar la sesión (Login) . . . . . . . . .
Recuperar Objeto Usuario en una Acción para posteriormente evaluarlo.
Test Validar Sesión . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejecución Medini-QVT. . . . . . . . . . . . . . . . . . . . . . . . . .
Diccionario Español. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Diccionario Inglés. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extracto de código del Patrón Singleton . . . . . . . . . . . . . . . . .
Ejemplo clase Manager. . . . . . . . . . . . . . . . . . . . . . . . . . .
Ejemplo UnMarshall . . . . . . . . . . . . . . . . . . . . . . . . . . .
xxv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 91
. 97
98
102
104
108
109
115
116
. 117
. 121
. 121
122
122
124
125
125
. 127
173
176
Capítulo 1
Introducción
Debido a la ingente oferta de producto en la actualidad, la demanda es muy selectiva y
como consecuencia las exigencias de los consumidores son muy elevadas. Es por eso que las
organizaciones han experimentado un cambio en cuanto al paradigma de mercado, ya que su
supervivencia está estrechamente relacionada con el producto que ofrecen y por tanto con su
calidad.
La calidad en el entorno Software no es una excepción, aunque en la mayoría de los casos
es cierto que no puede ser asegurada basándose en el producto final o desarrollando controles
de calidad estadísticos, sino que es conveniente fijarnos en el proceso por el cual éste se
obtiene. Según [36] existe una correlación directa entre la calidad del proceso y la calidad del
producto obtenido.
Básicamente un Proceso Software es un conjunto coherente de políticas, estructuras
organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir,
desarrollar, empaquetar y mantener un producto software [36]. La idea básica es que el
proceso defina quién hace qué, cuándo y cómo alcanzar un determinado objetivo.
Las organizaciones cada vez son más conscientes de que documentar, medir y comparar
sus procesos son premisas esenciales para ofrecer un producto de calidad. Cada organización debe tener sus procesos definidos, propios e intransferibles, que deben satisfacer sus
propósitos de negocio. No obstante, es recomendable tener en cuenta una serie de estándares
y buenas prácticas en su definición para lograr un proceso de calidad. Estas guías toman el
nombre de modelo de referencia.
2
Básicamente, un modelo de referencia define un conjunto de procesos organizado de
forma coherente, que facilitan a una organización un mejor desempeño de los mismos y que
suele traducirse en una mayor calidad en los productos y servicios que ofrecen.
La idea de mejora de procesos por parte de las organizaciones con el objetivo de incrementar la calidad de los mismos ha llevado a la aparición de muchos marcos de procesos y de
evaluación, hasta tal punto que se ha convertido en “una ciénaga en la que se empantanen los
esfuerzos de mejora de procesos si una organización no es cuidadosa” [65].
Figura 1.1: La ciénaga de los estándares y modelos de referencia de la madurez, evaluación y
mejora de procesos [57].
CAPÍTULO 1. INTRODUCCIÓN
3
Sin embargo y a pesar de la cantidad de estándares y modelos de referencia así como de la
heterogeneidad de sus propósitos, resultaría imprudente intentar adaptar los procesos de una
organización para con un marco de referencia particular, pues son metodologías generales y
no tienen por qué adaptarse fielmente a los propósitos de una organización. Es por eso que las
empresas pueden encontrarse ante la necesidad de la implementación de varios modelos de
referencia, echando en falta mecanismos que les faciliten el trabajo. Surge así el concepto de
Armonización de marcos de referencia.
Elementos de distintos marcos de referencia pueden coincidir con los propósitos de negocio de las organizaciones, la armonización permite integrar estos elementos heterogéneos en
un único marco de referencia personalizado, tal como se aborda con más profundidad en el
siguiente apartado.
Una vez determinado el marco de referencia que vamos a utilizar (armonizado o no), las
organizaciones deberán definir sus procesos siguiendo las pautas del mismo. Para ello el
mercado dispone de algunas herramientas que darán soporte a esta tarea, entre estas herramientas destacaremos EPF Composer. EPF Composer, en adelante EPFC, es una herramienta
que da soporte a la definición de los procesos de una organización utilizando para ello el
metamodelo UMA, compatible con SPEM 2.0 [42]. Tanto UMA como SPEM 2.0 permiten
a las organizaciones representar un proceso de forma sencilla utilizando como elementos
básicos roles, productos de trabajo y tareas. La idea subyacente es que el modelo del proceso
nos especifique quién hace (rol) qué tarea para, a partir de unas entradas productos de
trabajo obtener unas salidas productos de trabajo).
Mediante EPFC las empresas pueden crear sus Contenidos de Método (que contendrán
roles, tareas, productos de trabajo, etc.) y a partir de ella definir sus procesos de una forma
sistemática. No obstante si la organización decide alinear sus procesos con uno o más modelos
de referencia, no dispone de los mecanismos para evaluar si sus procesos son conformes a
éstos.
Por este motivo surge el concepto de “Compliance” o Conformidad con la definición del
proceso, que permite evaluar si el proceso cumple con el modelo de referencia y su grado de
4
1.1. ANTECEDENTES
cumplimiento en base a distintas ponderaciones. Cabe destacar que para facilitar la comprensión y lectura del documento se utilizará el término Conformidad en lo sucesivo, no obstante
es muy común encontrar en la bibliografía la expresión en su traducción inglesa (Compliance).
Este último concepto constituye la principal motivación del presente TFG y determina su
alcance, que comprende la representación de modelos y marcos de referencia de acuerdo al
metamodelo (UMA), el cálculo de conformidad de los procesos de la organización respecto a
procesos de referencia, la transformación de procesos para facilitar su procesamiento automático y la visualización de la conformidad como soporte para la toma de decisiones.
A continuación se presentan los antecedentes que dan soporte y motivan la herramienta
objeto del Trabajo de Fin de Grado.
1.1
Antecedentes
Los antecedentes que constituyen la motivación del desarrollo de esta herramienta son: HFramework [53], tesis que propone mecanismos de armonización en ambientes multimarco
y la herramienta ARMONÍAS-DGS, la cual da soporte tecnológico al paradigma anterior,
soportando la armonización y evaluación de marcos de procesos heterogéneos [61].
La herramienta objeto del presente Trabajo de Fin de Grado está estrechamente relacionada con el segundo antecedente, pues se nutrirá del conocimiento almacenado en la base
de datos de ARMONÍAS-DGS para definir la Librería de Método de la organización. De
esta manera, además de marcos de referencia estandarizados, COMPROMISE también podrá
analizar la conformidad de los procesos de ambientes multi-marco.
Para contextualizar el antecedente principal se debe considerar que la herramienta ARMONÍASDGS está dividida en dos bloques, el componente de armonización y el componente de
evaluación:
• Componente de Armonización: Básicamente las tareas de este componente se dividen
en gestionar y analizar gráficamente los proyectos de armonización. Por un lado tiene
CAPÍTULO 1. INTRODUCCIÓN
5
en cuenta los recursos que necesita y por otro gestiona la estrategia de armonización de
los marcos de procesos.
• Componente de Evaluación: Este componente se encarga de la gestión y configuración de las evaluaciones que se llevarán a cabo sobre las fábricas, partiendo de los
cuestionarios hasta el soporte y análisis gráfico de los resultados.
A continuación, en la Figura 1.2 se presenta un esquema básico de la herramienta y su
interacción con ARMONÍAS-DGS. Como podemos ver, COMPROMISE provee al usuario
de funcionalidades de transformación de modelos entre Procesos Software y Procesos de
negocio y análisis de conformidad de los procesos de la organización respecto a los modelos
de referencia almacenados en la base de datos de ARMONÍAS-DGS.
GESTIÓN DE
ORGANIZACIÓN
TRANSFORMACIÓN
ARMONÍAS - DGS
Modelos no Armonizados
BBDD
Modelos Armonizados
COMPLIANCE
EPFC
COMPROMISE
BBDD Hibernate
PROCESOS DEFINIDOS
Figura 1.2: Relación entre ARMONIAS-DGS y COMPROMISE
6
1.2. ESTRUCTURA DEL DOCUMENTO
1.2
Estructura del Documento
Además de la Introducción el presente TFG está formado por los siguientes capítulos:
2. Objetivos: Se presentan los objetivos que se desean satisfacer con el desarrollo de la
presente herramienta, así como una breve explicación de los mismos.
3. Estado de la Cuestión: En este capítulo se presentan los distintos avances en las áreas
que tienen relación con el desarrollo del presente Trabajo de Fin de Grado.
4. Método de Trabajo: En este capítulo se presenta el método de trabajo seguido en
el proceso de desarrollo de COMPROMISE y el entorno tecnológico utilizado en el
mismo.
5. Resultados: Herramienta COMPROMISE En este capítulo se presentarán los principales artefactos generados durante el desarrollo de la herramienta en sus distintas
iteraciones de acuerdo al método de trabajo seguido.
6. Conclusiones y Propuestas: En este capítulo se presentan las conclusiones obtenidas
al final del desarrollo, el grado del cumplimiento de los objetivos, propuestas para
trabajo futuro y la opinión personal del autor una vez finalizado el proceso de desarrollo
de COMPROMISE.
El presente documento incluye además los siguientes apéndices.
1. Manual de Instalación (Apéndice A): En este apéndice se detallarán los pasos necesarios para la correcta instalación de COMPROMISE.
2. Manual de Usuario (Apéndice B): En este apéndice se describe el manual de usuario
de la herramienta y se ilustra su uso con ejemplos.
3. Acrónimos: (Apéndice C): En este apéndice se presentarán los acrónimos utilizados
para la elaboración del presente documento.
4. Glosario: (Apéndice D): En este apéndice se pueden encontrar los términos utilizados
en el presente TFG.
CAPÍTULO 1. INTRODUCCIÓN
7
5. Planificación del TFG: (Apéndice E): En este apéndice se muestra una estimación
del esfuerzo y recursos utilizados. Además se expone una planificación temporal del
desarrollo.
6. Código Fuente: (Apéndice F): En este apéndice se presentan extractos de código
representativo del proceso de desarrollo.
Capítulo 2
Objetivos del PFC
A lo largo de este capítulo se describe el objetivo principal de este Trabajo de Fin de Grado,
junto con los objetivos parciales derivados del mismo.
La motivación del presente Trabajo de Fin de Grado viene determinada por la necesidad
de una herramienta que evalúe el nivel de conformidad de los procesos de una organización
respecto a un modelo de referencia, mostrar los resultados de su análisis de una manera
gráfica y proporcionar a las organizaciones un valor tangible por el cual determinar el grado
de conformidad de sus tareas implementadas.
Además aumentará el valor añadido de la herramienta ARMONIAS-DGS, antecedente de
la presente, pues lograremos una representación de los modelos de referencia de su base de
datos mediante el metamodelo UMA, las organizaciones dispondrán de este conocimiento a
la hora de definir sus procesos y será posible determinar su grado de conformidad.
Del mismo modo la herramienta dará soporte a la ejecución de transformaciones entre
modelos UMA y BPMN, siguiendo el paradigma de desarrollo dirigido por modelos (Model
Driven Development) con el objetivo de representar su resultado en la herramienta de modelado BPMN Modeler para facilitar la ejecución futura de los procesos.
10
2.1. OBJETIVOS DERIVADOS
A continuación descompondremos el objetivo principal en varios objetivos subyacentes:
2.1
Objetivos derivados
• Establecer la correspondencia de los procesos de la base de datos de la herramienta
ARMONÍAS-DGS [61] que provienen de los distintos estándares (armonizados o no)
con el metamodelo UMA.
• Proporcionar a la herramienta EPF Composer de una base de conocimiento en forma
de Librería de Método que contenga todos los elementos de los distintos marcos de
procesos que alberga la herramienta ARMONÍAS-DGS en su base de datos.
• Analizar la conformidad de los procesos que la organización haya definido para con los
marcos de referencia que sean seleccionados. Así la organización tendrá mecanismos
de visualización gráfica que proporcionen el estado y nivel de completitud en el que
se encuentran los procesos y de qué manera se podrían mejorar teniendo en cuenta los
recursos de la organización.
• La herramienta tendrá la capacidad de crear un perfil para las empresas con los recursos
que posee. Éstos se tendrán en cuenta a la hora de proponer soluciones a la organización.
Un ejemplo es la función de recomendador, que indica al usuario la certificación que
menos recursos necesitará para llevarse a cabo satisfactoriamente.
• Elaborar informes de conformidad de los distintos procesos de la organización que
incluya las propiedades de los mismos así como los componentes principales que lo
forman (tareas, roles y productos de trabajo).
• Dará soporte a la transformación entre modelos, pudiendo representar las tareas de la
organización conforme al metamodelo BPMN en alguna herramienta de modelado de
procesos de negocio (Bizagi, BPMN Modeler, Bonita, etc.)
CAPÍTULO 2. OBJETIVOS DEL PFC
2.2
11
Funcionalidad General de la Herramienta
Con el fin de cumplir los objetivos especificados en el apartado anterior, la herramienta estará
formada por cuatro bloques principales de funcionalidad:
1. En primera instancia se necesitará un bloque encargado de proveer a la herramienta EPF
Composer de una Librería de Método que contenga todos los elementos que componen
los distintos marcos de referencia almacenados en ARMONÍAS-DGS.
2. Será necesario incorporar a la base de datos el/los procesos que previamente hayamos
definido en la herramienta EPF Composer.
3. Dará soporte a la visualización gráfica de la conformidad de los procesos respecto de
los distintos marcos de referencia.
4. Un cuarto bloque que se encargará de las transformaciones entre procesos UMA y
BPMN y de su representación en algún framework de modelado de Procesos de Negocio
(Bonita, Bizagi, BPMN Modeler, etc.)
Además de las funcionalidades ya mencionadas la herramienta necesitará satisfacer unos
requisitos no funcionales:
• Portabilidad: La ejecución de la herramienta debe ser independiente de la plataforma,
es por eso que se ha escogido la opción de una aplicación Web; de esta manera la
posibilidad de la ejecución de la herramienta únicamente la limita la necesidad de una
conexión a Internet y la de un equipo con un navegador instalado.
• Usabilidad: Dada la complejidad de los conceptos tratados en la herramienta ésta debe
de ser intuitiva, automatizando los máximos procesos posibles y deberá ser acompañado
de un manual de usuario incluido en el presente documento con el objetivo de facilitar
en la medida de lo posible el trabajo a los usuarios.
• Disponibilidad La herramienta deberá estar disponible para su uso cuando se necesite,
es por eso que se desarrollará mediante una plataforma web, con acceso 24/7.
12
2.3. DESTREZAS A ADQUIRIR
• Accesibilidad: La herramienta deberá proporcionar un fácil acceso al servicio. Este es
otro de los motivos por los que se ha escogido el paradigma de una herramienta web.
El sistema estará accesible en cualquier posición geográfica, previa identificación del
usuario en el mismo.
• Escalabilidad: La herramienta deberá estar implementada teniendo en cuenta las
posibles necesidades que el crecimiento de la misma puedan ocasionar.
2.3
Destrezas a adquirir
1. Ser capaz de llevar a cabo un proyecto, desde la recogida de requisitos hasta la implementación de los mismos, pruebas y posterior mantenimiento.
2. Aplicación de Patrones de Diseño para que la arquitectura sea robusta y extensible [37].
3. Aprender la metodología de OpenUP aplicándola al desarrollo de la herramienta.
4. Adquirir destreza con el framework de desarrollo Struts2, suponiendo un nuevo paradigma de implementación usando el patrón Modelo-Vista-Controlador.
5. Conocer herramientas CASE utilizadas para definir los procesos, así como para representarlos gráficamente, conociendo de qué manera almacenan los datos.
6. Adquirir aptitudes en ramas transversales como es el caso de la tecnología Web. Lo que
conlleva al conocimiento de lenguajes y tecnologías asociadas como JSP, Strut2, XML,
HTML, Java Script, CSS3, etc.
7. Afianzar e incrementar conceptos de la rama de Ingeniería del Software, como pueden
ser los Procesos, Estándares, Gestión de Procesos, Metodologías de Desarrollo, etc.
8. Estudiar los modelos de referencia con sus respectivos modelos de evaluación del área
de Procesos Software.
9. Analizar el contexto real en el que se encuentran los procesos en las organizaciones y
los mecanismos para determinar un valor objetivo de correspondencia con los modelos
de referencia.
10. Estudiar mecanismos de intercambio de información entre herramientas heterogéneas.
CAPÍTULO 2. OBJETIVOS DEL PFC
13
11. Conocimientos de herramientas de Correspondencia Objeto-Relacional (ORM), en este
caso la herramienta Hibernate.
12. Conocimiento de los metamodelos SPEM v2.0 y BPMN así como de éste último los
metamodelos que le sirven como apoyo (BPMNDI, DC y DI).
13. Adquirir competencias en desarrollo software dirigido por modelos, en particular en
tecnologías MDA (modelos, metamodelos, transformaciones).
14. Adquirir la destreza para llevar a cabo el control de versiones, realizando la gestión de
la configuración mediante un repositorio remoto GIT.
Capítulo 3
Estado de la Cuestión
En este capítulo se presentan los conocimientos derivados de la construcción de la herramienta.
En primer lugar se profundizará en el concepto de proceso software, el cual constituye una
base fundamental para el presente TFG, siendo el dominio sobre el cual el sistema tendrá
cabida.
Después se tratarán varios conceptos, como la relación del presente TFG con la Ingeniería
de Procesos Software, con los metamodelos SPEM, UMA y la herramienta EPFC, se realizará
una breve introducción en los modelos de referencia y mejora de procesos software más
importantes en la industria, el paradigma de la armonización y conformidad de procesos así
como el desarrollo de software dirigido por modelos y las herramientas existentes relacionadas
con la conformidad de procesos software.
16
3.1. PROCESOS SOFTWARE
3.1
Procesos Software
La Ingeniería del Software, desde un origen, se ha centrado principalmente en las metodologías de desarrollo, en los lenguajes de programación, en los modelos de desarrollo y en las
herramientas que la apoyan. No obstante su complejidad, ha hecho necesario tener en cuenta
aspectos organizacionales y de gestión en la elaboración del producto, es por eso que surge la
denominada Ingeniería del Software Basada en el Proceso [74].
Básicamente un Proceso Software es un conjunto coherente de políticas, estructuras
organizacionales, tecnologías, procedimientos y artefactos que son necesarios para concebir,
desarrollar, empaquetar y mantener un producto software [36].
Como podemos observar en la definición anterior, un proceso se compone de varios
elementos muy próximos a la organización, y es por eso que se hace necesaria una gestión de
todos ellos denominada Gestión de Procesos.
La Gestión de Procesos [57] es vital para las organizaciones, pues éstas son tan eficientes
como lo sean sus procesos. Para lograr una buena Gestión de Procesos una organización debe
asumir cuatro responsabilidades sobre los mismos: Definir, Medir, Controlar y Mejorar el
Proceso. (Figura 3.1)
• Definición del Proceso: El primer paso es la definición del mismo. Para ello deberemos
modelarlos, representando los elementos oportunos.
• Ejecución y Control del Proceso: Los proyectos software de una organización se
llevan a cabo de acuerdo a los modelos de procesos definidos. Por eso es importante
poder controlar en todo momento la ejecución de los proyectos. Para esta labor se han
desarrollado los Entornos de Ingeniería del Software orientado a Procesos (PSEE).
• Medición y Mejora: Es clara la correlación entre estos dos términos. Antes de poder
mejorar un proceso es necesario llevar a cabo una evaluación, la cual necesita de una
medición. Con los resultados de ésta es posible disponer de una información objetiva
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
17
que permita planificar, identificar y llevar a cabo de una manera eficiente las acciones
de mejora.
A continuación se presenta una imagen que ilustra las etapas clave en la gestión del
proceso anteriormente nombradas, junto con sus interrelaciones.
Figura 3.1: Etapas Clave de la Gestión del Proceso Software [57].
Para modelar los procesos de una organización, decidiremos qué elementos forman parte
del proceso y sus interrelaciones. Con el fin de sistematizar el procedimiento de definición el
proceso será conveniente utilizar unos patrones bien formados, denominados metamodelos.
Aunque trataremos el término en más profundidad en la Sección 3.7, básicamente un
metamodelo es un modelo del lenguaje que captura las propiedades y características esenciales. Esto incluye los conceptos de lenguaje que lo apoya y/o la sintaxis gráfica junto con la
semántica [31].
El término anterior unido a la creciente complejidad de los sistemas actuales hacen necesarias un conjunto de reglas y herramientas con las que visualizar el sistema a construir. Este
paradigma es conocido como Modelado de Sistemas Software.
El modelado de Sistemas Software trajo consigo una cantidad notable de Lenguajes de
Modelado, no obstante el más conocido en la actualidad y respaldado por el OMG es el
18
3.2. INGENIERÍA DE PROCESOS SOFTWARE
Lenguaje Unificado de Modelado (UML, por sus siglas en inglés, Unified Modeling Language), dicho lenguaje se explica con más profundidad en la sección del método de trabajo
correspondiente (Sección 4.2.4.1).
El paradigma del modelado influyó de manera notable también en el área de los Procesos
Software. El aprovechamiento de este concepto por parte de las organizaciones puede dotarla
de una posición privilegiada respecto al resto. Por ejemplo, una organización, a partir de los
modelos de Procesos definidos puede realizar una simulación de la ejecución de éstos que
evaluará el impacto de la toma de decisiones en un periodo de tiempo sensiblemente menor
que si se ejecutaran de manera real. De esta manera se abre un mayor número de alternativas,
pues en unos pocos minutos podremos obtener resultados que de otra manera nos llevarían
semanas, meses o años. Esta opción, además de rápida, ofrece unas ventajas significativas en
cuanto a costes se refiere, comparado por ejemplo, con el tratamiento de “prueba y error”.
No obstante, hay algunas desventajas que pueden dificultar la labor del modelado. La
dificultad intrínseca del mismo puede no capturar todos los elementos del proceso así como
sus relaciones y dependencias. Es por eso que el encargado del modelado de procesos de una
organización deberá tener un alto grado de preparación y experiencia para elaborar nuevos
modelos e interpretar las salidas de éstos.
3.2
Ingeniería de Procesos Software
Según lo expuesto en la sección anterior, modelando los procesos de la organización obtenemos una visión con un nivel de abstracción que nos permitirá controlar cada uno de los
aspectos de la misma en cuanto a procesos se refiere, redundando en una mejora de la calidad
de los productos. Además el modelado supone la apertura de nuevas perspectivas que se
derivan de que los procesos se manejan (representan, definen, publican, etc) de una manera
mucho más eficiente, suponiendo una ventaja a la hora de la certificación de los modelos [62].
Hay varias maneras de expresar los procesos de una organización, no obstante la forma
en la que se publican determina en gran medida el uso posterior que podrán recibir. En el
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
19
caso de que el/los procesos se presenten en forma de documento de texto con una descripción
detallada de los mismos, únicamente podremos hacer uso de esta presentación para apoyarnos
en la gestión de los mismos.
Por el contrario, si la información del proceso está soportada por un metamodelo y representada mediante un formato de intercambio estándar, como por ejemplo XML (siglas de
eXtensible Markyp Language), será posible realizar cualquier tipo de procesamiento automático, y el intercambio de esta información entre las distintas herramientas del mercado propias
de este paradigma será mucho más accesible.
Es decir, la forma en la que el Proceso se presenta puede determinar la transformación
de una visión Contemplativa a una Productiva, lo que genera múltiples posibilidades a la
Ingeniería de Procesos Software, de las cuales la organización puede obtener sustanciosas
ventajas. Algunas de ellas son [62]:
• Poder integrar varios Procesos Software , cada uno con su modelo.
• Dar soporte a la mejora de Procesos Software.
• Facilitar la evolución del modelo de un Proceso Software.
• Gestionar de forma integrada el proceso y su ciclo de vida (diseño, despliegue, ejecución,
automatización, mejora, etc.)
• Facilitar la construcción de plataformas más potentes de cara a la gestión de procesos y
la gestión de proyectos.
• Permitir que el repositorio de procesos sea más genérico y tenga más capacidad semántica. Esto significa facilitar técnicamente la gestión del conocimiento relacionado con
los procesos.
• Permitir que todas las herramientas (CASE, gestión de proyectos, etc.) compartan los
modelos.
• Generar la plantilla del plan de un proyecto.
• Realizar procesamiento y transformaciones directamente sobre los modelos.
20
3.3. SPEM Y EPFC
• Reutilizar mediante diferentes mecanismos de herencia fragmentos de métodos y
procesos.
• Disponer de distintas vistas de un proceso y diferentes versiones de una familia de
procesos.
• Facilitar la generación de información on-line para formación de recursos humanos
Un ejemplo de la aplicación de este paradigma es el caso de la herramienta EPFC, men-
cionada con anterioridad, que da soporte a la representación de procesos software conforme al
metamodelo UMA (compatible con SPEM 2.0). Ello permite, por ejemplo, a la herramienta
EPFC procesar la información de los modelos y publicar automáticamente en formato Web la
información necesaria sobre los procesos de la Organización, favoreciendo así la transmisión
de conocimiento entre los involucrados. En la siguiente sección se describe con mayor detalle
SPEM 2.0 (junto con el Metamodelo UMA) y EPFC.
3.3
SPEM y EPFC
UMA es el lenguaje de modelado que soportará la definición de procesos en la herramienta
de modelado EPFC. La Arquitectura de Método Unificado o Unified Method Architecture
(UMA) , es un metamodelo basado en SPEM 2.0 que permite generar modelos compatibles
con éste. UMA surgió de la necesidad de simplificar SPEM 2.0 para aquellas labores en las
que no se necesitaba de tanta granularidad a la hora de definir los procesos. No obstante
hablaremos de SPEM 2.0 en esta sección, pues comparten la mayoría de los componentes y
es el metamodelo original.
SPEM 2.0, siglas de (Software & Systems Process Engineering Metamodel Specification),
es un metamodelo utilizado para definir modelos (instancias de los metamodelos) de procesos
software. Dota al estado de la cuestión con una guía con la que homogeneizar la terminología
existente entre los lenguajes de modelado de procesos software en los conceptos tratados con
nombres diferentes.
El metamodelo SPEM 2.0 propone unos elementos mínimos sobre los cuales cabe la
posibilidad de definir los procesos, estos son: los roles, los productos de trabajo y las tareas. A
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
21
continuación, en la Figura 3.2, se ilustra con una imagen los elementos nombrados, así como
las interrelaciones entre los mismos.
Figura 3.2: Conceptos centrales de SPEM 2.0. [63]
Además de un metamodelo que apoya la ingeniería de procesos, SPEM 2.0 es un marco de
trabajo que proporciona la estructura para modelar, documentar, presentar, publicar, gestionar,
intercambiar y realizar métodos y procesos software.
22
3.3. SPEM Y EPFC
La Figura 3.3 representa el marco de trabajo anteriormente mencionado. A continuación
enunciaremos los usos principales de SPEM 2.0.
Figura 3.3: Usos básicos SPEM 2.0. [63]
A continuación se explicarán de manera detallada los usos de la figura anterior [57]:
• Proporcionar un repositorio de conocimiento en forma de “Contenido de método”, entendiéndose éstos como un conjunto de unidades de trabajo reutilizables (una colección
organizada de roles, tareas, productos de trabajo, guías, etc). Así, el Ingeniero de Procesos se apoyará en este conocimiento para componer los procesos de la organización.
• Una guía para todo el equipo que servirá como pauta para soportar el desarrollo, la
gestión y el conocimiento de los procesos software. A medida que el proyecto software
avanza, los distintos grupos de trabajo que forman parte del desarrollo del proyecto
deben conocer y saber aplicar los métodos de desarrollo y el conjunto de prácticas
óptimo a adquirir a lo largo del ciclo de vida. SPEM 2.0 nos proporciona un marco de
trabajo idóneo para la compartición de conocimiento, presentándolo de una manera
organizada y ofreciendo frameworks que soporten este paradigma (por ejemplo el
utilizado en este desarrollo, EPFC).
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
23
• SPEM 2.0 nos permite definir distintas configuraciones del contenido de método dependiendo de las características del proyecto. Teniendo en cuenta que exactamente el
mismo proceso no se ejecuta dos veces de manera idéntica, es útil definir el despliegue
del contenido de método y proceso que se necesita en cada caso.
• Dar soporte a la realización de un proceso para llevar a cabo los proyectos de desarrollo concretos [57]. Lo cual permite a los jefes de proyecto contar con información
del mismo y abstraerse de la complejidad del mismo para definir los planes del proyecto.
Una vez tratados los propósitos del mismo, nos centraremos en la estructura interna del
metamodelo para comprender los elementos que lo conforman y su interrelación. En SPEM
2.0 se distinguen dos grupos conceptuales claramente diferenciados, una parte denominada
contenido de Método o “Method Content”, que albergará los elementos que componen sus
procesos, como pueden ser las tareas, los roles que llevan a cabo éstas, las herramientas que
intervienen para su correcta realización, etc. Y por otro lado un componente denominado
“Procesos” o Process, que se apoyará en el anterior, definiendo los procesos de la organización a partir de la combinación de elementos del contenido de método. Los elementos que
componen los procesos se dice que están en uso, por tanto este apartado está formado por
Tareas en uso, Roles en uso, etc.
En la Figura 3.4 se muestran los dos conceptos anteriores. Además se puede ver que ambos
están unidos por elemento común denominado guía o Guidance en inglés, cuyo cometido
será proporcionar información adicional a cualquiera de los dos grupos mencionados con
anterioridad, asumiendo una función contemplativa.
24
3.3. SPEM Y EPFC
Figura 3.4: Elementos de SPEM 2.0 [63].
3.3.1
Visión del metamodelo SPEM 2.0
SPEM 2.0 utiliza UML como notación gráfica para describir su metamodelo, adoptando un
enfoque orientado a objetos, y definiendose en términos de paquetes, con fines de reutilización
y organización [57]. SPEM 2.0 se organiza en una jerarquía de 7 paquetes, en los que los
hijos extienden la funcionalidad del padre, aportando algunas funcionalidades adicionales.
Dependiendo de las intenciones del modelado y el nivel de completitud deseado, puede
hacerse uso de todos los paquetes o del subconjunto necesario en cada caso. A contiuación
se presentan las funcionalidades básicas de cada paquete así como la Figura 3.5 en la que
podremos observar su jerarquía.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
25
Figura 3.5: Estructura de paquetes de SPEM 2.0 [57].
A continuación pasaremos a detallar cada uno de los paquetes:
• Core: Contiene las clases y abstracciones que sirven de base para las clases de los
demás paquetes del metamodelo.
• Process Structure: Contiene las clases necesarias para la creación de modelos de
procesos.
• Managed Content: Nos va a permitir dotar a nuestros procesos o sistemas de anotaciones y descripciones que no pueden ser expresadas como modelos y que por tanto
deben ser documentadas y gestionadas como descripciones en lenguaje natural.
• Method Content: Contiene los conceptos de SPEM 2.0 relacionados con los usuarios y
su organización. Estos conceptos son necesarios para construir la base de conocimiento
sobre desarrollo que pueda ser utilizada independientemente del proceso o proyecto
específico.
26
3.3. SPEM Y EPFC
• Process With Methods: Contiene los elementos necesarios para integrar los conceptos
del paquete “Process Structure” con los conceptos y elementos del paquete “Method
Content”.
• Method Plug-In: Introduce los conceptos para diseñar, gestionar y mantener repositorios y librerías de “Methods Content” y Procesos.
Como hemos enunciado en el Capítulo 2 uno de los objetivos de COMPROMISE es
proporcionar al ingeniero de procesos una fuente de conocimiento almacenable y disponible
en todo momento. Es por eso que nos centraremos en el paquete del contenido de método, el
cual dispone de los siguientes constructores básicos [57]:
• Tarea (Task Definition): Es el nivel atómico de descomposición de los procesos. Está
relacionado con:
– Uno o más Roles que realizan la tarea
– Uno o más Productos de Trabajo que pueden ser definidos como entradas obligatorias, opcionales o salidas.
– Cero o más Herramientas que se recomiendan usar para la realización de la tarea.
– Cero o más Pasos que describen de forma secuencial el trabajo a realizar.
– Cero o más Habilidades que se requieren para llevar a cabo la tarea.
• Paso (Step): Descompone la tarea en unidades más pequeñas en caso de que se necesite
una granularidad mayor a la hora de elaborar dicha tarea, aunque por sí mismas no
tienen valor dentro del proceso. Cabe destacar que a la hora de definir los pasos de una
tarea, estos no tienen por qué ejecutarse cada vez que se lleve a cabo, pues se podrá
implementar siguiendo diferentes combinaciones de los mismos. Es por eso que los
datos se pueden expresar como flujos de trabajo alternativos. Hay varios tipos de pasos
que se pueden considerar dentro de una tarea.
– Pensamiento o Thinking steps, en los que la finalidad es que el rol comprenda la
tarea y examine todos los artefactos de entrada y formula un resultado (outcome).
– Realización (Performing steps), en los que el usuario crea o modifica algunos
artefactos.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
27
– Revisión (Reviewing steps), en los que los roles inspeccionan los resultados
respectos a unos criterios.
• Producto de trabajo (Work Product Definition): Son los elementos del contenido de
método de los cuales hacen uso, modifican y producen las tareas. A su vez los productos
de trabajo pueden estar relacionados con otros. Existen los siguientes tipos:
– Artefacto (artifact): Define un producto de trabajo tangible, como puede ser un
modelo, documento, código fuente, etc. Éste a su vez puede estar compuesto por
otros artefactos.
– Entregable (deliverable): Representa un entregable de valor para el usuario o
cliente.
– Resultado (outcome): Se utilizan para representar productos de trabajo que no
están formalmente definidos. Los resultados de éstos no son reutilizables.
• Rol (Role Definition): Define un elemento con un cojunto de habilidades, competencias
y responsabilidades de una persona o un conjunto de personas. Una persona no es un
rol, un individuo puede desempeñar varios roles dependiendo de sus competencias o un
rol puede estar desempeñados por varias personas.
• Cualificación(Qualification): Documenta las aptitudes, habilidades y competencias por
parte de los roles para la realización de las tareas. En el presente TFG no haremos uso
de este elemento.
• Herramienta (Tool): Describe las capacidades de una herramienta CASE, o de propósito general, o de cualquier otra unidad automatizada de apoyo para realizar las tareas
por parte de los roles.
• Categoría (Category): Permite agrupar cualquier número de elementos describibles de
cualquier subtipo en base a unos criterios. Una categoría puede anidarse estableciéndose
jerarquías. Las categorías estándar son:
– Disciplina (Discipline): Permite categorizar el trabajo (tareas). Una disciplina es
una colección de tareas que están relacionadas dentro de una determinada área de
interés de un proyecto.
28
3.3. SPEM Y EPFC
– Conjunto de Roles (Rol Set): Agrupa roles que tienen algo en común como el
hecho de usar técnicas similares, requerir habilidades parecidas, etc.
• Guía (Guidance) proporciona información adicional a cualquier elemento describible.
Existen diversos tipos de guías:
– Guías (guidelines)
– Listas de comprobación (checklist)
– Plantillas (templates)
– Informes (reports)
– Estimaciones (estimates)
• Métrica (Metric), define una medición estándar para las instancias de cualquier elemento descriptible en SPEM 2.0, como por ejemplo las horas de esfuerzo para una
tarea.
3.3.2
Eclipse Process Framework Composer (EPFC)
SPEM 2.0 proporciona un contexto en el que definir nuestro proceso junto con todos sus
elementos y componentes. No obstante, sería precipitado pensar en una definición de procesos
software complejos y a su vez abordables de manera manual siguiendo dicho metamodelo,
pues su dificultad seguramente lo impediría. Es por eso que se hace necesario el uso de
herramientas que permitan la visualización, almacenamiento y composición de los procesos
de una organización, así como de sus elementos más importantes. Con tal fin se creó Eclipse
Process Framework Composer, cuyas siglas EPFC dan nombre al Framework en la mayoría
de los casos.
EPFC es una herramienta gratuita, desarrollada en el entorno Eclipse y que sirve para
editar fragmentos de método, procesos o metodología y generar automáticamente la documentación pertinente en formato Web, entre otras funcionalidades.
La completitud y granularidad del metamodelo SPEM 2.0 no era necesaria para la gestión
de los procesos en la herramienta, es por eso que ésta utiliza como lenguaje de modelado
la Arquitectura de Método Unificado (Unified Method Architecture, UMA), basada en el
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
29
metamodelo SPEM 2.0, motivo por el cual EPFC es capaz de generar modelos compatibles
con SPEM 2.0.
El primer paso con EPFC es definir el contenido de método con todos los elementos
disponibles para su posterior utilización en la definición de los procesos. Aunque para
el funcionamiento de nuestro TFG es un paso fundamental, que la herramienta realizará
automáticamente, poblar el contenido de método no es estrictamente obligatorio para las
organizaciones, aunque si nos permite tener la base de conocimiento mencionada en la
Sección 3.3.1 con todos los elementos definidos por la organización. Además nos facilitará la
definición de nuestros procesos basándonos en una continua reutilización del Contenido de
Método propio de cada organización, de esta manera también será menos propenso a errores,
pues se utilizarán tareas predefinidas (en la mayoría de los casos probadas con anterioridad)
que incluiremos en el proceso a definir.
Figura 3.6: Ejemplo gráfico del contenido de método definido con EPFC.
Además, como vemos en la Figura 3.6, los elementos del contenido de método se englobarán dentro de subcategorías según su naturaleza, separando así entre tareas, disciplinas, guías,
etc; tal y como enunciábamos en la sección anterior.
30
3.3. SPEM Y EPFC
Un paso posterior a determinar el contenido de método del que dispondrá la organización,
será la definición del proceso con todos los componentes que intervienen en el mismo, así
como sus interrelaciones. A continuación, en la Figura 3.7 se ilustra la jerarquía de elementos
de un proceso definidos en SPEM 2.0:
Figura 3.7: Jerarquía de los elementos de SPEM 2.0 en la definición de Procesos [57].
EPFC cuenta con una interfaz sencilla e intuitiva que permite al ingeniero de procesos
estructurar un proyecto mediante una estructura de descomposición de trabajo (EDT), tal
como se ilustra en el ejemplo de la Figura 3.8.
Figura 3.8: Definición del proceso con EPFC
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
31
Este paso es muy importante a la hora de controlar nuestro proceso y medirlo, y es eso
por lo que cada vez este tipo de herramientas están cobrando mayor importancia, pues juegan
un papel fundamental a la hora de la certificación en los distintos marcos de referencia del
mercado [57]. En la siguiente sección se presentan algunos modelos de referencia.
3.4
Modelos de Referencia y Mejora de Procesos Software
En este apartado se presentan los modelos de referencia más importantes por su implicación
en el presente TFG. En COMPROMISE, es objetivo que estos modelos pueblen el contenido
de método de EPFC, aunque como ya hemos comentado anteriormente no es estrictamente
necesario para las organizaciones, pues podrán crear tareas que no estén sujetas a ningún modelo de referencia. No obstante sí que es recomendable, pues de este modo las organizaciones
tendrán sus tareas completamente alineadas con los estándares del mundo empresarial.
3.4.1
CMMI
CMMI es un modelo desarrollado por el SEI (siglas de Software Engineering Institute) o
Instituto de Ingeniería de Software, para la mejora y evaluación de los procesos basándose en
que la calidad de los productos es consecuencia directa de la calidad de los procesos que lo
desarrollan [57].
Para ello, el framework CMMI provee a las organizaciones de un conjunto de Áreas Clave
de Proceso (KPA - Key Process Area). Dichas áreas a su vez se agrupan en cinco niveles de
madurez, de modo que una organización que posea un nivel de madurez determinado, con
todas las áreas clave del proceso satisfechas además de ese nivel, también se considera que
cumple los anteriores.
La disposición de las organizaciones según su nivel de madurez, como hemos dicho, se
basa en la calidad de sus procesos y como consecuencia en la calidad que es capaz de ofrecer
con sus productos resultantes.
CMMI define cinco niveles de madurez [67]:
• Inicial: En un origen todas las organizaciones están en este nivel. En él no disponen de
32
3.4. MODELOS DE REFERENCIA Y MEJORA DE PROCESOS SOFTWARE
un ambiente estable para el desarrollo y mantenimiento Software.
• Repetible: En este nivel las organizaciones disponen de unas prácticas institucionalizadas de gestión de proyectos además de unas métricas estándar con un nivel básico de
seguimiento de la calidad.
• Definido: A este nivel las organizaciones poseen procedimientos funcionales de coordinación entre grupos, formación del personal y son capaces de medir sus procesos.
• Gestionado: En este nivel las organizaciones poseen un conjunto de métricas significativas de la calidad y productividad que se usan de modo sistemático en la toma de
decisiones.
• Optimizado: Se hace uso intensivo de las métricas y se persigue la innovación del
proceso mediante la continua mejora de sus procesos. Son muy pocas las organizaciones
que se encuentran en este nivel de madurez.
Debido a la aceptación del modelo y a la heterogeneidad de las posibles aplicaciones,
el SEI propone tres especializaciones de CMMI para soportar las diferentes prácticas. Los
diferentes ámbitos (adquisición, desarrollo y servicios) se resumen brevemente a continuación
nombrados por sus siglas:
• CMMI-ACQ: Proporciona un conjunto de buenas prácticas para el cliente con el fin
de controlar la adquisición de productos y servicios.
• CMMI-DEV: Cubre actividades de desarrollo y mantenimiento respecto de productos
y servicios.
• CMMI-SVC: Provee a las organizaciones de una guía para proveer servicios tanto a
clientes externos como dentro de la propia organización.
3.4.2
ISO/IEC 12207
Este estándar internacional establece un marco común para los procesos del ciclo del software
con una terminología bien definida y conocida que puede ser referenciada por la Industria del
Software.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
33
La norma ISO/IEC 12207 fue publicada en Agosto de 1995 por el International Organization for Standardization (ISO) y por el International Electrotechnical Commision (IEC).
Establece la arquitectura que da cabida a los procesos y a sus interrelaciones. Abarca todo el
ciclo de vida y aboga por una descomposición del proceso en actividades, implementadas a
partir de un conjunto de tareas, siendo éstas un elemento atómico [12].
Dichos procesos, actividades y tareas se aplican durante el suministro, desarrollo, operación y mantenimiento de productos software. Además la norma deja cierta libertad a las
organizaciones para definir cómo ejecutar el proceso, de esta manera la norma proporciona la
flexibilidad necesaria para que los países o las organizaciones la implementen de acuerdo a
los recursos disponibles y a las prácticas propias de cada posición geográfica en caso de que
se necesite.
Este Estándar Internacional puede ser usado para los siguientes propósitos:
• Por una Organización: Para ayudar a establecer los procesos deseados. Estos procesos
pueden ser soportados por una infraestructura de métodos, procedimientos, técnicas,
herramientas y personal entrenado.
• Por un Proyecto: Para ayudar a seleccionar, estructurar y emplear los elementos de un
ciclo de vida establecido con el fin de proveer productos y servicios. En este modo, el
estándar es usado para asegurar la conformidad del proyecto.
• Por un Proveedor o Cliente : Para ayudar a desarrollar los procesos y actividades
acordados previamente entre ambos. Mediante este acuerdo, los procesos y actividades
son seleccionados, negociados, aprobados y realizados. En este propósito el estándar es
usado como guía en el desarrollo de dicho acuerdo.
• Por Organizaciones y Asesores: En este propósito el estándar es usado para realizar
evaluaciones de los procesos de la organización.
A continuación, en la Figura 3.9 se encuentran todos los procesos que conforman la norma
ISO/IEC 12007:2008 categorizados y agrupados:
34
3.4. MODELOS DE REFERENCIA Y MEJORA DE PROCESOS SOFTWARE
SYSTEM CONTEXT PROCESSES
Agreement
Process
Project
Processes
Technical
Processes
SW Implementation
Process
SW Support
Process
Project Planning Proceses
Stakeholder
Requirements Definition
Process
Software Implementation
Process
Software Documentation
Management Process
(Clause 7.1.1)
(Clause 7.2.1)
Acquisition Process
(Clause 6.1.1)
SOFTWARE SPECIFIC PROCESSES
(Clause 6.3.1)
(Clause 6.4.1)
Supply Process
(Clause 6.1.2)
Project Assesment and
Control Process
(Clause 6.3.2)
Organizational
Project-Enabling
Processes
Life Cycle Model
Management Process
(Clause 6.2.1)
System Architectural
Design Process
(Clause 6.4.3)
Risk Management
Process
Implementation
Process
(Clause 6.3.4)
(Clause 6.4.4)
Configuration Management
Process
(Clause 6.3.5)
System Integration
Process
Information Management
Process
(Clause 6.3.6)
System Qualification
Testing Process
Project Portfolio
Management Process
(Clause 6.2.3)
(Clause 6.4.5)
(Clause 6.4.6)
System Instalation Process
Measurement Process
Human Resource
Management Process
(Clause 6.4.2)
Decision Management
Process
(Clause 6.3.3)
Infraestructure
Management Process
(Clause 6.2.2)
System Requirements
Analysis Process
(Clause 6.3.7)
(Clause 6.2.4)
(Clause 6.4.7)
Software Requirements
Analysis Process
(Clause 7.1.2)
Software Configuration
Management Process
(Clause 7.2.2)
Software Architectural
Design Process
(Clause 7.1.3)
Software Quality
Assurance Process
(Clause 7.2.3)
SoftwareDetailed Design
Process
Software Verification
Process
(Clause 7.1.4)
(Clause 7.2.4)
Software Construction
Process
(Clause 7.1.5)
Software Integration
Process
(Clause 7.1.6)
Software Qualification
Testing Process
(Clause 7.1.7)
Software Validation
Process
(Clause 7.2.5)
Software Audit Process
(Clause 7.2.6)
Software Problem
Resolution Process
(Clause 7.2.7)
Software Acceptance
Support Process
(Clause 6.4.8)
Quality Management
Process
(Clause 6.2.5)
Software Operation Process
Software Reuse Processes
(Clause 6.4.9)
Software Mantenace
Process
(Clause 6.4.10)
Software Disposal
Process
(Clause 6.4.11)
Domain Engineering
Process
(Clause 7.3.1)
Reuse Program
Management Process
(Clause 7.3.3)
Reuse Asset
Management Process
(Clause 7.3.2)
Figura 3.9: Procesos ISO 12207
3.4.3
ISO/IEC 9000
Es un conjunto de buenas prácticas que se ocupa de la gestión de la calidad en las organizaciones. Su primera publicación tuvo lugar en 1987 y cumpliendo con la norma ISO, que obliga a
que todas las normas sean revisadas al menos cada cinco años, tendrá su próxima revisión en
2015. Actualmente, la familia ISO 9000 se compone de cuatro normas [57]:
• UNE-EN ISO 9000 - Sistemas de gestión de la calidad. Funcionamientos y vocabulario
• UNE-EN ISO 9001 - Sistemas de gestión de la calidad. Requisitos
• UNE-EN ISO 9004 - Gestión para el éxito sostenido de una organización. Enfoque de
gestión de la calidad.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
35
• UNE-EN ISO 19011 - Directrices para la auditoría de sistemas de gestión de la calidad
y/o medioambiental.
Básicamente especifica los requisitos para un sistema de gestión de la calidad cuando
necesita demostrar su capacidad para proporcionar regularmente productos con requisitos
que satisfagan al cliente o aumentar la satisfacción del cliente aplicando los procesos para la
mejora continua del sistema.
3.4.4
ISO 90003
Proporciona una guía a las organizaciones para la aplicación de la norma ISO 9001 para la
adquisición, apoyo, desarrollo, operaciones y mantenimiento de los procesos software y los
servicios necesarios. Dicha norma no añade o cambia nada de los requisitos de la norma ISO
9001 [57].
Las guías de la norma ISO/IEC 90003:2004 no están destinadas a ser utilizados como
criterios de evaluación en el sistema de gestión de calidad.
Para cumplir la norma, las organizaciones no tienen por qué implementar todas las
actividades, sino que pueden centrarse en algún área a mejorar. La norma aborda las cuestiones
que deben tratarse y es independiente de la tecnología, los modelos de ciclo de vida, los
procesos de desarrollo, la secuencia de actividades y la estructura de la organización.
3.5
Armonización
Como hemos comentado en el capítulo de Introducción existen numerosos marcos de referencia, los cuales proveen a las organizaciones de un conjunto de buenas prácticas que permiten
a las mismas disponer de un conocimiento adicional a la hora de elaborar sus procesos.
Dada la gran cantidad de modelos de referencia (Figura 1.1), algunos de ellos expuestos
en la sección anterior, y los propósitos tan diversos de los mismos puede ocurrir que elegir
adecuadamente el modelo que agrupe todos los requisitos necesarios sea una tarea ardua.
Es por eso que muchas organizaciones encuentran la solución al problema mediante la
Armonización de procesos de distintos marcos de referencia, surgiendo así el paradigma
de los Ambientes Multimarco. Según [53] los ambientes multimarco surgen cuando una
organización decide o necesita integrar a sus procesos diversas prácticas o características no
36
3.5. ARMONIZACIÓN
presentes en uno, sino en varios marcos.
Dado el estado de la cuestión actual en este área unido al desconocimiento de la manera
de proceder de las organizaciones, es común que las prácticas que utilicen para lograr la
armonización de distintos marcos de procesos no sea la adecuada, imposibilitando la tarea y
convirtiéndose en una práctica poco menos que intratable.
Es por eso que desde el grupo de investigación Alarcos de la Escuela Superior de Informática de Ciudad Real, César Pardo ha llevado a cabo una tesis doctoral [53] con el nombre de
A Famework to Support the Harmonization between Multiple Models and Standards,
que da soporte a la resolución de esta problemática y que describiremos a continuación,
nombrando los componentes más significativos de la misma.
3.5.1
HFramework
La tesis HFramework, llevada a cabo por César Pardo en el Grupo de Investigación Alarcos
de la Escuela Superior de Informática de Ciudad Real, trata la problemática existente en el
proceso de armonización de distintos marcos de referencia.
Según [53] “la gran diversidad y heterogeneidad de los modelos y estándares disponibles
proporcionan a las organizaciones un ambiente positivo que les permite elegir entre diferentes
soluciones para diferentes problemas y necesidades.”
No obstante, las organizaciones tienen serias dudas a la hora de elegir el modelo o los
modelos adecuados y lo que en origen parece una ventaja para éstas se puede convertir en un
hándicap.
Es por eso que dada la problemática, dentro su tesis, Pardo propone un Framework cuyo
fin es la armonización e integración de modelos de referencia heterogéneos así como distintos
modelos de calidad y seguridad.
Para desarrollar el marco que permite esta armonizazión, HFramework se divide en tres
bloques fundamentales, los cuales proveen al marco de trabajo de todo lo necesario para
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
37
realizar la armonización. Estos bloques son los siguientes:
• Conceptual Framework: Define dos ontologías donde se almacena todo el conocimiento relacionado con la armonización de múltiples modelos. Es necesario para
comprender la complejidad derivada de alineación de éstos.
• Metodological Framework: Permite un control sistemático sobre las actividades, las
tareas y los roles que soportan el esfuerzo de la gestión y la configuración de la estrategia
de armonización de modelos heterogéneos. La parte de la metodología establece un
conjunto de Actividades englobadas en un conjunto de cuatro fases.
• Technological Environment: Está compuesta por una herramienta web que permite
al proyecto de armonización ser soportado, gestionado, controlado y monitorizado.
Ésta parte del proyecto corresponde al PFC de Francisco Romero [61], herramienta
antecedente de la presente, que será tratada en la siguiente sección.
A modo de pequeño resumen y para facilitar la comprensión al lector, los tres bloques
necesarios proveen a la organización el conocimiento (Conceptual Framework), la metodología (Metodological Framework) y el soporte (Technological Enviroment) necesarios para
la armonización de marcos de trabajo heterogéneos.
3.5.2
ARMONÍAS-DGS
Después de tratar el marco teórico se vio necesario implementar el entorno tecnológico que
diese soporte a la tesis. Ese framework, objeto del Proyecto de Fin de Carrera de Francisco
Romero [61], titulada ARMONÍAS-DGS, “Herramienta para la Armonización y Evaluación
de Calidad de Procesos en Desarrollo Global de Software” tiene como objetivo principal
“Elaborar una herramienta que de soporte a la armonización de marcos de calidad
de procesos y a la evaluación de los mismos, todo ello bajo el contexto del Desarrollo
Global de Software”[61].
Aunque en el presente Trabajo de Fin de Grado únicamente usaremos la base de datos
que provee de conocimiento a la herramienta, expondremos brevemente los aspectos más
importantes de la misma en la presente sección.
38
3.5. ARMONIZACIÓN
Figura 3.10: Esquema de HFramework [53].
ADMONÍAS-DGS posee dos componentes que dotan de funcionalidad a la herramienta
(además del componente de Administración, el cual no trataremos). Dichos componentes se
resumen brevemente a continuación:
• Componente de Armonización: Este componente se encarga de la gestión y análisis
gráfico de los proyectos de armonización y de crear una estrategia para ello. Ésta
será la parte de la cual se nutrirá nuestra herramienta, pues su base de datos posee el
conocimiento de los distintos modelos de referencia (armonizados o no) y de todos los
elementos que intervienen en los mismos. Esto nos servirá como punto de partida para
la elaboración de COMPROMISE.
• Componente de Evaluación: Por otro lado la herramienta ARMONÍAS-DGS provee
a las organizaciones de un componente de evaluación encargado de la configuración y
la gestión de las evaluaciones que llevarán a cabo.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
39
Figura 3.11: Esquema de ARMONÍAS-DGS. [61]
ARMONÍAS-DGS está englobada en el proyecto ORIGIN, cuyo objetivo es “desarrollar
un conjunto de herramientas conceptuales, metodológicas y sistemas que permitan optimizar
la fabricación de software en este tipo de escenarios, paliando los problemas de comunicación
y gestión de conocimiento y asegurando la calidad del software producido”.
Para satisfacer el objetivo anterior se desarrolla ARMONÍAS-DGS, cuya funcionalidad,
englobada en el componente tecnológico de HFramework, completa el framework de Pardo.
ARMONÍAS-DGS permite tanto la creación como la gestión de proyectos de armonización. Para ello define estrategias compuestas por tres fases relacionadas: Homogeneización,
Comparación e Integración. A partir de cuestionarios ARMONÍAS-DGS es capaz de evaluar
la calidad de los procesos Software de la organización.
Por último la herramienta posee funciones de representación de los datos, mostrando
gráficas e informes de los aspectos anteriormente comentados.
Una vez que definimos los modelos de referencia se hace saber si los procesos definidos
por una organización son implementados correctamente y conforme a dichos modelos. En
siguiente sección se exponen mecanismos para determinar la correlación entre el marco de
40
3.6. CONFORMIDAD DE PROCESOS
referencia y la definición del proceso de manera cuantificable.
3.6
Conformidad de Procesos
Las organizaciones deben definir sus procesos adecuadamente para cumplir sus objetivos
de negocio. Sin embargo, en la constante batalla de éstas por ser más competitivas y lograr
un producto de calidad, las certificaciones en distintos estándares aceptados por la industria
juegan un papel fundamental en el mercado actual.
La aplicación de los estándares determinan una serie de características del proceso que
hacen que éstos no puedan ser definidos libremente por las organizaciones, sino que es de
obligado cumplimiento la satisfacción de una serie de normas y pautas para que los procesos
de la organización sean acreditados por los organismos oficiales correspondientes.
La obtención de certificaciones suponen a las organizaciones una ventaja competitiva
notable [40], pues sus productos serán sinónimo de calidad, además permitirán el desarrollo
colaborativo entre distintas organizaciones heterogéneas y podrán expandir su mercado gracias a la estandarización.
Es por eso que a la hora de la certificación, las organizaciones deberán alinear sus procesos
tanto con sus objetivos de negocio como con los distintos estándares o modelos (CMMI,
ISO/IEC 12207, ISO/IEC 9000, etc.). Es aquí cuando tiene cabida el paradigma de la vista productiva del proceso, más concretamente la evaluación de conformidad de los procesos.
La conformidad tiene como fin cuantificar el grado de alineamiento de los procesos de la
organización para con los modelos de referencia. Es decir, provee mecanismos a las organizaciones para ponderar sus procesos en función del cumplimiento de los estándares. De esta
manera, es sencillo para las organizaciones determinar en qué grado satisfacen sus procesos
los distintos aspectos considerados por los estándares para que la calidad del producto sea
óptima.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
41
Para que esto sea posible, es necesario establecer una correspondencia entre los distintos
elementos que conforman los procesos de las organizaciones y los que componen el marco
de referencia. Constituir esta correspondencia no es una tarea sencilla puesto que requiere el
conocimiento en profundidad de ambos procesos, tanto el definido por la organización como
el del modelo de calidad. Habitualmente esta tarea no es trivial y la deben realizar personas
con una amplia experiencia en la gestión de procesos.
El concepto de conformidad es mucho más extendido en la gestión de los procesos de
negocio, no obstante en la mayoría de la bibliografía se refieren a él como Compliance,
por su traducción en inglés. Para establecer la conformidad en los procesos de negocio es
necesario establecer un conjunto de especificaciones particulares del negocio en cuestión.
Dichas especificaciones establecen las normas de ejecución que el proceso debe seguir [41].
Es por eso que la evaluación de la conformidad de los procesos de negocio y la evaluación de
los procesos software difieren significativamente.
Los procesos software son una especialización de los procesos de negocio, por lo que
comparten características comunes. Básicamente un proceso de negocio es un conjunto de
tareas interrelacionadas y que mediante la realización de las mismas en un orden determinado
se genera un producto o un servicio.
No obstante comparar ambos procesos sin los mecanismos apropiados sería imprudente,
pues a pesar de que comparten ciertos elementos, es en la ejecución del mismo cuando se
pueden ver algunas diferencias notables.
Para lograr una certificación en los modelos aceptados por por la industria, son necesarias auditorías periódicas que controlen que las directrices expuestas en los mismos son
aplicadas a la hora de que la organización mejore sus procesos. Si una organización no tiene
bien definidos sus procesos, la preparación para afrontar con éxito esa auditoría requiere un
esfuerzo adicional de todos los participantes en la organización, con el consecuente sobrecoste
para la misma. Es por eso que para reducir este umbral, usualmente traducido en labores de
consultoría, es necesario que las organizaciones definan sus procesos de una manera correcta
en un origen y tal y como los marcos de referencia exponen para cada uno de los casos.
42
3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Con el fin de evitar este problema, COMPROMISE junto con las herramientas relacionadas
en el proyecto, basan su funcionalidad en una serie de objetivos a cumplir desde el inicio de
la definición de los procesos [52]:
• Dotar a todos los integrantes de la organización con el conocimiento relacionado con
los procesos y propósitos de la misma.
• Proveer un acceso fácil al conjunto de buenas prácticas establecido.
• Proveer a los stakeholders mecanismos automáticos que apoyen la promulgación de los
procesos y sus directrices.
• Proveer mecanismos para la monitorización continua del proceso.
• Automatizar las distintas vistas del proyecto ofreciendo soluciones a los distintos
stakeholders, además de proveer a los mismos de evidencias del cumplimiento del
mismo para con el modelo en cuestión.
• Dar soporte a la preparación de la evaluación y medición del rendimiento con evidencias
recogidas automáticamente.
3.7
Desarrollo de Software Dirigido por Modelos (DSDM)
La herramienta objeto de este trabajo de Fin de Grado provee mecanismos de transformación
de modelos siguiendo el paradigma de la visión productiva del proceso mediante Ingeniería
Dirigida Por Modelos.
Los procedimientos de Desarrollo Software han ido cambiando desde los inicios de la
Ingeniería del Software hasta la actualidad. En la década de los años 1990 se popularizó el
uso de la programación orientada a objetos (POO), con las consecuentes técnicas que ésta
incluía; herencia, abstracción, polimosfismo, encapsulamiento, etc. Además, el alto nivel de
abstracción proporcionado permitía al programador obviar aspectos propios de los lenguajes
de bajo nivel, que impedían un desarrollo fluido y eran propensos a errores.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
43
Aunque el paradigma anterior sigue vigente, la complejidad del software, la cantidad
ingente de tecnologías y plataformas existentes, además de la poca expresividad que proporcionaba a la hora de la interpretación para algunos de los involucrados en el proyecto,
hizo necesario elevar notablemente el nivel de abstracción [71]. Es por eso que un nuevo
paradigma surge intentando evitar todas las desventajas anteriores, la Ingeniería dirigida por
modelos o MDE.
La Ingeniería Dirigida por Modelos es una metodología de desarrollo motivada en sus
inicios por el aumento de productividad, además de otros factores, que supone la utilización
de modelos que representan el conocimiento desde el punto de vista que proporciona un alto
nivel de abstracción.
Aunque son varias las definiciones, diremos que un modelo es la descripción de un sistema, o una parte de él, escrita en un lenguaje bien definido [72].
Según la definición anterior de modelo es necesario especificar el lenguaje en el que éste
será expresado, ese lenguaje bien definido se conoce como metamodelo. Aunque anteriormente hemos proporcionado una definición genérica del mismo, a continuación se definirá de
nuevo para contextualizar el presente apartado.
Un metamodelo es un modelo que define un lenguaje para expresar los modelos. Así
para expresar los metamodelos se utilizan meta-metamodelos. La relación entre metametamodelos y metamodelos es análoga a la relación entre metamodelos y modelos.
En la Figura 3.12 se presenta una relación gráfica entre los conceptos mencionados en el
párrafo anterior:
44
3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Figura 3.12: Arquitectura de distintos niveles de modelado[38].
Apoyadas en estos conceptos surgen una serie de técnicas englobadas dentro del MDE
(Figura 3.13), una de ellas es el Desarrollo Dirigido por modelos, que podremos encontrar en
la bibliografía con las siglas MDD o DSDM (por sus siglas en castellano).
Figura 3.13: Organización de MDE [38]
El Desarrollo de Software Dirigido por Modelos (DSDM) es un nuevo paradigma para el
desarrollo Software englobado dentro de la Ingeniería dirigida por modelos (MDE o IDM,
por sus siglas en castellano).
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
45
Una buena implementación del paradigma DSDM puede suponer una serie de beneficios
a las organizaciones. Algunos de ellos se presentan a continuación: [38]
• Mejora de la productividad. Se pasa de la idea de “Escribir una vez y ejecutar en cualquier sitio” (dependiente de la plataforma) a “Modela una vez y genera en cualquier
lugar”.
• Aumenta la calidad. Los esfuerzos del desarrollo están centrados en el dominio del
problema en lugar del dominio de la solución.
• Mejor Comprensión del sistema a desarrollar. El nivel de abstracción que proporciona
el modelado permite el mejor entendimiento a los stakeholders. “Legible para los
humanos y compatible para las máquinas” [30].
• Facilita la evolución y el mantenimiento.
Como podemos ver en la figura 3.13 el MDE está compuesta por varias iniciativas en las
que se apoya. Una de ellas es la Arquitectura Dirigida por Modelos o MDA. Lanzada por
la OMG en 2001, se trata de una arquitectura que proporciona un enfoque para desarrollar
Sistemas Software basándose en una serie de guías para estructurar sus especificaciones como
modelos.
El MDA está motivados por unos principios que se exponen a continuación [38]:
• Modelos expresados en una notación bien definida.
• La construcción de sistemas puede ser organizada en torno a un conjunto de modelos
sobre los que se han definido unas transformaciones.
• La organización de la arquitectura en capas y transformaciones facilita la integración y
transformación entre modelos, que es la base para lograr la automatización mediante
herramientas.
• La aceptación de este paradigma requiere estándars implementados por la industria.
Como podemos ver en la Figura 3.14, en las transformaciones hay cuatro pasos fundamentales, descendientes sucesivamente en nivel de abstracción, cuyo último hito es el código
generado.
46
3.7. DESARROLLO DE SOFTWARE DIRIGIDO POR MODELOS (DSDM)
Figura 3.14: Transformaciones MDA[38]
A continuación explicaremos los modelos que intervienen en el mecanismo del Framework
MDA [39]:
• CIM: Siglas de Computing Independent Model es un modelo independiente de los
detalles relacionados con la computación que se refieren a aspectos de negocio, un
ejemplo de modelo CIM es un modelo BPMN.
• PIM: Siglas de Platform Independent Model es un modelo independiente de la herramienta. El paso automatizado entre los modelos CIM y PIM es un proceso complicado
pues hay un gran salto semántico entre ellos.
• PSM: Siglas de Platform Specific Model como se puede apreciar en la Figura 3.14 es el
último modelo involucrado y es dependiente de la plataforma. Finalmente se obtiene
código de aplicación mediante transformaciones M2M, acrónimo de Model-To-Text.
Además del MDA, la Ingeniería Dirigida por Modelos se apoya en una serie de herramientas que proporcionan al estado de la cuestión un soporte tecnológico para tareas de modelado,
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
47
transformaciones, etc.
Ejemplos de estas herramientas son Eclipse Modeling Framework (EMF) o Graphical
Modeling Project (GMP, la cual nos permite desarrollar editores gráficos basados en EMF y
GEF.
Como hemos dicho en el inicio de este capítulo, COMPROMISE ofrece mecanismos de
transformación entre modelos. Básicamente hay dos tipos de transformaciones en MDE:
• Transformaciones Model-To-Model, que permiten transformaciones entre modelos,
forman parte de las tres primeras transformaciones en la Figura 3.14. Se pueden
destacar dos lenguajes, por un lado QVT Core Language (utilizando la parte del
lenguaje relacional en este proyecto) y por otro ATL, siglas de Atlas Transformation
Language. Una de las diferencias más notable entre ambos es que QVT sigue el estándar
de la OMG y ATL no. No obstante el segundo es mucho más utilizado que el primero y
posee más soporte.
• Transformaciones denominadas Model-to-Text, las cuales transforman los modelos a
código, este tipo de transformación es la que tiene lugar en el último paso de la Figura
3.14
Aunque las diferencias son muchas, el desarrollo a partir del modelado es un concepto
también presente en las ingenierías tradicionales antes de construir sus artefactos. Los modelos sirven para especificar el sistema de una manera comprensible para los stakeholders,
establecer analogías del sistema en el caso de que exista, razonar y validar el sistema por
medio de la detección temprana de errores y prototipados y guiar la implementación.
El cambio de visión, como hemos mencionado, se basa en el entendimiento del problema
por todos los roles involucrados en el desarrollo mediante la visión del mismo con un nivel de
abstracción superior.
La sintaxis proporcionada por la definición de los metamodelos junto con el conjunto de
reglas permiten formar ficheros ECORE. Este tipo de ficheros contendrán una implementación válida del metamodelo con la que podremos trabajar en distintas herramientas que den
soporte al paradigma MDE. Podremos generar este formato a partir de una implementación
48
3.8. HERRAMIENTAS RELACIONADAS
del metamodelo o mediante la transformación de ficheros que lo contengan (XSD es un
ejemplo) utilizando para ello frameworks específicos, en nuestro caso EMF [8].
Por último, una vez obtenidos los metamodelos sobre los que realizar la transformación
(origen y destino), utilizando frameworks de transformación (Medini QVT en nuestro caso)
podremos realizar transformaciones entre modelos definiendo su correspondencia entre los
distintos elementos de ambos. Dicho proceso se encuentra ilustrado en la Figura 3.15
Figura 3.15: Arquitectura Conceptual de Transformaciones[38]
3.8
Herramientas relacionadas
Actualmente en el mercado existen algunas herramientas que dan soporte a la gestión de la
conformidad de los procesos. Aunque la mayoría pertenecen al ámbito de los procesos de
negocio, hay algunas que si dan soporte a la gestión de conformidad de procesos software
tanto con marcos de referencia de procesos como con otros de carácter legislativo.
CAPÍTULO 3. ESTADO DE LA CUESTIÓN
49
A continuación se presentan algunas de las más importantes junto con una breve descripción de las mismas:
• SAI GLOBAL COMPLIANCE 360º SUITE: Se trata de un conjunto de herramientas
y aplicaciones que permiten a las organizaciones controlar tanto aspectos de conformidad como de gestión de riesgos, aspectos financieros, etc.
• Sepia Solutions ofrece la suite PAWS, siglas de Audit & Risk Management Software.
Permite definir Planes de auditoría, ofrece gestión de riesgos, así como una serie de
recomendaciones y acciones para afrontarlas con ésito. Da soporte a los procesos y a la
metodología utilizada a las organizaciones en sus actividades diarias. Es utilizada por
una gran variedad de industrias, destacando entre ellas bancos, gobiernos, empresas del
sector energético, etc.
Principalmente estas herramientas se centran en la gestión de los distintos cumplimientos
legales que una organización ha de realizar.
Una de las principales razones del desarrollo de COMPROMISE es la incapacidad de las
herramientas existentes en el mercado para definir marcos de trabajo aplicados al desarrollo
Software. Un ejemplo son los modelos armonizados que permite definir la herramienta
ARMONÍAS-DGS para los cuales realizamos análisis de conformidad.
Capítulo 4
Método de Trabajo
El presente capítulo está compuesto por dos secciones. La primera presenta el método
de trabajo que se ha seguido para el desarrollo de la herramienta del presente TFG. La
metodología utilizada en nuestro desarrollo será OpenUP, idónea para desarrollos con un
equipo de trabajo pequeño y que se basa en un modelo iterativo e incremental.
La segunda sección corresponde al entorno tecnológico, describiendo las herramientas
utilizadas para el modelado y el desarrollo, las empleadas para la documentación y los
lenguajes y librerías utilizados en la implementación.
4.1
OpenUP
OpenUP es una metodología utilizada para el desarrollo software propuesta por un conjunto
de empresas y posteriormente donada a la Eclipse Software Fundation, quienes la publicaron
bajo licencia Pública de Eclipse [35].
Está diseñada para pequeños grupos de personas autorganizados, tomando una aproximación de desarrollo Ágil. Además, esta metodología está basada en un desarrollo iterativo e
incremental, pudiendo realizar pequeños microincrementos dentro de las distintas iteraciones
del proyecto dotando al proceso de desarrollo de una granularidad muy alta, lo cual se adapta
perfectamente al tipo de desarrollo que pretendemos abordar.
La organización en la que OpenUP se basa recoge cuatro principios fundamentales
soportados entre sí:
• Colaboración: Se deben desarrollar prácticas colaborativas para alinear los intereses,
facilitar la comunicación y difundir el conocimiento sobre el proyecto y generar un
entorno de trabajo saludable.
52
4.1. OPENUP
• Balance: Lograr el equilibrio entre las necesidades y costos técnicos del proyecto y la
maximización del valor para los stakeholders.
• Enfoque: Hace especial hincapié en facilitar la colaboración técnica para así reducir
los riesgos y el coste en la medida de lo posible.
• Evolución: Una continua evolución del proyecto basada en entrega de funcionalidades
tempranas reduce los errores y obtiene un feedback del cliente.
Siguiendo el paradigma de EPFC, OpenUP se organiza en dos dimensiones. Por un lado
se encuentra el contenido metodológico, que es el que define los elementos como disciplinas,
roles, tareas, artefactos y procesos para su posterior reutilización. Esta dimensión no se ocupa
de la combinación de los mismos o de su uso.
Por otro lado, el contenido procedimental, donde tendrá lugar la aplicación de los elementos anteriormente mencionados a la hora de elaborar los procesos de la organización.
Los elementos que forman el contenido metodológico se enuncian a continuación [60]:
• Disciplinas: Se centra en los requisitos, arquitecturas, desarrollo, pruebas, gestión de
proyecto, gestión de la configuración y del cambio.
• Tareas: Se define tarea como la unidad de trabajo que debe ser realizada por algún rol.
• Artefactos: Un artefacto se considera a todo aquello que una tarea necesita para
realizar su función, o bien la produce o modifica.
• Procesos: Los procesos toman los elementos metodológicos y definen las relaciones
entre ellos.
4.1.1
Ciclo de Vida
Según la metodología de OpenUP, el ciclo de vida permitirá a los integrantes del equipo de
desarrollo ir completando el proyecto con pequeños incrementos, esfuerzos comprendidos
entre horas y días, que irán dotando al proyecto de funcionalidad adicional.
La idea subyacente de OpenUP es que a partir de las iteraciones, el proyecto vaya incrementando valor y que éste se vea reflejado en los entregables a los clientes, ya que cada vez
CAPÍTULO 4. MÉTODO DE TRABAJO
53
que una iteración termina el cliente debería obtener software operativo y funcional. Este tipo
de desarrollo incremental, centrado en añadir valor al producto en cada iteración permite
controlar aspectos como el riesgo, la financiación o el cumplimiento de expectativas de una
forma continuada.
El ciclo de vida de OpenUP comprende cuatro fases: inicio, elaboración, construcción y
transición.
Figura 4.1: Ciclo de vida de OpenUP [35]
A continuación se proporciona la descripción de cada una de las fases [70]:
• Inicio: Una vez terminada esta fase se deberán haber completado cuatro objetivos
principales. Primero se entenderá qué queremos construir determinando la visión
general del proyecto, el alcance del mismo, sus límites y una identificación de los
interesados en el proyecto y por qué, con el objetivo de satisfacer las necesidades
entendiendo los requisitos para cumplir las expectativas del cliente cuanto antes.
• Elaboración: Se realiza el análisis del problema y se define la arquitectura del sistema.
Se debe elaborar un plan de proyecto, plasmando los requisitos y determinando una
arquitectura estable acorde con las necesidades. Además se especifican las herramientas,
la infraestructura a utilizar y el entorno de desarrollo. Al final de esta fase se tendrá la
definición de los casos de uso, los actores, la arquitectura del sistema y un prototipo
ejecutable de la herramienta.
• Construcción: En esta fase se realizarán e implementarán todos los componentes
que falten por completar, serán probados e integrados. Los incrementos deben ser
desarrollados de la forma más rápida sin repercutir en la calidad del producto.
54
4.1. OPENUP
• Transición: Se enfoca el producto software a la plataforma tecnológica del cliente
logrando que los interesados convengan que el desarrollo del producto cumple con los
requisitos planteados. El propósito de esta fase es asegurar que el producto de software
está listo para ser distribuido a los usuarios.
4.1.2
Roles de OpenUP
En la elaboración del Software el factor humano es determinante. Las personas que intervienen
cuentan unas habilidades e intereses distintos, es por eso que dependiendo de la tarea a
realizar puede ocurrir que una persona tenga más aptitudes que otra para llevarla a cabo
satisfactoriamente. Debido a la naturaleza del presente trabajo, los roles serán ostentados por
dos personas:
4.1.2.0.1
Analista Este rol representa la parte del cliente y de los usuarios finales, obte-
niendo los requisitos de los stakeholders y encargado de ajustar prioridades.
Figura 4.2: Relaciones del Rol Analista en OpenUP[35]
4.1.2.0.2
Cualquier Rol Se trata de un rol que lleva a cabo tareas sin carga técnica, en
términos generales se puede decír que es un “peón”.
Figura 4.3: Relaciones del Rol Comodín en OpenUP[35]
CAPÍTULO 4. MÉTODO DE TRABAJO
4.1.2.0.3
55
Arquitecto Este rol es el encargado de diseñar la arquitectura que soportará la
herramienta. Entre sus funciones están la toma de decsiones técnicas sobre el diseño y la
implementación del proyecto. Normalmente se ocupa de identificar y documentar los aspectos
arquitecturales del sistema.
Este rol es un pilar fundamental de un proyecto, y además está estrechamente relacionado
con el rol de Director de Proyecto.
Figura 4.4: Relaciones del Rol Arquitecto en OpenUP[35]
4.1.2.0.4
Desarrollador Este rol tendrá un perfil técnico y a grandes rasgos se ocupará
de las siguientes tareas:
• Ofrecer soluciones técnicas en la parte de desarrollo.
• Aceptación de la arquitectura y desarrollo del proyecto según los paradigmas de la
misma.
• Identificar y construir los casos de prueba necesarios.
• Comunicar las decisiones de modo que otros miembros del grupo las entiendan.
56
4.1. OPENUP
Figura 4.5: Relaciones del Rol Desarrollador en OpenUP[35]
4.1.2.0.5
Project Manager Lidera el planteamiento del proyecto. Además será un nexo
entre el equipo de desarrollo y los clientes. Este rol debe tener conocimientos de gestión,
herramientas, técnicas de negociación, etc. Es responsable directo del resultado del proyecto y
se ocupará de la evaluación de los riesgos del proyecto y de proponer planes de contingencia
para contenerlos en el caso de que ocurran.
Figura 4.6: Relaciones del Rol Project Manager en OpenUP[35]
Aunque no es requisito fundamental, este rol es frecuentemente asumido por una única
persona.
4.1.2.0.6
Stakeholder Representan grupos de interés relacionados con el proyecto. El
único requisito de este rol es estar relacionado (en un presente o en un futuro) con el resultado
del proyecto.
Figura 4.7: Relaciones del Rol Stakeholder en OpenUP[57]
CAPÍTULO 4. MÉTODO DE TRABAJO
4.1.2.0.7
57
Tester Es el rol responsable de las actividades de pruebas. Debe identificar,
definir, implementar y dirigir los casos de pruebas.
Figura 4.8: Relaciones del Rol Tester en OpenUP[57]
A pesar de que la metodología defina los roles anteriormente mencionados con el fin de
repartir el esfuerzo entre el personal involucrado en el proyecto, dado el carácter de este TFG
no es posible, pues el autor asumirá todos los roles anteriormente mencionados (exceptuando
el de Project Manager que lo asumirá el director del TFG), por lo que guiar el método de
trabajo a partir de los mismos no sería correcto.
Es por eso que el proceso de desarrollo se guiará a través de las distintas iteraciones
definidas en la fase de inicio de la metodología [60]. En la siguiente iteración veremos en qué
consisten las distintas etapas llevadas a cabo en las distintas iteraciones.
4.1.3
Proceso Iterativo e Incremental
A continuación se presenta un esquema de ejemplo de los subprocesos llevados a cabo en el
desarrollo, así como el esfuerzo repartido por las distintas iteraciones y fases del desarrollo.
En estos subprocesos intervienen un conjunto de actividades, roles, prácticas y artefactos que
guían el proceso de desarrollo a través de las cuatro fases descritas en el apartado 4.1.1.
58
4.1. OPENUP
Figura 4.9: Ciclo de Vida de OpenUP[57]
Como podemos observar en el gráfico de la Figura 4.9, las diferentes iteraciones se distribuyen a través de las cuatro fases y cada fase puede tener tantas iteraciones como ésta
necesite, normalmente vendrá determinado por la complejidad, el conocimiento del dominio
y la tecnología, etc. En nuestro caso las iteraciones serán definidas en base a los casos de uso
de la herramienta, es decir, teniendo en cuenta su funcionalidad.
La duración de las iteraciones pueden depender de muchos factores. No obstante al
finalizar cada iteración se tienen que generar una serie de informes que:
• Indiquen el incremento funcional realizado.
• Sirvan de conocimiento al resto de los involucrados en el proyecto.
• Minimicen los riesgos y problemas debido a la pronta aparición de los mismos y
consecuentemente a la rápida mitigación de estos.
En nuestro desarrollo, estos informes estarán recogidos en las distintas iteraciones que
están presentes en el Capítulo de Resultados.
CAPÍTULO 4. MÉTODO DE TRABAJO
4.1.4
59
Flujos Fundamentales de Trabajo Obtenidos para el desarrollo
de COMPROMISE.
En este apartado se exponen a modo de resumen los distintos flujos de trabajo que podemos
encontrar en las distintas iteraciones presentes en el ciclo de vida propuesto para la elaboración
de COMPROMISE.
4.1.4.1
Captura de Requisitos
Este flujo fundamental de trabajo tiene como objetivo establecer todos los aspectos que
el cliente desea tener presentes en el sistema desarrollado. El contexto del problema será
comprendido por el analista y posteriormente se catalogarán dependiendo de la prioridad
de los mismos, separando a su vez la naturaleza de los mismos en funcionales y no funcionales.
Cabe destacar que estos requisitos no son estáticos y pueden ser cambiados a medida que
el desarrollo va avanzando, en nuestro caso no ha sido una excepción y se han añadido algunos
que en un origen no habían sido contemplados. Esto es debido a que, durante el tiempo de
desarrollo, los objetivos de negocio del cliente están abiertos a cambios. Un buen desarrollo
ha de ser flexible e integrar estos nuevos objetivos de forma dinámica con el mínimo coste de
desarrollo posible.
4.1.4.2
Análisis y diseño
En la etapa de análisis tendrá lugar el entendimiento y comprensión del problema a resolver.
Se analizará el entorno sobre el que el problema es definido y se obtendrá la información
necesaria a partir de los requisitos para lograr una solución satisfactoria.
Una vez recogida la información en la etapa de análisis, se determinará la estrategia a
seguir para dar una buena solución al problema. En esta etapa se generan artefactos en forma
de diagramas, los cuales pueden proveer a todos los stakeholders de una idea generalizada de
la solución del mismo y modificarlo si es necesario. Una vez validado el diseño tendrá lugar
la etapa de implementación, expuesta a continuación.
60
4.2. ENTORNO TECNOLÓGICO
4.1.4.3
Implementación
Partiendo de la solución proporcionada por las etapas anteriores, en esta etapa se desarrollará
el software que de solución al problema. Es en la fase de construcción cuando esta etapa cobra
mayor importancia aunque en la fase anterior podemos haber construido algunas pruebas de
concepto que han sido necesarias para comprender la tecnología.
Al finalizar esta etapa obtendremos como artefacto el código de la iteración correspondiente.
4.1.4.4
Etapa de Pruebas
En esta etapa se verifica la funcionalidad de la herramienta, primero con pruebas unitarias y
posteriormente con pruebas de integración.
Para la elaboración de los mismos se tendrán en cuenta valores extremos del dominio y la
utilización de valores propensos a error.
Es de vital importancia la correcta elaboración de esta etapa, pues salvo labores de
mantenimiento, será la última antes de que el producto final esté listo para la entrega al
usuario final. Únicamente después de haber concluido esta etapa se considerará válida la
funcionalidad de la iteración salvo cambios por parte del cliente.
4.2
Entorno Tecnológico
A continuación se mencionarán las herramientas utilizadas para el desarrollo de COMPROMISE, la documentación así como las librerías, lenguajes y tecnologías utilizadas.
4.2.1
Herramientas de modelado y desarrollo y tecnologías utilizadas
En esta sección se presentarán las herramientas utilizadas para el desarrollo y modelado de la
herramienta objeto del presente TFG.
CAPÍTULO 4. MÉTODO DE TRABAJO
4.2.1.1
61
EPFC
Tal y como se ha mencionado en los capítulos anteriores, el presente TFG genera modelos
compatibles con EPFC a partir de la base de datos de ARMONÍAS. EPFC [9] (Eclipse Process
Framework Composer) es una herramienta desarrollada dentro del entorno Eclipse y que como
lenguaje de modelado utiliza UMA (siglas de Unified Method Architecture), a su vez basado
en el metamodelo SPEM 2.0. Es un editor de procesos SPEM 2 que incluye metodologías
importables y que con ella las organizaciones pueden diseñar sus procesos de una manera
fácil y dinámica, favoreciendo el conocimiento con mecanismos de compartición tales como
la publicación Web de un proceso.
Figura 4.10: Pantalla Principal Herramienta EPFC
62
4.2. ENTORNO TECNOLÓGICO
Como referencia esencial para el aprendizaje de la herramienta se ha seguido el manual
elaborado por Francisco Ruiz y Javier Verdugo del Grupo Alarcos [63].
4.2.1.2
Struts2
Struts2 [20] es un framework de código abierto de la Apache Software Foundation que permite
el desarrollo de aplicaciones web mediante el patrón MVC (Modelo-Vista-Controlador o
Model-View-Controller). Struts2 provee al desarrollador de mecanismos para que la implementación de las aplicaciones sean más sencillas, rápidas y robustas. Además soluciona el
problema de la persistencia mediante una buena integración con Hibernate, el cual será tratado
más adelante en esta sección.
Básicamente Struts2 procesa las peticiones por parte del cliente utilizando tres elementos:
• Interceptores: Son clases que siguen el patrón interceptor y están estrechamente
relacionadas con las acciones, ejecutándose antes y después de éstas. Se pueden utilizar
para muchas labores, tales como el login de usuarios de la aplicación, manejar sesiones
HTTP, etc.
• Acciones: Son las clases encargadas de la lógica de la aplicación, cada URL es mapeada
a una acción concreta que provee a la herramienta de la lógica necesaria para cumplir
un objetivo concreto. Estos únicamente devuelven una cadena de caracteres (String)
denominado Result, que determinará el resultado que el cliente visualizará.
• Resultados: Indica cómo debe ser tratado el resultado que se entregará al cliente. Un
action puede tener más de un result asociado. De esta manera la ejecución puede tomar
varias direcciones dependiendo del cómputo realizado por los Actions.
A continuación, en la Figura 4.11, se ofrece el flujo natural de una petición atendida por
el famework.
4.2.1.3
Eclipse
Eclipse [7] es un entorno de trabajo Integrado o IDE (Integrated Development Environment)
de código abierto que dota al desarrollador de los mecanismos necesarios para implementar
un sistema software. Es además extensible mediante plugins y facilita editores para otro tipo
CAPÍTULO 4. MÉTODO DE TRABAJO
63
Figura 4.11: Atención de una Petición Struts2[10]
de lenguajes como JSP, HTML, XML, CSS, etc.
Un ejemplo de plugin utilizado en nuestro desarrollo es JAXB (Sección 4.2.4.9), el
cual permite crear clases de manera automática a partir de su esquema XSD y facilita
al desarrollador de una API (Application Programming Interface) que da soporte a las
operaciones de Marshalling y Unmarshalling de documentos XML.
4.2.1.4
Apache Tomcat
Apache Tomcat es un servidor que nos permite alojar servlets y JavaServer Pages (JSP). Se
utilizará para desplegar nuestra herramienta Web, además presenta una buena integración con
el IDE Eclipse.
Esta herramienta ha sido utilizada en su versión Apache-Tomcat-7.0.52. A partir de la
versión 7 de Apache, la herramienta incorpora [1]:
• Implementaciones de Servlet 3.0, JSP 2.2 y EL 2.2.
• Mejoras para detectar y prevenir “fugas de memoria” en las aplicaciones Web.
• Limpieza interna de código.
• Soporte para la inclusión de contenidos externos directamente en una aplicación Web.
64
4.2. ENTORNO TECNOLÓGICO
4.2.1.5
MySQLWorkbench
Se trata de una herramienta que da soporte a todas las fases propias del desarrollo de una base
de datos, facilitando al desarrollador una interfaz amigable e intuitiva [17].
Esta herramienta permitirá desarrollar código SQL a partir de un diagrama E/R (Entidad/Relación) generado, presente en la Figura 4.12, que ejecutaremos en la propia herramienta.
La versión utilizada en la elaboración de nuestro TFG es MySQL Workbench 6.0
Figura 4.12: Ejemplo Aplicación MySQLWorkbench[10]
4.2.1.6
Visual Paradigm
Es una herramienta CASE que permite el diseño y modelado de diagramas UML que soportan
el desarrollo de nuestra herramienta. Destaca su potencia, pues prácticamente todos los
diagramas necesarios para desarrollar un proyecto es posible realizarlos con esta herramienta.
Además posee herramientas de generación de código automático y recogida de requisitos a
partir de documentos previamente configurados.
Para el desarrollo de la herramienta se ha utilizado la versión Visual Paradigm for UML
11.0 [22].
CAPÍTULO 4. MÉTODO DE TRABAJO
4.2.1.7
65
JUnit
JUnit es un Plug-in de Eclipse que permite a los desarrolladores realizar labores de Testing de
las distintas funcionalidades de un Software.
Se implementa bajo una serie de librerías disponibles en la página de descarga del
Framework. Su integración con el IDE Eclipse facilita las labores de testing, ofreciendo
también funciones de Profiling.
4.2.1.8
BPMN Modeler
BPMN Modeler [4] es una herramienta gráfica que permite definir procesos de negocio acordes al metamodelo BPMN (Business Process Modeling Notation). Se trata de una herramienta
perteneciente a la Eclipse Foundation y desarrollada bajo el proyecto de Model Development
Tools (MDT).
Su metamodelo es compatible con la especificación de BPMN 2.0 propuesto por la OMG,
no obstante su especificación no es idéntica y han sido necesarias labores transformación para
la representación de modelos BPMN 2.0 de manera gráfica.
Figura 4.13: Pantalla principal de la Herramienta BPMN Modeler
66
4.2.1.9
4.2. ENTORNO TECNOLÓGICO
Bootstrap
Bootstrap es un framework desarrollado por la compañía Twitter y liberado bajo licencia
Apache Basado en CSS3 y HTML5 para crear diseños de interfaces Web de una manera
eficaz e intuitiva. Sus principales características son que sus funciones están soportadas por la
mayoría de los navegadores Web actuales y su particular diseño con rejillas (grid) permiten
el uso de aplicaciones web prácticamente en la totalidad de dispositivos haciendo que la
visualización sea independiente de la resolución del dispositivo utilizado.
4.2.1.10
GIT
Es un software de control de versiones que ayuda en el desarrollo y la gestión de aplicaciones
complejas. Aunque en el presente desarrollo se ha utilizado únicamente por una persona
permite gestionar aplicaciones teniendo en cuenta las necesidades de grupos de trabajo
numerosos. Además ofrece mecanismos para la gestión de repositorios remotos, desacoplando
el desarrollo de un puesto de trabajo convencional.
CAPÍTULO 4. MÉTODO DE TRABAJO
4.2.2
67
Entorno tecnológico MDA
A continuación se presentan un conjunto de herramientas relacionadas con el paradigma
MDA. Estas herramientas han sido utilizadas para realizar el componente de transformación
de la herramienta objeto del TFG.
4.2.2.1
EMF
Se trata de una herramienta de modelado de la fundación Eclipse cuyo acrónimo viene
determinado por las siglas en inglés de Eclipse Modeling Framework [8] . Permite manipular
y generar modelos software para posteriormente construir herramientas basadas en modelos
de datos estructurados. Son muchas sus funcionalidades; producir código java a partir del
modelado, da soporte a la especificación de modelos mediante anotaciones java, documentos
XML, etc. En nuestro desarrollo lo utilizaremos para representar los metamodelos .ecore y
generarlos a partir de esquemas XML.
Figura 4.14: Pantalla principal Eclipse Modelling Framework (EMF)
4.2.2.2
Medini-QVT
Es un framework implementado por la OMG (Object Management Group) que permite la
transformación model-to-model [16]. Dado que sigue el estándar de la OMG será el utilizado
68
4.2. ENTORNO TECNOLÓGICO
junto con su lenguaje de transformaciones QVT Relations, encargado de implementar los
detalles de la transformación.
Figura 4.15: Vista de ejemplo de la aplicación Medini QVT[10]
4.2.3
Documentación
4.2.3.1
LATEX
LATEXes un sistema que facilita la documentación, especialmente diseñado para la producción
de textos técnicos y científicos. Ha supuesto un estándar de facto para la comunicación y la
publicación de este tipo de documentos, en parte por su rápida curva de aprendizaje y por su
carácter gratuito.
Para la elaboración del presente documento se utilizará el compliador MikTex en su
versión 2.9.
4.2.3.2
Texmaker
Es un editor para documentos LATEX, que provee al usuario de mecanismos de visualización
de la estructura, inserción de elementos, tales como figuras o tablas, y la definición de snippets
para la introducción repetitiva de código en listas, enumeraciones etc.
Además facilita la compilación del texto y la bibliografía de una manera cómoda para el
programador, así como la visualización de documentos finales en formatos PDF, PS o DVI.
CAPÍTULO 4. MÉTODO DE TRABAJO
69
Figura 4.16: Ejemplo de la herramienta TexMaker[10]
4.2.3.3
BIBTEX
Es una herramienta de LATEXutilizada para dar formato a listas de referencias, destaca por su
completitud y su facilidad de uso junto a LATEX.
En la elaboración de la bibliografía del presente documento ha sido utilizada la herramienta
BIBTEX.
4.2.3.4
GIMP
Se trata de una herramienta de edición de imágenes, posee un gran número de funcionalidades
y por ser una herramienta de Software Libre. Además tiene la posibilidad de ser ampliada
mediante Plug-ins, lo cual la dota de una alta capacidad de personalización.
La versión de la herramienta utilizada en el presente TFG es GIMP 2.8.10
4.2.3.5
Dia
Dia es una herramienta utilizada para construir diagramas y se desarrolla como parte del
proyecto GNOME. Se puede utilizar para dibujar diferentes tipos de diagramas tales como
UML, esquema Entidad/Relación, esquemas eléctricos, etc.
70
4.2. ENTORNO TECNOLÓGICO
Una de las ventajas más importantes radica en la exportación de sus archivos como
imágenes vectoriales, lo cual nos permite redimensionar la misma sin que la calidad se vea
afectada. Además Dia es capaz de exportar a muchos más formatos, como pueden ser EPS,
PNG, PDF, etc.
4.2.4
Lenguajes y Librerías utilizadas
4.2.4.1
UML
UML 2.0, siglas de Unified Modeling Language es un lenguaje de modelado propuesto por la
OMG. Ofrece un alto nivel de abstracción a la hora de construir la herramienta que permite
al diseñador centrarse en la complejidad del problema, ofreciando varios tipos de diagramas
útiles durante el proceso de desarrollo del proyecto, tales como los diagramas de análisis, los
diagramas de diseño o los de despliegue [21].
4.2.4.2
Java
Java es el lenguaje utilizado para desarrollar la herramienta COMPROMISE. Se trata de un
lenguaje de alto nivel y portable a la mayoría de las herramientas actuales del mercado, de ahí
su gran aceptación. Se ejecuta sobre una máquina virtual denominada JRE, siglas de Java
Runtime Environment [13].
4.2.4.3
QVT Relations
Se trata de un lenguaje declarativo utilizado para escribir transformaciones entre modelos,
tanto unidireccionales como bidireccionales [19].
4.2.4.4
JavaScript
Es un lenguaje interpretado, ejecutado normalmente en el lado del cliente y que dota a la
página de dinamismo y le confiere gran cantidad de mejoras en el aspecto de la misma.
Además puede operar con algunos elementos y ejecutar algunas funciones, como por ejemplo
restricciones.
CAPÍTULO 4. MÉTODO DE TRABAJO
4.2.4.5
71
HTML
Siglas de HyperText Markup Language, es un lenguaje utilizado en la generación de páginas
web en el lado del cliente. Se trata de un estándar de la W3C (World Wide Web Consortium).
Basa su funcionalidad en el uso de etiquetas para definir las distintas partes que componen la
página.
4.2.4.6
JSP
Es una tecnología que permite la construcción de páginas web dinámicas basadas en el
lenguaje HTML. Para su despliegue es necesario un servidor compatible, en nuestro caso
Apache Tomcat. Lo que hace particular a esta tecnología es la utilización del lenguaje java,
pudiendo hacer uso del mismo dentro del archivo .jsp mediante la definición de etiquetas.
4.2.4.7
IText
IText proporciona al desarrollador mecanismos de tratamiento para ficheros con formato PDF.
En el presente Trabajo de fin de Grado la utilizaremos para generar informes de Compliance
para las organizaciones.
4.2.4.8
Hibernate
Hibernate es una tecnología ORM (Object-Relational Mapping o en español “Mapeo ObjetoRelacional”) que facilita a los desarrolladores la construcción de aplicaciones en las que los
datos son externos a las mismas y se hace necesaria una persistencia de los mismos [11].
Mediante la definición de la estructura mediante documentos XML o mediante anotaciones
en el código, es posible introducir directamente los objetos en la misma sin preocuparnos
de extraer sus valores. Además es independiente de la base de datos que usemos, lo que
reduce la acoplabilidad del sistema definiendo el driver junto con los datos necesarios para la
conexión en un fichero XML. Si surge la necesidad de cambiar la tecnología de la persistencia
únicamente se modificará ese fichero.
72
4.2. ENTORNO TECNOLÓGICO
4.2.4.9
JAXB
JAXB [18] es un plug-in que dota al IDE Eclipse de capacidades de gestión de documentos
XML. Con este plugin es posible generar las clases de dominio de un sistema a partir de la
especificación de su esquema, componer o leer de ficheros XML a partir de las clases de
dominio de un sistema, etc.
El plugin proporciona una API, con dos funcionalidades principales, Marshalling y
UnMarshalling, términos utilizados en el documento y que procederemos a su explicación:
• Marshalling: Esta función es la encargada de la composición del archivo XML con
los datos de las clases de dominio que queramos incluir en el mismo. Para establecer la
jerarquía de árbol, que unos elementos contengan a otros y que a la hora de la inclusión
mediante la función arrastre todos los elementos relacionados, es necesario realizar
anotaciones en las clases de dominio que deseemos que formen parte del documento.
• UnMarshalling: Dada la funcionalidad anterior, el UnMarshalling es totalmente lo
opuesto. A partir de un fichero XML permite seleccionar los elementos que queramos
permitiéndonos el acceso de los datos de éste y de los relacionados con él.
4.2.4.10
XML
XML es un lenguaje de marcas desarrollado por la W3C utilizado para almacenar datos y que
permite definir la gramática de lenguajes específicos. Es muy útil cuando, como es nuestro
caso, varias aplicaciones necesitan comunicarse intercambiando datos.
Las ventajas radican en que es un lenguaje extensible, pudiendo añadir las etiquetas que
consideremos necearias en cada momento. Además cabe la posibilidad de validarlo mediante
su esquema, el cual contiene la definición bajo la que se debe implementar el documento,
siendo así idóneo para el intercambio entre herramientas.
4.2.4.11
MySQL
Es un Sistema de Gestión de Base de Datos (SGBD) multihilo y multiusuario. Se desarrolla
como un sistema de software libre con doble licencia. Por un lado se ofrece bajo licencia
CAPÍTULO 4. MÉTODO DE TRABAJO
73
GPL para usuarios normales, para aquellas empresas que quieran incorporarlo en productos
privativos deberán comprar la licencia correspondiente que autorice su uso.
Capítulo 5
Resultados: Herramienta
COMPROMISE
En este capítulo se presentan los resultados obtenidos durante el desarrollo de la herramienta
COMPROMISE, guiada por la metodología de desarrollo presentada en el Capítulo 4.
El desarrollo se ha establecido bajo un único ciclo dividido en las cuatro etapas propias de
la metodología, Fase de Inicio, Fase de Elaboración, Fase de Construcción, Fase de Transición.
No obstante esta última fase no tendrá cabida en el presente desarrollo, pues es la fase de
entrega al cliente, la cual no forma parte del alcance del presente TFG. Además cada una
las etapas estarán divididas en iteraciones, con sus respectivos incrementos expresados en
las mismas, elaboradas en la fase de Inicio. Con el fin de facilitar el seguimiento del proyecto y encuadrar los artefactos siguiendo el desarrollo natural del mismo, se presentarán
los artefactos más importantes, si el lector quisiera profundizar en algún aspecto concreto se
le mostrará el resto de detalles en los apéndices oportunos o en la bibliografía correspondiente.
La herramienta consta de dos bloques de funcionalidad. Por un lado, el componente de
análisis de conformidad de los procesos definidos en EPF Composer para con un modelo de
referencia concreto y por otro el bloque de transformación de un proceso software representado como proceso de negocio.
Finalmente se incluye un módulo de Administración de la herramienta que permitirá
al administrador de la misma soluciones como la inclusión de Usuarios, Organizaciones y
activos pertenecientes a la misma.
76
5.1. FASE DE INICIO
5.1
Fase de Inicio
En la primera fase se han llevado a cabo un número considerable de tareas, tales como las
reuniones con el director de proyecto para comprender la dimensión de la solución requerida
para solventar el problema, preparación bibliográfica que nos permita tener una visión global
del proyecto, elaboración de un plan general del mismo en cuanto a funcionalidades se refiere,
captura de requisitos que la herramienta debe cumplir para satisfacer los objetivos propuestos,
el plan de iteraciones junto con los incrementos que las completarán, la elaboración de diagramas de casos de uso que el sistema debe implementar, además de determinar la arquitectura
del sistema a construir.
En la siguiente tabla se presentan los roles que interactúan con la herramienta:
Funcionalidad
Rol
Bloque
Gestor de Usuarios
Administrador de la Herramienta
Administración
Gestión de Compañías
Administrador de la Herramienta
Administración
Gestión de herramientas, roles, Activos
Administrador de la Organización
Administración
Gestión de Conformidad de una Organización
Todos
Análisis
Conformidad
Gestión de Procesos de la Organización
Análisis
Todos
Conformidad
Gestión de Resultados
Análisis
Todos
Conformidad
Gestión de Transformaciones
Todos
Transformación
Tabla 5.1: Roles de la herramienta con sus funcionalidades y componente al que pertenecen.
5.1.1
Requisitos
Como hemos mencionado, la captura de requisitos dio lugar a los tres roles mencionados en
la parte anterior:
• Gestor de Procesos
• Administrador de la Organización
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
77
• Administrador de la Herramienta.
Además se propuso un mecanismo para medir la Conformidad del proceso respecto de
un marco de referencia. Se determinó que la mejor estrategia sería comprobar si la tarea
implementada en el proceso de la organización está o no en el modelo de referencia, constituyendo así un “sistema bivalente” menos propenso a errores de algoritmia, dejando la parte de
constitución de un algoritmo en la sección de trabajo futuro del presente documento. (Sección
6.1.1)
Posteriormente, en sucesivas reuniones se planteó el requisito de que la herramienta posea
mecanismos de visualización del proceso software en un motor de procesos de negocio con su
consecuente transformación y tratar dicho proceso software como si de un proceso de negocio
se tratase, pues el primero es una especialización del segundo. Así surgió la necesidad de una
transformación entre modelos.
5.1.2
Dominio de la Herramienta
A continuación se explicarán algunos términos del dominio sobre el cual tiene cabida el sistema desarrollado, las razones de las decisiones tomadas, así como una relación de conceptos
que serán útiles al lector para comprender el alcance de la herramienta.
Dependiendo del tipo de relación con COMPROMISE hay varios roles que pueden
interactuar con la misma. Básicamente se distinguen tres tipos:
• Gestor de Procesos: Normalmente este rol lo obstentará el ingeniero de procesos y
tendrá la posibilidad de controlar los procesos, evaluarlos, inspeccionarlos, además
de ejecutar transformaciones para la visualización en otras herramientas y medir el
compromiso de los mismos con los estándares. No obstante no podrá gestionar los
activos de la empresa.
• Administrador de la organización: Es el encargado de gestionar todos los activos de
la empresa, teniendo capacidad de modificación, creación, actualización y eliminación
de los mismos.
78
5.1. FASE DE INICIO
• Administrador de la herramienta: Será el encargado de la Gestión de los Usuarios
de la herramienta. Sus funcionalidades se expresan en el modelo de casos de Uso de la
fase de inicio.(Sección 5.2).
Además, debido a la complejidad del dominio con el que trabajamos, se creyó conveniente
que en la Fase de Inicio se debe elaborar una visión global del proyecto, así como las relaciones entre las herramientas. Esta relación se podrá observar de manera gráfica en el diagrama
general de la herramienta, presente en la Figura 5.1
La aplicación se nutrirá de la herramienta ARMONÍAS-DGS, concretamente de la Base de
Datos que almacena los procesos convirtiéndolos al metamodelo UMA. Dicho conocimiento
será recogido por la herramienta EPF Composer, poblando su contenido de método para que
después a partir de la reutilización de los elementos cargados formar su proceso.
Una vez modelado el/los procesos con EPFC, a partir del contenido de método cargado
con anterioridad, se deberá cargar el archivo que contiene los procesos en COMPROMISE,
guardará todos sus elementos en su base de datos para su reutilización a la hora de elaborar
informes o gráficos y por último dará soporte al análisis de la conformidad respecto de los
modelos de referencia de la herramienta ARMONÍAS-DGS. Además tendrá un componente
de transformación que nos permitirá representar el proceso software como un proceso de
negocio acorde al metamodelo BPMN 2.0 y visualizar dicho proceso en la herramienta BPMN
Modeler mediante el postprocesamiento del archivo resultante de la tarea anterior.
A continuación, en la figura de la siguiente página (Figura 5.1), se presenta un esquema general de la herramienta en la que podemos observar como COMPROMISE sirve de
“puente” entre ARMONÍAS-DGS y EPFC, Medini-QVT y BPMN Modeler; dotándola de
funcionalidades que no poseía tales como la gestión de los procesos, así como de todos los
elementos comprendidos en los mismos, funciones de transformación Model-to-Model que
tendrán como objetivo representar procesos mediante BPMN, y funcionalidades de análisis
de Conformidad de los mismos respecto con Modelos de Referencia utilizados en la industria.
GESTIÓN DE
ORGANIZACIÓN
METAMODELOS
BPMN
UMA
EJECUCIÓNFDEFPROCESOSFBPMN
DIRECCIÓN
TRANSFORMACIÓN
Task 1
Task 2
MODELOS
Task 3
Task 4
DESCOMPOSICIÓNFPROCESOS
GENERACIÓNFDEFPDF
ARMONÍASF-FDGS
COMPLIANCE
GENERACIÓNFDEFGRÁFICASFDEFCOMPLIANCE
ModelosFnoFArmonizados
BBDD
DETERMINARFESTADO
DEFPROCESOS
ModelosFArmonizados
CERTIFICACION CON MENOS
RECURSOS POSIBLES
RECOMENDADOR
CONOCIMIENTOFGLOBAL
PUBLICARFPROCESOF
EPFC
COMPRIMISE
ELEMENTOS
METHODFLIBRARY
PROCESOS
BBDDFHibernate
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
GESTIÓN DE ACTIVOS
ARTEFACTOS
EXPORTAR
G.P.S
PROCESOSFYFACTIVOSFDEFLAFORGANIZACIÓN
79
PROCESOSFDEFINIDOS
Figura 5.1: Diagrama general de COMPROMISE
80
5.1. FASE DE INICIO
5.1.3
Modelo de Casos de Uso
A continuación se presentan los casos de uso del rol de Administrador y del Gestor de Procesos.
Este es el diagrama del Administrador de la herramienta. Podemos ver las funciones
anteriormente comentadas en la figura:
Figura 5.2: Diagrama de Casos de Uso de Administrador de la Herramienta
A continuación se presenta el diagrama de casos de Uso del Gestor de Procesos o responsable de medir la conformidad de los procesos de la organización.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
81
Figura 5.3: Diagrama de casos de uso Gestor de Procesos
5.1.4
Plan de Iteraciones
Corresponde a la Fase de Inicio del ciclo de vida elaborar el plan de Iteraciones. Dicho plan
se ha determinado a partir de los diagramas de casos de uso presentados con anterioridad. A
continuación se presentan a modo de tabla, incluyendo un dígito que determina el orden de las
mismas, la fase a la que pertenecen, los objetivos que se pretenden satisfacer, los artefactos
obtenidos conformando éstos los incrementos y el grado de importancia que adquieren en las
mismas los flujos de trabajo fundamentales en forma de porcentaje (Captura de Requisitos,
Análisis, Diseño, Implementación y Pruebas).
82
5.1. FASE DE INICIO
Número Iteración
0
Fase
Inicio
• Identificar Requisitos
Objetivos
• Visión general de la herramienta
• Especificación de Requisitos Software
• Estimación de tiempo y complejidad
• Anteproyecto (Visión general del proyecto)
• Estimación y Planificación del TFG (Apéndice E)
Productos de Trabajo
• Modelo de Casos de Uso
• Plan de Iteraciones
Requisitos: 50 %
Análisis: 35 %
Esfuerzo flujo de Trabajo
Diseño: 15 %
Implementación: Pruebas: Tabla 5.2: Iteración 0
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
Número Iteración
1
Fase
Elaboración
• Establecer correspondencia entre la base de datos de
ARMONÍAS-DGS y metamodelo UMA
Objetivos
• Composición XML prueba de Concepto.
• Integración Plugin JAXB
• Despliegue en el servidor Arquitectura Struts2
• Corespondencia entre los elementos de la BBDD de
ARMONÍAS-DGS y UMA
Productos de Trabajo
• Documento XML desechable
• Estructura de la Aplicación en el servidor Apache
Requisitos: 15 %
Análisis: 30 %
Esfuerzo flujo de Trabajo
Diseño: 10 %
Implementación: 30 %
Pruebas: 15 %
Tabla 5.3: Iteración 1
83
84
5.1. FASE DE INICIO
Número Iteración
2
Fase
Elaboración
• Implementación Marshalling y UnMarshalling automático de
Contenido de Método
Objetivos
• Carga de Procesos definidos en EPFC en la herramienta
• Integración con Struts2
• Visualización de los procesos de la organización
Productos de Trabajo
• Funcionalides básicas para Marshalling y Unmarshalling
• Herramienta Funcional integrada en el servidor Apache
Requisitos: 0 %
Análisis: 30 %
Esfuerzo flujo de Trabajo
Diseño: 20 %
Implementación: 30 %
Pruebas: 20 %
Tabla 5.4: Iteración 2
Número Iteración
3
Fase
Elaboración
• Implementar función Recomendador
Objetivos
• Implementar funciones de Conformidad
Productos de Trabajo
• Análisis de Conformidad de Procesos
Requisitos: 0 %
Análisis: 10 %
Esfuerzo flujo de Trabajo
Diseño: 20 %
Implementación: 40 %
Pruebas: 30 %
Tabla 5.5: Iteración 3
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
Número Iteración
4
Fase
Construcción
85
• Dar soporte a la representación gráfica
Objetivos
• Carga de archivos XML externos
• Visualización de estadísticas
• Salida de documentos PDF, presentación de Informes
Productos de Trabajo
• Componente de carga de ficheros con Interfaz
• Componente de visualización de Estadísticas
Requisitos: 0 %
Análisis: 10 %
Esfuerzo flujo de Trabajo
Diseño: 15 %
Implementación: 60 %
Pruebas: 15 %
Tabla 5.6: Iteración 4
86
5.1. FASE DE INICIO
Número Iteración
5
Fase
Construcción
• Definición del esquema de Base de Datos
• Implementar componente de Administración.
Objetivos
• Integración de Hibernate con Struts2
• Persistencia de los procesos de la organización definidos en EPF
en la BBDD
• Integración de COMPROMISE con Medini QVT, EPFC, BPMN
Modeler.
• Subida y bajada al servidor de archivos a procesar necesarios.
• Gestión de ficheros en el servidor.
Productos de Trabajo
• Esquema de Base de Datos
• Componente de Administración.
Requisitos: 0 %
Análisis: 5 %
Esfuerzo flujo de Trabajo
Diseño: 15 %
Implementación: 70 %
Pruebas: 10 %
Tabla 5.7: Iteración 5
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
Número Iteración
6
Fase
Construcción
87
• Conversión entre básica entre modelos UMA Y BPMN
• Menú de la herramienta
Objetivos
• Validador de sesiones de Usuario.
• Representación gráfica de modelos BPMN
• Plan de conversión entre modelos
Productos de Trabajo
• Fichero qvt de transformación
• Software adicional para la representación gráfica en BPMN
Modeler
Requisitos: Análisis: 10 %
Esfuerzo flujo de Trabajo
Diseño: 10 %
Implementación: 70 %
Pruebas: 10 %
Tabla 5.8: Iteración 6
Número
7
Fase
Construcción
• Integración con otras heramientas (EPFC, MediniQVT,
BPMN2Modeler )
Objetivos
Selector de Idiomas
• TestSuite
Productos de Trabajo
• Herramienta con todas las Funcionalidades
• Manual de Instalación y Usuario
Requisitos: Análisis: -
Esfuerzo flujo de Trabajo
Diseño: 10 %
Implementación: 30 %
Pruebas: 60 %
Tabla 5.9: Iteración 7
88
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
5.2
Fase de Elaboración y Construcción
A continuación se presentarán en detalle las iteraciones definidas en la fase anterior, prestando
especial interés al análisis y diseño de la herramienta.
Como hemos dicho en capítulos anteriores, COMPROMISE se diseñará bajo el framework
Struts2, el cual provee al desarrollador de mecanismos necesarios para implementar su
solución bajo una arquitectura en tres capas conocida como Modelo-Vista-Controlador (MVC
por sus siglas), éste es explicado a continuación [59]:
• Modelo: En el modelo se encuentra la lógica de negocio y la información a representar.
Se comunica con la vista para proporcionarle los datos solicitados. No obstante el cliente
no interactúa directamente con este componente, sino que le envía las peticiones a un
controlador y éste es el encargado de acceder al modelo. De esta manera se mantiene la
independencia ambos.
• Controlador: Interactúa con la vista y es el que envía las peticiones al modelo para
operar sobre los datos que el cliente ha solicitado. Podemos decir que su función es un
filtro que impide al cliente operar directamente en el modelo, en el framework Struts2
al controlador se le conoce como “FilterDispatcher”.
• La vista es la encargada de interaccionar con el cliente, presentándole la información,
siendo por tanto es la salida del modelo.
La definición de esta arquitectura será determinante a lo largo del proyecto y se establece
en las primeras reuniones de la fase de elaboración, ya que desde un origen se buscaba una
estructura sólida y extensible.
Por otro lado la fase de Construcción estuvo orientada prácticamente a la elaboración del
código necesario para implementar la herramienta.
A continuación se dividirá esta sección en las siete iteraciones , exponiendo individualmente los artefactos obtenidos así como los diagramas más representativos que dan soporte a
la elaboración de la herramienta.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
5.2.1
89
Iteración 1: Generador de Modelos UMA a partir de la BBDD de
ARMONÍAS-DGS
5.2.1.1
Análisis y Diseño
Corresponde a esta iteración elaborar una prueba de concepto que serialice elementos del
metamodelo UMA para su posterior carga en la herramienta EPFC. No obstante esta función
se detallará en la siguiente iteración, pues en la presente cobra más importancia la correspondencia de los distintos elementos de la base de datos de ARMONÍAS-DGS a UMA.
Como mencionábamos, la base de datos de ARMONÍAS-DGS es la que proporciona el
conocimiento necesario para poblar el Contenido de Método de nuestra herramienta. Además,
será necesaria dicha base de datos origen con el fin de lograr una correcta correspondencia
entre los elementos de la misma y los generados adscritos al metamodelo UMA. Para comparar los procesos de la organización con los modelos de referencia es necesario establecer una
correspondencia, pues no todos los elementos de ARMONÍAS-DGS tienen una correspondencia clara en UMA.
Pertenecerá a la etapa de análisis dar una solución a la problemática expuesta con la
siguiente propuesta de transformación:
• Las tareas (Task) de la BBDD de ARMONÍAS-DGS se corresponderán con las tareas
Task por las similitudes entre ambas. No obstante, para no perder semántica, en algunas
de ellas será necesario englobar sus propiedades en los Task Descriptor, siendo éstos
una ampliación del nivel semántico de las anteriores.
• Las actividades (Activities) de ARMONÍAS-DGS no tendrán una correspondencia
clara. Pues en EPFC únicamente tendremos actividades en el momento de componer el
proceso, y lo que hacemos en un origen es poblar el contenido de método. Es por eso
que se convertirán en Disciplinas. Como hemos comentado en capítulos anteriores una
disciplina es una colección de Tareas relacionadas dentro de un área de interés y por
tanto, permite categorizar el trabajo.
90
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
• Los roles de la BBDD de ARMONÍAS-DGS si tendrán una clara correspondencia
con los roles de UMA, es por eso que su transformación es directa, aunque ajustando
algunas propiedades entre los mismos.
• Los procesos (Process) no tendrán una correspondencia directa, pues es obvio que
en EPFC es lo que estamos modelando, pasando éstos a la categoría de guías en el
metamodelo UMA. Dicho elemento está definido en el capítulo anterior.
• Por último los productos de trabajo (Work Products) si que tendrán una correspondencia
directa, pues abordan el mismo concepto, son consumidos y/o producidas por las tareas.
Una particularidad de este elemento a la hora de exportarlo desde la base de datos de
ARMONÍAS-DGS es que, primero, deberemos introducir el tipo de Producto de trabajo,
distinguiendo entre “Artifact”, “Deliverable” y “Outcome”.
Además deberemos indicar en el mismo campo la naturaleza de los mismos, siendo
ésta “MandatoryInput”, “OptionalInput” y “Output” . Por tanto el campo “type” de la
base de datos de ARMONÍAS-DGS quedaría (como ejemplo) de la siguiente forma
“Artifact;MandatoryInput”. De esta menera, enriqueceremos la base de datos origen ya
que ARMONÍAS-DGS no contempla esta posibilidad.
ARMONÍAS-DGS
ROL
COMPROMISE
CORRESPONDE
ROL
PROCESO
GUÍA
TAREA
TAREA
PROD.TRABAJO
PROD.TRABAJO
Figura 5.4: Correspondencias ARMONÍAS-DGS y UMA
En esta sección se presentan algunos artefactos resultantes de completar la primera iteración.
El primero (Figura 5.5) corresponde a la prueba de concepto que fue necesaria para
componer el documento XML que cargará la herramienta EPFC. Por su sencillez, este primer
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
91
documento no se incluirá en el presente proyecto, no obstante se incluirá el archivo en su
versión completa con el fin de que sirva como ejemplo de estructura para futuros desarrollos.
Figura 5.5: Diseño de Clases Prueba de Concepto
5.2.1.2
Implementación
A continuación, en el listado 5.1, se representa un extracto de código en el que se puede
observar la correspondencia entre tareas comentadas anteriormente. Hay que decir que dicho
extracto es un ejemplo representativo y que su madurez será completa al terminar la segunda
iteración, completando así la automatización de la carga del Contenido de Método.
Después de establecer dicha correspondencia, la herramienta EPFC cargará este archivo
(XML) para poblar su librería de método y así la organización podrá componer sus procesos
usando los elementos incluidos automáticamente en el Contenido de Método.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
p u b l i c s t a t i c v o i d l o a d _ T a s k ( M e t h o d P l u g i n method , V e c t o r d a t a _ t a s k ) {
S t r i n g name= n u l l , i d = n u l l , d e s c r i p t i o n = n u l l , i d _ c o m p a r e = n u l l , n o d e i c o n = n u l l ;
f o r ( i n t z = 0 ; z < d a t a _ t a s k . s i z e ( ) ; z ++) {
/*A continuación rellenaremos los campos de la tarea declarados anteriormente*/
name = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "name" ) ;
i d = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "id" ) ;
d e s c r i p t i o n = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "description" ) ;
i d _ c o m p a r e = u t i l . g e t _ p a r t _ t a s k ( d a t a _ t a s k . g e t ( z ) . t o S t r i n g ( ) , "activity" ) ;
u t i l . i n s e r t _ C o n t e n t E l e m e n t ( method , name , "Task" , i d . r e p l a c e ( " " , "" ) , d e s c r i p t i o n , i d _ c o m p a r e ) ;
}
}
Listado 5.1: Extracto “ActionCargarMethodContent.java”
92
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
5.2.1.3
Pruebas
Para las pruebas en esta etapa temprana del desarrollo se realizaron distintas transformaciones
de elementos de la base de datos a modelos UMA en XML de modo que se fuera comprobando
de forma incremental (cada vez incluyendo más elementos de proceso) en la herramienta
EPFC.
En la presente etapa de la primera iteración únicamente se pudieron hacer pruebas de
serialización (Marshalling) y deserialización (UnMarshalling) de los distintos elementos en
el formato de intercambio seleccionado (XML), no obstante la importación del documento
elaborado mediante la serialización por parte de la herramienta EPFC requirió de pruebas
manuales para dar por finalizada esta etapa de Pruebas.
En el paquete “test” del proyecto desarrollado se encuentra una serie de pruebas en la que
un objeto es serializado y desserializado y se comprueba si los elementos antes y después
coinciden en número y en forma.
5.2.2
Iteración 2: Carga del Contenido de Método de EPFC a partir de
la BBDD ARMONÍAS-DGS
Al finalizar esta iteración podremos componer automáticamente un documento con todos y
cada uno de los elementos que recoge la base de datos de ARMONÍAS-DGS y su correspondencia con el metamodelo UMA y obtendremos mediante la carga del fichero exportado
por EPFC los distintos procesos, junto con los elementos que lo definen para importarlos a
COMPROMISE.
A continuación se puede ver una imagen de la comparativa y cómo reconoce los procesos
definidos.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
93
Figura 5.6: Comparativa de procesos COMPROMISE y EPFC
Cada proceso será un enlace a una página que nos proporcionará toda la información
acerca del mismo.
5.2.2.1
Análisis y Diseño
Como hemos mencionado, una parte fundamental para el desarrollo de esta iteración ha sido
el uso del Plug-in JAXB, descrito en el Capítulo 4.2.4.9.
En esta iteración corresponde integrar las funcionalidades de Marshalling y Unmarshalling en la capa de dominio de la herramienta. Cabe destacar que para hacer uso de ambas
funcionalidades primero se deben tener todas las clases java que, con su serialización, compondrán el documento XML. Hacer esto de manera artesanal sería muy tedioso y propenso
a errores, pues en la mayoría de los casos se trata de un número alto de clases con muchas
relaciones entre ellas, es por eso que el plugin dota a eclipse de mecanismos de generación
de código automático que modela las clases de dominio a partir del esquema (.xsd) y las
genera automáticamente, asegurando que la implementación de cada uno de los elementos es
conforme al metamodelo.
94
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Figura 5.7: Generar Clases con JAXB
Una vez obtenidas las clases correspondientes a los distintos elementos del metamodelo
UMA, se hace necesario elaborar una estructura en forma de árbol que tendrá los componentes
y los procesos de la organización a tratar y que, por tanto, compondrán el documento en
cuestión. Hay que recordar que a pesar de hacer uso del metamodelo UMA, éste es compatible
con SPEM. Los elementos y su jerarquía se encuentran en la Figura 5.8:
Figura 5.8: Jerarquía de Elementos para la definición de Procesos en SPEM 2.0[10]
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
95
A continuación, en la Figura 5.9, se presenta el diagrama de clases de diseño correspondiente a la funcionalidad de obtención de procesos de una organización por parte de
COMPROMISE. Una vez guardados los procesos de la organización que provienen del documento XML generado por EPFC (después de componer los procesos), éstos son cargados a la
base de datos de COMPROMISE, para posteriormente visualizarlos en la Web y poder operar
con ellos. Además de su obtención, el conocer los procesos de la organización será un paso
previo a operar con ellos en forma de gráficas, estadísticas, etc.
Figura 5.9: Diagrama de Diseño correspondiente a la obtención de Procesos de la Organización
Como enuncia la segunda iteración, además de la serialización y deserialización de archivos de intercambio (XML), corresponde a la presente iteración la integración de estas
funcionalidades en la arquitectura definida en la Fase de Inicio. En la Figura 5.10 podemos
observar un diagrama de la herramienta COMPROMISE integrada en el framework de Struts
2, haciendo uso del patrón Modelo-Vista-Controlador.
96
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Figura 5.10: Diagrama General de la Herramienta con Struts2
A modo de esquema se presenta la Arquitectura definida integrada con el framework
Struts2, que permitirá desarrollar COMPROMISE de acuerdo a las políticas propias del patrón
MVC, proporcionando una serie de implementaciones (por ejemplo la clase ActionSupport)
que nos ayudan a hacer un uso correcto del paradigma en tres capas.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
97
Figura 5.11: Estructura General Paquetes COMPROMISE
5.2.2.2
Implementación
A continuación se representa un extracto de código representativo de la presente iteración.
En la Figura 5.2 se encuentra el código correspondiente a la función Marshaller (Sección
4.2.4.9) de JAXB a la que posteriormente dio lugar esta prueba de concepto, mientras que
en la Listado F.2 (en el apéndice de Código) se encuentra la implementación de la función
UnMarshaller (Sección 4.2.4.9).
1
2
3
4
5
6
7
8
9
10
11
12
13
JAXBContext c o n t e x t ;
try {
c o n t e x t = JAXBContext . n e w I n s t a n c e ( M e t h o d L i b r a r y . c l a s s ) ;
Marshaller marshaller = context . createMarshaller () ;
m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_FORMATTED_OUTPUT, t r u e ) ;
F i l e W r i t e r f i l e = new F i l e W r i t e r ( "./DB12.xml" ) ;
m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_ENCODING , "ISO-8859-1" ) ;
m a r s h a l l e r . m a r s h a l ( method , f i l e ) ;
} c a t c h ( JAXBException e ) {
e . printStackTrace () ;
}
Listado 5.2: Ejemplo Marshall.
98
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Como podemos observar en el código nos definimos un contexto JAXB (línea 3) con
la instancia que queremos que tenga como padre de las demás, en este caso es la clase
MethodLibrary. Después creamos un fichero, que será el que contendrá nuestro archivo XML
(línea 7) y por último, después de definir una serie de propiedades del objeto marshaller (línea
8), introducimos el contenido (method) en el fichero en la línea 10.
5.2.2.3
Pruebas
A continuación se presenta una prueba en la que el documento es compuesto y en el que es
creado bajo el nombre de fichero_test.xml. Se comprueba que una vez creado, éste existe y no
ha dado ningún problema. Será tarea de la herramienta EPFC encargarse de su validación, y
de esta manera comprobamos que es un fichero creado conforme al metamodelo UMA y que
todos sus elementos son pasados al contenido de método de la Librería de Método definida en
el documento.
1
2
3
4
5
6
7
8
9
10
11
M e t h o d L i b r a r y method = new M e t h o d L i b r a r y ( ) ;
JAXBContext c o n t e x t ;
try {
c o n t e x t = JAXBContext . n e w I n s t a n c e ( M e t h o d L i b r a r y . c l a s s ) ;
Marshaller marshaller = context . createMarshaller () ;
m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_FORMATTED_OUTPUT, t r u e ) ;
F i l e f i l e = new F i l e ( "./fichero_test.xml" ) ;
m a r s h a l l e r . s e t P r o p e r t y ( M a r s h a l l e r . JAXB_ENCODING , "ISO-8859-1" ) ;
m a r s h a l l e r . m a r s h a l ( method , f i l e ) ;
assertTrue ( file . exists () ) ;
Listado 5.3: Test Composición XML.
5.2.3
Iteración 3: Implementación de las funciones para el Análisis de
Conformidad de Procesos
En esta iteración nos ocupará el establecimiento de un mecanismo que permita medir la
conformidad de los procesos de la organización respecto con un modelo de referencia. Se
pudo observar la cantidad de bibliografía que hay respecto al Compliance (Compromiso) en
los procesos de negocio, sin embargo observamos que no hay demasiada al respecto cuando a
procesos software nos referimos, tal como se ha descrito en el capítulo 3.
Es por eso que tras sucesivas reuniones, se determinó que uno o varios procesos tendrá
conformidad con un modelo si todas y cada una de las taras de éste último están correctamente
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
99
implementadas por la organización (o en su defecto un número alto previamente fijado antes
de la evaluación), además deberá disponer de todos los activos necesarios para su ejecución
satisfactoria (herramientas, roles que se ocupen de ciertas tareas, etc.).
5.2.3.1
Análisis y Diseño
A partir de aquí se planteó el problema de cómo lograr la correspondencia automática entre
tareas. Es por eso que se determinaron tres vías para resolverlo, presentadas a continuación:
• Mediante la comparación del nombre: El nombre de la tarea en el proceso de la
organización se debe corresponder íntegramente con el nombre de la tarea perteneciente
al modelo de referencia. Esta solución es idónea si se conservan los nombres (en nuestro
caso lo conservaría, pues la tarea con la que formamos el proceso en EPFC proviene del
modelo de referencia cargado a partir de la bbdd de ARMONÍAS-DGS.), no obstante
en el momento en que los nombres cambien no habrá correspondencia, aunque sea la
misma tarea.
• Comparación del id: Es una forma unívoca y muy útil, no obstante ocurrirá lo mismo
que con el anterior, si hay algún problema la detección de la correspondencia entre
ambas tareas fallará.
• Con un ratio definido del nombre y propiedades de la tarea: Proponer un ratio de
concordancia de nombre, de esta manera definiremos un umbral a partir del cual se
considera que una tarea corresponde con otra.
En un origen la herramienta da opción al uso de cualquiera de las tres posibilidades,
incluso a la selección de las tres (Figura 5.12). No obstante, conforme fue creciendo la
madurez del proyecto se determinó que estas funciones se reducirían a una sola en lo sucesivo,
únicamente comparandose el nombre en la continuación del desarrollo.
100
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Figura 5.12: Prototipo de Interfaz para la visualización de la conformidad
A continuación se presentan dos diagramas correspondientes a la etapa de análisis y
diseño. Por un lado, en la Figura 5.13 corresponden a los pasos que sigue la herramienta para
obtener el análisis de conformidad de un proceso.
Figura 5.13: Diagrama clases de análisis para evaluar la Conformidad de Proceso
En la figura 5.14, se muestra el diseño de las clases que intervienen en la función de
Recomendador. Recordar que la función recomendador nos indica los elementos que nos
faltan para completar un marco de referencia (Tareas, Herramientas y Roles).
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
101
Figura 5.14: Diagrama Clases Recomendador
Por último, otra funcionalidad a completar al término de esta iteración fue la de recomendador. Esta función indica cuánto nos falta por implementar y lo que tenemos implementado
(elementos del marco de referencia) además de apoyarnos en el gráfico de barras 5.12 que nos
indica el tanto por ciento de tareas que reunimos para cada uno de los marcos de referencia.
102
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Figura 5.15: Gráfica de Compliance total de la organización.
5.2.3.2
Implementación
A continuación, en el Listado 5.4, podemos observar la implementación de los aspectos
mencionados. Las listas “porcentaje_compliance_g1” y “nombre_compliance_g1” contienen
los nombres de los procesos y el tanto por ciento de la concordancia de las tareas del proceso
con las del modelo de calidad examinado. Haremos esta función para cada una de las gráficas
presentes en la herramienta.
Como podemos ver en la línea 11, las tareas con las que comparamos están en la base de
datos de ARMONÍAS-DGS.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public void realiza_compliance ( ) {
f o r ( i n t i = 0 ; i < p r o c e s o s . s i z e ( ) ; i ++) {
//metemos el proceso en el array que representaremos
n o m b r e _ c o m p l i a n c e _ g 1 [ i ] = p r o c e s o s . g e t ( i ) . getName ( ) ;
//sacamos todas las tareas y comparamos el nombre con la bbdd de armonías.
Vector tasks_armonias = u t i l . getAll_Task_by_Process_Vector ( s e l e c c i o n _ h i s t o r i c o ) ;
a u x _ t a r e a s _ o r g = t a s k _ m a n a g e r . g e t T a s k b y P r o c e s s ( p r o c e s o s . g e t ( i ) . getName ( ) ) ;
f o r ( i n t j = 0 ; j < a u x _ t a r e a s _ o r g . s i z e ( ) ; j ++) {
i f ( u t i l . e x i s t T a s k ( s e l e c c i o n _ h i s t o r i c o , a u x _ t a r e a s _ o r g . g e t ( j ) . getName ( ) ) ) {
p e r c e n t ++;
}
}
p o r c e n t a j e _ c o m p l i a n c e s _ g 1 [ i ] = ( i n t ) ( ( ( double ) p e r c e n t / ( double ) t a s k s _ a r m o n i a s . s i z e ( ) ) *100) ;
}
}
Listado 5.4: Ejemplo clase Manager.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
103
Para llevar a cabo la implementación de la función Recomendador es de vital importancia
haber hecho la de conformidad, pues en realidad se basa en ella. Es decir, para cada marco
de referencia extraemos las tareas que posee (de la BBDD de ARMONÍAS-DGS) y vamos
comparando todas y cada una de ellas con las de los procesos de la organización, de esta
forma se sabe en cada instante que porcentaje de tareas del marco de referencia están cubiertas
por la organización.
En la siguiente iteración, serán estas listas las que provean de datos a las gráficas para
representarlos.
5.2.3.3
Pruebas
En la etapa de pruebas correspondientes a la presente iteración elaboraremos casos de prueba
para la función recomendador. Como hemos enunciado con anterioridad, dicha función tiene
como objetivo proveer al usuario de aspectos por implementar para lograr la conformidad
con los marcos armonizados de procesos deseada. Estas pruebas han sido realizadas bajo
un entorno controlado y con procesos definidos previamente conociendo el resultado de los
valores analizados.
En el método setUp() que inicia el test de la Figura 5.5, se llama a funcion_recomendador(),
el cual debe retornar valores para las listas tareas_por_representar, roles_por_representar y
herramientas_por_representar. En la primera función de test llamada testCreacion() (líneas
8, 9 y 10) se comprueban que éstas hayan tomado los valores devueltos por la función
anterior. En el test denominado Insercion_correcta se comprueba que cumplen con los valores
establecidos de manera manual. Por último en el test generacion_reporte() se comprueba que
los métodos que devuelven en forma de cadena de caracteres los valores por implementar no
estén vacíos.
104
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
@Before
p u b l i c void setUp ( )
{
funcion_recomendador ( ) ;
}
@Test
public void t e s t C r e a c i o n ( ) {
assertNotNull ( tareas_por_representar ) ;
assertNotNull ( roles_por_representar ) ;
assertNotNull ( herramientas_por_representar ) ;
}
@Test
public void I n s e r c i o n _ c o r r e c t a ( ) {
a s s e r t T r u e ( t a r e a s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==25) ;
a s s e r t T r u e ( r o l e s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==3) ;
a s s e r t T r u e ( h e r r a m i e n t a s _ p o r _ r e p r e s e n t a r . s i z e ( ) ==1) ;
}
@Test
public void g e n e r a c i o n _ r e p o r t e ( ) {
a s s e r t N o t E q u a l s ( T a r e a s _ p a r a _ I n f o r m e ( ) , "" ) ;
a s s e r t N o t E q u a l s ( H e r r a m i e n t a s _ p a r a _ I n f o r m e ( ) , "" ) ;
a s s e r t N o t E q u a l s ( R o l e s _ p a r a _ I n f o r m e ( ) , "" ) ;
}
Listado 5.5: Test Función Recomendador.
5.2.4
Iteración 4 : Implementación de Módulo de Representación gráfica de estadísticas.
En esta iteración se pretende dotar a la herramienta de mecanismos de representación de los
niveles de conformidad de los distintos procesos que posee la organización. Es por eso que se
hace necesario implementar gráficas dinámicas para la representación de dichos datos.
Para ello hemos hecho uso de la librería Chart de JavaScript. Esta librería, basada en
HTML 5, nos permite crear gráficos como los de las figuras 5.16 y 5.17.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
105
Figura 5.16: Ejemplo gráfica Barras de Compliance
Figura 5.17: Ejemplo gráfica Área de Compliance
En las figuras anteriores, el color rojo representa el porcentaje de tareas del proceso que
forman parte del marco de referencia con el que se comparan (color azul). En el ejemplo podemos ver como el proceso “Preparar Documentación” no tiene ninguna tarea implementada
(del marco de referencia con el que comparamos), mientras que el proceso de “Pruebas” sí
que las tiene. Como hemos mencionado antes el color azul representa el ratio de aceptación
en el que se considera que un proceso cumple con el estándar. Dicho ratio será definido por el
usuario en un panel de selección implementado en una iteración posterior.
106
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Por último se planteó la automatización de generación de documentos PDF con los
resultados de la función recomendador de la iteración anterior. En la parte de implementación
de esta iteración, en la Figura 5.6, podemos ver parte del código que se encarga de este
cometido. A modo de ejemplo se incluirá en el proyecto un archivo de ejemplo de esta función
que recogerá a modo de lista los elementos implementados y los que restan de implementar
para que la conformidad con el marco de procesos sea plena.
5.2.4.1
Análisis y Diseño
A continuación se presenta un diagrama de diseño, en la figura 5.18 en la que se puede ver
la nueva funcionalidad añadida de Generar Informe. Esta función hará uso de la función
Recomendador expuesta en la iteración anterior.
Figura 5.18: Diagrama de clases de Diseño Generar Informe
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
107
En la Figura 5.19 se incluye un diagrama de análisis que expresa la arquitectura de la
función recomendador, así como de la extracción de informes mencionada con anterioridad.
En la etapa de análisis de la presente iteración se determinó la extracción de dicho documento
con el fin de lograr el desacoplamiento entre la información proporcionada y COMPROMISE,
pues de esta forma ésta será portable, posibilitando la transmisión de conocimiento entre
los miembros de la organización y ofreciendo la posibilidad de la persistencia en distintos
momentos de evaluación de la conformidad de procesos.
Figura 5.19: Diagrama de clases de Análisis para generar PDF[10]
108
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
5.2.4.2
Implementación
A continuación, en la figura 5.6 se presenta una simplificación, a modo ilustrativo, de la función
automática para la generación automática de informes PDF. Los datos que representaremos
en el informe real vendrán determinados por la salida de la función recomendador.
1
2
3
4
5
6
7
8
9
10
11
12
13
public String realizarInforme () {
try {
O u t p u t S t r e a m f i l e = new F i l e O u t p u t S t r e a m ( new F i l e ( "C:\\Test.pdf" ) ) ;
Document document = new Document ( ) ;
P d f W r i t e r . g e t I n s t a n c e ( document , f i l e ) ;
document . open ( ) ;
S t r i n g t a r e a s = LoginAction . Tareas_para_Informe ( ) ;
document . add ( new P a r a g r a p h ( t a r e a s ) ) ;
document . c l o s e ( ) ;
f i l e . close () ;
} catch ( Exception e )
Listado 5.6: Código de generación de documentos PDF.
Como hemos mencionado en el capítulo de Objetivos del presente TFG, COMPROMISE
también sirve de nexo entre distintas herramientas. A parte de ARMONÍAS-DGS, integrada
en la primera iteración, COMPROMISE necesita de otras tres para completar su funcionalidad, MediniQVT, EPFC y Eclipse BPMN Modeler. Parte de esa integración consiste en
la transmisión de los datos mediante archivos de intercambio (los mencionados XML), no
obstante se desea interactuar con las herramientas anteriormente nombradas y es por eso que
a partir de la presente podrán ejecutarse desde el menú principal de COMPROMISE.
Sin embargo se hace necesario conocer las rutas en las que éstas están ubicadas (las herramientas estarán incluidas en el proyecto), en esta iteración corresponde la implementación
de esta funcionalidad, dejando los formularios de introducción en iteraciones posteriores.
Hay que tener en cuenta que las herramientas mencionadas deben mantener la jerarquía de
carpetas proporcionadas, pues las rutas de los espacios de trabajo (Workspace) de cada una de
ellas serán determinantes a la hora de lograr una ejecución satisfactoria. A pesar de que casi
la totalidad de la funcionalidad respecto a la invocación de las herramientas es completada en
esta iteración, corresponde a las últimas etapas elaborar el formulario correspondiente para la
introducción automática de las rutas.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
5.2.4.3
109
Pruebas
En esta etapa de la iteración se probará la generación de documentos PDF. En la Figura 5.7 se
muestra una parte del código relativo a esta función.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
p u b l i c void t e s t ( ) throws DocumentException , IOException {
String ruta = null ;
S t r i n g s S i s t e m a O p e r a t i v o = System . g e t P r o p e r t y ( "os.name" ) ;
Document document = new Document ( ) ;
OutputStream f i l e ;
f i l e = new F i l e O u t p u t S t r e a m ( new F i l e ( "C:\\Test.pdf" ) ) ;
P d f W r i t e r . g e t I n s t a n c e ( document , f i l e ) ;
document . open ( ) ;
S t r i n g t a r e a s = RecomendadorAction . T a r e a s _ p a r a _ I n f o r m e ( ) ;
S t r i n g h e r r a m i e n t a s =RecomendadorAction . H e r r a m i e n t a s _ p a r a _ I n f o r m e ( ) ;
S t r i n g r o l e s = RecomendadorAction . Roles_para_Informe ( ) ;
document . add ( new P a r a g r a p h ( "Informe de Compliance del Modelo" ) ) ;
document . add ( new P a r a g r a p h ( t a r e a s ) ) ;
document . add ( new P a r a g r a p h ( h e r r a m i e n t a s ) ) ;
document . add ( new P a r a g r a p h ( r o l e s ) ) ;
document . c l o s e ( ) ;
f i l e . close () ;
a s s e r t T r u e ( s S i s t e m a O p e r a t i v o . c o n t a i n s ( "Windows" ) ) ;
a s s e r t F a l s e ( t a r e a s . e q u a l s I g n o r e C a s e ( "" ) ) ;
a s s e r t F a l s e ( h e r r a m i e n t a s . e q u a l s I g n o r e C a s e ( "" ) ) ;
a s s e r t F a l s e ( r o l e s . e q u a l s I g n o r e C a s e ( "" ) ) ;
}
Listado 5.7: Test salida documento PDF.
110
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
5.2.5
Iteración 5: Integración de la capa de Persistencia con COMPROMISE
Los modelos de referencia (armonizados y no armonizados) se encuentran en la base de datos
de ARMONÍAS-DGS y mediante la función Cargar Contenido de Método, COMPROMISE
permite representar este conocimiento en lenguaje XML para que pueda ser procesado por
herramientas como EPFC. Un paso posterior será definir los procesos con el contenido importado y guardar dichos procesos en otro archivo de intercambio XML para cargar los procesos
en COMPROMISE. En el momento en el que esto ocurre poblaremos nuestra base de datos
con los procesos que no tengamos guardados de cargas de archivos anteriores. El diagrama
que se muestra en lo sucesivo a este apartado (Figura 5.23) pertenece a la base de datos de la
herramienta.
A continuación se muestra un ejemplo de la estructura de un proceso definido mediante
EPFC, ésta puede tener iteraciones, actividades, fases, etc. con relaciones entre ellas. Este
tipo de relaciones se ven plasmadas en el modelo de base de datos propuesta y son recogidas
en el momento de carga del documento intercambiado en COMPROMISE.
Figura 5.20: Ejemplo de Proceso definido con EPFC
En la siguiente imagen se puede ver la composición jerárquica de un proceso definido en
EPFC. Cabe destacar que la necesidad de la base de datos radica, además de almacenar los
datos relativos a las organizaciones, en dar cabida al nuevo tipo de definición de proceso, pues
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
111
por ejemplo un proceso puede estar definido por una fase, que a su vez contiene a otra, y ésta
una actividad que contiene a otra. Mediante la jerarquía definida en el diseño de la base de
datos de ARMONÍAS-DGS, almacenar el proceso con todos sus elementos en árbol no es
posible.
Figura 5.21: Descomposición Proceso
Otro objetivo a abordar dentro de esta iteración es la gestión de nuevos usuarios, nuevas
herramientas, nuevos roles a la hora de abordar tareas, etc. Esta problemática se soluciona
mediante una interfaz visible al administrador de la organización y al de la herramienta, en la
que es posible introducir roles, herramientas, activos, nuevos usuarios y nuevas organizaciones.
A continuación, en la figura 5.22, se muestra un ejemplo de alta de usuario:
Figura 5.22: Alta de Usuario
Una parte fundamental de esta iteración será la utilización del ORM Hibernate, que nos
permitirá abstraernos de la complejidad que supone el almacenamiento de cada uno de los
112
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
atributos de las clases utilizadas para representar los elementos de COMPROMISE (procesos,
iteraciones, hitos, etc.).
Por último al finalizar la presente iteración deberemos obtener las funcionalidades de
subida y bajada de archivos al servidor, para el posterior procesamiento de los mismos. El
usuario dispondrá de una ventana que permita la selección de archivos de subida así como de
rutas en las que se guardarán los archivos procesados que provienen del servidor.
5.2.5.1
Análisis y Diseño
Como podemos ver a continuación, la base de datos guarda todos los usuarios de la herramienta, así como las organizaciones junto con todos sus activos (considerando los procesos y
todos sus elementos relacionados también como tal) e históricos de conformidad. Además, en
lo relativo a las funciones de conformidad, todos los procesos junto con sus elementos son
almacenados en ella. Cabe destacar que esta base de datos se usa para tareas de representación
de elementos en la herramienta, labores de análisis de conformidad con los marcos de procesos
persistentes en la base de datos de ARMONÍAS-DGS, obtención de procesos a la hora de
realizar transformaciones entre modelos mediante el paradigma de DSDM y elaboración de
informes.
name VARCHAR(100)
Role VARCHAR(100)
Password VARCHAR(45)
Organization
idhistorico_compliance INT
name VARCHAR(100)
porcentaje VARCHAR(45)
address VARCHAR(200)
observaciones VARCHAR(700)
telephone VARCHAR(45)
Quality_model
name VARCHAR(200)
Organization_name VARCHAR(100)
logo_url VARCHAR(300)
purpose VARCHAR(500)
Quality_model_name VARCHAR(200)
approach VARCHAR(500)
Indexes
Organization_name V…
Indexes
Indexes
Process
idProcess INT
name VARCHAR(100)
Indexes
description VARCHAR(…
purpose VARCHAR(600)
Organization_has_Process
Organization_name VARCHAR(100)
Process_idProcess INT
Activity
objectives VARCHAR(6…
idActividad INT
Quality_model_name V…
nombre VARCHAR(45)
descripcion VARCHAR(45)
Indexes
Indexes
Process_idProcess INT
Activity_idActividad INT
Fase_idFase INT
Task
idTask INT
Iteracion_idIteracion INT
name VARCHAR(300)
description VARCHAR(800)
Indexes
Activity_idActividad INT
Fase_idFase INT
Iteracion_idIteracion INT
1 more...
Indexes
Role
Tool
Activo
idRole INT
idTool INT
idActivo INT
name VARCHAR(200)
name VARCHAR(300)
name VARCHAR(300)
description VARCHAR(800)
description VARCHAR(800)
description VARCHAR(800)
type VARCHAR(200)
Organization_name VARCHAR(100)
value INT
skills VARCHAR(800)
capabilities VARCHAR(800)
Organization_name VARCHAR(100)
Indexes
Organization_name VARCHAR(100)
Indexes
Indexes
Work_Product
idWork_Product INT
Fase
name VARCHAR(200)
idFase INT
description VARCHAR(700)
name VARCHAR(200)
features INT
Activity_idActividad INT
Task_idTask INT
Process_idProcess INT
1 more...
Indexes
Indexes
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
historico_compliance
User
idUser INT
Iteracion
idIteracion INT
name VARCHAR(250)
Activity_idActividad INT
Process_idProcess INT
Iteracion_idIteracion INT
Indexes
Milestone
idMilestone INT
description VARCHAR(400)
Process_idProcess INT
Activity_idActividad INT
Fase_idFase INT
Iteracion_idIteracion INT
Indexes
113
Figura 5.23: Diagrama de base de datos de COMPROMISE
114
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
A continuación, en la Figura 5.24 se adjunta la parte de la definición de la base de datos de
la herramienta ARMONÍAS-DGS que utilizaremos. Como podemos ver, aunque hay algunas
similitudes, las diferencias son notables:
Figura 5.24: Simplificación BBDD Armonias-DGS
Otra parte importante del desarrollo que tiene cabida en la presente iteración es el menú
de administración. Éste, como hemos comentado, será oculto al rol de gestor de procesos y
permitirá introducir nuevos usuarios, activos, herramientas y roles, en caso de que el rol del
usuario sea el correcto permitirá añadir nuevas organizaciones a nuestro proyecto, cambiar las
rutas de las herramientas relacionadas con COMPROMISE, además de seleccionar el grado
de aceptación de cada proceso por separado para su posterior visualización en las gráficas del
panel principal. Esta última funcionalidad se ilustra con la Figura 5.25.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
115
Figura 5.25: Selección márgen de aceptación para Proceso
5.2.5.2
Implementación
Como hemos mencionado en el Capítulo 4, para lograr la persistencia de nuestros elementos
se ha optado por el ORM Hibernate. Esta herramienta permite insertar objetos directamente,
asumiendo éste las funciones del establecimiento de la correspondencia entre los atributos
del objeto en cuestión y de la base de datos. Para nuestra herramienta se han definido
previamente estos objetos como clases .java indicándole a hibernate los distintos atributos
que deseamos incluir mediante anotaciones presentes en la librería javax.persistence. A
continuación, en la Figura 5.8 se presenta una parte del código relativo la persistencia de un
Proceso. Todas las clases que necesitan de funciones de almacenamiento se encuentran en el
paquete hibernate.model.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
@Id
@GeneratedValue
@Column ( name="idActivo" )
public int getIdActivo () {
return idActivo ;
}
@Column ( name="name" )
p u b l i c S t r i n g getName ( ) {
r e t u r n name ;
}
@Column ( name="description" )
public String getDescription () {
return description ;
}
@Column ( name="value" )
public String getValue ( ) {
return value ;
}
@Column ( name="Organization_name" )
public String getOrganization_name () {
return organization_name ;
}
Listado 5.8: Persistencia objeto Proceso.
116
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Además, como mencionábamos en la sección anterior, al término de esta iteración se
tendrá una versión funcional de la herramienta con la funcionalidad de subida y bajada de
archivos al servidor. Para llevar a cabo esta función deberemos hacer usos de los mecanismos
que Struts2 nos ofrece. Para ello deberemos configurar un interceptor que se ejecutará antes
de la acción correspondiente, en el que definiremos las propiedades que el archivo deba tener.
El ejemplo de este interceptor se ilustra en el Listado 5.9.
1
2
3
4
5
6
7
8
9
10
11
12
< a c t i o n name="resultAction" c l a s s ="actions.FileUploadAction">
< i n t e r c e p t o r −r e f name="exception" / >
< i n t e r c e p t o r −r e f name="i18n" / >
< i n t e r c e p t o r −r e f name="fileUpload">
<param name="allowedTypes"> t e x t / xml< / param >
<param name="maximumSize">102400 < / param >
< / i n t e r c e p t o r −r e f >
< i n t e r c e p t o r −r e f name="workflow">
<param name="excludeMethods"> i n p u t < / param >
< / i n t e r c e p t o r −r e f >
< r e s u l t t y p e ="redirectAction"> c a r g a r _ n u e v o s P r o c e s o s < / r e s u l t >
</ action>
Listado 5.9: Ejemplo Interceptor.
5.2.5.3
Pruebas
En la etapa de pruebas de esta iteración se han probado funcionalidades relativas a las bases
de datos de COMPROMISE y de la herramienta ARMONÍAS-DGS. Un extracto del código
de las pruebas (Listado 5.10) presenta la inserción de un nuevo Rol en nuestra herramienta.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
1
2
3
4
5
6
7
8
9
10
11
12
13
117
public class GestionActivos {
@Test
p u b l i c void NuevaHerramienta ( ) {
h i b e r n a t e . c o n t r o l l e r . ToolManager t o o l _ m a n a g e r = new ToolManager ( ) ;
h i b e r n a t e . model . T o o l t o o l = new T o o l ( "prueba" , "prueba" , "CMMI-DEV 1.3" , "Organisoft" ) ;
t o o l _ m a n a g e r . add ( t o o l ) ;
a s s e r t T r u e ( t o o l _ m a n a g e r . e x i s t s _ b y _ n a m e ( "prueba" ) ) ;
}
@Test
p u b l i c v o i d NuevoRol ( ) {
h i b e r n a t e . c o n t r o l l e r . RoleManager r o l _ m a n a g e r = new RoleManager ( ) ;
h i b e r n a t e . model . R o l e r o l e _ a u x = new R o l e ( "prueba" , "prueba" , "prueba" , "prueba" , "prueba" , "Organisoft
") ;
14
15
16
17
18
19
20
21
22
23
24
25
26
r o l _ m a n a g e r . add ( r o l e _ a u x ) ;
a s se r t T r ue ( rol_manager . e x i s t _ r o l e ( role_aux ) ) ;
a s s e r t T r u e ( r o l _ m a n a g e r . e x i s t s _ b y _ n a m e ( "prueba" ) ) ;
}
@Test
p u b l i c void NuevoUsuario ( ) {
h i b e r n a t e . c o n t r o l l e r . UserManager u s e r _ m a n a g e r = new UserManager ( ) ;
h i b e r n a t e . model . U s e r u s e r = new U s e r ( "prueba" , "pruebas" , "pruebas" , "Organisoft" ) ;
u s e r _ m a n a g e r . add ( u s e r ) ;
a s s e r t T r u e ( u s e r _ m a n a g e r . g e t U s e r O r g a n i z a t i o n ( "prueba" ) . e q u a l s ( "Organisoft" ) ) ;
}
}
Listado 5.10: Test Nuevo Rol.
5.2.6
Iteración 6: Definir transformación entre los metamodelos UMA
y BPMN
En esta iteración abordamos el componente de transformación entre los modelos UMA y
BPMN. Como hemos mencionado en capítulos anteriores, haremos uso del framework Medini
QVT para realizar la transformación. Se harán necesarios los metamodelos UMA y BPMN
con extensión .ecore. Este último metamodelo tiene una estrecha relación con otros tres, que
son DI.ecore (parte de los diagramas), DC.ecore (parte de propiedades) y BPMNDI.ecore
(recoge aspectos organizacionales de los anteriores).
Además se aborda el validador de sesión de usuario que, si éste no se ha identificado
no podrá ejecutar ninguna acción de la herramienta, remitiendo al usuario a la página de
inicio, en la que se tendrá que identificar para hacer uso de ella. Para el validador de usuario
es imprescindible haber logrado la completitud de la anterior iteración, pues será sobre la
persistencia que ofrece la tecnología Hibernate sobre la que se apoyará esta función.
118
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
Por último otro producto de trabajo importante será la introducción de un menú interactivo
[5] por el cual el usuario podrá seleccionar las distintas opciones que posee COMPROMISE
de forma intuitiva y atractiva, con efectos visuales que permiten una mejor experiencia para el
usuario. Los efectos del mismo están implementados bajo la tecnología de JQuery.
Figura 5.26: Menú de Selección COMPROMISE
5.2.6.1
Análisis y Diseño
En la Figura 5.27 podemos observar el flujo de clases y métodos que sigue el usuario de
COMPROMISE para lograr una transformación entre los modelos UMA y BPMN2.0. Para
ello, primero deberemos crear un documento (que obtendrá la herramienta MediniQVT)
que recoja todos los procesos de la organización. Una vez hecho esto, deberemos ejecutar
MediniQVT como ilustra el manual de instalación y ejecutar la transformación.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
119
Figura 5.27: Diagrama de Análisis para la función de Transformación entre Modelos
Como salida de este procesamiento tenemos un fichero con extensión .bpmn cuyo objetivo
es la representación en el framework BPMN Modeler. Antes de lograr este fin deberemos
realizar un posprocesamiento (automatizado mediante COMPROMISE) del mismo, pues
aunque prácticamente la totalidad de los motores de procesos son conformes al metamodelo
BPMN, cada uno los representa con un formato distinto, es es por eso que se deberá definir una
estructura a partir del metamodelo BPMN mediante JAXB Este posprocesamiento convierte
un conjunto de tareas de un proceso software, en un proceso de negocio, con una precedencia
entre tareas y con un evento de principio y fin. A continuación se plantean dos vistas, la
primera con la estructura jerárquica tanto del proceso en cuestión como de su representación
gráfica.
Figura 5.28: Ejemplo de estructura deproceso definida con EPFC en la herramienta BPMN2
Modeler
120
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
En la siguiente Figura se presenta una imagen con las tareas del proceso de negocio a
modo de cascada y con un evento de inicio y otro de fin.
Figura 5.29: Ejemplo proceso BPMN
5.2.6.2
Implementación
Un artefacto de salida de esta iteración es el código de la transformación, expuesto en lo
sucesivo. Hay que mencionar que se ha realizado una transformación únicamente de tareas,
pues determinar la correspondencia de elementos entre ambos metamodelos es una tarea que
escapa al alcance del presente Trabajo de Fin de Grado, proponiéndose como trabajo futuro.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
121
t r a n s f o r m a t i o n uma2bpmn (UMA: uma , BPMN2 : bpmn2 ) {
key d e f i n i t i o n s { i d , name } ;
key P r o c e s s { i d , name } ;
t o p r e l a t i o n TaskToBPMNTask{
name_process : S t r i n g ;
element : String ;
id : String ;
c h e c k o n l y domain UMA p r o c e s o : uma : : D e l i v e r y P r o c e s s {
name = n a m e _ p r o c e s s ,
id = id
};
c h e c k o n l y domain UMA e l e m e n t o s : uma : : BreakdownElement {
name = e l e m e n t
};
e n f o r c e domain BPMN2 d e f i n i c i o n : bpmn2 : : d e f i n i t i o n s {
i d =’Definition’ ,
name = n a m e _ p r o c e s s ,
t a r g e t N a m e s p a c e =’Mi_ejemplo_de_proceso’ ,
t y p e L a n g u a g e =’http://www.java.com/javaTypes’ ,
e x p r e s s i o n L a n g u a g e =’http://www.mvel.org/2.0’ ,
r o o t E l e m e n t s = f : bpmn2 : : P r o c e s s {
name = name ,
i d = id ,
f l o w E l e m e n t s = e l : bpmn2 : : Task {
name = e l e m e n t
}
}
};
}
}
Listado 5.11: Ejemplo de código de la Transformación.
El otro aspecto importante de esta iteración es el código que representa la validación de
usuario. Esta implementación la utilizaremos en las acciones en las que las funcionalidades
estén restringidas a determinados roles, o simplemente para comprobar que hay un usuario
registrado y que no se ha saltado la fase de login (si es así se le remitirá a la página de
identificación). Estos codigos están representados en los Listados 5.12 y 5.13 respectivamente
1
2
3
4
5
6
7
S t r i n g c o n f i r m a c i o n = A c t i o n S u p p o r t . ERROR ;
L i s t < h i b e r n a t e . model . User > u s u a r i o _ a _ v a l i d a r = u s e r m a n . V a l i d a t e U s e r ( u s u a r i o , pwd ) ;
i f ( usuario_a_validar . size ( ) !=0) {
c o n f i r m a c i o n = A c t i o n S u p p o r t . SUCCESS ;
s e s s i o n . p u t ( "user" , u s u a r i o _ a _ v a l i d a r ) ;
}
Listado 5.12: Introducir el objeto usuario al validar la sesión (Login)
122
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
1
A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t < User > ) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) . g e t ( "
user" ) ;
Listado 5.13: Recuperar Objeto Usuario en una Acción para posteriormente
evaluarlo.
5.2.6.3
Pruebas
En esta etapa de la iteración realizaremos test de validación de usurios. La Figura 5.14
es un ejemplo de ello. Podemos ver como en la función setUp() creamos un usuario y
lo introducimos en la sesión para posteriormente recuperarlo en el método testCreacion(),
correspondiente al test, y ver que hay un usuario con nombre Matias. Cabe destacar que
para realizar los test es necesario tener el servidor funcionando y haber llamado a la acción
correspondiente.
1
2
3
4
5
6
7
8
9
10
11
12
@Before
p u b l i c void setUp ( )
{
Map s e s s i o n = A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) ;
h i b e r n a t e . c o n t r o l l e r . UserManager u s e r m a n = new h i b e r n a t e . c o n t r o l l e r . UserManager ( ) ;
L i s t < h i b e r n a t e . model . User > u s u a r i o _ a _ v a l i d a r = u s e r m a n . V a l i d a t e U s e r ( "matias" , "a" ) ;
s e s s i o n . p u t ( "usuario" , u s u a r i o _ a _ v a l i d a r ) ;
}
@Test
public void t e s t C r e a c i o n ( ) {
A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t < User > ) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) .
g e t ( "usuario" ) ;
13
14
a s s e r t T r u e ( u s u a r i o . s i z e ( ) ==1) ;
a s s e r t T r u e ( u s u a r i o . g e t ( 0 ) . getName ( ) . e q u a l s ( "matias" ) ) ;
Listado 5.14: Test Validar Sesión
5.2.7
Iteración 7: Documentación de la herramienta
En esta iteración tendrá como objetivos la integración de COMPROMISE con las herramientas de modelado y desarrollo que la complementan. Para ello deberemos proponer los
mecanismos necesarios para su ejecución desde nuestra herramienta.
Otro componente importante y que es vital para las herramientas actuales es la posibilidad
de cambio de idioma. COMPROMISE está disponible en Inglés y Español, pudiendo cambiar
en cualquier momento de idioma y manteniendo la selección durante la navegación en la
herramienta.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
123
Figura 5.30: Iconos de Cambio de Idioma
5.2.7.1
Análisis y Diseño
Por la simplicidad de su diseño y el poco aporte de los diagramas de análisis con respecto
a los anteriormente presentados, en esta iteración no se han plasmado en el documento los
diagramas correspondientes a estas fases, pues la integración con las demás herramientas
únicamente supone el cambio de ruta antes de la llamada a ejecución, implementado con la
llamada a una acción en la clase RutasAction junto con su formulario correspondiente situado
en el menú de administración de la herramienta, y para la funcionalidad de cambio de idiomas
también supone la llamada de una acción proporcionada por el framework Struts2.
5.2.7.2
Implementación
A continuación se dispone de un formulario proporcionado por COMPROMISE para proporcionar las rutas de los ejecutables a las tres aplicaciones relacionadas con la herramienta
(Figura 5.31).
Figura 5.31: Ventana de cambio de rutas de las distintas herramientas
124
5.2. FASE DE ELABORACIÓN Y CONSTRUCCIÓN
El cambio de rutas proporcionado consiste en una cadena de caracteres que será enviada
a la acción de ejecución de las herramientas, Execute_Medini.java, Execute_EPFC.java y
Execute_BPMN2Modeler.java. A continuación, en el Listado 5.15 se puede observar un
extracto del código que permite llamar al ejecutable e iniciar la sesión en la herramienta
Medini-QVT.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
package a c t i o n s ;
p u b l i c c l a s s Execute_Medini extends ActionSupport {
p r i v a t e s t a t i c S t r i n g p a t h ="" ;
public s t a t i c String getPath () {
return path ;
}
public s t a t i c void s e t P a t h ( S t r i n g path ) {
Execute_Medini . path = path ;
}
public String execute_medini () {
S t r i n g r e t o r n o = "" ;
A r r a y L i s t < h i b e r n a t e . model . User > u s u a r i o = ( A r r a y L i s t < User > ) A c t i o n C o n t e x t . g e t C o n t e x t ( ) . g e t S e s s i o n ( ) .
g e t ( "user" ) ;
16
17
18
19
20
21
22
23
24
25
26
27
28
i f ( u s u a r i o == n u l l ) {
r e t o r n o =NONE;
} else {
try
{
Runtime app = Runtime . g e t R u n t i m e ( ) ;
app . e x e c ( "C:\\Users\\Victor\\Desktop\\mediniQVT\\mediniQVT.exe" ) ;
r e t o r n o = SUCCESS ;
}
}
return retorno ;
}
}
Listado 5.15: Ejecución Medini-QVT.
Además, como hemos dicho antes, pertenece a esta iteración implementar la funcionalidad
relativa al cambio de idiomas. Struts2 provee al desarrollador de funciones que facilitan tal fin
mediante diccionarios. En las figuras 5.16 y 5.17 se puede ver como se definen las variables a
utilizar por toda la herramienta. Será una variable global la que considere el idioma a utilizar,
cambiando dicha variable mediante los botones de la Figura 5.30.
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
125
1 title=tip 11 - i18n
2 user = Usuario
3 pdw = Contraseña
4 login = Entrar
5 compliance = Conformidad
6 transformaciones = Transformaciones
Listado 5.16: Diccionario Español.
1 title=tip 11 - i18n
2 user = User
3 pdw = Password
4 login = Login
5 compliance = Compliance
6 transformaciones = Transformations
Listado 5.17: Diccionario Inglés.
5.2.7.3
Pruebas
Por su extensión de código y como teniendo como objetivo facilitar la lectura del documento
las pruebas pertenecientes a esta iteración se encuentran en el paquete test del código de la
herramienta proporcionado junto a la documentación. Cabe destacar que COMPROMISE se
ha probado en los navegadores Google Chrome, Firefox e IExplorer.
5.3
Fase de Transición
Como hemos comentado en esta sección, la fase de Transición tendrá como objetivo la entrega
de la herramienta operativa al usuario final y su despliegue en el entorno real. Es por eso que
en el presente trabajo no se tratará como ésta requeriría en el caso de que la aplicación fuese
probada en una organización.
126
5.4. PATRONES DE DISEÑO
5.4
Patrones de Diseño
A continuación se presentan una serie de patrones utilizados en el desarrollo de la herramienta
COMPROMISE:
5.4.1
Modelo-Vista-Controlador
El patrón Modelo-Vista-Controlador o Model-View-Controller [29] en inglés, permite separar
los datos y la lógica de negocio de la interfaz. Este desacoplamiento permite, por ejemplo,
cambiar aspectos de la vista sin que afecte a ninguna de las otras dos capas. Este patrón
de arquitectura software tiene como objetivos evitar la repetición de código y facilitar el
mantenimiento posterior.
A continuación se representa un esquema del patrón MVC:
Figura 5.32: Esquema del Patrón MVC
CAPÍTULO 5. RESULTADOS: HERRAMIENTA COMPROMISE
5.4.2
127
Singleton
El patrón Singleton está diseñado para impedir que en una clase exista más de un objeto
instanciado de un tipo determinado, de esta manera se asegura un punto de acceso único
y global. A continuación se proporciona un extracto del código que hace uso del patrón
Singleton:
1 public String[] getProcesos_nombre_compliance() {
2
if(procesos_nombre_compliance == null){
3
procesos_nombre_compliance = new String[procesos.size()];
4
}
5
return procesos_nombre_compliance;
6
}
Listado 5.18: Extracto de código del Patrón Singleton
En nuestro caso el ejemplo de la aplicación del patrón consiste en la creación de una lista
de procesos. Mediante el método getProcesos_nombre_compliance() accedemos a la variable
creada, si no está inicializada se inicializa y devuelve dicha variable, en caso de que ya esté
inicializada únicamente la devolverá sin otra acción previa. De esta manera nos aseguramos
que ésta sea única.
5.4.3
DAO
Es uno de los patrones más importantes de cara a la persistencia de datos. Se trata de una clase
intermedia entre la capa de modelo y la de persistencia, que en nuestro caso hemos llamado
Manager, que se encarga de proporcionar a cada objeto las operaciones CRUD Create, Read,
Update y Delete necesarias. Por tanto cada objeto que sea persistente en memoria deberá
implementar el patrón DAO.
Este patrón permite modelas las operaciones para administrar una entidad de información.
Permite al desarrollador aumentar la productividad, ya que aumenta el nivel de abstracción y
éste únicamente hace uso de las operaciones proporcionadas sin preocuparse de sentencias
SQL evitando así la repetición de trabajo y el sistema resultante será menos propenso a errores.
Un ejemplo de la aplicación del DAO se encuentra el apéndice correspondiente (F.1).
Capítulo 6
Conclusiones y Propuestas
En este capítulo se exponen las conclusiones tras el desarrollo de este Trabajo de Fin de Grado.
Se determina el grado de cumplimiento de los objetivos definidos en el inicio del proyecto
(Capítulo 2), se incluyen algunas propuestas de trabajo futuro que amplían los resultados del
presente y se proporciona la opinión personal del autor tras la realización del presente TFG.
6.1
Conclusiones
Como resultado de este desarrollo se han conseguido satisfacer todos los objetivos propuestos
en un origen, presentados en el Capítulo 2.
Entre los objetivos cumplidos destacan por su importancia; la dotación de contenido de
método a la herramienta EPFC desde la base de datos de ARMONÍAS-DGS, el cambio de paradigma de un proceso contemplativo a uno productivo, el soporte al análisis de Conformidad
de Procesos Software así como la salida de informes, y la transformación model-to-model
para la representación y futura ejecución de Procesos Software en un motor de procesos.
El contenido de método proporcionado a la herramienta EPFC a partir de la BBDD de
ARMONÍAS-DGS supone el primer paso para la conversión de los procesos de la organización a procesos productivos, permite a las empresas almacenar su conocimiento en forma de
contenido de método para reutilizarlo en la futura composición de procesos, aprovechando
la ventaja sustancial para la organización que supone la reutilización de los elementos del
proceso a la hora de componerlo, evitando el trabajo repetitivo que supondría la definición de
éstos cada vez que tiene lugar la etapa de modelado (Capítulo 3).
Además, siguiendo el paradigma de la transformación a procesos productivos, la trans-
130
6.1. CONCLUSIONES
formación model-to-model proporciona una ventaja competitiva a las organizaciones que la
implementen, pues tendrán la posibilidad de ejecutar sus procesos y simularlos, detectando
los fallos de éstos como puedan ser los cuellos de botella, permitiendo la experimentación
con el sistema simulado sin interrumpir la actividad el sistema real evitando los daños reales
resultantes de una mala implementación.
Por otro lado y centrados en el objetivo principal del presente TFG, la organización que
haga un correcto uso de la herramienta obtendrá valores cuantificados del estado de sus
procesos y los distintos elementos que conforman su implementación, de una manera clara e
intuitiva que son capaces de proporcionar las distintas gráficas de los informes que facilita
COMPROMISE. Además, cuando tenga lugar la evaluación, la organización no tendrá que
preocuparse de si está tratando un estándar reconocido por los organismos oficiales, como
pueda ser ISO, o uno resultante de la armonización de éstos, pues gracias al paradigma de
Pardo [53] y a la herramienta ARMONÍAS-DGS [61] estos aspectos son transparentes a la
organización.
Otra de las ventajas que provee COMPROMISE a las organizaciones es la visualización
de los procesos de la organización además de todos los componentes que los conforman y
la función de recomendador que provee a las organizaciones de una serie de sugerencias
que indicarán los recursos necesarios para implementar las mejoras para lograr las futuras
certificaciones. Además se reducirán en gran medida las labores de consultoría previas a la
certificación, pues una organización podrá conocer en tiempo real el estado de sus procesos y
en caso necesario, obtendrá un informe con los elementos por implementar necesarios para su
perfeccionamiento.
Por último mencionar que la metodología utilizada para el proceso de desarrollo de la
herramienta objeto de este trabajo de fin de grado, OpenUP se adapta perfectamente a este
tipo de desarrollos, pues está pensada para equipos de desarrollo pequeños y por tanto no se
centra en aspectos propios de metodologías que soportan la coordinación de un gran equipo
de desarrollo. La explicación de dicha metodología se encuentra en la Sección 4.1.
CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS
6.1.1
131
Propuestas de trabajos futuros
En esta sección se proponen posibles mejoras y ampliaciones de la herramienta. A continuación se indican posibles propuestas de trabajo futuro.
• Estudio exhaustivo entre la correspondencia de Proceso Software y Proceso de
Negocio. Establecer la equivalencia entre los conceptos de los distintos tipos de procesos no es tarea fácil. Es por eso que como trabajo futuro se propone la realización de
un estudio minucioso, como ejemplo se propone la lectura de [55], entre los distintos
metamodelos para establecer una transformación sin perder semántica, pues la transformación propuesta en el presente TFG es una solución acotada por los margenes de
tiempo propios de la naturaleza del mismo y focalizar el esfuerzo en este cometido
habría supuesto la imposibilidad de la realización de otras funcionalidades.
• Menú de gráficas y resultados personalizable. Sería muy útil para las organizaciones
personalizar su cuadro de mando, las gráficas que representan el estado de sus procesos,
el nivel de detalle de presentación de los elementos de los mismos, así como cualquier
aspecto que se considere relevante y que influya en la presentación de los datos.
• Analizar y aplicar otros mecanismos avanzados para analizar la conformidad. En
nuestro caso de estudio se ha establecido una correspondencia Tarea a Tarea entre los
procesos de la organización y los procesos estandarizados de los marcos de trabajo.
Aunque es una aproximación válida, sería interesante establecer unas políticas mucho
más rigurosas de medición que ponderen ciertos aspectos de implementación, tales como
el orden de las tareas, tiempos, calidad de las herramientas, históricos de productividad
en distintas tareas, etc. Por ejemplo en [50] se propone una extensión del metamodelo
SPEM que recoge una serie de pautas que determinan la calidad del conocimiento
del Proceso Software mediante una serie de métricas, categorizando y ponderando las
tareas a partir del conocimiento que le aportan los elementos relacionados con la misma
(roles, herramientas, productos de trabajo, etc.). De esta manera se puede definir un
valor que puede determinar la concordancia entre dos o más tareas.
• Automatización de la Transformación propuesta entre UMA y BPMN. Actualmente se realiza haciendo uso del Plug-in de Medini QVT. Aunque se han probado a realizar
132
6.1. CONCLUSIONES
en la herramienta labores de transformación internas utilizando librerías proporcionadas
por Medini-QVT, las restricciones temporales han impedido la automatización de dicha
transformación. Será interesante incorporar estos mecanismos en un trabajo futuro
6.1.2
Opinión Personal
Una vez desarrollado el presente TFG he de decir que las experiencias obtenidas han sido
satisfactorias. Claramente dos aspectos que en un origen consideraba muy distantes, el marco
teórico y la tecnología, a medida que el desarrollo iba avanzando se volvieron complementarios. Ha sido el tiempo, junto con el estudio de la materia, lo que me ha proporcionado la
mejor de las perspectivas para darme cuenta de que todo tiene relación y que el apoyo de las
distintas áreas de la Informática así como de los campos relacionados con la materia, son
vitales para lograr ser competitivos en el mundo laboral a la hora de desarrollar productos de
calidad.
Por una parte el trabajo desarrollado me ha servido tanto para adquirir nuevos conceptos
de Ingeniería del Software como para afianzar y profundizar en los que tenía. Conceptos como
metamodelo, transformación, metalenguaje o MDE eran extraños en un origen y difícilmente
pensaba en una aplicación de los mismos en el entorno empresarial. A su vez he podido
conocer un sinfín de herramientas en las que se apoyan y olvidar el hecho de que “cuando
tenemos un martillo, todo son clavos”, aceptar que hay varias soluciones para un mismo
problema y que el conocimiento de los aspectos relativos a la organización en un proyecto es
fundamental a la hora de cumplir los objetivos propuestos.
Uno de los conceptos adquiridos que me gustaría conocer en profundidad son las distintas
visiones de los procesos, pues a mi parecer creo que el paso de una visión puramente consultiva a una visión productiva que permita en gran medida la automatización de la gestión del
proceso es muy interesante.
Por otro lado se han afrontado una serie de competencias técnicas que nunca antes habían
tenido lugar, desarrollo web, lenguajes de transformación, cómo lograr la conformidad de procesos, paso de información entre herramientas, conocimiento de estándares. Han sido muchas
las tecnologías empleadas para la herramienta y aún más las que existen para proporcionar
CAPÍTULO 6. CONCLUSIONES Y PROPUESTAS
133
soluciones seguramente mejores que las propuestas en el presente documento. Darme cuenta
de que, a pesar de los conocimientos adquiridos en estos últimos años, queda un abismo por
aprender y es eso lo que motiva el estudio continuo y alimenta las ganas de seguir avanzando.
Por último mencionar que, según mi criterio, la realización de un Trabajo de Fin de Grado
es fundamental para terminar satisfactoriamente la primera etapa de un Informático, pues
proporciona una visión de conjunto que únicamente ofrece un trabajo terminado. Permite
darse cuenta de que la palabra Ingeniería no aparece por casualidad en el título del diploma y
que tampoco consiste en sistematizar de una serie de pasos para resolver un problema, sino
que supone la responsabilidad de dar soluciones a cuestiones que aún no han sido resueltas y
es bajo esta premisa cuando el término tiene sentido.
Ciudad Real, a 1 de Diciembre del 2014
Fdo.: Víctor Parrado López
Bibliografía
[1] Apache foundation.
http://apachefoundation.wikispaces.com/
Apache+Tomcat, Último acceso 20-12-2013.
[2] Bibtex. http://www.bibtex.org, Último acceso 04-04-2014.
[3] Bitbucket. https://bitbucket.org, Último acceso 29-05-2014.
[4] Bpmn modeler. http://eclipse.org/bpmn2-modeler/, Último acceso 2703-2014.
[5] Bubble navigation template.
http://tympanus.net/Tutorials/
BubbleNavigation/, Último acceso 15-06-2014.
[6] Chart.js. http://www.chartjs.org/, Último acceso 24-09-2014.
[7] Eclipse ide. https://www.eclipse.org/home/index.php, Último acceso
25-06-2014.
[8] EMF Eclipse Modeling Framework. http://www.eclipse.org/modeling/
emf/, Último acceso 12-03-2014.
[9] Epf - eclipse process framework.
http://www.eclipse.org/epf/, Último
acceso 04-10-2013.
[10] Flujo de petición con struts2. http://www.javatutoriales.com/2011/06/
struts-2-parte-1-configuracion.html, Último acceso 14-01-2014.
[11] Hibernate orm. http://hibernate.org/orm/, Último acceso 24-03-2014.
[12] ISO/IEC 12007:2008 (OBP).
https://www.iso.org/obp/ui/#iso:std:
iso-iec:12207:ed-2:v1:en, Último acceso 09-09-2014.
136
BIBLIOGRAFÍA
[13] Java.
https://www.java.com/es/download/faq/whatis_java.xml,
Último acceso 14-05-2014.
[14] Junit. http://junit.org/, Último acceso 14-05-2014.
[15] Latex. http://www.latex-project.org, Último acceso 04-04-2014.
[16] Medini qvt. http://projects.ikv.de/qvt, Último acceso 12-03-2014.
[17] Mysql workbench.
http://www.mysql.com/products/workbench/, Úl-
timo acceso 12-05-2014.
[18] Project jaxb. https://jaxb.java.net/, Último acceso 12-07-2014.
[19] Qvt relations. http://projects.ikv.de/qvt/wiki/tutorial, Último acceso 12-03-2014.
[20] Struts2. http://struts.apache.org/development/2.x/, Último acceso
05-10-2013.
[21] Uml - unified modeling language. http://www.uml.org/, Último acceso 27-082014.
[22] Visual paradigm. http://www.visual-paradigm.com/, Último acceso 09-032014.
[23] Guía Rápida Proceso de Desarrollo OpenUP/OAS, 2013.
http:
//www.udistrital.edu.co/files/dependencias/oas/
GuiaRapidaOpenUPOAS.pdf, Último acceso 18-06-2014.
[24] Gestión empresarial de los procesos, 29 de Julio de 2013.
http://www.
excelencia-empresarial.com/Gestion_procesos.htm.
[25] Acuña, Silvia T. and De Antonio, A. and Ferre, X. and López, M. and Maté, L.: The
software process: Modelling, evaluation and improvement, 2000.
[26] Alarcos Research Group: QVT - Query/View/Transformation Meta Object Facility (MOF)
2.0. 2008.
BIBLIOGRAFÍA
137
[27] Awad, Ahmed and Mathias Weske: Visualization of compliance violation in business process models.
http://bpt.hpi.uni-potsdam.de/pub/Public/
AhmedAwad/21-Awad.pdf. Último acceso 14-11-2013.
[28] Brown, Donald E.: Struts 2. Anaya Editorial, 2008, ISBN 978-84-4152-498-9.
[29] Burbeck, S.: Applications programming in smalltaks-80(tm): How to use model-viewcontroller(mvc). 1992. Último acceso 12-06-2014.
[30] Bézivin, J.: MDA: From Hype to Hope, and Reality. 2003. UML Conference.
[31] Clark, Tony, Paul Sammut, and James Willans: Superlanguages: Developing, Languages
and Applications with X MF. Ceteva, 2008.
[32] Cuevas, A., Jose A. Calvo-Manzano, and T. San Feliu: Análisis de estándares y modelos
de referencia de mejores prácticas. http://www.dlsiis.fi.upm.es/docto_
lsiis/Trabajos20062007/Munoz.pdf, 2007. Último acceso 09-03-2014.
[33] Derniame, Jean Claude, Badara Ali Kaba, and David Graham Wastell (editors): Software
Process: Principles, Methodology, Technology, volume 1500 of Lecture Notes in Computer Science. Springer, 1999, ISBN 3-540-65516-6. http://dblp.uni-trier.
de/db/conf/ewspt/sp1999.html, Último acceso 09-04-2014.
[34] Florac, W. and A.D. Carleton: Measuring the Software Process. Statical Process Control
for Software Process Improvement. Addison Wesley, 1999.
[35] Foundation Eclipse: Metodología OpenUP, url = http://epf.eclipse.org/wikis/openup/,
2007. Último acceso 16-05-2014.
[36] Fuggetta, Alfonso: Software process: a roadmap. In Proceedings of the Conference
on The Future of Software Engineering, ICSE ’00, pages 25–34, New York, NY, USA,
2000. ACM, ISBN 1-58113-253-0. http://doi.acm.org/10.1145/336512.
336521, Último acceso 18-01-2014.
[37] Gamma, E. and Helm, R. and Johnson, R. and Vlissides, J.: Patrones de diseño. elementos de software orientado a objetos reutilizable, November 2003, ISBN 0-201-63361-2.
[38] García, Félix O.: Process management and model driven engineering. Grupo Alarcos (UCLM) - Escuela Superior de Informática de Ciudad Real.
138
BIBLIOGRAFÍA
[39] García, J. and García, F.O. and Pelechano, V. and Vallecillo, A. and Vara, J.M and
Vicente-Chicote, C.: Desarrollo de Software Dirigido por Modelos: Conceptos, Métodos
y Herramientas. RA-MA Editorial, 2013, ISBN 978-84-9964-215-4.
[40] Ghose, Aditya and George Koliadis: Auditing business process compliance. SpringerVerlag, pages 169–180, 2007. Decision Systems Laboratory, School of Computer
Science and Engineering.
[41] Governatori, G. and A. Rotolo: An algorithm for business process compliance. Jurix
2008, IOS Press, 2008. NICTA, Queensland Research Laboratory.
[42] Group Object Management: Software & Systems Process Engineering Meta-Model
Specification (SPEM). Version 2.0. 2008. Último acceso 24-05-2014.
[43] Institute of Electrical and Electronics Engineers (IEEE): IEEE Recommended Practice for Software Requirements Specifications. http://www.math.uaa.alaska.
edu/~afkjm/cs401/IEEE830.pdf, 1998. Último acceso 24-02-2014.
[44] International Organization for Standardization: ISO/IEC 15939 Software engineering Software Measurement Process. Ginebra, Suiza, 2002.
[45] International Organization for Standardization: ISO/IEC 15504:2003 Information technology - Process assessment, SPICE (Software Process Improvement and Capability
Determination). 2003.
[46] International Organization for Standardization: Guidelines for the application of iso
9001:2000 to computer software. http://www.iso.org/iso/catalogue_
detail?csnumber=35867, 2004. Último acceso 12-02-2014.
[47] International Organization for Standardization: ISO/IEC 12207 - standard for information technology - software life cycle processes. Standard, 2008.
[48] International Organization for Standardization (ISO): ISO IEC 15504 TR2: 1998, part
2: A reference model for processes and process capability., 1998. Ginebra, Suiza.
[49] Juran, J.M.: A History of Managing for Quality.
ISBN 978-0873893411.
McGraw-Hill, New York, 1988,
BIBLIOGRAFÍA
139
[50] Kerazi, N., M Lavallée, and Pierre N. Robillard: A knowledge-based perspective for
software process modeling. Software Engineering Journal, Volume 7, 2013.
[51] McLeod, Raymond: Management information systems.
Prentice-Hall Interna-
tional editions. Prentice Hall International, London [u.a.], 6. ed edition, 1995,
ISBN 0131809512.
http://gso.gbv.de/DB=2.1/CMD?ACT=SRCHA&
SRT=YOP&IKT=1016&TRM=ppn+184709016&sourceid=fbw_bibsonomy,
Último acceso 14-05-2014.
[52] Methodpark: Effectively managing process compliance. Último acceso 30-07-2014.
[53] Pardo, César: A framework to support the harmonization between multiple models and
standards. PhD thesis, Junio 2012. Institute of Information Technologies Systems,
University of Castilla-La Mancha.
[54] Paulk, M. C. and Weber, C. V. and Curtis, B. and Chrissis, M. B.: The Capability
Maturity Model: Guidelines for improving the software process. Addison-Wesley
Publishing Company, Massachusetts, 1995. The SEI Series in Software Engineering.
[55] Perez Cota, M. and Riesco, D. and Debnath, G. and Montejano, G.: Transformations
from SPEM Work Sequences to BPMN Sequence Flows for the Automation of Software
Development Process. Journal of Computational Methods in Science and Engineering
(JCMSE), 2010.
[56] Piattini, Mario G. and Félix O. García: Calidad en el desarrollo y mantenimiento del
Software. RA-MA, Madrid, 2003, ISBN 84-7897-544-6.
[57] Piattini, Mario G. and García, Félix, O. and García, I. and Pino, Francisco: Calidad de
Sistemas de Información. RA-MA, Madrid, 2011, ISBN 978-84-9964-070-9.
[58] Pérez, Juan D.: Notaciones y lenguajes de procesos. una visión global. https://www.
lsi.us.es/docs/doctorado/memorias/Perez,%20Juan%20D.pdf,
2007. Último acceso 03-02-2014.
[59] Reenskaug, T., P. Wold, and O. A. Lehne: Working with objects: the Ooram software
engineering method. Manning Publications, Greenwich, CT, 1996. Último acceso
10-06-2014.
140
BIBLIOGRAFÍA
[60] Rios, S., C. Hinojosa, and R. Delgado: Aplicación de la metodología OpenUP en el
desarrollo del sistema de difución de gestión del conocimiento de la ESPE. Escuela
Politécnica del Ejército.
[61] Romero, F.: ARMONÍAS-DGS, Herramienta para la Armonización y Evaluación de
Calidad de Procesos en Desarrollo Global de Software. Proyecto Fin de Carrera, Junio
2012. Castilla - La Mancha, España.
[62] Ruiz, F.: De una gestión de procesos contemplativa a una productiva.
alarcos.esi.uclm.es/ipsw/doc/SPE-IDEA.pdf, 2007.
http://
Último acceso
03-06-2014.
[63] Ruiz, Francisco and Javier Verdugo: Guía de uso de spem 2 con epf composer. 2008.
Universidad de Castilla-La Mancha Escuela Superior de Informática Departamento de
Tecnologías y Sistemas de Información.
[64] Satpathy, M. and R. Harrison: A Typed Generic Process Model for Product Focused
Process Improvement. Proceedings of the 26th Annual International Computer Software
and Applications Conference (COMPSAC’02). Oxford, England, 2002.
[65] Sheard, Sarah A.: Systems engineering standards and models compared. In Proceedings
of the 8th International Symposium on Systems Engineering (INCOSE, pages 589–605,
1998.
[66] Software Engineering Institute (SEI): CMMI ® for Acquisition, Version 1.3. November
2010. http://goo.gl/ngL1c.
[67] Software Engineering Institute (SEI): CMMI ® for Developement, Version 1.3. November 2010. http://goo.gl/oljH2.
[68] Software Engineering Institute (SEI): CMMI ® for Services, Version 1.3. November
2010. http://goo.gl/DGK8i.
[69] Software Engineering Institute (SEI): Standard CMMI ® appraisal Method for Process
Improvement (SCAMPI) A, Version 1.3: Method Definition Document. March 2010.
http://goo.gl/76z80.
BIBLIOGRAFÍA
[70] Universidad Distrital Francisco José de Caldas: Guía openup.
141
http://www.
udistrital.edu.co/dependencias/oas/documentos/, Último acceso
16-10-2014.
[71] Vallecillo, A.: Desarrollo de software dirigido por modelos. Último acceso 16-05-2014.
[72] Vicente Pelechano - Universidad Politécnica de Valencia: Model driven development.
Último acceso 17-05-2014.
[73] Vizcaino, A and J. Favela: Supporting Software Maintenance in Web Repositories
through a Multi-Agent System. First International Atlantic Web Intelligence Concerence
(AWIC’ 2003) LNAI 2663 Menasalvas, E. and Segovia, J. and Szczepaniak, P.S. P.S.
(Eds): 307-317, 2003.
[74] Wang, Y. and King G.: Software Engineering Processes: Principles and Applications.
CRC Press, 2000.
Apéndice A
Manual de Instalación
Este apéndice corresponde al manual de Instalación de la herramienta. Para su ejecución se
necesitará un servidor Apache Tomcat que aloje la herramienta mediante, por ejemplo, un
archivo con extensión .war, y del lado del cliente un navegador Web como Mozilla Firefox,
Internet Explorer, Safari, Google Chrome, Opera, etc. con la función JavaScript activada.
Compromise utiliza dos bases de datos, que serán proporcionadas junto a la documentación
de la herramienta (directorio BBDD), la primera será denominada compromise.sql (referente
a la presente herramienta) y la otra armonias.sql. Para llevar a cabo la instalación de ambas
bases de datos se deberá ejecutar las siguientes sentencias en la terminal del equipo utilizado:
mysql -u root -p <compromise.sql
mysql -u root -p <armonias.sql
Los parámetros de conexión de COMPROMISE con las bases de datos anteriormente
mencionadas están configurados para un servidor local, no obstante si se deseara desplegar la
herramienta en un servidor remoto se necesita cambiar las rutas de las conexiones a las bases
de datos éstas están presentes en la clase Persistence.Agente.java y resources.hibernate.cfg.xml
respectivamente.
Además del código de la aplicación, se proporcionarán los frameworks MediniQVT,
Eclipse BPMN Modeler, y Eclipse Process Framework Composer en una carpeta interna
llamada Frameworks. Dentro de cada una de estas se encuentra una subcarpeta denominada
Workspace, hay que respetar la jerarquía, pues COMPROMISE hará uso de esta carpeta para
guardar los archivos de intercambio que necesiten las herramientas.
Apéndice B
Manual de Usuario
En este apéndice se presenta el manual de usuario de la herramienta COMPROMISE. Estará
organizado por secciones que corresponderán a las distintas funcionalidades que ofrece la
misma.
B.1
Registro de Usuario
El primer paso para utilizar COMPROMISE será la identificación de Usuario. Haremos uso
de esta función mediante la página de login, presente en la Figura B.1. En ella introduciremos
el nombre del usuario y su password.
Figura B.1: Vista Login
146
B.2. SELECTOR DE IDIOMA Y MENÚ DE COMPROMISE
A continuación se presentan los identificadores que se han utilizado para las pruebas de la
herramienta:
• usuario - usuario
• adminHerramienta - adminHerramienta
• adminOrganizacion - adminOrganizacion
Dichos usuarios tendrán los privilegios mencionados en la Tabla 5.1. No obstante si los
usuarios introducidos no estuviesen contemplados en la base de datos y no se pudiera lograr
una identificación de usuario satisfactoria, la aplicación retornará de nuevo a esta ventana no
pudiendo implementar ninguna acción de la herramienta sin haber hecho uso de esta función
(validar.action).
B.2
Selector de Idioma y Menú de COMPROMISE
Mediante la utilización de los botones expuestos en la Figura 5.30 situados en cada una
de las páginas de la herramienta, el usuario podrá cambiar el idioma a Inglés o a Español,
convirtiendo la herramienta en multilenguaje. Además, en el caso en el que se quiera salir de
la misma únicamente tendrá que pulsar el botón situado en la esquina superior derecha del
panel o de la barra superior, según corresponda
A continuación se proporciona un ejemplo resultante del cambio de idioma en la página
del menú correspondiente a la herramienta. Mientras que la Figura B.2 presenta al usuario el
menú en Español, la Figura B.3 lo hace en inglés. Mencionar que una vez cambiado el idioma
será sustituido en todas las páginas de la herramienta, pudiendo volver al anterior en cualquier
momento.
APÉNDICE B. MANUAL DE USUARIO
147
Figura B.2: Ejemplo del Menú en Español
Figura B.3: Ejemplo del Menú en Inglés
B.3
Administración de la herramienta
Una vez identificado el usuario y que éste ha accedido al menú de COMPROMISE, en el caso
de que el usuario tenga los privilegios adecuados, podrá acceder al menú principal situándonos
en el botón que aparece en la Figura B.4.
148
B.3. ADMINISTRACIÓN DE LA HERRAMIENTA
Figura B.4: Acceso al menú de administración.
Una vez ejecutada la acción, se redigirá al usuario al panel de administración en el que
podremos observar distintas funcionalidades; una lista de usuarios de la organización a la que
pertenece el usuario autenticado (Figura B.5), la lista de organizaciones en el caso de que sea
el administrador de la herramienta (Figura B.6), un selector de rutas de la figura (Figura B.7)
y el selector de márgenes de aceptación que consideremos oportuno para nuestro proceso en
cuestión (Figura B.8).
Figura B.5: Usuarios registrados en COMPROMISE
En la Figura B.6 podemos observar cómo cada organización dispone de una serie de
botones que abren distintas ventanas modales para modificar, crear o eliminar cada uno de los
elementos de las mismas (activos, herramientas, roles y usuarios).
Figura B.6: Administración de las organizaciones de COMPROMISE.
En la Figura B.7 podemos observar el formulario en el que introduciremos todas las rutas
de las herramientas complementarias a COMPROMISE. Una vez introducidas todas ellas
pulsaremos el botón Guardar. A partir de este momento podremos ejecutar Medini QVT,
APÉNDICE B. MANUAL DE USUARIO
149
BPMN Modeler y EPFC desde el menú principal de la herramienta.
Figura B.7: Selector de Rutas de COMPROMISE
COMPROMISE permite a las organizaciones definir el margen de aceptación de cada
proceso, es decir, definimos a partir de qué umbral el proceso se considera satisfecho. Para
ello haremos uso del formulario de la Figura B.8. Cabe mencionar que el proceso aparecerá
una vez hecho uso del menú Cargar nuevos Procesos, inicializando el valor de su margen de
aceptación a cero.
Figura B.8: Definición de los márgenes de aceptación
Podremos hacer uso del cuadro de texto, introduciendo el valor oportuno, o bien un selector
presente en la Figura B.9. Una vez que se ha hecho uso del selector circular pulsaremos el
botón Guardar para que los cambios surtan efecto.
150
B.4. CARGAR PROCESOS EPFC
Figura B.9: Selector de aceptación de Conformidad
B.4
Cargar Procesos EPFC
Para proveer a la herramienta EPFC del contenido de método (Roles, Tareas, Disciplinas, etc.)
previamente tendremos que cargar los elementos en un documento XML que automáticamente
EPFC capturará al inicio. Para ello deberemos accionar el botón Cargar Contenido de Método
de la Figura B.10. Una vez accionado, COMPROMISE proveerá al usuario de una ventana
que le permita guardar el Contenido de Método, en forma de archivo, que necesitará EPFC en
el paso posterior.
Haremos uso de esta función mediante la siguiente ventana en el menú de COMPROMISE:
Figura B.10: Menú de Conformidad de Compromise.
APÉNDICE B. MANUAL DE USUARIO
151
Una vez realizado este paso procederemos a la visualización de la herramienta EPFC haciendo uso de la función del menú de la Figura B.11, la cual nos mostrará todos los elementos
cargados desde la base de datos de Armonías-DGS. Hay que mencionar que para cargar el
archivo proporcionado por COMPROMISE, antes deberemos importar el archivo guardado
en el instante anterior (MethodContent.xml. Lo realizaremos en el menú de EPFC mediante la
secuencia File 99K Import 99K XML.
Figura B.11: Ejecutar EPFC
En la siguiente figura, además de la carga de contenido de método, se muestra la composición del proceso. Para ello crearemos un Delivery Process (Ilustrado en la Figura B.13)
que será el proceso de la organización que deseemos modelar y que posteriormente nuestra
herramienta incluirá en su base de datos y representará.
Figura B.12: Composición de Procesos mediante EPFC
Una vez realizado este paso restará exportar como XML la librería de método y cargar
el archivo exportado en COMPROMISE. Para ello haremos uso del botón Cargar Nuevos
Procesos en la pestaña Conformidad/Compliance del menú principal. Una vez accionado se
152
B.4. CARGAR PROCESOS EPFC
Figura B.13: Crear Delivery Process EPFC
dispondrá de un selector para ello.
APÉNDICE B. MANUAL DE USUARIO
B.5
153
Compliance Organización
Una vez seguido estos pasos volveremos al menú de la herramienta y seleccionaremos la
opción de Panel Principal dentro del submenú de Usuarios. Dicha selección la podemos ver
en la figura B.14.
Figura B.14: Ejecución el Panel Principal de Compromise
Realizada esta acción nos aparecerá un gestor de control que nos permite visualizar los
procesos de la organización, las tareas de la misma, así como unas gráficas que indican
aspectos que ahora explicaremos. Hay tres tipos de gráficas, el primer tipo (Figura B.15) es
de histórico de Conformidad, el cual muestra por años la conformidad de la organización para
con un marco de referencia concreto. El segundo tipo de gráfica (Figura B.16) muestra la
conformidad actual categorizada por procesos. Y por último, el tercer gráfico (Figura B.18)
muestra el estado de la organización respecto con los marcos de referencia de la base de datos
de Armonías-DGS.
154
B.5. COMPLIANCE ORGANIZACIÓN
Figura B.15: Gráfica de Histórico de la Conformidad de Procesos de una Organización
Figura B.16: Gráfico de barras correspondiente a la Conformidad de Proceso
Dentro de esta vista podremos observar los Roles que tiene asociados cada tarea seleccionando la que consideremos oportuna (Figura B.17).
APÉNDICE B. MANUAL DE USUARIO
155
Figura B.17: Roles Relacionados con la Tarea Seleccionada
Además de proveer la función de visualización, la herramienta podrá utilizar la función de
recomendador anteriormente mencionada. Para ello haremos uso del menú desplegable que
tenemos en la Figura B.19 de la gráfica de la Figura B.18.
Figura B.18: Gráfica correspondiente al Compliance de la Organización por Marcos de Referencia
156
B.5. COMPLIANCE ORGANIZACIÓN
Figura B.19: Menú desplegable para la función Recomendador
Una vez hecho uso de esta función aparecerá una pantalla similar a la anterior que nos
indicará en tres tablas las herramientas, las tareas y los roles por implementar. Si deseáramos
extraer esa documentación en formato PDF haremos uso del botón Extraer PDF, presente en
la Figura B.20.
Figura B.20: Función de generación de Informes PDF
APÉNDICE B. MANUAL DE USUARIO
B.6
157
Generar archivo para MediniQVT
Para realizar la transformación entre modelos UMA y BPMN2 antes deberemos componer
el documento XML que contenga los procesos de la organización a transformar por Medini.
Para ello necesitaremos hacer uso de la función Componer documento Medini en el submenú
Compliance/Compromise.
Figura B.21: Ejecución de la Composición del Documento .xmi para el Framework MediniQVT
Una vez que se han realizado los pasos anteriores se abrirá una ventana modal que
nos permitirá guardar nuestro archivo con extensión xmi, que posteriormente cargará la
herramienta Medini QVT.
B.7
Abrir Medini-QVT y ejecutar transformación
Una vez realizado el documento de la transformación ejecutaremos la herramienta MediniQVT
mediante el menú de la Figura B.22.
Figura B.22: Ejecución del Framework MediniQVT
B.8. REPRESENTACIÓN PROCESO TRANSFORMADO (BPMN) EN BPMN2
MODELER
158
Cuando se nos ha cargado el Framework ejecutaremos la transformación como se presenta
en la Figura B.23
Figura B.23: Ejecución de la transformación MediniQVT
B.8
Representación Proceso transformado (BPMN) en BPMN2
Modeler
A continuación ejecutando el framework BMPN Modeler mediante el submenú de la Figura
B.24, lograremos ver el proceso transformado en las dos variantes presentadas en la Figura
B.25 y en la cascada de la Figura 5.29.
Figura B.24: Ejecuta el Framework BPMN Modeler
APÉNDICE B. MANUAL DE USUARIO
159
Una vez terminado el proceso interno de la herramienta, COMPROMISE activará una
ventana que permitirá al usuario guardar el archivo con extensión .bpmn, que posteriormente
cargaremos con BPMN Modeler.
Figura B.25: Presentación de Proceso mediante BPMN Modeler
B.9
Ayuda
Si hacemos uso de esta función se cargará el presente manual para su visualización.(Figura
B.26)
Figura B.26: Ejecución de la ayuda de Compromise
Apéndice C
Acrónimos
A continuación se presentan un conjunto de acrónimos utilizados en el presente Trabajo de
Fin de Grado:
API. Application Programming Interface.
ATL. Atlas Transformation Language
BBDD. Base de Datos
BPMN. Business Process Model and Notation
CASE. Computer Aided Software Engineering.
CIM. Colaborative Information Manager.
CMMI. Capability Maturity Model Integration.
CMMI-ADQ. Capability Maturity Model Integration for Acquisition.
CMMI-DEV. Capability Maturity Model Integration for Development.
CMMI-SVC. Capability Maturity Model Integration for Services.
CRUD. Create, Read, Update and Delete.
CSS. Cascading Style Sheets.
DGS. Desarrollo Global de Software.
DSDM. Desarrollo de Software Dirigido por Modelos.
162
DSL. Domain Specific Language.
DVI. DeVice Independent.
EMF. Eclipse Model Framework.
EPFC. Eclipse Process Framework Composer.
GMP. Graphical Modeling Project.
GNOME. GNU Network Object Model Environment.
GPL. General Public License.
HTML. HyperText Markup Language.
HTTP. Hypertext Transfer Protocol.
IDE. Integrated Development Environment.
IDM. Ingeniería Dirigida por Modelos.
IEEE. Institute of Electrical and Electronics Engineers.
ISO. International Organization for Standardization.
JSP. JavaServer Pages.
MDA. Model Driven Architecture.
MDD. Model Driven Development.
MDE. Model Driven Engineering.
MDSD. Model-Driven Software Development.
MVC. Modelo-Vista-Controlador.
OMG. Object Management Group.
OpenUP. Open Unified Process.
APÉNDICE C. ACRÓNIMOS
ORM. Object Relational Mapper.
PDF. Portable Document Format.
PIM. Platform-Independent Model.
POO. Programación Orientada a Objetos.
PS. PostScript.
PSEE. Process-centered Software Engineering Environments.
PSM. Platform-Specific Model.
QVT. Query/View/Transformation.
SGBDR. Sistema de Gestión de Bases de Datos Relacionales.
SPEM. Software & Systems Process Engineering Metamodel.
SQL. Structured Query Language.
TFG. Trabajo de Fin de Grado.
UMA. Unified Method Architecture.
UML. Unified Modeling Language.
URI. Uniform Resource Identifier.
UML. Unified Modeling Language.
W3C. World Wide Web Consortium.
WWW. World Wide Web.
WYSIWYG. What-You-See-Is-What-You-Get.
XML. Extensible Markup Language.
XSD. XML Schema Definition
163
Apéndice D
Glosario
A continuación se presenta la definición de algunos términos utilizados en el trabajo:
1. Actividad. Definiremos la Actividad como un conjunto de tareas relacionadas con un
fin común. Un conjunto de Actividades compondrán un proceso.
2. Ambientes Multimarco: Haciendo mención a los marcos de referencia como estándares de la Industria, diremos que se da un Ambiente Multimarco cuando éstos son
utilizados de manera conjunta, componiendo un nuevo estándar con características de
dos o más de ellos.
3. Armonías-DGS: Es la herramienta desarrollada por Francisco Romero [61] y tiene
como propósito dotar a HFramework del soporte tecnológico necesario para cubrir los
aspectos automatizados, así como la presentación de los datos resultantes en forma de
gráficas e informes.
4. Ciclo de vida: Según la norma ISO/IEC Standard 12207:2008:Software life-Cycle
processes [47], se define el ciclo de vida es “un marco de referencia que contiene
los procesos, las actividades y las tareas involucradas en el desarrollo, explotación
y mantenimiento de un producto software, abarcando la vida del sistema desde la
definición de requisitos hasta que se deja de utilizar.”
5. Conformidad: Cuando nos referimos en el documento a conformidad nos referimos al
cumplimiento de nuestro proceso para con un marco de referencia determinado. Además
éste puede ser armonizado o no, ya que gracias al paradigma que nos proporciona la
herramienta Armonías-DGS nos es transparente.
166
6. Eclipse: Es un programa informático de código abierto compuesto por múltiples
herramienas de programación que permiten desarrollar software. Es muy utilizado por
su potencia y porque ofrece la posibilidad de extender funcionalidades específicas a
través de plugins.
7. Esquema xml o xsd: Se trata de un lenguaje para describir y definir la estructura de los
documentos XML. Una de las características más importantes es que ofrece funciones
de verificación, muy útil cuando se trata de un archivo de intercambio de información.
Fue desarrollado por el W3C en 2001.
8. Framework: Su transcripción literal es “marco de trabajo” y define en términos
generales un conjunto de conceptos, prácticas y herramientas que permiten enfocar
una problemática específica y darles solución mediante la estructura conceptual y
tecnológicas que éste proporciona.
9. HFramework: Es una tesis desarrollada por César Pardo en la Escuela Superior de
Informática de Ciudad Real que da un soporte teórico a la armonización de marcos de
referencia adoptados por la industria.
10. JAXB: Es un API que proporciona al programador facilidades a la hora elaborar
documentos XML y proporciona métodos de acceso a la información contenida en
éstos una vez creados. Además, se utiliza como Plug-in del IDE Eclipse y permite la
creación automática de las clases Java que componen un esquema XML, con todos los
elementos definidos junto con sus interrelaciones.
11. Librería de Método: Se trata de un contenedor definido en el metamodelo UMA
que recoge todos los Elementos de Método, entendiéndose éstos como un conjunto de
Contenidos de Método, Contenidos de Proceso, etc.
12. Marshall: El Marshall es un término que hace referencia a la composición de documentos XML a partir de un árbol de objetos Java mediante la API JAXB. El concepto
opuesto es el UnMarshall, que permite obtener los datos de un documento XML bien
definido y transformarlo en un árbol Java de Objetos definidos en el esquema.
13. Metamodelo: Es un modelo del lenguaje que captura las propiedades y características
esenciales. Esto incluye los conceptos de lenguaje que lo apoya y/o la sintaxis gráfica
junto con la semántica.
APÉNDICE D. GLOSARIO
167
14. Modelo de Referencia: Es un conjunto de buenas prácticas estandarizadas, están
definidos por organizaciones o un conjunto de ellas y son aceptadas por la industria.
Algunos ejemplos son CMMI, ISO/IEC 12007, etc.
15. Patrón de Diseño: Son un conjunto de soluciones a problemas de diseño estandarizadas con una serie de características. Se debe haber comprobado su efectividad de
resolución de problemas similares y debe ser reutilizable, lo que conlleva a aplicarse en
soluciones a diseños similares.
16. Plugin: Un plugin es un complemento utilizado para extender las funcionalidades de
ciertos programas informáticos. Son soluciones específicas a problemas determinados, permitiéndonos configurar el entorno sobre el que estemos trabajando de forma
personalizada.
17. Proceso Software: Un proceso es un “conjunto coherente de políticas, estructuras
organizacionales, tecnologías, procedimientos y artefactos que son necesarios para
concebir, desarrollar, empaquetar y mantener un producto software”.
18. Profiling: O análisis de rendimiento es la investigación del comportamiento de un
programa. El objetivo del mismo es averiguar el tiempo de ejecución dedicado a
cada ejecución para efectuar mejoras, detectando puntos de ejecución problemáticos,
optimización del rendimiento, etc.
19. Requisitos: El concepto de requisitos comprende cada uno de los aspectos y características que el cliente desea tener presentes en su sistema software. Así, la recogida de
requisitos se realiza en la primera fase del desarrollo mediante una serie de técnicas
comprendidas en el área de la Ingeniería de Requisitos.
20. Rol: Define un conjunto de habilidades, competencias y responsabilidades de una
persona o un conjunto de personas. Una persona puede desempeñar varios roles. [57].
21. Servlet: Es una clase en el lenguaje Java que permite extender la funcionalidad de un
servidor. Usualmente son utilizados en aplicaciones web.
22. Test suite: Es un conjunto de Test tratados como una unidad que se definen en la
etapa de pruebas. Cada Suite estará compuesta por una serie de test unitarios con la
posibilidad de tener relación entre ellos.
Apéndice E
Planificación del TFG
En este apéndice se presenta la planificación realizada que determina la posibilidad del
desarrollo del presente TFG en el tiempo previsto. Se presentarán las planificaciones realizadas
tanto temporales como económicas, los recursos necesarios para su realización y el equipo de
personal disponible. Además destacaremos algunos cambios realizados en el planteamiento
original que en un origen imposibilitaban el desarrollo satisfactorio del mismo.
E.1
Planificación Temporal
En un origen se definió el trabajo para la presentación en Septiembre. No obstante, la complejidad que supuso la adquisición de determinados conceptos tratados en el desarrollo, la
inexperiencia inicial en la tecnología utilizada y la ampliación del alcance que suponía el tratamiento de transformaciones entre modelos, determinaron la presentación en la convocatoria
de Diciembre.
A continuación se presenta una tabla con la cantidad de horas dedicadas al proyecto
separadas por iteraciones:
170
E.2. EQUIPO DE TRABAJO
Iteración
Horas
Iteración 0
31 horas
Iteración 1
137 horas
Iteración 2
91 horas
Iteración 3
114 horas
Iteración 4
211 horas
Iteración 5
164 horas
Iteración 6
143 horas
Iteración 7
106 horas
Cuadro E.1: Planificación Temporal.
Lo que supone un total de 997 horas trabajadas. En dicha media se han tenido en cuenta
las horas de realización de la herramienta así como las necesarias para el aprendizaje de
los aspectos técnicos y teóricos necesarios para abordar satisfactoriamente el desarrollo del
presente TFG.
Hay que destacar que, según la guía docente del trabajo de Fin de Grado, se han empleado
más horas de las estimadas. En gran medida ha sido debido a la inexperiencia en los distintos
aspectos técnicos presentados en el documento así como en el aprendizaje previo a la utilización de las herramientas necesarias para la elaboración de COMPROMISE y adquisición de
conocimientos necesarios.
E.2
Equipo de Trabajo
En el desarrollo el autor asume los roles de Ingeniero de Requisitos, Analista, Diseñador,
Desarrollador y Tester. El Rol de Director de Proyecto ha sido asumido por el Director del
Trabajo de Fin de Grado. Por lo que únicamente contaremos con dos personas involucradas
activamente en la realización del Trabajo.
E.3
Recursos Materiales
Durante el desarrollo se han utilizado dos equipos, expuestos a continuación E.2:
APÉNDICE E. PLANIFICACIÓN DEL TFG
171
Equipo
Características
Equipo Portátil
Intel(R) Core(TM) i5 CPU M450 2.40 GHz
Equipo
AMD Phenom(tm) II X4 945 Processor 3.0 GHz
Sobremesa
Cuadro E.2: Recursos Hardware.
En cuanto al Software utilizado mencionar que todos los programas informáticos utilizados
han sido de Software libre, exceptuando la herramienta Visual Paradigm, sin embargo se
cuenta con la licencia de Estudiante proporcionada por la Escuela Superior de Informática de
Ciudad Real. Respecto al Sistema Operativo utilizado ha sido necesario el desarrollo bajo
Windows 7 por la incompatibilidad de algunas herramientas con GNU/Linux, no obstante
también ambos equipos contaban con sus respectivas licencias.
E.4
Presupuesto
En esta sección se estimarán los recursos económicos necesarios para la realización de la
herramienta. Por la fluctuación propia de los gastos variables, como pueden ser la luz, el agua,
la electricidad, etc. éstos no se tendrán en cuenta, cuantificándose únicamente los gastos fijos
relativos al salario de los recursos humanos. A continuación se presentarán en la tabla E.3:
Número horas
Coste de la hora Bruto
Régimen social
Total
997
12,00 ¤
Empleado
11.964 ¤
Cuadro E.3: Costes por contratación de empleados.
Apéndice F
Código Fuente
F.1
Ejemplo clase Manager
1 package hibernate.controller;
2
3
4 import java.util.List;
5 import org.hibernate.HibernateException;
6 import org.hibernate.classic.Session;
7 import hibernate.model.Actividad;
8 import hibernate.model.Iteracion;
9 import hibernate.model.Role;
10 import hibernate.model.Task;
11 import hibernate.util.HibernateUtil;
12
13 public class TaskManager extends HibernateUtil {
14
15
16
public Task add(Task task){
17
if(!this.exists(task)){
18
Session session = HibernateUtil.getSessionFactory().
getCurrentSession();
19
session.beginTransaction();
20
session.save(task);
21
session.getTransaction().commit();
22
}
23
24
25
return task;
174
26
F.1. EJEMPLO CLASE MANAGER
}
27
28
public Task delete(int id){
29
Session session = HibernateUtil.getSessionFactory().
getCurrentSession();
30
session.beginTransaction();
31
Task task= (Task) session.load(Task.class, id);
32
if(null != task){
33
session.delete(task);
34
}
35
session.getTransaction().commit();
36
37
38
return task;
}
39
40
@SuppressWarnings("unchecked")
41
public List <Task> list(){
42
43
Session session = HibernateUtil.getSessionFactory().
getCurrentSession();
44
session.beginTransaction();
45
List<Task> task = null;
46
47
try {
48
49
task = ((List<Task>)session.createQuery("from Task").list
());
50
51
} catch (HibernateException e) {
52
e.printStackTrace();
53
session.getTransaction().rollback();
54
}
55
session.getTransaction().commit();
56
57
return task;
58
59
60
61
}
APÉNDICE F. CÓDIGO FUENTE
62
private boolean exists(hibernate.model.Task task){
63
boolean exist = false;
64
List <hibernate.model.Task> lista_actividades = this.list();
65
66
for(int i=0;i<lista_actividades.size();i++){
67
if(task.getName().equalsIgnoreCase(lista_actividades.get(i
).getName()) && task.getDescription().equalsIgnoreCase
(lista_actividades.get(i).getDescription())){
68
exist = true;
69
}
70
}
71
return exist;
72
}
73
74
public List<hibernate.model.Task> getTaskbyProcess(String
process_name){
75
76
Session session = HibernateUtil.getSessionFactory().
getCurrentSession();
77
session.beginTransaction();
78
List<hibernate.model.Task> tareas = null;
79
80
try {
81
tareas = ((List<hibernate.model.Task>)session.createQuery(
"from Task WHERE Process_name=’"+process_name+"’").
list());
82
83
} catch (HibernateException e) {
84
e.printStackTrace();
85
session.getTransaction().rollback();
86
}
87
session.getTransaction().commit();
88
89
return tareas;
90
91
92
93
94 }
}
175
176
F.1. EJEMPLO CLASE MANAGER
Listado F.1: Ejemplo clase Manager.
1 public static void getElementsUnmarshaller( ){
2
3
try {
4
5
JAXBContext jaxbContext = JAXBContext.newInstance(
BPMN20_unmarshall.TDefinitions.class);
6
Unmarshaller jaxbUnmarshaller = jaxbContext.
createUnmarshaller();
7
8
empsd = jaxbUnmarshaller.unmarshal(new StreamSource(new File
("./saliente.xmi")),BPMN20_unmarshall.TDefinitions.class
);
9
10
/*Obtenemos los procesos*/
11
12
setProcesos(getprocesos(empsd));
13
setElementos_procesos(getFlowElements(procesos));
14
15
} catch (JAXBException e) {
16
// TODO Auto-generated catch block
17
e.printStackTrace();
18
}
19
20 }
Listado F.2: Ejemplo UnMarshall