<?xml version='1.0' encoding='Shift_JIS' ?>
<doc xml:lang='ja'>
	<body>
		<p>設計フェーズの目的は、分析フェーズで分析されたモデルを、プログラムを記述するためのモデルに変換することです。
			このフェーズでも、分析フェーズと同様にUMLを用いて記述します。</p>
		<p>このフェーズで作成するのは以下の図です。</p>
		<ul>
			<li>設計モデルクラス図</li>
			<li>行動間シーケンス図</li>
			<li>行動状態遷移図</li>
		</ul>
		<p>本チュートリアルの設計フェーズでは英語を使います。これは、より"プログラム"に近いモデルを書くためで、
			実装プログラムとの関係がわかりやすいと判断したためです。
			Javaでは、クラス名や変数名に日本語が使えますが、一般的ではないので本チュートリアルでのプログラムは 英語を使っています。</p>
		<subsection title="基礎モデルフレームワークを使った設計">
			<p>このフェーズで行われる設計は、基礎モデルフレームワーク上で動作することを意識して行います。
				ここで、基礎モデルフレームワークの基本をおさらいしておきましょう。</p>
			<subsubsection title="Typeを利用する設計? 継承を利用する設計?">
				<p>分析フェーズでは、登場事物の表現に全て継承を用いていました。
					しかし概念的には継承でも、設計・実装で継承を利用するとは限りません。
					継承を使った実装には、動的な変更ができない、多重継承ができないといった限界がありますし、
					実装のしやすさや効率などの要因で継承を使えないこともあります。</p>
				<p>そのまま継承として実装する方法以外で分析モデルでの継承を実装する方法として、
					パワータイプ（べき型）を使った設計が代表的です。 これは、種類クラスを作って種類をインスタンスで実現するというものです。
					基礎モデルフレームワークでは、この2つの手法をうまく組み合わせることで、
					拡張性が高く、かつ実装しやすいモデルを作ることが出来るように配慮されています。</p>
				<p>基礎モデルフレームワークにおいて、パワータイプの型クラスとしてTypeというクラスが用意されています。
					例えば、Agentであれば、AgentType、つまり「エージェントの種類」というクラスが提供されているので、
					インスタンスとして、「個人」「法人」を生成することで、
					直接Agentを継承することなく、エージェントの種類を実装することが出来ます。</p>
				<p>基礎モデルフレームワークでは、基礎モデルでの概念の種類に対応して、
					継承、Typeのどちらを使った設計を利用するべきかが決まっています。 まとめたものが以下の表です。</p>
				<table style="width:100%" title="利用できる設計方法">
					<thead>
						<tr>
							<th>基礎モデルでの概念</th>
							<th>クラス名</th>
							<th>継承を使った設計</th>
							<th>Typeを使った設計</th>
							<th>Typeクラス名</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>エージェント</td>
							<td>Agent</td>
							<td>×</td>
							<td>○</td>
							<td>AgentType</td>
						</tr>
						<tr>
							<td>関係</td>
							<td>Relation</td>
							<td>×</td>
							<td>○</td>
							<td>RelationType</td>
						</tr>
						<tr>
							<td>財</td>
							<td>Goods</td>
							<td>×</td>
							<td>○</td>
							<td>GoodsType</td>
						</tr>
						<tr>
							<td>情報</td>
							<td>Information</td>
							<td>○</td>
							<td>○</td>
							<td>InformationType</td>
						</tr>
						<tr>
							<td>行動</td>
							<td>Behavior</td>
							<td>○</td>
							<td>○</td>
							<td>BehaviorType</td>
						</tr>
					</tbody>
				</table>
				<p>以降、この設計の種類ごとに詳しい設計の方法を説明します。</p>
			</subsubsection>
			<subsubsection title="イベントと状態遷移を利用した設計">
				<p>基礎モデルフレームワークでは、動的な振る舞いを規定する方法として、状態遷移モデルを採用しています。
					そのため、状態遷移モデルの設計が重要です。 実際に設計フェーズでは、ほとんどの時間が振る舞いの状態遷移モデルの設計に費やされます。</p>
				<p>美しく、かつ確実な動作をする状態遷移モデルを設計するポイントは、</p>
				<ul>
					<li>何を「状態」とするか</li>
					<li>どのようなイベントを受け取ったときに状態が遷移するか</li>
				</ul>
				<p>の2点です。特に2つ目の「どのようなイベントを受け取ったときに状態が遷移するか」を考える際に、
					基礎モデルフレームワークでのイベントの定義を意識する必要があります。</p>
				<p>以下の表で、基礎モデルフレームワークで定義されているイベントをおさらいしておきましょう。
					特に、重要度が○の2つのイベントを押さえておきましょう。</p>
				<table style="width:100%" title="利用できるイベントの種類">
					<thead>
						<tr>
							<th>イベント名</th>
							<th>重要度</th>
							<th>説明</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>TimeEvent</td>
							<td>○</td>
							<td>時間が経過すると全てのエージェント、行動が1つずつ受信します。(※)</td>
						</tr>
						<tr>
							<td>ChannelEvent</td>
							<td>○</td>
							<td>経路を通して財が送られてくると、受信する行動が受信します。</td>
						</tr>
						<tr>
							<td>OpenChannelEvent</td>
							<td>△</td>
							<td>経路開設要求があると、対象となる行動が受信します。</td>
						</tr>
						<tr>
							<td>KillEvent</td>
							<td>×</td>
							<td>エージェントが消滅したときに、そのエージェントが持つ全ての行動が受信します。</td>
						</tr>
					</tbody>
				</table>
				<p>※ターン毎にランダムな順番で受信します。</p>
			</subsubsection>
		</subsection>
		<subsection title="Typeを設計する">
			<p>基礎モデルフレームワークを利用した設計では、エージェント、財、関係の設計にはTypeを利用し、
				情報と行動の設計は継承を利用するのが基本です。</p>
			<p>今回のレモン市場でも、基本に従うことにして、エージェント、財、関係の設計を行います。</p>
			<p>Typeの設計で気をつけることは、ただ一つ、「名前の付け方」です。Typeの命名規則を以下の表に示します。</p>
			<table style="width:100%" title="Typeの命名規則">
				<thead>
					<tr>
						<th>Typeクラス名</th>
						<th>命名規則</th>
						<th>具体例</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td>AgentType</td>
						<td>AGENT_[タイプ名(※)]</td>
						<td>AGENT_Individual</td>
					</tr>
					<tr>
						<td>RelationType</td>
						<td>RELATION_[タイプ名]</td>
						<td>RELATION_Friend</td>
					</tr>
					<tr>
						<td>GoodsType</td>
						<td>GOODS_[タイプ名]</td>
						<td>GOODS_Money</td>
					</tr>
					<tr>
						<td>InformationType</td>
						<td>INFORMATION_[タイプ名]</td>
						<td>INFORMATION_Order</td>
					</tr>
					<tr>
						<td>BehaviorType</td>
						<td>BEHAVIOR_[タイプ名]</td>
						<td>BEHAVIOR_BuyLemon</td>
					</tr>
				</tbody>
			</table>
			<p>※タイプ名の命名規則はJavaのクラス名の命名規則と同様です。</p>
			<p>Typeの設計で難しいことは何もありません。以下の例で示すように、きっちり分析が出来ていればほぼ同様の図になるからです。</p>
			<subsubsection title="エージェントTypeを設計する">
				<p>レモン市場では、エージェントは個人のみでした。ですから、エージェントTypeの設計モデルクラス図は、図9.11のようになります。</p>
				<figure title="エージェントの設計" id="fig:design_agent"
					src="image/design_agent"/>
				<p>Typeはインスタンスで表現するので、UMLクラス図の記法では、継承ではなく、インスタンス化関係で記述します。
					インスタンス化関係は、上図のように、依存関係（点線）とステレオタイプ「instanceOf」で記述します。
					矢印の元がインスタンスで、先がクラスです。</p>
				<p>上図の例で、「AgentTypeのインスタンスとして、AGENT_Individualを生成する」という意味になります。</p>
			</subsubsection>
			<subsubsection title="財Typeを設計する">
				<p>エージェントTypeの場合と同様です。（図9.12）</p>
				<figure title="財の設計" id="fig:design_goods"
					src="image/design_goods" />
			</subsubsection>
			<subsubsection title="関係Typeを設計する">
				<p>エージェントTypeの場合と同様です。（図9.13）</p>
				<figure title="関係の設計" id="fig:design_relation"
					src="image/design_relation" />
			</subsubsection>
		</subsection>
		<subsection title="情報を設計する">
			<p>情報は基本的に、継承を使って設計します。Informationはインターフェイスですので、
				正確にはInformationインターフェイスを実装するということになります。</p>
			<p>命名規則は次のようになっています。</p>
			<table style="width:100%" title="Informationインターフェイスを実装するクラスの命名規則">
				<thead>
					<tr>
						<th>実装するインターフェイス</th>
						<th>命名規則</th>
						<th>具体例</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td>Information</td>
						<td>[情報名(※)]Information</td>
						<td>PriceInformation</td>
					</tr>
				</tbody>
			</table>
			<p>※情報名の命名規則はJavaのクラス名の命名規則と同様です。</p>
			<p>レモン市場での例ですと、図9.14のように設計することができます。</p>
			<figure id="fig:design_information" src="image/design_information"
				title="情報の抜き出し"/>
			<p>Informationインターフェイスは、空インターフェイスですので、データ構造は自由に設計して構いません。</p>
			<p>上記の例ですと、PriceInformation(価格情報)には、価格を数値として持っている必要があるので、
				価格属性を加えています。</p>
			<p>より高度に構造化された情報を設計するには、オブジェクト指向の知識が必要です。
				人工市場やシュガースケープの章で、少し高度な情報の設計例を取り上げます。</p>
		</subsection>
		<subsection title="行動を設計する">
			<p>さて、最後の大仕事が待っています。行動の設計です。
				まず、行動クラスの名前を定義することから始めましょう。行動も基本的に継承を使って設計します。</p>
			<p>命名規則は次のようになっています。</p>
			<table style="width:100%" title="Behaviorクラスを継承するクラスの命名規則">
				<thead>
					<tr>
						<th>継承するするクラス</th>
						<th>命名規則</th>
						<th>具体例</th>
					</tr>
				</thead>
				<tbody>
					<tr>
						<td>Behavior</td>
						<td>[行動名(※)]Behavior</td>
						<td>BuyLemonBehavior</td>
					</tr>
				</tbody>
			</table>
			<p>※行動名の命名規則はJavaのクラス名の命名規則と同様です。</p>
			<p>レモン市場では以下のようになります。（todo:図を作る）</p>
				<figure id="fig:design_behavior" src="image/design_behavior" title="行動の設計"/>
			<subsubsection title="設計シーケンス図を作成する">
				<p>さて、行動クラスの名前が定義された所で、状態遷移図を書きたいところなのですが、
					その前の準備をしておくと状態遷移図がとても書きやすくなります。設計シーケンス図です。</p>
				<p>レモン市場の設計シーケンス図は次のようになります。</p>
				<figure id="fig:design_sequenceView"
					src="image/design_sequenceView" title="設計シーケンス図"/>
				<p>上図を見ると、分析フェーズで書いた取引シーケンス図ととてもよく似ています。（見比べてみてください）</p>
				<p>異なる所は、</p>
				<ul>
					<li>設計モデルの言葉（情報や財の名前）で書かれていること</li>
					<li>シーケンス図の始まり方</li>
				</ul>
				<p>ここで注意することは、2つ目のシーケンスがどこから始まるかという違いです。
					分析段階での取引シーケンス図ではエージェントが自然に行動を開始するように書かれていましたが、
					実際のプログラムで動作させるためには、何らかのきっかけが必要です。基礎モデルフレームワークでは、
					きっかけをEventとして定義しています。</p>
				<p>
					たいていは、TimeEventかChannelEventで取引が開始します。TimeEventはBESPから受け取りますので、
					TimeEventを受け取る場合は上図のようにオブジェクト「BESP」を加えます。</p>
			</subsubsection>
			<subsubsection title="状態遷移図を作成する">
				<p>さて、いよいよ状態遷移図を作成します。状態遷移図の記述には、コンポーネントビルダーを使うと、
					Javaプログラムのスケルトンを自動生成できるので便利です。</p>
				<p>状態遷移図は今まで作ってきた、</p>
				<ul>
					<li>設計モデルクラス図</li>
					<li>設計シーケンス図</li>
					<li>行動アクティビティー図</li>
				</ul>
				<p>を参考に作ります。</p>
				<p>たいていの場合、設計シーケンス図の、メッセージを受け取る個所が「状態」に、
					行動アクティビティ図におけるアクティビティが「アクション」になりますので、目安にするとよいです。</p>
				<p>また、状態遷移図の要素の命名規則は次のようになっています。</p>
				<table style="width:100%" title="状態遷移図要素の命名規則">
					<thead>
						<tr>
							<th>要素</th>
							<th>命名規則</th>
							<th>具体例</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>イベント</td>
							<td>基礎モデルインターフェイスで定義されているもの</td>
							<td>TimeEvent, ChannelEvent</td>
						</tr>
						<tr>
							<td>アクション</td>
							<td>「アクション名(※)」Action</td>
							<td>SendLemonAction</td>
						</tr>
						<tr>
							<td>状態</td>
							<td>任意</td>
							<td>WaitingForLemon</td>
						</tr>
						<tr>
							<td>ガード条件</td>
							<td>任意</td>
							<td>isLemon(送られてきた財がレモンであればの意)</td>
						</tr>
					</tbody>
				</table>
				<p>※タイプ名の命名規則はJavaのクラス名の命名規則と同様です。（大文字からはじめる）</p>
				<p>レモン市場における、買い行動の状態遷移図は以下のようになります。</p>
				<figure id="fig:design_buyLemonBehavior"
					src="image/design_buyLemonBehavior"
					title="BuyLemonBehaviorの状態遷移図"/>
				<p>この例を利用して状態遷移図の要素を簡単に説明すると次のようになります。</p>
				<dl>
					<dt>状態</dt>
					<dd>角の丸い長方形が状態を表します。WaitingForTimeなどが例で、状態は行動内でユニークな名前をもっています。
						行動は常にどれか１つの状態を持ちます。同時に2つの状態を持つことはありませんし、
						状態が無いこともありません。特に、黒丸は初期状態を表し、行動が生成された直後には初期状態になります。</dd>
					<dt>遷移</dt>
					<dd>状態が異なる状態へ変化することを遷移といい、その方向を矢印で示します。
						この例では出てきませんが、ある状態から同じ状態へ遷移することを自己遷移といいます。</dd>
					<dt>イベント</dt>
					<dd>
						遷移を引き起こすきっかけです。例えば、WaitingForTime状態にいて、TimeEventというイベントが起こると、
						WaitingForPriceへの遷移が起こります。基本的にはイベントが起こらないと状態遷移は起こらないのですが、
						遷移にイベントを書かないと「自動遷移」の意味になり、自動的に遷移が起こります。</dd>
					<dt>アクション</dt>
					<dd>
						行動が実行する動作の単位です。例えば、SendPriceRequestActionは、価格要求を送る動作を指します。
						アクションは、たいてい遷移が起こる際に行われます。例えば、WaitingForTime状態でTimeEventを受け取って、
						WaitingForPrice状態に遷移する際に、遷移に記述されたSendPriceRequestActionが実行されます。</dd>
					<dt>ガード条件</dt>
					<dd>UMLでは、遷移するときの条件を記述することが出来ます。その条件のことをガード条件といいます。
						ガード条件が記述されている場合、例えイベントを受け取っても、条件が一致しない場合、遷移は起こりません。
						例えば、WaitingForLemon状態で、ChannelEventを受け取ったとしてもisLemonガード条件が真でなければ、
						遷移が起こらないということになります。</dd>
				</dl>
				<p>次に、売り行動の状態遷移図を以下に示します。</p>
				<figure id="fig:design_sellLemonBehavior"
					src="image/design_sellLemonBehavior"
					title="SellLemonBehaviorの状態遷移図"/>
				<p>ここでは、簡単に状態遷移図の要素を説明しましたが、状態遷移図を書くのが不慣れな人に、
					一つだけ覚えてほしいことがあります。それは、分析フェーズで書いた行動アクティビティ図における「アクティビティ」は、
					絶対に「状態」にならないということです。
					これは、UMLにおいて、アクティビティ図と状態遷移図が似ているために初心者がよく間違えることです。</p>
				<p>アクティビティ図では、角丸四角をアクションの単位とし、その中で状態遷移が行われるというように記述します。
					しかし、状態遷移図では、角丸四角は状態であり、遷移のとき起こるものとして記述します。
					つまり、表記の意味が全く逆になるわけです。ややこしいですね。</p>
			</subsubsection>
		</subsection>
	</body>
</doc>
