凡庸な物書きが気をつけるべきことは、荒削りで不正確な表現を、正確な表現に性急に置き換えないことである。そんなことをすれば、最初のひらめきが殺されてしまう。小さな植物にはまだ生命があったのに、正確さのために、枯れて、すっかり無価値となる。ゴミとして捨てられてしまいかねない。貧相でも植物のままであったなら、なにかの役には立っていたのだが。


研究


連載中

  • 原則のモデル化
  • 設計原則のメタモデル化
  • 設計順序の原則

ゲーム系

  • ルーチンゲームデザインのためのチェックリスト

一般系

  • 生き方知識

個別ネタ


  • コンサーンの活性化(2009/3/14): さっきの僕の関心をもうちょっと具体的(といっても抽象的ですけど)にいうと、プログラミングor設計しているときには、プログラマは色々なことを気にしながらやってると思います。特に僕が興味あるのは、プログラム解に影響を与えるような関心事orコンサーンです。たとえば、ある機能を実装している場合or部分的な問題解決に取り組んでいる場合には、再利用性、可読性、保守性、性能、ポータビリティ、拡張性、その他色々なことを考慮して、解の選択を行なうと思います。で、僕の興味は「いったいどれくらいの考慮する項目があるんだろうか? 」というものです。可読性や拡張性といった比較的抽象的な考慮点だけでなく、今ある問題に近い具体的な考慮点もあわせて全てです。次の興味は、「じゃあ、これらの考慮点の個々の特徴、さらには考慮点の間の関係はどうなっているんだろう?」という疑問です。たとえば、可読性はどんなプログラムを書いているときでも考慮するようなものですが、常に考慮し続けるということはないかもしれません。別の言い方をすると、部的な問題を解決するときに、*活性化*する考慮点にはどんなものがあるのか。活性する/しない/再活性する/しないといったタイミングはどんな時か、というふうに僕の中ではイメージしてます。

  • 機能の分解性(2009/2/2): 普通のアプリでの機能orフィーチャの再利用(プロダクトライン的な意味で)と、ゲームでのそれとは同じだろうか? たとえば、機能A、B、Cがあって、AとBを利用するとか、AとCを利用するとかいうのと、ゲームシステムでの機能a, b, c があって、a, b とするのは同じだろうか?何かしらの違いがある気がする。うまくいえないけど、それは、ゲームの場合、満たしたい要求は、機能的なものではなく、非機能的な性質or楽しさとか面白さとかに重点を置くからな気がする。適当な機能を組み合わせても、それらの性質を満たせるとは限らない。従来のプロダクトラインとかでももちろん、非機能要件はある。たとえば、機能を削減することによって組み込みなどリソース制限がきつい環境でも対応できるようにする、など。ある機能とある機能を組み合わせて、それらの機能要件を満たすことと、ある非機能件を満たすことは違うということか?多くのゲームのシステムを細かなシステム(機能?)に分解するとする。で、動作する機能の組み合わせの集合があるとする。でも、その集合の中で、非機能的な、ユーザにとって面白いとか楽しさを感じさせる組み合わせは単なる機能の組み合わせより少ない(と思われる)。

の- 作業担当(2009/1/12): なんとなく疑問。同じ要求仕ちょっと別の話。開発作業をたとえば、A、B、C、Dに作業単位(orモジュール)に分割できるとする(簡単のため作業量は同じと仮定)。担当者としてa、bさんがいるとする。このとき、たとえば、aさんがAとBを担当することと、aさんがAとCを担当することは同じだろうか?同じでない、と思う理由は、モジュール間の関係が同じと限らないという点。たとえば、モジュールA、Bは、大きなモジュールXの分割結果で、CとDはYのそれかもしれない。このとき、AとBを担当と、AとCの担当では理解度とかの点で異なることになる気がする。

  • 言語の作業分割への影響(2009/1/12): なんとなく疑問。同じ要求仕様を、言語Aで開発するときと、Bで開発するときで、どれだけ作業を分割できるか、とかの違いは、どんな違いになるんだろうか。もちろん、開発する人の言語スキルで分割の行い方の違いは出ると思うけど。.

  • 変更の独立性を備える構造(2009/1/8): 昨日思ったこと。プログラム構造の進化に、独立性みたいな性質はあるのだろうか? たとえば、一人でプログラムを作っているなら、自分の構造上のルールだけに従って構造を変化させていける。一方で、複数人が同じ構造を変更する場合、みんなが構造を変化させる上でのルールor(ボールドウィンらのいうデザインルールといえるかも?)を理解していないといけない。それってモジュール化orモジュラリティじゃないの? との指摘があるかもしれない。でもちょっと違って、構造を変化させるある種のルールは、他のルールよりも、互いに存在をしらせておく度合いが低いように思える。たとえば、リファクタリング。クラス間でコードの重複がある場合、スーパークラスを作ってコードの重複をなくすような変更操作。このような操作は、たとえば、AさんがBさんにこういうリファクタリングやるよ、と知らせておかなくても別にやっていいような雰囲気がある。もちろん常にではないけど。このように、現在の構造上の性質だけから、各プログラマが独立して構造を変更していけるようなのってないだろうか、みたいな。逆に言えば、そのような構造上の性質を *多く備える* 構造を規定するようなプログラミング言語なんかを考えられるだろうか?

  • DSMの分解(2008/11/9): DSMの分解

  • アーキテクチャ(2008/11/3): 平鍋さんの記事への反応

  • センター(2008/9/6): ソフトウェアの構造って"コア"or"中心"みたいなのがあるのだろうか。複数の中心があるかもしれない。で、その中心内と外では要素の依存の度合いは同じだろうか?たとえば、クラス内の要素の依存の度合いと、クラス間の要素の依存の度合いは同じだろうか? SOAでの、サービス間の依存の度合いは同じだろうか? 直感的には、SOAなどでは度合いは緩いように感じる。もし、中心から近い構造と、遠い構造で違いがあるなら、構造の何らかの特性も違うといってもいいかもしれない。ということは、どんな特性を持つ構造が(環境に)適しているのかを考えるとき、構造を作る言語or仕組みも異なる気がする。モジュール化するとは、中心を移動することだろうか?

  • ソフトウェデザインデシジョン(2008/7/23): とりあえず思ったのは、ソフトウェア開発のコミュニティでこの問い、つまり、開発者、特に設計者のデシジョンをよくするにはどうすればいいか? に答える研究は十分に行われているんだろうか? ということ。我々は、開発者がどんなデシジョンを日々行っているか十分に知っているんだろうか? 開発者は、適切なデシジョンを日々行えているんだろうか? 多くの状況で一般的に発生するような誤った or バイアスされた(?)デシジョンはあるのだろうか?我々は、適切でないデシジョンを行わなせないためにどんなアプローチを行ってきたのだろうか? 僕がぱっと思い浮かぶのは、設計手法、設計原則、デザインパターンなど。これらのアプローチだけで十分だろうか? これらのアプローチは適切だろうか?

  • ドメイン特化仕様(2008/7/21): ドメイン固有の暗黙的な仕様ってどんなのがあるんだろう。たとえば、ゲームで、十字キーでキャラクターを操作できること、というのは明示化されなければならないのだろうか。あるいは、ドメイン固有の、ありえない仕様ってどんなのがあるんだろうか。たとえば、ゲームの場合、アナログスティックではキャラクターを操作できるけど、十字キーでは操作できないこと、というような仕様になることはあるんだろうか。

  • SFBSフレームワーク(2008/7/4):Studying Design Creativity'08の論工学での設計プロセスを一般に表現するモデルにFunction-Behavior-Structure Frameworkがあるんだけど、これにServiceを追加して拡張できるかもしれないと昨日寝ながら思った。 もしくは、Goalの要素もからむかもしれない。

  • Model Transformations as Execution Process(2008/6/24)
  • Reflective Model(2008/6/24)
  • Model VM(2008/6/24)

  • デザインバイアス(2008/6/22):Studying Design Creativity'08の論文チェックしてて単に感じたことだけど、クリエイティビティな思考してることと、クリエイティビティな成果物が作られることは、別に考える必要があるのかな、と思った。で、Geroさんの"Creative designing: An ontological view"の論文思い出した。この論文では、historical creativity、psychological creativity、situated creativityの三つがあるとして議論してる。 プログラマの成果物がソースコードだとして、プログラミングにクリエイティビティな側面があるとすると、他人があるプログラマのクリエイティビティを感じる対象は、ソースコードになるのかな?しかし、プログラミングに意思決定の側面があるとして、ソースコードに意思決定結果が表現されるわけでないとすると、意思決定結果に関わるクリエイティビティは、感じられない(?)ことになる気がする。

  • デザインバイアス(2008/6/21):設計に意思決定側面があり、ヒューリスティクスな側面があるとするなら、設計するさいに、何らかのバイアスはあるのだろうか? 設計(デザイン)バイアスって存在するのかな。
    • ソフトウェアパターンとバイアスの関連性を考えてみるのも面白そうですなー。

  • 開発プロセスと拡張性の考慮(2008/6/5):開発プロセスは、拡張性とかをどれだけ考慮すればいいのかについての思考にどんな影響を与えるんだろうか? たとえば、同じ開発者が同じ要求仕様を、異なる開発プロセス、たとえば、ウォーターフォールなのとアジャイルなのとで設計する場合、拡張性の考慮の度合いにどんな違いが出るのだろうか?拡張性の考慮の違いは、結果的には関数やクラスといったモジュールのインタフェースをどういうものにするのかという違いになる。アジャイルな開発プロセスでやってきた開発者が、ウォーターフォールな開発プロセスで開発を行わなければいけなくなった場合、アジャイルな開発プロセスの時の拡張性考慮の思考は通用するだろうか? あるいはその逆(ウォーターフォールからアジャイル)の場合は?

  • プロセスモジュラリティ(2008/5/27):ソフトウェア構造のモジュール化はできても、つまり分担作業はできてるけれど、それでも完全に作業が分割されているわけではないと感じる。何が分割されていないか。それはドキュメントとか開発のポリシー、あるいは開発文化に思える。 ウォーターフォールでやってる開発を、部分的にアジャイルにするのは困難だと思う。何を思い浮かべながら書いてるかというと『Design Rules』の話。うまく言い表せてるかどうかわからないけど言ってみる。インタフェース(やデザインルール)を決めることで、構造を分割し、分割された単位で作業ができるようになる。しかし、開発プロセスの分割はどうか?たとえば、オープンソースの開発なんかで複数人が開発に関わっているとして、各開発者がどんな開発プロセスでそのプロダクトに関わるかを考えてみると、必ずしもみんなが同じプロセスで行う必要はないと思う。プロダクトもプロセスも分割するほどいいとは思えないけど、その適切な分割度合いを決める要因はなんだろう。

  • ソフトウェア開発における解の抽象化(2008/5/17):プロダクト(or 要素、対象)も抽象化(とさらに一般化)されて表現されるように、プロセスも抽象化(とさらに一般化)されて表現されるものなんだよなー。つまり、現実世界におけるなんかのプロセスを表現する場合、抽象化の結果として残った情報と残らなかった情報が存在する。抽象化は、たぶん3つのパラメータを受け取る。1つは抽象化の対象、もう1つは、抽象化の向き、最後は、抽象化の度合い。最後の二つは異なる要素として見なすのが適切かどうかはわかないけど。したがって、抽象化して表現する、つまりモデリングするとき、抽象化の向きと度合いの妥当性を常に意識しておく必要がある。ソースコード、プログラム構造、さらにはそれらのレベルで表現できない概念的な設計上の決定を対象として抽象化(さらには一般化)するとはどういうプロセスなのかが最近興味ある。


  • 抽象化とプログラム理解(2008/5/10):System.out.println("[TaskInstruction] before interception: " + current); current = intercept(current); System.out.println("[TaskInstruction] after interception: " + current);をアスペクトにした場合の抽象。具体的なログ内容とポイントカットされているという抽象の違い。


  • モデルを作るプロセスとメタモデルを作るプロセスの違い(208/5/6):とはいえ、メタモデル、とかメタメタモデルを作るときって、必ず抽象化のプロセスを含むのだろうか。ここで抽象化は、情報のフィルタリングのプロセスだと考えてる。なんか、予想外に面白そうな疑問にぶちあたった間がある。モデルを作るのと、メタモデルを作るのは、同じプロセスを含むのだろうか? もちろん、モデルとメタモデルの関係は非対称なので、異なる部分はあると思うけど。非対称という言葉は適切なのかな。ちょっと間違ってるかも。例で言うと、モデル駆動開発でのモデルとメタモデルの間の関係の1つは、モデルはメタモデルに従う、というもの。逆、つまり、メタモデルがモデルに従う、という関係はない。


  • 順序的進化(2008/5/5): ある構造Aから構造Bに変換(リファクタリング)しようとする場合があるとする。変換過程は、小さな変換aとbで構成されるとする。さらに、a->bの順序でもb->aの順序でもAからBの変換結果に到達できるとする。このとき、a->bの変換順序とb->aの変換順序では変換の難しさは異なる場合がある。

  • 非一貫性進化(2008/5/5): あるプログラム構造Aから他のプログラム構造Bへの変換(リファクタリング)を行う場合、変換のステップ数や複雑さによっては、構造Aの設計と構造Bの設計が混ざる。したがって、たとえば、アーキテクチャレベルに当てはめると、アーキテクチャAからアーキテクチャBへの進化の場合、ソフトウェアは、進化の過程において二つのアーキテクチャ上の設計を保持することになる。

  • アーキテクチャ 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』本の用語を使えば、構造に対するモジュラオペレータ。ソフトウェアの分野では、主にプログラム構造を対象とし、モジュール化やモジュラリティという言葉を使う。要求構造に対しても、同じようなことはいえるのだろうか?


  • 抽象化の度合い(2008/4/20):コード進化パターンを4年ほど収集してきてさっきも書いてて難しいと思うのは、抽象化の度合い。デザインパターンがプログラムの構造を抽象化(と一般化?)して表現しているように、コード(or プログラム)の進化も抽象化(と一般化)して表現したい。とすると、コードを抽象化するとは、どういうことか。さっき書いてたコード進化の例だと、何に焦点を合わせてたかというと、interfaceに型パラメータを導入するようなコード進化。焦点が決まったので、ではこの焦点に関係しないものは何か。たとえば、interfaceのメソッド数は関係ない。どんなメソッドかは関係するかもしれない。というのも、あるメソッドは型パラメータをメソッドを使用するから。さらに、実際のコードでは、interface を実装するクラスなどからなるクラス(型?)階層があるとも言える。でも、さきほどの焦点でいえば、どんな型階層になっているのかは関係ないとして、無視することもできる。一方で、階層を無視しないことも選択肢としてはある。なぜなら、interface に型パラメータを導入することで階層に影響を与えるかもしれないから。むしろ、型パラメータを導入する動機は、下の階層から発生するしたのかもしれない(実際の作ってたゲームのコードでは発生した)。このように抽象化の度合いの難しさにどう対処すればいいのか。僕としては今のところ、抽象度を1つに絞るのではなく、複数の度合いの違う抽象化として表現しようと思ってる。ただこの場合は、表現する数が多くなってしまうという現実的な問題点もあると思う。

  • 全体性(2008/4/19):Martin FowlerさんのDSL本のページみてて思ったんだけど、それぞれのトピックが互いに関係しあっているとするなら、ひとつでもそのトピック要素がなくなったとしたら、どうなるんだろう。各トピック(Expression BuilderとかNested Closureとか)がパターンかどうか、そしてパターン言語かどうかは不明だけど、1つの要素が消えることで全体としての調和(?)は保てるのだろうか。なんでこんなことを思ったのかというと、今、Nested Closureのトピックをみて、RubyとC#のサンプルはあるのにJavaのはなかったから。Javaでもできるのかもしれないけど、もしできないとしたらNested ClosureのトピックはJavaの文脈では存在しなくなる。



  • 特定ドメイン向けのパターンの洗練・特化記述(2008/3/28):GoFの『デザインパターン』本なんかみたいに、解説が何冊も出てたりするなら、そこで書かれている個々のパターンを(完全にじゃないとしても)それなりに適切な状況で適切に使えるようにはなると思う。でも、よく知らないパターンだと、やっぱり難しい。たとえば僕は『プログラムデザインのためのパターン言語』で書かれている型オブジェクトがいまだによくわからん。サンプルコードがSmalltalkなのが原因かもしれないけど。もちろん、本に書かれているデザインパターンに無理に従う必要はない。各自の状況でその状況に適していると思われる解決策を自分でやればいい。で、実際に、少し前、作ってるゲームで型オブジェクトっぽい設計になった気がした。型オブジェクトになってるかはちゃんとは確かめてないけど、別に気にする必要はない。で、ここまでが動機っぽい話で思ったのはパターンになってるかどうか気にしなくてもいいとしても、やっぱり気にしたくはある、ということ。どういうことかというと、自分のさっきの経験でいってみると、特定のドメイン(僕の場合がゲーム)での各パターンの適用例があるといいんじゃないかということ。つまり、ある特定のドメインで、あるパターンがどんな状況で実際に使われることがあるのかを知ることは便利だと思う。でも、ブログとかでもたまに、「ゲーム開発でXXXパターン使ってみましたー」とかの記事をみかけるけど、これでは不十分だと思う。理由は、これは仮説だけど、GoFのデザインパターンのように汎用的っぽいパターンでも、適用ドメイン(たとえばゲーム開発)が違えば、問題の状況も異なるかもしれない。何を考慮するのか、という点でも、比重が異なるかもしれない。この仮説が正しいとすると、特定のドメインに向けてデザインパターンの記述(クラスとかの解構造だけじゃないよ?)を洗練・特化することが有効かもしれないということになる。いいたいことをまとめると、(1)特定のドメインでのデザインパターンの適用例があれば嬉しい、ということ。理由は、自分がやってるドメインに近いほど、パターンの理解もしやすいであろうということ。(2)特定のドメイン向けに、パターンを洗練・特化して記述できる可能性があるとするなら、それをしたらよいだろうということ。これは、その特定ドメインでの考慮点を初めから考えることなく、設計知識を再利用できることを意味する。なので、間違った設計になる可能性を減らせるかもしれない。課題としては、仮説の検証がある。特定ドメインで、汎用的なパターンを適用する場合、たとえば、GoF本で書かれていない点で新たに考慮しなければいけない状況が本当にあるのか、ということ。ある意味では、複数の特定ドメインで出現した問題・状況・解として抽象化一般化されたパターンを具体化・特化しなおすプロセスといえるかもしれない。


そうだ。思い出した。適当に書きながらアウトプットしてみる。ある程度の規模のソフトウェアを作っていたとして、次にもう一度それを作り直すとして、前と後で同じアーキテクチャになる 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 デザインルールの変更が必要。この仮定が正しいのかは不明)、変更前にどれだけデザインルールに依存しているモジュールがあるのか、ってのは結構な影響じゃないのか。

  • パターン言語の条件、メタパターン、メタパターン言語(2008/3/20):いま、アーキテクチャとか、デザインとか、イディオムレベルのパターンがどれだけあるのか知らないけど、まだパターン言語になっていないのかもしれないな。そんな気がした。逆に、パターン言語を構成する上で、パターン数はどんな意味を持つのだろう。何が十分なパターン数を決めるのだろう。極端なことをいえば、二つのパターンと、それらから構成されるパターン言語はあるのだろうか。

  • フィールドVSGenericプロパティ(2008/3/19): アイテムへの呪いとかのプロパティ。さび、祝福、その他のプロパティ。拡張性。ドメインモデルの拡張性との関係。パターンとパターン言語自体もシステムとみなせるなら(この前提が正しいかは不明)、メタパターンとかメタパターン言語とかはありえるのだろうか。

  • APIのドキュメントが設計に与える影響(2008/3/16):JavaDocみたいにAPIの表示の存在って、APIとかクラスの設計に影響を与えるんだろうか。イントロダクションの例。AJDOC。たとえば、いくつかの言語(AspectJ, MultiJava。Rubyもだっけ?)では、外部からクラスを拡張できるけど(or オープンクラス)。 このとき気になるのは、あるクラスのソースコードだけみてもどんなメンバが定義されてるのか分からないというもの。でも、AspectJのJavaDoc版のAJDocでは確か表示の上では元々クラスで定義されたメンバと外部から導入されたメンバが一緒なって表示される。あるいは、JavaDocじゃなくても、Eclipseとかのプラグインとして、外部から導入されたメンバも表示してくれるかもしれない。

  • ニコニコ動画の分析(2008/3/6):「[OGC2008#04]「ニコニコ動画は2007年最大ヒットのオンラインゲーム」ネット社会学の若手論客,濱野智史氏にネットコミュニティについて聞いてみた」の記事を読んで。

  • Model-Driven Requirements Evolution Analysis(2008/3/2):アナリシスパターン』とも『Domain Driven Design』とも関連しそうなんだけど、ちょっと分からん。他にキーワードは、Metamodeling、Software Evolution, Requirements Evolution みたいな感じ。

  • Interface Breaking Evolution(2008/3/2):クラスのインタフェースを更新するような進化? 進化リクエスタとプロバイダ?

  • 予期できた進化とできなかった進化(2008/3/2):

  • コード進化の非対称性(2008/3/1):今コード進化のドキュメント書きながらふと思ったことだけど、コード進化の対称性って何か言えるんだろうか。たとえば、クラスAからクラスBにアクセッサを移動するようなコード進化のとき、その後クラスBからクラスAにアクセッサを戻すような進化はAからBと同じ設計理由・根拠で起こるのだろか。直感的には非対称に思える。

  • どう設計する?(2008/3/1): 「どう書く?」に設計の問題がないのはそれなりに理由があると思う(というか関心がないのかもしれないけど)。設計の問題がどんな種類の問題であり、その問題をどうやって表現して、解をどう評価するのかを知らないからじゃないかと思う。僕も知らない。
    • 手軽であること --> 十分に問題を小さくしないといけない
    • やりやすい --> 入出力だけ書けば成立するから
他に適当に思いつくのは、設計問題だけど、たぶん、普通の開発で使うような要件仕様っぽいのが必要。あとはうまく解けたかどうかの評価基準。これが難しい。要求仕様を満たすのは必須だけど、他の評価基準として何を使うのか。理解容易性、保守性、拡張容易性、速度などなど。そもそも「どう設計する?」の目的は何か。僕のもともとのモチベーションは、遊びではなく、本気があった。で、その違いはどう影響するか。 本気の立場からいうと、たぶんベンチマークを作りましょう、という話になるんだと思う。実際、数年前これに向けてちょっと途中まで研究してた。でも、ベンチマークを作る、というのは、作ること自体が難しい。ベンチマーク 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" より。 この基準からいれば、「どう書く?」は、ソフトウェア工学の問題に直接関わるよーな問題を扱っているわけじゃないよーな気がする。では、この二つの基準(多数での開発・使用とプログラムの保守・進化)を扱えるような、「どう設計する?」を考えればいいのか? それとも、もっと中間的なものを考えればいいのか?とりあえず、研究的・実用的な観点を薄めて「どう設計する?」みたいなのを立ち上げるとしても、それなりに需要がなきゃいけない気がする。みんな「どう書く?」で満足しているのか?

  • 仕様変化の予測基準(2008/3/1):将来起こるかもしれない仕様の変化を、どこまで予測すればいいんだろうか。何か基準があるんだろうか。今一瞬思ったのは、ドメインメタモデル(クラス図)のレベルで変化しないレベルでは予測して対処してもいいかもしれない。武器の種類。

  • 仕様変化のモデル化(2008/2/29):アナリシスパターン、ドメインモデル。アイテムの追加。モデルとメタモデルでの進化。

  • デザインパターンの抽象度とドメイン特化度(2008/2/29):

  • TDDとクリエイティブデザイン(2008/2/28):ブログ記事かこうと思ったんだけど、TDDとルーチン、クリエイティブ or イノベイティブデザインとの関係が気になったので久々にkent Beckの『Test-Driven Development』本を取り出してる。仮説としては、TDDは経験済み(orルーチン)のデザインを行うときは有効だと思うけど、その他のデザインについては有効じゃないかもしれない、ということ。 まあ、そもそも、ソフトウェアデザインでのルーチン、クリエイティブ or イノベイティブデザインを議論しなきゃならない気もするけど。

  • TDDとFBS(2008/2/28):

  • 設計順序の原則パート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):Status intercepterの例。STRだけインターセプトできるインタフェースだけが要求されてる場合の例。今は必要ないが VIT もインタフェースに含むかどうか。

  • 設計解候補間の変換(2008/2/17):設計するとき、通常いくるかの設計解の候補が思い浮かぶ。たとえば、設計解A、設計解B、設計解Cなど。このとき、主観的であったとしても設計者は、各候補間で良いか悪いかの評価を行う。ただし、本当にある設計解が他の設計解と比べて優れているかは、実際にコーディングしてみないと分からないことが多いとする。これは ill-defined な問題の特徴の一つだと思う(『Engineering Design Method』本を確認しながら)。 そして、もし(1)扱っている部分的な問題が小さく、(2)各設計解の候補も小さく、とすると、ある解候補から他の解候補への変換が適切に可能かどうかが問題となる? 別の言葉で言えば、良くないかもしれない設計解候補から出発して、実際に良くなかったとしたら、他の設計解候補に適切にリファクタリングできるかどうかが関心となる?

  • コードレベルと設計レベルの状態空間(2008/2/14):コードレベルの状態空間(コンパイルできるコードの集合)と、設計レベルの状態空間は異なる?たとえば、Null Object の役割を持つクラスを継承して、さらに Null Object を導入するケースってどれくらいあるだろう。他にも、あるクラスのサブクラスとして、Null Object の役割をもつクラスが二つ以上あるケースってどのくらいあるだろう。


  • 進化ルールとリンファクタリングの関係(2008/2/13):ルールを破る場合はリファクタリングステップをなくす? Strategy パターンの例。設計構造の進化過程の一部を抽象化して表現しようとするとき、変更ルールとのからみが重要になるんじゃないかと思った。

  • 設計問題自体のモデル(2008/2/13):適切な抽象度を決める困難さ。

  • コンサーンのモデル。(2008/2/13):ある設計上の問題を考えているとき、プログラマーはコードの一部にしか関心を持っていない。たとえば、そのプログラマに、コードの要素(フィールドとかメソッドとかクラス)を見せて「この要素は今あなたの考えていることに関係するか?」と聞けば、する/しない/たぶんする/たぶんしない みたいな返答があると思う。他の疑問としては、たぶん、関係する要素の集合は、プログラマーごとに異なるんじゃないかと思う。もう1つの疑問は、あるプログラマーが関心をよせる要素の集合が静的なのか動的なかという点。おそらく動的。Representing Concerns in Source Code

  • ドメイン分析による進化的設計(2008/2/13):装備種類の進化とその進化に対する設計。

  • Metamodeling Software Design Concepts(2008/2/8):composition と superimposition の例。

  • 企画(or アーキテクチャ的構想)なしで、インクリメンタルかるイテラティブにゲームデザインして、面白いものに到達できるんだろうか。(2008/2/7):

  • ソフトウェアデザインにクリエイティブ性は必要か?(2008/2/6):John Gero の論文。

  • 抽象化のための原則(2008/2/5):抽象化の程度を決定するにあたっての原則が存在するかも?

  • フィーチャ図でパターン表現の例(2008/2/5):NullObjectの実装方法の例。サブクラス化といんたふぇーす。

  • ドメイン市場の規模(2008/1/30):ゲームのジャンル数。表計算ソフト。バリエーションの受け入れ。似たソフトでも購入者がいる。

  • RPGデザインにおける可変性(2008/1/29):キャラクター作成。コンフィグで対処できるものとできないもの。

  • 良いデザイン=悪くないデザイン(2008/1/29):ノート本の例。ミスフィット。

  • 問題が先。(2008/1/29):問題ドメインの表現。

  • OCamlでDP(2008/1/29)

  • 実装横断と紺さーん横断?(2008/1/28):⇒エフェクトの例

  • どこからどこが無視できるパターンの実装バリエーションなのか。(2008/1/12):情報隠蔽と関係?

  • 管理できるCCCと管理できないCCC(2008/1/10):

  • モジュラークラスターの体系的な開発手法?(2008/1/4):

  • 進化のスムーズさ(2007/12/22):NoO本を読んで。

  • DIをDSMで表現してみる?(2007/12/7):


  • ドメイン特化の問題の収集と設計への影響(2007/11/12):ゲームの例。キーのおしっぱの回避。表示のコンポジション。

  • 意思決定の抽象度がアーキテクチャなどの抽象度を決める?(2007/11/12):

  • 曖昧な要求(2007/11/11):セーブデータ数の例。3個か100個か。スクロール機能の有無。


  • 進化できるとできないの違い(2007/10/26):何を保ったまま変化しなければならないか? 要求を一時的になくして構造をよくするとかは無理? モジュラリティはこれにどう影響する?

  • 情報が進化の容易性に与える影響?(2007/10/25):geneとmemeの違い?

  • メトリクスは評価関数?(2007/10/25):パーソナルストッピングルールと表関数

  • problem structuring=re(2007/10/25):問題の構造化は、要求フェーズに対応?

  • 生物進化と人工物の進化の違い(2007/10/18):設計は、問題を解くこと。設計での解の変更にはコストがかかる。

  • アーキテクチャ設計とNatureOfOrderの一つずつの例(2007/10/15)

  • 環境制約の例(2007/10/2):UACの例

  • FOを目的としたリファクタリングと、AOを目的としたリファクタリングは同じか?(2007/10/1):
  • モジュール化の境界??(2007/9/24)抽象クラスに関わるリファクタリングの場合。クラス名の変更の場合。

  • POSA5のパターン合成の例をAODPで書き直したらどうなる?(2007/9/23)

  • intra-interレベルのデザイン構造の進化(2007/9/22):

  • フィーチャダイアグラムによるデザインパターンのデザイン構造の表現(2007/9/22):DPの進化の難しさ。

  • 初音ミク(2007/9/21):ウィキノミクスとの関係

  • 要求実装の順番。横/縦。共通項目の発見。(2007/9/21):キーボード、パッド、マウス

  • ノックアウトマウス。ノックアウトソフトウェア(2007/8/31)

  • アンチパターンは言語にならない(2007/8/21)

  • マップチップパラメータ。「氷の地面」「毒の床」「泥沼」(2007/8/21)
  • デバイスがデザインに影響。環境パラメータ。(2007/8/15)

  • 我々はデザインしているのか? ルーチン、イノヴェイティブ、クリエイティブデザイン(2007/8/10)

  • アーキテクチャなしの進化?(2007/7/27)

  • 原則のメタ思考(2007/7/27)
    • 原則を探す
    • 原則を疑う
    • 原則は階層的?

  • デザインのやり方の変更は、意思決定のやり方の変更

  • 情報へのアクセス容易性
最終更新:2009年03月14日 16:26