モデルを表示

システムエンジニアリング、ソフトウェアエンジニアリング、エンタープライズエンジニアリングにおけるビューモデルまたはビューポイントフレームワークは、システムアーキテクチャ、ソフトウェアアーキテクチャ、または エンタープライズアーキテクチャの構築に使用される一貫したビューのセットを定義するフレームワークです。ビューは、関連する一連の関心事の観点からシステム全体を表現したものです。^{[1] [2]}

1990 年代初頭から、システム アーキテクチャを記述および分析するためのアプローチを規定する取り組みが数多く行われてきました。これらの取り組みの結果、一連のビュー (または視点) が定義されました。これらは、アーキテクチャ フレームワークまたはエンタープライズ アーキテクチャ フレームワークと呼ばれることもありますが、通常は「ビュー モデル」と呼ばれます。

通常、ビューは、特定のシステムの特定のアーキテクチャ データを提示する作業成果物です。ただし、同じ用語が、特定の視点と、各具体的なビューを定義する対応するガイダンスを含むビュー定義を指すために使用されることもあります。ビュー モデルという用語は、ビュー定義に関連しています。

ビューと視点の目的は、人間が非常に複雑なシステムを理解し、問題と解決策の要素を専門分野を中心に整理し、関心事を分離できるようにすることです。物理的に集約的なシステムのエンジニアリングでは、視点はエンジニアリング組織内の能力と責任に対応することがよくあります。 ^[3]

複雑なシステムの仕様のほとんどは非常に広範囲にわたるため、仕様のすべての側面を完全に理解できる人間は一人もいません。さらに、特定のシステムに対する関心も、システムの仕様を調べる理由も人それぞれです。システムの構成に関して、経営幹部が尋ねる質問は、システム実装者とは異なるでしょう。したがって、ビューポイント フレームワークの概念は、利害関係者とのコミュニケーションを容易にするために、特定の複雑なシステムの仕様に個別のビューポイントを提供することです。各ビューポイントは、システムの特定の側面に関心を持つ対象者を満足させます。各ビューポイントは、そのビューポイントの対象者向けに語彙と表現を最適化する特定のビューポイント言語を使用できます。ビューポイント モデリングは、大規模な分散システムに固有の複雑さに対処するための効果的なアプローチとなっています。

IEEE Std 1471-2000で説明されているアーキテクチャ記述の実践では、複数のビューを使用して複数の懸念事項に対処し、各ビューはシステムの特定の側面に焦点を当てています。複数のビューを使用するアーキテクチャ フレームワークの例には、Kruchten の「4+1」ビュー モデル、Zachman Framework、TOGAF、DoDAF、RM-ODPなどがあります。

1970 年代には、ソフトウェア エンジニアリングにおいて、複数の視点でモデリングを行う手法が登場し始めました。Douglas T. Rossと KE Schoman は 1977 年に、システム要件定義におけるモデリング プロセスを体系化するために、コンテキスト、視点、および有利な点という構成要素を導入しました。^[4] Ross と Schoman によると、視点は「[モデルの] 全体的な目的を達成するためにどの側面が関連していると考えられるかを明確にし」、[モデル化されている主題] をどのように見るかを決定します。

この論文では、視点の例として、技術的視点、運用的視点、経済的視点を挙げています。1992 年に、Anthony Finkelsteinらは視点に関する非常に重要な論文を発表しました。^[5]その論文では、「視点は、開発プロセスにおける「アクター」、「知識源」、「役割」または「エージェント」という概念と、アクターが維持する「ビュー」または「パースペクティブ」という概念を組み合わせたものと考えることができます。」と述べています。この論文の重要な概念は、「表現スタイル (視点が見えるものを表現するためのスキームと表記法)」と「仕様 (特定のドメインを記述する視点のスタイルで表現されたステートメント)」を区別することでした。IEEE 1471などの後続の作業では、それぞれ「視点」と「ビュー」という 2 つの別個の用語を使用することで、この区別が維持されました 。

1990 年代初頭から、システム アーキテクチャを記述および分析するためのアプローチを体系化する取り組みが数多く行われてきました。これらは、アーキテクチャ フレームワーク、またはビューポイント セットと呼ばれることもあります。これらの多くは米国国防総省によって資金提供されていますが、一部はISOやIEEEにおける国際的または国内的な取り組みから生まれました。これらの中で、IEEE のソフトウェア集約型システムのアーキテクチャ記述に関する推奨プラクティス ( IEEE Std 1471-2000 ) は、ビューポイント、視点、利害関係者、および懸念の有用な定義と、利害関係者の懸念に対処するためにビューポイントを適用することにより、複数のビューを使用してシステム アーキテクチャを文書化するためのガイドラインを確立しました。[6] 複数のビューの利点は、隠れた要件や利害関係者の意見の不一致^をより簡単に発見できることです。ただし、実際には、複数のビューを調整する複雑さが増すため、この利点が損なわれる可能性があることが研究で示されています。^[7]

IEEE 1471（現在のISO/IEC/IEEE 42010:2011、システムおよびソフトウェア エンジニアリング - アーキテクチャ記述）は、アーキテクチャ記述の内容を規定し、前例のない設計、進化的設計、既存システムの設計のキャプチャなど、いくつかのシナリオでの作成と使用について説明します。これらすべてのシナリオで、全体的なプロセスは同じです。つまり、利害関係者を特定し、懸念事項を引き出し、使用する一連の視点を特定し、これらの視点の仕様を適用して、対象のシステムに関連する一連のビューを開発します。特定の視点のセットを定義するのではなく、この規格は、設計者と組織が独自の視点を定義するための統一されたメカニズムと要件を提供します。1996 年には、大規模分散システムのアーキテクチャと設計を記述するための便利なフレームワークを提供するために、オープン分散処理の ISO 参照モデル（RM-ODP）が公開されました。

システムのビューとは、ある視点から見たシステムの表現である。このシステムの視点には、システムに関する特定の懸念事項に焦点を当てた視点が含まれており、詳細を省略して、視点の懸念事項に関連する要素のみを含む簡略化されたモデルが提供される。たとえば、セキュリティの視点はセキュリティ上の懸念事項に焦点を当てており、セキュリティの視点モデルには、システムのより一般的なモデルからのセキュリティに関連する要素が含まれている。^[8]

ビューを使用すると、ユーザーは特定の関心領域の一部を調べることができます。たとえば、情報ビューでは、特定の情報を使用するすべての機能、組織、テクノロジなどを表示できますが、組織ビューでは、特定の組織に関連するすべての機能、テクノロジ、情報を表示できます。ザックマン フレームワークでは、ビューは作業成果物のグループで構成されます。ビューは、企業の「何を」、「どのように」、「誰が」、「どこで」、「いつ」、「なぜ」に焦点を当てているため、開発には特定の分析および技術の専門知識が必要です。たとえば、機能ビューの作業成果物は、「ミッションはどのように実行されるか」という質問に答えます。機能ビューの作業成果物は、プロセスおよびアクティビティ モデリングを使用して機能分解の専門家によって最も簡単に開発されます。ビューは、機能の観点から企業を示します。また、組織および情報コンポーネントを示すこともできますが、機能に関連する場合のみです。^[9]

システム工学において、視点とはシステム内の関心事を区分または制限することです。視点を採用することで、それらの側面における問題を個別に対処することができます。また、視点を適切に選択することで、システムの設計を特定の専門分野に分割することもできます。^[3]

ビューポイントは、ビューを構築、提示、分析するための規則、ルール、言語を提供します。ISO/IEC 42010:2007 ( IEEE-Std-1471-2000 ) では、ビューポイントは個々のビューの仕様です。ビューは、ビューポイントの観点から見たシステム全体の表現です。ビューは、1 つ以上のアーキテクチャ モデルで構成されます。^[10]このような各アーキテクチャ モデルは、関連するアーキテクチャ システムによって確立された方法と、システム全体によって確立された方法を使用して開発されます。 ^[6]

モデリングの観点は、システムの事前に選択された側面を表現するための一連の異なる方法です。各観点は、モデルが表現するものに対する焦点、概念化、専念、視覚化が異なります。

情報システムでは、モデリングの観点を構造的、機能的、行動的/プロセス的観点に分けるのが伝統的な方法です。これは、ルール、オブジェクト、コミュニケーション、アクターとロールの観点とともに、モデリングアプローチを分類する方法の1つです^[11]

任意の視点において、その視点から見えるオブジェクトのみを含むシステムのモデルを作成することができますが、そのモデルにはシステム内に存在し、その視点に関連するすべてのオブジェクト、関係、制約も含まれています。このようなモデルは、視点モデル、またはその視点からのシステムのビューと呼ばれます。^[3]

与えられたビューは、与えられた視点から特定の抽象レベルでシステムに対する仕様です。異なる抽象レベルには異なるレベルの詳細が含まれます。高レベルのビューにより、エンジニアは設計全体を設計・理解し、大きな問題を特定して解決することができます。低レベルのビューにより、エンジニアは設計の一部に集中し、詳細な仕様を開発することができます。^[3]

しかし、システム自体では、さまざまな視点モデルに現れる仕様はすべて、システムの実現されたコンポーネントで対処されなければなりません。また、任意のコンポーネントの仕様は、さまざまな視点から引き出される可能性があります。一方、特定のコンポーネントへの機能の分散とコンポーネントの相互作用によって誘導される仕様は、通常、元の視点に反映されたものとは異なる関心の分割を反映します。したがって、個々のコンポーネントの関心とシステムのボトムアップ合成に対処する追加の視点も役立つ場合があります。^[3]

アーキテクチャ記述とは、システム アーキテクチャを、その構成要素、それらの構成要素の機能、それらの構成要素が機能する際のルールと制約、それらの構成要素が互いに、また環境とどのように関係しているかという観点から表現したものです。アーキテクチャ記述では、アーキテクチャ データは複数のビューと製品間で共有されます。

データ レイヤーには、アーキテクチャ データ要素と、それらの定義属性および関係があります。プレゼンテーション レイヤーには、アーキテクチャの目的、アーキテクチャの説明、および実行されたさまざまなアーキテクチャ分析を視覚的に伝達および理解するための手段をサポートする製品とビューがあります。製品は、アーキテクチャ データをグラフィカル、表形式、またはテキスト表現として視覚化する方法を提供します。ビューは、製品全体にわたるアーキテクチャ データを視覚化し、アーキテクチャの特定の観点または全体的な観点に合わせてデータを論理的に整理する機能を提供します。

1977年に導入されたデータモデリングのための3スキーマアプローチは、最初のビューモデルの1つと考えることができます。これは、データ統合を実現するための鍵として概念モデルを推進する、情報システムとシステム情報管理を構築するためのアプローチです。^[13] 3スキーマアプローチでは、3つのスキーマとビューを定義します。

• ユーザービューの外部スキーマ
• 概念スキーマは外部スキーマを統合する
• 物理的なストレージ構造を定義する内部スキーマ

中心となる概念スキーマは、ユーザーが考え、話す概念のオントロジーを定義します。物理スキーマは、データベースに格納されているデータの内部形式を記述し、外部スキーマはアプリケーションプログラムに提示されるデータのビューを定義します。^[14]このフレームワークは、外部スキーマに複数のデータモデルを使用できるようにしようとしました。^[15]

長年にわたり、情報システムの構築に関するスキルと関心は飛躍的に高まってきました。しかし、システム構築の従来のアプローチは、ほとんどの場合、 「ユーザー ビュー」と「コンピューター ビュー」という 2 つの異なるビューからデータを定義することにのみ焦点を当ててきました。ユーザー ビュー (「外部スキーマ」と呼ばれる) からのデータの定義は、個人が特定の仕事をするのに役立つように設計されたレポートと画面のコンテキストで行われます。使用状況ビューからのデータに必要な構造は、ビジネス環境とユーザーの個々の好みによって変わります。コンピューター ビュー (「内部スキーマ」と呼ばれる) からのデータの定義は、保存と検索のためのファイル構造の観点から行われます。コンピューター ストレージに必要なデータ構造は、採用されている特定のコンピューター技術と、データの効率的な処理の必要性によって異なります。^[16]

4+1は、複数の同時ビューの使用に基づいてソフトウェア集約型システムのアーキテクチャを記述するために、1995年にフィリップ・クルヒテンによって設計されたビューモデルです。 ^[17]ビューは、エンドユーザー、開発者、プロジェクトマネージャーなどのさまざまな利害関係者の観点からシステムを記述するために使用されます。モデルの4つのビューは、論理ビュー、開発ビュー、プロセスビュー、物理ビューです。

モデルの 4 つのビューは次の点に関係します。

• 論理ビュー: システムがエンドユーザーに提供する機能に関係します。
• 開発ビュー: プログラマーの観点からシステムを示し、ソフトウェア管理に関係します。
• プロセス ビュー: システムの動的な側面を扱い、システム プロセスとそれらの通信方法を説明し、システムの実行時の動作に焦点を当てます。
• 物理ビュー: システム エンジニアの観点からシステムを描写します。物理層上のソフトウェア コンポーネントのトポロジと、これらのコンポーネント間の通信に関係します。

さらに、選択されたユースケースやシナリオがアーキテクチャを説明するために利用されます。したがって、モデルには4+1のビューが含まれます。^[17]

エンタープライズ アーキテクチャ フレームワークは、エンタープライズ アーキテクチャに関連付けられた構造とビューを編成する方法を定義します。エンタープライズ アーキテクチャとエンジニアリングの分野は非常に広範囲であり、企業は大規模で複雑になる可能性があるため、この分野に関連付けられたモデルも大規模で複雑になる傾向があります。この規模と複雑さを管理するために、アーキテクチャ フレームワークは、タスクに焦点を当て、最も必要なときに貴重な成果物を作成できるようにするツールと方法を提供します。

アーキテクチャ フレームワークは、情報技術と情報システムガバナンスでよく使用されます。組織では、システム設計が承認される前に特定のモデルを作成することを義務付ける場合があります。同様に、調達システムのドキュメントで使用する特定のビューを指定する場合もあります。米国国防総省は、一定額を超える資本プロジェクトに対して、機器サプライヤーが特定の DoDAF ビューを提供するよう規定しています。

Zachman Framework は、 1987 年に IBM のJohn Zachmanによって考案されたエンタープライズ アーキテクチャのフレームワークであり、エンタープライズを表示および定義するための正式かつ高度に構造化された方法を提供します。

フレームワークは、アーティファクトの対象者（ビジネスオーナーやビルダーなど）と対処する特定の問題（データや機能など）の両方を考慮した方法で、アーキテクチャの「アーティファクト」を整理するために使用されます。これらのアーティファクトには、設計ドキュメント、仕様、モデルなどが含まれます。^[19]

ザックマンフレームワークは、エンタープライズアーキテクチャの基本要素を表現するための標準的なアプローチとしてよく参照されます。ザックマンフレームワークは、米国連邦政府によって「企業およびそれをサポートするシステムの変更を管理するための統合フレームワークとして世界中で受け入れられている」と認められています。^[20]

国際標準化機構（ISO）のオープン分散処理参照モデル（RM-ODP）^[21]は、分散ソフトウェア/ハードウェアシステムの設計を分割するための一連の視点を規定しています。ほとんどの統合問題は、このようなシステムの設計または非常に類似した状況で発生するため、これらの視点は統合の問題を分離するのに役立つ可能性があります。RMODPの視点は次のとおりです。^[3]

• 企業の視点。これは、組織のビジネス目標とビジネスプロセスに関連するシステムの目的と動作に関係します。
• 情報観点。システムによって処理される情報の性質と、その情報の使用と解釈に対する制約に関係する。
• 計算論的観点では、システムを特定の動作を示し、インターフェースで相互作用する一連のコンポーネントに機能的に分解することに関心がある。
• 工学的観点。計算コンポーネントの相互作用をサポートするために必要なメカニズムと機能に関係する。
• 技術観点。システムの実装、特にコンポーネント間の通信のための技術の明確な選択に関係する。

RMODPはさらに、設計に視点間の一貫性の仕様を含める必要があることを定義しています。^[3]

• 情報単位を定義する際にエンタープライズオブジェクトとプロセスを使用する
• 計算コンポーネントの動作を指定するためのエンタープライズオブジェクトと動作の使用、および計算インターフェースを定義するための情報ユニットの使用
• エンジニアリングの選択と計算インターフェースおよび動作要件との関連
• 選択された技術における情報、計算、エンジニアリングの要件の満足

国防総省アーキテクチャ フレームワーク(DoDAF) は、エンタープライズ アーキテクチャ(EA) またはシステム アーキテクチャを補完的で一貫性のあるビューに編成する標準的な方法を定義します。これは、複雑な統合と相互運用性の課題を抱える大規模システムに特に適しており、開発中のシステムが動作する外部顧客の運用ドメインを詳細に示す「運用ビュー」の使用が明らかに独特です。

DoDAF は、アーキテクチャ記述の広範な範囲と複雑さをグラフィック、表、またはテキストの手段で視覚化し、理解し、統合するためのメカニズムとして機能する一連の製品を定義します。これらの製品は、次の 4 つのビューに分類されます。

• 包括的な全体ビュー（AV）、
• 運用ビュー（OV）、
• システムビュー（SV）と
• 技術標準ビュー（TV）。

各ビューは、以下に説明するように、アーキテクチャの特定の観点を表しています。通常、各システム開発では、完全な DoDAF ビューセットのサブセットのみが作成されます。この図は、運用ビュー、システムとサービスのビュー、技術標準ビューをリンクする情報を表しています。共通のアーキテクチャデータ要素によって駆動される 3 つのビューとそれらの相互関係は、相互運用性やパフォーマンスなどの指標を導き出すための基礎となり、これらの指標の値が運用上のミッションとタスクの有効性に与える影響を測定するための基礎となります。^[22]

米国連邦エンタープライズアーキテクチャでは、エンタープライズ、セグメント、ソリューションアーキテクチャは、詳細レベルを変え、関連性はあるものの異なる懸念に対処することで、異なるビジネス観点を提供します。エンタープライズ自体が階層的に構成されているのと同様に、各タイプのアーキテクチャによって提供されるさまざまなビューも同様です。連邦エンタープライズアーキテクチャ実践ガイダンス（2006）では、3つのタイプのアーキテクチャを定義しています。^[23]

• エンタープライズアーキテクチャ、
• セグメントアーキテクチャ、および
• ソリューション アーキテクチャ。

定義上、エンタープライズ アーキテクチャ (EA) は、基本的に共通または共有の資産 (戦略、ビジネス プロセス、投資、データ、システム、テクノロジーなど) を特定することに関係しています。EA は戦略によって推進され、機関がそのリソースが機関の使命と戦略目標および目的に適切に適合しているかどうかを特定するのに役立ちます。投資の観点から見ると、EA は IT 投資ポートフォリオ全体に関する決定を推進するために使用されます。したがって、EA の主な利害関係者は、機関が可能な限り効果的かつ効率的に使命を果たすことを任務とする上級管理職と幹部です。^[23]

対照的に、セグメント アーキテクチャは、コア ミッション領域、ビジネス サービス、またはエンタープライズ サービスのシンプルなロードマップを定義します。セグメント アーキテクチャはビジネス管理によって推進され、市民や機関のスタッフへのサービスの提供を改善する製品を提供します。投資の観点から見ると、セグメント アーキテクチャは、コア ミッション領域または共通または共有サービスをサポートするビジネス ケースまたはビジネス ケースのグループに関する決定を推進します。セグメント アーキテクチャの主な利害関係者は、ビジネス オーナーとマネージャーです。セグメント アーキテクチャは、構造、再利用、調整という 3 つの原則を通じて EA と関連しています。まず、セグメント アーキテクチャは EA で使用されるフレームワークを継承しますが、コア ミッション領域または共通または共有サービスの特定のニーズを満たすために拡張および特化される場合があります。次に、セグメント アーキテクチャは、データ、共通のビジネス プロセスと投資、アプリケーションとテクノロジなど、エンタープライズ レベルで定義された重要な資産を再利用します。3 番目に、セグメント アーキテクチャは、ビジネス戦略、義務、標準、パフォーマンス測定などのエンタープライズ レベルで定義された要素と一致します。^[23]

「宇宙システムアーキテクチャのモデリングフレームワーク」を求めて、ピーター・シェイムズとジョセフ・スキッパー（2006）は「名目上のビューセット」を定義しました。^[6] CCSDS RASDS、RM-ODP、ISO 10746から派生し、IEEE 1471に準拠しています。

以下に説明するように、この「ビューのセット」は、可能なモデリングの視点のリストです。これらのビューのすべてを 1 つのプロジェクトに使用することはできず、必要に応じて他のビューを定義できます。一部の分析では、複数の視点からの要素が、階層化された表現を使用して新しいビューに結合される場合があることに注意してください。

後のプレゼンテーションでは、この名目上のビューセットは、拡張RASDSセマンティック情報モデル導出として発表されました。^[24]ここで、RASDSは宇宙データシステムの参照アーキテクチャの略です。2番目の画像を参照してください。

企業の視点^[6]

• 組織ビュー –組織要素とその構造および関係が含まれます。契約、契約書、ポリシー、組織間のやり取りが含まれる場合があります。
• 要件ビュー –システムを動かす要件、目標、目的を説明します。システムが実行できなければならないことを説明します。
• シナリオ ビュー – システムの想定される使用方法を説明します (シナリオ プランニングを参照)。ユーザーのビューと、システムが想定される動作の説明が含まれます。

情報の観点^[6]

• メタモデル ビュー –情報モデル要素とその構造および関係を定義する抽象ビュー。システムとデータ アーキテクチャによって作成および管理されるデータのクラスを定義します。
• 情報ビュー –システム内で実現および操作される実際のデータと情報を説明します。データ要素はメタモデル ビューによって定義され、他のビューの機能オブジェクトによって参照されます。

機能的観点^[6]

• 機能データフロー ビュー – システム内の機能要素、それらの相互作用、動作、提供されるサービス、制約、およびそれらの間のデータ フローを説明する抽象ビュー。これらの機能が実際にどのように実装されているかに関係なく、システムが実行できる機能を定義します。
• 機能制御ビュー –システム内の機能要素間の制御フローと相互作用を説明します。全体的なシステム制御相互作用、制御要素とセンサー/エフェクター要素間の相互作用、および管理相互作用が含まれます。

物理的な観点^[6]

• データ システム ビュー – システムで使用される機器、コンピューター、データ ストレージ コンポーネント、それらのデータ システム属性、および通信コネクタ (バス、ネットワーク、ポイント ツー ポイント リンク) について説明します。
• テレコム ビュー – テレコム コンポーネント (アンテナ、トランシーバー)、それらの属性、およびコネクタ (RF または光リンク) について説明します。
• ナビゲーション ビュー – システム内の主要要素の動き (軌道、経路、軌道) を説明します。これには、システムの制御外にある外部要素や力との相互作用が含まれますが、システムの動作を理解するためにモデル化する必要があります (惑星、小惑星、太陽の圧力、重力)。
• 構造ビュー – システム内の構造コンポーネント (s/c バス、ストラット、パネル、関節)、それらの物理的属性とコネクタ、および他のコンポーネントの関連する構造的側面 (質量、剛性、アタッチメント) について説明します。
• 熱ビュー – システム内のアクティブおよびパッシブ熱コンポーネント (ラジエーター、クーラー、通気口) とそれらのコネクタ (物理的および自由空間放射) および属性、および他のコンポーネント (例: サンシェードとしてのアンテナ) の熱特性について説明します。
• 電力ビュー – システム内のアクティブおよびパッシブ電力コンポーネント (ソーラーパネル、バッテリー、RTG) とそのコネクタ、および他のコンポーネント (電力シンクとしてのデータ システムと推進要素、接地面としての構造パネル) の電力特性について説明します。
• 推進ビュー – システム内のアクティブおよびパッシブ推進コンポーネント（スラスタ、ジャイロ、モーター、ホイール）とそのコネクタ、および他のコンポーネントの推進特性について説明します。

エンジニアリングの観点^[6]

• 割り当てビュー – システム内の設計された物理コンポーネントと計算コンポーネントへの機能オブジェクトの割り当てを記述し、パフォーマンスの分析を可能にし、要件の満足度を確認するために使用されます。
• ソフトウェア ビュー - システムのソフトウェア エンジニアリングの側面、ソフトウェア設計、ソフトウェア コンポーネント内の機能の実装、使用する言語とライブラリの選択、API の定義、抽象的な機能オブジェクトの具体的なソフトウェア要素へのエンジニアリングについて説明します。ソフトウェア言語を使用して記述された一部の機能要素は、実際にはハードウェア (FPGA、ASIC) として実装される場合があります。
• ハードウェア ビュー – システムのハードウェア エンジニアリングの側面、ハードウェア設計、システムに組み込むすべての物理コンポーネントの選択と実装について説明します。これらのビューは多数存在し、それぞれが異なるエンジニアリング分野に固有のものです。
• 通信プロトコル ビュー – 通信プロトコルと関連するデータ転送およびデータ管理サービスのエンドツーエンドの設計について説明し、システムの各物理コンポーネントに実装されているプロトコル スタックを表示します。
• リスクビュー – システム設計、プロセス、テクノロジーに関連するリスクを説明し、アーキテクチャで説明されている他の要素に追加のリスク評価属性を割り当てます。
• 制御工学の視点 - 制御可能性、制御対象システムへの要素の割り当て、制御システムの観点からシステムを分析します。
• 統合とテストの視点 – システムとサブシステム、およびアセンブリを組み立て、統合、テストするために何を行う必要があるかという観点からシステムを検討します。要件を満たすために、シナリオに基づいて適切な機能が検証されることが含まれます。
• IV&V ビュー – 要件を満たすシステムの機能性と適切な動作の独立した検証と確認。設計および開発されたシステムは目標と目的を満たしていますか。

技術的観点^[6]

• 標準ビュー – システムの設計時に採用する標準を定義します (例: 通信プロトコル、放射線耐性、はんだ付け)。これらは基本的に、設計および実装プロセスに対する制約です。
• インフラストラクチャ ビュー – エンジニアリング、設計、製造プロセスをサポートするインフラストラクチャ要素を定義します。データ システム要素 (設計リポジトリ、フレームワーク、ツール、ネットワーク) とハードウェア要素 (チップ製造、熱真空施設、機械工場、RF テスト ラボ) が含まれる場合があります。
• 技術開発と評価ビュー – システム開発プロジェクトに含まれる可能性のあるアルゴリズムまたはコンポーネントを作成するために設計された技術開発プログラムの説明が含まれます。選択されたハードウェアおよびソフトウェア コンポーネントの特性を評価し、設計中のミッションに採用できるほど十分に成熟しているかどうかを判断します。

前にリストしたビューモデルとは対照的に、この「名目上のビューセット」には、ソフトウェア集約型システムアーキテクチャの一般的なクラスを記述するための強力で拡張可能なアプローチを開発できるさまざまなビューがリストされています。^[6]

• エンタープライズアーキテクチャフレームワーク
• 組織アーキテクチャ
• ソフトウェア開発方法論
• 財務エンタープライズアーキテクチャフレームワーク
• トガフ
• ザックマンフレームワーク
• オントロジー（情報科学）
• 知識の獲得

帰属

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

• ウィキメディア・コモンズのビューモデルに関連するメディア