私は次の用語についてかなり混乱しています:
ソフトウェアアーキテクチャ
ソフトウェアアプリケーションアーキテクチャは、パフォーマンス、セキュリティ、管理性などの一般的な品質属性を最適化しながら、技術的要件と運用要件のすべてを満たす構造化ソリューションを定義するプロセスです。これには、さまざまな要因に基づく一連の決定が含まれます。これらの決定はそれぞれ、アプリケーションの品質、パフォーマンス、保守性、および全体的な成功に大きな影響を与える可能性があります。 ( マイクロソフト )
システムアーキテクチャ
システムアーキテクチャは、システムの構造、動作、およびその他のビューを定義する概念モデルです。 1 アーキテクチャの説明は、システムの正式な説明と表現であり、システムに関する推論をサポートする方法で編成されていますシステムの構造と動作( wiki )
クラス図
ソフトウェアエンジニアリングでは、統一モデリング言語(UML)のクラス図は、システムのクラス、それらの属性、操作(またはメソッド)、およびオブジェクト間の関係を示すことによってシステムの構造を記述する一種の静的構造図です。 ( wiki )
これらの説明を読んだ場合、これらはすべて、アプリケーションのさまざまなモジュール間の相互作用を説明しています。 しかし、これらの違いは何ですか?
これらの用語を比較するために私が思った/試みたもの:
structure, behavior, and more views of a system
)は、アーキテクチャーに実装の詳細が存在しないことを意味しますが、クラス図は実装を説明し、おそらくアーキテクチャーではなく設計の方向にありますか?システムアーキテクチャは、システムのコンポーネントを説明します。たとえば、次のもので構成される注文入力システムがあるとします。
Webフロントエンド、ビジネスレイヤーサービス、およびデータストア。
したがって、これを示す高レベルの図を作成する必要があります。
ソフトウェアアプリケーションアーキテクチャは、特定のコンポーネントのアーキテクチャを示します。たとえば、注文入力システムのコンポーネントの1つはWebフロントエンドです。アプリケーションアーキテクチャは、そのコンポーネントのさまざまな層と相互作用を示します。レスポンシブUI、モデルビューコントローラー、Webサービスコールアウト、ロギングの実行方法など。これにより、各コンポーネントが構築され、より大きなシステムの一部であるそのコンポーネント内のレイヤーがわかります。
通常、そのコンポーネントの構築方法を示すより詳細な図が作成されます。
最後に、クラス図は、ソフトウェアアプリケーションアーキテクチャの詳細を示します。たとえば、ロギングインターフェイスのコントラクトはどのようになっていますか? Viewはどのようにコントローラーと相互作用しますか?など。これらは、システムの特定のコンポーネントのソフトウェアアプリケーションアーキテクチャをさらに詳しく説明します。
特定のコンポーネントが大きく複雑な場合、これらの多くが存在するはずです。
追加のポイント:
最後に重要なことですが、アーキテクチャとは、すべてを再構築せずに後で戻すのが困難または不可能である1回限りの選択です。設計とは一線を画すアーキテクチャの最良の定義は、「変更に非常にコストがかかるものすべて」です。したがって、アーキテクチャでは、通常、プログラミング言語、オペレーティングシステム、リレーショナルデータベースのブランドなど、ある種のソリューションに縛られるものの選択肢が見つかります。したがって、アーキテクチャとして分類されるものは、システム自体と、アスペクトに関してどの程度(柔軟性がない)かにも依存します。
クラス図は、残りの2つの用語とはかなり異なります。これらの用語は、クラスが他のクラスに提供するものと、クラスが互いにどのように相互作用するかを示します。ただし、「システムアーキテクチャ」と「ソフトウェアアーキテクチャ」という用語は混乱を招き、さらに明確にする必要があります。
「システム」とは、ソフトウェアコンポーネントだけでなく、ハードウェアコンポーネントなどの他のコンポーネントも指すことを理解することが重要です。システムにソフトウェアシステムのみが含まれている場合、両方の用語に違いはありません。ただし、明らかに、システムに他の非ソフトウェアコンポーネントが含まれている場合、ソフトウェアアーキテクチャはシステムのシステムアーキテクチャとは大きく異なります。