De Procesos SPEM a Procesos BPMN. Un enfoque...

De Procesos SPEM a Procesos BPMN.

Un enfoque basado en MDE

Diego Esteban Cruz Rojas12, Marıa Cecilia Bastarrica1, Helga Duarte-Amaya2

1 Computer Science Department, Universidad de Chile, Chile2 Departamento de Ingenierıa de Sistemas e Industrial, Universidad Nacional de

Colombia

Abstract. Las empresas de software definen sus procesos de desarrollocomo una forma de organizar sus actividades, y como un medio paraalcanzar una posible certificacion ISO o una evaluacion CMMI. Existenestandares como SPEM y herramientas libres como EPF Composer quepermiten que toda empresa pueda contar con un soporte robusto y acce-sible para la definicion de sus procesos. Pero esta definicion es trabajosa ycara, y muchas veces los procesos ası definidos no se aplican en la practicaporque resulta complejo y burocratico para los desarrolladores. Por otrolado BPMN se ha convertido en un estandar para la definicion de pro-cesos de negocios, proporcionando claridad grafica y la posibilidad detransformar automaticamente estos procesos para ejecutarlos sobre unaplataforma BPMS. Sin embargo, BPMN no esta definido especıficamentepara procesos de software y por lo tanto tiene mucho menor especifici-dad que SPEM. En este artıculo proponemos un enfoque basado en MDEpara la definicion de procesos en SPEM y su transformacion automatica aprocesos BPMN. Ilustramos su aplicacion con un caso real de la empresachilena Mobius.

1 Introduccion

La definicion rigurosa de procesos de software ha mostrado ser un medio conve-niente para lograr un mayor control sobre el desarrollo, permitiendo a las empre-sas mejorar su productividad y la calidad de sus productos. Esta definicion deprocesos posibilita tambien a las empresas alcanzar una certificacion ISO [14] ouna evaluacion CMMI [20], lo cual les proporciona tambien una ventaja comer-cial. Definir formalmente los procesos trae consigo las ventajas de los metodosformales, tales como la posibilidad de analizar el proceso [12] o bien adaptarloautomaticamente a distintos contextos de proyectos [13] permitiendo en principiomejorar aun mas la calidad y la productividad. SPEM 2.03, que es el estandarde la OMG, es el lenguaje mas utilizado a nivel industrial para la formalizacionde procesos [15], probablemente por la existencia de EPF Composer4, una he-rramienta de libre acceso que da soporte a este estandar y facilita su utilizacion.

3 Software Process Engineering Metamodel [8]4 Eclipse Process Framework Composer: http://www.eclipse.org/epf/

Proceedings of the XVII Ibero-American Conference on Software Engineering (CIBSE2014)

April, 23-25, Pucón, Chile Universidad de La Frontera, Temuco, Chile. 41

Sin embargo, tener el proceso formalmente especificado no asegura que sea efec-tivamente aplicado por parte de los desarrolladores. Esto hace que los esfuerzosinvertidos en la formalizacion tengan un retorno de la inversion incierto, y quizashasta no se justifique la inversion en algunos casos. Un proceso de negocio esun conjunto estructurado de actividades logicamente relacionadas que, tomandouna o varias entradas, produce un resultado que tiene valor para una organi-zacion en la medida que contribuye a alcanzar sus objetivos [11]. BPMN5 es lanotacion estandar para la especificacion de procesos de negocios. En este con-texto, un proceso de desarrollo de software es un proceso de negocio especıficopara una empresa de software.

Tener una especificacion del proceso de desarrollo de software en BPMN per-mite a las empresa visualizar el flujo de ejecucion a seguir durante el desarrollo,o sea una vision dinamica de esta actividad, en contraste con la vision estaticaaunque muy rica en detalles que brinda SPEM [17]. Para una empresa es muycaro definir el proceso de desarrollo de software en SPEM y el proceso de negocioasociado en BPMN, ademas de mantener la consistencia de ambos, y mas aunsi se trata de pequenas empresas, las cuales constituyen la mayor parte de lasempresas de software en el mundo, y en particular de Chile [21].

La ingenierıa dirigida por modelos (MDE) es una estrategia de desarrollode software basada en la definicion de modelos formales y su manipulacion au-tomatica a traves de transformaciones de modelos [18]. En este trabajo pro-ponemos la transformacion automatica de modelos de proceso especificados enSPEM 2.0 usando EPF Composer a procesos de negocio utilizando BPMN, detal modo de servir de puente a las especificaciones estatica y dinamica del de-sarrollo de software y poder obtener los beneficios de ambos enfoques. Si bienexiten otras propuestas para esta misma tarea, nuestro trabajo es mas rico encuanto a elementos que es capaz de transformar. La transformacion se imple-menta usando Extensible Stylesheet Language Transformations (XSLT) [4], ellenguaje de transformacion propuesto por la W3C. Si bien XSLT no es uno delos lenguajes mas usados en MDE, el proceso en BPMN no tiene un formato demodelo sino un formato XML. Los lenguajes de transformacion tales como ATL6

o QVT7 requieren que tanto la entrada como la salida sean modelos. Logramoscon XSLT un resultado equivalente pero evitando el problema de formatos.

Validamos la factibilidad tecnica de realizar esta transformacion usando elproceso definido en la empresa chilena Mobius. Los resultados obtenidos apuntana que la solucion es factible pero impone ciertas exigencias sobre la calidad dela especificacion del proceso en SPEM, lo cual solamente apunta a mejorar lacalidad.

El resto del documento se estructura de la siguiente forma. El marco teoricoes presentado en la seccion 2. En la seccion 3 presentamos otros enfoques para latransformacion de procesos de software y procesos de negocio usando MDE. En laseccion 4 presentamos la transformacion involucrada en la solucion propuesta. La

5 Business Process Management Notation6 Atlas Transformation Language7 Query View Transformation



aplicacion practica en el proceso de la empresa Mobius se presenta en la seccion 5.Finalmente, en la seccion 6 incluimos las conclusiones de nuestro trabajo, asıcomo indicamos tambien el trabajo futuro.

2 Marco Teorico

Business Process Management (BPM) es la capacidad de gestionar las activi-dades de un proceso de negocio. Esto implica descubrir, disenar, desplegar,ejecutar, interactuar, operar, optimizar y analizar los procesos desde la per-spectiva del negocio, y no su implementacion tecnica [19]. Un Business Pro-cess Management System (BPMS) es una plataforma computacional construidapara gestionar procesos de negocios. Un BPMS es responsable de coordinar lastransacciones definidas por el proceso, manejar las instancias de los procesos, yprocesar las transacciones distribuidas. BPMS extiende el concepto de workflowcon mayor control sobre las conversaciones, control y gesion de diferentes hilosde ejecucion, ejecucion paralela, manejo de errores, compensacion de transac-ciones, y soporte para datos XML complejos, entre otros. Existen actualmentedos notaciones estandar para la especificacion de procesos de negocio: UnifiedModeling Language Activity Diagrams (UML AD) [9] y Business Process Man-agement Notation (BPMN) [10]. Ambas notaciones son promovidas por OMG,pero BPMN esta mas enfocada al proceso de negocio8. Para la ejecucion de losprocesos de negocio es necesario traducir la notacion de diseno del proceso a unlenguaje de ejecucion. Para eso, la Workflow Management Coalition (WfMC) hadefinido XML Process Definition Language (XPDL) [3] que define la importaciony exportacion de procesos para poder ser ejecutados por diversas aplicaciones.Por su parte, el Advancing Open Standards for the Information Society (OASIS)ha definido Business Process Execution Language (BPEL) [7], un lenguaje deejecucion basado en XML disenado especialmente para el control centralizadode la invocacion de servicios web. Existen propuestas que tansforman BPMN aXPDL [1] y a BPEL [5].

XSLT es un lenguaje de programacion declarativo que, usado desde la per-spectiva de MDE, permite generar modelos a partir de modelos fuente, todosellos estructurados como XML. XSLT 1.0 fue parte de la recomendacion XLSdel consorcio W3C publicada en 1999. En julio de 2012 se publico un borrador dela version 3.0 con marcadas mejoras para la transformacion de streaming (flujode datos de transformaciones) y caracterısticas que permitirıan la modularidaden modelos complejos. El uso de XSLT supone un conjunto de restricciones talescomo que el procesador XSLT aplica reglas de transformacion sobre un solomodelo fuente.

3 Trabajos Relacionados

Existen propuestas para transformar procesos de software especificados en SPEM2.0 a lenguajes ejecutables por maquinas de workflow, como son XPDL o BPEL.

8 BPMN FAQ: http://www.omg.org/bpmn/Documents/FAQ.htm



Fig. 1. Transformacion de procesos SPEM 2.0 a BPMN con MOSKitt4ME

En [6] se presenta un conjunto de reglas expresadas en OCL para transformarprocesos de software de SPEM 2.0 a XPDL. Mientras que en [1] se presentaModelBus, un marco de integracion desde la perspectiva de MDE para cadenasde herramientas; ModelBus se basa en SOA y permite transformar tambien, atraves de restricciones OCL, procesos SPEM a BPEL. Si bien esta estrategia enun unico paso puede parecer en principio mas eficiente, los procesos de desa-rrollo de software modelan actividades eminentemente humanas, y por lo tantohemos visto que las personas prefieren poder visualizar los procesos porque lespermite una mayor comprension de ellos. Es mas, estas propuestas estan orien-tadas a coordinar la ejecucion de proyectos donde participan grupos humanosgrandes, mientras que nosotros estamos mas enfocados en empresas pequenas dedesarrollo de software.

En [16] se propone la transformacion de procesos de software SPEM a proce-sos de negocio en BPMN, pero usando RSL como lenguaje de transformaciones.En [22], se propone la misma transformacion pero usando QVT como lenguajede transformaciones.

Cervera et al. en [2] presentan MOSKitt4ME, una herramienta construidasobre EPF Composer que tambien permite la especificacion de procesos dedesarrollo de software e incluye una extension para transformar estos directa-mente a procesos de negocio en BPMN 2.0. Sin embargo la transformacion queMOSKitt4ME es capaz de realizar se limita solamente a las tareas, tal como semuestra en la Fig. 1.



Fig. 2. Transformacion de procesos SPEM 2.0 a procesos de negocio BPMN

4 Transformacion de SPEM a BPMN

Los procesos de desarrollo de software especificados en EPF Composer se definena partir de dos modelos: uno con la informacion referente al metodo (contentmethod - model.xmi) y uno con la representacion grafica a traves de los estereoti-pos definidos por el perfil UML de SPEM (activity diagram - diagram.xmi), talcomo se indica en la Fig. 2. En el model.xmi persiste la informacion de todaslas entidades como nodos con estructura, mientras que el diagram.xmi contienesolamente conectores sin estructura, sin embargo el modelo de actividades no esejecutable de por sı.

Al iniciar la transformacion los dos modelos fuente se componen en un solomodelo para superar la restriccion del procesador XSLT. La transformacioncomienza recorriendo la estructura de nodos (actividades del proceso) con elproposito de encontrar el nodo padre (actividad raız o padre). El recorrido atraves de los conectores (diagram.xmi) y la contrastacion de la estructura (enel model.xmi) permiten recuperar cada una de las entidades que describen elcomportamiento del proceso de desarrollo, como fases, actividades, tareas, even-tos (inicio/fin) y nodos de decision simples y compuestos (join, merge y fork).Conforme se recuperan las entidades del modelo de entrada, se aplican las reglasde transformacion para el mapeo a entidades en BPMN que permitan la con-struccion del modelo de salida. La tabla de la Fig. 3 muestra la correspondenciaentre los elementos de ambos lenguajes. La conexion de los objetos en BPMN yel establecimiento del flujo del proceso de negocio resultante son posibles recu-perando la informacion del diagram.xmi.



Fig. 3. Correspondencia de elementos de SPEM 2.0 y BPMN

Para conducir de manera explıcita el proceso de seleccion sobre el conjunto denodos, se hace uso de la primitiva <xsl:for-each>; esta genera explıcitamenteun bucle para una coleccion de nodos . La sintaxis es la siguiente:

<xsl:for-each select= >

.....

</xsl:for-each>

El atributo select puede contener cualquier ruta XPath y el bucle reuniraa cada elemento del conjunto de nodos resultante.

Otro recurso que se utilizo para el procesamiento condicional es la sentencia</xsl:if>. Esta permite evaluar expresiones logicas (segun defina la especifi-cacion XPath) y a partir de su resultado producir diferentes salidas. Su sintaxises la siguiente:

<xsl:if test=expresi\’on booleana>

<!Plantilla -- >

</xsl:if>

La Fig. 4 ilustra el fragmento de codigo con el que se procesan los nodos forky join de SPEM, para ser transformados a nodos Gateway de tipo Diverging yConverging respectivamente.

Limitaciones del enfoque. Inconsistencias en la persistencia de los datos en EPFComposer introducen serias dificultades en el desarrollo de la transformacion. Lasinconsistencias entre el contenido del model.xmi y el contenido del diagram.xmidificultan la busqueda de entidades (pues a menudo se representa una misma



Fig. 4. Transformacion de proceso SPEM en BPMN

entidad con diferentes nombres), la navegabilidad en algunos casos se hace im-posible (se pierden los conectores de flujo) y eventualmente entidades que se haneliminado del modelo diagram.xmi siguen existiendo en el model.xmi.

Inicialmente, en el presente trabajo se abordo el diseno de la transformaciondesde la perspectiva de los roles y no desde unidades de trabajo. El proposito fuemapear los roles participantes en el proceso de desarrollo a los correspondientespools en el proceso de negocio obtenido. Sin embargo, tal iniciativa no permitirıarepresentar actividades (subprocesos) en donde estuvieran vinculados diferentesroles (pools). Como el empaquetamiento de actividades en capability patternsresulta una buena practica en la definicion de procesos de desarrollo (lo quefavorece su reutilizacion) y estos reunen tareas desempenadas por diferentesroles, con lo cual los subprocesos obtenidos en BPMN no pertenecerıan a ununico pool, se desistio de tal perspectiva y se trabajo desde las actividades delproceso.

5 Caso de Estudio

Mobius es una pequena empresa chilena de desarrollo de soluciones integradas desoftware y hardware. Tiene aproximadamente tres anos de antiguedad y brindaservicios fundamentalmente al transporte publico de Santiago. Cuenta con aprox-imadamente 30 empleados, entre ingenieros y tecnicos en electronica e ingenierosen computacion. Desde hace un ano han comenzado con la formalizacion de suproceso de desarrollo, pero una vez alcanzada esta meta, desean poder automa-tizar la ejecucion de su proceso a fin de agilizar esta tarea y permitir tener unmayor control sobre la gestion.



Fig. 5. Disciplina de Desarrollo:Proceso de Mobius especificado en SPEM 2.0

El proceso de desarrollo que guıa los proyectos al interior de la companıareune conceptos de RUP y los mezcla con algunas practicas de metodologıasagiles. Esta combinacion le permite alcanzar un proceso formal pero con el su-ficiente dinamismo que le permita adaptarse a proyectos de corta y media du-racion.

Como parte del proceso de desarrollo se definieron cuatro fases: inicio, elabo-racion, construccion y transicion; cinco disciplinas: administracion, arquitectura,desarrollo, requerimientos y testing; y once actividades. Visto con mayor detalle,el proceso incluye 47 tareas, 10 roles y 44 productos de trabajo. Se identificarontambien puntos de variabilidad que posibilitan el ajuste del proceso al contextode cada proyecto.

En la Fig. 5 se muestra el diagrama de actividad de la Disciplina de Desarrollodel proceso de Mobius, modelada en EPF Composer. Cada uno de los ıconos quese muestran corresponde a un estereotipo definido en el perfil UML de SPEM.Este diagrama contiene once tareas e incluye diferentes elementos para definirel comportamiento y el flujo del proceso (nodos fork, join, decision y merge).En la Fig. 6 se muestra el diagrama en BPMN obtenido con la transformacion.En la figura se observa que el modelo obtenido es consistente con el modelo deentrada, conservando el contenido y el comportamiento definido en el diagramade actividad.

En la Fig. 7 se muestra el diagrama relativo a las actividades de Control deCambios del proceso de Mobius. Lo particular en este caso es la inclusion dedos actividades: analisis de requerimientos y planificacion del proyecto. Con estose representa un segundo nivel de profundidad: una actividad contenida dentrode otra actividad. El diagrama BPMN obtenido con la transformacin (Fig. 8)



Fig. 6. Disciplina de Desarrollo: Proceso de Mobius resultante en BPMN

Fig. 7. Disciplina de Control de Cambios: Proceso de Mobius con actividades especi-ficado en SPEM 2.0

representa las actividades como subprocesos y los despliega de forma extendida,detallando el contenido y el comportamiento de todas las actividades.

6 Conclusiones

En este artıculo se mostro un enfoque basado en MDE para la obtencion deprocesos de negocios especificados en BPMN a partir de procesos de software



Fig. 8.Disciplina de Control de Cambios:Proceso de Mobius con subprocesos resultanteen BPMN

especificados en SPEM. Esta transformacion se implemento en XSLT y se validoaplicandola al caso del proceso de la empresa chilena Mobius.

En terminos tecnicos, hemos sido capaces de transformar todos los elemen-tos de proceso de SPEM que tienen un correspondiente en BPMN, de acuerdocon [17]. Las tareas se transformaron como actividades de BPMN, las decisionesde SPEM como decisiones en BPMN, y las actividades de SPEM como sub-procesos de BPMN. Este ultimo punto fue una decision de compromiso: o bienorganizabamos el BPMN en pools y lanes distribuyendo las tareas de acuerdocon los respectivos roles, o bien las agrupabamos por subprocesos; se opto porla segunda opcion. Si bien ambas vistas eran posibles, no se pueden obtener deforma simultanea.

Como parte del trabajo en curso esta el generar el proceso BPMN a partir nosolamente del proceso de software en SPEM, sino tambien a partir del modelo derecursos humanos disponible para llevar a cabo el proyecto. El proceso de negocioque debera ejecutarse sera distinto dependiendo del tamano y las caracterısticastecnicas y de personalidad de las personas que participaran.



References

1. Aitor Aldazabal, Terry Baily, Felix Nanclares, Andrey Sadovykh, Christian Hein,Martin Esser, and Tom Ritter. Automated Model Driven Development Processes.In Proceedings of the ECMDA Workshop on Model Driven Tool and Process Inte-gration, Fraunhofer IRB Verlag, Stuttgart, 2008.

2. Mario Cervera, Manoli Albert, Victoria Torres, and Vicente Pelechano. A Model-Driven Approach for the Design and Implementation of Software DevelopmentMethods. International Journal of Information System Modeling and Design(IJISMD), 3(4):86–103, 2012.

3. Workflow Management Coalition. Process Definition Interface – XML Process Def-inition Language. Technical Report WFMC-TC-1025, version 2.2, WfMC, August2012.

4. World Wide Web Consortium. Extensible Stylesheet Language Transformations.Technical Report Version 1.0, W3C, November 1999. http://www.w3.org/TR/xslt.

5. Lonneke Dikmans. Transforming BPMN into BPEL: Why and How, September2008. http://www.oracle.com/technetwork/articles/dikmans-bpm-101437.html.

6. Yuan Feng and LI Ming-Shu. Towards Software Process Enactment Based on theSPEM2XPDL Model Transformation. Journal of Software, 18:2141–2152, 2007.

7. Advancing Open Standards for the Information Society. Web Services BusinessProcess Execution Language. Technical Report Version 2.0, April 2007.

8. Object Management Group. Software Process Engineering Metamodel SPEM 2.0OMG Beta Specification. Technical Report ptc/07-11-01, OMG, 2007.

9. Object Management Group. Unified Modeling Language Superstructure Spec-ification, version 2.1.1. Technical Report Document formal/2007-02-05, OMG,February 2007. accessed April 2013.

10. Object Management Group. Business Process Model and Notation (BPMN). Tech-nical Report formal/2011-01-03, OMG, January 2011.

11. Michael Hammer and James Champy. Reengineering the Corporation: A Manifestofor Business Revolution. HarperBusiness; Rev Upd edition, October 2006.

12. Julio Ariel Hurtado Alegrıa, Marıa Cecilia Bastarrica, and Alexandre Bergel.AVISPA: a tool for analyzing software process models. Journal of Software: Evo-lution and Process, 2013. To Appear.

13. Julio Ariel Hurtado Alegrıa, Marıa Cecilia Bastarrica, Sergio F. Ochoa, and JocelynSimmonds. MDE software process lines in small companies. Journal of Systemsand Software, 86(5):1153–1171, 2013.

14. JTC 1 Information technology /SC 7. ISO/IEC 12207:2008 Systems and Soft-ware Engineering – Software life cycle processes. Technical report, InternationalOrganization for Standarization ISO, 2008.

15. Marco Kuhrmann, Daniel Mendez Fernandez, and Ragna Steenweg. Systematicsoftware process development: where do we stand today? In Jurgen Munch, Jo AnnLan, and He Zhang, editors, ICSSP, pages 166–170. ACM, 2013.

16. M. Perez Cota, D. Riesco, I. Lee, N. Debnath, and G. Montejano. Transformationsfrom SPEM Work Sequences to BPMN Sequence Flows for the Automation ofSoftware Development Process. J. Comp. Methods in Sci. and Eng., 10(1-2S1):61–72, September 2010.

17. Carlos Portela, Alexandre Vasconcelos, Antonio Silva, Ariane Sinimbu, Elder Silva,Maurıcio Ronny, Wallace Lira, and Sandro Oliveira. A Comparative Analysisbetween BPMN and SPEMModeling Standards in the Software Processes Context.Journal of Software Engineering and Applications, 5(5):330–339, May 2012.



18. Douglas Schmidt. Model-Driven Engineering. IEEE Computer, 39, February 2006.19. Howard Smith, Douglas Neal, Lynette Ferrara, and Francis Hayden. The Emer-

gence of Business Process Management. Technical Report Version 1.0, CSC’s Re-search Services, January 2002.

20. CMMI Product Team. CMMI for Development, Version 1.3. Improving processesfor developing better products and services. Technical Report CMU/SEI-2010-TR-033, ESC-TR-2010-033, Software Engineering Institute, 2010.

21. Software y Servicios Chile A.G.-GECHS y Escuela de Ingenierıa Universidad deVina del Mar. 6to Diagnstico de la Industria de Software y Servicios de Chile.Technical Report version 1.0, 2008.

22. F. A. Zorzan and D. Riesco. Transformation in QVT of Software DevelopmentProcess based on SPEM to Workflows. IEEE Latin America Transactions, 6(7),December 2008.



De Procesos SPEM a Procesos BPMN. Un enfoque...

Documents

Transcript of De Procesos SPEM a Procesos BPMN. Un enfoque...