• No se han encontrado resultados

INTERVAR Sistema para la interpretación de archivos XPDL correspondientes a procesos de negocio modelados con notación gráfica BPMN

N/A
N/A
Protected

Academic year: 2020

Share "INTERVAR Sistema para la interpretación de archivos XPDL correspondientes a procesos de negocio modelados con notación gráfica BPMN"

Copied!
58
0
0

Texto completo

(1)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”.

(2) 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____________.

(3) Pensamiento. Pensamiento Ser culto es único modo de ser libre. José M. Pérez B..

(4) Agradecimientos. Agradecimientos. Agradezco a todos los que de una forma u otra ayudaron a la realización de este trabajo..

(5) Agradecimientos.

(6) Dedicatoria. Dedicatoria A mi mamá, mi hermano, mi abuela a mis familiares y a todos mis amigos..

(7) Resumen. 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.. vii.

(8) Abstract. 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.. viii.

(9) Índice 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. ix.

(10) Índice 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. x.

(11) Índice. 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. xi.

(12) Índice. 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. xii.

(13) Introducción. 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.. 1.

(14) Introducción 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. 2.

(15) Introducción 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.. 3.

(16) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. Capítulo 1. LENGUAJES DE MODELADO DE PROCESOS DE NEGOCIO.SELECCIÓN DE FORMATOS DE SALIDA A INTERPRETAR.. 4.

(17) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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 5.

(18) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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) 6.

(19) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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.. 7.

(20) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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.. 8.

(21) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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. 9.

(22) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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. 10.

(23) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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.. 11.

(24) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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).. La. XPDL para guardar los modelos e intercambiarlos entre las diferentes aplicaciones. 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). 12.

(25) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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. 13.

(26) Capítulo 1: Lenguajes de modelado de procesos de negocio. Selección de formatos de salida a interpretar.. 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.. 14.

(27) Capítulo 2: Descripción de la Propuesta de Solución. Capítulo 2. Descripción de la Propuesta de Solución. 15.

(28) Capítulo 2: Descripción de la Propuesta de Solución. 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 16.

(29) Capítulo 2: Descripción de la Propuesta de Solución. 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:. 17.

(30) Capítulo 2: Descripción de la Propuesta de Solución. 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. Postcondiciones. -. 18.

(31) Capítulo 2: Descripción de la Propuesta de Solución. (A). 19.

(32) Capítulo 2: Descripción de la Propuesta de Solución. (B-1). 20.

(33) Capítulo 2: Descripción de la Propuesta de Solución. (B-2). 21.

(34) Capítulo 2: Descripción de la Propuesta de Solución. (C). Acción del Actor. Respuesta del sistema. 1- El Especialista da clic. 2- El sistema analiza el fichero con extensión. en la opción “Interpretar Variables” .Como se muestra en la imagen (B-1) o (B-2). .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.. 22.

(35) Capítulo 2: Descripción de la Propuesta de Solución. 2.6 Diagrama de clases del diseño.. Figura 4: Diagrama de Clases del Diseño.. 23.

(36) Capítulo 2: Descripción de la Propuesta de Solución. 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.. 24.

(37) Capítulo 2: Descripción de la Propuesta de Solución. 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.. 25.

(38) Capítulo 2: Descripción de la Propuesta de Solución. 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 *>.. 26.

(39) Capítulo 2: Descripción de la Propuesta de Solución. 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.. 27.

(40) Capítulo 2: Descripción de la Propuesta de Solución. 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.. 28.

(41) Capítulo 2: Descripción de la Propuesta de Solución. 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. Para la variable anteriormente descrita, una parte del modelado expresada en el formato interpretable XPDL es la siguiente:. 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.. 29.

(42) Capítulo 2: Descripción de la Propuesta de Solución. 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. Para la variable anteriormente descrita, una parte del modelado expresada en el formato interpretable XPDL es la siguiente:. 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.. 30.

(43) Capítulo 2: Descripción de la Propuesta de Solución. 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 *>.. 31.

(44) Capítulo 2: Descripción de la Propuesta de Solución. 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. 32.

(45) Capítulo 2: Descripción de la Propuesta de Solución. 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 Buscar. hijos. los. Si el. Activities;. hijo. hijos. Activity;. 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; 33.

(46) Capítulo 2: Descripción de la Propuesta de Solución 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 Buscar los hijos. Artifact;. 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. 34.

(47) Capítulo 2: Descripción de la Propuesta de Solución. 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”.. 35.

(48) Capítulo 3: Validación de la Propuesta de Solución.. Capítulo 3. Validación de la Propuesta de Solución.. 36.

(49) Capítulo 3: Validación de la Propuesta de Solución.. 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.. 37.

(50) Capítulo 3: Validación de la Propuesta de Solución.. 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". 38.

(51) Capítulo 3: Validación de la Propuesta de Solución.. 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 39.

(52) Capítulo 3: Validación de la Propuesta de Solución.. 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-. NMC-. NF-. NS-. NE-. NMD-. Número Mecanismos Número. Número Número. Número. de. de. Máximo. de Control. Tareas. de. de. Eventos. de. Fronteras Sujetos. Entidades Dependencias. 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. 40.

(53) Capítulo 3: Validación de la Propuesta de Solució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. 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.. 41.

(54) Conclusiones. 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.. 42.

(55) Recomendaciones. 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.. 43.

(56) Referencias Bibliográficas. Referencias Bibliográficas. 44.

(57) Referencias Bibliográficas. 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. 45.

(58) Referencias Bibliográficas Tiempo. Intensificación (Escalation) Error. Compensación. Cancelar. Condicional. Señal. 46.

(59)

Figure

Tabla 1: Formatos de salida de las herramientas BizAgi y Visual Paradigm.
Tabla 2: Correspondencia Variables Determinadas - Codificación XPDL
Figura 2: Diagrama de casos de Uso del sistema
Figura 3: Diagrama de secuencia del caso de uso Interpretar Variables.
+7

Referencias

Documento similar

Ciaurriz quien, durante su primer arlo de estancia en Loyola 40 , catalogó sus fondos siguiendo la división previa a la que nos hemos referido; y si esta labor fue de

Las manifestaciones musicales y su organización institucional a lo largo de los siglos XVI al XVIII son aspectos poco conocidos de la cultura alicantina. Analizar el alcance y

En este sentido, puede defenderse que, si la Administración está habilitada normativamente para actuar en una determinada materia mediante actuaciones formales, ejerciendo

Proporcione esta nota de seguridad y las copias de la versión para pacientes junto con el documento Preguntas frecuentes sobre contraindicaciones y

[r]

Contraindicaciones: El uso de la mascarilla está contraindicado para los pacientes y los miembros de sus familias, profesionales sanitarios y compañeros de

 Para recibir todos los números de referencia en un solo correo electrónico, es necesario que las solicitudes estén cumplimentadas y sean todos los datos válidos, incluido el

La determinación molecular es esencial para continuar optimizando el abordaje del cáncer de pulmón, por lo que es necesaria su inclusión en la cartera de servicios del Sistema