ソフトウェアアーキテクチャ その5 - 品質特性の実現手法 [arch]
前回，アーキテクチャ決定要因の中でもとりわけ品質特性と6つの要素から成る品質特性シナリオによる分析がいかに重要かを述べたが，今回は品質特性の実現手法について書いてみたいと思う．
Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003
--> Chapter 5
|
タイトルの "in Practice" (実践における) が示す通り，様々なケーススタディを交えつつ，非常に具体性のある内容になっている．
こちらがその和訳本．
アーキテクチャ決定要因を分析し，優先順位もつけたとしよう．ではここから具体的に特定の品質特性を実現するにはどうすれば良いのだろうか．
本書ではこの実現手法を "tactics" と呼び，その集合を "architectural strategy" と呼んでいる．
Tactics 1つ1つは特に新しい概念ではなく，実際の開発でよく見かける設計方針を体系的に整理し，特定の品質特性に紐付けたものだ．
例えば availability (可用性) の実現には，fault detection (障害検出)，fault recovery (障害復帰)，fault prevention (障害防止) といった要素があり，それぞれの tactics は，
Fault detection
- Ping/echo
- Heartbeat
- Exception
Fault recovery
- Voting
- Active redundancy
- Passive redundancy
- Spare
- Shadow
- State resynchronization
- Checkpoint/rollback
Fault prevention
- Removal from service
- Transactions
- Process monitor
となる．
これを見ても分かるように，ping を飛ばしたり，ハートビートやエクセプションを使ったり，あらかじめシステムに冗長性 (redundancy) を持たせたり (ハードディスクをミラーリングするとか) などは特に珍しい話ではないだろう．
他の品質特性も含めて各 tactics の詳細については，本書の5章，もしくは以下を参照頂きたい．特に各セクションの最後には各品質特性に属する tactics が分かりやすくまとめられている．
Availability Tactics
→ Figure 5.3. Summary of availability tactics
Modifiability Tactics
→ Figure 5.5. Summary of modifiability tactics
Performance Tactics
→ Figure 5.7. Summary of performance tactics
Security Tactics
→ Figure 5.9. Summary of security tactics
Testability Tactics
→ Figure 5.11. Summary of testability tactics
Usability Tactics
→ Figure 5.13. Summary of usability tactics
実際の開発においては，まず architectural pattern を先に決め，それから要件に応じて tactics を適用しながら pattern を洗練させていくやり方もあるだろうし，先に採用する tactics を決め，そこから pattern に落とし込んでいくやり方もあるだろう．個人的な経験では，制約から pattern が見えてくる場合が多く，そこから複数の pattern を組み合わせながら tactics を適用していくアプローチが多いように思う．
前回「全ての方針決定はトレードオフを伴う」と述べた．
例えば問題領域の関係を疎にすることが先決であると判断し，architectural pattern として "client-server" を採用したとしよう．
Pattern は特定の品質特性を促進し，特定の品質特性を抑制する．client-server を採用したことにより，スケーラビリティを上げた一方で，performance，security，availability などは低下してしまった．これが問題かどうかは要件分析結果次第だが，このシステムは availability のプライオリティが高かったと仮定して，それを促進する為に availability tactics の適用を検討する．
ここでもトレードオフはあり，例えば ping/echo を採用すれば performance をさらに下げるだろうし，voting は testability を下げるだろうし，spare では満たしたい availability には不十分かもしれない．
…といった具合にバランスを取りながら1つ1つの方針を決定していき，いかにシステム全体として品質を高めていくか，ということがトレードオフの概念だ．要件分析と優先順位設定を注意深く実施し，ビジネスケースをアーキテクチャにマッピングしていくことがなにより重要なことである．
こういった設計の具体的な手順についてもいずれ本シリーズで扱いたいと思うが，最近よく思うことは，正しい見積りを行う為にはアーキテクチャを予見することが不可欠であり，しかもそのアーキテクチャは担当者に可視化されていなければいけないということだ．
それを怠ると，どこまでやれば終わりか担当者に見えず，特に開発の初中期段階でグループリーダーレベルが不安になり，二言目には「人が足りない」「終わらない」という言葉が出るようになる．これはグループリーダーの能力が低いと言うよりは，アーキテクトの責任によるところが大きいのかもしれない．
0 コメント:
コメントを投稿