アプリケーション・アーキテクチャにおけるアジャイルの実践

Microsoft社はパターンや実践方法を元にしたHow-To Design Using Agile Architecture(リンク)(アジャイルなアーキテクチャを使った設計方法)というガイドを発表した。これにはアジャイルにアプリケーションを構築する際に従うべき詳細なガイドラインが示されている。
 

ガイドでは以下の入力情報を元に作業を開始することを推奨している。

• ユース・ケースとユーザ・シナリオ
• 機能要求
• 非機能要求(パフォーマンス、セキュリティ、信頼性といった品質特性)
• 技術的要求
• ターゲットとなる運用環境
• 制約条件

そして、以下を成果物とする。

• アーキテクチャ上重要なユース・ケース
• アーキテクチャ上困難な部分
• アーキテクチャ候補
• アーキテクチャの要の部分

このガイドではアーキテクチャを一つのステップで構築するのではなく、反復的な五つのステップで構築するという方法でアジャイルさを導入することを推奨している。

• ステップ1．アーキテクチャの目標を明確にする。 目標を明確にすることでアーキテクチャがはっきりしてきて、設計における本当の問題を解決することに集中できるようになる。良い目標は、(このフェーズの)完了と次のフェーズへの移行の判断を助けます。
• ステップ2．重要なシナリオ。 重要なシナリオを使って設計が主にどのような問題に注力すればいいのかを判断し、候補となるアーキテクチャが決まった際にはその評価をする。
• ステップ3．アプリケーションを概観する。 どのような種類のアプリケーションなのか、運用環境のアーキテクチャがどうなっているのか、アーキテクチャのスタイル、そしてアプリケーションが扱う実世界と設計とをつなぐための技術要素について理解すること。
• ステップ4．重要かつ困難な部分。 品質特性とアーキテクチャのフレームから重要かつ困難な部分を見極める。それはアプリケーションの設計において最もミスを犯しやすい領域である。
• ステップ5．解決策の候補。 アーキテクチャの候補かアーキテクチャ上の要の部分を作成し、重要なシナリオと重要かつ困難な部分、そして運用上の制約を使ってそれを評価する。

ステップ1．アーキテクチャの目標を明確にする

Microsoft社でPrincipal Program Manager on patterns & practices(パターンと実践に関する主幹プログラム・マネージャ)を務めるJ.D. Meier氏によると、このステップでは“全体の労力を知ることと同様に、これ以降のステップでどれだけの時間とエネルギーを費やせばいいのかを明確にすること”が目標であるとのことである(リンク)。ステップ1．の成果物は以下のようになる。

• プロトタイプの作成
• 重要な技術的リスクを明確化する
• 仮の方針をテストしてみる
• モデルと知識を共有する

ステップ2．重要なシナリオ

同じくJ.D. Meier氏によると最良のシナリオは以下の判断基準から導かれるユースケースである。

1. (プロジェクトの)成功と完成したアプリケーションの受け入れに欠かせない。
2. アーキテクチャを評価するのに十分なくらいに設計の訓練となること。
    

ステップ3．アプリケーションを概観する

実世界の詳細と具象性を設計に取り込むためにはアプリケーションを概観することが必要不可欠である。そして、それは以下のような手順で成し遂げられる。
 

• アプリケーションの種類を明らかにする。 まず、どのようなアプリケーションを構築しようとしているのかを明らかにする。モバイル・アプリケーションなのか、リッチ・クライアントなのか、リッチ・インターネット・アプリケーションなのか、Webアプリケーションなのか、あるいはそれらの組み合わせなのか？
• 運用上の制約を理解する。 次に、ターゲットとなる運用環境について理解しそれがアーキテクチャに与える影響について確認する。
• 重要なアーキテクチャのスタイルを見分ける。 設計上どのようなアーキテクチャのスタイルを採用するつもりなのか明らかにする。。サービス指向アーキテクチャで構築するのか、クライアント/サーバ型か、レイヤ化するのか、メッセージ・バスを使うのかあるいはそれらの組み合わせなのか？
• 関連する技術を明らかにする。 最後に、選択したアプリケーションの種類とその他の制約に基づいて関連する技術を明確にし、アーキテクチャに影響を与えるのがどの技術要素なのかを明らかにする。
   

ガイドには上記の各段階に関するアドバイスが記載されている。例えばいくつかのアーキテクチャ・スタイルから選択をする際のオプションは以下のように示されている。

• クライアント/サーバ。 クライアントがサーバへリクエストを送信する形式にシステムを分離する。
• コンポーネント・ベース。アプリケーションを再利用可能で良く定義されたインタフェースを持つコンポーネントへと分解する。
• レイヤ化。同じような機能を持つ単位でグループ化してそれぞれ別のレイヤへと分離する。
• メッセージ・バス。 接続する全てのシステムが利用する既知の(メッセージ)形式を定義して実際の受信者ごとの違いを意識しなくてよいようにする。
• オブジェクト指向。責務をデータと振る舞いを持つ再利用可能なオブジェクトに分割するプログラミング・スタイル。
• サービス指向(SOA)。契約とメッセージを使って機能をサービスとして公開したり利用したりするアプリケーション。
   

ステップ4．重要かつ困難な部分

このステップでは以下のことをすべきであるとしている。"どのような部分でミスが起こりやすいのかを理解するためにアプリケーション・アーキテクチャ上の困難な部分を明確化します。重要かつ困難な部分は品質特性や横断的な関心事に関連する部分に存在することがあります。"
ガイドに示されている困難な部分の長いリストには以下のようなものが含まれている。可用性、相互運用性、保守性、信頼性、セキュリティなど。
 

ステップ5．解決策の候補

重要かつ困難な部分を明確化した後、アーキテクチャの最初のドラフト版が提供される。その後、ステップ2に戻ってアーキテクチャ候補を検証し、さらにステップ3から5と続けて新しい候補を生成する。このプロセスは反復的に繰り返され反復ごとに改良されていく。
 

原文はこちらです：http://www.infoq.com/news/2008/11/Agile-Architecture