顶级设计者在设计中并不是按部就班地采用自上而下(或自下而上)
的方法，而是着眼于权重更大的目标。这些目标通常是难点问题，
设计者不能轻易地看出这些问题的解决方案。为了得到整个问题的
设计方案，设计者必须先致力于难点的设计并消除其中的疑惑
——《软件工程的事实与谬误》
CA概念架构就是对系统设计的最初构想，就是把系统最关键的设计要素及交互机制确定下来，然后再考虑具体的技术应用，设计出实际架构。概念架构阶段主抓大局，不拘小节，不过分关注设计实现的细节内容。
概念架构阶段的特点：
Ø满足“架构=组件+交互”的基本定义(所有架构都逃离不了该模式)
Ø对高层组件的“职责”进行笼统界定，并给出高层组件的相互关系
Ø不应涉及接口细节
在讲具体的概念架构设计实践之前，请大家思考以下问题：
Ø不同系统的架构，为什么不同？
Ø架构设计中，应何时确立架构大方向的不同？（功能、质量、约束）
一、业界现状
- 误将“概要架构”等同于“理想架构”
架构设计是功能需求驱动的，对吗？
架构设计是用例驱动的，对吗？
实际上架构设计的驱动力：功能+质量+约束
- 误把“阶段”当“视图”
概要架构阶段还是概念视图？
阶段体现先后关系，视图体现并列关系
概要架构阶段根据重大需求、特殊需求、高风险需求形成稳定的高层架构设计成果
二、主要工作内容和目标
概念架构是一个架构设计阶段，必须在细化架构设计阶段之前，针对重大需求，特色需求、高风险需求、形成文档的高层架构设计成果。
重大需求塑造概念架构，这里的重大需求涵盖功能、质量、约束等3类需求的关键内容。
如果只考虑功能需求来设计概念架构，将导致概念架构沦为“理想化的架构”，这个脆弱的架构不久就会面临“大改”的压力，甚至直接导致项目失败。
- 概念架构的三个步骤
整体可分为3个阶段：
- 初步设计
- 高层分割
- 质疑驱动
1. 初步设计
初步设计的目标就是发现职责，运用“职责协作链”原理画鲁棒图。
鲁棒图的三种对象
•边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入、处理内部内容的解释、并表达或传递相应的结果。
•控制对象对行为进行封装，描述用例中事件流的控制行为。
•实体对象对信息进行描述，它往往来自领域概念，和领域模型中的对象有良好的对应关系。
初步设计原则
•初步设计的目标是“发现职责”，为高层切分奠定基础
•初步设计“不是”必须的，但当“待设计系统”对架构师而言并无太多直接经验时，则强烈建议进行初步设计
•基于关键功能（而不是对所有功能）、借助鲁棒图（而不是序列图，序列图太细节）进行初 步设计。
2. 高层分割
运用成熟的经验及方法论，结合场景选择合适的架构模式(参看《架构师之路(四)之十二个架构模式》)来确定系统的层级关系。
针对高层分割，我们可以采取分阶段的模式来进行落地实践：
- 直接划分层次：直接把系统划分为多个层次，梳理清晰各层次间的关联关系
- 分为2个阶段：先划分为多个子系统，然后再梳理子系统的层次，梳理清晰没格子系统的层次关系
针对分层模式的引入，这里分享几类划分模式及方法：
- 逻辑层：逻辑层，上层使用下层观念；不关注物理划分，也不关注通用性
- 物理层：分布部署在不同机器上
- 通用性分层：通用性越多，所处层次越靠下
3. 质疑驱动，不断完善系统架构
基于系统中的重大功能来塑造概念架构的高层框架，过程中需要通过质量及约束等非功能性需求不断质疑初步的概念架构，逐步让这个概念架构完善，能够满足及支撑各类质量及约束的要求。具体的操作方法我们可以采取之前《架构师之路(六)之ADMEMS方法论》中介绍的 “目标-场景-决策表” 来实现。
Ø通过“目标-场景-决策表”分析非功能需求：
通过分析关键的质量及约束内容，给出具体的场景及应对策略，梳理出清晰的决策表，在概念架构阶段融合决策表中给出的方案，最终给出初步的概念架构设计。
64
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
