非機能要求とアーキテクチャ分析 wg - ipa ·...

非機能要求とアーキテクチャ分析 WG 報告書

～非機能要求記述とアーキテクチャの関係分析事例研究結果より～

Ver. 1.0

独立行政法人情報処理推進機構

ソフトウェア・エンジニアリング・センター

エンタプライズ系ソフトウェア開発力強化推進委員会

非機能要求とアーキテクチャ分析WG

2011年 3月

Copyright© 201, IPA All rights reserved.

＜＜空ページ＞＞

i Copyright© 2011, IPA All rights reserved.

目次第 1 章はじめに ··············································································1

1.1. 背景と位置づけ .............................................................................. 1 1.2. 概要 ............................................................................................... 1 1.3. 本報告書の前提 ............................................................................. 2 1.4. 本報告書の想定読者 ...................................................................... 2 1.5. 本報告書の構成 ............................................................................. 3

第 2 章アーキテクチャ決定に影響する非機能要求の見極め·············4

2.1. 非機能要求とアーキテクチャの関係................................................. 4 2.2. アーキテクチャ設計プロセスの概要 ................................................. 4 2.3. 品質要求から技術的な機能要求への変換 ....................................... 6 2.4. アーキテクチャで解決する非機能要求の見極め ............................... 7 2.5. アーキテクチャ決定プロセス ............................................................ 8 2.6. アーキテクチャ決定の因果関係 ..................................................... 15

第 3 章. 参照アーキテクチャの事例研究の紹介····························17

3.1. 概要 ............................................................................................. 17 3.2. Patterns for e-business の解説 ................................................. 18

3.2.1. Patterns for e-business のパターン階層構造 .................................... 18 3.2.2. Patterns for e-business のパターン駆動アプローチ ......................... 21

3.3. 事例研究の分析結果 .................................................................... 21 3.3.1. ドライバとアプリケーションパターンの因果関係 ........................... 21 3.3.2. セルフサービスのアプリケーションパターン .................................. 23 3.3.3. アプリケーションパターンの分析 .................................................... 25 3.3.4. 基本パターン、非機能要求、ドライバの因果関係 ........................... 26

3.4. まとめ ........................................................................................... 30

付録 A 本報告書が対象にするアーキテクチャ ································31

A.1. アーキテクチャに関する定義 ......................................................... 31 A.1.1. アーキテクチャのスコープ............................................................... 31 A.1.2. アーキテクチャのビューポイント .................................................... 32

付録 B 事例研究資料 ····································································39

B.1. 非機能要求とアーキテクチャ分析のメタモデル ............................... 39 B.2. セルフサービスのアプリケーションパターン(一部)........................... 40

ii Copyright© 2011, IPA All rights reserved.

iii Copyright© 2011, IPA All rights reserved.

＜＜空ページ＞＞

第1章はじめに

1.1. 背景と位置づけ

2006 年 4 月に独立行政法人情報処理推進機構ソフトウェア・エンジニアリング・センター（以下 IPA

SEC と略す）エンタプライズ系「要求工学・設計開発技術研究部会」では、「非機能要件とアーキテ

クチャ」WG を発足、その後 IPA SEC の「非機能要求とアーキテクチャ WG」を経て「非機能要求と

アーキテクチャ分析 WG」（ここではこの 3 つの WG を総称して、当 WG と呼ぶ）の活動を通じて、非

機能要求(Non-functional Requirement、以下、NFR と略すことがある）とアーキテクチャに関するスタ

ディーを実施してきた。2006 年度には、NFR の記述とアーキテクチャの評価に関わる課題、および、

既存の技術や手法の概要を「2006 年度活動報告書」[IPA2007]で示した。2007 年度には，NFR の記述

方法をガイドにまとめ、事例プロジェクトの要件定義書を題材にして時間効率性と回複性に関する

NFR の記述を実験し、ガイドの妥当性分析・評価も合わせて「非機能要求記述ガイド」[IPA2008]とし

て公開した。2008 年度からは、他の品質特性への「非機能要求記述ガイド」の拡張、および、参照ア

ーキテクチャ（以下「RA」と略すことがある）の事例研究を通じて NFR とアーキテクチャの関係分析

を実施した。

「ソフトウェアジャパン 2011」において、IPA SEC は、「非機能要求とシステム設計－安全・安心な

CPS 構築に向けて－」の IT フォーラムセッションプログラムを提供し、当 WG は、このセッションに

おいて、「非機能要求からアーキテクチャへ－アーキテクチャの意思決定に影響する NFR の見極め－」

を紹介した。本報告書は、この発表内容をベースに、当 WG で実施した RA の事例研究を通じて得ら

れた知見とアーキテクチャの意思決定に影響する NFR の見極め手法をまとめたものである。

1.2. 概要

情報処理学会の「ソフトウェアジャパン 2011」は、テーマとして「サイバー・フィジカル・システ

ム－クラウドに組み込まれる実世界－」を取り上げている。「サイバー・フィジカル・システム

(Cyber-Physical Systems、以下 CPS と略す)」とは、実世界と情報技術（Information Technology、以下 IT

と略す）が作り出すサイバースペース（Cyberspace）が融合したシステムである。CPS は、2009 年頃

から米国で注目され始めた新しい言葉であり日本では一般的に馴染みがないが、省エネルギー化、省

資源化、低炭素化を推進するスマートグリッド、スマートハウス、スマートシティなど、スマートな

社会基盤システムの特徴を表現する言葉として注目されている。

現代は、インターネットと融合した携帯端末やディジタル家電の普及により、簡単な操作で電子商

取引やデジタル・コンテンツ・サービスが利用できる便利な IT 化社会である。サービスを利用するユ

ーザからは見えないが、IT 化社会の経済活動は、商流、金流、物流の隅々まで様々な企業の IT システ

ムが複雑に連係した複合システム(System of Systems)に依存している。これは、ある企業の 1 つの IT シ

ステムの障害や誤動作がサプライチェーンを構成する社内や他企業の IT システムに連鎖し、経済活動

に大きな影響を与えるリスクを抱えていることを意味する。そのため、IT 化社会を支える複合システ

1 Copyright© 2011, IPA All rights reserved.

ムは、CPS として捉える必要がある。CPS の品質を高めるためには、各企業の IT システムの品質に関

して、上位の複合システムに与える影響とリスク分析の重要性をあらためて認識する必要がある。

一方で、企業は、競争優位に立ち続けるために、IT を駆使した新しいビジネスを迅速に市場投入す

る必要があり、投資対効果がある IT システムを短期間に低コストで開発することが求められている。

そのため、ベストプラクティスとして参照アーキテクチャを活用して、短期間に IT システムのソリュ

ーションアーキテクチャを設計する IT アーキテクトが増えている。RA は、特定の問題領域を対象に

したソリューションアーキテクチャの成功事例に共通して見出された、典型的なノウハウを一般化し

たアーキテクチャの参照モデルであり、ビジネスに必要な機能要求を満足するだけでなく、様々な NFR

に関連するアーキテクチャの基本パターンが複合的に含まれている。

NFR とは、品質要求（信頼性要求、可用性要求、性能要求、セキュリティ要求、管理容易性要求、

保守容易性要求、変更容易性要求、など）、および制約条件（運用環境、外部システム、IT 標準、コス

ト、開発スケジュール、など）である。雛形としての RA は、特定の問題領域を対象にした前提条件

の下で、様々な NFR のトレードオフを全体適で解決している。そのため、IT アーキテクトは、RA

の基本パターンが解決している NFR、トレードオフした NFR、基本パターンと NFR の間にある因果関

係、および、それらの前提条件や原理(Principle)を理解する必要がある。RA の本質を理解しないまま

安易に真似て、個別 IT システムのソリューションアーキテクチャを設計すると、前提条件が異なる場

面や環境では原理が成立せず、全体適のバランスが崩れ、期待した NFR を満足しないリスクがある。

本報告書では、このリスクを緩和するために、NFR からアーキテクチャを策定するプロセスの中で、

アーキテクチャ上の決定(Architectural Decision)に影響する NFR を見極め、NFR の必要性(Necessity)の

正当性(Justification)、および、アーキテクチャの理論的根拠(Rationale)を明文化することの重要性に関

して、事例研究の分析結果を交えて紹介する。

1.3. 本報告書の前提

本報告書では、事業体としての企業や公的機関(以下、エンタプライズ)が価値創造や組織活動の支援

に利用するITシステムのNFRとアーキテクチャを対象とする。本報告書が対象にするITシステムは、情

報技術に基づいた情報システム(Information Technology based Information System)であり、IT製品(ハード

ウェアやソフトウェア)を基盤として主にアプリケーションソフトウェアを開発対象とするソフトウェ

ア集約システム（Software-Intensive Systems）[IEEE 1471-2000]である。本報告書が対象にするアーキテ

クチャの定義と位置づけに関しては、付録Aの補足資料に示している。また、本報告書が対象にする

NFRの記述方法に関しては、当WGのIPA発行物「非機能要求記述ガイド」[IPA2008] に示している。

1.4. 本報告書の想定読者

本報告書の想定読者は、次の立場の IT アーキテクトとしている。

① IT システムのオーナーと同じ法人に所属する「企画・設計」担当の IT アーキテクト

② IT システムのオーナーから設計を委託される IT アーキテクト

③ IT システムのオーナーから分析・評価を委託される IT アーキテクト



本報告書は、想定読者が以下の IPA 発行物を読解していることを前提としている。

□ 非機能要求とアーキテクチャ WG 2006 年度活動報告書 [IPA2007a]

□ 非機能要求記述ガイド [IPA2008]

□ ＩＴアーキテクトコミュニティの報告書

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

□ 参照アーキテクチャ調査報告

http://www.ipa.go.jp/jinzai/itss/activity/ITA/2004/RA.pdf

□ 参照アーキテクチャ調査報告（2005 年度版）

http://www.ipa.go.jp/jinzai/itss/activity/ITA/2005/ITA2005_RA.pdf

1.5. 本報告書の構成

本報告書の構成は次のとおり。

第1章はじめに

第2章アーキテクチャ決定に影響する非機能要求の見極め

第3章参照アーキテクチャの事例研究の紹介

付録 A 本報告書が対象とするアーキテクチャ

付録 B 事例研究資料

付録 A、付録 B は、第 2 章、第 3 章を補完するための内容を記述した。

第2章アーキテクチャ決定に影響する非機能要求の見極め

用語解説：IT システム

IPA SEC エンタプライズ系プロジ

ェクトでは、民間企業や公的機関

の情報システムを対象にしている。

本報告書では、情報技術に基づ

いた情報システム (Information

Technology based Information

System)を略して IT システムとす

る。IT システムは、IT 製品(ハード

ウェアやソフトウェア)を基盤として

主にアプリケーションソフトウェアを

開発対象とするソフトウェア集約シ

ステム (Software‐Intensive

Systems） [IEEE 1471‐2000]の一

つである。

2.1. 非機能要求とアーキテクチャの関係

IT システムのアーキテクチャが NFR に強く依存することは IT アー

キテクトに広く知られている。しかし、「機能要求以外の全ての要求で

ある」と NFR を広義に解釈すると、アーキテクチャで全ての NFR を満

足できるとは言えない。しかし、アーキテクチャ(静的な構造や動的な

振る舞い)で解決する必要がある NFR を見極めることは、IT アーキテ

クトの重要な責務である。

アーキテクチャ上重要な要求(ASR)

欧米では、アーキテクチャ決定に影響する NFR に関して、様々な研

究や実践が報告されている。 Rational, Philips, Nokia, Siemens,

Lockheed-Martin, IBM のソフトウェアアーキテクトがソフトウェア

アーキテクチャの分析と評価に関するノウハウをまとめた

SARA(Software Architecture Review and Assessment Report)[SARA2002]や

米国カーネギーメロン大学 SEI（ソフトウェアエンジニアリングインス

ティテュート）のソフトウェア集約システムのアーキテクチャ品質評

価手法 QUASAR (A Method for the QUality Assessment of

Software-Intensive System ARchitectures)[Firesmith2006]によると、IT シス

テムのアーキテクチャに影響する品質要求があり、アーキテクチャ上

重要な要求 ASR(Architecturally Significant Requirement)と呼ばれている。

SARA によると、ASR かどうか識別する方法として、2 つの判定基準が

示されている。

用語解説：アーキテクチャ

本報告書では、IT システムの基本

構造を構成するコンポーネント群

（アプリケーションソフトウェア、ミド

ルウェア、システムソフトウェア、ハ

ードウェア、ネットワークなど）、コン

ポーネント間の相互関係、IT シス

テムの利用・運用環境との関係に

関する IT システム全体の機能構

造や配置構成を規定するアーキテ

クチャを対象とする。本報告書で

は、IT システムのコンポーネントの

１つであるアプリケーションソフトウ

ェアのプログラミングレベルの設計

を対象にしない。

1. その要求の実現(Realization)に複数のコンポーネント、または、

システム全体が必要になる場合、その要求は、ASR である。

コラム：ASR

米国カーネギーメロン大学 SEI

は、SARA で提唱されたソフトウェ

アアーキテクチャに影響する品質

要求/ASR を、QUASAR で航空

機、宇宙船、艦船などの複雑な製

品システム (Complex Product

System)のシステムアーキテクチャ

に拡張している。 2. その要求の関心事(Concern)が単一のコンポーネントだけで実現

できる場合、その要件は、ASR ではない。

つまり、NFR には、機能要求に変換して IT システムの構成要素（コンポーネント）に割り当てでき

ず、アーキテクチャで解決する必要がある品質要求があることを意味している。

2.2. アーキテクチャ設計プロセスの概要

当WGを通じて見出されたNFRからアーキテクチャを設計するプロセスの概要を図 2-1に示してい

る。開発するITシステムの要求は、ステークホルダ要求から定義される。ここで重要なことは、ITシ

ステムを直接的に利用するユーザの要求だけでなく、システム開発者や運用者、導入効果を評価する


経営層なども含め、開発するITシステムのライフサイクルにおいて、何らかのメリットやデメリット

を受ける全ての利害関係者の要求をステークホルダ要求の対象にすることである。

開発するITシステムの要求

非機能要求(NFR)

品質要求制約

その他の要求

構成要素

ソフトウェア(機能)

アプリケーション

技術機能

ハードウェア(資源)

機能要求

機能分解

能力・資源要求の割り当て

非機能要求の割り当て

アーキテクチャ

静的構造

動的振る舞い

開発・テストプロセス

ITサービス管理プロセス

保守プロセス

関連するITシステム

業務部門の人間系プロセス

移行プロセス

展開プロセス

教育プロセス

アーキテクチャ要求(ASR)

成功事例/参照アーキテクチャ(RA)

ステークホルダ要求外部経営層業務部門 IT部門

能力・資源要求

図 2-1 アーキテクチャ設計プロセス

コラム：ステークホルダ要求

開発する IT システムの要求は必

要条件であるが、これだけではス

テークホルダ要求の十分条件を

満たしていない。業務部門の人間

系プロセス、関連する他の IT シス

テム、開発する IT システムのライ

フサイクルプロセス（開発、テスト、

移行、展開、教育、保守・改修、

機能拡張など）、IT サービス管理

プロセスなど、その他の要求も併

せた上でステークホルダ要求の必

要十分条件を満足させる必要が

ある。

開発する IT システムの要求は、機能要求として定義できるものがあ

る。機能要求は、機能の「あり・なし」で識別でき、更に下位の機能

に分解して IT システムの構成要素に割り当てることができる。

一方で NFR は、機能の「あり・なし」ではなく、機能する上で必要な

品質要求や制約として定義される。NFR には、IT システムの構成要素

に割り当てることができる技術的な機能要求に変換できるもの

品質要求から技術的な機能要求への変換（2.3参照）がある。もちろん、

技術的な機能要求だけでNFRを満足できるわけではなく、多くの場合、

その他の要求を前提条件として定義する必要がある。

アーキテクチャを設計するために、アーキテクチャで解決する必要

があるASR(図 2-1のアーキテクチャ要求)を識別する必要がある。

終的に、設計したアーキテクチャに基づいてサイジングを行い、IT

システムが達成する能力の数値目標として能力要求 (Performance

Requirement)、および、必要な資源量として資源容量要求(Resource

Capacity Requirement)を定義し、構成要素のハードウェアやソフトウェアの構成パラメータに割り当て

て、システム構成を決定する。

用語解説：機能要求

ステークホルダ要求に明示されて

いる機能要求は、容易に識別でき

る。その他の機能要求に関して

は、成功事例や参照アーキテクチ

ャから開発する IT システムに必要

な機能要求を見つけている。


2.3. 品質要求から技術的な機能要求への変換

機能要求は、ITシステムの機能を動詞で表現するが、NFRの品質要求は、ITシステムの品質特性を形

容詞や副詞で表現する。例えば性能要求は「応答が速い」、セキュリティ要求は「攻撃に強い」、可用

性要求は「回復が早い」などである。品質特性のままでは、実現でき

ないため、技術的な機能要求に変換し、アーキテクチャの構成要素に

割り当てる必要がある（図 2-2）。例えば、性能要求は、「応答を早く

するため、動的なページをリバースプロキシにキャッシュする」。セ

キュリティ要求は、「攻撃に強くするため、パイプ・アンド・フィル

タでウィルスを検出する」。可用性要求は、「HA(High Availability)クラ

スタで自動的にテークオーバーする」などである。

IT アーキテクトは、自分自身の経験に基づく知見と成功事例や RA

を参考にして、NFR を IT システムの構成要素に割り当てることがで

きる技術的な機能要求に変換していると考えられる。

用語解説：参照アーキテクチャ

(RA)

ソフトウェアのコンポーネント設計

や実装に関する粒度の小さいデ

ザインパターンやイデオムではな

く、開発するソフトウェアの基盤と

なるハードウェアやシステムソフト

ウェア、さらに、利用・運用される

環境も含めた IT システム全体の

アーキテクチャパターンのベスト

プラクティスをまとめたものである。

図 2-2 品質要求から技術的な機能要求へ変換


2.4. アーキテクチャで解決する非機能要求の見極め

アーキテクチャで解決するASR

NFRには、技術的な機能要求に変換して特定の構成要素（コンポー

ネント）に割り当てできず、アーキテクチャで解決する必要があるASR(

図 2-3アーキテクチャ要求)が存在する。例えば、複雑な製品システム

(Complex Product System)である自動車は、何万点もの部品からできてお

り、それぞれに機能要求や品質要求が分解され割り当てられている。

言うまでもなく、部品の集まりの状態では、自動車として機能しない。

完成車には、自動車の部品に割り当てられた機能要求や品質要求だけ

でなく、自動車全体で達成する品質要求であるASRがあり、部品の配

置や接続でASRを満足するアーキテクチャが存在する。ところが、完

成車と部品の集まりを比較した場合、質量など物理的な特性だけでな

く、原材料費も同じであることが容易にわかる。これは、完成車に必

要なASRを実現するアーキテクチャは、物理的に存在する部品の集ま

りには含まれておらず、論理的な設計として存在していることを意味

する。

コラム：ASR の例

技術的な機能要求に変換して１

つの構成要素（コンポーネント）に

割り当てることができる NFR は、

ASR ではないと考えられる。例え

ば、性能要求の応答時間を良く

するには、キャッシュ機能が「あ

る」だけでは不十分である。IT シ

ステムの静的な構造上、「どこにキ

ャッシュ置けば効果的か」、動的

な振る舞い上「どのような仕組み

でキャッシュの有効期限切れを判

断するのか」などを考えなくてはい

けない。IT アーキテクトは、ASR

に関して自覚しているかどうか別

にしても、自分自身の経験に基づ

く知見および成功事例やRAを参

考にして、ASR を満足するアーキ

テクチャを設計していると考えられ

る。

IT システムの開発プロジェクトでは、機能要求を階層的に機能モジュールまで分解し、単体テスト

の後、結合テスト、システムテストまで組み上げる V モデルが主流である。しかし、デカルトの還元

主義だけで考えられた IT システムは、適化されたアーキテクチャ(静的な構造や動的な振舞い)の設

計が重視されず重要な ASR を見落としたまま、機能要求の開発とテストだけを進めてしまうことがあ

る。そのため、システムテストやオペレーションテスト（悪の場合、本番稼動後）になって初めて、

期待した品質を満たさず、機能しない（使えない）ことに気づくことになる。

また、NFR やアーキテクチャは、初期の要求に基づいて開発された IT システムを利用する時だけを

考えるのではなく、将来の機能拡張や保守・改修しやすいようにライフサイクルの要求を先取りして

設計しておくことが重要である。


図 2-3 アーキテクチャ要求

2.5. アーキテクチャ決定プロセス

図 2-5のシステムズエンジニアリングプロセス(Systems

En

図 2-4のアーキテクチャ決定プロセスは、

gineering Process）[IEEE1220-2005]や図 2-6の米国カーネギーメロン大学SEI Architecture Tradeoff

Analysis Method(ATAM)をヒントにして、当WGで再構成したものである。

図 2-4 アーキテクチャ決定プロセスの 4 つの重要な分析


図 2-5 システムズエンジニアリングプロセス

スクのある場面・稼動状況に対応するシステムの運転モード

成功事例やRAを参考にして、ステークホルダ要求を引き出したとし

はできない。図 2-4に示すように、ITシステムのライフサイクルプロセ

スの様

用語解説：システムズエンジニアリングプロセス

システムズエンジニアリングプロセスや INCOSE(The INternational

COuncil on Systems Engineering)の論文等に基づいて作成された代表的な要求とアーキテクチャの決定プロセスである。要求分

析、機能分析それらに基づくアーキテクチャ設計結果の候補を、多面的なシステム分析を繰り返しながら要求とアーキテクチャを絞り

は、IEEE1220‐2005で定義されており、米国Military Standard

込んでいくプロセスである。

リ

ても、必ずしもアーキテクチャに影響する重要なNFRを定義すること

々な局面で起きるビジネスの変化(新規出店、事業統廃合、海外

展開など)を場面(Situation)として捉える必要がある。また、場面に起こ

りえる稼動状況(Operating Condition)に関しては、通常時に加えて、サー

ジ（予想可能なピーク）やバースト（予想不可能なピーク）など、平

時だけでなく有事を想定することが重要になる。起こりえるリスクの

あるシナリオ（ミスユースケース、フェイルケース、チェンジケース

など）を設定し、ステークホルダ要求として明示されていない隠れた

要求を明らかにした上で、場面と稼動状況に対応した運転モード(Mode

用語解説：場面(Situation)

場面の考え方は、Concept of

Operations(以降、ConOps と略

す) [IEEE1362‐1998]に基づいて

テいる。場面は、開発する IT シス

クルプムのライフサイロセス（開

発、テスト、移行、展開、教育、保

守・改修、機能拡張など）に設定

する。

用語解説：稼動状況(Operating

Condition)

稼動状況の考え方は、コントロー

ルケース (Control Case)

[Zou2006]に基づいている。状況

設定したケースに基づいて品質

要求のサービスレベルを制御する

コントロールケースで NFR を記述

する。


of Operation i)毎に提供可能な機能やサービスレベルを実現するアーキテクチャを設計しておく必要が

ある。あらかじめ想定した場面と稼動状況に対応した運転モード毎（正

常、縮退、制限、代替）に提供可能な機能やサービスレベルを明確に

できるため、ステークホルダにとってもITシステムに対して本質的に

必要な機能要求とNFRが理解しやすくなる。このアプローチに関して

は、当WGの「非機能要求とアーキテクチャWG 2006 年度活動報告書」

[IPA2007a]、および、「非機能要求記述ガイド」[IPA2008]に解説してい

るので詳細な説明はこの 2 つの文献を参照のこと。

用語解説：運転モード(Mode of

Operation)

運転モードの考え方は、ConOps

に基づいている。ConOps では、

IT システムの構想段階で、あらか

じめ想定した場面と状況に対応す

る運転モードを設定する。

NFRとアーキテクチャの分析と評価

図 2-4のアーキテクチャ決定プロセスに示したセンシティビティ分析、コンフリクト分析、トレード

ギーメロン大学SEI のATAMに基づいている。オフ分析、リスク分析は、米国カーネ

図 2-6 ATAM プロセス

図 2-6に引用したATAMのプロセス（A Conceptual Flow of the ATAM [SEIb]）は、これから開発するシ

テム、または、本番稼動済のシステムのアーキテクチャに関して、品質特性に影響があるシナリオ

に

ス

基づいてトレードオフ分析を行う手法である。

ビジネスドライバ(Business Drivers)をモチベーション(動機付け)として、品質特性(Quality

Attributes)に影響があるシナリオを設定する。

アーキテクチャの計画(Architectural Plan)やアプローチ(Architectural Approaches)からアーキテ

i Mode of Operation: 「非機能要求記述ガイド」[IPA2008]では、Operation Mode としていたが、本報告書では、ConOps [IEEE1362‐1998]に合わせた。


クチャ上の決定(Architectural Decisions)を識別する

offs)を識別する

る

クチャを洗練する

練を反復する

全ての品質特性を同時に良くする万能の設計はなく、図 2-7に示すような品質特性間のトレードオフ

2007a]。

フが

必要になっているのか理論的根 n 本報告書では、アーキテクチ

ャの基本パターンに対して、ATAMのセンシティビティポイント(Sensitivity Point)とトレードオフポイ

ン

SEI の ATAM によると、アーキテクチャのパターンには、主目的の品質特性をよくするアーキテク

チャの仕掛け(Architectural Mechanism)があり、品質特性に基づく設計の根本(Quality Attribute Design

ote CMU/SEI-2000-TN-007]と呼んでいる。また、欧州では、アーキ

テ

決定されたアーキテクチャからセンシティビティポイント(Sensitivity Points)を識別する

センシティビティポイントからトレードオフ(Trade

トレードオフをリスク分析し、残存するリスク(Risks)を識別する

残存するリスクを緩和/回避するリスクテーマ(Risk Themes)を策定す

リスクテーマをフィードバックして、ビジネスドライバとアーキテ

残存するリスクが許容できる(Non-Risks)までアーキテクチャの分析と洗

品質特性間のトレードオフ関係

関係が経験的に知られている[IPA

図 2-7 品質特性間のトレードオフ関係

しかし、図 2-7に示すような品質特性の「○○性(-ilitiy)」では、具体的に何が原因でトレードオ

拠(Ratio ale)が判然としない。そのため、

ト(Trade-off Point)を識別する分析手法を採用している。

品質特性に関係する基本パターン

Primitive)[Len Bass et al., Technical N

クチャのパターンから識別した解決策の本質的な仕掛けをアーキテクチャの根本(Architectural

Primitive)［Uwe Zdun at al., Modeling Architectural Patterns Using Architectural Primitives, OOPSLA ’05,

October 2005] と呼んでいる。


これらの用語は、日本語として馴染みが薄いため、本報告書では、こ

れを基本パターン(Essential Pattern)と呼ぶこととし、「特定の場面や稼動

状況に想定されるリスクや制約を前提として、主目的の品質特性に貢

献

チャ上のパラメータ(Architectural Parameter)にな

っ

セ

シこと(キャ

ッシュヒット率が高くなるこ

品質特性を良くするセンシティビティポイントは、

他

するアーキテクチャのパターンが品質を良くする本質的な仕掛けで

ある。」と定義する。

センシティビティポイントは、基本パターンを構成するコンポーネン

トやその関係の特徴(Property)として見出され、主目的とする品質特性

を良くするアーキテク

ている。例えば、図 2-8の例では、ネットワークファイルシステム

(NFS)など、データをキャッシュするアーキテクチャの場合、データアク

フォーマンスの品質特性を良くする効果を大きくするためには、キャッ

ッシュ無効率が小さい)、および、キャッシュのデータ容量が大きくキャ

とが前提条件である。しかし、この前提条件を満たさない場合には、意図したパフォーマンスの品質

特性が良くならない。これら前提条件は、アーキテクチャのパラメータであり、センシティビティポ

イントになる。

トレードオフポイントは、同時に満足できないコンフリクト(対立)

している複数の品質特性に影響するアーキテクチャのパラメータで

ある。一般に、ある

コラム：パターン言語

Christopher Alexander により建

築・都市計画の分野において、タ

ウンやコミュニティ、建物の外観、

建物の構造、インテリアなど、大構

が異なる造から小構造まで粒度

様々なパターンを体系化した言語

である。建築以外に様々な分野に

応用されており、ソフトウェア・エン

ジニアリング分野でも、様々な書

籍や論文でパターンが提案され

ている。

スの応答時間を短くしてパ

ュ有効時間が長い

の品質特性を悪くするトレードオフポイントにもなっていること

が知られている。例えば、図 2-9の例では、分散データベースなど、

データをレプリケーションするアーキテクチャの場合、レプリカの頻

度を短くするとデータの新性(Data Currency)の品質特性が良くなる

が、読み取りロックやサーバーの負荷が増加して性能が悪くなる。

コラム：パターン

自動車や建築物など物理的な形

があるシステムは、完成物の外観

や内部構造を視覚的に設計図で

表現できるが、ソフトウェア中心シ

システムの場合、ステムである IT

直接的に見ることができないソフト

ウェアの概念や論理を視覚化した

モデル図で表現する。そのため、

よく知られた「ものごと」に喩えるこ

とで、ソフトウェアの構造や振る舞

いを共通に理解できるパターン言

語を活用することが必要になる。


図 2-8 センシティビティポイントの例

図 2-9 トレードオフポイントの例

このようなトレードオフは、例えばクラウドコンピューテイングで話題になっている CAP 定理

(C

onsistency, Availability and Partition Tolerance Theorem)にも当てはまっており、キャッシュサーバーに

データを物理的(空間的)に分散させて(Partition Tolerance)、マスターデータサーバーの処理能力の限界

やサービス提供時間の制約に依存せずに、大量のユーザに早い応答時間で何時でもデータアクセスサ

ービス(Availability)を提供するためには、データの新性や一貫性(Consistency)をトレードオフする必

要がある。


アーキテクチャ決定プロセスの 4 つの分析

当 WG では、優先順位の正当性根拠(Justification)と効果・影響の理論的根拠(Rationale)が判然として

いない品質特性間のトレードオフ関係を明確にするため、ATAM のプロセスを 4 つの分析に再構成し

ている。

1. センシティビティ分析

アーキテクチャ要求(ASR)を満足する基本パターンを識別し、それが品質特性に良い効果を現

す仕組みとその理論的根拠(Rationale)を明らかにする

2. コンフリクト分析

基本パターンが副作用として他の品質特性に悪い影響を与えるアーキテクチャ制約とその理

論的根拠を明らかにする

3. トレードオフ分析

品質特性に良い効果を得る NFR、および、悪影響を被る NFR に関して、それぞれの背景にあ

るステークホルダ要求間の優先順位とその正当性根拠(Justification)に基づいて優先する NFR

を選択する

4. リスク分析

トレードオフによりサービスレベルが低下する NFR(品質要求)に関して残存するリスクを識

別し、ステークホルダ要求への影響による損失とその正当性根拠を明らかにする。

アーキテクチャ決定プロセスは、「リスクなし」と判断されるまで NFR とアーキテクチャの分析と

洗練が反復される。終的に、IT アーキテクトは、決定した NFR とアーキテクチャに関して、選択し

たパターン名やそのモデル図を示すだけでなく、決定理由に明記して文書化する必要がある。

アーキテクチャ決定に関する正当性根拠(Justification)と理論的根拠(Rationale)

IT アーキテクトは、アーキテクチャ決定の理由として 2 つの根拠に説明責任がある。

1 つ目は、正当性根拠(Justification)である。これは、ステークホルダ間の利害関係から影響を受け、

NFR の目的に関して損得の価値観を倫理(Ethics)で説明する必要がある「情の世界」である。IT システ

ムの品質を良くする NFR の必要性に関して、その背景にあるステークホルダ要求のドライバ/モチベー

ション(動機付け)になっているビジネスゴールまたはリスクの優先順位を明らかにすることが重要で

ある。

2 つの目は、理論的根拠(Rationale)である。これは、技術上の制約から影響を受け、アーキテクチャ

に関して仕掛けを論理(Logic)で説明できる「理の世界」である。IT システムの品質を良くするアーキ

テクチャの仕掛け(Mechanism)とその原理(Principle)を明らかにすることが重要である。

一般に、アーキテクチャ決定の理由には、正当性根拠だけが記述されていることが多い。また、正

当性根拠に関しても、品質要求の必要性ではなく、既存のIT技術やIT標準、プロジェクトの予算やス

ケジュールなど、制約だけを記述している例をよく見かける。図 2-10に示すとおりITアーキテクトが

アーキテクチャ決定に対して説明責任を果たすためには、アーキテクチャ決定の理由として正当性根

拠(Justification)と理論的根拠(Rationale)を区別し、その前提条件と仮説も文書化する必要がある。


図 2-10 アーキテクチャの正当性と理論的根拠

2.6. アーキテクチャ決定の因果関係

当WGが事例研究を通じて得た結論として、NFRとアーキテクチャ決定に関連する 2 つの因果関係の

流れを図 2-11を示している。

図 2-11 アーキテクチャ決定の因果関係

1 つ目は、目的から手段への因果関係の流れである。ビジネスのドライバ/モチベーション（目的）

からビジネス要求、ステークホルダ要求、IT 要求、NFR、品質要求、ASR 要求、IT アーキテクチャ(手



段)まで目的-手段展開される。この流れでは、因果関係の妥当性は必要性や正当性根拠に依るため、ア

ーキテクチャは NFR の品質要求や ASR の優先順位で、NFR は IT 要求の優先順位で、ステークホルダ

要求はビジネス要求の優先順位で決定されるべきである。そして、ビジネス要求の優先順位は、ビジ

ネスゴールやリスクに対して全体適になるように決定すべきである。しかし、大抵のプロジェクト

では、特定のステークホルダや下部組織のゴールやリスクに限定した局所適になり、全体適にな

るビジネス要求の優先順位を決めることが難しい。欧米では、企業の社会的責任 CSR(Corporate Social

Responsibility)や企業倫理(Corporate Ethics)を背景にした企業行動指針(ビジネス・ポリシー)に基づいて

EA(Enterprise Architecture)を策定し、基本原則（ガイディング・プリンシプル）やアーキテクチャプリ

ンシプルを定めて、ビジネス要求、IT 要求、品質要求の優先順位を組織的に意思決定する制度が多く

の政府系機関や企業に導入されている。しかし、日本では、このような制度の導入事例は少ない。NFR

とアーキテクチャの普及が日本で遅れている原因の一つがここにあると考えられる。

2 つ目は、原因から結果（効果・影響）への因果関係の流れである。アーキテクチャの仕掛け

(Mechanism)から得られる主効果と副作用による悪影響がビジネスのゴールやリスクまで原因-結果展

開される。この流れでは、因果関係の妥当性は理論的根拠に依るため、定石とした基本パターンの原

理やその前提条件と仮説を明らかにするべきである。特に、成功事例や RA を参考にしてアーキテク

チャを決定する場合、様々な NFR に関連するアーキテクチャの基本パターンが複合的に含くまれてい

るため、本報告書で紹介した手法で成功事例や RA を分析・評価した上で、重要な ASR と基本パター

ンを見極めてから適用するべきである。

第3章. 参照アーキテクチャの事例研究の紹介

3.1. 概要

当WGでは、NFRとアーキテクチャの関係分析を行う上で、分析結果の公開に差し支えない実在のIT

システムを選定することが難しいため、TOGAFで紹介されているRAの 1 つであり、インターネットで

公開されているIBM Patterns for e-businessi [IBM2000]を研究材料とした。

この事例研究では、ATAM のアーキテクチャ分析アプローチ[SEIb]を参考にして、複数のアプリケー

ションパターンに含まれる基本パターンと NFR の関係、ステークホルダ要求、ドライバ/モチベーショ

ンまで因果関係の解読を試みた。手順を以下に示す。

複数のアプリケーションパターンの違いを決定づけている基本パターンとNFR(品質要求と制

約)を識別する

アプリケーションパターン選択の動機づけ（モチベーション）になっているドライバと基本

パターンの間にある複雑な因果関係を可視化する

i © IBM Corporation 2004, 2010. All rights reserved


3.2. Patterns for e-businessの解説

初に、当 WG が NFR とアーキテクチャの関係分析の事例研究で題材とした Patters for e-business に

関して、公開されている内容を基に概要を解説する。

3.2.1. Patterns for e-businessのパターン階層構造

Patterns for e-businessは、e-businessのベストプラクティスに共通して見出されるパターンを専門分野

や抽象度が異なる複数のビューポイントで体系化し、構造化された参照アーキテクチャ（図 3-1）とし

て提供されている。

図 3-1 Patterns for e-business パターン階層構造

(1) 複合パターン(Composite patterns) ビジネスパターンの上位構造として、電子商取引(e-Commerce)、電子市場(e-Marketplace)、ポータル

(Potals)、アカウントアクセス(Account Access)が複合パターンとして定義されている。複合パターンは、

基本的なビジネスパターンを統合パターンで組み合わせることにより、e-businessの多様な目的や要件

に適合する複雑なパターンの創造を可能にしている。（図 3-2）


図 3-2 複合パターン e-Commerce

(2) ビジネスパターン(Business patterns) e-business を通じてユーザ(User)、ビジネス(Business)，および、データ(Data)の間で行われる取引や情

報アクセスのパターンとして、以下の 4 つのビジネスパターンが定義されている。

Self-Service (U2B)：コールセンターやサービス窓口の担当員に取引を依頼せず、ユーザが自分

自身で双方向の電子的なネットワーク（インターネットなど）を利用して e-business と直接的

に取引する形態である。Patterns for e-business では、企業(Business)と消費者(Consumer)の取引

を意味する一般的な B2C(Business to Consumer)に限定せず、社外ユーザだけでなく、社内ユー

ザも含めて U2B(User to Business)と定義している。

Collaboration (U2U)：共通の目的のために複数のユーザが e-business を通して双方向の電子的

なネットワーク（インターネットなど）を利用し共同作業(Collaboration)する形態である。

Patterns for e-business では、消費者間の取引を意味する一般的な C2C(Consumer to Consumer)に

限定せず、外部ユーザや企業の社内ユーザも含めて U2U(User to User)と定義している。

Information Aggregation (U2D)：外部ユーザや企業の社内ユーザが e-business を通して複数の異

なる情報ソースから様々な文字、映像、動画、音声などデジタルデータにアクセスする形態

である。このビジネスパターンは、電子商取引の一般的な形態として命名されていないが、

Patterns for e-business では、U2D(User to Data) と定義している。

Extended Enterprise (B2B)：企業間の取引を意味する一般的な B2B(Business to Business)と同じ

であるが、e-business の IT システム間の電子取引に限定した形態である。取引先企業のユーザ

が自分自身で e-business と直接的に取引する場合は、Self-Service (U2B)である。

(3) 統合パターン(Integration Pattern) 基本的なビジネスパターンを組み合わせて複合パターンを作成できようにするため、2 つの統合

パターンが定義されている。

アクセス統合(Access Integration)：ユーザが利用する様々なデバイスと e-business システムの間

のアクセス統合パターン


アプリケーション統合(Application Integration)：外部システムや企業内の関連システムと

e-business システムの間のアプリケーション統合パターン

プロセス統合(Process Integration): 分散したプロセス間の同期/非同期インタラクションによる

複数システム間のアプリケーション統合

データ統合(Data Integration): データ転送、データリプリケーション、リモートデータアクセ

スなどによる複数システム間のアプリケーション統合

(4) アプリケーションパターン(Application Pattern) ビジネスパターンと統合パターンには、様々な要件に対応できる複数のアプリケーションパターン

が定義されている。アプリケーションパターンの選択の動機付けになっているビジネスドライバ

(Business Driver)およびITドライバ(IT Driver)を表形式(表 3-1)で示し、目的に合った手段としてアプリ

ケーションパターンを選択しやすくしている。

アプリケーションパターンは、標準化されたテンプレートにモデル図とパターン記述で解説されて

いる。

アプリケーションパターンは、プレゼンテーション、ビジネスロジック、データを分離した論理層

(Logical Tier)によりアプリケーションの構成要素をモデル化している。論理層間のインタラクションの

タイプは、同期(Synchronous)、または、非同期(Asynchronous)のラベルを接続線に付けて表現している。

表 3-1 ビジネスドライバおよび IT ドライバの関連表

(5) ランタイムパターン(Runtime Pattern) アプリケーションパターンには、様々な要件に対応できる複数のランタイムパターンが定義されて

いる。ランタイムパターンは、アプリケーションの構成要素(構成要素(論理層やデータストア)だけで

なく、テクニカルな構成要素も定義され、構成要素の実行基盤をノードでモデル化している。また、

ノードが配置されるネットワークをゾーンでモデル化し、ノード間の線分で通信接続を表現している。


(6) 非機能要求パターン図 3-1には示されていないが、Patterns for e-businessでは、ビジネスパターンや統合パターンのアプリ

ケーションパターンから選択するランタイムパターンに共通する非機能要求の解決策を補完するた

め、高可用性(High Availability)と高性能(High Performance)の非機能要求に特化した 2 つのランタイムパ

ターンが定義されている。この 2 つのNFR以外に関連するアーキテクチャパターンは、アプリケーシ

ョンパターンやランタイムパターンに基本パターンとして暗黙的に含まれている。

3.2.2. Patterns for e-businessのパターン駆動アプローチ

Patterns for e-business は、e-business の参照アーキテクチャを提供しているだけでなく、以下のような

ステップで、参照アーキテクチャを活用してビジネス目的やドライバに適合するソリューションアー

キテクチャを短期間に設計するパターン駆動アプローチを紹介している。

① e-business のニーズに合ったビジネスパターン、統合パターン、複合パターンを選択する

② e-business 固有のビジネスドライバに合ったアプリケーションパターンを選択する

③ IT ドライバに合ったランタイムパターンを評価し選択する

④ ガイドラインを評価し、ランタイムパターンにマッピングされた製品を選択する

3.3. 事例研究の分析結果

本報告書では、Patterns for e-business の e-business に共通に見られるビジネスパターンであるセルフ

サービスから 3 つのアプリケーションパターンを選択し、ドライバ、NFR、およびアプリケーション

パターンに含まれる基本パターンの間にある因果関係を分析した。Patterns for e-businessは、ビジネス

パターンや統合パターン別にアプリケーションパターンを選択するモチベーションとなるビジネスド

ライバ(Business Driver)やITドライバ(IT Driver)を関係表(表 3-1)で示している。しかし、アプリケーシ

ョンパターンに含まれている基本パターンとNFR(品質要求や制約)、および、NFRとドライバの因果関

係は明示的な表形式で可視化されていない。そのため、ドライバとの関係表に基づいて選択したアプ

リケーションパターンがどのNFRの品質特性を良くしているのか、また、トレードオフによりどのNFR

の品質特性を悪くしているのか、パターン記述から読み取る必要がある。本事例研究ではアプリケー

ションパターン選択の分かれ目になるNFR、および、3 つのアプリケーションパターンの違いを決定づ

けている基本パターンの識別を試みた。これが識別できればNFRとアーキテクチャの因果関係を明確

にできる。

3.3.1. ドライバとアプリケーションパターンの因果関係

Patterns for e-businessでは、ビジネスドライバとITドライバからアプリケーションパターンを簡単に

選択できるデシジョンテーブルとして表 3-1が提供されている。3 つのアプリケーションパターンに関

連する部分を翻訳して表 3-2と表 3-3に示す。


表 3-2 ビジネスドライバとアプリケーションパターンの関係表


パターン

ビジネスドライバ

スタンドアロン

シングルチャネルルーターエージェント

迅速なビジネス開始i ○

複数のデリバリー・チャネルの統合 ○ ○

顧客から見たビューの統一ii ○

一括カスタマイズ iii ○

注）セルフサービスから 3 つのアプリケーションパターンについて、一部のビジネスドライバだけ引用している。

表 3-3 IT ドライバとアプリケーションパターンの関係表


パターン

IT ドライバ

スタンドアロン

シングルチャネルルーターエージェント

アプリケーションの複雑さを小化 ○

TCOの小化iv ○ ○

バックエンドアプリケーションの統合化 ○ ○

保守性の向上 ○ ○

注）セルフサービスから 3 つのアプリケーションパターンについて、一部の IT ドライバだけ引用している

このデシジョンテーブルでは、「迅速なビジネス開始」や「アプリケーションの複雑さを小化」を意図

する場合は、「スタンドアロンシングルチャネル」が良く、「ルーター」や「エージェント」は選択さ

れない。しかし、ドライバであるステークホルダ要求の達成に必要な NFR(品質要求や制約)、特にシ

ステム全体のアーキテクチャで解決する必要があるアーキテクチャ上、重要な要求 ASR(Architecturally

i 迅速なビジネス開始(Time to market)： Patterns for e‐business では、バックエンドシステムとデータベースの変更の

小化、およびバックエンドのコードを再利用することで、短時間での e‐business ソリューションの開発・配置を容易にし、迅速にビジネスを立ち上げることを指している。

ii 顧客から見たビューの統一(Unified Customer View)：顧客満足度の向上による収益性向上のために、複数の製品ラインやサービスに対して一貫性のある統一された見え方(ビュー)を顧客に提供する顧客中心(Customer‐centric)のビジネス戦略で製品中心(Product‐centric)と対比される。シングルカスタマービュー(Single Customer View)とも呼ばれ、コールセンターや EC ショップ(Webshop)は、ワンストップサービス(One Stop Service)やワンストップショップ(One Stop Shop)と呼ばれる。

iii 一括カスタマイズ(Mass Customization)：大量生産(Mass Production)と同程度の低コストで、パーソナライゼーション(Personalization)を提供して、オーダーメードやカスタムメイドに近い顧客の個別要望に応えるビジネス戦略である。

iv TCO の小化(Minimize Total Cost of Ownership)： e‐business 分野での新アプリケーションを構築していると、多くの組織では、短期的なビューで、開発コストやハードウェア、ソフトウェアの調達コストにとらわれがちである。その為、重要なバックエンドのコスト、例えば、コードの保守、保守、サポート、テクノロジーのアップグレードといったコストを見逃しがちである。この IT ドライバは、フロントエンドの調達や開発コストだけでなく、ソリューションの総所有コストを（長期的な実現可能性として）小限に抑えることを指している。


Significant Requirement)とそれを満足する基本パターンの因果関係は、このデシジョンテーブルから読

みとることができない。

3.3.2. セルフサービスのアプリケーションパターン

Patterns for e-businessのオリジナルを参考にして、セルフサービスの 3 つのアプリケーションパター

ンを分析・評価しやすいように書き直したアーキテクチャの静的構造を図 3-3に示す。

ホスト端末

①スタンドアロンシングルチャネル

同期

②ルーター

③エージェント

プレゼンテーション２

プレゼンテーション１

アプリケーション２

アプリケーション１

エージェント

ODS

同期非同期


プレゼンテーション２


アプリケーション１

ルーター

同期同期

ルール


同期

同期


同期アプリケーション１

非同期

新規

更新

一時的

既存

凡例

参照

端末

図 3-3 セルフサービスの 3 つのアプリケーションパターン

当WGが事例研究を通して Patterns for e-businessのオリジナル英語版と日本語版のパターン記述から

読み解いた 3 つのアプリケーションパターンの要約を示す。

スタンドアロンシングルチャネルパターン 1 つの販売チャネルを支援するプレゼンテーション層(Tier)iから 1 つの事業（商品・サービス）を支

援するアプリケーション層(Tier)を 1 対 1(Point-to-point)で接続する 2 層(Tier)のアプリケーションパター

ンである。このパターンは、社内販売チャネル（営業拠点など）がホスト端末で事業（商品・サービ

ス）を支援する既存アプリケーション 2 を利用している企業が新たにインターネットチャネルを短期

間に開始する場面を想定している。Web化に必要な既存アプリケーション 2 の改修に時間がかかるた

め、1 つの事業（商品・サービス）のインターネットチャネル向けのプレゼンテーション 1 とアプリケ

ーション 1 を短期間に開発するプロジェクトで適用される。アプリケーション 1 は、1 つの事業（商品・

i ユーザーインタフェースだけを提供するソフトウェアの UI 層(Layer)ではなく、チャネル向けのアプリケーション層(Tier)で

ある。新の Patterns for e‐business では、プレゼンテーション層をフロントエンド層、アプリケーション層をバックエンド層と再定義している。


サービス）の全てのプロセス支援を想定しておらず、受注プロセス以降の後続プロセスに関しては、

バックエンドのアプリケーション 2 に手作業のデータ入力、または、オフラインのデータ交換で連係

することを前提としている。将来、インターネットチャネルへ他の事業（商品・サービス）を追加す

る、または、コールセンターなど他のチャネルを追加する場面では、事業（商品・サービス）間やチ

ャネル間に「顧客から見たビューの統一」や「複数のデリバリー・チャネルの統合」ができるセルフ

サービスを顧客に提供することを意図していない。また、オンラインによる「バックエンドアプリケ

ーションの統合化」を意図していないため、バックエンドのアプリケーション 2 で処理される受注プ

ロセス以降の後続プロセスに関して、顧客自身による注文の進行状況を確認することができない。

ルーターパターン複数の販売チャネルを支援するプレゼンテーション層(Tier)と複数の事業(商品・サービス)を支援す

るアプリケーション層(Tier)を間接的にハブ・アンド・スポーク(Hub-and-spoke)で接続する 3 層(Tier)の

アプリケーションパターンである。ルーター iは、プレゼンテーション層とアプリケーション層の対応

関係やメッセージ変換のルールを参照データ・ストアとしてハブ層に配置し、プレゼンテーション層

(Tier)から要求されるメッセージをルールに従ってアプリケーション層(Tier)に割り当てる。

プレゼンテーション層（依頼人）とアプリケーション層（引受人）は、ハブ層のルーター(仲介人)を介

在させることで公開したくない内部情報を相互に交換せずに e-business の取引が可能になる。このパタ

ーンは、将来、プレゼンテーション層やアプリケーション層が増えた場合でも、システム全体の構造

がシンプルに保て、インタフェースの多様性や変化に迅速に対応することを意図している。ハブ・ア

ンド・スポーク(Hub-and-spoke)の原理は、メッシュ構造になる一対一(Point-to-point)に比較してシステ

ム全体の構造がシンプルになることである。

プレゼンテーション層とアプリケーション層の間は、同期接続（要求応答型）であり、バックエン

ドのアプリケーション 2 で処理される受注プロセス以降の後続プロセスに関して顧客自身がセルフサ

ービスにより注文の進行状況を確認することが可能になる。

事業（商品・サービス）の観点では、ルーターを介在した取引により「複数のデリバリー・チャネル

の統合」ができる。しかし、顧客の観点では、ルーターは、取引の仲介人にすぎず、エージェントパ

ターンのように顧客の代理人として「顧客から見たビューの統一」や「一括カスタマイズ」を提供し

ていない。

また、同期接続を前提にしているためセルフサービスを提供できる時間帯は、バックエンドのアプ

リケーション層のサービス運用時間に依存する。

エージェントパターンルーターパターンと同じハブ・アンド・スポーク(Hub-and-spoke)で接続する 3 層(Tier)のアプリケー

ションパターンである。エージェントiiは、更新可能データ・ストアであるオペレーショナルデータス

i ルーターは、別名としてブローカー(Broker)と呼ばれることもあり、e‐business の仲介人である。アプリケーション層(Layer)のビジネスルールに基づく e‐business の取引手配、e‐business の取引情報の変換を行うビジネス上の機能である。IT 資源のアドレスによるルーティング、フォーマットや文字コード変換を行うネットワーク層(Layer)やミドルウェア層(Layer)のルーターではない。

ii エージェントは、旅行代理店を例に考えると代理人としての役割が容易にイメージできる。旅行代理店（代理人）は、旅行者（依頼人）の旅行に必要な交通手段、宿泊施設、参加イベントなど複数の提供サービス（引受人）の手配や情報収集を代理で行う。


トア(ODS)や顧客情報ファイル(CIF)をハブ層に配置し、ルーターのように単なる仲介人ではなく顧客

の代理人として、依頼された取引に関連する商品・サービス（アプリケーション）をまとめて手配す

る、依頼された取引に関連する情報をあらかじめ複数の商品・サービス（アプリケーション）から収

集するなど、「顧客から見たビューの統一」や「一括カスタマイズ」を可能にする。

エージェントは、ハブ層に配置された更新可能データストア(ODS や CIF)と非同期接続を利用してアプ

リケーション層のサービス停止時間帯でもセルフサービスが提供できるため機会損失が少ない。また、

複数の商品・サービス（アプリケーション）を組み合わせた処理時間が長くなる場合でも顧客を待た

せずに後で結果を通知することもできる。

しかし、更新可能データストア(ODSやCIF)のデータ鮮度が常に新状態を維持できないことi、およ

びエージェントがカバーしない受注プロセス以降の後続プロセスに関してはセルフサービスが提供で

きない制約がある。

3.3.3. アプリケーションパターンの分析

アプケーションパターンから基本パターンを識別する方法は、図 3-3の(1)モデル図からの図形識別

と(2)パターン記述文からの概念識別がある。(1)図形識別は、論理層やデータ・ストアの関連から静的

構造を、論理層間の接続方式（同期または非同期）から動的振舞を比較的容易に識別できる。しかし、

(2)概念識別は、e-businessの知識や経験に依存するため、分析する人によりパターン記述文から概念を

認知する能力にばらつきが大きくなる。

当事例研究では、アプリケーションパターンの分析に当たって、「非機能要求記述ガイド」[IPA2008]

で説明したコントロールケースii[Zou2006]に加え、BMM（Business Motivation Model）[BMM2007]やア

ーキテクチャ記述(Architectural Description)のためのメタモデル[IEEE1471-2000]も参考にして、当WG独

自に付録Bに示したNFRとアーキテクチヤに関連する概念のメタモデル(B.1)を定義した。このメタモデ

ルの概念を識別タグ(B.2)として活用し、Patterns for e-businessのオリジナル英語版と日本語版のパター

ン記述からメタモデルの概念を示唆する文節を抽出し、それらの間の因果関係をUMLの依存関係モデ

ルで分析した。

表 3-4は、3 つのアプリケーションパターンから識別した代表的な基本パターンとNFRの対応関係を

示している。この分析により、普遍的に見出される基本パターンとアプリケーションパターンの選択

の分かれ目になる基本パターンがあることが確認できた。例えば、「アプリケーション層とプレゼンテ

ーション層の分離」は、3 つのアプリケーションパターンに共通しており、選択の分かれ目になる基本

パターンではない。「ハブ・アンド・スポーク」は、「スタンドアロンシングルチャネル」と「ルータ

ー」や「エージェント」の分かれ目になる基本パターンである。「更新データストア(ODS/CIF)のハブ

層配置」は、「ルーター」と「エージェント」の分かれ目になる基本パターンである。

また、アプリケーションパターンを選択するモチベーションになるドライバ(表 3-1表 3-2表 3-3)と

して明記されていない暗黙のドライバがあることも確認できた。例えば、「更新データストア(ODS/CIF)

のハブ層配置」は、エージェント（代理人）の機能（役割）と必要な更新データストア(ODS/CIF)によ

i在庫の引き当てや指定席の予約などをセルフサービスで提供している EC サイトは、鮮度の古い情報に基づいた受注であ

ることをあらかじめ顧客が承諾した上で取引を行い、取引結果をメールなどで通知している。また、欠品、予約不能、納期遅延などが発生した場合、代替品や代替手段の提案、割引券やポイントの付与などにより顧客満足度の向上も合わせて実施している。

ii NFR 記述の拡張に伴い、コントロールケースも関連するシナリオを記述できるように変更している。


り、明示的な「顧客から見たビューの統一」や「一括カスタマイズ」を実現しており、これは、機能

要求である。「ハブ層配置」は明示的なドライバに必要な要求ではなく、「アプリケーション層の非同

期統合」と併せて、「アプリケーション層のサービス停止時間帯でもセルフサービスが提供できる」や

「複数の商品・サービス（アプリケーション）を組み合わせた処理時間が長くなる場合でも顧客を待た

せずに後で結果を通知する」など、「可用性」や「時間効率性」に関する暗示的なドライバをモチベー

ションにしている。暗示的なドライバは、パターン記述文の中に示唆され容易に読み取ることができ

るものもあるが、多くは分析者の経験や能力に依存する。

表 3-4 基本パターンとアプリケーションパターンの関係性

YN-使用性: 遅い処理結果の応答を待たない

資源効率性: 資源を占有しない

動的振舞プレゼン層の非同期統合

YN-

可用性: 既存アプリのサービス時間帯や計画停止の制約下でも24x365に対応する

最新性: ODSとマスターデータ間に遅延がある

静的構造更新データ(ODS)の

ハブ配置

(アプリ層のハブ配置)

Y

Y

Y

Y

N

Y

エージェン

ト

N

Y

Y

Y

N

Y

ルーター

-

-

Y

N

Y

Y

スタンドアロ

ン

「更新データ(ODS)のハブ配置」と同じ

(時間効率性: 処理パス長が短く応答時間が早い)

(最新性: マスター更新データにアクセスできる)

(使用性: 応答の有無が直ぐに判る)

(制約: スキル/非同期は設計が難しい)

保守性: インタフェースの多様性や変化に迅速に対応する


(制約: 期間、コスト、体制など)

保守性: UIの要求や技術の変化に迅速に対応する

品質青: メリット黒: 制約

（括弧) 明記されていない

動的振舞アプリ層の非同期統合

動的振舞アプリ層の同期統合

動的振舞プレゼン層の同期統合

静的構造ハブ・アンド・スポーク接続

静的構造直接接続

静的構造アプリ層とプレゼン層の分離

赤: デメリットタイプ基本パターン

YN-使用性: 遅い処理結果の応答を待たない

資源効率性: 資源を占有しない

動的振舞プレゼン層の非同期統合

YN-

可用性: 既存アプリのサービス時間帯や計画停止の制約下でも24x365に対応する

静的構造更新データ(ODS)の

ハブ配置

(アプリ層のハブ配置) 最新性: ODSとマスターデータ間に遅延がある

Y

Y

Y

Y

N

Y

エージェン

ト

N

Y

Y

Y

N

Y

ルーター

-

-

Y

N

Y

Y

スタンドアロ

ン

「更新データ(ODS)のハブ配置」と同じ


(最新性: マスター更新データにアクセスできる)

(使用性: 応答の有無が直ぐに判る)

(制約: スキル/非同期は設計が難しい)

保守性: インタフェースの多様性や変化に迅速に対応する


(制約: 期間、コスト、体制など)

保守性: UIの要求や技術の変化に迅速に対応する

品質青: メリット黒: 制約

（括弧) 明記されていない

動的振舞アプリ層の非同期統合

動的振舞アプリ層の同期統合

動的振舞プレゼン層の同期統合

静的構造ハブ・アンド・スポーク接続

静的構造直接接続

静的構造アプリ層とプレゼン層の分離

赤: デメリット基本パターンタイプ

3.3.4. 基本パターン、非機能要求、ドライバの因果関係

図 3-4は、B.1に添付した当WG独自のNFRとアーキテクチャに関連する概念のメタモデルの本質的な

因果関係を概略図として示したものである。

RA に基づいてアーキテクチャを決定する（例えば、Patterns for e-business では、ドライバに基づ

いてアプリケーションパターンを選択する）方向の因果関係は、「目的→手段」である。RAのアーキテ

クチャパターンから識別した基本パターンが品質特性に良い効果を現す、または、悪い影響を及ぼす

方向の因果関係は、「原因→結果（効果・影響）」である。この２つ因果関係がマッチングしていない

場合、決定した IT システムのアーキテクチャは、ゴールの達成、または、リスクの緩和・回避に何ら

かの欠陥を内在していることになる。

第 2章で解説したように、NFRの必要性根拠になるステークホルダ要求の正当性根拠は、ゴール達成

を動機としたものとリスク緩和・回避を動機としたものがある。ステークホルダは、ゴールの達成に

必要な手段としてだけでなく、ゴール達成の手段に伴って起こりえる悪影響をリスクとして捉え、リ

スク緩和・回避の動機をドライバとしてステークホルダ要求をITシステムに求めている。


ドライバに基づいてアプリケーションパターンを選択する場合、ステークホルダ要求がアーキテク

チャパターン選択のドライバと一致しているとしても、リスクに基づく動機はステークホルダの経験

や直感に頼っていることが多く、必要性根拠や正当性根拠に関して、客観的な分析・評価が行われて

いないことが多い。リスクの正当性とNFRの必要性に対する妥当性を評価する上で、第 2章で解説した

コントロールケースやATAMを活用したNFRとアーキテクチャ分析するアプローチが有効である。

結果（効果・影響）

結果（効果・影響）

ドライバゴールリスクゴールリスク

基本パターン

非機能要求

品質要求

制約

目的

手段原因

コントロールケース

基本パターン

原因

目的

手段

ｽﾃｰｸﾎﾙﾀﾞ要求

ﾄﾞﾗｲﾊﾞ

ﾄﾞﾗｲﾊﾞゴール

リスク

アーキテクチャパターン



正当性

正当性

機能要求

基本ﾊﾟﾀｰﾝの前提要求

非機能要求

マッチング

図 3-4 基本パターン、非機能要求、ドライバの因果関係

「スタンドアロンシングルチャネルパターン」を分析した事例を紹介する。

チェンジケースに想定されるリスク緩和の例（図 3-5 ）。

チェンジケース（将来、数万人レベルの同時アクティブユーザが想定されている）が明記されて

おり、想定されるリスクを緩和する性能拡張性に関して、コントロールケースを活用して、場面（ビ

ジネスプラン上のユーザー増加）と稼動状況（通常時、サージ、バーストなど）に合わせた運転モ

ード（正常、能力増強、能力縮小、など）毎に NFR を記述することで、より適切なアーキテクチャ

を設計できる可能性がある。

基本パターン「接続プール」と相反する基本パターン「都度接続」に対する考慮が記述されおり、

「サーバーの大接続数の制限」や「リソース不足」といった IT リスクを示唆している。このアプ

リケーションパターンには、性能拡張性に関する NFR と基本パターンが必要になることを意味して

いる。


性能拡張性の記載漏れ

図 3-5 スタンドアロンシングルチャネルパターンの整理結果（一部：その１）

センシティビティポイントとトレードオフポイントの例(図 3-6)

センシティビティポイント「CIF・・データ解釈に使用するアルゴリズムの品質」がビジネスリス

ク「顧客の好みに関する認識を誤る」に影響するため、基本パターン「データ統合」に高度なアル

ゴリズムを適用して品質特性「アルゴリズムの正確性」を良くする。しかし、基本パターン「デー

タ統合」の品質特性「時間効率性」が悪くなり、IT リスク「・・動的収集に時間がかかりすぎる」

ため、IT リスク「・・データの不整合・・」の可能性があり、ビジネスリスク「顧客の好みに関す

る認識を誤る」に影響がループしている。この場合、センシティビティポイント「アルゴリズムの

品質」は、トレードオフポイントにもなっている。基本パターン「データ統合」の方式により、デ

ータ転送の時間効率性やデータの一貫性を制御することができる。しかし、CIF データ加工に求め

られるアルゴリズムの正確性と時間効率性の適解に関しては、アーキテクチャでは解決できない。

アルゴリズムの設計工程で、正確性と時間効率性の検証を継続して実施する必要がある。


図 3-6 エージェントパターンの整理結果（一部）

品質要求ではなく、制約でアーキテクチャが決まる例(図 3-7 )

当 WG では、基本パターンは、主目的とする品質特性があると仮定していたが、この例が示す様

に特に主目的とする品質特性がなく、制約により決まる基本パターンがあることがわかった。この

ような基本パターンは、変更できない制約を受け入れる代償として、前提条件(Requisite)や免責事項

(Disclaimer)が明記されている。

図 3-7 シングルチャネルのパターン整理結果（一部：その 2）



3.4. まとめ

Patterns for e-business のアプリケーションパターンを題材にした NFR とアーキテクチャの関係分析

の事例研究で、Patterns for e-business に含まれる NFR とアーキテクチャに関連する概念を識別タグで抽

出し、ビジネスモチベーションモデル [BMM2007] 、コントロールケース [Zou2006]、および、ATAM

を参考にして WG 独自のメタモデルを作成して、NFR とアーキテクチャの因果関係を整理した。RA

を参考にしてアーキテクチャを決定するプロセスにおいて、このメタモデルを参照することで、暗示

的な NFR や基本パターンを見つけやすくすることが確認できた。NFR とアーキテクチャの関係分析の

事例研究を通じて得られた知見を以下に示す。

Patterns for e-business は、モデル図だけなく、パターン記述として、ドライバ、ソリューション、

使用上のガイドライン、メリット、制限事項、および、パターンの使用例を示しており、パタ

ーンを適用する場面、前提条件、達成するゴール、回避するリスク、効果、影響、残存するリ

スク、免責事項、代替案、他のパターンの組み合わせなど有用な知見を提供している。

Patterns for e-business のようにアーキテクチャパターンを体系的にまとめた RA の場合でも、

NFR とアーキテクチャの因果関係は十分に可視化されておらず曖昧さが残っている。

RA を適用する IT システムに関して、具体的な場面と IT システムの稼動状況に想定されるリス

クを分析・評価し、IT システムの運転モードに NFR をコントロールケースで記述する手法が効

果的である。

コントロールケースや NFR とアーキテクチャ分析のメタモデルを活用することで、ステークホ

ルダ要求の正当性根拠、NFR の必要性根拠、および、アーキテクチャの必要性根拠と理論的的

根拠に関する説明責任の明確化が期待できる。

今後、このメタモデルや識別タグを洗練した上でツール化することにより、要求の定義作業の

品質と効率を高めることが期待できる。

付録A 本報告書が対象にするアーキテクチャ

A.1. アーキテクチャに関する定義

アーキテクチャ（Architecture）の定義に関しては、様々な定義が存在し統一された標準が確立して

いないため、本報告書では、企業や公的機関(以下、エンタプライズ)が価値創造や組織活動の支援に利

用する IT システムのアーキテクチャに限定する。本報告書が対象にする IT システムは、情報技術に

基づいた情報システム(Information Technology based Information System)であり、IT 製品(ハードウェアや

ソフトウェア)を基盤として主にアプリケーションソフトウェアを開発対象とするソフトウェア集約シ

ステム（Software-Intensive Systems）[IEEE 1471-2000]である。ソフトウェア中心システムのアーキテク

チャ記述（Architectural Description）の推奨プラクティスである IEEE1471-2000 は、アーキテクチャを

次のように定義している。

The fundamental organization of a system, embodied in its components, their relationships to each other and

the environment, and the principles governing its design and evolution.

システムの基本構造であり、コンポーネント群、コンポーネント間の相互関係と環境との関係、設

計と改良を律する原理・原則により構成される。(当 WG による意訳)

アーキテクチャは、設計（Design）の一種であるが、全ての設計がアーキテクチャではない。例えば、

システムの構成要素であるコンポーネントに実装するアルゴリズムや入出力するデータの構造など

は、コンポーネントの設計であり、システム全体の組織構造のアーキテクチャではない。CMU/SEI で

は、システム要件の満足に対して重要でなく、コンポーネントの設計者や実装者に意思決定を委ねる

ことができる設計をアーキテクチャと区別して「アーキテクチャ以外の設計（Non-architectural design）」

と定義している (CMU SEI, http://www.sei.cmu.edu/architecture/start/glossary/ )。

本報告書では、開発対象のアプリケーションソフトウェアのコンポーネント設計ではなく、アプリ

ケーションソフトウェアの基盤となるハードウェアやシステムソフトウェア、さらに利用・運用され

る環境も含めた IT システムのアーキテクチャを対象とする。

なお、本報告書が対象とする IT システムは、ハードウェアとソフトウェアだけで構成され、ユーザ

や運用要員など人を含まないシステムであり、エンタプライズの組織(人、制度、施設も含む)を中心と

したビジネスシステム(Business System)ではない。また、ソフトウェアを組み込んだ機器(Embedded

device)や航空機など複雑な製品(Complex Product)を中心としたシステムも対象としない。

A.1.1. アーキテクチャのスコープ

IT アーキテクチャは、その対象領域のスコープにより、一般にエンタープライズアーキテクチャと

ソリューションアーキテクチャに大別される。エンタープライズアーキテクチャは、エンタプライズ

の全体適化を目的として、IT 標準や参照アーキテクチャ(Reference Architecture)など、個別の IT シス

テムが遵守すべきアーキテクチャガバナンスである。本報告書では、エンタープライズアーキテクチ

ャは、ソリューションアーキテクチャを設計する上で遵守する NFR の制約に位置け、アーキテクチャ

記述では、個別の問題領域を対象とした IT システムのソリューションアーキテクチャを対象とする。


http://www.sei.cmu.edu/architecture/start/glossary/

A.1.2. アーキテクチャのビューポイント

全てのステークホルダの様々な関心事 (Concern)を満足するアーキテクチャ記述 (Architectural

Description)を単一のビューポイント(Viewpoint) やビュー(View)で作成することは、困難である。その

ため、様々なビューポイントカタログ(表)が提案されているが、業界標準として確立されたものが存在

していない。

表 A-1 主要なビューポイントカタログ

ビューポイント

カタログ

ビューポイント/ビュー

TOGAF Business Architecture

Information System Architecture

– Application Architecture

– Data Architecture

Technology Architecture

ArchiMate Viewpoint Purpose

Designing – navigate, design, support design decisions, compare alternatives

Deciding – decision-making

Informing – explain, convince, obtain commitment

Viewpoint Abstraction Levels

Details – one layer and one aspect

Coherence – architecture relations like process-uses-system (multiple layer) or

application-uses-object (multiple aspect)

Overview – multiple layers and multiple aspects

Layers

Business layer

Application layer

Technology layer

Aspects

Structure

Behavior

Information

Basic Viewpoints

Organization Viewpoint – All purpose, Coherence level, Business layer, Structure

aspect

Actor Co-operation Viewpoint – All purpose, Details level, Business

(Application) layer, Structure and Behavior aspects

Business Function Viewpoint – Designing purpose, Coherence level, Business

layer, Behavior and Structure aspects

32

Business Process Viewpoint – Designing purpose, Details level, Business layer,

Behavior aspect

Business Process Co-operation Viewpoint – Designing and deciding purposes,

Coherence level, Business and Application layers, Behavior aspect

Product Viewpoint – Designing and deciding purposes, Coherence level, Business

and Application layers, Behavior and Information aspects

Application Behavior Viewpoint – Designing purpose, Coherence and Details

levels, Application layer, Information, Behavior and Structure aspects

Application Co-operation Viewpoint – Designing purpose, Coherence and Details

levels, Application layer, Behavior and Structure aspects

Application Structure Viewpoint – Designing purpose, Details level, Application

layer, Structure and Information aspects

Application Usage Viewpoint – Designing and Deciding purposes, Coherence

level, Business and Application layers, Behavior and Structure aspects

Infrastructure Viewpoint – Designing purpose, Details level, Technology layer,

Behavior and Structure aspects

Infrastructure Usage Viewpoint – Designing purpose, Coherence level,

Application and Technology layers, Behavior and Structure aspects

Implementation and Deployment Viewpoint – Designing purpose, Coherence

level, Application and Technology layers, Information, Behavior and Structure

aspects

Information Structure Viewpoint – Designing purpose, Details level, Business,

Application and Technology layers, Information aspects

Service Realization Viewpoint – Designing and Deciding purposes, Coherence

level, Business (Application) layers, Behavior, Structure and Information aspects

Layered Viewpoint – All purposes, Overview level, Business, Application and

Technology layers, Information, Behavior and Structure aspects

Landscape Map Viewpoint – Deciding purpose, Overview level, Business,

Application and Technology layers, Information, Behavior and Structure aspects

IEEE1220 Systems

Engineering Process

Operational View

Functional View (Performance Requirement も含む)

Design View (1994 年版までは、Physical View と呼ばれていた)

UPDM

(UML Profile for

DoDAF and

MODAF)

All View

Strategic Viewpoint

Custom Viewpoint

Operational Viewpoint

Acquisition Viewpoint

Services Viewpoint

33

Systems Viewpoint

Technical Viewpoint

RUP 4+1 Scenarios

Logical View

Development View

Process View

Physical View

RM-ODP Enterprise Viewpoint

Information Viewpoint

Computational Viewpoint

Engineering Viewpoint

Technology Viewpoint

MDA CIM (Computation-Independent Model)

PIM (Platform-Independent Model)

PSM (Platform-Specific Model)

Rows

Scope Context – Strategists as Theorists {Scope, Contextual, Planner}

Business Concepts – Executive Leaders as Owners {Business Model, Conceptual,

Owner}

System Logics – Architects as Designers {System Model, Logical, Designer}

Technology Physics – Engineers as Builders {Technology Model, Physical,

Builder}

Component Assemblies – Technicians as Implementers {Detailed

Representations, Out-of-context, Subcontractor}

Operations Classes – Workers as Participants {Functioning Enterprise}

THE ZAKMAN

ENTERPRISE

FRAMEWORK2

(バージョン 2)

注) {}内は、バージ

ョン 1 の名称

Columns

What – Inventory Sets {Data}

How – Process Transformations {Function}

Where – Network Nodes {Network}

Who – Organization Groups {People}

When – Timing Periods {Time}

Why – Motivation Reasons {Motivation}

IBM Patterns for

e-business

Business Patterns – interaction between users, businesses, and data

Integration Patterns – both Front-End and Back-End connect other Business

patterns together to create solutions with advanced functionality

Composite patterns – advanced e-business solutions combining Business patterns

and Integration patterns

Application Patterns – both a decomposition of the existing IT subsystem and a

34

decomposition of the planned enhanced IT subsystem

Runtime Patterns – nodes interconnected to solve a business problem

Basic Viewpoints

Requirements Viewpoint

Solution Viewpoint

– Functional Viewpoint

– Operational Viewpoint

Validation Viewpoint

IBM Views and

Viewpoints

Framework for IT

systems

Cross-cutting Viewpoint

Application Viewpoint

Technical Viewpoint

Systems Management Viewpoint

Availability Viewpoint

Performance Viewpoint

Security Viewpoint

IPA IT スキル標準

IT アーキテクチ

ャ・メタモデル・セ

マンティックス解

説

Business View

IT View

– Functional View

– Operational View

TOGAF ITAC IT

Architect Disciplines

Enterprise Architecture

Business Architecture

Information Architecture

Application Architecture

Technology Infrastructure Architecture

IPA IT スキル標準

IT アーキテクト専

門分野

アプリケーションアーキテクチャ

インテグレーションアーキテクチャ

インフラストラクチャアーキテクチャ

本報告書では、主要なビューポイントカタログやITスキル標準の「ITアーキテクチャ・メタモデル・

セマンティックス解説」[IPA2007b]も考慮して、主要なビューポイントを独自に分類した上で、本報告

書がカバーするビューとの関係を表 A-1示す。

35

表 A-1 本報告書がカバーするビューポイント

ビューポイントの

分類

ビューポイント

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

本報告書の対応

Strategic Viewpoint

[UPDM: Strategic Viewpoint]

本報告書の対象とする。

Acquisition Viewpoint

[UPDM: Acquisition Viewpoint]

本報告書では対象としない。

Requirement Viewpoint

[IBM: Requirement Viewpoint]


Solution Architecture Viewpoint

[IBM: Solution Viewpoint]

[IPA: IT View]


Development Viewpoint

[RUP: Development View]


Validation Viewpoint

[IBM: Validation Viewpoint]


ライフサイクルプロ

セス (Lifecycle

Process)

Systems Management Viewpoint

[IBM: Systems Management Viewpoints]


Business System Viewpoint

[TOGAF: Business Architecture]

[UPDM: Operational Viewpoint]

[IEEE1220: Operational View]

[RM-ODP: Enterprise Viewpoint)

[ZACKMAN: Business Concepts]


Complex Product System Viewpoint

[IEEE1220: Functional View, Design View]

[UPDM: Systems Viewpoint]


Embedded System Viewpoint

[embedded-systems-portal]

[IPA: 組み込み系]


システムタイプ

(System Type)

IT System Viewpoint

[TOGAF: Information System Architecture]

[IEEE1471: Software-intensive System]

[ZACKMAN: System Logics]

[IPA: エンタプライズ系]

[IBM: IT System]


IT アーキテクト専門 Enterprise Architecture Viewpoint 本報告書では対象としない。

36

(ITAC: Enterprise Architecture)

Business Architecture Viewpoint

[ITAC: Business Architecture]

[IBM Patterns for e-business: Business

Pattern)


Application Architecture Viewpoint

[TOGAF: Application Architecture]

[ITAC: Application Architecture)

[RM-ODP: Computational Viewpoint]

[IBM: Application Viewpoint]

[IBM Patterns for e-business: Application

Pattern]

[IPA: アプリケーションアーキテクチャ]


Information Architecture Viewpoint

[TOGAF: Data Architecture]

[ITAC: Information Architecture)

[RM-ODP: Information Viewpoint]


Integration Architecture Viewpoint

[IPA: インテグレーションアーキテクチ

ャ]

[IBM Patterns for e-business: Integration

Pattern]


分野

(Discipline)

Technical Architecture Viewpoint

[TOGAF: Technology Architecture]

[UPDM: Technical Viewpoint)

[RM-ODP: Engineering, Technology

Viewpoint]

[IBM: Technical Viewpoint]

[IBM Patterns for e-business: Runtime

Pattern]

[ITAC: Technology Infrastructure

Architecture]

[IPA: インフラストラクチャアーキテクチ

ャ]

本報告書の対象とする。ただし、

具体的な技術や製品の選定に関

しては対象としない。

Conceptual Viewpoint

[MDA: Computation-Independent Model]

本報告書の対象とする。抽象度

(Abstraction)

Logical Viewpoint 本報告書の対象とする。

37

38

[MDA: Platform-Independent Model]

[IEEE1220: Functional View]

[RUP: Logical View]

Physical Viewpoint

[MDA: Platform-Specific Model]

[IEEE1220: Design View (Physical View)]

[RUP: Physical View]


具体的な技術や製品の選定や実

装に関しては対象としない。

付録B 事例研究資料

B.1. 非機能要求とアーキテクチャ分析のメタモデル

非機能要求とアーキテクチャ分析のメタモデルを図 B-1 に示す。これは、当 WG で下記を参考に独

自にメタモデルとして整理したものである。

・ Patterns for e-business [IBM2000] のアーキテクチャパターンとその基本パターンの整理

・ BMM（Business Motivation Model ）[BMM2007]

・「非機能要求記述ガイド」[IPA2008]で記述したコントロールケース[Zou2006]

・文献[IEEE1471-2000] で唱えているミッションからアーキテクチャの関連性

・ IT アーキテクチャ・メタモデルセマンティクス解説[IPA2007b]

BMMを参照した動機に関する部分

コントロールケースPatterns for e-business

IT アーキテクチャ・メタモデルセマンティクス解説を参照した部分

基本パターン

図 B-1 非機能要求とアーキテクチャ分析のメタモデル


B.2. セルフサービスのアプリケーションパターン(一部)

Patterns for e-businessの日本語翻訳版(2003 年 12 月 7 日)からセルフサービスビジネスパターンのアプ

リケーションパターンをRA分析の題材として選択し、パターン記述の原文iにWG独自のメタモデルに

基づく識別タグ< >と補足説明を青色または赤色のテキストで追記して、NFRとアーキテクチャに関連

するパターン言語を抽出した。

例えば、セルフサービスビジネスパターンの場合、ITドライバとアプリケーションパターンの関連

表(表 3-1、表 3-3)では、スタンドアロン単一チャネル(Stand-Alone Single Channel)アプリケーションパ

ターンとアプリケーションの保守性(Maintainability)の関連性が明示されていない。しかし、スタンドア

ロン単一チャネルパターン記述(表 B-2 のソリューション(Solution)節には、アプリケーションの保守性

に関連する基本パターン「N層アプリケーション(N-Tier Application)」を示唆する「2 つの論理層(Logical

Tier)に分割して、プレゼンテーションロジックはビジネスロジックから分離」が記述されている。た

だし、基本パターン「N層アプリケーション(N-Tier Application)」がアプリケーションの保守性を良く

する仕掛けとその原理に関する理論的な根拠は明示されていない。

i Patterns for e‐business の日本翻訳版は、IPA SEC の標準と異なる外来語や翻訳語で記述されている。また、誤訳や誤

植と思われる記述も散見されるが、原文のまま引用している。

40

スタンドアロン単一チャネルパターン記述の抜粋

アプリケーションを<essential pattern> 2 つの論理層(Logical Tier)に分割して、プレゼンテーショ

ンロジックはビジネスロジックから分離</essential pattern>します。分離する主な理由は、開発す

るアプリケーションの<NFR quality attribute>保守容易性</NFR quality attribute>を確保すること、

および<essential pattern>シンクライアント</essential pattern>をサポートすることです。

表 B-2 パターン言語の識別タグ

NFR とアーキテクチャの依存関係に関連するパターン言語の識別タグ

コンテクスト

<situation> : 場面

<condition> : 稼動状況

ビジネスドライバ(Business Driver)

<business goal> : 達成するビジネスゴール

<business risk> : 回避するビジネスリスク

<business strategy> : ビジネスゴールの達成、または、ビジネスリスクの回避のための戦略

<business policy> : ビジネスゴールの達成、または、ビジネスリスクの回避のための方針(制約、優先

順位)

IT ドライバ(IT Driver)

<IT goal> : 達成する IT ゴール

<IT risk> : 回避する IT リスク

<IT policy> : IT ゴールの達成、または、IT リスクの回避を目的とした方針(制約、優先順位)

前提条件

<requisite> : 必要条件 ― このパターンを適用するコンテクストで必要な条件

<disclaimer>: 免責条件 ― このパターンを適用するコンテクストで免責される条件(満足しない要求)

<unachievable business goal> : 達成できないビジネスゴール

<residual business risk> : 残存するビジネスリスク

<unachievable IT goal> : 達成できない IT ゴール

<residual IT risk> : 残存する IT リスク

機能要件

<functional requirement>: 機能要求 ― このパターンを適用するコンテクストで必要な機能要件

非機能要件

<change case> : 将来要件 ― このパターンを適用しておくと、将来、満足する要件

<NFR quality requirement> : 非機能要求の品質要求

<primary quality attribute> : 主目的の品質特性の名称

<secondary quality attribute> : 副目的の品質特性の名称

<negative quality attribute> : 副作用のある品質特性の名称

<NFR constraint> : 非機能要求の制約

41

<unnecessary requirement> : 必要ない要件


<essential pattern> : このパターンに含まれる基本パターン

<contradictory pattern> : このパターンに含まれる基本パターンと相反する基本パターン

<sensitivity point> : 基本パターンのセンシティビティポイント

<tradeoff point> : 基本パターンのトレードオフポイント

<architectural principle> : アーキテクチャの原理・原則

42

表 B-3 スタンドアロンシングルチャネル(Stand-Alone Single Channel)パターン記述

パターン名

スタンドアロンシングルチャネル(Stand-Alone Single Channel)

パターンの概要

スタンドアロンシングルチャネル・アプリケーションパターンが提供するアプリケーションは、他の

システムと統合する必要はなく、1 つのデリバリーチャネルに焦点を絞るのに必要な構造を提供しま

す。このアプリケーションパターンは、どのデリバリーチャネルをインプリメントする場合にも使用

できますが、ここに記載の内容では、主に Web デリバリーチャネルに焦点を当てています。

ビジネス要件および IT 要件(Business & IT Driver)

5. <business goal>ビジネスの迅速な開始</ business goal >

6. <IT risk>アプリケーションの複雑さを軽減</IT risk>

ビジネスの迅速な開始は、このアプリケーションパターンを選択する際の基本的なビジネス要件にな

ります。このアプローチは、Web 上にセルフサービス機能を提供して Web 公開を迅速に拡張するのに

使用できます。

7. <disclaimer>バックエンドアプリケーションとの統合のための即時のビジネス要件がないこ

と(no immediate business requirements)<disclaimer>が条件となります。通常、<disclaimer>Web

アプリケーションはバックエンドアプリケーションとの統合</disclaimer>が必要になります

が、<IT strategy>実用化への時間を短縮 ― Time to Market</IT strategy>し、<IT risk>アプリ

ケーションが複雑になるのを防止</IT risk>するためには、<business policy>このような統合操

作(Integration)は後の開発段階に後回し</business policy>できます。<disclaimer>Web アプリケ

ーションとバックエンドアプリケーション間のデータの同期化については、むしろ手動で処理

を行うこと</disclaimer>もできます。

<IT goal>単一デリバリーチャネルをサポートすること</IT goal>が唯一の現在の目標である場合は、こ

のアプリケーションパターンは選択すべき理想的なパターンです。つまり Web、音声認識装置、キオ

スク、コールセンターのアプリケーションなど、<disclaimer>様々なデリバリーチャネル間で、シーム

レスな統合</disclaimer>の必要がない場合です。

ソリューション(Solution)

アプリケーションを<essential pattern> 2 つの論理層(Logical Tier)に分割して、プレゼンテーションロジ

ックはビジネスロジックから分離 ― N 層アプリケーション (N-Tiered Application)</essential

pattern>します。分離する主な理由は、開発するアプリケーションの<primary quality attribute>保守容

43

易性</NFR quality attribute>を確保すること、および<requisite><essential pattern>シンクライアント

</essential pattern></requisite>をサポートすることです。

8. プレゼンテーション層は、データフォーマットや画面のナビゲーション機能など、ユーザー

インタフェース関連のすべてのロジックを提供します。

9. アプリケーション層は、ビジネスロジックをインプリメントし、ローカルデータベースから

データにアクセスすることを提供します。

<essential pattern>プレゼンテーション層とアプリケーション層の間のリクエスター対話は同期 ― 同

期アクセス統合(Synchronous Access Integration)</essential pattern>で、ユーザーインタフェースから

送られるすべての要求がこのアプリケーション層の上でビジネスロジックを直接呼び出します。ビジ

ネスロジックが実行されると、制御権はプレゼンテーション層に渡され、戻された結果を使用して、

ユーザーインタフェースを更新します。

次のレベルの処理では、必要に応じてこれらの層がさらに細かな<architectural principle>機能コンポー

ネント単位に分割 ― 疎結合(Low Coupling) </architectural principle>されます。例えば、プレゼンテ

ーション層は、ユーザ<architectural principle>類縁性 (affinity) ― 高凝集度 (High Cohesion)

</architectural principle>とプロセス類縁性の項目に区分けされることがあります。代表的な Web のイ

ンプリメンテーションでは、ユーザ類縁性の部分は、クライアントデバイス上でユーザーインタフェ

ースを実行するプレゼンテーションロジックとなります。例えば、画面のナビゲーションと簡単な入

力検証をインプリメントする<essential pattern>JavaScript をダウンロードして、ブラウザークライアン

ト上で実行 ― 自動ダウンロードスクリプト(Automatic Download Script)、クライアントサイドスク

リプティング(Client-side Scripting)</essential pattern>します。プロセス類縁性の部分は、サーバー上

で実行されるプレゼンテーションロジックの<essential pattern>動的ページ作成 (Dynamic Page

Generation)</essential pattern>部分の場合があります。例えば、Java Server Page(JSP) ― サーバーサイ

ドスクリプティング(Server-side Scripting)</essential pattern>をサーバー上で実行して、HTML ページ

を動的に生成します。このアプリケーションパターンをインプリメントするには、IBM の WebSphere

Application Server のような Web アプリケーションサーバーがよく使用されます。

使用上のガイドライン(Guidelines for use)

アプリケーションサーバー・ベンダーは、サポート対象をスタンドアロンシングルチャネル・アプリ

ケーションパターンだけに限っている場合があります。<change case>将来的に Web アプリケーション

をバックエンドアプリケーションに統合する必要がある</change case>場合は、そうした<NFR quality

attribute>機能拡張 ― 機能拡張性(extensibility)<NFR quality attribute>のための明確なパスを提供す

るアプリケーションサーバーを選択してください。

アプリケーションサーバー・ベンダーは、<essential pattern>プレゼンテーションロジックとビジネス

ロジックの明確な分割 ― N 層アプリケーション(N-Tiered Application)</essential pattern>を推奨して

いない場合があります。そうしたベンダーを選択して明確な分割をできない場合は、アプリケーショ

ンの<primary quality attribute>保守容易性 ― 保守性(Maintainability)</primary quality attribute>が

低下するので<business risk>TCO(Total Cost of Ownership)が増加</business risk>します。プレゼンテー

ションロジックとビジネスロジックが混ざり合うと、プレゼンテーションロジックを変更したときに

ビジネスロジックに影響が生じ、ビジネスロジックを変更したときにもプレゼンテーションロジック

44

に影響が生じます。その結果として<IT risk>アプリケーションの大幅な更新が必要</IT risk>になりま

す。特に、e-business アプリケーションでは、<business strategy> 新技術を取り上げ、サイト・ユー

ザーを獲得および保持する</business strategy>ためには、ユーザの操作環境やサイトの<secondary

quality attribute>ルックアンドフィール (look and feel) ― 使用性 (Usability)</secondary quality

attribute>を<change case>常に機能強化する</change case>ためにも、これらの<essential pattern>論理

層を分離 ― N 層アプリケーション(N-Tiered Application) <essential pattern>することは重要です。

<business goal>顧客の要求を満足させる</business goal>ため、あるいは<business risk>競争で顧客を失

う</business risk>のを避けるためには、<business strategy>サイトに常に新しいビジネス機能を加える

</business strategy>必要があります。この分離を行うと、新のワイヤレス携帯情報端末(PDA)やネッ

トアプライアンスなど、<change case>新しいタイプのユーザーインタフェースを<NFR quality

requirement>即時に採用</NFR quality requirement>できます。</change case>

メリット(Benefits)

<disclaimer>バックエンドアプリケーションの統合</disclaimer>をすぐにまたは将来的に必要としな

いアプリケーションの場合は、このアプリケーションパターンは目的に合う適なアーキテクチャで

す。

このアプリケーションパターンでは、ブラウザーベースの HTML クライアントなどの<essential

pattern>シンクライアント</essential pattern>を使用します。プレゼンテーションロジックおよびビジ

ネスロジックの多くはサーバー上で実行します。<requisite>サーバーマシンを<essential pattern> パワ

ーアップ ― Scale Up</essential pattern>するか、またはアプリケーションロジックを<essential

pattern>多数のサーバーに拡散 ― Scale Out</essential pattern>すること</requisite>で、アプリケーシ

ョンを拡張することができます。これにより、<NFR constraint>アプリケーションパターンを変更し

なく</NFR constraint>ても<secondary quality attribute>拡張容易性 ― 性能拡張性 (Scalability)

</secondary quality attribute>を達成できます。

このアプリケーションパターンでは、ユーザーインターフェースクライアント(ブラウザーなど) とサ

ーバー上で実行するプレゼンテーション層部分との間の通信に、<essential pattern>HTTP などの接続

プロトコル―ステートレス接続(Stateless Connection)</essential pattern>を使用します。サーバーサイ

ドのプレゼンテーション層のコンポーネントでは、アプリケーション層(ビジネスロジックが組み込ま

れて、データベースにアクセスします )に対する<sensitivity point>接続を限られた数だけ維持

</sensitivity point >して、複数のユーザに対してこのような<essential pattern>接続をプール ― 接続プ

ール(Connection Pool)</essential pattern>できます。この戦略を使用すると、Web アプリケーションを

拡張して、<secondary quality requirement>数万人レベルの同時アクティブユーザ</secondary quality

requirement>をサポートできます。一方、従来の<contradictory pattern>クライアント/サーバー ― 2

層クライアントサーバー（Two-tier Client Server）＜/contradictory pattern>インプリメンテーション

で使用するプロトコルでは、<contradictory pattern>ユーザーインターフェースクライアントと各ユー

ザのサーバーの間の接続を維持 ― ステートフル接続(Stateful Connection) </contradictory pattern>し

ます。このような接続を維持すると、サーバー上のメモリーや処理能力などの重要な<IT risk>リソー

スを消費</IT risk>します。さらに、<NFR constraint>一定の時間についてサーバーが維持できる大

接続数が制限<NFR constraint>されます。その結果、従来の<contradictory pattern>クライアント/サー

45

バー</contradictory pattern>アプリケーションでは、<NFR quality requirement>数万人レベルの同時ユ

ーザをサポート</NFR quality requirement>する場合でも、</NFR quality attribute>拡張容易性 ― 性

能拡張性(Scalability) </NFR quality attribute>ついて重大な制約が課せられます。このアプリケーショ

ンパターンを使用すると、通常の<contradictory pattern>クライアント /サーバー</contradictory

pattern>アプリケーションで発生する</NFR quality attribute>拡張容易性 ― 性能拡張性(Scalability)

</NFR quality attribute>の問題を克服できます。

制限事項(Limitation)

<disclaimer>バックエンドアプリケーションの統合がないので、Web アプリケーションと関連データは

他の企業システム ― 業務システム(Enterprise System)から分離されます。</disclaimer> <situation>組

織内の多くの部門がそのような異種混合システムをインプリメントする場合</situation>、<residual IT

risk>それぞれのシステムのデータがミスマッチ</residual IT risk>する可能性があります。そうした

<disclaimer>情報を手動で同期</disclaimer>すると、エラーの原因となったり、<residual business risk>

組織の総合的な効率が低下</residual business risk>します。その結果、<residual business risk> TCO

(Total Cost of Ownership)が上昇</residual business risk>します。

<disclaimer>組織内の多数の部門が異種混合のスタンドアロン単一チャネル・アプリケーションをイン

プリメントおよび実行する</disclaimer>と、組織内の<residual IT risk>システム管理業務が二重三重に

必要</ residual IT risk>になります。

さらに、<disclaimer>1 つの組織で多数のスタンドアロン単一チャネル・アプリケーションが実行され

る</disclaimer>と、<residual IT risk>ビジネスロジックの再利用が難しく</residual IT risk>なり、この

結果として<residual business risk> TCO(Total Cost of Ownership)が上昇</residual business risk>します。

このアプリケーションパターンでは、<disclaimer>Web、コールセンターアプリケーション、キオスク、

音声認識装置、その他の様々なチャネルに対する統合はサポート</disclaimer>されていないので、

<residual business risk>ユーザは、チャネルごとに異なる回答を得る</residual business risk>ことがあ

ります。

パターンの使用例(Scenario)

ある大手保険会社が Web 販売チャネルを使用して、<business goal>対応範囲の拡大 ― 多経路マーケ

ティング(Multi-Marketing Channel) </business goal>を計画しました。既存のインフラストラクチャー

としては、電話セールスチャネルとバックエンドの保険証作成、保険金請求、請求書作成発行システ

ム(<essential pattern>バッチ処理</essential pattern>があります。オンライン取引には、「<essential

pattern> ホスト端末 </essential pattern>」装置を使用しています。<NFR constraint>バックエンドア

プリケーションを修正して、毎日 24 時間体制にすることは短期間にはできません。</NFR constraint>

この保険会社は、<disclaimer>バックエンドの統合</disclaimer>を必要としないサービスを提供するこ

とで、オンラインサービスを開始しました。サービスの内容は、近隣営業所の検索、ブローカーとエ

ージェントの検索、財務計算、および保険ニーズ分析ツールです。このサービスをサポートするため、

バックエンドの統合を必要としないスタンドアロン単一チャネル・アプリケーションパターンを選択

しました。

46

表 B-4 ルーター(Router)パターン記述

パターン名

セルフサービス::ルーター(Self-service::Router)


「ルーター」アプリケーションパターンの構造は、複数のデリバリー・チャネルから複数のバックエン

ドアプリケーションの中の 1 つのアプリケーションに対して要求を効率的に振り分ける必要があるよ

うなアプリケーションに適しています。


10. <business goal>ビジネス・イベントの待ち時間の短縮</business goal>

11. <business goal>合併買収時の適応が容易</business goal>

12. <business strategy>複数デリバリー・チャネルの統合</business strategy>

13. <business goal>TCO (Total Cost of Ownership) の小化</business goal>

14. <IT strategy>既存のスキルの有効利用</IT strategy>

15. <IT strategy>既存システムの有効利用</IT strategy>

16. <IT strategy>バックエンドアプリケーションの統合</IT strategy>

17. <business risk>企業の複雑さの軽減</business risk>

18. <primary quality attribute>保守容易性(Maintainability)</primary quality attribute>

19. <primary quality attribute>拡張容易性(Scalability)</primary quality attribute>

<application pattern>「ルーター」</application pattern>アプリケーションパターンを選択する基本的

なビジネス要件は、<business strategy>複数デリバリー・チャネルのシームレスな統合</business

strategy>をサポートすることです。現在のディジタル経済では、<functional requirement>ユーザは情

報への汎用アクセスを要求</functional requirement>します。この需要を満足するため、<business

strategy>インターネット、音声認識装置、キオスク、コール・センター・アプリケーションなどの複

数のデリバリー・チャネルを多くの会社がサポート</business strategy>しています。ユーザは、情報

へのアクセスにどのデリバリー・チャネルを使用した場合でも、<NFR quality requirement>情報(the

same information を取り出せる) ― <quality attribute>データの一貫性(Data Consistency) </quality

attribute></NFR quality requirement>と考えています。例えば、<scenario>証券会社などでは、ユーザ

が Web サイトまたは音声認識装置のいずれを使用した場合でも、同様の取引明細書を取り出せるよ

うにする</scenario>必要があります。同時に、<situation>このような企業には複数のバックエンドア

プリケーションがあります。例えば、各種の課税要件に対応するため、証券会社などでは個人年金口

座と通常の投資口座を異なるバックエンドアプリケーションで管理している場合があります。

</situation> このため、<functional requirement>多くのチャネルで、複数のバックエンドアプリケーシ

ョンの情報にアクセスする</functional requirement>必要があります。

<change case>アプリケーションは、新たな技術革新を利用したり、またはビジネス環境の変化を取り

入れて、時間とともに進化します。</change case> 理想的には、<IT strategy>このような変化は、他

のアプリケーションとは独立して実行されるべき</IT strategy>です。例えば、<situation>新技術を利

47

用するために 1 つのバックエンドアプリケーションを新しいシステムに置換する場合</situation>、<IT

risk>その置換によって、そのバックエンドアプリケーションにアクセスするデリバリー・チャネルの

すべてで大量の変更作業が必要</IT risk>にならないことが重要です。同時に、<situation>ワイヤレス

PDA などの新しいデリバリー・チャネルをサポートする場合</situation>には、<IT risk>バックエンド

アプリケーションに大きな変更が必要</IT risk>にならないようにすべきです。特に企業環境が不安定

で、<business strategy>合併買収</business strategy>などが計画されている企業では、そうした<quality

attribute>拡張性 ― 機能拡張性(extensibility) </quality attribute>が重要になります。このような企業

には、<application pattern>「ルーター」</application pattern>アプリケーションが理想的です。

このアプリケーションパターンを選択する基本的な IT 要件は、<business risk>「企業の複雑さの軽減」

</business risk>と<business goal>「TCO (Total Cost of Ownership) の削減」</business goal>です。この

ためには、デリバリー・チャネルとバックエンドアプリケーションの間で、<contradictory pattern>

Point-to-Point </contradictory pattern>アーキテクチャーの代わりに<essential pattern>「ハブ・アンド・

スポーク (hub-and-spoke) 」</essential pattern>アーキテクチャーを使用します。


上の図に示されているように、<application pattern>「ルーター」</application pattern>アプリケーシ

ョンパターンは、プレゼンテーション、ルーター、およびバックエンドアプリケーションの 3 つの

<essential pattern> 論理層 (Logical Tier) に分割 ― N 層アプリケーション (N-Tiered

Application)</essential pattern>されています。

20. 前述のセルフサービス・アプリケーション・パターン ― <application pattern>スタンドアロ

ン単一チャネル(Stand-Alone Single Channel) </application pattern>と異なり、このアプリケー

ションパターンの<IT strategy>プレゼンテーション層は、インターネット、コールセンター、

キオスク、および音声認識装置などのさまざまなプレゼンテーション・スタイルをサポート

</IT strategy>します。

21. ルーター層は、複数のプレゼンテーション・コンポーネントから要求を受け取り、正しいバ

ックエンド・トランザクションに<essential pattern>知的にルーティング ― インテリジェン

トルーティング(Intelligent Routing)</essential pattern>します。この層では、この操作のため

48

に<essential pattern>読取専用データベース</essential pattern>を使用して、<essential pattern>

ルーティング規則(Routing Rule)</essential pattern>を検索することができます。さらに、ルー

ターは、<essential pattern>メッセージ伝送</essential pattern>、<essential pattern>プロトコル

変換</essential pattern>、異なるレベルのセキュリティ管理、および<IT strategy>セッション

の集信(session concentration) ― セッションコンセントレーション</IT strategy>などを行い

ます。多くの場合、<requisite>ルーター層は小さなビジネスロジックをインプリメント

</requisite>します。このルーティング機能は、<functional requirement>1 つのバックエンド・

システムから他のバックエンド・システムに要求をルーティングする </functional

requirement>ときにも使用できます。

22. このアプリケーションパターンの<requisite>ビジネスロジックは、ほとんどがバックエンドア

プリケーション層に集中</requisite>しています。

パターン言語補足

セッションコンセントレーション (session concentration) : メッセージ・キューイングにより

Hub‐and‐spokeでルーティングすることにより、複数ノードの間に必要な Point‐to‐pointのセッション数

とネットワークトラフィックの量を少なくすること。

<essential pattern>プロトコル変換</essential pattern>を行うルーターは、<IT strategy>デリバリー・チャネ

ル固有のプロトコルの内容からバックエンド・トランザクションを切り分ける</IT strategy>ことができます。例え

ば、インターネット・アプリケーションでは、ブラウザーとプレゼンテーション層のサーバー・サイドとの接続に、通

常は HTTP を使用します。この層では、ルーターとの通信に RMI または IIOP を使用します。一方、コー

ル・センター・アプリケーションでは、RMI または IIOP を使用して要求をルーターに直接送信します。ルータ

ー層では、バックエンド・トランザクションを起動する前に、このような<functional requirement>プロトコル固

有の要求をプロトコルから独立した要求に変換</functional requirement>します。このアプローチでは、

<change case>将来的にワイヤレス PDA などの新しいタイプのデリバリー・チャネルをサポートする</change

case>必要が生じた場合でも、<NFR constraint>バックエンドアプリケーションを変更せず</NFR constraint>

― <quality attribute>機能拡張性 (Extensibility)</quality attribute>, <quality attribute>保守性

(Maintainability) </quality attribute> に対応できます。

<NFR quality requirement>デリバリー・チャネルごとに異なる<quality attribute>セキュリティー・レベル ―

セキュリティ(Security)</quality attribute>が必要</NFR quality requirement>になります。<business

policy>コール・センター・アプリケーションを使用するユーザには顧客の口座に関する特定の詳細を表示でき

るのに、セルフサービス Web チャネルなどを利用する顧客にはそうした情報を表示できない</business

policy>場合があります。このような<IT strategy>セキュリティー・レベルの違いは、デリバリー・チャネルの要件

に密接に結合しています。このため、バックエンドアプリケーションは、このような細部とは切り離す必要</IT

strategy>があります。ルーター層は、このようなセキュリティが必要な場合に理想的です。

高度な<quality attribute>拡張容易性 ― 性能拡張性(Scalability)</quality attribute>と優れた<quality

49

attribute>パフォーマンス ― 時間効率性、資源効率性</quality attribute>を達成するには、<functional

requirement>セッション管理と割り振り</functional requirement>をルーター層で実行する必要がありま

す。このため、ルーター層は、<requisite>バックエンド・システム・セキュリティー機能が許せば</requisite>、

複数のデリバリー・チャネルの数千人のユーザに対していくつかの<essential pattern>バックエンド接続を確

立してこれをプール ― 接続プール(Connection Pooling)</essential pattern>します。

プレゼンテーション層とルーター層の間のリクエスターの対話は、ルーター層とバックエンドアプリケーションの

間のリクエスターの対話と同様に同期 ― <essential pattern>呼び出し/戻り要求（Call/Return Request）

</essential pattern> 、 <essential pattern> 同期アクセス統合 (Synchronous Access

Integration)</essential pattern> 、 <essential pattern>同期プロセス統合 (Synchronous Process

Integration)</essential pattern>します。<disclaimer>その結果、<condition>バックエンド・システムを利用

できない場合</condition>は、その<mode of operation>バックエンドアプリケーションがサポートするビジネ

ス機能をすべてのデリバリー・チャネルで利用することはできなく ― 機能制限モード(limited service

mode)</mode of operation>なります。</disclaimer>

アプリケーションパターンでの<essential pattern>同期 (またはブロッキング) 要求 ― <essential pattern>

呼び出し/戻り要求（Call/Return Request）</essential pattern></essential pattern>は、ランタイム・パター

ン・レベルでは<essential pattern>同期 ― 同期接続(Synchronous Connection)または非同期通信プロト

コル ― 非同期接続(Asynchronous Connection)になることに注意してください。


このアプリケーションパターンでは、上に示した機能を提供するため、この Web サイトの他の場所に記載され

ている<requisite><application pattern>「アクセス統合」</application pattern>および<application

pattern>「アプリケーション統合」</application pattern>のパターンを使用</requisite>します。例えば、この

アプリケーションパターンで複数のデリバリー・チャネルをサポートするには、「アクセス統合」の<application

pattern>「デバイス・サポート・サービス」</application pattern>アプリケーションパターンを使用できます。同

様に、ルーター層では、<application pattern>「アプリケーション統合:ブローカー・アプリケーション・パター

ン」</application pattern>に記載の統合技術を使用します。

このソリューション設計の Product mappings の項で後述しますが、このアプリケーションパターンのインプリ

メンテーションには、WebSphere Application Server® などの Web アプリケーション・サーバーおよび

MQSeries Integrator などの<essential pattern>メッセージ・ブローカー</essential pattern>がよく利用され

ます。


このアプリケーションパターンでは、デリバリー・チャネルの<quality attribute>可用性</quality

attribute>、<quality attribute>拡張容易性</quality attribute>および<quality attribute>パフォーマンス

</quality attribute>は、バックエンドアプリケーションの<quality attribute>可用性</quality attribute>、

50

<quality attribute>拡張容易性</quality attribute>および<quality attribute>パフォーマンス</quality

attribute>に強く依存します。このため、<requisite>バックエンドアプリケーションのインプリメンテ

ーションには、堅固な<essential pattern>トランザクション処理</essential pattern>システム</requisite>

を使用すべきです。このアプリケーションパターンは、<IT strategy>既存または新規の<essential

pattern>トランザクション処理</essential pattern>システムの Web 対応化</IT strategy>に使用できま

す。

<situation>新規バックエンドアプリケーションの開発または既存バックエンドアプリケーションの変

更を行うとき</situation>には、<requisite>トランザクションをチャネルと独立 ― <architectural

principle> 疎結合(Low Coupling)</architectural principle>して<quality attribute>再利用可能な形態

― 再利用性(Reusability)</quality attribute>に定義する</requisite>必要があります。これにより、ワ

イヤレス PDA デバイスなどの<business strategy>新しいチャネルにトランザクションを簡単に迅速

に拡張できます。</business strategy>


このアプリケーションパターンで、<requisite>ルーターを使用して<essential pattern>セッション集信

― セッションコンセントレーション(session concentration) </essential pattern>を管理</requisite>し、

<requisite>ビジネスロジックのインプリメンテーションに堅固な<essential pattern>トランザクション

処理</essential pattern>システムを使用する</requisite>と、高度な<quality attribute>拡張容易性

</quality attribute>と優れた<quality attribute>パフォーマンス</quality attribute>を得ることができま

す。このアーキテクチャーは、現在の大容量 e-business サイトの多くにとって、目標となるアーキテ

クチャーです。

このアプリケーションパターンでは、デリバリー・チャネルからバックエンド・インプリメンテ

ーションの細部を切り離し、バックエンドアプリケーションからデリバリー・チャネル・インプ

リメンテーションの詳細を切り離します。このような <architectural principle>疎結合

</architectural principle>のアーキテクチャーにより、<IT strategy>バックエンドアプリケーショ

ンとデリバリー・チャネルの変更、置換および追加を簡単に実行 ― <quality attribute>変更性

(Changeability)、機能拡張性(Extensibility)</quality attribute></IT strategy>でき、<IT risk>アーキ

テクチャー内の他のアプリケーションに影響を与えること</IT risk>もありません。

さらにこのような<architectural principle>疎結合</architectural principle>のアーキテクチャーで

は、<quality attribute>保守容易性</quality attribute>を向上し、<business goal>TCO (Total Cost of

Ownership) を低減</business goal>します。

<IT strategy>複数のデリバリー・チャネルに対して同一のバックエンド・トランザクションを使

用するので、複数のシステム上に同一のビジネスロジックを複写する必要がありません。</IT

strategy> その結果、ビジネスロジックの変更を 1 つのシステムで実行できます。これにより、

システム全体の<quality attribute>保守容易性</quality attribute>が向上します。


特定のビジネス機能の<quality attribute>可用性</quality attribute>は、バックエンドアプリケーシ

ョンの<quality attribute>可用性</quality attribute>に強く依存します。<NFR constraint>現在、多

51

くの組織で使用されている<essential pattern>トランザクション処理</essential pattern>システム

は、毎日の使用可能時間が制限</NFR constraint>されています。<mode of operation 使用不可能な

時間帯 ― オフラインモード(offline mode)は、<essential pattern>バッチ処理 ― オフラインバッ

チ処理(offline batch processing)</essential pattern>、<essential pattern>バックアップ処理 ― オフ

ラインバックアップ処理(offline backup)</essential pattern>、および</essential pattern>保守活動

― オフライン保守(offline maintenance)</essential pattern>などに使用されます。 <disclaimer>デ

リバリー・チャネルを使用して Web 上でセルフサービス機能を提供するには、そうした

<unachievable IT goal><NFR quality requirement>システムの<quality attribute>可用性</quality

attribute>を毎日 24 時間体制に拡張する</NFR quality requirement></unachievable IT goal>必要

があります。<business risk>既存システムでそのような拡張を行うことはコストが高く、時間もか

かります</business risk>。</disclaimer>

ここでの主な焦点は、複数のデリバリー・チャネルからバックエンドアプリケーションへのアク

セスを提供することです。<NFR constraint>ほとんどのバックエンドアプリケーションは製品固

有 ― 製品中心(Product-centric)</NFR constraint>になっており、「ルーター」アプリケーション

パターンでは、<disclaimer>製品固有の表示から総合的な顧客中心的な表示 ― 顧客中心

(Customer-centric)への移行方法に関する議論はありません。</disclaimer>このような状況では、

<application pattern>「分解」</application pattern>または<application pattern>「エージェント」

</application pattern>などのより高度なアプリケーションパターンの使用を考慮する必要があり

ます。


<situation>ある大手金融会社が証券取引、投資信託、銀行、クレジット・カード・サービスを顧

客に提供しています。</situation>もちろん、<NFR constraint>このような業務活動は、それぞれ

が性質の異なるバックエンドアプリケーションを必要</NFR constraint>とします。この会社が使

用する<NFR constraint>デリバリー・チャネルには、インターネット、セルフサービス、キオス

ク、音声認識装置、24 時間体制のコールセンター、および各支店での窓口サービス</NFR

constraint>があります。

<business policy>すべてのチャネルからすべての口座情報を得ることはできません。例えば、証券

取引と投資信託の口座にアクセスできるのは、インターネット、音声認識装置、およびコールセ

ンターを使用した場合だけです。一方、銀行口座情報にアクセスできるのは、キオスク (ATM)、

音声認識装置、および支店窓口に限られます。</business policy>

現在、バックエンドアプリケーションとの接続には、異なるチャネルで <contradictory pattern>

Point-to-Point </contradictory pattern> を使用しています。<contradictory pattern>チャネルの中に

はデータのコピーが作成 ― オペレーショナルデータストア(ODS) </contradictory pattern>さ

れる場合もあり、<business risk>特定のタイミングでチャネルごとに情報に不整合 ― <quality

attribute>データ整合性(Data Consistency)</quality attribute>が生じること</business risk>があり

ます。製品関連 ― 製品中心(Product-centric)のバックエンドアプリケーションのほとんどが、堅

固な<essential pattern>トランザクション処理</essential pattern>システムなので、<NFR quality

requirement>毎日 24 時間の体制 ― <quality attribute>可用性(Availability) </quality attribute>

52

十分に可能</NFR quality requirement>です。(適切な翻訳: 幸いにも、製品中心のバックエンドア

プリケーションのほとんどは、毎日 24 時間体制で運用できる堅牢なトランザクション処理シス

テムだったので・・・)

<NFR quality requirement>会社は、すべてのチャネルを使用して、すべての製品情報について、

一貫したアクセス ― <quality attribute>データ整合性(Data Consistency) </quality attribute>を提

供したい</NFR quality requirement>と考えています。さらに、目的のアーキテクチャーでは、

<quality attribute>拡張性 ― 性能拡張性(Scalability)</quality attribute>、<quality attribute>可用

性</quality attribute>、<quality attribute>応答時間</quality attribute>などが優れている必要があ

ります。このような目標を達成するため、会社は「ルーター」アプリケーションパターンを選択

しました。

53

表 B-5 分解(Decomposition)パターン記述

パターン名

セルフサービス::分解(Self-service::Decomposition)


「分解」アプリケーション・パターンは、「ルーター」アプリケーション・パターンの「ハブ・アンド・

スポーク (hub-and-spoke) 」アーキテクチャーを拡張します。クライアントから出される 1 つの複合

要求を複数の簡単な要求に分解して、複数のバックエンドアプリケーションに知的にルーティングし

ます。通常、複数のバックエンドアプリケーションから出された応答は、1 つの応答として再構成され

てからクライアントに返送されます。


23. <business goal>組織内の効率性の改善</business goal>




27. <business strategy>業務種別 (LOB) 全体で顧客表示の統一</business strategy>





32. <business risk>企業の複雑さの軽減</business risk>



<application pattern>「ルーター」</application pattern>アプリケーション・パターンのすべてのビジ

ネス要件および IT 要件がここでも該当します。さらに、バックエンドアプリケーションは、多くの

組織で<business strategy>特定の製品種別 ― 製品・商品中心(Product Centric) に焦点が当てられてい

る</business strategy>ことも要件の 1 つです。例えば、保険会社はさまざまなシステムを使用して、

健康保険や生命保険をサポートしています。<business policy>ビジネス・ロジックやビジネス・データ

の要件は製品ごとに大きく異なる</business policy>ので、そのような製品固有の業務スタイルは必要

性から進化したといえます。同じ理由で、多くの企業が<NFR constraint>製品種別単位に異なるシス

テムを使用</NFR constraint>しています。

しかし、このような会社でも、<business strategy>顧客がセルフサービス Web サイトやコールセンタ

ーにアクセスしたときには、製品ごとにばらばらの表示をするのではなく、統一された表示を顧客に

提供 ― 顧客中心(Customer Centric)したい</business strategy>と考えています。同様に <NFR quality

requirement>1 つのシステムで顧客情報に変更があった場合には、その内容が他のシステムに自動的に

反映 ― <quality attribute>データ整合性 (data consistency)</quality attribute>されるべき</NFR

quality requirement>です。例えば、健康保険と生命保険を取り扱っている上記の保険会社では、住所

54

変更などの情報は、両方のシステムに自動的に反映されるべきです。<business risk>顧客は複数の口座

について統一された表示を求めることがある ― 顧客の苦情(customer complaint)</business risk>の

で、このような機能は重要です。


上の図に示されているように、<application pattern>「分解」</application pattern>アプリケーション

パターンは、プレゼンテーション、分解(Decomposition)、およびバックエンドアプリケーションの 3 つ

の<essential pattern>論理層(Logical Tier)に分割 ― N 層アプリケーション(N-Tiered Application)

</essential pattern>されています。

35. プレゼンテーション層については、<application pattern>「ルーター」</application pattern>

アプリケーション・パターンを参照してください。

36. 分解層は、要求の<essential pattern>インテリジェントルーティング</essential pattern>、

<essential pattern>プロトコル変換</essential pattern>、セキュリティ、およびセッション集信

― セッションコンセントレーション(session concentration)など、<application pattern>「ルー

ター」</application pattern>アプリケーション・パターンのルーター層が提供するサービスの

ほとんどをサポートします。さらに、分解層ではインテリジェンスをインプリメントして

<functional requirement>1 つのプレゼンテーション・クライアント要求を簡単な複数の要求に

<essential pattern>分解(Decomposition)</essential pattern>し、複数のバックエンドアプリケー

ションにルーティング</functional requirement>します。この操作を実行する時には、

<functional requirement>ローカルの <essential pattern>「進行中の作業 (WIP)」データベース

</essential pattern>を使用して、ルーティング、分解、および再構成の<essential pattern>各規

則(rule)</essential pattern>を保管し、目的の応答が再構成されるまで、複数のバックエンドア

プリケーションの結果を<essential pattern>キャッシュ (cache)</essential pattern>します

</functional requirement>。分解層では、ルーター層よりも多数のビジネス・ロジックをイン

プリメントします。この<functional requirement>ビジネス・ロジックでは、顧客中心の統一

表示(unified customer-centric view)を提供する</functional requirement>ことが焦点となりま

す。

37. <NFR constraint>製品および機能に固有のビジネス・ロジック(product and function specific

55

business logic)の多くは、ここでもバックエンドアプリケーション層に集中(concentrated in)

</NFR constraint>されています。このような<requisite>バックエンドアプリケーションには、

<quality attribute>可用性</quality attribute>と<quality attribute>拡張性</quality attribute>に

優れた<essential pattern>オンライン・トランザクション処理</essential pattern>システムと

<essential pattern>バッチ</essential pattern>・アプリケーション</requisite>とがあります。


セッションコンセントレーション(session concentration) : メッセージ・キューイングにより Hub‐and‐spokeで

ルーティングすることにより、複数ノードの間に必要な Point‐to‐point のセッション数とネットワークトラフィック

の量を少なくすること。

プレゼンテーション層と分解層の間のリクエスター対話 ― アクセス統合(Access Integration)は<essential

pattern>同期</essential pattern>します。分解層とバックエンドアプリケーション層の間のリクエスター対話

― アプリケーション統合(Application Integration)は、<essential pattern>同期</essential pattern>の

場合と<essential pattern>非同期</essential pattern>の場合があります。

保険会社とその顧客の場合のように、<situation><NFR quality requirement>プレゼンテーション・クライ

アントが即時の応答を求める</NFR quality requirement>場合</situation>は、<essential pattern>リク

エスター対話を同期 ― 同期アクセス統合(Synchronous Access Integration)</essential pattern>させる

必要があります。保険会社の例では、顧客がセルフサービス Web サイトにログオンして、総合請求書の表示

を求めます。<functional requirement>この要求は、複数の同期要求に<essential pattern>分解

</essential pattern>されて、複数の製品固有の請求書作成発行システムに向けられ</functional

requirement>ます。分解層は、<functional requirement>これらのシステムからの応答が届くと、結果を組

み合わせて、顧客に総合請求書を表示</functional requirement> ― 同期プロセス統合(Synchronous

Process Integration)</essential pattern>します。

<situation><unnecessary requirement>プレゼンテーション・クライアントが即時の応答を求めない ― 応

答に長時間を要するサービスであることを顧客が理解しており、通知を受ける、または、セルフサービスで確

認することに同意している場合<unnecessary requirement>場合</situation>は、<essential pattern>

分解層とバックエンドアプリケーションの間のリクエスター対話を非同期 ― 非同期プロセス統合

(Asynchronous Application Integration)</essential pattern>にできます。例えば、顧客がセルフサー

ビス Web サイトを使用して、自分の口座からその月の請求分を支払う操作をする場合があります。この要

求は、2 つの要求に分解されます。 <essential pattern> 初の要求は確認エンジン(confirmation

engine)に向けられて、処理確認のために顧客に確認番号を同期で提供 ― 同期プロセス統合</essential

pattern> します。同時に、<essential pattern>非同期要求がバッチ・システムに送られ、このシステムは

EDI 技術を使用して地元の銀行に電子振替要求を送信 ― 非同期プロセス統合</essential pattern>し

ます。

このパターンのバリエーションとしては、2 番目の論理層で<essential pattern>キャッシング</essential

56

pattern>を行い、<IT strategy>バックエンドアプリケーションへのアクセス量を抑える ― <quality

attribute>時間効率性(Time Efficiency) </quality attribute> : <NFR quality requirement>短い応答

時間</NFR quality requirement>、<quality attribute>資源効率性(Resource Efficiency) </quality

attribute> : <NFR quality requirement>バックエンドの資源制約の下で大量のスループット</NFR

quality requirement></IT strategy>方法があります。もう 1つのバリエーションとしては、< IT strategy >

高速非同期通信を使用して複数の要求を同時に 3 番目の層に送り ― <essential pattern>非同期並列

処理(Asynchronous Parallel Processing) <essential pattern>、<NFR quality requirement>逐次的

な要求方法よりも ― <quality attribute>時間効率性(Time Efficiency) </quality attribute> :応答時間

を改善する</NFR quality requirement>方法</ IT strategy >があります。

このパターンの場合も、<application pattern>「セルフサービス: ルーター」</application pattern>アプリ

ケーション・パターンと同様に、「Patterns for e‐business」Web サイトの他の場所に記載されている、

<application pattern>「アクセス統合」、</application pattern>および、<application pattern>「アプリケ

ーション統合」、</application pattern>などのパターンの要素を使用します。特に、このアプリケーション・パ

ターンでは、<requisite><application pattern>「アプリケーション統合: ブローカー・アプリケーション・パタ

ーン」</application pattern></requisite>に記載の技法を使用します。

このアプリケーション・パターンの Product mappings の項で後述しますが、WebSphere Advanced Edition

V4 のような優れた Web アプリケーションを使用すると、メッセージ指向のミドルウェアを完全統合して、この

アプリケーション・パターンを使用できます。

考慮事項(Considerations)

ビジネス要求を複数のバックエンド・トランザクションに分解して、1 つのビジネス応答として複数の

応答を再構成する方法には多数のアプローチがあります。次のような方法があります。

<essential pattern>RYO (roll-your-own: ユーザ作成プログラム) </essential pattern> を作成して、

複数の非同期要求をバックエンド・システムに発行し、応答を構成する。

<essential pattern>メッセージ・ブローカー</essential pattern>と<essential pattern>ルール・エン

ジン</essential pattern>を使用する (<essential pattern>2 フェーズコミット (2PC) </essential

pattern> または<essential pattern>補正メカニズム ― 補償(compensation)＜/essential pattern>を

付けることができる)。

<essential pattern>2PC </essential pattern>プロトコルの<essential pattern>コンポーネント・ブロ

ーカー</essential pattern>を使用する。

パターン言語の補足

2 フェーズコミット/2PC(Two Phase Commit) : 同一のグローバルトランザクションスコープ内で各シ

ステムのリソースマネージャーが密結合された複数システム間でビジネス上の整合性を維持するメカ

ニズムである。グローバルトランザクションマネージャーが第一フェーズで全てのシステムにコミッ

トの可否を確認した後、第二フェーズで全てのシステムで同期コミットするため、トランザクション

をコミットできないシステムが一つでもあると全体のシステムでロールバックが行われ、全体の整合

性を自動的に維持できる。グローバルロックの時間が長くなると、全てのシステムのスループットや

57

応答時間が悪化するリスクがある。

補償(compensation) : 独立したトランザクションスコープ内で各システムのリソースマネージャーが

疎結合された複数システム間でビジネス上の整合性を維持するメカニズムである。全てのシステムの

トランザクションに対して 2 フェーズの同期コミットを行わないため、トランザクションをコミット

できないシステムが一つでもあると全体の整合性が失われた状態が発生する。各システム別にコミッ

トされたトランザクションを取り消す補償トランザクションにより、ビジネス上の整合性を維持する

必要がある。2 フェーズの同期コミットによるグローバルロックが発生しないため、全てのシステム

のスループットや応答時間が悪化するリスクがない。


「ルーター」アプリケーション・パターンに記載のすべてのガイドラインがここでも該当します。

<situation>新規バックエンドアプリケーションの開発または既存バックエンドアプリケーションの変

更を行うとき</situation>には、<requisite>トランザクションをチャネルと独立 ― <architectural

principle> 疎結合(Low Coupling)</architectural principle>して<quality attribute>再利用可能な形態

― 再利用性(Reusability)</quality attribute>に定義する</requisite>必要があります。これにより、ワ

イヤレス PDA デバイスなどの<business strategy>新しいチャネルにトランザクションを簡単に迅速

に拡張できます。</business strategy>


このアプリケーション・パターンでは、<application pattern>ルーター</application pattern>のすべて

のメリットが提供されます。さらに、次のメリットがあります。

<business strategy>製品中心のばらばらな情報表示ではなく、顧客中心の総合的な表示を提供

</business strategy>できます。

必要に応じて<IT strategy>トランザクションをバッチ・モードで実行</IT strategy>するので、<IT

strategy>システム・リソースを実行中のより重要なタスクに解放する</IT strategy>など、複数の

メリットがあります。 <application pattern>「分解」</application pattern>アプリケーション・パ

ターンではトランザクションを区別して、状況に応じて<essential pattern>非同期モードで通信

― 非同期プロセス統合</essential pattern>できます。このことは<unnecessary requirement>デー

タ・ストアに即時に更新を反映する必要 ― <quality attribute>データ新性(Data Currency)がな

い場合</unnecessary requirement><に該当します。


このアプリケーション・パターンの焦点は、<business strategy>顧客中心の統一された情報表示を

提供すること</business strategy>です。ただし、<disclaimer>そのような情報は必要なときにだけ

収集されて、トランザクションの後には廃棄</disclaimer>されます ― <essential pattern>一時

データ(Transient Data)</essential pattern>。このため、このアプリケーション・パターンでは、サ

ービスの一括カスタマイズや関連商品販売などの目的に使用する<contradictory pattern>オペレ

ーショナル・データ・ストア (ODS) <contradictory pattern>にすべての必要情報は累積されませ

ん ― <essential pattern>一時データ(Transient Data)</essential pattern>。このような場合は、さ

らに高度な「エージェント」アプリケーション・パターンの使用を考慮してください。


58

<application pattern>「ルーター」</application pattern>アプリケーション・パターンの例に登場

した<situation>大手金融会社が<business strategy>すべてのデリバリー・チャネルですべての製品

情報に一貫したアクセスを提供する</business strategy>ことを計画</situation>しました。

会社は、<business strategy>製品単位のばらばらの表示を提供するのではなく、どのチャネルを使

用した場合でも顧客中心の統一表示を提供したい</business strategy>と考えました。例えば、証

券取引口座、投資信託口座、銀行口座、クレジット・カード口座などの合計資産(a consolidated net

worth)を顧客に総合的に表示すること(a consolidated customer-centric view)を計画しました。インタ

ーネット、セルフサービス、キオスク、音声認識装置、24 時間体制のコールセンター、および支

店窓口のすべてのデリバリー・チャネルでそうしたサービスの提供を目標としました。この目標

を達成するため、会社は「分解」アプリケーション・パターンを選択しました。

59

表 B-6 エージェント(Agent)パターン記述

パターン名

セルフサービス::エージェント(Self-service::Agent)


「エージェント」アプリケーションパターンによるアプリケーション設計構造では、サービスの一括カ

スタマイズや関連商品販売を可能にする、顧客中心の統一表示を提供します。


38. <business goal>組織内の効率性の改善</business goal>




42. <business strategy>業務種別 (LOB) 全体で顧客表示の統一 ― ユニファイドカスタマービュ

ー(Unified Customer View) </business strategy>

43. <business strategy> 効率的な関連商品販売のサポート ― クロスセリング

(Cross-Selling)</business strategy>

44. <business strategy>一括カスタマイズ ― マスカスタマイゼーション(Mass Customization)

</business strategy>





49. <business goal>企業の複雑さの軽減</business goal>



「分解(Decomposition)」アプリケーションパターンのすべてのビジネス要件および IT 要件がここでも

該当します。さらに、このパターンは、インターネットのセルフサービス・サイトで、<business

strategy>一括カスタマイズ ― マスカスタマイゼーション(Mass Customization)</business strategy>や

<business strategy>関連商品販売 ― クロスセリング(Cross-Selling)</business strategy>を目的とする、

<business strategy>統一された顧客表示 ― ユニファイドカスタマービュー(Unified Customer View)

</business strategy>を可能にします。

ビジネス戦略の補足説明

ユニファイドカスタマービュー(Unified Customer View): 顧客満足度の向上による収益性向上のため

に、複数の製品ラインやサービスに対して一貫性のある統一された見え方(ビュー)を顧客に提供する顧

客中心(Customer-centric)のビジネス戦略で製品中心(Product-centric)と対比される。シングルカスタマー

ビュー(Single Customer View)とも呼ばれ、コールセンターや EC ショップ(Webshop)は、ワンストップ

60

サービス(One Stop Service)やワンストップショップ(One Stop Shop)と呼ばれている。

クロスセリング(Cross Selling): 顧客の注文に際して、顧客ニーズに合わせて関連する他の商品やサー

ビスを紹介して販売促進するビジネス戦略である。顧客の注文より上位の商品やサービスを紹介する

戦略は、アップセリング(Up Selling)と呼ばれている。

マスカスタマイゼーション(Mass Customization): 大量生産(Mass Production)と同程度の低コストで、パ

ーソナライゼーション(Personalization)を提供して、オーダーメードやカスタムメイドに近い顧客の個

別要望に応えるビジネス戦略である。


上の図に示されているように、このアプリケーションパターンは、プレゼンテーション、エージェン

ト、およびバックエンドアプリケーションの 3 つの<essential pattern>論理層(Logical Tier)に分割 ―

N 層アプリケーション(N-Tiered Application)</essential pattern>されています。

52. プレゼンテーション層およびバックエンドアプリケーション層については、「ルーター」アプ

リケーションパターンを参照してください。

53. エージェント層は、前述のアプリケーションパターンの分解(Decomposition)層によるサービス

をすべてサポートします。さらに、ユーザと組織の関係の統合された<essential pattern>表示

を動的に構築 ― 動的ページ生成(Dynamic Page Generation) </essential pattern>します。これ

を利用して、<business strategy>各個別ユーザに適した組織の商品やサービスを一括カスタマ

イズ ― マスカスタマイゼーション(Mass Customization)</business strategy>する方法を見付

けます。これにより、<essential pattern>ユーザに対して事例に閲覧をさらに「押し出し」て

(This results in pushing' an additional browser instance in front of the user)、ユーザは、固有のタス

クを実行する前に(before continuing with their original task.)、カスタマイズ内容を受け入れるか、

または拒否するかを選択できます。(so they can accept or reject the customized offer,) ― パーソ

ナライズページ(Personalized Page) </essential pattern >

この設計のバリエーションとしては、<IT risk>総合表示の動的収集(dynamically gather the consolidated

view)に時間がかかりすぎる場合や高価な場合</IT risk>に、<essential pattern>オペレーショナル・デ

ータ・ストア (ODS) </essential pattern>をインプリメントすると、<IT strategy>総合的な顧客情報ファ

61

イル(consolidated Customer Information File - CIF) を管理</IT strategy>できます。この<functional

requirement>CIF では、顧客が加入しているすべてのサービスについて、複数のオペレーショナル・

システムから集約され、総合表示 (integrated view) </functional requirement>を <NFR quality

requirement> 現行状態 (current) またはリアルタイムに近い状況 (near real-time) </NFR quality

requirement>で提供できます。さらに、<IT goal>顧客の個人情報をさまざまなソースから収集して保

管</IT goal>できます。この情報は、<IT strategy>カスタマー・リレーションシップ・マネージメン

ト (CRM) システム</IT strategy>で<business goal>顧客サービス改善</business goal>のために使用し

ます。

インターネットのセルフサービス・サイトでは、<functional requirement>特別な情報を使用して、顧

客の個人情報 ― 顧客層(Customer Demographics)に一致した特定のサービス ― 顧客ターゲット特

化サービス (target certain services)を見つけること</functional requirement>ができます。コール・セ

ンター・アプリケーションでは、<functional requirement>この個人情報を使用して、顧客サービス担

当者 (CSR) に関連商品販売スクリプト ― クロスセリングスクリプト(cross selling script)を提供

</functional requirement>して、<business strategy>顧客に追加サービスの加入を勧誘できる</business

strategy>ようにします。<change case>この関連商品販売プロセスは、顧客データから推論するような

アプリケーション (エキスパート・システム) を使用して、プログラマチックに起動すること(be driven

programmatically)もできます。</change case>

この設計のもう 1つのバリエーションとしては、<essential pattern>エージェント層</essential pattern>

の<essential pattern>「進行中の作業(work-in progress)」データベース</essential pattern>を使用すると、

<functional requirement>バックエンドアプリケーションで確定する前に、長期実行トランザクショ

ン・データを保留できます。(to hold long running transaction data before committing such information to back

end applications.) </functional requirement> 例えば、<scenario>住宅金融会社の Web サイトで、住宅ロ

ーンの詳細な申込書をオンラインで提出することが考えられます。このサイトでは、ユーザは複数の

ログイン・セッションを使用して、ローン申込書を完成します。つまり、このサイトでは、ユーザが

「進行中の作業」のローン申込書を保管しておき、申込書を後で完成させることができます。このよう

な「進行中の作業」の申込書は、顧客が申込書を完成するまで、バックエンドのローン承認エンジン

には提出されません。</scenario> エージェント層を効率的に使用すると、このような<functional

requirement>長期実行トランザクションを保管して、トランザクションが完了してからバックエンド

アプリケーションで確定することができます。</functional requirement>

<requisite>製品および機能に固有のビジネスロジックの多くは、ここでもバックエンドアプリケーシ

ョンに集中</requisite>されています。このような<requisite>バックエンドアプリケーションには、

<quality attribute>可用性</quality attribute>と<quality attribute>拡張性</quality attribute>に優れたオ

ンライン・トランザクション処理システムとバッチ・アプリケーション</requisite>とがあります。

各層の間のリクエスターの対話は、<essential pattern>同期</essential pattern>の場合と<essential

pattern>非同期</essential pattern>の場合があります。層の間が<essential pattern>非同期</essential

pattern> の場合は、 <requisite> アプリケーション設計を正しく </requisite> 行えば、 <IT

risk><condition>1 つのシステムが使用できなくなった場合</condition>でも、システムの総合的な可用

性に影響</IT risk>はありません。つまり、<condition>1 つのバックエンドアプリケーションが使用

62

できなくなった場合</condition>でも、<functional requirement>そのバックエンドアプリケーションに

向けられた要求をプレゼンテーション層が受け入れて、その要求を保管しておき</functional

requirement>、 <condition>バックエンドアプリケーションが使用できるようになってから

</condition><functional requirement>処理すること</functional requirement>ができます。

このアプリケーションパターンでは、上記の機能を提供するために、この Web サイトに記載の

<requisite>「アクセス統合」</requisite>と<requisite>「アプリケーション統合」</requisite>のパター

ンの要素を使用します。特に、<application pattern>「アプリケーション統合:ブローカー」</application

pattern>および<application pattern>「データ主体アプリケーション統合:オペレーショナル・データ・

ストア」</application pattern>に記載の技法を使用できます。

ビジネス戦略の補足説明

顧客層(customer demographics): 年齢、地位、職業などで顧客を層別してセグメンテーションすること。

顧客ターゲット特化サービス (target certain services) : 顧客層のニーズや価値観に的を絞ったサービ

スを提供すること。

クロスセリングスクリプト(Cross Selling Script): クロスセリングを促すスクリプトのこと。コールセ

ンターやコンタクトセンターでは、オペレーターが電話対応する際の指針となる基本的な対話台本を

スクリプトと呼んでいる。


<application pattern>「分解(Decomposition)」</application pattern>アプリケーションパターンに記載の

すべてのガイドラインがここでも適用できます。さらに、<IT risk>バックエンドアプリケーションの

間でデータの不整合が生じる可能性</IT risk>があるので、上記の <essential pattern>ODS </essential

pattern>バリエーションを使用して、<NFR quality requirement>データの調整をしておくこと</NFR

quality requirement>が望まれます。 <business risk>顧客の好みに関する認識の確かさ</business risk>

は、<sensitivity point>CIF <essential pattern>オペレーショナル・データ・ストア</essential pattern>と

データ解釈に使用する<quality attribute>アルゴリズムの品質 ― 機能性 (Functionality):正確性

(Accuracy)</quality attribute></sensitivity point>に大きく依存します。 <functional requirement>この

ような CIF <essential pattern>オペレーショナル・データ・ストア</essential pattern>を作成すること

</functional requirement>は、<tradeoff point><quality attribute>時間がかかり ― 効率性(Efficiency):

時間効率性 (Time behavior) </quality attribute >、 <quality attribute>内容も複雑 ― 保守性

(Maintainability):変更性(Changeability)</quality attribute ></tradeoff point>です。データ・ストアを作

成した場合は、<requisite>顧客中心の総合表示(the unified customer-centric view)と製品中心のアプリケ

ーション・データ(the product-centric application data)の間で<essential pattern>情報の同期化 ― 情報同

期化 (Information Synchronization)</essential pattern></essential pattern> を行って <NFR quality

requirement>常に更新 ― <quality attribute>データ一貫性(Data Consistency)、データ新性(Data

Currency) </quality attribute></NFR quality requirement>する</requisite>必要があります。さらに、個

人情報(demographic information) ― 顧客層(customer demographics)の情報は、<requisite>外部ソースか

ら定期的に購入して、CRM <essential pattern>オペレーショナル・データ・ストア</essential pattern>

と<essential pattern>同期化 ― 情報同期化 (Information Synchronization)</essential pattern>する

63

</requisite>必要があります。 <residual IT risk> CIF オペレーショナル・データ・ストアの作成、更新、

拡張には、ビジネス・プロセスと技術インフラストラクチャーを明確に設計するように注意する ― IT

リスクを明示していない</residual IT risk>必要があります。


<application pattern>「エージェント」</application pattern>アプリケーションパターンでは、

<application pattern>「分解」</application pattern>アプリケーションパターンのすべてのメリットが

提供されます。さらに、<essential pattern>パーソナライゼーション</essential pattern>手法を使用して、

企業がマーケットに提供している製品およびサービスの<business strategy>一括カスタマイズ ― マ

スカスタマイゼーション(Mass Customization)</business strategy>を実行できます。同様の手法を使用

して、<business strategy>効果的な関連商品販売 ― クロスセリング(Cross-Selling)</business strategy>

の目的に使用できます。


<application pattern>「エージェント」</application pattern>アプリケーションパターンでは、<essential

pattern>「ハブ・アンド・スポーク( hub-and-spoke) 」</essential pattern>アーキテクチャーを使用して、

<IT strategy>複雑さを軽減した</IT strategy>上で、すべてのビジネス要件および IT 要件を満たすこ

とが目的です。しかし、<residual IT risk>エージェント層のインプリメンテーションはどうしても複

雑になります。</residual IT risk> その理由は、<tradeoff point>ODS のインプリメンテーションが複

雑になる</ tradeoff point>場合が多く、さらに <tradeoff point>CIF とバックエンド・オペレーショナ

ル・システムとの間で <essential pattern> 情報を同期化 ― 情報同期化 (Information

Synchronization)</essential pattern></essential pattern>する必要がある ― 残存する IT リスクを明示

していない</ tradeoff point>からです。現在、既製のミドルウェア製品の中には、このアプリケーショ

ンパターンに必要なエンドツーエンド(end-to-end)機能を提供するものがあることに注意してくださ

い。


<situation>ある通信会社が市内電話サービス、長距離電話サービス、ワイヤレス・サービス、および

インターネット・アクセスを提供しています。この会社は、この優れたサービスのポートフォリオを

主に合併買収により構築しました。その結果、この会社では製品固有 ― 通信サービス・商品特化

(Product-specific)のバックエンドアプリケーションを多数継承しました。</situation>

<business strategy>常に変化を続ける技術環境をフォロー</business strategy>し、さらに<business

goal>ワイヤレス・インターネット・アクセス、IP 電話、およびケーブル利用のブロードバンド・イン

ターネット・アクセスなどの新しい分野でも市場占有率を迅速に獲得する</business goal>ため、会社

は<business strategy>パートナーの買収と合併を積極的に継続する計画</business strategy>です。これ

らの傾向は、<change case>製品固有 ― 通信サービス・商品特化(Product-specific)のシステムが今

後ますます求められること</change case>を意味します。

積極的な成長戦略が総合的に成功するには、<business strategy>すべての顧客に異なるサービスを効果

的に関連商品販売 ― クロスセリング (Cross-Selling)</business strategy>する能力が必要です。

64

<business strategy>顧客がコールセンターに請求書支払いのために連絡をしたときには、CSR が他の

サービスへの加入を効果的に勧誘する必要があります。そうした勧誘をするには、顧客の現行加入状

態だけではなく、顧客の個人情報(the demographics of the customer) ― 顧客層(customer demographics)

の情報が必要になります。同様に、顧客がインターネット・アカウントにログオンした場合も、<essential

pattern>ウェルカム・ページをパーソナライズ ― パーソナライズページ(personalized page)</essential

pattern>して、その顧客の関心事を反映することが必要です。</business strategy>

目標達成のため、そして<IT strategy>複数の製品固有 ― 通信サービス・商品特化(Product-specific)

バックエンドアプリケーションを継続使用する</IT strategy>ためにも、この会社は<application

pattern>「エージェント」</application pattern>アプリケーションパターンを選択しました。 CIF

<essential pattern>オペレーショナル・データ・ストア</essential pattern>を構築する場合は、<business

strategy>顧客中心の総合表示― マスカスタマイゼーション(Mass Customization) </business strategy>

を提供できます。<essential pattern>エージェント層</essential pattern>がこのデータを使用して、優れ

た<business strategy>パーソナライゼーション</business strategy>と<business strategy>関連商品販売

― クロスセリング(Cross-Selling)</business strategy>の目的を達成できます。

65

参考文献

[Alur2005] D. Alur et al: J2EE パターン, 第 2 版, 日経 BP 社, 2005.

[Avgeriou2005] Paris Avgeriou and Uwe Zdun: “Architectural Patterns Revisited - A Pattern Language”, 10th

European Conference on Pattern Languages of Programs (EuroPlop2005), 2005.

http://hydra.infosys.tuwien.ac.at/Staff/zdun/publications/ArchPatterns.pdf

[Bass2000] Len Bass et al.: Quality Attribute Design Primitives, Technical Note, CMU/SEI-2000-TN-017

(2000).

[BMM2007] The Business Motivation Model, The Business Rules Group, 2007.

[Buschmann2000] F. ブッシュマン他: ソフトウェアアーキテクチャ－ソフトウェア開発のためのパ

ターン体系, 近代科学社, 2000.

[Firesmith2006] Donald Firesmith: “QUASAR: A Method for the Quality Assessment of Software-Intensive

System Architectures”, HANDBOOK, CMU/SEI-2006-HB-001 (2006).

[IBM2000][4] IBM: Patterns for e-business,

新版(英語版)

https://www.ibm.com/developerworks/patterns/

日本語翻訳版(2003 年 12 月 7 日)

https://www.ibm.com/developerworks/patterns/library/index.html#translations

現時点では、新の記事をご自分の言語でご利用になれない場合もあります。年表のページは、更

新内容を示しています。これを現在の timeline (英語版)ページと比較してください。

http://www.ibm.com/developerworks/patterns/timeline.html

Jonathan Adams 他： Web システムのデザインパターン―すぐに使える e‐business アプリケーション

構築の定石集，翔泳社，2003.

[IEEE1220-2005] IEEE Standard for Application and Management of the Systems Engineering Process,

IEEE-CS, 2005.

[IEEE1362-1998] IEEE Guide for Information Technology – System Definition - Concept of Operations

(ConOps) , IEEE, 1998..

[IEEE1471-2000] IEEE Recommended Practice for Architectural Description of Software-Intensive Systems,

IEEE, 2000.

[IPA2007a] IPA SEC 編: 要求工学・設計開発技術研究部会非機能要求とアーキテクチャ WG 2006 年

度報告書, 2007.

http://sec.ipa.go.jp/reports/20070905.html

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

ーキテクチャ・メタモデルセマンティクス解説 Ver1.0, 2007.

http://www.ipa.go.jp/jinzai/itss/activity/ITA/2006/ITA_MMS_guide2006.pdf

66

https://www.ibm.com/developerworks/patterns/

https://www.ibm.com/developerworks/patterns/library/index.html#translations

http://www.ibm.com/developerworks/patterns/timeline.html

[IPA2008] IPA SEC 編: 非機能要求記述ガイド, 2008. http://sec.ipa.go.jp/reports/20080717.html

[ISO/IEC-42010:2007] ISO/IEC 42010:2007 Systems and software engineering -- Recommended practice for

architectural description of software-intensive systems, 2007.

[Kazman2000] Rick Kazman et al.: Architecture Tradeoff Analysis Method, Technical Report CMU,

CMU/SEI-2000-TN-004. http://www.sei.cmu.edu/architecture/tools/atam/

[SARA2002] SARA WG: Software Architecture Review and Assessment(SARA) Report, Version 1.0, 2002.

[SEIa] CMU/SEI: Attribute-Driven Design Method, Software Architecture,

http://www.sei.cmu.edu/architecture/tools/add/index.cfm .

[SEIb]CMU/SEI: Architecture Tradeoff Analysis Method (ATAM),

http://www.sei.cmu.edu/architecture/tools/atam/ .

[TOGAF2009] The Open Group: TOGAF Version 9: The Open Group Architecture Framework (TOGAF),

2009.

[Zdun2005] Uwe Zdun at al.: Modeling Architectural Patterns Using Architectural Primitives, OOPSLA ’05

Proceedings of the 20th annual ACM SIGPLAN conference on Object-oriented programming, systems,

languages, and applications (2005).

[Zou2006] Joe Zou and Christopher J. Pavlovski: ”Modeling Architectural Non Functional Requirements:

From Use Case to Control Case ” , IEEE International Conference on e-Business Engineering

(ICEBE2006.). http://www.ipa.go.jp/jinzai/itss/activity/architect_com.html

[鷲崎 2007] 鷲崎弘宜, 丸山勝久, 山本理枝子, 久保淳人著, 深澤良彰監修, “ソフトウェアパターン

- パターン指向の実践ソフトウェア開発”, 近代科学社, 2007.

67

68

執筆者一覧（2010 年度非機能要求とアーキテクチャ分析 WG、一部を除き 50 音順）

リーダ：榊原彰日本アイ・ビー・エム株式会社

サブリーダ：羽生田栄一株式会社豆蔵

井上道夫株式会社インテック

大嶽隆児日本アイ・ビー・エム株式会社

鈴木三紀夫 TIS 株式会社

関根智東芝ソリューション株式会社

早川祐志日本電気株式会社

林惠美子富士通株式会社

山本久好日本アイ・ビー・エム株式会社

鷲崎弘宜早稲田大学

藤瀬哲朗情報処理推進機構ソフトウェア･エンジニアリング・センター

略語索引

Ａ

ASR(Architecturally Significant Requirement)

アーキテクチャ上重要な要求 ................................................................................................................. 4

ATAM (Architecture Tradeoff Analysis Method).................................................................................. 9

Ｃ

ConOps (Concept of Operations) ........................................................................................................... 9

CPS (Cyber-Physical Systems)

サイバー・フィジカル・システム ................................................................................................................ 1

Ｎ

NFR (Non-functional Requirement)

非機能要求 ........................................................................................................................................... 1

Ｑ

QUASAR (A Method for the QUality Assessment of Software-Intensive System ARchitectures) ... 4

Ｒ

RA (Reference Architecture)

参照アーキテクチャ ............................................................................................................................... 1

Ｓ

SARA(Software Architecture Review and Assessment Report) .......................................................... 4


非機能要求とアーキテクチャ分析 wg - ipa ·...

Documents