Cómo dibujar un diagrama de clases UML

El paso uno es escribir cómo se describe el dominio en voz alta y subrayar los sustantivos."Un paciente pide cita con un médico, y el médico puede emitir una receta" da cuatro candidatos de inmediato. Quédate con los que tienen tres propiedades: identidad (dos de ellos se distinguen), estado que cambia con el tiempo, y una vida propia. Un sustantivo que falla las tres - un color, un importe, un estado - es atributo de otra cosa.

El paso dos es una línea por cada frase que puedas decir sobre el dominio. No por join de base de datos ni por llamada a método: una línea significa que las dos clases se conocen en el sentido de negocio. El diagrama de arriba es donde eso termina, y ya merece ponerse delante de alguien que conozca el dominio, porque la discusión que quieres es si una receta pertenece a una cita o a un paciente, y esa discusión está disponible ahora, antes de teclear un solo atributo.

Cada línea recibe un número en cada extremo antes de añadir un solo atributo. Este es el paso que la gente se salta y el que compensa, porque una multiplicidad es una decisión sobre qué permite el sistema y un atributo es un detalle que se deriva de ella.

Lee cada extremo como una frase y dila en voz alta. "Un paciente tiene cero o más citas": bien. "Una cita tiene exactamente un paciente": bien, y conviene comprobarlo, porque una consulta que alguna vez reserva un hueco familiar acaba de decirte lo contrario. Las tres preguntas en cada extremo son: ¿puede ser cero?, ¿puede ser más de uno?, y ¿cambia eso en un mal día?

Después elige la clase de relación, y solo dos decisiones merecen que te agobies. ¿Se borra la parte con el todo? Si sí, composición. ¿Algo sostiene el tipo padre sin importarle el subtipo? Si sí, generalización. Todo lo demás es una asociación simple, y los ejemplos trabajados muestran los dos juicios en acción.

Los atributos van en cuarto lugar y cada uno tiene que tener una fuente. Si no puedes decir de dónde sale un valor - un formulario, otro sistema, un cálculo - es una suposición, y las suposiciones son lo que hace que un modelo deje de encajar con aquello que describe. Merece la pena escribir los tipos: startsAt: Instant zanja una discusión que startsAt: Date deja abierta.

Las operaciones van en quinto lugar y la mayoría de las clases no reciben ninguna. Una operación pertenece a una clase cuando el comportamiento necesita de verdad el estado propio de esa clase: cancel() necesita el estado de la cita, así que pertenece ahí. Cualquier cosa que necesite otros tres objetos para hacer su trabajo es un servicio, y ponerla aquí es como un modelo de dominio se convierte calladamente en un diagrama del código en vez de del dominio.

Luego para. El diagrama terminado de arriba tiene cuatro clases y responde a una pregunta; añadir Clinic, Room, Invoice e Insurer lo haría más completo y menos útil. Si hay que responder a una segunda pregunta, dibuja una segunda vista sobre el mismo modelo: para eso están las vistas.