アクター・ゴールリストと用語辞書の作成
要求事項をもとに、Hashikakeのアーキテクチャをベースに、 Playerのコンテキストを考えてみました(図:コンテキスト概観)。
この図は、メインアクター(ユーザー)とPlayerとの関わりを示しています。Playerはアクターとの接点となるBoundary、 盤面の情報を管理するEntity、BoundaryとEntityをつなぐContorolの3種類に分割しています。 この図を元に、アクターゴールリストを作成し、各目的について優先順位をつけた。
アクタ | ゴール | 優先度 |
---|---|---|
ユーザー | マウスの挙動 | 1 |
問題の読みこみ | 1 | |
解答のチェック | 2 | |
盤面のリセット | 3 |
解答のチェックは、とりあえずなくても遊ぶことが可能であるため、 盤面のリセットは、問題のロードでとりあえず可能なためそれぞれ優先度を低くした。 これらのゴールのドメイン分析は次回以降のIterationで行う。
このコンテキスト図より、以下の用語が抽出されました。
用語 | 種類 | 説明 |
---|---|---|
ユーザー | actor | 遊ぶ人 |
マウスの挙動 | boundary | 盤面の操作/変更を行う |
メニュー項目/ツールバー | boundary | 問題のロードやリセット、チェックなどの操作の入り口 |
問題の読みこみ | control | ユーザーが指定した問題を読みこみ、盤面に反映させる。 |
盤面のリセット | control | 現在までの操作をリセットし、初期状態に戻す。 |
解答のチェック | control | 正解かどうかをチェックする |
画面の表示 | control | 盤面の操作による変更を画面に反映させる |
盤面情報の管理 | entity | 現在の盤面の状態を管理するもの |
この時点で、boundary/entity/contorolの情報は関係ないです。 将来これらの分析オブジェクトの候補なるかも知れないという程度のものです。
要求事項より得られた現実世界をオブジェクトの世界に写しとるために、システムの静的側面をクラス図としてモデル化する。 まず盤面の管理についての静的側面を観察する(図:盤面の管理、静的構造)。
ユーザーが行った変更を管理するための情報が必要であり、 この情報として、1つ以上の各セルの情報を持つ必要があると思われる。 また、各セルについては、そのセルの状態と位置があればとりあえずは十分であると思われる。
この分析で更に以下の用語が抽出されました。
用語 | 種類 | 説明 |
---|---|---|
セル | 盤面の一区画 | |
各セルの情報 | value | セルの内部情報を管理 |
セルの状態 | value | セルの現在の状態 |
位置情報 | value | 盤面上の位置 |
次にマウスの挙動についての静的側面(図:マウスの挙動、静的構造)。
マウスの挙動に関して詳しく見ていくと、マウスクリックなのかドラッグなのかマウスリリースなのかを判断する アクションのタイプと、選択された位置やその他の入力情報を管理する選択位置が発見されました。
この分析で更に以下の用語が抽出されました。
用語 | 種類 | 説明 |
---|---|---|
アクションのタイプ | value | マウスクリックなどのアクションのタイプを保持 |
選択された位置 | value | 選択された位置やその他の入力情報を管理 |
問題のロードの静的構造は以下のように分析された(図:問題のロード、静的構造)
問題のロードも詳しく見ていくと、ユーザーが選択した問題に対する情報が必要である事がわかる。 この分析より、以下の用語が抽出された。
用語 | 種類 | 説明 |
---|---|---|
選択された問題の情報 | value | ユーザーが選択した問題 |
問題情報 | 問題の初期配置 |