面向对象分析与设计——复杂性
第一篇概念
1 复杂性
软件复杂性 → 项目延迟、超预算、有缺陷，
即：软件危机 → 人力资源浪费、机会丧失
1.1 复杂系统的结构
世界是复杂的，以下举例论证。
1.1.1 个人计算机的结构
层次化 → 每一层有一组设备协作，为更高层提供服务
各部件协同工作
各部件为独立逻辑整体
（1.1.2提到，Disk中也有NAND门→基本组件可能存在于不同的高级部件中）
1.1.1 植物和动物的结构
【抽象层】：内外之间有清晰边界，不同抽象层的不同部分间，分离关注
如，叶子各部分协同，作为整体提供叶子功能，但与根各组成部分间很少或无直接交互。
此外更层次有相同点，如：根、茎、叶都由细胞构成，且不尽相同。
没有指导层，各部分(层次)独自工作，每一部分对高层功能作贡献。
动物：细胞 →组织 → 器官 → 系统
细胞为跨领域共性，虽动植物细胞也不尽相同。
1.1.1 物质的结构
恒星、行星、碎块 → 银河系 夸克 → 质子、中子 ； 质子、中子 + 电子 → 原子普适性：重力、电磁力、强相互作用、弱相互作用；能量守恒定律、动量守恒定律；
1.1.2 社会机构的结构
各地办公室 → 分支机构→ 部门 → 子公司 → 跨国公司
机构与个人寿命差别：有些机构临时，有些长期存在，超过个人寿命
各级别内部的个体间关系更紧密（分离关注）
存在适用不同层次的共同机制：如各级别都由同一个财务机构发薪水，共用公共设施等
1.2 软件固有的复杂性
Einstein arguedthat there must be simplified explanations of nature, because God is notcapricious or arbitrary. No such faith comforts the software engineer. Much ofthe complexity that he must master is arbitrary complexity
1.2.1 定义软件复杂性
可被遗忘的应用：由一个人提出、构建、维护和使用；不必服用、修复或扩展。
工业级： 事件驱动或发出驱动；时空为稀有资源；大数据，支持并发更新和查询；
控制真实世界的实体；长生命期，用户依赖于系统；人工智能；
（特征）单人几乎无法理解其设计的所有方面。
1.2.2 为什么软件复杂性在本质上是复杂的
1） 问题域的复杂性
需求复杂性 ← 用户与开发者间沟通不畅（用户需求不明确，或无法准确记录）
需求变更 → 系统随时间推移而发展，这种情况常被错误地称为软件维护
维护：修正错误
演化：应对改变的需求
保护：用极端手段来保持古老而陈腐的软件继续工作（占用相当资源）
2） 管理开发过程的困难性
开发团队的基本任务：制造简单的假象——让用户与外部复杂性隔离
→发明方法以少写代码；或复用已有的设计、代码框架；但仍有不可逃避的需求
→启用开发团队→沟通的复杂；特别是团队在地理上分隔
→管理挑战：维持设计的一致性和完整性
3） 软件中随处可能出现的灵活性
开发者打造几乎所有的初级模块
→但是，软件行业对“原材料”品质很少有统一的标准。
→软件行业是一种劳动密集型的产业（labor-intensive business）
4） 描述离散行为系统的问题
混沌：在非线性科学中，混沌现象指的是一种确定的但不可预测的运动状态。
它的外在表现和纯粹的随机运动很相似，即都不可预测。
但和随机运动不同，在动力学上是确定的，其不可预测性来源于运动的不稳定性。
混沌系统对无限小的初值变动和微扰也具有敏感性，无论多小的扰动在长时间以后，也会使系统彻底偏离原来的演化方向。
软件系统：即便通过分离关注来降级影响，也不可能成为连续系统。
受外界事件影响，或被破坏。穷尽测试几乎无法做到。
1.3 复杂系统的5个属性
1.3.1 层次结构
所有系统都有子系统，所有系统都是更大系统的组成部分。
一个系统所提供的价值肯定来自于各个组成部分之间的相互关系，而非单个组成部分
1.3.2 相对本原
选择什么作为系统的基础组件取决于观察者的判断→是相对，而非绝对的
1.3.3 分离关注
层次系统“几乎可分解”（各部分不是完全独立的）
组件中的高频动作（组件的内部结构）与低频动作（组件间相互作用）分离
1.3.4 共同模式
复杂系统具有共同的模式，小组件复用，子系统共通性等（1.1.2的动植物共性）
1.3.5 稳定的中间形式
系统→复杂系统→更复杂系统，从能工作的子系统逐步发展
1.4 有组织和无组织的复杂性
1.4.1 复杂系统的规范形式
层次结构的两种类型：组成部分(partof) 和 是一种(is a)
→“对象结构”和“类结构”（还有其他，如“模块结构”：动态组件间关系）
（此处类和对象更抽象，非狭义上的类和对象，如1.3.2相对本原所述）
将系统的类结构和对象结构统称为它的“架构”
系统架构的挑战性： 没有特定的“正确的”架构；
在复杂系统5属性和用户需求中寻求平衡
1.4.2 处理复杂性时人的能力的局限
人能同时理解的最大信息数为7±2；接受一组新信息需要5s；
困境：软件系统的复杂性在增加；我们处理复杂性的能力却有局限
1.5 从混沌到有序
工业级软件开发不能总依赖个人灵感，必须考虑一些训练有素的方式来控制复杂性。
1.5.1 分解的作用
控制复杂性 → 分而治之
1） 算法分解
自顶向下的结构化设计
2） 面向对象的分解
3） 算法分解和面向对象分解
各有其重要性。但无法同时使用，两种观点完全正交。
算法强调事件顺序；OO强调代理（要么发出动作；要么是操作执行的对象）
OO的优点：复用机制，得到较小的系统；
应对变化更有弹性（因其设计基于稳定的中间状态）；
降低风险（其思路是从有信息的、较小的系统开始增量式地严谨）；
分离关注（直接关注了内在复杂性）
| 分析和设计方法的分类 方法：一个有规定的过程，目的是生成一组模型，利用某种定义良好的表示法，描述被开发的软件系统的各个方面 方法学：一组方法，适用于软件开发生命周期的各个阶段，由过程、实践和某种一般的哲学统一起来。 绝大多数方法可归为以下三类之一： 自顶向下的结构化设计(组合设计，超过10W行就不行了) 不考虑数据抽象和信息隐蔽问题； 数据驱动设计 系统的输入和输出之间的映射关系驱动着软件系统的结构 面向对象设计 将系统建模为一组协作的对象 |
1.5.2 抽象的作用
不能全面掌握一个复杂对象，就选择忽略它的非本质的细节，转而处理这个对象的一般化的理想化的模型。
对象作为真是世界中实体的抽象，代表了特定的一块密集而内聚的信息。
1.5.3 层次结构的作用
对象结构 (1.5.1) → 不同对象间如何通过一些交互模式进行写作 → 机制
类结构 (1.5.2) → 系统中的公共结构行为 → 抽象
确定层次结构 → 要在许多对象中发现模式
1.6 复杂系统的设计
1.6.1 作为科学和艺术的工程
设计时，我们都试图利用已验证过的抽象和机制（即“稳定的中间状态”，即“已验证过的类结构和对象结构”）作为基础，在此之上构建新的复杂系统。
1.6.2 设计的含义
设计的目的是要构建如下的系统：
- 满足给定的（可能是非正式的）功能规格说明(即，需求)
- 符合目标介质的限制
- 满足隐含的和明确的性能及资源使用需求
- 满足隐含的和明确的关于产品形式方面的设计限制条件
- 满足对设计过程本身额限制，如时间、费用或设计工具
Stroustrup：“the purpose ofdesign is to create a clean and relatively simple internal structure, sometimesalso called anarchitecture. . . . Adesign is the end product of the design process”
1） 建模的重要性
建模引证了分解、抽象和层次结构的原则；在老模型基础上构建新模型；
电子工程师的例子：
组件视图→逻辑视图→散热；线路板布局→物理封装→制造
散热和制造问题可以独立思考。
单个组件的静态连接；组件随时间变化的行为 → 静态、动态模型
2） 软件设计方法学的要素
没有银弹。软件设计方法学的共同要素：
- 表示法 表达每个模型的语言
- 过程 导致有序构建系统模型的过程
- 工具 消除枯燥并强制实现模型本身的规则的工件，可揭示错误和不一致性
3） 面向对象开发的模型
OOAD的方法实现了OO分解。
分离状态空间→提升对软件正确性的信息→降低了开发复杂软件的固有风险
OOD所基于的原则：抽象、封装、模块化、层次结构、类型、并发和持久(第二章)
1.7 小结
- 软件本质上是复杂的，软件系统的复杂性常超了人类智能的范围
- 软件开发团队的任务就是制造出简单的假象
- 复杂性常以层次结构表现出来，“是一种”和“组成部分”层次结构模型是有意义的
- 人类的认识有一些基本的限制因素，可通过分解、抽象和层次结构来克服
- 复杂系统可以从事物或处理过程的角度来分析，采用面向对象的分解有一些令人感兴趣的理由。它将世界看作是一组有意义的对象进行协作，实现某种高级的行为。
- OOAD的方法实现了OO分解。OOD采用了一套表示法和过程来构造复杂软件系统，提供了丰富的模型，可以通过这些模型来阐明目标系统的不同方面。