Analysis Patterns 2 - Work in Progress
- Temporal Patterns
- Quantityand Range
- Accounting patterns: a (considerable) update of the material in the Analysis Patterns book.
- Accountability narrative and patterns
しばらくの間、私はずっとアナリシスパターンの仕事をしていた。現在のところ、アナリシスパターンの第２版の予定はなかったが、仕事でパターンを書くよりもむしろ本を書くほうが重要だと思った。これは、オリジナルのアナリシスパターン本からの題材だけでなく、新しいものも含んでいる。現在私が考えていることは、ある時点での、新しいアナリシスパターン本を製作するつもりだが、それは第１版のほんの一部分の置き換えで、厳密にはまだ決めていない。
やっとアナリシスパターンの題材として、追いついてきた。やっと使うための情報が出そろった。それらのフィードバックを得たいと考えている。私は、パターンを使う方々の経験にとても興味がある。あなたはパターンを使った事がありますか？それらは使いやすいですか？おもしろいバリエーションのパターンに出くわしたことがありますか？どうか教えてください、私はこのサイトの題材にコメントをフィードバックして行こう思っている。
はるかなるパターン
私が作った利用可能な最初のパターンのセットはaccountability patternsで、 アナリシスパターンの２章から、私が今使っている新しい形へと、本質的に改訂する。 これらのパターンは、２つのpdfファイル： narrative and a collection of patternsになっている。私はpdfファイルを使うことをやめ、これから作られるパターンにはhtmlを使うつもりだ。-しかし多分自然なフォーマットに変えてゆくにはしばらく時間がかかるだろう。
Quantity と Rangeの２つは、小さいがとても共通的なパターンである。これらは小さく、基本的なパターンで、かなり広い範囲で使われる。もしあなたがOOシステムを書くならばそれらのパターンは、ツールキットのうちの一部に常に表れているだろう。
ひとつの型またはそれ以外の型のAccountingは、私の生涯で決して終わらないテーマだと思われる。 アナリシスパターンでは、accounting パターンの章がある。その後さらにアイデアが出てきた。それがaccounting pdf ファイルである。 出だしには、いくつかのパターンが出てくる。 それ以外のパターンとしては、パターンの概要を先に読んでください。そうすれば、詳細まで深く掘り下げてパターンを使うことができるだろう。 それらは去年の私のアナリシスパターンチュートリアルの半日分だ。パターンの詳細はそこで話したものが反映されているだろう。私の最近のパターンのセットは、歴史的な情報のためのパターンの組のうちの一つだ。歴史を捕らえる事は、モデルに多くの複雑さを加えることであり、それらのパターンはその歴史的な問題点を解決することを助け、それらを分けて扱うことを可能にしている。同時にパターンは共通の実装技術を連想させる。
新しい形式
アナリシスパターンの発行以来私が実験していた、最も大きなもののうちの1つは、パターンを表現する形式である。アナリシスパターンでは率直な物語だった。このことがリファレンスとしてパターンを使うのをより難しくしていると分かった。しかし、それと引き換えに、物語形式とすることで、中心にあるパターンの関係について容易に議論できるようになると思った。
さしあたりの解決策として、2つのセクションに分割して記述するようにして以来、物語形式とリファレンス形式での取り組みこそが私にとって共通のテーマだった。そのトレードオフについて議論する。より長いカタログ・セクションは、順番に各パターンの詳細についてとりあげる。この分離が、私に一石二鳥を可能にさせているだけではなく、さらに、読み手がパターンの存在やラフな意味を理解するために単なる物語を読むことを可能にしている。そのように、パターンが関係しているよい視点を得るために本を全部読む必要がなく、物語をちょっと読むこともできる。
カタログ項目は次の形式でパターンを詳述する。
- 名前
- 目的
- ダイアグラム
- どうそれは作動するか
- それを使用するべきとき:
- いくつかのコード・サンプルは例としての実装を示している。
パターンのためにこのフォーマットはかなり緩いだろう。しかし、私はパターンの主要なセクションが本質を表すことに期待する。
何人かの人はコード・サンプルの使用についてコメントした。これらのコメントは喜びから恐怖へと変わった。それらを使う主な理由はプログラマ(彼らは結局プログラムを理解する)とより意志が通じるからである。多くのプログラマは、図や本文の記述からパターンがどう働くか理解するのに苦労していた。サンプルをコード化することで、その概念をはっきりさせる。
忘れてはならない大事なことは、これらが例としての実装でしかないということである。誰も、そのまま使うことはできないだろう。それらは適用される問題に応じて適応させる必要があるだろう。 それらは、それ以上説明されない概念を補うために存在している。
さらに、コード・サンプルはパターンの理解にとって必要ではない。私の目標は、UMLダイアグラムを合理的に読むことができれば、コードによらずに、パターンを理解できることにある。もしコードを読みたくなければ、無視していいだろう。それでも、おそらくはパターンは意味をなしているはずだから。