Knowledge Level (p465) †
Knowledge Levelとは他のオブジェクトのグループが
どのように振舞うべきかを述べるオブジェクトの
グループである[Martin Fowler "Account ability,"]
要約 †
KNOWLEDGE LEVEL（知識レベル）
P465
- 知識レベルは、モデルの一部をユーザーが変更できるようにしたいが、多くのルールセットによる制約も必要な状況をうまく解決する。知識レベルは、ソフトウェアの振る舞い（具体的には、ENTITIES間の役割や関連）の、インストール時や実行時の変更可能性を重視している。
- 書籍「アナリシスパターン」で知識レベルは独自の章を持たないが、これは他のパターンがドメインのモデリングである一方、知識レベルはモデル自体に構造をあたえるものだからだ。
- 具体的に「アカウンタビリティ（責任関係）」を見てみると、人や組織の定義やその間の役割・関係は組織によって大きく異なることがわかる。
- ある企業では、部門はディレクターに率いられていて、ディレクターはバイス・プレジデントに報告する
- 他の企業では、モジュールがマネジャに率いられており、マネージャはシニアマネジャに報告する
- マトリックス型組織を取る場合もある
- ソフトウェアによる仮定が正しくなければ、ユーザーは違った使い方をはじめ、自らの作業の結果とソフトウェアの作業結果のマッピングが必要になってしまう。
P466
- システム変更やリプレース時に、開発者はこのような状況に気づくが、彼らの編み出した使い方を壊さないようにシステムを修正するのは非常につらい仕事になる。
例：従業員の給与支払いと年金（その1） †
- 従業員、給与支払いの種別、年金の種別の関係は以下のようになっていた（図16.15/16）。
- 非正規社員（Hourly Employee）は確定拠出年金が適用される
- 正社員（Salaried Employee）は確定給付年金が適用される
P467
- マネージメントはオフィス管理者は確定給付年金にすることを決めたが、オフィス管理者は非正規社員であり、今までのモデルでは対応できなくなったため、モデルを変更した（図16.17/18）。
P468
- これは従来のモデルの制約を単に緩めたものだが、企業のポリシーを反映していないため却下された。以下の定義が正確にモデル化されることが求められた。
- オフィス管理者は、非正規社員であり、確定拠出年金制度が適用される。
- このポリシーは、「ジョブタイトル」が重要なドメイン概念であることを示唆している。開発者はこのコンセプトを「従業員タイプ」として抽出した（図16.19/20）。
- 要件は、ユビキタス言語で以下のように記すことができる。
- 従業員タイプは、任意の「退職プラン」や「給与支払い」に割り当てることができる。
- 従業員は、従業員タイプによる制約を受ける。
P469
- 従業員タイプオブジェクトの編集は、スーパーユーザーに制限されており、スーパーユーザーは企業ポリシーが変更された場合のみに変更を行う。一般ユーザーは、従業員オブジェクト自体か、従業員タイプへの関連付けのみ変更できる。
- 静的なモデルは問題を引き起こすことがあるが、どのような関連も許すような完全にフレキシブルなシステムもまた問題であり、このようなシステムは使いづらかったり、必要なポリシーを適用できなかったりする。
- 個々の組織形態に沿ってソフトウェアを完全にカスタマイズするのは現実的ではない。コスト上問題がなくても、個々の組織ですらその構造を頻繁に変えるからだ。
- よってソフトウェアは、ユーザーによる組織構造の変更（現在の組織構造の反映）を許すような選択肢を提供する必要があるが、扱いづらくなりがちなのが問題だ。
問題サマリ
- 状況が異なるとENTITIES間の役割や関連が変わるようなアプリケーションにおいては、複雑さの爆発が起きうる。完全に一般的なモデルも高度にカスタマイズされたモデルのいずれも、ユーザーの要求を満たさない。オブジェクトは様々な状況に対応するために異なるタイプへの参照を持つことになり、異なる状況で異なる使い方をされるような属性を持つことになってしまう。異なる組み立てルールに対応するためだけに、同じデータや振る舞いを持つクラスが数多く生まれてしまうかもしれない。
- うまくフィットするのは、自分たちのモデル自身に関するモデルだ。知識レベルはモデルの自己記述的な側面を分離し、モデルに関する制約を明示する。
- 知識レベルは、ドメインレイヤに関するREFRECTIONパターンの適用だ。REFRECTIONパターンは、ソフトウェアを以下の2つに分離することで、変化への対応を達成する。
- 操作に関する責務を表す「基本レベル」
- ソフトウェア自身の構造や振る舞いに関する知識を表す「メタレベル」
P470
- Refrectionパターンは layeringに似ているが、知識"layer"にとは呼ばれていない。
（2つのレベルは相互に依存しあっている）
- Reflectionパターンはドメイン層にも適用する事ができる。
Knowledge LevelとREFLECTIONの比較
| Fowler | POSA |
| Knowledge Level | Meta Level（メタレベル） |
| Operations Level | Base Level(基本レベル） |
- ドメインモデルにおける知識レベルは普通のオブジェクトで作られなければならない。
- 知識レベルは次の2つ有益な特徴を提供してくれる。
Therefore:
- 基本的なモデルの構造と振る舞いを説明し、かつ制約を与える特徴的なオブジェクト郡を形成しなさい。
- オブジェクト郡の関心事を2つの"levels"に分け続けなさい
- １つは、ほぼ不変な部分
- もう一方は、柔軟に変更させる事が出来るルールと知識を反映している部分
解決方法サマリ
- 知識レベルは他の方法では扱いがとても難しい問題を解決してくれる。
- REFLECTION厨や、KNOWLEDGE LEVEL厨にならないように程ほどに使いなさい。（遠まわしな説明は不鮮明さを与えます。）
- KNOWLEDGE LEVELが複雑になってしまうと、システムの振る舞いは理解しづらいものにあんってしまうでしょう。
- 知識レベルを導入したからといってデータ移行の基本的な問題が消え去るわけではありません。知識レベルが変っても、古い操作レベルと新しい操作レベルが共存する可能性があり、慎重な解析が必要となるでしょう。
結果、実装上の検討事項、サンプル
例：従業員の給与支払いと年金（その2：知識レベル） †
- 何故、あるオブジェクトは守られる一方で、他のオブジェクトは編集可能なのか？制約のあるオブジェクト郡が知識レベルの導入を思い立たせた。
- 日々の編集は操作レベルであるが、編集に対する制約は知識レベルであった。
- 「従業員タイプ」は「従業員」に振る舞い与えていた
- 2つの特徴的な概念(「退職プラン」と「給与支払い」）が、同じオブジェクト（「従業員タイプ」）によって結合された。
- 「給与支払い」は当初の、モデルには存在しない概念（将来へのassumption）だったが、「従業員タイプ」によって明確にモデルにする事ができるようになった。（Figure16.22）
- 知識レベルは、他のlarge-scale structuresのように、必ず必要なものではない。
＊＊＊
- 一見、知識レベルはResponsibility Layersの特殊なケース（特にpolicy layerに関して）に見えるが、そうではない。
- 依存性はLayersを伴ったLevel間で生じるが、下位層は上位層から独立している。
- 実際、知識レベルは補足的な次元の組織化を提供しながら、殆どのlarge-scale structuresと共存することが出来る。
担当者のつぶやき †
とりあえず、前半終わらせました。m(__)m
- ↑お疲れ様です。（以下、池田）
- 前回の反省から出来るだけ1段落1行で頑張ってみた(笑）
- p474 LevelとLayerの違いとは？
みんなの突っ込み †
- アナパタよりも説明がわかりやすい件 -- 渡邉?
- アナパタより説明が分かりやすいのは，アナパタの知識レベルと同じものではないからでは．アナパタの知識レベルに出てくる〜タイプ (〜型) は Odell のパワータイプで，実装することが困難 (Java では不可能) なので特に分かりにくいのだと思われます．一方，ここで出てくる従業員タイプはパワータイプではありません． -- koichik?
- 主題と関係ないんですが、Hourly Employeeも、残業代がでる正規社員じゃないんですかね？（非正規用の企業年金って存在するのかな？）Salaried Employeeは年俸制（又は裁量労働制）の正規社員とか？。
http://biztaxlaw.about.com/od/glossaryh/a/hourlyemployee.htm -- 池田?
- なるほどー。arkで検索してみると、そのまんま「時間給従業員、時間給労働者」になってました。明日までにはこれに書き直しときます。 -- 渡邉?
