連載 アプリケーション・アーキテクチャ・ガイド2.0解説 第1回 Application Architecture Guideの概要 日本ユニシス　猪股 健太郎 2009/03/10
Page1 Page2

■AAfNとAAG

　「パターンとプラクティス」で公開されているアーキテクチャ・ガイドラインとしては、すでに「.NET のアプリケーション アーキテクチャ」（以下、AAfN）が存在している。

　AAfNは2002年に公開されたドキュメントであり、その内容を要約した記事「アプリケーション・アーキテクチャ設計入門」も＠ITで公開されている。AAfNとAAGの関係はどのようになっているのだろうか。

　実際のところ、AAGはAAfNの後継である（そのため、AAGには「2.0」というバージョン番号も付与されている）。AAfNを踏まえつつ新しくAAGが書かれた背景は、AAG執筆チームの一員であるDavid Hillが自身のブログに投稿したエントリに書かれている。それによると、AAG執筆の動機は、最新のプラットフォームへの対応と、利用者の要望への対応という2つの理由があったようだ。

• AAfNは実装技術の詳細に依存しない原則や概念も多く含んでいるため、現在でもなお価値のある情報源ではある。しかし、やはり古びてきた部分もある。AAfNが公開されたのは2002年であり（日本語訳は2004年）、想定されていた.NET Frameworkのバージョンは1.0および1.1であった。2009年現在は.NET Framework 3.5 SP1が最新であり、年末には.NET Framework 4.0のリリースが予定されている。.NETアプリケーションの開発を支援するという目的を考えれば、前提とする技術、製品、ソリューション、ベスト・プラクティスは早急に更新する必要があった。

• AAfNの公開に当たっては、最初の包括的なアーキテクチャ・ドキュメントであったこともあり、多くの人が手軽に利用できるように、ページ数を200ページ以下に抑える配慮がなされていた。ページ数が抑えられていた半面、記述は抽象度がやや高くなっていた。AAfNの読者たちからのフィードバックとして、「適切なアーキテクチャを選択する指針が欲しい」「アーキテクチャを実装するために適切な技術を選択する指針が欲しい」という要望が挙がっていた。要望に対応するには記述範囲を拡大する必要があった。

　これらの2点を踏まえて、新しくAAGが記述された。AAfNの記述範囲とAAGの記述範囲を大まかに図解してみると、次のようになる。

AAfNの記述範囲とAAGの記述範囲の比較

　では、「AAGではどの記述がどのように改訂／追記されたのか」について、順に説明していこう。

• 論理構造が改定された：AAfNで定義する論理階層は、「プレゼンテーション層」「ビジネス層」「データ・アクセス層」の3階層であった。AAGではこれを少し変更し、「サービス層」を4つ目の階層として独立させている。

• シナリオが拡充された：AAfNではサンプル・シナリオとして、Webアプリケーション、Windowsフォーム・アプリケーション、外部サービスの3者が連携するという小売業者のシステムを想定していた。AAGでは1つのシナリオでアーキテクチャ全体をカバーしようとせず、要件の異なるシナリオを多数用意し、それぞれに適したアーキテクチャを提示している。

• アプリケーション種別が拡充された：AAGでは「RIA（リッチ・インターネット・アプリケーション）」「モバイル・アプリケーション」「OBA（Officeビジネス・アプリケーション）」「SharePoint業務アプリケーション」に関する記述が追加されている。

• 設計上の選択肢が拡充された：実際の開発プロジェクトごとに要件や制約が異なるため、それぞれで設計上の判断をしなければいけないポイントを多数抽出し、具体的な考察を加えている。

• アーキテクチャ・スタイルが追加された：複数のアーキテクチャに共通する性質や設計原則を、アーキテクチャ・スタイルという形にまとめて提示している。

• アーキテクチャ設計プロセスが追加された：AAfNでは、どのようにアーキテクチャ設計を進めるかについての指針は存在しなかった。AAGでは、反復的にアーキテクチャ設計を深めていく手法とその手順について概要を説明している。

　このようにAAGはAAfNを大幅に拡充する内容となっている。実際にページ数も増加しており、PDFドキュメントで見ると、AAfNは166ページだが、AAGは381ページと2倍以上のボリュームである。

■アーキテクチャ全体を規定するメタな枠組み

　AAGでは、アプリケーションのアーキテクチャを規定するメタな枠組みとして、以下のような図を用いている。

アプリケーション・アーキテクチャを規定するメタな枠組み

　このAAGの「メタな枠組み」では、アプリケーションのアーキテクチャは次の3つの部分から構成されるとしている。

• アプリケーション種別（図中央上）
• アーキテクチャ・スタイル（図右上）
• アーキテクチャ・フレーム（図右下）

　それぞれについて説明しよう。

●アプリケーション種別

　アプリケーションを、その物理配置のパターンから分類したもの。AAGでは、マイクロソフト・テクノロジを使ったアプリケーションの「原型（アーキタイプ）」として、以下の7種類を取り上げている。

1. Webアプリケーション
2. RIA
3. Windowsフォーム・アプリケーション
4. Webサービス
5. モバイル・アプリケーション
6. OBA
7. SharePoint業務アプリケーション

●アーキテクチャ・スタイル

　複数のアーキテクチャに共通して見られる設計原則の集合のこと。書籍『ソフトウェアアーキテクチャ』（近代科学社、ISBN:978-4764902831）における「アーキテクチャ・パターン」と同義。

　いくつかのアーキテクチャ・スタイルは重なり合う場合もあるし、組み合わせて取り入れられる場合もある。AAGでは、以下の8種類のアーキテクチャ・スタイルを取り上げている。

1. クライアント／サーバ型
2. コンポーネント指向
3. 論理的多階層
4. メッセージ・バス
5. MVC（モデル／ビュー／コントローラ）
6. 物理的多階層
7. オブジェクト指向
8. サービス指向

●アーキテクチャ・フレーム

　アプリケーション・アーキテクチャの細部を決定付ける要素。個々のアーキテクチャ要素は、実際の開発プロジェクトごとに設計上の判断が要求される“ホットスポット（可変場所）”となる。

　AAGでは、アーキテクチャ・フレームに含まれるアーキテクチャ要素の代表として、認証と承認、キャッシュ、通信、コンポジション、同時実行とトランザクション、構成管理、結合度と凝集度、データ・アクセス、例外管理、論理階層、ログ出力と監視、状態管理、内部構造、ユーザー体験、入力値検証、ワークフローを最初に取り上げ、それぞれについて設計方針を提示している。これ以外のアーキテクチャ要素は、AAGの後半で適宜取り上げられている。

　以上の3つの構成要素は互いに関連している。アプリケーション種別が変われば、それに応じて適用されるアーキテクチャ・スタイルも変わり、アーキテクチャ・フレームにおいて取り得る選択肢の範囲も変わる。

　そして、これら全体を規定する入力となるのが、次の3つである。

• シナリオ
• 品質属性
• 要件と制約

　それぞれについて説明しよう。

●シナリオ

　シナリオは、アプリケーションの要件を象徴し、アプリケーションの設計に大きな影響を与えるような現実世界のシナリオである。

　AAGでは、アプリケーションが実現すべきゴールを、ユーザーの観点、ビジネスの観点、システムの観点に分類し、それぞれをカバーするようなシナリオを抽出することを推奨している。そのように抽出したシナリオこそが、アプリケーションを設計するうえで鍵となる。

●品質属性

　品質属性は、アプリケーションの非機能要件のうち、アプリケーションの品質を規定するものとしてとらえられるものを指す。

　品質属性自体は、どのようなアプリケーション種別やアーキテクチャ・スタイルを採用する場合でも検討しなければならない横断的な関心事である。しかし、品質属性が変われば、アーキテクチャ・スタイルやアーキテクチャ・フレームの選択肢が変わる。

　品質属性の例としては、セキュリティ、パフォーマンス、運用性などが挙げられる。ISO標準（国内ではJIS規格）で定義される「ソフトウェア品質特性」と同じである。

●要件と制約

　アーキテクチャ設計の選択肢を限定するような要件や制約。要件は機能要件の場合もあれば非機能要件の場合もある。制約とは技術的な制約の場合もあれば、スケジュールやコストや要員といったプロジェクト管理上の制約もある。

■

　さて、今回はAAGの概要について説明した。次回以降は、AAG本文に書かれている内容について順に解説していく。

INDEX
	連載：アプリケーション・アーキテクチャ・ガイド2.0解説
	第1回 Application Architecture Guideの概要
	1．『Application Architecture Guide 2.0』とは何か？
	2．Application Architecture Guide 2.0の全体像

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

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