asatoの技術的な日常日記

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

スポンサーサイト

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

メモ:科学と定量化

更新履歴
2008.03.05:「Designerly Ways of Knowing: design discipline versus design science」への参照を追加。
2008.01.05:論文のタイトルを載せました。


デザイン科学という言葉が気になる。「なんとか科学」、そもそも科学とは?

ドラッカーによれば:

 科学とは、多くの専門家が考えているような、定量化のことではない。もしそうならば、占星術は科学の女王となる。占星術は科学そのものでないことはもちろん、科学の応用でさえない。占星術は、現象を観察し、一般化して仮定とし、その仮定を観察によって検証する。しかしそれでも占星術は、科学ではなく迷信である。古代の航海上の記憶のヒントにすぎなかった獅子や魚への連想から、星座とその黄道内の動きに意味を与えるなどということなど、子どもじみた迷信以外の何者でもない。

 つまり、科学であると言いうるには、一貫した整合的かつ総合的な前提、そして公理の構築に加えて、科学の対象となる世界、すなわち有意なる現象を合理的に定義しなければならない。しかも、この科学の世界に関する定義と基本とすべき公理の構築は、いかに雑なものにとどまろうとも、科学的な手法を適用する前になさなければならない。これがあって、初めて科学的な手法が適用可能になり、大きな力を発揮しうるのだ。


P.F. ドラッカー経営論, 「経営科学の罠」, p. 79. より。

もちろん、ウィキペディア先生も参考に。

デザインと科学との関係について参考になる論文。


N. Cross, Designerly Ways of Knowing: design discipline versus design science, Design Issues, Vol. 17, No. 3, pp. 49-55, 2001.


スポンサーサイト

メモ:進化できるとできないの区別

書きなぐり。後でちゃんと議論したい。思いつつままに書いてる。


カウフマンの「自己組織化と進化の論理」を読んでいて感じたこと。

ソフトウェアが進化できるとできないの区別は何か?


新たな要求に対応することが難しくなったとき、いくつかの対処が考えられると思う。一つは、スクラッチで書き直す。もう一つは、再構造化などをする。もう一つは、そのまま難しいけど、要求に対処する。

スクラッチで書き直す場合、ソフトウェア進化だといえるだろうか?

他の二つは違和感はない。


で、感じたのは、すでにある要求を保ちながら進化する必要があるという前提がありそうなこと。

この前提を破ればどうなるだろう? 

追加しながら進化することはできそうなのに、削除して追加というプロセスがあまり聞かないのはなぜだろう?

モジュラリティはこれにどう影響してるんだろう?

モジュラリティが高ければ、容易に追加できるというのはよくきく。容易に削除できるというのもありそうな話。プロダクトラインとかフィーチャー指向プログラミングとかではそういう観点だと思う。


構造の再構築は、少なくとも、機能要求を保ったまま行われる気がする。構造が変われば、構造の性質(保守性や、性能、モジュラリティ)なども影響が受ける気もする。

要求を満たしたまま、進化させようとするのは何故だ?

もし、あるシステムが10の機能要求からなるとしよう。

そのうちの半分の5個の機能要求を分離できたとして、別々に進化はできるだろうか?

いったん全体として進化(成長)してきたら、もう個別に進化はできないのか?

モジュラリティが高ければ、ここのモジュールは、他に影響することなく進化でやすといわれる。もちろん、インタフェースは保つ必要があると思うけど。


機能5個を実現する構造と、その機能5個+5個を実現する構造は異なる?


機能・非機能要求を保ったまま進化しなければならないのは何故だろう?


10つの要求を満たすためにデザインされた構造があるとする。後に、そのうちから一つの要求を削除する必要が出たとする。で、実際に削除する。このとき、構造は、9つの要求に対して最適なデザインといえるだろうか?

もちろん、何が最適なのかを議論する必要があるとは思う。

でも、たとえば、デザインパターンは、初めから適用しまくるべきではなく、状況にあわせて適切に使っていくべき(Refactoring to Patterns)という議論もある。

アルゴリズムが一つの機能要求を表すとしよう。二つのアルゴリズムをサポートするだけなら、Strategyパターンは必要ないかもしれない。10個のアルゴリズムになったら、必要になる。

その後に、8つのアルゴリズムが不要になったとする。Staretegyパターンをアンリファクタリングするだろうか?

さらに、一つのアルゴリズムだけになったら?

よほどドメインを絞っていない限り、ソフトウェアに要求される機能は増えていくと思う(リーマンの法則に書いてたっけ?)。


でも、フルスクラッチで書き直すこともないかもしれない。コアの部分(フレームワークを想像)はコピペできるかもしれないし、末端のユーティリティクラスなんかは、再利用できる可能性がある。

ユーティリティクラスが、独立して進化していけるのは、直接要求を満たしていないからか?


結局モジュラリティの話?

Ultra-Large-Scale Systems - The Software Challenge of the Future

Kevin Sullivan さんのページ久しぶりに見てたら、

 Ultra-Large-Scale (ULS) Systems: The Software Challenge of the Future

という本?があったので気なったりした。

どうやら「Ultra-Large-Scale (ULS) Systems」というプロジェクトがあるらしい。

ワークショップも何度か開催されているようだし興味深い。


 

依存の粒度、DSM、XPI などなど

アノテーションつかって、アドバイスが適用される側のコードとアスペクト側のコードの依存を軽減できる?

たとえば、実際の例:

before:
public aspect RoomBoundsChecking {

before(Room room, int x, int y) :
args(*, x, y) && this(room) && execution(void setMapCharactor(..))
{
if (x >= room.getWidth() || y >= room.getHeight() ) {
throw new IllegalArgumentException("x >= getWidth() || y >= getHeight()");
}
}
}
public class Room {
....
public void setMapCharactor(MapCharactor chara, int x, int y) {

chara.setLocation( toAbsoluteLocation(x, y) );

charactors.put(new Point(x, y), chara);
}
...
}
after:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface BoundsCheck { }


public aspect RoomBoundsChecking {

before(Room room, int x, int y) :
args(*, x, y) && this(room) &&
execution(@BoundsCheck * Room.*(..))
{
if (x >= room.getWidth() || y >= room.getHeight() ) {
throw new IllegalArgumentException("x >= getWidth() || y >= getHeight()");
}
}
}
public class Room {
....
@BoundsCheck
public void setMapCharactor(MapCharactor chara, int x, int y) {

chara.setLocation( toAbsoluteLocation(x, y) );

charactors.put(new Point(x, y), chara);
}
...
}


あと、数分で適当に考えた DSM (Design Structure Matrix):

dsm1

dsm2




色々疑問とか思ったこと:

  • アノテーションってデザインルール or XPI になってる?
  • 依存の粒度って重要かも。メソッドのシグニチャとかメソッド内部の実装とか
  • DSM のツールってどこかにないの? 手書きでやるのめんどくさい


関連しそうな文献:
Gregor Kiczales and Mira Mezini
Separation of Concerns with Procedures, Annotations, Advice and Pointcuts
European Conference on Object-Oriented Programming (ECOOP), Springer LNCS, 2005
http://www.st.informatik.tu-darmstadt.de/public/Publications.jsp


William Griswold, Kevin Sullivan, Yuanyuan Song, Macneil Shonle, Nishit Tewari, Yuanfang Cai, Hridesh Rajan,
"Modular Software Design with Crosscutting Interfaces",
IEEE Software, Special Issue on Aspect-Oriented Programming, Jan/Feb 2006.
http://www.cs.iastate.edu/~hridesh/research.shtml

FC2Ad

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