plataforma para la agrupación de modelos de procesos de

Plataforma para la agrupación de modelos de procesos de negocio bajo el algoritmo de clustering

K-MEANS

Felipe Alejandro Valencia Bacca, [email protected]

Trabajo de Grado presentado para optar al título de Ingeniero de Sistemas

Asesor: Hugo Armando Ordoñez Erazo, Doctor (PhD) en.

Universidad de San Buenaventura Colombia

Facultad de Ingenierías

Ingeniería de Sistemas

Santiago de Cali, Colombia

2017

Bibliotecas Universidad de San Buenaventura

Biblioteca Fray Alberto Montealegre OFM - Bogotá.

Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

Departamento de Biblioteca - Cali.

Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13

Agradecimientos

A Dios en primera instancia por brindarme tantas oportunidades y permitirme estar aquí hoy

después de estos valiosos años de vida universitaria; a mi familia por el apoyo incondicional que

me brindaron, que a pesar de las adversidades siempre estuvieron allí brindándome cada día una

nueva oportunidad, dándome alientos para nunca desfallecer y aconsejándome para ser mejor

cada día. Papá y mamá gracias por ser siempre ser mi ejemplo a seguir, esto es por y para

ustedes.

Daniela Vargas Gómez, gracias por tu apoyo en los momentos más difíciles de mi carrera, valoro

mucho que hayas estado ahí siempre sin importar las condiciones.

Al tutor del trabajo de grado, Hugo Armando Ordóñez Erazo, gracias por compartir todo su

conocimiento, por el tiempo brindado y por la paciencia que tuvo en estos meses, sin su ayuda no

hubiese sido posible. Directora de programa de ingeniería de sistemas, Beatriz Eugenia Grass,

gracias por ser parte siempre de nuestro equipo, gracias por tu apoyo y ayuda en estos años,

¡Gracias por ser nuestra mejor amiga en la Universidad! A todos los docentes de la universidad

que compartieron sus conocimientos y nos ayudaron a ser las excelentes personas que somos hoy

en día. A mis compañeros de clase, gracias por todos los momentos de risa y su apoyo, nunca

olvidare los momentos tan geniales que vivimos juntos, fueron una parte muy importante en todo

este camino de aprendizaje. Mis compañeros de tesis, Dilan Mejía y Santiago Rodríguez, gracias

por el apoyo y por compartir tanto conocimiento. Demás profesores y compañeros de la

universidad, gracias.

Felipe Alejandro Valencia Bacca.

TABLA DE CONTENIDO

RESUMEN ....................................................................................................................................... 9

I. INTRODUCCIÓN ...................................................................................................................... 12

II. PLANTEAMIENTO DEL PROBLEMA .................................................................................. 14

III. JUSTIFICACIÓN ..................................................................................................................... 15

IV. OBJETIVOS ............................................................................................................................ 16

A. Objetivo general .................................................................................................................... 16

B. Objetivos específicos ............................................................................................................. 16

V. MARCO TEÓRICO .................................................................................................................. 17

A. BPM ....................................................................................................................................... 17

B. Importancia de BPM ............................................................................................................. 17

C. BPMN ................................................................................................................................... 18

D. Elementos de BPMN ............................................................................................................ 19

E. Representación de los objetos de flujo de BPMN ................................................................ 20

1) Representación de los objetos de flujo tipo “Evento” de BPMN .................................... 21

2) Representación de los objetos de flujo tipo “Actividad” de BPMN ................................ 22

3) Representación de los objetos de flujo tipo “Puerta de enlace” de BPMN ..................... 24

F. XPDL ..................................................................................................................................... 25

G. Importancia de XPDL ........................................................................................................... 25

H. Estructura básica de XPDL ................................................................................................... 26

I. Clúster .................................................................................................................................... 26

J. Clustering ............................................................................................................................... 27

1) DS1 .................................................................................................................................. 28

2) DS2 .................................................................................................................................. 28

K) Tipos de Clustering ............................................................................................................... 29

L) K-MEANS ............................................................................................................................. 31

M) DBSCAN .............................................................................................................................. 36

VI. METODOLOGÍA .................................................................................................................... 38

A) Modelo de proceso de desarrollo de software. ................................................................... 38

1) Descripción de Iteraciones realizadas y fases realizadas ................................................. 40

B) Educción de Requisitos ...................................................................................................... 43

1) Entrevista ......................................................................................................................... 44

2) Workshop ......................................................................................................................... 45

C) Requisitos Funcionales ....................................................................................................... 45

D) Requisitos No Funcionales .................................................................................................... 48

VII. RESULTADOS ...................................................................................................................... 49

A) Componentes de la aplicación ............................................................................................ 49

B) Arquitectura de la aplicación .............................................................................................. 53

1) Vista de Procesos ............................................................................................................. 53

2) Vista lógica ...................................................................................................................... 56

3) Vista de escenarios .......................................................................................................... 56

C) Patrones de Diseño Implementados ................................................................................... 58

D) Pruebas y Evaluación de Software ..................................................................................... 59

E) Tecnologías utilizadas ........................................................................................................ 59

1) JavaEE ............................................................................................................................. 59

2) JavaServer Faces .............................................................................................................. 59

3) PrimeFaces 6.0 ................................................................................................................. 60

4) Spring Framework 4.3.8 .................................................................................................. 60

5) Hibernate 5.2.5 ................................................................................................................ 60

6) Spring Security 4.2.0 ....................................................................................................... 61

7) Slf4j 1.7.21 ...................................................................................................................... 61

8) Log4j2 2.7 ........................................................................................................................ 61

9) Lucene 30 ........................................................................................................................ 61

10) PostgreSQL 9.4 ............................................................................................................ 62

11) Angular 2 ..................................................................................................................... 62

VIII. DISCUSIÓN .......................................................................................................................... 63

A) Análisis de impactos ........................................................................................................... 63

B) Experiencia de diseño en ingeniería de software ............................................................... 64

LISTA DE TABLAS

Tabla 1: Representación gráfica notaciones de los objetos de flujo de BPMN. Tomado de [4]. ... 21

Tabla 2: Representación gráfica notaciones de los objetos de flujo de tipo “Evento” de BPMN.

Tomado de [4] ................................................................................................................................ 22

Tabla 3: Representación gráfica notaciones de los objetos de flujo de tipo “Actividad” de BPMN.

Tomado de [4] ................................................................................................................................ 23

Tabla 4: Representación gráfica de las notaciones de los objetos de flujo de tipo “Puerta de enlace”

de BPMN. Tomado de [4] .............................................................................................................. 24

Tabla 5: Datos de ejemplo para la ejecución del algoritmo. .......................................................... 33

Tabla 6: Fase de inicio: fechas de inicio y fin, cantidad de semanas y días................................... 41

Tabla 7: Fase de elaboración: fechas de inicio y fin, cantidad de semanas y días. ........................ 41

Tabla 8: Fase de construcción: fechas de inicio y fin, cantidad de semanas y días. ...................... 41

Tabla 9: Fase de transición: fechas de inicio y fin, cantidad de semanas y días. ........................... 42

Tabla 10: Requisitos funcionales ................................................................................................... 47

Tabla 11: Requisitos no funcionales .............................................................................................. 48

LISTA DE FIGURAS

Ilustración 1: Representación gráfica de un modelo de proceso de negocio.................................. 18

Ilustración 2: Representación del clúster de acuerdo a la clasificación. Tomado de [8]. .............. 29

Ilustración 3: Clasificación representada en un Dendograma. Tomado de [9] .............................. 30

Ilustración 4: Ejemplo de agrupación con K=3. Tomado de [10] .................................................. 31

Ilustración 5: Representación de dos puntos en el plano cartesiano .............................................. 33

Ilustración 6: Formula distancia euclidiana ................................................................................... 33

Ilustración 7: Formula Suma de Errores Cuadrados ...................................................................... 35

Ilustración 8: Representación del resultado algoritmo DBSCAN. Tomado de [15] ...................... 37

Ilustración 9: Modelo de proceso de desarrollo de software en espiral ......................................... 38

Ilustración 10: Modelo de proceso de desarrollo de software en cascada...................................... 39

Ilustración 11: Actividades con el tiempo de ejecución de cada una de ellas. ............................... 43

Ilustración 12: Componentes de la plataforma web ....................................................................... 49

Ilustración 13: Formato y campos del formato XPDL para representar actividades de BPMN .... 50

Ilustración 14: Representación de los agrupamientos para realizar el codebook ........................... 51

Ilustración 15: Diagrama de actividades: Registro e inicio de sesión ............................................ 53

Ilustración 16: Diagrama de actividades: Crear repositorio y/o Cargar PN ................................... 54

Ilustración 17: Diagrama de actividades: Consulta y agrupación de los PN.................................. 55

Ilustración 18: Modelo entidad relación ......................................................................................... 56

Ilustración 19: Caso de uso: Usuarios ............................................................................................ 56

Ilustración 20: Caso de uso: Repositorios ...................................................................................... 57

Ilustración 21: Caso de uso: Procesos de negocio .......................................................................... 57

Ilustración 22: Caso de uso: Agrupamiento ................................................................................... 58

Plataforma para la agrupación de modelos de procesos de negocio bajo el algoritmo…9

RESUMEN

El presente trabajo tiene como propósito la construcción de una plataforma web con una

arquitectura escalable, la cual realiza búsquedas multimodales en modelos de procesos de negocio

con el fin de efectuar agrupaciones a través del algoritmo de clustering K-MEANS, el cual tiene

como objetivo la partición en grupos (k) de un conjunto de observaciones (n), aplicándolo a los

modelos de proceso de negocio. La plataforma utiliza un repositorio de modelos de proceso de

negocio en formato XPDL, en los que se evalúa la agrupación de estos por medio de métricas

internas, las cuales no necesitan intervención de humanos.

Actualmente las empresas que cuentan con modelos de proceso de negocio se ven en la ardua tarea

de realizar búsquedas sobre repositorios con volúmenes muy grandes cuando se requieren realizar

modificaciones o reutilizaciones, esto demanda tiempo, genera reproceso y costos. La iniciativa es

desarrollar una plataforma web con un repositorio centralizado, donde se pueda realizar la

búsqueda y agrupación de modelos de procesos de negocio, con una estrategia de agrupación de

búsqueda automática, presentando los resultados de las búsquedas de una manera ordenada y

categorizada permitiendo que el usuario gaste menos tiempo y se pueda realizar un análisis más

efectivo.

La plataforma se desarrolló bajo una metodología de desarrollo en cascada, con la asesoría y con

el acompañamiento del Ing. Hugo Ordoñez, PhD., y en conjunto con los estudiantes Dilan Mejía y

Santiago Rodríguez.

Palabras clave: Clustering, KMEANS, BPM, BPMN, XPDL, XML.


ABSTRACT

The purpose of this paper is to construct a web platform with a scalable architecture, which

performs multimodal searches in business process models in order to perform groupings through

the algorithm of Clustering K-MEANS, which aims to partition into groups (k) a set of

observations (n), applying it to business process models. The platform uses a repository of

business process models in XPDL format, which evaluates the grouping of these by means of

internal metrics, which do not need human intervention.

Nowadays companies that have business process models see themselves in the arduous task of

searching on repositories with very large volumes when it is necessary to make modifications or

reuses, this demands time, generates reprocessing and costs. The initiative is to develop a web

platform with a centralized repository, where you can perform the search and grouping of

business process models, with an automatic search grouping strategy, presenting the search

results in an orderly and categorized way allowing The user spends less time and can perform a

more effective analysis.

The platform was developed under a methodology of development in cascade, with the advice

and the accompaniment of the Ing. Hugo Ordoñez, PhD., and together with the students Dilan

Mejía and Santiago Rodríguez.

Keywords: Clustering, KMEANS, BPM, BPMN, XPDL, XML.


GLOSARIO

BPMN: Business Process Modeling Notation es una notación abierta y estándar para

diagramas de flujos gráficos usada para definir flujos de trabajo de procesos de negocio.

Proceso de Negocio (PN): Un conjunto estructurado, medible de actividades diseñadas para

producir un producto especificado, para un cliente o mercado específico. Implica un fuerte

énfasis en cómo se ejecuta el trabajo dentro de la organización, en contraste con el énfasis

en el qué, característico de la focalización en el producto. (Davenport, 1993)

Repositorio: Un repositorio digital es un medio para gestionar, almacenar, preservar, difundir y facilitar el acceso a los objetos digitales que alberga. (Polanco-Cortés, 2014)

Clúster: Colección de objetos que son similares entre ellos y diferentes a los miembros de otro clúster. (Politecnico di Milano)

Clustering: Proceso de organizar objetos en grupos cuyos miembros son de alguna forma

similares. Politecnico di Milano

Búsqueda y Recuperación de Información: En inglés Information Retrieval (IR), es encontrar material (usualmente documentos) de naturaleza no estructurada (usualmente

texto) que satisface una necesidad de información desde grandes colecciones de datos

(normalmente almacenados en computadores). Manning, C. D., Raghavan, P., & Schütze,

H. (2008). Introduction to information retrieval (Vol. 1). Cambridge: Cambridge university

press.

K-MEANS: algoritmo de clustering basado en la definición de un número K de centroides que son usados para definir los clústeres. Un punto es considerado perteneciente a un clúster

si está más cerca del centroide de ese clúster que de los demás. El algoritmo encuentra la

mejor ubicación de los centroides al ser iterativo. Stanford University

XPDL: es el formato de serialización de BPMN. XPDL provee un formato de archivo que soporta cada aspecto de la notación de definición de procesos BPMN incluyendo

descripciones gráficas del diagrama y propiedades ejecutables utilizadas en tiempo de

ejecución. (xpdl.org, accedido el 07/03/2017)

OMG: Object Management Group es un consorcio, formado en 1989, dedicado al cuidado

y el establecimiento de diversos estándares de tecnologías orientadas a objetos, tales como

UML, XMI, CORBA y BPMN.

WfMC: Workflow Management Coalition es un consorcio industrial formado para definir estándares para la interoperabilidad de sistemas de gestión de flujos de trabajo.


I. INTRODUCCIÓN

La apertura y globalización de los negocios hacen que las organizaciones centren la atención en la

oferta de productos y servicios que sean innovadores y que tengan facilidad de adaptarse a un

medio cambiante. Para lograr todo esto, las organizaciones se ven en la tarea de mejorar y/o

automatizar sus procesos constantemente, entender y medir la cantidad de recursos humanos y

físicos que se requieren para lograr un objetivo, evaluar oportunidades de mejora de procesos, para

garantizar ahorro de recursos, disminución de tiempos de ejecución y aumento de satisfacción del

cliente. Lograr toda esta orquestación de manera manual resulta poco práctico. La pieza clave aquí,

para lograr realizar todas estas actividades, es utilizar modelos de proceso de negocio, que

solventan la orquestación de estas actividades y permiten ejecutar el proceso y visualizar

resultados.

Los modelos de procesos de negocio, si bien pueden definir un proceso o el conjunto de todos y

cada uno de los procesos necesarios para cumplir los objetivos específicos de una organización.

Estos modelos de proceso de negocio son reutilizables debido a que, si se cuenta con una estructura

del negocio bien definida, se pueden adecuar los modelos existentes al cambio y/o la necesidad,

por lo tanto, a medida que pasa el tiempo, crece el negocio y los procesos de negocio requieren de

cambios y/o mejoras continuas, se podrán realizar sin inconveniente alguno. En consecuencia,

cuando se desea modelar un nuevo proceso, modificar un proceso existente o basarse en un proceso

para la construcción de un nuevo modelo, se tiene que revisar o analizar de manera manual la

información contenida en los ya existentes, tarea que demanda mucho esfuerzo y tiempo

considerable.

A partir de todo esto es donde se evidencia la oportunidad que hay de mejora, con la

implementación de la plataforma web, debido a que en la actualidad la mayoría de las empresas

detallan los objetivos de la organización y su negocio en tecnologías de la información, como lo

son los modelos PN ya que, como se ha mencionado, estos les garantiza una prevención temprana

en la detección de posibles problemas o cuellos de botella en el proceso y garantiza una agilidad


en el mercado, pero no cuentan y/o desconocen de las herramientas que les permiten hacer un

constante seguimiento y gestión de la información de los mismos.


II. PLANTEAMIENTO DEL PROBLEMA

Actualmente las organizaciones pueden contar con repositorios de modelos de procesos de

negocio de volúmenes muy grandes, de manera que sea necesario la información allí

contenida, ya sea para modelar un nuevo proceso de negocio o para modificarlo, un miembro

de la organización debe realizar la búsqueda general por los criterios de agrupamiento dados

dentro de los repositorios o analizar individualmente la información contenida en estos

modelos, tarea que demanda un esfuerzo considerable y no aprovecha a fondo el potencial que

tiene para la organización el descubrir las similitudes entre sus procesos de negocio.


III. JUSTIFICACIÓN

El creciente volumen de PN almacenados en repositorios ha significado un aumento en la

investigación de todo lo relacionado con estos pues son problemas reales de la industria y la

academia, por tanto, la disponibilidad de los resultados obtenidos por estas investigaciones,

más aún los resultados prácticos como el modelo de búsqueda descrito en [11], pueden resultar

más útiles al implementarse dentro de un entorno web.

La implementación de los algoritmos de clustering en una plataforma web permite abstraer al

usuario de tareas como la instalación local de software, con todo que implica como la

actualización del mismo, los requisitos locales de hardware y software, entre otros; además de

ofrecer portabilidad y eficiencia en los grupos de trabajo que los utilizan.


IV. OBJETIVOS

A. Objetivo general

Construir una plataforma web para la agrupación bajo demanda, a partir de una búsqueda o

consulta, de modelos de proceso de negocio, que permita realizar búsquedas multimodales y

ejecutar el algoritmo de clustering K-MEANS, con el fin de que los resultados obtenidos en

el proceso de búsqueda sean desplegados de manera organizada (en forma de grupos).

B. Objetivos específicos

Adaptar el algoritmo de clustering K-Means para utilice información textual y

estructural existente en los modelos de PN de un repositorio.

Desarrollar una plataforma web que implemente el algoritmo de agrupación

anteriormente propuesto.

Evaluar el comportamiento del algoritmo frente al otro algoritmo de clustering

utilizando métricas de evaluación internas.


V. MARCO TEÓRICO

A. BPM

La gestión de modelos de procesos de negocio (por sus siglas en inglés: Business Process

Management - BPM), son un conjunto de métodos, herramientas y tecnologías que permiten

a una organización modelar, implementar y ejecutar conjuntos de actividades relacionadas

entre sí, donde se ven reflejados un conjunto actividades, pasos, tareas, personal, aplicaciones

e incluso actividades de otras organizaciones que interactúan en un proceso de negocio.

Las organizaciones están apuntando a la utilización de esta tecnología debido a que permite:

Analizar los procesos actuales o nuevos para conocer cómo definir las tareas, cómo

ejecutar dichas tareas, quién realiza las tareas, dónde se realizan, qué datos utiliza, qué

reglas de negocio deben cumplirse, etc.

Diseñar los procesos de negocio siguiendo una notación BPM.

Ejecutar y automatizar los procesos con un motor de reglas de trabajo, e integrar las

aplicaciones y datos para que exista una orquestación adecuada.

Monitorizar las actividades de negocio y relacionar la información de los procesos con

la estrategia empresarial para conocer si se está encaminado a los objetivos o no, y así

tomar decisiones reactivas.

B. Importancia de BPM

Actualmente los PN son una pieza clave para las organizaciones, estos dan un valor agregado

que aportan a las estrategias corporativas y ayudan en la diferenciación en el mercado. Los

modelos de proceso de negocio se convierten en un instrumento fundamental para el éxito ya

que la visión sistemática de la organización con sus respectivos procesos facilita la mejora,

dirección y gobernabilidad. La gestión de estos, permite medir, controlar y evaluar los

procesos con el fin de mejorarlos de inicio a fin, garantizando así el aumento de la satisfacción

de los empleados y clientes, agilidad y calidad de servicios, disminución de tiempo, calidad

en los productos, reducción de costos, aumento de los beneficios, entre otros.


C. BPMN

Modelo y notación de procesos de negocio (por sus siglas en ingles Business Process Model

Notation – BPMN), es una notación grafica estándar que permite el modelado visual de un

proceso de negocio. Con esta notación, se pueden representar los modelos de proceso de

negocio conociendo así la descripción gráfica, como se representa en la Figura 2.1, del

procedimiento con su conjunto de actividades o sub actividades, definiendo los roles y las

relaciones funcionales. Entre los múltiples beneficios que aportan estas representaciones se

encuentra conocer una visión de extremo a extremo del proceso del negocio, detalle de la

orquestación de las tareas que se deben de ejecutar, identificación los cuellos de botella que

se puedan tener, ejecutar simulaciones de la ejecución de estos procesos de negocio lo cual

aporta información valiosa para optimizar y/o mejorar el negocio antes de una puesta en

producción, entre otros.

Ilustración 1: Representación gráfica de un modelo de proceso de negocio

Dentro de sus principales objetivos se encuentran:


Presentar una notación grafica estándar que sea fácilmente legible y entendible por

parte de todos los involucrados e interesados que interactúan con el proceso del

negocio.

Permitir la portabilidad de las definiciones del proceso, de modo que los usuarios

puedan tomar las definiciones del proceso creadas en el entorno de una aplicación y

puedan migrarse a otra fácilmente.

D. Elementos de BPMN

BPMN proporciona un pequeño conjunto de categorías de notación para que el lector del

modelo pueda reconocer fácilmente los tipos básicos de elementos y comprenderlo. Dentro de

las categorías básicas de elementos, se pueden agregar variaciones e información adicionales

para apoyar los requisitos de complejidad sin cambiar drásticamente la apariencia básica del

diagrama [4].

Las cinco categorías básicas de elementos son:

Objetos de flujo

Datos

Conexiones de objetos

Líneas de conexión

Artefactos

Los objetos de flujo son los elementos gráficos principales para definir el comportamiento de

un proceso, estos elementos gráficos serán el insumo principal para realizar las búsquedas

multimodales y ejecutar el algoritmo de clustering. Los objetos de flujo se representan con

tres tipos de elementos:

Eventos

Actividades

Compuertas


Los datos se representan con los cuatro elementos:

Objetos de datos

Entrada de datos

Salida de datos

Almacenamiento de datos

Hay cuatro formas de conectar los objetos de flujo entre sí u otra información. Las conexiones

de objetos son representadas por cuatro elementos:

Secuencia de flujos

Flujos de mensajes

Asociaciones

Asociaciones de datos

Hay dos formas de agrupar los elementos primarios de modelado a través de artefactos, estos

son representados por dos elementos:

Pool

Etiquetas

E. Representación de los objetos de flujo de BPMN

Evento Un evento es algo que sucede durante el curso de un

proceso. Estos eventos afectan el flujo del modelo y

suelen tener una causa (desencadenante) o un

impacto (resultado). Los eventos son círculos con

centros abiertos para permitir que los marcadores

internos diferencien diferentes disparadores o

resultados. Hay tres tipos de eventos, en función de

cuándo afectan al flujo: Inicio, Intermedio y Fin.


Actividad Una Actividad es un término genérico para el trabajo

que realiza un proceso. Una actividad puede ser

atómica o no atómica (compuesto). Los tipos de

Actividades que forman parte de un Modelo de

proceso son: Subproceso y Tarea, que son

rectángulos redondeados.

Puerta de

enlace

Se utiliza para controlar la divergencia y la

convergencia de los flujos de secuencia en un

proceso. Por lo tanto, determinarán ramificación,

bifurcación, fusión y unión de rutas. Los marcadores

internos indicarán el tipo de control de

comportamiento.

Tabla 1: Representación gráfica notaciones de los objetos de flujo de BPMN. Tomado de

[4].

Es necesario conocer la terminología y representación, únicamente, de los objetos de flujo de

BPMN ya con la descripción de cada uno de ellos, se generarán todos los archivos necesarios

para ejecutar cada uno de los métodos que componen la plataforma web.

1) Representación de los objetos de flujo tipo “Evento” de BPMN

Hay tres tipos de eventos, basados en cuándo afectan al flujo: Inicio, Intermedio y Fin.

Start: (Inicio) indica cuando un proceso en particular inicia.

Intermediate: (Intermedios) ocurren entre un evento de inicio y un evento de

finalización. Ellos afectarán el flujo del proceso, pero no iniciarán ni terminarán

(directamente) el Proceso.

End: (Inicio) indica cuando un proceso en particular termina.


Cada tipo de evento se tiene unos sub eventos dependiendo del proceso que se desea ejecutar,

como se representa en la tabla 2.

Tabla 2: Representación gráfica notaciones de los objetos de flujo de tipo “Evento” de

BPMN. Tomado de [4]

2) Representación de los objetos de flujo tipo “Actividad” de BPMN

Hay diferentes tipos de Tareas identificadas dentro de BPMN como se representan en la tabla

3. La representación de tipo de tarea específica se obtiene colocando un fabricante de Task


Type en la esquina superior izquierda de la forma de tarea, o indicando si el tipo de tarea hace

referencia a un subproceso colapsado o subproceso expandido. Una tarea que no se especifica

se llama tarea abstracta.

Tabla 3: Representación gráfica notaciones de los objetos de flujo de tipo “Actividad” de

BPMN. Tomado de [4]


3) Representación de los objetos de flujo tipo “Puerta de enlace” de BPMN

Las puertas de enlace se utilizan para controlar cómo interactúan los flujos de secuencia a

medida que convergen y divergen dentro de un proceso. Si no es necesario controlar el flujo,

no se necesita una puerta de enlace.

Tabla 4: Representación gráfica de las notaciones de los objetos de flujo de tipo “Puerta de

enlace” de BPMN. Tomado de [4]


F. XPDL

XPDL (Por sus siglas en inglés: XML Process Definition Language), es un formato

estandarizado por la Workflow Management Coalition (WfMC) para intercambiar

definiciones de procesos de negocio entre diferentes productos de flujo de trabajo, es decir,

entre diferentes herramientas de modelado y suites de administración. XPDL define un

esquema XML para especificar la parte declarativa del flujo de trabajo / proceso empresarial.

G. Importancia de XPDL

XPDL habilita un ecosistema de definición de procesos que es usado hoy por más de 80

productos diferentes hoy para intercambiar definiciones de procesos. A medida que un

porcentaje mayor de la organización comienza a usar herramientas de proceso para el trabajo

diario, será cada vez menos razonable adoptar una estrategia de un solo proveedor para

procesar el trabajo de definición. Los usuarios necesitan ir más allá del bloqueo del proveedor

y adoptar un enfoque de "mejor opción" que permita el uso de su tecnología de proceso

favorita para realizar tareas específicas orientadas a procesos, como la simulación, la

optimización, etc. [7]

XPDL es extensible de modo que permite que cada herramienta diferente almacene la

información específica de la implementación dentro del XPDL y que los valores se conserven

incluso cuando son manipulados por herramientas que no entienden esas extensiones. Esta es

la única manera de proporcionar un "viaje de ida y vuelta" a través de múltiples herramientas

y aun así ser capaz de volver a la herramienta original con total fidelidad.

XPDL es el formato de serialización para BPMN. BPMN es un estándar de notación de

proceso visual de la OMG, aprobado por WfMC, y ampliamente adoptado en toda la industria.

Pero el estándar BPMN define sólo el aspecto de cómo se muestra la definición del proceso

en la pantalla. XPDL proporciona un formato de archivo que admite todos los aspectos de la

notación de definición de procesos BPMN, incluyendo descripciones gráficas del diagrama,


así como ejecutable Propiedades utilizadas en tiempo de ejecución. Con XPDL, un producto

puede escribir una definición de proceso con total fidelidad, y otro producto puede leerlo y

reproducir el mismo diagrama que se envió.

H. Estructura básica de XPDL

<Package>

<PackageHeader>

...

</PackageHeader>

<WorkflowProcesses>

<DataFields>...</DataFields>

<Participants>... <Participants>

<Activities>...</Activities>

<Transitions>...</Transitions>

</WorkflowProcesses>

</Package>

I. Clúster

El concepto de “Clúster” fue popularizado por el economista Michel Porter el año 1990, en su

libro The Competitive Advantage of Nations, refiriéndose a “un grupo geográficamente

próximo de compañías interconectadas e instituciones asociadas, en un campo particular,

vinculadas por características comunes y complementarias, incluyendo empresas de productos

finales o servicios, proveedores, instituciones financieras y empresas de industrias conexas”.

Así, Porter dijo que” la competitividad de una región se basa en la competitividad de sus

industrias que a su vez es mejorada si una industria está sumergida en una profunda red”. Es

decir que los clústeres son concentraciones geográficas de empresas e instituciones

interconectadas que actúan en determinado campo.


Según el Diccionario Compacto Oxford “Clúster es un grupo de cosas similares posicionadas

o que ocurren de manera cercana entre sí”, de esta manera, así el concepto inicial de clúster

haya nacido en el ámbito industrial, el termino Clúster puede hacer referencia a múltiples

disciplinas, ya que su objetivo es definir un grupo con ciertas similitudes.

J. Clustering

El Clustering es una tarea que consiste en agrupar un conjunto de objetos (no etiquetados) en

subconjuntos de objetos llamados Clústeres. Cada Clúster está formado por una colección de

objetos que son similares (o se consideran similares) entre sí, pero que son distintos respecto

a los objetos de otros Clústeres. Para medir la similitud entre objetos se suelen utilizar

diferentes formas de distancia: distancia euclídea, de Manhatan, de Mahalanobis, etc. El

representar los datos por una serie de clústeres, conlleva la pérdida de detalles, pero consigue

la simplificación de los mismos. Clustering es una técnica más de Aprendizaje Automático,

en la que el aprendizaje realizado es no supervisado. Desde un punto de vista práctico, el

clustering juega un papel muy importante en aplicaciones de minería de datos, tales como

exploración de datos científicos, recuperación de la información y minería de texto,

aplicaciones sobre bases de datos espaciales, aplicaciones web, marketing, diagnóstico

médico, análisis de ADN en biología computacional, y muchas otras.

Es importante no confundir el Clustering con los problemas de Clasificación. Las técnicas de

Clasificación se enmarcan dentro del aprendizaje supervisado porque para cada dato tenemos

información sobre sus variables de entrada y de salida; es decir, cada dato u objeto esta

etiquetado. Sin embargo, para aquellos casos en los que no disponemos de la salida de cada

dato y queramos agrupar estos objetos en grupos similares, debemos de aplicar alguna de las

técnicas de Clustering para saber la procedencia de estos datos.

Tomando el siguiente caso de ejemplo [8]: Se tiene un data set (DS1) con el color de pelo de

un conjunto de personas. Como entrada se tiene el color en RGB del pelo de cada persona y


como salida un conjunto finito de etiquetas {Moreno, Rubio, Castaño, Canoso}. Por otro lado,

se tiene otro data set (DS2) con el color del pelo en RBG de otro conjunto de personas, pero

en este caso no se tiene como salida una etiqueta que diga si el individuo es Moreno, Rubio,

Castaño o Canoso. Para ambos casos se requiere generar un modelo que permita etiquetar a

nuevas personas en Morenos, Rubios, etc. ¿Cómo se abordaría este problema para el DS1 y

DS2?

1) DS1

El primer caso se trata de un problema de clasificación, ya que para cada individuo se tiene su

color de pelo en RGB y su clasificación correspondiente {Moreno, Rubio, Castaño, Canoso}.

Para este caso se debe de obtener una función (o hipótesis) en base a los datos de

entrenamiento para que a cada nueva entrada (color del pelo en RGB) lo etiquete de forma

correcta:

f(x=color) = {Moreno, Rubio, Castaño, Canoso}

2) DS2

El segundo caso se trata de un ejemplo claro de Clustering, ya que se tiene que obtener

información sobre su estructura o dominio de salida con base a los datos del color de pelo que

se tienen en el DS2. Para ello se debe de utilizar alguna de las técnicas de Clustering para

agrupar todos los datos en 4 Clústeres. Una vez ejecutado este algoritmo de Clustering se

pueden identificar que individuos son Morenos, Rubios, Castaños o Canosos viendo

solamente el valor medio (o Centroide) de cada Clúster. Un ejemplo de Clustering de este data

set visto en 2D sería el siguiente:


Ilustración 2: Representación del clúster de acuerdo a la clasificación. Tomado de [8].

K) Tipos de Clustering

1) Clustering Jerárquico

El análisis clúster jerárquico configura grupos con estructura arborescente, de forma que

clústeres de niveles más bajos van siendo englobados en otros niveles superiores. Partiendo

de tantos grupos iniciales como individuos, se trata de conseguir agrupaciones sucesivas entre

ellos de forma que progresivamente se vayan integrando en clústeres los cuales, a su vez, se

unirán entre sí en un nivel superior formando grupos mayores que más tarde se juntarán hasta

llegar a un clúster final que contiene a todos los casos analizados.

La decisión sobre el número de grupos se toma en función del método de enlace de clúster

que hayamos elegido: enlace simple, enlace completo, métodos de Ward, etc. Según el que se

use, puede salir una clasificación u otra. El proceso comienza con tantos grupos como

individuos. Entonces, a medida que transcurren las etapas se van formando nuevos clústeres:

Por unión de individuos

Por unión de un individuo con un grupo previo

Por unión de dos grupos anteriores entre los que existe la menor distancia.


El proceso finaliza con un único clúster que contiene a todos los individuos, pero constituido

por aglomeraciones sucesivas en distintos niveles. El objetivo consiste en decidir donde se

detiene el esquema de aglomeración para quedarnos con una solución clúster aceptable.

La representación se hace por medio de un Dendograma. Un dendrograma es un tipo de

representación gráfica o diagrama de datos en forma de árbol que organiza los datos en

subcategorías que se van dividiendo en otros hasta llegar al nivel de detalle deseado

(asemejándose a las ramas de un árbol que se van dividiendo en otras sucesivamente). Este

tipo de representación permite apreciar claramente las relaciones de agrupación entre los datos

e incluso entre grupos de ellos aunque no las relaciones de similaridad o cercanía entre

categorías. Observando las sucesivas subdivisiones se puede hacer a la idea sobre los criterios

de agrupación de los mismos, la distancia entre los datos según las relaciones establecidas,

etc.

Ilustración 3: Clasificación representada en un Dendograma. Tomado de [9]

2) Clustering No Jerárquico

En este caso las observaciones se asignan a unos clústeres que el propio análisis configura sin

que haya una relación entre unos grupos y otros. Se necesita que el experto fije de antemano


el número de clústeres (k) en que quiere agrupar sus datos. Como esto no se suele saber a

priori con exactitud lo que se suele hacer es repetir el análisis con diferente número de

clústeres hasta conseguir la mejor interpretación o la clasificación que más se ajusta al objetivo

de nuestro problema.

Una clasificación se considera correcta si la dispersión dentro de cada grupo formado sea la

menor posible. Esta condición se denomina “criterio de varianza” y lleva a seleccionar una

configuración cuando la suma de las varianzas dentro de cada grupo sea mínima. Basándose

en esta condición se han propuesto varios métodos. El más conocido es el algoritmo de las K-

MEANS [10].

Ilustración 4: Ejemplo de agrupación con K=3. Tomado de [10]

L) K-MEANS

K-Means es un método particional de clustering donde se construye una partición de una base

de datos D de N objetos en un conjunto de K grupos, buscando optimizar el criterio de

particionamiento elegido. En K-Means cada grupo está representado por su centro.

K-Means comienza particionando los datos en k subconjuntos no vacíos, aleatoriamente o

usando alguna heurística. Luego calcula el centroide de cada partición como el punto medio

del clúster y asigna cada dato al clúster cuyo centroide sea el más próximo. Luego los

centroides son recalculados para los grupos nuevos y el algoritmo se repite hasta la

convergencia, la cual es obtenida cuando no haya más datos que cambien de grupo de una


iteración a otra. Para calcular el centroide más cercano a cada punto se debe utilizar una

función de distancia. Para datos reales se suele utilizar la distancia euclídea. Para datos

categóricos se debe establecer una función específica de distancia para ese conjunto de datos.

Algunas de las opciones son utilizar una matriz de distancias predefinidas o una función

heurística.

El algoritmo no garantiza que se obtenga un óptimo global. La calidad de la solución final

depende principalmente del conjunto inicial de grupos. Debido a esto, se suelen realizar varias

ejecuciones del algoritmo con distintos conjuntos iniciales, de modo de obtener una mejor

solución.

Dado k, el algoritmo K-Means se implementa en 4 pasos

I. Particionar los objetos en k subconjuntos no vacíos.

II. Computar los centroides de los clúster de la partición corriente. El centroide es el

centro (punto medio) del clúster.

III. Asignar cada objeto al clúster cuyo centroide sea más cercano.

IV. Volver al paso II, hasta que no haya más reasignaciones.

1) Distancia euclidiana

Es una función no negativa usada en diversos contextos para calcular la distancia entre dos

puntos, primero en el plano y luego en el espacio. También sirve para definir la distancia entre

dos puntos en otros tipos de espacios de tres o más dimensiones. Y para hallar la longitud de

un segmento definido por dos puntos de una recta, del plano o de espacios de mayor

dimensión, la cual se deduce a partir del teorema de Pitágoras. [12]


Ilustración 5: Representación de dos puntos en el plano cartesiano

En un espacio bidimensional, tomando como referencia la figura 6, la distancia euclidiana

entre dos puntos P1 y P2, de coordenadas cartesianas (x1, y1) y (x2, y2) respectivamente, es:

Ilustración 6: Formula distancia euclidiana

2) Ejecución del algoritmo

Tabla 5: Datos de ejemplo para la ejecución del algoritmo.

Se da como ejemplo un estudio con 3 variables (X1, X2 y X3) y 6 observaciones (O1, O2, O3,

O4, O5, O6) o individuos


Paso 1:

Se parte de k clústeres iniciales. Para este caso k=3 y se seleccionan los valores iniciales de

cada clúster:

Clúster 1 = {2, 5, 6}

Clúster 2 = {1, 3}

Clúster 3 = {4}

Paso 2:

Se calculan los centroides de cada clúster:

Centroide Clúster 1 ({2, 5, 6}) = (14/3, 19/3, 15/3)

Coordenada para X1: (6 + 5 + 3)/3 = 14/3



Centroide Clúster 2 ({1, 3}) = (9/2, 7, 20)

Centroide Clúster 3 ({4}) = (6, 9, 46)

Paso 3:

Se calcula la suma de varianzas dentro de cada grupo, conocido cono error de esa clasificación.

En el ejemplo da 137.805.

Paso 4:

Se comprueba si el movimiento de una observación o individuo a otro clúster implica una

reducción en el error anterior, es decir, en la suma de varianzas dentro de cada grupo.

En el ejemplo se comprueba que pasa con el error si se mueve la observación 1 al clúster 1ó

3, la 2 al clúster 2 ó 3, la 3 al clúster 1 ó 3, la 4 al clúster 1 ó 2, la 5 al clúster 2 ó 3 y la 6 al

clúster 2 ó 3.

Se comprueba que el único caso donde disminuye el error es cuando se mueve la observación

6 al clúster 2. Se pasa de un error de 137.805 a un error de 85.655

Paso 5:

Se calculan los nuevos centroides de los clústeres.


Clúster 1 = {2, 5} Centroide Clúster 1 = (11/2, 9, 3/2)

Clúster 2 = {1, 3, 6} Centroide Clúster 2 = (4, 5, 52/3)

Clúster 3 = {4} Centroide Clúster 3 = (6, 9, 46)

Paso 6:

Se comprueba si algún otro movimiento reduce aún más el error y se repite el procedimiento

anterior hasta que no se consiga ninguna mejora. En el ejemplo se comprueba que no hay

ningún movimiento que haga disminuir el error y por lo tanto, la solución final es:

Clúster 1 = {2, 5}

Clúster 2 = {1, 3, 6}

Clúster 3 = {4}

3) Suma de errores cuadrados

Suma de Errores Cuadrados (Sum of Squares Error – SSE): SSE es la suma de las diferencias cuadradas entre cada observación y la media de su grupo. Es utilizado como una medida de la variación dentro de un clúster. Si todos los casos dentro de un grupo son idénticos, el SSE sería entonces igual a 0. [13] La fórmula para SSE es:

Ilustración 7: Formula Suma de Errores Cuadrados

Donde n es el número de observaciones x i es el valor de la i-ésima observación y 0 es la media de todas las observaciones. Estas métricas se utilizan para identificar cuán cerca o distante se encuentran entre sí en los grupos formados.


M) DBSCAN

Se presenta la información y se utilizará este algoritmo de clustering con el fin de suplir el

objetivo específico del proyecto en la sección 1.5.3, que inicialmente estaba pactado como

evolución del comportamiento del algoritmo de clustering K-MEANS contra el algoritmo de

clustering usado en la plataforma implementada por los compañeros de Tesis Dilan Steven

Mejia Buitrago y Santiago Rodriguez Flor, pero evaluando las posibles consecuencias el día

de la presentación del ante proyecto, se optó por hacer una pequeña implementación del

algoritmo que sería implementado en caso tal de que la otra plataforma no estuviese completa.

Algoritmo de agrupamiento de datos propuesto por Martin Ester, Hans-Peter Kriegel, Jörg

Sander y Xiaowei Xu en 1996.1 Es un algoritmo de agrupamiento basado en densidad

(density-based clustering) porque encuentra un número de grupos (clústeres) comenzando por

una estimación de la distribución de densidad de los nodos correspondientes.

Se definen dos parámetros, un número épsilon positiva y un número natural minPoints, y se

elige un punto arbitrario en el conjunto de datos. Si hay una cantidad de puntos mayor o igual

a minPoints a una distancia épsilon del punto arbitrario, a partir de ese momento se consideran

todos los puntos como parte de un "clúster". A continuación, se expande ese grupo mediante

la comprobación de todos los nuevos puntos y ver si ellos también tienen más puntos

minPoints a una distancia épsilon, creciendo el clúster de forma recursiva en caso afirmativo.

[14]

A medida que se generan los clústeres, quedan puntos sin añadir al clúster. A continuación,

se elige un nuevo punto arbitrario y se repite el proceso. Es posible que el punto arbitrario

escogido tenga menos de minPoints puntos en su círculo de radio épsilon, y tampoco sea parte

de cualquier otra agrupación. Si ese es el caso, se considera un "punto de ruido" que no

pertenece a ningún grupo.


Ilustración 8: Representación del resultado algoritmo DBSCAN. Tomado de [15]


VI. METODOLOGÍA

En este capítulo se presentan los procesos específicos de ingeniería aplicados para el

desarrollo de este proyecto. Los procesos son: elección de un modelo de proceso, la reducción

de requisitos funcionales y no funcionales, definición de artefactos necesarios para el análisis

y diseño, la elección de las herramientas, patrones y tecnologías que fueron usadas durante el

proceso de desarrollo del software, culminando con las respectivas pruebas que validarán el

cumplimiento de los objetivos propuestos.

La presentación de dichos procesos tiene como objetivo evidenciar el desarrollo de

competencias en términos de desarrollo de software, por parte de los autores del documento.

A) Modelo de proceso de desarrollo de software.

El modelo escogido fue el modelo de desarrollo evolutivo en espiral.

El modelo propuesto por Boehm (1988) conjuga la naturaleza iterativa, como se representa en

la Ilustración 9, de la construcción de prototipos con los aspectos controlados y sistemáticos

del modelo en cascada.

Ilustración 9: Modelo de proceso de desarrollo de software en espiral


El modelo en cascada propuesto por Royce (1970), se derivó de procesos de sistemas más

generales. Sus principales etapas, como se representan en la Ilustración 10, se transforman en

actividades fundamentales del desarrollo:

Ilustración 10: Modelo de proceso de desarrollo de software en cascada

Cuando se aplica el modelo en espiral, el software se desarrolla en una serie de entregas

evolutivas. Cada una de las actividades del marco de trabajo representa un segmento de la ruta

en espiral.

Este modelo se basa en la idea de desarrollar una implementación inicial, exponiéndola a los

comentarios del usuario y refinándola a través de las diferentes versiones que se generan hasta

que se desarrolle un sistema adecuado.

Las actividades de diseño, implementación y verificación, del modelo en cascada, se

entrelazan, en el modelo espiral, en vez de separarse, con una rápida retroalimentación entre

estas. Existen dos tipos de desarrollo evolutivo:

Desarrollo exploratorio: En este caso el objetivo del proceso es trabajar con el cliente

para explorar sus requerimientos y entregar un sistema final. El desarrollo empieza

con las partes del sistema que se comprenden mejor. El sistema evoluciona agregando

nuevos atributos propuestos por el cliente.


Prototipos desechables: El objetivo de este proceso de desarrollo evolutivo es

comprender los requerimientos del cliente para así desarrollar una definición mejorada

de los requerimientos para el sistema. El prototipo se centra en experimentar los

requerimientos del cliente que no se comprenden del todo.

Haciendo referencia a la producción del software, el enfoque evolutivo suele ser más efectivo

que el enfoque en cascada, ya que satisface las necesidades inmediatas de nuestro cliente, que

en este caso es el tutor de la tesis de grado. La ventaja de un software que se basa en un

enfoque evolutivo es que las especificaciones se pueden desarrollar de forma creciente. Tan

pronto como se desarrolle un mejor entendimiento de su problema, esto se puede reflejar en

el software. Precisamente, por esta ventaja, se escogió el modelo de procesos de desarrollo de

software en espiral como el modelo apto para llevar a cabo la ejecución del proyecto, y el tipo

de desarrollo exploratorio, debido a que la plataforma cuenta con unas funcionalidades básicas

(conexión con base de datos, manejo de sesiones, visualización de opciones de acuerdo a los

roles, etc.) de cualquier aplicación independiente de su objetivo y se fueron adicionando, a

medida que se realizaron las entregas de la plataforma, las funcionalidades esenciales para

suplir los objetivos del proyecto.

1) Descripción de Iteraciones realizadas y fases realizadas

Se realizó el diseño, desarrollo e implementación en 4 fases, las iteraciones se realizaron por

semana. En las tablas 5, 6, 7 y 8 se encuentra un resumen de las fases realizadas. En la tabla

3 se encuentra el detalle de las actividades y horas que tomo la ejecución de cada una de las

actividades.


FASE 1 - INICIO

Fecha inicio 29-nov-16

Fecha fin 20-dic-16

Total semanas 3

Total días 12

Tabla 6: Fase de inicio: fechas de inicio y fin, cantidad de semanas y días.

FASE 2 - ELABORACIÓN

Fecha inicio 03-ene-17

Fecha fin 31-ene-17

Total semanas 3

Total días 18

Tabla 7: Fase de elaboración: fechas de inicio y fin, cantidad de semanas y días.

FASE 3 - CONSTRUCCIÓN


Fecha fin 28-mar-17

Total semanas 8

Total días 48

Tabla 8: Fase de construcción: fechas de inicio y fin, cantidad de semanas y días.


FASE 4 - TRANCISIÓN


Fecha fin 28-mar-17

Total semanas 8

Total días 48

Tabla 9: Fase de transición: fechas de inicio y fin, cantidad de semanas y días.


Ilustración 11: Actividades con el tiempo de ejecución de cada una de ellas.

B) Educción de Requisitos

Se utilizaron las siguientes técnicas de educción y de asistencia para obtener los requisitos

del sistema:

Técnicas de educción:

Entrevista

Workshop

Técnicas de asistencia:

Lluvia de ideas

Prototipos

Disciplinas Artefacto Actividad 1 2 3 Total 4 5 6 Total 7 8 9 10 11 12 13 14 Total 15 16 17 Total

Documento

vision

Elaborar borrador con la informacion

referente al proyecto (papers, codigo

fuente) 3 3 4 10 3 3 3 9

Encontrar actores y casos de uso 3 3 4 10

Priorizar casos de uso 3 3 4 10 1 1 2 1 1

Detallar casos de uso 3 3 4 10 1 1 2 1 1

Estructurar modelo de casos de uso 3 3 4 10 1 1 2 1 1 Esfuerzo

Total por fase 50 6 12 68

Entrevista 1 1 1 1 0 0

Toma de requisitos 1 1 2 0 0 0

Preguntas referentes a los requisitos 1 1 2 0 2 2 0

Elicitacion de los requisitos 2 2 4 2 2 4 2 4 4 2 2 2 2 4 22 0 Esfuerzo

Total por fase 9 5 24 0 38

Diagrama de

requisitos

Realizar diagrama para comprender las

tareas y delimitar su alcance 0 6 6 5 17 0 0

Diagrama de clases0 6 6 5 17 0 0

Diagrama de actividades 0 6 6 12 0 0

Vista logica Modelo entidad-relación 0 2 4 6 4 4 2 1 1 12 0


Sistema de

software

Diseño y desarrollo de casos de uso y/o

flujos de acuerdo con la planeación

iterativa 0 6 5 5 16 13 13 13 15 20 18 20 15 127 2 2 2 6

Casos de prueba

Pruebas de los casos de uso

desarrollados, y pruebas de regresión

según sea el caso 0 4 4 4 4 4 4 4 8 8 10 46 2 2 2 6

InterfazDesarrollo de los protoripos de las

páginas web 0 4 4 6 6 6 6 6 30 2 2 2 6 Esfuerzo


Pruebas Pruebas funcionales 0 0 4 2 4 4 2 2 7 15 40 8 8 8 24


Instalación en los servidores 0 0 0 8 8 15 24

Estabilización 0 0 0 8 8 5 21 Esfuerzo


Total por iteración 20 19 20 39 30 30 27 174 33 30 30 32 34 39 43 50 291 30 30 34 94

Transición

Codificación

Instalación

Modelo del

negocio

Requisitos

Análisis y

diseño

Inicio

Vista de

procesos

Elaboración Construcción

Semana

Diagrama de

casos de uso

Especificacion

de requisitos


1) Entrevista

El objetivo principal de realizar la entrevista es que permiten a los analistas, en este caso a

nosotros como estudiantes y desarrolladores, tomar conocimiento del problema y comprender

los objetivos de la solución buscada. Esta técnica logra orientar al equipo de trabajo al

problema de una forma natural. A pesar de que existan muchos tipos de entrevistas y sean

muchos los autores que han tratado de definir una estructura base para su realización [5], no

se optó por una estructura base y se fueron modificando las preguntas en curso de la ejecución

de la entrevista. La entrevista, donde se abordó la necesidad del proyecto, se realizó con el

director de la tesis Hugo Armando Ordoñez Erazo.

Los pasos principales que fueron llevados a cabo en la entrevista fueron los siguientes:

Estudio del domino del problema a abordar en el proyecto, para tener la necesidad de

una manera más clara la necesidad y la expectativa del dueño del negocio.

Identificación de las tecnologías necesarias y utilizadas por los trabajos relacionados

al proyecto.

Preparación del plan de trabajo, definición actividades a realizar, entregas, etc.

Utilizar la técnica de asistencia de prototipos para garantizar que el objetivo o

funcionalidades de la plataforma, estén encaminadas a suplir los objetivos específicos

A pesar de que las entrevistas son esenciales en el proceso de la captura de requisitos y, con

su aplicación, el equipo de desarrollo puede obtener una amplia visión del trabajo y las

necesidades del usuario, es necesario destacar que no es una técnica sencilla de aplicar y que

tiene varias deficiencias, ya que requiere en la mayoría de los casos que el entrevistador, en

este caso yo como analista encargado de la ejecución del proyecto, sea experimentado en el

área de las entrevistas y tenga un amplio conocimiento acerca del dominio del problema. Para

solventar este problema, lo que se realizó fue obtener la mayor cantidad de información por

parte del tutor de la tesis, que es un experto en el dominio del problema, y generar, a través de

allí, las dudas correspondientes tanto para la ejecución del proyecto como para la utilización

de las tecnologías necesarias.


2) Workshop

Aunque la ejecución del proyecto se haya realizado de manera individual, las actividades

como educción de los requisitos, diseño e implementación de tecnologías necesarias, se

realizaron de manera conjunta con los estudiantes Dilan Steven Mejía y Santiago Rodríguez

Flor, que abordan el mismo problema, pero desarrollan la solución desde una perspectiva y

algoritmos diferentes. Con base en esto, se realizaron Workshop, los cuales fueron planeados

con los días a ejecutar y temas a tratar, con los estudiantes anteriormente mencionados.

Los objetivos principales de la realización del Workshop fueron los siguientes:

Ampliar y detallar los requisitos que fueron identificados en primera instancia en la

entrevista realizada con el tutor de la tesis.

Educir requisitos nuevos e innovadores, con la técnica de asistencia de lluvia de ideas,

para representar mejoras frente a lo que se ha especificado o adicionar funcionalidades

básicas que se pasaron por alto y/o mejoran la calidad y rendimiento de la aplicación.

C) Requisitos Funcionales

Ref. Prioridad Descripción Requisito Fuente de

Información.

RF-1 Alta

Registro de usuario: El sistema debe permitir a un

realizar un registro en el Sistema. Los datos de

registro serán: Nombre de usuario, correo y

contraseña.

Restricciones: Todos los datos del registro son

obligatorios.

Director de

tesis.


RF-2 Media

Notificación usuario: El sistema debe de notificar al

Usuario, al correo que él suministró en el registro, que

su cuenta ha sido creada satisfactoriamente.

Equipo de

desarrollo.

RF-3 Baja Modificación usuaria: El sistema permitirá a un

usuario modificar su nombre y/o contraseña.

Equipo de

desarrollo.

RF-4 Media

Registro rol usuario: El sistema le asignará por defecto

el rol “Usuario” a un usuario que se haya registrado

satisfactoriamente.

Equipo de

desarrollo.

RF-5 Baja Inactivación de Usuario: El sistema permitirá

inhabilitar un Usuario, al rol “Administrador”

Equipo de

desarrollo.

RF-6 Media

Validación inactivación de usuario: El sistema no

permitirá inactivar un usuario si tiene Repositorios

activos

Equipo de

desarrollo.

RF-7 Baja Inactivación de Repositorio: El sistema permitirá

inhabilitar un Repositorio, al rol “Administrador”

Equipo de

desarrollo.

RF-8 Media

Validación inactivación de Repositorio: El sistema no

permitirá inactivar un Repositorio si tiene procesos de

negocio activos.

Equipo de

desarrollo.

RF-9 Alta

Creación de repositorios: El sistema permitirá crear

un Repositorio a los roles “Usuario” y

“Administrador”. Los datos para la creación son

Nombre y Descripción.


obligatorios.

Director de

tesis.

RF-10 Alta Cargar proceso de negocio: El sistema permitirá

cargar un proceso de negocio a los roles “Usuario” y

Director de

tesis.


“Administrador”. Los datos para la creación son un

Archivo y Descripción.


obligatorios. El proceso de negocio tiene que ser

cargado a un Repositorio y solo puede ser cargado a

un Repositorio que pertenezca al Usuario o

Administrador

RF-11 Alta

El sistema deberá extraer la información textual y

estructural de un proceso de negocio y deberá

almacenar está información en un índice.

Director de

tesis.

RF-12 Media

El sistema permitirá realizar búsquedas textuales

sobre los procesos de negocio almacenados en el

índice.

Director de

tesis.

RF-13 Media

El sistema permitirá realizar búsquedas estructurales

sobre los procesos de negocio almacenados en el

índice.

Director de

tesis.

RF-14 Alta

El sistema permitirá ejecutar el algoritmo de

clustering K-MEANS sobre el índice de los procesos de

negocio almacenados.

Director de

tesis.

RF-15 Baja

El sistema no permitirá crear, modificar o inactivar los

Roles definidos para el sistema. Los roles definidos

son “Usuario” y “Administrador”

Equipo de

desarrollo.

Tabla 10: Requisitos funcionales


D) Requisitos No Funcionales

Ref. Descripción

Requisito

Escalabili

dad

Extensibil

idad

Rendim

iento

Usabili

dad

Manten

ibilidad

Segurida

d

RFN-1

La plataforma debe

funcionar en

navegadores de

escritorio que

soporten HTML5

x

RFN-2

La interfaz de usuario

debe ser consistente

en toda la plataforma

x

RFN-3

Las interfaces de

comunicación deben

seguir los protocolos

comunes a los

estándares web

x

x

RFN-4

Solo los usuarios

registrados podrán

ingresar al sistema con

su usuario y

contraseña

x

RFN-5 La plataforma debe

estar documentada x

RFN-6

La plataforma debe

permitir el desarrollo

futuro de nuevas

funcionalidades

x

Tabla 11: Requisitos no funcionales


VII. RESULTADOS

A) Componentes de la aplicación

Ilustración 12: Componentes de la plataforma web

Descripción:

Adicionar/Modificar: Interfaz gráfica del usuario mediante la cual se puede hacer gestión de

los modelos de procesos de negocio nuevos o existentes dentro de la plataforma.

Gestión: Este componente permite gestión sobre los modelos de proceso de negocio, en

formato XPDL que representan los modelos de BPMN.


Almacenamiento: Este componente es la unidad central de almacenamiento. Es una base de

datos relacional donde se almacenan los archivos adicionados y la información procesada de

los mismos.

Procesamiento: Se encarga de convertir la información textual de los modelos de proceso de

negocio a un formato estándar, elimina caracteres inválidos, espacios en blanco, etc.

Análisis textual: En este proceso se recorre de manera secuencial la estructura en árbol de los

archivos XPDL donde se describe cada modelo de proceso de negocio. El proceso del análisis

textual inicia tomando cada actividad y extrayendo sus características principales, formando

así, un conjunto textual con la información relevante At(nombre actividad, tipo actividad y

descripción), como se representa en la figura 17, y posteriormente formando un vector con

todos los conjuntos (At1, At2,.., Atn).

Ilustración 13: Formato y campos del formato XPDL para representar actividades de

BPMN


Análisis estructural: Este proceso incorpora una estrategia de formación y uso de libros de

códigos llamados “codebooks”, para generar unidades estructurales básicas secuenciales de

los modelos de proceso de negocio. Estos codebooks son construidos con base en las

propiedades de similitud en patrones secuenciales frecuentes en la estructura de cada uno de

los modelos de proceso de negocio [6]. En este paso se ejecutará un algoritmo que analiza la

estructura de los modelos de proceso de negocio almacenados en el repositorio. Al igual que

en el análisis textual, en este proceso se recorre de manera secuencial la estructura en árbol de

los archivos XPDL donde se describe cada modelo de proceso de negocio. En la figura 18, se

representa la forma en la cual son agrupados cada uno de los componentes para representarlos

en los codebooks.

Ilustración 14: Representación de los agrupamientos para realizar el codebook

Donde el resultado del agrupamiento seria el siguiente: [StartEvent_Task1, Task_Route2,

Route_Task3, Route_Task4, Task_EndEvent5, Task_EndEventError6]

Índice: Este proceso ejecuta un algoritmo el cual permite crear una estructura de datos para

el acceso rápido a la información, algo similar semánticamente a lo que podría ser el índice

de un libro. Se crea un índice el cual contiene la información textual y estructural por cada

modelo de proceso de negocio adicionado. Estas dos formas de indexación se unifican y se


agrupan bajo el concepto de representación multimodal, la cual permite tener una

representación más exacta del objeto de estudio. El índice almacena eficientemente una

estructura conceptual denominada matriz índice de términos por modelos de proceso de

negocio.

Búsqueda/Agrupamiento:

Query – Textual: Hace referencia a la búsqueda textual, o por palabras clave, que permite al

usuario digitar una palabra o conjunto de ellas y estas formaran un vector de consulta textual

el cual será comparado contra la información almacenada en el índice lo cual arrojara como

resultado los modelos de proceso de negocio que tengan similitud con ellas.

Query – Estructural: Hace referencia a la búsqueda estructural, o por componentes, que

permite al usuario seleccionar uno o varios componentes de una lista y estos formaran un

vector de consulta estructural el cual será comparado contra la información almacenada en el

índice lo cual arrojara como resultado los modelos de proceso de negocio que tengan similitud

con ellos.

Query – Multimodal: Este proceso de consulta integra las dos opciones de consulta

anteriores. Para realzar este proceso el sistema forma automáticamente un vector de consulta,

el cual se compara con cada modelo de proceso de negocio registrado en el índice, tomando

las dos zonas o componentes.

Clustering: Se ejecuta el algoritmo de clustering K-MEANS con base a la información textual

y estructural de cada proceso de negocio almacenado dentro del índice.


B) Arquitectura de la aplicación

1) Vista de Procesos

Ilustración 15: Diagrama de actividades: Registro e inicio de sesión


Ilustración 16: Diagrama de actividades: Crear repositorio y/o Cargar PN


Ilustración 17: Diagrama de actividades: Consulta y agrupación de los PN


2) Vista lógica

Ilustración 18: Modelo entidad relación

3) Vista de escenarios

Ilustración 19: Caso de uso: Usuarios


Ilustración 20: Caso de uso: Repositorios

Ilustración 21: Caso de uso: Procesos de negocio


Ilustración 22: Caso de uso: Agrupamiento

C) Patrones de Diseño Implementados

Fachada: Es un tipo de patrón de diseño estructural. Viene motivado por la necesidad

de estructurar un entorno de programación y reducir su complejidad con la división en

subsistemas, minimizando las comunicaciones y dependencias entre estos

Singleton: Es un patrón de diseño diseñado para restringir la creación de objetos

pertenecientes a una clase o el valor de un tipo a un único objeto.

Abstrac Factory: Permite crear, mediante una interfaz, conjuntos o familias de objetos

(denominados productos) que dependen mutuamente y todo esto sin especificar cuál

es el objeto concreto.

Factory Method: Consiste en utilizar una clase constructora (al estilo del Abstract

Factory) abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el

dedicado a la construcción de objetos de un subtipo de un tipo determinado. Es una

simplificación del Abstract Factory, en la que la clase abstracta tiene métodos


concretos que usan algunos de los abstractos; según usemos una u otra hija de esta

clase abstracta, tendremos uno u otro comportamiento.

D) Pruebas y Evaluación de Software

Se abordó una estrategia de diseño de pruebas distribuidas, en casos de pruebas detallados por

cada una de las funcionalidades involucradas en el proceso a evaluar, basándose en los casos

de uso. Se generó un documento de diseño independiente para cada funcionalidad de forma

genérica.

Las variables de prueba y el resultado de la ejecución de las mismas se encuentran en el Anexo

1, Sección: 3.8. Pruebas y Evaluación de Software

E) Tecnologías utilizadas

1) JavaEE

Java Platform Enterprise Edition o Java EE (anteriormente conocido como Java 2 Platform,

Enterprise Edition o J2EE hasta la versión 1.4; traducido informalmente como Java

Empresarial), es una plataforma de programación para desarrollar y ejecutar software de

aplicaciones en el lenguaje de programación Java. Permite utilizar arquitecturas de N capas

distribuidas y se apoya ampliamente en componentes de software modulares ejecutándose

sobre un servidor de aplicaciones.

http://docs.oracle.com/javaee/7/index.html

2) JavaServer Faces

Tecnología y framework para aplicaciones Java basadas en web que simplifica el desarrollo

de interfaces de usuario en aplicaciones Java EE. JSF usa JavaServer Pages (JSP) como la

http://docs.oracle.com/javaee/7/index.html


tecnología que permite hacer el despliegue de las páginas, pero también se puede acomodar a

otras tecnologías como XUL (acrónimo de XML-based User-interface Language, lenguaje

basado en XML para la interfaz de usuario).

http://www.oracle.com/technetwork/java/javaee/documentation/index-137726.html

3) PrimeFaces 6.0

Biblioteca de componentes para JavaServer Faces (JSF) de código abierto que cuenta con un

conjunto de componentes enriquecidos que facilitan la creación de las aplicaciones web.

Primefaces está bajo la licencia de Apache License V2.

https://www.primefaces.org/docs/guide/primefaces_user_guide_6_0.pdf

4) Spring Framework 4.3.8

Framework para el desarrollo de aplicaciones y contenedor de inversión de control, de código

abierto para la plataforma Java.

https://projects.spring.io/spring-framework/

5) Hibernate 5.2.5

Herramienta de mapeo objeto-relacional que facilita el mapeo de atributos entre una base de

datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos

declarativos (XML) o anotaciones en los beans de las entidades que permiten establecer estas

relaciones.

http://hibernate.org/orm/documentation/5.2/

http://www.oracle.com/technetwork/java/javaee/documentation/index-137726.html

https://www.primefaces.org/docs/guide/primefaces_user_guide_6_0.pdf

https://projects.spring.io/spring-framework/

http://hibernate.org/orm/documentation/5.2/


6) Spring Security 4.2.0

Spring Security es un marco que se centra en ofrecer autenticación y autorización a las

aplicaciones Java, gestiona todo lo relativo a la seguridad de la aplicación web, el protocolo

de seguridad, hasta los roles que necesitan los usuarios para acceder a los diferentes recursos

de la aplicación.

http://docs.spring.io/spring-security/site/docs/current/apidocs/

7) Slf4j 1.7.21

El Simple Logging Facade for Java (SLF4J) sirve como una simple fachada o abstracción para

varios marcos de registro (por ejemplo, java.util.logging, logback, log4j) que permite al

usuario final conectar el marco de registro deseado en el momento de la implementación.

https://www.slf4j.org/manual.html

8) Log4j2 2.7

Es una librería adicional de java que permite a nuestra aplicación mostrar mensajes de

información de lo que está sucediendo en ella, lo que habitualmente se conoce como un log.

Tiene la ventaja de ser dinámico y, por tanto, configurable.

https://logging.apache.org/log4j/2.x/

9) Lucene 30

Apache Lucene es una API de código abierto para recuperación de información, originalmente

implementada en Java por Doug Cutting. Está apoyado por el Apache Software Foundation y

se distribuye bajo la Apache Software License. Lucene tiene versiones para otros lenguajes

http://docs.spring.io/spring-security/site/docs/current/apidocs/

https://www.slf4j.org/manual.html

https://logging.apache.org/log4j/2.x/


incluyendo Delphi, Perl, C#, C++, Python, Ruby y PHP. Es útil para cualquier aplicación que

requiera indexado y búsqueda a texto completo. Lucene ha sido ampliamente usado por su

utilidad en la implementación de motores de búsquedas.

El centro de la arquitectura lógica de Lucene se encuentra el concepto de Documento

(Document) que contiene Campos (Fields) de texto. Esta flexibilidad permite a Lucene ser

independiente del formato del fichero. Textos que se encuentran en PDF, páginas HTML,

documentos de Microsoft Word, archivos XML, etc., pueden ser indexados mientras que se

pueda extraer información de ellos.

https://lucene.apache.org/core/3_0_3/api/core/org/apache/lucene/util/Version.html

10) PostgreSQL 9.4

Es un Sistema de gestión de bases de datos relacional orientado a objetos y libre, publicado

bajo la licencia PostgreSQL.

https://www.postgresql.org/docs/9.4/static/release-9-4.html

11) Angular 2

AngularJS es un framework MVC de JavaScript para el Desarrollo Web Front End que

permite crear aplicaciones SPA Single-Page Applications.

https://angular.io/

https://lucene.apache.org/core/3_0_3/api/core/org/apache/lucene/util/Version.html

https://www.postgresql.org/docs/9.4/static/release-9-4.html

https://angular.io/


VIII. DISCUSIÓN

A) Análisis de impactos

La propuesta de ingeniería discutida en el presente documento tiene diferentes impactos en el

escenario en el cual se contextualiza el problema, desde las siguientes perspectivas:

Ambiental: La centralización del almacenamiento y procesamiento de los datos en

servidores accesibles a través de Internet implica que cada organización no debe manejar

sus propios equipos físicos para estos objetivos, que a su vez influye positivamente en un

mejor aprovechamiento de los recursos energéticos que conlleva el almacenamiento y

procesamiento de información.

Social: Las organizaciones serán las principales beneficiadas con la propuesta desarrollada

pues en consecuencia se verán reflejadas mejoras en sus procesos de negocio, que a su vez

pueden impulsar a las organizaciones como generadoras de empleos dentro de la sociedad.

Económica: Como se mencionó en la perspectiva ambiental, las organizaciones pueden

migrar sus repositorios a una herramienta web y rescindir de grandes equipos

computacionales y sus gastos de operación y mantenimiento, además, las mejoras en los

procesos de búsqueda de proceso de negocio permiten ahorrar tiempo y generar nuevos

procesos de negocio más rápidamente, lo que se traduce en valor agregado y finalmente en

capital para las organizaciones.

Técnica: El enfoque académico con el que se desarrolló la plataforma web permiten afirmar

que ésta estará disponible para su uso mediante la infraestructura que disponga la

Universidad de San Buenaventura Cali para este fin, garantizando la longevidad de la

información allí contenida y procurando por la innovación a través de sus grupos de

investigación.

Individual: Las personas encargadas de gestionar los PN dentro de sus organizaciones se

verán beneficiadas a nivel individual, pues la plataforma web proporciona herramientas que

agilizan la búsqueda de PN y les permiten ser más eficientes en su trabajo.


B) Experiencia de diseño en ingeniería de software

Lo presentado en las secciones de Análisis de Impactos, Utilización de herramientas y Análisis

de diseño de componentes se argumenta como una evidencia de que, a lo largo del proceso de

formación de la carrera de ingeniería de sistemas, que culmina con esta experiencia de proyecto

de grado, se lograron alcanzar los siguientes resultados de aprendizaje:

Una habilidad para para entender el impacto de soluciones de ingeniería en un contexto

global, económico, ambiental y social.

Una habilidad para identificar, analizar, seleccionar e integrar técnicas y herramientas de

ingenierías para las prácticas de ingeniería.

Una habilidad para para diseñar un sistema, componente o proceso dando soluciones a

necesidades, en un contexto dado.


XI. CONCLUSIONES

Cumplimiento con lo establecido en los objetivos del proyecto.

El tiempo de respuesta de las consultas de los modelos de proceso de negocio se ve reducido

significativamente comparándolo contra consultas directas a la base de datos o búsqueda

de información dentro de un repositorio.

La investigación en diferentes áreas permite el fortalecimiento de las capacidades en los

ámbitos de la ingeniera de software.

Familiarizarse con este tipo de metodologías para el análisis de la información permite tener

una visión más profunda de las problemáticas que pueden solventarse con la ingeniería de

software.


XII. RECOMENDACIONES

Adicionar a la opción de procesamiento más formatos de archivos, debido a que la

aplicación únicamente trabaja con XPDL. Se podría adicionar en los formatos de entrada

el archivo BPMN directamente.

Calculo de las distancias entre los puntos del clúster con más formulas aparte de la

euclidiana.


REFERENCIAS

[1] H. Ordoñez, J. Corrales y C. Cobos, «Business Processes Retrieval Based on Multimodal

Search and Lingo Clustering Algorithm,» 2015.

[2] H. Ordoñez, J. Corrales y C. Cobos, «MultiSearchBP: Entorno para búsqueda y

agrupación de modelos de procesos de negocio,» 2014.

[3] The Apromore Initiative, «Apromore,» 2016. [En línea]. Available:

http://apromore.org/.

[4] Object Management Group (OMG). (2011). Business Process Model and Notation

(BPMN) Version 2.0. Business, 50(January), 170. https://doi.org/10.1007/s11576-008-

0096-z

[5] PRESSMAN, R. Software Engineering: a practitioner’s approach, 6th ed. McGraw Hill,

New York, 2005.

[6] Ordoñez, H., Corrales, J. C., & Cobos, C. (2014). MultiSearchBP: Entorno para la búsqueda y agrupación de modelos de procesos de negocio.

[7] Workflow Management Coalition. (2014). XPDL - Workflow Management Coalition. Retrieved from http://www.wfmc.org/standards/xpdl

[8] ¿Que es el Clustering? Moya 2016. Retrieved from https://jarroba.com/que-es-el-clustering/

[9] http://www.betametrica.com.ec/2015/05/07/cluster-centroides-aglomeracion-es-solo-cuestion-de-distancias-y-separaciones/

[10] González, C. P. (2011). Departamento de Estadística e Investigación Operativa.

[11] M. Search et al., “Cumulative and No-Continuous N-Grams,” no. January 2017, 2016.Construcción de la arquitectura de la plataforma.

[12] Distancia euclídea - EcuRed. Retrieved from https://www.ecured.cu/Distancia_euclídea

https://doi.org/10.1007/s11576-008-0096-z

https://doi.org/10.1007/s11576-008-0096-z

http://www.wfmc.org/standards/xpdl

https://jarroba.com/que-es-el-clustering/

http://www.betametrica.com.ec/2015/05/07/cluster-centroides-aglomeracion-es-solo-cuestion-de-distancias-y-separaciones/

http://www.betametrica.com.ec/2015/05/07/cluster-centroides-aglomeracion-es-solo-cuestion-de-distancias-y-separaciones/

https://www.ecured.cu/Distancia_euclídea


[13] Huguenard, J. (2015). Error Sum of Squares. Stanford University School of Medicine. Retrieved from http://hlab.stanford.edu/~brian/error_sum_of_squares.html

[14] Navarrete, F. J. (2014.). DBSCAN.

[15] Cárdenas Montes, M. (2013). Clustering: Clasificación no Supervisada. Retrieved From http://wwwae.ciemat.es/~cardenas/curso_MD/clustering.pdf

http://hlab.stanford.edu/~brian/error_sum_of_squares.html

http://wwwae.ciemat.es/~cardenas/curso_MD/clustering.pdf


ANEXOS

Anexo 1. Reporte técnico de la investigación

Plantilla_Reporte Tecnico_Trabajo de Grado_2017-I.docx

plataforma para la agrupación de modelos de procesos de

Documents