Reflexión sobre relaciones de Agregación y Asociación en UML Continuación

Relación Maestro-Esclavo:

Esta semana leí un documento que formaliza la relación tiene un, realmente era una formalización científica y estaba escrito en OCL (Object Constraint Language).

Lo interesante es que si nos detenemos en la relación maestro-esclavo, es una relación tiene-un, es decir, el maestro, en este caso, debe tener un esclavo porque si no entonces no es maestro.

Pero esta relación se refiere a mando, uno indica y el otro obedece. Sin embargo, analicemos esta situación: Digamos que tenemos un vaso, ahora le agregamos un dado. ¿El vaso tiene un dado?. Pareciera que si en el momento que sí en el momento en que tenemos el dado, pero si le quitamos el dado el vaso sigue siendo un vaso completo. Por lo tanto, el vaso no tiene un dado porque una condición de la relación tiene un es que si le quitas la parte al todo, el todo se destruye por la simple razón que pasa de ser todo a ser algo parcial, lo que constituiría una contradicción.

Ahora bien, el vaso con el dado es una relación maestro-esclavo porque a donde mueves el vaso mueve el dado, pero a donde mueves el dado no mueves el vaso (lo puedes mover dentro del vaso). Por herencia entonces si decimos la relación vaso-dado es maestro-esclavo y maestro-esclavo es tiene-un por transitividad la relación vado-dado es tiene-un. Entonces ¿Colocamos una agregación entre el vaso y el dado?.

La respuesta es no, porque para que el vaso comande al dado primero debemos agregarle el dado, es decir, el vaso ya existía antes de poseer el dado A la vez, un diagrama de clase es un diagrama estructural, muestra como se componen los objetos de los que son familia las clase. Por ejemplo, tenemos este vaso con el dado y le colocamos un vaso aparte, si decimos que el vaso tiene un dado entonces el otro no es un vaso pero es un contradicción porque realmente es un vaso.

En conclusión, un Diagrama de Clases muestra definiciones y porque un objeto mande a otro, no quiere decir que el objeto que manda tenga una agregación con el que obedece.

Muchas Gracias por su lectura.

Referencia al documento indicado inicialmente:

The Whole-Part Relationship in the Unified Modeling Language: A

New Approach

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.72.43&rep=rep1&type=pdf

Reflexión sobre relaciones de Agregación y Asociación en UML

Realizando un proyecto tuve un serio problema cuando tuve que decidir si una relación UML era de Agregación o Asociación.

Por ello estuve buscando por Internet, (ya saben Google). Entre las paginas que visite la que se destacó como casi siempre fue Stack Overflow (muy buen foro de preguntas).

En fin la respuesta que casi siempre obtuve fue la siguiente, una agregación es una relación entre un todo y sus partes en las que las partes pueden existir sin el todo, y una asociación, una relación débil entre las partes que indica que ambas colaboran entre sí.

Bueno a mi me parece que es una buena definición si estas creando una Ontología. Sin embargo, si lo que estas creando un diseño creo que pueden existir otras formas de pensar al respecto.

La clave a la solución me llegó cuando estaba desarrollando un modulo para crear una lista de estudiantes de un hipotético sistema de administración de exámenes.

Por ejemplo, digamos que queremos un Examen, que es mejor hacer:

Profesor.getExamen () o Estudiante.getExamen ()

Si hacemos Estudiante.getExamen () necesitamos primero la lista de todos los estudiantes, digamos Matricula.getEstudiante () y así encontramos los estudiantes, después de todo una matricula tiene un conjunto de estudiantes, luego seleccionamos un estudiante y decimos Estudiante.getExamen ().

Eso parece bien excepto por el hecho de que el estudiante pudo no haber asistido al examen, entonces tendríamos que pasar al siguiente estudiante y así sucesivamente.

Sin embargo si decimos Profesor.getExamen () pueden ocurrir dos cosas, una regresa null, pero eso indicaría que no existe aun el examen, o nos regresa el examen.

Esto me parece se debe a que quien tiene la responsabilidad de darnos el Examen es el Profesor, es decir a el es a quien se le pide el examen, ya sea para agendarlo y administrarlo posteriormente o para que el propio estudiante obtenga el examen si este es administrado por el propio profesor.

Ahora bien, es cierto que al principio el examen es en realidad un cuestionario, pero aún así a quien le debemos preguntar quien asistió o no al Examen es al administrados, no a cada estudiante