システム工学、ソフトウエア工学、及び事業体工学におけるビュー・モデル（）またはビューポイント・フレームワークは、システムアーキテクチャ、ソフトウェアアーキテクチャ、あるいはエンタープライズアーキテクチャの構築で使われる"ビュー"の整然としたセットを定義する一つのフレームワークである。"ビュー"は関係する関心事のセットの観点からのシステム全体の一つの表現である。ビュー・モデルはアーキテクチャの構築、分類、及び組織化にためのガイダンスとルールを提供する。1990年代初期から、システムアーキテクチャを記述し分析するための標準アプローチを定義する幾つかの努力が行われた。最近のエンタープライズアーキテクチャフレームワークのそれぞれは、ビューのセットを定義したが、しかしこれらのセットが常に『ビュー・モデル』と呼ばれるわけではない。普通一つのビューは、与件のシステムのためのアーキテクチャデータの特定セットを表す非常に具体的なプロダクトである。しかしながら、同じ用語は時々、各具体的ビューを定義する特定ビューポイントと対応するガイダンスを含む、ビュー"定義"を参照するのに使われる。用語"ビュー・モデル"は、ビュー定義に関係する。ビューポイント及びビューの目的は、複雑システムを人間の技術者に理解を可能にさせ、そして専門的知識ドメインを取り巻く問題と解決策の要素を編成することである。物理集約的システムにおけるエンジニアリングではビューポイントは、しばしばエンジニアリング組織内の能力と責任に対応する。ほとんどの複雑システムの仕様は、一個人では仕様のすべてを完全に理解できないほど大規模である。更に、我々はそれぞれ、与件システムに異なった関心を持ち、システムの仕様を試す異なった理由を持っている。事業の執行者は、システムの実装者よりシステムを作り上げるための異なった質問を問いかける。ビューポイントフレームワークの概念は、その利害関係者とのコミュニケーションを円滑にするため、与件の複雑システムの仕様に別々のビューポイントを提供することである。各ビューポイントは、システムの特定の局面のセットに関心を持つ聴衆を満足させる。各ビューポイントは、そのビューポイントの聴衆のため、語彙と表現を最適化する特定な"ビューポイント言語"を利用し得る。ビューポイントモデリングは、大きな分散システム本来の複雑性を取り扱うための有効なアプローチになった。現在のソフトウエアアーキテクチャ的実践は、IEEE 1471に記述されている様に、それぞれがシステムの特定局面に焦点を当てる、幾つかの関心領域に設計活動を分ける。例には、、Zachmanフレームワーク、TOGAF、、及びを含む。1990年代初期から、システムアーキテクチャを記述し分析するための標準的アプローチを定義しようとする幾つかの試みがあった。これらの多くは、米国防省によって資金が提供されたが、幾つかはISOあるいはIEEEにおける国際的及び国家的取組みから生まれた。これらの内最も適切な、ソフトウエア集約システムのアーキテクチャ記述のための推奨されるプラクティス（IEEE 1471）は、システムアーキテクチャが何であるかや、(stakeholder concerns)を取り扱うためビューポイント仕様を使うのにたいへん有用な定義とガイドラインを提供する。IEEE 1471仕様は、設計の前後関係、進化的な設計、及び既存システムの設計の獲得等を含む、多数のシナリオの元でアーキテクチャの記述を開発するためのプロセスを記述する。これらのシナリオの全てにおいて、全体的プロセスは同じである：利害関係者を識別する、関心事を引き出す、使われるべきビューポイントのセットを識別する、そしてその後、システムの適切なビューのセットを開発するのにこれらのビューポイント仕様を適用する。IEEE 1471 は、定義するシステム、（他との間の）機能的及び技術的なビューには言及していないが、それは、ビューのあらゆる特定セットを定義するほど遠くなく、またそれが何をするか判らないほど遠くない。結局1996年に、RM-ODPのためのISO参照モデルが、大規模分散システムのアーキテクチャの記述と設計のための有用なフレームワーク提供して発行された。システムの一つのビューは、一つのビューポイント（視点）の観点からのシステムの一つの表現である。システムのこの視点は、その視点の関心事に関係する要素のみを持つ単純化されたモデルを提供し詳細を抑制する、そのシステムに関する特定な関心に焦点を当てた一つの観点を伴う。例えば、セキュリティの視点はセキュリティの関心に焦点を当て、セキュリティ視点のモデルは、システムのより一般的モデルからセキュリティに関係するそれらの要素を含む。一つのビューは、ユーザーに特定な関心領域の部分を調べることを許す。例えば、組織ビューが特定組織に該当する全ての機能、技術、及び情報を表現する一方で、一つの情報ビューは、特定な情報の断片を利用する、全ての機能、組織、秘術などを表現するかもしれない。Zachmanフレームワークにおけるビューは、その開発が、事業体の『何を』、『如何に』『誰が』、『何処で』、『何時』、あるいは『なぜ』のいずれかに焦点を当てることから、特定の分析と技術的専門性を要求する作業プロダクトのグループを構成する。例えば、機能的ビューの作業プロダクトは、『どのようにミッションが遂行されるか？』の質問に答える。それらはプロセスとアクティビティ・モデリングで使ったにおけるエキスパートによって最も容易に開発される。それらは、機能のビューポイントから事業体を示す。それらはまた組織的あるいは情報的構成要素も示すかもしれないが、それらは機能との関係としてのみ示される。視点は、特定な関心事のセットに限定するシステムにおける区画化を記述する、一つのシステム工学の概念である。一つの視点の適用は、それらの局面における課題が別々に取り扱われ得るため有用である。視点をうまく選定すれば、システムの設計を専門的な特定領域に区分できる。視点は、ビューを構築し、表現し、そして分析するための慣習、ルール、及び言語を提供する。ISO/IEC 42010:2007 (IEEE 1471)における一つの視点は、ここのビューのための一つの仕様である。一つのビューは、一つの観点からシステム全体の一つの表現である。一つのビューは、一つ以上のから構成され得る。Each such architectural model is developed using the methods established by its associated architectural system, as well as for the system as a whole.は、システムの事前に選ばれた局面を表現する異なる方法のセットである。各観点は、何をモデルが表現するかの、異なる焦点、概念化、専念化、及び可視化を持つ。情報システムにおいて、モデリングの観点を分割する典型的な方法は、構造的、機能的、及び振舞的／順序的観点を区別することである。ルール、オブジェクト、コミュニケーション、及びアクターや役割の観点を伴うこれは、モデリングのアプローチの分類の一つの方法である。与えられたどんな視点でも、その視点から視認されるオブジェクトだけを含む、システムの一つのモデルを作ることができるが、そのシステムにおいて表されかつその視点に適切な、そのオブジェクト、関係、及び制約の全ての獲得もできる。そのようなモデルが、ビューポイント・モデル、あるいはその視点からのシステムのビューと言われる。与件のビューは、与えられた視点から特定の抽象レベルでのそのシステムのための仕様である。異なる抽象レベルは、詳細な異なるレベルを含む。より高いレベルのビューにより、エンジニアは設計全体を作りかつ理解することと、大きな問題を識別し解決することが可能になる。より低いレベルのビューは、エンジニアに設計の一部を具体化し、詳細な仕様を開発することを可能にする。しかし、システムそれ自身において、種々のビューポイント・モデルに現れる仕様の全ては、そのシステムの実現化される構成要素で取り扱われなければならない。そして、あらゆる与件の構成要素の仕様は、多くの異なる視点から描くことができる。一方で、特定の構成要素と構成要素の相互作用を超えた機能分散によって誘発された仕様は、典型的にオリジナルの視点を反映したより関心の異なる区分を反映され得る。そこで、個別の構成要素の関心とシステムのボトムアップな合成を取り扱う、追加の視点が有用であり得る。一つのアーキテクチャ記述は、いつでも、その構成要素部分に関して、どのようにその部分が機能し、それらの部分がどんなルールや制約の下で機能し、どのようにそれらの部分がお互い及びその環境と関係するかについての、システムアーキテクチャの一つの表現である。アーキテクチャ記述におおける"アーキテクチャデータ"は、複数のビュー及びプロダクトを横切って共有される。データでのレイヤーは、アーキテクチャデータ要素とそれらの属性及び関係である。表現でのレイヤーは、それが何を記述し、様々なアーキテクチャ分析を実施する、そのアーキテクチャの目的を伝達し理解する視覚手段を支援するプロダクトとビューである。プロダクトは、図式、表形式、あるいは文章的な表現としてアーキテクチャデータを視覚化する一つの方法を提供する。ビューは、プロダクトを横断することなくアーキテクチャデータを視覚化し、アーキテクチャの特定または全体的観点のためデータを論理的に組織化する能力を提供する。データ・モデリングのは、1977年に登場した最初のビュー・モデルの一つと考えられる。それは、を達成する鍵としてを促進する、情報システムとシステム情報管理を構築する一つのアプローチである。3層スキーマ・アプローチは、3つのスキーマとビューを定義する：中心で、概念的スキーマは、ユーザーが考えそして会話するように、概念のオントロジーを定義する。物理的スキーマは、データベースに格納されるデータの内部的フォーマットを記述し、外部スキーマは、アプリケーションソフトウェアに表されるデータのビューを定義する。そのフレームワークは、外部スキーマのため使われるべき複数のデータ・モデルを許そうと試みた。数年を経て、情報システムの構築における技能と関心はとてつもなく成長した。しかしながら、ほとんどの部分でシステム構築への伝統的アプローチは、『ユーザー・ビュー』と『コンピュータ・ビュー』の、2つの個別のビューからデータを定義することにだけ焦点を当てた。『外部スキーマ』として参照される、ユーザー・ビューからのデータ定義は、報告書あるいは各個人が彼らのジョブを行うのを支援するため設計される画面の文脈である。用途ビューから要求されるデータ構造は、事業環境やユーザー個々の好みで変化する。『内部スキーマ』として参照されるコンピュータ・ビューからのデータは、格納と読出のためのファイル構造の基準で定義される。コンピュータ・ストレージのため要求されるデータ構造は、採用される特定のコンピュータ技術と効率的なデータ処理へのニーズに依存する。は、1995年にによって設計された一つのビュー・モデルである。そのビューは、エンドユーザー、開発者、あるいはプロジェクト・マネージャのような、異なる利害関係者の視点でシステムを記述するため使われる。モデルの4つのビューは、論理、開発、プロセス、及び物理的ビューである。モデルの4つのビューは以下に係わる：加えて、選ばれたユースケースまたはシナリオが、そのシステムを描き出すため利用される。そこでモデルは4+1ビューを包含する。エンタープライズアーキテクチャフレームワークは、エンタープライズアーキテクチャに関連する、構造とビューをどのように組織化するかを定義する。エンタープライズアーキテクチャとエンジニアリングの規律があまりにも広く、かつ事業体は大規模かつ複雑になり得ることから、その規律に関連するモデルも大規模かつ複雑となる傾向がある。このスケールと複雑さを管理するためアーキテクチャフレームワークは、彼らが最も必要なときにタスクを焦点に持ち込みそして価値ある生成物を作成できるようにする、ツールや手法を提供する。アーキテクチャフレームワークは、情報技術と情報システムの統治で一般に使われる。組織は、あるシステム設計が承認される前に、明確なモデルを作成することを望む。同様に、彼らは、調達されるシステムのドキュメントに使われるべき明確なビューの特定を望む。米国防省は、一定規模以上の投資プロジェクトの装置サプライヤによって提供されるDoDAF特定のビューを規定する。1987年にIBMでによって最初に提唱された、Zachmanフレームワークは、事業体を眺めそして定義する公式かつ高度に構造化された方法を提供する、事業体アーキテクチャのための一つのフレームワークである。そのフレームワークは、生成物がターゲットとするのは誰か（例えば、事業オーナー、構築者）と扱われる特定の課題は何か（例えば、データや機能性）の両方を考慮に入れる一つの方法で、アーキテクチャの『生成物』を組織化するため使われる。これらの生成物は、設計ドキュメント、仕様、及びモデルを含みえる。Zachmanフレームワークは、しばしばエンタープライズアーキテクチャの基本要素を表すための標準アプローチとして参照される。Zachmanフレームワークは、米連邦政府によって『事業体における変更を管理しそれらを支援するシステムの統合化されたフレームワークとして世界的に受容れられている』と認められた。のための国際標準化機構（ISO）参照モデルは、分散化されたソフトウエア／ハードウエア・システムの設計を区分するためのビューポイント（視点）のセットを規定する。ほとんどの統合化課題はそのようなシステム、または類似の状況の設計に現れ、これらの視点は統合の関心から分離するのに有用であると証明しえる。RM-ODP視点とは：RMODPは更に、以下を含む視点間の整合した仕様を含める設計への要求を定義する：（国防省アーキテクチャフレームワーク）は、エンタープライズアーキテクチャまたはシステムアーキテクチャを補完し、一貫したビューに組織化する標準の方法を定義する。それは、複雑な統合と相互運用性へ挑戦する大規模システムに適しており、そして開発するシステムが運用する外部顧客の運用ドメインを詳細化する、その『運用ビュー』の利用で明らかにユニークである。DoDAFは、図式、表形式、あるいは文章手段を通してアーキテクチャ記述の広いスコープと複雑さを可視化させ、理解させ、そして同化させるためのメカニズムとして演じるプロダクトのセットを定義する。これらのプロダクトは以下の4つのビューで組織化される： 各ビューは、下記に述べられるようなアーキテクチャの一定の観点を描く。完全なDoDAのビューセットのサブセットは各システム開発のため普通に創作される。図は、システムとサービス・ビュー及び技術ビューをつなぐ情報を表現する。その3つのビューと相互関係は、相互運用性や性能のような基準を引き出し、そして運用ミッションとタスクの有効性におけるこれらのメトリクスの値の影響を測定するため、基盤を提供する。米国連邦エンタープライズアーキテクチャ (FEA)において、事業体、セグメント、及びソリューションのアーキテクチャは、詳細さのレベルを変えることにより異なる事業の展望と、関連しているが別の関心を提供する。まさに事業体がそれ自身階層的に組織化されるように、アーキテクチャの各タイプによって準備される異なるビューもそうなる。FEA実践ガイド (2006) は3つのアーキテクチャのタイプを定義した：定義では、EA は、基本的に共通または共有資産（それらが戦略、事業プロセス、投資、データ、システム、あるいは技術であろうとも）の識別に係わる。EAは戦略によって駆動される；それは各機関が、その機関のミッションと、戦略的目標及び目的に対してその資源が正しく整合されているかどうかを識別するのを助ける。投資の観点からEAは、全体としてIT投資ポートフォリオについての意思決定を促進するため使われる。従って、EAの一次的利害関係者は、その機関がそのミッションを可能な限り効果的で効率的に満たすことを確かにすることを担っている上級マネージャや行政幹部である。それとは対照に、セグメントアーキテクチャは、中核ミッション領域、事業サービス、及びエンタープライズ・サービスのための簡単なロードマップを定義する。セグメントアーキテクチャは、事業管理によって促進され、市民と機関スタッフへのサービス供給を改善するプロダクトを提供する。投資の観点から、セグメントアーキテクチャは、中核ミッション領域あるいは、共通または共有サービスをサポートする事業または事業のグループのケースのための意思決定を促進する。セグメントアーキテクチャの一次的利害関係者は、事業所有者とマネージャである。セグメントアーキテクチャは3つの原則（構造、再利用、及び整合）を通してEAに関係する。最初に、セグメントアーキテクチャは、EAによって使われるフレームワークを継承するが、それは、中核ミッション領域、あるいは共通または共有サービスの特定ニーズに合致させるため拡張及び特殊化され得る。2番目に、セグメントアーキテクチャは、エンタープライズレベルで定義された重要な資産（データ、共通事業プロセスと投資、及びアプリケーションと技術）を再利用する。3番目に、セグメントアーキテクチャは、事業戦略、代表権、標準、及び性能測定のような、エンタープライズ・レベルで定義された要素を整合させる。In search of "Framework for Modeling Space Systems Architectures" Peter Shames and Joseph Skipper (2006) defined a "nominal set of views

出典:wikipedia