24 July 2007

Tips para construcción de diagramas de clases útiles y legibles

Escribo en este post uno de los temas más recurrentes y de más utilidad en clases, revisiones de pares, recomendaciones de diseño, revisiones de documentos de arquitectura y en general en cualquier momento donde aparezca un diagrama de clases.

Hago una recopilación de los tips y observaciones que surgen continuamente y que teniéndolos en cuenta se mejora significativamente la calidad y utilidad de los diagramas.

El error más común: Relaciones conceptuales

En muchos casos un modelo conceptual, que representa el espacio del problema, se utiliza como base para la identificación de clases. Las relaciones que se presentan en un modelo conceptual suelen ser acciones o interacciones de elementos en el mundo real. Por ejemplo en el modelo conceptual de un sistema de inscripciones de un ente educativo, seguramente consiguiremos una relación inscribe entre los conceptos de Estudiante y Materia.

Figura 1: Modelo Conceptual
En el modelamiento de un diagrama conceptual ésto es perfectamente válido. Ahora cuando se habla de relaciones entre clases, una relación inscribe entre las clases Estudiante y Materia tiene un significado bien específico y está relacionado directamente con la implementación.

Figura 2: Diagrama de Clases
La relación de la figura 2 establece que en la clase Materia existe un método llamado inscribe y que este método es invocado en algún momento por la clase Estudiante. Hay que estar claros con lo que se está expresando y hacerlo concientemente.

Si por ejemplo asumimos que un componente, capa de software o servicio es responsable de un contrato de registro de la inscripción de una materia y ofrece una operación o método con firma:
void inscribirMateria(Estudiante estudiante, Materia nuevaMateria)
throws InscripciónDuplicadaException

Este servicio en su implementación podría hacer una serie de validaciones y luego acceder a un repositorio y almacenar la formalización de la inscripción de la materia.
En este caso la clase Estudiante nunca invocaría un método inscribir de la clase Materia e inclusoeste método podría no existir, aunque sea cierta la relación conceptual entre ambas clases. En un diagrama de clases, de acuerdo a la implementación planteada, sería un error colocarla en un diagrama de clases.

Tipos de relaciones:
estáticas vs. dinámicas

Las relaciones entre dos clases pueden ser clasificadas en dos tipos, estáticas y dinámicas.

Las relaciones estáticas son aquellas que definen estructuralmente a la clase, básicamente en los lenguaes OO utilizados actualmente se definen tres tipos; extensión o herencia, agregación y composición. No es el objeto de este artículo explicar estas relaciones, hay múltiples fuentes disponibles.

Las relaciones dinámicas son las que definen la interacción de la clase con otras, invocaciones que desde la clase se hace a métodos de otra clase. Un ejemplo de relación dinámica se define en la Figura 2.

El tip que se presenta a continuación se basa en esta definición teórica para hacer una recomendación concreta en la construcción de diagramas.

No llene el diagrama de clases con relaciones dinámicas descontextualizadas

Las relaciones dinámicas se dan en el contexto de la ejecución de una operación, servicio o contrato específico. Una clase que participa en la realización de múltiples operaciones, probablemente contará con múltiples invocaciones a otras clases, subconjuntos de todas estas relaciones (invocaciones) participan en la relización de una cada operación específica.

Si en un diagrama de clases, adicionalmente a las relaciones estáticas, colocamos todas las relaciones dinámicas que se dan entre las clases del diagrama (es decir, todas las relaciones por cada vez que una clase llama a un método de otra clase) entonces terminaremos con un diagrama sobrecargado, de aquellos que solemos llamar spaghetti diagram.
Figura 4: Espagueti inentendible... encontré un buen ejemplo buscando imágenes en la red.

Cuando se presenta un diagrama de clases, lo más recomendable es presentar la estructura utilizando sólo las relaciones estáticas. Las relaciones dinámicas recomiendo presentarlas en su debido contexto, por ejemplo utilizando un diagrama de secuencias o colaboración para cada operación o servicio. De esta forma se apreciará claramente la interacción entre las diferentes clases e incluso objetos, para lograr la realización de una operación.

Seguir esta recomendación mejora significativamente la utilidad de la documentación para el equipo que hará mantenimiento del sistema en construcción, disminuyendo así los costos de soporte y mantenimiento a futuro.

3 comments:

Unknown said...

Pedro,

Lo que dices sobre la figura 2 es confuso porque en UML los diagramas de clase son estáticos así que la figura no puede implicar la existencia de un método.

Se que estás tratando de denunciar el error que cometen los que interpretan el diagrama de esa manera, pero no se entiende bien.

José Asdrúbal said...

Pedro, me parece excelente tu apreciación y tu clara diferenciación entre las relaciones estructurales y dinámicas.

Quisiera agregar otro aspecto del porque no es recomendable colocar las relacioens dinámicas.
De acuerdo a la especificación de la superestructura de UML 2.0(OMG, 2004), indica la definición de asociación, como "una relación que puede ocurrir entre instancias de clasificadores" (clases). Fijense de acuerdo a esto, las asociaciones ocurren en entre entre instancias y no a nivel estructural. Por ello a nivel de diseño no es necesario aplicar asociaciones dinámicas, sino mas bien sus relaciones tipicas estructurales, como bien lo menciona Pedro. Además de que a nivel de diseño, podrias incurrir en el error de acoplar una clase con otra, cuando en realidad resulte falso.

Unknown said...

Gracias por compartir tus experiencias, ya que nos ayudas mucho, por ahora soy estudiante y trabajo como analista programador pero algun dia quiero ser un arquitecto de software