El diagrama de clases es una herramienta para comunicar el diseño de un programa orientado a objetos, permitiendo modelar las relaciones entre las entidades. En UML, una clase es representada por un rectángulo que posee tres divisiones: Nombre de la clase, atributos que tiene y mensajes que entiende.
En el primer cuadro anotamos el nombre de la clase (si es abstracta se escribe en cursiva, o bien se usa un estereotipo <
En la segunda parte (que para nosotros no será de tanta importancia) van los atributos (o variables de instancia, las variables de clase van en subrayado).
En el último cuadro escribimos las operaciones (qué mensajes que puede entender). No confundir con los métodos que es cómo lo resuelve cada objeto. Lo importante no es documentar todos los mensajes de un objeto, sino sólo los más relevantes. Así quedan fuera los getters, setters, métodos privados (o auxiliares) y aquellos que uno considere menores. Moraleja: cuidado con las herramientas que en base al código generan el diagrama (y viceversa). Bien vale la pena un diagrama útil hecho a mano antes que uno inútil en 3D.
Importante: Una clase que no tiene comportamiento no está comunicando qué rol cumple en la solución: o está faltando definir qué le puedo pedir o esa clase no debería estar en el diagrama.
Dependencia: uno de los elementos usa o depende del otro cuando:
Este tipo de relación indica que los dos elementos colaboran entre sí, pero que esa relación es débil, casual; tiene un contexto temporal que no trasciende más allá de una operación. No obstante, sabemos que los cambios en la clase B podrían impactar en alguna medida en la clase A.
Asociación: uno de los elementos conoce al otro, almacenándolo como variable de instancia.
Puede definirse una etiqueta que expresa el rol que cumple dicha relación. En cada extremo de la asociación puede agregarse la siguiente información:
En las asociaciones, hay una relación más fuerte que en las dependencias (uso) entre ambos elementos. El conocimiento implica que la colaboración excede el marco temporal de una operación, aunque cada uno de los objetos sigue teniendo objetivos diferentes.
Generalización: una clase específica hereda los atributos, relaciones, operaciones y métodos de otra más general.
Cuando una subclase redefine el comportamiento de su superclase, se escriben los nombres de los métodos que redefine.
Realización: se establece entre una clase y una interfaz; esto implica que la clase debe implementar todas las operaciones que defina la interfaz. Si bien no todos los lenguajes requieren explicitar por código la existencia de una interfaz (en Smalltalk no hace falta, pero en Java sí por tener un checkeo de tipos estático), desde un punto de vista conceptual la interfaz existe y puede comunicarse en el diagrama.
Home
Artículos
