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

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

我目前的理解是:

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

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


当前回答

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

或者换句话说

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

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

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

其他回答

建筑与设计密切相关;它们之间的主要区别在于我们面对的方向。 建筑面向战略、结构和目的,面向抽象。 设计面向实现与实践,面向具体。

软件架构“关注的问题是……超出了计算的算法和数据结构。

架构特别不是关于实现的细节(例如,算法和数据结构)。体系结构设计包含了比OOD(面向对象设计)通常提供的更丰富的抽象集合。

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

“建筑”经常被用作“设计”的同义词(有时前面带有形容词“高级”)。许多人使用术语“架构模式”作为“设计模式”的同义词。

查看这个链接。

定义术语体系结构、设计和实现

这个问题没有明确的答案,因为“软件架构”和“软件设计”有相当多的定义,而且都没有一个规范的定义。

一个很好的思考方法是Len Bass, Paul Clements和Rick Kazman的声明,“所有的架构都是设计,但并不是所有的设计都是架构”[软件架构实践]。我不确定我是否完全同意这一点(因为架构可以包括其他活动),但它抓住了架构是处理设计的关键子集的设计活动的本质。

我的稍微轻率的定义(在SEI定义页面上找到)是,它是一组决策,如果做出错误的决定,将导致项目被取消。

A useful attempt at separating architecture, design and implementation as concepts was done by Amnon Eden and Rick Kazman some years ago in a research paper entitled "Architecture, Design, Implementation" which can be found here: http://www.sei.cmu.edu/library/assets/ICSE03-1.pdf. Their language is quite abstract but simplistically they say that architecture is design that can be used in many contexts and is meant to be applied across the system, design is (err) design that can be used in many contexts but is applied in a specific part of the system, and implementation is design specific to a context and applied in that context.

So an architectural decision could be a decision to integrate the system via messaging rather than RPC (so it's a general principle that could be applied in many places and is intended to apply to the whole system), a design decision might be to use a master/slave thread structure in the input request handling module of the system (a general principle that could be used anywhere but in this case is just used in one module) and finally, an implementation decision might be to move responsibilities for security from the Request Router to the Request Handler in the Request Manager module (a decision relevant only to that context, used in that context).

我希望这能有所帮助!

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

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

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

...long time ago in a faraway place philosophers worried about the distinction between the one and the many. Architecture is about relationship, which requires the many. Architecture has components. Design is about content, which requires the one. Design has properties, qualities, characteristics. We typically think that design is within architecture. Dualistic thinking gives the many as primordial. But architecture is also within design. It's all how we choose to view what is before us - the one or the many.