Cómo dibujar un diagrama de clases UML

Step one is to write down how the domain is described out loud and underline the nouns. "A patient books an appointment with a doctor, and the doctor may issue a prescription" gives four candidates immediately. Keep the ones with three properties: identity (two of them can be distinguished), state that changes over time, and a lifetime of their own. A noun failing all three - a colour, an amount, a status - is an attribute of something else.

Step two is one line per sentence you can say about the domain. Not per database join, and not per method call: a line means the two classes know about each other in the business sense. The diagram above is where that ends, and it is already worth putting in front of somebody who knows the domain, because the argument you want is about whether a prescription belongs to an appointment or to a patient - and that argument is available now, before any attribute has been typed.

Every line gets a number at each end before a single attribute is added. This is the step people skip and the one that pays, because a multiplicity is a decision about what the system permits and an attribute is a detail that follows from it.

Read each end as a sentence and say it aloud. "One patient has zero or more appointments" - fine. "One appointment has exactly one patient" - fine, and worth checking, because a clinic that ever books a family slot has just told you otherwise. The three questions to ask at every end are: can it be zero, can it be more than one, and does that change on a bad day?

Then pick the relationship kind, and there are only two decisions worth agonising over. Is the part deleted with the whole - if yes, composition. Does something hold the parent type without caring which subtype - if yes, generalization. Everything else is a plain association, and the worked examples show both calls being made.

Attributes come fourth and each one has to have a source. If you cannot say where a value comes from - a form, another system, a calculation - it is a guess, and guesses are what make a model stop matching the thing it describes. Types are worth writing: startsAt: Instant settles an argument that startsAt: Date leaves open.

Operations come fifth and most classes get none. An operation belongs on a class when the behaviour genuinely needs that class's own state to work - cancel() needs the appointment's status, so it belongs. Anything that needs three other objects to do its job is a service, and putting it here is how a domain model quietly becomes a diagram of the code instead of a diagram of the domain.

Then stop. The finished diagram above has four classes and answers a question; adding Clinic, Room, Invoice and Insurer would make it more complete and less useful. If a second question needs answering, draw a second view over the same model - that is what views are for.