Bankovní systém v UML
Většina bankovních příkladů modeluje účet jako zůstatek s metodou vlož, což je přesně to jediné, co žádná banka nedělá. Tady je verze postavená na podvojném účetnictví a k tomu stavový automat, který rozhoduje, co smí převod udělat dál.
8 min čteníUML 2.5.121 z 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.
04Časté dotazy
Jak se má v UML modelovat zůstatek na účtu?
Jako odvozená operace, ne jako uložený atribut: balance() sečte pohyby na účtu. Uložený zůstatek je druhá kopie údaje, který kniha už obsahuje, a v den, kdy se obě rozejdou, nejde zjistit, která je špatně - přesně proto si ho skutečné účetní knihy nedrží.
Jak zobrazit převod mezi dvěma účty?
Jako jednu transakci složenou přesně ze dvou pohybů, jednoho záporného a jednoho kladného, které dávají součet nula. Šipka z jednoho účtu na druhý ztrácí fakt, že převod je jedna atomická věc se dvěma důsledky - a právě tuhle atomicitu má celý model chránit.
Jaké UML diagramy potřebuje bankovní systém?
Diagram tříd na účetní knihu, stavový automat na cokoli se životním cyklem - převody, karty, žádosti - a diagram komponent na hranici s platebními schématy a jádrovým bankovnictvím. Sekvenční diagramy pomohou u dvou tří toků, kde je pořadí opravdu sporné.
Má být bankomat na stejném diagramu jako účty?
Ne. Bankomat je kanál a patří na diagram komponent nebo nasazení k ostatním kanálům; diagram účetní knihy je o tom, co je transakce. Míchání obojího vyrobí klasický školní diagram, kde je hardwarové zařízení v asociaci s účetním pojmem.
Související články