Redefinición de asociaciones en UML: semántica y utilización

Universidad Politécnica de Cataluña Departamento de Lenguajes y Sistemas Informáticos Máster en Computación Tesis de Máster Redefinición de Asociaciones en UML: Semántica y Utilización Estudiante: Pilar Nieto Soler Director(es): Dolors Costal Costa y Cristina Gómez Seoane Fecha: 18 de Septiembre, 2008 Título: Redefinición de asociaciones en UML: Semántica y Utilización Autor: Pilar Nieto Soler Fecha: 18 de Septiembre, 2008 Resumen: Un inconveniente importante que presenta hoy en día UML es la falta de semántica formal. Existen muchos conceptos que no define con la suficiente precisión como para que puedan ser interpretados sin ambigüedades. Uno de los principales objetivos de este trabajo es precisar la semántica de la redefinición de asociaciones, un constructor de UML que nos permite definir de manera más específica extremos de asociaciones. Así mismo, comparamos este constructor con conceptos similares, como el subsetting (de UML) o el refinamiento de asociaciones (de otros lenguajes de modelado), con el objetivo de mostrar claramente que se tratan de conceptos semánticamente diferentes. Todo ello ayudará al diseñador a hacer un uso correcto del constructor de la redefinición de asociaciones. Otra contribución significativa de este trabajo es la de incorporar a UML la semántica del refinamiento de asociaciones. Para ello, creamos nuevos estereotipos que nos permitirán incorporar todos aquellos casos que podemos expresar con el refinamiento y que no quedan cubiertos por la redefinición de asociaciones. Finalmente, implementamos estos estereotipos en la herramienta CASE PoseidonUML. Palabras clave: Modelado conceptual, Semántica de asociaciones, Redefinición de asociaciones en UML. - 5 - Índice general 1. Introducción......................................................................................................................................10 2. Descripción general de la Investigación en la Semántica de las Asociaciones en UML.............12 3. Conceptos Básicos.............................................................................................................................14 3.1 Sintaxis.........................................................................................................................................14 3.2 Semántica.....................................................................................................................................14 3.2.1 Dominio Semántico.............................................................................................................15 3.2.2 Mapping Semántico.............................................................................................................16 3.3 El enfoque del Meta-modelado....................................................................................................16 4. Redefinición de Asociaciones en UML...........................................................................................18 4.1 Sintaxis.........................................................................................................................................18 4.2 Semántica.....................................................................................................................................19 4.2.1 Redefinición de Nombre......................................................................................................20 4.2.2 Redefinición de Tipo............................................................................................................21 4.2.3 Redefinición de Multiplicidad.............................................................................................22 4.2.4 Redefinición del tipo de derivación.....................................................................................23 4.2.5 Visión global........................................................................................................................25 4.2.6 Combinaciones.....................................................................................................................26 4.2.6.1 Combinación de dos redefiniciones de tipo.................................................................26 4.2.6.2 Redefiniciones de nombre, tipo y multiplicidad..........................................................26 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones....28 5.1 Subconjunto de una asociación en UML.....................................................................................28 5.1.1 Sintaxis.................................................................................................................................28 5.1.2 Semántica.............................................................................................................................29 5.2 Comparación con la Redefinición de Asociaciones....................................................................30 5.2.1 Sintáctica..............................................................................................................................31 5.2.2 Semántica.............................................................................................................................31 5.2.2.1 Comparación de los diagramas traducidos...................................................................31 5.2.2.2 Satisfacción de restricciones OCL...............................................................................32 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones..................40 6.1 Refinamiento de una asociación..................................................................................................40 6.1.1 Refinamiento de Participantes.............................................................................................40 6.1.1.1 Notación.......................................................................................................................40 6.1.1.2 Semántica.....................................................................................................................42 6.1.2 Refinamiento de Restricciones de Cardinalidad..................................................................43 6.1.2.1 Notación.......................................................................................................................43 6.1.2.2 Semántica.....................................................................................................................44 6.2 Comparación con la Redefinición de Asociaciones....................................................................46 6.2.1 Refinamiento de Participantes.............................................................................................46 6.2.2 Refinamiento de Restricciones de Cardinalidad..................................................................48 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones...............52 7.1 Estereotipos definidos..................................................................................................................53 7.1.1 <<Refinement>>..................................................................................................................53 7.1.2 <<RefinementOfParticipants>>...........................................................................................53 7.1.3 <<RefinementOfCardinality>>............................................................................................54 7.2 Implementación............................................................................................................................55 - 6 - 8. Conclusiones y trabajo futuro.........................................................................................................57 Referencias............................................................................................................................................58 Anexo: Manual de usuario para el plugin de PoseidonUML............................................................60 A.1 Creación de refinamientos..........................................................................................................60 A.2 Edición de refinamientos.............................................................................................................63 A.3 Borrado de refinamientos............................................................................................................64 - 7 - Índice de figuras Fig. 4.1. Notación de la redefinición......................................................................................................18 Fig. 4.2. Ejemplo de redefinición...........................................................................................................18 Fig. 4.3. Fragmento del metamodelo de UML que describe redefiniciones de extremos de asociaciones .....................................................................................................................................................................19 Fig. 4.4. Ejemplo de redefinición de nombre.........................................................................................20 Fig. 4.5. Traducción de la redefinición de nombre................................................................................21 Fig. 4.6. Traducción de la redefinición de nombre de la fig. 4.4...........................................................21 Fig. 4.7. Ejemplo de redefinición de tipo...............................................................................................22 Fig. 4.8. Traducción de la redefinición de tipo......................................................................................22 Fig. 4.9. Traducción de la redefinición de tipo de la fig. 4.7.................................................................22 Fig. 4.10. Ejemplo de redefinición de multiplicidad..............................................................................23 Fig. 4.11. Traducción de la redefinición de multiplicidad.....................................................................23 Fig. 4.12. Traducción de la redefinición de multiplicidad de la figura 4.10..........................................23 Fig. 4.13. Ejemplo de una redefinición del tipo de derivación..............................................................24 Fig. 4.14. Traducción de la redefinición del tipo de derivación.............................................................24 Fig. 4.15. Traducción de la redefinición del tipo de derivación de la fig. 4.13......................................24 Fig. 4.16. Ejemplo de dos redefiniciones de tipo para dos extremos de una sola asociación................26 Fig. 4.17. Traducción de las redefiniciones de la fig. 4.16....................................................................26 Fig. 4.18. Ejemplo de redefiniciones de nombre, tipo y multiplicidad de un extremo de asociación....27 Fig. 4.19. Traducción de las redefiniciones de la fig. 4.18....................................................................27 Fig. 5.1. Notación del subsetting............................................................................................................28 Fig. 5.2. Ejemplo de subsetting..............................................................................................................29 Fig. 5.3. Fragmento del metamodelo de UML que describe el subsetting de extremos de asociación..29 Fig. 5.4. Traducción del subsetting ........................................................................................................30 Fig. 5.5. Traducción del subsetting de la fig. 5.2...................................................................................30 Fig. 5.6. La restricción de participación no queda garantizada por el subsetting ..................................33 Fig. 5.7. Ejemplo de subsetting con diferentes subclases......................................................................34 Fig. 5.8. La restricción de cardinalidad mínima queda garantizada por el subsetting ...........................34 Fig. 5.9. La restricción de cardinalidad máxima no queda garantizada por el subsetting......................35 Fig. 5.10. La restricción general (deducida de una regla de derivación) no queda garantizada por el subsetting ....................................................................................................................................................36 Fig. 5.11. Traducción del subsetting con el subsetting end derivado.....................................................36 Fig. 5.12. Ejemplo de subsetting con el subsetting end derivado..........................................................37 Fig. 6.1. Notación del refinamiento de participantes............................................................................40 Fig. 6.2. Ejemplo de refinamiento de participantes................................................................................41 Fig. 6.3. Notación del refinamiento de participantes con un conjunto de clases origen y destino.........41 Fig. 6.4. Ejemplo de refinamiento de participantes con un conjunto de clases origen y destino...........42 Fig. 6.5. Traducción del refinamiento de participantes con un conjunto de clases origen y destino de la fig. 6.3.........................................................................................................................................................42 Fig. 6.6. Traducción del refinamiento de participantes de la fig. 6.4.....................................................42 Fig. 6.7. Notación del refinamiento de cardinalidad..............................................................................43 Fig. 6.8. Ejemplo de refinamiento de cardinalidad................................................................................44 Fig. 6.9. Ejemplo de notación del refinamiento de cardinalidad con un conjunto de clases origen......44 Fig. 6.10. Traducción del refinamiento de cardinalidad con un conjunto de clases origen...................45 Fig. 6.11. Ejemplo de refinamiento de cardinalidad con un conjunto de clases origen.........................45 Fig. 6.12. Traducción del refinamiento de cardinalidad de la fig. 6.11.................................................45 Fig. 6.13. Refinamiento de participantes versus redefinición de tipo....................................................47 Fig. 6.14. Traducción del refinamiento de participantes y la redefinición de tipo de la fig. 6.13.........48 Fig. 6.16. Traducción del refinamiento de restricciones cardinalidad y la redefinición de multiplicidad de la fig. 6.15...............................................................................................................................................49 Fig. 6.17. Refinamiento de cardinalidad versus redefinición de tipo y multiplicidad...........................50 Fig. 6.18. Traducción del refinamiento de restricciones de cardinalidad y la redefinición de tipo y multiplicidad de la fig. 6.17........................................................................................................................50 Fig. 6.19. Ejemplo de refinamiento de participantes y redefinición de tipo y multiplicidad.................51 Fig. 7.1. Estereotipos para el refinamiento de asociaciones...................................................................52 Fig. 7.2. Ejemplo de uso del estereotipo refinementOfParticipants ......................................................53 Fig. 7.3. Ejemplo de uso del estereotipo refinementOfCardinality........................................................54 Fig. 7.4. Definición del refinamiento de participantes...........................................................................55 - 8 - Fig. 7.5. Representación gráfica del refinamiento de participantes.......................................................56 Fig. A.1. Selección del tipo de refinamiento..........................................................................................60 Fig. A.2. Introducción de los parámetros para la definición del refinamiento de participantes.............61 Fig. A.3. Introducción de los parámetros para la definición del refinamiento de cardinalidad.............62 Fig. A.4. Representación del refinamiento de participantes...................................................................63 Fig. A.5. Representación del refinamiento de cardinalidad...................................................................63 Fig. A.6. Edición de refinamientos.........................................................................................................64 Fig. A.7. Borrado de refinamientos........................................................................................................65 - 9 - Índice de tablas Tabla 4.1. Resumen de las traducciones propuestas para redefiniciones de extremos de asociaciones 25 Tabla 5.1. Restricciones OCL (generadas en la traducción) que quedan garantizadas por la redefinición y el subsetting de asociaciones...............................................................................................32 Tabla 6.1. Casos del refinamiento de participantes cubiertos por la redefinición.................................47 Tabla 6.2. Casos del refinamiento de restricciones de cardinalidad cubiertos por la redefinición........48 3. Conceptos Básicos - 16 - identificadores de objetos de una clase hijo es un subconjunto de los identificadores de objetos de sus clases padre. • Restricciones generales en OCL. Una restricción general es una condición o una restricción expresada en algún lenguaje con el propósito de declarar algún aspecto de la semántica de un elemento. Nosotros consideramos que las restricciones generales son expresadas en OCL. En [OMG06] se define formalmente la sintaxis y semántica del OCL. 3.2.2 Mapping Semántico Dado un lenguaje L y un dominio semántico S, el segundo paso de la definición semántica es establecer un mapping M (es decir, M: L → S) entre los conceptos sintácticos definidos en L y los conceptos del dominio semántico S [Rum00]. Un mapping entre un lenguaje L y un dominio semántico es una función que proporciona para cada constructor del lenguaje L una explicación de este constructor en el dominio semántico S. Esta explicación se da a través de los conceptos que se comprenden bien en el dominio semántico S. Los mappings semánticos pueden ser definidos de diferentes maneras. Una manera es establecer la correspondencia entre el lenguaje y el metamodelo del dominio semántico, es decir, entre la sintaxis abstracta del constructor y los elementos adecuados del dominio semántico. Otra manera alternativa es definir el mapping algorítmicamente, es decir, traduciendo las expresiones en la sintaxis abstracta a expresiones en el lenguaje semántico [KER99]. En este trabajo utilizamos la primera alternativa. 3.3 El enfoque del Meta-modelado Existen diferentes enfoques generales para formalizar constructores del modelado orientado a objetos en UML, que definen estos constructores estableciendo un dominio semántico y un mapping entre la sintaxis y el domino semántico (tal como se ha explicado en subsecciones anteriores). La mayoría de estos enfoques han sido identificados por el Precise UML group (PUML) en [And00, FELR98]. Uno de los enfoques usados para formalizar constructores de UML, cuando se considera como dominio semántico una capa básica de UML, es el enfoque del metamodelado. Este enfoque fue propuesto inicialmente en [KER99]. En este trabajo se utiliza el enfoque del meta-modelado para formalizar el concepto de la redefinición de una asociación en UML. Usamos este enfoque porque proporciona a los diseñadores una semántica precisa de los constructores (a través de su formalización) utilizando el mismo UML, sin necesidad de aprender otro lenguaje formal de especificación. Los pasos básicos de este enfoque (extraídos de [KER99]) son los siguientes: 1. Desarrollar la sintaxis y semántica del núcleo del lenguaje de meta-modelado que se selecciona como dominio semántico. En nuestro caso, este lenguaje corresponde a la capa básica de UML presentada anteriormente. Su sintaxis concreta y abstracta se define de manera completa en [OMG06, OMG07, RBJ05] y su semántica se presenta utilizando como base teoría de conjuntos. Ésta última puede encontrarse en [OMG06, RG98, Szl06]. 2. Transformar la sintaxis de los constructores UML en el metamodelo de UML, es decir, en una sintaxis abstracta. Este paso ya se ha hecho para el caso de redefinición de asociaciones. Las sintaxis concreta y abstracta para este 3. Conceptos Básicos - 17 - constructor son proporcionadas por OMG y explicadas en detalle en [OMG07, RJB05]. Una descripción general de ambas sintaxis para el constructor se muestran en las siguientes secciones. 3. Establecer un mapping entre la sintaxis abstracta del constructor (es decir, entre la parte del metamodelo que representa este constructor) y la descripción del metamodelo de la semántica (es decir, el metamodelo de la capa básica de UML) como se hace, por ejemplo, en [GR98]. Para entender mejor este mapping, lo definimos como una traducción entre un esquema general usando el constructor y otro esquema general usando sólo elementos definidos en la capa básica de UML. En las siguientes secciones mostramos, usando este enfoque, cómo transformar redefiniciones de asociaciones en elementos de la capa de UML. - 18 - 4. Redefinición de Asociaciones en UML La redefinición de una asociación binaria nos permite definir un extremo de asociación de manera más específica [OMG07, RJB05]. Diferentes redefiniciones pueden ser especificadas para cada extremo de una asociación y los dos extremos de una asociación binaria pueden ser redefinidos. En las siguientes subsecciones se presenta una descripción general de la sintaxis concreta y abstracta de las redefiniciones de asociaciones en UML y se define una semántica precisa de este constructor. 4.1 Sintaxis La sintaxis concreta {redefines <nombre-extremo>} situada cerca de un extremo de asociación (el redefining end) indica que este extremo redefine a otro llamado <nombre -extremo> (el redefined end). La figura 4.1 muestra esta notación. Esta figura describe una asociación binaria R con un extremo b que es redefinido por otro extremo b1. En la figura 4.1 a) el redefining end b1 está conectado a la misma clase del redefined end b mientras que en la figura 4.1 b) el redefining end b1 está conectado a un descendiente directo o indirecto de la clase conectada al redefined end b. R b b1 {redefines b} A B R b b1 {redefines b} A B A 1 B 1 a) b) A 1 Fig. 4.1. Notación de la redefinición Consideremos, por ejemplo, la redefinición que se muestra en la figura 4.2. El extremo jeProyecto para los empleados juniors define de manera más específica el extremo proyecto para estos empleados. Participa proyecto jeProyecto {redefines proyecto} Empleado Proyecto Júnior 1..* 1..3 Fig. 4.2. Ejemplo de redefinición La sintaxis abstracta identifica los conceptos principales que describen su notación. En UML, esta sintaxis se presenta a través del metamodelo de UML. La figura 4.3 muestra un fragmento del metamodelo de UML que contiene todos los conceptos que participan en la redefinición de extremos de asociaciones. En general, un elemento que se puede redefinir (representado en el metamodelo de UML como una instancia de la metaclase RedefinableElement) es un elemento que, cuando es definido en el contexto de un clasificador, redefine de manera más especifica o diferente otro elemento en el contexto de otro clasificador que generaliza (directa o indirectamente) el contexto del clasificador. Los elementos que están siendo redefinidos son representados por el rol redefinedElement. 4. Redefinición de Asociaciones en UML - 19 - StructuralFeature Property Relationship Classifier Association isderived:Boolean * * redefinedProperty {subsets redefinedElement} 2..* 0..1 memberEnd association Feature NamedElement RedefinableElement * * /redefinedElement {readOnly,union} Fig. 4.3. Fragmento del metamodelo de UML que describe redefiniciones de extremos de asociaciones La redefinición de extremos de asociaciones es un caso particular de la redefinición de propiedades. En general, las características de una propiedad que pueden ser redefinidas son el nombre, tipo (que puede ser especializado), valor por defecto, tipo de derivación, visibilidad, multiplicidad y restricciones en los valores. Para las propiedades que corresponden a extremos de asociación (es decir, propiedades con un rol association no vacío, véase figura 4.3) deducimos que sólo pueden ser definidas redefiniciones de nombre, tipo, visibilidad y multiplicidad. En estos casos, el rol redefinedProperty del extremo de una asociación, que es un elemento que se puede redefinir, contiene el extremo de asociación que está siendo redefinido por este extremo. En este trabajo, nos centramos sólo en redefiniciones de asociaciones que restringen la especificación original (es decir, redefiniciones de tipo, multiplicidad y del tipo de derivación). Además, estudiamos las redefiniciones de nombre ya que éstas se combinan frecuentemente con otros tipos de redefiniciones. Según una de las well-formedness rules definidas en el metamodelo de UML [OMG07], el extremo opuesto al redefining end debe estar siempre conectado a una clase que sea descendiente de la clase conectada al extremo opuesto del redefined end. Consideremos los diagramas descritos en la figura 4.1, donde A1 es la clase conectada al extremo opuesto del extremo de b1 y A la clase conectada al extremo opuesto del extremo b. Entonces, A1 debe ser un descendiente de A (como en cada uno de los ejemplos de la figura). Como consecuencia, la redefinición de un extremo de asociación debe combinarse siempre con una relación de generalización/especialización. Otra well-formedness rule establece que el redefining end puede estar conectado a la misma clase que el redefined end o a uno de sus descendientes [OMG07]. En el ejemplo de la figura 4.1 a), el extremo b1 está conectado a la misma clase (es decir, la clase B) a la que está conectado el extremo b, mientras que en el ejemplo de la figura 4.1 b) b1 está conectado a un descendiente de la clase conectada a b (es decir, la clase B1). 4.2 Semántica El efecto semántico de una redefinición se aplica sobre un subconjunto de las instancias de la asociación redefinida (es decir, la asociación con el redefined end). Llamamos a este subconjunto instancias afectadas de la redefinición. Para cualquier tipo de redefinición de asociación, las instancias afectadas son los links o instancias de la asociación redefinida, que conecta instancias de la clase del extremo opuesto del redefining end con otras instancias. Consideremos los ejemplos que se muestran en la figura 4.1, donde R es una asociación redefinida que relaciona A y B, y A1 es la clase 4. Redefinición de Asociaciones en UML - 20 - conectada al extremo opuesto del redefining end. En este caso, las instancias afectadas son instancias de R que asocian instancias de A1 con otras instancias. En las siguientes subsecciones se explica la semántica y sintaxis abstracta específica de cada característica redefinida (nombre, tipo, multiplicidad y tipo de derivación) a través de traducciones a nuestra capa básica de UML. La última subsección muestra ejemplos de posibles combinaciones entre características redefinidas. 4.2.1 Redefinición de Nombre Decimos que una redefinición es una redefinición de nombre cuando el redefining end tiene un nombre diferente del redefined end. El efecto de una redefinición de nombre es dar un nuevo nombre a la propiedad del redefined end para las instancias afectadas de la redefinición. Como consecuencia, el antiguo nombre del redefined end no puede ser usado por estas instancias. Las redefiniciones de nombre se combinan frecuentemente con la redefinición de otras características en una única redefinición de asociación aunque, según el metamodelo de UML, es posible especificar una redefinición que sólo redefine el nombre. La figura 4.4 muestra un ejemplo de una redefinición que sólo redefine la característica del nombre. El nombre proyecto es redefinido por el extremo jeProyecto. Su efecto es que el nombre jeProyecto se utilizará para referirse a los proyectos en los que participan empleados juniors. Participa proyecto jeProyecto {redefines proyecto} Empleado Proyecto Júnior presupuesto Fig. 4.4. Ejemplo de redefinición de nombre Para precisar la semántica de la redefinición de nombre, indicamos en la figura 4.5 cómo traducirla a nuestra capa básica de UML. En la traducción, la asociación que redefine (es decir, la asociación con el redefining end) es eliminada. La razón de esta eliminación es que todas sus instancias son instancias de la asociación redefinida y pueden ser deducidas de éstas. Esto no sorprende ya que el objetivo de una redefinición no es definir una nueva asociación, sino mejorar la definición de una asociación ya existente. De esta traducción, se puede observar fácilmente que el efecto de una redefinición de nombre es sólo sintáctico y no tiene un efecto semántico en la asociación que se redefine. Esto es así porque la redefinición de nombre raramente se utiliza sola, sino que se combina normalmente con la redefinición de otras características. Como la asociación que redefine ha desaparecido en la traducción del diagrama, las restricciones OCL sobre el diagrama que hacen referencia a b1, deben ser rescritas para ser evaluadas en el diagrama traducido. Concretamente, ‘b1‘ debe ser reemplazado por ‘b’. En la figura 4.5, expsOCL denota un conjunto de expresiones OCL sobre el diagrama original y nuevasExpsOCL denota el conjunto de expresiones obtenidas de reemplazar ‘b1’ por ‘b’ en expsOCL. 4. Redefinición de Asociaciones en UML - 21 - R b A B + expsOCL + nuevasExpsOCL R b b1 {redefines b} A B A 1 A 1 Fig. 4.5. Traducción de la redefinición de nombre La traducción que se muestra en la figura 4.5 sólo representa aquellos elementos que deben ser cambiados del diagrama original, para obtener el diagrama equivalente en nuestra capa básica de UML. Otros elementos tales como atributos o la multiplicidad de la asociación redefinida no se muestran, ya que éstos seguirán siendo los mismos en el diagrama traducido. Consideremos el ejemplo de la figura 4.4 y la siguiente expresión OCL (invariante) definida sobre él: context Júnior inv: self.jeProyecto->select(p | p.presupuesto>100000) -> size()<=1 Ésta restricción prohíbe que empleados juniors participen en más de un proyecto con un presupuesto mayor que 100000: La figura 4.6 muestra la traducción del diagrama y su expresión OCL. Participa proyecto Empleado Proyecto Júnior presupuesto context Jú nior inv: self.proyecto->select(p | p.presupuesto>100000) -> size()<=1 Fig. 4.6. Traducción de la redefinición de nombre de la fig. 4.4 4.2.2 Redefinición de Tipo En general, el redefining end de una redefinición puede estar conectado a la misma clase a la que está conectado el redefined end o a alguno de sus descendientes [OMG07]. Decimos que una redefinición es una redefinición de tipo cuando el redefining end está conectado a un descendiente de la clase del redefined end ya que, claramente, el tipo no es redefinido cuando el redefining end está conectado a la misma clase que el redefined end. El efecto de una redefinición de tipo es establecer una restricción de participación adicional sobre la asociación redefinida. Concretamente, se indica que las instancias afectadas de la redefinición deben asociar instancias de la clase opuesta al redefining end con instancias de la clase conectada al redefining end. En el ejemplo de la figura 4.7, el extremo ncProyecto redefine el tipo del extremo proyecto ya que la clase NoCrítico es un descendiente de la clase Proyecto. El efecto es que los empleados juniors sólo pueden participar en proyectos no críticos. Nótese que no se impone la condición inversa, es decir, los proyectos no críticos pueden tener como participantes cualquier tipo de empleado. La razón es que sólo el extremo proyecto es redefinido pero no el extremo empleado. 4. Redefinición de Asociaciones en UML - 22 - Participa proyecto ncProyecto {redefines proyecto} Empleado Proyecto Júnior 1..* N oCrítico empleado Fig. 4.7. Ejemplo de redefinición de tipo La traducción de una redefinición de tipo a nuestra capa básica de UML, consiste en sustituir la redefinición por una restricción de participación que especifica de manera precisa su efecto sobre la asociación redefinida. La figura 4.8 indica la regla de equivalencia para esta traducción. R b b1 {redefines b} A B R b B + restricción de participación context A1 inv: self.b - >forAll(oclIsTypeOf(B 1 )) A 1 B 1 A A 1 B 1 Fig. 4.8. Traducción de la redefinición de tipo La restricción de participación es necesaria para asegurar que cada instancia del extremo b asociado con una instancia de A1 debe ser instancia de B1. Esta restricción puede ser expresada como un invariante de OCL tal y como se muestra en la figura 4.8. Aunque la redefinición de la figura 4.8 redefine el tipo y el nombre, por claridad, la traducción propuesta se centra en el efecto de la redefinición de tipo. La figura 4.9 muestra la traducción del ejemplo de la figura 4.7. El invariante OCL asegura que todos los proyectos de un empleado júnior son proyectos no críticos. Participa proyecto Empleado Proyecto Júnior 1..* NoCrítico context Jú nior inv: self.proyecto->forAll(oclIsTypeOf(NoCrítico)) Fig. 4.9. Traducción de la redefinición de tipo de la fig. 4.7 4.2.3 Redefinición de Multiplicidad Según el metamodelo de UML, la multiplicidad del redefining end, si se especifica, debe ser igual o más restrictiva que la multiplicidad especificada en el redefined end [OMG07]. Decimos que una redefinición es una redefinición de multiplicidad cuando se especifica una multiplicidad en el redefining end y ésta es más restrictiva que la del redefined end. De lo contrario, la multiplicidad no sería redefinida. El efecto de una redefinición de multiplicidad es establecer una restricción de cardinalidad adicional sobre la asociación redefinida. Básicamente, ésta restringe la multiplicidad permitida para las instancias afectadas de la redefinición. En el ejemplo de la figura 4.10, el extremo jeProyecto redefine la multiplicidad del extremo proyecto. El efecto de esta redefinición es que los empleados juniors no pueden participar en más de tres proyectos. Nótese que la multiplicidad del redefinig end, 1..3, es más restrictiva que la multiplicidad redefinida, 1..*. 4. Redefinición de Asociaciones en UML - 23 - Participa proyecto jeProyecto {redefines proyecto} Empleado Proyecto Júnior 1..* 1..3 Fig. 4.10. Ejemplo de redefinición de multiplicidad La figura 4.11 indica cómo traducir una redefinición de multiplicidad a nuestra capa básica de UML, con el fin de hacer más preciso su significado semántico. En la traducción, la redefinición es sustituida por una restricción de cardinalidad que especifica su efecto sobre la asociación redefinida. + restricción de cardinalidad mínima (en caso que minb>0 y minb1 > minb) context A1 inv: self.b->size() >= minb1 + restricción de cardinalidad máxima (en caso que maxb no es* y maxb1 < maxb) context A1 inv: self.b-> size() <= maxb1 b1 {redefines b} R b A B A 1 minb..maxb minb1..maxb1 R b A B A 1 minb..maxb Fig. 4.11. Traducción de la redefinición de multiplicidad Las restricciones de cardinalidad son necesarias para asegurar que cada instancia de la clase A1 está asociada a través de la asociación R a un número minb1 de instancias como mínimo y a un número maxb1 de instancias como máximo. En general, estas restricciones pueden ser expresadas en OCL tal y como se muestra en la figura 4.11. La figura 4.12 muestra la traducción del ejemplo de la figura 4.10. El invariante OCL garantiza que los empleados juniors no pueden participar en más de tres proyectos. Participa proyecto Empleado Proyecto Júnior 1..* context Jú nior inv: self.proyecto->size() <= 3 Fig. 4.12. Traducción de la redefinición de multiplicidad de la figura 4.10 4.2.4 Redefinición del tipo de derivación Según se indica en [OMG07] sólo están permitidas redefiniciones de propiedades no derivadas en derivadas. Decimos que una redefinición es una redefinición del tipo de derivación cuando una barra (/) se sitúa delante del nombre del redefining end. El efecto de la redefinición del tipo de derivación es cambiar el tipo de derivación (es decir, la manera que utiliza el sistema para conocer la población) de la propiedad del redefined end para las instancias afectadas de la redefinición. Concretamente, la redefinición del tipo de derivación indica que las instancias afectadas de la redefinición deben ser deducidas o calculadas por la regla de derivación (nosotros suponemos reglas de derivación expresadas en OCL). 4. Redefinición de Asociaciones en UML - 24 - Consideremos el ejemplo de la figura 4.13. El extremo jeProyecto redefine el tipo de derivación del extremo proyecto. El efecto de esta redefinición es que los empleados juniors participaran en proyectos (calculados por la regla de derivación) con un máximo de ocho semanas de duración. Participa proyecto / jeProy ect o {redefines proyecto} Empleado Proyecto Júnior duración context Jú nior :: jeProy ect o: Set (Proy ect o ) derive: Proyecto.allInstances->select(p | p.duración <= 8) Fig. 4.13. Ejemplo de una redefinición del tipo de derivación Para hacer más precisa la semántica de la redefinición del tipo de derivación, mostramos en la figura 4.14 cómo traducirla a nuestra capa básica de UML. En la traducción, la redefinición es eliminada y la regla de derivación para b1 es sustituida por una restricción sobre el extremo b para las instancias afectadas. Esta restricción establece que las instancias de B que están asociadas con cada instancia de A1 se obtienen a través de la regla de derivación para b1. + restricción general deducida de la regla de derivación para b1 context A1 inv: self.b = expresión OCL de la regla de derivación para b 1 /b1 {redefines b} R b A B A 1 R b A B + regla de derivación para b 1 context A1 :: b1: Set(B) derive: regla de derivación para b 1 A 1 Fig. 4.14. Traducción de la redefinición del tipo de derivación Obsérvese que el diagrama original y traducido son equivalentes con respecto a las instancias y links que éstos contienen (es decir, las instancias de A, A1 y B y los links de R son las mismos en ambos diagramas) aunque la manera que utiliza el sistema para conocerlas es diferente. En el diagrama original los links de la asociación redefinida afectados por la redefinición son calculados automáticamente por la regla de derivación, mientras que en el diagrama traducido estos links deben ser proporcionados explícitamente por el usuario (y deben cumplir la restricción definida sobre el extremo b). En la figura 4.15 mostramos cómo traducir el ejemplo de la figura 4.13. El invariante OCL garantiza que los proyectos en los que participan empleados juniors son proyectos con una duración máxima de ocho semanas. Participa proyecto Empleado Proyecto Júnior duración context Jú nior inv: self.proyecto = Proyecto.allInstances->select(p | p.duración <= 8) Fig. 4.15. Traducción de la redefinición del tipo de derivación de la fig. 4.13 4. Redefinición de Asociaciones en UML - 25 - 4.2.5 Visión global En las anteriores subsecciones se ha definido de manera precisa la semántica de la redefinición de asociaciones, a través de la traducción de cada una de las características redefinidas a nuestra capa básica de UML. Todas estas traducciones se encuentran resumidas en la tabla 4.1. Mediante su análisis, es posible obtener una visión global del significado de la redefinición de asociaciones en UML. El principal objetivo de una redefinición de asociación no es añadir una nueva asociación, sino mejorar la definición de una asociación existente. Por este motivo, la asociación que redefine no aparece en la traducción de ninguna redefinición (véase tabla 4.1). Además, las instancias de la asociación que redefine pueden ser siempre deducidas de las de la asociación redefinida. En segundo lugar, la definición de la asociación redefinida se mejora en todos los casos al restringir el conjunto de instancias que están permitidas para ésta, con la única excepción de aquellos casos que solo redefinen la característica de nombre. Los tipos de restricciones que se imponen dependen de las características que están siendo redefinidas. Concretamente, las restricciones de tipo establecen restricciones de participación adicionales, las redefiniciones de multiplicidad establecen restricciones de cardinalidad mínima y máxima y las redefiniciones del tipo de derivación imponen restricciones que dependen de la regla de derivación proporcionada por el diseñador. La tabla 4.1 resume estas restricciones. La especificación precisa de estas restricciones se ha realizado a través de expresiones OCL en subsecciones anteriores. Las redefiniciones de nombre no siguen este patrón y sólo tienen el efecto sintáctico de dar un nuevo nombre a la propiedad redefinida para las instancias afectadas de la redefinición. Esto es así, porque la traducción de la redefinición de nombre simplemente consiste en la sustitución de ese nombre en las expresiones OCL definidas en el diagrama original (véase tabla 4.1). Para concluir, debemos señalar que las redefiniciones del tipo de derivación tienen una particular implicación adicional que no es tratada por la traducción propuesta, tal y como se explica en la sección 4.2.4, es decir, las instancias afectadas de la redefinición son calculadas automáticamente por la regla de derivación en vez de ser proporcionadas por los usuarios del sistema, tal y como ocurre con el resto de instancias de la asociación redefinida. Asociación que redefine Redefining end Restricciones Nombre Eliminada Sustituido por el redefined end en las expresiones OCL Tipo Eliminada -Restricción de participación Multiplicidad Eliminada -Restricción de cardinalidad mínima -Restricción de cardinalidad máxima Característica redefinida Tipo de derivación Eliminada -Restricción general deducida de la regla de derivación para b1 Tabla 4.1. Resumen de las traducciones propuestas para redefiniciones de extremos de asociaciones 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 32 - end. Por este motivo, como hemos comentado anteriormente, al traducir el subsetting a nuestra capa básica de UML, la asociación del subsetting end no se elimina en el diagrama traducido. La figura 5.2 muestra un ejemplo en el que se ha definido un subsetting entre dos extremos de las asociaciones Participa y Líder. La primera de ellas expresa que un empleado puede participar en proyectos y la segunda que un empleado senior puede ser líder de proyectos. Ambas asociaciones son semánticamente diferentes y las instancias de la asociación Líder no pueden ser deducidas de las instancias de la asociación Participa. Resumiendo, hemos visto que los diagramas traducidos para la redefinición y el subsetting de asociaciones son diferentes: en la redefinición, la asociación con el redefining end desaparece y en su lugar se añade una restricción OCL que define su efecto sobre el diagrama. En cambio en el subsetting, la asociación con el subsetting end se mantiene en el diagrama traducido. 5.2.2.2 Satisfacción de restricciones OCL En esta subsección, demostramos formalmente qué restricciones OCL, generadas al traducir la redefinición y el subsetting de asociaciones a nuestra capa básica de UML, quedan garantizadas por cada uno de estos constructores. La tabla 5.1 resume estas restricciones. Restricción OCL Participación Cardinalidad mínima Cardinalidad máxima General (deducida de una regla de derivación) Inclusión Redefinición P (redefinición de tipo) P (redefinición de la multiplicidad) P (redefinición de la multiplicidad) P (redefinición del tipo de derivación) P Subsetting O P O O P Tabla 5.1. Restricciones OCL (generadas en la traducción) que quedan garantizadas por la redefinición y el subsetting de asociaciones Como podemos ver en la tabla anterior, todas las restricciones OCL quedan garantizadas por la redefinición: la restricción de participación queda garantizada por la redefinición de tipo, la de cardinalidad mínima y máxima por la redefinición de multiplicidad, la restricción general (deducida de una regla de derivación) por la redefinición del tipo de derivación y finalmente, la restricción de inclusión, generada en la traducción del subsetting, queda garantizada por cualquier tipo de redefinición. En cambio, sólo dos restricciones OCL quedan garantizadas por el subsetting: la restricción de inclusión y la de cardinalidad mínima, generada en la traducción de la redefinición de multiplicidad. A continuación, demostramos formalmente a través de cinco teoremas que: (a) la restricción de participación no queda garantizada por el subsetting, (b) la restricción de cardinalidad mínima queda garantizada por el subsetting, (c) la restricción de cardinalidad máxima no queda garantizada por el subetting, (d) la restricción general (deducida de una regla de derivación) no queda garantizada por el subsetting y (e) la restricción de inclusión queda garantizada por cualquier tipo de redefinición. 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 33 - La restricción de participación no queda garantizada por el subsetting Tal y como explicamos en la sección 4, la restricción de participación se genera al traducir la redefinición de tipo a nuestra capa básica de UML. Recordemos que para definir este tipo de redefinición, el redefining end debe estar conectado a una de las clases descendientes de la clase del redefined end. Por este motivo, para demostrar que la restricción de participación no queda garantizada por el subsetting, partimos del escenario descrito en la figura 5.6. R b b1 {subsets b} A B context A1 inv: self.b->forAll(oclIsTypeOf(B1)) (no garantizada) A 1 B 1 R1 Fig. 5.6. La restricción de participación no queda garantizada por el subsetting Teorema 5.1: La restricción de participación no queda garantizada por el subsetting Sean A y B dos clases y R una asociación binaria entre ellas. Sea b el extremo de la asociación que conecta R a la clase B. Sea A1 una subclase de A, B1 una subclase de B y R1 una asociación binaria entre ellas. Sea b1 el extremo que conecta R1 a B1. Suponemos que el extremo b1 se declara como un subsetting del extremo b. Entonces, la restricción de participación expresada como context A 1 inv: self.b- >forAll(oclIsTypeOf(B1)) no queda garantizada por el subsetting (véase figura 5.6). Demostración. (1) La traducción del subsetting declarado a nuestra capa básica de UML requiere la restricción de inclusión expresada como context A1 inv: self.b - > includesAll(self.b1). La figura 5.4 d) muestra el esquema traducido. (2) Suponemos una base de información (BI) donde: (2.1) x e y son instancias de B y x es también una instancia de B1. (2.2) z es una instancia de A y A1. (2.3) z está R-relacionada con x y con y y z está R1-relacionada con x. (3) La BI descrita en (2) satisface todas las restricciones del diagrama traducido descrito en (1), es decir, ésta satisface la restricción textual de la inclusión junto con las restricciones gráficas definidas sobre el diagrama traducido. (4) La BI descrita en (2) no satisface la restricción de participación porque, según esta restricción, las instancias x y y deben ser de tipo B1, y por el paso (2) sólo x es una instancia de B1. (5) Por tanto, por (3) y (4) la restricción de participación no queda garantizada por el subsetting. Consideremos el ejemplo de la figura 5.7 que relaciona estudiantes y asignaturas. Un estudiante tiene inicialmente una serie de asignaturas que son de su interés. Una vez el estudiante ha sido aceptado y se ha decidido que asignaturas serán ofrecidas, éste puede matricularse de dichas asignaturas, siempre y cuando sean de su interés. Para este ejemplo, vemos que la restricción de participación, expresada como context Aceptado inv: self.asignatura->forAll(oclIsTypeOf(Ofrecida)) no se satisface por el diagrama. Según esta restricción, todas las asignaturas que son de interés para un estudiante aceptado deben ser finalmente ofrecidas. En cambio, vemos que el diagrama no satisface esta restricción ya que según éste, un estudiante puede tener asignaturas que sean de su interés y que finalmente no sean ofrecidas. 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 34 - Interesa Matricula Estudiante Aceptado Asignatura Ofrecida ofrecida {subsets asignatura} asignatura Fig. 5.7. Ejemplo de subsetting con diferentes subclases La restricción de cardinalidad mínima queda garantizada por el subsetting Recordemos que la restricción de cardinalidad mínima se genera al traducir la redefinición de multiplicidad a nuestra capa básica de UML. Para definir este tipo de redefinición, el redefining y el redefined end deben estar conectados a la misma clase (suponiendo que no se combina con una redefinición de tipo). Por este motivo, para demostrar que la restricción de cardinalidad mínima queda garantizada por el subsetting, consideramos el escenario descrito en la figura 5.8. R b b1 {subsets b} A B context A1 inv: self.b->size() >= minb1 (garantizada) A 1 R 1 minb1.. maxb1 minb..maxb Fig. 5.8. La restricción de cardinalidad mínima queda garantizada por el subsetting Teorema 5.2: La restricción de cardinalidad mínima queda garantizada por el subsetting Sean A y B dos clases y R una asociación binaria entre ellas. Sea b el extremo que conecta R a la clase B. Sea A1 una subclase de A y R1 una asociación binaria entre A1 y B. Sea b1 el extremo que conecta R1 a B y minb1 la multiplicidad mínima para el extremo b1. Suponemos que el extremo b1 se declara como un subsetting del extremo b. Entonces, la restricción de la cardinalidad mínima expresada como context A1 inv: self.b->size() >= minb1 queda garantizada por el subsetting (véase figura 5.8). Demostración. (1) La traducción del subsetting declarado a nuestra capa básica de UML requiere la restricción de inclusión expresada como context A1 inv: self.b - > includesAll(self.b1). La figura 5.4 b) muestra el esquema traducido. (2) Como self.b contiene todos los elementos de self.b1 el tamaño de self.b debe ser mayor o igual que el tamaño del self.b1. Entonces, self.b->size() >=self.b1->size(). (3) Como minb1 es la cardinalidad mínima del extremo b1 el tamaño del self.b1 debe ser mayor o igual a minb1. Entonces, self.b1->size() >= minb1. (4) Por tanto, por (2) y (3) la restricción de cardinalidad mínima queda garantizada por el subsetting. En el ejemplo de la figura 5.2, la restricción de cardinalidad mínima se expresa como context Senior inv: self.proyecto->size() >= 2. Según esta restricción un empleado senior debe participar en como mínimo dos proyectos. Por otro lado, el diagrama indica que un empleado senior debe ser líder de como mínimo dos proyectos en los que participa, por tanto dicho empleado debe participar en como mínimo dos proyectos. Así pues, vemos claramente que el diagrama satisface dicha restricción. 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 35 - La restricción de cardinalidad máxima no queda garantizada por el subsetting Como vimos en la sección 4, para definir una redefinición de multiplicidad, el redefining y el redefined end deben estar conectados a la misma clase (suponiendo que no se combina con una redefinición de tipo). Por este motivo, para demostrar que la restricción de cardinalidad máxima, generada en la traducción de la redefinición de multiplicidad, no queda garantizada por el subsetting, consideramos el escenario descrito en la figura 5.9. R b b1 {subsets b} A B context A1 inv: self.b->size() <= maxb1 (no garantizada) A 1 R 1 minb1.. maxb1 minb..maxb Fig. 5.9. La restricción de cardinalidad máxima no queda garantizada por el subsetting Teorema 5.3: La restricción de cardinalidad máxima no queda garantizada por el subsetting Sean A y B dos clases y R una asociación binaria entre ellas. Sea b el extremo que conecta R a la clase B y maxb la multiplicidad máxima del extremo b. Sea A1 una subclase de A y R1 una asociación binaria entre A1 y B. Sea b1 el extremo que conecta R1 a B y maxb1 la multiplicidad máxima del extremo b1. Suponemos que el extremo b1 está declarado como un subsetting del extremo b. Entonces, la restricción de cardinalidad máxima expresada como context A 1 inv: self.b->size() <= maxb1 no queda garantizada por el subsetting (véase figura 5.9). Demostración. (1) La traducción del subsetting declarado a nuestra capa básica de UML requiere la restricción de inclusión expresada como context A1 inv: self.b - > includesAll(self.b1). La figura 5.4 b) muestra el diagrama traducido. (2) Suponemos una base de información (BI) donde: (2.1) x e y son instancias de B. (2.2) z es una instancia de A y A1. (2.3) maxb = 2 y maxb1 = 1. (2.4) z está R-relacionada con x y con y y z está R1-relacionada con x. (3) La BI descrita en (2) satisface todas las restricciones del diagrama traducido descrito en (1), es decir, ésta satisface la restricción textual de inclusión junto con las restricciones gráficas definidas sobre el diagrama traducido. (4) La BI descrita en (2) no satisface la restricción de cardinalidad máxima porque según esta restricción, z debe estar R-relacionada como mucho con una instancia de tipo B y por el paso (2) z está R-relacionada con x y con y. (5) Entonces, por (3) y (4) la restricción de cardinalidad máxima no queda garantizada por el subsetting. En el ejemplo de la figura 5.2, vemos que la restricción de cardinalidad máxima, expresada como context Senior inv: self.proyecto->size() <= 3 no se satisface por el diagrama. Según esta restricción, un empleado senior puede participar en como máximo tres proyectos. No obstante, la restricción gráfica de cardinalidad máxima * indica que un empleado puede participar en más de tres proyectos, lo que contradice lo expresado por la restricción OCL. 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 36 - La restricción general (deducida de una regla de derivación) no queda garantizada por el subsetting Recordemos que la restricción general (deducida de una regla de derivación) se genera al traducir la redefinición del tipo de derivación a nuestra capa básica de UML. Para aplicar la redefinición del tipo de derivación, el redefining y el redefined end deben estar conectados a la misma clase (suponiendo que no se combina con una redefinición de tipo). Por tanto, para demostrar que la restricción general no queda garantizada por el subsetting, partimos del escenario descrito en la figura 5.10. /b1 {subsets b} R b A B A 1 context A1 :: b1: Set(B) derive: regla de derivación para b1 context A1 inv: self.b = expresión OCL de la regla de derivación para b1 (no garantizada) R 1 Fig. 5.10. La restricción general (deducida de una regla de derivación) no queda garantizada por el subsetting Teorema 5.4: La restricción general (deducida de una regla de derivación) no queda garantizada por el subsetting Sean A y B dos clases y R una asociación binaria entre ellas. Sea b el extremo que conecta R a la clase B. Sea A1 una subclase de A y R1 una asociación binaria entre A1 y B. Sea b1 el extremo que conecta be R1 a B. Suponemos que el extremo b1 está declarado como un subsetting del extremo b. Entonces, la restricción general expresada como context A1 inv: self.b = expresión OCL de la regla de derivación de b1 no queda garantizada por el subsetting (véase figura 5.10). + restricción general deducida de la regla de derivación para b1 context A1 inv: self.b1 = expresión OCL de la regla de derivación para b1 + restricción de inclusión context A1 inv: self.b -> includesAll(self.b1) /b1 {subsets b} R b A B A 1 R b A B A 1 + regla de derivación para b1 context A1 :: b1: Set(B) derive: b1 derivation rule b1 R 1 R 1 Fig. 5.11. Traducción del subsetting con el subsetting end derivado Demostración. (1) La traducción del subsetting declarado a nuestra capa básica de UML requiere la restricción de inclusión expresada como context A1 inv: self.b - > includesAll(self.b1) y la restricción general deducida de la regla de derivación para b1: context A 1 inv: self.b1 = expresión OCL de la regla de derivación para b1. La figura 5.11 muestra el diagrama traducido. Nótese que en la traducción, se elimina la indicación de derivación (es decir, la /) y se añade un invariante OCL que sustituye la 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 37 - regla de derivación inicial. Evidentemente, desaparece también la palabra clave subsets y se añade la restricción de inclusión. (2) Suponemos una base de información (BI) donde: (2.1) x es una instancia de B. (2.2) y es una instancia de A y A1. (2.3) y está R-relacionada con x. (3) La BI descrita en (2) satisface todas las restricciones del diagrama traducido descrito en (1), es decir, ésta satisface la restricción textual de inclusión y la restricción deducida de la regla de derivación para b1, junto con las restricciones gráficas definidas sobre el diagrama traducido. (4) La BI descrita en (2) no satisface la restricción general expresada como context A1 inv: self.b = expresión OCL de la regla de derivación de b1 (Nótese que en la restricción general nos referimos al conjunto self.b y en la restricción deducida de la regla de derivación al conjunto self.b1). Según esta restricción general, se deduce que conjunto self.b es igual a self.b1 ya que la regla de derivación es la misma, y por (2) y está R-relacionada con x pero no está R1-relacionada con x. (5) Entonces, por (3) y (4) la restricción general expresada como context A1 inv: self.b = expresión OCL de la regla de derivación de b 1 no queda garantizada por el subsetting. Consideremos el ejemplo de la figura 5.12 en el que se relacionan estudiantes y asignaturas. Además, se ha definido una regla de derivación que calcula las asignaturas, en las que un estudiante con M.H podría matricularse de forma gratuita. Matricula MatriculaGratis Estudiante EstMH /easignatura {subsets asignatura} asignatura Asignatura créditos + regla de derivación para easignatura context EstMH :: easignatura: Set(Asignatura) derive: self.asignatura->select(créditos>=9) Fig. 5.12. Ejemplo de subsetting con el subsetting end derivado Para este ejemplo, la restricción general deducida de la regla de derivación para easignatura, se expresa como context EstMH inv: self.asignatura = self.asignatura -> select (créditos>=9). Nótese que la parte derecha del ‘=’ corresponde a la regla de derivación para easignatura. Como podemos ver, esta restricción general no queda garantizada por el diagrama. Según esta restricción, un estudiante con M.H solo podría matricularse de asignaturas que tengan nueve o más créditos. Si nos fijamos en la regla de derivación definida, vemos que estas asignaturas corresponderían a las asignaturas en las que un estudiante con M.H puede matricularse gratis. No obstante, el diagrama de la figura no impide que un estudiante con M.H pueda matricularse de asignaturas con menos de nueve créditos. Por tanto, vemos que la restricción general expresada como context EstMH inv: self.asignatura = self.asignatura –> select (créditos>=9) no queda garantizada por el diagrama. 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 38 - La restricción de inclusión queda garantizada por cualquier tipo de redefinición Como vimos en la sección 4, para redefinir una asociación, el extremo opuesto al redefining end debe estar siempre conectado a un descendiente de la clase, a la que está conectado el extremo opuesto al redefined end. Dependiendo del tipo de redefinición, se pueden dar dos casos: el redefining end puede estar conectado a (1) la misma clase del redefined end o (2) a uno de sus descendientes. Por tanto, para demostrar que la restricción de inclusión queda garantizada por cualquier tipo de redefinición, consideramos los dos escenarios descritos en la figura 5.13. El escenario a) corresponde al caso (1) y el escenario b) al caso (2). R b b1 {redefines b} A B R b b1 {redefines b} A B A 1 B 1 a) b) A 1 context A1 inv: self.b->includesAll(self.b1) (garantizada) Fig. 5.13. La restricción de inclusión queda garantizada por cualquier tipo de redefinición Teorema 5.5: La restricción de inclusión queda garantizada por cualquier tipo de redefinición (es decir, redefinición de nombre, redefinición de tipo, redefinición de multiplicidad y la redefinición del tipo de derivación) Sean A y B dos clases, R una asociación binaria entre ellas y A1 una subclase de A. Sea b el extremo de la asociación que conecta R con la clase B. Suponemos que b1 es una redefinición del extremo b y que su extremo opuesto está conectado a A1. Entonces, la restricción de inclusión expresada como context A 1 inv: self.b- >includesAll(self.b1) queda garantizada por la redefinición (véase figura 5.13). Demostración. (1) Distinguimos dos casos: (1.1) el extremo b1 también redefine el nombre del extremo b. Entonces, la traducción de la redefinición a nuestra capa básica de UML sustituye b1 por b en las expresiones OCL y la restricción de inclusión se traduce como context A 1 inv: self.b- >includesAll(self.b). (1.2) el extremo b1 no redefine el nombre, por tanto el nombre b1 es igual a b. Entonces, la restricción de inclusión puede también ser formulada como context A1 inv: self.b->includesAll(self.b). (2) Como self.b contiene todos los elementos de self.b la restricción de inclusión se satisface para la redefinición en ambos casos. Recordemos el diagrama del ejemplo 4.16 de la sección 4, en el que se definen dos redefiniciones de tipo. En la figura 4.17 se muestra su diagrama traducido, junto a las restricciones de participación generadas en dicha traducción. Según estas restricciones, todas las personas que viajen con un billete infantil deben ser niños y todos los billetes con los que viaja un niño deben ser billetes infantiles. Para este ejemplo, las restricciones de inclusión se expresarían de la siguiente manera: context Infantil inv: self.viajero->includesAll(self.nviajero) 5. Subconjunto de Asociaciones en UML: Comparación con la Redefinición de Asociaciones - 39 - context Niño inv: self.billete->includesAll(self.ibillete) Según estas dos restricciones de inclusión, todos los niños que viajan con billetes infantiles deben estar incluidos en las personas que viajan con dichos billetes y todos los billetes infantiles con los que viaja un niño deben estar incluidos en los billetes con los que éste viaja. Partiendo de esto y de las restricciones de participación generadas en la traducción, vemos claramente que las dos restricciones de inclusión quedan garantizadas por el diagrama. - 40 - 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones En las secciones anteriores, se ha explicado la sintaxis y semántica de la redefinición y el subsetting de asociaciones, dos constructores que ofrece UML y que nos permiten definir restricciones de integridad, tales como restricciones de cardinalidad o de inclusión. El refinamiento de asociaciones es un concepto utilizado en algunos lenguajes de modelado (como por ejemplo, Syntropy [CD94]) que, a diferencia de la redefinición o el subsetting de asociaciones, no ofrece el UML. A continuación, se explica la semántica de este concepto a través de su traducción a nuestra capa básica de UML y se compara con la redefinición de asociaciones. 6.1 Refinamiento de una asociación El refinamiento de una asociación binaria R, nos permite definir restricciones de integridad adicionales, cuando alguna de las instancias de las clases que participan en R, es a su vez instancia de otras clases [Oli07]. Existen diferentes tipos de refinamiento, pero nosotros nos centraremos en los dos casos más comunes: el refinamiento de participantes y el refinamiento de cardinalidad. En las siguientes subsecciones se define de manera precisa la semántica de cada uno de estos tipos de refinamiento, así como la notación (o sintaxis concreta) utilizada para su especificación. Dicha notación es la que se propone en [COT01]. Como hemos comentado anteriormente, el refinamiento de asociaciones es un concepto que no ofrece el UML. Así pues, al no disponer del metamodelo de UML, no se explica la sintaxis abstracta para este concepto. 6.1.1 Refinamiento de Participantes La definición del refinamiento de participantes sobre una asociación permite restringir las posibles clases que pueden participar en dicha asociación. A continuación, se muestra la notación y semántica para este tipo de refinamiento. 6.1.1.1 Notación La notación utilizada para definir el refinamiento de participantes es la que se muestra en la figura 6.1. R A A 1 B B 1 b <refines> Fig. 6.1. Notación del refinamiento de participantes La palabra clave refines junto a una flecha discontinua que apunta a R y la flecha que une las clases A1 y B1, indica que se ha definido un refinamiento de participantes sobre la asociación R. Nótese que se ha especificado una dirección en dicho refinamiento utilizando una flecha que une las clases A1 (clase origen) y B1 (clase destino). Esta 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones - 41 - dirección indica que se restringe la participación de la clase A1 en la asociación R, pero no la participación de la clase B. Si no se establece la dirección del refinamiento no es posible saber sobre qué clase se aplica la restricción de participación. Es importante destacar que la flecha que une las clases A1 y B1 no se trata de una nueva asociación, sino la indicación de que se ha realizado un refinamiento de la asociación R. La figura 6.2 muestra un ejemplo de refinamiento de participantes sobre la asociación Participa. Dicho refinamiento restringe la participación de la clase Júnior en dicha asociación, es decir, indica que los empleados júnior solo pueden participar en proyectos que no sean críticos. Participa proyecto Empleado Júnior 1..* Proyecto NoCrítico <refines> Fig. 6.2. Ejemplo de refinamiento de participantes En los ejemplos anteriores, hemos visto el refinamiento de participantes en el caso que existe una única clase origen y destino. No obstante, este tipo de refinamiento también se puede definir en el caso que tengamos un conjunto de clases origen y un conjunto de clases destino. La figura 6.3 muestra la notación para este caso. A … A 1 A n … … B … B 1 B m … … b <refine s > x + R … Fig. 6.3. Notación del refinamiento de participantes con un conjunto de clases origen y destino Nótese que una instancia de la clase A puede ser al mismo tiempo instancia de A1,...,An, subclases que pertenecen o no a generalizaciones/especializaciones diferentes. De manera similar, una instancia de la clase B puede ser al mismo tiempo instancia de B1,…,Bm, subclases que en este caso, suponemos que pertenecen siempre a la misma generalización/especialización. La notación gráfica de la figura 6.3 indica que se ha definido un refinamiento sobre la asociación R. El significado de este refinamiento es que, dada una instancia de la asociación R, que conecta dos instancias de las clases A y B, si la instancia de A es a su vez instancia de todas las subclases A1,…,An, entonces la instancia de B debe ser instancia de alguna de las subclases B1,...,Bm. Por ejemplo, el refinamiento definido en la figura 6.4 indica que los empleados juniors que tienen una posición temporal, sólo pueden participar en proyectos de corta o media duración. 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones - 48 - Para demostrar que el refinamiento de participantes y la redefinición de tipo son semánticamente equivalentes, para el caso descrito en la figura 6.13, traducimos ambos conceptos a nuestra capa básica de UML. La idea es comparar los diagramas traducidos, junto a las restricciones OCL generadas en dicha traducción. La figura 6.14 muestra los diagramas traducidos junto a las restricciones OCL para la figura 6.13. R b B context A inv: self.oclIsTypeOf(A1) implies self.b - >forAll(oclIsTypeOf(B 1 )) A B 1 A 1 R b B context A1 inv: self.b->forAll(oclIsTypeOf(B1)) A 1 B 1 A Refinamiento de participantes Redefinición de tipo Fig. 6.14. Traducción del refinamiento de participantes y la redefinición de tipo de la fig. 6.13 Como podemos observar, en ambos casos, el diagrama traducido es el mismo y las restricciones OCL son equivalentes. Tanto en el refinamiento de participantes como en la redefinición de tipo, las restricciones OCL expresan que una instancia de la subclase A1 sólo puede estar asociada con instancias de B1. Por tanto, podemos afirmar que ambos conceptos son semánticamente equivalentes para el caso descrito en la figura 6.13. 6.2.2 Refinamiento de Restricciones de Cardinalidad Como hemos visto anteriormente, el refinamiento de restricciones de cardinalidad se define a partir de un conjunto de clases origen y una clase destino. Recordemos que en el caso de tener una única clase origen, dicha clase puede ser la clase conectada a la asociación sobre la que se define el refinamiento o alguno(s) de sus descendientes. De manera similar, la clase destino puede ser la clase conectada a la asociación sobre la que se define el refinamiento o un descendiente de ésta. Si combinamos estas posibilidades, obtenemos todos los casos que se pueden expresar con el refinamiento de restricciones de cardinalidad. La tabla 6.2 muestra cuáles de estos casos pueden ser expresados también con la redefinición de asociaciones. Nótese que para referirse al conjunto de clases origen y clase destino se han utilizado los nombres que se muestran en la figura 6.9. Clase(s) origen Una (Ai) Más de una (A1,…, Am) Clase asociada (A) Clase asociada (B) P (redefinición de multiplicidad) O - Clase destino Subclase (Bi) O O O Tabla 6.2. Casos del refinamiento de restricciones de cardinalidad cubiertos por la redefinición Recordemos que según el metamodelo de UML, al definir una redefinición, el extremo opuesto al redefining end, debe estar siempre conectado a una clase que sea descendiente de la clase conectada al extremo opuesto del redefined end. Por este motivo, los casos que se muestran en la tabla 6.2, en los que existe más de una clase 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones - 49 - origen o la clase origen es A, no pueden ser expresados a través de la redefinición de asociaciones. El caso en el que la clase origen es A y la clase destino la B, se puede prescindir del refinamiento y utilizar una restricción de multiplicidad sobre la asociación que une ambas clases. A continuación, analizamos los dos casos que faltan: (1) la clase origen es Ai y la clase B, (2) la clase origen es también Ai pero la clase destino es la subclase Bi. Concretamente, demostramos de manera intuitiva, que para el caso (1), el refinamiento de restricciones de cardinalidad es semánticamente equivalente a la redefinición de multiplicidad y que el caso (2), no puede ser expresado por la redefinición, es decir, el refinamiento de restricciones de cardinalidad y la redefinición no son semánticamente equivalentes. Refinamiento de Restricciones de Cardinalidad versus Redefinición de Multiplicidad A continuación, demostramos que el refinamiento de cardinalidad y la redefinición de multiplicidad son semánticamente equivalentes, para el caso de la tabla 6.2 en el que la clase origen es Ai y la clase destino es B. Para ello, consideramos el escenario descrito en la figura 6.15. Refinamiento de restricciones de cardinalidad Redefinición de multiplicidad R b A B A 1 minb..maxb min..max <refines> b1 {redefines b} R b A B A 1 minb..maxb min..max Fig. 6.15. Refinamiento de restricciones de cardinalidad versus la redefinición de multiplicidad La idea es comparar los diagramas traducidos de ambos conceptos a nuestra capa básica de UML, junto a las restricciones OCL generadas en dicha traducción. La figura 6.16 muestra los diagramas traducidos y las restricciones OCL para la figura 6.15. Refinamiento de restricciones de cardinalidad Redefinición de multiplicidad context A inv: self.oclIsTypeOf(A1) implies self.b->size()>=minb context A inv: self.oclIsTypeOf(A1) implies self.b-> size()<=maxb R b A B A 1 minb..maxb context A1 inv: self.b->size() >= minb context A1 inv: self.b-> size() <= maxb R b A B A 1 minb..maxb Fig. 6.16. Traducción del refinamiento de restricciones cardinalidad y la redefinición de multiplicidad de la fig. 6.15 Como podemos ver en la figura anterior, los diagramas traducidos son iguales y las restricciones OCL equivalentes. En ambos casos, las restricciones expresan que una instancia de la subclase A1 debe estar asociada como mínimo a min y como máximo a max instancias de la clase B. Por tanto, podemos afirmar que el refinamiento de restricciones de cardinalidad y la redefinición de multiplicidad son semánticamente equivalentes, para el caso descrito en la figura 6.15. 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones - 50 - El Refinamiento de Restricciones de Cardinalidad versus Redefinición de Tipo y Multiplicidad A continuación, demostramos que el refinamiento de cardinalidad y la redefinición de tipo y multiplicidad no son semánticamente equivalentes, para el caso de la tabla 6.2 en el que la clase origen es Ai y la clase destino es Bi. Para ello, consideramos el escenario descrito en la figura 6.17. Refinamiento de restricciones de cardinalidad R <refines> A A 1 B B 1 b min..max R b1 {redefines b} A A 1 B B 1 b minb..maxb minb1..maxb1 Redefinición de tipo y multiplicidad Fig. 6.17. Refinamiento de cardinalidad versus redefinición de tipo y multiplicidad Para demostrar que ambos conceptos no son semánticamente equivalentes, comparamos los diagramas traducidos de ambos conceptos y las restricciones OCL generadas en dicha traducción. La figura 6.18 muestra los diagramas traducidos junto a las restricciones OCL para la figura 6.17. Refinamiento de restricciones de cardinalidad R b B context A inv: self.oclIsTypeOf(A1) implies self.b->select (b | b.oclIsTypeOf(B1)) -> size()>=min context A inv: self.oclIsTypeOf(A1) implies self.b->select (b | b.oclIsTypeOf(B1)) -> size()<=max A B 1 A 1 R b B context A1 inv: self.b ->forAll(oclIsTypeOf(B1)) and self.b->size() >= minb1 context A1 inv: self.b ->forAll(oclIsTypeOf(B1)) and self.b->size() <= maxb1 A B 1 A 1 minb..maxb Redefinición de tipo y multiplicidad Fig. 6.18. Traducción del refinamiento de restricciones de cardinalidad y la redefinición de tipo y multiplicidad de la fig. 6.17 Como podemos observar, los diagramas traducidos son iguales. No obstante, vemos que no ocurre lo mismo con las restricciones OCL. En el caso de la redefinición, las restricciones expresan que una instancia de la subclase A1 puede estar asociada a como mínimo minb y como máximo maxb instancias de la clase B1, no pudiendo estar asociada a ninguna instancia de otra subclase de B. En el caso del refinamiento, sí que es posible que una instancia de A1 pueda estar asociada también a instancias de otras subclases de B. Por tanto, podemos afirmar que para el caso descrito en la figura 6.17, el refinamiento de restricciones de cardinalidad no es semánticamente equivalente a la redefinición de tipo y multiplicidad. La figura 6.19 muestra un ejemplo para cada uno de estos conceptos. 6. Refinamiento de Asociaciones: Comparación con la Redefinición de Asociaciones - 51 - Refinamiento de restricciones de cardinalidad Participa <refines> 1..3 ncProyecto {redefines proyecto} Empleado Júnior NoCrítico Proyecto 1..3 Empleado NoCrítico Proyecto Júnior Participa proyecto proyecto 1..* 1..* Redefinición de tipo y multiplicidad Fig. 6.19. Ejemplo de refinamiento de participantes y redefinición de tipo y multiplicidad En el ejemplo de la figura anterior, la redefinición de multiplicidad definida sobre la asociación Participa, indica que un empleado júnior puede participar en como mínimo uno y como máximo tres proyectos no críticos. La redefinición de tipo definida indica además que los empleados juniors sólo pueden participar en proyectos no críticos. Por otro lado, el refinamiento de restricciones de cardinalidad definido sobre la asociación Participa, indica también que un empleado júnior puede participar en como mínimo uno y como máximo tres proyectos no críticos. No obstante, a diferencia del caso del refinamiento, los empleados juniors pueden participar en otros proyectos que no sean críticos. - 52 - 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones Como hemos comentado en la sección anterior, el refinamiento de asociaciones es un concepto que hoy en día no ofrece el UML. El objetivo de esta sección es extender este lenguaje, para incorporar la semántica del refinamiento de asociaciones. De esta manera, se consiguen expresar todos aquellos casos del refinamiento que no quedan cubiertos por la redefinición de asociaciones. Para realizar la extensión de UML, utilizamos un mecanismo que ofrece el propio lenguaje y que se conoce con el nombre de perfil (en inglés, UML Profile). Nuestra propuesta consiste en extender el perfil definido en [CGQ+06], creando dos nuevos estereotipos (uno por cada tipo de refinamiento). La figura 7.1 muestra estos estereotipos. Constraint <<stereotype>> PredefinedConstraint << stereotype>> RefinementOfCardinality minCardinality : String maxCardinality: String Element constrainedElement <<stereotype>> Refinement sourceClasses: Set (String) destinationClasses: Set (String) <<stereotype>> RefinementOfParticipants * Fig. 7.1. Estereotipos para el refinamiento de asociaciones Como podemos ver en la figura anterior, la metaclase Constraint está asociada a un conjunto de elementos llamado constrainedElement, es decir, el conjunto de elementos necesarios para evaluar la restricción (en inglés, constraint). PredefinedConstraint es un estereotipo abstracto de la clase Constraint que define todas las características comunes a todas las restricciones predefinidas. El conjunto de las instancias de este estereotipo es la unión de las instancias de sus subtipos. Nuestra propuesta consiste en crear un nuevo estereotipo abstracto Refinement que a su vez tiene dos subtipos: RefinementOfParticipants y RefinementOfCardinality. En las siguientes subsecciones se explican con más detalle cada uno de estos estereotipos y se muestra la implementación que se ha llevado a cabo para incorporar dichos estereotipos a la herramienta CASE PoseidonUML. 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones - 53 - 7.1 Estereotipos definidos 7.1.1 <<Refinement>> Recordemos que el refinamiento de una asociación R nos permite definir restricciones de integridad adicionales, cuando alguna de las instancias de las clases que participan en R, es a su vez instancia de otras clases. Esta restricción se puede expresar a través del estereotipo Refinement con dos atributos, sourceClasses y destinationClasses, que representan las clases origen y destino que participan en el refinamiento de la asociación. Las restricciones asociadas a este estereotipo son las siguientes: • El constrainedElement debe ser un elemento de tipo AssociationEnd. • Las clases de las sourceClasses no pueden ser disjuntas entre ellas si son de la misma generalización/especialización. 7.1.2 <<RefinementOfParticipants>> El refinamiento de participantes de una asociación R restringe las posibles clases que pueden participar en R. Esta restricción puede ser expresada a través del estereotipo RefinementOfParticipants con los atributos sourceClasses y destinationClasses. La figura 7.2 muestra un ejemplo de uso de este estereotipo. Proyecto proyecto Empleado Júnior Senior <<RefinementOfP articipants>> sourceClasses = {“Junior”} d estinationClasses = {“Corto, Medio”} Corto Medio Largo Participa Fig. 7.2. Ejemplo de uso del estereotipo refinementOfParticipants El estereotipo definido en la figura 7.2, restringe la participación de un Empleado en la asociación Participa. Concretamente, indica que un empleado Júnior sólo puede participar en proyectos de tipo Corto o Medio. Las instancias de este estereotipo tienen que cumplir las siguientes restricciones: • Si el número de clases de sourceClassses es 0 entonces el número de clases de destinationClasses ha de ser más grande que 0. • Si el número de clases de destinationClasses es 0 entonces el número de clases de sourceClasses ha de ser más grande que 0. • Los valores del atributo sourceClasses deben ser clases descendientes de la clase conectada al extremo opuesto al constrainedElement. • Los valores del atributo destinationClasses deben ser clases descendientes (de la misma generalización/especialización) de la clase conectada al constrainedElement. 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones - 54 - 7.1.3 <<RefinementOfCardinality>> Recordemos que el refinamiento de restricciones de cardinalidad de una asociación R, permite definir restricciones de cardinalidad adicionales sobre R. Para ello, es necesario definir nuevas cardinalidades que serán más restrictivas que las cardinalidades de la asociación R. Esta restricción puede expresarse a través del estereotipo RefinementOfCardinality con cuatro atributos, sourceClasses, destinationClasses, minCardinality y maxCardinality. Estos últimos atributos indican los valores mínimo y máximo de las nuevas cardinalidades definidas. La figura 7.3 muestra un ejemplo de uso de este estereotipo. Proyecto proyecto Empleado Júnior Senior <<RefinementOfC ardinality >> sourceClasses = {“Junior, Fijo”} destinationClass = {“Medio”} minCardinality = 1 maxCardinality = 3 Temporal Fijo Corto Medio Largo Participa 1..* Fig. 7.3. Ejemplo de uso del estereotipo refinementOfCardinality El estereotipo definido en la figura 7.3, indica que los empleados juniors que tienen una posición fija, pueden participar en como mínimo uno y como máximo tres proyectos de tipo Medio, pudiendo participar también en proyectos de tipo Corto y Largo. Las instancias de este estereotipo tienen que cumplir las siguientes restricciones: • El número de sourceClasses debe ser más grande que 0. • El número de destinationClasses debe ser igual a 1 y puede ser la clase conectada al constrainedElement o un descendiente de ésta. • Si el número de sourceClasses es 1 entonces dicha clase puede ser la clase conectada al extremo opuesto al constrainedElement o un descendiente de ésta. • No se puede dar el caso que la clase origen sea la clase conectada al extremo opuesto del constrainedElement y la clase destino, la clase conectada al constrainedElement. • Si el número de sourceClasses es más grande que 1 entonces éstas deben ser clases descendientes de la clase conectada al extremo opuesto al constrainedElement. • Las cardinalidades minCardinality y maxCardinality deben ser más restrictivas que las cardinalidades definidas para el constrainedElement. Es decir, minCardinality debe ser mayor o igual a la cardinalidad mínima del constrainedElement y maxCardinality debe ser menor o igual a la cardinalidad máxima del constrainedElement. No se puede dar el caso que minCardinality sea igual a la cardinalidad mínima del constrainedElement y maxCardinality igual a la cardinalidad máxima de éste. 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones - 55 - 7.2 Implementación Los estereotipos que hemos definido para incorporar al UML la semántica del refinamiento de asociaciones han sido implementados en la herramienta CASE PoseidonUML. Esta herramienta ofrece un mecanismo para incorporar nuevas funcionalidades, conocido con el nombre de plugin y cuya programación debe realizarse en Java. Nuestra implementación consiste en extender el plugin creado en [Vil07] con el nombre de PredefinedConstraint. Este plugin, nos permite definir y gestionar una serie de restricciones predefinidas (en inglés, predefined constraints) definidas en dicho trabajo. Concretamente, hemos creado dos nuevos estereotipos, con los que podemos expresar dos nuevas restricciones predefinidas: (1) el refinamiento de participantes, a través del estereotipo RefinementOfParticipants y (2) el refinamiento de restricciones de cardinalidad, con el estereotipo RefinementOfCardinality. La extensión de este plugin se ha realizado para la versión estándar PoseidonUML 6.0. Puede descargarse de http://www.lsi.upc.edu/~cristina/tesiMaster/ PredefinedConstraints.zip y se instala en la herramienta CASE como cualquier otro plugin desarrollado para la herramienta. La figura 7.4 muestra un ejemplo de definición del estereotipo RefinementOfParticipants en PoseidonUML. El diseñador selecciona el extremo de asociación sobre el que desea aplicar el refinamiento y a continuación indica las clases origen y destino que participan en dicho refinamiento. Fig. 7.4. Definición del refinamiento de participantes Una vez definido el refinamiento, el esquema conceptual queda de la siguiente manera: 7. Extensión de UML para incorporar la semántica del Refinamiento de Asociaciones - 56 - Fig. 7.5. Representación gráfica del refinamiento de participantes En el anexo de este trabajo, se encuentra la guía de usuario para el plugin que hemos desarrollado. En ésta, se explica con más detalle cómo utilizar cada uno de los estereotipos implementados. - 57 - 8. Conclusiones y trabajo futuro En este trabajo hemos precisado la semántica de la redefinición de asociaciones en UML, a través de su traducción a nuestra capa básica de UML. Ésta consiste en un subconjunto de elementos básicos de UML con una definición precisa, junto a invariantes OCL. Así mismo, hemos comparado la redefinición de asociaciones con otros conceptos similares como el subsetting o el refinamiento de asociaciones. Traduciendo estos conceptos a nuestra capa básica de UML, hemos podido demostrar que la redefinición de asociaciones es semánticamente diferente al subsetting y el refinamiento de asociaciones. Con el objetivo de incorporar la semántica del refinamiento de asociaciones al UML, hemos realizado una extensión de dicho lenguaje utilizando un perfil de UML (en inglés, UML profile). Concretamente, hemos creado nuevos estereotipos que nos permiten expresar en UML, todos aquellos casos de refinamiento que no quedan cubiertos por la redefinición de asociaciones. Finalmente, hemos implementado dichos estereotipos a través de un plugin para la herramienta CASE PoseidonUML. Como trabajo futuro proponemos realizar una guía de usuario para orientar al diseñador de UML a la hora de definir redefiniciones de asociaciones. Otra propuesta, es comparar la redefinición de asociaciones con otros conceptos similares de UML, como la especialización de asociaciones. Tal y como sucede con el subsetting de asociaciones, el UML no deja claro la diferencia entre la redefinición y la especialización de asociaciones. La comparación de dichos conceptos, contribuiría a entender con mayor precisión la semántica de la redefinición de asociaciones en UML. Anexo: Manual de usuario para el plugin de PoseidonUML - 64 - 2. En la tabla de la pestaña Predefined Constraints se muestran todos los refinamientos definidos para el extremo de la asociación. Seleccionamos uno de ellos y pulsamos el botón Editar (véase figura A.6). Fig. A.6. Edición de refinamientos 3. A continuación, se abre la ventana que se utiliza para introducir los parámetros, con los valores que tiene actualmente el refinamiento. Modificamos los valores que deseamos y pulsamos el botón Ok. El comentario del diagrama de clases y la tabla de la pestaña Predefined Constraints se actualizan con los nuevos valores. A.3 Borrado de refinamientos Los pasos a seguir para borrar un refinamiento existente son los siguientes: 1. Seleccionar el extremo de asociación sobre el que se ha definido el refinamiento que deseamos borrar. 2. En la tabla de la pestaña Predefined Constraints se muestran todos los refinamientos definidos para el extremo de la asociación. Seleccionamos uno de ellos y pulsamos el botón Delete (véase figura A.7). Anexo: Manual de usuario para el plugin de PoseidonUML - 65 - Fig. A.7. Borrado de refinamientos 3. A continuación, se borra el comentario del diagrama de clases y el estereotipo de de la tabla de la pestaña Predefined Constraints.