ソフトウェアアーキテクチャとは何ですか。
ソフトウェアアーキテクチャの明確な説明をたくさん検索してきましたが、混乱するたびに、ソフトウェアアーキテクチャとは何か、それを表す標準的な方法はありますか、それともいくつかのソフトウェアコンポーネントを説明する一般的なものですか？
ソフトウェアアーキテクチャとは、多くの定義があります。 Software Engineering Instituteは ソフトウェアアーキテクチャの定義のコレクション を含みます。これには、SEIデータベースの論文や記事から引用された書誌定義、さまざまな書籍やその他の執筆から出版された定義、より著名または影響力のある古典的な定義が含まれます作品、より最近の作品からの現代の定義、およびコミュニティによって提供された定義。
正しい定義はありませんが、私は決定に言及するものを好む傾向があります。 Rational Unified Processの定義は、私がアーキテクチャと考えるものを最もよく捉えていると感じています。
アーキテクチャとは、ソフトウェアシステムの構成、システムを構成する構造要素とそのインターフェイスの選択、およびこれらの要素間のコラボレーションで指定された動作、これらの構造の構成に関する重要な決定のセットですそして、次第に大きくなるサブシステムへの行動要素と、この組織を導くアーキテクチャスタイル-これらの要素とそれらのインターフェイス、それらのコラボレーション、およびそれらの構成。
このアーキテクチャの定義に基づいて、重要な決定とその根拠、構造要素とそれらの構造要素へのインターフェイス、および構造要素を組み合わせて大規模なシステムを作成する方法を表す必要があります。
重要な決定は、変更するのに（時間、労力、または金銭的コストの点で）コストのかかる決定であると考えます。例としては、特定のプログラミング言語を選択し、特定の環境（ハードウェア環境、オペレーティングシステム、専用デバイス）、データ転送、および保存方法をターゲットにすることが考えられます。ウィキから正式な会議の議事録、そして 決定マトリックス の使用に至るまで、さまざまなテキストツールまたはグラフィックツールを使用して、これらの決定を記録できます。
構造要素は、任意の数の表現を使用してキャプチャできます。 SysML および [〜＃〜] uml [〜＃〜] は一般的です。 [〜＃〜] bmpn [〜＃〜] は、ビジネスプロセスを表すのに役立ちます。 Object-Process Methodology は、システムを構成するオブジェクトとアクションをキャプチャするために、システム設計フェーズで使用できます。データ量の多いシステムがある場合は、 Entity-Relationship Modeling も役立ちます。標準で十分に文書化されたモデリング言語を使用することをお勧めします。 -慣れていない人でも、既存のソースからモデリング表記法を理解する方法について、かなりの量の情報を入手できるはずです。 UML用に書かれていますが、 Martin FowlerのUMLモード は、これらの他の正式なモデリング言語にも適用できます。モデルは、スケッチから設計図まで忠実に再現され、開発前に開始され、表示された後に完了できます。対象となる対象読者に適切な情報。
詳細を知りたい場合は、 実際のソフトウェアアーキテクチャ と ドキュメント化ソフトウェアアーキテクチャ：ビューとその先 が、作成、維持、ソフトウェアシステムのアーキテクチャの文書化。
アーキテクチャとは、アプリケーションを構成する「大きなボックス」と、アプリケーションが機能するために相互にどのように相互作用するかを意味します。これらの「ボックス」は各プロジェクトに固有であるため、すべてのプロジェクトに適用されるソフトウェアアーキテクチャの普遍的に受け入れられている定義はありません（あるプロジェクトに適切なソフトウェアアーキテクチャは、別のプロジェクトに障害となる可能性があります）。したがって、それを表す標準的な方法もありません。 。
Martin Fowlerが短いプレゼンテーションで、一般的な特性の観点から、ソフトウェアアーキテクチャとは何かについて語っています。「Making Architecture Matter」（youtube link here ）。
講演のハイライト：
- ソフトウェアアーキテクチャは重要です。
- それはあなたが早い段階で行う必要がある決定です。
- アーキテクチャは、コストとトレードオフできない内部品質に関するものです（または、アーキテクチャが悪いと、製品の競争力を高める新しい機能を追加することが困難になるため、長期的には失うことになります）。
- 変更するのが難しいのは決定です。
ソフトウェアアーキテクチャとは何ですか？
ソフトウェアアーキテクチャ は、システムの上位レベルの構造です。つまり、ソフトウェアをそのビルディングブロックに分解し、ピースを一緒に保持するために選択された方法です。
ここで、Martin Fowlerの本「Patterns of enterprise application architecture」からの素敵な引用：
アーキテクチャは、多くの人々がほとんど合意せずに定義しようとする用語です。 2つの一般的な要素があります。1つはシステムをその部分に分解する最高レベルです。変更が難しい他の決定。
アーキテクチャの例
最上位レベルでは、アーキテクチャは多くの場合、そのレイヤーと外界との境界で表されます。例：
- マーティンの クリーンアーキテクチャ
- コックバーンの 六角形のアーキテクチャ
- ファウラーの プレゼンテーションドメインデータソースレイヤー
- そして他の多くの階層化アプローチ
アーキテクチャを表す方法は？
ファセットが異なる建物のアーキテクチャ（環境内の建物の体積表現、建物のファサードの全体図、各フロアの設計図など）と同様に、ソフトウェアアーキテクチャも同じシステムで異なるビューを処理します。
Tiの助け、UMLがあります。最高レベル：
- 環境内のシステムは ハイレベルユースケース で表されます。これは、境界、主な機能、および外部のアクター（人間または他のシステム）との関係を示します
- ビルディングブロックは コンポーネント図 で表すことができます
- a 展開図 は、ソフトウェアの環境でコンポーネントを配布する方法の概要を示すことができます
- コンポーネントの 内部構造 を示す複合構造図。
レベルがより詳細になるにつれて、クラス図、シーケンス図、アクティビティ図、およびコミュニケーション図を使用して、徐々にアーキテクチャの分野を離れて設計に行き着きます。
アーキテクチャはシステムの一部であり、最初からやり直すことなく変更することは不可能です。
言い換えれば、変更するのに本当に高価な部品です。
つまり、1つのシステムの設計を別のシステムのアーキテクチャにすることができ、その逆も可能です。
たとえば、3層を信じて、重要なものすべてをビジネスレイヤーに置く場合、データベースを、行と列のダンプコンテナーと見なすだけで、簡単に置き換えることができる場合、RDBMSはアーキテクチャーの一部にはなりません。
一方、データがシステムのコア部分と見なされ、アプリケーションが、認証および承認された結果セットを要求する可能性のある小さなツールである場合、RDBMSは、アーキテクチャおよび愚かなものになる可能性があります。少し完全に置き換え可能なJavaまたはその他のクライアントコンポーネントにはなりません。