Architecture Driverベースの評価とは？
はじめに
ソフトウェアの設計とは？からの続きです。 前回触れた、利点や問題点をどうまとめるか？それをどう評価するか？についてまとめていきます。
アーキテクチャドライバーとは？
Architecture Driver（アーキテクチャドライバー） とは、ソフトウェアアーキテクチャの設計方針や構造を決定する重要な要因のことです。設計上の制約や要求事項を指します。前回挙げた利点・問題点もアーキテクチャドライバーの一部となります。
主な種類
大きく以下に分けられます。
- 機能要件（Function Requirement、以下FR）
- 非機能要件（Quality Attributes、以下FR）
- 機能要件（Function Requirement、以下FR）
利点や問題点をどうまとめるか？
こういった利点・問題点は非機能要件（Quality Attributes、以下QA）としてまとめることができます。なお、機能要件は「できる・できない」であるのに対して、非機能要件は「よし・あし」で評価される点に注意してください。
以下に主要な非機能要件（QA）を挙げます。
- Maintainability（保守性）: 変更・修正のしやすさ
- Testability（テスト容易性）: テストの実施しやすさ
- Debbugability（デバッグ容易性）: デバッグの実施しやすさ
- Reusability（再利用性）: 他の場面での利用しやすさ
- Understandability（理解しやすさ）: コードの読みやすさ
- Performance（性能）: 実行速度・メモリ使用量
- Reliability（信頼性）: 障害の起こりにくさ
電卓の例での評価
設計の実例で使った電卓を例にして評価してみます。
まずはそれぞれのQAから、ケース1とケース2それぞれを評価します。
| QA | ケース1（1つのクラス） | ケース2（複数クラス） |
|---|---|---|
| Maintainability | ❌ ログ出力を変更したいだけで計算処理も理解が必要 | ✅ 該当クラスのみ修正すればOK |
| Testability | ❌ 計算処理だけテストするのが困難 | ✅ 各機能を独立してテスト可能 |
| Reusability | ❌ 計算機能だけ他で使いたくても全体が必要 | ✅ MathOperationsクラスだけ再利用可能 |
| Understandability | ❌ 1つのメソッドで複数の責任を持つ | ✅ 各クラスの役割が明確 |
| Performance | ✅ オブジェクト生成が少ない | ❌ 複数オブジェクトでメモリ使用量増 |
ケース2の方が圧倒的によいかと思いきや、Performanceの観点ではケース1のほうが優れています。
Trade-offの明示
上で挙げた通り、どのような案の評価であってもほぼ必ず何かしらのTrade-Offがあるため、最後は設計判断（どの案をなぜ選んだか？のDecition）が必要になります。アーキテクトレビューでは、この設計判断をレビューしています。
設計判断
Performance vs Maintainability
✅ Performanceを重視する場合
→ ケース1を選択（オブジェクト生成コスト削減）
✅ Maintainability他を重視する場合
→ ケース2を選択（変更容易性向上）
判断基準
- このシステムはどのくらいの頻度で機能追加・変更があるか？
- パフォーマンスの要求レベルはどの程度か？
- 開発チームの規模は？（大きいチームほどMaintainabilityが重要）
評価の書き方
上の表でも簡単な評価は可能ですが、実際に評価する際にはTestable（評価可能）でなければ、設計案が本当にその非機能要件を十分に満たせているか？が明確になりません。このため、この非機能要件をSix Part Scenariosで表現することが一般的です。
2つのQAに対して実例を考えてみましょう。
Maintainability（保守性）の例
シナリオ：ログの出力形式を変更したい
【ケース1の場合】
- 変更箇所：Calculatorクラス内のcalculateメソッド
- 影響範囲：計算処理も含む1つの大きなメソッド全体を理解する必要
- リスク：計算処理に影響を与える可能性
【ケース2の場合】
- 変更箇所：CalculationLoggerクラスのlogメソッドのみ
- 影響範囲：ログ処理のみ
- リスク：他の処理への影響なし
Testability（テスト容易性）の例
シナリオ：計算処理の正確性をテストしたい
【ケース1の場合】
- テスト対象：Calculatorクラス全体
- 必要な準備：入力処理、表示処理、ログ処理も含めた統合テスト
- 問題：計算のバグか他の処理のバグか切り分けが困難
【ケース2の場合】
- テスト対象：MathOperationsクラスのみ
- 必要な準備：計算処理のみの単体テスト
- 利点：計算ロジックだけを集中的にテスト可能
Six Part ScenarioによるArchitecture Driverの記載例
Source: 開発者
Stimulus: ログの出力形式を変更したい
Environment: 運用中のシステム
Response: 変更を実施する
Response Measure: 2時間以内に変更完了、他機能への影響なし
→ この要求を満たすためには、ログ処理を独立したクラスに分離する設計が適している
まとめ
Six Part Scenarioにて各QAをArchitecture Driverとして表現、評価することで、設計判断が可能となります。設計を進めるうえで、これらを意識したドキュメント作成を心がけましょう。
Discussion