risk = nil;

抽象問題領域は，抽象概念・抽象タスク・抽象アクタ・抽象対象・抽象要求・抽象ドメインプロパティから構成されると考えている．(p.74)

 冒頭にたくさんの抽象がついた言葉が並ぶ．この中で目新しいのは，タスクであろうか．KAOS手法の中で，タスクという用語は，余り使用されない．エージェント（アクタ）が機械ではなく，人間である場合，その操作をタスクと呼んでいる．

さて，ここでの議論を始める前に少し過去を振り返ることにする．

アナリシスパターン ¹

デザインパターンの議論が華やかなときに，ひっそり(?)と出版された．とても示唆に富んだ本だが，直接的なありがたさが見えづらかったせいか，話題になることは少なかった．

アナリシスパターン表現型例

これは，「測定」における知識としての「表現型 ²」と，その操作との関係である．最初に提示されているもっとも単純な形式である．これだけでは，不明である．

具体的な例を当てはめてみる（なお，多重度に関してはUML風の表記に変えている）．いま，表現型として，身長を考える．それは，誰か固有の「人」のものであり，量としては長さであり，測定は身長計で行う．これは，体重であろうが，CRP（C反応性蛋白）であろうが，同じである．設計におけるパターンと同様に，一つのメタな構造がある．それを分析において必要なものを探し出して，カタログ化したのが，アナリシスパターンである．

Catalysis ³

個人的には，情報系の書籍の中で，最も啓蒙された本である．言語化できなかったもやもやを，きちんと文節化してくれている．それでもなお，もやもやのまま書かれているところもたくさんあるが，それもまたこの本の良さである．出版されてずいぶんになるが，今でもその有効性を保っている．

Catalysis モデルフレームワーク

Catalysis では，モデルフレームワークという記述法がある．＜＞は，使用時には具体的なクラス名が入る．リソース割当問題を，整理すると上記のように書ける．それは，英会話教師のスケジュール管理でも，配管工のスケジュール管理でも同じになる．

KAOS

KAOSの場合，特別な表記法が用意されているわけではない．考え方のみである．

メタモデルとしてのゴールモデル要素と図書館システム要素との対応

ここでは，ゴールモデルにおけるメタレベルとシステムレベルの関係を示している．ゴールモデルは，この対象・ゴール・エージェント・操作の関係を持っている．図書館であれば，対象は本であり，ゴールは本の貸し出しであり，エージェントであるユーザが，貸出という操作を行うことを示している．

 さて，今回の主題は，問題領域依存の知識表現と再利用である．ここまでは，Analysis Pattern は，測定というシンプルな例を用いた．問題領域よりのものも多く，カタログには，貿易やデリバティブ取引というのもある．Catalysisは，カタログこそ持っていないが，特定の問題領域の知識を，モデルフレームワークとして表現できる．

さて，KAOSは？先の例は，ゴールモデルの構造に当てはめているだけなので，問題領域に依存した知識とはいえない．

Lamsweerdeさんは，基本的にはテキストの人だと思う．KAOSというと，ゴールモデルを初めとする図式に注目することになるが，KAOSの魅力はテキストの操作にあるからだ．

ここでは，次のような例が示される．

いま，データ管理という範囲の広い問題領域があって，そこには次の記述がある．

管理下にあるデータベースは，関連するシステム外部の状態を正確に反映しなくてはならない．

図書館管理において，以下の置き換えを考える．

「管理下にあるデータベース」→ 「図書館データベース」

「関連するシステム外部（the corresponding environment data）」→「書庫」

図書館管理というより狭い問題領域への置き換えである．そうすると，次の要求が必要であることが分かる．

図書館データベースは，書庫の状態を正確に反映しなくてはならない．

テキストの人というのが分かってもらえると思う．

（nil）