Una propuesta basada en el paradigma dirigido por modelos para la extracción de procesos del software desde sistemas heredados utilizando la perspectiva temporal

Departamento de Lenguajes y Sistemas Informáticos Escuela Técnica Superior de Ingeniería Informática Universidad de Sevilla Avda. Reina Mercedes s/n. 41012 Sevilla Tlf: (+34) 954 555 964, Fax: (+34) 954 557 139, Email: [email protected] Una propuesta basada en el paradigma dirigido por modelos para la extracción de procesos del software desde sistemas heredados utilizando la perspectiva temporal TESIS DOCTORAL Autor D. Carlos Arévalo Maldonado Directoras Dra. Dª María José Escalona Cuaresma Dra. Dª Isabel Ramos Román Sevilla, Diciembre 2015 La alegría está en la lucha, en el esfuerzo, en el sufrimiento que supone la lucha, y no en la victoria misma. Nuestra recompensa se encuentra en el esfuerzo y no en el resultado. Un esfuerzo total es una victoria completa. Mohandas Karamchand Gandhi (1869-1948) Tesis doctoral – cam iii CONTENIDO Contenido .................................................................................................... iii Índice de definiciones ................................................................................. ix Índice de expresiones ................................................................................. xi Índice de figuras ....................................................................................... xiii Índice de tablas .......................................................................................... xv Agradecimientos ...................................................................................... xvii Resumen .................................................................................................... xix PARTE I. INTRODUCCIÓN Capítulo 1. Contexto de la investigación ............................................... 25 1.1 Organizaciones del negocio del software (TI) ................................................... 25 1.2 Motivación ............................................................................................................ 29 1.3 Desarrollo del trabajo de investigación ............................................................. 36 1.3.1 Contexto ......................................................................................................................................... 36 1.3.2 Metodología ................................................................................................................................... 38 1.4 Estructura de la memoria ................................................................................... 41 1.5 Resumen y conclusiones ...................................................................................... 42 Capítulo 2. Retos y objetivos .................................................................. 43 2.1 Identificación del problema ................................................................................ 44 2.2 Retos ...................................................................................................................... 46 2.3 Un ejemplo motivador ......................................................................................... 47 2.3.1 Planificación de un proyecto como sistema origen ........................................................................ 47 2.3.1.1 Restricciones temporales .............................................................................................................................. 48 2.3.1.2 Dependencias temporales ............................................................................................................................. 49 2.3.2 Proceso BPMN para el plan del proyecto ...................................................................................... 49 2.3.3 Discusión ........................................................................................................................................ 52 2.4 Hipótesis y objetivos ............................................................................................ 52 2.4.1 Legacy systems como sistemas origen ........................................................................................... 53 2.4.2 Reglas temporales sobre procesos .................................................................................................. 55 2.4.3 Lenguajes para representación de procesos .................................................................................... 56 2.4.4 Extracción de procesos desde legacy databases ............................................................................. 57 2.4.5 Verificación del enfoque en un caso de estudio ............................................................................. 58 2.4.6 Resumen hipótesis vs objetivos de la investigación ....................................................................... 60 iv Tesis doctoral – cam 2.5 Arquitectura de la solución ................................................................................. 60 2.6 Resumen y conclusiones ...................................................................................... 62 PARTE II. ANTECEDENTES Capítulo 3. Estado del arte ..................................................................... 67 3.1 Ingeniería del software dirigida por modelos .................................................... 67 3.1.1 Problemas del desarrollo tradicional de software ........................................................................... 67 3.1.2 Model-Driven Engineering (MDE) ................................................................................................ 71 3.2 Gestión de procesos del software ........................................................................ 78 3.3 Gestión de procesos de negocio (BPM) .............................................................. 78 3.3.1 Conceptos ....................................................................................................................................... 78 3.3.2 Ciclo de vida BPM ......................................................................................................................... 79 3.3.3 Beneficios del enfoque BPM ......................................................................................................... 81 3.3.4 Estándares BPM ............................................................................................................................. 82 3.3.4.1 Business Process Definition MetaModel (BPDM) ..................................................................................... 84 3.3.4.2 Business Process Model and Notation (BPMN) ........................................................................................... 85 3.3.4.3 Xml Process Definition Language (XPDL) .................................................................................................. 87 3.3.4.4 Evolución histórica ....................................................................................................................................... 87 3.3.5 Sistemas de gestión de procesos (PAIS) ........................................................................................ 88 3.4 Navigational Development Techniques (NDT) .................................................. 91 3.5 Modernización de legacy systems ....................................................................... 96 3.5.1 Conceptos y problemas en legacy systems ..................................................................................... 96 3.5.2 Arquitectura ADM para modernización de sistemas ...................................................................... 98 3.6 Resumen y conclusiones ...................................................................................... 99 Capítulo 4. Trabajo relacionado .......................................................... 101 4.1 Introducción ....................................................................................................... 101 4.2 Reglas temporales sobre procesos .................................................................... 102 4.3 Procesos de negocio del software ...................................................................... 105 4.4 Modernización de legacy systems ..................................................................... 106 4.5 Otras perspectivas BPM: Organizacional y Casos ......................................... 109 4.6 Minería de procesos ........................................................................................... 110 4.7 Resumen y conclusiones .................................................................................... 111 Capítulo 5. Legacy systems en el sector de las TI .............................. 113 5.1 Sistemas de gestión en organizaciones orientadas al software ...................... 113 5.1.1 Sistemas de planificación y control de proyectos ......................................................................... 114 5.1.2 Sistemas de gestión documental (ECMs) ..................................................................................... 115 5.1.3 ERPs, CRMs, SCMs y desarrollos a medida ................................................................................ 115 5.2 Perspectivas de procesos vs legacy systems ..................................................... 116 5.3 Dimensión temporal en un legacy system ........................................................ 117 5.4 Resumen y conclusiones .................................................................................... 118 Tesis doctoral – cam v PARTE III. SOLUCIÓN PROPUESTA Capítulo 6. Reglas temporales sobre procesos ................................... 121 6.1 Perspectiva temporal en los procesos de negocio ............................................ 121 6.2 Taxonomía de reglas temporales ...................................................................... 122 6.2.1 Restricciones temporales .............................................................................................................. 123 6.2.2 Dependencias temporales ............................................................................................................. 126 6.3 Enfoques para la extensión de BPMN 2.0 con reglas temporales.................. 127 6.3.1 Capacidades y limitaciones de BPMN 2.0 para representar la perspectiva temporal ................... 127 6.3.2 Extensiones a BPMN mediante decoradores ................................................................................ 129 6.3.3 Patrones BPMN para representación de reglas temporales .......................................................... 132 6.4 MetaModelos estándar para representación de procesos ............................ 136 6.4.1 MetaModelo UML Activity Diagrams ....................................................................................... 136 6.4.2 MetaModelo BPMN 2.0 ............................................................................................................. 139 6.4.3 MetaModelo XPDL 2.2 ............................................................................................................. 140 6.4.4 Comparación de MetaModelos de procesos .............................................................................. 141 6.5 Un MetaModelo de procesos con reglas temporales (PIM-up) ................... 142 6.5.1 MetaModelo UML de procesos ................................................................................................. 142 6.5.1.1 Diagrama de clases ..................................................................................................................................... 142 6.5.1.2 Enumeraciones ........................................................................................................................................... 144 6.5.1.3 Extensión del ciclo de vida de una actividad bajo CPM ............................................................................. 145 6.5.2 Definición de la dimensión temporal con OCL ............................................................................ 146 6.5.2.1 Restricciones sobre el ciclo de vida de procesos y actividades ................................................................... 146 6.5.2.2 Restricciones temporales sobre una actividad ............................................................................................ 148 6.5.2.3 Dependencias temporales entre actividades ............................................................................................... 152 6.6 Resumen y conclusiones .................................................................................... 153 Capítulo 7. Extracción de procesos desde Legacy Databases ........... 155 7.1 Enfoque MDE para la extracción de procesos ................................................ 155 7.2 MetaModelo de procesos (PIM-upl) ............................................................... 159 7.3 Plataforma origen piloto: MS Project Server ................................................. 160 7.3.1 Arquitectura de MS Project Server .............................................................................................. 161 7.3.2 MetaModelo PSM de tareas ....................................................................................................... 162 7.4 Extracción de procesos desde Legacy Databases ............................................ 164 7.4.1 Extracción de modelos PSM→PIM-upl ....................................................................................... 165 7.4.1.1 Algoritmo ................................................................................................................................................... 167 7.4.1.2 Reglas de Mapeo ........................................................................................................................................ 168 7.4.2 Actividades replicadas en legacy systems .................................................................................... 171 7.4.2.1 Identificación del problema ........................................................................................................................ 171 7.4.2.2 Resolución mediante extensión del MetaModelo PIM-upl ...................................................................... 171 7.4.2.3 Escenario ejemplo ...................................................................................................................................... 175 7.4.3 Transformación de modelos PIM-upl→CIM ............................................................................... 178 7.4.3.1 Algoritmo ................................................................................................................................................... 182 7.4.3.2 Reglas de Mapeo ........................................................................................................................................ 183 7.5 Resumen y conclusiones .................................................................................... 185 Capítulo 8. Caso de estudio: Aqua-WS project ................................. 187 8.1 AQUA-WS Project ............................................................................................. 187 8.1.1 Proyectos definidos en projectserver_Published_AQUA-WS ..................................................... 188 vi Tesis doctoral – cam 8.1.2 Extracción de tareas, restricciones y relaciones de precedencia................................................... 189 8.1.2.1 Extracción E1: tareas generales y fases de la planificación general ........................................................... 189 8.1.2.2 Extracción E2: Grupo de tareas ligadas a un subsistema ............................................................................ 190 8.1.2.3 Extracción E3: Tarea elemental de la planificación general ....................................................................... 191 8.1.2.4 Extracción E4: Patrón NDT ASI (Análisis del sistema) ............................................................................. 193 8.2 Generación de modelos de procesos ................................................................. 194 8.2.1 Extracción E1: tareas generales y fases de la planificación general ............................................. 197 8.2.2 Extracción E2: Grupo de tareas ligadas a un subsistema ............................................................. 198 8.2.3 Extracción E3: Tarea elemental de la planificación general ........................................................ 199 8.2.4 Extracción E4: Patrón NDT ASI .................................................................................................. 200 8.3 Discusión de resultados ..................................................................................... 202 8.3.1 Proceso general y fases del proyecto ............................................................................................ 202 8.3.2 Fase NDT ASI .............................................................................................................................. 203 8.3.3 Nivel de abstracción de los modelos ............................................................................................ 204 8.3.4 Extensión y reutilización de modelos ........................................................................................... 204 8.4 Resumen y conclusiones .................................................................................... 205 PARTE IV. CONCLUSIONES Capítulo 9. Conclusiones y trabajo futuro .......................................... 209 9.1 Contribuciones ................................................................................................... 209 9.1.1 Estudio del estado del arte (ob.0.). ............................................................................................... 209 9.1.2 Meta-Modelos de tareas para legacy system de uso habitual en «TI» (ob.1.). ............................. 211 9.1.3 Taxonomía de reglas temporales (ob.2.). ..................................................................................... 212 9.1.4 MetaModelo de procesos PIM-up con reglas temporales (ob.3.). .............................................. 212 9.1.5 Extensión al MetaModelo BPMN (ob.4.). ................................................................................. 212 9.1.6 Ingeniería inversa MDE para extraer procesos desde legacy systems (ob.5.) .............................. 213 9.1.6.1 MetaModelo PIM-upl (ob.5.1) ................................................................................................................. 213 9.1.6.2 Algoritmo de transformación PSM→PIM-upl (ob.5.2) .............................................................................. 214 9.1.6.3 Algoritmo de transformación PIM-upl→CIM (ob.5.3) .............................................................................. 214 9.1.7 Verificación del enfoque en el caso AQUA-WS Project (ob.6) ................................................... 214 9.2 Trabajo futuro .................................................................................................... 216 9.3 Conclusiones ....................................................................................................... 217 Referencias ............................................................................................... 219 PARTE V. ANEXOS Anexo I: Acrónimos ................................................................................ 251 Anexo II: MetaModelos de tareas en legacy databases (LDB) ......... 259 Anexo II.a: LDB MS Access/MS Project .................................................................. 261 Anexo II.b: LDB SQL*Server/MS Project Server Published instance ................. 261 Anexo II.c: LDB PostgreSQL/ECM Alfresco .......................................................... 262 Anexo II.d: LDB MySQL/RedMine .......................................................................... 264 Anexo III: MetaModelos relacionales SQL ........................................ 265 Tesis doctoral – cam vii Anexo III.a: MetaModelos relacionales OMG:IMM ............................................ 267 Anexo III.b: Extensiones a MetaModelos relacionales. Restricciones ................ 273 Anexo IV: Proyecto AQUA-WS ............................................................. 275 Anexo IV.a: Planificación del proyecto (MS Project) ............................................. 277 Anexo IV.a1. Planificación general del Proyecto (Tareas generales y subsistemas) ................................ 277 Anexo IV.a2. Planificación Control Calidad Tarea (64): (ASI) Instalaciones y equipos ......................... 283 Anexo IV.a3. Patrón de Planificación para Control Calidad de la fase NDT ASI ................................... 284 Anexo IV.b: Diagrama Relacional BD SQL*Server Published-AQUA ................ 285 Anexo IV.c: Tablas BD SQL*Server Published-AQUA ......................................... 286 Anexo V. Publicaciones y proyectos ...................................................... 299 Capítulos de libros ...................................................................................................... 301 Publicaciones en revistas internacionales ................................................................. 302 Publicaciones en conferencias internacionales ........................................................ 305 Publicaciones en conferencias nacionales ................................................................. 306 Proyectos ..................................................................................................................... 307 Proyectos de investigación ....................................................................................................................... 307 Proyectos de transferencia tecnológica ..................................................................................................... 308 Redes nacionales ...................................................................................................................................... 309 Redes internacionales ............................................................................................................................... 310 xiv Tesis doctoral – cam Figura. 7.6. Proceso de extracción de la dimensión temporal PSM→PIM 166 Figura. 7.7. Algoritmo para extracción de la dimensión temporal PSM→PIM 167 Figura. 7.8. Extensión al MetaModelo PIM-upl para resolver colisiones de actividades replicadas 173 Figura. 7.9. Resolución de colisiones del atributo Activity.name 174 Figura. 7.10. Resolución de colisiones del atributo Activity.unique_Identifier 174 Figura. 7.11. Resolución de colisiones con atributos start y end de la clase Activity 174 Figura. 7.12. Resolución de colisiones con atributos startCPM y endCPM 175 Figura. 7.13. Derivación de reglas para la clase Merged_Activity 175 Figura. 7.14. Escenario de extracción de modelos de procesos con actividades replicadas 177 Figura. 7.15. Proceso de extracción de la dimensión temporal PIM→ CIM 179 Figura. 7.16. MetaModelo BPMN 2.0 con extensiones temporales 181 Figura. 7.17. Algoritmo de transformación PIM→CIM 183 Figura. 8.1. E1::Tareas Organizativas, Control de Calidad y Fases AQUA-WS 190 Figura. 8.2. E1::Precedencias en Tareas Organizativas, Control de Calidad y Fases AQUA-WS 190 Figura. 8.3. Tareas de un grupo de actividades (AQUA-WS) 191 Figura. 8.4. Dependencias en tareas de grupo (AQUA-WS) 191 Figura. 8.5. Tabla Msp_Tasks para el subproyecto (64) (AQUA-WS) 192 Figura. 8.6. Tabla Msp_Links para el subproyecto (64) (AQUA-WS) 192 Figura. 8.7. Tabla Msp_Tasks para el subproyecto patrón (1001): Fase NDT ASI 193 Figura. 8.8.Tabla Msp_Links para el subproyecto patrón (1001): Fase NDT ASI 194 Figura. 8.9. Actividades generales y subsistemas AQUA-WS (BPMN) 197 Figura. 8.10. Proceso BPMN (61) Fase Alfa 0.4: Clientes Intervenciones en Red (AQUA-WS) 198 Figura. 8.11. Proceso de negocio BPMN (64) (ASI) Instalaciones y Equipos (AQUA-WS) 199 Figura. 8.12. Proceso de negocio BPMN (1001) Patrón NDT (ASI) Análisis del Sistema 200 Figura. 8.13. Procesos de negocio NDT: Fases de Requerimientos y Análisis 201 Figura. AII.1. MetaModelo de tareas de MS Project (MS Access) 261 Figura. AII.2. MetaModelo de tareas de MS Project Server (SQL*Server™). Tablas principales 261 Figura. AII.3. Workflow básico de Alfresco 262 Figura. AII.4. MetaModelo del ECM:Alfresco (PostgreSQL) 262 Figura. AII.5. MetaModelo de tareas de Activity (Integrado con Alfresco en PostgreSQL) 263 Figura. AII.6. MetaModelo de tareas de RedMine 264 Figura. III.1. MetaModelo OMG:IMM PSM Relacional. Main Schemata 267 Figura. III.2. MetaModelo OMG:IMM PSM Relacional. Tables 268 Figura. III.3. MetaModelo OMG:IMM PSM Relacional. Columns 269 Figura. III.4. MetaModelo OMG:IMM PSM Relacional. Constraint Unique Keys 270 Figura. III.5. MetaModelo OMG:IMM PSM Relacional. Constraint Foreign Keys 271 Figura. III.6. MetaModelo OMG:IMM PSM Relacional. Constraint Other Constraints 272 Figura. III.7. MetaModelo PSM Relacional. Paquetes 273 Figura. III.8. MetaModelo PSM Relacional. Extensiones para triggers 273 Figura. IV.1. Planificación General Proyecto AQUA-WS por subsistemas 277 Figura. IV.2. Planificación General Proyecto AQUA-WS por fases 280 Figura. IV.3. Planificación Control Calidad (64) (ASI) Instalaciones y Equipos AQUA-WS 283 Figura. IV.4. Patrón de Planificación para Control Calidad de la fase NDT (ASI) 284 Figura. IV.5. Diagrama Relacional BD SQL*Server Published-AQUA 285 Figura. IV.6. Tabla Ext_Task_Constraint_Types (AQUA-WS) 286 Figura. IV.7. Tabla Ext_Link_Types (AQUA-WS) 286 Figura. IV.8. Tabla Msp_Projects (AQUA-WS) 287 Figura. IV.9. Tabla Msp_Tasks (AQUA-WS) 288 Figura. IV.10. Tabla Msp_Links (AQUA-WS) 293 Tesis doctoral – cam xv ÍNDICE DE TABLAS Tabla. 2.1. Hipótesis vs Objetivos 60 Tabla. 3.1. Retos de los sistemas legacy systems 97 Tabla. 5.1. Perspectivas BPM soportadas por tipo de legacy system 116 Tabla. 5.2. Reglas temporales soportadas por tipo de legacy system 117 Tabla. 5.3. Dependencias temporales soportadas por tipo de legacy system 118 Tabla. 6.1. Cotas de eventos para restricciones de inicio y terminación flexibles 125 Tabla. 6.2. Extensión temporal a BPMN 2.0 mediante nuevos decoradores 130 Tabla. 6.3. Construcciones BPMN 2.0 para representar Restricciones de Tiempo (TC) 133 Tabla. 6.4. Construcciones BPMN 2.0 para representar Dependencias Temporales (TD) 135 Tabla. 6.5. Comparación de MetaModelos de procesos: clases y asociaciones 142 Tabla. 6.6. Restricciones temporales OCL 151 Tabla. 6.7. Dependencias temporales OCL 153 Tabla. 7.1. Tabla Constraint_Type (MS Project Server) 164 Tabla. 7.2. Tabla Link_Type (MS Project Server) 164 Tabla. 7.3. Proyecto como proceso de negocio. 169 Tabla. 7.4. Subproceso como Actividad Resumen y Proceso de Negocio. 169 Tabla. 7.5. Actividades del proceso de negocio. 169 Tabla. 7.6. Restricción de tiempo de duración fija para cada tarea ‘FIXD’ 170 Tabla. 7.7. Restricciones de tiempo sobre inicio y terminación de la actividad 170 Tabla. 7.8. Dependencias temporales sobre la actividad 171 Tabla. 7.9. Proceso de negocio BPMN 183 Tabla. 7.10. Pool BPMN para el proceso 184 Tabla. 7.11. Actividad BPMN 184 Tabla. 7.12. Calle para la actividad dentro del Pool del proceso 184 Tabla. 7.13. Subproceso BPMN 184 Tabla. 7.14. Subproceso BPMN AdHoc 184 Tabla. 7.15. Restricciones temporales BPMN 185 Tabla. 7.16. Dependencias temporales BPMN 185 Tabla. 8.1. Mapeo de elementos de la planificación AQUA-WS a procesos BPMN 194 Tabla. IV.1. Tabla SQL*Server Msp_Tasks (AQUA-WS) 289 Tabla. IV.2. Tabla SQL*Server Msp_Tasks (AQUA-WS) 294 Tabla. IV.3. Tabla de asignación de recursos (AQUA-WS) 296 Tesis doctoral – cam xvii AGRADECIMIENTOS Este trabajo me ha permitido recibir directrices, contrastar opiniones, orientaciones y contar con la experiencia de personas que han hecho posible su realización, a las que agradezco su colaboración. En primer lugar, a mis directoras de tesis, María José Escalona e Isabel Ramos, por sus sabias orientaciones, motivación, apoyo y acogida en el grupo de investigación IWT2. A María Teresa Gómez, por su empuje en el inicio de la tesis. A Miguel Toro, por su análisis y consejos para enfocar el trabajo. A mi compañera Margarita Cruz, por sus revisiones y oír pacientemente mis reflexiones. A todos mis compañeros de Departamento y del grupo IWT2, especialmente a Julián, Laura y Francis. A mis amigos, y especialmente a mi familia, por apoyarme en la dedicación a este trabajo. A todos ellos, mi reconocimiento y gratitud. Tesis doctoral – cam xix RESUMEN En el contexto actual de la globalización, la competencia es cada vez mayor para las organizaciones de cualquier sector. Las «Tecnologías de la Información y Comunicaciones (TIC)» representan una clave innovadora para hacer frente a los retos a que se enfrenta el ser humano en las próximas décadas, tanto para las economías avanzadas como para las emergentes. Muchos investigadores consideran el enfoque «Business Process Management (BPM)» [van der Aalst 2004; Netjes et al. 2006] como una ventaja estratégica [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014] para las organizaciones, pues contribuye a optimizar sus procesos, reduciendo tiempo y costes y aumentando la calidad de sus servicios. La implantación de BPM en una organización mejora el conocimiento general de la misma «Know-how de la organización», su funcionamiento interno y sus procesos de negocio [Malinova & Mendling 2013]. Las «organizaciones del software (TI)» no son una excepción; así aparecen recomendaciones realizadas por instituciones como «International Standard Office (ISO)», «Object Management Group (OMG)» y «Workflow Management Consortium (WfMC)», con distintas normas y estándares relativas a procesos generales y procesos específicos del software, sin olvidar conocidas propuestas como «Information Technology Infrastructure Library (ITIL)» [ITIL 2015; Iso/Iec 20000:2012; Clifford & van Bon 2008], PMBOK [PMI:PMBOK 2013], PRINCE2 [SOB 2009] o «Capability maturity model integration (CMMI)» [Chrissis et al. 2011], entre otras. Los procesos de las «TI» son más impredecibles y complejos que los de otros sectores, pues están en constante evolución al ser afectados, entre otros aspectos, por nuevos ciclos de vida, nuevas tecnologías y llevados a cabo por grandes equipos de desarrollo multidisciplinares; por esta razón, su establecimiento, control y medición es especialmente costoso [Ruiz-González & Canfora 2004]. Implantar el enfoque BPM supone gestionar dichos procesos e integrarlos con sistemas de información destinados a cubrir todas las áreas de la organización: producción de software, gestión de relaciones con clientes, proveedores o colaboradores, gestión económica y financiera, gestión de activos, etc. Algunos de estos sistemas, los más modernos, permiten la especificación y gestión de procesos (PAIS [Dumas et al. 2005]), pero otros no contemplan este enfoque (legacy systems [Bisbal et al. 1997, 1999; Stavru et al. 2013]); de cualquier manera, todos tienen en común que su capa de persistencia, representada habitualmente por bases de datos relacionales (legacy databases [Bisbal et al. 1997,1999; Pérez et al. 2003]), alberga estados que son el resultado de la ejecución de los procesos de negocio de la organización [van der Aalst 2015]. Estos estados están referidos a las distintas perspectivas de los xx Tesis doctoral – cam procesos: control del flujo, información, temporal, organizacional, operacional, y de casos [Jablonski 1996; Reichert & Weber 2012; van der Aalst et al. 2004, 2005, 2007, 2012]. La literatura está llena de referencias sobre dos enfoques para el análisis de los sistemas de información: i) Análisis orientado a datos y ii) Análisis orientado a procesos. En los últimos años han emergido técnicas que intentan trazar un puente entre los dos enfoques, como la minería de procesos («process mining») [van der Aalst et al. 2007, 2012; van der Aalst 2011, 2013, 2014, 2015; Reichert & Weber 2012] o enfoques que buscan la modernización del software y, en algún caso, la obtención de procesos utilizando el enfoque «Ingeniería del Software Dirigida por Modelos: Model Driven Engineering (MDE)» [Kent 2002; Schmidt 2006]. En este trabajo de tesis se va a plantear un enfoque, basado en MDE, que extraerá automáticamente aproximaciones a los procesos del software desde legacy systems 1 utilizados habitualmente por las «TI». La propuesta se va a centrar en el estudio de la dimensión temporal de los procesos, analizando los estados representados en la capa de persistencia, especialmente las estructuras y reglas que permiten capturar esta perspectiva: tareas, restricciones y dependencias temporales. Se desarrollará un conjunto de transformaciones, basadas en Meta  Modelos, que manejan la perspectiva temporal de los procesos en distintos niveles de abstracción, extrayendo aproximaciones a los procesos del software ejecutados por cada «TI», con objeto de ayudar en la implantación del enfoque BPM y de integrar esta tecnología con los legacy systems que se utilizan para planificar y controlar proyectos informáticos, gestionar documentación y todo tipo de contenidos, o bien para gestionar otras áreas de la organización como la económico-financiera, gestión de activos, relaciones con terceros (clientes, aprovisionamiento, activos, etc.). El resultado serán procesos expresados con notaciones gráficas muy extendidas [Bonnet et al. 2014] como BPMN [OMG:BPMN 2013; Iso/Iec:19510 2013], que otorgan mayor comprensibilidad [Lu & Sadiq 2007] para el experto en software, o bien basados en otros Meta  Modelos muy extendidos en el sector como «Software Engineering Meta  Model for Development Methodologies» [Iso/Iec:24744 2007, 2014] o «Software & Systems Process Engineering Meta  Model specification (SPEM 2.0)» [Bendraou et al. 2007; OMG: SPEM 2008]. BPMN es esencialmente imperativo, y tiene cierta capacidad para expresar la dimensión temporal, aunque manifiesta cierta debilidad para expresar un abanico amplio de éstas, razón por la que diversos autores están proponiendo extensiones que recojan mejor esta dimensión. La superposición de reglas temporales mediante un enfoque complementario de especificación [Fahland 2009a, 2009b; Pichler et al. 2011; Reijers et al. 2013] evitará la sobrecarga de los modelos con más artefactos de carácter 1 El término legacy system (sistema heredado) se asocia a sistemas de información basados en arquitecturas tecnológicas que pueden estar obsoletas. No obstante, estos sistemas suelen tener mucha funcionalidad y su sustitución es difícil y costosa. Tesis doctoral – cam xxi imperativo que, de otro modo, harían perder claridad a la especificación de los procesos. El enfoque de la tesis se contrasta con el caso “AQUA-WS Project”, que consistió en la modernización integral de la arquitectura de aplicaciones de la Empresa Metropolitana de Abastecimiento y Saneamiento de Aguas de Sevilla S.A. (EMASESA 2 ), basada en nuevo desarrollo web de distintos subsistemas, y soportada con la metodología «Navigational Development Techniques (NDT)» del grupo IWT2, que realizó el control de calidad del proyecto. Este caso ha servido para evaluar los resultados del trabajo de investigación, detectar limitaciones, e identificar trabajos futuros. 2 http://www.emasesa.com/ PARTE I. INTRODUCCIÓN Capítulo 1. Contexto de la investigación Parte I. Introducción 30 Tesis doctoral – cam Los centros productivos existentes a comienzos del siglo XX [US GPO 1918] ya manejaban el concepto de proceso (Definición 1.1 [Weske 2012]) para gestionar sus operaciones, especificando tareas, departamentos, entradas, salidas, recursos y su asignación, y la planificación de la ejecución del trabajo, etc. No es hasta mediados de los 90’s cuando se reactiva el uso del concepto de proceso, con la aparición del campo de la modelación de procesos de negocio [Rolstadås 1995]. Definición. 1.1. Proceso de negocio Un modelo de procesos formal permite compartir el conocimiento en toda la organización y facilita el adiestramiento de nuevo personal; también permite analizar la utilidad y oportunidad de cada actividad, medir eficiencias, tiempos muertos o bloqueos, parámetros de calidad, etc., tanto a nivel de detalle como para el proceso global. En la teoría de la organización «Management 16 » [Dean & Bowen 1994], enfoques como «Gestión Total de la Calidad: Total Quality Management (TQM)» [US Dod 1989; Dean & Bowen 1994; Dooley & Johnson 2001], y «Mejora de los Procesos: Process Improvement» [Dooley & Johnson 2001] se asocian a la mejora progresiva de calidad de los procesos existentes en la organización. La «Reingeniería de procesos de negocio: Business Process Reengineering (BPR)» (Definición 1.2 [Hammer & Champy 1993]) es un enfoque más ambicioso; BPR busca desechar procesos obsoletos y/o instaurar nuevos procesos, más simples, rápidos, económicos y eficientes para la organización, haciendo frente a los retos (se conoce como las tres Cs) que representan: i) las necesidades de los Clientes, ii) la Competencia en el mercado y iii) el riesgo de hacer Cambios drásticos en la organización. Para llevar a cabo un proyecto BPR es imprescindible contar con una plataforma TIC 17 robusta. Definición. 1.2. Business Process Reengineering (BPR) La reingeniería supone una ventaja estratégica para la organización [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014]. Inicialmente, la reingeniería se aplicaba a los procesos internos de cada organización, pero la evolución tecnológica 16 El Management versa sobre la coordinación de esfuerzos de personas y equipos para lograr metas y objetivos mediante el uso de los recursos disponibles de manera eficiente y eficaz. 17 Tecnologías de Información y Comunicaciones (TIC). Tecnologías de la Información (TI) «Un proceso de negocio consiste en un conjunto de actividades que se realizan en coordinación en un entorno organizativo y técnico. Estas actividades están relacionadas con un objetivo de negocio. Cada proceso de negocio es promulgado por una sola organización, pero puede interactuar con los procesos de negocio realizadas por otras organizaciones» «La reingeniería de procesos es un análisis y rediseño radical de la concepción fundamental de los procesos de negocio para lograr mejoras relevantes en costos, calidad, servicio y rapidez» Parte I. Introducción Capítulo 1. Contexto de la investigación Tesis doctoral – cam 31 (Internet, SOAP, Cloud Computing, etc.) ha llevado a plantear Procesos de Negocio Inter  Organizaciones «Inter  Organizational Business Processes (IOBP)»[Attaran 2004; Cheikhrouhou 2013a, 2014b] y al rediseño de relaciones entre dos organizaciones o «reingeniería X  engineering» [Attaran 2004], donde los procesos cruzan las fronteras de una organización; p. ej.: para definir relaciones con proveedores, clientes, socios, etc. que se ejecutan en un entorno colaborativo. Un concepto más amplio, que abarca a los anteriores, es «Business Process Management (BPM)» (Definición 1.3) [van der Aalst 2004; Netjes et al. 2006]: Definición. 1.3. Business Process Management (BPM) BPM es considerado por muchos investigadores como una ventaja estratégica [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014] para las organizaciones que utilizan este enfoque, pues contribuye a optimizar los procesos de las organizaciones, reduciendo tiempo y costes y aumentando la calidad de los servicios de la organización. Desde la aparición de las TIC, a mediados de los 50’s, el negocio del software ha venido padeciendo sensibles problemas, «Crisis del software (Software crisis)» [Dijkstra 1972; Sommerville & Kotonya 1998; Greenfield et al. 2004], que provocan serios inconvenientes en el desarrollo de sistemas informáticos, fundamentalmente por desviaciones en plazos y sobrecostes [Lauesen & Vinter 2001], que son bastante habituales y pueden provocar, en muchos casos, la cancelación de esos proyectos [Standish 2012; McNeil & Hanman 2013]. La reacción a esta crisis fue la aparición de la ingeniería del software (Definición 1.4) [Bauer 1972]: Definición. 1.4. Ingeniería del Software Acercarse a la problemática de las organizaciones orientadas al software requiere, en primer lugar, definir el concepto de «Proceso software» [Fuggetta 2000] (Definición 1.5.), entendido como proceso de negocio en el sector del software: «Business Process Management (BPM)» incluye aquellos métodos, técnicas y herramientas de soporte al ciclo de vida de los procesos de negocio, el cual a su vez incluye el diseño, aprobación, gestión y análisis de los procesos de negocio operacionales que involucran a personas, organizaciones, aplicaciones, documentos y cualquier otra fuente de información» «La ingeniería del software es el establecimiento y uso de principios de ingeniería robustos, orientados a obtener económicamente software que sea fiable y funcione eficientemente sobre máquinas reales» Capítulo 1. Contexto de la investigación Parte I. Introducción 32 Tesis doctoral – cam Definición. 1.5. Proceso software En ingeniería del software se contemplan distintos tipos de procesos [Pressman 2010]; entre ellos, pueden considerarse los grupos: i) Definición, que contempla las fases de captura de requisitos, análisis y diseño del sistema; ii) Desarrollo, que implica la generación de código y diferentes niveles de pruebas del mismo; y iii) Mantenimiento, que agrupa diferentes categorías de tareas para soportar la corrección de errores y evolución del producto para adaptarse a nuevos requisitos, a nuevas plataformas y para mejorar la estructura del propio código. En [Osterweil 1987] se resalta la relevancia de los procesos del software: «Software processes are software too»; cualquier acción encaminada a conseguir software fiable y dentro de plazos y costes aceptables es considerada como parte del proceso del software. Habitualmente, estos procesos se organizan como proyectos informáticos, que hoy en día ya no se asocian sólo a la creación de software sino a todo lo que implica, tanto su creación como su adquisición y uso (p. ej.: suministros y servicios informáticos) y control (control de la calidad). Existen múltiples estándares para distintas categorías de procesos, entre otros: los Iso/Iec [12207:2008; 24744:2007, 2014; 27000:2014; 29119:2014; 33001:2015; 9001:2015], modelos de referencia como SPEM [Bendraou et al. 2007; OMG: SPEM 2008]; y buenas prácticas, como: CMMI [Chrissis et al. 2011], ITIL [ITIL 2015; Iso/Iec 20000:2012; Clifford & van Bon 2008], PMBOK [PMI:PMBOK 2013] y PRINCE2 [SOB 2009], que proponen métodos y herramientas para, definir, desarrollar, mantener, usar, planificar y controlar plazos, costes y controlar la calidad de los productos generados en todo el ciclo de vida del software. Hay que tener en cuenta la singularidad de los procesos del software, pues están evolucionando continuamente, con nuevos ciclos de vida, nuevas tecnologías, estándares y buenas prácticas que hay que integrar en estos procesos, que son más complejos e impredecibles [Ruiz-González & Canfora 2004] que los de otros sectores profesionales. Muchas de las actividades son difíciles de automatizar, pues tienen fuertes dependencias de personas, de la organización de equipos de trabajo y de protocolos de comunicación entre individuos y grupos. Para paliar estos inconvenientes, en los últimos años, el paradigma «Ingeniería del Software Dirigida por Modelos: Model Driven Engineering (MDE)» [Kent 2002; Schmidt 2006] se ha establecido como un enfoque ampliamente aceptado para el desarrollo de software, teniendo su mejor exponente en «Model Driven Architecture (MDA)» [OMG:MDA; Kleppe et al. 2003] (ver Sección 3.1.2) del organismo OMG. Las organizaciones enfocadas al software gestionan su negocio con el mismo tipo de «El proceso software se define como un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos necesarios para concebir, desarrollar, desplegar y mantener un producto software» Parte I. Introducción Capítulo 1. Contexto de la investigación Tesis doctoral – cam 33 modelos, sistemas de información, estándares y buenas prácticas que organizaciones de otros sectores productivos, definiendo sus procesos, ejecutándolos y llevando a cabo su diagnóstico. Hoy en día, la mayoría de estas organizaciones, como las de otros sectores, tienen en cuenta el enfoque BPM [van der Aalst 2004; Netjes et al. 2006] para apoyar sus operaciones internas y las que implican actividades de colaboración con otras organizaciones. En cada caso es necesario establecer modelos de estos procesos que evolucionen adaptados al negocio. Los principales estándares en gestión de procesos seguidos por las organizaciones del software tienen en cuenta el enfoque BPM; entre ellos, los más relevantes son: i) [Iso/Iec:24744 2007, 2014] «Software Engineering Meta  Model for Development Methodologies» y ii) «Software & Systems Process Engineering Meta  Model specification (SPEM 2.0)» [Bendraou et al. 2007; OMG: SPEM 2008]; en la Sección 3.2 se analizará con mayor profundidad la literatura relacionada con la gestión de procesos del software. Tanto el enfoque MDE como BPM buscan reducir los inconvenientes detectados en los procesos del software [Dijkstra 1972; Sommerville & Kotonya 1998; Lauesen & Vinter 2001; Greenfield et al. 2004; Standish 2012] mediante la diferenciación de niveles de abstracción de modelos y Meta  Modelos [Seidewitz 2003; Fondemenet & Silaghi 2004] para conseguir independizar, en lo posible, los distintos modelos y los artefactos que los componen, buscando los beneficios que otorga la «interoperabilidad»; Veánse la Definición 1.6 del «Institute of Electrical and Electronics Engineers (IEEE)» [Geraci 1991], y la Definición 1.7 de la «Comunidad Económica Europea (CEE) 18 » [Criado et al. 2010]. Definición. 1.6. Interoperabilidad (IEEE) Definición. 1.7. Interoperabilidad (CEE) Hasta hace pocos años la gestión de procesos no ha estado automatizada, realizándose manualmente o con un nivel de automatización muy bajo, sostenido con herramientas 18 Este término es destacado en el ámbito de la Administración Electrónica Española. BOE núm. 25, de 29/1/2010, pp.8139-8156 «La habilidad de dos o más sistemas o componentes para intercambiar información y utilizar la información intercambiada» «La habilidad de organizaciones y sistemas dispares y diversos para interaccionar con objetivos consensuados y comunes y con la finalidad de obtener beneficios mutuos. La interacción implica que las organizaciones involucradas compartan información y conocimiento a través de sus procesos de negocio, mediante el intercambio de datos entre sus respectivos sistemas de tecnología de la información y las comunicaciones» “la habilidad de organizaciones y sistemas dispares y diversos para interaccionar con objetivos consensuados y comunes y con la finalidad de obtener beneficios mutuos. La interacción implica que las organizaciones involucradas compartan información y conocimiento a través de sus procesos de negocio, mediante el intercambio de datos entre sus respectivos sistemas de tecnología de la información y las comunicaciones” Capítulo 1. Contexto de la investigación Parte I. Introducción 34 Tesis doctoral – cam ofimáticas y/o el intercambio de correos electrónicos. Esto se debe, en gran parte, a que la automatización de distintas áreas de la organización está soportada por sistemas de información desarrollados a medida o con productos de mercado que no soportan el concepto de proceso, sino de función que el usuario debe lanzar para que se ejecute. Entre estos sistemas, en las últimas décadas, las organizaciones del software han venido utilizando sistemas automatizados para i) Planificar y controlar proyectos, como ejemplo MS Project [Hansen & Hansen 2013; Stover 2007] y RedMine [Lang 2010]; ii) más recientemente, sistemas para la gestión documental que permiten almacenar, compartir y algunas funciones de gestión de versiones y circuitos de aprobación de documentos, por ejemplo: «Alfresco» [Shariff 2013] o «MS Sharepoint» [Smith & Bates 2007] y iii) sistemas, más o menos integrados, que permiten gestionar otras áreas de la organización, como recursos humanos, nóminas y seguros sociales, finanzas y contabilidad, fabricación y logística, etc.; como ejemplo los ERPs SAP, Oracle Suite o Microsoft Business Solutions [Hendricks et al. 2007]. La mayoría de estos sistemas podrían agruparse bajo la categoría de «sistema heredado: legacy information system o legacy system» [Bisbal et al. 1997, 1999]; un legacy system, frecuentemente, no contempla el concepto de proceso, e incluye sólo las funciones cuyo orden de ejecución queda en manos del usuario. Un legacy system suele presentar tres niveles de abstracción o capas de la lógica [Eckerson 1995]: i) Capa de presentación, ii) Capa de aplicación y iii) Capa de persistencia. Un sistema informático es del tipo «Process aware information system (PAIS)» [Dumas et al. 2005] cuando contempla un nivel de abstracción adicional para los procesos, diferenciado de las aplicaciones y otorgando mayor nivel de independencia y de interoperabilidad de estos procesos con respecto a las aplicaciones internas de la organización o las de colaboradores externos. Una categoría especial de PAIS son los sistemas «Business Process Management Systems (BPMS)» [Dumas et al. 2013] (ver Sección 3.3.5), que cuentan con componentes para gestionar el ciclo de mejora continuo BPM 19 [van der Aalst 2004; Hill et al. 2006; Dumas et al. 2013]. La introducción de la tecnología BPM en una organización no supone sustituir o eliminar los legacy systems, sino integrar un BPMS con estos legacy systems y con los de otras organizaciones en un nuevo contexto global y tecnológicamente complejo. El ciclo de mejora continuo BPM propone la identificación, contraste y mejora de los procesos de negocio; mientras que un BPMS y, en general un sistema PAIS, cuenta con herramientas, como el log de eventos de ejecución [Reichert & Weber 2012] para automatizar, parcial o totalmente, la extracción de estos procesos mediante reingeniería o mejora continua de los procesos con técnicas como «process mining» [van der Aalst et al. 2007, 2012; van der Aalst 2011, 2013, 2014, 2015; Reichert & Weber 2012], que permiten contrastar modelos de procesos con las instancias ejecutadas de sus modelos, para diagnosticar el grado de cumplimiento de reglas del negocio y derivar nuevos modelos de procesos o mejorarlos. Pero no todos los legacy systems son de categoría PAIS, lo que significa que no existe log de eventos; por 19 El ciclo BPM de van der Aalst es de los más simples y conocidos, aunque existen otros en la literatura científica. Parte I. Introducción Capítulo 1. Contexto de la investigación Tesis doctoral – cam 35 ejemplo: sistemas para planificar y controlar proyectos, o para gestionar documentación y los sistemas desarrollados a medida para realizar otras funciones de gestión de la organización. Llevar el enfoque BPM a una organización va íntimamente ligado al empleo intensivo de TICs. Los expertos en el dominio del negocio y expertos en TI colaboran estrechamente, pues no es fácil extraer el conocimiento del dominio [Sommerville & Kotonya 1998]; los primeros son los que cuentan con el conocimiento del problema, mientras que los técnicos TI ayudarán a automatizar la ejecución y monitorización de estos procesos. Aceptando que el enfoque BPM es también una ventaja competitiva [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014] para el sector del software, una implantación BPM obliga a la especificación de modelos de procesos, lo que supone realizar entrevistas con el experto de negocio o manejar manuales organizativos que describan los procesos, pero que no siempre están actualizados; ésta es una fase crítica que representa un costo considerable, en sí, porque los procesos deben estar definidos fielmente para que sean útiles y por el coste que puede suponer cometer errores en su definición. Las organizaciones del software siguen utilizando legacy system no orientados a procesos, pero que contienen infinidad de datos (legacy database) que son el resultado de la ejecución de distintos procesos y esto sucede independientemente de que se utilie un sistema PAIS o un legacy system, aunque los primeros sí definen y dejan rastro de la ejecución de procesos. Una «TI» que implanta BPM puede plantearse una serie de cuestiones (Figura 1.1), que motivan el trabajo de tesis: i) ¿Debe empezar definiendo manualmente sus modelos de procesos? o ¿Puede extraerse conocimiento de legacy databases? ¿Es posible automatizar esta extracción? ii) ¿Cuáles serían los legacy systems candidatos para iniciar esta extracción de conocimiento? ¿Qué dimensiones de los procesos pueden analizarse en una legacy datatase? iii) ¿Qué puede aportar el paradigma MDE para realizar ingeniería inversa de una legacy database y representar una aproximación a los procesos? ¿Qué lenguajes de representación de procesos interesan al experto en software? Capítulo 1. Contexto de la investigación Parte I. Introducción 36 Tesis doctoral – cam Figura. 1.1. Extracción de procesos de legacy systems 1.3 Desarrollo del trabajo de investigación 1.3.1 Contexto Esta tesis se realiza dentro del Grupo de investigación «Ingeniería Web y Testing Temprano (IWT2) 20 » del Departamento de Lenguajes y Sistemas Informáticos 21 de la Universidad de Sevilla 22 , grupo referenciado en el Plan Andaluz de Investigación como PAIDI TIC021. En el grupo IWT2, constituido en el año 2000, se han estado desarrollando un conjunto de tesis doctorales relacionadas con la implantación de procesos de negocio, basados en el marco tecnológico NDTQ-Framework [Ponce et al. 2013; Aragón 2014] que se ha desarrollado a raíz de la propuesta metodológica «Navigational Development Techniques (NDT)» [Escalona 2004; Escalona & Aragón 2008] (que se describirán en esta memoria de tesis; Sección 2.4). Los trabajos de tesis se han ido contrastando en 20 http://iwt2.org/, referenciado como PAIDI TIC021 en el Plan Andaluz de Investigación. 21 http//www.lsi.us.es 22 http://www.us.es Parte I. Introducción Capítulo 1. Contexto de la investigación Tesis doctoral – cam 37 proyectos de transferencia tecnológica (se han realizado, hasta la fecha, más de 150 proyectos) de estas contribuciones metodológicas con organizaciones del sector público y privado, a nivel nacional e internacional, como el estudio comparativo de herramientas de modelación en la Consejería de Cultura de la Junta de Andalucía [IWT2 2008] y AQUA-WS Project [Cutilla et al. 2012] en la Empresa Municipal de Abastecimiento de Aguas de Sevilla, y CALIPSOneo [Escalona et al. 2013; Salido et al. 2014] en el sector aeronáutico europeo, para el Grupo Airbus 23 . De todos estos proyectos realizados por el grupo IWT2, los relacionados con la gestión de procesos de negocio y/o el paradigma MDE, hasta la fecha suponen un volumen económico de 3,5 M€. En particular, esta tesis está relacionada con otras tesis desarrolladas o en desarrollo por miembros del grupo de investigación. Aunque hay más trabajos en curso en el grupo, se destacan las siguientes, por estar relacionadas con procesos del software y emplear el Meta  Modelo de procesos NDTQ-Framework: i) García García, J.A. (2015): “Una propuesta para el uso del paradigma guiado por modelos (MDE) para la definición y ejecución de procesos de negocio”, IWT2. Esta tesis define las bases teóricas y prácticas de un marco metodológico para llevar a cabo una gestión de procesos de software desde una perspectiva basada en modelos, proponiendo una serie de Meta  Modelos y transformaciones para resolver este problema. La propuesta ayuda a formalizar, sistematizar y automatizar la gestión de procesos, generando una versión ejecutable de dichos procesos desde la definición. En el marco de la tesis, se ha desarrollado la herramienta PLM4BS basada en perfiles UML [Alhir 2006; Giachetti et al 2008] y plugins desarrollados sobre Sparx Sytems Enterprise Architect (EA) [Sparx:EA 2015], donde se plasma un protocolo automatizado para generar transformaciones QVT [OMG:QVT 2011] que llevan a procesos ejecutables. ii) García Borgoñón, L. (2015): “Un lenguaje para definir procesos del software integrados en entornos orientados a modelos”, IWT2. Trata de proporcionar a las organizaciones del software un mecanismo que mejore la interoperabilidad entre los diferentes lenguajes de modelado de procesos de negocio, para que sean capaces de elegir el lenguaje más apropiado que satisfaga sus necesidades. Incluye varios aspectos: a) Un lenguaje de modelado de procesos de negocio flexible, ampliable y adaptable mínimo que se puede utilizar en cualquier contexto del negocio. b) Un conjunto de protocolos que permiten la transformación de modelado de procesos de un lenguaje origen a un lenguaje destino. 23 http://www.airbusgroup.com Capítulo 1. Contexto de la investigación Parte I. Introducción 38 Tesis doctoral – cam 1.3.2 Metodología En esta sección se describe la actividad (Véase Figura 1.2) y metodología utilizada en el desarrollo de los trabajos. La Figura 1.2 ilustra la cronología del trabajo de investigación llevado a cabo, destacando las fases, publicaciones y proyectos de investigación. Figura. 1.2. Cronología del desarrollo de la tesis Con anterioridad a 2010, el doctorando realizó la formación de tercer ciclo en el programa de doctorado del Departamento de Lenguajes y Sistemas Informáticos: “Tecnología e Ingeniería del Software”, adscribiendo el proyecto de tesis a la línea de investigación: “Ingeniería del software”. A partir de 2010 se analiza el estudio del arte en relación a los paradigmas MDE y BPM, poniendo foco en la modelación y verificación de reglas sobre modelos de procesos [Gómez-López et al. 2010; Proyecto OPBUS]. Entre 2011 y 2013, durante el periodo de investigación, se realiza el trabajo de investigación presentado en el Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla como requisito a cumplir para la presentación de la Tesis Doctoral: «Diploma de Estudios Avanzados (DEA)». Durante este período se analizan: i) Propuestas y enfoques para la especificación y verificación de reglas sobre procesos de negocio, ii) Estudio de la problemática de legacy systems [Bisbal et al. 1997, 1999; Stavru et al. 2013]; iii) Enfoques para la modernización de legacy systems basados en MDE y ADM [Arevalo et al. 2013; Proyecto Tempros], evaluándose, entre otros i) La plataforma «Eclipse Modeling Framework (EMF)» [Merks 2010; Eclipse:EMF 2015] y ii) trabajos como 2010 2011 2012 2013 2014 2015 Estado del Arte BPM, Procesos de negocio Paradigma MDE Desarrollo DEA, Proyecto de Tesis Reglas de negocio sobre procesos Legacy Systems Ingeniería inversa MDE sobre BD Relacionales Procesos del software Meta  Modelos de procesos software Reglas temporales sobre procesos Ingeniería inversa de BDR en Legacy Systems para planificación y control de proyectos, y gestión documental Redacción memoria de la tesis [Gómez-López et al. 2010] [DEA; Proyecto de Tesis] [Arevalo et al. 2013] [Arevalo 2014] [Arevalo et al. 2015a] [Arevalo et al. 2015b] [Dominguez et al. 2015] [Proyecto OPBUS] [Proyecto Tempros] [Proyecto Megus] [Red Conacyt México] [Red PLM] [Proyecto Empower] Parte I. Introducción Capítulo 1. Contexto de la investigación Tesis doctoral – cam 39 MARBLE [Pérez-Castillo et al. 2009, 2011a, 2012a], basado en ADM, y la solución Gra2Mol [Izquierdo et al. 2008] y [Izquierdo & Molina 2009a, 2009b, 2014] desarrollada en Java sobre Eclipse. Durante este período se trabajó con EMF enfocando el esfuerzo a la ingeniería inversa [Chikofsky & Cross 1990] de legacy systems, instalando, evaluando y manejando esquemas de sistemas reales sobre ORACLE; se han utilizado los subsistemas: i) Núcleo EMF que maneja la variante Ecore de la facilidad «Essential Meta-object Facility (EMOF)» [OMG:MOF 2011], generando modelos en este formato y conforme a su Meta  Modelo. Provee distintos editores para generar modelos e instancias que se pueden intercambiar en formato .xmi [OMG:XMI 2013]. ii) Xtext [Eclipse:Xtext 2015] como framework para definir «Lenguajes específicos de dominio o Domain Specific Languages (DSL)» [van Deursen 1997, 2000]. Xtext utiliza «ANTLR (ANother Tool for Language Recognition» [Parr & Fisher 2011; Antlr 2015] como base para crear reconocedores sintácticos, interpretes, compiladores en base a las descripciones gramaticales realizadas conforme a un Meta  Modelo. iii) ATL [Eclipse:ATL 2015; Jouault et al. 2008] que permite realizar transformaciones «Modelo-to-Text (M2T)». iv) Modisco [Eclipse:Modisco 2015; Bruneliere et al. 2010b] es el módulo que facilita la ingeniería inversa de legacy systems. Permite definir Meta  Modelos Ecore y extraer modelos con discoverers (Java, JSP y XML entre otros). La generación de nuevos discoverers es compleja y se requiere una gramática basada en ANTLR. Sobre esta infraestructura se han realizado exploraciones a distintas bases de datos de proyectos de I+D+i [Cutilla et al. 2011; Escalona et al. 2013; Salido et al. 2014]. Sobre EMF también se ha instalado Gra2Mol [Izquierdo et al. 2008; Izquierdo & Molina 2009a, 2009b, 2014], como solución propietaria alternativa a Modisco que intentaba resolver inconvenientes de la plataforma EMF en el momento de su desarrollo. Se han manejado los Meta  Modelos relacionales existentes en la solución Gra2Mol para PL/SQL y AtlanMod Zoos 24 . v) OCL [OMG:OCL 2014; Iso/Iec 19507:2012]. EMF proporciona tres niveles para la especificación de restricciones OCL: a) «Essential OCL» para expresiones OCL básicas sobre elementos; b) «Xtext OCLinEcore de OCL”» que permite incrustar fórmulas OCL en un modelo Ecore; y c) «Complete OCL», que permite cargar 24 [Atlanmod 2015] ofrece Meta  Modelos para esquemas relacionales básicos: CWMRelationalData 1.0. Relational 1.1, RelationalDBContent 1.0 y RelationalDBSchema 1.0. Estos Meta  Modelos están disponibles para su descarga libre; están expresados conforme a los Meta  Modelos Kernel Meta Model [Eclipse:KM3 2006] y Ecore para plataformas Eclipse Modeling Framework [Merks 2010; Eclipse:EMF 2015], pero se centran en las estructuras relacionales básicas y son simples. http://www.emn.fr/z-info/atlanmod/index.php/Zoos Capítulo 2. Retos y objetivos Parte I. Introducción 46 Tesis doctoral – cam de relaciones con clientes, proveedores y colaboradores, iv) Gestión económicofinanciera. Estos sistemas deben integrarse con el BPMS, que albergará los modelos de procesos y facilitará su ejecución y diagnóstico. El problema planteado es “La extracción automática de procesos del software desde legacy systems, que ayuden a una organización a implantar BPM como impulso estratégico”. 2.2 Retos Las «TI» se enfrentan a distintos retos: i) Es fundamental definir y mantener vivos los procesos del software de una organización para ser competitiva en el mercado global. El enfoque BPM es estratégico para las «TI» que, con tecnología BPMS, debe aunar todo tipo de estándares, modelos de referencia y buenas prácticas para conseguir procesos del software de calidad. ii) Un proyecto BPM requiere una definición detallada de modelos de procesos, la cual está en manos del experto del dominio del problema (experto de negocio en software) que puede definirlos desde cero, o bien puede partir de los legacy systems existentes. Algunos legacy systems manejan procesos, como es el caso de los «Process aware information system (PAIS)» [Dumas et al. 2005], pero lo más habitual es que no soporten este concepto. Existen iniciativas de modernización de legacy systems como «Architecture Driven Modernization (ADM)» [Newcomb 2005; OMG:ADM 2005; Ulrich & Newcomb 2010] y enfoques de modernización del software como «Model Driven Software Modernization (MDSM)» [Favre 2004], ambas basadas en MDE y en procesos de ingeniería inversa [Chikofsky & Cross 1990; Favre 2004, 2010; Bruneliere et al. 2010a] que permiten extraer artefactos (estructuras de datos, restricciones) de niveles de abstracción bajos (código fuente, esquemas de bases de datos) para presentar otros artefactos de modelos de nivel mayor de abstracción (clases, actividades, flujos, reglas de negocio). Ante estos retos: i) ¿Es posible ofrecer al experto en software una aproximación a los procesos de negocio que se están llevando a cabo en su organización?; ii) ¿Puede derivarse automáticamente ese conocimiento de los sistemas que están en funcionamiento (legacy systems)?; iii) ¿Qué tipo de legacy systems son mejores para abordar esta extracción?; iv) ¿Qué enfoques y tecnología puede generar estas aproximaciones de los modelos de procesos? y v) ¿Qué sistemas de representación de procesos interesan a los expertos en software?. A continuación se expone un caso motivador de extracción de un proceso de negocio Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 47 desde «Microsoft™ (MS) Project 29 » [Hansen & Hansen 2013]. En la siguiente sección se definirán objetivos que detallan el enfoque del trabajo y, por último, se planteará una aproximación a la solución que se propondrá en esta tesis. 2.3 Un ejemplo motivador Todas las «TI» llevan a cabo proyectos, donde uno de los riesgos principales de estos proyectos es una mala planificación, o peor aún, su inexistencia [Standish 2012; McNeil & Hanman 2013]. La planificación no es estática sino que suele estar viva durante todo el proyecto. El responsable o Jefe de Proyecto suele utilizar técnicas que le permiten gestionar planes que involucran tareas, recursos y grupos de recursos, asignaciones y reglas que establecen restricciones de tiempo y de recursos (personas, perfiles, costes u otros); las técnicas más conocidas son los «Diagramas de Gantt» [Gantt 1919; PMI:PMBOK 2013] y los grafos «Project Evaluation and Review Tecnhiques (PERT)» [Malcolm et al. 1959; PMI:PMBOK 2013]). La duración mínima del proyecto se puede calcular resolviendo el grafo PERT con el método «Critical Path Method (CPM)» [Kelley & Walker 1959]. MS Project [Hansen & Hansen 2013] es un sistema informático para gestión de proyectos bajo licencia MicrosoftTM, utilizado frecuentemente en todo el mundo, entre otras, por las «TI». El caso presentado es una planificación MS Project de un proyecto realizado por una «TI», representada mediante un «Diagrama de Gantt». El resultado buscado es un modelo de negocio correspondiente al proyecto especificado, en este caso, con el estándar «Busines Process Model and Notation (BPMN)» [OMG:BPMN 2013; Iso/Iec:19510 2013]. Se verá, en esta memoria de tesis, que el sistema origen podría ser otro, incluso de otro tipo, y que, el sistema destino también podría ser otro sistema de representación de los procesos diferente a BPMN. El proceso de negocio generado se obtiene manejando sólo la perspectiva temporal que se observa en el plan de partida. El objetivo del planteamiento no es realizar un planteamiento formal, sino ilustrar la idea que se desarrollará en la tesis. En este documento se establecerán las hipótesis, objetivos y métodos para generar sistemáticamente procesos que representan las interacciones y reglas de negocio definidas en un proyecto. 2.3.1 Planificación de un proyecto como sistema origen El diagrama de Gantt de la Figura 2.1 representa el “plan de un proyecto de una empresa consultora que realiza una reingeniería de procesos de negocio (BPR) [Hammer & Champy 1993; Mohapatra 2012] en un cliente”. Las tareas contempladas son: 1) Reunión de Lanzamiento del proyecto. 2) Análisis de la situación actual. 29 Existen otros productos para gestionar proyectos, tanto del mismo fabricante, como MS Project Server [Stover 2007], software libre como RedMine [Lang 2010] y otros. Capítulo 2. Retos y objetivos Parte I. Introducción 48 Tesis doctoral – cam 5) Definir nuevo modelo de negocio. 9) Entrega del Modelo. 10) Aceptación del Modelo. 11) Facturación. Las tareas (2) y (5) son en realidad grupos de tareas que se subdividen en: 3) Revisar documentación. 4) Realizar entrevistos. 6) Modelo básico. 7) Revisión. 8) Refinamiento. Para definir el plan del proyecto es necesario especificar: a) Restricciones de tiempo ligadas a cada tarea elemental y b) Dependencias temporales entre tareas, expresadas como relaciones de precedencia en consonancia con las restricciones que aparecen en el «Álgebra de intervalos de Allen» [Allen 1983]. Las tareas de grupo (2) y (5) fijan sus restricciones de tiempo en función de la planificación de las tareas subordinadas y de sus interrelaciones con otras tareas del plan. Figura. 2.1. Un ejemplo de planificación de actividades con MS Project 2.3.1.1 Restricciones temporales En primer lugar hay que distinguir el tipo de duración de cada tarea, que puede ser duración fija o estimada (calculada con CPM) y puede especificarse (Figura 2.2) en distintas unidades (días, semanas, meses, etc.). Cuando es estimada, aparece con un signo de interrogación sobre el diagrama. Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 49 Figura. 2.2. Restricciones temporales sobre tareas en MS Project, p. ej.: MSON, SNET También pueden especificarse restricciones temporales [Allen 1983] ligadas al inicio y terminación de cada tarea elemental, especificando si la programación es manual o automática (calculada mediante CPM). Por defecto, MS Project asocia restricciones «As Soon As Possible (ASAP)» a cada tarea; no se requiere la especificación de una fecha como restricción. No obstante, pueden especificarse restricciones específicas (programando manual o automáticamente y especificando en las pestañas generales y avanzadas). 2.3.1.2 Dependencias temporales En la pestaña predecesoras (Figura 2.3) se especifican las dependencias temporales 30 (CC=Start To Start, CF=Start To Finish, FC=Finish To Start que es la opción por defecto y FF=Finish To Finish) [Allen 1983]. La columna Pos especifica el adelanto o retraso entre los dos eventos; en este caso, la tarea sucesora (tarea 10: Aceptación) comienza al terminar la predecesora (tarea 9: Entrega del modelo); se especifica una dependencia de tipo FS (en castellano FC). Figura. 2.3. Dependencias temporales sobre tareas en MS Project, p. ej.: FS 2.3.2 Proceso BPMN para el plan del proyecto MS Project maneja una perspectiva temporal de tareas que permite ordenarlas en el tiempo y fijar restricciones para cada tarea y restricciones para las relaciones de precedencia. Se plantean las cuestiones: i) ¿Puede representarse el conocimiento del plan de proyecto de la Figura 2.1 como un proceso de negocio BPMN? ii) ¿Qué transformaciones hay que realizar para la obtención del proceso? 30 La versión de MS Project usada es en castellano. Las dependencias temporales están traducidas y la equivalencia es CC=SS, CF=SF, FC=FS y FF=FF. Capítulo 2. Retos y objetivos Parte I. Introducción 50 Tesis doctoral – cam La primera equivalencia o patrón de transformación consiste en representar un “Plan de Proyecto” como un “Proceso de Negocio BPMN” (Figura 2.4): A continuación hay que establecer patrones de mapeo para las tareas del proyecto. En BPMN una tarea es una actividad elemental, pero también son actividades: un grupo de tareas, un subproyecto o un proyecto. Por tanto, es posible: i) Mapear las tareas elementales del proyecto como actividades BPMN. ii) Considerar procesos BPMN Ad-hoc para representar tareas de grupo del proyecto, como es el caso de “Análisis de la Situación Actual”, modelado como subproceso expandido, que incluye las actividades elementales “Revisar Documentación” y “Entrevistas” que corren en paralelo. El subproceso “Definir nuevo proceso de negocio” se ha modelado como subproceso colapsado, cuyo detalle se muestra en la Figura 2.5. iii) Mapear restricciones de tiempo como anotaciones en el diagrama (color azul). Así aparecen Actividades con “Duración Fija” y “Duración Flexible” (son aquellas donde la misma es estimada). Por defecto, sobre los eventos de inicio y terminación de una Actividad, la restricción MS Project es “Tan Pronto Como Sea Posible”; no se ponen leyendas en el diagrama BPMN para estos casos. Sí se ponen explícitamente para los casos: “Entrevistas” con una restricción “Tan Tarde Como Sea Posible” y “Entrega del Modelo” con una restricción “Empezar No Antes De: 17/8/15”. Las duraciones de los subprocesos “Análisis de la situación actual” y “Definir nuevo proceso de negocio” son calculadas mediante el método CPM [Kelley & Walker 1959]. iv) Mapear las dependencias temporales (color rojo). Estas dependencias (relaciones de precedencia en un diagrama «PERT» [Malcolm et al. 1959; PMI:PMBOK 2013]) se transcriben como flujo de control del proceso. Se especifican con arcos, puertas y leyendas en color rojo. Las dependencias “Fin a Comienzo” se resuelven con flujo de control secuencial, mientras que las dependencias “Comienzo a Comienzo” y “Fin a Fin” exigen ejecución en paralelo (puertas de bifurcación y sincronización en paralelo). Así, puede obtenerse un modelo BPMN (Figura 2.4) que se corresponde con el plan del proyecto de partida (Figura 2.1). Este proceso refleja aspectos del flujo de control y de la perspectiva temporal que se ha derivado del plan del proyecto en MS Project. Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 51 Figura. 2.4. Tareas del proyecto como actividades del proceso BPMN (a) Proceso general (b) Subproceso “Definir proceso de negocio” Capítulo 2. Retos y objetivos Parte I. Introducción 52 Tesis doctoral – cam 2.3.3 Discusión En la sección anterior se ha planteado un camino para derivar un proceso de negocio BPMN a partir de un plan de proyecto realizado con MS Project. Hay que reflexionar sobre algunos puntos que han permitido llegar a ese resultado: i) MS Project soporta el Álgebra de Allen [Allen 1983] y el método Critical Path Method (CPM) [Kelley & Walker 1959] que genera un grafo de duración mínima para un plan expresado con un grafo PERT [Malcolm et al. 1959; PMI:PMBOK 2013]. BPMN no soporta esta semántica, aunque sí tiene artefactos (eventos de temporización y señales) que permitirían generar construcciones o patrones, como se realiza en el trabajo [Flores & Sepúlveda 2011] para recoger la dimensión temporal. En el diagrama BPMN se han incluido anotaciones para todas las reglas detectadas, pero eso no supone una formalización de restricciones y dependencias temporales, por lo que se sugiere la cuestión: ¿De qué modo pueden formalizarse estas reglas sobre BPMN u otros lenguajes de especificación de procesos utilizados por los expertos del software? ii) MS Project también gestiona recursos y grupos de recursos, por tanto: ¿Podría enriquecerse la definición del proceso contemplando recursos, grupos de recursos y sus asignaciones? iii) Además de MS Project, ¿Qué otros sistemas de gestión de proyectos podrían utilizarse para extraer estas aproximaciones a los procesos? ¿Podrían utilizarse otros legacy systems, como sistemas de gestión documental o de contenidos, ERPs, CRMs, SCMs o bien desarrollos a medida? iv) ¿Podrían extraerse automáticamente estos procesos? ¿Qué enfoques tecnológicos podrían utilizarse? v) Se han establecido reglas de transformación que permiten ir de un plan a un proceso. Para un conjunto de proyectos se generaría un conjunto de procesos, pero ¿Sería posible obtener un tipo o clase de procesos que representase un modelo de procesos genérico? A raíz del ejemplo analizado, estos retos planteados permitirán centrar los objetivos del trabajo de investigación. 2.4 Hipótesis y objetivos El objetivo fundamental de esta investigación es “Extraer aproximaciones a los procesos de las «TI» desde legacy systems [Bisbal et al. 1997, 1999; Stavru et al. 2013] utilizando la dimensión temporal”. El objetivo de partida para el trabajo de investigación es llevar a cabo: (ob.0) Un estudio del estado del arte relacionado con: i) Sistemas de información heredados (legacy systems). Se analizarán los problemas que platean y los enfoques para su modernización, especialmente los relacionados con el Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 53 tratamiento de bases de datos (legacy databases). ii) Lenguajes para representación de procesos del software. Se estudiarán los sistemas de representación de procesos más extendidos en el sector TI, contemplando tanto estándares generales como específicos para el ciclo de vida del software. iii) Especificación de reglas temporales sobre procesos. Se estudiarán las fortalezas y debilidades de los sistemas del apartado anterior. Se seleccionará la bibliografía científica que contemple la modelación de la dimensión temporal sobre los procesos. El contraste de estos dos puntos permitirá establecer una taxonomía de reglas temporales que abarque la tipología de reglas de negocio manejadas en el sector TI. Por otro lado, permitirá detectar las necesidades de extensión de los modelos de procesos a utilizar. En relación con los bloques anteriores se definen hipótesis de trabajo y, sobre ellas, los objetivos detallados a alcanzar. 2.4.1 Legacy systems como sistemas origen Esta sección está relacionada con los sistemas de información utilizados habitualmente por las «TI» que se plantean BPM como nuevo enfoque estratégico en su negocio. En los últimos años las «TI» han usado sistemas que, en mayor o menor medida, automatizan sus procesos de negocio, facilitando la adopción de metodologías, la definición y gestión de equipos de trabajo, personas, perfiles, recursos, productos entregables y la planificación y control de proyectos y tareas ligadas al software. Estos sistemas, bien como productos de mercado adaptables o como desarrollos específicos (a medida o propietarios) suelen estar soportados por bases de datos relacionales [Codd 1970, 1992] (legacy databases) que recogen estructuras de datos y, en muchos casos, tienen embebidas reglas de negocio [Türker & Gertz 2001] ligadas a estos procesos. El esquema relacional de una base de datos (legacy database) se sitúa en el nivel de implementación de una aplicación. Está representado por tablas que definen tipos de datos y reglas intrínsecas o estructurales sobre valores de columnas en una fila, diversos tipos de claves (primarias, alternativas, ajenas). Estas definiciones son persistentes y están plasmadas en el catálogo de cada base de datos configurando la Meta-base de datos. Las versiones comerciales de gestores de bases de datos que soportan disparadores (triggers) permiten implementar reglas específicas codificadas, normalmente, como bloques de programación en lenguajes procedurales propietarios, que encapsulan código catalogado como artefactos ligados mediante eventos a las tablas. El referente ISO de lenguaje propietario procedural es ISO SQL/PSM 31 [Eisenberg 1996; Melton & Simon 2002] para la codificación de rutinas, funciones y disparadores en el esquema de la base de datos. Los productos comerciales basan sus lenguajes propietarios en variantes de SQL/PSM, aunque cada uno con una sintaxis concreta; así PL/SQL [Feuerstein & Pribyl 31 El componente “Persistent Stored Modules” SQL/PSM es propuesto como lenguaje procedural para la especificación de funciones, procedimientos y triggers. Aparece por primera vez en el estándar ISO SQL:1999 y se ha mantenido hasta la versión ISO SQL:2011. Capítulo 2. Retos y objetivos Parte I. Introducción 54 Tesis doctoral – cam 2005] es el producto de ORACLE™, Transact-SQL [Colledge 2008; Ben-Gan 2012; Microsoft™:T-SQL 2014] el de SQL*Server™, PL/pgSQL el de PostgreSQL™ y MySQL™ stored procedures [Harrison & Feuerstein 2008] el del popular MySQL[Dubois 2005]. Los Meta  Modelos de un esquema relacional se sitúan en el nivel de abstracción cercano a cada plataforma (nivel PSM). Se consideran dos tipos de Meta  Modelos basados en sintaxis abstracta (ASTM): genéricos (GASTM) para las estructuras tabulares de cualquier base de datos relacional, y específicos (SASTM) para cada caso concreto de gestor de base de datos comercial, contemplando estructuras, restricciones y disparadores codificados en el lenguaje procedural propietario de cada producto (ver Anexo II donde figuran los Meta  Modelos de algunos legacy systems seleccionados para el estudio). Se consideran las siguientes hipótesis y objetivos: (hp.1) Uso de legacy systems en «TI». La mayoría de las «TI» utilizan frecuentemente sistemas de información automatizados (legacy systems) para i) Planificación y gestión de proyectos, p. ej.: «MS Project» [Hansen & Hansen 2013; Stover 2007]» o «RedMine» [Lang 2010]; ii) Gestores de contenido o documentales «Enterprise Content Management Systems (ECM)» como «Alfresco» [Shariff 2013] o «MS Sharepoint» [Smith & Bates 2007]; y iii) Gestión general de recursos (ERPs) [Hendricks et al. 2007]: procesos de negocio de compras, ventas, gestión financiera, gestión de activos, CRMs, SCMs [Hendricks et al. 2007], o bien en desarrollos a medida. (hp.2) Legacy database como estado de los procesos de negocio. Los sistemas referenciados en (hp.1) suelen tener una legacy database relacional basada en SQL [Melton & Simon 2002], que hace persistentes estados que son el resultado de la ejecución de procesos de negocio [van der Aalst 2015]. En estas legacy databases aparecen tareas, recursos, grupos de recursos, restricciones temporales y asignaciones de recursos que están relacionados con las perspectivas de control del flujo, información, temporal, organizacional, operacional, y de casos [Jablonski 1996; Reichert & Weber 2012; van der Aalst et al. 2004, 2005, 2007, 2012] que pueden encontrarse en un proceso. Estos sistemas, en mayor o menor medida, contienen estructuras y reglas de negocio (tablas, restricciones, disparadores) que pueden, además, estar embebidas en los esquemas mediante código propietario [Feuerstein & Pribyl 2005]. MS Project Server no es un sistema de la categoría PAIS. Cada proyecto planificado está relacionado con instancias de uno o más procesos realizados por la «TI». La dimensión temporal de un proyecto (visto como un proceso) está formalmente definida con este sistema, de modo que la legacy database representa un conjunto de instancias de procesos, compuestos por tareas que se han planificado y que están en Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 55 ejecución o han terminado (lo cual puede ser visto como una sucesión de eventos que acontecen en el proceso de la «TI», independientemente de que el proceso esté automatizado o se ejecute manualmente mediante la invocación de sucesivas funciones por los usuarios del sistema). Para utilizar estos legacy systems como fuente para extraer procesos de negocio se plantean los siguientes objetivos. (ob.1.) Establecer MetaModelos de tareas para legacy systems de uso habitual en «TI». Se estudiarán los «legacy systems referenciados en (h1)» respecto a estructuras y reglas existentes en su capa de persistencia, relacionadas con las distintas perspectivas de los procesos, y en particular, las estructuras relacionadas con la dimensión temporal: tareas, agrupaciones de tareas, reglas y dependencias temporales entre ellas. El estudio se enfoca a representar Meta  Modelos de tareas existentes en cada legacy system (Ver Anexo II), que, a nivel tecnológico, están vinculados con los Meta  Modelos de los sistemas relacionales que los soportan (GASTM, SASTM; ver Anexo III). Se prestará atención especial a las distintas bases de datos «MS Project Server» definidas sobre el gestor de base de datos SQL*Server [Colledge 2008; Ben-Gan 2012; Microsoft™:T-SQL 2014], estudiando el soporte de la dimensión temporal de este legacy system. 2.4.2 Reglas temporales sobre procesos BPM contempla distintas perspectivas [Jablonski 1996; Reichert & Weber 2012; van der Aalst et al. 2004, 2005, 2007, 2012] para un proceso de negocio. Vamos a poner el foco en la perspectiva temporal, buscando artefactos ligados a la gestión de tareas en legacy systems que han venido sirviendo para planificar y controlar proyectos informáticos. Creemos que, con esta perspectiva, muy común en este tipo de sistemas, llegaremos a representar una aproximación de los procesos, extrayendo actividades, características del flujo de control y un conjunto de reglas o restricciones temporales que refinarán estos procesos. Con posterioridad, manteniendo el mismo esquema, podrían integrarse otras perspectivas para generar procesos más enriquecidos; por ejemplo, utilizando la perspectiva de recursos o de casos [van der Aalst et al. 2005, 2007] donde existen Meta  Modelos basados en UML [Awad et al. 2009; Stroppi et al. 2012] que servirían para extender nuestra propuesta inicial. Se consideran las siguientes hipótesis: (hp.3) Perspectiva temporal en los lenguajes de modelación de procesos. Existen múltiples lenguajes para la modelación de procesos que contemplan la perspectiva temporal, recogiendo distinto tipo de restricciones y dependencias temporales entre actividades (Véase Capítulo 4: trabajo relacionado). (hp.4) Comprensibilidad de los lenguajes gráficos. La notaciones gráficas para especificación de procesos aportan beneficios significativos en el contexto BPM [Lu Capítulo 2. Retos y objetivos Parte I. Introducción 62 Tesis doctoral – cam [Escalona 2004; Escalona & Aragón 2008]. Todos ellos tienen en común la existencia de Meta  Modelos de procesos que necesitan ser reforzados para representar adecuadamente la dimensión temporal, razón por la cual se hace necesario establecer una clasificación o taxonomía de reglas temporales y un Meta  Modelo PIM que soporte el proceso de extracción automática o ingeniería inversa mediante MDE. 2.6 Resumen y conclusiones Las «TI» manejan procesos de negocio complejos, cambiantes e íntimamente ligados a personas, equipos y protocolos de comunicación entre ellos, incluyendo actividades que no siempre es posible automatizar. Los legacy systems evolucionan continuamente para soportar nuevos estándares, tecnologías y mejores prácticas. El enfoque BPM es un valor estratégico indiscutible para todo tipo de organización, y también lo es para las «TI». Este enfoque propone un ciclo de mejora continua de los procesos, donde es necesario modelarlos, ponerlos en ejecución, y evaluar el grado de cumplimiento o conformidad de estos respecto a los modelos definidos, para mejorarlos y eliminar inconvenientes que perjudican a la organización. Mientras que los PAIS proveen herramientas automáticas que ayudan a la mejora continua, en general, otros legacy systems carecen de ellas. No obstante, cualquier organización deja trazas de sus procesos, como estados persistentes en legacy databases. En este Capítulo se utiliza un ejemplo motivador, basado en la planificación de un proyecto con el sistema MS Project. El caso representa un proyecto compuesto por tareas, y una representación alternativa del mismo con la notación BPMN, asociando un proceso al proyecto y actividades a las tareas, además de trasladar un conjunto de restricciones y dependencias temporales del proyecto al proceso, que condicionan el flujo de control del mismo y asociando anotaciones que recogen las restricciones de la dimensión temporal asociada al proyecto. Este caso de transformación parte del estado del proyecto (almacenado en la legacy database de MS Project), utiliza el análisis de la dimensión temporal y usa ciertos patrones para acondicionar el flujo de control del proceso con BPMN. Tras el ejemplo, se han definido hipótesis de partida y objetivos que se persiguen con este trabajo de investigación, agrupados en: i) Tratamiento de los sistemas de información de origen (legacy systems comunes en las «TI»); ii) Estudio de la dimensión temporal de los procesos; iii) Elección de lenguajes para la representación de procesos en notaciones cercanas al experto; iv) Métodos basados en ingeniería inversa MDE para transformar automáticamente estados de legacy databases en aproximaciones a los procesos del software, contemplando aspectos del control del flujo y de la dimensión temporal; v) Por último se selecciona un caso de estudio, suficientemente significativo en cuanto a nivel de complejidad, AQUA-WS Project, que es un proyecto de modernización Web en la Empresa Municipal de Abastecimiento de Aguas del Excmo. Ayuntamiento de Sevilla (EMASESA), donde se aplican los principios metodológicos de NDT, y se han utilizado Parte I. Introducción Capítulo 2. Retos y objetivos Tesis doctoral – cam 63 sus procesos en las distintas fases de concepción, análisis, diseño, construcción e implantación de distintos subsistemas software. El caso debe servir para contrastar el grado de cumplimiento de los objetivos definidos y las limitaciones del enfoque propuesto en el trabajo de investigación. PARTE II. ANTECEDENTES Tesis doctoral – cam 67 Capítulo 3. ESTADO DEL ARTE “La verdadera ciencia enseña, sobre todo, a dudar y a ser ignorante" Ernest Rutherford (1871-1937) as organizaciones del software «TI» se desenvuelven en una sociedad globalizada muy compleja y competitiva. Como en otros sectores, necesitan del enfoque BPM para gestionar su negocio y reducir los problemas detectados en los 70’s por Dijkstra en la denominada crisis del software, algunas de cuyas causas siguen estando aún vigentes. En este Capítulo se analizan estándares y buenas prácticas en relación con los objetivos que se han planteado para la tesis en el Capítulo 2. Se revisa el paradigma dirigido por modelos MDE y la conocida iniciativa MDA de la OMG. Se estudia el enfoque BPM, desde el punto de vista de su ciclo de vida de mejora continua y la arquitectura de sistemas y estándares que desarrollan este paradigma. Específicamente, para los procesos del software, se han analizado lenguajes, estándares, tendencias y mejores prácticas. Se dedica un apartado a describir las características de nuestra metodología «Navigational Development Techniques (NDT)» y NDTQ-Framework fundamentado en NDT, MDE, UML y OCL, que propone procesos para distintas fases del ciclo de vida del software. Por último se han analizado los problemas de los legacy systems y el enfoque de modernización ADM propuesto por el OMG. 3.1 Ingeniería del software dirigida por modelos 3.1.1 Problemas del desarrollo tradicional de software Hace décadas que Dijkstra identificó la problemática del desarrollo de software, acuñando el término «Crisis del software» [Dijkstra 1972; Pressman 2010]; aunque han transcurrido más de cuarenta años, algunos de los problemas siguen aún estando vigentes: i) Baja calidad del producto en general. El software no satisface los requisitos y la funcionalidad alcanzada no es adecuada. La captura de requisitos del sistema es uno de los puntos críticos de un sistema, pues, por diversas razones, no es fácil que, utilizando lenguaje natural, un experto en TI obtenga fielmente el conocimiento que posee el experto en el dominio [Sommerville & Kotonya 1998]. Esto supone una fuente de errores importantes, que se propagan y multiplican a otros niveles, generando, entre otros inconvenientes, retrasos y costos económicos [Lauesen & Vinter 2001]. La detección en etapas posteriores obliga a redefinir los L Capítulo 3. Estado del arte Parte II. Antecedentes 68 Tesis doctoral – cam requisitos y a corregir los artefactos dependientes en los niveles afectados del sistema. ii) Desviaciones significativas en la planificación, tanto en plazos como económica. Costes desorbitados de mantenimiento con el tiempo. En [Greenfield et al. 2004] se apuntan posibles causas de estos inconvenientes: i) Deficiencias en la gestión del conocimiento. No se maneja bien el Know how ni el código generado en proyectos anteriores. ii) Desarrollo monolítico con componentes muy interdependientes. iii) Utilización de lenguajes de bajo nivel que, ofreciendo flexibilidad y eficiencia en la ejecución, provocan baja productividad por la cantidad de errores que el programador debe subsanar. iv) Aunque se ha avanzado en estandarización y modelos de madurez del software, los procesos no son tan estables como otros procesos de la ingeniería (construcción, fabricación, etc.). v) La elevada demanda de los usuarios provoca el planteamiento de proyectos en los plazos muy reducidos. En relación a estos problemas, sus causas y la repercusión en proyectos del software, la empresa consultora The Standish Group International, Inc. elabora el informe «The Standish Group Chaos» [Standish 2012] que evalúa grandes proyectos software en el mundo para medir, entre otras variables: a) Proyectos que acaban con éxito (Succesful), cumpliendo plazo y costes, b) Proyectos que terminan con desviaciones en plazo o costes (Challenged) y c) Proyectos cancelados (Failed). La Figura 3.1 muestra el informe global de 2012, donde sólo el 39% de los proyectos acaban según lo presupuestado y planificado y el 18% son cancelados. Figura. 3.1. Informe Chaos 2012 Fuente: The Standish Group International, Inc. https://www.standishgroup.com/ Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 69 Figura. 3.2. Informe Chaos: serie temporal 1994-2012 El informe Chaos [Standish 2012] comienza a elaborarse en 1994 (tabulado en la Figura 3.2) y, aunque se observa que la tasa de éxitos ha ido mejorando, pues sólo en el informe de 2006 la tasa de proyectos finalizados con éxito llegó hasta el 35%, mientras que el valor más bajo de proyectos cancelados nunca ha bajado del 18% y llegó al 40% en el informe de 1996. La consultora desglosa estos datos y analiza una serie de factores o causas, que están muy en la línea de los esgrimidos por los autores anteriores [Dijkstra 1972; Sommerville & Kotonya 1998; Greenfield et al. 2004]. Aunque existen autores que discuten los métodos estadísticos y la exactitud de los resultados obtenidos por Standish, como [Moløkken & Jørgensen 2003; Eveleens & Verhoef 2009], la discrepancia suele estar en el segundo grupo de proyectos que tienen desviaciones en plazos y costes, lo que significa que es aceptado que la tasa de proyectos que finalizan con éxito es demasiado pequeña y la de proyectos cancelados sigue siendo considerable. [Ruiz-González & Canfora 2004] identifican al software como un producto con un elevado nivel de complejidad e impredecibilidad. Observan las propiedades de los procesos específicos del software comparándolos con otros tipos de procesos; destacando: i) Los procesos software son complejos debido a que se ven fuertemente condicionados por multitud de circunstancias impredecibles y por muchos equipos de trabajo. Esta característica hace que los procesos software sean completamente diferentes a procesos de producción de otros sectores productivos. ii) Las fases de diseño y producción no están claramente diferenciadas, como sucede en otros procesos industriales. Frecuentemente, surgen nuevos requisitos durante la fase de desarrollo del producto. iii) Es difícil presupuestar y planificar los procesos software con fiabilidad y certeza para garantizar una calidad suficiente del producto. iv) Los procesos software tienen fuertes dependencias de los esquemas organizativos, de los protocolos de comunicación, coordinación y cooperación de equipos de Fuente: The Standish Group International, Inc. https://www.standishgroup.com/ Capítulo 3. Estado del arte Parte II. Antecedentes 70 Tesis doctoral – cam trabajo compuestos por usuarios y personas con diversos roles de distintas compañías. A esto hay que añadir la complejidad que supone manejar escenarios o entornos heterogéneos de desarrollo, con diversas tecnologías y versiones. v) La gestión de los procesos software está en continua y constante evolución debido a que frecuentemente incorpora diferentes ciclos de vida, estándares y buenas prácticas, que manejan distintas versiones de entregables para llegar al producto software definitivo. El desarrollo de software también ha evolucionado según los lenguajes de programación predominantes en cada momento y el nivel de abstracción de dichos lenguajes. i) Primera generación o código máquina. La complejidad de los desarrollos era muy elevada, ya que el bajo nivel del lenguaje obligaba a realizar mucho código para implementar algoritmos y dificultaba la realización de pruebas. ii) Segunda generación o lenguaje ensamblador. Elevan el nivel de abstracción con respecto al código máquina, introduciendo mejoras a nivel cualitativo y productivo. iii) Tercera generación o lenguajes procedurales. Mejoran aún más la productividad pues se acercan más al pensamiento humano, sin embargo, suponen una pérdida de rendimiento. iv) Cuarta generación o lenguajes orientados a objetos. Introducen un mayor nivel de abstracción, manejando clases y sus instancias, y apareciendo términos como la encapsulación, el polimorfismo y la herencia. De nuevo, aumenta la productividad a costa de la eficiencia en ejecución. v) Quinta generación o lenguajes orientados a aspectos [Elrad et al. 2001; Filman et al. 2004; Reina et al. 2004, Soule 2010]. El objetivo principal es la separación de funcionalidades dentro del código de la aplicación «Programación Orientada a Aspectos (AOP)», que conduce a una mejor definición y localización de conceptos. Es más fácil mantener las aplicaciones y el código es más reutilizable [Soule 2010]. Existen todavía discrepancias entre autores sobre el establecimiento de esta categoría, aunque, hoy, supone el mayor nivel de abstracción para la clasificación de lenguajes y el mayor nivel de productividad, aunque el concepto se ha extendido a todo el ciclo del software, acuñándose términos como «Desarrollo del Software Orientado a Aspectos (AOSD), «Análisis Orientado a Aspectos (AOA)» y «Diseño Orientados a Aspectos (AOD)». En paralelo a los avances en la capacidad de los lenguajes ha crecido la complejidad de las plataformas de desarrollo, evolucionando mucho más rápido que los primeros; entre otras, «Java Enterprise Edition» (J2EE) [Rubinger et al. 2014] y «Microsoft .NET Framework» [Millas 2013] están compuestas por miles de clases y métodos con un complejo intrincado de dependencias que pueden provocar efectos secundarios inesperados. Estas plataformas demandan un esfuerzo considerable a los desarrolladores, Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 71 más aún, cuando aparecen en escena nuevas versiones y se consideran proyectos de migración o evolución tecnológica de los sistemas. En estos casos se debe mantener el mismo modelo conceptual del negocio o del dominio del problema, independientemente de la plataforma. Teniendo en cuenta el nivel de abstracción, las cinco categorías anteriores podrían reagruparse en lenguajes de bajo nivel, nivel intermedio y lenguajes de alto nivel. Un aumento del nivel de abstracción genera mejoras en la productividad y reduce el rendimiento de ejecución de las aplicaciones. [Selic 2008] propone dos tipos de complejidad en el desarrollo de software: a) la complejidad esencial, que no se puede evitar y es inherente al dominio del problema, y b) la complejidad arbitraria, que está asociada a los métodos y tecnología empleada. En esta sección se expondrán los dos enfoques: MDE y BPM, que intentan reducir la complejidad arbitraria. 3.1.2 Model-Driven Engineering (MDE) En [Seidewitz 2003] se ofrecen definiciones de los conceptos de Modelo (3.1.) y Meta  Modelo (3.2): Definición. 3.1. Modelo En este sentido, declaración significa algún tipo de expresión que puede ser considerada como verdadera o falsa en el contexto del sistema en estudio. Un modelo es una abstracción del mundo real, que normalmente es un tipo de descripción; su significado tiene dos aspectos: i) la relación del modelo con lo que se está especificando y ii) con otros modelos derivables de él; considerar cuidadosamente ambos aspectos puede ayudar a: i) entender cómo utilizar modelos para razonar acerca de los sistemas que construimos y ii) cómo utilizar Meta  Modelos para diseñar lenguajes que puedan expresar modelos. Una interpretación de un modelo establece una correspondencia entre los elementos del modelo y los elementos del sistema en estudio, de tal manera que se puede determinar el valor de verdad de las declaraciones con cierto nivel de precisión. Un Meta  Modelo contiene declaraciones sobre cómo pueden expresarse modelos válidos en el lenguaje de especificación de los modelos. Existen conceptos relacionados en otros campos, entre otros: Meta-lenguaje 34 [Jakobson 1980] para hablar sobre reglas en los lenguajes, Meta-matemáticas 35 [Hunter 1971] y Meta-teoría [Ritzer 1991; Wallis 34 Bertrand Russell (18721970) establece la teoría de los niveles de los lenguajes, y Alfred Tarski (19021983) diferencia los conceptos lenguaje objeto y Meta-lenguaje. 35 En el campo de la lógica matemática moderna existen contribuciones de autores como Gottfried Leibniz (16461716), Gottlob Frege (18481925), David Hilberth (18621943), Bertrand Russell y Kurt Gödel (19061978), que han «Modelo es un conjunto de declaraciones sobre un sistema en estudio» Capítulo 3. Estado del arte Parte II. Antecedentes 78 Tesis doctoral – cam MDA también observa distintos niveles de abstracción para representar modelos y Meta  Modelos [van der Straeten et al. 2009; Brambilla et al. 2012] que se asocian a plataformas: i) «Platform Specific Meta  Model (PSM)», ii) «Platform Independent Meta  Model (PIM)» y iii) «Computer Independent Meta  Model CIM» y, así, facilitar un alto nivel de interoperabilidad, basada en el concepto MOF. 3.2 Gestión de procesos del software En [Fuggetta 2000] (Definición 1.5.) se define el concepto de «Proceso software». Existen distintos enfoques en materia de propuestas para el apoyo al proceso de software: i) Las primeras aportaciones, aparecidas en los 90’s: a) Basadas en reglas como «Lenguajes de modelación de procesos software (SPMLs)» [Kaiser et al. 1990]. b) Las Redes de Petri [Bandinelli et al. 1993]. c) Y otras, basadas en lenguajes de programación [Conradi et al. 1992; Sutton et al. 1995]. Todos estos lenguajes están enfocados a la ejecutabilidad, de ahí, su formalidad, poca flexibilidad y complejidad, por lo que no han propiciado su adopción en la industria del software. ii) Como alternativa han emergido otras propuestas basadas en buenas prácticas y estándares: a) El estándar para la modelación de procesos BPMN 2.0 [OMG:BPMN 2013; Iso/Iec:19510 2013] debido a su simplicidad y popularidad, así como la posibilidad de ejecutar los procesos modelados [Bonnet et al. 2014]. b) Existen enfoques de diversos autores basados en UML 2.0 [OMG:UML 2011] y en la propuesta «SPEM, Software & Systems Process Engineering Metamodel specification 2.0» [Bendraou et al. 2007; OMG: SPEM 2008] que provee un lenguaje para la especificación de metodologías de desarrollo de software c) Así como la propuesta del estándar «Software Engineering Meta  Model for Development Methodologies» [Iso/Iec:24744 2007, 2014]. 3.3 Gestión de procesos de negocio (BPM) 3.3.1 Conceptos En [van der Aalst 2004; Netjes et al. 2006] se define el concepto «Business Process Management (BPM)» (Definición 1.3) y [Weske 2012] define el concepto de «Proceso de negocio» (Definición 1.1): En «Process Mining Manifesto» [van der Aalst et al. 2012] se definen las distintas perspectivas que caracterizan a la gestión de procesos de negocio: a) Perspectiva de control, b) Perspectiva organizacional o de los recursos, c) Perspectiva del tiempo y d) Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 79 Perspectiva de casos [van der Aalst et al. 2005, 2007]; la perspectiva de control del flujo lógico es la más típica pero no la única, pues también tienen relevancia los aspectos ligados a la estructura de la organización, los recursos, roles, y los flujos de información, así como los aspectos ligados al tiempo (tipos de reglas de negocio temporales) y la especificación de reglas de negocio que pueden ligarse a casos concretos o agrupaciones de estos. En [Reichert & Weber 2012] se consideran las siguientes perspectivas de un sistema basado en procesos: i) Operacional o de servicios de las aplicaciones; ii) Organizacional, para definir unidades de negocio, actores y sus roles; iii) Temporal para definir reglas de tiempo; iv) Funcional, que contempla actividades elementales o agrupaciones de estas en unidades mayores como procesos y subprocesos que tienen capacidad de realizar una acción; v) Comportamiento, asociada a la dinámica del proceso o descripción de flujo de control; y vi) Información, asociada a los objetos de datos y flujos de información. [Reichert & Weber 2012] definen los conceptos de instancia de un proceso y modelo de un proceso (Definición 3.3) como una clase o tipo de instancias de procesos cuyas trazas de ejecución (Definición 3.4) quedan reflejadas en un registro de la actividad o log de eventos del sistema. Definición. 3.3. Instancia de un proceso Definición. 3.4. Traza de ejecución de un proceso 3.3.2 Ciclo de vida BPM En la Figura 3.6. se presenta el Ciclo BPM de mejora continua de van der Aalst [van der Aalst 2004], similar a otros propuestos, p. ej. en [Hill et al. 2006] y [Dumas et al. 2013], donde se contemplan diversas fases en el ciclo de vida de implantación de una solución BPM: i) Diseño, ii) Configuración, iii) Ejecución y iv) Diagnóstico. Sea S un modelo de proceso, entonces una instancia I=(S,  I) queda definida por S y su traza de ejecución  I de S en el log de eventos. Cada traza  I en el log de eventos está relacionada con la ejecución de actividades (inicio y terminación de cada actividad) o la evaluación de condiciones de transición de S relativas a una instancia. Sea S un modelo de proceso e IS el conjunto de todas las instancias de procesos que ejecutan S, entonces: La traza de ejecución  I de la instancia de proceso I  IS viene dada por: I=<e1,,ei ,,en> donde el orden de ei en I refleja el orden temporal en que los eventos relativos a la ejecución de actividades o evaluación de condiciones de transición ocurren en S. El conjunto de todas las trazas que capturan todas las instancias {  I  IS} se denota como el log de ejecución. Capítulo 3. Estado del arte Parte II. Antecedentes 80 Tesis doctoral – cam Figura. 3.6. Ciclo de mejora continuo BPM i) En la fase de Diseño [Ko 2009] se identifican los procesos, se modelan, analizan, simulan y verifican por expertos en el dominio del problema, analistas de negocio y usuarios. Es necesario contar con lenguajes y entornos para la definición formal, simulación y verificación de estos procesos. ii) Las otras fases requieren herramientas para desplegar los procesos y conectarlos con el nivel de aplicación (Configuración) y ejecutar estos procesos en un entorno automatizado, dejando un registro de la actividad (log de actividades) que permitirá monitorizar y diagnosticar la ejecución de estos procesos e iniciar una mejora mediante redefinición o reingeniería de procesos [Hammer & Champy 1993; Mohapatra 2012]. La reingeniería de procesos, como etapa dentro de la fase de Diagnóstico del ciclo de mejora continua, se ha desarrollado en torno a los sistemas automatizados que gestionan procesos (PAIS) (ver sección 3.3.5), apareciendo el campo de «process mining» [van der Aalst et al. 2007, 2012; van der Aalst 2011, 2013, 2014, 2015; Reichert & Weber 2012]. Se distinguen tres tipos de actividades en relación al «process mining» (Figura 3.7) [van der Aalst et al. 2011]: i) Descubrimiento de procesos (discovery), mediante algoritmos, se pueden inferir modelos de procesos analizando un conjunto de trazas del log de eventos; ii) Conformidad (conformance), se compara el modelo de procesos con las trazas existentes para detectar incumplimientos o desviaciones en la ejecución de los Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 81 modelos de procesos; y iii) Mejora (enhancement) del proceso, que compara el modelo con las trazas reales para proponer mejoras a los modelos. Existen herramientas automatizadas, como «ProM» [Verbeek et al. 2011; Kalenkova et al. 2014] para llevar a cabo este proceso a partir del log de eventos [Reichert & Weber 2012] de los sistemas que mantienen este artefacto como reflejo de la actividad de ejecución de los procesos que acontecen en el sistema. Figura. 3.7. Minería de procesos (process mining) 3.3.3 Beneficios del enfoque BPM El enfoque BPM también contribuye a reducir la complejidad arbitraria [Selic 2008], ya que evita que todo lo asociado con la definición, configuración, ejecución y diagnóstico de un proceso dependa del código de las aplicaciones informáticas. Entre el nivel del proceso y el nivel de aplicación existirá solo el puente necesario. BPM aporta beneficios [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014] a las organizaciones que utilizan este enfoque: i) Formalización de procesos. En muchos escenarios los procesos sólo los conocen sus responsables, dificultando su seguimiento por otros actores. BPM obliga a la modelación mediante un lenguaje formal, así se facilita la comunicación y la posibilidad de modificar el proceso. ii) Automatización de procesos. Cada proceso se compone de actividades pertenecientes a un proceso. La duración de las actividades y el flujo de control condicionan la duración del proceso global. La reducción de tiempos muertos entre actividades optimiza la duración del proceso. iii) Incremento de la productividad. En escenarios reales BPM reduce el tiempo de ejecución y disminuye la necesidad de intervención manual, mejorando así la Capítulo 3. Estado del arte Parte II. Antecedentes 82 Tesis doctoral – cam productividad y calidad de los procesos. En [Malinova & Mendling 2013] se realiza un trabajo de campo, entrevistando a expertos BPM de varias compañías. El estudio concluye que las razones para adoptar BPM son tres principalmente: i) comprender y asimilar el conocimiento intrínseco de los procesos de negocio («Know-how» de la organización); ii) conocer el desempeño de sus trabajadores en la ejecución de los procesos; iii) controlar y medir los procesos. Las organizaciones que no contemplan el enfoque BPM están desaprovechando una ventaja competitiva [Havey 2005; Trkman 201; Mohapatra 20120; von Rosing et al. 2014] esencial. Las «TI» no son una excepción, por lo que este enfoque es cada vez más común en este negocio. Por otro lado el enfoque BPM se va proponiendo por distintos organismos como buenas prácticas o estándares: «Project Management Institute (PMI)» con «Project Management Body of Knowledge (PMBOK)» [PMI:PMBOK 2013]; «Stationery Office Books (SOB)» con «PRojects IN Controlled Environments 2 (PRINCE2)» [SOB 2009]; o estándares como «Capability Maturity Model Integration (CMMI)» [Chrissis et al. 2011], en la que define modelos de madurez para la mejora y evaluación de procesos o «Information Technology Infrastructure Library (ITIL)» [ITIL 2015; Iso/Iec 20000:2012; Clifford & van Bon 2008]; y la organización ISO con algunas de sus normas, como por ejemplo la norma «Quality management systems, Requirements» [Iso/Iec 9001:2008] y el estándar BPMN [OMG:BPMN 2013; Iso/Iec:19510 2013]. Ahora bien, conseguir todos los beneficios de implantación de BPM en una «TI» no es tarea fácil por las características intrínsecas de esta tecnología y por la complejidad e impredecibilidad de los procesos [Ruiz-González & Canfora 2004] en el sector del software. 3.3.4 Estándares BPM El organismo «Workflow Management Coalition (WfMC)» define una arquitectura de referencia para los sistemas de gestión de procesos de negocio (Figura 3.8). Diferencia distintos componentes para la gestión del ciclo de vida de los procesos [van der Aalst 2004]: i) Herramientas para la definición de procesos, ii) Herramientas para la activación y control de actividades de los procesos en ejecución, iii) Herramientas para la integración con la capa de aplicaciones y con otros sistemas de ejecución de procesos y iv) Herramientas para la administración y monitorización de los procesos. Entre los distintos componentes se definen interfaces que permiten la portabilidad de artefactos ligados a los procesos que existen en cada nivel. Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 83 Figura. 3.8. Arquitectura de referencia para la gestión de procesos Figura. 3.9. Principales estándares para la gestión de procesos La Figura 3.9 muestra el mapa de estándares para los componentes enumerados. Entre ellos, por el enfoque de la tesis a la especificación de procesos, cabe destacar «Business Process Model and Notation (BPMN )» [OMG:BPMN 2013] para la definición de procesos de negocio, «XML Process Definition Language (XPDL)» [Shapiro 2010; WfMC:XPDL 2012] para el intercambio de metadatos (esquemas e instancias de procesos) y BPEL («Web Services Business Process Execution Language (WS-BPEL)» [OASIS:BPEL 2007], («WS-BPEL Extension for People BPEL4People» Fuente: Workflow Management Coalition http://www.wfmc.org/ Fuente: Workflow Management Coalition http://www.wfmc.org/ Capítulo 3. Estado del arte Parte II. Antecedentes 84 Tesis doctoral – cam [OASIS:BPEL4People 2010]) como estándar para la ejecución de procesos. [Ko et al. 2009] coinciden en la selección de estándares anteriores pero añaden alguno más (Figura 3.10). Así, para la especificación de procesos, considera también los «Diagramas de actividad UML (UML AD) incluidos en el estándar [OMG:UML 2011])» como alternativa a la especificación gráfica, y «Semantics of Business Vocabulary and Rules (SBVR) [OMG:SBVR]» como lenguaje natural declarativo de reglas de negocio. Aunque UML AD tienen mucha similitud con los diagramas BPMN, su capacidad expresiva es inferior a los diagramas BPMN [Eloranta et al. 2006]. En cuanto a los estándares de intercambio de metadatos de procesos, además de XPDL, se considera la propuesta «Business Process definition Meta  Model (BPDM)» [Harmon 2004; OMG:BPDM 2008]; ambas se analizan a continuación. Figura. 3.10. Principales estándares para la gestión de procesos El foco del trabajo de tesis se pone en la especificación de procesos del software. Por esta razón se describen a continuación los estándares BPDM, BPMN y XPDL que otorgan tanto facilidades para la definición como para la portabilidad o interoperabilidad de procesos. 3.3.4.1 Business Process Definition MetaModel (BPDM) OMG propone BPDM [Harmon 2004; OMG:BPDM 2008] como primer Meta  Modelo del mercado para la definición y ejecución de procesos. Dentro de MDA es Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 85 una plataforma de nivel de abstracción PIM que puede involucrar personas o solo sistemas automatizados. El objetivo esencial es la interoperabilidad de procesos (Figura 3.11), ofreciendo capacidades para facilitar el intercambio de procesos entre distintos entornos. Los objetivos específicos buscados son: Figura. 3.11. BPDM i) Unificar la comunicación entre distintos lenguajes de definición de procesos de negocio, tanto de carácter gráfico como de carácter textual. ii) Definir un Meta  Modelo que complemente a UML para ganar consistencia y completitud en la definición de procesos. iii) Usar coreografías en la comunicación entre procesos, favoreciendo la colaboración a través de servicios web. Desde la aparición de BPMN 2.0 (2011), con un robusto Meta  Modelo y creciente popularidad, BPDM ha tenido baja aceptación, ya que pocos fabricantes de BPMS ofrecen facilidades de interoperabilidad de procesos bajo este estándar [Cabot 2010]. Se revisa en el apartado siguiente la contribución de BPMN 2.0 a la definición, ejecución y portabilidad de procesos. 3.3.4.2 Business Process Model and Notation (BPMN) Sobre las notaciones gráficas para la definición de procesos, en [Lu & Sadiq 2007] se concluye que: i) permiten representaciones más simples de la mayoría de los procesos y con mayor abstracción, lo que reduce la complejidad y facilita la verificación; ii) las notaciones textuales, aunque son más precisas y flexibles, requieren un conocimiento técnico que no se puede presuponer a usuarios expertos del dominio. BPMN [OMG:BPMN 2013] es un estándar OMG con una lenguaje gráfico que tiene una elevada cantidad de artefactos para definir procesos de negocio. Los esenciales son: Capítulo 3. Estado del arte Parte II. Antecedentes 86 Tesis doctoral – cam procesos, actividades, compuertas, flujo de control, elementos de información y flujos de información. Existen muchos más que ofrecen características más avanzadas para modelar procesos con distintos tipos de diagramas: coreografías, colaboración y conversaciones. La versión OMG BPMN 2.0.1 es también el estándar [Iso/Iec:19510 2013] y cubre los siguientes aspectos de los procesos [White & Bock 2011]: i) Una notación gráfica para la especificación de procesos, comprensible por usuarios, analistas y expertos en la gestión y monitorización de procesos de negocios. ii) Soporte de la notación con un Meta  Modelo interno capaz de soportar la semántica necesaria para interrelacionar y ejecutar procesos. iii) Formatos de intercambio estándar para la transferencia de procesos e interacción de modelos. «BPMN Model Interchange Working Group (BPMN MIWG)» se encarga de los aspectos de intercambio de modelos BPMN. Se ofrecen capacidades «BPMN Diagram Intechange (BPMN DI)» con ficheros XML para la serialización de procesos: a) Intercambio de esquemas (.xsd format) y b) Metadatos para el intercambio de instancias de procesos (.xmi format [OMG:XMI 2013; Ruiz et al. 2003]). BPMN 2.0 crea un puente entre la definición e implementación de procesos. Desde su aparición ha ido cobrando creciente popularidad en la comunidad científica [Bonnet et al. 2014] como tecnología preferida por la mayoría de expertos en la definición de modelos de procesos, porque ofrece un lenguaje gráfico, sencillo y como un soporte para llegar a especificaciones ejecutables de procesos. BPMN provee con mayor facilidad [Lu & Sadiq 2007] para la intercomunicación entre expertos del negocio (usuarios y consultores) y expertos en TIC. BPMN es principalmente un «lenguaje imperativo»; esto significa que muestra exactamente cómo tiene que ejecutarse el proceso. Por el contrario, un «lenguaje declarativo» solo propone las características esenciales que restringen la ejecución de actividades dentro de un proceso de negocio. De este modo, los enfoques imperativos están más cercanos a la producción, mientras que los enfoques de especificación están más próximos a usuarios y a los expertos en negocio [Fahland 2009a, 2009b; Pichler et al. 2011; Reijers et al. 2013] facilitando la comprensión de la especificación y el mantenimiento de las reglas de negocio. Por otro lado, existen autores que argumentan excesiva complejidad en BPMN 2.0, por el elevado número de artefactos y el coste de instrucción en su empleo a un usuario no experto [Wahl & Sindre 2005; Recker 2010]. Por otro lado en [Zur Muehlen & Recker 2008, 2013; White 2008; Chinosi & Trombetta 2012] se argumenta que, en muchos casos, sólo se emplea una cantidad reducida de artefactos para definir los procesos. [MorenoMontes de Oca et al. 2015] es un estudio sistemático de la literatura cuya conclusión es mejorar la calidad de las distintas perspectivas de los procesos en los modelos reales; en Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 87 [Mendling et al. 2010] se proponen guías para plantear modelos con buena comprensibilidad, entre las que está la utilización de un conjunto reducido de símbolos. 3.3.4.3 Xml Process Definition Language (XPDL) WfMC propone XPDL [Shapiro 2010; WfMC:XPDL 2012] (Figura 3.12) como un ecosistema para facilitar la interoperabilidad de procesos (aspectos de especificación y ejecución) entre distintas herramientas [Hornung et al. 2006]. XPDL ofrece un Meta  Modelo de procesos y un formato de intercambio XML (ficheros que capturan metadatos con XSD y datos). Figura. 3.12. Capas de XPDL 2.2 Desde la versión 2.2 (versión actual) se soportan gran parte de las características de BPMN 2.0, ofreciendo distintas capas de conformidad de la especificación: Simple, Descriptiva, Analítica y Total. Hasta la versión 3.0, en desarrollo, no se cubrirán todos los aspectos de BPMN 2.0 [Shapiro 2010]. Generar formatos de intercambio XPDL da portabilidad a las herramientas que soporten esta facilidad, pero también garantiza la conformidad BPMN 2.0 soportada por el estándar. 3.3.4.4 Evolución histórica La Figura 3.13 muestra la evolución de los principales estándares para la definición y ejecución de procesos [Chinosi & Trombetta 2012] que destaca a los distintos organismos del escenario de estándares de procesos: a) OMG en las propuestas para la Capítulo 3. Estado del arte Parte II. Antecedentes 94 Tesis doctoral – cam día de hoy, NDT cubre y define un conjunto de procesos categorizados en seis grupos: i) Procesos de Desarrollo de Software, basados en el ciclo de vida software que define la propia metodología NDT. ii) Procesos de Mantenimiento de Software, basados en ITIL [ITIL 2015] y los modelos de madurez de CMMI [Chrissis et al. 2011]. iii) Procesos de Pruebas Software, basados en la reciente norma [Iso/Iec 29119:2014]. iv) Procesos de Calidad del Software, basados en la norma [Iso/Iec 9001:2008] y en los modelos de madurez de CMMI [Chrissis et al. 2011]. v) Procesos de Gestión de Proyecto Software, basados en la guía de dirección de proyectos PMBOK [PMI:PMBOK 2013] y en los modelos de madurez de CMMI. vi) Procesos de Seguridad, basados en la norma [Iso/Iec 27000:2014]. Todos estos procesos están definidos formalmente con la herramienta NDTQFramework [Ponce et al. 2013; Aragón 2014] y se han estado aplicando en entornos reales. NDTQ-Framework se sustenta sobre un Meta  Modelo básico de procesos (Figura 3.17) compatible con la norma [Iso/Iec:24744 2007, 2014], la cual proporciona una guía para la descripción de procesos del software. Se contemplan las Meta-clases: i) «Process» que representa un conjunto de acciones ordenadas que deben ser ejecutadas para obtener un determinado objetivo o resultado de negocio; ii) cada una de estas acciones se representa mediante la Meta-clase «Activity» que contempla una asociación recursiva para segmentar la actividad en un conjunto de sub-actividades. Figura. 3.17. Meta  Modelo de procesos NDTQ-Framework Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 95 iii) las clases «Executant» y «Participant» diferencian al responsable de la actividad de otro actor que participa en la actividad; iv) la Meta-clase «Product» representa los productos obtenidos como resultado de ejecutar el proceso; v) la Meta-clase «Metric» se contempla en el Meta  Modelo para definir métricas que permitan medir el desempeño del proceso y la Meta-clase «Indicator» para medir una métrica concreta contra un rango posible de valores «limitedValueTop» y «limitedValueLower» de la Meta-clase «Indicator». NDT se ha utilizado con éxito en diferentes proyectos I+D+i a lo largo de la última década. Entre ellos, se pueden mencionar los siguientes: el proyecto Mosaico llevado a cabo en el seno de la Consejería de Cultura y Deporte de la Junta de Andalucía [Escalona et al. 2008]; el proyecto AQUA-WS [Cutilla et al. 2011] llevado a cabo en EMASESA (Empresa Metropolitana de Abastecimiento y Saneamiento de Aguas de Sevilla S.A.); y más recientemente el proyecto de CALIPSOneo [Escalona et al. 2013; Salido et al. 2014] llevado a cabo de forma conjunta con El Grupo Airbus (http://www.airbusgroup.com). En [García-Borgoñón et al. 2013] se plantea una propuesta de lenguaje de especificación de procesos del software, lo que ha dado lugar al Meta  Modelo InRoma (Figura 3.18), que extiende NDTQ-Framework en el tratamiento de productos, métricas y agentes involucrados en la gestión y ejecución de los procesos del software. Figura. 3.18. Meta  Modelo InRoma Capítulo 3. Estado del arte Parte II. Antecedentes 96 Tesis doctoral – cam 3.5 Modernización de legacy systems 3.5.1 Conceptos y problemas en legacy systems [Bisbal et al. 1997, 1999] identifican la problemática de los legacy systems: i) Algunas organizaciones cuentan con complejos sistemas, compuestos por centenares de miles de líneas de código, con una vida superior a los diez años, pudiendo llegar incluso a los veinte. Estos sistemas suelen representar el corazón del negocio de la organización y no es fácil sustituirlos por un sistema nuevo sin causar un fuerte impacto en la organización. ii) Estos sistemas, creados por diversos equipos de trabajo, sometidos a mantenimiento correctivo y perfectivo a lo largo de años, suelen contar con escasa documentación y de baja calidad. La arquitectura de los sistemas está basada en la tecnología existente en el momento de la concepción, que distará bastante de la tecnología actual. iii) El mantenimiento de estos sistemas se vuelve tedioso y muy costoso. iv) El desconocimiento de interfaces claras con estos sistemas hace muy difícil su integración con nuevos sistemas. v) Es necesario encontrar nuevos enfoques para modernizar estos sistemas, que basándose en tecnología actual, permitan adaptarlos en tiempo y costo aceptables. En [Ulrich 2002; Seacord et al. 2005; Heuvel et al. 2006; Heckel et al. 2008] se analiza el proceso de modernización de legacy systems así como estrategias y procedimientos para llevar a cabo un proyecto con éxito. En [Stavru et al. 2013] se realiza un estudio del estado del arte sobre modernización de legacy systems basada en MDE. Se identifican dos tipos de retos: i) Relacionados con MDD y ii) Relacionados con la modernización del software (SM). A su vez, se establecen dos subcategorías: i) Retos organizacionales (O) y ii) Retos técnicos (T). La Tabla 3.1 sumariza la clasificación de estos retos: Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 97 Tabla. 3.1. Retos de los sistemas legacy systems Cat SC Reto MDD O Ausencia de modelos de procesos Adquisición de competencias y experiencia Reestructuración del equipo de desarrollo Reestructuración de ciclos de vida del software Dependencia de modelos de alto nivel Herramientas inmaduras, ausencia de entornos de desarrollo integrados con la plataforma T Gestión de modelos Transformación de modelos Diseño de los lenguajes de modelación Calidad de los modelos Generación artesanal de código SM O Definición del contexto del negocio Falta de compromiso empresarial Resistencia al cambio Adquisición de competencias y experiencia Riesgo incrementado por nuevas tecnologías Falta de conocimiento detallado de las reglas de negocio T Extracción de conocimiento de negocio y técnico del legacy system Garantizar la equivalencia de comportamiento entre los sistemas de origen y destino Coexistencia del sistema origen y destino Sustituir tecnologías obsoletas (hardware y software) En [Favre 2004] se sientan los fundamentos de la modernización de software dirigida por modelos «Model Driven Software Modernization (MDSM)», basado en el paradigma MDE. Un proceso de modernización de software implica cambios sustanciales en un sistema informático existente (sistema origen); no se trata de un proceso de mantenimiento del software [Pressman 2010]. Las técnicas empleadas son el metamodelado y las transformaciones entre modelos. La reingeniería de un sistema es un tipo de modernización disciplinado, cuyo fin es mejorar la calidad del sistema [Tilley & Smith 1995; Müller et al. 2000], manteniendo el valor estratégico del sistema existente. Un proceso de modernización consta de tres etapas: i) Ingeniería inversa, ii) Reestructuración y iii) Generación o ingeniería directa. i) La ingeniería inversa se inicia con la inyección de modelos a partir de artefactos (como código o un esquema relacional) del sistema origen. ii) La reestructuración consiste en una sucesión de transformaciones modelo-amodelo (M2M) que pueden elevar el nivel de abstracción de cada modelo obtenido en función de la semántica del Meta  Modelo correspondiente. Cuando el nivel de abstracción llega al experto de negocio, éste puede incorporar nuevo conocimiento a los modelos generados, enriqueciendo su valor para la fase de generación. iii) La generación o ingeniería directa es otra cadena de transformaciones M2M que van disminuyendo el nivel de abstracción, pudiendo llegar hasta obtener código final en el sistema destino. Capítulo 3. Estado del arte Parte II. Antecedentes 98 Tesis doctoral – cam Una migración es un caso especial de reingeniería donde sólo se cambia la plataforma tecnológica, manteniendo la funcionalidad del sistema. A continuación se describe la iniciativa OMG ADM para soportar MDSM. 3.5.2 Arquitectura ADM para modernización de sistemas «Architecture Driven Modernization (ADM)» [Newcomb 2005; OMG:ADM 2005; Ulrich & Newcomb 2010] es el estándar propuesto por el OMG para la modernización de legacy systems. Propone un proceso y Meta  Modelos para llevar a cabo esta acción. Los Meta  Modelos son «Abstract Syntax Tree Meta  Model (ASTM)» [OMG:ASTM 2011] y «Knowledge Discovery Model (KDM)» [Iso/Iec 19506:2009]. ASTM se utiliza en las primeras etapas para obtener árboles de sintaxis abstracta, bien con las características gramaticales genéricas «Generic Abstract Syntax Tree Meta  Model (GASTM)» o específicas «Specific Abstract Syntax Tree Meta  Model (SASTM)» del código del legacy system que se inspecciona. Figura. 3.19. Modelo de herradura ADM «Horseshoe Model» El proceso de modernización de legacy systems que propone ADM está caracterizado por un «ciclo en herradura (Horseshoe Model)» (Figura 3.19.), donde se propone un camino ascendente para el proceso de «Ingeniería inversa» [Chikofsky & Cross 1990] y un camino descendente para la «Ingeniería directa». La «Ingeniería inversa» parte de los artefactos del sistema origen (código y esquemas de BD) y aplica transformaciones para ir derivando modelos de mayor nivel de abstracción (PSM, PIM y CIM) en la plataforma que elige el ingeniero de sistemas. A nivel CIM, el experto en negocio cuenta con modelos Parte II. Antecedentes Capítulo 3. Estado del arte Tesis doctoral – cam 99 independientes de la tecnología dónde puede analizar la especificación y puede modificar o añadir nuevos artefactos al modelo (proceso de Reestructuración). La «Ingeniería directa» es el proceso de obtención automática de código desde la especificación de más alto nivel. ASTM se utiliza en las capas o niveles próximos al código (PSM) y KDM para resolver diversas transformaciones entre las capas PSM y las PIM y CIM. Las trayectorias de modernización pueden plantear objetivos de menor o mayor calado en cuanto a su impacto en la organización; así, pueden plantearse: i) «Trayectorias de modernización tecnológica (T)», donde se mantiene la funcionalidad del sistema y se cambian sólo componentes tecnológicos (lenguajes, infraestructura software y hardware). ii) «Trayectorias de modernización de la arquitectura de aplicaciones y datos (A)», donde se reestructuran la capa de persistencia y el código de las aplicaciones para facilitar el mantenimiento y beneficiarse de una arquitectura de datos más moderna pero manteniendo la funcionalidad del sistema. iii) «Trayectorias de modernización de la arquitectura de negocio (B)». Esta es la más ambiciosa, pues afecta a la manera de ver los procesos de negocio e incluso a readaptarlos o reestructurarlos (reingeniería de procesos de negocio [Hammer & Champy 1993; Mohapatra 2012]); obliga a regenerar la arquitectura de datos y aplicaciones y a generar nuevo código para todos los nuevos artefactos o los modificados. 3.6 Resumen y conclusiones En el Capítulo se han revisado tecnologías, estándares, tendencias y buenas prácticas relacionadas con los objetivos del trabajo de tesis. En primer lugar se han planteado las características de los procesos software cuyos problemas inherentes, aunque se detectaron hace ya más de 40 años (crisis del software enunciada por Dijkstra), todavía siguen estando vigentes en muchos proyectos informáticos, llevándolos incluso a su cancelación 36 . Los lenguajes de programación, con el tiempo, han ido elevando su nivel de abstracción, acercándose cada vez más al nivel cognitivo del programador, facilitándole la tarea, evitando o reduciendo algunos errores y, en general aunque aisladamente, mejorando la productividad; pero no es la única solución, puesto que la tecnología, en paralelo, se ha ido complicando con multitud de sistemas operativos, gestores de bases de datos, lenguajes, entornos de desarrollo, etc. Los paradigmas MDE y BPM ofrecen nuevos niveles de abstracción que se acercan al experto para que colabore activamente en la especificación de modelos más cercanos al dominio del negocio. Se han revisado los conceptos MDE, donde el artefacto fundamental es el 36 informe Chaos de la consultora Standish Group Inc [Standish 2012]. Capítulo 3. Estado del arte Parte II. Antecedentes 100 Tesis doctoral – cam Meta  Modelo para soportar distintos niveles de abstracción y plataformas que ayudan a conseguir buenos niveles de interoperabilidad. MDA es la iniciativa del OMG más popular que soporta MDE. Gira en torno al concepto de Meta-Meta  Modelo MOF y la utilización de otros Meta  Modelos, como: UML, CWM, IMM y QVT. BPM también otorga independencia e interoperabilidad cuando se sustenta sobre sistemas automatizados orientados a procesos (PAIS y especialmente BPMS), que independizan la capa de procesos de la capa de aplicación. Se revisa la arquitectura de un BPMS propuesta por el WfMC y los estándares esenciales en gestión de procesos, fundamentalmente para la definición, ejecución y portabilidad o intercambio de procesos, revisando las propuestas de OMG, WfMC y OASIS. Se analizan los principales estándares vinculados al ciclo de vida BPM, donde destacan BPMN, XPDL y BPEL para la definición, intercambio y ejecución de procesos. En el grupo de investigación IWT2, los proyectos y colaboraciones con distintas empresas y organismos se desarrollan bajo el paraguas de la metodología NDT. Se revisan las características de esta metodología y se describe el entorno NDTQ-Framework que soporta NDT, su Meta  Modelo de procesos y un conjunto de herramientas, NDTSuite, que soportan NDTQ-Framework con distintos plugins desarrollados sobre Sparx Systems Enterprise Architect (EA) que implementan distintas transformaciones QVT y reglas de validación. Por último, ya que se van a proponer enfoques de ingeniería inversa desde legacy databases, se detalla la contribución de OMG ADM como arquitectura de modernización de legacy systems, que aporta Meta  Modelos para describir sintaxis abstracta (ASTM: GASTM y SASTM) así como el Meta  Modelo KDM para extraer conocimiento de estos sistemas. ADM promueve distintos caminos de modernización desde un sistema origen a un sistema destino, con un ciclo ascendente inicial de ingeniería inversa, que va incrementando el nivel de abstracción según el camino elegido y un camino descendente o de ingeniería directa que lleva un modelo del sistema origen al sistema destino. Durante todo el proceso, los modelos se describen conforme a Meta  Modelos de referencia y las transformaciones se realizan en QVT utilizando las facilidades MOF. Tesis doctoral – cam 101 Capítulo 4. TRABAJO RELACIONADO “Aquel que duda y no investiga, se torna no sólo infeliz, sino también injusto" Blaise Pascal (1623-1662) n este capítulo se analizará la literatura científica específica de distintos investigadores que desarrollan el estado del arte del Capítulo anterior. Se consideran distintos bloques: i) Publicaciones relacionadas con la definición y verificación de reglas temporales sobre procesos de negocio; ii) Literatura sobre procesos del software; iii) Modernización de legacy systems, que a su vez describe trabajos sobre a) La problemática de los legacy systems y como abordar su tratamiento, b) La ingeniería dirigida por modelos (MDE), c) La arquitectura ADM que el organismo OMG propone para la modernización de legacy systems y d) Ingeniería inversa de bases de datos relacionales. Por último: iv) Se han analizado trabajos sobre otras perspectivas de los procesos, sobre todo, la organizacional y la de casos, ya que sirven como referencia al enfoque de la tesis y permitirán extenderlo en un futuro. 4.1 Introducción La dimensión temporal de los procesos es la base sobre la que se sustentan las propuestas de este trabajo de tesis; con su especificación a distintos niveles de abstracción, van a cobrar sentido transformaciones basadas en MDE que llevarán desde sistemas de bajo nivel a sistemas al nivel de conocimiento del experto de negocio. La bibliografía está llena de trabajos de investigación concernientes a la dimensión temporal sobre procesos de negocio. Hay que distinguir los enfoques que proponen la especificación de esta dimensión en los procesos de negocio de aquellos que van más allá y, basándose en la especificación, proponen métodos para verificar el cumplimiento de las reglas establecidas. Aquí, a su vez, caben dos orientaciones: i) Métodos de verificación que analizan o monitorizan trazas de procesos que ya se han producido y ii) Métodos que son capaces de analizar el proceso en tiempo de ejecución. A continuación se dedica una sección al análisis de bibliografía dedicada a los procesos de gestión del software, contemplando estándares y buenas prácticas. Para la selección de referencias se han tenido en cuenta las recomendaciones que permiten hacer un «Estudio sistemático de la literatura (SLR)» [Kitchenham et al. 2009]. E Capítulo 4. Trabajo relacionado Parte II. Antecedentes 102 Tesis doctoral – cam Utilizar un enfoque de ingeniería inversa MDE sobre legacy systems obliga a revisar aportaciones de la comunidad científica relacionados con: i) Procesos de modernización del software, en particular, los basados en la propuesta OMG ADM, así como otros alternativos que no utilizan ADM; ii) Hay que contemplar trabajos que focalizan en la ingeniería inversa desde bases de datos relacionales, ya que va a ser el primer artefacto de dónde se pretende extraer la dimensión temporal que permitirá ofrecer aproximaciones a los procesos de la organización. La última sección se dedica a trabajos que, de algún modo, contemplan otras dimensiones BPM, como la organizacional o la de casos; hay que tener en cuenta este tipo de contribuciones por la orientación que dan a la captura de esta dimensión y porque estas dimensiones pueden ser utilizadas en ampliaciones o trabajos futuros relacionados con esta tesis. 4.2 Reglas temporales sobre procesos Los trabajos pueden clasificarse en i) Autores que sólo trabajan en la especificación o modelación del tiempo y ii) Autores que además proponen métodos de verificación de reglas temporales sobre procesos. i) En el primer grupo, cabe destacar: a) Quienes utilizan «Time Petri Nets», por ejemplo: [Huai et al. 2010; Makni et al. 2010, 2011]. b) Otros prefieren como herramienta «Timed Automata», tales como [Watahiki et al. 2011; Cheikhrouhou et al. 2014a, 2014b]. c) [Du et al. 2011] proponen «Time Workflow Nets». d) [Kazhamiakin et al. 2006] usan «Web Service Timed State Transition Systems». e) [Kallel et al. 2009] con «XTUS-Automata». f) [Wong & Gibbons 2009] proponen «Communicating Sequential Processes (CSP)». g) [Eder & Tahamtan 2008a, 2008b ] usan «Timed Activity Graphs». h) En [Barba et al. 2012] se propone un enfoque para generar planes que optimizan el tiempo global de ejecución de un proceso en base a una función objetivo que tiene en cuenta modelos declarativos de restricciones temporales sobre procesos. Los planes generados se pueden utilizar para diferentes propósitos: suministrar planes de ejecución para usuarios; facilitar la detección temprana de situaciones críticas y predecir el tiempo de ejecución de actividades. [Barba et al. 2013] realizan una propuesta a los usuarios para minimizar el tiempo de ejecución global de un proceso sobre un PAIS donde exista flexibilidad para este objetivo. Es un enfoque basado en «programación con Parte II. Antecedentes Capítulo 4. Trabajo relacionado Tesis doctoral – cam 103 restricciones (constraint programming)» [Rossi et al. 2006], que considera el flujo de control y la asignación de recursos con capacidad para regenerar nuevos planes de ejecución del proceso. i) En [Gómez-López et al. 2014b] se propone también un enfoque declarativo de reglas basadas en la «programación con restricciones» [Rossi et al. 2006] sobre un proceso. Muchos de los métodos habituales de verificación de reglas están basados en el diagnóstico sobre trazas de procesos en el log de eventos, lo que significa que la regla ya se ha violado. En el trabajo se propone un método para pronosticar en tiempo de ejecución la violación de las reglas declaradas y asegurar que se obtienen trazas robustas en el log de eventos. j) Por último, un grupo de autores coinciden en considerar BPMN como un pilar para desarrollar extensiones temporales, tales como [Gagné & Trudel 2009a; Flores & Sepúlveda 2011; Watahiki et al. 2011; Cheikhrouhou et al. 2013b]. ii) En la segunda categoría, en relación a la verificación de reglas temporales, los investigadores tratan de verificar cuellos de botella, situaciones de abrazo mortal o bucles infinitos, tareas muertas, duraciones mínimas y máximas de procesos y la consistencia temporal entre otros aspectos. Pueden distinguirse las siguientes contribuciones: a) [Watahiki et al. 2011; Du et al. 2011; Cheikhrouhou et al. 2014a, 2014b] trabajan con el entorno integrado «UPPAAL» para llevar a cabo la validación y verificación de sistemas en tiempo real modelados como redes de autómatas temporizados, extendidos con tipos de datos (enteros acotados y arrays entre otros). b) [Eder & Tahamtan 2008a, 2008b ] usan algoritmos. c) [Kazhamiakin et al. 2006; Wong & Gibbons 2009; Huai et al. 2010; Makni et al. 2010, 2011], manejan otras técnicas diferentes a las anteriores. d) [Cheikhrouhou et al. 2013a] es un buen estudio comparativo de la literatura sobre aspectos de especificación y verificación de reglas temporales sobre procesos. En este trabajo de tesis se pone el foco en la especificación de reglas temporales sobre Meta  Modelos de procesos, pues se va a proponer un enfoque MDE basado en la perspectiva temporal BPM para extraer modelos de procesos de legacy systems; por esta razón se discutirán con más detalle las propuestas relacionadas con la expresión de reglas de tiempo sobre el estándar BPMN, donde todos los autores identifican cierta debilidad de BPMN para especificar algunos tipos de reglas temporales. [Flores & Sepúlveda 2011] trabajan sobre BPMN 1.2. Parten de las restricciones de tiempo utilizadas en Diagramas de Gantt [Gantt 1919; PMI:PMBOK 2013] y PERT [Malcolm et al. 1959; PMI:PMBOK 2013] para la planificación y control de proyectos con MS Project [Hansen & Hansen 2013; Stover 2007]. Proponen usar patrones o construcciones BPMN para modelar cada clase de restricción de tiempo sobre una Capítulo 4. Trabajo relacionado Parte II. Antecedentes 110 Tesis doctoral – cam et al. 2012] usan plantillas lingüísticas o patrones [Gamma et al. 1995; Tran et al. 2007] para definir textualmente PPIs, introduciendo la notación y el Meta  Modelo PPINOT. En [Del Rio Ortega et al. 2013b] se propone el análisis de PPIs utilizando el Meta  Modelo PPINOT. [Del Rio Ortega et al. 2013a], ya citado en el párrafo anterior, es un trabajo donde se asocian PPIs a la perspectiva de recursos de los procesos de negocio y se especifican los PPIs a partir del archivo de log generado durante la ejecución del BPMS de código abierto Activiti 38 [Rademakers 2012]. En [Cruz et al. 2014] se aplica la notación PPINOT a un proceso de negocio definido sobre el servidor de correo corporativo de la Universidad de Sevilla. 4.6 Minería de procesos La minería de procesos («process mining») intenta descubrir, monitorizar y mejorar los procesos existentes mediante la extracción de conocimiento de los diarios de eventos (event logs) de los sistemas de información. En [van der Aalst et al. 2005] se resalta la relevancia de la perspectiva de casos de los procesos para sustentar nuevos enfoques para realizar «process mining». En [van der Aalst et al. 2007, 2012; van der Aalst 2011, 2013, 2014] se desarrolla este enfoque y se proponen distintos algoritmos para descubrir y verificar modelos de procesos desde el log de eventos cuya existencia es habitual en los BPMS [Dumas et al. 2013]. El algoritmo básico, α-algorithm [van der Aalst 2011], rastrea el log de eventos, buscando patrones de flujo de control (ejecución en paralelo, secuencial; puertas inclusivas, exclusivas, etc.) sobre múltiples instancias que puedan llevar a un modelo genérico del proceso. Para procesos complejos y logs de gran tamaño se emplean algoritmos que particionan el log y utilizan lógica inductiva para resolver el descubrimiento de procesos con mayor eficiencia [van der Aalst 2013]. Existen distintos sistemas que realizan «process mining», como: i) Los sistemas comerciales [van der Aalst 2015] Disco (Fluxicon), Perceptive Process Mining (Perceptive Software, before Futura Reflect and BPMone by Pallas Athena), ARIS Process Performance Manager (Software AG), Celonis Process Mining (Celonis GmbH), ProcessAnalyzer (QPR), Interstage Process Discovery (Fujitsu), Discovery Analyst (StereoLOGIC), and XMAnalyzer (XMPro). ii) El sistema de código abierto ProM 39 que trabaja con el estándar XES para log de eventos [Verbeek et al. 2011; Kalenkova et al. 2014; van der Aalst 2015]. Ahora bien, no todos los sistemas orientados a procesos (PAIS) [Dumas et al. 2005] 38 http://activiti.org/ 39 http://www.promtools.org/doku.php Parte II. Antecedentes Capítulo 4. Trabajo relacionado Tesis doctoral – cam 111 cuentan con logs de eventos disponibles para «process mining», aunque sí mantienen diarios de la actividad en el sistema. Esto lo han aprovechado autores como: i) [Ingvaldsen &Gulla 2008] que trabajan con el ERP SAP para construir un log de eventos desde los diarios de transacciones de datos. ii) [Günther & van der Aalst 2007] proveen un framework genérico para obtener un log de eventos desde distintos tipos de PAIS. Existen autores como [Pérez-Castillo et al. 2009, 2011a] que trabajan sobre sistemas no orientados a procesos para obtener modelos de procesos. Definen el framework (Modernization Approach for Recovering Business processes from Legacy Systems «MARBLE»), basado en mejoras de ADM para extraer una base de procesos de negocio dentro de su concepto de «Arqueología de Procesos de Negocio». Utilizan el camino de ingeniería inversa ADM para llegar a propuestas de modelos de procesos basados en BPMN. En [Pérez-Castillo et al. 2012a] se aplica MARBLE a una familia de casos. Por último [van der Aalst & Nikolov 2007; van der Aalst 2015] son otros ejemplos de tentativas que parten de sistemas origen no orientados a procesos: i) [van der Aalst & Nikolov 2007] es un trabajo que describe EMailAnalyzer, que es un plugin para extraer trazas de procesos de una corriente de correos electrónicos con objeto de alimentar al framework ProM. Los autores establecen como hipótesis que los correos originarios estén generados por un sistema automatizado, de modo que contengan datos que permiten clasificarlos (es posible asociarlos a una tarea codificada). De este modo, un conjunto de correos son reutilizados para reconstruir un log de eventos que se utiliza en ProM. ii) En [van der Aalst 2015] se propone un enfoque que establece una base conceptual para sistemas de información genéricos que se construyen sobre una base de datos. La base de datos del sistema refleja el estado actual de un conjunto de procesos, mientras que los cambios en la misma se producen mediante eventos. El autor propone modelos de objetos para representar procesos, modelos de clases para representar modelos de procesos y un modelo de eventos para representar las modificaciones a la base de datos. Sobre esta conceptualización se propone un método para generar un log de eventos que puede alimentar a los métodos genéricos de «process mining». El autor concluye que es necesario sustentar este enfoque sobre gestores de bases de datos específicos. 4.7 Resumen y conclusiones En este Capítulo se ha revisado la literatura relacionada con los objetivos de la tesis. El foco del trabajo de investigación es la dimensión temporal de los procesos. En primer lugar se han analizado los lenguajes para la especificación y verificación de reglas temporales sobre procesos. A continuación se han extraído un conjunto de referencias Capítulo 4. Trabajo relacionado Parte II. Antecedentes 112 Tesis doctoral – cam relevantes en torno a lenguajes, estándares y buenas prácticas para la definición de procesos ligados al software, resaltando las que utilizan Meta  Modelos. El proceso de modernización del software comprende el tratamiento de legacy systems, los cuales no son fáciles de mantener ni de sustituir. La mayoría de los métodos, actualmente, están basados en el paradigma MDE y contemplan caminos de modernización como: i) La ingeniería inversa que va de niveles bajos de abstracción que empiezan con las plataformas tecnológicas origen del proceso: código y bases de datos, y ii) Ingeniería directa, que permite transformar modelos de alto nivel de abstracción en modelos de menor nivel, hasta llegar al código del nuevo sistema destino. Una posición destacada en este proceso de modernización está ocupada por OMG ADM y distintas contribuciones que han extendido este estándar. Las legacy databases van a ser el foco de este trabajo de investigación; por esta razón se han revisado un conjunto de trabajos que realizan ingeniería inversa desde esquemas de bases de datos relacionales. Se han analizado también trabajos relacionados con conceptos como la arqueología de procesos y «process mining». Los procesos de ingeniería inversa de legacy databases suelen capturar entidades y algunas reglas de negocio de carácter estructural, siendo más difícil derivar reglas que estén implementadas como algoritmos más complejos en el código de las aplicaciones. Por otro lado, la minería de procesos lleva a derivar modelos de procesos basándose en heurísticas que analizan múltiples instancias de éstos. Estos modelos de procesos presentan sólo la perspectiva de control del flujo. El enfoque que se va a desarrollar para derivar procesos propone buscar otras perspectivas de los procesos en las legacy databases, poniendo inicialmente el foco en la perspectiva temporal mediante el estudio específico de legacy systems de uso frecuente en el sector TI y su caracterización de la dimensión temporal. Aunque la perspectiva temporal sea el foco principal de la investigación, se han seleccionado un conjunto de trabajos que tratan otras dimensiones de los procesos, como la organizacional y la de casos, porque podrían enriquecer los procesos obtenidos en trabajos futuros. Tesis doctoral – cam 113 Capítulo 5. LEGACY SYSTEMS EN EL SECTOR DE LAS TI "Es de importancia para quien desee alcanzar una certeza en su investigación, el saber dudar a tiempo” Aristóteles (384-322 A.C.) as «organizaciones del software (TI)» usan distintos tipos de legacy systems que, habitualmente, no están diseñados teniendo en cuenta el enfoque BPM (no son PAIS), aunque, de un modo u otro, contienen artefactos en su legacy database (estructuras de datos y reglas) que representan estados de ejecución relacionados con las distintas perspectivas de los procesos que han sucedido en la organización. Se han seleccionado un grupo de legacy systems, habituales en las «TI», para extraer sus esquemas (legacy databases, ver Anexo II) y realizar un estudio comparativo del soporte de cada una de las perspectivas de los procesos, en particular, de la dimensión temporal. Las conclusiones del análisis servirán para seleccionar los sistemas candidatos a ser utilizados en el enfoque de ingeniería inversa MDE propuesto en la tesis, que transformará artefactos de legacy databases en procesos definidos con lenguajes cercanos al experto en software. 5.1 Sistemas de gestión en organizaciones orientadas al software Cualquier organización dedicada al negocio del software ha utilizado sistemas de información para apoyar el desarrollo de su actividad. Así es común que, entre sus actividades realice planificación y control de sus proyectos; Esto implica estructurar y ordenar las actividades del proyecto, prever fechas de inicio y terminación, estimar duraciones, así como hacer un seguimiento de la ejecución de esas actividades para medir las desviaciones y ajustar y acordar la planificación con los actores implicados. Por otro lado, esa planificación también puede incluir la asignación de recursos (humanos, económicos, etc.), grupos de recursos, etc. La generación, recepción, aprobación, control de versiones y envío de documentos es también un conjunto de tareas muy comunes. Tampoco hay que olvidar que una organización orientada al software, como cualquier otra, necesita sistemas de gestión horizontales (no específicos del software) para llevar a cabo sus relaciones con proveedores, bancos, clientes y empleados, además de las obligaciones contables y fiscales. Desde la década de los 90’s ha crecido una tendencia a L Capítulo 5. Legacy systems en el sector de las TI Parte II. Antecedentes 114 Tesis doctoral – cam utilizar aplicaciones de mercado (fabricadas por distintos niveles de proveedores especializados en software estándar) para adaptarlas a las necesidades de cada organización. En diversos puntos de esta memoria de tesis, se ha comentado la tendencia de los últimos años a utilizar enfoques BPM como ventaja competitiva. Según su ciclo de vida [van der Aalst 2004; Hill et al. 2006; Dumas et al. 2013], utilizar esta tecnología implica comenzar por identificar y definir sus procesos de negocio que habrán de integrarse con los sistemas existentes. Cabe en este momento preguntarse si el experto de negocio debe partir de cero para hacer esta definición mediante un proceso manual o bien puede recabar automáticamente características de estos procesos de los sistemas existentes. En este trabajo de tesis se ha desarrollado el estudio de la dimensión temporal de los procesos y se pretende utilizar la misma para extraerla de determinados tipos de sistemas mediante un enfoque de ingeniería inversa MDE. Se han analizado sistemas de información de amplia cobertura en el mercado y utilizados por las organizaciones del software, llevando a cabo las siguientes tareas: i) Análisis de documentación de productos. ii) Instalación del software o búsqueda de esquemas XSD. iii) Importación de esquemas (ODBC o XSD) a Enterprise Architect (EA) [Sparx:EA 2015]. iv) Extracción de vistas con reglas temporales sobre actividades que soporta cada producto (Ver Anexo II). 5.1.1 Sistemas de planificación y control de proyectos Estos sistemas permiten crear proyectos, compuestos por actividades y subproyectos. Los proyectos constan de un conjunto de tareas que pueden planificarse, asignándole gran parte de las reglas temporales que se han estudiado en la taxonomía de reglas (Figura 6.1), como restricciones sobre tareas o bien como dependencias temporales entre las mismas basadas en «Álgebra de intervalos de Allen» [Allen 1983]. También facilitan la medición del grado de avance o terminación de cada tarea, el establecimiento de líneas de base para realizar comparaciones, la definición de recursos, grupos de recursos y la asignación de tareas a recursos. En cualquier momento de un proyecto activo, pueden realizarse planificaciones o re-planificaciones del proyecto que tienen en cuenta las actividades finalizadas, las activas, las no iniciadas y el nivel de asignación de recursos, tipo de restricciones o dependencias, etc., aplicándose para el cálculo de duraciones flexibles o fechas de terminación flexibles el método «Critical Path Method (CPM)» [Kelley & Walker 1959]. Los sistemas más sencillos son herramientas unipersonales, como MS Project [Hansen & Hansen 2013] (Anexo II.a), pero en organizaciones más complejas es necesario contar con sistemas colaborativos, soportados por BD relacionales y tecnología web, como MS Project Server [Stover 2007] (Anexo II.b) que permite la integración de Parte II. Antecedentes Capítulo 5. Legacy systems en el sector de las TI Tesis doctoral – cam 115 MS Project sobre un SGBD SQL*Server™ [Colledge 2008; Ben-Gan 2012; Microsoft™:T-SQL 2014] y RedMine™ [Lang 2010] (Anexo II.d), sobre mySQL™ [Harrison & Feuerstein 2008] y servidores web Apache™ y Tomcat™. Redmine también facilita la gestión de peticiones de usuarios o incidencias (se usa comúnmente en Centros de Atención a Usuarios). Estos sistemas tratan la dimensión temporal y la dimensión organizacional (recursos) que son ejes fundamentales planteados en el «Process Mining Manifesto» [van der Aalst et al. 2012]. De hecho, existen trabajos, como [Flores & Sepúlveda 2011; Gagné & Trudel 2009b], que tratan de establecer equivalencias entre la representación de tareas en estos sistemas y el mundo de los procesos de negocio. En los Anexos II.a, II.b y II.d se han extraído vistas ERD de las bases de datos de cada sistema, buscando las entidades relacionadas con los procesos, tareas y la especificación de la dimensión temporal. 5.1.2 Sistemas de gestión documental (ECMs) Los sistemas de gestión documental o gestores de contenido «Enterprise Content Management Systems (ECMs)» suelen configurarse como un entorno colaborativo, hoy basado en tecnología Web y en potentes bases de datos relacionales o documentales que permiten expresar la vista organizacional y gestionar la publicación, intercambio, aprobación y gestión de versiones de documentos. Suelen integrar un cierto nivel de gestión simplificada de flujos de trabajo «Workflows» o bien la integración con gestores de procesos. Luego, sin duda, también incluyen comportamiento común con la perspectiva del tiempo y organizacional BPM. A esta categoría de sistemas pertenecen «Alfresco™» [Shariff 2013] o «MS Sharepoint™» [Smith & Bates 2007]. Alfresco utiliza como SGBD PostgreSQL™ y MS Sharepoint SQL*Server™ [Colledge 2008; Ben-Gan 2012; Microsoft™:T-SQL 2014]. Se ha extraído una vista ERD del esquema relacional de Alfresco (ver Anexo II.c). Alfresco maneja una serie de workflows predefinidos (secuencial, paralelo) para los circuitos de aprobación de documentos, pero permite la integración con Activity para diseñar flujos más complejos. 5.1.3 ERPs, CRMs, SCMs y desarrollos a medida Estos sistemas [Hendricks et al. 2007] integran diversos módulos o aplicaciones para la gestión del negocio en un núcleo estándar, sobre el que se superponen capas para localizaciones nacionales con los aspectos normativos o legales de cada país. También suelen incluir facilidades para parametrizar y/o adaptar sus interfaces o generar código que se integre en el estándar. De este modo pueden llegar a satisfacer gran parte de los requisitos de las organizaciones y hacen más fácil la expansión a otras líneas de negocio y/o geográfica. Los ERPs suelen contar con módulos contables, de recursos humanos, almacenes, compras, ventas, gestión de la producción, etc. Los CRMs son módulos especializados en la gestión de relaciones con clientes (Marketing, fichas de clientes, ofertas, contratos, ventas, facturación, cobro y gestión de incidencias). Los SCMs Capítulo 5. Legacy systems en el sector de las TI Parte II. Antecedentes 116 Tesis doctoral – cam involucran todos los procesos logísticos, internos o vinculados a colaboradores externos para gestionar la cadena de suministro. Aunque cada vez es menos común, no hay que olvidar el desarrollo de aplicaciones específicas a medida del cliente, en casos en que las adaptaciones del software estándar son muy costosas, o no existe funcionalidad suficiente en el estándar, o bien en nuevas líneas de negocio que no están suficientemente bien abordadas por esos paquetes. Aunque estos sistemas no tengan modelos de procesos transparentes a usuarios y expertos de negocio, se pueden encontrar dimensiones BPM en la capa de persistencia de cada uno. Ahora bien, al igual que en casos anteriores, sería necesario extraer las vistas de estos procesos vinculadas a la dimensión BPM que se pretenda contrastar. 5.2 Perspectivas de procesos vs legacy systems Tras el estudio de los diversos tipos de sistemas utilizados por las organizaciones del software, se observa que cada tipo de sistema soporta en mayor o menor medida las perspectivas BPM: temporal, organizacional y casos; se excluyen otras perspectivas, como la de flujo de control, información y operacional que suelen ser específicas de los PAIS [Dumas et al. 2005]. La Tabla 5.1 puede ilustrar la existencia de estructuras que soportan reglas de negocio asociadas a cada perspectiva BPM según el tipo de legacy system: Tabla. 5.1. Perspectivas BPM soportadas por tipo de legacy system Tipo de legacy system Perspectiva BPM Tiempo Organizacional (Recursos, información) Casos i) Sistemas de planificación y control de proyectos p. ej.: MS Project, RedMine ▲ ∆ ⦸ ii) Enterprise Content Management Systems (ECMs) p. ej. Alfresco, SharePoint ∆ ▲ ∆ iii) ERPs, CRMs, SCMs (workflows de sus procesos) ∆ ∆ ∆ iv) Desarrollos a medida ∆ ∆ ∆ ▲Bien soportado, ∆ Soportado con limitaciones, ⦸ No soportado. i) Los sistemas de planificación de proyectos suelen recoger bien la dimensión temporal y una aproximación al tratamiento de la vista organizacional con recursos y grupos de recursos, pero no están enfocados para establecer jerarquías, departamentos, empresas, holdings, etc. La especificación de reglas para casos es manual. ii) Los ECMs suelen manejar bien la perspectiva organizacional y contienen algunas reglas temporales básicas, así como la agrupación y parametrización del tratamiento de casos que obedecen a patrones de gestión, pero bajo una Parte II. Antecedentes Capítulo 5. Legacy systems en el sector de las TI Tesis doctoral – cam 117 especificación muy simple de reglas. iii) El grupo de ERPs, CRMs, SCMs soportan reglas temporales (vencimientos, fechas tope o límite), facilitan la definición de la estructura organizacional (con modelos robustos que permiten definir holdings, empresas, departamentos, roles, responsabilidades, etc.) y también el tratamiento de casos mediante reglas de parametrización. Los modelos de datos de los sistemas de mayor alcance internacional son excesivamente complejos. iv) Los desarrollos a medida pueden soportar cualquier perspectiva, pero normalmente los analistas enfocan más los modelos a la funcionalidad que a tratar de manera estándar las distintas perspectivas BPM de un proceso. El otro inconveniente importante estriba en el nivel de actualización de la documentación para poder extraer artefactos ligados a los modelos de procesos. 5.3 Dimensión temporal en un legacy system En relación al análisis específico de la dimensión temporal, las Tablas 5.2 y 5.3 muestran la comparación de estos sistemas respecto a la taxonomía de reglas (Figura 6.1). Tabla. 5.2. Reglas temporales soportadas por tipo de legacy system Tipo de regla temporal Tipo de legacy system Duración Cardinalidad Ausencia Inflexible Flexible FIXD FLEXD CARD ABS-U ABS-C MSON MFON FALAP FASAP FNET FNLT SALAP SASAP SNET SNLT i) Sistemas de planificación y control de proyectos p. ej.: MS Project, RedMine ▲ ∆ ⦸ ⦸ ⦸ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲ ii) Enterprise Content Management Systems (ECMs) p. ej. Alfresco, SharePoint ▲ ∆ ⦸ ⦸ ⦸ ▲ ▲ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ iii) ERPs, CRMs, SCMs (workflows de sus procesos) ▲ ∆ ⦸ ⦸ ⦸ ▲ ▲ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ ⦸ ▲Bien soportado, ∆ Soportado con limitaciones, ⦸ No soportado. Los sistemas de planificación y control son los que mejor soportan la dimensión temporal, mientras que el resto de los sistemas soportan mejor otras perspectivas (Tabla 6.1). Por esta razón son los primeros en ser elegidos para aplicar un enfoque de ingeniería inversa MDE que extraiga modelos de procesos, aunque, posteriormente pueden utilizarse otros sistemas y añadir también otras perspectivas que enriquezcan los resultados. Capítulo 5. Legacy systems en el sector de las TI Parte II. Antecedentes 118 Tesis doctoral – cam Tipo de legacy system Dependencia Temporal FF FS SF SS ABS-U ABS-C i) Sistemas de planificación y control de proyectos p. ej.: MS Project, RedMine ▲ ▲ ▲ ▲ ⦸ ⦸ ii) Enterprise Content Management Systems (ECMs) p. ej. Alfresco, SharePoint ⦸ ▲ ⦸ ▲ ⦸ ⦸ iii) ERPs, CRMs, SCMs (workflows de sus procesos) ⦸ ▲ ⦸ ▲ ⦸ ⦸ ▲Bien soportado, ∆ Soportado con limitaciones, ⦸ No soportado. 5.4 Resumen y conclusiones En este Capítulo se han analizado diversos tipos de legacy systems habituales en las «TI»: planificación y control de proyectos, gestores documentales o de contenido (ECMs), ERPs, CRMs, SCMs y, por último, desarrollos a medida. Se ha estudiado en primer lugar el soporte de las distintas perspectivas de los procesos; en segundo lugar, utilizando la taxonomía de reglas (Figura 6.1), se han contrastado los tipos de reglas que soportan estos legacy systems. La conclusión es que los legacy systems que mejor soportan la perspectiva temporal son los sistemas para la planificación y control de proyectos (p. ej.: MS Project o Redmine) y, en segundo lugar, los ECMs. Este resultado, el extendido uso en el mercado y nuestra experiencia en proyectos invita a seleccionar en primer lugar MS Project como legacy system para aplicar el enfoque de ingeniería inversa MDE que se desarrolla en el trabajo de tesis. Tabla. 5.3. Dependencias temporales soportadas por tipo de legacy system PARTE III. SOLUCIÓN PROPUESTA Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 126 Tesis doctoral – cam iv) Restricción de cardinalidad. Limita el número de iteraciones de una actividad en bucle en relación a su duración. Si N es el número de veces que una actividad A{Ai} se ejecuta, siendo {Ai} el conjunto de instancias de ejecución de la actividad A. Se restringe el tamaño del bucle que puede ejecutarse según la expresión 6.4: Expresión. 6.4. Restricción temporal de cardinalidad v) Restricción de ausencia. Establece que una actividad no puede ser ejecutada, lo que significa que se evita la ejecución de dicha actividad, bien en permanentemente (incondicional: ABS-U; Expresión 6.5a) o bien habilitando su ejecución sólo fuera de un intervalo de tiempo [t1, t2] (condicionada: ABS-C; Expresión 6.5b), lo que equivale a saltar o pasar por alto la ejecución de dicha actividad dentro de dicho intervalo: Expresión. 6.5. Restricción de ausencia de una actividad 6.2.2 Dependencias temporales Las dependencias temporales suponen relaciones de precedencia entre una actividad predecesora y una actividad sucesora, especificándose el tipo de relación; así: i) Dependencia de ausencia. Establece que la actividad sucesora no puede ser ejecutada si la predecesora está activa o ha sido ejecutada. Al igual que en la ausencia ligada a una actividad del bloque anterior, esta restricción puede ser permanente, o bien ligada a un intervalo de tiempo [t1, t2] donde la sucesora puede tomar control para realizar su trabajo y fuera de este intervalo está desactivada. Figura. 6.3. Dependencia de ausencia entre actividades Si P y S son dos actividades, P la predecesora y S la sucesora (Figura 6.3 y Expresión 6.6), las dependencias (incondicional: ABS-U; Expresión 6.6a) y (condicionada: ABS-C; Expresión 6.6b) expresan dependencias de ausencia para S:     1 1 ( ) ( ) ( ) ( ) ( ) min ( ) ( ) ( ) max ( ) N ii i N ii i e A s A dur A e A s A Dur A e A s A Dur A               12 ( ): is in Absence ( ): [ , ] is in Absence a t A b t t t A     S P S ABS-U P ABS-C [t1,t2] (a) (b) Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 127 Expresión. 6.6. Dependencia de ausencia entre actividades ii) Start to Start (SS), Start to Finish (SF), Finish to Start (FS) y Finish to Finish (FF). Son dependencias temporales del «Álgebra de intervalos de Allen» [Allen 1983], estableciendo restricciones entre los eventos de inicio y terminación de la actividad sucesora (S) y sus predecesoras (P) (Figuras 6.4a, b, c y d), teniendo en cuenta un lapso de tiempo ∆t que puede significar un adelanto (∆t<0) o retraso (∆t>0) entre los eventos implicados (Expresiones 6.7a, b, c y d). Figura. 6.4. Dependencias temporales SS, SF, FS, FF Expresión. 6.7. Dependencias temporales SS, SF, FS, FF 6.3 Enfoques para la extensión de BPMN 2.0 con reglas temporales Aunque BPMN 2.0 contempla la perspectiva temporal, diversos autores (ver Capítulo 4) coinciden en que este estándar muestra algunas debilidades para contemplar determinadas reglas (taxonomía de la Figura 6.1) temporales. A continuación se plantea una sección que revisa capacidades y limitaciones del estándar respecto a esta perspectiva y, en las siguientes, se analizan dos alternativas que proponen enfoques para dotarlo con mayor capacidad expresiva, basados en la utilización de nuevos decoradores que ofrecen semántica adicional y mediante patrones o construcciones [Gamma et al. 1995; Tran et al. 2007] a base de artefactos BPMN. 6.3.1 Capacidades y limitaciones de BPMN 2.0 para representar la perspectiva temporal BPMN 2.0 permite definir la dimensión temporal. En este sentido, un proceso está compuesto de artefactos, donde la actividad es el principal de ellos, representando un estado y un trabajo a realizar en un tiempo finito. Existen flujos de control, flujos de información y eventos que dependen del espacio temporal, induciendo órdenes o relaciones de precedencia entre artefactos (actividades, objetos o almacenes de datos, etc.). Muchos investigadores están de acuerdo en que, a pesar de estas capacidades,             12 ( ) : ( ) ( ) is in Absence ( ) : [ , ] ( ) ( ) is in Absence a ABS U t s P null e S null A b ABS C t t t s P null e S null A                P S SS ∆t P S (a) (b) P S P S (c) (d) SF ∆t FS ∆t FF ∆t ( ) : ( ) ( ) ( ) : ( ) ( ) ( ) : ( ) ( ) ( ) : ( ) ( ) a SS s S s P t b SF e S s P t c FS s S e P t d FF e S e P t             Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 128 Tesis doctoral – cam BPMN manifiesta ciertas debilidades para expresar la dimensión temporal (ver Capítulo 4). Es importante hacer notar que BPMN no soporta todas las clases de reglas temporales incluidas en la taxonomía de reglas (Figura 6.1). En lo concerniente al análisis del ciclo de vida de una actividad en BPMN, la Figura 6.5 muestra una máquina de estados UML [OMG:UML 2011] simplificada y extraída de la versión original incluida en el estándar [OMG:BPMN 2013]. En [Weske 2012] se profundiza en el análisis de este ciclo de vida, contemplando más estados y transacciones que no están en el ciclo contemplado en BPMN; así, aparecen: a) “Desactivada” y las transiciones correspondientes con el estado “Lista”, b) “Suspendida” y transiciones entre el estado “Activa” y c) “Ignorada” para no ejecutar la actividad cuando le llega el token del flujo de control, evitando la ejecución sin hacer el trabajo correspondiente. Figura. 6.5. Ciclo de vida de una actividad BPMN En [Svatos 2012] se muestra que los lenguajes de modelación de procesos contemporáneos, entre los que se incluye BPMN, sólo cubren parcialmente el ciclo de vida general de una actividad perteneciente a un proceso de negocio. Esta podría ser una de las razones principales de la debilidad del estándar a la hora de especificar el tiempo. Otra razón de peso es que las relaciones de precedencia que se consideran en el «Álgebra de intervalos de Allen» [Allen 1983] tampoco están soportadas directamente. Además, tampoco existen mecanismos simples para capturar el evento de comienzo de la actividad y controlar el trabajo a realizar después del mismo. No obstante, BPMN 2.0 introduce el concepto de «eventos sin-interrupción (non-interrupting-events)» ligados a actividades, stm BPMN activity lifecycle Inactive Ready Completed Closed Active Failed CompensatedTerminated [End process] [Non-error interrupting event] [Interrupting event] [End process] [End process] [Compensation event] [Interrupting event Cancel | Error] [Data input available] [End process] [Work completed] [Token arrives] Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 129 que permiten modelar nuevos flujos de control que parten de la actividad mientras aún está activa, ayudando así a diseñar nuevos patrones [Gamma et al. 1995; Tran et al. 2007] o construcciones. El estándar BPMN [OMG:BPMN 2013; Iso/Iec:19510 2013] se ha convertido en los últimos años en una de las tecnologías preferida por la mayoría de expertos [Bonnet et al. 2014] para la definición de modelos de procesos, porque ofrece un lenguaje sencillo y como un soporte para llegar a especificaciones ejecutables de procesos. La notación gráfica [Lu & Sadiq 2007] de BPMN otorga a los expertos del dominio (consultores y usuarios finales) mayor facilidad para la intercomunicación con expertos en TIC. BPMN es principalmente un «lenguaje imperativo», mientras que los «lenguajes declarativos», como SBVR y OCL, solo proponen las características esenciales que restringen la ejecución de actividades dentro de un proceso de negocio, facilitando la comprensión de la especificación y el mantenimiento de las reglas de negocio [Fahland 2009a, 2009b; Pichler et al. 2011; Reijers et al. 2013]. Por estas razones, desde el punto de vista de la especificación de reglas, creemos que es mejor superponer una especificación de reglas de tiempo que utilizar patrones [Gamma et al. 1995; Tran et al. 2007] o construcciones BPMN para expresar estas reglas como agrupaciones de artefactos, ya que esta orientación puede sobrecargar en exceso los modelos y/o hacerlos muy dependientes y difícil de mantener ante cambios en las reglas. A continuación se dedican dos secciones a comparar estos enfoques. 6.3.2 Extensiones a BPMN mediante decoradores Los trabajos Time-BPMN de [Gagné & Trudel 2009a] y los de [Cheikhrouhou et al. 2013b] proponen nuevos decoradores para plasmar sobre BPMN 2.0 la semántica de reglas temporales que no soporta directamente el estándar. La segunda propuesta es un poco más completa, al contemplar duración flexible, restricciones de cardinalidad y las de ausencia sobre una actividad o en dependencias entre actividades. La Tabla 6.2 ilustra la aplicación de estos decoradores y compara las dos propuestas: Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 130 Tesis doctoral – cam Tabla. 6.2. Extensión temporal a BPMN 2.0 mediante nuevos decoradores Tipo Regla Ta Cb TC, TD (a) TC y TD sobre eventos inicio y fin TC (b) Duración flexible TC (c) Inicio y terminación inflexibles (fijos) TC (d) Inicio y terminación flexibles (ASAP, ALAP) TC (NET, NLT) TC (e) Restricción de cardinalidad TC (f) Ausencia incondicional (ABS-U) (g) Ausencia condicionada (ABS-C) TD (h) Start to Finish (i) Start to Start TD (j) Finish to Start (k) Finish to Finish TD (l) Ausencia incondicional (ABS-U) (m) Ausencia condicionada (ABS-C) a Time-BPMN [Gagné & Trudel 2009a] b [Cheikhrouhou et al. 2013b] No TCs Default=ASAP Start and End constraints [t1,t2] ABS-C ABS-U MSON MFON SASAP FASAP SALAP FALAP ! ! [minDur,maxDur] Duration [minDur,maxDur] Cardinality [Max_loopTimes] Predecessor Successor [leadORlag] SF Predecessor Successor [leadORlag] SS [leadORlag] FS Successor Predecessor [leadORlag] FF Predecessor Successor SNLT FNLT SNET FNET ABS-C ABS-U [t1,t2] Successor Successor Predecessor Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 131 a) TC y TD sobre eventos de inicio y fin. Se especifica una actividad sin restricciones ni dependencias y los nuevos decoradores para asociar restricciones ligadas a los eventos de inicio ( círculo con trazo fino) y terminación de la actividad ( círculo con trazo grueso). b) TC (Duración flexible). El decorador reloj de arena ( ) denota la duración flexible de la actividad en el intervalo [minDur, maxDur]. c) TC (Inicio y terminación inflexibles). Permite la especificación de inicio ( MSON) y terminación fija ( MFON). Se debe asociar el instante de referencia (vencimiento) a cada evento. d) TC (Inicio y terminación flexibles). Permite la especificación de los cuatro tipos de restricciones ASAP ( SASAP, FASAP) y ALAP ( SALAP, FALAP) que maneja el planificador de tareas. TC (NET, NLT). Aunque estos inicios y terminaciones también son flexibles, se establece una cota inferior o superior para cada evento; así, pueden especificarse las restricciones NET ( SNET, FNET) y NLT ( SNLT, FNLT). Sobre el evento en cuestión se especifica la cota. e) TC (Restricción de cardinalidad). Se expresa el máximo número de bucles de ejecución de una actividad cuya duración total es flexible . f) TC (Ausencia incondicional ABS-U). La actividad está permanentemente inactiva ( ). g) TC (Ausencia condicional ABS-C). La actividad está inactiva en el intervalo . h) TD (Start to Finish). Es una dependencia entre el evento de inicio de una actividad prececesora y el evento de finalización de la sucesora . Se puede especificar un adelanto o retraso entre estos eventos (leadORlag). i) TD (Start to Start). Es una dependencia entre los dos eventos de inicio de la precedesora y sucesora . j) TD (Finish to Start). Marca la dependencia entre el fin de la predecesora e inicio de la sucesora . k) TD (Finish to Finish). Dependencia entre los dos eventos de finalización . ! ! [Max_loopTimes] [minDur,maxDur] [t1,t2] [leadORlag] SF [leadORlag] SS [leadORlag] FS [leadORlag] FF Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 132 Tesis doctoral – cam l) TD (Ausencia incondicional, ABS-U). Si la predecesora se ha activado, la sucesora debe estar inactiva . m) TD (Ausencia condicionada en un intervalo, ABS-C). Si se activó la predecesora, la sucesora está inactiva en el intervalo de tiempo especificado . La especificación de reglas temporales mediante este enfoque es clara y elegante, pero por contra utiliza una semántica que no está todavía soportada por BPMN 2.0. 6.3.3 Patrones BPMN para representación de reglas temporales En [Flores & Sepúlveda 2011] se realiza una propuesta que utiliza patrones [Gamma et al. 1995; Tran et al. 2007] o construcciones BPMN para especificar las distintas restricciones temporales que soporta MS Project [Hansen & Hansen 2013; Stover 2007] bajo la perspectiva de restricciones contempladas en «Álgebra de intervalos de Allen» [Allen 1983]. Se contemplan: a) Restricciones temporales sobre una actividad y b) Dependencias temporales entre dos actividades. Proponen una construcción específica para tipo de restricción, considerando exclusivamente artefactos del estándar BPMN 1.2 (en el cual se basan), es decir: actividades, eventos, flujo de control y eventos de señal. La ventaja de la propuesta estriba en su plena adaptación al estándar, pero por otro lado hay que hacer mención que los modelos obtenidos si se aplican estas construcciones o patrones estarían sobrecargados. El empleo de señales puede deberse a la limitación de la versión BPMN 1.2 que no soportaba los «Eventos intermedios no interruptores del flujo de control (non-interrupting-intermediate events)» que aparecen en la versión BPMN 2.0. En esta sección se realiza como ejercicio el establecimiento de patrones similares a las propuestas de [Flores & Sepúlveda 2011] (que sólo representa las restricciones del Álgebra de Allen [Allen 1983]) pero utilizando non-interrupting-intermediate events para analizar el tipo de construcciones o patrones obtenidos. Las Tablas 6.3 y 6.4 muestran una propuesta de estos patrones para las restricciones y dependencias temporales, utilizando BPMN 2.0 y la taxonomía de reglas de referencia (Figura 6.1). BPMN 2.0 aporta nuevos artefactos que le otorgan una mejora en la expresividad frente a la versión BPMN 1.2 utilizada en [Flores & Sepúlveda 2011]. Se ha realizado el ejercicio de elaboración de estas construcciones sobre todas las reglas de la taxonomía (Figura 6.1) para compararlo con las construcciones de estos autores, y se observa que algunos patrones para moderar las reglas de tiempo siguen todavía muy sobrecargado de artefactos; es decir, si se utilizasen estos patrones para representar reglas de tiempo en los procesos de negocio, los procesos quedarían poco claros a ojos del experto. No obstante, la ventaja del enfoque estriba en que respeta el estándar al no aportar nueva semántica. A continuación se comentan las restricciones temporales de la Tabla 6.3: ABS-U ABS-C [t1,t2] Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 133 Time constraint over cardinality A={Ai} maxloop N times a) Comienzo y terminación flexible (ASAP, ALAP). Los flujos normales de ejecución (flujos por defecto marcados como ) son comienzo (SASAP) y finalización (FASAP). La introducción de las variantes ALAP (SALAP, FALAP) se puede realizar con un evento intermedio (timer ) que dispare el inicio de la actividad. En el caso FALAP, el evento es incrustado y provoca la finalización de la actividad al alcanzarse el evento de tiempo. Por otro lado, la duración (fija o flexible) puede modelarse también con eventos intermedios incrustados que disparen la finalización de la tarea aunque no se haya completado todo el trabajo. En los casos ASAP y ALAP no deben introducirse retrasos en el proceso global que contiene a la actividad. b) Cardinalidad (CARD). La actividad puede finalizar al realizar todo su trabajo o bien al alcanzar el máximo número de iteraciones en los límites de duración de la actividad. Se puede modelar con el evento condicional incrustado . Business Proces... maxloop N times Tabla. 6.3. Construcciones BPMN 2.0 para representar Restricciones de Tiempo (TC) (a) Comienzo y terminación flexible (ASAP, ALAP). Duración fija y flexible. (b) Restricción de cardinalidad. (c) Comienzo y terminación fijos (inflexibles). (d) Comienzo y terminación flexible (NET, NLT) (e) Restricción de ausencia incondicional (ABS-U) (f) Restricción de ausencia condicionada en un intervalo (ABS-C) Business Process BPMN 2.0 Time capabilities and limitations Inflexible Time Constraints A e(A)=MFON s(A)=MSON     1 1 ( ) ( ) ( ) ( ) ( ) min ( ) ( ) ( ) max ( ) N ii i N ii i e A s A dur A e A s A Dur A e A s A Dur A               Business Process BPMN 2.0 Time capabilities and limitations Fixed and flexible duration A dur(A) FALAP Flexible duration: minDur(A)<=dur(A)<=maxDur(A) SASAP None sucessor activity is delayed in the same process None predecessor activity is delayed in the same process SALAP Fixed duration: dur(A)=minDur(A)=maxDur(A) e(A)=s(A)+dur(A) FASAP Business Process BPMN 2.0 Time capabilities and limitations Flexible Start and End Time Constraints A dueDate=FNET and e(A)=FNET+T dueDate=FNLT and e(A)=FNLT-T dueDate=SNET dueDate=SNLT Normal flow +T -T s(A)=SNLT-T SNET+T=s(A) Business Process BPMN 2.0 Time capabilities and limitations The Absence constraint conditional ABS-C [t1, t2] Skip A Continue A ABS-C: AND now() IN [t1, t2] THEN CANCEL A Business Process BPMN 2.0 Time capabilities and limitations The absence constraint unconditional A ABS-U: Cancel A ABS-U: Skip A Continue Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 134 Tesis doctoral – cam c) Comienzo y terminación fijos (inflexibles). Los casos MSON y MFON pueden modelarse con timers ( ) que disparen el inicio y finalización de la actividad. d) Comienzo y terminación flexibles (NET, NLT). En cuanto al evento de inicio, si se especifican fechas tope, la actividad se podrá iniciar no antes de SNET (s(A)=snet+T), o bien no después de SNLT (s(A)=SNLT-T), siendo en ambos casos (T>=0) y modelándose con timers ( ). Para especificar la terminación se introducen eventos condicionales ligados a las fechas tope FNET (e(A)=FNET+T) y FNLT (e(A)=FNLT-T). En el primer caso, al alcanzar la fecha de referencia FNET no cancela la actividad, pues puede transcurrir un lapso posterior de tiempo. En el segundo caso, FNLT sí dispara la cancelación de la actividad. e) Ausencia incondicional (ABS-U). Si la actividad no se ha iniciado, equivale a saltar (skip) su ejecución; si se ha iniciado, corresponde cancelar la actividad y seguir el flujo del proceso. f) Ausencia condicionada a un intervalo (ABS-C [t1, t2]). En este caso hay que saltar la actividad o inhabilitarla sólo dentro del lapso de tiempo especificado. La Tabla 6.4 muestra propuestas de construcciones para las dependencias temporales: a) Finish to Start (FS). En este caso simplemente hay que considerar un lapso de tiempo (leadORlag ) entre la finalización de la predecesora y el inicio de la sucesora. El flujo de control es secuencial. b) Start to Start (SS). El flujo de ejecución de la predecesora y sucesora es en paralelo, pero puede existir un lapso de tiempo (leadORlag ) entre ambos inicios. c) Finish to Finish (FF). El flujo de ejecución también es en paralelo, aunque no se exige la sincronización de los inicios. Tras la finalización de la predecesora se captura con un evento el transcurso del lapso de tiempo (leadORlag ), y tras él se emite una señal ( ) que la sucesora puede capturar ( ) para interrumpir su ejecución, con lo que se sincronizan ambas finalizaciones. d) Start to Finish (SF). En este caso hay que capturar el inicio de la predecesora con la señal ( ) que no interrumpe la actividad. Tras este evento y transcurrido el lapso de tiempo (leadORlag ) se emite la señal ( ) que la sucesora puede capturar ( ) para ser interrumpida, sincronizando así el inicio y terminación de ambas. Busines... Finish Aj Business Process... Finish Aj Business Proc... Ai started Busines... Finish Aj Business Process... Finish Aj Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 135 Ai Aj leadORlag e) Dependencia de ausencia incondicional (ABS-U). Si la actividad predecesora se activa ( ), entonces la sucesora no debe llevar a cabo su trabajo. Se modela mediante el lanzamiento de un evento de compensación ( ) que captura la sucesora ( ), entrando en compensación y deshaciendo su trabajo ( ). f) Dependencia de ausencia condicionada en un intervalo (ABS-C [t1, t2]). El esquema es el anterior pero añadiendo como condición que el instante considerado esté en el intervalo Se han analizado las dos propuestas: a) Declarativa, mediante extensión del estándar con decoradores; y b) Imperativa, con utilización de patrones BPMN que se construyen utilizando exclusivamente artefactos existentes en el estándar. Pretendemos captar las ventajas de ambas propuestas: enfoque declarativo [Fahland 2009a, 2009b; Pichler et al. 2011; Reijers et al. 2013] para especificar la dimensión temporal y, además, respetar el soporte del estándar actual, lo cual otorgará simplicidad a los modelos y la posibilidad de implementarlos con esas características temporales. Se propondrá un enfoque Business Proc... Ai is started Business P... Throw AD(Ai/Aj) Busines... Business Proce... Rollback Aj Tabla. 6.4. Construcciones BPMN 2.0 para representar Dependencias Temporales (TD) (a) FS: Finish to Start (b) SS: Start to Start (c) FF: Finish to Finish (d) SF: Start to Finish (e) Dependencia de ausencia incondicional (ABS-U) (f) Dependencia de ausencia condicionada (ABS-C) Ai Aj leadORlag SF: Start to Finish Ai Ai started Aj Finish Aj leadORlag Finish Aj Business Process BPMN 2.0 Time capabilities and limitations FF: Finish to Finish Ai Aj Finish Aj leadORlag Finish Aj Business Process BPMN 2.0 Time capabilities and limitations The Unconditional Absence Dependency Ai Ai is started Aj Throw AD(Ai/Aj) Rollback Aj Business Process BPMN 2.0 Time capabilities and limitations The conditional Absence Dependency Ai Ai is started AND now() IN [t1,t2] Aj Throw AD(Ai/Aj) Rollback Aj Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 142 Tesis doctoral – cam 6.5 Un MetaModelo de procesos con reglas temporales (PIM-up) Se propone un enfoque declarativo [Fahland 2009a, 2009b; Pichler et al. 2011; Reijers et al. 2013] para expresar reglas temporales sobre procesos, basado en un Meta  Modelo UML pivote y fórmulas OCL (PIM-up) para especificar este tipo de restricciones. Las estructuras esenciales son las capturadas en la Tabla 5.5 anterior; este Meta  Modelo (PIM-up) otorgará mayor autonomía frente a la elección de alguno de los de los Meta  Modelos de los estándares de procesos de la sección anterior. Se utilizará posteriormente para sustentar el enfoque de ingeniería inversa [Chikofsky & Cross 1990] basada en MDE; además de ofrecer una representación más clara de la dimensión temporal, ayudará en la resolución de algunos problemas, como colisiones en la integración de artefactos (Capítulo 7). La utilización de un Meta  Modelo permitirá, con pocas adaptaciones, aprovechar las facilidades de lenguajes gráficos que lo soporten, ya que, dentro del estándar, las herramientas suelen permitir adaptaciones del interfaz, por ejemplo con estereotipos y/o personalizaciones de las figuras ligadas a los artefactos BPMN, de modo que se facilite la percepción visual de esta nueva semántica temporal, y asimilarla a propuestas como [Gagné & Trudel 2009a; Cheikhrouhou et al. 2013b] donde la semántica subyace en los nuevos decoradores aportados. 6.5.1 MetaModelo UML de procesos 6.5.1.1 Diagrama de clases El estudio de los Meta  Modelos de los estándares estudiados en las secciones anteriores permite extraer un conjunto mínimo de clases que pueden representarse en el diagrama UML de clases de la Figura 6.11 [Arevalo et al. 2015b]. Estas clases se agrupan dentro de un paquete «Semantic». La clase principal es Activity, cuyos subtipos pueden ser Task y Subprocess, que a su Tabla. 6.5. Comparación de MetaModelos de procesos: clases y asociaciones Concepto Meta  Modelos UML AD BPMN 2.0 XPDL 2.2 PIM-up Proceso ∄ process⇾tprocess⇾flowElement flowElement⇾tFlowElement WorkflowProcess⇾processType Process Subproceso, grupo de actividades ∄ subprocess⇾tSubProcess⇾flowElement tSubProcess⇾tActivity flowElement⇾tFlowElement BlockActivity⇾Activity BlockActivity⇾ActivitySet Subprocess⇾Process Subprocess⇾Activity Actividad Activity Activity⇾tActivity tActivity⇾tFlowNode⇾tFlowElement Activity Activity Tarea Activity tTask⇾tActivity Task⇾Activity Task⇾Activity Piscina o grupo de calles SwinLane laneSet⇾tLaneSet Pool Pool Calle SwinLane lane⇾tLane Lane Lane Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 143 vez es un subtipo de Process. Un Proceso (Process) se compone de un conjunto de actividades (+activities); tiene los atributos nombre (name:char), instante de inicio (start:date) y de finalización (end:date), y los eventos calculados por CPM: (startCPM:date), (endCPM:date) y la duración mínima (minDur:interval) del proceso para el camino crítico del proceso. El atributo (end) se activa cuando el proceso ha terminado. Un subproceso puede ser de tipo Adhoc (isAdhoc:boolean). Figura. 6.11. Meta  Modelo PIM-up La clase Activity posee los atributos nombre (name:char) y los eventos de inicio (start:date), de finalización (end:date) y los eventos calculados por CPM: (startCPM:date) y (endCPM:date). Una actividad puede tener asociado un conjunto de restricciones temporales (Temporal_Constraint). Para la clase Temporal_Constraint figuran los siguientes grupos de propiedades: i) start_sch:date y end_sch:date denota un intervalo de fechas de referencia que se van a instanciar para restricciones que fijan la fecha (MSON, MFON) o class Semantic Activity - name :char - start :date - end :date - startCPM :date - endCPM :date Process - name :char - start :date - end :date - startCPM :date - end_CPM :date - minDur :interval Subprocess - isAdHoc :boolean Task Temporal_Dependency - td_type :ETD_type - leadORlag :interval - startAbsence :date - endAbsence :date - isInAbsence :boolean Temporal_Constraint - end_sch :date - endAbsence :date - isInAbsence :boolean - loopTimes :int - maxDur :interval - minDur :interval - start_sch :date - startAbsence :date - tc_type :ETC_type A Semantic + Activity + Process + Subprocess + Task + Temporal_Constraint + Temporal_Dependency + ETC_Absence + ETC_Cardinality + ETC_Duration + ETC_TC_Flexible + ETC_TC_Inflexible + ETC_type + ETD_type +sucessor 1 td +predecessor * +activities * +tc* tc Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 144 Tesis doctoral – cam dejan los eventos de inicio o terminación flexible (NET, NLT). ii) isInAbsence:boolean especifica la restricción de ausencia (ABS-U),y startAbsence:date, endAbsence:date definen el intervalo de tiempo de la restricción de ausencia condicionada (ABS-C). iii) minDur:interval y maxDur:interval es el intervalo de tiempo para especificar duración fija (FIXD) o flexible (FLEXD) de ejecución de la actividad. iv) loopTimes:int es un entero que limita el número máximo de instancias de una actividad que se ejecuta en bucle (Restricción de cardinalidad: CARD); en este caso minDur:interval y maxDur:interval es el intervalo de tiempo de ejecución de cada instancia, puesto que las propiedades Activity.start y Activity.end marcan el intervalo de ejecución de todas las instancias. v) tc_Type:ETC_Type es el tipo de restricción, según el enumerado ETC_Type que se desglosa jerárquicamente en la Figura 6.12 [Arevalo et al. 2015b]. Para la clase Temporal_Dependency se instancian los atributos: i) isInAbsence:boolean especifica la dependencia de ausencia (ABS-U), y startAbsence:date, endAbsence:date definen el intervalo de tiempo de la dependencia de ausencia condicionada (ABS-C). ii) leadORlag:interval es el adelanto o retraso entre los eventos de la actividad sucesora y predecesora según el tipo de dependencia (SF, SS, FS, FF). iii) td_type es el tipo de dependencia, según la enumeración ETD_type de la Figura 6.12. 6.5.1.2 Enumeraciones La Figura 6.12 [Arevalo et al. 2015b] representa una jerarquía de enumeraciones para tipificar las restricciones y dependencias temporales. Figura. 6.12. Enumeraciones del Meta  Modelo PIM-up class Enumerations «enumeration» ETD_type FS FF SS SF ABS-U ABS-C «enumeration» ETC_type «enumeration» ETC_TC_Inflexible MSON MFON «enumeration» ETC_Duration FIXD FLEXD «enumeration» ETC_TC_Flexible FALAP FASAP FNET FNLT SALAP SASAP SNET SNLT «enumeration» ETC_Cardinality CARD «enumeration» ETC_Absence ABS-U ABS-C Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 145 6.5.1.3 Extensión del ciclo de vida de una actividad bajo CPM En la Figura 6.5 se ha expuesto una máquina de estados para ilustrar el ciclo de vida de las actividades de un proceso. En la Figura 6.13 se introduce un estado intermedio, asociado a las acciones o iteraciones del método CPM: estado «Scheduled» entre el estado «Inactive» y el estado Closed». También se especifican las transiciones en función de los estados que deben tener los atributos del Meta  Modelo. Hay que tener en cuenta que un proceso es un tipo de actividad que puede aparecer en otro proceso, con lo que la máquina de estados es válida para una actividad y también para un proceso. Figura. 6.13. Ciclo de vida de proceso y actividades (cálculo CPM) En el estado «Inactive», todos los atributos implicados no están instanciados: startCPM, endCPM, minDur (si es un proceso) start y end. Cuando se lleva a cabo una planificación mediante el método CPM, se instancian los atributos startCPM, endCPM y minDur (si es un proceso, con la duración del camino crítico del grafo). Los atributos start y end no instanciados representan que la tarea aún no ha recibido el token para activarse. Al llegar el token a la actividad y quedar disponibles los datos de entrada, la actividad puede llevar a cabo su trabajo «Active». Se instancia entonces el atributo start (inicio real de la tarea) y se igualan (startCPM=start). Desde el estado «Active» se puede realizar una nueva planificación que afecte al proceso y su conjunto de actividades o bien que la actividad termine su trabajo, pasando a estado «Closed», en cuyo momento se instancia end y se igualan (endCPM=end). Esta máquina de estado será de gran utilidad en la siguiente sección, que formula las stm process-activity SM-CPM Scheduled Active Inactive closed startCPM=null and endCPM=null and start=null and end=null and minDur=null [CPM calculated] /startCPM<>null and endCPM<>null and start=null and end=null and minDur<>null [Token arrives and data input available] /startCPM<>null and endCPM=null and start=startCPM and end=null and minDur calculated [work completed] /endCPM<>null and end=end_CPM [Re-scheduling] Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 146 Tesis doctoral – cam restricciones temporales mediante el lenguaje OCL [OMG:OCL 2014], pues permitirá formular las reglas temporales independientemente del estado, ofreciendo así fórmulas OCL más compactas y sencillas. 6.5.2 Definición de la dimensión temporal con OCL OCL es un «lenguaje declarativo Side-effect free» [Demuth et al. 1999, 2001; Cabot et al. 2012; OMG:OCL 2014]. Declarativo significa que está exento de construcciones imperativas, especificándose sólo fórmulas que expresan cada restricción. «Side-effect free» significa que se restringe el estado pero no incluye primitivas que modifiquen un estado inicial. En primer lugar se establecen fórmulas que representan como restricciones OCL las transiciones de la máquina de estados del apartado anterior (Figura 6.13). A continuación se formulan las distintas restricciones de tiempo y dependencias temporales de la taxonomía de reglas contemplada en la Figura 6.1. De este modo, las expresiones de las reglas temporales serán más compactas y no obligarán a sobrecargar cada sentencia con condiciones excesivas (asociadas a distinguir en qué estado está la actividad). 6.5.2.1 Restricciones sobre el ciclo de vida de procesos y actividades La Figura 6.14 representa la formulación OCL de las transiciones de la máquina de estados anterior (Figura 6.13), distinguiendo los invariantes de procesos y actividades. Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 147 Figura. 6.14. Restricciones OCL sobre el ciclo de vida de procesos y actividades MM PIM-up class OCL TC_0 Semantic::Process - name :char - start :date - end :date - startCPM :date - endCPM :date - minDur :interval Semantic::Activity - name :char - start :date - end :date - startCPM :date - endCPM :date (0) inactive inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() and minDur.oclIsUndefined() (1) scheduled inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and minDur.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() (2) active inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and minDur.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() and start=startCPM (3) closed inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and minDur.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() and start=startCPM and end=endCPM (0) inactive inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() (1) scheduled inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() (2) active inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() and start=startCPM (3) closed inv: startCPM.oclIsUndefined() and endCPM.oclIsUndefined() and start.oclIsUndefined() and end.oclIsUndefined() and start=startCPM and end=endCPM +activities * Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 148 Tesis doctoral – cam 6.5.2.2 Restricciones temporales sobre una actividad Las restricciones de tiempo se establecen sobre las clases Activity y Temporal_Constraint del Meta  Modelo (Figuras 6.15, 6.16 y Tabla 6.6) [Arevalo et al. 2015b]. Figura. 6.15. Restricciones de tiempo OCL (a) class OCL TC_1 «Time perspective» Temporal_ConstraintA MSON inv: (self. tc_type='MSON' ) implies self.tc->select( self.startCPM = self.start_sch )->notEmpty() MFON inv: ( self.tc_type='MFON' ) implies self.tc->select( self.endCPM = self.end_sch )->notEmpty() SNET inv: ( self.tc_type='SNET' ) implies self.tc-> select( self.startCPM >= self.start_sch )-> notEmpty() SNLT inv: ( self.tc_type='SNLT' ) implies self.tc-> select( self.startCPM <= self.end_sch )-> notEmpty() FNET inv: ( self.tc_type='FNET' ) implies self.tc-> select( self.endCPM <= self.start_sch )-> notEmpty() FNLT inv: ( self.tc_type='FNLT' ) implies self.tc-> select( self.endCPM <= self.end_sch )-> notEmpty() FLEX_START_END inv: ( ( Set{'SASAP','SALAP','FASAP','FALAP','SNET','SNLT','FNET','FNLT'} )->includes(self.tc_type) and self.tc.startCPM>=self.start_sch and self.tc.endCPM<=self.end_sch ) implies self->select ( ( self.tc.process.endCPM - self.tc.process.startCPM)=self.tc.min_Dur_P)->notEmpty() Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 149 Figura. 6.16. Restricciones de tiempo OCL (b) class OCL TC_2 «Time perspective» Temporal_ConstraintA FLEXD inv: (self.tc_type='FLEXD' ) implies self.tc->select( ( self.endCPM-self.startCPM )>=self.minDur and ( self.endCPM-self.startCPM )<=self.maxDur and ( self.end_sch-self.start_sch )>=self.minDur and ( self.end_sch-self.start_sch )<=self.maxDur )->notEmpty() FIXD inv: (self. tc_type='FIXD' ) implies self.tc->select ( ( self.endCPM - self.startCPM )=( self.end_sch-self.start_sch ) and ( self.endCPM-self.startCPM )=self.minDur and ( self.endCPM-self.startCPM )=self.maxDur )->notEmpty() CARD inv: (self.tc_type='CARD') implies self.tc->select ((self.startCPM+self.loopTimes·self.minDur<=self.endCPM) and (self.endCPM<=self.startCPM+self.loopTimes·self.maxDur) )->notEmpty() inv: (self. tc_type='CARD' and ( self.start_sch.oclIsUndefined() and self.end_sch.oclIsUndefined() ) implies (self.start_sch+self.loopTimes·self.minDur<=self.end_sch ) and (self.end_sch<=self.start_sch+self.loopTimes·self.maxDur ) )->notEmpty() ABS inv: ( self.tc_type='ABS-U' ) implies self.startAbsence.oclIsUndefined() and self.endAbsence.oclIsUndefined() and self.isInAbsence=true inv: ( tc_type='ABS-C' ) implies ( self.startAbsence.oclIsUndefined() and self.endAbsence.oclIsUndefined() and ( self.startAbsence<=self->tc.startCPM or self->tc.endCPM<=self.endAbsence) ) implies self. isInAbsence=true Capítulo 6. Reglas temporales sobre procesos Parte III. Solución propuesta 150 Tesis doctoral – cam Duración Fija (‘FIXD’). Este invariante expresa que la duración de la actividad coincide con la duración planificada, siendo ésta: (minDur=maxDur), que debe coincidir con el intervalo de ejecución de dicha actividad (expresión 6.1). Duración Flexible (‘FLEXD’). La expresión es similar a la anterior, pero relajando la duración de la actividad a un intervalo (expresión 6.2). Inicio y terminación flexibles (FLEX_Start_End). Este invariante agrupa a un conjunto de restricciones; esto se expresa con la condición OCL. Set{ 'SASAP','SALAP','FASAP','FALAP','SNET','SNLT','FNET','FNLT' }→includes(tc_type) Hay que distinguir el grupo {ASAP, ALAP} del grupo {NET, NLT}, pues en el primero, CPM, en las iteraciones de cálculo del camino crítico, puede alterar libremente los eventos de inicio de las actividades que tienen holgura (las que no afectan a la duración mínima del proceso), mientras que en el segundo grupo, el modelador puede poner cota a alguno de los eventos. Esto ya se ha expresado en la Figura 6.2 y Tabla 6.1; sustituyendo en esa expresión los parámetros: (so=start_sch y eo=end_sch). Con start_sch y end_sch se fijan las cotas en cada caso (Figura 6.2). El atributo process.minDur es la duración del camino crítico calculada mediante CPM, luego el invariante expresa que modificando los eventos de las restricciones de inicio y terminación flexible, la duración total de proceso se conserva igual a process.minDur. Cardinalidad (‘CARD’). minDur y maxDur son las duraciones máximas de ejecución de cada instancia de la actividad en bucle. El bucle no puede ejecutarse más de loopTimes veces dentro del intervalo de ejecución global de la tarea (en magnitudes reales o sobre el plan de ejecución). Comienzo (MSON) o terminación fijas (MFON). El comienzo de la actividad debe suceder en el instante planificado (MSON) o el evento de finalización de la actividad está determinado por la planificación (MFON). SNET, SNLT, FNET, FNLT. En este caso los invariantes expresan restricciones sobre las fechas tope que actúan como cotas para los eventos de inicio o terminación de la actividad. Este grupo de restricciones también están involucradas en el invariante previo de inicio y terminación flexible, así que no deben alterar la duración mínima del proceso. ABS (ABS-U, ABS-C). El atributo isInAbsence se refiere al estado de ausencia de una actividad. Si el estado es permanente (isInAbsence=true) la ausencia es incondicional (ABS-U) y la actividad se salta cuando le llega el flujo de control, pero si la actividad figura en este estado sólo durante un intervalo de tiempo, la ausencia es condicionada (ABS-C) en el intervalo [startAbsence, endAbsence]. Parte III. Solución propuesta Capítulo 6. Reglas temporales sobre procesos Tesis doctoral – cam 151 Tabla. 6.6. Restricciones temporales OCL # tr Especificación OCL de la restricción temporal FIXD Context Temporal_constraint inv: (self. tc_type='FIXD' ) implies self.tc→select ( ( self.endCPM - self.startCPM )=( self.end_sch-self.start_sch ) and ( self.endCPM-self.startCPM )=self.minDur and ( self.endCPM-self.startCPM )=self.maxDur )→notEmpty() FLEXD Context Temporal_constraint inv: ( self.tc_type='FLEXD' ) implies self.tc→select( ( self.endCPMself.startCPM )>=self.minDur and ( self.endCPMself.startCPM )<=self.maxDur and ( self.end_sch-self.start_sch )>=self.minDur and ( self.end_sch-self.start_sch )<=self.maxDur )→notEmpty() FLEX_ Start_ End Context Temporal_constraint inv: ( ( Set{'SASAP','SALAP','FASAP','FALAP','SNET','SNLT','FNET','FNLT'} )→includes( self.tc_type) and self.tc.startCPM>= self.start_sch and self.tc.endCPM<= self.end_sch ) implies self→select ( ( self.tc.process.endCPM - self.tc.process.startCPM)=self.tc.min_Dur_P)→notEmpty() CARD Context Temporal_constraint inv: ( self.tc_type='CARD') implies self.tc→select (( self.startCPM+self.loopTimes·self.minDur<=endCPM) and ( self.endCPM<= self.startCPM+self.loopTimes - self.maxDur) )→notEmpty() Context Temporal_constraint inv: inv: ( self.tc_type='CARD' and ( self.start_sch→notEmpty() and self.end_sch→notEmpty() ) implies (self.start_sch+self.loopTimes·self.minDur<=self.end_sch ) and (self.end_sch<=self.start_sch+self.loopTimes·self.maxDur ) )→notEmpty() MSON Context Temporal_constraint inv: ( self.tc_type='MSON' ) implies self.tc→select( self.startCPM = self.start_sch )→notEmpty() MFON Context Temporal_constraint inv: ( self.tc_type='MFON' ) implies self.tc→select( self.endCPM = self.end_sch )→notEmpty() SNET Context Temporal_constraint inv: ( self.tc_type='SNET' ) implies self.tc→select( self.startCPM >= self.start_sch )→notEmpty() SNLT Context Temporal_constraint inv: ( self.tc_type='SNLT' ) implies self.tc→select( self.startCPM <= self.end_sch )→notEmpty() FNET Context Temporal_constraint inv: ( self.tc_type='FNET' ) implies self.tc→select( self.endCPM <= self.start_sch )→notEmpty() FNLT Context Temporal_constraint inv: ( self.tc_type='FNLT' ) implies self.tc→select( self.endCPM <= self.end_sch )→notEmpty() ABS Context Temporal_constraint inv: ( self.tc_type='ABS-U' ) implies self.startAbsence.oclIsUndefined() and self.endAbsence.oclIsUndefined() and self.isInAbsence=true Context Temporal_constraint inv: ( self.tc_type='ABS-C' ) implies ( self.startAbsence.oclIsUndefined() and self.endAbsence.oclIsUndefined() and ( self.startAbsence<=self→tc.startCPM or self→tc.endCPM<=self.endAbsence) ) implies self.isInAbsence=true Acrónimos Parte V. Anexos 254 Tesis doctoral – cam CPM. «Critical Path Method». Método para calcular el camino crítico o de duración mínima de un grafo PERT. CWM. «Common Warehouse Meta  Model». Estándar OMG para la definición e intercambio de almacenes de datos. Experto de negocio. Persona de la organización que conoce el dominio del problema. Tiene el conocimiento para poder especificar cualquier proceso y sus variantes, detallando al máximo nivel cualquier regla del negocio. Experto TIC. Experto en tecnologías de información y comunicaciones (consultor, analista, programador, técnico de sistemas, etc.). GASTM. «Generic Abstract Syntax Tree Meta  Model». Estándar OMG para la definición de árboles de sintaxis abstracta con instrucciones compartidas por distintos lenguajes. ISO. «International Organization for Standardization». Organismo internacional para la estandarización. ITIL. «Information Technology Infrastructure Library». IWT2. Grupo de investigación «Ingeniería Web y Testing Temprano» del Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla. IMM. «Information Management Meta  Model». Estándar OMG para soportar la interoperabilidad entre distintos Meta  Modelos. Es una evolución de OMG CWM. KDM. «Knowledge Discovery Meta  Model». Estándar OMG para la extracción de conocimiento desde legacy systems. Es un Meta  Modelo integrado en ADM. Legacy database. Base de datos heredada o base de datos de un legacy system. Una legacy database da persistencia a estados que son consecuencia de la ejecución de distintos procesos de una organización. Legacy system (o legacy information system). Sistema heredado o aplicación informática antigua que se sigue utilizando y no es fácil de sustituir. Mapeo. Este término es la traducción al español utilizado en esta tesis del término mapping operation, definido en QVT como una operación que implementa una parte de una transformación. MDA. «Model-Driven Architecture». Iniciativa de OMG que soporta el paradigma MDE con un conjunto de Meta  Modelos y lenguajes. MDE. «Model-Driven Engineering». Estas siglas denotan una filosofía de desarrollo guiada por modelos, en la cual, el principal objetivo de una fase (análisis, diseño, etc.) es desarrollar los modelos adecuados a partir del refinamiento de los modelos obtenidos en la fase anterior. Parte V. Anexos Acrónimos Tesis doctoral – cam 255 MDD. «Model-driven Development» o «Model-driven Software Development». MDSD. «Model-driven Software Development» o «Model-driven Development». MDSM. «Model Driven Software Modernization». MetaModelo. En el contexto de este trabajo un Meta  Modelo es la definición de una gramática (elementos y reglas de construcción) con la que poder elaborar modelos que sean conformes a dicho metamodelo. MOF. «Meta-Object Facility» que representa conjunto de interfaces estándares que pueden ser utilizadas para definir y manipular metamodelos interoperables y sus correspondientes modelos. MOFM2T. «MOF Model to Text Transformation Language». Ver también M2T. que identifica un estándar propuesto por el OMG para definir reglas de derivación para generar una versión textual de modelos. Modelo. En el contexto de este trabajo, un modelo es una representación mediante un lenguaje concreto, con un mayor o menor grado de abstracción, de un aspecto de un sistema de información. Por ejemplo, un modelo de pruebas será la representación de un conjunto de pruebas a realizar sobre el sistema. M2M. «Model to Model». Transformaciones desde artefactos de un modelo a otro modelo, basadas en Meta  Modelos. M2T. «Model to Text»; ver también MOFM2T. Transformaciones realizadas desde un modelo a una especificación en un lenguaje textual. NDT. «Navigational Development Techniques» que identifica la propuesta metodológica que ha servido como influencia para la realización de este trabajo de tesis y que será fundamental en trabajos futuros posteriores. NDTQ-Framework. Entorno tecnológico del grupo de investigación IWT2 basado en la metodología NDT, basado en MDE, estándares, modelos de madurez y buenas prácitcas. OASIS. «Advanced Open Standards for the Information Society». Organismo de estandarización que, entre otros estándares, gestiona los asociados a BPEL y arquitecturas BPM. OCL. «Object Constraint Language» que identifica un lenguaje para la descripción formal de expresiones en los modelos UML. Su papel principal es el de completar los diferentes artefactos de la notación UML con requerimientos formalmente expresados. OMG. «Object Management Group», que identifica a un consorcio sin ánimo de lucro formado por diversas compañías y organizaciones. Se dedica al cuidado y el establecimiento de diversos estándares de tecnologías orientadas a objetos, así como a fomentar el uso de tecnología orientada a objetos mediante guías y especificaciones Acrónimos Parte V. Anexos 256 Tesis doctoral – cam para las mismas. PAIS. «Process Aware Information System». Sistema informático que contempla la gestión de procesos. Perfil UML. Herramienta de extensión del lenguaje UML con el que es posible describir un problema de modelado en particular y facilitar la construcción de modelos en ese dominio. PERT. «Project Evaluation and ReviewTechniques». Técnicas de evaluación y control de proyectos ideadas por la Oficina de Proyectos Especiales de la Marina de Guerra del Departamento de Defensa de los EE.UU. PIM. «Platform Independent Meta  Model». Término MDA para Meta  Modelo independiente de la plataforma tecnológica. PIP. «Process Improvement Process». Metodología que busca la mejora contínua de los procesos existentes en una organización. PMI. Project Management Institute. PMBOK. «Project Management Body of Knowledge». Iniciatiba del PMI: Procedimientos o buenas prácticas para la gestión de proyectos. PRINCE2. «PRojects IN Controlled Environments 2». Metodología de gestión de proyectos que, que manejan una carga importante de variabilidad y de incertidumbre, en entornos controlados. Proceso Software. Se define como un conjunto coherente de políticas, estructuras organizacionales, tecnologías, procedimientos y artefactos necesarios para concebir, desarrollar, desplegar y mantener un producto software. PSM. «Platform Specific Meta  Model». Término MDA para Meta  Modelo específico de una plataforma. PRR. «Production Rule Representation». Estándar OMG para la definición de reglas de producción. QVT. «Query/View/Transform» que identifica el lenguaje de transformaciones de modelo a modelo definido por la OMG y utilizado en este trabajo de tesis. SASTM. «Specific Abstract Syntax Tree Meta  Model». Estándar OMG para la definición de árboles de sintaxis abstracta específicos de un lenguaje. SBVR. «Semantics of Business Vocabulary and Rules». Estándar OMG para la definición de vocabularios y reglas de negocio. Sintaxis abstracta. En este trabajo de tesis, este término es sinónimo del termino metamodelo y se utiliza con el mismo significado. Sintaxis concreta. En este trabajo de tesis, este término es sinónimo del termino modelo Parte V. Anexos Acrónimos Tesis doctoral – cam 257 y se utiliza con el mismo significado. Sistema heredado. Legacy system o legacy information system. Es un sistema o aplicación informática antigua que se sigue utilizando y no es fácil de sustituir. SPEM. «Software & Systems Process Engineering Meta  Model specification (SPEM 2.0)». SQL. «Structured Query Language». Estándar ISO para la definición u manipulación de bases de datos relacionales. TI. Tecnologías de la información (Sector TI: organizaciones dedicadas al negocio del software). TIC. Tecnologías de la información y comunicaciones (Sector TIC: abarca a todo tipo de organización dedicada a software, hardware o de las comunicaciones). Transformación (O transformación MDE). En el contexto de este trabajo una transformación es una especificación de cómo construir un modelo conforme con un metamodelo, tomando como entrada otro modelo conforme a otro metamodelo, que puede ser el mismo o distinto. UML. Acrónimo de «Unified Modelling Language» y que identifica a un lenguaje estándar de modelado gráfico, utilizado en este trabajo principalmente para definir los metamodelos y modelos presentados. WfMC. «Workflow Management Coalition». Organismo de estandarización en el mundo BPM. WS-BPEL. «Web Services Business Process Execution Language». Lenguaje estándar de OASIS para la ejecución de procesos. XPDL. «XML Process Definition Language». Lenguaje del WfMC para la definición e intercambio de modelos de procesos. ANEXO II: METAMODELOS DE TAREAS EN LEGACY DATABASES (LDB) Parte V. Anexos Anexo II: Meta  Modelos de tareas en Legacy Systems Tesis doctoral – cam 261 Anexo II.a: LDB MS Access/MS Project Figura. AII.1. MetaModelo de tareas de MS Project (MS Access) Anexo II.b: LDB SQL*Server/MS Project Server Published instance Figura. AII.2. MetaModelo de tareas de MS Project Server (SQL*Server™). Tablas principales class ERD View Project Task Resource Group Assignment PredecessorLinkCalendar +FK_Project_Calendar (CalendarUID = UID) +PK_Calendar +FK_Assignment_Resource (ResourceUID = UID) +PK_Resource +FK_PredecessorLink_Task (PredecessorUID = WBS) +PK_Task +FK_Assignment_Task (TaskUID = WBS) +PK_Task +FK_Task_Task (OutlineNumber = WBS) +PK_Task +FK_Task_Project +PK_Project erd Draft MSP_ASSIGNMENTS MSP_LINKS MSP_TASKS MSP_PROJECTS MSP_RESOURCES MSP_PROJ_HIERARCHIES MSP_CALENDARS MSP_ASSIGNMENT_BASELINES MSP_CUSTOM_FIELDS MSP_PROJECT_RESOURCE_BASELINES MSP_QUEUE_PROJECT_GROUP MSP_VERSIONS MSP_WEB_GROUP_SCHEMES MSP_WEB_OBJECTS Anexo II: Meta  Modelos de tareas en Legacy Systems Parte V. Anexos 262 Tesis doctoral – cam Anexo II.c: LDB PostgreSQL/ECM Alfresco Figura. AII.3. Workflow básico de Alfresco Figura. AII.4. MetaModelo del ECM:Alfresco (PostgreSQL) Parte V. Anexos Anexo II: Meta  Modelos de tareas en Legacy Systems Tesis doctoral – cam 263 Figura. AII.5. MetaModelo de tareas de Activity (Integrado con Alfresco en PostgreSQL) Anexo III: Meta  Modelos relacionales SQL Parte V. Anexos 270 Tesis doctoral – cam Figura. III.4. MetaModelo OMG:IMM PSM Relacional. Constraint Unique Keys Parte V. Anexos Anexo III: Meta  Modelos relacionales SQL Tesis doctoral – cam 271 Figura. III.5. MetaModelo OMG:IMM PSM Relacional. Constraint Foreign Keys Anexo III: Meta  Modelos relacionales SQL Parte V. Anexos 272 Tesis doctoral – cam Figura. III.6. MetaModelo OMG:IMM PSM Relacional. Constraint Other Constraints Parte V. Anexos Anexo III: Meta  Modelos relacionales SQL Tesis doctoral – cam 273 Anexo III.b: Extensiones a MetaModelos relacionales. Restricciones Este MetaModelo [Arevalo et al. 2013] se ha utilizado para la extracción de ECA Rules desde bases de datos relacionales. Figura. III.7. MetaModelo PSM Relacional. Paquetes Figura. III.8. Meta  Modelo PSM Relacional. Extensiones para triggers ANEXO IV: PROYECTO AQUA-WS Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 277 Anexo IV.a: Planificación del proyecto (MS Project) Anexo IV.a1. Planificación general del Proyecto (Tareas generales y subsistemas) Figura. IV.1. Planificación General Proyecto AQUA-WS por subsistemas Anexo IV: Proyecto AQUA-WS Parte V. Anexos 278 Tesis doctoral – cam Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 279 Anexo IV: Proyecto AQUA-WS Parte V. Anexos 286 Tesis doctoral – cam Anexo IV.c: Tablas BD SQL*Server Published-AQUA Figura. IV.6. Tabla Ext_Task_Constraint_Types (AQUA-WS) Figura. IV.7. Tabla Ext_Link_Types (AQUA-WS) Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 287 Figura. IV.8. Tabla Msp_Projects (AQUA-WS) Anexo IV: Proyecto AQUA-WS Parte V. Anexos 288 Tesis doctoral – cam Figura. IV.9. Tabla Msp_Tasks (AQUA-WS) Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 289 Tabla. IV.1. Tabla SQL*Server Msp_Tasks (AQUA-WS) PROJ_ UID TASK_ UID TASK_ HUID TASK_ PAREN T_UID TASK_NAME TASK_DU R_IS_EST TASK_OUTL INE_LEVEL TASK_ DUR TASK_ST ART_DAT E TASK_FIN ISH_DAT E TASK_AC T_START TASK_ACT_ FINISH TASK_CONS TRAINT_DA TE TASK_C ONSTRAI NT_TYPE 1 1 1 Proyecto True 1 567,00 19-11-07 19-1-10 19-11-07 0 1 2 1.1 1 Seguimiento y Control del Proyecto True 2 567,00 19-11-07 19-1-10 19-11-07 19-1-10 6 1 3 1.2 1 Organización y lanzamiento del Proyecto False 2 109,00 19-11-07 17-4-08 19-11-07 0 1 4 1.2.1 3 Reunión de Lanzamiento False 3 1,00 19-11-07 19-11-07 19-11-07 19-11-07 0 1 5 1.2.2 3 Elaboración y Revisión Manual de Calidad False 3 23,00 10-12-07 9-1-08 10-12-07 9-1-08 10-12-07 6 1 6 1.2.3 3 Elaboración y Revisión Plan de Gobierno del Proyecto False 3 17,00 29-11-07 21-12-07 29-11-07 21-12-07 21-12-07 6 1 7 1.2.4 3 Elaboración Plan Maestro del Proyecto False 3 15,00 10-12-07 28-12-07 10-12-07 28-12-07 28-12-07 6 1 8 1.2.5 3 Elaboración y Aceptación Plan de Calidad False 3 3,00 9-1-08 11-1-08 9-1-08 11-1-08 11-1-08 6 1 9 1.2.6 3 Elaboración del Plan de Comunicación False 3 10,00 3-3-08 14-3-08 3-3-08 14-3-08 3-3-08 4 1 10 1.2.7 3 Puesta en marcha del Plan de Comunicación False 3 24,00 17-3-08 17-4-08 0 1 11 1.3 1 Alfa 0.1: Capa Transversal. Subsistema Común True 2 220,00 10-12-07 10-10-08 10-12-07 0 1 12 1.3.1 11 Identificación de Subsistemas False 3 49,00 10-12-07 14-2-08 10-12-07 14-2-08 20-11-07 4 1 13 1.3.2 11 Definición del Sistema False 3 51,00 14-12-07 22-2-08 14-12-07 22-2-08 22-2-08 6 1 14 1.3.3 11 Establecimiento de Requisitos False 3 55,00 17-12-07 29-2-08 17-12-07 29-2-08 29-2-08 6 1 15 1.3.4 11 Análisis Modelo de Datos Actual False 3 80,00 17-12-07 4-4-08 17-12-07 4-4-08 4-4-08 6 1 16 1.3.5 11 Definición de la arquitectura del sistema False 3 30,00 25-2-08 4-4-08 25-2-08 4-4-08 28-3-08 6 1 17 1.3.6 11 Modelo Conceptual Núcleo Aqua False 3 45,00 3-3-08 9-5-08 3-3-08 9-5-08 9-5-08 6 1 18 1.3.7 11 Front End Análisis Elementos Comunes True 3 31,00 18-2-08 31-3-08 18-2-08 31-3-08 31-3-08 6 1 19 1.3.8 11 Front End Entrega Borrador Servicios False 3 0 31-3-08 31-3-08 12-3-08 4 1 20 1.3.9 11 Front End Entrega Análisis Elementos Comunes False 3 0 31-3-08 31-3-08 31-3-08 6 1 21 1.3.10 11 Sistemas Transversales Análisis Elementos Comunes True 3 55,00 14-1-08 28-3-08 14-1-08 28-3-08 28-3-08 6 1 22 1.3.11 11 Sistemas Transversales Entrega Análisis Elementos Comunes True 3 1,00 31-3-08 31-3-08 0 1 23 1.3.12 11 ASI Capa Transversal False 3 45,50 3-3-08 12-5-08 3-3-08 12-5-08 9-5-08 6 1 24 1.3.13 11 ASI Subsistema Común Núcleo AQUA False 3 44,00 3-3-08 9-5-08 3-3-08 9-5-08 9-5-08 6 1 25 1.3.14 11 Diseño físico de datos False 3 56,88 14-3-08 2-6-08 14-3-08 2-6-08 2-6-08 6 1 26 1.3.15 11 DSI Subsistema Común Núcleo AQUA False 3 25,00 7-4-08 20-6-08 7-4-08 20-6-08 20-6-08 6 1 27 1.3.16 11 Front End Diseño Técnico de Elementos Comunes False 3 30,00 28-4-08 23-5-08 28-4-08 23-5-08 28-4-08 4 1 28 1.3.17 11 Front End Entrega Diseño Técnico de Elementos Comunes False 3 0 23-5-08 23-5-08 14-4-08 4 1 29 1.3.18 11 Sistemas Transversales Diseño Técnico Elementos Comunes False 3 30,00 28-4-08 23-5-08 28-4-08 23-5-08 28-4-08 4 1 30 1.3.19 11 Sistemas Transversales Entrega Diseño Técnico Elementos Comunes False 3 0 23-5-08 23-5-08 14-4-08 4 Anexo IV: Proyecto AQUA-WS Parte V. Anexos 290 Tesis doctoral – cam Tabla. IV.1. Tabla SQL*Server Msp_Tasks (AQUA-WS) PROJ_ UID TASK_ UID TASK_ HUID TASK_ PAREN T_UID TASK_NAME TASK_DU R_IS_EST TASK_OUTL INE_LEVEL TASK_ DUR TASK_ST ART_DAT E TASK_FIN ISH_DAT E TASK_AC T_START TASK_ACT_ FINISH TASK_CONS TRAINT_DA TE TASK_C ONSTRAI NT_TYPE 1 31 1.3.20 11 Sistemas Transversales Análisis Gestor Documental False 3 45,00 26-5-08 4-7-08 26-5-08 0 1 32 1.3.21 11 Sistemas Transversales Diseño Técnico Gestor Documental False 3 15,00 7-7-08 25-7-08 14-4-08 4 1 33 1.3.22 11 CSI Prototipo Capa Transversal False 3 55,00 7-4-08 20-6-08 7-4-08 20-6-08 20-6-08 6 1 34 1.3.23 11 Especificación técnica del plan de pruebas False 3 15,00 2-6-08 20-6-08 2-6-08 20-6-08 20-6-08 6 1 35 1.3.24 11 CSI Subsistema Común Núcleo AQUA False 3 70,00 23-6-08 26-9-08 23-6-08 0 1 36 1.3.25 11 IAS Pruebas Subsistema Común Núcleo AQUA False 3 10,00 29-9-08 10-10-08 16-5-08 4 1 37 1.3.26 11 Front End Desarrollo elementos comunes False 3 45,00 26-5-08 4-7-08 26-5-08 0 1 38 1.3.27 11 Sistemas Transversales Desarrollo elementos comunes False 3 30,00 26-5-08 20-6-08 26-5-08 0 1 39 1.3.28 11 Sistemas Transversales Desarrollo Integración Gestor Documental False 3 30,00 28-7-08 22-8-08 0 1 40 1.4 1 Alfa 0.2 : Gestión de Clientes. False 2 254,75 31-3-08 20-3-09 31-3-08 0 1 41 1.4.1 40 ASI Atención Cliente / Contratación /Lecturas False 3 60,00 31-3-08 20-6-08 31-3-08 20-6-08 20-6-08 6 1 42 1.4.2 40 ASI Gen/ Plan/ Cump/Val y Fin. de actuaciones tipo False 3 60,00 31-3-08 20-6-08 31-3-08 20-6-08 20-6-08 6 1 43 1.4.3 40 Front End Análisis Atención Ciudadano y Empleado False 3 20,00 20-6-08 17-7-08 20-6-08 4 1 44 1.4.4 40 Sistemas Transversales Análisis FICO False 3 60,00 29-12-08 20-2-09 0 1 45 1.4.5 40 Sistemas Transversales Análisis Recursos Humanos False 3 30,00 23-2-09 20-3-09 17-10-08 6 1 46 1.4.6 40 DSI Atención Cliente / Contratación/Lecturas False 3 45,00 23-6-08 22-8-08 23-6-08 18-7-08 6 1 47 1.4.7 40 DSI Gen/ Plan/ Cump/Val y Fin. de actuaciones tipo False 3 45,00 23-6-08 22-8-08 23-6-08 22-8-08 6 1 48 1.4.8 40 Front End Diseño Técnico 1 False 3 18,00 25-8-08 9-9-08 0 1 49 1.4.9 40 Sistemas Transversales Diseño Técnico FICO False 3 15,00 20-10-08 7-11-08 20-10-08 4 1 50 1.4.10 40 Sistemas Transversales Diseño Técnico Recursos Humanos False 3 15,00 10-11-08 28-11-08 10-11-08 4 1 51 1.4.11 40 CSI Alfa 0.2: Gestión de Clientes 1 False 3 90,00 25-8-08 26-12-08 26-12-08 6 1 52 1.4.12 40 IAS Pruebas Alfa 0.2 False 3 15,00 29-12-08 16-1-09 16-5-08 4 1 53 1.4.13 40 Front End Desarrollo CRM Atención Ciudadano y Empleado 1 False 3 40,00 10-9-08 15-10-08 0 1 54 1.4.14 40 Sistemas Transversales Desarrollo Integración FICO False 3 45,00 10-11-08 19-12-08 10-11-08 4 1 55 1.4.15 40 Sistemas Transversales Desarrollo Integración Recursos Humanos False 3 30,00 1-12-08 26-12-08 0 1 56 1.5 1 Alfa 0.3: Gestión de Obras y Proyectos False 2 173,00 17-3-08 12-11-08 17-3-08 0 1 57 1.5.1 56 ASI Gestión de Obras y Proyectos False 3 45,00 17-3-08 16-5-08 17-3-08 16-5-08 0 1 58 1.5.2 56 DSI Gestión de Obras y Proyectos False 3 48,00 19-5-08 23-7-08 19-5-08 23-7-08 0 1 59 1.5.3 56 CSI Gestión de Obras y Proyectos False 3 90,00 26-6-08 29-10-08 0 1 60 1.5.4 56 Pruebas Gestión de Obras y Proyectos False 3 10,00 30-10-08 12-11-08 18-6-08 4 Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 291 Tabla. IV.1. Tabla SQL*Server Msp_Tasks (AQUA-WS) PROJ_ UID TASK_ UID TASK_ HUID TASK_ PAREN T_UID TASK_NAME TASK_DU R_IS_EST TASK_OUTL INE_LEVEL TASK_ DUR TASK_ST ART_DAT E TASK_FIN ISH_DAT E TASK_AC T_START TASK_ACT_ FINISH TASK_CONS TRAINT_DA TE TASK_C ONSTRAI NT_TYPE 1 61 1.6 1 Alfa 0.4: Clientes: Intervenciones en Red True 2 229,50 28-4-08 13-3-09 28-4-08 0 1 62 1.6.1 61 ASI Facturación False 3 9,00 23-6-08 3-7-08 23-6-08 3-7-08 3-7-08 6 1 63 1.6.2 61 DSI Facturación False 3 36,00 4-7-08 22-8-08 4-7-08 0 1 64 1.6.3 61 ASI Instalaciones y Equipos False 3 60,00 23-6-08 12-9-08 23-6-08 12-9-08 6 1 65 1.6.4 61 ASI Validación y Facturación de Intervenciones en Redes False 3 60,00 23-6-08 12-9-08 23-6-08 0 1 66 1.6.5 61 ASI Cobros / Cortes e Impagos False 3 40,00 15-9-08 7-11-08 0 1 67 1.6.6 61 DSI Cobros / Cortes e Impagos False 3 35,00 10-11-08 26-12-08 5-12-08 6 1 68 1.6.7 61 Front End Análisis Atención Ciudadano 2 False 3 10,00 29-12-08 9-1-09 0 1 69 1.6.8 61 Front End Análisis Gestión Empleados 2 False 3 10,00 12-1-09 23-1-09 0 1 70 1.6.9 61 DSI Instalaciones y Equipos False 3 40,00 15-9-08 7-11-08 28-3-08 4 1 71 1.6.10 61 DSI Validación y Facturación de Intervenciones en Redes False 3 40,00 15-9-08 7-11-08 28-3-08 4 1 72 1.6.11 61 Front End Diseño Técnico 2 False 3 18,00 29-12-08 13-1-09 0 1 73 1.6.12 61 Sistemas Transversales Análisis GIS False 3 30,00 1-12-08 26-12-08 0 1 74 1.6.13 61 Sistemas Transversales Diseño Técnico GIS False 3 15,00 29-12-08 16-1-09 14-4-08 4 1 75 1.6.14 61 CSI Alfa 0.4: Gestión de Clientes 2 False 3 105,00 28-4-08 19-9-08 0 1 76 1.6.15 61 IAS Pruebas Alfa 0.4 False 3 15,00 22-9-08 10-10-08 18-6-08 4 1 77 1.6.16 61 Front End Desarrollo CRM Atención Ciudadano y Empleado 2 False 3 60,00 14-1-09 6-3-09 0 1 78 1.6.17 61 Front End Desarrollo ayuda True 3 4,50 9-3-09 13-3-09 0 1 79 1.6.18 61 Sistemas Transversales Desarrollo GIS False 3 30,00 19-1-09 13-2-09 0 1 80 1.7 1 Alfa 0.5: Clientes. Informes de Gestión False 2 265,00 9-6-08 12-6-09 0 1 81 1.7.1 80 ASI Gestión Cl./P5 / Gest. Demanda / Herramientas Auxiliares False 3 35,00 10-11-08 26-12-08 0 1 82 1.7.2 80 ASI Informes de Gestión y MMR False 3 45,00 10-11-08 9-1-09 0 1 83 1.7.3 80 Sistemas Transversales Análisis Almacenes False 3 30,00 19-1-09 13-2-09 0 1 84 1.7.4 80 Sistemas Transversales Análisis Compras False 3 30,00 16-2-09 13-3-09 0 1 85 1.7.5 80 DSI Gestión Cl./P5 / Gest. Demanda / Herramientas Auxiliares False 3 30,00 29-12-08 6-2-09 7-11-08 4 1 86 1.7.6 80 DSI Informes de Gestión y MMR False 3 30,00 12-1-09 20-2-09 7-11-08 4 1 87 1.7.7 80 Sistemas Transversales Diseño Técnico Almacenes False 3 15,00 16-3-09 3-4-09 14-4-08 4 1 88 1.7.8 80 Sistemas Transversales Diseño Técnico Compras False 3 15,00 6-4-09 24-4-09 14-4-08 4 1 89 1.7.9 80 CSI Alfa 0.5:Gestión de Clientes 3 False 3 45,00 9-6-08 8-8-08 0 1 90 1.7.10 80 CSI Alfa 0.5: Informes de Gestión / MMR False 3 80,00 23-2-09 12-6-09 29-12-08 4 Anexo IV: Proyecto AQUA-WS Parte V. Anexos 292 Tesis doctoral – cam Tabla. IV.1. Tabla SQL*Server Msp_Tasks (AQUA-WS) PROJ_ UID TASK_ UID TASK_ HUID TASK_ PAREN T_UID TASK_NAME TASK_DU R_IS_EST TASK_OUTL INE_LEVEL TASK_ DUR TASK_ST ART_DAT E TASK_FIN ISH_DAT E TASK_AC T_START TASK_ACT_ FINISH TASK_CONS TRAINT_DA TE TASK_C ONSTRAI NT_TYPE 1 91 1.7.11 80 IAS Pruebas Alfa 0.5 False 3 10,00 11-8-08 22-8-08 18-6-08 4 1 92 1.7.12 80 Desarrollo Integración Almacenes False 3 45,00 6-4-09 15-5-09 0 1 93 1.7.13 80 Desarrollo Integración Compras False 3 30,00 27-4-09 22-5-09 0 1 94 1.8 1 Beta 0.6: Núcleo Aqua False 2 324,00 25-8-08 19-11-09 0 1 95 1.8.1 94 CSI Beta 0.6: Núcleo Aqua False 3 10,00 25-8-08 5-9-08 0 1 96 1.8.2 94 Incorporación al entorno de pruebas False 3 5,00 3-6-09 9-6-09 3-6-09 4 1 97 1.8.3 94 Carga de datos False 3 5,00 10-6-09 16-6-09 25-5-09 4 1 98 1.8.4 94 Pruebas de integración Beta 0.6 False 3 20,00 8-7-09 4-8-09 4-8-09 6 1 99 1.8.5 94 Elaboración de manuales de usuario False 3 20,00 22-5-09 18-6-09 18-6-09 6 1 100 1.8.6 94 Formación de formadores False 3 10,00 21-9-09 2-10-09 21-9-09 4 1 101 1.8.7 94 Front End Formación de usuarios False 3 40,00 1-7-09 25-8-09 1-7-09 4 1 102 1.8.8 94 IAS Pruebas de integración Release Candidata 0.7 False 3 10,00 5-8-09 18-8-09 0 1 103 1.8.9 94 Pruebas de integración Versión 1.0 False 3 22,00 19-8-09 17-9-09 18-3-08 4 1 104 1.8.10 94 Pruebas de aceptación Versión 1.0 False 3 45,00 18-9-09 19-11-09 30-9-09 6 1 105 1.8.11 94 Presentación y aprobación del sistema False 3 0 19-11-09 19-11-09 15-10-09 6 Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 293 Figura. IV.10. Tabla Msp_Links (AQUA-WS) Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 294 Tabla. IV.2. Tabla SQL*Server Msp_Tasks (AQUA-WS) LINK_ UID LINK_PRE D_UID LINK_SUCC_ UID LINK_TYPE LINK _LAG 1 94 2 0 2 3 2 3 3 4 5 1 4 5 6 1 5 6 7 1 6 7 8 1 7 8 9 1 8 9 10 1 9 3 11 3 5,00 10 12 13 1 11 13 14 1 12 14 15 1 13 15 16 1 14 16 17 1 15 18 19 1 16 18 20 1 17 21 22 1 18 17 25 1 19 24 26 1 20 20 27 1 21 27 28 1 22 22 29 1 23 29 30 1 24 30 31 1 25 31 32 1 26 16 33 1 Tabla. IV.2. Tabla SQL*Server Msp_Tasks (AQUA-WS) LINK_ UID LINK_PRE D_UID LINK_SUCC_ UID LINK_TYPE LINK _LAG 27 23 33 1 28 25 34 1 29 26 35 1 30 33 35 1 31 35 36 1 32 27 37 1 33 29 38 1 34 32 39 1 35 11 40 3 30,00 36 51 44 1 37 44 45 1 38 41 46 1 39 41 47 1 40 42 47 1 41 43 48 1 42 47 48 1 43 48 49 1 44 49 50 1 45 46 51 1 46 51 52 1 47 48 53 1 48 49 54 1 49 50 55 1 50 40 56 3 30,00 51 57 58 1 -15,00 52 58 59 1 -20,00 Tabla. IV.2. Tabla SQL*Server Msp_Tasks (AQUA-WS) LINK_ UID LINK_PRE D_UID LINK_SUCC_ UID LINK_TYPE LINK _LAG 53 59 60 1 54 56 61 3 30,00 55 62 63 1 56 64 66 1 57 65 66 1 58 66 67 1 59 71 67 1 60 67 68 1 61 68 69 1 62 64 70 1 63 65 71 1 64 67 72 1 65 50 73 1 66 73 74 1 67 75 76 1 68 72 77 1 69 77 78 1 70 74 79 1 71 61 80 3 30,00 72 66 81 1 73 71 82 1 74 74 83 1 75 83 84 1 76 81 85 1 77 82 86 1 78 84 87 1 Parte V. Anexos Anexo IV: Proyecto AQUA-WS Tesis doctoral – cam 295 Tabla. IV.2. Tabla SQL*Server Msp_Tasks (AQUA-WS) LINK_ UID LINK_PRE D_UID LINK_SUCC_ UID LINK_TYPE LINK _LAG 79 86 87 1 80 87 88 1 81 86 90 1 82 89 91 1 83 87 92 1 84 88 93 1 85 80 94 3 30,00 86 91 95 1 87 95 96 1 88 96 97 1 89 97 98 1 90 98 102 1 91 102 103 1 92 103 104 1 93 104 105 1 Anexo V: Publicaciones y Proyectos Parte V. Anexos ORCID 0000-0002-5050-3664 302 Tesis doctoral – cam Publicaciones en revistas internacionales Gómez-López, M. T., Gasca, R. M., & Arévalo Maldonado, C. (2010). A survey using constraints to decision-making for fault tolerance in Business processes. International Journal of Software Engineering and Its Applications, 4(4), 79-92. Abstract Sometimes the business processes do not work how it is expected. In these cases, a diagnosis process has to be executed to determine the responsible activity or activities of the fault in order to substitute it or them for a correct activity. The aim of this paper is describe the necessary steps to find out another service that can replace it in an efficient way. In order to automate the search and substitution of activities, we propose to describe the functionality of the tasks using constraints, making easier the determination of the possible activities that could substitute everyone faulty activities in the business process. In this paper, it is also analyzed how to adapt the communication protocol with XML messages to a behavior described using constraints. Keywords Business Process, Fault tolerance, Constraint Satisfaction Problem. Parte V. Anexos Anexo V: Publicaciones y Proyectos ORCID 0000-0002-5050-3664 Tesis doctoral – cam 303 C. Arevalo, M.J. Escalona, I. Ramos and M. Domínguez-Muñoz (2015): “A metamodel to integrate business processes time perspective in BPMN 2.0”. In Elsevier Information and software technology (IST). Manuscrit number INFSOF-D-15-00235 (En revisión). Abstract Context: Business Process Management (BPM) is becoming a strategic advantage for organizations to streamline their operations. Most business experts are betting for OMG Business Process Model and Notation (BPMN) as de-facto standard (ISO/IEC 19510:2013) and selected technology to model processes. The temporal dimension underlies in any kind of process however, technicians need to shape this perspective that must also coexist with task control flow aspects, as well as resource and case perspectives. BPMN poorly gathers temporary rules. This is why there are contributions that extend the standard to cover such dimension. BPMN is mainly an imperative language. There are research contributions showing time constraints in BPMN, such as (i) BPMN patterns to express each rule with a combination of artifacts, thus these approaches increase the use of imperative BPMN style, and (ii) new decorators to capture time rules semantics giving clearer and simpler comprehensible specifications. Nevertheless, these extensions cannot yet be found in the present standard. Objective: To define a time rule taxonomy easily found in most business processes and look for an approach that applies each rule with current BPMN 2.0 standard in a declarative way. Method: A model-driven approach is used to propose a BPMN metamodel extension to address time-perspective. Results: We look at a declarative approach where new time specifications may overlie the main control flow of a BPMN process. This proposal is totally supported with current BPMN standard, giving a BPMN metamodel extension with OCL constraints. We also use AQUA-WS as a software project case study which is planned and managed with MS Project. We illustrate business process extraction from project plans. Conclusion: This paper suggests to handle business temporal rules with current BPMN standard, along with other business perspectives like resources and cases. This approach can be applied to reverse engineering processes from legacy databases. Keywords BPM, BPMN, Time perspective, Metamodel, OCL, MDE, Legacy system Anexo V: Publicaciones y Proyectos Parte V. Anexos ORCID 0000-0002-5050-3664 304 Tesis doctoral – cam M. Domínguez-Muñoz, M.J. Escalona, I. Ramos, and C. Arevalo. (2015): “Systematic Literature Review for Web Application Estimation with Use Case Points. Looking for a Model-Driven Perspective”. Springer, Software Quality Journal, Submision. Manuscrit number SQJO-S-15-00125, (En revisión). Abstract Context: Software effort estimation has always been a matter of interest for companies since they need to carry out their projects on time and budget. In contrast, Web Applications development could be different to regular Software development as Web Application effort estimations might need different techniques and measures. Objective: This paper aims to analyse how Use Case Points (UCP) technique is used in real Web Application effort estimation and evaluate whether the research community is applying new tendencies, like the Model-Driven paradigm. Method: A Systematic Literature Review (SLR) process has been executed to revise the current situation for UCP usage in Web Applications effort estimations as well as the use of Model-Driven Engineering (MDE) techniques. Results: The SLR compiles a large number of studies about effort estimation using UCP, some studies regarding Web Application and few works related to MDE-based techniques or enterprise uses. Conclusion: UCP does not usually fit Web Application effort estimation approaches properly, although it is one of the most popular effort estimation techniques, therefore, it is not applied to enterprises. The lack of related studies reveals that effort estimation in Web Applications using UCP constitutes a real gap the research community is not currently filling in. Keywords Effort Estimation, Use Case Points, Web Application, Model-Driven Engineering, Systematic Literature Review. Parte V. Anexos Anexo V: Publicaciones y Proyectos ORCID 0000-0002-5050-3664 Tesis doctoral – cam 305 Publicaciones en conferencias internacionales Arevalo, C., Ramos, I. and M.J. Escalona (2015). “Discovering Business Models for Software Process Management An Approach for Integrating Time and Resource Perspectives from Legacy Information Systems”. In 17th International Conference on Enterprise Information Systems (ICEIS 2015), Barcelona. Paper Nr.271. Abstract Business Process Management (BPM) is becoming the modern core to support business in all type of organizations and software business is not a n exception. Software companies are often involved in important and complex collaborative projects carried out by many stakeholders. Each actor (customers, suppliers or government instances, among others) works with individual and shared processes. Everyone needs dynamic and evolving approaches for managing their software projects lifecycle. Nevertheless, many companies still use systems that are out of the scope of BPM for planning and control projects and managing enterprise content (Enterprise Content Management, ECM) as well as all kinds of resources (ERP). Somehow systems include scattered artifacts that are related to BPM perspectives: control and data flow, time, resource and case, for example. It is aimed to get interoperable BPM models from these classical Legacy Information Systems (LIS). Model-Driven Engineering (MDE) allows going from application code to higher-level of abstraction models. Particularly, there are standards and proposals for reverse engineering LIS. This paper illustrates LIS cases for software project planning and ECM, looking at time and resource perspectives. To conclude, we will propose a MDE-based approach for taking out business models in the context of software process management. Keywords Software Process Management, BPMN, Interoperability, Legacy Systems, Reverse Engineering, Model-Driven Engineering. Anexo V: Publicaciones y Proyectos Parte V. Anexos ORCID 0000-0002-5050-3664 306 Tesis doctoral – cam Publicaciones en conferencias nacionales Arévalo, C. (2014). “Extracting Business Models for Software Process Support”. Ed. Riquelme, J., Ruiz, M., & García, M. T. Actas JISBD, SISTEDES, Doctoral Consortium., Cádiz, 2014, pp.40-47. Abstract Organizations oriented to software business have similar problems to other pro-ductive organizations; they are subject to globalization, competitiveness and they also need dynamic and evolutionary computer-aided software tools for managing life cycle of their projects that may quickly adapt to complex and changing envi-ronments. They also use the BPM (Business Process Management) approach for definition and execution of their own business process based on BPMN (Busi-ness Process Model Notation) language. A business expert, within these com-plex organizations, manages knowledge that lies in these multiple and heteroge-neous automated tools, distributed all over the world, each one with different lan-guages and data structures that usually are relational databases. Model Driven Engineering (MDE) paradigm and several standards of the Object Management Group (OMG) based on the Model Driven Architecture (MDA) together with other research works offer concepts, metamodels and methods for software re-verse engineering going from application code and data structures to models of higher level of abstraction nearest to the business expert level. We will look for proposals to discover this knowledge, gathering artifacts that lie in relational da-tabases such as table structures, constraints and hardcoded triggers. The desired result must be a global data business view of the whole organization containing common and essential data structures (business models, business pro-cesses structures, resources involved and metrics for processes, etc.). This global view must have a high level of independency from every used computer-aided tool. It will also allow extracting global reports and efficient migrations between pairs of these tools and it will be more stable along time. Keywords Software Process Support, Legacy System, Model Driven Architecture (MDA), Architecture-Driven Modernization (ADM), SQL, Trigger, Interoperability. Parte V. Anexos Anexo V: Publicaciones y Proyectos ORCID 0000-0002-5050-3664 Tesis doctoral – cam 307 Proyectos Proyectos de investigación [P08-Tic-04095] "Opbus: Mejora De La Calidad De Procesos De Negocio Mediante Tecnologías De La Optimización y tolerancia a fallos”. Información del proyecto Responsable: Rafael Martínez Gasca Tipo de proyecto: Proyectos de Excelencia de la Junta de Andalucía Referencia: TIN2010-20057-C03-02 Fecha de comienzo: 13-1-2009 Fecha de finalización: 31-7-2011 Financiado por Junta de Andalucía (Consejería de Innovación, Ciencia y Empresas) [TIN2010-20057-C03-02] “Testing temprano y modelos de simulación híbrida en la producción de software. Tempros”. Información del proyecto Responsable: María José Escalona Cuaresma Tipo de proyecto: Plan Nacional del 2010 Referencia: TIN2010-20057-C03-02 Fecha de comienzo: 01-01-2011 Fecha de finalización: 31-12-2013 Financiado por Ministerio de Ciencia e Innovación [TIN2013-46928-C3-3-R] "Mecanismos Guiados En Etapas Tempranas Para La Mejora Del Software. Megus". Información del proyecto Responsable: María José Escalona Cuaresma Tipo de proyecto: Programa Estatal de Fomento de la Investigación Científica y Técnica de Retos. Referencia: TIN2013-46928-C3-3-R Fecha de comienzo: 01-01-2014 Fecha de finalización: 31-12-2016 Financiado por Ministerio de Economía y Competitividad Anexo V: Publicaciones y Proyectos Parte V. Anexos ORCID 0000-0002-5050-3664 308 Tesis doctoral – cam Proyectos de transferencia tecnológica [P047-14/E09] “Proyecto EMPOWER". Información del proyecto Responsable: María José Escalona Cuaresma; García-García, Julián Alberto Tipo de proyecto: Contrato art. 11/45 LRU - 68/83 LOU. Referencia: P047-14/E09 Fecha de comienzo: 01-03-2015 Fecha de finalización: 31/12/2016 Financiado por CDTI / CTA Parte V. Anexos Anexo V: Publicaciones y Proyectos ORCID 0000-0002-5050-3664 Tesis doctoral – cam 309 Redes nacionales [TIN2015-71938-REDT] "Red Temática para el desarrollo de soluciones software de calidad en entornos PLM". Información del proyecto Responsable: María José Escalona Cuaresma Tipo de proyecto: Plan Estatal 2013-2016 Excelencia - Redes. Referencia: TIN2015-71938-REDT Fecha de comienzo: 01-12-2014 Fecha de finalización: 31-12-2016 Financiado por Ministerio de Economía y Competitividad Anexo V: Publicaciones y Proyectos Parte V. Anexos ORCID 0000-0002-5050-3664 310 Tesis doctoral – cam Redes internacionales 000000000244467] "Red Temática Mexicana En Ingeniería Del Software". Información del proyecto Responsable: María José Escalona Cuaresma Tipo de proyecto: Registro y Estructuración de Redes Temáticas CONACYT 2014. Referencia: TIN2013-46928-C3-3-R Fecha de comienzo: 01-12-2014 Fecha de finalización: Financiado por Consejo Nacional De Ciencia Y Tecnologia (Conacyt). Mexico