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

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

ソフトウェアアーキテクチャとは、ソフトウェアシステムの基本的な構造と、そのような構造やシステムを作成するための規律を指します。各構造は、ソフトウェア要素、それらの間の関係、および要素と関係の両方のプロパティで構成されます。[1]ソフトウェアシステムのアーキテクチャは、建物のアーキテクチャに類似した比喩です。[2]システムと開発プロジェクトの青写真として機能し、設計チームが実行するために必要なタスクをレイアウトします。[3]

ソフトウェアアーキテクチャとは、実装後に変更するのにコストがかかる基本的な構造上の選択を行うことです。ソフトウェアアーキテクチャの選択には、ソフトウェアの設計における可能性からの特定の構造オプションが含まれます。たとえば、スペースシャトルのロケットを制御するシステムには、非常に高速で信頼性が高いという要件がありました。したがって、適切なリアルタイムコンピューティング言語を選択する必要があります。さらに、信頼性の必要性を満たすために、プログラムの複数の冗長で独立して作成されたコピーを持ち、結果をクロスチェックしながらこれらのコピーを独立したハードウェアで実行することを選択できます。

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

Software_Architecture_Activities

スコープ

ソフトウェアアーキテクチャの範囲に関しては意見が異なります:[5]

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

ソフトウェアアーキテクチャと設計および要件エンジニアリングの間に明確な違いはありません(以下の関連フィールドを参照)。それらはすべて、高レベルの意図から低レベルの詳細までの「志向性の連鎖」の一部です。[11] :18 

特徴

ソフトウェアアーキテクチャは次のことを示しています。

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

関心の分離アーキテクトが複雑さを軽減するための確立された方法は、設計を推進する関心を分離することです。アーキテクチャのドキュメントは、さまざまな利害関係者の懸念に関連する個別の観点からアーキテクチャをモデル化して説明することにより、すべての利害関係者の懸念に対処することを示しています。[12]これらの個別の説明は、アーキテクチャビューと呼ばれます(たとえば、 4 + 1アーキテクチャビューモデルを参照)。

品質重視:従来のソフトウェア設計アプローチ(Jackson Structured Programmingなど)は、必要な機能とシステムを介したデータの流れによって推進されましたが、現在の洞察[4] :26–28 は、ソフトウェアシステムのアーキテクチャがより厳密であるということです。フォールトトレランス下位互換性拡張性信頼性保守性、可用性、セキュリティ、使いやすさなど品質属性に関連します利害関係者の懸念は、多くの場合、要件に変換されます非機能要件、機能外要件、行動要件、または品質属性要件 とさまざまに呼ばれるこれらの品質属性について。

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

概念の完全性:ソフトウェアシステムのアーキテクチャが、ソフトウェアシステムが何をすべきか、どのように行うべきかについての全体的なビジョンを表すという考えを表すために、1975年の著書The MythicalMan-MonthでFredBrooksによって導入された用語。このビジョンは、その実装から分離する必要があります。アーキテクトは「ビジョンのキーパー」の役割を引き受け、システムへの追加がアーキテクチャーと一致していることを確認し、概念の整合性を維持します。[15] :41–50 

認知的制約: コンピュータープログラマーのメルヴィン・コンウェイが1967年の論文で最初に行った観察では、システムを設計する組織は、これらの組織のコミュニケーション構造のコピーである設計を作成するように制約されています。概念の完全性と同様に、彼が「コンウェイの法則」と呼んでいる 彼のエレガントな古典人月の神話」の論文とアイデアを引用したときに、それをより多くの聴衆に紹介したのはフレッド・ブルックスでした。

モチベーション

ソフトウェアアーキテクチャは、複雑なシステムを「知的に把握できる」抽象化したものです。[4] :5–6 この抽象化には、いくつかの利点があります。

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

歴史

ソフトウェア設計と(市民)アーキテクチャの比較は、1960年代後半に最初に描かれましたが[18]、「ソフトウェアアーキテクチャ」という用語は、1990年代まで広く使用されていませんでした。[19]コンピュータサイエンスの分野は、その形成以来、複雑さに関連する問題に直面していた。[20]複雑さの初期の問題は、開発者が適切なデータ構造を選択し、アルゴリズムを開発し、関心の分離の概念を適用することによって解決されました「ソフトウェアアーキテクチャ」という用語は業界では比較的新しいものですが、この分野の基本原則はソフトウェアエンジニアリングによって散発的に適用されています。1980年代半ばからのパイオニア。システムのソフトウェアアーキテクチャをキャプチャして説明する初期の試みは不正確でまとまりがなく、多くの場合、一連のボックスアンドラインによって特徴付けられていました。[21]

概念としてのソフトウェアアーキテクチャは、1968年のEdsgerDijkstraと1970年代初頭のDavidParnasの研究に端を発しています。これらの科学者は、ソフトウェアシステムの構造が重要であり、構造を正しくすることが重要であることを強調しました。1990年代には、建築様式(パターン)、アーキテクチャ記述言語アーキテクチャドキュメント、および形式手法に焦点を当てた研究を行い、分野の基本的な側面を定義および体系化するための協調的な取り組みが行われました[22]

研究機関は、分野としてのソフトウェアアーキテクチャを促進する上で重要な役割を果たしてきました。カーネギーメロン大学のメアリーショーとデビッドガーランは、1996年に「ソフトウェアアーキテクチャ:新しい分野の展望」というタイトルの本を書き、コンポーネント、コネクタ、スタイルなどのソフトウェアアーキテクチャの概念を推進しました。カリフォルニア大学アーバイン校ソフトウェアアーキテクチャ研究研究所のソフトウェアアーキテクチャ研究への取り組みは、主にアーキテクチャスタイル、アーキテクチャ記述言語、および動的アーキテクチャに向けられています。

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

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

建築活動

ソフトウェアアーキテクトが実行する多くのアクティビティがあります。ソフトウェアアーキテクトは通常、プロジェクトマネージャーと協力し、アーキテクチャ上重要な要件について関係者と話し合い、ソフトウェアアーキテクチャを設計し、設計を評価し、設計者や関係者と通信し、アーキテクチャ設計を文書化します。[23]ソフトウェアアーキテクチャの設計には4つのコアアクティビティがあります。[24]これらのコアアーキテクチャアクティビティは、システムの進化全体と同様に、初期のソフトウェア開発ライフサイクルのさまざまな段階で繰り返し実行されます。

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

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

アーキテクチャの統合または設計は、アーキテクチャを作成するプロセスです。分析によって決定されたアーキテクチャ上重要な要件、設計の現在の状態、および評価アクティビティの結果を考慮して、設計が作成および改善されます。[24] [4] :311–326 

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

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

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

アーキテクチャ支援活動

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

  • 知識の管理とコミュニケーションは、ソフトウェアアーキテクチャの設計に不可欠な知識を調査および管理する行為です。ソフトウェアアーキテクトは単独では機能しません。彼らは、さまざまな利害関係者から、インプット、機能要件と非機能要件、および設計コンテキストを取得します。利害関係者にアウトプットを提供します。ソフトウェアアーキテクチャの知識は暗黙知であることが多く、利害関係者の頭に残っています。ソフトウェアアーキテクチャの知識管理活動とは、知識を見つけ、伝達し、保持することです。ソフトウェアアーキテクチャの設計の問題は複雑で相互に依存しているため、設計推論における知識のギャップがソフトウェアアーキテクチャの設計の誤りにつながる可能性があります。[23] [30]知識管理とコミュニケーション活動の例には、デザインパターンの検索、プロトタイピング、経験豊富な開発者と建築家への質問、同様のシステムの設計の評価、他の設計者や利害関係者との知識の共有、およびwikiページでの経験の文書化が含まれます。
  • 設計の推論と意思決定は、設計の決定を評価する活動です。このアクティビティは、3つのコアソフトウェアアーキテクチャアクティビティすべての基本です。[9] [31]これには、意思決定コンテキストの収集と関連付け、設計決定問題の定式化、ソリューションオプションの検索、および意思決定の前のトレードオフの評価が含まれます。このプロセスは、重要なアーキテクチャ要件とソフトウェアアーキテクチャの決定、およびソフトウェアアーキテクチャの分析、合成、評価を評価しながら、さまざまなレベルの決定粒度で行われます。推論アクティビティの例には、要件または設計が品質属性に与える影響の理解、設計が引き起こす可能性のある問題の質問、考えられるソリューションオプションの評価、およびソリューション間のトレードオフの評価が含まれます。
  • ドキュメントは、ソフトウェアアーキテクチャプロセス中に生成された設計を記録する行為です。システム設計は、システムのコード構造を示す静的ビュー、実行中のシステムのアクションを示す動的ビュー、および実行のためにシステムがハードウェアに配置される方法を示す配置ビューを含むいくつかのビューを使用して記述されます。 Kruchtenの4+ 1ビューは、ソフトウェアアーキテクチャを文書化するために一般的に使用されるビューの説明を示唆しています。[32] ソフトウェアアーキテクチャの文書化:Views and Beyondには、ビューの説明内で使用できる表記法の種類の説明があります。[1] 文書化活動の例としては、仕様の作成、システム設計モデルの記録、設計根拠の文書化、視点の開発、ビューの文書化があります。

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

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

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

アーキテクチャ記述言語

アーキテクチャ記述言語(ADL)は、ソフトウェアアーキテクチャ( ISO / IEC / IEEE 42010 )を記述するために使用される表現手段です1990年代以降、AADL(SAE標準)、Wright(Carnegie Mellonが開発)、Acme(Carnegie Mellonが開発)、xADL(UCIが開発)、DarwinImperial College Londonが開発)など、多くの特殊用途のADLが開発されています。 、DAOP-ADL(マラガ大学が開発)、SBC-ADL(国立中山大学が開発)、ByADL(カリフォルニア大学アーバイン校)。

アーキテクチャの視点

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

アーキテクチャフレームワーク

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

建築様式とパターン

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

伝統的な建築建築に続いて、「ソフトウェア建築様式」は、それを際立たせる特徴によって特徴付けられる特定の建築方法です」(建築様式)。

建築様式は次のことを定義します。構造組織のパターンに関するシステムのファミリー。コンポーネントとコネクタの語彙。それらを組み合わせる方法に制約があります。[33]

建築様式は、選択された望ましい品質を誘発するために建築に適用される設計決定と制約の再利用可能な「パッケージ」です。[34]

その中には、多くの認識されているアーキテクチャパターンとスタイルがあります。

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

ソフトウェアアーキテクチャとアジャイル開発

また、ソフトウェアアーキテクチャが、特にアジャイルソフトウェア開発の支持者の間で、ビッグデザインアップフロントが多すぎるという懸念もあります先行設計と敏捷性のトレードオフのバランスをとるために、多くの方法が開発されてきました[36]。これには、「十分な」アーキテクチャ基盤が構築される「基盤」フェーズを義務付けるアジャイル手法DSDMが含まれます。IEEEソフトウェアは、敏捷性とアーキテクチャの間の相互作用に特別な問題を捧げました。

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

ソフトウェアアーキテクチャの侵食(または「崩壊」)とは、ソフトウェアシステムの実装で実現された、計画されたアーキテクチャと実際のアーキテクチャの間に見られるギャップを指します。[37]ソフトウェアアーキテクチャの侵食は、実装の決定が計画どおりのアーキテクチャを完全に達成していないか、そうでなければそのアーキテクチャの制約または原則に違反している場合に発生します。[2]

例として、厳密に階層化されたシステムを考えてみましょう。各層は、そのすぐ下の層によって提供されるサービスのみを使用できます。この制約を遵守しないソースコードコンポーネントは、アーキテクチャ違反を表します。修正されない場合、そのような違反はアーキテクチャをモノリシックブロックに変換し、理解可能性、保守性、および進化可能性に悪影響を与える可能性があります。

侵食に対処するために、さまざまなアプローチが提案されてきました。「ツール、技術、プロセスを含むこれらのアプローチは、主に3つの一般的なカテゴリに分類され、アーキテクチャの侵食を最小限に抑え、防止し、修復しようとします。これらの幅広いカテゴリ内で、各アプローチは、侵食に取り組みます。これらは、プロセス指向のアーキテクチャ適合、アーキテクチャ進化管理、アーキテクチャ設計の実施、アーキテクチャと実装のリンク、自己適応、およびリカバリ、検出、調整で構成されるアーキテクチャ復元技術です。」[38]

アーキテクチャ違反を検出するには、反射モデルとドメイン固有言語の2つの主要な手法があります。反射モデル(RM)手法は、システムのアーキテクトによって提供された高レベルのモデルをソースコードの実装と比較します。アーキテクチャ上の制約の指定とチェックに重点を置いた ドメイン固有言語もあります。

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

ソフトウェアアーキテクチャの回復(または再構築、またはリバースエンジニアリング)には、ソフトウェアシステムのアーキテクチャを、その実装やドキュメントなどの利用可能な情報から明らかにするための方法、手法、およびプロセスが含まれます。古くなった、または古くなったドキュメントやアーキテクチャの侵食に直面して、情報に基づいた決定を下すには、アーキテクチャの回復が必要になることがよくあります 。つまり、実装と保守の決定は、想定されるアーキテクチャとは異なります。[39]静的プログラム分析としてソフトウェアアーキテクチャを回復するための慣行が存在しますこれは、ソフトウェアインテリジェンスの実践 でカバーされる主題の一部です。

関連フィールド

デザイン

建築はデザインですが、すべてのデザインが建築であるとは限りません。[1]実際には、アーキテクトは、ソフトウェアアーキテクチャ(アーキテクチャ設計)と詳細設計(非アーキテクチャ設計)の間に線を引く人です。区別を形式化する試みがなされてきましたが、すべての場合に適合する規則やガイドラインはありません。Intension / Locality Hypothesis [40]よると、アーキテクチャ設計と詳細設計の区別はLocality Criterion [40]によって定義され、ソフトウェア設計に関するステートメントは、プログラムがそれを満たさないプログラムに拡張することができます。たとえば、この原則に基づいて構築されたプログラムは、たとえばピアツーピアノード を追加することにより、クライアントサーバーではないプログラムに拡張できるため、クライアントサーバースタイルはアーキテクチャ(戦略的)です。

要求工学

要件エンジニアリングとソフトウェアアーキテクチャは補完的なアプローチと見なすことができます。ソフトウェアアーキテクチャは「ソリューションスペース」または「方法」を対象としていますが、要件エンジニアリングは「問題スペース」または「何」に対応しています。[41]要件エンジニアリングには、要件の引き出し交渉仕様検証文書化、および管理が含まれます要件エンジニアリングとソフトウェアアーキテクチャはどちらも、利害関係者の懸念、ニーズ、要望を中心に展開しています。

要求工学とソフトウェアアーキテクチャの間にはかなりの重複があります。たとえば、 「入力(目標、制約など)は通常、明確に定義されておらず、発見されるか、より良くなるだけである」と結論付ける5つの産業用ソフトウェアアーキテクチャ手法の研究によって証明されています。アーキテクチャが出現し始めると理解されます」そして「ほとんどのアーキテクチャの懸念はシステムの要件として表されますが、それらには義務付けられた設計上の決定も含まれる可能性があります」[24]要するに、必要な動作はソリューションアーキテクチャに影響を与え、それが新しい要件を導入する可能性があります。[42]ツインピークスモデル[43]などのアプローチは、相乗効果を活用することを目的としています要件とアーキテクチャの関係。

他のタイプの「アーキテクチャ」

コンピュータアーキテクチャ
コンピュータアーキテクチャは、 CPU(またはプロセッサ)バスメモリなどのハードウェアコンポーネントを連携させるという観点から、コンピュータシステムの内部構造を対象としています
システムアーキテクチャ
システムアーキテクチャという用語は、元々、ハードウェアとソフトウェアの両方で構成されるシステムのアーキテクチャに適用されていましたシステムアーキテクチャが取り組む主な関心事は、ソフトウェアとハ​​ードウェアを完全で正しく機能するデバイスに統合することです。別の一般的な(はるかに広い)意味では、この用語は、技術的、社会技術的、または社会的性質複雑なシステムのアーキテクチャに適用されます。
エンタープライズアーキテクチャ
エンタープライズアーキテクチャの目標は、「ビジネスビジョンと戦略を効果的なエンタープライズに変換する」ことです。TOGAFやZachmanFrameworkなどのエンタープライズアーキテクチャフレームワーク、通常、異なるエンタープライズアーキテクチャレイヤーを区別します。用語はフレームワークごとに異なりますが、多くの場合、少なくともビジネスレイヤーアプリケーション(または情報レイヤーテクノロジーレイヤーの区別が含まれていますエンタープライズアーキテクチャは、特にトップダウンアプローチで、これらのレイヤー間の調整に対応します。

も参照してください

参考文献

  1. ^ a b c クレメンツ、ポール; フェリックス・バックマン; レンバス; デビッド・ガーラン; ジェームズアイバーズ; リードリトル; パウロ・メルソン; ロバートノード; ジュディススタッフォード(2010)。ソフトウェアアーキテクチャの文書化:ビューとその先、第2版ボストン:アディソン-ウェスリー。ISBN 978-0-321-55268-6
  2. ^ a b c d ペリー、DE; ウルフ、AL(1992)。「ソフトウェアアーキテクチャの研究のための基礎」(PDF)ACMSIGSOFTソフトウェアエンジニアリングノート17(4) 40。CiteSeerX10.1.1.40.5174土井10.1145 /141874.141884S2CID628695_   
  3. ^ 「ソフトウェアアーキテクチャ」www.sei.cmu.edu 2018年7月23日取得
  4. ^ a b c d e f g h i j Bass、Len; ポールクレメンツ; リック・カズマン(2012)。ソフトウェアアーキテクチャの実践、第3版ボストン:アディソン-ウェスリー。ISBN 978-0-321-81573-6
  5. ^ SEI(2006)。「ソフトウェアアーキテクチャをどのように定義しますか?」2012年9月12日取得
  6. ^ Garlan&Shaw(1994)。「ソフトウェアアーキテクチャ入門」(PDF)2012年9月13日取得
  7. ^ a b ファウラー、マーティン(2003)。「デザイン–建築家が必要なのは誰ですか?」IEEEソフトウェア20(5):11–44。土井10.1109 /MS.2003.1231144S2CID356506_ 
  8. ^ ISO / IEC / IEEE 42010:「アーキテクチャ」の定義Iso-architecture.org。2013年7月21日に取得。
  9. ^ a b Jansen、A。; ボッシュ、J。(2005)。「一連のアーキテクチャ設計決定としてのソフトウェアアーキテクチャ」。ソフトウェアアーキテクチャに関する第5回作業IEEE / IFIP会議(WICSA'05)p。109. CiteSeerX10.1.1.60.8680_ 土井10.1109 /WICSA.2005.61ISBN  978-0-7695-2548-8S2CID13492610 _
  10. ^ アリ・ババール、ムハンマド; Dingsoyr、Torgeir; ラゴ、パトリシア; van Vliet、ハンス(2009)。ソフトウェアアーキテクチャナレッジマネジメントドルドレヒトハイデルベルクロンドンニューヨーク:スプリンガー。ISBN 978-3-642-02373-6
  11. ^ a b c ジョージ・フェアバンクス(2010)。ちょうど十分なソフトウェアアーキテクチャマーシャル&ブレイナード。
  12. ^ a b ISO / IEC / IEEE(2011)。「ISO / IEC / IEEE 42010:2011システムおよびソフトウェアエンジニアリング–アーキテクチャの説明」2012年9月12日取得
  13. ^ Muller、Gerrit(2007年8月20日)。「リファレンスアーキテクチャ入門書」(PDF)ガウディのサイト2015年11月13日取得
  14. ^ アンゲロフ、サムイル; グレフェン、ポール; グリーフホースト、ダニー(2009)。「ソフトウェア参照アーキテクチャの分類:それらの成功と有効性の分析」。Proc。WICSA / ECSA 2009の:141–150。CiteSeerX10.1.1.525.7208_ 土井10.1109 /WICSA.2009.5290800ISBN  978-1-4244-4984-2S2CID10417628 _
  15. ^ Brooks、Jr.、Frederick P.(1975)。The Mythical Man-Month –ソフトウェアエンジニアリングに関するエッセイアディソン-ウェスリー。ISBN 978-0-201-00650-6
  16. ^ a b Obbink、H。; Kruchten、P。; Kozaczynski、W。; Postema、H。; ラン、A。; ドミニク、L。; カズマン、R。; ヒリアード、R。; Tracz、W。; Kahane、E。(2002年2月6日)。「ソフトウェアアーキテクチャのレビューと評価(SARA)レポート」(PDF)2015年11月1日取得
  17. ^ Poort、Eltjo; van Vliet、ハンス(2012年9月)。「RCDA:リスクおよびコスト管理の分野としての設計」ジャーナルオブシステムズアンドソフトウェア85(9):1995–2013。土井10.1016 /j.jss.2012.03.071
  18. ^ P。ナウア; B.ランデル編 (1969)。「ソフトウェアエンジニアリング:1968年10月7〜11日、ドイツのガルミッシュで開催されたNATO科学委員会が主催する会議の報告」(PDF)ブリュッセル:NATO、科学部2012年11月16日取得
  19. ^ P. Kruchten; H.オブビンク; J.スタッフォード(2006)。「ソフトウェアアーキテクチャの過去、現在、そして未来」。IEEEソフトウェア23(2): 22。doi 10.1109 /MS.2006.59S2CID2082927_ 
  20. ^ ウォータールー大学(2006)。「コンピュータサイエンスの非常に簡単な歴史」2006年9月23日取得
  21. ^ ソフトウェアエンジニアリングに関するIEEEトランザクション(2006)。「ソフトウェアアーキテクチャ特集号の紹介」。土井10.1109 /TSE.1995.10003 {{cite journal}}: Cite journal requires |journal= (help)
  22. ^ Garlan&Shaw(1994)。「ソフトウェアアーキテクチャ入門」(PDF)2006年9月25日取得
  23. ^ a b Kruchten、P。(2008)。「ソフトウェアアーキテクトは実際に何をしているのですか?」ジャーナルオブシステムズアンドソフトウェア81(12):2413-2416。土井10.1016 /j.jss.2008.08.025
  24. ^ a b c クリスティン・ホフマイスター; フィリップ・クルーシュテン; ロバートL.ノード; ヘンクオブビンク; アレクサンダーラン; ピエールアメリカ(2007)。「5つの産業的アプローチから派生したソフトウェアアーキテクチャ設計の一般的なモデル」。ジャーナルオブシステムズアンドソフトウェア80(1):106–126。土井10.1016 /j.jss.2006.05.024
  25. ^ a b ISO / IEC(2011)。「ISO / IEC25010:2011システムおよびソフトウェアエンジニアリング–システムおよびソフトウェアの品質要件と評価(SQuaRE)–システムおよびソフトウェアの品質モデル」2012年10月8日取得
  26. ^ Osterwalder and Pigneur(2004)。「e-ビジネスモデルのオントロジー」(PDF)E-ビジネスモデルからの価値創造pp。65–97。CiteSeerX10.1.1.9.6922_ 土井10.1016 / B978-075066140-9 / 50006-0ISBN   9780750661409S2CID14177438 _ 2018年11月17日にオリジナル (PDF)からアーカイブされました
  27. ^ チェン、リアンピン; アリババール、ムハンマド; Nuseibeh、Bashar(2013)。「アーキテクチャ的に重要な要件の特徴づけ」。IEEEソフトウェア30(2):38–45。土井10.1109 /MS.2012.174hdl10344/3061S2CID17399565_ 
  28. ^ Woods、E。(2012)。「TARAを使用した産業建築評価」。ジャーナルオブシステムズアンドソフトウェア85(9):2034〜2047。土井10.1016 /j.jss.2012.04.055S2CID179244_ 
  29. ^ マランツァーノ、JF; Rozsypal、SA; ジマーマン、GH; ワーンケン、GW; Wirth、PE; ワイス、DM(2005)。「アーキテクチャレビュー:実践と経験」。IEEEソフトウェア22(2): 34。doi 10.1109 /MS.2005.28S2CID11697335_ 
  30. ^ マサチューセッツ州ババール; Dingsøyr、T。; Lago、P。; Vliet、H。van(2009)ソフトウェアアーキテクチャ知識管理:理論と実践(編)、初版スプリンガー。ISBN 978-3-642-02373-6
  31. ^ 唐、A。; ハン、J。; Vasa、R。(2009)。「ソフトウェアアーキテクチャ設計の推論:改善された方法論サポートの事例」。IEEEソフトウェア26(2): 43。doi 10.1109 /MS.2009.46hdl1959.3 / 51601S2CID12230032_ 
  32. ^ クルーシュテン、フィリップ(1995)。「アーキテクチャの青写真–ソフトウェアアーキテクチャの「4 + 1」ビューモデル」(PDF)IEEEソフトウェア12(6):42–50。arXiv2006.04975土井10.1109 /52.469759
  33. ^ a b ショー、メアリー; ガーラン、デビッド(1996)。ソフトウェアアーキテクチャ:新たな分野の展望プレンティスホール。ISBN 978-0-13-182957-2
  34. ^ UCIソフトウェアアーキテクチャ研究– UCIソフトウェアアーキテクチャ研究:建築様式Isr.uci.edu。2013年7月21日に取得。
  35. ^ a b 第3章:アーキテクチャパターンとスタイルMsdn.microsoft.com。2013年7月21日に取得。
  36. ^ ベーム、バリー; ターナー、リチャード(2004)。敏捷性と規律のバランスをとるアディソン-ウェスリー。ISBN 978-0-321-18612-6
  37. ^ Terra、R.、MT Valente、K。Czarnecki、and RS Bigonha、 "Recommending Refactorings to Reverse Software Architecture Erosion"、16th European Conference on Software Maintenance and Reengineering、2012。http: //gsd.uwaterloo.ca/sites/ default / files / Full%20Text.pdf
  38. ^ de Silva、L。; Balasubramaniam、D。(2012)。「ソフトウェアアーキテクチャの侵食の制御:調査」。ジャーナルオブシステムズアンドソフトウェア85(1):132–151。土井10.1016 /j.jss.2011.07.036
  39. ^ Lungu、M。「ソフトウェアアーキテクチャの回復」、ルガーノ大学、2008年 。http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  40. ^ abアムノン H.エデン; リック・カズマン(2003)。「アーキテクチャ設計の実装」(PDF)2007年9月28日にオリジナル(PDF)からアーカイブされました
  41. ^ C。シェカラン; D.ガーラン; M.ジャクソン; NRミード; C.ポッツ; HB Reubenstein(1994)。「要求工学におけるソフトウェアアーキテクチャの役割」。要件エンジニアリングに関するIEEE国際会議の議事録:239–245。土井10.1109 /ICRE.1994.292379ISBN 978-0-8186-5480-0S2CID3129363 _
  42. ^ Remco C. de Boer、ハンスファンフリート(2009)。「要件とアーキテクチャの類似性について」。ジャーナルオブシステムズアンドソフトウェア82(3):544–550。CiteSeerX10.1.1.415.6023_ 土井10.1016 /j.jss.2008.11.185 
  43. ^ Bashar Nuseibeh(2001)。「要件とアーキテクチャを織り交ぜる」(PDF)コンピューター34(3):115–119。土井10.1109 /2.910904

さらに読む

外部リンク