Coursera Software Architecture Week3 Analyzing and Evaluating an Architecture

システムアーキテクチャのデザインが、すべてのステークホルダーの関心を考慮したものかどうかをどう判断すればいいのか？デザインの標準ルール・ガイドラインに従うことで、アーキテクチャが基準を満たしたものになることを期待できる。このレッスンでは、個々の品質特性をどのように評価するのかと、デザイン全体をどのように評価するのかを学ぶ。

品質特性は、機能要件や非機能要件の測定に使用される。しかし、測定とはどのように行えばよいのか？それには品質特性シナリオを使用する。シナリオには『一般』と『特定』の二つがあり、『一般シナリオ』はシステム全般を測定するのに使用する。『特定シナリオ』は特定のシステムを測定するのに使用する。すべてのシナリオは、以下の要素で構成される。 - 誘発源（外部/内部の誘発のもと。タイマーだったりエンドユーザーだったり） - 誘発（システムの応答を促す原因） - 環境（システムが誘発を受けたときの状態） - アーティファクト（誘発によって影響を受ける部分のシステム） - レスポンス（誘発をうけてシステムがどのように振る舞うのかの結果） - レスポンスの測定（品質特性の測定のため、レスポンスの内容を計測する基準）

シナリオでは、正常な場合のシナリオに加えて、不正な入力があった場合、ロードアベレージが高い場合なども含める必要がある。品質特性で可用性を挙げている場合なら、システムが使えなくなる場合のシナリオを作成し、回復にどれくらい時間がかかるのかを測定しないといけない。

一般シナリオでは、 - 誘発源:エンドユーザー、内部のサブシステム、外部システム - 誘発:不正なユーザー入力、内部エラー、認識されていないシステムからのリクエスト、巨大なリクエスト、高負荷 - 環境:通常、スタートアップ中、シャットダウン中、高負荷、エラーからの回復中、リクエストへ返答中 - アーティファクト:サーバー、プロセス - レスポンス:例外をログする、ユーザー通知、外部システムにエラーを返す、システムがスタートアップ中/シャットダウン中と通知する - レスポンスの測定:リスタートにかかる時間、回復までの時間、レスポンス完了までの時間などのように場合を用意し、それぞれについてシナリオを作成する。

特定シナリオでは、ある特定の場合についてシナリオを作成する。例えば、可用性について、 - 誘発源:顧客 - 誘発:コンサートチケット購入リクエスト - 環境:プロセス数が最大数に到達 - アーティファクト: Webサーバー - レスポンス:顧客にサービスがビジーと返答 - レスポンスの測定:現在のリクエストを完了させるまでの時間のようにして特定の場合について評価する。

このシナリオを、品質特性の評価について使うやり方として、ATAM（Architecture Tradeoff Analysis Method）というものがある（カーネギーメロン大学によって開発された）。これは、評価者はアーキテクチャー自体や問題のスコープに詳しくなくても利用できるメソッドである。

ATAMは、参加者を３つのグループに分ける。一つは評価グループ。評価グループは３つのサブグループに分かれ、それぞれデザイナー、ピア、外部の人間となる。評価グループの一番大事な特徴は、バイアスがかかっていないということである。デザイナーはアーキテクチャーデザインに関わる。仮説を立て、要求を分析し、デザインを作成し、レビューすることを反復的に行う。ピアはデザインプロセスにはかかわらないが、デザインに必要な別角度からの観点を提供する。外部の人間は、プロジェクトやチームとはかかわらず、バイアスがまったくないことが必要である。しかしアーキテクチャの分析には経験を持ち、バイアスのない視点からの分析を可能とする。

二つ目のグループは、プロジェクトの決定者である。このグループには、プロジェクトマネージャー、顧客、プロジェクトオーナー、ソフトウェアアーキテクト、テクニカルリードが含まれる。このグループはプロジェクトの行う決定について権限と責任をもつ。

３つ目のグループは、アーキテクチャステークホルダーである。このグループには、アーキテクチャにビジネス上のニーズを表現することを求める誰でもが含まれる。しかしその誰でもは、評価プロセス自体には含まれないこともある。エンドユーザー、開発者、サポートスタッフはこのグループに属する。

ATAMによる評価のプロセスは、ざっくりと以下のようになる。

ビジネスメンバーが必要性からシステム開発プロジェクトを立ち上げる。
ビジネスメンバーは連帯してビジネス上の問題を解決するためのシステムアーキテクチャを作成する。
ビジネスメンバーとシステムアーキテクチャは品質特性とデザインを作成する。
品質特性とデザインから、品質特性シナリオを作成する。
シナリオは分析結果から、トレードオフ・重要な点・非リスク・リスクの４つに分けられる。
リスクシナリオはビジネスによくない影響を与えるため、リスクシナリオをカテゴライズしてリスクテーマに分類する。

ATAMの詳細なプロセスは、以下の9段階に分けられる。 1. ATAMについてプレゼンする。 2. ビジネスメンバーがビジネス上の問題とシステムのゴール、それにシステムの機能、要求、プロジェクトの制約、スコープをプレゼンする。 3. 現在のアーキテクチャと将来のアーキテクチャについてプレゼンする。アーキテクチャはプロジェクトの制約の影響を受ける。 4. アーキテクチャの方針を確認する。ドキュメントや3でのプレゼンを評価し、システムについてより詳しい情報を得る。 5. 品質特性木をつくる。個々の品質特性についての要求は、品質特性木であらわされる。システム内部の情報と、ビジネスメンバーから得られる品質の優先順位によってこの木を更新できる。 6. アーキテクチャのアプローチを分析する。品質特性木のASRによって、システムがどのように要求を満たすようになっているのか評価する。 7: それぞれのグループがグループにとって大事な点についてシナリオを作成し、優先順位をつける。それぞれのグループのシナリオで、似ているものはマージする。 - 重要な点: ASRに影響する（例：高トラフィックはシステム応答の遅れの要因になる） - トレードオフ:一つの品質特性を満たそうとすると他の特性が犠牲になる（例：システムの高負荷対策に同時接続人数を制限できるが、それは可用性を低めることになる。どちらを選ぶかはビジネス的な決定になる） 8: 優先順位五〜十位までのシナリオを使い、再度品質特性木を作成する。 9 結果を評価し、ドキュメント化する。