オルタナティブ・ブログ > An Agile Way >

アジャイルに行こう!

分析とは何か、設計とは何か?

»

blog5-1ソフトウェア開発を「問題解決」、と見ると、 
問題→解という活動だと考えられる。左の「問題」は、問題空間にあり、右の「解」は解空間にある。設計とは、このマッピングを行なう活動だと考える。では、分析とは何か。 

実際には、(ソフトウェアでは特に)問題が複雑だったり曖昧だったりすることから、このままではうまく解けない(悪構造 ill-structured problem)。そこで、一旦、この「問題解」という現実世界の問題をモデル化しよう、ということになる。「問題空間」、「解空間」という空間と直行する空間軸として、上下に「モデル空間」と「現実空間」を導入する。そうすると、4つの象限が現れる。その4つの象限に、現実空間の「問題」と「解」、そして、モデル空間の「分析モデル」と「設計モデル」を置く。ここで、分析モデル=モデル化された問題 、設計モデル=モデル化された解である。そして、問題→解という直線的な解き方ではなく、一旦モデル空間に上って遠回りをしてみる。

 分析モデル→設計モデル

   ↑    ↓

   問題   解

問題を一旦モデル化する活動を「分析」と呼ぶ。成果物は、「モデル空間上の問題」(分析モデル)だ。そして、モデル空間上で解決させる活動を、「設計」と呼ぶ。成果物は、「モデル空間上の解」(設計モデル)だ。最後に、モデル空間から現実空間へと逆変換する。これを実装と呼ぶ。成果物は解、すなわち(ソフトウェア開発であれば)動くコードである。 

まとめると、設計とは、問題空間から解空間への変換である。ただし、一旦問題をモデル化し(分析)、それをモデルで解決する(設計)。つまり、モデル領域で変換する。そして、解のモデルを、再度現実領域にもどしてやる。これで最終的な現実世界の解にたどりつく。 

blog5-2

最後のミッシングリンクは、現実領域での、問題と解との突合せ、すなわち「テスト」である。テストによって、「右回りの活動」がもともとの意図である「問題→解決」と合っていることを示す。そう、この「テスト」こそが、問題に対する解が正しいことの最終的保障になるのだ。

Thanks > ぁまんにょさん(このロジックは二人の共作)

実は、最後の一行は、「だから、ソフトウェア開発は「テスト」を第一級の概念として扱うべきなんだ。テストしやすい設計、は決して本末転倒ではない。 」という文がありました。ですが、ちょっと「落ち」として不適切だったので、取りました。

(この話は、verification/validationの話をちゃんとしないと誤解を生みそうなので)

Comment(0)

コメント

コメントを投稿する