パターン周辺メモ

気になって読んだ本の気になった部分の間引きされた引用と自分の解釈のごっちゃメモです．自分用です．すんません．ちなみに句読点が，．になっているころの僕は論文書きが切羽詰っている時です．．．．．．．

パターン体系とは何か?(p354あたり)

　パターン体系とは，その構成要素であるパターンを互いに結びつけるものである．パターン体系では、この「結びつける」のやり方にパターン群を効果的にソフトウェア開発に利用するための工夫がなされているといえる．この工夫に対するメタファとして，パターンの元祖Alexandar自身は「体系(System)」ではなく「ランゲージ(Langage)」という言葉を選んだらしい．本にはAlexandarの原文が引用されているが，それを読んで俺なりに解釈した彼の意図は，

パターンランゲージは、パターンを要素(＝パターンは単語)とした構造化された何かであり，その構造化にはルール(≒文法，要するに構文規則)がある．そして，そのルールに従った構造化がなされるとソフトウェア開発に役に立つ(≒意味を持つ，要するにセマンティクスに従った解釈が可能となる)．つまり，パターン体系は，「パターンをノードとして，意味ありげなラベル付きエッジでそれらを接続した有向グラフ」以上のものでなければならない．

ということであろう．
　ただ，この本で書かれているソフトウェア・アーキテクチャに関する知識体系をAlexandarのメタファでいう「パターンランゲージ」だとするにはオコガマシイナアと筆者は感じているらしい．そこで、やっぱりパターン体系という概念を定義して，その「パターン体系」ぐらいは目指したいよねと言っている．その「パターン体系」とは以下のとおり．

定義： ソフトウェアアーキテクチャのためのパターン体系は，ソフトウェアアーキテクチャのためのパターンのコレクションであり，その実装のためのガイドラインやソフトウェア開発における実際の利用や組み合わせのためのガイドラインを含んでいる

確かに体系と呼ぶにはずいぶん控えめだ．また、「ToBeとしてのパターン体系のあるべき特性は何」かも本書で記述されており，以下のとおりである

• パターン体系は，パターンすべてを提供する「根拠地」として十分なものでなければならない
• パターン体系は，すべてのパターンが統一された形式で記述されなければならない
• パターン体系は，パターンの間のさまざまな関係を明確にするものでなくてはならない
• パターン体系は，構成要素であるパターンを組織化しなければならない
• パターン体系は，ソフトウェアシステムの構築を支援しなければならない
• パターン体系は，パターン体系自身の進化を支援しなければならない

確かにこれを見ると本当はLangageとしたいだけど．．．という感じが見てとれるねえ．

パターンの分類スキーマ(p357)

これは今後の参考に引用．このあるべき論は，どちらかというと「本当に手放しで使われるためには」という点を強く意識しているものといえる.これはLangageとしたいんだけど．．とは対立している要求という気がしないでもない．

• 理解し使用するのに，単純で,容易でなければならない
• 少数の分類基準で構成されるべきである
• 分類基準はパターンが持つ自然な特性を反映したものであるべきである(’自然’というのは，公理的に決めました基準とか出なく，実存世界の内容から理解しうるという意味のようだ)
• 潜在的に適用可能な一連のパターンを知ることが出来るようなロードマップを提供すべきである(なんかWeb2.0っぽいというか，協調フィルタリング的というか，あまり唯一正解のパターンとそれしか見つからない検索手順を提供するというのはダメってことみたい)
• 既存の分類を再構成しないでも新しいパターンを統合できるようにスキーマはオープンでなければならない．(これはムズいと思う．これに対して「拡張可能なマークアップ言語であるXMLを使えばいい！」とか「RDFマンセー,RSSを見ろよ」とかいう小学生みたいな回答でなければ)

パターン選択のステップ(p362)

詳細はこの本を実際に読んでくれ．最初の３つの手順の順番が結構面白い．

1. 課題を定義
2. パターンカテゴリの選択
3. 課題カテゴリの選択
4. 課題の記述の比較
5. 利点と欠点の比較
6. バリエーションの選択
7. 代替可能な課題カテゴリの選択

パターンコミュニティの特徴(p405)

ここでいうパターンコミュニティとは具体的にはPLoPとEuroPLoPだが，それらには他のカンファレンスと以下のような差異があるそうな．これもすべては「使える物を作るには」という価値観から来ている感じ．

• 実用性に主眼を置く．つまり,別に最新のコンピュータサイエンスの成果を使っていることが偉いわけではない．
• オリジナリティはあえて無視する． ある開発における課題に直面し解決したオリジナルな人でなくても別にパターンのauthorになってよい．
• 匿名評価を行わない． パターンは．偉い匿名な人がレビューするものではなくみんなで育てるものであるということか
• プレゼンテーションでなくライターズワークショップ．つまり，インタラクティブな英語に嗜みがないとひどいことに．．．
• 注意深く編集作業を行う．カンファレンスは発表の場でなくパターンを議論で洗練させる場であると憂いことだと思う

どうも今は，Hillsideでの管理がメインのようだす．

ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系

↑すごいいいことたくさん書いてある．