Bankovní systém v UML

Téměř každý bankovní příklad na internetu dá třídě Account atribut balance a dvojici metod, které k němu přičítají a odečítají. Je to první věc ke smazání, protože žádná účetní kniha, která musí být auditovatelná, takhle nefunguje.

Uložený zůstatek je druhá kopie faktu, který zápisy už obsahují. Dvě kopie jednoho faktu si mohou odporovat, a když si odporují - částečné selhání, opakovaná zpráva, migrace - nedá se zjistit, která je správná, protože zůstatek nenese historii, proti které by se dal ověřit. Odvodit ho, jako balance() na obrázku výše, dělá rozpor nemožným už konstrukcí.

Kompozice vpravo na titulním obrázku je druhé nosné rozhodnutí. Transaction je složená z právě dvou zápisů - násobnost říká 2, ne 0..* - a konvencí dávají v součtu nulu: peníze z jednoho účtu odejdou a na druhý přijdou.

Nakreslit asociaci z Account rovnou na Account, což je zřejmý první pokus, ztratí obě ty poloviny. Ztratí atomicitu, protože dvě šipky mohou existovat nezávisle a převod se nemůže stát napůl. A ztratí referenci: transakce je věc, na kterou se zákazníci ptají podle čísla, rozporují ji a stornují, což znamená, že je entitou, a ne čárou mezi dvěma jinými.

Plný kosočtverec pak říká, že zápisy zemřou s transakcí. To je správné a je to zároveň omezení pro kód: nemůžete smazat polovinu převodu a storno je nová transakce, ne úprava té staré. Průvodce diagramem tříd má kompletní pravidla, kdy je kosočtverec plný.

Stavový automat si zaslouží místo vždy, když má objekt životní cyklus, na kterém závisí pravidla, a pohyb peněz je archetyp. Hodnotou nejsou ty čtyři boxy, které by uhodl každý - jsou to přechody, které chybí.

Settled nemá odchozí přechod. To říká, že vyrovnaný převod je konečný a storno je jiná transakce, ne změna stavu - což je totéž tvrzení, jaké udělala kompozice na doménovém modelu. Rejected ho nemá také: schválení po zamítnutí začíná nový převod. Stráže dělají zbytek explicitním - reject [limit]pojmenovává proč, a diagram, který říká jen "reject", nechává důvod na čtenáři.

Pro totéž zpracování jiné domény viz e-shopovou architekturu, namodelovanou. Pro datovou polovinu účetní knihy - klíče, kardinalitu a schéma pod tím - viz ER diagramy.