IDEF3

IDEF3または統合プロセス定義記述キャプチャ法は、 IDEF0を補完するビジネスプロセスモデリング手法です。^[1] IDEF3法は、特定のシステムの動作方法に関する知識をキャプチャすることを目的としたシナリオ駆動型のプロセスフロー記述キャプチャ手法です。^[2]

IDEF3法は、両方を表現するモードを提供する^[2]

• プロセスフローの説明は、特定のシナリオのコンテキスト内でのアクション間の関係を捉え、
• 許容される状態と条件の説明をキャプチャするためのオブジェクト状態遷移。

この方法は、システムおよびソフトウェア エンジニアリングの分野におけるモデリング言語のIDEFファミリーの一部です。

世界を記述するために使用される主要なメカニズムの 1 つは、順序付けられた一連のイベントまたはアクティビティの観点からストーリーを関連付けることです。IDEF3 プロセス記述キャプチャ メソッドは、状況またはプロセスを記述するための一般的なメカニズムであると考えられる一連のアクティビティの記述をキャプチャするために作成されました。IDEF3 の主な目的は、ドメイン エキスパートが特定のシステムまたは組織の運用に関する知識を表現できる構造化された方法を提供することです。知識の獲得は、現実世界のプロセスとイベントに関するアサーションを、キャプチャに最も自然な形式で直接キャプチャすることによって可能になります。IDEF3 は、プロセス知識獲得のための信頼性が高く構造化されたアプローチと、情報のキャプチャと表現のための表現力豊かで使いやすい言語を提供することで、この種の知識獲得をサポートします。^[1]

IDEF3の開発の動機は次のような必要性であった: ^[1]

• ビジネスシステムモデリングのプロセスをスピードアップするため、
• このデータライフサイクル情報を記述するメカニズムを提供するため、
• 自動化ツールによるプロジェクト管理手法のサポート
• システム要件記述書を作成するための概念、構文、手順を提供し、
• IDEFメソッド ファミリへの補完的な追加として、独立して、また異なる集中領域に対処する他のメソッド ( IDEF0機能モデリング メソッドなど) と連携して、うまく機能します。

オリジナルのIDEFは、既存のシステムをどのように統合するかを決定する必要のある人々のコミュニケーションを強化する目的で、1970年代半ばから開発されました。IDEF0は、機能分解のプロセスと機能間の関係の分類（つまり、入力、出力、制御、メカニズムの分類）を通じて、システムの機能の記述をスムーズに拡張できるように設計されました。IDEF1は、組織が目的を達成するために管理することが重要であると考える情報の記述を可能にするように設計されました。^[2]

3 番目のIDEF ( IDEF2 ) は、もともとユーザー インターフェイスのモデリング手法として意図されていました。しかし、統合コンピュータ支援製造(ICAM) プログラムにはシミュレーション モデリング ツールが必要だったため、結果として生まれた IDEF2 は、製造システム内のリソースの時間変動動作を表現する手法であり、数学モデルに基づくシミュレーションの仕様のフレームワークを提供しました。この状況を修正することがICAM内の方法論プログラムの意図でしたが、資金の制限により実現できませんでした。その結果、システムのユーザー ビューの説明の構造化をサポートする手法が欠如していることが、IDEF システムの大きな欠点となっています。方法論の観点から見た基本的な問題は、システム (既存または提案) が行うことになっていることの説明と、システムが行うことを予測する代表的なシミュレーション モデルを区別する必要があることです。後者はIDEF2の焦点であり、前者は IDEF3 の焦点です。^[2]

記述とモデルの区別は微妙ではあるが、IDEF3では重要なものであり、どちらも正確な技術的意味を持っている。^[1]

• 「記述」という用語は、経験的観察の記録を意味する予約技術用語として使用されます。つまり、記述は観察や経験に由来する、または観察や経験に基づいた知識を記録します。
• モデルという用語は、実体または事態の理想化を意味します。つまり、モデルは、特定の関連する点において、特定の現実世界のシステムの特性を模倣するように設計された、オブジェクト、プロパティ、および関係の理想化されたシステムです。摩擦のない平面、完全に剛体、質点の仮定などが、モデルの代表的な例です。

モデルの威力は、それが表す現実世界のシステムを単純化し、モデル内の対応する事実に基づいてそのシステムに関する特定の事実を予測する能力から生まれます。したがって、モデルはそれ自体が設計されたシステムです。モデルは、不正確であることがわかっているものの、ドメイン内の事前定義された関心領域に対して信頼できる予測子を提供するのに十分近いと想定される理想化されたシステムです。一方、説明は、個人の知識または経験の範囲内の事実または信念の記録です。このような説明は一般に不完全です。つまり、説明を行う人は、無関係であると考える事実や、システムを説明する過程で忘れられた事実を省略する場合があります。説明は、ドメイン内の状況を他の人がどのように観察したかに関して一貫性がない場合もあります。IDEF3 は、同じシナリオまたはプロセスの代替説明をキャプチャして整理できる特定の機能を提供することで、これらの可能性に対応しています (図を参照)。^[1]

モデリングでは、矛盾した視点や矛盾した視点を解決するために、記述のキャプチャを超えた追加の手順を実行する必要があります。これにより、通常、モデラーは単一の視点を選択または作成し、直接的な知識や経験が利用できないギャップを埋めるために人工的なモデリング近似を導入する必要があります。モデルとは異なり、記述は、単純な精度を除いて、満たさなければならない理想化されたテスト可能な条件によって制約されません。^[1]

記述キャプチャの目的は、単にプロセス知識を記録して伝達すること、または主要なプロセスが実際にどのように機能するかを人々が理解する方法の矛盾を特定することである可能性があります。記述キャプチャ方法を使用すると、ユーザーは実行可能なモデルを作成するために強制される規則（正確性、内部一貫性、論理的一貫性、非冗長性、完全性を保証する規則など）を学習して適用する必要がありません。ユーザーにモデル化を強制すると、モデル設計の観点を採用する必要があり、ドメインの経験的知識を正確にキャプチャしないモデルを作成するリスクがあります。^[1]

シナリオまたはストーリーの概念は、IDEF3 プロセス記述の基本的な構成構造として使用されます。シナリオは、組織またはシステムが対処する典型的な問題の種類を説明する一連の状況、またはプロセスが発生する設定として考えることができます。シナリオは、記述の焦点と境界条件を確立します。このようにシナリオを使用すると、特定のシナリオまたは状況のコンテキスト内で、順序付けられた一連のアクティビティの観点から自分が知っていることを説明するという人間の傾向を活用できます。シナリオは、プロセス中心の知識のコレクションを整理するための便利な手段も提供します。^[1]

IDEF3 プロセス スキーマは、プロセス中心の知識を収集、管理、表示するための主要な手段です。これらのスキーマは、さまざまなアプリケーション領域のドメイン エキスパートとアナリストがプロセスに関する知識を伝達するのに役立つグラフィカル メディアを提供します。これには、イベントとアクティビティ、それらの発生に参加するオブジェクト、および発生の動作を制御する制約関係に関する知識が含まれます。^[1]

IDEF3オブジェクトスキーマは、プロセスのオブジェクト中心の記述、つまり、さまざまな種類のオブジェクトがプロセスを通じて他の種類のものにどのように変換されるか、特定の種類のオブジェクトがプロセスを通じてどのように状態を変えるか、またはプロセス内のオブジェクト間の重要な関係に関するコンテキスト設定情報に関する情報をキャプチャ、管理、および表示します。^[1]

IDEF3の記述は、プロセス中心とオブジェクト中心という2つの異なる観点から開発されています。これらのアプローチは相互に排他的ではないため、IDEF3では複雑なプロセス記述を表現するためにそれらの間の相互参照が可能です。^[1]

プロセス図は、IDEF3 メソッドの最もよく知られ、広く使用されているコンポーネントです。これらの図は、シナリオのプロセス中心の説明を視覚化するメカニズムを提供します。プロセス図を構成するグラフィカル要素には、動作単位 (UOB) ボックス、優先リンク、ジャンクション、参照先、メモなどがあります。ここでの構成要素は次のとおりです。^[1]

• 行動単位（UOB）ボックス
• リンク: リンクは、UOB ボックスを接続して動的プロセスの表現を形成する接着剤です。
• 単純な優先順位リンク: 優先順位リンクは、1 つの UOB のインスタンスと別の UOB のインスタンスの間の時間的な優先順位関係を表します。
• アクティベーション プロット: アクティベーション プロットはアクティベーションを表すために使用されます。
• 破線リンク: 破線リンクには事前定義されたセマンティクスはありません。
• リンク番号: すべてのリンクには詳細と固有のリンク番号があります。
• 非分岐プロセス スキーマのアクティベーション セマンティクス。
• ジャンクション: IDEF3 のジャンクションは、プロセス分岐のロジックを指定するためのメカニズムを提供します。
• UOB 分解: 詳細化により、プロセスに関する詳細な知識が取得され、構造化されます。
• UOB 参照番号付けスキーム: IDEF3 プロセス記述内の各 UOB ボックスに UOB ボックス番号が割り当てられます。
• 部分的な説明: UOB ボックスはリンクによって結合されます。説明のキャプチャが IDEF3 の焦点であるため、IDEF3 回路図の他の部分へのリンクがない UOB を想定することも可能です。
• 参照対象: 参照対象は、プロセス図とオブジェクト図の両方の理解を深め、追加の意味を提供し、構成を簡素化 (つまり、乱雑さを最小限に抑える) します。

IDEFは、オブジェクト中心の詳細なプロセス情報を表現するための一連の構成要素を提供します。つまり、さまざまな種類のオブジェクトがプロセスを通じて他の種類のものにどのように変換されるか、または特定の種類のオブジェクトがプロセスを通じてどのように状態を変えるかに関する情報です。^[1]

• オブジェクト: シャーシなどの特定の種類のオブジェクトは、適切なラベルが付いた円で単純に表されます。
• オブジェクトの状態: 特定の状態にある特定の種類のオブジェクトは、その種類自体と対応する状態を表すラベルが付いた円で表され、それによってその状態にあるオブジェクトのタイプまたはクラスを表します。
• オブジェクト スキーマ: 種類シンボルとオブジェクト状態シンボルから構築された複雑な表現の構築。
• 遷移図: 最初の最も基本的な構成は、基本状態遷移図、または単に遷移図です。

• IDEF
• オントロジー
• オントロジー（コンピュータサイエンス）

• Costin Badic と Chris Fox (2004)。「ビジネス プロセスのハイブリッド IDEF0/IDEF3 モデリング: 構文、セマンティクス、表現力」
• Mounira Harzallah (2007)。「IDEF3 を統合エンタープライズ モデリング言語に組み込む」。2007年第 11 回国際 IEEE EDOC 会議ワークショップの議事録。pp 133～140。
• CH Kim 他 (2001)。「ビジネス プロセス モデリングをサポートする IDEF0、IDEF3、およびペトリ ネット メソッドの統合使用」。機械技術者協会の議事録。パート E、プロセス機械工学ジャーナル。第 215 巻、第 4 号、317 ～ 329 ページ。
• Jeong KY 他 (2008)。「ビジネス プロセス分析のためのキューイング ネットワークと IDEF3 の統合」。Business Process Management Journal、第 14 巻、第 4 号、471 ～ 482 ページ。
• L. Whitman および B. Huff (1997)。「構造化モデルと動的システム分析: IDEF0/IDEF3 モデリング手法と離散イベント シミュレーションの統合」。シミュレーション カンファレンス、1997 年、1997 年冬季会議の議事録。1997 年 12 月 7 ～ 10 日、pp. 518 ～ 524。

Wikimedia Commons には、IDEF3に関連するメディアがあります。

• IDEF3 の概要 2010-04-25にWayback Machineでアーカイブされました(www.idef.com)