クラスの属性

	そうだね。では、今度はクラスの属性について考えてみよう。
	属性とは、クラスの情報のことですか？
	そうだよ。正しくは、クラスのインスタンスが持っているデータの定義のことなんだよ。例えばこのモデルの「顧客」クラスなら、「名前」、「住所」、「電話番号」などがすぐに思い付くだろう。でも、何でも書けばいいというわけではなくて、その属性は必ず他のオブジェクトから必要とされるものでなくてはならないんだ。例えば、今回のシステムにおいて「顧客」クラスの属性として「身長」や「体重」を書いても、これらの情報はどのオブジェクトも必要としていないし、オブジェクト間のやりとりの中で出てくることもないから、不適切な属性といえるね。
	属性は、問題領域を考えながら記述していくものなのですね？
	そうだよ。だから、属性の多くは、クラスを発見するときに見つかることが多いんだ。
	なるほど、分かりました。
	ところでChen君、先程作成したシーケンス図を見てみよう。予約可能な在庫数を計算する際には実在庫数が必要だが、今のままでは、注文商品を受け付ける度に「在庫情報管理システム」にアクセスして実在庫数を参照することになるよね？
	はい、そうですね。
	そうではなくて、システムの起動時にだけ実在庫情報を参照しておけば、後はこのシステム内で予約可能な在庫数を計算できるようにしたらどうかな？
	つまり、在庫情報をどこかのクラスの属性として持たせるということですか？
	そのとおり。では、どのクラスの属性にすればいいと思うかい？
	「配送センター」クラスの属性としたいところですが、そうすると、どの商品についての在庫情報なのかが分からないですね。でも「商品」クラスの属性とすると、今度はどこの配送センターか分からなくなってしまいますね。うーん、困ったなぁ。
	このように、多対多の多重度の関連を持った「配送センター」クラスと「商品」クラスに「在庫」の情報を持たせたい場合は、インスタンス間の個々のリンクに「在庫」を持たせるという考え方をするんだ。そして、そのリンクそのものをクラスとして実体化したものが、関連クラスである「在庫」クラスなんだよ。ただし、関連クラスは、ひとつの関連に対してはひとつしか持つことができないから注意しておこう。関連クラスは、図3.4.5のように、関連から破線でクラスをぶらさげるんだよ。（図3.4.5）
図3.4.5　関連クラスについて
	また、関連クラスを使うとモデルに柔軟性が出てくるから、将来的に多重度が変わる可能性がある場合にも関連クラスを使ったりするんだよ。
	分かりました。
	ではChen君、それぞれのクラスの属性を考えて、さっき作成したクラス図を更新しよう。

	この図では、各クラスの属性を表示させ、また関連クラスとして「在庫」クラスを追加しています。「顧客」クラスには「顧客ID」、「名前」、「住所」、「電話番号」など、「在庫」クラスの属性としては在庫数を表す「数量」が考えられます。
	この時点で出てくる属性としてはこれぐらいでいいだろう。このシステムで必要とされるデータが属性として定義してあるね。

	では次に、モデルを詳細化していこう。

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