asatoの技術的な日常日記

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

スポンサーサイト

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

コード進化パターン:トップレベル interface の追加

Java におけるコード進化パターン」を更新。今回は、抽象クラスからなるクラス階層のトップに interface を導入するという進化の例。
スポンサーサイト

コピー&ペーストプログラミング

面白い記事。

 マイクロソフトによる講演「Windows Vista ゲーム開発」- 数多くの国内PCゲームが躓いたIME問題は、SDKサンプルのささいなバグだった!?

サンプルコードがバグってるのに、みんな気づかずにコピー&ペーストでプログラミングしていた、という話。

これに対する一つの反応は、コピペプログラミングはけしからん、というものかもしれない。しかし、コピペプログラミングは プログラミングの原則 の一つかもしれない。

ソフトウェア工学の観点からは、この課題にどう取り組めばいいだろう?


関連記事:
[CEDEC 2007]TSFにUAC。Windows Vistaベースのゲーム開発における「ちょっといい話」 (4Gamer.net)


更新履歴:
2007.10.02:関連記事へのリンクを追加。


Groovy でメタプログラミング

 Groovy got the best meta programming elements

Groovy は、全然さわってないけど、面白そうですなー。メタプログラミング体験として、そろそろ Groovy ってみるかなー。

ソフトウェアの美と品質

初トラックバック。変なこと書いてたらすいません。

ひらさんが「ソフトウェアにおける美とは何か」について書いてるので、反応してみよう。

面白い問いだと思うけど、色々と疑問はある。この記事ではどんな疑問があるのかを考えたい。ひらさんの意図していた議論とは少しずれているかもしれないけど。


まず、ソフトウェア開発者は、美という性質を追及する必要があるのか? について。いい例えかどうか分からないけど、数学者は、"役に立つ" 数学を追求する必要があるのだろうか?

Bertrand Meyer さんは「Object-Oriented Software Construction」という本の最初でこう書いている。

Engineering seeks quality. software engineering is the production of quality software. [...]


そして、ソフトウェア品質についてこう書いている。

[...] Software quality is best described as a combination of several factors.


そして次のような特性(ファクター)について議論している。
・Correctness
・Robustness
・Extendibility
・Resusability
・Compatibility
・Efficiency
・Portability
・Ease of use
・Functionality
・Timeliness

もちろん、他の品質特性もあると思うけど、これらの特性の中には、「美」に直接関係するものは無いように思える。では、それらの特性と「美」との関係はなんだろうか?

たとえば、より美しいソフトウェアを追い求めることは、これら品質が高いソフトウェアを追い求めることなんだろうか?


「美」だけがひらさんの議論の中心ではないと思うので、上記の議論は少しずれているかもしれない。というのも、ひらさんは、次のように「感動」という言葉を強調していると思うので。

僕は、ソフトウェアに美が存在しなければ、多くの人に認められそして感動されるような美が存在しなければ、ソフトウェア開発者は永遠に不幸であるような気がする。

~途中省略~

美しさとは感覚に依存するものだろう。であるなら、ヒトの感覚に訴えるソフトウェアを作れるなら、そこに美が宿る。ソフトウェアに感動する。




ここで、「美」というのを、ソフトウェア開発者が追い求めるべきソフトウェア品質の一つだと仮定しよう。

ソフトウェア開発者は、高品質のソフトウェアを開発することが目標なので、開発しているソフトウェアの品質の確認は重要な行為だと思う。たとえば「このソフトウェアは再利用性が高いだろうか? このソフトウェアの性能は十分だろうか? このソフトウェアは使いやすいだろうか?」といった疑問をなげかけ、もし十分な品質が得られていなければ、改善するかどうかを検討する。

もし「美」が品質の一つなら、同じように問いかけることは役立つだろうか? 「このソフトウェアは、十分に美しいだろうか? このソフトウェは、感動させられるだろうか?」

ここでは、誰が「美」や「感動」を感じる対象であるのかを明確にしておく必要がある気がする。大きく分けて二つ考えられる。
(1)開発者:開発者は、恐らく、ソフトウェアの内部構造に関する「美」や「感動」に関心がある。

(2)ユーザ:ユーザは、ソフトウェアの内部構造には関心は無い。ソフトウェアが提供する機能に関わる「美」や「感動」に関心がある。

もし、ひらさんの議論が二番目のユーザにあるなら、僕はこの記事ではこれ以上議論しない。

一番目にあるなら、もうすこし議論する。

そのどちらでもないなら、僕が間違った議論をしているので、ここで終了。


具体的な例で考えてみよう。最近読んだ、APIデザイン を例にしてみる。

あることをするためのライブラリ(API)が二つあるとする。APIを使う側の開発者からすると、これらのAPIをどんな観点から比較・評価するだろう? ありそうな問いは「どちらのほうが使いやすいだろうか?」や「どちらのほうが、理解しやすいだろうか?」といったものだと思う。しかし「どちらのほうが、美しくて感動できるだろうか?」という問いを行うだろうか?

APIユーザの追及する品質が「使いやすさ」であったり「理解しやすさ」であるなら、開発者はこれらの品質が高いAPIを設計しなければならない。API設計時に「このAPIは美しいだろうか?」と問いながら考えれば、「使いやすく」「理解しやすい」APIが生まれるのだろうか?


二番目の例。ソフトウェア内部構造の「美」とは何だろう? 我々は、たとえば、よりモジュラー(モジュール性が高い)なソフトウェア構造を見ると、より「美しい」と感じるのだろうか? 感じるかもしれない。しかし、単に「感じる」だけかもしれない。

オブジェクト指向が提供する技術では、十分なモジュール性を得られないことが知られている。たとえば、アスペクト指向プログラミングやフィーチャ指向プログラミングなどは、オブジェクト指向よりもさらに高いモジュール性を提供するための技術であると考えられる。

これら新しいモジュール化の技術は、「美」の追求の結果として現れたのだろうか? 通常論文で書かれる品質は「モジュール性」「再利用性」「理解容易性」「保守性」などであり、「美」ではない。


以上のことから、僕は、ソフトウェア開発者が考慮すべき品質特性として「美」を考えることはそれほど役に立たない気がする。理由は以下の点。

(1)「美」よりも具体的な品質特性がある。

(2)ソフトウェア開発技術の発展は、「美」という特性の直接的な追求の結果ではない。


今回の記事の目的は、「ソフトウェアにおける美」を考えるのは、くだらないということを主張したいのではなく、もし美を考えるなら、いくつかの疑問に答えなければならないとうことでした。以下は、疑問のまとめ。

疑問のまとめ:
(1)ソフトウェア開発者が追求するべきものが、高品質なソフトウェアであるとするなら、ソフトウェアの「美」の追求は重要だろうか?

(2)「美」は品質特性の一つだろうか?

(3)もし、「美」が品質特性の一つなら、開発者が「このソフトウェアは十分に美しく、感動させられるか?」という問いを発することは役立つだろうか?

(4)もし、「美」が品質特性の一つでないとするなら、何か? なぜ開発者は「美」を気にする必要があるのか?

(5)もし、ソフトウェアの美やその美から得られる感動を与えたい対象がソフトウェア使うユーザであるなら、開発者の役割は何か?

コード進化パターン:抽象クラスのジェネリック化

Java におけるコード進化パターン」を更新。今回は、抽象クラスをジェネリックにするというリファクタリングのコード進化の例。

Evolution Styles

まだちゃんと読んでないけど、

Olivier Le Goaer and Peter Ebraert

Evolution styles: change patterns for Software Evolution

Proceedings Third International ERCIM Workshop on Software Evolution 2007

http://w3.umh.ac.be/~infofs/preprints/index.php?page=paper_info&ID=199


この論文って、僕のやってる「Java におけるコード進化パターン」のプロジェクトに似てる気がする。

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


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

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


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

パターン適用の確認

あるデザインパターンをシステムに適用したかどうかを知るにはどうすればいいだろう。

デザインパターンのカタログを読み、そこで書かれているあるパターンは今まで知らなかったものだが、今作っているシステムでそのパターンを適用している ような気がする。しかし、本当にそのパターンを適用したことになっているか確信が持てない。

この状況に対する二つの反応が考えられる。

(1)あるパターンを適用しているかどうかを知ることは重要でない。私は設計上の問題を熟考し、現在の解決策を適用した。その解決策がパターンだったかどうかは関係ない。

一方で、パターンを適用したかどうかを知ることが重要だという主張も考えられる。

(2)あるパターンを適用したかどうかを知るのは重要である。パターンは問題と解決策の関係を表現する。パターンの適用を知ることで、どんな設計上の問題があったのかを理解できる。パターンの記述を読むことで、なぜそのような設計になったのかを理解できる。仕様変化などでパターンが適用された構造を変化させなければならないとき、設計の意図を壊さないように安全に変更することができる。

二番目の主張は仮説を含んでいるが、妥当に思える。


もし二番目の主張が妥当だとしたら、あるパターンを適用したかどうかを知るのは重要だということになる。ここでの課題は、適用したかどうかを確認するのが難しい点にある。よく知られたパターン、たとえば、Singleton パターンなどなら確認は簡単かもしれない。しかし、自分の良く知らないパターンである場合、難しい。

難しくなる要因にはいくつか考えられる。

(1)開発者は、そのパターンを十分に理解できるだけの経験がない。

(2)パターンの適用範囲、もしくはバリエーションの範囲が広い。そのため、パターンの記述でカバーされている範囲外に実際に適用したバリエーションが存在している、と開発者は感じている。

(3)パターンの記述形式は、パターンを適用したかどうかをチェックできるのに適した形式ではない。
pattern.png



要因のひとつには、(3)がある気がする。パターンを学ぶのは難しい。パターンをマスターするために GoF のパターンカタログだけを読むのは不十分だったのは、その後入門書が何冊も出版されたことからも分かる。したがって、パターン記述に則った形式に基づき、異なる観点からパターンを記述できると考えられる。

pattern_desc.png


感じるのは、もうすこしフォーマルな記述があってもいいんではないかという点。


関係しそうな文献:

Neil B. Harrison, Paris Avgeriou, Uwe Zdun, "Using Patterns to Capture Architectural Decisions," IEEE Software, vol. 24, no. 4, pp. 38-45, Jul/Aug, 2007

Frank Buschmann, Kevlin Henney, Douglas C. Schmidt, Pattern-Oriented Software Architecture: On Patterns and Pattern Languages, John Wiley & Sons, 2007

Decision Support Systems

前回の記事に書いたように、設計が意思決定に関わるものだとしたら、設計に関する情報だけでなく、意思決定に関する情報にも注目しておき必要があるのかも。

ってことで「Decision Support Systems」というジャーナルがあるっぽい。

設計のジャーナルは、僕が集めたのをここにまとめてる。

Scala メモ

Scala メモ」を更新。たまに触るぐらいじゃあ、なかなか慣れない。

コード進化パターン:hook operationの追加

久しぶりにコード進化パターンを更新。

 Java におけるコード進化パターン
 

ソフトウェアは技術

実際の設計-こうして決めた」という本に次のような記述がある(19ページ)。

 個々の技術が存在しているとき、その技術を作ったときの決定の過程の記述は何故必要なのであろうか。それを示したのが図2.1である。できあがった技術をただ単に見ただけではその技術を真に理解し、利用し、更に発展させることはできない。そんなことを可能にするためには、今見えているものを生み出した過程、なかんずく、決定した過程を知らなくてはならない。図2.1(a)に示すように、技術の獲得には今見えているものを生み出した思考の過程を知ることが必要であり、そのことは技術を生み出した者自身がその思考の過程を記述し、他人に伝達可能な形に持ってゆく必要がある。このような記述をしたものは、同図(b)に示すように技術伝達に必要な閾値を越えるので、時間・空間・組織・文化・技術分野を超えて水平展開が可能となるが、そのような記述のないものは閾値に達することがないので消滅してしまう。


ここで上記の文の「技術」を「ソフトウェア」に置き換え、さらに、ソフトウェアの進化・発展を強調してみよう。


 個々のソフトウェアが存在しているとき、そのソフトウェアを作ったときの決定の過程の記述は何故必要なのであろうか。それを示したのが図2.1である。できあがったソフトウェアをただ単に見ただけではそのソフトウェアを真に理解し、利用し、更に発展させることはできない。そんなことを可能にするためには、今見えているものを生み出した過程、なかんずく、決定した過程を知らなくてはならない。図2.1(a)に示すように、ソフトウェアの獲得には今見えているものを生み出した思考の過程を知ることが必要であり、そのことはソフトウェアを生み出した者自身がその思考の過程を記述し、他人に伝達可能な形に持ってゆく必要がある。このような記述をしたものは、同図(b)に示すようにソフトウェア伝達に必要な閾値を越えるので、時間・空間・組織・文化・ソフトウェア分野を超えて水平展開が可能となるが、そのような記述のないものは閾値に達することがないので消滅してしまう


いくつかの疑問が思い浮かぶかもしれない。

・「設計文書がそのような記述に相当するのではないか?」設計文書は、選択肢を明示的に記述しているだろうか? 決定とは、選択肢からの選択である。設計文書は、なぜその選択肢が選ばれたのか問う根拠を記述しているだろうか?

・「ソースコードは、そのような記述に相当するのだろうか?」相当しないと考えられる。ソースコードは、概念的な決定を含まない。たとえば、開発者が想定(決定)したアーキテクチャのスタイルと、ソースコードを分析して抽出された実際のアーキテクチャは一致しているだろうか?

デザイン: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)



ソースコードからソフトウェアデザインは学べるか? その1

ソースコードからソフトウェアデザインは学べるか?」

まず、この質問/疑問は、適切なものだろうか? つまり、「うどんとラーメンどちらが優れているか?」といった類の質問でないかどうか。

適切だとしたら、次に、この疑問に答えることは重要なのだろうか? もしYESなら、その理由は?


この疑問に答える上で、最初の難関は「ソフトウェアデザイン」という用語の定義だと思う。まず、ソフトウェアに限らず、工学におけるデザインとは何か? 次に、ソフトウェアにおけるデザインとは何か?


次回に続く。

FC2Ad

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