asatoの技術的な日常日記

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

スポンサーサイト

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

要求構造 Part4: 局所的変更

「要求構造の変化」を考えるテーマのパート4。

今回は、さらに実例を基に、要求構造の変化を考えたい。

今回は「ダメージの計算方法」を例にしたい。仕様の変更として、計算方法を対象とする。

まず、通常攻撃仕様を考えてみる。基本的にはこんな感じ。
req_structure_attack.png


前回書いたように、仕様は、ある設計空間のおける状態の一つであると考えられる。
現在の「通常攻撃仕様」の設計空間は次の通り。
design_space_attack.png


仕様変化による依存関係はないと考えられる。たとえば、計算式が他のものに変わっても、効果音やダメージを表示することに影響しない。

req_structure_attack_dsm.png


ここで、「通常攻撃仕様の設計空間」におけるサブ仕様での依存関係がないので、「ダメージ値計算」の仕様(設計次元)だけを取り上げて、他の仕様との関係をさらに分析してみようと思う。
req_structure_attack_damage.png


現在の計算式は攻撃力から防御力を引いた値をダメージとしている。これは、「ステータス仕様」に依存していることを意味する。
req_structure_attack_damage_status.png


「ステータス仕様」の設計空間は次の通り。
design_space_status.png


もし、現実的にはありえないとはいえ、「攻撃力」と「防御力」がステータスからなくなってしまったら、現在のダメージ計算式は変更されなければならない。

Cai の Constraint Network を使って表現するならこうなる:

scalar damage: (orig, other) // orig は「攻撃力 - 防御力」
scalar attack_point: (yes, no) // 攻撃力
scalar guard_point: (yes, no) // 防御力

damage = orig => attack_point = yes && guard_point = yes; //「攻撃力 - 防御力」の計算式が有効なのは、「攻撃力」と「防御力」のステータス項目が存在するときのみ



ここまでがまえおき。

さて、ここでダメージの計算式が「攻撃力 - 防御力」から他の計算式に変化したらどうなるのか。

たとえば、ダメージ値を変動させるために、ランダム要素を加えようとしてみる。

ダメージ = 攻撃力 - 防御力 - 1~3の乱数値


req_structure_attack_damage_status2.png


この仕様(要求)の変化の特徴を考察すると以下の通り。
(1)仕様の変化は、他の仕様の変更を要求しない。つまり、仕様間で横断的でない。
(2)仕様の変化は、上位の仕様(例で言えば、「通常攻撃仕様」)の変更を要求しない。
(3)仕様の変化は、他の仕様との依存関係を変更していない。
(4)仕様の変化は、上位の仕様との依存関係を変更していない。


このような特徴を持つ要求(仕様)変化を 局所的な要求(仕様)変化 と呼ぶことにしよう。

まとめ


例を用いて、要求構造の変化の特徴を分析した。

要求の構造を、設計空間の観点から考えた。

局所的な要求(仕様)変化とは、以下を満たすような変化である:
(1)仕様の変化は、他の仕様の変更を要求しない。つまり、仕様間で横断的でない。
(2)仕様の変化は、上位の仕様(例で言えば、「通常攻撃仕様」)の変更を要求しない。
(3)仕様の変化は、他の仕様との依存関係を変更していない。
(4)仕様の変化は、上位の仕様との依存関係を変更していない。


今後の課題



-要求構造変化のパターン化。
-「プロブレムフレーム」との関係性。
-「Design Rules」本における、デザイン階層図との関係性の調査。
スポンサーサイト

コメント

コメントの投稿


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

トラックバック

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

FC2Ad

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