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

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

我目前的理解是:

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

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


当前回答

建筑就是设计,但并非所有的设计都是建筑。因此,严格地说,尝试区分架构设计和非架构设计会更有意义。有什么区别呢?视情况而定!每个软件架构师可能有不同的答案(ymmv!)我们开发我们的启发式来提出一个答案,例如“类图是架构,序列图是设计”。有关更多信息,请参阅DSA书籍。

人们常说,架构比设计处于更高的抽象级别,或者架构是逻辑的,而设计是物理的。但这种观念虽然被普遍接受,但在实践中却毫无用处。在高抽象和低抽象之间,逻辑和物理之间,你的界线在哪里?视情况而定!

所以,我的建议是:

create a single design document. name this design document the way you want or, better, the way the readers are more accustomed to. Examples: "Software Architecture", "Software Design Specification". break this document into views and keep in mind you can create a view as a refinement of another view. make the views in the document navigable by adding cross-references or hyperlinks then you'll have higher level views showing broad but shallow overview of the design, and closer-to-implementation views showing narrow but deeper design details. you may want to take a look at an example of multi-view architecture document (here).

说了这么多……我们需要问的一个更相关的问题是:多少设计才足够?也就是说,我什么时候应该停止描述设计(用图表或散文),而应该转向编码?

其他回答

以下是可能更详细地解释体系结构的参考资料和软件体系结构的UML图列表。(我找不到用于软件设计的UML图列表)

Grady Booch

在架构模型中使用UML 2图

UML图的分类

UML图的分类

即使在发布了这个答案之后,我自己也不清楚哪个图是用于架构的,哪个图是用于设计的:)。Grady Booch在他的第58张幻灯片中指出,类、接口和协作是设计视图的一部分,而这个设计视图是架构视图的一部分!!

程序或计算系统的软件体系结构是系统的结构,由软件组件、这些组件的外部可见属性以及它们之间的关系组成。

(来自维基百科,http://en.wikipedia.org/wiki/Software_architecture)

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

(来自维基百科,http://en.wikipedia.org/wiki/Software_design)

我自己也说不出更好的话了:)

架构设计的基本原理来自于各种因素,其中最重要的是非功能性需求,比如可伸缩性,当然最重要的是经验。没有了理论基础,你就只剩下平淡的模式,或者怎么做。无论是在更高的层次上还是在类的层次上,它仍然是设计。

或者换句话说

架构是元设计,即设计设计。您有一些已知的模式适合某个解决方案空间,您会选择哪个,为什么?架构是当你回答“是哪个”和“为什么”时(“如何”已经在设计中给出了)。它当然不依赖于抽象级别,例如实现分布式会话不是一个类级别的任务,但是对于给定的体系结构有一些设计可供选择。

同样,体系结构也反映在类级设计中。在可伸缩的体系结构下,如果不考虑可伸缩性因素,类设计通常是不同的。为什么你必须有一个方法“BeginAsyncUpload”而不是“Upload”是一个架构决策。

有趣的是,当我们将注意力转移到更高层次的系统元素时,“哪个和为什么”问题变得更加重要,而“如何”变得不那么相关。从另一个方向来看,“如何”部分变得更加重要,这也是因为重复使用使得它变得很明显,例如,在抽象工厂和原型之间进行选择。

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

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

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

我认为架构是关于人类和/或系统的接口。例如,web服务契约(包括协议等)就是体系结构。一个屏幕是如何组成的,不是颜色之类的,而是有什么领域,这就是架构。

设计就是如何建造某样东西。什么框架、语言、技术等等。当然,这必须与考虑平台、安全性等的企业指导方针和限制相一致。