Implementacin de Asociaciones UML en Java*

Gonzalo Gnova, Carlos Ruiz del Castillo, Juan Llorens

Departamento de Informtica, Universidad Carlos III de Madrid Avda. Universidad 30, 28911 Legans (Madrid), Spain {ggenova, llorens}@inf.uc3m.es, crcu@inicia.es

Resumen. Los lenguajes de programacin orientados a objetos no contienen ni la sintaxis ni la semntica necesarias para expresar directamente las asociaciones. Por tanto, hay que implementar las asociaciones UML mediante una adecuada combinacin de clases, atributos y mtodos. Este artculo presenta algunos principios para la implementacin de asociaciones binarias UML en Java, prestando especial atencin a la multiplicidad, la navegabilidad y visibilidad. Nuestro anlisis ha encontrado algunas paradojas en la especificacin de la visibilidad para las asociaciones bidireccionales. Hemos utilizado estos principios para escribir una serie de plantillas de cdigo que utilizamos en combinacin con una herramienta para generar el cdigo de las asociaciones, que son ledas de un modelo almacenado en formato XMI.

1. Introduccin
Uno de los bloques de construccin claves en el Lenguaje Unificado de Modelado [UML] es el concepto de asociacin. Una asociacin (association) en UML se define como un tipo de relacin (relationship) entre clases1, que representa la relacin semntica entre dos o ms clases que implica conexiones o enlaces (links) entre sus instancias [UML, p. 2-20]2. Como ya ha sido denunciado hace tiempo [Rumbaugh 87], los lenguajes de programacin orientados a objetos expresan bien la clasificacin y la generalizacin, pero no contienen ni sintaxis ni semntica para expresar directamente las asociaciones. Por tanto, hay que implementar las asociaciones mediante una adecuada combinacin de clases, atributos y mtodos [Rumbaugh 96a, Noble 96, Noble 97, Ambler 01]. La idea ms simple consiste en aadir un atributo que almacene los enlaces de la asociacin, y mtodos lectores (accessors) y mutadores (mutators) para manipular los enlaces. Otras tcnicas hacen hincapi en el uso de interfaces de Java para implementar las asociaciones, lo que presenta algunas ventajas [Harrison 00]. Las herramientas CASE a menudo proporcionan algn tipo de generacin de cdigo a partir de los modelos de diseo3, pero limitada a un esqueleto de cdigo que incluye slo

Publicado originalmente como Gonzalo Gnova, Carlos Ruiz del Castillo, Juan Llorens. Mapping UML Associations into Java Code, Journal of Object Technology, 2(5): 135-162, Sep-Oct 2003. 1 En realidad clasificadores. Classifier es una superclase de Class en el metamodelo de UML. 2 La actual propuesta de communityUML al OMG para el desarrollo de UML 2.0 [cUML] sugiere un cambio de terminologa: asociacin en lugar de enlace y tipo de asociacin en lugar de asociacin. Si bien apoyamos este cambio, este artculo vamos a seguir la actual terminologa oficial de UML. 3 Distinguimos aqu entre modelos de anlisis y modelos de diseo. Un modelo de anlisis es una abstraccin del problema (el mundo real tal como es antes de que se construya el sistema propuesto), mientras que un modelo de diseo es una abstraccin de la

2 generalizaciones y clases, con las signaturas de los atributos y los mtodos, pero sin asociaciones4. El programador tiene que escribir manualmente el cdigo para gestionar las asociaciones de modo controlado, de forma que se tengan en cuenta todas las restricciones e invariantes para obtener una implementacin correcta. Habitualmente esto es una tarea repetitiva que podra automatizarse hasta cierto punto. Adems, el nmero de aspectos que el programador tiene que tener en cuenta al escribir el cdigo para las asociaciones es tan grande, que se arriesga continuamente a olvidar algn detalle vital, especialmente cuando se trata de asociaciones mltiples (con multiplicidad mayor que 1) o bidireccionales (navegables en ambas direcciones). Ms an, el cdigo escrito finalmente se encuentra con frecuencia disperso entre el cdigo de las clases participantes, hacindolo ms difcil de mantener. El objetivo de este trabajo es doble. En primer lugar, escribir una serie de plantillas de cdigo que ayuden a los programadores a traducir las asociaciones UML al lenguaje orientado a objetos destino. En este trabajo el lenguaje escogido es Java, aunque los principios que hemos seguido son aplicables a otros lenguajes prximos como C++ o el entorno .NET. En segundo lugar, construir una herramienta que usando estas plantillas genere cdigo para las asociaciones, que sern ledas de un modelo almacenado en formato XMI5. Un tercer objetivo ser posibilitar la ingeniera inversa, es decir, obtener las asociaciones entre clases a partir del anlisis del cdigo que las implementa. Nuestra herramienta no lleva a cabo actualmente esta tarea, aunque es muy sencilla y directa si el cdigo ha sido escrito con nuestras plantillas. Una descripcin completa de las plantillas y herramientas est fuera del alcance de este artculo, pero puede encontrarse en otros lugares [Ruiz 02]. Las asociaciones en UML pueden tener una gran variedad de propiedades (features). El presente trabajo se limita al anlisis e implementacin de las propiedades de multiplicidad, navegabilidad y visibilidad en asociaciones binarias. Excluye, por tanto, algunos tipos ms complejos de asociaciones como asociaciones reflexivas, asociaciones todo/parte (agregaciones y composiciones), asociaciones cualificadas, clases-asociacin, y asociaciones n-arias. Excluye tambin propiedades tales como ordenacin (ordering), modificabilidad (changeability), etc. Las tres Secciones siguientes de este artculo estn dedicadas al estudio de las propiedades de multiplicidad, navegabilidad y visibilidad de las asociaciones, con un anlisis detallado de los posibles problemas y soluciones propuestas. Luego, la Seccin 5 contiene la descripcin de una interfaz uniforme para todos los tipos de asociaciones desde el punto de vista de las clases participantes, tal como son implementadas con nuestras plantillas y herramientas. Finalmente, la Seccin 6 describe brevemente cmo funciona nuestra herramienta.

2. El problema de la multiplicidad
La multiplicidad de una asociacin binaria, situada junto al extremo de la asociacin (el extremo destino), especifica el nmero de instancias destino que pueden estar asociadas a una nica instancia origen a travs de la asociacin en cuestin, en otras palabras, cuntos objetos de una clase (la clase destino) pueden estar asociados con un nico objeto dado de la otra clase (la clase origen) [RM, p. 348; UML, p. 2-23]6. solucin (la construccin interna del sistema propuesto) [Kaindl 99], por tanto la generacin de cdigo slo tiene sentido para los modelos de diseo. 4 Algunas herramientas son una excepcin a esta regla [Fujaba, Rhapsody]. 5 XML Metadata Interchange [XMI], un formato basado en XML diseado para almacenar e intercambiar modelos UML entre distintas herramientas. 6 Otras notaciones invierten la posicin de los valores de multiplicidad, siguiendo el convenio extremo cercano en lugar del convenio extremo lejano, que es el usado en

3 El clsico ejemplo de la Figura 1 ilustra la multiplicidad binaria. Cada instancia de Persona puede trabajar para cero o una instancias de Empresa (0..1), mientras que cada empresa puede estar enlazada a una o ms personas (1..*). Para aquellos lectores menos familiarizados con la notacin de UML, el smbolo (*) significa muchos (nmero ilimitado), y los rangos (1..1) y (0..*) pueden abreviarse respectivamente como (1) y (*).

Persona

1..* trabaja para

0..1

Empresa

Figura 1. Un clsico ejemplo de asociacin binaria con la expresin de multiplicidades

Las posibles multiplicidades en UML incluyen cualquier subconjunto de los enteros no negativos [RM, p. 346], sin estar limitadas slo a un nico intervalo como (2..*), o a una lista de intervalos enteros separados por comas como (1..3, 7..10, 15, 19..*): tambin son vlidas las especificaciones de multiplicidad tales como {nmeros primos} o {cuadrados de enteros positivos}, aunque no hay notacin estndar para ellas. No obstante, en UML, como en otras tcnicas de modelado, las multiplicidades ms habituales son (0..1), (1..1), (0..*) y (1..*). Nuestro anlisis quedar restringido a multiplicidades que puedan expresarse como un nico intervalo entero en la forma (min..max). La restriccin de multiplicidad es un tipo de invariante, es decir, una condicin que debe ser satisfecha por el sistema. Una posible prctica al programar es no comprobar el invariante en todo momento, sino slo cuando lo pida el programador, despus de completar un conjunto de operaciones que se supone dejan el sistema en un estado vlido (una transaccin). Esta prctica es ms eficiente en tiempo de ejecucin, y da al programador ms libertad y responsabilidad en la escritura del cdigo, con el correspondiente riesgo de que se olvide de incluir las necesarias comprobaciones y deje el sistema por descuido en un estado errneo. Por otra parte, pensamos que comprobar las restricciones de multiplicidad no es excesivamente ineficiente en consumo de tiempo, especialmente cuando se compara con el tiempo requerido para gestionar colecciones o sincronizar asociaciones bidireccionales (ver Seccin 3.2). As pues, pensamos que vale la pena hacer todo lo que podamos para descargar al programador, de modo que nuestro primer objetivo ser analizar la posibilidad de realizar comprobaciones automticas para las restricciones de multiplicidad. 2.1. Asociaciones opcionales y obligatorias El valor de la multiplicidad mnima puede ser cualquier entero positivo, aunque los valores ms comunes son 0 y 1. Cuando el valor es 0 decimos que la asociacin es opcional (optional) para la clase en el extremo opuesto (clase Persona en la Figura 1), y decimos que es obligatoria (mandatory) cuando el valor es 1 o mayor (clase Empresa). Las asociaciones opcionales no presentan problemas especiales para la implementacin, pero las obligatorias s. Desde el punto de vista conceptual, un objeto que participa en una asociacin obligatoria tiene que estar enlazado en todo momento con un objeto (o ms) al otro lado de la asociacin, en caso contrario el sistema est en un estado errneo. En el ejemplo de la Figura 1, una instancia de Empresa necesita siempre una instancia de Persona. Por tanto, en el mismo momento en que se crea una instancia de Empresa hay que enlazarla a una instancia de Persona. UML. Est bien establecido que la semntica de ambas convenciones es equivalente para asociaciones binarias, pero difiere sustancialmente cuando se aplican a asociaciones de mayor grado [Song 95, McAllister 98, Castellani 00, Gnova 02, Gnova 03b].

4 Esto puede ocurrir de tres formas distintas: Una instancia de Empresa es creada por una instancia de Persona y enlazada a su creador. Una instancia de Empresa es creada con una instancia de Persona suministrada como parmetro. Una instancia de Empresa es creada y solicita la creacin de una instancia de Persona. El tercer caso plantea problemas adicionales. La creacin de una persona probablemente requerir datos adicionales, como el nombre, la direccin, etc., y no parece muy razonable suministrarlos en la creacin de una empresa. Este problema empeora si Persona tiene otras asociaciones obligatorias, por ejemplo con el pas donde vive: si ste fuera el caso, la creacin de una empresa requerira suministrar datos para crear una persona, un pas, etc. La solucin ms obvia es permitir slo las dos primeras formas de instanciacin. Pero supngase entonces que la asociacin es obligatoria en los dos extremos. Cul de las dos instancias hay que crear primero? No tenemos una eleccin satisfactoria, ya que dejaramos al sistema en un estado errneo hasta que las dos creaciones hayan terminado. Podemos pensar en una creacin atmica de las dos instancias, pero esto vale slo para el caso ms sencillo en el que slo hay dos clases implicadas. Tendremos que definir creaciones atmicas para dos, tres, cualquier nmero de clases? En la destruccin de objetos surgen problemas similares. Imaginemos ahora que no vamos a crear o destruir instancias, sino que vamos a cambiar enlaces entre instancias. Si queremos cambiar la instancia de Empresa que est enlazada con una determinada instancia de Persona, podemos borrar simplemente el enlace con la antigua empresa y aadir un nuevo enlace a la nueva empresa. Esto funciona siempre que la antigua empresa est enlazada con otras instancias de Persona; incluso podemos borrar el enlace y no aadir ninguno, ya que la asociacin es opcional para Persona. Si slo tuviramos una persona enlazada a una empresa determinada, tendramos que suministrar una nueva persona a la empresa antes de borrar el enlace con la antigua persona, pero esto no es ms que el comportamiento especificado (la asociacin es obligatoria para Empresa) y no podemos quejarnos por eso. No obstante, aqu encontramos nuevos problemas. Si la asociacin con Empresa fuera obligatoria tambin para Persona (es decir, multiplicidad 1..1 en lugar de la presente 0..1), la instancia de Persona no podra borrar el antiguo enlace con la empresa y luego aadir el nuevo enlace, ni podra hacerlo en el orden inverso, primero aadir, luego borrar, porque pasara por un estado errneo del sistema. Un cambio atmico de enlaces sera vlido slo para los casos ms sencillos, pero no para casos ms complicados como el siguiente, que es ms bien retorcido (ver Figura 2): consideremos las clases A y B, asociadas con multiplicidad 1..1 en ambos extremos, y las correspondientes instancias a1, a2, b1 y b2. En el estado inicial tenemos los enlaces a1-b1 y a2-b2. En el estado final queremos tener los enlaces a1-b2 y a2-b1. Aunque pudiramos cambiar atmicamente a1-b1 por a1-b2 sin violar la restriccin de multiplicidad para a1, esto dejara a b1 sin ningn enlace y a b2 con dos enlaces hasta que se alcanzase el estado final. Tendramos que llevar a cabo todo el cambio de modo atmico por medio de un trueque atmico implementado en una nica operacin.

1..1 (a)

1..1

a1 : A

b1 : B

a1 : A

b1 : B

a1 : A

b1 : B

a2 : A (b)

b2 : B

a2 : A (c)

b2 : B

a2 : A (d)

b2 : B

Figura 2. Las restricciones de multiplicidad pueden hacer muy difcil el cambio de enlaces entre instancias sin pasar por un estado errneo del sistema: a) diagrama de clases; b) estado inicial; c) estado intermedio errneo; d) estado final deseado

Evidentemente, no podemos definir una nueva operacin para evitar cualquier estado errneo concebible que implique varias instancias. En consecuencia, pensamos que las asociaciones obligatorias plantean problemas insolubles en lo que se refiere a la creacin y destruccin de instancias y enlaces: no podemos conseguir con unas pocas operaciones primitivas que una asociacin obligatoria sea obedecida en todo momento, y no podemos aislar, dentro de operaciones atmicas, los momentos en los que la restriccin no es obedecida. Por tanto, tenemos que relajar las implicaciones de las asociaciones obligatorias para la implementacin, como hacen otros mtodos [Harrison 00]. Nuestra propuesta es la siguiente: no comprobar la restriccin de multiplicidad mnima al modificar los enlaces de la asociacin (mtodos mutadores), sino slo al acceder a los enlaces (mtodos lectores). El programador ser responsable de usar las primitivas de modo consistente, de modo que se alcance cuanto antes un estado vlido del sistema. Por ejemplo, estar permitido crear una empresa sin enlazarla a ninguna persona, y estar permitido borrar todos los enlaces de una empresa con instancias de Persona; pero antes de acceder, con otros fines, a los enlaces de esa instancia particular de Empresa con instancias de Persona, ser necesario restaurarlos a un estado vlido, en caso contrario se obtendr una excepcin de multiplicidad invlida (invalid multiplicity exception), que ser definida en el cdigo que implemente las asociaciones de acuerdo con nuestra propuesta. 2.2. Asociaciones sencillas y mltiples El valor de la multiplicidad mxima en un extremo de asociacin puede ser cualquier entero mayor o igual que 1, aunque los valores ms comunes son 1 y *. Cuando el valor es 1 decimos que la asociacin es sencilla (single) para la clase en el extremo opuesto (clase Persona en la Figura 1), y decimos que es mltiple (multiple) cuando el valor es 2 o mayor (clase Empresa). Las asociaciones sencillas son ms fciles de implementar que las asociaciones mltiples: para almacenar la nica instancia posible de una asociacin sencilla habitualmente empleamos un atributo que tenga como tipo la correspondiente clase destino, pero para almacenar los muchos enlaces potenciales de una asociacin mltiple tenemos que usar algn tipo de coleccin de objetos, tal como las predefinidas en Java Vector, HashSet, etc. En el caso general no podemos usar un array de objetos, porque su tamao queda fijado al instanciarlo. Como las colecciones en Java pueden tener cualquier nmero de elementos, la restriccin de multiplicidad mxima no puede ser establecida en la declaracin de la coleccin en el cdigo Java, de modo que habr que comprobarla en algn otro lugar en tiempo de ejecucin.

6 Necesitamos dos tipos de mtodos mutadores, add (aadir) y remove (borrar), que aceptarn como parmetro un nico objeto o una coleccin. Debido a los problemas con la multiplicidad mnima explicados ms arriba, el mtodo borrador a veces tendr que dejar a la instancia origen en un estado errneo; no podemos evitar esta situacin. El mtodo aadidor, en cambio, nos permite un cierto grado de eleccin. Si intentamos aadir algunos enlaces por encima de la restriccin de multiplicidad mxima, podemos elegir entre rechazar la adicin o llevarla a cabo; en el ltimo caso violamos temporalmente la restriccin hasta que una llamada al mtodo borrador restaure la instancia origen a un estado seguro; el estado errneo slo sera detectado por los mtodos lectores, tal como establecimos en el caso de la multiplicidad mnima. Sin embargo, esto vale slo para asociaciones mltiples implementadas mediante una coleccin; en asociaciones sencillas simplemente no podemos violar la restriccin de multiplicidad mxima: estamos obligados a rechazar la adicin. Si decidimos rechazar la adicin, en cambio, adems de tener un comportamiento asimtrico entre el mtodo borrador y el mtodo aadidor, podemos encontrar problemas de precedencia al invocar el aadidor y el borrador uno detrs de otro. Consideremos la clase Juego asociada con la clase Participante con multiplicidad 2..4 (ver Figura 3), y supongamos que una instancia j1 de Juego est enlazada con dos instancias p1, p2 de Participante. Queremos reemplazar estos dos participantes por cuatro nuevos participantes diferentes, q1, q2, q3, q4. Si ejecutamos primero borrar, luego aadir, obtenemos finalmente lo que queremos; pero si ejecutamos primero aadir, luego borrar, la adicin es rechazada y el borrado deja la instancia de Juego en un estado errneo.

Juego

0..* (a)

2..4

Participante

q1 : Participante

p1 : Participante j1 : Juego p2 : Participante j1 : Juego

q2 : Participante
j1 : Juego

q3 : Participante

q4 : Participante (b) (c)

(d)

Figura 3. Problemas de precedencia al invocar sucesivamente el mtodo aadidor y el mtodo borrador: a) diagrama de clases de la asociacin Juego-Participante; b) estado inicial con participantes p1, p2; c) estado final deseado despus de borrar los participantes p1, p2 y luego aadir los participantes q1, q2, q3, q4; d) estado final incorrecto despus de intentar aadir sin xito los participantes q1, q2, q3, q4 y luego borrar los participantes p1, p2.

Al final hemos preferido rechazar la adicin si viola el mximo permitido, y pedir a los usuarios de los mtodos mutadores que los usen siempre en el orden correcto, primero borrar, luego aadir, de modo que obtengamos un comportamiento anlogo para asociaciones sencillas y mltiples. As pues, el mtodo borrador no comprueba la restriccin de multiplicidad mnima (tal vez dejando vaca una asociacin obligatoria), el

7 mtodo aadidor s comprueba la restriccin de multiplicidad mxima, y el mtodo lector levanta una excepcin si cualquiera de las restricciones no se satisface. Los mtodos lectores de las asociaciones mltiples tienen otra peculiaridad, cuando se comparan con los de las asociaciones sencillas: devuelven una coleccin de objetos, no un nico objeto, y por tanto el tipo del valor de retorno es el de la coleccin, no el de la clase destino. En nuestra implementacin el tipo devuelto es la interfaz Collection de Java, implementada por todas las colecciones estndar. Internamente usamos una coleccin HashSet, que asegura que no hay enlaces duplicados en una asociacin, tal como exige UML [UML, p. 2-19] 7. Finalmente, las colecciones estndar en Java estn especificadas para contener instancias de la clase estndar Object, que es superclase de todas las dems clases en Java. No es posible especializar estas colecciones para que almacenen objetos que pertenezcan slo a una clase determinada8. Esto significa que, si utilizamos un HashSet dentro de Empresa para almacenar los enlaces con Persona, debemos asegurar por nuestra cuenta que nadie pone un enlace a una instancia de otra clase como Perro o Informe (esto podra ocurrir si se pasa como parmetro una coleccin de objetos al mtodo add). As pues, los mtodos mutadores deben realizar una comprobacin de tipos por medio de un moldeado (casting) explcito en tiempo de ejecucin. Si falla la comprobacin de tipos, entonces no se actualiza el enlace a ese objeto, y se levanta una excepcin de molde de clase (class cast exception), predefinida en Java.

3. El problema de la navegabilidad
La direccionalidad o navegabilidad de una asociacin binaria, expresada grficamente mediante una flecha abierta en el extremo de la lnea de la asociacin que conecta las dos clases, especifica la capacidad que tiene una instancia de la clase origen de acceder a las instancias de la clase destino por medio de las instancias de la asociacin (enlaces) que las conectan9. Si la asociacin puede ser recorrida en ambas direcciones, entonces es bidireccional (two-way), en caso contrario es unidireccional (one-way). Un extremo de asociacin navegable, referenciado por su nombre de rol, define un pseudo-atributo de la clase origen, de modo que la instancia origen puede usar el nombre de rol en expresiones, del mismo modo que usa sus propios atributos [RM, p. 354]. Una instancia puede comunicarse (enviando mensajes) con las instancias conectadas en los extremos opuestos navegables, y puede usar referencias a stas como argumentos o valores de respuesta en las comunicaciones [UML, p. 2-114]. De modo similar, si el extremo de asociacin es navegable, la instancia origen puede consultar (query) y actualizar (update) los enlaces que la conectan a las instancias destino. Los ejemplos de la Figura 4 ilustran la navegabilidad. La asociacin Llave-Puerta es unidireccional, lo que quiere decir que una llave puede acceder a la puerta que abre, pero Aunque en otros lugares hemos dado argumentos concluyentes en contra de esta restriccin [Gnova 03b], en la generacin de cdigo hemos respetado la definicin actual de UML. 8 Es decir, no es posible especializarlas para modificar su estructura de almacenamiento, pero s es posible modificar su funcionamiento para que, de hecho, slo almacenen los objetos requeridos, precisamente mediante el mtodo de comprobacin de tipo en tiempo de ejecucin que estamos describiendo. 9 Una definicin alternativa: la posibilidad que tiene un objeto origen de designar un objeto destino a travs de una instancia de asociacin (enlace), con el fin de manipularlo o acceder a l en una interaccin con intercambio de mensajes. El Estndar no contiene una definicin clara de navegabilidad, como hemos mostrado en trabajos anteriores donde hemos intentado aclarar este tema [Gnova 01, Gnova 03a, Gnova 03b]. En este artculo tomamos navegabilidad y direccionalidad como sinnimos.
7

8 una instancia de Puerta no conoce el conjunto de instancias de Llave que la abren: la puerta no puede recorrer las conexiones o enlaces en contra de la navegabilidad de la asociacin. Por otra parte, la asociacin Hombre-Mujer es bidireccional, lo que quiere decir que las instancias conectadas de estas clases se conocen mutuamente.

Llave

0..* abrir (a)

1..1

Puerta

Hombre

0..1 esposo (b)

0..1 esposa

Mujer

Figura 4. Ejemplos de a) asociacin unidireccional y b) asociacin bidireccional

Las puntas de flecha pueden mostrarse u omitirse en una asociacin bidireccional [UML, p. 3-73]. Desafortunadamente, esto conduce a una ambigedad en la notacin grfica, porque no podemos distinguir entre asociaciones bidireccionales y asociaciones sin navegabilidad especificada. O, peor an, se asume que las asociaciones sin navegabilidad especificada son bidireccionales sin posterior anlisis. 3.1. Asociaciones unidireccionales Una asociacin unidireccional sencilla es muy similar a un atributo de valor nico (single valued attribute) en la clase origen, del tipo de la clase destino: una referencia incrustada, puntero, o como quiera denominrselo. La equivalencia, no obstante, no es completa. Mientras que el valor del atributo es posedo por la instancia de la clase y no tiene identidad, un objeto externo referenciado tiene identidad y puede ser compartido por instancias de otras clases que tengan referencias a ese mismo objeto [Rumbaugh 96b] (ver Figura 5). En todo caso, la equivalencia es suficientemente satisfactoria como para servir de base para la implementacin de este tipo de asociaciones. En realidad, en Java no hay ninguna diferencia: excepto en el caso de los valores primitivos, los atributos en Java son objetos con identidad, y si son pblicos no se puede evitar que sean referenciados y compartidos por otros objetos.
Persona nacimiento: Fecha (a)

Persona

0..1 nacimiento

Fecha (b)

1..1 publicacin

Libro

Figura 5. Equivalencia parcial entre a) atributo y b) asociacin unidireccional sencilla

9 Una asociacin unidireccional mltiple es algo ms complicada, aunque la implementacin puede basarse en los mismos principios, ya que puede asimilarse a un atributo multivaluado (multivalued attribute)10. Sin embargo, para gestionar la coleccin de objetos en el extremo navegable necesitamos un objeto adicional de una clase coleccin estndar, que en nuestra implementacin es la clase HashSet (ver Figura 6).

Receta

1..* Alimento ingrediente (a)

Receta

Alimento

1..1

ingrediente 1..* element (b) Object

HashSet

Figura 6. Asociacin unidireccional mltiple: a) diagrama de anlisis y b) diagrama de diseo. Es necesario insertar un nuevo objeto para gestionar la coleccin de objetos destino. Las colecciones estndar en Java, tales como HashSet, estn definidas para la clase estndar Object, que es superclase de todas las clases; por tanto, los mtodos mutadores deben asegurar que los objetos contenidos en el parmetro coleccin son del tipo apropiado antes de aadirlos al atributo coleccin.

As pues, el tipo del atributo usado para implementar la asociacin dentro de la clase origen ya no es la clase destino misma, sino la clase HashSet u otra clase coleccin conveniente. Los mtodos para gestionar la asociacin tendrn que llevar al cabo algunas tareas adicionales. Los mtodos mutadores pueden aadir o borrar no slo objetos singulares de la clase destino, sino tambin enteras colecciones; as, el tipo del parmetro ser o bien la clase destino de la asociacin o bien la clase coleccin intermedia. En este caso, los mtodos mutadores deben asegurar que los objetos contenidos en el parmetro coleccin son del tipo apropiado antes de aadirlos al atributo coleccin. Los mtodos lectores, como ya hemos explicado (ver Seccin 2), no devuelven un objeto singular, sino una coleccin de objetos, aunque est formada por un solo elemento. El objeto coleccin devuelto no es idnticamente el mismo que el que est almacenado dentro de la clase origen, sino un clon (un nuevo objeto con una coleccin de referencias a los mismos elementos destino), porque el objeto coleccin original debe permanecer completamente encapsulado dentro del objeto origen (esto se representa como una composicin en la Figura 6). Como muestran los diagramas de las Figuras 4 y 5, en nuestra opinin la restriccin de multiplicidad en un diagrama de diseo slo puede especificarse en el extremo de

UML permite la multiplicidad en atributos, y por tanto los atributos multivaluados [UML, p. 2-50].

10

10 asociacin navegable11. En efecto, la multiplicidad es una restriccin que debe ser evaluada en el contexto de la clase que posee el extremo de la asociacin; si esta clase conoce la restriccin, entonces conoce el extremo de asociacin, es decir, el extremo es navegable. No se puede restringir el nmero de objetos conectados a una instancia dada a menos que esta instancia tenga algn conocimiento de los objetos conectados, es decir, a menos que se haga navegable el extremo de asociacin. Por tanto, la necesidad de una restriccin de multiplicidad distinta de 0..* (es decir, no restringida) es una indicacin de que el extremo de asociacin debe ser navegable. En consecuencia, las asociaciones unidireccionales con restricciones de multiplicidad en el extremo de asociacin no navegable deben ser rechazadas en la generacin de cdigo. 3.2. Asociaciones bidireccionales La equivalencia parcial entre atributos y asociaciones unidireccionales ya no la encontramos entre las asociaciones bidireccionales. En su lugar, una instancia de una asociacin bidireccional es ms parecida a una tupla de elementos [UML, p. 2-19]. Combinando las multiplicidades en ambos extremos de asociacin, podemos tener tres casos: sencilla-sencilla, sencilla-mltiple, y mltiple-mltiple. Una forma fcil de implementar una asociacin bidireccional sencilla-sencilla es por medio de dos asociaciones unidireccionales sencillas sincronizadas (ver Figura 7). La sincronizacin de las dos mitades debe ser preservada por los mtodos mutadores en cada lado: cada vez que se solicita una actualizacin en un lado, el otro lado debe ser informado para realizar la correspondiente actualizacin; sta es llevada a cabo slo si ambos lados estn de acuerdo en que pueden ejecutarla manteniendo las restricciones de multiplicidad mxima12 (ver Figura 8).

Hombre

0..1 esposo (a)

0..1 esposa

Mujer

esposa 0..1 Hombre 0..1 esposo (b) {sincronizado} Mujer

Figura 7. Asociacin bidireccional sencilla-sencilla: a) diagrama de anlisis y b) diagrama de diseo. La implementacin de los mtodos mutadores de la asociacin debe asegurar que el esposo de la esposa de un cierto hombre es ese hombre mismo, y viceversa

Este principio no es aplicable a los modelos de anlisis, que habitualmente no tratan con la navegabilidad [Fowler 97, Stevens 00]. Evidentemente, la generacin de cdigo slo tiene sentido a partir de diagramas de diseo. 12 Ya hemos justificado en la Seccin 2 que debe permitirse a los mtodos mutadores que violen la restriccin de multiplicidad mnima.

11

11

Mara : Mujer : Oficial resultado:= add(Juan)

Juan : Hombre

[esposo=null]: resultado:= add(self) [esposa=null] : esposa=Mara [resultado=ok]: esposo=Juan

Figura 8. Diagrama de secuencia que ilustra la sincronizacin de una asociacin bidireccional. La actualizacin del atributo Mujer.esposo a Juan (ltima operacin) slo tiene lugar despus de que la actualizacin del atributo Hombre.esposa ha sido correctamente realizada. Si la mujer ya estuviera casada, entonces no solicitara al hombre que actualizara la asociacin de matrimonio en su lado; si la actualizacin en el lado del hombre falla (porque ya est casado), entonces la mujer no actualiza su lado. Para lograr este comportamiento, el mtodo add devuelve un resultado conveniente que es comprobado por el objeto cliente

Una asociacin bidireccional sencilla-mltiple puede implementarse de modo similar, combinando una asociacin unidireccional sencilla con una asociacin unidireccional mltiple. Y, finalmente, una asociacin bidireccional mltiple-mltiple se consigue mediante dos asociaciones unidireccionales mltiples (ver Figura 9).

Persona

1..3 autor

0..10 publicacin (a)

Libro

1..1 HashSet publicacin

0..10 element

Object

Persona

{sincronizado}

Libro

Object

1..3 element (b)

HashSet

1..1 autor

Figura 9. Asociacin bidireccional mltiple-mltiple: a) diagrama de anlisis y b) diagrama de diseo

La sincronizacin se vuelve progresivamente ms complicada cuando uno o dos de los extremos de asociacin es mltiple. Consideremos el ejemplo de la Figura 9. Supongamos que queremos aadir un autor a cierta instancia de Libro; para ello invocamos el mtodo

12 add en la instancia de Libro, pasando una instancia de Persona como parmetro. Si el libro puede tener ms autores sin violar su multiplicidad mxima (que es 3), entonces solicita al autor que aada el libro mismo a la coleccin de publicaciones de la persona; esto puede fallar si la restriccin de multiplicidad mxima para el nmero de publicaciones (en este caso, 10) es violada. Si la solicitud al autor tiene xito, entonces el libro actualiza su lado. Ahora bien, podemos intentar tambin aadir una coleccin de autores a un libro. Como podramos esperar, el libro solicita a cada uno de los autores que aada el libro mismo como publicacin; si cualquiera de los autores falla en aadir el libro, entonces toda la operacin debe ser deshecha, ya que una actualizacin debe ser atmica: todo o nada. Consideraciones similares afectan al mtodo mutador remove, teniendo en cuenta que ste es ejecutado aunque la restriccin de multiplicidad mnima no sea satisfecha, y por tanto puede dejar a la instancia origen o alguna de las instancias destino afectadas en un estado invlido. En UML una asociacin se define como un conjunto de tuplas [UML, p. 2-19], lo que quiere decir que no podemos tener dos veces la misma tupla en la coleccin de enlaces de una asociacin13. Esto queda automticamente salvaguardado si seguimos el esquema de implementacin explicado ms arriba. En todo caso, tambin sugiere un tipo diferente de implementacin que podra tener algunas ventajas. En lugar de sincronizar dos asociaciones unidireccionales para obtener una bidireccional, podemos almacenar directamente la coleccin de enlaces bidireccionales (ver Figura 10).

Persona 1..1 autor

1..1 1..1 singleton asociacinPL AsociacinPersonaLibro asociacinPL

Libro

publicacin 1..1 tupla 0..*

EnlacePersonaLibro

Figura 10. Un esquema alternativo para implementar asociaciones bidireccionales por medio de una coleccin de tuplas cosificadas

En este esquema alternativo los enlaces estn cosificados y se transforman en objetos en s mismos [Rumbaugh 87]. Para gestionar la coleccin de enlaces, o tuplas, necesitamos un objeto, que sea la nica instancia de una clase (aplicando el patrn de diseo Singleton [Gamma 94]) y que representa a la asociacin misma. La principal ventaja de este enfoque es que evita la dispersin de la informacin acerca de las instancias de la asociacin (enlaces), de modo que las actualizaciones se efectan en un nico sitio, sin problemas de sincronizacin. Se puede extender fcilmente para implementar clases-asociacin y asociaciones de mayor grado (ternarias, etc.). Sin embargo, estas ventajas tienen un alto coste, como podemos apreciar comparando las Figuras 9 y 10. En primer lugar, ntese que las restricciones de multiplicidad originales no estn expresadas en este esquema: la multiplicidad de los roles Persona.asociacinPL y Libro.asociacinPL deben ser obviamente 1..1, ya que slo hay una instancia del objeto que gestiona la asociacin considerada como coleccin de enlaces; adems, un enlace es la conexin de dos instancias, por tanto un enlace tiene exactamente una pata en La conveniencia de esta restriccin, heredada del Modelo Entidad-Relacin, es discutida por muchos autores [Genilloud 99, Stevens 02, Gnova 03b].
13

13 cada lado [Gnova 02, Gnova 03b], es decir, las multiplicidades deben ser 1..1 en los roles autor y publicacin; finalmente, el rol tupla tiene multiplicidad 0..* sea cual sea la multiplicidad de la asociacin original, aunque fuera sencilla-sencilla, porque almacena todos los enlaces que pueden existir entre cualesquiera dos instancias en cada lado. En consecuencia, las restricciones de multiplicidad resultan ms difciles de mantener, puesto que el control no puede consistir simplemente en contar enlaces. Otro problema que encontramos es que la unicidad de cada tupla, exigida por la restriccin conjunto de tuplas, no queda automticamente salvaguardada. Supongamos que implementamos la coleccin de tuplas mediante un HashSet de objetos, donde cada objeto almacena dos referencias, autor y publicacin. Como cada objeto tupla tiene su propia identidad, dos tuplas diferentes que referencien los mismos dos objetos destino seran consideradas como objetos diferentes, de modo que la coleccin HashSet no comprobara por nosotros la unicidad de cada tupla14. Considerando todos estos factores, en nuestra implementacin hemos descartado el enfoque de tuplas cosificadas en favor del anterior esquema de referencias cruzadas sincronizadas.

4. El problema de la visibilidad
Hasta ahora hemos tratado slo con la implementacin en Java de dos propiedades de las asociaciones UML: multiplicidad y navegabilidad (direccionalidad), pero tambin estamos interesados en la implementacin de la visibilidad. De acuerdo con el Estndar [UML, p. 2-23], la visibilidad de un extremo de asociacin especifica la visibilidad del extremo de asociacin desde el punto de vista del clasificador en el otro extremo. El Estndar asimila la visibilidad de un extremo de asociacin a la visibilidad de un atributo, y da las mismas cuatro posibilidades: public - otros clasificadores pueden navegar la asociacin y usar el nombre de rol en expresiones, de modo similar al uso de un atributo pblico. protected - los descendientes del clasificador origen pueden navegar la asociacin y usar el nombre de rol en expresiones, de modo similar al uso de un atributo protegido. private - slo el clasificador origen puede navegar la asociacin y usar el nombre de rol en expresiones, de modo similar al uso de un atributo privado. package - los clasificadores que estn en el mismo paquete (o paquete anidado, hasta cualquier nivel) que la declaracin de la asociacin pueden navegar la asociacin y usar el nombre de rol en expresiones15. En Java encontramos los mismos cuatro tipos de visibilidad para atributos y mtodos (no es casualidad, por supuesto), denominados niveles de control de acceso (access control levels) [Gosling 96, Arnold 00], aunque su significado no es exactamente el mismo que en

En todo caso, no es una dificultad insalvable. Para que dos tuplas iguales sean reconocidas como tales y as garantizar su unicidad, es necesario redefinir los mtodos equals y hashCode, heredados de la clase Object, y empleados por la coleccin HashSet con este fin [Eckel 00]. 15 Este ltimo tipo de visibilidad, aadido en la versin 1.4 del Estndar, est definida de modo ambiguo, puesto que podra declararse una asociacin entre clasificadores de dos paquetes diferentes. Entonces, a qu paquete pertenece la declaracin de la asociacin? Sugerimos esta otra redaccin (adiciones en cursiva): Los clasificadores que estn en el mismo paquete (o paquete anidado, hasta cualquier nivel) que el clasificador origen pueden navegar la asociacin y usar el nombre de rol en expresiones, de modo similar al uso de un atributo con visibilidad de paquete.

14

14 UML16. La opcin por defecto, obtenida cuando no se especifica el control de acceso, es la visibilidad de paquete (habitualmente conocida en Java como friendly). Como hemos implementado las asociaciones UML mediante atributos y mtodos Java, parece que no deberamos encontrar especiales problemas con la implementacin de la visibilidad17; al contrario, debera ser ms bien fcil. Esto es verdad para asociaciones unidireccionales: si declaramos los atributos y mtodos Java con el mismo control de acceso que el extremo de asociacin UML que queremos implementar, automticamente obtenemos el comportamiento deseado. Pero la historia es diferente para asociaciones bidireccionales. En principio, parece razonable declarar privado uno o dos de los extremos de una asociacin binaria. Podemos pensar en una asociacin con dos extremos privados como una relacin secreta que no es conocida fuera de las clases participantes, tal como una asociacin Banco-Cliente, por ejemplo. De modo similar, una asociacin con un extremo pblico y otro privado sera slo parcialmente conocida desde el exterior. Pero hay problemas. Consideremos la asociacin bidireccional Profesor-Materia con visibilidades pblica y privada (ver Figura 11).

Profesor

0..* +profesor

0..* -materia

Materia

Figura 11. Una asociacin bidireccional con un extremo de asociacin pblico y otro privado

El extremo de asociacin pblico, profesor, puede ser usado por cualquier otra clase en el modelo que tenga visibilidad hacia la clase Materia, es decir, la coleccin de profesores que ensean una determinada materia puede ser consultada y actualizada directamente por cualquier clase en el modelo que vea la materia. En cambio, el extremo de asociacin privado, materia, que significa la coleccin de materias que ensea un determinado profesor, es conocido slo por el profesor mismo, exactamente igual que un atributo privado. La clase Profesor podra declarar pblicos otros mtodos que internamente se refirieran al nombre de rol materia, proporcionando de esta manera acceso indirecto al extremo de asociacin privado, pero el acceso directo est restringido a la clase poseedora misma. Esto no es ms que la idea de declarar privada alguna cosa. Ahora bien, aqu tenemos una paradoja en relacin con la bidireccionalidad de la asociacin. El extremo de asociacin con el nombre de rol privado materia slo es conocido por su poseedor, es decir, la clase Profesor. Repetimos, slo por su poseedor. Esto significa que la clase Materia no conoce el extremo de asociacin materia! La clase Materia conoce que est asociada con la clase Profesor, pero no conoce que la clase Profesor est a su vez asociada con ella. Es esto realmente una asociacin bidireccional? En nuestra implementacin, basada en referencias cruzadas sincronizadas como hemos explicado ms arriba, esta paradoja se manifiesta en la imposibilidad de actualizacin recproca de los extremos de asociacin. Recurdese que, cuando una instancia de Materia intenta aadir una instancia nuevoProfesor de Profesor a su coleccin de El control de acceso protected significa en Java la unin de las visibilidades protected y package de UML, es decir, el elemento protegido es accesible tanto a los descendientes como a otros elementos del mismo paquete [Arnold 00, Eckel 00, Gosling 96]. 17 Salvo que el significado de protected ser el de Java, no el de UML. El Estndar reconoce que todas las formas de visibilidad no pblica son de hecho dependientes de la implementacin [UML, p. 3-42].
16

15 profesores (profesor.add(nuevoProfesor)), primero tiene que invocar el mtodo add en el lado recproco (profesor.materia.add(self)) 18; pero esto ahora resulta imposible debido a la visibilidad privada del extremo de asociacin materia. Lo mismo ocurre con el mtodo remove. Por el contrario, si una instancia de Profesor intenta actualizar la asociacin, puede invocar el mtodo de actualizacin en el lado opuesto, porque es pblico, y puede actualizar su propio lado privado, de modo que toda la operacin tiene xito. A primera vista, pues, pareca que la asociacin poda ser gestionada a travs de la clase poseedora del extremo de asociacin pblico (en este caso, la clase Materia), pero esto ha resultado ser falso: en realidad, slo la clase que posee el extremo de asociacin privado (Profesor) puede gestionar la asociacin, y el acceso directo desde fuera de las dos clases participantes es imposible. No obstante, como hemos explicado ms arriba, la clase Profesor podra declarar mtodos pblicos para proporcionar acceso indirecto al extremo de asociacin privado desde el exterior. An peor, si ambos extremos de asociacin fueran privados, como en el ejemplo Banco-Cliente, la asociacin resultara inaccesible desde ambos lados19. El enfoque basado en tuplas cosificadas tampoco soluciona el problema, ya que implica clases auxiliares que no pueden proporcionar acceso privado a las clases principales, excluyendo a todas las dems clases. Resumiendo, una asociacin bidireccional pblica-privada puede ser gestionada slo desde la clase que posee el extremo privado, y todas las dems clases, incluyendo la clase al otro extremo de la asociacin, slo pueden tener acceso indirecto si esta clase proporciona los mtodos pblicos adecuados. Una asociacin bidireccional privada-privada, por el contrario, no puede ser gestionada de ninguna manera. Se pueden hacer consideraciones similares para las visibilidades de paquete y protegida, que se comportan a estos efectos respectivamente como las visibilidades pblica y privada. En consecuencia, las asociaciones bidireccionales con visibilidad distinta de public o package en ambos extremos deben ser rechazadas en la generacin de cdigo. Pensamos que este resultado no slo est influenciado por nuestra particular implementacin, sino que se trata de una dificultad semntica real de la definicin de visibilidad en asociaciones bidireccionales. La visibilidad en UML no se especifica para asociaciones sino para extremos de asociacin, y est asimilada a la visibilidad de los atributos [UML, p. 2-23]. Necesitamos en UML una definicin de visibilidad que encaje mejor con el concepto de asociacin bidireccional.

5. Una interfaz uniforme

El cdigo requerido para implementar una asociacin UML consiste bsicamente en una adecuada combinacin de atributos y mtodos Java, pero esta combinacin depende de la multiplicidad, navegabilidad y visibilidad de la asociacin. Con respecto a la multiplicidad, para almacenar la nica instancia posible de una asociacin sencilla podemos emplear un atributo de la correspondiente clase destino, pero para almacenar los muchos enlaces potenciales de una asociacin mltiple necesitamos algn tipo de coleccin de objetos: hemos elegido HashSet, porque asegura que no hay objetos duplicados en la coleccin. Con respecto a la navegabilidad, una asociacin unidireccional se implementa slo en la clase origen, mientras que una asociacin bidireccional se implementa en las dos clases, con cdigo que asegura la sincronizacin de ambos extremos. La visibilidad de los extremos de asociacin se traduce directamente en la visibilidad de los mtodos requeridos; Un objeto se refiere a s mismo en UML/OCL mediante la palabra clave self; el equivalente en Java es this. 19 Una asociacin reflexiva (una asociacin entre instancias de la misma clase) es una excepcin a esta regla, ya que los extremos de asociacin privados son visibles dentro de la clase, es decir, para ambos lados de la asociacin.
18

16 los atributos, en cambio, sern siempre privados, para mantener el acceso controlado a travs de los mtodos de la interfaz. Hemos diseado una interfaz uniforme para todo tipo de asociaciones, es decir, una interfaz tan independiente como sea posible de la multiplicidad, navegabilidad y visibilidad de los extremos de asociacin. La interfaz comprende mtodos lectores y mutadores, as como otros mtodos auxiliares para averiguar el estado y definicin de la asociacin. Nuestra intencin es que el cdigo cliente pueda usar la interfaz de la asociacin sin conocer a priori, cuando sea posible, de qu tipo de asociacin se trata; esto har el cdigo cliente mucho ms estable frente a cambios en el diseo (por ejemplo, una asociacin unidireccional que se transforma en bidireccional). En realidad la implementacin de asociaciones unidireccionales y bidireccionales es diferente, porque slo las bidireccionales tienen que estar sincronizadas, pero ambos tipos presentan exactamente la misma interfaz en cada extremo. Por el contrario, las asociaciones sencillas y mltiples no slo tienen implementaciones diferentes, sino tambin una interfaz ligeramente distinta, porque las asociaciones sencillas no manejan colecciones de objetos como parmetros o valores de retorno. Podramos tratar las asociaciones sencillas como un caso particular de las asociaciones mltiples y no proporcionar ninguna implementacin o interfaz especiales para ellas, pero consideramos que se usan con tanta frecuencia que los beneficios en eficiencia son proporcionados a las prdidas en uniformidad de interfaz. El los prrafos que siguen, %Target significa el nombre de la clase destino en la asociacin, que tendr que ser sustituido por su nombre real cuando el cdigo sea generado para cada asociacin en el modelo de diseo. La clase origen de una asociacin unidireccional presenta una interfaz para consultar y actualizar el extremo de asociacin opuesto; la clase destino no presenta ninguna interfaz, porque no tiene conocimiento de la asociacin. Por el contrario, los dos lados de una asociacin bidireccional presentan una interfaz; en este caso los trminos origen y destino son relativos a la clase que est viendo el extremo de asociacin opuesto. 5.1. Mtodos lectores Tenemos dos mtodos lectores, test y get, con las signaturas siguientes: boolean test(%Target query_link); boolean test(Collection query_links); %Target get(); Collection get(); El mtodo test comprueba si una instancia dada de la clase destino (el parmetro query_link) est enlazada con la instancia de la clase origen que recibe la invocacin del mtodo. La segunda versin de este mtodo se define slo cuando el extremo de asociacin es mltiple; en este caso el mtodo comprueba si todas las instancias contenidas en el parmetro coleccin estn enlazadas con la instancia origen20. El mtodo get devuelve las instancias destino que estn enlazadas con la instancia origen. La primera versin es para un extremo de asociacin sencillo y devuelve un valor nico cuyo tipo es la clase destino, mientras que la segunda versin es para un extremo de asociacin mltiple, y por tanto devuelve un valor de tipo Collection. De acuerdo con la justificacin dada ms arriba al tratar con los problemas de la multiplicidad, los mtodos mutadores garantizan que la multiplicidad mxima no es violada, pero en cuanto a la multiplicidad mnima, puede ocurrir que el nmero de instancias enlazadas sea menor que

El parmetro se define de tipo Collection para tener mayor generalidad. Collection es una abstraccin de los conceptos de lista (list), conjunto (set) y correspondencia (map). Tcnicamente, es una interfaz realizada por clases de librera tales como Vector (obsoleta), ArrayList, HashSet, TreeMap y otras.

20

17 el mnimo requerido por el diseo, en cuyo caso se levanta la excepcin de multiplicidad invlida21. 5.2. Mtodos mutadores Tenemos tambin dos mtodos mutadores, remove y add, con las signaturas siguientes: int remove(); int remove(%Target old_link); int remove(Collection old_links); boolean add(%Target new_link); boolean add(Collection new_links); El mtodo remove borra las instancias destino del extremo de asociacin opuesto, y devuelve un cdigo de error conveniente. Puede borrar todas las instancias (primera versin sin parmetros), una instancia (segunda versin), o una coleccin de instancias (tercera versin, disponible slo cuando el extremo de asociacin opuesto es mltiple). En la tercera versin, si cualquiera de las instancias en el parmetro coleccin no es de tipo %Target, entonces no se borra ningn enlace, siguiendo la semntica de todo o nada, y se levanta una excepcin de molde de clase (class cast exception). Por el contrario, si alguna de las instancias de la coleccin (o la nica instancia, en la segunda versin del mtodo) simplemente no est enlazada a la instancia origen, entonces la operacin prosigue sin considerarlo un error. En una asociacin bidireccional el mtodo invoca un remove recproco en cada una de las instancias que hay que borrar. El mtodo remove puede dejar la instancia origen o alguna de las instancias destino en un estado invlido respecto a las restricciones de multiplicidad mnima, en cuyo caso se devuelve un cdigo de error, pero no se levanta ninguna excepcin. Si a continuacin se invocara el mtodo get, se levantara la excepcin de multiplicidad invlida. El mtodo add aade una nueva instancia o coleccin de instancias destino en el extremo de asociacin opuesto, y devuelve un valor boolean para indicar si la operacin fue ejecutada o no. La segunda versin de este mtodo se define slo cuando el extremo de asociacin es mltiple; si cualquier instancia del parmetro coleccin no es de tipo %Target, entonces no se aade ningn enlace, siguiendo la semntica de todo o nada y se levanta una excepcin de molde de clase (class cast exception). Por el contrario, si alguna de las instancias de la coleccin (o la nica instancia, en la primera versin del mtodo) ya est enlazada a la instancia origen, entonces la operacin prosigue sin considerarlo un error (y, por supuesto, sin aadir un duplicado). En una asociacin bidireccional, el mtodo invoca un add recproco en cada una de las instancias que hay que aadir. El mtodo add comprueba si la instancia origen, o alguna de las instancias destino, sera dejada en un estado invlido respecto a las restricciones de multiplicidad mxima, en cuyo caso la operacin es cancelada, no se aade ningn enlace, y se devuelve un valor False22. Si se desea sustituir algunas instancias destino por otras instancias destino, hay que invocar primero el mtodo remove y luego el mtodo add; en caso contrario el resultado podra ser diferente del esperado (ver Seccin 2). Atencin, esto vale incluso para asociaciones sencillas: no hay ningn remove implcito de la instancia antigua cuando se De hecho, la comprobacin la lleva a cabo el mtodo isValid, que puede ser algo ms elaborado que simplemente verificar que el nmero de instancias enlazadas no es menor que el mnimo requerido; el programador puede modificar manualmente el cdigo de isValid para implementar una restriccin ms compleja. 22 Como en el caso anterior, la comprobacin es ejecutada por el mtodo isValid, que puede conseguir un comportamiento ms general.
21

18 aade una nueva (se hace as para obtener un comportamiento lo ms parecido posible entre asociaciones sencillas y mltiples). 5.3. Mtodos auxiliares para averiguar el estado de la asociacin Tenemos dos mtodos auxiliares para conocer el estado de la asociacin desde el punto de vista de una instancia origen particular: boolean isValid(); long numberOfLinks(); El mtodo isValid determina si la instancia origen ve el nmero correcto de instancias destino en el lado opuesto de la asociacin, de acuerdo con las restricciones de multiplicidad especificadas en el modelo de diseo. La herramienta genera cdigo slo para el caso ms sencillo, cuando la restriccin de multiplicidad consiste en un nico intervalo MIN..MAX. En todo caso, el programador puede modificar manualmente el cdigo para implementar una restriccin ms compleja, y los cambios afectarn a la ejecucin de los mtodos lectores y mutadores, ya que ellos comprueban las restricciones de multiplicidad por medio de este mtodo. Este mtodo tambin es til cuando la comprobacin automtica de las restricciones de multiplicidad est desactivada y el programador asume la responsabilidad de comprobarlas manualmente en puntos especficos del cdigo fuente. El mtodo numberOfLinks devuelve el nmero de instancias destino enlazadas a la instancia origen. 5.4. Mtodos auxiliares para averiguar la definicin de la asociacin Tenemos cinco mtodos auxiliares para conocer la definicin de la asociacin desde un lado de la misma, que pueden ser tiles para el cdigo cliente: boolean isBidirectional(); boolean isMandatory(); boolean isMultiple(); long getMIN(); long getMAX(); El mtodo isBidirectional determina si el extremo de asociacin recproco tambin es navegable. El mtodo isMandatory determina si la multiplicidad mnima es mayor que cero. El mtodo isMultiple determina si la multiplicidad mxima es mayor que uno. El mtodo getMIN devuelve el valor de la restriccin de multiplicidad mnima. El mtodo getMAX devuelve el valor de la restriccin de multiplicidad mxima. Cundo sta es muchos (*) se devuelve un valor especial. La interfaz tambin define el valor constante int MANY (de hecho -1).

6. La herramienta de generacin de cdigo

En esta seccin vamos a presentar brevemente la herramienta que hemos desarrollado: JUMLA (Java code generator for Unified Modeling Language Associations). Esta herramienta lee un modelo UML, almacenado en formato XMI, y genera el cdigo Java para gestionar las asociaciones UML contenidas en el modelo de entrada, de acuerdo con la tcnica descrita en este artculo. La herramienta slo genera cdigo para asociaciones: ignora cualquier otro artefacto UML que no est directamente relacionado con las asociaciones, como generalizaciones entre clases, atributos y operaciones de clase, etc. La herramienta presenta las clases y asociaciones encontradas en el modelo, y el usuario puede seleccionar de qu asociaciones quiere que se genere el cdigo. La herramienta crea ficheros de salida Java para las clases implicadas e inserta en ellas el cdigo para las asociaciones, con etiquetas convenientes que marcan el principio y fin del cdigo generado. Si el fichero de la clase ya existe, el cdigo es insertado al final del

19 fichero, respetando cualquier otro cdigo de la clase que el programador pueda haber escrito manualmente (por el contrario, si el programador cambia el cdigo de la asociacin y luego lo vuelve a generar, los cambios manuales se pierden). La Figura 12 muestra un modelo de ejemplo y la Figura 13 muestra cmo se presenta en la ventana principal de la herramienta JUMLA. El panel izquierdo de la herramienta muestra las clases contenidas en el modelo, en una estructura en rbol correspondiente a la estructura de paquetes del modelo. El panel derecho muestra las asociaciones contenidas en el modelo. Para cada asociacin se presenta la siguiente informacin: clases origen y destino; nombre de rol (opcional), multiplicidad, navegabilidad y visibilidad de los extremos de asociacin origen y destino; nombre de asociacin (opcional). El usuario puede seleccionar con una casilla de verificacin las asociaciones cuyo cdigo quiere generar.

1..1 Universidad

0..1 < estudia en 0..*

Estudiante

0..* +estudiante +curso 1..*

controla >

0..* (-)

Curso 0..3

-director 1..1 1..* Departamento +miembro 1..* Profesor +profesor 1..2

+curso

ensea >

Figura 12. Un modelo de ejemplo con algunas clases y asociaciones entre las clases

Figura 13. Una instantnea de la herramienta JUMLA.

20 La herramienta funciona de acuerdo con cinco opciones predefinidas que pueden ser deshabilitadas por el usuario para obtener mayor flexibilidad en la generacin de cdigo o en el tratamiento del modelo de entrada. La Tabla 1 resume las opciones de la herramienta. Opcin Comprobar las restricciones de multiplicidad mnima y mxima en el mtodo get Comprobar la restriccin de multiplicidad mxima en el mtodo add Comprobar el tipo de los objetos en parmetros Collection en los mtodos add y remove Rechazar asociaciones unidireccionales con restriccin de multiplicidad en el extremo origen Rechazar asociaciones bidireccionales con un extremo privado o protegido
Tabla 1. Resumen de opciones de la herramienta

Valor por defecto S S S S S

Las dos primeras opciones se refieren a la comprobacin automtica de restricciones de multiplicidad en los mtodos mutadores y lectores mediante el mtodo auxiliar isValid. De acuerdo con la justificacin dada en la Seccin 2, el funcionamiento predefinido es as: los mtodos lectores (get) levantan una excepcin de multiplicidad invlida (invalid multiplicity exception), definida en el cdigo que implementa las asociaciones, si no se satisfacen las restricciones de multiplicidad; los mtodos aadidores (add) rechazan la adicin de nuevos enlaces si no se satisfacen estas restricciones, pero no levantan ninguna excepcin; y los mtodos borradores (remove) no hacen ninguna comprobacin. Estas dos primeras opciones permiten generar un cdigo simplificado que omite estas comprobaciones, asumiendo el usuario la responsabilidad del control de la multiplicidad. La tercera opcin de la herramienta se refieren a la comprobacin automtica de tipos en los mtodos mutadores (add y remove) para asociaciones mltiples, que manejan parmetros de tipo Collection, por medio de un moldeado (casting) explcito en tiempo de ejecucin. De acuerdo con la justificacin dada en la Seccin 2, si falla la comprobacin de tipos, entonces no se actualizan los enlaces, y se levanta una excepcin de molde de clase (class cast exception), predefinida en Java. Esta tercera opcin permite generar un cdigo simplificado que no comprueba el tipo de los objetos recibidos en el parmetro Collection, y no levanta ninguna excepcin. Las dos ltimas opciones se refieren a la comprobacin de la validez del modelo de entrada. En el funcionamiento predefinido se rechazan las asociaciones unidireccionales con restricciones de multiplicidad en el extremo de asociacin no navegable (ver Seccin 3), y las asociaciones bidireccionales con visibilidad distinta de public o package en ambos extremos (ver Seccin 4). La cuarta opcin permite generar el cdigo sin comprobar la multiplicidad en el extremo no navegable, en lugar de rechazar la asociacin. La quinta opcin permite generar el cdigo, en lugar de rechazar la asociacin, cuando uno de los dos extremos tiene visibilidad protected o private y el otro extremo public o package, advirtiendo al usuario de que debe proporcionar acceso indirecto por medio de otros mtodos. Cuando ambos extremos son protected o private, la asociacin siempre es rechazada, porque el cdigo generado no podra funcionar correctamente.

7. Conclusiones
En este trabajo hemos desarrollado una forma concreta de traducir las asociaciones UML en cdigo Java: hemos escrito plantillas de cdigo especficas, y hemos construido

21 una herramienta que lee un modelo de diseo UML almacenado en formato XMI y genera los ficheros Java necesarios. Hemos prestado especial atencin a tres propiedades principales de las asociaciones: multiplicidad, navegabilidad y visibilidad. Nuestro anlisis ha encontrado dificultades que pueden revelar algunas debilidades de la Especificacin de UML. En lo que respecta a la multiplicidad, hemos mostrado que es imposible en la prctica con unas pocas operaciones primitivas satisfacer la restriccin multiplicidad mnima en todo momento en un extremo de asociacin obligatorio; nuestra propuesta es comprobar esta restriccin slo al acceder a los enlaces, pero no al modificarlos. El programador ser responsable de usar las primitivas de modo consistente, de modo que se alcance cuanto antes un estado vlido del sistema. Por el contrario, es posible asegurar el cumplimiento de la restriccin de multiplicidad mxima en tiempo de ejecucin, de modo que nuestra implementacin la hace cumplir. Los extremos de asociacin sencillos se almacenan fcilmente en atributos que tengan como tipo la clase destino, pero los extremos de asociacin mltiples requieren el uso de colecciones para almacenar el correspondiente conjunto de enlaces; como las colecciones en Java estn basadas en la clase estndar Object, es necesario realizar comprobacin de tipos en tiempo de ejecucin por medio de moldeado (casting) explcito cuando se usan colecciones como parmetros en los mtodos mutadores. En lo que respecta a la navegabilidad, las asociaciones unidireccionales son ms fciles de implementar por medio de atributos que las asociaciones bidireccionales, debido a las dificultades en la sincronizacin de los dos extremos de la asociacin. Una actualizacin en una asociacin bidireccional debe ser ejecutada atmicamente en ambos extremos para mantenerla consistente; esto se consigue en el objeto origen solicitando una actualizacin recproca en el objeto destino. Hemos considerado los pros y contras de una implementacin alternativa, basada en el almacenamiento de tuplas cosificadas, y finalmente la hemos descartado en favor de nuestro esquema de referencias cruzadas sincronizadas. Una consecuencia derivada de nuestro anlisis es que la restriccin de multiplicidad en un modelo de diseo slo puede ser especificada para un extremo de asociacin navegable. En lo que respecta a la visibilidad, en el caso de asociaciones unidireccionales se implementa con cierta facilidad simplemente traduciendo la visibilidad del extremo de la asociacin a la visibilidad de los correspondientes mtodos lectores y mutadores, porque los niveles de visibilidad de UML y Java tienen la misma semntica. Sin embargo, las asociaciones bidireccionales con uno o dos extremos privados (o protegidos) se comportan de modo paradjico, porque la actualizacin recproca resulta imposible. Adems, consideramos que la visibilidad de paquete est mal definida para las asociaciones en la Especificacin de UML, y hemos sugerido una nueva definicin. El cdigo generado para cada asociacin se localiza fcilmente dentro de las clases Java implicadas. Cada extremo de asociacin presenta una interfaz uniforme para el programador. La interfaz es exactamente la misma para extremos de asociacin unidireccionales y bidireccionales, pero hay ligeras diferencias para extremos de asociacin sencillos y mltiples. Nuestro enfoque es ms bien exhaustivo en cuanto a las comprobaciones de invariantes. Pensamos que vale la pena hacer todo lo que se pueda para ayudar al programador, de modo que nuestra herramienta inserta cdigo que realiza comprobaciones de multiplicidad y tipo en tiempo de ejecucin y, por supuesto, que solicita las actualizaciones recprocas en asociaciones bidireccionales. No obstante, la herramienta tiene distintas opciones que permitirn al usuario omitir las comprobaciones automticas de multiplicidad y tipo al generar el cdigo, en favor de la eficiencia. Adems, hemos argumentado que las asociaciones unidireccionales no deberan tener restricciones de multiplicidad en el extremo origen en un modelo de diseo, y que las asociaciones bidireccionales no deberan tener ambos extremos con visibilidad privada (o protegida); por tanto, nuestra herramienta

22 rechazar la generacin de cdigo para estas asociaciones. Una vez ms, el usuario podr desactivar esta comprobacin de correccin del modelo y generar el cdigo por su cuenta y riesgo. Este trabajo puede continuarse en distintas lneas. Primero, implementacin de otras propiedades de los extremos de asociacin, tales como ordenacin, modificabilidad, especificador de interfaz, asociaciones exclusivas, etc. Segundo, implementacin especfica de algunos tipos particulares de asociaciones binarias tales como asociaciones reflexivas, agregaciones y composiciones. Tercero, implementacin de asociaciones ms complejas: asociaciones cualificadas, clases-asociacin, y asociaciones n-arias. Cuarto, ampliar la herramienta para que lleve a cabo ingeniera inversa, es decir, obtener las asociaciones entre clases analizando el cdigo que las implementa. Nuestra herramienta no lleva a cabo actualmente esta tarea, aunque es muy sencilla y directa si el cdigo ha sido escrito con nuestras plantillas. Finalmente, adaptar la herramienta y las plantillas de modo que sigan la nueva Java Metadata Interface (JMI) Specification [JMI]. Agradecimientos. Los autores desean dar las gracias a Perdita Stevens, ya que este artculo fue escrito principalmente mientras el primer autor estaba visitando el Laboratory for Foundations of Computer Science (LFCS), parte de la Division of Informatics de la Universidad de Edimburgo, invitado por ella en febrero-abril de 2002; una versin preliminar de este trabajo fue presentada en el LFCS Lab Lunch el 23 de abril de 2002. Esta estancia investigadora fue realizada gracias a la financiacin de la Fundacin Universidad Carlos III, Madrid, Espaa. Gracias tambin a Jos Miguel Fuentes, Vctor Quintana, David Fernndez y Vicente Palacios por sus valiosas sugerencias para mejorar este artculo.

Referencias
[Ambler 01] Scott W. Ambler. An Overview of Object Relationships, Unidirectional Object Relationships, Implementing One-to-Many Object Relationships, Implementing Many-to-Many Object Relationships. A series of tips to be found at IBM Developer Works, http://www-106.ibm.com/developerworks/. Ken Arnold, James Gosling, David Holmes. The Java Programming Language. Addison-Wesley, 3rd ed., 1998. Xabier Castellani, Henri Habrias, Philippe Perrin. A Synthesis on the Definitions and Notations of Cardinalities of Relationships, Journal of Object Oriented Programming, 13(6):32-35 (2000) Financial Systems Architects (New York, U.S.A.). 3C-Clear Clean Concise. Submission to OMG. http://www.community-ml.org/. Bruce Eckel. Thinking in Java, 2nd ed. Prentice-Hall, 2000. Martin Fowler, Kendall Scott. UML Distilled: Applying the Standard Object Modeling Language. Addison-Wesley, 1997. The Fujaba CASE Tool, University of Paderborn, http://www.fujaba.de/. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns. Elements of Reusable Object-Oriented Software. AddisonWesley, 1994. Guy Genilloud. Informal UML 1.3 - Remarks, Questions, and some Answers. UML Semantics FAQ Workshop (held at ECOOP99), Lisbon, Portugal, June 12th 1999.

[Arnold 00] [Castellani 00]

[cUML] [Eckel 00] [Fowler 97] [Fujaba] [Gamma 94]

[Genilloud 99]

23 [Gnova 01] Gonzalo Gnova. Semantics of Navigability in UML Associations. Technical Report UC3M-TR-CS-2001-06, Computer Science Department, Carlos III University of Madrid, November 2001, pp. 233-251. Gonzalo Gnova, Juan Llorens, Paloma Martnez. The Meaning of Multiplicity of N-ary Associations in UML, Software and Systems Modeling, 1(2): 86-97, 2002. A preliminary version in: Gonzalo Gnova, Juan Llorens, Paloma Martnez. Semantics of the Minimum Multiplicity in Ternary Associations in UML. The 4th International Conference on the Unified Modeling Language-UML2001, October 1-5 2001, Toronto, Ontario, Canada. Published in Lecture Notes in Computer Science 2185, Springer 2001, pp. 329-341. Gonzalo Gnova, Juan Llorens, Vicente Palacios. Sending Messages in UML, Journal of Object Technology, vol.2, no.1, Jan-Feb 2003, pp. 99115, http://www.jot.fm/issues/issue_2003_01/article3. Gonzalo Gnova. Entrelazamiento de los aspectos esttico y dinmico en las asociaciones UML. PhD Thesis, Carlos III University of Madrid, 2003. James Gosling, Bill Joy, Guy Steele. The Java Language Specification. Addison-Wesley, 1996. William Harrison, Charles Barton, Mukund Raghavachari. Mapping UML Designs to Java. The 15th Annual ACM Conference on ObjectOriented Programming, Systems, Languages, and ApplicationsOOPSLA2000, October 15-19 2000, Minneapolis, Minnesota, United States. ACM SIGPLAN Notices, 35(10): 178-187. ACM Press, New York, NY, USA. Java Community Process. Java Metadata Interface (JMI) Specification, Version 1.0, June 2002. Available at http://www.jcp.org/. Hermann Kaindl. Difficulties in the Transition from OO Analysis to Design. IEEE Software, 16(5):94-102 (1999).

[Gnova 02]

[Gnova 03a]

[Gnova 03b]

[Gosling 96] [Harrison 00]

[JMI] [Kaindl 99]

[McAllister 98] Andrew McAllister. Modeling N-Ary Data Relationships in CASE Environments, Proceedings of the 7th International Workshop on Computer Aided Software Engineering, pp. 132-140, Toronto, Canada (1995). A more recent version in: Complete Rules for N-Ary Relationship Cardinality Constraints, Data & Knowledge Engineering, 27(3):255-288 (1998). [Noble 96] James Noble. Some Patterns for Relationships. In Proceedings of Technology of Object-Oriented Languages and Systems (TOOLS Pacific 21), Melbourne, 1996. Prentice-Hall. James Noble. Basic Relationship Patterns. In Proceedings of the European Conference on Pattern Languages of Program Design (EuroPLOP97). Irsee, Germany, 1997. The Rhapsody CASE Tool, ILogix, http://www.ilogix.com/. James Rumbaugh, Ivar Jacobson, Grady Booch. The Unified Modeling Language Reference Manual. Addison-Wesley, 1998. Carlos Ruiz del Castillo. Implementacin en Java de asociaciones binarias UML. Universidad Carlos III de Madrid, Proyecto Fin de

[Noble 97]

[Rhapsody] [RM] [Ruiz 02]

24 Carrera, Ingeniera Informtica (Segundo Ciclo), julio 2002. Tutor: Gonzalo Gnova. [Rumbaugh 87] James Rumbaugh. Relations as Semantic Constructs in an ObjectOriented Language, In Proceedings of the ACM Conference on ObjectOriented Programming: Systems, Languages and Applications, pp. 466481, Orlando, Florida, 1987. [Rumbaugh 96a] James Rumbaugh.: Models for Design: Generating Code for Associations. Journal of Object Oriented Programming, 8(9):13-17, February 1996. [Rumbaugh 96b] James Rumbaugh. A Search for Values: Attributes and Associations. Journal of Object Oriented Programming, 9(3):6-8, June 1996. [Song 95] Il-Yeol Song, Mary Evans, E.K. Park. A Comparative Analysis of Entity-Relationship Diagrams, Journal of Computer and Software Engineering, 3(4):427-459 (1995) Perdita Stevens, Rob Pooley. Using UML: Software Engineering with Objects and Components. Addison-Wesley, 2000. Perdita Stevens. On the Interpretation of Binary Associations in the Unified Modelling Language, Journal on Software and Systems Modeling, 1(1):68-79 (2002). A preliminar version in: Perdita Stevens. On Associations in the Unified Modeling Language. The Fourth International Conference on the Unified Modeling Language, UML2001, October 1-5, 2001, Toronto, Ontario, Canada. Published in Lecture Notes in Computer Science 2185, Springer 2001, pp. 361-375. Object Management Group. Unified Modeling Language (UML) Specification, Version 1.4, September 2001 (Version 1.3, June 1999). Available at http://www.omg.org/. Object Management Group. XML Metadata Interchange (XMI) Specification, Version 1.2, January 2002. Available at http://www.omg.org/.

[Stevens 00] [Stevens 02]

[UML]

[XMI]