ソフトウェア設計とソフトウェア アーキテクチャの違いを誰か説明できますか?
すなわち; あなたが誰かに「デザイン」を提示するように言ったら、彼らは何を提示することを期待しますか? 「建築」も同様です。
私の現在の理解は次のとおりです。
私が間違っている場合は修正してください。ウィキペディアにはhttp://en.wikipedia.org/wiki/Software_designとhttp://en.wikipedia.org/wiki/Software_architectureの記事があることを参照しましたが、それらを正しく理解しているかどうかはわかりません。
そうです、そうです。システムのアーキテクチャは、その「スケルトン」です。これは、システムの抽象化の最高レベルです。どのような種類のデータ ストレージが存在するか、モジュールがどのように相互作用するか、どのような復旧システムが導入されているか。デザイン パターンと同様に、MVC、3 層レイヤー デザインなどのアーキテクチャ パターンがあります。
ソフトウェア設計とは、個々のモジュール/コンポーネントを設計することです。モジュール x の責任、機能は何ですか? Yクラス？何ができて、何ができないのでしょうか? どのようなデザインパターンを使用できますか?
要するに、ソフトウェア アーキテクチャはシステム全体の設計に関するものであり、ソフトウェア設計はモジュール/コンポーネント/クラス レベルに重点を置いています。
SDLC (ソフトウェア開発ライフ サイクル)の一部の記述では、それらは互換性がありますが、それらは別個のものであるというのが一般的な意見です。それらは同時に、(1)段階、(2)責任範囲、(3)意思決定のレベルが異なります。
これらの 2 つの段階は、さまざまな理由で混ざり合って いるように見えます。
責任の段階や領域が混ざり合ってあちこちで発生する場合でも、どのレベルの意思決定が行われているかを知ることは常に良いことです. (私たちはこれを永遠に続けることができます. 私はそれを要約しておくようにしています.) 最後に: あなたのプロジェクトに正式な建築または設計段階/AOR/ドキュメンテーションがないように見えても、誰かが意識的にするかしないか。誰もアーキテクチャーをやろうと決心しなければ、デフォルトのものが起こり、おそらく貧弱です。デザインについても同様です。これらの概念は、それらを表す正式な段階がない場合、より重要になります。
アーキテクチャは戦略的ですが、デザインは戦術的です。
アーキテクチャは、フレームワーク、ツール、プログラミング パラダイム、コンポーネント ベースのソフトウェア エンジニアリング標準、高レベルの原則で構成されます。
デザインは、デザインパターン、プログラミングイディオム、リファクタリングなどのローカルな制約に関係する活動です。
私自身、アーキテクチャとデザインの単純な区別を探していたときにこれを見つけました。
このような見方についてどう思いますか。
アーキテクチャとは、コンピューターまたはコンピューター ベースのシステムの概念的な構造と論理的な編成を意味します。
デザインとは、システムや物が作られる前に、外観や機能、仕組みを示すために作成された計画や図面を意味します。
コンポーネントを「設計」している場合は、より大きなシステムでの動作を定義しています。
同じコンポーネントを「設計」している場合は、内部でどのように動作するかを定義しています。
すべてのアーキテクチャはデザインですが、すべてのデザインがアーキテクチャではありません。
Whatpart は設計、は具体的な実装であり、とはアーキテクチャHowの交差点です。WhatHow
アーキテクチャとデザインを区別するためのイメージ:
アーキテクチャ的に重要ではない、つまり設計のアーキテクチャ ブランチに属さない設計上の決定もあります。たとえば、一部のコンポーネントの内部設計の決定、アルゴリズムの選択、データ構造の選択などです。
コンポーネントの境界の外に見えない設計上の決定は、コンポーネントの内部設計であり、アーキテクチャには関係ありません。これらは、設計がシステム レベル アーキテクチャによって課されるアーキテクチャ上の制約を破らない限り、システム アーキテクトがモジュール設計者の裁量または実装チームに任せる設計上の決定です。
よく似たリンク
私自身の言葉で言えば、あなたは正しいと思います。
アーキテクチャとは、システム要件をシステム要素に割り当てることです。アーキテクチャに関する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万人のユーザーがボタンを押したときに何が起こるかを懸念しています。」
SCEAforJava™EE学習ガイドMarkCadeとHumphreySheilによる
私は多くの説明に同意します。基本的に、ソフトウェア システムのアーキテクチャ設計と詳細設計の違いを認識しています。
設計者の目標は、仕様を開発に必要なだけ正確かつ具体的にすることです。アーキテクトは基本的に、システムの構造とグローバルな動作を、詳細な設計を開始するために必要なだけ指定することを目的としています。
優れたアーキテクトは過剰な仕様を防ぎます - アーキテクチャは過度に指定されるべきではありませんが、対処するのに最もコストのかかるリスクを提示する側面に対してのみ (アーキテクチャの) 決定が確立され、フレームワーク (「共通性」) を効果的に提供する必要があります。詳細な設計、つまりローカル機能の可変性に取り組むことができます。
実際、アーキテクチャ プロセスまたはライフサイクルはまさにこのテーマに従います。つまり、(アーキテクチャ上) 重要なビジネス要件の構造を概説するための適切なレベルの抽象化であり、より具体的な成果物の設計フェーズに詳細を残します。
建築はデザインですが、すべてのデザインが建築であるとは限りません。したがって、厳密に言えば、建築設計と非建築設計を区別しようとする方が理にかなっています。そして、違いは何ですか？場合によります！各ソフトウェア アーキテクトは異なる答えを持っている可能性があります (ymmv!)。「クラス図はアーキテクチャであり、シーケンス図は設計である」などの答えを導き出すためのヒューリスティックを開発します。詳細については、 DSA ブックを参照してください。
アーキテクチャは設計よりも高い抽象化レベルにある、またはアーキテクチャは論理的で設計は物理的であるとよく言われます。しかし、この概念は、一般的に受け入れられているとはいえ、実際には役に立ちません。高度な抽象化と低次の抽象化の間、論理と物理の間のどこに線を引きますか? 場合によります！
したがって、私の提案は次のとおりです。
以上のことをすべて述べた後...私たちが尋ねる必要があるより関連性の高い質問は、どのくらいのデザインで十分かということです。つまり、設計の説明 (図または散文) をやめて、コーディングに移る必要があるのはいつですか?
アーキテクチャ:
技術的に重要な要件をシステムに実現する、より高いレベルの抽象化での構造設計作業。アーキテクチャは、さらなる設計の基礎を築きます。
デザイン:
抽象化の各レイヤーでの反復プロセスを通じて、アーキテクチャーが行わないことを埋める技術。
ええ、それは私には正しいように聞こえます。設計はあなたがやろうとしていることであり、アーキテクチャは設計の断片を結合する方法です. 言語にとらわれない可能性がありますが、通常は使用するテクノロジを指定します。つまり、LAMP v Windows、Web サービス v RPC です。
...遠い昔、哲学者たちは一と多の区別を心配していました。建築とは関係性であり、それには多くが必要です。アーキテクチャにはコンポーネントがあります。デザインはコンテンツに関するものであり、それにはコンテンツが必要です。デザインには特性、品質、特性があります。私たちは通常、デザインは建築の中にあると考えています。二元論的思考は、多くのものを原始的なものとして与えます。しかし、建築もデザインの中にあります。目の前にあるものをどのように見るかがすべてです。
アーキテクチャを設計から分離するための経験則として、このペーパーが本当に気に入りました。
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
これは、意図/局所性仮説と呼ばれます。非ローカルで意図的なソフトウェアの性質に関する記述は、アーキテクチャに関するものです。ローカルで内在的なステートメントはデザインです。
良い質問です...それらの間の境界線はほとんど明るく鋭い線ではありませんが、私見ですが、両方の用語を使用している場合、アーキテクチャには、何かを構築または構築する方法に関するより技術的または構造的な決定、特に困難な決定が含まれます (設計には、後で簡単に変更できる決定 (メソッド名、クラス <-> ファイルの組織構造、設計パターン、特定の問題を解決するためにシングルトンを使用するか静的クラスを使用するかなど) が含まれます。など) および/またはシステムまたはアプリケーションの外観または美的側面に影響を与えるもの (ヒューマン インターフェイス、使いやすさ、ルック アンド フィールなど)
プログラムまたはコンピューティング システムのソフトウェア アーキテクチャは、ソフトウェア コンポーネント、それらのコンポーネントの外部から見えるプロパティ、およびそれらの間の関係で構成されるシステムの構造です。
(ウィキペディアからhttp://en.wikipedia.org/wiki/Software_architecture )
ソフトウェア設計は、問題を解決し、ソフトウェア ソリューションを計画するプロセスです。ソフトウェアの目的と仕様が決定された後、ソフトウェア開発者はソリューションの計画を作成するために設計するか、設計者を雇用します。低レベルのコンポーネントとアルゴリズムの実装の問題、およびアーキテクチャ ビューが含まれます。
(ウィキペディアよりhttp://en.wikipedia.org/wiki/Software_design )
自分でそれをうまく言えなかったでしょう:)
私は建築をパトリック・ケルヒャーと同じように見ています - 全体像です。たとえば、建物にアーキテクチャを提供し、その構造サポート、窓、出入り口、排水などを表示できます。ただし、フロア レイアウト、キュービクルの位置などは「設計」していません。
つまり、建物を設計したとしても、各オフィスのレイアウトを設計したわけではありません。ソフトウェアも同じだと思います。
レイアウトの設計を「レイアウトの設計」と見なすこともできますが...
かなり主観的ですが、私の見解：
アーキテクチャ 他のシステムとの相互作用、ハードウェア要件、全体的なコンポーネント設計、およびデータ フローを含む、システムの全体的な設計。
設計 システム全体におけるコンポーネントの編成と流れ。これには、他のコンポーネントと対話するためのコンポーネントの API も含まれます。
ソフトウェアアーキテクチャは「計算のアルゴリズムとデータ構造を超えた問題に関係しています。
アーキテクチャは具体的には…実装の詳細 (アルゴリズムやデータ構造など) ではありません。アーキテクチャ設計には、OOD (オブジェクト指向設計) によって通常提供されるものよりも豊富な抽象化のコレクションが含まれます。
設計は、設計要素のモジュール化と詳細なインターフェイス、それらのアルゴリズムと手順、およびアーキテクチャをサポートし、要件を満たすために必要なデータ型に関係しています。
「アーキテクチャ」は、「デザイン」の単なる同義語として使用されることがよくあります (「ハイレベル」という形容詞が先行する場合もあります)。また、多くの人が「アーキテクチャ パターン」という用語を「デザイン パターン」の同義語として使用しています。</p>
このリンクをチェックしてください。
誰かが船を建造する場合、エンジン、船体、電気回路などは彼の「建築要素」になります。彼にとって、エンジンの製造は「設計作業」になります。
その後、彼がエンジンの構築を別のチームに委任すると、彼らは「エンジン アーキテクチャ」を作成します...
つまり、抽象化または詳細のレベルに依存します。ある人の建築は別の人の設計かもしれません!
アーキテクチャは「変更が難しい設計上の決定」です。
TDD を使用した後、実際には設計が常に変更されることを意味するため、この質問に苦労することがよくありました。上記の定義は、Martin Fowler 著の Patterns of Enterprise Application Architectureから抜粋したものです。
これは、アーキテクチャがシステムの言語、フレームワーク、およびドメインに依存することを意味します。5 分で Java クラスからインターフェイスを抽出できれば、それはもはやアーキテクチャの決定ではありません。
ソフトウェア アーキテクチャは、より高いアーキテクチャ レベルで特定されるビジネスと機能をアプリケーションに投影する必要がある場合に、システム レベルで使用するのが最適です。
例えば、御社の業務はトレーダーにとって「損益」であり、主な機能は「ポートフォリオ評価」と「リスク計算」です。
しかし、ソフトウェア アーキテクトがソリューションの詳細を説明すると、次のことがわかります。
「ポートフォリオ評価」はひとつのアプリケーションではありません。次のような管理可能なプロジェクトで洗練する必要があります。
(関連する操作が非常に大きいため、共通の GUI を介して常に監視しながら、複数のコンピューターに分割する必要があります)
ソフトウェア設計では、さまざまなアプリケーション、それらの技術的関係、およびそれらの内部サブコンポーネントを調べます。
最後のアーキテクチャ レイヤ(「技術アーキテクチャ」) が (技術フレームワークまたは横断コンポーネントに関して) 作業し、プロジェクト チーム (ビジネス機能の実装をより重視) が開始するために必要な仕様を作成します。それぞれのプロジェクト。
アーキテクチャは高レベルで抽象的かつ論理的な設計ですが、ソフトウェア設計は低レベルで詳細かつ物理的な設計です。
私は Roy Thomas Fielding の彼の論文でのソフトウェア アーキテクチャとは何かについての定義と説明が好きです: Architectural Styles and the Design of Network-based Software Architectures
ソフトウェア アーキテクチャは、ソフトウェア システムの動作のあるフェーズにおける実行時の要素を抽象化したものです。システムは、多くのレベルの抽象化と操作の多くのフェーズで構成され、それぞれに独自のソフトウェア アーキテクチャがあります。
彼は「実行時の要素」と「抽象化のレベル」を強調しています。
設計:モジュール、モジュール間の関係、各モジュールの機能、クラスとそのメンバー関数、相互に通信する各モジュールのインターフェイスについて学習します。
アーキテクチャ:アーキテクチャは、ソフトウェア システムの構造全体です。すべてのモジュール、クラス、およびコンポーネントは異なるタスクを実行し、独自の結果をもたらします。
例: 5 つの部屋がある家があります。付属のバスルームもあります。キッチンも家にあります。このように、家庭にはさまざまなものがあり、これらすべてのものは互いに異なる関係にあります。つまり、これは家の「デザイン」に関するすべてです。
あなたが家の外から見ているとき、あなたが見ている全体の構造はすべて建築に関するものです.
ソフトウェア設計の歴史は古いですが、ソフトウェア アーキテクチャという用語はまだ 20 年しか経っていません。したがって、それは現在成長の痛みを経験しています。
学者は、アーキテクチャをソフトウェア設計のより大きな分野の一部と見なす傾向があります。Arch は独自の分野であるという認識が高まっていますが。
実務家は、Arch を、戦略的であり、プロジェクトで元に戻すのにコストがかかる可能性がある高レベルの設計決定と見なす傾向があります。
Arch とデザインの正確な境界線は、ソフトウェア ドメインによって異なります。たとえば、Web アプリケーションのドメインでは、レイヤード アーキテクチャが現在最も人気を集めています (Biz ロジック レイヤー、データ アクセス レイヤーなど)。この Arch の下位レベルの部分は設計と見なされます (クラス ダイアグラム、メソッド シグネチャなど)。 ) これは、組み込みシステム、オペレーティング システム、コンパイラなどのドメインでは異なる定義になります。
クリフ ノーツ バージョン:
設計: 目的の製品の仕様に基づいてソリューションを実装します。
アーキテクチャ: 設計をサポートする基盤/ツール/インフラストラクチャ/コンポーネント。
これは非常に広範な質問であり、多くの回答が得られます。
アーキテクチャは、システムを構築するための設計パターンの集合です。
デザインは、これらすべてをまとめるために使用される創造性だと思いますか?
「ソフトウェアアーキテクチャ」と「ソフトウェア設計」にはかなりの数の定義があり、どちらにも標準的な定義がないため、これに対する決定的な答えはありません。
それを考える良い方法は、「すべてのアーキテクチャはデザインですが、すべてのデザインがアーキテクチャであるわけではありません」[Software Architecture in Practice] という Len Bass、Paul Clements、および Rick Kazman の声明です。(アーキテクチャには他の活動が含まれる可能性があるため) これに完全に同意するかどうかはわかりませんが、アーキテクチャは設計の重要なサブセットを扱う設計活動であるという本質を捉えています。
私の少しばかげた定義 ( SEI 定義ページにあります) は、間違った場合にプロジェクトがキャンセルされる一連の決定であるというものです。
アーキテクチャ、設計、および実装を概念として分離する有用な試みは、数年前に Amnon Eden と Rick Kazman によって「アーキテクチャ、設計、実装」というタイトルの研究論文で行われました。 .edu/library/assets/ICSE03-1.pdf . 彼らの言葉は非常に抽象的ですが、単純に言えば、アーキテクチャは多くのコンテキストで使用でき、システム全体に適用されることを意図した設計であり、設計は多くのコンテキストで使用できるが特定の部分に適用される (誤った)設計です。システムの実装であり、実装はコンテキストに固有の設計であり、そのコンテキストに適用されます。
したがって、アーキテクチャ上の決定は、RPC ではなくメッセージングを介してシステムを統合するという決定になる可能性があります (したがって、これは多くの場所に適用できる一般原則であり、システム全体に適用することを目的としています)。設計上の決定は、マスターを使用することになります。システムの入力要求処理モジュール内の /slave スレッド構造 (どこでも使用できる一般原則ですが、この場合は 1 つのモジュールでのみ使用されます)。最後に、実装の決定は、要求ルーターからセキュリティの責任を移すことである可能性があります。 Request Manager モジュールの Request Handler へ (そのコンテキストで使用される、そのコンテキストにのみ関連する決定)。
これが役立つことを願っています！
私の意見では、アーキテクチャはビジョンに他ならず、要件を収集し、構成要素を正しい方法で組み立てます。
design として、特定のブロックを構築するために 100 のソリューションが利用可能である可能性がありますが、正確な要件を満たすには、正しい method を選択する必要があるため、正しい方法またはアルゴリズムを選択することは設計に他なりません。
アーキテクチャは、システムの基本的なコンポーネントを特定し、それらの構成と、システムのフレームワークを作成するためにそれらがどのように関連しているかを説明します。
設計では、さまざまなコンポーネントと、システム アーキテクチャによって提供されるフレームワークで必要な機能を提供するためにそれらを開発する方法について説明します。
建築とは、人間やシステムとのインターフェースだと思います。たとえば、プロトコルなどを含む Web サービス コントラクトはアーキテクチャです。画面をどのように構成するか、色などではなく、そこにどのような領域があるかが建築です。
デザインとは、何かを構築する方法です。フレームワーク、言語、テクノロジーなど。これはもちろん、プラットフォーム、セキュリティなどを考慮した企業のガイドラインと制限に合わせる必要があります。
アーキテクチャ:- アーキテクチャは、仕様に従って、建設のさまざまな段階で計画レイアウトを作成します。
デザイナー:- デザイナーとは、建築計画のすべての必須要件を、機能的、美的、およびレイアウトの外観で満たす活動です。
他の人も指摘しているように、ソフトウェアのアーキテクチャをレイアウトすることは、実際にはソフトウェア開発または実行ライフサイクル全体に影響を与える主要な設計上の決定を下すことです。単純化すると、アーキテクチャは高レベルの設計にすぎません。
アーキテクチャの決定がすべてのコンポーネントに影響を与えない (したがってローカルである) 場合でも、グローバルに関連している必要があります。つまり、何らかの形でシステム全体に影響を与えます。それ以外の場合は、単にローカルの設計上の決定です。
ただし、アーキテクチャに関連するより関連性の高い質問は、Hennessy & Patterson in Computer Architecture で定義されている Architecture vs Organization である可能性があることを指摘したいと思います。これに基づいて、アーキテクチャをシステムのデータ モデル (入力/出力、状態) の抽象化として、組織を実装 (ソフトウェア開発) プロセス中に行われる典型的な設計上の決定として考えることができます。
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
アーキテクチャは、システムがどのようにレイアウトされているかを示します。従来のアーキテクチャ パターンの例の 1 つは、システムがプレゼンテーション、ビジネス、およびデータ レイヤーに分割される 3 層システムです。
ドメイン駆動型の設計により、4 層アーキテクチャが促進されます。プレゼンテーション、アプリケーション、ドメイン、およびインフラストラクチャ レイヤー。また、リポジトリ パターンは、ドメイン レイヤーとインフラストラクチャ レイヤーの間に存在します。ドメイン モデルは、インフラストラクチャについて何も認識してはならず、純粋で独立した状態に保つ必要もあります。そのため、これら 2 つのレイヤーを仲介するリポジトリが用意されています。
リポジトリ パターンは、再利用可能なソリューションであり、繰り返される問題を処理するため、依然としてパターンです。ただし、リポジトリ パターンは、アーキテクチャについて話すときにのみ関連します。これには、ドメイン駆動設計アーキテクチャにおける役割と責任があります。これは、システムのどこにでも適用できる抽象的なファクトリ パターンのような数学的タイプの一般的なソリューションではありません。