有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
我认为架构是关于人类和/或系统的接口。例如，web服务契约(包括协议等)就是体系结构。一个屏幕是如何组成的，不是颜色之类的，而是有什么领域，这就是架构。
设计就是如何建造某样东西。什么框架、语言、技术等等。当然，这必须与考虑平台、安全性等的企业指导方针和限制相一致。
其他回答
体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。 设计是指在一个系统或物体被制造出来之前，为显示其外观、功能或工作方式而设计的计划或图纸。 如果您正在“架构”一个组件，那么您正在定义它在更大的系统中的行为。 如果你在“设计”同一个组件，你就是在定义它的内部行为。
所有的建筑都是设计，但并非所有的设计都是建筑。
什么部分是设计，如何具体实现，以及什么和如何是架构的交集。
区分建筑和设计的形象:
还有一些设计决策，在架构上并不重要，也就是说不属于设计的架构分支。例如，某些组件的内部设计决策，如算法的选择，数据结构的选择等。
任何在组件边界之外不可见的设计决策都是组件的内部设计，并且是非架构性的。这些是系统架构师留给模块设计人员或实现团队的设计决策，只要他们的设计不打破系统级架构施加的架构限制。
这个链接提供了一个很好的类比
你说得对，是的。系统的架构是它的“骨架”。它是系统抽象的最高层次。有什么样的数据存储，模块之间如何交互，有什么样的恢复系统。就像设计模式一样，也有架构模式:MVC、3层分层设计等。
软件设计就是设计各个模块/组件。模块x的职责和功能是什么?Y类?它能做什么，不能做什么?可以使用哪些设计模式?
所以简而言之，软件架构更多的是整个系统的设计，而软件设计则强调模块/组件/类的层面。
我认为架构是关于人类和/或系统的接口。例如，web服务契约(包括协议等)就是体系结构。一个屏幕是如何组成的，不是颜色之类的，而是有什么领域，这就是架构。
设计就是如何建造某样东西。什么框架、语言、技术等等。当然，这必须与考虑平台、安全性等的企业指导方针和限制相一致。
正如其他人指出的那样，规划软件的架构实际上是做出对软件开发或执行生命周期有整体影响的主要设计决策;所以简单地说，建筑只是高层次的设计。
即使架构决策不影响所有组件(因此是局部的)，它仍然必须是全局相关的，即它以某种方式影响整个系统;否则只是一个本地设计决策。
不过，我想指出的是，与架构相关的一个更相关的问题可能是Hennessy & Patterson在《计算机架构》中定义的架构vs组织。基于此，我们可以将体系结构视为系统的数据模型(输入/输出，状态)抽象，而将组织视为实现(软件开发)过程中所采取的典型设计决策。
在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.
