软件设计与软件体系结构[关闭]

有人可以解释一下软件设计和软件体系结构之间的区别吗？

进一步来说; 如果您告诉某人向您介绍“设计”，您希望他们介绍什么？“架构”也是如此。

我目前的理解是：

• 设计：UML图/流程图/用于系统的特定模块/部分的简单线框（用于UI）
• 体系结构：组件图（显示系统的不同模块如何与彼此以及其他系统进行通信），使用哪种语言，模式...？

如我错了请纠正我。我已经提到Wikipedia在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但是我不确定我是否正确理解它们。

你是对的。系统的架构就是它的“骨架”。这是系统的最高抽象级别。存在什么样的数据存储，模块之间如何交互，有哪些恢复系统。就像设计模式一样，也有架构模式：MVC，3层分层设计等。

软件设计是关于设计各个模块/组件。模块x的职责，功能是什么？Y级的？它能做什么，不能做什么？可以使用哪些设计模式？

简而言之，软件体系结构更多地是关于整个系统的设计，而软件设计则强调模块/组件/类级别。

在SDLC（软件开发生命周期）的某些描述中，它们是可互换的，但是，有一个共同点是它们是不同的。它们是同时存在的：不同的（1）阶段，（2）职责范围和（3）决策水平。

• 架构是更大的图景：选择框架，语言，范围，目标和高级方法（Rational，Waterfall，Agile等）。
• 设计是较小的图景：代码组织方式的计划；系统不同部分之间的合同将如何看待；项目方法和目标的持续实施。在此阶段编写规范。

由于不同的原因，这两个阶段似乎融合在一起。

1. 较小的项目通常没有足够的范围来将计划分为几个阶段。
2. 一个项目可能是一个较大项目的一部分，因此，已经确定了两个阶段的一部分。（已经存在数据库，约定，标准，协议，框架，可重用代码等）
3. 关于SDLC的新思路（请参阅敏捷方法论）在某种程度上重新排列了这种传统方法。SDLC的设计（较小程度的架构）是有意进行的。通常会有更多迭代，整个过程反复发生。
4. 软件开发既复杂又难以计划，但是客户/经理/销售人员通常会在中途更改目标和要求，从而使软件开发变得更加困难。无论是不是计划，都必须在项目的后期进行设计甚至是建筑决策。

即使责任的各个阶段或领域融合在一起并发生在各地，但最好还是知道正在执行什么级别的决策。（我们可能会永远对此继续下去。我试图对其进行总结。）我将以以下结尾：即使您的项目似乎没有正式的架构或设计阶段/ AOR /文档，也无论是否有人在有意识地做与否。如果没有人决定进行体系结构设计，那么默认情况可能会很糟糕。同上设计。如果没有正式的阶段代表这些概念，那么这些概念几乎更为重要。

建筑是战略性的，而设计是战术性的。

体系结构包括框架，工具，编程范例，基于组件的软件工程标准，高级原则。

设计是一项与局部约束有关的活动，例如设计模式，编程习惯用法和重构。

我在寻找架构与设计之间的简单区别时发现了这一点。
您如何看待他们：

• 建筑是我们正在建造的“什么”。
• 设计是我们正在建造的“方式”。

1. 体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。

   设计是指为制作系统或对象之前显示其外观和功能或工作原理而制作的计划或图纸。

2. 如果要“构造”组件，则需要定义组件在较大系统中的行为。

   如果要“设计”相同的组件，则需要定义其内部行为。

所有架构都是设计，但并非所有设计都是架构。

What部分是设计，How是具体落实和的交集What，并How为架构。

用于区分建筑和设计的图像：

还有一些设计决策，这些决策在架构上并不重要，即不属于设计的架构分支。例如，某些组件的内部设计决策，例如算法选择，数据结构选择等。

在组件边界之外不可见的任何设计决策都是组件的内部设计，并且是非架构性的。这些是系统架构师将由模块设计人员或实施团队自行决定的设计决策，只要他们的设计不会破坏系统级架构所施加的架构约束即可。

打个比方的链接

用我自己的话说，你说的对。

体系结构是系统需求对系统元素的分配。关于架构的四个陈述：

1. 它可能会引入非功能性要求，例如语言或模式。
2. 它定义了组件，接口，时序等之间的交互。
3. 它不会引入新功能，
4. 它将系统打算执行的（设计的）功能分配给元素。

当细分系统的复杂性时，架构是必不可少的工程步骤。

示例：考虑您的房子，您的厨房不需要建筑师（仅涉及一个元素），但是完整的建筑物需要一些交互定义，例如门和屋顶。

设计是该功能（建议的）实现的丰富信息表示。它旨在引起反馈并与利益相关者进行讨论。这可能是很好的做法，但不是必需的工程步骤。

可以在安装厨房之前看到厨房设计很高兴，但这对于烹饪要求不是必需的：

如果我考虑一下，您可以声明：

• 体系结构在更详细的抽象层上供公众/工程师使用
• 设计是针对不太详细的抽象级别的公众设计的

我的提醒：

• 我们可以更改设计而无需问别人
• 如果我们更改架构，则需要与某人（团队，客户，利益相关方……）进行沟通。

我认为我们应该使用以下规则来确定何时谈论设计与体系结构：如果可以将您创建的软件画面的元素一对一地映射到编程语言的语法构造，则为设计，如果不是，则为Architecture。

因此，例如，如果您看到类图或序列图，则可以使用类语法构造将类及其关系映射到面向对象的编程语言。这显然是设计。另外，这可能会使讨论内容与您将用于实现软件系统的编程语言有关。如果使用Java，则前面的示例适用，因为Java是一种面向对象的编程语言。如果您想出一个显示软件包及其依赖关系的图表，那也是Design。您可以将元素（在这种情况下为包）映射到Java语法构造。

现在，假设您的Java应用程序分为模块，每个模块是一组程序包（表示为jar文件部署单元），并且为您提供了一个包含模块及其依赖关系的图，即架构。在Java中（至少在Java 7之前）没有一种方法可以将模块（一组程序包）映射到语法构造。您可能还会注意到，该图代表了软件模型抽象级别上的更高一步。当使用Java编程语言进行开发时，上面的任何图（粗略地表示为包图）都表示架构视图。另一方面，如果您在Modula-2中进行开发，则模块图表示设计。

（摘录自http://www.copypasteisforword.com/notes/software-architecture-vs-software-design的片段）

我个人喜欢这个：

“设计师关心的是当用户按下按钮时发生的事情，而建筑师关心的是当一万用户按下按钮时发生的事情。”

Mark Cade和Humphrey Sheil撰写的 SCEA for Java™EE学习指南

我同意许多解释。本质上，我们正在认识到体系结构设计和软件系统的详细设计之间的区别。

尽管设计人员的目标是在规格上精确和具体，但对于开发而言是必需的；架构师的主要目的是指定系统的结构和全局行为，就像开始进行详细设计一样。

一个好的架构师将防止过度规范-架构不能被过度指定，而应恰到好处，仅针对存在最大代价要处理的风险的方面建立（架构）决策，并有效地提供一个框架（“共性”），可以进行详细的设计，即本地功能的可变性。

实际上，架构过程或生命周期正好遵循此主题-足够的抽象级别来概述（架构上）重要业务需求的结构，并为设计阶段留出更多细节以获取更具体的可交付成果。

建筑是设计，但并非所有设计都是建筑。因此，严格来说，尝试区分建筑设计和非建筑设计将更有意义。有什么区别？这取决于！每个软件架构师可能都有不同的答案（ymmv！）。我们开发启发式方法以得出答案，例如“类图是架构，序列图是设计”。有关更多信息，请参见DSA。

通常说架构比设计更高的抽象级别，或者架构是逻辑的而设计是物理的。但是，尽管这一观点被普遍接受，但实际上是没有用的。您如何在逻辑的抽象和物理的抽象之间划清界限？这取决于！

因此，我的建议是：

• 创建一个设计文件。
• 以您想要的方式来命名此设计文档，或者更好地，以读者更习惯的方式来命名。示例：“软件体系结构”，“软件设计规范”。
• 将此文档分为多个视图，请记住您可以创建一个视图以完善另一个视图。
• 通过添加交叉引用或超链接使文档中的视图可导航
• 那么您将拥有较高级别的视图，显示了广泛而浅薄的设计概述，而接近实现的视图则显示了狭窄但更深的设计细节。
• 您可能想看一下多视图架构文档的示例（此处）。

说了这么多…… 我们需要问的一个更相关的问题是：多少设计就足够了？也就是说，什么时候应该停止描述设计（以图表或散文形式），而应该继续进行编码？

是的，对我来说听起来不错。设计就是您要做的事情，而架构则是将设计的各个部分连接在一起的方式。它可能与语言无关，但通常会指定要使用的技术，例如LAMP v Windows，Web Service v RPC。

程序或计算系统的软件体系结构是系统的一个或多个结构，包括软件组件，这些组件的外部可见属性以及它们之间的关系。

（来自Wikipedia，http：//en.wikipedia.org/wiki/Software_architecture）

软件设计是解决问题和计划软件解决方案的过程。确定软件的用途和规格后，软件开发人员将设计或雇用设计师来制定解决方案的计划。它包括底层组件和算法实现问题以及体系结构视图。

（来自Wikipedia，http：//en.wikipedia.org/wiki/Software_design）

我自己不能说的更好:)

我认为架构就像Patrick Karcher所做的那样-全局。例如，您可以为建筑物提供建筑，查看其结构支撑，窗户，入口和出口，排水等。但是您尚未“设计”地板布局，隔间位置等。

因此，当您设计建筑物时，您并未设计每个办公室的布局。我认为软件也是如此。

您可以将设计布局视为“设计布局”，尽管...

很好的问题...虽然它们之间的界线不是一条鲜明的鲜明界限，恕我直言，如果您同时使用这两个术语，那么Architecture会包含有关如何构建或构造某些事物的更多技术或结构决策，尤其是那些很难的决策（或一旦实现就难以更改，而设计包含那些以后易于更改的决策（例如方法名称，类<->文件的组织结构，设计模式，是否使用单例或静态类来解决某些特定问题）等）和/或影响系统或应用程序的外观或美观方面的内容（人机界面，易用性，外观等）。

软件体系结构 “除了计算的算法和数据结构外，还存在其他问题……”。

架构并不是专门针对……具体实现（例如算法和数据结构）。架构设计所包含的抽象集合比OOD（面向对象设计）通常所提供的更为丰富。

设计涉及设计元素的模块化和详细接口，其算法和过程以及支持体系结构和满足要求所需的数据类型。

“体系结构”通常仅用作“设计”的同义词（有时在形容词“高级”之前）。许多人使用“建筑模式”一词作为“设计模式”的同义词。

查看此链接。

定义术语架构，设计和实施

体系结构：
在较高抽象级别上进行结构设计工作，这些技术设计对系统具有重要的技术要求。该架构为进一步设计奠定了基础。

设计：
在抽象的每个层上通过迭代过程填充体系结构中没有的内容的艺术。

我真的很喜欢这篇文章，因为它具有将建筑与设计分离的经验法则：

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

它被称为内涵/局部性假设。关于软件性质的声明是非本地的和意图性的。局部和意图性陈述是设计性的。

……很久以前，在一个遥远的地方，哲学家们担心一人与多人之间的区别。体系结构是关于关系的，这需要很多。体系结构具有组件。设计是关于内容的，这需要内容。设计具有属性，品质，特征。我们通常认为设计在体系结构之内。二元思维使许多人成为原始人。但是建筑也在设计之内。这是我们选择查看摆在我们面前的事物的全部-一个或多个。

很主观，但我认为：

体系结构体系结构 的总体设计，包括与其他系统的交互，硬件要求，总体组件设计和数据流。

设计 整个系统中组件的组织和流程。这也将包括用于与其他组件交互的组件的API。

当您需要将业务和功能由更高的架构级别标识到应用程序中时，软件体系结构最适合在系统级别使用。

例如，您的业务涉及交易者的“利润和损失”，而您的主要职能涉及“投资组合评估”和“风险计算”。

但是，当软件架构师详细介绍其解决方案时，他将意识到：

“投资组合评估”不能只是一种应用。需要在可管理的项目中对其进行完善，例如：

• 图形用户界面
• 发射器
• 调度员
• ...

（由于涉及的操作非常庞大，因此需要在多台计算机之间进行拆分，同时始终通过一个通用GUI对其进行监视）

软件设计将检查不同的应用程序，它们的技术关系以及它们的内部子组件。
它将为最后一个架构层（“技术架构”）（在技术框架或横向组件方面）进行工作以及为项目团队（更侧重于业务功能的实现）制定所需的规范。他们各自的项目。

如果有人造船，那么发动机，船体，电路等将是他的“建筑元素”。对他来说，发动机制造将是“设计工作”。

如果他随后将发动机的制造工作委托给另一个团队，他们将创建一个“发动机架构”。

所以-这取决于抽象或细节的级别。一个人的建筑可能是另一个人的设计！

架构是“难以更改的设计决策”。

在使用TDD之后，这实际上意味着您的设计一直在变化，我经常发现自己在为这个问题而苦苦挣扎。上面的定义摘自Martin Fowler 的“企业应用程序体系结构模式”

这意味着体系结构取决于系统的语言，框架和域。如果您只需在5分钟内从Java类中提取接口，就不再是架构决定。

悬崖笔记版本：

设计：根据所需产品的规格实施解决方案。

体系结构：支持您的设计的基础/工具/基础结构/组件。

这是一个相当广泛的问题，将引起很多回应。

架构是生成系统的设计模式的最终集合。

我想设计是用来将所有这些整合在一起的创造力吗？

软件设计的历史悠久，而软件架构这个词才刚刚使用了20年。因此，它正在经历越来越大的痛苦。

学术界倾向于将体系结构视为软件设计更大领域的一部分。尽管人们越来越认识到Arch是它自己的领域。

从业者倾向于将Arch视为具有战略意义的高级设计决策，并且在撤消项目时可能会付出高昂的代价。

Arch与设计之间的确切界限取决于软件领域。例如，在Web应用程序领域，分层体系结构目前正获得最广泛的使用（Biz逻辑层，数据访问层等）。此Arch的下层部分被认为是设计（类图，方法签名等）。 ）在嵌入式系统，操作系统，编译器等领域的定义将有所不同。

架构是高层的，抽象的和逻辑的设计，而软件设计是底层的，详细的和物理的设计。

另外，请参阅：http : //en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

我喜欢Roy Thomas Fielding在他的论文中对什么是软件体系结构的定义和解释： 体系结构样式和基于网络的软件体系结构设计

软件体系结构是软件系统在其操作的某个阶段的运行时元素的抽象。一个系统可能由许多抽象级别和许多操作阶段组成，每个阶段都有自己的软件体系结构。

他强调“运行时元素”和“抽象级别”。

对此没有明确的答案，因为“软件体系结构”和“软件设计”有很多定义，而对于这两个都没有规范的定义。

Len Bass，Paul Clements和Rick Kazman认为“所有体系结构都是设计，但并非所有设计都是体系结构”是一种很好的思维方式。我不确定我是否完全同意（因为架构可以包括其他活动），但它抓住了本质，即架构是一种处理设计的关键子集的设计活动。

我稍微大胆的定义（可在SEI定义页面上找到）是这组决策，如果决策不正确，则会导致您的项目被取消。

几年前，Amnon Eden和Rick Kazman在题为“体系结构，设计，实现”的研究论文中进行了有用的尝试，将构架，设计和实现作为概念进行了分离，该论文可以在以下位置找到：http：//www.sei.cmu .edu / library / assets / ICSE03-1.pdf。他们的语言是非常抽象的，但简单地说，他们说架构是可以在多种情况下使用的设计，并且打算在整个系统中应用；设计是（err）设计，可以在多种情况下使用，但是应用于特定的部分系统实现，并且实现是针对特定于上下文的设计，并在该上下文中应用。

因此，架构决策可能是通过消息而不是RPC集成系统的决策（因此这是一条通用原则，可以在许多地方应用，并且旨在应用于整个系统），而设计决策则可能是使用主服务器。 / slave线程结构在系统的输入请求处理模块中（可以在任何地方使用但在这种情况下仅在一个模块中使用的一般原理），最后，一个实现决定可能是从请求路由器转移安全责任到请求管理器模块中的请求处理程序（仅与该上下文相关的决策，用于该上下文）。

我希望这有帮助！