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

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

我目前的理解是:

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

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


当前回答

软件设计有更长的历史,而软件架构这个术语只有20年的历史。因此,它正在经历成长的烦恼。

学术界倾向于将架构视为更大的软件设计领域的一部分。尽管越来越多的人认识到Arch是一个独立的领域。

实践者倾向于将Arch视为高级设计决策,具有战略性,并且在项目中撤销可能代价高昂。

Arch和设计之间的确切界限取决于软件领域。例如,在Web应用领域,分层架构是目前最受欢迎的(业务逻辑层,数据访问层等)。Arch的低层部分被认为是设计(类图,方法签名等)。在嵌入式系统,操作系统,编译器等领域,这将是不同的定义。

其他回答

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

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

或者换句话说

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

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

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

架构: 结构设计是在更高的抽象层次上进行的工作,它将技术上重要的需求实现到系统中。该体系结构为进一步的设计奠定了基础。

设计: 通过在每个抽象层的迭代过程来填充架构所没有的内容的艺术。

体系结构确定了系统的基本组件,描述了它们的组织,以及它们与创建系统框架的关系。

设计描述了各种组件,以及应该如何在系统架构提供的框架中开发它们以提供所需的功能。

体系结构是用于构建系统的设计模式的最终集合。

我猜设计是用来把所有这些放在一起的创造力?