ソフトウェアアーキテクチャ

ソフトウェアアーキテクチャとは、ソフトウェアシステムについて推論するために必要な構造の集合と、そのような構造やシステムを作成するための規律である。各構造は、ソフトウェア要素、それらの関係、および要素と関係の両方のプロパティから構成される。^{[1] [2]}

ソフトウェアシステムのアーキテクチャは、建物の建築に似た比喩です。[ 3 ]これは^システムと開発プロジェクトの青写真として機能し、プロジェクト管理ではこれを使用して、関係するチームや人々が実行する必要があるタスクを推測することができます。

ソフトウェアアーキテクチャとは、一度実装すると変更にコストがかかる基本的な構造上の選択を行うことです。ソフトウェアアーキテクチャの選択には、ソフトウェアの設計における可能性からの特定の構造オプションが含まれます。ソフトウェアアーキテクチャには2つの基本法則があります。^{[4] [5]}

1. すべてはトレードオフだ
2. 「なぜかはどうやってかよりも大切だ」

「アーキテクチャ カタ」は、ニーズに合ったアーキテクチャ ソリューションを作成するために使用できるチームワークです。各チームは、アーキテクチャ特性 (非機能要件とも呼ばれます) を抽出して優先順位を付け、それに応じてコンポーネントをモデル化します。チームは、アーキテクチャをモデル化するための柔軟な方法であるC4 モデルを使用できます。アーキテクチャ コンポーネント間の同期通信はそれらを絡ませ、同じアーキテクチャ特性を共有する必要があることに注意してください。^[6]

ソフトウェアアーキテクチャを文書化することで、利害関係者間のコミュニケーションが容易になり、高レベルの設計に関する早期の決定が記録され、プロジェクト間で設計コンポーネントの再利用が可能になります。^{[7] ：29–35}

ソフトウェア アーキテクチャ設計は、ソフトウェア アプリケーション設計と対比されることがよくあります。アプリケーション設計は、必要な機能 (システムが提供するサービス) をサポートするプロセスとデータの設計に重点を置いていますが、ソフトウェア アーキテクチャ設計は、アプリケーションの機能を実現および実行できるインフラストラクチャの設計に重点を置いており、その機能はシステムの非機能要件を満たす方法で提供されます。

ソフトウェアアーキテクチャは、モノリスと分散アーキテクチャの2つの主要なタイプに分類でき、それぞれにサブカテゴリがあります。^[5]

ソフトウェアアーキテクチャは時間の経過とともに複雑になる傾向があります。ソフトウェアアーキテクトは「適応度関数」を使用して、アーキテクチャを継続的にチェックする必要があります。^[5]

ソフトウェアアーキテクチャの範囲については意見が分かれている。^[8]

• マクロシステム構造：これは、計算コンポーネントの集合と、それらのコンポーネント間の相互作用を記述するコネクタで構成されるソフトウェアシステムの高レベルの抽象化としてのアーキテクチャを指します。 ^[9]
• 重要なことは、それが何であれ、ソフトウェアアーキテクトがシステムとその利害関係者に大きな影響を与える決定に関与する必要があるという事実を指します。^[10]
• 環境内のシステムを理解する上で基本的なもの^[11]
• 人々が変更が難しいと認識しているもの: アーキテクチャの設計はソフトウェア システムのライフサイクルの最初に行われるため、アーキテクトは最初から正しくなければならない決定に重点を置く必要があります。この考え方に従うと、アーキテクチャ設計の問題は、その不可逆性を克服できれば、非アーキテクチャになる可能性があります。^[10]
• アーキテクチャ設計の決定の集合：ソフトウェアアーキテクチャは、単なるモデルや構造の集合としてではなく、これらの特定の構造につながる決定とその背後にある理論的根拠も含める必要があります。^{[12]この洞察により、ソフトウェアアーキテクチャの}知識管理に関する重要な研究が行われました。^[13]

ソフトウェアアーキテクチャと設計および要件エンジニアリングの間には明確な区別はありません（以下の関連分野を参照）。それらはすべて、高レベルの意図から低レベルの詳細までの「意図の連鎖」の一部です。^{[14] : 18}

ソフトウェア アーキテクチャは次のようになります。

多数の利害関係者：ソフトウェアシステムは、ビジネスマネージャ、所有者、ユーザー、オペレーターなど、さまざまな利害関係者に対応する必要があります。これらの利害関係者は皆、システムに関して独自の懸念を抱いています。これらの懸念のバランスを取り、それらが対処されていることを示すことは、システム設計の一部です。^{[7] ：29–31}これは、アーキテクチャが多種多様な懸念と利害関係者に対処することを含み、学際的な性質を持っていることを意味します。

関心の分離：建築家が複雑さを軽減するための確立された方法は、設計を推進する関心を分離することです。アーキテクチャのドキュメントは、さまざまな利害関係者の関心事に関連する別々の視点からアーキテクチャをモデル化および記述することで、すべての利害関係者の関心事に対処することを示しています。 ^[15]これらの個別の記述はアーキテクチャビューと呼ばれます（たとえば、 4 + 1アーキテクチャビューモデルを参照）。

品質主導:古典的なソフトウェア設計アプローチ (例:ジャクソン構造化プログラミング) は、必要な機能とシステムを通るデータの流れによって設計されていましたが、現在の見解^{[7] : 26–28}では、ソフトウェア システムのアーキテクチャは、フォールト トレランス、下位互換性、拡張性、信頼性、保守性、可用性、セキュリティ、ユーザビリティなどの品質属性とより密接に関連していると考えられています。利害関係者の懸念は、多くの場合、これらの品質属性に関する要件に変換され、非機能要件、機能外要件、動作要件、品質属性要件など、 さまざまな名前で呼ばれます。

繰り返し発生するスタイル:建築建築と同様に、ソフトウェアアーキテクチャの分野では、繰り返し発生する問題に対処するための標準的な方法が開発されています。これらの「標準的な方法」は、抽象化のレベルに応じてさまざまな名前で呼ばれています。繰り返し発生するソリューションの一般的な用語は、アーキテクチャスタイル、^{[14] : 273–277、}戦術、^{[7] : 70–72、} 参照アーキテクチャ、アーキテクチャパターンです。^{[16] [17] [7] : 203–205}

概念的整合性:フレッド・ブルックスが1975 年の著書『人月の神話』で導入した用語で、ソフトウェア システムのアーキテクチャは、ソフトウェア システムが何をすべきか、どのようにすべきかという全体的なビジョンを表すという考え方を示すものです。このビジョンは実装とは切り離す必要があります。アーキテクトは「ビジョンの番人」の役割を担い、システムへの追加がアーキテクチャと一致していることを確認し、概念的整合性を維持します。^{[18] : 41–50}

認知的制約：コンピュータプログラマーのメルビン・コンウェイが1967年の論文で初めて指摘した、システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計をするように制約されているという見解。^[19]フレッド・ブルックスは、この論文とアイデアを『人月の神話』で引用し、これをコンウェイの法則と呼んで、より広い聴衆に紹介した。

ソフトウェアアーキテクチャは、複雑なシステムを「知的に理解可能な」抽象化したものである。^{[7] : 5–6}この抽象化には、次のような多くの利点がある。

• これは、システムが構築される前にソフトウェアシステムの動作を分析するための基礎を提供します。^[3]将来のソフトウェアシステムが実際に構築することなく利害関係者のニーズを満たすことを検証する機能は、大幅なコスト削減とリスク軽減を意味します。^[20] ATAMやソフトウェアシステムの視覚的表現の作成など、このような分析を実行するためのさまざまな手法が開発されています。
• これは、要素と決定事項の再利用の基盤を提供します。^{[3] [7] : 35}完全なソフトウェアアーキテクチャまたはその一部、個々のアーキテクチャ戦略や決定事項などは、利害関係者が同様の品質特性や機能を必要とする複数のシステム間で再利用できるため、設計コストを節約し、設計ミスのリスクを軽減できます。
• これは、システムの開発、展開、保守の寿命に影響を与える初期の設計決定をサポートします。^{[7] ：31}影響の大きい初期の決定を正しく行うことは、スケジュールと予算の超過を防ぐために重要です。
• 利害関係者とのコミュニケーションを促進し、彼らのニーズをよりよく満たすシステムに貢献します。^{[7] ：29–31}利害関係者の視点から複雑なシステムについてコミュニケーションすることは、彼らが表明した要件とそれに基づいた設計上の決定の結果を理解するのに役立ちます。アーキテクチャは、システムが実装される前、つまりまだ比較的簡単に適応できるときに、設計上の決定についてコミュニケーションする機能を提供します。
• リスク管理に役立ちます。ソフトウェアアーキテクチャはリスクと障害の可能性を減らすのに役立ちます。^{[14] : 18}
• コスト削減を可能にします。ソフトウェアアーキテクチャは、複雑なITプロジェクトにおけるリスクとコストを管理する手段です。^[21]

ソフトウェア設計と（土木）建築の比較は、1960年代後半に初めて行われたが^[22] 、 「ソフトウェア アーキテクチャ」という用語は1990年代まで広く使用されていなかった。^[23]コンピュータ サイエンスの分野は、その形成以来、複雑性に関連する問題に直面してきた。^[24]初期の複雑性の問題は、開発者が適切なデータ構造を選択し、アルゴリズムを開発し、関心の分離の概念を適用することで解決された。「ソフトウェア アーキテクチャ」という用語は業界では比較的新しいが、この分野の基本原則は、 1980年代半ばからソフトウェア エンジニアリングの先駆者によって散発的に適用されてきた。システムのソフトウェア アーキテクチャを捉えて説明する初期の試みは、不正確でまとまりがなく、ボックスとラインの図のセットで特徴付けられることが多かった。^[25]

ソフトウェアアーキテクチャの概念は、 1968年のエドガー・ダイクストラと1970年代初頭のデイビッド・パルナスの研究に端を発しています。これらの科学者は、ソフトウェアシステムの構造が重要であり、その構造を正しく理解することが極めて重要であると強調しました。1990年代には、この分野の基本的な側面を定義し体系化するための協調的な取り組みが行われ、研究作業はアーキテクチャスタイル（パターン）、アーキテクチャ記述言語、アーキテクチャドキュメント、および形式手法に集中しました。^[26]

研究機関は、ソフトウェア アーキテクチャを学問として推進する上で重要な役割を果たしてきました。カーネギー メロン大学のMary ShawとDavid Garlan は、1996 年に「ソフトウェア アーキテクチャ: 新興分野の展望」というタイトルの本を執筆し、コンポーネント、コネクタ、スタイルなどのソフトウェア アーキテクチャの概念を推進しました。カリフォルニア大学アーバイン校のソフトウェア研究機関のソフトウェア アーキテクチャ研究の取り組みは、主にアーキテクチャ スタイル、アーキテクチャ記述言語、動的アーキテクチャに向けられています。

IEEE 1471 -2000「ソフトウェア集約型システムのアーキテクチャ記述に関する推奨プラクティス」は、ソフトウェアアーキテクチャの分野における最初の正式な標準でした。これは、2007年にISOによってISO/IEC 42010:2007として採用されました。2011年11月、IEEE 1471–2000は、 ISO/IEC/IEEE 42010:2011、「システムおよびソフトウェアエンジニアリング-アーキテクチャ記述」（IEEEとISOが共同発行）に置き換えられました。 ^[15]

IEEE 1471では、ソフトウェア アーキテクチャは「ソフトウェア集約型システム」のアーキテクチャに関するもので、「ソフトウェアがシステム全体の設計、構築、展開、進化に重要な影響を及ぼすあらゆるシステム」と定義されていましたが、2011 版ではさらに一歩進んで、ハードウェアとソフトウェアだけでなく、「人間、プロセス、手順、設備、材料、自然発生的なエンティティ」も含むISO/IEC 15288およびISO/IEC 12207のシステム定義が取り入れられています。これは、ソフトウェア アーキテクチャ、エンタープライズ アーキテクチャ、ソリューション アーキテクチャの関係を反映しています。

ソフトウェアアーキテクトが行う活動は多岐にわたります。ソフトウェアアーキテクトは通常、プロジェクトマネージャーと連携し、利害関係者とアーキテクチャ上重要な要件について話し合い、ソフトウェアアーキテクチャを設計し、設計を評価し、設計者や利害関係者とコミュニケーションを取り、アーキテクチャ設計を文書化します。^[27]

アーキテクチャ特性（非機能要件とも呼ばれる）をビジネス要件と一致させることはソフトウェアアーキテクトの責任です。例: ^[5]

• 高い顧客満足度を実現するには、システムの可用性、フォールト トレランス、セキュリティ、テスト可能性、回復可能性、俊敏性、パフォーマンスが必要です。
• 合併と買収（M&A）には、拡張性、スケーラビリティ、適応性、相互運用性が必要です。
• 予算と時間が限られているため、実現可能性とシンプルさが求められる
• 市場投入までの時間を短縮するには、保守性、テスト可能性、および信頼性が必要です。

ソフトウェアアーキテクチャ設計には4つのコアアクティビティがあります。^[28]これらのコアアーキテクチャアクティビティは、初期のソフトウェア開発ライフサイクルのさまざまな段階で、またシステムの進化を通じて反復的に実行されます。

アーキテクチャ分析は、提案されたシステムが動作する環境を理解し、システムの要件を決定するプロセスです。分析アクティビティへの入力または要件は、任意の数の利害関係者から提供され、次のような項目が含まれます。

• システムが運用時に何を行うか（機能要件）
• システムが、信頼性、操作性、パフォーマンス効率、セキュリティ、互換性などの実行時の非機能要件をISO/IEC 25010 :2011規格^{[29]で定義されているとおりにどの程度実行できるか}
• ISO 25010:2011規格で定義されている保守性や移転可能性などの非機能要件の開発時間^[29]
• 法律、社会、財務、競争、技術などの懸念事項など、時間の経過とともに変化する可能性のあるシステムのビジネス要件と環境コンテキスト^[30]

分析活動の出力は、ソフトウェアシステムのアーキテクチャに測定可能な影響を与える要件であり、アーキテクチャ的に重要な要件と呼ばれます。^[31]

建築の統合または設計は、建築を作成するプロセスです。分析によって決定された建築上重要な要件、設計の現状、および評価活動の結果に基づいて、設計が作成され、改善されます。^{[28] [7] : 311–326}

アーキテクチャ評価とは、現在の設計またはその一部が分析中に導き出された要件をどの程度満たしているかを判断するプロセスです。評価は、アーキテクトが設計上の決定を検討しているとき、設計の一部が完了した後、最終設計が完了した後、またはシステムの構築後に行うことができます。利用可能なソフトウェア アーキテクチャ評価手法には、アーキテクチャ トレードオフ分析法 (ATAM)や TARA などがあります。^{[32]これらの手法を比較するためのフレームワークは}、SARA レポート^[20]やアーキテクチャ レビュー: 実践と経験などのフレームワークで説明されています。^[33]

アーキテクチャの進化とは、要件や環境の変化に合わせて既存のソフトウェア アーキテクチャを維持および適応させるプロセスです。ソフトウェア アーキテクチャはソフトウェア システムの基本構造を提供するため、その進化とメンテナンスは必然的に基本構造に影響を与えます。そのため、アーキテクチャの進化は、新しい機能の追加と、既存の機能およびシステム動作の維持に関係します。

アーキテクチャには重要なサポート活動が必要です。これらのサポート活動は、コア ソフトウェア アーキテクチャ プロセス全体にわたって行われます。サポート活動には、知識管理とコミュニケーション、設計の推論と意思決定、ドキュメント作成などが含まれます。

ソフトウェア アーキテクチャ サポート アクティビティは、コア ソフトウェア アーキテクチャ アクティビティ中に実行されます。これらのサポート アクティビティは、ソフトウェア アーキテクトが分析、統合、評価、および進化を実行するのに役立ちます。たとえば、アーキテクトは分析フェーズ中に知識を収集し、決定を下し、文書化する必要があります。

• 知識管理とコミュニケーションは、ソフトウェアアーキテクチャの設計に不可欠な知識を探索および管理する行為です。ソフトウェアアーキテクトは孤立して作業しません。さまざまな利害関係者から入力、機能要件と非機能要件、設計コンテキストを取得し、出力を利害関係者に提供します。ソフトウェアアーキテクチャの知識は暗黙的であることが多く、利害関係者の頭の中に保持されています。ソフトウェアアーキテクチャの知識管理活動は、知識を見つけ、伝え、保持することです。ソフトウェアアーキテクチャの設計上の問題は複雑で相互に依存しているため、設計の理由付けにおける知識のギャップは、誤ったソフトウェアアーキテクチャ設計につながる可能性があります。^{[27] [34]}知識管理とコミュニケーション活動の例には、設計パターンの検索、プロトタイピング、経験豊富な開発者やアーキテクトへの質問、類似システムの設計の評価、他の設計者や利害関係者との知識の共有、Wiki ページでの経験のドキュメント化などがあります。
• 設計推論と意思決定は、設計上の決定を評価する活動です。この活動は、3 つのコア ソフトウェア アーキテクチャ活動すべてに共通する基礎となります。^{[12] [35]}これには、決定コンテキストの収集と関連付け、設計上の決定問題の定式化、ソリューション オプションの検出、および決定前のトレードオフの評価が含まれます。このプロセスは、重要なアーキテクチャ要件とソフトウェア アーキテクチャの決定を評価し、ソフトウェア アーキテクチャの分析、統合、および評価を行う際に、さまざまなレベルの決定粒度で発生します。推論活動の例には、要件または設計が品質属性に与える影響の理解、設計によって発生する可能性のある問題の検討、考えられるソリューション オプションの評価、およびソリューション間のトレードオフの評価などがあります。
• ドキュメンテーションとは、ソフトウェアアーキテクチャのプロセス中に生成された設計を記録する行為です。システム設計は、システムのコード構造を示す静的ビュー、実行中のシステムの動作を示す動的ビュー、実行のためにシステムがどのようにハードウェア上に配置されるかを示すデプロイメントビューなど、いくつかのビューを使用して記述されます。Kruchten の 4+1 ビューは、ソフトウェアアーキテクチャを文書化するためによく使用されるビューの説明を示しています。 ^[36] Documenting Software Architectures: Views and Beyond には、ビューの説明で使用できる表記法の種類についての説明があります。^[1]ドキュメンテーション活動の例には、仕様の作成、システム設計モデルの記録、設計根拠の文書化、視点の開発、ビューの文書化などがあります。

ソフトウェア アーキテクチャの記述には、アーキテクチャ記述言語、アーキテクチャ ビューポイント、アーキテクチャ フレームワークなどのメカニズムを使用して、アーキテクチャをモデル化および表現するための原則と実践が含まれます。

アーキテクチャ記述言語 (ADL) は、ソフトウェア アーキテクチャ ( ISO/IEC/IEEE 42010 ) を記述するために使用される表現手段です。1990 年代以降、AADL (SAE 標準)、Wright (カーネギー メロン大学が開発)、Acme (カーネギー メロン大学が開発)、xADL (UCI が開発)、Darwin (インペリアル カレッジ ロンドンが開発)、DAOP-ADL (マラガ大学が開発)、SBC-ADL (国立中山大学が開発)、ByADL (イタリアのラクイラ大学) など、多くの専用 ADL が開発されてきました。

ソフトウェア アーキテクチャの記述は、一般的にビューにまとめられます。これは、建築物の建築で作成されるさまざまな種類の設計図に似ています。各ビューは、そのビューポイントの規則に従って、一連のシステムの問題に対処します。ビューポイントとは、特定の利害関係者とその問題の観点から、問題のアーキテクチャを表現するビューで使用する表記法、モデリング、および分析手法を記述した仕様です ( ISO/IEC/IEEE 42010 )。ビューポイントは、フレーム化された (つまり、対処される) 問題だけでなく、プレゼンテーション、使用するモデルの種類、使用する規則、およびビューと他のビューの一貫性を保つための一貫性 (対応) ルールも指定します。

アーキテクチャ フレームワークは、「特定のアプリケーション ドメインおよび/または利害関係者のコミュニティ内で確立されたアーキテクチャの記述に関する規約、原則、および実践」( ISO/IEC/IEEE 42010 ) をキャプチャします。フレームワークは通常、1 つ以上のビューポイントまたは ADL に基づいて実装されます。

アーキテクチャパターンは、特定のコンテキスト内でソフトウェア アーキテクチャでよく発生する問題に対する、一般的な再利用可能なソリューションです。アーキテクチャ パターンは、多くの場合、ソフトウェア設計パターンとして文書化されます。

「ソフトウェア建築様式」とは、伝統的な建築様式に倣い、それを際立たせる特徴を備えた特定の建築手法である（建築様式）。

アーキテクチャスタイルは、構造組織のパターンの観点から見たシステムのファミリー、コンポーネントとコネクタの語彙、およびそれらを組み合わせる方法に関する制約を定義します。^[37]

アーキテクチャスタイルは、選択された望ましい品質を誘導するためにアーキテクチャに適用される設計上の決定と制約の再利用可能な「パッケージ」です。^[38]

認識されている建築パターンやスタイルは数多くありますが、その中には次のようなものがあります。

• 黒板
• ブローカーパターン
• クライアント サーバー(2 層、3 層、n層、クラウド コンピューティングはこのスタイルを採用しています)
• コンポーネントベース
• データ中心
• イベント駆動型（または暗黙的な呼び出し）
• インタープリタパターン
• 階層化（または多層アーキテクチャ）
• マスタースレーブ
• マイクロサービスアーキテクチャ
• モデル・ビュー・コントローラ
• モノリシックアプリケーション
• ピアツーピア(P2P)
• パイプとフィルター
• プラグイン
• リアクティブアーキテクチャ
• 表現状態転送(REST)
• ルールベース
• サービス指向
• シェアードナッシングアーキテクチャ
• 宇宙ベースの建築
• サーバーレスアーキテクチャ

アーキテクチャパターンとアーキテクチャスタイルを同じものとして扱う人もいれば、^[39]スタイルをパターンの特殊化として扱う人もいます。共通点は、パターンとスタイルはどちらも建築家が使用するイディオムであり、システムのクラスを記述するための 「共通言語」 ^[39]または「語彙」^{[37]を提供することです。}

また、ソフトウェアアーキテクチャは、特にアジャイルソフトウェア開発の支持者の間では、事前の設計が大きすぎるという懸念もあります。事前の設計とアジリティのトレードオフのバランスをとるために、いくつかの方法が開発されてきました。^[40]アジャイルメソッドDSDMは、「十分な」アーキテクチャの基礎が築かれる「基礎」フェーズを義務付けています。IEEEソフトウェアは、アジリティとアーキテクチャの相互作用に特別号を割きました。

ソフトウェアアーキテクチャの侵食とは、ソフトウェアシステムの意図されたアーキテクチャと実装されたアーキテクチャの間に時間の経過とともに徐々に生じるギャップを指します。^[41]ソフトウェアアーキテクチャの侵食の現象は、1992年にペリーとウルフによってソフトウェアアーキテクチャの定義とともに初めて明らかにされました。^[3]

ソフトウェアアーキテクチャの侵食は、ソフトウェア開発ライフサイクルの各段階で発生する可能性があり、開発速度と保守コストにさまざまな影響を与えます。ソフトウェアアーキテクチャの侵食は、アーキテクチャ違反、技術的負債の蓄積、知識の蒸発など、さまざまな理由で発生します。^[42]アーキテクチャ侵食の有名な例は、Mozilla Webブラウザの失敗です。^[43] MozillaはNetscapeによって作成されたアプリケーションであり、コードベースが複雑で、継続的な変更により保守が困難になりました。当初の設計が不十分でアーキテクチャ侵食が拡大したため、Netscapeは2年かけてMozilla Webブラウザを再開発しました。これは、大規模な修復作業、時間、コストの損失を避けるためにアーキテクチャの侵食を管理することがいかに重要であるかを示しています。

アーキテクチャの侵食は、ソフトウェアのパフォーマンスを低下させ、進化コストを大幅に増加させ、ソフトウェアの品質を低下させる可能性があります。アーキテクチャの侵食を検出するために、さまざまなアプローチとツールが提案されています。これらのアプローチは、主に一貫性ベース、進化ベース、欠陥ベース、および意思決定ベースのアプローチの4つのカテゴリに分類されます。^[41]さらに、アーキテクチャの侵食に対処するために使用される対策には、予防策と改善策の2つの主要なタイプがあります。^[41]

ソフトウェアアーキテクチャの回復（または再構築、リバースエンジニアリング）には、実装やドキュメントなどの利用可能な情報からソフトウェアシステムのアーキテクチャを明らかにする方法、技術、プロセスが含まれます。アーキテクチャの回復は、古くなったドキュメントやアーキテクチャの劣化（想定されたアーキテクチャから逸脱した実装や保守の決定）に直面したときに、情報に基づいた決定を下すために必要になることがよくあります。^[44]静的プログラム分析としてソフトウェアアーキテクチャを回復するためのプラクティスが存在します。これは、ソフトウェアインテリジェンスプラクティスでカバーされる主題の一部です。

アーキテクチャは設計ですが、設計の全てがアーキテクチャ的であるわけではありません。^[1]実際には、ソフトウェア アーキテクチャ (アーキテクチャ設計) と詳細設計 (非アーキテクチャ設計) の線引きをするのはアーキテクトです。区別を形式化する試みはありましたが、すべてのケースに当てはまるルールやガイドラインはありません。内包/局所性仮説^[45]によれば、アーキテクチャ設計と詳細設計の区別は局所性基準^[45]によって定義され、それによれば、ソフトウェア設計に関する記述が非局所的 (アーキテクチャ的) であるのは、それを満たすプログラムを、それを満たさないプログラムに拡張できる場合のみです。たとえば、クライアント サーバースタイルはアーキテクチャ的 (戦略的) です。なぜなら、この原則に基づいて構築されたプログラムは、たとえばピアツーピアノードを追加するなどして、クライアント サーバーではないプログラムに拡張できるからです。

要件工学とソフトウェアアーキテクチャは補完的なアプローチと見ることができます。ソフトウェアアーキテクチャが「ソリューション空間」または「方法」を対象としているのに対し、要件工学は「問題空間」または「内容」に対処します。^{[46]要件工学には、}要件の引き出し、交渉、仕様、検証、文書化、管理が含まれます。要件工学とソフトウェアアーキテクチャはどちらも、利害関係者の懸念、ニーズ、希望を 中心に展開されます。

要件エンジニアリングとソフトウェア アーキテクチャの間には、かなりの重複部分があります。たとえば、5 つの産業用ソフトウェア アーキテクチャ手法に関する研究では、「入力 (目標、制約など) は通常、明確に定義されておらず、アーキテクチャが出現し始めて初めて発見されたり、理解が深まったりする」と結論付けられています。また、「アーキテクチャ上の懸念事項のほとんどは、システムの要件として表現されますが、必須の設計上の決定も含まれる場合があります」と結論付けられています。^[28]つまり、必要な動作はソリューション アーキテクチャに影響を及ぼし、その結果、新しい要件が導入される可能性があります。^[47]ツイン ピークス モデル^{[48]などのアプローチは、要件とアーキテクチャの}相乗関係を活用することを目的としています。

コンピュータアーキテクチャ

コンピュータ アーキテクチャは、CPU (プロセッサ)、バス、メモリなどのハードウェア コンポーネントの連携という観点から、コンピュータ システムの内部構造を対象としています。

サーバーレスアーキテクチャ

サーバーレス アーキテクチャは、サーバーフリーであると誤解されることが多いクラウド コンピューティング パラダイムです。基本的に、サーバー管理の責任を開発者からクラウド サービス プロバイダーに移行します。これにより、企業はバックエンド コードをクラウド インフラストラクチャ上で実行できるようになり、物理的なサーバー管理が不要になります。サーバーレス アーキテクチャのイベント駆動型アプローチは、オンデマンドで実行される小さなタスク固有の機能に依存しています。これらの機能は Function as a Service (FaaS) と呼ばれ、従量課金モデルとアプリケーションの需要に基づく動的なリソース スケーリングによってコスト効率を高めます。^{[49] [より適切なソースが必要]}

システムアーキテクチャ

システム アーキテクチャという用語は、もともとハードウェアとソフトウェアの両方で構成されるシステムのアーキテクチャに適用されていました。システム アーキテクチャが扱う主な関心事は、ソフトウェアとハ​​ードウェアを統合して、完全に正しく動作するデバイスを作成することです。もう 1 つの一般的な (より広い) 意味では、この用語は、技術的、社会技術的、または社会的な性質を持つ可能性のある複雑なシステムのアーキテクチャに適用されます。

エンタープライズアーキテクチャ

エンタープライズ アーキテクチャの目標は、「ビジネス ビジョンと戦略を効果的なエンタープライズに変換する」ことです。TOGAFやZachman Frameworkなどのエンタープライズアーキテクチャフレームワークでは、通常、異なるエンタープライズ アーキテクチャ レイヤーを区別します。用語はフレームワークによって異なりますが、多くの場合、少なくともビジネスレイヤー、アプリケーション(または情報)レイヤー、テクノロジレイヤーが区別されます。エンタープライズ アーキテクチャでは、これらのレイヤー間の調整が、通常はトップダウン アプローチで行われます。

• リチャーズ、マーク (2020)。ソフトウェアアーキテクチャの基礎:エンジニアリングアプローチ。オライリーメディア。ISBN 9781492043454。
• Len, Bass (2012)。『ソフトウェアアーキテクチャ実践』（第3版）。Addison - Wesley Professional。ISBN 9780321815736。- この本では、この分野の基本概念を取り上げています。テーマは、システムの品質特性を達成することに重点を置いています。
• クレメンツ、ポール (2010)。『ソフトウェア アーキテクチャのドキュメント化: ビューとその先(第 2 版)』。Addison-Wesley Professional。ISBN 9780321552686。- この本では、ソフトウェア アーキテクチャとは何かを説明し、UML やその他の表記法を使用して、複数のビューでドキュメント化する方法を示します。また、動作、ソフトウェア インターフェイス、および根拠のドキュメント化によってアーキテクチャ ビューを補完する方法についても説明します。この本には、ソフトウェア アーキテクチャ ドキュメント化の例を含む wiki が付属しています。
• Bell, Michael (2008)。Bell, Michael (編)。サービス指向モデリング: サービス分析、設計、アーキテクチャ。Wiley。doi :10.1002 / 9781119198864。ISBN 9780470255704。
• Shan, Tony; Hua, Winnie (2006年10 月)。「ソリューション アーキテクチャ メカニズム」。2006年 10 回 IEEE 国際エンタープライズ分散オブジェクト コンピューティング カンファレンス (EDOC'06)。pp. 23–32。doi :10.1109 / EDOC.2006.54。ISBN 978-0-7695-2558-7. S2CID  8361936。
• Garzás, Javier; Piattini, Mario (2005). 「マイクロアーキテクチャ設計知識のオントロジー」. IEEE Software . 22 (2): 28–33. doi :10.1109/MS.2005.26. S2CID  17639072.
• Fowler, Martin (2003年9 月)。「建築家は誰に必要か?」(PDF)。IEEEソフトウェア。20 (5) 。doi :10.1109/MS.2003.1231144。S2CID 356506  。
• Kazman, Rick (2003 年 5 月)。「アーキテクチャ、設計、実装」(PDF)。ソフトウェア エンジニアリング インスティテュート。2015年 9 月 21 日のオリジナルからアーカイブ(PDF) 。- 建築設計と詳細設計の違いについて。
• Kruchten, Philippe (1995). 「アーキテクチャ ブループリント - ソフトウェア アーキテクチャの「4+1」ビュー モデル」(PDF) . IEEE ソフトウェア. 12 (6): 42–50. arXiv : 2006.04975 . doi :10.1109/52.469759. S2CID  219558624. 2006-06-13 にオリジナルからアーカイブ(PDF)されました。
• Pautasso, Cesare (2020). ソフトウェアアーキテクチャ: ビジュアル講義ノート。LeanPub. p. 689。

ウィキメディア・コモンズには、ソフトウェアアーキテクチャに関連するメディアがあります。

Wikiquote にはソフトウェア アーキテクチャに関する引用があります。

• IBM Developerworks の説明
• カーネギーメロン大学(CMU)のソフトウェアエンジニアリング研究所(SEI)におけるソフトウェアアーキテクチャ定義のコレクション
• 国際 IT アーキテクト協会 (IASA Global)、旧称国際ソフトウェア アーキテクト協会 (IASA)
• SoftwareArchitecturePortal.org –ソフトウェア アーキテクチャに関するIFIP ワーキング グループ 2.10の Web サイト
• SoftwareArchitectures.com – 分野に関する独立した情報源
• ソフトウェア アーキテクチャ、Roy Fieldingの REST 論文の第 1 章
• 良い建築が悪くなるとき
• スパイラルアーキテクチャ駆動開発 -スパイラルモデルに基づくSDLCは、非効率的なアーキテクチャのリスクを軽減することを目的としています。
• ソフトウェアアーキテクチャの実際のケーススタディ