スポンサーサイト 

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

設計と実装に潜む状態遷移の罠 

ウォーターフール型ソフトウェア開発は理想論であり、現実的ではないと私は思っています。 けれどもアジャイルと言われるような開発スタイルにおいても設計と実装という概念が無くなるわけではないとも考えています。

 

一般的にウォーターフール型開発が理想論であると考える理由の一つに実装前に設計としての完全なアウトプットが不可能であるということが言えます。 完全でなければ設計の手直しが行われ、設計に手直しが行われれば大なり小なり実装に影響を与えます。 このようなスパイラルを繰り返して実装すべき項目が無くなっていくことで製品として出荷できることになります。 実装項目が減らなければデスマーチです。

 

実装項目を減らしていくということは逆に言えば変更することで実装項目が増えてしまう可能性がある部分に関してはできるだけ早めに設計を固めてしまうことが重要になります。 実装項目を増やしてしまうような設計変更要因は幾つもあるでしょうが、ここでは状態遷移をキーワードに考えてみました。

 

一つ目は考慮すべき状態の追加です。 status1が状態Aと状態Bを取りうるときにそれぞれ処理Aと処理Bを行うという初期の仕様に対して開発途中において状態C,Dを取りうるstatus2が登場し、 状態Dの時は処理Aは行わないことになったとします。さらに状態E,Fを取りうるstatus3が登場し状態Fの時は必ず処理Bを行い、 その際処理Aを行う必要がある場合には必ず先に行うことなどとなってくるとバグを仕込む可能性はかなり高くなってきます。 依存関係のある状態遷移については早めの仕様確定が望ましいのですが、そうも行かない場合もあるでしょうから、 設計や実装の際にif文をネストしなくて済むような構造を意識すべきでしょう。

 

二つ目はボトムアップ式に開発する際のソフトウェア構造です。状態Aと状態Bを取りうるstatusがあり、 モジュール1の関数mod1funcとモジュール2の関数mod2funcにおいてそれぞれ状態Aと状態Bで別の処理を行っていたとします。 それぞれ状態の取得はモジュールSのAPIから取得します。状態の遷移はモジュールSが別のコンテキストで非同期に行っています。 商品仕様としてmod1funcの処理とmod2funcの処理が同じコンテキストで同期が取られていなければならない場合、 モジュール単位でのテストでは何も不具合が生じないのに連結後のテストでは稀に発生する捕まえにくい不具合となります。モジュール1, 2は処理に徹するべきで、早めにモジュールSのAPI使用の排除をお勧めします。

 


コメント

コメントの投稿















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

トラックバック

この記事のトラックバックURL
http://ochoo.blog48.fc2.com/tb.php/48-57b23e0e

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