Fillomino Player Architecture / Domain Analysis

目的

アクター・ゴールリストと用語辞書の作成

コンテキスト構成

要求事項をもとに、Hashikakeのアーキテクチャをベースに、 Playerのコンテキストを考えてみました(図:コンテキスト概観)。

Context Diagram
図:コンテキスト概観

この図は、メインアクター(ユーザー)と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ユーザーが選択した問題
問題情報問題の初期配置

up : [目次] next : [要求分析]


© 2003, Kazuhiko TAMURA All rights reserved.

[W3C validator]