面向对象分析与设计——实战
7 实战
7.1 管理和计划
强有力的、积极主动管理和指导项目活动的项目领导的重要性。
7.1.1 风险管理
软件开发经理管理非技术风险，项目架构师管理技术风险。
技术风险包括：继承结构的选择、机制的选择
非技术风险：监督第三方厂商交付，管理客户和开发团队间关系，分析期间发现真正的需求
对微观过程，固有的不稳定性，需要采取积极的计划来强制结束
设计开发的宏观过程
OO项目的不同之处在于任务调度和产品评审与其他系统有一些差别
7.1.2 任务计划
大中型项目，每周一次团队会议（讨论已完成和即将进行的工作）
小频率会议对促进交流有必要，但不能过多（项目失去方向的信号）
OO开发需要每个开发人员有大量时间可支配
团队会议：微调进度，洞察隐现的风险
调度宏观过程可提交的产品。
评估即将面临的和长远的风险，必要时集中开发资源处理这些风险（如果没有主动攻击风险，就会被其攻击）
不受过于乐观的计划支配：开发团队的校准标准和工具
管理团队对每一个开发人员可能遇到的附加因素做出计划
管理团队认识各成员的真实生产率，开发人员更准确估工
尽早交付架构方面的发布版本，尽早使用工具
7.1.3 开发评审
对用例场景和系统的架构进行正式评审，对较小技术问题进行非正式评审
用例场景正式评审：团队分析员（精通用例开发）、领域专家、其他最终用户，开发人员在场，含QA（测试员）。贯穿分析阶段。
架构评审：系统的整体结构，包括类结构和机制。架构师和其他设计人员领导。
早期注重于系统架构问题，以后聚焦于某个组件或具体的普遍机制。
在早期确认设计的有效性，沟通架构愿景；增加架构可见度，发现模式和协作，便于简化
7.2 人员配备
7.2.1 资源配置
OO过程重点在架构设计上，架构师和其他设计人员在开发早期加快工作，甚至在分析后期就催促其进行探索。后续增量中，需要的资源通常更少，测试所需资源也更少。
测试一个在早期进行，自证是一个累计而非单独的活动。集成所需的资源也更少，因为增量式发生
7.2.2 开发团队角色
角色： 项目架构师；组件主管；应用工程师
架构师： 梦想家。中小系统，由一两个具有独特洞察力的个人负责。对大型，由团队负责
不一定是最高级开发人员，但是最有资格去制定战略决策的人
有丰富经验，凭直觉就能够判断出给定领域有关的通用架构模式，存在什么问题
具有编程经验，精通表示法，过程和工具（根据类的聚集和对象的协作来展示愿景）
架构师最好参与全程（熟悉系统，接受架构决策的结果等）
组件主管：设计一个完整的组件，设计、保护和商讨组件接口，指导其实现
类聚集和机制的拥有者，负责系统的测试和发布
精通表示法和过程。比架构师更好的设计员和程序员，但比架少经验；占1/3~1/2
应用工程师：完成一项或两项职责。在组件主管的监督下实现一个组件。
可以含设计类，通常实现类，单元测试；使用类，组装类来完成用例场景
熟悉表示法和过程，但不必是这方面的专家；是非常优秀的程序员，占一半或更多
大型项目：
项目经理 负责项目的交付、任务、资源和日程安排的动态管理
分析员 演化和解释最终用户的需求，是问题域内的专家，不脱离开发图案段
复用工程师 管理项目的类、组件和设计的仓储，寻找共同点，生产和改造通用的类和组件
质量保证员 度量开发产物。指导原型、产品发布的系统级测试
集成经理 组装已发布组件的兼容版本，以便组成一个可交付版本，维护发布产品的配置
文档编写员 产出产品及其架构的最终用户文档
工具编制工程师 创建和改编方便生产项目移交物的软件工具
系统管理员 管理项目使用的物理计算资源
7.3 发布版本管理
7.3.1 配置管理和版本控制
对组件做版本控制。代码、用例规格、可视化模型、软件架构文档等都需要配置管理
7.3.2 集成
一个宏观过程生产一系列可执行的发布版本，每一个都有新增功能
7.3.3 测试
开发过程期间持续进行。
（1） 单元测试：单个类和机制的测试，由实现结构的应用工程师负责
（2） 组件测试：一个完整组件的集成测试，由组件主管负责，可用作组件的回归测试
组件泛指，一个或一组，或一个子系统，相对于项目大小
（3） 系统测试：系统整体的集成测试，有质量保证团队负责。也用作回归测试
每个级别，聚焦于测试对象的外部行为；
将系统推向极限，以了解在某些条件下如何发生故障
7.4 复用
7.4.1 复用的元素
用例场景、设计、代码、文档都可复用
类是首要复用工具：可被子类化，特化或扩展基类；
可以惯用法、机制和框架的形式复用类、对象和设计的模式；
以组件形式复用协作的类；相对单个类，框架和模式复用处在更高抽象级别
复用的比例数值无法起衡量作用，易产生误导；有复用总比没有强
7.4.2 建立复用制度
复用不会自发产生，必须制度化；积极寻找复用的机会并奖励
这就是把模式提取作为一个明确活动包含在宏观过程的原因
由专人负责领导，通过架构评审识别共同点，鼓励复用
购买商业类和组件来协助开发
复用短期消耗资源，有长期回报
7.5 质量保证和度量
7.5.1 软件质量
整个软件产品使用的适应性。
一个简单的、可修改的架构是所有高质量软件的关键
缺陷bug率曲线比数字更重要，应该为钟形
对每个增量发布版本，都应该执行一个系统测试，并画出曲线
缺陷率：在大约10000行代码被检查后达到一个稳定值，并保持不变
80%的缺陷在20%的系统类中被发现
7.5.2 面向对象度量
过程度量
● 应用规模
场景脚本的数目（NSS） 关键类的数目（NKS） 支持类的数目（NSC） 子系统的数目（NOS）
● 人员规模
每个类人-天数（PDC） 每个开发人员类数（CPD）
● 调度
主要迭代的数目（NMI） 已完成的合同数目（NCC）
进度测量：关键接口的稳定性，后期即使要改，通常向上兼容
CK产品度量（设计度量）：
- 每个类的加权方法（WMC）：规模
- 继承树的深度（DIT）
- 孩子的数量（NOC）
- 对象类间的耦合（CBO）：耦合
- 类应答数（RFC）：耦合
- 方法内聚缺乏度（LCOM）
7.6 文档化
7.6.1 开发遗产
可视的模型：用例图展示需求；活动图-用例场景的细节；类图-关键抽象；状态机图-状态相关类；序列图-系统功能时对象的协作；组件图-类到组件的映射
7.6.2 文档化的内容
- 高层系统架构文档
- 系统架构的关键抽象和机制的文档
- 系统关键方面的相关行为的场景文档
糟糕：逐个类对每个方法的语义作孤立的描述，无协作（生成无用的文档）
7.7 工具
7.7.1 工具种类
支持UML的可视化建模工具
软件配置管理和版本控制工具（组件为配置管理单元）
类库工具（如果查找组件成本高于新建，则不会复用）
7.7.2 组织上的意义
复用工程师：维护类库。鼓励复用
工具编制工程师：有集成工具套件的最佳情况下，不需要，系统管理员管理集成套件
7.8 特殊主题
7.8.1 领域特定问题
开发高效的用户界面：更多偏向艺术而非科学
原型使用是必要的；用例场景的生成能高效地驱动用户界面分析
数据库组件（遗留数据），用分离关注原则；将这些数据库的访问封装在已经定义良好的接口类的界限之内。
实时系统：以用户为中心，亚秒级；对数据获取，亚微秒级；防止过早发生优化。聚焦于产生简单的架构，发布版本逐代演化
遗留系统：不能放弃，但维护费难忍，随时间推移，需要被取代；可将其封装在定义良好的接口类的上下文之中，随时间推移，移动架构覆盖范围，以取代遗留系统的功能（架构愿景有必要，逐步替代并非不一致的修补）
7.8.2 采纳面向对象技术
如何开发面向对象设计的能力：
● 为开发人员和管理人员提供以下正式培训
UML
要使用的OOAD过程
要使用的工具
要使用的语言和库
● 先在一个低风险项目中使用OO开发，让团队通过以下途径学习
使用有经验的OOAD顾问作为项目团队的导师
培养团队中的高手，让他们作为OO方法的导师，去其他项目播种
● 向开发人员和管理人员展示设计良好的面向对象系统
通过例子来学习通常直接和高效。从分析师做起，逐渐成长为设计角色；从设计人员开始，使用现有的结构良好的抽象。
7.9 面向对象开发的好处和风险
7.9.1 面向对象开发的好处
采纳的原因：寻求竞争优势；项目复杂，似乎没有其他解决方案
好处：采用人类的认知来工作；使系统更便于修改；鼓励复用；减少开发风险；利用OO语言的表现力
7.9.2 面向对象开发的风险
【OO概念列表】
- 用一种方法定义架构和数据结构实例
- 通过抽象和封装达到信息隐藏
- 继承以组织相关的元素
- 多态以自动适配所操作结构的类型来执行操作
- 特化的分析和设计方法
- 面向对象语言
- 促进创建面向对象系统的环境
- 按契约设计，解决模块边界和接口问题
- 内存管理，可以自动回收不使用的内存
- 分布式对象，促进创建强有力的分布式系统
- 对象数据库，超越关系数据库管理系统的数据类型限制
【风险】
- 人员短缺
- 不现实的进度、预算和过程
- 商业现货产品、外部组件或遗留软件的短缺
- 需求或用户界面的不匹配
- 架构、性能或质量不过关
- 持续的需求变更流
- 外部执行任务不足
- 曲解计算机科学