抽象化とプログラム理解(2008/5/10):System.out.println("[TaskInstruction] before interception: " + current); current = intercept(current); System.out.println("[TaskInstruction] after interception: " + current);をアスペクトにした場合の抽象。具体的なログ内容とポイントカットされているという抽象の違い。
アーキテクチャ or デザインパターンの構造化のやり方(2008/5/3): 自然言語とかプログラミング言語と同じように、(アーキテクチャ or デザイン)パターン or パターン言語の書き方、という解説が必要かもしれないと感じてる。もちろん、『Pattern Hatching』とかに書かれてる、パターンを書く際の心構え(?)みたいなのは既にある。あと "A Pattern Language for pattern writing" という論文もあるけど、僕が想像してるのとはちょっと違うかも。まだちゃんと読んでないので読む必要あり。
要求構造のモジュール化(2008/4/26): 「Modularity is a structural fact: its existence can be determined by inspecting the structure of some particular thing.」『Design Rules』より。ここで重要になるのが、Structure つまり、構造という単語。構造の定義ってなんだろう。僕は単に、要素とその間の関係として、簡単に定義してる。間違ってるかもしれないけど。この構造の定義に従うと、要求仕様も構造を持つ。ある仕様と他の仕様の間にはなんらかの関係がある。たとえば、仕様Aは仕様Bの存在を必要とする、など。で、さっきのモジュラリティの定義をここで使うと、要求仕様の構造にもモジュラリティは存在するのか? という疑問が浮かぶ。これがさっき思ったこと。モジュラリティは、構造から得られる特性・性質の1つだと思う。そして、一般にモジュール化は、構造に対する操作だと考えられる。『Design Rulues』本の用語を使えば、構造に対するモジュラオペレータ。ソフトウェアの分野では、主にプログラム構造を対象とし、モジュール化やモジュラリティという言葉を使う。要求構造に対しても、同じようなことはいえるのだろうか?
そうだ。思い出した。適当に書きながらアウトプットしてみる。ある程度の規模のソフトウェアを作っていたとして、次にもう一度それを作り直すとして、前と後で同じアーキテクチャになる or するだろうか?まあ、たぶん作り直す理由としては、アーキテクチャレベルで死んでるから、というのもあるかもしれないし、単にアーキテクチャが死んだ、ということもあるかもしれない。architectural drift だっけ? 専門用語でいうと。 Architectural erosionか。で、architectural drift は起こっていないとする。起こっていないので、architectural erosion もない。たとえば、一人でそこそこの規模のソフトウェアを作っている、というような状況を想定。そういうときに、ソフトウェアを作り直す理由はあるだろうか? 「ただ座って問題ドメインのことを考えているだけでは、再利用可能なフレームワークは開発できない。正しい抽象概念を思いつくような洞察を持つ人はいない。ドメインエキスパートは、頭の中にある抽象概念をどうやってコード化すればよいかを理解できないし、プログラマはそうした抽象概念を導き出せるほど、ドメインをよく理解できていない。」この場合は、フレームワークだけど、単なるアプリケーション開発でも、程度は違っても同じようなことはいえるはず。 「Finally, design activity occurs within two contexts: the context within which the designer operates and the context produced by the developing design itself. The context shifts as the designer's perceptions change.」なんの話かわからなくなってきたけど、いえそうなのは、コード(or アーキテクチャ)を変更してなくても、いつコード(アーキテクチャ)をみるかで、品質に関する評価は変わるかもしれない。ドメイン(or 設計するコンテキスト)のことを初めから十分に理解していることがないとすると、初めに想定したアーキテクチャでは、不十分かもしれないことが明らかになりうる。もちろん、原理的には、リファクタリングを繰り返していけばアーキテクチャレベルで改善していくことも可能だと思う。『Refactoring in Large Software Projects』とかを読んだことを思い出しながら、適当に発言。さっきの話の続きかどうかは知らないけど、設計手法の構成要素って何だろう? ある設計手法間の違いは、どんな設計を出力できるかの違いだとすると、何になるのかな。ぱっと適当に思い浮かぶのは、「原則の集合」「設計 or 解空間の構築方法(?)」とか?今、ぱっと適当に思い浮かんだことだけど、モジュール間の依存がインタフェースやデザインルール(『Design Rules』本)で分離されているとして、その後、インタフェースに守られた範囲でモジュールを追加などするとする。で、アーキテクチャレベルの構造の変換 or リファクタリングは、モジュール構成を大幅に変えるとすると(インタフェース or デザインルールの変更が必要。この仮定が正しいのかは不明)、変更前にどれだけデザインルールに依存しているモジュールがあるのか、ってのは結構な影響じゃないのか。
他に適当に思いつくのは、設計問題だけど、たぶん、普通の開発で使うような要件仕様っぽいのが必要。あとはうまく解けたかどうかの評価基準。これが難しい。要求仕様を満たすのは必須だけど、他の評価基準として何を使うのか。理解容易性、保守性、拡張容易性、速度などなど。そもそも「どう設計する?」の目的は何か。僕のもともとのモチベーションは、遊びではなく、本気があった。で、その違いはどう影響するか。 本気の立場からいうと、たぶんベンチマークを作りましょう、という話になるんだと思う。実際、数年前これに向けてちょっと途中まで研究してた。でも、ベンチマークを作る、というのは、作ること自体が難しい。ベンチマーク or ベンチマーキングの話で僕がすきなのは "A Theory of Benchmarking with Applications to Software Reverse Engineering", http://www.ics.uci.edu/~ses とすると二つの観点からの考慮が必要になるのか。お題を作る側と、お題を解く側。恐らく「どう設計する?」の場合、お題を作る側が結構苦労するんじゃないかと思う。でも、遊びの立場をとるなら、どうなんだろう。適当に、教科書とかにのってる例題をお題に使えばいいのか?そもそも「どう書く?」に参加してる人は、何を楽しんでるんだ? この言語だとこう書けるよ。とか、こういう書き方もあるよ、みたいな感じ?またまじめな話に戻るなら、Parnas曰く。「Software Engineering is the design of useful programs under one or both of the following conditions: ...」 「... 1. More than one person is involved in the construction and/or use of the program, and ... 」 「... 2. More than one version of the program will be produced.」, "Some Software Engineering Principles" より。 この基準からいれば、「どう書く?」は、ソフトウェア工学の問題に直接関わるよーな問題を扱っているわけじゃないよーな気がする。では、この二つの基準(多数での開発・使用とプログラムの保守・進化)を扱えるような、「どう設計する?」を考えればいいのか? それとも、もっと中間的なものを考えればいいのか?とりあえず、研究的・実用的な観点を薄めて「どう設計する?」みたいなのを立ち上げるとしても、それなりに需要がなきゃいけない気がする。みんな「どう書く?」で満足しているのか?
TDDとクリエイティブデザイン(2008/2/28):ブログ記事かこうと思ったんだけど、TDDとルーチン、クリエイティブ or イノベイティブデザインとの関係が気になったので久々にkent Beckの『Test-Driven Development』本を取り出してる。仮説としては、TDDは経験済み(orルーチン)のデザインを行うときは有効だと思うけど、その他のデザインについては有効じゃないかもしれない、ということ。 まあ、そもそも、ソフトウェアデザインでのルーチン、クリエイティブ or イノベイティブデザインを議論しなきゃならない気もするけど。
TDDとFBS(2008/2/28):
ゲームデザインとイノベーション(2008/2/24):ゲームデザインとイノベーションが気になって、ドラッカーの『イノベーションと企業家精神』を再読してた。John Gero さんによれば、デザインは、ルーチン的なのと、クリエイティブ的なのと、イノベイティブ的なのがあるとしている。ゲームデザインの観点からこれらがどう関わるのかを考えていきたい。"Creative designing: An ontological view"
設計順序の原則パート2(2008/2/22):気になってるのは、たぶんRational Unified Processの本かなにかだったとおもうけど、アーキテクチャから先に作れ、ということとの関係性。ユースケースとかの視点も必要かもしれない。これらの点は、今まで勉強不足だったのでいい機会なので調査してみる。もうひとつは、Alexander の『The Nature of Order』Book2とか読んでて思ったことだけど、Step-by-Step Adaptation?だったかな? それの観点からどう関わるのかという点。あるいは、もっと抽象度を低くすれば、モジュール化の方法(オブジェクト指向、アスペクト指向、フィーチャ指向などなど)がどう影響してくるのかという点。特に、フィーチャ指向の場合は、機能っぽい単位でモジュール化になってくるきがするのでどう影響するのか気になる。もくしくは、Parnasの情報隠蔽の観点か、ボールドウィンのデザインルールの観点もあるかも。さらには、要求の構造(?)と解の構造(?)の関連性の観点からは、どうせなら、Alexander のノートの研究にまでちょっとさかのぼって考えてみてもいいかも。
ソフトウェア医学(2008/2/21):『病気はなぜ、あるのか』を読んでいて思ったことだけど、Software Medicine (ソフトウェア医学)っていう概念はありだろうか。ソフトウェア保守は、変更していく活動だし、ソフトウェア進化は、変更過程そのものを対象とする。Wikipediaによると医学とは「生体の構造や生理機能についての探求や、疾病の性状、原因について調査し、その診断、治療、検査、予防等についての研究診療を行う学問である。」とある。そのままで少し変えると「ソフトウェアの構造やソフトウェア機能(生理機能は何に対応する?)についての探求や、疾病の性状、原因について調査し、その診断、治療、検査、予防等についての研究診療を行う学問である。」 で、まあ『ソフトウェア病理学 -システム開発・保守の手引-』があるのは知ってるけど。 読んだことはない。
抽象概念としての設計のモデル(2008/2/19):むしろ、問題はデザインパターンじゃなくて、より一般的に、コードを抽象化してより抽象的なコンセプト(設計もしくはデシジョン?)を表現する or 設計をモデル化するとはどういうことなのか、という議論が必要なのかもしれない。まだ読んでないけど、"Abstraction Classes in Software Design" が関係するかも。
進化容易なパターンコンセプトのモデル化(2008/2/19):前から取り組みたいと思ってるんだけど、ある(デザイン)パターンが書かれた時点での経験をもとにしているとすると、パターンは改善・進化の対象となる。『ソフトウェアアーキテクチャ』本にも書いてたとは思う。とはいえ、この10年で、そんなに個々のパターンを改善する、という試みはなかったきがする。何件かは知ってるけど。恐らく、挑戦しようとした人はいたんだろうけど、何か困難があったんじゃないかと思う。 『Pattern-Oriented Software Architecture: On Patterns and Pattern Languages』本にも、このトピックは議論されてないような気もするし(読んで確認は必要)。 『Pattern Hatching』にはもしかすると関連することが書かれてたかも。確認が必要。
『The Nature of Order』の議論が検証できるように、ソフトウェアの何らかの要素をモデル化?(2008/2/18):
ゲームデザインで何のための仕様変更か(2008/2/17):
設計進化の漸進度の適切さ(2008/2/17):Status intercepterの例。STRだけインターセプトできるインタフェースだけが要求されてる場合の例。今は必要ないが VIT もインタフェースに含むかどうか。