”Use Case驱动“的观点既有积极意义，也有不利影响。从积极的方面看，Use Case这种需求描述方式确实有助于分析模型，设计模型，实现模型和测试模型的建立.....但是从另一方面看，OOSE对Use Case的依赖程度超出了它的实际能力。 -- 邵伟忠，《面向对象的系统设计》

顶级设计者在设计中并不是按部就班地采用自顶向下（或自底向上）的方法，而是着眼于权重更大的目标。这些目标通常是难点问题，设计者不能轻易地看出这些问题的解决方案。为了得到整个的设计方案，设计者必须先致力于难点的设计并消除其中的疑惑。 -- Robert L. Glass, 《软件工程的事实与谬误》

概念架构是大型系统架构设计成败的关键。

7.1. 什么是概念架构

下面是宏伟的金门大桥，这么复杂的架构，桥梁架构师是怎么“开始设计”的呢？

答案是：概念架构（Conceptual Architecture）。下图展示了斜拉桥的概念架构示意图。由此图可以看出，概念架构高屋建瓴的给出高层解决方案：索塔负责承重，斜拉索吊起刚性梁。

下面，来看看软件行业（来自Dana Bredemeyer等专家）中概念架构的定义：

概念性架构界定系统的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正规约及架构图，但不涉及接口细节。(The Conceptual Architecture identifies the high-level components of the system, and the relatiooonships among them. Its purpose is to direct attention at an appropriate decomposition of the system without delving into details. Moreover, it proovides a useful vehicle for coommunicating the architecture to non-technical audiences, such as management, marketing, and users. It consists oof the Architecutre Diagram (without interface detail) and an informal component specification for each component.)

根据定义，我们注意到如下几点：

概念架构满足“架构 = 组件 + 交互”的基本定义，只不过概念架构仅关注高层组件(high-level components)。
概念架构对高层组件的“职责 ”进行笼统的界定（informal specification），并给出了高层组件之间的相互关系(Architecture Diagram)。
概念架构不应涉及接口细节(withouot iinterface detaiil)。

7.2. 实际意义

不同的系统架构经常不同。但请继续追问自己两个极具价值的问题。

不同系统的架构，为何不同？
架构设计中，应何时建立架构大方向的不同？

第1个问题的答案：需求不同，所有架构不同 ；当然，“需求”不是单指“功能需求”，而是包含了功能、质量、约束等方面。第2个问题的答案：进行概念架构设计时应确立架构大方向 。架构设计跪在有针对性，概念架构针对重大需求、特色需求、高风险需求的要求，给出高层次的解决方案--这就是概念架构最重要的意义。另外，所谓“备选架构方案”经常是概念架构一级的，有助于架构的对比分析、评审优化。最后，概念架构为投标、售前、市场宣传等工作提供强力支持 ，所以，概念架构也是售前和市场人员的“必修课”。

7.3. 业界现状

7.3.1. 误将“概念架构”等同于“理想架构”

主动思考以下两种说法是否正确：

架构设计是功能需求驱动的，对吗？
架构设计是用例驱动的，对吗？

说法1，错误。因为，架构设计的驱动力 = 功能 + 质量 + 约束。说法2，同样错误。用例技术是功能需求实际上的标准，用例技术涉及，但无法全面涵盖非功能需求。所以，说法2和说法1并无本质区别。因此，“用例驱动的架构设计”的做法颇值得商榷。纵观业界，有不少书持“用例驱动的架构设计”的观点。比如《Rational 统一过程：实践者之间》一书中有一节名为“是用哪个架构重要用例来驱动架构设计”，其中写道：

对架构重要的用例驱动了架构设计。对于大多数系统而言你通过选择仅仅20%至30%的用例，然后设计、实现并测试每个用例的一两个场景，就能降低大部分技术风险，并驱动欧诺个架构的实现。为了实现某个特定用例，你要识别出那些支持用例的软件元素。

实际上，实践者误认为概念架构就是只考虑功能设而设计出来的理想化架构，其实，这是关于概念架构的最大误解，在实践中应当注意避免 。

7.3.2. 误把“阶段”当做“视图”

“视图”是架构领域的热门词汇，但很不幸，“视图是个筐，什么都往里面装” -- 我们的同行经常犯这种错误。例如，《编程匠义 -- 编写卓越代码》一书中错误的认为：

概念视图，有时候也称为 “逻辑视图”，这种视图显示了系统的主要部分以及它们之间的相互关系。

再例如，一种称为“4视图法”的架构设计方法在业界有一定影响，该方法也误把“概念架构”当成了“概念架构视图”。

其实，视图与视图之间必须是并列的关系，是一种并行思维关系。概念架构不可能与“模块 + 接口”一级的设计并列。概念架构不是一个“架构设计视图”。

正确的做法是，概念架构是一个“架构设计阶段”，必须在细化架构阶段之前，针对重大需求、特殊需求、高风险需求，形成稳定的高层架构设计成果。

阶段之于方法的意义和视图大不相同：

阶段是先后关系，视图是并列关系，这其中有本质区别。
不同阶段解决不同层次的问题--概念架构确定架构设计的大方针。
阶段应该与明确的里程碑想对应--概念架构确定的是高层分割方案及其他重要决策是否合理？

7.4. 实践要领

很多有经验的架构师已经意识到概念架构的重要性，却缺乏理性方法的指导。我们来讲讲ADMEMS方法Conceptual Arch阶段的核心理念和3个步骤。

7.4.1. 重大需求塑造概念架构

ADMEMS方法Conceptual Arch阶段的核心理念：重大需求塑造概念架构，这里的“重大需求”应涵盖功能需求、质量及约束3来需求中的关键部分。

概念架构针对重大需求、特色需求、高风险需求，给出高层次解决方案

问题1：过于理想化
问题2：未来修改很大

如果只考虑“功能需求”来设计概念架构，将导致概念架构沦为“理想化架构”，这个脆弱的架构不久就会面临“大改”的压力，甚至直接导致投标等工作失败。

7.4.2. 概念架构阶段的3个步骤

概念架构设计分为3个步骤：

初步设计 ：基于关键功能，借助鲁棒图进行以发现职责为目的 的初步设计。这一步并不总是需要，但对于架构师而言，是“新系统”就必须重视这一步。
高层分割 ：对系统这个黑盒子进行高层切分 ，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
考虑非功能需求 ：概念架构 ≠ 理想化架构 ，所以不仅要考虑功能，也必须考虑非功能。

下一节：好的开始是成功的一半。 -- 谚语

所谓鲁棒性分析时这样一种方法：通过分析用例规约中的事件流，识别出实现用例规定的功能所需要的主要对象及其职责，形成以职责模型为主的初步设计 -- 温昱，《软件架构设计》

Conceptual Architecture阶段包含3个步骤：

第1步，初步设计。
第2步，高层分割。
第3步，考虑非功能需求。