<?xml version='1.0' encoding='Shift_JIS' ?>
<doc xml:lang='ja'>
	<body>
		<p>分析フェーズの目的は、これから作るシミュレーションはどういうシミュレーションなのかを明らかにすることです。
			シミュレーションに登場するエージェント・財・情報、エージェントが行う行動、およびそれらの関係すべてを洗い出し、定義します。
			また、エージェントがシミュレーション中にどのように振舞うかを明らかにし、記述します。</p>
		<p>このフェーズで作成するのは以下の図です。</p>
		<ul>
			<li>概念モデルクラス図</li>
			<li>行動アクティビティ図</li>
			<li>取引シーケンス図</li>
		</ul>
		<p>これからUMLにもとづいた各種の図を記述します。
			本チュートリアルでは、分かりやすさを重視して、そのため、分析モデルを日本語で表記しています。
			また、必要に応じてメモなども追加します。
			</p>
		<subsection title="シミュレーションのタイトルを考える">
			<p>これが一番初めの、一番重要な作業です。
				どのようなシミュレーションか、または何を解決するシミュレーションなのかを考慮して、
				適切で分かりやすく、かつ愛着がもてるようなタイトルを決めます。</p>
			<p>
				これから説明していく具体例のタイトルは、「レモン市場」というタイトルです。
				これは経済学で有名な中古車市場のモデルで、「情報の非対称性」
				を分析するモデルです。
				「レモン」というのは、中古車市場において欠陥のある車を指す俗語であり、
				「レモン市場」とは、売り手に対して買い手はレモンに対する十分な情報を得にくいために、欠陥のある商品をつかまされてしまうことがある市場をさします。
				Boxed Economyは、そういった「情報の非対称性」を分析するシミュレーション
				が作りやすいように設計されているので、最初の相手としては十分です。
				ただし、このチュートリアルでは、「情報の非対称性」までシミュレーション
				するのは難しいので、最初は買い手1人、売り手1人、とにかく欠陥のあるかどうかわからないレモンを買い続けるというモデルです。</p>
		</subsection>
		<subsection title="シミュレーションに登場する事物の洗い出しと定義">
			<p>
				タイトルが決まったら、次は登場人物（キャスト）の洗い出しです。
				エージェントベースシミュレーションの主役はもちろんエージェントなのですが、
				情報など脇役たちの活躍も同じぐらい重要です。
				では、どういうふうに洗い出せばよいのでしょうか？
				しかし、心配は無用です。Boxed Economyでは、登場する事物を洗い出すために基礎モデルという枠組み
				が提供されています。特に、ここでは、基礎モデルで定義されている言葉（概念）のうち、次の5つに注目します。</p>
			<ul>
				<li>エージェント - Agent</li>
				<li>情報 - Information</li>
				<li>財 - Goods</li>
				<li>行動 - Behavior</li>
				<li>関係 - Relation</li>
			</ul>
			<p>これら5つのキーワードにもとづいて、あなたが作るシミュレーションの登場事物を抜き出していきましょう。</p>
			<p>抜き出した登場事物は、UML（クラス図）で記述します。</p>
			<subsubsection title="エージェントと行動">
				<p>
					まず、エージェントと行動から考えてみましょう。
					「レモン市場」の例で行くと、「売り手」と「買い手」というエージェントがまず考えられます。</p>
				<p>
					ですが、ちょっと考えてみてください。現実の世界で、一生売り手な人や、一生買い手な人っていません。
					例えば、パン屋の主人は、
					普段はパンを売る「売り手」だけれども、休みの日には、外食する「買い手」になる可能性もあるわけです。
					あと、基礎モデルにおけるエージェントは、
					「一生種類が変わらない」というルールがあることに注意しましょう。
					そのようなルールの下では、売り手が急に買い手になったり、その逆になったり、
					さらには、売り手であり、かつ買い手であるエージェントが存在できなくなってしまうのです。
					それでは、現実世界をモデルとして作成してシミュレーションする際に困る場合があります。</p>
				<p>
					そのような場合を考えて、基礎モデルでは、「行動」という概念が定義されています。
					エージェントは、行動を入れ替えたり、複数同時並行で
					実行したりすることができる仕組みになっています。
					この仕組みを使えば、買い手であり売り手であるパン屋の主人をつくることもできるし、高校生から大学生へと「進化するエージェント」を作ること
					ができます。</p>
				<p>
					さて、レモン市場では、どのようにエージェントを洗い出しましょうか。
					最初の難関です。発展性を考えると
					「売り手」「買い手」は「売り行動」「買い行動」を持つエージェントの方がよさそうです。
					基本的にエージェントの振る舞いに関する
					種類は、行動としてモデル化することをお勧めします。
					行動としてモデル化すると、エージェントに様々な機能を動的に追加したり、入れ替えたり
					することができるからです。
					ただし、エージェントの種類を変えなければならない場合もあります（プライオリティが関連する場合）。</p>
				<figure title="登場するエージェント" id="fig:analysis_agent"
					src="image/analysis_agent" style="scale:1.0"/>
				<p>
					できたクラス図は、エージェントとしての「個人」（名前はなんでもよいのですが、このモデルでは、個人売買ということにしました。）と、行動が
					2つになりました。</p>
			</subsubsection>
			<subsubsection title="エージェントの関係">
				<p>次に、「関係」というキーワードから、エージェント同士がどう関連するかを考えていきます。</p>
				<p>レモン市場の例では、売り買いしか行われないので、関係は一つです。「売り手と買い手の関係」です。
					クラス図で示すと、以下のようになります。</p>
				<figure title="エージェントの関係" id="fig:analysis_relationView"
					src="image/analysis_relationView"/>
				<p>
					この図、エージェントとエージェントの関係になっていて、ちょっと難しいのですが、クラスではなく、インスタンスを想像してみてください。
					エージェントクラスのインスタンスが2つあって、その一方が売り手行動をもち、もう片方が買い手行動を持っていることを想定します。
					売り手と買い手の関係になっているでしょう？</p>
				<p>
					ここで注意して欲しいのは、関係は双方向ではなく、単方向であることです。もちろん、双方向にすることも出来ますが、基礎モデルでは、
					一本の線で単方向の関連を表します。双方向にするには、2本の線を引きます。単方向である場合、その方向が重要になります。
					では、この場合は、どちらからどちらからの関係になるのでしょうか？</p>
				<p>
					どちらでもよいのですが、ここでは、買い手から売り手への関係ということにします。つまり、買い手が売り手のことを知っていて、買い手が
					売り手に対して「売ってください」と持ちかけることにします。セールスはお断りです。</p>
				<p>方向が決まると、関係の名前が決まるはずです。「レモン市場」では、関係は一つだけなので、クラス図は以下のように簡単です。</p>
				<figure title="登場する関係" id="fig:analysis_relation"
					src="image/analysis_relation" style="scale:1.0"/>
			</subsubsection>
			<subsubsection title="財と情報">
				<p>
					最後に、財と情報の洗い出しが残っているわけですが、
					実は、この作業は次のセクションで分析する、エージェントの振る舞いを考えていくと
					見つけやすいです。（レモン市場でいえば、直感的に分かるのは、
					「レモン」財ぐらいです。）</p>
				<p>
					そのようなわけで、財と情報の定義は振る舞いの後に考えることにして、次のセクションへ進みましょう。</p>
			</subsubsection>
		</subsection>
		<subsection title="エージェントの振る舞いの分析">
			<p>ここまでで、シミュレーションのキャストが洗い出されました。
				キャストが集まれば、次はキャストがどう行動するのかという台本の手配です。
				分析の第2段階として、エージェントの振る舞いを分析していくことにしましょう。</p>
			<p>エージェントの振る舞いは、次の２つの方法で分析します。</p>
			<ul>
				<li>行動アクティビティ分析</li>
				<li>取引シーケンス分析</li>
			</ul>
			<p>行動アクティビティ分析では、各行動がどのような手順（アルゴリズム）で動作するかを記述します。</p>
			<p>取引シーケンス分析では、複数のエージェント同士がどのような順序（シーケンス）で取引をするかを記述します。</p>
			<subsubsection title="行動のアクティビティ">
				<p>まず、エージェントがどのように振舞うかを、アクティビティという概念を使って、行動単位で記述します。</p>
				<p>「アクティビティ」というのは、聞きなれない言葉ですが、エージェントの行為の単位だと思ってください。
					このため、アクティビティはたいてい、「・・・する」という形になります。</p>
				<p>例えば、レモン市場で登場する買い行動はどんな振る舞いを見せるか考えてみましょう。まず、レモンを買うには、
					価格を質問して、価格を知る必要があります。その後、代金を支払って、商品を受け取ると、取引完了ですね。
					これをまとめると、「レモンを買う」とは、</p>
				<ol>
					<li>価格を質問し、</li>
					<li>価格を知り、</li>
					<li>代金を支払い、</li>
					<li>商品を受け取る。</li>
				</ol>
				<p>というような手順で行われるということになります。列挙された一つ一つを「アクティビティ」と呼びます。
					この「レモンを買う行動」をアクティビティ図で書くと次のようになります。</p>
				<figure title="「レモンを買う」アクティビティ図"
					id="fig:analysis_buyLemonActivity"
					src="image/analysis_buyLemonActivity" />
				<p>簡単でしょう角の丸い長方形で示された一つ一つがアクティビティです。この場合では、上から順番に、
					一つ一つアクティビティをしていくという図になります。アクティビティ図では、条件分岐を記述することも
					できますが、ここでは省略します。</p>
				<p>「レモンを売る」のアクティビティ図も同様に作ると、図のようになります。</p>
				<figure title="「レモンを売る」アクティビティ図"
					id="fig:analysis_sellLemonActivity"
					src="image/analysis_sellLemonActivity" />
			</subsubsection>
			<subsubsection title="取引のシーケンス">
				<p>さて、次は取引の流れを分析してみましょう。
					アクティビティ分析では、各行動がどのように動くかを記述しましたが、行動はたいてい、一つだけでは動作せず、他の行動と連携しながら動いていきます。
					レモン市場の例では、買い行動は売り行動がないと動作しないのは当然で、逆の場合も同じです。
					そこで、行動と行動がどのように連携するかを分析します。</p>
				<p>基礎モデルで、行動と行動の連携の方法は1つしかありません。
					それは、財を送る/受け取るという方法です。
					つまり、経済シミュレーションにおいて、行動と行動の連携は全て「取引」であり、経済活動であるということなのです。
					ここでは基礎モデルの方針に従い、シーケンス図を使って取引がどのような順番で行われるかを記述します。</p>
				<p>一般的なシーケンス図では、オブジェクト同士のやり取りがメッセージとして記述されますが、ここでは、シーケンス図の書き方に少し制約が加わります。
					オブジェクトは必ず行動になり、メッセージは必ず財になります。</p>
				<p>しかし、この制約は、厄介な場合があります。分析段階でまだ行動の単位があいまいな場合や、
					財のやりとりではなく、情報のやりとりを明示したい場合です。そのため、オブジェクトはエージェント単位でもよく、
					メッセージは情報でもよいことにしています。</p>
				<p>基礎モデルを使ったシーケンス図の記法をまとめると次のようになります。</p>
				<table style="width:100%" title="基礎モデルを使ったシーケンス図の記法">
					<thead>
						<tr>
							<th>UMLでの概念</th>
							<th>基礎モデル</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>オブジェクト</td>
							<td>行動 （またはエージェント）</td>
						</tr>
						<tr>
							<td>メッセージ</td>
							<td>財 （または情報）</td>
						</tr>
					</tbody>
				</table>
				<p>レモン市場の例では、以下のようになります。</p>
				<figure title="レモン取引のシーケンス" id="fig:analysis_sequenceView"
					src="image/analysis_sequenceView"/>
				<p>この例では、オブジェクトは売り手の行動と買い手の行動です。
					また、メッセージのうち、価格質問と価格情報は情報で、お金とレモンは財ということになります。</p>
				<p>今回は、買う/売るの2行動の取引になりますが、3行動以上の取引が分析されることもあるでしょう。</p>
			</subsubsection>
		</subsection>
		<subsection title="イテレーション">
			<p>ここまでで、一通りの分析作業が完了しましたが、やり残していた仕事がありますね。それは、財と情報の定義です。
				取引シーケンス図を書いたことで、どのような財や情報が登場するかが明らかになりました。
				取引シーケンス図に書かれたメッセージが財や情報です。</p>
			<p>登場する財と情報をまとめると、以下のようになります。</p>
			<figure title="登場する財" id="fig:analysis_goods"
				src="image/analysis_goods" />
			<figure title="登場する情報" id="fig:analysis_information"
				src="image/analysis_information"/>
			<p>さらに、財がどの行動同士で取引されるかを明らかにするために、次のような図を書くと分かりやすいです。</p>
			<figure title="行動と取引される財の関係" id="fig:analysis_interactionView"
				src="image/analysis_interactionView" />
			<p>今回の例で、登場事物の分析と振る舞いの分析は、どちらかを完成させてからもう片方にとりかかる
				という方法で進めるのは難しいことが分かるでしょう。登場事物の分析と振る舞いの分析を
				交互に繰り返し（イテレーション）することが大切です。次の設計フェーズに進んだときに、
				分析の足りないものがあれば、また分析フェーズに戻って足りないものを追加することもあります。</p>
		</subsection>
	</body>
</doc>
