第9章 概念架构设计
概念架构设计能够获得顶级的概念性组件模型，但没有想象的接口定义和细化的组件。
其中鲁棒图既能否进行组件发现，也能够组件的分层，以及展现组件之间的关系。
概念架构与领域建模的主要区别是：
- 领域建模：关心的是系统展现出来的外部行为和期望，属于需求描述。
- 概念架构：关心的是系统内部的功能模块划分，是属于设计描述。采用鲁棒图进行标准化模块建模：边界类+控制类+实体类。
- 领域建模：是对用例图需求的深化，是对用例图需要的进一步展现，属于需求描述
- 概念架构：是对用例图需求的设计，是对用例图需要的架构实现！，属于架构设计
9.1 概念架构是什么
9.1.1 概念架构是直指目标的设计思想、重大选择
9.1.2 案例1：汽车电子AUTOSAR——跨平台复用
NA
9.1.3 案例2：腾讯QQvideo架构——高性能
NA
9.1.4 案例3：微软MFC架构——简化开发
NA
9.2 概念架构设计概述
9.2.1 “关键需求”进，“概念架构”出
9.2.2 概念架构≠理想化架构
9.2.3 概念架构≠细化架构
概念架构设计的三大组成：
- 功能组件分层图：以分层的方式展现系统内部的主要功能组件，功能组件的切分分为横向切分和纵向切分。
- 鲁棒图：采用标准化的方法，把以用例形式展现的需求转换成内部对象/功能实体的方法。
- 目标—场景—决策表：以表格的形式，结构化的思考结构设计的宏观决策与选择！！！
9.3 左手功能——概念架构设计（上）
9.3.1 什么样的鸿沟，架什么样的桥
备注：
用例需求：是站在系统外部看系统所展现出的外部行为，或者说站在系统外，对系统提出的诉求和期望。此时系统是一个黑盒子。
概念架构设计：把系统这个黑盒子打开，站在系统内部，通过设计内部模块的组织架构，分配内部模块的职责和功能，从而使得系统满足客户对其的期望和诉求。
没有概念架构，只有用例需求，程序员只能根据自己的经验编写代码了。这就导致不同的程序员，编写出来的代码结构千差万别。而概念架构设计，就是把用户的需求，按照规范化的方法，映射成通用的架构，这样不同的程序员编写的代码，不至于千差万别，能够在架构上保持一致。这样编写出来的软件的一致性就比较好，不同的程序员的水平即使相差很大，同样的用户需求，最终实现的程序，相差不会太大。
这就是概念架构设计的重要意义！！！概念架构设计是架构师为程序员搭好了代码的基本框架！！！
同时，为避免了程序员由于缺乏业务领域的知识而对需求产生误解！！！
9.3.2 鲁棒图“是什么”
鲁棒图的作用是：用来解决以用例形式展现的用户需求，如何映射成内部的结构设计，特别是对象设计！！！是把用例需求转换成内部架构/对象设计的一种工具和方法，是把需求转换成需求的桥梁。
鲁棒图使用边界对象、控制对象和实体对象，以标准化方式，抽象和设计所有的用户用例！！！
- 边界对象：系统在实现用例时，系统与外界的边界与接口
- 控制对象：系统在实现用例时，内部的业务逻辑(行为、算法）
- 实体对象：系统是实现用例时，内部的数据存储（数据结构）
鲁棒图与功能组件分层图、目标—场景—决策表一起构成了概念架构设计的三剑客。
鲁棒图的输入是用例图，它能够把用例需求转换成软件内部的设计，因此，在架构设计时，他可以检查架构设计的完整性，检查设计的架构是否已经完成的表达了需求。而分层的功能架构是无法达到这样的效果的，分层的功能架构无法与用例需求完全一一对应，分层的功能，更多是架构师的经验，而不是结构化的方法。
在概念架构设计阶段，主要展现的事关键需求、核心需求。
在详细架构设计阶段，可以展现所有的用户用例需求。
因此，鲁棒图实际上是一种思维方式，思维过程，一种把需求转换成设计的方法！！！
9.3.3 鲁棒图“画什么”
- 应用程序层由特定于此应用程序的那些元素组成。 所以这将包含UI和接口，UI的后端处理以及应用程序和业务逻辑层之间的任何绑定。 在完美的设计里，这个层不会包含任何业务领域的逻辑，纯粹的软件接口编程（UI和外界通信）。
- 业务逻辑层（BLL）包含特定于业务领域的逻辑，与特定的业务领域强相关。 另外，如果要构建一个单独的BLL，该层应该包含其他应用程序可以使用的逻辑以及这个逻辑。 例如，一组Web服务暴露了一个定义良好的API。 这将BLL与您的应用程序UI分离开来，并使您可以灵活地在将来构build其他应用程序UI。业务逻辑的稳定的，应用程序UI是易变的。业务逻辑是“里子”，应用程序是“外表”！
- 业务层负责业务决策和涉及客户协议的逻辑。
- 应用程序层是与业务决策无关的原始进程。
控制对象实现三部分功能：
- 应用程序的后台
- 纯粹的业务逻辑，与应用程序的前后台解耦
- 数据访问逻辑
而实体对象：真正的数据，可以是数据库或数据结构！！！
9.3.4 鲁棒图“怎么画”
9.4 右手质量——概念架构设计（下）
备注：
质量需求并不是以用例的形式展现的，而是以条文的形式展现的。因此，鲁棒图无法实现纯粹的质量需求到架构设计的转换！！！这就需要一种新的方法，把质量需求和约束条件的需求，转换成架构设计的决策和架构设计要考虑的因素！！！这种方法就是目标、场景、决策表格！！！
9.4.1 再谈什么样的鸿沟，架什么样的桥
备注：
质量需求和约束条件，不是以用例的形式存在的（当然，转换成用例的质量需求除外），如何把用文字表达的非功能需求转换成架构设计的需求和要求，就需要新的工具和方法。
9.4.2 场景思维
笼统需求 =》 场景描述 =》 概念设计
在上图中：
指标目标：笼统性的质量需求
场景：明确性的路径
设计决策：根据明确的路径，明确设计决策，以满足笼统的质量要求。
备注:
场景思维的本质是把笼统的质量需求，转换“功能性、场景性、明确化、具体化“需求。
在特定的场景中，体现质量需求！！！
9.4.3 场景思维的工具
备注：
把质量需求转换成特定的场景，原本是需求分析师的责任。
但在现实中，很多需求分析师，只给出功能性需求，非功能性需求都是架构师去挖掘的，更谈不上需求分析师把非功能性需求转换成场景了。这个活，就落在了架构师的身上，如果架构师也没有进行转换，就只能靠程序之间的造化了。
备注：
上述的箭头反应了反向的作用力的过程。
而概念设计时，正好是相反的，即：目标需求，如质量属性 =》分解成质量场景 =》设计决策，决定哪些场景是支持的，哪些场景是不支持的。
9.4.4 目标—场景—决策表应用举例
备注：
在某个场景下，可以有很多if....then.....子场景。
9.5 概念架构设计实践要领
9.5.1 要领1：功能需求与质量需求并重
9.5.2 要领2：概念架构设计的1个决定、4个选择
9.5.3 要领3：备选设计
在项目研发的初始阶段，提供多种可能的设计方案是常态，单一的方案是危险的行为。
特别是复杂的系统，对于技术难点大的部分，提供多种方案是非常有必要的！！！
