asatoの技術的な日常日記

「成長に最大の責任をもつ者は、本人であって組織ではない。自らと組織を成長させるためには何に集中すべきかを、自らに問わなければならない」  非営利組織の経営 - ピーター・ドラッカー

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

要求構造 Part2: 横断的要求構造

要求構造を考えるトピック、パート2。

前回と同じく、例としてゲーム(「不思議のダンジョン」風ゲーム)を取りあげる。例だけど、実際に作り中のゲームなのでそれなりに本格的。クラス数は、250~300ぐらい。


今回は、「クリティカル攻撃仕様」を基に考えていきたいと思う。この仕様は、図でしめしているようなサブ仕様で構成される。
req_structure_critical.png


クリティカル攻撃仕様:キャラクタの持つクリティカル率に従い繰り出される強力な攻撃
・キャラクタは、クリティカル率をステータスとして持つ
・通常攻撃より大きなダメージを与える
・通常攻撃と異なる効果音を出す
・攻撃ヒット時に「Critical」文字列を表示する
・ステータス画面で、クリティカル率を表示する


次に、いつものように DSM (Design Structure Matrix) を使って要素間の依存を分析してみる。DSM は、要素間の依存関係を表現するための方法。
req_structure_critical_dsm.png


ここでの難しい点は、「(サブ)仕様間の依存関係をどうやって導き出すのか」という点。

少なくとも二つのアプローチが考えられる。
(1)具体的な実装を考慮(想像)して依存関係を導き出す
(2)具体的な実装を考慮(想像)しないで依存関係を導き出す

上の DSM は、(1)のアプローチを採用して、なるべく実装を考慮しないで依存関係を考えてみた。

依存関係を導き出すための基本的な戦略は、「もしこのサブ仕様が変更になったら、他の仕様の変更を考える必要があるのか」という方法。


ここで注目すべき点は、ソフトウェアの構造的なデザインは、まだ 扱っていないけど、ゲームのデザインは扱っている という点。

5つのサブ仕様からなる「クリティカル攻撃仕様」は、ゲームのある設計空間において決定されたデシジョンでもある。

そもそも、「クリティカル攻撃」をゲームの機能として導入すると決めたこと自体が、ゲームのデザインについての決定。

Cai の Constraint Network を用いて表現するならこうなる:
before:

subspace normal_attack: (yes, no);

after:

subspace normal_attack: (yes, no);
subspace critical_attack: (yes, no);

critical_attack_yes [ // クリティカル攻撃が必要な場合の設計空間
scalar critical_rate: (orig, other)
scalar critical_attack_damage: (orig, other)
scalar critical_effect_sound: (orig, other)
scalar critical_effect_image: (orig, other)
scalar critical_rate_draw: (orig, other)
]


次に、他の仕様との関係を考えてみようと思う。

まずは「クリティカル攻撃仕様」が 追加される前 の「ステータス仕様」。
req_structure_status.png


次に、「クリティカル攻撃仕様」が 追加された後 の「ステータス仕様」。
req_structure_status2.png


「クリティカル攻撃仕様」と「ステータス仕様」を組み合わせて図で表すとこんな感じ。
req_structure_status_critical.png


アスペクト指向プログラミングに慣れてる人向けに言うなら、AspectJ でいうところの「イントロダクション(or inter-type 宣言)」の機能に相当する(ただし、次のようにしてプログラミングするのが良いとはいえない):

public class Status {
private int hp;
private int maxhp;

// その他のフィールドとアクセッサメソッド
}

public aspect CriticalAttackFeature {
privtae int Status.criticalRate; // Status クラスへの criticalRate フィールドの導入。
}


次に、DSM を用いて依存関係を分析してみる。「クリティカル攻撃仕様」が追加される前と後のの「ステータス仕様」のDSM:
before:
req_structure_status_dsm.png


after:
req_structure_status_critical_dsm.png


この場合は簡単なので、「クリティカル攻撃仕様」は、単に「ステータス仕様」から見た ビュー を変更するだけで、何か依存関係を導入するわけではない。

仕様レベルでの DSM はこうなる。
req_structure_status_critical_dsm2.png

「ステータス仕様」が「クリティカル攻撃仕様」に依存しているのは、「クリティカル攻撃仕様」がなくなれば、「ステータス仕様」が変わるため。つまり、『キャラクタのステータスには何がありますか?』と聞かれたときに『クリティカル率があるかないか』。


次に、「クリティカル攻撃仕様」の追加が「ステータス画面表示仕様」にどう影響するのかを同じようにして分析したいと思う。

「ステータス画面表示仕様」は次のような感じ:「あるキーが押されたら、プレイヤーのステータスを表示する」
req_structure_status_view.png


「クリティカル攻撃仕様」と「ステータス画面表示仕様」を組み合わせてみるとこうなる。
req_structure_status_view_critical.png



「クリティカル攻撃仕様」が追加される前と後での「ステータス画面表示仕様」の DSM の変化はこうなる。
before:
req_structure_status_view_dsm.png


「描画レイアウト」は、プレイヤーのどのステータスを表示するかに依存して変わる必要がある。たとえば、命中率や回避率は、ゲームのユーザに直接表示せずに、内部的なパラメータとして持っておくほうがゲームとして面白いかもしれない。そのようなゲームデザイン上の変化があったときには、「描画レイアウト」は影響を受ける。
after:
req_structure_status_view_dsm2.png

「ステータス仕様」の DSM の場合と違って、「クリティカル攻撃仕様」は、仕様内部での依存関係を導入する。「描画レイアウト」は「ステータス画面で、クリティカル率を表示する」に依存する。もし、「クリティカル攻撃仕様」で「ステータス画面で、クリティカル率を表示 しない」に変更されたら、「描画レイアウト」は影響を受ける。


仕様レベルでの依存関係はこう。
req_structure_status_view_critical_dsm2.png



まとめ:
ゲームを例として取り上げて、機能仕様追加が、既存の仕様に与える影響について、DSM を用いて分析した。ある機能の追加(「クリティカル攻撃仕様」)は、他の仕様(「ステータス仕様」「ステータス表示仕様」)に横断的に影響を与えることが分かった。


まとめとしての考察は以下の点:
(1)設計空間は、変化する:要求変化により、設計空間は変化する。新たな設計次元が追加/削除され、ある設計次元におけるドメインも変化する。

(2)ある仕様の追加は、他の仕様に横断的に影響する:「クリティカル攻撃仕様」の追加は、他の機能仕様「ステータス仕様」「ステータス表示仕様」への追加であった。つまり、ある仕様の追加は、他の仕様に横断的に影響する。

(3)「ビュー依存」と「要素間依存」:依存関係には、「ビュー依存」と「要素間依存」がある。ある仕様の導入は、他の仕様のビューに影響するが、要素の依存関係は導入しない場合がある。一方で、ある仕様の導入は、他の仕様の要素との依存関係は導入する。
スポンサーサイト

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://asatohan.blog77.fc2.com/tb.php/49-41a68096
この記事にトラックバックする(FC2ブログユーザー)

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。