ソフトウェア設計とソフトウェアアーキテクチャ[終了]

誰かがソフトウェア設計とソフトウェアアーキテクチャの違いを説明できますか？

すなわち; 誰かにあなたに「デザイン」を提示するように伝えた場合、彼らに何を提示することを期待しますか？同じことが「アーキテクチャ」にも言えます。

私の現在の理解は：

• 設計：システムの特定のモジュール/部分のUMLダイアグラム/フローチャート/単純なワイヤーフレーム（UI用）
• アーキテクチャ：コンポーネント図（システムのさまざまなモジュールが相互に通信し、他のシステムとどのように通信するかを示す）、使用する言語、パターン...？

私が間違っていたら訂正してください。ウィキペディアにhttp://en.wikipedia.org/wiki/Software_designとhttp://en.wikipedia.org/wiki/Software_architectureに関する記事があることを紹介しましたが、それらを正しく理解しているかどうかはわかりません。

あなたは正しいです。システムのアーキテクチャは、その「骨格」です。これは、システムの抽象化の最高レベルです。存在するデータストレージの種類、モジュールが相互にどのように相互作用するか、どのような回復システムが導入されているか。デザインパターンと同様に、MVC、3層のレイヤードデザインなどのアーキテクチャパターンがあります。

ソフトウェア設計とは、個々のモジュール/コンポーネントを設計することです。モジュールxの責任、機能は何ですか？クラスYの？それは何ができ、何ができないのですか？使用できるデザインパターンは何ですか？

つまり、ソフトウェアアーキテクチャはシステム全体の設計に関するものであり、ソフトウェア設計はモジュール/コンポーネント/クラスレベルに重点を置いています。

SDLC（ソフトウェア開発ライフサイクル）のいくつかの説明ではそれらは交換可能ですが、共通点はそれらが異なるということです。同時に、（1）段階、（2）責任の領域、（3）意思決定のレベルが異なります。

• アーキテクチャは全体像です。フレームワーク、言語、スコープ、目標、高レベルの方法論（Rational、Waterfall、アジャイル）の選択など）の選択。
• デザインは小さな絵です。コードの編成方法の計画。システムの異なる部分間の契約がどのように見えるか; プロジェクトの方法論と目標の継続的な実施。この段階で仕様が作成されます。

これらの2つの段階は、さまざまな理由で混ざり合っているように見えます。

1. 多くの場合、小規模なプロジェクトでは、計画をこれらの段階に分けるための十分なスコープがありません。
2. プロジェクトは、より大きなプロジェクトの一部である可能性があるため、両方の段階の一部がすでに決定されています。（すでに存在するデータベース、規約、標準、プロトコル、フレームワーク、再利用可能なコードなどがあります。）
3. SDLCについての新しい考え方（アジャイル方法論を参照）では、この従来のアプローチをいくらか再構成しています。設計（より少ない範囲のアーキテクチャ）は、SDLC全体で意図的に行われます。多くの場合、プロセス全体が何度も繰り返される反復が多くなります。
4. ソフトウェア開発は複雑であり、とにかく計画を立てることは困難ですが、クライアント/マネージャー/営業担当者は通常、途中で目標と要件を変更することにより、それを困難にします。計画であろうとなかろうと、設計およびアーキテクチャ上の決定さえも、プロジェクトの後半で行う必要があります。

責任の段階や領域が混ざり合って、いたるところに起こっているとしても、どのレベルの意思決定が行われているかを知ることは常に良いことです。（私たちはこれで永遠に続けることができます。私はそれを要約にしようとしています。）終わりに：プロジェクトに正式なアーキテクチャまたは設計段階/ AOR /ドキュメントがないように見えても、それは誰かが起こっているかどうかです意識してやっているかどうか。誰もアーキテクチャを決定しない場合、おそらく貧弱なデフォルトのアーキテクチャが発生します。同上デザイン。これらの概念を表す正式な段階がない場合、これらの概念はほとんどより重要です。

アーキテクチャは戦略的ですが、デザインは戦術的です。

アーキテクチャは、フレームワーク、ツール、プログラミングパラダイム、コンポーネントベースのソフトウェアエンジニアリング標準、高レベルの原則で構成されています。

デザインは、デザインパターン、プログラミングイディオム、リファクタリングなどのローカル制約に関係するアクティビティです。

私は自分で建築とデザインの簡単な区別を探していたときにこれを見つけました。
それらのこの見方についてどう思いますか：

• アーキテクチャは、私たちが構築している「もの」です。
• デザインは私たちが構築している「方法」です。

1. アーキテクチャとは、コンピュータまたはコンピュータベースのシステムの概念的な構造と論理的な編成を意味します。

   設計とは、システムまたはオブジェクトが作成される前の外観と機能、または動作を示すために作成された計画または図面を意味します。

2. コンポーネントを「設計」している場合は、より大きなシステムでのコンポーネントの動作を定義しています。

   同じコンポーネントを「設計」する場合は、内部での動作を定義します。

すべてのアーキテクチャは設計ですが、すべての設計がアーキテクチャであるとは限りません。

What一部のデザインで、How具体的な実装との交点であるWhatとHowアーキテクチャです。

アーキテクチャとデザインを区別するための画像：

アーキテクチャ的に重要ではない、つまり設計のアーキテクチャブランチに属さない設計決定もあります。たとえば、アルゴリズムの選択、データ構造の選択など、一部のコンポーネントの内部設計決定。

コンポーネントの境界の外側に表示されない設計上の決定は、コンポーネントの内部設計であり、アーキテクチャではありません。これらは、設計がシステムレベルのアーキテクチャによって課されるアーキテクチャ上の制約を破らない限り、システム設計者がモジュール設計者の裁量または実装チームに任せる設計上の決定です。

良いアナロジーを与えるリンク

私の言葉では、あなたは正しいと思います。

アーキテクチャとは、システム要件をシステム要素に割り当てることです。アーキテクチャに関する4つのステートメント：

1. 言語やパターンなど、機能以外の要件が導入される可能性があります。
2. コンポーネント、インターフェース、タイミングなどの間の相互作用を定義します。
3. 新しい機能は導入されません。
4. システムが実行することを目的とした（設計された）関数を要素に割り当てます。

システムの複雑さを細分化する場合、アーキテクチャはエンジニアリングの重要なステップです。

例：家について考えてみてください。キッチンには建築家は必要ありませんが（要素は1つしか含まれていません）、建物全体にはドアや屋根などの相互作用の定義が必要です。

設計は、関数の（提案された）実装の有益な表現です。これは、フィードバックを引き出し、関係者と話し合うことを目的としています。これは良い方法かもしれませんが、必須のエンジニアリング手順ではありません。

キッチンを設置する前にキッチンのデザインを確認しておくとよいでしょうが、調理要件に必須ではありません。

私がそれについて考えるなら、あなたは述べることができます：

• アーキテクチャは、より詳細な抽象化レベルのパブリック/エンジニア向けです
• 設計は、あまり詳細でない抽象化レベルでの公開を目的としています

私のリマインダー：

• 私たちは誰かに尋ねることなくデザインを変えることができます
• アーキテクチャを変更した場合、それを誰か（チーム、クライアント、利害関係者など）に伝える必要があります。

設計とアーキテクチャについて話し合うときは、次のルールを使用する必要があると思います。作成したソフトウェア画像の要素を1対1でプログラミング言語の構文構造にマッピングできる場合、アーキテクチャではなくてもデザインです。

したがって、たとえば、クラス図またはシーケンス図が表示されている場合は、クラス構文構成を使用して、クラスとその関係をオブジェクト指向プログラミング言語にマッピングできます。これは明らかにデザインです。さらに、これは、この議論がソフトウェアシステムを実装するために使用するプログラミング言語と関係があることを表にするかもしれません。Javaはオブジェクト指向プログラミング言語であるため、Javaを使用する場合は前の例が当てはまります。パッケージとその依存関係を示す図が思いついたら、それもデザインです。要素（この場合はパッケージ）をJava構文構造にマップできます。

ここで、Javaアプリケーションがモジュールに分割されており、各モジュールが一連のパッケージ（jarファイルデプロイメントユニットとして表されている）であり、モジュールとその依存関係、つまりアーキテクチャを含む図が表示されているとします。Java（少なくともJava 7までは）ではなく、モジュール（パッケージのセット）を構文構造にマップする方法はありません。また、この図がソフトウェアモデルの抽象化レベルの1つ上のステップを表していることに気付くかもしれません。パッケージ図の上（粗い粒子）の図は、Javaプログラミング言語で開発する場合のアーキテクチャビューを表します。一方、Modula-2で開発している場合、モジュール図はデザインを表します。

（http://www.copypasteisforword.com/notes/software-architecture-vs-software-designからの抜粋）

個人的に、私はこれが好きです：

「デザイナーはユーザーがボタンを押すとどうなるかを気にし、建築家は1万人のユーザーがボタンを押すとどうなるかを考えています。」

Mark CadeとHumphrey Sheilによる SCEA for Java™EEスタディガイド

私は多くの説明に同意します。基本的に、ソフトウェアシステムのアーキテクチャ設計と詳細設計の違いを認識しています。

設計者の目標は、開発に必要なだけ正確かつ具体的な仕様にすることですが、アーキテクトは基本的に、詳細設計を開始するために必要なだけシステムの構造とグローバル動作を指定することを目的としています。

優れたアーキテクトはハイパー仕様を防止します-アーキテクチャを過度に指定することはできませんが、（アーキテクチャ上の）決定は、処理する最もコストのかかるリスクを提示する側面に対してのみ確立され、その中にフレームワーク（「共通性」）を効果的に提供します詳細な設計、つまりローカル機能の多様性に取り組むことができます。

実際、アーキテクチャプロセスまたはライフサイクルはこのテーマに従っています-（アーキテクチャ的に）重要なビジネス要件の構造を概説し、より具体的な成果物の設計フェーズに詳細を残す適切なレベルの抽象化です。

建築はデザインですが、すべてのデザインが建築であるとは限りません。したがって、厳密に言えば、建築設計と非建築設計を区別しようとする方が理にかなっています。そして、違いは何ですか？場合によります！各ソフトウェアアーキテクトは、異なる答えを持っている場合があります（ymmv！）。「クラス図はアーキテクチャであり、シーケンス図は設計である」などの答えを見つけるために、ヒューリスティックを開発します。詳細については、DSAブックを参照してください。

アーキテクチャはデザインよりも抽象化レベルが高い、またはアーキテクチャは論理的でデザインは物理的であると言うのが一般的です。しかし、この概念は、一般に受け入れられているとはいえ、実際には役に立たない。抽象化の高低、論理と物理のどこに線を引きますか？場合によります！

だから、私の提案は：

• 単一の設計ドキュメントを作成します。
• このデザインドキュメントには、好きなように名前を付けてください。例：「ソフトウェアアーキテクチャ」、「ソフトウェア設計仕様」。
• このドキュメントをビューに分割し、別のビューの絞り込みとしてビューを作成できることを覚えておいてください。
• 相互参照またはハイパーリンクを追加して、ドキュメント内のビューをナビゲート可能にします
• 次に、デザインの概観が広くて浅い概要を示す高レベルのビューと、狭くても深いデザインの詳細を示す実装に近いビューが表示されます。
• マルチビューアーキテクチャドキュメントの例（こちら）をご覧ください。

以上のことをすべて述べた後、私たちが尋ねる必要があるより関連性の高い質問は、どれだけのデザインで十分かということです。つまり、（図や文章で）デザインの説明をやめて、コーディングに移すべきなのはいつですか。

そうですね。デザインはあなたがやろうとしていることであり、アーキテクチャはデザインの断片を結合する方法です。言語にとらわれない場合もありますが、通常は使用するテクノロジー（LAMP v Windows、Webサービスv RPCなど）を指定します。

プログラムまたはコンピューティングシステムのソフトウェアアーキテクチャは、システムの1つまたは複数の構造であり、ソフトウェアコンポーネント、それらのコンポーネントの外部から見えるプロパティ、およびコンポーネント間の関係を含みます。

（ウィキペディア、http：//en.wikipedia.org/wiki/Software_architectureから）

ソフトウェア設計は、ソフトウェアソリューションの問題解決と計画のプロセスです。ソフトウェアの目的と仕様が決定したら、ソフトウェア開発者は設計者を設計または採用して、ソリューションの計画を作成します。低レベルのコンポーネントとアルゴリズムの実装の問題、およびアーキテクチャのビューが含まれます。

（ウィキペディア、http：//en.wikipedia.org/wiki/Software_designから）

自分でもっと上手く言えなかったでしょう:)

パトリックカーチャーがそうであるように私は建築を見る-全体像。たとえば、建物に建築を提供したり、その構造サポート、窓、出入り口、排水などを表示したりできます。ただし、フロアレイアウトやキュービクルの位置などは「設計」していません。

そのため、建物を設計している間は、各オフィスのレイアウトを設計していません。ソフトウェアについても同じことが言えると思います。

レイアウトの設計は、「レイアウトの設計」と見ることもできますが...

良い質問...それらの間の線はほとんど鮮明な線ではありませんが、両方の用語を使用している場合、アーキテクチャは何かを構築または構築する方法に関するより技術的または構造的な決定、特に難しい決定を包含します（またはより難しい）実装後に変更するのに対し、デザインは後で簡単に変更できる決定（メソッド名、クラス<->ファイルの組織構造、デザインパターン、シングルトンと静的クラスのどちらを使用して特定の問題を解決するかなど）を包含しますなど）および/またはシステムまたはアプリケーションの外観または美的側面に影響する要素（ヒューマンインターフェイス、使いやすさ、ルックアンドフィールなど）

ソフトウェアアーキテクチャは、「アルゴリズムと計算のデータ構造を超えた問題に関係しています。

アーキテクチャは、具体的には…実装の詳細（アルゴリズムやデータ構造など）ではありません。アーキテクチャ設計には、通常OODによって提供されるよりも豊富な抽象のコレクションが含まれます（オブジェクト指向設計）。

設計は、設計要素のモジュール化と詳細なインターフェイス、それらのアルゴリズムと手順、およびアーキテクチャをサポートし、要件を満たすために必要なデータ型に関係しています。

「アーキテクチャ」は、「デザイン」の同義語として使用されることがよくあります（「ハイレベル」という形容詞が前に付いている場合があります）。また、多くの人は「アーキテクチャパターン」という用語を「設計パターン」の同義語として使用しています。

このリンクをチェックしてください。

アーキテクチャ、設計、実装という用語の定義

アーキテクチャ：
構造設計は、システムに技術的に重要な要件を実現する抽象化のより高いレベルで機能します。アーキテクチャは、さらなる設計のための基礎を築きます。

設計：
抽象化の各層での反復プロセスを通じて、アーキテクチャが行わないことを埋める技術。

アーキテクチャとデザインを分離する上での経験則として、私はこのペーパーが本当に気に入りました。

http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf

それは意図/局所性仮説と呼ばれています。非ローカルで意図的なソフトウェアの性質に関する記述は、アーキテクチャーによるものです。ローカルで意図的なステートメントはデザインです。

...ずっと昔、哲学者たちは遠く離れた場所で、1つと多くの違いを心配していました。建築とは、多くの人を必要とする関係性に関するものです。アーキテクチャにはコンポーネントがあります。デザインはコンテンツに関するものであり、コンテンツを必要とします。デザインには、特性、品質、特性があります。私たちは通常、デザインはアーキテクチャ内にあると考えています。二元論的思考は、多くを原始的なものとして与えます。ただし、アーキテクチャも設計の範囲内です。私たちの目の前にあるもの、つまり1つまたは多くのものを表示するために選択するのは、すべてです。

かなり主観的ですが、私の見解：

アーキテクチャ 他のシステムとの相互作用、ハードウェア要件、コンポーネント全体の設計、データフローなど、システムの全体的な設計。

設計 システム全体におけるコンポーネントの構成とフロー。これには、他のコンポーネントと対話するためのコンポーネントのAPIも含まれます。

ソフトウェアアーキテクチャは、より高いアーキテクチャレベルで識別されるビジネスや機能をアプリケーションに投影する必要がある場合に、システムレベルで使用するのが最適です。

たとえば、あなたのビジネスはトレーダーにとって「利益と損失」についてであり、あなたの主な機能は「ポートフォリオ評価」と「リスク計算」を含みました。

しかし、ソフトウェアアーキテクトが彼のソリューションを詳しく説明するとき、彼はそれを認識します：

「ポートフォリオ評価」は一つのアプリだけでは出来ません。次のような管理可能なプロジェクトで改良する必要があります。

• GUI
• ランチャー
• 発車係
• ...

（含まれる操作が非常に大きいため、共通のGUIで常に監視されている間、複数のコンピューターに分割する必要があるため）

ソフトウェア設計では、さまざまなアプリケーション、それらの技術的関係、およびそれらの内部サブコンポーネントを調べます。
最後のアーキテクチャレイヤー（「テクニカルアーキテクチャ」）が（テクニカルフレームワークまたはトランスバーサルコンポーネントの観点から）作業し、プロジェクトチーム（ビジネス機能の実装に重点を置いている）が開始するために必要な仕様を生成します。それぞれのプロジェクト。

誰かが船を造るなら、エンジン、船体、電気回路などが彼の「建築要素」になります。彼にとって、エンジン建設は「設計作業」になります。

エンジンの構築を別のチームに委任すると、「エンジンアーキテクチャ」が作成されます...

だから-それは抽象化または詳細のレベルに依存します。一人の建築は他の人のデザインかもしれません！

アーキテクチャは、「変更するのが難しい設計上の決定」です。

TDDを使用した後、つまり実際には設計が常に変更されることを意味しますが、この質問に苦労していることがよくありました。上記の定義は、Patterns of Enterprise Application Architecture、Martin Fowler から抜粋したものです。

つまり、アーキテクチャはシステムの言語、フレームワーク、ドメインに依存します。5分でJavaクラスからインターフェースを抽出できる場合、それはもはやアーキテクチャーの決定ではありません。

クリフノートバージョン：

設計：目的の製品の仕様に基づいてソリューションを実装します。

アーキテクチャ：設計をサポートする基盤/ツール/インフラストラクチャ/コンポーネント。

これは非常に広範な質問であり、多くの応答を引き起こします。

アーキテクチャとは、システムを構築するための設計パターンの集まりです。

デザインは、これらすべてを組み合わせるために使用される創造性だと思いますか？

ソフトウェア設計の歴史は長いですが、ソフトウェアアーキテクチャという用語はわずか20年前のものです。したがって、それは現在、成長する苦痛を経験しています。

学者は、アーキテクチャをソフトウェア設計のより大きな分野の一部と見なす傾向があります。Archは独自の分野であるという認識が高まっています。

実務家は、Archを戦略的であり、プロジェクトで元に戻すのにコストがかかる可能性がある高レベルの設計決定と見なす傾向があります。

Archとデザインの正確な境界は、ソフトウェアドメインによって異なります。たとえば、Webアプリケーションのドメインでは、レイヤードアーキテクチャが現在最も人気を得ています（Bizロジックレイヤー、データアクセスレイヤーなど）。このArchの下位レベルの部分は、設計と見なされます（クラス図、メソッドシグネチャなど）。 ）これは、組み込みシステム、オペレーティングシステム、コンパイラなどのドメインでは異なる定義になります。

アーキテクチャは高レベルの抽象的で論理的な設計ですが、ソフトウェア設計は低レベルの詳細で物理的な設計です。

また、http：//en.wikipedia.org/wiki/4%2B1_Architectural_View_Modelも参照してください 。

ロイトーマスフィールディングの論文でソフトウェアアーキテクチャとは何かについての定義と説明が好きです： アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計

ソフトウェアアーキテクチャとは、ソフトウェアシステムの動作のある段階におけるソフトウェアシステムのランタイム要素を抽象化したものです。システムは、多くの抽象化レベルと操作の多くのフェーズで構成され、それぞれ独自のソフトウェアアーキテクチャを備えています。

彼は「実行時の要素」と「抽象化のレベル」を強調しています。

「ソフトウェアアーキテクチャ」と「ソフトウェアデザイン」にはかなりの数の定義があり、どちらにも標準的な定義がないため、これに対する明確な答えはありません。

それについての良い考え方は、Len Bass、Paul Clements、Rick Kazmanによる「すべてのアーキテクチャはデザインであるが、すべてのデザインがアーキテクチャではない」[ソフトウェアアーキテクチャインプラクティス]という言葉です。（アーキテクチャには他のアクティビティが含まれる可能性があるため）私はそれに同意するかどうかはわかりませんが、アーキテクチャは設計の重要なサブセットを扱う設計アクティビティであるという本質を捉えています。

私のわずかに軽微な定義（SEI定義ページにあります））は、それが一連​​の決定であり、間違って行われた場合にプロジェクトがキャンセルされることです。

アーキテクチャ、設計、実装を概念として分離する有用な試みは、アムノンエデンとリックカズマンによって数年前に「アーキテクチャ、設計、実装」というタイトルのリサーチペーパーで行われました。こちらはhttp：//www.sei.cmu .edu / library / assets / ICSE03-1.pdf。彼らの言語は非常に抽象的ですが、単純に言えば、アーキテクチャは多くのコンテキストで使用できる設計であり、システム全体に適用されることを意図しており、設計は（err）多くのコンテキストで使用できるが特定の部分に適用される設計ですシステムの実装であり、実装はコンテキストに固有の設計であり、そのコンテキストに適用されます。

したがって、アーキテクチャ上の決定は、RPCではなくメッセージングを介してシステムを統合する決定である可能性があります（そのため、多くの場所で適用でき、システム全体に適用することを意図した一般的な原則です）、設計決定は、マスターを使用することになるかもしれませんシステムの入力要求処理モジュールの/ slaveスレッド構造（どこでも使用できる一般的な原則ですが、この場合は1つのモジュールでのみ使用されます）。最後に、実装の決定は、要求ルーターからセキュリティの責任を移動することです。リクエストマネージャーモジュールのリクエストハンドラー（そのコンテキストでのみ使用される、そのコンテキストに関連する決定）

これが役に立てば幸いです！