有人能解释一下软件设计和软件架构的区别吗?
更具体地说;如果你让别人给你展示“设计”——你希望他们展示什么?“建筑”也是如此。
我目前的理解是:
设计:系统特定模块/部分的UML图/流程图/简单线框(用于UI) 架构:组件图(显示系统的不同模块如何相互通信以及如何与其他系统通信)，要使用什么语言，模式……?
如果我说错了，请指正。我提到了维基百科在http://en.wikipedia.org/wiki/Software_design和http://en.wikipedia.org/wiki/Software_architecture上有文章，但我不确定我是否理解正确。
当前回答
Cliff Notes版本:
设计:根据所需产品的规格实现解决方案。
架构:支持设计的基础/工具/基础设施/组件。
这是一个相当宽泛的问题，会引起很多人的回应。
其他回答
当您需要将较高体系结构级别识别的业务和功能投射到应用程序中时，软件体系结构最好用于系统级。
例如，你的业务是关于交易员的“盈亏”，你的主要功能涉及“投资组合评估”和“风险计算”。
但是当软件架构师详细描述他的解决方案时，他会意识到:
“投资组合评估”不能只是一个应用程序。它需要在可管理的项目中进行细化，例如:
GUI 发射器 调度程序 .．.
(因为涉及的操作太大了，需要在几台计算机之间进行拆分，同时仍然可以通过一个通用的GUI随时监控)
软件设计将检查不同的应用程序，它们的技术关系和内部子组件。 它将产生最后一个体系结构层(“技术体系结构”)工作所需的规范(根据技术框架或横向组件)，以及项目团队(更面向业务功能的实现)开始各自的项目所需的规范。
我同意其中的许多解释;本质上，我们认识到软件系统的架构设计和详细设计之间的区别。
虽然设计师的目标是在开发所需的规格中尽可能精确和具体;架构师本质上的目标是指定系统的结构和全局行为，就像详细设计开始时所要求的那样。
优秀的架构师会避免过度规范——架构不能过分指定，但要足够，(架构)决策只针对那些风险处理成本最高的方面建立，并有效地提供一个框架(“通用性”)，在这个框架内可以进行详细设计，即局部功能的可变性。
实际上，体系结构过程或生命周期只是遵循这个主题——足够的抽象级别来概述(体系结构上的)重要业务需求的结构，并将更多细节留给设计阶段以实现更具体的可交付成果。
软件架构“关注的问题是……超出了计算的算法和数据结构。
架构特别不是关于实现的细节(例如，算法和数据结构)。体系结构设计包含了比OOD(面向对象设计)通常提供的更丰富的抽象集合。
设计涉及到设计元素的模块化和详细接口，它们的算法和过程，以及支持体系结构和满足需求所需的数据类型。
“建筑”经常被用作“设计”的同义词(有时前面带有形容词“高级”)。许多人使用术语“架构模式”作为“设计模式”的同义词。
查看这个链接。
定义术语体系结构、设计和实现
你说得对，是的。系统的架构是它的“骨架”。它是系统抽象的最高层次。有什么样的数据存储，模块之间如何交互，有什么样的恢复系统。就像设计模式一样，也有架构模式:MVC、3层分层设计等。
软件设计就是设计各个模块/组件。模块x的职责和功能是什么?Y类?它能做什么，不能做什么?可以使用哪些设计模式?
所以简而言之，软件架构更多的是整个系统的设计，而软件设计则强调模块/组件/类的层面。
体系结构是指计算机或基于计算机的系统的概念结构和逻辑组织。 设计是指在一个系统或物体被制造出来之前，为显示其外观、功能或工作方式而设计的计划或图纸。 如果您正在“架构”一个组件，那么您正在定义它在更大的系统中的行为。 如果你在“设计”同一个组件，你就是在定义它的内部行为。
所有的建筑都是设计，但并非所有的设计都是建筑。
什么部分是设计，如何具体实现，以及什么和如何是架构的交集。
区分建筑和设计的形象:
还有一些设计决策，在架构上并不重要，也就是说不属于设计的架构分支。例如，某些组件的内部设计决策，如算法的选择，数据结构的选择等。
任何在组件边界之外不可见的设计决策都是组件的内部设计，并且是非架构性的。这些是系统架构师留给模块设计人员或实现团队的设计决策，只要他们的设计不打破系统级架构施加的架构限制。
这个链接提供了一个很好的类比
