ソフトウェア設計とアーキテクチャ
ソフトウェア設計とアーキテクチャは、ソフトウェアシステムがコンポーネントとコネクタにどのように構造化されるか、責任がどのように分解されるか、そして設計上の決定が機能的ニーズと品質属性をどのように満たすかに関係します。
Definition
ソフトウェア設計とは、システムのアーキテクチャ、コンポーネント、インターフェース、およびその他の特性を定義するプロセスであり、ソフトウェアアーキテクチャとは、システムの要素、それらの関係、および両方の特性から構成される構造の集合です。
Scope
この分野は、アーキテクチャスタイルとパターン（階層型、クライアントサーバー型、マイクロサービス型、イベント駆動型、パイプ＆フィルター型）、モジュール性、情報隠蔽、凝集度、結合度、関心の分離などの設計原則、オブジェクト指向設計とコンポーネントベース設計、デザインパターン、アーキテクチャの品質属性とそのトレードオフ、および設計を表現するために使用されるUMLなどのモデリング表記法をカバーしています。
Sub-topics
Core questions
- システムはどのようにモジュールとコンポーネントに分解されるべきか？
- どのアーキテクチャスタイルが、必要な品質属性を最もよくサポートするか？
- 結合度や凝集度といった設計原則は、どのように優れた構造を導くのか？
- 再発する設計上の問題は、再利用可能なパターンによってどのように解決されるのか？
Key theories
- 情報隠蔽とモジュール性
- Parnasは、変更される可能性のある設計上の決定を安定したインターフェースの背後に隠すようにモジュールを定義すべきだと主張しました。これにより、変更が局所化され、この原則がモジュール性、カプセル化、低結合度の基礎となっています。
- アーキテクチャの品質属性とトレードオフ
- アーキテクチャは、パフォーマンス、変更容易性、可用性、セキュリティなどの品質属性によって推進されます。これらは互いに矛盾するため、アーキテクチャは本質的に、戦術とパターンに導かれたトレードオフに関する推論が中心となります。
- デザインパターン
- 再発する設計上の問題には、よく理解された名前付きの解決策（生成、構造、振る舞いのパターン）があり、これらは専門家の実践を捉え、オブジェクト指向設計のための共通の語彙を提供します。
Clinical relevance
アーキテクチャの決定は、後で変更するのが最も困難であり、システムの品質属性を最も強く決定するため、健全な設計とアーキテクチャは長期的なメンテナンスコストを削減し、スケーラビリティと進化を可能にし、チームの組織を形成します。
Evidence & guidelines
ISO/IEC/IEEE 42010はアーキテクチャ記述を標準化しており、SWEBOKソフトウェア設計知識領域は、『Software Architecture in Practice』などの参考書とともに、合意されたガイダンスを提供しています。
History
モジュール設計の原則は、1970年代初頭にParnasによって明確にされました。オブジェクト指向設計とデザインパターンは1980年代から1990年代にかけて成熟し、ソフトウェアアーキテクチャは1990年代半ばのShawとGarlanの研究によって独立した分野として登場しました。その後、2000年代にはサービス指向スタイル、2010年代にはマイクロサービススタイルが続きました。
Debates
- モノリシックアーキテクチャとマイクロサービスアーキテクチャ
- システムを単一のデプロイ可能なモノリスとして構築するか、多数の独立してデプロイ可能なサービスとして構築するかについては広く議論されています。マイクロサービスは、分散システムの複雑さを犠牲にして独立したスケーリングとデプロイを提供するため、適切な選択は規模と組織構造に依存します。
Key figures
- David Parnas
- Mary Shaw
- Len Bass
- Erich Gamma
- Grady Booch
Related topics
Seminal works
- parnas1972
- gamma1994
- bass2012
Frequently asked questions
- 設計とアーキテクチャの違いは何ですか？
- アーキテクチャは、最も高レベルの構造と、変更に最もコストがかかる決定（主要なコンポーネント、それらの相互作用、システム全体の品質属性）に関係する一方、設計はそれらのコンポーネントのより詳細な内部構造をカバーします。その境界は、明確な線引きというよりも重要性の違いによるものです。
- デザインパターンが重要なのはなぜですか？
- パターンは、再発する設計上の問題に対する実証済みの解決策を捉え、エンジニアに共通の語彙を提供することで、設計の伝達、推論、進化を容易にします。これらは、必須のレシピではなく、慎重に適用されるべきガイダンスです。