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

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

ソフトウェアシステムのアーキテクチャは、建物の建築に類似したメタファーです。[ 2 ]これは^{、システムと}開発プロジェクトの設計図として機能し、プロジェクト管理は後ほどこれを使用して、関係するチームや人々が実行する必要のあるタスクを抽出できます。

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

1. すべてはトレードオフだ
2. 「なぜ」は「どのように」よりも重要である

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

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

ソフトウェアアーキテクチャ設計は、ソフトウェアアプリケーション設計と対比されることが多い。アプリケーション設計は、必要な機能（システムが提供するサービス）をサポートするプロセスとデータの設計に焦点を当てるのに対し、ソフトウェアアーキテクチャ設計は、アプリケーションの機能が実現および実行され、システムの非機能要件を満たす形で機能が提供されるようなインフラストラクチャの設計に焦点を当てる。

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

ソフトウェアアーキテクチャは時間の経過とともに複雑化する傾向があります。ソフトウェアアーキテクトは、アーキテクチャを継続的に監視するために「適合度関数」を使用する必要があります。 ^{[ 4 ]}

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

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

ソフトウェアアーキテクチャと設計・要求工学の間には明確な区別はありません（下記の関連分野を参照）。これらはすべて、高レベルの意図から低レベルの詳細に至るまでの「意図の連鎖」の一部です。^{[ 12 ]： 18}

ソフトウェアアーキテクチャパターンは、システムレベルで繰り返し発生する問題に対する再利用可能で実績のある解決策であり、システムの全体構造、コンポーネント間の相互作用、および品質属性に関連する懸念事項に対処します。ソフトウェアアーキテクチャパターンは、ソフトウェアデザインパターンよりも高い抽象度で動作し、より広範なシステムレベルの課題を解決します。これらのパターンは通常システムレベルの懸念事項に影響を与えますが、アーキテクチャパターンとアーキテクチャスタイルの区別は曖昧になる場合があります。例としては、サーキットブレーカーがあります。^{[ 13 ] [ 14 ] [ 15 ]}

ソフトウェアアーキテクチャスタイルは、システム全体の構成を定義する高レベルの構造的組織であり、コンポーネントがどのように組織され、どのように相互作用し、それらの相互作用に対する制約を規定します。アーキテクチャスタイルには通常、コンポーネントとコネクタタイプの語彙、およびシステムのプロパティを解釈するための意味モデルが含まれます。これらのスタイルは、システム構成の最も粗粒度のレベルを表します。例としては、階層型アーキテクチャ、マイクロサービス、イベント駆動型アーキテクチャなどがあります。^{[ 13 ] [ 14 ] [ 15 ]}

アーキテクトが意思決定を行う際に、以下のようなアーキテクチャ上のアンチパターンが発生する可能性があります。これらのアンチパターンは、多くの場合、段階的に発生し、1つを解決すると別のアンチパターンが出現する可能性があります。^{[ 4 ]}

• アーキテクトは、誤った選択をすることを恐れて、アーキテクチャ上の決定を遅らせたり、避けたりすることがあります。これに対処するには、開発チームとの継続的かつ緊密な連携がしばしば必要となり、彼らのフィードバックに基づいてアーキテクチャ上の選択が調整されます。さらに、決定は通常「最後の責任ある瞬間」に行われ、決定を正当化し検証するのに十分な情報が確保されるとともに、分析麻痺を引き起こしチームの進捗を妨げる可能性のある不必要な遅延が回避されます。^{[ 4 ]}
• アーキテクチャ上の決定が忘れられたり、文書化されなかったり、理解されなかったりすると、別のアンチパターンが発生し、解決に至らない議論が繰り返されることになります。これは、アーキテクチャ上の決定を伝えるために電子メールが使用される場合によく発生します。これらの課題に対処するために、アーキテクトは通常、アーキテクチャ上の決定に関する単一の記録（通常はアーキテクチャ決定記録）に、技術的およびビジネス上の正当性（多くの場合、コスト、ユーザー満足度、市場投入までの時間に関連）の両方を提供します。この記録は、wiki などのアクセス可能なリポジトリで維持できます。電子メールによるコミュニケーションは、変更の性質とコンテキストに焦点を当て、中央集権的な記録へのリンクとともに、関連する利害関係者のみに向けられます。これにより、常に単一の更新された真実の情報源が確保されます。さらに、アーキテクチャ上の決定が具体的なビジネス価値を提供しない場合、またはビジネス価値がビジネス利害関係者と一致しない場合は、再検討が必要になる場合があります。^{[ 4 ]}

ソフトウェアアーキテクチャは、以下の特徴を示す。

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

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

品質重視:従来のソフトウェア設計アプローチ ( Jackson Structured Programmingなど) は、必要な機能とシステムを通るデータの流れによって推進されていましたが、現在の洞察^{[ 5 ] : 26–28}では、ソフトウェア システムのアーキテクチャは、耐障害性、後方互換性、拡張性、信頼性、保守性、可用性、セキュリティ、ユーザビリティなどの品質属性とより密接に関連しています。利害関係者の懸念は、多くの場合、これらの品質属性に関する要件に変換され、これらは非機能要件、機能外要件、動作要件、または品質属性要件などと呼ばれます。

繰り返し用いられるスタイル：建築設計と同様に、ソフトウェアアーキテクチャの分野では、繰り返し生じる懸念事項に対処するための標準的な方法が開発されてきました。これらの「標準的な方法」は、さまざまな抽象度レベルでさまざまな名称で呼ばれています。繰り返し用いられる解決策の一般的な用語としては、アーキテクチャスタイル^{[ 12 ]： 273–277}、タクティクス^{[ 5 ]： 70–72、}参照アーキテクチャ、アーキテクチャパターン[ ^{17 ] [ 18 ] [ 5 ]： 203–205などがあります。}

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

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

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

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

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

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

研究機関は、ソフトウェアアーキテクチャを学問分野として発展させる上で重要な役割を果たしてきた。カーネギーメロン大学のメアリー・ショーとデビッド・ガーランは、1996年に『ソフトウェアアーキテクチャ：新興分野の展望』という書籍を執筆し、コンポーネント、コネクタ、スタイルといったソフトウェアアーキテクチャの概念を提唱した。カリフォルニア大学アーバイン校のソフトウェア研究所は、ソフトウェアアーキテクチャ研究において、主にアーキテクチャスタイル、アーキテクチャ記述言語、動的アーキテクチャに重点を置いている。

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

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

建築上の意思決定には、十分な関連情報を収集し、決定の正当性を示し、決定とその根拠を文書化し、適切な利害関係者に効果的に伝えることが含まれます。^{[ 4 ]}

ソフトウェアアーキテクトの責任は、アーキテクチャ特性（非機能要件とも呼ばれる）をビジネス要件に合わせることです。例：^{[ 4 ]}

• 顧客満足度を高めるには、システムの可用性、耐障害性、セキュリティ、テスト容易性、復旧性、俊敏性、およびパフォーマンスが不可欠である。
• 合併・買収（M&A）を行うには、拡張性、スケーラビリティ、適応性、相互運用性が必要となる。
• 予算と時間の制約があるため、実現可能性と簡便性が求められる。
• 市場投入までの時間を短縮するには、保守性、テスト容易性、および展開容易性が不可欠である。

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

アーキテクチャ分析とは、提案されたシステムが動作する環境を理解し、システムの要件を決定するプロセスです。分析活動へのインプットまたは要件は、さまざまなステークホルダーから得られ、次のような項目が含まれます。

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

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

建築的合成または設計とは、建築物を創造するプロセスである。分析によって決定された建築的に重要な要件、設計の現状、およびあらゆる評価活動の結果に基づいて、設計が創造され、改良される。^{[ 29 ] [ 5 ]： 311-326}

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

アーキテクチャの進化とは、要件や環境の変化に対応するために、既存のソフトウェアアーキテクチャを維持・適応させるプロセスです。ソフトウェアアーキテクチャはソフトウェアシステムの基本的な構造を提供するものであるため、その進化と維持は必然的にその基本構造に影響を与えます。したがって、アーキテクチャの進化は、既存の機能やシステム動作を維持するだけでなく、新しい機能を追加することにも関わります。

アーキテクチャには、重要な支援活動が不可欠です。これらの支援活動は、ソフトウェアアーキテクチャの中核となるプロセス全体を通して行われます。具体的には、知識管理とコミュニケーション、設計上の推論と意思決定、そしてドキュメント作成などが含まれます。

ソフトウェアアーキテクチャは本質的に不確実性を扱い、アーキテクチャコンポーネントのサイズは、システムの結果にプラスにもマイナスにも大きな影響を与える可能性があります。ニール・フォードとマーク・リチャーズは、コンポーネントの特定と適切なサイズ決定という課題に対処するための反復的なアプローチを提案しています。この方法は、チームがシステムの動作と要件についてより繊細な理解を深めるにつれて、継続的な改善を重視します。^{[ 4 ]}

このアプローチは通常、いくつかの段階からなるサイクルを伴います。^{[ 4 ]}

• 高レベルのパーティショニング戦略が策定され、多くの場合、技術的またはドメインベースに分類されます。最小単位の展開可能な意味のある単位（「クオンタ」と呼ばれる）に関するガイドラインが定義されます。これらの基本的な決定は早期に行われますが、必要に応じてサイクル後半で再検討される可能性があります。
• 初期構成要素は、確立された戦略に基づいて特定される。
• 要件は、特定されたコンポーネントに割り当てられます。
• 各構成要素の役割と責任を分析し、明確性を確保し、重複を最小限に抑えます。
• 拡張性、耐障害性、保守性といったアーキテクチャ特性が評価される。
• コンポーネントは、開発チームからのフィードバックに基づいて再構成される場合があります。

このサイクルは一般的な枠組みとして機能し、さまざまな分野に適用できる。

• リチャーズ、マーク（2020）。ソフトウェアアーキテクチャの基礎：エンジニアリングアプローチ。オライリーメディア。ISBN 978-1-4920-4345-4。
• Len, Bass (2012).ソフトウェアアーキテクチャの実践（第3 版）. Addison-Wesley Professional . ISBN 978-0-321-81573-6。本書は、当該分野の基本概念を網羅的に解説しています。テーマは、システムの品質特性を実現することに重点を置いています。
• クレメンツ、ポール（2010）。ソフトウェアアーキテクチャのドキュメント化：ビューとその先（第2 版）。アディソン・ウェスリー・プロフェッショナル。ISBN 978-0-321-55268-6。本書では、ソフトウェアアーキテクチャとは何かを説明し、UMLなどの表記法を用いて複数の視点からアーキテクチャを文書化する方法を示します。また、アーキテクチャビューを動作、ソフトウェアインターフェース、および設計根拠に関するドキュメントで補完する方法についても解説します。本書には、ソフトウェアアーキテクチャのドキュメント例を掲載したWikiが付属しています。
• Bell, Michael (2008). Bell, Michael (編).サービス指向モデリング：サービス分析、設計、およびアーキテクチャ. Wiley. doi : 10.1002/9781119198864 . ISBN 978-0-470-25570-4。
• 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 . Bibcode : 2005ISoft..22b..28G . doi : 10.1109/MS.2005.26 . S2CID 17639072 . 
• ファウラー、マーティン（2003年9月）。「建築家は誰に必要なのか？」 （PDF ）。IEEE Software。20 （ 5）：11。Bibcode ：2003ISoft..20e..11F。doi ：10.1109/ MS.2003.1231144。S2CID 356506。 
• カズマン、リック（2003年5月）。「アーキテクチャ、設計、実装」（PDF）。ソフトウェアエンジニアリング研究所。2015年9月21日にオリジナルからアーカイブ（PDF） 。―建築設計と詳細設計の区別について。
• Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF) . IEEE Software . 12 (6): 42– 50. arXiv : 2006.04975 . doi : 10.1109/52.469759 . S2CID 219558624 . 2006年6月13日にオリジナルからアーカイブされた(PDF) 。 
• Pautasso, Cesare (2020).ソフトウェアアーキテクチャ：ビジュアル講義ノート. LeanPub. p.  689.
• Magee, J.、Dulay, N.、Eisenbach, S.、Kramer, J. (1995年9月)。分散ソフトウェアアーキテクチャの仕様記述。欧州ソフトウェアエンジニアリング会議（pp. 137-153）。ベルリン、ハイデルベルク：Springer Berlin Heidelberg。

• IBM DeveloperWorksに関する説明
• カーネギーメロン大学（CMU）ソフトウェアエンジニアリング研究所（SEI ）におけるソフトウェアアーキテクチャ定義集
• 国際ITアーキテクト協会（IASA Global）（旧称：国際ソフトウェアアーキテクト協会（IASA））
• SoftwareArchitecturePortal.org – IFIPワーキンググループ2.10（ソフトウェアアーキテクチャ）のウェブサイト
• SoftwareArchitectures.com は、2023年10月29日にWayback Machineにアーカイブされました。これは、この分野に関する独立した情報リソースです。
• ソフトウェアアーキテクチャ、ロイ・フィールディングのRESTに関する博士論文の第1章
• 優れた建築が悪くなる時
• スパイラルアーキテクチャ主導開発–スパイラルモデルに基づくSDLCは、非効率的なアーキテクチャのリスクを軽減することを目的としています。
• ソフトウェアアーキテクチャの実例ケーススタディ