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

#1 楼

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

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

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

#2 楼

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



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

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


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

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

#3 楼

架构是战略性的，而设计是战术性的。

架构包括框架，工具，编程范例，基于组件的软件工程标准，高级原则。是一项与局部约束有关的活动，例如设计模式，编程习惯用法和重构。

#4 楼

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


架构是“什么”正在建造；
设计是我们正在建造的“方式”；

#5 楼

体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。
设计是指为显示系统或对象的外观和功能或工作而设计的计划或图形。在制造之前。


如果“架构”组件，则定义的是它在较大系统中的行为。
如果“设计”同一组件，您要定义它的内部行为。



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

What部分是设计， How是具体实现，而What和How的交集是Architecture。
用于区分体系结构和设计的图像：

还有一些设计决定，这些决定在架构上并不重要，即不属于设计的架构分支。例如，某些组件的内部设计决策，例如算法的选择，数据结构的选择等。
在组件边界之外不可见的任何设计决策都是组件的内部设计，并且是非架构的。这些是系统架构师将由模块设计人员或实施团队自行决定的设计决策，只要他们的设计不会破坏系统级架构所施加的架构约束即可。
给出良好类比的链接

#6 楼

用我自己的话，我会说你是对的；

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


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

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

示例：考虑一下您的房子，您不需要为厨房设计建筑师（仅涉及一个元素），但是完整的建筑物需要一些交互定义，例如门和屋顶。 >
设计是该功能（建议的）实现的丰富信息表示。它旨在引起反馈并与利益相关者进行讨论。这可能是好的做法，但不是必需的工程步骤。

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

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


体系结构适用于更详细的抽象级别的公众/工程师
设计适用于较不详细的抽象级别的公众

#7 楼

我的提醒：


我们可以更改设计而无需询问任何人
如果更改体系结构，我们需要将其传达给某人（团队，客户，利益相关方...）

#8 楼

我认为，当我们谈论设计与体系结构时，应该使用以下规则来确定：如果您创建的软件画面的元素可以一对一映射到编程语言的语法构造，则为Design，如果不是，则为Architecture。 br />
因此，例如，如果您看到类图或顺序图，则可以使用类语法构造将类及其关系映射到面向对象的编程语言。这显然是设计。另外，这可能会使该讨论与您将用来实现软件系统的编程语言有关。如果使用Java，则前面的示例适用，因为Java是一种面向对象的编程语言。如果您想出一个显示软件包及其依赖关系的图表，那也就是Design。您可以将元素（在这种情况下为包）映射到Java语法结构。

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

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

#9 楼

就我个人而言，我喜欢这样：

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

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

#10 楼

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

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

优秀的架构师将防止出现超规范-架构不能太过分指定但足够的是，（架构）决策仅针对存在最大代价要处理的风险的方面而建立，并有效地提供一个框架（“通用性”），在该框架中可以进行详细的设计，即局部功能的可变性。 >
实际上，架构过程或生命周期正好遵循此主题-足够的抽象级别来概述（架构上的）重要业务需求的结构，并为设计阶段留出更多细节以获取更具体的可交付成果。 br />

#11 楼

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

通常说架构处于比设计更高的抽象级别，或者架构是逻辑的而设计是物理的。但是，尽管这个观点被普遍接受，但实际上是没有用的。您如何在逻辑的抽象和物理的抽象之间划清界限？这要看情况！ ，使读者更加习惯。示例：“软件体系结构”，“软件设计规范”。
将此文档分为多个视图，请记住您可以创建一个视图以完善另一个视图。
通过添加交叉引用或超链接使文档中的视图可导航
，那么您将拥有较高级别的视图，显示了设计的较宽泛但较浅的概述，而接近实现的视图则显示了较窄但较深的设计设计细节。
您可能想看看一个多视图体系结构文档的示例（在这里）。

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

#12 楼

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

#13 楼

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

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

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

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

我自己不能说的更好:)

#14 楼

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

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

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

#15 楼

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

#16 楼

软件体系结构“除了计算的算法和数据结构之外，还涉及到其他问题。”

体系结构尤其不涉及……实现细节（例如，算法和数据结构）。体系结构设计涉及比面向对象的设计通常提供的更丰富的抽象集合。”

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

“体系结构”通常仅用作“设计”的同义词（有时以形容词“ high-level”开头）。许多人使用“建筑模式”一词作为“设计模式”的同义词。

请查看此链接。

定义术语“体系结构，设计和实现”

#17 楼

体系结构：
结构设计工作在更高的抽象层次上进行，从而实现了对系统的技术上重要的要求。该体系结构为进一步的设计奠定了基础。

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

#18 楼

我真的很喜欢本文，因为它是将体系结构与设计分离的经验法则：

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

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

#19 楼

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

#20 楼

非常主观，但我的看法是：

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

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

#21 楼

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

例如，您的业务对于交易者来说是“利润与损失”，并且您的主要功能涉及“投资组合评估”和“风险计算”。

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

“投资组合评估”可以不只是一个应用程序。它需要在可管理的项目中完善，例如：


GUI
Launcher
Dispatcher
...涉及的操作非常庞大，需要将其拆分到多台计算机之间，同时仍然始终通过通用的GUI进行监视。

软件设计将检查不同的应用程序，它们的技术关系和内部子组件。
将为工作（在技术框架或横向组件方面）的最后一个架构层（“技术架构”）和项目团队（更侧重于业务职能的实施）以开始各自的项目。

#22 楼

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

如果他然后将发动机的建造委托给另一个团队，他们将创建一个“发动机架构” ...

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

#23 楼

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

使用TDD后，实际上意味着您的设计一直在变化，我经常发现自己在为这个问题而苦苦挣扎。上面的定义摘自Martin Fowler的“企业应用程序体系结构的模式”，这意味着体系结构取决于系统的语言，框架和域。如果您只需在5分钟内从Java类中提取接口，就不再是架构决定。

#24 楼

Cliff Notes版本：

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

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

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

#25 楼

建筑是生成系统的设计模式的集合。

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

#26 楼

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

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

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

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

#27 楼

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

#28 楼

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

#29 楼

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


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


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

#30 楼

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

一种好的思考方式是Len Bass，Paul Clements和Rick Kazman的声明“所有架构都是设计，但并非所有设计都是架构” [实践中的软件架构]。我不确定我是否完全同意（因为架构可以包含其他活动），但它抓住了本质，即架构是一种设计活动，可以处理设计的关键子集。

我的定义有些浮躁（位于SEI定义页面上）是决策的集合，如果决策不正确，则会导致您的项目被取消。

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

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

我希望这会有所帮助！