ソフトウェアの設計プロセスは数多くある。
「アーキテクチャ中心設計（ACDM）」の「アーテクチャドライバ (Architectural Drivers) 」を用いた設計もその中のひとつ。
近年、システムは複雑化し要件を「正しく」捉えて「正しい」設計をすることが難しくなってきている。
しかし、すべてのアーキテクチャ設計者は
ステークホルダーを特定し、要件を正しく理解して捉えること
そして、
なぜ「正しい」かを示す手法（要求を発見し、洗練させ、問題として設定）を持つこと
が求められる。
アーキテクチャドライバの抽出と整理は、そのためのツールとなる。
書籍では「Software Architecture in Practice, Second Edition, by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003」の和訳である下記が分かりやすい。
アーキテクチャドライバに関する記事は長谷川倫也氏（元ソニー、現Snap Inc日本代表）の記事が有名だ。
共著で書籍も出している。
アーキテクチャ中心設計手法 (IT Architects’Archive ソフトウェア開発の実践)
今回のブログは、こちらの記事に対する補足（簡易な表現と図示化）という位置づけとして公開しておく。
アーキテクチャ決定要因 (Architectural Drivers)
一般的に「要件」は、次の4つに分類され、これらは「アーキテクチャドライバ (Architectural Drivers) 」と呼ばれている。
- 技術制約 (Technical Constraint)
- ビジネス制約 (Business Constraint)
- 機能要件 (Functional Requirement)
- 品質特性 (Quality Attribute)
機能要件とは「あり/なし」の二値で評価される要素。
そして、
品質特性とは「良し/悪し」の度合で評価される要素。
一番分析が難しく、かつ一番見落とされがちなのが
品質特性
アーキテクチャの良し悪しは品質特性で決まる
品質特性とは機能の他にシステムが保有するべき性質のこと。
つまり、アーキテクチャを大きく決定付けるのは品質特性であり、設計の初期段階から検討に組み込まれている必要がある。
ソフトウェアが実現するべき品質特性は次の6つに分けられる。
| 品質特性 | 意味 |
|---|---|
| Availability (可用性) | システムがどれぐらい安定して動作するか？ |
| Modifiability (変更容易性) | どれぐらい変更しやすく設計するか？ |
| Performance (性能・速度) | どれぐらい早く、安定して応答するか？ |
| Security (堅牢性) | 不正なアクセスをどれだけ排除できるか？ |
| Testability (テスト容易性) | どれぐらいテストしやすいシステムか？ |
| Usability (使いやすさ) | 操作が容易で、間違いが起こりにくいか？ |
【コラム】製品品質モデルの品質特定との違い
「品質特性」という言葉は、「ソフトウェア品質特性（品質を構成する要素／品質の評価観点）」の方がなじみ深い人も多い（※JIS X 25010：2013 (ISO/IEC 25010：2011)）。
| 品質特性 | 副特性 |
|---|---|
| 機能性(Functionality) | 合目的性，正確性，相互運用性，標準適合性，セキュリティ |
| 信頼性(Reliability) | 成熟性，障害許容性，回復性 |
| 使用性（Usability） | 理解性，習得性，運用性 |
| 効率性(Efficiency) | 時間効率性，資源効率性 |
| 保守性(Maintainability) | 解析性，変更性，安定性，試験性 |
| 移植性（Portability） | 環境適用性，設置性，規格適合性，置換性 |
この「製品品質モデルの品質特定」と「アーキテクチャドライバの品質特性」に違いは何だろうか？
これは、「製品品質モデルの品質特定」から「アーキテクチャを決定する要件」だけを抽出したもの「アーキテクチャドライバの品質特性」だとコンサルタントから聞いた。
要するに「ソフトウェア品質特性（品質を構成する要素／品質の評価観点）」の一部は既にアーキテクチャ決定時には考慮しておく必要がある。
「テストしにくい実装」が生まれるのは、これが原因の一つ。
アーキテクチャ設計と品質特性シナリオ
「システムは可能な限り早く起動しなくてはならない」
これは「Performance (性能・速度) 」に関する品質特性だが、アーキテクチャ設計的には何も情報を与えていない。
「品質特性」からアーキテクチャ課題を分析するには、次のように あいまいな品質特性を分解して分析することが重要。
| 分解方法 | 例 |
|---|---|
| Howを数値で表現してみる | 1秒で起動する |
| 重要と思われる特定の「機能」に絞る | 起動とは、メニューが表示されて操作開始できるまで |
| 使われる状況をもっと限定してみる | メモリカードやバッテリーなどのシステム構成を変えない状態で、電源オフからオンした時 |
ようするに「アーキテクチャ設計」では次のようなことを行う。
- ソフトウェアを構成する要素 を分解する
- 構成要素間の関係 を明示する
- 外部から見える特性 を明確にする
この時、「システムが備えるべき品質特性のシナリオ」は次の6つの要素（6-parts）で記述できる。
| 要素 | 説明 |
|---|---|
| 刺激の発生源（Source of Stimulus） | これは、刺激を生み出す実体（人間、コンピュータシステム、あるいは他の装置） |
| 刺激（Stimulus） | システムに達した場合に考慮する必要がある状況 |
| 環境（Environment） | 刺激が発生した状況・環境 |
| 成果物（Artifact） | 刺激によって受けた成果物（システム全体、その一部分） |
| 応答（Response） | 刺激が到着した後に開始される行動・動作 |
| 応答測定（Response measure） | 評価可能なシステムの応答単位 |
アーキテクチャドライバの6-partsによる分析例
ポータブルオーディオプレイヤーの「Performance (性能・速度)」に対しての例。
通常使用時に，ユーザーがコンテンツリストから任意の曲を選択した場合，100ms 以内に画面をコンテンツリストから曲の詳細情報画面に切り換え，1秒以内にその曲を再生し，3秒以内にその曲のタイトルとアーティスト情報を画面に提示すること．
| 要素 | 説明 |
|---|---|
| 刺激の発生源 | ユーザー |
| 刺激 | コンテンツリストからの選曲 |
| 環境 | 通常使用時 |
| 成果物 | システム |
| 応答 | 画面を詳細情報画面に切り換える・曲を再生する・曲のタイトルとアーティスト情報を画面に提示する |
| 応答測定 | それぞれ100ms以内・1秒以内・3秒以内 |
システムの「Availability (可用性) 」に対しての例。
システムAは呼び出し命令を受けた時、起動しているシステムBが動作不安定になることを防止するためにデータベースCのデータタイプやデータの確認を行いロック解除して終了する。
| 要素 | 説明 |
|---|---|
| 刺激の発生源 | コンピュータシステム |
| 刺激 | システムAに対する呼び出し命令 |
| 環境 | システムAの実行時 |
| 成果物 | システムA |
| 応答 | データタイプやデータの確認を行う |
| 応答測定 | ロック解除して終了している |
要件のシナリオを作成する段階では、多くの要件は6-partsの粒度におさまる。
6-partsの内容を分析することで、何を具体的にしなくてはならないのかを明確にし、どんな質問をステークホルダーと行うべきかを検討することが重要。
実際には 6-parts のシナリオは1回で決まることは少ないため、反復的に洗練されていく。
[説明省略] アーキテクチャを表現する視点
アーキテクチャ表現について議論する場合に「構造（Structure）」と「ビュー（View）」を使用する。
アーキテクチャ上の構造は、大きく3つに分割できる。
| 構造 | 視点 | 視点例 |
|---|---|---|
| モジュール構造（Module viewtype） | 静的視点 | モジュール、クラス、データベースのテーブル、ファイル、データ構造、レイヤー |
| コンポーネント&コネクタ構造（Component and Connector viewtype） | 動的視点 | プロセス、スレッド、オブジェクト、データリポジトリ |
| 割り当て構造（Allocation viewtype） | 物理的視点 | ネットワーク、センサー、配線 |
今回の説明では省略する（必要に応じて下記の参照を。）
[説明省略] アーキテクチャが十分か評価する
今回の説明では省略する。
ただし一番大切なことは、ステークホルダーにとってアーキテクチャが意味あるものとすること、その価値を最大化することにある。
[説明省略] レビュー観点
品質特性シナリオを使って、設計したアーキテクチャが、それを満たすか評価する。
| 品質特性 | 確認内容（例） |
|---|---|
| 可用性 | 検索インデックスが死んでいても、必要最低限のレスポンスを返せる |
| 可用性 | メンテナンス中を除いて、常にレスポンスを返すことができる |
| 性能 | 平均的な負荷状態で、3秒以内にレスポンスが返すことができる |
| スケーラビリティ | 向こう5年間で毎年20%ずつデータ量が増加していくデータを扱うことができる |
| … | … |
「Ratingの基準」は次のとおり。
- 1 = シナリオの期待にそぐわない、または評価に値しない
- 2 = 部分的にシナリオを満たしている。またはシナリオは見たせるが、受け入れがたい高リスクや技術的負債、コスト超過がある。
- 3 = シナリオを満たせており、許容できるリスク、技術負債、コストである。
- 4 = シナリオを満たしており、リスクや技術的負債がほとんどない（まったくない）、また予算内に収まっている。
[説明省略] テスト観点
システム結合テスト（構造検証）とソフトウェア結合テスト（結合テスト）は検証方法や検証観点は異なる。
システム結合テスト（構造検証）では、アーキテクチャ設計（構造設計）に対する検証（ハードとソフトを組み合わせた際の機能ブロックが動作すること）を確認する。
まとめ
品質特性シナリオは
- 設計に落とし込めるような形で記述されていない要求を具体的に分析すること
- 足りない情報が何かを把握すること
- 要求の中に複数の品質特性が重複していたり異なる要素が混ざっていないかを認識すること
などを可能とする。
品質保証・品質管理部は「品質を請け合う」事が仕事だが、
品質アーキテクト
として、設計開発部門や製造・サービス部門の最上流工程であるアーキテクチャの決定に携われている人はどの程度いるだろうか？
少なくとも私は見たことがない。
品質とはテスト工程ではなく設計工程の課題
にも関わらず、品質保証部に配属される人は設計経験の乏しい人ばかり。
会社の上層部がそもそも品質保証が何たるか？を理解しておらず本気で保証するつもりが無いのだろう。
今回は、アーキテクチャドライバの簡単なさわりだけ。
