問題フレームアプローチ

問題分析または問題フレーム アプローチは、ソフトウェア要件分析のアプローチです。これは、1990 年代に 英国のソフトウェア コンサルタントであるMichael A. Jacksonによって開発されました。

問題フレーム アプローチは、Jackson が著書「Software Requirements & Specifications 」(1995 年) およびソフトウェア エンジニアリングに関するさまざまなジャーナルの多数の記事で初めて概説しました。この問題は、Jackson の著書「Problem Frames: Analysing and Structuring Software Development Problems」 (2001 年) で最も詳細に説明されています。

問題フレームに関するセッションは、2003年にオーストリアのクラーゲンフルト/フェルデンで開催された第9回国際要件工学ワークショップ：ソフトウェア品質の基礎（REFSQ）の一部でした。 ^[1]問題フレームのアプリケーションと進歩に関する最初の国際ワークショップ^{[2]は、スコットランドのエジンバラで開催されたICSE'04の一環として開催されました。そのワークショップの成果の1つは、2005年に}International Journal of Information and Software Technologyで問題フレームに関する特別号として出版されたことです。

問題フレームの応用と進歩に関する第 2 回国際ワークショップ^[3]は、中国の上海で開催された ICSE 2006 の一環として開催されました。問題フレームの応用と進歩に関する第 3 回国際ワークショップ (IWAAPF) ^[4]は、ドイツのライプツィヒで開催された ICSE 2008 の一環として開催されました。2010 年に、IWAAPF ワークショップは、問題指向の応用と進歩に関する国際ワークショップ (IWAAPO) に置き換えられました。IWAAPO は、ワークショップの焦点を広げ、問題分析を重視するソフトウェア開発への代替的かつ補完的なアプローチを含めています。^[5] IWAAPO-2010 は、南アフリカのケープタウンで開催された ICSE 2010 の一環として開催されました。^[6]

現在、問題フレームアプローチに関する研究は多くの大学で行われており、最も有名なのは英国のオープン大学における「問題と解決構造の関係づけ」研究テーマの一環として行われている^{[7] [8]。}

問題フレーム アプローチのアイデアは、問題指向開発(POD) と問題指向エンジニアリング (POE) の概念に一般化されており、問題指向ソフトウェア エンジニアリング (POSE) はその特定のサブカテゴリです。問題指向開発に関する最初の国際ワークショップは、2009 年 6 月に開催されました。

問題分析または問題フレーム アプローチは、コンピュータ ソフトウェアの要件を収集し、仕様を作成するときに使用するアプローチ (一連の概念) です。その基本的な考え方は、次の点を主張する点で、他のソフトウェア要件方法とは大きく異なります。

• 要件分析に取り組む最良の方法は、ユーザー要件を階層的ではなく並列的に分解するプロセスです。^[9]
• ユーザー要件は、ソフトウェア システムやソフトウェア システムとのインターフェースではなく、現実世界 (アプリケーション ドメイン) における関係に関するものです。

解決策はコンピュータとそのソフトウェアの中にあり、問題は外の世界にあると認識する方がより役に立ちます。コンピュータは外の世界とつながっているため、これらの問題に対する解決策を提供できます。 ^[10]

教訓は明らかです。問題を研究し分析するには、問題の世界をある程度深く研究し分析することに集中しなければなりません。また、調査のためにコンピュータから少し離れて調査することもいとわない必要があります。... [コール転送の問題では...]そこに何があるのか​​ (人、オフィス、休日、オフィスの移動、責任の委譲)、そして[問題の世界で] システムにどのような効果を達成させたいか (A の番号への通話は A に届く必要があり、 [B が休暇中で、C が一時的に D のデスクで働いている場合]、 B または C の番号への通話は C に届く必要がある) を説明する必要があります。 ^[11]

これらはどれもコンピュータとのインターフェースには現れません。...それらはすべてそれよりも世界の奥深くにあります。 ^[12]

このアプローチでは、3 セットの概念ツールを使用します。

特定の問題を説明するために使用される概念には、 現象（イベントを含むさまざまな種類）、 問題のコンテキスト、 問題領域、 ソリューション領域（マシンとも呼ばれる）、 共有現象（ドメイン インターフェイスに存在）、 ドメイン要件（問題領域に存在）、および 仕様（問題領域とマシンのインターフェイスに存在）が含まれます。

問題を記述するためのグラフィカル ツールは、コンテキスト図と 問題図です。

問題フレーム アプローチには、問題のクラスを記述するための概念が含まれています。認識された問題のクラスは、問題フレーム(デザイン パターンにほぼ類似) と呼ばれます。

問題フレームでは、ドメインに一般的な名前が付けられ、重要な特性に基づいて説明されます。たとえば、ドメインは、因果的(イベントに対して決定論的かつ予測可能な方法で反応する) または従順(イベントに応答するように命令または要求できるが、イベントに対して予測可能かつ決定論的な方法で常に反応するとは期待できない) に分類できます。(従順なドメインは通常、人で構成されます。)

問題フレームを表すグラフィカル ツールは、フレーム ダイアグラムです。フレーム ダイアグラムは、いくつかの小さな違いを除けば、一般的には問題ダイアグラムに似ています。ドメインには、特定の名前ではなく一般的な名前が付けられ、ドメインを表す四角形には、ドメインの種類 (因果的または入札可能) を示す注釈が付けられます。

ジャクソンが特定した問題フレームの最初のグループには次のものが含まれます。

1. 必要な行動
2. 命令された行動
3. 情報表示
4. 単純なワークピース
5. 変換

その後、他の研究者が追加の問題フレームを説明または提案しました。

問題分析では、ソフトウェア アプリケーションを一種のソフトウェアマシンと見なします。ソフトウェア開発プロジェクトは、ソフトウェア マシンを作成し、それを問題のコンテキストに追加することで問題のコンテキストを変更し、特定の望ましい効果をもたらすことを目的としています。

特定の問題に関連して関心のある問題コンテキストの特定の部分、つまり問題のコンテキストを形成する問題コンテキストの特定の部分は、アプリケーション ドメインと呼ばれます。

ソフトウェア開発プロジェクトが終了し、ソフトウェア マシンが問題のコンテキストに挿入されると、問題のコンテキストにはアプリケーション ドメインとマシンの両方が含まれます。その時点で、状況は次のようになります。

問題のコンテキストには、マシンとアプリケーション ドメインが含まれます。マシン インターフェイスは、マシンとアプリケーション ドメインが出会って対話する場所です。

同じ状況を、別の種類の図、つまりコンテキスト図で次のように表すことができます。

問題分析者の最初の仕事は、問題を真に理解することです。つまり、問題が設定されているコンテキストを理解するということです。つまり、コンテキスト図を描くということです。

ジャクソンは、問題のコンテキスト、この場合は建設される橋のコンテキストを調べる方法について次のように説明しています。

あなたは、川に橋を架ける計画を立てているエンジニアです。そこで、現場を訪れます。川の片岸に立って、周囲の土地と川の交通を見ます。その場所がいかに危険にさらされているか、風がいかに強く吹いているか、川の流れがいかに速いかを感じます。川岸を見て、岩だらけの地形に地質調査でどのような断層が現れるだろうかと考えます。これから架ける橋を思い描きます。(ソフトウェア要件と仕様: 「問題のコンテキスト」)

ソフトウェア開発の問題を理解しようとするアナリストは、ブリッジ エンジニアと同じプロセスを経る必要があります。アナリストは、アプリケーション ドメイン内のさまざまな問題ドメインを調べることから始めます。これらのドメインは、計画されているマシンが適合するコンテキストを形成します。次に、アナリストはマシンがこのコンテキストにどのように適合するかを想像します。そして、マシンがインストールされた問題コンテキストのビジョンを示すコンテキスト ダイアグラムを作成します。

コンテキスト ダイアグラムには、アプリケーション ドメイン内のさまざまな問題領域、それらの接続、およびマシンと (一部の) 問題領域への接続が表示されます。コンテキスト ダイアグラムは次のようになります。

この図は次のことを示しています。

• 構築するマシン。暗い枠線は、マシンを表すボックスを識別するのに役立ちます。
• 問題に関連する問題領域。
• 実線はドメインインターフェース、つまりドメインが重複し、共通の現象を共有する領域を表します。

ドメインとは、私たちが関心を持つ世界の一部に過ぎません。ドメインは、個人、イベント、状況、関係、行動といった 現象から構成されます。

ドメイン インターフェイスは、ドメインが接続して通信する領域です。ドメイン インターフェイスはデータ フローやメッセージではありません。インターフェイスはドメインが部分的に重複する場所であり、インターフェイス内の現象は共有される現象であり、重複するドメインの両方に存在します。

ドメインは、原始的な単細胞生物 (アメーバなど) のようなものだと想像できます。ドメインは、自らの一部を擬足に伸ばすことができます。このような 2 つの生物が、一種の握手のように擬足を伸ばし、握手している部分の細胞物質が混ざり合って、両方の生物に属するようになることを想像してください。これがインターフェイスです。

次の図では、X はドメイン A と B 間のインターフェイスです。X に存在する個体または発生するイベントは、A と B の両方に存在または発生します。

共有された個体、状態、およびイベントは、それらを共有するドメインに対しては異なって見える場合があります。たとえば、コンピューターとキーボード間のインターフェイスを考えてみましょう。キーボード ドメインがイベント「キーボード オペレーターがスペースバーを押した」を検出すると、コンピューターは入力バッファーにバイト 16 進数 ("20") が表示されるのと同じイベントを検出します。

問題分析者が問題を説明するために使用する基本的なツールは、問題図です。以下は一般的な問題図です。

コンテキスト図に表示される内容に加えて、問題図には次の内容が表示されます。

• 点線の楕円は、問題領域で特定の効果をもたらすという要件を表します。
• 点線は要件参照を表します。要件内の問題領域内の現象への参照です。

問題領域をマシンに接続するインターフェースは仕様インターフェースと呼ばれ、仕様インターフェース内の現象は仕様現象と呼ばれます。要件アナリストの目標は、要件を満たすためにマシンがマシン インターフェースで示さなければならない動作の仕様を作成することです。

ここに、単純ではありますが、実際の問題図の例を示します。

この問題は、病院のコンピュータ システムの一部である可能性があります。病院では、患者は体温と血圧を検出して測定できるセンサーに接続されています。要件は、ナース ステーションのパネルに患者の状態に関する情報を表示できるマシンを構築することです。

要件の名前は「ディスプレイ ~ 患者の状態」です。チルダ (~) は、要件がパネル ディスプレイと患者の状態の関係または対応に関するものであることを示しています。矢印は、パネル ディスプレイ ドメインに接続された要件参照も要件制約であることを示しています。つまり、要件には、パネル ディスプレイが満たさなければならない何らかの規定が含まれています。つまり、要件は、パネル ディスプレイが患者の状態と一致し、正確に報告する情報を表示する必要があるということです。

問題フレームとは、認識可能な問題のクラスを記述したもので、その問題のクラスには既知の解決策があります。ある意味では、問題フレームは問題のパターンです。

各問題フレームには、独自のフレーム ダイアグラムがあります。フレーム ダイアグラムは、本質的には問題ダイアグラムに似ていますが、特定のドメインと要件を示す代わりに、ドメインの種類と要件の種類を示します。ドメインには、特定の名前ではなく一般的な名前が付けられ、ドメインを表す四角形には、ドメインの種類 (因果的または入札可能) を示す注釈が付けられます。

問題フレームでは、ジャクソンは、彼が特定した 5 つの基本的な問題フレームのバリエーションについて説明しました。バリエーションは通常、問題のコンテキストにドメインを追加します。

• 説明バリアントは説明語彙領域を導入する
• 演算子バリアントは演算子を導入する
• 接続バリアントは、マシンとそれがインターフェースする中央ドメインとの間に接続ドメインを導入する。
• 制御バリアントは新しいドメインを導入するものではなく、インターフェース現象の制御特性を変更するものである。

ジャクソン氏は、問題フレームを扱う際に生じる特定の種類の懸念についても論じています。

特別な懸念

• オーバーラン
• 初期化
• 信頼性
• アイデンティティ
• 完全

構成に関する懸念

• 同等の説明
• 一貫性
• 優先順位
• 干渉
• 同期

ジャクソンが最初に特定した問題フレームには次のものがありました。

1. 必要な行動
2. 命令された行動
3. 情報表示
4. 単純なワークピース
5. 変換

その後、他の研究者が追加の問題フレームを説明または提案しました。

この問題フレームの背後にある直感的な考え方は次のとおりです。

• 物理世界には、特定の条件を満たすように動作を制御する必要がある部分があります。問題は、その制御を実行するマシンを構築することです。

この問題フレームの背後にある直感的な考え方は次のとおりです。

• 物理世界には、オペレータが発行するコマンドに従って動作を制御する必要がある部分があります。問題は、オペレータのコマンドを受け入れ、それに応じて制御を実行するマシンを構築することです。

この問題フレームの背後にある直感的な考え方は次のとおりです。

• 物理世界には、その状態や動作に関する特定の情報が継続的に必要とされる部分があります。問題は、この情報を世界から取得し、必要な場所に、必要な形式で提示するマシンを構築することです。

この問題フレームの背後にある直感的な考え方は次のとおりです。

• ユーザーが、コンピューターで処理可能な特定のクラスのテキストやグラフィック オブジェクト、または同様の構造を作成および編集し、後でコピー、印刷、分析、またはその他の方法で使用できるようにするツールが必要です。問題は、このツールとして機能するマシンを構築することです。

この問題フレームの背後にある直感的な考え方は次のとおりです。

• コンピューターで読み取り可能な入力ファイルがいくつかあり、そのデータを変換して特定の必要な出力ファイルを生成する必要があります。出力データは特定の形式でなければならず、特定のルールに従って入力データから派生する必要があります。問題は、入力から必要な出力を生成するマシンを構築することです。

問題分析がソフトウェア開発プロセスに組み込まれると、ソフトウェア開発ライフサイクルは問題分析者から始まります。問題分析者は状況を調査し、次のことを行います。

• コンテキスト図を作成する
• 要件のリストを収集し、要件の楕円をコンテキスト図に追加して、壮大な「オールインワン」の問題図を作成します。(ただし、多くの場合、実際にオールインワンの問題図を作成することは非現実的または役に立たない場合があります。図を縦横に交差する要件参照が多すぎるため、あまり役に立ちません。)
• オールインワンの問題と問題図を、より単純な問題とより単純な問題図に分解します。これらの問題は、オールインワン図のサブセットではなく、投影です。
• 各問題が十分に単純になり、認識された問題フレームのインスタンスとして見ることができるようになるまで、問題を分解し続けます。各サブ問題の説明には、構築するマシンの仕様インターフェイスの説明が含まれます。

この時点で、問題分析 (問題の分解) は完了です。次のステップは、プロセスを逆にして、ソリューション構成のプロセスを通じて目的のソフトウェア システムを構築することです。

ソリューション構成プロセスはまだ十分に理解されておらず、依然として研究テーマとなっています。ソフトウェア要件と仕様のヒントから推測すると、ソフトウェア開発プロセスは開発者によって継続され、開発者は次のことを行うと考えられます。

• 複数のサブ問題のマシン仕様を、単一のオールインワン マシンの仕様に構成します。これは、顧客のすべての要件を満たすソフトウェア マシンの仕様です。これは簡単な作業ではありません。構成プロセスによって、解決する必要のある構成問題が発生する可能性が非常に高くなります。
• 従来のコード/テスト/デプロイのプロセスを経て、オールインワン マシンを実装します。

問題分析といくつかの点で似ているソフトウェア開発のアイデアは他にもいくつかあります。

• デザイン パターンの概念は、ジャクソンの問題フレームの概念に似ています。デザイン パターンは、要件の問題を認識して処理するのではなく、設計の問題 (多くの場合、C++ や Java などの特定のオブジェクト指向プログラミング言語の設計の問題) を認識して処理するために使用されるという点で異なります。さらに、デザイン パターンはソリューションをカバーするのに対し、問題フレームでは問題が表現されるという違いもあります。ただし、デザイン パターンは、実装されるプログラミング言語にネイティブではないセマンティックな結果も考慮する傾向があります。したがって、もう 1 つの違いは、問題フレームは問題のドメインのネイティブなメタ表記であるのに対し、デザイン パターンは言語実装者が残した技術的負債のカタログであるということです。
• アスペクト指向プログラミング(AOP) (アスペクト指向ソフトウェア開発(AOSD) とも呼ばれる) も同様に並列分解に関心があり、AOP 支持者が横断的関心事またはアスペクトと呼ぶものに対処します。AOP は、要件分析フェーズよりも設計およびコード生成フェーズに近い関心事に対処します。
• AOP は、ITU-T Z.151 ユーザー要件表記法 (URN) などの要件エンジニアリング表記法に移行しました。URN では、AOP はすべての意図的な要素に適用されます。AOP は、問題フレームをヒューリスティックとして使用する要件モデリングにも適用できます。問題フレーム思考で駆動され、側面がインターリーブされた URN モデルにより、アーキテクチャ戦術を要件モデルに組み込むことができます。
• Martin Fowler の著書「Analysis Patterns」は、パターンの探索という点では問題分析と非常によく似ています。しかし、新しい要件分析手法は提示されていません。また、問題分析にとって非常に重要な並列分解の概念は、Fowler の分析パターンには含まれていません。
• ジョン・G・ホール、ルシア・ラパノッティはジャクソンとともに、問題フレームの基礎を共有する問題指向ソフトウェアエンジニアリング（POSE）フレームワーク^[13]を開発しました。2005年以降、ホールとラパノッティはPOSEを問題指向エンジニアリング（POE）に拡張しました。これは、開発プロセスモデルと保証主導設計を含むエンジニアリング設計のフレームワークを提供し、^[14]多くの利害関係者を含み、ソフトウェアと教育提供などのさまざまなエンジニアリング分野を組み合わせたプロジェクトに拡張できる可能性があります。^[15]

• http://mcs.open.ac.uk/mj665/ はマイケル・A・ジャクソンのホームページです。
• http://www.jacksonworkbench.co.uk/stevefergspages/pfa/index.html には、問題フレームアプローチに関する論文や記事が掲載されています。