asatoの技術的な日常日記

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

スポンサーサイト

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

デザイン:デザインパターンにおける設計問題と設計解の変化過程

更新履歴:

2008.04.25:誤字・脱字を修正。


昨日の 自分のTwitter で垂れ流した内容を(オリジナルに近いのは こちら)自分でさらに考察してみる。


スタートポイントとなったのは、とある論文にあったこんな記述。

[...] Evidence in support of first-person knowledge is provided by the fact that different designers are likely to produce different designs for the same set of requirements. And the same designer is likely to produce different designs at different points in time even though the same requirements are presented. This is a result of the designer acquiring new knowledge while interacting with their environment.


Gero, JS and Kannengiesser, U (2008) A Function-Behaviour-Structure ontology of processes, AIEDAM (to appear).

気になったのは次の点。

 (1)同じ要求が与えられたとしても、設計者が異なれば、異なるデザインを出力する。
design_output1.png


 (2)同じ要求が与えられ、同じ設計者であっても、設計する時期が異なれば、異なるデザインを出力する。
design_output2.png


僕は最近は デザインパターンの研究 をしているので、このことをデザインパターンの観点から考えてみた。

このことをデザインパターンの観点から考えてみると、複数の設計者のその時の設計知識を基にして抽象化・一般化して記述されたのがパターンといってもいい気がする。したがって、オリジナルの筆者に加えて他の人がパターンの執筆に加わっていたとしたら、パターンの記述内容は変化する可能性がある。さらには、オリジナルの執筆者が後にパターン記述を見直したとき、記述内容は変化する可能性がある。



上に書いたことを考え直してみると、いくつか間違いとか疑問とかがある。

 (間違の点)設計知識というよりは設計経験といったほうが適切だった。

 (疑問の点)抽象化・一般化の定義が曖昧なので、この点はちゃんと考える必要がある。

僕がここで1つ意識してたのは、各パターンの解(クラス図とかの構造)だけでなく、パターンの記述内容も考えの対象にしている点。つまり、そのパターンがどんな設計問題を解決しようとしているのかとか、どんなフォースがあるのかとか、パターン解以外にどんな代替案があるのかとか、そういうのも含めてる。

「したがって~」からの後半の部分は、最初に引用した論文の内容を基に考えると、あってる気がする。


続いて僕はこう書いてみた。

とここまで書いた思ったのだけど、もしかするとパターンの品質とか妥当性の評価は、元々の記述内容が '変化しない度合い' によって測ることができるのか? 元々のアレクサンザーのパターンの定義はここでは置いておくとして。


ここで、いきなりパターンの品質とか妥当性の評価の話になってるのは、僕がいまこのテーマを研究しているため。

で、上で書いたときの感覚をうまく伝えるのは難しいけど、感じたのは、パターンの記述内容が変化しないということは、パターンの記述内容が適切だった、といえるんではないかということ。特に、パターン解が変化しないということは、それこそがパターンの本質なんではないか、ということ。

なぜこの点がひっかかるかというと、ソフトウェアにおけるデザインパターンの場合、パターン解はプログラミング言語に依存するから。たとえば、アスペクト指向言語のひとつである AspectJ でパターンを再実装してみた、というような研究がある。この観点からいうと、従来のオブジェクト指向におけるパターン解と、他の言語でのパターン解は、プログラム構造(クラスだけでなくアスペクトも構造要素として用いられている)の点で異なる。

アレクサンザーの話を最後にいってるのは、この点が気になったから。つまり、元々の建築におけるアレクサンザーのパターンは、ソフトウェアと同じように解の構造が変化するのかわからなかったため。この点に関しては、パタンランゲージ本などを読み直す必要があると感じてる。


続いてこう書いた。

各パターンが解決の対象とする設計問題があるとして、パターンはその問題への解を与える。一方で、その解は、問題を解決する解候補の1つにすぎないともいえる。

パターン解と代替案の違いの1つの側面は、解の安定性にあるのかもしれない。つまり、問題の状況が変化するとして、パターン解から代替案への変換の度合いと、代替案からパターン解の変改の度合いには違いがあるはず。 別の言葉で言えば、代替案からパターン解へのリファクタリングを行う度合いと、代替案からパターン解へのリファクタリングの度合いは異なるといえるきがする。



「解の安定性」というのは、ここでは厳密に定義はしていないけれど、図で僕のイメージを伝えるとこんな感じ。
design_transformation.png


問題空間とは何か?とか解空間とは何か? とかの疑問はとりあえず置いておくことにする。

この図の例では解として、パターン解、代替案A~Cの4つあると考えてる。

それぞれの解が、問題を解決する(かもしれない)とする。この部分についても今後考える必要があるけど、とりあえずは、そういうことにする。

「解の安定性」という言葉でいいたかったのは、ある解から他の解への変換がどれだけ行われるのか、という度合い。

図の例で言うと、こうなる。

 ・パターン解から他の代替案への変換数は、0
 ・代替案Aから他の解への変換数は、2
 ・代替案Bから他の解への変換数は、3
 ・代替案Cから他の解への変換数は、1

この場合、パターン解が一番小さな数字なので、一番安定した解であるといえる、というのが僕がイメージしたこと。

ただ、上のTwitterでの発言では書いていないけど、気になることがある。それは、解が安定しているからといって優れているとは必ずしもいえないのではないか、という点。たとえば、解がそこで留まってしまっている、つまり、この解から他の解への変換数が少ない理由は、他の解への変換自体が難しいからかもしれない。特に、アーキテクチャレベルで考えると、イメージしやすいと思う。あるアーキテクチャから他のアーキテクチャの変換が難しいのは、変換自体が困難であるためとも考えられる。もちろん、この点についても検証する必要がある。


続いての発言。

この変換の度合いの違いは、恐らく問題空間の問題の変換の度合いの違いに関わってくると思う。

とすると、設計問題A-->Bの変換と、設計問題B-->Aの変換の度合いが異なるのは何故だ?

もっと一般的には、問題の変換のプロセスに、何か特徴があるのか? たとえば、問題の(構造?)は複雑になっていくように変化していく、など。これは、リーマンのソフトウェア進化の法則からなんとなく言ってみただけだけど。

再びソフトウェアの文脈でいいなおしてみると、要求仕様(ソフトウェアの機能・非機能、振る舞い)の変化、もしくは設計問題(ソフトウェアの構造、構造の品質)の変化を観察するとき、何か法則はあるのか?


最初の文は、図で書いたのと矛盾してるかもしれない。図では、問題が変化せずに解だけが変化すると捉えての議論だった。

ここで感じていたのは、解の変換(変化)の度合いが対称でないのと同じように、問題の変換(変化)の度合いも対称でない、ということ。もし、非対称であるとするなら、この非対称性を生み出す原因はなんなのだろう? また、問題は複雑になっていくようには変化するけれど、簡単になっていくようには変化しないのか? もし複雑になっていくとするなら、どのくらいの複雑さに変化していくのだろう?

最後の複雑性の点は重要に思える。つまり、あるデザインパターンの解が優れており、僕が上で単純に定義したように解の安定性が高いとしても、もし問題が複雑になり続けていくなら、その安定性は保てなくなるかもしれない。

スポンサーサイト

コメント

コメントの投稿


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

トラックバック

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

FC2Ad

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