<?xml version='1.0' encoding='Shift_JIS' ?>
<doc xml:lang='ja'>
	
	<body>
		
		<subsection title="エージェント・財・関係を設計する">
			<p>分析フェーズで作成した分析モデルクラス図を参照しながら、エージェント・財・関係の設計モデルクラス図を新しく作成します。</p>
			<figure id="fig:design_agent" src="image/design_agent" title="エージェントの設計"/>
			<figure id="fig:design_relation" src="image/design_relation"
				title="関係の設計"/>
			<figure id="fig:design_goods" src="image/design_goods" title="財の設計"/>
		</subsection>
		
		<subsection title="情報を設計する">
			<p>分析フェーズで明らかになった情報に１つずつ注目しながら、情報がもつ内容をどのような型で表わせるのか、設計します。</p>


				<subsubsection title="StartSignalInformation(取引開始合図)の設計">
					<p>取引開始合図には、どのような情報が載っていると考えられるでしょうか？
						実際の世界では午前９時の鐘であったり、銀行のダイレクトメールといったお知らせであり、契約要綱などの色々な情報が載っています。
						ですが、人工市場モデルでは、投資家に「注文を送りなさい」というシグナルであればいいので、とくに情報を載せる必要はありません。</p>
					<p>取引開始合図を他の情報と区別して、「取引開始合図である」と投資家が認識するためには、何らかの識別符が必要なのではないのか？そう考える方もいるかもしれません。
						しかし、（実装フェーズの話になりますが）識別にはクラス名を使用すればいいので、取引開始合図は空で構わないのです。</p>
				</subsubsection>
				<subsubsection title="PriceHistoryInformation(価格履歴)の設計">
					<p>一般的に財の価格の履歴は、例えば『１．ハンバーガー（種類）が』『２．湘南台店（場所）で』『３．8月29日14時23分（時刻）に』『４．65円（価格）だった』といった４次元的な情報が必要です。
						人工市場モデルでは、取引される財、つまり株は１種類だけであり、場所も1つであるため、１．と２．の区別は（つまり情報は）必要ありません。
						また、時刻も、１期、２期、３期、、、というように一定期間を所与の条件として区切るだけなので、３．を連続的ではなく、離散的に扱います。
						４．の価格はどうでしょうか？これはそのままで構いませんが、コンピュータの特性により、小数点以下の加減乗除は端数が丸められてしまうことがありますので、今回は小数点以下を扱わず、整数のみということにします。</p>
					<p>ここまででわかったことは、「整数（価格）が」「時系列で離散的に並んでいる」という情報の構造です。このような情報の構造をJAVAでは”List”と呼びます（詳しくはJAVAの文献を参考にしてください）。
						このListは、（メモリの続く限り）いくらでも情報オブジェクトを追加することでき、追加順に一列に並んでいます。
						価格履歴の設計として、このPriceHistoryInformationというクラスにpriceList : LinkedListをもたせることににします。</p>
					<p>最後に、トレンド追従トレーダーがシミュレーション開始時に既にもっている価格履歴として、
						上昇傾向のbull : PriceHistoryInformation、下降傾向のbear : PriceHistoryInformation、ランダムなrandom : PriceHistoryInformationの３つをもたせます。</p>
					<p>以上、価格履歴の中身として設計した属性は以下の４つです。</p>
						<dl>
							<dt>priceList</dt>
							<dd>過去の価格が順番に入っているLinkedList。</dd>
							<dt>bull</dt>
							<dd>上昇傾向の価格履歴をもつPriceHistoryInformation。
								モデル作成者の必要に応じて、トレンド追従トレーダーにこの価格履歴あらかじめ与えておくことができます。</dd>
							<dt>bear</dt>
							<dd>下降傾向の価格履歴をもつPriceHistoryInformation。
								モデル作成者の必要に応じて、トレンド追従トレーダーにこの価格履歴あらかじめ与えておくことができます。</dd>
							<dt>random</dt>
							<dd>ランダムの価格履歴をもつPriceHistoryInformation。
								モデル作成者の必要に応じて、トレンド追従トレーダーにこの価格履歴あらかじめ与えておくことができます。</dd>
						</dl>
				</subsubsection>
				<subsubsection title="OrderInformation(注文内容･約定結果内容)の設計">
					<p>注文内容と約定結果内容を、なぜ同じ情報として扱おうとするのでしょうか？
						それは、人工市場モデルでは両者に根本的な違いがないからです。
						一般的に注文内容・約定結果内容は、『１．A社の株を（種類）』『２．伊藤一郎が（注文主）』『３．１０００万円ぶん（量と価格）』『４．買う（注文の種類）』の４つから構成されるといってよいでしょう。
						勿論、スワップ取引・先物取引を考慮すると、これだけでは足りませんが、人工市場モデルでは、むしろ多すぎるといえます。
						価格履歴の設計の時に述べたように、１．は無視できます。
						他の３つ（量・価格は分離されるので実際は４つ）はどうでしょうか。誰が注文したのかは無視できないし、量と価格は言うに及ばず、注文の種類も必要です。
						よって、設計される属性は「注文主」「注文の種類」「注文価格」「注文量」の４つとなります。</p>
					<p>注文主はAgentです。注文の種類は「買いか売りか」の識別子なのでintやboolean(真偽値)でもいいのですがわかりやすさを考えてString(文字列)にします。
						そして、注文価格と注文量は先ほど述べたとおり、整数ですのでintとします。</p>
						<dl>
							<dt>agent</dt>
							<dd>注文主を記したAgent</dd>
							<dt>orderAction</dt>
							<dd>注文の種類（買い注文、売り注文）を記したString</dd>
							<dt>price</dt>
							<dd>注文価格を記したint</dd>
							<dt>amount</dt>
							<dd>注文量を記したint</dd>
						</dl>
				</subsubsection>
				<subsubsection title="OrderListInformation(注文リスト・約定結果リスト)の設計">
					<p>注文リスト・約定結果リストは、基本的には価格履歴と同じ設計思想です（Listを使用します）。
						ですが、この情報をもつ証券取引所が板寄せ約定を行うことを考えると、売り注文と買い注文をしまうListを別々にわけ、また約定価格をもたせたほうが便利です。
						従って、設計される属性は「買い注文リスト」「売り注文リスト」「約定価格」の３つとなります。</p>
						<dl>
							<dt>buyOrderList</dt>
							<dd>買い注文をまとめたList</dd>
							<dt>sellOrderList</dt>
							<dd>売り注文をまとめたList</dd>
							<dt>price</dt>
							<dd>約定価格を記したint</dd>
						</dl>
				</subsubsection>
				<subsubsection title="BoardInformation(約定板)の設計">
					<p>約定版とは、板寄せ約定の時に使用される２次元のセルシートです。全ての売買注文が記されています。</p>
				<table style="width:100%" title="約定板">
					<thead>
						<tr>
							<th>買い注文</th>
							<th>価格</th>
							<th>売り注文</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>０株</td>
							<td>１０２円</td>
							<td>１８００株</td>
						</tr>
						<tr>
							<td>５００株</td>
							<td>１０１円</td>
							<td>１３００株</td>
						</tr>
						<tr>
							<td>１０００株</td>
							<td>１００円</td>
							<td>５００株</td>
						</tr>
						<tr>
							<td>１５００株</td>
							<td>９９円</td>
							<td>４００株</td>
						</tr>
						<tr>
							<td>２０００株</td>
							<td>９８円</td>
							<td>０株</td>
						</tr>
					</tbody>
				</table>
					<p>板寄せ約定は、この約定板をみて、「一番販売価格の低い売り注文」と「一番購入価格の高い買い注文」を順に約定していき、約定版から引いていきます。
						実際に上の約定板を約定してみましょう。
						まず、一番高い値段の買い注文は「１０１円５００株」、一番低い値段の売り注文は「９９円４００株」です。
						これを約定すると以下の通りになります。</p>
				<table style="width:100%" title="約定板">
					<thead>
						<tr>
							<th>買い注文</th>
							<th>価格</th>
							<th>売り注文</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>０株</td>
							<td>１０２円</td>
							<td>１８００株</td>
						</tr>
						<tr>
							<td>１００株</td>
							<td>１０１円</td>
							<td>１３００株</td>
						</tr>
						<tr>
							<td>１０００株</td>
							<td>１００円</td>
							<td>５００株</td>
						</tr>
						<tr>
							<td>１５００株</td>
							<td>９９円</td>
							<td>０株</td>
						</tr>
						<tr>
							<td>２０００株</td>
							<td>９８円</td>
							<td>０株</td>
						</tr>
					</tbody>
				</table>
					<p>現在、取引が確定した注文は４００株です。このように順々に約定していくと、結果は以下の通りになります。
						（ちなみに低い価格の買い注文と高い価格の売り注文は成立しません）</p>
				<table style="width:100%" title="約定板">
					<thead>
						<tr>
							<th>買い注文</th>
							<th>価格</th>
							<th>売り注文</th>
						</tr>
					</thead>
					<tbody>
						<tr>
							<td>０株</td>
							<td>１０２円</td>
							<td>１８００株</td>
						</tr>
						<tr>
							<td>０株</td>
							<td>１０１円</td>
							<td>１３００株</td>
						</tr>
						<tr>
							<td>６００株</td>
							<td>１００円</td>
							<td>０株</td>
						</tr>
						<tr>
							<td>１５００株</td>
							<td>９９円</td>
							<td>０株</td>
						</tr>
						<tr>
							<td>２０００株</td>
							<td>９８円</td>
							<td>０株</td>
						</tr>
					</tbody>
				</table>
					<p>この時、取引の確定した注文は９００株です。板に残った残りの注文は全てお流れになります。</p>
					<p>さて、このような約定板をどのように表現したらよいのでしょうか？
						２次元の情報は、縦と横にわけて考えてみるといいでしょう。
						横の構造について。約定版の作成を考えると、注文は値段の横に順々に追加されていきますので、売買注文とも、価格の数だけ横へのListがあると便利です。
						縦の構造について。どんな値段の注文が飛び込んでくるかわからないわけですから、価格をあらかじめ高い順に並べておくことはできません。
						従って、新しい注文が来た時は、既にその価格による横の注文リストが存在する場合は、そこに追加し、
						まだ横の注文リストがない場合は、新しく横の注文リストを作って縦に追加する、という処理になります。
						そう考えると、「価格による検索」がしやすいMapという情報の構造が縦に相応しいと考えられます。
						Mapは、Listのような順番をもたない集合なのですが、情報を入れるときに検索キーを指定することによって、後からキーによる検索が可能な情報の構造です（List同様に、Mapに関してはJAVAの文献を参考にして下さい）。</p>
					<p>まとめると、約定板は「注文のList（横のつながり）を、価格をキーとして保存しているMap（縦のつながり）」となります。</p>
					<p>設計する属性としては、約定板の他に、取引の確定した注文のList、約定板に加えることのできない（売りでも買いでもない）注文のListの２つ、合計で３つです。</p>
						<dl>
							<dt>priceBoardMap</dt>
							<dd>注文のListを、価格をキーとして保持するMap</dd>
							<dt>nonePriceOrders</dt>
							<dd>約定板に追加できない注文のList</dd>
							<dt>contractedPriceBoard</dt>
							<dd>取引の確定した注文を保持するOrderListInformation</dd>
						</dl>
				</subsubsection>
				<p>以上、５つの情報の設計が終わりました。設計結果をクラス図として書くと以下の通りになります。</p>
			<figure id="fig:design_information" src="image/design_information"
				title="情報の設計"/>
		</subsection>
		
		<subsection title="行動を設計する">
			<p>本章のはじめで述べた通り、人工市場モデルにおける投資家エージェントの意思決定アルゴリズムには多くの種類があります。
				今回はノイズ・トレーダーとトレンド追従型トレーダーの２種類の意思決定をモデリングするのですが、
				今後、同じ人工市場モデルの、投資家のアルゴリズムだけ入れ替えて、様々な理論を検証したいと思いませんか？
				そのような拡張性をモデルに組み込むため、本節では「継承」を用いることにします。</p>
			<subsubsection title="「継承」とは？">
			<p>継承とは、似たような構造をもつオブジェクトを複数設計する際に、共通化できる部分を探して、構造の共有を図るために用いられます。
				行動の設計において「継承」を用いるとき、以下のような作業を行います。（継承の詳細についてはオブジェクト指向の文献を参照して下さい）</p>
		<ul>
			<li>設計対象群を、『共通化できる部分』と『共通化できない部分』に区別する</li>
			<li>『共通化できない部分』が『共通化できる部分』のどこに依存しているのかを考える</li>
		</ul>
			</subsubsection>
			<subsubsection title="「継承」を用いた行動の設計フロー">
			<p>ノイズ・トレーダーであれトレンド追従型トレーダーであれ、
				投資家の行動には、「証券取引所に注文を伝える」「約定結果を受け取る」など、共通化できる部分があります。
				意思決定の部分も「ランダムに注文を決める」「過去の価格変動にもとづいて注文を決める」を「アルゴリズムは色々とあるがとにかく注文を決める」といった共通化を図ることができます。</p>
			<p>このように投資家の行動で共通化できる部分と共通化できない部分を区別していき、
				共通化できない部分（意思決定アルゴリズム）が、共通化できる部分のどこに依存しているのか（この場合は「注文を決定する」）を
				考えていきます。
				</p>
			<p>その後、共通化できる部分を「TraderBehavior」とし、
				共通化できない部分を、ノイズ・トレーダーの場合は「TraderByRandomBehavior」、トレンド追従型トレーダーは「TraderByTrendBehavior」とします。
				この時、「TraderByRandomBehavior」と「TraderByTrendBehavior」は、
				「TraderBehavior」の構造を全て利用しながら、「TraderBehavior」内では曖昧に扱われている「注文を決定する」という部分を、ランダムやトレンド追従という形で実現する、ということになります。
				</p>
			<p>このような関係を「TraderByRandomBehaviorとTraderByTrendBehaviorが、TraderBehaviorを継承している」と呼びます。
				</p>
			</subsubsection>
			<subsubsection title="設計シーケンス図を作成する">
				<p>分析フェーズのシーケンス図を設計用に書き換えます。</p>
				<figure id="fig:design_sequenceView"
					src="image/design_sequenceView" title="設計シーケンス図"/>
			</subsubsection>
			
			<subsubsection title="エージェントの優先順位">
		
				<p>前項の設計シーケンス図をご覧下さい。レモン市場の場合と異なり、証券取引所だけが特別に時計信号を受け取って
					投資家エージェントに問いかけを行っています。
				</p>
				<p>このようなモデル化を行う場合、エージェントの実行順序が問題になる場合があります。
					今回の場合ですと、優先順位をつけなくても何とか動きそうですが、投資家が時計信号を受け取って何か行動を起こすように
					することを考えると、証券取引所が一番早く時計信号を受け取ることを保証したい時があります。
				</p>
				<p>
					BESPでは、この優先順位をエージェントの種類ごと（つまりAgentTypeごと）に制御することができます。
					実装フェーズで設定の方法を説明します。
				</p>
			</subsubsection>			
			
			<subsubsection title="状態遷移図を作成する">
				<p>
					設計シーケンス図をもとに、状態遷移図を作成すると次のようになります。
				</p>
				<figure id="fig:design_StockExchangeBehavior"
					src="image/design_StockExchangeBehavior" title="StockExchangeBehavior"/>
				<figure id="fig:design_TraderBehavior"
					src="image/design_TraderBehavior" title="TraderBehavior"/>
			</subsubsection>
			
		</subsection>
		
		<!--
		<section title="シーケンス設計">
			<subsection title="シーケンス設計にあたって: 前提知識">
Priority, TimeEvent
			</subsection>
			<subsubsection title="取引仕様シーケンスの作成">
取引仕様の作成
（前提知識としてキュー、時間信号の配信の仕方、を説明する）
・相互作用クラス図とアクティビティ図を参照しながら、どの行動が一番初めにどの行動に対して何を渡して、それによって次の行動がどのように動作していくのか、、、という時間経過をモロに意識したインタラクションのある「流れ」を書いてください。この時、「時間になる」で行動が一番初めに動くことになります。
！！「全ての主体に何かを送って、次にその返事をまとめて受け取る」を理解させるためにキューの説明が必要！！
！！「時間を管理する主体（例えば、神様）」の有無を判断させるために、時間信号の配信の仕方の説明が必要！！具体的には、時間信号によって発火したアクションが発火したアクションが、、、、というのが終わるまで、同じ時間信号が他のエージェントに送られることはない。
！！この時点で、前に戻って仕切り直し、が発生する（case: 山田）！！
　　＞＞取引仕様シーケンスが完成
			</subsubsection>
		</subsection>
		<subsection title="データモデル設計">
			<subsubsection title="データモデル設計にあたって: 前提知識">
			</subsubsection>
			<subsubsection title="データモデル仕様の作成">
・全体像クラス図と相互作用クラス図とアクティビティ図と取引仕様シーケンスを参照しながら、Informationの型を決めてください。この時、そのInformationに「どんな情報を入れたいのか？」「どんな風に取り出したいのか？」という処理の要求に基づいて型を決定してください。
　　＞＞取引仕様データモデルが完成
			</subsubsection>
		</subsection>
		<subsection title="ステートチャート設計">
・アクティビティ図と取引仕様シーケンスを参照しながら、アクティビティを適当な単位（アクション）に分割して下さい。ここで、適当な単位とは、「名前が付けられる」小ささの単位にしてください。
　　＞＞アクション仕様が完成

（前提知識として状態遷移図とガード条件の説明）
・アクティビティ図とアクション仕様と取引仕様シーケンスを参照しながら、

この時、各状態は「?待ち状態」と名づけ、TimeEventあるいはChannelEventをまつ状態として統一して下さい。
AUTOを使うのは、最小限にとどめましょう。
		</subsection>
-->
	</body>
</doc>
