De los procesos de desarrollo a la definición de procesos workflow

Transcripción

1 De los procesos de desarrollo a la definición de procesos workflow Daniel Romero 1, Marcelo Uva 1 1 Universidad Nacional de Río Cuarto Ruta 36 Km 601 CP X5804BYA - Tel/Fax: {dromero, uva}@dc.exa.unrc.edu.ar Abstract. El modelado de los procesos de negocio es de vital importancia en el desarrollo de toda industria, en particular, en la industria del software. La ingeniería y re-ingeniería de los procesos de negocio apuntan principalmente a elevar la calidad de los procesos de producción y consecuentemente, la de los productos desarrollados. Una de las formas de optimizar la producción es mediante la automatización de los procesos de negocio, lo que implica definir reglas de transición, recursos involucrados, responsables para cada actividad, etc. En el siguiente trabajo se propone una alternativa para el logro de la automatización de los procesos de desarrollo de software. Esta automatización, se obtiene luego de sucesivas transformaciones. Los procesos son modelados en SPEM (Software Process Engineering Metamodel) y luego de una secuencia de pasos, son transformados en procesos workflow. Introducción Un proceso de negocio es un conjunto de tareas lógicamente relacionadas, ejecutadas para obtener un cierto resultado de negocio. El modelado, análisis y administración de estos procesos, ha cobrado gran importancia ante la necesidad de una industria competitiva, dinámica, que se adapte rápidamente a los cambios, y donde se aprovechen al máximo los recursos disponibles. Toda esta situación ha provocado que uno de los objetivos principales de la industria actual sea la automatización de los procesos de producción. Para el logro de este fin, se han venido utilizado tecnologías Workflow. Se denomina workflow a la automatización parcial o total de un proceso de negocio. La WfMC (Workflow Management Coalition), es un conjunto de instituciones que se encarga de identificar áreas comunes de funcionalidad y de desarrollar especificaciones apropiadas para la implementación en productos workflow. Se pretende que esas especificaciones permitan la interoperabilidad entre productos heterogéneos y mejoren la integración de aplicaciones workflow con otros servicios IT tales como correo electrónico y administración de documentos. Dentro de los estándares definidos por la WfMC, se encuentra la Interfaz 1 de definición de procesos workflow. Ésta define un formato de intercambio común para la transferencia de definiciones de procesos entre productos diferentes. Esto es realizado a través de un esquema XML (Extensible Markup Language) denominado

2 Lenguaje de Definición de Procesos XML (XML Process Definition Language - XPDL) [WFMC ]. La incorporación de tecnologías workflows permite automatizar los flujos de información que circulan a través de una determinada industria, posibilitando el secuenciamiento de las actividades y la optimización de los recursos. El caso particular de la industria del desarrollo de software, no es diferente al del resto de las industrias. Dentro de ella, se encuentran los procesos de negocios tendientes a la construcción o generación de un producto (software) de calidad en un tiempo determinado. Actualmente, ingenieros de software trabajan para optimizar los procesos de desarrollo. Los procesos de negocios, dentro de la industria de desarrollo de software son conocidos como metodologías de desarrollo, encargadas de guiar la producción. En este trabajo se propone la optimización del proceso de producción de software mediante la automatización de las metodologías de desarrollo. Para lograr este objetivo se realizaron los siguientes pasos: Primero: Fue seleccionada una metodología de desarrollo de software para ser utilizada como caso de estudio en este trabajo. La metodología en cuestión es una instancia de la metodología RUP (Rational Unified Process) denominada SmallRUP, definida por Gary Pillice en su artículo Using the RUP for small projects [Pollice2003]. Segundo: Se utilizó el Metamodelo para la Ingeniería de Procesos de Software SPEM (Software Process Engineering Metamodel) definido por la OMG (Object Management Group) para el modelado de procesos de desarrollo. Tercero: Una vez especificado el proceso de desarrollo SmallRUP en SPEM, el paso siguiente fue la definición de un conjunto de reglas de transformación para convertir la especificación SPEM en una especificación XPDL (XML Process Definition Language). Esta última, ya es una definición estándar de un proceso Workflow, por lo que podrá ser ejecutada, como cualquier proceso automatizado, por un sistema workflow. Las reglas de transformación fueron definidas utilizando el lenguaje XSLT (XSL Transformations). Este trabajo está organizado de la siguiente manera. En la sección 1 es presentado el caso de estudio SmallRUP. En la sección 2, se explican algunas características del metamodelo SPEM, y se muestra cómo es realizada la especificación de SmallRUP. La sección 3 muestra como es el proceso de transformación de una especificación SPEM a una definición de proceso workflow. Finalmente en la sección 4, las conclusiones. 1 Caso de estudio SmallRUP El caso de estudio utilizado es una instanciación particular del RUP (Rational Unified Process - RUP) definida para pequeños proyectos [Pollice2003] denominada SmallRUP. La elección del RUP se debió a que es una metodología que presenta buenas prácticas en el desarrollo de software moderno para una amplia gama de proyectos y organizaciones, está embebido en técnicas orientadas a objetos, utiliza

3 UML como notación principal, permite a organizaciones del software ajustar el proceso a su necesidad específica y cubre diferentes dominios particulares [Kruchten2002]. 1.1 Ajustando el RUP para pequeños proyectos SmallRUP El Proceso Unificado Rational (Rational Unified Process - RUP) es una metodología de desarrollo de software orientada a objetos. El RUP mantiene pautas, plantillas, y ejemplos para todos los aspectos y fases de desarrollo del software. Además, establece cuatro fases de desarrollo, cada una de las cuales está organizada en iteraciones separadas que se van secuenciando a medida que se satisfacen determinados criterios. Al ser el RUP un framework de procesos de desarrollo de software existen diversas formas en las que se lo puede instanciar, dependiendo de las características del proyecto. Una de estas variantes es SmallRUP. 1.2 Las cuatro fases del SmallRUP SmallRUP posee cuatro fases de desarrollo. Fase de Inicio, Elaboración, Construcción y Transición. Cada etapa determina un conjunto de actividades a desarrollar por un grupo de personas con determinados roles dentro del proyecto, por ej. Programador, Jefe de Programadores, etc. Como resultado, cada fase produce artefactos que serán utilizados por las fases subsecuentes. En las Tablas 1, 2 3 y 4 se muestran las actividades de cada etapa con sus respectivos roles. Tabla 1. Fase de Inicio, se identifican las características del proyecto, y su factibilidad. Roles Actividades Artefacto Visión Formular el alcance del proyecto Plan de aceptación Jefe de Programadores Planificar y preparar los Casos de Uso de Negocio (CUN) Síntesis de la arquitectura candidate Preparar las condiciones del proyecto Modelo de Casos de Uso de Negocio Lista de Riesgos Modelo inicial de Casos de Uso de Sistema (CUS) Bosquejo de la Arquitectura candidata Plan de proyecto preliminar Plan para empezar fase de elaboración Tabla 2. Fase de Elaboración, se obtiene un delineamiento de la arquitectura del sistema. Roles Actividades Artefacto

4 Jefe de Programadore s Definir, validar y delinear la arquitectura Refinar la visión Crear y delinear el plan de iteración para la fase de construcción Documentación de la arquitectura del software (SAD) CUS y Lista de Riesgos (Actualizados) Plan de iteración para la fase de construcción Programador Iniciar el desarrollo Código Fuente V1.0 Jefe de Programadore s Crear el entorno de testeo Código de Testeo V1.0 Tabla 3. Fase de Construcción, el objetivo principal de esta etapa es completar el desarrollo del sistema. Roles Actividades Artefacto Administrar los recursos y los Planificación procesos de control Desarrollar y testear los Programador Componentes componentes Evaluar la iteración Plan de Iteración para la fase de Transición Tabla 4. Fase de Transición, se asegura que el software este disponible para el usuario final. Roles Actividades Artefacto Programador Finalizar los materiales de Plan de Despliegue soporte para el usuario Manual del Usuario Cliente Testear el producto entregado en el entorno del cliente Lista de Issues Programador Ajustar el producto sobre el feedback del cliente Producto final Entregar el producto final 2 Especificación de los procesos de desarrollo Para especificar las actividades propuestas por un proceso de desarrollo utilizamos el metamodelo definido por la OMG para la descripción de procesos de desarrollo denominado SPEM. En el SPEM se especifica cómo manipular los modelos utilizando XMI (XML Metadata Interchange). Se pretende con esto, obtener la especificación de nuestro proceso de desarrollo en un formato que sea posible de manipular.

5 2.1 Metamodelo para la Ingeniería de Procesos de Software - SPEM El nacimiento del Proceso Unificado (Unified Process - UP) y del Lenguaje Unificado de Modelado (Unified Modeling Language -UML) a finales de 1990 produjo un cambio fundamental en la industria del desarrollo de software. Existen actualmente muchas variantes del UP que son utilizadas por todo el mundo. Esto provocó la necesidad de un estándar unificado en esta área, debido a que al existir diferentes técnicas de modelado de procesos, se utilizaban diferentes terminologías e incluso diferentes significados para las mismas palabras. En reconocimiento a esta necesidad, la OMG definió el Metamodelo para la Ingeniería de Procesos de Software SPEM (Software Process Engineering Metamodel). SPEM es un metamodelo utilizado para describir procesos de desarrollo de software concretos o una familia de procesos de desarrollo de software relacionados. El metamodelo SPEM permite abstraerse de las características particulares de cada proceso de desarrollo, dando la posibilidad de definir distintos procesos de desarrollo de software. SPEM ofrece un framework para el modelado de procesos de desarrollo de software y sus componentes, dando una sintaxis y una estructura común para cada aspecto del proceso de desarrollo, incluyendo: roles, tareas, artefactos, lista de chequeo. El SPEM usa UML como notación [SPEMv1.0]. Estructura de Paquetes de SPEM El metamodelo SPEM es construido extendiendo un subconjunto del metamodelo UML 1.4 el cual, es encapsulado en un paquete denominado SPEM_Foundation (figura 1). El paquete SPEM_Foundation describe la estructura estática del modelo y hereda de los siguientes paquetes de UML 1.4: Data_Types, Core, Actions, State_Machines, Activities_Graphs, Model_Managements [UML1.4]. SPEM_Foundation SPEM_Extensions Fig. 1. Paquetes SPEM_Foundation y SPEM_Extensions El paquete SPEM_Extensions incorpora los constructores y la semántica propia para la ingeniería de procesos de desarrollo de software. El paquete SPEM_Extensions está compuesto por los siguientes subpaquetes: BasicElements, Dependencies, ProcessStructure, ProcessComponents y ProcessLifecycle.

6 BasicElements: Define los elementos básicos para la descripción de los procesos. Dependencies: Define las dependencias entre los componentes. Se definen como subclases de las clases del paquete SPEM_Foundation. ProcessStructure: Define la estructura de los elementos. ProcessComponents: Permite la división de una o más descripciones de procesos en partes autocontenidas. ProcessLifecycle: Incorpora los elementos de definición de procesos que ayudan a definir la ejecución de los procesos. 2.2 Re-escribiendo SmallRUP con SPEM El objetivo de esta sección es mostrar como se puede especificar un proceso de desarrollo utilizando el SPEM. Esto implica dar una instanciación de las clases de este metamodelo que se correspondan con el proceso de desarrollo que se quiere especificar. Con las clases del SPEM definiremos nuestro modelo de objetos del proceso de desarrollo, y lo representaremos mediante la utilización de XMI, es decir, obtendremos un documento XMI que contiene el modelo de objetos que representa al SmallRUP en el SPEM. Daremos primero un maping y un ejemplo entre las terminologías del SmallRUP y el SPEM para detectar que clases del SPEM corresponde con cada componente del SmallRUP, y luego como se definieron las dependencias entre actividades mediante la utilización de un diagrama de actividades como un caso particular del un diagrama de estados. Tabla 5. Maping entre las terminologías del SmallRUP y el SPEM. SmallRUP SPEM Ejemplo Roles ProcessRoles Chief Programmer Actividad Activity Síntesis de la arquitectura candidata Artefacto WorkProduct Arquitectura preliminar Disciplina Discipline Captura de requisitos Fase Phase Fase de Inicio Iteración Iteration Primera Iteración En la figura 2 se muestra como se define en el SPEM para una actividad, quienes participan, el artefacto que se produce y el tipo de este artefacto. Por último, la figura 3 muestra la forma en la cual se construye el diagrama de objetos que corresponde a la dependencia entre actividades. Para ello se define un diagrama de actividad mediante un diagrama de estados, en donde se tienen estados de acción (ActionState) asociados a una actividad (Activity) por medio de la operación de la acción de entrada (CallAction) de ese estado. De esta manera se pueden obtener todos los objetos que formarán nuestro modelo de objetos del SmallRUP. El paso siguiente es serializar este modelo utilizando XMI (XML Metadata Interchange).

7 subwork Summary of Candidate Architecture : Activity behaviorallfeacture activity assistant ChiefProgrammer : ProcessRole responsiblerole parameters : ActivityParameter type workproduct Draf Architecture : WorkProduct parentwork Iteration 1, Inception Phase : Iteration kind UML Diagram : WorkProductKind Fig. 2. Diagrama de Objeto: Actividades, roles y artefactos outgoing : Transition incoming source : ActionState target : ActionState entry : CallAction entry : CallAction operation To refine the vision : Activity operation To create, and to delineate the iteration plan for the construction phase : Activity Figura 3. Dependencia de Actividades y Diagrama de Objeto 2.3 Serialización El SPEM especifica cómo manipular los modelos utilizando XMI (XML Metadata Interchange). Con esto se pretende obtener la especificación de nuestro proceso de desarrollo en un formato que sea factible de manipular para luego transformarlo en la entrada de un motor workflow. El principal propósito de la norma XMI propuesta por el OMG, es facilitar el intercambio de metadatos en entornos distribuidos heterogéneos, entre diferentes tipos de herramientas software y, en especial, entre herramientas de modelado basadas en UML y repositorios de metadatos basados en la propuesta MOF (Meta-Object

8 Facility). XMI permite que los metadatos puedan ser intercambiados como flujos o archivos con un formato estándar basado en XML. El proceso de producción de documentos XMI está definido como un conjunto de reglas, donde estas reglas son aplicadas a un modelo y se obtiene como resultado un documento XML. La inversa de estas reglas pueden ser aplicadas para reconstruir el modelo original. En ambos casos, las reglas son empleadas en el contexto del metamodelo para el metadato que está siendo intercambiado. La producción de XML esta representada en la forma Backus-Naur extendida EBNF (Extended Backus Naur Form) [XMIv2.0]. 3 Automatización de los procesos de desarrollo La producción del software se realiza a través de la ejecución de un proyecto de desarrollo de software guiado por una metodología de desarrollo. Para su automatización se deberá definir, dentro de un proceso workflow, las actividades propuestas por la metodología. Para poder intercambiar la definición de las actividades al motor workflow es preciso re-escribirlas en el lenguaje XPDL, y como la especificación de procesos de desarrollo de software está definida en XMI, bastará con definir las reglas de transformación necesarias para convertir un documento XMI en uno XPDL. 3.1 Workflow Un workflow se define como la automatización total o parcial de un proceso de negocio, durante la cual documentos, información o tareas son intercambiadas entre los participantes conforme a un conjunto de reglas procedimentales preestablecidas [Allen2001]. Un workflow comprende un número de pasos lógicos, conocidos como actividades. Una actividad puede involucrar la interacción manual o automática con el usuario. Un motor workflow es un sistema de software que controla la ejecución de las actividades definidas en el workflow. La WfMC ha definido un Modelo de Referencia Workflow (Workflow Reference Model) [WFMC ]. Este modelo define 5 interfases para la interoperabilidad de diferentes productos con un motor workflow. La interfaz 1 especifica el formato de intercambio común para soportar la transferencia de definiciones de procesos entre productos diferentes, utilizando un Lenguaje de definición de Procesos (XML Process Definition Language - XPDL) [WFMC ]. El Lenguaje XPDL permite escribir especificaciones de procesos workflow de manera estandarizada. Esto significa que cualquier definición de proceso que cumpla con todos los requisitos establecidos en la interfaz 1 podrá ser tomada como entrada por cualquier motor workflow que respete el estándar establecido por la WfMC. El metamodelo workflow está compuesto por entidades y relaciones. Las entidades principales del metamodelo Workflow son las siguientes: Workflow Process Activity: Representa una actividad dentro de un proceso.

9 Transition Information: Describe las transiciones entre actividades y las condiciones que la habilitan o inhabilitan, durante la ejecución del workflow. Workflow Participant Specification: Representa los participantes intervinientes en una actividad. Puede ser un rol, un humano, u otro sistema. Workflow Application Declaration: Es representada como una lista de las aplicaciones o herramientas requeridas por el proceso workflow. Workflow Relevant Data: Representa a la información que circula dentro de un proceso workflow. 3.2 Workflow aplicado al Proceso de desarrollo Workflow es una tecnología de información que puede contribuir al logro de los objetivos del proceso de desarrollo y al mejoramiento de sus resultados mediante la administración efectiva de las actividades que componen sus diferentes procesos por parte de los propios participantes. Un proceso de software consiste en un conjunto de actividades concurrentes y cooperativas, que tienen que ver con el desarrollo y mantenimiento de software, así como con la gestión del proyecto y la calidad del producto. Por lo tanto, un proceso de software puede verse como un caso particular de proceso, y puede aplicarse la tecnología de workflow para dar soporte al proceso de desarrollo de software [Acuña2000]. 3.3 Definición de reglas de transformación En la sección 2 se mostró como un proceso de desarrollo puede ser instanciado en SPEM, y como se puede representar en un documento XMI, el paso siguiente es transformar este documento en un documento XPDL. Para realizar esta transformación se utilizó XSLT (Transformaciones XSL - XSL Transformations) [XSLTv1.0], un lenguaje para transformar documentos XML en otros documentos XML, mediante definiciones de reglas de transformación. Para la construcción de las reglas de transformación se establecieron asociaciones entre las clases del metamodelo SPEM y las entidades de la especificación XPDL. Las reglas de transformación definidas son independientes del proceso o instancia utilizada, dando así una forma general de transformación entre objetos del SPEM y entidades del XPDL. Las reglas de transformación generadas, fueron aplicadas al caso de estudio SmallRUP. A continuación se mostrarán algunas de las correspondencias entre entidades del metamodelo Workflow (XPDL) y clases de SPEM. XPDL.TypeDeclaration: Los tipos de datos utilizados son los tipos que pueden tener los artefactos producidos, SPEM:WorkProductKind. Ejemplo: UML Diagram. XPDL.Application: A cada tipo de artefacto producido (SPEM:WorkProductKind), se asoció un tipo de aplicación. Ejemplo: a un UML Diagram se asoció un UML CASE Tool.

10 XPDL.Activity: SPEM:Activity definen las actividades de tipo implementación del XPDL, las actividades de tipo JOIN o FORK son definidas mediante SPEM.PseudoState. XPDL.DataField: Son los artefactos producidos, SPEM:WorkProduct. Ejemplo: el artefacto Model of business use case. XPDL.WorkFlowProcess: SPEM:Process, El SmallRUP define el WorkFlowProcess del XPDL. XPDL.Transition: SPEM:Transition, cada transición definida en nuestro diagrama de actividad se corresponde con las transiciones de las actividades en el XPDL. XPDL.Participant: Los distintos roles que participan en el RUP, SPEM:Role. Ejemplo: Project Manager. Código de ejemplo correspondiente a la regla de transformación XSLT de la clase SPEM:ProcessRole. <xsl:template name="xpdl_participants"> <xsl:text disable-output-escaping="yes"> <Participants></xsl:text> <xsl:for-each select="//spem.processrole"> <xsl:text disable-output-escaping="yes"> <Participant Id="</xsl:text> <xsl:value-of select="@xmi.id"/> <xsl:text disable-output-escaping="yes"> " Name="</xsl:text> <xsl:value-of select="@name"/> <xsl:text disable-output-escaping="yes">"> <ParticipantType Type="ROLE" /> <Description> </xsl:text> <xsl:value-of select="@name"/> <xsl:text disable-output-escaping="yes"> </Description> </Participant> </xsl:text> </xsl:for-each> <xsl:text disable-output-escaping="yes"> </Participants></xsl:text> </xsl:template> De esta manera se construyeron las reglas de transformación que se aplican a un modelo de objetos correspondiente a un proceso de desarrollo especificado en el SPEM en formato XMI.

11 3.4 Generando el documento XPDL Una vez definidas las reglas de transformación, el paso siguiente es aplicar a la especificación del proceso de desarrollo en SPEM XMI de éstas, reglas para generar la definición de procesos workflow en XPDL. En la figura 4 se muestra la secuencia completa de los pasos de transformación. Figura 4. Secuencia de transformaciones 4 Conclusión Ante la competencia, eficiencia y velocidad que requiere actualmente el mercado globalizado, la automatización de los procesos de negocio dentro de la industria ocupa un lugar fundamental. El correcto desarrollo de las actividades, buen uso de los recursos, exigencias en cuanto a la producción y al control son puntos vitales para toda industria. El desarrollo del software no es ajeno a estos conceptos, y es por ello que existen varias líneas de investigación estudiando como colaborar en su automatización. A la necesidad de automatización también se debe sumar la necesidad de la utilización de estándares para lograr un mejor entendimiento e integración con las demás tecnologías. Dos grandes estándares se utilizaron en este trabajo; el metamodelo para la descripción de procesos de software definido por la OMG denominado SPEM, y la especificación workflow definida por la WfMC. En este trabajo lo que se presentó una alternativa que permite la automatización de un proceso de desarrollo de software (SmallRUP). Las ventajas que conllevan la automatización de un proceso de desarrollo de software son las siguientes: Con respecto a la construcción del software: Se considera que el proceso de transformación optimiza la construcción del software debido a que se dispone de un sistema automatizado (motor workflow) que administrará los recursos y organizará a un equipo de ingenieros de software en el transcurso del desarrollo de un proyecto en particular. El proceso de desarrollo adopta todas las ventajas propias de un proceso

12 workflow, como son la ejecución y simulación del proceso, el rediseño buscando un modelo más óptimo, entre otras. Con respecto a la independencia de las reglas de transformación: La utilización de un caso de estudio para este trabajo nos permitió aplicar las reglas de transformación en un caso concreto, lo que no limita la extrapolación de éstas reglas a otras metodologías de desarrollo, debido a que las reglas no hacen referencia a las particularidades de un proceso, sino que trabajan con las clases del metamodelo SPEM. La definición de las reglas de transformación de documentos XMI a XPDL fue construida de manera independiente al proceso de desarrollo sobre el cual puede aplicarse. Con respecto a la interacción de diferentes herramientas: La utilización de estándares SPEM, XMI, XSLT, XPDL adoptados por organizaciones como OMG, WfMC, W3C y a escala mundial, por la comunidad informática, ofrece una mejor comprensión del trabajo y flexibilidad para futuras extensiones. Referencias [Acuña2000] Silvia Teresita Acuña, La tecnología de workflow como soporte para la formalización de proceso software integral, Anales de las Jornadas Universitarias sobre Computación de Santiago del Estero (JUCSE 2000); 5-6 de Octubre de Santiago del Estero, Argentina. [Allen2001] Rob Allen, Open Image Systems Inc., United Kingdom Chair, WfMC External Relations Committee; The Workflow Handbook 2001 ; Workflow Management Coalition; Octubre de [Kruchten2002] Philippe Kruchten; Introduction to the Rational Unified Process ; 24th International Conference on Software Engineering; IEEE; 19 al 25 de Mayo de 2002; Orlando, Florida. [Pollice2003] Gary Pollice Using the RUP for small projects: Expanding upon Extreme Programming, A Rational Software White Paper 17 de junio [SPEMv1.0] Object Management Group; Software Process Engineering Metamodel Specification ; An Adopted Specification of the Object Management Group, Inc; Version 1.0 formal/ ; Noviembre de [UMLv1.4] Object Management Group; OMG Unified Modeling Language Specification ; An Adopted Specification of the Object Management Group, Inc; Version 1.5 formal/ ; Marzo de [WFMC ] Workflow Management Coalition; The Workflow Reference Modelo. The Workflow Management Coalition Specification; WFMC-TC-1003 Version 1.1 Issue; Enero de [WFMC ] Workflow Management Coalition; Workflow Process Definition Interface, XML Process Definition Language. The Workflow Management Coalition Specification; WFMC-TC-1025 Version 1.0 Final Draft; Octubre de [XMIv2.0] Object Management Group; XML Metadata Interchange (XMI) Specification ; An Adopted Specification of the Object Management Group, Inc; Versión 2.0; Mayo [XSLTv1.0] Word Wide Web Consortiun; XSL Transformations (XSLT) ; Version 1.0; 19 de noviembre de http: //