ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

ソフトウェア工学コミュのパターンあれこれ

  • mixiチェック
  • このエントリーをはてなブックマークに追加
どうも、別のトピックに出ていた「テストパターン」ですが、他にも色々とパターンってありますよね。

アナリシスパターン、デザインパターン、アーキテクチャパターン、テストパターン、アンチパターン(これはちょっと毛並みが違うかも知れない)

個人的にはあと、パフォーマンスチューニングパターン、例外処理パターン、や運用パターンなんてのが有れば良いなと期待しています。
まーパフォーマンスチューニングパターンの場合は結局、設計と実装のトレードオフが付きまとうので、デザインパターンの派生パターン+αてな感じで表現できてしまうのかもとも思っていたりします。
例外処理パターンはセキュリティとの絡みで既に研究されてそうな気もするのですが、実際にはどうなんでしょう。

てな感じでパターンについてあれこれ雑談できればと思います。お気軽にどうぞ。

コメント(15)

そんなにたくさんの文献を読んだわけではないのですが、アンチパターンが読み物としては一番面白かったと思います。
ハムレットさん:
Portland Patterns Repository をたとえば例外で検索すると、ずらずらと出てくるようですね。
http://c2.com/cgi/wiki?search=Exception
最近、エラー処理はアスペクトでくるんで切り分けられないかなと思うのですが、こういうのも、成功事例が積み重なればパターンになっていくのかもしれませんね。

希望のパターンがなくて困るなら、パターンの形に書いてみる、というのもいいんじゃないでしょうか。最初は名前だけで、記述は徐々に付け足すとか。
hei, Izu-ru さん:
確かにアンチパターンは経験則的な色が強いので、でその生々しさが面白かったりしますよね。『リファクタリング』での不吉な匂いとかも同様かな。

みんぺいさん:
おお、便利な物があるんですね。さーと見、なかなかまとめるの苦労していそうですね。アスペクトですか、確かに例外処理には相性は良さそうですよね。オブジェクト指向なんかで通常の機能要件から設計に入って、例外処理とか非機能要件の処理を追加して行くと、なんかごっちゃごちゃになりますが、機能要件と非機能要件って別々の関心事(Concern) なので、アスペクトとして分けた方がより自然に成ると思います。ただ例外処理の場合は、実装面で実行順序の不定性(プログラムでの可制御性といった方が良いのかも)などが問題となった場合、どうクリアするか、ちと難しいかもしれないですね。

よっしーさん:
PHP ですか、最近はオブジェクト指向化されたそうですね。ただ現状、デザインパターンって、オブジェクト指向を前提にしたものが殆どだと思いますが、まー非オブジェクト指向言語でも工夫しだいで何とかなるんかな。
ハムレットさん:
>> 確かにアンチパターンは経験則的な色が強いので、でその生々しさが面白かったりしますよね。

邪悪の理のようなものが垣間見えるような気がして楽しいです。
邪悪の源の七つの大罪というのがなんとも。
印象に残っているのは Lava Flow と Poltergeist ですね。
projct management の章はあまり真面目に読んでいないのですが、analysis paralysis は身に覚えがあり過ぎでした。

>> 『リファクタリング』での不吉な匂いとかも同様かな。

これオムツ管理の話ですね。

>> ただ例外処理の場合は、実装面で実行順序の不定性
>> (プログラムでの可制御性といった方が良いのかも)などが
>> 問題となった場合、どうクリアするか、ちと難しいかもしれないですね。

すみません、ここがちょっと良く分からなかったので教えてくださいまし。何を実行する順序なのでありましょうか?
hei, Izu-ruさん>すみません、ここがちょっと良く分からなかったので教えてくださいまし。何を実行する順序なのでありましょうか?

えーと、例えば AspectJ の場合ですが、通常の Java のプログラム中の横断的な関心事を示す Pointcut に具体的な処理を定義するAdvice をくっつけるわけですが、一つの Pointcut に複数の Advice が定義されている場合、その Advice の実行順序は完全に状況依存でプログラムした本人には制御できなかったと思います。そんな感じです。(今では改良されているんでしょうか。)
ああ、なるほど。よく分かりました。ありがとうございました。
雑感なのですが。

そう言えば、最近、別のトピックでアスペクト指向とか AOP とかの論議をしていますが、Object Orientedにおけるデザインパターンについても取り上げられており、再度改めて、考える事が多くなりました。(?(。_。).。o0O??

そんでもって、私がデザインパターンについて、学んだ本について最近、ちょっと読み直すことも多くなってきたので、mixi でレビューを書こうと思ったのですが、検索をかけても出て来ません。ググッて調べてみると・・絶版・・・L(゚□゚)」オーマイガ!

けど、とってもいい本なので、ここに簡単にレビューします。
------------------------------------------------------------------
デザインパタ−ンプログラミング ISBN: 4810181022 出版社: トッパン 著者: Wolfgang Pree 訳: 佐藤 啓太、金澤 典子 出版日: 1998/11

実はこの本、昔デザインパターンを勉強すべく、GoF のデザインパターンを買おうとしたのですが、帰りの少し電車賃が足りなく事が分かり、とりあえず近くにあったので買った本です。しかしながらホットスポットやフックメソッド、テンプレートの設計論等、フレームワークを構築する上で大切な概念・手法を学ぶ事が出来たし、継承と集約を使い、7つのメタパターンに分類して、そこから合成的に必要なデザインパターンを導き出すといった、GoF の博物学的なアプローチとはまた一味違った考え方に非常に感心したものです。却って GoF 本より良かったと思います。怪我の功名、貧乏もたまには良しですね。

しかし、GoF のカタログの本はしきりに注目される出るのですが、この本にあるメタパターンの話ってあんまり注目されなかったですね。やはり具体例で考える方が楽なのかな。短期的にはそうだと思うけど、結局そう言ったアプローチって、勘と経験、記憶力勝負で論理的な応用が聞かないような気もするんだけどな。うーんこの本が絶版になってしまった辺り、抽象的な思考による本質を捉えることの難しさがにじみ出ているような気がします。

後この本年代的に UML が無くったって Object Oriented で物を考え、表現できるという事の実例でもあります。
Pree の「デザインパターンプログラミング」は、非常に良い本でした。復刊.com でも候補になっているようですが。
http://www.fukkan.com/vote.php3?no=2946

Pree のメタパターンの考え方は、``The UML Profile for Framework Architectures'' ISBN 0-201-67518-8 において、`Framework Construction Principle' として受け継がれています。フレームワーク構造の記述に適している、というのがそこでの主張でした。

、、、というようなことも解説したパターンの本が、もうしばらくすると出版される予定です。
# 遅れに遅れてようやく 5 月出版と決まったかに見えたんですが、さらにもうちょっと遅れそうな雲行きではあります。
みんぺいさん:

復刊.com の情報ありがとうございました。
早速一票入れておきました。
出版予定の本も興味津々です。
またこのコミュでも教えて下さいまし。
hei, Izu-ru さん:
どうもありがとうございます。
パターン本(実は名前がまだ決まっていない(^_^;))が出るのはまだ少し先でもあるので、共著の細谷さんが書かれて最近出版された別の本をこの機会にご紹介しておきます。
「Javaデザインパターンハンドブック」
http://isbn.sbpnet.jp/2793
というもので、GoF のデザインパターンをパターンランゲージとして再構成することを試みているそうです。事実とすれば、野心的・画期的な試みだと思います。
パターンランゲージということは、パターンを適用することで現れてくる別の問題について、さらに別のこのパターンを検討して解きなさい、ということを指示しているわけで、単なるパターンカタログから進歩していると見ることができるでしょう。

私自身は現在、日本の技術書を入手しにくい環境にいるためまだ当分読めないのですが、細谷さんからご連絡をいただいて、一人の胸の内に収めておくのはもったいなさすぎると思いご紹介してみました。

なお上記 URL を参照すると、「GoFによって提唱された*Javaの*デザインパターンは」という箇所がありますが、これは出版社の方の勇み足のようです。:-)
どうも管理人です。
情報提供ありがとうございます。→ みんぺいさん

復刊.comの仕組み面白いですね。私も早速、一票入れておきました。

細谷さんの名前は以前、情報処理学会誌の記事でも見た事があります。確か、GoF のパターン本の翻訳メンバーの一人だったでしょうか。あの本の改訂版には確かパターンの Java のサンプルコードのCD-ROM が入っていましたが、細谷さんもコード作成を行ったていたんじゃなかったかな。

なにはともあれ、一度手にとって読んでみようと思います。
ハムレットさん:

そうですね。
細谷さんは、日本語改訂版で Java のサンプルコードを作成されていますね。GoF の一人、Ralph Johnson から直接薫陶を受けてもいます。

ところで、また別件です。
生産性の高い組織はどうなっているのかについて興味のある方には格好の題材があります。

じつは、Organizational Patterns of Agile Software Development の著者の一人、Neil Harrison から、この書籍の紹介を頼まれました。

曰く:
Organizational Patterns 本は、なぜかアメリカとカナダでしか販売されていないらしいことに気がついた。日本でも興味を持っている人がいることは分かっているのに、痛恨事。ひょっとして、すでに発売されていることを知らない人もいるのではないか。そこで、日本でこの本を買いたいと思っている人がいるかどうか聞いてみてはくれまいか。なんとか日本に送れるようにしたいと思う、とのこと。

実際に amazon.co.jp で探してみると、なんと不思議なことに `organizational patterns' では検索に引っかからず、`james coplien' や `neil harrison' と著者名を入れると結果に出てきます。
というわけで、必ずしも日本で入手できないというわけではなさそうですが、見つけにくいのは確かなようです。
http://www.amazon.co.jp/exec/obidos/ASIN/0131467409/249-8681483-1534708

Organizational Patterns がどんなものかというと、一言で言ってしまえば、実際に成功している開発組織について、その構造や振る舞いをパターンとして抽出したものです。

以前 2001 年に、著者達が日本でこの Organizational Patterns をテーマにセミナーを開いたことがありますが、これを私が所属組織向けにレポートしたときには非常に高い関心を集め、平常時をずっと上回る閲覧がありました。
今回書籍としてまとめられている Organizational Patterns は、当時のものよりもさらに磨きがかかっているはずです。

なお amazon.com の書評では、現在のところ 9 人の評者が 9 人とも最高点をつけています。
http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/102-3164799-8874518

書籍としてまとまった形で入手できるようになっていますので、プロジェクトや組織のあり方について関心のある方は、ぜひ手に取ってみてください。

なお first author の James Coplien は、「C++ プログラミングの筋と定石」の著作がある C++ の手だれで、PLoPD (Pattern Languages of Program Design) シリーズのエディタを務めるなど、ソフトウェアパターンのコミュニティでも指導的な役割を果たしてきた人です。「マルチパラダイムデザイン」も彼の手によるもので、commonality / variability 分析などの優れた提案を行なっています。

今回依頼のメールをくれた second author の Neil Harrison も、PLoPD シリーズのエディタとして活躍しているだけでなく、パターンを書く人・コメントを与える人のための `The Language of Sphepherds' といったパターンを書くなど、パターンについて極めて造詣が深い人です。

宣伝めいた話を続けて恐縮ですが、ご参考まで。
こんばんわ、管理人です。

みんぺいさん>じつは、Organizational Patterns of Agile Software Development の著者の一人、Neil Harrison から、この書籍の紹介を頼まれました。・・・・宣伝めいた話を続けて恐縮ですが、ご参考まで。

( v^-゚)Thanks for good introduction ♪ こう言うの大歓迎です。今後ともよろしくお願いします。

面白いですね。 Organizational Patterns ですか。日本だと経営学の分野に分類されてしまうのかな。この辺の発想はアメリカなんかの方が得意なのかもしれないですね。
例えばカーネギーメロンで開発された CMM(capability maturity model) も要は恒常的に品質の高いソフトウェアを生産できる組織とはという命題から出来たモデルですしね。そこから最適なプロセスのあり方と。それを実現するための組織の能力の標準仕様、判定基準、CMMレベル言う風に展開していったと思います。しかしながら組織レベルでのアセスメントとレベルの認定という形態が故に、変に誤解され、レベルを取る事が目的にされたり、「開発プロセスを硬直化させて、かえって生産性を落とすし弊害の方が多い」と(特に Agileな方々から)目の敵にされたりと必ずしも正しく理解されているとは思いません。(CMM って開発プロセスの組織論的なメタモデルですよね。だから分かりにくいのかもしれませんが)

そうした流れで考えると、示されたパターンからその中から自組織のあり方にマッチした物を選ぶと言うのは、分かり易いし取っ付き易いかも知れないですね。組織の規模にあまり依存しないですし。(of Agile Software Development ってのがミソなのかな?)やはりパターンで示すとより具体的に成るからでしょうか。ただ個人的には CMMI 等と組み合わせて使うとかなり強力なプロセス並びに組織の改善手法に繋がると思うのですが、ちょっと飛躍しすぎでしょうか。

何はともあれ、購読書リストの中に入れておくことにします。ご紹介ありがとうございました。
ほしいのはドキュメントパターン(IEEEフォーマットじゃなくて)。
開発手法とか開発対象となるシステムによって、インとアウトを明確に記述して、何が足りないと何が不明になるかを定義できるやつ。
で、つくれない時は、コレコレの事項が不明になるよ、とわかればいいのですが。

ドキュメントに対する戦略をある程度定めたいのです。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

ソフトウェア工学 更新情報

ソフトウェア工学のメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。

人気コミュニティランキング