Software_Architecture_in_Practice

アーキテクチャが現在でも有効かどうか、という問いに対して著者はyesと答えている。それは以下のような理由による

要件の増加の速度自体が速くなっており、アーキテクトはカスタマーの競合に対するプレッシャーから加速する機能要求と不具合の修正に対峙している。アーキテクトはシステムのモジュラリティに注意を払わなければ、システムはすぐに理解できず、変更とデバッグが難しく、ビジネスの悩みの種になる

システムの抽象化が進んでいる中で、システムの複雑さも加速度的に増加している

情報システムの成長により、誰もシステムの全体像を理解できなくなっている。適切なアーキテクチャを選定しなければ、それに複雑さを加えることになりさらに理解が困難になる。

ツールにより自動化が進んだかなでも、システムの品質特性は自分たちで把握する必要がある。

クラウドやモバイル、仮想化が進んでいる中でこの本の第四版は作られた。

アーキテクチャは

ソフトウェア構造の集合である

抽象化である

アーキテクチャの重要性

以下のような重要性が書籍では定義されている

1. アーキテクチャはシステムの品質属性を左右する

2. アーキテクチャにおける決定はシステムの進化における推論と変更管理を可能にする

3. アーキテクチャの分析は早期のシステムの品質の推測を可能にする

4. ドキュメント化されたアーキテクチャはステークホルダ間のコミュニケーションを円滑にする

5. アーキテクチャは初期における基礎的な土台であり、設計の変更が難しい

6. アーキテクチャはその後の実装における制約を定義する

7. アーキテクチャは組織構造に影響を与える、またはその逆

8. アーキテクチャは段階的な開発の基礎を提供する

9. アーキテクトとプロジェクトマネージャに対してのコストとスケジュールの推測に利用される

10. プロダクトラインにおける根幹として定義され、移転可能で再利用可能なモデルとして作られる

11. アーキテクチャベースの開発はコンポーネントの組み込みにフォーカスをさせる

12. 設計の代替への制約を与えることで、開発者を生産性に集中させ、設計とシステムの複雑性を軽減させる

13. 新規メンバーへのシステムの理解に利用できる

品質属性

システムが満たすべき品質の基準の定義。システムがどのように動作するべきか。機能要件とは異なるもので、それと同様に重要。

ランタイム特性とシステム開発特性の2つに分類される。

ランタイム特性: 可用性、パフォーマンス、ユーザビリティ

システム開発特性: 変更容易性、テスト容易性、デプロイ容易性

ASR: Architecturally Significant Requirements

全ての要求は等価ではなく、いくつかの要求はアーキテクチャに重要な影響を及ぼす。これをASRと呼美、システムの構造とその成功に大きな影響を及ぼす要件である。ASRはシステムに対して必ず与えられるべきものである。

有無によってアーキテクチャの内容が左右されるものはASRと言って良い。

ASRは要件定義から引っ張ってきたりできるが曖昧な記述な場合があるため、ステークホルダーとのやりとりを通じて定義したり、ビジネス目標をベースに派生させて定義する。

Utility Treeを利用したASRの定義も可能。品質属性をツリー形式で記述し、品質特性のノードとして具体的なシナリオを記述、各シナリオにはビジネス価値と技術的なリスクの2つをLow, Medium, Highで定義してASRの優先順位を設定する。

ADDを用いたアーキテクチャ設計