Un système bancaire en UML

Presque tous les exemples bancaires d'internet donnent à Account un attribut balance et une paire de méthodes qui y ajoutent et en retranchent. C'est la première chose à supprimer, car aucun grand livre devant être auditable ne fonctionne ainsi.

Un solde stocké est une seconde copie d'un fait que les écritures contiennent déjà. Deux copies d'un même fait peuvent diverger, et quand elles le font - une panne partielle, un message rejoué, une migration - rien ne permet de dire laquelle a raison, parce que le solde ne porte aucun historique auquel le confronter. Le dériver, comme balance() sur la figure ci-dessus, rend la divergence impossible par construction.

La composition à droite de la figure d'ouverture est la deuxième décision structurante. Une Transaction est composée d'exactement deux écritures - la multiplicité dit 2, pas 0..* - et par convention leur somme est nulle : l'argent quitte un compte et arrive sur un autre.

Dessiner une association d'Account directement vers Account, ce qui est la première tentative évidente, perd les deux moitiés de cela. Cela perd l'atomicité, car deux flèches peuvent exister indépendamment et un virement ne peut pas se produire à moitié. Et cela perd la référence : une transaction est une chose dont les clients parlent par son numéro, qu'ils contestent et qu'ils annulent, donc une entité et non un trait entre deux autres.

Le losange plein dit ensuite que les écritures meurent avec la transaction. C'est correct et c'est aussi une contrainte sur le code : vous ne pouvez pas supprimer la moitié d'un virement, et une annulation est une nouvelle transaction plutôt qu'une modification de l'ancienne. Le guide du diagramme de classes détaille toutes les règles disant quand un losange est plein.

Une machine à états mérite sa place chaque fois qu'un objet a un cycle de vie dont dépendent des règles, et l'argent qui circule en est l'archétype. La valeur n'est pas dans les quatre boîtes, que n'importe qui devinerait : ce sont les transitions absentes.

Settled n'a aucune transition sortante. Cela dit qu'un virement réglé est définitif et qu'une annulation est une autre transaction plutôt qu'un changement d'état - la même affirmation que faisait la composition sur le modèle de domaine. Rejected n'en a pas non plus : une approbation après un refus démarre un nouveau virement. Les gardes rendent le reste explicite : reject [limit]nomme le pourquoi, et un diagramme qui dit seulement "reject" laisse la raison au lecteur.

Pour le même traitement sur un autre domaine, voyez l'architecture e-commerce, modélisée. Pour la moitié modélisation de données d'un grand livre - clés, cardinalité et schéma sous-jacent - voyez les diagrammes ER.