Ein UML-Klassendiagramm zeichnen

Schritt eins ist, aufzuschreiben, wie die Domäne laut beschrieben wird, und die Substantive zu unterstreichen."Eine Patientin bucht einen Termin bei einer Ärztin, und die Ärztin kann ein Rezept ausstellen" liefert sofort vier Kandidaten. Behalten Sie die mit drei Eigenschaften: Identität (zwei davon sind unterscheidbar), Zustand, der sich über die Zeit ändert, und eine eigene Lebensdauer. Ein Substantiv, das an allen dreien scheitert - eine Farbe, ein Betrag, ein Status - ist ein Attribut von etwas anderem.

Schritt zwei ist eine Linie je Satz, den Sie über die Domäne sagen können. Nicht je Datenbank-Join und nicht je Methodenaufruf: eine Linie heißt, dass die beiden Klassen im fachlichen Sinn voneinander wissen. Das Diagramm oben ist, wo das endet, und es lohnt sich schon jetzt, es jemandem vorzulegen, der die Domäne kennt - denn die Diskussion, die Sie wollen, geht darum, ob ein Rezept zu einem Termin oder zu einer Patientin gehört, und die ist jetzt zu haben, bevor ein einziges Attribut getippt wurde.

Jede Linie bekommt an beiden Enden eine Zahl, bevor ein einziges Attribut ergänzt wird. Das ist der Schritt, den man überspringt, und der, der sich auszahlt - denn eine Multiplizität ist eine Entscheidung darüber, was das System zulässt, und ein Attribut ein Detail, das daraus folgt.

Lesen Sie jedes Ende als Satz und sprechen Sie ihn aus. "Eine Patientin hat null oder mehr Termine" - in Ordnung. "Ein Termin hat genau eine Patientin" - in Ordnung, und prüfenswert, denn eine Praxis, die je einen Familientermin vergibt, hat Ihnen gerade das Gegenteil gesagt. Die drei Fragen an jedem Ende lauten: kann es null sein, kann es mehr als eins sein, und ändert sich das an einem schlechten Tag?

Dann wählen Sie die Beziehungsart, und nur über zwei Entscheidungen lohnt sich Grübeln. Wird der Teil mit dem Ganzen gelöscht - wenn ja, Komposition. Hält etwas den Elterntyp, ohne sich um den Untertyp zu kümmern - wenn ja, Generalisierung. Alles andere ist eine schlichte Assoziation, und die durchgearbeiteten Beispiele zeigen beide Urteile in Aktion.

Attribute kommen viertens, und jedes braucht eine Quelle. Wenn Sie nicht sagen können, woher ein Wert stammt - ein Formular, ein anderes System, eine Berechnung -, ist er geraten, und Geratenes ist das, was ein Modell aufhören lässt, zu dem zu passen, was es beschreibt. Typen aufzuschreiben lohnt sich: startsAt: Instant entscheidet eine Frage, die startsAt: Date offenlässt.

Operationen kommen fünftens, und die meisten Klassen bekommen keine. Eine Operation gehört an eine Klasse, wenn das Verhalten wirklich deren eigenen Zustand braucht - cancel() braucht den Status des Termins, gehört also dorthin. Alles, was drei andere Objekte braucht, um seine Arbeit zu tun, ist ein Service, und es hierher zu setzen ist der Weg, auf dem ein Domänenmodell still zum Diagramm des Codes statt der Domäne wird.

Dann hören Sie auf. Das fertige Diagramm oben hat vier Klassen und beantwortet eine Frage; Clinic, Room, Invoice und Insurer zu ergänzen machte es vollständiger und weniger nützlich. Muss eine zweite Frage beantwortet werden, zeichnen Sie eine zweite Sicht über dasselbe Modell - dafür gibt es Sichten.