itアーキテクチャ・メタモデルセマンティクス解説iii 2007 ipa all rights...

Ⓒ2007 IPA All Rights Reserved

IT アーキテクチャ・

メタモデル

セマンティクス解説

ＩＴスキル標準® V2 2006

プロフェッショナ・ルコミュニティ®

ＩＴアーキテクト委員会

2007 年 6 月 28 日 Ver1.0


● 本報告書に記載されている「ＩＴスキル標準®」および「プロフェッショナル・コミュニ

ティ®」は、独立行政法人情報処理推進機構（ＩＰＡ）の登録商標です。また、社名お

よび製品名は、それぞれの会社の商標です。なお、本文中では「ＴＭ」、「®」は省略し

ています。

● 本報告書に記載されているＷｅｂページに関する情報（ＵＲＬ等）については、予告な

く変更、追加、削除（閉鎖）等される場合があります。あらかじめご了承願います。

i Ⓒ2007 IPA All Rights Reserved

はじめに

独立行政法人情報処理推進機構（以下、IPA）ＩＴスキル標準センターでは、ＩＴスキル標準を

基盤とした人材育成の支援事業を進めており、ＩＴスキル標準の改版や、企業などでの活用事例の収

集と分析、プロフェッショナルの育成に有益な情報発信などを行っている。

この一環として、ＩＴスキル標準センターにプロフェッショナル・コミュニティを創設し、後進人

材のスキルアップに貢献するため、次のような活動を継続している

•後進人材育成のためのガイドライン作成

•ＩＴスキル標準／研修ロードマップに対する改善事項の指摘

•ハイレベルなＩＴ人材の育成要素に関する助言など

2003 年 11 月の活動開始からＩＴアーキテクト委員会は、ＩＴアーキテクトに関する人材像の明確

化、ＩＴスキル標準および研修ロードマップの改善指摘、研修コースのレビュー、および各種情報調

査とその公開を行っており、以下の活動成果を報告している。

「ＩＴアーキテクト育成ハンドブック」（平成 15 年度）

「参照アーキテクチャ調査報告」（平成 16 年度、平成 17 年度）

「ＩＴスキル標準改善提案報告書（中間報告）」（平成 16 年度）

「ＩＴアーキテクトの責務と活動プロセスに関する研究（中間報告）」（平成 16 年度）

「ＩＴアーキテクト解説書」

これらの活動成果は、ＩＴアーキテクト委員会のＷｅｂページから参照可能である。

（ＩＴアーキテクト委員会のページ

http://www.ipa.go.jp/jinzai/itss/activity/architect_com.html）

2006 年度はＩＴアーキテクト委員会の下に、複数のワーキンググループにてコミュニティ活動を行

った。本書は、ＩＴアーキテクト委員会の 2005、2006 年度の活動成果に基づいて「ＩＴアーキテチ

ャ・メタモデルセマンティクス解説」として整理したものである。

ワーキンググループ活動名

IT アーキテクチャ・メタモデル策定ワーキンググループ

（略称：メタモデル WG）

活動の目的

IＴアーキテクトが扱うＩＴアーキテクチャおよびＩＴアーキテクチャが支えるべきビジネ

ス・アーキテクチャの構造を抽象概念としてとらえ、モデルとして提供することによって、Ｉ

Ｔアーキテクトが自己の活動においてどのような事柄を扱うのかを明確にする。

ii Ⓒ2007 IPA All Rights Reserved

活動メンバー（五十音順、○はリーダ、年度は WG メンバーとして活動した時期）

• 岩崎新一日本電気株式会社（2005 年度）

• 小池和雄日本電気株式会社（2005 年度）

• 今野睦サイバービーンズ株式会社（2005 年度）

• 榊原彰 ○ 日本アイ・ビー・エム株式会社（2005-2006 年度）

• 長坂実ＣＳＫシステムズ株式会社（2005-2006 年度）

• 野村一行マイクロソフト株式会社（2005-2006 年度）

• 羽生田栄一株式会社豆蔵（2005 年度）

なお、本書は、IT アーキテクト委員会の 2007 年度以降の活動により、必要に応じて随時改版してい

く予定である。

2007 年 6 月

ＩＴスキル標準プロフェッショナル・コミュニティＩＴアーキテクト委員会

iii Ⓒ2007 IPA All Rights Reserved

本書について

IT アーキテクチャのメタモデル策定は、IT スキル標準センター内に設けられたプロフェッショナル・

コミュニティ、IT アーキテクト委員会の中の 1 サブ・プロジェクトとして発足した。当初は IT システ

ムに関する部分のみを対象とし、単一のビュー（後述）を提供することを念頭において策定を開始した

が、IT スキル標準の V2 に伴う改訂により、IT アーキテクトの専門領域を大きく 3種類（アプリケーシ

ョン・アーキテクチャ、インテグレーション・アーキテクチャ、インフラストラクチャ・アーキテクチ

ャ）に収斂したことと、V2 以降の改訂の議論においてビジネス・アーキテクチャの側面にも検討範囲を

広げていることを考慮し、現在および近い将来の IT アーキテクトが取り扱わなければならないアーキ

テクチャ要素全般を取り扱うこととした。

メンバー個々が業務多忙につきなかなか策定作業に取り掛かれなかったことや、内容検討と文書化作

業の間隔が大きく開いてしまったことなどから進捗が計画通りに進まなかったという事情があるが、内

容としては厳密性よりも整然とした理解容易性を狙った読みやすいものとなったと考えている。

■本書の目的

本書は、IT アーキテクチャおよび IT アーキテクチャが支えるべきビジネス・アーキテクチャの構造

を抽象概念としてとらえ、モデルとして提供することによって、IT アーキテクトが自己の活動において

どのような事柄を扱うのかを明確にすることを第 1の目的として作成された。ただし、本書が提供する

IT アーキテクチャのメタモデル自体はビジネスや IT を構成する要素とその構成に着目しているに過ぎ

ず、このメタモデルで書き表せないアーキテクチャ構成要素およびその周辺技術（たとえば設計手法や

プロセス、ソフトウェアパターンやフレームワーク技術など）も残っていることをあらかじめ断ってお

く。

本書の第 2の目的は、IT アーキテクトを育成する担当者が育成プランを作成するにあたり考慮すべき

スキル構成要素が何かを明らかにすることである。メタモデルに記された各モデル要素は、そのままそ

れらをどのように取り扱うのか、またどのように組み合わせるのかといった応用力を身につけるために

何が必要かということを端的に表したものであるため、育成すべき技術領域などの計画を立案しやすい

はずである。

iv Ⓒ2007 IPA All Rights Reserved

■対象読者

本書は、主に以下の読者を対象として想定している。

• IT アーキテクト（IT スキル標準のレベルを問わず）

• IT アーキテクトを目指す他の職種

• IT アーキテクトの育成に携わる方（研修担当者、メンター）

また、IT アーキテクチャの職種という観点以外に、以下に示す作業の担当者にも参考になる可能性が

あると言える。

• アーキテクチャ設計の開発プロセス策定担当者

（プロセスの項目を決めるために、IT アーキテクチャのメタ要素を扱うことは網羅性および

作業順序の検討に役立つ）

• アーキテクチャの評価やアーキテクチャ再構築のためのコンサルティング担当者

（アーキテクチャの評価のためには、基準となる構成を持つモデルとの比較も優れた手法で

あり、本メタモデルはそのための抽象概念を提供する）

■本書の構成

本書は、「第 1部ＩＴアーキテクト委員会によるＩＴアーキテクチャ・メタモデルセマンティクス

解説」と「第 2 部一般的なアーキテクチャ記述の解説とビューポイントのカタログ」の２部で構成す

る。

第１部は当委員会で検討したアーキテクチャ・メタモデルの概要、個々のモデル等について説明する。

第２部は、参考となる一般的なアーキテクチャ記述の解説を目的に、書籍等に記載されているビューポ

イントをカタログ的に紹介する。

v Ⓒ2007 IPA All Rights Reserved

CONTENTS

第１部ＩＴアーキテクト委員会によるＩＴアーキテクチャ・メタモデルセマンティクス解説............................... 1

１．ＩＴアーキテクチャ・メタモデルの必要性 .......................................................................................................... 3

２．IEEE STD. 1471-2000 との関連性 .............................................................................................................................. 5

2.1 SOFTWARE INTENSIVE SYSTEM のためのアーキテクチャ記述標準 – IEEE STD. 1471-2000 .........5

３．メタモデルにおける各ビューの解説 ........................................................................................................................ 7

3.1 ハイレベル・ビュー .......................................................................................................................7 3.1.1 全体概要 .................................................................................................................................7

3.2 IT ビュー.........................................................................................................................................8 3.2.1 全体概要 .................................................................................................................................8

3.3 FUNCTIONAL ビュー........................................................................................................................9 3.3.1 全体概要 .................................................................................................................................9 3.3.2 モデル要素..............................................................................................................................9

3.4 OPERATIONAL ビュー ....................................................................................................................11 3.4.1 全体概要 ...............................................................................................................................11 3.4.2 モデル要素............................................................................................................................11

3.5 BUSINESS ビュー...........................................................................................................................13 3.5.1 全体概要 ...............................................................................................................................13 3.5.2 モデル要素............................................................................................................................13

４．メタモデルのインスタンス化とアーキテクチャ設計手順 ...........................................................................16

4.1 メタモデルのインスタンス化 .......................................................................................................16 4.2 アーキテクチャ設計の手順...........................................................................................................17

第２部一般的なアーキテクチャ記述の解説とビューポイントのカタログ.............................................................19

５．ビューポイントのカタログ ..........................................................................................................................................21

5.1 RUP ４+１VIEW...........................................................................................................................22 5.2 RM-ODP.......................................................................................................................................28 5.3 ROZANSKI & WOODS .....................................................................................................................31 5.4 TOGAF のビューポイント・タクソノミ ......................................................................................35 5.5 MICROSOFT の SOFTWARE FACTORIES..........................................................................................38

６．独自ビューポイントの定義方法 ................................................................................................................................40

1 Ⓒ2007 IPA All Rights Reserved

第１部

ＩＴアーキテクト委員会による

ＩＴアーキテクチャ・メタモデルセマンティクス解説

第１部では当委員会で検討したアーキテクチャ・メタモデルの概要、個々のモデル等について説明する


１．ＩＴアーキテクチャ・メタモデルの必要性

IT スキル標準において IT アーキテクトという職種が公文書に登場して以来、徐々にではあるが IT ア

ーキテクトがどのような職業で、どのような職務を遂行するのか、どのような責務を持つのかが概念的

には明らかにされつつある。しかしながら、IT アーキテクトが作る IT アーキテクチャそのものに対す

る理解はまだまだ広く浸透しているとは言い難く、これをして IT アーキテクチャを作るプロフェッシ

ョナルである IT アーキテクトに関する理解も実践レベルでコンセンサスを得るには至っていないのが

現状である。

そこで、IT スキル標準センタープロフェッショナル・コミュニティ IT アーキテクト委員会（以下、

ITA 委員会と表記）では、IT アーキテクチャのメタモデルを策定して、より俯瞰的に IT アーキテクチ

ャをとらえてもらうことが必要と考え、当セマンティクス解説を書き起こすこととした。

メタモデルとは、モデルを規定するためのモデルである。プログラム言語の処理系を構築する際にコ

ンパイラのためのコンパイラ、コンパイラ・コンパイラが必要とされるようにモデルを規定する概念と

してのモデルは必要欠くべからざるものである。しかしながらメタのためのメタ、そのまた上位概念の

メタ、と永久に概念の抽象化を図っても実用上の意味がないため、通常は一定の抽象概念は自己記述を

行えるよう再帰的な定義を以ってこの体系を完結する。

当セマンティック解説においては、UML（統一モデリング言語）を規定する MOF（メタ・オブジェクト・

ファシリティ）の概念をアナロジーとして以下の 4階層のメタモデル構造を前提とする。

図 1-1 メタモデルの 4階層と当 IT アーキテクチャ・メタモデルの位置づけ

モデル化対象のシステム

種々アーキテクチャ・モデル

IT アーキテクチャ・

メタモデル

M3：メタ-メタモデル

M2：アーキテクチャ

メタモデル

M1：アーキテクチャ

モデル

M0：

アーキテクチャ


ただし、我々の目的はメタレベルのレイヤー構造を規定することにあるのではなく、あくまでもアーキ

テクチャを明らかにするためのメタモデルの表出にあるため、上位レベルの「メタ・メタ」構造を定

めることはしない。したがって、当解説書を利用される方はその点をご理解のうえ、不要な抽象論に目

を向けることのないようお願いしたい。


２．IEEE Std. 1471-2000 との関連性

2.1 Software Intensive System のためのアーキテクチャ記述標準 – IEEE Std. 1471-2000

当 IT アーキテクチャ・メタモデルは、IEEE Std. 1471-2000（以下、IEEE1471 と表記）にて定義され

ている Software Intensive System のアーキテクチャ記述標準の概念にヒントを得ている。しかしなが

ら ITA 委員会の考える IT アーキテクチャは、ソフトウェアのみならずソフトウェアを稼動させる環境

までも含めたシステム全体をスコープとしていることから、IEEE1471 の定義をベースとしながらもこれ

を拡張する必要があった。また、昨今の状況から IT はビジネスとの整合なくしては成り立たず、IT シ

ステムをドライブする、あるいは IT システムによって支えられるビジネスのアーキテクチャも含めた

形での検討が必要だと考え、IEEE1471 よりもさらに広い概念を導入することとした。

ArchitectureDescriptionStakeholder

Concern Viewpoint View

Model

ArchitectureSystem

1

1..*

1..*1..*1..*organized by

described by

establishes methods for

inhabits

has source

conforms to

Mission

Environment influences

fulfills 1..*

has an

Rationaleprovides

participates in

aggregates1..*

consists of

has

1..*is important to

1..*has

1..*identifies

identifies1..*

1..*is addressed to

used tocover1..*

0..1

LibraryViewpoint 1..*

selects

participates in1..*

図 2-1 IEEE Std. 1471-2000 で定義される IT アーキテクチャ記述の概念モデル

ITA 委員会で注目した点は、アーキテクチャ記述（Architecture Description）の View である。アー

キテクチャそのものは形がないものであるため、アーキテクチャはアーキテクチャ記述によって表現さ

れるが、アーキテクチャ記述はステークホルダの細かな関心事に応じた視点があり（Viewpoint）、複

数の関連する視点によって IT アーキテクチャ設計時に意味のある View を構成する。

関心事によって Viewは多様な側面を持つものであり、たとえば大きなくくりとしては、IT構成の View、

IT システムを開発する場合の View、IT ガバナンスの View など多岐にわたる。

本書は、このうち、IT アーキテクトが設計の対象とする、IT を構成する要素に注目した「IT 構成の

View」に関するメタモデルとそのセマンティックを解説するものである。これによって IT アーキテク

トはどのような要素を設計対象としなければならない。


また、当セマンティクス解説書におけるアーキテクチャ構造としては、現在 IT アーキテクト委員会

にて議論・検討中であるビジネス・アーキテクチャに関するメタ構造も参考までに記載した。IT アーキ

テクトの職責はビジネスから IT への橋渡しが中心であるため、どうしても IT アーキテクチャの構造だ

けを語ることは片手落ちとなってしまうためである。したがって、ビジネス・アーキテクチャ部分は今

後大幅に変更する可能性もあることをご理解いただきたい。


３．メタモデルにおける各ビューの解説

3.1 ハイレベル・ビュー

3.1.1 全体概要

ハイレベルのビューは、アーキテクチャ・メタモデル全体の俯瞰を行うためのビューである。ハイレ

ベル・ビューは、分離してとらえる必要のある関心事それぞれがどのような関連を持っているかを示す

コンテキスト図の位置づけである。

ITIT is governed by

is driven by

BusinessBusiness

is supported by

IT GovernanceIT Governance

図 3-1 ハイレベル・ビュー

ハイレベル・ビューにおける依存関係の主軸は、Business が IT によってサポートされ、IT が Business

によって駆動される関係である。もちろん関心事をどのように切り出すかによってこの依存関係は一意

なものではなかったり、依存関係そのものが意味をなさなかったりする場合もあるが、IT アーキテクト

が IT アーキテクチャを構築するという責務を考える際に Business と IT の関係は前述した依存関係が

大前提になる。ちなみに IT アーキテクチャは IT Governance によって統治される。


3.2 IT ビュー

3.2.1 全体概要

IT ビューは、IT アーキテクトが設計対象とするアーキテクチャ・コンポーネントの要素およびそれ

らの関係を表すビューである。

ITIT

FunctionalFunctional

Quality (Service Level)Quality (Service Level)

OperationalOperational

+ +

図 3-2 IT ビューが内在する Functional/Operational ビューと Quality の関係

IT アーキテクチャには、大きく機能要求を受けてそれらを実現するソフトウェア・コンポーネントの

設計を行う機能的な側面（Functional）と、それらのソフトウェア・コンポーネントを稼動させるため

のインフラの側面（Operational）がある。非機能要求と言われる要求に関しては、Functional な側面

および Operational な側面どちらかの実装として実現されるのではなく、双方の設計で協調して満たす

べき要求である。特にその中でも品質要求はこれら 2つの側面を整合性あるものとして設計した成果と

して実現され、その指標はサービスレベルとして評価される対象となる。


3.3 Functional ビュー

3.3.1 全体概要

Functional ビューは、IT ビューで示した IT アーキテクチャ全体の中で機能要求を受けて設計を進め

る部分を示している。各機能要求はコンポーネントとして実装するが、その際に明確にインタフェース

を定義することが重要である。

Interface OperationSignatureComponent

Subsystem

1

specifies

offers

aggregatesimplements

composites accesses

Data

PersistentData TransientData

1..*

1..*

1 1..*

1..*

1

1

1..*

1..*1 1..*

図 3-3 Functional ビュー

3.3.2 モデル要素

Subsystem

当該ソリューション・アーキテクチャを適用するシステムを、何らかの基準に従って領域分割した

単位。通常単一の問題領域に対して機能する単位として分割される。1 システムに対して 1 から複

数のサブシステムが存在する。Subsystem は複数の Component の集約とみなすことができる。

Component

Component は単一の機能を、属性と属性を操作するメソッドの集まりとしてカプセル化した単位を

言う。一般に言うオブジェクトと同じと考えることができるが、操作に対するインタフェース（実

装を伴わずに操作を指定することが可能な機構）を指定することができ、これによって他のコンポ

ーネントとの依存関係を弱めるよう設計できる。Component の粒度はさまざまで、単一の Component

が複数の Component からなる場合がある。オブジェクト指向を用いていない設計においても、モジ


ュール凝集度を高めることによってコンポーネントを指向した設計に近づける事は可能である。

Interface

Component の Interface は Component の機能にアクセスするための手段であり、Component 内の属

性を隠蔽するための仕組みである。アーキテクチャ設計の際には、Component の責務自体は

Interface にて表現され、Component の責務を Interface によって Component 外部に提供するとい

う考え方が重要となる。

Operation Signature

Interface 内には Operation Signature が 1 つあるいは複数指定されている。Operation Signature

はその名が示すとおり、操作の内容を記すものであり、操作と操作が使用する引数、および必要に

応じて戻り値を指定することができる。プログラミング・レベルでの指定と異なり初期のアーキテ

クチャ設計においては引数まで指定することは稀だと思われるが、操作自体の指定は、ビジネスル

ールやビジネスロジックの指定を端的に表すものとなるため Interfaceおよび Componentの責務を

決定付ける要素として記述することが必要である。

Data

Data は本来、Component の一部として考えることも可能だが、ここでは明示的に責務を伴う

Component がアクセスする対象として記述した。Data は Component が使用する可能性のあるデータ

すべてが対象となる概念で、永続性の有無によって PersistentData と TransientData に分類され

る。したがって、アーキテクチャ設計の際には、これらがデータベースやファイルとして保管され

るものだけではなく、トランザクション・メッセージやコンポーネント間のメッセージ交換で使用

される引数である場合もある。

PersistentData

Data として表される Component のアクセス対象のうち、永続性を必要とするデータを表す。永続性

を必要とするデータとはデータの状態を蓄積して別な機会に取り出して利用する可能性のあるデ

ータである。したがって物理的な媒体としてはストレージ・メディアに保管されるデータとなり、

ソフトウェア上ではデータベース管理システムやファイル・システムによって管理されるデータを

言う。

TransientData

Data として表される Component のアクセス対象のうち、永続性を必要としないデータを表す。永続

性が不要ということは、そのデータの処理が終了した後に保管を必要としないという意味であり、

Component が主記憶上で使用するデータを表すものである。具体的には Operation Signature に指

定される引数や、システムの制御用に使用されるデータなどが該当する。


3.4 Operational ビュー

3.4.1 全体概要

Operational ビューも Functional ビューと同様、IT ビューを構成する下位のビューである。

Operational ビューは、Functional ビューで示した設計内容を稼動させるためのインフラ設計の面が強

く、Functional で定義したコンポーネントを稼動させるという目的のほか、システム運用やサービスマ

ネジメントなども考慮に入れる必要がある。

また、インフラ設計にノードやゾーンなどの抽象概念を取り込むことによって、インフラ設計そのもの

を再利用しやすいものとする狙いもある。つまり、インフラ設計も概念的な設計内容から物理的な設計

内容に展開させる手順が必要であり、概念レベルと物理レベルを分離することによって、物理的なテク

ノロジーや製品の選択は設計の後工程において行うというメリットを得ることができる。この考え方は、

インフラ設計の要素におけるシステム投資を適なものにし、供給タイミングを少しでもシステムのリ

リースに近い段階にもって行きたいという、IT システム調達関係者の利害関係が一致するものだ。

Location

Connection

Zone

Node

1..*

provides connectivity by

composed of

1

1..*1

*

1..*1

1..* 1..*

*

located at

consists of

duplicates

図 3-4 Operational ビュー


Node

Node は IT システムを構成するハードウェアやソフトウェア・プラットフォームを抽象化した概念

である。該当するものの例としては、サーバーやクライアント・マシン、ルーター、ディスパッチ

ャー、OS、ミドルウェア製品、ERP パッケージなどが該当する。アーキテクチャ設計の過程におい

て概念的な設計から物理的な設計へと展開することを前提としたものである。Node には、Node 自

体が機能要件によって決定されるノードと、システム接続上派生的に決定されるノードの 2種類が

あると考えるとわかりやすい。


Location

Location には前述の Node が配置される。わかり易く実体の例で言うならば、東京のセンターにア

プリケーション・サーバーのノードやデータベース・ノードが配置され、大阪のオフィスにクライ

アント・マシンのノードが配置される、といった具合である。Location を考慮しなければならない

のは、ネットワーク接続などインフラ構成を考えること以前に、その場所に存在するステークホル

ダの分析を行う必要があるためだ。Operational ビュー上では省略しているが、Location に参加す

るこれらステークホルダも本来 Location との関連で示されてもよい。

Connection

Node は単体で存在するものは少なく、大多数が他の Node と接続される。そのため、Node は

Connection と関係があり、Connection は物理的な設計のレベルにおいては、今日さまざまな技術

選択肢がある。

Zone

Zone は Location とは異なる概念で、1 個の Location よりも大きな単位の場合や Location の中の

特定の一部分を表す場合もある。Zone の考え方は主にセキュリティの観点や運用監視の仕組みの中

で語られることが多い。セキュリティの DMZ の分離や、運用・監視の管理下にあるか否かといった

概念で括られるため、Location をまたがって 1 つの Zone を構成するなどして、実行可能なエリア

を特定することが重要である。


3.5 Business ビュー

3.5.1 全体概要

Business ビューは、現在ＩＴスキル標準Ｖ２で IT アーキテクトの作業・スキルとして範囲外として

いるビジネスレベルの構造を定義するものである。Business アーキテクチャの設計は、ビジネス・プロ

セス・マネジメントや SOA などの開発が密接に結びつきつつある今日、IT アーキテクトにとっても重要

な作業領域となりつつある。

BusinessGoal

BusinessPerformance

BusinessUnit Role

BusinessProcess

BusinessRule

BusinessEnvironment

Business

*

1

*

11

1..*

1..*1..*

1

drives

is decomposed by

is influenced by

constraints

fulfills

1..*

1..*

BusinessEvent

BusinessResource

BusinessPolicy

*

assembles

1

*

is defined by

performs

*

1

belongs

achieves

1

1..*input

output

1

1..*

1..*includes

1..*

consists of

1..*

1..*

1 1

1

evaluates

*1..*

1..*

1

1..*is driven by

図 3-5 Business ビュー


Business

Business は各事業体（企業やその他なんらかの事業団体）が行う事業の集合体を表す。したがって

その粒度や提供するサービスの種別などは一律に決まらない。文脈上 1つあるいは複数の事業を総

合的に表現する概念として定義される。

BusinessEnvironment

Business は BusinessEnvironment の影響を受けその事業内容・事業戦略を決定していく。

BusinessEnvironment はビジネスを取り巻く環境全体を表すもので、本来は一まとめに記述可能な

ものではないが、このモデルにおいてはビジネスがビジネス環境の影響下にあることを強調するた

めに、一まとめに要素として記述した。


BusinessGoal

BusinessGoal は、上記 Business を遂行する際に達成する目標を指す。ビジネスの目標という観点

から、Business は複数の BusinessGoal の集合として全体の事業目標を達成する。

BusinessPerformance

BusinessPerformance は、ビジネスを遂行した結果の業績を表す。通常 BusinessGoal は達成すべき

目標を表す BusinessPerformance の期待値の集合として定義されるが、これは同時に達成度の評価

にも使われる数値として管理される。BusinessGoal と BusinessPerformance の関係は、ゴール指向

プランニング手法を用いて分割・総合される関係として予実対比を明確に示すものとして定義され

なくてはならない。ここで設定される明確な指標とは一般的に KPI（Key Performance Indicator）

と呼ばれるものが相当する。

BusinessUnit

BusinessUnit はビジネスを遂行する組織単位を表す。したがって達成すべき Business の粒度によ

って BusinessUnit の粒度も異なる。BusinessUnit は設定された BusinessGoal の達成に向けてビジ

ネスの遂行を行う。

Role

BusinessUnit 内でビジネスを遂行するにあたり、後述 BusinessProcess の一旦を担う重要な構成要

素として Role を特別に図示した。ビジネスプロセスを実行する役割をもった人・グループ・自動

機器などを指す。Role は BusinessProcess のフローを決定するため、特に BusinessUnit において

遂行されるBusinessProcessが複雑なフローを持つ場合、きちんと分析しておくことが必要となる。

BusinessProcess

ビジネスの形態という観点から見ると、ビジネスはビジネスプロセスの集合体とみなすことができ

る。ビジネスプロセスを複数組み合わせて 1 つの事業を行うという形態である。BusinessProcess

は Role によって駆動・実行され、BusinessGoal の達成に向け履行される。そして前述のとおり、

Business を構成するため複数の BusinessProcess が集約される。また、BusinessProcess 自体が複

数の下位レベルの BusinessProcess で構成される。

BusinessRule

BusinessRule はビジネスプロセスが実行される際に個々のプロセス自体に条件を与えたり、制約を

課したりする規則を表す。通常複数の BusinessRule の組み合わせにより BusinessProcess が構成

される。BusinessRule 自体は後述 BusinessPolicy によって制約を受ける。

BusinessPolicy

BusinessPolicy は BusinessRule に制約を与え、結果として BusinessProcess の実行に影響を及ぼ

す。ビジネスの遂行時には、一般規則に反する一定のトレードオフ判断や利益優先に基づかない「哲

学」などがあり、それらは複数選択肢をもつビジネスルールの適用基準として機能する。


BusinessEvent

BusinessEvent はビジネス上意味を持つイベントを表し、これがトリガーとなりビジネスプロセス

が起動される。通常 BusinessEvent はプロセス間における刺激（調達プロセスから生産・加工プロ

セスに対するイベント、たとえば「必要な資材の調達が完了した」など）もしくは日付や時刻など

をトリガーにするケース（4月 1日から新商品キャンペーン開始、など）の 2通りが考えられる。

BusinessResource

ここでいう BusinessResource は、BusinessProcess に対する入力・出力となるデータ・情報・物理

的な資材/製品などを指す。BusinessProcess をブラックボックスとしてとらえる際には、何をイン

プットとし、処理の結果何がアウトプットされるのかを示している。


４．メタモデルのインスタンス化とアーキテクチャ設計手順

4.1 メタモデルのインスタンス化

前述のとおり、メタモデルはあくまでもモデルを作成するための上位構造のモデルにすぎない。した

がって、メタモデルを活用するということは、メタモデルのインスタンスであるモデルを作成すること

である。ただし、モデルを作成すると言ってもその手順はさまざまである。抽象的なモデルから物理的

なモデルへと設計内容を変換していく方法もあれば、テンプレートとしての参照モデルを作成しておき、

実際の開発時にはそれらを用いて具体化を行うという手順も多く用いられている。

メタモデルのインスタンス化の基本的な概念を図 4-1 に示す。一般的に Functional ビューで表され

る側面は、さまざまなソフトウェア開発の手法・技法が存在するため詳細な説明をあまり必要としない

ようであるが、インフラストラクチャ設計に関しては、インスタンス化を行うことを前提としたメタモ

デルの存在意義が認識されていないことが多い。そこでここでは Operational ビューのインスタンスと

してのインフラストラクチャ設計に触れる。

図 4-1 メタモデルのインスタンス化の概念

図 4-1 では、Location のインスタンスとして店舗・電算センター（破線枠内はセンター別フロア）な

どが設定されている。それぞれのロケーションの色分けは Zone のインスタンスとしてセキュリティ運

Reverse

Proxy

HTTP

Server

Appl.

Server

DB

Server

Backend

Server

M2

M1

Browser

店舗 DMZ 電算センター


用上の管理下であるか、DMZ であるかという区分を示す。

また、それぞれのロケーションには Node のインスタンスである Browser・Proxy・各種 Server などが

配置され、それらの間は Connection のインスタンスである回線接続によって結ばれているという見方

をしてほしい。

4.2 アーキテクチャ設計の手順

図 4-1 に示すアーキテクチャは説明のための単純なモデルであり、インフラストラクチャ設計におけ

る概念レベルの設計仕様のモデルである。実際にはこのモデルからルーターやハブなど（それぞれ Node

のインスタンス）の接続経路設定のための機器構成が加えられていき、また回線 2重化、サーバーの冗

長化といった物理条件・物理制約を加味した設計に落とし込んでいくことが必要である（図 4-2）。

図 4-2 インフラストラクチャ設計の段階的詳細化

同様に、Functional ビューにおける設計手順には RUP など多くのオブジェクト指向方法論などで提唱

されている概念モデル/詳細モデル/実装モデル（表現は個々の方法論により多少異なるが、意味として

は、概ね IT 非依存のモデル/実装非依存のモデル/実装仕様モデルと解釈）のように 3 段階の設計手順

を踏む。

Functional ビューの設計の結果としてのコンポーネントは、Operational ビューの設計結果である各

ノード上に配置される。また、Operational ビューの設計内容によって制約や非機能要求から機能要求

としてソフトウェア上で実装が必要な要求のフィードバックが行われる。したがって両側面の設計作業

における協調は図 4-3 のように考えるとよい。これは情報も機能も運用もすべてが一極集中で行われて

いた時代から変化してきた、現代のコンポーネント指向のアーキテクチャ（Functional/Operational 双

方において）設計においては、大前提となるシステム全体の設計原則であると言える。

インフラストラクチャの

概念設計


詳細設計


物理設計

• ノードの種別と配置が機能要件によっ

て決定されることのみを扱う設計

• 概念設計で決定された機能的ノードの

配置をベースに、システムおよびネッ

トワーク接続の観点から経路設定のノ

ード配置を付加した設計

• サーバー冗長化、ネットワークの多重

化などの物理条件を付加した設計


図 4-3 Functional と Operational の協調によるアーキテクチャ設計の手順

アプリケーション

概念モデル


詳細モデル


実装モデル

インフラストラクチャ

概念モデル


詳細モデル


物理モデル

Functional ビュー Operational ビュー

配置と

フィードバック

配置と


配置と



第２部

一般的なアーキテクチャ記述の解説と

ビューポイントのカタログ

第２部では、参考となる一般的なアーキテクチャ記述の解説を目的に、書籍等に記載されているビュ

ーポイントをカタログ的に紹介する。


５．ビューポイントのカタログ

IEEE1471 はアーキテクチャを記述するための概念フレームワークであり、ステークホルダの関心事を

反映するビューで組み立てられている。ビューはステークホルダや開発プロジェクトなどの要求に応じ

てテーラリングされるものであり、絶対的に正しいというビューが存在するわけではない。しかしなが

ら、アーキテクチャ設計の基盤となるビューの再利用性を高めることが「適切な」アーキテクチャの開

発コストを削減することは明白である。したがって、必要に応じてビューを定義するための手段が必要

とされる。その手段がビューポイントであり、アーキテクト及びアーキテクチャ設計に関わる開発者は

ビューポイントをパターンやテンプレートなどとして利用し、ビューを導出することでステークホルダ

の関心事に適合するアーキテクチャを設計できる。

アーキテクトはこれらのビューを作成するにおいて合目的的（fitness-for-purpose）であるかどう

か考慮するべきである。アーキテクトは完全性、すなわち関連する全てのビュー、それらのビューの関

係、それら異なるビューから発生する矛盾に対応しているか、を含めて考慮しているかを理解しなけれ

ばならない。更にアーキテクトはアーキテクチャの実行可能性についても対処しなければならない。も

しアーキテクチャを実装することができないなら、その価値が疑わしいからである。

それぞれのビューポイントには名前、関連するステークホルダ、関連する関心事、言語、記法、モデ

リング技法もしくは分析技法などが仕様として含まれる。

ビューポイントのカタログには様々なものがあり、公開されている主なものだけでも以下のように多

岐に渡る。

RUP の 4+1 ビュー（1995 年）

RM-ODP のビューポイント（1996 年）

Seimens 社の４つのビュー（2000 年）

Clements のビュータイプ（2003 年）

Garland と Anthony のビューポイント（2003 年）

TOGAF(The Open Group Architecture Framework) 8 のビューポイント・タクソノミ（2004 年）

Rozanski と Woods のビューポイントとパースペクティブ（2005 年）

詳細はそれぞれの資料に当たるのが適切だが、ここでは、RUP の 4+1 ビュー（5.1）、RM-ODP のビュ

ーポイント（5.2）、さらに IEEE1471 のビューポイントにパースペクティブという直交する概念を取り

入れた Rozanski と Woods（5.3）、IEEE1471 をベースとした TOGAF のビューポイント・タクソノミ（5.4）、

それと IEEE1471 をベースにプロダクトライン開発を念頭に入れた Microsoft 社の Software Factories

のビューポイント分割例（5.5）等を紹介する。


5.1 RUP ４+１View

RUP（Rational Unified Process）は、米国ラショナルソフトウェア社が開発したソフトウェア開発

方法論である。ソフトウェア開発の基本となる一連の理念と実践原則を中核として、開発を進めるため

のプロセスモデルと関連するコンテンツライブラリ、効率的な推進を支援するプロセス定義言語やプロ

セス提供ツールで構成される。

その中で、ソフトウェア・アーキテクチャのデザインについて言及しており、アーキテクチャの概念

やその記述方法を定義している。RUP のアーキテクチャ記述方法は、開発プロセスの様々な利害関係者

に対応するため、複数のビューを用いることを採用しており、典型的なビューポイントとして RUP ビュ

ーポイントセット（RUP 4+1 ビュー）を示している。この RUP 4+1 ビューは、1995 年に Philippe Kruchten

が発表した「4+1 View モデル」1を原点とするものである。

図 5-1-1 4+1 View モデル（概念）

（１）View ポイント

RUP４＋１ビューは、開発プロセスの利害関係者（エンドユーザ、設計者、管理者、システムエン

ジニア、保守担当者など）の固有の関心事を適切に扱うために、以下に示す５つのビューを持つ。

① ユースケース・ビュー

② 論理ビュー

③ 実装ビュー

④ プロセス・ビュー

⑤ 配置ビュー

1 Philippe Kruchten 著 1995, 「The 4+1 view model of architecture」 (IEEE Software.) 12(6) November 1995

Logical View

Process View

DevelopmentView

Physical View

Scenarios


（２）ユースケース・ビュー

ユースケース・ビューは、アーキテクチャ上重要なユースケースモデルのサブセット、ユースケー

ス、アクターのサブセット、アクターを示す。あわせて、技術面でのリスクを含むユースケースお

よびシナリオを示す。

ユースケースビューは、アーキテクチャビューの中でも大きな粒度の概念であり、アーキテク

チャデザインの初に作成する。システムのユースケースとアクターを上位レベルから個別レベル

まで段階的に整理し、要件を過不足なく捉え、また全体として矛盾なく整合したアーキテクチャさせ

る。

図 5-1-2 ユースケース・ビュー（概念）

ユースケース・ビューは、要求作業分野で使用され、ユースケースモデルの成果物サブセットと位置

づけられる。

（３）論理ビュー

論理ビューは、アーキテクチャ上重要な振舞いを含む、サブシステム、パッケージ、クラスの論理

的なコンポーネントの構成を示す。そして、各構成の要素に関する、協調・順序・状態遷移などの振

舞いをあわせて示す。

ユースケースモデルで記述される機能性をどのように実現するか、抜け漏れなく実現しているか、

さらに構成要素の構造・振舞いが矛盾なく整合しているか、またそれ以外の冗長な振舞いをしないこ

とを明らかにする。

最上位レベルのパッケージ

ユースケースパッケージ

ユースケースアクター

ユースケースビューユースケース

ビュー


図 5-1-3 論理ビュー（概念）

論理ビューは、分析／設計ワークフローで使用され、設計モデルの成果物サブセットに位置づけら

れる。

（４）プロセス・ビュー

プロセス・ビューは、システムのプロセス分解を図示し、関与するタスク (プロセスとスレッド)、

そのタスクの相互作用と構成、タスクへの設計オブジェクトとクラスの割り当てを明らかにする。

たとえば、クラスとサブシステムをプロセスとスレッドにマッピングすることで、クラス間相互作

用や時間的側面を考慮した振る舞いを定義する。このように、プロセス・ビューはシステムの動的側

面を把握することができ、多重並行性があるシステムに効果的である。

最上位レベルのパッケージ

設計サブシステム

ユースケースの実現

クラス

ユースケースビュー論理ビューパッケージ

シーケンス


図 5-1-4 プロセス・ビューの成果物例

プロセス・ビューは分析／設計ワークフローで使用され、設計モデルの成果物サブセットに位置づけ

られる。

（５）実装ビュー

実装ビューは、システム上に実装されるアーキテクチャを示す。実装モデル内の全てのサブシステ

ム・コンポーネントと、論理ビューおよびプロセス・ビューとの関連、さらに実装したコンポーネン

ト間のインポート依存関係を明らかにする。たとえば以下のような内容を示す。

ディレクトリの構造

ソースコードファイル、実行コードファイルの構成と配置

スクリプトファイルの構成と配置

設定・参照情報の構成と配置および形式

実装ビューを活用することで、以下のようなタスクに効果が期待できる。

個人、チーム、または下請け業者への実装作業の割り当

開発、変更、削除されるコードの量の見積

大規模な再利用の検討

リリース戦略の検討

構成管理・変更管理の検討

<<process>>携帯電話Main

<<process>>ユーザインタフェース

キーボード制御

スピーカ制御

ディスプレイ制御

<<process>>通信制御

<<thread>>デバイス制御

GPS

メモリカード

電源

<<thread>>ネットワーク

sm メイン

電文作成済み

保存済み

電文送信中

削除済

電文送信済

削除済み

外部に電文を送信している間は送信中

破棄

アーカイブ化

電文作成

元に戻す

削除

相手からの送達確認

一定時間が経過 [優先度高]

送信

削除

キャンセル

送信

電文保存

Tech-SPA


図 5-1-5 実装ビュー（概念）

実装ビューは実装プロセスで使用され、実装モデルの成果物サブセットに位置づけられる。

（６）配置ビュー

配置ビューは、システム内のノード間での処理の分散、およびプロセスとスレッドの物理的な分散

を示し、システムにおける処理ノード間での物理的な分散を示す。

例：処理ノードの設置場所、実行時の処理ノードの構成、ノード間の通信リンク、ノード上にある

コンポーネントのインスタンスとオブジェクトを明らかにし、ユースケースシナリオに対して妥当な

構造

図 5-1-6 配置ビューの成果物例

配置ビューは、分析／設計フローで使用し、配置モデルのサブセットに位置づけられる。

id 本番環境

BPM

バックアップサーバ

データベース#1

WebAPサーバ#1

ApServer

WebServer

WorkFlow/BI

RHEL4

Cluster

Data　Protecter

Unix

OracleDatabase10gR2

EAIサーバ（内部）　#2

EAIサーバ（外部）　#1

RHEL4

EAI

RHEL4

EAI

WebAPサーバ#2

webServer

ApServer

RHEL4

データベース#2

Unix

Cluster

OracleDatabase10gR2

HREL4

HP　ServiceGuard

Cluster

EAIサーバ（内部）　#1

EAI

RHEL4

EAIサーバ（外部）　#2

EAI

Cluster

RHEL4

Cluster

WindowsServer2003

クライアント

WebBrowser

運用管理サーバ

HREL4LogManager障害監視 JobManager

BPM（見積の範囲外）

EAI（内部）新基幹コア

運用管理

EAI（外部）

ロードバランサー+SSLアクセラレータArray TMX2000

Firewall (Juniper SSG 140 ×2)

SCSIストレージHP MSA500G2146GB × 12 （RAID5 + ホットスペア)用途： Oracle DB

ロードバランサー(TX1100) ×2

Firewall ( G140)×2

Internet

共通機能/APサーバ (Windows2003 SE)360CPU 2.66G DualCore 4GMemory HDD: 146G ×3（RAID1 + ホットスペア)リダンダントパワーサプライ

データ連携サーバ (RHEL4)360G5CPU 2.66G DualCore 4GMemory HDD: 146G ×3（RAID1 + ホットスペア)リダンダントパワーサプライ

DBサーバ (RHEL4)DL380G5CPU 2.66G DualCore 8GMemory HDD: 146G ×3（RAID1 + ホットスペア)リダンダントパワーサプライ

開発検証用共通機能/AP サーバ (Windows2003 SE)DL360G5CPU 2.66G DualCore 4GMemory HDD: 146G ×2（RAID1)

開発検証用DB/データ連携サーバ (RHEL4)DL360G5CPU 2.66G DualCore 4GMemory HDD: 146G ×6（RAID5)

テスト環境

ロードバランサーによる負荷分散

新基盤システムインフラ構成検討資料新構成

運用管理サーバ(RHEL4)DL380G5CPU 1.6G DualCore 2GMemoryHDD: 146G ×8（RAID5 + ホットスペア)リダンダントパワーサプライ

L3SW ×2

クラスタ構成

その他

・ハード保守： 24h/7day 初年度、次年度以降保守費用・Oracle10gはRAC構成ではなく、Active-Standby構成・Backup方式：ネットワークバックアップ

バックアップサーバ

現行機器を共用

新規回線：100Mbps フロントシステム

WMS

L2SW × 2

メール/DNSサーバ (RHEL4)440CPU 2.66G DualCore 4GMemory HDD: 146G ×3（RAID1 + ホットスペア)リダンダントパワーサプライ

メール/DNS/WebProxy/NTPサーバ

ロードバランサーによる冗長化


［出典/参考文献］

・"The Rational Unified Process, An Introduction"、第 2 版

・"The "4+1" View Model of Software Architecture" (in PDF format).

http://www.win.tue.nl/~mchaudro/sa2004/Kruchten4+1.pdf

・Architectural manifesto: Designing software architectures, Part 5

http://www-128.ibm.com/developerworks/wireless/library/wi-arch11/


5.2 RM-ODP

分散処理では、異なった場所で異なったコンポーネントが互いに通信をするため、通信が遅れたり、

失敗したりすることがある。ODP（Open Distributed Processing）は、ODP 標準に従った設計になって

いる分散処理のことで、コンポーネントの異種性を問わず、さらに、組織的な境界をも越えて分散処理

をサポートする。日本語ではオープン分散処理や開放型分散処理と訳されることがある。ODP には、ODP

標準と呼ばれるさまざまな標準が規定されており、その 1 つとしてオープン分散処理の参照モデルと呼

ばれる RM-ODP（Reference Model of Open DistributedProcessing）がある。

RM-ODP は、ODP システムを明確に記述するために必要となる重要な概念／用語を定義している。そ

して、この参照モデルは、大規模システムや分散システムにおける要素の分散配置（distribution）、

相互接続（interworking）、インターオペラビリティ、ポータビリティを実現し、システム仕様を構築

するためのフレームワークを提供する。つまり、RM-ODP は、システム自体のための規定ではなく、シ

ステムの仕様言語やシステムのモデルを記述するための規定である。

このオープン分散処理のための標準の記述方法について規定したRM-ODP は、ISO/IEC 10746-1～

10746-4 の4 部構成になっており、それぞれの内容は以下のとおり。なお、Part2 とPart3 は、引用国

際規格として、JIS 化（JIS X5740-2、JIS X5740-3）されている。

■Part1 （ITU-T Recommendation X.901 | ISO/IEC 10746-1）: Overview

ODP入門、RM-ODPの概観と主要概念の説明

■Part2 （ITU-T Recommendation X.902 | ISO/IEC 10746-2）: Foundations

ODPシステムのモデリングに必要な基本的な概念／用語の規定

■Part3 （ITU-T Recommendation X.903 | ISO/IEC 10746-3）: Architecture

ODPシステムをどのように規定するかの定義

ODPシステムに要求される特性／機能の定義

策定済みのODP標準や今後のODP標準を調整し、かつ、各ODP標準から参照されるフレーム

ワークの確立

■Part4 （ITU-T Recommendation X.904 | ISO/IEC 10746-4）: Architectural Semantics

Part2とPart3の補足

（１）View ポイント一覧

通常、物事を1つの視点で規定しようとすると、複雑な仕様となることがよくある。分散システム

や大規模システムなどでは、視点を分割して捉えることで、それぞれの関心事を分離し、仕様化する

際の複雑さを緩和することができる。企業やシステムといった、ある1つの対象について異なった視

点から仕様を記述するとき、その視点をビューポイントと呼ぶ。

大規模で複雑な情報システムを、標準に沿った手法を用いて複数のビューポイントで記述すること

により、対象システムの複雑な仕様を適度な粒度で分割管理でき、関係者を含めた第三者にもシステ

ムの理解が簡単になるというメリットがある。

RM-ODP では、システムを分割記述するために、5つのビューポイントが定義されており、これらは、

分散処理システムの仕様を効果的で統制の取れたものにするためのフレームワークを提供する。

エンタープライズ・ビューポイント

インフォメーション・ビューポイント


コンピュテーショナル・ビューポイント

エンジニアリング・ビューポイント

テクノロジー・ビューポイント

（２）エンタープライズ・ビューポイント

このビューポイントは、システムの目的、スコープ、ポリシーに焦点を当てたもので、コンテキス

トやシステムの環境全体を規定する。つまり、そのシステムは何のためなのかという観点である。そ

のため、他のビューポイントに適合しなければならない制約や義務なども存在する。

先に述べたように、RM-ODP には、ビューポイント毎にビューポイント言語が定義されているが、

そのエンタープライズ言語でも、後に拡張されたエンタープライズ言語（X.911 | ISO/IEC 15414）

でも、このビューポイントの表記法は定めていない。定めているのは、ビューポイントの仕様のみと

なっている。

エンタープライズ・ビューポイントは、自然言語やベンダー独自の表記法を用いることも可能であ

るが、近年、標準的なモデリング言語としてUML が普及したことにより、ユースケース図やアクティ

ビティ図を使用して記述する事例が増加している。

（３）インフォメーション・ビューポイント

このビューポイントは、システムの情報と関連する処理に焦点を当てたもので、スキーマやエンテ

ィティといった、ビジネス分析者やデータベーススペシャリストにとってよく知られた領域である。

このビューポイントは、情報の流れ、情報の保管、情報の利用者などを記述するためのもので、イン

ターフェイスではなく、オブジェクトを記述する。つまり、そのシステムは何についてのものなのか

という観点である。

インフォメーション・ビューポイントは、エンタープライズ・ビューポイント、コンピュテーショ

ナル・ビューポイントと関連しながら洗練していく。特に、エンタープライズ・ビューポイントから

情報要素をピックアップしていき、コンピュテーショナル・ビューポイントで利用しながら洗練して

いくのが抽象レベルの展開として考えやすい

（４）コンピュテーショナル・ビューポイント

このビューポイントは、システムをいくつかのオブジェクトへ機能分解する。それらのオブジェク

トは、あるインターフェイスを介して相互作用を行う。つまり、オブジェクト、インターフェイス、

操作などを記述するためのもので、どのように動作するのかという観点である。

コンピュテーショナル・ビューポイントはネットワーク、ハードウェア、OS などを意識しないで、

全てが単一のコンピュータ上で動作すると想定し、どんな機能を持ったオブジェクトが、どのように

連携すれば、エンタープライズ・ビューポイントで書かれた目的を実現できるかを表現したものであ

る。

分散処理システムの配置は、コンピュテーショナル・ビューポイントにおいて無視される。これは、

透過性があるということである。コンピュテーショナル・ビューポイントでは、リソースはいつも必

要なときに使用可能で、通信はオブジェクト間で透過性を有することになる。


（５）エンジニアリング・ビューポイント

このビューポイントは、システムのオブジェクト間の相互動作をサポートするメカニズムと機能に

関するもので、クラスター、ノード、チャネル、などを記述するためのものである。つまり、コンピ

ュテーショナル・ビューポイントと同じく、どのように動作するのかという観点である。

エンジニアリング・ビューポイントでは、基本的にネットワークを意識して、コンピュテーショナ

ル・ビューポイントのオブジェクトの働きを実現するには、ネットワーク上の何処に、どのようなオ

ブジェクトを配置し、それらを連携させれば良いかを考える。従って、コンピュテーショナル・オブ

ジェクトの一部分に対応するオブジェクトや、セキュリティやトランザクションのようなインフラ部

分で動作するオブジェクトが定義される。

エンジニアリング・ビューポイントは、コンピュテーショナル・モデルを実現するメカニズムであ

り、オブジェクト間の通信チャネル、リソース管理といったものを扱う。このことは、コンピュテー

ショナル・ビューポイントからの分散配置を隠す透過性のメカニズムを提供することにつながる。

（６）テクノロジー・ビューポイント

このビューポイントは、特定のテクノロジーの詳細に関するものであり、どのようにシステム設計

に実際の技術を利用するかを記述するためのものである。つまり、どのように組み立てるのかという

観点である。しかし、このビューポイントにはほとんどルールがないと言ってよい。

テクノロジー・ビューポイントの「テクノロジー」とは、具体的なハードウェア、ソフトウェア、

ネットワークなどを表す。例えば、コンピュータ本体、OS、ミドルウェア、デーテクノロジー・ビュ

ーポイントア、管理ソフトウェア、セキュリティハードウェア・ソフトウェア、二重化系、使用する

既存システム、ネットワーク、Java 環境、 .NET 環境、ゲートウェイ等々とそれらの構成・組み合

わせなどが挙げられる。

また、このビューポイントは、ODP システムの実際のハードウェア、ソフトウェアの適合性試験の

ための情報も含んでいる。


5.3 Rozanski & Woods

「Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives」

において Nick Rozanski と Eoin Woods は、IEEE1471 に準拠したアーキテクチャ記述の手法を議論して

いる。彼らはアーキテクチャ記述を、ステークホルダが理解でき、ステークホルダの関心事に適合する

アーキテクチャを明示する一連の成果物としている。彼らがビュー及びビューポイントに注目する理由

は、すべてのステークホルダが理解できる包括的なアーキテクチャは単一のモデルで表現できないため

である。

ビューとは Rozanski と Woods の説明によれば、「どのようにアーキテクチャが１人以上のステーク

ホルダの関心事に対応するかを説明した、アーキテクチャにおける１つ以上の構造的側面の表現」であ

る。

ビューポイントとは Rozanski と Woods の説明によれば、「ある種類のビューを構築するための一連

のパターン、テンプレート、規約」であり、「そのビューを構築するためのビューポイント、ガイドラ

イン、原則、テンプレートモデルとして反映されている関心事を持つステークホルダを定義する」もの

である。

Rozanski と Woods は本書において、以下の６種類のビューポイントをカタログ化している。

機能（Functional）：システムの機能的要素、それらの責務、インタフェース、及び基本的な相

互作用を記述する。

情報（Information）：情報の保存、操作、管理、配布の方法について記述する。

並行性（Concurrency）：システムの並行性の構造について記述する。また機能的要素を並行性

の単位にマッピングすることで、システムのどの部分が並行して実行され、どのように調整・制

御されるかを明確に定義する。

開発（Development）：ソフトウェア開発プロセスを支援するアーキテクチャを記述する。

配置（Deployment）：システムが配置される環境、実行時におけるシステムの依存性について記

述する。

運用（Operational）：システムがどのように運用・管理され、稼動環境にて支援されるかにつ

いて記述する。

ビューポイントを策定する利点は、関心事の分離、ステークホルダ集団とのコミュニケーション、複

雑性の管理、開発者の焦点強化とされる。しかしながら、ビューポイントが全てのアーキテクチャにま

つわる問題を解決するものではなく、いくつかの欠点もある。一貫性の欠如、誤ったビューを選択する

怖れ、過度の分裂化、などが挙げられる。

まとめれば、ビューポイントはビューを策定する際の知識ベースであり、プラクティスとしてアーキ

テクチャ設計のガイドとなり、アーキテクチャ策定プロセスのひな形として利用できる。それらビュー

ポイントから導かれたビューはアーキテクチャ記述に一貫した構造を与え、様々なステークホルダの関

心を分離し、ステークホルダ間のコミュニケーションを促進する。


ビューポイントでアークテクチャを記述しようとすると、いくつかの弊害が出てくる。その中でも

も顕著なのは「品質要件」である。品質要件はアーキテクチャ設計にとって重要な要素であるが、ビュ

ーポイントの観点からは明確に考慮されていない。また品質要件は上記のビューポイントを横断する、

一種のアスペクトと言うべきものであり、またビューポイントよりビューを導く際に同時期に考慮すべ

きものである。（すなわち、ビューポイント決定の後で考慮すべきものではない。）

Rozanski と Woods はこうした課題に対し、ビューポイントと直交する概念である、「パースペクティ

ブ」を提示している。パースペクティブはビューに品質要件をアーキテクチャ記述に付加するものであ

る。またパースペクティブは１つ以上の品質要件を扱う。このことは、パースペクティブを独立して扱

うのではなく、それぞれのビューにおいてアーキテクチャの品質を分析・検証し、アーキテクチャにお

ける意思決定により正確を期すことを志向している。

パースペクティブとは Rozanski と Woods の説明によれば、「一連のアクティビティ、チェックリス

ト、タクティクス、ガイドラインであり、１つのシステムが密接に関連する品質要件－これらは複数の

システムのビューをまたがり考慮すべきものである－を確実に示すためのプロセスをガイドするもの」

である。

Rozanski と Woods は本書において、以下の１０種類のパースペクティブをカタログ化している。

セキュリティ（Security）：システムを安全に制御、モニタリング、監査

パフォーマンスとスケーラビリティ（Performance and Scalability）：決めされたパフォーマ

ンスプロフィールの範囲で予想通りにシステムを実行し、増大する処理に対応する能力。

可用性と回復性（Availability and Resilience）：要求される限り完全にあるいは部分的にシ

ステムを利用でき、システムの可用性に影響を与える障害を効率的に処理する能力。

発展性（Evolution）：避けられない変化に直面しても柔軟性を保つシステムの能力。

アクセシビリティ（Accessibility）：障害者などハンディを持つ人々によって使われるシステ

ムの能力。

開発リソース（Development Resource）：人、予算、時間、機材に関する制約のもとで設計、構

築、配置、運用するシステムの能力。

国際化（Internationalization）：特定の言語、国、文化的集団に依存しないシステムの能力。

ロケーション（Location）：システムの構成要素の絶対的位置や要素間の距離によってもたらさ

れる問題を克服する能力。

法規（Regulation）：国内および国際法、準法律的な規制、企業ポリシー、および他のルールや

標準に準拠するシステムの能力。

ユーザビリティ（Usability）：人とシステムとの相互作用が効率的に行われることに対する容

易性。

パースペクティブを適用する利点は、システム品質の記述、アーキテクチャ上の意思決定をガイドす

る関心事の記述、アーキテクチャの検証の方法の記述、共通する問題に対する解決策の記述、関心事に

対応するためのシステマチックな方法を提供するとされる。しかしながら、パースペクティブを適用す

るにおいて、いくつかの欠点があることも意識しておかねばならない。複数のパースペクティブのコン

フリクトの可能性、ステークホルダによって異なるパースペクティブの優先度の問題、パースペクティ

ブを適切に適用するための状況の正しい把握、などが挙げられる。


前述のようにパースペクティブは１つ以上のビューに関連させることができ、アーキテクチャが特定

の品質要件を満たしているかどうか分析し、修正するためのガイダンスを提供する。

Functional ビュー

Information ビュー

Concurrency ビュー

Development ビュー

Deployment ビュー

Operational ビュー

Security パースペクティブ

Performance パースペクティブ

Availability パースペクティブ

Usability パースペクティブ

Accessibility パースペクティブ

Location パースペクティブ

Regulation パースペクティブ

etc.

図 5-3-1 ビューへのパースペクティブの適用

たとえば、ビューとパースペクティブを軸に 2次元表を作成し、重要な品質要件や関心事を検証でき

る。


Security Performance Availability Evolution

Ope

rationa

Concurr

enc

yIn

form

atio

nFunctional

InformationSecurity

(アクセスコントロー

ル、アクセスクラス、

オブジェクトレベルの

セキュリティ)

ConcurrencyPerformance(共有リソース、ブ

ロッキング、キューイ

ング、コーディネー

ション)

FunctionalEvolution

(拡張ポイント、柔軟

なインターフェイス、

メタアプローチ)

パースペクティブ

ビュ

ー

図 5-3-2 ビューにパースペクティブを適用した例

ビューとパースペクティブは多対多で関係づけられるが、全ての組み合わせにおいて影響を及ぼすわ

けではない。Rozanski と Woods はパースペクティブごとにビューへの適用に関してどのような関係ある

いは影響があるかまとめている。

[出典/参考文献]

・ Rozanski, N. and Woods, E. : Software Ssytems Architecture: Working With Stakeholders Using

Viewpoints and Perspectives, Addison Wesley, 2005.


5.4 TOGAF のビューポイント・タクソノミ

TOGAF 8.1 に収録されている“Developing Architecture Views”という記事において、IEEE1471 の

ビューポイント概念に基づいてタクソノミがまとめられている。

TOGAF においてもアーキテクチャ記述においてはビューが重要な成果物（artifact）となる。しかし

ながら、IEEE1471 は必須ではなく推奨する、という位置づけとなっている。

TOGAF においてビューポイントおよびビューの開発には特定のプロセスは要求してはいない。しかし

ながら IEEE1471 が適応されプラクティスとして確立されているなら、以下のステップにて特定のビュ

ーが作成されると考えられるとしている。

１．既存のビューポイントライブラリが参照される。

２．ステークホルダと関心事をもとに適切なビューポイントが選択される。

３．選択されたビューポイントをテンプレート（ひな型）としてシステムのビューが作成される。

このタクソノミにおいては、ビューポイントという用語は明示的に使用されておらず、すべてビュー

という用語にて分類されている。しかしながら、記事においてビューの作成方法に多くの文面を割いて

解説されており、そこでステークホルダや関心事、ビューのモデリング、重要な課題や概念などを議論

しているため、ビューをビューポイントと読み替えても問題ないと思われる。


図 5-4-1 TOGAF におけるアーキテクチャのビューポイントタクソノミ例

Business Architecture ビューはユーザーやプランナ、ビジネス管理者の関心事に対応しシステムの

ユーザーの視野からシステムの機能的な側面にフォーカスする。Business Architecture ビューは以下

のサブビューから構成される。

People ビュー：システムの人的資源の側面にフォーカスする。

Business Process ビュー：システムに含まれたユーザープロセスを扱う。

Business Function ビュー：上記のプロセスをサポートするために必要な機能を扱う。

Business Information ビュー：上記のプロセスのサポートにおいてフローが必要な情報を扱う。


Usability ビュー：システムとその環境のユーザビリティの側面を扱う。

Business Performance ビュー：システムとその環境のパフォーマンスの側面を扱う。

Data Architecture ビューと Application Architecture ビューはデータベース設計者/管理者やシス

テム、システムのソフトウェアエンジニアの関心事に対応し、様々なタイプのエンジニア（セキュリ

ティ、ソフトウェア、データ、コンポーネント、通信）の視野からどのようにシステムが実装されるか、

そしてそれらが修正可能性、再利用性、可用性などにどのように影響を与えるかにフォーカスする。こ

の２つのビューは以下のサブビューから構成される。

Data Flow ビュー：データストレージ、データの取得、処理、保存、セキュリティを扱う。それ

らはデータが保存・処理される際にデータのフローとして考察され、保存・処理をサポート・管

理するために必要とされる要素が何であるかを考察する。

Software Engineering ビュー：ソフトウェア開発者の関心の側面を扱う。新しいシステムにお

けるソフトウェア開発の制約や機会、技術とリソースの両面から開発の進め方を考察する。

System Engineering ビュー：どのソフトウェアやハードウェア要素でシステムを構築するかと

いう点で様々な方法を提示する。既にどのような技術が組織に採用されていて、現在あるいは近

い先にどのような技術が利用可能か考察する。

Technology Architecture ビューはシステムの所有者、オペレータ、通信技術者、システム管理者の

関心事に対応する。Technology Architecture ビューは以下のサブビューから構成される。

Communication Engineering ビュー：通信技術者の関心事に対応し、ネットワーク計画と設計を

単純化するための通信設備を構築する様々な方法を考察する。また、地理的制約、バンド幅の要

件などを考慮してネットワーク要素を考察する。

Acquire のビュー：システムの所有者、調達者の要望に対応し、アーキテクチャに適合する要素

を購入するための適切なガイダンスを提供する。Acquire のビューには更に下位のビューとして

Cost と Standard のビューが存在する。

Composite ビューとしては以下のサブビューがある。

Enterprise Manageability ビュー：システムの運用、管理の関心事に対応する。様々な管理の

視点（セキュリティ、ソフトウェア、データ、コンピューティング/ハードウェア、通信）から

初の配置、更新、可用性、セキュリティ、パフォーマンス、資産管理、フォールト及びイベン

ト管理のような課題をカバーする。

Enterprise Security ビュー：組織の中の情報を保護するためのシステムのセキュリティ側面に

対応する。どのような情報が保存され処理されているか、それらをどのように活用するか、どの

ようなセキュリティ上の脅威が存在し対応するか、を考察する。


・The Open Group. : TOGAF™Version 8.1.1 "Enterprise Edition", 2006.


5.5 Microsoft の Software Factories

Microsoft の Software Factories においてもビューポイントは、アーキテクチャを記述するための観

点である。しかしながら、Software Factories ではモデル駆動開発アプローチを採用し、アプリケーシ

ョン開発の自動化を DSL（ドメイン特化言語）や文脈に沿ったガイダンス（Guidance by Context）など

で実現しようとしているため、他のビューポイント分割手法より実装面を強く意識している。また、共

通する課題に対する複数のアプリケーション開発のための Product Lines アーキテクチャ設計アプロー

チを取り入れているため、問題ドメインと解決ドメインという２つのビューポイントを追加しているこ

とも特徴的である。

図 5-5-1 Software Factories におけるビューポイント分割例

各ビューポイントには関連する資産が記述される。例えば、ツール、コンポーネント、ライブラリ、

パターン、実装に要求されるガイダンス、などである。以下は HL7 対応のソフトウェアファクトリのビ

ューポイント記述例である。

ビューポイント名ツール資産成果物（artifact）問題ドメインソリューションビルダ問題特性モデル問題構成情報解決ドメインソリューションビルダ解決特性モデル解決構成情報テスト HL7 Collaboration Port テストドライバテストガイダンステスト計画

テスト結果アプリケーションアーキテクチャHL7 Collaboration Port Code Generator 設計ガイドライン HL7 Collaboration Port Model

HL7 Collaboration Port Designer WSDL(by HL7 Application Role) WSDL(洗練された)HL7 Collaboration ModelHL7 メッセージ型仕様(XSD)コードテンプレート

インフラストラクチャ論理システムデザイナ設計ガイドライン技術アーキテクチャモデルオーケストレーションオーケストレーションデザイナ設計ガイドラインオーケストレーションモデル設計クラスデザイナ実装ガイドラインクラスモデル実装 C#開発環境 HL7 Collaboration Port Messaging Framework

実装ガイドライン C#ソースコードユニットテストドライバインストレーションユニット.NETアセンブリ

配置管理インターフェイス配置ガイドライン配置計画配置構成情報

図 5-5-2 HL7 対応のソフトウェアファクトリのビューポイント例

Software Factories では、ビューポイント間の関係も記述する。Rozanski と Woods、TOGAF ではいず


れもビューポイント間の関係は表（グリッド）で記述されているが、Software Factories ではグラフで

も記述される。またビューポイントは下位のビューポイントを持つことができツリー構造で記述される。

例えば Lenz と Wienands のソフトウェアファクトリの例である ISpySoft のビューポイントは以下の

ようにツリー構造で表わされている。

ビジネス（問題）ビューポイント

要件（解決）ビューポイント

アーキテクチャビューポイント

論理ビューポイント

コントロールフロービューポイント

分散システムビューポイント

コンポーネント構造ビューポイント

実装ビューポイント

ビジネスワークフロービューポイント

データエントリビューポイント

物理データ構造ビューポイント

ユーザーエクスペリエンス（UX）ビューポイント

ソリューション構造ビューポイント

テストビューポイント

ユニットテストビューポイント

統合テストビューポイント

システムテストビューポイント


・ Eadie, S. : A GSI's Perspective of Software Factories, Microsoft, 2006. Available from:

<http://msdn2.microsoft.com/en-us/arcjournal/bb245775.aspx>

・ Regio, M. and Greenfield, J. : A Software Factory Approach To HL7 Version 3 Solutions, Microsoft,

2005. Available from: <http://msdn2.microsoft.com/en-us/library/ms954602.aspx>

・ Lenz, G. and Wienands, C. : Practical Software Factories in .NET, Apress, 2006.


６．独自ビューポイントの定義方法

これまで、メタモデル解説や、一般に知られる代表的なビューポイントカタログを通して様々なビュ

ーポイントを紹介してきたが、後に独自のビューポイントを定義するための手法を紹介しておきたい。

Koning と Vliet は IEEE1471 の主な貢献はステークホルダと関心事における明確な方向付けにあると

したが、ステークホルダの「アクセシビリティ」と「理解容易性（understandability）」のようなド

キュメント品質の向上のためのガイダンスが必要と考えた。それが「A method for defining IEEE Std

1471 viewpoints」である。ビューポイントを定義する前に、ビューポイントをアーキテクチャ記述の

質を向上させるためのてことすること、とりわけアーキテクチャ設計とステークホルダの関心事との関

係における洞察を深めることを目的としている。

Koning と Vliet の手法のゴールは IEEE1471 のビューポイント概念に基づいたテンプレートを用い、

プロジェクトのステークホルダの関心事に適合するビューポイントを導き出すことにある。この手法に

よるアクティビティを IEEE1471 の主要概念に関連づけると以下のような図になる。

図 6-1 IEEE1471 の主要概念における Koning と Vliet のビューポイント定義技法の位置づけ

上の図のように Koning と Vliet の手法は４つのステップからなり、それぞれの成果物の作成を経て

独自のビューポイントを導き出してゆく。


ステップ成果物ステークホルダのプロファイルを集め、編集するステークホルダのプロファイル内部の設計文書を要約するアーキテクチャ設計の要約（テキスト、ダイアグラム）

コンテキストマップ要約された文書とステークホルダの関心事を関連づける "Content 2 concerns"テーブル

関心事を付与したコンテキストマップビューポイントを定義するテンプレートに記述されたビューポイント

図 6-2 Koning と Vliet の手法のステップと成果物

このように、もし特定のプロジェクトにおいてあるステークホルダの関心事により密接に適合したビ

ューポイントを定義し、それをもとにアーキテクチャを設計したい場合は既存のビューポイントカタロ

グに依らず独自のものを用意することも可能である。しかしながら、再利用可能なビューポイントを開

発するのは既存の設計文書をまとめ、かつ新たな成果物の作成をも必要とする非常に手間と時間のかか

る作業となる。特にステップ３（要約された文書とステークホルダの関心事を関連づける）からステッ

プ４（ビューポイントを定義する）へ進むにはなお一層の改善点（ガイドライン、ビューポイント例、

より正確なテンプレートの提供など）があることを Koning と Vliet も認めている。


・Koning, H. and Vliet, H. : A method for defining IEEE Std 1471 viewpoints, Elsevier Inc.,

2006.


ＩＴアーキテクチャ・メタモデルセマンティクス解説

2007 年 6 月 28 日初版

著作・監修ＩＴスキル標準プロフェッショナル・コミュニティ

ＩＴアーキテクト委員会

発行者独立行政法人情報処理推進機構（ＩＰＡ）

IT スキル標準センター〒113-6591 東京都文京区本駒込 2-28-8 文京グリーンコートセンターオフィス 16 階

TEL：03-5978-7544／FAX：03-5978-7516

http://www.ipa.go.jp/jinzai/itss/index.html


――本書の無断複製・転載を禁じます――

itアーキテクチャ・ メタモデル セマンティクス解説iii 2007 ipa all rights...

Documents

itアーキテクチャ・メタモデルセマンティクス解説iii 2007 ipa all rights...