《Applying UML and Patterns》读书笔记

第1章：绪论

OOAD（Object-Oriented Analysis and Design） & 迭代开发（Iterative Development）

OOD的原则和模式

• 原则：分配职责
• 职责驱动设计（responsibility-driven design）：经典OO设计之象征

第2章：迭代、进化和敏捷

迭代开发是OOAD成为最佳实践的核心。敏捷实践（如敏捷建模）是有效应用UML的关键。 UP是相对流行的、示范性的迭代方法。

2.1 什么是UP & RUP？

UP是构造面向对象系统的迭代软件开发过程。描述了构造、部署以及维护软件的方式。

RUP是UP的详细精化。

• UP鼓励引进其他迭代方法的有效实践。例如：XP的重构，Scrum日常会议等实践 （不管黑猫还是白猫，抓到耗子的就是好猫）

• UP可应用于敏捷方法（XP或Scrum）

2.2 迭代开发（interative development）（iterative and incremental development）

（interative and evolutionary development）

• 每一个迭代（3周）：都有需求分析、设计、实现、测试的活动
• 迭代是时间定量的：关键思想

2.5 风险驱动和客户驱动的迭代计划

UP（及大多数新方法）提倡 风险驱动（risk-driven） 和 客户驱动（client-driven） （用例驱动）相结合的迭代计划。

风险驱动迭代开发更明确地包含了 以架构为中心（architecture-centric） 迭代 开发的实践。意味着早期迭代要致力于核心架构的构造、测试和稳定。因为没有稳定的架构会 带来高风险。

2.6 什么是敏捷方法

敏捷开发（agile development）方法通常是时间定量的迭代开发，提倡增量交付，提倡 敏捷性 （快速灵活地响应变更）。

• 敏捷方法是不可能精确地定义的

2.7 什么是敏捷建模（agile modeling）

建模（构建UML草图等）的目的是为了来理解，而非文档。

• “实行UML”（其真正含义为“实行OOAD”）的目的不是指设计者创建大量详细的UML图并递交 给编程者（这其实是非敏捷的和面向瀑布的思维方式）

2.8 什么是敏捷UP

UP的创始人并没有为其赋予重量级或非敏捷的含义。实际上，UP可以采纳和应用可适应性和轻量级 的精神——敏捷UP。

• 使用UP活动和制品的简集

2.10 什么是UP的阶段

四个主要阶段

1. 初始化（Inception）：大体构想、业务案例、范围和模糊评估
   • 初始阶段不是需求阶段，而是研究可行性的阶段
2. 细化（Elaboration）：精化的构想、核心架构的迭代实现、高风险的解决、确定大多数的 需求和范围、更为实际的评估
   • 细化阶段不是需求或设计阶段，而是迭代实现核心架构并解决高风险的阶段
3. 构造（Construction）：对遗留下来的低风险和简单元素进行迭代实现，准备部署
4. 移交（Transition）：进行beta测试和部署

2.11 什么是UP科目

科目（descipline）：一组活动（及相关制品），例如需求分析中的活动。

制品（artifact）：工作产品的统称，如代码、模型、图等。

本书关注以下三个科目中的制品：

• 业务建模： 领域模型制品
• 需求： 用例模型及其补充性的规格说明制品。
• 设计： 设计模型

开发案例

第5章：进化式需求

5.4 需求的类型

FURPS

• 可靠性（Functional）：特性、功能、安全性。
• 可用性（Usability）：人性化因素、帮助、文档。
• 可靠性（Reliability）：故障频率、可恢复性、可预测性。
• 性能（Performance）：响应时间、吞吐量、准确率、有效性、资源利用率。
• 可支持性（Supportability）：适应性、可维护性、国际化、可配置性。

第8章：迭代1—基础

迭代1：细化（Elaboration）阶段第一次迭代

实际项目中的迭代1应该以框架为核心或是风险驱动的。

8.2 过程：初始和细化

初始阶段

• 简短的需求讨论会。
• 大部分用例的名称
• 详细编写10%~20%的用例
• 风险列表
• 讨论高层架构（只是讨论，并不意味是最终结果）

细化阶段

用一句话概括细化（elaboration）：构建核心架构，解决高风险元素，定义大部分需求，以及预计 总体进度和资源

细化阶段开始构建的制品

• 领域模型：领域概念的可视化，类似于领域实体的静态信息模型
• 设计模型：描述逻辑设计的一组图，包括软件类图、对象交互图、包图等
• 软件架构文档：学习辅助工具，概括关键架构问题及其在设计中的解决方案。该文档是对重要 设计思想及其在系统中动机的概要
• 数据模型：包括数据库方案，一级在对象和非对象表示之间映射的策略
• 用例示意板，用户界面原型：描述用户界面、导航路径、可用性模型等

第9章：领域模型

领域模型是OO分析中最重要的和经典的模型。是其它几个制品的输入。

用例概念和专家的观点将作为领域模型的输入。

用例是重要的需求分析制品，但不是面向对象的。用例强调了活动视图。

9.2 什么是领域模型(domain model)

• 领域模型(domain model)也被称为 概念模型 、 领域对象模型 、 分析对象模型 。

更准确地讲,UP领域模型是UP 业务对象模型 (BOM)的特化,但是本书并不提倡创建BOM(因为 需要在实现前进行大量建模)

• 领域模型的两个传统定义

  • 领域模型是显示世界中对象的概念透视图,而非软件透视图.

  • 领域模型也用来表示”软件对象的领域层”

    本书中通常使用 领域层(domain layer) 来表现领域模型的第二个含义

• 领域模型 不是 数据模型

9.4 如何创建领域模型

以当前迭代中所要设计的需求为界:

1. 寻找概念类
2. 将其绘制为UML类图中的类
3. 添加关联和属性

• 寻找概念类的三条策略

  1. 重用和修改现有的模型( best )
  2. 使用分类列表（ 我个人感觉不是很好 ）
  3. 确定名词短语（ 我个人最常用 ）

方法2：使用分类列表

方法3：通过识别名词短语寻找概念类（对用例文本进行 语言分析（lingguistic analysis） ）

> * 语言分析已经演变得更为完备，同时也发展成为 **自然语言建模**。
* 使用这种方法时必须小心处理自然语言中词语的 **二义性** 

9.7 准则：敏捷建模——绘制类图的草图

9.8 准则：敏捷建模——不需要使用工具维护领域模型

创建领域模型的目的是为了快速理解和沟通大致的关键概念。完美不是目的。领域模型在创建之后通常 很快就被抛弃（即使这样，如果你使用白板的话，我还是建议用数码相机拍下来）

9.16 属性

• 大部分属性类型应该是 简单 数据类型，例如数字和布尔。通常，属性的类型不应该是复杂的 领域概念。
• 领域概念对别的领域概念不应该使用属性，而是应该使用关联。

第10章：系统顺序图

10.3 动机：为什么绘制SSD

因为我么必须为处理和响应这些 系统事件 来设计软件。基本上，软件系统给要对一下三种时间 进行响应

1. 来自参与者（人或计算机）的外部事件
2. 时间事件
3. 错误或异常(通常源于外部)

这些事件是 系统行为（system behavior） 分析的重要部分。

第12章：从需求到设计——迭代进化

12.1 以迭代方式做正确的事，正确的做事

需求和面向对象的分析重点关注学习 做正确的事情 ，后续的设计工作将强调 正确地做事 。

第14章：迈向对象设计

开发者如何设计对象？

1. 编码: 在编码的同时进行设计(Java, C#, … …), 更为理想的是使用诸如再工程 (refactoring)这样的强大工具. 根据想象的模型直接编码.
2. 绘图,然后编码: 在白板或UML CASE工具中绘制一些UML, 然后转到第一种方式,使用文本 增强型集成开发环境(IDE, 如Eclipse或Vsiual Studio)进行编码.
3. 只绘图,不编码: 使用工具从图中生成一切. 众多倒闭的工具提供商都冲向了这一恶岛之滨 . “只绘图”是不当之词, 因为实际上还是会在UML图形元素上附加文本的编程语言.

本章介绍的是在对象设计前进行 轻量级绘图 。

设计对象：什么是静态和动态建模

对象模型有两种类型：动态和静态。

• 动态建模 有助于设计逻辑、代码行为或方法体，例如UML交互图（顺序图或通信图）。动态 模型倾向于创建更为有益、困难和重要的图形。
• 静态模型 有助于设计包、类名、属性和方法特征标记的定义，例如UML类图。

第15章：UML交互图

UML使用交互图来描述对象间通过消息的交互。交互图可以用于动态对象建模。

15.1 顺序图和通信图

交互图分为：

• 顺序图
  • 优势：能够清晰表示消息的顺序和时间排序，大量详细表示法选项
  • 劣势：强制在右侧增加新对象；消耗水平空间
• 通信图
  • 优势：空间效用——能够在二维空间内灵活地增加新对象
  • 劣势：不易查阅消息的顺序，表示法选项较少

15.4

• 创始消息(found message)
• 执行规格条(execution specification bar)
• 控制期(focus of control)
• 实心箭头表示常规的同步消息
• 开放箭头表示异步调用

• 表示应答或返回
  1. 使用消息语法returnVar=message(parameter)
  2. 在活动条末端使用应答(或返回)消息线

• 发送给”自身”的消息

• 实例的创建

• 常见的图框操作符

• 如何关联交互图

第16章: UML 类图(class diagram)

第17章: GRASP:基于职责的设计对象

有时候，OOD会被解释为：

首先明确你的需求并创建领域模型，然后为适当的类添加方法，再定义对象之间的消息以实现需求。

17.1 UML与设计原则

对象思想是本书的主题。最关键的软件开发工具是受过良好设计原则训练的思维，而不是UML或任何 其他技术。

17.2 对象设计：输入、活动和输出

• 输入
  • 需求讨论会
  • 确定第一个迭代的主要关注点
  • 详细分析10%到20%的需求
  • 其他制品启动：补充规格说明、术语表和领域模型
  • 编程实验已经解决相关的技术问题
  • 大型逻辑架构的构思

所有的制品都是可选的，也许是为了降低某种风险而创造的。

• 活动
  • 给定一个或多个输入，开发者有以下三个选择：
    1. 立即开始编码
    2. 开始为对象设计进行一些UML建模
    3. 利用其他建模技术，如CRC cards
  • 在UML案例中，真正要关注的不是UML，而是可视化建模。
  • 更为重要的是，在绘图活动中，我们要运用各种OO设计原则，如GRASP和GoF（四人帮）设计模式
  • OO设计建模总的来说，基于 职责驱动设计（RDD） 所代表的含义是考虑怎样给协作中 的对象分配职责
  • 我们绘制模型主要是为了理解和沟通，并不是为了编写文档
• 输出
  • 尤其对于对象设计而言，我们期望在开始编程之前针对设计中的难点创建UML交互图、类图、包图
  • UI的草图和原型
  • 数据库模型
  • 报表的草图和原型

17.3 职责和职责驱动设计

思考软件对象设计以及大型构件的流行方式是，考虑其 职责、角色和协作 。这是被称为 职责驱动设计 的大型方法的一部分

17.4 GRASP： 基本OO设计的系统方法

理解在对象设计中如何运用GRASP是本书的一个关键目标。

所以,GRASP是有意义的,但另一方面,它只是对原则进行结构化和命名的一种学习工具。一旦你掌握 了这些基本原则，特定的GRASP术语（信息专家（Information Expert),创建者（Creator），…) 就不重要了。

17.6 什么是模式

• 学习GRASP和基本GoF模式是本书的关键目标

• GRASP是一组 原则

17.9 在对象设计中应用GRASP

GRASP是通用职责分配软件模式（General Responsibility Assignment Software Patterns） 的缩写。

GRASP是设计OO系统的基础

GRASP的九种模式如下：

• 创建者（Creator）
• 信息专家（Information Expert）（OO设计中有效、核心的原则）
• 低耦合（Low Coupling）
• 控制器（Controller）
• 高内聚（High Cohesion）
• 多态性（Polymorphism）
• 纯虚构（Pure Fabrication）
• 间接性（Indiretion）
• 防止变异（Protected Variations）

Dawson Lee

A man who loves to watch Korean dramas