ビュー・モデル

システム工学、ソフトウエア工学、及びエンタープライズエンジニアリングにおけるビュー・モデル（英: view model）またはビューポイント・フレームワークは、システムアーキテクチャ、ソフトウェアアーキテクチャ、あるいはエンタープライズアーキテクチャの構築で使われるビューの整然としたセットを定義する一つのフレームワークである。ビューは関係する関心事のセットの観点からのシステム全体の一つの表現である^[1]。ビュー・モデルはアーキテクチャの構築、分類、及び組織化にためのガイダンスとルールを提供する^[2]。

1990年代初期から、システムアーキテクチャを記述し分析するための標準アプローチを定義する幾つかの努力が行われた。最近のエンタープライズアーキテクチャフレームワークのそれぞれは、ビューのセットを定義したが、しかしこれらのセットが常に『ビュー・モデル』と呼ばれるわけではない。

普通一つのビューは、与件のシステムのためのアーキテクチャデータの特定セットを表す非常に具体的なプロダクトである。しかしながら、同じ用語は時々、各具体的ビューを定義する特定ビューポイントと対応するガイダンスを含む、ビュー定義を参照するのに使われる。用語ビュー・モデルは、ビュー定義に関係する。

全貌[編集]

ビューポイント及びビューの目的は、複雑システムを人間の技術者に理解を可能にさせ、そして専門的知識ドメインを取り巻く問題と解決策の要素を編成することである。物理集約的システムにおけるエンジニアリングではビューポイントは、しばしばエンジニアリング組織内の能力と責任に対応する^[3]。

ほとんどの複雑システムの仕様は、一個人では仕様のすべてを完全に理解できないほど大規模である。更に、我々はそれぞれ、与件システムに異なった関心を持ち、システムの仕様を試す異なった理由を持っている。事業の執行者は、システムの実装者よりシステムを作り上げるための異なった質問を問いかける。ビューポイントフレームワークの概念は、その利害関係者とのコミュニケーションを円滑にするため、与件の複雑システムの仕様に別々のビューポイントを提供することである。各ビューポイントは、システムの特定の局面のセットに関心を持つ聴衆を満足させる。各ビューポイントは、そのビューポイントの聴衆のため、語彙と表現を最適化する特定なビューポイント言語を利用し得る。ビューポイントモデリングは、大きな分散システム本来の複雑性を取り扱うための有効なアプローチになった。

現在のソフトウエアアーキテクチャ的実践は、IEEE 1471に記述されている様に、それぞれがシステムの特定局面に焦点を当てる、幾つかの関心領域に設計活動を分ける。例には、4+1 アーキテクチャビュー・モデル（英語版）、Zachmanフレームワーク、The Open Group Architecture Framework (TOGAF)、DoDAF（英語版）、及びRM-ODF（英語版）を含む。

歴史[編集]

1990年代初期から、システムアーキテクチャを記述し分析するための標準的アプローチを定義しようとする幾つかの試みがあった。これらの多くは、米国防省によって資金が提供されたが、幾つかはISOあるいはIEEEにおける国際的及び国家的取組みから生まれた。これらの内最も適切な、ソフトウエア集約システムのアーキテクチャ記述のための推奨されるプラクティス（IEEE 1471）は、システムアーキテクチャが何であるかや、利害関係者の関心（英語版）(stakeholder concerns)を取り扱うためビューポイント仕様を使うのにたいへん有用な定義とガイドラインを提供する^[4]。

IEEE 1471仕様は、設計の前後関係、進化的な設計、及び既存システムの設計の獲得等を含む、多数のシナリオの元でアーキテクチャの記述を開発するためのプロセスを記述する。これらのシナリオの全てにおいて、全体的プロセスは同じである：利害関係者を識別する、関心事を引き出す、使われるべきビューポイントのセットを識別する、そしてその後、システムの適切なビューのセットを開発するのにこれらのビューポイント仕様を適用する。IEEE 1471 は、定義するシステム、（他との間の）機能的及び技術的なビューには言及していないが、それは、ビューのあらゆる特定セットを定義するほど遠くなく、またそれが何をするか判らないほど遠くない。結局1996年に、RM-ODPのためのISO参照モデルが、大規模分散システムのアーキテクチャの記述と設計のための有用なフレームワーク提供して発行された^[4]。

ビュー･モデルのトピック[編集]

ビュー[編集]

システムの一つのビューは、一つのビューポイント（視点）の観点からのシステムの一つの表現である。システムのこの視点は、その視点の関心事に関係する要素のみを持つ単純化されたモデルを提供し詳細を抑制する、そのシステムに関する特定な関心に焦点を当てた一つの観点を伴う。例えば、セキュリティの視点はセキュリティの関心に焦点を当て、セキュリティ視点のモデルは、システムのより一般的モデルからセキュリティに関係するそれらの要素を含む^[5]。

一つのビューは、ユーザーに特定な関心領域の部分を調べることを許す。例えば、組織ビューが特定組織に該当する全ての機能、技術、及び情報を表現する一方で、一つの情報ビューは、特定な情報の断片を利用する、全ての機能、組織、秘術などを表現するかもしれない。Zachmanフレームワークにおけるビューは、その開発が、事業体の『何を』、『如何に』『誰が』、『何処で』、『何時』、あるいは『なぜ』のいずれかに焦点を当てることから、特定の分析と技術的専門性を要求する作業プロダクトのグループを構成する。例えば、機能的ビューの作業プロダクトは、『どのようにミッションが遂行されるか？』の質問に答える。それらはプロセスとアクティビティ・モデリングで使った機能分割（英語版）におけるエキスパートによって最も容易に開発される。それらは、機能のビューポイントから事業体を示す。それらはまた組織的あるいは情報的構成要素も示すかもしれないが、それらは機能との関係としてのみ示される^[6]。

ビューポイント（視点）[編集]

視点は、特定な関心事のセットに限定するシステムにおける区画化を記述する、一つのシステム工学の概念である^[7]。一つの視点の適用は、それらの局面における課題が別々に取り扱われ得るため有用である。視点をうまく選定すれば、システムの設計を専門的な特定領域に区分できる^[3]。

視点は、ビューを構築し、表現し、そして分析するための慣習、ルール、及び言語を提供する。ISO/IEC 42010:2007 (IEEE 1471)における一つの視点は、ここのビューのための一つの仕様である。一つのビューは、一つの観点からシステム全体の一つの表現である。一つのビューは、一つ以上のアーキテクチャモデル（英語版）から構成され得る^[8]。Each such architectural model is developed using the methods established by its associated architectural system, as well as for the system as a whole.^[4]

モデリングの観点[編集]

モデリングの観点（英語版）は、システムの事前に選ばれた局面を表現する異なる方法のセットである。各観点は、何をモデルが表現するかの、異なる焦点、概念化、専念化、及び可視化を持つ。

情報システムにおいて、モデリングの観点を分割する典型的な方法は、構造的、機能的、及び振舞的／順序的観点を区別することである。ルール、オブジェクト、コミュニケーション、及びアクターや役割の観点を伴うこれは、モデリングのアプローチの分類の一つの方法である^[9]。

ビューポイント・モデル[編集]

与えられたどんな視点でも、その視点から視認されるオブジェクトだけを含む、システムの一つのモデルを作ることができるが、そのシステムにおいて表されかつその視点に適切な、そのオブジェクト、関係、及び制約の全ての獲得もできる。そのようなモデルが、ビューポイント・モデル、あるいはその視点からのシステムのビューと言われる^[3]。

与件のビューは、与えられた視点から特定の抽象レベルでのそのシステムのための仕様である。異なる抽象レベルは、詳細な異なるレベルを含む。より高いレベルのビューにより、エンジニアは設計全体を作りかつ理解することと、大きな問題を識別し解決することが可能になる。より低いレベルのビューは、エンジニアに設計の一部を具体化し、詳細な仕様を開発することを可能にする^[3]。

しかし、システムそれ自身において、種々のビューポイント・モデルに現れる仕様の全ては、そのシステムの実現化される構成要素で取り扱われなければならない。そして、あらゆる与件の構成要素の仕様は、多くの異なる視点から描くことができる。一方で、特定の構成要素と構成要素の相互作用を超えた機能分散によって誘発された仕様は、典型的にオリジナルの視点を反映したより関心の異なる区分を反映され得る。そこで、個別の構成要素の関心とシステムのボトムアップな合成を取り扱う、追加の視点が有用であり得る^[3]。

アーキテクチャ記述[編集]

一つのアーキテクチャ記述は、いつでも、その構成要素部分に関して、どのようにその部分が機能し、それらの部分がどんなルールや制約の下で機能し、どのようにそれらの部分がお互い及びその環境と関係するかについての、システムアーキテクチャの一つの表現である。アーキテクチャ記述におけるアーキテクチャデータは、複数のビュー及びプロダクトを横切って共有される^[2]。

データでのレイヤーは、アーキテクチャデータ要素とそれらの属性及び関係である。表現でのレイヤーは、それが何を記述し、様々なアーキテクチャ分析を実施する、そのアーキテクチャの目的を伝達し理解する視覚手段を支援するプロダクトとビューである。プロダクトは、図式、表形式、あるいは文章的な表現としてアーキテクチャデータを視覚化する一つの方法を提供する。ビューは、プロダクトを横断することなくアーキテクチャデータを視覚化し、アーキテクチャの特定または全体的観点のためデータを論理的に組織化する能力を提供する^[2]。

システム・ビュー・モデルのタイプ[編集]

3層スキーマ・アプローチ[編集]

データ・モデリングの3層スキーマ・アプローチ（英語版）は、1977年に登場した最初のビュー・モデルの一つと考えられる。それは、データ統合（英語版）を達成する鍵として概念的モデル（英語版）を促進する、情報システムとシステム情報管理を構築する一つのアプローチである^[11]。3層スキーマ・アプローチは、3つのスキーマとビューを定義する：

ユーザー・ビューのための外部スキーマ
概念スキーマは、外部スキーマを統合する
物理的格納構造を定義する、内部スキーマ

中心で、概念的スキーマは、ユーザーが考えそして会話するように、概念のオントロジーを定義する。物理的スキーマは、データベースに格納されるデータの内部的フォーマットを記述し、外部スキーマは、アプリケーションソフトウェアに表されるデータのビューを定義する^[12]。そのフレームワークは、外部スキーマのため使われるべき複数のデータ・モデルを許そうと試みた^[13]。

数年を経て、情報システムの構築における技能と関心はとてつもなく成長した。しかしながら、ほとんどの部分でシステム構築への伝統的アプローチは、『ユーザー・ビュー』と『コンピュータ・ビュー』の、2つの個別のビューからデータを定義することにだけ焦点を当てた。『外部スキーマ』として参照される、ユーザー・ビューからのデータ定義は、報告書あるいは各個人が彼らのジョブを行うのを支援するため設計される画面の文脈である。用途ビューから要求されるデータ構造は、事業環境やユーザー個々の好みで変化する。『内部スキーマ』として参照されるコンピュータ・ビューからのデータは、格納と読出のためのファイル構造の基準で定義される。コンピュータ・ストレージのため要求されるデータ構造は、採用される特定のコンピュータ技術と効率的なデータ処理へのニーズに依存する^[14]。

アーキテクチャの4+1 ビュー・モデル[編集]

4+1アーキテクチャビュー・モデル（英語版）は、1995年にフィリップ・クルーシュテン（英語版）によって設計された一つのビュー・モデルである^[15]。そのビューは、エンドユーザー、開発者、あるいはプロジェクト・マネージャのような、異なる利害関係者の視点でシステムを記述するため使われる。モデルの4つのビューは、論理、開発、プロセス、及び物理的ビューである。

モデルの4つのビューは以下に係わる：

論理的ビュー: システムがエンドユーザーに提供する機能性に係わる。
開発ビュー: プログラマの観点からシステムを描写し、ソフトウエア管理に係わる。
プロセス・ビュー: システムの動的局面を取扱い、システムのプロセスとどのようにそれらがコミュニケートするかを説明し、システムの実行時の振舞いに焦点を当てる。
物理的ビュー: システム・エンジニアの視点からシステムを描く。それは物理的レイヤー上のソフトウエア構成要素の配置（トポロジ）に係わる。

加えて、選ばれたユースケースまたはシナリオが、そのシステムを描き出すため利用される。そこでモデルは4+1ビューを包含する^[15]。

エンタープライズアーキテクチャビュー・モデルのタイプ[編集]

エンタープライズアーキテクチャフレームワークは、エンタープライズアーキテクチャに関連する、構造とビューをどのように組織化するかを定義する。エンタープライズアーキテクチャとエンジニアリングの規律があまりにも広く、かつ事業体は大規模かつ複雑になり得ることから、その規律に関連するモデルも大規模かつ複雑となる傾向がある。このスケールと複雑さを管理するためアーキテクチャフレームワークは、彼らが最も必要なときにタスクを焦点に持ち込みそして価値ある生成物を作成できるようにする、ツールや手法を提供する。

アーキテクチャフレームワークは、情報技術と情報システムの統治で一般に使われる。組織は、あるシステム設計が承認される前に、明確なモデルを作成することを望む。同様に、彼らは、調達されるシステムのドキュメントに使われるべき明確なビューの特定を望む。米国防省は、一定規模以上の投資プロジェクトの装置サプライヤによって提供されるDoDAF特定のビューを規定する。

Zachman フレームワーク[編集]

1987年にIBMでジョン・ザックマン（英語版）によって最初に提唱された、Zachmanフレームワークは、事業体を眺めそして定義する公式かつ高度に構造化された方法を提供する、事業体アーキテクチャのための一つのフレームワークである。

そのフレームワークは、生成物がターゲットとするのは誰か（例えば、事業オーナー、構築者）と扱われる特定の課題は何か（例えば、データや機能性）の両方を考慮に入れる一つの方法で、アーキテクチャの『生成物』を組織化するため使われる。これらの生成物は、設計ドキュメント、仕様、及びモデルを含みえる^[17]。

Zachmanフレームワークは、しばしばエンタープライズアーキテクチャの基本要素を表すための標準アプローチとして参照される。Zachmanフレームワークは、米連邦政府によって『事業体における変更を管理しそれらを支援するシステムの統合化されたフレームワークとして世界的に受容れられている』と認められた^[18]。

オープン分散処理参照モデル (RM-ODP) ビュー[編集]

オープン分散処理（英語版）^[19]のための国際標準化機構（ISO）参照モデルは、分散化されたソフトウエア／ハードウエア・システムの設計を区分するためのビューポイント（視点）のセットを規定する。ほとんどの統合化課題はそのようなシステム、または類似の状況の設計に現れ、これらの視点は統合の関心から分離するのに有用であると証明しえる。RM-ODP視点とは^[3]：

事業体視点は、組織の事業目的と事業プロセスに関係するようなシステムの目的と振舞いに係わる。
情報視点は、システムによって取り扱われる情報の性質と、その情報の利用と解釈を制約に係わる。
コンピュータ的視点は、インタフェースで特定の振舞いと相互作用を示す構成要素のセットへのシステムの機能的分割に係わる。
エンジニアリング的視点は、コンピュータ的構成要素の相互作用をサポートする、要求されるメカニズムと機能に係わる
技術的視点は、システムの実装のためと特に構成要素間でコミュニケートするための技術の明示的選定に係わる。

RMODPは更に、以下を含む視点間の整合した仕様を含める設計への要求を定義する^[3]：

情報ユニットを定義する事業体のオブジェクトとプロセスの利用
コンピュータ的構成要素の振舞いを規定する事業体のオブジェクトと振舞いの利用と、コンピュータ的インタフェースを定義する情報ユニットの利用
コンピュータ的インタフェースと振舞い要求とのエンジニアリング的選定の連携
技術選定における、情報、コンピュータ的、及びエンジニアリング的要求の充足

DoDAF ビュー[編集]

DoDAF（英語版）（国防省アーキテクチャフレームワーク）は、エンタープライズアーキテクチャまたはシステムアーキテクチャを補完し、一貫したビューに組織化する標準の方法を定義する。それは、複雑な統合と相互運用性へ挑戦する大規模システムに適しており、そして開発するシステムが運用する外部顧客の運用ドメインを詳細化する、その『運用ビュー』の利用で明らかにユニークである。

DoDAFは、図式、表形式、あるいは文章手段を通してアーキテクチャ記述の広いスコープと複雑さを可視化させ、理解させ、そして同化させるためのメカニズムとして演じるプロダクトのセットを定義する。これらのプロダクトは以下の4つのビューで組織化される：

包括的な、全体ビュー (AV)
運用ビュー（英語版） (OV)
システム・ビュー (SV)
技術標準ビュー (TV)

各ビューは、下記に述べられるようなアーキテクチャの一定の観点を描く。完全なDoDAのビューセットのサブセットは各システム開発のため普通に創作される。図は運用ビュー（英語版）、システムとサービス・ビュー及び技術ビューをつなぐ情報を表現する。その3つのビューと相互関係は、相互運用性や性能のような基準を引き出し、そして運用ミッションとタスクの有効性におけるこれらのメトリクスの値の影響を測定するため、基盤を提供する^[20]。

連邦エンタープライズアーキテクチャ（FEA）ビュー[編集]

米国連邦エンタープライズアーキテクチャ (FEA)において、事業体、セグメント、及びソリューションのアーキテクチャは、詳細さのレベルを変えることにより異なる事業の展望と、関連しているが別の関心を提供する。まさに事業体がそれ自身階層的に組織化されるように、アーキテクチャの各タイプによって準備される異なるビューもそうなる。FEA実践ガイド (2006) は3つのアーキテクチャのタイプを定義した^[21]：

エンタープライズアーキテクチャ (EA)
セグメントアーキテクチャ
ソリューションアーキテクチャ

定義では、EA は、基本的に共通または共有資産（それらが戦略、事業プロセス、投資、データ、システム、あるいは技術であろうとも）の識別に係わる。EAは戦略によって駆動される；それは各機関が、その機関のミッションと、戦略的目標及び目的に対してその資源が正しく整合されているかどうかを識別するのを助ける。投資の観点からEAは、全体としてIT投資ポートフォリオについての意思決定を促進するため使われる。従って、EAの一次的利害関係者は、その機関がそのミッションを可能な限り効果的で効率的に満たすことを確かにすることを担っている上級マネージャや行政幹部である^[21]。

それとは対照に、セグメントアーキテクチャは、中核ミッション領域、事業サービス、及びエンタープライズ・サービスのための簡単なロードマップを定義する。セグメントアーキテクチャは、事業管理によって促進され、市民と機関スタッフへのサービス供給を改善するプロダクトを提供する。投資の観点から、セグメントアーキテクチャは、中核ミッション領域あるいは、共通または共有サービスをサポートする事業または事業のグループのケースのための意思決定を促進する。セグメントアーキテクチャの一次的利害関係者は、事業所有者とマネージャである。セグメントアーキテクチャは3つの原則（構造、再利用、及び整合）を通してEAに関係する。最初に、セグメントアーキテクチャは、EAによって使われるフレームワークを継承するが、それは、中核ミッション領域、あるいは共通または共有サービスの特定ニーズに合致させるため拡張及び特殊化され得る。2番目に、セグメントアーキテクチャは、エンタープライズレベルで定義された重要な資産（データ、共通事業プロセスと投資、及びアプリケーションと技術）を再利用する。3番目に、セグメントアーキテクチャは、事業戦略、代表権、標準、及び性能測定のような、エンタープライズ・レベルで定義された要素を整合させる^[21]。

ビューの名目セット[編集]

In search of "Framework for Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views",^[4] Derived from CCSDS RASDS, RM-ODP, ISO 10746 and compliant with IEEE 1471.

This "set of views", as described below, is a listing of possible modeling viewpoints. Not all of these views may be used for any one project and other views may be defined as necessary. Note that for some analyses elements from multiple viewpoints may be combined into a new view, possibly using a layered representation.

In a latter presentation this nominal set of views was presented as an Extended RASDS Semantic Information Model Derivation.^[22] Hereby RASDS stands for Reference Architecture for Space Data Systems. see second image.

Enterprise Viewpoint^[4]

Organization view – Includes organizational elements and their structures and relationships. May include agreements, contracts, policies and organizational interactions.
Requirements view – Describes the requirements, goals, and objectives that drive the system. Says what the system must be able to do.
Scenario view – Describes the way that the system is intended to be used, see scenario planning. Includes user views and descriptions of how the system is expected to behave.

Information viewpoint^[4]

Metamodel view – An abstract view that defines information model elements and their structures and relationships. Defines the classes of data that are created and managed by the system and the data architecture.
Information view – Describes the actual data and information as it is realized and manipulated within the system. Data elements are defined by the metamodel view and they are referred to by functional objects in other views.

Functional viewpoint^[4]

Functional Dataflow view – An abstract view that describes the functional elements in the system, their interactions, behavior, provided services, constraints and data flows among them. Defines which functions the system is capable of performing, regardless of how these functions are actually implemented.
Functional Control view – Describes the control flows and interactions among functional elements within the system. Includes overall system control interactions, interactions between control elements and sensor / effector elements and management interactions.

Physical viewpoint^[4]

Data System view – Describes instruments, computers, and data storage components, their data system attributes and the communications connectors (busses, networks, point to point links) that are used in the system.
Telecomm view – Describes the telecomm components (antenna, transceiver), their attributes and their connectors (RF or optical links).
Navigation view – Describes the motion of the major elements within the system (trajectory, path, orbit), including their interaction with external elements and forces that are outside of the control of the system, but that must be modeled with it to understand system behavior (planets, asteroids, solar pressure, gravity)
Structural view – Describes the structural components in the system (s/c bus, struts, panels, articulation), their physical attributes and connectors, along with the relevant structural aspects of other components (mass, stiffness, attachment)
Thermal view – Describes the active and passive thermal components in the system (radiators, coolers, vents) and their connectors (physical and free space radiation) and attributes, along with the thermal properties of other components (i.e. antenna as sun shade)
Power view – Describes the active and passive power components in the system (solar panels, batteries, RTGs) within the system and their connectors, along with the power properties of other components (data system and propulsion elements as power sinks and structural panels as grounding plane)
Propulsion view – Describes the active and passive propulsion components in the system (thrusters, gyros, motors, wheels) within the system and their connectors, along with the propulsive properties of other components

Engineering viewpoint^[4]

Allocation view – Describes the allocation of functional objects to engineered physical and computational components within the system, permits analysis of performance and used to verify satisfaction of requirements
Software view - Describes the software engineering aspects of the system, software design and implementation of functionality within software components, select languages and libraries to be used, define APIs, do the engineering of abstract functional objects into tangible software elements. Some functional elements, described using a software language, may actually be implemented as hardware (FPGA, ASIC)
Hardware views – Describes the hardware engineering aspects of the system, hardware design, selection and implementation of all of the physical components to be assembled into the system. There may be many of these views, each specific to a different engineering discipline.
Communications Protocol view – Describes the end to end design of the communications protocols and related data transport and data management services, shows the protocol stacks as they are implemented on each of the physical components of the system.
Risk view – Describes the risks associated with the system design, processes, and technologies, assigns additional risk assessment attributes to other elements described in the architecture
Control Engineering view - Analyzes system from the perspective of its controllability, allocation of elements into system under control and control system
Integration and Test view – Looks at the system from the perspective of what must be done to assemble, integrate and test system and sub-systems, and assemblies. Includes verification of proper functionality, driven by scenarios, in satisfaction of requirements.
IV&V view – independent validation and verification of functionality and proper operation of the system in satisfaction of requirements. Does system as designed and developed meet goals and objectives.

Technology viewpoint^[4]

Standards view – Defines the standards to be adopted during design of the system (e.g. communication protocols, radiation tolerance, soldering). These are essentially constraints on the design and implementation processes.
Infrastructure view – Defines the infrastructure elements that are to support the engineering, design, and fabrication process. May include data system elements (design repositories, frameworks, tools, networks) and hardware elements (chip fabrication, thermal vacuum facility, machine shop, RF testing lab)
Technology Development & Assessment view – Includes description of technology development programs designed to produce algorithms or components that may be included in a system development project. Includes evaluation of properties of selected hardware and software components to determine if they are at a sufficient state of maturity to be adopted for the mission being designed.

In contrast to the previous listed view models, this "nominal set of views" lists a whole range of views, possible to develop powerful and extensible approaches for describing a general class of software intensive system architectures.^[4]

参照[編集]

この記事にはパブリックドメインである、アメリカ合衆国連邦政府が作成した次の文書本文を含む。アメリカ国立標準技術研究所.

^ ISO/IEC 42010:2007, Systems and Software Engineering -- Recommended practice for architectural description of software-intensive systems
^ ^a ^b ^c DoD Architecture Framework v1.5, Volume I
^ ^a ^b ^c ^d ^e ^f ^g Edward J. Barkmeyer ea (2003). Concepts for Automating Systems Integration NIST 2003.
^ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j ^k ^l Peter Shames, Joseph Skipper. "Toward a framework for modeling space systems architectures". NASA, JPL. 2006-06-19
^ Sinan Si Alhir (2003). "Understanding the Model Driven Architecture (MDA)". In: Methods & Tools. Fall 2003.
^ US Department of the Treasury Chief Information Officer Council (2000). Treasury Enterprise Architecture Framework Archived 2009年3月18日, at the Wayback Machine.. Version 1, July 2000.
^ IEEE-Std-1471-2000 Recommended Practice for Architectural Descriptions for Software-Intensive Systems, Institute for Electrics, NY, 2000.
^ IEEE-1471-2000
^ John Krogstie, (2003). Conceptual modeling,
^ Matthew West and Julian Fowler (1999). Developing High Quality Data Models Archived 2008年12月21日, at the Wayback Machine.. The European Process Industries STEP Technical Liaison Executive (EPISTLE).
^ STRAP SECTION 2 APPROACH. Retrieved 30 September 2008.
^ John F. Sowa (2004). [ "The Challenge of Knowledge Soup"]. published in: Research Trends in Science, Technology and Mathematics Education. Edited by J. Ramadas & S. Chunawala, Homi Bhabha Centre, Mumbai, 2006.
^ Gad Ariav & James Clifford (1986). New Directions for Database Systems: Revised Versions of the Papers. New York University Graduate School of Business Administration. Center for Research on Information Systems, 1986.
^ itl.nist.gov (1993) Integration Definition for Information Modeling (IDEFIX). 21 Dec 1993.
^ ^a ^b Kruchten, Philippe (1995, November). Architectural Blueprints — The “4+1” View Model of Software Architecture. IEEE Software 12 (6), pp. 42-50.
^ US Department of Veterans Affairs (2008) A Tutorial on the Zachman Architecture Framework. Accessed 06 Dec 2008.
^ A Comparison of the Top Four Enterprise Architecture Methodologies, Roger Sessions, Microsoft Developer Network Architecture Center,
^ Federal Enterprise Architecture Framework Archived 2012年2月13日, at the Wayback Machine.
^ ISO/IEC 10746-1:1998 Information technology – Open Distributed Processing: Reference Model – Part 1: Overview, International Organization for Standardization, Geneva, Switzerland, 1998.
^ ^a ^b DoD (2007) DoD Architecture Framework Version 1.5 Archived 2005年3月11日, at the Wayback Machine.. 23 April 2007
^ ^a ^b ^c ^d Federal Enterprise Architecture Program Management Office (2006). FEA Practice Guidance.
^ ^a ^b ^c Peter Shames & Joseph Skipper (2006). "Towards a Framework for Modeling Space Systems Architectures". 25 May 2006.