名前 | 名前。設計者同士の会話で容易に使えるものを採用した。 |
アイコン | 設計者の多くは図を使ってやり取りするため、ビジュアル言語も用意した。この言語が、パターンを組み立ててより大きなパターンとして使えることを示している。 |
文脈 | どんな種類の仕事がこの(パターンが解決する)問題を引き起こしがちか。 |
問題 | 直面している困難を質問形式で記載。ここを読むと、このパターンが自分に関係するか判断できる。 |
フォース | 問題の解決を難しくしている制約を掘り下げる。うまくいきそうでうまくいかない解決策を示すこともある。 |
解決策 | 問題を解決するためにはどうすべきか。読者固有の状況に限定されたものではなく、「問題」で示した状況への対応が記される。問題と解決策を理解すれば、パターンを理解したことになる。「問題」と同じ形式で記載。 |
スケッチ | 解決策を図示したもの。Alexander形式でもっとも魅力的な要素の一つ。 |
結論 | 解決策の適用方法や、どのようにフォースを解決するかを詳細に示す。パターン適用によって新たに起こる問題を解決する(示す方?)こともある。 |
関連 | このパターン適用後に考慮すべき他のパターンの一覧。単なるパターンカタログではなく、パターン言語の性質を示す項目。 |
サイドバー | 技術的な問題やパターンの派生系について詳細に議論する。 |
例 | 著名な用途のな前であったり、コードサンプルであったり。メッセージング技術は数多くあり、例に使われている技術を知っているとは限らないため、とばしても問題ないようにしている。 |