Universidad Politécnica de Valencia

Manuela Albert Albiol

Tratamiento de Relaciones de Asociación en Entornos de Producción Automática de

Código

Borrador de Tesis Doctoral

Dirigida por: Dr. Vicente Pelechano Ferragud y

Dr. Oscar Pastor López

ii

Índice General .

Introducción...........................................................................................- 1 - 1.1. Introducción ..................................................................................- 1 -

1.1.1 Contexto Tecnológico .......................................................................... - 2 - 1.2. Motivación .....................................................................................- 4 - 1.3. Objetivos.......................................................................................- 6 - 1.4. Metodología de Trabajo ...................................................................- 8 -

1.4.1. Definición del Modelo Conceptual ............................................................ - 8 - 1.4.2. Construcción del Framework .................................................................. - 9 -

1.5. Estructura de la Tesis .................................................................... - 10 -

Estado del Arte .....................................................................................- 13 - 2.1. Introducción ................................................................................ - 13 - 2.2. Desarrollo Dirigido por Modelos ...................................................... - 14 -

2.2.1. Métodos y Herramientas...................................................................... - 14 - 2.2.1.1. CASE iUML ...................................................................................................- 14 - 2.2.1.2. OBLOG CASE ................................................................................................- 15 - 2.2.1.3. BridgePoint ..................................................................................................- 15 - 2.2.1.4. OptimalJ ......................................................................................................- 15 - 2.2.1.5. CodaGen Architect ........................................................................................- 16 - 2.2.1.6. ArcStyler......................................................................................................- 16 - 2.2.1.7. Diferencias Respecto a OO-Method..................................................................- 17 -

2.2.2. Transformaciones de Modelo a Modelo................................................... - 18 - 2.2.2.1. MTF (Model Transformation Framework) ..........................................................- 18 - 2.2.2.2. ATL (Atlas Transformation Language) ..............................................................- 18 - 2.2.2.3. QVT (Query, Views and Tranformations) ..........................................................- 19 - 2.2.2.4. Gramáticas de Grafos y AGG ..........................................................................- 19 -

2.2.3. Transformaciones de Modelo a Texto ..................................................... - 20 - 2.2.3.1. XSLT ...........................................................................................................- 20 - 2.2.3.2. Motores de Plantillas......................................................................................- 20 - 2.2.3.3. MOFScript ....................................................................................................- 21 -

2.3. La Asociación en el Espacio del Problema ......................................... - 22 - 2.3.1. Lenguajes y Metodologías de Modelado Conceptual OO ............................ - 22 -

2.3.1.1. Catalysis. .....................................................................................................- 22 - 2.3.1.2. Syntropy......................................................................................................- 22 - 2.3.1.3. UML. ...........................................................................................................- 23 - 2.3.1.4. OML. ...........................................................................................................- 26 -

2.3.2. Otros Estudios de la Asociación............................................................. - 27 - 2.3.3. Particularidades de la Propuesta de la Tesis............................................ - 35 -

2.4. La Asociación en el Espacio de la Solución ........................................ - 35 - 2.4.1. Técnicas de Implementación ................................................................ - 36 -

2.4.1.1. Referencias ..................................................................................................- 36 - 2.4.1.2. Objetos Relación ...........................................................................................- 36 - 2.4.1.3. Primitivas Empotradas ...................................................................................- 37 - 2.4.1.4. Clases Parametrizadas ...................................................................................- 37 - 2.4.1.5. Metaclases ...................................................................................................- 37 - 2.4.1.6. Análisis de las Técnicas de Implementación ......................................................- 38 -

2.4.2. Patrones de Diseño............................................................................. - 39 - 2.5. Conclusiones................................................................................ - 41 -

Un Marco Conceptual para el Modelado de la Asociación .......................... 42 3.1. Introducción .................................................................................... 42 3.2. Identificación de Propiedades ............................................................. 43 3.3. Categorización de Propiedades ........................................................... 44

iii

3.4. Selección de Propiedades................................................................... 45 3.4.1. Criterios de Calidad .................................................................................46 3.4.2. Propiedades de Restricción de Cardinalidad .................................................49 3.4.3. Propiedades Dinámicas.............................................................................50

3.4.3.1. Creación, Destrucción y Modificación de Enlaces ................................................... 51 3.4.3.2. Dependencias entre ciclos de vida. ...................................................................... 55

3.4.4. Propiedades de Restricción de Enlaces ........................................................59 3.4.5. Propiedades de Accesibilidad .....................................................................62 3.4.6. Mecanismos de Identificación ....................................................................65 3.4.7. Propiedades Estructurales.........................................................................66

3.5. Definición del Marco Conceptual.......................................................... 67 3.5.1. Formalización de las Propiedades ...............................................................68 3.5.2. Dinamicidad............................................................................................69 3.5.3. Mutabilidad.............................................................................................70 3.5.4. Multiplicidad ...........................................................................................71 3.5.5. Propagación de Borrado............................................................................71 3.5.6. Navegabilidad .........................................................................................72 3.5.7. Proyección de Identificación ......................................................................72 3.5.8. Reflexividad............................................................................................73 3.5.9. Simetría.................................................................................................73 3.5.10. Transitividad .........................................................................................74 3.5.11 Dependencias entre las Propiedades del Marco............................................74

3.6. Conclusiones.................................................................................... 77

Un Modelo para las Asociaciones .............................................................. 78 4.1. Introducción .................................................................................... 78 4.2. Definición de Asociación..................................................................... 79

4.2.1. Comportamiento de la Asociación ..............................................................80 4.2.2. Clase Asociación......................................................................................82

4.3. Caracterización de las Asociaciones ..................................................... 82 4.3.1. Interpretación de los Conceptos Asociación, Agregación y Composición. ..........83

4.4. Metamodelo ..................................................................................... 85 4.4.1 Metaclase Asociación...............................................................................87 4.4.2. Metaclase AsociaciónReflexiva ...................................................................89 4.4.3. Metaclase ExtremoAsociación ..................................................................90 4.4.4. Instanciación del Metamodelo. Ejemplos. ....................................................96

4.5. Definición de un Perfil UML................................................................100 4.5.1. Los Perfiles UML ....................................................................................100

4.5.1.1. Ejemplo de Perfil............................................................................................. 101 4.5.2. Definición de un Perfil UML para la Asociación............................................101

4.5.2.1. Extensiones al Metamodelo UML ....................................................................... 101 4.5.2.2. Estereotipos ................................................................................................... 104 4.5.2.3. Restricciones .................................................................................................. 105

4.6. Diseño de un Ayudante para el Modelado de Asociaciones......................108 4.6.1. Descripción del Ayudante........................................................................109

4.6.1.1. Pasos del Ayudante ........................................................................................ 112 4.6.2. Formulación de Preguntas.......................................................................113 4.6.3. Características Técnicas..........................................................................115

4.6.3.1. Conexión Rational Rose y Ayudante ................................................................ 117 4.7. Conclusiones...................................................................................118

Generación de Código............................................................................. 120 5.1. Contexto ........................................................................................120

5.1.1. Arquitectura de las aplicaciones generadas................................................122 5.2. Definición del Framework..................................................................123

5.2.1. Factores de Calidad ...............................................................................123

iv

5.2.2. Selección de Patrones de Diseño..............................................................124 5.2.2.1. Patrón Mediador (“Mediator”) ............................................................................ 124 5.2.2.2. Patrón Decorador (“Decorator”).......................................................................... 125 5.2.2.3. Patrón Método Plantilla (“Template Method”)........................................................ 126

5.2.3. Estructura del Framework.......................................................................127 5.3. Definición de Correspondencias. Instanciación del Framework ................130

5.3.1. Vista Estructural....................................................................................131 5.3.1.1. Correspondencia entre los Elementos de la Asociación y las Clases de Diseño ........ 131 5.3.1.2. Correspondencia entre las Propiedades Estructurales y Atributos y Métodos de Diseño................................................................................................................................. 138

5.3.2. Vista Funcional......................................................................................141 5.3.2.1. Correspondencia entre Propiedades de la Asociación y Métodos de Diseño.............. 142

5.3.3. Implementación de Correspondencias.......................................................146 5.4. Implementación de Métodos..............................................................147

5.4.1. Estrategia de Implementación .................................................................147 5.4.2. Estructura de Presentación .....................................................................148 5.4.3. Creación de Enlaces. ..............................................................................149

5.4.3.1. Método insertar de las clases Decoradoras Concretas ........................................ 152 5.4.3.2. Método Constructor de la clase Mediadora Abstracta............................................ 154 5.4.3.3. Método conectar_enlace de la clase Decoradora Abstracta. ................................ 156 5.4.3.4. Métodos Complementarios en la Creación de Enlaces........................................... 158

5.4.4. Destrucción de Enlaces...........................................................................164 5.4.4.1. Método borrar de las clases Decoradoras Concretas. .......................................... 167 5.4.4.2. Método destructor de la clase Mediadora Abstracta.............................................. 168 5.4.4.3. Método desconectar_enlace de la clase Decoradora Abstracta. ........................... 169 5.4.4.4. Métodos Complementarios en la Destrucción de Enlaces ...................................... 171

5.4.5. Modificación de Enlaces. .........................................................................175 5.4.5.1. Método modificar de las clases Decoradoras Concretas. ..................................... 179 5.4.5.2. Método actualizar de la clase Mediadora Abstracta. .......................................... 180

5.4.6. Creación de Objetos Participantes. ...........................................................183 5.4.6.1. Método constructor de las clases Decoradoras Abstractas..................................... 184 5.4.6.2. Método constructor de las clases Decoradoras Concretas. .................................... 184 5.4.6.3. Método constructor de las clases Participantes .................................................... 188 5.4.6.4. Métodos Complementarios en la Creación de Objetos .......................................... 188

5.4.7. Destrucción de Objetos Participantes........................................................189 5.4.7.1. Método destructor de las clases Decoradoras Abstractas ...................................... 189 5.4.7.2. Método destructor de las clases Participantes ..................................................... 190 5.4.7.3. Método Complementario en la Destrucción de Objetos ......................................... 191

5.4.8. Uso de las Clases del Framework .............................................................192 5.5. Nivel de Persistencia ........................................................................193

5.5.1. Correspondencia entre asociaciones binarias y tablas..................................193 5.6. Nivel de Presentación .......................................................................197

5.6.1. Asociaciones en el Nivel de Presentación...................................................197 5.6.1.1. Recuperación de Información............................................................................ 197 5.6.1.2. Introducción de Datos en la Creación de Enlaces................................................. 203 5.6.1.3. Introducción de Datos en la Modificación de Enlaces ............................................ 205 5.6.1.4. Introducción de Datos en el Borrado de Enlaces .................................................. 206 5.6.1.5. Introducción de Datos en la Creación de Objetos Asociados.................................. 208

5.6.2. Un Modelo de Presentación .....................................................................210 5.6.3. Aplicaciones Web...................................................................................211

5.6.3.1. La Aproximación Metodológica OOWS ................................................................ 211 5.6.3.2. Extracción de Conocimiento de la Especificación de una Asociación........................ 214

5.7. Conclusiones...................................................................................220

Conclusiones y Trabajo Futuro................................................................ 221 6.1. Contribuciones ................................................................................221 6.2. Trabajo Futuro ................................................................................224 6.3. Publicaciones ..................................................................................225

Ejemplo de Modelado y Generación de Código ........................................ 227

v

A.1. Descripción.....................................................................................227 A.2. Estructura de Clases Generada ..........................................................228 A.3. Código Generado.............................................................................230

Implementación de Transformaciones utilizando el Lenguaje MOFScript 263 B.1. Contexto ........................................................................................263 B.2. Particularidades del Lenguaje MOFScript .............................................266 B.3. Implementación de la Transformación ................................................267

- 1 -

Capítulo 1 Introducción

En un sistema de información, las relaciones entre los elementos que lo constituyen son de vital importancia para el cumplimiento del cometido de éste. Las relaciones se encargan de la integración de los componentes dentro del sistema. Al trasladar estas relaciones a los modelos que representan de forma abstracta un sistema, surgen cuestiones complejas respecto a las propiedades y naturaleza de éstas. El papel que juegan los modelos dentro de los procesos de desarrollo de software actuales, como el Desarrollo Dirigido por Modelos o las Factorías de Software, requiere la definición precisa de las abstracciones de modelado. Sólo de esta manera, es posible completar con éxito el proceso de desarrollo del software. En esta tesis se estudian las relaciones de asociación a nivel conceptual y a nivel de diseño, proponiendo un modelo para las asociaciones y un framework para su implementación. A partir del modelo y del framework se definen las correspondencias que permiten llevar a cabo la transformación de un modelo de asociación concreto en su correspondiente representación software. Estas correspondencias permiten llevar a cabo el proceso de generación sistemática de código.

1.1. Introducción

El modelado de sistemas es una técnica fundamental usada en muchos

de los paradigmas para el desarrollo de software. La utilización de modelos durante el desarrollo del software permite trabajar con conceptos más próximos al dominio del problema que los ofrecidos por los lenguajes de programación actuales, con lo que se reduce la complejidad en el desarrollo de sistemas. De esta manera, es posible aumentar la productividad y calidad en el desarrollo de software. La técnica del modelado conceptual, en el ámbito de cualquier método OO, comprende dos pasos básicos: (1) la identificación de clases, con sus atributos y métodos, y (2) la identificación de relaciones entre clases [DHC01]. Las relaciones son componentes fundamentales de un sistema, evitan el aislamiento de los elementos que lo constituyen, estableciendo conexiones que permiten llevar a cabo la función del sistema. En los modelos conceptuales OO, las relaciones permiten a las clases integrarse en el sistema modelado, configurando la funcionalidad de éste. Las relaciones utilizadas básicamente por los métodos OO son las relaciones de generalización y las relaciones de asociación.

La generalización permite la definición de nuevas clases, llamadas

subclases, como especialización de otras clases ya definidas, llamadas superclases. Las subclases heredan los atributos y métodos de sus superclases, pudiendo definir nuevas propiedades. Por ejemplo, Coche es la especialización de Vehículo [Pele01].

- 2 -

La asociación es una conexión estructural entre clases. Es posible encontrar asociaciones binarias o n-arias (n ≥ 3). Un ejemplo de asociación binaria es la relación trabaja para entre una clase Empleado y una clase Compañía [RUM87]. Existe un tipo especial de asociación, la agregación, en el que entre las clases asociadas se distingue una clase agregada y una o varias clases componentes. Por ejemplo, Coche es una clase agregada de las clases componentes Rueda, Motor y Chasis [SAK98].

El uso de las relaciones durante el modelado del dominio de una

aplicación es a menudo problemático [WSW00]. Al trasladar las propiedades y la naturaleza de las relaciones al modelo conceptual, surgen complejas cuestiones que dificultan la tarea de modelado a los usuarios de metodologías de modelado conceptual. Pese a que en los últimos años han aparecido trabajos que tratan de solucionar estas cuestiones, la utilización de definiciones y términos relativos a las asociaciones con diferentes propósitos y significados, da lugar a definiciones poco precisas e interpretaciones ambiguas de muchos conceptos relacionados con la asociación.

La falta de una definición consensuada para la asociación hace compleja

la utilización e interpretación de las asociaciones en modelos conceptuales. Esto dificulta transformar las asociaciones en una representación software, lo que impide obtener código que represente fielmente la realidad especificada en el modelo mediante las asociaciones. La tesis propone una solución a algunas de las carencias detectadas de la asociación, definiendo un modelo de asociación preciso que permite definir las características más relevantes de la asociación. Actualmente también es necesaria la definición de una propuesta de implementación para la asociación que permita representar fielmente las características especificadas en un modelo de forma que se cumplan los principales criterios de calidad del software. Para ello, se propone un framework de implementación que define la estructura de clases de diseño que permite representar la asociación y las propiedades del modelo introducido. Además, se definen las correspondencias que permiten transformar un modelo de asociación concreto en su representación software, lo que permite completar el proceso de desarrollo de software en el contexto de un método de desarrollo de software basado en modelos.

• Contexto Tecnológico

El Desarrollo Dirigido por Modelos (“Model-Driven Development”) [MMF03] y las Fábricas de Software (“Software Factories”) [GSCK04] constituyen dos enfoques para el desarrollo de software sobre los que actualmente existe especial interés. Ambas aproximaciones utilizan los modelos como recurso fundamental dentro de sus propuestas de desarrollo.

El Desarrollo Dirigido por Modelos (DDM) propone iniciar el proceso de

desarrollo a partir de modelos de alto nivel de abstracción, transformando las abstracciones de estos modelos, en primitivas de más bajo nivel, que en última instancia se corresponden con líneas de código en un lenguaje de programación. Dentro de esta aproximación, aparece la propuesta MDA (“Model-Driven Architecture”) [MDA03] de la OMG (“Object Management

- 3 -

Group”). MDA es un estándar que promueve el MDD y agrupa varios lenguajes que pueden usarse para seguir este enfoque. MDA proporciona la infraestructura tecnológica y conceptual con la que construir métodos MDD.

El enfoque de las Fábricas de Software se centra en el desarrollo de sistemas similares promoviendo la reutilización de arquitecturas, componentes software y conocimiento. Para un conjunto de sistemas similares se diseña una arquitectura, con un framework1 que soporte esta arquitectura, y se desarrollan métodos específicos (lenguajes, herramientas, etc.) para este tipo de sistemas. Utilizando estos métodos, los desarrolladores describen cada sistema a través de un lenguaje de modelado específico que permite expresar las características del sistema en desarrollo utilizando conceptos más cercanos al dominio. Estas especificaciones son el punto de partida para la generación automática de código que extiende el framework que sigue la arquitectura compartida por todos los sistemas desarrollados utilizando la factoría.

En el ámbito de estas aproximaciones, aparecen métodos que

proporcionan herramientas y técnicas que guían y facilitan el proceso de desarrollo del software. Estos métodos necesitan definir abstracciones conceptuales que permitan especificar de forma precisa la realidad de un sistema. Estas abstracciones deben posteriormente ser transformadas a una representación software de calidad. En este contexto adquieren especial relevancia los patrones de diseño [Gam94] que proponen estructuras de diseño para implementar diferentes abstracciones presentes en la mayoría de las aplicaciones. También, la utilización de frameworks [JF88], conjunto de clases que constituyen estructuras de implementación, rentabiliza la generación de código, facilitando la tarea a los desarrolladores de software.

Los métodos, herramientas y técnicas proporcionados por estas

aproximaciones se utilizan en la tesis para desarrollar el modelo de asociación, el framework para su implementación y un conjunto de correspondencias que permiten trasladar asociaciones especificadas a través del modelo propuesto en una estructura de clases de diseño que instancia el framework. De esta forma, la tesis proporciona un proceso de desarrollo completo para la generación de código de la asociación.

Una vez presentado el contexto en el que se desarrolla la presente tesis

a continuación se presentan los siguientes apartados: en el segundo apartado se presenta la motivación que nos ha llevado a desarrollar el trabajo de investigación de esta tesis; en el tercer apartado se presentan los objetivos definidos en la tesis; en el cuarto apartado se presenta la metodología de trabajo que se ha utilizado durante el desarrollo de la tesis; y por último el quinto apartado presenta la estructura de la tesis.

1 En la tesis se utiliza el término inglés “framework” puesto que su traducción a castellano (marco) no se adecua al significado exacto de la palabra inglesa en el contexto en el que ésta se utiliza.

- 4 -

1.2. Motivación En el contexto del MDD y las Fábricas de Software se necesitan técnicas

y herramientas que den soporte a sus propuestas de desarrollo. Fundamentalmente, existen tres aspectos que se deben desarrollar:

• Abstracciones de Modelado Conceptual con una semántica precisa. La

precisión de los constructores de modelado es un aspecto crucial para facilitar la construcción de modelos conceptuales y la definición de transformaciones que garanticen que el código generado es funcionalmente equivalente a la especificación.

• Técnicas de Implementación (Frameworks y Patrones de Diseño) que faciliten la implementación de las abstracciones de modelado en los lenguajes de implementación destino, simplificando la definición de transformaciones y la obtención de soluciones de calidad.

• Técnicas y Lenguajes de Transformación para facilitar el desarrollo de

generadores de código mediante transformaciones automáticas. Las transformaciones entre modelos son un elemento clave en la propuesta. Actualmente existen algunas propuestas de lenguajes de transformación y técnicas para realizar estas transformaciones, que pueden ayudar en la construcción de generadores de código automático.

Una de las abstracciones de Modelado Conceptual que carece de

soluciones para las necesidades detectadas es la asociación entre clases. Esta abstracción es una de las más usadas en el Modelado Conceptual. Sin embargo existe un considerable desacuerdo respecto a qué es una asociación y cuáles son sus propiedades, lo que dificulta la construcción de modelos conceptuales precisos [Eve05]. En el ámbito de Modelado Conceptual, se puede afirmar que una asociación es una relación que representa una conexión semántica o estructural entre clases, más allá de esta afirmación surgen discrepancias que contribuyen a la falta de consenso.

En este contexto es inevitable hacer referencia al estándar UML

[UML2.0]. UML proporciona la sintaxis y semántica de un lenguaje de modelado estándar. En distintos trabajos [STV02, DIA99, GNV03] se ha puesto de relevancia las ambigüedades e imprecisiones que aparecen en la definición de los elementos que constituyen UML, en especial de las asociaciones. No obstante, el marco que proporciona UML puede ser útil como punto de partida para la definición precisa de un modelo de asociaciones, lo que permite beneficiarse de la enorme difusión de los conceptos utilizados por este lenguaje.

Respecto a las técnicas de implementación y de diseño para la

asociación, actualmente existe una importante carencia de técnicas que ofrezcan garantías de calidad y propongan procesos de trasformación que permitan obtener automáticamente el código asociado a la especificación de la abstracción en los modelos conceptuales. Las técnicas aplicadas en la actualidad (Objeto-Relación, Punteros [GBHS97], Metaclases [DCH01,

- 5 -

DP94], Genericidad [RHS95, KP97],...) ofrecen soluciones parciales y de baja calidad debido a la dificultad en el mantenimiento de la consistencia, la complejidad de implementación, la difícil aplicabilidad, etc.

Por otro lado, son necesarias propuestas de transformación que

permitan obtener implementaciones completamente operativas a partir de especificaciones de asociaciones en modelos conceptuales.

La presente tesis pretende dar respuesta a las necesidades de la

asociación detectadas. La tesis realiza las siguientes aportaciones: 1. definición de un modelo para la asociación que clarifique los aspectos

más complejos de ésta, de forma que sea posible utilizar la abstracción de forma clara, comprensible y concisa. Para ello se utiliza como punto de partida las definiciones básicas de UML para la asociación;

2. propuesta de una implementación de calidad completa para las

asociaciones. La utilización de patrones de diseño y frameworks proporciona soluciones reutilizables de calidad facilitando la generación de código; y

3. definición de las correspondencias entre la especificación de la

asociación y su representación software. Esto permite construir un proceso de transformación que se pueda automatizar y pueda ser aplicado de forma sistemática en herramientas CASE.

El trabajo de tesis se desarrolla en el contexto del método de desarrollo

de software OO-Method. OO-Method [OOM96, OOM97, OOM98, OOM01] es un método Orientado a Objetos2 de producción automática de software basado en un modelo formal de objetos, desarrollado en el grupo de investigación al que pertenece la autora de la tesis. OO-Method parte de modelos conceptuales OO para el desarrollo de sistemas de gestión. A estos modelos se les aplican transformaciones que permiten obtener el código del sistema de forma automática. La finalidad de OO-Method es generar aplicaciones sobre un conjunto específico de tecnologías.

La filosofía de OO-Method integra las aproximaciones de MDA y Factorías

del Software. Por un lado, siguiendo la estrategia metodológica que proponen las Factorías del Software, OO-Method genera aplicaciones para un conjunto de sistemas del mismo tipo (sistemas de gestión). Para implementar estos sistemas se propone un lenguaje de modelado específico (DSL) y un framework de implementación. Por otro lado, siguiendo la propuesta de MDA, el DSL se desarrolla utilizando primitivas conceptuales independientes de plataforma y se especifica siguiendo la técnicas que propone la OMG (creando perfiles UML).

El proceso de desarrollo que sigue actualmente OO-Method se puede ver

en la figura 1.1. La transformación de PIM a código es directa, sin pasar por la transformación a PSM. Esta aproximación se contempla en MDA (ver [MDA03] pág 3-7).

2 En [MMF03] Atkinson y Kühne identifican la Orientación a Objetos como la tecnología más adecuada para abordar el Desarrollo Dirigido por Modelos.

- 6 -

Figura 1.1. Representación gráfica del proceso de desarrollo OO-Method

1.3. Objetivos La presente tesis persigue tres objetivos generales:

• Definir un modelo de asociación con una semántica bien definida, precisando la semántica de los conceptos de UML utilizados para la definición de las asociaciones (asociación, agregación y composición) y eliminando las ambigüedades introducidas por UML. En esta tesis se propone una interpretación semántica para estos conceptos basada en la utilización de un marco conceptual que identifica un conjunto de propiedades esenciales que permiten caracterizar las asociaciones.

• Proponer un framework basado en el uso de patrones de

diseño para la implementación de las asociaciones. Este framework permite obtener una implementación de calidad para las asociaciones especificadas en función de las propiedades del marco conceptual propuesto.

• Definir una aproximación metodológica completa para la

generación automática de código. Se define una estrategia de implementación que define un conjunto de correspondencias entre la abstracción conceptual (PIM) y el framework propuesto (PSM). Estas correspondencias permiten instanciar el framework para obtener una implementación completa de la asociación.

Estos tres objetivos se pueden dividir en subobjetivos específicos que determinan de forma detallada las tareas a realizar. El primer objetivo se divide en los siguientes subobjetivos:

• estudiar las distintas propuestas que han abordado la definición (formal y semi-formal) de la asociación en el ámbito del modelado conceptual OO, con el fin de determinar las características comunes que poseen las propuestas existentes, para construir un marco

Enterprise JavaBeans (EJB) . NET Visual Basic

( Com+)

Modelo Conceptual

Frameworks Patrones de Diseño

Estrategias de Ejecución

PIM

Código

DSL

- 7 -

general aplicable en la identificación y caracterización de la asociación en la etapa de modelado,

• definir de forma precisa un modelo para las asociaciones,

incorporando este nuevo modelo a OO-Method, y proporcionando una notación gráfica basada en UML,

• construir un perfil (“profile”) UML para las asociaciones. Este perfil

nos permite extender el estándar UML incorporando los constructores definidos en nuestra propuesta.

• desarrollar una guía metodológica a partir del marco conceptual y el

modelo de asociaciones introducido. Esta guía ayudará al modelador en el proceso de identificación y especificación de asociaciones. Se definirá un método que determinará cómo se aplica de forma sistemática esta guía en la etapa de modelado conceptual

El detalle del segundo objetivo es el siguiente:

• determinar cuáles son los factores de calidad del software a

desarrollar. Estos factores determinan el proceso de construcción de la propuesta indicando qué estructuras son adecuadas para implementar la asociación,

• analizar los distintos patrones de diseño y técnicas de

implementación que permitan implementar las asociaciones cumpliendo las características de calidad identificadas,

• construir la estructura de clases de diseño del framework. Utilizando

los patrones de diseño seleccionados en el paso anterior se definen las clases de diseño que permiten implementar las asociaciones.

Los subobjetivos implicados en el tercer objetivo general son los siguientes:

• establecer las correspondencias entre los elementos y propiedades estructurales de las asociaciones y la estructura (clases de diseño, métodos y atributos) del framework definido,

• establecer las correspondencias entre las propiedades de

comportamiento de las asociaciones y los métodos de las clases de diseño que forman parte del framework,

- 8 -

1.4. Metodología de Trabajo

En este apartado se presenta el método seguido para desarrollar la solución que propone la tesis. El método detalla las etapas que han permitido llegar a la solución propuesta.

Este apartado se divide en dos bloques atendiendo a los aspectos que presenta la tesis: por un lado la definición del Modelo Conceptual y por otro la construcción del Framework de Implementación. 1.4.1. Definición del Modelo Conceptual

La figura 1.2 muestra el esquema del método seguido para la definición del Modelo Conceptual. En el esquema se identifican las distintas etapas llevadas a cabo (representadas por rectángulos nominados) y los datos de entrada y salida de dichas etapas (representados por flechas etiquetadas que entran y salen de las etapas).

El método comienza con una primera etapa, Análisis de Trabajos, donde se analizan los trabajos más relevantes que estudian las relaciones de asociación y que identifican sus propiedades estructurales y de comportamiento. Como resultado de este análisis se obtienen las propiedades de la asociación identificadas en los diversos trabajos.

Paralelamente, se lleva a cabo la etapa de Selección de Criterios de Calidad, donde se selecciona un conjunto de criterios que garantiza la calidad de los modelos conceptuales.

Las propiedades identificadas y los criterios de calidad son las entradas de la siguiente etapa, Selección de Propiedades. En esta etapa se selecciona un subconjunto de las propiedades identificadas en función de los criterios de calidad seleccionados. Estas propiedades permiten caracterizar la asociación de forma precisa.

En la etapa Interpretación de la Asociación, se proporciona una interpretación precisa a los conceptos UML que definen la asociación. Esta interpretación se realiza en función de las propiedades seleccionadas en la etapa anterior.

Con las definiciones realizadas y el diagrama de clases de OO-Method, se pasa a la etapa de Definición del Modelo para las Asociaciones. En esta etapa se definen los nuevos constructores conceptuales y sus propiedades a través de un metamodelo. El modelo definido se utiliza en las dos últimas etapas: Desarrollo del Perfil UML, donde se desarrolla un perfil UML para extender el lenguaje incorporando los constructores de nuestro modelo; y Desarrollo de un Ayudante para el Modelado de las Asociaciones, donde se construye una herramienta para facilitar el modelado de las asociaciones.

- 9 -

Figura 1.2. Esquema del proceso seguido para la definición del Modelo de Asociaciones propuesto

1.4.2. Construcción del Framework

La figura 1.3 muestra el esquema del proceso seguido para la construcción del framework.

El proceso comienza con la Identificación de Criterios de Calidad. En esta etapa se seleccionan los criterios de calidad específicos para la asociación entre criterios de calidad del software existentes. Estos criterios se utilizan en la etapa de Selección de Patrones de Diseño, donde se seleccionan entre los patrones de diseño existentes, aquellos que permiten implementar una asociación cumpliendo los criterios de calidad identificados. Esto permitirá generar estructuras de diseño adecuadas para la asociación.

En la siguiente etapa, Definición del Framework, se aplican los patrones de diseño seleccionados sobre la abstracción asociación. De esta forma se construye una estructura de clases de diseño que implementa la asociación. Esta estructura de clases constituye el framework.

Una vez el framework ha sido definido, en la etapa Definición de Correspondencias entre la Asociación y el Framework, se establecen las correspondencias entre la especificación de la asociación en el Modelo Conceptual y la estructura de clases de diseño del framework. Estas correspondencias permiten instanciar el framework a partir de relaciones de asociación concretas, obteniendo la implementación de dichas asociaciones.

Figura 1.3. Esquema del proceso seguido para el desarrollo del Framework

- 10 -

1.5. Estructura de la Tesis

La tesis se estructura en los siguientes capítulos:

• Capítulo 1. Introducción

El presente capítulo introduce en primer lugar el contexto en el que se desarrolla el tema de la tesis, seguidamente se presenta la motivación que ha llevado a abordar dicho tema, en el tercer apartado se presentan de manera detallada los objetivos que se pretende alcanzar, en el cuarto apartado se presenta la metodología de trabajo que se ha seguido durante el desarrollo de la tesis, y por último, se muestra cómo se estructura la tesis en diferentes capítulos.

• Capítulo 2. Estado del Arte

En este capítulo se realiza un análisis de los trabajos que tratan aspectos relativos a las relaciones de asociación tanto a nivel de análisis OO como de diseño OO. Se describen sus características principales y se identifican cuáles son los principales problemas que presentan. Además, dado en el contexto en el que se enmarca la tesis, se presenta un análisis de las aproximaciones y métodos para el desarrollo de software relacionados con la aproximación seguida en la tesis.

Parte I. La Asociación en el Espacio del Problema

• Capítulo 3. Un Marco Conceptual para el Modelado de la Asociación

En este capítulo se propone un marco que identifica un conjunto de propiedades estructurales y de comportamiento que permiten caracterizar las asociaciones en el esquema conceptual. Estas propiedades se seleccionan y adaptan tras un análisis de las aproximaciones más relevantes que estudian estas relaciones. Previo a la selección de las propiedades se identifican los factores que permiten determinar la calidad de un modelo y que serán los que guíen el proceso de selección. El marco propuesto permite categorizar los distintos tipos de asociaciones y comprender sus características esenciales y su semántica independientemente de los términos utilizados para nombrarlas.

• Capítulo 4. Un Modelo para las Asociaciones

Una vez introducido el marco conceptual, en este capítulo se precisa la semántica de los conceptos de UML relacionados con las asociaciones (asociación, agregación y composición). Para ello se parte de las definiciones básicas que UML propone para estos conceptos. A partir de estas definiciones se utiliza el marco conceptual propuesto para precisar su semántica. Una vez definido el modelo se realiza la especificación de los patrones conceptuales

- 11 -

identificados en OO-Method y se proporciona una notación gráfica basada en el estándar notacional UML. Además, se construye un perfil UML para el modelo construido, de forma que se extiende el lenguaje incorporando los nuevos constructores del modelo. En el último apartado, se construye una guía que dirige el proceso de modelado de asociaciones. La guía ayuda al modelador a identificar los distintos tipos de asociaciones existentes y sus características estructurales y de comportamiento

Parte II. La Asociación en el Espacio de la Solución

• Capítulo 5. Generación de Código

En este capítulo se seleccionan un conjunto de patrones de diseño para la implementación de las asociaciones, de tal manera que se cumplan los criterios de calidad identificados para estas implementaciones. A partir de estos patrones y haciendo uso del marco conceptual propuesto en el capítulo 3, se construye un framework basado en patrones de diseño que permite implementar las asociaciones de forma que soporta de manera natural las características estructurales y de comportamiento de las asociaciones especificadas utilizando el modelo presentado en el capítulo 4. A partir del framework se define un proceso de transformación que establece las correspondencias entre los elementos del esquema conceptual y los elementos que forman el framework. El framework propuesto cumple una serie de factores de calidad de software que garantiza la calidad de la propuesta. La generación de código se lleva a cabo en arquitecturas de tres niveles utilizando el lenguaje C# para presentar los ejemplos de código generado. La propuesta aborda de forma detallada la generación de los elementos software del nivel de la arquitectura en el que se implementa la lógica de los objetos de negocio; y propone una implementación para el nivel de presentación y de persistencia.

• Capítulo 6. Conclusiones

En este capítulo se presentan las conclusiones del trabajo y se destacan las principales contribuciones de la tesis. Además se proponen líneas de trabajo futuras relacionadas con la presente tesis.

• Apéndice.

Para completar el trabajo de tesis se presentan los Apéndices A y B.

En el Apéndice A, Ejemplo de Modelado y Generación de Código, se desarrolla un caso de estudio en el que se aplican las propuestas presentadas en esta tesis. El ejemplo se aborda desde la etapa de modelado hasta la generación de código C# a través de los siguientes pasos:

- 12 -

1. aplicando la guía de modelado presentada en el capítulo 4, 2. construyendo el esquema conceptual OO-Method siguiendo la

notación UML propuesta en el capítulo 4, 3. instanciando el framework utilizando las correspondencias

definidas en el capítulo 5, y obteniendo los componentes software del nivel de aplicación.

En el apéndice B, Implementación de Transformaciones utilizando el lenguaje MOFScript, se presentan las plantillas construidas utilizando el lenguaje MOFScript que permiten transformar de forma automática un modelo construido utilizando el metamodelo propuesto en el capítulo 4 y la representación software propuesta en el capítulo 5.

- 13 -

Capítulo 2 Estado del Arte

A lo largo de la literatura es posible encontrar numerosos trabajos que tratan las asociaciones en diversas áreas de estudio, como el Modelado Conceptual OO, el Modelado de Datos, las aproximaciones Ontológicas, los Métodos de Producción Automática de Software o los Métodos de Diseño. En este capítulo se presenta un análisis de distintas aproximaciones relacionadas con las áreas de investigación de la tesis. El objetivo de este análisis es contextualizar adecuadamente el trabajo desarrollado, destacando las aportaciones de nuestra propuesta frente a las existentes.

2.1. Introducción

La Asociación es una de las abstracciones más utilizadas en el modelado conceptual OO. Esto ha originado la aparición de diferentes aproximaciones que han propuesto definiciones y propiedades para caracterizarla. A pesar de ello, no se ha logrado alcanzar un consenso que permita utilizar e interpretar la asociación de forma precisa durante el modelado conceptual. Respecto a la implementación de la asociación, es posible encontrar diferentes técnicas que proponen estructuras de programación para la implementación del concepto de asociación, aunque la mayoría de estas propuestas dejan de lado la implementación de sus propiedades. El conocimiento de diseño proporcionado por estas técnicas se puede aprovechar y combinar para elaborar estructuras de diseño que representen la asociación y sus propiedades cumpliendo criterios de calidad del software. Por otro lado, en el marco del DDM, actualmente existen diversas propuestas que proporcionan técnicas que se pueden utilizar para la definición de transformaciones que permitan de forma automática obtener una representación software de calidad para la asociación.

El objetivo de este capítulo es analizar las propuestas de modelado, de

implementación y de transformación existentes, de forma que sea posible, por un lado, integrar las aportaciones o mejores prácticas de los distintos trabajos y, por otro, enmarcar de forma adecuada la propuesta de la tesis en el conjunto de dichas propuestas. El análisis de las diferentes propuestas se ha llevado a cabo en tres subapartados atendiendo a diferentes aspectos que abarca la tesis:

(1) con el objetivo de contextualizar el trabajo de la tesis dentro de las

aproximaciones DDM (puesto que el método OO-Method sigue esta filosofía), en el segundo apartado se realiza un repaso de las aproximaciones y herramientas englobadas en este contexto. En este apartado además se incluye un estudio de las técnicas de transformación existentes que aparecen entorno al DDM, entre las cuales se encuentran algunas técnicas que serán utilizadas en la tesis para llevar a cabo la transformación de la asociación a su representación software;

- 14 -

(2) en el tercer apartado se analizan los trabajos que tratan las asociaciones desde la perspectiva de modelado (Espacio del Problema). Este estudio permitirá conocer el estado actual de la abstracción asociación en el modelado conceptual; y

(3) en el cuarto apartado se estudian las técnicas de implementación y

patrones de diseño existentes para la implementación de las asociaciones (Espacio de la Solución). Este estudio permitirá identificar las carencias presentes en las propuestas de implementación existentes y conocer cuáles son las técnicas más utilizadas para la implementación de la asociación.

2.2. Desarrollo Dirigido por Modelos

En el contexto del DDM se pueden encontrar diversos métodos y herramientas que dan soporte a este paradigma. En el primer subapartado de esta sección, se realiza un repaso a estos métodos y herramientas. El segundo subapartado se centra en uno de los puntos clave del DDM, los procesos de transformación, analizando las técnicas existentes para la implementación de transformaciones entre modelos.

2.2.1. Métodos y Herramientas

Desde hace más de un década han ido apareciendo métodos de DDM soportados por herramientas CASE que generan aplicaciones o prototipos de éstas a partir de modelos conceptuales. A continuación se presentan algunos de ellos. 2.2.1.1. CASE iUML

Entre estos métodos y herramientas destacamos el método xUML y su herramienta CASE iUML [iUML00]. xUML es un subconjunto de UML que incorpora un lenguaje de especificación de acciones. Este lenguaje proporciona toda la lógica condicional y las acciones primitivas para manipular el modelo de objetos de UML, permitiendo a los desarrolladores construir modelos del sistema que sean ejecutables, y utilizar estos modelos para producir código. xUML exige que los modelos estén completos para poder ejecutar satisfactoriamente un conjunto de pruebas asociadas. xUML es un perfil ejecutable para UML. Para construirlo se ha elegido un subconjunto de UML para el cual es posible asociar una semántica ejecutable. Con ello se pretende que los desarrolladores sólo utilicen un subconjunto de las técnicas que proporciona UML. xUML consigue producir prototipos ejecutables con la información de modelado con el propósito de ser validados. Estos prototipos no son evolutivos, si se desea producir código final, los modelos se deben enriquecer con información de diseño, por lo que se exige que el modelador construya modelos de diseño (basados en patrones de diseño) y los enlace con los modelos conceptuales, instanciando adecuadamente dichos modelos; todo ello de forma manual. iUML proporciona herramientas para que el desarrollador pueda construir generadores de código para tipos de proyectos específicos.

- 15 -

2.2.1.2. OBLOG CASE

OBLOG CASE [OBLCS] es una herramienta basada en el lenguaje de especificación formal OBLOG, que propone un proceso de generación automática de código basado en la reescritura de reglas en un determinado lenguaje que el diseñador debe conocer. El proceso que presenta OBLOG CASE para implementar un sistema se descompone en tres dimensiones: (1) el dominio del problema a resolver, (2) la arquitectura del sistema elegida para su implementación y (3) el entorno software. OBLOG es el lenguaje de modelado del dominio y ofrece independencia de las otras dos dimensiones. El modelo conceptual en el lenguaje OBLOG se almacena en un repositorio. Las otras dos dimensiones se llevan a cabo mediante un conjunto de reglas (en un lenguaje de script) que definen cómo navegar a través del modelo almacenado en el repositorio, permitiendo extraer la información relevante y producir la implementación del sistema software en un determinado lenguaje de programación y en una determinada arquitectura. Ésta es una aproximación abierta en la cual los diseñadores desarrollan su propio proceso de generación. El problema es que la herramienta no puede garantizar la calidad del software producido, y el resultado final depende de muchos factores, entre ellos que los desarrolladores entiendan bien la semántica de los elementos del lenguaje OBLOG y que sean unos buenos arquitectos e implementadores. Además un problema adicional es que las reglas embeben conjuntamente aspectos de arquitectura y de implementación. 2.2.1.3. BridgePoint

Otra aproximación interesante es el Diseño Recursivo de Shlaer y Mellor [SHML97] soportado por la herramienta BridgePoint. Este método no utiliza un lenguaje de especificación formal. Propone el modelado del dominio del problema y el modelado de la arquitectura de la aplicación con la misma notación. A partir de los modelos conceptuales del dominio y de la arquitectura se desarrollan una especie de patrones, llamados “archetypes” que el diseñador debe especificar utilizando un determinado lenguaje de programación (puede ser el lenguaje de programación destino). Mediante dichos “archetypes” se definen plantillas que, en el proceso de generación de código, se aplicarán a los modelos almacenados. La generación de código es un nuevo proceso que debe definir el desarrollador a través de un script. De nuevo este tipo de herramientas permiten generar código aunque es el desarrollador el que debe incorporar las reglas de traducción. Ésta es una aproximación abierta en la que la calidad del producto generado depende del desarrollador. 2.2.1.4. OptimalJ

OptimalJ3 es un entorno de desarrollo para aplicaciones J2EE, construido por Compuware Corporation. OptimalJ permite generar aplicaciones a partir de modelos visuales, basándose en el uso de patrones y en la arquitectura MDA. Proporciona una manera de escribir aplicaciones Java distribuidas

3 http://www.compuware.com/products/optimalj/

- 16 -

basadas en la arquitectura J2EE. OptmialJ proporcionan un editor de modelos de dominio para construir modelos de dominio. Este modelo de alto nivel está basado en objetos y contiene la estructura de la información manejada en la aplicación, así como las relaciones entre las diferentes estructuras de datos. El modelo de dominio contiene las clases de dominio, sus atributos, asociaciones, métodos y reglas de negocio. A partir del modelo de dominio, es posible generar modelos de presentación, lógico y de datos de la aplicación a través de la generación de patrones en línea con el estándar J2EE de Sun. OptimalJ proclama como una de sus principales claves la utilización de patrones que encapsulan prácticas de codificación de las especificaciones J2EE. Estos patrones están constituidos por un conjunto de plantillas de diseño e implementación y se utilizan para generar el código de las aplicaciones. Con OptimalJ se pueden crear aplicaciones utilizando el rango completo de componentes J2EE (Session and Entity Enterprise Java Beans (EJB), Java Server Pages (JSP) y tablas de datos de aplicación). El principal handicap de esta herramienta es que está pensada específicamente para el desarrollo de aplicaciones J2EE. 2.2.1.5. CodaGen Architect

CodaGen Architect, una herramienta proporcionada por CodaGen4, permite a los equipos de desarrollo transformar modelos UML en software ejecutable o en procesos de negocio. Esta herramienta permite adoptar la aproximación MDA, por lo que es posible centrarse en el código específico del negocio, y permite a éste evolucionar independientemente de la tecnología de la infraestructura. CodaGen trabaja con perfiles UML para EJB, XSDL, servicios web y soluciones e-business. La familia de herramientas CodaGen utiliza estándares como UML, XML, MOF, XMI, OCL, J2EE, .NET y otros relacionados con la creación y orquestación de servicios web. Existe un adaptador gráfico de UML para herramientas de modelado compatible con XMI 1.1. CodaGen da soporte a varios diagramas de UML: de clase, de estado, de actividad, de secuencia, de colaboración y de casos de uso. Los productos de CodaGen generan código fuente en Java, C#, VB, C++ y lenguajes basados en XML. Existen herramientas de adaptación (add-ins) para Rational Rose. 2.2.1.6. ArcStyler ArcStyler [REF] es una herramienta de Interactive Objects. Se define como una aproximación compatible con MDA, abierta a distintas plataformas. Utiliza MOF para soportar los estándares UML, XMI y JMI. Integra herramientas de modelado (UML) y desarrollo (ingeniería inversa, explorador de modelos basado en MOF, construcción y despliegue) con la arquitectura CARAT. Esta arquitectura permite la creación, edición y mantenimiento de cartuchos MDA (MDA-Cartridge). Los cartuchos MDA contienen la tecnología y mecanismos para la transformación automática de modelos a infraestructuras de bajo nivel. Incluye herramientas relacionadas con el modelado del negocio y el modelado de requisitos. En [GRMOS04] se realiza una comparación de las herramientas OptimalJ y ArcStyler. En este trabajo se destaca la flexibilidad de ArcStyler para generar código en

4 http://www.codagen.com/products/architect/default.htm

- 17 -

distintas plataformas frente a la opción de OptimalJ orientada únicamente a la plataforma J2EE. Por otro lado, se cuestiona la dificultad de ArcStyler para llevar a cabo la integración de modelos y la de OptimalJ para el modelado de interfaces de usuario. 2.2.1.7. Diferencias Respecto a OO-Method. El trabajo desarrollado en la tesis se realiza en el contexto del método OO-Method, por lo que en este punto es interesante destacar algunas de las ventajas de este método frente a las distintas herramientas y métodos analizados. Las diferencias que presenta OO-Method respecto a estos métodos y herramientas consisten básicamente en:

• utilización de un lenguaje de especificación de acciones declarativo, OASIS [LSRP98]. Este lenguaje permite definir restricciones (como OCL) y acciones (como los lenguajes de especificación de acciones, ASL),

• 100% generación de código automática, frente a las demás herramientas que dejan en manos del modelador/desarrollador la definición de las correspondencias, por lo que no se puede garantizar que la generación sea completa ni funcionalmente equivalente,

• tradicionalmente la generación de código en OO-Method se interpreta como una compilación de modelos, más que una transformación de modelos, puesto que OO-Method garantiza la generación de código 100% ejecutable y funcional,

• incorporación de patrones de diseño y frameworks para producir software de calidad totalmente operativo,

• ser una aproximación general y cerrada, que garantiza una representación software funcionalmente equivalente al modelo conceptual. Actualmente se están proporcionando herramientas de “tweaking” que permiten modificar el código generado a nivel de interfaz de usuario y en subsiguientes generaciones mantener dichas modificaciones. Esto se está extendiendo también al código de la lógica de negocio a través de un repositorio de cambios,

• el método está soportado por una herramienta de generación de código industrial, OLIVA NOVA Model Execution [ONME]. Esta herramienta ha sido evaluada por Gartner Group y comparada con otras herramientas de modelado, arrojando unos resultados que la sitúan a la cabecera de este tipo de herramientas5.

• ONME está considerada por OMG como una herramienta “MDA compliant”6.

Una vez presentados los distintos métodos y herramientas de modelado que dan soporte a la filosofía DDM, en los dos siguientes apartados se presentan distintas técnicas que permiten llevar a cabo la transformación entre modelos, y de modelo a texto, necesarias en los métodos DDM.

5 http://www.care-t.com/technology/gartner.html 6 http://www.omg.org/mda/committed-products.htm

- 18 -

Hace apenas unos años existía una importante carencia de aproximaciones que dieran soporte al proceso de transformación que constituye un paso clave dentro de la aproximación MDA (como se ponía de relevancia en [TRF02]). Sin embargo, en los últimos años han aparecido diversos lenguajes y técnicas que permiten dar soporte a este proceso de transformación (en [CLS03] se presenta un trabajo en el que se propone una clasificación para las aproximaciones de transformación de modelos). A continuación se presentan algunas de estas técnicas. 2.2.2. Transformaciones de Modelo a Modelo En MDA juegan un papel clave los procesos de transformación que automatizan la transformación de modelos de alto nivel de abstracción en modelos de más bajo nivel. Por ello, desde la aparición de MDA, las transformaciones entre modelos son un campo de intensa investigación. A continuación se examinan algunas de las propuestas para la implementación de transformaciones. 2.2.2.1. MTF (Model Transformation Framework)

MTF7 es una propuesta de IBM como respuesta al MOF/QVT RFP de OMG [RQTRS]. IBM desarrolla MTF como un prototipo que implementa algunos conceptos de QVT. MTF está constituido por un conjunto de plug-ins que se integran a Eclipse8 o a las plataformas de desarrollo de IBM. Algunas características de MFT son:

- proporciona un lenguaje declarativo sencillo para definir mappings

entre modelos, - proporciona un motor de transformaciones capaz de interpretar los

mappings y llevar a cabo las transformaciones, - la transformación se aplica a modelos EMF9.

2.2.2.2. ATL (Atlas Transformation Language) El grupo ATLAS de la Universidad de Nantes desarrolla el lenguaje ATL10 [ATL05] como respuesta al MOF/QVT RFP de OMG. Este lenguaje híbrido (declarativo e imperativo) permite implementar transformaciones entre modelos (de PIM a PSM). Las transformaciones definidas en ATL son unidireccionales, a partir de un modelo fuente (de sólo lectura, no se permiten modificaciones en el modelo fuente) es posible generar un modelo destino. Para definir una transformación bidireccional se debe implementar la transformación como un par de transformaciones, una en cada sentido. Los siguientes principios caracterizan el lenguaje ATL:

- los modelos son entidades de primera clase, - las transformaciones son modelos, - permite la especialización y composición de transformaciones.

7 http://www.alphaworks.ibm.com/tech/mtf 8 http://www.eclipse.org 9 http://www.eclipse.org/EMF 10 http://www.sciences.univ-nantes.fr/lina/atl/atlProject/

- 19 -

2.2.2.3. QVT (Query, Views and Tranformations)

El lenguaje QVT [QVT05] es una propuesta de la OMG. Su utilización está orientada al contexto de MDA, tanto para realizar transformaciones PIM

PIM como PIM PSM. QVT proporciona tres tipos de transformaciones: - Queries: permite seleccionar elementos específicos dado un modelo

de entrada. - Views: permite generar modelos a partir de otros modelos - Transformations: permite modificar o crear un nuevo modelo a partir

de uno de entrada. QVT define tres lenguajes de transformación:

- CORE (declarativo) - Relations (declarativo) - Operational Mappings (imperativo)

Los lenguajes CORE y Relations encarnan la misma semántica a dos

niveles diferentes de abstracción. 2.2.2.4. Gramáticas de Grafos y AGG

Las gramáticas de grafos [EEKR99] se componen de un conjunto de reglas. Cada regla define en su parte izquierda (LHS) un subgrafo patrón y un su parte derecha (RHS) una subgrafo sustitución. Cuando se aplica una gramática de grafos a un grafo de entrada, las ocurrencias de los patrones de las LHS de las reglas son sustituidas por las RHS. De este modo, el grafo se va transformando. La representación de las reglas dependerá de la representación utilizada para los grafos.

Desde un punto de vista matemático, los modelos son grafos:

concretamente multigrafos de vértices y aristas etiquetadas, donde las etiquetas denotan las entidades definidas en el metamodelo. Por lo tanto, la aplicación de las gramáticas de grafos a la transformación de modelos es directa.

Una transformación puede definirse mediante una gramática de grafos

que toma como entrada un modelo expresado con elementos de un metamodelo determinado y devuelve otro modelo expresado con elementos de otro metamodelo.

Las gramáticas de grafos presentan algunas ventajas respecto a otras

técnicas para la transformación de modelos:

• Tienen una sólida base matemática desarrollada durante muchos años.

• Permiten una representación gráfica, lo que facilita la comprensión de

las transformaciones.

- 20 -

• Ya existen algoritmos y herramientas para su aplicación. Son de

naturaleza declarativa.

Las ventajas que ofrece esta última aproximación, nos han llevado a utilizar las gramáticas de grafos como técnica para la implementación de las transformaciones entre el modelo de asociación y el framework de diseño propuestos en la tesis.

Una de las implementaciones que utilizan Gramáticas de Grafos es AGG

(The Attributed Graph Grammar System) 11. AGG es un sistema que permite realizar transformaciones entre modelos basado en gramáticas de grafos. 2.2.3. Transformaciones de Modelo a Texto La transformación de modelo a texto constituye otro paso fundamental en el proceso de desarrollo de software dentro de la aproximación DDM. Este paso permite culminar el proceso de desarrollo de software que normalmente finalizará con la obtención del código fuente de una aplicación. A continuación se presentan algunas de las técnicas existentes que permiten llevar a cabo este paso. 2.2.3.1. XSLT

El lenguaje XSLT12 (XSL Transformation) lo define el consorcio W3C. Este lenguaje permite definir transformaciones entre documentos XML. Una transformación expresada en este lenguaje describe reglas para transformar un árbol fuente en un árbol destino. XSLT puede utilizarse para implementar transformaciones entre modelos, puesto que éstos pueden serializarse en documentos XML usando el XML Metadata Interchange (XMI). Desafortunadamente, esta aproximación tiene numerosas limitaciones de escalabilidad. La implementación manual de transformaciones en XSLT lleva a implementaciones difíciles de mantener debido a la poca legibilidad de XMI y XSLT. 2.2.3.2. Motores de Plantillas Un motor de plantillas es un software que procesa un texto de entrada, la plantilla, junto con un conjunto de datos para producir uno o más textos de salida. Una plantilla es un documento con vacíos de información que se completan al aplicar los datos. Las plantillas se definen utilizando un lenguaje de plantillas. Dentro de esta categoría de técnicas de transformación de modelo a código se encuentran las siguientes aproximaciones:

11 http://tfs.cs.tu-berlin.de/agg/ 12 http://www.w3.org/TR/xslt

- 21 -

FreeMarker13. Es un motor de plantillas en Java. Es una herramienta genérica que permite generar textos de salida. Está constituida como un paquete Java. Tiene un lenguaje de plantillas propio. El motor de plantillas utiliza las plantillas y los objetos Java para generar la salida de texto.

Velocity14. Es un motor de plantillas “open source”, implementado en Java. Utiliza su propio lenguaje de plantillas, denominado VTL. Las plantillas permiten referenciar de forma sencilla objetos definidos en código Java. Se puede utilizar en cualquier aplicación invocándose desde Java.

JET (Java Emitter Templates)15. JET es un motor genérico de plantillas “open source” que puede ser utilizado para generar código fuente SQL, XML, Java u otros destinos a partir de plantillas. JET facilita la definición de plantillas para la generación de código utilizando un subconjunto de la sintaxis JSP. Se localiza en el plug-in org.eclipse.emf.codegen como parte del “runtime” de EMF. Una plantilla JET es un fichero de texto con un nombre que acaba en “jet”.

2.2.3.3. MOFScript MOFScript16 es una herramienta “open source” para Eclipse que permite generar texto a partir de modelos basados en Ecore (subconjunto de MOF). Se está desarrollando en el ámbito del proyecto europeo MODELWARE. MOFScript proporciona un constructor “texttransformation” como la primitiva principal del lenguaje para la organización de la transformación. Una transformación tiene como entrada un metamodelo y está compuesta de una o más reglas. Cada regla se define sobre un elemento del metamodelo. Las reglas pueden tener argumentos, incluso devolver valores. La regla “main” es el punto de entrada de la transformación. En el apéndice B de la tesis se utiliza MOFScript para realizar la transformación de un modelo de asociaciones a código. Se ha utilizado esta herramienta porque presenta las siguientes ventajas:

- MOFScript es un lenguaje especialmente diseñado para llevar a cabo transformaciones de modelo a ficheros de texto. Se estructura a través de transformaciones y reglas.

- MOFScript trabaja directamente con descripciones de metamodelos (fichero Ecore).

- Las transformaciones MOFScript se ejecutan directamente en Eclipse. - MOFScript proporciona un constructor “file” para la creación de los

ficheros de texto destino. 13 http://freemarker.sourceforge.net/ 14 http://jakarta.apache.org/ 15 http://www.eclipse.org/emf 16 http://www.eclipse.org/gmt/mofscript/

- 22 -

2.3. La Asociación en el Espacio del Problema

En este apartado se presentan algunos de los trabajos que tratan la asociación desde la perspectiva del modelado conceptual OO. El apartado se estructura en dos secciones: en la primera se introducen algunos de los lenguajes y metodologías de Modelado Conceptual OO existentes, y en la segunda se presentan diversos trabajos que estudian propiedades conceptuales de las asociaciones. 2.3.1. Lenguajes y Metodologías de Modelado Conceptual OO

A continuación se presentan (en orden cronológico) algunos lenguajes y metodologías de modelado conceptual OO existentes. Cada uno de estos lenguajes o metodologías realiza una propuesta para el modelado de la asociación. 2.3.1.1. Catalysis.

Catalysis es una aproximación para el desarrollo basado en componentes y frameworks con UML. Está en desarrollo y aplicación desde 1992. Catalysis es un método que carece de propietarios. Los desarrolladores originales son Desmond D’Souza y Alan Wills, los cuales son coautores del primer libro de Catalysis[CAT98].

En Catalysis una asociación se define de la siguiente manera: “[...] un

par de atributos que son inversos uno del otro [...]” pág. 2-91 [CAT98]. Las propiedades de la asociación son:

• navegabilidad, la navegación permite referirse a los objetos asociados de un objeto utilizando la notación “.” seguida del nombre del atributo; en el caso de la asociación se puede especificar si los extremos son navegables o no,

• cardinalidad, especifica el número mínimo y máximo de objetos

asociados a un objeto,

• dinamicidad, especifica si el/los objeto/s asociado/s a un objeto es/son siempre el/los mismo/s,

• tipo de colección, especifica si la colección de objetos asociados a un

objeto es un conjunto (sin elemento duplicados), una bolsa (con elementos duplicados), o una secuencia (una bolsa con los elementos ordenados).

2.3.1.2. Syntropy.

Syntropy, descrito en el libro de Cook y Daniels [SYN94], es un método de análisis y diseño OO de segunda generación, desarrollado en “Object Designers Limited” en Reino Unido a principios de la década de los 90. El objetivo de desarrollar Syntropy era proporcionar una serie de técnicas de modelado que permitieran la definición de especificaciones precisa. Muchas

- 23 -

de las ideas de Syntropy se han incorporado en UML y Catalysis. En particular Syntropy es un predecesor directo de OCL.

Syntropy propone una notación y una semántica para las distintas

abstracciones que aparecen en el modelado conceptual OO, entre ellas la asociación. En [SYN94] pág. 30 la asociación se define de la siguiente manera: “Las propiedades que son otros objetos o colecciones de objetos se llaman asociaciones.”

Siguiendo la notación de OMT, en Syntropy una asociación entre tipos se

representa gráficamente como una línea que une los tipos participantes en la asociación. Cada extremo de la asociación une la asociación con un tipo. En Syntropy todas las asociaciones son navegables en ambas direcciones, entendiendo que la navegación no tiene relación con visibilidades o con caminos de acceso, sino más bien con el hecho de que una asociación puede ser leída en ambos sentidos. Una asociación implica la existencia de un par de asociaciones inversas, cada una con diferentes características.

Los conceptos propuestos por Syntropy para modelar las asociaciones

son:

• los roles, nombres que se asignan a los extremos de una asociación para identificar el papel que juegan en la relación los objetos de un extremo respecto a los objetos del otro extremo

• las multiplicidades, determinan el número mínimo y máximo de

objetos asociados que pueden tener los objetos de cada extremo

• los cualificadores, permiten distinguir un objeto entre el conjunto de objetos asociados a un objeto

• la agregación, es un tipo de asociación en el que la relación entre los

tipos es del tipo parte_de

• las propiedades de la relación, la asociación puede tener sus propias propiedades

• las relaciones ternarias, la asociación puede darse entre tres o más

tipos, dando lugar a relaciones ternarias o en general n-arias

• el operador indeterminado, permite ser menos específico cuando se modela la relación dando un valor indeterminado a la multiplicidad

2.3.1.3. UML.

UML se presenta como el “Método Unificado” en OOPSLA’95 en Octubre de 1995, propuesto por Grady Booch y Jim Rumbaugh. Ese mismo año se une a ellos Ivar Jacobson. En Noviembre de 1997 UML es aprobado por la OMG, apareciendo en 1998 el estándar UML 1.2[UML1.2]. UML ha ido evolucionando hasta su última versión UML 2.0 [UML2.0] que se publica en 2004. UML es un lenguaje de modelado que pretende unificar la semántica y la notación de los distintos elementos que aparecen en el modelado. UML

- 24 -

dispone de tres herramientas para especificar la semántica de las abstracciones conceptuales: el metamodelo, el lenguaje de definición de restricciones para objetos (OCL) y el lenguaje natural.

En UML se definen tres conceptos para modelar la abstracción

conceptual asociación:

• Asociación: “Una asociación describe un conjunto de tuplas cuyos valores son instancias de un tipo. Una instancia de una asociación es un enlace.” pág. 36 [UML2.0]

• Agregación: “Una forma especial de asociación que especifica una

relación parte-de entre el agregado (todo) y una parte componente.” pág. 4 [UMLI2.0]

• Composición: “Una forma de agregación que requiere que una parte

esté incluida en como máximo un compuesto a la vez, y que el objeto compuesto sea responsable de la creación y destrucción de sus partes.” pág. 7 [UMLI2.0]

En UML las asociaciones son por defecto bidireccionales (pese a que en

su definición se utiliza el término tupla, que no contiene direccionalidad). En la agregación se introduce una dirección, por lo que en este caso la agregación se considera unidireccional.

Según el metamodelo de UML 2.0 (ver figura 2.1) en los modelos

(instancias del metamodelo) las asociaciones son vistas como propiedades de las clases participantes. La propiedad de la clase representa uno de los extremos de la asociación (el extremo unido a la clase). Estas propiedades pueden pertenecer a la clase a la que están relacionadas, en cuyo caso la asociación es navegable, o a la asociación en sí. Si pertenecen a la asociación, la propiedad puede definirse como navegable o no navegable. La metaclase propiedad tiene un conjunto de atributos que permite definir las propiedades de cada extremo de la relación. Estos atributos son:

• multiplicidad, especifica el rango de cardinalidades que un conjunto

puede asumir. En el caso de que la propiedad represente una asociación, la multiplicidad determina el número mínimo y máximo de objetos asociados que pueden tener un objeto

• visibilidad, permite restringir el uso de un elemento en diferentes espacios de nombres (“namespaces”) dentro de un modelo. En el caso de la asociación permite restringir el uso de los extremos de la asociación

• modificabilidad, en un conjunto permite restringir la adición de nuevos

valores, eliminación de valores existentes o cambio de valores. En el caso de la asociación restringe la adición, eliminación o modificación de objetos asociados a un objeto

• tipo de asociación (normal, agregación o composición), especifica el tipo

de agregación que se aplica al extremo

- 25 -

Figura 2.1. Diagrama de Clases del paquete “Constructs” [UMLI2.0]

• orden, especifica si los valores de un conjunto están secuencialmente

ordenados. En el caso de la asociación determina si los objetos asociados a un objeto están ordenados

• unicidad, especifica si los valores de un conjunto son únicos. En el caso

de la asociación determina si en el conjunto de objetos asociados a un objeto pueden existir elementos repetidos.

La propuesta de UML para la asociación no ha logrado alcanzar un

consenso en cuanto a su semántica y categorización. Sellers et al. en [DIA99] ponen de manifiesto algunas ambigüedades que presenta la propuesta de UML 1.4 en la definición de composición. Este trabajo muestra como algunos aspectos concernientes al comportamiento de las partes y del todo en una composición no se definen de forma precisa en UML y se sugiere la revisión de las definiciones de agregación y composición, de tal manera que se pueda establecer claramente cuáles son las propiedades esenciales de la agregación y cuáles son las propiedades que permiten diferenciar la agregación de la composición. En [GNV03], Génova et al. identifican las contradicciones que aparecen en UML 1.4 en la definición e interpretación de las propiedades navegabilidad, visibilidad y direccionalidad.

En la tabla 2.1 se muestra una síntesis de algunas contradicciones y ambigüedades que aparecen en UML.

- 26 -

Concepto Descripción Agregación Definición poco precisa del concepto de

agregación. Cuestiones cómo ¿es posible separar una parte del todo? o ¿cuál es la repercusión de destruir una parte durante la vida del todo? no se clarifican.

Composición Definición poco precisa del concepto de composición. Cuestiones cómo ¿es posible separar una parte del todo? o ¿es posible crear una parte antes de que el todo haya sido creado? o ¿es posible destruir una parte después de que el todo haya sido destruido? no se clarifican.

Navegabilidad Falta de precisión en la definición de la relación entre navegabilidad, visibilidad y direccionalidad.

Simetría Carencia de mecanismos para la especificación de relaciones simétricas.

Instanciación Falta de precisión en la definición de las instancias de una asociación. Cuestiones cómo ¿los enlaces tienen identidad propia? ó ¿pueden existir tuplas repetidas? no se clarifican.

Tabla 2.1.Síntesis de las contradicciones y ambigüedades de UML respecto a las asociaciones 2.3.1.4. OML.

OML[OML97] es un lenguaje de modelado comparable a UML. OML aparece como lenguaje que da soporte a OPEN [OPM96], una metodología propuesta por un grupo de investigadores que surgen como alternativa a la OMG y sus propuestas. Los creadores de OML ofrecen una alternativa a la propuesta de UML, que como ellos mismos apuntan puede ayudar a mejorar el propio UML: “Las propuestas en OML[...] contienen un número de técnicas de notación y metamodelado avanzadas las cuales podrían ser también utilizadas para mejorar UML”.

OML proporciona un modelo para las relaciones basado en un conjunto

de propiedades que permite caracterizarlas. Las asociaciones (que se corresponden en OML con las llamadas “referential relationship”) son un subtipo de relación. En [OPR98] y [FHS98] se presenta la clasificación para las asociaciones que propone OML. En la figura 2.2 se puede ver el metamodelo OML para las relaciones.

Las asociaciones (“Referential Relationship”) se especializan en tres

subtipos: “Normal Association”, “Containment” y “Whole-Part”. La primera relación (“Normal Association”) es una asociación en la que no se especifica la direccionalidad, y que puede especializarse en asociaciones unidireccionales o bidireccionales. La segunda relación (“Containment”) es una asociación en la que existe una inclusión topológica (relación entre un contenedor, área o duración temporal y lo que está contenido en ellos). La última relación (“Whole-Part”) es una relación entre un objeto agregado y sus partes. Esta relación a su vez se especializa en “Aggregation” y “Membership”, según la relación sea configuracional o no. La

- 27 -

Configuracionalidad indica si existe una relación funcional o estructural entre las partes. Por ejemplo, la clase MotorCoche es una agregación en OML, puesto que la forma en que las partes están configuradas es crucial para la funcionalidad del motor.

La clasificación de las relaciones en OML constituye una diferencia

fundamental entre el modelo de asociación de UML y el de OML. En la figura 2.3 se pueden ver las propiedades que se utilizan en UML y OML para caracterizar las relaciones parte_de (“whole-part”).

Figura 2.2. Metamodelo OML para las asociaciones [FHS98]

Figura 2.3. Propiedades que caracterizan las relaciones “parte_de” en OML y UML [FHS98]

2.3.2. Otros Estudios de la Asociación

La complejidad y problemática que envuelve a algunos aspectos de las asociaciones ha llevado a numerosos autores a realizar estudios que traten de dar respuesta a estos problemas. Es el caso de Henderson-Sellers, el cual, en [OPR98], trata uno de los aspectos más problemáticos de la asociación, la Direccionalidad. Como el mismo autor reconoce “[...]

- 28 -

todavía permanecen anomalías subyacentes y preguntas sin respuesta. Una de éstas se refiere a la direccionalidad de una asociación [...]”. En este sentido este autor discrepa de la propuesta de UML donde las asociaciones son por naturaleza bidireccionales. Su propuesta opta por trabajar con relaciones en las que la direccionalidad no se especifica durante la etapa de análisis. La dirección de las relaciones se considera un aspecto de diseño, y no se define por tanto durante el modelado: “Sería mejor tomar una asociación en análisis para representar una conexión sin una dirección específica [...] y posteriormente usar el proceso de “refinamiento” [...] para convertir las relaciones sin dirección en una correspondencia dirigida apropiada [...]”.

Otro aspecto problemático es el que aparece en el mismo trabajo en el

que se estudia “[...] si una asociación es lo mismo que una tupla o lo mismo que una correspondencia, o ninguna.”. Siguiendo la propuesta del autor sobre la direccionalidad se propone “que las conexiones iniciales sean vistas como conexiones sin dirección o tuplas”, considerando que las tuplas no implican direccionalidad. Cuando después de refinar la relación se le dé una dirección, ésta es vista entonces como una correspondencia dirigida.

Otro trabajo que desarrolla un análisis en profundidad de estos

conceptos es el de Génova en [GNV03]. El autor estudia la abstracción asociación, centrándose en las propiedades Multiplicidad, Navegabilidad y Visibilidad que aparecen en UML. Este análisis pone de relevancia las contradicciones que comete UML en la definición de estas propiedades a lo largo de los distintos documentos que especifican el lenguaje. En este trabajo el autor trata de definir de forma precisa estas tres propiedades de la asociación, diferenciándolas unas de otras. La navegabilidad “no es directamente la posibilidad de enviar mensajes, sino la posibilidad que un objeto origen tiene de referenciar, nombrar o designar un objeto destino, con el fin de manipularlo o acceder a él en una interacción con intercambio de mensajes”.

El análisis de la navegabilidad refleja la relación entre ésta y otros

conceptos tales como la direccionalidad, la visibilidad, la dirección del nombre, la invertibilidad o la dependencia, propiedades que a partir de las definiciones de UML pueden confundirse con la navegabilidad. “En principio podemos asumir que una asociación es invertible cuando es bidireccional, es decir, cuando es navegable en ambos sentidos. Así pues, desde nuestro punto de vista, invertibilidad (invertibility), bidireccionalidad (bidirectionality) y navegabilidad en ambos sentidos (two-way navigability) son sinónimos.” Si la asociación es navegable en ambos sentidos se dice que es bidireccional, por el contrario si la asociación es navegable en solo un sentido es unidireccional. Sin embargo, esto no es lo que se desprende de los manuales de UML, donde más bien aparecen afirmaciones contradictorias respecto a estos conceptos.

Génova también analiza la relación existente entre los conceptos de

navegabilidad y visibilidad: “son conceptos independientes que se especifican también de modo independiente, pero la capacidad de utilizar una determinada clase, propiedad o extremo de asociación debe ser permitida conjuntamente por ambas características, primariamente por la

- 29 -

navegabilidad y secundariamente por la visibilidad”. En este sentido se propone que cuando una asociación sea navegable sólo en una dirección, el extremo de la asociación que no sea navegable no debe tener especificada la visibilidad.

Respecto a la dirección del nombre, se explicita la diferencia de esta

propiedad respecto a la navegabilidad. La dirección del nombre es una característica descriptiva de la relación que no tiene ninguna implicación sobre la funcionalidad de ésta: “la dirección del nombre no tiene nada que ver con la navegabilidad en un modelo de objetos, y en consecuencia no tiene nada que ver con la comunicación o interacción entre objetos.” Respecto a estos dos conceptos Génova propone que cuando una asociación sea navegable sólo en una dirección, la dirección del nombre de la asociación debe apuntar en la misma dirección que la asociación misma.

Génova referencia a la dependencia como una propiedad consecuente de

la navegabilidad: “una asociación navegable crea dependencia”. A este respecto se propone que no se debe introducir la navegabilidad bidireccional a menos que sea verdaderamente requerida.

Figura 2.4. Modelado de la relación Matrimonio como una clase Bock y Odell en distintos trabajos presentan un modelo para las

relaciones y su implementación. En [BOI98], se propone la utilización del tipo de objeto (clase) para el modelado de relaciones. Teoría respaldada también en [STW04]. En la figura 2.4 se puede ver un ejemplo de la relación Matrimonio modelada como un tipo de objeto (siguiendo la notación de UML). En este ejemplo la relación Matrimonio entre una clase Hombre y una clase Mujer se modela como una clase. Si se utiliza esta aproximación se pueden modelar restricciones de cardinalidad para las relaciones de dos tipos: (1) el número mínimo y máximo de objetos que pueden participar en una sola tupla de la relación y (2) el número mínimo y máximo de tuplas en las que puede participar un objeto a la vez. En el ejemplo de la figura 2.4 el primer tipo de cardinalidad indica que en una instancia (o tupla) de la relación matrimonio sólo pueden participar 1 objeto mujer y 1 objeto hombre. El segundo tipo de cardinalidad indica que un hombre sólo puede

- 30 -

estar relacionado a través de la relación Matrimonio con una mujer, y viceversa. La mayoría de los métodos sólo permiten modelar la segunda restricción de cardinalidad, considerando para la primera que la cardinalidad es siempre 1. Esta aproximación también permite modelar propiedades de las relaciones de forma sencilla. En este caso la relación/clase Matrimonio se relaciona con la clase Ciudad para especificar que un matrimonio se certifica en una ciudad.

En la aproximación seguida por esta tesis, las asociaciones se modelan

siempre como relaciones. Cuando la relación requiera un tratamiento complejo, debe reconsiderarse la opción de que la relación en si misma sea una clase asociada a otras clases. De esta manera el analista a partir de los requisitos del sistema puede optar por modelar las relaciones como clases, en las que puede especificar detalles adicionales de las relaciones, o simplemente modelarlas como relaciones cuando no sea necesario un tratamiento más complejo. En el caso de la relación Matrimonio entre la clase Hombre y la clase Mujer, se podría modelar como una clase, figura 2.5, o como una asociación, figura 2.6.

Hombre Mujer

-fechaMatrimonio

Ciudad

1..1

0..1

1..1

0..1

marido mujer

0..*

1..1certificación

Figura 2.5. Modelado de la clase Matrimonio

Figura 2.6. Modelado de la relación Matrimonio como una asociación

Olivé en [OLIVL] realiza un estudio del tipo relación y de sus

características, incluyendo un análisis de los aspectos temporales del tipo relación. En este trabajo se contempla la representación lógica y en UML de las relaciones, y se estudia la representación de las relaciones en bases de información no temporales y temporales.

En el estudio de las relaciones en bases de información no temporales,

se presentan reflexiones interesantes, como el estudio lingüístico de las asociaciones, que permite expresar una relación como un hecho de un

- 31 -

dominio a través de una oración gramatical, a la que se llama oración patrón. Las oraciones patrón ayudan a entender el significado del tipo relación.

Sobre las restricciones de cardinalidad de las asociaciones se propone

una representación para las restricciones de cardinalidad y se clasifican las relaciones atendiendo a la cardinalidad mínima: participación total (min >0) o parcial (min=0) y a la cardinalidad máxima: correspondencia funcional (max=1) o no funcional (max>1). Para las relaciones de grado superior a 2 se realiza un estudio adicional.

En la representación de las asociaciones en bases de información

temporales, se tratan los aspectos temporales de las relaciones. En las bases de información temporales, un tipo relación se representa utilizando un literal en el tipo relación que denota un instante en la unidad básica de tiempo. En este contexto, se definen cuatro características temporales del tipo relación:

• durabilidad (indica si las instancias de la relación son instancias en

instantes determinados, sin persistir de un instante a otro, o si son instancias durante un cierto intervalo de tiempo),

• frecuencia (indica si las instancias de la relación sólo pueden serlo durante un único intervalo (o instante) de tiempo en toda su vida),

• permanencia (indica si una instancia de una relación debe serlo durante toda su vida una vez lo ha sido) y,

• población constante (una relación es de población constante si posee las mismas instancias durante toda su vida).

Además de estas características, se definen otras cinco características

que son específicas del tipo relación: • sincronismo (la relación es síncrona cuando todos los participantes

en la relación deben existir en el mismo instante de tiempo en el que existe la relación, en el caso contrario es asíncrona),

• participación inicial de un participante en un tipo relación (especifica si es obligatorio, posible o no posible que un participante forme parte de una relación al iniciar su existencia como participante),

• intervalo de existencia de un tipo relación en un participante (indica si un participante siempre forma parte de una instancia de una relación a partir de la primera vez que forma parte de alguna instancia),

• mutabilidad de un tipo relación respecto de un participante (determina si es posible que un participante pueda cambiarse por otro en una instancia de una relación) y,

• capacidad de inserción en un tipo relación respecto de un participante (especifica si es posible añadir nuevas instancias de una relación de un participante).

La presente tesis utiliza modelos conceptuales no temporales (en

[PHIE98] se propone una extensión temporal del modelo de objetos de OO-Method). En los modelos conceptuales no temporales no se contempla de

- 32 -

forma explícita la dimensión tiempo, por lo que no se representan aspectos relacionados con la evolución temporal del sistema: valores temporales, restricciones temporales o características asociadas a la evolución temporal. Esto implica que algunas de las propiedades temporales que identifica Olivé (durabilidad, frecuencia, población constante, sincronismo) no se pueden representar en el modelo. No obstante, los modelos conceptuales no temporales permiten especificar ciertas propiedades relacionadas directamente con el tiempo, sin representar las instancias de las relaciones utilizando el instante de tiempo en el que acontecen. En el siguiente capítulo se analizan las propiedades relacionadas con el tiempo que pueden especificarse en modelos conceptuales no temporales (a las que llamamos propiedades dinámicas).

Modelado de la Agregación.

La agregación es una de las relaciones más estudiadas hasta el momento. Existen diferentes términos que se han utilizado comúnmente en el modelado OO para identificarla, como “composición”, “parte_de”, “meronimia” o “todo-parte”. En la presente tesis se utiliza el término “agregación” para identificar estas relaciones.

Una de las principales disyuntivas de la agregación consiste en si ésta se

considera un subtipo de la asociación o si, por el contrario, es una abstracción independiente. Mientras que OML y sus seguidores adoptan la idea de que es una abstracción independiente, UML apuesta por considerarla un subtipo de la asociación. En la tesis la agregación se define como una asociación con una característica semántica específica que la convierte en un subtipo de la relación de asociación.

Un trabajo interesante en el contexto de la agregación es el de Saksena

et al. [SAK98], donde se propone un conjunto de propiedades primarias y secundarias para estas relaciones. El conjunto de propiedades primarias se define como un conjunto suficiente y necesario para que una relación sea una relación de agregación. Mientras que el conjunto de propiedades secundarias es el conjunto formado por las propiedades de la agregación que la caracterizan en diferentes categorías (“flavours”).

El conjunto de propiedades primarias está formado por: • la Propiedad Emergente (la relación debe tener al menos una

propiedad independiente de las propiedades de sus componentes), • la Propiedad Resultante (la relación debe tener al menos una

propiedad que se pueda derivar de un subconjunto de las propiedades de sus componentes),

• la Transitividad (si un objeto A es parte de un objeto B y el objeto B es parte de un objeto C, entonces A es parte de C),

• la Antisimetria (si el objeto A es parte del objeto B entonces el objeto B no puede ser parte del objeto A),

• la Antirreflexividad (un objeto no puede ser parte de si mismo directa o indirectamente),

• el Solapamiento (el ciclo de vida de la parte debe solaparse con el ciclo vida del todo) y,

- 33 -

• la Pertenencia (un objeto es dueño de sus partes en el sentido de que controla el comportamiento de sus partes).

El conjunto de propiedades secundarias está formado por: • la Compartición (cuando un parte está asociada a más de un

agregado en un mismo instante de tiempo), • la Homogeneidad (las partes en una agregación son homogéneas

cuando tienen propiedades en común con el agregado o con otras partes de la estructura) y,

• la Propagación (las propiedades del agregado, atributos, operaciones y referencias, pueden propagarse a sus partes). La propagación es una forma de especificar un comportamiento continuo conjunto. Por ejemplo, en la propagación de operaciones, considerando un objeto agregado triángulo con sus extremos como partes, desplazar el triángulo requiere el desplazamiento de sus partes. La operación desplazar del agregado se propaga a sus partes. La propagación de atributos, supone, considerando un objeto agregado Coche formado por las partes Motor y Chasis, el color del Chasis es el color del Coche. El color del Coche se propaga al Chasis.

Este trabajo constituye el punto de partida de Henderson-Sellers et al.

en [WHT99], donde los autores tratan de mejorar la propuesta de Saksena ampliando y modificando las propiedades primarias y secundarias. En este trabajo, los autores identifican como propiedad primaria adicional, la propiedad Parte-de (relación que une un objeto que puede ser referenciado como el todo y varios objetos que son las partes). La transitividad no se considera propiedad primaria, argumentándose esta afirmación con ejemplos de relaciones donde no se cumple la propiedad pero donde se intuye claramente que las relaciones son agregaciones. La transitividad se considera una propiedad secundaria. Lo mismo ocurre con la propiedad Solapamiento, que pasa de ser considerada propiedad primaria a propiedad secundaria. La Pertenencia, se excluye del grupo de propiedades primarias, considerándose consecuencia de las propiedades primarias.

Como propiedades secundarias se incorporan la Mutabilidad (un parte

es mutable cuando puede sustituirse por otra parte de su misma clase), la Obligatoriedad (una parte obligatoria es una parte que debe existir para que exista el agregado), la Separabilidad (una parte es separable cuando puede ser eliminada del agregado) y la Encapsulación (cuando las partes son sólo visibles dentro del objeto agregado).

En [OPD00], Opdahl et al. validan este framework realizando un análisis

ontológico de la relación de agregación en modelos OO. Este análisis confirma la mayoría de las propiedades sugeridas. Sin embargo también propone una serie de modificaciones y sugiere proporcionar definiciones más precisas para algunas de las propiedades del framework.

Siguiendo con la agregación, Snoeck et al. en [SNK98] proponen una

única propiedad para caracterizar estas relaciones: la Dependencia Existencial. Esta propiedad se define de manera informal como: “si cada objeto de la clase P siempre se asocia a como mínimo 1 y como máximo 1, y siempre al mismo objeto de la clase Q, entonces P es dependiente

- 34 -

existencialmente de Q”. En el trabajo se propone modelar la relación de agregación utilizando exclusivamente esta propiedad. Pese a que en el trabajo se aportan demostraciones que justifican el uso de esta propiedad como única caracterización de la agregación, la utilización de esta propiedad durante el modelado resulta compleja. Para modelar la agregación a través de la Dependencia Existencial, es necesario utilizar en el modelo clases adicionales a las clases de dominio, con lo que no se cumpliría el propósito del modelado conceptual de intentar modelar los sistemas lo más próximo a la realidad.

Odell, en [ODL94], propone tres propiedades que permiten clasificar la

agregación (“composition relationships”) en seis tipos distintos. La clasificación para la agregación que Odell propone se basa en las propiedades Configuracionalidad, Homogeniedad (las partes y el agregado son el mismo tipo de ‘cosa’) e Invarianza (las partes pueden ser separadas del todo).

Otro trabajo interesante es el realizado por Civello en [CVL93]. En este trabajo Civello estudia la agregación (“Whole-part associations”) desde la perspectiva del análisis y del diseño, identificando las propiedades que son relevantes en cada etapa. Civello propone una clasificación sintáctica y semántica para las agregaciones en la etapa de análisis. Como patrones sintácticos identifica las agregaciones y las colecciones. Las primeras son agregaciones en las que la clase compuesta se relaciona con clases componentes con multiplicidad 1. En el caso de las colecciones la clase compuesta se relaciona con una clase componente con multiplicidad n. La clasificación semántica propone categorizar la agregación en la etapa de análisis según sea Funcional o no. En una agregación funcional la parte está conceptualmente incluida en el compuesto por medio de una conexión estructural o funcional, que permite que la parte contribuya a la función del compuesto.

Además de la clasificación propuesta para los modelos de análisis,

Civello identifica un conjunto de propiedades que caracterizan a las agregaciones en los modelos de diseño. Según Civello las agregaciones en el modelo de diseño se muestran como jerarquías de composición de objetos para enfatizar que su principal función es estructurar el sistema software y no modelar el dominio del problema. El conjunto de propiedades identificadas en el modelo de diseño está formado por las propiedades:

• Visibilidad (condición necesaria para que un objeto agregado pueda

enviar mensajes a sus partes), • Encapsulación, • Compartición, • Inseparabilidad de las partes (cuando las partes son no

separables), • Inseparabilidad del todo (cuando el todo no es separable), • Inmutabilidad (cuando la identidad del objeto parte no puede

cambiar) y, • Propiedad (“Ownership”) (un objeto es propietario (dueño) de

otro cuando el borrado del objeto agregado implica el borrado de sus partes).

- 35 -

Las propiedades introducidas en los trabajos presentados son analizadas

en el siguiente capítulo, donde se construye el marco conceptual. 2.3.3. Particularidades de la Propuesta de la Tesis

La propuesta de la tesis pretende mejorar el modelo actual de asociación/agregación de OO-Method con la intención de precisar las propiedades existentes e intentar introducir expresividad nueva. Con el objetivo de conseguir una mayor aceptación por la comunidad de desarrolladores y de ofrecer una propuesta que se aproxime a las abstracciones más utilizadas, la tesis toma como punto de partida la propuesta de UML para el modelado de la asociación. A partir de las definiciones básicas de UML nuestra propuesta trata de:

• precisar los conceptos relacionados con la abstracción asociación que aparecen en la literatura con ambigüedad, como la semántica de la agregación y la composición, y la definición de las propiedades de navegabilidad, visibilidad y direccionalidad,

• definir un modelo más pragmático (se pretende construir un modelo aplicable en entornos reales, que cumpla las premisas de claridad, concisión y corrección),

• dotar de expresividad adicional al modelo para capturar la máxima semántica posible de la asociación,

• independizar el modelo de aspectos de diseño, • orientarse a la ejecutabilidad del modelo. La definición básica de la asociación en UML, especializada en tres tipos,

asociación, agregación y composición, y utilizada en los lenguajes Syntropy y Catalysis, se adopta en la tesis como punto de partida para la elaboración del modelo de asociación. Las propiedades de la asociación presentes en estos lenguajes, se incorporan al marco conceptual propuesto, adecuando las propiedades para que puedan utilizarse de forma clara y concisa.

El marco conceptual introduce otras propiedades que tratan de dotar de

expresividad adicional al modelo de asociación. Puesto que en el contexto de OO-Method el objetivo principal es generar aplicaciones ejecutables y funcionales, las propiedades del marco son exclusivamente propiedades con representación en la implementación de la asociación, evitando incluir propiedades que capturen aspectos del dominio de la asociación que no puedan representarse en su implementación. 2.4. La Asociación en el Espacio de la Solución

Actualmente existen diferentes técnicas y patrones de diseño para la implementación de la asociación. A continuación se presentan algunas de ellas.

- 36 -

2.4.1. Técnicas de Implementación

En este subapartado se presenta un estudio de las técnicas de implementación existentes para la asociación basado en el trabajo de Dahchour en [DHC01], donde para cada técnica se presenta una breve descripción, identificando sus ventajas e inconvenientes. Una vez introducidas las técnicas se realiza un análisis de las implementaciones propuestas en función de los criterios de calidad de software que satisfacen y los requisitos intrínsecos de la asociación que cumplen. 2.4.1.1. Referencias

Esta técnica (Refe.)17 [GBHS97] es una de las técnicas más utilizada para la implementación de relaciones. Las relaciones se implementan a través de referencias o punteros. La semántica de las relaciones se implementa en sus clases participantes. Existen dos posibles implementaciones: (1) una dirección, donde la relación se representa en una de las clases participantes a través de un atributo objeto valuado (univaluado o multivaluado) y (2) dos direcciones, donde la relación se representa en las dos clases participantes a través del atributo objeto valuado. A continuación se presentan las ventajas e inconvenientes de esta técnica:

• Ventajas: permite el acceso rápido (directo) a la relación en la dirección en la que se implementa el atributo que la representa.

• Inconvenientes: la estructura y el comportamiento de la relación está

descentralizado, las clases participantes son complejas, presenta dificultad en la inserción, borrado y modificación de enlaces, y en el mantenimiento de la consistencia.

2.4.1.2. Objetos Relación

En esta técnica (O.R.) las instancias de una relación se implementan como objetos que mantienen referencias a los objetos relacionados. Para ello se definen clases relación que implementan la semántica de la relación. Las ventajas e inconvenientes de esta técnica son las siguientes:

• Ventajas: facilita la inserción, borrado y modificación de enlaces, proporciona utilización óptima de recursos de memoria, las clases participantes son reusables.

• Inconvenientes: el acceso a la relación es lento (indirecto), es

susceptible a la existencia de referencias perdidas (en el borrado de objetos participantes en una relación).

17 Abreviatura de la técnica que se utilizará en las tablas de esta sección. Para cada técnica se utiliza una abreviatura.

- 37 -

2.4.1.3. Primitivas Empotradas

La idea básica de esta técnica (Prim.) [AGO91, BSC96, DPW93, ER97, Rum87] consiste en proporcionar constructores para los lenguajes de programación OO, de forma que sea posible declarar y especificar explícitamente relaciones específicas. Basándose en estas especificaciones, el sistema subyacente implementa y mantiene automáticamente la semántica de las relaciones especificadas. Esta aproximación asume que existe un constructor en el lenguaje de programación para todas las relaciones. Este constructor se puede utilizar como un patrón para declarar la semántica común de las relaciones específicas. La semántica declarada incluye el grado de la relación, las clases participantes, multiplicidad, atributos de la relación, restricciones de dependencia de existencia (borrado por defecto, en cascada y restrictivo). El sistema posteriormente transforma la semántica de la relación especificada en una implementación interna de objetos relación. A continuación se presentan las ventajas e inconvenientes de esta técnica:

• Ventajas: la estructura y el comportamiento de la relación está centralizado en una sola clase, las relaciones son reusables.

• Inconvenientes: existe semántica que no puede ser capturada a

través de estos constructores. 2.4.1.4. Clases Parametrizadas

Esta técnica (C.P.) [RHS95, KP97] propone la utilización de plantillas para la definición de la estructura y comportamiento común de relaciones. Estas plantillas se instanciarán posteriormente por clases que implementen relaciones específicas. La aproximación propone definir plantillas para distintos tipos de relaciones, de forma que cada una abstraiga la estructura y el comportamiento de las relaciones específicas de dicho tipo. A continuación se presentan las ventajas e inconvenientes de esta técnica:

• Ventajas: las relaciones son reusables

• Inconvenientes: no permite tratar con propiedades a nivel de clase, no todos los lenguajes soportan la definición de plantillas.

2.4.1.5. Metaclases

Esta técnica (Meta.) [DCH01, DP94] consiste en definir la semántica de una relación en una estructura de metaclases que permite definir y consultar la relación a nivel de clase, creando y borrando instancias de las clases participantes. Las clases de la aplicación involucradas en una relación son instancias de las metaclases que representan la relación. El diseñador de la aplicación declara la semántica deseada eligiendo los valores adecuados para las diferentes características de la relación y para los parámetros de los métodos suministrados por la metaclase. El sistema automáticamente garantiza el cumplimiento de la especificación elegida. Las ventajas e inconvenientes de esta técnica son los siguientes:

- 38 -

• Ventajas: las relaciones son reusables, facilita el mantenimiento de la consistencia, satisface la dinamicidad de las relaciones.

• Inconvenientes: la propuesta es difícil de implementar, los

programadores deben trabajar con varios niveles de abstracción (instancias, clases y metaclases), los lenguajes de programación “industriales” no las soportan.

2.4.1.6. Análisis de las Técnicas de Implementación

Una vez presentadas las técnicas de implementación para la asociación, la representación software que propone cada una de ellas se analiza en función de:

• Cumplimiento de los requisitos intrínsecos de una asociación. Estos requisitos son:

Dinamicidad: las relaciones deben ser creadas, modificadas,

borradas dinámicamente sin interferir en la estructura y comportamiento de las clases participantes.

Mantenimiento de la Dependencia Existencial: asegurar el

cumplimiento de la integridad referencial (evitar la pérdida de referencias en el borrado de objetos).

En la tabla 2.2 se puede ver para cada técnica si satisface los requisitos.

Requisitos/Aproximaciones Refe. O.R. Prim. C.P. Meta

Dinamicidad Bajo Alto Alto Bajo Alto Mantenimiento Dependencia Existencial Medio Bajo Alto Alto Alto

Tabla 2.2: Requisitos que cumplen las técnicas de implementación.

• Cumplimiento de criterios de calidad18:

Coste de implementación: en tiempo y espacio. Se pretende obtener una implementación lo menos costosa posible (en tiempo de desarrollo y código utilizado).

Reusabilidad de Clases: la implementación de las clases del

dominio participantes en una relación deben ser independientes de la relación, lo que facilita su reusabilidad.

Minimización de Código Duplicado para las Relaciones

(Relaciones Reusables): la implementación de comportamiento y propiedades común de las relaciones no debe duplicarse.

18 Se han seleccionado los criterios de calidad de software más utilizados para la implementación de las relaciones.

- 39 -

Extensibilidad: la implementación propuesta debe ser extensible para abarcar cualquier tipo nuevo de relación o propiedad que aparezca.

Mantenimiento: la implementación debe reflejar las relaciones

especificadas en el análisis de forma simple y directa, para facilitar el mantenimiento del código. Por ejemplo centralizando la estructura y el comportamiento de la relación, diseñando las clases participantes simples, facilitando la inserción, borrado y modificación de enlaces,...

Coste en Tiempo de Ejecución:

o Coste Temporal: es deseable que la implementación

proporcione tiempos de ejecución óptimos.

o Coste Espacial: es deseable que en ejecución se optimice la utilización de la memoria.

En la tabla 2.3 se analiza para cada técnica cuáles son los criterios de calidad que cumplen. Como se observa ninguna de las técnicas combina adecuadamente todos los criterios de calidad considerados.

Criterios de Calidad/Aproximaciones Refe. O.R. Prim. C.P. Meta

Coste de Implementación Bajo Bajo Alto Bajo Bajo Reusabilidad de clases Bajo Alto Alto Alto Alto Relaciones Reusables Bajo Medio Alto Alto Alto Extensibilidad Bajo Alto Bajo Alto Bajo Mantenimiento Bajo Alto Alto Alto Bajo Coste Temporal en Ejecución Alto Bajo Alto Alto Alto Coste Espacial en Ejecución Bajo Alto Alto Alto Alto

Tabla 2.3: Criterios de Calidad satisfechos por las técnicas de implementación.

A través de este análisis se deduce que las técnicas existentes en general presentan los siguientes problemas:

• no satisfacen los requisitos de las asociaciones (tabla 2.2) y • no cumplen los criterios de calidad (tabla 2.3).

La aproximación propuesta en la tesis pretende dar solución a estos

problemas, de tal manera que la solución software propuesta cumpla los requisitos intrínsecos de las relaciones, y que sea sencilla, con elementos reusables y de fácil mantenimiento. Además la solución debe permitir representar las asociaciones y las propiedades introducidas en los siguientes capítulos de forma natural, sin introducir elementos software artificiales. 2.4.2. Patrones de Diseño

Además de las aproximaciones vistas en el apartado anterior, en el mundo de los patrones de diseño se están desarrollando diversas

- 40 -

propuestas que intentan representar los distintos patrones conceptuales mediante estructuras de diseño independientes del lenguaje de programación. Los patrones de diseño constituyen en el ámbito de esta tesis, una herramienta esencial para la implementación de la asociación.

Los patrones de diseño son patrones software, aplicables en las fases de

diseño, que describen una estructura común de componentes que se comunican para resolver problemas generales de diseño en un contexto particular.

Los patrones de diseño se agrupan en lo que se denomina catálogo de

patrones. Estos catálogos pretenden ayudar al diseñador inexperto a adquirir las habilidades de los diseñadores expertos. Actualmente existen varios catálogos de patrones. La elección de alguno de ellos depende del conocimiento completo de los patrones. El catálogo de patrones más famoso es el propuesto en el libro de Gamma et al. [GAM94].

En la actualidad existen diversos trabajos que utilizan los patrones de

diseño para obtener implementaciones de calidad. Es el caso de Pelechano en [Pele01], donde se proporciona una implementación para las relaciones taxonómicas basada en diversos patrones de diseño.

A continuación se revisan algunos patrones relacionados con el trabajo desarrollado en la tesis.

En el libro de Fowler [FWL97] se presenta una primera introducción a las técnicas comúnmente utilizadas en la implementación de patrones conceptuales como la especialización, la asociación y la agregación. El patrón “Decorator” resuelve la necesidad de asociar responsabilidades adicionales a un objeto de forma dinámica. Esto se consigue “envolviendo” (mediante agregación) el objeto (el decorado) con un nuevo objeto (el decorador) que le proporciona las nuevas responsabilidades. Este patrón puede servir para implementar los objetos participantes en una relación, de forma que el comportamiento adicional de los objetos por participar en una relación se implemente en una clase envolvente.

En la aproximación que se presenta en la tesis se incorporan otros

patrones de diseño propuestos por Gamma et al. en [GAM94]: el patrón “Mediator” y el patrón “Template Method”. El patrón “Mediator” define una clase mediadora que encapsula la interacción de un conjunto de objetos de clases colega. Esta estructura se puede utilizar para representar los enlaces entre objetos como instancias de una clase mediadora que encapsula la interacción de objetos asociados. Por otro lado el patrón “Template Method” permite definir métodos plantilla que especifiquen estrategias de ejecución comunes, lo cual será utilizado en nuestro caso para reutilizar el comportamiento de las asociaciones, por ejemplo en la inserción y borrado de enlaces.

- 41 -

2.5. Conclusiones

En este capítulo se han presentado diversos lenguajes y métodos de modelado conceptual OO que proponen semánticas particulares para la asociación. Esta semántica es próxima para propuestas con filosofías similares como es el caso de UML, Syntropy o Catalysis, mientras que otras propuestas como el lenguaje OML presentan importantes diferencias en la semántica definida. Además de las definiciones que proporcionan estos lenguajes y métodos, se han presentado otros trabajos que estudian la asociación identificando sus propiedades estructurales y de comportamiento. Estos trabajos presentan importantes diferencias tanto en la terminología utilizada en las propiedades como en la interpretación semántica que se les da. La propuesta de la tesis define la semántica de la asociación utilizando como punto de partida la propuesta de UML. A partir de las definiciones básicas de UML, se utilizan algunos de los trabajos existentes para seleccionar un conjunto de propiedades de la asociación que permitan caracterizarla.

El análisis de las técnicas de implementación para la asociación pone de

relevancia las deficiencias que presentan las técnicas de implementación actuales: son técnicas que no dan soporte a las restricciones implícitas de las asociaciones, y no cumplen la mayoría de los criterios de calidad del software. La presente tesis pretende cubrir estas necesidades proponiendo una implementación para las asociaciones basada en el uso de patrones de diseño. Los patrones de diseño son patrones software que facilitan el diseño de sistemas aportando soluciones probadas a problemas concretos. La utilización de patrones de diseño en la implementación propuesta en la tesis permite mejorar la calidad del software obtenido.

En el contexto del DDM se han presentado algunas de las técnicas

existentes para definir transformaciones entre modelos. Aunque actualmente este campo no ha alcanzado un nivel de madurez suficiente, están apareciendo numerosas técnicas que permiten llevar a cabo de forma automática la transformación entre modelos.

42

Capítulo 3 Un Marco Conceptual para el Modelado de la Asociación

Este capítulo presenta un marco conceptual que identifica un conjunto de propiedades que permiten caracterizar las asociaciones de forma precisa. Las propiedades del marco se seleccionan de entre propiedades identificadas en distintos trabajos de la literatura que estudian la asociación y sus características. Para seleccionar las propiedades se hace uso de un conjunto de características derivadas de criterios de calidad de modelos, que pueden aplicarse para evaluar las propiedades de la asociación. El marco facilita la construcción de un modelo de asociación expresivo a partir del cual obtener de forma sistemática su representación software.

3.1. Introducción

Algunas de las aproximaciones que estudian las asociaciones en el modelado conceptual, identifican propiedades que se utilizan para definir y caracterizar las asociaciones. Entre las propiedades identificadas en los distintos trabajos existen numerosas diferencias, respecto tanto a la terminología utilizada como a la semántica propuesta. Estas diferencias explicitan una falta de consenso que dificulta la definición de una visión unificada de la asociación.

Este capítulo pretende recopilar las diferentes aproximaciones,

proponiendo un marco conceptual que identifique un conjunto de propiedades, de entre las introducidas por las aproximaciones existentes, que permita caracterizar las asociaciones de forma precisa. Estas propiedades deben cumplir un conjunto de criterios de calidad que garanticen su uso claro, conciso y correcto en modelos conceptuales.

En el contexto de la tesis, el marco conceptual va a permitir: 1) definir un modelo ejecutable19 de calidad para la asociación, 2) definir una guía metodológica para el modelado de la asociación y, 3) proponer una solución de calidad para la implementación de las

asociaciones. Además, la construcción de un marco conceptual de estas características

permitiría comparar modelos de asociaciones (expresividad, aplicabilidad,...), y detectar carencias y ambigüedades en modelos de asociaciones existentes.

19 Entendiendo como modelo ejecutable aquél para el cual es posible definir correspondencias a sentencias de código ejecutable para todos sus elementos.

43

Para construir el marco conceptual se han llevado a cabo los siguientes pasos:

1. Identificar las propiedades utilizadas en las aproximaciones existentes. 2. Clasificar las propiedades en diferentes categorías. 3. Seleccionar para cada categoría, aquellas propiedades que constituirán el marco conceptual.

A continuación se presentan cada uno de los pasos llevados a cabo. Una vez presentados, se introduce la descripción detallada de las propiedades que constituyen el marco conceptual. 3.2. Identificación de Propiedades En este apartado se recopilan las propiedades de la asociación presentes en la literatura.

[OP

NR

L]

Mo

delo

s ER

[SA

K9

8]

[SN

K9

8]

[OLV

L]

[CV

L9

3]

[OD

L9

4]

UM

L

SY

NTR

OP

Y

CA

TA

LY

SIS

Multiplicidad √ √ √ √ √ Opcionalidad √ √ √

Compartición √ √ √ √

Modificabilidad √

Separibilidad √ √ √

Mutabilidad √ √ √

Estaticidad/ Dinamicidad √ √ Dependencia Existencial √ √

Conexión entre ciclos de vida √ √

Propagación de Borrado √

Reflexividad √ √ √

Simetría √ √ √

Transitividad √

Visibilidad √ √

Encapsulación √

Navegabilidad √ √ Pertenencia √ √

Mecanismos de Identificación √ √ √

Parte_De √ √

Homogeneidad √ √

Configurabilidad √ √

Propiedad Emergente √ √

Propiedad Resultante √ √

Tabla 3.1. Propiedades que aparecen en las distintas aproximaciones

44

Tras el análisis del estado del arte realizado en el capítulo anterior, se identifican las propiedades que aparecen en las aproximaciones que estudian la asociación en el área del modelado conceptual OO. La tabla 3.1 muestra las propiedades identificadas, indicando (con el símbolo ‘√’) qué propiedades (filas) aparecen en las distintas aproximaciones (columnas). 3.3. Categorización de Propiedades

Una vez identificadas las propiedades, éstas se clasifican en diferentes categorías. La categorización de las propiedades permite estructurar el análisis de éstas, facilitando el proceso de selección.

La categorización se realiza en función de diversos criterios: como la

estaticidad o dinamicidad, el tipo de estructura o comportamiento afectado, o el tipo de restricción asociada. La categorización agrupa las propiedades en seis categorías:

• Restricción de Cardinalidad. Propiedades relacionadas con la restricción en el número mínimo y máximo de enlaces20 de los objetos participantes21.

• Accesibilidad. Propiedades que definen la alcanzabilidad sobre los

objetos participantes.

• Identidad. Propiedades que definen el modo de identificación de los objetos participantes.

• Estructurales. Propiedades que definen características sobre la

constitución de los enlaces.

• Dinámicas. Propiedades que modelan características temporales de las relaciones. Las propiedades dinámicas permiten caracterizar el comportamiento de los enlaces y de los objetos participantes respecto al tiempo.

• Restricciones de Enlaces entre Objetos. Propiedades relacionadas

con la restricción de enlaces entre objetos.

En la tabla 3.2 se pueden ver las propiedades según la clasificación propuesta.

En el siguiente apartado se analizan las propiedades de las distintas

categorías. Para ello, en primer lugar, se identifican los criterios de calidad que se aplicarán sobre las propiedades, y a continuación, se seleccionan aquellas propiedades suficientes para especificar la característica de la asociación que representa la categoría y que cumplen los criterios de calidad. Con esto se evita sobre-expresividad en el modelo, y se consigue

20 Un enlace es una instancia de una asociación. 21 Llamamos objetos participantes a los objetos que participan en un enlace.

45

unificar propiedades con significados similares que utilizan distintos términos para nombrarlas.

Restricciones de Cardinalidad

Multiplicidad Opcionalidad Compartición

Accesibilidad

Visibilidad Encapsulación Navegabilidad Pertenencia Identidad

Proyección de Identificación Estructurales

“Parte_de” Homogeneidad Configurabilidad

Propiedad Emergente Propiedad Resultante

Dinámicas

Modificabilidad Separabilidad Mutabilidad

Estaticidad/Dinamicidad Dependencia Existencial

Conexión entre ciclos de vida Propagación de Borrado

Restricciones entre objetos

Reflexividad Simetría

Transitividad

Tabla 3.2. Categorización de las propiedades 3.4. Selección de Propiedades

Una vez se ha definido la categorización, en este apartado se seleccionan las propiedades que constituyen el marco conceptual. La selección de las propiedades requiere un análisis en el que se llevan a cabo las siguientes tareas:

• evaluación de las propiedades de la asociación aplicando un conjunto de criterios de calidad. Estos criterios se derivan de las características de calidad publicadas en distintos trabajos del ámbito del modelado conceptual. Estos criterios están orientados a facilitar la construcción de modelos conceptuales expresivos, involucrados en procesos de desarrollo automático de software,

46

• identificación de las propiedades que representan características de la asociación similares o idénticas, de forma que sea posible definir el conjunto mínimo de propiedades que permite especificar una característica.

A partir de este estudio, la selección de las propiedades se realiza aplicando las siguientes directrices:

• se excluyen las propiedades que no cumplen los criterios de calidad,

• se seleccionan, entre las propiedades que cumplen los criterios de calidad, las propiedades suficientes para especificar las características asociadas a cada categoría.

En el siguiente subapartado se identifican los criterios de calidad para la evaluación de las propiedades. Posteriormente, se analizan las propiedades, seleccionando aquéllas que van a constituir el marco conceptual. 3.4.1. Criterios de Calidad

En esta sección se identifican los criterios de calidad utilizados para evaluar las propiedades de la asociación.

En el ámbito de la calidad de modelos conceptuales, se han desarrollado

diversos trabajos que proponen criterios u objetivos para alcanzar la calidad en los modelos conceptuales [SR98, MS03, LSS94]. Sin embargo, a pesar de estos trabajos, es difícil encontrar un estándar que determine de forma clara y consensuada cuáles son las propiedades que debe satisfacer un modelo conceptual para ser considerado de calidad. A continuación se presentan criterios de calidad identificados por distintos autores.

Daniel L. Moody et al. en [MS03] identifican seis factores de calidad para modelos ER. Estos factores son: Completitud: capacidad del modelo de incluir todos los requisitos de usuario; Simplicidad: el modelo debe contener el mínimo número de entidades y relaciones; Flexibilidad: facilidad con que el modelo puede adaptarse a cambios de negocio; Integración: consistencia del modelo con el resto de la organización; Comprensión: facilidad con que las estructuras y conceptos del modelo pueden entenderse; Implementabilidad: facilidad con que el modelo puede implementarse dentro de las restricciones de tiempo, presupuesto y tecnología del proyecto.

Lindland et al. en [LSS94], estudian diversos trabajos que intentan

definir la calidad en los modelos conceptuales, proponiendo un marco que, además de identificar los objetivos de calidad más relevantes en modelos conceptuales, propone las pautas que se deben seguir para alcanzarlos. Los principales objetivos de calidad identificados en este trabajo se agrupan en tres tipos de calidad:

• Calidad Sintáctica (referente a la adecuación del modelo al lenguaje

de modelado):

47

o Corrección Sintáctica: adecuación del modelo a las reglas del lenguaje

• Calidad Semántica (referente a la adecuación del modelo al dominio):

o Validez Factible: todas las afirmaciones del modelo deben ser correctas y relevantes al problema.

o Completitud Factible: el modelo contiene todas las afirmaciones sobre el dominio que son correctas y relevantes.

• Calidad Pragmática (referente a la adecuación del modelo a la

interpretación de la audiencia): o Comprensión Factible: el modelo debe ser entendible.

Schuette y Rotthowe en [SR98], proponen unas guías de modelado

(“The Guidelines of Modeling (GoM)”) que contienen seis principios para mejorar la calidad de los modelos. Estos principios son:

• Adecuación de la construcción: consenso sobre el modelo

representado y consenso sobre la representación utilizada (principio de minimalismo).

• Adecuación del lenguaje: interrelación entre el sistema modelado y el lenguaje utilizado.

• Eficiencia económica: restricción económica • Claridad: comprensibilidad y realidad explicitada de los modelos • Diseño Sistemático: consistencia entre modelos estructurales y de

comportamiento • Comparabilidad: el contenido de dos modelos debería compararse

respecto a su correspondencia y similitud. Selic en [SEL03], en el ámbito del DDM, realiza un breve análisis de la

calidad de modelos, destacando que para que un modelo sea de calidad debe ser: Abstracto: se enfatizan los elementos importantes y se ocultan los irrelevantes; Comprensible: fácil de entender por los observadores; Preciso: se representa de forma fiel el sistema que se modela; y Económico: un modelo debe ser más económico y sencillo que el coste de construir el propio sistema.

Además de los criterios de calidad que identifican los distintos autores estudiados, es necesario tener en cuenta que en el ámbito del DDM deseamos construir un modelo ejecutable. Por ello, consideramos la ejecutabilidad un criterio de calidad adicional para nuestro modelo.

Tomando como punto de referencia los criterios de calidad para modelos

conceptuales identificados por los diversos autores estudiados, se pueden extraer tres criterios aplicables en la evaluación de las propiedades de la asociación que incluyen de forma sintetizada los demás criterios. Estos criterios son:

o Precisión: las propiedades deben capturar semántica del dominio no

ambigua y definirla de forma clara.

48

o Implementabilidad: las propiedades deben capturar semántica del dominio con representación en la implementación de la asociación.

o Usabilidad: la semántica de las propiedades debe ser

suficientemente intuitiva para que el modelador pueda utilizarlas con facilidad.

En la figura 3.1 se muestra gráficamente los criterios de calidad

subsumidos por los tres criterios seleccionados (P=Precisión, I=Implementabilidad y U=Usabilidad).

Figura 3.1. Representación gráfica de los criterios de calidad englobados en las

propiedades de calidad seleccionadas En los siguientes subapartados las propiedades de la asociación se

analizan en función de estos criterios. Para cada categoría de propiedades se muestra una tabla indicando el grado de satisfacción de cada criterio por parte de las propiedades. La tabla 3.3 muestra los posibles grados de satisfacción de los tres criterios identificados. La escala incluye los valores Alto (si se cumple completamente el criterio), Medio (si se cumple el criterio parcialmente) y Bajo (si no se cumple el criterio).

Grado de Satisfacción + -

Implementabilidad Alto Bajo Precisión Alto Medio Bajo Usabilidad Alto Medio Bajo

Tabla 3.3. Grados de satisfacción de los criterios de calidad

I

P

U

comprensible

económico

abstracto preciso comprensión factible

completitud semántica

ejecutable

implementabilidad

completitudsimplicidad

flexibilidad

integración

adecuación de la construcciónadecuación del lenguaje

diseño sistemáticovalidez semántica

corrección sintáctica

claridad

eficiencia económica

49

3.4.2. Propiedades de Restricción de Cardinalidad

El término cardinalidad define el número de elementos existentes en un conjunto. En los modelos ER la cardinalidad es una propiedad de las ocurrencias de una entidad que participa en una relación [REF]. Esta propiedad especifica con cuántas ocurrencias de la entidad relacionada se pueden y/o se deben relacionar. Paralelamente se ha ido utilizando a lo largo de la literatura el término multiplicidad como sinónimo de cardinalidad. En la propuesta de notación UML se especifica que la cardinalidad es el número de elementos de un conjunto y que la multiplicidad especifica el rango de cardinalidades posibles que puede tener un conjunto.

En el contexto de una asociación la multiplicidad determina el rango de cardinalidades permitidas en el conjunto de objetos asociados a otro objeto a través de una relación, por lo que la multiplicidad se especifica en términos de multiplicidad máxima (max) y multiplicidad mínima (min). En una asociación la multiplicidad se define para cada extremo de la relación. La multiplicidad puede tomar un valor entre 0 y n, siendo n un número Natural.

Figura 3.1. Ejemplo de la propiedad multiplicidad en una asociación

Ejemplo 1. Supongamos una asociación como la de la figura 3.122. En

este ejemplo, una clase Publicacion se relaciona con una clase Firmante a través de la relación firmar. En la figura se utiliza la notación UML para representar la asociación y sus multiplicidades. La multiplicidad especificada en el extremo de la clase Publicacion determina el número mínimo y máximo de publicaciones que puede tener asociadas un firmante. En este caso un firmante está asociado siempre a una sola publicación, por lo que la multiplicidad máxima y mínima es 1. De la misma manera la multiplicidad especificada en el extremo de la clase Firmante determina el número mínimo y máximo de firmantes que puede tener asociados una publicación. En este caso una publicación tendrá como mínimo 1 firmante y no tiene límite máximo (representado gráficamente por el símbolo ’*’).

En la literatura OO aparecen algunas propuestas que utilizan términos diferentes para representar restricciones de cardinalidad. Es el caso de la propiedad opcionalidad (“Optionality”). La opcionalidad determina si la relación es obligatoria u opcional. En este caso la propiedad hace referencia al número mínimo de enlaces que debe tener un objeto; si puede ser 0, opcional, o debe ser mayor de 0, obligatorio. En el ejemplo de la figura 3.1 la relación es obligatoria en ambos sentidos. La opcionalidad puede considerarse un caso particular de la multiplicidad puesto que equivale a la multiplicidad mínima, restringiendo los valores posibles a 0 o mayor que 0.

22 Por simplicidad en las figuras del capítulo se omiten las propiedades de la asociación que no son relevantes para el contexto en el que se presenta la figura.

50

Shaksena et al. identifican en [SAK98] la propiedad compartición (“Homogeneous Sharing”) como una propiedad secundaria de la agregación, al igual que Sellers et al. en [WHT99] donde la identifican como “Local Sharing”. En [SAK99] se especifica que “la compartición de partes ocurre cuando una parte está asociada a más de un todo en el mismo instante de tiempo”. La propiedad hace referencia al número máximo de objetos con los que puede relacionarse otro objeto a través de una asociación; si es mayor que 1 existe compartición y si es 1 no existe compartición. En el ejemplo de la figura 3.1 existe compartición de publicaciones, pero no de firmantes. La compartición es un caso particular de la multiplicidad puesto que equivale a la multiplicidad máxima, teniendo limitados los valores posibles a 1 o mayor que 1.

Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Multiplicidad Alto Alto Alto Opcionalidad/Obligatoriedad Alto Alto Alto Comparticion Alto Alto Alto

Tabla 3.4. Análisis de las propiedades de restricción de cardinalidad En la tabla 3.4 se muestra la relación entre las propiedades identificadas

y los criterios de calidad propuestos. Las tres propiedades se pueden representar como restricciones en la implementación de la asociación, por lo que cumplen el criterio de Implementabilidad. La semántica de las tres propiedades cumple el criterio de Precisión, puesto que poseen una interpretación única. Las tres propiedades se especifican de forma intuitiva y son bien conocidas por los modeladores, por lo que cumplen el criterio de Usabilidad.

Tras este análisis, se considera que la propiedad multiplicidad es

suficiente para especificar las restricciones de cardinalidad de la asociación, siendo la opcionalidad y la compartición casos particulares de ésta. Por ello, en el marco conceptual únicamente se incluye la propiedad multiplicidad. 3.4.3. Propiedades Dinámicas

Un factor importante para la caracterización de la asociación es el tiempo. Las características de la asociación relacionadas con este factor, permiten especificar una serie de restricciones dinámicas que caracterizan el comportamiento de los objetos participantes respecto al tiempo. A estas características las llamamos propiedades dinámicas.

Las propiedades tratadas en este apartado, son aquellas que pueden

especificarse en modelos conceptuales no temporales. Las propiedades que requieren la representación de la dimensión temporal en la definición del estado del sistema, las consideramos fuera del ámbito de estudio de la tesis.

Las propiedades dinámicas estudiadas en este apartado son las

relacionadas con la:

51

o Creación, Destrucción y Modificación de Enlaces: durante la vida de un objeto participante en un enlace, es necesario especificar si es posible crear, destruir o modificar el enlace.

o Dependencia entre ciclos de vida de objetos participantes: entre

los ciclos de vida de los objetos participantes en un enlace pueden existir diversas dependencias que determinan la relación entre el comienzo y/o final de vida de los objetos participantes.

3.4.3.1. Creación, Destrucción y Modificación de Enlaces

En UML las asociaciones poseen una propiedad dinámica que permite especificar la posibilidad de crear o destruir enlaces durante la vida de los objetos participantes. Esta propiedad es la modificabilidad (“changeabilityKind”) ([UMLI2.0] pág. 43). La modificabilidad es una característica de los extremos de una asociación (heredada de la clase “StructuralFeature”) que determina si objetos del extremo opuesto ya inicializados pueden crear o destruir enlaces con objetos del extremo. Los posibles valores que puede tomar la propiedad son:

• “unrestricted”, se pueden crear o destruir enlaces sin restricciones

• “readOnly”, no se pueden crear ni destruir enlaces desde objetos ya inicializados (sólo es posible durante la creación de objetos)

• “addOnly”, no se pueden destruir enlaces desde objetos ya

inicializados (sólo crear)

• “removeOnly”, no se pueden crear enlaces desde objetos ya inicializados (sólo destruir)

Figura 3.2. Ejemplo de la propiedad “changeabilityKind” de UML

Ejemplo 2. Supongamos una relación como la de la figura 3.2, donde

existe una relación fundar entre las clases Compañía y Miembro. El extremo de la clase Compañía tiene el valor “unrestricted”, porque un miembro durante su vida puede fundar otras compañías o una compañía que fundó un miembro puede destruirse. En el extremo de la clase Miembro el valor de la modificabilidad es “readOnly”, porque una compañía no puede añadir o eliminar miembros fundadores una vez ha sido creada.

Otros autores como Sellers en [WHT99], Odell en [ODL94] y Civello en [CVL93] identifican la separabilidad (“separability”) como propiedad secundaria de la agregación. En estos trabajos esta propiedad determina “si las partes pueden ser o no separadas del todo”, es decir, la separabilidad especifica si un enlace entre parte y todo puede ser destruido durante la vida de la parte.

52

Figura 3.3. Agregación entre las clases Coche y Rueda

Figura 3.4. Agregación entre las clases Coche y Chasis

Ejemplo 3. Supongamos la relación de agregación de la figura 3.3 entre

una clase agregada Coche y la clase Rueda. En la figura se utiliza la notación UML para representar la agregación, representada gráficamente a través de un rombo en el extremo de la clase agregada. En este ejemplo la relación es separable, puesto que durante la vida de una rueda es posible eliminar la relación con el coche. Por el contrario, en el ejemplo de la figura 3.4, donde existe una relación de agregación entre una clase agregada Coche y una clase Chasis, la relación es inseparable, puesto que durante la vida de un chasis no se puede eliminar su relación con el coche.

La separabilidad puede expresarse a través de la modificabilidad y la multiplicidad. Que una parte sea inseparable de su todo significa que:

o la parte siempre tiene que estar asociada a un todo, lo cual se puede expresar con la multiplicidad mínima en el extremo del todo, estableciendo su valor a 1, y

o la parte no puede destruir su relación con el todo, lo cual se puede expresar a través de la modificabilidad en el extremo del todo, con los valores “addOnly” o “readOnly”.

Además de la separabilidad, Sellers y Civello en [WHT99] y [CVL93]

identifican la mutabilidad (“mutability”) como propiedad de las agregaciones. La mutabilidad está relacionada con la posibilidad de modificar enlaces durante la vida de las partes. En [WHT99] se define que una parte mutable “puede ser cambiada por un objeto equivalente (un objeto con diferente identidad pero de la misma clase)”. La mutabilidad especifica si un enlace se puede modificar sustituyendo un objeto parte por otro. Esta propiedad no es posible modelarla en UML.

Figura 3.5. Agregación entre las clases Barco y Patrón

Ejemplo 4. En el ejemplo de la figura 3.5 la clase Barco se relaciona con

la clase Patrón a través de la relación patronear. Cada patrón puede, como máximo, patronear un barco. Un barco siempre debe estar patroneado por un solo patrón, por lo que no se le pueden añadir ni eliminar enlaces con

53

patrones. Sin embargo, sí es posible sustituir el patrón del barco por otro, por lo que la relación es mutable.

En el modelo ER se puede determinar si es posible crear o destruir ocurrencias de una relación durante la vida de las ocurrencias participantes a través de la propiedad de las asociaciones que determina si una relación (no los extremos) es Estática o Dinámica. Una relación estática indica que no se pueden crear, destruir, ni modificar ocurrencias de la relación durante la vida de las ocurrencias participantes (sólo es posible en el momento de la creación de éstas últimas). En una relación dinámica sí se pueden crear, destruir o modificar ocurrencias de la relación durante la vida de las ocurrencias participantes. Esta propiedad del modelo ER, es un caso particular de la modificabilidad de UML, junto con la mutabilidad que especifica si es posible modificar enlaces. Mientras que la propiedad del modelo ER se define sobre la relación, la propiedad la modificabilidad y la mutabilidad se definen para cada una de las clases participantes. Cuando en las dos clases participantes el valor de la modificabilidad y la mutabilidad es el mismo, el significado es equivalente al de la propiedad del modelo ER. El caso en el que las clases participantes tienen valores de modificabilidad y/o mutabilidad diferentes no es posible expresarlo en el modelo ER. Propiedad / Criterio Calidad Implementabilidad Presición Usabilidad

Modificabilidad Alto Alto Alto Separabilidad Alto Medio Medio Mutabilidad Alto Alto Medio Estaticidad/Dinamicidad Alto Alto Alto

Tabla 3.5. Análisis de las propiedades dinámicas

En la tabla 3.5 se puede observar que las propiedades estudiadas satisfacen los criterios de calidad. Las cuatro propiedades se pueden representar en la implementación de la asociación como restricciones dinámicas, por lo que cumplen el criterio de Implementabilidad. La interpretación de las propiedades es única, cumpliendo el criterio de Precisión. Respecto a la Usabilidad, las cuatro propiedades son suficientemente sencillas, aunque la separabilidad y la mutabilidad, no son tan intuitivas como las demás. No obstante, la semántica de estas propiedades se solapa. Para evitar sobre-expresividad en nuestro marco, es necesario determinar la semántica común de todas las propiedades y definir un conjunto mínimo de propiedades que permitan especificarla.

Tras el análisis de las propiedades presentadas, se puede concluir que es

necesario especificar el siguiente comportamiento para los extremos de una asociación:

1. si se pueden crear y destruir enlaces durante la vida de los objetos, teniendo para ello las siguientes posibilidades: a) no existen restricciones para ello, b) no se pueden ni crear ni destruir enlaces una vez creado el objeto, c) no se pueden destruir enlaces una vez creado el objeto, d) no se pueden crear enlaces una vez creado el objeto.

54

Para especificar este comportamiento, se utilizará una propiedad a la que llamaremos dinamicidad con cuatro valores.

2. si se pueden o no modificar los enlaces sustituyendo un objeto asociado por otro de su misma clase. Para especificar este comportamiento se utilizará la propiedad mutabilidad.

Concluimos que la dinamicidad y la mutabilidad son propiedades

suficientes para especificar el comportamiento de la asociación analizado, por lo que únicamente van a formar parte del marco conceptual estas dos propiedades. En [OLVL], Olivé presenta un detallado estudio de las propiedades temporales de la asociación. En dicho estudio se utilizan modelos temporales. Puesto que en el contexto de trabajo de la tesis se utilizan modelos no temporales, no es posible definir las restricciones temporales que definen las propiedades identificadas por Olivé. Sin embargo, existen vías alternativas para definir algunas de estas restricciones:

• La propiedad permanencia (una relación es permanente si una vez se

crea una instancia ésta perdura hasta el final de vida del sistema) se puede representar parcialmente a través de la propiedad dinamicidad introducida en el marco conceptual. Si los dos extremos de la relación se definen estáticos o incrementables (no es posible destruir un enlace durante la vida de los objetos participantes), garantizamos que la relación existe mientras existen los participantes.

• La propiedad participación inicial de un participante en un tipo

relación (esta propiedad define si los objetos de una clase, cuando inician el intervalo de clasificación, deben participar o no en algún enlace de la relación, jugando un determinado rol) se puede representar parcialmente a través de la propiedad multiplicidad mínima. Con la multiplicidad mínima es posible representar si es obligatorio u opcional que al crear un objeto de una clase éste deba asociarse con otro objeto de su clase asociada.

• La propiedad intervalo de existencia en un participante (esta

propiedad indica si un participante siempre forma parte de una instancia de una relación a partir de la primera vez que forma parte de alguna instancia) se puede representar parcialmente a través de la propiedad multiplicidad mínima. Con la multiplicidad mínima es posible representar si el intervalo de existencia de un participante es único permanente o no.

• La propiedad mutabilidad respecto de un participante (esta propiedad

determina si un objeto puede cambiar su participación en un enlace por su participación en otro enlace) se puede representar parcialmente a través de la propiedad mutabilidad introducida en el marco conceptual. Los valores inmutabilidad absoluta y mutabilidad introducidos por Olivé se representan a través de los valores no mutable y mutable.

55

• La propiedad capacidad de inserción respecto de un participante (esta propiedad determina si es posible insertar nuevos enlaces donde participen objetos de una clase jugando un determinado rol) se puede representar parcialmente a través de la propiedad dinamicidad introducida. La relación es insertable respecto a una clase si es posible crear enlaces durante la vida de los objetos de la clase. En otro caso, la relación es no insertable respecto a la clase.

3.4.3.2. Dependencias entre ciclos de vida.

La dependencia entre los ciclos de vida de objetos participantes determina la relación temporal entre los momentos de nacimiento y de destrucción de éstos. A continuación se presentan algunas de las propiedades más relevantes que tratan este aspecto de las asociaciones.

Sellers en [WHT99] presenta un estudio de la dependencia entre los

ciclos de vida de objetos relacionados en el contexto de una relación de agregación, haciéndose eco del estudio realizado por Saksena en [SAK98]. A la dependencia entre los ciclos de vida de los objetos se le denomina en [WHT99] “lifetime linkage” o “lifetime dependency”. Sellers detecta las diferentes dependencias que se pueden dar entre el ciclo de vida de una parte y el ciclo de vida de su/s todo/s, identificando las posibles relaciones temporales entre el momento de nacimiento y destrucción de una parte respecto al de su/s todo/s. Se identifican los nueve casos de dependencia que se muestran en la figura 3.6. El cuarto caso, ciclos de vida coincidentes (“coincident lifetimes”), se utiliza en UML para definir la composición. Esta dependencia implica que el ciclo de vida de la parte y el ciclo de vida de su todo deben coincidir en el tiempo, es decir, que todas las partes de un todo deben nacer y destruirse al mismo tiempo que el todo. Sellers destaca también este caso porque según afirma “es ciertamente una categoría interesante de la agregación”.

56

TodoParte

TodoParte

TodoParte

TodoParte

TodoParte

TodoParte

TodoParte

TodoParte

Sol

pam

ient

o de

l cic

lo d

e vi

da

Ciclo de vida de los objetos

Figura 3.6. Dependencias entre los ciclos de vidas de la parte y el todo

Estos casos de dependencias para agregaciones presentados por Sellers se pueden generalizar para las asociaciones, obteniendo cinco casos de dependencia. La figura 3.7 muestra estos casos. Al igual que los casos anteriores, éstos identifican relaciones temporales entre el momento de nacimiento y destrucción de objetos asociados. Algunas de estas relaciones temporales no se pueden especificar en modelos conceptuales no temporales (puesto que en estos modelos no se registran los instantes de creación y destrucción de objetos, lo cual imposibilita establecer ciertas dependencias entre estos instantes). Sin embargo, sí es posible especificar algunas dependencias que se derivan de estos casos:

1. al crear un objeto, éste debe asociarse a un objeto del extremo opuesto, y 2. un objeto no puede sobrevivir a su objeto asociado, es decir, el instante de destrucción de un objeto no puede ser posterior al de su objeto asociado. El primer caso se puede modelar a través de la Multiplicidad Mínima, con

un valor mayor que 1.

57

objeto aobjeto b

objeto aobjeto b

objeto aobjeto b

objeto aobjeto b

ojbeto aobjeto b

Sol

pam

ient

o de

l cic

lo d

e vi

da

Ciclo de vida de los objetos

Caso 1

Caso 2

Caso 3

Caso 4

Caso 5

Figura 3.7. Dependencias entre los ciclos de vidas de objetos asociados

En el segundo caso es necesario utilizar una propiedad que permita

especificar dicho comportamiento. Esta propiedad podría ser la propagación de destrucción o borrado [WHT99]. La mayoría de los autores estudian esta propiedad al margen de la dependencia entre ciclos de vida, generalmente se estudia como un aspecto de la propagación de operaciones en clases asociadas. La propagación de destrucción implica una dependencia entre los ciclos de vida de objetos asociados, pues supone que el ciclo de vida de un objeto no puede exceder el ciclo de vida de su objeto asociado, es decir, un objeto participante debe destruirse antes que su objeto asociado. La propagación de destrucción o borrado se especifica para cada extremo de la relación y determina si al destruir un objeto de un extremo se destruye/n o no su/s objeto/s asociado/s.

Ejemplo 5. Se tiene un sistema en el que existen tres clases: Miembro, Grupo y Participante (ver figura 3.8). Los grupos están formados por miembros. Un participante puede ser un miembro (no perteneciente a un grupo) o un grupo. Si se destruye un grupo del sistema se deben destruir sus miembros. Esta propiedad de la clase Miembro se podría especificar con la Propagación de Borrado.

58

Figura 3.8. Asociación pertenece entre las clases Grupo y Miembro

Otra propiedad que hace referencia a las dependencias entre ciclos de

vida es la Dependencia Existencial. Snoeck et al. definen esta propiedad en [SNK98]: “A depende existencialmente de B si y sólo si la vida de cada ocurrencia a del tipo A está embebida en la vida de una sola y siempre la misma ocurrencia b del tipo B”. En [SNK98] estos autores presentan esta propiedad como propiedad suficiente para definir los aspectos estructurales y de comportamiento de los diferentes tipos de agregación.

Figura 3.9. Agregación entre las clases Factura y LineaFactura

Ejemplo 6. Supongamos una agregación entre una clase Factura y otra

clase LineaFactura (ver figura 3.9). En este caso una linea_factura siempre debe estar relacionada con una y solo una factura (siempre con la misma), por lo que la clase LineaFactura tiene dependencia existencial respecto a la clase Factura.

La especificación de la agregación a través de la Dependencia Existencial como única propiedad requiere la definición de clases intermediarias en el modelo. Esto dificulta la utilización de la propiedad durante el modelado, por lo que no se incluye en nuestro marco conceptual. La semántica de la Dependencia Existencial de una clase puede capturarse a través de las siguientes propiedades del extremo opuesto a la clase: multiplicidad (min=max=1), la dinamicidad (estática), la mutabilidad (no mutable) y la propagación de borrado (propagación).

Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Dependencia Existencial Alto Alto Bajo Conexión entre ciclos de vida

Alto Alto Bajo

Propagación de Borrado Alto Alto Alto Tabla 3.6. Análisis de las propiedades dinámicas

59

Como muestra la tabla 3.6, únicamente la propiedad Propagación de Borrado satisface todos los criterios de calidad. Las tres propiedades introducidas implican restricciones en la implementación de la asociación, por lo que cumplen el criterio de Implementabilidad. El criterio de Precisión también se cumple, puesto que la definición de las tres propiedades sólo acepta una interpretación. Sin embargo, respecto a la Usabilidad, la Dependencia Existencial no cumple el criterio debido a la introducción de clases auxiliares en su especificación, que dificultan la utilización de la propiedad en modelos conceptuales. La conexión entre ciclos de vida tampoco cumple la Usabilidad, puesto que la tarea de especificar las dependencias entre los ciclos de vida de objetos requiere la definición de la dimensión temporal en el modelo.

Tras este análisis, se concluye que únicamente la propiedad Propagación de Borrado se incluye en el marco conceptual. 3.4.4. Propiedades de Restricción de Enlaces

En el contexto de la agregación, Sellers et al. en [WHT99] y Saksena et al. en [SAK98], identifican dos propiedades que restringen los posibles enlaces que pueden instanciar una agregación. Estas dos propiedades pertenecen al conjunto de propiedades primarias de la agregación:

• Antirreflexividad a nivel de instancia: un objeto no puede estar

compuesto de él mismo, y • Antisimetría a nivel de instancia: un objeto no puede estar

compuesto por un objeto del que es a su vez parte. Otra propiedad de este tipo es la transitividad, que aparece en [SAK98,

OMT] como propiedad necesaria de la agregación. La transitividad especifica que: “si un objeto a es parte de un objeto b y el objeto b es parte de un objeto c, entonces el objeto a es parte del objeto c”. Sellers et al. en [WHT99] contradicen la teoría de que la transitividad sea una propiedad necesaria de la agregación, argumentando que no todas las agregaciones cumplen esta propiedad (mi mano es parte de mí (agregación), yo soy parte de mi universidad (agregación), pero mi mano no es parte de mi universidad).

Figura 3.10. Asociación es_padre_de entre la clase Persona consigo misma

Aunque en [SAK98] y [WHT99] se consideran estas propiedades en el

contexto de una relación de agregación, pueden darse también entre asociaciones. Consideremos el caso de una relación es_padre_de (ver figura 3.10) de la clase Persona consigo misma. En este caso el objeto p1 no

60

puede ser_padre_de él mismo (p1), por lo que la asociación es antirreflexiva.

La reflexividad, a nivel de instancia, es una propiedad que puede darse

en relaciones reflexivas. El valor de la propiedad puede ser:

• Reflexiva: un objeto debe relacionarse con él mismo.

• Antirreflexiva: un objeto no puede relacionarse con él mismo.

• No Reflexiva: no existe ninguna restricción de este tipo.

La simetría, a nivel de instancia, es una propiedad de las relaciones reflexivas que puede tomar los valores:

• Simétrica: si a está relacionado a través de r con b, entonces b se relaciona con a a través de r.

Tomemos como ejemplo el caso de una relación casado_con de la

clase Persona consigo misma (ver figura 3.11). Si un objeto persona p1 esta_casado con otro objeto persona p2, necesariamente p2 esta_casado con p1.

Figura 3.11. Asociación casada_con entre la clase Persona consigo misma

• Antisimétrica: si a está relacionado a través de r con b, entonces b no se puede relacionar con a a través de r.

Tomemos como ejemplo el caso de una clase Empleado relacionada con ella misma a través de la relación es_jefe (ver figura 3.12). En este caso si un objeto empleado e1 es_jefe de otro objeto empleado e2, entonces el mismo objeto e2 no puede ser_jefe del objeto e1.

Figura 3.12. Asociación ser_jefe entre la clase Empleado consigo misma

61

• No Simétrica: no existe ninguna restricción de este tipo.

Por ejemplo una relación admirar_a entre una clase Empleado con ella misma (ver figura 3.13). En este caso si el empleado e1 admira_a el empleado e2, no se puede deducir nada acerca de si el empleado e2 admira_a el empleado e1.

Figura 3.13. Asociación admirar_a entre la clase Empleado consigo misma

En la tesis utilizamos la transitividad, a nivel de instancia, únicamente en

el caso de relaciones reflexivas (la transitividad entre varias asociaciones no se incluye por ser una propiedad que caracteriza la relación entre asociaciones, quedando este tipo de propiedades fuera del ámbito de estudio de la tesis). La transitividad puede tomar dos valores:

• Transitiva: si a está relacionado a través de r con b y b está relacionado a través de r con c, entonces a está relacionado a través de r con c.

Supongamos el ejemplo de la figura 3.12. En este caso si el empleado e1 es_jefe del empleado e2, y el empleado e2 es_jefe del empleado e3, entonces el empleado e1 es_jefe del empleado e3, por lo que la relación es transitiva.

• No transitiva: no existe ninguna restricción de este tipo.

En el ejemplo de la figura 3.13 la relación es no transitiva, puesto que no se cumple que si el empleado e1 admira_a el empleado e2, y el empleado e2 admira_a el empleado e3, el empleado e1 admira_a el empleado e3.

Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Reflexividad Alto Alto Medio Simetría Alto Alto Medio Transitividad Alto Alto Medio

Tabla 3.7. Análisis de las propiedades de restricción de enlaces entre objetos

Como muestra la tabla 3.7 todas las propiedades satisfacen los criterios de calidad. Las tres propiedades se pueden representar en la

62

implementación de la asociación como restricciones en la creación, destrucción y modificación de enlaces, cumpliendo el criterio de Implementabilidad. Las tres propiedades se definen sin ambigüedades, por lo que cumplen el criterio de Precisión. La utilización de estas propiedades en el ámbito de funciones y relaciones matemáticas facilita la aplicación de estas propiedades en modelos conceptuales. Sin embargo, su grado de compresión se sitúa un punto por debajo del de otras propiedades como la multiplicidad, la modificabilidad o la propagación de borrado, por lo que calificamos la usabilidad de estas propiedades en su grado medio.

Las propiedades reflexividad, simetría y transitividad se incluyen en el marco conceptual.

3.4.5. Propiedades de Accesibilidad

Una asociación define un camino de acceso entre las clases participantes. A través de la asociación se crea un canal de comunicación entre los objetos de las clases participantes. Existen propiedades de la asociación que permiten especificar características de estos canales de comunicación. A continuación se presentan algunas de ellas.

La navegabilidad determina si los canales de comunicación entre clases son o no navegables, en el sentido de si es posible que un objeto de un extremo pueda acceder a sus objetos asociados en el otro extremo. En UML cuando un extremo de la asociación es no navegable, la propiedad que representa el extremo no aparece en el espacio de nombres de las clases asociadas. Mientras que si el extremo es navegable, la propiedad es también un atributo de la clase asociada. En UML, por defecto las asociaciones son navegables en ambos sentidos. En este caso se dice que la asociación es bidireccional. Las agregaciones son navegables sólo en un sentido, de la clase compuesta a la componente. En este caso se dice que las agregaciones son unidireccionales.

La visibilidad determina cómo es visto un elemento por otros elementos del modelo. La visibilidad y la navegabilidad son conceptos diferentes, aunque es posible confundirlos porque ambos se refieren a la habilidad de un objeto de ver o utilizar otros objetos. En UML “la visibilidad de un atributo proporciona el medio para restringir el uso del elemento en los diferentes espacios de nombres dentro de un modelo”. La visibilidad de un atributo o una operación especifica si puede ser usado/a por otras clases. Los valores posibles para esta propiedad son:

• publico, el elemento puede ser utilizado por cualquier clase con visibilidad a la clase del elemento,

• protegido, el elemento sólo puede ser utilizado por las clases

descendientes más la clase del elemento,

• privado, el elemento sólo puede ser utilizado por su clase.

63

Figura 3.14. Relación entre las clases Llave y Puerta

En la figura 3.14 se puede ver un ejemplo de la relación que existe entre la visibilidad y la navegabilidad. En el ejemplo los dos extremos de la relación tienen visibilidad pública (utilizando la notación de UML se representa a través del símbolo ‘+’ delante del nombre del extremo), pero sólo uno de los dos extremos, el extremo puerta, es navegable (utilizando la notación de UML se representa con una flecha en el extremo). Esto significa que, pese a que el extremo llave es público, al ser no navegable no es posible que un objeto de la clase Puerta utilice las operaciones insertar y extraer (llave.insertar o llave.extraer). Sin embargo como el extremo puerta tiene visibilidad pública y además es navegable es posible que un objeto de la clase Llave utilice las operaciones cerrar y abrir (puerta.cerrar y puerta.abrir).

Otra propiedad que hace referencia a la accesibilidad de objetos es la encapsulación o “information hiding”. Según Civello en [CVL93] “Un objeto encapsulado es sólo visible dentro del ámbito del objeto que lo encapsula. Un objeto compuesto puede encapsular sus partes, haciendo su estructura interna invisible a sus clientes”. Sellers en [WHT99] aporta información adicional acerca de esta propiedad con su argumento de que no es una propiedad necesaria de la agregación puesto que “[...]un objeto persona que es miembro de un club podría relacionarse con una cuenta de un banco en el contexto de sus necesidades financieras”.

+arrancar()+detener()

Coche

+encender()+apagar()

Motor

1 <<encapsulada>>

Figura 3.15. Agregación entre las clases Coche y Motor En la figura 3.15 se puede ver un ejemplo de la propiedad

encapsulación. En la figura existe una relación de composición entre una clase compuesta Coche y una clase componente Motor. Se utiliza la notación UML para representar la composición. En UML la composición se representa gráficamente a través de un rombo negro en el extremo de la clase compuesta. En este ejemplo la clase Coche encapsula la clase Motor. Esto significa que las operaciones de un objeto motor (encender y apagar) sólo se pueden llevar a cabo a través del coche al que pertenecen (por las características de la composición en UML un componente sólo puede pertenecer a un compuesto). En este caso las operaciones de un coche, arrancar y detener, utilizan las operaciones de su motor, motor.encender

64

y motor.apagar respectivamente. Además la clase motor no puede relacionarse con ninguna otra clase.

Saksena et al. en [SAK98] identifican otra propiedad de este tipo, la pertenencia. Esta propiedad se considera como una propiedad necesaria de la agregación. Se define como: “un objeto es propietario de su parte en el sentido de que controla el comportamiento de sus partes, es decir, el agregado controla como y cuando los servicios de sus partes son utilizados. Esto requiere que una clase agregada tenga métodos que llamen a los métodos de sus partes”. Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Visibilidad Alto Medio Alto Navegabilidad Alto Medio Alto Encapsulación Alto Medio Medio Pertenencia Alto Medio Medio

Tabla 3.8. Análisis de las propiedades de accesibilidad

En la tabla 3.8 se muestra el grado de satisfacción de los criterios de calidad de las propiedades de accesibilidad introducidas. Todas las propiedades se pueden representar en la implementación de la estructura de la asociación, por lo que cumplen el criterio de Implementabilidad. La precisión se cumple en su grado medio, puesto que las definiciones existentes de estas propiedades pueden dar lugar a diferentes interpretaciones. Las propiedades que se seleccionen para el marco conceptual necesitarán definirse de forma precisa. La visibilidad y la navegabilidad son propiedades con un grado de usabilidad alto, puesto que resultan fácilmente comprensibles. Sin embargo la encapsulación y pertenencia poseen numerosas implicaciones (como la propagación de operaciones y la restricción de asociaciones entre clases) que dificultan su comprensibilidad, por lo que en estos dos casos la usabilidad se satisface en su grado medio.

Pese a que las cuatro propiedades cumplen los tres criterios de calidad,

no se incluyen todas en el marco conceptual: • La visibilidad es una propiedad de distintos elementos de un modelo

(atributos, métodos y asociaciones), no exclusivamente de la asociación, por lo que no es necesario incluirla en el modelo de asociación.

• La encapsulación: el control de las operaciones de una clase se puede

especificar definiendo un comportamiento específico en las operaciones de la clase que lleva a cabo la encapsulación (en OO-Method esto se puede realizar en el Modelo Funcional), por lo que no sería necesario incluir una propiedad adicional a la asociación. Además el hecho de que una clase no pueda tener otras asociaciones es una propiedad que se da entre varias asociaciones y, como se ha

65

comentado anteriormente, este tipo de propiedades no se estudia en la tesis.

• La pertenencia es una propiedad que se puede englobar dentro de la

encapsulación, puesto que implica que un objeto debe encapsular el comportamiento de su objeto asociado.

Se concluye que la propiedad Navegabilidad se incluye en el marco

conceptual.

3.4.6. Mecanismos de Identificación

En la versión 1.5 de UML, aparece una propiedad de la composición que determina si el compuesto “proyecta su identidad sobre las partes en la relación. En otras palabras, cada parte en un modelo de objetos puede ser identificada por un único compuesto. La parte mantiene su propia identidad como primaria. El matiz es que también puede ser identificada como parte de un único compuesto.” [UML1.5] pág. 3-81.

Existen asociaciones en las que aparece la proyección de identificación

que introduce UML de forma obligatoria, es decir, donde los objetos de una clase se identifican siempre a través de su objeto asociado. Olivé, en [OLVL], estudia este mecanismo de identificación como referencia compuesta. Un ejemplo de proyección de identificación en una asociación, se presenta en la figura 3.16. En este ejemplo, la clase Ciudad y la clase Provincia están relacionadas a través de la relación pertenece. Los objetos de la clase Ciudad se identifican a través de un identificador propio más un identificador de la provincia a la que pertenecen, es decir, la provincia proyecta su identidad a través de la relación para identificar a sus ciudades. Por lo que la clase Provincia proyecta su identidad sobre la clase Ciudad.

Figura 3.16. Asociación entre las clases Ciudad y Provincia

Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Dependencia de Identificación

Alto Alto Alto

Tabla 3.9. Análisis de las propiedades de identificación

En la tabla 3.9 se muestra el grado de satisfacción de los criterios de calidad de la propiedad proyección de identificación. La propiedad cumple el criterio de Implementabilidad, puesto que especifica cómo se implementa el mecanismo de identificación de las clases participantes. La definición de la propiedad no es ambigua, cumpliendo el criterio de Precisión. Por último, la

66

especificación de la propiedad se puede realizar de forma intuitiva, por lo que se cumple el criterio de Usabilidad.

Se incluye una propiedad en el marco conceptual llamada Proyección de Identificación para especificar este comportamiento. 3.4.7. Propiedades Estructurales.

Una propiedad identificada por Sellers en [WHT99] como propiedad primaria de las agregaciones es la propiedad Parte-de (“Whole-Part”). Esta propiedad especifica si la asociación es una relación del tipo “es_parte_de”.

Otras dos propiedades identificadas por Odell en [ODL94], Saksena en [SAK98] y Sellers en [FHS98] en el contexto de la agregación son la Homogeneidad y la Configuracionalidad. La primera determina “si las partes son el mismo tipo de cosa que el todo”, la segunda “si las partes tienen una relación funcional o estructural particular unas con otras o con el objeto que constituyen”.

Saksena en [SAK98] y Sellers en [WHT99] identifican otras dos

propiedades que definen las agregaciones: la Propiedad Emergente y la Propiedad Resultante. La primera es una propiedad “que no pueda deducirse de la inspección de sus partes”, mientras que la segunda es una propiedad “que pueda derivarse de la inspección de sus partes”. Por ejemplo, supongamos una relación de agregación de una clase agregada bicicleta y las clases componentes: cuadro, rueda, manillar y pedal. Una

propiedad emergente de la clase bicicleta sería precio, puesto que es propia de la clase y no es necesario consultar las partes para obtener su valor,

mientras que una propiedad resultante sería el peso, que se obtendría a partir del peso de cada una de sus partes. En [SAK98] y [WHT99] una clase agregada debe tener como mínimo una propiedad emergente y una resultante. Propiedad / Criterio Calidad Implementabilidad Precisión Usabilidad

Parte/de Bajo Alto Alto Homogeneidad Bajo Alto Alto Configurabilidad Bajo Alto Alto Propiedad Emergente Bajo Alto Alto Propiedad Resultante Bajo Alto Alto

Tabla 3.10. Análisis de las propiedades estructurales Como se puede ver en la tabla 3.10 las propiedades estructurales

identificadas no satisfacen el criterio de Implementabilidad: • las tres primeras propiedades, Parte-De, Configurabilidad y

Homogeneidad, capturan un aspecto semántico de la asociación en el dominio que no posee una representación explícita en su implementación (estructura y comportamiento):

o la propiedad parte_de: por ejemplo la relación entre una clase Factura y una clase LineaFactura es del tipo “parte_de”, sin embargo esta característica no afecta ni a la estructura ni a la

67

funcionalidad de la relación existente entre las clases y se implementa sin tener en cuenta esta característica;

o la configurabilidad: por ejemplo las clases Motor y Chasis relacionadas con la clase Vehiculo mantienen una relación estructural entre ellas: un motor y un chasis se relacionan de una forma concreta para constituir un vehículo. Sin embargo, esto no afecta a la estructura y funcionalidad de las asociaciones que las clases mantienen con la clase Vehiculo;

o la homogeneidad: por ejemplo la clase Edificio y la clase Piso relacionadas a través de una asociación del tipo “parte_de” representan clases del tipo Estructura Física, que pertenecen a una misma categoría, al igual que las clases Factura y LineaFactura son clases del tipo Información Virtual. Sin embargo, de nuevo esta característica no tiene repercusión en la implementación de la asociación que mantienen las clases.

• las dos siguientes propiedades presentadas, Propiedad Emergente y

Propiedad Resultante, caracterizan atributos de las clases de dominio. Al margen del hecho de que estos atributos se implementan como atributos de la clase de diseño, que una clase tenga una propiedad emergente y/o resultante no representa una codificación adicional en la implementación.

Ninguna de las propiedades introducidas se incluye en el marco conceptual. 3.5. Definición del Marco Conceptual

Las propiedades seleccionadas en el apartado anterior constituyen un marco conceptual que permitirá caracterizar las asociaciones de forma precisa. En este apartado se presentan formalmente las propiedades introducidas en el marco.

En la tabla 3.12 se presentan de forma sintetizada las propiedades que

constituyen el marco, indicando el nombre de la propiedad, una descripción breve y el elemento de la asociación sobre el que se define.

Nombre Descripción Elemento

Dinamicidad Restricción de la modificación

del número enlaces

Extremo

Mutabilidad Restricción de la modificación

de enlaces

Extremo

Multiplicidad Restricción del número de

enlaces

Extremo

68

Reflexividad ¿Es posible relacionar al objeto

a consigo mismo?

Relación

Reflexiva

Simetría ¿Si a está relacionado con b, es

posible relacionar b con a?

Relación

Reflexiva

Transitividad ¿Si a está relacionado con b, y

b está relacionado con c, está

de forma implícita a relacionado

con c?

Relación

Reflexiva

Propagación

de Borrado

Acción al borrar objeto asociado Extremo

Proyección de

Identificación

Identificación de objetos

asociados

Extremo

Navegabilidad Accesibilidad a objetos

asociados

Extremo

Tabla 3.12. Síntesis de las propiedades que constituyen el marco conceptual

Figura 3.17. Asociación r entre dos clases A y B

Para presentar las propiedades del marco, se utiliza como ejemplo la

relación de la figura 3.17, donde se representa gráficamente una asociación r entre las clases A y B. La relación r posee dos extremos E1 y E2. Cada extremo une la asociación con una clase participante. Al nombre que acompaña a un extremo se le denomina rol, puesto que indica el papel que juega en la relación la clase asociada al extremo. 3.5.1. Formalización de las Propiedades

La presentación del marco conceptual incluye la formalización de las

propiedades que lo constituyen. Para llevar a cabo la formalización se ha utilizado lógica de primer orden (LPO), utilizando algunas funciones que denotan cambios de estado para representar el paso del tiempo de un sistema. Se ha utilizado la LPO por ser una lógica sencilla, que puede ser fácilmente entendida, y que a su vez permite expresar todas las condiciones requeridas para nuestras propiedades.

Antes de introducir la formalización de las propiedades se presentan

algunos conceptos sobre la notación utilizada.

69

a) ϑ denota un objeto b) 2ϑ denota un conjunto de objetos c) ∅ denota el conjunto vacío d) C denota el conjunto de clases del sistema, e) R denota el conjunto de relaciones del sistema, f) P denota el conjunto de propiedades de una clase g) V denota el conjunto de métodos de una clase h) La función r: ϑ 2ϑ toma un objeto o y devuelve el conjunto de

objetos asociados a o a través de la relación r i) La función M: ϑ ϑ toma un objeto y devuelve el objeto en el estado

siguiente del sistema. La función se utiliza para definir una transición de estado del sistema.

j) La función acc: C x R x C P x V toma una clase origen, una relación y una clase destino y devuelve el conjunto de propiedades y métodos de la clase destino que pueden utilizar los objetos de la clase origen en su especificación como si fueran propiedades y métodos propios (utilizando los operadores de navegación de cada lenguaje de modelado).23

k) La función size: 2ϑ entero toma un conjunto de objetos y devuelve el número de elementos del conjunto

l) R es un predicado y el átomo R(x, y) es cierto cuando y pertenece al conjunto r(x).

m) A es un predicado y el átomo A(x) es cierto cuando x es un objeto de la clase A.

En los siguientes apartados se presentan de forma detallada cada una de

estas propiedades. Para cada propiedad: (1) se identifica el elemento de la relación sobre el cual se define, (2) se describe su significado, (3) se introduce la nomenclatura que se utilizará a lo largo de esta tesis, (4) se definen los posibles valores que puede tomar la propiedad y, (5) se formalizan los valores posibles de la propiedad. 3.5.2. Dinamicidad

• Definida sobre: los extremos de la relación.

• Significado: Esta propiedad especificada sobre un extremo E1 de una relación r, determina si los objetos del extremo24 opuesto (E2) pueden durante su vida añadir o eliminar enlaces de la relación r con objetos del extremo E1. El valor Dinámica indica que los objetos sí pueden durante su vida añadir o eliminar enlaces, mientras que el valor Estática indica que esto no es posible (sólo se pueden añadir o eliminar enlaces durante la creación del objeto). Existen dos valores

23 Para utilizar las propiedades y métodos también se necesitaría tener en consideración la visibilidad. 24 Utilizamos la expresión “objetos del extremo” para referirnos a los “objetos de la clase asociada al extremo”.

70

más de la propiedad, Incrementable y Decrementable, que indican, en el primer caso, que es posible sólo añadir enlaces, y en el segundo, que sólo es posible eliminarlos.

• Nomenclatura: Drol25.

• Valores: Estática | Dinámica | Incrementable | Decrementable

• Formalización:

o DA = Estática:

(∀x) (A(x) IGUAL_QUE( size(r(x)) , size(r(M(x))))

o DA = Dinámica:

(∃x) (A(x) DISTINTO_QUE( size(r(x)) , size(r(M(x))))

o DA = Incrementable: (∀x) (A(x) MAYOR_IGUAL_QUE( size(r(x)), size(r(M(x))))

o DA = Decrementable:

(∀x) (A(x) MENOR_IGUAL_QUE( size(r(x)) , size(r(M(x))))

3.5.3. Mutabilidad

• Definida sobre: los extremos de la relación. • Significado: Esta propiedad especificada sobre un extremo E1 de una

relación r, determina si los objetos del extremo opuesto (E2) pueden, durante su vida, modificar enlaces de la relación r, sustituyendo un objeto del extremo E1 por otro de su misma clase. El valor Mutable indica que los objetos sí pueden modificar enlaces durante su vida, mientras que el valor No Mutable indica que esto no es posible.

• Nomenclatura: Mrol

• Valores: Mutable | No Mutable

• Formalización:

o MA = No Mutable:

(∀x) (A(x) ∧ DISTINTO_QUE(r(x) , r (M(x)))

25 Cuando la clase sólo tenga una relación, utilizaremos el nombre de la clase en lugar del nombre del rol.

71

DISTINTO_QUE(size(r(x)) , size(r(M(x))))

o MA = Mutable:

(∃x) (A(x) ∧ DISTINTO_QUE(r(x) , r(M(x)) ) IGUAL_QUE(size(r(x)) , size(r(M(x))))

3.5.4. Multiplicidad

• Definida sobre: los extremos de la relación.

• Significado: La Multiplicidad especificada sobre un extremo E1 de una relación r determina el valor mínimo(Min)/máximo(Max) de objetos del extremo E1 que deben/pueden ser conectados a través de la relación r a un solo objeto del extremo opuesto E2.

• Nomenclatura: Minrol, Maxrol.

• Valores: enteros no negativos.

• Formalización: La fórmula que representa MinA y MaxA es la

siguiente:

(∀x) (A(x) MENOR_IGUAL_QUE(size(r(x)) , MaxA) ∧ MAYOR_IGUAL_QUE(size(r(x)) , MinA))

3.5.5. Propagación de Borrado

• Definida sobre: los extremos de la relación.

• Significado: La Propagación de Borrado especificada en un extremo E1 de una relación r indica qué acciones deben llevarse a cabo cuando se destruye un objeto del extremo opuesto E2.

• Restrictivo: si el objeto tiene enlaces de la relación R, no puede

ser destruido. • Cascada: si el objeto tiene enlaces de la relación R, éstos y sus

objetos asociados se destruyen. • Enlace: si el objeto tiene enlaces de la relación R, éstos se borran

(no se destruyen los objetos asociados).

• Nomenclatura: PBrol.

• Valores: Restrictivo | Cascada | Enlace.

• Formalización:

o PBA = Cascada:

72

(∀x,∀y) (A(x) ∧ B(y) ∧ R(x,y) ∧ ∼ A(M(x)) ∼ B(M(y))

o PBA = Restrictivo:

(∀x) (A(x) ∧ ∼ A(M(x)) ∼(∃y) (B(y) ∧ R(x,y))

o PBA = Enlace:

(∀x,∀y) (A(x) ∧ B(y) ∧ R(x,y) ∧ ∼ A(M(x)) ∼ R(M(x), M(y))

3.5.6. Navegabilidad

• Definida sobre: los extremos de la relación.

• Significado: La Navegabilidad especificada sobre un extremo E1 de una relación r indica si los objetos del extremo opuesto E2 pueden acceder a sus objetos asociados en el extremo E1 a través de la relación r. El valor No Navegable indica que no pueden ser accedidos. El valor Navegable especifica que sí pueden ser accedidos.

• Nomenclatura: Nrol.

• Valores: Navegable | No Navegable.

• Formalización:

o NA = Navegable:

acc(B x R x A) <> ∅ o NA = No Navegable

acc(B x R x A) = ∅

3.5.7. Proyección de Identificación

• Definida sobre: los extremos de la relación.

• Significado: Esta propiedad especificada sobre un extremo E1 de una relación r, indica si los objetos del extremo se identifican a través de su/s objeto/s asociado/s (objetos del extremo opuesto E2). En el caso de que esto ocurra, el valor de la propiedad es Proyectado. En otro caso, el valor es No Proyectado.

• Nomenclatura: PIrol.

• Valores: Proyectado | No Proyectado.

73

• Formalización:

o PIA = Proyectado

(∀x) (AtrIdA(x) AtrA (x) ∨ AtrB(x)) o PIA = No Proyectado

(∀x) (AtrIdA(x) AtrA (x))

donde AtrIdA representa el conjunto de atributos identificadores de la clase A y AtrA el conjunto de atributos de la clase A.

3.5.8. Reflexividad

• Definida sobre: la relación.

• Significado: La Reflexividad especifica si un objeto puede o debe relacionarse consigo mismo. El valor Reflexiva indica que cada objeto se relaciona consigo mismo obligatoriamente, el valor Antirreflexiva indica que no es posible que un objeto se relacione con él mismo, mientras que No Reflexiva indica que esto es posible pero no obligatorio.

• Nomenclatura: RFrelacion.

• Valores: Reflexiva | Antirreflexiva | No Reflexiva.

• Formalización:

o RFR = Reflexiva:

(∀x) (A(x) R(x, x)) o RFR = Antirreflexiva:

∼ (∃x) (A(x) R(x, x))

o RFR = No Reflexiva:

∼ (∀x) (A(x) R(x, x)) 3.5.9. Simetría

• Definida sobre: la relación.

• Significado: La simetría especifica si un objeto puede o debe relacionarse con otro objeto, el cual ya está relacionado con él. Si es posible (pero no obligatorio) el valor de la propiedad es No simétrica.

74

Si es obligatorio el valor de la propiedad es Simétrica. Si no es posible, el valor de la propiedad es Antisimétrica.

• Nomenclatura: Srelacion.

• Valores: No simétrica | Simétrica | Antisimétrica.

• Formalización:

o SR = Simétrica:

(∀x)(∀y) (A(x) ∧ A(y) ∧ R(x,y) R(y,x))

o SR = Antisimétrica: (∀x)(∀y) (A(x) ∧ A(y) ∧ R(x,y) ∼R(y,x))

o SR = No simétrica:

∼(∀x)(∀y) (A(x) ∧ A(y) ∧ R(x,y) R(y,x)) 3.5.10. Transitividad

• Definida sobre: la relación.

• Significado: si un objeto a está asociado a un objeto b, y el objeto b está asociado a un objeto c, entonces el objeto a está asociado al objeto c. Si ocurre esto, la relación es transitiva, en otro caso la relación es no transitiva.

• Nomenclatura: Trelacion.

• Valores: Transitiva | No Transitiva.

• Formalización:

o TR = Transitiva:

(∀x)(∀y)(∀z) (A(x) ∧ A(y) ∧ A(z) ∧ R(x,y) ∧ (R(y,z)) R(x,z))

o TR = No transitiva:

∼(∀x)(∀y)(∀z) (A(x) ∧ A(y) ∧ A(z) ∧ R(x,y) ∧ (R(y,z)) R(x,z))

3.5.11 Dependencias entre las Propiedades del Marco Las propiedades del marco conceptual no son ortogonales por lo que existen dependencias entre algunas de sus propiedades. Estas dependencias aportan un aspecto metodológico al marco propuesto,

75

facilitando la comprensión de la semántica de las asociaciones y ayudando a derivar información durante el modelado. A continuación se presentan las dependencias detectadas. A cada dependencia se le asocia un identificador (DPDX, siendo X un entero) que permitirá referenciarla en posteriores capítulos.

DPD1: La Propagación de Borrado de un extremo depende del valor de la

propiedad Dinamicidad y Multiplicidad del extremo opuesto. Cuando al destruir un objeto de un extremo se destruyen también sus

enlaces (PB = Enlace en el extremo opuesto), los objetos del extremo opuesto deben eliminar la conexión que mantienen con el enlace, para lo que no debe existir restricción dinámica

(Dinamicidad debe ser Dinámica o Decrementable) ni de multiplicidad mínima.

PBE1 = Enlace DE2 = Dinámica o Decrementable y MinE2 = 0

Ejemplo. Supongamos la relación firmar de la figura 3.1. El extremo

de la clase Publicación es Estático y la PB es Enlace. En el extremo de la clase Firmante la PB es Cascada. ¿Qué ocurre si el extremo de la clase Firmante se modela Estático? No sería posible destruir ningún firmante, puesto que al intentar borrar el enlace con la publicación asociada (PBPUBLICACION = Enlace) se violaría la dinamicidad de ésta. Por esta razón, el extremo de la clase Firmante debe ser Dinámico (o Decrementable).

DPD2: La Proyección de Identificación depende del valor de la propiedad

Multiplicidad Máxima y Mínima. Si los objetos de un extremo pueden estar relacionados con más de un objeto del extremo opuesto

(Max>1) o no estar relacionados con ninguno (Min = 0), entonces no es posible identificar a los primeros a través de los objetos

asociados (PI <> Proyectada).

PIE1 = Proyectada MinE2 = 1 y MaxE2 = 1

Ejemplo. Supongamos una relación pertenece entre una clase Item y una clase Línea. Si los objetos de la clase Item se identifican a través de la línea a la que pertenecen, es necesario que los ítems siempre pertenezcan a una sola línea, de otra forma, no sería posible aplicar correctamente el mecanismo de identificación (puesto que no sería posible establecer la correspondencia objeto objeto).

DPD3: La Reflexividad depende del valor de la propiedad Multiplicidad

Mínima. Cuando la relación es Reflexiva, todos los objetos de la clase se relacionan con ellos mismos, por lo que la multiplicidad mínima debe ser mayor que 0.

76

Rr = Reflexiva MinE1 y MinE2 > 0

Ejemplo. Supongamos una relación querer entre una clase Persona con ella misma. Si la relación es Reflexiva significa que todos los objetos persona se quieren a ellos mismos, por lo que existe una instancia de la relación para todos los objetos de persona con ellos mismos. Esto significa que la multiplicidad mínima será siempre mayor que 0 (en ambos extremos).

DPD4: La Mutabilidad depende del valor de la propiedad Dinamicidad y Multiplicidad. Si un extremo de la asociación es Mutable, el extremo opuesto debe ser Dinámico y la multiplicidad mínima debe ser distinta a la multiplicidad máxima, para permitir sustituir un objeto del enlace por otro de su misma clase.

ME1 = Mutable MinE2 <> MaxE2 y DE2 = Dinámica

Ejemplo. Supongamos la relación patronear entre la clase Patrón y la clase Barco. Si el extremo de la clase Patrón es Mutable (es posible sustituir un patrón de un barco por otro patrón), el extremo de la clase Barco debe ser Dinámico y su multiplicidad mínima debe ser distinta de la máxima, porque sino no sería posible eliminar (o añadir) de un patrón un enlace con un barco.

DPD5: El valor de la propiedad Propagación de Borrado no puede tomar el valor Cascada en un extremo si dicho extremo es No Navegable, puesto que los objetos del extremo opuesto no pueden acceder a los objetos de la clase y por tanto no es posible destruir dichos objetos.

NE1 = No Navegable PBE2 <> Cascada

Ejemplo. Supongamos la relación entre la clase Factura y la clase LineaFactura. Si el extremo de la clase Factura es No Navegable (una línea de factura no puede acceder a su factura), el extremo de la clase Factura debe tener como Propagación de Borrado el valor Enlace o Restrictivo, puesto que no es posible al destruir una línea de factura destruir su factura asociada.

DPD6: El valor de la propiedad Proyección de Identificación no puede tomar el valor Proyectado en los dos extremos de la relación, porque esto originaría una identificación recursiva.

PIE1 = Proyectado PIE2 = No Proyectado

DPD7: El valor de la propiedad Propagación de Borrado no puede tomar el valor Cascada en los dos extremos de la relación, puesto que se podrían originar ciclos infinitos durante la destrucción de un objeto.

77

PBE1 = Cascada PBE2 <> Cascada Este conocimiento puede aplicarse en la construcción de herramientas de modelado gráficas que incluyan comprobación semántica. Esto ayudará al ingeniero de software en la construcción de Esquemas Conceptuales. 3.6. Conclusiones

En este capítulo se ha presentado un marco conceptual formado por un conjunto de propiedades seleccionadas de entre las propiedades más referenciadas de distintas aproximaciones que estudian la asociación.

La selección de las propiedades se ha realizado en base a un conjunto de

características de calidad (implementabilidad, precisión y usabilidad) identificadas para la evaluación de las propiedades. Estas características tienen como objetivo la construcción de modelos conceptuales de calidad en el ámbito de un método DDM. No obstante, el resultado de la evaluación de las propiedades refleja que únicamente los criterios de implementabilidad y usabilidad han excluido propiedades del marco conceptual, puesto que todas las propiedades estudiadas cumplían el criterio de precisión (aunque algunas en su grado medio). Además de la aplicación de los criterios de calidad, para llevar a cabo el proceso de selección, se ha tenido en cuenta el solapamiento de la semántica de las distintas propiedades.

El conjunto de propiedades que constituye el marco se ha formalizado de

manera que no se permiten interpretaciones ambiguas para estas propiedades. Con esto se consigue que el marco conceptual caracterice las asociaciones de forma precisa.

El marco conceptual se utiliza en los siguientes capítulos de la tesis, para

(1) definir el modelo de asociación, (2) definir una guía metodológica para la especificación de la asociación y (3) definir un framework para la implementación de las propiedades.

La estrategia aplicada para construir el marco (que utiliza como punto de

partida distintas propiedades presentes en la literatura) garantiza al marco un grado de expresividad suficiente para modelar las características esenciales de la asociación. Sin embargo, no es posible garantizar la completitud del marco. Por ello, el marco presentado está abierto a la incorporación de nuevas propiedades. La incorporación de éstas está sujeta al cumplimiento de los criterios de calidad identificados para las propiedades de las asociaciones. Esto podría mejorar la propuesta realizada, permitiendo un modelado de las asociaciones más completo.

78

Capítulo 4 Un Modelo para las Asociaciones

Este capítulo presenta un modelo para las asociaciones, basado en el marco conceptual propuesto en el capítulo 3. Las características particulares del marco conceptual permiten especificar las asociaciones de forma precisa y construir un modelo ejecutable de calidad. Este modelo se define utilizando la técnica del metamodelado, que permite introducir de forma precisa los elementos que constituyen un modelo. Además se construye también un perfil UML que extiende la propuesta de UML para la asociación. Por último, el capítulo presenta un ayudante que, basándose en las propiedades del marco conceptual, proporciona una guía metodológica para el modelado de las asociaciones. 4.1. Introducción

La asociación es una abstracción muy utilizada en el modelado conceptual. Sin embargo, debido a la falta de precisión y completitud de las propuestas actuales, no existe hoy en día una definición estandarizada para ella. La carencia de una definición unificada para la asociación nos ha llevado a realizar una propuesta de modelado para la asociación.

La construcción del modelo de asociación parte de tres principios que

constituyen los pilares sobre los que se basa. Estos tres principios y sus implicaciones se presentan a continuación:

1. El modelo debe ser lo más próximo posible a la propuesta del estándar UML. Esto facilitará su comprensibilidad y garantiza una mayor aceptación por parte de la comunidad de desarrolladores. La enorme difusión del estándar UML, cuyo lenguaje es conocido por la mayoría de la comunidad de modelado conceptual OO, implica que la propuesta para el modelado de la asociación de UML esté extensamente difundida. Esto nos ha llevado a utilizar la propuesta para las asociaciones de UML como punto de partida para la construcción del modelo de asociación. Con esto se consigue que el nuevo modelo se base en conceptos bien conocidos para gran parte de los modeladores, lo que convierte al modelo propuesto en un modelo de fácil uso.

2. El modelo debe ser preciso, evitando ambigüedades, para

permitir que la representación software cumpla los requisitos especificados en el modelo. La propuesta de una especificación para la asociación que evite los problemas detectados en muchas de las aproximaciones que tratan las asociaciones, en las que existen ambigüedades e inconsistencias, nos permitirá posteriormente desarrollar una solución software que sea funcionalmente equivalente a la especificación de la asociación.

79

3. El modelo debe proporcionar expresividad suficiente para especificar las asociaciones de la forma más completa posible. En la especificación de la asociación se deben capturar las propiedades esenciales de la asociación en el dominio. Como se ha presentado en el capítulo anterior, el marco conceptual proporciona la expresividad necesaria para caracterizar las asociaciones. Por ello, para garantizar la expresividad en el modelo propuesto, se incorporan las propiedades del marco conceptual. Estas propiedades se utilizan para precisar y completar los conceptos introducidos por UML tomados como punto de partida en la construcción del modelo.

Siguiendo los principios introducidos se obtienen las directrices

principales del proceso de construcción del modelo para las asociaciones: se utilizan como punto de partida las definiciones básicas de UML para la asociación y se completan de forma precisa a través de las propiedades del marco conceptual. Con esto se pretende disponer de la expresividad suficiente para especificar las propiedades de la asociación del marco conceptual y evitar la ambigüedad existente respecto algunos conceptos relacionados con la asociación. Las particularidades del marco conceptual utilizado como base para construir el modelo, permiten garantizar que éste sea un modelo ejecutable de calidad.

El capítulo se estructura de la siguiente manera: a continuación se delimita el concepto de asociación, clarificando los principales aspectos de la abstracción que no han sido definidos de forma precisa. En el tercer apartado se presenta la caracterización propuesta para la asociación. Esta caracterización utiliza como punto de partida la clasificación de UML y a partir de ella, se basa en el marco conceptual para precisar los conceptos introducidos por UML. El cuarto apartado presenta el metamodelo del modelo descrito en anteriores apartados, de forma que se precisan los elementos introducidos. En el quinto apartado se construye un perfil UML para el modelo de asociaciones propuesto. El perfil permite extender el metamodelo de UML para que incorpore los elementos del modelo propuesto. En el sexto apartado se presenta una herramienta ayudante que proporciona un soporte metodológico al modelado de asociaciones. La herramienta utiliza las propiedades del marco conceptual para capturar la información necesaria para especificar la asociación. Por último, se presentan las conclusiones del capítulo. 4.2. Definición de Asociación

Una asociación binaria describe una conexión entre dos clases, de tal

forma que las instancias de las clases pueden estar conectadas entre sí en un momento dado. La asociación une la perspectiva estática y dinámica de un sistema. Por un lado, en su visión estática la asociación representa una estructura de datos, por otro lado en su visión dinámica, la asociación se usa como infraestructura de comunicación entre objetos [GNV03].

A una instancia de una asociación se le denomina enlace. Un enlace es

una tupla formada por dos objetos pertenecientes cada uno a una clase

80

participante, siendo una tupla una lista ordenada de un número finito de objetos. Si existe una relación r entre dos clases A y B, una instancia de la relación r es una tupla del tipo {ab}, donde a ∈ A y b ∈ B. El orden de los objetos de un enlace es una propiedad inherente de la asociación, que viene dada por el hecho de que los roles de la asociación son siempre distinguibles.

Al igual que los objetos como instancias de clases, los enlaces como

instancias de una asociación poseen una identidad propia. La notación utilizada para representar las asociaciones es la notación

propuesta por UML. Una asociación se representa gráficamente en el diagrama de clases mediante una línea que une las clases participantes. El nombre de la relación puede representarse como una etiqueta junto a la línea que representa la asociación. Los extremos de la relación pueden aparecer etiquetados con el nombre de extremo (rol). En la figura 4.1. se muestra un ejemplo de la notación utilizada en el caso de una relación r entre las clases A y B.

Figura 4.1. Representación gráfica de una asociación r entre dos clases A y B.

Las asociaciones tratadas en esta tesis son asociaciones binarias o de

grado 2. En la mayoría de los modelos conceptuales se definen asociaciones de grado 2; asociaciones ternarias (asociaciones con tres clases participantes) y en general n-arias (asociaciones con n clases, siendo n > 2) son poco frecuentes. En algunas aplicaciones aparecen asociaciones ternarias, y muchas veces ni siquiera se modelan como tales, puesto que los modeladores las transforman en asociaciones binarias. La extensión para relaciones n-arias del modelo propuesto en este capítulo, es una de las líneas de trabajo que abre esta tesis. Esta extensión no implica un cambio significativo en el modelo: las propiedades que caracterizan las relaciones son las mismas, aunque es necesario reformular las dependencias entre las propiedades y proponer notaciones gráficas específicas (por ejemplo para especificar las cardinalidades). 4.2.1. Comportamiento de la Asociación

Los enlaces de una asociación pueden crearse, destruirse y modificarse. Para ello, en las clases participantes se definen operaciones que permiten añadir, eliminar o modificar enlaces a/de sus objetos. A estas operaciones las llamamos operaciones de inserción, borrado y modificación de enlaces.

La definición de estas operaciones depende de las propiedades dinámicas

Dinamicidad y Mutabilidad que especifican características del comportamiento temporal de las asociaciones. A continuación se presentan estas dependencias:

81

• Cuando el valor de la propiedad Dinamicidad sobre un extremo de la

asociación es:

- Dinámica, se deben especificar operaciones en la clase del extremo opuesto que permitan añadir y eliminar enlaces a los objetos de la clase.

- Incrementable, se deben especificar operaciones en la clase del extremo opuesto que permitan añadir enlaces a los objetos de la clase.

- Decrementable, se deben especificar operaciones en la clase del extremo opuesto que permitan eliminar enlaces a los objetos de la clase.

• Cuando el valor de la propiedad Mutabilidad sobre un extremo de la

asociación es:

- Mutable, se deben especificar operaciones en la clase del extremo opuesto que permitan modificar enlaces de los objetos de la clase.

Figura 4.8. Relación fundar entre una clase Miembro y una clase Compañía

Ejemplo. Se tiene una clase Compañía relacionada con una clase

Miembro a través de una relación fundar (ver figura 4.8). El extremo de la clase Compañía es Incrementable puesto que durante la vida de un miembro, éste puede fundar otras compañías (por tanto puede añadir enlaces). El extremo opuesto es Estático, porque una vez se funda una compañía no se pueden modificar los miembros fundadores de ésta. La dinamicidad del extremo de la clase Compañía implica que es necesario disponer de operaciones en la clase Miembro que permitan conectar objetos de la clase Miembro con objetos de la clase Compañía. Para ello en la clase Miembro se especifica un método fundar_compañía que permite insertar un enlace entre un miembro y una compañía.

Este conocimiento puede ser utilizado en la construcción de

herramientas CASE, de tal forma que la especificación de operaciones que obligatoriamente deben ser definidas en el diagrama de clases, puede solicitarse de forma automática al modelador.

82

4.2.2. Clase Asociación Cuando una asociación posee propiedades de clase, la asociación se define como una clase. A esta abstracción única se la conoce como clase asociación. Una clase asociación puede tener las características de cualquier asociación (multiplicidad, dinamicidad, navegabilidad,…) y las características de cualquier clase (conteniendo propiedades, operaciones y relaciones con otras clases). Los enlaces de una clase asociación, al igual que los enlaces de una asociación, poseen identidad propia. En este caso, los enlaces se pueden identificar además:

- a través de los objetos participantes o, - en el caso de que existan propiedades que definen la identidad de la

clase, a través de estas propiedades más los objetos participantes.

La notación utilizada para representar la clase asociación es la notación propuesta por UML. La clase asociación se representa gráficamente mediante un rectángulo de clase, unido por una línea discontinua al punto medio de una línea de asociación. El nombre de la clase asociación es único, y representa tanto el nombre de la clase como el nombre de la asociación. En la figura 4.7 se puede ver un ejemplo de una clase asociación. En este ejemplo la asociación matrimonio entre una clase Hombre y una clase Mujer es también una clase, por lo que se modela como una clase asociación.

Hombre Mujer

-fechamatrimonio

0..1 0..1

Figura 4.7. Ejemplo de Clase Asociación

4.3. Caracterización de las Asociaciones

El contexto científico y técnico dentro del cual se desarrolla el modelo propuesto gira en torno a un eje constituido principalmente por la propuesta de UML. Esto nos ha llevado a tomar como punto de partida para la caracterización de las asociaciones la categorización propuesta por UML. UML las clasifica en tres tipos: asociación, agregación y composición. Se toman como base las definiciones que propone UML para estos conceptos, y a partir de estas definiciones se completa y precisa su semántica utilizando las propiedades del marco conceptual.

Las definiciones UML que se toman como punto de partida son las

siguientes:

• Asociación: Declara que pueden existir enlaces entre instancias de los tipos asociados. Un enlace es una tupla con un valor para cada

83

extremo de la asociación, donde cada valor es una instancia del tipo del extremo. [UML2.0]

• Agregación: Es una forma especial de asociación que especifica una

relación todo-parte entre un agregado (todo) y una parte componente. [UML2.0]

• Composición: Es una forma de agregación que requiere que una

parte esté incluida en como mucho un compuesto a la vez, y que el compuesto sea responsable de la creación y destrucción de las partes. La composición puede ser recursiva. [UML2.0]

Para precisar la semántica se propone una interpretación particular a los

conceptos de UML. De esta manera se pueden eliminar las ambigüedades y contradicciones introducidas en la documentación que proporciona UML. 4.3.1. Interpretación de los Conceptos Asociación, Agregación y Composición.

A partir de las definiciones básicas de los conceptos asociación, agregación y composición, se propone una interpretación basada en las nociones más aceptadas de estos conceptos, presentes en diferentes aproximaciones metodológicas, tratando a su vez de aproximarse a la descripción que UML realiza de ellos.

La interpretación se realiza utilizando las propiedades del marco

conceptual presentado en el capítulo anterior. Para ello, se determina el valor de las propiedades del marco para la asociación, agregación y composición, de tal manera que se sitúe cada concepto de manera correcta dentro del marco. Es decir, se pretende dotar de semántica adicional a cada concepto dando valor a las propiedades del marco para cada uno de ellos. Propiedad/Concepto Asociación Agregación Composición

Compuesto, Componente

Dinamicidad * * Estática,*

Mutabilidad * * No Mutable, No Mutable

Multiplicidad * * (1,1) , (*,*)

Propagación de Borrado * * *, Cascada

Navegabilidad * * No Navegable, Navegable

Proyección de Identificación

* * *, *

Reflexividad * Antirreflexiva Antirreflexiva

Simetría * Antisimétrica Antisimétrica

Transitividad * * Transitiva Tabla 4.2: Valores de las propiedades para la asociación, agregación y composición.

84

Para presentar los valores de las propiedades que debe tener cada concepto se define la tabla 4.2. En ella se muestran los valores que toman las propiedades para la asociación, agregación o composición, según nuestra interpretación. Para cada concepto (columna), la tabla muestra los valores que debe tomar cada propiedad (fila). En algunos casos la propiedad puede tomar cualquier valor, en estos casos aparece el símbolo ’*’ en la casilla correspondiente.

• La asociación no tiene ningún valor determinado para las propiedades. Este concepto engloba las asociaciones en el sentido más general. Una relación semántica o estructural entre clases es una asociación, sin que exista ninguna restricción respecto al valor de las propiedades.

• La agregación tiene dos valores determinados. Por un lado, puesto

que en una agregación un objeto no puede ser a su vez todo y parte, la relación debe ser Antirreflexiva. Por otro lado, si un objeto es parte de un todo, este todo no puede ser a su vez parte de su propia parte, por tanto la relación debe ser Antisimétrica.

• La composición tiene un valor determinado para cada propiedad.

Tradicionalmente en la literatura, y en UML, la composición aparece como una “agregación fuerte”. Para determinar el valor de las propiedades partimos de la idea de que el concepto de composición implica que los componentes estén totalmente sujetos a los compuestos:

o un componente forma parte siempre de un solo compuesto,

por tanto el valor de la Multiplicidad Mínima y Máxima en el extremo del compuesto deber ser 1;

o este compuesto debe ser siempre el mismo, por tanto el valor

de la Dinamicidad en el extremo del compuesto deber ser Estática;

o el compuesto no puede sustituirse por otro de su misma clase,

por lo que el valor de la propiedad Mutabilidad en el extremo del compuesto es No Mutable;

o cuando se borra un compuesto se tienen que borrar todos sus

componentes, por tanto el valor de Propagación de Borrado en el extremo del componente debe ser Cascada;

o los componentes no pueden sustituirse por otro de su misma

clase, por lo que el valor de la propiedad Mutabilidad en el extremo del componente es No Mutable;

o los componentes son accesibles por su compuesto pero el compuesto no es accesible por los componentes, por tanto el

valor de la propiedad Navegabilidad sobre el extremo del compuesto debe ser No Navegable y sobre el extremo del componente debe ser Navegable;

o por ser la composición una agregación debe ser Antirreflexiva y Antisimétrica;

85

o la composición siempre es Transitiva puesto que si un objeto está compuesto de otro, y éste está compuesto de un tercero, el primer objeto está compuesto del tercero.

La interpretación propuesta para estos conceptos permite categorizar de

forma precisa las asociaciones en asociación, agregación y composición. La determinación de los valores de las propiedades para cada concepto, permite eliminar las ambigüedades que UML introduce.

Una vez se ha definido de forma precisa la semántica de los conceptos

asociación, agregación y composición, se presenta el metamodelo a partir del cual se instancia el modelo de asociaciones propuesto. 4.4. Metamodelo

En este apartado se presenta el metamodelo del modelo de asociaciones introducido. Para construir el metamodelo se utiliza el “Meta-Object Facility” (MOF) propuesto por la OMG.

Figura 4.16. Ejemplo de la Jerarquía de 4 Capas de UML [UMLI2.0]

La arquitectura de UML está basada en una estructura de metamodelado

en cuatro capas: meta-metamodelo (MOF), metamodelo, modelo y objetos de usuario. La capa del meta-metamodelo, o MOF, define un lenguaje abstracto y un marco para especificar, construir y manejar metamodelos de tecnología neutral. La capa del metamodelo es instancia del meta-

86

metamodelo y define el lenguaje para especificar el modelo. La capa del modelo es instancia del metamodelo y define el lenguaje para describir dominios. La capa de objetos de usuario es instancia del modelo y describe un dominio específico. En la figura 4.16 se puede ver un ejemplo de la jerarquía de capas de UML.

UML utiliza el metamodelo para definir el lenguaje utilizado para

especificar modelos. El metamodelo UML define todos los conceptos que se pueden utilizar en un esquema conceptual.

ClaseParticipante

nombre : String

ExtremoAsociacionnombre : Stringmultipl icidadMin : Integermultipl icidadMax : Integerdinamicidad : T ipoDinamicidadmutabi lidad : Booleannavegabilidad : BooleanproyeccionIdentificacion : BooleanpropagacionBorrado : TipoPropagacionagregada : TipoAgregacion

1..1

0..n

+participante1..1

0..n

Asociacionnombre : String/parte_de : Boolean

2..2 1..1

+conexion

2..2

+asociacion

1..1

TipoDinamicidadDinamicaEstaticaIncrementableDecrementable

<<enumeration>>TipoPropagacion

CascadaEnlaceRestrictivo

<<enumeration>>

TipoAgregacionAsociacionAgregacionComposicion

<<enumeration>>TipoSimetriaSimetricaNo SimetricaAntisimetrica

<<enumeration>>TipoReflexividad

ReflexivaNo ReflexivaAntirreflexiva

<<enumeration>>

AsociacionReflexivareflexividad : TipoReflexividadsimetria : TipoSimetriatransitividad : Boolean

Figura 4.9. Metamodelo MOF para las Asociaciones

En la figura 4.9 se puede ver el metamodelo MOF correspondiente al modelo descrito en el anterior apartado. Una asociación (instancia de la metaclase Asociación) tiene dos extremos (instancias de la metaclase ExtremoAsociacion), cada uno de ellos relacionado con una clase. Las metaclases y os atributos de éstas son los siguientes:

• La clase ExtremoAsociacion tiene como atributos las propiedades del marco conceptual definidas sobre los extremos:

o multiplicidad mínima y máxima, o dinamicidad, o mutabilidad, o propagación de borrado, o proyección de identificación, o navegabilidad,

87

más los atributos:

o nombre, cadena de caracteres con el nombre del extremo (rol) o agregada, TipoAgregacion que indica si la clase es una clase

agregada, compuesta o ninguna de las dos cosas.

• La clase Asociación tiene como atributos

o nombre, cadena de caracteres con el nombre de la asociación o /parte_de, booleano que especifica si la relación es una

agregación. Es un atributo derivado.

• La clase AsociaciónReflexiva, es una especialización de la clase Asociación que representa las asociaciones reflexivas (también llamadas recursivas o de grado 1). Tiene como atributos las propiedades del marco conceptual definidas sobre este tipo de relaciones:

o reflexividad, o simetría y o transitividad.

Además, en el metamodelo se definen un conjunto de restricciones

originadas por las dependencias que existen entre las propiedades del marco conceptual. En los siguientes apartados se presentan estas restricciones asociadas a las distintas metaclases.

A continuación se presentan con detalle las dos metaclases que

constituyen el metamodelo. Para cada una de ellas se introducen los siguientes puntos: (1) descripción informal de su semántica; (2) sus atributos, para los que se presenta el nombre, el tipo, una descripción informal de su significado y el valor por defecto; (3) sus asociaciones, para las que se introduce el nombre, la clase asociada, la cardinalidad de la asociación en el extremo opuesto y una breve descripción de su significado; (4) restricciones que la acompañan, para las que se presenta una descripción informal y su formalización en OCL; y (5) una propuesta de notación gráfica. 4.4.1 Metaclase Asociación

Una instancia de la metaclase Asociación (asociación) representa una relación semántica que puede ocurrir entre instancias de clases. Una asociación tiene dos extremos, cada uno de ellos conectado a una clase.

Una asociación puede ser una relación del tipo “parte_de”. En este caso

la asociación es una agregación y el atributo parte_de toma el valor verdadero. En una agregación una de las clases participantes juega el papel de agregada y la otra juega el papel de parte.

88

Atributos

• nombre: cadena. Nombre que recibe la asociación.

• /parte_de: booleano. Atributo derivado que especifica si la asociación es del tipo “parte_de” (verdadero) o no lo es (falso). Su fórmula de derivación es:

{parte_de = self.conexion->exists(c:ExtremoAsociacion | c.agregada=Agregacion or c.agregada=Composicion) }

Asociaciones

• conexión: ExtremoAsociación [2..2] Cada extremo representa la participación de instancias de la clase asociada al extremo en enlaces de la asociación.

Restricciones

1. Cuando el valor del atributo parte_de es verdadero, uno de los dos extremos de la asociación debe tener en el atributo agregada un valor distinto de Asociacion (Agregacion o Composición).

context Asociacion inv:

self.parte_de = true implies self.conexion->exists( e | e.agregada <> Asociacion)

Notación Una asociación se representa gráficamente con una línea conectando las dos clases participantes. Esta línea puede ir etiquetada con un nombre, que normalmente describirá el significado de la relación.

Cuando la asociación es del tipo “parte_de” (una agregación o una composición), un extremo de la asociación viene caracterizado por un rombo, indicando que la clase asociada al extremo es la clase agregada, siendo la otra clase la parte.

En la figura 4.10 se puede ver un ejemplo de la notación gráfica utilizada

para representar una asociación. En este caso se representa la asociación TrabajaPara entre una clase Empresa y una clase Empleado.

Figura 4.10 Notación gráfica utilizada para representar una Asociación TrabajaPara.

89

4.4.2. Metaclase AsociaciónReflexiva

Esta metaclase representa las relaciones en las que ambos extremos se conectan a una misma clase. En este caso la relación es reflexiva a nivel de clase.

Cuando la asociación es una agregación siempre es antirreflexiva y

antisimétrica a nivel de instancia. Atributos

• reflexividad: TipoReflexividad. Especifica si la relación es Reflexiva, No Reflexiva o Antirreflexiva. El valor por defecto es No Reflexiva.

• simetría: TipoSimetria. Especifica si la relación es Simétrica, No

Simétrica o Antisimétrica. El valor por defecto es No Simétrica. • transitividad: booleano. Especifica si la relación es Transitiva

(verdadero) o No Transitiva (falso). El valor por defecto es No Transitiva.

Restricciones

1. Cuando el valor del atributo parte_de es verdadero la relación es antirreflexiva y antisimétrica.

context AsociacionReflexiva inv:

self.parte_de = true implies self.reflexividad = Antirreflexiva and self.simetria = Antisimetrica

Notación Una asociación reflexiva se representa de la misma forma que una asociación, con la particularidad de que la línea conecta en sus dos extremos la misma clase.

Los valores de las propiedades Reflexividad, Simetría y Transitividad se especifican mediante símbolos situados junto a la relación. El significado de los símbolos es el siguiente:

• Reflexividad: o Reflexiva: ℜ o No Reflexiva: ausencia de símbolo (valor por defecto) o Antirreflexiva: ℜ

90

• Simetría: o Simétrica: ≡ o No Simétrica: ausencia de símbolo (valor por defecto) o Antisimétrica: ≠

• Transitividad o Transitiva: Τ o No Transitiva: ausencia de símbolo (valor por defecto)

La ausencia de símbolo para una propiedad indica que ésta toma el valor

por defecto. En la figura 4.11 se puede ver un ejemplo de la notación gráfica utilizada

para representar una asociación reflexiva. En este caso la relación es Simétrica (indicado a través del símbolo ≡ junto al nombre de la asociación), No Reflexiva y No Transitiva (estos dos valores no se representan gráficamente al ser los valores por defecto).

Figura 4.11 Notación gráfica utilizada para representar una Asociación Reflexiva 4.4.3. Metaclase ExtremoAsociación

Una instancia de la metaclase ExtremoAsociación representa un extremo de una asociación. Cada extremo está conectado con una clase participante.

Cuando la asociación es del tipo “parte_de” (atributo parte_de de la asociación toma el valor verdadero) puede ser una agregación o una composición. Si es una agregación, en el extremo de la clase agregada el valor del atributo agregada toma el valor Agregacion. Si es una composición, en el extremo de la clase agregada el valor del atributo agregada toma el valor Composicion. En una composición a la clase agregada se le denomina clase compuesta, y a la clase asociada, clase componente. El extremo compuesto tiene multiplicidad mínima y máxima 1, es Estático, No Mutable y No Navegable; y el extremo del componente es Navegable y el borrado en Cascada. Además cuando la composición es reflexiva a nivel de clase, es Antirreflexiva, Antisimétrica y Transitiva.

91

Atributos

• nombre: cadena. Nombre que recibe el extremo. Describe el papel

que juega la clase conectada al extremo dentro de la asociación. Es un valor opcional. Se le denomina rol.

• multiplicidadMin: entero. Especifica el valor de la Multiplicidad

Mínima en el extremo.

• multiplicidadMax: entero. Especifica el valor de la Multiplicidad Máxima en el extremo (cuando el valor es ilimitado se especifica con -1).

• dinamicidad: TipoDinamicidad. Especifica el valor de la propiedad

Dinamicidad en el extremo, Estática , Dinámica, Incrementable o Decrementable. Por defecto el valor es Dinámica.

• mutabilidad: booleano. Especifica el valor de la Mutabilidad en el

extremo, si es mutable es verdadero, en caso contrario es falso. Por defecto los extremos son no mutables.

• navegabilidad: booleano. Especifica el valor de la Navegabilidad en

el extremo, si es navegable es verdadero, en caso contrario es falso. El valor por defecto es navegable.

• proyeccionIdentificacion: booleano. Especifica el valor de la

propiedad Proyección de Identificación en el extremo, Proyectado (verdadero) o No Proyectado (falso). El valor por defecto es No Proyectado.

• propagacionBorrado: TipoPropagación. Especifica el valor de la

propiedad Propagación de Borrado en el extremo, Cascada, Enlace o Restrictivo. El valor por defecto es Enlace.

• agregada: TipoAgregacion. Especifica si el extremo está conectado a

una clase agregada (Agregación), compuesta (Composición) o ninguna de las dos (Asociación). Por defecto el valor es Asociación.

Asociaciones

• participante : Clase [1..1] Representa la clase conectada al extremo.

• asociacion : Asociacion [1..1] Representa la asociación a la que

pertenece el extremo.

92

Restricciones

1. Sólo un extremo de una asociación puede tener el valor Cascada en el atributo propagacionBorrado. Esta es una restricción originada por la dependencia DPD7 definida en el capítulo 3 página 76.

context ExtremoAsociacion inv:

self.propagacionBorrado = Cascada implies

self.asociacion.conexion->select(e | e<>self and

e.propagacionBorrado = Cascada)->isEmpty()

2. Sólo un extremo de una asociación puede tener el valor verdadero en el atributo proyeccionIdentificacion. Esta es una restricción originada por la dependencia DPD6 definida en el capítulo 3 página 76.

context ExtremoAsociacion inv:

self.proyeccionIdentificacion = true implies

self.asociacion.conexion->select(e | e<>self and

e.proyeccionIdentificacion = true)->isEmpty()

3. Si un extremo de una asociación tiene el valor Enlace en el atributo propagacionBorrado, en el otro extremo de la asociación el valor del atributo dinamicidad debe ser Dinámica o Incrementable y el valor del atributo multiplicidadMin debe ser 0. Esta es una restricción originada por la dependencia DPD1 definida en el capítulo 3 página 75.

context ExtremoAsociacion inv:

self.propagacionBorrado = Enlace implies

self.asociacion.conexion->select(e | e<>self and

(e.dinamicidad = Dinamica or Incrementable) and e.multiplicidadMin =0)->notEmpty()

4. Si un extremo de una asociación tiene el valor verdadero en el atributo proyeccionIdentificacion, en el otro extremo de la asociación el valor de los atributos multiplicidadMin y multiplicidadMax debe ser igual a 1. Esta es una restricción originada por la dependencia DPD2 definida en el capítulo 3 página 75.

context ExtremoAsociacion inv:

self.proyeccionIdentificacion = true implies

self.asociacion.conexion->select(e | e<>self and

93

e.multiplicidadMax=e.multiplicidadMin=1)->notEmpty()

5. Si la relación es Reflexiva, la multiplicidad mínima de ambos extremos debe ser mayor que 0. Esta es una restricción originada por la dependencia DPD3 definida en el capítulo 3 página 75. context AsociacionReflexiva inv: self.reflexividad = Reflexiva implies

self.conexion->select(e|e.multiplicidadMin=0)->isEmpty()

6. Si un extremo de una asociación tiene el valor verdadero en el atributo Mutabilidad, en el otro extremo de la asociación el valor de los atributos multiplicidadMin y multiplicidadMax debe ser distinto y el valor del atributo dinamicidad deber ser Dinamico. Esta es una restricción originada por la dependencia DPD4 definida en el capítulo 3 página 76.

context ExtremoAsociacion inv:

self.mutabilidad = true implies

self.asociacion.conexion->select(e | e<>self and

e.multiplicidadMax <> e.multiplicidadMin and

e.dinamicidad = Dinamica)->notEmpty()

6. Si un extremo de una asociación tiene el valor falso en el atributo Navegabilidad, el valor del atributo Propagación de Borrado del extremo debe ser distinto de Cascada. Esta es una restricción originada por la dependencia DPD5 definida en el capítulo 3 página 76.

context ExtremoAsociacion inv:

self.navegabilidad = true implies

self.propagacionBorrado <> Cascada

7. Si un extremo de una asociación tiene el valor agregada Composicion, se deben cumplir las propiedades de la composición.

context ExtremoAsociacion inv:

self.agregada = Composicion implies

94

self.dinamicidad = Estatica and self.mutablidad = false and self.multiplicidadMax = 1 and self.multiplicidadMin = 1 and self.navegabilidad = false

self.asociacion.transitividad = true and self.asociacion.reflexividad = Antirreflexiva and self.asociacion.simetria = Antisimetrica and self.asociacion.conexion->select(e | e<>self and

e.navegabilidad = false or e.mutabilidad = true or e.propagacionBorrado <> Cascada)->isEmpty()

Notación

Un extremo de una asociación se representa gráficamente por el extremo que une la línea que representa la relación y la clase participante. El nombre del extremo o rol, si se define, aparece como una etiqueta junto al extremo.

La multiplicidad mínima y máxima se representan gráficamente de la

misma forma que en UML: a través de 2 enteros separados por dos puntos, indicando la multiplicidad mínima y máxima. El símbolo ’*’ para la multiplicidad máxima indica que no existe un número limitado (se corresponde con el valor -1 de la propiedad).

Por defecto las asociaciones son navegables en los dos extremos.

Cuando uno de los dos extremos es no navegable, se indica que el extremo opuesto es navegable a través de una punta de flecha sobre el extremo.

Las propiedades dinamicidad, mutabilidad, propagación de borrado y

proyección de identificación se representan con etiquetas estereotipadas junto al extremo, indicando los valores de cada propiedad. Los valores de estas etiquetas son:

• Dinamicidad:

o Estática: Ausencia de símbolo (valor por defecto) o Dinámica: «+,-» o Incrementable: «+» o Decrementable: «-»

95

• Mutabilidad:

o Mutable: «MT» o No Mutable: Ausencia de símbolo (valor por defecto)

• Propagación de Borrado

o Cascada: «CC» o Enlace: Ausencia de símbolo (valor por defecto) o Restrictivo: «RT»

• Proyección de Identificación

o Proyectado: «PI» o No Proyectado: Ausencia de símbolo (valor por defecto)

Cuando en un extremo el valor del atributo agregada es Agregacion (la asociación es una agregación), indicando que la clase que acompaña al extremo es una clase agregada, se representa gráficamente a través de un rombo blanco entre la clase y el final de la línea que representa la asociación. En la figura 4.12 se muestra un ejemplo de una agregación. En el ejemplo, el extremo de la clase Alumno es Dinámico, indicándose a través de su correspondiente etiqueta estereotipada (<<+,->>) y el extremo de la clase Alumno tiene propagación en Cascada, indicándose a través de su correspondiente etiqueta (<<CC>>). Las demás propiedades de los extremos toman los valores por defecto, por lo que no se definen etiquetas para ellos.

Figura 4.12. Ejemplo de la notación gráfica utilizada para representar una Agregación

Si el valor del atributo agregada de un extremo es Composicion (la asociación es una composición), indicando que la clase es una clase compuesta, gráficamente se utiliza un rombo negro entre la clase del extremo y el final de la línea que representa la asociación. En la figura 4.13 se muestra un ejemplo de una composición. En este caso la composición tiene los valores predeterminados, más en el extremo componente el valor Dinámica, y en el extremo compuesto el valor Enlace.

Figura 4.13. Notación gráfica utilizada para representar una Composición

96

4.4.4. Instanciación del Metamodelo. Ejemplos. En esta sección se presentan tres ejemplos de instancias del metamodelo presentado. Para la elaboración de los ejemplos se ha utilizado el trabajo de Nicola et al. [BOL04]. En este trabajo se identifican 12 patrones de análisis que capturan un conjunto mínimo de relaciones que pueden existir entre clases. Los autores, basándose en su experiencia en el trabajo de desarrollo y consultoría utilizando estos patrones, definen este conjunto de patrones como un conjunto irreducible a partir del cual se puede derivar cualquier otro patrón de análisis. A estos patrones se les da el nombre de “Collaboration Patterns”. Los “Collaboration Patterns” pueden utilizarse para comprobar la completitud (en cierto grado) de un modelo de asociación, puesto que si éste es capaz de modelar todo este conjunto de patrones, entonces se puede deducir que puede modelar cualquier relación de asociación entre clases (de las más comunes y utilizadas en el modelado de sistemas software reales). Para instanciar el metamodelo propuesto, se han seleccionado tres de los patrones presentados en [BOL04] y se han utilizado para modelar un ejemplo de asociación, de agregación y de composición. Para cada uno de los ejemplos se determina el valor de las propiedades del marco y en función de dichos valores se establece si la relación es una asociación, agregación o composición.

Figura 4.14. Instanciación del Patrón T1

Caso 1. Patrón T1: Item - SpecificItem. Se instancia el patrón con el ejemplo de la figura 4.14, donde una clase Pelicula se relaciona con la clase CintaPelicula a través de una relación tiene_copias.

Los valores de las propiedades del marco para este caso se muestran en

la tabla 4.2.

Propiedad/Extremo Película CintaPelícula

Dinamicidad Estática Dinámica

Mutabilidad No Mutable Mutable

Multiplicidad (1,1) (0,*)

Propagación de Borrado Enlace Cascada

Navegabilidad Navegable Navegable

Proyección de Identificación No Proyectado Proyectado

Reflexividad -

Simetría -

Transitivad - Tabla 4.2: Valores de las propiedades para el caso 1.

97

La relación tiene_copias es una asociación (no es del tipo “parte_de”). Siendo una asociación, no existen restricciones sobre los valores de las propiedades. A continuación se analizan las propiedades de los extremos:

• Extremo CintaPelícula: o Multiplicidad [0..n]: una película puede tener 0 ó varias copias. o Dinámico: pueden crearse o destruirse copias de una película. o Mutable: es posible sustituir una copia por otra. o Cascada: si se destruye una película se destruyen todas sus

copias. o Proyectado: las copias de una película se identifican utilizando

los mecanismos de identificación de la película más los suyos propios.

o Navegable: una película tiene acceso a sus copias.

• En el extremo de la clase Película: o Multiplicidad [1..1]: una cinta de película es copia de una sola

película. o Estático y No Mutable: una cinta de película es siempre copia

de una misma película. o Enlace: si se destruye una cinta de película se eliminan los

enlaces con la película. o No Proyectado: las películas se identifican a través de

propiedades de su clase. o Navegable: una copia tiene acceso a la película.

Caso 2. Patrón T4: Group - Member. Se instancia el patrón con el ejemplo de la figura 4.15, donde una clase Equipo se relaciona con la clase Jugador a través de una relación pertenece.

Figura 4.15. Instanciación del Patrón T4

La tabla 4.3 muestra los valores de las propiedades del marco para el ejemplo. La relación pertenece es del tipo “parte_de”, entre una clase agregada Equipo y una clase parte Jugador. A continuación se analizan las propiedades de los extremos:

• Extremo Equipo: o Multiplicidad [0..n]: un jugador puede no pertenecer a ningún

equipo o pertenecer a varios. o Dinámico: un jugador puede cambiar de equipo. o Mutable: es posible sustituir un equipo al que pertenece un

jugador por otro.

98

o Enlace: si se destruye un jugador se eliminan sus enlaces. o No Proyectado: los equipos se identifican a través de

propiedades de su clase. o Navegable: un jugador puede acceder a sus equipos.

• Extremo Jugador: o Multiplicidad [0..n]: un equipo puede no tener ningún jugador

o tener varios. o Dinámico: en un equipo se pueden incorporar o eliminar

jugadores. o Mutable: es posible sustituir un jugador de un equipo por otro. o Enlace: si se destruye un equipo se eliminan sus enlaces. o No Proyectado: los jugadores se identifican a través de

propiedades de su clase. o Navegable: un equipo puede acceder a sus jugadores.

No se cumplen los valores fijos de una composición, por lo que la relación es una agregación.

Propiedad/Extremo Equipo Jugador

Dinamicidad Dinámica Dinámica Mutabilidad Mutable Mutable Multiplicidad (0,*) (0,*) Propagación de Borrado Enlace Enlace Navegabilidad Navegable Navegable Proyección de Identificación No Proyectado No Proyectado Reflexividad - Simetría - Transitivad -

Tabla 4.3: Valores de las propiedades para el caso 2. Caso 3. Patrón E3: CompositeTransaction - LineItem. Se instancia el

patrón con el ejemplo de la figura 4.16, donde una clase Obra se relaciona con la clase Representacion.

Figura 4.16. Instanciación del Patrón E3

99

Propiedad/Extremo Obra Representacion

Dinamicidad Estática Dinámica Mutabilidad No Mutable No Mutable Multiplicidad (1,1) (1,*) Propagación de Borrado Enlace Cascada Navegabilidad No Navegable Navegable Proyección de Identificación No Proyectado Proyectado Reflexividad - Simetría - Transitivad -

Tabla 4.4: Valores de las propiedades para el caso 3.

En la tabla 4.4 se presentan los valores para las propiedades del marco

del ejemplo. La relación del caso 3 es del tipo “parte_de”, entre una clase agregada Obra y una clase parte Representacion. A continuación se analizan las propiedades de los extremos:

• Extremo Obra: o Multiplicidad [1..1]: una representación pertenece a 1 sola

obra. o Estático: una representación pertenece siempre a la misma

obra. o No Mutable: no es posible sustituir la obra a la que pertenece

una representación por otra. o Enlace: si se destruye una representación se elimina su enlace

con la obra. o No Proyectado: las obras se identifican a través de propiedades

de su clase. o No Navegable: una representación no tiene acceso a su obra.

• Extremo Representacion: o Multiplicidad [1.. n]: una obra como mínimo tendrá una

representación, y puede tener varias. o Dinámico: una obra puede añadir o eliminar representaciones

durante su vida. o No Mutable: no es posible sustituir una representación de una

obra por otra o Cascada: si se destruye una obra se destruyen sus

representaciones. o Proyectado: una representación se identifica a través de su

obra. o Navegable: una obra puede acceder a sus representaciones.

La relación es una composición, puesto que se cumplen todos los valores fijos de este tipo de relación.

100

4.5. Definición de un Perfil UML

En este apartado se presenta un perfil UML para las asociaciones. El perfil UML extiende el metamodelo de UML incorporando los elementos del nuevo modelo. Con este perfil se pretende mejorar la especificación de asociaciones en UML. El perfil proporciona al diseñador nuevos constructores, con su correspondiente representación gráfica, que pueden utilizarse para definir esquemas conceptuales UML.

Los perfiles UML están definidos en el paquete “Profiles” de la

“InfrastructureLibrary”. Este paquete contiene mecanismos que permiten extender las metaclases de metamodelos existentes para adaptarlos a diferentes propósitos. Por ejemplo, la aplicación del metamodelo UML a diferentes plataformas (tales como J2EE o .NET) o dominios (como sistemas de tiempo real o modelado de procesos de negocio (BPM)).

El mecanismo de perfiles no es un mecanismo de extensión de “primera

clase”, es decir no permite la modificación de metamodelos existentes. La intención de los perfiles es proporcionar un mecanismo directo para adaptar un metamodelo existente con constructores que son específicos para un dominio, plataforma o método particular. Dichas adaptaciones se agrupan en un perfil. No es posible eliminar ninguna restricción de los metamodelos de UML, pero es posible añadir nuevas restricciones que son específicas para el perfil. Las demás restricciones son inherentes al mecanismo de perfiles; no existe ninguna restricción más que limite la manera en la que un metamodelo es adaptado.

En nuestro caso, puesto que lo que se pretende es extender UML con el

propósito de mejorar la especificación de las asociaciones, incorporando constructores específicos para ello, se puede construir un perfil UML para las asociaciones.

4.5.1. Los Perfiles UML

Antes de abordar la construcción del perfil UML es necesario conocer la terminología utilizada en la construcción de perfiles, para ello en este apartado se introducen brevemente los conceptos básicos.

El paquete “Profiles” de UML contiene los elementos que se pueden

utilizar en la definición de un perfil. Entre éstos los más relevantes son las extensiones y los estereotipos. A continuación se introducen brevemente estos elementos del paquete “profiles”, más otros elementos que también se utilizan en la definición de perfiles.

• Estereotipos. Un estereotipo define cómo se puede extender una

metaclase de UML. Permite usar terminología y notación propia de un dominio o plataforma, adicional a la de la metaclase que extiende [UMLI2.0]. Un estereotipo es un tipo de Clase (“Class”) por lo que se le pueden asociar propiedades (“property”), que pueden ser definiciones etiquetadas (“tagged definition”), y restricciones (“constraint”). Un estereotipo tiene que ser usado siempre junto con

101

una metaclase a la que extiende, la cual se asocia al estereotipo a través de una extensión.

• Extensiones. Una extensión se utiliza para indicar que las

propiedades de una metaclase se extienden a través de un estereotipo, y proporciona la capacidad de añadir (y posteriormente eliminar) estereotipos a clases [UMLI2.0]

• Restricciones. Pueden asociarse a cualquier elemento de modelo

para redefinir su semántica.

• Definiciones Etiquetadas. Especifican nuevos tipos de propiedades que pueden asociarse a elementos de modelo. Los valores de estas propiedades pueden ser referidos como valores etiquetados (“tagged value”).

4.5.1.1. Ejemplo de Perfil.

Para facilitar la compresión de apartados posteriores a continuación se muestra un ejemplo de perfil UML. Para ello se presenta el ejemplo introducido en [REF] pag. 176: Supóngase que se quiere incluir en el modelo la abstracción “Clock” para representar clases con una propiedad adicional, resolution. En este caso es necesario extender (o adaptar) la metaclase Class. Para ello se define un estereotipo Clock con la propiedad resolution y una extensión entre la metaclase Class y el estereotipo Clock.

En la figura 4.17 se puede ver la representación gráfica del estereotipo Clock. Como se puede ver se ha extendido la metaclase Class, para lo que se ha añadido la definición etiquetada resolution. No se han añadido restricciones. Una vez definido el estereotipo se debe definir la definición etiquetada.

<<metaclass>>Class -resolution : int

<<stereotype>>Clock

Figura 4.17. Ejemplo de Estereotipo

4.5.2. Definición de un Perfil UML para la Asociación

El primer paso en la construcción de un perfil UML es identificar las extensiones a incorporar en el metamodelo UML. En nuestro caso, se deben identificar las diferencias del modelo propuesto para las asociaciones respecto al modelo que propone UML. Una vez identificadas las diferencias se pueden incorporar como extensiones al metamodelo utilizando perfiles. 4.5.2.1. Extensiones al Metamodelo UML En UML las asociaciones son instancias de la metaclase Association. Esta metaclase es una especialización de la metaclase Relationship. La asociación en UML conecta tipos mediante propiedades de dichos tipos. Las

102

propiedades son instancias de la metaclase Property. Los extremos de una asociación son propiedades de las clases participantes, por lo que son instancias de esta metaclase.

Las asociaciones de nuestro modelo poseen un atributo derivado, parte_de, que se utiliza para determinar si la relación es del tipo “parte_de”. Además las asociaciones se especializan en asociaciones reflexivas caracterizadas a través de tres propiedades adicionales: Reflexividad, Simetría y Transitividad.

La especificación de estas propiedades requiere la definición de atributos

adicionales en la metaclase Association. Esto es posible definiendo nuevas metaclases virtuales que extiendan a la metaclase Association y que añadan dichos atributos. Para ello, se creará a través de un estereotipo la clase virtual ExtendedAssociation. Esta clase se especializará en la clase virtual ExtendedReflexiveAssociation.

La clase ExtendedReflexiveAssociation deberá tener asociada una

restricción para especificar que cuando la asociación es del tipo “parte_de” (agregación o composición) el valor del atributo Reflexividad es siempre Antirreflexiva y el valor del atributo Simetría es siempre Antisimétrica. Si además la agregación es una composición, la relación es siempre Transitiva.

En UML, las propiedades de una clase (o tipo), poseen atributos que

permiten especificar las características de los extremos de las asociaciones. En nuestro modelo se ha propuesto un conjunto de características (propiedades del marco conceptual) diferente (algunas se corresponden con las propuestas por UML, otras son adicionales y otras no se consideran). Para representar las propiedades de nuestra aproximación en la metaclase Property, se deben redefinir los atributos de la siguiente manera:

1. Atributos sin modificación: Multiplicity, Changeability, Aggregation

(del tipo enumerado “AgreggationKind”, permite determinar si el extremo de la relación es una asociación simple (valor “none”), una agregación (valor “shared”) o una composición (valor “composite”)).

2. Atributos nuevos: Mutabilidad, Propagación de Borrado, Proyección

de Identificación y Navegabilidad.

3. Atributos con restricciones:

• isOrdered: permite definir colecciones de objetos ordenadas. En nuestro modelo, el conjunto de objetos asociados, no está ordenado, por lo que el valor del atributo toma siempre el valor unordered.

• isUnique: permite especificar si es posible tener más de un enlace

entre el mismo conjunto de objetos. Si el valor del atributo es false es posible, en otro caso no lo es. En la propuesta presentada es posible que exista más de un enlace con las mismas instancias asociadas (por ejemplo en una clase asociación). Por

103

ello el atributo tendrá el valor restringido a false, para lo que añadiremos una nueva restricción.

La redefinición de estos atributos requiere la extensión de la metaclase

Property con una metaclase virtual, a la que llamamos ExtendedProperty, que redefina los atributos a través de definiciones etiquetadas nuevas y restricciones. En el perfil es necesario definir un nuevo estereotipo, ExtendedProperty.

La metaclase Association mantiene una asociación con la metaclase Property, especificando que como mínimo una asociación tiene dos extremos (la multiplicidad mínima de la metaclase Association en el rol memberEnd es 2) y como máximo un número ilimitado (la multiplicidad máxima de la metaclase Association en el rol memberEnd es *). Nuestro modelo aborda exclusivamente relaciones binarias, por lo que la multiplicidad máxima en el rol memberEnd de la relación debe limitarse a 2. En el perfil debe aparecer una restricción que limite el valor de dicha cardinalidad máxima.

Una vez presentadas las extensiones a UML en los siguientes

subapartados se presentan los estereotipos, definiciones etiquetadas y restricciones que componen el perfil UML para las Asociaciones.

Figura 4.18. Perfil UML para las Asociaciones

104

4.5.2.2. Estereotipos En la figura 4.18 se muestra el perfil UML para las asociaciones. Como muestra la figura, en el perfil se definen los siguientes estereotipos: Estereotipo Clase Extendida Etiquetas Restricciones

ExtendedAssociation Association Whole-Part R14, R15, R16, R3

ExtendedReflexiveAssociation Association Reflexivity, Simmetry, Transitivity

R4, R13

ExtendedProperty Property Mutability, Delete Propagation, Identity Projection, Navigability

R1, R2, R5, R6, R7, R8, R9, R10, R11, R12

Estereotipo Descripción

ExtendedAssociation Redefine la metaclase Association para representar nuestras asociaciones.

ExtendedReflexiveAssociation Clase hija de la clase ExtendedAssociation. Representa asociaciones reflexivas caracterizadas por las propiedades Reflexividad, Simetría y Transitividad.

ExtendedProperty Redefine la metaclase Property para representar los extremos de las asociaciones y agregaciones. Los extremos se caracterizan por las propiedades Dinamicidad, Multiplicidad, Mutabilidad, Propagación de Borrado, Proyección de Identificación.

y las siguientes definiciones etiquetadas: Tag Estereotipo Tipo Mult Rest

Reflexitivity ExtendedReflexiveAssociation AssociationProfile:: Reflexitivity {Irreflexive, Not Reflexive, Reflexive}

1 Ninguna

Simmetry ExtendedReflexiveAssociation AssociationProfile:: Simmetry {Simmetric, Antysimetric, Not Simmetric}

1 Ninguna

Transitivity ExtendedReflexiveAssociation Boolean 1 Ninguna Whole-Part ExtendedAssociation Boolean

1 Ninguna

Mutability ExtendedProperty Boolean 1 Ninguna Delete Propagation

ExtendedProperty AssociationProfile:: Delete Propagation {Cascade, Link, Restrictive}

1 Ninguna

Navigability ExtendedProperty Boolean 1 Ninguna Identity Projection

ExtendedProperty Boolean 1 Ninguna

105

Tag Descripción

Reflexitivity Especifica si un objeto puede relacionarse con el mismo. Simmetry Especifica si un objeto puede relacionarse con otro que ya se relaciona

con él. Transitivity Especifica si la relación es Transitiva. Whole-Part Especifica si la relación es del tipo “parte_de”. Mutability Especifica si es posible sustutuir en un enlace un objeto por otro de su

misma clase. Delete Propagation

Especifica las acciones que deben llevarse a cabo cuando se destruye un objeto de la clase del extremo opuesto.

Identity Projection

Especifica si los objetos de la clase del extremo opuesto se identifican a través de los atributos identificadores de la clase.

Navigability Especifica si los objetos de la clase del extremo opuesto pueden acceder a los objetos de la clase asociada al extremo.

4.5.2.3. Restricciones Las restricciones definidas en el perfil son las siguientes:

R1: El valor del atributo isOrdered de cualquier extremo de una relación tiene que ser unordered.

context ExtendedProperty inv:

isOrdered = unordered

R2: Si la asociación no es una clase asociación, el valor del atributo isUnique de cualquier extremo de la relación tiene que ser true.

context ExtendedProperty inv:

self.association.type <>AssociationClass implies

isUnique = true

R3: No existen instancias de la metaclase Association. Las

asociaciones del modelo serán siempre instancias de la clase ExtendedAssociation o ExtendedReflexiveAssociation.

context Association inv:

self.allInstances->Empty()

R4: Cuando el atributo whole-part de una asociación tiene el valor

true, los atributos reflexivity y simmetry de la asociación toman el valor irreflexive y antisimmetric.

context ExtendedReflexiveAssociation inv:

whole-part = true implies reflexivity = irreflexive and simmetry = antisimmetric

106

R5: Cuando el atributo aggregation de un extremo de la asociación

tiene el valor composite, el atributo transitivity de la asociación toma el valor true.

context ExtendedProperty inv:

aggregation = composite implies association.transitivity = true

R6: Sólo un extremo de una asociación puede tener el valor cascade

en el atributo DeletePropagation (restricción originada por la DPD7 definida en el capítulo 3).

context ExtendedProperty inv:

deletePropagation = cascade implies association.memberEnd->select(e | e<>self and e.deletePropagation = cascade)->isEmpty()

R7: Sólo un extremo de una asociación puede tener el valor true en el atributo IdentityProjection (restricción originada por la DPD6 definida en el capítulo 3).

context ExtendedProperty inv:

identityProjection = true implies association.memberEnd->select(e | e<>self

and e.identityProjection = true)->isEmpty()

R9: Si un extremo de una asociación tiene el valor link en el atributo deletePropagation del extremo opuesto, el atributo changeability debe ser unrestrictive o addonly y el valor del atributo lowermultiplicity debe ser 0 (restricción originada por la dependencia DPD1 definida en el capítulo 3).

context ExtendedProperty inv:

deletePropagation = link implies association.memberEnd->select(e | e<>self and (e.changeability = unrestricted or e.changeability = addonly) and e.lowermultiplicity = 0 )->notEmpty()

107

R10: Si un extremo de una asociación tiene el valor true en el

atributo identityProjection, en el otro extremo de la asociación el valor del atributo uppermultiplicity y lowemultiplicity debe ser igual a 1 (restricción originada por la dependencia DPD2 definida en el capítulo 3).

context ExtendedProperty inv:

identityProjection = true implies association.memberEnd->select(e | e<>self and e.uppermultiplicity = 1 and e.lowermultiplicity = 1 )->notEmpty()

R11: Si un extremo de una asociación tiene el valor false en el atributo navigability, el valor del atributo deletePropagation debe ser igual a Cascade (restricción originada por la dependencia DPD5 definida en el capítulo 3).

context ExtendedProperty inv:

navigability = false implies deletePropagation <> Cascade

R12: Si un extremo de una asociación tiene el valor true en el

atributo mutability, el valor de los atributos del extremo opuesto uppermultiplicity y lowermultiplicity debe ser distinto, y el valor del atributo changeability debe ser unrestrictive (restricción originada por la dependencia DPD4 definida en el capítulo 3).

context ExtendedProperty inv:

mutability = true implies association.memberEnd->select (e | e <> self and e.lowermultiplicity <> e. uppermultiplicity and e.changeability = unrestrictive)->notEmpty()

R13: Si la asociación tiene el valor Reflexive en el atributo reflexivity, el valor del atributo lowermultiplicity en los dos extremos de la asociaicón debe ser mayor que 0 (restricción originada por la dependencia DPD3 definida en el capítulo 3).

context ExtendedReflexiveAssociation inv:

reflexivity = reflexive implies

108

memberEnd->forAll(e | e.lowermultiplicity>0)

R14: Cuando el valor del atributo whole-part de la asociación es true, uno de los dos extremos de la asociación debe tener en el atributo aggregation un valor distinto de none.

context ExtendedAssociation inv:

whole-part = true implies memberEnd->exists( e | e.aggregation <> none)

R15: Todas las relaciones son binarias.

context ExtendedAssociation inv:

memberEnd.size() = 2

R16: No existen instancias de la relación ownedEnd. La

navegabilidad se representa a través de una propiedad de la clase ExtendedProperty.

context ExtendedAssociation inv:

ownerEnd.size() = 0

4.6. Diseño de un Ayudante para el Modelado de Asociaciones

En el contexto del DDM es interesante proporcionar guías metodológicas que ayuden al analista en la tarea de modelado. En este apartado, se presenta una herramienta ayudante (“wizard”) que facilita al analista la especificación de asociaciones durante el modelado. Esta herramienta proporciona soporte metodológico para el modelado completo de las asociaciones.

La herramienta recoge información a través de preguntas, las cuales

permiten determinar el tipo de asociación que se está modelando (asociación, agregación o composición). Las preguntas son independientes del dominio y están orientadas a identificar las propiedades específicas de la asociación.

La estrategia utilizada para la formulación de las preguntas viene

inducida por la semántica de la abstracción y las dependencias existentes entre las distintas propiedades presentadas en el marco.

109

4.6.1. Descripción del Ayudante La herramienta desarrollada pretende dar soporte a los métodos de

modelado, utilizándose como complemento del diagrama de clases. La entrada y salida de la herramienta son:

o Entrada: las dos clases involucradas en la relación. o Salida: la asociación entre las dos clases participantes con la

especificación de las propiedades. El ayudante además determina si la relación entre las clases es una asociación, agregación o composición.

La idea básica del ayudante consiste en la formulación de una serie de

preguntas que capturen información de la relación existente entre dos clases. Las preguntas están orientadas a determinar el valor de las propiedades del marco conceptual. El proceso de formulación de preguntas se define de forma que se realicen el mínimo número de preguntas posibles. Las preguntas pretenden ser sencillas, con un conjunto de respuestas a seleccionar, sin que sea un prerrequisito conocer la semántica de las propiedades para responder a las preguntas.

Figura 4.19. Esquema de las preguntas del ayudante En la figura 4.19 se puede ver un esquema de las preguntas que realiza el ayudante. Cada rectángulo de la figura representa una pregunta. El nombre de las preguntas indica la propiedad del marco analizada (como se puede ver algunas propiedades se analizan a través de varias preguntas). Junto a las preguntas se indica el tipo de respuesta solicitada por cada una. Los rectángulos sombreados representan preguntas que se realizan para los dos extremos de la relación. A continuación se describen brevemente las preguntas y respuestas de cada una de las propiedades.

Pregunta Multiplicidad

Mínima (entero)

Pregunta Transitividad

(SI/NO)

Pregunta Propagación de Borrado I

(SI/NO)

Pregunta Propagación de Borrado II

(SI/NO)

Pregunta Proyección de Identificación

(SI/NO)

Pregunta Simetría (Selección

de un valor)

Pregunta Navegabilidad

(SI/NO)

Pregunta Mutabilidad

(SI/NO)

Pregunta Reflexividad (Selección de

un valor)

Pregunta Dinamicidad I

(SI/NO)

Pregunta Dinamicidad II

(SI/NO)

Pregunta Multiplicidad

Máxima (entero)

110

Pregunta Reflexividad: ¿un objeto puede conectarse a él mismo?

Las respuestas a esta pregunta son:

• (1) es posible, aunque no obligatorio • (2) es posible y obligatorio. • (3) no es posible

Si la respuesta seleccionada es la 1, la relación es No Reflexiva, si es la 2 es Reflexiva y si es la 3 es Antirreflexiva.

Pregunta Simetría: ¿un objeto puede ser conectado a otro objeto

el cual ya está conectado a él? Las respuestas a esta pregunta son:

• (1) es posible, aunque no obligatorio • (2) es posible y obligatorio • (3) no es posible

Si la respuesta seleccionada es la 1, la relación es No Simétrica, si es la 2 es Simetría y si es la 3 es Antisimétrica.

Pregunta Transitividad: ¿el hecho de que exista un enlace entre a

y b, y otro enlace entre b y c, implica que debe existir un enlace entre a y c? Las respuestas a esta pregunta son:

• SI • NO

Si la respuesta seleccionada es SI, la relación es Transitiva, si es NO la

relación es No Transitiva. Pregunta Multiplicidad Mínima: ¿un objeto de la clase A con

cuentos objetos de la clase B debe relacionarse como mínimo? Las respuestas a esta pregunta son:

• (1) no es necesario que se relacione con ningún objeto • (2) se debe relacionar con objetos

Si la respuesta seleccionada es la 1 el valor de la multiplicidad mínima es 0, si es la 2 el valor es el introducido por el usuario.

Pregunta Multiplicidad Máxima. ¿un objeto de la clase A con cuentas

objetos de la clase B puede relacionarse como máximo? Las respuestas a esta pregunta son:

• (1) no existe un número limitado de objetos • (2) como máximo se puede relacionar con objetos

Si la respuesta seleccionada es la 1 el valor de la multiplicidad máxima

es * (-1), si es la 2 el valor es el introducido por el usuario.

111

Pregunta Dinamicidad: Para determinar el valor de la propiedad dinamicidad se realizan dos preguntas.

- Dinamicidad I: ¿es posible añadir enlaces a un objeto de la

clase A una vez ha sido creado? Las respuestas a esta pregunta son:

• SI • NO

- Dinamicidad II: ¿es posible eliminar enlaces de un objeto de la clase A una vez ha sido creado? Las respuestas a esta pregunta son:

• SI • NO

Si la respuesta a las dos preguntas es SI, el valor de la propiedad

dinamicidad es Dinámica; si las dos respuestas son NO, es Estática; si la primera es SI y la segunda es NO es Incrementable; si la primera es NO y la segunda es SI es Decrementable.

Pregunta Mutabilidad: ¿es posible sustituir el objeto asociado b

de la clase B del objeto a por otro objeto de la clase B? Las respuestas a esta pregunta son:

• SI • NO

Si la respuesta es SI el extremo es Mutable, si es NO el extremo es No Mutable.

Pregunta Propagación de Borrado: Para determinar el valor de la

propiedad propagación de borrado se realizan dos preguntas.

- Propagacion Borrado I: ¿es posible destruir un objeto de la clase A si este objeto posee algún enlace con algún objeto de la clase B?

• SI • NO Si la respuesta es SI se pasa a la siguiente pregunta (Propagación Borrado II). Si la respuesta es NO el valor de la propagación de Borrado es Restrictivo.

- Propagacion Borrado II: ¿si destruimos un objeto de la clase A se destruyen también sus objetos asociados?

• SI • NO

112

Si la respuesta es SI el valor de la propiedad es Cascada, si la respuesta es NO el valor es Enlace.

Pregunta Proyección de Identificación: ¿los objetos de la clase A

se identifican a través de algún atributo de su objeto asociado de la clase B? Las respuestas a esta pregunta son:

• SI • NO

Si la respuesta es SI el extremo tiene el valor Proyectado, si es NO el

valor es No Proyectado. Pregunta Navegabilidad: ¿los objetos de la clase A pueden

acceder a sus objetos asociados de la clase B? Las respuestas a esta pregunta son:

• SI • NO

Si la respuesta es SI el extremo es Navegable, si es NO el extremo es No Navegable. 4.6.1.1. Pasos del Ayudante

El ayudante sigue los siguientes pasos: 1. Selección de las clases participantes en la relación dentro del

diagrama de clases. En este paso se indica además qué tipo de relación existe entre las clases, si es del tipo “parte_de” o no.

2. Proceso de formulación de preguntas. Este paso tiene como objetivo

identificar el valor de las propiedades del marco para la asociación analizada. El proceso de preguntas fluctúa en función de las respuestas que se van obteniendo. El proceso sigue un orden que permite realizar el mínimo número de preguntas posible. Para establecer el orden se debe tener en cuenta:

a. si la relación es reflexiva a nivel de clase, b. si la relación es del tipo “parte_de”, c. las dependencias entre las propiedades del marco.

Teniendo en cuenta estas consideraciones es posible identificar automáticamente el valor de algunas propiedades. El proceso de formulación de preguntas se presenta con más detalle en el apartado 4.6.2.

3. Especificación de la relación con los valores de las propiedades. El

usuario debe confirmar dicha especificación

113

4.6.2. Formulación de Preguntas El proceso de formulación de preguntas se muestra en la figura 4.20. Los rectángulos representan las preguntas. Los rombos indican bifurcaciones26. Algunas preguntas se acompañan de restricciones que validan la respuesta en función de otros valores de propiedades. La primera parte del proceso (rama superior de la figura) se inicia con la selección de las clases del diagrama de clases entre las cuales se va a definir una relación de asociación/agregación. Una vez las clases han sido identificadas y se ha definido el tipo de relación (si es del tipo parte_de o no), se extrae información sobre las propiedades Reflexividad, Simetría y Transitividad. Estas propiedades se aplican únicamente a relaciones reflexivas, por lo que sólo se formulan las preguntas asociadas a ellas cuando la relación es reflexiva (a nivel de clase). Además si la relación es del tipo “parte_de” los valores de la Reflexividad y Simetría poseen valores predeterminados, por lo que no se preguntan las cuestiones asociadas a estas dos propiedades (los valores se fijan automáticamente).

A continuación, el orden en el que se van realizando las preguntas de las propiedades está en función de las implicaciones que éstas tienen sobre otras propiedades. De esta manera, en la siguiente parte del proceso se recupera información referente a las propiedades Proyección de Identificación y Multiplicidad (Mínima y Máxima). Para la formulación de las preguntas se tienen en cuenta las siguientes dependencias:

• DPD 6: Si un extremo de la relación tiene el valor Proyectado, el extremo opuesto no puede tener este valor. Por esta dependencia si un extremo toma el valor Proyectado, no se solicita información referente a la propiedad Proyección de Identificación del extremo opuesto y se le asocia automáticamente el valor No Proyectado.

• DPD 2: Si un extremo de la relación toma el valor Proyectado, el

extremo opuesto debe tener como Multiplicidad Mínima el valor 1. Por esta dependencia si obtenemos la confirmación de que un extremo toma el valor Proyectado, no se solicita información referente a la propiedad Multiplicidad Mínima del extremo opuesto y se le asocia automáticamente el valor 1.

• DPD 3: Si la relación es Reflexiva la Multiplicidad Mínima de los dos

extremos debe ser mayor que 0. Esta dependencia origina una restricción que permitirá validar la respuesta a la pregunta referente a la Multiplicidad Mínima en caso de que el valor de la Reflexividad sea Reflexivo (para evitar que el valor de la Multiplicidad Mínima sea 0).

26 Las preguntas seguidas por un rombo tienen distintas preguntas destino, dependiendo de la respuesta recuperada. Las preguntas que no están seguidas de un rombo siempre llevan a la misma pregunta destino, independientemente de la respuesta.

114

A continuación se solicita información referente a las propiedades Propagación de Borrado y Dinamicidad. Para ello se tienen en cuenta las siguientes dependencias:

• DPD 7: Si un extremo de la relación tiene el valor Cascada, el extremo opuesto no puede tener este valor. Por esta dependencia, si en un extremo de la relación el valor de la propiedad es Cascada, en el extremo opuesto únicamente se realizará la primera pregunta asociada a la Propagación de Borrado. Si la respuesta a esta pregunta es SI, automáticamente se le da a la propiedad el valor Enlace (sin pasar a la siguiente pregunta asociada a la propiedad).

• DPD 1: Si un extremo de la relación tiene el valor Enlace, el extremo

opuesto debe ser Dinámico o Incrementable y la Multiplicidad Mínima debe ser 0. Esta dependencia tiene dos consecuencias:

o si se obtiene la confirmación de que un extremo tiene el valor Enlace, el valor de la primera pregunta asociada a la propiedad Dinamicidad del extremo opuesto se fija automáticamente (la respuesta a si es posible añadir enlaces a un objeto será SI) y únicamente se solicita información de la segunda pregunta.

o se origina una restricción para validar la respuesta sobre la Propagación de Borrado en caso de que la Multiplicidad Mínima del extremo opuesto sea distinta de 0 (para evitar que el valor seleccionado sea Enlace).

En la última parte del proceso (rama inferior de la figura) se recupera información sobre las propiedades Mutabilidad y Navegabilidad. En este caso se tiene en cuenta la siguiente dependencia:

• DPD 4: Si un extremo de la relación es Mutable el extremo opuesto debe ser Dinámico y la Multiplicidad Mínima debe ser distinta de la Multiplicidad Máxima. Esta dependencia origina una restricción que valida la respuesta a la pregunta de la Mutabilidad, evitando que el valor sea Mutable si el extremo opuesto no es Dinámico o la Multiplicidad Máxima y Mínima toman el mismo valor.

• DPD 5: Si en un extremo de la relación la Propagación de Borrado es

en Cascada, dicho extremo debe ser Navegable. Esta dependencia origina una restricción que valida la respuesta a la pregunta de la Navegabilidad, evitando que el valor sea false si el extremo tiene propagación de borrado en cascada.

115

Selección Clases

ENTRADARational Rose

¿relación reflexiva?

¿”parte_de”?si

no

Transtividad

Reflexivdad

Proyección IdentificaciónA

Simetria

si

noTranstividad

Proyección IdentificaciónA

¿proyectado?

si

MinA MaxA

Proyección IdentificaciónB

MinB

no

Propagación Borrado IA

¿restrictivo?

Dinamicidad IB Dinamicidad IIB

si

no

¿proyectado?

si

no

MaxB

MinB MaxB MinA MaxA

Propagación Borrado IIA

¿enlace?

Dinamicidad IB

si

Propagación Borrado IB

noDinamicidad IB Dinamicidad IIB

¿restrictivo?

Dinamicidad IA Dinamicidad IIA

Propagacion Borrado IB

¿restrictivo?

Dinamicidad IAno

si

si

Propagacion Borrado IIB

no

¿enlace?

Dinamicidad IA

si

Dinamicidad IA Dinamicidad IIAno

Propagacion Borrado IB

Propagacion Borrado IIB

Mutabilidad A Mutabilidad B Navegabilidad A Navegabilidad BConfirmación

de Valores

SALIDARational Rose

{ }Si Reflexiva Min > 0

{ }Si MinB <>0 PBA <> Enlace

{ }Si MinA <>0 PBB <> Enlace

{ }

Si DA <> Dinámica o MinA=MaxAMB <> Mutable

{ }

Si DB <> Dinámica o MinB=MaxBMA <> Mutable

{ si PB = Cascada -> N = true}

Figura 4.20. Proceso de Presentación de Formularios

116

4.6.3. Características Técnicas

La herramienta ha sido desarrollada como un anexo (“add-in”) de Rational Rose (herramienta de modelado de la compañía Rational Sofware de IBM, que utiliza la notación gráfica de UML).

El ayudante se integra como un componente más de Rational Rose, de tal forma que cuando se modela un diagrama de clases es posible utilizar el ayudante para modelar semi-automáticamente una asociación.

La implementación del ayudante conlleva dos tareas básicas:

• el desarrollo del ayudante como una aplicación, • la conexión entre Rational Rose y el ayudante.

El ayudante se ha desarrollado como una aplicación Windows común

utilizando el entorno de desarrollo Visual .NET. Se han diseñado 19 formularios que permiten recuperar la información requerida por el ayudante:

• un formulario inicial, para seleccionar las dos clases participantes, • 21 formularios de preguntas sobre las propiedades del marco, • un formulario final que muestra la propuesta de especificación de la

asociación.

En la figura 4.21 se muestra la ventana del ayudante donde se recopila información acerca de la propiedad Simetría. Este formulario permite recuperar información acerca de si la asociación es Simétrica, Antisimétrica o No Simétrica.

Figura 4.21. Ventana Simetría del ayudante.

117

4.6.3.1. Conexión Rational Rose y Ayudante La conexión entre Rational Rose y el ayudante se ha realizado

utilizando objetos COM. El ayudante interactúa con Rational Rose:

• al iniciarse, para obtener la información acerca de las clases

especificadas en el diagrama de clases, • al finalizar, para dibujar la relación generada en el diagrama de

clases.

El ayudante necesita por tanto una comunicación directa con Rational Rose. La comunicación desde el ayudante hacia Rational Rose se realiza utilizando los objetos COM. La comunicación desde Rational Rose hacia el ayudante se realiza mediante el registro del sistema operativo.

Para la integración del ayudante en Rational Rose se ha añadido una

entrada en el ítem Tools de la barra superior del menú de la herramienta. Esta entrada, identificada con el nombre “Wizard para las relaciones de asociación” (ver figura 4.22) permite lanzar a ejecución el ayudante. Para ello se ha modificado el fichero rose.mnu que contiene todas las entradas de la barra del menú principal de la herramienta. Cuando se lanza a ejecución el ayudante se llevan a cabo los siguientes pasos:

• Rational crea un objeto ayudante, • el ayudante captura la referencia de algún objeto Rational Rose

Aplication en funcionamiento, • el ayudante a través del objeto capturado puede acceder al diagrama

de clases.

118

Figura 4.22. Ampliación del menú Tools de Rational con la nueva entrada del ayudante.

4.7. Conclusiones En este capítulo se ha definido un modelo para las asociaciones construido a partir de las definiciones básicas de UML para la asociación y basado en el marco conceptual propuesto en el capítulo anterior. A partir de las definiciones propuestas por UML para los conceptos asociación, agregación y composición, se ha propuesto una caracterización completa y precisa para la asociación. Para ello, se ha introducido una interpretación semántica de los conceptos asociación, agregación y composición utilizando el marco conceptual propuesto en el capítulo anterior y basándonos en las nociones más aceptadas de los conceptos, presentes en diferentes aproximaciones metodológicas, intentando paralelamente no perder proximidad con el estándar UML. La utilización del marco conceptual como base para la construcción del modelo permite garantizar la calidad del modelo construido. Además las características del marco permiten definir un modelo para las asociaciones ejecutable de calidad.

119

Una vez descrito el modelo se ha utilizado la técnica de metamodelado para precisarlo y se ha construido un perfil UML para extender el lenguaje incluyendo los elementos de nuestro modelo. El perfil proporciona nuevos constructores que pueden utilizarse para construir esquemas conceptuales en UML. Por último, el capítulo presenta una herramienta ayudante que proporciona soporte metodológico al modelo propuesto, con lo que se completa y mejora el proceso de modelado de las asociaciones.

120

Capítulo 5 Generación de Código

En este capítulo se presenta un framework basado en el uso de patrones de diseño para la implementación de la asociación. El framework propone una implementación de la estructura y funcionalidad común de las asociaciones. La instanciación del framework, realizada en base a un conjunto de correspondencias definidas entre el modelo para las asociaciones y el framework, permite obtener la implementación de una asociación específica. Este paso se puede automatizar para abordar la construcción de generadores automáticos de código.

La representación software que propone el framework se estructura

siguiendo un estilo arquitectónico de tres niveles: nivel de presentación, nivel de aplicación y nivel de persistencia. El framework se centra fundamentalmente en el nivel de aplicación, donde se implementan los requisitos funcionales definidos por la asociación y sus propiedades.

5.1. Contexto

Las últimas tendencias en la Ingeniería del Software permiten mejorar la calidad del software generado. MDA propone utilizar como punto de partida para el desarrollo de software modelos conceptuales de alto nivel de abstracción para transformarlos en modelos convertibles a código en alguna tecnología específica. Las Factorías de Software proponen la utilización de frameworks para el desarrollo de sistemas similares que aumenten el nivel de abstracción de la tecnología destino. De esta manera, la cantidad de código generada a partir de los modelos de alto nivel de abstracción se reduce. Nuestra aproximación combina ambas tendencias. Por un lado, siguiendo la propuesta de las factorías de software se propone un framework para la implementación de la asociación. Por otro lado, siguiendo la propuesta de MDA se transforma el modelo de asociación en un modelo de bajo nivel de abstracción, de forma que éste sea fácilmente convertible a código.

La aplicación de ambas aproximaciones nos permite generar código

equivalente funcionalmente a la especificación de una asociación realizada utilizando el modelo presentado en el capítulo anterior. La propuesta para la generación de código se realiza definiendo:

o un framework de implementación que propone una estructura de

clases en el nivel de aplicación para la representación software de la asociación. El framework proporciona una solución software para la representación de la estructura y funcionalidad común de asociaciones caracterizadas por las propiedades del marco conceptual construido en el capítulo 3.

121

o las correspondencias que permiten llevar a cabo la instanciación del framework. Con la instanciación del framework se obtiene la representación software completa de una asociación específica27. Las correspondencias se definen entre el modelo de asociaciones construido en el capítulo anterior (PIM) y los elementos que constituyen la estructura de clases del framework.

La figura 5.1 representa de forma gráfica la estrategia utilizada para la

generación de código desde la perspectiva de MDA. A partir de un modelo de asociación (PIM), se realiza una transformación, definida en función de un conjunto de correspondencias determinadas a partir del framework, y se obtiene el conjunto de clases de diseño que implementan el modelo PIM.

Figura 5.1. Pasos seguidos para la generación de código desde el prisma de MDA

La figura 5.2 representa de forma gráfica la estrategia utilizada para la generación de código desde la perspectiva de las factorías de software. Se define un framework de implementación que permite reducir el “gap” existente entre el modelo de asociación y el código que implementa el modelo.

Figura 5.2. Estrategia para saltar el gap entre el modelo y la plataforma destino desde el prisma de las factorías de software

El framework se basa en un conjunto de patrones de diseño aplicables

en la implementación de la asociación. La utilización de patrones de diseño para la construcción del framework permite obtener estructuras de diseño de calidad que componen la solución software propuesta. Los patrones de

27 Usamos el término asociación específica cuando nos referimos a una asociación en concreto, es decir, a una instancia de la metaclase asociación en el modelo conceptual.

Modelo de Asociación

Código Generado

Framework

Plataforma

122

diseño utilizados han sido seleccionados entre un conjunto de patrones de diseño [Gam94] en función de diversos factores de calidad. 5.1.1. Arquitectura de las aplicaciones generadas

En la aproximación seguida en la tesis, enmarcada en el contexto del método OO-Method, las aplicaciones generadas se estructuran siguiendo una arquitectura multinivel que hace uso de distintos patrones arquitectónicos [ABM97, BRW96, BMRS]. Se utiliza como patrón genérico la arquitectura de tres niveles que divide la aplicación en tres partes interconectadas: el nivel de presentación donde se presentan los elementos software necesarios para llevar a cabo la interacción usuario-aplicación, el nivel de aplicación que proporciona los elementos software que implementan los requisitos funcionales que debe ofrecer la aplicación y el nivel de persistencia que proporciona los elementos software necesarios para dotar de persistencia a los datos de la aplicación.

La elección de este patrón se justifica gracias al elevado grado de

independencia existente entre los elementos de los distintos niveles, ya que son arquitecturas cerradas [RBPEL], reduciendo las dependencias entre niveles y permitiendo que los cambios se hagan con facilidad porque la interfaz de una de ellas sólo afecta al nivel siguiente. Estas arquitecturas permiten estructurar adecuadamente la aplicación en tres niveles lógicos con una funcionalidad independiente y bien diferenciada, lo que facilita la división adecuada de los esfuerzos de codificación y la especialización del trabajo de desarrollo.

Este capítulo se centra principalmente en la generación de código del

nivel de aplicación. En el nivel de aplicación se sitúan los elementos que implementan el comportamiento de las clases especificadas en la fase de modelado conceptual. La implementación de estos elementos se realiza de forma que se asegure la equivalencia funcional entre la descripción del sistema y su reificación en un lenguaje de programación OO, garantizando que se ofrece la funcionalidad especificada en la fase de modelado. Aunque existen aproximaciones que implementan la asociación en el nivel de persistencia, el contexto en el que se desarrolla la tesis opta por concentrar en el nivel de aplicación toda la lógica de los objetos de negocio, constituyendo una solución portable a distintos SGBD. Por ello, la implementación de la asociación se realiza completamente en este nivel.

La última parte del capítulo presenta la generación del nivel de

persistencia y el nivel de presentación. En el nivel de persistencia se exponen las directrices para la generación del esquema de la Base de Datos, y en el nivel de presentación se explica cómo afecta la presencia de asociaciones en el modelo conceptual a la interfaz gráfica de usuario.

El capítulo se estructura de la siguiente manera: en el siguiente apartado

se introduce la estructura del framework propuesto. Se presentan los patrones de diseño seleccionados para la construcción del framework y se combinan para obtener la estructura de clases de diseño que implementa la estructura y funcionalidad común de las asociaciones. En el tercer apartado se presenta cómo instanciar el framework para obtener la implementación

123

de un asociación específica. Para ello, se definen las correspondencias entre el modelo de asociación y el framework introducido. El cuarto apartado presenta la implementación de los métodos de las clases de diseño que componen la estructura del framework. Se propone la implementación para la creación, modificación y destrucción de enlaces, y para la creación y destrucción de objetos decoradores. Los apartados quinto y sexto presentan cómo se aborda la generación de código correspondiente a los niveles de presentación y persistencia respectivamente. Por último el apartado octavo presenta las conclusiones del capítulo. 5.2. Definición del Framework

La propuesta de implementación que se presenta en este capítulo, se compone de un framework de implementación construido utilizando patrones de diseño. Las estructuras de diseño que proponen estos patrones son estructuras probadas, y de alta calidad. Por ello, la utilización de patrones en la construcción de una solución software para la asociación permite mejorar la calidad de la implementación.

El framework proporciona la estructura y funcionalidad común de

asociaciones caracterizadas por las propiedades del marco conceptual construido en el capítulo 3.

En este apartado se introduce la estructura del framework. Para ello, en primer lugar (1) se identifican los factores de calidad que debe cumplir la implementación de la asociación. Basándonos en estos factores, (2) se seleccionan los patrones de diseño apropiados para implementar la asociación y sus propiedades. Una vez seleccionados los patrones de diseño, (3) éstos se combinan para obtener una estructura de clases de diseño que implemente la asociación. 5.2.1. Factores de Calidad

En este apartado se identifican tres factores que garantizan una estructura de diseño de calidad en la implementación de la asociación. Los tres factores de calidad identificados son consecuencia de las características específicas de la implementación de la asociación. Los factores identificados son los siguientes:

o Acoplamiento débil: Una asociación constituye una abstracción de

modelado que aporta al esquema conceptual un conocimiento adicional al propio de las clases participantes en la relación. La mayoría de propuestas de implementación introducen dependencias explícitas (referencias, atributos, métodos) consiguiendo así un acoplamiento fuerte entre las clases. En este sentido es importante que la implementación de la relación y las clases participantes sea lo más independiente (ortogonal) posible, para conseguir un acoplamiento débil.

o Separación de Responsabilidades: Los objetos de las clases

participantes, por el hecho de participar en una asociación, poseen un

124

comportamiento y una estructura adicional a la especificada por su clase. Es importante implementar este comportamiento y estructura adicional de forma separada del comportamiento y estructura propio de las clases participantes. De esta manera la mantenibilidad del software mejora considerablemente, ya que es más fácil identificar que partes del código deben modificarse cuando es necesario realizar una actualización.

o Reutilización y Genericidad: El comportamiento y la estructura

propia de las asociaciones se puede generalizar en su mayor parte a todas las relaciones. La implementación de relaciones específicas de forma independiente, implica tener gran cantidad de código duplicado en la aplicación. La reutilización de código, por ejemplo definiendo clases abstractas, métodos y estrategias de ejecución comunes para la creación y destrucción de enlaces, puede solucionar este problema.

La mayoría de las implementaciones existentes no cumplen estos

criterios (ver capítulo 2, apartado 2.4.1.6). Como consecuencia, las implementaciones propuestas son a menudo demasiado complejas, lo que dificulta su mantenimiento e impide que se cumplan gran parte de los factores de calidad del software.

Los patrones de diseño seleccionados para la construcción del framework

deben dar soporte a estos tres factores. 5.2.2. Selección de Patrones de Diseño

El primer paso en la aplicación de patrones de diseño para la construcción del framework, consiste en seleccionar los patrones de diseño apropiados. Los patrones de diseño seleccionados deben, por un lado, adecuarse a la abstracción asociación, y por otro lado, dar soporte a los tres factores de calidad identificados. En este caso se han seleccionado los siguientes patrones de diseño: 5.2.2.1. Patrón Mediador (“Mediator”) El patrón Mediador [Gam94] se utiliza para encapsular la interacción de distintos objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la información de forma independiente. Para ello el patrón define una clase mediadora encargada de encapsular la interacción de un conjunto de objetos de clases colega. El patrón se aplica en nuestra propuesta para implementar una clase de diseño que encapsule la interacción entre los objetos de las clases participantes. Esta clase representa la asociación en sí (mantiene las propiedades y operaciones de la asociación en caso de que las tuviera). En la figura 5.3 se muestra un ejemplo gráfico de la estructura de clases que se obtiene aplicando este patrón para el ejemplo de una asociación participar entre una clase Publicación y una clase Conferencia. En el ejemplo a la clase mediadora se le da el nombre MediadorParticipar. Con esta estructura se consigue un bajo acoplamiento entre las clases participantes,

125

que evita que los objetos se referencien explícitamente, permitiendo variar su interacción de forma independiente. Con la aplicación de este patrón se garantiza el acoplamiento débil y la reutilización de clases.

Publicacion Conferencia

MediadorParticipar

Figura 5.3. Estructura de Clases obtenida al aplicar el patrón Mediador

5.2.2.2. Patrón Decorador (“Decorator”) El propósito de este patrón [Gam94] es permitir la adición de funcionalidad a un objeto de forma dinámica. El patrón propone la definición de clases decoradoras que envuelven a una clase (clase decorada) sobre la que se añade funcionalidad de forma dinámica. En nuestra aproximación el patrón decorador se aplica para cada clase participante del modelo, de forma que la clase participante es la clase decorada y cada extremo en el que participe la clase se corresponde con una clase decoradora. Las clases decoradoras envuelven a la clase participante y permiten añadir de forma dinámica la funcionalidad introducida por las diferentes asociaciones que ésta mantiene. La figura 5.4 representa gráficamente la estructura de clases obtenida para el ejemplo de la clase Publicación que participa en las asociaciones firmar y participar. Como se ve en la figura se implementa una clase abstracta PublicacionAbstracta que define la interfaz de una publicación. De esta clase heredan la clase Publicación y una clase decoradora abstracta DecoradorPublicacion, de la que a su vez heredan las clases decoradoras que representan los distintos extremos en los que participa la clase Publicación (participar y firmar). Esta estructura de clases permite utilizar los objetos decoradores de una publicación como objetos de la clase publicación. Con la aplicación de este patrón se garantiza la separación de responsabilidades y la reutilización.

126

PublicacionAbstracta

Publicacion DecoradorPublicacionAbstracta

DecoradorPublicacionParticipar DecoradorPublicacionFirmar

Figura 5.4. Estructura obtenida tras la aplicación del patrón Decorador

5.2.2.3. Patrón Método Plantilla (“Template Method”) Este patrón [Gam94] propone la definición del esqueleto de un algoritmo en una operación delegando algunos pasos en las subclases. Así, se definen métodos plantilla con estrategias de ejecución en clases abstractas cuyos pasos se implementan posteriormente en las subclases de éstas. Nuestra propuesta aplica el patrón para implementar métodos que definan estrategias de ejecución comunes para las asociaciones. Para ello se define una clase abstracta de la clase mediadora, que define métodos plantilla para la implementación del comportamiento común de los enlaces. La figura 5.5 muestra un ejemplo gráfico de la estructura de clases diseñadas al aplicar el patrón Método Plantilla. En la figura se utiliza el ejemplo de la clase Publicación que posee dos asociaciones: participar y firmar. Con la aplicación de este patrón se garantiza la reutilización y la genericidad.

Figura 5.5. Estructura de clases obtenida tras la aplicación del patrón Método Plantilla

127

Los patrones de diseño seleccionados proponen soluciones probadas y de calidad para la implementación de estructura y comportamiento que aparece en la abstracción asociación. 5.2.3. Estructura del Framework En el apartado anterior se han identificado tres patrones de diseño que se pueden utilizar para implementar aspectos independientes de una asociación. En este apartado estos patrones se combinan para obtener una estructura de clases de diseño completa que implemente una asociación. La figura 5.6 muestra la estructura de clases de diseño genérica que representa un arquetipo de asociación (dos clases participantes conectadas a través de una asociación). A continuación se describen los elementos de la figura.

Las clases de diseño participantes (ClaseOrigen y ClaseDestino en la figura) implementan las clases participantes del modelo conceptual de acuerdo a su correspondiente especificación. En la figura usamos los términos Origen y Destino para distinguir las dos clases participantes. La aplicación del patrón Decorador, implica la definición de clases decoradas (DecoradorClaseOrigenNombreRol y DecoradorClaseDestinoNombreRol en la figura) que envuelven a las clases participantes y representan el extremo de la asociación que conecta la clase con la asociación. Estas clases implementan la estructura y el comportamiento añadido a las clases participantes como consecuencia de su participación en una asociación. Además la aplicación de este patrón conlleva la definición de clases decoradoras abstractas (DecoradorClaseOrigenAbstracta y DecoradorClaseDestinoAbstracta en la figura) que generalizan los decoradores de cada clase participante (estas clases representan la generalización de todos los extremos asociación conectados a una clase participante). Finalmente, el patrón implica la definición de una clase abstracta participante (ClaseOrigenAbstracta y ClaseDestinoAbstracta en la figura) a partir de la cual heredan la clase participante y la clase decoradora abstracta correspondiente. Las clases decoradoras abstractas mantienen una referencia a un objeto de esta clase, que representa el objeto decorado. Esta estructura de clases permite utilizar de la misma forma un objeto decorado (objeto de una clase participante) y un objeto decorador (objeto de una clase decoradora). El patrón Mediador se aplica con el objetivo de encapsular la interacción de los objetos participantes. La aplicación de este patrón implica la definición de una clase mediadora (MediadorNombreAsociacion en la figura) que implementa la estructura y comportamiento de la asociación (independientemente de las clases participantes). Esta clase conecta las clases decoradoras concretas que representan los extremos de la asociación (no conecta las clases participantes puesto que éstas se mantienen independientes).

128

El patrón Método Plantilla se aplica en el contexto de las clases mediadoras. Se define una clase abstracta (MediadorAbstracta en la figura) para las clases mediadoras concretas, que implementa la estructura y el comportamiento común de las asociaciones, describiendo estrategias de ejecución comunes. Esta clase define métodos plantillas para la creación y destrucción de enlaces e incluye una referencia a cada objeto participante (en la figura los atributos que representan estas referencias se denominan origen y destino). Finalmente, se define una interfaz (InterfazDecorador en la figura) que permite especificar los métodos que deben implementarse en las clases decoradoras. Las clases decoradoras abstractas implementan esta interfaz.

Figura 5.6. Estructura de diseño obtenida tras la aplicación de los patrones

129

La aplicación de los patrones de diseño en la definición del framework reporta beneficios en la implementación software de la asociación que conllevan una mejora de la reusabilidad y mantenibilidad del software. Fundamentalmente, existen dos aspectos que contribuyen a la calidad del framework:

• Definición de Estrategias de Ejecución Comunes. La aplicación

del patrón Método Plantilla permite la definición de métodos plantilla que implementan estrategias de ejecución para llevar a cabo la funcionalidad común de las asociaciones. Estas estrategias de ejecución definen las secuencias de pasos (métodos) necesarias para implementar la funcionalidad asegurando que se cumplen los requisitos definidos por las propiedades de la asociación.

• Independencia de Clases de Diseño. La aplicación de los patrones

Mediador y Decorador permiten reusar las clases participantes mejorando la mantenibilidad del software. Esta solución permite implementar:

o las propiedades y las operaciones de los enlaces en la clase

mediadora, o las propiedades y las operaciones específicas de los objetos

participantes (extremos de la asociación) en las clases decoradoras, y

o las propiedades y operaciones inherentes de las clases participantes en sus correspondientes clases de diseño.

La figura 5.7 muestra un ejemplo intuitivo de los objetos creados

siguiendo la estructura del framework propuesta, suponiendo una relación trabajaPara entre las clases Empleado y Compañía. En el ejemplo, Juan, objeto de la clase Empleado, está asociado al objeto IBM de la clase Compañía a través del objeto enlace JuanIBM. Los objetos Juan e IBM están decorados por los objetos decoradores, DecoradorJuan y DecoradorIBM, los cuales mantienen una referencia al objeto JuanIBM.

Figura 5.7. Un ejemplo de objetos asociados a través de la relación trabajaPara

130

5.3. Definición de Correspondencias. Instanciación del Framework Una vez se ha introducido el framework, en este apartado se definen las correspondencias entre la abstracción asociación y los elementos que constituyen el framework. La estructura del framework presentada en el apartado anterior define la estructura común de las asociaciones (nótese que los valores de las propiedades no se han tenido en cuenta en la definición de la estructura del framework). En el presente apartado las correspondencias determinan cómo instanciar el framework, de forma que a partir de una asociación específica sea posible obtener la estructura de clases en un lenguaje de programación OO que la implementa. Esta solución permite obtener una solución software de calidad que implementa las propiedades del marco conceptual. La definición de las correspondencias se realiza a través de descripciones en lenguaje natural estructurado, lo que nos permite definir una transformación intuitiva. Las correspondencias se definen:

• entre los elementos básicos que constituyen la asociación y las clases de diseño del framework: identificando por cada elemento del modelo conceptual las clases de diseño que lo representan, y

• entre las propiedades que caracterizan una asociación (en nuestro

caso estas propiedades son las presentadas en el marco conceptual introducido en el capítulo 3) y los elementos software del framework. Estas correspondencias se determinan en función de los valores de las propiedades e introducen restricciones funcionales y estructurales sobre la estructura del framework introducida. Estas restricciones:

- permiten o prohíben la existencia de atributos o métodos en una

clase de diseño, o

- implican comprobaciones u otras acciones cuando la propiedad afecta a la funcionalidad ejecutada.

La presentación de las correspondencias se divide en dos apartados

dependiendo del aspecto de implementación afectado:

• Vista Estructural: Se definen las correspondencias entre las estructuras conceptuales (elementos constituyentes de la asociación y propiedades estructurales) y las clases de diseño (clases, sus atributos y sus relaciones).

• Vista Funcional: Se definen las correspondencias entre propiedades

que especifican el comportamiento de la asociación y los métodos que implementan el comportamiento específico de ésta.

131

Las correspondencias que se presentan en este apartado se han definido formalmente en [MRAP04] utilizando las gramáticas de grafos [EEKR99]. En este trabajo se definen formalmente las correspondencias entre el modelo de asociación (PIM) y un modelo intermedio (PSM) que definimos explícitamente para representar clases de un lenguaje de programación orientado a objetos genérico. Las reglas de la gramática las definimos a partir del framework. Estas correspondencias definen una transformación modelo a modelo. Para la especificación de la transformación optamos por la técnica de las gramáticas de grafos porque éstas poseen una base formal sólida y una sintaxis gráfica que permite la especificación visual y operativa de transformaciones de modelos. La descripción mediante gramáticas de grafos puede implementarse a través de herramientas específicas (como ATOM [LV05] o AGG) de forma que es posible automatizar la transformación entre el modelo de asociaciones y el framework. Existen otras técnicas y herramientas que permiten realizar transformaciones automáticas entre modelos. Entre éstas destacan la propuesta de la OMG QVT 2.0 [QVT2.0], AGG o ATL.

A continuación, en el apartado 5.3.1, se presenta la correspondencia

entre las estructuras conceptuales y las clases de diseño (vista estructural del framework). En el apartado 5.3.2 se presenta la correspondencia entre propiedades de comportamiento y la implementación de los métodos (vista funcional del framework). 5.3.1. Vista Estructural

Este apartado presenta las correspondencias entre los elementos de la asociación en el modelo conceptual y los elementos de su representación software. La definición de las correspondencias hace posible obtener una estructura de clases de diseño que representa una asociación a partir de su especificación en el modelo conceptual. Para definir las correspondencias, se especifica: 1. cómo se implementan los elementos que constituyen una asociación

(clases participantes, extremos y asociación) 2. cómo se implementan las propiedades estructurales de la asociación

(dinamicidad, proyección de identificación, etc.) 5.3.1.1. Correspondencia entre los Elementos de la Asociación y las Clases de Diseño

El modelo propuesto para las asociaciones distingue tres elementos básicos correspondientes a las tres metaclases del metamodelo:

o las clases participantes o los extremos de la asociación o la asociación

Las correspondencias entre los tres elementos de una asociación y las

clases de diseño se definen haciendo uso de la estructura del framework

132

presentada en el apartado 5.2.3. A continuación se presentan estas correspondencias:

• Clase participante. Por cada clase participante se implementa:

o Una clase abstracta: define los atributos y operaciones de la clase participante, según la especificación de la clase en el modelo conceptual.

o Una clase concreta: hereda de la anterior clase abstracta e implementa la estructura y el comportamiento de la clase participante, según la especificación de la clase en el modelo conceptual.

o Una clase decoradora abstracta: define los atributos y operaciones de los objetos decoradores de la clase participante. Mantiene una referencia a un objeto de la clase participante abstracta. Este objeto es el objeto decorado. De esta forma, los objetos decoradores delegan en el objeto decorado el comportamiento propio de estos objetos.

• Asociación. Por cada asociación se implementa: o Una clase mediadora concreta: es una clase mediadora de las

clases decoradoras concretas.

• Extremo Asociación. Por cada extremo asociación se implementa: o Una clase decoradora concreta: hereda de la clase decoradora

abstracta correspondiente. Representa el extremo de la asociación en el que participa la clase e implementa la estructura y comportamiento asociado a éste.

En la tabla 5.1. se presenta un resumen de cómo se representan estos elementos mediante las clases de diseño.

Elemento del Modelo

Conceptual

Elemento de Diseño

Clase Participante Clase Abstracta Clase Concreta Clase Decoradora Abstracta

Asociación

Clase Mediadora Concreta

Extremo Asociación Clase Decoradora Concreta

Tabla 5.1. Correspondencia de los componentes de una asociación y los elementos de la solución software

La figura 5.8 muestra un ejemplo de las correspondencias entre los

elementos de una asociación y las clases de diseño de la implementación. En este ejemplo se especifica una relación firmar entre una clase Publicación y una clase Firmante. Como resultado de la instanciación del framework se implementa:

133

o una clase de diseño abstracta por cada clase del dominio: PublicacionAbstracta y FirmanteAbstracta,

o una clase de diseño por cada clase del dominio participante: Publicacion y Firmante, cada una hereda de una clase abstracta

o una clase mediadora: MediadorFirmar, o una clase decoradora abstracta por cada clase participante:

DecoradorPublicacion y DecoradorFirmante, cada una hereda de una de las clases abstractas anteriores.

o una clase decoradora concreta por cada extremo asociación: DecoradorPublicacionFirmar y DecoradorFirmanteFirmar. Estas clases heredan de las clases decoradoras abstractas. Ambas clases mantienen una referencia a la clase MediadorFirmar.

Figura 5.8. Ejemplo de aplicación del framework para una asociación

La figura 5.9 muestra un ejemplo de instanciación del framework donde aparece una clase que posee dos asociaciones. En este ejemplo la clase Publicación participa en dos relaciones, la asociación firmar con la clase Firmante y la asociación participar con la clase Congreso. Como resultado de la instanciación del framework se implementa:

o una clase de diseño abstracta por cada clase del dominio

participante: PublicacionAbstracta, FirmanteAbstracta y CongresoAbstracta

134

o una clase de diseño por cada clase del dominio participante: Publicación, Firmante y Congreso, cada una hereda de una clase abstracta

o una clase decoradora abstracta por cada clase participante:

DecoradorPublicacion, DecoradorFirmante y DecoradorCongreso, cada una hereda de una de las clases abstractas anteriores

o para la asociación firmar:

• una clase mediadora: MediadorFirmar, • una clase decoradora que implementa el extremo de la clase

Firmante: DecoradorFirmanteFirmar. Hereda de la clase DecoradorFirmante y mantiene una referencia a la clase MediadorFirmar,

• una clase decoradora que implementa el extremo de la clase Publicación: DecoradorPublicacionFirmar. Hereda de la clase DecoradorPublicación y mantiene una referencia a la clase mediadora MediadorFirmar.

o para la asociación participar:

• una clase mediadora: MediadorParticipar, • una clase decoradora que implementa el extremo de la clase

Congreso: DecoradorCongresoParticipar. Hereda de la clase DecoradorCongreso y mantiene una referencia a la clase MediadorParticipar,

• una clase decoradora que implementa el extremo de la clase Publicación: DecoradorPublicacionParticipar. Hereda de la clase DecoradorPublicación y mantiene una referencia a la clase mediadora MediadorParticipar.

135

participat

Figura 5.9. Ejemplo de aplicación del framework para una clase con dos asociaciones

La figura 5.10 muestra un ejemplo de las correspondencias entre los elementos de una asociación reflexiva y las clases de diseño de la implementación. En el ejemplo de la figura se especifica una asociación reflexiva esJefe de una clase Empleado. Como resultado de la instanciación del framework, se implementa:

o una clase EmpleadoAbstracta, o una clase Empleado que hereda de EmpleadoAbstracta

o una clase DecoradorEmpleado, hereda de la clase EmpleadoAbstracta

o una clase mediadora MediadoresJefe, o una clase decoradora DecoradorEmpleadoSubordinado que

implementa el extremo de la asociación subordinado. Hereda de la clase DecoradorEmpleado y mantiene una referencia a la clase MediadoresJefe.

o una clase decoradora DecoradorEmpleadoJefe. que implementa el extremo de la asociación jefe. Hereda de la clase DecoradorEmpleado y mantiene una referencia a la clase MediadoresJefe.

136

Empleado -subordinado

-jefe esJefe

Espacio del Problema

Empleado

MediadoresJefe

1

*

Espacio de la Solución

Mediador

*

1

DecoradorEmpleadoJefe DecoradorEmpleadoSubordinado

DecoradorEmpleado

EmpleadoAbstracto

Figura 5.10. Ejemplo de aplicación del framework para una asociación reflexiva

A continuación se presenta la implementación de las clases de diseño.

Para ello se utiliza el lenguaje C#. Se ha escogido C# como lenguaje representativo de un lenguaje de programación OO. Este lenguaje se utilizará en adelante para presentar los detalles de código necesarios en este capítulo. Las expresiones particulares del lenguaje C# que se presenten, pueden adaptarse a cualquier lenguaje de programación OO que se considere oportuno.

Clase Abstracta Descripción

public asbstract class NomClaseAbstracta{ ... }

• Define la estructura y el comportamiento de una clase participante independientemente de la asociación en la que participa.

137

Clase Concreta Descripción public class NomClase: NomClaseAbstracta{ ... }

• Hereda de la clase abstracta participante.

• Implementa la estructura y el comportamiento de una clase participante.

Interfaz Decorador Descripción public interfaz Decorador { ... }

• Define la interfaz de las clases decoradoras.

Clase Decoradora Abstracta Descripción public abstract class DecoradorNomClase: NomClaseAbstracta, Decorador{ NomClaseAbstracta decorado; ... }

• Hereda de la clase de abstracta participante.

• Implementa la interfaz Decorador

• Define una referencia a un objeto de la clase abstracta participante, objeto al que decora.

Clase Decoradora Concreta Descripción public class DecoradorNomClaseNomRol28: DecoradorNomClase{ ArrayList coleccionEnlaces; ... }

• Implementa las operaciones públicas de la clase participante que envuelve, delegando en las operaciones de ésta a través del objeto decorado heredado.

• Define una referencia a la colección de enlaces. Esto permite a los objetos decoradores acceder a sus enlaces.

Clase Mediadora Abstracta Descripción public abstract class Mediador{ protected Decorador origen; protected Decorador destino;

• Define métodos plantilla para la creación y destrucción de enlaces.

• Define una referencia 28 Si no existe el nombre del rol se puede utilizar el nombre de la asociación en lugar del nombre del rol, siempre que no de lugar a ambigüedad.

138

... }

privada a los objetos decoradores que participan en el enlace29.

Clase Mediadora Descripción

internal30 class MediadorNomAsociacion: Mediador{ public Decorador obtener_origen(){ return origen; } public Decorador obtener_destino(){ return destino; } ... }

• Implementa los pasos de los métodos plantilla de la clase abstracta de la que hereda.

• Es accesible sólo por sus clases colegas, clases decoradoras (otras clases cliente no pueden acceder a ella).

• Define un método consultor para cada objeto participante.

5.3.1.2. Correspondencia entre las Propiedades Estructurales y Atributos y Métodos de Diseño. En este apartado se expone cómo representar las propiedades de la asociación que afectan a su estructura sobre los distintos elementos software (clases, atributos y métodos) que la implementan. Estas propiedades son:

- dinamicidad - mutabilidad - proyección de identificación - navegabilidad

A continuación se presenta con detalle la representación software de cada una de ellas. Dinamicidad. Esta propiedad especifica si un objeto de una clase puede dinámicamente durante su vida, conectarse o desconectarse (creando o destruyendo enlaces) a uno o más objetos de su clase asociada. Los valores de la propiedad son: • Dinámico: Los enlaces pueden añadirse o eliminarse a/de los objetos del

extremo opuesto sin ninguna restricción temporal. Esta situación implica que deben incluirse métodos en la clase de diseño que gestiona el ciclo

29 Se utilizan los nombres origen y destino en las referencias para distinguir de forma genérica los dos objetos participantes. 30 En c# se utiliza el modificador internal para indicar que una clase es únicamente visible dentro de su ensamblado. En este caso se construiría un ensamblado con la clase mediadora más sus clases decoradoras.

139

de vida de los enlaces, para que proporcionen dicha funcionalidad. Estos métodos son los métodos insertar y borrar, y se añaden a la clase decoradora que implementa el extremo opuesto.

• Estático: Los enlaces no pueden modificarse después de la creación del objeto, por tanto los métodos para añadir o eliminar enlaces no deben añadirse a la clase.

• Incrementable: Es posible añadir enlaces a los objetos del extremo opuesto, pero no es posible eliminar enlaces. Para implementar esta funcionalidad se incluye el método insertar en la clase de diseño del extremo opuesto.

• Decrementable: Es posible eliminar enlaces de los objetos del extremo opuesto, pero no es posible añadir enlaces. Para implementar esta funcionalidad se incluye el método borrar en la clase de diseño del extremo opuesto.

Ejemplo. Consideremos el ejemplo de una clase Profesor asociada a una clase Departamento a través de una relación pertenece. En el ejemplo el extremo Profesor es Dinámico, puesto que durante la vida del departamento éste puede contratar o despedir profesores. Sin embargo, el extremo de la clase Departamento es Estático, asumiendo que un profesor siempre pertenece al mismo departamento. En la definición de la clase decoradora de Departamento, se implementan los siguientes métodos: public class DecoradorDepartamentoPertenece: DecoradorDepartamento{

public Mediador insertar (...){ //inserta un profesor en el departamento ... } public void borrar(...){ //borra a un profesor del departamento ... }

} La implementación de los métodos insertar y borrar se presenta en los apartados 5.4.2 y 5.4.3 respectivamente. Mutabilidad. Esta propiedad especifica si un objeto participante en un enlace, puede durante su vida ser sustituido por otro objeto de su misma clase. Los valores de la propiedad son: • Mutable: Los objetos de la clase puede ser sustituidos por otros objetos

de la clase en el enlace en el que participan. Para dar soporte a esta funcionalidad es necesario definir un método modificar en la clase del extremo opuesto, que permita sustituir en un enlace un objeto de la clase asociada por otro.

• No Mutable: Los objetos de la clase no pueden ser sustituidos por otros objetos, por lo que no es necesario añadir ningún método.

Ejemplo. Consideremos el ejemplo de una clase Barco asociada a una clase Patrón a través de una relación pratonear. En el ejemplo el extremo Patrón

140

es Mutable, puesto que en un enlace entre un patrón y un barco, es posible sustituir el patrón de un barco por otro patrón. Sin embargo, el extremo de la clase Barco es No Mutable, puesto que en un enlace no es posible sustituir un barco por otro barco. En la definición de la clase decoradora de Barco, se debe implementar el siguiente método: public class DecoradorBarcoPatronear: DecoradorBarco{

public Mediador modificar(...){ //sustituye al patrón de un barco por otro ... }

} La implementación del método modificar se presenta en el apartado 5.4.4. Proyección de Identificación. Esta propiedad especifica si una clase participante proyecta su mecanismo de identificación sobre su clase asociada. Los valores de la propiedad son: • Proyectado: La clase de diseño decoradora incluye los atributos

identificadores de su clase asociada para identificar sus instancias. • No Proyectado: No se realiza ninguna modificación adicional sobre la

estructura del framework introducida. Ejemplo. Consideremos el ejemplo de una clase Ciudad asociada a una clase Comunidad a través de una relación pertenece. En el ejemplo, la clase Comunidad proyecta su identidad en la clase Ciudad (PICiudad = Proyectado). En la definición de las clases decoradoras, se implementa el siguiente código: public class DecoradorComunidadPertenece: DecoradorComunidad {

private string codComunidad; .... public string obtenerCodComunidad(){ return codComunidad; }

} public class DecoradorCiudadPertenece: DecoradorCiudad {

private string codCiudad; private string nombre; .... public string obtenerCodCiudad(){ return String.Concat(decorado.obtenerCodComunidad(), codCiudad); }

} Navegabilidad. Esta propiedad especifica si un objeto de una clase participante puede acceder a sus objetos asociados. Los valores de la propiedad son:

141

• Navegable: No se realiza ninguna modificación adicional sobre la estructura del framework introducida. Nótese que la navegabilidad implica que los objetos del extremo opuesto pueden acceder a los objetos de la clase. El framework permite esta accesibilidad ya que los objetos participantes contienen referencias a sus enlaces y éstos a su vez contienen referencias a los objetos participantes (los métodos consultores permiten el acceso a estos objetos). Los objetos pueden acceder a sus objetos asociados a través del enlace.

• No Navegable: Los objetos del extremo opuesto no pueden acceder a los objetos de la clase. Para evitar este acceso, los enlaces no deben proporcionar acceso al objeto participante del extremo no navegable. Este comportamiento se implementa convirtiendo en la subclase mediadora el método consultor que devuelve el objeto del extremo no navegable en un método privado. Esto impide que los objetos de otras clases accedan a él.

Ejemplo. Consideremos el ejemplo de la clase Empleado relacionada con una clase Compañía a través de la relación trabajaPara, siendo el extremo de la clase Compañía No Navegable. En la clase mediadora, se implementa el siguiente código (los objetos del extremo No Navegable están representados por la referencia destino): public class MediadorTrabajaPara: Mediador{

private Decorador obtener_destino(){ return destino;

} ....

} 5.3.2. Vista Funcional La especificación de una asociación introduce un comportamiento específico, independiente al de las clases participantes. Este comportamiento debe reflejarse en la implementación del modelo mediante funcionalidad adicional a la proporcionada por las clases participantes. Esta funcionalidad adicional es la siguiente: • Creación, Destrucción y Modificación de Enlaces: permite la creación, destrucción y modificación de enlaces entre objetos de clases participantes. • Creación y Destrucción de Objetos Participantes: permite la creación y destrucción de objetos participantes. En el siguiente apartado se presenta la correspondencia entre las propiedades de comportamiento de la asociación y los métodos que implementan la funcionalidad específica de las asociaciones. La implementación completa de la funcionalidad, con la implementación de todos los métodos que la soportan, se presenta en el apartado 5.4.

142

5.3.2.1. Correspondencia entre Propiedades de la Asociación y Métodos de Diseño En este apartado se expone cómo representar las propiedades de la asociación que afectan a su comportamiento sobre los métodos de diseño. Estas propiedades son:

- multiplicidad - reflexividad - simetría - transitividad - propagación de borrado

Para cada una de estas propiedades se analiza:

1. cuál es la condición que debe cumplirse para cada valor de la propiedad. Siguiendo el criterio mantenido en la tesis de no perder proximidad con el estándar UML, las restricciones asociadas a las propiedades se presentan como condiciones expresadas en el lenguaje OCL, y

2. dónde debe comprobarse esta condición, es decir, en qué parte del

código que implementa la funcionalidad de la asociación es necesario comprobarla.

A continuación se presenta con detalle la representación software de cada una de las propiedades. Multiplicidad. Esta propiedad define una restricción que debe cumplir la asociación. La condición asociada a la restricción se define sobre el atributo coleccionEnlaces (atributo definido en las clases decoradoras, ver tablas de la sección 5.3.1.1), el cual mantiene los enlaces de los objetos decoradores. La condición OCL es: context od: DecoradorNomClaseNomRol inv:

Min ≤ od.coleccionEnlaces.size() ≥ Max Multiplicidad Máxima: • Max <> n: el framework debe asegurar que la restricción se satisface. • Max = n: no es necesario realizar ninguna comprobación (la condición

siempre se cumple). Multiplicidad Mínima: • Min > 0: el framework debe asegurar que se satisface la restricción. • Min = 0: no es necesaria ninguna comprobación (la condición siempre

se cumple). La comprobación de la propiedad se debe realizar en la implementación de las funcionalidades que llevan a cabo actualizaciones sobre el atributo coleccionEnlaces. A continuación se presentan cuales son estas funcionalidades, distinguiendo las que afectan a la multiplicidad máxima y las que afectan a la multiplicidad mínima (puesto que la primera implica que

143

se actualice la colección añadiéndole algún elemento y la segunda implica que se inicialice la colección o se actualice eliminando algún elemento). Multiplicidad Máxima:

• creación de enlaces, • modificación de enlaces,

Para garantizar el cumplimiento de esta restricción, en la implementación de estas funcionalidades se incorporará una llamada al método: comprobar_multiplicidad_maxima, el cual se encargará de comprobar que se cumple la condición de multiplicidad máxima.

Multiplicidad Mínima:

• modificación de enlaces, • destrucción de enlaces, • creación de objetos decoradores.

Para garantizar el cumplimiento de esta restricción, en la implementación de estas funcionalidades se incorporará una llamada al método: comprobar_multiplicidad_minima, el cual se encargará de comprobar que se cumple la condición de multiplicidad mínima. Reflexividad. Esta propiedad especifica si puede existir un enlace entre un objeto y él mismo. La condición se define sobre los atributos de los enlaces origen y destino, que representan a los objetos participantes (atributos definidos en la clase mediadora abstracta, ver tablas de la sección 5.3.1.1). Los valores de la propiedad son: • Irreflexiva. El framework debe satisfacer la siguiente condición:

context e: MediadorNomAsociacion inv: e.origen <> e.destino

• No Reflexiva. No existe ninguna restricción. • Reflexiva. El framework debe satisfacer la siguiente condición:

context DecoradorNomClaseNomRol inv: DecoradorNomClaseNomRol.allInstances->forAll(d| exists(e | d.coleccionEnlaces->select(e) and e.origen = e.destino)

La comprobación de la propiedad se debe realizar en la implementación de las funcionalidades que llevan a cabo actualizaciones sobre los atributos origen y destino. Estas funcionalidades son:

• creación de enlaces, • destrucción de enlaces y • modificación de enlaces

144

Además como la reflexividad afecta a todas las instancias de una clase participante se debe comprobar también en la:

• creación de objetos participantes Para garantizar el cumplimiento de esta restricción, en la implementación de estas funcionalidades se incorporará una llamada al método: comprobar_reflexividad, el cual se encargará de comprobar que se cumple la condición de reflexividad.

Simetría. Esta propiedad especifica si puede existir un enlace entre un objeto a y un objeto b, si existe en el sistema un enlace entre el objeto b y el objeto a. Los valores de la propiedad son: • Antisimétrica. El framework debe satisfacer la siguiente condición: context e1,e2: MediadorNomAsociacion inv: e1.origen <> e2.destino or e2.origen <> e1.destino • Simétrica: El framework debe satisfacer la siguiente condición: context MediadorNomAsociacion inv: MediadorNomAsociacion.allInstances->forAll(e1| exists(e2| e1.origen = e2.destino and e2.origen = e1.destino)) • No Simétrica: No existe ninguna restricción. La comprobación de la propiedad se debe realizar en la implementación de las funcionalidades que lleven a cabo alguna actualización de los atributos origen y destino. Estas funcionalidades son:

• creación de enlaces, • destrucción de enlaces y • modificación de enlaces

Para garantizar el cumplimiento de esta restricción, en la implementación de estas funcionalidades se incorporará una llamada al método: comprobar_simetría, el cual se encargará de comprobar que se cumple la condición de simetría. Transitividad. Esta propiedad especifica si cuando existe un enlace entre un objeto a y un objeto b, y un enlace entre el objeto b y un objeto c, entonces existe un enlace entre el objeto a y el objeto c. • Transitiva: Es necesario implementar automáticamente los enlaces

transitivos (enlaces derivados de la transitividad de la relación).

• No Transitiva: El framework no debe realizar ninguna condición.

145

La comprobación de la propiedad se debe realizar en la implementación de las funcionalidades que impliquen la creación, modificación o destrucción de enlaces transitivos. Estas funcionalidades son:

• creación de enlaces, • destrucción de enlaces y • modificación de enlaces

Para garantizar el cumplimiento de esta restricción, en la implementación de estas funcionalidades se incorporará una llamada al método: comprobar_transitividad, el cual se encargará de comprobar que se cumple la condición de transitividad. Propagación de Borrado. Esta propiedad especifica las acciones que deben llevarse a cabo cuando un objeto es destruido. Los valores de las propiedades son: • Restrictivo: El objeto sólo puede ser destruido si no tiene ningún enlace.

Si existe algún enlace se lanza una excepción. • Enlace: Todos los enlaces del objeto deben ser eliminados cuando se

destruye el objeto. • Cascada: Los enlaces del objeto y los objetos asociados deben

destruirse. La propiedad propagación de borrado determina el comportamiento de la destrucción de objetos participantes. Para garantizar el cumplimiento de la propiedad en la implementación de esta funcionalidad se incorporará una llamada al método: propagar_borrado_destrucción, el cual realizará las operaciones correspondientes para que se cumpla la condición de propagación de borrado. Propagación de Borrado + Dinamicidad. La combinación de ambas propiedades determina las acciones que se deben llevar a cabo cuando se desconecta un enlace de un objeto decorador. Esto sucede durante la eliminación o modificación de un enlace. La combinación de las propiedades y su correspondiente implicación es la siguiente: • (RestrictivoA || CascadaA || EnlaceA) & DinamicoB: No se realiza ninguna

comprobación durante la eliminación o modificación de enlaces de objetos de la clase B.

• RestrictivoA & EstaticoB: No se puede borrar o modificar un enlace de un objeto de la clase B, se devuelve una excepción.

• CascadaA & EstaticoB: Al borrar o modificar un enlace de un objeto de la clase B se destruye el objeto de la clase A que se desconecta.

La combinación de ambas propiedades implica un determinado comportamiento en la destrucción y modificación de enlaces. Para garantizar el cumplimiento de estas condiciones en la implementación de esta funcionalidad se incorporará una llamada al método:

146

propagar_borrado_desconexion, el cual se encargará de realizar las operaciones oportunas para que se cumplan las condiciones especificadas. En la tabla 5.2 se puede ver un resumen de los métodos que se utilizarán en la implementación de las distintas funcionalidades ofrecidas por la asociación.

Creación de

Enlaces

Destrucción de

Enlaces

Modificación de

Enlaces

Creación de

Objetos Asociados

Destrucción de

Objetos Asociados

Comprobar_multiplicidad_maxima √ * √ * * Comprobar_multiplicidad_minima * √ √ √ * Comprobar_simetria √ √ √ * * Comprobar_reflexividad √ √ √ √ * Comprobar_transitividad √ * √ * * propagar_borrado_destrucción * * * * √ propagar_borrado_desconexion * √ √ * *

Tabla 5.2. Representación de las propiedades de comportamiento sobre las distintas funcionalidades

5.3.3. Implementación de Correspondencias

Las correspondencias definidas en este apartado y la propuesta para la implementación de métodos que se presenta en el apartado 5.4 permiten llevar a cabo la transformación entre el modelo de asociaciones y su representación software (transformación de PIM a código).

La implementación de esta transformación puede realizarse utilizando

algunas de las herramientas y lenguajes que existen actualmente para llevar a cabo transformaciones de modelo a texto. En el anexo B se implementa esta transformación de modelo a texto utilizando los plugins de Eclipse para la gestión de modelos. Concretamente, se utiliza EMF [EMF] para editar y hacer persistentes los modelos, y MOFScript [MFS] para especificar y aplicar las transformaciones de modelo a texto. La implementación de esta transformación constituye un generador de código completo para la asociación.

La utilización de transformaciones de PIM a código nos permite construir un generador de forma rápida sin la necesidad de invertir tiempo en la construcción de un PSM y una transformación de PSM a código. Esta aproximación posee ventajas y desventajas que se explicitan en el anexo B.

147

5.4. Implementación de Métodos

Este apartado completa la propuesta de representación software de la asociación, proponiendo una implementación para los métodos que dan soporte a la funcionalidad específica de ésta.

Como se ha presentado en el apartado 5.3.2, las asociaciones requieren la implementación de funcionalidad adicional a la ofrecida por las clases participantes. Esta funcionalidad o comportamiento específico es el siguiente:

o Creación de enlaces o Destrucción de enlaces o Modificación de enlaces o Creación de objetos participantes o Destrucción de objetos participantes Esta funcionalidad se implementa a través de métodos de las clases de

diseño del framework. En los siguientes apartados se presenta con detalle la implementación de estos métodos.

Antes de presentar la implementación, se introduce la estrategia utilizada para implementar la funcionalidad de la asociación. Esta estrategia permite garantizar el cumplimiento de las restricciones asociadas a las propiedades de la asociación.

5.4.1. Estrategia de Implementación

La funcionalidad específica de la asociación se implementa a través de métodos de las clases decoradoras y de la clase mediadora. Como se ha presentado en el apartado 5.3.2.1 esta funcionalidad debe satisfacer una serie de restricciones que vienen determinadas por las propiedades de la asociación. Esto implica que se debe comprobar el cumplimiento de estas propiedades durante la ejecución de dicha funcionalidad.

Para poder garantizar el cumplimiento de estas restricciones se utiliza

una estrategia de implementación basada en la aplicación del Patrón Método Plantilla. Este patrón se utiliza para definir estrategias de ejecución que dan soporte a estas funcionalidades:

• Las clases abstractas del framework definen algoritmos (métodos)

que especifican los pasos (métodos) de las estrategias que implementan partes de la funcionalidad común de las asociaciones.

• Las subclases de estas clases abstractas implementan los pasos en función del valor de la propiedad de cada asociación específica.

Por otro lado, la responsabilidad de la comprobación de las propiedades

se distribuye entre las clases decoradoras y mediadoras dependiendo del elemento de la asociación sobre el que se aplican:

148

o Propiedades de la relación: las clases mediadoras son responsables de garantizar que el sistema satisface las propiedades

Reflexividad, Simetría y Transitividad, puesto que estas clases implementan la estructura y el comportamiento de las asociaciones.

o Propiedades de los extremos: las clases decoradoras son

responsables de garantizar que el sistema satisface las propiedades

Multiplicidad y Propagación de Borrado, puesto que estas clases implementan la estructura y el comportamiento de los extremos de las asociaciones.

A lo largo del capítulo la propuesta de implementación de los métodos se

ejemplifica a través de implementaciones en código C#. Para algunos casos se han obviado detalles de implementación que no son de relevancia para la ilustración del método y que permiten dotar de mayor legibilidad al código. En el Anexo A se presenta la implementación completa de un caso de estudio en el que se incluyen todos los detalles de implementación. 5.4.2. Estructura de Presentación

La presentación de cada una de las funcionalidades de la asociación se

estructura en los siguientes puntos: o Propósito: descripción del comportamiento ofrecido por la

implementación de la funcionalidad. o Clases y Métodos participantes: identificación de las clases y

métodos de estas clases que implementan la funcionalidad presentada. o Comprobación de Propiedades: identificación de los métodos de

comprobación que deben activar los métodos que dan soporte a la funcionalidad presentada.

o Interacciones: enumeración de la secuencia de llamadas a métodos

necesaria para llevar a cabo la funcionalidad presentada. Este punto se completa con un diagrama de secuencia UML que muestra gráficamente la secuencia.

o Ejemplo: introducción de un ejemplo de la funcionalidad presentada. Se

muestran los pasos seguidos en el ejemplo para llevar a cabo la funcionalidad.

Una vez definidos estos cinco puntos se presentará la implementación de

los métodos participantes en la funcionalidad presentada. Para cada uno de ellos se introduce:

• Descripción, • Clase Propietaria, • Signatura, • Efecto, pasos llevados a cabo por el método,

149

• Implementación Propuesta, • Optimización, guías para la instanciación del framework que

permiten mejorar la implementación, y • Ejemplo, sólo en el caso de métodos con una implementación

específica para distintos valores de una propiedad. 5.4.3. Creación de Enlaces. o Propósito: Ofrecer funcionalidad para crear enlaces entre objetos de

clases asociadas. Esto implica la creación del objeto enlace y de las referencias entre objetos (entre el enlace y los objetos participantes y viceversa).

MediadorNomAsociacion 1*

+Mediador()

Mediador

* 1

+insertar()

DecoradorNomClaseNomRol

+insertar()

DecoradorNomClaseNomRol

+conectar_enlace()

DecoradorNomClase

+conectar_enlace()

DecoradorNomClase

Figura 5.11. Clases y Métodos participantes en la creación de enlaces o Clases y Métodos Participantes: En la figura 5.7 se identifican las

clases y métodos utilizados durante la creación de enlaces. En la figura aparecen los métodos implementados en cada clase de diseño participante en la creación de un enlace. A continuación se describe brevemente cada uno de estos métodos.

• Clase: DecoradorNomClaseNomRol

Método: insertar, desencadena la creación de un objeto enlace desde uno de los objetos participantes (al que llamaremos objeto fuente). El método está sobrecargado, proporcionando dos tipos de inserción de enlace:

o insertar(Decorador): el objeto fuente se conecta a otro objeto proporcionado por el argumento del método.

o insertar(Coleccion): el objeto fuente se conecta a un objeto nuevo creado usando la colección de atributos proporcionada por el argumento del método.

• Clase: Mediador

Método: Mediador (Decorador, Decorador). Método constructor. Es un método plantilla. Define la estrategia para crear un objeto

150

enlace. Debe garantizar que se cumplan las propiedades de la relación afectadas por la creación de enlaces (reflexividad, simetría y transitividad).

• Clase: DecoradorNomClase

Método: conectar_enlace(Mediador). Es un método plantilla. Define la estrategia para conectar un enlace a un objeto decorador. Debe garantizar que se cumplan las propiedades de los extremos de la relación afectadas por la creación de enlaces (multiplicidad máxima).

o Comprobación de Propiedades: En la tabla 5.3 se identifican los

métodos de comprobación que se utilizan en la implementación de la creación de enlaces. La tabla muestra qué métodos que implementan la creación de enlaces se encargan de realizar las distintas comprobaciones.

Creación de enlaces

Mediador conectar_enlace

comprobar_multiplicidad_maxima * √

comprobar_multiplicidad_minima * *

propagar_borrado_destruccion * *

comprobar_reflexividad √ *

comprobar_simetria √ *

comprobar_transitividad √ *

propagar_borrado_desconexion * *

Tabla 5.3: Identificación de los métodos de comprobación utilizados en la creación de enlaces.

o Interacciones: El método que desencadena la creación de un enlace es

el método insertar de las clases decoradoras. La secuencia de acciones que se produce durante la creación de un enlace es la siguiente:

1. Llamada al método insertar de un objeto decorador. 2. El método insertar llama al método constructor de la clase mediadora concreta. 3. El método constructor crea el objeto enlace y llama al método conectar_enlace de los objetos participantes. 4. El método conectar_enlace conecta cada objeto participante con el nuevo enlace.

151

Figura 5.12. Secuencia de llamadas para la creación de un enlace

En la figura 5.12 se muestra el diagrama de secuencia con las llamadas que se producen durante la creación de un enlace. Un objeto cliente realiza una petición del método insertar a un objeto decorador (o1). El argumento del método es el objeto asociado (o2). Durante la ejecución del método insertar se llama al método constructor de la clase mediadora para que cree el objeto enlace entre los objetos o1 y o2. El método constructor llama al método conectar_enlace del objeto o1 y del objeto o2 para que se conecten con el nuevo enlace.

Figura 5.13. Ejemplo gráfico de llamadas entre objetos durante la creación de un enlace

entre un objeto de una clase Empleado y un objeto de una clase Compañía o Ejemplo: En la figura 5.13 se muestra un ejemplo gráfico de las

llamadas entre objetos que se producen durante la creación de un enlace. Siguiendo con el ejemplo presentado en la figura 5.7, se solicita el método insertar del objeto DecoradorJuan para asociarlo con el objeto DecoradorIBM. Los pasos que se muestran en la figura son:

1. Llamada al método insertar del objeto DecoradorJuan. El argumento del método es el objeto DecoradorIBM.

152

2. El método insertar llama al método constructor de la clase MediadorTrabajaPara, para que cree el objeto enlace entre DecoradorJuan y DecoradorIBM. 3. El método constructor crea el objeto enlace JuanIBM y llama al método conectar_enlace del objeto DecoradorJuan y del objeto DecoradorIBM, para que se conecten con el objeto enlace JuanIBM. 4. Resultado final de la creación del enlace: en el sistema aparece un nuevo objeto enlace JuanIBM, asociado con los objetos DecoradorJuan y DecoradorIBM. A continuación se detallan cada uno de los métodos que participan en la

implementación de la creación de un enlace. 5.4.3.1. Método insertar de las clases Decoradoras Concretas

o Descripción: Desencadena la creación de enlaces desde los objetos decoradores. Permite crear un enlace entre el objeto que ejecuta el método (objeto fuente) y otro objeto, que puede ser el argumento del método o un nuevo objeto creado a partir de los argumentos del método.

o Clase Propietaria: DecoradorNomClaseNomRol

o Signatura: El método está sobrecargado:

• void insertar(Decorador), crea un enlace entre el objeto

fuente y el objeto argumento.

• void insertar(Coleccion), crea el objeto asociado nuevo utilizando los argumentos del método (atributos del nuevo objeto). Durante la creación de este objeto se crea el enlace entre el objeto fuente y el nuevo objeto creado.

o Efecto:

• El método insertar(Decorador) se encarga de crear un

objeto enlace llamando al método constructor de la clase mediadora. Los argumentos del constructor son el objeto fuente y el objeto decorador argumento. El orden de los argumentos está en función del rol de la clase decoradora en la asociación: si es origen, el primer argumento es el objeto que ejecuta el método; si es destino, el primer argumento es el objeto decorador argumento.

• El método insertar(Coleccion) se encarga de crear un

objeto decorador nuevo llamando al método constructor de la clase decoradora correspondiente. El argumento del método constructor es la colección de atributos del nuevo objeto, más

153

el objeto fuente. Este método se encargará de crear el enlace entre ambos objetos.

En la figura 5.14 se puede ver el diagrama de secuencia del método insertar(Coleccion). Como se puede observar, un objeto cliente realiza una petición del método insertar a un objeto decorador (o1). El argumento del método es una colección con los valores de los atributos de un objeto decorador para que sea creado. Durante la ejecución del método insertar se llama al método constructor de la clase decoradora correspondiente, para que cree el nuevo objeto decorador. El argumento del método es la colección de atributos más el objeto fuente o1. Este método constructor se encargará de llamar al método constructor de la clase mediadora para que cree el objeto enlace entre los objetos o1 y el nuevo objeto creado, o2. El método constructor llama al método conectar_enlace del objeto o1 y del objeto o2 para que se conecten con el nuevo enlace.

Figura 5.14. Secuencia de llamadas producida durante la ejecución del método

insertar(Coleccion)

o Implementación:

public void insertar(Decorador objAsociado) {

new MediadorNomAsociacion(objAsociado, this); //se llama al constructor de la clase mediadora, en este //caso la clase decoradora es la clase destino en la //relación

} public void insertar(ArrayList listaAtributos) {

DecoradorNomClaseOrigenNomRol coleccion = [this]; //se crea un vector con el objeto fuente new DecoradorNomClaseDestinoNomRol (new NomClaseDestino(

listaAtributos), coleccion);

154

//se envuelve el objeto asociado, se decora para que //inserte un nuevo enlace

}

o Optimización:

• El método insertar(Decorador) de una clase decoradora no se implementa si las propiedades del extremo cumplen la siguiente condición:

Dinamicidad = Estática ó Max = Min

En este caso no se puede crear un enlace con un objeto de la clase del extremo opuesto, puesto que a estos objetos no se les puede añadir ningún enlace (por la restricción que impone la

propiedad Dinamicidad o por la que impone la Multiplicidad).

o Ejemplo: Siguiendo con el ejemplo de la relación trabajaPara entre una clase Empleado y una clase Compañía:

• No se implementa el método insertar de la clase Empleado

porque el extremo opuesto es Estático. • El método insertar de la clase Compañía:

public void insertar(ArrayList listaAtributos) { DecoradorCompanyiaTrabajaPara coleccionComp = [this]; //se crea un vector con el objeto servidor

EmpleadoAbstracta objetoEmpleado = new DecoradorEmpleadoTrabajaPara(new Empleado(listaAtributos),

coleccionComp); //se llama al constructor de la clase decoradora Empleado

}

Siguiendo la optimización propuesta, en la clase Compañía no se implementa el método insertar(DecoradorEmpleadoTrabajaPara) porque el extremo es Estático y con multiplicidad (1,1). Esto significa que a una compañía no se le puede insertar un enlace con un empleado existente, puesto que los empleados no pueden añadir enlaces por

su Multiplicidad y Dinamicidad. 5.4.3.2. Método Constructor de la clase Mediadora Abstracta.

o Descripción: Define la estrategia para crear un objeto enlace. Los argumentos del método son los objetos participantes en el enlace. Se encarga de crear el objeto enlace y las relaciones entre éste y sus objetos participantes. En la estrategia se definen los pasos necesarios

155

para garantizar que siempre se satisfacen las propiedades de la relación afectadas por la creación de enlaces.

o Clase Propietaria: Mediador

o Signatura: Mediador(Decorador, Decorador)

o Efecto: El método debe:

1. Comprobar si se puede crear el enlace. La comprobación viene

determinada por:

• Las propiedades de la relación que pueden no satisfacerse tras la creación de enlaces. Estas propiedades son:

o Reflexividad: si la relación es Irreflexiva un objeto no

puede relacionarse con él mismo. Si es Reflexiva un objeto debe relacionarse con él mismo.

o Simetría: si la relación es Antisimétrica un objeto no puede relacionarse con otro que ya esté relacionado con él mismo. Si es Simétrica cuando se crea un enlace se debe crear su enlace simétrico.

o Transitividad: si la relación es Transitiva deben crearse automáticamente los enlaces transitivos.

Se implementan tres métodos en la subclase mediadora para que realicen estas comprobaciones. Estos métodos dependen del valor de las propiedades de cada asociación específica. Los métodos son comprobar_reflexividad, comprobar_simetria y comprobar_transtividad respectivamente.

• La restricción de identificación intrínseca de las relaciones. Se

define un método que compruebe que el enlace que se crea no existe en el sistema. Este método se define en la subclase porque depende de la relación específica. A este método se le llama comprobar_unicidad.

2. Llamar al método conectar_enlace de los objetos participantes.

Se encarga de conectar los objetos participantes con el enlace que se está creando.

3. Inicializar objetos participantes. Se actualiza el valor de los objetos

participantes (atributos origen y destino), asignándoles el valor de los argumentos del método. La asignación se realiza en orden: el primer argumento se asigna al atributo origen, y el segundo argumento se asigna al atributo destino.

156

DecoradorJuan DecoradorIBM

JuanIBM

DecoradorJuan DecoradorIBM

Estado Inicial Estado Final

Figura 5.15. Ejemplo del estado de parte de un sistema antes y después de la ejecución del

método constructor de la clase mediadora MediadorTrabajaPara

En la figura 5.15 se presenta un ejemplo gráfico del estado de los objetos antes y después de la ejecución del método constructor MediadorTrabajaPara (DecoradorJuan, DecoradorIBM).

o Implementación: La implementación del método constructor es la

siguiente:

public Mediador (Decorador origen, Decorador destino) {

comprobar_reflexividad(origen, destino); comprobar_simetria(origen, destino); comprobar_transitividad(origen, destino); comprobar_unicidad(origen, destino); //Paso 1. Se comprueba si es posible crear el enlace origen.conectar_enlace(this); destino.conectar_enlace(this); //Paso 2. Se llama al método conectar_enlace de los //objetos participantes this.origen = origen; this.destino = destino; //Paso 3. Se inicializan los objetos participantes

} 5.4.3.3. Método conectar_enlace de la clase Decoradora Abstracta.

o Descripción: Define la estrategia para conectar un enlace a un objeto decorador. El argumento del método es un objeto enlace. Se encarga de relacionar el objeto que ejecuta el método con el objeto enlace argumento. En la estrategia se definen los pasos necesarios para garantizar que se satisfacen siempre las propiedades de los extremos afectadas por la creación de enlaces.

o Clase Propietaria: DecoradorNomClase

o Signatura: void conectar_enlace(Mediador)

o Efecto: El método debe:

157

1. Comprobar si es posible añadir un enlace al objeto. La

comprobación viene determinada por las propiedades definidas sobre los extremos de la asociación que pueden no satisfacerse tras la creación de un enlace. Estas propiedades son:

• Multiplicidad Máxima: al asociar un enlace nuevo a un objeto

se puede violar el número máximo de enlaces asociados al objeto. Para realizar esta comprobación se define un método en las subclases decoradoras. Este método se define en las subclases porque depende del valor de la propiedad de cada relación específica. A este método le llamamos comprobar_multiplicidad_maxima.

2. Añadir el enlace al objeto. Se añade el nuevo enlace creado en la

colección de enlaces del objeto (atributo coleccionEnlaces). Para ello se define un método anyadir_enlace en las subclases decoradoras.

DecoradorJuan DecoradorIBM

JuanIBM

DecoradorJuan DecoradorIBM

Estado Inicial Estado Final

JuanIBM

Figura 5.16. Ejemplo del estado de parte de un sistema antes y después de la ejecución del

método conectar_enlace(JuanIBM) del objeto DecoradorJuan

En la figura 5.16 se presenta un ejemplo gráfico del estado de los objetos antes y después de la ejecución del método conectar_enlace (JuanIBM) del objeto DecoradorJuan.

o Implementación: La implementación del método conectar_enlace

es la siguiente:

public void conectar_enlace(Mediador objEnlace) { comprobar_multiplicidad_maxima(); \\Paso 1. Comprobar que es posible conectar el enlace anyadir_enlace(objEnlace); \\Paso 2. Anyadir el enlace a la coleccion de enlaces

} A continuación se presenta la implementación de los métodos que llevan a cabo los pasos de las estrategias de ejecución introducidas por los métodos Mediador y conectar_enlace. La figura 5.17 identifica estos

158

métodos y sus clases. A estos métodos les llamamos métodos complementarios.

Figura 5.17: Identificación de los métodos complementarios que participan en la creación de

un enlace

5.4.3.4. Métodos Complementarios en la Creación de Enlaces Método comprobar_reflexividad(Decorador, Decorador) de la clase

Mediadora. Comprueba que se cumpla la Reflexividad. Existen diferentes implementaciones para el método según los posibles valores de la propiedad:

• Irreflexiva. Comprueba que los objetos participantes no sean el

mismo objeto, en caso de que lo sean, lanza una excepción.

public void comprobar_reflexividad(Decorador origen, Decorador destino) {

if (origen.Equals(destino)) throw new Exception(“Violación Reflexividad”);

\\se comprueba si el objeto es el mismo }

• Reflexiva y No Reflexiva. No realiza ninguna comprobación.

public void comprobar_reflexividad(Decorador origen Decorador destino) {

\\no se lleva a cabo ninguna acción }

Ejemplo. Consideremos una asociación esJefe de una clase Empleado consigo misma. La asociación es Irreflexiva (un empleado no puede ser jefe de él mismo). El método comprobar_reflexividad se implementa de la siguiente forma:

public class MediadoresJefe: Mediador{ ...

public void comprobar_reflexividad(Decorador objEmpleado, Decorador objJefe) {

159

if (objEmpleado.Equals(objJefe))

throw new Exception(“Violación Reflexividad”); }

} Método comprobar_simetria(Decorador, Decorador) de la clase

Mediadora. Comprueba que se cumpla la Simetría. Existen diferentes implementaciones según los posibles valores de la propiedad:

• Antisimétrica. Comprueba que no exista un enlace con los mismos objetos participantes, si existe lanza una excepción.

public void comprobar_simetria(Decorador origen, Decorador destino) {

if (encontrar_simetrico31()!=null) { throw new Exception(“Violacion Antisimetria”);

} //se comprueba en la colección de enlaces de destino //si existe un enlace con origen como destino

} • No simétrica. No realiza ninguna comprobación.

public void comprobar_simetria(Decorador origen,

Decorador destino) { //no se realiza ninguna acción

}

• Simétrica. Crea un enlace en el sentido opuesto.

public void comprobar_simetria(Decorador origen, Decorador destino) {

Mediador enlaceSimetrico = encontrar_simetrico(); if (enlaceSimetrico==null)

new MediadorNomAsociacion((DecoradorNomClase)destino, (DecoradorNomClase)origen, nomRolOrigen);

} Ejemplo. Siguiendo con el ejemplo de la asociación reflexiva esJefe entre una clase Empleado consigo misma, consideremos la asociación antisimétrica (un empleado no puede ser jefe de su propio jefe). La implementación del método comprobar_simetría es la siguiente: public class MediadoresJefe: Mediador{

... public void comprobar_simetria(Decorador objEmpleado,

Decorador objJefe) {

if (encontrar_simetrico()!=null) { throw new Exception(“Violacion Antisimetria”);

}

31 encontrar_simetrico es un método de la clase que devuelve un enlace simétrico en caso de que exista, sino devuelve null.

160

//se comprueba en la colección de enlaces del objeto jefe //si existe un enlace con el objeto empleado como jefe

} public MediadorNomClase encontrar_simetrico(){

ArrayList asociados = this.obtener_destino().obtener_coleccion(nomRolOrigen);

foreach(MediadorNomClase enlace in asociados){ if (enlace.obtener_destino().Equals(this.obtener_origen())) return enlace; } return null; } } Método comprobar_transitividad(Decorador, Decorador) de la clase Mediadora. Se encarga de crear los enlaces transitivos en caso de que la asociación sea transitiva. Para implementar estos enlaces existen dos alternativas:

o Enlaces No Persistentes: no se crean los enlaces transitivos. En las consultas se deriva la información necesaria.

o Enlaces Persistentes: se crean los enlaces transitivos. Al crear,

destruir o modificar un enlace se crean, destruyen o modifican los enlaces derivados de la transitividad de la relación.

La decisión sobre la elección de la implementación depende de diversos

factores propios de cada aplicación, como son la frecuencia de acceso a los enlaces o la frecuencia de modificación de los enlaces. En la tesis se opta por reducir la complejidad temporal en consultas, creando los enlaces transitivos. La desventaja de esta aproximación es que aumenta la complejidad espacial y la temporal en las actualizaciones.

La implementación del método depende del valor de la propiedad:

• Transitiva. Se crean los enlaces transitivos derivados del nuevo enlace creado.

public void comprobar_transitividad(Decorador origen, Decorador destino) {

DecoradorNomClaseNomRol dorigen = (DecoradorNomClaseNomRol)

origen; foreach(MediadorNomAsociacion enlace in

dorigen.obtener_coleccion(nomRolDestino){ DecoradorNomClase nuevoOrigen =

enlace.obtener_origen(); if (encontrar_identico(nuevoOrigen, destino)==null) new MediadornomAsociacion(nuevoOrigen,

(DecoradorNomClase) destino, nomRolOrigen); }

161

DecoradorNomClaseNomRol ddestino = (DecoradorNomClaseNomRol) destino;

foreach(MediadornomAsociacion enlace in ddestino.obtener_coleccion(nomRolOrigen)){

DecoradorNomClase nuevoDestino = enlace.obtener_destino();

if (encontrar_identico(origen, nuevoDestino)==null) new MediadorNomAsociacion((DecoradorNomClase)

origen, nuevoDestino, nomRolOrigen); } }

• No Transitiva. No se realiza ninguna acción.

public Decorador comprobar_transitividad(Decorador origen, Decorador destino) {

//No se realiza ninguna acción } Ejemplo. Siguiendo con el ejemplo de la asociación esJefe entre una clase Empleado consigo misma, consideremos la asociación transitiva (si Sara es jefa de Pedro y Pedro es jefe de Juan, entonces Sara es jefa de Juan). La implementación del método es la siguiente: public class MediadoresJefe: Mediador{ ... public void comprobar_transitividad(Decorador objSubordinado, Decorador objJefe) {

DecoradorEmpleadojefe dorigen = (DecoradorEmpleadojefe) origen; foreach(MediadoresJefe enlace in

dorigen.obtener_coleccion("subordinado")){ DecoradorEmpleado nuevoOrigen =

enlace.obtener_origen(); if (encontrar_identico(nuevoOrigen, destino)==null) new MediadoresJefe(nuevoOrigen,

(DecoradorEmpleado) destino, "jefe"); } DecoradorEmpleadojefe ddestino = (DecoradorEmpleadojefe)

destino; foreach(MediadoresJefe enlace in

ddestino.obtener_coleccion("jefe")){ DecoradorEmpleado nuevoDestino =

enlace.obtener_destino(); if (encontrar_identico(origen, nuevoDestino)==null) new MediadoresJefe((DecoradorEmpleado)origen,

nuevoDestino, "jefe"); } } } Método comprobar_unicidad(Decorador, Decorador) de la clase Mediadora. Comprueba que el enlace creado no exista ya. En caso de que el enlace exista lanza una excepción.

162

public void comprobar_unicidad(Decorador origen, Decorador destino){ if (encontrar_identico()!=null) throw new Exception("Violacion Unicidad."); //se comparan los objetos para comprobar si son iguales

} Ejemplo. En el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía, el método comprobar_unicidad se implementa de la siguiente forma: public class MediadorTrabajaPara: Mediador { ... public void comprobar_unicidad(Decorador objEmpleado, Decorador objCompanyia) {

if (encontrar_identico()!=null)

throw new Exception("Violacion Unicidad."); //se comparan los objetos para ver si son iguales

} public MediadorTrabajaPara encontrar_identico(Decorador origen, Decorador destino) { DecoradorEmpleadotrabajaEn dorigen =

(DecoradorEmpleadotrabajaEn)origen; foreach (MediadorTrabajaPara enlace in

dorigen.obtener_coleccion(“TrabajaPara”)){ if (destino.Equals(enlace.obtener_destino())) return enlace; } return null; } } Método comprobar_multiplicidad_maxima() de la clases Decoradoras

Concretas. Comprueba que se cumpla la Multiplicidad Máxima. Existen diferentes implementaciones según los posibles valores de la propiedad:

• Max = un número limitado: comprueba que el número de enlaces del objeto no exceda este número. Si se excede, lanza una excepción. Este número aparece en el framework como una variable (VALOR_MULTIPLICIDAD_MAXIMA). En la instanciación del framework se le debe dar el valor de la multiplicidad máxima de la relación específica.

public void comprobar_multiplicidad_maxima() {

if (coleccionEnlaces.Count == VALOR_MULTIPLICIDAD_MAXIMA) throw new Exception(“Violacion Multiplicidad Maxima”); //si el número de enlaces de la colección es igual al //numero máximo permitido se lanza una excepción

} • Max = ilimitado (n): no se realiza ninguna comprobación

163

public void comprobar_multiplicidad_maxima() {

//No se realiza ninguna acción }

Ejemplo. Siguiendo con el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía, el método comprobar_multiplicidad_maxima se implementa en las clases participantes de la siguiente forma:

• El método de la clase Empleado:

public void comprobar_multiplicidad_maxima() {

if (coleccionEnlaces.Count == 1) throw new Exception(“Violacion Multiplicidad Maxima”);

//Si el número de enlaces de la colección es igual 1, se //lanza una excepción

}

• El método de la clase Compañía:

public void comprobar_multiplicidad_maxima() { //No se realiza ninguna acción porque no existe límite de //multiplicidad máxima

} Método anyadir_enlace(Mediador) de las clases Decoradoras Concretas. Añade un enlace a la colección de enlaces del objeto. public void anyadir_enlace(Mediador objEnlace) {

coleccionEnlaces.Add(objEnlace); //Anyade el enlace a la colección de enlaces

} Ejemplo. Siguiendo con el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía, la implementación del método en las clases participantes es la siguiente:

• El método de la clase Compañía:

public void anyadir_empleado(Mediador objEnlace) {

coleccionEnlaces.Add(objEnlace); //Añade el objeto enlace a la colección de enlaces

} • El método de la clase Empleado: public void anyadir_enlace(Mediador objEnlace) {

coleccionEnlaces.Add(objEnlace); //Añade el objeto enlace a la colección de enlaces

}

164

5.4.4. Destrucción de Enlaces. o Propósito: Ofrecer funcionalidad para destruir enlaces entre objetos de

clases relacionadas. Implica la destrucción del objeto enlace y de las referencias asociadas.

MediadorNomAsociacion 1*

+destruir()

Mediador

* 1

+borrar()

DecoradorNomClaseNomRol

+borrar()

DecoradorNomClaseNomRol

+desconectar_enlace()

DecoradorNomClase

+desconectar_enlace()

DecoradorNomClase

Figura 5.18: Clases y Métodos participantes en la destrucción de un enlace o Clases y Métodos Participantes: En la figura 5.18 se identifican las

clases y métodos utilizados durante la destrucción de enlaces. En la figura se muestra para cada clase de diseño participante en la destrucción de un enlace, los métodos implementados. A continuación se describe brevemente cada uno de estos métodos.

• Clase: DecoradorNomClaseNomRol

Método: borrar(Decorador), desencadena la destrucción de un enlace desde uno de los objetos participantes.

• Clase: Mediadora

Método destructor, define la estrategia para destruir un objeto enlace, debe garantizar que se cumplan las propiedades de la relación afectadas por la destrucción de enlaces (reflexividad, simetría y transitividad).

• Clase: DecoradorNomClase

Método: desconectar_enlace(Mediador), define la estrategia para desconectar un enlace de un objeto decorador, debe garantizar que se cumplan las propiedades de los extremos de la relación afectadas por la destrucción de enlaces (multiplicidad mínima).

o Comprobación de Propiedades: En la tabla 5.4 se identifican los

métodos de comprobación que se utilizan en la implementación de la destrucción de enlaces. La tabla muestra qué métodos que implementan la destrucción de enlaces se encargan de realizar las distintas comprobaciones.

165

Destrucción de enlaces

Destructor desconectar_enlace

comprobar_multiplicidad_maxima * * comprobar_multiplicidad_minima * √ propagar_borrado_destruccion * * comprobar_reflexividad √ * comprobar_simetria √ * comprobar_transitividad * * propagar_borrado_desconexion * √

Tabla 5.4: Identificación de los métodos de comprobación utilizados en la destrucción de

enlaces. o Interacciones: El método que desencadena la destrucción de un enlace

es el método borrar de las clases decoradoras. La secuencia de acciones que se produce durante la destrucción de un enlace es la siguiente:

1. Llamada al método borrar de un objeto decorador.

2. El método borrar llama al método destructor de la clase mediadora.

3. El método destructor llama al método desconectar_enlace de los objetos participantes.

4. El método desconectar_enlace elimina la referencia al enlace de los objetos participantes.

5. Una vez eliminada esta referencia el método destructor destruye el objeto enlace.

cliente

borrar(o2:Decorador)

o1:DecoradorNomClaseNomRol enlace:MediadorNomAsociacion

Dispose()

o2:DecoradorNomClaseNomRol

desconectar_enlace(enlace:MediadorNomAsociacion)

desconectar_enlace(enlace: MediadorNomAsociacion)

Figura 5.19. Secuencia de llamadas producida durante la destrucción de un enlace

En la figura 5.19 se puede ver el diagrama de secuencia con las llamadas realizadas durante la destrucción de un enlace. Un objeto cliente realiza una petición del método borrar a un objeto decorador (o1). El argumento del método es el objeto que quiere desconectarse (o2). Durante la ejecución del método borrar se llama al método

166

destructor del objeto enlace entre los objetos o1 y o2, (objeto enlace e), para que se destruya. El objeto enlace e llama al método desconectar_enlace del objeto o1 y del objeto o2 para que eliminen la referencia al enlace e. Finalmente el método destructor destruye el objeto enlace e.

Figura 5.20. Ejemplo gráfico de llamadas entre objetos durante la destrucción del enlace JuanIBM

o Ejemplo: En la figura 5.21 se muestra un ejemplo gráfico de la

secuencia de llamadas entre objetos producida durante la destrucción de un enlace. En este ejemplo se solicita el método borrar al objeto DecoradorJuan para que destruya la relación que mantiene con el objeto DecoradorIBM. Los pasos que se muestran gráficamente en la figura son los siguientes:

1. Llamada al método borrar del objeto DecoradorJuan. El argumento del método es el objeto DecoradorIBM. 2. El método borrara llama al método destructor del objeto JuanIBM para que se destruya. 3. El método destructor llama al método desconectar_enlace del objeto DecoradorJuan y del objeto DecoradorIBM para que eliminen la relación con el objeto enlace JuanIBM. 4. El método destructor destruye el objeto enlace JuanIBM. 5. Resultado final del borrado del enlace: desaparece la conexión entre los objetos DecoradorJuan y DecoradorIBM.

A continuación se presentan los métodos participantes en la

implementación de la destrucción de un enlace.

167

5.4.4.1. Método borrar de las clases Decoradoras Concretas.

o Descripción: Desencadena la destrucción de enlaces desde los objetos decoradores. Permite destruir un objeto enlace entre el objeto que ejecuta el método (al que llamaremos objeto fuente) y el objeto argumento.

o Clase Propietaria: DecoradorNomClaseNomRol o Signatura: void borrar (Decorador) o Efecto: Los pasos del método son los siguientes:

1. recuperar el objeto enlace: encontrar en la colección de enlaces del objeto fuente (atributo coleccionEnlaces) el enlace con el objeto argumento.

2. llamar al método destructor del enlace recuperado para que se

destruya.

o Implementación: La implementación del método borrar es la siguiente:

public void borrar(Decorador objAsociado) {

MediadorNomAsociacion enlace = buscar_enlace32(objAsociado); \\Se busca el enlace con el objeto objAsociado if (enlace != null) enlace.Dispose(); \\Se llama al método destructor del enlace encontrado

}

o Ejemplo: Siguiendo con el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía la implementación del método en las clases participantes es la siguiente:

• El método borrar de la clase Empleado no se implementa, puesto

que el extremo opuesto es Estático. • El método borrar de la clase Compañía:

public void borrar(Decorador objEmpleado) {

MediadorTrabajaPara enlace = buscar_enlace(objEmpleado); if (enlace != null) enlace.Dispose();

} 32 Suponemos un método buscar_enlace(Decorador) en la clase decoradora que devuelve de la colección de enlaces de la clase el enlace con el objeto asociado argumento.

168

5.4.4.2. Método destructor de la clase Mediadora Abstracta.

o Descripción: Define la estrategia para destruir un objeto enlace. Se encarga de destruir el objeto enlace y las relaciones entre éste y sus objetos participantes. En la estrategia se definen los pasos necesarios para garantizar que siempre se satisfacen las propiedades de la relación afectadas por la destrucción de enlaces.

o Clase Propietaria: Mediadora. o Signatura: void Dispose33 () o Efecto: Los pasos de la estrategia son los siguientes:

1. Comprobar si se puede destruir el enlace. La comprobación viene

determinada por las propiedades de la relación que pueden no satisfacerse tras la destrucción de enlaces. Las propiedades son:

• Reflexividad: si la relación es Reflexiva no se puede destruir un

enlace reflexivo. • Simetría: si la relación es Simétrica deben destruirse

automáticamente los enlaces simétricos.

Se definen tres métodos en la subclase mediadora, comprobar_reflexividad, comprobar_simetria y comprobar_transtividad, para que realicen estas comprobaciones. Los métodos se definen en las subclases porque dependen del valor de las propiedades de la asociación específica. Estos métodos sobrecargan los métodos introducidos anteriormente en la creación de enlaces.

2. Llamar al método desconectar_enlace de los objetos participantes. Este método se encarga de desconectar los objetos participantes con el enlace que va a destruirse.

3. Destruir el enlace.

33 En C# para implementar el método constructor se debe utilizar el método Dispose.

169

JuanIBM

DecoradorJuan DecoradorIBM

Estado Inicial Estado Final

DecoradorJuan DecoradorIBM

Figura 5.22. Ejemplo del estado de parte de un sistema antes y después de la ejecución del

método destructor del enlace JuanIBM.

En la figura 5.22 se presenta un ejemplo gráfico del estado de los objetos antes y después de la ejecución del método destructor del objeto enlace JuanIBM.

o Implementación: La implementación del método destructor es la

siguiente:

public class Mediadora : IDisposable 34{ ... public void Dispose() {

comprobar_reflexividad(this); comprobar_simetria(this) comprobar_transitividad(this); //Paso 1. Se comprueba que se puede destruir el enlace origen.desconectar_enlace(this); destino.desconectar_enlace(this); //Paso 2. Se llama al método desconectar_enlace de los //objetos participantes GC.Finalize(this); //Paso 3. Se destruye el enlace

} ...

} 5.4.4.3. Método desconectar_enlace de la clase Decoradora Abstracta.

o Descripción: Define la estrategia para eliminar un enlace de la colección de enlaces de un objeto decorador. El argumento del método es el objeto enlace a eliminar. El método elimina la relación del objeto que ejecuta el método con el objeto enlace. En la estrategia se definen los pasos necesarios para garantizar que se satisfacen las propiedades de los extremos de la asociación afectadas por la destrucción de enlaces.

34 En C# para implementar el método Dispose la clase debe implementar la interfaz IDisposable.

170

o Clase Propietaria: DecoradorNomClase

o Signatura: void desconectar_enlace(Mediador)

o Efecto: Los pasos de la estrategia son los siguientes:

1. Eliminar el enlace del objeto. Se elimina el enlace del atributo coleccionEnlaces. Para ello se define un método eliminar_enlace en las subclases decoradoras.

2. Comprobar si es posible eliminar el enlace del objeto. La

comprobación viene determinada por las propiedades de los extremos de una relación que pueden no satisfacerse tras la desconexión de un enlace de un objeto. Estas propiedades son:

• Multiplicidad Mínima: al desconectar un enlace de un objeto se

puede violar el número mínimo de enlaces asociados a un objeto. Para realizar esta comprobación se define un método en las subclases decoradoras al que llamamos comprobar_multiplicidad_minima. Este método se define en las subclases porque depende del valor de las propiedades de cada relación específica.

• Propagación de Borrado + Dinamicidad: al desconectar un

enlace de un objeto se deben llevar a cabo determinadas acciones en función del valor de ambas propiedades, propagación de borrado y dinamicidad. Para ello se utiliza el método propagar_borrado_desconexion. Este método se define en las subclases porque depende del valor de las propiedades de cada asociación específica.

JuanIBM

DecoradorJuan DecoradorIBM

Estado Inicial Estado Final

DecoradorJuan DecoradorIBM

JuanIBM

Figura 5.23. Ejemplo del estado de parte de un sistema antes y después de la ejecución del

método desconectar_enlace del enlace DecoradorJuan.

En la figura 5.23 se presenta un ejemplo gráfico del estado de los objetos antes y después de la ejecución del método desconectar_enlace (DecoradorIBM) del objeto DecoradorJuan.

o Implementación: La implementación del método

desconectar_enlace es la siguiente:

171

public void desconectar_enlace(Mediador objEnlace) {

eliminar_enlace(objEnlace); //Paso 1. Se elimina el enlace de la colección comprobar_multiplicidad_minima(); propagar_borrado_desconexion(); //Paso 2. Se comprueba si se puede desconectar el enlace

} A continuación se presenta la implementación de los métodos que llevan a cabo los pasos de las estrategias de ejecución presentadas. La figura 5.24 identifica estos métodos y sus clases.

+comproba_reflexividad()+comprobar_simetria()

MediadorNomAsociacion 1*

+destruir()

Mediador

*1

+borrar()+comprobar_multiplicidad_minima()+eliminar_enlace()

DecoradorNomClaseNomRol

+borrar()+comprobar_multiplicidad_minima()+eliminar_enlace()

DecoradorNomClaseNomRol

+desconectar_enlace()

DecoradorNomClase

comprobar_multiplicidad_minima() comprobar_multiplicidad_minima()eliminar_enlace() eliminar_enlace()

+desconectar_enlace()

DecoradorNomClase

Figura 5.24: Identificación de los métodos complementarios que participan en la destrucción

de un enlace

5.4.4.4. Métodos Complementarios en la Destrucción de Enlaces Método comprobar_multiplicidad_minima() de las clases

Decoradoras. Comprueba que se cumpla la Multiplicidad Mínima. Existen diferentes implementaciones según los posibles valores de la propiedad. La implementación de este método requiere la inclusión de una variable en las clases decoradoras que permita conocer si el objeto está siendo destruido. De esta manera, cuando se elimine un enlace como consecuencia de la destrucción de un objeto no será necesario forzar a que se cumpla la multiplicidad mínima del objeto. A esta variable la llamamos idestruccion y podrá tomar los valores cierto o falso. La variable se inicializará a falso al crear el objeto decorador y se actualizará a cierto en la llamada al método destructor del objeto.

• Min = 0: no realiza ninguna comprobación.

public void comprobar_multiplicidad_minima() {

//No se realiza ninguna acción }

172

• Min > 0: comprueba que el número de enlaces del objeto no sea menor que este número. Si no se cumple la condición se devuelve una excepción. El número mínimo de enlaces permitido aparece en la implementación como una variable (VALOR_MULTIPLICIDAD_MINIMA). En la instanciación del framework se le debe dar el valor de la multiplicidad mínima de la relación específica.

public void comprobar_multiplicidad_minima() { if ((!idestruccion) && (coleccionEnlaces.Count == VALOR_MULTIPLICIDAD_MINIMA - 1) )

throw new Exception(“Violacion Multiplicidad Minima”); //Si el objeto no se encuentra en proceso de destrucción y //en la colección de enlaces el número de elementos es el //número mínimo de enlaces permitido, se lanza una //excepción

} Ejemplo. Siguiendo con el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía, la implementación del método en las clases participantes es la siguiente:

• El método de la clase Empleado:

public void comprobar_multiplicidad_minima() { if ((!idestruccion) && (coleccionEnlaces.Count == 0))

throw new Exception(“Violacion Multiplicidad Minima”); //Si el empleado no está siendo destruido y en la //colección de enlaces no hay elementos se lanza una //excepción

}

• El método de la clase Compañía: public void comprobar_multiplicidad_minima() {

//La multiplicidad mínima es 0 por lo que no //se realiza ninguna acción

}

Método comprobar_reflexividad(Mediador) de la clase Mediadora.

Comprueba que se cumpla la Reflexividad. Existen diferentes implementaciones según los posibles valores de la propiedad:

• Irreflexiva y No reflexiva. No realiza ninguna comprobación.

public void comprobar_reflexividad(Mediador enlace) {

//No se realiza ninguna acción }

• Reflexiva. Impide la destrucción del enlace reflexivo.

public void comprobar_reflexividad(Mediador enlace) {

173

if (enlace.obtener_origen().Equals(enlace.obtener_destino())) throw new Exception(“Violacion Reflexividad”);

} Ejemplo. Tomemos la asociación querer entre una clase Persona consigo misma, consideremos la asociación reflexiva (una persona se quiere a ella misma). La implementación del método comprobar_reflexividad es la siguiente: public MediadorQuerer{

... public void comprobar_reflexividad(Mediador enlace){

if (enlace.obtener_origen().Equals(enlace.obtener_destino()))

throw new Exception(“Violacion Reflexividad”);

} }

Método comprobar_simetria(Mediador) de la clase Mediadora.

Comprueba que se cumpla la Simetría. Existen diferentes implementaciones según los posibles valores de la propiedad:

• Antisimétrica y No simétrica. No realiza ninguna comprobación.

public void comprobar_simetria(Mediador enlace) {

//No se realiza ninguna acción }

• Simétrica. Destruye el enlace simétrico.

public void comprobar_simetria(Mediador enlace) {

Mediador enlaceSimetrico = encontrar_simetrico (); if (enlaceSimetrico != null) enlaceSimetrico.Dispose();

} Ejemplo. Siguiendo con el ejemplo de la asociación reflexiva casado_con entre una clase Persona consigo misma, consideremos la asociación simétrica. La implementación del método comprobar_simetría es la siguiente: public Mediadorcasado_con{

... public void comprobar_simetria(Mediador enlace){

Mediadorcasado_Con enlaceSimetrico = buscar_simetrico(); if (enlaceSimetrico!=null) enlaceSimetrico.Dispose();

}

}

174

Método propagar_borrado_desconexion() de las clases Decoradoras. Se implementa en las clases decoradoras concretas. Realiza un conjunto de

acciones en función del valor de la propiedad Propagación de Borrado

asociada a la clase y la propiedad Dinamicidad asociada a la clase opuesta:

• (Restrictivo || Cascada || Enlace) & (Dinámico || Decrementable). No se lleva a cabo ninguna acción.

public void propagar_borrado_desconexion () { //No se lleva a cabo ninguna accion

}

• Restrictivo & (Estático || Incrementable). Se devuelve una excepción cuando se intenta eliminar el enlace.

public void propagar_borrado_desconexion () { throw new Exception(“No es posible eliminar un enlace”);

}

• Cascada & (Estático || Incrementable). Se destruye el objeto asociado que pierde el enlace (si no está siendo ya destruido), llamando al método destructor del objeto.

public void propagar_borrado_desconexion () {

if (!idestruccion) this.Dispose(); }

Ejemplo. Siguiendo con el ejemplo de la clase Companyia asociada a la clase Empleado a través de la relación trabajaPara, si consideramos que en el extremo de la clase Companyia la propagación de borrado es Cascada, el método propagar_borrado_desconexion se implementaría de la siguiente manera: public class DecoradorCompanyiaTrabajaPara: DecoradorCompanyia { ... public void propagar_borrado_desconexion () {

if (!idestruccion) this.Dispose(); } }

Método eliminar_enlace(Mediador) de las clases Decoradoras. Elimina un enlace de la colección de enlaces del objeto. public void eliminar_enlace(Mediador objEnlace) { coleccionEnlaces.Remove(objEnlace);

} Ejemplo. Siguiendo el ejemplo de la asociación trabajaPara entre una clase Empleado y una clase Compañía, la implementación del método en las clases participantes es la siguiente:

175

• El método de la clase Compañía:

public void eliminar_enlace(Mediador objEnlace) { coleccionEnlaces.Remove(objEnlace); //Se elimina de la colección de enlaces el objeto enlace

}

• El método de la clase Empleado:

public void eliminar_enlace(Mediador objEnlace) { coleccionEnlaces.Remove(indice); //Se elimina de la colección de enlaces el objeto enlace

}

5.4.5. Modificación de Enlaces. o Propósito: Ofrecer funcionalidad para modificar enlaces. La

modificación consiste en la sustitución de un objeto participante por otro de su misma clase. Esto implica la actualización del objeto enlace y de las referencias entre objetos (entre el enlace y los objetos participantes y viceversa).

Figura 5.25. Clases y Métodos participantes en la modificación de enlaces o Clases y Métodos Participantes: En la figura 5.25 se identifican las

clases y métodos utilizados en la modificación de enlaces. En la figura aparece por cada clase de diseño participante en la modificación de un enlace, los métodos implementados. A continuación se describe brevemente cada uno de estos métodos.

• Clase: DecoradorNomClaseNomRol

176

Método: modificar(Decorador, Decorador) desencadena la modificación de un objeto enlace desde uno de los objetos participantes.

• Clase: Mediadora

Método: actualizar (Decorador, Decorador). Actualiza uno de los objetos participantes. Debe garantizar que se cumplan las propiedades de la relación afectadas por la modificación de enlaces (esto implica a las propiedades afectadas por la creación y destrucción de enlaces).

• Clase: DecoradorNomClase

Método: conectar_enlace(Mediador). El método se ha introducido en la creación de enlaces.

Método: desconectar_enlace(Mediador). El método se ha introducido en la destrucción de enlaces.

o Comprobación de Propiedades: En la tabla 5.5 se identifican los

métodos de comprobación que se utilizan en la modificación de enlaces. La tabla muestra qué métodos que implementan la modificación de enlaces se encargan de realizar las distintas comprobaciones.

Modificación de enlaces

constructor conectar Enlace

desconectar_enlace

comprobar_multiplicidad_maxima * √ * comprobar_multiplicidad_minima * * √ propagar_borrado_destruccion * * * comprobar_reflexividad √ * * comprobar_simetria √ * * comprobar_transitividad √ * * propagar_borrado_desconexion * * √

Tabla 5.5: Identificación de los métodos de comprobación utilizados en la modificación de

enlaces o Interacciones: El método que desencadena la creación de un enlace es

el método modificar de las clases decoradoras. La secuencia de acciones es la siguiente:

1. Llamada al método modificar de un objeto decorador. 2. El método modificar llama al método actualizar de la clase mediadora.

177

3. El método actualizar de la clase mediadora actualiza el objeto enlace y llama a los métodos conectar_enlace del nuevo objeto asociado y desconectar_enlace del antiguo objeto asociado. 1. El método conectar_enlace conecta el nuevo objeto participante con el enlace. 2. El método desconectar_enlace desconecta el antiguo objeto participante con el enlace.

Figura 5.26. Secuencia de llamadas producida durante la modificación de un enlace

En la figura 5.26 se muestra el diagrama de secuencia con las llamadas que se producen durante la modificación de un enlace. Un objeto cliente realiza una petición del método modificar a un objeto decorador (o1). Los argumentos del método son el nuevo objeto asociado (oN) y el objeto a sustituir (o2). Durante la ejecución del método modificar se llama al método actualizar de la clase mediadora para que actualice el objeto enlace, sustituyendo el objeto o2 por el nuevo objeto asociado oN. El método actualizar llama al método conectar_enlace del objeto oN y al método desconectar_enlace del objeto o2.

178

DecoradorJuan DecoradorIBM

modificar(DecoradorIBM, DecoradorMicrosoft)

DecoradorJuan DecoradorMicrosoft

JuanMicrosoft

(1) Llamada al método modificar del objeto DecoradorJuan

(2) El método modificar llama al método actualizar del enlace JuanIBM

(3) El método actualizar llama al métodoconectar_enlace de DecoradorMicrosoft

(6) Resultado de la Ejecución

JuanIBM

DecoradorMicrosoft

DecoradorJuan DecoradorIBM

JuanIBM

actualizar(DecoradorIBM, DecoradorMicrosoft)

DecoradorJuan DecoradorIBM

JuanIBM DecoradorMicrosoft

DecoradorMicrosoft

DecoradorIBM

conectar_enlace(this)

(4) El método actualizar llama al métododesconectar_enlace de DecoradorIBM

DecoradorJuan DecoradorIBM

JuanIBM DecoradorMicrosoft

desconectar_enlace(this)

DecoradorJuan DecoradorIBM

JuanIBM DecoradorMicrosoft

(4) El método actualizar actualiza las referencias a los objetos participantes

Figura 5.27. Ejemplo gráfico de llamadas entre objetos durante la modificación del enlace

JuanIBM

o Ejemplo: En la figura 5.27 se muestra un ejemplo gráfico de las llamadas entre objetos que se producen durante la modificación de un enlace. Se solicita el método modificar del objeto DecoradorJuan para modificar el enlace JuanIBM, sustituyendo la compañía IBM por Microsoft. Los pasos que se muestran en la figura son:

1. Llamada al método modificar del objeto DecoradorJuan. Los argumentos del método son los objetos DecoradorIBM y DecoradorMicrosoft. 2. El método modificar llama al método actualizar de la clase MediadorTrabajaPara, para que actualice el objeto enlace JuanIBM. 3. El método actualizar llama al método desconectar_enlace del objeto DecoradorIBM. 4. El método actualizar llama al método conectar_enlace del objeto DecoradorMicrosoft.

179

5. El método actualizar actualiza las referencias a los objetos participantes (elimina la referencia al objeto DecoradorIBM y la sustituye por la referencia al objeto DecoradorMicrosoft). 6. Resultado final de la modificación del enlace: en el sistema aparece el objeto enlace actualizado JuanMicrosoft, asociado con los objetos DecoradorJuan y DecoradorMicrosoft. A continuación se detallan cada uno de los métodos que participan en la

implementación de la modificación de un enlace. 5.4.5.1. Método modificar de las clases Decoradoras Concretas.

o Descripción: Desencadena la modificación de enlaces desde un objeto decorador. Permite actualizar un enlace del objeto que ejecuta el método (objeto fuente), sustituyendo el objeto asociado por otro. El primer argumento del método es el objeto asociado a sustituir, el segundo argumento es el nuevo objeto asociado.

o Clase Propietaria: DecoradorNomClaseNomRol

o Signatura: modificar(Decorador, Decorador)

o Efecto: Los pasos del método son los siguientes:

1. recuperar el objeto enlace: encontrar en la colección de

enlaces del objeto fuente (atributo coleccionEnlaces), el enlace con el objeto asociado a sustituir (primer argumento del método).

2. llamar al método actualizar de la clase mediadora. Los

argumentos de este método son el nuevo objeto asociado y el objeto a sustituir.

o Implementación:

public void modificar(Decorador objetoAnterior, Decorador objetoNuevo) {

MediadorNomAsociacion enlace = buscar_enlace(objetoAnterior);

enlace.actualizar(objetoAnterior, objetoNuevo);

}

o Ejemplo: Siguiendo con el ejemplo de la relación trabajaPara entre una clase Empleado y una clase Compañía:

• No se implementa el método modificar de la clase Compañía

porque el extremo opuesto es No Mutable. • El método modificar de la clase Empleado:

180

public void modificar(Decorador companyiaAntigua, Decorador companyiaNueva) {

MediadorTrabajaPara enlace = buscar_enlace(companyiaAntigua); //se busca el enlace entre el empleado y la companyia

enlace.actualizar(companyiaAntigua, companyiaNueva); //se llama al método actualizar de la clase mediadora } 5.4.5.2. Método actualizar de la clase Mediadora Abstracta.

o Descripción: Define la estrategia para modificar un objeto enlace. Los argumentos del método son el objeto a sustituir y el nuevo objeto participante. El método se encarga de actualizar el objeto enlace, y las relaciones entre el enlace y su nuevo objeto participante, y el enlace y el antiguo objeto participante. En la estrategia se definen los pasos necesarios para garantizar que se satisfacen siempre las propiedades de la asociación afectadas por la modificación de enlaces.

o Clase Propietaria: Mediador

o Signatura: actualizar(Decorador, Decorador)

o Efecto: Los pasos que lleva a cabo el método son:

1. Comprobar si se puede destruir el enlace existente. Puesto que la

modificación implica la destrucción de un enlace y la creación de otro nuevo. La comprobación se realiza antes y después de actualizar los objetos que participan en el enlace. Se comprueban las propiedades de la relación que pueden no satisfacerse tras la destrucción de un enlace. Estas propiedades son:

o Reflexividad: si la relación es Reflexiva no se puede destruir el enlace.

o Simetría: si la relación es Simétrica se debe destruir el enlace simétrico.

o Transitividad: si la relación es Transitiva deben destruirse los enlaces transitivos.

Para realizar estas comprobaciones se utilizan los métodos comprobar_reflexividad, comprobar_simetria y comprobar_transtividad introducidos en el apartado 5.4.3.4.

2. Actualizar el objeto participante. Se actualiza el valor del objeto

participante, asignándole el valor del argumento del método.

3. Comprobar si se puede crear el nuevo enlace. Puesto que la modificación implica la destrucción de un enlace y la creación de otro nuevo. La comprobación se realiza antes y después de actualizar los objetos que participan en el enlace. Se comprueba:

181

• las propiedades de la relación que pueden no satisfacerse tras

la creación de un enlace. Estas propiedades son:

o Reflexividad: si la relación es Irreflexiva un objeto no puede relacionarse con él mismo. Si es Reflexiva debe relacionarse con el mismo.

o Simetría: si la relación es Antisimétrica un objeto no puede relacionarse con otro que ya esté relacionado con él mismo. Si es Simétrica se debe crear el enlace simétrico.

o Transitividad: si la relación es Transitiva deben crearse automáticamente los enlaces transitivos.

Para realizar estas comprobaciones se utilizan los métodos comprobar_reflexividad, comprobar_simetria y comprobar_transtividad introducidos en el apartado 5.4.2.4.

• la restricción de identificación intrínseca de las relaciones. Se utiliza el método comprobar_unicidad.

4. Llamar al método desconectar_enlace del objeto participante

que va a ser sustituido. Se encarga de desconectar el objeto participante con el enlace.

5. Llamar al método conectar_enlace del nuevo objeto participante.

Se encarga de conectar el objeto participante con el enlace.

Figura 5.28. Ejemplo del estado de parte de un sistema antes y después de la ejecución del método actualizar del objeto JuanIBM

En la figura 5.28 se presenta un ejemplo gráfico del estado de los objetos antes y después de la ejecución del método actualizar(DecoradorIBM, DecoradorMicrosoft).

Estado Inicial Estado Final

DecoradorMicrosoft

JuanIBM

DecoradorJuan DecoradorIBM

JuanMicrosoft

DecoradorJuan DecoradorMicrosoft

182

o Implementación: La implementación del método actualizar es la siguiente:

public void actualizar(Decorador objAntiguo, Decorador objNuevo)

{ comprobar_reflexividad(this);

comprobar_simetria(this); //Paso 1. Se comprueba si es posible destruir el enlace

if (objAnt.Equals(origen)) origen = objNuevo; else destino = objNuevo;

//Paso 2. Se actualizan los objetos

comprobar_reflexividad(origen, destino); comprobar_simetria(origen, destino); comprobar_transitividad(origen, destino); comprobar_unicidad(origen, destino);

//Paso 3. Se comprueba si es posible crear el nuevo enlace

objAntiguo.desconectar_enlace(this); //Paso 4. Se llama al método desconectar_enlace del //objeto participante a sustituir

objNuevo.conectar_enlace(this);

//Paso 5. Se llama al método conectar_enlace del nuevo //objeto participante }

Figura 5.29: Identificación de los métodos complementarios que participan en la modificación

de un enlace En la figura 5.29 se muestran los métodos complementarios utilizados en la modificación de enlaces.

183

5.4.6. Creación de Objetos Participantes. o Propósito: Ofrecer funcionalidad para crear objetos participantes.

Siguiendo la estructura del framework, los objetos participantes se envuelven por objetos de sus clases decoradoras. El código que implementa la creación de un objeto de una clase participante es independiente del código que implementa la creación de un objeto decorador, lo que facilita la reusabilidad de las clases y el mantenimiento del código.

o Clases y Métodos Participantes:

• Clase: DecoradorNomClase Método: constructor, actualiza la referencia al objeto decorado.

• Clase: DecoradorNomClaseNomRol

Método: constructor, construye un objeto decorador. El método está sobrecargado, proporcionando tres posibilidad para la creación de objetos decoradores:

o DecoradorNomClaseNomRol(NomClaseAbstracta), el método crea un objeto decorador.

o DecoradorNomClaseNomRol(NomClaseAbstracta, Vector): el método crea un objeto decorador y lo asocia a un objeto (o varios) de su clase asociada.

o DecoradorNomClaseNomRol(NomClaseAbstracta, Coleccion): el método crea un objeto decorador y un objeto (o varios) de su clase asociada para ser conectados a él.

• Clase: NomClase

Método: constructor, construye un objeto de una clase de dominio:

o NomClase(Coleccion): el método crea un objeto de una clase participante.

o Comprobación de Propiedades: En la tabla 5.6 se identifican los

métodos de comprobación que se utilizan en la implementación de la creación de objetos participantes.

Creación de

Objetos comprobar_multiplicidad_maxima * comprobar_multiplicidad_minima √ propagar_borrado_destruccion * comprobar_reflexividad √ comprobar_simetria * comprobar_transitividad * propagar_borrado_desconexion *

Tabla 5.6: Identificación de los métodos de comprobación utilizados en la creación de objetos

participantes.

184

5.4.6.1. Método constructor de las clases Decoradoras Abstractas.

o Descripción: Actualiza el objeto decorado

o Clase Propietaria: DecoradorNomClase

o Signatura: DecoradorNomClase(NomClaseAbstracta)

o Efecto: actualizar el atributo que representa el objeto decorado

o Implementación: public abstract class DecoradorNomClase{

public DecoradorNomClase (NomClaseAbstracta decorado){ this.decorado = decorado; } }

5.4.6.2. Método constructor de las clases Decoradoras Concretas.

o Descripción: Se encarga de crear un objeto decorador. Los argumentos del método son el objeto decorado y, opcionalmente, una colección de objetos o atributos de objetos, para asociarse con el objeto decorador.

o Clase Propietaria: DecoradorNomClaseNomRol

o Signatura: El método constructor está sobrecargado, de forma que

existen tres métodos constructores:

• DecoradorNomClaseNomRol(NomClaseAbstracta), crea un objeto decorador.

• DecoradorNomClaseNomRol(NomClaseAbstracta, Vector), crea

un objeto decorador y lo relaciona con el segundo argumento del método (vector de objetos decoradores).

• DecoradorNomClaseNomRol(NomClaseAbstracta, Coleccion),

crea un objeto decorador y una colección de objetos decoradores de una clase decoradora asociada.

o Efecto:

• El método DecoradorNomClaseNomRol(NomClaseAbstracta) se

encarga de:

1. Crear el objeto decorador e inicializar su estado.

2. Comprobar si se cumple la multiplicidad mínima. Se llama al método comprobar_multiplicidad_minima.

185

3. Comprobar si se cumple la reflexividad. A través de un método comprobar_reflexividad de las clases decoradoras se comprueba que se cumpla la reflexividad.

• El método DecoradorNomClaseNomRol(NomClaseAbstracta,

Vector) se encarga de:

1. Crear el objeto decorador e inicializar su estado. 2. Crear un objeto enlace entre el objeto decorador y el/los objeto/s argumento/s. Se llama al método constructor de la clase mediadora correspondiente. 3. Comprobar si se cumple la multiplicidad mínima. Se llama al método comprobar_multiplicidad_minima. 4. Comprobar si se cumple la reflexividad. A través de un método comprobar_reflexividad de las clases decoradoras se comprueba que se cumpla la reflexividad.

• El método DecoradorNomClaseNomRol(NomClaseAbstracta,

Coleccion) se encarga de:

1. Crear el objeto decorador e inicializar su estado.

2. Crear el/los objeto/s nuevo/s a relacionar con el objeto creado. Se llama al método constructor de la clase decoradora correspondiente (durante la creación de este objeto se crea el objeto enlace). 3. Comprobar si se cumple la multiplicidad mínima. Se llama al método comprobar_multiplicidad_minima. 4. Comprobar si se cumple la reflexividad. A través de un método comprobar_reflexividad de las clases decoradoras se comprueba que se cumpla la reflexividad.

o Optimización:

• El método DecoradorNomClaseNomRol (NomClaseAbstracta, Coleccion) de una clase decoradora no se implementa si en la clase del extremo se cumple la siguiente condición:

Dinamicidad = Estática ó Max = Min

En este caso no se puede crear un objeto decorador conectándolo con un objeto de la clase asociada ya creado, puesto que a los objetos de la clase asociada no se les puede añadir ningún enlace (bien por la

186

restricción que impone la propiedad Dinamicidad o bien por la que

impone la Multiplicidad).

• No es obligatorio que se implementen los métodos DecoradorNomClaseNomRol( NomClaseAbstracta, Vector) y DecoradorNomClaseNomRol (NomClaseAbstracta, Coleccion) de una clase decoradora si en la clase del extremo opuesto se cumple que la multiplicidad mínima es menor que 0. En este caso es opcional conectar un enlace a un objeto durante su

creación (si Multiplicidad Mínima > 0 es obligatorio).

Además de los pasos mencionados, el método constructor realiza un paso previo que consiste en inicializar la variable idestruccion. A la variable se le asigna el valor false.

o Implementación: public DecoradorNomClaseNomRol (NomClaseAbstracta decorado): base(decorado) { coleccionEnlaces = new ArrayList(); comprobar_multiplicidad_minima(); comprobar_reflexividad(); } public DecoradorNomClaseNomRol (NomClaseAbstracta decorado, params object [] coleccionDecoradores): base (decorado) { coleccionEnlaces = new ArrayList(); foreach (DecoradorNomClaseNomRol objetoAsociado in coleccionDecoradores) {

MediadorNomAsociacion enlace = new MediadorNomAsociacion(this, objetoAsociado);

} //se crean enlaces con todos los objetos de la colección de //decoradores comprobar_multiplicidad_minima(); comprobar_reflexividad(); } public DecoradorNomClaseNomRol(NomClaseAbstracta decorado, ArrayList coleccionDecoradores) : base(decorado) { coleccionEnlaces = new ArrayList();

foreach(ArrayList coleccionAtributos in coleccionDecoradores) {

Decorador [] coleccionDecorador = new Decorador[1]; coleccionDecorador[0] = this; //se crea un vector con el objeto creado

new DecoradorNomClaseNomRol (coleccionAtributos, coleccionDecorador); //se crea un objeto de la clase decoradora asociada

187

//con la coleccion de objetos decoradores creada }

comprobar_multiplicidad_minima(); comprobar_reflexividad(); }

o Ejemplo: Siguiendo con el ejemplo de la asociación trabajaPara

entre una clase Empleado y una clase Compañía, el método constructor de la clase DecoradorEmpleadoTrabajaPara se implementa de la siguiente forma:

public DecoradorEmpleadoTrabajaPara(Decorador decorado) : base(decorado){

coleccionCompanyias = new ArrayList(); comprobar_multiplicidad_minima(); comprobar_reflexividad(); }

public DecoradorEmpleadoTrabajaPara(Decorador decorado, params object [] coleccionCompanyias) : base(decorado){

coleccionCompanyias = new ArrayList();

foreach (DecoradorCompanyiaTrabajaPara objCompanyia in coleccionCompanyias) {

MediadorTrabajaPara enlace = new MediadortrabajaPara(this, objCompanyia);

} //se crean enlaces con todas las companyias de la colección comprobar_multiplicidad_minima(); comprobar_reflexividad(); } public DecoradorEmpleadoTrabajaPara(Decorador decorado,

ArrayList coleccionAtributosCompanyias):base(decorado) {

coleccionCompanyias = new ArrayList();

foreach(ArrayList coleccionAtributos in coleccionCompanyias) {

DecoradorEmpleadoTrabajaPara coleccionEmpleado = new DecoradorEmpleadoTrabajaPara [1]; coleccionEmpleado[0] = this; //se crea un vector con el empleado creado new DecoradorCompanyiaTrabajaPara (new

CompanyiaAbstracta(coleccionAtributos), coleccionEmpleado); //se crea un objeto companyia con el vector de empleados

} comprobar_multiplicidad_minima(); comprobar_reflexividad(); }

188

5.4.6.3. Método constructor de las clases Participantes

o Descripción: Se encarga de crear un objeto de una clase participante.

o Clase Propietaria: NomClase

o Signatura: NomClase (...)

o Efecto: El método se encarga de crear el objeto e inicializar su

estado.

o Implementación:

public NomClase (…) {

.......... //se inicializan los atributos con los argumentos del método

}

o Ejemplo: Siguiendo con el ejemplo de la asociación trabajaPara, para la clase Empleado el método constructor es:

public Empleado(string nombre, string dni, string direccion) {

this.nombre = nombre; this.dni = dni; this.direccion = direccion; //se inicializan los atributos con los argumentos del método

}

5.4.6.4. Métodos Complementarios en la Creación de Objetos Método comprobar_reflexividad() de las clases Decoradoras.

Comprueba que se cumpla la Reflexividad. Existen diferentes implementaciones según los posibles valores de la propiedad:

• Reflexiva. Comprueba que el objeto creado se relacione con él mismo.

public void comprobar_reflexividad() { if (buscar_enlace(this)==null) then new MediadorNomAsociacion(this, this);

} • Irreflexiva y No Reflexiva. No realiza ninguna comprobación.

public void comprobar_reflexividad() {

\\no se lleva a cabo ninguna acción }

189

Ejemplo. Consideremos la asociación Querer de una clase Persona consigo misma. La asociación es Reflexiva (una persona se quiere a si misma). El método comprobar_reflexividad se implementa de la siguiente forma: public class DecoradorPersonaQuiere: DecoradorPersona{ ...

public void comprobar_reflexividad(){ if (buscar_enlace(this)== null) then new MediadorQuerer(this, this); }

} 5.4.7. Destrucción de Objetos Participantes o Propósito: Ofrecer funcionalidad para destruir objetos participantes. Se

mantiene independiente el código que implementa la destrucción de objetos de clases participantes y el código que implementa la destrucción de objetos decoradores, lo que facilita la reusabilidad de clases y el mantenimiento del código.

o Clases y Métodos Participantes:

• Clase: DecoradorNomClase Método: destructor de la clase, destruye un objeto decorador.

• Clase: NomClase

Método: destructor de la clase, destruye un objeto de una clase participante.

o Comprobación de propiedades: En la tabla 5.7 se identifican los

métodos de comprobación que se utilizan en la destrucción de objetos participantes.

Destrucción de Objetos

comprobar_multiplicidad_maxima * comprobar_multiplicidad_minima * propagar_borrado_destruccion √ comprobar_reflexividad * comprobar_simetria * comprobar_transitividad * propagar_borrado_desconexion *

Tabla 5.7: Identificación de los métodos de comprobación utilizados en la destrucción de

objetos participantes. 5.4.7.1. Método destructor de las clases Decoradoras Abstractas

o Descripción: Se encarga de destruir un objeto decorador de un objeto asociado.

190

o Clase Propietaria: DecoradorNomClase

o Signatura: void Dispose()

o Efecto:

1. realizar la propagación de borrado. Se define un método en la subclase que realiza esta comprobación. El método se define en la subclase porque depende del valor de la propiedad Propagación de Borrado. Al método le llamamos propagar_borrado_destruccion,

2. destruir el objeto decorado. Se llama al destructor del objeto. 3. destruir el objeto decorador.

Además de los pasos mencionados, el método destructor realiza un paso previo que consiste en actualizar la variable idestruccion. A la variable se le asigna el valor true.

o Implementación:

public void Dispose () { idestruccion = true;

propagar_borrado_destruccion(); //Paso 1. Se realiza la propagación de borrado objetoDecorado.Dispose(); //Paso 2. Se destruye el objeto decorado GC.SuppressFinalize(); //Paso 3. Se destruye el objeto decorador

}

5.4.7.2. Método destructor de las clases Participantes

o Descripción: Se encarga de destruir un objeto de una clase participante.

o Clase Propietaria: NomClase

o Signatura: void Dispose()

o Efecto: el método se encarga de destruir un objeto de una clase.

o Implementación:

public void Dispose() { //acciones para destruir un objeto

}

191

5.4.7.3. Método Complementario en la Destrucción de Objetos Método propagar_borrado_destruccion(). Se implementa en las clases decoradoras concretas. Realiza un conjunto de acciones en función del valor

de la propiedad Propagación de Borrado asociada a la clase del extremo opuesto:

• Restrictivo. Si el objeto decorador tiene enlaces, se devuelve una excepción.

public void propagar_borrado_destruccion () { if (coleccionEnlaces.Count > 0)

throw new Exception(“Violación Propagación de borrado”); //si el objeto tiene enlaces se devuelve una excepción

}

• Enlace. Se borran los enlaces del objeto decorador, llamando al método destructor de los enlaces,

public void propagar_borrado_destruccion () { foreach (MediadorNomAsociacion enlace in coleccionEnlaces){ enlace.Dispose();

} //se destruyen todos los enlaces del objeto

}

• Cascada. Se destruyen los objetos asociados, llamando al método destructor de cada objeto, (este método se encarga de destruir los enlaces),

public void propagar_borrado_destruccion () {

foreach (MediadorNomAsociacion enlace in coleccionEnlaces){ enlace.obtener_destino35().Dispose();

//se destruyen los objetos asociados, estos se encargan //de destruir los enlaces

} }

Ejemplo. Siguiendo con el ejemplo de la clase Companyia asociada a la clase Empleado a través de la relación trabajaPara, si consideramos que en el extremo de la clase Empleado la propagación de borrado es Cascada, el método propagar_borrado_destruccion de la clase decoradora Companyia se implementaría de la siguiente manera: public class DecoradorCompanyiaTrabajaPara: DecoradorCompanyia {

35 Dependiendo del papel que juegue la clase decoradora dentro de la asociación se utilizará el método obtenerDestino u obtener_origen.

192

... public void propagar_borrado_destruccion () {

foreach (MediadorTrabajaPara enlace in coleccionEnlaces) {

enlace.obtener_origen().Dispose(); //se destruyen los empleados de la companyia, estos se

//encargan de destruir el enlace

} } }

La propuesta de implementación de los métodos que dan soporte a la funcionalidad específica de las asociaciones, completa el framework propuesto, de tal forma que se proporciona una solución software para la implementación de las asociaciones completa.

193

5.5. Nivel de Persistencia

El nivel de persistencia se encarga de asegurar la persistencia de los objetos presentes en el nivel de aplicación. Para garantizar la persistencia es necesario obtener una representación de las clases del modelo conceptual a través de un diseño adecuado (relacional, objeto-relacional u orientado a objetos, dependiendo del SGBD utilizado para almacenar a los objetos del sistema). En la aproximación que se presenta, el modelo de datos utilizado es un modelo relacional.

El objetivo de este apartado es proporcionar una serie de

transformaciones que permitan abordar de forma automática la obtención de los elementos del esquema relacional que representan asociaciones binarias.

5.5.1. Correspondencia entre asociaciones binarias y tablas

Los desarrolladores poseen diversas opciones para traducir asociaciones a tablas relacionales. A continuación se introducen las diferentes alternativas: • Introducir una clave ajena: Es la aproximación más común para

traducir relaciones “uno-a-uno”36 y “uno-a-muchos”37. Consiste en incluir en la tabla de la clase de cardinalidad uno (en el primer caso) o muchos (en el segundo caso) como clave ajena la clave primaria de la que posee cardinalidad uno. Un ejemplo de esta solución se muestra en la figura 5.30.

• Utilizar una tabla diferente para la relación: En esta aproximación

la asociación se representa mediante una tabla diferente a la de las clases participantes. Esta aproximación proporciona gran flexibilidad, pero un rendimiento más bajo si se debe recorrer muy a menudo. Esta opción se utiliza para traducir asociaciones “muchos-a-muchos”38. En la figura 5.31 se puede ver un ejemplo de esta correspondencia.

• Embeber las clases en una sola tabla: En esta aproximación las dos

clases relacionadas se mezclan en una sola tabla. Esta aproximación mejora el rendimiento pero viola la normalización. Suele utilizarse algunas veces en relaciones “uno-a-uno”. En la figura 5.32 se puede ver un ejemplo de clases de dominio embebidas en una sola tabla.

36 Multiplicidad máxima 1 en ambos extremos de la asociación. 37 Multiplicidad máxima 1 en un extremo de la asociación, ilimitada en el extremo opuesto de la asociación. 38 Multiplicidad máxima ilimitada en ambos extremos de la asociación.

194

Figura 5.30. Ejemplo de la utilización de una clave ajena en la BD para representar la asociación

Estudiante

PK numExp

nombre

Asignatura

PK codigo

nombre

EstudianteAsignatura

PK codigoPK numExp

fecha

-numExp-nombre

Estudiante-codigo-nombre

Asignatura

1..* 10

matricular

Figura 5.31. Ejemplo de la utilización de una nueva tabla en la BD para representar la

asociación

195

-dni-nombre-fechaNacimiento

Empleado-codExp-universidad-centro

Expediente

EmpleadoExpediente

PK dni

codExpnombreuniversidadcentrofechaNacimiento

1..1 0..1

tiene

Figura 5.32. Ejemplo de clases de dominio embebidas en una sola tabla de la BD Existen diversos trabajos [TT90, MPM99, CCM03, EN04] que proponen reglas de transformación para convertir modelos entidad-relación en esquemas relacionales. Estas reglas se pueden extrapolar al modelo Orientado a Objetos, y así determinar a partir de un modelo conceptual OO el esquema relacional correspondiente. A continuación se presentan un conjunto de pautas, basadas en las transformaciones propuestas por M. Celma et al. en [CCM03], que indican cómo transformar las asociaciones del modelo conceptual propuesto en sus correspondientes elementos del esquema relacional. Para ello se tienen en cuenta diferentes propiedades de la asociación: • Respecto a las cardinalidades máximas:

o Una cardinalidad de “una-a-muchos” genera una clave ajena en la tabla que representa la clase con cardinalidad muchos en la asociación.

o Una cardinalidad “uno-a-uno” genera una clave ajena en una de

las dos tablas que representan las clases. Es necesaria la definición de clave única sobre la clave ajena.

o Una cardinalidad “muchos-a-muchos” genera una tabla nueva

cuya clave ajena será la compuesta por las claves de las clases participantes. En este caso dicha clave podrá ser clave candidata (no siendo obligatorio que sea clave primaria). Las claves ajenas que representan a las clases componentes se definirán como atributos con restricción de Valor No Nulo.

• Respecto a las cardinalidades mínimas:

196

o Una cardinalidad de uno supone:

Si la tabla correspondiente a la entidad con cardinalidad 1 es la que representa la relación: la definición de la restricción de Valor No Nulo sobre la clave ajena

Sino (incluye el caso de cardinalidad máxima muchos a

muchos): la definición de una restricción de integridad.

o Una cardinalidad mayor que 1 genera la definición una restricción de integridad.

• Una clase asociación genera una tabla nueva. Los atributos de la tabla

serán los atributos de la clase asociación. Una clave ajena de la tabla será la compuesta por las claves de las clases participantes. La clave primaria de la tabla puede ser uno de los atributos de la clase o la clave ajena compuesta por las claves de las clases componentes.

• Por último se etiqueta la restricción de clave ajena con null, restrict o

cascade para las operaciones de borrado siguiendo las directrices de la

propiedad Propagación de Borrado:

o Enlace genera clave ajena con restricción null. o Restrictivo genera clave ajena con restricción restrict. o Cascade genera clave ajena con restricción cascade.

Además de la obtención del diseño relacional, se deben proporcionar elementos software que sirvan para que los objetos del nivel de aplicación interactúen con el SGBDR. Estos elementos normalmente llamados mediadores (del inglés “mediators”), proporcionan métodos para recuperar los datos y convertir filas de tablas de la base de datos en objetos, para que estos objetos sean manipulados en el nivel de aplicación aplicándoles eventos que modifiquen su estado, haciéndolos persistentes después de la finalización de la ejecución de un evento. Estos elementos software permiten independizar el nivel de aplicación del nivel de persistencia, ofreciendo una serie de servicios independientes del tipo de SGBD utilizado. Los entornos de desarrollo comerciales y algunos marcos de trabajo proporcionan elementos de persistencia que pueden adaptarse para implementar el enlace entre el nivel de aplicación y el de persistencia. Actualmente están adquiriendo especial relevancia los llamados Frameworks de Persistencia. Un framework de persistencia está constituido por una librería de clases que facilita el desarrollo de clases persistentes, permitiendo almacenar objetos en bases de datos relacionales de manera lógica y eficiente. Es el caso del proyecto Hibernate para Java39.

39 http://www.hibernate.org

197

5.6. Nivel de Presentación

El nivel de presentación constituye la representación visual de las aplicaciones, proporcionando a los usuarios finales una forma de acceder a los datos y controlar la funcionalidad del sistema.

El objetivo de este apartado es analizar cómo afecta a la interfaz gráfica de usuario de una aplicación la presencia de asociaciones en el modelo conceptual. El apartado se divide en tres secciones:

o En la primera sección se muestra qué partes de la IGU se ven afectadas por la presencia de asociaciones, presentando algunas características que debe poseer dicha interfaz.

o La segunda sección presenta un conjunto de patrones que permiten modelar la interacción con el usuario y que están directamente relacionados con las asociaciones. Estos patrones son un subconjunto de los patrones de presentación introducidos en [MMP02].

o Para completar este apartado, en la tercera sección se presenta cómo se ve afectada la navegación en las aplicaciones Web por la presencia de asociaciones en el modelo conceptual.

5.6.1. Asociaciones en el Nivel de Presentación

En este apartado se presenta cómo se ve afectado el nivel de interfaz

por la presencia de asociaciones en el modelo conceptual. El apartado se divide en dos partes:

o En el primer subapartado se presentan distintos escenarios de

interacción con el usuario, en los que es necesario tener en cuenta las asociaciones involucradas en ellos. En cada uno de los escenarios se indican algunas características que éstos deben poseer y que, en ocasiones, dependen del valor de las propiedades de la asociación involucrada.

o En los siguientes subapartados, se muestran las características que deben poseer los escenarios de interacción con el usuario para la (1) creación, (2) modificación o (3) destrucción de enlaces, y para la (4) creación de objetos participantes en asociaciones.

Para ejemplificar los diferentes subapartados se utiliza la web del grupo

de investigación OO-Method (http://oomethod.dsic.upv.es). En esta web se dispone de información de los distintos miembros del grupo, sus publicaciones, proyectos, actividades y recursos. Además, los miembros del grupo pueden actualizar sus datos a través de la aplicación. En la figura 5.33 se muestra una parte del modelo conceptual correspondiente a dicho sistema. 5.6.1.1. Recuperación de Información

El nivel de presentación debe incorporar un tratamiento específico para las asociaciones y las clases participantes en asociaciones.

198

Figura 5.33. Parte del modelo conceptual subyacente a la aplicación web.

199

A continuación se presentan diferentes escenarios (información complementaria, navegación, operaciones ofertadas, varios niveles de agregación) en los que la existencia de asociaciones afecta al modo en el que se presenta la información relativa a uno o varios objetos.

• Información Complementaria Las asociaciones forman parte de la información complementaria de un objeto, por lo que es necesario tenerlas en cuenta cuando se muestra información de éste.

La propiedad Navegabilidad indica si al mostrar la información de un objeto es posible recuperar la información de sus objetos asociados:

o Navegable. Cuando el extremo opuesto de la relación es navegable se muestran los objetos asociados.

o No Navegable. Cuando el extremo opuesto de la relación es no

navegable no es posible mostrar los objetos asociados.

La propiedad Multiplicidad Máxima sirve de indicador del tipo de presentación que se puede utilizar para mostrar la información de un objeto participante en una asociación:

o Max = 1. Cuando se muestra información del objeto se incluye en la interfaz gráfica de usuario un registro con la información del objeto asociado. Un ejemplo en el que la multiplicidad máxima es 1 se presenta en la figura 5.34. En esta figura se puede ver una página web que muestra información de un proyecto. La información que aparece incluye una línea Main Researcher con el nombre del investigador principal del proyecto. Este dato se obtiene a través de la relación Project_responsible entre las clases Project y Member, y forma parte de la información complementaria del proyecto.

200

Figura 5.34. Ejemplo de página web con información complementaria

o Max > 1. Cuando la multiplicidad máxima es mayor que 1, la información se puede mostrar en forma de maestro/detalle. En este caso, el escenario de interacción con el usuario está formado por dos componentes. En uno se muestra la información relativa a un objeto y en el otro se muestran los objetos asociados. La figura 5.35 muestra una página que recupera información de una actividad. En la sección superior de la página se muestra información de la actividad (maestro), mientras que en la sección inferior aparece un recuadro con los miembros participantes en la actividad (detalle). Esta información se obtiene a través de la relación activity_participants entre la clase Activity y Member.

201

Figura 5.35. Ejemplo de página web con información maestro-detalle • Navegación En los escenarios de interacción con el usuario, cuando se muestra información de un objeto participante en una relación, se puede ofrecer navegación a sus objetos asociados, de forma que se pueda obtener información detallada de éstos. Esto es únicamente posible cuando los objetos asociados pertenecen a clases de extremos Navegables. En la página que se muestra en la figura 5.36 es posible navegar hasta la página de los miembros asociados a un firmante de una publicación, puesto que el extremo de la relación signer_member en la clase Member es Navegable.

202

Figura 5.36. Ejemplo de página web con información complementaria más navegación • Operaciones ofertadas Cuando se muestran las operaciones de un objeto, es necesario tener en cuenta además de las operaciones del propio objeto, las operaciones que éste puede utilizar como consecuencia de las asociaciones que mantiene. Los objetos de una clase pueden acceder a los objetos de su clase asociada si el extremo es Navegable. Así, a través de los objetos asociados, es posible utilizar las operaciones ofertadas por la clase asociada. Por lo que, en la interfaz gráfica de usuario es necesario tener en cuenta estas operaciones para ofrecer la posibilidad de que el usuario de la aplicación las solicite desde un objeto asociado.

La página web de la figura 5.37 muestra información de una actividad. En la página aparecen tres botones que permiten llevar a cabo operaciones desde la actividad seleccionada. Una de estas operaciones, es la modificación de un grupo. Esta operación aparece como consecuencia de la relación entre Activity y Group, siendo posible que la actividad lleve a cabo una operación de su grupo asociado.

203

Figura 5.37. Ejemplo de página web con operaciones de objetos asociados • Varios niveles de Agregación Se pueden dar situaciones en las que existan varios niveles de agregación, es decir, situaciones en las que un objeto está compuesto por objetos que contienen a su vez otros objetos. Esto ocurre típicamente en relaciones de composición reflexivas, aunque también se puede dar en otro tipo de asociaciones. Para mostrar este tipo de información se pueden utilizar árboles o composiciones de maestro-detalle anidadas, de forma que se pueda ver de forma intuitiva el nivel de agregación que existe entre los distintos componentes. En el ejemplo de la web del grupo que estamos siguiendo, no encontramos ninguna situación como la descrita en este punto. 5.6.1.2. Introducción de Datos en la Creación de Enlaces

La propiedad Dinamicidad determina la existencia de escenarios que activen la creación de enlaces asociados a un objeto:

o Dinámica/Incrementable: se requiere la existencia de un escenario de interacción para activar el método de creación de enlaces.

o Estática/Decrementable: no se requiere ningún escenario de interacción para activar el método de creación de enlaces.

204

Existen dos posibles escenarios de interacción para recoger los datos durante la activación del método de inserción de un enlace: • Selección del Objeto Asociado. En este caso uno de los argumentos del

método de inserción es el objeto asociado (o varios objetos asociados). En el escenario de interacción se debe mostrar:

o el objeto al que se va a añadir el enlace, o una lista con los objetos asociados potenciales.

El usuario seleccionará de la lista el objeto asociado que desee añadir. • Creación del Objeto Asociado. En este caso los argumentos del método

son los valores de los atributos del objeto asociado que debe crearse. Es necesario mostrar:

o el objeto al que se va a añadir el enlace, o un formulario para recoger los datos relativos al objeto asociado.

Figura 5.38. Ejemplo de página web para la inserción de un proyecto

205

Figura 5.39. Ejemplo de página web con listado de proyectos para seleccionar Las figuras 5.38 y 5.39 muestran las ventanas involucradas en la inserción de un enlace entre un recurso y un proyecto. Para ello, desde el recurso se proporciona un botón (Add) que permite añadir un proyecto (figura 5.38). La ventana abierta desde dicho botón (figura 5.39) muestra todos los proyectos existentes que pueden asociarse a la publicación. El usuario seleccionará los que considere convenientes. La inserción de enlace de este ejemplo se corresponde con el escenario Selección del Objeto Asociado introducido en este subapartado. 5.6.1.3. Introducción de Datos en la Modificación de Enlaces

La propiedad Mutabilidad determina la existencia de escenarios que activen la modificación de enlaces asociados a un objeto:

o Mutable: se requiere la existencia de un escenario de interacción para activar el método de modificación de enlaces.

o No Mutable: no se requiere ningún escenario de interacción para activar el método de modificación de enlaces.

206

Los datos requeridos para la activación del método de modificación de enlaces son el objeto a sustituir y el nuevo objeto. Para obtener estos datos en el escenario de interacción con el usuario se debe mostrar:

• el objeto para el que se quiere modificar el enlace, • una lista con los objetos asociados actuales, • una lista con los objetos asociados potenciales.

El usuario debe seleccionar de la primera lista el objeto a sustituir y de la segunda lista el nuevo objeto asociado. Estos objetos son los argumentos del método.

5.6.1.4. Introducción de Datos en el Borrado de Enlaces

La propiedad Dinamicidad determina la existencia de escenarios para activar la destrucción de enlaces asociados a un objeto:

o Dinámica/Decrementable: se requiere la existencia de un escenario de interacción para activar el método de destrucción de enlaces.

o Estática/Incrementable: no se requiere ningún escenario de interacción para activar el método de destrucción de enlaces.

En la activación del método de borrado de enlaces es necesario proporcionar el objeto asociado que se quiere eliminar. Para ello en el escenario de interacción se debe mostrar:

• el objeto al que se va a eliminar el enlace, • una lista con los objetos asociados al objeto.

El usuario debe seleccionar de la lista el objeto asociado que desee eliminar. Este objeto es el argumento del método. En las figura 5.40 y 5.41 se muestran las páginas que permiten borrar un enlace entre una publicación y un firmante. Desde la publicación se proporciona un botón (Delete) que permite eliminar un firmante (figura 5.40). La ventana abierta desde dicho botón (figura 5.41) muestra todos los firmantes asociados a la publicación. El usuario seleccionará el firmante que desee borrar.

207

Figura 5.40. Ejemplo de página web para la eliminación de un firmante de una publicación

208

Figura 5.41. Ejemplo de página web con los firmantes de una publicación

5.6.1.5. Introducción de Datos en la Creación de Objetos Asociados

Existen tres posibles escenarios de interacción con el usuario para recoger los datos necesarios durante la activación del método de creación de objetos: • Creación Simple. Los argumentos del método son los valores de los

atributos del objeto. Es necesario mostrar un formulario para recoger estos datos.

• Selección del Objeto Asociado. Además de los valores de los atributos, el

método tiene un argumento adicional: un objeto asociado. Por ello, es necesario mostrar una lista con los objetos asociados potenciales. El usuario debe seleccionar el objeto asociado que desee.

• Creación del Objeto Asociado. Además de los valores de los atributos, el

método requiere de los datos relativos a un objeto asociado que debe ser creado. Para ello, es necesario mostrar un formulario que recoja los datos relativos a este objeto asociado.

Las figuras 5.42 y 5.43 muestran las páginas que permiten crear una

publicación. La primera página recoge diferentes datos de la publicación. Toda la información que se solicita en esta página se corresponde con atributos de la clase Publicación. En la segunda página se solicita información sobre los firmantes de la publicación. Esta información creará un enlace entre la publicación y el firmante. Un firmante es específico de una publicación, por lo que antes de crear el enlace se crea el firmante. Además un firmante puede estar asociado a un miembro, lo que se puede

209

indicar en el último campo desplegable de la página, creándose un enlace entre el firmante y el miembro.

Figura 5.42. Ejemplo de página web para crear una publicación

210

Figura 5.43. Ejemplo de página web con información adicional solicitada para la creación de una publicación

5.6.2. Un Modelo de Presentación La casuística introducida en el punto anterior se podría extender y precisar en forma de patrones donde se identificara el problema asociado a cada caso y se propusiera una solución de implementación. Patrones de estas características han sido presentados en [MMP02] por P.J. Molina. En este trabajo se propone un modelo de presentación como extensión a OO-Method, para la especificación de interfaces de usuario. El modelo está constituido por un lenguaje de patrones, que identifica un conjunto de patrones que permiten capturar distintas especificaciones necesarias para modelar la interfaz de usuario de una aplicación. Directamente relacionado con las asociaciones se encuentran los patrones:

• Patrón Navegación. Este patrón determina qué información relacionada con un objeto es alcanzable en un contexto dado. Cuando en un escenario de interacción con el usuario se fija un objeto, se puede ofrecer al usuario la posibilidad de obtener información relacionada con el objeto. En estos casos se puede ofertar un menú de navegación a partir de la información proporcionada por el patrón de navegación. Para la definición del patrón navegación es necesario considerar la especificación de las asociaciones y la propiedad

Navegabilidad del esquema conceptual. • Patrón Maestro/Detalle. Este patrón representa una composición de

escenarios de interacción con el usuario, donde se encapsula al mismo tiempo comportamiento de sincronización entre el

211

componente maestro y los detalles. Siempre que cambian los datos del componente maestro, el detalle cambia automáticamente para sincronizar sus datos respecto al maestro. La aplicación del patrón Maestro/Detalle está fuertemente vinculada a la existencia de asociaciones entre los objetos maestro y detalles. La existencia de asociaciones con multiplicidad genérica “uno-a-muchos” pueden ser firmes candidatas a ser presentadas de un modo natural a través del patrón Maestro/Detalle.

Otros patrones en los que la presencia de asociaciones es relevante son:

• Patrón Criterio de Ordenación. Un criterio de ordenación proporciona un mecanismo de ordenación de objetos basado en las propiedades de éstos. El criterio de ordenación está compuesto por un conjunto de atributos visibles por la clase a la que pertenecen los objetos. Estos atributos pueden ser propios de la clase o visibles a través de asociaciones.

• Patrón Conjunto de Visualización. Un conjunto de visualización

describe una lista ordenada de propiedades que son observables por los usuarios en un contexto dado. La lista de propiedades está compuesta por los atributos de una clase o los atributos alcanzables mediante asociaciones alcanzables desde la clase.

• Patrón Acciones. Determina las acciones que son ofertadas al usuario

al seleccionar o fijar un objeto. Para elaborar el conjunto de acciones es necesario considerar las asociaciones de la clase del objeto.

La utilización de estos patrones para construir un modelo de

presentación, permite capturar las especificaciones necesarias para modelar la interacción de usuario relativa a las asociaciones.

5.6.3. Aplicaciones Web En el contexto de OO-Method existe una propuesta para el modelado de aplicaciones web. Esta propuesta constituye el método OOWS (Object Oriented Web Solution) [PFAP05]. OOWS es una extensión de OO-Method que introduce la expresividad necesaria para capturar los requisitos navegacionales y de presentación que permiten el desarrollo de aplicaciones Web. En este ámbito se ha realizado un estudio sobre cómo las asociaciones especificadas en un esquema conceptual pueden ayudar a determinar el modo de acceso a la información y funcionalidad por parte de los usuarios de una aplicación web. 5.6.3.1. La Aproximación Metodológica OOWS Antes de presentar el estudio realizado, es necesario introducir brevemente las características esenciales de OOWS. OOWS introduce en el modelado conceptual, el modelo navegacional y de presentación. Un modelo navegacional se construye para capturar los requisitos navegacionales de la aplicación. Una vez el modelo navegacional

212

se ha construido, se especifican los requisitos de presentación a través de un modelo de presentación, que utiliza un conjunto de patrones de presentación sencillo. Además OOWS define las correspondencias necesarias entre las abstracciones conceptuales introducidas y los elementos software que implementan cada capa de la arquitectura. A continuación se presenta con más detalle el modelo navegacional de OOWS. El Modelo Navegacional de OOWS Este modelo permite capturar la semántica navegacional de una aplicación Web, describiendo cómo los usuarios acceden a la información y funcionalidad del sistema. El modelo representa los usuarios del sistema y sus inter-relaciones por medio de un Diagrama de Usuarios. Para describir las posibles navegaciones de cada tipo de usuario, el modelo navegacional propone cinco primitivas navegacionales: Mapa Navegacional, Contexto Navegacional, Enlace Navegacional, Clase Navegacional y Relación Navegacional. Un Mapa Navegacional representa la vista global del sistema para cada tipo de usuario. Se representa a través de un grafo dirigido cuyos nodos son Contextos Navegacionales y los arcos representan Enlaces Navegacionales. Un Contexto Navegacional representa una vista parcial del sistema que ayuda al usuario a satisfacer ciertos requisitos. Un Enlace Navegacional representa una alcanzabilidad dirigida entre contextos, definiendo caminos de navegación válidos. La figura 5.44 muestra un ejemplo de un Mapa Navegacional. En este mapa hay ocho contextos (nodos del grafo), cada uno con sus alcanzabilidades (enlaces del grafo). Por ejemplo, desde el contexto Publicaciones el usuario puede alcanzar dos contextos: el contexto LineasInvestigacion, que permite obtener las líneas de investigación relacionadas con la publicación; y el contexto Investigadores, que permite obtener los autores de cada publicación.

213

Figura 5.44. Mapa Navegacional

Los Contextos Navegacionales (gráficamente representados como paquetes UML estereotipados con la palabra clave <<contexto>>) representan puntos de interacción de usuario que proporcionan un conjunto de datos y operaciones cohesivos. Estos pueden ser de dos tipos: • contextos navegacionales de exploración. Son nodos alcanzables desde cualquier otro nodo (marcados con la etiqueta “E”). Estos contextos definen enlaces navegacionales implícitos desde cualquier nodo y explícitamente desde la raíz del mapa que representa el usuario. En el ejemplo de la figura 5.44, se han incluido siete contextos de navegación (Actividades, Grupos, Recursos, Proyectos, Líneas de Investigación, Publicaciones e Investigadores). • contextos navegacionales de secuencia. Sólo pueden ser alcanzados a través de un camino navegacional predefinido (marcado con la etiqueta “S”). En la figura 5.44, Invitados es un contexto navegacional de secuencia que solo se puede alcanzar desde los contextos Investigadores y Proyectos. Los contextos navegacionales están constituidos por Clases Navegacionales y Relaciones Navegacionales.

214

Una Clase Navegacional (representada por una clase UML estereotipada con la palabra clave <<vista>>) denota una clase vista. Especifica los atributos y operaciones visibles/ejecutables por los usuarios del contexto. Además, es posible especificar un filtro de población para una clase navegacional, a través de una fórmula OCL. Cada contexto navegacional tiene: una clase obligatoria desde la que comienza la información proporcionada, esta clase el la clase “manager”; y otras clases navegacionales opcionales que proporcionan información complementaria, llamadas clases complementarias. Todas las clases navegacionales deben estar relacionadas por relaciones binarias unidireccionales (relaciones navegacionales). Estas se definen sobre relaciones de asociación o especialización del diagrama de clases. Las relaciones navegacionales pueden ser de dos tipos: 1. Relaciones de Dependencia de Contexto (se representan gráficamente

como flechas punteadas). Representan información básica recuperada atravesando relaciones estructurales entre clases. Cuando se define una relación de dependencia de contexto, todas las instancias relacionadas entre clases se recuperan.

2. Relaciones de Contexto (se representan gráficamente usando flechas

sólidas). Representan la misma información recuperada por las relaciones de dependencia de contexto, más una navegación adicional a un contexto destino. En este caso aparecen dos relaciones adicionales: el atributo de contexto (representado por corchetes), especifica el contexto destino que será accedido a través de la navegación; y el atributo enlaces que especifica el atributo que actuará como “ancla” de la navegación.

5.6.3.2. Extracción de Conocimiento de la Especificación de una Asociación Una vez se ha introducido la aproximación OOWS, en este apartado se estudia el conocimiento que se puede extraer de una asociación, con el objetivo de proporcionar guías de modelado que ayuden en la construcción de Modelos Navegacionales. Este conocimiento se obtiene analizando las propiedades estructurales y de comportamiento de las asociaciones. El objetivo de este apartado es diseñar un conjunto de reglas que permitan definir una guía metodológica que soporte el diseño de unidades de interacción básicas (nodos del grafo) de los modelos navegaciones y sus inter-relaciones (caminos navegacionales). En la aproximación OOWS, estas reglas afectan a la definición de clases y relaciones navegacionales en la especificación de contextos navegacionales. Para poder extraer este conocimiento, se utiliza la siguiente estrategia: 1. Se estudia como las asociaciones influyen en la construcción de modelos

navegacionales.

215

2. Se analizan las propiedades de las asociaciones que introducen conocimiento adicional al detectado en la sección previa.

Asociaciones en el Modelado Navegacional. Las asociaciones son la base para definir relaciones navegacionales en contextos navegacionales. Este conocimiento nos lleva a derivar la siguiente regla general: Dada una asociación entre dos clases (A y B) en un diagrama de clases, en el contexto navegacional deben aparecer dos clases navegacionales (<<vista A>> y <<vista B>>) y una relación navegacional entre ellas. Esta relación navegacional puede ser de uno de los siguientes tipos:

• Relación de contexto, debe conectar el contexto navegacional a otros contextos cuya clase “manager” es la clase navegacional destino de la relación de contexto. Este tipo de relación debe seleccionarse cuando es necesario proporcionar información adicional a la clase destino.

• Relación de dependencia de contexto, debe conectar una clase navegacional (origen) con otra clase (destino) en el contexto navegacional. Este tipo de relación debe seleccionarse cuando existe información suficiente de la clase destino para satisfacer los requisitos funcionales del contexto (no es necesaria la navegación para proporcionar información adicional de la clase destino).

Figura 5.45. Ejemplo de tres clases relacionadas por dos asociaciones

La figura 5.45 muestra un ejemplo de tres clases relacionadas a través

de dos asociaciones: la asociación trabajaEn entre la clase Investigador y la clase Recurso y la agregación aCargoDe entre la clase Investigador y LineaInvestigación. Cada investigador utiliza y es responsable de un conjunto de recursos (ordenadores, herramientas específicas, etc.). Una vez un recurso se asigna a un investigador, no es posible reasignarlo a otro investigador.

216

Figura 5.46. Contexto Navegacional Info Investigador

Figura 5.47. Contexto Navegacional Info Linea Investigacion Aplicando la regla general a las clases y relaciones de la figura 5.45, se definen dos contextos navegacionales: Info Investigador e Info Línea Investigación, (ver figuras 5.46 y 5.47 respectivamente) con las clases navegacionales Investigador y Línea Investigación y sus clases “manager” respectivas. Aplicando el criterio de clasificación de relaciones navegacionales descrito, se han incluido relaciones de contexto para permitir la navegación de un contexto a otro. En este punto del proceso de modelado, la clase Recurso parece de relevancia menor40 que las clases Investigador y Línea Investigación en el espacio del problema; por esta razón no se definen otros contextos 40 La interpretación particular del modelo se realiza en base al conocimiento del sistema real que se supone tener y que permite tomar este tipo de decisiones.

217

navegacionales que los definidos hasta ahora. A continuación se introducen otras reglas de diseño que pueden modificar la decisión de modelado tomada (incorporando otros contextos navegaciones) o confirmarla. Seguidamente, se describe el conocimiento extraído de las propiedades de las asociaciones y las reglas de diseño navegacional derivadas de éste. Finalmente se presenta los resultados de la aplicación de estas reglas en la construcción del Modelo Navegacionales de la aplicación Web del ejemplo. Extracción de Conocimiento de las Propiedades de la Asociación.

Analizando las propiedades de las asociaciones, se detecta que sólo dos propiedades de la asociación influyen en la construcción de los modelos

navegacionales. Estas propiedades son la Proyección de Identificación y la

Dinamicidad. Para cada una de estas propiedades, se proporciona la siguiente información:

• Conocimiento Extraído: Es una descripción de la forma en que la relación y los valores de las propiedades afectan a las primitivas del modelo navegacional. Este conocimiento ayuda a determinar la estructura de un contexto navegacional a través de las clases y relaciones navegacionales.

• Reglas de Diseño: Basándose en el conocimiento extraído es posible derivar un conjunto de reglas de diseño aplicables en la construcción de contextos navegacionales. Se introduce una regla de diseño por cada valor de la propiedad.

Para la presentación de las propiedades se toma como ejemplo una asociación r entre dos clases A y B. Proyección de Identificación Conocimiento Extraído. Determina la definición de clases complementarias y sus relaciones navegacionales en un contexto navegacional. Reglas de diseño:

• Caso PI1: Proyectado. Si el extremo de la clase A es proyectado, los objetos de la clase A se identifican a través de sus objetos asociados de la clase B.

Regla de Diseño: Cada clase navegacional de A debe tener una relación navegacional a la clase navegacional B, excepto cuando exista ya una relación navegacional de B a A.

• Caso PI2: No Proyectado. Si el extremo de la clase A es no

proyectado, los objetos de la clase A no se identifican a través de sus objetos asociados.

Regla de Diseño: No es obligatorio diseñar relaciones navegacionales entre las clases navegacionales A y B.

218

Siguiendo con el ejemplo de la figura 5.45, la clase Investigador proyecta su identidad sobre la clase Recurso (valor Proyectado en el extremo de la clase Recurso), caso PI1. La regla que se aplica para este caso proporciona dos alternativas:

• crear una relación de contexto al contexto navegacional Recurso como su clase “manager”, obligando la inclusión de una relación navegacional a una clase navegacional o investigador.

• definir una relación de dependencia de contexto desde alguna clase

navegacional de Investigador a una clase navegacional de Recurso. Para el ejemplo se ha optado por la segunda alternativa, puesto que no se considera necesario incluir navegación a los objetos de la clase Recurso. La figura 5.46 muestra el contexto navegacional Info Investigador, en el cual se incluye una relación de dependencia de contexto desde la clase “manager” Investigador hasta la clase navegacional Recurso. Dinamicidad Conocimiento Extraído. Determina qué clases navegacionales pueden incluir operaciones de creación y destrucción de instancias de una asociación. Reglas de Diseño:

• Caso D1: Dinámica. Si el extremo de una clase B es dinámico, los objetos de la clase A pueden durante su vida, crear y destruir enlaces de la asociación con objetos de la clase B.

Regla de Diseño: Deben incluirse operaciones para crear y destruir enlaces de la asociación en la clase navegacional A, en al menos uno de los contextos navegaciones donde A es la clase “manager” y donde existe una relación navegacional que se corresponde con la asociación en el mapa navegacional.

• Caso D2: Estático. Si el valor del extremo A es estático, los objetos

de la clase A no pueden durante su vida crear o destruir enlaces de la asociación con objetos de la clase B. Regla de Diseño: No está permitido incluir operaciones de creación y destrucción de enlaces con objetos de la clase B a clases navegacionales de A.

• Caso D3: Incrementable. Si el valor del extremo A es incrementable, los objetos de la clase A no pueden durante su vida destruir enlaces de la asociación con objetos de la clase B. Regla de Diseño: No está permitido incluir operaciones de destrucción de enlaces con objetos de la clase B a clases navegacionales de A. Deben incluirse operaciones para crear enlaces

219

de la asociación en la clase navegacional A, en al menos uno de los contextos navegaciones donde A es la clase “manager” y donde existe una relación navegacional que se corresponde con la asociación en el mapa navegacional.

• Caso D4: Decrementable. Si el valor del extremo A es decrementable, los objetos de la clase A no pueden durante su vida crear enlaces de la asociación con objetos de la clase B. Regla de Diseño: No está permitido incluir operaciones de creación de enlaces con objetos de la clase B a clases navegacionales de A. Deben incluirse operaciones para destruir enlaces de la asociación en la clase navegacional A, en al menos uno de los contextos navegaciones donde A es la clase “manager” y donde existe una relación navegacional que se corresponde con la asociación en el mapa navegacional.

En el ejemplo, debido al valor dinámico del extremo de la clase Investigador de la asociación trabajaEn (caso D1), se han incluido las operaciones añadirInvestigador y eliminarInvestigador en la clase navegacional Linea Investigación del contexto navegacional Info Linea Investigación (ver figura 5.47). De la misma manera, el valor dinámico del extremo opuesto de la asociación trabajaEn, fuerza a la inclusión de operaciones similares (añadirLineaInvestigación y eliminarLineaInvestigación) en la clase “manager” Investigador del contexto navegacional Info Investigador (ver figura 5.46). El valor dinámico del extremo de la clase Recurso en la asociación aCargoDe (caso D1) justifica la inclusión de las operaciones añadirRecurso y eliminarRecurso de la clase “manager” Investigador del contexto navegacional Info Investigador (ver figura 5.46). El valor estático del extremo opuesto de la asociación aCargoDe (caso D2) no permite la inclusión de este tipo de operaciones en la clase navegacional Recurso. Los resultados del análisis de las asociaciones permiten mejorar el proceso de modelado y generación de código introducido por OOWS. Las reglas presentadas se aplican sobre las asociaciones del diagrama de clases, facilitando el proceso de construcción de modelos navegacionales. Aunque estas reglas ayudan al modelador en la construcción de especificaciones completas y coherentes, no son reglas obligatorias y el modelador puede decidir cuando aplicarlas.

220

5.7. Conclusiones

La propuesta de un framework para la implementación de la asociación que se proporciona en este capítulo, se caracteriza por una serie de propiedades que la hacen destacar frente a otras implementaciones existentes. Estas propiedades son:

o Estar basada en el uso de patrones de diseño. La utilización de patrones de diseño en la construcción del framework asegura la calidad de las estructuras de diseño obtenidas en la implementación de la asociación.

o Cumplir unos factores de calidad específicos para la implementación

de la asociación. La selección de los patrones de diseño se realiza en función de un conjunto de factores de calidad, específicos para la asociación, que dan lugar a una solución software compuesta por una estructura de diseño óptima para la implementación de las asociaciones, que permite que los factores de calidad del software se satisfagan.

o Definir las correspondencias entre el modelo de asociaciones y su

representación software. Además de proponer un framework para la implementación de las asociaciones se definen las correspondencias entre la especificación de una asociación y los elementos del framework. Estas correspondencias definen cómo instanciar el framework, lo que permite obtener la implementación de una asociación en concreto. Esto permite la construcción de generadores de código capaces de realizar automáticamente el proceso de transformación.

o Ser completa. La implementación propuesta proporciona todos los

elementos de la solución software. El framework proporciona la estructura de clases de diseño y además propone una implementación para los métodos de estas clases que dan soporte a la funcionalidad adicional de las asociaciones. Por otro lado, aunque el framework se centra fundamentalmente en el nivel de aplicación, también se realiza un análisis de cómo afecta la asociación y sus propiedades al nivel de persistencia y el nivel de presentación.

221

Capítulo 6 Conclusiones y Trabajo Futuro Este capítulo presenta las principales contribuciones de la tesis en el área del desarrollo automático de software. Se introducen también una serie de trabajos futuros que se pueden llevar a cabo tras la finalización de la tesis. Por último, se presentan las principales publicaciones realizadas por la autora en el ámbito de la tesis. 6.1. Contribuciones El Desarrollo Dirigido por Modelos y las Factorías de Software son aproximaciones para el desarrollo de software que en los últimos años están aportando importantes beneficios a la Ingeniería del Software. Estas filosofías de desarrollo de software requieren la definición de modelos conceptuales precisos y de implementaciones de calidad que representen a nivel software estos modelos. Además es necesario proporcionar técnicas de transformación que permitan obtener la implementación de los modelos de forma automática. La asociación carece actualmente de una definición unificada que permita utilizarla en los modelos conceptuales de forma precisa. Además, tampoco existen para esta abstracción propuestas de implementación completas que satisfagan los principales factores de calidad del software. En este contexto, las principales contribuciones de la tesis son: • Definición de un Marco Conceptual que identifica un conjunto de

propiedades de la asociación que permiten capturar las características esenciales de las asociaciones en el modelo conceptual. El marco se construye tras un proceso de análisis donde se estudian trabajos previos del área de modelado conceptual que han estudiado y analizado las propiedades de las asociaciones. Durante el proceso de análisis se seleccionan las propiedades de la asociación que cumplen tres criterios básicos: (1) tienen repercusión en la implementación de las asociaciones, evitando propiedades que aporten a los modelos semántica sin ninguna correspondencia en el proceso de transformación a la implementación, (2) son simples, para facilitar su uso en modelos conceptuales y (3) son precisas, para no introducir ambigüedades. Las características del marco propuesto han permitido la definición de un modelo de asociaciones ejecutable y de calidad; y la construcción de un framework que proporciona una implementación de calidad para las asociaciones.

• Construcción de un Modelo para las Asociaciones. El modelo

construido se caracteriza por satisfacer unos criterios de calidad que garantizan su utilidad y eficiencia en el área de modelado conceptual. El modelo es: (1) comprensible. La elaboración del modelo parte de las definiciones básicas de UML para los conceptos de asociación, agregación

222

y composición. La enorme difusión de UML garantiza la comprensibilidad del modelo; (2) preciso. Se clarifican los principales aspectos problemáticos de las asociaciones, posicionando el trabajo entre las distintas tendencias existentes. Además se utilizan las propiedades del marco conceptual para caracterizar los tipos de asociación (asociación, agregación y composición); (3) abstracto. Se evitan detalles irrelevantes de las asociaciones, las propiedades del marco conceptual únicamente incluyen propiedades con implicación en la implementación; (4) sencillo. Las nociones utilizadas para la construcción del modelo son las más recurrentes de la literatura, lo que simplifica su uso en modelos conceptuales. Las propiedades del marco han sido seleccionadas utilizando el criterio de usabilidad, esto garantiza la sencillez del modelo construido en base a estas propiedades. Por otro lado, es importante destacar que el modelo ha sido presentado utilizando la técnica del metamodelado. De esta forma el modelo propuesto se introduce de forma precisa.

• Definición de un Perfil UML. Con el objetivo de ampliar el ámbito de

aplicación del modelo propuesto se ha construido un perfil UML que extiende el metamodelo de este lenguaje. Esto permite mejorar la especificación de asociaciones en UML. El perfil proporciona nuevos constructores que permiten al diseñador definir sus modelos en UML, utilizando como base para el modelado las definiciones de nuestra propuesta.

• Construcción de una Guía Metodológica. Los métodos de modelado

actuales olvidan con frecuencia la importancia de ofrecer guías metodológicas que faciliten la tarea de modelado a los diseñadores. La relevancia que están adquiriendo los modelos dentro del proceso de desarrollo del software, aumenta la necesidad de ofrecer guías metodológicas que den soporte a estos modelos. Nuestra propuesta ofrece una guía metodológica que, basándose en las propiedades del marco conceptual, dirige de forma sistemática el proceso de modelado de asociaciones, facilitando al diseñador la realización de esta tarea. Esta guía se ha implementado a través de un ayudante (“wizard”), construido como un anexo de la herramienta de modelado Rational Rose.

• Construcción de un Framework para la implementación de las

asociaciones. La necesidad de proporcionar una implementación para las asociaciones viene motivada por la carencia de propuestas de implementación completas y de calidad. Nuestra propuesta ha utilizado como directrices de desarrollo unos factores de calidad específicos de la implementación de asociaciones. Esto ha permitido que la implementación construida satisfaga los principales criterios de calidad del software. Para dar respuesta a estos factores de calidad, el framework se ha basado en el uso de patrones de diseño. Los patrones de diseño garantizan la calidad de las estructuras propuestas, puesto que los patrones ofrecen estructuras de diseño probadas y de alta calidad. La estructura de clases que forma el framework se obtiene con la combinación de tres patrones de diseño seleccionados para

223

implementar las asociaciones siguiendo las directrices marcadas. Con la aplicación de estos patrones se proponen estrategias de ejecución que garantizan la satisfacción de las condiciones asociadas a las propiedades del marco. El framework proporciona una estructura de clases de diseño óptima para la implementación de las asociaciones. Esta estructura se completa con una propuesta para la implementación de los métodos que dan soporte a la funcionalidad específica de las asociaciones. De esta manera se consigue una implementación completa y de calidad.

• Definición de las Correspondencias entre el Modelo de

Asociaciones y el Framework. Además del Modelo de Asociaciones y del Framework que representa a nivel software al modelo, se han definido las correspondencias entre los elementos del modelo conceptual y los elementos del framework. Estas correspondencias constituyen el proceso de transformación entre el modelo de asociaciones y su representación software. De esta forma se proporcionan todos los elementos participantes en el ciclo de desarrollo de un producto software siguiendo la filosofía del MDD: desde los modelos de alto y bajo nivel de abstracción (el modelo conceptual de asociaciones y el framework), hasta los procesos de transformación que permiten convertir unos modelos en otros. Las correspondencias entre ambos modelos se han definido basándose en (1) los elementos que componen la asociación y en (2) las propiedades que la caracterizan.

• Validación del Framework. En el apéndice A se ha evaluado el

framework con el objetivo de ratificar la validez del mismo. Se han diseñado un conjunto de casos de prueba para instanciar el framework. Los resultados de estas pruebas permiten determinar si es posible realizar la implementación de cualquier tipo de asociación. El éxito en la evaluación del framework depende de la correcta elección de los casos de pruebas. Para elaborar un conjunto de casos de prueba que permita evaluar de forma completa el framework, se han utilizado los patrones identificados por Nicola et al. en [BOL04]. Estos patrones representan un conjunto irreducible de patrones de asociación que aparecen en la mayoría de aplicaciones de negocio. Este trabajo está basado en la experiencia de sus autores en el desarrollo y consulta de aplicaciones de negocio. En el apéndice se muestra la implementación de todos los casos de prueba, lo que confirma la validación del framework.

La tesis en su totalidad muestra el proceso de desarrollo completo para

la generación de código de asociaciones. Para ello, la tesis incorpora el uso de diferentes técnicas en la construcción de un método de desarrollo de software para las asociaciones: elaboración de un marco conceptual para precisar y caracterizar la abstracción asociación, utilización de perfiles UML, aplicación del metamodelado y uso de patrones de diseño en la construcción de una solución software para esta abstracción.

Las propuestas realizadas en la tesis están siendo incorporadas a la

herramienta CASE que da soporte al método OO-Method, OLIVA NOVA Model Execution[ONME]. Estas propuestas pretenden mejorar el proceso de

224

desarrollo de productos software, en particular, respecto a la abstracción asociación. 6.2. Trabajo Futuro El trabajo desarrollado tiene continuidad en varias áreas de trabajo que se pueden abordar en un futuro próximo. Estas áreas son: 1. Modelado Conceptual.

El marco conceptual propuesto puede ampliarse capturando nuevas propiedades de la asociación en el dominio de la aplicación. Estas propiedades deberían cumplir los criterios de calidad identificados en la tesis. Identificando propiedades que satisfagan estos criterios se podría mejorar la expresividad del marco.

El modelo de asociaciones puede extenderse para relaciones n-arias. Aunque las asociaciones binarias son las más frecuentes en las aplicaciones, sería interesante completar la propuesta de modelo para asociaciones de grado mayor que 2. La extensión del modelo requiere la reformulación de las propiedades del marco. La semántica de algunas propiedades debería modificarse, por ejemplo, las propiedades definidas sobre los extremos que tienen valores complementarios tienen que ser replanteadas. Además, sería necesario actualizar la notación gráfica utilizada para representar algunas propiedades del framework, como la multiplicidad. También las dependencias entre las propiedades del marco deberían ser redefinidas.

Otra posible extensión de la tesis sería abordar el estudio de relaciones entre asociaciones. A este nivel aparecen restricciones relacionadas con la multiplicidad, la simetría o la transitividad. En nuestro modelo las relaciones entre asociaciones que implican restricciones, se definen utilizando un lenguaje de restricciones. La propuesta mejoraría si se capturaran las posibles relaciones que pueden aparecer entre distintas asociaciones, de esta manera se evitaría la necesidad de formular condiciones en un lenguaje específico para expresar estas relaciones. 2. Técnicas de Implementación.

Un trabajo interesante es la búsqueda de patrones de diseño alternativos, que se puedan aplicar en la construcción del framework de implementación. Esto podría mejorar la calidad del producto software generado.

Los patrones constituyen una herramienta que está adquiriendo especial relevancia dentro de las aproximaciones de MDA y Software Factories. Los patrones proporcionan un mecanismo perfecto para soportar la construcción de máquinas de transformación y contribuyen en la producción automática de software de alta calidad. La investigación en el área de DSDM basada en los patrones de diseño y frameworks para el software es actualmente un tema candente, dentro del cual se posiciona la tesis.

225

3. Procesos de Transformación.

Siguiendo la aproximación de MDA, el framework propuesto puede aplicarse en generadores automáticos de código. Actualmente se está trabajando en la especificación de una Gramática de Grafos que implemente automáticamente las correspondencias especificadas [MRAP04]. Esta gramática permite transformar modelos construidos usando el marco conceptual propuesto, en modelos que extienden e instancian el framework de implementación construido.

Las técnicas para la implementación de transformaciones entre modelos, es una de las tendencias actuales en la aproximación MDA donde existe gran actividad. 6.3. Publicaciones El trabajo relacionado con la tesis ha sido publicado en las siguientes revistas, libros, conferencias y congresos41: Manoli Albert, Marta Ruiz, Javier Muñoz y Vicente Pelechano. A Framework based on Design Patterns to Implement UML Association, Aggregation and Composition Relationships in the Context of Model-Driven Code Generation. Object-Oriented Design Knowledge: Principles, Heuristics and Best Practices Edited by Javier Garzás and Mario Piattini Editorial: IDEA Group Publishing 2007 ISBN: 1-59140-896-2 Manoli Albert, Vicente Pelechano, Joan Fons, Marta Ruiz y Oscar Pastor. Implementing UML Association, Aggregation and Composition. A Particular Interpretation based on a Multidimensional Framework. Springer-Verlag, Lecture Notes in Computer Science. Proc. Of the Advanced Information Systems Engineering, 15th International Conference, CAiSE 2003, Klagenfurt/Velden (Austria), June 16-20, 2003. ISBN 3-540-40442-2. LNCS (2681). Marta Ruiz, Manoli Albert, Victoria Torres, Vicente Pelechano. Un Framework para la Implementación de Relaciones de Asociación, Agregación y Composición en UML. VII Workshop Iberoamericano en Ingeniería de Requisitos y Ambientes Software. IDEAS’04. ISBN 9972-9876-1-2. Javier Muñoz, Marta Ruiz, Manoli Albert, Vicente Pelechano. MDA Aplicado: Una Gramática de Grafos para la Transformación de Relaciones de Asociación. JISBD’04. pp. 539-546. ISBN: 84-688-8983-0. Manoli Albert, Vicente Pelechano, Joan Fons, Gonzalo Rojas y Oscar Pastor. Extracting Knowledge form Association, Aggregation and Composition Relationships to Navigational Models. 1st Latin American Web Congreso. LAWEB. ISBN 0-7695-2058-8. 2003.

41 Los trabajos se presentan en orden cronológico.

226

Manoli Albert, Eva Campos, Vicente Pelechano. Un Modelo de Agregación y su Representación Software. I+D Computación (Cenidet, Centro Nacional de Investigación y Desarrollo Tecnológico, Mexico). ISSN: 1665-238X Academia de postgrado de Ciencias Computacionales. Vo. 1 (2) 2002. pp. 164-177. Manoli Albert y Vicente Pelechano. Modelado e Implementación de Relaciones de Asociación. Una Caracterización Multidimensional. Jornadas de Ingeniería del Software y Bases de Datos. JISBD’02. ISBN: 84-688-0206-9. 2002. Eva Campos, Manoli Albert, Vicente Pelechano. Un Modelo de Agregación y su Representación Software. 5º Workshop Iberoamericano de Ingeniería de Requisitos y Ambientes Software. IDEAS’02. ISBN: 959-7160-14-5. 2002.

227

Apéndice A Ejemplo de Modelado y Generación de Código En este apéndice se desarrolla un caso de estudio en el que se aplica la estrategia de generación de código propuesta en el capítulo anterior. Con el modelo asociado al caso de estudio se instancia el framework propuesto de forma que se obtienen un conjunto de clases de diseño que constituyen la implementación completa en código C# del nivel de aplicación. A.1. Descripción El sistema utilizado en este apéndice como caso de estudio ha sido introducido anteriormente en el capítulo 5. Este sistema se encarga de la gestión de un grupo de investigación. Para este apéndice seleccionamos un subconjunto del sistema formado por investigadores, conferencias, publicaciones y firmantes de estas publicaciones. La figura B.1 muestra el modelo para el que se va a generar el código.

A.1. Subsistema para la gestión de un grupo de investigación.

Como se puede ver en la figura A.1, la parte del sistema seleccionada, está formada por cuatro clases y tres relaciones. A continuación se describe la naturaleza de estas relaciones:

• Publicación-Firmante: Esta relación representa los firmantes de una publicación. Como se puede ver en el modelo, una publicación debe tener asociado como mínimo un firmante y como máximo 10.

228

Además una publicación puede añadir o eliminar firmantes durante su vida. Cuando se destruye una publicación se destruyen los firmantes asociados a ésta. Los firmantes se identifican a través de la publicación a la que están asociadas. Un firmante siempre está asociado con una publicación (siempre con la misma).

• Publicación-Conferencia: Esta relación representa la conferencia

en la que se difunde una publicación. Una publicación puede no estar difundida en ninguna conferencia, y no puede estarlo en más de una. Un publicación durante su vida puede asociarse con una conferencia, pero una vez ha sido difundida en ella ya no puede eliminarse su relación con ésta. Una conferencia puede difundir un número ilimitado de publicaciones. Durante la vida de una conferencia se le pueden ir añadiendo o eliminando publicaciones. No es posible destruir una conferencia si tiene publicaciones asociadas.

• Firmante-Investigador: Esta relación identifica al investigador

asociado a un firmante de una publicación. Un firmante puede estar asociado a un investigador. Durante la vida de un firmante es posible asociarlo con un investigador o eliminar la relación con un investigador si la tuviera. Un investigador puede estar asociado con un número ilimitado de firmantes. Durante la vida de un investigador se le pueden añadir o eliminar firmantes.

A.2. Estructura de Clases Generada A partir de del modelo de la figura A.1 y aplicando el framework propuesto en el capítulo 5 se obtienen las siguientes clases de diseño:

• ConferenciaAbstracta o Conferencia o DecoradorConferenciaAbstracta

DecoradorConferenciapublicaEn

• PublicacionAbstracta o Publicación o DecoradorPublicacionAbstracta

DecoradorPublicacioncontiene DecoradorPublicacionfirma

• FirmanteAbstracta

o Firmante o DecoradorFirmanteAbstracta

DecoradorFirmanteaparece DecoradorFirmantefirmaComo

• InvestigadorAbstracta

o Investigador o DecoradorInvestigadorAbstracta

229

DecoradorInvestigadoresUn

La figura A.2 muestra la estructura de las clases de diseño que constituyen la implementación del modelo.

A.2. Estructura de Clases de Diseño En el siguiente apartado se presenta la implementación de cada una de estas clases.

230

A.3. Código Generado El código que se muestra en este apartado ha sido generado automáticamente aplicando las plantillas que se presentan en el apéndice B. Clases Participantes Abstractas //Clase ConferenciaAbstracta using System; namespace org.oomethod.publications {

public abstract class ConferenciaAbstracta { protected String nombre; public ConferenciaAbstracta (){ } public abstract String pnombre(); public abstract void Dispose(); } } //Clase PublicacionAbstracta using System; namespace org.oomethod.publications { public abstract class PublicacionAbstracta { //Atributos protected String titulo; protected int anyoPublicacion; protected String resumen; //Constructor

public PublicacionAbstracta (){ } //Métodos de Consulta public abstract String ptitulo(); public abstract int panyoPublicacion(); public abstract String presumen(); public abstract void Dispose(); } } //Clase FirmanteAbstracta

231

using using System; namespace org.oomethod.publications { public abstract class FirmanteAbstracta { //Atributos

protected String firma; protected int posicion; //Atributo proyectado de la clase Publicacion protected String titulo; //Constructor

public FirmanteAbstracta (){ } //Métodos de Consulta public abstract String pfirma(); public abstract int pposicion(); public abstract void Dispose(); } } //Clase FirmanteAbstracta using System; namespace org.oomethod.publications { public abstract class InvestigadorAbstracta { //Atributos

protected String nombre; protected String categoria; //Constructor

public InvestigadorAbstracta (){ } //Métodos de Consulta public abstract String pnombre(); public abstract String pcategoria(); public abstract void Dispose(); } }

232

Clases Participantes //Clase Conferencia using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Conferencia:ConferenciaAbstracta { //Constructor

public Conferencia(String nombre) { this.nombre = nombre; //nombre es el atributo identificador de la clase } //Implementación de los métodos de consulta public override String pnombre(){ return nombre; } public override void Dispose(){ } } } //Clase Publicación using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Publicacion:PublicacionAbstracta { //Constructor

public Publicacion(String titulo) { this.titulo = titulo; //titulo es el atributo identificador } //Implementación de los métodos de consulta public override String ptitulo(){ return titulo; } public override int panyoPublicacion(){ return anyoPublicacion; } public override String presumen(){

return resumen; } public override void Dispose(){ } } }

233

//Clase Firmante using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Firmante:FirmanteAbstracta { //Constructor

public Firmante(String titulo, int posicion) { this.titulo = titulo; this.posicion = posicion; //titulo y posición son los atributos identificadores } //Implementación de los métodos de consulta public override String pfirma(){

return firma; } public override int pposicion(){ return posicion; } public override void Dispose(){ } } } //Clase Investigador using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Investigador:InvestigadorAbstracta { //Constructor public Investigador(String nombre) { this.nombre = nombre; //nombre es el atributo identificador } //Implementación de los métodos de consulta public override String pnombre(){

return nombre; } public override String pcategoria(){ return categoria; } public override void Dispose(){ } } }

234

Clases Mediadoras Concretas //Clase MediadorPublicacionConferencia using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class MediadorPublicacionConferencia:Mediador,IDisposable { public MediadorPublicacionConferencia (DecoradorPublicacionAbstracta origen, DecoradorConferenciaAbstracta destino, String nombre):base(origen, destino, nombre) {

} public override void comprobar_reflexividad(Decorador origen, Decorador destino){ } public override void comprobar_simetria(Decorador origen, Decorador destino){ } public override void comprobar_transitividad(Decorador origen, Decorador destino){ } public override void comprobar_unicidad(Decorador origen, Decorador destino){ if (encontrar_identico(origen, destino)!=null) throw new Exception("Violacion Unicidad"); } public override void comprobar_reflexividad(){ } public override void comprobar_simetria(){ }

public DecoradorPublicacionAbstracta obtener_origen(){ return (DecoradorPublicacionAbstracta) origen; }

private DecoradorConferenciaAbstracta obtener_destino(){ return (DecoradorConferenciaAbstracta) destino; }

public MediadorPublicacionConferencia encontrar_identico(Decorador origen, Decorador destino){

DecoradorPublicacionAbstracta dorigen = (DecoradorPublicacionAbstracta)origen;

foreach(MediadorPublicacionConferencia enlace in dorigen.obtener_coleccion("PublicacionConferencia")){

if (destino.Equals(enlace.obtener_destino())) return enlace; }

return null; } } }

235

//Clase MediadorPublicacionFirmante using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class MediadorPublicacionFirmante:Mediador,IDisposable { public MediadorPublicacionFirmante(DecoradorPublicacionAbstracta origen, DecoradorFirmanteAbstracta destino, String nombre):base(origen, destino, nombre) {

} public override void comprobar_reflexividad(Decorador origen, Decorador destino){ } public override void comprobar_simetria(Decorador origen, Decorador destino){ } public override void comprobar_transitividad(Decorador origen, Decorador destino){ } public override void comprobar_unicidad(Decorador origen, Decorador destino){ if (encontrar_identico(origen, destino)!=null) throw new Exception("Violacion Unicidad"); } public override void comprobar_reflexividad(){ } public override void comprobar_simetria(){ }

public DecoradorPublicacionAbstracta obtener_origen(){ return (DecoradorPublicacionAbstracta) origen;

} public DecoradorFirmanteAbstracta obtener_destino(){

return (DecoradorFirmanteAbstracta) destino; } public MediadorPublicacionFirmante encontrar_identico(Decorador origen, Decorador destino){

DecoradorPublicacionAbstracta dorigen = (DecoradorPublicacionAbstracta)origen; foreach(MediadorPublicacionFirmante enlace in dorigen.obtener_coleccion("PublicacionFirmante")){

if (destino.Equals(enlace.obtener_destino())) return enlace; } return null; } } }

236

//Clase MediadorFirmanteInvestigador using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class MediadorFirmanteInvestigador:Mediador,IDisposable { public MediadorFirmanteInvestigador(DecoradorFirmanteAbstracta origen, DecoradorInvestigadorAbstracta destino, String nombre):base(origen, destino, nombre) { } public override void comprobar_reflexividad(Decorador origen, Decorador destino){ } public override void comprobar_simetria(Decorador origen, Decorador destino){ } public override void comprobar_transitividad(Decorador origen, Decorador destino){ } public override void comprobar_unicidad(Decorador origen, Decorador destino){ if (encontrar_identico(origen, destino)!=null) throw new Exception("Violacion Unicidad"); } public override void comprobar_reflexividad(){ } public override void comprobar_simetria(){ }

public DecoradorFirmanteAbstracta obtener_origen(){ return (DecoradorFirmanteAbstracta) origen; }

public DecoradorInvestigadorAbstracta obtener_destino(){

return (DecoradorInvestigadorAbstracta) destino; }

public MediadorFirmanteInvestigador encontrar_identico(Decorador origen, Decorador destino){ DecoradorFirmanteAbstracta dorigen = (DecoradorFirmanteAbstracta)origen;

foreach(MediadorFirmanteInvestigador enlace in dorigen.obtener_coleccion("FirmanteInvestigador")){

if (destino.Equals(enlace.obtener_destino())) return enlace; }

237

return null; } } }

238

Clases Decoradoras Abstractas //Clase DecoradorConferenciaAbstracta using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public abstract class DecoradorConferenciaAbstracta:ConferenciaAbstracta, Decorador, IDisposable { protected ConferenciaAbstracta ObjetoDecorado; protected bool idestruccion = false; public DecoradorConferenciaAbstracta(ConferenciaAbstracta decorado) { ObjetoDecorado = decorado; } public void conectar_enlace (Mediador enlace) { comprobar_mult_max(enlace.obtener_nombre()); anyadir_enlace(enlace, enlace.obtener_nombre()); } public void desconectar_enlace (Mediador enlace){ eliminar_enlace(enlace, enlace.obtener_nombre()); comprobar_mult_min(enlace.obtener_nombre()); propagar_borrado_desconexion(enlace.obtener_nombre()); } public override void Dispose(){ if (!idestruccion){ idestruccion = true; propagar_borrado_destruccion(); ObjetoDecorado.Dispose(); GC.SuppressFinalize(this); } } public ConferenciaAbstracta obtener_objetoDecorado(){ return ObjetoDecorado; } public abstract void comprobar_mult_max(String asociacion); public abstract void comprobar_mult_min(String asociacion); public abstract void propagar_borrado_destruccion(); public abstract void propagar_borrado_desconexion(String asociacion); public abstract void comprobar_reflexividad(); public abstract void anyadir_enlace(Mediador enlace, String asociacion); public abstract void eliminar_enlace(Mediador enlace, String asociacion); public abstract ArrayList obtener_coleccion(); public abstract ArrayList obtener_asociado(); } }

239

//Clase DecoradorPublicacionAbstracta using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public abstract class DecoradorPublicacionAbstracta:PublicacionAbstracta, Decorador, IDisposable { protected PublicacionAbstracta ObjetoDecorado; protected bool idestruccion = false; public DecoradorPublicacionAbstracta(PublicacionAbstracta decorado) { ObjetoDecorado = decorado; } public void conectar_enlace (Mediador enlace) { comprobar_mult_max(enlace.obtener_nombre()); anyadir_enlace(enlace, enlace.obtener_nombre()); } public void desconectar_enlace (Mediador enlace){ eliminar_enlace(enlace, enlace.obtener_nombre()); comprobar_mult_min(enlace.obtener_nombre()); propagar_borrado_desconexion(enlace.obtener_nombre()); } public override void Dispose(){ if (!idestruccion){ idestruccion = true; propagar_borrado_destruccion(); ObjetoDecorado.Dispose(); GC.SuppressFinalize(this); } } public PublicacionAbstracta obtener_objetoDecorado(){ return ObjetoDecorado; } public abstract void comprobar_mult_max(String asociacion); public abstract void comprobar_mult_min(String asociacion); public abstract void propagar_borrado_destruccion(); public abstract void propagar_borrado_desconexion(String asociacion); public abstract void comprobar_reflexividad(); public abstract void anyadir_enlace(Mediador enlace, String asociacion); public abstract void eliminar_enlace(Mediador enlace, String asociacion); public abstract ArrayList obtener_coleccion(String asociacion); public abstract ArrayList obtener_asociado(String asociacion); }

240

} //Clase DecoradorFirmanteAbstracta using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public abstract class DecoradorFirmanteAbstracta:FirmanteAbstracta, Decorador, IDisposable { protected FirmanteAbstracta ObjetoDecorado; protected bool idestruccion = false; public DecoradorFirmanteAbstracta(FirmanteAbstracta decorado) { ObjetoDecorado = decorado; } public void conectar_enlace (Mediador enlace) { comprobar_mult_max(enlace.obtener_nombre()); anyadir_enlace(enlace, enlace.obtener_nombre()); } public void desconectar_enlace (Mediador enlace){ eliminar_enlace(enlace, enlace.obtener_nombre()); comprobar_mult_min(enlace.obtener_nombre()); propagar_borrado_desconexion(enlace.obtener_nombre()); } public override void Dispose(){ if (!idestruccion){ idestruccion = true; propagar_borrado_destruccion(); ObjetoDecorado.Dispose(); GC.SuppressFinalize(this); } } public FirmanteAbstracta obtener_objetoDecorado(){ return ObjetoDecorado; } public abstract void comprobar_mult_max(String asociacion); public abstract void comprobar_mult_min(String asociacion); public abstract void propagar_borrado_destruccion(); public abstract void propagar_borrado_desconexion(String asociacion); public abstract void comprobar_reflexividad(); public abstract void anyadir_enlace(Mediador enlace, String asociacion); public abstract void eliminar_enlace(Mediador enlace, String asociacion); public abstract ArrayList obtener_coleccion(String asociacion); public abstract ArrayList obtener_asociado(String asociacion);

241

} } //Clase DecoradorInvestigadorAbstracta using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public abstract class DecoradorInvestigadorAbstracta:InvestigadorAbstracta, Decorador, IDisposable { protected InvestigadorAbstracta ObjetoDecorado; protected bool idestruccion = false; public DecoradorInvestigadorAbstracta(InvestigadorAbstracta decorado) { ObjetoDecorado = decorado; } public void conectar_enlace (Mediador enlace) { comprobar_mult_max(enlace.obtener_nombre()); anyadir_enlace(enlace, enlace.obtener_nombre()); } public void desconectar_enlace (Mediador enlace){ eliminar_enlace(enlace, enlace.obtener_nombre()); comprobar_mult_min(enlace.obtener_nombre()); propagar_borrado_desconexion(enlace.obtener_nombre()); } public override void Dispose(){ if (!idestruccion){ idestruccion = true; propagar_borrado_destruccion(); ObjetoDecorado.Dispose(); GC.SuppressFinalize(this); } } public InvestigadorAbstracta obtener_objetoDecorado(){ return ObjetoDecorado; } public abstract void comprobar_mult_max(String asociacion); public abstract void comprobar_mult_min(String asociacion); public abstract void propagar_borrado_destruccion(); public abstract void propagar_borrado_desconexion(String asociacion); public abstract void comprobar_reflexividad(); public abstract void anyadir_enlace(Mediador enlace, String asociacion); public abstract void eliminar_enlace(Mediador enlace, String asociacion); public abstract ArrayList obtener_coleccion(); public abstract ArrayList obtener_asociado();

242

} }

243

Clases Decoradoras Concretas //Clase DecoradorConferenciapublicaEn using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class DecoradorConferenciapublicaEn:DecoradorConferenciaAbstracta { ArrayList ColeccionPublicacion; public DecoradorConferenciapublicaEn(ConferenciaAbstracta decorado):base(decorado) { ColeccionPublicacion = new ArrayList(); comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public DecoradorConferenciapublicaEn(ConferenciaAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionPublicacion = new ArrayList(); foreach (PublicacionAbstracta asociado in asociados){ new MediadorPublicacionConferencia((DecoradorPublicacionAbstracta)asociado, this, "PublicacionConferencia"); } comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public DecoradorConferenciapublicaEn(ConferenciaAbstracta decorado, params object [] atributos):base(decorado) { ColeccionPublicacion = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); PublicacionAbstracta nuevoObjeto = new DecoradorPublicacionfirma( new DecoradorPublicacioncontiene(new Publicacion(atributos[0].ToString()))); comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion){ return (new MediadorPublicacionConferencia((DecoradorPublicacionAbstracta)nobject, this, asociacion)); } public void borrar(Decorador nobject, String asociacion){ MediadorPublicacionConferencia enlace = buscar_enlace((DecoradorPublicacionAbstracta)nobject); if (enlace != null) enlace.Dispose(); } public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion)

244

{ MediadorPublicacionConferencia enlace = buscar_enlace((DecoradorPublicacionAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); }

public override void comprobar_mult_max(String asociacion) {

//No es necesaria ninguna comprobacion }

public override void comprobar_mult_min(String asociacion) {

//No es necesaria ninguna comprobacion } public override void propagar_borrado_destruccion(){ if (ColeccionPublicacion.Count<>0) throw new Exception("Exiting Link cannot be destroyed"); } public override void propagar_borrado_desconexion(String asociacion){ //No es necesaria ninguna comprobacion } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion } public override void anyadir_enlace(Mediador enlace, String asociacion) { ColeccionPublicacion.Add(enlace); } public override void eliminar_enlace(Mediador enlace, String asociacion) { ColeccionPublicacion.Remove(enlace); } public override ArrayList obtener_coleccion(){ return ColeccionPublicacion; } public override ArrayList obtener_asociado(){ ArrayList asociados = new ArrayList(); foreach (MediadorPublicacionConferencia enlace in ColeccionPublicacion){ asociados.Add(enlace.obtener_origen()); } return asociados; } public MediadorPublicacionConferencia buscar_enlace(DecoradorPublicacionAbstracta nobject) { foreach(MediadorPublicacionConferencia enlace in ColeccionPublicacion) {

245

if (enlace.obtener_origen().Equals(nobject)) return enlace; } return null; } public override String pnombre(){ return ObjetoDecorado.pnombre(); } } } //Clase DecoradorPublicacioncontiene using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class DecoradorPublicacioncontiene:DecoradorPublicacionAbstracta { ArrayList ColeccionConferencia; public DecoradorPublicacioncontiene(PublicacionAbstracta decorado):base(decorado) { ColeccionConferencia = new ArrayList(); comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public DecoradorPublicacioncontiene(PublicacionAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionConferencia = new ArrayList(); foreach (ConferenciaAbstracta asociado in asociados){ new MediadorPublicacionConferencia( this, (DecoradorConferenciaAbstracta)asociado,"PublicacionConferencia"); } comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public DecoradorPublicacioncontiene(PublicacionAbstracta decorado, params object [] atributos):base(decorado) { ColeccionConferencia = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); ConferenciaAbstracta nuevoObjeto = new DecoradorConferenciapublicaEn(new Conferencia(atributos[0].ToString())); comprobar_mult_min("PublicacionConferencia"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionConferencia")){

246

DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma) ObjetoDecorado; return dec.insertar(nobject, asociacion); } else return (new MediadorPublicacionConferencia(this, (DecoradorConferenciaAbstracta) nobject, "PublicacionConferencia")); } public void borrar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionConferencia")){ DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma) ObjetoDecorado; dec.borrar(nobject, asociacion); } else { //No es necesaria ninguna accion } } public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion)

{ if (!asociacion.Equals("PublicacionConferencia")) { DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma)ObjetoDecorado; dec.modificar(objAntiguo, objNuevo, asociacion); } else { MediadorPublicacionConferencia enlace = buscar_enlace((DecoradorConferenciaAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); } }

public override void comprobar_mult_max(String asociacion) {

if (asociacion.Equals("PublicacionConferencia")){ if (ColeccionConferencia.Count ==1){ throw new Exception("Max Multiplicity Violation"); } } else { DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma)ObjetoDecorado; dec.comprobar_mult_max(asociacion); } }

public override void comprobar_mult_min(String asociacion) {

if (asociacion.Equals("PublicacionConferencia")){ //No es necesaria ninguna comprobacion } else {

247

DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma)ObjetoDecorado; dec.comprobar_mult_min(asociacion); } } public override void propagar_borrado_destruccion(){ ArrayList enlacesModificados = new ArrayList(); foreach(MediadorPublicacionConferencia enlace in ColeccionConferencia){ enlacesModificados.Add(enlace); } foreach(MediadorPublicacionConferencia enlace in enlacesModificados){ enlace.obtener_destino().Dispose(); } } public override void propagar_borrado_desconexion(String asociacion){ if (asociacion.Equals("PublicacionConferencia")){ throw new Exception("Disconnection Not Allowed"); } else { DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma) ObjetoDecorado; dec.propagar_borrado_desconexion(asociacion); } } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion } public override void anyadir_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionConferencia")) { ColeccionConferencia.Add(enlace); } else { DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma)ObjetoDecorado; dec.anyadir_enlace(enlace, asociacion); } } public override void eliminar_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionConferencia")) { ColeccionConferencia.Remove(enlace); } else { DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma)ObjetoDecorado; dec.eliminar_enlace(enlace, asociacion); } }

248

public override ArrayList obtener_coleccion(String asociacion){ if (!asociacion.Equals("PublicacionConferencia")){ DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma) ObjetoDecorado; return dec.obtener_coleccion(asociacion); } else { return ColeccionConferencia; } } public override ArrayList obtener_asociado(String asociacion){ if (!asociacion.Equals("PublicacionConferencia")){ DecoradorPublicacionfirma dec = (DecoradorPublicacionfirma) ObjetoDecorado; return dec.obtener_asociado(asociacion); } else { ArrayList asociados = new ArrayList(); foreach (MediadorPublicacionConferencia enlace in ColeccionConferencia){ asociados.Add(enlace.obtener_destino()); } return asociados; } } public MediadorPublicacionConferencia buscar_enlace(DecoradorConferenciaAbstracta nobject) { foreach(MediadorPublicacionConferencia enlace in ColeccionConferencia) { if (enlace.obtener_destino().Equals(nobject)) return enlace; } return null; } public override String ptitulo(){ return ObjetoDecorado.ptitulo(); } public override int panyoPublicacion(){ return ObjetoDecorado.panyoPublicacion(); } public override String presumen(){ return ObjetoDecorado.presumen(); } } } //Clase DecoradorPublicacionfirma using System; using System.Collections; using System.Text;

249

namespace org.oomethod.publications { public class DecoradorPublicacionfirma:DecoradorPublicacionAbstracta { ArrayList ColeccionFirmante; public DecoradorPublicacionfirma(PublicacionAbstracta decorado):base(decorado) { ColeccionFirmante = new ArrayList(); comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public DecoradorPublicacionfirma(PublicacionAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionFirmante = new ArrayList(); foreach (FirmanteAbstracta asociado in asociados){ new MediadorPublicacionFirmante( this, (DecoradorFirmanteAbstracta)asociado,"PublicacionFirmante"); } comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public DecoradorPublicacionfirma(PublicacionAbstracta decorado, params object [] atributos):base(decorado) { ColeccionFirmante = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); FirmanteAbstracta nuevoObjeto = new DecoradorFirmanteaparece( new DecoradorFirmantefirmaComo(new Firmante(atributos[0].ToString(), int.Parse(atributos[1].ToString())))); comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionFirmante")){ DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene) ObjetoDecorado; return dec.insertar(nobject, asociacion); } else return (new MediadorPublicacionFirmante(this, (DecoradorFirmanteAbstracta) nobject, "PublicacionFirmante")); } public void borrar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionFirmante")){ //No es necesaria ninguna accion } else { MediadorPublicacionFirmante enlace = buscar_enlace((DecoradorFirmanteAbstracta)nobject); if (enlace != null) enlace.Dispose(); } }

250

public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion) { if (!asociacion.Equals("PublicacionFirmante")) { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene)ObjetoDecorado; dec.modificar(objAntiguo, objNuevo, asociacion); } else { MediadorPublicacionFirmante enlace = buscar_enlace((DecoradorFirmanteAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); }

}

public override void comprobar_mult_max(String asociacion) {

if (asociacion.Equals("PublicacionFirmante")){ if (ColeccionFirmante.Count ==10){ throw new Exception("Max Multiplicity Violation"); } } else { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene)ObjetoDecorado; dec.comprobar_mult_max(asociacion); } }

public override void comprobar_mult_min(String asociacion) {

if (asociacion.Equals("PublicacionFirmante")){ if ( !idestruccion && ColeccionFirmante.Count ==0){ throw new Exception("Min Multiplicity Violation"); } } else { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene)ObjetoDecorado; dec.comprobar_mult_min(asociacion); } } public override void propagar_borrado_destruccion(){ ArrayList enlacesModificados = new ArrayList(); foreach(MediadorPublicacionFirmante enlace in ColeccionFirmante){ enlacesModificados.Add(enlace); } foreach(MediadorPublicacionFirmante enlace in enlacesModificados){ enlace.obtener_destino().Dispose(); } }

251

public override void propagar_borrado_desconexion(String asociacion){ if (asociacion.Equals("PublicacionFirmante")){ //No es necesaria ninguna comprobacion } else { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene) ObjetoDecorado; dec.propagar_borrado_desconexion(asociacion); } } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion } public override void anyadir_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionFirmante")) { ColeccionFirmante.Add(enlace); } else { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene)ObjetoDecorado; dec.anyadir_enlace(enlace, asociacion); } } public override void eliminar_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionFirmante")) { ColeccionFirmante.Remove(enlace); } else { DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene)ObjetoDecorado; dec.eliminar_enlace(enlace, asociacion); } } public override ArrayList obtener_coleccion(String asociacion){ if (!asociacion.Equals("PublicacionFirmante")){ DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene) ObjetoDecorado; return dec.obtener_coleccion(asociacion); } else { return ColeccionFirmante; } } public override ArrayList obtener_asociado(String asociacion){ if (!asociacion.Equals("PublicacionFirmante")){ DecoradorPublicacioncontiene dec = (DecoradorPublicacioncontiene) ObjetoDecorado;

252

return dec.obtener_asociado(asociacion); } else { ArrayList asociados = new ArrayList(); foreach (MediadorPublicacionFirmante enlace in ColeccionFirmante){ asociados.Add(enlace.obtener_destino()); } return asociados; } } public MediadorPublicacionFirmante buscar_enlace(DecoradorFirmanteAbstracta nobject) { foreach(MediadorPublicacionFirmante enlace in ColeccionFirmante) { if (enlace.obtener_destino().Equals(nobject)) return enlace; } return null; } public override String ptitulo(){ return ObjetoDecorado.ptitulo(); } public override int panyoPublicacion(){ return ObjetoDecorado.panyoPublicacion(); } public override String presumen(){ return ObjetoDecorado.presumen(); } } } //Clase DecoradorFirmanteaparece using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class DecoradorFirmanteaparece:DecoradorFirmanteAbstracta { ArrayList ColeccionPublicacion; public DecoradorFirmanteaparece(FirmanteAbstracta decorado):base(decorado) { ColeccionPublicacion = new ArrayList(); comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public DecoradorFirmanteaparece(FirmanteAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionPublicacion = new ArrayList();

253

foreach (PublicacionAbstracta asociado in asociados){ new MediadorPublicacionFirmante((DecoradorPublicacionAbstracta)asociado, this, "PublicacionFirmante"); } comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public DecoradorFirmanteaparece(FirmanteAbstracta decorado, params object [] atributos):base(decorado) { ColeccionPublicacion = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); PublicacionAbstracta nuevoObjeto = new DecoradorPublicacionfirma( new DecoradorPublicacioncontiene(new Publicacion(atributos[0].ToString()))); comprobar_mult_min("PublicacionFirmante"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionFirmante")){ DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo) ObjetoDecorado; return dec.insertar(nobject, asociacion); } else return null; } public void borrar(Decorador nobject, String asociacion) { if (!asociacion.Equals("PublicacionFirmante")){ DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo) ObjetoDecorado; dec.borrar(nobject, asociacion); } else { //No es necesaria ninguna accion } } public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion)

{ if (!asociacion.Equals("PublicacionFirmante")) { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo)ObjetoDecorado; dec.modificar(objAntiguo, objNuevo, asociacion); } else { MediadorPublicacionFirmante enlace = buscar_enlace((DecoradorPublicacionAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); }

}

254

public override void comprobar_mult_max(String asociacion) {

if (asociacion.Equals("PublicacionFirmante")){ if (ColeccionPublicacion.Count ==1){ throw new Exception("Max Multiplicity Violation"); } } else { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo)ObjetoDecorado; dec.comprobar_mult_max(asociacion); } }

public override void comprobar_mult_min(String asociacion) {

if (asociacion.Equals("PublicacionFirmante")){ if ( !idestruccion && ColeccionPublicacion.Count ==0){ throw new Exception("Min Multiplicity Violation"); } } else { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo)ObjetoDecorado; dec.comprobar_mult_min(asociacion); } } public override void propagar_borrado_destruccion(){ ArrayList enlacesModificados = new ArrayList(); foreach(MediadorPublicacionFirmante enlace in ColeccionPublicacion){ enlacesModificados.Add(enlace); } foreach(MediadorPublicacionFirmante enlace in enlacesModificados){ enlace.Dispose(); } } public override void propagar_borrado_desconexion(String asociacion){ if (asociacion.Equals("PublicacionFirmante")){ this.Dispose(); } else { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo) ObjetoDecorado; dec.propagar_borrado_desconexion(asociacion); } } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion }

255

public override void anyadir_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionFirmante")) { ColeccionPublicacion.Add(enlace); } else { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo)ObjetoDecorado; dec.anyadir_enlace(enlace, asociacion); } } public override void eliminar_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("PublicacionFirmante")) { ColeccionPublicacion.Remove(enlace); } else { DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo)ObjetoDecorado; dec.eliminar_enlace(enlace, asociacion); } } public override ArrayList obtener_coleccion(String asociacion){ if (!asociacion.Equals("PublicacionFirmante")){ DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo) ObjetoDecorado; return dec.obtener_coleccion(asociacion); } else { return ColeccionPublicacion; } } public override ArrayList obtener_asociado(String asociacion){ if (!asociacion.Equals("PublicacionFirmante")){ DecoradorFirmantefirmaComo dec = (DecoradorFirmantefirmaComo) ObjetoDecorado; return dec.obtener_asociado(asociacion); } else { ArrayList asociados = new ArrayList(); foreach (MediadorPublicacionFirmante enlace in ColeccionPublicacion){ asociados.Add(enlace.obtener_origen()); } return asociados; } } public MediadorPublicacionFirmante buscar_enlace(DecoradorPublicacionAbstracta nobject) { foreach(MediadorPublicacionFirmante enlace in ColeccionPublicacion) { if (enlace.obtener_origen().Equals(nobject)) return enlace;

256

} return null; } public override String pfirma(){ return ObjetoDecorado.pfirma(); } public override int pposicion(){ return ObjetoDecorado.pposicion(); } } } //Clase DecoradorFirmantefirmaComo using System; using System.Collections; using System.Text; namespace org.oomethod.publications {

public class DecoradorFirmantefirmaComo:DecoradorFirmanteAbstracta {

ArrayList ColeccionInvestigador; public DecoradorFirmantefirmaComo(FirmanteAbstracta decorado):base(decorado) { ColeccionInvestigador = new ArrayList(); comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public DecoradorFirmantefirmaComo(FirmanteAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionInvestigador = new ArrayList(); foreach (InvestigadorAbstracta asociado in asociados){ new MediadorFirmanteInvestigador( this, (DecoradorInvestigadorAbstracta)asociado,"FirmanteInvestigador"); } comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public DecoradorFirmantefirmaComo(FirmanteAbstracta decorado, params object [] atributos):base(decorado) { ColeccionInvestigador = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); InvestigadorAbstracta nuevoObjeto = new DecoradorInvestigadoresUn(new Investigador(atributos[0].ToString())); comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion) {

257

if (!asociacion.Equals("FirmanteInvestigador")){ return null; } else return (new MediadorFirmanteInvestigador(this, (DecoradorInvestigadorAbstracta) nobject, "FirmanteInvestigador")); } public void borrar(Decorador nobject, String asociacion) { if (!asociacion.Equals("FirmanteInvestigador")){ //No es necesaria ninguna accion } else { MediadorFirmanteInvestigador enlace = buscar_enlace((DecoradorInvestigadorAbstracta)nobject); if (enlace != null) enlace.Dispose(); } } public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion)

{ if (!asociacion.Equals("FirmanteInvestigador")) { DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece)ObjetoDecorado; dec.modificar(objAntiguo, objNuevo, asociacion); } else { MediadorFirmanteInvestigador enlace = buscar_enlace((DecoradorInvestigadorAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); } }

public override void comprobar_mult_max(String asociacion) {

if (asociacion.Equals("FirmanteInvestigador")){ if (ColeccionInvestigador.Count ==1){ throw new Exception("Max Multiplicity Violation"); } } else { DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece)ObjetoDecorado; dec.comprobar_mult_max(asociacion); } }

public override void comprobar_mult_min(String asociacion) {

if (asociacion.Equals("FirmanteInvestigador")){ //No es necesaria ninguna comprobacion } else {

258

DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece)ObjetoDecorado; dec.comprobar_mult_min(asociacion); } } public override void propagar_borrado_destruccion(){ ArrayList enlacesModificados = new ArrayList(); foreach(MediadorFirmanteInvestigador enlace in ColeccionInvestigador){ enlacesModificados.Add(enlace); } foreach(MediadorFirmanteInvestigador enlace in enlacesModificados){ enlace.Dispose(); } } public override void propagar_borrado_desconexion(String asociacion){ if (asociacion.Equals("FirmanteInvestigador")){ //No es necesaria ninguna comprobacion } else { DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece) ObjetoDecorado; dec.propagar_borrado_desconexion(asociacion); } } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion } public override void anyadir_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("FirmanteInvestigador")) { ColeccionInvestigador.Add(enlace); } else { DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece)ObjetoDecorado; dec.anyadir_enlace(enlace, asociacion); } } public override void eliminar_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("FirmanteInvestigador")) { ColeccionInvestigador.Remove(enlace); } else { DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece)ObjetoDecorado; dec.eliminar_enlace(enlace, asociacion); } }

259

public override ArrayList obtener_coleccion(String asociacion){ if (!asociacion.Equals("FirmanteInvestigador")){ DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece) ObjetoDecorado; return dec.obtener_coleccion(asociacion); } else { return ColeccionInvestigador; } } public override ArrayList obtener_asociado(String asociacion){ if (!asociacion.Equals("FirmanteInvestigador")){ DecoradorFirmanteaparece dec = (DecoradorFirmanteaparece) ObjetoDecorado; return dec.obtener_asociado(asociacion); } else { ArrayList asociados = new ArrayList(); foreach (MediadorFirmanteInvestigador enlace in ColeccionInvestigador){ asociados.Add(enlace.obtener_destino()); } return asociados; } } public MediadorFirmanteInvestigador buscar_enlace(DecoradorInvestigadorAbstracta nobject) { foreach(MediadorFirmanteInvestigador enlace in ColeccionInvestigador) { if (enlace.obtener_destino().Equals(nobject)) return enlace; } return null; } public override String pfirma(){ return ObjetoDecorado.pfirma(); } public override int pposicion(){ return ObjetoDecorado.pposicion(); } } } //Clase DecoradorInvestigadoresUn using System; using System.Collections; using System.Text; namespace org.oomethod.publications {

260

public class DecoradorInvestigadoresUn:DecoradorInvestigadorAbstracta { ArrayList ColeccionFirmante; public DecoradorInvestigadoresUn(InvestigadorAbstracta decorado):base(decorado) { ColeccionFirmante = new ArrayList(); comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public DecoradorInvestigadoresUn(InvestigadorAbstracta decorado, ArrayList asociados):base(decorado) { ColeccionFirmante = new ArrayList(); foreach (FirmanteAbstracta asociado in asociados){ new MediadorFirmanteInvestigador((DecoradorFirmanteAbstracta)asociado, this, "FirmanteInvestigador"); } comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public DecoradorInvestigadoresUn(InvestigadorAbstracta decorado, params object [] atributos):base(decorado) { ColeccionFirmante = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); FirmanteAbstracta nuevoObjeto = new DecoradorFirmanteaparece( new DecoradorFirmantefirmaComo(new Firmante(atributos[0].ToString(), int.Parse(atributos[1].ToString())))); comprobar_mult_min("FirmanteInvestigador"); comprobar_reflexividad(); } public Mediador insertar(Decorador nobject, String asociacion){ return (new MediadorFirmanteInvestigador((DecoradorFirmanteAbstracta)nobject, this, asociacion)); } public void borrar(Decorador nobject, String asociacion){ MediadorFirmanteInvestigador enlace = buscar_enlace((DecoradorFirmanteAbstracta)nobject); if (enlace != null) enlace.Dispose(); } public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion) { MediadorFirmanteInvestigador enlace = buscar_enlace((DecoradorFirmanteAbstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); }

public override void comprobar_mult_max(String asociacion) {

261

//No es necesaria ninguna comprobacion }

public override void comprobar_mult_min(String asociacion) {

//No es necesaria ninguna comprobacion } public override void propagar_borrado_destruccion(){ ArrayList enlacesModificados = new ArrayList(); foreach(MediadorFirmanteInvestigador enlace in ColeccionFirmante){ enlacesModificados.Add(enlace); } foreach(MediadorFirmanteInvestigador enlace in enlacesModificados){ enlace.Dispose(); } } public override void propagar_borrado_desconexion(String asociacion){ //No es necesaria ninguna comprobacion } public override void comprobar_reflexividad(){ //No es necesaria ninguna comprobacion } public override void anyadir_enlace(Mediador enlace, String asociacion) { ColeccionFirmante.Add(enlace); } public override void eliminar_enlace(Mediador enlace, String asociacion) { ColeccionFirmante.Remove(enlace); } public override ArrayList obtener_coleccion(){ return ColeccionFirmante; } public override ArrayList obtener_asociado(){ ArrayList asociados = new ArrayList(); foreach (MediadorFirmanteInvestigador enlace in ColeccionFirmante){ asociados.Add(enlace.obtener_origen()); } return asociados; } public MediadorFirmanteInvestigador buscar_enlace(DecoradorFirmanteAbstracta nobject) { foreach(MediadorFirmanteInvestigador enlace in ColeccionFirmante) { if (enlace.obtener_origen().Equals(nobject)) return enlace; } return null;

262

} public override String pnombre(){ return ObjetoDecorado.pnombre(); } public override String pcategoria(){ return ObjetoDecorado.pcategoria(); } } }

263

Apéndice B Implementación de Transformaciones utilizando el Lenguaje MOFScript En este apéndice se definen las transformaciones que permiten convertir automáticamente modelos construidos utilizando el metamodelo presentado en el capítulo 4 (PIM), en código C# que extiende el framework de implementación presentado en el capítulo 5. Esta transformación de modelo a texto se implementa utilizando plugins de Eclipse para la gestión de modelos. Concretamente se han utilizado EMF y MOFScript. B.1. Contexto La implementación de la transformación que se presenta en este apéndice se ha realizado utilizando el entorno Eclipse. Eclipse es una plataforma flexible y extensible con numerosos plugins que añaden funcionalidad con propósitos específicos. Para implementar las transformaciones de este apéndice se ha utilizado EMF y MOFScript. EMF permite la implementación automática del metamodelo. EMF genera automáticamente las clases Java que implementan la funcionalidad necesaria para crear, borrar y modificar los elementos del metamodelo, y para la serialización de modelos. También se genera un editor en árbol básico. La figura B1 muestra una imagen de un modelo creado usando este editor.

264

B1. Editor generado por EMF para la especificación de relaciones de asociación

Para implementar la transformación modelo a texto se ha utilizado MOFScript, incluida en el proyecto eclipse Generative Model Transformer (GMT). El objetivo de este proyecto es “producir un conjunto de herramientas de investigación en el área del MDSD (Model Driven Software Development)”. En este contexto el proyecto MOFScript “trata de desarrollar herramientas y frameworks para dar soporte a las transformaciones de modelo a texto”. Este subproyecto está desarrollado por la comunidad de desarrollo SINTEF, soportado y validado por MODELWARE. La herramienta MOFScript es una implementación del lenguaje de transformación de modelo a texto MOFScript. Este lenguaje fue enviado a OMG como respuesta a la “MOF Model to Text Transformation Language RFP”. La figura B2 muestra los diferentes elementos introducidos en este apéndice y cómo se relacionan unos con otros.

265

Marco Conceptual

MOFScript

CorrespondenciasFramework de

Implementación

Modelo Conceptual Sistema

Software

Eclipse/EMF

Código C#

Transformación Modelo a Texto

Conocimiento

Herramientas

Piezas de Desarrollo

B2. Representación Gráfica de los distintos elementos utilizados

La transformación presentada en este apéndice se engloba dentro de las aproximaciones PIM a código. Este tipo de transformaciones posee diversas ventajas y desventajas frente a las transformaciones PIM – PSM - Código. Entre ellas destacamos:

• El generador se ha desarrollado con bastante rapidez, puesto que no ha sido necesario invertir tiempo en la construcción de un metamodelo C# completo, ni en el desarrollo de transformaciones de modelos C# a código.

• Las transformaciones modelo a código no son reusables, puesto que en la transformación existe semántica específica del metamodelo PIM. Sin embargo, en las transformaciones PIM-PSM-Código, la semántica se embebe en la transformación PIM-PSM. De esta forma, la transformación modelo a código es reusable (por ejemplo una transformación para generar código C# desde modelos representando un programa C#)

• Los elementos C# que son siempre generados (diversos atributos y operaciones) son directamente embebidos en las plantillas de texto. Usando una transformación PIM-PSM-Código, los elementos deben ser explícitamente creados en el PSM, lo cual supone un trabajo adicional a la aproximación utilizada en este apéndice.

• Nótese que en la aproximación PIM-PSM-Código, la transformación modelo a texto normalmente es una conversión sintáctica, mientras que la transformación modelo a modelo (PIM-PSM) mantiene toda la semántica. En nuestro caso la transformación modelo a código contiene el conocimiento embebido en las correspondencias.

266

B.2. Particularidades del Lenguaje MOFScript Se ha utilizado la herramienta/lenguaje MOFScript por las ventajas que ésta ofrecía respecto a otras herramientas/lenguajes (como FreeMarker o Velocity). Entre estas ventajas destacamos las siguientes:

• MOFScript es un lenguaje específicamente diseñado para la transformación de modelos a ficheros de texto, mientras que otros lenguajes son motores de plantillas de propósito general.

• MOFScript se estructura a través de transformaciones y reglas,

mientras que otros lenguajes no disponen de esta facilidad. • MOFScript trabaja directamente con descripciones del metamodelo

(ficheros Ecore) como entrada, mientras que otros lenguajes necesitan de las clases Java.

• Las transformaciones MOFScript pueden ejecutarse directamente desde

el entorno Eclipse. • MOFScript proporciona un constructor “file” para la creación de ficheros

de texto destino. MOFScript proporciona el constructor “texttransformation” como la principal primitiva del lenguaje para organizar el proceso de transformación. Una transformación toma como entrada un metamodelo y se compone de una o varias reglas. Cada regla se define sobre un elemento del metamodelo. Las reglas pueden tener argumentos y/o devolver un valor. Existe una regla especial, llamada “main”, que es el punto de entrada de la transformación. La transformación presentada en este apéndice se ha estructurado en diferentes módulos:

• Se define una transformación específica por cada tipo de clase (fichero):

o ParticipanteAbstracta (fichero ParticipantAbstract.m2t) o Participante (fichero Participant.m2t) o DecoradorAbstracta (fichero DecoratorAbstract.m2t) o DecoradorConcreto (fichero DecoratorConcrete.m2t) o MediadorConcreto (fichero MediatorConcrete.m2t y

MediatorConcreteReflexive.m2t) o MediadorAbstracta (fichero Mediator.m2t) o InterfazDecorador (fichero Decorator.m2t)

• La transformación raíz se encarga de navegar por el modelo e invocar a las transformaciones específicas.

267

B.3. Implementación de la Transformación A continuación mostramos la transformación raíz (definida en el fichero Aso2Csharp.m2t), la cual toma como entrada un modelo especificado usando nuestro metamodelo. La regla principal (main) itera (usando el constructor MOFScript “foreach”) sobre las clases participantes, las asociaciones y los extremos asociación. Los ficheros que se generan siguen las correspondencias definidas en el capítulo 5. Fichero Aso2Csharp.m2t import "ParticipantAbstract.m2t" import "Participant.m2t" import "DecoratorAbstract.m2t" import "DecoratorConcrete.m2t" import "MediatorConcrete.m2t" import "MediatorConcreteReflexive.m2t" import "Mediator.m2t" import "Decorator.m2t" texttransformation Aso2csharp (in asso:"http:///modeloasociacion.ecore" ) { asso.DiagramaDeClases::main(){ var tipoasociacion; self.ClaseParticipante->forEach(c:asso.ClaseParticipante) { file (c.nombre+"Abstracta.cs") c.generateParticipantAbstractClass() file (c.nombre+".cs") c.generateParticipantClass() file ("Decorador"+c.nombre+"Abstracta.cs") c.generateDecoratorAbstractClass() c.ExtremoAsociacion->forEach(end:asso.ExtremoAsociacion){ file ("Decorador" + c.nombre + end.nombre +".cs") end.generateDecoratorConcreteClass() } } self.Asociacion->forEach(a:asso.Asociacion){ file("Mediador"+ a.nombre +".cs" ) tipoasociacion = a.oclGetType() if (tipoasociacion=="AsociacionReflexiva"){ a.generateMediatorConcreteReflexiveClass() } else { a.generateMediatorConcreteClass() } } file("Mediador.cs") self.generateMediatorClass()

268

file("Decorador.cs"); self.generateDecoratorInterface() stdout.println ("") } } A continuación mostramos las demás transformaciones definidas en diferentes ficheros MOFScript. Fichero ParticipantAbstract.m2t /** * Clase Participante Abstracta * * */ texttransformation ParticipantAbstract (in asso:"http:///modeloasociacion.ecore") { asso.ClaseParticipante::generateParticipantAbstractClass(){ <%using System; namespace org.oomethod.publications { public abstract class %> self.nombre <%Abstracta { %> //Mapeo de los Atributos self.Atributo->forEach(a:asso.Atributo) { a.generateAttribute() } //Mapeo de la Proyeccion de Identificacion self.ExtremoAsociacion->forEach(end:asso.ExtremoAsociacion | end.proyeccionIdentificacion == true ) end.asociacion.conexion->forEach(conx:asso.ExtremoAsociacion | conx <> end) { conx.participante.Atributo->forEach(atrib:asso.Atributo | atrib.esIdentificador == true ) { atrib.generateAttribute() } } //Constructor <% public %> self.nombre <%Abstracta (){ } %> //Métodos Abstractos Set y Get self.generateAbstractGetSet()

269

//Destructor <% public abstract void Dispose(); } }%> } asso.Atributo::generateAttribute(){ println(" protected " + self.tipo + " " + self.nombre + ";") } asso.ClaseParticipante::generateAbstractGetSet(){ //Genera los métodos abstractos Get y Set self.Atributo->forEach(atrib:asso.Atributo){ <% public abstract %> atrib.tipo <% p%> atrib.nombre <%(); %> } } } Fichero Participant.m2t /** * Clase Participante * * */ texttransformation Participant (in asso:"http:///modeloasociacion.ecore") { asso.ClaseParticipante ::generateParticipantClass(){ //Variables Auxiliares var nAtrIdent = 0 var index = 0 <%using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class %> self.nombre <%:%> self.nombre <%Abstracta { %>

//Cabecera del Constructor <% public %> self.nombre <%(%>

270

self.ExtremoAsociacion ->forEach( end:asso.ExtremoAsociacion | end.proyeccionIdentificacion==true ) { end.asociacion.conexion->forEach(conx:asso.ExtremoAsociacion | conx <> end) { conx.participante.Atributo->forEach(atrib:asso.Atributo | atrib.esIdentificador == true ) { print(atrib.tipo + " " + atrib.nombre + ", ") } } } self.Atributo->forEach(atri:asso.Atributo | atri.esIdentificador==true) { nAtrIdent = nAtrIdent + 1 } self.Atributo->forEach(atri:asso.Atributo | atri.esIdentificador==true) { index = index + 1 print(atri.tipo + " " + atri.nombre) if (index != nAtrIdent) print(", ") } <%) { %>

//Cuerpo del constructor self.ExtremoAsociacion->forEach( end:asso.ExtremoAsociacion | end.proyeccionIdentificacion==true ) { end.asociacion.conexion->forEach(conx:asso.ExtremoAsociacion | conx <> end) { conx.participante.Atributo->forEach(atrib:asso.Atributo | atrib.esIdentificador==true ) { println(" " + "this." + atrib.nombre + " = " + atrib.nombre + ";") } } } self.Atributo->forEach(atri:asso.Atributo | atri.esIdentificador==true) { println(" " + "this." + atri.nombre + " = " + atri.nombre + ";") } <% } %> //Metodos Set y Get sobrescritos self.generateGetSet() //Destructor <% public override void Dispose(){ } } }%> }

271

asso.ClaseParticipante::generateGetSet(){ self.Atributo->forEach(atrib:asso.Atributo){ <% public override %> atrib.tipo <% p%> atrib.nombre <%(){ //get { return %> atrib.nombre <%; } //set { %> atrib.nombre <% = value; } return %> atrib.nombre <%; } %> }

} } Fichero DecoratorAbstract.m2t /** * Clase Decoradora Abstracta * * */ texttransformation DecoratorAbstract (in asso:"http:///modeloasociacion.ecore") { asso.ClaseParticipante::generateDecoratorAbstractClass(){ //Variables Auxiliares var tipoAsociacion var nomAsociacion var nomRolOrigen var nomRolDestino var indice = 0 tipoAsociacion = self.ExtremoAsociacion.first().asociacion.oclGetType() <%using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public abstract class Decorador%> self.nombre <%Abstracta:%>self.nombre<%Abstracta, Decorador, IDisposable { protected %> self.nombre <%Abstracta ObjetoDecorado; protected bool idestruccion = false; public Decorador%>self.nombre<%Abstracta(%>self.nombre<%Abstracta decorado) { ObjetoDecorado = decorado; } %> //Metodos conectar y desconectar enlace

272

if (tipoAsociacion == "AsociacionReflexiva") { self.ExtremoAsociacion->forEach(c:Asso.ExtremoAsociacion ){ if (indice==0) { nomRolOrigen = c.nombre nomAsociacion = c.asociacion.nombre } else { nomRolDestino = c.nombre } indice = indice + 1 } <% public void conectar_enlace (Mediador enlace) { Mediador%>nomAsociacion<% enlaceCc = (Mediador%>nomAsociacion<%) enlace; if (this.Equals(enlaceCc.obtener_origen())) { comprobar_mult_max("%>nomRolOrigen<%"); anyadir_enlace(enlace,"%>nomRolOrigen<%" ); } else { comprobar_mult_max("%>nomRolDestino<%"); anyadir_enlace(enlace,"%>nomRolDestino<%"); } } public void desconectar_enlace (Mediador enlace){ Mediador%>nomAsociacion<% enlaceCc = (Mediador%>nomAsociacion<%) enlace;

if (this.Equals(enlaceCc.obtener_origen())) { eliminar_enlace(enlace,"%>nomRolOrigen<%"); comprobar_mult_min("%>nomRolOrigen<%"); propagar_borrado_desconexion("%>nomRolOrigen<%"); } else { eliminar_enlace(enlace,"%>nomRolDestino<%"); comprobar_mult_min("%>nomRolDestino<%"); propagar_borrado_desconexion("%>nomRolDestino<%"); } } %> }//Fin AsociacionReflexiva else { <% public void conectar_enlace (Mediador enlace) { comprobar_mult_max(enlace.obtener_nombre()); anyadir_enlace(enlace, enlace.obtener_nombre()); } public void desconectar_enlace (Mediador enlace){ eliminar_enlace(enlace, enlace.obtener_nombre()); comprobar_mult_min(enlace.obtener_nombre()); propagar_borrado_desconexion(enlace.obtener_nombre()); } %>

}

273

//Metodo Destructor <% public override void Dispose(){ if (!idestruccion){ idestruccion = true; propagar_borrado_destruccion(); ObjetoDecorado.Dispose(); GC.SuppressFinalize(this); } } %> <% public %>self.nombre<%Abstracta obtener_objetoDecorado(){ return ObjetoDecorado; } public abstract void comprobar_mult_max(String asociacion); public abstract void comprobar_mult_min(String asociacion); public abstract void propagar_borrado_destruccion(); public abstract void propagar_borrado_desconexion(String asociacion); public abstract void comprobar_reflexividad(); public abstract void anyadir_enlace(Mediador enlace, String asociacion); public abstract void eliminar_enlace(Mediador enlace, String asociacion); public abstract ArrayList obtener_coleccion(%> if (self.ExtremoAsociacion.size()>1){ <%String asociacion%> } <%); %> <% public abstract ArrayList obtener_asociado(%> if (self.ExtremoAsociacion.size()>1){ <%String asociacion%> } <%); %> <% } }%> }//Fin GenerateDecoratorAbstractClass }

274

Fichero DecoratorConcrete.m2t /** * Clase Decoradora Concreta * * */ texttransformation DecoratorConcrete (in asso:"http:///modeloasociacion.ecore") { asso.ExtremoAsociacion::generateDecoratorConcreteClass(){ //Variables Auxiliares var counter =0 var isSource = 1 var insertMyClass = 0 var insertDecoratedClass = 0 var deleteMyClass = 0 var deleteDecoratedClass = 0 var modifyMyClass = 0 var modifyDecoratedClass = 0 var tipoAsociacion var rolOrigen var rolDestino var nomRol var nomRolOpuesto var nomClaseDestino var nomOtroExtremoClase var numAtributosClaseOpuesta = 0 tipoAsociacion = self.asociacion.oclGetType() nomRol = self.asociacion.nombre nomRolOpuesto = self.asociacion.nombre self.asociacion.conexion->forEach(con:Asso.ExtremoAsociacion){ if (counter==0) { rolOrigen = con.nombre if (con==self) { isSource = 0 } else { nomClaseDestino = con.participante.nombre } } else { rolDestino = con.nombre if (con<>self) { nomClaseDestino = con.participante.nombre } } counter = counter + 1 } self.participante.ExtremoAsociacion->forEach (ext:Asso.ExtremoAsociacion | ext <> self){ nomOtroExtremoClase = ext.nombre

275

ext.participante.Atributo->forEach(atr:Asso.Atributo| atr.esIdentificador==true ){ numAtributosClaseOpuesta = numAtributosClaseOpuesta+1 } } if (tipoAsociacion=="AsociacionReflexiva") { if (isSource==0) { nomRol = rolOrigen nomRolOpuesto = rolDestino } else { nomRol = rolDestino nomRolOpuesto = rolOrigen } } <%using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Decorador%> self.participante.nombre + self.nombre <%:Decorador%>self.participante.nombre<%Abstracta { %> //Definicion de la colección asociada self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% ArrayList Coleccion%> con.participante.nombre <%; %> } //Constructor Simple <% public Decorador%>self.participante.nombre + self.nombre<%(%>self.participante.nombre<%Abstracta decorado):base(decorado) { %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <% = new ArrayList(); comprobar_mult_min("%>nomRol<%"); comprobar_reflexividad(); } %> } //Constructor con Objetos Asociados <% public Decorador%>self.participante.nombre + self.nombre<%(%>self.participante.nombre<%Abstracta decorado, ArrayList asociados):base(decorado) { %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) {

276

<% Coleccion%> con.participante.nombre <% = new ArrayList(); foreach (%>con.participante.nombre<%Abstracta asociado in asociados){ new Mediador%>self.asociacion.nombre<%(%> if (isSource<>0) { <%(Decorador%>con.participante.nombre<%Abstracta)asociado, this, %> } else { <% this, (Decorador%>con.participante.nombre<%Abstracta)asociado,%> } <%"%>self.asociacion.nombre<%"); } comprobar_mult_min("%>nomRol<%"); comprobar_reflexividad(); } %> } counter = 0 //Constructor con Atributos de un Objeto Asociado <% public Decorador%>self.participante.nombre + self.nombre<%(%>self.participante.nombre<%Abstracta decorado, params object [] atributos):base(decorado) { %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <% = new ArrayList(); ArrayList asociados = new ArrayList(); asociados.Add(this); %> con.participante.nombre<%Abstracta nuevoObjeto = %> con.participante.ExtremoAsociacion->forEach(extremo:Asso.ExtremoAsociacion){ <% new Decorador%>con.participante.nombre+extremo.nombre<%(%> } <%new %>con.participante.nombre <%(%> con.participante.ExtremoAsociacion->forEach(extremo:Asso.ExtremoAsociacion){ if (extremo.proyeccionIdentificacion==true){ extremo.asociacion.conexion->forEach(otroextremo:Asso.ExtremoAsociacion|otroextremo<>extremo) { otroextremo.participante.Atributo->forEach(atr:Asso.Atributo|atr.esIdentificador==true){ if (atr.tipo=="String"){ <%atributos[%>counter<%].ToString(), %> } else { <%int.Parse(atributos[%>counter<%].ToString()), %> } counter = counter + 1 } } }

277

}

con.participante.Atributo->forEach(atr:Asso.Atributo|atr.esIdentificador==true){

if (atr.tipo=="String"){ <%atributos[%>counter<%].ToString()%> } else { <%int.Parse(atributos[%>counter<%].ToString())%> } counter = counter + 1 if (counter<numAtributosClaseOpuesta){ <%, %> } } <%)%> con.participante.ExtremoAsociacion->forEach(c){ if (c==self) { <%, asociados%> } <%)%> } <%; comprobar_mult_min("%>nomRol<%"); comprobar_reflexividad(); } %>

}

//Metodos de inserción, borrado y modificacion

//Fijamos el valor para las variables auxiliares insertMyClass, deleteMyClass, insertDecoratedClass y deleteDecoratedClass

self.asociacion.conexion->forEach( c:Asso.ExtremoAsociacion | c<>self){ if (c.dinamicidad=="Dinamica" or c.dinamicidad=="Incrementable"){ insertMyClass = 1; } if (c.dinamicidad=="Dinamica" or c.dinamicidad=="Decrementable"){ deleteMyClass = 1; } }

self.participante.ExtremoAsociacion->forEach(e1:Asso.ExtremoAsociacion |e1<>self ){ e1.asociacion.conexion->forEach(e2:Asso.ExtremoAsociacion|e2<>e1){ if ( e2.dinamicidad=="Dinamica" or e2.dinamicidad=="Incrementable"){ insertDecoratedClass = 1; } if ( e2.dinamicidad=="Dinamica" or e2.dinamicidad=="Decrementable"){ deleteDecoratedClass = 1;

278

} } } //Fijamos el valor para las variables auxiliares modifyMyClass, modifyDecoratedClass self.asociacion.conexion->forEach( c:Asso.ExtremoAsociacion | c<>self){ if (c.mutabilidad==true){ modifyMyClass = 1; } } self.participante.ExtremoAsociacion->forEach(e1:Asso.ExtremoAsociacion|e1<>self ){ e1.asociacion.conexion->forEach(e2:Asso.ExtremoAsociacion|e2<>e1){ if ( e2.mutabilidad==true){ modifyDecoratedClass = 1; } } } //Clase con mas de un extremo if (self.participante.ExtremoAsociacion.size()>1 ) { //Definicion de los metodos de insercion en funcion del valor de las variables auxiliares //Insertar self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con<>self ){ if ( insertMyClass == 1 or insertDecoratedClass == 1){ <% public Mediador insertar(Decorador nobject, String asociacion) { if (!asociacion.Equals("%> self.participante.ExtremoAsociacion->forEach(end:asso.ExtremoAsociacion | end<>self) { print(nomRol) <%")){%> if (insertDecoratedClass == 1){ <% Decorador%> self.participante.nombre + nomOtroExtremoClase<% dec = (Decorador%>self.participante.nombre + nomOtroExtremoClase<%) ObjetoDecorado; return dec.insertar(nobject, asociacion); %> } else { <% return null; %> } <% } %> } if (insertMyClass==1) { <%

279

else return (new Mediador%> self.asociacion.nombre <%(%> if (isSource==0){ <%this, (Decorador%> con.participante.nombre <%Abstracta) nobject, "%>nomRol<%"%> } else { <%(Decorador%>con.participante.nombre <%Abstracta)nobject, this, "%>nomRol<%"%> } <%)); %> } else { <% else return null; %> } <% } %> } } //Borrar self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con<>self) { if (deleteMyClass == 1 or deleteDecoratedClass == 1){ <% public void borrar(Decorador nobject, String asociacion) {%> <% if (!asociacion.Equals("%> self.participante.ExtremoAsociacion->forEach(end:asso.ExtremoAsociacion | end<>self) { print(nomRol) <%")){ %> if (deleteDecoratedClass == 1){ <% Decorador%> self.participante.nombre + nomOtroExtremoClase <% dec = (Decorador%>self.participante.nombre + nomOtroExtremoClase <%) ObjetoDecorado; dec.borrar(nobject, asociacion); }%> } else { <% //No es necesaria ninguna accion }%> } } <% else {%> if (deleteMyClass == 1) { <% Mediador%> self.asociacion.nombre <% enlace = buscar_enlace((Decorador%> con.participante.nombre <%Abstracta)nobject); if (enlace != null) enlace.Dispose();

280

%> } else { <% //No es necesaria ninguna accion %> } <% }%> <% } %> } } //Modificar <% public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion) { %> if (modifyDecoratedClass == 1) { <% if (!asociacion.Equals("%> self.asociacion.nombre <%")) { Decorador%>self.participante.nombre + nomOtroExtremoClase <% dec = (Decorador%>self.participante.nombre + nomOtroExtremoClase<%)ObjetoDecorado; dec.modificar(objAntiguo, objNuevo, asociacion); } %> } if (modifyMyClass==1) { if (modifyDecoratedClass==1) { <% else { %> } <% Mediador%>self.asociacion.nombre<% enlace = buscar_enlace((Decorador%>nomClaseDestino<%Abstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); %> if (modifyDecoratedClass==1) { <% } %> } } <% } %> } else { //Clase con solo un extremo //Insertar <% public Mediador insertar(Decorador nobject, String asociacion){ return (new Mediador%>self.asociacion.nombre<%((Decorador%>nomClaseDestino <%Abstracta)nobject, this, asociacion)); }

281

%> //Borrar <% public void borrar(Decorador nobject, String asociacion){ Mediador%>self.asociacion.nombre <% enlace = buscar_enlace((Decorador%> nomClaseDestino <%Abstracta)nobject); if (enlace != null) enlace.Dispose(); } %> //Modificar <% public void modificar(Decorador objAntiguo, Decorador objNuevo, String asociacion) { Mediador%>self.asociacion.nombre<% enlace = buscar_enlace((Decorador%>nomClaseDestino<%Abstracta)objAntiguo); if (enlace != null) enlace.actualizar(objAntiguo, objNuevo); } %> }//Fin del else //Metodos de Comprobacion de Propiedades //Clase con solo un extremo if (self.participante.ExtremoAsociacion.size()==1) { <% public override void comprobar_mult_max(String asociacion)

{ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { if (con.multiplicidadMax <> -1) { <% if (Coleccion%> print(con.participante.nombre) <%.Count ==%> con.multiplicidadMax <%){ throw new Exception("Max Multiplicity Violation"); } %> } else { <% //No es necesaria ninguna comprobacion %> } } <% } %> <% public override void comprobar_mult_min(String asociacion)

{ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) {

282

if (con.multiplicidadMin >0) { <% if ( !idestruccion && Coleccion%> print(con.participante.nombre) <%.Count ==%> (con.multiplicidadMin - 1)<%){ throw new Exception("Min Multiplicity Violation"); } %> } else { <% //No es necesaria ninguna comprobacion %> } } <% } %> <% public override void propagar_borrado_destruccion(){ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con<>self){ //Cascada if (con.propagacionBorrado="Cascada"){ <% ArrayList enlacesModificados = new ArrayList(); %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in Coleccion%> con.participante.nombre<%){ enlacesModificados.Add(enlace); } %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in enlacesModificados){ enlace.obtener_%> if (isSource==0) {<%destino%>} else {<%origen%>} <%().Dispose(); } %> } //Enlace else if (con.propagacionBorrado="Enlace"){ <% ArrayList enlacesModificados = new ArrayList(); %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in Coleccion%>con.participante.nombre<%){ enlacesModificados.Add(enlace); } %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in enlacesModificados){ enlace.Dispose(); } %> }

283

//Restrictivo else { <% if (Coleccion%>con.participante.nombre<%.Count<>0) throw new Exception("Exiting Link cannot be destroyed"); %> } } <% } public override void propagar_borrado_desconexion(String asociacion){ %> self.asociacion.conexion->forEach(con:Asso.ExtremoAsociacion | con !=self){ if ( con.dinamicidad == "Dinamica" or con.dinamicidad =="Decrementable" or self.dinamicidad =="Estatica" or self.dinamicidad =="Incrementable"){ <% //No es necesaria ninguna comprobacion%> } else { if (self.propagacionBorrado== "Restrictivo") { <% throw new Exception("Disconnection Not Allowed");%> } else { if (self.propagacionBorrado == "Cascada"){ <% this.Dispose(); %> } } } } <% } %> } else { //Clase con mas de un extremo <% public override void comprobar_mult_max(String asociacion)

{ %> <% if (asociacion.Equals("%>nomRol<%")){%> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { if (con.multiplicidadMax <> -1) { <% if (Coleccion%> print(con.participante.nombre) <%.Count ==%> con.multiplicidadMax <%){ throw new Exception("Max Multiplicity Violation"); } %> }

284

else { <% //No es necesaria ninguna comprobacion %> } <% } else { Decorador%>self.participante.nombre + nomOtroExtremoClase <% dec = (Decorador%>self.participante.nombre+nomOtroExtremoClase<%)ObjetoDecorado; dec.comprobar_mult_max(asociacion); } %> } <% } %> <% public override void comprobar_mult_min(String asociacion)

{ if (asociacion.Equals("%>nomRol<%")){ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { if (con.multiplicidadMin >0) { <% if ( !idestruccion && Coleccion%> print(con.participante.nombre) <%.Count ==%> (con.multiplicidadMin - 1)<%){ throw new Exception("Min Multiplicity Violation"); } %> } else { <% //No es necesaria ninguna comprobacion %> } <% } else { Decorador%>self.participante.nombre + nomOtroExtremoClase <% dec = (Decorador%>self.participante.nombre+nomOtroExtremoClase<%)ObjetoDecorado; dec.comprobar_mult_min(asociacion); } %> } <% } %> <% public override void propagar_borrado_destruccion(){ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con<>self){ //Cascada

285

if (con.propagacionBorrado="Cascada"){ <% ArrayList enlacesModificados = new ArrayList(); %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in Coleccion%> con.participante.nombre<%){ enlacesModificados.Add(enlace); } %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in enlacesModificados){ enlace.obtener_%> if (isSource==0) {<%destino%>} else {<%origen%>} <%().Dispose(); } %> } //Enlace else if (con.propagacionBorrado="Enlace"){ <% ArrayList enlacesModificados = new ArrayList(); %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in Coleccion%>con.participante.nombre<%){ enlacesModificados.Add(enlace); } %> <% foreach(Mediador%> self.asociacion.nombre<% enlace in enlacesModificados){ enlace.Dispose(); } %> } //Restrictivo else { <% if (Coleccion%>con.participante.nombre<%.Count<>0) throw new Exception("Exiting Link cannot be destroyed"); %> } } <% } public override void propagar_borrado_desconexion(String asociacion){ if (asociacion.Equals("%>nomRol<%")){ %> self.asociacion.conexion->forEach(con:Asso.ExtremoAsociacion | con !=self){ if ( con.dinamicidad == "Dinamica" or con.dinamicidad =="Decrementable" or self.dinamicidad =="Estatica" or self.dinamicidad =="Incrementable"){ <% //No es necesaria ninguna comprobacion%> } else { if (self.propagacionBorrado== "Restrictivo") {

286

<% throw new Exception("Disconnection Not Allowed");%> } else { if (self.propagacionBorrado == "Cascada"){ <% this.Dispose(); %> } } } <% } else { Decorador%>self.participante.nombre+nomOtroExtremoClase<% dec = (Decorador%>self.participante.nombre+nomOtroExtremoClase<%) ObjetoDecorado; dec.propagar_borrado_desconexion(asociacion); } %> } <% } %> } <% public override void comprobar_reflexividad(){ %> if (tipoAsociacion=="AsociacionReflexiva" && self.asociacion.reflexividad=="Reflexiva") { <% new Mediador%> self.asociacion.nombre <%(this, this); %> } else { <% //No es necesaria ninguna comprobacion %> } <% } %> //Metodos anyadir y eliminar enlace //Clase con mas de un extremo if (self.participante.ExtremoAsociacion.size()>1) { <% public override void anyadir_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("%>nomRol<%")) {%> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <%.Add(enlace); } else { Decorador%>self.participante.nombre+nomOtroExtremoClase<% dec =

287

(Decorador%>self.participante.nombre+nomOtroExtremoClase<%)ObjetoDecorado; dec.anyadir_enlace(enlace, asociacion); } %> } <% } %> <% public override void eliminar_enlace(Mediador enlace, String asociacion) { if (asociacion.Equals("%>nomRol<%")) {%> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <%.Remove(enlace); } else { Decorador%>self.participante.nombre+nomOtroExtremoClase<% dec = (Decorador%>self.participante.nombre+nomOtroExtremoClase<%)ObjetoDecorado; dec.eliminar_enlace(enlace, asociacion); } %> } <% } %> } else { //Clase con solo un extremo <% public override void anyadir_enlace(Mediador enlace, String asociacion) {%> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <%.Add(enlace); } %> } <% public override void eliminar_enlace(Mediador enlace, String asociacion) {%> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% Coleccion%> con.participante.nombre <%.Remove(enlace); %> }

288

<% } %>

} //Metodo obtener_coleccion //Clase con solo un extremo if (self.participante.ExtremoAsociacion.size()==1){ <% public override ArrayList obtener_coleccion(){ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% return Coleccion%> con.participante.nombre <%; }%> } } else{ //Clase con mas de un extremo <% public override ArrayList obtener_coleccion(String asociacion){ if (!asociacion.Equals("%> self.participante.ExtremoAsociacion->forEach(c: Asso.ExtremoAsociacion | c <> self ){ print(nomRol) <%")){ Decorador%> self.participante.nombre + c.nombre <% dec = (Decorador%> self.participante.nombre + c.nombre <%) ObjetoDecorado; return dec.obtener_coleccion(asociacion); } %> } <% else { %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% return Coleccion%> con.participante.nombre <%; } } %> } } //Metodo obtener_asociados //Clase con solo un extremo if (self.participante.ExtremoAsociacion.size()==1){ <% public override ArrayList obtener_asociado(){ %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% ArrayList asociados = new ArrayList(); foreach (Mediador%>self.asociacion.nombre <% enlace in Coleccion%>con.participante.nombre<%){

289

asociados.Add(enlace.obtener_%> if (isSource==0) {<%destino%>} else {<%origen%>} <%()); } return asociados; }%> } } else{ //Clase con mas de un extremo <% public override ArrayList obtener_asociado(String asociacion){ if (!asociacion.Equals("%> self.participante.ExtremoAsociacion->forEach(c: Asso.ExtremoAsociacion | c <> self ){ print(nomRol) <%")){ Decorador%> self.participante.nombre + c.nombre <% dec = (Decorador%> self.participante.nombre + c.nombre <%) ObjetoDecorado; return dec.obtener_asociado(asociacion); } %> } <% else { %> self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% ArrayList asociados = new ArrayList(); foreach (Mediador%>self.asociacion.nombre <% enlace in Coleccion%>con.participante.nombre<%){ asociados.Add(enlace.obtener_%> if (isSource==0) {<%destino%>} else {<%origen%>} <%()); } return asociados; } }%> } } //Metodos Auxiliares self.asociacion.conexion->forEach(con:asso.ExtremoAsociacion | con <> self ) { <% public Mediador%> self.asociacion.nombre <% buscar_enlace(Decorador%> print(con.participante.nombre) <%Abstracta nobject) { foreach(Mediador%> self.asociacion.nombre <% enlace in Coleccion%> print(con.participante.nombre) <%) {

290

%> <% if (enlace.obtener_%> if (isSource==0) {<%destino%>} else {<%origen%>} <%().Equals(nobject)) return enlace; } return null; }%> }

//Sobreescritura de métodos Get y Set a través de self.participante.Atributo->forEach(atrib:asso.Atributo){ <% public override %> atrib.tipo <% p%> atrib.nombre <%(){ return ObjetoDecorado.p%> print(atrib.nombre) <%(); }%> } <% } }%> }//generateDecoratorConcreteClass } Fichero MediatorConcrete.m2t /** * Clase Mediadora Concreta * * */ texttransformation MediatorConcrete (in asso:"http:///modeloasociacion.ecore") { asso.Asociacion::generateMediatorConcreteClass(){ //Variables Auxiliares var counter = 0; var nombreClaseOrigen; <%using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Mediador%> self.nombre <%:Mediador,IDisposable { %> //Constructor

291

<% public Mediador%> self.nombre <%(%> self.conexion->forEach(end:asso.ExtremoAsociacion){ counter = counter + 1 <%Decorador%> print(end.participante.nombre)<%Abstracta%> if (counter=1) { <% origen, %>} else {<% destino, String nombre):base(origen, destino, nombre)%>} } counter = 0 <% { } %> //Metodos de Comprobacion <% public override void comprobar_reflexividad(Decorador origen, Decorador destino){ } public override void comprobar_simetria(Decorador origen, Decorador destino){ } public override void comprobar_transitividad(Decorador origen, Decorador destino){ } public override void comprobar_unicidad(Decorador origen, Decorador destino){ if (encontrar_identico(origen, destino)!=null) throw new Exception("Violacion Unicidad"); } public override void comprobar_reflexividad(){ } public override void comprobar_simetria(){ } %> self.conexion->forEach(end:asso.ExtremoAsociacion){ counter = counter + 1

if (end.navegabilidad==true) {<% public%> }

else {<% private%> } <% Decorador%>

print(end.participante.nombre)<%Abstracta%> if (counter==1) { <% obtener_origen(){

return (Decorador%>end.participante.nombre<%Abstracta) origen; } %>

} else {<% obtener_destino(){ return (Decorador%>end.participante.nombre<%Abstracta) destino;

292

} %>

} }

nombreClaseOrigen = self.conexion.first().participante.nombre <% public Mediador%>self.nombre <% encontrar_identico(Decorador origen, Decorador destino){ Decorador%>nombreClaseOrigen<%Abstracta dorigen = (Decorador%>nombreClaseOrigen<%Abstracta)origen; foreach(Mediador%>self.nombre<% enlace in dorigen.obtener_coleccion("%>self.nombre<%")){ if (destino.Equals(enlace.obtener_destino())) return enlace; } return null; } } } %> } } Fichero MediatorConcreteReflexive.m2t /** * Clase Mediadora Concreta Reflexiva * * */ texttransformation MediatorConcreteReflexive (in asso:"http:///modeloasociacion.ecore") { asso.AsociacionReflexiva::generateMediatorConcreteReflexiveClass(){ //Variables Auxiliares var counter = 0; var nomParticipante; var nomRolOrigen; <%using System; using System.Collections; using System.Text; namespace org.oomethod.publications { public class Mediador%> self.nombre <%:Mediador,IDisposable { %> //Constructor <% public Mediador%> self.nombre <%(%>

293

self.conexion->forEach(end:asso.ExtremoAsociacion){ counter = counter + 1 <%Decorador%> print(end.participante.nombre)<%Abstracta%> if (counter=1) { nomRolOrigen = end.nombre <% origen, %> } else { <% destino, String nombre):base(origen, destino, nombre)%> } } counter = 0 <% { } %> //Metodos de comprobacion <% public override void comprobar_reflexividad(Decorador origen, Decorador destino){ %> if (self.reflexividad=="Irreflexiva"){ <% if (origen.Equals(destino)) throw new Exception("Violacion de la Reflexividad"); %> }else { <% //No es necesaria ninguna comprobacion %> } <% }%> <% public override void comprobar_simetria(Decorador origen, Decorador destino){ %> self.conexion->forEach(c: Asso.ExtremoAsociacion){ nomParticipante = c.participante.nombre; } if (self.simetria =="Simetrica"){ <% new Mediador%>self.nombre<%((Decorador%> nomParticipante <%Abstracta)destino, (Decorador%>nomParticipante<%Abstracta)origen); %> } else if (self.simetria=="Antisimetrica"){ <% if (encontrar_simetrico()!=null) { throw new Exception("Violacion de la Simetria"); } %> }else { <% //No es necesaria ninguna comprobacion

294

%> } <% }%> <% public override void comprobar_transitividad(Decorador origen, Decorador destino) { %> if (self.transitividad== true){ <% Decorador%>nomParticipante<%Abstracta dorigen = (Decorador%>nomParticipante<%Abstracta) origen; foreach(Mediador%> self.nombre <% enlace in dorigen.obtener_coleccion("%>nomRolOrigen<%")){ Decorador%> nomParticipante <%Abstracta nuevoOrigen = enlace.obtener_origen(); if (encontrar_identico(nuevoOrigen, destino)==null) new Mediador%>self.nombre<%(nuevoOrigen, (Decorador) destino, "%>nomRolOrigen<%"); } %> <% Decorador%>nomParticipante<%Abstracta ddestino = (Decorador%>nomParticipante<%Abstracta) destino; foreach(Mediador%>self.nombre<% enlace in ddestino.obtener_coleccion("%>nomRolOrigen<%")){ Decorador%> self.conexion.first().participante.nombre <%Abstracta nuevoDestino = enlace.obtener_destino(); if (encontrar_identico(origen, nuevoDestino)==null) new Mediador%>self.nombre<%((Decorador)origen, nuevoDestino, "%>nomRolOrigen<%"); } %> } else if (self.transitividad==false){ <% //No es necesaria ninguna comprobacion %> } <%}%> <% public override void comprobar_reflexividad(){ %> if (self.reflexividad=="Reflexiva"){ <% if (origen.Equals(destino)) throw new Exception("Violacion de la Reflexividad");%> }else {

295

<% //No es necesaria ninguna comprobacion %> } <% }%> <% public override void comprobar_simetria(){ %> if (self.simetria =="Simetrica"){ <% Mediador enlaceSimetrico = encontrar_simetrico(); if (enlaceSimetrico!=null) enlaceSimetrico.Dispose(); %> }else { <% //No es necesaria ninguna comprobacion %> } <% }%> self.conexion->forEach(end:asso.ExtremoAsociacion){ counter = counter + 1 if (end.navegabilidad==true) {<% public%> } else { <% private%> } <% Decorador%> print(end.participante.nombre)<%Abstracta%> if (counter==1) { <% obtener_origen(){ return (Decorador%>end.participante.nombre<%Abstracta) origen; } %>} else {<% obtener_destino(){ return (Decorador%>end.participante.nombre<%Abstracta) destino; } %>} } <% public Mediador%>self.nombre <% encontrar_simetrico(){ ArrayList asociados = this.obtener_destino().obtener_coleccion("%>nomRolOrigen<%"); foreach(Mediador%>self.nombre<% enlace in asociados){ if (enlace.obtener_destino().Equals(this.obtener_origen())) return enlace; } return null; } %> <% } }

296

%> } } } Fichero Mediator.m2t /** * Clase Mediadora * * */ texttransformation Mediator (in asso:"http:///modeloasociacion.ecore") { asso.DiagramaDeClases::generateMediatorClass(){ <%using System; namespace org.oomethod.publications { public abstract class Mediador { protected String nombreAsociacion; protected Decorador origen; protected Decorador destino; public Mediador(Decorador origen, Decorador destino, String nombre){ nombreAsociacion = nombre; comprobar_reflexividad(origen, destino); comprobar_transitividad(origen, destino); comprobar_unicidad(origen, destino); this.origen = origen; this.destino = destino; origen.conectar_enlace(this); destino.conectar_enlace(this); comprobar_simetria(origen, destino); } public void actualizar(Decorador objAntiguo, Decorador objNuevo) { //Comprobamos que se pueda eliminar el enlace comprobar_reflexividad(); //Actualizamos las referencias if (objAntiguo.Equals(origen)) origen = objNuevo; else destino = objNuevo; //Desconectamos el objeto a sustituir objAntiguo.desconectar_enlace(this); comprobar_simetria(); //Comprobamos que se puede crear el enlace comprobar_reflexividad(origen, destino); comprobar_transitividad(origen, destino); comprobar_unicidad(origen, destino); //Conectamos el objeto sustituyente objNuevo.conectar_enlace(this);

297

comprobar_simetria(origen, destino); } public String obtener_nombre() { return nombreAsociacion; } public void Dispose() { comprobar_reflexividad(); origen.desconectar_enlace(this); destino.desconectar_enlace(this); comprobar_simetria(); GC.SuppressFinalize(this); } public abstract void comprobar_reflexividad(Decorador origen, Decorador destino); public abstract void comprobar_simetria(Decorador origen, Decorador destino); public abstract void comprobar_transitividad(Decorador origen, Decorador destino); public abstract void comprobar_unicidad(Decorador origen, Decorador destino); public abstract void comprobar_reflexividad(); public abstract void comprobar_simetria(); } } %> } }

Fichero Decorator.m2t /** * Interfaz Decorador * * */ texttransformation Decorator (in asso:"http:///modeloasociacion.ecore") { asso.DiagramaDeClases::generateDecoratorInterface(){ <% using System; namespace org.oomethod.publications { public interface Decorador { void comprobar_mult_max(String asociacion); void comprobar_mult_min(String asociacion); void propagar_borrado_destruccion();

298

void propagar_borrado_desconexion(String asociacion); void comprobar_reflexividad(); void anyadir_enlace(Mediador enlace, String asociacion); void eliminar_enlace(Mediador enlace, String asociacion);

void conectar_enlace(Mediador enlace); void desconectar_enlace(Mediador enlace); } } %> } }

299

Referencias [AGO91] A. Albano, G Ghelli, and R. Orsini. A relationship mechanism for a

strongly typed object oriented database programming language. En <<Proceedings of the 17th International Conference on Very Large Data Bases, VLDB’91>>. G.M. Lohman, A. Sernadas, and R. Camps, editors, Pags. 565–575. 1991.

[BOI98] Conrad Bock, James Odell. A More Complete Model of Ralations

and Their Implementation. Part I: Relations as Object Types. Journal of Object Oriented Programming, Vol. 10, No. 3, 1997, pags. 68-70, 85

[BOL04] N.Bolloju. Improving the Quality of Business Object Models Using

Collaboration Patterns. COMMUNICATIONS OF THE ACM, Vol. 47, No. 7, pags. 81-86, July 2004,

[BSC96] J. Bosch. Relations as object model components. Journal of

Programming Languages, Vol. 4 No.1. Pags. 39–61. 1996. [CVL93] Franco Civello. Roles for composite objects in object-oriented

analysis and design. En <<Proceedings of OOPSLA 1993>>. Pags. 376-393.

[CLS03] Krzysztof Czarnecki and Simon Helsen. Classification of Model

Transformation Approaches. En <<2nd OOPSLA Workshop on Generative Techniques in the context of Model Driven Architecture>> 2003.

[CAT98] D.F. D’Souza and A.C. Wills. Catalysis- Objects, Components and

Frameworks with UML. Addison-Wesley, Reading, MA, 1998. [DP94] O. Díaz and N.W. Paton. Extending ODBMSs using metaclasses.

IEEE Software, Vol. 11, No. 3, pags 40–47, May 1994. [DHC01] Mohamed Dahchour. Ph D. Thesis. Integrating Generic

Relationships into Object Models Using Metaclasses. Département d’Ingénierie Informatique. Université Catholique de Louvain. 2001.

[DPW93] M. Doherty, J. Peckham, and V.F. Wolfe. Implementing

relationships and constraints in an object-oriented database using a monitor construct. En <<Proceedings of the International Workshop on Rules in Database Systems, RIDS’93>> LNCS 1312, pags. 347–363, Edinburgh, Scotland, 1993. Springer-Verlag.

[DIA99] Brian Henderson-Sellers, Frank Barbier. Black and White

Diamonds. En <<Proceedings of <<UML>>’99, Beyond the Standard>> Fort Collins, USA, LNCS 1723, Springer, pags. 550-565, October 28-30, 1999

300

[EEKR99] H. Ehrig, G. Engels, H.-J. Kreowski, and G. Rozenberg, editors. Handbook on Graph Grammars and Computing by Graph Transformation, volume 2 Applications, Languages and Tools. World Scientific Publishing Co., Inc., 1999.

[EMF] Eclipse Modeling Framework. http://www.eclipse.org/emf [ER97] B.K. Ehlmann and G.A. Riccardi. An integrated and enhanced

methodology for modeling and implementing object relationships. Journal of Object-Oriented Programming, Vol. 10, No. 2, pags. 47–55, May 1997.

[FWL97] M. Fowler. Analysis Patterns: Reusable Object Models. Addison-

Wesley, 1997. [FHS98] D.G. Firesmith and B. Henderson-Sellers. Clarifying specialized

forms of association in UML and OML. Journal of Object Oriented Programming. Vol. 11, No. 2, pags. 47-50, May 1998.

[GBHS97] I. Graham, J. Bischof, and B. Henderson-Sellers. Associations

considered a bad thing. Journal of Object-Oriented Programming, Vol. 9, No. 9, pags. 41–48, Feb 1997.

[Gam94] E. Gamma, R. Helm, R. Jonson, and J. Vlissides. Design Patterns:

Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1994, editor: Professional Computing Series

[GNV03] Gonzalo Génova Fuster. Ph D. Thesis. Entrelazamiento de los

aspectos estático y dinámico en las asociaciones UML. Departamento de Informática. Universidad Carlos III de Madrid. 2003.

[iUML00] K. Carter. Executable Modelling with the UML. The xUML method

and iUML, the xUML toolset. Technical Report ref: CTN 80 v1.1, Kennedy Carter Ltd., http://www.kc.com/, 2000.

[KP97] M. Kolp and A. Pirotte. An aggregation model and its C++

implementation. En <<Proceedings of the 4th International Conference on Object-Oriented Information Systems, OOIS’97>> pags. 211–224, Brisbane, Australia, November 1997.

[LSS94] Odd Ivar Lindland, Guttorm Sindre, Arne Solvberg. Understanding

Quality in Conceptual Modeling. IEEE Software, Vol. 11, No. 2, pags. 42-49, March 1994

[MDA03] Object Management Group. Model Driven Architecture Guide, 2003 [MFS] http://www.eclipse.org/gmt/mofscript [MMF03] Colin Atkinson and Thomas Kühne. Model-Driven Development: A

Metamodeling Foundation. IEEE Software, Vol. 20, pags. 36-41, September-October 2003.

301

[MMP02] Pedro J. Molina Moreno. Ph D. Thesis. Especificación de Interfaces

de Usuario: de los requisitos a la generación automática. Departamento de Sistemas Informáticos y Comunicación. Universidad Politécnica de Valencia. 2002.

[MRAP04] Javier Muñoz, Marta Ruiz, Manoli Albert, Vicente Pelechano. MDA

Aplicado: Una Gramática de Grafos para la Transformación de Relaciones de Asociación. En <<Proceedings of the IX Jornadas de Ingeniería del Software y Bases de Datos 2004, JISBD’04>> pags. 539-546. ISBN: 84-688-8983-0.

[MOOD] Daniel L. Moody. Metrics for Evaluating the Quality of Entity

Relationships Models. En <<Proceedings of the 17th International Conference on Conceptual Modeling>>, Singapore, pags, 211-225. November 16-19, 1998.

[MS03] Daniel L. Moody and Graeme G. Shanks. Improving the Quality of

Data Models: Empirical Validation of a Quality Management Framework. Information Systems. Vol. 28 , No. 6, pags. 619 – 650, September 2003. ISSN:0306-4379

[OOM01] O. Pastor, J. Gómez, E. Insfrán, and V. Pelechano. The OO-Method

Approach for Information Systems Modelling: From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems, Vol. 26, No. 7, pags. 507–534. 2001.

[OOM96] O. Pastor, V. Pelechano, B. Bonet, and I. Ramos. An Object

Oriented Methodological Approach for Making Automated Prototyping Feasible. En <<Proceedings of the Database and Expert Systems Applications (DEXA’96)>>, pags 29–39, Zurich, Switzerland, September 1996. Springer-Verlag. LNCS 1134. ISBN: 3-540-61656-X.

[ODL94] James J. Odell. Six Different Kinds of Composition. Journal of

Object-Oriented Programming Vol. 5, No. 8, January 1994. [OOM98] O. Pastor, V. Pelechano, E. Insfrán, and J. Gómez. From Object

Oriented Conceptual Modeling to Automated Programming in Java. En <<Proceedings of the 17th Internacional Conference on Conceptual Modeling (ER’98)>> pags. 183–196, Singapore, November 1998. Springer-Verlag. LNCS (1507). ISBN 3-540-65189-6.

[OOM97] O. Pastor, E. Insfrán, V. Pelechano J., Romero, and J. Merseguer.

OO-Method: An OO Software Production Environment Combining Conventional and Formal Methods. En <<Proceedings of the 9th Conference on Advanced Information Systems Engineering (CAiSE’97)>> pags. 145–159, Barcelona, Spain, June 1997. Springer-Verlag. LNCS 1250. ISBN: 3-540-63107-0.

302

[OBLCS] OBLOG Software S.A. The OBLOG software development approach. Technical Report, OBLOG Software S.A., 1999.

[OPD00] A.L. Opdahl, B. Henderson-Sellers, F. Barbier. Ontological Analysis

of whole-part relationships in OO-models. Information and Software Technology, Vol. 43, No. 6, pags. 387-399, May 2001.

[OML97] Don Firesmith, Brian Henderson-Sellers and Ian Graham. The

OML Reference Manual. Published by SIGS Books, NY, in March 1997, ISBN 1-884842-75-5.

[OPEN96] B. Henderson-Sellers. The OPEN methodology. Object Magazine,

Vol. 6, Part 9, pags. 56-59, November 1996, SIGS Publications [OPNRL] B. Henderson-Sellers. OPEN Relationships – Associations,

Mappings, Dependencies and Uses. Journal of Object Oriented Programming, Vol. 10, No. 9, pags. 49-57, Feb 1998

[OLIVL] Antoni Olivé. Modelització conceptual de sistemes d'informació.

L'estructura. Edicions UPC. 2002. [ONME] OLIVA NOVA Model Execution. www.care-t.com [PFAP05] Oscar Pastor, Joan Fons, Silvia Abrahao, Vicente Pelechano.

Conceptual Modelling of Web Applications: the OOWS approach. Book Chapter. Web Engineering - Theory and Practice of Metrics and Measurement for Web Development, Mendes E. (Eds.), Springer 2005, 35 p.

[PELET] Vicente Pelechado. Ph. D Tesis. Tratamiento de Relaciones

Taxonómicas en Entornos de Producción Automática de Software. Una Aproximación Basada en Patrones. Departamento de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia. 2001.

[PHIE98] Carlos Meneses, Oscar Pastor, Juan Carlos Molina, Emilio Insfrán.

Temporality Specification in Automatic Production Software Enviroments Based on Object-Oriented Conceptual Models. Computación y Sistemas, Vol. 4, No.4, pags. 327-339, 2001.

[QVT2.0] Object Management Group. MOF QVT Final Adopted Specification.

2005. http://www.omg.org [RQTRS] Object Management Group. OMG MOF 2.0 query, views,

transformations request for proposals. [RMB87] J. Rumbaugh. Relations as semantic constructs in an object-

oriented language. En <<Proceedings of the OOPSLA> pags. 466-481, October 1987.

[RHS95] D.W. Renouf and B. Henderson-Sellers. Incorporating roles into

MOSES. En <<Proceedings of the 15th Conference on Technology

303

of Object-Oriented Languages and Systems, TOOLS 15>> pags 71–82, 1995.

[SG99] Anthony J.H. Simons, Ian Graham. 30 Things That Go Wrong in

Object Modeling with UML 1.3. Chapter 17 in Haim Kilov, Bernhard Rumpe, Ian Simmonds (eds.): Behavioural Specifications of Businesses and Systems. Pags. 237-257. Kluwer Academic Publications, 1999.

[SPACC] C. Parent, S. Spaccapietra, E. Zimányi, Modeling time from a

conceptual perspective. En <<Proceedings of the 7th International Conference on Information and Knowledge Management, CIKM'98>> pags. 432-440. 1998.

[STV02] Perdita Stevens. On the Interpretation of Binary Associations in

the Unified Modelling Language. Journal of Software and Systems Modeling, Vol. 1, No. 1, pags. 68-79, 2002.

[SAK98] Monika Saksena, Robert B. France, Maria M. Larrondo-Petrie. A

Characterization of Aggregation. En <<Proceedings of the 5th International Conference on Object-Oriented Information Systems (OOIS'98)>> September 1998. Edited version printed in the International Journal of Computer Systems Science & Engineering.

[SEL03] Bran Selic. The Pragmatics of Model-Driven Development. IEEE

Software, Vol. 20, No. 5, pags. 19-25, September-October 2003. [SNK98] Monique Snoeck, Guido Dedene. Existence Dependency: The key

to Semantic Integrity Between Structural and Behavioural Aspects of Object Types. IEEE Transactions On Software Engineering, Vol. 24, No. 4, April 1998

[SR98] Schuette, Rotthowe. The Guidelines of Modeling –An Approach to

Enhance the Quality in Information Models. En <<Proceedings of the 17th International Conference on Conceptual Modeling>> Pags. 240 - 254, 1998 ISBN:3-540-65189-6

[SYN94] S. Cook and J. Daniels. Designing Objects Systems. Object-

Oriented Modelling with Syntropy. Prentice Hall, 1994. [SHML97] S. Shlaer and S.J. Mellor. Recursive Design of an Application-

Independent Architecture. IEEE Software, Vol. 14, No.1, pags. 61-72, January 1997.

[TRF02] Anna Gerber, Michael Lawley, Kerry Raymond, Jim Steel, and

Andrew Wood. Transformation: The Missing Link of MDA. En <<Proceedings of the First International Conference on Graph Transformation ICGT 2002>> A. Corradini, H. Ehrig, H.-J. Kreowski, and G. Rozenberg, editors http://citeseer.ist.psu.edu/gerber02transformation.html

304

[UML1.2] Object Management Group. Unified Modeling Language, version 1.2. 1998

[UML2.0] Object Management Group. UML 2.0 Superestructure

Specification. October 8, 2004. [UMLI2.0] Object Management Group. UML 2.0 Infaestructure Specification. [WHT99] Brian Henderson-Sellers, Frank Barbier. What Is This Thing Called

Aggregation? En <<Proceedings of the Technology of Object Oriented Languages and Systems 1999>> Pags. 216-230. ISBN:0-7695-0275-X

[WSW00] Yair Wand, Veda C. Storey and Ron Weber. An Ontological

Analysis of the Relationship Construct in Conceptual Modeling. ACM Transactions on Database Systems, Vol. 24, No. 4, pags. 494-528, December 1999.