Remove ads
IDEF（Integration DEFinition）はシステム工学やソフトウエア工学分野における統合化定義のためのモデリング手法ファミリを参照する。
 | この項目「IDEF」は途中まで翻訳されたものです。（原文：en:IDEF 18:11, 1 May 2011 UTC） 翻訳作業に協力して下さる方を求めています。ノートページや履歴、翻訳のガイドラインも参照してください。要約欄への翻訳情報の記入をお忘れなく。（2011年5月） |
機能モデリングからデータ、シミュレーション、オブジェクト指向の分析／設計と知識獲得までの幅広い利用レンジをカバーしている。これらの『定義手法』は米国空軍からの資金で開発され、その後他の軍隊や国防省の機関を含め、今も彼らによって最も共通に使用されるパブリック・ドメインの手法になっている。
IDEFファミリ手法で最も幅広く認識されかつ使われているコンポーネントは、構造化分析及び設計技法で構築された機能モデリングの手法であるIDEF0と、情報モデリングとデータベース設計課題を扱うIDEF1Xである。
IDEFファミリ手法は、IDEF14まで定義された。
- IDEF0: 機能モデリング手法[2]
- IDEF1: 情報モデリング手法[3]
- IDEF1X: 情報／データ・モデリング手法[4]
- IDEF2 : シミュレーション・モデル設計
- IDEF3 : プロセス記述獲得手法[5]
- IDEF4 : オブジェクト指向設計手法[6]
- IDEF5 : オントロジ記述獲得手法[7]
- IDEF6 : 設計根拠獲得手法[8]
- IDEF7 : 情報システム監査
- IDEF8 : ユーザ・インタフェース・モデリング
- IDEF9 : 事業制約発見
- IDEF10 : 実装仕組モデリング
- IDEF11 : 情報生成物モデリング
- IDEF12 : 組織モデリング
- IDEF13 : 3層スキーマ・マッピング設計
- IDEF14 : ネットワーク設計
1995年までにIDEF0、IDEF1X、IDEF2、IDEF3、及びIDEF4が完全に開発された。[9] 他のいくつかのIDEF手法の概念設計も行われた。最後の試みは、1995年の事業制約発見 (IDEF9)、設計根拠獲得 (IDEF6)、人間－システム相互作用設計 (IDEF8)、及びネットワーク設計 (IDEF14)のための信頼できる手法に向けての新しいIDEF手法開発だった[1]。
手法IDEF7、IDEF10、IDEF11、IDEF 12、及びIDEF13は、それらの初期定義以上のどんな開発も行われなかった[10]。
Remove ads
IDEFは、1970年代に米空軍のマテリアル・ラボ、オハイオ州ライト・パターソン空軍基地でデニス・ウィスノスキー、ダン・L.・シュンク（Dan L. Shunk）他によって始められた、ICAMの定義が起源となり、1980年代に開発が終了した[11]。IDEFは、アメリカ空軍のICAMイニシアティブのプロダクトだった。『IDEF』は、当初『ICAM DEFinition』言語であり、IEEE標準はそれを『Integration DEFinition』としてIDEFを改名した。
IDEFを作ったその特定プロジェクトは、プライオリティ111と112（後に1102と再付番された）のICAMプロジェクトであった。後に続いたプライオリティ6201、6202、及び6203情報統合支援システム（Integreted Information Support System：IISS）プロジェクトは、異種混合物理コンピュータ環境で実行できる情報処理環境を創作する努力だった。新しいモデリング技術の応用で向上した経験の結果として、IDEFの更なる開発がそれらのプロジェクトの下で起こった。IISS努力の意図は、米国の軍需契約や友好国の武装軍隊のような多くの協調した事業体で使うことができる'汎用的サブシステム'を創出することだった。
ICAM1102努力の時点で、コンピュータにデータを格納するための、多彩で、ほとんど互換性のない、データモデル手法が存在した[12]関係モデルは、容易で、効率的で、かつ正確なアクセスのためのデータの構造化について考える頼もしい方法としてちょうど台頭した。関係データベース管理システムは、データ管理のための一般的標準としてまだ登場していなかった。
ICAM プログラムオフィスは、大規模システムのデータ・コンテンツを記述する「中立的」方法を作成することに価値を乱していた。登場する学問的文献は、それが物理的に格納される方法と独立なデータを処理する方法を示唆した。そこでIDEF1言語が、格納方法あるいはファイル・アクセス方法に関係なく等しく適用され得る、データ構造の中間的記述を可能にするため作られた。
IDEF1は、SofTech社との契約の下でヒューズ・エアクラフトのロバート・R.・ブラウンによって ICAMプログラム プライオリティ1102の下で開発された。ブラウンは、以前働いていたロックウェル・インターナショナルでIMS開発の責任があった（ロックウェルは、市場製品としてIMSを追求するのを止めたが、その開発中に支援契約としてサービスしていたIBMがそのあとその製品を引き継ぎ、その市場への更なる開発を成功させた）。ブラウンは、ヒューズの同僚ティモシー・レイミー（Timothy Ramey）を情報構造モデリングの実現可能な形式のIDEF1の創案者として認めた。2人のヒューズの研究者は、その時のフィールドに存在する多くの著名人からのアイデアの上に構築した。特に、IDEF1は以下の技術を活用している。
- G. M. Nijssen(CDC)の進化する自然言語情報モデル(ENALIM)技術 — この技術は現在、NIAMあるいはオブジェクト役割モデル（ORM）としてより幅広く知られている。
- チャールズ・バックマン(Honeywell Information Systems)の、一般にCODASYLアプローチと呼ばれる、ネットワーク・データ構造。
- IBMのIMSデータ管理システムに実装され、ブラウン(ロックウェル・インターナショナル)が開発した、階層データ管理技術。
- エドガー・F・コッド (IBM)のデータのリレーショナル・アプローチ。
- ピーター・チェン (UCLA)の実体関連モデル。
IDEF1 を発展させる努力は、情報モデリングの新しい方法と「製造の参照情報モデル」のフォームでのその使用例の両方をもたらした。この後の作成物は、レイミーの指揮の元、ヒューズのサブ契約者として行動した、D. Appleton Company (DACOM)のD.・S.・コールマンによって開発された。DACOM の要員は、IDEF1モデリングの大変なエキスパートに成り、その後 IDEF1モデリング技術のトレーニングコースとそれに伴う資料を作った。
IDEF1 の経験は、データベース設計への情報要求の変換が当初の予測より相当に難しかったことを明らかにした。IDEF1 情報モデリング技術の最も有益な価値は、それらのデータがどのように格納され使われるべきかと独立にデータを表現する能力だった。それは、要求収集プロセスの間にデータ要求を表すことを、方法を伴いデータ・モデラーとデータ分析者に提供した。これは設計者が、データ要求の本質が理解された後で、どのDBMSを様々な状況下で使うかの意思決定に接することを可能にした。結果は、DBMSの能力と限界へのデータ要求の「不整合」の縮小でしたこれによってIDEF1モデルからデータベース設計への変換は、難しいことが証明された。
Remove ads
IDEF0
IDEF0 機能モデリングは、組織又はシステムの意思決定、行動、及び活動のモデル化をすることを意図している[13] 。それは、ダグラス・テイラー・ロス と SofTech社によって開発され確立された図式モデリング手法の構造化分析及び設計技法 (SADT)から派生した。IDEF0は、そのオリジナル形式で図式モデリング言語 (文法と意味論)とモデル開発のための包括的手法論の解説の両方を含む。[14] 。米空軍は、システムの機能的視点から分析とコミュニケーションのための機能モデリング手法の開発を SADT の開発者に委託した。IDEF0は、単純化された図式デバイスでシステム分析の組織化で支援し、分析者と顧客間のコミュニケーションを効果的に促進する。[13]
IDEF1X
IISS-6202プロジェクトで認識されたデータモデリングの拡張要求を充たすため、サブコントラクタ（DACON）は、論理データベース設計技術 (LDDT)とその支援ソフトウエア（ADAM）へのライセンスを取得した。LDDTは、1982年に、IDEFプログラムのまったく外の、さらにIDEF1の知識を持たない、データベース設計グループ（The Database Design Group）のRobert G. Brownによって開発された。LDDTは、リレーショナル・モデル、E-Rモデル、及び、データ・モデリングとデータベース設計へのデータ・モデルの変換を支援することを意図した具体的方法におけるデータ汎化の要素を結びつけた。LDDTの図式構文はIDEF1のそれとは異なり、そしてより重要には、LDDTが含む相互関係モデリング概念は、IDEF1で存在しない。Mary E. Loomis は、可能なかぎりIDEF1と互換性のある用語を使って、LDDTの重要なサブセットの構文と意味論の簡潔な要約を書いた。DACOMは、結果をIDEF1Xと名づけ、そしてそれを1985年に発効した、ICAMプログラムに供給した[15][16]
IDEFプログラムは政府による資金で行われたことから、その技術はパブリック・ドメインに存在する。ADAMソフトウエアへの追加で、Leverageの名前の下でDACOMによって売られた、CAのERwinのような幾つかのコンピュータ支援ソフトウエアエンジニアリング（CASE）ツールが、データ・モデリングのための彼らの表現技術としてIDEF1Xを使った。
IISSプロジェクトは、異種のコンピュータ環境で実行でる情報処理環境の作業プロトタイプを実際に作った。JavaやJDBCのような技術における現在の優位性は、IISSによって最初に示された、あらゆるところ（ubiquity）でかつあらゆる用途（versatility）を横断したコンピューティング環境の目標を現在到達している。
IDEF2 と IDEF3
3番目のIDEF（IDEF2）は、ユーザー・インタフェース・モデリング手法として当初意図された。しかしながらICAMプログラムは、シミュレーション・モデリング・ツールを必要とし、結果のIDEF2は、数学モデル・ベース・シミュレーションの使用のためのフレームワークを提供する、製造システムにおける資源の時系列的振舞を表現する手法であった。この状況を改善することがICAM内での手法論プログラムの意図であったが、資金の限界がそれをすることを許さなかった。結果として、システムの利用者ビューの記述の構造化支援の方法の不足が、IDEFシステムの主要な欠陥となっていた。手法論的観点からの基本的問題は、システム（既存または提案された）が何をするはずかの記述と、システムが何をするであろうかを予測するシミュレーション・モデルの表現とを区別することの必要性である。この後者がIDEF2の焦点であり、前者がIDEF3の焦点である[17]。
IDEF4
IDEF4の開発は、オブジェクト指向プログラミングパラダイムからの結果、モジュール性、維持性、及びコードの再利用性が、伝統的なデータ処理アプリケーションで実現され得ることを認識したことから始まった。大規模複雑な分散システムにおけるデータ・レベルの統合を支援するオブジェクト指向プログラミング・パラダイムの実証された能力は、また伝統的なデータ処理コミュニティからこの技術に対する幅広く広がった関心における大きな要素でもあった[17]。
IDEF4は、LISP、Flavors、Smalltalk、Objective-C、C++ 、およびその他を使うソフトウエア設計者のための設計ツールとして開発された。オブジェクト指向パラダイムの効果的な使用法は、従来の手続的あるいはデータベース言語を使用と異なる思考過程を必要とすることから、構造化チャート、データ・フロー・ダイアグラム、あるいは伝統的データベース・モデル（階層的、リレーショナル、およびネットワーク）のような標準手法論では十分でない。IDEF4は、オブジェクト指向設計の意思決定過程を支援する必要な手段を提供することを模索した[17]。
IDEF5
IDEF5、またはオントロジ獲得のための統合化定義手法は、ドメインのオントロジ（概念体系）を開発し、その有用性、正確性を維持するためのソフトウエア・エンジニアの手法である[18]。コンピュータ科学の分野で概念体系は、関連づけられた関係と意味とともに、特定のドメインにおける概念とオブジェクトを獲得するために使われます。加えて、概念体系獲得は、用語の標準化により協調するプロジェクトを助け、情報の再利用の機会を創り出す。IDEF5 オントロジ獲得手法は、特定ドメインの人間の理解を密接に反映する方法で、概念体系をしっかり構築するため開発された[18]。
IDEF5手法において、概念体系は、実世界のオブジェクト、それらの特性、およびそれらの相互関係についてある特定の想定のコンテンツを獲得し、直観的で自然な形式でそれらのコンテンツを表現することによって構築される。IDEF5手法は、3つの主要な構成要素を持つ。概念的な体系分析を支援する図式言語、概念体系を特徴付ける詳細化のための構造化テキスト言語、および効果的な概念体系獲得のためのガイドラインを提供する体系的な手順[19]。
IDEF6
IDEF6 ([:en])または設計根拠獲得のための統合化定義は、事業体システムの開発で使われる設計根拠の収集、表現、および維持を促進する手法である。根拠とは、理由、妥当性、動機の背景、あるいは設計者に特定な戦略あるいは設計の特徴を選ばせる弁解である。より簡単には、根拠は、『なぜこの設計がこのような方法で行われているのか？』の質問への答えの解釈である。ほとんどの設計手法は、その設計は何か（例えば、なぜ設計がそのような方法か、よりむしろ、最終製品に関して）に焦点を当てる[1]。
IDEF6は、概念的資源と、1. 与えられたシステム内で設計根拠を構成する情報の性質と構造を表現すること、及び 2. そのシステムのため設計仕様、モデル、及び文書に関係づけることを必要とする言語能力を持つ手法である。IDEF6は、予備的及び詳細設計活動の両方を通して初期の概念化から 情報システム開発プロセスの全てのフェーズに適用される。ソフトウエア・システムがコーディング・フェーズに下ろされるのための詳細な意思決定に広げるため、IDEF6技術は同様にソフトウエア構築プロセスの間にも利用可能であるべきである[8]。
IDEF8
IDEF8または人間－機械相互作用設計の統合化定義は、ユーザーと彼らが運用するシステムとの間に起こる相互作用の高品質な設計をするための一つの手法である。 システムは、特定目標を達成する機能群を実行するオブジェクトの集合として特徴付けられる。ユーザーが相互作用するシステムは、必ずしもコンピュータ・プログラムを必要とせず、どんなシステムでもあり得る。人間と機械の相互作用は、IDEF8手法内に3レベルの仕様で設計された。その最初のレベルは、システム運用の考え方（哲学）を定義し、全体的システム・プロセスのモデル・セットと文章記述を作り出す。設計の2番目のレベルは、システム利用の役割中心的シナリオを規定する。IDEF8設計の3番目のレベルは、人間と機械の詳細設計のためである。設計のこのレベルでIDEF8は、ユーザーと設計者がより知られている振舞いの他のオブジェクトの基準で望む振舞いを規定するのを助ける、メタファーのライブラリを提供する。メタファーは、よく知られた具体的オブジェクト及び経験の基準で、抽象概念のモデルを提供する。[1]
IDEF9
IDEF9または事業制約発見のための統合化定義は、事業システム (business system)における制約の発見と分析を支援することを意図した。IDEF9の開発を駆動する主要な動機は、事業体システムを築き上る制約の集合が一般的に十分に定義されていないことを認めたことであった。どんな制約が存在しそれら制約がどのように相互作用かの知識が、不完全で、断絶し、配布され、そして時にはまったく知られていないことである。まさに生体がある種の振舞いを統治する遺伝子的または自律的制約に気付いていないように、組織は、システムを組立てる接着剤の明示的知識なしでうまく能力を（ほとんどの場合）発揮できる。しかしながら、予測可能な方法で事業を変更するため、遺伝子工学で遺伝子の知識が重要なように、これらの制約の知識が重要である。[1]
IDEF14
IDEF14またはネットワーク設計のための統合化定義手法は、コンピュータや通信ネットワーク (communication network)のモデリングと設計をターゲットとした一つの手法である。それは、既存（As-is）または想定（To-be）のネットワークをモデル化するのに使われ得る。それはネットワーク設計者に潜在的ネットワーク設計を調査し、設計根拠を文書化するのを助ける。 IDEF14研究プロジェクトの基本的目標は、すばやく勝つ正確に実装されえる良いネットワーク設計のためのニーズから発展された。 [1]
Remove ads
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
Remove ads