クラスの抽出

「クラス図」は、対象領域やシステムの静的な構造を表すもので、「クラス」と「クラス間の静的な関係」を図に表現していくんだよ。

＜＜クラス図＞＞

◆「クラス図」ってどんな図？

クラス図は、モデルの静的な構造を表す図。
システムの機能に着目して、問題領域を論理的、静的に見るための図。
設計段階では、開発者の視点からモデルが詳細化される。

◆「クラス図」

　 wd_06

		クラス
		クラスはデータ構造（属性）と振る舞い（操作）、そして他の要素への関係を持つ。属性とは、クラスのインスタンスが持っているデータの定義のこと。特定のオブジェクトに対する属性の値を「属性値」という。操作とは、クラスのインスタンスの振る舞いのこと。操作は、あるオブジェクトからの要求で起動することのできるサービス。
		クラス間の関係
		クラスとクラスはお互いに協調し合って動作しており、それはクラス間の関係を通して実現される。関係には、「関連」、「集約」、「汎化」などがあるが、分析段階では、「関連」と「集約」を中心に使用する。「関連」は、クラスとクラスの間の双方向の意味的な接続。「集約」は関連の一種で、全体とその部分との関係を表す。「汎化」は、継承構造を定義するための関係で、再利用を考慮した概念。実装よりの概念なので、設計段階で定義することが多い。
		多重度
		多重度とは、あるクラスの１つのインスタンスが、もう一方のクラスのいくつのインスタンスと関係するかを表す数。多重度から、次の2つのことが分かる。関連は必須か任意かひとつのインスタンスと関連することができる他方のインスタンスの最小、最大の数はいくつか
		ロール
		ロールは、あるクラスが他のクラスと関連する目的、立場または能力を示す。ロール名は必須ではなく、モデルに意味を付加する場合にのみ使用すればよい。

まず、クラスの抽出から始めよう。クラスの抽出とは、クラスを見つけ出すことだよ。

クラスはどうやって見つけるのですか？

先程作成してもらったシナリオから、クラスの候補となる名詞や名詞句を検討するんだよ。それらはオブジェクトの候補になるから、そこからクラスを導き出し、それがクラスとして適切かどうかを判断していくんだ。

ill_21

シナリオから名詞を検討したところ、クラスの候補として次のようなものが考えられました。（図3.4.1）

図3.4.1　Chen君が考えたクラスの候補

登録顧客	注文商品
顧客係	注文票
お客様番号	配送票
大阪配送センター	注文受付画面
神戸配送センター

なるほど。では、Chen君が見つけ出したクラスの候補が本当にクラスとして適切かどうかを判別することにしよう。名詞を取り出すことは簡単だが、その後のフィルタリングがとても重要で、難しいところなんだよ。システムにとっての単一の概念を探すことがポイントなんだ。

顧客係はアクターなので、クラスにはならないですね。また、「大阪配送センター」と「神戸配送センター」は両方とも配送センターの具体例（オブジェクト）なので、抽象化して「配送センター」クラスにできると思います。

そうだね。また、Chen君が考えたクラスの候補の中には、状態を指していたり、クラスの持つ情報を表している単語も含まれているようだね。「登録顧客」は顧客が登録されているかされていないかという状態を表しているから、「登録顧客」クラスではなく、「顧客」クラスとなるだろう。それに、「お客様番号」も「顧客」クラスが持っている情報だと考えられるから、クラスとは言えないね。

なるほど、そうですね。状態かどうかという判別は難しいですね。

「注文票」と「配送票」については、それぞれ注文情報と配送情報を持ったクラスという意味で「注文」クラスと「配送」クラスにしてもいいかもしれないね。

はい、そうですね。

それから、「注文受付画面」クラスは確かに大事なクラスなんだが、画面などのインターフェースとなるクラスについては設計段階で考えていくので、ここで作成するクラス図のモデルには含めなくていいよ。

分かりました。

ill_20

では、シナリオには登場していないが、他に必要と思われるクラスはないかな？

えーっと、「注文商品」クラスは商品ごとの注文情報だけで、商品そのものの情報は持っていないですよね。ですから、商品名や定価の情報を持つ商品マスタのような「商品」クラスが必要ではないでしょうか？

そうだね。では、ここまでで抽出されたクラスをまとめてみよう。（図3.4.2）

図3.4.2　抽出したクラス
wd_07

この後で作成する図によっても、新しいクラスが発見されたり、クラス名が変わってきたりする場合があるから、この時点で考えられるクラスがすべてとは限らないことを頭に置いておこう。

分かりました。

【チュートリアル】 - 分析編