クラスの操作

	では、このシーケンス図をもとに、それぞれのクラスの操作を考えてみよう。操作とは、あるオブジェクトからの要求で起動することのできるサービスのことなんだよ。主に、シーケンス図で表したメッセージから発見されることが多いんだ。なぜなら、シーケンス図で表されるメッセージはたいてい、メッセージを受けるクラスの操作だからね。また、クラスの操作を考えていくうちに、新しいクラスや関係が発見されることもあるから、その場合は随時新しい情報を図に反映させるようにしよう。
	分かりました。操作の書き方で注意することはありますか？
	操作の書き方だが、分析の段階では、お客様にも分かるような名前を付けたほうがいいね。それから、属性を考えるところでも話したように、操作についても、問題領域に応じたものだけを作成していくようにしよう。
	はい。それでは、操作を追加し、クラス間の関係を見直してクラス図を更新してみます。

	シーケンス図を見ると、「注文」クラスに対しては、新規に注文を作成するメッセージ、顧客情報の確認をするメッセージ、個々の注文を入力していくメッセージ、予約するメッセージ、注文を完了するメッセージが送られています。だから、「注文」クラスの操作としては、「新規注文の作成」、「顧客情報の確認」、「注文商品の入力」、「予約」、「注文の完了」という操作が必要だと考えました。また、「在庫」クラスでは、予約可能な在庫数を取得する「予約可能な在庫数の取得」や、予約されたときに在庫数を減算するような「在庫予約」という操作があると思います。
	そうだね。シーケンス図のメッセージの情報を、クラス図にちゃんと反映できているね。
	Jun先輩、ここでは、操作の引数も考えておかなければいけないのでしょうか？
	分かっている程度は書いておいてもいいが、設計段階で追加すればいい情報だから、ここではそんなに意識しなくていいよ。
	はい、分かりました。
	ところで、今回更新されたクラス図では、「注文商品」クラスと「在庫」クラスとの間に関連が引かれているようだが？
	はい。「在庫」クラスに「在庫予約」という操作が必要だからです。これは、「在庫」クラスの属性である在庫数から、予約された注文数（「注文商品」クラスの属性）を引いて予約可能な在庫数を計算しておくという操作です。（図3.5.4で詳しく説明）

	よく考えたね。確かに、こうすると予約可能数を計算しておくことができるようになるね。
	「在庫」クラスと「注文商品」クラスとの間の関連には「引き当てる」という関連名を付け、多重度は「１対０以上」としました。ひとつの商品に対して、全然注文がない場合と、複数の個別注文がある場合があり得るからです。
	そうだね。このように、シーケンス図において、あるオブジェクトから別のオブジェクトへメッセージが投げられている場合、該当するクラスどうしは何らかの形で関係を持っている必要があるんだよ。さらに、「シーケンス図」の情報をもとに、「クラス図」に必要な関係、操作、属性をトレースして、不足している情報がないか、整合性がとれているか、などを考えてモデルを詳細化していくことが大事なんだよ。こうすることで、新しい情報が発見されることもあるからね。これは、分析においても設計においても同じだよ。

	はい、勉強になりました。
	では次に、ステートチャート図を作成しよう。

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