（１） 新システムのクラス一覧

クラス種別 クラス名 機能

バウンダリクラス 審査官I/F

審査長I/F

顧客I/F

信用調査会社I/F

審査官が利用する画面

審査長が利用する画面

顧客が利用するインタフェース（電話）

信用調査会社が利用する画面

コントロールクラス 審査

決裁

審査官による審査をコントロール

審査長による決裁をコントロール

エンティティクラス 未処理の申請書リスト

申請書

審査中リスト

信用調査会社1

信用調査会社2

信用情報１

信用情報2

審査結果

最終結果データベース

未処理の申請書データベース

顧客（申請者）の個人情報を持つ

審査中の申請者データベース

システムへ信用情報1の提供を行う

システムへ信用情報2の提供を行う

消費者金融関係の信用情報

銀行・流通関係の信用情報

審査の結果・判定などを記述

システムは、決済を終了した関連書類を登録

（２） 新システムのクラス図

審査官

I/F

審

査

未処理の申請者リス

ト

申請

書

最終結果データベース

審査中リスト

信用調査会社

I/F

信用情報1

信用情報2

信用調査会社

2

信用調査会社

1

決

裁

審査長

I/F

審査結

果

顧客

I/F

（３） 新システムのシーケンス図

審査官

I/F

顧客

I/F

審

査

決

裁

未処理リスト 申請

書

審査開始：

審査1：

審査2：

決裁：

書類の受付

未処理リスト

の検索 審査中リスト

への移行

審査中リスト審査長

I/F

調査会社

I/F

情報1 情報2 審査結

果

最終結

果

情報1の提供 情報2の提供

電話

身元確認

検索

電話番号

の取得

審査2の

結果

審査1の

結果

決裁 関連づけ

登録

消費者金融

銀行・流通

関係

削除

選択

バウンダリクラスの説明

●審査官I/F審査官が審査1及び2を行うためのインタフェースである。

業務内容の異なる審査長とは別のインタフェースとした。

●審査長I/F審査長が決裁を行うためのインタフェースである。

●顧客I/F審査2において審査官より電話連絡を受けるためのインタフェースである。

実態は電話機であるため、不要とも考えられるがシステムの理解には必要と判断し

盛り込んだ。

●信用調査会社I/F信用調査会社より信用情報の提供を受け付けるためのインタフェースである。

実態はオンラインデータベースであるため、不要とも考えられるがシステムの理解

には必要と判断し盛り込んだ。

コントロールクラスの説明

●審査審査官による審査の流れをコントロールする。

具体的には審査開始と審査官による審査1及び2をコントロールする。

●決裁審査長による決裁の流れをコントロールする。

具体的には決裁と審査終了をコントロールする。

●分割の理由仮に審査官及び審査長を分割せずに審査I/F・審査コントロールクラスのみとした場

合に、とりわけ審査コントロールクラスに対して記述すべき内容が多くなりすぎて

しまう。

このようなことを回避するため、審査官及び審査長を分割し、それぞれにインタフ

ェース及びコントロールクラスを割り当てることとした。

＊エンティティクラスについては、(1) 新システムのクラス一覧の機能欄を参照

考察

＝ソフトウェア開発法2 ＝

●システム設計の際には、どの程度の曖昧性を

持ち記述するのかが、非常に大切になってく

る。今回の例では、当初「審査I/F・審査コン

トロールクラス」のセットのみで記述するこ

とを考えていたが、結果的に審査コントロー

ルクラスが非常に大きくなりすぎてしまった

。そのようなクラスは実装が難しいことが多

く、分割可能であることを示していると考え

られる。

以上