Consistencia entre Diagramas de Secuencia y Diagramas de Clases

Autor: Carlos M. Macías Medina

Alias: Charlie Macías (México)

Categoría: Certificación

El tema que voy a desarrollar en esta entrada discute un punto de evaluación típico en los exámenes de certificación de UML. Se trata de la consistencia que debe existir entre los diagramas de secuencia y los diagramas de clases.

Como sabemos, los diagramas de secuencia normalmente son empleados para visualizar, especificar o documentar la manera en la que una sociedad de objetos colabora para alcanzar los objetivos planteados en un escenario de un caso de uso. Nos ofrecen una perspectiva desde la cual podemos abordar el comportamiento de un sistema. Por supuesto, este comportamiento debe estar plenamente soportado por la estructura del sistema. Como en todos los sistemas, nada puede moverse si su estructura no lo soporta. Si la estructura de un sistema no soporta cierto aspecto dinámico normalmente suele colapsar.

Las tres reglitas son las que enumero a continuación:

1. Cualquier objeto que aparezca como participante en el diagrama de secuencia, debe ser instancia de un clasificador en un diagrama de clases (observe que los diagramas de casos de uso son un tipo de diagrama de clases).
2. Cualquier intercambio de mensajes que se dé entre dos participantes que sean instancia de distintas clases, implica que las clases de las cuales son instancia dichos participantes deben estar vinculados mediante algún tipo de relación (asociación, agregación, composición, dependencia o generalización).
3. Cualquier mensaje que se intercambie entre participantes, ya sea reflexivo o no, debe estar soportado por una operación de la clase.

De esta manera, con base en el diagrama que se muestra a continuación nos podrían preguntar ¿Qué métodos deben ser implementados por la clase "Secretaria"?:

Con base en la tres premisas anteriores, la respuesta sería:

1. Con base en el diagrama, debe implementar los métodos "aceptarAplicacion(...)", "almacenar()", "obtenerAplicacion()".

Además podríamos decir:

En el diagrama de clases deben existir las clases:

1. "Persona" la cual debe estar relacionada con la clase "Secretaria" como consecuencia de la llamada a operación "aceptarAplicacion(...)".
2. "Secretaria" que debe estar relacionada con las clases "Bandeja", por las invocaciones a las operaciones "colocar(...)" y "obtener()", y "Gerente", por la operación "notificar(...)" respectivamente.
3. "Bandeja" de la cual no se origina ninguna relación, salvo la antes mencionada con "Secretaria".
4. "Gerente" que origina una relación hacia la clase "Secretaria", derivada de la invocación a la operación "obtenerAplicacion()".

Existen muchas variantes para evaluar este aspecto pero siempre que se tengan presentes los tres principios expuestos la respuesta será simple.