IDEF

IDEF は、当初はICAM Definitionの略称で、1999 年にIntegration Definitionに改名された、システムおよびソフトウェア エンジニアリングの分野におけるモデリング言語のファミリーです。機能モデリングからデータ、シミュレーション、オブジェクト指向分析と設計、知識獲得まで、幅広い用途をカバーしています。これらの定義言語は、米国空軍の資金提供を受けて開発され、現在でも米国空軍やその他の軍隊、米国国防総省 (DoD) 機関で最も一般的に使用されていますが、パブリック ドメインとなっています。

IDEF ファミリーの中で最も広く認識され、使用されているコンポーネントは、SADT に基づいて構築された機能モデリング言語である IDEF0 と、情報モデルとデータベース設計の問題に対処する IDEF1X です。

IDEFは、機能モデリングからデータ、シミュレーション、オブジェクト指向分析/設計、知識獲得まで、幅広い用途をカバーする モデリング言語のファミリーを指します。最終的に、IDEF メソッドは IDEF14 まで定義されました。

• IDEF0 : 機能モデリング^[1]
• IDEF1 : 情報モデリング^[2]
• IDEF1X :データモデリング^[3]
• IDEF2 : シミュレーションモデル設計
• IDEF3 :プロセス記述キャプチャ^[4]
• IDEF4 :オブジェクト指向設計^[5]
• IDEF5 :オントロジー記述キャプチャ^[6]
• IDEF6 :設計根拠の把握^[7]
• IDEF7: 情報システム監査
• IDEF8: ユーザーインターフェースモデリング
• IDEF9: ビジネス制約の発見
• IDEF10: 実装アーキテクチャモデリング
• IDEF11: 情報成果物モデリング
• IDEF12: 組織モデリング
• IDEF13: 3スキーママッピング設計
• IDEF14: ネットワーク設計

1995年には、IDEF0、IDEF1X、IDEF2、IDEF3、IDEF4のみが完成していました。^{[8]他のIDEF概念のいくつかは、予備的な設計がされていました。最後の取り組みのいくつかは、ビジネス制約の発見IDEF9、設計根拠の捕捉}IDEF6、人間システム、インタラクション設計IDEF8、ネットワーク設計IDEF14のための信頼性の高い方法を確立するための1995年の新しいIDEF開発でした。 ^[9]

IDEF7、IDEF10、IDEF11、IDEF12、IDEF13の手法は、当初の定義よりさらに発展させられていない。^[10]

IDEFはもともとICAM Definitionの略で、1970年代にオハイオ州ライトパターソン空軍基地の米国空軍材料研究所でデニス・E・ウィスノスキー、ダン・L・シュンクらによって開始され^{、 1980年代に完成しました。IDEFは}米国空軍のICAMイニシアチブの成果です。IEEEはIDEFの略語をIntegration Definitionに改名しました。^[12]

IDEF を作成した特定のプロジェクトは、ICAM プロジェクト優先順位 111 および 112 (後に 1102 に再番号付け) でした。その後の統合情報サポート システム (IISS) プロジェクト優先順位 6201、6202、および 6203 は、異機種の物理コンピューティング環境で実行できる情報処理環境の作成を試みました。新しいモデリング手法の適用から得られた経験の結果として、これらのプロジェクトの下で IDEF のさらなる開発が行われました。IISS の取り組みの目的は、米国の防衛請負業者や友好国の軍隊 など、多数の協力企業が使用できる「汎用サブシステム」を作成することでした。

ICAM 1102 の取り組みの時点では、コンピュータ データを格納するためのデータ モデルメソッドが多数存在していましたが、そのほとんどは互換性がありませんでした。シーケンシャル( VSAM )、階層( IMS )、ネットワーク( Cincomの TOTAL とCODASYL、CullinetのIDMS ) などです。リレーショナル データ モデルは、簡単、効率的、かつ正確なアクセスのためにデータを構造化する有望な方法として登場したばかりでした。リレーショナル データベース管理システムは、データ管理の一般的な標準としてはまだ登場していませんでした。

ICAM プログラム オフィスは、大規模システムのデータ コンテンツを記述する「中立的な」方法を作成することが有益であると考えました。新たに登場した学術文献では、物理的に格納されている方法とは関係なくデータを処理する方法が必要であることが示唆されていました。そのため、格納方法やファイル アクセス方法に関係なく適用できるデータ構造の中立的な記述を可能にするために、IDEF1 言語が作成されました。

IDEF1 は、ICAM プログラム優先度 1102 に基づき、ヒューズ エアクラフト カンパニーの Robert R. Brown 氏によってSofTech, Inc.との契約に基づいて開発されました。Brown 氏は以前、 Rockwell Internationalで勤務中にIMSの開発を担当していました。Rockwell は IMS を市場性のある製品として追求しないことを選択しましたが、開発中にサポート契約者となっていたIBM がその後製品を引き継ぎ、市場向けにさらに開発を進めることに成功しました。Brown 氏は、ヒューズの同僚 Timothy Ramey 氏が情報構造をモデル化するための実行可能な形式として IDEF1 を発明したと考えています。Hughes の 2 人の研究者は、当時のこの分野の多くの著名人からのアイデアや交流を基に開発を進めました。特に、IDEF1 では次の手法が利用されています。

• GM Nijssen ( Control Data Corporation )の進化型自然言語情報モデル ( ENALIM ) 手法 — この手法は現在、 NIAMまたはオブジェクトロールモデルORMとして広く知られています。
• Charles Bachman ( Honeywell Information Systems )のネットワーク データ構造手法 (一般にCODASYLアプローチと呼ばれる) 。
• RR Brown ( Rockwell International )によって開発され、IBM の IMS データ管理システムに実装されている階層型データ管理手法。
• EF Codd ( IBM )のデータに対するリレーショナルアプローチ
• Peter Chen ( UCLA ) のエンティティ・リレーションシップ・アプローチ(E-R) 。

IDEF1 の開発努力の結果、情報モデリングの新しい方法と、「製造の参照情報モデル」という形でその使用例が生まれました。この後者の成果物は、ヒューズの下請け業者として活動し、ラメイの指導の下、D. Appleton Company (DACOM) の DS Coleman によって開発されました。DACOM のスタッフは IDEF1 モデリングの専門家となり、その後、IDEF1 モデリング手法のトレーニング コースと付随資料を作成しました。

IDEF1 の経験から、情報要件をデータベース設計に変換することは、当初予想していたよりも困難であることがわかりました。IDEF1 情報モデリング手法の最も有益な価値は、データの保存方法や使用方法に関係なくデータを表現できることです。これにより、データ モデラーとデータ アナリストは、要件収集プロセス中にデータ要件を表現する方法を得ることができました。これにより、設計者はデータ要件の性質を理解した後、どの DBMS を使用するかを決定でき、データ要件と DBMS の機能および制限との間の「不一致」が軽減されました。しかし、IDEF1 モデルをデータベース設計に変換することは困難であることが判明しました。

IDEF0 機能モデリング手法は、組織またはシステムの意思決定、行動、活動をモデル化するように設計されています。^[13]これは、Douglas T. RossとSofTech, Inc.によって開発された、確立されたグラフィック モデリング言語構造化分析および設計手法(SADT)から派生したものです。元の形式では、IDEF0 には、グラフィカル モデリング言語 (構文とセマンティクス)の定義と、モデルを開発するための包括的な方法論の説明が含まれています。^[14]米国空軍は、システムの機能的観点を分析して伝達するための機能モデル手法の開発を SADT 開発者に委託しました。IDEF0 は、システム分析の整理を支援し、簡素化されたグラフィカル デバイスを通じてアナリストと顧客間の効果的なコミュニケーションを促進する必要があります。^[13]

IISS-6202 プロジェクトで特定されたデータ モデリング拡張要件を満たすために、下請け業者である DACOM は、論理データベース設計手法(LDDT) とそのサポート ソフトウェア (ADAM) のライセンスを取得しました。LDDT は、1982 年にデータベース設計グループの Robert G. Brown によって、IDEF プログラムとはまったく関係なく、IDEF1 の知識もない状態で開発されました。LDDT は、リレーショナル データ モデル、E-R モデル、および一般化の要素を、データ モデリングとデータ モデルのデータベース設計への変換をサポートすることを特に意図した方法で組み合わせました。LDDT のグラフィック構文は IDEF1 のものと異なり、さらに重要なことに、LDDT には IDEF1 には存在しない相互に関連するモデリング概念が含まれていました。Mary E. Loomis は、可能な限り IDEF1 と互換性のある用語を使用して、LDDT の重要なサブセットの構文とセマンティクスの簡潔な要約を作成しました。DACOM は、その結果をIDEF1Xと名付け、ICAM プログラムに提供しました。^{[15] [16]}

IDEF プログラムは政府によって資金提供されているため、その技術はパブリック ドメインです。DACOM が Leverage という名前で販売している ADAM ソフトウェアに加えて、多数のCASEツールがデータ モデリングの表現技術としてIDEF1X を使用しています。

IISS プロジェクトでは、異機種コンピューティング環境で動作する情報処理環境の実用的なプロトタイプが実際に作成されました。Java や JDBC などの技術の現在の進歩により、IISSによって初めて実証されたコンピューティング環境全体にわたる普遍性と汎用性の目標が達成されつつあります。

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

IDEF4の開発は、オブジェクト指向プログラミングパラダイムから得られるモジュール性、保守性、コードの再利用性が、従来のデータ処理アプリケーションで実現できるという認識から生まれました。オブジェクト指向プログラミングパラダイムが大規模で複雑な分散システムでデータレベルの統合をサポートすることが実証されていることも、従来のデータ処理コミュニティからこの技術への関心が高まっている大きな要因です。^[17]

IDEF4は、 Common Lisp Object System、Flavors、Smalltalk、Objective-C、C++などのオブジェクト指向言語を使用するソフトウェア設計者向けの設計ツールとして開発されました。オブジェクト指向パラダイムを効果的に使用するには、従来の手続き型言語やデータベース言語とは異なる思考プロセスが必要なため、構造図、データフロー図、従来のデータ設計モデル（階層型、リレーショナル型、ネットワーク型）などの標準的な方法論では不十分です。IDEF4は、オブジェクト指向設計の意思決定プロセスをサポートするために必要な機能を提供することを目指しています。^[17]

IDEF5、またはオントロジー記述キャプチャ法の統合定義は、使用可能で正確なドメインオントロジーを開発および維持するためのソフトウェアエンジニアリング手法です。^[18]コンピュータサイエンスの分野では、オントロジーは特定のドメインの概念とオブジェクトを、関連する関係と意味とともにキャプチャするために使用されます。さらに、オントロジーキャプチャは用語を標準化することでプロジェクトを調整し、情報の再利用の機会を作り出します。IDEF5オントロジーキャプチャ法は、特定のドメインに対する人間の理解を厳密に反映する方法でオントロジーを確実に構築するために開発されました。 ^[18]

IDEF5法では、現実世界のオブジェクト、その特性、相互関係に関する特定の主張の内容をキャプチャし、その内容を直感的で自然な形式で表現することによってオントロジーが構築されます。IDEF5法には、概念的なオントロジー分析をサポートするグラフィカル言語、詳細なオントロジー特性評価のための構造化テキスト言語、および効果的なオントロジーキャプチャのガイドラインを提供する体系的な手順という3つの主要なコンポーネントがあります。^[19]

IDEF6 （設計根拠の統合定義）は、エンタープライズシステムの開発で使用される設計根拠の取得、表現、操作を容易にする方法です。根拠とは、設計者が特定の戦略や設計機能を選択した理由、正当性、根底にある動機、または言い訳です。もっと簡単に言えば、根拠は「なぜこの設計はこのように行われるのか」という質問に対する答えとして解釈されます。ほとんどの設計方法は、設計が何であるか（つまり、設計がなぜそのようになっているのかではなく、最終製品）に焦点を当てています。^[9]

IDEF6は、必要な概念的リソースと言語的能力を備えた手法である。

1. 特定のシステム内の設計根拠を構成する情報の性質と構造を表現すること、そして
2. その根拠をシステムの設計仕様、モデル、およびドキュメントに関連付けます。

IDEF6は、初期概念化から予備設計および詳細設計活動まで、情報システム開発プロセスのすべての段階に適用できます。ソフトウェアシステムの詳細な設計決定がコーディング段階に委ねられている限り、IDEF6手法はソフトウェア構築プロセスでも使用できるはずです。^[7]

IDEF8 またはヒューマン システム インタラクション設計の統合定義は、ユーザーとユーザーが操作するシステムとの間のインタラクションの高品質な設計を作成する方法です。システムは、特定の目標を達成するための機能を実行するオブジェクトの集合として特徴付けられます。ユーザーがインタラクションするシステムは、必ずしもコンピュータ プログラムではなく、任意のシステムです。ヒューマン システム インタラクションは、IDEF8 メソッド内の 3 つの仕様レベルで設計されます。最初のレベルでは、システム操作の哲学を定義し、システム プロセス全体のモデルとテキスト記述のセットを作成します。2 番目の設計レベルでは、システム使用の役割中心のシナリオを指定します。IDEF8 設計の 3 番目のレベルは、ヒューマン システム設計の詳細化用です。この設計レベルでは、IDEF8 は、ユーザーと設計者が、動作がよりよく知られている他のオブジェクトの観点から、望ましい動作を指定できるように、メタファーのライブラリを提供します。メタファーは、よく知られている具体的なオブジェクトと経験の観点から、抽象的な概念のモデルを提供します。^[9]

IDEF9、つまりビジネス制約発見のための統合定義は、ビジネス システムにおける制約の発見と分析を支援するために設計されています。IDEF9 の開発を推進した主な動機は、エンタープライズ システムを形成する制約の集合が一般に十分に定義されていないことを認識したことでした。どのような制約が存在し、それらの制約がどのように相互作用するかについての知識は不完全で、ばらばらで、分散しており、完全に不明な場合がよくあります。生物が特定の動作を制御する遺伝的または自律的な制約を認識する必要がないのと同様に、組織はシステムを構成する接着剤に関する明示的な知識がなくてもうまく機能できます (ほとんどの組織がそうしています)。ただし、ビジネスを予測可能な方法で変更するには、これらの制約に関する知識が、遺伝子工学者にとっての遺伝学の知識と同じくらい重要です。^[9]

IDEF14、つまりネットワーク設計の統合定義法は、コンピュータおよび通信ネットワークのモデリングと設計を対象とする手法です。既存の（「現状のまま」）または想定される（「予定の」）ネットワークをモデル化するために使用できます。ネットワーク設計者が潜在的なネットワーク設計を調査し、設計の根拠を文書化するのに役立ちます。IDEF14研究プロジェクトの基本的な目標は、迅速かつ正確に実装できる優れたネットワーク設計の必要性を認識したことから生まれました。^[9]

 この記事には、国立標準技術研究所の パブリックドメイン資料が組み込まれています。

• Ovidiu S. Noran (2000)。ビジネスモデリング: UML vs. IDEF 2006-01-13 にWayback Machineでアーカイブされた論文 グリフィス大学

ウィキメディア・コモンズには、 IDEFに関連するメディアがあります。

• 統合された定義方法
• データモデリング
• IDEF プロセス モデリング方法論 (Robert P. Hanrahan 著、1995 年)