TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Luis Angel Chi... · IDentification), por lo tanto,...

Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Transformación entre un Enfoque de Modelado de Negocios Basado en i* y un Lenguaje Visual de Dominio Específico

Presentada por

Luis Ángel Chi Islas Lic. en Informática por el I. T. de Chetumal

como requisito para la obtención del grado de: Maestría en Ciencias en Ciencias de la Computación

Director de tesis: Dr. Máximo López Sánchez

Co-Director de tesis: Dra. Alicia Martínez Rebollar

Jurado:

MC. Juan Gabriel González Serna – Presidente Dr. Azucena Montes Rendón – Secretario

Dr. Hugo Estrada Esquivel – Vocal Dr. Máximo López Sánchez – Vocal Suplente

Cuernavaca, Morelos, México. 08 de Noviembre de 2012

Agradecimientos

Antes que nada quiero agradecer a las personas que con su ayuda han colaborado en la realización del presente trabajo, en especial al Dr. Máximo López Sánchez, director de esta tesis, por la orientación y la supervisión continua de la misma, pero sobre todo por la motivación y el apoyo recibido. Su confianza en mi trabajo y su habilidad para guiar mis ideas han sido un aporte invaluable, no sólo en el desarrollo de esta tesis, sino también en mi formación como investigador.

Quiero expresar también un especial agradecimiento a la Dra. Alicia Martínez Rebollar, co-directora de esta tesis, por su importante aporte y participación en el desarrollo de este trabajo, no cabe duda que su participación ha enriquecido el

trabajo realizado.

Quiero agradecer a mis revisores de tesis, Dr. Hugo Estrada Esquivel, Dr. Juan Gabriel González Serna y Dra. Azucena Montes Rendón, quienes me brindaron consejos y sugerencias para el desarrollo de esta tesis.

Debo agradecer al Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET) por haberme dado la oportunidad de realizar mis estudios de maestría. También agradezco al Consejo Nacional de Ciencia y Tecnología (CONACYT) por el apoyo económico brindado en mis estudios.

Agradezco a mis compañeros que me apoyaron y con los cuales compartí gratas experiencias que hicieron agradable mi estancia en Cuernavaca.

Finalmente, pero no menos importante, quiero agradecer a mi familia por el apoyo brindado durante mis estudios, animándome siempre a superarme y dar lo mejor de mí.

Resumen

La elicitación de requisitos de software ha sido un elemento importante en el desarrollo de sistemas, ya que proporciona información relevante para los analistas y desarrolladores. En la mayoría de los casos un buen entendimiento de los requisitos determina el éxito de un sistema.

En la actualidad existen trabajos que se encargan de obtener requisitos a través de modelos de procesos de negocios, los cuales son utilizados en el desarrollo de software bajo un enfoque MDD (Model Driven Development), con el objetivo de mejorar la calidad de los modelos utilizados en el desarrollo de sistemas.

Esta tesis vincula, mediante un método de transformación, un modelo de negocios basado en i* y un modelo conceptual para ambientes inteligentes. El

modelo conceptual para ambientes inteligentes pretende ser utilizado para generar código de sistemas de ambientes inteligentes RFID (Radio Frequency IDentification), por lo tanto, vincularlo con el modelo de negocios basado en i* ahorraría tiempo considerable al generar sistemas de ambientes inteligentes para las organizaciones, además de sistemas de información más adaptados a las necesidades de la organización utilizando un enfoque MDD.

Para el desarrollo del método de transformación se analizaron los meta-modelos de ambos modelos involucrados, con la finalidad de conocer la estructura y características de los elementos que los conforman. Mediante el análisis se identificaron los elementos equivalentes entre los meta-modelos, esto dio lugar a un conjunto de directrices que componen al método de transformación. El método es implementado en una herramienta la cual guía al usuario durante el proceso de transformación.

Abstract

The software requirement elicitation has been a relevant element in system development, since it provides important information to developers and analysts. In most cases a good understanding of the requirements determine the success of a system.

Nowadays there are works that obtain requirements through process business models, which are used in software development under a MDD (Model Driven Development) approach with the goal to improve the quality of the models used in the system development.

This thesis links, by means of a transformation method, a business model based on i* and a conceptual model for intelligent environments. The conceptual model for intelligent environments is intended to be used to generate ambient intelligent

RFID (Radio Frequency IDentification) system code; therefore to link the conceptual model with the business model based on i* would save considerable time when generate ambient intelligent systems for the organizations, as well as information systems more adapted to the needs of the organization using a MDD approach.

For the development of the transformation method, the meta-models of both involved models were analyzed in order to know the characteristics and structure of the elements that constitute the meta-models. The equivalent elements between the meta-models were identified through the analysis, this resulted in a set of guidelines that compose the transformation method. The method is implemented in a tool which guides the user during the transformation process.

Tabla de contenido

INTRODUCCIÓN ................................................................................................................................... 1

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN ............................................................................. 3

1.1 Planteamiento del problema .................................................................................................... 3

1.2 Objetivo ..................................................................................................................................... 4

1.3 Justificación ............................................................................................................................... 4

1.4 Diseño de la investigación ......................................................................................................... 5

1.5 Alcances y limitaciones ............................................................................................................. 7

CAPÍTULO 2. MARCO TEÓRICO............................................................................................................ 8

2.1 Modelado conceptual ............................................................................................................... 8

2.2 Modelado de negocios .............................................................................................................. 9

2.2.1 El framework de modelado i* ............................................................................................ 9

2.3 Lenguaje Visual de Dominio Específico (DSVL) ......................................................................... 9

2.4 Desarrollo Dirigido por Modelos (MDD) ................................................................................. 10

2.4.1 Arquitectura Dirigida por Modelos (MDA) ....................................................................... 10

2.4.2 Transformación de modelos ............................................................................................ 10

2.4.3 Lenguajes de transformación de modelos ....................................................................... 10

2.5 Meta-modelo........................................................................................................................... 11

2.6 Extensión Gráfica de la Forma Backus–Naur .......................................................................... 11

CAPÍTULO 3. ESTADO DEL ARTE ........................................................................................................ 12

3.1 Transformation of a Process Business Model to Domain Model ........................................ 12

3.2 From i* Requirements Models to Conceptual Models of a Model Driven Development

Process ...................................................................................................................................... 12

3.3 Towards Use Case and Conceptual Models Through Business Modeling ........................... 12

3.4 Conceptual Schema Generation from Organizational Models in an Automatic Software

Production Process .................................................................................................................... 13

3.5 Integrating Use Cases and Organizational Modeling .......................................................... 13

3.6 From Activity Diagrams to Class Diagrams .......................................................................... 13

3.7 Towards Obtaining Analysis-Level Class and Use Case Diagrams from Business Process

Models ....................................................................................................................................... 14

3.8 A Guideline to Mapping Business Processes to UML Class Diagrams ................................. 14

3.9 An algorithm to derive use cases from business process ................................................... 14

3.10 Model Transformation with Triple Graph Grammars ....................................................... 14

3.11 ATL: a Model Transformation Tool.................................................................................... 14

3.12 Applying CIM-to-PIM model transformations for the service-oriented development of

information systems .................................................................................................................. 15

3.13 Model Interoperability via Model Driven Development ................................................... 15

3.14 Model Transformation from VisualOCL to OCL using Graph Transformation .................. 15

CAPÍTULO 4. MÉTODO DE SOLUCIÓN ............................................................................................... 18

4.1 Análisis de meta-modelos ....................................................................................................... 19

4.1.1 Meta-modelo i* extendido .............................................................................................. 19

4.1.2 Meta-modelo DSVL .......................................................................................................... 24

4.2 Comparación entre elementos de los meta-modelos ............................................................. 25

4.3 Método de transformación ..................................................................................................... 33

4.3.1 Paso 1: identificación de usuarios .................................................................................... 34

4.3.2 Paso 2: Definición del contexto de los usuarios ............................................................... 35

4.3.3 Paso 3: Identificación de actividades para los usuarios ................................................... 36

4.3.4 Paso 4: Identificación de documentos para los usuarios ................................................. 37

4.3.5 Paso 5: Relaciones entre actividades y documentos ....................................................... 38

4.4 Archivos XML ........................................................................................................................... 40

4.4.1 Adición de etiquetas para módulos tecnológicos a IStarML ............................................ 40

4.4.2 Creación del XML para la sintaxis concreta del DSVL (Hernández, 2010) ........................ 43

4.5 Herramienta de transformación ............................................................................................. 44

4.5.1 Proceso general de ejecución .......................................................................................... 45

4.5.2 Funcionamiento de la herramienta de transformación ................................................... 45

CAPÍTULO 5. PRUEBAS....................................................................................................................... 54

5.1 Plan de pruebas ....................................................................................................................... 54

5.1.1 Introducción ..................................................................................................................... 54

5.1.2 Elementos de prueba ....................................................................................................... 54

5.1.3 Características probadas .................................................................................................. 54

5.1.4 Características excluidas .................................................................................................. 55

5.1.5 Enfoque ............................................................................................................................ 55

5.1.6 Criterio éxito/fracaso de los casos de prueba .................................................................. 55

5.1.7 Criterios de suspensión y requerimientos de reanudación ............................................. 56

5.1.8 Documentos entregables de las pruebas ......................................................................... 56

5.1.9 Tareas de pruebas ............................................................................................................ 56

5.1.10 Requerimientos para realizar las pruebas ...................................................................... 56

5.1.11 Responsabilidades .......................................................................................................... 57

5.1.12 Riesgos y contingencias .................................................................................................. 57

5.1.13 Aprobación ..................................................................................................................... 57

5.2 Casos de prueba ...................................................................................................................... 57

5.2.1 Identificación de usuarios ................................................................................................ 57

5.2.2 Definición del contexto de los usuarios ........................................................................... 57

5.2.3 Identificación de actividades para los usuarios ................................................................ 57

5.2.4 Identificación de documentos para los usuarios ............................................................. 57

5.2.5 Relaciones entre actividades y documentos .................................................................... 58

5.3 Especificación de casos de prueba .......................................................................................... 58

5.4 Especificación del procedimiento de prueba .......................................................................... 61

5.4.1 Identificación de usuarios ................................................................................................ 61

5.4.2 Definición del contexto de los usuarios ........................................................................... 61

5.4.3 Identificación de actividades para los usuarios ................................................................ 62

5.4.4 Identificación de documentos para los usuarios ............................................................. 62

5.4.5 Relaciones entre actividades y documentos .................................................................... 63

5.5 Resultados del plan de pruebas .............................................................................................. 63

5.5.1 Modelo de integración de protocolo, creado con los escenarios descritos para el

lenguaje visual de dominio específico (Hernández, 2010) ........................................................ 63

5.5.2 Modelo de integración de protocolo, traducción de un modelo negocios encontrado en

tesis doctoral (Yu, 1995) ............................................................................................................ 75

5.6 Análisis de resultados .............................................................................................................. 82

CAPÍTULO 6. CONCLUSIONES ............................................................................................................ 83

6.1 Conclusiones............................................................................................................................ 83

6.1.1 Contribuciones ................................................................................................................. 84

6.2 Publicaciones ........................................................................................................................... 85

6.3 Trabajos futuros ...................................................................................................................... 85

Anexo A ............................................................................................................................................. 86

Anexo B ............................................................................................................................................. 86

Anexo C ............................................................................................................................................. 89

Anexo D ............................................................................................................................................. 91

Anexo E .............................................................................................................................................. 92

REFERENCIAS ..................................................................................................................................... 94

Lista de figuras

Figura 1.1. Procesos del desarrollo de la investigación. ..................................................................... 5

Figura 4.1. Actividades de los procesos del desarrollo de la investigación. ..................................... 19

Figura 4.2. Meta-modelo i* extendido (Morales, 2010). .................................................................. 20

Figura 4.3. Meta-modelo de i* (Morales, 2010). .............................................................................. 21

Figura 4.4. Meta-modelo DSVL (Hernández, 2010). ......................................................................... 24

Figura 4.5. Actores anidados con Boundary...................................................................................... 27

Figura 4.6. Modelo de integración del protocolo de recolección de información de inventario

(Morales, 2010). ................................................................................................................................ 32

Figura 4.7. Pasos para realizar la transformación entre el modelo de integración de protocolo

(Morales, 2010) y la sintaxis concreta (Hernández, 2010). ............................................................... 34

Figura 4.8. Identificación de usuarios aplicando el método de transformación. ............................. 35

Figura 4.9. Definición de contextos aplicando el método de transformación. ................................. 35

Figura 4.10. Identificación de actividades aplicando el método de transformación. ....................... 36

Figura 4.11. Identificación de actividades en dependencias aplicando el método de

transformación. ................................................................................................................................. 37

Figura 4.12. Identificación de documentos aplicando el método de transformación. ..................... 37

Figura 4.13. Identificación de documentos en dependencias aplicando el método de

transformación. ................................................................................................................................. 38

Figura 4.14. Identificación de relaciones aplicando el método de transformación. ......................... 39

Figura 4.15. Identificación de relaciones de documentos en dependencias aplicando el método de

transformación. ................................................................................................................................. 39

Figura 4.16. Identificación de relaciones en documentos aplicando el método de transformación.

........................................................................................................................................................... 40

Figura 4.18. Representación en XML de un modelo de integración de protocolo (Morales, 2010). 42

Figura 4.17. Representación en XML de un modelo creado con la sintaxis concreta (Hernández,

2010). ................................................................................................................................................ 44

Figura 4.19. Herramienta de transformación. .................................................................................. 45

Figura 4.20. Abrir archivo XML con la herramienta de transformación. .......................................... 46

Figura 4.21. Agregar contextos con la herramienta de transformación. .......................................... 47

Figura 4.22. Asignar contextos a los actores con la herramienta de transformación. ..................... 48

Figura 4.23. Eliminar actores, tareas y recursos con la herramienta de transformación. ............... 49

Figura 4.24. Pestaña de usuarios, actividades y documentos de la herramienta de transformación.

........................................................................................................................................................... 50

Figura 4.25. Asignar id's a actividades con la herramienta de transformación. ............................... 51

Figura 4.26. Ejemplo de id's asignados a las actividades con la herramienta de transformación. ... 51

Figura 4.27. Asignar documentos a actividades con la herramienta de transformación. ................ 52

Figura 4.28. Ejemplo de documentos asignados a actividades con la herramienta de

transformación. ................................................................................................................................. 52

Figura 4.29. Generar archivo XML con la herramienta de transformación. ..................................... 53

Figura 5.1. Modelo de integración de protocolo creado con los escenarios descritos para el

lenguaje visual de dominio específico (Hernández, 2010) ................................................................ 59

Figura 5.2. Modelo de negocios traducido (Yu, 1995). ..................................................................... 60

Figura 5.3. Resultado obtenido al aplicar el paso uno del método de transformación a la figura 5.1.

........................................................................................................................................................... 64

Figura 5.4. Resultado obtenido al aplicar el paso dos del método de transformación a la figura 5.1.

........................................................................................................................................................... 66

Figura 5.5. Resultado obtenido al aplicar el paso tres del método de transformación a la figura 5.1.

........................................................................................................................................................... 69

Figura 5.6. Resultado obtenido al aplicar el paso cuatro del método de transformación a la figura

5.1. ..................................................................................................................................................... 71

Figura 5.7. Resultado obtenido al aplicar el paso cinco del método de transformación a la figura

5.1. ..................................................................................................................................................... 75

Figura 5.8. Resultado obtenido al aplicar el paso uno del método de transformación a la figura 5.2.

........................................................................................................................................................... 76

Figura 5.9. Resultado obtenido al aplicar el paso dos del método de transformación a la figura 5.2.

........................................................................................................................................................... 77

Figura 5.10. Resultado obtenido al aplicar el paso tres del método de transformación a la figura

5.2. ..................................................................................................................................................... 78


5.2. ..................................................................................................................................................... 81

Lista de tablas

Tabla 3.1. Comparativa de trabajos .................................................................................................. 16

Tabla 4.1. Descripción de elementos del meta-modelo i* extendido. ............................................. 22

Tabla 4.2. Descripción de elementos del meta-modelo DSVL (Hernández, 2010). .......................... 25

Tabla 4.3. Descripción de relaciones del meta-modelo DSVL (Hernández, 2010). ........................... 25

Tabla 4.4. Comparativa de elementos entre el meta-modelo i* extendido (Morales, 2010) y el

meta-modelo DSVL (Hernández, 2010). ............................................................................................ 26

Tabla 4.5. Comparativa de relaciones entre el meta-modelo i* extendido (Morales, 2010) y el

meta-modelo DSVL (Hernández, 2010). ............................................................................................ 28

Tabla 4.7. Etiquetas XML para el modelo de integración de protocolo. ........................................... 41

Tabla 4.6. Etiquetas XML para la sintaxis concreta del DSVL. ........................................................... 43

Tabla 5.1. Tareas del plan de pruebas. .............................................................................................. 56

Introducción

1

INTRODUCCIÓN

La elicitación de requisitos es un elemento importante en el desarrollo de sistemas de información, ya que proporciona información relevante para los analistas y desarrolladores. En la mayoría de los casos un buen entendimiento de los requisitos determina el éxito de un sistema (Alencar, 2009).

Generalmente los requisitos son obtenidos a partir de los usuarios utilizando diversas técnicas tales como entrevistas, encuestas o lluvia de ideas; sin embargo los usuarios muchas veces no son la fuente más confiable (Suarez, 2008). Los requisitos pueden ser divididos en dos categorías; requisitos tempranos, que son aquellos que están enfocados en el entendimiento de un problema mediante el estudio del contexto organizacional y, los requisitos tardíos, en los cuales el sistema de software es descrito dentro de su ambiente operacional.

En la actualidad existe una gran diversidad de modelos de representación, estos tienen como propósito tener una vista del mundo real, ya sea de manera gráfica, simbólica o narrativa. El Desarrollo Dirigido por Modelos es un paradigma que utiliza modelos como principal elemento de desarrollo, éstos modelos son transformados de manera automática o semiautomática en código. La transformación de modelos nos permite obtener la equivalencia entre modelos o tomar información relevante de un modelo y transformarlo en otro, lo cual puede ayudar a extender una solución y poder resolver problemas más complejos.

Existen trabajos que utilizan modelos de negocios que incluyen requisitos tempranos y los transforman a modelos conceptuales enfocados a representar requisitos tardíos (Alencar, F., Marín, B., Giachetti, G., Pastor, O., Castro, J. & Henrique Pimentel J., 2009) (Martínez, 2008).

Este trabajo de tesis propone un método de transformación entre un modelo de negocios basado en i*, del cual se pueden obtener requisitos tempranos y un modelo conceptual para ambientes inteligentes que representa los requisitos tardíos, con el cual se pretende desarrollar sistemas para ambientes inteligentes más adaptados a las necesidades de la organización.

Organización del documento

La organización del presente documento de tesis se describe a continuación:

En el capítulo 1 se presenta la descripción de la investigación, la cual se compone del planteamiento del problema; el objetivo perseguido; la justificación de este trabajo y por último los alcances y limitaciones considerados para el desarrollo de esta investigación.

En el capítulo 2 se presenta el marco teórico, en el cual se describen los conceptos necesarios para la comprensión de esta tesis, tal como modelado de negocios, Desarrollo Dirigido por Modelos, transformación de modelos, entre otros.

Introducción

2

El capítulo 3 presenta el estudio realizado sobre el estado del arte en métodos, lenguajes y herramientas de transformación de modelos de negocios a modelos conceptuales.

El capítulo 4 aborda el método de solución desarrollado en esta tesis, describiendo cada una de las actividades realizadas para cumplir con los objetivos de esta tesis.

El capítulo 5 presenta las pruebas realizadas al método de transformación definido en esta tesis y los resultados obtenidos en ellas.

Por último en el capítulo 6 se presentan las conclusiones obtenidas con la evaluación de este trabajo las contribuciones realizadas, las publicaciones producidas y los trabajos futuros.

Capítulo 1. Descripción de la investigación

3

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN

Este capítulo presenta el contexto de este trabajo de tesis. La sección 1.1 presenta la descripción del problema, la sección 1.2 describe el objetivo principal de esta tesis y los objetivos específicos identificados para alcanzar el objetivo principal, la sección 1.3 se presenta la justificación. En la sección 1.4 se describe el diseño de la investigación utilizada y finalmente la sección 1.5 presenta los alcances y limitaciones considerados para esta tesis.

1.1 Planteamiento del problema

Hoy en día existen muchos trabajos de modelado que se enfocan en la representación de los requisitos tempranos (Estrada, 2008) (Santillán, 2011) [BPMI2011] y los requisitos tardíos (Hernández, 2010) (Pastor, O., Gómez, J., Insfran, E. & Pelechano V., 2001), sin embargo, no en todos los casos existe una capa intermedia que permita vincular estas dos fases. En otros casos no se contemplan las nuevas tecnologías de información, tanto en los modelos que representan requisitos tempranos como en los modelos que representan requisitos tardíos.

Actualmente en el “Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)” se está trabajando con la creación de un método de modelado organizacional enfocado a nuevas tecnologías de información (Santillán, 2011), el cual hace uso del lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010). Adicionalmente existe otro trabajo el cual se enfoca en la creación de un lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010). Ambos trabajos de modelado atienden diferentes niveles de abstracción, por lo tanto vincular el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010) y lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010) supondría un ahorro de tiempo en el desarrollo de sistemas de ambientes inteligentes para las organizaciones, además estos sistemas estarían más adaptados para apoyar a los usuarios que intervienen en esos procesos.

En los trabajos (Martínez, 2008) y (Alencar et al, 2008) se presenta una metodología que permite vincular la fase de requisitos tempranos y la fase de

requisitos tardíos mediante una transformación de modelos, no obstante, realizar una transformación de modelos en la cual intervienen uno o más modelos de entrada y se producen uno o más modelos de salida demanda un gran entendimiento de la sintaxis y semántica utilizada en todos los modelos involucrados (Sendall, S. &Kozaczynski, W., 2003). El modelo conceptual producto de la transformación de modelos definido en los trabajos (Martínez, 2008) y (Alencar et al, 2008) es utilizado en otro proceso para generar sistemas de información. A pesar de haber obtenido buenos resultados, los modelos involucrados carecen de primitivas para representar las nuevas tecnologías de información. Se considera que debido al impacto que tienen las tecnologías en los


4

procesos de negocio de una organización, es necesario representar esas tecnologías en etapas tempranas del proceso de desarrollo de sistemas de información (Santillán, 2011). El objetivo de la representación de esas tecnologías es obtener una vista completa de la organización, que represente en forma explícita la relación entre las tecnologías y los demás elementos de la organización y además, permita obtener una descripción detallada de los sistemas de información involucrados en la organización (Santillán, 2011).

Con base en lo anterior, este trabajo de tesis pretende proponer una solución al problema de la falta de un método que permita obtener un modelo de salida producto de la transformación entre el lenguaje de modelado de negocios basado en i* (Morales, 2010) y el lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes (Hernández, 2010), lo cual permitirá el desarrollo de sistemas de información para ambientes inteligentes mejor adaptados a las necesidades de la organización, debido a que se obtendrá un modelo requerimientos tardíos (modelo conceptual) a partir del modelo de negocios.

1.2 Objetivo

Definir un método que permita la transformación de un modelo de negocios i* a un modelo creado con la sintaxis concreta de un lenguaje visual de dominio específico.

Objetivos específicos

Analizar los meta-modelos del modelo de negocios basado en i* y del lenguaje visual de dominio específico.

Definir las reglas de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio específico (Hernández, 2010).

Desarrollar una aplicación software que soporte el método de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio específico (Hernández, 2010).

1.3 Justificación

Los sistemas de ambientes inteligentes son complejos de realizar, debido a que se requieren habilidades de programación de distintas especialidades, tales como: cómputo móvil, sensores, sistemas de localización (GPS, Redes, RFID), entre otras, lo cual dificulta su desarrollo para analistas y programadores no especializados (Hernández, 2010). El lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010) pretende ser utilizado para generar código de sistemas de ambientes inteligentes RFID, por lo tanto, vincular el lenguaje de modelado de negocios basado en i* (Morales, 2010) con el lenguaje visual de dominio específico para el desarrollo de ambientes


5

inteligentes supondría un ahorro de tiempo considerable a la hora de generar sistemas de ambientes inteligentes para las organizaciones, además de sistemas de información mejor adaptados a las necesidades de la organización.

1.4 Diseño de la investigación

La solución propuesta en este trabajo de tesis consiste en una serie de directrices que componen al método de transformación, las cuales son producto de un análisis y una comparación del meta-modelo de un modelo de negocios de i* extendido y del meta-modelo de un lenguaje visual de dominio específico. Además se propone un proceso semiautomático que implementa el método de transformación.

Esta investigación fue desarrollada en cinco procesos, los cuales son

agrupados en 2 fases, presentados en la figura 1.1.

Figura 1.1. Procesos del desarrollo de la investigación.

Fase 1: En esta fase se desarrolló el método de transformación que permite la generación de un modelo de sintaxis concreta a partir de un modelo de integración de protocolo. Esta fase se divide en dos procesos:


6

Proceso 1. Identificación de equivalencias entre meta-modelos

El punto de partida de esta investigación fue conocer la estructura y características de los elementos y relaciones de los meta-modelos, con la finalidad de identificar equivalencias entre ellos. El resultado de este proceso se detalla en el capítulo 4; la sección 4.1 para el análisis y la sección 4.2 para la comparativa.

Proceso 2. Desarrollo del método de transformación

Los elementos equivalentes identificados en el proceso 1 fueron utilizados en este proceso para definir las directrices que integran al método de transformación. Las directrices permiten identificar y seleccionar los elementos y relaciones que proporcionan información relevante para la transformación. Estas directrices y su aplicación se presentan en el

capítulo 4, específicamente en la sección 4.3.

Fase 2: Esta fase se centró en la transformación semiautomática de modelos, creados con los meta-modelos de la fase 1, mediante una herramienta de transformación, la cual integra el método de transformación desarrollado en la fase 1:

Proceso 3. Representación en XML de los modelos i*

Para poder tener modelos computables creados con el meta-modelo i* extendido, fue necesario extender un archivo para poder almacenar los modelos. Para lo anterior se adicionaron etiquetas XML (eXtensible Markup Language) a IStarML (Cares, 2007) para representar los módulos tecnológicos. El capítulo 4, específicamente la sección 4.4.1, describe este proceso.

Proceso 4. Representación en XML de la sintaxis concreta

Para poder tener modelos computables creados con el meta-modelo DSVL, fue necesario crear un archivo que permitiera almacenar los modelos. Para lo anterior se definieron las etiquetas y la estructura del archivo XML que permite representar tanto la sintaxis concreta como la sintaxis abstracta del DSVL. El capítulo 4, específicamente la sección 4.4.2, describe este proceso.

Proceso 5. Herramienta de transformación

Este proceso se enfocó en el desarrollo de la herramienta de

transformación que implementa el método de transformación definido en la fase 1. La herramienta toma como entrada el archivo XML de un modelo de integración de protocolo y realiza la transformación de manera semiautomática, obteniendo como resultado un modelo de sintaxis concreta en XML. Este proceso es descrito en el capítulo 4, específicamente en la sección 4.5.


7

1.5 Alcances y limitaciones

Alcances

Se analizaron los meta-modelos del modelo de negocios basado en i* y del lenguaje visual de dominio específico.

Se definieron las reglas de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio específico (Hernández, 2010).

Se desarrolló una aplicación software que soporte el método de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio específico (Hernández, 2010).

Limitaciones

No se verifica la correctitud del modelo fuente.

Únicamente se trabaja con los modelos de negocios i* creados con el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010).

Capítulo 2. Marco teórico

8

CAPÍTULO 2. MARCO TEÓRICO

En este capítulo se describen los conceptos necesarios para la clara comprensión de este trabajo. La sección 2.1 presenta una visión general del modelado conceptual, en la cual se menciona la clasificación de los elementos necesarios a modelar en la construcción de un sistema. La sección 2.2 presenta una visón general del modelado de negocios, y una descripción del marco de trabajo i*. En la sección 2.3 se define que es un lenguaje visual de dominio específico. La sección 2.4 presenta una visión general del Desarrollo Dirigido por Modelos y algunos elementos involucrados en él. La sección 2.5 define que es un meta-modelo. Por último la sección 2.6 describe de manera general el enfoque Extensión Gráfica de la Forma Backus–Naur.

2.1 Modelado conceptual

El modelado conceptual es la actividad de describir formalmente algunos aspectos físicos y sociales del mundo que nos rodea para efectos de compresión y comunicación; tales descripciones, comúnmente conocidas como esquemas conceptuales, requieren la adopción de una notación formal para capturar aspectos relevantes del mundo o en otras palabras para capturar el conocimiento sobre un tema dado (Mylopoulos, 1992). Un modelo conceptual es útil para el desarrollo de un sistema de información y para ello es necesario examinar diferentes tipos de conocimiento que necesitan ser representados durante el proceso de construcción de un sistema de información, los cuales están clasificados de la siguiente forma:

• Mundo: consta de la materia para el sistema, es decir la información que alimentará al sistema, por ejemplo: el mundo de un sistema bancario está formado por clientes, cuentas, transacciones, saldos, tasas de interés, etc.

• Sistema: Describe al propio sistema de información en detalle, el que puede ir desde una especificación de requisitos funcionales para el sistema hasta un diseño y una implementación.

• Uso: describe el medio ambiente en el que se pretende que el sistema funcione y se compone de agentes, actividades, tareas, proyectos, usuarios, interfaces de usuario (con el sistema), etc.

• Desarrolladores: describe al equipo de analistas de sistemas y programadores que participan, la metodología y decisiones de diseño junto con las justificaciones.

Este conocimiento es relevante para el desarrollo inicial del sistema así como también para el mantenimiento y uso del mismo, por lo que debe estar representado de manera integral en la construcción de sistemas de información. El reto de un modelado conceptual es dar las facilidades para esta tarea con el objetivo de obtener una representación adecuada y manejable computacionalmente, hablando que ofrezca un nuevo paradigma basado en conocimiento para el desarrollo del software (Mylopoulos, 1992).


9

2.2 Modelado de negocios

El modelado de negocios es una colección de técnicas de modelado conceptual para describir la estructura y procesos de un negocio (Loucopoulos, Kavakli, 1995). El modelado de negocios trata de describir, de manera formal, un sistema social con sus agentes, roles de trabajo, metas, responsabilidades y similares (Loucopoulos, Kavakli, 1997).

Para tener una idea más clara del modelado de negocios es necesario definir que es un modelo de negocios. En el dominio de negocios, un modelo representa un concepto de cómo funciona el negocio y por lo tanto sería inevitable incluir metas, visiones, eficiencia y otros factores importantes. Un modelo de negocios sirve como base para el modelo de sistemas de información, asegurando requerimientos consistentes y precisos en el diseño de software (Noran, 2000). Es importante conocer la diferencia entre modelo de negocios y modelo de procesos

de negocio; el modelo de negocios se centra en el intercambio de valores entre socios del negocios, mientras que el modelo de procesos de negocios se centra en aspectos operacionales y procedimentales de la comunicación del negocio, se puede decir que el modelo de negocios define el "que" y el modelo de procesos de negocio define el "como" (Belgholtz, Jayaweera, Johannesson, Wohed, 2002).

Otra definición de modelo de negocios menciona que es un arquitectura para el producto, servicio y flujos de información incluyendo una descripción de varios actores con sus roles (Timmers, 1998).

2.2.1 El framework de modelado i*

El framework i* es un lenguaje para soportar al modelado orientado a metas y el razonamiento de requerimientos (Yu, 2001). En este contexto, el framework i* es una de las técnicas de modelado organizacional mejor fundamentadas hoy en día, se enfoca en dos aspectos principales: a) la representación de las relaciones sociales e intencionales que existen entre la red de actores de un negocio. b) la representación del comportamiento interno requerido para satisfacer las dependencias entre actores. El framework i* permite describir una organización como una red de actores que tienen libertad de acción, pero que dependen de otros actores para lograr sus metas y objetivos (Estrada, 2008).

2.3 Lenguaje Visual de Dominio Específico (DSVL)

Un Lenguaje Visual de Dominio Específico, DSVL por sus siglas inglés, es un tipo de DSL (Domain Specific Language) el cual proporciona una interfaz visual de

programación. Por su parte un DSL es un lenguaje de programación o un lenguaje de especificación ejecutable que ofrece, a través de apropiadas anotaciones y abstracciones, poder expresivo enfocado, y usualmente restringido, a un dominio específico (van Deursen, A., Klint, P., Visser, J., 2000).

"Un DSVL cuenta con dos tipos de sintaxis: abstracta y concreta. La sintaxis abstracta incluye conceptos del lenguaje y sus relaciones, y la sintaxis concreta define la apariencia gráfica de los elementos de la sintaxis abstracta" (Hernández, 2010)


10

2.4 Desarrollo Dirigido por Modelos (MDD)

El Desarrollo Dirigido por Modelos, MDD por sus siglas en inglés, es simplemente la noción de que podemos construir un modelo de un sistema, el cual se puede transformar en un sistema real (Mellor, 2003) (Atkinson, 2003). MDD utiliza los modelos como artefactos primarios del proceso de producción de software. Durante el desarrollo, los pasos consisten en la transformación semiautomática de los modelos (Ameller, 2010).

2.4.1 Arquitectura Dirigida por Modelos (MDA)

La Arquitectura Dirigida por Modelos, MDA por sus siglas en inglés, es el método

MDD más popular; en este método destacan el Computational Independent Model (CIM), Platform Independent Model (PIM) y Platform Specific Model (PSM) (Ameller, 2010), (Kleppe, 2003), los cuales se describen brevemente a continuación:

CIM: especifica el modelo independiente de software utilizado para describir el sistema de negocio.

PIM: especifica un sistema de software de una forma independiente de la plataforma tecnológica elegida para su implementación.

PSM: refina el PIM para que sea especificado en la plataforma de implementación.

2.4.2 Transformación de modelos

La transformación es la generación automática de un modelo especifico a partir de un modelo fuente, de acuerdo a la definición de la transformación, para lo cual se utilizan reglas de transformación, que describen la manera en que un modelo fuente puede ser transformado a un modelo específico.

Una regla de transformación es una descripción de cómo uno o más elementos del modelo fuente van a ser transformados en uno o más elementos del modelo en específico (Kleppe et al, 2003).

2.4.3 Lenguajes de transformación de modelos

Los lenguajes de transformación de modelos sirven para especificar la sintaxis y la semántica de los modelos de transformación, y son esenciales si se quiere proporcionar soporte automático en la transformación de modelos. Existe una gran variedad de lenguajes de transformación tales como: Query View Transformation (QVT), Atlas Transformation Language (ATL), VIsual Automated model TRAnsformations (VIATRA2), entre otros (Kleppe et al, 2003).


11

2.5 Meta-modelo

Es una descripción o definición de un lenguaje bien definido en la forma de un modelo (Kepple, 2003), en el cual se encuentra definido cada elemento y las relaciones que pueden ser usadas en el modelo a construir.

2.6 Extensión Gráfica de la Forma Backus–Naur

Extensión Gráfica de la Forma Backus–Naur, GEBNF por sus siglas en inglés, es un enfoque de meta-modelado para la definición de sintaxis abstracta de lenguajes de modelado e incluye una teoría y una técnica que induce lenguajes de lógica de predicados de primer orden a partir de la sintaxis abstracta, con lo cual las restricciones de completes y consistencia en modelos gráficos pueden ser formalmente definidas para la comprobación automática (Zhu, 2006). Además la transformación de modelos puede ser especificada como un mapeo y relaciones entre la definición de la sintaxis en GEBNF y las fórmulas de lógica de predicados (Zhu, 2008).

Capítulo 3. Estado del arte

12

CAPÍTULO 3. ESTADO DEL ARTE

Este capítulo muestra algunas investigaciones enfocadas a transformar modelos de negocios en modelos conceptuales, de las cuales se identificaron ciertas características en común. Se contemplan métodos, lenguajes y herramientas de las cuales se analizaron las siguientes características:

Problema que aborda cada trabajo analizado.

Método, lenguaje o herramienta utilizada por los trabajos analizados.

Producto resultante del trabajo de investigación.

Resultado de su investigación.

3.1 Transformation of a Process Business Model to Domain Model

Este trabajo de investigación (Suarez, 2008) se centra en el problema de la elicitación de requerimientos al obtenerlos directamente de los usuarios, ya que estos tienden a no expresar bien las ideas que pueden ser de utilidad a un ingeniero de software en el desarrollo de software. Como una solución a lo anterior se presenta una metodología para realizar la transformación desde un modelo de procesos de negocio, especificado por un diagrama de actividad UML, a un modelo de dominio UML. El proceso de transformación es realizado a partir de un Modelo de Computación Independiente (CIM por sus siglas en inglés) hacia un Modelo de Plataforma Independiente (PIM), bajo el marco de trabajo MDA. El resultado de la metodología propuesta es un diagrama de dominio centrado en los procesos del negocio.

3.2 From i* Requirements Models to Conceptual Models of a Model Driven

Development Process

Este trabajo de investigación (Alencar, 2009) se enfoca en generar un modelo conceptual de OO-Method a partir de un modelo i*, como una solución a la brecha entre propuestas Goal-Oriented Requirements Engineering (GORE) y propuestas MDD. Para lo anterior propone un conjunto de directrices que generan un modelo conceptual a partir de un modelo de requerimientos i*. El modelo conceptual generado se utiliza como entrada de un proceso MDD para la generación de productos de software, el proceso MDD utilizado está basado en el enfoque OO-Method. OO-Method fue creado en la base formal de OASIS, que es un lenguaje de

especificación formal para sistemas de información orientado a objetos. Básicamente se distinguen dos componentes de modelado en OO-Method, el modelo conceptual y el modelo de ejecución (Pastor, 2001). El propósito de este trabajo es mejorar la calidad de los modelos usados en el desarrollo de sistemas de información y por consecuencia obtener mejores productos de software.

3.3 Towards Use Case and Conceptual Models Through Business Modeling

Es este trabajo de investigación (García, Ortín, Moros, Nicolás, Toval, 2000) los autores se enfocan en el problema del análisis de requerimientos utilizando


13

diagramas de casos de uso, para ello presenta una guía de modelado de requerimientos mediante diagramas de casos de uso y clases de dominio a partir de un modelo de negocios, este último basado en diagrama de actividades. Su proceso consiste en una fase para el modelado del negocio dirigida a describir los procesos del negocio de la organización, los cuales son descritos con diagramas de actividades de UML, e identificar los casos de uso para cada uno de ellos y los conceptos (clases de dominio).

3.4 Conceptual Schema Generation from Organizational Models in an Automatic

Software Production Process

Este trabajo de investigación (Martínez, 2008) se centra en la obtención de especificaciones de software a través de modelos organizacionales, para mejorar el proceso de desarrollo de software mediante un conocimiento más profundo de las actividades y metas del negocio. Propone un lenguaje de patrones para ligar los requerimientos tempranos que se encuentran en los modelos de negocios con los requerimientos tardíos que se utilizan en los modelos conceptuales y sirven para el desarrollo de software. En este trabajo se involucra el marco de trabajo Tropos y el enfoque OO-Method. El producto final de esta tesis son diagramas de casos de uso derivados del modelo de negocios Tropos, lo cual se logra mediante el enfoque MDD ONME (Olivanova Model Execution).

3.5 Integrating Use Cases and Organizational Modeling

Este trabajo de investigación (Santander, 2002) se enfoca en obtener diagramas de caso de uso a partir de un modelo de negocios basado en i*, con el propósito de mejorar el desarrollo de los casos de uso. Como una solución a lo presentado anteriormente proponen una serie de directrices que permiten la integración del marco de trabajo i* y los diagramas de casos de uso, ayudando a los ingenieros de requerimientos a desarrollar casos de uso más apegados a la organización. Este trabajo ayuda a proponer soluciones a tópicos importantes, por ejemplo cómo el sistema ayuda a cumplir las metas de la organización, por qué es necesario el sistema, cuáles son las implicaciones de las partes involucradas.

3.6 From Activity Diagrams to Class Diagrams

Este trabajo de investigación (Barros, 2000) presenta una traducción de diagramas de actividades a diagramas de clases, dado que muchas veces en un

sistema enfocado a eventos, un modelo de comportamiento, diagrama de actividades en este caso, es mejor punto de partida. Proponen un método manual para transformar diagramas de actividades a diagramas de clases y posteriormente generar código, el cual es integrado con el marco de trabajo de C++. Su método consiste en realizar la transformación mediante los meta-modelos del diagrama de actividades y el diagrama de clases. El diagrama de actividades a su vez es utilizando para generar el controlador, en base al modelo-vista-controlador, que posteriormente servirá para el marco de trabajo de C++.


14

3.7 Towards Obtaining Analysis-Level Class and Use Case Diagrams from Business

Process Models

Este trabajo de investigación (Rodríguez, 2008) se enfoca en obtener requerimientos funcionales a partir de procesos de negocios, para ello parten de un modelo de negocios expresado en BPMN (Business Process Model Notation) del cual obtienen diagramas de clases y diagramas de casos de uso. El proceso consiste en definir una serie de reglas de transformación en QVT (Query/View/Transformation) las cuales dan como resultado diagramas de clases y diagramas de casos de uso, que complementan los requerimientos ya capturados en el proceso de desarrollo de software.

3.8 A Guideline to Mapping Business Processes to UML Class Diagrams

Este trabajo de investigación (Rungworawut, 2005) se centra en obtener diagramas de clases a partir de un modelo BPMN, para ayudar a los diseñadores de software a generar modelos a partir de modelos de procesos de negocio. Para lograr lo anterior aplican un análisis a los procesos del negocio, una semántica formal de dominio específico y semánticas adicionales al modelo obtenido.

3.9 An algorithm to derive use cases from business process

Este trabajo de investigación (Dijkman, 2002) se concentra en obtener requisitos funcionales, como diagramas de caso de uso, a partir de un modelo de procesos de negocio, ya que los errores en los requisitos funcionales son los más difíciles de detectar y más costosos de corregir. Por lo tanto para producir especificaciones de requisitos más robustas y acelerar el proceso de ingeniería de requisitos proponen un algoritmo que transforma el modelo de procesos de negocio, creado a partir de un meta-modelo generado en la investigación, a diagramas de casos de uso; estos últimos pueden ser producidos más rápido cuando son derivados del modelo de procesos de negocio existentes.

3.10 Model Transformation with Triple Graph Grammars

Este trabajo de investigación (Königs, 2005) presenta un caso de estudio de una transformación de modelos utilizando gramáticas triples de grafo. El caso de estudio se centra en la transformación de diagramas de clases a esquemas de base de datos. Proponen un algoritmo que ha sido integrado como parte del proyecto Toolnet (Altheide et al, 2003) y se basa en los meta-modelos de ambos

modelos involucrados para realizar la transformación. El resultado obtenido son tablas de una base datos las cuales contienen llaves primerias, llaves foráneas y los campos de la tabla.

3.11 ATL: a Model Transformation Tool

Este trabajo de investigación (Jouault, 2008) presenta un lenguaje de transformación llamado ATL (Atlas Transformation Language), las herramientas que componen a ATL proporcionan soporte para editar, compilar, ejecutar y depurar las tareas que tengan que ver con el lenguaje. Todas las herramientas


15

enfocadas a las actividades mencionadas se encuentran construidas sobre EMF (Eclipse Modeling Framework). El lenguaje ATL está inspirado en el estándar de recomendación de la OMG QVT y basado en el formalismo de OCL (Object Constraint Language), además permite utilizar los enfoques imperativo y declarativo según sea el problema a tratar.

3.12 Applying CIM-to-PIM model transformations for the service-oriented

development of information systems

Este trabajo de investigación (Castro, 2011) presenta un enfoque dirigido por modelos para el desarrollo orientado a servicios, el cual parte de la vista del negocio especificada en e3value y BPMN y son derivados en diagramas de casos de uso, modelo de composición de servicio y modelo de proceso de servicio. Lo anterior surge en base a uno de los principales desafíos en la computación orientada a servicios que es la falta de metodologías que soporten la especificación y diseño de composición de servicios, permitiendo a los ingenieros de software ir de escenarios tempranos del análisis del negocio a la implementación. Dentro del enfoque dirigido por modelos presentando se menciona una herramienta que utiliza ATL para realizar la transformación de e3value a diagrama de casos de uso.

3.13 Model Interoperability via Model Driven Development

Este trabajo de investigación (Ameedeen, 2011) se enfoca en el diseño y el análisis formal de dominios dentro del proceso de desarrollo de software. El diseño de software muchas veces se considera una tarea dirigida a las personas mientras que la fase de análisis se soporta sobre una base con representación formal y fundamento matemático. En base a lo anterior proponen un marco de trabajo de transformación de modelos llamado SD2PN, el cual soporta la transición entre diagramas de secuencia a redes de Petri; las redes de Petri tienen una fuerte base matemática y son adecuadas para el análisis.

3.14 Model Transformation from VisualOCL to OCL using Graph Transformation

Este trabajo de investigación (Ehrig, 2006) utiliza la representación visual (VisualOCL) y textual de OCL. VisualOCL proporciona una forma sencilla y fácil para modelado en OCL, sin embargo la representación textual de OCL puede ser usada en otras aplicaciones que lo requieran, por ejemplo la extensión de Eclipse

EMF. Para lo anterior crearon una herramienta programada en JAVA, utilizando el motor de transformación de grafos AGG (Atributted Graph Grammar), la cual fue implementada como un plug-in de VisualOCL.


16

Tabla 3.1. Comparativa de trabajos

Modelo de entrada

Rol en el proceso de

desarrollo

Resultado de la

investigación

Nivel de automatización

Modelo de salida

Suarez et al. Diagrama de

actividad UML

Elicitación de

requerimientos

Método Manual Modelo

dominio UML

Alencar et al. I* Participación en

la mayoría de

las fases de

desarrollo de

software

Directrices Semiautomático Producto de

software

García et al. Diagrama de

actividad UML

Análisis de

requerimientos

Directrices Manual Diagramas de

casos de uso y clases de

dominio

Martínez A. Tropos Elicitación de

requerimientos

Lenguaje de

patrones

Manual Diagramas de

casos de uso.

Santander et al.

I* Análisis de requerimientos

Directrices Manual Diagramas de casos de uso

Barros et al. Diagrama de

actividad UML

Codificación Directrices Manual Diagramas de

clases

Rodríguez et al. BPMN Elicitación de

requerimientos

Método Automático Diagramas de

clases y

diagramas de

casos de uso UML

Rungworawut BPMN Análisis de

requerimientos

Directrices Manual Diagramas de

clases

Dijkman et al. Diagrama de actividades

Elicitación de requerimientos

Algoritmo Manual Diagramas de casos de uso

UML


17

Königs A. Diagramas de

clases.

Generación de

esquema de bases de datos

Algoritmo Manual Esquema de

base de datos

Jouault et al. Acepta

cualquier

metodología

Aplicable en

cualquier etapa

Herramienta de

transformacion

es entre modelos

Automático Cualquiera

que se

especifique

Castro et al. E3value y

BPMN

Participación en

la mayoría de

las fases de

desarrollo de

software orientado a

servicios

Enfoque

dirigido por

modelos

Semiautomático diagramas de

casos de uso,

modelo de

composición

de servicio y modelo de

proceso de

servicio

Ameedeen et

al.

Diagramas de

secuencia

Análisis de

requerimientos

Herramienta de

transformación

SD2PN

Automático Red de petri

Ehrig et al. VisualOCL Apoyo en el

diseño o

análisis de

requerimientos

Herramienta

implementada

como plug-in

Automático OCL

Capítulo 4. Método de solución

18

CAPÍTULO 4. MÉTODO DE SOLUCIÓN

Este capítulo presenta las actividades, correspondientes a cada proceso de la figura 4.1, realizadas para alcanzar los objetivos propuestos en el capítulo 1. La actividad análisis de meta-modelos correspondiente al primer proceso de la fase uno se realizó para conocer los elementos y relaciones que componen a cada meta-modelo involucrado en el método de transformación; este análisis es presentado en la sección 4.1. La comparativa de meta-modelos, presentada en la sección 4.2, se enfocó en identificar que elementos representan información semejante. Los elementos y relaciones utilizados en el método de transformación fueron seleccionados a partir del análisis y la comparativa de los meta-modelos. La actividad realizada en el segundo proceso de la fase uno corresponde a la definición las directrices que componen al método de transformación, las cuales

expresan la forma de mapear elementos del meta-modelo i* extendido al meta-modelo del DSVL; estas directrices se detallan en la sección 4.3. En la actividad del tercer proceso, correspondiente a la fase dos, se realizó la adición de etiquetas para el módulo tecnológico del meta-modelo i* extendido (Morales, 2010) a IStarML (Cares, 2007), y así representar modelos del meta-modelo i* extendido, con la finalidad de manejarlos en la herramienta de transformación; la sección 4.4.1 presenta el resultado de esta actividad. La actividad del cuarto proceso de la fase dos se enfocó en crear el archivo XML para representar modelos del meta-modelo DSVL (Hernández, 2010), este archivo permite representar los tipos de sintaxis que integran al lenguaje visual de dominio específico (Hernández, 2010); la sección 4.4.2 presenta el resultado de esta actividad. En el quinto y último proceso de la fase dos se desarrolló la herramienta de transformación, que implementa el método de transformación obtenido en la fase uno; esta herramienta realiza la transformación de manera semiautomática guiando al usuario de esta durante el proceso. La herramienta y su funcionalidad se describen en la sección 4.5.


19

Figura 4.1. Actividades de los procesos del desarrollo de la investigación.

4.1 Análisis de meta-modelos

Esta sección presenta el análisis realizado al meta-modelo DSVL (Hernández, 2010) y al meta-modelo i* extendido (Morales, 2010) para conocer los elementos que los integran y las relaciones entre estos elementos.

4.1.1 Meta-modelo i* extendido

El meta-modelo i* extendido (Morales, 2010), presentado en la figura 4.2, surge de un enfoque de modelado que integra los elementos de negocio y tecnológicos de una organización, el cual se encuentra basado en el marco de trabajo i* (Yu, 1995). Este enfoque "trata con las tecnologías de una manera conveniente, considerándolas directamente en relación con los requerimientos de negocio independientemente de sus capacidades funcionales, mediante la especificación de las características de calidad principales" (Morales, 2010). El enfoque de modelado (Morales, 2010) está compuesto de las siguientes tres vistas:

"El modelo global: El proceso de modelado de negocios comienza con la definición de una vista de alto nivel de los servicios ofrecidos y utilizados por la empresa. El modelo global permite la representación de los servicios de negocio y los actores que juegan el rol de cliente y proveedor. En este modelo


20

se definen los servicios básicos y compuestos de la organización, utilizando extensiones de los conceptos de modelado i*" (Morales, 2010).

"El modelo de procesos. Una vez que los servicios de negocio han sido especificados, deben descomponerse en un conjunto de procesos concretos que los llevan a cabo. Esto se hace con un modelo de procesos que representa las abstracciones funcionales del proceso de negocio para un servicio específico; este modelo provee los mecanismos requeridos para describir el flujo de múltiples procesos utilizando nuevamente extensiones de i*" (Morales, 2010).

"El modelo de protocolos. Finalmente, la descripción de los protocolos y transacciones de cada proceso de negocio se representa en un diagrama independiente utilizando los conceptos de modelado i*. Este modelo provee una descripción de un conjunto de actividades estructuradas y asociadas que producen un resultado o producto específico para un servicio de negocio"

(Morales, 2010). En este trabajo únicamente se considera el modelo de protocolo debido a que este modelo detalla ampliamente los procesos de negocios y por lo tanto proporciona mayor información.

Figura 4.2. Meta-modelo i* extendido (Morales, 2010).


21

El meta-modelo propuesto en el enfoque de modelado (Morales, 2010) surge en base al meta-modelo del marco de trabajo i* presentado en la figura 4.3. La diferencia entre ambos meta-modelos radica en los tipos de relaciones (ActorLink y Sr-Link) presentados, los cuales se omitieron en la figura 4.2 para presentar de forma más clara el elemento TechnologyModule.

Figura 4.3. Meta-modelo de i* (Morales, 2010).

Los principales elementos de los meta-modelos de la figura 4.2 y figura 4.3 son descritos en la tabla 4.1. Para una descripción más completa de los elementos que integran el marco de trabajo i* se recomienda visitar la i*Guide (i*Wiki, 2011).


22

Tabla 4.1. Descripción de elementos del meta-modelo i* extendido.

Elemento Descripción

Node El elemento Node en el meta-modelo representa al elemento del cual se derivan los elementos en los modelos de i*.

Actor Elemento padre del cual se derivan los siguientes tipos de actores:

General: es una entidad activa que ejecuta tareas para cumplir metas.

Role: caracterización abstracta del comportamiento de un actor dentro de un dominio o contexto especializado.

Agent: es un actor con "manifestaciones concretas", puede ser un humano o un agente de software/hardware.

Position: abstracción intermedia que puede ser usada entre un rol y un agente.

ActorLink Elemento padre del cual se derivan las siguientes relaciones entre actores:

Is-part-of: se utiliza para representar que un elemento actor forma parte de otro elemento actor.

Is-a: representa una relación de generalización entre actores.

Covers: es utilizado para describir la relación entre un actor Position y un actor Role. Designa el rol que cubre una posición.

Occupies: es utilizado para describir la relación entre un actor Agent y un actor Position. Muestra la posición que ocupa un agente.

Plays: se utiliza entre un actor Agent y un actor Role, para representar que un actor Agent está interpretando un rol.

Instance: se utiliza para representar que instancia de una entidad más general, por ejemplo un actor agent es una instancia de otro actor Agent.

IntentionalElement Elemento utilizado para representar intenciones en los modelos de i* las cuales se presentan a continuación:

Goal: es una representación de algo que desea alcanzar un actor, este elemento se satisface cumpliendo las tareas (elementos Task) que se derivan de ella.

Softgoal: Similar al elemento Goal, sin embargo la satisfacción de este elemento queda a criterio del actor.

Task: representa una tarea que debe cumplir un actor.

Resource: representa una entidad física o informativa que requiere un actor.


23

Dependency Elemento que describe la relación entre dos actores a través de un tipo de IntentionalElement, el cual se compone de los elementos Depender, Dependum y Dependee. El Depender es el actor dependiente, el Dependum es el elemento sobre el cual se centra la relación y el Dependee es el actor del cual se depende. A continuación se presentan los tipos de relaciones que se pueden dar:

Goal Dependency

Task Dependency

Resource Dependency

Softgoal Dependency

Sr-Link Elemento padre del cual se derivan las siguientes relaciones entre las intenciones de IntentionalElement:

MeansEnd: esta relación involucra a una intención Goal y una o muchas intenciones Task. El Means corresponde a las intenciones Task e indica las tareas a ejecutar para alcanzar la intención Goal que corresponde al End.

TaskDecomposition: esta relación involucra a una intención Task como el elemento padre de una o muchas intenciones, estas últimas pueden ser de un solo tipo o una combinación de todos los tipos. Indica que una tarea es descompuesta en varios elementos los cuales se deben llevar a cabo para cumplir con esta.

Contribution: esta relación indica un impacto negativo, positivo o desconocido a una intención Softgoal a través de una intención Goal, Task o Softgoal.

TechnologyModule Elemento que permite modelar componentes tecnológicos, utilizando actores, intenciones y relaciones entre estos, para ser integrados a un modelo de negocios.

DependecyWithoutDepender "Este concepto es utilizado para describir requerimientos importantes para el uso de una tecnología, dependiendo de la medida en que estos se cumplan se puede esperar que la tecnología funcione de manera adecuada" (Morales, 2010). Este tipo de relación es aplicado en los componentes tecnológicos modelados.

DependecyWithoutDependee "Este concepto es utilizado para representar la funcionalidad que puede ser ofrecida por una tecnología a sus usuarios, pero principalmente los atributos de calidad que pueden esperar de dicha funcionalidad" (Morales, 2010). Este tipo de relación es aplicado en los componentes tecnológicos modelados.

Boundary El Boundary es un elemento aplicado a un actor el cual encapsula una serie de intenciones e incluso a otros actores, estos últimos pueden incluir intenciones dentro de


24

su propio Boundary.

Aunque no se representa como un elemento en los meta-modelos i*, Boundary es importante en este trabajo de tesis por lo cual es descrito en la tabla 4.1.

4.1.2 Meta-modelo DSVL

El meta-modelo DSVL (Hernández, 2010) surge de un lenguaje visual de dominio específico (DSVL) que permite a los usuarios finales describir un ambiente inteligente mediante representaciones gráficas. Este lenguaje fue desarrollado utilizando las técnicas activity-based computing, modelado de tareas, método para involucrar a los usuarios finales en un enfoque MDD y el enfoque de las cuatro w's. Lo anterior dio como resultado el meta-modelo presentado en la figura 4.4.

El lenguaje visual de dominio específico (Hernández, 2010) se compone de las sintaxis concreta y abstracta, las cuales se basan en el meta-modelo de la figura 4.4. Este trabajo de tesis únicamente tomó en cuenta la sintaxis concreta ya que es paso inicial del enfoque MDD propuesto en el trabajo del lenguaje visual de dominio específico (Hernández, 2010).

Figura 4.4. Meta-modelo DSVL (Hernández, 2010).

Es importante mencionar que el lenguaje se encuentra enfocado al dominio médico, específicamente al área de medicina interna. Las tablas 4.2 y 4.3 presentan la descripción de los elementos que integran al meta-modelo y las relaciones entre estos elementos, respectivamente.


25

Tabla 4.2. Descripción de elementos del meta-modelo DSVL (Hernández, 2010).


Usuario Persona que ejecuta una serie de acciones en un lugar determinado.

Actividad Acción que desempeña un Usuario.

Contexto Lugar en el cual un Usuario desempeña sus actividades.

Dato Elemento utilizado por una Actividad determinada, los cuales corresponden a documentos médicos.

Tabla 4.3. Descripción de relaciones del meta-modelo DSVL (Hernández, 2010).


Realiza Relación utilizada para asignar una Actividad a un Usuario.

Utiliza Relación utilizada para asignar un Dato a una Actividad.

Pertenece Relación utilizada para denotar el Contexto de un Usuario o Actividad.

Operador Relación para ligar Actividades entre sí.

Aunque la sintaxis abstracta hace uso del meta-modelo DSVL (Hernández, 2010) y es una parte importante del DSVL, esta no es utilizada y por lo tanto no fue analizada.

4.2 Comparación entre elementos de los meta-modelos

La comparación de los elementos del meta-modelo DSVL (Hernández, 2010) y el meta-modelo i* extendido (Morales, 2010) se realizó a partir del análisis de sus elementos con la finalidad de encontrar equivalencia entre ellos. El resultado de esta comparación fueron dos tablas que incluyen la equivalencia entre elementos de ambos meta-modelos y la equivalencia entre las relaciones de los elementos. La tabla 4.4 presenta la equivalencia de los elementos describiendo el elemento del modelo de negocios, el objetivo del elemento, el elemento equivalente en el meta-modelo DSVL y observaciones.


26

Tabla 4.4. Comparativa de elementos entre el meta-modelo i* extendido (Morales, 2010) y el meta-modelo DSVL

(Hernández, 2010).

Elemento del meta-modelo i* extendido

Objetivo Equivalencia en el meta-

modelo DSVL

Observación

Actor: General Representar una entidad activa.

Usuario Ambos elementos son entidades activas.

Actor: Role Representar una caracterización del

comportamiento de un actor dentro de un dominio o contexto

especializado.

--- No se encontró la definición de

comportamientos para ser representada con el meta-modelo DSVL (Hernández,

2010).

Actor: Agent Representar una entidad con

manifestaciones concretas

Usuario Ambos elementos tienen manifestaciones concretas.

Actor: Position Representar una abstracción intermedia

entre un actor role y agent.

--- No se encontró la definición de usuarios intermedios para ser

representada con el meta-modelo DSVL (Hernández,

2010).

IntentionalElement: Goal

Representar un objetivo que desea alcanzar un

actor.

--- No existe la definición de objetivos en el meta-

modelo DSVL (Hernández, 2010).

IntentionalElement: Task

Representar una acción a realizar por un actor.

Actividad Ambos elementos describen la ejecución de

una acción.

IntentionalElement: Softgoal

Representar un atributo de un elemento goal o

task.

--- No existe la definición de atributos en el meta-

modelo DSVL (Hernández, 2010).

IntentionalElement: Resource

Representar un objeto físico o informativo

requerido por un actor.

Dato Ambos elementos son utilizados para representar

información.

TechnologyModule Representar una tecnología de

información utilizada en el negocio.

--- No existe un elemento para poder representar la

tecnología con el meta-modelo DSVL (Hernández,

2010).

Boundary Encapsular elementos de un actor.

Contexto Ambos encapsulan elementos.

A pesar de que el modelo de negocios cuenta con cuatro tipos de actores, dos de ellos (General y Agent) representan entidades que ejecutan acciones, sin embargo el tipo de actor Position y Role representan entidades intermedias y comportamientos respectivamente, los cuales no es posible representarlos con el


27

meta-modelo DSVL (Hernández, 2010) de acuerdo a la definición de sus elementos. Con respecto a los elementos IntentionalElement se identificó que Task es equivalente a una Actividad ya que ambos son utilizados para representar acciones a realizar por una entidad. También se identificó que Resource es utilizado para representar información al igual que el elemento Dato. Por otra parte no se encontró equivalencia para Goal y Softgoal, los cuales representan objetivos y atributos respectivamente. En los modelos creados con el meta-modelo DSVL (Hernández, 2010), específicamente con la sintaxis concreta, la tecnología RFID (Radio Frequency IDentification) se encuentra de forma implícita y no existe un elemento en el meta-modelo para representarla, por lo tanto el elemento TechnologyModule no tiene

equivalencia. Boundary a pesar de no ser representado como elemento en el meta-modelo i* extendido (Morales, 2010), encapsula elementos que pueden ser mapeados a elementos del meta-modelo DSVL (Hernández, 2010), a su vez estos elementos encapsulados se encuentran asignados al actor del cual se despliega el Boundary, exceptuando a los elementos dentro del Boundary de otro actor que se encuentre anidado. La figura 4.5 presenta un Actor B el cual tiene dentro de su Boundary un IntentionalElement Task, a su vez el Actor B se encuentra dentro del Boundary del Actor A; el Boundary es representado con líneas punteadas.

Figura 4.5. Actores anidados con Boundary.


28

Las equivalencias entre relaciones se encuentran presentadas en la tabla 4.5 en la cual se muestra relación del modelo de negocios, que es lo que esta especifica, que elementos relaciona, su equivalencia con alguna relación del meta-modelo DSVL (Hernández, 2010) y observaciones.

Tabla 4.5. Comparativa de relaciones entre el meta-modelo i* extendido (Morales, 2010) y el meta-modelo DSVL

(Hernández, 2010).

Tipo de relación en el meta-modelo i* extendido

Especifica Relaciona Equivalencia en el meta-

modelo DSVL

Observación

ActorLink: Is-part-of Un actor

constituye una parte de otro actor.

Actor con Actor (binaria)

--- No existen

relaciones entre

actores en el meta-modelo DSVL

(Hernández, 2010).

ActorLink: Is- a Un actor es una

especificación de otro actor.


--- No existen relaciones

entre actores en el meta-modelo DSVL

(Hernández, 2010).

ActorLink: Covers El rol que cubre un

actor Position.




(Hernández, 2010).

ActorLink: Occupies La posición que ocupa un actor Agent.




(Hernández, 2010).

ActorLink: Plays El rol que Actor con Actor --- No existen


29

desenvuelve un actor Agent.

(binaria) relaciones entre

actores en el meta-modelo DSVL

(Hernández, 2010).

ActorLink: Instance Un actor específico de otro actor.

Actor con actor (binaria)



(Hernández, 2010).

Goal Dependency La relación entre dos actores a

través de un objetivo.

Actor con IntentionalElement

con Actor (ternaria)

--- ---

Task Dependency La relación entre dos actores a

través de una tarea.



--- ---

Resource Dependency La relación entre dos actores a

través de un recurso.



--- ---

Softgoal Dependency La relación entre dos actores a

través de un atributo.



--- ---

Sr-Link: Means-End El cómo lograr el

objetivo propuesto.

Goal con Task (binaria)

Realiza u Operador

El tipo de relación

depende de la jerarquía en la cual

se encuentre el

elemento.

Sr-Link: TaskDecomposition Un elemento está

compuesto por partes

más

Task con Goal, Task con Task,

Task con Softgoal o Task con Resource

Operador o Realiza.

Únicamente se toman en cuenta las relaciones Task con


30

pequeñas. (binaria) Task.

Sr-Link: Contribution El impacto que tiene un

elemento sobre un atributo.

Goal con Softgoal, Task con Softgoal

o Softgoal con Softgoal (binaria)

--- No se trabaja con atributos en

el meta-modelo DSVL

(Hernández, 2010) por lo

tanto las relaciones de estos no se toman en

cuenta.

DependecyWithoutDepender Un requerimiento

de una tecnología.

Goal con Actor o Softgoal con Actor

(binaria)

--- No existe un

elemento para poder representar

la tecnología

con el meta-modelo DSVL

(Hernández, 2010).

DependecyWithoutDependee Una funcionalidad

de una tecnología.

Goal con Actor o Softgoal con Actor

(binaria)

--- No existe un

elemento para poder representar

la tecnología

con el meta-modelo DSVL

(Hernández, 2010).

En lo que respecta a las relaciones se descartaron todos los tipos de ActorLink, debido a que en el meta-modelo DSVL (Hernández, 2010) no existen relaciones entre Usuarios. Se descartaron también todos los tipos de Dependecy a pesar de que existe el concepto de tareas cooperativas en el lenguaje visual de dominio específico (Hernández, 2010) con el cual se podría presentar una equivalencia con Task Dependency, los elementos que intervienen caen en el tipo de relación Realiza u Operador, la cual corresponde a una relación binaria. La relación Means-End descrita en el meta-modelo i* extendido (Morales, 2010) involucra IntentionalElements del tipo Task que si tienen una equivalencia en el meta-modelo DSVL (Hernández, 2010), por lo tanto esta relación es tomada


31

en cuenta y su equivalencia depende del nivel que se encuentra en la jerarquía. La figura 4.6 presenta un modelo creado con el enfoque de modelado (Morales, 2010) en el cual se observa que la relación Means-End se encuentra en la jerarquía más alta dentro del Boundary del Actor Inventory Board (IB), dando lugar a una posible relación Realiza del IntentionalElement Task asociado; también se puede observar que existe otra relación Means-End pero en una jerarquía más baja, la cual podría dar lugar a una posible relación Operador.


32

Figura 4.6. Modelo de integración del protocolo de recolección de información de inventario (Morales, 2010).


33

La sección 4.3 describe de una manera más detallada cuando usar el tipo de relación Realiza y Operador derivada de una relación Means-End. En la relación TaskDecomposition del meta-modelo i* extendido (Morales, 2010) se involucran IntentionalElements del tipo Task los cuales tienen una equivalencia a Actividades en el meta-modelo DSVL (Hernández, 2010), dando lugar a relaciones entre Actividades las cuales son del tipo Operador. Existe la posibilidad que el IntentionalElement Task padre genere una relación Realiza, dependiendo del orden en que se requieran la ejecución de actividades en el modelo creado con la sintaxis concreta del lenguaje visual de dominio específico (Hernández, 2010), la sección 4.3 describe de manera detallada este caso. La relación Contribution se descartó ya que involucra al IntentionalElement Softgoal el cual no tiene equivalencia en el meta-modelo DSVL (Hernández, 2010), en cuanto a las relaciones DependecyWithoutDepender y DependecyWithoutDependee son utilizadas en el elemento TechnologyModule que tampoco tiene equivalencia.

En adelante se referirá a los elementos y relaciones que tienen equivalencia con los siguientes nombres:

IntentionalElement Task ---> Tarea

IntentionalElement Resource ---> Recurso

Task Dependency ---> Dependencia de Tarea

Resource Dependecy ---> Dependencia de Recurso

Actor (en todos sus tipos) ---> Actor

TaskDecomposition ---> Descomposición

Dato --> Documento Se optó por el nombre Documento en lugar de Dato, elemento del meta-modelo DSVL (Hernández, 2010), debido a que Documento describe mejor las instancias de este elemento.

4.3 Método de transformación

En esta sección se describe el método de transformación en una serie de directrices las cuales son aplicadas al modelo de integración de protocolo (Morales, 2010), de acuerdo a la figura 4.7, para poder generar la sintaxis concreta del DSVL (Hernández, 2010). En la sección anterior se mencionó que la relación Dependency no tenía

una relación equivalente en el meta-modelo DSVL (Hernández, 2010), sin embargo algunos IntentionalElement involucrados en ella sí y estos a su vez deben ser relacionados con el elemento que les corresponde. Lo anterior es tratado con las directrices descritas en esta sección ya que estos elementos pueden proporcionar información de interés.


34

Figura 4.7. Pasos para realizar la transformación entre el modelo de integración de protocolo

(Morales, 2010) y la sintaxis concreta (Hernández, 2010).

Para la aplicación de estas directrices se debe contar con un modelo de integración de protocolo desarrollado con el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010), en adelante se hará referencia al modelo de integración de protocolo como modelo de negocios.

4.3.1 Paso 1: identificación de usuarios

En este paso se identifican los Usuarios potenciales a partir de los Actores definidos en el modelo de negocios; la figura 4.8 presenta un ejemplo. Directriz 1.1: Cada Actor especificado en el modelo de negocios debe ser considerado como un posible Usuario en el DSVL.

Directriz 1.2: El Actor considerado debe ser una entidad humana para que pueda ser mapeado a un Usuario en el DSVL, por ejemplo enfermera y no una entidad abstracta como puede ser Hospital o un sistema de software. Directriz 1.3: Se debe descartar a los Actores que no se encuentren dentro de las categorías: médico, enfermera o químico. Lo anterior se debe a que el modelo destino está centrado en esos Usuarios. Con las directrices anteriores se obtienen los posibles Usuarios que serán representados con la sintaxis concreta del DSVL, sin embargo existe la posibilidad que algún Usuario identificado no se encuentre definido en el DSVL o tenga un nombre distinto. El anexo A presenta los Usuarios definidos para el DSVL.


35

Figura 4.8. Identificación de usuarios aplicando el método de transformación.

4.3.2 Paso 2: Definición del contexto de los usuarios

En este paso se define el Contexto sobre el cual actuarán los Usuarios identificados; la figura 4.9 presenta un ejemplo. Los Contextos definidos en el DSVL son: Oficina de medicina interna, sala de discusión, cama del paciente, pasillos y laboratorio. Directriz 2.1: Si el Usuario se encuentra definido en la sintaxis concreta del DSVL los Contextos se asignarán de la siguiente manera:

Cama del paciente: Médico interno, enfermera y paciente.

Laboratorio: Químico.

Sala de juntas: Médico general. Se ha omitido el contexto pasillos, dado que es utilizado en la sintaxis concreta al momento de que un Usuario recibe algún tipo de notificación del sistema.

Directriz 2.2: Si el Usuario no se encuentra definido en la sintaxis concreta del DSVL, se deben observar las tareas que realiza el Usuario identificado en el modelo de negocios o si se encuentra dentro de las categorías: médico, enferma o químico, para poder definir un contexto.

Figura 4.9. Definición de contextos aplicando el método de transformación.


36

4.3.3 Paso 3: Identificación de actividades para los usuarios

En este paso se identifican las Tareas que servirán para definir las Actividades que realizará un Usuario en el DSVL; las figuras 4.10 y 4.11 presentan ejemplos de identificación de actividades. Directriz 3.1: Cada Tarea definida dentro del Boundary de un Actor, el cual ha sido identificado como Usuario, debe ser considerada como una posible Actividad del Usuario. Directriz 3.2: Las Tareas consideradas deben tener relación con una entidad paciente o bien tener una relación directa con el rol del Actor a asociar.

Figura 4.10. Identificación de actividades aplicando el método de transformación.

Directriz 3.3: Cada Dependencia de Tarea en la cual participe el Actor, el cual ha sido identificado como Usuario, debe ser considerada como una posible Actividad, siempre y cuando el Actor que se está analizando sea el Dependee. En caso que la Dependencia de Tarea se encuentre relacionada con una Tarea del mismo nombre dentro del Boundary, esta directriz debe ser descartada. Con las directrices anteriores se obtienen las posibles Actividades que puede realizar un Usuario, al igual que los Usuarios existe la posibilidad que

alguna Actividad identificada no se encuentre definida en el DSVL o tenga un nombre distinto. El anexo B presenta las Actividades definidas para el DSVL.


37

Figura 4.11. Identificación de actividades en dependencias aplicando el método de transformación.

4.3.4 Paso 4: Identificación de documentos para los usuarios

En este paso se identifican los Recursos que servirán para definir las documentos que utilizará un Usuario en el DSVL; las figuras 4.12 y 4.13 presentan ejemplos de identificación de documentos. Directriz 4.1: Cada Recurso definido dentro del Boundary de un Actor, el cual ha identificado como Usuario, debe ser considerado como un posible Documento del Usuario. Directriz 4.2: Los Documentos identificados deben tener relación con el dominio médico, por ejemplo: una receta médica, expediente clínico, etcétera.

Figura 4.12. Identificación de documentos aplicando el método de transformación.


38

Directriz 4.3: Cada Dependencia de Recurso en el cual participe el Actor, el cual ha identificado como Usuario, debe ser considerada como un posible Documento, siempre y cuando el Actor que se está siendo analizando sea el depender.

Figura 4.13. Identificación de documentos en dependencias aplicando el método de transformación.

Con las directrices anteriores se obtienen los posibles Documentos que puede utilizar un Usuario en el DSLV. Al igual que los Usuarios y las Actividades, existe la posibilidad que en algún Documento identificado no se encuentre definido en el DSVL o tenga un nombre distinto. El anexo C presenta los Documentos definidos para el DSVL.

4.3.5 Paso 5: Relaciones entre actividades y documentos

En este paso se definen las relaciones entre las Actividades y Documentos que utilizará el Usuario; las figuras 4.14, 4.15 y 4.16 presentan ejemplos de identificación de relaciones. Directriz 5.1: Una Actividad puede contener una o más relaciones a ella, sin embargo un Documento no puede tener relación con otro Documento ni relación directa al Usuario. Directriz 5.2: Se recomienda que la Actividad inicial para cada Usuario sea una Actividad que se encuentre en la jerarquía más alta, siempre y cuando

cumpla con la directriz 3.2. Si durante el análisis se detecta otra Actividad más acorde se recomienda utilizarla. Directriz 5.3: Las relaciones de Descomposición del modelo de integración de protocolo, que involucran a las Actividades identificadas, son mapeadas a relaciones entre Actividades en secuencia, teniendo como Actividad inicial a la Tarea padre del modelo de integración de protocolo. Si la Actividad padre ha sido descartada por la directriz 3.2, las Actividades hijas se deben ligar a la Actividad identificada más próxima a la Actividad padre, solamente a una de ellas y continuar en secuencia, o de lo contrario directamente al Usuario.


39

Directriz 5.4: Las relaciones Means-End del modelo de integración de protocolo, que involucran a las Actividades identificadas, son mapeadas a relaciones entre Actividades en discontinuidad. La actividad padre para esta(s) Actividad(es) será una actividad que se encuentre en una jerarquía más alta, si la actividad padre ha sido descartada por la directriz 3.2 se debe ir subiendo en la jerarquía, de lo contrario el padre será el Usuario.

Figura 4.14. Identificación de relaciones aplicando el método de transformación.

Directriz 5.5: Una relación Documento-Actividad es generada a partir de un Documento identificado de una Dependencia de Recurso ligada a una Tarea, siempre y cuando la Actividad que corresponde a la Tarea no haya sido descartada por la directriz 3.2, de lo contrario se asigna a la Tarea más apropiada de acuerdo al análisis.

Figura 4.15. Identificación de relaciones de documentos en dependencias aplicando el método de transformación.


40

Directriz 5.6: Una relación Documento-Actividad es generada a partir de un documento identificado de una Descomposición de una Tarea, siendo la Tarea padre de la Descomposición la Actividad a la cual es ligada el Documento, siempre y cuando la Actividad que corresponde a la Tarea no haya sido descartada por la directriz 3.2, de lo contrario se asigna a la Tarea más apropiada de acuerdo al análisis.

Figura 4.16. Identificación de relaciones en documentos aplicando el método de transformación.

4.4 Archivos XML

En esta sección se presentan los archivos XML propuestos, los cuales son utilizados por la herramienta de software que aplica el método de transformación definido. Los archivos XML están basados en una gramática que se definió utilizando GEBNF (Graphic Extension of Backus–Naur Form) para cada uno de los meta-modelos involucrados.

4.4.1 Adición de etiquetas para módulos tecnológicos a IStarML

Las etiquetas para representar instancias del meta-modelo i* extendido (Morales, 2010) en XML, fueron tomadas de IStarML (Cares, 2007). Lo anterior

se debe a que IStarML permite representar diversos meta-modelos de variantes del marco de trabajo i* (Cares, 2011), sin embargo no se contemplan etiquetas para los módulos tecnológicos propuestos en el meta-modelo i* extendido (Morales, 2010) por lo cual se generó una gramática que valida los modelos de integración de protocolo. La gramática se compone de cuatro elementos: Símbolo raíz (R), símbolos no terminales (N), símbolos terminarles (T), reglas de producción (S), a continuación se presenta la gramática: G=(R, N, T, S)

R = i*


41

N = i*, Node, Dependum, Module, Property, Asoc, AsocNN, Rel, Link, Boundary

T = String S =

1. i*::= nodes: Node*, dependums: Dependum*, modules: Module+, No-No: Asoc* [AsocNN+], No-Mo: Rel*, links: Link*, Boundaries: Boundary

2. Node::= name: String, type: String 3. Dependum: name: String, type: String 4. 4. Module::= name:String, [nodes: Node 2..*],

[properties: Property*] 5. Property::= concept:String, from:

Dependum@i*.dependums to: [email protected] | from: [email protected] to: Dependum@i*.dependums

6. Asoc::= type:String, from: Dependum@i*.dependums to: Node@i*.nodes | from: Node@i*.nodes to: Dependum@i*.dependums

7. AsocNN::= type:String, from: Node@i*.nodes to: Node@i*.nodes | from: [email protected] to: [email protected]

8. Rel: type: String, (from: Dependum@i*.dependums to: Node@i*.nodes | from: Node@i*.nodes to: Dependum@i*.dependums) | (from: Dependum@i*.dependums to: Module@i*.modules | from: Module@i*.modules to: Dependum@i*.dependums)

9. Link::= type:String, value:String, from: Dependum@i*.dependums, to: Dependum@i*.dependums

10. Boundary::= Node: Node@i*.Nodes, Items: Dependum@i*.dependums+

Las etiquetas generadas a partir de la gramática y las tomadas de IStarML (Cares, 2007) con sus atributos se presentan en la tabla 4.7. La estructura del archivo XML para el modelo de integración de protocolo se encuentra en el anexo E.

Tabla 4.7. Etiquetas XML para el modelo de integración de protocolo.

Concepto Etiqueta Atributo

Node <actor> "Type" "Id" "Name"

Dependum <ielement> "Type"

"Name"

Asoc Propiedades: from, to

<dependency> <depender> <dependee>

"aref" "aref"

Boundary <boundary>

Link <ielementLink> "Type" "Value"

AsocNN <actorlink> "Type" "aref"


42

Module <techmodule> "Name"

Property <property>

Rel <dependencym> <dependerm> <dependeem>

"aref" "aref"

Versión XML <istarml> "Versión"

Diagrama <diagram> "Autor" "Id" "Name"

La figura 4.18 presenta un extracto del XML de un modelo de integración de protocolo definido en el trabajo lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010).

Figura 4.18. Representación en XML de un modelo de integración de protocolo (Morales, 2010).


43

4.4.2 Creación del XML para la sintaxis concreta del DSVL (Hernández, 2010)

La gramática definida para representar instancias del meta-modelo DSVL fue creada para soportar la sintaxis concreta y abstracta del lenguaje visual de dominio específico (Hernández, 2010). Se compone de cuatro elementos: Símbolo raíz (R), símbolos no terminales (N), símbolos terminarles (T), reglas de producción (S). A continuación se presenta la gramática: G=(R, N, T, S)

R = Dsvl N = Dsvl, Usuario, Actividad, Contexto, Asoc, Rel T = String, Médico general, Enfermera, Químico, User, abstract,

interaction, application, Cama del paciente, laboratorio, sala de juntas, pasillo, |||, |[], |= |, [>,>>,[] >>, |>, *, [...],(n)

S = 1. Dsvl::= usuarios: Usuario+, actividades: Actividad+, Us-Ac:

Asoc+, [Ac-Ac: Rel*] 2. Usuario::= nombre: String, contextos: Contexto+ 3. Actividad::= nombre:String, tipo: String, operador: [String],

dato: String*, contextos: Contexto 4. Contexto::= nombre: String 5. Asoc: [nombre: String], from: [email protected], to:

[email protected] 6. Rel::= [nombre: String], from: [email protected],

to: [email protected] Dado que la gramática fue definida en base al meta-modelo y una lista de operadores (Hernández, 2010) presentada en el anexo D, esta puede representar tanto la sintaxis abstracta como la sintaxis concreta del DSVL, sin embargo únicamente se utilizará para representar la sintaxis concreta ya que la sintaxis abstracta corresponde a otro proceso del enfoque MDD propuesto en el trabajo del lenguaje visual de dominio específico (Hernández, 2010). La tabla 4.6 describe las etiquetas utilizadas en el archivo XML. No se utilizaron todos los atributos para la representación de la sintaxis concreta del DSVL ya que algunos corresponden la sintaxis abstracta del DSVL.

Tabla 4.6. Etiquetas XML para la sintaxis concreta del DSVL.

Concepto Etiqueta Atributo

Usuario <usuario> "Id" "Nombre":

Actividad <actividad> "Id" "Nombre" "Tipo": "Dato:" "Operador":

Contexto <contexto> "Nombre": Cama del paciente, laboratorio, sala de juntas, pasillo.

Relación Usuario-Actividad <enlaceu> "Referencia"


44

Relación Actividad-Actividad

<enlacea> "Referencia"

Versión XML de DSVL <dsvl> "Versión": 1.0

Diagrama <diagrama> "Autor" "Id" "Nombre"

La representación de un modelo creado con la sintaxis concreta del lenguaje visual de dominio específico (Hernández, 2010) y su equivalencia en XML se presenta en la figura 4.17.

Figura 4.17. Representación en XML de un modelo creado con la sintaxis concreta (Hernández,

2010).

4.5 Herramienta de transformación

En esta sección se presenta la herramienta de transformación, la cual hace uso del método de transformación definido en la sección 4.3 así como de los archivos XML de la sección 4.4.


45

4.5.1 Proceso general de ejecución

El proceso de ejecución de la herramienta se divide en cinco etapas, en algunas de ellas se requiere la intervención de un analista para proporcionar información relacionada con la transformación de acuerdo al método de transformación de la sección 4.3. A continuación se presentan las etapas antes mencionadas:

1. Definición del contexto para los elementos significativos 1. Identificación de Actores 2. Definición del Contexto para los Actores 3. Identificación de Tareas potenciales dentro del Boundary de un

determinado Actor 4. Identificación de Tareas como elementos de una Dependencia 5. Identificación de Recursos dentro del Boundary de un

determinado Actor 6. Identificación de Recursos como elementos de una Dependencia

2. Definición del orden de los elementos a transformar. 3. Comparación de nombres de los elementos identificados con las

Actividades definidas en el DSVL, para distinguir entre los elementos de la sintaxis abstracta y los elementos que no se encuentran en la sintaxis abstracta.

4. Transformación de elementos al modelo destino 5. Construcción del XML

4.5.2 Funcionamiento de la herramienta de transformación

La herramienta de transformación, presentada en la figura 4.19, se compone de una barra de menú que contiene la opción archivo la cual permite abrir un archivo XML o cerrar la herramienta y la opción info que presenta información acerca de la herramienta, además de cuatro pestañas que guían a la persona en el proceso de transformación.

Figura 4.19. Herramienta de transformación.

La figura 4.20 presenta la forma de abrir un archivo XML con el cual se desea trabajar. Este archivo XML debe cumplir la estructura definida del anexo E.


46

Figura 4.20. Abrir archivo XML con la herramienta de transformación.

Comenzando con la primera etapa que corresponde a la definición de Contextos es necesario conocer el modelo de negocios con el cual se trabajará para tener una idea clara de los Contextos. Dado que el dominio del modelo destino es el médico, los Contextos posibles son: sala de juntas, cama del paciente, sala de juntas y laboratorio; el modelo destino es un modelo creado con la sintaxis concreta del DSVL (Hernández, 2010). La pestaña que corresponde a la primera etapa permite agregar y eliminar contextos y no permite continuar al usuario si estos no se agregan. La figura 4.21 presenta como se definen los Contextos con la herramienta.


47

Figura 4.21. Agregar contextos con la herramienta de transformación.

Una vez insertados los Contextos es necesario agregar a los Usuarios potenciales identificados por la herramienta al Contexto que les corresponde, para ello se presiona el botón siguiente que aparece en la figura 4.21 el cual nos coloca en la pestaña de Actores. Los Usuarios potenciales son asignados, al Contexto que se desee, seleccionándolos y presionando el botón asignar. La figura 4.22 presenta un ejemplo. Es importante tener en cuenta que si no se asignan los Usuarios potenciales a un Contexto, la herramienta no permite moverse a la siguiente pestaña, en este paso no importa si el Usuario potencial es una entidad abstracta ya que es en la siguiente pestaña donde el usuario puede eliminar elementos identificados por la herramienta.


48

Figura 4.22. Asignar contextos a los actores con la herramienta de transformación.

Seleccionando un Usuario potencial que se encuentra ya en un Contexto y presionando el botón eliminar deslinda a un Usuario potencial de un Contexto. Una vez asignados los Usuarios potenciales a su Contexto es necesario presionar el botón siguiente para posicionarnos en la pestaña de Tareas y Recursos, la cual permite eliminar Actores, Tareas y Recursos. Se incluye el botón anterior en caso que se requiera añadir otro Contexto. La figura 4.23 presenta la pestaña de Tareas y Recursos, esta pestaña incluye tres listas correspondientes a Actores, Tareas y Recursos en las cuales se implementa la misma funcionalidad de eliminar que en las pestañas anteriores. Una de las restricciones en la pestaña de Tareas y Recursos es que un Actor debe contener al menos una Tarea pero puede contener cero Recursos. Lo anterior se debe a que la cardinalidad en el meta-modelo DSVL (Hernández, 2010) entre los elementos Usuario y Actividad es de uno a muchos y la cardinalidad entre los elementos Actividad y Dato es de cero a muchos. Como

se mencionó en la sección 4.2 el equivalente de Actor es Usuario, de Tarea es Actividad y de Recurso es Dato.


49

Figura 4.23. Eliminar actores, tareas y recursos con la herramienta de transformación.

Ya que se tengan los actores, tareas y recursos de acuerdo a las directrices del método de transformación, el siguiente paso es definir el orden de las Actividades de los Usuarios y a qué Actividad irán ligados los Documentos. La figura 4.24 presenta la pestaña de Usuarios, Actividades y Documentos, en esta pestaña no es posible eliminar a los Usuarios pero se tiene un botón anterior el cual nos posiciona en la pestaña Tareas y Recursos en la se pueden eliminar Actores. Esta pestaña corresponde a la segunda etapa del proceso de la herramienta.


50

Figura 4.24. Pestaña de usuarios, actividades y documentos de la herramienta de transformación.

La pestaña de Usuarios, Actividades y Documentos presenta una lista de Actividades con el botón id relación, la figura 4.25 presenta un ejemplo de cómo agregar las relaciones. Para los id's de las relaciones de las Actividades se utilizan números enteros y números con decimales, los números enteros corresponden a relaciones Realiza que van de Usuario a Actividad, mientras que en los números con decimales la parte entera corresponde al id de la Actividad con la cual se está trabajando y la parte decimal corresponde al id, previamente asignado, de la Actividad a la cual se va a relacionar lo cual da como resultado una relación Operador. La figura 4.26 presenta un ejemplo de la asignación de id's, se omiten los id's de los Documentos.


51

Figura 4.25. Asignar id's a actividades con la herramienta de transformación.

Figura 4.26. Ejemplo de id's asignados a las actividades con la herramienta de transformación.

Para generar relaciones Utiliza (Actividad con Dato) es necesario asignar los Documentos a una Actividad, para ello se selecciona un Documento de la lista de Documentos y se presiona el botón asignar. El id introducido para el documento corresponde a un id de una Actividad, en el caso de los números con decimales sólo se introduce la parte entera, la figura 4.27 presenta un ejemplo de la asignación de Documentos a Actividades.


52

Figura 4.27. Asignar documentos a actividades con la herramienta de transformación.

La figura 4.28 presenta un ejemplo de cómo quedan asignados los Documentos a una Actividad.

Figura 4.28. Ejemplo de documentos asignados a actividades con la herramienta de transformación.

Una vez completados los pasos anteriores es posible generar el archivo XML correspondiente a un modelo de sintaxis concreta (Hernández, 2010), para ellos presionamos el botón generar, elegimos la carpeta en la cual se guardara el archivo y escribimos el nombre del archivo, la figura 4.29 muestra un ejemplo. Este último paso engloba las etapas tres, cuatro y cinco.


53

Si alguna Actividad o Documento se encuentran sin id no es posible generar el archivo XML.

Figura 4.29. Generar archivo XML con la herramienta de transformación.

Capítulo 5. Pruebas

54

CAPÍTULO 5. PRUEBAS

Este capítulo presenta las pruebas realizadas para comprobar que el método de transformación, definido en el capítulo 4, permite generar modelos con la sintaxis concreta (Hernández, 2010).

5.1 Plan de pruebas

5.1.1 Introducción

El presente plan de pruebas se encuentra basado en el estándar IEEE 829-1998 (IEEE, 1998), con el cual se verificó el método de transformación creado para mapear elementos de un modelo de integración de protocolo (Morales, 2010) a un modelo de sintaxis concreta (Hernández, 2010). Cabe mencionar que el método de transformación que se evaluó en este plan de pruebas es apoyado por la herramienta de transformación del capítulo 4. El plan de pruebas se compone de las siguientes secciones: elementos de prueba, características probadas, características excluidas, enfoque, criterio éxito/fracaso de casos de prueba, criterios de suspensión y requerimientos de reanudación, documentos entregables de las pruebas, tareas de pruebas, requerimientos para realizar las pruebas, responsabilidades, riesgos y contingencias, aprobación, casos de prueba, especificación de casos de prueba, especificación de procedimiento de pruebas, resultados del plan de pruebas y evaluación de resultados.

5.1.2 Elementos de prueba

Los elementos de prueba consisten en dos modelos de negocios, específicamente en modelos de integración de protocolo, creados utilizando el meta-modelo i* extendido (Morales, 2010). Estos modelos incluyen los elementos requeridos para generar un modelo en la sintaxis concreta basado en el meta-modelo DSVL (Hernández, 2010). No todos los elementos de los modelos de negocios son significativos para la transformación, por lo cual no toda la información contenida en estos modelos fue transformada. Se requiere tener la representación de los modelos de negocios en formato XML, considerando como base a las reglas de la gramática definida en

este trabajo de tesis y la estructura del anexo E.

5.1.3 Características probadas

Las características probadas utilizando el método de transformación definido y la herramienta que apoya a dicho método se describen a continuación:

Actores del modelo de negocio: se evaluó que el Actor identificado fuera una entidad humana y no abstracta (hospital, sistema de software, departamento, etc.), además la herramienta determinó que Actores no contenían Tareas ni Recursos y fueron descartados automáticamente.


55

Tareas del modelo de negocio: como parte del método de transformación se evaluó que la Tarea identificada fuera relevante para ser mapeada a un Actividad en el modelo de sintaxis concreta. En lo que respecta a la herramienta, se evaluó que la identificación de las Tareas fuera correcta y que no genere duplicidad de Tareas, esto último como consecuencia de una Dependencia de Tarea y una Tarea dentro del Boundary de un Actor.

Dependencia de tareas: se evaluó que las Dependencias de Tareas entre Actores se asignaran al Actor correcto; de acuerdo al método de transformación se deben asignar al Dependee.

Recursos del modelo de negocio: como parte del método de transformación se evaluó que el Recurso identificado fuera relevante para ser mapeado a un Documento en el modelo de sintaxis concreta. En lo que respecta a la herramienta se evaluó la identificación de todos los Recursos asociados a un Actor.

Dependencia de recursos: se evaluó que las Dependencias de Recursos entre Actores se asignen al Actor correcto; de acuerdo al método definido se debe asignar al Depender.

5.1.4 Características excluidas

No se evaluó que las descripciones de los elementos del modelo de negocios sea correcta. por ejemplo que contenga errores ortográficos.

Elementos descartados: no se evaluó los elementos Goal y Softgoal ni las Dependencias de Recursos en las cuales intervenga el TechnologyModule, ya que no proporcionan información relevante para la transformación.

Modelo de negocios: no se verificó que el modelo de negocios se encontrara construido sintáctica y/o semánticamente correcto.

5.1.5 Enfoque

Las pruebas fueron utilizadas para verificar que el método de transformación definido es capaz de generar un modelo en la sintaxis concreta, el cual contenga información relevante para el usuario.

5.1.6 Criterio éxito/fracaso de los casos de prueba

Se consideró como éxito si durante el proceso de la transformación se cumplieron los siguientes puntos:

El método de transformación permite la identificación correcta de Actores.

La herramienta de transformación descarta automáticamente los Actores que no contienen Tareas.

Los elementos Tareas y Recursos mapeados a Actividades y Documentos

respectivamente son relevantes para el usuario.

Las relaciones entre Usuarios y Actividades son generadas correctamente de acuerdo a la especificación del usuario, de igual manera para las relaciones entre Actividades y Documentos.

No existen tareas duplicadas, producto de una Dependencia de Tareas y una Tarea dentro del Boundary.

Si los puntos anteriores no se cumplían se contó como un fracaso la prueba y se procedía a revisar el método de transformación y la herramienta de software que apoya al método de transformación.


56

5.1.7 Criterios de suspensión y requerimientos de reanudación

No se estableció ningún criterio de suspensión ni requerimientos de reanudación en las pruebas.

5.1.8 Documentos entregables de las pruebas

Los siguientes documentos fueron generados por el tesista Luis Ángel Chi Islas y entregados al Dr. Máximo López Sánchez para la aprobación de estos.

Plan de pruebas.

Reporte de pruebas. Únicamente se presenta el análisis de resultados del reporte de pruebas.

5.1.9 Tareas de pruebas

El conjunto de tareas identificadas para llevar a cabo las pruebas al método de transformación definido en esta tesis se presentan en la tabla 5.1.

Tabla 5.1. Tareas del plan de pruebas.

Tarea Tarea

predecesora

Habilidades especiales Responsabilidad Esfuerzo Fecha de

entrega

1.-Diseño del

plan de

pruebas

- Conocimiento del estándar

IEEE 829, conocimiento del

lenguaje de modelado para un

nuevo proceso de negocios

semántico (Morales, 2010),

conocimiento del lenguaje

visual de dominio específico

(Hernández, 2010)

Tesista - 15/05/2012

2.-Ejecución

del plan de

pruebas

Tarea 1 - Tesista - 30/05/2012

3.-Evaluación

de resultados

Tarea 2 Conocimiento del lenguaje de

modelado para un nuevo

proceso de negocios

semántico (Morales, 2010),

conocimiento del lenguaje

visual de dominio específico

(Hernández, 2010)

Tesista - 14/06/2012

4.-Reporte de

resultados

Tarea 3 - Tesista - 14/06/2012

5.1.10 Requerimientos para realizar las pruebas

Para llevar a cabo las pruebas descritas en este plan, en las cuales interviene la herramienta de software, se necesitaron cumplir ciertos requerimientos de hardware y software. Requerimientos de hardware:

Procesador 1 Ghz o superior


57

Memoria RAM 1 GB o superior

Espacio en disco duro 10 MB Requerimientos de software:

Sistema operativo Windows 7

JAVA JRE 6 o superior

5.1.11 Responsabilidades

El tesista Luis Ángel Chi Islas tuvo la responsabilidad de llevar a cabo cada una de las tareas de prueba especificadas en este documento, además de las correcciones que surgieron a partir de fracasos encontrados durante la ejecución del plan de pruebas.

5.1.12 Riesgos y contingencias

Si la herramienta de software presenta problemas de ejecución se debe

determinar si los problemas son causados por el software o el hardware, de ser necesario se debe utilizar otro equipo de cómputo para realizar las pruebas.

5.1.13 Aprobación

La aprobación de este plan de pruebas quedó a cargo del Dr. Máximo López Sánchez.

5.2 Casos de prueba

En esta sección se describe el propósito de cada paso del método de transformación, definido en esta tesis, en el modelo de integración de protocolo.

5.2.1 Identificación de usuarios

Esta prueba consistió en identificar a los Actores humanos del modelo de integración de protocolo con los cuales se generaron los Usuarios en la sintaxis concreta (Hernández, 2010).

5.2.2 Definición del contexto de los usuarios

La prueba consistió en identificar correctamente el Contexto sobre el cual un Usuario desarrollará sus actividades, esto se realizó en base a la lista de Contextos definidos en el lenguaje visual de dominio específico (Hernández, 2010).

5.2.3 Identificación de actividades para los usuarios

La prueba consistió en identificar todas las Tareas de un Actor, las cuales posteriormente fueron mapeadas a Actividades de Usuario de acuerdo al método de transformación.

5.2.4 Identificación de documentos para los usuarios

Esta prueba, al igual que la anterior, consistió en identificar todos los Recursos de un Actor los cuales posteriormente fueron mapeados a Documentos que estarían asignados a una Actividad del Usuario.


58

5.2.5 Relaciones entre actividades y documentos

La prueba consistió en generar correctamente las relaciones tratando de no mezclarlas, como puede ser relacionar Usuarios con Documentos lo cual no está permitido en el meta-modelo DSVL (Hernández, 2010). Con lo anterior se genera un documento XML, el cual es una representación de la sintaxis concreta (Hernández, 2010).

5.3 Especificación de casos de prueba

Para realizar las pruebas del método de transformación se utilizaron dos modelos de integración de protocolo, en virtud de que no se contaba con un banco de modelos de negocios creados con el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010) que fueran del dominio médico. Se creó un modelo de integración de protocolo con los escenarios

presentados en el trabajo de investigación del lenguaje visual de dominio específico (Hernández, 2010) y se realizó la traducción de un modelo negocios encontrado en una tesis doctoral (Yu, 1995) al cual se le agregó el módulo tecnológico RFID.

1. El primer caso de prueba contempla los principales usuarios del lenguaje visual de dominio específico (Hernández, 2010), que son médico interno, químico y enfermera. La figura 5.1 presenta el modelo creado.

2. El segundo caso es un modelo de negocios elaborado con i* el cual ha sido traducido a partir del modelo de negocios de una tesis doctoral (Yu, 1995), aunque el modelo incluye en su representación la venta de seguros médicos también incluye la interacción de un médico y un paciente, por lo cual se tomó en cuenta para las pruebas. La figura 5.2 presenta el modelo con el módulo tecnológico agregado.


59

Figura 5.1. Modelo de integración de protocolo creado con los escenarios descritos para el

lenguaje visual de dominio específico (Hernández, 2010)


60

Figura 5.2. Modelo de negocios traducido (Yu, 1995).


61

5.4 Especificación del procedimiento de prueba

Los pasos seguidos en el procedimiento de prueba son los siguientes:

5.4.1 Identificación de usuarios

a) Propósito Generar Usuarios a partir de los Actores en el modelo de negocios y observar si el Usuario es significativo en el modelo destino. b) Entorno de prueba El método de transformación se aplica a los modelos de integración de protocolo del dominio médico creados con el meta-modelo i* extendido (Morales,

2010), se tiene como requisito que la persona encargada de aplicar el método conozca los elementos del modelo de integración de protocolo y cuente con el archivo XML del modelo. c) Proceso 1. Seleccionar el Actor que se quiere analizar. 2. Ejecutar las directrices del paso 1 del método de transformación. 3. Observar si el Usuario es relevante en el modelo destino. d) Resultado esperado Los Usuarios que cumplen con las directrices se ven reflejados en el modelo creado con la sintaxis concreta (Hernández, 2010).

5.4.2 Definición del contexto de los usuarios

a) Propósito

Definir el Contexto sobre el cual un Usuario realiza sus Actividades, los Contextos corresponden a los definidos en el lenguaje visual de dominio específico (Hernández, 2010). b) Entorno de prueba El método de transformación se aplica a los modelos de integración de protocolo del dominio médico creados con el meta-modelo i* extendido (Morales,

2010), se tiene como requisito que la persona encargada de aplicar el método conozca los elementos del modelo de integración de protocolo y cuente con el archivo XML del modelo. c) Proceso 1. Seleccionar el Usuario identificado. 2. Ejecutar las directrices del paso 2 del método de transformación. d) Resultado esperado


62

Cada Usuario identificado tiene su contexto definido de acuerdo al lenguaje visual de dominio específico (Hernández, 2010).

5.4.3 Identificación de actividades para los usuarios

a) Propósito Generar actividades a partir de las Tareas incluidas dentro del Boundary de un Actor o en una Dependencia de Tarea, para los Usuarios identificados. b) Entorno de prueba El método de transformación se aplica a los modelos de integración de protocolo del dominio médico creados con el meta-modelo i* extendido (Morales, 2010), se tiene como requisito que la persona encargada de aplicar el método conozca los elementos del modelo de integración de protocolo y cuente con el archivo XML del modelo. c) Proceso 1. Seleccionar un Actor. 2. Observar si contiene Tareas dentro de su Boundary. 3.- Observar si tiene Dependencias de Tareas. 4. Ejecutar las directrices del paso 3 del método de transformación. d) Resultado esperado Conjunto de actividades para un usuario en el modelo creado con la sintaxis concreta (Hernández, 2010).

5.4.4 Identificación de documentos para los usuarios

a) Propósito Generar documentos a partir de Recursos incluidos dentro del Boundary de un Actor o en una Dependencia de Recurso, para los Usuarios identificados. b) Entorno de prueba El método de transformación se aplica a los modelos de integración de protocolo del dominio médico creados con el meta-modelo i* extendido (Morales,

2010), se tiene como requisito que la persona encargada de aplicar el método conozca los elementos del modelo de integración de protocolo y cuente con el archivo XML del modelo. c) Proceso 1. Seleccionar un Actor. 2. Observar si contiene Recursos dentro de su Boundary. 3.- Observar si tiene Dependencias de Recursos. 4. Ejecutar las directrices del paso 4 del método de transformación.


63

d) Resultado esperado Conjunto de Documentos para un Usuario en el modelo creado con la sintaxis concreta (Hernández, 2010).

5.4.5 Relaciones entre actividades y documentos

a) Propósito Generar relaciones entre los elementos relevantes (Actividades y Documentos) en la transformación. b) Entorno de prueba El método de transformación se aplica a los modelos de integración de protocolo del dominio médico creados con el meta-modelo i* extendido (Morales, 2010), se tiene como requisito que la persona encargada de aplicar el método conozca los elementos del modelo de integración de protocolo y cuente con el archivo XML del modelo. c) Proceso 1. Seleccionar una Actividad o Documento. 2. identificar el elemento al cual se va a relacionar. 3. Ejecutar las directrices del paso 5 del método de transformación. d) Resultado esperado Relaciones de Usuarios-Actividades, Actividades-Actividades y Actividades-Documentos en el modelo creado con la sintaxis concreta (Hernández, 2010).

5.5 Resultados del plan de pruebas

Los resultados obtenidos de las pruebas descritas anteriormente se presentan en esta sección. Se utilizó una representación gráfica para representar los elementos obtenidos de la transformación, sin embargo la salida de la transformación es un archivo XML.

5.5.1 Modelo de integración de protocolo, creado con los escenarios descritos para

el lenguaje visual de dominio específico (Hernández, 2010)

Caso de prueba: Identificación de usuarios Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.1 y se ejecutaron las directrices del primer paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se obtuvieron los siguientes Actores: a. Enfermera


64

b. Médico general c. Médico interno d. Paciente e. Químico

2. Se identificaron a los Actores humanos:

a. Enfermera b. Médico general c. Médico interno d. Paciente e. Químico

3. Se descartaron los Actores que no tenían elementos importantes en la

transformación: a. Médico general b. Paciente c. Químico

Una vez ejecutadas las directrices del paso uno del método de transformación se identificaron los Usuarios mostrados en la figura 5.3; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.

Figura 5.3. Resultado obtenido al aplicar el paso uno del método de

transformación a la figura 5.1.

Observaciones:

Los Usuarios identificados corresponden a los Usuarios definidos en el DSVL (Hernández, 2010), sin embargo se puede dar el caso en que los Usuarios tengan nombres diferentes.

Se descartaron los Usuarios médico general y paciente ya que no tienen Actividades ni Recursos. La herramienta de software descarta automáticamente a estos Usuarios.

Responsable de la prueba: Luis Ángel Chi Islas Cargo: Autor


65

Caso de prueba: Definición del contexto de los usuarios Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.1 y se ejecutaron las directrices del segundo paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se identificaron los siguientes Contextos: a. Cama del paciente b. Laboratorio

2. Se asociaron los Usuarios a los Contextos de la siguiente manera:

a. Enfermera ---> cama del paciente b. Médico interno ---> cama del paciente

c. Químico ---> laboratorio Una vez ejecutadas las directrices del paso dos del método de transformación, se colocaron a los Usuarios en su cuadro de Contexto como se muestra en la figura 5.4; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.


66

Figura 5.4. Resultado obtenido al aplicar el paso dos del método de


Observaciones:

Los Contextos identificados corresponden a los Contextos definidos en la sintaxis concreta (Hernández, 2010).

Se limita a tres Contextos (cama del paciente, sala de juntas, laboratorio) debido a que la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) presenta una plantilla predeterminada para estos, sin embargo la herramienta de transformación permite definir más Contextos.

Aunque el Usuario médico interno puede actuar en el contexto sala de juntas, sólo se limitó a cama del paciente debido a posibles problemas de representación en la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010). Lo anterior viene en base a que se liga al Usuario a un Contexto y no a cada Actividad del Usuario, sin embargo se permite la declaración de muchos Contextos para un Usuario.


Caso de prueba: Identificación de actividades para los

usuarios Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.1 y se ejecutaron las directrices del tercer paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se identificaron las siguientes Actividades dentro del Boundary de cada Actor:

a. Enfermera i. Cuidar al paciente ii. Consultar nota de evolución iii. Consultar receta médica


67

iv. Administrar medicamento al paciente b. Médico interno

i. Tratar al paciente ii. Visitar al paciente iii. Consultar expediente médico iv. Evaluar progreso v. Revisar al paciente vi. Elaborar nota de evolución vii. Elaborar receta médica viii. Recabar información del caso ix. Elaborar resumen clínico x. Redactar diagnostico xi. Consultar historia clínica xii. Solicitar análisis de sangre

xiii. Elaborar nota de evolución xiv. Llenar solicitud de análisis de sangre xv. Reevaluar al paciente xvi. Consultar resultado de análisis de sangre xvii. Examinar al paciente xviii. Realizar examen físico

c. Químico i. Escribir resultados obtenidos ii. Recopilar documentos de análisis iii. Consultar nota de evolución iv. Consultar solicitud de análisis v. Analizar muestra de sangre

2. La identificación de Actividades a partir de las Dependencias de Tarea

no fue posible dado que no se encontró ninguna.

3. No se descartó ninguna Actividad identificada. Una vez ejecutadas las directrices del paso tres del método de transformación, se colocaron a los Usuarios con sus Actividades en su cuadro de Contexto como se muestra en la figura 5.5; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.


68


69

Figura 5.5. Resultado obtenido al aplicar el paso tres del método de transformación a la

figura 5.1.

Observaciones:

Algunas de las Actividades identificadas no tienen asociada una imagen predeterminada en la sintaxis concreta, por lo que la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) podría presentar una imagen por default o generar un error.

Se utilizó una imagen con un contenido aproximado a las Actividades identificadas que no tienen asociada una imagen predeterminada en la sintaxis concreta.

Se detectaron Actividades repetidas, sin embargo estas corresponden a diferentes estructuras de Descomposición de Tareas o Means-End del modelo fuente.


Caso de prueba: Identificación de documentos para los


Se seleccionó el modelo de integración de protocolo de la figura 5.1 y se ejecutaron las directrices del cuarto paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se identificaron los siguientes Documentos dentro del Boundary de cada Actor:


70

a. Enfermera i. Nota de evolución ii. Receta médica

b. Médico interno i. Resultados de análisis de sangre ii. Observaciones médicas iii. Información del paciente

c. Químico i. Muestra de sangre ii. Solicitud de análisis de sangre iii. Nota de evolución

2. La identificación de Documentos a partir de las Dependencias de

Recursos no fue posible dado que no se encontró ninguno.

3. No se descartó ningún Recurso identificado.

Una vez ejecutadas las directrices del paso cuatro del método de transformación, se colocaron a los Usuarios con los Documentos en su cuadro de Contexto como se muestra en la figura 5.6; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.


71

Figura 5.6. Resultado obtenido al aplicar el paso cuatro del método de transformación a la

figura 5.1.

Observaciones:

Algunos de los Documentos identificados no tienen asociado una imagen predeterminada en la sintaxis concreta, por lo que la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) podría presentar una imagen por default o generar un error.

Se utilizó una imagen con un contenido aproximado a los Recursos identificados que no tienen asociado una imagen predeterminada en la sintaxis concreta.


Caso de prueba: Relaciones entre actividades y documentos Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.1 y se ejecutaron las directrices del quinto paso del método de transformación. Los

resultados de las directrices se muestran a continuación.

1. Se identificaron las Actividades iníciales para cada Usuario: a. Enfermera

i. Cuidar al paciente b. Médico interno

i. Tratar al paciente c. Químico

i. Recopilar documentos de análisis ii. Analizar muestra de sangre


72

iii. Escribir resultados obtenidos

2. Se identificaron las siguientes relaciones entre Actividades a partir de las relaciones de Descomposición y Means-End del modelo de integración de protocolo:

a. Enfermera i. Relación secuencial

Cuidar al paciente (padre)

Consultar nota de evolución (hijo)

Consultar receta médica (hijo)

Administrar medicamento al paciente (hijo) b. Médico interno

i. Relación secuencial

Tratar al paciente (padre)

Visitar al paciente (hijo)

Revisar al paciente (hijo - padre)

Consultar expediente médico (hijo)

Evaluar progreso (hijo - padre)

Elaborar nota de evolución (hijo)

Elaborar receta médica (hijo)

Recabar información del caso (hijo - padre)

Elaborar resumen clínico (hijo)

Redactar diagnostico (hijo)

Consultar historia clínica (hijo)

Solicitar análisis de sangre (hijo - padre)

Elaborar nota de evolución (hijo)

Llenar solicitud de análisis de sangre (hijo)

Reevaluar al paciente (hijo - padre)

Consultar resultado de análisis de sangre (hijo)

Examinar al paciente (hijo - padre)

Realizar examen físico (hijo) c. Químico

i. Relación discontinua

Químico (padre)

Escribir resultados obtenidos (hijo)

Recopilar documentos de análisis (hijo)

Analizar muestra de sangre (hijo) ii. Relación secuencial

Recopilar documentos de análisis (padre)

Consultar nota de evolución (hijo)

Consultar solicitud de análisis (hijo)

3. Se identificaron las siguientes relaciones entre Actividades y Documentos a partir de las Dependencias de Recursos del modelo de integración de protocolo:

a. Enfermera


73

i. Consultar nota de evolución (padre)

Nota de evolución (hijo) ii. Consultar receta médica (padre)

Receta médica (hijo) b. Médico interno

i. Consultar resultado de análisis de sangre (padre)

Resultados de análisis de sangre (hijo) ii. Recabar información del caso (padre)

Observaciones médicas (hijo) iii. Tratar al paciente (padre)

Información del paciente (hijo) c. Químico

i. Consultar nota de evolución (padre)

Nota de evolución (hijo) ii. Consultar solicitud de análisis (padre)

Solicitud de análisis de sangre (hijo) iii. Analizar muestra de sangre (padre)

muestra de sangre (hijo) Una vez ejecutadas las directrices del paso cinco del método de transformación, se obtuvo el diagrama que se muestra en la figura 5.7; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.


74


75


5.1.

Observaciones:

El orden de las Actividades puede variar de acuerdo a la necesidad de la persona que lleva a cabo la transformación.

El modelo final es una aproximación a los ejemplos que encontrados en el trabajo del lenguaje visual de dominio específico (Hernández, 2010)

Mientras más específico sea el modelo de integración de protocolos con las Tareas que realizan los Actores y los Recursos que estos utilizan, se tendrá mayor detalle al momento de generar un modelo de sintaxis concreta.

El diagrama mostrado en esta prueba es una posible representación de la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010). La salida de la herramienta que apoya al método de transformación es un archivo XML.


5.5.2 Modelo de integración de protocolo, traducción de un modelo negocios

encontrado en tesis doctoral (Yu, 1995)

Caso de prueba: Identificación de usuarios Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.2 y se ejecutaron las directrices del primer paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se obtuvieron los siguientes Actores: a. Compañía de seguros b. Médico c. Paciente

2. Se identificaron a los Actores humanos:


76

a. Médico b. Paciente

3. Se descartaron los Actores que no eran importantes en la

transformación: a. Paciente

Una vez ejecutadas las directrices del paso uno del método de transformación se identificaron los Usuarios mostrados en la figura 5.8; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.

Figura 5.8. Resultado obtenido al aplicar el paso uno del método de


Observaciones:

Médico y compañía de seguros no corresponden a los Usuarios definidos en el DSVL (Hernández, 2010), sin embargo el Usuario médico cae dentro de la categoría definida en el paso dos del método de transformación.

Se descartaron los Usuarios paciente y compañía de seguros, debido a que paciente no contiene Actividades de interés ni es un Usuario primario en la sintaxis concreta del DSVL (Hernández, 2010) y la compañía de seguros es una entidad abstracta.

Se utilizó la imagen del médico interno para representar al Usuario médico identificado en este modelo de integración de protocolo.


Caso de prueba: Definición del contexto de los usuarios Resultado: OK

Se seleccionó el modelo de integración de protocolo de la figura 5.2 y se ejecutaron las directrices del segundo paso del método de transformación. Los resultados de las directrices se muestran a continuación.

1. Se identificaron los siguientes Contextos: a. Cama del paciente


77

2. Se asociaron los Usuarios a los Contextos de la siguiente manera: a. Médico ---> cama del paciente

Una vez ejecutadas las directrices del paso dos del método de transformación se colocaron a los Usuarios en su cuadro de Contexto como se muestra en la figura 5.9; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.

Figura 5.9. Resultado obtenido al aplicar el paso dos del método de


Observaciones:

Los Contextos identificados corresponden a los Contextos definidos en la sintaxis concreta del DSVL (Hernández, 2010).

Se limita a tres Contextos (cama del paciente, sala de juntas, laboratorio) debido a que la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) presenta una plantilla predeterminada para estos.

Aunque el Usuario médico no se encuentra definido como tal en los Usuarios de la sintaxis concreta del DSVL (Hernández, 2010), se le asoció el Contexto cama del paciente por ser el más acorde dentro de su categoría.


Caso de prueba: Identificación de actividades para los




78

1. Se identificaron las siguientes Actividades dentro del Boundary de cada Actor:

a. Médico interno i. Ejecutar práctica médica ii. Tratar paciente con seguro completo iii. Tratar paciente con seguro MGD iv. Diagnosticar enfermedad v. Tratar enfermedad vi. Pasar la cuenta a la compañía de seguro vii. Tratar a miembro de HMO

2. Se descartaron las siguientes Actividades:

i. Ejecutar práctica médica ii. Pasar la cuenta a la compañía de seguro

3. La identificación de Actividades a partir de las Dependencias de Tarea no

fue posible dado que no se encontró ninguna. Una vez ejecutadas las directrices del paso tres del método de transformación se colocaron a los Usuarios con sus Actividades en su cuadro de Contexto como se muestra en la figura 5.10; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.

Figura 5.10. Resultado obtenido al aplicar el paso tres del método de transformación a la figura

5.2.


79

Observaciones:

Algunas de las Actividades identificadas no tienen asociada una imagen predeterminada en la sintaxis concreta, por lo que la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) podría presentar una imagen por default o generar un error.

Se utilizó una imagen con un contenido aproximado a las Actividades identificadas que no tienen asociada una imagen predeterminada en la sintaxis concreta.

Las Actividades identificadas no corresponden a ninguna de la lista de actividades definidas en el trabajo del lenguaje visual de dominio específico (Hernández, 2010), a pesar de esto se utilizaron como una sugerencia de posibles nuevas Actividades.


Caso de prueba: Identificación de documentos para los



1. No se identificaron Documentos dentro del boundary del Actor:

2. Se identificaron los siguientes Documentos a partir de las Dependencias de Recursos del Actor.

a. Médico i. Reembolso ii. Aprobación (tratamiento) iii. Reembolso iv. Pago por miembro del plan

3. Se descartaron lo siguientes Documentos por no tener relación con el

dominio médico: a. Médico

i. Reembolso ii. Aprobación (tratamiento) iii. Reembolso

iv. Pago por miembro del plan

Observaciones:

No se tomó en cuenta ninguno de los Documentos identificados ya que no tienen relación con el dominio médico y no cumplen con la directriz 4.3 del paso cuatro del método de transformación



80

Caso de prueba: Relaciones entre actividades y documentos Resultado: OK


1. Se identificaron las Actividades iníciales para el Usuario: a. Médico

i. Tratar paciente con seguro completo ii. Tratar paciente con seguro MGD iii. Tratar a miembro de HMO

2. Se identificaron las siguientes relaciones entre Actividades a partir de las

relaciones de Descomposición y Means-End del modelo de integración de protocolo:

a. Médico interno i. Relación discontinua

Médico (padre)

Tratar paciente con seguro completo (hijo)

Tratar paciente con seguro MGD (hijo)

Tratar a miembro de HMO (hijo) ii. Relación secuencial

Tratar paciente con seguro MGD (padre)

Tratar enfermedad (hijo)

Diagnosticar enfermedad (hijo)

3. No se identificaron relaciones entre Actividades y Documentos, ya que se descartaron los Documentos en el paso cuatro.

Una vez ejecutadas las directrices del paso cinco del método de transformación se obtuvo el diagrama que se muestra en la figura 5.11; se presenta un extracto del archivo XML generado a partir del modelo de integración de protocolo utilizado.


81

Figura 5.11. Resultado obtenido al aplicar el paso cinco del método de transformación a la

figura 5.2.

Observaciones:

El orden de las Actividades puede variar de acuerdo a la necesidad de la persona que lleva a cabo la transformación.

Mientras más específico sea el modelo de integración de protocolos con las tareas que realizan los actores y los recursos que estos utilizan, se tendrá mayor detalle en el modelo con la sintaxis concreta.

El modelo resultante posiblemente tenga que ser enriquecido para poder generar una aplicación de ambientes inteligente con el proceso descrito en el trabajo del lenguaje visual de dominio específico (Hernández, 2010).

El diagrama mostrado en esta prueba es una posible representación de la herramienta propuesta en el trabajo del lenguaje visual de dominio específico (Hernández, 2010). La salida de la herramienta que apoya al método de transformación es un archivo XML.



82

5.6 Análisis de resultados

Los resultados obtenidos del plan de pruebas sirvieron para comprobar que mediante la aplicación del método de transformación es posible obtener modelos creados con la sintaxis concreta del DSVL (Hernández, 2010). Sin embargo, se observó que no todas las Tareas del modelo de integración de protocolo llegan a ser significativas como para ser mapeadas a Actividades en la sintaxis concreta del DSVL, al igual que los Recursos a Documentos. También se observó que en el modelo de integración de protocolo se especifica la acción a realizar con un Recurso mediante una Tarea, a su vez, este Recurso es relacionado con dicha acción. A diferencia de la sintaxis concreta en la cual un Documento, producto de un Recurso, es ligado a una acción escribir, consultar o seleccionar, la cual no es una Actividad producto de una Tarea. Las Actividades, Documentos, Usuarios y relaciones generadas con el método de transformación son una aproximación a los posibles escenarios definidos en el trabajo del lenguaje visual de dominio específico (Hernández, 2010), por lo cual estos elementos deben ser complementados por la persona encargada de llevar a cabo la transformación. Es importante mencionar que no es posible encontrar los mismos nombres de los elementos Usuarios, Actividades y Documentos de la sintaxis concreta definidos como Actores, Tareas y Recursos en el modelo de integración de protocolo, dando lugar a que la mayoría de los elementos, producto del método de transformación, que se encuentren sean sugerencias de posibles nuevos elementos. Al tratarse de un DSVL, se limitó al modelo de integración de protocolo a ser del dominio médico, específicamente al cuidado del paciente.

Capítulo 6. Conclusiones

83

CAPÍTULO 6. CONCLUSIONES

En este capítulo se presentan las conclusiones de este trabajo de investigación, incluyendo las contribuciones realizadas, las publicaciones producidas y los trabajos futuros.

6.1 Conclusiones

Esta tesis presenta un método de transformación el cual vincula los requerimientos tardíos representados con el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010) y requerimientos tempranos representados con el lenguaje visual de dominio específico (Hernández, 2010). El método de transformación pretende ser integrado al enfoque MDD descrito en el trabajo del lenguaje visual de dominio específico (Hernández, 2010), participando en la transformación de CIM a PIM. Cabe mencionar que el enfoque MDD mencionado anteriormente tiene como meta final generar aplicaciones de ambientes inteligentes con la tecnología RFID.

El siguiente objetivo principal fue propuesto para dar solución al problema planteado en esta tesis: “Definir un método que permita la transformación de un modelo de

negocios i* a un modelo creado con la sintaxis concreta de un lenguaje visual de dominio especifico”

A continuación se listan los tres objetivos específicos que ayudaron a

cumplir con el objetivo principal, en los cuales se incluye las actividades realizadas en cada uno de ellos y que se obtuvo:

1. Analizar los meta-modelos del modelo de negocios basado en i* y del lenguaje visual de dominio especifico.

Para cumplir este objetivo se llevó a cabo el análisis presentado en la sección 4.1. En este análisis se identificaron los elementos que integran ambos meta-modelos y las relaciones que se pueden dar entre ellos, con el propósito de conocerlos a detalle y posteriormente realizar una comparativa entre ellos.

2. Definir las reglas de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio especifico (Hernández, 2010).

Para cumplir este objetivo se realizó la comparativa entre los elementos y las relaciones presentadas en la sección 4.2, dando lugar al método de transformación presentado en la sección 4.3. La comparativa entre elementos y las relaciones entre ellos, se enfocó en identificar elementos y relaciones que permitieran generar modelos en la sintaxis concreta (Hernández, 2010) a partir de un modelo de integración de protocolo (Morales, 2010). El método de transformación que permite generar los modelos en la sintaxis concreta


84

(Hernández, 2010), se encuentra formado de una serie de directrices las cuales describen una serie de criterios que deben cumplir los elementos identificados en la comparativa de la sección 4.2. El lenguaje visual de dominio específico (Hernández, 2010) se encuentra limitado a un dominio específico y los elementos de la sintaxis concreta y abstracta fueron diseñados y validados para representar determinados escenarios, al contrario del lenguaje de modelado para un nuevo proceso de negocios semántico (Morales, 2010) el cual puede ser aplicado a cualquier dominio y con distintos escenarios. Lo anterior presentó una limitante en el método de transformación ya que es poco probable encontrar los mismos nombres de los elementos de la sintaxis concreta y abstracta del lenguaje visual de dominio específico (Hernández, 2010) en los modelos generados con el lenguaje de modelado para un nuevo proceso de negocios semántico (Morales,

2010), sin embargo el método de transformación fue propuesto a partir de los meta-modelos el cual permite realizar la transformación identificando los elementos predefinidos para el lenguaje visual de dominio específico (Hernández, 2010) y proponiendo nuevos que pueden ser de interés en un escenario.

3. Desarrollar una aplicación software que soporte el método de transformación entre el modelo de negocios basado en i* (Morales, 2010) y un modelo creado con la sintaxis concreta de un lenguaje visual de dominio especifico (Hernández, 2010).

Para cumplir este objetivo se diseñó y codificó la herramienta de la sección 4.5, la cual hace uso de los archivos XML de la sección 4.4 que almacenan los modelos de negocios y los modelos en la sintaxis concreta. La herramienta implementa el método de transformación y se encarga de guiar al usuario de esta mediante una serie de etapas, indicando que se debe de realizar en cada una de las etapas. En base a lo obtenido de los tres objetivos específicos se concluye que es posible generar modelos con la sintaxis concreta de acuerdo a la equivalencia entre elementos y relaciones de los meta-modelos, aun cuando no todos los elementos transformados pertenezcan a la lista de elementos (actividades, usuarios y documentos) definidos en el lenguaje visual de dominio específico (Hernández, 2010). Algunos casos en el que un IntentionalElement de tipo Goal, tal como "Curar al paciente", puede dar lugar a una Actividad de la sintaxis concreta, sin embargo por la definición y el uso del elemento éste no fue considerado dentro de la transformación.

Se tiene la certeza que si el lenguaje visual de dominio específico (Hernández, 2010) tuviera un cambio de dominio, el método de transformación únicamente presentaría cambios en la definición de los contextos y la categorización de los usuarios a identificar.

6.1.1 Contribuciones

A continuación se presenta la lista de contribuciones realizadas en esta tesis:


85

Conjunto de directrices que permiten realizar la transformación de un modelo de negocios en i* a un modelo de sintaxis concreta de un DSVL.

Una herramienta para la transformación semiautomática de modelos de negocios en i* a modelos de un DSVL.

XML para almacenar los modelos creados con el lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010).

6.2 Publicaciones

El trabajo de investigación desarrollado en esta tesis produjo dos publicaciones, las cuales se presentan a continuación:

Chi, L., López, M. & Martínez, A., “Análisis de Métodos de Transformación de Modelos de Negocios a Modelos de Conceptuales”, Vigesimosegunda reunión internacional de otoño, de comunicaciones, computación, electrónica, automatización, robótica y exposición industrial, IEEE, Guerrero.

Chi, L., López, M., González, G. & Martínez, A., “Representación gramatical de meta-modelos utilizando GEBNF”, Undécima Conferencia Iberoamericana en Sistemas, Cibernética e Informática: CISCI 2012, International Institute of Informatics and Systemics, Orlando, p. 155-159.

6.3 Trabajos futuros

Con las contribuciones de esta tesis se proponen los siguientes trabajos:

Aplicar el método de transformación en otros DSVL's que sigan el mismo enfoque presentado en el trabajo del lenguaje visual de dominio específico (Hernández, 2010) pero con diferente dominio.

Extender el método de transformación a otras variantes del marco de trabajo i*, por ejemplo Tropos.

Anexos

86

ANEXO A

Este anexo muestra los usuarios definidos en el trabajo lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010), los cuales fueron utilizados para representar de manera gráfica la salida del método de transformación.

Tabla anexo A. Usuarios utilizados en la sintaxis concreta (Hernández, 2010).

Usuario Nueva representación

Químico

Médico

General

Médico

Interno

Enfermera

ANEXO B

Este anexo muestra las actividades definidas en el trabajo lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010), las cuales fueron utilizadas para representar de manera gráfica la salida del método de transformación.

Tabla anexo B. Actividades utilizadas en la sintaxis concreta (Hernández, 2010).

Actividad Nueva

representación

Examina

evidencia

clínica

Anexos

87

Realiza

interconsulta

médica

Realiza

Prescripción

médica

Reúne

evidencia

clínica

Evalúa el

progreso del

paciente

Revisa al

paciente

Visita al

paciente

Visita al

paciente

Visita al

paciente

Anexos

88

Visita al

paciente

Valora al

paciente

Administra

medicamento

s

Solicita

análisis de

sangre

Analiza

resultado de

laboratorio

Toma muestra

Realiza

análisis de

sangre

Busca focos de

infección

Comunicación

con el equipo

médico

Anexos

89

Establece

pautas: Dx y

Tx

Reevalúa al

paciente

Discute caso

clínico

ANEXO C

Este anexo muestra los documentos definidos en el trabajo lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010), los cuales fueron utilizados para representar de manera gráfica la salida del método de transformación.

Tabla anexo C. Documentos utilizados en la sintaxis concreta (Hernández, 2010).

Usuario Nueva

representación

Registro

Clínico de

Enfermería

Pronóstico

Conclusiones

Interconsult

a médica

http://www.google.com.mx/imgres?um=1&hl=es&biw=1311&bih=625&tbm=isch&tbnid=K-cl2fCqPtDBRM:&imgrefurl=http://proyecto1-joseline-pamela.wikispaces.com/conclusiones&docid=HsTexdceGskM1M&imgurl=http://proyecto1-joseline-pamela.wikispaces.com/file/view/conclusiones.jpg/201240284/conclusiones.jpg&w=743&h=340&ei=WohBT726AuSQ2AWT1fmgCA&zoom=1&iact=rc&dur=263&sig=113913456918251461350&page=7&tbnh=89&tbnw=195&start=145&ndsp=24&ved=0CPEFEK0DMKMB&tx=94&ty=40

Anexos

90

Resumen

Clínico

Historia

Clínica

General

Notas de

Evolución

Solicitud de

Laboratorio

Diagnóstico

Receta

Médica

Expediente

Clínico

Anexos

91

ANEXO D

Este anexo muestra los operados definidos en el trabajo lenguaje visual de dominio específico para el desarrollo de ambientes inteligentes basado en MDD (Hernández, 2010), los cuales fueron tomados en cuenta para su representación en el archivo XML definido en la sección 4.4.2.

Tabla anexo D. Operadores utilizados en la sintaxis abstracta (Hernández, 2010). Operador Descripción

Concurrencia independiente

(Independent Concurrence)

(T1 ||| T2)

Acciones que pertenecen a dos tareas que

pueden ser desarrolladas en algún orden sin

restricciones.

Elección (Choice)

(T1 [] T2)

Consiste elegir una tarea de un conjunto de

tareas, una vez elegida ésta, otras tareas no

pueden desarrollarse hasta que sea

terminada la tarea elegida.

Concurrencia con

intercambio de información

(Concurrence with

information exchange)

(T1 |[] T2)

Dos tareas pueden ser realizadas

concurrentemente pero tienen que estar

sincronizadas para intercambiar información.

Orden independiente

(Independent order) T1 |= |

T2

Ambas tareas tienen que ser realizadas; la

segunda necesita que la primera se finalice

para que ésta ser realizada.

Desactivación (Deactivation)

(T1 [> T2)

La primera tarea es definitivamente

desactivada si la primera acción de la

segunda tarea ha sido desarrollada.

Habilitación (Enabling)

(T1 >> T2)

En este caso una tarea habilita a la segunda

una vez que termine de ejecutarse ésta.

Habilitación con paso de

información (Enabling with

information passing)

(T1 [] >> T2)

La tarea T1 proporciona información a la

tarea T2 después de habilitarla.

Suspender- Reanudar

(Suspend-resume)

(T1 |> T2)

Este operador da a T2 la posibilidad de

interrumpir a T1 y después que T2 es

terminada T1 puede reactivar su estado

anterior a la interrupción.

Iteracción (Iteration)

T*

Las tareas son desarrolladas repetitivamente.

Iteracción finita (Finite

Iteraction)

(T1(n))

Es usado cuando se conoce cuantas veces

una tarea será desarrollada.

Tarea opcional (Optional

Task)

([T])

Indica que el desarrollo de una tarea es

opcional.

Recursión (Recursion)

Existe cuando en el desarrollo de la tarea

puede ocurrir una ocurrencia de sí misma.

Anexos

92

ANEXO E

Este anexo muestra la estructura básica que deben cumplir los archivos XML para almacenar modelos de integración de protocolo (Morales, 2010). Una estructura más detallada y completa se encuentra en IStarML (Cares, 2007). <?xml version="1.0" encoding="ISO-8859-1"?> <istarml version="1.1"> <diagram autor="" id="" name=""> <ielement id="" name="" type=""/>  <actor id="" name="" type="">  <boundary>  <ielement id="" name="" type=""/>  . . . <ielement id="" name="" type="">  <ielementlink type="" value="">  <ielement id="" name="" type="">  <ielementlink type="" value=""> <ielement id="" name="" type=""/> . . . </ielementlink> </ielement> </ielementlink> </ielement> </boundary> </actor> <actor id="" name="" type=""/>  <techmodule name="">  </techmodule> <ielement id="" name="" type="">  <dependency> <depender iref="" aref=""/>  <dependee iref="" aref=""/>  </dependency> </ielement> .

Anexos

93

. . <ielement id="" name="" type="">  <dependencym>  <dependerm iref="" aref=""/> <dependeem iref="" aref=""/> </dependency> </ielement> </diagram> </istarml>

Referencias

94

REFERENCIAS

Alencar, F., Marín, B., Giachetti, G., Pastor, O., Castro, J. & Henrique Pimentel J., (2009), From i* Requirements Models to Conceptual Models of a Model Driven Development Process, In: Proceedings of PoEM, Springer, Heidelberg, p. 99-114. Altheide, F., Dörfel, S., Dörr, H. & Kanzleiter, J., (2003), An architecture for a sustainable tool integration framework, In: Schürr and Dörr , The 9th European Software Engineering Conference and 11th ACM SIGSOFT Symposium on the Foundations of Software Engineering, Helsinki, p. 29–32. Ameedeen, M.A., Bordbar, B. & Anane, R., (2011), Model interoperability via Model Driven Development, In: Journal of Computer and System Sciences,

Elsevier, p. 332-347. Ameller, D., Franch, X., Cabot, J., (2010), Dealing with Non-Functional Requirements in Model-Driven Development, In: 18th IEEE International Requirements Engineering Conference, IEEE Computer Society Publication, Sidney, p. 189-198. Atkinson, C. & Kühne, (2003), Model-Driven Development: A Metamodeling Foundation, In: IEEE Software 20, IEEE Computer Society Publication, p. 36-41. Bandara, W., Tan, H. M., Recker, J., Indulska, M., & Rosemann, M. (2009). Bibliography of process modeling: An Emerging research field, In: Unpublished results, Queensland University of Technology, Australia. Bergholtz, M., Jayaweera, P., Jayaweera, P., & Wohed, P. (2002). Process Models and Business Models - A Unified Framework, In: Conceptual Modeling - ER, 21st International Conference on Conceptual Modeling, Springer, Heidelberg, p. 364-377. Barros, J.P. & Gomes, L, (2000), From Activity Diagrams To Class Diagrams, In: Workshop Dynamic Behaviour in UML Models: Semantic Questions in Conjunction with Third International Conference on UML, York. Business Process Management Initiative, (2011), Business Process Model and Notation (BPMN) Version 2.0, Object Management Group (OMG), Document

formal/2011-01-03. Cares, C., Franch, X., Perini, A. & Susi, A., (2007), IStarML. The i* Mark-up Language: REFERENCE’S GUIDE, Technical Report. Cares, C.,Franch, X., Perini, A. & Susi, A., (2011), Towards interoperability of i* models using iStarML, In: Computer Standards & Interfaces, Elsevier, Amsterdam, p. 69-79.

Referencias

95

Castro, V.D., Marcos, E. & Vara, J.M., (2011), Applying CIM-to-PIM Model Transformations For The Service-Oriented Development Of Information Systems, In: Information & Software Technology, Elsevier, Newton, p. 87-105. Czarnecki, K. & Helsen, S., (2006), Feature-based survey of model transformation approaches, In: IBM Systems Journal, IBM Corp, Riverton, p. 621-645. CENIDET, (2010), ProAMI: Plataforma de Modelado Conceptual para Ambientes Inteligentes basado en MDD, Proyecto, Centro Nacional de Investigación y Desarrollo Tecnológico, Departamento de Ciencias Computacionales. Dijkman, R.M. & Joosten, S.M.M, (2002), An Algorithm to Derive Use Cases from Business Processes, In: 6th IASTED International Conference on Software

Engineering and Applications, M.H. Hamza, Boston, p. 679-684. Ehrig, K. & Winkelmann, J., (2006), Model Transformation From VisualOCL to OCL Using Graph Transformation, In: Electronic Notes in Theoretical Computer Science, Elsevier, Amsterdam, p. 23-37. Estrada Esquivel, Hugo, (2008), A service-oriented approach for the i* framework, PhD Thesis, Universidad Politécnica de Valencia, Departamento de Sistemas Informáticos y Computación. García Molina, J., Ortín, M.J., Moros, B., Nicolás, J. & Toval, A., (2000) Towards Use Case and Conceptual Models Through Business Modeling, In: 19th International Conference on Conceptual Modeling, Springer, Utah, p. 281-294. Hernández Ramírez, K., (2010), Lenguaje de Modelado para el Desarrollo de Ambientes Inteligentes RFID Basado en MDD, Tesis de maestría, Centro Nacional de Investigación y Desarrollo Tecnológico, Departamento de Ciencias Computacionales. Jouault, F., Allilaire, F., Bézivin, J. & Kurtev I., (2008), ATL: A Model Transformation Tool, In: Science of Computer Programming, Elsevier, Amsterdam, p. 31-39. Kleppe, A., Warmer, J. & Bast, W., (2003), MDA Explained, The Model-Driven Architecture: Practice and Promise, Addison Wesley, Boston.

Königs, A., (2005), Model Transformation with Triple Graph Grammars, In: Model Transformations in Practice Satellite Workshop of MODELS, Springer, Heidelberg. Loucopoulos, P. & Kavakli, E., (1995), Enterprise Modelling and the Teleological Approach to Requirements Engineering, In: International Journal of Intelligent and Cooperative Information Systems, p. 45-79.

Referencias

96

Loucopoulos, P. & Kavakli, V., (1997), Enterprise Knowledge Management and Conceptual Modelling, In: Conceptual Modeling (ER’97), Springer, p. 123-143. Martínez Rebollar, Alicia, (2008), Conceptual Schema Generation from Organizational Models in an Automatic Software Production Process, PhD Thesis, Universidad Politécnica de Valencia, Departamento de Sistemas Informáticos y Computación. Mellor, Stephen J., Clark, Anthony N. & Futagami, T., (2003), Guest Editors' Introduction: Model-Driven Development, In: IEEE Software 20, IEEE Computer Society Publication, p. 14-18. Morales Gonzáles, E., (2010), Especificación de un lenguaje de modelado orientado a servicios para procesos de negocio con nuevas tecnologías de información, Tesis de maestría, Centro Nacional de Investigación y Desarrollo Tecnológico, Departamento de Ciencias Computacionales. Murzek, M., Kramler, G., Michlmayr, E. (2006), Structural Patterns for the Transformation of Business Process Models, In: 10th IEEE on International Enterprise Distributed Object Computing Conference Workshops, IEEE Computer Society Publication, Washington, p. 18-28. Mylopoulos, J., (1992), Conceptual Modelling and Telos, Technical Report, University of Toronto, Department of Computer Science. Noran S.O. (2000), Business Modelling: UML vs. IDEF, Technical Report, Griffith University, New Zealand. Pastor, O., Gómez, J., Insfran, E. & Pelechano V., (2001), The OO-Method Approach For Information Systems Modeling: From Object-Oriented Conceptual Modeling To Automated Programming, In: Information Systems 26, p. 507-534. Paterno, F., Mancini, C. & Meniconi, (1997), S. ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models, In: IFIP TC13 International Conference on Human-Computer Interaction (INTERACT’97), Chapman & Hall, London, p. 362-369. Santander, V. & Castro, J. (2002). Integrating Use Cases And Organizational Modeling, In: XVI Brazilian Symposium on Software Engineering, Gramado, p. 222-253.

Santillán Hernández, Luis C., (2011), Creación de un Método de Modelado Organizacional Enfocado a Nuevas Tecnologías de Información, Propuesta de tesis, Centro Nacional de Investigación y Desarrollo Tecnológico, Departamento de Ciencias Computacionales. Sendall, S. & Kozaczynski, W., (2003), Model Transformation: The Heart and Soul of Model-Driven Software Development, In: IEEE Software 20, IEEE Computer Society Publication, p. 42-45.

Referencias

97

Suarez, E., Delgado, M. & Vidal, E., (2008), Transformation of a Process Business Model to Domain Model, In: World Congress on Engineering, Newswood Limited, Londres, p. 165-169. Rodríguez, A., Fernández-Medina, E. & Piattini, M., (2008), Towards Obtaining Analysis-Level Class and Use Case Diagrams from Business Process Models, In: 4º International Workshop on Foundations and Practices of UML (FP-UML), Springer, Barcelona, p. 103-112. Rungworawut, W. and Senivongse, T., (2005), A guideline to mapping business processes to UML class diagrams, In: WSEAS Transactions on Computers, p. 1526-1533. Tapia D. I., Abraham, A., Corchado, J. M. & Alonso, R. S. (2009), Agents and Ambient Intelligence: Case Studies, In: Ambient Intelligence and Humanized Computing, p. 85-93. Timmers, P. (1998), Bussines Models for Electronic Markets. In: EM International Journal of Electronic Markets 2, p. 3-8. van Deursen, A., Klint, P., Visser, J.,(2000), Domain-specific languages: An annotated bibliography, In: ACM SIGPLAN Notices, ACM Press, New York, p. 26-36. Xu, J., Jin, L., & Zhu, H., (1996), Tool support of orderly transition from informal to formal descriptions in requirements engineering, In: IFIP World Conference on IT Tools, p. 199-206. Yu, E. & Liu, L. (2001), Modelling Trust for System Design Using the i* Strategic Actors Framework, In: Proceedings of the Workshop on Deception, Springer, London, p. 175-194. Zhu, H., (2008), An Institution Theory of Formal Meta-Modelling in Graphically Extended BNF, In: Frontier of Computer Science, Springer, Secaucus, p. 40-56. Zhu, H., (2010), On the Theoretical Foundation of Meta-Modelling in Graphically Extended BNF and First Order Logic, In: 4th IEEE International Symposium on Theoretical Aspects of Software Engineering, IEEE Computer Society, Washington, p. 95-104. Zhu, H. & Shan, L., (2006), Well-Formedness, Consistency and Completeness of Graphic Models, In: Proc. of UKSIM’06, Oxford, p. 47-53.

TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Luis Angel Chi... · IDentification), por lo tanto,...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS - cenidet.edu.mx Luis Angel Chi... · IDentification), por lo tanto,...