You are on page 1of 109

Notaciones y lenguajes de procesos. Una visi´ on global.

Juan Diego P´ erez, 25179398X jdperez.averroes@juntadeandalucia.es

Supervised by Prof. Dr. Amador Dur´ an Toro

Research Report submitted to the Department of Computer Languages and Systems of the University of Sevilla in partial fulfilment of the requirements for the degree of Ph.D. in Computer Engineering. (Research Period)

´ Indice general
1. Introducci´ on 1.1. Motivaciones y objetivos . . . . . . . . . . . . . . . . . . . . . . . 1.2. Contexto de la investigaci´ on . . . . . . . . . . . . . . . . . . . . . 1.3. Estructura de este documento . . . . . . . . . . . . . . . . . . . . 2. Diagramas de Actividad 2.1. ¿Qu´ e son los Diagramas de Actividad? . . . . . 2.2. Elementos de los Diagramas de Actividad . . . 2.2.1. Nodos de Acci´ on . . . . . . . . . . . . . 2.2.2. Flujos . . . . . . . . . . . . . . . . . . . 2.2.3. Nodos de Control . . . . . . . . . . . . . 2.2.4. Nodos Objeto . . . . . . . . . . . . . . . 2.2.5. Particiones . . . . . . . . . . . . . . . . 2.2.6. Regiones de Expansi´ on . . . . . . . . . . 2.2.7. Excepciones . . . . . . . . . . . . . . . . 2.2.8. Regiones de Actividad Interrumpibles . 2.2.9. Streaming . . . . . . . . . . . . . . . . . 2.3. Herramientas para Diagramas de Actividad . . 2.4. Conclusiones sobre los Diagramas de Actividad 2.5. Ejemplos de Diagramas de Actividad . . . . . . 3. SPEM 3.1. ¿Qu´ e es SPEM? . . . . . . . . . . . . 3.2. Metamodelo de SPEM . . . . . . . . 3.2.1. SPEM Core . . . . . . . . . . 3.2.2. SPEM Process Structure . . 3.2.3. SPEM Process Behavior . . . 3.2.4. SPEM Managed Content . . 3.2.5. SPEM Method Content . . . 3.2.6. SPEM Process With Methods 3.2.7. SPEM Method Plug-In . . . 3.3. SPEM 2.0 como perfil. . . . . . . . . 3.4. Conclusiones sobre SPEM . . . . . . 3.5. Ejemplos en SPEM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 3 5 6 6 7 8 8 9 10 11 11 12 13 13 14 15 16 17 17 18 19 20 22 22 22 24 26 27 30 32

i

4. BPMN 4.1. ¿Qu´ e es BPMN? . . . . . . . . . . . . . . . . . . . 4.2. Modelos en BPMN . . . . . . . . . . . . . . . . . . 4.2.1. Procesos de negocio privados(internos) . . . 4.2.2. Procesos de negocio abstractos (p´ ublicos) . 4.2.3. Procesos de colaboraci´ on (globales) . . . . . 4.3. Diagramas BPMN . . . . . . . . . . . . . . . . . . 4.3.1. Elementos b´ asicos de los diagramas BPMN 4.3.2. Variaciones de los elementos b´ asicos . . . . 4.4. Herramientas BPMN . . . . . . . . . . . . . . . . . 4.5. Conclusiones sobre BPMN . . . . . . . . . . . . . . 4.6. Ejemplos de Diagramas en BPMN . . . . . . . . . 5. XPDL 5.1. ¿Qu´ e es XPDL? . . . . . . . . . . . . . 5.2. El metamodelo XPDL . . . . . . . . . 5.2.1. Metamodelo Package . . . . . . 5.2.2. Metamodelo Process . . . . . . 5.3. Entidades b´ asicas de los metamodelos 5.4. Herramientas XPDL . . . . . . . . . . 5.5. Conclusiones sobre XPDL . . . . . . . 5.6. Ejemplos en XPDL . . . . . . . . . . . 6. jBPM y jPDL 6.1. ¿Qu´ e son jBPM y jPDL? . . . . 6.2. Arquitectura de jBPM . . . . . . 6.3. Modelando gr´ aficamente procesos 6.4. jPDL . . . . . . . . . . . . . . . . 6.5. Conclusiones sobre jBPM-jPDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35 35 36 36 36 36 38 38 41 43 44 46 47 47 49 50 51 51 52 53 55 57 57 57 58 60 63 65 65 65 66 66 69 69 70 72 72 72 73 73 74 74 76 76 77 77 79

. . . . . . . . . . . . . . . . . . . . . . . . . . de negocio con jBPM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . de Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7. ARIS 7.1. ¿Qu´ e es ARIS? . . . . . . . . . . . . . 7.2. Arquitectura de ARIS . . . . . . . . . 7.2.1. Vistas descriptivas . . . . . . . 7.2.2. Niveles descriptivos . . . . . . . 7.3. Function View . . . . . . . . . . . . . 7.3.1. Requirements Definition . . . . 7.3.2. Design Specification . . . . . . 7.3.3. Implementation . . . . . . . . . 7.4. Data View . . . . . . . . . . . . . . . . 7.4.1. Requirements Definition . . . . 7.4.2. Design Specification . . . . . . 7.4.3. Implementation . . . . . . . . . 7.5. Organization View . . . . . . . . . . . 7.5.1. Requirements Definition . . . . 7.5.2. Design Specification- Topolog´ ıa 7.5.3. Implementation . . . . . . . . . 7.6. Control View/Process View . . . . . . 7.6.1. Requirements Definition . . . . 7.6.2. Design Specification . . . . . .

ii

. . . . .2. . . . . . . . . . . . . 8.2. . Referents . 8.6. 8. . . . . . . . Links . . . . . . . 8. . Curriculum vitae iii . . . . . Unidad de trabajo . . 8. . . . . .6. . . . . . . . 8. . . . . Conclusiones sobre IDEF . . . . . . . . . . . . Comparativa de las notaciones presentadas 10. . . . . . . . .7. IDEF 8.Access Diagram (Physical) . 79 80 82 83 83 84 87 87 87 88 89 90 90 91 92 94 97 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . .1. . . . . . .3. . . Elementos de IDEF3 . .Conclusiones y Trabajo Futuro A. .5. 8. . . . . . . . . . . . . . . . . . . ¿Qu´ e es IDEF? . . . . 8. . . . . . . . . 8. . . . . . . . . . . . . Conclusiones sobre ARIS . . .3. 7. . . . . . . . . . .4. . . . .1. . . . .7. . . . . . . Herramientas para IDEF0 e IDEF3 8. . . . . . Ejemplos sobre IDEF .4. . . . . . . . . . . . . .3. . . . . . . . 7. . . . . . . . . . . . . Elementos de IDEF0 . . .3. . . . .3. . . . . . . . . . . . . .3. . . . . . . . . .8. . . . Product/Service View . . . . . . . . . . . . Conexiones . . . . . . . . . . . . . . . . . . . . . . . .3. . . . . . Implementation. . . . .

. . . . . 3.9. . . . . . . . . . . . . . . . . . 2. . . . .4. . . . . . . . . . . . . . . . . . . . . . . . Diagrama en BMPN. . . Tipos de flujos. .7. . . . . . Ejemplo de utilizaci´ on de excepciones . . 3.13. . . . 2. .10. . . . . . Ejemplo de Regi´ on de Expansi´ on Iterativa .7. . . . . . . . . . . . .7. . . . . . . . .0 Diagrama detallado de una actividad . . . 3. . 2. SPEM 2. SPEM 2. . . Proceso de negocio abstracto . . . . . 3. . . . 3. . . SPEM 2.0. . . Combinaci´ on Merge/Decision .2. iv .0 Metamodelo del Paquete Process Structure . .8. . . 3.2. .0 Work Definition y sus relaciones . 6 8 9 9 10 10 11 12 12 13 13 14 16 18 19 21 23 24 25 27 27 31 32 33 34 34 36 37 37 41 42 46 46 Paquetes del metamodelo de SPEM 2. SPEM 2. . 4. . . .3. 4. . . .0 Estructura del paquete Process With Methods .1. . . . . . . . . . . SPEM 2. .8. . . . . . . 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SPEM 2. . . . . SPEM 2. .0 Situaci´ on del perfil y del metamodelo dentro de los niveles de abstacci´ on de la OMG. . . . . . . . . .11. .0. . . 2. . . . . . . . . . 2. . . Ejemplo de Actividad y Acciones que la componen. . . .1. . . . . . Ejemplo de acciones que se ejecutan en streaming. . . . Combinaci´ on Fork/Join . Fragmento de la descripci´ on textual de la metodolog´ ıa DMR Macroscope de Fujitsu. 3. . . Diagrama de componentes del equipo. . . . . 4. . . . . .6. . . . . . .0. . . . . . . . . . . . . . . . 4. . 2. . . . . . . . . . . . . . . . . . . SPEM 2. Proceso de colaboraci´ on . . . SPEM 2. . . . 4. . . . . . . . . Paquetes de UML para la descripci´ on de comportamientos 2. . . . . .´ Indice de figuras 2. . 2.5. . . . Regiones de actividad interrumpibles . . . 4. . . 4. . . . . .3. . . . . 2. . . . . . Ejemplos de Diagramas de Actividad . . . . . .2. . . . . . . . . . . . . Tipos de eventos.10.9. . . . . . . . . . 3.12.4. . . . . . . . . .6. . .0 Estructura del paquete Method Plugin . . . . 3. . . . . . . . . .11. . . . .0 Metamodelo del Paquete Managed Content . . . Nodos de Control de los Diagramas de Actividad . . . . . Tipos de Gateways en BPMN . . . . Proceso de negocio privado . . . . . 3.13. . . Visi´ on detallada del proceso de voto electr´ onico . . . . . . 3. SPEM 2. .4. . . . . . . . . . .12. 2. 3. . . . SPEM 2. . . . . . . .5. . . . . . . . . . BPMN. . . . . . . . . Nodos Objeto .1. . . . . . . . . . . . 2. . . . . . Proceso de voto electr´ onico. . . . Diagrama de dependencias entre Work Products . .0 . . . . . . . . . . . . . . . . Ejemplo de Partici´ on Bi-dimensional . 3.5.3. . .6. . . . SPEM 2. .0 Metamodelo del paquete Method Content . . Diagrama en BPMN. . . . . .0 Separaci´ on entre definici´ on e implementaci´ on . . .

Diagrama jer´ arquico en IDEF0 . . . . Relaci´ on entre vistas y niveles. . . . . . . . . .20. . . . . . .16. . Descomposici´ on modular de una aplicaci´ on. . . . 7. . . . . . . . .Ejemplo de relaci´ on entre function view y organizational view. ARIS. . . . . ´ 7. . . . ARIS. . . . . . . . Diagrama de Ejemplo en IDEF3 . . . . . 7. . . . . ARIS. . . . . 7. .14. . ARIS. . 7. .7.15. .7. . . 8. . Arboles de Funciones . . . . . . . . . . . . . 7. . . . Gr´ afico BPMN correspondiente al ejemplo no 2 en XPDL . . . Una decisi´ on exclusiva. . . .22. . . . . . . . . . ARIS. . . . . . . . . Unidades b´ asicas de IDEF0 . . . . . . . . . . . . . . . Niveles Descriptivos y sus relaciones. . . . . . . . . . . . Metamodelo Package .13. . 8. . . 8. . . . . . . . . .6. . . . .5. . . . . . . . . . . . . . . 7. . . . . . . . Organizational Chart. . . . ´ 7. . .18. 7. ARIS. . . . . . . 7. . . . . . . . . . . . . . . Plug-In de Eclipse para jBPM . . . . . . . . . . .12. . . ARIS. . . . .2. . . . . . .7. Ejemplo de Product Allocation Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .21. . . . . . . . . . . . . . . . .1. . Ejemplos de Product Selection Matrix Diagram. . Diagrama Y.9. . .11. . 7. . . . . . . 8. 8. . . .4. . . . . . . . . . . . . . . . . .8. . . 5.1. . . Metamodelo Process . . . . . . Aplicaci´ on y m´ odulo en el nivel de implementaci´ on. . . . . .8. . . . . . . 5. IDEF3 Link de Flujo de Ojetos . . . . . . . . . . . . Aplicaci´ on. . . 5. . . . . . . .4. . . . . . . ARIS. . . . . . .1. 7. 7. . . . . . . . Objetivo. Ejemplo Access Diagram Nivel de Dise˜ no . . .2. . . . . . . Relaci´ on Entidad-Relaci´ on-Atributos. . . . .1. . . . 8. . . . . .2. . .19. . . . . . . . ARIS. . . . . . . . Relaci´ on entre XPDL y BPEL . ARIS. . . . Gr´ afico BPMN correspondiente al ejemplo no 1 en XPDL. . .5. . . . . Ejemplo de Process State en jPDL . . . . . . 7. ARIS.3. . . . . ARIS. . . .3. . . . . ARIS. . . . 7. . . . . . . . . . . . ARIS. . . . . . . . . . . . . IDEF3 Link Relacional . . . . . . 48 50 51 54 55 55 56 56 58 62 66 67 68 69 69 70 70 71 71 71 72 73 73 74 74 75 76 77 79 80 81 81 84 86 87 87 88 88 88 91 91 v . . . . . . . .10. . . . . . . . 7. . . . 8. . 7. . . . . . . ARIS. . . Ejemplo XPDL no 2. . 8. . . . . . . .4. . . . . . . . . IDEF3 Link de Precedencia Temporal . . 7. . . . . . . . . . . . . . . . . . . . . . . . . Actividad que comienza tras un evento de mensaje . . . . . . .17. . . . . . . . . . Relaci´ on. . . 7. . . . .2. . . . . . . . . . . . . . 8. . . . . Asignaci´ on de campos a un SGBD concreto. . . . Arbol de Objetivos. .5. . . 5. . . . ARIS. ARIS. . . . Ejemplo XPDL no 1. . . . ARIS.6. . . . . . . . Ejemplo de diagrama EPC . . . . . . . . . . . . ARIS. . . . . . . . . . . 6. . . . Vistas de la arquitectura. . . . . . . ARIS. . .6. . 6. . . . . . . .9. . . . . . . . . 5. . . . . . . . . . . . . . . . . . . . . . . 7. . . . . Ejemplo de Unidad de Trabajo en IDEF3 . . . Network Diagram . 5. . . . . Tabla y campo de tabla. . . . . . . . . ARIS. S´ ımbolo de Funci´ on. . . . . . 7. . . . . . . ARIS. . . . . . . 7. 5. .3. . . . . . . . IDEF3 Ejemplo de Diagrama con conexiones Diagrama de Ejemplo en IDEF0 . . . . . .Relaci´ on BPMN-XPDL . . 5.8. . . . . . . . . . . . . . . . . . . . .

. . . . Objetos de Flujo en BPMN Conectores en BPMN . . . . . .0 . . . . . . . . . . .1. . . . . . 4. 8. . . . . . . Esteretipos del Perfil SPEM 2. . . . . .2. . . . . . . Tipos de divergencia . . . . . . . . . . . . . . . . . . . . . Tipos de convergencia . . . . . . .1. . . . . . . . IDEF3. . . . . . . . . . . . . . . .4. . . . . . . . . 4. . . . . .1. . 4. . Objetos Swinlane en BPMN Artifacts en BPMN . . . . . . . . . . . . . . . . Elementos de EPC . . . . . . . . Comparativa de notaciones . . . .3. 8. . . . IDEF3. . . . . . . . . .´ Indice de cuadros 3. . . . .1. . . . .2. . . . . . . . . . . 4. . . . . 29 38 39 39 40 78 89 89 93 7. . . . . . vi . . . . . . . . . . . . . . .1. . . . . . . . 9. . .

en especial a mi supervisor. Amador Dur´ an por su paciencia. Antonio Ruiz por ser fuente inagotable de informaci´ on y al profesor Carlos M¨ uller por estar siempre que se le necesit´ o. Y por supuesto. Dr. que no se pone celosa de una m´ aquina. al Dr. vii .Reconocimientos A todo el departamento de Lenguajes y Sistemas Inform´ aticos de la Universidad de Sevilla por su inestimable ayuda. orientaci´ on e ideas. a Zahira.

el uso de esta t´ ecnica es relativamente reciente dentro del ´ ambito de la Ingenier´ ıa del Software. Sin embargo. adem´ as se est´ a utilizando como elemento de comunicaci´ on durante la elicitaci´ on de requisitos y como elemento fundamental dentro de enfoques como MDD (Model Driven Engineering) que buscan una paulatina automatizaci´ on del proceso de desarrollo. Su objetivo principal siempre ha sido la b´ usqueda de costes y tiempos ´ optimos. el de la Ingenier´ ıa del Software. El objetivo de este trabajo es repasar las notaciones y lenguajes de procesos m´ as difundidos. realizar una comparativa de ´ estos e introducir algunas herramientas que nos permitan trabajar con ellos. Su aplicaci´ on dentro de este campo.Resumen Las notaciones y lenguajes de procesos llevan ya varias d´ ecadas us´ andose en numerosos campos de la industria. . no s´ olo se limita al intento de optimizar el proceso de desarrollo software en s´ ı mismo.

Cap´ ıtulo 1

Introducci´ on
El presente documento es la memoria de investigaci´ on correspondiente al periodo investigador del programa de doctorado “Tecnolog´ ıa e Ingenier´ ıa de Software“ de la Universidad de Sevilla. El punto de partida para la elaboraci´ on fue el trabajo de investigaci´ on ”Definici´ on de modelos de procesos de desarrollo para f´ abricas BDD/SOA”propuesto por el departamento de Lenguajes y Sistemas Inform´ aticos.Este trabajo de investigaci´ on propon´ ıa en un principio el siguiente programa: Estudio de las diferentes notaciones para la definici´ on de procesos, en especial SPEM. Estudio de herramientas de software libre y/o propietario para el dise˜ no de modelos de procesos. Estudio del modelo de desarrollo de F´ abricas BDD/SOA que se quiere especificar. Aplicaci´ on de la notaci´ on SPEM al modelo estudiado en el apartado anterior. Al abordar ya el primero de los puntos del programa se pudo comprobar la gran cantidad de lenguajes y notaciones existentes, la gran cantidad de nuevos conceptos que se deb´ ıan asimilar y la gran cantidad de literatura a revisar y por ello se opt´ o por la modalidad de An´ alisis de Bibliograf´ ıa que est´ a pensada para aquellos, que como el autor de esta memoria, carecen de resultados investigadores pero que sin embargo han realizado un importante esfuerzo para comenzar a encauzar su investigaci´ on mediante un profundo an´ alisis de la bibliograf´ ıa. En este cap´ ıtulo presentamos esta memoria de investigaci´ on. En su primer apartado expondremos cu´ ales han sido los motivos y objetivos que la han guiado, en el segundo daremos una visi´ on global sobre el contexto de esta investigaci´ on y sobre la situaci´ on actual del modelado y definici´ on de procesos de negocio dentro del mundo del desarrollo del software y en el u ´ltimo apartado describiremos la estructura del resto de este documento.

1

1.1.

Motivaciones y objetivos

En la actualidad la situaci´ on econ´ omica mundial esta dominada por aspectos como la globalizaci´ on, que conlleva la deslocalizaci´ on de las empresas, la b´ usqueda constante de una reducci´ on de costes para maximizar los beneficios, por continuas fusiones y adquisiciones de empresas y por una b´ usqueda constante de la mejora y optimizaci´ on de todos los procesos. Las tecnolog´ ıas de la informaci´ on van de la mano (no se sabe muy bien quien tira de quien) de las tendencias econ´ omicas globales y nos encontramos con un panorama donde la situaci´ on est´ a determinada por los siguientes aspectos: Lucha entre las tendencias centralizadoras y descentralizadoras. ´ Exito de tecnolog´ ıas como los servicios web y SOA. La importancia de la integraci´ on de aplicaciones, que en algunos casos se convierte en el aspecto m´ as importante y complejo del desarrollo. La existencia de una gran cantidad de plataformas (estamos en la era del todo conectado), lo que, si no se toman medidas dispara enormemente los costes de los desarrollos. Traducido a t´ erminos m´ as t´ ecnicos y centr´ andonos en el marco de los desarrollos software nos damos cuenta de que la industria del software se encuentra en un estado de transici´ on. Tecnol´ ogicamente estamos en el fin de la era web tal y como la conocemos ya que el navegador web no es un cliente viable para todo tipo de aplicaciones. Arquitect´ onicamente los sistemas han llegado a un grado de complejidad enorme en donde los bordes entre las diferentes partes son difusos y en donde los esfuerzos por integrar las aplicaciones constituyen muchas veces la parte m´ as importante de los costes. A la vez las necesidades de los clientes son cada d´ ıa m´ as complejas y piden aplicaciones mucho m´ as generalistas (sin bordes), que aseguren el ´ exito comercial, con ciclos de desarrollo cada vez m´ as cortos, con presupuestos cada vez m´ as bajos, con la posibilidad de reingenier´ ıa para adaptarse a los continuos cambios de las empresas y que adem´ as permitan gestionar gran cantidad de datos y realizar actividades complejas.Todo esto nos conduce a una globalizaci´ on de la informaci´ on y los procesos. En este marco est´ an tomando cada vez m´ as importancia actividades como el modelado y el an´ alisis de procesos de negocio. Un proceso de negocio es un conjunto de actividades relacionadas dentro de una organizaci´ on que tienen como objetivo conseguir un determinado resultado. La gesti´ on de estos procesos, BPM (Business Process Management), conlleva una serie de actividades de las cu´ ales las m´ as importantes son: 1. La definici´ on de los procesos, normalmente mediante una notaci´ on formal, y la creaci´ on del correspondiente modelo. 2. La configuraci´ on de los procesos como paso previo a su ejecuci´ on. 3. La ejecuci´ on y/o simulaci´ on de los mismos. 4. El control y an´ alisis de las distintas ejecuciones.

2

Los modelos de procesos de negocio se usan para mejorar la comunicaci´ on tanto entre el analista y el desarrollador como entre el analista y el ciente, se est´ an utilizando para analizar el comportamiento de procesos de desarrollo de software con el objetivo de comprobar cu´ ales son las causas de el retraso en las fecha de entrega y que alternativas existen para reducir los costes y adem´ as, se est´ an empezando a utilizar para integrar la definici´ on, el modelado y el an´ alisis de procesos dentro de las metodolog´ ıas de desarrollo que tienen un enfoque MDD/MDA(Model Driven Development/Model Driven Architecture) [13] con el objetivo de ir automatizando, poco a poco, y en la medida de lo posible, el desarrollo de productos software dentro de un dominio determinado. Los objetivos de esta memoria, una vez se opt´ o por la modalidad de revisi´ on bibliogr´ afica, son: Adquirir una visi´ on global sobre el estado del arte en el mundo del modelado y definici´ on de procesos de negocio y conocer la situaci´ on de la industria en ese campo detectando las ´ areas en las que se est´ a poniendo en pr´ actica esta t´ ecnica. Profundizar en el conocimiento de las las notaciones y lenguajes m´ as relevantes con el prop´ osito de distinguir los diferentes enfoques existentes y las caracter´ ısticas diferenciadoras. Familiarizarse con la utilizaci´ on de herramientas que soporten las notaciones descritas a lo largo de la memoria. Sentar las bases para afrontar con garant´ ıas futuros trabajos de investigaci´ on en este ´ area.

1.2.

Contexto de la investigaci´ on

La investigaci´ on sobre la definici´ on formal y el modelado de procesos de negocio dentro del marco descrito en el apartado anterior constituye una tendencia actual de cuyo universo forman parte: Los grupos de trabajo sobre workflow. Los est´ andares y lenguajes de workflow. Las metodolog´ ıas de modelado de procesos. Los patrones de workflow. Existen numerosos grupos de investigaci´ on que desarrollan su trabajo en este ´ area aunque debemos destacar los siguientes: OMG. Object Management Group. WfMC. Workflow Management Coalition. BPMI. Business Process Management Initiative. BPMG. Business Process Management Group. ebXML. UN/CEFACT and OASIS. 3

Se han elegido por ser los m´ as usados dentro del la industria. ARIS-EPC. XPDL. En cuanto a los lenguajes y est´ andares que nos van a permitir realizar modelos de procesos de negocio destacamos: Diagrama de Actividad de UML. Workflow and Reengineering International Association. XML Workflow Definition Language. por ser los que m´ as ´ exito est´ an teniendo comercialmente o por ser los que est´ an apoyados por organismos que tiene un gran peso dentro del ´ ambito de la ingenier´ ıa del software o del modelado y definici´ on de procesos. Estos patrones nos van a ayudar a describir los comportamientos de los procesos. ICAM Definition Language. la interacci´ on entre los diferentes procesos y van a permitir a los desarrolladores construir modelos y documentarlos de forma eficiente. destacando Eindhoven University of Technology. IDEF. jBPM-jPDL. Han sido aceptados por la comunidad investigadora. Se han elegido porque. Orientados a recurso: Se centran en la utilizaci´ on y distribuci´ on de los recursos que son necesarios para llevar a cabo la realizaci´ on del proceso.Universidades. Presentan el nivel de abstracci´ on adecuado para comparar las caracter´ ısticas de los lenguajes y notaciones de modelado de procesos de negocio. Dependiendo de las metodolog´ ıas y estrategias empleadas pueden clasificarse en : Orientados a proceso: Se centran en las diferentes tareas a completar para llevar a cabo un proceso completo. Orientados a datos: Se centran en la definici´ on de los datos y en las transformaciones que sufren ´ estos a los largo del proceso. Son comprensibles por los profesionales de la inform´ atica. BPMN. Event-Driven Process Chain. WARIA. jBOSS Process Definition Language. tal y como se concluye en [29]: Est´ an ampliamente difundidos. Los patrones de workflow [32] surgen de la investigaci´ on de Wil van der Alst de la Eindhoven University of Technology y son la herramienta principal que hemos utilizado en esta memoria de investigaci´ on para el an´ alisis de la expresividad de las diferentes notaciones presentadas. Businees Process Moedeling Notation. Estos lenguajes y est´ andares no son por casualidad los mismos que los seleccionados para ser analizados posteriormente en esta memoria de investigaci´ on. Software Process Engineering Metamodel. SPEM. Son 20 y se dividen en 6 categor´ ıas: 4 .

1. ya sea la definici´ on o el modelado. principalmente porque son herramientas muy usadas. 5 . MagiDraw 12. la ejecuci´ on o simulaci´ on o el an´ alisis. La respuesta es sencilla. Patrones con m´ ultiples instancias: Comprenden aquellas situaciones en las que puede haber ejecut´ andose varias instancias de una misma actividad dentro de una misma instancia de un proceso.De control b´ asico de flujo: Describen los aspectos elementales del control de flujo de los procesos. la configuraci´ on. De ramificaci´ on avanzada y sincronizaci´ on. Patrones de cancelaci´ on: Para representar la terminaci´ on de actividades e instancias de procesos cuando concurren ciertas circunstancias. ¿Por qu´ e estas herramientas y no otras?. gesti´ on y monitorizaci´ on de los procesos. En esta memoria nos vamos a centrar en la fase de modelado y definici´ on y analizaremos las siguientes herramientas: TIBCO Business Process Studio. Patrones estructurales: Permiten identificar limitaciones estructurales de los procesos. Borland Together Architect 2006. jBOSS jBPM. Patrones basados en estado: Permiten describir situaciones donde el siguiente paso de la ejecuci´ on de la instancia de un proceso viene determinado por el estado de la propia instancia. El cap´ ıtulo noveno hace una comparativa de estas notaciones de acuerdo a una serie de caracter´ ısticas.3. En el cap´ ıtulo d´ ecimo se describen una serie de herramientas para el modelado de procesos de negocio y en el u ´ltimo cap´ ıtulo se desarrollan una serie de conclusiones y se presentan las posibles l´ ıneas de investigaci´ on que podr´ ıa abordar el autor a la hora de realizar su tesis doctoral. en especial aquellas relacionadas con bucles y terminaciones. hay much´ ısimas m´ as herramientas pero muchas de ellas son dif´ ıciles de conseguir y adem´ as tienen unas licencias que son enormemente caras. Soyatec eBPMN. Como resultado de todo este movimiento en el mundo de los procesos de negocio han surgido numerosas herramientas que pretender dar soporte a alguna de las cuatro actividades principales relacionadas con esta rama. Estructura de este documento El resto del trabajo se estructura de la siguiente forma. En los cap´ ıtulos del segundo al octavo se hace una descripci´ on de las notaciones y lenguajes que han sido incluidas en la memoria por su difusi´ on e implantaci´ on dentro de la industria. gratuitas y de f´ acil obtenci´ on. Como ya veremos a lo largo de toda esta memoria.

Cap´ ıtulo 2 Diagramas de Actividad 2. ¿Qu´ e son los Diagramas de Actividad? Los Diagramas de Actividad son uno de los tres diagramas de UML(Unified Modeling Language). Esto unido a la gran difusi´ on de UML justifica 6 .1. Estos paquetes y las relaciones existentes entre ellos se pueden apreciar en la figura 2. junto con los Diagramas de Estado y los Diagramas de Secuencia. Figura 2.1. utilizados para la descripci´ on del comportamiento din´ amico de un sistema. Estos diagramas utilizan clases del metamodelo de UML que se encuentran en los paquetes de la especificaci´ on dedicados a la descripci´ on de comportamientos. flujos de trabajo y procesos de negocio” [10] lo que coincide perfectamente con la tem´ atica de esta memoria de investigaci´ on.1: Paquetes de UML para la descripci´ on de comportamientos El objetivo de estos diagramas es ”describir l´ ogica procedural.

En las redes de Petri una acci´ on comienza a ejecutare u ´nicamente cuando tiene disponibles todas las transiciones o flujos precedente. los nodos.2. Para dar soluci´ on a esta situaci´ on se modific´ o la sem´ antica de los diagramas que pasaron de ser un caso especial de m´ aquina de estados a tener una sem´ antica de Redes de Petri basada en la producci´ on y consumo de tokens por parte de los elementos que conforman el diagrama.[17]. 2.5 a la versi´ on 2. Son transiciones pull. Adem´ as de estos nodos en los Diagramas de Actividad disponemos de otros tipo de elementos y conceptos como: Flujos Particiones Regiones de Expansi´ on Excepciones Regiones de Actividad Interrumpibles Streaming 7 . El paso de la versi´ on 1. Las principal diferencia entre estos dos enfoques es que: En los diagramas o m´ aquina de estados las transiciones se producen autom´ aticamente.la inclusi´ on de esta notaci´ on dentro del presente trabajo. pasando el control al estado siguiente una vez ha acabado el estado anterior. Elementos de los Diagramas de Actividad En la versi´ on actual los Diagramas est´ an compuestos por una serie de elementos fundamentales. Nodos Objeto: Contienen datos de manera temporal a la espera de mover estos datos a lo largo del diagrama. Este gran cambio estuvo motivado por la falta de expresividad de los Diagramas de Actividad que en sus versiones anteriores dejaban sin cubrir muchos de los patrones de workflow [33]. Actualmente UML se encuentra en su versi´ on 2. que se pueden clasificar en: Nodos de Acci´ on: Realizan operaciones con los datos que reciben y pasan el control y datos a otras acciones.1. Tienen lo que se viene a llamar transiciones sin disparadores. o transiciones push.0 supuso una gran revisi´ on donde la parte que m´ as se modific´ o es precisamente aquella que hace referencia a los Diagramas de Actividad [10]. Nodos de Control: Distribuyen el control de la ejecuci´ on y los tokens a lo largo del diagrama.1.

2.2.1.

Nodos de Acci´ on

A la hora de hablar de los nodos de acci´ on tenemos que distinguir dos conceptos fundamentales, actividades y acciones. Actividades: Agrupaciones de acciones que pueden poseer pre y post condici´ on adem´ as de par´ ametros de entrada o de salida. Acci´ on: Son consumidores/productores de token que reciben datos y el control de flujo y traspasan estos elementos a otras acciones. Es la unidad m´ ınima de comportamiento en los Diagramas de Actividad de UML 2.X. Podemos ver en ejemplo de una actividad con par´ ametros y condiciones y las acciones que la componen en la figura 2.2.

Figura 2.2: Ejemplo de Actividad y Acciones que la componen.

2.2.2.

Flujos

En los Diagramas de Actividad tenemos dos tipos de flujos: El flujo de control que nos sirve para modelar el paso de una acci´ on a otra. Tiene la misma notaci´ on que una transici´ on en UML 1.X. El flujo de datos que nos sirve para modelar el paso de informaci´ on de una acci´ on a otra. Podemos ver las distintas formas de modelar estos flujos en la figura 2.3. Adem´ as para cada uno de estos flujos podemos, mediante etiquetas, especificar aspectos como: La multiplicidad: Para indicar el n´ umero de tokens objeto que se consumen cada vez (como m´ aximo o m´ ınimo). El l´ ımite superior: Para indicar el n´ umero de tokens que como m´ aximo se pueden acumular en un flujo debido a que la acci´ on en la que acaba el flujo no consume tokens. El peso: Para indicar cu´ antos tokens de los disponibles consumo. El orden en el que se van a consumir los tokens. 8

Figura 2.3: Tipos de flujos. Los posibles grupos de objetos que entran en una acci´ on. Las transformaciones que van a sufrir los objetos que se pasan de una acci´ on a otro.

2.2.3.

Nodos de Control

Existen distintos tipos de nodos de control que podemos ver en la figura 2.4.

Figura 2.4: Nodos de Control de los Diagramas de Actividad Initial Node: Nodo que recibe el control cuando comienza la ejecuci´ on de una actividad y que pasa inmediatamente dicho control a las acciones sucesivas. Es importante destacar que una actividad puede tener m´ as de un nodo inicial y que si dicho nodo posee m´ as de una transici´ on de salida el control se pasa u ´nicamente a una de dichas transiciones. Decision Node: Gu´ ıan el flujo en una u otra direcci´ on. Esta direcci´ on se decide en tiempo de ejecuci´ on al comprobar las condiciones de cada uno

9

de los flujos salientes. Poseen un u ´nico flujo de entrada y varios flujos de salida que llevan condiciones asociadas. Merge Node: Tiene la misma representaci´ on que el nodo anterior pero a diferencia de este tienen m´ ultiples flujos entrada pero un u ´nico flujo de salida. Pasa de manera inmediata cualquier tipo de flujo que le llegue, ya sea de control o de datos, a su u ´nico flujo de salida, es decir, sirve para juntar varios flujos. Podemos combinar nodos Decision/Merge tal y como podemos apreciar en la figura 2.5.

Figura 2.5: Combinaci´ on Merge/Decision Fork Node: Divide un u ´nico flujo de entrada en varios flujos de salida que se ejecutar´ an de manera concurrente. El control y los datos que llegan a este nodo son duplicados para cada uno de los flujos de salida. Join Node: Para sincronizar m´ ultiples flujos. Tienen la misma notaci´ on que los nodos Fork pero con la diferencia de tener varios flujos de entrada yu ´nico flujo de salida que u ´nicamente se dispara cuando est´ an disponibles todos los flujos de entrada. Podemos combinar nodos Fork/Join tal y como podemos apreciar en la figura 2.6

Figura 2.6: Combinaci´ on Fork/Join Flow Final: Recibe cualquier tipo de flujo, de control o de datos, y no hace nada, es decir destruye todo los tokens que le llegan. No tiene flujos de salida. Activity Final: Al recibir un token acaba con todos los flujos de la actividad.

2.2.4.

Nodos Objeto

Existen distintos tipos de nodos objetos que podemos ver en la figura 2.7. Activity Parameter: Para representar datos de entrada o salida de una actividad completa. La actividad comienza cuando tiene disponibles todos sus par´ ametros de entrada y acaba cuando ha producido todos sus par´ ametros de salida. 10

2. Sirve para representar el paso de tokens de datos de una acci´ on a otra.7: Nodos Objeto Pins: Existen tres formas posibles de representarlos. No tienen sem´ antica de ejecuci´ on y nos van a permitir agrupar acciones de acuerdo a una serie de criterios. Particiones Aunque ya existen en versiones anteriores de la especificaci´ on. las particiones a partir de la versi´ on de UML 2. Acepta los tokens de los flujos de entrada y los pone disponibles a los flujos de salida.5. Almacenan tokens de datos de tal manera que ´ estos no pueden ser borrados y est´ an disponibles para que las acciones posteriores puedan comenzar a usarlos cuando estimen necesario. tal y como podemos apreciar en la figura 2. 2.2.Figura 2. Central Buffer: Sirven para evitar situaciones de carrera cuando los tokens vienen de diferentes fuentes. La actividad o acci´ on se ejecutar´ a una vez por cada uno de los datos de entrada. Data Store: Son los nodos que nos proporciona la nueva especificaci´ on para dar soporte al comportamiento push de los diagramas de actividad anteriores. 2. Esta agrupaci´ on puede hacerse en una o en dos dimensiones. Si el objeto ya se encuentra en el data store es reemplazado.0 tienen m´ as expresividad. iterativa o en stream y se debe tener en cuenta que el conjunto de los objetos de entrada tiene que ser igual que el conjunto de los objetos de salida. en el n´ umero 11 . No se conecta directamente a las acciones si no que lo hace a trav´ es de pins. Regiones de Expansi´ on Las regiones de expansi´ on nos van a permitir realizar una misma acci´ on y/o actividad sobre un conjunto de datos.6. Esta ejecuci´ on puede ser o bien paralela.8 en la que las acciones se han agrupado verticalmente en relaci´ on a la responsabilidad y horizontalmente en relaci´ on al lugar de ejecuci´ on de la acci´ on.

10 12 . Figura 2.9. que se interrumpe al llegar la excepci´ on.7.Figura 2. Excepciones Las excepciones en los Diagramas de Actividad sirven para modelar que tipo de acciones hay que llevar a cabo en caso de que una excepci´ on especificada ocurra durante la ejecuci´ on de un proceso protegido.9: Ejemplo de Regi´ on de Expansi´ on Iterativa 2. Podemos ver un ejemplo de dos formas alternativas de describir este tipo de construcciones en la figura 2.2. Podemos ver un ejemplo de representaci´ on de una regi´ on de expansi´ on en la figura 2.8: Ejemplo de Partici´ on Bi-dimensional y en el tipo de cada uno de ellos.

2. 13 .11 Figura 2.2. Streaming Con los Diagramas de Actividad de UML 2.11: Regiones de actividad interrumpibles 2.8.12.10: Ejemplo de utilizaci´ on de excepciones 2.Para indicar esto en UML tenemos varias notaciones alternativas que podemos ver en la figura 2.Figura 2.9. Para denotar una regi´ on de actividad interrumpible podemos usar una de las dos maneras especificadas en la figura 2. Una acci´ on se dice que tiene una ejecuci´ on de streaming cuando puede producir su salida mientras procesa sus entradas.X tambi´ en podemos modelar un comportamiento de streaming. Regiones de Actividad Interrumpibles Es una regi´ on dentro de la actividad que interrumpe todos sus flujos cuando un token atraviesa sus l´ ımites (delimitados por l´ ınea discontinua) a trav´ es de uno de sus flujos de salida.

Herramientas para Diagramas de Actividad Desde la creaci´ on de UML han surgido innumerables herramientas.Figura 2.3. Las que seg´ un la propia OMG soportan los Diagramas de Actividad que nos ocupan quedan recogidas en [2] y algunas de ellas son: Atportunity Altova UModel JUDE Concept Draw IBM Rational Software Architect EDGE UML Suite Mia-Studio Innovator Magic Draw Select Component Architect MDWorkbench Objecteering Enterprise Architect Power Designer Pattern Weaver Telelogic TAU Visual Paradigm 14 .12: Ejemplo de acciones que se ejecutan en streaming. 2.

15 . la organizaci´ on m´ as importante relacionada con la creaci´ on de est´ andares de software. En primer lugar. los Diagramas de Actividad.2. Lo que si es cierto es que en relaci´ on a los Diagramas de Actividad debemos tener presente algunas cosas: Existen muchas herramientas para trabajar con ellos. Por lo tanto nos encontramos con dos notaciones con el mismo prop´ osito dentro de una misma organizaci´ on. Conclusiones sobre los Diagramas de Actividad UML es la especificaci´ on de software m´ as extendida de OMG. Sobre esta situaci´ on de conflicto y sobre c´ omo la est´ a resolviendo la OMG se habla en el siguiente cap´ ıtulo en el que analizaremos en profundidad BPMN. otra notaci´ on para el modelado de procesos de negocio que tambi´ en es analizada en esta memoria. se ha utilizado para el modelado de procesos de negocio aunque su uso para este tipo de prop´ osito fue muy criticado dada la limitada expresividad de las versiones anteriores [33]. Los desarrolladores tienen gran experiencia utilizando tanto UML como sus Diagramas de Actividad. Existe gran cantidad de procesos de negocio que est´ an modelados usando esta notaci´ on.4. reform´ o por completo los Diagramas de Actividad para conseguir que fueran una notaci´ on con la expresividad adecuada para modelar todo tipo de procesos de negocio [33]. En segundo lugar absorbi´ o a la organizaci´ on BPMI(Business Process Management Initiative)[12] y con ello BPMN. Una de las partes de UML. Para solucionar esta situaci´ on y dada la gran importancia que est´ a tomando el modelado de procesos de negocio en el mundo del desarrollo del software la OMG tom´ o una serie de medidas. tal y c´ omo se ha dicho anteriormente.

13: Ejemplos de Diagramas de Actividad 16 .5.2. Ejemplos de Diagramas de Actividad Figura 2.

La nueva versi´ on. Ensamblado r´ apido de procesos mediante el uso de patrones. Soporte para diferentes modelos de ciclo de vida. Permitir el desarrollo de extensiones para SPEM con el objetivo de que sean usadas por herramientas para conseguir la automatizaci´ on de procesos. Alinear SPEM con los est´ andares emergentes que no sean UML.0 [16]. BPMN que es tambi´ en descrito en este mismo documento.0. Mantenimiento consistente de distintas alternativas de procesos. SPEM 2. como por ejemplo. Tras el desarrollo de la especificaci´ on adem´ as de conseguir los propuesto en [14] se han a˜ nadido a SPEM nuevas capacidades como: Clara separaci´ on de la definici´ on de los m´ etodos de la aplicaci´ on de dichos m´ etodos al desarrollo de un proceso concreto. una versi´ on casi totalmente nueva que intenta solucionar las numerosas cr´ ıticas que aparecieron tras la versi´ on anterior SPEM 1. Mecanismo flexible para dar soporte a la variabilidad y extensibilidad de los procesos. 17 . ¿Qu´ e es SPEM? SPEM (Software Process Engineering Metamodel) es un est´ andar de la OMG [6] cuyo objetivo principal es proporcionar un marco formal para la definici´ on de procesos de desarrollo de sistemas y de software as´ ı como para la definici´ on y descripci´ on de todos los elementos que los componen.0.Cap´ ıtulo 3 SPEM 3. Definir un nuevo SPEM XML Schema que fuera compatible con MOF 2.1 [15] que pr´ acticamente no ha tenido ning´ un soporte por parte de la industria.1. Recientemente se ha publicado la versi´ on draft apdoted (no definitiva) de SPEM 2.se marcaba en sus inicios[14] los siguientes objetivos: Ser compatible con UML 2.0. una especificaci´ on con mucha m´ as expresividad la hora de describir comportamientos [33].

1: Paquetes del metamodelo de SPEM 2. su comportamiento.Utilizaci´ on de los principios de la encapsulaci´ on para conseguir componentes de proceso reemplazables y reusables. Process Structure: Contiene las clases necesarias para la creaci´ on de modelos de procesos.0 relacionados con los usuarios y la organizaci´ on. Estos conceptos son necesarios para construir una base de conocimiento sobre desarrollo que pueda ser utilizada independientemente del proceso o proyecto espec´ ıfico.0 se estructura en 7 paquetes tal y como queda reflejado en la figura 3. Method Content: Contiene los conceptos de SPEM 2.2. Managed Content: Nos va a permitir dotar a nuestros procesos o sistemas de anotaciones y descripciones que no pueden ser expresadas como modelos y que por lo tanto deben ser documentadas y gestionadas como descripciones en lenguaje natural. Process Behavior: Para representar la parte din´ amica de los procesos.0 Estos paquetes nos van a proporcionar las siguientes capacidades: Core: Contiene todas las clases y abstracciones que constituyen la base para el resto de los paquetes del metamodelo. 18 . 3. Metamodelo de SPEM El metamodelo de SPEM 2. Figura 3.1.

Work Definition Performer Map: Es clase abstracta que nos sirve para generalizar la relaci´ on entre aquel que realiza un trabajo y un Work Definition.Process With Methods: Contiene los elementos necesarios para integrar los conceptos del paquete Process Structure con los conceptos y elementos del paquete Content Method. Kind. Parameter Direction Kind. Method Plug-In: Introduce los conceptos para dise˜ nar.2 Work Definition Parameter:: Es una generalizac´ ı´ on de los elementos del proceso que representan par´ ametros de entrada o de salida para un Work Definition determinado.2: SPEM 2. de acuerdo a las necesidades de los usuarios. SPEM Core El paquete SPEM Core constituye. Es uno de los elementos m´ as importantes de la especificaci´ on y su relaci´ on con el resto de las clases la podemos apreciar en la figura 3.2. Work Definition Parameter y Work Definition Performer Map y nos van a permitir dar soporte a dos de las capacidades de SPEM: Crear clasificaciones de las clases de SPEM 2. gestionar y mantener repositorios y librer´ ıas de Methods Content y Procesos. Work Definition. Tener disponibles un conjuntos de clases abstractas para describir el trabajo mediante un proceso SPEM 2.0.1. Sus superclases principales son Extensible Element.0.0. tal y como se dijo en el apartado anterior.0. la base sobre la que se construyen el resto de los paquetes de SPEM 2.0 Work Definition y sus relaciones 19 . Son especialmente interesantes las tres u ´ltimas: Work Definition: Es una clase asbtracta que nos va a permitir generalizar cualquier tipo de trabajo dentro de una especificaci´ on en SPEM 2. 3. Figura 3.

Activity Use Kind: Para reusar una actividad relacion´ andola con otra. El elemento principal es la actividad (Activity) que a su vez se puede descomponer en otras actividades y contener otro tipo de elementos como MileStones.3. . Work Sequence Kind: Para expresar relaciones de orden entre dos Work BreakDown Element de manera m´ as general que en el elemento anterior. Work BreakDown Element: Especializaci´ on de Breakdown Element que se usa para representar alguna clase de trabajo. Role Use: Para representar qui´ en realiza o participa en una Activity.2.2. .3 Las clases m´ as relevantes de este paquete son: Activity: Elemento que nos sirve para representar la unidad b´ asica de trabajo o para representar un proceso en s´ ı mismo. Breakdown Element: Clase abstracta que nos sirve para generalizar cualquier tipo de elemento que forma parte de una actividad de nivel superior. MileStone: Un evento significativo dentro del proceso de desarrollo. Podemos ver los elementos del paquete y sus relaciones el figura 3. Work Sequence: Relaci´ on entre dos Work Breakdown elements que sirve para expresar que el comienzo de uno depende del final del otro. Process Element: Clase abstracta que generaliza cualquier elemento que forma parte de un proceso expresado en SPEM 2. 20 . Role Uses etc. Process Responsibility Assignment Map: Elemento que representa una relaci´ on entre instancias de Role Use y un u ´nico Work Product Use. SPEM Process Structure Contiene los elementos b´ asicos para definir procesos de desarrollo mediante un mecanismo de descomposici´ on. Process Performer Map: Para representar las relaciones entre una actividad y las instancias de Role Use que indican que el Role Use participa de alguna manera en el trabajo desempe˜ nado en la Activity. Process Parameter: Especializaci´ on de Work Definition Parameter y Breakdown Element que sirve para representar entradas y salidas de un proceso. Work Product Use Relationship: Para expresar relaciones (que pueden ser de distintos tipos) entre Work Products. Work Product Use: Especializaci´ on de Breakdown Element que se usa para representar o bien cualquier entrada o salida de una actividad o bien cualquier participante en la actividad.0. .

3: SPEM 2.0 Metamodelo del Paquete Process Structure 21 .Figura 3.

3. que nos va a permitir describir (de una u otra manera) todos los elementos de mi modelo de proceso. 22 . SPEM Process Behavior SPEM 2. . definir cu´ ales son los productos de entrada y salida de cada una de ellas y especificar qui´ en ha sido el que ha realizado la tarea. . Pasos(Steps) y WorkProduct Definitions. Default Task Definition Performer Map: Para relacionar instancias de Role Definition con instancias de Task Definition. checklists etc. plantillas. los otro componentes fundamentales del paquete son: Category: Para clasificar en categor´ ıas los distintos elementos. ) con los elementos del paquete Process Structure del metamodelo. No introduce por lo tanto ning´ un formalismo y u ´nicamente define como enlazar los modelos creados con otras notaciones (BPMN. 3.2.4 El elemento pincipal de este paquete es la clase abstracta Describable Element que es la superclase de todos los elementos del sistema para los cu´ ales es posible tener una descripci´ on textual. Tareas(Tasks).5. Diagramas de Actividad . Podemos apreciar los elementos del paquete y sus relaciones en la figura 3.2. Los elementos de este paquete y las relaciones entre ellos quedan descrito en el metamodelo que podemos apreciar en la figura 3. Guidance: Elemento que nos proporciona informaci´ on adicional sobre cualquier Describable Element.4. organizarlas en distintos pasos. . SPEM Managed Content El paquete Managed Content nos proporciona todo lo necesario para gestionar descripciones textuales de procesos y elementos. Content Description: Para almacenar descripciones textuales de un Describable Element. Section: Para estructurar en distintas partes las descripciones de los elementos 3. Pueden ser de distintos tipos gu´ ıas. .5 Default Responsibility Assignment Map: Para espeficicar relaciones entre instancias de Role Definition y Work Product Definition. Metric: Define medidas sobre Describable Elements. Su objetivo principal es definir las tareas.0 deja en manos del usuario la elecci´ on de la notaci´ on que crea m´ as conveniente para modelar el comportamiento din´ amico del sistema. . SPEM Method Content El paquete Method Content contiene los elementos principales de los m´ etodos como Roles. Adem´ as de esa clase.2.3. Default Task Definition Parameter: Especializaci´ on de Work Definition Parameter que nos permite usar Work Product Definitions como un atributo opcional.

competencias y responsabilidades de un participante o de un conjunto de participantes. Optionality Kind: Enumeraci´ on para describir si los Task Definition Parameters son opcionales u obligatorios. 23 . Tool Definition: Especificaci´ on de la participaci´ on de una aplicaci´ on (de cualquier tipo) para la realizaci´ on de una tarea. Work Product Definition: Cualquier cosa que es consumida. Constituye la unidad b´ asica para conseguir la reutilizaci´ on. Work Product Definition Relationship: Pr´ acticamente tiene la misma sem´ antica que Work Product Use Relationship sin embargo se utiliza para representar relaciones por defecto entre Work Products que han sido definidas en las descripciones generales de los m´ etodos. Role Definition: Conjunto de habilidades.Figura 3.0 Metamodelo del Paquete Managed Content Method Content Element: Generalizaci´ on de cualquiera de los elementos que van a componer un m´ etodo. Step: Para organizar una Task Definition en partes o subunidades de trabajo. producida o modificada por las tareas. Qualification: Para documentar las habilidades o competencias que deben poseer los Role Definitios.4: SPEM 2. Task Definition: Para definir el trabajo llevado a cabo por las instancias de Role Definition. es decir una unidad asignable de trabajo.

Method Content Kind: Refinamiento de Kind (del paquete Core) para Method Content Element. .6. Los Method Content poseen una serie de elementos y una serie de relaciones que pueden ser modificados para un Process particular para el cu´ al ha sido creado el Method Content.5: SPEM 2. Method Content Packageable Element: Cualquier elemento que puede ser empaquetado en un Method Content Package. Los elementos del paquete y sus relaciones pueden verse en la imagen 3. Method Content Package: Para describir un paquete que se caracteriza por contener u ´nicamente Method Content Elements. Method Content Use: Generalizaci´ on para Breakdown Elements que hace referencia a un Method Content Element concreto. ) definidos en un espacio de nombres y para los que se han descrito una serie de relaciones seg´ un el m´ etodo o proyecto en el que nos encontremos. task uses.Figura 3. roles.Es el concepto clave para entender la separaci´ on entre process y method content. .2. Breakdown Element: Generalizaci´ on de Process Element que es parte de una estructura compuesta por varios elementos. 24 .6 Activity: Grupo de distintos elementos (otras actividades.0 Metamodelo del paquete Method Content 3. SPEM Process With Methods El paquete Process With Methods proporciona las estructuras de datos necesarias para reflejar las buenas pr´ acticas de la industria y permitir la reutilizaci´ on entre distintas instancias de m´ etodos y procesos. milestone etc. Composite Role: Role Use especial que referencia a m´ as de un Role Definition con el objetivo de simplificar.

Work Product Use: Work Product Definition dentro del contexto de una actividad determinada. Process Kind: Refinamiente de Kind (paquete Core) para referirse a los Process Element.0 Estructura del paquete Process With Methods Planning Data: Process Element que a˜ nade informaci´ on sobre planificaci´ on.Figura 3.6: SPEM 2. Process Packageable Element: Cualquier elemento que puede ser empaquetado dentro de un Process Package. Process Performer Map: Extiende el Process Performer Map del paquete Process Structure a˜ nadi´ endole una asociaci´ on adicional con Task Use. Task Use: Task Definition dentro del contexto de una actividad determinada. 25 . Team Profile: Agrupaci´ on con estructura jer´ arquica de Role Uses o Composite Roles. Process Package: Un paquete que u ´nicamente puede contener Process Elements. Role Use: Un role en el contexto de una actividad determinada.

SPEM Method Plug-In El paquete Method Plug-In proporciona capacidades para gestionar librer´ ıas de Method Content y Process permitiendo mecanismos de extensibilidad y variabilidad mediante la reutilizaci´ on de Method Content y Process determinados. empaquetado e implantamci´ on de Process y Method Content. Method Library Packageable Element: Cualquier elemento que puede contener una Method Library. Process Component: Especializaci´ on de Process Package a la que se le pueden aplicar los conceptos de encapsulaci´ on y que contiene exactamente una Activity. Method PluginPackageable Element: Cualquier elemento que puede ser empaquetado dentro de un Method Plugin. WorkProduct Port: Entradas y salidas de Work Products para un Process Component.3.2.extends. Method Library: Contenedor de Method Plugins y definiciones de Method Configuration. replaces. Method Plugin: Una unidad de almacenamiento de la configuraci´ on.0. Method Configuration: Subconjunto l´ ogico dentro de una Method Library definido mediane una selecci´ on de Method Packages. La estructura de este paquete.7. 26 . modularizaci´ on.extendsreplace) para instancias de Variability Element. Section: Extiende Section (del paquete Managed Content) con capacidades de variabilidad. Puede albergar cualquier elemento de SPEM 2. sus elementos y las relaciones entre ellos se pueden apreciar en la figura 3. Process Component Use: La aplicaci´ on de un Process Component dentro de cualquier otro Process. Variability Element: Para proporcionar capacidades de variaci´ on y extensi´ on a los elementos de SPEM que derivan de ´ el.7. Work Product Connector: Para conectar Work Product Ports con el objetivo de ensamblar Process Components. Variability Type: Enumeraci´ on de valores (contributes. extensi´ on. Actividad: Extensi´ on de Activity para proporcionarle capacidades de variabilidad.

se define como un perfil UML.1. Los estereotipos m´ as Figura 3. el perfil de SPEM y UML se relacionan dentro de los niveles de abstracci´ on de la OMG tal y como podemos apreciar en la figura 3.El resto de estereotipos queda recogidos en [16]. De esta manera SPEM. SPEM 2.8: SPEM 2. Estereotipo Meta-/Superclase Icono 27 .0 Estructura del paquete Method Plugin 3. Con la creaci´ on del perfil los creadores pretenden que se puedan seguir utilizando para SPEM la gran cantidad de herramientas que han sido creadas para trabajar con UML.la Meta-/Superclase de cada uno de ellos y el icono correspondiente para su representaci´ on gr´ afica quedan recogidos en la tabla 3.0 Situaci´ on del perfil y del metamodelo dentro de los niveles de abstacci´ on de la OMG.8.3. importantes del perfil . al igual que sus versiones anteriores.7: SPEM 2.0 como perfil.Figura 3. Adem´ as de como metamodelo SPEM 2.0.

Planned Element /Action Describable Element / Class Category CompositeRole Role Use Guidance Describable Element / Class Method Content Package MethodLibrary MethodPlugin Metric Package /Package /Package Guidance Milestone Process ProcessComponent ProcessPackage Role Definition RoleUse Step TaskDefinition WorkBreakdownElement Classifier Activity /Package Package / MethodContentElement / Class BreakdownElement / Classifier MethodContentElement.Activity Work Definition. WorkDefinition MethodContentElement. WorkDefinition 28 .

1: Esteretipos del Perfil SPEM 2.TaskUse WorkBreakdownElement. PlannedELement / Classifier.0 29 . Action BreakDownElement / Classifier MethodContent Class Element / TeamProfile ToolDefinition WorkProductDefinition Method Content Element / Class BreakDownElement / Classifier WorkProductUse Cuadro 3.

Facilita la definici´ on de procesos a partir del ensamblaje de partes ya existentes. Conclusiones sobre SPEM La u ´ltima versi´ on de SPEM [16] ha sido publicada hace muy poco tiempo. la 1.4 que ten´ ıan una expresividad limitada [33].1. lo que permite la utilizaci´ on de la ingente cantidad de herramientas que dan soporte a esa especificaci´ on.1 la descripci´ on de la parte din´ amica del proceso se hac´ ıa mediante la utilizaci´ on de los diagramas de actividad de UML 1. editarlos y personalizarlos. que fue adoptada por muy pocas empresas dentro de la industria. No obstante dentro de la propia especificaci´ on “sugiere“ especificaciones como los diagramas de actividad de UML 2. en SPEM 1. que las empresas se decidan por su utilizaci´ on. Reconoce la necesidad de que puedan existir ciertas partes que no puedan formalizarse y que por lo tanto deben incluirse dentro del proceso mediante una descripci´ on en lenguaje natural.0 que han mejorado mucho la expresividad con respecto a las versiones anteriores [33] y BPMN que soporta la mayor´ ıa de los patrones de workflow [34] 30 . Prevee la derivaci´ on de manera autom´ atica de planes de desarrollo y otro tipo de documentaci´ on.4. Deja abierta a los desarrolladores la elecci´ on de la notaci´ on (ya sea de la OMG o de terceras partes) para describir la parte din´ amica del proceso.9 se puede ver un esquema donde se distingue esta separaci´ on. Establece una clara separaci´ on entre los elementos utilizados para la definici´ on formal de un m´ etodo (Method Content) y los elementos utilizados para describir la aplicaci´ on de dicho m´ etodo a un proceso (Process) dentro de un proyecto en concreto. Pose´ ıa una sem´ antica con algunas ambiguedades. Podemos destacar las siguientes: Se sigue definiendo como un perfil UML.1 [15] presentaba numerosos problemas entre ellos. En la figura 3. seg´ un los propios desarrolladores de la OMG: Era una especificaci´ on de dif´ ıcil comprensi´ on. Permite la creaci´ on de repositorios donde almacenar los procesos para posteriormente recuperarlos.Este hecho permite superar los problemas de expresivdad de la versi´ on anterior ya que se elegir´ a la notaci´ on de acuerdo al dominio del problema.0 ha modificado dr´ asticamente la versi´ on anterior y ahora proporciona una serie de caracter´ ısticas que pueden hacer.3. Adem´ as de estas afirmaciones hechas por los propios desarrolladores de la especificaci´ on. SPEM 2. SPEM 1. una vez ya se haya publicado la versi´ on totalmente definitiva. A´ un es pronto para ver si con esta nueva versi´ on se consigue superar el fracaso de versi´ on anterior.

0 Separaci´ on entre definici´ on e implementaci´ on 31 .Figura 3.9: SPEM 2.

3.5. Ejemplos en SPEM Figura 3. Fragmento de la descripci´ on textual de la metodolog´ ıa DMR Macroscope de Fujitsu.10: SPEM 2.0. 32 .

0 Diagrama detallado de una actividad 33 .11: SPEM 2.Figura 3.

0.12: SPEM 2.0. Diagrama de dependencias entre Work Products Figura 3. 34 .Figura 3.13: SPEM 2. Diagrama de componentes del equipo.

. recursos. Los propios autores de BPMN por otro lado. Que los lenguajes basados en XML para describir procesos (como BPEL4WS) tengan una notaci´ on gr´ afica. estrategias. lo que significa que otro tipo de modelos relacionados (estructura de la organizaci´ on. desde los analistas. . ) quedan fuera de la especificaci´ on.1.Otros objetivos importantes que se plantea esta especificaci´ on son: Crear puentes entre el dise˜ no de los procesos de negocio y la implementaci´ on del proceso. . modelos de datos. UML EDOC IDEF ebXML BPSS ADF Diagram RossetaNet LOVeM EPC Es importante tener en cuenta que BPMN abarca u ´nicamente los procesos de negocio. . . . ¿Qu´ e es BPMN? BPMN (Business Process Modelling Notation) es un est´ andar de la BPMI (Business Process Management Initiative)[12]. los desarrolladores t´ ecnicos. reconocen haberse inspirado y haber recogido la experiencia de varios est´ andares: Diagramas de Actividad de UML. 35 . reglas de negocio etc. hasta aquellos que monitorizar´ an y gestionar´ an los procesos“. organismo que ha sido absorbido recientemente por la OMG.Cap´ ıtulo 4 BPMN 4. cuyo principal objetivo es seg´ un [8] “proporcionar una notaci´ on f´ acilmente comprensible por todos los usuarios del negocio.

dentro de una organizaci´ on espec´ ıfica. as´ ı como las correspondientes estructuras de control de flujo.2. de hecho. 4. Procesos de colaboraci´ on (globales) 36 . Procesos abstractos (p´ ublicos). Si usamos calles para representarlos este tipo de procesos u ´nicamente ocupar´ an una calle aunque pueda interactuar. Procesos de negocio abstractos (p´ ublicos) Los procesos de negocio abstractos nos sirven para representar las interacciones existentes entre un proceso de negocio privado y. no es un diagrama de flujo de datos“. con otros procesos de negocio de la misma clase.Todo este tipo de modelados y sus relaciones con BPMN ser´ an definidos m´ as formalmente conforme BPMN y otras especificaciones evolucionen.2.2.2.3.1.2. Estas secciones son: Procesos de negocio privados (internos).1: Proceso de negocio privado 4. 4. “aunque BPMN muestre el flujo de datos(mensajes) y las asociaciones de los artifacts con las actividades. En este tipo de procesos u ´nicamente se incluyen aquellas actividades que se usan para comunicar un proceso privado con el exterior. 4. Procesos de negocio privados(internos) Los procesos de negocio privados o internos son los que. Figura 4. mediante el flujo de mensajes. Estos diagramas constan de una serie de elementos que nos van a permitir diferenciar claramente las tres secciones (o submodelos) b´ asicos que existen en un modelo BPMN. han sido tradicionalmente llamados diagramas de flujo de trabajo o diagramas de workflow. o bien otro proceso de negocio o bien un participante del proceso.1. .2. Podemos ver un ejemplo de representaci´ on gr´ afica para este tipo de procesos en la figura 4.Podemos ver un ejemplo de este tipo de submodelo en la figura 4. Modelos en BPMN Los modelos BPMN se expresan gr´ aficamente mediante diagramas BPMN. Procesos de colaboraci´ on (globales).

3: Proceso de colaboraci´ on 37 .2: Proceso de negocio abstracto Este tipo de procesos sirven para mostrar la interacci´ on entre distintas entidades de negocio. Estas interacciones son definidas como secuencias de actividades que representan el intercambio de mensajes entre las distintas entidades.Figura 4.3. Figura 4. La colaboraci´ on se entiende como la comunicaci´ on entre dos o m´ as procesos.Podemos ver un ejemplo de representaci´ on gr´ afica para este tipo de procesos en la figura 4.

[8] 4. Objetos de Flujo (Flow objects) 2. Pueden ser de tres tipos. Los tres objetos de flujo principales los podemos ver en la tabla 4. tambi´ en llamados BPD est´ an formados por una serie de elementos fundamentales. Conectores (Connecting Objects) 3. por eso se recomiendo al modelador que se centre en un tipo de modelo para los diagramas“.1.1: Objetos de Flujo en BPMN 38 . un join. . de Inicio. Artefactos (Artifacts) Objetos de flujo(Flow objects) BPMN posee un conjunto reducido de elementos de este tipo. crear diagramas con distintos tipos de modelos aunque siempre debemos tener en cuenta la advertencia de la propia especificaci´ on de BPMN “debemos tener cuidado si combinamos demasiados tipos de submodelos. obtendremos un diagrama dif´ ıcil de entender.3. Calles (Swinlanes) 4.3.1. . Intermedio y de Finalizaci´ on El t´ ermino gen´ erico para denominar cualquier trabajo que realiza la compa˜ nia. Elementos b´ asicos de los diagramas BPMN Los diagramas BPMN. Podremos adem´ as. Estos se pueden clasificar en cuatro categor´ ıas fundamentales: 1. . Tipo Eventos(events) Descripci´ on Algo que ocurre durante el transcurso de un proceso de negocio. p´ ublico y de colaboraci´ on). . El objetivo de que sea un conjunto reducido es “que los modeladores no tengan que aprender y memorizar gran cantidad de iconos“ [37].4. Diagramas BPMN BPMN es una notaci´ on gr´ afica con la que podemos crear multitud de diagramas dentro de los tres tipos de submodelos (privado. Imagen Actividades (Activity) Pasarelas (Gateway) Cuadro 4. puede ser una decisi´ on tradicional. un merge y un fork. Pueden ser at´ omicas o compuestas Para controlar el flujo.

Conectores Son los elementos que servir´ an para conectar los diferentes Flow Objects con el objeto de crear el esqueleto estructural b´ asico del procesos de negocio.2: Conectores en BPMN Calles(Swinlanes) Las calles o swinlanes son un mecanismo que nos va a permitir clasificar las actividades de manera visual para ilustrar las distintas categor´ ıas o responsabilidades. Existen tres tipos de conectores cuyas descripciones y s´ ımbolos podemos ver en la tabla 4. ya sea vertical u horizontal que nos va a permitir clasificar las actividades Cuadro 4.Los tres tipos predefinidos se pueden apreciar en la tabla 4. 39 .4. Para asociar artifacts con flow objects Flujo de mensaje (Message Flow) Asociaci´ on tion) (Associa- Cuadro 4.3 Tipo Pool Descripci´ on Para indicar los participantes en el proceso Es una partici´ on de POOL.2 Tipo Descripci´ on Imagen Flujo de secuencia (Secuence Flow) Para indicar el orden en el cu´ al son ejecutadas las actividades del proceso de negocio Para mostrar el intercambio de mensajes entre dos participantes (entidades de negocio o roles).3: Objetos Swinlane en BPMN Imagen Lane Artifacts(Artefactos o Productos) Existen tres tipo de artifacts predefinidos. aunque para un determinado dominio BPMN permite a˜ nadir artifacts adicionales.Las distinas clases de ete tipo de objetos se puende apreciar en la tabla 4.

4: Artifacts en BPMN 40 .Tipo Descripci´ on Imagen Datos (Data Object) Para mostrar los datos que son producidos o requeridos por las actividades Grupo (Group) Para agrupar distintos elementos del diagrama Para proporcionar informaci´ on adicional Anotaciones (Annotations) Cuadro 4.

Estas especializaciones las podemos ver en la imagen 4.4 Figura 4. tal y como se definieron previamente son algo que ocurre en el transcurso de un proceso de negocio. Tipos de eventos Los eventos. Timer: Evento que se dispara al llegar un momento previamente determinado. Compensation: Para realizar acciones de compensaci´ on en caso de que se deba cancelar una actividad o para generar esta actividad de cancelaci´ on de una actividad en curso. Message:Al recibir un mensaje de un participante(Inicio. 41 . Tipos de eventos. Link: Para conectar eventos de distintos tipos. Adem´ as de estos elementos b´ asicos existen distintas variaciones de los mismos.Intermedio y Final) existen especializaciones de los mismos.3. Rule: Evento que se dispara cuando se cumple una regla determinada. Va asociado a las excepciones. Cancel:Evento que se dispara al cancelarse una transacci´ on(Intermedio) o que permite generar una cancelaci´ on de una transacci´ on.4: BPMN. Error: Al producirse un error (Inicio o intermedio) o que genera un error que debe ser capturado.intermedio) o que env´ ıa un mensaje a un participante al acabar el proceso. Variaciones de los elementos b´ asicos En la secci´ on anterior vimos los elementos b´ asicos b´ asicos que componen los diagramans en BPMN.2.4. Adem´ as de los tres tipos b´ asicos (Inicio.

Adem´ as del tipo b´ asico descrito anteriormente existen diversas variaciones. Complex: Para describir Merge/Join o decisiones que requieran condiciones complejas para consumir o producir tokens a trav´ es del gateway. Inclusive: Para consumir tokens de una o m´ as ramas de entrada(Inclusive Merge) o para propagar tokens a. Terminate:Finaliza todas las actividades del proceso. al menos. Estas variaciones las podemos ver en 4. una de las ramas de salida(Inclusive Desicion). Tipos de Gateway Los gateways son los elementos que nos van a permitir realizar el control de flujo dentro de un diagrama BPMN. Figura 4. BPMN posee otros s´ ımbolos y variaciones cuya descripci´ on y sem´ antica podemos ver en [8] 42 .5. Adem´ as de estas variaciones.Multiple: Cuando existen varias formas de que se dispare el evento (Inicio. Parallel: Consume todos los tokens de entrada (Parallel Merge) y dispara todos los tokens de salida (Parallel Joining).intermedio) o cuando existen diversas consecuencias al producirse el mismo.5: Tipos de Gateways en BPMN Exclusive(Event o Data Based): Para consumir tokens u ´nicamente de una de las ramas de entrada (Exclusive Merge) o para propagar tokens en s´ olo una de las ramas de salida(Exclusive Decision).

1 Graham Technology: GT-X Global 360: Business Optimization Server .4. Herramientas BPMN Desde la aparici´ on de BPMN.Process Sketchpad IDS-Scheer: Aris Corel: iGrafx ILOG: JViews Intalio: n Designer Intellior AG: AENEIS ITpearls: Process Modeler for Visio Kaisha-Tec: ActiveModeler Lanner: Witness Lombardi Software: TeamWorks M1 Global: BPI Studio Mega International: Mega Suite No Magic: MagicDraw UML 10.4.0 43 . Las que seg´ un la propia OMG[20] implementan la especificaci´ on son las siguientes: Appian Enterprise 5 Business Process Management Suite aXway: Process Manager BizAgi BOC Information Systems: ADONIS BOC Information Systems: ADONIS Borland R Together R Products: Together Architect R 2006 and Together Designer R Casewise: Corporate Modeler Cordys: Studio Fuego: Fuego 5 (BEA) Elixer Intelligent Software: eliXir BPMN-MDA Framework Fujitsu: Interstage Business Process Manager 7. y mucho m´ as desde la absorci´ on de BPMI por parte de la OMG. la notaci´ on BPMN ha tenido un ´ exito notable y como consecuencia de ´ este ´ exito han ido apareciendo gran cantidad de herramientas que dan soporte a esta especificaci´ on.

BPMN.0. Nos encontramos por lo tanto con dos especificaciones dentro de la misma OMG. ya se dijo anteriormente.1 Sun Microsystems: Studio Enterprise Edition Sybase: PowerDesigner R 12 Troux: Metis 3. supervisar y gestionar ese tipo de procesos.NET 2006 Sparx Systems: Enterprise Architect 6. simular. El motivo de ´ este cambio fue la falta de expresividad que para algunos investigadores de la rama del workflow ten´ ıan los citados diagramas de actividad.5. sugiriendo no obstante la misma BPMN o los Diagramas de Actividad.Orbus Software: iServer Pegasystems: BPMSuite Seagull Software: LegaSuite BPM Software AG: Enterprise Business Process Manager Popkin: System Architect Popkin: System Architect Proforma: ProVision Santeon: XIP BPM Platform Select Business Solutions: Select Component Factory Skelta: Skelta BPM. A d´ ıa de hoy es un hecho que cada d´ ıa est´ an teniendo m´ as importancia los procesos de negocio y por extensi´ on las herramientas que nos sirven para modelar.6 Enterprise Architecture Suite 4. El hecho de que la OMG haya absorbido BPMI hace preguntarse si los procesos de desarrollo de software pueden ser expresados mediante notaciones de procesos de negocio. La mejora producida por este cambio fue notable. Conclusiones sobre BPMN BPMN fue. y podemos comprobar en [33] que la nueva versi´ on de los diagramas de actividad cumple casi todos los patrones de workflow [32]. una iniciativa de la BPMI. seg´ un [34] cubre casi totalmente los patrones de workflow con lo cu´ al se le supone una gran expresividad a la hora de especificar procesos. los Diagrama de 44 . Uno de los cambios m´ as profundos al pasar de UML 1. que pasaron de tener sem´ antica de m´ aquinas de estados a redes de petri (pseudo redes de petri para los puristas).La nueva especificaci´ on SPEM 2. Esta instituci´ on fue absorbida por la OMG que es una de las organizaciones punteras en la creaci´ on de especificaciones para el desarrollo de software orientado a objetos.0 (especificaci´ on estrella de la OMG) fue la nueva sem´ antica con la que se dot´ o a los diagramas de actividad. [16] cuando se refiere a la descripci´ on del comportamiento deja las puertas abiertas y nos da la libertad para elegir la especificaci´ on que creamos m´ as conveniente para el dominio de nuestra aplicaci´ on.5 a UML 2.

45 . BPMN tiene el apoyo de la WfMC. es m´ as expresivo. una de las organizaciones m´ as importantes en el campo del workflow que adem´ as de miembro de la propia OMG ha modificado una de sus especificaciones XPDL (que posteriormente es descrita en esta memoria) para dar cobertura total a BPMN. BPMN puede transformarse directamente en BPEL. no s´ olo como concesi´ on a la organizaci´ on absorbida sino tambi´ en por otras razones expuestas en[28]: BPMN es capaz de expresar m´ as patrones [34] que los diagramas de actividad [33]. con menos s´ ımbolos fundamentales. pero con m´ as variaciones de ´ estos. BPMN es gr´ aficamente m´ as rico. cuyo objetivo es b´ asicamente el mismo. un lenguaje de orquestaci´ on de servicios web que se est´ a consolidando como un est´ andar.Actividad de UML y BPMN. Todo parece indicar que la OMG se est´ a decantando por BPMN. es decir.lo que facilita su comprensi´ on por parte de gente no experta.

Ejemplos de Diagramas en BPMN Figura 4.6.7: Diagrama en BPMN. Proceso de voto electr´ onico. Figura 4.6: Diagrama en BMPN.4. Visi´ on detallada del proceso de voto electr´ onico 46 .

“las especificaciones XPDL y BPMN afrontan el mismo problema de modelado desde diferentes perspectivas.1. 47 .Cap´ ıtulo 5 XPDL 5. Seg´ un los propios creadores de XPDL. con el objetivo de que. La versi´ on m´ as reciente de XPDL es la 2. consultores e investigadores en el campo de la gesti´ on de procesos de negocio“.Fue fundada en 1993 y actualmente es miembro de la OMG siendo uno de los participantes que m´ as han influido sobre la especificaci´ on de UML 2. Interoperabilidad entre distintos sistemas de workflow. este modelo pueda ser usado por otras aplicaciones de modelado y/o por otras aplicaciones que trabajen en el entorno de ejecuci´ on.0. Sistema para monitorizar los procesos que nos proporcione una serie de m´ etricas que nos faciliten la gesti´ on de los mismos. Para la WfMC deben existir 5 interfaces funcionales en un proceso o servicio de workflow [18]: Definici´ on de procesos e importaci´ on/exportaci´ on de los mismos. ¿Qu´ e es XPDL? XPDL (XML Process Definition Language) es un lenguaje de la WfMC (Workflow Management Coallition) que es “Una organizaci´ on sin a ´nimo de lucro para desarrolladores.0. BPMN proporciona una notaci´ on gr´ afica para facilitar la comunicaci´ on humana entre usuarios de negocio y usuarios t´ ecnicos“ [38]. analistas. aunque se modele un proceso en una aplicaci´ on.0 que no pose´ ıa XPDL 1.0 y mantiene compatibilidad total con las versiones anteriores. XPDL forma parte de la documentaci´ on relativa al INTERFACE UNO que da soporte a la definici´ on y a la importaci´ on/exportaci´ on de procesos. XPDL proporciona un formato de fichero XML para ser intercambiado entre aplicaciones. Y precisamente esta u ´ltima versi´ on surge para dotar a XPDL de los elementos de BPMN 1. dejando muy claro el prop´ osito de su especificaci´ on. Interacci´ on con otros tipos de aplicaciones. Interacci´ on con los interfaces de escritorio de los usuarios.

La relaci´ on entre XPDL y BPMN puede apreciarse con m´ as claridad en la imagen 5.1. la definici´ on de procesos y el intercambio de estas definiciones utilizando XML como mecanismo para realizar estos intercambios. donde quedan tambi´ en patentes los dos principales objetivos de XPDL. Figura 5.1: Relaci´ on BPMN-XPDL 48 .

que se encarga de las agrupaciones de procesos. Atributos de procesos. del intercambio de mensajes entre ´ estos y de las diferentes caracter´ ısticas que poseen los mismos. El metamodelo XPDL Para llevar a cabo lo que se propone con XPDL la WfMC define un metamodelo para XPDL que cubre: Las entidades de m´ as alto nivel en el dominio de la definici´ on de procesos. Definiciones de datos comunes que puedan ser usados en variedad de modelos.5. Agrupaciones de diferentes procesos en modelos relacionados. Para todos estos aspectos tenemos dos meta-modelos principales: El metamodelo Package. El metamodelo Process que describe las principales entidades que componen un proceso as´ ı como los atributos de ´ estas.2. 49 .

5.2: Metamodelo Package 50 .1.2 Figura 5. Metamodelo Package Este metamodelo queda descrito en la figura 5.2.

2. Metamodelo Process Este metamodelo queda descrito en la figura 5.3. Entidades b´ asicas de los metamodelos De las entidades que conforman los dos metamodelos vamos a describir brevemente las de m´ as alto nivel. Process Definition: Proporciona informaci´ on contextual que se aplica a una serie de entidades a lo largo de un proceso.3: Metamodelo Process 5. Event:Cualquier suceso que ocurre mientras se est´ a ejecutando un proceso y que normalmente afecta al flujo del mismo. Task: Unidades de trabajo que componen una actividad. t´ ıpicamente en relaci´ on a los roles participantes. Actividad: Trabajo dentro de un proceso que ser´ a desempe˜ nado por una combinaci´ on de recursos humanos y computacionales.2. 51 .5. Lane: Entidad que nos va a permitir subdividir un Pool. que son precisamente las que tienen relaci´ on directa con los elementos de la notaci´ on gr´ afica BPMN: Pool: Contenedor de actividades y transiciones entre ellas.3 Figura 5.

Amazonas Workflow. flujo de mensajes) y que se relacionan con objetos del flujo(flow objetcs ) mediante asociaciones. 5. total o parcialmente.Transition: Paso de una actividad a otra cuando se cumplen determinadas condiciones. Association: Para asociar un Artifact con un objeto de flujo (Object Flow ) y para mostrar las actividades que se usan para compensar otra actividad. Message Flow: Flujo de mensajes entre dos participantes y/o procesos que est´ an preparados para enviar y recibir informaci´ on. Artifact: Elementos del proceso que no pertenecen al conjunto de elementos b´ asicos (actividades. Relevant Data: Los datos que son creados y usados por una instancia de un proceso durante su ejecuci´ on. Herramientas XPDL Existen multitud de herramientas que nos permiten trabajar con XPDL. un Data Object. Pueden ser (siguiendo la notaci´ on BPMN). secuencia. una o varias actividades. Participant: El que realiza una serie de actividades. Application: Elementos computacionales que nos van permitir automatizar. System and Enviromental data: Datos que son mantenidos por el sistema de workflow o el sistema de entorno local y que son accedidos por las actividades para ser usados de la misma manera que los Relevant Data.4. Brein BV offers InProces CapeVisions CARNOT Process Engine CHALEX BPM Framework The Cubetto Toolset Enhydra Shark Enhydra JaWE Finantix Studio (FXS) Fuego 52 . las reconocidas por la propia WfMC son las siguientes [9]: ADVANTYS.7. BOC ADONIS 3. una Annotation o un Group. ya sea un elemento humano o un elemento computacional.

Eclaire Group Metoda S. y siempre que mantengan compatibilidad (WfMC es miembro de la OMG y BPMI tambi´ en.PL IDS Scheer Integic e. XPDL puede ser considerado como la notaci´ on textual de BPMN.p.5. 53 . Por lo tanto XPDL y BPMN son un binomio a tener muy en cuenta dentro de campo del modelado de procesos de negocio.Fujitsu Interstage HOGA.0 que.POWER WorkManager Builder tool Interstage Business Process Manager Studio ITP-Commerce Jenz & Partner GmbH Flow Designer.2 Projekty Bankowe Polsoft TIBCO R Staffware Process Suite TIBCO R Business Studio. o al rev´ es. como ya dijimos antes.A Tell-Eureka’s OfficeObjects R WorkFlow Open Business Engine Oracle9i Warehouse Builder 9. Together Workflow Editor Vignette Process Workflow Modeler ZAPLET 3 PROCESS BUILDER 5. . un campo que cada vez est´ a adquiriendo m´ as importancia Para darle efectividad a esta pareja. aunque nunca se sabe . Eso al menos para la versi´ on de XPDL 2. se modific´ o precisamente para reflejar todos y cada uno de los elementos de BPMN. A su vez. Conclusiones sobre XPDL XPDL es una notaci´ on para definir e intercambiar modelos de procesos de negocio. . ) lo ideal ser´ ıa encontrar una herramienta que nos permita usar ambas especificaciones de la siguiente manera: Usar BPMN para modelar de manera gr´ afica los modelos de procesos de negocio (lo cu´ al es m´ as amigable tanto para los ingenieros como para los clientes). BPMN la notaci´ on gr´ afica de XPDL.

4 obtenido de [30]. Ambos tienen prop´ ositos diferentes que van permitir que en determinadas ocasiones puedan complementarse tal y como podemos apreciar en el siguiente en la figura 5.4: Relaci´ on entre XPDL y BPEL 54 . Pese a las confusiones que pudieran surgir BPEL no es un competidor de XPDL. Esta asociaci´ on toma a´ un mas valor cuando le a˜ nadimos BPEL. otro de las tem´ aticas punteras dentro del mundo de la ingenier´ ıa del software.XPDL para guardar los modelos e intercambiarlos entre las diferentes aplicaciones. BPEL se est´ a convirtiendo en el est´ andar de facto para la orquestaci´ on de Servicios Web. Figura 5.

55 .6.5: Ejemplo XPDL no 1. El texto de la figura 5.6: Gr´ afico BPMN correspondiente al ejemplo no 1 en XPDL.5 se corresponde con la figura 5.5. Una decisi´ on exclusiva. Figura 5.6: Figura 5. Ejemplos en XPDL A continuaci´ on podemos ver algunos extractos de documentos XML que cumplen con el est´ andar XPDL y tras ellos su equivalente gr´ afico en BPMN.

En el segundo ejemplo podemos ver el XPDL correspondiente a una actividad que comienza tras un evento de tipo mensaje: Figura 5.8: Figura 5. Actividad que comienza tras un evento de mensaje El texto de la figura 5.7 se corresponde con la figura 5.8: Gr´ afico BPMN correspondiente al ejemplo no 2 en XPDL 56 .7: Ejemplo XPDL no 2.

uno de los servidores de aplicaciones m´ as usados. generar c´ odigo de manera autom´ atica y realizar un seguimiento gr´ afico de la evoluci´ on de la ejecuci´ on del procesos definido. adem´ as. Aunque est´ a centrado en un dominio espec´ ıfico. jbpm. ¿Qu´ e son jBPM y jPDL? jBPM (jBoss Business Process Management) es “un sistema flexible y extensible de administraci´ on de workflow que cuenta con un lenguaje de proceso intuitivo para expresar gr´ aficamente procesos de negocio en t´ erminos de tareas. A su vez el jbmp-server est´ a compuesto por los siguientes elementos: El proceso servidor propiamente dicho. estados de espera para comunicaci´ on as´ ıncrona.Cap´ ıtulo 6 jBPM y jPDL 6. el desarrollo de aplicaciones web. Arquitectura de jBPM jBPM est´ a compuesto por una serie de elementos: jbpm-server que es un servidor jBoss preconfigurado para funcionar de manera conjunta con jbpm. jbpm-designer que es un plug-in de eclipse que nos permite crear de manera gr´ afica modelos de procesos de negocio expresados en jBPM. 6.2. temporizadores. jbpm-bpel. el componente central. acciones automatizadas“ [22]. Extensi´ on para BPEL de jBPM. Este sistema jBPM ha sido desarrollado para ser utilizado con jBoss.Nos va permitir. 57 . Un servidor de bases de datos integrado (HSQL). se ha decidido incluirlo en este documento porque proporciona tanto una notaci´ on gr´ afica para modelar los procesos como una notaci´ on basada en XML (jPDL) para almacenar e intercambiar procesos.1. que contiene todas las librer´ ıas necesarias y toda la documentaci´ on.

Un programador jBPM para planificar y automatizar la ejecuci´ on de tareas. Modelando gr´ aficamente procesos de negocio con jBPM Para modelar gr´ aficamente procesos de negocio en jBPM disponemos de una notaci´ on gr´ afica propia que podemos utilizar a trav´ es de un plug-in de eclipse de f´ acil instalaci´ on. Una herramientas para ejecutar ordenes y monitorizar ´ ordenes. A trav´ es de este plug-in podremos adem´ as de modelar gr´ aficamente el proceso: Editar el jPDL correspondiente al modelo.1.1: Plug-In de Eclipse para jBPM 58 . Figura 6. Podemos ver la apariencia de ese editor gr´ afico de procesos de negocio en la figura 6. Modificar todas las propiedades de los elementos gr´ aficos.3. 6.Aplicaciones de administraci´ on y configuraci´ on del servidor jBoss. Visualizar y editar el c´ odigo java que se genera autom´ aticamente a partir del modelo gr´ afico del proceso de negocio.

La otra forma de modelar la decisi´ on es cuando las decisiones la toma una parte externa. Una vez le han llegado todos los tokens u ´nicamente propaga un token de salida. 59 . El c´ odigo es invisible en la representaci´ on gr´ afica. Se diferencia del task-node en que no pone ninguna tarea en la lista de tareas a realizar por los usuarios de la aplicaci´ on. Task-Node: Para indicar una actividad. SuperState: Un SuperState es un grupo de nodos que pueden estar anidados de forma recursiva. de tal manera que el token no pasar´ a del estado origen al estado destino si no se cumple dicha condici´ on. dentro del proceso de negocio. varias rutas de ejecuci´ on concurrentes. El ProcessState es un tipo de nodo o estado que est´ a asociado a una definici´ on de proceso. Fork: Pasa el token de ejecuci´ on a todas las ramas salientes provocando de esa manera. Se suelen usar para a˜ nadir jerarqu´ ıa a la definici´ on del proceso. Node: Nodo de caracter´ ısticas especiales donde podremos definir de manera program´ atica las acciones a llevar a cabo una vez lleguen los tokens. Pueden tener tanto nombre como condiciones asociadas. End: Para indicar un estado final para nuestro proceso de negocio. State: Para indicar que el sistema espera a que llegue un evento que t´ ıpicamente suele provenir de un sistema externo no humano. es en este caso cuando utilizaremos los nodos Decisi´ on y a˜ nadiremos elementos de condici´ on en las transiciones que partan de dicho nodo. lo que es ideal si simplemente estamos analizando el proceso y no la l´ ogica. Cuando la ejecuci´ on llega a ese nodo se crea una instancia del proceso al cu´ al esta asociado y no se continua la ejecuci´ on hasta que esa instancia o subproceso ha finalizado. Transition: Para representar el paso de un nodo origen a un nodo destino. Join: Estado del proceso en el que espera a que le lleguen los tokens de todas las ramas de ejecuci´ on entrantes. El proceso mantendr´ a el token. sin propagar la ejecuci´ on. Es un estado v´ alido pero que no puede ser ejecutado. Una vez ha llegado el evento se propaga el testigo de la ejecuci´ on. ProcessState: jbpm admite la composici´ on de estados mediante este tipo de nodos. En ese caso usaremos las transiciones partiendo de un nodo State para crear las condiciones de la decisi´ on.Las entidades de alto nivel que nos proporciona el editor jBPM son las siguientes: Start: Para indicar el estado de inicio de nuestro proceso de negocio. que debe ser realizada por el usuario. Se suele usar para implementar en java alguna l´ ogica que sea importante para el analista de negocio. Decisi´ on: Tenemos dos formas para modelar una decisi´ on. hasta que el usuario no haya realizado su tarea. La primera de ellas es cuando los propios procesos toman la decisi´ on.

Esta correspondencia no es completa ya que existen ciertas entidades que. Swinlanes: Nos sirven para indicar la asignaci´ on de los distintos actores a las tareas. 6. jPDL jDPL es la notaci´ on XML que.Todos los archivos relacionados con la definici´ on del proceso se empaquetan en un fichero .4. Timers: Los timers o temporizadores nos van a permitir realizar acciones o ejecutar transiciones una vez se acabe el tiempo definido para ellos.zip cuyo fichero central es el fichero processdefinition.Adem´ as de todos estos elementos gr´ aficos desde el plug-in de eclipse podremos a˜ nadir. no tienen su equivalente en la notaci´ on gr´ afica. B´ asicamente jPDL se puede considerar como el equivalente XML a lo expresado gr´ aficamente mediente el Plug-In jBPM para Eclipse. La ejecuci´ on del gr´ afico en si misma no genera excepciones. aunque podemos representarlas de manera textual mediante jPDL. Actions: Porciones de c´ odigo Java que se ejecutar´ an cuando suceda alg´ un determinado tipo de evento Excepciones: El mecanismo de excepciones en jbpm s´ olo atiende las excepciones del c´ odigo java generado.xml que contiene las etiquetas XML que describen el modelo de acuerdo al XML Schema de jPDL. aunque sea de manera textual (mediante jPDL) los siguientes elementos a nuestro modelo de proceso de negocio: Events: Representan momentos concretos durante la ejecuci´ on de un proceso. Estas etiquetas se definen con detalle en [22] y son las siguientes: Process-definition Node Common node elements Start-state End-state State Task-node Process-State Super-State Fork Join 60 . nos va a permitir empaquetar todos los archivos asociados a una definici´ on de proceso en un archivo de proceso. de acuerdo a un XLM Schema determinado.

2: 61 .Decision Event Transition Action Script Expresion Variable Handler Timer Create-timer Cancel-timer Task Swimlane Assignment Controller Sub-Process Condition Exception-Handler Podemos ver un ejemplo en jPDL de un Process-State en la figura 6.

2: Ejemplo de Process State en jPDL 62 .Figura 6.

una de los servidores de aplicaciones m´ as usados. A˜ nade un editor gr´ afico de procesos. Para lograr eso jPDL viene con una peque˜ na serie de nodo b´ asicos pero facilita que un desarrollador pueda escribir c´ odigo y enlazarlo como la implementaci´ on del comportamiento de un nodo del grafo. Genera autom´ aticamente mucho c´ odigo a partir del diagrama generado de manera gr´ afica. Nos permite comprobar nuestra evoluci´ on en el gr´ afico del proceso mientras estamos ejecut´ andolo. que es uno de los entornos de desarrollo m´ as utilizados. Conclusiones sobre jBPM-jPDL Ciertamente jBPM+jPDL son dos notaciones estrechamente ligadas a un dominio muy concreto. el desarrollo de aplicaciones web sobre el servidor de aplicaciones jBoss. Con estas caracter´ ısticas lo que se consigue es que la creaci´ on de procesos llegue m´ as all´ a de la programaci´ on visual. acerc´ andolo mucho m´ as al lenguaje de programaci´ on de prop´ osito general (en este caso Java). Lo que no tiene en cuenta este autor es la utilizaci´ on del modelado de procesos de negocio ya no en el ´ ambito del desarrollo de aplicaciones web sino en el 63 .6. Hay una gran falta de integraci´ on entre los lenguajes de definici´ on de procesos y los lenguajes de programaci´ on de prop´ osito general. Va asociado a JBOSS. Nos permite la definici´ on e intercambio de definiciones de procesos a trav´ es de la notaci´ on jPDL.5. basada en un XML schema. En lo relativo a la expresividad seg´ un sus propios creadores (no se han encontrado estudios independientes) [23] jPDL es capaz de soportar las mayor´ ıa de los patrones de workflow para dar soporte a las construcciones m´ as complejas del modelado de procesos pero siempre intentando mantener los detalles m´ as complejos s´ olo a la vista de los usuarios m´ as expertos. jPDL fue creado con esos problemas siempre presentes y teniendo en cuenta una m´ axima le separa de los objetivos de las aplicaciones BPM tradicionales: Puedes analizar o puedes implementar pero no puedes hacer ambas cosas a la vez. Partiendo de esa afirmaci´ on podr´ ıamos pensar en descartarlas si el proceso de negocio a modelar fuera un proceso de desarrollo de aplicaciones y si estuvi´ eramos buscando notaciones y aplicaciones lo m´ as flexibles posible. Seg´ un [7] (uno de los creadores de jBPM) antes de hablar de jPDL debemos tener en cuenta varios problemas en relaci´ on a la gesti´ on de procesos de negocio (BPM): Los vendedores de herramientas para BPM suelen asegurar que sus herramientas pueden unificar la fase de an´ alisis y de implementaci´ on cosa que luego no es cierto. Sin embargo jBPM posee algunas caracter´ ıstica que lo hace muy interesante: Se instala como un plug-in para Eclipse.

aunque no elijamos jBPM por ser para un dominio muy espec´ ıfico aporta ideas muy u ´tiles para el modelado de procesos de negocio dentro de un ´ ambito determinado. que es adem´ as una de las posibilidades de jBPM y que se est´ a convirtiendo en el est´ andar de facto para la orquestaci´ on de servicios web. el objetivo debe ser un dominio concreto para poder ir automatizando paulatinamente las fases que compongan nuestro proceso. El modelado de procesos de negocio aplicado al desarrollo de software nos permitir´ a comprender mejor la integraci´ on o la arquitectura basada en servicios.´ ambito de la integraci´ on de aplicaciones. ni un proceso completo ni un nodo en particular. siempre teniendo en cuenta que mientras haya alguna informaci´ on incompleta no podremos automatizar. En estos dominios lo que se busca precisamente es minimizar la fase de implementaci´ on mediante el aprovechamiento de aplicaciones ya existentes. con el a˜ nadido de poder transformar ese proceso de negocio en una orquestaci´ on BPEL. 64 . Por todo ello. De hecho el querer obtener una herramientas de modelado de procesos de negocio de car´ acter general puede ser un error.

procesos y aplicaciones de negocio. 65 .2. Esta compa˜ n´ ıa es de lejos la compa˜ n´ ıa l´ ıder en el campo de las herramientas BPR (Businees Process Reengineering). Incorporaci´ on de las distintas vistas para obtener como resultado un proceso global sin ninguna redundancia.1. la ejecuci´ on y el control de los procesos de negocio. independientemente del n´ umero de departamentos de la compa˜ n´ ıa. Permite utilizar distintas notaciones dependiendo de la actividad que estemos realizando pero para la descripci´ on y definici´ on de los procesos. De esta manera se pueden utilizar los m´ etodos que mejor se adapten a cada una las vistas. Arquitectura de ARIS El modelo de arquitectura de ARIS tiene como objetivo fundamental la integraci´ on de sistemas tras un an´ alisis del proceso de negocio [19]. utiliza diagramas EPC(EventDriven Process Chain). El objetivo principal de este framework es el proceso de negocio de las compa˜ n´ ıas aunque con el conjunto de herramientas asociadas cubre todas las ´ areas. el tama˜ no de las mismas o del software disponible. Este proceso se lleva cado mediante una serie de pasos: Crear un modelo que contenga los aspectos fundamentales del proceso de negocio. 7. Descomponer el modelo en diferentes vistas para reducir su complejidad. que es la parte que nos ocupa principalmente en esta memoria. ¿Qu´ e es ARIS? ARIS(Architecture of integrated Information Systems) es un framework de la compa˜ n´ ıa IDS Scheer para describir estructuras organizativas. An´ alisis de las distintas vistas por separado.Cap´ ıtulo 7 ARIS 7. Nos proporciona herramientas para la definici´ on. En los apartados posteriores vamos a ver una primera aproximaci´ on al framework completo para en la conclusi´ on poner m´ as atenci´ on en los diagramas EPC y en sus caracter´ ısticas. la configuraci´ on.

la descripci´ on del problema del negocio (operational business problem). Organization View: Para representar los usuarios. 7.1. las unidades organizativas. sus relaciones y sus estructuras.2.1: ARIS. Este ciclo de vida no tiene car´ acter procedural y lo que hace es establecer distintos niveles de acuerdo a su proximidad a la tecnolog´ ıa. Desde este punto de partida y hasta la implantaci´ on del sistema de informaci´ on que estamos desarrollando pasaremos por una serie de niveles descriptivos cuya relaci´ on podemos apreciar en la figura 7. Function View: Para representar las funciones (procesos a desarrollar) y las relaciones existentes entre ellas. Data View: Para representar la informaci´ on que debe ser gestionada por el proceso. Vistas de la arquitectura.1. que carece de detalles y para la que se utiliza un lenguaje que no es formal. Product/Service View: Para representar las relaciones entre las realizaciones de los distintos productos y servicios del proceso que se est´ a modelando.2 66 . Vistas descriptivas La arquitectura del m´ etodo ARIS y las diferentes vistas que lo componen se pueden apreciarse en la figura 7.2. Control View: Es una vista introducida de manera adicional para representar las relaciones entre las diferentes vistas. Figura 7.2. Niveles descriptivos La metodolog´ ıa ARIS describe un ciclo de vida propio.7. De esta manera tendremos un punto de partida para el proceso.

Niveles Descriptivos y sus relaciones.2: ARIS.Figura 7. 67 .

Especificaci´ on del dise˜ no (design specification): Donde se produce el paso de la descripci´ on del nivel de requisitos a una nueva descripci´ on orientada a las tecnolog´ ıas de la informaci´ on. requisitos. dise˜ no e implementaci´ on.3: ARIS. Implementaci´ on (implementation): Concretaremos la descripci´ on tecnol´ ogica del nivel anterior a un software y hardware determinado. 68 . tal y como queda descrito en la figura 7.Definici´ on de requisitos (requirements definitions): En este nivel describiremos de manera formal la aplicaci´ on para que sirva como punto de partida para el traslado de esta informaci´ on a un nivel tecnol´ ogico. Es lo que se denomina el nivel sem´ antico.3 Figura 7. Cada uno de las vistas se describe desde el punto de vista de los tres niveles. Relaci´ on entre vistas y niveles. La uni´ on de estos niveles descriptivos juntos con las vistas del apartado anterior constituyen el n´ ucleo de la arquitectura ARIS.

7. las funciones 69 .1. Las funciones se representan gr´ aficamente con el s´ ımbolo que podemos apreciar en la figura 7.3. 7.4 y dentro de este nivel se pueden agrupar y representar de distintas formas: Figura 7.5: ARIS.4: ARIS. Las funciones administrativas van en la rama izquierda de la Y mientras que las funciones de la rama derecha son funciones t´ ecnicas. ´ Figura 7. Arboles de Funciones Mediante diagramas Y.5. Function View Requirements Definition Debemos de tener en cuenta la definici´ on de funci´ on “tarea t´ ecnica o actividad para conseguir uno o m´ as objetivos“ [19]. S´ ımbolo de Funci´ on. Adem´ as tenemos un divisi´ on adicional.3. Mediante ´ arboles de funciones. Donde las funciones se pueden descomponer jerarquicamente tal y como podemos apreciar en la figura 7.

Objetivo. El tipo de aplicaci´ on se va a representar gr´ aficamente mediante el s´ ımbolo representado en la figura 7. distintos sistemas operativos. Cada una de estas aplicaciones o m´ odulos pueden relacionar adem´ as con: Funciones provenientes del nivel de requisitos.9 y en la figura 7. por ejemplo.7: ARIS. Podemos ver un ejemplo de este tipo de diagramas en la figura 7.2. Mediante diagramas compatibles con el modelo de referencia SAP R/3. interfaces o sistemas de bases de datos. 70 . Design Specification La especificaci´ on del dise˜ no de la Function View contiene la descripci´ on del tipo de aplicaci´ on y la estructura modular de la aplicaci´ on entendiendo por modulo un componente de la aplicaci´ on que se puede ejecutar de manera independiente.10 podemos ver una descomposici´ on modular de un tipo de aplicaci´ on.8 Figura 7.3.6. Diagrama Y. que se describen mediante el s´ ımbolo de la figura 7. Asignaciones de la aplicaci´ on para relacionarla con.6: ARIS. 7.de planificaci´ on van en la parte superior mientras que las funciones de control van en la parte inferior. Mediante diagramas de objetivos. Figura 7.7 y que pueden tambi´ en relacionarse de manera jer´ arquica tal y como podemos ver en la figura 7.

Figura 7. 71 . Figura 7. Aplicaci´ on.´ Figura 7. Descomposici´ on modular de una aplicaci´ on. Arbol de Objetivos.10: ARIS.9: ARIS.8: ARIS.

No hay que confundir este concepto con el concepto de tipo de aplicaci´ on del apartado anterior donde nos refer´ ıamos a la aplicaci´ on como a un conjunto de sistemas con las mismas caracter´ ısticas tecnol´ ogicas.3.1. Figura 7.4.11: ARIS. DTD. 7. Para llevar a cabo esta descripci´ on del modelo de datos en [19] se nos dan varias posibilidades: El modelo relacional.4. mediante por ejemplo. Aplicaci´ on y m´ odulo en el nivel de implementaci´ on. Implementation En el nivel de implementaci´ on tendremos aplicaciones que pueden ser identificadas de manera un´ ıvoca. Data View Requirements Definition La definici´ on de requisitos de la vista de datos incluye una descripci´ on del modelo de datos del dominio sobre el cu´ al vamos a trabajar.11 donde tenemos la representaci´ on de un m´ odulo y una aplicaci´ on dentro del nivel en el que nos encontramos. el n´ umero de licencia. IE Data Model. con m´ ınimos cambios tal y como podemos apreciar en la figura 7. 72 . Los diagramas del nivel de implementaci´ on ser´ ıan similares a los del nivel anterior.El uso de pantallas y listas usadas o generadas por el sistema de informaci´ on. 7. El modelo relacional extendido. SEDAM MODEL.3. SAP SERM. Adem´ as dentro de este nivel ARIS introduce una serie de diagramas adicionales: Diagramas de materiales que son entradas y salidas de las funciones del proceso de negocio. 7.

Relaci´ on.3. Las diagramas de jerarqu´ ıas de autorizaci´ on para el acceso de los distintos roles a los datos.2.Para ello utilizaremos los diagramas de relaciones y los diagramas de asignaciones de atributos. Relaci´ on Entidad-Relaci´ on-Atributos.4.12: ARIS. El concepto de relaci´ on describe la asignaci´ on de valores. Implementation Consiste en la elaboraci´ on de un diagrama de tablas concret´ andolo en un sistema gestor de bases de datos concreto.12 y su relaci´ on con la entidad de origen y los atributos que lo componen la podemos ver en la figura 7. Se representa mediante la figura que podemos ver en la figura 7. Diagramas de costes.Estructura del DataWareHouse. Tendremos dos entidades gr´ aficas 73 .13: ARIS. dentro de un dominio concreto.4.13 Figura 7. 7. Design Specification En este nivel se transforman las estructuras l´ ogicas definidas en el nivel de requisitos de tal manera que adopten una forma que nos permita posteriormente plasmarlas en un sistema gestor de base de datos concreto. Figura 7. Modelos de datos de gesti´ on del proyecto. a los atributos de una ocurrencia de una entidad. 7.

1. Organization View Requirements Definition Las compa˜ n´ ıas son estructuras sociales complejas. hasta hace poco no se ha tenido en cuenta el an´ alisis de la organizaci´ on como uno de los factores a tener en cuenta en el desarrollo de sistemas de informaci´ on. Asignaci´ on de campos a un SGBD concreto. sin embargo. Un ejemplo de este tipo de diagrama lo podemos ver en la figura 7.15. 7. Con estas dos entidades b´ asicas podemos representar Figura 7. la tabla y el campo cuya representaci´ on la podemos ver en la figura 7.14. el organizativo que recoge las reglas que rigen la estructura est´ atica de la propia empresa.15: ARIS.14: ARIS.b´ asicas para dichos diagramas. Figura 7.5. Estas estructuras complejas se pueden considerar desde dos puntos de vista. En l´ ıneas generales el objetivo de toda organizaci´ on es siempre conseguir una reducci´ on de costes.Tradicionalmente para alcanzar este objetivo se han 74 . Tabla y campo de tabla. 7. y el procedural que comprende las reglas que rigen su comportamientos. varios tipos de diagramas entre ellos el de asignaci´ on de campos a su representaci´ on en un sistema concreto.5.

la localizaci´ on de los mismos o las persona concretas que ocupan dichos puestos. Organizational Chart. o bien estructurar la compa˜ n´ ıa de manera funcional o bien estructurar la compa˜ n´ ıa de acuerdo a las diferentes ´ areas de productos existentes. sea del tipo que sea. Unidad organizativa se define como “quienes realizan las tareas que deben ser desarrolladas en orden para alcanzar objetivos de negocio“[19]. una serie de diagramas para poder representar la estructura de nuestra empresa. dentro de este nivel de la vista organizativa.16: ARIS. 75 . En el momento actual las situaciones y el mercado son tan complejos que hacen necesarios la existencia de estructuras flexibles e h´ ıbridas que puedan modificarse para adaptarse lo m´ as r´ apidamente posible tanto a los cambios externos como internos. Figura 7. Podemos ver un ejemplo de este tipo de diagramas en la figura 7. El m´ etodo y la arquitectura ARIS tienen muy presente todo lo anterior y nos proporciona.16 donde la unidades organizativas se representan mediante elipses y adem´ as mediante rect´ angulos podemos representar los componentes de esa unidad y que personas encarnan a dichos componentes.seguido dos enfoques. Organizational Chart El organizational chart es una forma de representar la estructura organizativa de una empresa mediante unidades organizativas (organizational units) y sus relaciones atendiendo a una serie de criterios como los puestos de trabajos y las relaciones jer´ arquicas entre ellos.

En el nivel m´ as bajo se representan los Breaks que son periodos de tiempo durante los cu´ ales no se realiza trabajo y de los que conocemos el comienzo y la duraci´ on. Los tipos de materiales son asignados como entrada o salida a las funciones. Para ello dispondremos de elementos como nodos de red. 7. elementos de interconexi´ on y hardware conectado a la red 7.5. Figura 7.2. En el siguiente nivel se colocan los Shift que son periodos donde s´ ı que se realiza trabajo y de los que tambi´ en conocemos su comienzo y su duraci´ on. Material Flow Modeling-Technical Resources: Sirve para ilustrar el flujo de materiales en los modelos de procesos. Nos van a servir para representar las transformaciones de los materiales.5.17. Design Specification. Implementation En el nivel de implementaci´ on de la vista organizativa distinguimos dos tipos de diagramas: Network Diagrams: Que es la realizaci´ on concreta de la topolog´ ıa de red que ha sido descrita en el nivel anterior. Podemos ver un ejemplo en la figura 7.Topolog´ ıa de Red En este nivel de la vista organizativa podremos representar los diferentes elementos de red que van a permitir las comunicaciones entre los componentes de un Organizational Chart. Es un diagrama multinivel.17: ARIS.Shift Calendar Shift Calendar es un diagrama para representar disponibilidad tanto de recursos como de personas.3. Adem´ as para estos dos elementos podemos a˜ nadir atributos que nos sirvan para representar la periodicidad. Network Diagram 76 .

7. 77 .18 muestra un ejemplo de este tipo de diagramas. La figura 7.1.18: ARIS. Figura 7.6. Requirements Definition Relaci´ on entre Function View y Organizational View El objetivo del diagrama con el que vamos a expresar la relaci´ on entre estas dos vistas es asignar las responsabilidades de la realizaci´ on de las distintas funciones a los distintos componentes que forman un Organizational Chart. Function Allocation Diagram: Para ilustrar la transformaci´ on de los datos de entrada en los datos de salida. Control View/Process View La Control View/Process View es la vista que nos va a permitir relacionar las vistas anteriores.6. Relaci´ on entre Function View y Data View Para establecer esta relaci´ on vamos a utilizar varios tipos de diagramas que posteriormente podremos combinar. EPC( Event Driven-Even Process Diagram) que nos van a a permitir representar la secuencia de las distintas funciones dentro del proceso de negocio. Podremos hacerlo a distintos niveles de detalle y a˜ nadirle los roles o responsabilidades que realizan esta transformaci´ on.Ejemplo de relaci´ on entre function view y organizational view. 7.

Information Flow Diagram: Para representar el flujo de informaci´ on entre funciones. Value-Add Chain: Para enlazar las funciones con el valor a˜ nadido que ´ estas crean para la compa˜ n´ ıa. Classification Diagrams. Rule Diagramas: Para expresiones complejas con los operadores OR/AND/XOR: Communication Diagram: Para agrupar los procesos de acuerdo a las comunicaciones entre unidades organizativas. Tambi´ en se pueden establecer distintos niveles de detalle. Todos estos diagramas poseen una serie de elemento gr´ aficos b´ asicos que podemos ver en la tabla 7.1 y que se pueden combinar para formar diagramas complejos tal y como podemos apreciar en la figura 7.19. Tipo Funci´ on Eventos Imagen Operaciones Datos Cuadro 7. 78 . Event Diagram: Para describir la evoluci´ on del estado de un objeto a lo largo del tiempo.1: Elementos de EPC Relaci´ on entre Function-Organizational-Data Juntamos las tres vistas anteriores. nos permitir´ a obtener una serie de diagramas adicionales: EPC con elementos de las tres vistas anteriores.

Adem´ as de estos diagramas ARIS para este nivel nos da la posibilidad de utilizar otros muchos diagramas.6.20. Screen Diagram: Para representar las pantallas de la aplicaci´ on a lo largo del proceso de desarrollo. De esta manera tendremos por ejemplo diagramas con flujos concretos de datos y diagramas con asignaciones de roles y datos a un hardware concreto. Ejemplo de diagrama EPC Input/Output Diagrams. tal y como queda especificado en [19].19: ARIS. 79 .Access Diagram (Physical) En el nivel de implementaci´ on de la vista actual se tienen en cuenta los mismos aspectos que en el nivel de dise˜ no pero concret´ andolo a un sistema en concreto. Podemos ver un ejemplo en la figura 7.3. 7. Program Flow Chart: Para representar el flujo de control de un programa.Figura 7. Design Specification En el nivel de dise˜ no de la vista Control View/Process View tendremos la posibilidad de utilizar los siguientes diagramas: Access Diagrams: Para expresar las relaciones entre los elementos del nivel de dise˜ no de las diferentes vistas. 7. Implementation.6.2.

Product tree diagram: En el nivel de requisitos.Figura 7. Podemos ver un ejemplo de este tipo de diagrama en la figura 7. Ejemplo Access Diagram Nivel de Dise˜ no 7. Product/service tree: Para representar de manera jer´ arquica los productos.20: ARIS. 80 . Product selection matrix diagram: Para representar la relaci´ on entre los roles. Product allocation diagram: Para representar que unidades organizativas proporcionan o usan los productos. Podemos ver un ejemplo de este tipo de diagramas en la figura 7.21. Product/service exchange diagram: Para mapear la creaci´ on de productos y servicios y su intercambio dentro de lo l´ ımites de la compa˜ nia. Product/Service View ARIS proporciona distintas formas (diagramas) de describir los productos y servicios proporcionados por una compa˜ n´ ıa. que funciones son necesarias para su creaci´ on y los ojetivos relacionados con los mismos. los productos generados y los objetivos.7. Competition model diagram : Para representar relaciones de los productos y servicios de una compa˜ n´ ıa con los clientes que est´ an utiliz´ andolos y con los partners de la propia compa˜ nia.22. se utiliza para analizar la composici´ on de los productos.

22: ARIS. Figura 7. Ejemplos de Product Selection Matrix Diagram.Figura 7.21: ARIS. Ejemplo de Product Allocation Diagram. 81 .

Frente a todas estas caracter´ ısticas ventajosas debemos analizar la expresividad de los diagramas EPC que es la notaci´ on de la metodolog´ ıa ARIS para expresar los procesos de negocio que. pese a lo elevado del precio de todas y cada una de las distintas herramientas. integraci´ on e implementaci´ on de un sistema de informaci´ on.7. Posee ciertas caracter´ ısticas que hacen que sea. por otra parte. Permite una vista multinivel de los procesos. Fue creada conjuntamente con un conjunto de herramientas [5](para cubrir todo tipo de actividades) por la compa˜ nia IDS Scheer [4]. es un gran impedimento para el intercambio de modelos entre herramientas de distintos vendedores (lo que favorece los intereses comerciales de algunas compa˜ n´ ıas).8. Conclusiones sobre ARIS ARIS es una metodolog´ ıa compleja (por su gran extensi´ on) cuya notaci´ on cubre todos y cada uno de los aspectos relacionados con el desarrollo. En [31] el autor hace un intento de formalizaci´ on de los diagramas EPC transform´ andolas en redes de Petri. siempre que se pueda pagar el precio de una licencia. tal y como queda descrito en [24]. tal y como queda descrito en [31] y en [36] los diagramas EPC pueden ser ambiguos y no tienen una sintaxis bien definida. la ausencia de un sem´ antica formal bien definida. pero de dif´ ıcil comprensi´ on para los no expertos y que que presenta problemas a la hora de expresar patrones que involucran m´ ultiples instancias. una opci´ on a considerar: Los modelos de procesos que se crean (Diagramas EPC) son comprensibles para aquellos que no son especialistas en modelado lo que es un requisito fundamental en cualquier proyecto de gesti´ on de procesos de negocio (BPM)[21]. optimizaci´ on. Estos diagramas han tenido una gran difusi´ on debido precisamente al ´ exito de la metodolog´ ıa ARIS y de otras como SAP R/3 pero pese a ello hay que tener en cuenta que. Actualmente est´ a teniendo gran ´ exito dentro de campo de los procesos de negocio. son el objeto de estudio de esta memoria de investigaci´ on. Integraci´ on con UML [19]. una notaci´ on totalmente formalizada. Soporte tecnol´ ogico para el desarrollo colaborativo. con la posibilidad de tener modelos de alto nivel y tambi´ en niveles con gran nivel de detalle. para el desarrollo de herramientas de an´ alisis de procesos e impide un estudio preciso sobre los patrones de workflow a los que da los que da soporte este tipo de diagramas. Este hecho. 82 . sincronizaci´ on avanzada y cancelaci´ on [35].Incluso se est´ a utilizando dentro del ´ ambito de nuestra propia comunidad aut´ onoma en el campo de la gesti´ on de los servicios de salud.

A lo largo de los a˜ nos ha ido produciendo diversas metodolog´ ıas para distintos aspectos relacionados con la creaci´ on de sistemas de informaci´ on. Adem´ as de esos m´ etodos citados en la lista anterior existen m´ as m´ etodos descritos por IDEF pero que todav´ ıa no han sido desarrollados en profundidad. Podr´ ıa parecer que tanto IDEF0 como IDEF3 pretender cosas parecidas pero existen 3 diferencias fundamentales: 83 . Fue un proyecto iniciado en los a˜ nos 70. IDEF1 para el modelado de informaci´ on. a partir de la descripci´ on dada por un experto“ [11]. Entre los distintos m´ etodos que ha logrado producir cabe destacar: IDEF0 para el modelado de procesos dentro de una organizaci´ on. IDEF0 “es una metodolog´ ıa. a˜ nos en los que conviv´ ıan multitud de especificaciones y m´ etodos incompatibles entre s´ ı.Cap´ ıtulo 8 IDEF 8. IDEF4 para el dise˜ no orientado a objetos.1. gestionar y mejorar procesos de negocio. En el ´ ambito en el que nos encontramos (notaciones y lenguajes de procesos) nos debemos centrar principalmente en IDEF0 e IDEF3. IDEF3 “es una metodolog´ ıa para representar el flujo de trabajo de un proceso. basada en SADT(Structured An´ alisis and Design Technique) que pretende representar de manera estructurada y jer´ arquica las actividades que conforman un sistema o empresa y los objetos o datos que soportan la interacci´ on de esas actividades“ [11]. IDEF5 para describir ontolog´ ıas para la captura de descripciones. IDEF3 para la captura de descripciones de procesos. IDEF2 para el dise˜ no de modelos de simulaci´ on. IDEF1X para el modelado de datos. siendo ICAM Integrated-Aided Manufactoring) es el resultado de una iniciativa de la United States Air Force cuyo objetivo es modelar. as´ ı como sus objetos participantes. ¿Qu´ e es IDEF? IDEF (ICAM Definition Languages.

IDEF0 nos sirve para describir qu´ e hacemos mientras que IDEF3 nos sirve para describir c´ omo lo hacemos. .2. Facilitar un an´ alisis para identificar puntos de mejora. en contraste a los procedimientos no formalizados de modelado de procesos (p.1: Unidades b´ asicas de IDEF0 Entradas: Designan la materia o informaci´ on que es transformada o consumida por la actividad. 84 . Identificar y capturar conocimiento cr´ ıtico sobre un proceso. por el contrario se aplica principalmente a: Documentar un proceso actual (a nivel de detalle). Facilitar un an´ alisis de un proceso en particular. . que bastan para descripciones de flujos m´ as sencillos. IDEF3. IDEF0 facilita el trabajo en situaciones de mayor complejidad y mayores exigencias en cuanto al tratamiento“. en diagramas de flujo. Planear cambios en un proceso 8. IDEF0 esta pensado para la comunicaci´ on con usuarios no t´ ecnicos mientras que IDEF3 es para la comunicaci´ on con el propietario mismo del proceso.ej. Elementos de IDEF0 Seg´ un [26] “.1 Figura 8. Obtener una visi´ on estrat´ egica de un proceso. Proponer alternativas a un proceso.IDEF0 nos va a guiar en la descripci´ on de un proceso (funci´ on o actividad) que es considerado como la combinaci´ on de cinco unidades b´ asicas que interact´ uan tal y como podemos apreciar en la figura 8. Y por tanto IDEF0 se aplica principalmente a: Comunicar reglas y procesos de negocio. IDEF0 nos da una visi´ on estrat´ egica mientras que IDEF3 nos proporciona detalles de actividades terminales.

Diagrama Padre: Los diagramas padres son aquellos que contienen una o m´ as cajas padre. S´ eg´ un la profundidad podemos distinguir los siguientes tipos de diagramas: Diagramas Top-Level o diagramas A-0: Son los diagramas de m´ as alto nivel que nos sirven para representar un proceso de negocio completo y que suelen estar dotados de un nombre muy descriptivo. Descomposici´ on: Divisi´ on de una funci´ on o proceso en las funciones que la componen.Controles: Objetos que regulan c´ omo. y alguno m´ as que podemos ver en [26]. ). cu´ ando y si una actividad se ejecuta o no. Flecha: L´ ınea que modeliza un traspaso de objetos o informaci´ on desde una fuente hasta su uso. Adem´ as de esos conceptos tenemos m´ as conceptos relacionados con los diagramas IDEF0. Diagramas de exposici´ on: Diagramas que s´ olo se usar´ an cuando se requiera un nivel adicional de conocimientos extra. . Se suelen asociar con la parte superior de las cajas. Todos estos tipos de diagramas y los elementos citados anteriormente se rigen por una serie de reglas generales: 85 . Todos los elementos anteriores. Bifurcaci´ on: Punto en el que se dividen uno o m´ as segmentos de flecha. Flecha de control: Flecha que expresa las condiciones requeridas para producir una salida correcta. Flecha l´ ımite: Flecha con un extremo no conectado a ninguna caja o diagrama. nos sirven para construir los diagramas en IDEF0 que son diagramas jer´ arquicos que van introduciendo gradualmente m´ as y m´ as nivel de detalle conforme vamos profundizando en la estructura del modelo. . Mecanismos: Todos aquellos recursos que son necesarios para llevar a cabo un proceso (personas. Diagrama Hijo: Diagramas en los que se puede descomponer el diagrama A-0 y que a su vez pueden descomponerse en otros procesos de mayor detalle. Texto y glosario: Asociados a otro tipo de diagramas para otorgar un punto de vista conciso sobre el mismo. Etiqueta de flecha: Nombre que se le asigna a una flecha. herramientas. Salidas: Todo aquello que es producido por la actividad o proceso. software. Caja: Rect´ angulo que contiene un nombre y es usado para representar una funci´ on. informaci´ on.

Una caja puede tener 0 o 1 flechas de llamada. Podemos apreciar la jerarquizaci´ on de los diagramas IDEF0 en la figura 8.Los diagramas de alto nivel deben tener un n´ umero de nodo A-n. nunca diagonales.2: Figura 8. El n´ umero de caja de la caja del diagrama A-0 debe ser 0. El modelo debe contener un diagrama de contexto A-0 que contenga una sola caja. donde n es igual o mayor que 0. Las flechas deben dibujarse con trazos horizontales o verticales.2: Diagrama jer´ arquico en IDEF0 86 . Una caja puede tener 0 o m´ as flechas de entrada. Cada caja debe tener como m´ ınimo una flecha de control y una flecha de salida. Cada caja de un diagrama que no sea de A-0 debe numerarse en su esquina inferior derecha de 1 hasta 6. Una caja puede tener 0 o m´ as flechas de mecanismo. Cada caja que ha sido detallada debe tener la expresi´ on de la referencia a su diagrama hijo escrito bajo la esquina inferior derecha de la caja.

siempre van a tener un identificador u ´nico y pueden tener una referencia asociada a una actividad de un diagrama de IDEF0. Podemos ver un ejemplo en la figura 8. Para ello utilizaremos diagramas cuyos elementos principales son los siguientes: Unidad de trabajo Links Functions Referents 8. Se expresan mediante la figura 8. Se expresan tal y como vemos en la figura 8.2.3.3 Figura 8.3.4.4: IDEF3 Link de Precedencia Temporal De flujo de objetos: Enfatiza la participaci´ on de un objeto entre dos procesos.3. Unidad de trabajo Las unidades de trabajo representan una actividad. son unidireccionales. pueden iniciarse y terminar en cualquier parte de la actividad (caja). Elementos de IDEF3 IDEF3 pretende. Figura 8.3: Ejemplo de Unidad de Trabajo en IDEF3 8.5. 87 . especificar c´ omo hago lo que he especificado con IDEF0. Tenemos links de distintos tipos: De precedencia temporal: El proceso origen debe acabar antes de que el proceso destino pueda comenzar. Links Los links sirven para representar relaciones restrictivas entre actividades. La sem´ antica es igual a la de precedencia.1.8. tal y como dijimos antes.

3.6: IDEF3 Link Relacional 8.6: Figura 8. Representar la temporalidad (sincron´ ıa/asincron´ ıa) en el flujo de actividades de un procesos. La activaci´ on de una actividad causa la activaci´ on de m´ ultiples actividades. Se representa con la figura 8. Repressentar los puntos en los cu´ ales m´ ultiples procesos convergen en un solo proceso. Figura 8.3. Conexiones Las conexiones en los diagramas IDEF3 nos van a servir para lo siguiente: Representar los puntos en los que un proceso se ramifica en m´ ultiples subprocesos.5: IDEF3 Link de Flujo de Ojetos Relacional: Existencia de una relaci´ on entre los procesos relacionados. La sem´ antica no est´ a definida (la define el usuario).Figura 8.7: IDEF3 Ejemplo de Diagrama con conexiones Y podemos distinguir a su vez entre dos tipos de ramificaciones: Divergencia (Fan-Out): Distribuye el flujo del proceso. tan solo sirve para indicar que el proceso origen empezar´ a antes que el destino. Existen distintos tipos que quedan explicados en el siguiente cuadro resumen: 88 .7. Podemos ver un ejemplo de diagrama con conexiones en la figura 8.

Tipos de convergencia 8. Existen distintos tipos que quedan explicadas en el siguiente cuadro resumen: Tipo de Conexi´ on AND-As´ ıncrono AND-S´ ıncrono OR-As´ ıncrono OR-S´ ıncrono XOR Significado Todas las actividades precedentes deben terminar. Goto: Para construir ciclos. Cuadro 8. Exactamente una de las actividades precedentes terminar´ a. Una o m´ as actividades precedentes terminar´ an al mismo tiempo. Se iniciar´ an al mismo tiempo una o m´ as actividades que suceden a la conexi´ on. ELAB: Para documentar de manera detallada alg´ un gr´ afico.1: IDEF3.3. Note: A˜ nadir cualquier informaci´ on importante a un elemento gr´ afico.Tipo de Conexi´ on AND-As´ ıncrono AND-S´ ıncrono OR-As´ ıncrono OR-S´ ıncrono XOR Significado Todas las actividades que suceden a la conexi´ on se iniciar´ an Todas las actividades que suceden a la conexi´ on se iniciar´ an al mismo tiempo.2: IDEF3. Cuadro 8. Hay varios tipos: Object: Para describir la participaci´ on de un objeto importante en una actividad. Tipos de divergencia Convergencia (Fan In): La terminaci´ on de m´ ultiples actividades provoca el inicio de una actividad. 89 . Todas las actividades precedentes deben terminar al mismo tiempo. UOB(Unit of behavior): Para incluir una actividad descrita sin implicar un ciclo. S´ olo una de las actividades que suceden a la conexi´ on ocurrir´ a. Una o m´ as actividades precedentes terminar´ an. Se iniciar´ an una o m´ as actividades que suceden a la conexi´ on.4. Referents Los Referents son s´ ımbolos especiales cuyo objetivo es dirigir la atenci´ on del lector a otras partes importantes del modelo.

De igual manera. tal y como podemos apreciar en [25].5. los modelos IDEF0 tampoco reflejan de manera correcta las interacciones entre los miembros del equipo.8. entre ellas podemos citar las siguientes[1]: 4Keeps AI0 WIN BPWin Business Object Modelling Workbench CORE Design IDEF Design Leverage IDEF Tools Popkins Systems Architect Pro CAP Pro SIM Process Maker SA/BPR Professional Workflow Modeler 8. 90 .IDEF3 sirve como herramienta para analizar procesos existentes y para dise˜ nar y probar nuevos procesos antes de iniciar cambios reales que pueden ser muy costosos.4.Nos permite modelar actividades y es independiente del tipo de organizaci´ on y del tiempo. Lo ideal. Conclusiones sobre IDEF IDEF0 es una t´ ecnica sencilla pero poderosa que lleva a˜ nos utiliz´ andose de manera eficiente en la industria sobre todo en la etapa de ingenier´ ıa de procesos de negocio. En ese mismo art´ ıculo se ponen de manifiesto las deficiencias de IDEF a la hora de reflejar estructuras organizativas y aspectos relacionados con los objetivos y la caracter´ ısticas cualitativas del proceso. Herramientas para IDEF0 e IDEF3 Existen numerosas herramientas que soportan IDEF. al menos para afrontar un desarrollo de software como proceso de negocio ser´ ıa usar de manera conjunta IDEF0 e IDEF3 representando los detalles de implantaci´ on as´ ı como lo procesos al nivel apropiado en cada momento. IDEF3 nos va a permitir documentar procesos para su estandarizaci´ on o para utilizarlos como gu´ ıa para nuevos integrantes del equipo para as´ ı reducir la curva de aprendizaje.Como punto a destacar existe la posibilidad de combinarlo con otras metodolog´ ıas para agregar secuenciaci´ on y sincronizaci´ on de actividades. En cuanto a su expresividad. IDEF0 e IDEF3 dan soporte a casi todos los patrones de workflow. por lo que hay que tener en cuenta que desde ese punto de vista no es ni un organigrama ni un diagrama de flujo. Nos permite tambi´ en capturar la secuencia temporal y la l´ ogica de decisi´ on que afecta al proceso.

9: Diagrama de Ejemplo en IDEF3 91 .8: Diagrama de Ejemplo en IDEF0 Figura 8.8. Ejemplos sobre IDEF Figura 8.6.

Para ello hemos comprobado el soporte que dan las distintas notaciones a los patrones de workflow. controlar o planificar los mismos). Desde nuestro punto de vista una notaci´ on. deber´ ıa poseer idealmente las siguiente caracter´ ısticas. Permitir una vista multi-nivel de los procesos para partiendo de descripciones m´ as comprensibles de alto nivel tener la posibilidad de alcanzar niveles con gran cantidad de detalles. Capacidad para especificar atributos que nos permitan gestionar los procesos (monitorizar. 92 . dentro del ´ ambito de la ingenier´ ıa del software. Capacidad para especificar las caracter´ ısticas de calidad de los procesos de negocio. La capacidad de modelar la complejidad de los procesos de negocio.Cap´ ıtulo 9 Comparativa de las notaciones presentadas Una vez se han presentado en los cap´ ıtulos anteriores las diferentes notaciones y lenguajes para el modelado y definici´ on de procesos de negocio en este cap´ ıtulo vamos a realizar una comparaci´ on de las mismas atendiendo a una serie de caracter´ ısticas. es decir la expresividad. Ser comprensible para aquellos que no son especialistas en modelado. Esta caracter´ ıstica es especialmente u ´til si con posterioridad se pretende utilizar los modelos para la fase de requisitos. Permitir la integraci´ on y soporte para otro tipo de notaciones que nos facilitar´ a una mejor interacci´ on entre las herramientas que den soporte a estas notaciones. Capacidad para especificar repositorios de procesos que nos permitan la reutilizaci´ on de procesos mediante la utilizaci´ on de conceptos como la variabilidad y la extensibilidad. El primer paso es establecer las caracter´ ısticas en las que nos vamos a fijar a la hora de realizar la comparativa. La capacidad de representar roles y su asignaci´ on a diferentes tareas.

Posibilidad de enlazar de manera directa una actividad con un fragmente de c´ odigo en un lenguaje de programaci´ on. en la tabla que se muestra a continuaci´ on podemos ver un resumen de las relaciones entre las caracter´ ısticas y las notaciones y lenguajes recogidos en esta memoria de investigaci´ on.1: Comparativa de notaciones (1). hhhh Notaci´ on Caracter´ ısticas hh hhhh hh SPEM (1) × × × × × × × × BPMN × × × × × BPMN XPDL jBPMjPDL ARIS (1) × × × × × × × × × × × IDEF AD Expresividad Roles Calidad Reuso Gesti´ on Multinivel Comprensible Integraci´ on y soporte × C´ odigo Herramientas (1) (1) BPMN AD XPDL UML × × XPDL UML SAPR/3 × × × × × Cuadro 9. Una vez se han fijado esta serie de caracter´ ısticas deseables y teniendo en cuenta que en cada uno de los cap´ ıtulos se han analizado detalladamente cada una de ellas por separado. La existencia de herramientas para trabajar con ella. Se deja a terceras notaciones. 93 .

Cap´ ıtulo 10 Conclusiones y Trabajo Futuro El mundo del modelado y definici´ on de procesos de negocio es. que se han elegido por su difusi´ on y aceptaci´ on dentro de la industria. Adem´ as de las notaciones y lenguajes descritos en esta memoria. herramientas y compa˜ n´ ıas con muy distinta actividad y objetivo empresarial. un mundo confuso donde conviven multitud de notaciones. y centr´ andonos en el ´ ambito de la ingenier´ ıa del software.a´ un a d´ ıa de hoy. lenguajes. no debemos olvidarnos de citar otros como: Yawl (Yet Another Workflow Language) Redes de Petri ebXML UBL RosettaNet Alf IPSE Marvel PMDB SOCCA SPADE TRIAD POP* SMDSDM ISO/IEC 10746 94 . grupos de investigaci´ on con distintos enfoques.

En esta situaci´ on. BPEL como lenguaje de ejecuci´ on concretando en la tecnolog´ ıa de servicios web lo expresado con alguna de las dos notaciones anteriores. la industria del modelado de procesos de negocio parece que tiende a centrarse en tres est´ andares[27]: BPMN como notaci´ on gr´ afica para describir los procesos de negocio de un workflow y con el prop´ osito de ser comprensible por todos los usuarios participantes.tiene como requisito previo la descripci´ on del proceso de desarrollo de una f´ abrica BDD/SOA. que pertenece al Departamento de Lenguajes y Sistemas de la Universidad de Sevilla. no se hizo de acuerdo a factores cualitativos sino que se tuvo en cuenta factores tan apriori poco t´ ecnicos como la disponibilidad de las mismas. Antes de cualquier posible elecci´ on deberemos analizar detenidamente cu´ al es el dominio del problema a solucionar. Esta tarea que est´ a directamente relacionada con el trabajo que se est´ a llevando a cabo dentro del grupo de investigaci´ on WEBFACTORIES. Proponer una u ´nica notaci´ on como resultado de esta memoria ser´ ıa sin duda un error. Una vez realizada la revisi´ on bibliogr´ afica. La notaci´ on elegida debe dar soporte al problema. ”Definici´ on de Modelos de Procesos de Desarrollo Software para F´ abricas BDD/SOA.EKA En relaci´ on a la elecci´ on de las herramientas. pese a que hay que hacer un an´ alisis previo del problema. Sin embargo. tambi´ en es cierto que actualmente nos encontramos en un per´ ıodo donde se est´ a produciendo una convergencia hacia una situaci´ on en donde los procesos se tienden a expresar de dos formas: Mediante una notaci´ on gr´ afica que de soporte a todos los workflow patterns [32]. Cada una de estas notaciones. la revisi´ on bibliogr´ afica que se ha hecho abre bastantes nuevas l´ ıneas en la investigaci´ on. al menos permiti´ endonos expresar el proceso de trabajo. como ya se dijo en anteriores cap´ ıtulos. si seguimos el programa establecido dentro del trabajo de investigaci´ on del que surgi´ o esta memoria.el siguiente paso ser´ ıa estudiar el proceso a modelar y elegir la notaci´ on m´ as acorde con dicho proceso. XPDL como formato para almacenar e intercambiar definiciones de procesos permitiendo a una herramienta modelar procesos en BPMN para que otra herramienta pueda leerlos.lenguajes y herramientas tiene sus propias peculiaridades y caracter´ ısticas.y proporcionarnos una herramienta que nos permita realizar las actividades necesarias. Sin embargo. ya sea u ´nicamente el modelado y la definici´ on o sean otras como la simulaci´ on o la automatizaci´ on de ciertas partes del proceso. Mediante un lenguaje expresado en XML que represente los descrito gr´ aficamente y que nos permita el intercambio de las definiciones de procesos entre distintas herramientas. y tras unos a˜ nos donde han convivido gran cantidad de notaciones. Al profundizar en el campo del modelado y definici´ on de procesos de negocio han surgida nueva posibilidades interesantes hacia las 95 .

como la gesti´ on de procesos sanitarios. elegir cu´ al es la l´ ınea a seguir y profundizar en ella para obtener esta vez resultados investigadores. algunas de las que m´ as inter´ es suscitan al autor de esta memoria son: La aplicaci´ on de estas t´ ecnicas para la elicitaci´ on de requisitos para comprobar. La obtenci´ on de casos de uso de manera autom´ atica a partir de modelos de procesos con la posibilidad de integrar esta operaci´ on dentro de herramientas para la gesti´ on de requisitos como REM. La integraci´ on de modelos de procesos dentro del enfoque de desarrollo MDD/MDD mediante la realizaci´ on de transformaciones de estos modelos en otros modelos PIM o PSM dentro de un dominio determinado. desde el metamodelo que define el proceso hasta el metamodelo de requisitos de la aplicaci´ on. dominio en el que ya se est´ a investigando en Andaluc´ ıa[24] y que requiere el estudio de especificaciones adicionales como HL7v3[3]. mediante estudios de campo. aspectos como que los diagramas BPMN sean m´ as f´ aciles de entender que los Diagramas de Actividad de UML y que sean comprensibles por todos los usuarios. El estudio y an´ alisis de la eficiencia de procesos de desarrollo ya establecidos. sirviendo as´ ı como elemento de gran utilidad para la comunicaci´ on cliente-desarrollador-analista. El siguiente paso ser´ a pues. especialmente los clientes.que dirigir una posible futura tesis. 96 . La aplicaci´ on de las tecnolog´ ıas de modelado de procesos a casos reales. Para ello en un primer paso deberemos modelar los procesos y posteriormente deberemos utilizar herramientas de simulaci´ on que nos permitan analizar los procesos con el objetivo de poder detectar los posibles puntos de mejora. En ese caso ser´ a necesario una transformaci´ on entre metamodelos.

Funcionario de carrera. (Universidad de Sevilla). Cursos de Doctorado. 97 . T´ ecnico de automatismos (Plataforma Europa: Grupo Inditex). Experiencia Profesional: Programador de aplicaciones de banca electr´ onica (C++)(Intercomputer). Profesor de Ense˜ nanza Secundaria especialidad Inform´ atica (Junta de Andaluc´ ıa). Master en Imagen de S´ ıntesis y Animaci´ on por Ordenador (Universidad de la Islas Baleares).Ap´ endice A Curriculum vitae Nombre: Juan Diego P´ erez Jim´ enez. Estudios: Ingenier´ ıa Superior Inform´ atica (Universidad de Zaragoza).

omg.omg. request for proposal edition. Noviembre 2004. Mda. http://www. [8] BPMI. final adopted 1. About bpm miracles an what you can expect in real life. http://www. http://www. 2004. Business Process Notation Specification. Bussiness Process Management Inititive.hl7.htm.org/standards/xpdl.bpmi.org.1 final adopted edition.omg. 2003. Object Management Group. Business process management initiative. Comisi´ on Federal de Electricidad. Workflow Management Coalition. OMG Object Management Group. BPMI.com/international/english/products/53961. Addisson Wesley.htm. Software Process Especification Metamodel Specification. UML Distilled.wfmc. Febrero 2006. [7] Tom Baeyens.com/blog/tbaeyens/2006/07/05/.com/. [14] OMG Object Management Group. OMG Object Management Group. [12] OMG. http://blogs.tudelft. 1. [15] OMG Object Management Group. [13] OMG. M´ etodos de modelado idef0 e idef3 y uso b´ asico del programa bpwin. http://www. http://www. scheer. Object Management Group. Enero 2005.ids- [10] Martin Fowler.org/. http://www.Bibliograf´ ıa [1] Herramientas que soportan idef. http://www. Technical report. 98 .isa. 3 edition. [4] Ids scheer. [6] Object management group. Software Process Especification Metamodel Specification. http://uml-directory. http://www. Xpdl tools.nl/ hom- [2] Herramientas uml. [5] Ids scheer products. mes/toolsub.org/v3ballot/html/welcome/environment/index.jboss.org/.0 edition.org/mda.its. [11] Jes´ us Martinez San Germ´ an. Julio 2006. [3] Hl7 v3. the architecture of choice for a changing world.html.ids-scheer. [9] WfMC.

ebizq. Wohed. [17] OMG Object Management Group. [18] David Hollingsworth. Universidad de Sevilla. jBOSS jBPM USER GUIDE. The bpmn-xpdl-bpel value chain. [22] jBoss Company.wordpress. Mayo 2006. [29] N.D. van der Aalst. [23] jBOSS Inc. Escuela Superior de Ingenieros.net. ACM. [20] Business Process Management Initative(BPMI). Universidad de Sevilla. 007. OMG Object Management Group.bpmn.pp75-90. Software Process Especification Metamodel Specification.1 edition. ¿Por qu´ e omg ha elegido bpmn para modelar procesos de negocio si ya existe uml? Technical report. Formalization and verification of event-driven process chains. Frami˜ nan. Vienna University of Technology. Hofstede. 2006. http://www. and P.1 edition. P´ erez A. communications of the acm. [21] Curtis B.[16] OMG Object Management Group. Pyke. Enero 2007. http://www. W. 2. pages 195–104. [30] Keith Swenson.jboss. vol 35. 3. [24] Rafae˜ n Ruiz-Usano Pedro L.htm.com/products/jbpm/overview. National Institute of Standars (NIST). In Proceedings of the Third Asia-PAcific Conference on Conceptual Modelling (APCCM).1 edition. Technical report. An evaluation of conceptual business process modelling language. Enero 2006.org/BPMN Supporters.1. OMG Object Management Group. Workflow Management Coalition. December 1993. Russel. Is XPDL the silentworkhorse of BPMN? http://www. [19] IDS Scheer. Unified Modeling Language. 2. [26] NIST. Integrated definition for function modeling (IDEF0). 2006. http://kswenson. Febrero 2007. jBoss a division of Red Hat Company. The Workflow Reference Model. Kellner M. 99 . volume 53 of Conferences in Research y Practice Information Technologies. Aris Method. Hobart. Technical report. VanderAlst. Febreo 2006. Eindhoven University of Technology. [28] J. Gonz´ alez Jos´ e M. Technical report. [25] Beate List Birgit Korhnerr. 1998. Dur´ an A. 2004. A.com/2006/05/26/bpmn-xpdl-and-bpel/. [27] J. 2007. Technical report. Ruiz. Julio 2004. Bpmn implementors and quotes.0 final adopted edition. 1. [31] W. Experiencias en la aplicaci´ on de modelado de procesos de negocio(bpm) en el sector sanitario. 1992. On the suitability of uml activity diagrams for business process modelling. Process modelling. jbpm overview. Enero 1995. Carlos Parra. Over J.

Technical report. van der Alst.0 edition. Hofstede B. Technical report. 2000. [35] A. van der Aalst A. White. [37] Stephen A.[32] W. Department of Technology Management Eindhoven University of Technology. Process Definition Interface – XML Process Definition Language. 2. Patter-based analysis of uml activity diagrams. Eindhoven University of Technology. [36] E. Pattern-base analysis of bpmn. 2005. Department of Technology Management Eindhoven University of Technology. van der Alst. 2002. Technical report. [34] Petia Wohed Wil van der Aalst Marlons Dumas Arthur Hofstede Nick Russell. Technical report. [38] Workflow Management Coalition. Workflow patterns: On the expressive power of (petri-net-based) workflow languages. Workflow patterns. 100 . 2004. Technical report. [33] Petia Wohed Wil van der Aalst Marlon Dumas Arthur Hofstede Nick Russel. Eindhoven University of Technology. 2002. On the semantics of epcs: A vicious circle. J. Barros. Klinder W. Introduction to bpmn. Hofstede W. Desel. IBM Corporation. Kiepuszewski A. Department of Technology Management Eindhoven University of Technology. Octubre 2005. Technical report. 2004.P.