有人能解释一下软件设计和软件架构的区别吗?

更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。

我目前的理解是:

设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信),要使用什么语言,模式……?

如果我说错了,请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章,但我不确定我是否理解正确。


当前回答

体系结构更像是集成系统的各种功能,以实现系统的一个整体目标,而设计则解决每个功能需求。

例如,以MVVM为例,这是一种体系结构模式。对于通知功能,MVVM使用观察者模式,这又是一种设计模式,

其他回答

我同意其中的许多解释;本质上,我们认识到软件系统的架构设计和详细设计之间的区别。

虽然设计师的目标是在开发所需的规格中尽可能精确和具体;架构师本质上的目标是指定系统的结构和全局行为,就像详细设计开始时所要求的那样。

优秀的架构师会避免过度规范——架构不能过分指定,但要足够,(架构)决策只针对那些风险处理成本最高的方面建立,并有效地提供一个框架(“通用性”),在这个框架内可以进行详细设计,即局部功能的可变性。

实际上,体系结构过程或生命周期只是遵循这个主题——足够的抽象级别来概述(体系结构上的)重要业务需求的结构,并将更多细节留给设计阶段以实现更具体的可交付成果。

用我自己的话来说,你是对的;

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

它可以引入非功能性需求,如语言或模式。 它定义了组件、接口、时序等之间的交互。 它不应该引入新的功能, 它将系统要执行的(设计的)功能分配给元素。

当对系统的复杂性进行细分时,体系结构是必不可少的工程步骤。

例如:想想你的房子,你的厨房不需要建筑师(只涉及一个元素),但整个建筑需要一些交互定义,比如门和屋顶。

设计是对功能(提议的)实现的一种信息表示。它旨在获得反馈,并与利益相关者进行讨论。这可能是一个很好的实践,但不是一个必要的工程步骤。

在厨房安装之前,最好能看到厨房的设计,但对于烹饪要求来说不是必需的:

如果我想一下,你可以这样说:

架构是为公众/工程师在更详细的抽象层次上设计的 设计是在一个不太详细的抽象层次上面向公众的

当我寻找建筑和设计之间的简单区别时,我发现了这一点; 你对这种看待他们的方式有什么看法?

架构是我们正在建造的“什么”; 设计是我们“如何”建造;

在SDLC(软件开发生命周期)的一些描述中,它们是可互换的,但共识是它们是不同的。它们同时是:不同的(1)阶段,(2)责任领域,(3)决策层次。

架构是更大的图景:框架、语言、范围、目标和高级方法(Rational、瀑布式、敏捷等)的选择。 设计是更小的画面:如何组织代码的计划;系统不同部分之间的契约将会是怎样的;项目方法和目标的持续实施。规范是在这个阶段编写的。

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

Smaller projects often don't have enough scope to separate out planning into these to stages. A project might be a part of a larger project, and hence parts of both stages are already decided. (There are already existing databases, conventions, standards, protocols, frameworks, reusable code, etc.) Newer ways of thinking about the SDLC (see Agile methodologies) somewhat rearrange this traditional approach. Design (architecture to a lesser extent) takes place throughout the SDLC on purpose. There are often more iterations where the whole process happens over and over. Software development is complicated and difficult to plan anyway, but clients/managers/salespeople usually make it harder by changing goals and requirements mid-stream. Design and even architectural decisions must bemade later in the project whether that is the plan or not.

Even if the stages or areas of responsibility blend together and happen all over the place, it is always good to know what level of decision-making is happening. (We could go on forever with this. I'm trying to keep it a summary.) I'll end with: Even if it seems your project has no formal architectural or design stage/AOR/documentaiton, it IS happening whether anyone is consciously doing it or not. If no one decides to do architecture, then a default one happens that is probably poor. Ditto for design. These concepts are almost more important if there are no formal stages representing them.

建筑是战略的,而设计是战术的。

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

而设计是一种与局部约束有关的活动,例如设计模式、编程习惯用语和重构。