TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA … · 2014-02-13 · Garcia 2006]. In this...

cenidet

Centro Nacional de Investigación y Desarrollo Tecnológico

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA COMPUTACIÓN

Modelado y Transformación entre Modelos que Satisfacen los Niveles de Abstracción del CIM y del PIM

presentada por

Luis Adrián García García Ingeniero en Sistemas Computacionales en Programación

por el Instituto Tecnológico de Celaya

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

Director de tesis:

Dr. Moisés González García

Co-Director de tesis: Dr. Hugo Estrada Esquivel

Jurado:

Dr. Máximo López Sánchez – Presidente Dr. René Santaolaya Salgado – Secretario

Dr. Moisés González García – Vocal Dr. Guillermo Rodríguez Ortiz – Vocal Suplente

Cuernavaca, Morelos, México. Mayo de 2011

DEDICATORIAS

Por todo su amor y apoyo a Miriam

Por su amor y comprensión a Sandra Yarely, Nancy Adriana y Luis Efrén

AGRADECIMIENTOS

A Dios.

A Miriam, mi esposa.

A Sandra, Nancy y Efrén, mis hijos.

A Hipólita e Inocencio, mis papás.

Gracias a las Autoridades del Instituto Tecnológico de Cuautla, por el apoyo.

Gracias al CENIDET, por darme la oportunidad.

Gracias al CONACyT, por el apoyo.

Gracias a mis profesores del CENIDET por compartir sus conocimientos.

Gracias a mis compañeros de maestría por la convivencia, especialmente a Miriam.

Gracias a mi Director de Tesis.

RESUMEN En la actualidad, un enfoque muy aceptado en la comunidad de desarrollo de software, es utilizar los diagramas UML de acuerdo a los niveles de abstracción propuestos en MDA, para modelar el desarrollo de software.

Existen herramientas, para el diseño de modelos y la transformación entre ellos de forma automática. Sin embargo, no se conocen las especificaciones de las operaciones de transformación que realizan.

Actualmente, en el CENIDET, se está desarrollando una Herramienta de transformación de modelo a modelo, que permitirá obtener un modelo destino a partir de un modelo origen, considerando los niveles MDA. Esta herramienta formará parte del ambiente AGDE, propuesto por [González-García 2006]. En este contexto, se realizó esta investigación, con el objetivo de determinar cuáles son las operaciones elementales (incluyendo operadores, operandos y reglas) para realizar la transformación de modelos en los niveles CIM a PIM. En esta investigación se propone:

Un modelo de transformación en los niveles CIM y PIM (§6). Este modelo consiste en un conjunto de transformaciones lineales semiformalizadas para los diagramas UML. Cada transformación incluye:

o Una función de transformación, que consta de reglas de mapeo y operaciones entre diagramas UML.

Para la propuesta de este modelo, fue necesario definir una propuesta de

características de diagramas UML en los niveles CIM y PIM. También se requirió analizar la forma en que se hace el proceso de software basado en modelos. Lo cual, dio resultados importantes en esta investigación, los cuales a continuación se enlistan:

Una descripción de las características, elementos, reglas y restricciones de diseño de nivel CIM y PIM de cada diagrama UML (§4.2). Esta descripción facilita la determinación de las operaciones y reglas de mapeo entre diagramas.

Estructuras jerárquicas de la información proporcionada por cliente(s) y analista(s) (§5.3). Estas estructuras permiten organizar la información que proporcionan los cliente(s) y analista(s), la cual es necesaria tanto para crear como para transformar los diagramas UML.

Un procedimiento de modelado de software en los niveles CIM y PIM (§6). Este procedimiento describe la construcción de diagramas UML en cada nivel, a partir de la información proporcionada por cliente(s) y analista(s) del sistema. Esta información tiene un papel primordial en la transformación de diagrama, la cual fue considerada en la función de transformación propuesta en esta investigación.

Los resultados permitirán continuar la construcción de la Herramienta de transformación de modelo a modelo, para el ambiente AGDE.

ABSTRACT

Currently, a widely accepted approach in the software development community is the employment UML diagrams according to the levels of abstraction proposed MDA to model software development.

There are tools for the design of models and the automatic transformation between them. However, the specifications of the processing operations they perform are not know.

Currently in CENIDET, a tool for the transformation from model to model is being developed. It will produce a target model from a source model, considering the different MDA levels. This tool will form part of the environment AGDE proposed by [Gonzalez-Garcia 2006].

In this context, this research was conducted with the aim of identifying the elementary operations (including operators, operands and rules) to perform the transformation of models in CIM to PIM levels.

This research is twofold: • A transformation model in CIM and PIM levels (§ 6). This model consists of a set of linear transformations semi formalized for UML diagrams. Each transformation includes a transformation function, which consists of mapping rules between UML diagrams and operations.

For the purpose of this transformation model it was necessary to define a proposal

of a set of features of UML diagrams in CIM and PIM levels. Also it was required to analyze the way the process of model-based software is performed. Which gave significant results in this research, they are listed below:

A description of the characteristics, elements, design rules and restrictions of CIM and PIM level of each UML diagram (§ 4.2). This description gives an assessment of operations and mapping rules between diagrams.

Hierarchical structures of information provided by customer(s) and analyst(s) (§5.3). These structures help to organize information provided by the client (s) and analyst (s), which is needed both to create and to transform the UML diagrams.

A software process modeling in CIM and PIM levels (§6). This procedure describes the construction of UML diagrams on every level, from the information provided by customer (s) and analyst (s) system. This information has a crucial role in transforming the diagram, which was considered in the transformation function proposed in this research.

The results will support the construction of the tool of transformation from model to model, the environment AGDE.

i

CONTENIDO

LISTA DE FIGURAS............................................................................................................................... III

LISTA DE TABLAS................................................................................................................................. V

GLOSARIO ......................................................................................................................................... VII

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

CAPÍTULO 1. DESCRIPCIÓN DE LA INVESTIGACIÓN ............................................................................. 4 1.1. DESCRIPCIÓN DEL PROBLEMA .......................................................................................................... 4 1.2. COMPLEJIDAD .............................................................................................................................. 5 1.3. JUSTIFICACIÓN .............................................................................................................................. 6 1.4. OBJETIVO .................................................................................................................................... 6 1.5. ALCANCES Y LIMITACIONES ............................................................................................................. 6

1.5.1. Alcances ............................................................................................................................. 6 1.5.2. Limitaciones ...................................................................................................................... 6

1.6. CONTEXTO DE LA INVESTIGACIÓN ..................................................................................................... 7

CAPÍTULO 2. MARCO TEÓRICO............................................................................................................ 8 2.1. UML .......................................................................................................................................... 8 2.1.1. CONCEPTOS BÁSICOS DE UML [ERIKSSON 2000] ............................................................................ 9 2.1.2. DIAGRAMAS DE UML ...............................................................................................................10 2.1.2.1. DIAGRAMAS DE CASOS DE USO [BOOCH 2006] ..........................................................................11 2.1.2.2. DIAGRAMAS DE CLASES [ERIKSSON 2000][BOOCH 2006] ...........................................................13 2.1.2.3. DIAGRAMAS DE ACTIVIDAD [ERIKSSON 2000][BOOCH 2006] ......................................................18 2.1.2.4. DIAGRAMAS DE SECUENCIAS [ERIKSSON 2000][BOOCH 2006] ....................................................20 2.2. XML (EXTENSIBLE MARKUP LANGUAGE)[XML1] [XML2][XML3] .....................................................22

2.2.1. Características de XML .................................................................................................... 22 2.2.2. Estructura de un documento XML .................................................................................. 23

2.3. MDA (MODEL DRIVEN ARCHITECTURE) .........................................................................................25 2.4.1. Nivel CIM ......................................................................................................................... 26 2.4.2. Nivel PIM ......................................................................................................................... 26 2.4.3. Nivel PSM ........................................................................................................................ 27

2.5. HERRAMIENTAS MDA .................................................................................................................27 2.5.1. Proyecto Eclipse [Eclipse 2009] ....................................................................................... 27

2.6. FUNCIONES MATEMÁTICAS ...........................................................................................................29

CAPÍTULO 3. ESTADO DEL ARTE ........................................................................................................31 3.1. TRABAJOS RELACIONADOS ............................................................................................................31

3.1.2. Hendryx & Associates [Hendryx 2000] ............................................................................ 32 3.1.3. Hacia la obtención de clases de análisis y casos de uso desde modelos de procesos de negocio [Rodríguez 2006] ......................................................................................................... 34 3.1.4. Una revisión de herramientas MDA [Bollati 2007] ......................................................... 35 3.1.5. Conclusiones.................................................................................................................... 38

CAPÍTULO 4. DIAGRAMAS UML PARA LOS NIVELES CIM Y PIM ........................................................39 4.1. PROPUESTA DE DIAGRAMAS PARA LOS NIVELES CIM Y PIM ................................................................40

ii

4.2. CARACTERÍSTICAS, ELEMENTOS Y REGLAS DE DISEÑO PARA LOS DIAGRAMAS UML ..................................40 4.2.1. Diagrama de casos de uso ............................................................................................... 41 4.2.2. Diagrama de clases .......................................................................................................... 41 4.2.3. Diagrama de actividad ..................................................................................................... 42 4.2.4. Diagrama de secuencia ................................................................................................... 43

4.3. CONCLUSIONES ...........................................................................................................................44

CAPÍTULO 5. MODELADO DE SOFTWARE EN LOS NIVELES CIM Y PIM .............................................45 5.1. DESCRIPCIÓN DEL PROCEDIMIENTO DE MODELADO CIM Y PIM ..........................................................46 5.2. PROPUESTA DE PROCEDIMIENTO DE MODELADO DE SOFTWARE EN LOS NIVELES CIM Y PIM ....................47 5.3. ESTRUCTURAS JERÁRQUICAS DE LA INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S) ..........51

5.3.1. Estructura jerárquica A .................................................................................................... 51 5.3.2. Estructura jerárquica B .................................................................................................... 52 5.3.3. Estructura jerárquica C .................................................................................................... 53 5.3.4. Estructura jerárquica D ................................................................................................... 56

5.4. CONCLUSIONES ...........................................................................................................................57

CAPÍTULO 6. MODELO DE TRANSFORMACIÓN EN LOS NIVELES CIM Y PIM .....................................58 6.1. CONJUNTO DE TRANSFORMACIONES ...............................................................................................59 6.2. DESCRIPCIÓN DE LAS TRANSFORMACIONES ......................................................................................60 6.3. DESCRIPCIÓN DE LAS FUNCIONES DE TRANSFORMACIÓN ....................................................................62 6.4. CONCLUSIONES ...........................................................................................................................65

CAPÍTULO 7. PRUEBAS.......................................................................................................................66 7.1. PRUEBA DE TRANSFORMACIÓN DE DIAGRAMAS DE CASOS DE USO........................................................67

7.1.1. Creación del diagrama de casos de uso en el nivel CIM ................................................. 67 7.1.2. Transformación de diagramas de casos de uso en el nivel CIM ..................................... 70 7.1.3. Transformación de diagramas de casos de uso del nivel CIM al nivel PIM ..................... 73

7.2. CONCLUSIONES ...........................................................................................................................76

CAPÍTULO 8. CONCLUSIONES ............................................................................................................77 8.1. RESULTADOS ..............................................................................................................................78 8.2. TRABAJOS FUTUROS.....................................................................................................................79

ANEXOS .............................................................................................................................................80 Anexo A. “Caracterización de las fronteras de los Modelos MDA” *López 2007+ ..................... 80

REFERENCIAS .....................................................................................................................................85

iii

LISTA DE FIGURAS

FIGURA 1. 1. ESTRUCTURA GENERAL DEL AGDE [LÓPEZ 2007] ....................................................................... 7

FIGURA 2. 1. NOTACIÓN PARA ACTORES Y CASOS DE USO ............................................................................. 12

FIGURA 2. 2. RELACIONES ENTRE CASOS DE USO ......................................................................................... 13

FIGURA 2. 3. SÍMBOLO UML PARA REPRESENTAR UNA CLASE ....................................................................... 14

FIGURA 2. 4. UNA CLASE CON ATRIBUTOS [ERIKSSON 2000] ........................................................................ 14

FIGURA 2. 5. EJEMPLO DE OPERACIONES EN UNA CLASE [ERIKSSON 2000] ...................................................... 14

FIGURA 2.6. DIAGRAMA DE CLASES [ERIKSSON 2000] ................................................................................. 15

FIGURA 2. 7. GENERALIZACIÓN [BOOCH 2006] .......................................................................................... 16

FIGURA 2. 8. RELACIÓN DE AGREGACIÓN [ERIKSSON 2000] ......................................................................... 16

FIGURA 2. 9. RELACIÓN DE COMPOSICIÓN [ERIKSSON 2000] ....................................................................... 17

FIGURA 2. 10. RELACIÓN DE DEPENDENCIA [ERICKSSON 2000] ..................................................................... 17

FIGURA 2. 11. DIAGRAMA DE ACTIVIDADES [BOOCH 2006] ......................................................................... 19

FIGURA 2. 12. REPRESENTACIONES DE OBJETOS. (A) OBJETO Y CLASE (B) OBJETO SIN CLASE EXPLÍCITA (C) OBJETO NO

ESPECIFICADO [BOOCH 2006] ......................................................................................................... 20

FIGURA 2. 13. DIAGRAMA DE SECUENCIAS [ERIKSSON 2000] ....................................................................... 21

FIGURA 2.14. LA FUNCIÓN F TRANSFORMA A EN B [ROSEN 2004] ................................................................ 29

FIGURA 2.15. FUNCIÓN ENTRE EL CONJUNTO {A, B, C, D, E} Y EL CONJUNTO {1, 2, 3, 4, 5}. ............................... 30

FIGURA 3. 1. PIRÁMIDE DE LA DISTRIBUCIÓN EN CAPAS DE MODELADO [HENDRYX 2003] .................................. 33

FIGURA 3. 2. CONCEPTOS COMPARTIDOS SEMÁNTICAMENTE ENTRE LOS LENGUAJES DE MODELADO .................... 34

FIGURA 3. 3. ESQUEMA GENERAL DE LA PROPUESTA [RODRÍGUEZ 2006] ........................................................ 35

FIGURA 5. 1. COMUNICACIÓN ENTRE NIVEL CIM Y PIM DURANTE EL PROCESO DE SOFTWARE ............................ 47

FIGURA 5.2. PROPUESTA DE PROCEDIMIENTO DE MODELADO DE SOFTWARE EN LOS NIVELES CIM Y PIM ............. 49

FIGURA 5.3. DIAGRAMA DE ACTIVIDAD DEL PROCEDIMIENTO DE MODELADO DE SOFTWARE EN LOS NIVELES CIM Y

PIM ............................................................................................................................................ 50

FIGURA 6. 1. MODELO DE TRANSFORMACIÓN EN LOS NIVELES CIM Y PIM ...................................................... 59

FIGURA 6. 2. FUNCIÓN DE TRANSFORMACIÓN ............................................................................................ 60

FIGURA 7. 1. DIAGRAMA DE CASOS USO CREADO ........................................................................................ 70

FIGURA 7.2. DIAGRAMA DE CASOS DE USO TRANSFORMADO EN EL NIVEL CIM (DIAGRAMA DESTINO) .................. 73

FIGURA 7.3. DIAGRAMA DE CASOS DE USO TRANSFORMADO EN EL NIVEL PIM (DIAGRAMA DESTINO) .................. 76

iv

FIGURA A. 1. REPRESENTACIÓN VISUAL DE LA DEFINICIÓN DE LOS MODELOS Y DE LAS FRONTERAS DE LOS MODELOS

MDA AL MODELO DE IMPLEMENTACIÓN [LÓPEZ 2007] ....................................................................... 81

FIGURA A. 2. REPRESENTACIÓN VISUAL DE LA DEFINICIÓN DEL MODELO CIM [LÓPEZ 2007] .............................. 82

FIGURA A. 3. FRONTERA CIM-PIM EN BASE A DIAGRAMAS Y SUS TRANSFORMACIONES [LÓPEZ 2007] ................ 84

v

LISTA DE TABLAS

TABLA 2. 1. CLASIFICACIÓN DE DIAGRAMAS DE UML ................................................................................... 10

TABLA 2.2. EJEMPLO DE UN DOCUMENTO XML .......................................................................................... 25

TABLA 2. 3.HISTORIA CRONOLÓGICA DEL PROYECTO ECLIPSE ........................................................................ 28

TABLA 3. 1. RESULTADO DEL ANÁLISIS COMPARATIVO DE HERRAMIENTAS MDA [BOLLATI 2007] ....................... 37

TABLA 3. 2. TABLA COMPARATIVA DE LOS TRABAJOS RELACIONADOS Y ESTA INVESTIGACIÓN .............................. 38

TABLA 4. 1. PROPUESTA DE DISTRIBUCIÓN DE DIAGRAMAS UML EN LOS NIVELES CIM Y PIM ............................ 40

TABLA 4. 2. ELEMENTOS PROPUESTOS PARA EL DIAGRAMA DE CASOS DE USO .................................................. 41

TABLA 4. 3. REGLAS Y RESTRICCIONES DE DISEÑO DEL DIAGRAMA DE CASO DE USO PARA LOS NIVELES CIM Y PIM . 41

TABLA 4. 4. ELEMENTOS PROPUESTOS PARA EL DIAGRAMA DE CLASES ............................................................ 42

TABLA 4. 5. REGLAS Y RESTRICCIONES DE DISEÑO DEL DIAGRAMA DE CLASES PARA LOS NIVELES CIM Y PIM .......... 42

TABLA 4. 6. ELEMENTOS PROPUESTOS PARA EL DIAGRAMA DE ACTIVIDAD ....................................................... 42

TABLA 4. 7. REGLAS Y RESTRICCIONES DE DISEÑO DEL DIAGRAMA DE ACTIVIDAD PARA LOS NIVELES CIM Y PIM ..... 43

TABLA 4. 8. ELEMENTOS DEL DIAGRAMA DE SECUENCIA ............................................................................... 43

TABLA 4. 9. REGLAS Y RESTRICCIONES DE DISEÑO DEL DIAGRAMA DE SECUENCIAS PARA LOS NIVELES CIM Y PIM ... 44

TABLA 5. 1. INFORMACIÓN QUE PROVEEN CLIENTE(S) Y ANALISTA(S) PARA EL DESARROLLO DE SOFTWARE ............ 46

TABLA 5. 2. PROCEDIMIENTO DE MODELADO CIM Y PIM............................................................................. 48

TABLA 5.3. ESTRUCTURAS JERÁRQUICAS PARA LA INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S) . 51

TABLA 5.4. INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S), ÚTIL PARA DIAGRAMAS DE CASOS DE

USO ............................................................................................................................................. 51

TABLA 5.5. ESTRUCTURA JERÁRQUICA A .................................................................................................... 52

TABLA 5.6. INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S), ÚTIL PARA DIAGRAMAS DE CLASES .... 52

TABLA 5.7. ESTRUCTURA JERÁRQUICA B .................................................................................................... 53

TABLA 5.8. INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S), ÚTIL PARA DIAGRAMAS DE ACTIVIDAD 54

TABLA 5.9. ESTRUCTURA JERÁRQUICA C .................................................................................................... 54

TABLA 5.10. INFORMACIÓN PROPORCIONADA POR CLIENTE(S) Y ANALISTA(S), ÚTIL PARA DIAGRAMAS DE SECUENCIAS

................................................................................................................................................... 56

TABLA 5. 11. ESTRUCTURA JERÁRQUICA D ................................................................................................. 56

TABLA 6. 1. CONJUNTO DE TRANSFORMACIONES T ..................................................................................... 61

TABLA 6.2. FUNCIÓN DE TRANSFORMACIÓN ENTRE DIAGRAMAS CASOS DE USO................................................ 63

TABLA 6.3. FUNCIÓN DE TRANSFORMACIÓN ENTRE DIAGRAMAS DE CLASES ..................................................... 63

TABLA 6.4. FUNCIÓN DE TRANSFORMACIÓN ENTRE DIAGRAMAS DE ACTIVIDAD ................................................ 64

TABLA 6.5. FUNCIÓN DE TRANSFORMACIÓN ENTRE DIAGRAMAS DE SECUENCIA ................................................ 65

vi

TABLA 7. 1. INFORMACIÓN PARA PROPORCIONADA POR CLIENTE(S) Y/O ANALISTA(S) ....................................... 68

TABLA 7.2. FORMATO XMI DEL DIAGRAMA DE CASOS DE USO CREADO ........................................................... 69

TABLA 7.3. INFORMACIÓN PARA PROPORCIONADA POR CLIENTE(S) Y/O ANALISTA(S) ........................................ 70

TABLA 7.4. FORMATO XMI DEL DIAGRAMA DE CASOS DE USO TRANSFORMADO EN EL NIVEL CIM (DIAGRAMA

DESTINO) ...................................................................................................................................... 71

TABLA 7. 5. INFORMACIÓN PARA PROPORCIONADA POR CLIENTE(S) Y/O ANALISTA(S) ....................................... 73

TABLA 7.6. FORMATO XMI DEL DIAGRAMA DE CASOS DE USO TRANSFORMADO EN EL NIVEL PIM (DIAGRAMA

DESTINO) ...................................................................................................................................... 75

vii

GLOSARIO

AGD Architectural and Group Development Method - Método de Desarrollo Arquitectónico en Grupo

MDA Model Driven Architecture - Arquitectura Dirigida por Modelos UML Unified Modeling Language - Lenguaje Unificado de Modelado XMI XML Metadata Interchange - XML de Intercambio de Metadatos XML Extensible Markup Language- Lenguaje de Marcas Extensible CIM Computation Independent Model - Modelo Independiente de Cómputo W3C World Wide Web Consortium

PIM Platform Independent Model - Modelo Independiente de Plataforma PSM Platform Specific Model - Modelo de Plataforma Específica IM Implementation Model - Modelo de Implementación MDD Model Driven Development - Desarrollo Dirigido por Modelos OMG Object Management Group - Grupo de Gestión de Objetos RCP Rich Client Platform, Plataforma del cliente enriquecido. API Application Programming Interface - Interfaz de programación de

aplicaciones, es un conjunto de funciones, procedimientos o métodos que ofrece cierta biblioteca para usarse por otro software como una capa de abstracción.

MOF Meta-Object Facility. Es el meta-meta-modelo reflexivo que constituye el corazón de MDA, MOF proporciona el entorno en que los modelos pueden ser exportados e importados entre herramientas, almacenados y extraídos de repositorios, transformados entre distintos meta-modelos y usados para generar código.

Plug-in Es un complemento, es una aplicación que se relaciona con otra para aportarle una función nueva y generalmente muy específica.

Wysiwig What You See Is What You Get, lo que ves es lo que obtienes, se aplica a ciertos paquetes visuales como procesadores de palabras y diseñadores gráficos entre otros.

Modelo [Booch 2006] Es una simplificación de la realidad, proporciona los planos de un sistema, siendo planos detallados y planos generales que ofrecen una visión global del sistema en consideración. Un modelo [Miller 2003] es una representación abstracta de un sistema o proceso que nos permite responder a preguntas acerca del mismo. Los modelos son útiles cuando se manejan sistemas que son demasiado grandes o complicados, debido a que permiten comunicar la estructura del sistema, especificar el comportamiento que se espera, comprender mejor lo que se está construyendo y detectar oportunidades para simplificar y reutilizar. El modelo se presenta a menudo como una combinación de dibujos y texto.

http://es.wikipedia.org/wiki/World_Wide_Web_Consortium

viii

Modelado de Negocios [Estrada 2002] (Business Modeling): El Modelado de Negocios es una abstracción de los elementos necesarios que conforman una organización, considerando las relaciones entre ellos.

Modelado del proceso de negocios [Estrada 2002](Business process modeling): Un

proceso de negocio es una forma organizacional lateral u horizontal que encapsula las interdependencias de tareas, roles, recursos humanos, departamentos y funciones requeridas para proveer un producto o servicio a un cliente. Los procesos de negocio definen la dinámica del comportamiento del negocio, actuando sobre entidades o recursos. El modelado de procesos de negocio es una actividad crucial para la comprensión y re-estructuración de las actividades que una empresa ejecuta para lograr sus metas de negocio.

Lenguaje para representar modelo [Giandini 2006](Languages to represent models): Es

un lenguaje gráfico para visualizar, especificar, construir y documentar software, generalmente basado en UML, que ofrece un estándar para describir un “plano” del sistema (modelo) para facilitar el diseño.

Lenguaje de transformación [Giandini 2006] (Languages transformation): La

transformación de modelos constituye una tecnología clave para el éxito de los diversos enfoques de desarrollo de software dirigido por modelos (DSDM). Definiendo al lenguaje de transformación como el que permite traducir de un nivel de abstracción a otro generalmente de entre las capas de modelado propuestas por la MDA.

1

Introducción

El modelado del desarrollo de software apoyado en diagramas, facilita su comprensión y permite un acercamiento a la realidad de los requerimientos del cliente. En la actualidad, un enfoque muy aceptado en la comunidad de desarrollo de software, es utilizar los diagramas UML de acuerdo a los niveles de abstracción propuestos en MDA, para modelar el desarrollo de software.

Se establecen diagramas en diferentes niveles, de acuerdo a la fase específica del desarrollo que se está modelando, lo cual depende directamente de la experiencia y criterio del desarrollador, ya que no existe un estándar.

Existen herramientas, tales como CORBA, QVT, NetBeans y Enterprise, entre otros, para el diseño de modelos y que permiten la transformación entre ellos de forma automática. Sin embargo, no se conocen las especificaciones de las operaciones de transformación que realizan.

Introducción

2

Actualmente, en el CENIDET, se está desarrollando una Herramienta de transformación de modelo a modelo, que permitirá obtener un modelo destino a partir de un modelo origen, considerando los niveles MDA. La transformación podrá ser entre distintos niveles de abstracción o en el mismo nivel de abstracción. Esta herramienta formará parte de un ambiente de herramientas para el soporte del desarrollo de software dirigido por modelos, denominado AGDE, propuesto por [González-García 2006].

En la actualidad, un enfoque muy aceptado en la comunidad de desarrollo de software, es utilizar los diagramas UML de acuerdo a los niveles de abstracción propuestos en MDA, para modelar el desarrollo de software. Existen herramientas para el diseño de modelos y la transformación entre ellos de forma automática. Sin embargo, no se conocen las especificaciones de las operaciones de transformación que realizan. En este contexto, se realizó esta investigación, con el objetivo de determinar cuáles son las operaciones elementales (incluyendo operadores, operandos y reglas) para realizar la transformación de modelos en los niveles CIM a PIM. En esta investigación se propone:

o Un modelo de transformación en los niveles CIM y PIM (§6). Este modelo consiste en un conjunto de transformaciones lineales semiformalizadas para los diagramas UML. Cada transformación incluye:

Una función de transformación, que consta de reglas de mapeo y operaciones entre diagramas UML.

Para la propuesta de este modelo, fue necesario definir una propuesta de características de diagramas UML en los niveles CIM y PIM. También se requirió analizar la forma en que se hace el proceso de software basado en modelos.

Lo anterior, generó otros resultados importantes en esta investigación tales como:




Introducción

3

Los resultados permitirán continuar la construcción de la Herramienta de transformación de modelo a modelo, para el ambiente AGDE.

Este documento está organizado en la siguiente forma: Capítulo 1. Descripción de la investigación. Se describe la investigación realizada,

incluyendo la justificación, el objetivo, complejidad, alcances, limitaciones y el contexto.

Capítulo 2. Marco teórico. Se presenta información requerida para el desarrollo de la investigación.

Capítulo 3. Estado del arte. Se describen trabajos relacionados con la investigación. Capítulo 4. Diagramas UML para los niveles CIM y PIM. Se describen las características,

elementos y restricciones y reglas de diseño, de cada diagrama UML. Capítulo 5. Modelado de software en los niveles CIM y PIM. Se describe un procedimiento

para la construcción de diagramas UML en los niveles CIM y PIM, a partir de la información proporcionada por cliente(s) y analista(s) del sistema. También se describen las estructuras jerárquicas para organizar dicha información.

Capítulo 6. Modelo de transformación en los niveles CIM y PIM. En este capítulo, se describen detalladamente las operaciones de transformación de diagramas UML.

Capítulo 7. Pruebas. Se presentan los resultados de las pruebas de transformación de diagramas UML en los niveles CIM y PIM.

Capítulo 8. Conclusiones. Se presentan los objetivos logrados, las aportaciones de este trabajo y los trabajos futuros.

4

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

En éste capítulo se describen los aspectos que motivaron la realización de la presente investigación. Se incluye la descripción y complejidad del problema, la justificación, el objetivo, así como los alcances y limitaciones.

1.1. Descripción del problema

En la actualidad, un enfoque muy aceptado en la comunidad de desarrollo de software, es utilizar los diagramas UML de acuerdo a los niveles de abstracción propuestos en MDA, para modelar el desarrollo de software.

Existen herramientas, tales como CORBA, QVT, NetBeans y Enterprise, entre otros, para el diseño de modelos y que permiten la transformación entre ellos de forma automática. Sin embargo, no se conocen las especificaciones de las operaciones de transformación que realizan.


5

Actualmente, en el CENIDET, se está desarrollando una Herramienta de transformación de modelo a modelo, que permitirá obtener un modelo destino a partir de un modelo origen, considerando los niveles MDA. La transformación podrá ser entre distintos niveles de abstracción o en el mismo nivel de abstracción.

Para el desarrollo de esta herramienta, se requiere establecer las operaciones necesarias para transformar los modelos.

En esta investigación se proponen operaciones de transformación de modelos, considerando los niveles CIM y PIM.

Un trabajo previo, es el realizado por [López 2007], en el que se establecen las fronteras que delimitan cada nivel de MDA, mediante diagramas UML.

Las operaciones de transformación de modelos, propuestas en esta investigación consideran:

Diagramas de casos de uso, diagramas de clases, diagramas de secuencia y diagramas de actividad.

Transformación de un diagrama en el nivel CIM a un diagrama del mismo tipo en el nivel PIM.

Transformación de un diagrama en el nivel CIM a otro diagrama del mismo tipo en el mismo nivel.

Transformación de un diagrama en el nivel PIM a otro diagrama del mismo tipo en el mismo nivel.

1.2. Complejidad El nivel de complejidad de esta investigación, tiene que ver con algunos problemas que se describen a continuación:

No existe un estándar que defina los elementos de cada diagrama UML para cada nivel de abstracción MDA. Por lo cual, fue necesario hacer un análisis para definir una propuesta de elementos de cada diagrama UML considerado en esta investigación, para el nivel CIM y el nivel PIM.

El trabajo con elementos gráficos, tales como los diagramas UML, requiere de experiencia por parte del desarrollador, para abstraer y comprender su significado. Lo cual dificultó la propuesta de elementos para cada diagrama en cada nivel, que fuera entendible sin importar la experiencia del desarrollador.

Aun cuando existen herramientas que realizan la transformación. Mantienen la confidencialidad de sus operaciones. Esto puede deberse a deficiencias en su documentación o por omisiones voluntarias [Dosi 1988]. Por tal motivo fue necesario hacer una propuesta propia de las operaciones de transformación.


6

1.3. Justificación Los resultados obtenidos en esta investigación permitirán continuar con el desarrollo de la Herramienta de transformación de modelo a modelo, ubicada en el ambiente AGDE, que actualmente se desarrolla en el CENIDET.

1.4. Objetivo Determinar cuáles son las operaciones elementales (incluyendo operadores, operandos y reglas) para realizar la transformación de modelos CIM a modelos PIM dentro del ambiente AGDE, basándose en el enfoque de MDA.

1.5. Alcances y limitaciones A continuación se enlistan los alcances y limitaciones de este trabajo.

1.5.1. Alcances

Se consideran los diagramas de casos de uso, diagramas de clases, diagramas de secuencia y diagramas de actividad.

Propuesta de transformación de un diagrama en el nivel CIM a un diagrama del mismo tipo en el nivel PIM.

Propuesta de transformación de un diagrama en el nivel CIM a otro diagrama del mismo tipo en el mismo nivel.

Propuesta de transformación de un diagrama en el nivel PIM a otro diagrama del mismo tipo en el mismo nivel.

Propuesta de funciones de transformación de modelos, que consta de reglas de mapeo y operaciones entre diagramas.

Semiformalización de las transformaciones propuestas.

1.5.2. Limitaciones

No se consideran transformaciones en los niveles PIM, PSM e IM.

No se propone un lenguaje de transformación.


7

1.6. Contexto de la investigación Los resultados de esta investigación contribuirán al desarrollo de la Herramienta de transformación de modelo a modelo, que se realiza actualmente en el CENIDET. Esta herramienta formará parte de un ambiente de herramientas para el soporte del desarrollo de software dirigido por modelos, denominado AGDE, basado en el método AGD, ambos propuestos por [González-García 2006]. El AGD es un método de desarrollo de software. AGD establece un método cuyo proceso integra modos de trabajo en grupo, dirigido a desarrollar productos de mejor calidad, como resultado de la importancia dada a los productos y a su arquitectura y de la sinergia obtenida del trabajo en grupo. [González-García 2006]. En la siguiente figura 1.1, se muestra la estructura general del AGDE.

Figura 1. 1. Estructura general del AGDE [López 2007]

Uno de los componentes que integran al AGDE es la herramienta de transformación de modelo a modelo. Esta herramienta permitirá obtener un modelo destino a partir de un modelo origen, siendo el modelo origen la entrada para la transformación. La transformación se puede realizar entre distintos niveles de abstracción (CIM a PIM, PIM a PSM) o igual nivel de abstracción (CIM a CIM, PIM a PIM, PSM a PSM) [López 2007].

8

Capítulo 2. Marco teórico

En este capítulo se explican los conceptos y términos relacionados con esta investigación, con lo que se pretende inducir al lector y facilitarle la comprensión de la terminología utilizada en el desarrollo de la presente investigación.

2.1. UML UML (Unified Modeling Language), Lenguaje Unificado de Modelado. “Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos a un sistema de software en desarrollo, así como para el modelado de negocios y otros sistemas que no son de software” *UML 2005+.Todas las abstracciones del sistema se organizan en modelos.


9

UML es útil para modelar problemas simples y también problemas difíciles. El 80% de la mayoría de los problemas puede modelarse con el 20% de UML [Booch 2006]. El UML fue creado por Grady Booch, James Rumbaugh e Ivar Jacobson, y posteriormente estandarizado por la OMG1 en 1997. El UML puede utilizarse a lo largo del proceso de desarrollo de software, con cualquier metodología y en cualquier plataforma tecnológica de implementación [UML 2005]. UML estandariza la notación para describir un proceso, pero no estandariza el proceso para producir estas descripciones, es decir, UML no especifica una forma específica de usarlo en un proyecto, de hecho, no hay una forma específica o correcta de usarlo [Eriksson 2000]. Sin embargo, esto no representa una desventaja para los desarrolladores de UML, por el contrario, ya que UML puede utilizarse en muchos diferentes procesos de desarrollo, por ejemplo: un proceso de desarrollo de un proyecto que involucra a tres personas es muy diferente a un proyecto que involucra a cientos de personas que trabajan en diferentes países.

Además el proceso también puede ser afectado por otros factores, tales como el tipo de sistema o el proceso de desarrollo utilizado que son frecuentemente configurables, esto es, que puede adaptarse o modificarse de acuerdo al proyecto.

2.1.1. Conceptos básicos de UML [Eriksson 2000]

Un lenguaje de modelado tiene una notación2 y un conjunto de reglas que guían el lenguaje. Las reglas son sintácticas, semánticas y pragmáticas.

Las reglas sintácticas dictan cómo deben verse los símbolos y cómo pueden componerse. La sintaxis puede compararse con las palabras en un lenguaje natural, como en el lenguaje natural es importante saber cómo se escriben y cómo se combinan para formar oraciones.

Las reglas semánticas nos dice que significa cada símbolo y cómo debe interpretarse por sí mismo o en contexto con otros símbolos. Estas reglas pueden compararse con las definiciones de las palabras en un lenguaje natural. Las reglas pragmáticas explican cómo usar el lenguaje. Pueden compararse con las reglas de escritura en un lenguaje natural. Estas reglas definen la intención de los símbolos, a través de las cuales se logra el propósito del modelo y se vuelve comprensible para los demás. Los símbolos de UML son geométricos, tales como rectángulos, círculos y líneas. UML tiene un conjunto bien definido de reglas sintácticas y semánticas que definen qué significan los símbolos y como pueden combinarse. Sin embargo, UML no tiene reglas pragmáticas, esto es, que no existen guías específicas para usar los símbolos.

1 OMG (Object Management Group) Consultar glosario.

2 Notación. Los símbolos usados en los modelos.


10

2.1.2. Diagramas de UML

De acuerdo con [UML 2005], el UML 2.0 está compuesto de 13 diagramas clasificados como se muestra en la tabla 2.1.

Tabla 2. 1. Clasificación de diagramas de UML

Diagramas de estructura Diagramas de

comportamiento

Diagramas de interacción

Representan la estructura

estática de la aplicación. Se

centran en los elementos que

deben existir en el sistema

modelado.

Pertenecen a esta clasificación

los siguientes diagramas:

Diagramas de clases

Diagramas de componente

Diagramas de objetos

Diagramas de despliegue

Diagramas de paquetes

Diagramas de estructura

compuesta

Representan los tipos de

comportamiento. Enfatizan lo

que debe suceder en el

sistema modelado.

Los diagramas que

pertenecen a esta clasificación

son:

Diagramas de casos de uso

Diagramas de actividad

Diagramas de estados

Son un subtipo de diagramas

de comportamiento, que

enfatizan el flujo de control y

de datos entre los elementos

del sistema modelado.

Esta clasificación incluye los

siguientes diagramas:

Diagramas de secuencia

Diagramas de comunicación

Diagramas de tiempos

Diagramas de revisión de la

interacción

Los diagramas de estructura representan aspectos estáticos y los diagramas de comportamiento y diagramas de interacción representan aspectos dinámicos de los sistemas.

A continuación se explican en forma general los diagramas UML:

Diagramas de clases. Estos muestran las clases y sus relaciones. Diagramas de componentes. Muestran los componentes y sus dependencias. Diagramas de objetos. Muestran los objetos y sus relaciones. Diagramas de estructura compuesta. Son diagramas de clases que incluyen partes y conectores. Diagramas de despliegue. Muestran la configuración del sistema en tiempo de ejecución. Diagramas de paquetes. Organizan y manipulan la complejidad de los modelos grandes. Diagramas de actividades. Muestran el orden en que se realizan las tareas en un sistema.

http://es.wikipedia.org/wiki/Diagrama_de_clases

http://es.wikipedia.org/wiki/Diagrama_de_componentes

http://es.wikipedia.org/wiki/Diagrama_de_objetos

http://es.wikipedia.org/wiki/Diagrama_de_estructura_compuesta

http://es.wikipedia.org/wiki/Diagrama_de_despliegue

http://es.wikipedia.org/wiki/Diagrama_de_paquetes

http://es.wikipedia.org/wiki/Diagrama_de_actividades


11

Diagramas de casos de uso. Muestran las acciones que realiza cada tipo de usuario. Diagramas de estados. Describen el comportamiento de un sistema dirigido por eventos. Diagramas de secuencia. Detallan la ordenación temporal de los mensajes. Diagramas de comunicación. Modelan interacciones entre objetos en el sistema. Diagramas de tiempos. Muestra la relación temporal entre varias señales. Diagramas de revisión de la interacción. Muestran criterios de visibilidad y manipulación a otras clases.

Para esta investigación se utilizarán los diagramas de casos de uso, diagramas de clases, diagramas de actividad y diagramas de secuencia, los cuales se explican con mayor detalle. 2.1.2.1. Diagramas de casos de uso [Booch 2006]

Ningún sistema se encuentra aislado. Cualquier sistema interesante interactúa con actores humanos o mecánicos que lo utilizan con algún objetivo y que esperan que el sistema funcione de forma predecible. Un caso de uso especifica el comportamiento de un sistema o de una parte de éste, y es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cómo se implementa ese comportamiento. Los casos de uso proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensión común del sistema. Los casos de uso bien estructurados denotan sólo comportamientos esenciales del sistema o de un subsistema, y nunca deben ser excesivamente genéricos, ni demasiados específicos. Un caso de uso puede tener variantes. En cualquier sistema, se pueden encontrar casos de uso que son versiones especializadas de otros casos de uso, casos de uso incluidos como parte de otros y casos de uso que extienden el comportamiento de otros casos de uso básicos. Los casos de uso y los diagramas de casos de uso se formulan en términos de un actor y un sistema. Un actor es un rol que un usuario u otro sistema tiene en relación al sistema. La notación de UML para los casos de uso y los actores se muestra en la figura 2.1.

http://es.wikipedia.org/wiki/Diagrama_de_casos_de_uso

http://es.wikipedia.org/wiki/Diagrama_de_estados

http://es.wikipedia.org/wiki/Diagrama_de_secuencia

http://es.wikipedia.org/wiki/Diagrama_de_colaboraci%C3%B3n

http://es.wikipedia.org/wiki/Diagrama_de_tiempos

http://es.wikipedia.org/w/index.php?title=Diagrama_de_vista_de_interacci%C3%B3n&action=edit&redlink=1


12

Actor. Representa un conjunto de roles que los usuarios de los casos de uso representan al interactuar con éstos. Un actor representa un rol desempeñado por una persona, un dispositivo o incluso otro sistema al interactuar con nuestro sistema. Los actores no forman parte del sistema de una forma específica. Están fuera de la aplicación, en el entorno que la rodea. Sin embargo en un sistema en ejecución, los actores no están separados.

Caso de uso. Describe qué hace un sistema, pero no especifica cómo lo hace. El caso de uso debe tener un nombre que lo distinga de otros casos de uso. El nombre es un texto, que describe algún comportamiento del sistema que se está modelando.

Los actores se pueden conectar a los casos de uso a través de asociaciones. Una

asociación entre un actor y un caso de uso indica que el actor y el caso de uso se comunican entre sí, y cada uno puede enviar y recibir mensajes. Esta asociación se representa con una línea que une un actor y un caso de uso.

Los casos de uso se organizan a través de relaciones entre ellos. Las relaciones principales son las de inclusión y extensión.

La relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en un lugar especificado en el caso base. Esta relación se representa como una dependencia y se especifica con la palabra “include”. Gráficamente es línea discontinua dirigida hacia el elemento que se incluye.

La relación de extensión entre casos de uso significa que una caso de uso base incorpora implícitamente el comportamiento de otro caso de uso en un lugar especificado indirectamente por el caso de uso que extiende al base. La relación de extensión modela la parte de un caso de uso que puede verse como un comportamiento opcional del sistema. Esta relación se representa como

Actor Caso de uso

Figura 2. 1. Notación para actores y casos de uso


13

una dependencia y se especifica con la palabra “extend”. Gráficamente es línea discontinua dirigida hacia el elemento que es extendido.

En la figura 2.2, se muestran las relaciones de inclusión y de extensión entre casos

de uso. Hacer pedido urgente extiende la funcionalidad de Hacer pedido, Hacer pedido incluye Validar usuario, Seguir pedido incluye Validar usuario.

2.1.2.2. Diagramas de clases [Eriksson 2000][Booch 2006]

Los sistemas están construidos a partir de objetos, los cuales pueden ser físicos, tales como computadoras, personas o materiales, o abstractos, tales como información. Los objetos están descritos por sus propiedades internas (atributos) y sus relaciones con otros objetos. Los atributos están descritos con un nombre y un tipo (por ejemplo, integer, Boolean, string). El comportamiento está descrito con operaciones atribuidas a los objetos. Una clase es un conjunto de objetos con las mismas características. Agrupando los objetos en clases se reduce la complejidad y el número de elementos cuando se modela y se facilita la descripción de sistemas complejos.

En UML una clase se dibuja con un rectángulo dividido horizontalmente en tres secciones. La sección superior contiene el nombre de la clase, la sección del medio contiene los atributos de la clase y la sección inferior contiene las operaciones de la clase. Se puede suprimir una sección en un diagrama. Ver figura 2.3.

“include”

“extend”

“include”

Hacer pedido Hacer pedido

urgente

Seguir pedido Validar usuario

Figura 2. 2. Relaciones entre casos de uso


14

Nombre de la clase

Atributos de la clase

Operaciones de la clase

Figura 2. 3. Símbolo UML para representar una clase

La visibilidad de los atributos, se refiere al acceso a ellos desde otras clases. Los atributos con signo (+), indican que otras clases pueden acceder a ellos, es decir, son públicos (public). Los atributos con signo (-), indican que son privados (private), es decir, sólo la propia clases y sus objetos pueden acceder a ellos. Los atributos protegidos (protected), se marcan con un símbolo (#), e indican que pueden ser usados por la clase y sus clases descendientes. Los atributos también pueden diseñarse como globales (global), que son atributos que tienen un valor común con todos los objetos, por ejemplo un atributo contador, que es común a todas las instancias de una clase. Los atributos globales se subrayan. Ver figura 2.4.

Las clases también tienen operaciones, que son los servicios que proporciona una clase. Las operaciones son similares a las funciones en los lenguajes de programación, pero las operaciones en una clase tienen únicamente acceso a todos los atributos de una clase. Una operación tiene un nombre, visibilidad, una lista de parámetros y un tipo de retorno. Ver figura 2.5.

Invoice

+ amount: Real

+ date: Date = Current date

+ customer: String

+ specification: String

- administrator: String=”Unspecified”

- number of invoices: integer

+ status: Status = unpaid {unpaid, paid}

Figura 2. 4. Una clase con atributos [Eriksson 2000]

Bank Account

- account number: String

- balance: CarData

+ cash deposit (amount:real):Boolean

+ cash withdrawal (amount:real): Boolean

+ bank statement (): real

Figura 2. 5. Ejemplo de operaciones en una clase [Eriksson 2000]


15

Las clases se modelan y se relacionan con otras en un diagrama de clases. Las clases están descritas con nombres, atributos y operaciones. Las relaciones entre las clases se describen con un nombre, roles y multiplicidad. Las asociaciones entre clases son relaciones estructurales que especifican que los objetos de un elemento están conectados con los objetos de otro. Una asociación se representa con una línea.

El nombre de la asociación (usualmente verbos), se utiliza para describir la naturaleza de la relación. Para que no haya ambigüedad en su significado, se puede dar una dirección al nombre por medio de una flecha que apunta en la dirección que se pretende se lea el nombre. El nombre de la asociación es opcional.

Cuando la clase se relaciona con otra, juega un rol específico en la relación. Se puede dar un nombre específico al rol de la clase.

La multiplicidad de una clase especifica cuántos objetos de la clase de ese extremo puede haber para cada objeto de la clase en el otro extremo.

La multiplicidad y los nombres de los roles se escriben en los extremos. La multiplicidad se representa como un rango o con un número específico, por ejemplo, 1..5, 0..*, 4. El asterisco (*) indica un intervalo abierto (muchos). En la figura 2.6, por ejemplo: la Compañía de Seguros emite Contratos de Seguro (no viceversa). La clase Persona está asociada con la clase Contrato de Seguro en la forma: una o varias Personas tienen (están aseguradas) con 0 ó más Contratos de Seguro, en forma similar una o más Compañías tienen (están aseguradas) con 0 ó más Contratos de Seguro. Respecto a los roles Compañía de Seguros tiene el rol de aseguradora, mientras que Persona y Compañía, tienen el rol de asegurados.

Además de las relaciones de asociación, existen otros tipos de relaciones, a continuación se describen algunas de ellas:

Está

asegurada

Está

asegurada

0..*

1 0..* 0..*

1..* asegurada asegurado

aseguradora

Compañía de

Seguros

Contrato de

Seguro

Persona Compañía

1..*

emite

Figura 2.6. Diagrama de clases [Eriksson 2000]


16

La generalización. Es una relación entre un elemento general (llamado superclase o padre) y un caso más específico de ese elemento (llamado subclase o hijo). La generalización se llama a veces relación “es-un-tipo-de”. La generalización se representa como una línea dirigida continua, con una punta de flecha vacía apuntando al padre. Las generalizaciones se utilizan cuando se requiere mostrar relaciones padre/hijo. Un ejemplo de esta relación se muestra en la figura 2.7, que puede leerse como Figura es una generalización de Rectángulo, Figura es una generalización de Círculo y Figura es una generalización de Polígono, o bien, Rectángulo es un tipo de Figura, Círculo es un tipo de Figura y Polígono es un tipo de Figura.

La agregación. Es una especialización de asociación usada en situaciones donde un “todo” se conecta con sus “partes”, representa una relación del tipo “tiene-un”, Se utiliza una línea con una forma de diamante hueco. En la figura 2.8, se muestra un ejemplo, que indica que una Entrega (el todo) contiene-un número de Productos (sus partes).

Figura

Rectángulo Círculo Polígono

Figura 2. 7. Generalización [Booch 2006]

* * Entrega

Producto

contiene

Figura 2. 8. Relación de agregación [Eriksson 2000]


17

La composición. Es un tipo de agregación, con una fuerte relación de dependencia y existencia de la “parte” con el “todo”. Esta relación indica que la “parte” puede estar sólo una vez en el “todo”. Gráficamente, utiliza una línea con una forma de diamante relleno (negro) en el lado del “todo”. La figura 2.9 muestra una relación de composición. La clase Ventana de mensaje puede tener sólo uno o ningún objeto de la clase botón Ok, uno o ningún objeto de la clase botón Cancel y uno o ningún objeto de la clase ícono de información.

La dependencia. Es una relación de uso que declara que un elemento utiliza la información y los servicios de otro elemento, pero no necesariamente a la inversa. Gráficamente, una dependencia se representa con una línea discontinua dirigida hacia el elemento del cual se depende. La dependencia se usan cuando se quiere indicar que un elemento utiliza a otro. En la figura 2.10, se muestra una relación de dependencia. La clase Compañía depende de Sistema de información.

info

rmat

ion

in

form

acio

n

o

k

c

ance

l

0..1 0..1 0..1

Ventana de

Mensaje

Botón ícono

Figura 2. 9. Relación de composición [Eriksson 2000]

Sistema de información Compañía

Figura 2. 10. Relación de dependencia [Ericksson 2000]


18

2.1.2.3. Diagramas de actividad [Eriksson 2000][Booch 2006]

Los diagramas de actividad son utilizados para describir flujos de trabajo (actividades de un proceso). Muestran aspectos de concurrencia y bifurcación de control. Implica describir los pasos secuenciales (y posiblemente concurrentes) de un proceso3. Un flujo de trabajo puede ser desde una simple operación, tal como, realizar una operación aritmética, hasta operaciones más complejas tal como un proceso de producción. En UML, las actividades que serán realizadas, es decir, un nodo de actividad, se representa por un rectángulo con las esquinas redondeadas. Una actividad puede detonar otra actividad. El flujo de control de actividades se representa con una línea continua que parte de la actividad concluída y termina en una punta de flecha en dirección a la siguiente acción. Un flujo de control puede tener etiquetas, acciones y cláusulas de envío. Los flujos secuenciales son frecuentes, pero no son el único tipo de camino. Se puede incluir una bifurcación que especifica caminos alternativos elegidos en función del valor de una expresión booleana. Es posible utilizar la bifurcación para representar una iteración. Una bifurcación se representa con un rombo. El inicio de un diagrama de actividad se indica con un círculo relleno (negro) y termina con un símbolo de un círculo vacío que contiene un círculo relleno (negro) más pequeño.

Los flujos secuenciales y las bifurcaciones son los caminos más utilizados en los diagramas de actividad, sin embargo, también es posible encontrar flujos concurrentes. En UML se utiliza una barra de sincronización para especificar la división y unión de flujos de control paralelos. Una barra de sincronización se representa con una línea horizontal o vertical ancha.

Una división puede tener una transición de entrada y dos o más transiciones de salida, cada una de las cuales representa un flujo de control independiente. Después de la división las actividades continúan su camino en paralelo.

La unión puede tener dos o más transiciones de entrada y una transición de salida. Antes de llegar a la unión, las actividades asociadas con cada uno de los caminos continúan en paralelo. En la unión, los flujos concurrentes se sincronizan, es decir, cada uno espera hasta que todos los flujos de entrada alcanzan la unión y a partir de ahí continúan un único flujo de control. En la figura 2.11, se muestra un diagrama de actividades.

3 También se puede modelar el flujo de valores entre los distintos pasos.


19

[en otro caso]

[no aceptado]

Elegir sitio

Contratar arquitecto

Desarrollar plano

Ofertar plano

Realizar trabajo en el

terreno

Terminar construcción

Hacer trabajo

comercial

Figura 2. 11. Diagrama de actividades [Booch 2006]


20

2.1.2.4. Diagramas de secuencias [Eriksson 2000][Booch 2006]

Los diagramas de secuencias se usan para explorar y visualizar la secuencia en la que interactúan diferentes objetos. Los objetos pueden ser unidades organizacionales, compañía, computadoras, personas, procesos o cosas mecánicas. Típicamente, los diagramas de secuencias describen claramente el orden y sincronización de mensajes entre un conjunto de objetos. El objeto se representa gráficamente con un rectángulo (como en la clase) que incluye el nombre del objeto subrayado, puede incluir la clase del objeto (opcional). En la figura 2.12, se muestran diferentes representaciones de objetos, en (a) Juan es un objeto de la clase Cliente, (b) Juan es un objeto sin especificar la clase de objetos y (c) Expresa un objeto de la clase Cliente, sin especificar el nombre del objeto. En los tres casos el nombre del objeto se subraya.

En el diagrama de secuencias, los objetos se colocan en la parte superior del modelo y a partir de ellos, se dibuja una línea vertical discontinua que representa la línea de vida, que muestra cuándo se crea y se destruye un objeto. La interacción entre objetos se representa con flechas, cuya dirección indica la secuencia. En la figura 2.13, se muestra parte de un diagrama de secuencias con algunas interacciones entre los objetos cliente y proveedor.

Se pueden colocar anotaciones a los lados de un diagrama de secuencia para clarificar la secuencia.

Juan: Cliente

Juan

: Cliente

(a)

(b)

( c)

Figura 2. 12. Representaciones de objetos. (a) objeto y clase (b) objeto sin clase explícita (c) objeto no especificado [Booch 2006]


21

Envía oferta

Envía contraoferta

Prepara contraoferta

Envía oferta

Envía requisición

cliente proveedor

Prepara requisición

Prepara oferta

Prepara oferta

Figura 2. 13. Diagrama de secuencias [Eriksson 2000]


22

2.2. XML (Extensible Markup Language)[XML1] [XML2][XML3]

XML, siglas en inglés de Extensible Markup Language (lenguaje de marcas extensible), es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium (W3C). XML no es realmente un lenguaje en particular, sino una manera de definir lenguajes para diferentes necesidades. Algunos de estos lenguajes que usan XML para su definición son XHTML, SVG, MathML.

XML se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Se puede usar en bases de datos, editores de texto, hojas de cálculo y casi cualquier cosa imaginable en el ámbito de la programación.

XML es una tecnología sencilla que tiene a su alrededor otras que la complementan y la hacen mucho más grande y con unas posibilidades mucho mayores.

XML, tiene las siguientes ventajas: Es extensible: Después de diseñado y puesto en producción, es posible extender

XML con la adición de nuevas etiquetas, de modo que se pueda continuar utilizando sin complicación alguna.

El analizador es un componente estándar, no es necesario crear un analizador específico para cada versión de lenguaje XML. Esto posibilita el empleo de cualquiera de los analizadores disponibles. De esta manera se acelera el desarrollo de aplicaciones.

Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarla. Mejora la compatibilidad entre aplicaciones.

2.2.1. Características de XML

Algunas de las características de XML se describen a continuación: XML es útil para estructurar datos. Los datos estructurados incluyen plantillas de

cálculo, libretas de direcciones, parámetros de configuración, transacciones financieras y dibujos técnicos, entre otros. XML es un conjunto de reglas o guías para diseñar formatos de texto que permitan estructurar los datos. XML no es un lenguaje de programación. XML facilita a la computadora la tarea de generar datos, leerlos, y asegurar que su estructura no es ambigua. XML evita las fallas comunes en diseño de lenguajes: es extensible, independiente de la plataforma, y soporta internacionalización y localización.

XML usa etiquetas. XML usa etiquetas4 y atributos (de la forma nombre="valor"), para delimitar las piezas de datos. La interpretación de los datos depende completamente de la aplicación que los lee.

XML es texto. Los documentos XML están escritos en forma de texto, lo cual es una ventaja, ya que permite a los desarrolladores corregir fácilmente sus aplicaciones, a diferencia de otros formatos binarios de datos.

4 Etiquetas: palabras encerradas en <>

http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

http://es.wikipedia.org/wiki/Lenguaje_de_marcado

http://es.wikipedia.org/wiki/Metalenguaje

http://es.wikipedia.org/wiki/World_Wide_Web_Consortium

http://es.wikipedia.org/wiki/XHTML

http://es.wikipedia.org/wiki/SVG

http://es.wikipedia.org/wiki/MathML

http://es.wikipedia.org/wiki/Tecnolog%C3%ADa


23

XML es voluminoso. Debido a que XML es n formato de texto y usa etiquetas para delimitar los datos, los archivos XML son grandes en tamaño respecto a los formatos binarios. Esta fue una decisión consciente de los diseñadores de XML, que aunque representa un desventaja, usualmente se compensa con otras ventajas.

XML es una familia de tecnologías. XML 1.0, es la especificación que define qué son las etiquetas y los atributos, sin embargo, XML es un conjunto creciente de módulos que ofrecen diferentes servicios útiles para realizar diferentes tareas. Algunos miembros de esta familia son:

Xlink que describe un modo standard de agregar hipervínculos a un archivo XML. XPointer y XFragments son sintaxis en desarrollo para apuntar a partes de un documento XML. XSL es el lenguaje avanzado para expresar las hojas de estilo. XML Schema apoya a los desarrolladores en la definición con precisión de las estructuras de sus propios formatos basados en XML.

Elegir XML como la base de un proyecto, se gana acceso a una comunidad grande y creciente de herramientas e ingenieros experimentados en la tecnología. XML requiere construir sus propios programas y procedimientos que lo manipulen, sin embargo existen muchas herramientas disponibles. XML no es siempre la mejor solución, pero siempre vale la pena considerarlo.

2.2.2. Estructura de un documento XML

XML expresa la información estructurada de la manera más abstracta y reutilizable posible. Que la información sea estructurada quiere decir que se compone de partes bien definidas y que esas partes se componen a su vez de otras partes. Una etiqueta consiste en una marca hecha en el documento, que señala una porción de éste como un elemento. Un pedazo de información con un sentido claro y definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se está señalando. Los documentos XML bien formados5 deben considerar los siguientes puntos:

Estructura jerárquica. Una etiqueta debe estar correctamente incluida en otra, es decir, deben estar correctamente anidadas. Los elementos con contenido deben estar correctamente cerrados.

Los documentos XML sólo permiten un elemento raíz del que todos los demás sean parte, es decir, solo pueden tener un elemento inicial.

5 Bien formados: del inglés well formed, se refiere a documentos que cumplen con las definiciones básicas

de formato (sintaxis).

http://www.w3.org/TR/xlink/

http://www.w3.org/TR/WD-xptr

http://www.w3.org/TR/xsl/

http://www.w3.org/Style/CSS-vs-XSL

http://www.w3.org/TR/xmlschema-1/


24

Los valores atributos en XML siempre deben estar encerrados entre comillas simples o dobles.

XML no es sensible a mayúsculas y minúsculas.

Es necesario asignar nombres a las estructuras, tipos de elementos, entidades, elementos particulares. En XML los nombres tienen alguna característica en común.

Se puede genera un archivo XML, con cualquier procesador de texto, sin embargo,

existen entornos de desarrollo como Eclipse o Visual Studio, que facilitan la generación de XML bien formados.

Un documento XML incluye el prólogo y el cuerpo del documento así como texto de etiquetas.

Prólogo: Aunque no es obligatorio, los documentos XML pueden empezar con unas líneas que describen la versión XML y el tipo de documento entre otros. El prólogo de un documento XML contiene:

Una declaración XML. Es la sentencia que declara al documento como un documento XML.

Una declaración de tipo de documento. Enlaza el documento con su DTD (definición de tipo de documento), o el DTD puede estar incluido en la propia declaración o ambas cosas al mismo tiempo.

Uno o más comentarios e instrucciones de procesamiento. Cuerpo: A diferencia del prólogo, el cuerpo no es opcional en un documento XML,

el cuerpo debe contener un solo elemento raíz, característica indispensable también para que el documento esté bien formado. Sin embargo es necesaria la adquisición de datos para su buen funcionamiento.

Elementos. Los elementos XML pueden tener contenido (más elementos, caracteres o ambos), o bien ser elementos vacíos.

Atributos. Los elementos pueden tener atributos, que son una manera de incorporar características o propiedades a los elementos de un documento. Deben ir entre comillas. Por ejemplo, un elemento "chiste" puede tener un atributo "tipo" y un atributo "calidad", con valores "vascos" y "bueno" respectivamente.

<chiste tipo="vascos" calidad="bueno">Esto es un dia que Patxi y Josu van

paseando…</chiste>

Entidades predefinidas. Entidades para representar caracteres especiales para que, de esta forma, no sean interpretados como marcado en el procesador XML. Por ejemplo & amp; Caracter &.

http://es.wikipedia.org/wiki/DTD


25

Secciones CDATA. Es una construcción en XML para especificar datos utilizando cualquier carácter sin que se interprete como marcado XML. Permite que Caracteres especiales no rompan la estructura. Por ejemplo

<![CDATA[ contenido especial: áéíóúñ& ]]> En la tabla 2.2, se muestra un ejemplo de un documento XML

Tabla 2.2. Ejemplo de un documento XML <?xml version="1.0" encoding="ISO-8859-1" ?>

<!DOCTYPE Edit_Mensaje SYSTEM "Lista_datos_mensaje.dtd"

[<!ELEMENT Edit_Mensaje (Mensaje)*>]>

<Edit_Mensaje>

<Mensaje>

<Remitente>

<Nombre>Nombre del remitente</Nombre>

<Mail> Correo del remitente </Mail>

</Remitente>

<Destinatario>

<Nombre>Nombre del destinatario</Nombre>

<Mail>Correo del destinatario</Mail>

</Destinatario>

<Texto>

<Asunto>

Este es mi documento con una estructura muy sencilla

no contiene atributos ni entidades....

</Asunto>

<Parrafo>

Este es mi documento con una estructura muy sencilla

no contiene atributos ni entidades....

</Parrafo>

</Texto>

</Mensaje>

</Edit_Mensaje>

2.3. MDA (Model Driven Architecture)

MDA (Model Driven Architecture), Arquitectura Dirigida por Modelos. Desarrollado por la OMG (Object Management Group, Grupo de Gestión de Objetos) se formó para ayudar a los desarrolladores a reducir la complejidad, bajar los costos y acelerar la introducción a nuevas aplicaciones de software. Sin embargo estas metas se lograron hasta que el mismo OMG desarrolló la MDA[Miller 2003] (Model Driven Architecture), la Arquitectura Dirigida por Modelos tiene como objetivo la portabilidad, la interoperabilidad y la reusabilidad. Una de las tendencias actuales en ingeniería de software es el desarrollo de sistemas de información a través del enfoque de “Desarrollo Dirigido por Modelos” (MDD, Model Driven Development) y MDA provee un enfoque en tres modelos con


26

diferentes niveles de abstracción, cada uno integrado por un conjunto de modelos con diferentes tipos de relación: CIM Computation Independent Model - (Modelo Independiente de Cómputo) PIM Platform Independent Model - (Modelo Independiente de Plataforma) PSM Platform Specific Model - (Modelo de Plataforma Específica).

2.4.1. Nivel CIM

El nivel CIM (Computation Independent Model), Modelo Independiente de Cómputo, de

acuerdo con [Miller 2003], es la vista de un sistema sin considerar aspectos de cómputo. El

CIM, es a veces llamado un modelo de dominio o modelo de negocio; para especificar

este modelo se utiliza un vocabulario que es propio de los profesionales del dominio en

cuestión.

Se supone que los profesionales del dominio no tienen conocimiento acerca de cómo

llevar a cabo la funcionalidad de sus requerimientos.

El nivel CIM es muy importante como un puente entre los expertos del dominio y sus

requerimientos por un lado y por el otro los expertos en el diseño y construcción de

artefactos que satisfacen tales requerimientos.

En el nivel CIM, se modelan los requerimientos del sistema. El nivel CIM describe la

situación en la cual se usará el sistema y el ambiente en el que operará.

En el nivel CIM es importante entender exactamente qué se espera que haga el sistema,

no sólo para entender el problema, sino también como una forma de establecer el

vocabulario compartido con otros modelos, tales como el PIM y el PSM.

2.4.2. Nivel PIM

El nivel PIM (Platform Independent Model), Modelo Independiente de Plataforma, de

acuerdo con [Miller 2003], es la vista de un sistema sin especificar una plataforma de

desarrollo.

El PIM muestra un grado de independencia de la plataforma, de esta forma es adecuado

para usarse en varias plataformas similares. En el nivel PIM, se describe el sistema sin

mostrar detalles de su plataforma.


27

2.4.3. Nivel PSM

El nivel PSM (Platform Specific Model), Modelo de Plataforma Específica, de acuerdo con

[Miller 2003], es la vista de un sistema considerando una plataforma específica. El PSM

combina la especificación obtenida del PIM especificando los detalles de uso en un tipo de

plataforma en particular.

2.5. Herramientas MDA

A continuación se describen algunas herramientas que apoyan el desarrollo de software con el enfoque MDA.

2.5.1. Proyecto Eclipse [Eclipse 2009]

El proyecto Eclipse (The Eclipse Project) es un proyecto de desarrollo de software, dedicado a proporcionar una plataforma industrial robusta, con amplias características y con calidad comercial para el desarrollo de herramientas altamente integradas. Eclipse está desarrollado con los lenguajes Java, Ansi C, C++ y JSP, principalmente. A diferencia de muchas aplicaciones escritas en Java, Eclipse tiene el aspecto y el comportamiento de una aplicación nativa. No está programada en Swing, sino en SWT (Standard Widget Toolkit) y Jface (juego de herramientas construida sobre SWT), que emula los gráficos nativos de cada sistema operativo. Eclipse consta de tres subproyectos: la Plataforma Eclipse, la Java Development Tool y el Plug-in Development Environment.

La arquitectura de Eclipse se conforma de: núcleo, área de trabajo (workspace), área de desarrollo o interfaz de usuario (workbench), ayuda de equipo (team support) y la documentación (help). A continuación se describe cada elemento de la arquitectura.

Núcleo: su tarea es determinar cuáles son los plug-ins6 disponibles de Eclipse. Cada plug-in tiene un fichero XML manifest que lista los elementos que necesita de otros plug-ins así como los puntos de extensión que ofrece. Sólo se cargan los plug-ins necesarios en el momento de ser utilizados para minimizar el tiempo de arranque y recursos.

Área de trabajo (workspace): maneja los recursos del usuario, organizados en uno o más proyectos. Cada proyecto corresponde a un directorio y contienen archivos y carpetas.

Interfaz de usuario (workbench): muestra los menús y herramientas, y se organiza en perspectivas que configuran los editores de código y las vistas.

6 Plug-in. Es la unidad mínima de la plataforma que puede desarrollarse por separado y que aporta una

nueva funcionalidad.


28

Ayuda de equipo: este plug-in facilita el uso de un sistema de control de versiones para manejar los recursos en un proyecto del usuario y define el proceso necesario para guardar y recuperar de un repositorio.

Documentación: el componente de ayuda es un sistema de documentación extensible. Los proveedores de herramientas pueden añadir documentación en formato HTML y usar XML para definir una estructura de navegación.

El proyecto Eclipse actualmente se encuentra en desarrollo y está compuesto de varios proyectos diferentes que se actualizan constantemente y que abordan diferentes aspectos, tales como:

Plataforma de Herramientas Web. Es una plataforma de herramientas para desarrollar aplicaciones Web en Java EE.

Proyecto de Edición Visual. Es una plataforma para crear constructores GUI para Eclipse.

Plataforma de Modelado Eclipse. Es una plataforma de modelado y generación de código para construir herramientas y otras aplicaciones basadas en un modelo de datos estructurado, desde una especificación de modelo descrita en XMI.

Herramientas de Modelado Generativo. Es un grupo de herramientas para modelado, entre las que se incluye una herramienta de transformación de modelo QVT.

UML2. Una implementación de UML 2.x metamodel para soportar el desarrollo de herramientas de modelado.

Tabla 2. 3.Historia cronológica del proyecto Eclipse

Año Actividad

1999 Inicia el trabajo en OTI/IBM

2000 Se presenta Eclipse Tech Preview

2001 http://www.eclipsecorner.org/ da inicio Surgen las versiones Eclipse 0.9 y Eclipse 1.0 IBM Dona el código base de Eclipse Se forma el consorcio para el desarrollo futuro de Eclipse como código abierto http://www.eclipse.org/

2002 Se publican las versiones: Eclipse 2.0, Eclipse 2.0.1, Eclipse 2.0.2

2003 Se publica la versión 2.1 de Eclipse Se crea la fundación independiente de IBM Se publica la versión 3.0 de Eclipse

2006 La fundación Eclipse coordina 10 proyectos de código abierto Plataforma Eclipse 3.2 A esta versión se le asigna el nombre de Callisto

2007 Se publica la versión Eclipse 3.3, con el nombre de Europa, la versión consecutiva de Callisto.

2008 La versión consecutiva a Europa es Ganymede, que corresponde a la versión 3.4 de Eclipse.

2009 Actualmente la versión de Eclipse es la 3.5, denominada Galileo.

http://es.wikipedia.org/w/index.php?title=Metamodel&action=edit&redlink=1

http://www.eclipsecorner.org/

http://www.eclipse.org/


29

Eclipse es un proyecto muy grande que comenzó como un proyecto de IBM Canadá y fue desarrollado por OTI (Object Technology International). En la tabla 2.3, se muestra la cronología de proyecto Eclipse.

2.6. Funciones matemáticas

Definición de función [Rosen 2004] Sean A y B conjuntos. Una función f de A en B es una asignación de exactamente un elemento de B a cada elemento de A. Escribimos f (a) = b si b es el único elemento de B asignado por la función f al elemento a de A. Si f es una función de A en B, escribimos

f: A B (Ecuación 2.5.1) Si f es una función de A en B, decimos que A es el dominio de f y B es el codominio de f. Si f (a) = b, decimos que b es la imagen de a y a es una preimagen de b. El rango o imagen de f es el conjunto de todas las imágenes de elementos de A. También decimos, si f es una función de A en B, que f transforma A en B. La figura 2.14, representa una función f de A en B

f

f

a

A

A

b=f(a)

B

A Figura 2.14. La función f transforma A en B [Rosen 2004]

http://es.wikipedia.org/w/index.php?title=Object_Technology_International&action=edit&redlink=1


30

Definición de función, transformación o mapeo De acuerdo con José María Rico Martínez7, sean A y B dos conjuntos de elementos o “puntos”. Una función, transformación o mapeo F de A en B se define como una relación o regla de correspondencia tal que para cada elemento a ∈ A hay asociado un único elemento b ∈ B. El símbolo F : A → B se usa para indicar que F es un mapeo de A en B. La figura 2.15 muestra una función entre el conjunto {a, b, c, d, e} y el conjunto {1, 2, 3, 4, 5}.

Figura 2.15. Función entre el conjunto {a, b, c, d, e} y el conjunto {1, 2, 3, 4, 5}.

7 José María Rico Martínez. Funciones y transformaciones lineales. Universidad de Guanajuato. http://www.ingenierias.ugto.mx/profesores/chema/documentos/Algebra Lineal/Algebra_lineal_11.pdf. visitada el 2 de abril de 2011.

http://www.ingenierias.ugto.mx/profesores/chema/documentos/Algebra%20Lineal/Algebra_lineal_11.pdf

31

Capítulo 3. Estado del arte

En este capítulo se muestran trabajos relacionados con la presente investigación. Es importante mencionar que la mayoría de los trabajos publicados referente al tema de transformaciones de modelos MDA, se enfocan en las transformaciones del nivel PIM al nivel PSM y del nivel PSM a la implementación. Son pocos los trabajos que abordan la transformación del nivel CIM al nivel PIM, que es el tema de esta tesis.

3.1. Trabajos relacionados Se presentan tres trabajos de Hendryx&Associates [Hendryx 2000], [Hendryx 2003] y [Hendryx 2003a], que es una organización que propone y aplica una técnica de desarrollo de software basado en modelado UML y ha trabajado en el tema del modelado en los niveles CIM y PIM.


32

Se presenta también un trabajo [Rodríguez 2006], que propone un conjunto de transformaciones entre modelos CIM y modelos PIM.

Por último se presenta un trabajo [Bollati 2007], que muestra un análisis comparativo de varias herramientas MDA. Este análisis permite ver que aunque estas herramientas trabajan el modelado en el nivel CIM, no permiten transformaciones a partir de este nivel. Por lo cual es necesario desarrollar investigaciones al respecto, tal como es el objetivo de esta tesis.

3.1.2. Hendryx & Associates [Hendryx 2000]

Hendryx & Associates (H&A) es una organización fundada en el año 2000 para desarrollar y aplicar la Ingeniería de Negocio Basada en Modelos (MBBE, Model-Based Business Engineering™). MBBE es una técnica de desarrollo de software basado en modelado UML. H&A desarrollaron una semántica de vocabulario y reglas del negocio (Semantics of Business Vocabulary and Business Rules, SBVR) aprobado por el OMG en septiembre de 2005. SBVR es la primera especificación de OMG para el modelado de lenguaje natural y el primero en incorporar un metamodelo de la lógica formal. H&A han publicado artículos referentes al modelado en los niveles CIM a PIM, que a continuación se describen: Architecture of Business Modeling [Hendryx 2003]

Architecture of Business Modeling (Arquitectura de Modelado de Negocios) presenta un enfoque por capas tomando el metamodelo del modelado de negocios BMM (Business Modeling Metamodel), para alcanzar el objetivo de generar modelado de manera flexible, en la figura 3.1 se muestra la representación del modelado por capas en forma de pirámide.

Las 2 capas de la base de la pirámide (capas verdes) representan la semántica del negocio de las reglas del negocio (Business Semantics of Business Rules, BSBR).


33

Figura 3. 1. Pirámide de la distribución en capas de modelado [Hendryx 2003]

Las siguientes 4 capas (capas de color azul), representan otra información importante para el modelado del negocio, obtenida de las técnicas de modelado, del modelo de la industria, del modelo de empresa y del modelo de negocios del usuario. Los modelos representados en estas capas, representan un modelo particular para un proyecto en específico.

Integrating Computation Independent Business Modeling Languages into the MDA with UML 2 [Hendryx 2003a]

En este trabajo se propone el UML4MDA en la infraestructura de UML 2. [Hendryx 2003a] explica que UML4MDA provee el soporte a los modeladores para definir una familia de lenguajes de modelado relacionales. Esta familia es esencial para la evolución del modelado de negocios independiente de cómputo (CIM) y del propio MDA. Para transformar modelos de CIM, PIM y PSM, formando una familia de lenguajes relacionados que pueden usar herramientas estándares y poder extender UML 2. Ver figura 3.2.


34

Figura 3. 2. Conceptos compartidos semánticamente entre los lenguajes de modelado

[Hendryx 2003a]

3.1.3. Hacia la obtención de clases de análisis y casos de uso desde modelos de procesos de negocio [Rodríguez 2006]

Un proceso de negocio construido de acuerdo a los requerimientos del negocio, es de gran utilidad en el proceso de construcción de software. Ya que es posible obtener, a partir de dicho proceso los requisitos del sistema, que es una etapa básica en la construcción del software.

En el artículo se propone un conjunto de transformaciones entre modelos CIM y modelos PIM. En la figura 3.3, se aprecia el esquema general de la propuesta. Se proponen las siguientes transformaciones:

Transformaciones de CIM a CIM. Se establece una relación entre conceptos especificados con BPMN8 y sus equivalentes en UML.

Transformación de CIM a PIM. Se obtienen Clases de Análisis y Casos de Uso a partir del modelo de proceso de negocio.

8 Consultar glosario.


35

Figura 3.3. Esquema general de la propuesta [Rodríguez 2006]

La figura 3.3, muestra una comparación entre los modelos componentes MDA (columna izquierda), los flujos de trabajos propuestos en el proceso unificado (columna derecha) y la propuesta de este artículo.

Este artículo propone lo siguiente:

La transformación de modelos desde CIM hacia CIM (C2C). Incluye modelos descritos con BPMN-BPD. El modelo de proceso de negocio, especificado con BPMN-BPD o UML 2.0-AD, es un modelo CIM y puede ser usado en el flujo de trabajo “modelo del negocio” del proceso unificado.

Las transformaciones desde CIM hacia PIM (C2P). Utilizadas para obtener clases de análisis (C2P-1) y casos de uso (C2P-2). Tanto las clases de análisis como los casos de uso son modelos PIM y pueden ser usados en los flujos de trabajo “Requisitos” y “Análisis & Diseño” del proceso unificado.

Se propone utilizar QVT para especificar las transformaciones porque es compatible

con el estándar MDA ya que su sintaxis abstracta es definida como un metamodelo MOF 2.0. (Meta Object Facility).

3.1.4. Una revisión de herramientas MDA [Bollati 2007]

La evolución de las herramientas de modelado, se inició con editores y procesadores de texto y herramientas de dibujo que incorporaban notaciones gráficas. Después aparecieron metodologías de desarrollo que integran diferentes técnicas, llamadas herramientas CASE (Computer-Aided Software Engineering). Posteriormente siguieron las herramientas extensibles, herramientas de transformación, generadoras de código y actualmente las herramientas MDA.


36

En este artículo se presenta un estudio comparativo de AndroMDA, ArgoUML y el entorno de desarrollo Eclipse. Con el objetivo de determinar la necesidad de desarrollo de una nueva herramienta o la adaptación de alguna de las mencionadas, para dar soporte a MIDAS9. Los resultados del análisis se presentan en la tabla 3.1, donde se muestra la comparación de Eclipse EMF, AndroMDA y ArgoUML. Los resultados se agrupan de la siguiente manera:

Características funcionales: Como son qué niveles de MDA cubre, el grado de generación de código, el grado de automatización de las transformaciones, el grado que muestra de interacción con el usuario, los tipos de transformaciones verticales y/o horizontales.

Características Técnicas: Tales características como el lenguaje de almacenamiento, gestión de modelos, las plataformas tecnológicas que soportan y el ámbito de aplicación.

Características de calidad: Las indispensables que debería cumplir una herramienta MDA, como son: el uso de estándares como UML, XML y MOF, lograr la extensibilidad, la Usabilidad y la interoperabilidad entre herramientas.

9 MIDAS. Es una arquitectura de modelos para el desarrollo de sistemas de información, basada en MDA.


37

Tabla 3. 1. Resultado del análisis comparativo de herramientas MDA [Bollati 2007]

Eclipse EMF AndroMDA ArgoUML

Características funcionales

Niveles que cubre CIM-PIM-PSM PIM-PSM CIM-PIM-PSM

Grado de Generación de código

JAVA principalmente Cualquier lenguaje. Se debe tener el cartdrige

10

adecuado

JAVA+AndroMDA

Transformaciones Completamente Completamente Completamente

Grado de Interacción con el Usuario

Alto Alto Alto

Tipo de Transformaciones

Verticales, se pueden implementar las

horizontales


horizontales


horizontales

Características técnicas

Lenguaje de almacenamiento y gestión de modelos

XMI XMI XMI

Plataformas y tecnologías soportadas

Ecore-GenModel-Java-H. Case para generar

diagramas UML

H. Case generen diagramas UML con

formato XMI- Nhibernate

11-Maven

12-

JBoss13

JAVA

Ámbito de aplicación Desarrollos orientados a servicios

SIW14

- Desarrollos orientados a servicios

SIW- Desarrollos orientados a servicios

Características de calidad

Uso de estándares XMI-UML-MOF15

XMI-UML-MOF UML-XMI-SVG16

-OCL17

Extensibilidad Por medio de pluggins Por medio de cartridge Integración con herramientas

Usabilidad Fácil de usar Difícil de usar Fácil de usar

Interoperabilidad con herramientas

Integración con otras herramientas



10 Tecnología de cartridge: Permite obtener módulos en diferentes plataformas, a partir de los PSM´s se

puede generar código en el lenguaje de programación que se desee siempre que se tenga el cartridge correspondiente. 11 NHibernate: Es la versión .Net de Hibernate, que es una herramienta de mapeo objeto-relacional para la

plataforma Java que facilita el mapeo de atributos entre una base de datos relacional tradicional y el modelo de objetos de una aplicación, mediante archivos declarativos (XML) que permiten establecer estas relaciones. 12 Maven es una herramienta de software para la gestión y construcción de proyectos Java creada por Jason

van Zyl, de Sonatype, en 2002. 13

JBoss es un servidor de aplicaciones J2EE de código abierto implementado en Java puro. 14

SIW, Sistemas de Información Web 15

MOF, The Meta-Object Facility, es un conjunto de interfases estándar usados para definir y manipular un conjunto de metamodelos y sus correspondientes modelos. 16

SVG, (Scalable Vector Graphics), Gráficos Vectoriales Escalables. 17

OCL, (Object Constraint Language) es un lenguaje declarativo para describir reglas aplicadas a UML.


38

3.1.5. Conclusiones

Los trabajos presentados en este capítulo, abordan los niveles CIM y PIM, sin embargo los trabajos de [Hendryx 2003] y [Hendryx 2003a], no especifican las operaciones de transformación. Por otra parte [Rodríguez 2006], coincide con esta investigación, al proponer un conjunto de transformaciones, sin embargo, difiere en que, utiliza el modelo de negocios, diagramas de casos de uso y diagramas de clases, mientras que en esta investigación se propone el uso de diagramas de casos de uso, diagramas de clases, diagramas de secuencia y diagramas de actividad. Cabe señalar, que los trabajos presentados utilizan además de UML, el modelado de negocios, mientras que la presente investigación, sólo utiliza UML. Ver Tabla 3.2.

Tabla 3. 2. Tabla comparativa de los trabajos relacionados y esta investigación

Trabajo Propuesta Modelos que abarca Representación utilizada

[Hendryx 2003] Arquitectura de modelado de negocios

Meta-modelo de negocios

Semántica del negocio (reglas del negocio)

[Hendryx 2003a] Herramienta de modelado UML (UML4MDA)

CIM, PIM y PSM UML

[Rodríguez 2006] Conjunto de transformacionesCIM a PIM

CIM ( Modelo de negocios)

PIM (Diagramas de casos de uso y diagramas de clases)

UML

BPMN

QVT

Presente trabajo de investigación

Transformaciones de nivel CIM a PIM

CIM (diagramas de casos de uso, de clases, de secuencia y de actividad)

PIM (diagramas de casos de uso, de clases, de secuencia y de actividad)

UML

Propuesta de una estructura jerárquica

39

Capítulo 4. Diagramas UML para los niveles CIM y PIM

En esta investigación, se propone utilizar los diagramas de casos de uso, diagramas de clases, diagramas de actividad y diagramas de secuencia, para modelar los niveles CIM y PIM.

En este capítulo se describen las características, elementos y un conjunto de reglas y restricciones de diseño, aplicables a los niveles CIM y PIM de cada diagrama UML propuesto. Lo cual facilitará determinar cuáles son las reglas y operaciones para transformarlos en los niveles CIM y PIM.


40

4.1. Propuesta de diagramas para los niveles CIM y PIM

Se propone utilizar los diagramas de casos de uso, diagramas de clases, diagramas de secuencia y diagramas de actividad, en los niveles CIM y PIM (ver tabla 4.1), entre otras razones, debido a que de acuerdo con [López 2007], estos diagramas representan el 60.67% del proceso MDA.

Tabla 4.1. Propuesta de distribución de diagramas UML en los niveles CIM y PIM

Nivel CIM Nivel PIM

Diagramas de casos de uso Diagramas de secuencia Diagramas de actividad Diagramas de clases

Diagramas de casos de uso Diagramas de secuencia Diagramas de actividad Diagramas de clases

Estos diagramas representan los siguientes aspectos de un proceso de software:

Los aspectos del negocio y del proceso general (diagramas casos de uso)

Las actividades del proceso (diagramas de actividad)

La secuencia de las actividades (diagrama de secuencias)

La clase de los objetos que intervienen en el proceso (diagramas de clases)

En el nivel CIM se representan los aspectos mencionados en un nivel general, mientras que en el nivel PIM, se representan los mismos aspectos, utilizando mayor nivel de detalle; sin llegar a detalles técnicos acerca de una plataforma tecnológica para el desarrollo.

4.2. Características, elementos y reglas de diseño para los diagramas UML

A continuación se describen las características, los elementos y las reglas y restricciones de diseño para cada uno de los diagramas propuestos en esta investigación, de acuerdo con los niveles CIM y PIM.


41

4.2.1. Diagrama de casos de uso

En la tabla 4.2, se muestran los elementos propuestos para el diagrama de casos de uso, su descripción, el símbolo correspondiente y una lista de los atributos para cada elemento.

Tabla 4.2. Elementos propuestos para el diagrama de casos de uso

Elemento Descripción Símbolo Atributos

Actor Representa quién o qué inicia una acción

dentro del sistema. Representa una

persona u objeto.

Id_actor

Nombre_actor

Caso de uso El caso de uso describe la funcionalidad

requerida por un sistema.

Id_caso_uso

Nombre_caso_de_uso

Relación C-A

Representa la relación que existe entre un

caso de uso y un actor.

Id_relacion_CA

Relación C-C Representa la relación entre casos de uso.

Puede ser de tipo Include o Extend.

Id_relacion_CC

Tipo_relación

En la tabla 4.3 se muestran las reglas y restricciones propuestas para el diseño de diagramas de casos de uso para los niveles CIM y PIM.

Tabla 4.3. Reglas y restricciones de diseño del diagrama de caso de uso para los niveles CIM y PIM

Reglas y Restricciones de diseño del diagrama de casos de uso

Nivel CIM Nivel PIM

a) Se identifican y se definen los casos de uso del sistema.

b) Se identifican y se definen los tipos de relación entre casos de uso.

c) Se identifican y se definen los actores del sistema.

d) Se identifican y se definen las relaciones entre actores y casos de uso.

e) Se identifica y se define el límite del sistema

a) Se refina el diagrama agregando casos de uso más detallados o eliminando casos de uso.

4.2.2. Diagrama de clases

En la tabla 4.4, se muestran los elementos propuestos para el diagrama de clases, su descripción, el símbolo correspondiente y una lista de atributos para cada elemento.

En la tabla 4.5, se muestran las reglas y restricciones propuestas para el diseño de diagramas de clases para los niveles CIM y PIM.


42

Tabla 4.4. Elementos propuestos para el diagrama de clases


Clase

Representa los elementos de la clase de

objetos. Incluye nombre de la clase, los

nombres y tipos de los atributos y los

nombres y tipos de los métodos de la

clase.

Id_clase

Nombre_clase

Lista_atributos_de_clase

Lista_metodos_de_clase

Relación Representa la existencia de una relación

de asociación entre clases.

Id_relacion_clase

Nombre_relacion

Multiplicidad_relacion

Tabla 4.5. Reglas y restricciones de diseño del diagrama de clases para los niveles CIM y PIM

Reglas y Restricciones de diseño del diagrama de clases

Nivel CIM Nivel PIM

a) Se definen los nombres de las clases

a) Se definen los nombres y tipos de los atributos b) Se definen los nombres y tipos de los métodos c) Se definen los nombres de las relaciones de

asociación entre clases d) Se define la multiplicidad de las relaciones

4.2.3. Diagrama de actividad

En la tabla 4.6, se muestran los elementos propuestos para el diagrama de actividad, su descripción, el símbolo correspondiente y una lista de atributos para cada elemento.

Tabla 4.6. Elementos propuestos para el diagrama de actividad


Actividad Representa la acción que será realizada

por el sistema.

Id_actividad

Nombre_actividad

Nodo de

decisión

Representa la posibilidad de que ocurra

más de una transición (resultado) al

terminar una determinada actividad.

Id_nodo_decision

Decisión

Nodo de inicio Indica el inicio de las actividades

Id_nodo_inicio

Nodo final Representa el fin de un diagrama de

actividad

Id_nodo_final

Barra de

sincronización Representa la unión o bifurcación de

flujos de actividades.

Id_barra

Línea de flujo Representa la dirección del flujo de la actividad.

Id_linea_flujo


43

En la tabla 4.7, se muestran las reglas y restricciones propuestas para el diseño de diagramas de actividad para los niveles CIM y PIM.

Tabla 4.7. Reglas y restricciones de diseño del diagrama de actividad para los niveles CIM y PIM

Reglas y Restricciones de diseño del diagrama de actividad

Nivel CIM Nivel PIM

a) Se definen los pasos secuenciales de una actividad. b) Se establece el nodo inicial. c) Se definen las líneas de flujo de los pasos de la

actividad. d) Se establece el nodo final.

a) Se definen los nodos de decisión necesarios

b) Se definen las barras de sincronización necesarias.

4.2.4. Diagrama de secuencia

En la tabla 4.8, se muestran los elementos propuestos para el diagrama de secuencias, su descripción, el símbolo correspondiente y una lista de atributos para cada elemento.

Tabla 4.8. Elementos del diagrama de secuencia


Objeto Representa la existencia de un objeto.

Id_objeto

Nombre_objeto

Nombre_clase

Mensaje Representa la comunicación entre

objetos.

Id_mensaje

Operación

Tiempo Representa el tiempo de la secuencia de

acciones

Id_tiempo

Línea de vida Representa el tiempo de vida de un

objeto en la secuencia de acciones

Id_linea_de_vida


44

En la tabla 4.9, se muestran las reglas y restricciones propuestas para el diseño de diagramas de secuencia para los niveles CIM y PIM.

Tabla 4.9. Reglas y restricciones de diseño del diagrama de secuencias para los niveles CIM y PIM

Reglas y Restricciones de diseño del diagrama de secuencias

Nivel CIM Nivel PIM

a) Se definen los objetos que intervienen en el proceso.

b) Se definen las clases de los objetos.

a) Se definen los mensajes entre objetos. b) Se definen líneas de vida.

4.3. Conclusiones

Los diagramas propuestos para modelar los niveles CIM y PIM son: los diagramas de casos de uso, diagramas de clases, diagramas de actividad y diagramas de secuencia. Las reglas y restricciones propuestas para el diseño de cada diagrama en los niveles CIM y PIM, están basadas en las siguientes consideraciones:

El modelado del sistema en el nivel CIM se enfoca principalmente a: o La comprensión de los requerimientos del cliente o Conocer y entender el dominio del sistema o El proceso general del negoci0

Por lo cual se detallan más ampliamente en este nivel los diagramas de casos de uso y los diagramas de actividad. Mientras que los diagramas de clases y los diagramas de secuencia sólo se definen en forma general. El modelado del sistema en el nivel PIM se enfoca principalmente a:

o La arquitectura general del sistema o La interacción entre los elementos del sistema

Por lo anterior, se detallan más ampliamente en este nivel los diagramas de clases y los diagramas de secuencia. Mientras que los diagramas de casos de uso y los diagramas de actividad sólo se van refinando de acuerdo a detalles que surjan conforme avanza el desarrollo del sistema.

45

Capítulo 5. Modelado de software en los niveles CIM y PIM

En este capítulo se propone un procedimiento que describe el modelado de software en los niveles CIM y PIM. Este procedimiento describe la forma en que se van construyendo los diagramas UML en cada nivel, a partir de la información proporcionada por cliente(s) y analista(s) del sistema.

Este procedimiento servirá de base para determinar las operaciones elementales de transformación de modelos CIM a modelos PIM dentro del ambiente AGDE (§1.6).

También se propone una estructura jerárquica basada en XML, para organizar la información proporcionada por cliente(s), la cual es útil para generar los diagramas UML.


46

5.1. Descripción del procedimiento de modelado CIM y PIM

A continuación se describe la forma en que se van construyendo los diagramas UML en los niveles CIM y PIM, a partir de la información proveniente de cliente(s) y analista(s) del sistema de software. Esta información es la que conduce a la creación y transformación de los diferentes diagramas.

La información que provee un cliente se trata de:

Conocimiento de requisitos del sistema. Se refiere a lo que el cliente requiere que haga el sistema.

Conocimiento del dominio. Se refiere a los conceptos relacionados con el negocio.

Conocimiento de datos del sistema. Se refiere a los datos que el cliente requiere manipular y obtener del sistema.

Conocimiento acerca de los procesos. Se refiere a la forma en que se llevan a cabo las actividades en el negocio.

Esta información es la que permite al analista del sistema, modelar el sistema en diferentes niveles hasta llegar a la implementación.

La información que provee el analista del sistema es: Conocimiento técnico. Se refiere a que el analista posee los conocimientos

técnicos acerca del modelado y lenguaje UML. Conocimiento empírico. Se refiere a que el analista tiene conocimiento que ha

adquirido a través de la experiencia en el modelado.

El analista aporta, sus conocimientos acerca de técnicas de modelado y del lenguaje UML, así como los conocimientos adquiridos a través de la experiencia en el modelado y desarrollo de sistema, los cuales le permiten abstraer la información de un cliente a modelos de software.

En la tabla 5.1, se presenta la información que proveen tanto los cliente(s) como los analista(s) del sistema, la cual es necesaria para el desarrollo del software.

Tabla 5.1. Información que proveen cliente(s) y analista(s) para el desarrollo de software

Información

De cliente(s) De analista(s) del sistema

Conocimiento de requisitos del sistema Conocimiento del dominio Conocimiento de datos del sistema Conocimiento acerca de los procesos

Conocimiento técnico Conocimiento empírico


47

La figura 5.1, muestra un esquema de comunicación entre cliente(s) y analista(s), durante el desarrollo de software, que permiten modelar los niveles CIM y PIM.

5.2. Propuesta de procedimiento de modelado de software en los niveles CIM y PIM

Se considera muy importante la comunicación entre cliente(s) y analista(s) para el desarrollo del software por lo cual, en este trabajo se propone un procedimiento para el modelado en los niveles CIM y PIM, que se describe en la tabla 5.2.

Este procedimiento hace énfasis en la comunicación entre cliente(s) y analista(s), durante el proceso de software.

Tomando como base este procedimiento de modelado, se propone un conjunto de operaciones de transformación de los diagramas UML de nivel CIM al nivel PIM, tomando en cuenta la información proveniente de cliente(s) y analista(s). Estas operaciones se describen a detalle en (§6) de este documento.

En la figura 5.2, que ilustra el procedimiento de modelado CIM y PIM (descrito en la tabla 5.2), el cual muestra que la información proporcionada por cliente(s) y analista(s), es indispensable para crear los diagramas, así como para lograr la transformación entre ellos en los niveles CIM y PIM.

Negocio Negocio+técnica Técnica

Cliente Analista Desarrollador

CIM PIM

Figura 5.1. Comunicación entre nivel CIM y PIM durante el proceso de software


48

En la figura 5.3 se muestra el diagrama de actividad correspondiente al procedimiento de modelado CIM y PIM.

Tabla 5.2. Procedimiento de modelado CIM y PIM

Procedimiento de modelado CIM y PIM Inicio 1. El analista del sistema, se entrevista con los clientes, particularmente con los actores del

sistema, para conocer sus requerimientos. 2. Los clientes proporcionan información útil al analista del sistema. 3. El analista del sistema con la información obtenida y su experiencia y conocimiento de

modelado UML, crea los primeros diagramas UML. 4. Repetir

4.1. El analista se entrevista con los clientes, para obtener información que le permita refinar los diagramas UML.

4.2. Los clientes proporcionan información útil al analista del sistema. 4.3. El analista del sistema refina sus diagramas UML, con la información obtenida y su

experiencia y conocimiento. Hasta que se obtengan los diagramas UML que modelan el sistema correctamente en los niveles CIM y PIM, es decir, ya no requieren de refinamiento.

Fin.


49

Refinamiento/Adición

Refinamiento/Adición

Transformación de

diagramas

Información inicial

CIM

PIM

De cliente(s)

Diagrama de

casos de uso

Diagrama de

clases

Diagrama de

actividad

Diagrama de

secuencia

Diagrama de

casos de uso

Diagrama de

secuencia

Diagrama de

actividad

Diagrama de

clases

De analista(s)

Información adicional

De cliente(s) De analista(s)

Creación de

diagramas

Figura 5.2. Propuesta de procedimiento de modelado de software en los niveles CIM y PIM


50

Figura 5.3. Diagrama de actividad del procedimiento de modelado de software en los niveles CIM y PIM


51

5.3. Estructuras jerárquicas de la información proporcionada por cliente(s) y analista(s)

Considerando la importancia de la información que intercambian cliente(s) y analista(s) para lograr el modelado del sistema, en esta investigación, se propone una estructura jerárquica para organizarla en elementos esenciales, los cuales permitirán interpretarla en forma sencilla en elementos de diagramas UML y facilitarán la transformación de diagramas. Se proponen cuatro estructuras jerárquicas, cada una con información específica útil para obtener cada tipo de diagrama UML. Estas estructuras están basadas en XML, por lo que se utilizarán etiquetas para describir cada elemento y se agrupan de acuerdo a los tipos de elementos.

La estructura jerárquica contiene información expresada en términos utilizados y comprensibles por el cliente y analista, no en términos específicos utilizados en diagramas UML.

Las estructuras jerárquicas propuestas son (tabla 5.3):

Tabla 5.3. Estructuras jerárquicas para la información proporcionada por cliente(s) y analista(s)

Nombre Útil para el diagrama UML

Estructura jerárquica A Diagrama de casos de uso

Estructura jerárquica B Diagrama de clases

Estructura jerárquica C Diagrama de actividad

Estructura jerárquica D Diagrama de secuencia

5.3.1. Estructura jerárquica A

La estructura jerárquica A (EJA), organiza la información proporcionada por cliente(s) y analista(s), la cual servirá para obtener diagramas de casos de uso de UML. Esta información se describe en la tabla 5.4. La EJA se describe en la tabla 5.5.

Tabla 5.4. Información proporcionada por cliente(s) y analista(s), útil para diagramas de casos de uso

Elementos de información Descripción

Nombre del sistema Se refiere al nombre del sistema.

Roles de los usuarios del sistema Define quiénes usarán el sistema y su propósito de acuerdo a su rol.

Requerimientos funcionales del sistema Describe los requerimientos funcionales del sistema. Expresa qué necesita que haga el sistema.

Relación de los usuarios con los requerimientos Describe para qué quiere cada usuario el sistema de acuerdo con su rol.

Relaciones entre requerimientos Describe qué relación hay entre los requerimientos.


52

Tabla 5.5. Estructura jerárquica A

Información de la estructura jerárquica A <Sistema>

< nombre_sistema> nombre del sistema </nombre_sistema>

</Sistema> <Usuarios> <usuario> <id_usuario> identificador del usuario </id_usuario> <rol_usuario> nombre del rol del usuario </rol_usuario> </usuario> </Usuarios> <Requerimientos funcionales del sistema> <requerimiento> <id_req> identificador del requerimiento </id_req> <nombre_req>descripción del requerimiento funcional </nombre_req> </requerimiento> </Requerimientos funcionales del sistema> <Usuarios_por_requerimiento_funcional> <usuario-req> <id_usuario-req>identificador de la relacion usuario-requerimiento </id_usuario-req> <id_usuario>identificador del usuario </id_usuario> <id_req> identificador del requerimiento </id_req> </usuario-req> </Usuarios_por_requerimientos_funcionales> <Relaciones_entre_requerimientos> <req-req> <id_req-req>identificador de la relación requerimiento-requerimiento </id_req-req> <id_req_fuente>identificador del requerimiento fuente </id_req_fuente> <id_req_destino>identificador del requerimiento destino </id_req_destino> <tipo_relacion> tipo de la relación (incluye o extiende)</tipo_relacion> </req-req> </Relaciones_entre_requerimientos>

5.3.2. Estructura jerárquica B La estructura jerárquica B (EJB), organiza la información proporcionada por cliente(s) y analista(s), la cual servirá para obtener diagramas de clases de UML. Esta información se describe en la tabla 5.6. La EJB se describe en la tabla 5.7.

Tabla 5.6. Información proporcionada por cliente(s) y analista(s), útil para diagramas de clases


Entidades del sistema Identifica las entidades que intervienen en el sistema.

Características de las entidades Define las características de las entidades. Incluyendo su tipo.

Funcionalidad de las entidades Describe la funcionalidad de cada entidad.

Relación entre entidades Describe cómo se relacionan las entidades entre sí. Incluyendo el número de entidades en cada relación.


53

Tabla 5.7. Estructura jerárquica B

Información de la estructura jerárquica B

<Entidades> <entidad> <id_entidad> identificador de la entidad del sistema </id_entidad> <nombre_entidad> nombre de la entidad </nombre_entidad> <caracteristicas_entidad> <caracteristica> <nombre_caract> nombre de la característica de la entidad </nombre_caract> <tipo_caract> tipo de la característica de la entidad </tipo_caract> </caracteristica> </caracteristicas_entidad> <funcionalidades_entidad> <funcionalidad> <nombre_func> nombre de la funcionalidad de la entidad </nombre_func> <tipo_func> tipo de la funcionalidad de la entidad </tipo_func> </funcionalidad> </funcionalidades_entidad> </entidad> </Entidades> <Relaciones> <relacion> <id_relacion> identificador de la relacion entre entidades </id_relacion> <tipo_relacion> descripción del tipo de relación </tipo_relacion> <id_entidad_fuente> identificador de la entidad relacionada fuente </id_entidad_fuente> <num_entidad_fuente> número de elementos de la entidad relacionada fuente </num_entidad_fuente> <id_entidad_destino> identificador de la entidad relacionada destino </id_entidad_destino> <num_entidad_destino> número de elementos de la entidad relacionada destino </num_entidad_destino> </relacion> </Relaciones>

5.3.3. Estructura jerárquica C La estructura jerárquica C (EJC), organiza la información proporcionada por cliente(s), la cual servirá para obtener diagramas de actividad de UML. Esta información se describe en la tabla 5.8. La EJC se describe en la tabla 5.9.


54

Tabla 5.8. Información proporcionada por cliente(s) y analista(s), útil para diagramas de actividad


Actividades del proceso Describe las actividades del proceso.

Actividad inicial del proceso Identifica la actividad que inicia el proceso.

Actividad(es) final(es) del proceso Identifica las actividades con las que finaliza el proceso.

Flujo de actividades Describe el flujo de las actividades.

Sincronización de actividades Describe las actividades que se sincronizan

Decisiones Describe el flujo de actividades de acuerdo decisiones específicas.

Tabla 5.9. Estructura jerárquica C

Información de la estructura jerárquica C

<Actividad_inicial> <id_actividad_inicial> identificador de la actividad inicial </id_actividad_inicial> <nombre_actividad_inicial> nombre de la actividad inicial </nombre_actividad_inicial> </Actividad_inicial> <Actividades_intermedias> <actividad> <id_actividad> identificador de la actividad </id_actividad> <nombre_actividad> nombre de la actividad </nombre_actividad> </actividad> </Actividades_intermedias> <Actividades_finales> <actividad_final> <id_actividad_final> identificador de la actividad final </id_actividad_final> <nombre_actividad_final> nombre de la actividad final </nombre_actividad_final> </actividad_inicial> </Actividades finales> <Decisiones> <decision> <id_decision> identificador de decision </id_decision> <decision> descripción de la decision </decision> </decision> </Decisiones> <Sincronizacion_de_actividades> <sincronizacion> <id_sincronizacion> identificador de la sincronizacion </id_sincronizacion> </sincronizacion> </Sincronizacion_de_actividades> <Flujos_de_actividad> <flujos_A2A> <flujo_A2A> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la actividad </inicio_flujo> <fin_flujo> identificador de la actividad</fin_flujo>


55

Información de la estructura jerárquica C

</flujo_A2A> </flujos_A2A> <flujos_A2D> <flujo_A2D> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la actividad </inicio_flujo> <fin_flujo> identificador de la decision </fin_flujo> </flujo_A2D> </flujos_A2D> <flujos_D2A> <flujo_D2A> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la decisión </inicio_flujo> <fin_flujo> identificador de la actividad </fin_flujo> </flujo_D2A> </flujos_D2A> <flujos_A2S> <flujo_A2S> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la actividad </inicio_flujo> <fin_flujo> identificador de sincronización </fin_flujo> </flujo_A2S> </flujos_A2S> <flujos_S2A> <flujo_S2A> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la sincronización </inicio_flujo> <fin_flujo> identificador de la actividad </fin_flujo> </flujo_S2A> </flujos_S2A> <flujos_S2D> <flujo_S2D> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la sincronizacion </inicio_flujo> <fin_flujo> identificador de la decision </fin_flujo> </flujo_S2D> </flujos_S2D> <flujos_D2S> <flujo_D2S> <id_flujo> identificador del flujo </id_flujo> <inicio_flujo> identificador de la decision </inicio_flujo> <fin_flujo> identificador de la sincronizacion </fin_flujo> </flujo_D2S> </flujos_D2S> </Flujos_de_actividad>


56

5.3.4. Estructura jerárquica D La estructura jerárquica D (EJD), organiza la información proporcionada por cliente(s) y analista(s), la cual servirá para obtener diagramas de secuencias de UML. Esta información se describe en la tabla 5.10. La EJD se describe en la tabla 5.11.

Tabla 5.10. Información proporcionada por cliente(s) y analista(s), útil para diagramas de secuencias


Objetos del sistema Identifica objetos específicos del sistema. Incluyendo la clase de objetos de que se trata.

Colaboración entre objetos Identifica la interacción entre los objetos a través de envío de mensajes que incluyen datos y acciones.

Duración de objetos Identifica la duración que tiene un objeto en el sistema.

Tabla 5.11. Estructura jerárquica D

Información de la estructura jerárquica D <Objetos> <objeto> <id_objeto> identificador de un objeto </id_objeto> <nombre_objeto> nombre del objeto </nombre_objeto> <nombre_clase> nombre de la clase del objeto </nombre_clase> </objeto> </Objetos> <Mensajes> <mensaje> <id_mensaje> identificador del mensaje </id_mensaje> <mensaje> contenido del mensaje </mensaje> <id_objeto_fuente> identificador del objeto que emite el mensaje </id_objeto_fuente> <id_objeto_destino>identificador del objeto que recibe el mensaje </id_objeto_destino> </mensaje> </Mensajes> <Duracion_objetos> <duracion_objeto> <id_objeto>identificador de un objeto </id_objeto> <ultimo_mensaje> identificador del último mensaje del objeto </ultimo_mensaje> </duracion_objeto> </Duracion_objetos>


57

5.4. Conclusiones

En este capítulo se propone un procedimiento que describe el modelado de software en los niveles CIM y PIM, la forma en que se van construyendo los diagramas UML en cada nivel, a partir de la información proporcionada por cliente(s) y analista(s) del sistema. Es importante señalar que en los niveles CIM y PIM, es esencial la comunicación y la información que intercambian cliente(s) y analista(s) para lograr un proceso de modelado correcto. Por lo cual se propone también una estructura jerárquica basada en XML, para organizar esta información en forma sencilla de tal forma que facilite generar los diagramas UML.

58

Capítulo 6. Modelo de transformación en los niveles CIM y PIM

En este capítulo se propone un modelo de transformación en los niveles CIM y PIM, el cual consiste en un conjunto de transformaciones lineales18 para los diagramas UML descritos en la (§4). Cada transformación se describe en las secciones siguientes.

La transformación consiste en una función que consta de reglas de mapeo y operaciones entre diagramas UML.

La transformación, considera los elementos y características de cada diagrama UML (§4) y el procedimiento propuesto de modelado de software de los niveles CIM y PIM (§5.2).

18

Se refiere a la transformación entre el mismo tipo de diagrama. Por ejemplo: diagrama de casos de uso a

diagrama de casos de uso.


59

6.1. Conjunto de transformaciones

Se propone un conjunto de transformaciones lineales19 para los diagramas de casos de uso, diagramas de clases, diagramas de actividad y diagramas de secuencia, definidos en los niveles CIM y PIM, que se muestran en la figura 6.1 y en la ecuación (6.1). Las transformaciones propuestas consideran la información proveniente de cliente(s) y analista(s), en el formato propuesto en (§5.3).Para la representación de un diagrama UML, se utilizará la notación XMI.

(Ecuación 6.1) donde:

T= es un conjunto de transformaciones lineales t= es una transformación lineal

19

Se refiere a la transformación entre el mismo tipo de diagrama. Por ejemplo: diagrama de casos de uso a

diagrama de casos de uso.

CIM

Diagrama de

casos de uso

Diagrama de

clases

Diagrama de

actividad

Diagrama de

secuencia

PIM

Diagrama de

casos de uso

Diagrama de

clases

Diagrama de

actividad

Diagrama de

secuencia

Transformaciones T

Figura 6. 1. Modelo de transformación en los niveles CIM y PIM


60

Para realizar las transformaciones t , se propone la función de transformación f, la

cual consiste en un conjunto de reglas para convertir la información (I) en diagrama UML. Ver figura 6.2. y ecuación 6.2.

(Ecuación 6.2)

donde:

t = es una transformación lineal del diagrama (d) = es una función de transformación, expresada en un conjunto de reglas de

transformación. d = diagrama fuente. Que es el diagrama que se desea transformar. d’ = diagrama destino. Que es el diagrama obtenido después de la transformación, del

mismo tipo que d. I = es la información necesaria para la transformación. Es información proporcionada por

cliente(s) y analista(s).

6.2. Descripción de las transformaciones

En la tabla 6.1, se identifican los elementos de las transformaciones t, de acuerdo con la

ecuación (6.2).

Diagrama fuente

d

Diagrama destino

d’

Función de transformación

f

Información necesaria para la

transformación

I

Figura 6. 2. Función de transformación


61

Tabla 6. 1. Conjunto de transformaciones T

Transformación

t

Diagrama origen

d

Diagrama destino

d’

t1 Diagrama de casos de uso en el nivel CIM

Diagrama de casos de uso en el nivel CIM

t2 Diagrama de casos de uso en nivel CIM

Diagrama de casos de uso en el nivel PIM

t3 Diagrama de casos de uso en el nivel PIM

Diagrama de casos de uso en el nivel PIM

t4 Diagrama de clases en el nivel CIM

Diagrama de clases en el nivel CIM

t5 Diagrama de clases en el nivel CIM

Diagrama de clases en el nivel PIM

t6 Diagrama de clases en el nivel PIM

Diagrama de clases en el nivel PIM

t7 Diagrama de actividad en el nivel CIM

Diagrama de actividad en el nivel CIM

t8 Diagrama de actividad en el nivel CIM

Diagrama de actividad en el nivel PIM

t9 Diagrama de actividad en el nivel PIM

Diagrama de actividad en el nivel PIM

t10 Diagrama de secuencia en el nivel CIM

Diagrama de secuencia en el nivel CIM

t11 Diagrama de secuencia en el nivel CIM

Diagrama de secuencia en el nivel PIM

t12 Diagrama de secuencia en el nivel PIM

Diagrama de secuencia en el nivel PIM


62

6.3. Descripción de las funciones de transformación

Se proponen cuatro funciones de transformación de la forma f(d,I), en donde :

d = Es un diagrama UML en formato XMI. Que es el diagrama que se desea transformar.

I = Es la información proporcionada por cliente(s) y analista(s), la cual está en forma de estructura jerárquica, propuesta en §5.3. Esta información es necesaria para la transformación del diagrama.

Las funciones de transformación propuestas son:

f1 es la función de transformación para diagramas de casos de uso f2 es la función de transformación para diagramas de clases f3 es la función de transformación para diagramas de actividad f4 es la función de transformación para diagramas de secuencias

Cada función de transformación consta de:

Reglas de mapeo entre los elementos del diagrama (d) y los elementos de la estructura de información(I). M(X,Y) donde:

M: Mapeo X: Los elementos de la estructura de información(I). Y: Los elementos del diagrama (d).

Las operaciones básicas Agregar y Eliminar. Las cuales indican que deben agregarse o eliminarse elementos del diagrama (d), a partir de la información (I). Una vez aplicadas estas operaciones, el diagrama (d) se transforma en el diagrama (d’),

La tabla 6.2, muestra la descripción de la función de transformación para diagramas de casos de uso. La tabla 6.3, muestra la descripción de la función de transformación para diagramas de clases. La tabla 6.4, muestra la descripción de la función de transformación para diagramas de actividad. La tabla 6.5, muestra la descripción de la función de transformación para diagramas de secuencias.


63

Tabla 6.2. Función de transformación entre diagramas casos de uso

f1

función de transformación I

formato EJA (§5.3) d

diagrama de casos de uso formato XMI

Reglas del mapeo: Forma general M(X,Y)

Mapeo entre N y L

M (N,L ) Mapeo entre U y A

M(U,A) Mapeo entre R y C

M(R,C) Mapeo entre T y AC

M(T,AC) Mapeo entre S y CC

M(S,CC)

Operaciones: Agregar: Agregar elementos al diagrama. Eliminar: Eliminar elementos del diagrama.

Elementos X: N=nombre del sistema U= {Usuarios del sistema} R={requerimientos funcionales del sistema} T={ Usuarios por requerimiento funcional } S={relaciones entre requerimientos funcionales}

Etiquetas EJA de los elementos N = < nombre_sistema> U = <Usuario> R = <requerimiento> T = <usuario-req> S = <req-req>

Elementos Y: L=nombre del sistema A={actores} C={casos de uso} AC={relaciones actor-caso de uso} CC={relaciones caso de uso-caso de uso}

Etiquetas XMI de los elementos L = <uml:Package xmi:id=””name= “”> A = <uml:Actor xmi:id=”” name=”“> C = <uml:UseCase xmi:id=”” name=”” > AC = <uml:Association xmi:id=”” name=”” type=”Use”> CC = <uml:Association xmi:id=”” name=”” type=”Extend”/”Include”>

Tabla 6.3. Función de transformación entre diagramas de clases

f2


formato EJB (§5.3) d

diagrama de clases formato XMI


Mapeo entre E y C

M(E,C) Mapeo entre F y A

M(F,A) Mapeo entre G y M

M(G,M) Mapeo entre H y R

M(H,R)


Elementos X: E= {entidades del sistema} F={características de cada entidad} G={funciones de cada entidad} H={relaciones ente entidades}

Etiquetas EJB de los elementos E = <entidad> F = <caracteristica> G = <funcionalidad> H = <<relacion>

Elementos Y: C={clases} A={atributos de cada clase} M={métodos de cada clase} R={relaciones entre clases}

Etiquetas XMI de los elementos

C = <uml:Class xmi:id=”” name=””> A = <uml:Attribute xmi:id=”” name=””> M = <uml:Operation xmi:id=”” name=””> R = <uml:Association xmi:id=”” name=””>


64

Tabla 6.4. Función de transformación entre diagramas de actividad

f3


formato EJC (§5.3) d

diagrama de actividad formato XMI


Mapeo entre B y A

M(B,A) Mapeo entre C y NI

M(C,NI) Mapeo entre D y NF

M(D,NF) Mapeo entre E y F

M(E,F) Mapeo entre G y ND

M(G,ND) Mapeo entre H y S

M(H,S)


Elementos X: B= {actividades del proceso} C={actividad inicial del proceso} D={actividades finales del proceso} E={flujo de actividades} G={decisiones} H={sincronización de actividades}

Etiquetas EJC de los elementos B = <actividad> C = <Actividad_inicial> D = <actividad_final> E = <Flujos_de_actividad> G = <decision> H = <sincronizacion>

Elementos Y:

A={actividades} NI={nodo inicial} NF={nodos finales} F={flujos} ND={nodos de decision} S={sincronizaciones}

Etiquetas XMI de los elementos A = <uml:Activity xmi:id=”” name=””> NI = <uml:InitialNode xmi:id=”” name=””> NF = <uml:FinalNode xmi:idref=”” name=””> F = <uml:Association xmi:id=”” name=”” type=”ControlFlow” > ND=<uml:DecisionNode xmi:id=”” name=”” type=”Decision” > S = <uml:ForkNode xmi:id=”” > <uml:JoinNode xmi:id=””>


65

Tabla 6.5. Función de transformación entre diagramas de secuencia

f4


formato EJD (§5.3) d

diagrama de secuencia formato XMI


Mapeo entre E y O

M(E,O) Mapeo entre C y M

M(C,M)


Elementos X: E= {objetos} C={colaboración entre objetos}

Etiquetas EJD de los elementos E = <objeto> C = <mensaje>

Elementos Y:

O={objetos} M={mensajes}

Etiquetas XMI de los elementos O = <uml:Lifeline xmi:id=”” name=”” type=”Lifeline”> <uml:Lifeline xmi:id=”” name=”” type=”Entity”> M = <uml:Association xmi:id=”” type=”Message”>

6.4. Conclusiones

El modelo de transformación en los niveles CIM y PIM, que se propone en este capítulo, está descrito en reglas de mapeo y operaciones entre diagramas UML, las cuales permiten en forma sencilla obtener los elementos del diagrama UML a partir de la información de cliente(s) y analista(s).

La estructura general de la función de transformación, puede ser aplicada a otros tipos

de transformaciones diferentes a las propuestas en esta investigación.

66

Capítulo 7. Pruebas

En este capítulo, se presentan tres pruebas de transformación con diagramas de casos de uso, se muestra la creación del diagrama de casos de uso en el nivel CIM, a partir de la información proporcionada por clientes y/o analistas. Después se transforma el diagrama creado a otro diagrama en el mismo nivel CIM. Por último se muestra la transformación del diagrama obtenido en la transformación CIM a otro diagrama en el nivel PIM. Las dos últimas transformaciones CIM a CIM y CIM a PIM se apoyan utilizando información proporcionada por clientes y/o analistas.


67

Las pruebas se llevarán a cabo con las siguientes consideraciones:

1. Se utilizará la operación de transformación mostrada en la §6 (ecuación 6.2 ), de la forma , donde:

t = es una transformación lineal = es una función de transformación, expresada en un conjunto de reglas

de transformación. d = diagrama fuente. Que es el diagrama que se desea transformar. d’ = diagrama destino. Que es el diagrama obtenido después de la transformación. I = es la información proporcionada por cliente(s) y analista(s), la cual es necesaria para llevar a cabo la transformación.

2. Los diagramas (d,d’)se representarán utilizando formato XMI, sin embargo, para las pruebas, también se mostrarán sus correspondientes diagramas gráficos.

3. La información (I ), necesaria para la transformación, para efectos de estas

pruebas se representará en una estructura jerárquica propuesta en (§5.3), sin embargo, la adquisición y formato de esta información dependerá de la herramienta de transformación que se desarrolle en un futuro.

4. La función de transformación (f ), se llevará a cabo con las reglas de mapeo

propuestas en (§6)

7.1. Prueba de transformación de diagramas de casos de uso

A continuación se muestra la prueba de transformación t1, transformación entre diagramas de casos en el nivel CIM.

7.1.1. Creación del diagrama de casos de uso en el nivel CIM

Para la creación del diagrama de casos de uso, se obtiene la información de cliente(s) y/o analista(s), a través de alguna herramienta. En la tabla 7.1, se muestra dicha información en forma de la estructura jerárquica A (EJA) propuesta en §5.3.1.


68

Tabla 7.1. Información para proporcionada por cliente(s) y/o analista(s)

Información proporcionada por cliente(s) y/o analista(s)

<Sistema> <nombre_sistema> Invernadero </nombre_sistema> </Sistema> <Usuarios> <usuario> <id_usuario> U1 </id_usuario> <nombre_usuario> termometro </nombre_usuario> </usuario> <usuario> <id_usuario> U2 </id_usuario> <nombre_usuario> tarjeta </nombre_usuario> </usuario> <usuario> <id_usuario> U3 </id_usuario> <nombre_usuario> calefactor </nombre_usuario> </usuario> </Usuarios> <Requerimientos funcionales del sistema> <requerimiento> <id_req> R1 </id_req> <nombre_req> tomar lectura </nombre_req> </requerimiento> <requerimiento> <id_req> R2 </id_req> <nombre_req> controlar calefactor </nombre_req> </requerimiento> </Requerimientos funcionales del sistema>

A esta información (tabla 7.1) se le aplica una función de transformación, siguiendo las reglas de mapeo de la función f1 (§6.3), para crear el formato XMI del diagrama de casos de uso que muestra en la tabla 7.2. El diagrama en forma gráfica se muestra en la figura 7.1.


69

Tabla 7.2. Formato XMI del diagrama de casos de uso creado

<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id=”CasosUso”name= “Caso de Uso general”> <uml:Actor xmi:id=U1” name=”termometro“> </uml:Actor>

<uml:Actor xmi:id=U2” name=”tarjeta“> </uml:Actor>

<uml:Actor xmi:id=U3” name=”calefactor“> </uml:Actor> <uml:UseCase xmi:id=”R1” name=”tomar lectura” subject=”S1”> </uml:UseCase> <uml:UseCase xmi:id=”R2” name=” controlar calefactor” subject=”S1”> </uml:UseCase> <uml:Subject xmi:id=”S1” name=”Invernadero”> </uml:Subject> </uml:Package> </XMI.content> </xmi:XMI>


70

Figura 7.1. Diagrama de casos uso creado

7.1.2. Transformación de diagramas de casos de uso en el nivel CIM

Para la transformación de diagramas de casos de uso, nuevamente se obtiene la información de cliente(s) y/o analista(s), a través de alguna herramienta. En la tabla 7.3, se muestra dicha información en forma de estructura jerárquica A (EJA) propuesta en §5.3.1.



<Sistema> <nombre_sistema> Invernadero </nombre_sistema> </Sistema> <Usuarios> <usuario> <id_usuario> U1 </id_usuario> <nombre_usuario> termometro </nombre_usuario> </usuario> <usuario> <id_usuario> U2 </id_usuario> <nombre_usuario> tarjeta </nombre_usuario> </usuario>


71


<usuario> <id_usuario> U3 </id_usuario> <nombre_usuario> calefactor </nombre_usuario> </usuario> </Usuarios> <Requerimientos funcionales del sistema> <requerimiento> <id_req> R1 </id_req> <nombre_req> tomar lectura </nombre_req> </requerimiento> <requerimiento> <id_req> R2 </id_req> <nombre_req> controlar calefactor </nombre_req> </requerimiento> </Requerimientos funcionales del sistema> <Usuarios por requerimientos funcionales> <usuario-req> <id_usuario-req>T1 </id_usuario-req> <id_usuario>U1 </id_usuario> <id_req> R1 </id_req> </usuario-req> <usuario-req> <id_usuario-req>T2 </id_usuario-req> <id_usuario>U2 </id_usuario> <id_req> R2 </id_req> </usuario-req> <usuario-req> <id_usuario-req>T3 </id_usuario-req> <id_usuario>U3 </id_usuario> <id_req> R2 </id_req> </usuario-req> </Usuarios por requerimientos funcionales>

Se aplica la función de transformación, siguiendo las reglas de mapeo de la función

f1 (§6.3), para crear el formato XMI del diagrama de casos de uso que muestra en la tabla 7.4. El diagrama en forma gráfica se muestra en la figura 7.2.

Tabla 7.4. Formato XMI del diagrama de casos de uso transformado en el nivel CIM (diagrama destino)

<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header>


72

<XMI.content> <uml:Package xmi:id=”CasosUso”name= “Caso de Uso general”> <uml:Actor xmi:id=U1” name=”termometro“> <Association xmi:idref=”T1”/> </uml:Actor>

<uml:Actor xmi:id=U2” name=”tarjeta“> <Association xmi:idref=”T2”/> </uml:Actor>

<uml:Actor xmi:id=U3” name=”calefactor“> <Association xmi:idref=”T3”/> </uml:Actor> <uml:UseCase xmi:id=”R1” name=”tomar lectura” subject=”S1”> </uml:UseCase> <uml:UseCase xmi:id=”R2” name=” controlar calefactor” subject=”S1”> </uml:UseCase> <uml:Subject xmi:id=”S1” name=”Invernadero”> </uml:Subject> <uml:Association xmi:id=”T1” name=”” type=”Use”> <Source xmi:idref=”U1”/> <Target xmi:idref=”R1”/> </uml:Association> <uml:Association xmi:id=”T2” name=”” type=”Use”> <Source xmi:idref=”U2”/> <Target xmi:idref=”R2”/> </uml:Association> <uml:Association xmi:id=”T3” name=”” type=”Use”> <Source xmi:idref=”U3”/> <Target xmi:idref=”R2”/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>


73

Figura 7.2. Diagrama de casos de uso transformado en el nivel CIM (diagrama destino)

7.1.3. Transformación de diagramas de casos de uso del nivel CIM al nivel PIM

Para la transformación de diagramas de casos de uso, nuevamente se obtiene la información de cliente(s) y/o analista(s), a través de alguna herramienta. En la tabla 7.5 se muestra dicha información en forma de estructura jerárquica A (EJA) propuesta en §5.3.1.


<Sistema> <nombre_sistema> Invernadero </nombre_sistema> </Sistema> <Usuarios> <usuario> <id_usuario> U1 </id_usuario> <nombre_usuario> termometro </nombre_usuario> </usuario> <usuario> <id_usuario> U2 </id_usuario> <nombre_usuario> tarjeta </nombre_usuario> </usuario> <usuario> <id_usuario> U3 </id_usuario> <nombre_usuario> calefactor </nombre_usuario> </usuario>


74

</Usuarios> <Requerimientos funcionales del sistema> <requerimiento> <id_req> R1 </id_req> <nombre_req> tomar lectura </nombre_req> </requerimiento> <requerimiento> <id_req> R2 </id_req> <nombre_req> controlar calefactor </nombre_req> </requerimiento> <requerimiento> <id_req> R3 </id_req> <nombre_req> encender calefactor </nombre_req> </requerimiento> <requerimiento> <id_req> R4 </id_req> <nombre_req> apagar calefactor </nombre_req> </requerimiento> </Requerimientos funcionales del sistema> <Usuarios por requerimientos funcionales> <usuario-req> <id_usuario-req>T1 </id_usuario-req> <id_usuario>U1 </id_usuario> <id_req> R1 </id_req> </usuario-req> <usuario-req> <id_usuario-req>T2 </id_usuario-req> <id_usuario>U2 </id_usuario> <id_req> R2 </id_req> </usuario-req> <usuario-req> <id_usuario-req>T3 </id_usuario-req> <id_usuario>U3 </id_usuario> <id_req> R2 </id_req> </usuario-req> </Usuarios por requerimientos funcionales> <Relaciones_entre_requerimientos> <req-req> <id_req-req>S1 </id_req-req> <id_req_fuente> R2 </id_req_fuente> <id_req_destino> R3 </id_req_destino> <tipo_relacion> incluye </tipo_relacion> </req-req> <req-req> <id_req-req>S2 </id_req-req> <id_req_fuente> R2 </id_req_fuente> <id_req_destino> R4 </id_req_destino> <tipo_relacion> incluye </tipo_relacion> </req-req> </Relaciones_entre_requerimientos>


75

Se aplica la función de transformación, siguiendo las reglas de mapeo de la función f1 (§6.3), para crear el formato XMI del diagrama de casos de uso que muestra en la tabla 7.6. El diagrama en forma gráfica se muestra en la figura 7.3.

Tabla 7.6. Formato XMI del diagrama de casos de uso transformado en el nivel PIM (diagrama destino)

<?xml version="1.0"?><!DOCTYPE xmi:XMI SYSTEM "DTDCasosUso.dtd"> <xmi:XMI xmi:version="2.0" xmlns:uml="http://schema.omg.org/spec/uml/2.0" xmlns:xmi="http://schema.omg.org/spec/XMI"> <XMI.header> <XMI.model xmi.name="UML" xmi.version="2.0"/> </XMI.header> <XMI.content> <uml:Package xmi:id=”CasosUso”name= “Caso de Uso general”> <uml:Actor xmi:id=U1” name=”termometro“> <Association xmi:idref=”T1”/> </uml:Actor>

<uml:Actor xmi:id=U2” name=”tarjeta“> <Association xmi:idref=”T2”/> </uml:Actor>

<uml:Actor xmi:id=U3” name=”calefactor“> <Association xmi:idref=”T3”/> </uml:Actor> <uml:UseCase xmi:id=”R1” name=”tomar lectura” subject=”S1”> </uml:UseCase> <uml:UseCase xmi:id=”R2” name=”controlar calefactor” subject=”S1”> </uml:UseCase> <uml:UseCase xmi:id=”R3” name=”encender calefactor” subject=”S1”> </uml:UseCase> <uml:UseCase xmi:id=”R4” name=”apagar calefactor” subject=”S1”> </uml:UseCase> <uml:Subject xmi:id=”S1” name=”Invernadero”> </uml:Subject> <uml:Association xmi:id=”T1” name=”” type=”Use”> <Source xmi:idref=”U1”/> <Target xmi:idref=”R1”/> </uml:Association> <uml:Association xmi:id=”T2” name=”” type=”Use”> <Source xmi:idref=”U2”/> <Target xmi:idref=”R2”/> </uml:Association> <uml:Association xmi:id=”T3” name=”” type=”Use”> <Source xmi:idref=”U3”/> <Target xmi:idref=”R2”/> </uml:Association> <uml:Association xmi:id=”S1” name=”” type=”Include”> <Source xmi:idref=”R2”/> <Target xmi:idref=”R3”/> </uml:Association> <uml:Association xmi:id=”S2” name=”” type=”Include”>


76

<Source xmi:idref=”R2”/> <Target xmi:idref=”R4”/> </uml:Association> </uml:Package> </XMI.content> </xmi:XMI>

Figura 7.3. Diagrama de casos de uso transformado en el nivel PIM (diagrama destino)

7.2. Conclusiones

Las pruebas realizadas en este capítulo, se llevaron a cabo para las transformaciones de diagramas de casos de uso en los niveles CIM y PIM. Se utilizaron las reglas de mapeo y operaciones propuestas en esta investigación, la información proporcionada por clientes y analistas de acuerdo con el formato de estructura jerárquica propuesto también este trabajo. Las pruebas se consideran exitosas ya que se logró obtener el diagrama UML correspondiente en formato XMI.

77

Capítulo 8. Conclusiones

En la actualidad, un enfoque muy aceptado en la comunidad de desarrollo de software, es utilizar los diagramas UML de acuerdo a los niveles de abstracción propuestos en MDA, para modelar el desarrollo de software. Existen herramientas para el diseño de modelos y la transformación entre ellos de forma automática. Sin embargo, no se conocen las especificaciones de las operaciones de transformación que realizan. En este contexto, se realizó esta investigación, con el objetivo de determinar cuáles son las operaciones elementales (incluyendo operadores, operandos y reglas) para realizar la transformación de modelos en los niveles CIM a PIM.

Muchos de los autores consultados, proponen sólo el uso de los diagramas de casos de uso y sus escenarios, para el modelado en el nivel CIM y otros diagramas para el nivel PIM. Otros proponen el uso del modelo de negocios en el nivel CIM.


78

En esta investigación se propone modelar los niveles CIM y PIM sólo con UML, trabajando con los diagramas de casos uso, diagramas de clases, diagramas de actividad y diagramas de secuencia, en ambos niveles, con lo cual se propone abarcar más elementos relevantes en el proceso de software.

A continuación se describen los resultados obtenidos en esta investigación y trabajos futuros.

8.1. Resultados

Los resultados de esta investigación son:

Un modelo de transformación en los niveles CIM y PIM (§6). Este modelo consiste en un conjunto de transformaciones lineales para los diagramas UML. Cada transformación incluye:

Una función de transformación, que consta de reglas de mapeo y operaciones entre diagramas UML.

La estructura general de la función de transformación, puede ser aplicada a otros tipos

de transformaciones diferentes a las transformaciones propuestas en esta investigación. Otros resultados son:




Los resultados de esta tesis, aportan elementos para continuar la construcción de

la Herramienta de transformación de modelo a modelo, para el ambiente AGDE [González-García 2006], que actualmente se desarrolla en el CENIDET.


79

8.2. Trabajos futuros

Es posible identificar áreas de oportunidad para futuras investigaciones tales como:

Funciones de transformación lineal para otros diagramas en los niveles CIM y PIM.

Funciones de transformación entre diferentes tipos de diagramas en los niveles MDA.

Definición de otras operaciones de transformación.

Implementación de la Herramienta de transformación de modelo a modelo, para el ambiente AGDE, que permita la creación y transformación automática de diagramas. Que incluya la interfaz para clientes y analistas.

80

Anexos

Anexo A. “Caracterización de las fronteras de los Modelos MDA” [López 2007]

En la figura A.1, se muestra un esquema de la definición de los modelos (CIM, PIM, PSM e IM) MDA y de sus fronteras (CIM a PIM, PIM a PSM y PSM a IM).

Se muestra cada una de las fronteras mediante una flecha de herencia, pues el modelo PIM esta heredando la información definida en el modelo CIM; el modelo PSM esta heredando la información del modelo PIM y del modelo más abstracto CIM y el modelo IM esta heredando la información del modelo PSM y por consecuencia hereda también información del modelo PIM y del modelo CIM.

En la figura A.1:

La documentación estructurada se refiere a la documentación de cada una de las fronteras de forma organizada para su mejor entendimiento y presentación, con el fin de servir de referencia a los diagramas en el modelo que les corresponda.

La documentación permanente (XML/XMI), es la representación almacenable de los diagramas UML y que se utiliza como fuente de los elementos a transformar de un diagrama y como destino de las transformaciones realizadas para obtener el diagrama objetivo.

Ambos tipos de documentación son utilizadas para procesar los modelos y refinar

la información contenida en ellos. A medida que se recorre cada una de las fronteras se realiza una especialización en

cada uno de los modelos, ya que van de lo abstracto a lo específico. Cada frontera especifica los elementos y características necesarias y suficientes

para un modelo antes de cruzar la frontera correspondiente (CIM a PIM, PIM a PSM, PSM a IM).

La frontera es la base para transformar un modelo al siguiente nivel, agregando mayor detalle (refinación) para un nivel menos abstracto.

Anexos

81

Figura A. 1. Representación visual de la definición de los modelos y de las fronteras de los modelos MDA

al modelo de implementación [López 2007]

A continuación se detallan los modelos CIM y PIM.

Representación del modelo CIM

El Modelo CIM está constituido por el modelo del negocio en su modelo funcional y no funcional, así como una generación de modelos de dominio que se utilizan como base para los modelos funcional y no funcional. Todos los modelos dentro de CIM, son el punto inicial para la comprensión de los que el cliente quiere y de cuál es su contexto. Ver figura A.2.

Anexos

82

Figura A. 2. Representación visual de la definición del modelo CIM [López 2007]

El modelo del negocio describe las funciones y los procesos que componen el negocio y las relaciones del mismo con procesos eternos. Los procesos del negocio describen cómo se realiza el trabajo en la empresa y se caracterizan por ser observables, medibles, mejorables y repetitivos. Este modelo contiene:

Reglas del negocio

Objetivos y metas del negocio

Definición de la estrategia del negocio

Funciones del negocio

Procesos del negocio (entradas, salidas, roles, actividades, entidades, atributos y relaciones).

El modelo del dominio ayuda a capturar las entidades y acontecimientos asociados

con el área (dominio), el cual contiene los términos básicos (entidades, acciones, actores y otros) y sus relaciones en correspondencia a su contexto.

La información del modelo de dominio, se obtendrá en general de los expertos del dominio (mediante entrevistas) o mediante el modelado de los involucrados y sus procesos, permitiendo una mejor comprensión del problema que se quiere resolver en relación a su contexto. Este modelo contiene:

Glosario, define los términos utilizados y las clases de los objetos y sus atributos relevantes.

Contenido de relaciones entre objetos.

Requerimientos funcionales.

Requerimientos no funcionales.

Mejoras prácticas.

Anexos

83

Modelo funcional. Se refiere a las operaciones que transforman de entradas a salidas en cada actividad de los procesos involucrados y en última instancia a las salidas de una aplicación computacional hacia su ambiente, ya sea dentro de un dominio o hacia entidades externas al negocio. Debe contener:

Identificación del proceso.

Identificación de actores y clases potenciales.

Identificación de escenarios.

Identificación de casos de uso.

Identificaciones de las relaciones entre casos de uso.

El Modelo no funcional se refiere a los requerimientos que describen características relacionadas a una aplicación computacional (entradas, salidas, procedimientos, actores y recursos) que no tienen que ver con su funcionalidad y algunas características pueden ser visibles para el usuario. Un requerimiento no funcional impone restricciones sobre un requerimiento funcional, pero también describe atributos, restricciones, consideraciones de funcionamiento, diseño, calidad, consideraciones de ambiente, de fracaso y recuperación, este modelo contiene:

Interfaces externas o Interfaces de usuario o Interfaces de hardware o Interfaces de software o Interfaces de comunicación.

Requisitos de rendimiento o Estáticos o Dinámicos

Atributos de software o Disponibilidad o Factores de calidad [ISO91]

Restricciones de diseño.

Representación del modelo PIM

El Modelo PIM se encuentra integrado por modelos de análisis y de diseño, los cuales son modelos independientes de plataforma que representan información y datos específicos desde el punto de vista computacional, sin mostrar los detalles de su uso en una plataforma o tecnología. En la figura A.3 se debe interpretar que el modelo PIM hereda del modelo CIM todos sus elementos y estructura. Para obtener el modelo PIM se toma como entrada principal un subconjunto de los elementos del modelo CIM y se añaden detalles para completar el diseño en modelo PIM. Los elementos del modelo PIM son:

Anexos

84

Modelo de análisis. Parte de la información de éste modelo se obtiene de un subconjunto de elementos del modelo CIM, agregando la especialización de dichos elementos. El modelo de análisis junto con los requerimientos no funcionales, se usan para preparar la arquitectura del sistema que se desarrolla durante el diseño. Este modelo contiene:

Refinamiento y estructuración de los elementos obtenidos del modelo CIM.

Flujo de datos.

Flujo de control. Modelo de Diseño. Este modelo se refiere a detalles de diseño independientes de la plataforma. Aquí se especifica información que es necesaria para desarrollar una aplicación computacional pero sin utilizar ningún lenguaje de programación para hacerlo. El modelo de diseño consta de:

Arquitectura del sistema.

Modelo de clases.

Estilo arquitectónico.

Modelo Lógico.

Modelo de especificaciones. Definición de la frontera CIM-PIM. En la figura A.3 se muestran los niveles CIM y PIM con sus respectivos modelos y diagramas, donde la especificación de máximo detalle del modelo CIM, y el mínimo del modelo PIM representa la frontera CIM-PIM. Se muestran los diagramas de ambos niveles, así como las transformaciones que pueden existir entre ambos. Además las transformaciones que se tienen que realizar para obtener el nivel PIM a partir del CIM se ilustran con líneas.

Figura A. 3. Frontera CIM-PIM en base a diagramas y sus transformaciones [López 2007]

85

Referencias

[Amaya 2002] Pablo Amaya, Carlos González, Juan M. Murillo. 2002. “Separación de Aspectos en MDA: Una aproximación basada en múltiples vistas”. Universidad de Extremadura,España, <Amayawww.dsic.upv.es/workshops/dsdm04/files/02-Amaya.pdf>. Visitada el 20 de agosto.

[Bollati 2007] Bollati Verónica, Vara Juan M., Vela Belén, Marcos Esperanza,

2007, "Una revisión de herramientas MDA", Universidad Rey Juan Carlos. <http://www.sistedes.es/sistedes/pdf/2007/dsdm-07-bollati-revisionHerramientas.pdf>. Visitada en agosto de 2009.

[Booch 2006] Booch Grady, Rumbaugh James, Jacobson Ivar. 2006. “El

lenguaje unificado de modelado”, 2ª. Ed. Pearson Educación, S. A., Madrid, España. ISBN 10: 84-7829-076-1, ISBN 13:978-84-7829-076-5.

[Dosi 1988] Dosi Giovanni. 1988. “Sources, Procedures and Microeconomic Effects of Innovation”.Journal of Economic Literature. Vol XXVI. September 1988, pp. 1120-1171.

[DTD] Definición de tipo de documento. Página de Wikipedia.

<http://es.wikipedia.org/wiki/Definición_de_tipo_de_documento> . Visitada el 12 de marzo de 2010.

[Eclipse 2009] Página oficial de Eclipse. <http://www.eclipse.org/>. Visitada en

agosto de 2009. [Eriksson 2000] Eriksson Hans-Erik, Penker Magnus. 2000. “UML. Business

Patterns at Work”, Wiley Computer Publishing, John Wiley&Sons, Inc., ISBN-0-471-29551-5, pp. 460.

[Estrada 2002] ESTRADA E. Hugo, MARTÍNEZ R. Alicia, PASTOR L. Oscar, “El

Modelo de negocios como origen de especificaciones de requisitos de software: una aproximación metodológica”. <http://www.dsic.upv.es/~alimartin/Publications_archivos/Ciicc2002.pdf>. Visitada el 10 de junio de 2008.

[Fowler 1999] Fowler Martin, Scott Kendall. 1999. “UML gota a gota”,

Addison Wesley, S. A. de C.V. México.

http://www.sistedes.es/sistedes/pdf/2007/dsdm-07-bollati-revisionHerramientas.pdf

http://www.sistedes.es/sistedes/pdf/2007/dsdm-07-bollati-revisionHerramientas.pdf

http://es.wikipedia.org/wiki/Definición_de_tipo_de_documento

http://es.wikipedia.org/wiki/Definición_de_tipo_de_documento

Referencias

86

[Giandini 2006] GIANDINI Roxana S., PONS Claudia F. “Un lenguaje para

Transformación de Modelos basado en MOF y OCL”. Universidad Nacional de La Plata, Facultad de Informática L I F I A - Laboratorio de Investigación y Formación en Informática Avanzada La Plata, Argentina. Disponible en <http://www.lifia.info.unlp.edu.ar/papers/2006/Giandini2006.pdf>

[González-García 2006] GONZÁLEZ-García Moisés, 2006, Tesis Doctoral: “Método de

Desarrollo Arquitectónico en Grupo”, Centro de Investigaciones y Estudios Avanzados del Instituto Politécnico Nacional.

[Hendryx 2000] Página oficial Hendryx & Associates.

<http://www.hendryxassoc.com/>. Visitada en junio de 2009. [Hendryx 2003] Hendryx Stan. 2003. “Architecture of Business Modeling”,

<http://www.hendryxassoc.com/pdf/Architecture%20of%20Business%20Modeling%2003-11-01.pdf>. Visitada en junio de 2009.

[Hendryx 2003a] Hendryx Stan. 2003. “Integrating Computation Independent

Business Modeling Languages into the MDA with UML 2“, <www.omg.org/docs_ad_03-01-32.pdf>. Visitada en junio de 2009.

[López 2007] López López Edna Daniela. 2007. Tesis de Maestría:

Caracterización de las Fronteras de los Modelos MDA Mediante UML”. Centro Nacional de Investigación y Desarrollo Tecnológico. Cuernavaca, Morelos, México.

[Miller 2003] MILLER Joaquín, MUKERJI Jishnu. 2003. “MDA Guide Version

1.0.1 Copyright © 2003 OMG”, Document Number: omg/2003-06-01, Date: 12th June 2003. <http://www.omg.org/docs/omg/03-06-01.pdf>. Visitada el 30 de junio de 2008.

[Pressman 2002] Pressman Roger S., 2002, “Ingeniería del software un enfoque

práctico”, quinta Edición, Mc Graw Hill, Madrid España.

http://www.lifia.info.unlp.edu.ar/papers/2006/Giandini2006.pdf







http://www.hendryxassoc.com/

Referencias

87

[Quatrani 2009] Quatrani Terry, ‘Writing Good Use Cases’, Rational Software IBM. <www.dama-nj.org/presentations/TQ%20Writing%20Good%20Use%20Cases.pdf>. Visitado el 23 de marzo de 2009.

[Quintero 2007] Quintero, Juan Bernardo. Anaya, Raquel. 2007. “MDA y el papel

de los modelos en el proceso de desarrollo de software”, Revista EIA, ISSN 1794-1237. Número 8, pp. 131-146. Diciembre 2007. Escuela de Ingeniería de Antioquía, Medellín, Colombia.

[Rodríguez 2006] Rodríguez Alfonso, Fernández-Medina Eduardo, Piattini Mario,

2006, "Hacia la obtención de clases de análisis y casos de uso desde modelos de procesos de negocio", http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/calidad.produccion/Clases.de.Analisis.desde.modelos.proc.negocios.pdf

[Rosen 2004] Rosen Kenneth H. 2004. “Matemática discreta y sus aplicaciones”. 5ª. Ed. Ed. Mc Graw Hill/INTERAMERICA DE ESPAÑA. ISBN: 0-07-242434-6

[UML 2005] UML. 2005. “Introduction to OMG's, Unified Modeling

Language™ (UML®)”. Updated July 2005 to reflect formal adoption of UML 2.0 Superstructure. , <http://www.omg.org/gettingstarted/what_is_uml.htm> consultada el 10 junio de 2008.

[XML1] XML. Página Wikipedia. <http://es.wikipedia.org/wiki/XML>. Visitada el 12 de marzo de 2010.

[XML2] XML. W3C World Wide Web Consortium. Oficina española. <http://www.w3c.es/divulgacion/guiasbreves/tecnologiasxml>.Visitada el 13 de marzo de 2010.

[XML3] XML. W3C World Wide Web Consortium. Página oficial. <http://www.w3.org/XML/1999/XML-in-10-points.es.html>. Visitada 13 de marzo de 2010.

http://www.eici.ucm.cl/Academicos/R_Villarroel/descargas/calidad.produccion/Clases.de.Analisis.desde.modelos.proc.negocios.pdf



http://www.omg.org/gettingstarted/what_is_uml.htm

TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA … · 2014-02-13 · Garcia 2006]. In this...

Documents

Transcript of TESIS DE MAESTRÍA EN CIENCIAS EN CIENCIAS DE LA … · 2014-02-13 · Garcia 2006]. In this...