SAAM vs. ATAM
ソフトウェア・アーキテクチャ評価の2つの手法、SAAMとATAMについて久々に調べてみた。手法自体に特に変化／進化はないようだ。今はアーキテクチャ評価というものから興味が薄れているのかしれない。
Software Architecture Analysis Method（SAAM）
SAAMはステークホルダーがどのようにシステムを利用するかというシナリオをベースにして分析する。ステークホルダーは、システムの利用者だけでなく、開発者、システム管理者、保守者などを含んでいる。シナリオには優先度をつけ、アーキテクチャへマッピングする。アーキテクチャがそれらのシナリオをうまく網羅できているかを診断するのだ。SAAMには7つのステップがある。
1. ステークホルダーを識別する 2. シナリオを作成し、優先度をつける 3. アーキテクチャ候補を記述する 4. シナリオを直接／間接で分類する 5. シナリオを評価する 6. シナリオの相互作用を明らかにする 7. 全体評価を行う
ステークホルダーは利用者だけではないので、開発者や管理者の視点でも拡張のシナリオ、変更のシナリオなども挙げて優先度を付けておく必要がある。これらのシナリオはATAMでも共通利用できる。優先度は、シナリオとしての現実性(そのシナリオが適用される局面がどの程度あるのか)と重要性を観点に例えば、高／中／低の3段階で付与する。
直接シナリオとは、通常のシステム利用のシナリオであり、システムに変更を加えることなく実施できるシナリオだ。間接シナリオは、システムに変更を加えなければ実施できないシナリオ。シナリオによって追加・削除・変更が必要なコンポーネントを識別し、変更の効果と困難さを予測する。影響度も例えば、高／中／低の3段階で見積もっておく。
多くのシナリオから影響を受けるコンポーネントは再設計が必要といえる。わずかなコンポーネントにしか影響を与えないシナリオは、コンポーネントの高い凝集度(cohesion)と低い結合度(coupling)を示唆することになる。（ただし、シナリオがありふれていて考察には適さないという場合もありえるので注意のこと。）
Architectural Tradeoff Analysis Method (ATAM)
ATAMはソフトウェアの品質属性に着目する。信頼性・変更容易性・保守性などである。これら品質属性は相互の依存関係を解析して、優先度を付ける。例えば、セキュリティはパフォーマンスに影響するとか、コストと期間の両方に影響するとかだ。アーキテクチャがそれら重要な品質属性をうまく網羅できているかを診断するのだ。ATAMには10のステップがある。
1. ATAMを示す 2. ビジネス・ドライバを示す 3. アーキテクチャを示す 4. アーキテクチャスタイルを識別する 5. 品質属性のユーティリティツリーを作成する 6. アーキテクチャスタイルを引き出し、分析する 7. シナリオのネタを作成する 8. シナリオをブレインストーミングし、優先度を付ける 9. スタイルにシナリオをマッピングする 10. 要約を示し、レポートを書く
ATAMの手順については、IPAの参照アーキテクチャ調査報告「ITA2005_RA.pdf、ITA2006_RA.pdf」などに詳細が見られるので割愛しておく。
