A banking system in UML
Most banking examples model an account as a balance with a deposit method, which is the one thing no bank does. Here is the version built on double entry, plus the state machine that decides what a transfer is allowed to do next.
8 min readUML 2.5.121 of 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.
04Common questions
How should a bank account balance be modelled in UML?
As a derived operation rather than a stored attribute: balance() sums the postings on the account. A stored balance is a second copy of a fact the ledger already holds, and the day the two disagree there is no way to tell which one is wrong, which is exactly why real ledgers do not keep one.
How do you show a transfer between two accounts?
As one Transaction composed of exactly two Postings, one negative and one positive, summing to zero. Drawing an arrow from one account to another loses the fact that a transfer is a single atomic thing with two effects, and it is that atomicity the whole model exists to protect.
What UML diagrams does a banking system need?
A class diagram for the ledger, a state machine for anything with a lifecycle - transfers, cards, applications - and a component diagram for the boundary with payment schemes and core banking. Sequence diagrams help for the two or three flows where the ordering is genuinely contested.
Should an ATM appear on the same diagram as the accounts?
No. An ATM is a channel and belongs on a component or deployment diagram with the other channels; the ledger diagram is about what a transaction is. Mixing them produces the classic student diagram where a hardware device is associated with an accounting concept.
Related reading