Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Herramienta Modelado Procesos
Herramienta Modelado Procesos
Presentada por:
Meylin Cinthia Camarena Gil
Jackeline Marina Pedreschi Nez
Sandro Salvador Rondn Suasnabar
LIMA PERU
2008
Resumen
Las organizaciones desarrolladoras de software en general, han comprendido que la
clave de la entrega exitosa de un producto radica en la efectiva gestin de su proceso
software, ya que existe una correlacin directa entre la calidad del proceso y la calidad del
producto obtenido a partir de ste [75]. Incluso los organismos gubernamentales han
emprendido una serie de proyectos cuyo objetivo es la adecuada documentacin de sus
procesos, como lo es el caso de la Oficina Nacional de Gobierno Electrnico e Informtica en
el Per.
La definicin de procesos es uno de los primeros esfuerzos que toda organizacin debe
completar para poder iniciar la mejora de sus procesos, en particular, aquellas que se
dedican al desarrollo de software. Es as, que nacen una serie de notaciones y lenguajes de
definicin de procesos (LDP), los cuales llevan ya varias dcadas usndose en numerosos
campos de la industria, pero que son recientemente aplicados en el mbito de la Ingeniera
de Software.
Un lenguaje de definicin de procesos tiene como objetivo principal definir las entidades
bsicas que conforman un proceso y las reglas de interaccin y operacin que puedan existir
entre ellas.
II
herramientas para el modelado de procesos, las cuales pueden hacer uso de lenguajes de
definicin de procesos formales o propios de la herramienta.
III
su
incondicional
apoyo
Meylin Camarena
Sandro Rondn
y sabios
brindndome
su
apoyo
amor
incondicional.
Jackeline Pedreschi
IV
Reconocimientos:
El presente trabajo est enmarcado dentro
del proyecto 506AC0287 COMPETISOFT
(Mejora de Procesos Para Fomentar la
Competitividad de la Pequea y Mediana
Industria de Software de Ibero Amrica) del
programa CYTED (Ciencia y Tecnologa para
el Desarrollo) y apoyado parcialmente por
la Direccin Acadmica de Investigacin y el
Departamento de Ingeniera de la Pontificia
Universidad Catlica del Per.
ndice general
Resumen ................................................................................................................................... II
ndice general ........................................................................................................................... VI
ndice de ilustraciones ............................................................................................................ VIII
ndice de cuadros ..................................................................................................................... IX
ndice de archivos fuente........................................................................................................... 1
Introduccin ............................................................................................................................... 2
1.
Marco Terico ................................................................................................................... 4
1.1.
Definicin de Procesos ............................................................................................ 4
1.2.
Modelado de Procesos ............................................................................................ 5
1.2.1.
Principios de Modelado ................................................................................... 6
1.2.2.
Lenguajes de Procesos ................................................................................... 7
1.3.
Lenguajes de Definicin de Procesos...................................................................... 7
1.4.
XPDL (XML Process Definition Language).............................................................. 9
1.4.1.
Modelado Grfico [3] ..................................................................................... 11
1.4.2.
Modelado Semntico [3]................................................................................ 14
1.5.
Tecnologas Java Web........................................................................................... 18
1.5.1.
Patrones de Software .................................................................................... 18
1.5.2.
Marco de Trabajo .......................................................................................... 20
1.5.3.
Parser Manejadores de Archivos XML.......................................................... 24
1.5.4.
Tecnologas de Presentacin ........................................................................ 25
1.5.5.
Servidores de Aplicaciones Web y Servidores Web ..................................... 25
1.5.6.
Sistemas Administradores de Base de Datos ............................................... 26
2.
Anlisis de la Situacin Actual ........................................................................................ 28
2.1.
Situacin Actual...................................................................................................... 28
2.2.
Evaluacin de herramientas existentes para la gestin de procesos.................... 29
2.3.
Caractersticas no encontradas en las herramientas evaluadas ........................... 32
2.4.
Caractersticas principales de la herramienta propuesta....................................... 32
2.5.
Proyecto COMPETISOFT Herramientas ............................................................ 33
3.
Anlisis y Diseo............................................................................................................. 36
3.1.
Definicin del producto........................................................................................... 36
3.2.
Requerimientos del Software ................................................................................. 38
3.3.
Casos de Uso......................................................................................................... 38
3.4.
Diagrama de Clases de Anlisis ............................................................................ 46
3.4.1.
Diagrama de Clases: Metamodelo Paquete.................................................. 49
3.4.2.
Diagrama de Clases: Metamodelo Proceso.................................................. 50
3.4.3.
Diagrama de Clases: Metamodelo Metodologa ........................................... 52
3.4.4.
Diagrama de Clases Metodologa ................................................................. 53
3.4.5.
Diagrama de Clases: Metamodelo Administracin / Seguridad.................... 54
3.5.
Extensin del Lenguaje XPDL ............................................................................... 55
3.6.
Arquitectura de la Solucin .................................................................................... 63
3.6.1.
Diagrama de Despliegue ............................................................................... 66
3.6.2.
Diagrama de Componentes........................................................................... 67
3.6.3.
Tecnologas usadas en la herramienta ......................................................... 68
3.7.
Diagrama de clases de Diseo .............................................................................. 72
3.8.
Diagrama de Secuencias ....................................................................................... 74
3.9.
Mdulos de la herramienta..................................................................................... 74
3.9.1.
Modelador de Procesos................................................................................. 74
3.9.2.
Explosin de Niveles ..................................................................................... 78
3.9.3.
Definicin de Metodologas ........................................................................... 79
3.9.4.
Gestin de Versiones .................................................................................... 81
3.10. Plan de Pruebas..................................................................................................... 82
4.
Construccin y Pruebas.................................................................................................. 84
4.1.
Implementacin de Componentes ......................................................................... 84
4.1.1.
Estructuracin Interna del Proyecto Web...................................................... 84
4.1.2.
Configuracin de Spring ................................................................................ 86
4.1.3.
Integracin de AJAX con Spring: .................................................................. 93
VI
4.1.4.
Generacin del Archivo XML:........................................................................ 96
4.2.
Buenas Prcticas usadas en la herramienta ......................................................... 97
4.3.
Pruebas de Componentes ..................................................................................... 98
4.3.1.
Modelador de Procesos................................................................................. 99
4.3.2.
Explosin de Niveles ................................................................................... 102
4.3.3.
Mdulo de Metodologas ............................................................................. 104
4.3.4.
Mdulo de Versionamiento.......................................................................... 106
4.3.5.
Generacin del Archivo XPDL..................................................................... 107
5.
Observaciones, Conclusiones, Recomendaciones ...................................................... 116
5.1.
Observaciones ..................................................................................................... 116
5.2.
Conclusiones........................................................................................................ 119
5.3.
Recomendaciones................................................................................................ 120
Bibliografa............................................................................................................................. 122
Mritos ................................................................................................................................... 126
ANEXOS
A. Documento de Visin del Sistema MJS Process Designer
B. Lista de Exigencias del Sistema MJS Process Designer
C. Especificacin de Requisitos de Software del Sistema MJS Process Designer
D. Documento de Anlisis del Sistema MJS Process Designer
E. Documento de Diseo detallado del Sistema MJS Process Designer
F. Documento de Arquitectura del Sistema MJS Process Designer
G. Plan de Pruebas del Sistema MJS Process Designer
H. Modelado y Gestor de Versiones de Procesos basado en XPDL
I. Anlisis, Diseo y Construccin de una herramienta para modelado de Procesos: MJS
Process Designer.
VII
ndice de ilustraciones
Ilustracin 1-1: Smbolos BPMN [26]....................................................................................... 10
Ilustracin 1-2: Task BPMN [3]................................................................................................ 11
Ilustracin 1-3: Transicin BPMN [3] ....................................................................................... 13
Ilustracin 1-4: Meta-Modelo del Paquete [3].......................................................................... 15
Ilustracin 1-5: Meta-Modelo del Proceso [3].......................................................................... 15
Ilustracin 1-6: Esquema del patrn MVC [32]........................................................................ 19
Ilustracin 3-1: Diagrama de Clases de Anlisis Inicial........................................................... 47
Ilustracin 3-2: Diagrama de Clases del Metamodelo Paquete .............................................. 50
Ilustracin 3-3: Diagrama de Clases de Proceso .................................................................... 51
Ilustracin 3-4: Diagrama de Clases de Metodologa ............................................................. 53
Ilustracin 3-5: Diagrama de Clases Administracin / Seguridad ........................................... 54
Ilustracin 3-6: Extensin WorkflowProcess ........................................................................... 56
Ilustracin 3-7: Elemento Process Basic ................................................................................. 56
Ilustracin 3-8: Elemento ProcessMethodology ...................................................................... 57
Ilustracin 3-9: Elemento ProcessExplosion ........................................................................... 58
Ilustracin 3-10: Extensin Activity.......................................................................................... 60
Ilustracin 3-11: Elemento ActivityMethodology...................................................................... 60
Ilustracin 3-12: Diagrama de Capas inicial de la Herramienta .............................................. 63
Ilustracin 3-13: Diagrama de Capas Final de la herramienta................................................ 64
Ilustracin 3-14: Diagrama de Despliegue .............................................................................. 66
Ilustracin 3-15: Diagrama de Componentes.......................................................................... 67
Ilustracin 3-16: Tipos de Clase de Diseo............................................................................. 72
Ilustracin 3-17: Diagrama de Clase de Diseo para el metamodelo Paquete ...................... 73
Ilustracin 3-18: Diagrama de secuencia para Crear Paquete............................................. 75
Ilustracin 4-1: Estructura Interna del Proyecto ...................................................................... 85
Ilustracin 4-2: Mantenimiento de Datos Generales de Paquete.......................................... 100
Ilustracin 4-3: Mantenimiento de Datos Generales de Proceso.......................................... 101
Ilustracin 4-4: Modelado grfico del proceso....................................................................... 101
Ilustracin 4-5: Mantenimiento de Datos Generales de Actividad ........................................ 102
Ilustracin 4-6: Mdulo de explosin de niveles.................................................................... 103
Ilustracin 4-7: Modelado grfico del nuevo nivel ................................................................. 104
Ilustracin 4-8: Formulario de creacin de metodologa ....................................................... 104
Ilustracin 4-9: Modelado grfico de la metodologa............................................................. 105
Ilustracin 4-10: Mantenimiento de actividad de una metodologa ....................................... 106
Ilustracin 4-11: Vista de Versionamiento ............................................................................. 106
VIII
ndice de cuadros
Cuadro 1-1: NodeGraphicsInfo [3]........................................................................................... 12
Cuadro 1-2: ConnectorGraphicsInfo [3]................................................................................... 13
Cuadro 2-1: Herramientas que existen en el mercado............................................................ 29
Cuadro 3-1: Componentes del Sistema MJS Process Designer ............................................ 68
IX
Introduccin
En la actualidad la industria de software tienen como uno de sus objetivos la mejora
constante de los procesos de desarrollo de software que utilizan en su actividad diaria. Esta
mejora se logra mediante la implementacin de algn modelo relativo a la calidad de
procesos. Esta mejora se hace necesaria debido a que el desarrollo de los sistemas ha
alcanzado un alto grado de complejidad acorde con las nuevas necesidades de los usuarios.
Adicionalmente, la alta competitividad, eficiencia y velocidad de respuesta que requiere el
mercado, obliga a las industrias a implementar ciclos de desarrollo ms cortos basados en
presupuestos bajos y que adems permitan gestionar gran cantidad de datos y realizar
actividades complejas.
Sin embargo, un LDP sin una herramienta de software adecuada que la soporte, no
constituye una opcin viable debido a lo engorroso que resulta su manejo y actualizacin.
Debido a esto la herramienta debe permitir la definicin de sus procesos, la administracin de
las definiciones existentes y un adecuado mecanismo de control de la evolucin de sus
procesos de forma sencilla para el usuario.
Como una alternativa de solucin ante las necesidades expuestas, el siguiente trabajo de
tesis presenta el desarrollo de una herramienta de software que permita la definicin grafica y
semntica de los procesos basada en el lenguaje XPDL versin 2.0. Adicionalmente esta
herramienta incluye el manejo de la explosin de actividades en niveles, la definicin de
metodologas y la gestin de versiones de los procesos. Estos conceptos no se encuentran
definidos nativamente en el lenguaje XPDL, por lo que se consider necesario elaborar una
extensin con la finalidad de incluirlos dentro del lenguaje.
la
herramienta, los estndares utilizados en su codificacin y las pruebas de cada uno los
componentes.
1.
Marco Terico
En este primer captulo, se presenta el marco terico relacionado con la definicin de
Definicin de Procesos
La actividad de cualquier organizacin, sin importar la naturaleza o el rubro en la que
se encuentre enfocada, puede ser concebida como un conjunto de procesos. De este modo,
cualquier organizacin puede ser considerada como un sistema de procesos relacionados
directa o indirectamente entre si, en donde la salida (output) de un proceso puede actuar
como entrada (input) de otro.
Segn la ISO/IEC 12207 [1], un proceso se define como las entradas que se transforman en
salidas mediante un conjunto de actividades relacionadas. Adicionalmente, un proceso est
conformado por otros elementos, tales como: puntos de inicio y fin de proceso, participantes,
aplicaciones, artefactos; as como la informacin relacionada a cada uno de los elementos.
Segn Curtis, Kellner & Over [4], los cinco objetivos principales en la definicin de los
procesos, son:
a. Concepcin: Define el alcance del proyecto en base a las necesidades expresadas por el
usuario.
b. Elaboracin: Define el plan de proyecto, especificndose las caractersticas, diseo y
arquitectura del mismo.
c.
1.2.
Modelado de Procesos
Debido a la gran complejidad de los procesos y subprocesos en una organizacin,
posibles puntos de conexin con otros procesos o subprocesos, los roles o participantes
encargados de la ejecucin de las actividades, entre otros. Del mismo modo, permite
identificar posibles problemas existentes as como oportunidades de mejora. Esto conlleva a
que la organizacin pueda automatizar, integrar, monitorizar y optimizar de forma continua
los procesos que administra [10].
1.2.1.
Principios de Modelado
Segn Jacobson, entre los principios bsicos del modelado de procesos se
Los mejores modelos son los que reflejan la realidad lo ms cercano posible. Si
1.2.2.
Lenguajes de Procesos
Un lenguaje de proceso es usado para definir las entidades bsicas que conforman
Segn Ould, los lenguajes para modelar los procesos se categorizan de acuerdo a los
objetivos que persiguen [13], entre los cuales se tiene:
sistema software coordine su ejecucin, esto es, gestione automticamente las tareas
necesarias para que los procesos puedan ser llevados a cabo. Los lenguajes de ejecucin
brindan los elementos necesarios para especificar como se desarrollar el flujo de un
proceso durante su ejecucin.
1.3.
Semi-formal: Aquel que cuenta con una notacin formal, por lo general grfica, pero no
En la actualidad existen diversos lenguajes tales como: XPDL [3], BPEL [16], SEPM [18],
Little JIL/Juliette [19], y YAWL [17], entre otros.
XPDL (XML Process Definition Language) [3]: Lenguaje basado en XML para la
definicin de un flujo de trabajo que puede ser usado para almacenar o intercambiar modelos
de procesos de negocio entre distintas herramientas.
diseado para definir procesos de negocio que interactan con entidades externas mediante
operaciones de un servicio Web.
patrones de proceso (workflow patterns) que provee un formato simple para el modelado de
sistemas cuya interrelacin de procesos describe un flujo de control complejo. Este lenguaje
puede ser usado tanto por herramientas orientadas a la ejecucin de procesos, as como
aquellas cuyo propsito es el de definir procesos de forma grfica gracias a los objetos
visuales que posee dicho lenguaje.
de procesos en formato XML. Los nombres de los elementos definidos en este lenguaje
estn basados en los nombres utilizados en la herramienta AlphaFlow.
jDPL (jBOSS Process Definition Language) [20]: Notacin en formato XML que
SPEM (Software Process Engineering Metamodel) [18]: Es un estndar del OMG [22]
Actualmente XPDL y BPEL son los ms usados en el mercado [24], sin embargo ambos
presentan enfoques distintos, siendo BPEL un lenguaje orientado a los aspectos de la
ejecucin de un proceso [23] y XPDL es un lenguaje orientado a la definicin de procesos de
forma grfica y semntica [23].
1.4.
La creciente popularidad de XML y su uso para definir los formatos de documentos para
Internet, combinados con algunos aos de la experiencia acumulada usando WPDL en
workflow y herramientas de BPM, condujo a la creacin de XPDL 1.0, el cual fue lanzado
oficialmente en octubre del 2002 [25].
XPDL conserv la semntica utilizada en WPDL pero defini una nueva sintaxis usando un
esquema de XML. Sin embargo, ni WPDL ni XPDL 1.0 propusieron una representacin
grfica especfica para el modelado de procesos a pesar que el metamodelo subyacente
para un proceso estaba conformado de actividades (nodos) y caminos conectores entre ellos
(transiciones) [25].
BPMN fue desarrollado por BPMI (Business Process Management Initiative) con la finalidad
de adoptar las tcnicas empleadas en las herramientas de esquematizacin, as como
unificar y extender los grficos utilizados en ellas para expresar la semntica de los
procesos. BPMN 1.0 fue lanzado en mayo de 2004. Adems de la notacin grfica, BPMN
Debido a que el lanzamiento de BPMN fue posterior al de XPDL 1.0, los conceptos de
diagramado propuestos por dicha notacin grfica no estaban incluidos dentro del lenguaje
XPDL. A raz de esto, la WfMC define la implementacin de XPDL 2.0, incorporando estos
mecanismos de diagramado y ofreciendo adems un meta-modelo extendido que unifica
XPDL y BPMN [25].
Sistema para monitorizar los procesos, que proporcionen mtricas que faciliten la gestin
de los mismos.
10
1.4.1.
a. NodeGraphicsInfo
Este elemento puede ser usado por las siguientes entidades del lenguaje XPDL:
Artifact
Pool
Lane
Activity
En base a la notacin grfica BPMN, la cual puede ser representada a travs del lenguaje
XPDL, una actividad puede tener diversas representaciones grficas, siendo la forma ms
bsica la actividad de tipo Task (ilustracin 1-2).
Cada herramienta es identificada a travs del atributo ToolId, permitiendo as que cada una
de estas herramientas pueda agregar su propia informacin grfica. Por lo tanto, cada
herramienta puede exhibir y representar el mismo archivo XPDL de diversas maneras, ya
11
que cada una utiliza su propia informacin grfica, pero conserva la informacin grfica de
las otras herramientas.
En el cuadro 1-1, se listan los atributos del elemento NodeGraphicsInfo con su respectiva
descripcin por cada uno de ellos.
Atributo
Descripcin
BorderColor
Coordinates
FillColor
Height
LaneId
En el caso que el elemento sea del tipo Lane, este atributo se usa
para almacenar su identificador.
ToolId
IsVisible
Este atributo posee dos valores: true y false. Si tiene el valor true,
indica que el nodo debe mostrarse grficamente.
Page
Shape
Width
Haciendo uso del elemento NodeGraphicsInfo se puede almacenar dicha informacin tal
como se muestra en el archivo fuente 1-1:
<NodeGraphicsInfos>
<NodeGraphicsInfo Width="75.0" Height="50.0" BorderColor="#3B8C3D"
FillColor="#FFFFFF" ToolId=MJSProcess Shape=Rectangulo Redondeado>
<Coordinates XCoordinate="128.0" YCoordinate="96.0"/>
</NodeGraphicsInfo>
</NodeGraphicsInfos>
12
b. ConnectorGraphicsInfo
Este elemento puede ser usado para representar la conexin grfica entre los elementos que
pertenecen a un proceso.
elemento son:
Transition
Association
Message Flow
Atributo
Descripcin
BorderColor
Coordinates
FillColor
ToolId
IsVisible
Page
Shape
Style
13
<ConnectorGraphicsInfos>
<ConnectorGraphicsInfo BorderColor="#193EA1" FillColor="#193EA1"
ToolId=MJSProcess Style=Continua>
<Coordinates XCoordinate="203.5" YCoordinate="122.82308197021484"/>
<Coordinates XCoordinate="228.5" YCoordinate="123.2227783203125"/>
</ConnectorGraphicsInfo>
<ConnectorGraphicsInfos>
1.4.2.
Cada una de las entidades definidas dentro del meta-modelo posee una serie de atributos
que pueden ser de carcter: obligatorio, opcional o extendido. Estos ltimos son los que
permiten al usuario aadir caractersticas adicionales a dichas entidades.
Un modelo de procesos incluye varias entidades cuyo rango de accin puede ir ms all del
mbito de un nico proceso. En particular, las definiciones de participantes, aplicaciones y
los datos relevantes pueden ser referenciadas por un gran nmero de procesos.
El meta modelo que ofrece el lenguaje XPDL propone el uso de un repositorio en comn que
contenga estas entidades que son usadas por ms de una definicin de proceso. Para poder
llevar a cabo este objetivo y lograr una eficiente transferencia de datos entre el repositorio de
datos y las definiciones de procesos es que se introduce el concepto de Paquete. Dicho
elemento acta como un contenedor de entidades comunes entre diferentes definiciones de
procesos con la finalidad de evitar su redefinicin de forma individual dentro de cada modelo.
Un paquete contiene adems de entidades, los atributos en comn de cada una de las
definiciones de proceso que agrupa. Cada definicin de proceso contenida en el paquete
puede hacer uso de cualquier cualidad comn del mismo.
A nivel de paquete se pueden definir las siguientes entidades: aplicaciones, participantes,
tipos de datos, variables, artefactos y atributos extendidos, tal y como se aprecia en la
ilustracin 1-4.
14
Por otro lado, a nivel de proceso se pueden definir las siguientes entidades: Actividades,
transiciones, participantes, parmetros formales, variables, aplicaciones, bloque de
actividades, conectores, asociaciones, sub-procesos y atributos extendidos, tal y como se
muestra en la ilustracin 1-5.
1
1
Process
(W. Process)
*
1
Type
Declaration
Data Field
(Property)
Activity Set
(Embedded SubProcess)
*
*
performer
*
Reference to
uses
Participant
Application
uses
Activity
performer
to
from
Transition
(Sequence Flow)
*
uses
uses
1
Pool
Lane
1
Task/Tool
Block Activity
W. Relevant Data
Route
SubFlow
Gateway
Event
Fin2
Fin1
System and
enviroment data
Resource Repository or
Organizational Model
15
1.4.2.1
a. Actividad (Activity):
Una definicin de proceso consiste en una o ms actividades donde cada una de ellas
constituye una unidad lgica y autnoma de trabajo dentro del proceso. Una actividad
representa el trabajo que ser realizado por una combinacin de recursos (especificado por
la asignacin del participante) y/o de las aplicaciones informticas (especificadas por la
aplicacin asignada).
procesamiento y por lo tanto no tiene ningn recurso y/o aplicacin asignado. La funcin que
cumple es apoyar en las decisiones de enrutamiento entre las transiciones de entrada y/o
salida que conectan a ms de una actividad.
Adicionalmente una actividad puede representar un evento, que viene a ser un suceso que
ocurre durante el curso de un proceso y que puede afectar el flujo del mismo.
b. Transicin (Transition)
La relacin entre dos actividades se establece mediante el elemento transicin. Un conjunto
de actividades y las relaciones existentes entre ellas conforman un flujo de control. Cada
transicin de forma individual tiene tres propiedades bsicas que guardan la siguiente
informacin: actividad origen desde donde parte la transicin, actividad destino de la
transicin y la condicin a la cual est asociada en caso exista. Su alcance de operacin es
local a la definicin de proceso que contiene las actividades asociadas.
Una transicin puede ser del tipo condicional o incondicional. Para el primer caso dicha
condicin est relacionada a la evaluacin de una o ms expresiones para habilitar o
deshabilitar su flujo.
16
Las transiciones dentro de un proceso pueden dar lugar a una ejecucin secuencial o
paralela de actividades individuales. La informacin requerida para relacionar condiciones de
unificacin (join) o separacin (split) se define dentro de la actividad apropiada.
c. Participante (Participant):
Esta entidad almacena informacin del ente que acta como el ejecutor de una o ms
actividades en la definicin de un proceso. Los recursos que pueden ser asignados para
realizar una actividad especfica se definen como un atributo de la actividad denominado
Participant Assigment, el cual liga la actividad al sistema de
d. Aplicacin (Application):
Contiene la informacin de las aplicaciones o servicios que se pueden invocar para apoyar o
automatizar la tarea asociada a cada actividad. Tales aplicaciones pueden ser herramientas
construidas, reas departamentales de una empresa o procedimientos puestos en ejecucin.
f.
17
A pesar de que XPDL cubre la mayora de elementos estndar necesarios para la definicin
de un proceso, despus de realizar un anlisis de las caractersticas de este lenguaje, se ha
encontrado que dicho lenguaje no contempla aspectos tales como:
a. No posee una lista estandarizada de valores posibles para asignar a los atributos que
conforman las estructuras grficas de una definicin de proceso, por ejemplo: una lista
de colores. De esta forma al importar una definicin en una aplicacin distinta a la que
fue generada, podran no plasmarse adecuadamente las caractersticas grficas
definidas en el modelo original.
El presente proyecto de tesis tiene como uno de sus objetivos desarrollar una extensin del
lenguaje XPDL con la finalidad de poder incluir los elementos necesarios que permitan
acoplar los conceptos mencionados en el punto b.
1.5.
el
que
evolucionan
las
tecnologas
arquitecturas
diseadas
para
soportarla.
Esto
dificulta la eleccin de las tecnologas con las cuales se va a trabajar debido a que muchas
de ellas cumplen una misma funcin. Adicionalmente, se debe buscar que las tecnologas
seleccionadas interacten de tal
1.5.1.
Patrones de Software
Un patrn define una solucin aplicada con xito para un mismo problema dentro de
un contexto dado, de tal modo que se puede reutilizar esta solucin ms adelante sin tener
que volver a pensarla otra vez [27]. Se denominan patrones de software a los patrones que
son aplicados durante el desarrollo de un sistema de software o aplicacin [28].
18
Capa Modelo: Es la encargada de guardar los datos en un medio persistente como son
capa Vista y se los enva a la capa Modelo. Esta ltima se encarga del procesamiento de
datos, los cuales son devueltos a la capa Vista a travs del Controlador. Todo este proceso
forma un ciclo que se repite cada vez que el usuario realiza una accin en la interfaz. La
19
La arquitectura MVC fue diseada para que los cambios realizados en una aplicacin afecten
lo menos posible a la programacin que ya se encuentra implementada. Esto es posible
gracias a que su arquitectura desacopla en diferentes capas los datos, la lgica del negocio
y la lgica de presentacin. Todo esto hace posible la actualizacin y desarrollo de cada uno
de los componentes de forma independiente [32].
1.5.2.
Marco de Trabajo
Un marco de trabajo (framework) brinda ayuda en las distintas reas del proceso de
desarrollo de una aplicacin [34]. Los frameworks estn diseados para permitir el desarrollo
fcil y rpido de las aplicaciones. Gracias a esto, los programadores ya no tendrn que
preocuparse por manejar programacin de bajo nivel, como por ejemplo: concurrencia
masiva, manejo de transacciones, seguridad, entre otros.
Adicionalmente, los frameworks ayudan a que las aplicaciones cuenten finalmente con
caractersticas superiores debido a que un framework forma parte de la aplicacin cuando
sta ya se encuentra en produccin [35].
A. Frameworks de Presentacin:
Los frameworks de presentacin son los responsables de recolectar la informacin generada
por parte del usuario y llevarla hacia la capa de negocio en donde ser procesada. Del
mismo modo, recoge la data procesada que proviene de la capa de negocio para presentarla
al usuario a travs de la interfaz utilizada por la aplicacin [36].
a.
Struts
Struts es un framework de cdigo abierto desarrollado bajo el proyecto Apache Jakarta. Fue
creado para facilitar el desarrollo de aplicaciones Web basadas en Java Servlets y Java
Serves Pages (JSP) [37].
20
Permite la integracin con el framework Validator para la validacin de los datos que son
ingresados en los formularios. Dichas validaciones son definidas externamente al cdigo
fuente en un archivo XML.
b.
Spring
Spring es un framework de aplicaciones Java/J2EE que fue desarrollado bajo los trminos de
la licencia Apache en su versin 2.0 [39].
Caractersticas principales:
Ofrece diversas plantillas que facilitan el uso de Hibernate, iBatis, JDBC, entre otros;
adicionalmente se integra "de fbrica" con Quartz, Velocity, Freemarker, Struts y
Webwork2.
Nace como una evolucin natural de los frameworks actuales hacia un sistema de
componentes.
21
Permite crear componentes grficos personalizados segn las necesidades del usuario.
Permite mostrar los componentes grficos en distintas formas, lo cual va a depender del
cliente Web (exploradores, celulares, PDA, etc.) que se est utilizando para ver la
aplicacin.
B. Frameworks de Persistencia
El lenguaje de programacin Java est diseado para el desarrollo de aplicaciones siguiendo
el paradigma de la programacin orientada a objetos.
Debido a estas dificultades, es que surgen diversos frameworks de persistencia que sirven
de interfaces entre los objetos de la aplicacin y las tablas de los sistemas de base de datos
relacionales, con el fin de poder ayudar al programador a realizar las tareas de persistencia
de datos de una forma menos engorrosa.
a.
JDBC es una interfaz de programacin Java que proporciona mtodos para el manejo de
operaciones sobre base de datos haciendo uso del lenguaje SQL.
La tarea principal de JDBC es ocultar las caractersticas especficas de cada base de datos y
preocuparse solamente por las tareas de consulta, insercin y/o actualizacin de los datos
[44].
Gracias al conjunto de interfaces Java y a los mtodos de gestin de conexiones que brinda
JDBC para los diferentes modelos de base de datos, el programador ya no tiene que
preocuparse por implementar dichas clases de conexin; sino que slo se enfoca en la
elaboracin de las sentencias adecuadas para el manejo de la informacin [45].
22
b.
Hibernate
Soporta la mayora de los sistemas de base de datos SQL como son: MySQL,
PostgreSQL, Oracle, DB2, entre otros.
Tiene un lenguaje de consulta propio: HQL (Hibernate Query Language), el cual est
diseado como una extensin mnima del SQL. Este lenguaje HQL est orientado a
objetos, lo que proporciona un puente para el mapeo de objetos Java y los objetos de la
base de datos. A este concepto se le denomina ORM (Object Relational Mapper).
Ofrece un soporte robusto para transacciones complejas tales como relaciones de uno a
muchos y de muchos a muchos. Adems, Hibernate se encarga de generar
automticamente complejos joins para optimizar la consulta de los datos.
Ofrece una amplia y variada documentacin, adems de contar con una comunidad de
seguidores muy activa.
c.
iBatis
La finalidad de este framework es facilitar la implementacin del acceso a base de datos para
aplicaciones Java.
iBatis est formado por dos componentes: la capa DAO y los SQLMaps. La primera se
encarga de realizar las conexiones con la base de datos, mientras que la segunda ayuda a
separar las llamadas a la fuente de datos del cdigo propio de la aplicacin. Esto se debe a
que dichas sentencias SQL se encuentran mapeadas en un archivo XML externo [44].
iBatis no es un ORM.
23
1.5.3.
A. JDOM
JDOM es un API (Application Programming Interface) de procesamiento de documentos XML
basado y optimizado en base al lenguaje Java, por lo cual utiliza todas las caractersticas y
ventajas que dicho lenguaje proporciona [51].
Facilidad de uso.
B. SAX
SAX es el acrnimo de Simple API for XML. Como su nombre lo indica es una API basada
en eventos correspondientes a las diversas caractersticas encontradas en el documento
XML [53].
No incluye un parser propio, pero puede utilizar alguno existente que soporte SAX v2.
Define mtodos para obtener y agregar valores a los diferentes atributos por medio de un
XML Reader.
C. XMLBeans
XMLBeans define la compilacin del esquema (*.xsd) asociado al archivo XML, generando
las clases e interfaces necesarias para el acceso y modificacin de los datos propios de
dicho esquema [53].
Provee una vista del documento XML basado en objetos Java, creados en base a la
estructura nativa del XML.
24
Permite el acceso a los elementos del documento XML a travs de mtodos get y set, los
cuales trabajan con tipos de datos propios de su esquema y generados al momento de
su compilacin.
1.5.4.
Tecnologas de Presentacin
Las tecnologas de presentacin permiten elaborar aplicaciones ms interactivas
JSTL se integra de manera limpia y uniforme a las etiquetas HTML, debido a que las
etiquetas que utiliza estn definidas en formato XML.
Las etiquetas JSTL pueden referenciar objetos que se encuentren en los ambientes
Request y Session sin conocer el tipo del objeto y sin necesidad de realizar una
operacin de cast.
B. AJAX
Acrnimo de Asynchronous JavaScript and XML. Es una tcnica de desarrollo Web para
crear aplicaciones interactivas o RIA (Rich Internet Applications) [57]. Estas aplicaciones se
ejecutan en el cliente, es decir en el navegador del usuario, manteniendo comunicacin
asncrona con el servidor en un segundo plano. De esta forma es posible realizar cambios
sobre una pgina Web cargada en el navegador sin necesidad de recargarla en su totalidad.
Esto permite aumentar la interactividad, velocidad y usabilidad del sistema [58].
1.5.5.
una red de computadores, en el cual se ejecuta una o ms aplicaciones para ser utilizadas
por los clientes definidos dentro de la red. Como consecuencia del xito del lenguaje de
25
A. JBoss
JBoss AS es el primer servidor de aplicaciones de cdigo abierto certificado para J2EE 1.4
disponible en el mercado. JBoss cuenta con la capacidad de funcionar en un ambiente de
produccin ofreciendo una plataforma de alto rendimiento para aplicaciones de e-business.
Haciendo uso de una arquitectura orientada a servicios y con una licencia de cdigo abierto,
JBoss AS puede ser descargado, utilizado, incrustado y distribuido sin restriccin alguna.
Por este motivo, JBoss AS es la plataforma ms popular de middleware para desarrolladores,
vendedores independientes de software y grandes empresas [61].
B. Apache Tomcat
Tomcat es la implementacin de referencia para las Java Server Pages (JSP) y las
especificaciones Java Servlet. Esto significa que es el servidor Java disponible que ms se
ajusta a los estndares establecidos para la distribucin de aplicaciones basadas en JSP.
En sus inicios existi la percepcin de que el uso de Apache Tomcat de forma autnoma era
slo recomendable para entornos de desarrollo y entornos con requisitos mnimos de
velocidad y gestin de transacciones. En la actualidad ya no existe dicha percepcin y
Tomcat es usado como servidor Web autnomo en entornos con alto nivel de trfico y alta
disponibilidad [62].
1.5.6.
Entre los sistemas administradores de base de datos open source ms conocidos se tiene:
26
A. PostgreSQL
PostgreSQL es un motor de base de datos de software libre que proporciona un manejador
de conexin nativa JDBC [64].
Es soportado por varios sistemas operativos como Windows y Linux, entre otros.
B. MySQL
MySQL es un servidor de bases de datos relacional que se distribuye bajo la licencia GPL
(General Public License), es decir, es libre para aquellas aplicaciones que se distribuyen con
el mismo tipo de licencia [66].
Es multiplataforma.
Soporta el acceso a las bases de datos de forma simultnea por varios usuarios y/o
aplicaciones.
27
2.
a las necesidades de modelar sus procesos y la importancia de contar con una herramienta
que les permita elaborar dichas definiciones.
Adems, se
herramientas para la definicin de procesos, las cuales fueron evaluadas con la finalidad de
enumerar las principales ventajas y carencias que presentan en base a las posibles
necesidades de las organizaciones actuales. Como punto final, se menciona las principales
caractersticas que contendr la herramienta propuesta.
2.1.
Situacin Actual
Las organizaciones realizan sus actividades a travs de un conjunto de procesos de
En este contexto, muchas agrupaciones mundiales han centrado sus esfuerzos en tratar de
desarrollar especificaciones estandarizadas que permitan a las organizaciones la adecuada
definicin de todos los elementos y el flujo de trabajo que siguen sus procesos. Para ello, se
28
utilizan diversas herramientas software que permiten a las organizaciones hacer este trabajo
mucho ms llevadero.
Las principales necesidades que se busca cubrir con una herramienta de administracin de
procesos son:
Contar con una herramienta que permita definir y administrar los procesos de forma fcil
y entendible para el usuario.
Manejar un lenguaje estndar que permita que las definiciones de procesos elaboradas
en la herramienta puedan ser interpretadas por otras herramientas afines.
Gestionar las versiones de los cambios que se dan a travs del tiempo en las
definiciones de procesos.
Definir metodologas que adapten los procesos existentes a las diferentes realidades que
se puedan dar en una organizacin.
2.2.
En la actualidad existen diversas herramientas que permiten modelar y/o definir los
procesos de una organizacin utilizando diversas estrategias y metodologas. Una de las
principales caractersticas es el grado de interoperabilidad e interaccin planificada con otras
herramientas afines.
Nombre de la
Compaa
Herramienta
Desarrolladora
Together
http://www.together.at/togeth
Workflow Editor
er/prod/twe/index.html
JOpera
http://www.jopera.ethz.ch/
for
Lenguaje
de
Versin
Proceso
Tipo de
Licencia
XPDL
Stand Alone
2.2-1
Evaluacin
Propio
Stand
2.1.2
Libre
Eclipse
ObjectWeb
Plataforma
Alone
http://bonita.objectweb.org/
XPDL
Web
3.0
GNU (LGPL)
http://www.workflowgen.com
XPDL
Web
--
Comercial
Bonita
WorkflowGen
/workflow/workflow_software
_features.htm
BPWin
http://www.bpwin.ru
Propio
Stand Alone
4.0
Comercial
XFLOW
http://xflow.sourceforge.net/
Propio
Web
--
Libre
Process
Management
System
29
Para el presente trabajo se realiz la evaluacin de una muestra de las herramientas para el
modelado de procesos que existen en el mercado. Cabe mencionar que muchas de ellas no
solamente permiten realizar el modelado, sino que adems permiten llevar a cabo su
ejecucin mediante la creacin de instancias de los procesos definidos.
evaluacin
realizada
solamente
abarc
aquellas
herramientas
Es as, que la
que
presentaban
En el cuadro 2-1 se
Hace uso del lenguaje XPDL para almacenar la definicin de sus procesos.
Genera un archivo XML con la definicin de los procesos creados por los usuarios.
Realiza una validacin grfica de los procesos, basndose en las reglas establecidas
por los patrones de procesos.
Permite importar la definicin de un proceso a partir de un archivo XML que cumpla con
el estndar definido por el lenguaje XPDL.
No es una herramienta propiamente dicha, sino que es un plugin que se integra al IDE
Eclipse.
30
Hace uso del lenguaje XPDL para almacenar la definicin de sus procesos.
Permite definir el flujo de un proceso de forma grfica, sin embargo las herramientas de
diagramado que utiliza son limitadas.
grfica.
Posee un sistema de seguridad basado en roles, los cuales poseen diferentes niveles de
acceso que permiten desde la visualizacin de un proceso, hasta la aprobacin o
rechazo del mismo.
Permite importar la definicin de un proceso a partir de un archivo XML que cumpla con
el estndar definido por el lenguaje XPDL.
WorkflowGen [71]
Hace uso del lenguaje XPDL para almacenar la definicin de sus procesos.
Posee un sistema de seguridad en base a perfiles, lo que permite tener un mejor control
sobre el nivel de acceso de los usuarios que acceden a la herramienta.
BPWin [72]
Brinda mecanismos de explosin de niveles, lo que permite que un proceso puede ser
representado en n-niveles de jerarqua.
Su integracin slo es posible con otros productos que manejen la misma tcnica de
modelado utilizada por la herramienta.
XFLOW [73]
Posee un formato de definicin de lenguaje propio, lo que hace que tenga una
integracin pobre con otras herramientas.
No posee una interfaz grfica para la definicin de los procesos, los usuarios tienen que
definir sus procesos de forma manual en un archivo XML de acuerdo a los estndares y
reglas definidos por la herramienta.
31
2.3.
siguientes carencias:
Ninguna de ellas posee un mecanismo que permita a las organizaciones adaptar las
definiciones de sus procesos bases al entorno de trabajo sobre el cual se est llevando
a cabo un proyecto.
2.4.
a continuacin:
Como parte del proceso de diagramado la herramienta realizar la validacin de los flujos
de trabajo definidos por el usuario segn las reglas bsicas de diagramado de procesos.
Entre las reglas que se tomarn en cuenta para el presente trabajo de tesis se tienen:
obligatoriedad de nodos de inicio y fin de proceso, consistencia entre el nmero de
entradas y salidas, entre otras.
32
2.5.
para todos los pases del mundo, especialmente para los iberoamericanos, ya que ofrece
mltiples fuentes de ingresos y empleo y se perfila como una de las oportunidades ms
importantes en los pases en va de desarrollo. Sin embargo, en los pases iberoamericanos,
las empresas de desarrollo de software normalmente pequeas y medianas empresas
(PYMEs)- no estn preparadas para competir internacionalmente debido a que se enfrentan
a una serie de problemas tales como la dependencia tecnolgica y metodolgica
(especialmente de EEUU), la falta de formacin sobre los procesos del ciclo de vida del
software y sobre la calidad del mismo.
33
Para
desarrollar
el
proyecto
COMPETISOFT,
se
estudiaron
diferentes
iniciativas
En el Per, las empresas vienen introduciendo distintos marcos de referencia para la mejora
de sus procesos, sin embargo estos no calzan con las distintas realidades que se presentan
en las empresas peruanas, por lo que el Per se convierte en un escenario propicio para
implantar un marco metodolgico orientado a las pequeas y medianas empresas como el
que propone COMPETISOFT.
Desarrollar mapeo de procesos entre modelos para apoyar a las empresas a elegir sus
respectivos caminos de mejora.
34
MJS Process Designer forma parte de este proyecto, teniendo como objetivo principal definir
un proceso a travs de un editor grfico, mantener su informacin a travs de formularios,
todo ello siguiendo un estndar general basado en el lenguaje XPDL con la finalidad de que
el usuario pueda definir cualquier tipo de proceso.
Dentro del proyecto PS-PUCP se encuentran adicionalmente dos herramientas, las cuales
son:
35
3.
Anlisis y Diseo
En este captulo se muestran los aspectos ms resaltantes de cada etapa del ciclo
de vida del proyecto, desde su concepcin como producto hasta el diseo de su arquitectura.
Antes de entrar a la seccin de diseo e implementacin, se presenta la definicin del
producto en base a las necesidades detectadas en el mercado y definidos en el proyecto
COMPETISOFT-PUCP. Para la etapa de anlisis se presenta la lista de requerimientos
asociada al sistema, la especificacin de los casos de uso de la herramienta y el diagrama
de anlisis de la aplicacin. Para la etapa de diseo se presenta el diagrama de clases de
diseo, la extensin realizada al lenguaje XPDL y la arquitectura de la herramienta.
Finalmente se presenta una descripcin detallada de los mdulos que componen la
herramienta y el plan de pruebas a realizar sobre las principales funcionalidades de la
misma.
3.1.
36
Con ello, se logra contar con una herramienta que adems de satisfacer las
necesidades del usuario, tambin asegure su interoperabilidad con otras herramientas que
manejen el mismo lenguaje. El anlisis y desarrollo de la extensin realizada se explicar
con mayor detalle a lo largo del presente captulo.
En el mdulo de explosin de niveles se considera que una actividad podr ser explosionada
en un nuevo nivel, el cual podr estar conformado por dos o ms actividades relacionadas
entre s. Este proceso se podr repetir las veces que el usuario considere necesario sin
restriccin alguna, por lo que el modelo podr reflejar un mayor detalle del flujo de trabajo
segn las necesidades del usuario.
MJS Process Designer ser desarrollada de tal forma que se pueda integrar en un conjunto
de herramientas de administracin de procesos que abarque a todos los miembros del
proyecto PS-PUCP.
37
3.2.
Process Designer:
El modelado de procesos se realizar por medio de una interfaz grfica, la cual estar
basada en la notacin grfica BPMN. Adems, el sistema permitir validar el flujo de trabajo
diagramado en base a un conjunto de reglas bsicas de diagramado de procesos.
El usuario podr definir parmetros de entrada y salida asociados a las actividades que
conforman una definicin de proceso.
El sistema validar la
El usuario podr definir metodologas en base a los procesos que haya registrado
previamente en el sistema.
3.3.
Casos de Uso
A continuacin se presenta la especificacin de los casos de uso principales:
38
Diagramado de Proceso
Descripcin
Actores
Usuario Modelador.
Precondicin
1.
El actor selecciona en el rbol sobre el nombre del proceso que se desea hacer el
diagramado.
2.
3.
El actor escoge un elemento para ser agregado al modelado grfico del proceso.
4.
5.
5.1.
5.1.1.
5.1.2.
Si el nodo escogido es del tipo inicio, el sistema verificar que no se haya dibujado
anteriormente la condicin de inicio.
5.1.3.
5.2.
Si es una transicin:
5.2.1.
5.2.2.
5.2.3.
El sistema verificar que el nodo fin de la transicin no sea el mismo que el nodo
inicio de la transicin.
5.2.4.
5.2.4.1
Si el tipo de transicin elegida es del tipo lineal, el sistema dibujar una lnea recta
uniendo el nodo de inicio y el nodo de fin de la transicin.
5.2.4.2
Si el tipo de transicin elegida es del tipo polilnea, el sistema dibujar una lnea
cuadrangular uniendo el nodo de inicio y el nodo de fin de la transicin.
5.3.
5.3.1.
5.3.2.
El sistema verificar que el nodo seleccionado sea del tipo actividad bsica o
actividad bucle.
5.3.3.
5.3.3.1
Si es una asociacin del tipo IN, el sistema dibujar automticamente una lnea de
un tamao definido en el lado izquierdo del nodo escogido con la cabeza de la
flecha ingresando a la actividad.
5.3.3.2
Si es una asociacin del tipo OUT, el sistema dibujar automticamente una lnea
de un tamao definido en el lado derecho del nodo escogido con la cabeza de la
flecha saliendo de la actividad.
39
5.4.
5.4.1.
5.4.2.
El sistema verificar que el nodo seleccionado sea del tipo actividad bsica o
actividad bucle.
5.4.3.
5.4.4.
El sistema verificar que el nodo seleccionado sea del tipo actividad bsica o
actividad bucle.
5.4.5.
5.4.6.
5.5.
Si es un texto:
5.5.1.
5.5.2.
5.5.3.
5.5.4.
6.
El actor sigue realizando los pasos 4 y 5 hasta que termine de realizar el modelado
grfico del proceso.
7.
El actor guardar el modelado grfico del proceso (Referencia al caso de uso Guardar
Proceso).
Poscondicin
1.
(parte
2.
El actor ir arrastrando el puntero del mouse hasta que el tamao del nodo sea el
deseado.
3.
1.
(parte
2.
El actor ir arrastrando el puntero del mouse hasta que el alto de la transicin sea el
deseado.
3.
1.
2.
El sistema cambia a color rojo el borde exterior del nodo escogido para indicar que ha
sido seleccionado.
3.
El actor ir arrastrando dentro del rea del editor grfico el nodo escogido hasta que se
encuentre en la ubicacin deseada.
4.
5.
40
2.
El sistema cambia a color rojo el borde exterior del texto escogido para indicar que ha
sido seleccionado.
3.
El actor ir arrastrando dentro del rea del editor grfico el texto escogido hasta que se
encuentre en la ubicacin deseada.
4.
Ocurre en el paso 5.2. o 5.4., cuando el actor ha escogido el mismo nodo de inicio y nodo
de fin para la transicin o la asociacin del tipo IN/OUT.
1.
2.
Ocurre en el paso 5.1. cuando el actor ha tratado de dibujar el elemento inicio, cuando ya
exista uno creado en el proceso.
1.
2.
Ocurre en el paso 5.3. o 5.4. cuando el actor ha escogido algn nodo que no es del tipo
actividad bsica o actividad bucle para que se el nodo de entrada o fin de la asociacin.
1.
2.
Mantenimiento de Proceso
Descripcin
Actores
Precondicin
1.
2.
El actor selecciona la opcin Inf que se encuentra al lado derecho del nombre del
proceso seleccionado.
3.
General
Definicin de Cabecera
41
4.
Redefinicin de Cabecera
Parmetros formales
Participantes
Aplicaciones
Atributos Extendidos
Set Activities
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
4.7.
4.8.
4.9.
5.
El actor ejecuta el paso 4 las veces que requiera hasta que termine de realizar el
mantenimiento del proceso.
Poscondicin
El sistema muestra un mensaje de error Faltan ingresar datos y muestra el detalle del
error.
2.
42
Explosionar Actividad
Descripcin
Actores
Precondicin
1.
El actor selecciona un proceso del rbol que lista los procesos pertenecientes a un
paquete en el mdulo Modelado de Procesos.
2.
3.
4.
5.
El sistema carga en el editor grfico (rea de trabajo) el modelado grfico del proceso.
6.
7.
8.
El sistema crea un nuevo nodo en el rbol del mdulo correspondiente al nivel producto
de la explosin de la actividad seleccionada.
9.
2.
3.
43
5.
6.
7.
2.
Mantenimiento de metodologa
Descripcin
Actores
Precondicin
1.
2.
3.
4.
5.
El actor ingresa los datos de la metodologa y selecciona los procesos base de donde
se extraern los elementos que conforman la metodologa.
6.
7.
8.
9.
El sistema carga el rbol de la metodologa, el cual tiene como nodo raz el nombre de
44
la metodologa y como nodos los procesos asociados a ella con sus respectivas
actividades.
Poscondicin
1.
2.
El actor selecciona la opcin Inf que se encuentra al lado derecho del nombre de la
metodologa que desea modificar.
3.
4.
5.
El actor modifica los datos de la metodologa y selecciona los procesos base de donde
se extraern los elementos que conforman la metodologa.
6.
7.
8.
Poscondicin
Se inicia en el paso 7 del flujo bsico y paso 7 del flujo alternativo si no se han ingresado los
datos requeridos.
1.
El sistema muestra un mensaje de error Faltan ingresar datos y muestra el detalle del
error.
2.
Actores
Usuario Supervisor.
Precondicin
1.
2.
45
En el sector derecho se encuentra el rea de trabajo con las opciones: Editor grfico
y Mantenimiento. En el primero de ellos se visualizar el modelado grfico de la
versin seleccionada y en el segundo se visualizar la informacin semntica del
elemento seleccionado en una versin.
3.
4.
5.
6.
Poscondicin
3.4.
Cada entidad definida en los meta modelos de paquete y proceso del lenguaje XPDL
(ilustraciones 1-4 y 1-5), es representada tal como se muestra en la ilustracin 3-1 a travs
de una clase. Del mismo modo, para modelar relaciones existentes entre dichas entidades
se utiliz el elemento asociacin de UML.
Las entidades definidas en el lenguaje XPDL poseen un conjunto de atributos que pueden
ser de carcter obligatorio u opcional. En el diagrama de clases de anlisis inicial se plante
que cada clase tendra como parte de sus atributos solamente aquellos que fuesen de
carcter obligatorio en el lenguaje XPDL. Para el manejo de los atributos opcionales se
decidi implementar una clase generalizada de uso comn.
Esta clase de uso comn debera contar con las siguientes caractersticas:
Estar relacionada con las dems clases a fin de poder definir sus atributos opcionales.
46
Persona
Usuario
idPersona
nombre
apellidos
dni
idUsuario
usuario
password
activo
0..n
1..n
Participante
(from Analysis model)
0..n
idParticipante
nombre
descripcion
TipoNodo
(from Analysis model)
idTipoNodo
nombre
descripcion
Empresa
(from Analysis model)
idEmpresa
nombre
ruc
Proyecto
(from Analysis model)
1..n
0..n
0..1
Proceso
1..n
idNodo
nombre
descripcion
0..n
0..n
1
1..n
0..n
0..1
Paquete
idPaquete
nombre
descripcion
idAtributoExtendido
valor
0..n
1
0..n
0..n
1
1..n
idParametro
nombre
modo
index
descripcion
0..n
0..n
0..n
1
Artefacto
ParametroFormal
0..n
0..n
0..n
0..n
idTipoEA
nombre
descripcion
tipoCreacion
grupo
0..n
0..n
idAplicacion : Integer
nombre
descripcion
AtributoExtendido
Aplicacion
0..n
TipoAtributoExtendido
0..n
Nodo
(from Analysis model)
idProceso
nombre
descripcion
idVersion
idMetodologia
1..n
0..n
(from Analysis model)
idTransicion
inicioFin
1
idProyecto
nombre
Transicion
CategoriaAtributoExtendido
(from Analysis model)
idCategoriaEA
nombre
TipoDato
0..n
0..n
Variable
(from Analysis model)
idVariable
nombre
descripcion
1
0..n
47
Permitir diferenciar los atributos que poseen nombres similares, pero que a su vez se
encuentren definidos en entidades diferentes.
Permitir diferenciar los atributos propios de las entidades del lenguaje XPDL de los
atributos definidos por un usuario.
Reducir del nmero de tablas a administrar debido a que solamente se definiran las
clases de las entidades principales del XPDL. Las dems entidades se expresaran
utilizando las siguientes clases: AtributoExtendido, CategoriaAtributoExtendido y
TipoAtributoExtendido.
Las deficiencias que presentaba el diagrama de clases inicial salieron a la luz cuando se
empez a elaborar el prototipo funcional de uno de los mantenimientos de la herramienta.
48
Este prototipo no slo inclua el diseo de interfaces, sino que adems contemplaba la
implementacin de dicha funcionalidad.
Otro inconveniente encontrado fue la fuerte carga transaccional que estara dirigida en gran
parte hacia las tablas de base de datos asociadas a las clases: AtributoExtendido,
CategoriaAtributoExtendido y TipoAtributoExtendido.
3.4.1.
Script: Clase que identifica el lenguaje script usado en las expresiones XPDL
pertenecientes a los procesos que se encuentran dentro de un mismo paquete.
Proceso: Clase donde se definen los atributos generales de la entidad Proceso del
lenguaje XPDL.
TipoDato: Clase que almacena informacin sobre los diferentes tipos de datos
manejados en las definiciones de proceso.
Artefacto: Clase que representa una informacin que es utilizada o producida durante el
desarrollo de un proceso.
49
DEFINICIONCABECERA
idDefinicionCabecera
unidadCosto
fechaCreacion
descripcion
documentacion
unidadPrioridad
vendedor
versionXPDL
duracion
unidadDuracion
limite
prioridad
tiempoEstimado
inicioValidez
finValidez
tiempoEspera
tiempoTrabajo
PARTICIPANTE
idParticipante
nombre
descripcion
tipoParticipante
id
REDEFINICIONCABECERA
idRedefinicionCabecera
autor
pais
estadoPublicacion
responsable
version
PROCESO
0..n
SCRIPT
idScript
tipo
version
gramatica
0..1
TIPODATO
idTipoDato
nombre
id
descripcion
tipoCreacion
idTipoDatoPadre
idReferenciaExterna
0..1
0..n
1
1
0..1
1
1
ARTEFACTO
idArtefacto
nombre
tipoArtefacto
0..n
id
1
1
1
1
PAQUETE
idPaquete
nombre
id
tipoCompatibilidad
1
0..n
0..n
1
0..n
ATRIBUTOEXTENDIDO
idAtributoExtendido
valor
nombre
0..n
0..1
REFERENCIAEXTERNA
idReferenciaExterna
localizacin
namespace
xref
1
0..n
0..n
APLICACION
idAplicacion
nombre
descripcion
id
tipoAplicacion
0..n
VARIABLE
idVariable
id
descripcion
nombre
valorInicial
banderaArreglo
longitud
0..n
3.4.2.
Proceso: Clase donde se definen los atributos principales de un proceso. Dicha clase se
relaciona consigo misma para establecer la relacin que existe entre dos procesos: un
proceso principal o padre y un proceso referenciado por el anterior como subproceso. El
flujo de trabajo del subproceso se considera parte del flujo de trabajo del proceso
principal.
Nodo: Clase donde se definen los atributos de los elementos grficos que intervienen en
el proceso, entre los cuales se encuentran: actividades, conectores, nodo de inicio y
nodo de fin.
Transicin: Clase que almacena informacin sobre las conexiones existentes entre los
nodos.
50
ATRIBUTOEXTENDIDO
idAtributoExtendido
valor
nombre
0..n
DEFINICIONCABECERA
idDefinicionCabecera
unidadCosto
fechaCreacion
descripcion
documentacion
unidadPrioridad
vendedor
versionXPDL
duracion
unidadDuracion
limite
prioridad
tiempoEstimado
inicioValidez
finValidez
0..1
tiempoEspera
tiempoTrabajo
REDEFINICIONCABECERA
idRedefinicionCabecera
autor
pais
estadoPublicacion
0..1
responsable
version
TEXTO
idTexto
posX
posY
valor
PARAMETROFORMAL
idParametroFormal
id
descripcion
nombre
longitud
modo
esArreglo
indice
0..n
0..n
1
0..n
0..n
APLICACION
idAplicacion
0..n nombre
descripcion
id
tipoAplicacion
1..n
0..1
0..n
1..1
PARTICIPANTE
idParticipante
nombre
descripcion
tipoParticipante
id
PROCESO
idProceso
idVersionProceso
1..1 nombre
nivelAcceso
adHoc
adHocOrdering
adHocCompletionCondition
enableInstanceCompensation
id
tipoProceso
descripcion
banderaActual
supressJoinFailure
estado
1..1
idActividadInicio
idSetActividadInicio
idProcesoPadre
idVersionProcesoPadre
tipo
0..n
1
VARIABLE
idVariable
id
descripcion
0..n nombre
valorInicial
banderaArreglo
longitud
OBJETODATO
idObjetoDato
nombre
productoFinalizado
inicioRequerido
estado
0..n
NODO
idNodo
descripcion
0..n 0..n implementacion
id
nombre
idTipoNodo
modoFinalizacion
posX
posY
nivel
ancho
alto
1..n 1..n idSubProceso
idProceso
idVersionProceso
banderaExplosion
documentacion
0..n
idProcesoExplosion
idVersionProcesoExplosion
idSetActivity
idNodoPadre
0..n 1
0..n
0..1
0..n
SETACTIVITY
idSetActivity
nombre
id
defaultStartActivityId
ARTEFACTO
idArtefacto
nombre
tipoArtefacto
id
0..n
0..n
1..2
2..2
ASOCIACION
idAsociacion
direccionAsociacion
descripcion
id
nombre
0..n puntos
idNodoOrigen
idNodoDestino
idAsociacionPadre
TRANSICION
idTransicion
0..n descripcion
id
condicion
nombre
puntos
idNodoOrigen
idNodoDestino
tipo
idNodoMetodologiaDestino
idNodoMetodologiaOrigen
51
La clase Nodo se relaciona consigo misma para representar la relacin del nodo padre con
los nodos hijos que surgen al momento de realizar la explosin de una actividad en un nuevo
nivel.
Un nodo slo puede estar relacionado a un proceso, pero un proceso est conformado por
un conjunto de nodos.
Asociacin: Clase donde se definen los atributos de las entradas y salidas relacionadas
a los nodos de tipo actividad. Esta clase se relaciona consigo misma para definir la
relacin de las entradas y salidas de un nodo explosionado con las entradas y salidas de
los nodos hijos.
Texto: Clase donde se almacenan los atributos de los textos creados en los modelados
grficos.
SetActivity: Clase donde se definen los atributos de los conjuntos de actividades que se
crean en un proceso. La estructura de un SetActivity es muy similar a la estructura de un
proceso, por lo tanto puede ser manejada como tal.
3.4.3.
NodoMetodologia: Clase donde se definen los atributos de los nodos que conforman
una metodologa, tanto los nodos extrados de los procesos base as como los nuevos
nodos definidos en la metodologa (inicio, fin y conectores).
Transicin: Clase donde se definen los atributos de las transiciones que conectan los
NodoMetodologia.
52
3.4.4.
PROCESO
idProceso
idVersionProceso
nombre
nivelAcceso
adHoc
adHocOrdering
adHocCompletionCondition
enableInstanceCompensation
id
tipoProceso
descripcion
banderaActual
supressJoinFailure
estado
idActividadInicio
idSetActividadInicio
idProcesoPadre
idVersionProcesoPadre
tipo
METODOLOGIA
PROCESOxMET ODOLOGIA
1..1
0..n
0..n
TEXTO
ASOCIACION
idAsociacion
direccionAsociacion
descripcion
id
nombre
puntos
idNodoOrigen
idNodoDestino
idAsociacionPadre
idT exto
posX
posY
valor
idProyecto
nombre
descripcion
fechaRegistro
nombreRegistro
0..n
fechaUltModif
activo
ASOCIACIONxMET ODOLOGIA
1
1..2
NODO
0..n
1
1
0..n
0..n
PROYECTO
idMetodologia
1..1 idVersionMetodologia
id
nombre
descripcion
0..1 banderaActual
idNodo
descripcion
implementacion
id
nombre
idT ipoNodo
modoFinalizacion
posX
posY
nivel
ancho
alto
idSubProceso
idProceso
idVersionProceso
banderaExplosion
documentacion
idProcesoExplosion
idVersionProcesoExplosion
idSetActivity
idNodoPadre
0..1 idAsociacionMetodologia
idNodoMetodologiaDestino
idNodoMetodologiaOrigen
idNodoOrigen
idNodoDestino
creado
puntos
direccionAsociacion
0..n
TRANSICIONxMET ODOLOGIA
0..1
1
TRANSICION
0..n
1
NODOMETODOLOGIA
0..1
0..n
idNodoMetodologia
idProcesoReferencia
idVersionProcesoReferencia
idNodo
posX
posY
ancho
alto
0..n
0..2
idT ransicion
descripcion
id
condicion
nombre
puntos
idNodoOrigen
idNodoDestino
tipo
idNodoMetodologiaDestino
0..n
idNodoMetodologiaOrigen
53
3.4.5.
EMPRESA
idEmpresa
razonSocial
RUC
direccion
telefono
paginaWeb
fechaRegistro
nombreRegistro
fechaUltModif
activo
1..n
PERSONA
idPersona
nombre
apellidos
tipoDocumento
numeroDocumento
pais
direccion
telefono
email1
email2
fechaRegistro
nombreRegistro
fechaUltModif
activo
USUARIO
idUsuario
usuario
contrasea
perfil
activo
1
0..n
PROYECTO
idProyecto
nombre
descripcion
fechaRegistro
nombreRegistro
fechaUltModif
activo
0..n
Empresa: Clase donde se definen los datos de una empresa registrada en el sistema.
Usuario: Clase donde se definen los datos necesarios para ingresar al sistema, como
son: usuario y contrasea. De igual forma se define el perfil que tiene un usuario dentro
de dicho sistema.
Persona: Clase donde se definen los datos de una persona. Dicha persona pertenece a
una empresa y tiene asignado un usuario para ingresar al sistema.
Proyecto: Clase donde se definen los atributos de un proyecto. Una empresa puede
administrar uno o ms proyectos propios. Cada proyecto estar asociado a un usuario
especfico de la empresa.
54
3.5.
Con la finalidad que la herramienta MJS Process Designer provea dichos conceptos de gran
utilidad para los usuarios, es que se decide incluirlos como parte de las funcionalidades
propias del sistema.
Con el fin de poder diferenciar entre un proceso base (definido por XPDL), un proceso de tipo
metodologa y un proceso de tipo explosin, se decide agregar un elemento denominado
ProcessCategory dentro del elemento WorkflowProcess.
55
En la ilustracin 3-6 se puede apreciar que el elemento ProcessCategory contiene otros tres
elementos denominados ProcessBasic, ProcessMethodology y ProcessExplosion; los cuales
permiten guardar informacin propia acerca de cada uno de estos tres tipos de procesos.
WORKFLOW PROCESS
PROCESS TYPE
PROCESS CATEGORY
PROCESS
BASIC
PROCESS
METHODOLOGY
PROCESS
EXPLOSION
A continuacin se detallan cada uno de los elementos por los que est compuesto el
elemento ProcessCategory:
a. ProcessBasic:
Este elemento permite identificar un proceso de tipo base o proceso definido nativamente por
el lenguaje XPDL.
De la misma forma, debido a que el lenguaje XPDL no ofrece de forma nativa los elementos
necesarios para poder almacenar informacin acerca de la versin de un proceso, es que se
decide crear un elemento denominado VersionInformation (ilustracin 3-7), el cual posee dos
atributos:
PROCESS BASIC
VERSION INFORMATION
IdVersion
CurrentVersion
56
Este elemento VersionInformation es usado dentro del elemento ProcessBasic y dentro del
elemento ProcessMethodology (elemento que se explicar ms adelante) con el fin de poder
realizar una gestin de versiones a nivel de procesos y metodologas.
b. ProcessMethodology:
Este elemento (ilustracin 3-8) permite identificar un proceso de tipo metodologa y a su vez
agrupa una serie de elementos que se encargan de guardar informacin propia de un
proceso de este tipo, entre los cuales se tiene:
PROCESS METHODOLOGY
PROCESSES REFERENCE
VERSION INFORMATION
PROCESS REFERENCE
IdProcess
IdProcVersion
c. ProcessExplosion:
Este elemento (ilustracin 3-9) permite identificar un proceso que fue generado como
consecuencia de la explosin de una actividad en un nuevo nivel. Dicho elemento contiene
otros dos elementos que se encargan de guardar informacin propia de este tipo de proceso,
los cuales son:
57
PROCESS EXPLOSION
PROCESS PARENT
ACTIVITY PARENT
IdActivity
Level
IdProcess
Level
<xsd:complexType name="ProcessType">
<xsd:sequence>
<!-- Ac se colocan atributos propios del XPDL - ProcessType -->
<!- Ac se agregan los atributos aadidos por mjsprocess -->
<xsd:element ref="mjs:ProcessCategory" minOccurs="1" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="ProcessCategory">
<xsd:complexType>
<xsd:choice>
<xsd:element name="ProcessBasic">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="mjs:VersionInformation"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ProcessMethodology">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="mjs:VersionInformation" minOccurs="1" />
<xsd:element ref="mjs:ProcessesReference" minOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ProcessExplosion">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="mjs:ProcessParent" minOccurs="1" />
<xsd:element ref="mjs:ActivityParent" minOccurs="1" />
</xsd:sequence>
58
</xsd:complexType>
</xsd:element>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="VersionInformation">
<xsd:complexType>
<xsd:attribute name="IdVersion" type="xsd:int" use="required" />
<xsd:attribute name="CurrentVersion">
<xsd:simpleType>
<xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="1" />
<xsd:enumeration value="0" />
</xsd:restriction>
</xsd:simpleType>
</xsd:attribute>
</xsd:complexType>
</xsd:element>
<xsd:element name="ProcessesReference">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="mjs:ProcessReference" minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ProcessReference">
<xsd:complexType>
<xsd:attribute name="IdProcess" type="xsd:string" use="required" />
<xsd:attribute name="IdProcVersion" type="xsd:int" use="required" />
</xsd:complexType>
</xsd:element>
<xsd:element name="ProcessParent">
<xsd:complexType>
<xsd:attribute name="IdProcess" type="xsd:string" use="required" />
<xsd:attribute name="IdProcVersion" type="xsd:int" use="required"/>
</xsd:complexType>
</xsd:element>
<xsd:element name="ActivityParent">
<xsd:complexType>
<xsd:attribute name="IdActivity" type="xsd:string" use="required" />
<xsd:attribute name="Level" type="xsd:int" use="required"/>
</xsd:complexType>
</xsd:element>
59
ACTIVITY
ACTIVITY SOURCE TYPE
ACTIVITY
BASIC
ACTIVITY
METHODOLOGY
ACTIVITY
EXPLOSION
A continuacin se detallan cada uno de los elementos por los que est compuesto el
elemento ActivitySourceType:
a. ActivityBasic:
Este elemento no posee ningn atributo adicional, solamente acta como elemento
categorizador de una determinada actividad.
b. ActivityMethodology:
Este elemento permite identificar una actividad que pertenece a un proceso de tipo
metodologa y a su vez agrupa una serie de elementos que se encargan de guardar
informacin propia de una actividad de este tipo (ilustracin 3-11), entre los cuales se tiene:
ACTIVITY
METHODOLOGY
ACTIVITY
REFERENCE
IdActivityRef
Level
PROCESS
REFERENCE
IdProcReference
IdVersionProcReference
60
Level: Nmero de nivel al que pertenece la actividad desde donde fue extrada.
c. ActivityExplosion:
Este elemento permite identificar una actividad que pertenece a un proceso de tipo explosin
y a su vez posee un atributo adicional denominado Level que permite identificar el nivel
dentro del proceso en el cual se encuentra la actividad.
<xsd:element name="Activity">
<xsd:complexType>
<xsd:sequence>
<!-- Ac se agregan los atributos aadidos por mjsprocess-->
<xsd:element ref="mjs:ActivitySourceType" minOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="ActivitySourceType">
<xsd:complexType> <xsd:choice>
<xsd:element name="ActivityBasic" />
<xsd:element name="ActivityMethodology">
<xsd:complexType> <xsd:sequence>
<xsd:element ref="mjs:ActivityReference" minOccurs="1" />
<xsd:element ref="mjs:ProcessReference" minOccurs="1" />
</xsd:sequence> </xsd:complexType>
</xsd:element>
<xsd:element name="ActivityExplosion">
<xsd:complexType>
<xsd:attribute name="LevelNumber" use="required" />
</xsd:complexType>
</xsd:element>
</xsd:choice> </xsd:complexType>
</xsd:element>
<xsd:element name="ActivityReference">
<xsd:complexType>
<xsd:attribute name="IdActivityRef" type="xsd:string" use="required" />
<xsd:attribute name="Level" type="xsd:int" use="required" />
</xsd:complexType>
</xsd:element>
61
C. Input/Output (Entrada/Salida)
Estos elementos contienen informacin sobre las entradas y salidas relacionadas a una
actividad y a su vez hacen referencia a un determinado artefacto.
<xsd:element name="Input">
<xsd:complexType>
<xsd:sequence>
<!- Ac se colocan los atributos propios del XPDL -->
<!-- Ac se agregan los atributos aadidos por mjsprocess-->
<xsd:element ref="mjs:IOIdentifier" minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="Output">
<xsd:complexType>
<xsd:sequence>
<!- Ac se colocan los atributos propios del XPDL -->
<!-- Ac se agregan los atributos aadidos por mjsprocess-->
<xsd:element ref="mjs:IOIdentifier" minOccurs="0" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
62
3.6.
Arquitectura de la Solucin
En sus inicios la herramienta MJS Process Designer propona contar con una
INTRANET
CLIENTES
LGICA
DEL
NEGOCIO
SERVIDOR CENTRAL
Repositorio
Datos
DATOS
La lgica del negocio no estara replicada en los clientes, lo cual permitira que las
modificaciones y mejoras a nivel de reglas del negocio se encuentren disponibles para el
conjunto de usuarios que hicieran uso de la herramienta. Con esto se reducira el costo
de recursos y tiempo en el mantenimiento de la aplicacin.
Los accesos, los recursos y la integridad de los datos seran controlados por el servidor.
Con ello se evitara que un programa cliente defectuoso o no autorizado pudiese daar el
sistema.
Todas estas ventajas representaban puntos muy favorables para el mantenimiento y soporte
del sistema a nivel de la lgica del negocio, pero qu sucedera si se realizara alguna
actualizacin en la interfaz del usuario? o qu pasara si el usuario no se encontrase dentro
de la red interna donde se encuentra instalada la herramienta?
En el primer caso se tendra que volver a reinstalar la aplicacin en todas las mquinas que
utilizaran dicha herramienta, lo cual demandara inversin de tiempo e interrupcin de las
labores cotidianas de los usuarios. En el segundo caso, el usuario no tendra acceso a la
herramienta fuera de la red interna, lo cual limitara su uso a un rea geogrfica muy
63
restringida.
Es as que se cambi la propuesta inicial de utilizar una plataforma cliente - servidor por una
plataforma Web, ya que ello permitira salvaguardar las dificultades anteriormente
mencionadas. Al mismo tiempo, el trabajar sobre una plataforma Web facilita el uso de
diversas tecnologas que dan la posibilidad de desarrollar un aplicativo mucho ms
estructurado e interactivo para el usuario.
En cuanto al nmero de capas fsicas se mantiene el mismo nmero del diseo original, sin
embargo, se plantea la divisin de la capa del negocio en tres capas lgicas, las cuales
sern explicadas con un mayor detalle ms adelante. El modelo de arquitectura de capas
final para la herramienta queda plasmado en la ilustracin 3-13.
MJS Process Designer
HTML
HTML
Request
HTML
Response
JSP/html
Response
Controller
Class
Controller
Class
Controller
Class
Model
Class
Model
Class
DAO
Jdbc
Model
Class
PostgreSQL
HTTP Server
INTERNET
Service Layer
Servidor de Aplicaciones
Web Server
Spring
Dispatcher Servlet
Internet
AJAX
Apache Tomcat
A continuacin se explican cada una de las capas que posee la arquitectura planteada:
a. Capa de Vista
Est formada por el conjunto de pginas Web que son accesadas por el usuario a travs de
un navegador Web (Browser).
b. Capa de Controlador
Est formada por las clases Controller Class, las cuales se encargan de recepcionar la
peticin de un usuario (HTML Request) y decidir qu informacin se le transmitir y a travs
de qu vista como respuesta a dicha peticin (HTML Response).
64
c. Capa de Modelo
Est formada por las clases Service y DAO (Data Access Object), las cuales en conjunto se
encargan de realizar las operaciones de lgica del negocio y de acceso a la base de datos.
La eleccin de este patrn de diseo se debe a las fuertes ventajas que ofrece para el
desarrollo de la herramienta, entre las cuales se tiene:
Permite tener diferentes vistas de usuario sin tener que realizar cambios radicales en la
lgica del negocio. Actualmente existe una gran variedad de equipos que se pueden
interconectar a una aplicacin Web, por lo que es necesario implementar diversos tipos
de vistas para una misma aplicacin, con la finalidad que el usuario pueda acceder a ella.
Dentro de la capa de Modelo o capa de Lgica del Negocio se hace uso de otros dos
patrones de diseo J2EE adicionales, los cuales son:
Business Delegate
Business Delegate acta como una abstraccin de la lgica del negocio en el lado del
cliente y por lo tanto oculta la implementacin de los servicios que brinda. De esta
manera se reduce el acoplamiento entre los clientes de la capa de presentacin y los
servicios de negocio del sistema.
65
manejo de la conexin con la fuente de datos para realizar operaciones de consulta y/o
almacenar informacin.
Como se mencion anteriormente, gracias al uso del patrn MVC algn cambio en las reglas
del negocio o el acceso a los datos slo se vera impactado en toda la capa de Lgica del
Negocio. Con el uso de los patrones Business Delegate y Data Access Object, se logra que
estos dos tipos de impactos ocurran en mbitos reducidos, tal es as que los cambios en las
reglas del negocio se veran reflejados en la capa de servicios y los cambios en el acceso a
datos se veran reflejados en la capa DAO.
En conclusin, el uso en conjunto de estos dos ltimos patrones de diseo dentro de la capa
del negocio brinda una mayor facilidad para el desarrollo y mantenimiento de la herramienta.
3.6.1.
Diagrama de Despliegue
En la ilustracin 3-14 se presenta el diagrama de despliegue en donde se visualizan
<<Browser>>
Cliente: Internet
Explorer
<<Servidor>>
Servidor de Aplicaciones:
MjsProcess
<<Base Datos>>
Servidor de Base de
Datos: Postgres
Cliente
Corresponde a la interfaz de usuario a travs de la cual los clientes acceden a la
herramienta haciendo uso de un navegador Web, que para el caso de la herramienta
MJS Process Designer es el Internet Explorer 6.0.
MJSProcess
Nodo principal de la herramienta que contiene las reglas del negocio para las funciones
de modelado de procesos, gestin de versiones, creacin de metodologas, explosin de
las actividades en niveles y generacin de archivos XPDL.
Base de Datos
Repositorio que contiene la informacin registrada por los usuarios acerca de los
procesos que han definido durante el transcurso del tiempo.
66
3.6.2.
Diagrama de Componentes
A continuacin se presentan los componentes principales que se encuentran en la
<<JAR>>
dwr
<<JAR>>
jstl
<<Web Pages>>
Interfaz de
Usuario
<<JavaScript>>
modeladorGrafi
co
<<Application>>
mjsprocess
<<File>>
applicationCont
ext-domain.xml
<<File>>
applicationServlet-co
ntrollers.xml
<<JAR>>
schemas
<<File>>
applicationCo
ntext-db.xml
<<JAR>>
xmlBean
<<File>>
applicationServletcontrollers.xml
<<JAR>>
spring
<<JAR>>
log4j
<<JAR>>
postgresql
Database
JSTL
ModeladorGrafico
67
MJSProcess
principal
de
la
herramienta
que
agrupa
las
ApplicationServlethandlerMapping.xml
ApplicationServletcontrollers.xml
Archivo
Schemas.jar
configuracin
que
contiene
el
registro
de
los
3.6.3.
donde se define cul es el propsito de cada una de ellas y cules son sus caractersticas
principales. Dentro de la arquitectura de la herramienta se han utilizado algunas de estas
tecnologas debido a las diferentes ventajas que ofrecen para el cumplimiento de las
caractersticas funcionales de la misma.
A continuacin se listan cules son las tecnologas usadas dentro de cada una de las capas
de la arquitectura de la herramienta MJS Process Designer y a su vez se menciona una
breve descripcin del porqu de su eleccin:
A. Frameworks de Presentacin
En el primer captulo se explic el concepto de framework de presentacin para el desarrollo
de aplicaciones Web.
Estos ltimos son los que presentan mayor difusin en el mercado de software [74], mejor
documentacin disponible y el respaldo de las respectivas organizaciones por las que fueron
desarrollados.
68
Para el presente trabajo de tesis se eligi Spring como framework de presentacin debido a
la ventaja que representa su capacidad de trabajar en unin de otras API o frameworks como
Struts, JSF, Hibernate, entre otros; lo cual no siempre se cumple en el caso de elegir Struts o
JSF.
B. Framework de Persistencia
Tal como se explic en el primer captulo, existen en la actualidad diversos frameworks de
persistencia que se pueden utilizar en el desarrollo de aplicaciones Java Web con el fin de
facilitar el mapeo con las bases de datos relacionales.
Entre las caractersticas a tomar en cuenta para la eleccin del framework de persistencia se
encuentran:
Estandarizacin: El uso de un lenguaje propio por parte de Hibernate ocasiona que las
aplicaciones estn sujetas a este framework en todo momento, ya que ante un posible
cambio se deber realizar una traduccin de las sentencias generadas en HQL a
sentencias SQL estndar. En cambio, JDBC es la interfaz nativa para conectarse a las
69
A pesar de las ventajas que ofrece JDBC frente a Hibernate, al usar este framework se
produce cierta prdida de la portabilidad de la aplicacin con respecto a la base de datos.
Esto se debe a que cada DBMS (Sistema Administrador de Base de Datos) implementa el
lenguaje estndar SQL de una manera distinta, por lo que las sentencias de acceso a la base
de datos estaran ligadas al DBMS utilizado.
Una manera de mitigar este inconveniente es a travs del uso de las interfaces DAO, las
cuales encapsulan y aslan el acceso a los datos de la lgica del negocio. Con ello, ante
cualquier cambio de la base de datos utilizada por la aplicacin, slo sera necesario
modificar la capa de acceso a datos (DAO) sin alterar la capa de lgica del negocio.
Otro motivo por el cual se decidi usar Tomcat en lugar de JBoss es la diferencia de tiempos
de inicializacin requeridos por estos servidores al realizar algn cambio durante la etapa de
desarrollo.
inicializado, JBoss requiere un mnimo de dos minutos para la misma operacin, lo cual
genera tiempos muertos durante el desarrollo del proyecto.
70
Escalabilidad: PostgreSQL posee una mayor escalabilidad que MySQL debido a que
soporta mayor cantidad de peticiones simultneas de manera correcta, con lo que
permite que mltiples usuarios puedan acceder a la aplicacin al mismo tiempo.
Dado que ninguno de estos dos DBMS cumpla en su totalidad con los objetivos no
funcionales de la herramienta, se tuvo que elegir aquel administrador de base datos que se
orientara hacia las caractersticas ms trascendentales para ella: escalabilidad e integridad
referencial. Es as que se decide optar por PostgreSQL como Sistema Administrador de
Base de Datos.
E. Tecnologas de Presentacin
Para el presente proyecto se opt por utilizar las tecnologas JSTL y AJAX con la finalidad de
crear una aplicacin interactiva y de fcil uso para el usuario.
a. JSP/JSTL
Se opt por utilizar JSTL durante la implementacin de la herramienta por las siguientes
razones:
Evita la inclusin de cdigo Java (scriptlets) dentro del cdigo fuente JSP. Con ello se
logra un mayor orden en la implementacin de la capa de presentacin.
Evita la inclusin de las clases propias de la lgica del negocio dentro del cdigo de los
formularios, debido a que ya no ser necesario realizar operaciones de cast en la
recuperacin de datos desde los objetos request y session.
Facilita el mantenimiento de los formularios al separar la lgica del negocio (cdigo Java)
de la capa de presentacin (JSP y HTML), facilitando el trabajo de los diseadores.
b. AJAX
Se opt por utilizar AJAX durante la implementacin de la herramienta por las siguientes
razones:
Aumenta la velocidad de la aplicacin al evitar que se recargue toda la pgina cada vez
que se realice alguna operacin.
71
3.7.
cuatro tipos:
Tipo Controller: Clases que sirven de intermediarias entre las peticiones del cliente y la
lgica del negocio.
Tipo Service: Interfaces que contienen toda la funcionalidad referente a la lgica del
negocio del sistema y que son implementadas por clases de tipo ServiceDb.
Tipo DAO: Interfaces que se encargan del acceso a base de datos para realizar
operaciones transaccionales y de consulta. Las clases de tipo DAOJdbc se encargan de
implementar dichas interfaces.
Tipo Entity: Clases que representan las entidades de negocio utilizadas por el sistema.
La relacin entre este tipo de clases (ilustracin 3-16) est basada en el patrn MVC, el cual
plasmado en el sistema MJS Process Designer se muestra a continuacin.
72
73
3.8.
Diagrama de Secuencias
En el diagrama de secuencia se muestra la interaccin entre las clases que
3.9.
Mdulos de la herramienta
A continuacin se presenta la descripcin de cada uno de los mdulos que
3.9.1.
Modelador de Procesos
La actividad de toda organizacin, sin importar el ramo o rea a la que pertenezca,
est basada en un conjunto de procesos que definen cmo y cundo se llevan a cabo las
diferentes actividades o tareas a realizar.
La herramienta utiliza como entidad raz o base el elemento paquete del XPDL, el cual acta
como contenedor de las definiciones de procesos y de los elementos relacionados a estas.
El uso de la herramienta MJS Process Designer implica como primer paso la creacin de una
nueva definicin de paquete o abrir una definicin previamente registrada en el sistema.
74
75
Una vez que el usuario cargue la definicin de un paquete en el sistema, se podr visualizar un
rbol en el cual se listan todas las versiones vigentes de las definiciones de los procesos y set
activities registrados dentro del mismo. Si el usuario desea ver el registro histrico de las
versiones existentes de una definicin de proceso deber utilizar el mdulo Gestor de
Versiones, el cual ser explicado ms adelante.
El mdulo Modelador de Procesos brinda al usuario dos tipos de interfaces con la finalidad de
realizar el modelado grfico y semntico de los procesos y metodologas.
Estos tipos de
interfaces son:
a. Interfaz Grfica:
Esta interfaz permite al usuario realizar el modelado grfico del proceso, en otras palabras,
diagramar el flujo de trabajo del mismo. El modelador grfico de la herramienta MJS Process
Designer utiliza la notacin grfica BPMN, la cual abarca la mayora de elementos definidos en
el lenguaje XPDL.
incluidos en la definicin de un flujo de trabajo son los siguientes: Actividad, evento de inicio y
fin, entrada y salida, conector, transicin y texto libre.
Actividad Loop: Este elemento representa una actividad que podr repetir su ejecucin
dentro de un flujo de trabajo en ms de una ocasin de acuerdo a una determinada
condicin.
El flujo de un proceso se define en base a transiciones, las cuales unen las actividades que
conforman el proceso, definiendo as una secuencia u orden de ejecucin para las mismas. La
herramienta MJS Process Designer proporciona al usuario dos tipos de transiciones: Lineal y
poli-lnea; esto con el fin de facilitar el diagramado de procesos complejos y grandes.
76
La definicin de procesos incluye tambin los artefactos utilizados y/o generados (inputs y
outputs) por las actividades que lo conforman. Para el presente trabajo de tesis se considera
como artefactos a los documentos que son generados durante la ejecucin de un proceso de
desarrollo de software; por ejemplo: Documento de Anlisis, Catlogo de Requisitos, Lista de
exigencias, Manual de Usuario, entre otros.
Una vez grabada la informacin grafica de las entidades modeladas, el usuario podr
seleccionar un elemento en el rea de diagramado y acceder a la lista de los mantenimientos
que tiene asociado. Dependiendo de la opcin de men elegida se proceder a cargar el
formulario en el rea de mantenimiento.
Adicionalmente, como parte del modelado grfico se ha considerado llevar a cabo la validacin
de algunas reglas bsicas de diagramado, con el fin de asegurar la consistencia del modelo de
procesos registrados en la herramienta. Entre las reglas de modelado que sern validadas se
encuentran las siguientes:
b. Interfaz de Formularios:
Esta interfaz permite al usuario realizar el mantenimiento semntico de las definiciones de
paquete, proceso y elementos relacionados a ellos.
En el lenguaje XPDL existen algunos elementos que pueden ser definidos en dos niveles
distintos: nivel de paquete o nivel de proceso. Los elementos definidos a nivel de paquete
podrn ser utilizados por los procesos que se encuentren contenidos en dicho paquete; en
cambio, un elemento que es definido a nivel de proceso slo podr ser utilizado dentro del
mbito del mismo.
77
El mantenimiento de aplicaciones, las cuales podrn ser utilizadas por las actividades
definidas en un proceso perteneciente al paquete.
El mantenimiento de participantes, los cuales podrn ser asignados como recursos para la
ejecucin de una actividad.
El mantenimiento de artefactos, los cuales podrn ser utilizados como entradas y/o salidas
de las actividades pertenecientes a un proceso.
El mantenimiento de aplicaciones, las cuales podrn ser utilizadas por las actividades que
conforman el proceso.
El mantenimiento de participantes, los cuales podrn ser asignados como recursos para la
ejecucin de una actividad.
La definicin de un proceso puede pasar por tres estados de publicacin a lo largo de su ciclo
de vida, los cuales son: Bajo revisin, Bajo prueba y Publicado.
3.9.2.
Explosin de Niveles
Los procesos dentro de una organizacin pueden variar en complejidad dependiendo
de la importancia que tengan dentro de la lgica del negocio manejada por la organizacin.
Como consecuencia de ello es posible encontrar desde modelos de procesos complejos y
recargados hasta modelos simples y bsicos. Un proceso puede ser parte de otro proceso
mayor que lo abarque, es as, que un proceso de negocio puede ser visto en varios niveles de
granularidad.
Uno de los objetivos de modelar es reflejar de forma precisa y detallada el flujo de trabajo a
llevarse a cabo en un proceso, pero igual de importante es lograr que el modelo de proceso
generado sea de fcil entendimiento para el usuario.
78
Es as que se define la implementacin del mdulo de Explosin de Niveles por actividad, con
la finalidad de brindarle al usuario la capacidad de poder modelar un proceso con mayor nivel
de detalle, as como facilitar las tareas de auditoria y seguimiento sobre los procesos de la
organizacin.
El usuario podr explosionar una actividad de tipo bsico en un nuevo nivel compuesto por dos
o ms actividades. Esta operacin se podr realizar las veces que el usuario lo requiera,
obtenindose con cada nuevo nivel un mayor detalle con respecto al nivel superior inmediato.
Adicionalmente, la herramienta permitir validar la consistencia de las entradas y salidas
compartidas entre niveles contiguos.
Para la implementacin del mdulo de Explosin de Niveles se consider necesario realizar las
siguientes
extensiones
al
lenguaje
XPDL:
ActivityParent,
ActivitySourceType
Permite explosionar una actividad en un nuevo nivel compuesto por dos o ms actividades.
Permite realizar el mantenimiento del modelado grfico y semntico de cada uno de los
elementos que conforman el nuevo nivel.
3.9.3.
Definicin de Metodologas
Dentro de una organizacin se pueden presentar diferentes entornos o contextos de
trabajo en los cuales se llevan a cabo los procesos involucrados en su actividad diaria. Incluso
a nivel de proyectos no siempre se utiliza un mismo flujo de trabajo debido a que no todos los
proyectos tienen el mismo alcance. Como consecuencia de lo anteriormente expuesto surge la
necesidad de adaptar las definiciones de procesos a los diferentes entornos de trabajo
mediante la definicin de metodologas.
79
Este mdulo puede ser accedido a travs de la vista Metodologa de la herramienta MJS
Process Designer, la cual brinda las siguientes funcionalidades:
Permite seleccionar los procesos base de los que se extraen las actividades que conforman
la metodologa.
Permite la visualizacin del rbol de metodologa, en el cual se listan los procesos base
referenciados por la metodologa y las actividades que lo conforman agrupadas de acuerdo
al nivel al cual pertenecen.
Al igual que el proceso, una metodologa tiene disponible tres estados de publicacin: Bajo
revisin, Bajo prueba y Publicado. Por defecto, al crearse una nueva metodologa el estado
de publicacin asignado es Bajo revisin.
El mantenimiento de cada uno de los elementos que conforman el flujo de una metodologa es
similar al realizado en el mdulo Modelador de Procesos. La informacin de las actividades y
asociaciones que son extradas de los procesos base solamente podr ser visualizada sin
poder modificarse.
Cabe resaltar que la herramienta mantendr en todo momento la consistencia ante posibles
variaciones en los elementos de los procesos base referenciados. De esta forma, cualquier
modificacin realizada sobre los elementos extrados de los procesos originales se ver
reflejada en la definicin de la metodologa automticamente.
80
las
siguientes
extensiones
del
lenguaje
XPDL:
ProcessMethodology,
3.9.4.
Gestin de Versiones
Los procesos desarrollados en una organizacin, al igual que las metodologas
definidas, pueden variar a lo largo del tiempo debido a diversos motivos, tales como:
Modificaciones en las reglas del negocio manejadas por la empresa, cambios en los roles o
participantes asociados a alguna actividad, refinamiento de procesos, reemplazo o
actualizacin de actividades, entre otros.
Para poder utilizar las funcionalidades de este mdulo se debe acceder a la vista Versin. Esta
vista contiene un rbol donde se listan todas las versiones existentes del proceso o
metodologa con el que se est trabajando.
Con el fin de mantener la coherencia histrica entre las distintas versiones, la herramienta
controlar que slo se puedan realizar modificaciones a un proceso o una metodologa que
tenga activo el indicador de versin actual. De esta forma, si se quisiera modificar alguna
versin anterior se deber crear previamente una nueva versin basada en la versin que se
desee cambiar.
81
3.10.
Plan de Pruebas
Para probar el correcto funcionamiento de la herramienta MJS Process Designer se
elabor un plan de pruebas que permita identificar errores durante su funcionamiento, esto con
el objetivo de poder corregirlos antes de finalizar la elaboracin del sistema.
Con el fin de probar los casos de uso especificados en el ERS (Anexo C: Especificacin de
Requisitos de Software) se elabor un conjunto de pruebas de tipo funcional.
UC 25-1
Objetivo :
Precondicin:
Proceso:
Resultado
Esperado:
UC 30-1
Objetivo :
Precondicin:
Proceso:
Resultado
Esperado:
explosin.
82
Diagramado de metodologa
ID Prueba:
UC 23-1
Objetivo :
Precondicin:
Proceso:
Resultado
Esperado:
UC 33-1
Objetivo :
Precondicin:
Proceso:
Resultado
Esperado:
83
4.
Construccin y Pruebas
En este captulo se presenta la fase final del proyecto, que corresponde a las etapas de
En la primera seccin del presente captulo se detalla la lgica utilizada para la implementacin
de los componentes que constituyen la herramienta MJS Process Designer. Posteriormente,
se hace mencin a las buenas prcticas seguidas durante la etapa de diseo y desarrollo de la
misma. Finalmente, se presentan las pruebas integrales de cada uno de los mdulos de la
herramienta, las cuales fueron ejecutadas de forma satisfactoria garantizando as el correcto
funcionamiento del sistema.
4.1.
Implementacin de Componentes
A continuacin se presentan algunas de las principales consideraciones que se
4.1.1.
desarrollo Eclipse, el tipo de proyecto que se utiliz fue el denominado Dynamic Web Project,
cuya estructuracin interna se muestra en la ilustracin 4-1.
84
a. /src/:
En este directorio se encuentran las clases Java, las cuales estn dividas en siete paquetes:
mjsprocess.comun: En este paquete se encuentran los archivos Java que son de uso
comn por las diferentes clases de la aplicacin, como por ejemplo: Constants.java (archivo
de constantes).
mjsprocess.domain: Este paquete agrupa todos los beans de entidad usados por la
aplicacin, los cuales representan las diferentes entidades que forman parte de la lgica del
negocio.
mjsprocess.service: Est conformado por las interfaces Java que definen los mtodos
necesarios para el manejo de la lgica del negocio de la herramienta.
mjsprocess.service.db: Este paquete contiene las clases que implementan las interfaces
que se encargan del manejo de la lgica del negocio de la herramienta.
85
b. /WebContent/css:
En este directorio se encuentran almacenadas las hojas de estilo usadas por la herramienta.
c. /WebContent/imagenes/:
Contiene las imgenes e iconos usados por la herramienta.
d. /WebContent/js/:
Agrupa un conjunto de archivos JavaScript que contienen funciones que son usadas en la capa
de presentacin de la herramienta. En este directorio se encuentran tambin el conjunto de
archivos que conforman el motor de modelado grfico de la herramienta MJS Process
Designer.
e. / WebContent /WEB-INF/context/:
Contiene el conjunto de archivos XML, los cuales son utilizados como archivos de configuracin
para el uso del framework Spring.
f.
/ WebContent /WEB-INF/jsp/:
En este directorio residen los archivos JSP utilizados por la aplicacin, los cuales forman parte
de la interfaz de usuario del aplicativo.
g. /WebContent/WEB-INF/lib/:
Agrupa los archivos JAR que estn siendo utilizados por la herramienta.
h. / WebContent /WEB-INF/web.xml:
Este archivo contiene elementos de configuracin del sistema, como por ejemplo: Pgina de
inicio, ubicacin y mapeo de servlets, manejo de errores, entre otros.
i.
/ WebContent /WEB-INF/dwr.xml:
En este archivo se declaran las clases Java que podrn ser llamadas desde una funcin
JavaScript con la finalidad de utilizar la tecnologa AJAX.
4.1.2.
Configuracin de Spring
Una de las caractersticas principales de Spring es que permite configurar y crear
Spring acta como un contenedor que se encarga de almacenar los objetos de una aplicacin,
manejar su ciclo de vida, declarar cmo es que estos objetos van a ser creados, cmo es que
van a ser configurados y en qu forma se van a asociar entre ellos.
86
87
Seccin de Listener:
Son tres listener principales que deben ser especificados en el archivo web.xml:
Log4jConfigListener: Permite utilizar la librera log4j que sirve para poder dejar trazas
durante la ejecucin de la aplicacin, lo cual es de mucha utilidad durante la etapa de
desarrollo.
Seccin de Contexto:
El elemento context-param, como su nombre lo indica, sirve para sealar todos los parmetros
globales que sern utilizados por la aplicacin. Uno de los parmetros especificados en este
archivo es la ruta en donde se encuentran los archivos de configuracin de Spring y cmo es
que son nombrados.
Como se puede observar en el archivo fuente 4-1, para el caso de la herramienta MJS Process
Designer son todos aquellos archivos que se encuentran en el directorio /WEB-INF/context/ y
cuyos nombres empiezan con applicationContext.
Seccin de Servlet
En esta seccin se requiere definir el servlet de Spring, el cual ser el encargado de atender los
eventos que se producen en la aplicacin.
La configuracin de dicho servlet se encuentra definida en los archivos que empiecen con
applicationServlet, los cuales se encuentran ubicados en el directorio /WEB-INF/context/.
88
Seccin Tag
En esta seccin se agregan todas aquellas libreras de etiquetas (taglib) que sern usadas por
la aplicacin. En el archivo fuente 4-1 se puede apreciar que ha sido agregado el taglib que
provee Spring para que dichas etiquetas puedan ser utilizadas en las pginas JSP.
Los archivos de configuracin manejados por la herramienta MJS Process Designer son los
siguientes:
a. Archivo applicationServlet.xml
En el archivo fuente 4-2 se muestra un extracto del archivo applicationServlet.xml utilizado por
la herramienta MJS Process Designer, el cual est dividido en dos secciones: View Resolver y
Excepciones.
89
que las vistas de la aplicacin trabajen con las etiquetas que ofrece la librera JSTL y se indica
cules sern los prefijos y sufijos agregados a los nombres lgicos de las mismas.
De esta forma cuando se solicite a la herramienta MJS Process Designer una vista index, el
bean viewResolver proveer la vista WEB-INF/jsp/index.jsp.
Seccin Excepciones
En
esta
seccin
se
declara
un
bean
de
excepcin
perteneciente
la
clase
b. Archivo applicationServlet-controllers.xml
En este archivo se definen los beans de tipo Controller utilizados en la aplicacin. Los tipos de
controladores utilizados por la herramienta MJS Process Designer son los que derivan de la
clase SimpleController y los que derivan de la clase MultiActionController. El primer tipo de
controlador posee un nico mtodo a ejecutar al momento de ser invocado, mientras que el
segundo tipo puede tener ms de un mtodo asociado.
<bean id="PaqueteFullController"
class="mjprocess.web.servlet.mvc.PaqueteFullController">
<property name="methodNameResolver" ref="paqueteControllerResolver"/>
<property name="servicePaquete" ref="PaqueteService" />
<property name="serviceConstante" ref="ConstanteService" />
<property name="serviceCabecera" ref="DefinicionCabeceraService" />
<property name="serviceScript" ref="ScriptPaqueteService" />
<property name="serviceRedefinicionCabecera" ref="RedefinicionCabeceraService" />
</bean>
....
<bean id="paqueteControllerResolver"
class="org.springframework.web.servlet.mvc.multiaction.ParameterMethodNameResolver">
<property name="paramName">
<value>
accion
</value>
</property>
</bean>
Spring define una interfaz denominada MethodNameResolver, la cual debe ser implementada
por todas las clases que se utilicen para identificar el mtodo a llamar. Dichas clases deben
ser referenciadas a travs de una propiedad cuyo nombre sea methodNameResolver.
90
En el archivo fuente 4-3 se puede observar que el bean paqueteControllerResolver que deriva
de la clase ParameterMethodNameResolver, permite identificar el nombre del mtodo a
invocar.
Es importante tener en cuenta que la definicin de un bean requiere indicar como mnimo el
identificador (id) y la clase a la que pertenece (class). Adicionalmente, si dicha clase posee
atributos, estos deben ser definidos a travs de la etiqueta <property>, en la cual se debe
indicar el nombre del atributo (name) y el nombre del bean o clase de Spring (ref) al cual se
hace referencia.
De acuerdo al patrn de diseo utilizado por la herramienta MJS Process Designer, los objetos
de tipo Service son invocados a travs de los objetos tipo Controller. Como se observa en el
archivo fuente 4-3, el bean PaqueteFullController hace referencia a varios beans de tipo
Service, entre los que se encuentran: PaqueteService, ConstanteService, entre otros.
Al
mismo tiempo, las clases a las que pertenecen los beans que son configurados en este archivo
deben implementar los mtodos get y set por cada uno de los property definidos, tal y como se
muestra en el archivo fuente 4-4. Esto con la finalidad de cumplir con los requisitos bsicos
para el uso del patrn de Inversin de Control.
91
c. Archivo applicationServlet-handlerMapping.xml
La funcionalidad bsica que provee el HandlerMapping es determinar segn el contenido del
request, que acciones deben llevarse a cabo.
La herramienta MJS Process Designer define un bean denominado urlMapping que deriva de la
clase BeanNameUrlHandlerMapping, el cual permite mapear una direccin URL directamente a
un bean.
<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="urlMap">
<map>
<entry key="/nuevo_paquete.htm"><ref bean="PaqueteFullController" /> </entry>
<entry key="/mantPaq_General.htm"><ref bean="PaqueteFullController" /></entry>
....
</map>
</property>
</bean>
92
Uno de estos archivos es el jdbc.properties, el cual contiene los datos necesarios para realizar
la conexin a la base de datos. Entre los datos que se encuentran en este archivo se tienen:
nombre del driver de la base de datos, usuario, contrasea y direccin Web.
<bean id="propertyConfigurer"
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="locations">
<list> <value>/WEB-INF/jdbc.properties</value> </list>
</property>
</bean>
b. Archivo applicationContext-Domain.xml
Este archivo contiene la lista de beans de tipo DAO y Service utilizados por la aplicacin
(archivo fuente 4-7).
4.1.3.
estndar de trabajo definido por el framework Spring, se decidi utilizar el API DWR (Direct
Web Remoting). Este API brinda una interfaz sencilla para la integracin con Spring, al mismo
tiempo, permite realizar llamadas remotas y de forma directa desde cdigo JavaScript (que se
ejecuta en un navegador Web) a objetos Java que se encuentran en el servidor.
93
Para poder realizar este tipo de llamadas remotas se requiere que la configuracin del API
DWR se encuentre tanto en el lado del servidor como en el lado del cliente.
Dicha
funcionalidades que ofrece Direct Web Remoting, las cuales van desde la generacin del
cdigo JavaScript a utilizar en el cliente hasta el marshalling de tipos de datos, incluyendo por
supuesto la invocacin a los mtodos remotos.
Como cualquier otro servlet, DWRServlet debe ser declarado y mapeado hacia alguna URL en
el archivo web.xml de la aplicacin Web, tal y como se muestra en el archivo fuente 4-8.
B. Exportacin de los Objetos Java que sern llamados desde cdigo JavaScript
Todas las declaraciones necesarias para realizar llamadas remotas a los mtodos de los
objetos Java que se encuentran en el servidor se realizan en el archivo dwr.xml.
Cabe
mencionar que para la presente herramienta estos objetos son los que se encuentran en la
capa Service, ya que son ellos los que se encargan de controlar la lgica del negocio.
Las clases a las que pertenecen los objetos Java cuyos mtodos podrn ser llamados desde el
cliente son definidas con la etiqueta <create>, tal como se muestra en el archivo fuente 4-9.
94
En esta etiqueta se indica cmo se deben crear y manejar dichas instancias a travs de los
siguientes atributos:
Para la
JavaScript: Es el nombre con el que ser referenciado el objeto desde alguna funcin de
tipo JavaScript.
El elemento Create tambin incluye una serie de parmetros necesarios, los cuales son:
BeanName: Nombre del bean declarado en los archivos de configuracin Spring que ser
exportado.
Las funciones JavaScript, que hacen referencia a los mtodos de una misma clase exportada,
se agrupan en un mismo fichero de extensin .js. Cada uno de estos ficheros se obtiene de la
URL: <servletdwrpath>/interface/<nombreclase>.js.
Para poder hacer uso de estas funciones JavaScript se siguen los siguientes pasos:
Inclusin de los ficheros .js: Se debe incluir en la cabecera de las pginas Web que
utilizan los mtodos de los objetos exportados la URL mostrada en el archivo fuente 4-10.
95
<head>
<script type="text/javascript"
src="<%=request.getContextPath()%>/dwr/interface/creadorProceso.js">
</script>
</head>
Invocacin a los mtodos exportados: Dado que las llamadas a los mtodos remotos
deben ser asncronas, no se puede llamar directamente a un mtodo y obtener un
resultado. Para que una llamada remota con DWR funcione es necesario pasarle como
parmetro una funcin de callback, la cual se encarga de procesar la respuesta del
servidor.
4.1.4.
96
Debido a que el desarrollo de la herramienta MJS Process Designer incluye la extensin del
lenguaje XPDL, se tuvo que generar un nuevo esquema basado en el esquema propio de dicho
lenguaje y que adems inclua la estructura de las extensiones realizadas al mismo.
Este nuevo esquema tuvo que ser compilado utilizando el JAR XBean propio del XMLBeans,
obtenindose como resultado un archivo JAR. Dicha librera contena el conjunto de clases
necesarias para generar el archivo XML de la definicin de un paquete.
Para que la herramienta MJS Process Designer realice la exportacin de las definiciones de un
paquete se siguieron los siguientes pasos:
4.2.
Se incluy la documentacin del cdigo fuente como parte del proceso de desarrollo de la
herramienta, con la finalidad de facilitar el entendimiento por parte del desarrollador que
requiera realizar una modificacin a la herramienta en el futuro.
De esta forma,
97
La inclusin de cdigo de Java nativo dentro de una pgina HTML (scriptles) permite
realizar operaciones ms complejas de las que se pueden elaborar con el lenguaje
JavaScript, pero a su vez hace ms ilegible y desordenado el cdigo fuente de la pgina
Web. Esto obliga a que el usuario posea cierto dominio del lenguaje Java para entender o
modificar dicha pgina.
Una alternativa a este inconveniente, es el uso de la librera JSTL, la cual brinda un
adecuado manejo de la informacin que es enviada desde el servidor a las pginas Web
que se encuentran en la capa de presentacin sin necesidad de incluir scriptles y
manteniendo el estndar de codificacin Web.
El uso del patrn de diseo MVC asegura la separacin de la lgica del negocio con la
capa de presentacin de la herramienta.
4.3.
Pruebas de Componentes
Con la finalidad de probar el cumplimiento de los requerimientos establecidos para la
herramienta MJS Process Designer se eligi el modelado de uno de los procesos principales de
desarrollo de la metodologa Mtrica v3.
98
Mtrica v3 est conformada por cuatro procesos principales de desarrollo, los cuales a su vez
estn conformados por actividades y estas ltimas se subdividen en tareas. Los procesos
principales que conforman Mtrica v3 son:
Anlisis.
Diseo.
Construccin.
4.3.1.
Modelador de Procesos
Para la prueba del mdulo Modelador de Procesos se escogi modelar el primer
proceso de Mtrica v3: Estudio de Viabilidad del Sistema, el cual est compuesto por las
siguientes actividades:
Seleccin de la solucin.
Para poder registrar una definicin de proceso, el usuario deber abrir una definicin de
paquete previamente registrada en el sistema o crear una nueva. Una vez abierto o creado el
paquete, el usuario podr visualizar la lista de mantenimientos disponibles en la herramienta,
los cuales le permitirn realizar el mantenimiento de la informacin y elementos relacionados al
paquete. Entre los principales mantenimientos se encuentran:
Definicin de cabecera.
Redefinicin de cabecera.
Script.
Aplicaciones.
Participantes.
Atributos extendidos.
Tipos de datos.
Variables de paquete.
Para poder visualizar uno de los mantenimientos del listado anterior, el usuario deber hacer
clic sobre la opcin acerca de la cual requiere mantener la informacin. Con ello, el formulario
asociado se cargar automticamente en la pestaa de Mantenimiento, en donde el usuario
podr registrar o modificar la informacin relacionada al paquete (ilustracin 4-2).
99
Cabecera de Proceso.
Redefinicin de cabecera.
Parmetros formales.
Participantes.
Aplicaciones.
Atributos extendidos.
Set Activities.
Para poder visualizar uno de los mantenimientos del listado anterior, el usuario deber hacer
clic sobre la opcin acerca de la cual requiere mantener la informacin. Con ello, el formulario
asociado se cargar automticamente en la pestaa de Mantenimiento, en donde el usuario
podr registrar o modificar la informacin relacionada al proceso, tal como se muestra en la
ilustracin 4-3.
100
101
La herramienta permite definir flujos de trabajo paralelos utilizando los diferentes tipos de
conectores lgicos proporcionados; para el ejemplo de prueba (ilustracin 4-4) se utiliz el
conector AND para reflejar la ejecucin sincronizada de las actividades Estudio de la situacin
actual y Definicin de los requisitos del sistema.
Al finalizar el diagramado, el usuario deber grabar en el sistema el estado actual del flujo de
trabajo modelado con la finalidad de asegurar la consistencia al iniciar el mantenimiento de la
informacin de los elementos diagramados (Modelado Semntico).
4.3.2.
Explosin de Niveles
Para la prueba del mdulo de Explosin de Niveles se escogi explosionar la actividad
102
Estudio de la solicitud.
Para explosionar una actividad en un nuevo nivel, el usuario deber seleccionar el proceso al
que pertenece la actividad y hacer clic en la opcin Ir a Vista de Explosin.
La herramienta
mostrar un rbol listando el proceso seleccionado, en el cual se irn agregando los nodos
correspondientes a los nuevos niveles creados producto de la explosin de una actividad
(ilustracin 4-6).
Si el usuario desea explosionar una actividad deber cargar el modelado grfico del proceso al
que pertenece en la pestaa Editor Grfico. Como siguiente paso deber seleccionar la
actividad a explosionar (la cual deber ser obligatoriamente de tipo bsico) y hacer clic en la
opcin Explosionar Nodo.
Como resultado de los pasos anteriores, el sistema registrar un nuevo nivel asociado a la
actividad y se agregar un nuevo nodo al rbol de la vista.
Para realizar el modelado grfico del nuevo nivel, el usuario deber hacer clic sobre el nodo
que corresponde a dicho nivel en el rbol de explosin, con lo que se habilitar la pestaa
Editor Grfico. Este modelado es idntico al explicado en la prueba del mdulo Modelador
de Proceso (ilustracin 4-7).
103
4.3.3.
Mdulo de Metodologas
Para la prueba del mdulo de Metodologas se decidi realizar una versin simplificada
104
Seleccin de la solucin.
Para crear una metodologa el usuario deber hacer clic en la opcin Ir a Vista de
Metodologa. El usuario har clic sobre la opcin Nueva Metodologa, a continuacin la
herramienta mostrar un formulario en el cual se ingresarn los siguientes datos: Identificador,
nombre y descripcin. Adicionalmente se debern seleccionar los procesos base de los cuales
se extraern las actividades que conformarn la nueva metodologa.
105
4.3.4.
Mdulo de Versionamiento
Para la prueba del mdulo de Versionamiento se defini crear una nueva versin del
Para versionar un proceso el usuario deber seleccionar el proceso del rbol de la vista actual
y hacer clic en la opcin Ir a Vista de Versionamiento. La herramienta mostrar un rbol
asociado al proceso seleccionado en el cual se listan todas las versiones existentes para dicho
proceso (ilustracin 4-11).
106
Si el usuario desea versionar un proceso deber seleccionar la versin que ser tomada como
base en el rbol de la vista y hacer clic en la opcin Nueva Versin.
La nueva versin creada ser tomada como versin vigente del proceso, el cual podr ser
modificado en el mdulo Modelador de Procesos.
4.3.5.
abrir una definicin previamente registrada y hacer clic en la opcin Generar archivo XPDL.
Como siguiente paso, la herramienta proceder a generar dicho archivo con la definicin del
paquete segn el lenguaje XPDL.
A continuacin, en el archivo fuente 4-12 se muestra el archivo XPDL generado para el ejemplo
anterior:
107
</xpd:Artifact>
<xpd:Artifact Id="art_3" Name="Catalogo de Usuarios" ArtifactType="DataObject">
<xpd:DataObject Id="doc_3" Name="Catalogo de Usuarios" RequiredForStart="false"
ProducedAtCompletion="true" />
</xpd:Artifact>
<xpd:Artifact Id="art_4" Name="Descrip. General del Sistema" ArtifactType="DataObject">
<xpd:DataObject Id="doc_4" Name="Descripcion General del Sistema"
RequiredForStart="false" ProducedAtCompletion="true" />
</xpd:Artifact>
</xpd:Artifacts>
<xpd:WorkflowProcesses>
<xpd:WorkflowProcess Id="EVS" Name="Evaluacion del Sistema de Informacion"
ProcessType="Abstract" Status="Aborted" AccessLevel="PUBLIC">
<mjs:ProcessCategory>
<mjs:ProcessBasic>
<mjs:VersionInformation IdVersion="0" CurrentVersion="0" />
</mjs:ProcessBasic>
</mjs:ProcessCategory>
<xpd:ProcessHeader>
<xpd:Created>17/05/2008</xpd:Created>
<xpd:Limit>0.0</xpd:Limit>
<xpd:TimeEstimation>
<xpd:WaitingTime>0.0</xpd:WaitingTime>
<xpd:WorkingTime>0.0</xpd:WorkingTime>
<xpd:Duration>0.0</xpd:Duration>
</xpd:TimeEstimation>
</xpd:ProcessHeader>
<xpd:RedefinableHeader PublicationStatus="UNDER_REVISION" />
<xpd:Activities>
<xpd:Activity Id="sta_1" Name="nodo_1">
<xpd:Event><xpd:StartEvent /></xpd:Event>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="conand_6" Name="nodo_5">
<xpd:Route GatewayType="AND" />
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="end_15" Name="nodo_8">
<xpd:Event><xpd:EndEvent /></xpd:Event>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_esa" Name="Estudio de la situacin actual" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_drs" Name="Definicin de los requisitos del sistema"
IsATransaction="false" StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
108
</xpd:Activity>
<xpd:Activity Id="act_easol" Name="Estudio de alternativas de solucin"
IsATransaction="false" StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_val" Name="Valoracin de las alternativas" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_ssol" Name="Seleccin de la solucin" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="conand_10" Name="nodo_6">
<xpd:Route GatewayType="AND" />
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
<xpd:TransitionRestrictions>
<xpd:TransitionRestriction>
<xpd:Join Type="AND" />
</xpd:TransitionRestriction>
<xpd:TransitionRestriction>
<xpd:Split Type="AND">
<xpd:TransitionRefs>
<xpd:TransitionRef Id="tran7" Name="tran7" />
</xpd:TransitionRefs>
</xpd:Split>
</xpd:TransitionRestriction>
</xpd:TransitionRestrictions>
</xpd:Activity>
<xpd:Activity Id="act_eas" Name="Establecimiento del alcance del sistema"
IsATransaction="false" StartActivity="false">
<xpd:Description>Establecimiento del alcance del sistema</xpd:Description>
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType >
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
<xpd:InputSets>
<xpd:InputSet>
<xpd:Input ArtifactId="art_1">
<mjs:IOIdentifier OwnerId="0" PersonalId="1">
</xpd:Input>
</xpd:InputSet>
</xpd:InputSets>
<xpd:OutputSets>
<xpd:OutputSet>
<xpd:Output ArtifactId="art_2">
<mjs:IOIdentifier OwnerId="0" PersonalId="2" />
</xpd:Output>
</xpd:OutputSet>
109
</xpd:OutputSets>
</xpd:Activity>
</xpd:Activities>
<xpd:Transitions>
<xpd:Transition Id="tran1" From="sta_1" To="act_eas" Name="transicion1">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran3" From="conand_6" To="act_esa" Name="tran3">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran4" From="conand_6" To="act_drs" Name="tran4">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran5" From="act_esa" To="conand_10" Name="tran5">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran6" From="act_drs" To="conand_10" Name="tran6">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran8" From="act_easol" To="act_val" Name="tran8">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran9" From="act_val" To="act_ssol" Name="tran9">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran10" From="act_ssol" To="end_15" Name="tran10">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
</xpd:Transition>
<xpd:Transition Id="tran7" From="conand_10" To="act_easol" Name="tran7">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
<xpd:Transition Id="tran2" From="act_eas" To="conand_6" Name="tran2">
<xpd:Condition Type="CONDITION" />
</xpd:Transition>
</xpd:Transitions>
</xpd:WorkflowProcess>
<xpd:WorkflowProcess Id="EVS" Name="Evaluacion del Sistema de Informacion"
ProcessType="Abstract" AccessLevel="PUBLIC">
<mjs:ProcessCategory>
<mjs:ProcessBasic>
<mjs:VersionInformation IdVersion="1" CurrentVersion="1" />
</mjs:ProcessBasic>
</mjs:ProcessCategory>
<xpd:ProcessHeader>
<xpd:Created>19/05/2008</xpd:Created>
</xpd:ProcessHeader>
<xpd:RedefinableHeader PublicationStatus="UNDER_REVISION" />
<xpd:Activities>
<xpd:Activity Id="sta_1" Name="nodo_1">
<xpd:Event><xpd:StartEvent /></xpd:Event>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="conand_6" Name="nodo_5">
<xpd:Route GatewayType="AND" />
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
110
</xpd:Activity>
<xpd:Activity Id="end_15" Name="nodo_8">
<xpd:Event><xpd:EndEvent /></xpd:Event>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_esa" Name="Estudio de la situacin actual" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_drs" Name="Definicin de los requisitos del sistema"
IsATransaction="false" StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_easol" Name="Estudio de alternativas de solucin"
IsATransaction="false" StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_val" Name="Valoracin de las alternativas" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="act_ssol" Name="Seleccin de la solucin" IsATransaction="false"
StartActivity="false">
<xpd:Implementation><xpd:No /></xpd:Implementation>
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
</xpd:Activity>
<xpd:Activity Id="conand_10" Name="nodo_6">
<xpd:Route GatewayType="AND" />
<mjs:ActivitySourceType>
<mjs:ActivityBasic />
</mjs:ActivitySourceType>
<xpd:TransitionRestrictions>
<xpd:TransitionRestriction>
<xpd:Join Type="AND" />
</xpd:TransitionRestriction>
<xpd:TransitionRestriction>
<xpd:Split Type="AND">
<xpd:TransitionRefs>
<xpd:TransitionRef Id="tran7" Name="tran7" />
</xpd:TransitionRefs>
</xpd:Split>
</xpd:TransitionRestriction>
</xpd:TransitionRestrictions>
</xpd:Activity>
111
112
113
114
115
5.
tesis, las conclusiones obtenidas y las recomendaciones que se han considerado pertinentes.
5.1.
Observaciones
Las investigaciones y el anlisis realizados previos al desarrollo de la herramienta permiten
identificar los conceptos, las tcnicas y estrategias utilizadas en la actualidad para la
definicin de procesos. Esto permite centrar esfuerzos en las deficiencias o vacos aun no
cubiertos en esta rea con el fin de evitar reinventar conceptos o herramientas previamente
desarrollados.
116
Para la etapa de anlisis se utiliz la notacin grfica UML como notacin estndar para la
construccin de los artefactos de software.
117
El uso del framework Spring brinda grandes beneficios para la construccin de aplicaciones
en base a componentes, como lo es la herramienta MJS Process Designer.
Cada
118
generado para toda persona involucrada en el citado desarrollo. Entre las acciones ms
importantes a realizar se tienen: la actualizacin permanente del diccionario de datos y el
establecimiento de un repositorio de versiones para la documentacin y mdulos
desarrollados.
En el caso de no establecer una adecuada gestin de la configuracin se podra presentar
problemas durante el proceso de desarrollo del sistema, como por ejemplo: Prdida de
versiones desarrolladas, retrasos al no conocer los avances realizados por otros miembros
del equipo, entre otros.
La
herramienta
MJS
Process
Designer
est
enmarcada
dentro
del
proyecto
5.2.
Conclusiones
Luego de haber ejecutado las pruebas de cada uno de los componentes de la herramienta,
las cuales incluan la definicin de procesos de marcos referenciales como por ejemplo
Mtrica v3; se puede concluir que se logr construir una herramienta que brinda los
elementos necesarios para la definicin y el almacenamiento de procesos.
Se puede concluir que MJS Process Designer es una herramienta que congrega los
conceptos de explosin de niveles, definicin de metodologas y gestin de versiones de
procesos y metodologas en una sola herramienta.
realizada sobre el lenguaje XPDL para incluir dichos conceptos, se elimina la necesidad de
crear un LDP propio que obstaculice el posible intercambio de dichas definiciones con otras
herramientas.
Se comprob las bondades que brinda el lenguaje XPDL para la definicin de procesos
debido a la gran variedad de elementos que incorpora, los cuales a su vez pueden ser
representados grficamente utilizando la notacin BPMN.
119
Se puede afirmar que la herramienta MJS Process Designer cumple con los objetivos de
acceso descentralizado por parte de los usuarios que hacen uso de ella. La plataforma
Web sobre la cual ha sido construida permite que cualquier usuario registrado en el sistema
pueda acceder a ella desde cualquier ubicacin geogrfica.
Se desarroll la herramienta MJS Process Designer de forma que sea amigable y de fcil
uso para el usuario. Esto se logr mediante el uso de las tecnologas AJAX y DHTML, las
cuales permiten que el funcionamiento de la herramienta sea ms interactivo y dinmico.
Adicionalmente, el modelado grfico de procesos se realiza a travs operaciones simples e
intuitivas para el usuario.
Se logr construir una herramienta modeladora de procesos con una slida arquitectura
basada en el framework Spring y los patrones de diseo MVC, Business Delegate y Data
Access Object, los cuales facilitan su mantenimiento y su posible ampliacin en el futuro.
El uso de patrones de diseo y buenas prcticas permiti cumplir con las caractersticas
principales del modelo de calidad planteado en la norma ISO 9126.
Se logr construir una herramienta con la capacidad de interactuar con otras herramientas
que utilicen el mismo lenguaje de definicin de procesos formal, salvaguardando as su
interoperabilidad.
5.3.
Recomendaciones
Si bien es cierto que la presente herramienta est concebida como un proyecto de fin de
carrera (pre-grado), sta ha sido desarrollada de tal forma que sirva de base para que en
un futuro, con las correcciones y mejoras necesarias, se convierta en un producto de
categora comercial satisfaciendo las necesidades existentes en el mercado.
Como trabajo futuro se recomienda culminar con la implementacin de las entidades del
lenguaje XPDL que no estn incluidas dentro de la herramienta, esto con la finalidad de
ampliar la gama de entidades disponibles para el modelado de procesos.
120
121
Bibliografa
[1] ISO/IEC 12207.1995/2002 Information Technology. Software Life Cycle Process.
[2] Norma Tcnica Peruana NTP-ISO/IEC12207. Visitado 2007, de
http://www.bvindecopi.gob.pe/normas/isoiec12207.pdf
[3] Workflow Management Coalition. Workflow Standard. Process Definition Interface XML
Process Definition Language" Document Number WFMC-TC-1025 Versin2.0. (2005).
[4] Curtis, B.; Kellner, M.; Over, J.: Processs Modeling. Communications of The ACM, Vol. 35.
New York, NY, USA (1992)
[5] Booch, G.; Rumbaugh, J.; Jacobson, I.: The Unified Modeling Language User Guide.
Addison Wesley, Massachusetts (2005).
[6] Jacobson, I.: Applying UML in The Unified Process. (1998)
[7] Fuggetta, A. Software process: a roadmap. 2000. International Conference on Software
Engineering (ICSE). ACM Press.
[8] Derniame, J.C.; Kaba, A.; Warboys, B.: The Software Process: Modelling and Technology, in
Software process: principles, methodology, and Technology. C. Montenegro, Editor. (1999).
[9] Manual de Procesos Documentacin de Procesos USBI-VER Unidad de Servicios
Bibliotecarios y de Informacin Universidad Veracruzana Regin Veracruz-Boca del Ro Mxico
Febrero 16 de 2003
[10] Gestin de Proyectos: Modelado de procesos. Visitado 2007, de
http://www.gestionempresarial.info/VerItemProducto.asp?Id_Prod_Serv=30&Id_Sec=8
[11] BPM: The Promise and the challenge. Visitado 2007, de
http://delivery.acm.org/10.1145/990000/984503/verner.pdf?key1=984503&key2=7331696811&c
oll=GUIDE&dl=GUIDE&CFID=15151515&CFTOKEN=6184618
[12] Anexo I - Anlisis, Diseo y Construccin de una herramienta para Modelado de Procesos:
MJS Process Designer
[13] Ould, M.: Business Processes: Modelling and Analysis for reengineering and
Improvement. John Wiley & Sons (1995).
122
123
124
125
Mritos
126