問題フレームアプローチ

問題分析、あるいは問題フレームアプローチは、ソフトウェア要件分析のアプローチの一つです。 1990年代にイギリスのソフトウェアコンサルタント、マイケル・A・ジャクソンによって開発されました。

歴史

問題フレームアプローチは、ジャクソンが著書『ソフトウェア要件と仕様』（1995年）およびソフトウェア工学に関する様々な学術誌に掲載された多数の論文で初めて概説しました。最も詳細な解説は、彼の著書『問題フレーム：ソフトウェア開発問題の分析と構造化』（2001年）でなされています。

問題フレームに関するセッションは、2003年にオーストリアのクラーゲンフルト／フェルデンで開催された第9回国際要件工学ワークショップ（REFSQ）の一環として開催されました。 ^[1]問題フレームの応用と進歩に関する第1回国際ワークショップ^{[2]は、スコットランドのエディンバラで開催されたICSE'04の一環として開催されました。このワークショップの成果の一つとして、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）はそのサブカテゴリーの一つです。問題指向開発に関する第1回国際ワークショップは2009年6月に開催されました。

概要

基本理念

問題分析、あるいは問題フレームアプローチは、コンピュータソフトウェアの要件収集と仕様作成に用いられるアプローチ（概念の集合）です。その基本的な考え方は、他のソフトウェア要件定義手法とは大きく異なり、以下の点を主張しています。

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

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

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

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

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

特定の問題を記述するためのツール

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

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

問題のクラスを記述するためのツール（問題フレーム）

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

問題フレームでは、ドメインに一般的な名前が与えられ、重要な特性に基づいて説明されます。例えば、ドメインは、因果的（イベントに対して決定論的かつ予測可能な方法で反応する）または従順（イベントへの対応を指示または要求できるが、必ずしも予測可能かつ決定論的な方法でイベントに反応するとは限らない）に分類されます。（従順なドメインは通常、人間で構成されます。）

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

認識されている問題のクラスのリスト（問題フレーム）

ジャクソンが特定した問題フレームの最初のグループは次のとおりです。

必要な行動
命令された行動
情報表示
シンプルなワークピース
変換

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

問題の説明

問題の背景

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

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

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

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

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

コンテキストダイアグラム

問題分析者の第一の仕事は、問題を真に理解することです。つまり、問題が置かれている文脈を理解することです。つまり、コンテキストダイアグラムを描くということです。

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

あなたはエンジニアで、川に橋を架ける計画を立てています。そこで、現場を訪れます。川岸に立って、周囲の地形と川の流れを眺めます。この場所がいかに風にさらされているか、風がいかに強く吹いているか、川の流れがいかに速いかを実感します。川岸を見ながら、岩だらけの地形に地質調査を行えばどんな断層が見つかるだろうかと考えます。そして、これから建設する橋を思い描きます。（ソフトウェア要件と仕様：「問題のコンテキスト」）

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

コンテキスト図は、アプリケーションドメイン内の様々な問題領域、それらの接続、そしてマシンと（一部の）問題領域との関連を示します。コンテキスト図は次のようになります。

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

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

ドメインとは、私たちが関心を持つ世界の一部分です。ドメインは、個人、出来事、状況、関係、行動といった 現象から構成されます。

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

ドメインは、原始的な単細胞生物（アメーバなど）のようなものだと想像できます。アメーバは自身の一部を仮足へと伸ばすことができます。そのような生物2体が、まるで握手のように仮足を伸ばし合い、握手している部分の細胞物質が混ざり合い、両方の細胞に属するようになる様子を想像してみてください。これがインターフェースです。

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

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

問題図

問題分析者が問題を記述するための基本的なツールは、問題図です。ここに一般的な問題図を示します。

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

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

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

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

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

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

問題のクラスの説明

問題フレーム

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

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

バリアントフレーム

ジャクソンは『問題フレーム』の中で、自身が特定した5つの基本的な問題フレームのバリエーションについて論じました。バリエーションは典型的には、問題の文脈にドメインを追加します。

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

問題の懸念

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

特別な懸念

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

構成に関する懸念

共通説明
一貫性
優先順位
干渉
同期

認識された問題フレーム

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

必要な行動
命令された行動
情報表示
シンプルなワークピース
変換

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