trabajo de diploma intervar

Universidad Central “Marta Abreu” de Las Villas

Facultad Matemática, Física y Computación

Licenciatura en Ciencia de la Computación

Trabajo de Diploma

INTERVAR

Sistema para la interpretación de archivos XPDL

correspondientes a procesos de negocio modelados con

notación gráfica BPMN.

Autor: Marlon Esquivel Ariz.

Tutores: Dra. Gheisa Lucía Ferreira Lorenzo

Ing. Yaimara Granados Hondares

Santa Clara, Cuba, 2014

“Año 55 de la Revolución”

Dictamen

Dictamen

Hago constar que el presente trabajo fue realizado en la Universidad Central “Marta Abreu” de

Las Villas como parte de la culminación de los estudios de la especialidad de Licenciatura en

Ciencia de la Computación, autorizando a que el mismo sea utilizado por la institución, para los

fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser

presentado en eventos ni publicado sin la autorización de la Universidad.

Firma del autor ____________

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

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

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

Firma del tutor ____________ Firma del jefe del Seminario____________

Pensamiento

Pensamiento

Ser culto es único modo de ser libre.

José M. Pérez B.

Agradecimientos

Agradecimientos

Agradezco a todos los que de una forma u otra ayudaron a la realización de

este trabajo.

Agradecimientos

Dedicatoria

Dedicatoria

A mi mamá, mi hermano, mi abuela a mis familiares y

a todos mis amigos.

Resumen

vii

Resumen

Las notaciones y lenguajes para modelar procesos de negocio se utilizan desde hace ya varias

décadas en numerosos campos de la industria. Su objetivo principal es la búsqueda de costes y

tiempos óptimos. Sin embargo, el uso de esta técnica es relativamente reciente dentro del ámbito

de la Ingeniería del Software. El presente trabajo define una herramienta para determinar de

forma automática la cantidad de cada una de las variables que intervienen en el cálculo de la

complejidad de informatizar un proceso de negocio a partir de su representación gráfica, en

notaciones de procesos altamente difundidas como BPMN.

Abstract

viii

Abstract

Notations and languages for business process management are in use since decades in numerous

fields of industry. Their main target is seeking of optimal costs and times. However, the use of

this technique is relatively recent inside Software Engineering. The present work defines a tool

to automatically determine the amount of each of the variables involved in the calculation of the

complexity involved in the automation of a business process using its graphics representation in

widespread process notations like BPMN.

Índice

ix

CONTENIDO

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

CAPÍTULO 1. ................................................................................................................................. 4

LENGUAJES DE MODELADO DE PROCESOS DE NEGOCIO.SELECCIÓN DE FORMATOS

DE SALIDA A INTERPRETAR. ...................................................................................................... 4

1.1 MODELADO DE PROCESOS DE NEGOCIO. .............................................................................................................. 5

1.1.1 BPM ............................................................................................................................................................ 5

1.2 LENGUAJES DE MODELADO. ................................................................................................................................. 6

1.2.1 BPMN .......................................................................................................................................................... 6

1.2.2 UML ............................................................................................................................................................ 8

1.2.3 IDEF ........................................................................................................................................................... 9

1.3 SELECCIÓN DE LA HERRAMIENTA A UTILIZAR .................................................................................................... 11

1.4 FORMATO DE SALIDA XPDL DE LA HERRAMIENTA BIZAGI. .............................................................................. 12

1.5 HERRAMIENTAS PARA EL DESARROLLO DE LA APLICACIÓN. .............................................................................. 13

1.6 CONCLUSIONES PARCIALES ................................................................................................................................ 14

CAPÍTULO 2. ............................................................................................................................... 15

DESCRIPCIÓN DE LA PROPUESTA DE SOLUCIÓN ............................................................... 15

2.1 MODELADO DEL NEGOCIO.................................................................................................................................. 16

2.2 REQUISITOS ....................................................................................................................................................... 16

2.3 DIAGRAMA DE CASOS DE USO DEL SISTEMA. ...................................................................................................... 17

2.4 ESPECIFICACIÓN DEL CASO DE USO “INTERPRETAR VARIABLES” ...................................................................... 18

2.5 DIAGRAMA DE SECUENCIA DEL CASO DE USO INTERPRETAR VARIABLES. ......................................................... 22

2.6 DIAGRAMA DE CLASES DEL DISEÑO. .................................................................................................................. 23

2.7 DIAGRAMA DE COMPONENTE. ............................................................................................................................ 24

2.8 INTERPRETACIÓN DE LOS ARCHIVOS XPDL ....................................................................................................... 25

2.7.1 Variable BE: Número de eventos inicio y fin. .......................................................................................... 27

2.7.2 Variable NMC: Número de Mecanismos de Control .............................................................................. 28

2.7.3 Variable NT: Número de Tareas ............................................................................................................... 29

2.7.4 Variable NMD: Número Máximo de Dependencias............................................................................... 30

2.7.5 Variable NE: Número Entidades ............................................................................................................. 31

2.7.6 Variable NF: Número de Fronteras ........................................................................................................ 31

2.7.7 Variable NS: Número Sujetos del Negocio ............................................................................................ 32

2.8 ALGORITMO DE INTERPRETACIÓN. ..................................................................................................................... 33

Índice

x

2.9 CONCLUSIONES PARCIALES DEL CAPÍTULO. ....................................................................................................... 35

CAPÍTULO 3. ............................................................................................................................... 36

VALIDACIÓN DE LA PROPUESTA DE SOLUCIÓN. ................................................................ 36

3.1 DISEÑO DE LOS CASOS DE PRUEBA ..................................................................................................................... 37

3.2 CONCLUSIONES PARCIALES DEL CAPÍTULO. ....................................................................................................... 41

CONCLUSIONES ......................................................................................................................... 42

RECOMENDACIONES ................................................................................................................ 43

REFERENCIAS BIBLIOGRÁFICAS ............................................................................................ 44

ANEXOS ........................................................................................................................................ 45

Índice

xi

Lista de Figuras

Figura 1: Diagrama de Casos de Uso del Negocio. ...................................................................... 16

Figura 2: Diagrama de casos de Uso del sistema .......................................................................... 18

Figura 3: Diagrama de secuencia del caso de uso Interpretar Variables. ..................................... 22

Figura 4: Diagrama de Clases del Diseño. .................................................................................... 23

Figura 5: Diagrama de Componentes. .......................................................................................... 25

Figura 6: PN Gestión y Aprobación de Cursos y Entrenamientos ............................................... 26

Figura 7: Formato XPDL que representa Eventos. ....................................................................... 27

Figura 8 : Formato XPDL Número de Mecanismos de Control. ................................................ 28

Figura 9: Formato XPDL que representa Número de Tareas. ...................................................... 29

Figura 10: Formato XPDL Número Máximo de Dependencias. ................................................ 30

Figura 11: Formato XPDL Número Entidades. ........................................................................... 31

Figura 12:Formato XPDL Número de Fronteras. ........................................................................ 32

Figura 13: Formato XPDL Número de Sujetos del Negocio ...................................................... 32

Figura 14: Pruebas de Caja Negra ................................................................................................ 38

Índice

xii

Lista de Tablas

Tabla 1: Formatos de salida de las herramientas BizAgi y Visual Paradigm. .............................. 11

Tabla 2: Correspondencia Variables Determinadas - Codificación XPDL .................................. 13

Tabla 3: Especificación del Caso de Uso “Interpretar variables” ................................................. 22

Tabla 4: Caso de Prueba "Cargar Archivo" .................................................................................. 38

Tabla 5: Caso de Prueba "Interpretar Archivo" ............................................................................ 39

Tabla 6: Base de casos para comprobar el conteo automático de los elementos correspondientes a

las variables. .................................................................................................................................. 41

Introducción

1

Introducción

Un proyecto de software, es un caso particular de proyecto donde existe una gran incertidumbre

sobre: el resultado final, su costo, sus riesgos y el esfuerzo y tiempo que implica su desarrollo. El

producto final es intangible desde el punto de vista físico, se deteriora con el tiempo y

generalmente se desarrolla a medida (Pressman, 2010), su valor depende no solo de su

corrección, sino del momento en que se pone en servicio, la calidad apreciada por el usuario, su

facilidad de uso, mantenimiento y extensión.

Para estimar el esfuerzo y el costo de los proyectos de software se han desarrollado múltiples

modelos de estimación según plantea (Mendoza, 2009). Uno de los problemas de los modelos de

estimación actuales es que son dependientes del juicio experto y requieren gerentes con

experiencia para aplicarlos. Los gerentes de proyecto con experiencia cada vez son más escasos

y la tendencia actual es a desplazarse hacia metodologías ágiles con equipos altamente reducidos,

motivados y comprometidos con la realización del proyecto (MacConnell, 2006).

Según (Salvetto et al., 2006), independizar la estimación (no la interpretación de los resultados)

del juicio experto aumenta la credibilidad de la industria, facilita la relación entre clientes y

desarrolladores, aumentando su transparencia. Puede ser el comienzo de metodologías de

gestión de contratos que no se basen en un precio cerrado en el momento en que menos se sabe

del proyecto, sino en una metodología de cálculo de acuerdo a las condiciones de ejecución del

proyecto y la complejidad del sistema a construir, que contribuya a poner en evidencia, sobre

bases objetivas, los riesgos que introducen las fechas fijadas con criterios no técnicos, y que

apoye a la gestión conjunta de los cambios, de los plazos y del alcance del proyecto.

Un factor que incide de manera directa y proporcional en los valores estimados de tiempo,

costo y esfuerzo de un proyecto de software es la complejidad. Mientras más complejo es el

producto a desarrollar, mayor será el tiempo que se invertirá en su desarrollo; el esfuerzo que

demandará su realización y los costos asociados. A partir de determinar el nivel de complejidad

que demanda desarrollar un producto de software, se puede tener una idea del tiempo, el costo y

el esfuerzo que se deben invertir en su desarrollo.

Introducción

2

Una buena práctica, ya detallada en (O’Farril, 2012) para medir la complejidad de la

informatización de una organización, pudiera ser a través del modelado de sus procesos de

negocio.

En (O’Farril, 2012) se analizaron algunas de las notaciones utilizadas para el modelado de

procesos de negocio, determinándose un conjunto de variables utilizadas para medir la

complejidad de la informatización de estos. En dicho trabajo de investigación se instanciaron

estas variables para alrededor de 20 procesos de negocio, formándose una base informativa que

permitió desarrollar un procedimiento para la evaluación de la complejidad de la información.

Resulta evidente que cuando los procesos de negocio de una empresa aumentan, la captura

manual de la información relativa a los mismos, para posteriormente aplicar un procedimiento

que determine la complejidad de la informatización a partir de las variables establecidas, resulta

un proceso engorroso. Sin embargo, es una cuestión a analizar, la manera en la cual las

herramientas de modelado, que han ido surgiendo para soportar las diferentes notaciones,

presentan diferentes formatos para guardar o exportar los resultados de la modelación, con el fin

de hacer más fácil el proceso de captura de los datos referentes a cada una de las variables

definidas una vez que aumente la cantidad de procesos de negocio a analizar.

A partir de esta problemática se define el siguiente problema de investigación:

¿Cómo interpretar el formato de salida XPDL de la herramienta Bizagi para el modelado de

procesos de negocio, de manera que se obtengan los datos necesarios para evaluar la complejidad

de estos a partir de su representación gráfica?

En consecuencia con lo planteado surge el siguiente objetivo general:

Diseñar e implementar una herramienta capaz de interpretar el formato de salida XPDL de la

herramienta Bizagi, con el fin de obtener archivos con información de las variables definidas

para el cálculo de la complejidad de la informatización de los procesos de negocio.

La satisfacción de tal objetivo depende del cumplimiento de los siguientes objetivos específicos:

1. Determinar cómo se presentan las variables de estimación de la complejidad de la

informatización de procesos de negocio, en el formato de salida XPDL de la herramienta

Bizagi.

2. Diseñar e implementar una herramienta que permita interpretar el formato de salida

XPDL de la herramienta Bizagi, con extracción de datos necesarios para el procedimiento

de evaluación de la complejidad de un proceso de negocio.

3. Validar la herramienta desarrollada a partir de casos de prueba que comprueben el

funcionamiento adecuado de la misma.

Introducción

3

Estructura del documento por capítulos

Capítulo I

En este capítulo se describen de los aspectos principales del estado del arte en cuanto a las

diferentes notaciones de modelado de procesos de negocios, así como herramientas que soportan

dichas notaciones. Se destaca también el conjunto de tecnologías utilizadas para la construcción

del sistema propuesto.

Capítulo II

En este capítulo se describen las diferentes etapas de desarrollo del sistema, haciendo énfasis en

forma de interpretar los archivos XPDL a fin de obtener los datos deseados.

Capítulo III

En este capítulo se evalúa el software desarrollado a partir del diseño de diferentes casos de

prueba que permitan demostrar la funcionalidad de la herramienta.

Capítulo 1: Lenguajes de modelado de procesos de negocio.

Selección de formatos de salida a interpretar.

4

Capítulo 1.

LENGUAJES DE MODELADO DE PROCESOS

DE NEGOCIO.SELECCIÓN DE FORMATOS DE

SALIDA A INTERPRETAR.



5

En el presente capítulo se realiza un análisis de diferentes lenguajes utilizados para modelar

procesos de negocio plasmados en (O’Farril 2012) que sirvieron como referente para la selección

de variables que pudieran influir en el cálculo de la complejidad de un proceso de negocio. Se

seleccionan de las herramientas que soportan cada lenguaje los formatos de salida candidatos a

ser interpretados, con el fin de capturar la mayor cantidad de datos posible relacionados con las

variables antes mencionadas, a partir de la representación gráfica de un proceso de negocio.

1.1 Modelado de procesos de Negocio.

Los modelos de negocio son representaciones de algo real, construidas a cierta escala y nivel de

detalle para mostrar puntos de vista, son representativos en el tiempo y construidos para un

propósito. Algunas de las partes del negocio pueden ser modeladas superficialmente mientras

que otras necesitan ser exactamente definidas en aras de automatizarlas (García, 2012).

La organización de los procesos de negocios, sobre todo en las empresas, ha demostrado su

eficiencia en la reducción de errores, asegurando que los procesos se comporten siempre de la

misma manera, y dando elementos que permitan visualizar el estado de los mismos durante cada

etapa (Laue and Mendling, 2010).

1.1.1 BPM

La metodología BPM (Business Process Management) es una metodología empresarial cuyo

objetivo es, mejorar la eficiencia a través de la gestión sistemática de los procesos de negocio,

que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua. Como

su nombre sugiere, BPM se enfoca directamente en la administración de los procesos del

negocio(Fowler and Scott, 1997).

BPM originalmente automatiza, ejecuta, y mejora procesos de negocio. Los procesos de negocio

están directamente relacionados con las actividades de la empresa, y actúan como un agente para

invocar varias aplicaciones. Con respecto a estas propiedades de los procesos de negocio, el

sistema de BPM tiene un papel esencial. En otras palabras, BPM no sólo puede dirigir procesos

de negocio sistemáticamente manteniendo la funcionalidad original, sino que también puede



6

desarrollar nuevas aplicaciones, permitiendo que la solución sea flexible a los cambios de

procesos.

Tradicionalmente la modelación de procesos de negocio se ha utilizado en la industria para

obtener una visión global de los procesos mediante actividades de soporte, control y

monitorización y para otras actividades como el procesado automático de documentos.

1.2 Lenguajes de modelado.

Los lenguajes utilizados para modelar procesos de negocios generan “los modelos que

especifican las actividades que se realizan dentro de una organización con sus relaciones”

(Weske, 2007).

Algunos de estos lenguajes son:

BPMN( del ingles Business Process Management Notation)

UML(del ingles Unifiqued Modeling Lenguage)

IDEF(del ingles Definition Languages)

Estos lenguajes fueron los seleccionados por (O’Farril 2012) para su estudio de selección de

variables que pueden influir directamente en el cálculo de la complejidad de un proceso de

negocio, de ahí que este estudio centre su atención en dichos lenguajes.

1.2.1 BPMN

Según (Calderón, 2010) BPMN es una notación gráfica que muestra los pasos de un proceso de

negocio. La notación ha sido diseñada específicamente para coordinar la secuencia de los

procesos y los mensajes que fluyen entre los participantes del mismo, con un conjunto de

actividades relacionadas.

Dentro de un modelo BPMN existe un conjunto de elementos gráficos que permiten representar

un proceso de negocio y hacen fácil el entendimiento del proceso, tanto para usuarios del

negocio como para desarrolladores.

Los elementos de BPMN se pueden clasificar en cuatro categorías básicas (OMG, 2011):

Objetos de Flujo: Eventos, Actividades, Compuertas (acrónimo del inglés Gateway)

Objetos de Conexión: Flujo de Secuencia, Flujo de Mensajes, Asociación

Canales: Piscina, carriles (acrónimo del inglés Pool, Lane)



7

Artefactos: Objetos de Datos, Grupos, Anotaciones

Desde la aparición de BPMN, y mucho más desde la absorción de BPMI por parte de la OMG, la

notación BPMN ha tenido un éxito notable y como consecuencia de este éxito han ido

apareciendo gran cantidad de herramientas que dan soporte a esta especificación.

Las que según la propia OMG implementan la especificación son las siguientes:

1- Appian Enterprise 5 Business Process Management Suite

2- aXway: Process Manager

3- BizAgi,

4- BOC Information Systems: ADONIS

5- Borland R Together R Products: Together Architect R 2006 and Together

Designer R

6- Casewise: Corporate Modeler

Se selecciona BizAgi por ser una herramienta libre para el modelado de procesos de negocio y

porque en el momento que se desarrolla la investigación el resto de las herramientas no se pudo

encontrar o se hace necesaria la licencia para su instalación. También existen herramientas las

cuales han sido desarrolladas para mostrar y entender el flujo del proceso de negocio en

determinada esfera de la vida real

BizAgi es capaz de representar más de 40 patrones de workflow de procesos de negocio con una

gran variedad de símbolos para la representación del lenguaje natural.

Uno de los elementos fundamentales a tener en cuenta el formato de salida con que se puede

exportar los modelos en dicha herramienta.

BizAgi permite exportar a un formato interpretable , posteriormente se mostrará cómo se

presentan las variables para el cálculo de complejidad de un procesos de negocio , además de

que es soportado por otras notaciones que lo referencian o sus modelos pueden ser utilizados

como punto de partida.



8

1.2.2 UML

UML (acrónimo del inglés, Unified Modeling Language) es el lenguaje de modelación de

sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (del

inglés Object Management Group).

Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. Ofrece un

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

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

lenguajes de programación, esquemas de bases de datos y componentes reutilizables.

UML modela los procesos de negocio a partir de diagramas de actividad, los cuales en la versión

actual están compuestos por una serie de elementos fundamentales, los nodos, que se pueden

clasificar en:

Nodos de Acción: Realizan operaciones con los datos que reciben y pasan el control y

datos a otras acciones.

Nodos de Control: Distribuyen el control de la ejecución y los tokens a lo largo del

diagrama.

Nodos Objeto: Contienen datos de manera temporal a la espera de mover estos datos a lo

largo del diagrama.

Además de estos nodos los diagramas de actividad disponen de otros elementos y conceptos

como:

Flujos

Particiones

Regiones de Expansión

Excepciones

Regiones de Actividad Interrumpibles

Streaming

En relación a los diagramas de actividad se debe tener en cuenta que:

Existen muchas herramientas para trabajar con ellos.

Existe gran cantidad de procesos de negocio que están modelados usando esta notación.



9

Los desarrolladores tienen gran experiencia utilizando tanto UML como sus Diagramas

de Actividad.

Desde la creación de UML han surgido innumerables herramientas. Las que según la propia

OMG soportan los Diagramas de Actividad que nos ocupan quedan recogidas en (OMG, 2009) y

algunas de ellas son:

1- Magic Draw

2- Power Designer

3- Rational Rose

4- Visual Paradigm

Como herramienta a analizar se seleccionó Visual Paradigm. Es una herramienta de gran

utilidad para el modelado de procesos de negocio a partir de los diagramas de actividad, aunque

su objetivo fundamental es generar artefactos de brinden un seguimiento total a todo el procesos

de desarrollo del software, esta herramienta posee una gran expresividad con una variedad de

símbolos con lo cual se asegura la representación concreta de procesos de negocio de la vida

cotidiana.

1.2.3 IDEF

IDEF (ICAM Definition Languages, siendo ICAM Integrated-Aided Manufactoring) es el

resultado de una iniciativa de la United States Air Force cuyo objetivo es modelar, gestionar y

mejorar procesos de negocio. Fue un proyecto iniciado en los años 70, años en los que convivían

multitud de especificaciones y métodos incompatibles entre sí. Paulatinamente han surgido y

evolucionado diversos métodos para distintos aspectos relacionados la gestión y modelación de

procesos de negocio:

IDEF0 para el modelado de procesos dentro de una organización.

IDEF3 para la captura de descripciones de procesos.

IDEF0 “es una metodología, basada en SADT (Structured Análisis and Design Technique) que

pretende representar de manera estructurada y jerárquica las actividades que conforman un



10

sistema o empresa y los objetos o datos que soportan la interacción de esas actividades“(Germán,

2003).

IDEF0 permite describir el qué hacer, brindando una visión estratégica. Está pensado para la

comunicación con usuarios no técnicos por lo cual se aplica principalmente a:

Comunicar reglas y procesos de negocio.

Obtener una visión estratégica de un proceso.

Facilitar un análisis para identificar puntos de mejora.

IDEF3.

IDEF3 permite documentar procesos para su estandarización o para utilizarlos como guía para

nuevos integrantes del equipo para así reducir la curva de aprendizaje. Asimismo posibilita la

captura de la secuencia temporal y la lógica de decisión que afecta al proceso.IDEF3 sirve como

herramienta para analizar procesos existentes y para diseñar y probar nuevos procesos antes de

iniciar cambios reales que pueden ser muy costosos.

Lo ideal, al menos para afrontar un desarrollo de software como proceso de negocio seria usar de

manera conjunta IDEF0 e IDEF3 representando los detalles de implantación así como lo

procesos al nivel apropiado en cada momento. En cuanto a su expresividad, IDEF0 e IDEF3 dan

soporte a casi todos los patrones de workflow, tal y como podemos apreciar en (Korhnerr,

2006).

Algunas de las herramientas que soportan la notación IDEF se citan a continuación:

1- Keeps

2- BPWin

3- Design IDEF

4- IDEF Tools

5- Popkins Systems Architect

6- Workflow Modeler



11

Para esta notación el presente trabajo nos selecciona herramienta candidata a analizar ya que por

lo general no son libres y su obtención se hace difícil. Aunque en algunos casos se logró

descargar con éxito la herramienta presentaban dificultades para ser instaladas.

1.3 Selección de la herramienta a utilizar

Como resultado del epígrafe anterior se seleccionaron como herramientas de modelado de

procesos de negocio BizAgi y Visual Paradigm. Es válido destacar que una de las bondades que

brinda esta última es la exportación de sus modelos a modelos compatibles con la herramienta

BizAgi lo cual permite la integración entre ambas.

Teniendo en cuenta los formatos de salida que brindan, se realiza a continuación un resumen de

las coincidencias o no de las herramienta con la finalidad de hallar un formato de salida común a

interpretar de manera que cubra tanto los modelos realizados con BizAgi y Visual Paradigm.

Formatos de salida BizAgi Visual Paradigm

XPDL Si No

Imagen si Si

XMI no Si

XML no Si

PDF si no

Word si no

Tabla 1: Formatos de salida de las herramientas BizAgi y Visual Paradigm.

Es notable que no existen formatos comunes en las dos herramientas que permitan realizar una

misma codificación para por lo cual la decisión del formato estará ligada estrechamente a lo

expresado anteriormente respecto a cómo se realiza la integración de una herramienta a otra.

El formato seleccionado para la interpretación fue XPDL. Esto brindará la posibilidad de cubrir

los modelos de la base de casos que estén realizados tanto en BPMN como en UML ya que este

último permite, como se mencionó antes, exportar sus modelos a la primera.



12

1.4 Formato de salida XPDL de la herramienta BizAgi.

XPDL es una notación para definir e intercambiar modelos de procesos de negocio. A su vez,

XPDL puede ser considerado como la notación textual de BPMN, o al revés, BPMN la notación

gráfica de XPDL. La versión más reciente, XPDL 2.0, fue actualizada para reflejar todos y cada

uno de los elementos de BPMN que en otras versiones presentaban problemas de compatibilidad.

Por lo tanto XPDL y BPMN son un binomio a tener en cuenta dentro de campo del modelado de

procesos de negocio, un campo que cada vez está adquiriendo más importancia.

Por lo tanto la idea adecuada sería:

- Usar BPMN para modelar de manera gráfica los modelos de procesos de negocio (lo cual

es más sencillo tanto para los ingenieros como para los clientes).

- XPDL para guardar los modelos e intercambiarlos entre las diferentes aplicaciones.

La interpretación, objeto del presente trabajo, estará basada en el conjunto de variables

resultantes de (Lianny 2012) para calcular la complejidad de procesos de negocio.

Estas variables fueron escogidas a partir de aquellos elementos que eran comunes en las tres

notaciones anteriormente descritas, estos elementos fueron:

Sujetos de negocio.

Tareas

Mecanismos de control

Entidades

Cantidad de dependencias

Cantidad de fronteras de negocios

A partir de estos elementos comunes se definieron como variables:

1) Número de tareas (NT)

2) Número de sujetos (NS)

3) Número de entidades diferentes (NE)

4) Número máximo de dependencias por tareas (NMD)

5) Número de fronteras del negocio (NFN)

6) Número de mecanismos de control (NMC)



13

Estas variables se miden a partir de la cantidad de elementos representados de cada tipo que se

relaciona en la definición de la variable. Por ejemplo, si en el proceso hay representadas 6

tareas entonces NT = 6, si existen en todo el flujo del proceso 4 entidades pero una de las

entidades se encuentra representada en más de una ocasión, solo se contará una vez. En el caso

del NMD, después de analizar el número de entradas por cada una de las tareas representadas,

para aquella tarea que mayor número de entradas tenga, su número de entradas será el valor del

NMD.

Una vez mencionadas las variables que determinan el costo computacional de un proceso de

negocio según (O´farrill, 2012) se presenta la correspondencia de estas con el código generado

en XPDL que facilita la interpretación.

Variables XPDL

Número de Tareas Activity

Número de Mecanismos De Control Route

Número Máximo de Dependencias Transition

Número de Fronteras del Negocio WorflowProcess

Número de Sujetos del Negocio Lane

Número de Entidades DataObject

Tabla 2: Correspondencia Variables Determinadas - Codificación XPDL

1.5 Herramientas para el desarrollo de la aplicación.

Durante el proceso de desarrollo del software deben tomarse decisiones de implementación como

la plataforma de desarrollo y el lenguaje de programación para poder dar cumplimiento de

manera efectiva a los objetivos planteados. Para llevar a cabo dicha tarea se seleccionó como

lenguaje de programación Java.

Este es un lenguaje de alto nivel orientado a Objetos el cual ofrece amplias posibilidades para el

desarrollo de aplicaciones. Existen un conjunto de Entornos de Desarrollo Integrado (IDE, de sus

siglas en inglés) que permiten el desarrollo de proyectos en Java.



14

El IDE NetBeans fue el seleccionado como ambiente de programación con jdk 1.7.0. Es un IDE

de código abierto y una plataforma de aplicación, la cual puede ser usada como una estructura de

soporte general (framework) para compilar cualquier tipo de aplicación.

JUnit para el desarrollo de las pruebas al código. Constituye un conjunto de bibliotecas creadas

por Erich Gamma y Kent Beck utilizadas en programación para hacer pruebas unitarias de

aplicaciones Java. JUnit es también un medio de controlar las pruebas de regresión, necesarias

cuando una parte del código ha sido modificado y se desea ver que el nuevo código cumple con

los requerimientos anteriores y que no se ha alterado su funcionalidad después de la nueva

modificación.

VisualParadigm para la modelación de todo el proceso de desarrollo del software y UML como

lenguaje de modelado que soporta dicha herramienta.

1.6 Conclusiones parciales

El estudio de las notaciones definidas en (O´farrill, 2012) y las herramientas que soportan cada

una de estas permitió la selección del formato de salida XPDL como archivo a interpretar en la

aplicación.

Esta selección hará posible la interpretación de modelos realizados utilizando tanto UML como

BPMN debido a la integración que brinda Visual Paradigm al permitir la exportación de sus

modelos a la herramienta BizAgi.

https://netbeans.org/features/index.html

https://netbeans.org/features/index.html

https://netbeans.org/features/platform/index.html

http://es.wikipedia.org/wiki/Erich_Gamma

http://es.wikipedia.org/wiki/Kent_Beck

http://es.wikipedia.org/wiki/Programaci%C3%B3n

http://es.wikipedia.org/wiki/Prueba_unitaria

http://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Java

http://es.wikipedia.org/wiki/Pruebas_de_regresi%C3%B3n

Capítulo 2: Descripción de la Propuesta de Solución

15

Capítulo 2.

Descripción de la Propuesta de Solución


16

En este capítulo se transita por todo el proceso de desarrollo de la solución propuesta, el

modelado del negocio y sistema detallando las principales funcionalidades que debe cumplir la

aplicación. Asimismo se destaca el proceso de interpretación de los archivos XPDL a fin de

obtener los datos necesario para calcular la complejidad de un proceso de negocio.

2.1 Modelado del negocio.

El proceso de recopilación de datos en la investigación de (O´farrill, 2012) se realizó de forma

manual, identificándose funcionalidades como el conteo, modelo por modelo, de la cantidad de

elementos que correspondían a cada variables seleccionada. Una vez realizada esta acción se

procedía a copiar estos datos para su posterior procesamiento.

Figura 1: Diagrama de Casos de Uso del Negocio.

2.2 Requisitos

Requisitos funcionales derivados del análisis anterior:

RF1: Leer un archivo de entrada en formato XPDL


17

RF2: Interpretar un archivo de entrada en formato XPDL

RF3: Mostrar la información del archivo interpretado

RF4: Almacenar o guardar la información del archivo interpretado en un archivo de extensión

.xls

RF5: Mostrar ayuda al usuario

Requisitos no funcionales:

RNF1: Software JRE 1.7 o superior

RNF2: Hardware (configuración mínima)

- 128 megabytes de memoria RAM

- 7 megabytes de espacio en disco para el código fuente

- 1 megabytes de espacio en disco para el ejecutable de la instalación

- 1 megabyte extra para guardar los archivos

RNF3: Sistema operativo Windows

RNF4: Fácil de usar

2.3 Diagrama de casos de uso del sistema.

El sistema va a ser utilizado por un especialista que necesite de la interpretación de formatos de

archivo .xpdl. Se declara entonces un actor Especialista que desarrolla las funcionalidades que

aparecen en el diagrama de casos de uso siguiente:


18

Figura 2: Diagrama de casos de Uso del sistema

Como Caso de Uso significativo se tiene Interpretar Variables, dedicado a la traducción del

archivo XPDL a una tabla con los datos correspondientes a cada una de las variables. A

continuación se muestra la descripción detallada de esta funcionalidad.

2.4 Especificación del Caso de Uso “Interpretar variables”

Principal

Caso de Uso Interpretar Variables

Actor Especialista

Breve

Descripción

El especialista da clic en la opción “Interpretar variables” del menú “Archivo”. Se

muestran los resultados de la interpretación junto a la complejidad computacional de

cada proceso seleccionado a interpretar

Precondicio

nes

Cargar al menos un archivo

Post-

condiciones

-


19

(A)


20

(B-1)


21

(B-2)


22

(C)

Acción del Actor Respuesta del sistema

1- El Especialista da clic

en la opción “Interpretar

Variables” .Como se

muestra en la imagen

(B-1) o (B-2)

2- El sistema analiza el fichero con extensión

.xpdl y muestra los resultados de cada una de las

Variables (C).

Tabla 3: Especificación del Caso de Uso “Interpretar variables”

2.5 Diagrama de secuencia del caso de uso Interpretar Variables.

Figura 3: Diagrama de secuencia del caso de uso Interpretar Variables.


23

2.6 Diagrama de clases del diseño.

Figura 4: Diagrama de Clases del Diseño.


24

Un aspecto interesante de este diagrama de clases del diseño es la creación de la jerarquía de

archivos que se presenta, esto le brinda al sistema adaptabilidad en el momento de incluir nuevos

tipos de archivo que surjan como resultado de investigaciones futuras. Bastará solo crear una

nueva clase con el nombre del archivo que redefina el método traducirArchivo presente en el

clase Archivo, sin que esto genere cambios en el código de la aplicación.

2.7 Diagrama de componente.

Un Diagrama de Componente es, como su nombre lo indica, un esquema o diagrama que

muestra las interacciones y relaciones de los componentes de un modelo. Entendiéndose como

componente a una clase de uso específico, que puede ser implementada desde un entorno de

desarrollo, ya sea de código binario, fuente o ejecutable; dichos componentes poseen tipo, que

indican si pueden ser útiles en tiempo de compilación, enlace y ejecución. Este tipo de diagrama

se representa mediante componentes unidos mediante relaciones de dependencia (generalmente

de compilación) (Web, 2010, En línea).

Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos1 que

conformarán un sistema. Un diagrama de Componentes tiene un nivel más alto de abstracción

que un diagrama de clase, usualmente un componente se implementa por una o más clases en

tiempo de ejecución. Estos son bloques de construcción, como eventualmente un componente

puede comprender una gran porción de un sistema.


25

Figura 5: Diagrama de Componentes.

2.8 Interpretación de los archivos XPDL.

El proceso de interpretación de los archivos XPDL se realizó a partir de los elementos que

componen un diagrama de procesos de negocio y cómo tributan estos elementos a cada variable.

A continuación se presenta un modelo del proceso de negocio “Procedimiento de Gestión y

Aprobación de Cursos y Entrenamientos” del Sistema para Gestión de Postgrado en la

Universidad Central “Marta Abreu” de Las Villas.


26

Figura 6: PN Gestión y Aprobación de Cursos y Entrenamientos

Las variables y sus Equivalentes en XPDL.

El modelo presentado anteriormente fue exportado al formato XPDL. Un análisis del mismo, ha

permitido asociar las variables del cálculo de la complejidad computacional, con elementos

significativos en esta forma de salida. Esta asociación se presenta a continuación:

1. Número de eventos (Eventos): representa la cantidad de elementos de inicio, fin u otros

(Anexo 1 Tabla A) que existen en el proceso de negocio modelado. Su representación es

<Event >, este nueva variable se define para mostrar información adicional, y es

utilizada para el caculo de la variable NT la cual se muestra a continuación.

2. Número de mecanismos de control (NMC): representa la cantidad de elementos

(decisiones) empleados para dirigir y controlar el flujo de las actividades. Se identifica

como <Route *>.

3. Número de tareas (NT): representa la cantidad de actividades dentro del proceso de

negocio. Su identificación es <Activity *>.

4. Número de sujetos (NS): es la cantidad de participantes (roles), conocido como calles

lanes y equivalente a <Lane *>.


27

5. Número de entidades diferentes (NE): cantidad de entidades (Data Object, objetos de

datos), es equivalente a <DataObject * >.

6. Número máximo de dependencias por tareas (NMD): el máximo número de entradas

necesarias para realizar una actividad. Se identifica por <Transition *>.

7. Número de fronteras del negocio (NF): la cantidad de instituciones involucradas en el

proceso, conocido como Pool y representado como <WorflowProcess *>.

Se considera a continuación, una explicación más detallada de cada variable, a partir de

segmentos del formato de salida XPDL obtenido del proceso de negocio objeto de estudio.

2.7.1 Variable Eventos: Número de Eventos .

Las actividades o tareas <Activity *> que poseen como su hijo más inmediato la etiqueta

<Event >, representan el inicio o fin de un proceso de negocio. El inicio de un proceso de

negocio no tiene por qué ser único, esto ocurre en dependencia del proceso a modelar, de igual

manera ocurre con las actividades de fin del proceso, donde al menos debe existir un fin.

Para la variable anteriormente descrita, una parte del modelado expresada en el formato

interpretable XPDL es la siguiente:

Figura 7: Formato XPDL que representa Eventos.

La variable Eventos puede cuantificarse contando el número de etiquetas del tipo <Event>. Para

el ejemplo que se muestra en la Figura 7 se tiene que el valor de la variable Eventos es 2.


28

2.7.2 Variable NMC: Número de Mecanismos de Control

El número de mecanismos de control, identificado por <Route *> y representado por la variable

NMC constituyen elementos del modelado que se utilizan para controlar la divergencia y la

convergencia del flujo.

Para la variable descrita, una parte del modelado expresada en el formato interpretable XPDL es

la siguiente:

Figura 8 : Formato XPDL Número de Mecanismos de Control.

Como se muestra en la figura anterior, la etiqueta <Activity*> seguida por su hijo más

inmediato <Route *> identifica a la variable NMC, de manera que puede cuantificarse contando

el número de etiquetas de este tipo. Para el ejemplo que se muestra en la Figura 8 se tiene que el

valor de la variable NMC es 2.


29

2.7.3 Variable NT: Número de Tareas

Las actividades o tareas <Activity *> representan el trabajo que es ejecutado dentro de un

proceso de negocio. Las actividades pueden ser compuestas o no, de manera que pueden

representarse como subprocesos o tareas simples.



Figura 9: Formato XPDL que representa Número de Tareas.

Como se muestra en la figura anterior la etiqueta <Activity *> seguido por su hijo más

inmediato <Implementation *> identifica a la variable NT, de manera que puede cuantificarse

contando el número de etiquetas de este tipo. Para el ejemplo que se muestra en la Figura 9 se

tiene que el valor de la variable NT es 9. El Id de cada actividad es almacenado en una tabla

hash que posteriormente es utilizada en el cálculo de otras variables.


30

2.7.4 Variable NMD: Número Máximo de Dependencias

El número máximo de dependencias, que se identifica por la etiqueta <Transition *>,

representado por la variable NMD son los elementos usados para conectar dos objetos del flujo

dentro de un proceso. Dentro de los ejemplos se utilizan las líneas de secuencia, que conectan los

objetos de flujo, y las asociaciones, que son las líneas punteadas que permiten asociar

anotaciones dentro de algunos flujos. Esta variable está sujeta a la mayor cantidad de líneas de

secuencia que fluya hacia una actividad determinada.



Figura 10: Formato XPDL Número Máximo de Dependencias.

Como se muestra en la figura anterior, la etiqueta <Transition *> identifica a la variable

NMD, de manera que puede cuantificarse contando el número de etiquetas de este tipo. Sin

embargo esta cuenta total no representa exactamente el número de dependencias ya que existen

líneas de secuencia que llegan a mecanismos de control. Por esta razón se hace un trabajo

previo donde de cada etiqueta <Activity *> que representa a la variable NT se almacena su

atributo único de tipo Id. Por tanto, bastaría en la etiqueta <Transition *> ir al atributo To=”

”, que refiere a una actividad en específico. Luego, se compara este Id con el almacenado y si

coincide se incrementa NMD, comprobándose al final cuál de todas es la más referenciada.

Para el ejemplo que se muestra en la Figura 10 se tiene que el valor de la variable NMD es 2.


31

2.7.5 Variable NE: Número Entidades

La variable Número de entidades del proceso de negocio, representada por la etiqueta <Artifact

*> es identificada por los artefactos que son usados para proveer información adicional sobre el

proceso.

Existen artefactos tales como:

1. Objetos de Datos

2. Grupos

3. Anotaciones

Se centra especial atención a los objetos de datos, que representan en sí a las entidades.

Figura 11: Formato XPDL Número Entidades.

Como se muestra en la figura anterior, la etiqueta <Artifact *> seguida por su hijo más

inmediato <DataObject *> identifica a la variable NE, de manera que puede cuantificarse

contando el número de etiquetas de este tipo. Para el ejemplo que se muestra en la Figura 11 se

tiene que el valor de la variable NE es 1.

2.7.6 Variable NF: Número de Fronteras

El número de fronteras del negocio (NF) es identificado por la etiqueta <WorkflowProcess *>.


32

Figura 12:Formato XPDL Número de Fronteras.

Como se muestra en la figura anterior la etiqueta <WorflowProcess *> representa la variable

NF. Para el ejemplo toma valor 0 debido a que las fronteras son el resultado de la cantidad de

<WorkflowProcess> -1.

2.7.7 Variable NS: Número Sujetos del Negocio

El Número de Sujetos del negocio (etiqueta <Lanes *>) representa a la variable NS. Los Carriles

(Lanes) son sub-particiones para los objetos dentro de un proceso de negocio. A menudo

representan roles organizacionales (ej. Departamento, Colectivo de Disciplina), pero pueden

representar cualquier característica deseada del proceso (roles internos, sistemas, departamentos

internos u otros).

La representación de esta variable para el proceso de Gestión Aprobación de Cursos y

Entrenamiento en XPDL es la siguiente:

Figura 13: Formato XPDL Número de Sujetos del Negocio


33

Como se muestra en la figura anterior, el conteo de la etiqueta <Lane *> da como resultado la

variable NS. Pero hay que tener en cuenta la cantidad de etiquetas <Pool *> que existen, pues si

alguna de ellas solo tiene representado un sujeto, no aparecerá en forma de etiqueta <Lane *>,

entonces se buscará el hijo inmediato de la etiqueta <Pool *> y si no posee, el NS es igual 1.

Luego de hacer este análisis el valor de la variable NS en el ejemplo que se sigue es 2.

2.8 Algoritmo de interpretación.

Se expone a continuación la idea general del algoritmo de interpretación que permite, a partir de

uno o varios archivos de entrada en formato .xpdl, obtener resultados de las variables definidas.

Paso 1: Leer archivo en formato .xpdl

Paso 2: Mientras que no se llegue a fin del archivo

2.1 Inicializar todas las variables

Eventos,NT,NE,NS,NMD,NMC=0;

NF=-1;

2.2 Calcular Número Eventos, NT, NMC;

Buscar los hijos WorkflowProcesses;

Buscar los hijos es WorkflowProcess;

Buscar los hijos Activities;

Buscar los hijos Activity;

Si el hijo Event

incrementar Eventos +1;

Si el hijo Implementation

incrementar Implementation;

Else

incrementar NMC;

2.3 Calcular Número de Sujetos NS

Buscar los hijos de Pools;


34

Buscar los hijos de Pool;

Buscar los hijos de Lanes;

Buscar los hijos de Lane;

incrementar NS +1;

2.4 Calcular Número de Fonteras

Buscar los hijos de WorkflowProcesses;

Buscar los hijos de WorkflowProcess;

Incrementar NF +1;

2.5 Calcular Número de Entidades

Buscar los hijos de Artifact;

Buscar los hijos de DataObject;

incrementar NE +1;

2.5 Calcular Número de Máximo de Dependencias

Buscar los hijos de WorkflowProcesses;

Buscar los hijos de WorkflowProcess;

Buscar los hijos de Transition;

NMD = actividad a la cuál lleguen mayor número

de transiciones;

Paso 3: Guardar archivo o ir al Paso 1


35

2.9 Conclusiones parciales del capítulo.

La descripción del proceso de desarrollo a partir de los diagramas presentados y la especificación

de los algoritmos utilizados permitió la implementación de la herramienta “INTERVAR Sistema

para la interpretación de archivos XPDL correspondientes a procesos de negocio modelados con

notación gráfica BPMN”.

Capítulo 3: Validación de la Propuesta de Solución.

36

Capítulo 3.

Validación de la Propuesta de Solución.


37

La implementación en el proceso de desarrollo de un software adquiere gran importancia debido

a que le da funcionalidad al producto que se desarrolla. Además, son importantes las pruebas

que se le realizan al mismo para validar su correcto funcionamiento. El capítulo abarca fase de

prueba de la aplicación. Se describen las pruebas realizadas a la aplicación con el objetivo de

verificar si se cumplieron los requerimientos de la misma.

3.1 Diseño de los casos de prueba

Para realizar la validación del sistema se analizarán dos tipos de pruebas, las pruebas de caja

blanca y las pruebas de caja negra.

Pruebas de caja blanca.

Son las pruebas que se le realizan directamente al código de la aplicación con el fin de encontrar

errores en la implementación. Estas se llevaron a cabo en la presente investigación con la

utilización de la librería JUnit.

Prueba de Caja Negra.

Las pruebas de caja negra también conocidas con sus varios nombres como pruebas funcionales,

pruebas de caja opaca, pruebas de entrada/salida, pruebas inducidas por los datos, son las que no

toman en cuenta el código, no se conoce cómo está estructurado por dentro el programa, solo

verifica las posibles entradas sin necesidad de entender cómo se deben obtener las salidas, donde

se trata de encontrar errores en la interfaz mientras se está usando, el cómo luce, se maneja

(Presman, 2003). Este grupo de pruebas se utilizó para a validación de las funcionalidades del

sistema. Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo

o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese

modulo que atiendan a su especificación.


38

Figura 14: Pruebas de Caja Negra

Según (Presman, 2003) las pruebas de caja negra permiten identificar problemas tales como:

1. Funciones incorrectas o ausentes.

2. Errores de interfaz.

3. Errores en estructuras de datos o en accesos a las Bases de Datos externas.

4. Errores de rendimiento.

5. Errores de inicialización y terminación.

Casos de prueba

Las pruebas de aceptación son creadas sobre la base de la herramienta INTERVAR. El usuario

debe especificar uno o diversos escenarios para comprobar para saber si el software ha sido

correctamente implementado. Los clientes son responsables de verificar que los resultados de

estas pruebas sean correctos.

Casos de Prueba de Aceptación

No de Prueba: 1 Nombre de la Prueba: Cargar Archivo.

Nombre de la persona que realiza la Tarea: Marlon Esquivel Ariz.

Descripción de la Prueba: Se ejecuta la prueba y se verifica que se cargue correctamente el archivo

Condiciones de Ejecución: Ejecutar el Intérprete INTERVAR.

Entrada / Pasos de ejecución: Para realizar esta prueba es necesario que se haya cargado

satisfactoriamente toda la información del archivo bpm con extensión .xpdl. Luego de haber interpretado

los valores de las variables para cálculo de complejidad computacional se verifica que el nombre del

archivo coincida con el cargado

Resultado Esperado: Que se muestre en el siguiente paso el nombre del archivo cargado

Evaluación de la Prueba: Satisfactorio

Tabla 4: Caso de Prueba "Cargar Archivo"


39

Casos de Prueba de Aceptación

No de Prueba: 2 Nombre de la Prueba: Interpretar Variable.

Nombre de la persona que realiza la Tarea: Marlon Esquivel Ariz.

Descripción de la Prueba: Se ejecuta la prueba y se verifica que cada una de las variables obtengan el

valor que le corresponde

Condiciones de Ejecución: Que se haya cargado previamente el archivo .xpdl.

Entrada / Pasos de ejecución: Para realizar prueba es necesario que se haya cargado satisfactoriamente

toda la información del archivo bpm con extensión .xpdl. Luego de haber interpretado los valores de las

variables del cálculo de complejidad computacional se verifica que el cada variable tenga el valor que le

corresponde es decir que el proceso modelado en BPMN coincida cada una de las variables con la salida

del Software.

Resultado Esperado: Que se muestre el valor de interpretación de las variables correctamente

Evaluación de la Prueba: Satisfactorio

Tabla 5: Caso de Prueba "Interpretar Archivo"

Con este caso de prueba conlleva una serie de proceso a probar para comprobar que la

herramienta funcione correctamente y determine el valor real de las variables que influyen en

el cálculo de la complejidad de los procesos modelados en cualquiera de las metodologías

escogidas.

Recolección de datos a probar.

Es necesario partiendo de las variables identificadas, recolectar un conjunto de procesos de

negocio para extraer el valor de las variables con la ayuda de la herramienta INTERVAR. Para

esto se definen un conjunto de pasos:

1. Recolectar procesos de negocio representados.

2. Crear de forma concisa los procesos de negocio que se usaran en la base de casos de

pruebas para validar la propia herramienta

3. Obtener los valores de las variables para el cálculo de la complejidad computacional de

la base de casos de pruebas a través de la herramienta INTERVAR y se comprará con

los valores obtenidos del conteo manual de la representación del proceso de negocio

modelado con software BizAgi.

Para la construcción de una base de casos de prueba se necesita el conjunto de datos que la

conformen, esos datos deben estar en correspondencia con las variables que se instancian. En el


40

caso de la presente investigación, las variables son las definidas a partir de la representación de

un proceso.

Se tiene un total de 19 procesos de negocios modelados con la notación BPMN. La obtención de

los procesos fue diversa. Para llenar la base de casos prueba se revisaron cada uno de los

procesos, y se midió el valor de cada una de las variables. Después de efectuar los pasos

planteados, se conformó la base de casos prueba de los procesos modelados quedando como

se muestra a continuación:

Nro.

NT-

Número

de

Tareas

NMC-

Mecanismos

de Control

NF-

Número

de

Fronteras

NS-

Número

de

Sujetos

NE-

Número

de

Entidades

NMD-

Número

Máximo de

Dependencias

Eventos

1 4 2 1 2 1 2 3

2 5 3 2 1 0 2 2

3 2 1 1 1 3 2 1

4 3 6 1 2 1 2 6

5 6 2 1 2 4 3 4

6 9 5 2 2 4 2 2

7 12 4 1 3 1 3 2


41

Tabla 6: Base de casos para comprobar el conteo automático de los elementos correspondientes a las variables.

Las pruebas realizados en base a la carga y ejecución de la herramienta INTERVAR sobre

la base de casos de pruebas resultó satisfactoria obteniéndose los valores correctos de cada

una de las variables de los procesos de negocio modelados en BPMN y UML.

3.2 Conclusiones parciales del capítulo.

El correcto diseño de los casos de prueba y la utilización de estos comprobó cada una de las

funcionalidades del sistema, arrojando resultados satisfactorios en su aplicación.

8 10 3 2 1 2 5 1

9 6 2 2 3 2 3 2

10 6 3 1 2 0 2 3

11 9 3 0 1 2 3 4

12 11 6 3 2 5 5 2

13 5 1 2 3 4 3 2

14 13 4 6 7 11 9 4

15 12 3 1 1 7 5 3

16 9 1 1 2 9 5 3

17 9 6 1 8 3 6 2

18 9 3 2 2 0 2 1

19 11 5 2 8 0 2 2

Conclusiones

42

Conclusiones

El estudio de las notaciones definidas en (O´farrill, 2012) y las herramientas que soportan cada

una de estas permitió la selección del formato de salida XPDL como archivo a interpretar en la

aplicación. Lo cual hizo posible la interpretación de modelos realizados utilizando tanto UML

como BPMN debido a la integración que brinda Visual Paradigm al permitir la exportación de

sus modelos a la herramienta BizAgi.

La descripción del proceso de desarrollo a partir de los diagramas presentados y la especificación

de los algoritmos utilizados permitió la implementación de la herramienta “INTERVAR Sistema

para la interpretación de archivos XPDL correspondientes a procesos de negocio modelados con

notación gráfica BPMN”.

El correcto diseño de los casos de prueba y la utilización de estos comprobó cada una de las

funcionalidades del sistema, arrojando resultados satisfactorios en su aplicación.

Recomendaciones

43

Recomendaciones

Continuar el estudio de formatos de salida que permitan interpretar diagramas de procesos de

negocio modelados con notación gráfica.

Incluir estos nuevos formatos de salida a la aplicación.

Referencias Bibliográficas

44



45

Anexos

Anexo #1 Tabla del lenguaje de proceso BPMN

Tabla A. Eventos de inicio para subprocesos.

Tipo de Evento Interruptor No-Interruptor

Mensaje

Tiempo

Intensificación

(Escalation)

Error

Compensación

Condicional

Señal

Múltiple

Múltiple Paralelo

Mensaje


46

Tiempo

Intensificación

(Escalation)

Error

Compensación

Cancelar

Condicional

Señal

trabajo de diploma intervar

Documents