asatoの技術的な日常日記

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

スポンサーサイト

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

要求構造 Part3:仕様依存とタスク依存

前回 は、要求構造の分析ということで、ある仕様の追加が、既存の仕様に構造的にどう影響をするのかを分析した。

今回は、同じ仕様の例をつかって、さらに分析を続けたい。


まずは、前回に例として取り上げた、「クリティカル攻撃仕様」の概要と、その構造。
req_structure_critical.png


この仕様は、以下のサブ仕様から成る。
-キャラクタは、クリティカル率をステータスとして持つ
-クリティカル率を基に,通常攻撃より大きなダメージを与える攻撃を行う
-通常攻撃と異なる効果音を出す
-攻撃ヒット時に「Critical」文字列を表示する
-ステータス画面で、クリティカル率を表示する

サブ仕様間の依存関係を DSM で表すをこんな感じ。
req_structure_critical_dsm.png


DSM からは、少なくとも、次の直接的な依存関係があることが分かる。
req_dep_critical.png


この関係からは、「キャラクタは、クリティカル率をステータスとして持つ 」に依存している二つの仕様を実現するためには、まず、「キャラクタは、クリティカル率をステータスとして持つ 」を実現しなければいけないことが分かる。

「クリティカル率」がなければ、「クリティカル率」を表示するこはできないし、クリティカルかどうかを判断するための計算を行うこともできない。


しかし、残りの二つの仕様はどうか。判断は容易ではない気がする。あえて依存関係を示すなら「クリティカル率を基に,通常攻撃より大きなダメージを与える攻撃を行う」に依存する気がする。
req_dep_critical2.png


DSM を書き直すとこうなる。
req_structure_critical_dsm_revised.png


しかし、これは何の依存か。「クリティカル率を基に,通常攻撃より大きなダメージを与える攻撃を行う」の仕様がどう変化したら、依存している二つの仕様が変化される可能性があるのか。

恐らく、ここで判断が困難になっている理由がいくつかあると思う。
-(1)デザイン次元依存とデザインデシジョン依存の混合

-(2)仕様の依存構造と仕様実現(タスク)依存構造の混合

デザイン次元依存とデザインデシジョン依存の混合


上記のサブ仕様は、それぞれあるデザイン次元から選択されたデシジョンの一つを表すと考えられる。
design_sapce.png


たとえば、「キャラクタは、クリティカル率をステータスとして持つ 」は、あるデザイン次元における一つの選択であると考えられる。たとえば、他のデシジョンとしては「システムは、クリティカルを攻撃を表すためのクリティカル率を持つ(system_level_critical)」が考えられる。

前者の場合は、より詳しく書くなら「各キャラクタは、自身のステータスの一つとして、クリティカル率をもつ。また、クリティカル率は、レベルやその他の要素により加減するとする(chara_level_critical)」ことを意味している。

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

scalar critical_rate_spec: (system_level_critical, chara_level_critical, other)


このように、他のサブ仕様も、なんらかのデザイン次元における一つのデシジョンであると考えられる。

たとえば、「ステータス画面で、クリティカル率を表示する(view_yes)」は、「ステータス画面で、クリティカル率を表示する(view_no)」というデシジョンを持つ。


scalar critical_rate_view: (view_yes, view_no)


ここでは二つのデザイン次元があるとした。
-クリティカル率次元
-クリティカル率表示次元

妥当な組み合わせは、次の通り。
(system_level_critical, view_no)
(chara_level_critical, view_yes)
(chara_level_critical, view_no)
enum.png



これからは、もし、chara_level_critical から system_level_critical に変化したときには、critical_rate_view に影響を与える可能性があることが分かる。

もし、view_yes なら、view_no に変化しなければならない。

一方で、system_level_critical から chara_level_critical は、critical_rate_view に影響を与えない。

また、chara_level_critical の時には、view_yes から view_no あるいは、view_no なら、view_yes の変化は他に影響を与えない。
state_transition.png




仕様の依存構造と仕様実現(タスク)依存構造の混合


ある仕様が変化したとき、それに伴って他の仕様も変化する必要がある。上記の例でいえば、キャラクタレベルのクリティカル率から、システムレベルのクリティカル率の仕様の変化は、ステータス表示仕様の変化を要求する。

これは、依存関係の一つの種類だと思う。


もう一つの種類は、タスクの観点からの依存。つまり、どの順番で仕様を実現していかなければならないのか、の依存。

たとえば、「キャラクタは、クリティカル率をステータスとして持つ」と「ステータス画面で、クリティカル率を表示する」の仕様は、実現の順序関係があると思われる。クリティカル率の仕様が実現された後でないと、表示仕様を実現するタスクに取り掛かれない(直感的には)。

同様に、
-クリティカル率を基に,通常攻撃より大きなダメージを与える攻撃を行う
-通常攻撃と異なる効果音を出す
-攻撃ヒット時に「Critical」文字列を表示する
の三つは、順序関係がある。

後者の二つは、「攻撃結果」を入力として受け取り、クリティカル攻撃だった場合に関係する仕様だと言える。

一方前者は、「攻撃結果」がクリティカル攻撃かどうかを決める仕様だと言える。

まとめ:


考察は以下の通り。

-(1)デザイン次元レベルでの仕様依存の分析:仕様間、あるいは、サブ仕様間の依存関係を分析するためには、デザイン次元を考慮したうえでの分析が有効に思える。

-(1)仕様依存とタスク依存の区別:仕様の変更における依存(仕様レベルの設計空間における状態変化)と、仕様を実現する上でのタスク順序の依存の区別が必要に思える。

参考文献:

Yuanfang Cai

Modularity in Design: Formal Modeling and Automated Analysis

PhD Dissertation.

DL: http://www.cs.virginia.edu/~yc7a/Publications.htm

スポンサーサイト

コメント

コメントの投稿


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

トラックバック

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

FC2Ad

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