Ejemplos de diagramas de clases UML

El diagrama de arriba merece leerse relación por relación. Book y DVD generalizan LibraryItem, que se dibuja como un triángulo hueco apuntando al padre, y la razón para dibujarlo así en vez de como dos clases sin relación con atributos duplicados es la asociación de debajo. Loan apunta a exactamente un LibraryItem, y como apunta al padre abstracto, puede prestar cualquiera de los subtipos sin saber cuál.

Esa es toda la prueba de la herencia en un modelo de dominio: no "¿estas dos cosas se parecen?", sino ¿hay en algún punto del modelo algo que quiera sostener una u otra sin importarle cuál? Si no lo hay, dos clases separadas son la respuesta más pequeña y más honesta.

Fíjate en las multiplicidades de la asociación Member-Loan: 1 a 0..*. Un socio sin préstamos es un socio; un préstamo sin socio es un fallo. Esa asimetría es un hecho real del dominio y está puesta en la línea en vez de dejarse a un comentario. El artículo del diagrama de clases cubre cómo se dibuja cada uno de esos símbolos.

Este no contiene herencia ninguna, y de eso se trata al mostrarlo junto a la biblioteca. Lo que tiene en su lugar es una composición y una interfaz, y cada una está ahí por una razón para la que el otro diagrama no tenía uso.

El rombo relleno entre Basket y BasketLine es una afirmación: borra la cesta y las líneas se van con ella, porque una línea de cesta no significa nada por su cuenta. Compáralo con la asociación simple de BasketLine a Product, donde el producto sobrevive claramente a la línea: la misma forma de relación, dos vidas distintas, y la notación las distingue.

PricingRule es el punto de extensión. Se dibujan dos realizaciones porque una sola realización no es una abstracción, es una clase con un paso de más, y en cuanto hay dos, añadir una tercera promoción es una clase nueva y no una rama nueva en un método existente.

Los dos diagramas premian el mismo orden de lectura, y no es de izquierda a derecha. Empieza por las multiplicidades, porque son las decisiones: dicen qué permite el sistema y son lo más difícil de cambiar después. Luego lee los rombos, que dicen qué se borra con qué. Después los triángulos, que dicen qué puede sustituir a qué. Los atributos al final, y solo los que te den dudas.

Un diagrama que sobrevive a esa lectura merece conservarse. Uno con las multiplicidades en blanco no está acabado, por muchos atributos que liste, y ese es con diferencia el estado en que más veces te encontrarás un diagrama de clases.

Siguiente: cómo dibujar uno desde cero, y la referencia de símbolos para comprobar una marca de la que no estés seguro.