第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的后端处理以及应用程序和业务逻辑层之间的任何绑定。 在完美的世界里，这个层不会包含任何业务领域的逻辑，纯粹的软件编程。
业务逻辑层（BLL）包含特定于业务领域的逻辑，与特定的业务领域强相关。 另外，如果要创build一个单独的BLL，该层应该包含其他应用程序可以使用的逻辑以及这个逻辑。 例如，一组Web服务暴露了一个定义良好的API。 这将BLL与您的应用程序分离开来，并使您可以灵活地在将来构build其他应用程序。
业务层负责业务决策和涉及客户协议的逻辑。
应用程序层是与业务决策无关的原始进程。
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：备选设计
