クレジット請求

とある雑誌で上がっていたサンプルをもとにモデリングにチャレンジ。

概念モデル クラス図

分析モデル 請求クラス

台帳を作成・分析してクラス図を作成

分析モデル カードクラス

口座をトップレベルのエンティティとしてはじめはとらえていましたが、契約のエンティティが識別され、かつ契約の構成要素として取り扱うことができそうなので、トップレベル扱いする必要がない可能性が高くなりした。口座台帳なるものはビジネス上必要なく、口座（番号）は契約の属性扱いで十分のようです。

このような管理単位を判断する方法として役立つのがエンティティ・インスタンスのライフサイクルを調べる方法です。このシステムにおいては、必ず、契約者の口座のライフサイクルはカードの契約と基本的に同じか短くなることを前提にすると、契約に関連づけられない口座の管理は行わない、必ず口座は契約に関連づけられるということになります。

分析モデル ロバストネス分析

サービス・ビジネスルールの識別

ポイントや利息計算は契約タイプによって決定される前提に立って整理すると、契約タイプを導入してクラス図を改訂。

請求_利用明細はもっと独立した利用明細があるはずだが、ここではこのままにしておきます。

答え合わせ

答え合わせをしたところ、まず、カードと契約の考え方がちがっていた。この点は、カード会社であればさまざまな種類のカードが取り扱えるほうが良く、より一般化しているモデルのほうがいいと思う。したがって、サブタイプ化していないほうが良いと思う。
次に、支払区分が利用明細にある。ようはカード利用時に支払区分が決まるというビジネスルールである。確かに普通はそうで、これはこの方が良いですね。モデルがより複雑になりそうですが、途中で支払方法を変えるビジネスルールがあれば、請求明細の支払区分も事実として残しておくのも悪くないかもしれません。
あと、答えのほうにはリボ定額料も利用明細にあったのですが、これもどうしてなんでだろう？リボ定額料は特定の利用明細にひもづく必要がないように思うのだが．．．