ビュー・モデル
From Wikipedia, the free encyclopedia
システム工学、ソフトウエア工学、及びエンタープライズエンジニアリングにおけるビュー・モデル（英: 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]。
