図5●顧客管理システムのヒアリング結果を基に作成したユース・ケース図
図5●顧客管理システムのヒアリング結果を基に作成したユース・ケース図
[画像のクリックで拡大表示]
図6●顧客管理システムのクラス図(その1)<BR>すべての名詞がクラスになると仮定した場合のクラス図
図6●顧客管理システムのクラス図(その1)<BR>すべての名詞がクラスになると仮定した場合のクラス図
[画像のクリックで拡大表示]
図7●顧客管理システムのクラス図(その2)&lt;BR&gt;属性と操作の案を書き加えたクラス図
図7●顧客管理システムのクラス図(その2)<BR>属性と操作の案を書き加えたクラス図
[画像のクリックで拡大表示]
図8●顧客管理システムのクラス図(その3)&lt;BR&gt;クラス間の関連を書き加えたクラス図
図8●顧客管理システムのクラス図(その3)<BR>クラス間の関連を書き加えたクラス図
[画像のクリックで拡大表示]
図9●「顧客情報を登録する」というユース・ケースのシーケンス図
図9●「顧客情報を登録する」というユース・ケースのシーケンス図
[画像のクリックで拡大表示]
図10●「顧客情報を登録する」というユース・ケースのコラボレーション図
図10●「顧客情報を登録する」というユース・ケースのコラボレーション図
[画像のクリックで拡大表示]

要求分析1●ユース・ケース図の作成

 オブジェクト指向とUMLの基礎知識,および,開発工程とUMLの各図の関係が確認できたところで,いよいよ実践に進もう。今回はまず,要求分析の方法の一部と,その際に作成するUMLの図を説明する。ここでは,開発者である皆さんが,ユーザーから以下のような「顧客管理システム」の依頼を受けたと仮定して話を進める。

【ユーザーのヒアリング結果】

 当社は,社長,3名の営業員,事務員からなる事務機の販売店です。これまでは顧客情報を営業員が個別に管理してきましたが,それをコンピュータで一元管理したいと思います。事務員がシステム管理者となって,営業員の持つ顧客情報をコンピュータに登録します。営業員は,顧客情報の閲覧と印刷だけができるようにして下さい。社長は,すべての操作ができるようにして下さい。顧客は,大きく分けて企業と個人です。

 ユーザーのヒアリング結果を基に,ユース・ケース図を作成しよう。まず,システムの利用者であるアクターの洗い出しから始める。ヒアリング内容から,「社長」,「営業員」,「事務員」がアクターになる。顧客は,システムを使う人ではないためアクターではない*1

 次に,ユース・ケースを洗い出す。ユース・ケースはアクターから見たシステムの機能なので,「顧客情報を登録する」,「顧客情報を閲覧する」,「顧客情報を印刷する」がユース・ケースになる。ただし,ヒアリング結果が完ぺきとは限らないので,開発者の判断でアクターやユース・ケースを追加することもある。ここでは,「データをバックアップする」というユース・ケースを追加しておこう。

 以上をユース・ケース図に表すと,図5[拡大表示]のようになる。この図をユーザーとレビューすれば,「あれっ? やっぱり事務員にもデータの閲覧ができた方が便利だなあ」といったことが見えてくる。そうやってレビューした結果をユース・ケース図に反映させれば良い。

要求分析2●クラス図の作成

 今度は,クラス図を作成しよう。クラスの候補は,要求仕様の中に登場する名詞である。ユーザーのヒアリング結果(これがシステムの要求仕様だとする)の中には,「当社」,「社長」,「営業員」,「事務員」,「事務機」,「販売店」,「顧客情報」,「コンピュータ」,「システム管理者」,「企業」,「個人」という名詞がある。この中からクラスを決定しなければならないが,とりあえず,すべての名詞がクラスになると仮定してクラス名だけのクラス図を作成すると図6[拡大表示]のようになる。

 システムの要求分析や設計に,絶対的な正解というものは無い。図6のクラス構成のまま開発を進め,プログラムを作成することも可能だろう。しかし図6のクラス構成は全く整理されておらず,そのままでは効率的な開発が望めない。クラス図を整理するには,個々のクラスに属性や操作の案を少しだけ書き加える。システムの目的を達成するのに必要になりそうな属性と操作を,少しだけ考えてみる。そうすることでクラス候補同士の関係が見え,クラス図を整理するためのアイデアが思い付きやすくなる。

 図6のクラス候補に属性と操作の案を書き込んだのが図7[拡大表示]である。図7を作成したことで,5つのことが見えてきた。

 (1)社長クラス,営業員クラス,事務員クラスは,複数の同じ属性を持っている。このことから,これらのクラスは1つのスーパー・クラス*継承*したクラスとして整理できる*2。ここでスーパー・クラスを「社員クラス」とする。(2)コンピュータ・クラスの適当な属性と操作が思い付かなかったことから,これはクラスとして適当ではない。(3)企業クラス,個人クラス,事務機クラスは,顧客情報クラスの顧客種別属性の値とするのが適当である*3。(4)当社クラスと販売店クラス,および,事務員クラスと管理者クラスは同じものを表しているので,どちらか一方だけでよい。ここでは,当社クラスと事務員クラスを使うことにする。(5)当社クラスと他のすべてのクラスの間に包含*関係がある*4

 以上を考慮してクラスを整理し,クラス間の関連を書き加えたクラス図が図8[拡大表示]である。図8では分かりやすくするために,属性や操作は省略している。図8のクラス図が絶対的な正解である保証は無い。だが,図6のクラス図と比べると,クラスの数は11個から6個と少なくなるなど,整理されていることは誰が見ても明らかだろう。

要求分析3●シーケンス図とコラボレーション図の作成

 オブジェクト間の相互作用を示す「シーケンス図」と「コラボレーション図」は,要求分析の工程で詳細に作成する必要は無い。だが,システムを吟味するために,メッセージ・パッシングの概要を示す程度の図を作成するのは有効である。

 図9[拡大表示]は,「顧客情報を登録する」というユース・ケースのシーケンス図である。メッセージ・パッシングとはオブジェクトの持つ操作を呼び出すことなので,メッセージを表す矢印と操作の名前を記述する。どのような操作があるかは,クラス図に記した操作名を見れば分かる。図9では,事務員オブジェクトが顧客情報オブジェクトの「登録する」という操作を呼び出すことを示している。Windowsアプリケーションで実装する場合,利用者(アクター)はGUI上のボタンなどを選択することになる。それは図9左のように,アクターと「[登録]ボタン」と記した矢印で示せば良い。同じユース・ケースをコラボレーション図で表すと,図10[拡大表示]のようになる*5


矢沢 久雄
グレープシティ(旧文化オリエント) アドバイザリースタッフ