連載：アプリケーション・アーキテクチャ・ガイド2.0解説 第2回 アプリケーション概要を定義するには？ ―― 設計プロセスから見るアプリケーション・アーキテクチャ（前編） ―― 日本ユニシス　猪股 健太郎 2009/06/02

Page1 Page2 Page3

■アーキテクチャ設計とは

　ソフトウェアにおいてアーキテクチャとは、「設計思想」と表現されたり「システムの構造」と表現されたりもする、極めて抽象的な概念である。

　この言葉の意味については、『Application Architecture Guide 2.0』（以下、AAG）の前版である「.NETのアプリケーション・アーキテクチャ」（以下AAfN）では触れられていなかった。AAGでは、アーキテクチャの定義について、複数の書籍（『The Rational Unified Process』『Patterns of Enterprise Application Architecture』『Software Architecture in Practice』）から引用して示している。

　AAGで引用されている定義はそれぞれ表現が異なっているので、本稿ではそれらを全部紹介することはしない。その代わりに、IEEE 1471標準の定義を示しておく。それは、「アーキテクチャはシステムの基本構造であり、コンポーネント（構成要素）や、コンポーネント同士の関係性や、コンポーネントと環境との関係性や、システムの設計と進化を導く原則として具体化される」というものである。

　すなわち、アーキテクチャ設計はシステム設計に含まれていて、厳密に区別することはできない。ただ多くの場合、アーキテクチャとはシステム開発の利害関係者（ステークホルダー）全体にまたがる共通理解を指す。この観点から見ると、個々の構成要素がどのようなアルゴリズムやデータ構造からできているかといった詳細部分の設計はアーキテクチャに含めなくてよい。そのような細部が利害関係者全体にとって問題になることは少ないからだ。

　システム開発の利害関係者は、それぞれが異なった要望や関心事を持っているものである。それらを大まかに分類すると、利用者の領域、ビジネスの領域、そしてシステムの領域となる。それぞれはトレードオフの関係にあることも多いため、アーキテクチャはこれら3つの領域のバランスを取ったものになっていなければならない。

システム開発の利害関係者が持つ要望や関心事の領域

■アーキテクチャ設計の5つのステップ

　近年のシステム開発においては、システム設計は徐々に進化していくものであり、実装やテストによって検証することなしに、すべてを設計し尽くすことはほとんど不可能だと考えられている。

　AAGにおいてもアーキテクチャの進化的設計を推奨している。すなわち、インクリメンタル（増加型）かつイテレーティブ（反復型）にアーキテクチャを具体化していくのである。そのようなアーキテクチャ設計のプロセスを表現したのが下の図である。

インクリメンタルかつイテレーティブなアーキテクチャ設計の5つのプロセス

　この図から分かるように、アーキテクチャ設計には次の5つのプロセスがある。

（1）アーキテクチャの目的決定
（2）重要シナリオの選択
（3）アプリケーション概要定義
（4）ホットスポット（＝可変場所）の抽出
（5）解候補の選定

　アーキテクチャ設計のプロセスにおけるインプットは以下のものである。

• ユースケースとシナリオ
• 機能要件
• 非機能要件（性能、セキュリティ、信頼性など）
• 採用技術に関する要件
• 運用環境
• 各種制約

　一方、アーキテクチャ設計のプロセスにおけるアウトプットは以下のものである。

• アーキテクチャに大きく影響するユースケース
• アーキテクチャのホットスポット
• アーキテクチャ候補

　では、5つのプロセスの中身を順に見ていこう。

●1 アーキテクチャ設計における目的と目標の決定

　最初に行うべきことは目的の明確化である。今回のアーキテクチャ設計は何のために行うのか？ 目的がはっきりしていれば作業の優先順位が明確になる。反対に、目的があいまいなままだと優先順位が決められないため、時間を無駄にしてしまう恐れがある。

　目的は、例えば以下のようなものだ。

• 主要な技術リスクを洗い出す
• 網羅率100％のテストをする
• システムの認識合わせをする
• セキュリティ・レビューを実施する

　目的が定まったら、それに合わせてアーキテクチャの設計目標を定める。これにより設計の範囲が決定する。

　目標は、例えば以下のようなものだ。

• ある業務についてWebユーザー・インターフェイスのプロトタイプを作成する
• 位置情報を表示する3種類の手法を実証する
• 注文状況を追跡する機能を実装する
• 認証・承認部分のアーキテクチャを設計する

　目的と目標がはっきりすれば成果物の形も明らかになる。そうすれば、そのために必要な時間や人員を見積もれるだろう。

●2 主要シナリオの選択

　ここでいうシナリオとは、システムが何らかの処理をする際の「5W1H」、すなわち、「いつ、どこで、誰が、なぜ、何を、どれだけ」を明確にしたものである。

　入力に含まれているユースケースやシナリオから主要なものを選び出したり、要件や制約などから新たに具体的なシナリオを書き起こしたりする。そのようにして選択したシナリオは、設計プロセスの出力となるアーキテクチャ候補をテストする際にも利用する。

　選択の際には、何が「主要」なのかが問題になる。例えば以下のようなことを基準にするとよい。

• アーキテクチャに大きな影響を与えるユースケースに含まれる
  頻繁に利用される機能、技術リスクの高い機能、複数の論理階層や物理階層をまたがる処理などは、アーキテクチャに大きな影響を与える。

• 機能要件と非機能要件の両方に関係している
  システムの認証方針は、ユーザーのログイン機能にも、システムのセキュリティにも、両方に関係している。

• 複数の非機能要件のトレードオフに関係している
  可用性を高くするとレスポンス・タイムが悪化する状況など。

　上のような基準で主要シナリオを選ぶのだが、シナリオの数や種類は必要十分でないといけない。重大なシナリオを見落とすと、後で設計を大きく変更しなければならない恐れがあるからだ。そのようなリスクを最小にするために、利用者の視点、ビジネスの視点、システムの視点からシナリオを検証するとよい。

●3 アプリケーション概要の定義

　次にアプリケーションの概要を定義する。ここでは論理的・物理的な構造を大まかに規定すればよい。アプリケーションの概要を決めることで、現実的な制約に照らし合わせて設計判断を進められるようになる。

　概要定義は以下のとおりに進める。詳細は後で説明する。

• 主要シナリオで想定している利用形態から、アプリケーション種別を決定する
• アプリケーションを配置する際の要件や制約を洗い出し、それらがアーキテクチャに与える影響を検討する
• 採用するアーキテクチャ・スタイルを選ぶ
• 要素技術の候補を洗い出し、アプリケーション種別などから来る制約を考慮して採用する技術を決める

　ここで決定したアプリケーション概要をベースラインとして、詳細なアーキテクチャを検討していくことになる。

●4 ホットスポット（＝可変場所）の抽出

　次に、アプリケーション概要では詰められていない、アーキテクチャの詳細を設計していく。

　AAGでは、要件と制約に応じて変わる部分を、アーキテクチャの「ホットスポット（可変場所）」と呼んでいる。その中でも、横断的な関心事に関係するホットスポットを「主要なホットスポット」と位置付けている。横断的関心事に関する設計判断は、アプリケーション全体に大きな影響を与えることになるが、にもかかわらず、しばしば設計ミスが起きているものだからである。

　詳細は後で述べるが、主要なホットスポットを抽出する手掛かりとして、AAGでは「アーキテクチャ・フレーム」と「品質属性」を説明している。

●5 成果物候補の作成

　主要なホットスポットを抽出できれば、それぞれに対して設計方針を定める。それが終わったときのアウトプットは、アーキテクチャ設計の成果物候補となる。

　成果物候補が出来上がったら、主要なシナリオに基づいたレビューやテストを実施し、技術的なリスクを小さくする。その際の推奨事項として、以下のことが挙げられている。

• ドキュメントの体裁にはこだわらない。この時点ではまだアーキテクチャが細部まで固まったわけではなく、変更される可能性が高い。よって、レビューを目的としたドキュメントであれば、最終的な成果物の体裁を取っている必要はない

• アーキテクチャ・スパイクを使う。設計したアーキテクチャが本当に要件や制約を満たしているかが、机上の設計だけでは判断できず、実装やテストを通じた検証が必要な場合もある。そのような場合は、アプリケーション全体ではなく、アプリケーションの一部をプロトタイプとして実装すれば足りる場合も多い。そのようにアーキテクチャの検証を目的として実装したプロトタイプを「アーキテクチャ・スパイク」と呼ぶ。アーキテクチャ・スパイクはアプリケーションそのものを完成させることが目的ではない。従って、アーキテクチャの検証が済み、得られた知見をアーキテクチャ設計に反映させた後は、作成したスパイクは破棄してよい

　レビューやテストが完了し、結果をアーキテクチャ設計に反映させたら、またプロセス2に戻り、まだ検討していないシナリオの中から重要なものを選ぶ。こうしてアーキテクチャ設計をどんどんブラッシュアップさせ、完成度を高めていく。

　このようにしてアーキテクチャ設計が完了した後は、システム開発の利害関係者に対してアーキテクチャを説明し、共通理解を得なければならない。もし詳細なドキュメントが必要になる場合は、ここで作成するのがよいだろう。

　以上が、AAGが推奨するアーキテクチャ設計の5つのステップである。以降では、このうち「2. アプリケーション概要の定義」についてより詳しく説明する。また次回では「3. ホットスポットの抽出」について説明する。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第2回 アプリケーション概要を定義するには？
	1．アーキテクチャ設計とは
	2．アプリケーション種別を決定する／配置シナリオを検討する
	3．アーキテクチャ・スタイルを選ぶ／採用する技術を決める

「アプリケーション・アーキテクチャ・ガイド2.0解説」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）