IDEF

IDEFメソッド:システムエンジニアのツールボックスの一部

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

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

IDEF手法の概要

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年には、 IDEF0IDEF1XIDEF2IDEF3IDEF4のみが完成していました。[ 8 ]その他のIDEF概念のいくつかは、予備設計段階にありました。1995年には、ビジネス制約発見IDEF9、設計根拠把握IDEF6、人間システムインタラクション設計IDEF8、ネットワーク設計IDEF14のための信頼性の高い手法を確立するための新たな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とCODASYLCullinetIDMS)などです。リレーショナルデータモデルは、容易で効率的かつ正確なアクセスを実現するデータ構造化の有望な手法として、登場したばかりでした。リレーショナルデータベース管理システムは、データ管理の一般的な標準としてはまだ確立されていませんでした。

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

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

IDEF1の開発努力は、情報モデリングのための新しい手法と、「製造業の参照情報モデル」という形でその活用例を生み出しました。この後者の成果物は、ヒューズ社の下請け業者として活動していたD.アップルトン社(DACOM)のDSコールマン氏によって、レイミー氏の指揮の下、開発されました。DACOMの担当者はIDEF1モデリングの専門家となり、その後、IDEF1モデリング手法に関するトレーニングコースと付随資料を作成しました。

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

IDEFモデリング言語

IDEF0

IDEF0図の例:修理可能なスペアパーツの保守プロセスの機能モデル

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

IDEF1X

IDEF1X図の例

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

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

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

IDEF2とIDEF3

IDEF3でモデル化された、強化された遷移図の例

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

IDEF4

IDEF4動作図

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

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

IDEF5

ボールペンのIDEF5構成図の例

IDEF5(統合定義オントロジー記述キャプチャ法)は、有用かつ正確なドメインオントロジーを開発・維持するためのソフトウェアエンジニアリング手法である。[ 18 ]コンピュータサイエンスの分野では、オントロジーは特定のドメインにおける概念やオブジェクト、および関連する関係性や意味を捉えるために使用される。さらに、オントロジーキャプチャは用語の標準化によってプロジェクトの調整を支援し、情報の再利用の機会を創出する。IDEF5オントロジーキャプチャ法は、特定のドメインに対する人間の理解を忠実に反映したオントロジーを確実に構築するために開発された。[ 18 ]

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

IDEF6

IDEF4設計活動のIDEF6モデル

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

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

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

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

IDEF8

IDEF8(ヒューマン・システム・インタラクション設計のための統合定義)は、ユーザーとユーザーが操作するシステムとの間のインタラクションの高品質な設計を作成するための手法です。システムは、特定の目標を達成するために機能を実行するオブジェクトの集合として特徴付けられます。ユーザーがインタラクションするシステムは、必ずしもコンピュータプログラムではなく、任意のシステムです。ヒューマン・システム・インタラクションは、IDEF8手法において3つの仕様レベルで設計されます。第1レベルでは、システム運用の理念を定義し、システムプロセス全体のモデルとテキスト記述のセットを作成します。第2レベルの設計では、システム利用における役割中心のシナリオを指定します。IDEF8設計の第3レベルは、ヒューマン・システム設計の詳細化です。この設計レベルでは、IDEF8はメタファーのライブラリを提供し、ユーザーと設計者が、より馴染みのある動作をする他のオブジェクトを用いて、望ましい動作を指定するのに役立ちます。メタファーは、馴染みのある具体的なオブジェクトや経験を用いて、抽象的な概念のモデルを提供します。[ 9 ]

IDEF9

典型的なビジネスシステム

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

IDEF14

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

参考文献

パブリックドメイン この記事には、米国国立標準技術研究所(NIST)パブリックドメイン資料が含まれています

  1. ^ IDEFØ 概要アーカイブ2016-03-05 at the Wayback Machine at idef.com
  2. ^ IDEF1 概要アーカイブ2016-03-03 Wayback Machine at idef.com
  3. ^ IDEF1x の概要は、 idef.com のWayback Machineで 2016 年 3 月 8 日にアーカイブされています。
  4. ^ IDEF3 概要アーカイブ2010-04-25 at the Wayback Machine at idef.com
  5. ^ IDEF4の概要は、 idef.comのWayback Machineで2016年2月27日にアーカイブされています。
  6. ^ IDEF5の概要は 、 idef.comのWayback Machineで2016年3月3日にアーカイブされています。
  7. ^ a b Mayer, Richard J. ; Griffith, Patricia A.; Menzel, Christopher P. (1990-91) 「IDEF6: 設計根拠捕捉法コンセプトペーパー」 2007年4月2日アーカイブ、Wayback Machine国防技術情報センター
  8. ^ Robert P. Hanrahan「IDEFプロセスモデリング手法」Wayback Machineに2007年1月26日アーカイブ。ソフトウェア技術サポートセンター。1995年
  9. ^ a b c d e Richard J. Mayer (1995) 他著「Information Integration for Concurrent Engineering (IICE) Compendium of methods report」Wayback Machineに2007年7月11日アーカイブ。ライト・パターソン空軍基地、オハイオ州45433-7604。
  10. ^技術アーキテクトの観察:エンタープライズ実装の問題と解決策Craig Borysowich. 2009年1月20日にアクセス。
  11. ^チャールズ・M・サベージ(1996年)『第五世代のマネジメント:バーチャル・エンタープライジング、ダイナミック・チーム、ナレッジ・ネットワーキングによる共創』バターワース・ハイネマン、1996年。ISBN 0-7506-9701-6184ページ
  12. ^ IEEE標準機能モデリング言語 - IDEF0の構文と意味論、IEEEコンピュータソサエティソフトウェアエンジニアリング標準委員会、IEEE-SA標準委員会、米国電気電子技術者協会、345 East 47th Street, New York, NY 10017-2394、 IEEE Std 1320.1-1998、1998年6月25日
  13. ^ a b Varun Grover、William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age . p. 168.
  14. ^ FIPS Publication 183 Archived 2009-02-27 at the Wayback Machine、IDEFØ 1993 年 12 月に米国国立標準技術研究所 (NIST) のコンピュータ システム研究所によってリリースされました。
  15. ^ IEEE (1998). IEEE Std 1320.2-1998. IDEF1Xの概念モデリング言語構文とセマンティクスに関するIEEE標準. ニューヨーク. p. iii.
  16. ^ブルース、トーマス A. (1992)、IDEF1X 情報モデルによる高品質データベースの設計、 ISBN 0-932633-18-8p=xii
  17. ^ a b cパトリシア・グリフィス・フリエル、トーマス・M・ブリン (1989). 「自動化されたIDEF3およびIDEF4システム設計仕様書」技術報告書。NASAジョンソン宇宙センター
  18. ^ a b Perakath C. Benjamin et al. (1994). IDEF5 Method Report Archived 2008-12-21 at the Wayback Machine . Knowledge Based Systems, Inc.
  19. ^ Varun Grover、William J. Kettinger (2000). Process Think: 情報化時代におけるビジネス変革の成功への展望. p.176-178

さらに詳しい情報