［奇妙なクラスと実世界］
２．銀行アプリケーションの事例
２．１ 典型的な分析モデル
ここでは、銀行システムにおける簡単な預金アプリケーションを例にとって話を進めることにしましょう。
図１に分析段階のクラス図を示します。
ここでは、以下に述べる６つのクラスが導出されています。
その銀行と取引のある顧客。
属性として「氏名」「住所」「電話番号」を持ち、顧客情報を登録、抹消するための振る舞いが定義されている。
ある顧客がその銀行で保有する、個々の預金口座。
一人の顧客は複数の口座を保有することが可能で、「口座番号」や「残高」が属性として定義されている。
また口座を新規に開設したり、入出金や解約をするための振る舞いを持っている。
ATMなどを利用して取引をする際に必要となるカード。
このシステムでは、カードは顧客の希望により、最大1枚まで発行できる。 本人確認のための暗証番号を検査する振る舞いが定義されている。
預金口座の取引内容を記録するための通帳。
通帳の印字に責任を持っており、そのための振る舞いが定義されている。
預金口座に対して実行された個々の取引（新規、入金、出金など）の内容が記録された履歴。
過去の取引照会や監査証跡などで利用される。
取引の内容を属性として保持しており、取引を記録するための振る舞いが定義されている。
カレンダーに関する手続きを集めたヘルパークラス。
休日判定（休日のATM取引の場合には通常手数料が徴収される）や、各種利息計算で必要な日数計算などの振る舞いが定義されている。
ここに書かれたクラス図は実際のアプリケーションを構築する上では不十分なものでしょう。
なぜなら、顧客の住所や電話番号を変更することができませんし、普通預金や定期預金といった預金種類の違いも考慮されていません。
実際のアプリケーションにおいては、ここに登場したクラスは、より多くの属性や振る舞いを持ち、周辺にはさらにたくさんのクラスが定義されることでしょう。
ただし業務範囲を限定すれば、概ね妥当な分析モデルといっても良いでしょう。
登場する6つのクラスはすべて現実世界に存在するものです。
「顧客」「カード」「通帳」「カレンダー」は、私たちが実際に目にすることが可能な、実体を伴った存在です。
「預金口座」は概念的なものであり、これを直接見ることはできませんが、顧客が銀行に置いてある自分用の仮想的な財布とでも考えておけば良いでしょう。
（余談ですが、最近ではこの財布には穴が空いていて、不良債権にどんどん流れてしまっているようですね．．．）
「取引履歴」も同様に実体はありませんが、金銭出納帳の1行と考えれば、実体とみなしても良いでしょう。
ここでは現実世界に存在する実体や概念は中核クラスとしてほぼ導出されていますし、個々のクラスの役割やクラス間の関連もほぼ明確になっています。
またこのモデルを使って、エンドユーザーと業務仕様についてのディスカッションをすることも期待できるでしょう。
オブジェクト指向による分析段階のモデルとしては、まずは及第点と言ったところでしょうか。
| © 1999 OGIS-RI Co., Ltd. |
|
