有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
我非常喜欢这篇文章，因为它提供了将建筑与设计分开的经验法则:
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
这被称为内涵/局部性假说。关于软件性质的非本地和内涵的陈述是架构性的。局部的和内涵的语句是设计的。
其他回答
在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.
另外，请参考: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model
体系结构是用于构建系统的设计模式的最终集合。
我猜设计是用来把所有这些放在一起的创造力?
架构是“难以改变的设计决策”。
在使用TDD之后，这实际上意味着你的设计一直在变化，我经常发现自己在这个问题上挣扎。上面的定义摘自Martin Fowler的《企业应用程序体系结构模式》
这意味着架构依赖于你的系统的语言、框架和领域。如果你能在5分钟内从Java类中提取出一个接口，这就不再是架构决策了。
我喜欢Roy Thomas Fielding在他的论文中对什么是软件架构的定义和解释: 架构风格与基于网络的软件架构设计
软件体系结构是软件系统在其操作的某个阶段的运行时元素的抽象。一个系统可能由许多抽象层次和许多操作阶段组成，每一个都有自己的软件体系结构。
他强调“运行时元素”和“抽象层次”。
