asatoの技術的な日常日記

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

スポンサーサイト

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

デザイン:問題の構造化

過去の記事で何度か、デザインとは何かについて考えてみた。デザインの一つの側面は、意思決定ということだった。

「デザインとは何か?」対するGrady Boochの回答
デザイン:Design is a decision-making procedure/process


デザインと意思決定について書かれた論文を少し前に見つけて読んで勉強中なので軽く紹介してみる。この論文は、ソフトウェア設計者に対して彼らが行った意思決定についてインタビューした、という内容。

以下は論文の結論(強調と改行は僕による)。

Conclusion #1 is that software design is primarily about problem structuring.

Conclusion #2 is that the more structured the design problem was, the more the interview subject primarily discussed rational approaches to solve the problem, and the more that naturalistic approaches were facilitators to this discussion.

Conclusion #3 is that the less structured the design problem was, the more the interview subject primarily discussed naturalistic approaches to solving the design problem, and the more that rational approaches were facilitators to this discussion.

Conclusion#4 is that decision makers use either NDM or RDM as the dominant decision making approach but use aspects of the other decision making approach to implement their decision, depending upon the structure of the decision.





C. Zannier, M. Chiasson, F. Maurer

A Model of Design Decision Making based on Empirical Results of Interviews with Software Designers,

A Special Issue of the Journal of Information and Software Technology, p. 637–653, Feb 2007.

DL: http://ebe.cpsc.ucalgary.ca/ebe/index.php/Publications/Home



まだこの論文については勉強中なので、変な疑問しかいえないけど、問題の構造化といった場合、どこまでいうんだろうか? 問題と解が対になっているとすると、直感的には、問題の構造化と解の構造化が存在するように思える。

問題の構造化といえば、マイケル・ジャクソン の「プロブレムフレーム」の本が思い浮かぶ(買ったけどちゃんと読んでないので、今軽く読んでる最中)。論文で言われている構造化とプロブレムフレームの構造化が同じかどうかはわからないけど。

でこの本では、プロブレムフレームとデザインパターンが似ているとしている。似ているというのは「繰り返し発生する状況を特定し記述する」という意味らしい。

たとえば、あるデザインパターンを洗練するとしよう。もっと具体的に言うと、新たな実装方法が見つかったのでそれをパターン記述に加える、という感じ。この場合、解の構造に対する洗練を行ってるんじゃないだろうか? と感じる。

いずれにせよ、論文が言う意味での問題の構造化をきちんと理解しないといけないのかもしれないけど。

デザイン:設計手法

設計手法って何だろう? 手法とかにあまりこだわらない or 気にしない僕なので、今までちゃんと考えたことが無い。

Nikos Salingaros さんの「A Theory of Architecture」という本を読んでいたら、こんなことが書かれていた(強調は僕)。


[...], a design method depends upon the number of solutions it can generate. We are arguing for including all possible design solutions to choose from. [...]



誤読してたらあれだけど、さらに当たり前かもしれないけど、ある設計手法とその他の設計手法の違いの一つは、その手法が生成する解の種類と数だと言えるんじゃないかと思う。

ここでは、簡単のため、あるプログラミング言語を使うとし、設計手法はその言語に依存するとする。

design_method.png


異なる二つの設計手法をもとに、簡単な例で考えたい。

一つ目の手法は、クラスのフィールド(データ)をきちんとカプセル化するという手法。

二つ目の手法は、クラスのフィールドを定義しても、カプセル化するかどうかについては何も言わない手法。


一つ目の手法が生成する解は、例えば次のもの。

public class MyClass {

private int n;

}



一方、二つ目の手法が生成する解は、次の二つ。


public class MyClass {

private int n;

}





public class MyClass {

int n;

}




だから何? という内容かもしれない。では、リファクタリングの役割とはここでは何だといえるだろうか? リファクタリングは設計手法だろうか? 

先ほどの例を使うなら、「フィールドのカプセル化」のリファクタリングをどう解釈できるだろう?


design_method2.png


上の図を見て分かるように、リファクタリングは、異なる設計手法の間をマッピングするような手法であると言えると思う。

もう少し一般的に言えば、ある解からある解へのマッピング手法。同じ設計手法でのマッピングかもしれないし、異なる設計手法でのマッピングかもしれない。


一般的な議論すぎて何も面白くないかもしれない。でも、もし、設計手法によって生成できる解の数と種類が異なるとしたら、どんな設計手法が望ましいだろう?


解の数と種類だけを考えた場合、設計手法の種類としては次の可能性が考えられる。

design_method3.png


5番目は論外だとしても、じゃあ、4番目が一番望ましいのか、という話になるかもしれない(1番から3番と、4番と5番の図を一緒に表したのは間違いかも)。

そもそも、4番は手法ではないといえるかもしれない。

さらに、そもそも、ある手法の間で解の種類と数が異なるのは何故だろう? ということになる。異なるのは、適切な解(その手法の解空間に含まれる解)と適切でない解(その手法の解空間に含まれない解)を区別する、制約やガイドラインがあるためだと考えられる。


とすると、設計手法とは、制約やガイドラインの集合で構成されるといえる。

とすると、ある意味では、細かな構成要素に分解できたことになるので、構成要素を組み合すことで様々な設計手法を再構成できるとも考えられる。


中途半端だけど考察終わり。


デザイン:「Design Rules」よりデザインの定義

デザインの定義例の紹介。今回は「Design Rules (日本語版)」という本の冒頭(二ページ目)にある定義というか、「デザインとは何か」の記述の紹介。


[...] Design is the process of inventing objects -- our "things" -- that perform specific functions[1]. These objects, the products of human intelligence and effot, are called "artifacts"[2]

[1] Christopher W. Alexander. Notes on the Synthesis of Form.

[2] Herbert A. Simon. The Sciences of the Artificial.


前回に書いた二つの記事と比べてみるといいかも。
「デザインとは何か?」対するGrady Boochの回答
Design is a decision-making procedure/process


「デザインとは何か?」対するGrady Boochの回答


「デザインとは何か?」という質問に対して、Grady Boochさんの回答があるみたい。「On Design」というブログ記事。

基本的には、デシジョン(意思決定)の観点からの回答。


ちなみに「Pattern-Oriented Software Architecture: On Patterns and Pattern Languages」という本の214ページにその議論があって、今読んでたら発見した。

デザイン:Design is a decision-making procedure/process

Yuanfang Cai さんのページを久しぶりにみてたら、見てなかったプレゼン資料があった。

 Modularity in Design. Invited talk at CMU. April, 2007

で、気になった記述。

Design is a decision-making procedure [Alexander 1970]

Alexander は、Christopher Alexander のことだと思う。どの本かは、分からない。「Notes on the Synthesis of Form」かな、と思うけど。


ついでに、「Design Rules」本の Carliss Baldwin さんの「Steps Toward a Science of Design」というプレゼン資料には、Herbert Simon の仕事を参照してこうある。
Design is a decision making process (under constraints of physics, logic and cognition)



前のページ

FC2Ad

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