软件架构设计的方法论—分而治之与隔离关注面

12
光有宏观的过程、方法还不够
z无论是简单的问题解决步骤，还是包含了大量实践 活动的软件过程域（科目），它们都属于宏观的解 决途径。然而，任何软件问题，其最终解决还是要 落实到具体的细节之上，这些问题细节需要采用与 之相对应的微观方法来解决。 z例如，架构设计作为技术解决过程域中的一项实践 （或者分析设计科目中的一项活动），涉及到大量 的模块划分问题；而帮助人们进行划分的方法则主 要有比较、分类等思维法。
6
简单问题解决步骤的不足
z前段中所描述的问题解决步骤，存在一个隐 含的假定前提，就是所有问题都能够采用同 样简单的方法、步骤来加以解决。对于那些 普通、单一的问题而言，这个假定是成立 的；但对于软件开发这种复杂和多方面问题 交织在一起的情况，假定就不再成立了。 z实际上，软件具有不一致性与多样性，不同 性质的软件，不相同的地方很多，所适应的 开发方法也可能完全不同。
定义过程
Define the Processes
开发产 品交付
工程Engineering过程域
Requirements Management Requirements Development Technical Solution Product Integration Verification Validation
30
示例：封装
将实现从客户角度隐
藏 客户只依赖于接口
31
抽象 vs 封装
9抽象和封装都是一种简化问题的思维模式， 但它们实现简化的方式不同: • 抽象剔除了不相关的内容，以突出重点； • 相对应地，封装则隐藏了相关但不需要被知道 （不能被剔除）的内部细节，以减少依赖。 9剔除与隐藏对于外部（客户）而言，其效果 是等价的
16
多边形对象集合关系示意
多边形 Polygon
四边形 Quadrangle 矩形 Rectangle
三角形 Triangle
五边形 Pentagon
归类法识别的多边形类层次
18
抽象与软件的表述 ——抓住软件问题的要害与根 本，简化构架设计处理的内容
19
软件表述——开发的前提条件
抽象表述 （Abstract） 问题域 （Problem Context）
13
过程、活动与思维法层次结构示意
过程层
过程域＃1 Process Area 1 过程域＃2 Process Area 2 过程域＃n Process Area n
实践/活动＃1 Practice 1 问题解决周期#1 problem solving 问题解决周期#2 problem solving 问题解决周期#n problem solving
33
层次化Hierarchy
9所谓层次化是指任何组织成为一种树状结构 的抽象级别或顺序； 9在面向对象的范式中，层次结构包括：
25
模块化Modularity
9所谓模块化是指逻辑和物理上将事物 分解为更小、更简单的分组（例如需求 和类），从而满足软件工程化管理的需 要； • 模块化的实质——“分而治之”； • 在面向对象的范式中，子系统、包、构 件和对象本身都是模块化的实体元素。
26
示例：模块化

将较大规模、复杂的系统分解 为可以管理的分块
软件架构设计的方法论 ——分而治之与隔离关注面
胡协刚
中国软件架构师网 首席软件架构师
szjinco@public.szptt.net.cn Tel: 13828737199
Agenda

问题解决规律 软件架构设计中的方法论 抽象与软件的表述 模块化与分而治之 封装和层次化 隔离关注面 隔离关注面的主要示例——架构中的分层 隔离关注面的主要示例——架构机制的抽取 隔离关注面的主要示例——AOP与分割横切面
22
示例：抽象
Salesperson
Customer
Product
23
模块化与分而治之 ——构架设计中的管理学，以分 工协作来扩展团队解决复杂软 件问题的能力
24
抽象解决不了软件中的规模问题
9抽 象 能 够 很 好 地 降 低 单 个 软 件 元 素 的 复 杂 度，但却解决不了软件中的规模问题 • 根据 7 ＋ / － 2 原则，人能够同时处理的元素是 5～9个，当软件中对象（种类）的数目超过一 定限度后，人们就无法同时去思考和处理这些 对象了。 9模块化通过划分，帮助人们将同时要考虑的 对象数目减少到普通智力的人能够胜任自如的 地步。
29
封装Encapsulation
9所谓封装是指将特性（属性、行为）在物理 上局限于一个单独的黑盒抽象中，且将它们 的实现（和相关的设计决定）隐藏于公共接 口背后； 9在面向对象的范式中，从系统、子系统到对 象都拥有封装的特性。
z抽象类（还有接口）使得客户代码client code只需要关注 对象外在行为中与它相关的部分（忽略对象固有的但并不相关 的其它外在行为，例如从其它类继承的操作）； z对象的封装机制则封闭了对象所有的内部结构和内部行为， 使得客户代码无需关注对象内部的细节。
监控问题解 决计划的执 行
评估与验收问题解决结果
8
软件开发过程原理
以往软件 项目 以往软件 以往软件 项目 项目
经验总结 为规范化 软件过程 软件 过程 QA监督实际开发 活动执行了过程 规范——确保开 发过程质量
业界经验
经理 顾客
规范化
化 实例
业务
表述（抽象） QC确保 每个中 间制品 的质量
职员
实践/活动＃n Practice n
活动与问题 解决层
问题解决周期#n problem solving 问题解决周期#1 problem solving
比较思维法 分类思维法 类比思维法 综合思维法 分析思维法
归纳思维法
想象思维法 直观思维法
演绎思维法
微观方法层
问题解决类型与思维法关系示意
直观思维法
控制过程的执行
Control the Processes
Configuration Management Process and Product Quality Assurance Measurement and Analysis
Causal Analysis and Resolution Decision Analysis and Resolution Organizational Environment for Integration
实现（分 析）
Analysis Model
精化（映 射）
软件交付
实施（转 化） QC确保 每个中间 制品的质 量
定义（引申） Use-Case Model
Design Model
CMMI过程域关系示意图
过程管理Process Management过程域
Organizational Process Focus Organizational Process Definition Organizational Training Organizational Process Performance Organizational Innovation and Deployment
用例模型（需求）
影响（映射）
现实具象 （Concrete）
定义（抽象） 经理 顾客 职员
业务
需要 支持（运行）
解决域 （Solution Context）
限制（反作用）
规定（实现）
设计模型（架构）
被描述
软件交付
基于对象的软件系统观
交互 操作 对象实例
属性 操作
消息 对象实例
属性 操作
连接
Actor
7
先选择方法的问题解决流程示意图
明确问题的性质与特点 如问题没能被解 决，往往需要选 择新的方法再次 去尝试
选择适合解决本类问题的方法（过程）
依照既定的方法（过 程）制定问题解决计划
通常是若干 基本问题解 决周期的某 种有机的组 合排列
分配人力及其它资源，执行问题 解决计划，直到问题被最终解决 贯彻既定方法（过程） 中定义的步骤，寻求并 实施最佳解决方案
计划执行 型
想象思维法
变更纠 正型 辨识表述 型 设计实施 型 度量核实 型
收集检索 型
分析揭示 型
比较思维法
类比思维法 分析思维法
综合思维法 归纳思维法 演绎思维法
分类思维法
示例：归类法在软件开发中的运用
z所谓分类是指根据研究对象的共同点和 差异点，将其区分为不同种类的一种逻 辑思维方法。 z在分类时，按共同点将研究对象归为较 大的类，而按差异点将研究对象区分为 不同的较小类（即大类集合中的较小集 合、或元素）。
Order Entry
Order Processing System
Order Fulfillment
Billing
27
封装和层次化 ——构架设计中的划分与组织技 巧，帮助团队不断提升所开发 软件的规模数量级
28
模块化带来模块之间关系处理问题
9将系统划分为若干模块后，人们可以分别在各模块 内部处理那些数量已大幅减少的元素；但为了确保系 统的完整一致，人们同时还必须在系统层面来处理这 些模块及其之间的关系。 • 根据 7 ＋ / － 2 原则，人能够同时处理的元素是 5 ～ 9 个，但此间实际上还有一个隐含的条件，就是每个元 素本身的复杂度也不超过一定限度。由此，如果模块 对外展现的内容过多，人们仍然是无法在系统层面处 理这些模块（及其关系）的。 9封装在模块化划分的基础上进一步简化了模块本身 对外暴露的复杂度。
2
问题解决规律 ——人类如何解决复杂问题
3
问题解决 Problem Solving
z问题解决是思维的一种形式；当个人或组织 不知道如何从已知条件得到目标（期望结 果）的时候， “解决问题 ”这一智力活动便开 始了。
4
问题解决流程示意图
识别与澄清问题
收集相关信息 如问题没能 被解决，则 再 次 尝 试 （下一轮解 决周期）
支 撑 过程 的执行
Support the Processes
支持Support过程域
软件架构设计中的方法论 ——微观思维方法在软件开发 中的运用
11
破除软件开发中的神秘主义
z国内软件界存在一定程度的神秘主义倾向，在自己 无力使用常规软件工程途径解决软件问题后，往往 简单地将软件开发归于艺术化、玄学化。 z经常看到的一种典型现象——某个高手熬了几个通 宵，终于拿出了一个精巧的设计方案；团队其他成 员都很钦佩他，并想向他学习其中设计的技巧；但 高手吹嘘说这完全是靠其灵感所得，思考过程毫无 逻辑可言。
对象实例 对象实例
属性 操作 属性 操作
பைடு நூலகம்
外 部 系 统
消息
对象实例
属性 操作
目标系统
抽象abstraction
9所谓抽象是指关注事物中与问题相关 的部分（通常是一个角度或方面），而 忽略其它不相关内容（细节）的一种思 考方式； • 抽象依赖于选择的问题领域和角度； • 在面向对象的范式中，使用从问题域的 抽象来表达目标系统（例如对象和 类）。
32
简单模块化仍处理不了大规模问题
9模块化通过划分来简化问题，但是简单的模 块化途径仍然处理不了大规模的事物 • 根据 7 ＋ / － 2 原则，人能够同时处理的元素是 5 ～ 9 个；那么针对一个具有 1000 个元素的系 统，我们当然可以将其划分为 150 个模块，这 样每个模块的元素不超过7个，可以交给150个 人来分担完成；但是同时为了确保系统的完整 和一致，需要有人来协同 150 个人的工作，而 这显然... 9层次化为模块化划分提供了一种递归途径， 以支持处理更大规模的事物
分析问题和评估已有信息
考虑各类解决方案选 项与结论
选择并实施最佳解决方案
5
软件开发的方法（理）论框架基础
z软件被用来解决人们的业务或领域问题，开 发软件的过程就是去获得解决业务问题结果 的过程。 z人类在问题解决规律研究方面已经有大量的 现成成果；传统的问题解决步骤，实际上为 软件开发（解决软件问题）提供了现成的 （战略级的）理论方法框架。 z现代的软件工程技术，其基础实际上就建立 在这些问题解决规律之上。
项目管理Project Management过程域
Project Planning Project Monitoring and Control Supplier Agreement Management Integrated Project Management Integrated Supplier Management Integrated Teaming (IPPD) Quantitative Project Management Risk Management