risk = nil;

対象としている問題のフレームと合致するほかの問題が数多くある場合，それらの問題に使えた手法と技術が，いま解こうとしている問題に適用可能であることが期待できる．このことが開発手法の要点である ¹．

ここでは，図式を用いた記述についての説明である．ときに半形式的と呼ばれる場合もある．自由な自然言語での記述から制約を加えていくと，自然とこの図式を用いた表現になる．

最初が，システム全体を示す図の紹介である．

コンテキスト図

20年ほど前に注目を浴びていた構造化分析手法におけるデータフロー図（DFD）を知っている人には，懐かしい言葉だと思う．階層に従って，様々なDFDが書かれるが，最上位のDFD.0が，コンテキスト図に相当する．DFD.1 以降は，システム内部の詳細化である．いまだと，最初のユースケース図が相当するだろうか（ちなみにDFDについては，数回後に紹介がある）．

コンテキスト図は，システム（DFDでは，通常プロセスと呼ぶ）と，そのシステムとデータをやりとりするエンティティとの関係を示している．ここでのエンティティには人も含む．会議スケジュール管理システムにおけるコンテキスト図は，以下になる．

構造化分析におけるコンテキスト図

システムが何かということを説明する前に，そのシステムが関与するコンポーネントを示すことは，システム境界を示すことでもある．Aというエンティティが，システムと情報をやりとりしているのであれば，Aは，システムの一部ではない．システムとコンポーネントAの間には，境界があるということになる．

次に，以前にも紹介したM.Jacksonの問題フレームワーク分析（PFA）のコンテキスト図である．これは，（同じコンテキスト図という名前を使っていても）構造化分析の表現とは異なる．

問題フレームワークのコンテキスト図

上記のコンテキス図は，会議スケジュール管理システムのものである．システム全体が中心ではない．ここでのメタファでは「機械」と呼ばれるアクティブな実体（ここでは，スケジューラ）が中心に来る．

制約リポジトリも（日程・場所）の衝突解析器（各参加者のスケジュールの調整を行う）は，機械に協力するコンポーネントである．

構造化分析のデータフロー図では（その名の通り）データの流れを示すために，流れる向きを記載する．機械とその協力者であるコンポーネントとの間では，（この段階では）相互の協力関係(shared phenomena)として，向きを示さない．

このように，PFAのコンテキスト図では，システム境界は意識されない．

(nil)