Ein Bankensystem in UML
Die meisten Bankbeispiele modellieren ein Konto als Saldo mit einer Einzahlmethode - genau das, was keine Bank tut. Hier die Fassung auf Basis der doppelten Buchführung, dazu der Zustandsautomat, der entscheidet, was eine Überweisung als Nächstes darf.
8 Min. LesezeitUML 2.5.121 von 23
01The account has no balance
Nearly every banking example on the internet gives Account a balance attribute and a pair of methods that add to it and subtract from it. It is the first thing to delete, because no ledger that has to be auditable works that way.
A stored balance is a second copy of a fact the postings already contain. Two copies of a fact can disagree, and when they do - a partial failure, a retried message, a migration - there is no way to tell which is right, because the balance carries no history to check it against. Deriving it, as balance() on the figure above, makes disagreement impossible by construction.
02A transfer is one thing with two effects
The composition on the right of the hero figure is the second load-bearing decision. A Transaction is composed of exactly two Postings - the multiplicity says 2, not 0..* - and by convention they sum to zero: money leaves one account and arrives at another.
Drawing an association from Account straight to Account, which is the obvious first attempt, loses both halves of that. It loses atomicity, because two arrows can exist independently and a transfer cannot half-happen. And it loses the reference: a transaction is a thing customers ask about by number, dispute, and reverse, which means it is an entity and not a line between two others.
The filled diamond then says the postings die with the transaction. That is correct and it is also a constraint on the code: you cannot delete half a transfer, and a reversal is a new transaction rather than an edit to the old one. The class diagram guide has the full rules for when a diamond is filled.
03What a transfer is allowed to do next
A state machine earns its place whenever an object has a lifecycle that rules depend on, and money moving is the archetype. The value is not the four boxes, which anybody could guess - it is the transitions that are absent.
Settled has no outgoing transition. That says a settled transfer is final, and a reversal is a different transaction rather than a state change, which is the same claim the composition on the domain model made. Rejected has none either: an approval after a rejection starts a new transfer. Guards make the rest explicit - reject [limit]names why, and a diagram that says only "reject" leaves the reason to the reader.
In one line each
- 01Delete the balance attribute - derive it from postings, or two copies of one fact will disagree.
- 02A transfer is one Transaction composed of exactly two Postings that sum to zero.
- 03Composition, not association: you cannot delete half a transfer, and a reversal is a new one.
- 04Model the lifecycle where rules depend on it, and read the missing transitions first.
- 05Name the guard on a transition; "reject" alone leaves the reason to the reader.
- 06Channels - ATM, app, branch - belong on a component diagram, not on the ledger.
For the same treatment of a different domain, see e-commerce architecture, modelled. For the data-modelling half of a ledger - keys, cardinality and the schema underneath - see ER diagrams.
04Häufige Fragen
Wie modelliert man einen Kontosaldo in UML?
Als abgeleitete Operation statt als gespeichertes Attribut: balance() summiert die Buchungen des Kontos. Ein gespeicherter Saldo ist eine zweite Kopie einer Tatsache, die das Buch bereits enthält - und an dem Tag, an dem beide auseinandergehen, lässt sich nicht sagen, welche falsch ist.
Wie zeigt man eine Überweisung zwischen zwei Konten?
Als eine Transaktion aus genau zwei Buchungen, einer negativen und einer positiven, deren Summe null ist. Ein Pfeil von Konto zu Konto verliert, dass eine Überweisung eine einzige atomare Sache mit zwei Wirkungen ist - und genau diese Atomarität soll das Modell schützen.
Welche UML-Diagramme braucht ein Bankensystem?
Ein Klassendiagramm für das Hauptbuch, einen Zustandsautomaten für alles mit Lebenszyklus - Überweisungen, Karten, Anträge - und ein Komponentendiagramm für die Grenze zu Zahlungssystemen und Kernbanksystem. Sequenzdiagramme lohnen für die zwei, drei Abläufe, bei denen die Reihenfolge wirklich strittig ist.
Gehört ein Geldautomat auf dasselbe Diagramm wie die Konten?
Nein. Ein Geldautomat ist ein Kanal und gehört mit den übrigen Kanälen auf ein Komponenten- oder Verteilungsdiagramm; das Hauptbuchdiagramm handelt davon, was eine Transaktion ist. Beides zu mischen ergibt das klassische Übungsdiagramm, in dem ein Gerät mit einem Buchhaltungsbegriff assoziiert ist.
Passend dazu