Coursera Software Architecture Week3 Architectual Trade-offs
Quality Attributes
- 何がアーキテクチャの良し悪しを決めるのか？
- 品質をどのように評価するのか？ 品質が改善されたかどうかということをどのように評価するのか？
- 開発プランと開発チーム構築の場面でアーキテクチャをどのように使用するのか？
- 開発コストを削減し、開発効率を上げる機会をどのように検知するのか？ についてこの週のモジュールでは学ぶ。
デザインパターンは、特定の技術的な問題に対処するのによい方法だが、広い範囲のビジネス上の問題と関心に対処するための方法ではない。 現代のシステム開発では、後者の問題についても対処するべきである。システムアーキテクチャは、機能要件・非機能要件を含む、システム全体の図を扱う。
アーキテクチャはデザインパターンやデザイン原則のためにガイドラインを提供する。これは、システムがConceptual Integrity（概念上の一貫性）をもつことが、システム全体にわたって一貫性をもつことにつながるからである。 デザインパターンはシステムのメンテナンス性、再利用性、パフォーマンスを向上させるが、システムのテスト可能性、ユーザビリティ、信頼性については関心を持たない。システムアーキテクチャは、後者の非機能要件にも関心をもち、デザインパターンを注意深く組み合わせることで、一貫性のあるシステムを構築する。
システムアーキテクチャの本質的な良さ・悪さというものはない。システムアーキテクチャは要求に沿ってデザインされるものであり、要求は問題や必要に応じて生成されるものである。 たとえば、Web上のゲームシステムに対しては、リポジトリベースアーキテクチャ上で構築されたイベントベースアーキテクチャを使用する。しかしこれはリポジトリベースアーキテクチャが悪いというわけではなく、多数のユーザーのプレイに対応する方法としてリポジトリベースアーキテクチャが適切でないというだけである。このように、現代のシステムでは、複雑な問題に対処するために複数のアーキテクチャを組み合わせて使用する。コンテキストが重要なのである。
システムをデザインするときには、機能要件のほかに非機能要件も重要になってくる。非機能要件は、クライアントやステークホルダーによって明示的に示されないことも多い。また、これらはステークホルダーごとに異なってくることもある。例えば、開発チームはシステムのメンテナンス性、再利用性、テスト可能性を気にするが、エンドユーザーはテスト可能性などは気にかけない。そのかわり、ユーザビリティ、エラーハンドリング、安定性を気にかける。システムアーキテクチャはそれぞれのグループの関心事を組み込まなければいけない。そして、それぞれの要求に優先度をつけ、よいバランスをとらなければいけない。
開発者が気にする品質特性
- メンテナンス性
- 再利用性
- 柔軟性
- 変更用意制
- テスト可能性
- 一貫性
エンドユーザーが気にする品質特性
- 可用性（アップタイムから算出する）
- 操作性
- セキュリティ
- パフォーマンス（スループット、レイテンシから算出する）
- ユーザビリティ
品質の高いシステムアーキテクチャのデザインは、方法論的に確立されている。どのようにデザインするかのルールとガイドラインに従うことで、よいデザインを行うことができる。
