Ein Bankensystem in UML

Nahezu jedes Bankbeispiel im Internet gibt Account ein balance-Attribut und ein Paar Methoden, die darauf addieren und davon subtrahieren. Das ist das Erste, was zu löschen ist, denn kein prüfbares Hauptbuch funktioniert so.

Ein gespeicherter Saldo ist eine zweite Kopie einer Tatsache, die die Buchungen bereits enthalten. Zwei Kopien einer Tatsache können sich widersprechen, und wenn sie es tun - ein Teilausfall, eine wiederholte Nachricht, eine Migration - lässt sich nicht sagen, welche stimmt, weil der Saldo keine Historie trägt, an der man ihn prüfen könnte. Ihn abzuleiten, wie balance() in der Abbildung oben, macht Widerspruch schon durch die Konstruktion unmöglich.

Die Komposition rechts in der Titelabbildung ist die zweite tragende Entscheidung. Eine Transaction ist aus genau zwei Buchungen komponiert - die Multiplizität sagt 2, nicht 0..* - und sie ergeben per Konvention in der Summe null: Geld verlässt ein Konto und kommt auf einem anderen an.

Eine Assoziation direkt von Account zu Account zu zeichnen, der naheliegende erste Versuch, verliert beide Hälften davon. Sie verliert die Atomarität, denn zwei Pfeile können unabhängig existieren, und eine Überweisung kann nicht halb geschehen. Und sie verliert die Referenz: eine Transaktion ist etwas, wonach Kunden per Nummer fragen, was sie beanstanden und stornieren - also eine Entität und keine Linie zwischen zwei anderen.

Die gefüllte Raute sagt dann, dass die Buchungen mit der Transaktion sterben. Das ist richtig und zugleich eine Einschränkung für den Code: Sie können keine halbe Überweisung löschen, und eine Stornierung ist eine neue Transaktion statt einer Änderung der alten. Der Leitfaden zum Klassendiagramm hat die vollständigen Regeln, wann eine Raute gefüllt ist.

Ein Zustandsautomat verdient seinen Platz immer dann, wenn ein Objekt einen Lebenszyklus hat, von dem Regeln abhängen, und Geld in Bewegung ist der Archetyp. Der Wert sind nicht die vier Kästen, die jeder erraten könnte - es sind die Übergänge, die fehlen.

Settled hat keinen ausgehenden Übergang. Das sagt, dass eine ausgeglichene Überweisung endgültig ist und eine Stornierung eine andere Transaktion statt einer Zustandsänderung - dieselbe Aussage, die die Komposition im Domänenmodell gemacht hat. Rejected hat auch keinen: eine Genehmigung nach einer Ablehnung startet eine neue Überweisung. Wächter machen den Rest ausdrücklich - reject [limit]benennt das Warum, und ein Diagramm, das nur "reject" sagt, überlässt den Grund der Leserin.

Für dieselbe Behandlung einer anderen Domäne siehe E-Commerce-Architektur, modelliert. Für die datenmodellierende Hälfte eines Hauptbuchs - Schlüssel, Kardinalität und das Schema darunter - siehe ER-Diagramme.