Símbolos del diagrama de clases UML

La regla que hace todo esto memorizable: el extremo decorado es el extremo que importa. El triángulo apunta al clasificador más general, el rombo se apoya en el todo que posee, y la flecha abierta señala lo que se usa. Si recuerdas qué extremo lleva la marca, normalmente puedes reconstruir el significado.

La mitad de las marcas de un diagrama de clases está en las líneas y la otra mitad en las cajas, y es la segunda la que la gente se salta. Un rectángulo con un nombre es una clase; todo lo que sigue cambia qué clase de cosa afirma ser ese rectángulo, y un lector que no conoce la diferencia lee una interfaz como una clase y se pregunta por qué no tiene atributos.

Una interfaz tiene una segunda notación, más pequeña, que no cuesta ninguna caja: una piruleta -un círculo en un palito- dibujada sobre el clasificador que la proporciona, y un zócalo a juego, un semicírculo abierto, sobre el que la necesita. Junta los dos y tienes la bola y zócalo con la que se construyen los diagramas de componentes. Dice exactamente lo que dice el triángulo discontinuo, en una décima parte del espacio, y es la elección correcta en cuanto un diagrama tiene más de unas tres interfaces.

Una caja de clase es una banda con el nombre y hasta dos compartimentos debajo: atributos y luego operaciones. Ambos son opcionales, y una caja que es solo un nombre es perfectamente legal: normalmente lo correcto en un diagrama sobre relaciones.

La multiplicidad se escribe en el extremo de una relación, y la sintaxis es corta: 1 exactamente uno, 0..1 opcional, * o 0..* cualquier número incluido ninguno, 1..* al menos uno y 2..5 un rango real. Una multiplicidad ausente significa sin especificar, no «uno»: dejarla en blanco es un hueco, no un valor por defecto.

Una operación se escribe + place(customer: Customer, at: Instant): Order: visibilidad, nombre, parámetros con sus tipos y luego el tipo de retorno tras los dos puntos. Dos decoraciones aparecen lo bastante a menudo como para reconocerlas: un parámetro puede llevar dirección, como en out receipt: Receipt, y un atributo un valor por defecto, como en - status: Status = DRAFT. Ninguna es obligatoria, y un modelo de dominio suele estar mejor sin ninguna de las dos.

Una relación lleva significado en ambos extremos, y casi todo lo que un diagrama de clases hace mal en una revisión está en un extremo y no en el medio. La línea dice que dos clases están conectadas; los extremos dicen quién puede alcanzar a quién, cuántos, en qué orden y con qué nombre.

El último grupo de marcas es el que lleva las reglas que un dibujo de cajas y líneas no puede expresar por sí solo. Un diagrama de clases es una estructura, y la mitad de lo que sabe un experto del dominio es una condición sobre esa estructura: un total que nunca puede ser negativo, un par de relaciones de las que exactamente una puede estar rellena.

Una convención fuera de esta tabla merece conocerse porque parece un diagrama de clases y no lo es: un nombre subrayado con la forma order1: Order es una instancia, y un diagrama hecho de esos es un diagrama de objetos: la misma notación mostrando un momento en vez de todos los momentos posibles. El subrayado dentro de una caja de clase significa algo completamente distinto: es el marcador estático de la tabla de compartimentos de arriba.

El texto entre comillas angulares -«interface», «enumeration», «entity»- es un estereotipo: una extensión del vocabulario estándar que dice qué clase de cosa es este clasificador más allá de «clase». UML define unos pocos; el resto viene de un perfil, que es el mecanismo para inventar los tuyos sin salir del lenguaje.

Las comillas angulares hacen dos trabajos distintos y la especificación los distingue aunque nada en la página lo haga. «interface» y «enumeration» son palabras clave: parte de UML, de significado fijo y legales en cualquier herramienta. «aggregate root» o «pii» son estereotipos: tu propio vocabulario, definido en un perfil, con significado solo para quien sepa qué quieren decir. Ambos merecen usarse. Merece saber cuál acabas de escribir, porque el segundo tipo necesita una leyenda en el diagrama y el primero no.

Un estereotipo también puede llevar valores etiquetados: {owner = payments-team, retention = 7y} bajo una clase estereotipada, y así es como un modelo empieza a contener los metadatos que una hoja de cálculo contenía mal. Ese es el mecanismo que un perfil existe para definir.

Para ver todo esto sobre modelos reales, lee los ejemplos trabajados; para el razonamiento detrás de las marcas y no las marcas en sí, el artículo del diagrama de clases.