Modelado de datos con UML: Clases asociativas

Muchas veces una asociación necesita almacenar información relevante o bien introduce un concepto nuevo para el dominio. Las clases asociativas se derivan de una asociación entre dos o más clases. Una instancia de esta clase está asociada siempre a una y solo una instancia de cada participante de la asociación. Las instancias de estas clases se crean al asociar otras clases y se destruyen cuando se rompe la asociación. Es decir, su ciclo de vida está ligado al ciclo de vida de la relación de la cual deriva. No pueden existir dos instancias de la asociativa que dependan de las mismas instancias de la clase (podíamos decir que el OID de la asociativa es la fusión de los dos OID de la clases asociadas. Gráficamente se conectan con una línea punteada hacia la parte intermedia de una asociación binaria o hacia el rombo de una N-aria. Se recomienda su uso en los siguientes escenarios: Cuando una asociación (binaria, recursiva, N-aria, pero no agregación ni composición) necesita almacenar atributos propios. Cuando se introduce un concepto nuevo fruto de la unión semántica de dos conceptos y este concepto necesita relacionarse con otros. Cuando una asociación ternaria (3 participantes) tiene en uno de sus términos una multiplicidad 1 (lo que se denomina falsa ternaria. Lo veremos más tarde en este episodio). Observa los siguientes ejemplos:

Una Convocatoria se produce cuando se desea impartir un Curso en una Oficina y una Fecha concretas. Una convocatoria siempre es de un curso concreto, en una fecha concreta y en una oficina concreta. La asociativa no permite lanzar dos convocatorias en la misma fecha y la misma oficina del mismo curso.

Una Candidatura se materializa cuando un Candidato se inscribe en una Oferta de Empleo. Es necesario saber en todo momento el estado de esta candidatura y la fecha de inscripción (atributos). Además, la asociativa no permite que puedan existir dos candidaturas de la misma oferta para el mismo candidato.

No obstante, este último ejemplo no debe confundirse con la siguiente construcción:

Aunque puedan parecer equivalentes a simple vista, la segunda construcción no es igual a la primera porque en la primera sólo hay una única asociación binaria *-*, mientras que en la segunda son dos asociaciones binarias 1-*. Además, en la primera, no pueden existir dos candidaturas de la misma oferta para el mismo candidato. En la segunda, nada lo impide a no ser que se declare una restricción textual prohibiéndolo. Añadir dicha restricción hace que ambas construcciones sí sean equivalentes.

Cuando tenemos una asociación ternaria y uno de sus extremos tiene una multiplicidad 0..1, se recomienda transformar el modelo.

La asociación ternaria de arriba se debe transformar en la siguiente construcción equivalente:

En el primer modelo, dado un Camarero y una Fecha concretas, sólo se permite trabajar en un único Turno (recuerda que hemos de poner 0..1 para evitar el problema de la obligatoriedad para todas las combinaciones). En el segundo modelo, hemos reformulado la relación ternaria. Creamos un nuevo concepto fruto de la relación entre una fecha y un camarero: la Jornada de Trabajo. A esa jornada se le asocia un turno. Si te fijas bien, ambos modelos son equivalentes. En conclusión, la transformación de una falsa ternaria a una clase asociativa es mecánica: Crear una asociación binaria *-* con las clases que tenían multiplicidad * en la antigua ternaria. Generar una clase asociativa de esta nueva asociación. Crear una asociación binaria con multiplicidades 1-* entre la clase asociativa y la clase que tenía multiplicidad 0..1 en la antigua ternaria.