功能、质量和商业需求的某个集合塑造了架构，也就是说关键需求塑造了架构。
概念性架构设计可以分为以下3步：
1． 鲁棒性分析
2． 引入架构模式
3． 质量属性分析
很多人认为从需求分析到架构设计之间的过渡遇到很多问题，究其根源，可能是以下的原因造成的：
- 用例是面向问题领域的，而设计是面向机器域的，这两个‘空间’存在映射。
- 用例技术本身不是面向对象的，而设计应该是面向对象的，这是两种不同的思维方式。
- 用例规约采取自然语言描述，而设计采取形式化的模型描述，描述的方式不一样。
鲁棒图可以很多的解决需求分析和架构设计之间的差别。
鲁棒图包含3中元素：边界对象、控制对象和实体对象。
边界对象是模拟外部环境和未来系统之间的交互进行建模，它负责接收外部输入、处理内部内容的解释，并表达或者传递相应的结果。
控制对象对行为进行封装，描述用例中事件流的控制行为。
实体对象对需要存储的信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
鲁棒图的三种对象很好的概括了实际系统 中对象的三种职责：交互、控制和信息。这三种职责和组成架构的抽象元素之间有完美的对应关系：连接元素、处理元素、数据元素。
鲁棒图的本质：
- 参与者只能同边界对象进行交谈
- 边界对象只能同控制体和参与者进行交谈
- 实体对象也只能同控制对象进行交谈
- 控制体既能与边界对象交谈，也能同控制对象进行交谈，但不能与参与者进行交谈。
可以将MVC结构和鲁棒图进行对应，View对应边界对象，Model对应实体对象，Controller对应控制对象。当然，有时Model中也包含一部分控制对象。
要建立概念性架构，应明确实现预期功能所需的职责模型，研究用例执行的不同场景是一个可取的方法。
所谓软件架构就是关于如何构建软件的一些最重要的设计决策，这些决策往往围绕着将系统分为哪些部分、各部分之间如何交互展开的。
软件架构模式就是高度抽象的、适用于许多类似系统的、预先定义好的一种特殊的软件架构。架构模式描述了软件系统基本的结构化组织方案，具体而言，架构模式提供了一套预定义的子系统，并规定了子系统的职责，以及子系统或自荐关系的组织原则和组织指南。
目前有很多比较成熟的架构模式，我们需要根据项目的具体需求去确定应该采取哪种架构模式。
分层：很流行，最大的优点是将整体问题局部化，把可能的变化分别封装在不同的层中，最后，系统被规划为一个单向依赖的分层体系，利于修改、扩展和替换。具体而言，各层之间的单向依赖关系可以分为两种：严格的分层架构要求第n层只能被第n+1层调用，于此相对的是不严格的分层架构，第n层可以被位于其上层的任意一层调用。我们需要注意分层的原则：职责划分和交互机制。
MVC：铺天盖地的一种模式。随着smalltalk发展而来，有很多变种。包含三种组件：Model、View、Controller。
微内核：最大的优点是适应变化。微内核架构不仅将应用相关部分与通用部分分离，而且又将通用部分进一步分离成一个最小化的基本服务内核和众多扩展服务。微内核不仅提供了一个基本服务的最小集合，这些基本服务屏蔽了其下层复杂环境的影响、并以规范的接口提供给上层的‘增值服务’使用，于是所有这些附加的增值服务都和复杂环境无关。微内核所提供的基本服务必须是完备的，从而实现了一个虚拟机。这个虚拟机不仅屏蔽了下层的复杂性，而且建立了更抽象、更易用的一个‘新机器’供其上层使用。
微内核的缺点：1.设计和实现的复杂性；2. 往往比同类情况下其他架构的性能低。
采取微内核架构的原因:1. 可扩展性；2. 可移植性；3. 延长软件系统的生命周期。
元模型架构：一个以适应变化、支持长生命周期为主要目标的架构模式。包括两个层：基本层和元层次。基本层定义应用，类似于我们要编写的程序；元层次包含一组‘元对象’，这些元对象组成的模型叫做‘元模型’，元模型是对基本层中的‘一切’的抽象，提供了软件本身的结构和行为的‘自描述’。
参考文献：
《软件架构设计》 温昱