1.1 在 OOAD 中使用 UML 和模式

• OOAD 的目标是设法生成一个高质量的软件‘蓝图’
• UML 是用来绘制软件‘蓝图’的符号语言
• 是一种思考和交流的工具
• 模式（Pattern）是已命名的，针对一个问题的，经过反复验证的一种优化解决方案
• 软件开发中的一些指导原则（Principles）
• UP（Unified Process）是一种指导软件开发活动的方法
• 本书是在 UP 的指导下，以一个案例（POS）为红线介绍 OOAD

1.2 分配职责

• 用OOAD开发出的软件系统是由一组相互合作的对象组成
• 很象现实生活中的团队合作
• 应该包含哪些成员？ （OOA）
• 各个成员的职责是什么？ （OOD）
• OOAD中最关键，最基本的技能是如何熟练的为软件组件分配职责
• 必不可少的一项活动，且对软件质量影响很大
• 比较难以掌握的一种技能
• GRASP 模式：关于对象设计和职责分配的一组基本原则

1.3 什么是分析和设计？

• 分析强调的是对问题和需求的调查研究（What?)
• 需求分析 － 对需求的调查研究
• 对象分析 － 对领域对象的调查研究
• 设计强调的是一个能满足需求的（概念上的）解决方案(How?)

1.4 什么是OOAD？

• OOA 强调的是在问题领域内去发现对象或概念
• 问题领域指的是需要开发的软件系统的背景领域
• 问题领域随着软件系统的不同而不同
• 问题领域涉及的都是已经存在的实体或概念
• OOD 强调的是如何定义软件对象及他们之间的协作方式来满足需求
• 软件对象大都是受领域对象的启发而得到的
• 在很多情况下软件对象和领域对象一一对应
• 但软件对象之间协作方式的定义却没有这么直观

一个 OOAD 的例子

　1.5 OOAD 举例: 掷骰子游戏（软件）

• OOAD 过程的主要活动
  – 定义用例 （需求获取）
  – 定义领域模型 （OOA, 对象分析）
  – 定义交互图 （OOD, 对象设计）
  – 定义设计类图 （OOD, 对象设计）
  
• 定义一个用例（简化的例子）

用例名: 玩掷骰子游戏

参与者: 玩游戏者

用例描述: 玩游戏者一次掷两个骰子，如果两个骰子的面值相加为七则赢

定义领域模型

　– 在做OOAD时, 我们先创建一个问题域的对象模型，然后在此对象模型的基础上构建一个求解域的对象模型（软件蓝图）
　– 问题域的模型的创建是通过识别问题域中的相关概念，概念的属性和相互关系，并将其用UML符号表示出来而完成的

• 定义交互图
  • 利用交互图来探索领域模型中的对象应如何合作来实现软件系统的需求
  • 交互图有两种形式（语义等价的）
    – 顺序图（Sequence Diagram）
    – 合作图（Collaboration Diagram）
    
• 对象间的合作是通过一个对象向另一个对象发送消息（请求服务）来实现的

　定义设计类图

• 在领域模型概念类的基础上定义设计类
• 设计类与软件实现（Java, C++）类相对应

　迭代开发和统一过程

• 简 介
• 现代软件的两个突出特点是复杂和多变
• 软件规模变得越来越大
• 从软件的构思开始至软件停止使用充满了变化
• 迭代开发是能很好地适应这两个特点的一种巧妙的方法
• 主动迎接变更，不断反馈和调整
• 统一过程（UP）是综合了当前最佳实践经验的一种流行的迭代开发方法
• 迭代的软件生命周期
• 风险驱动
• UP中一个最重要的思想: 迭代（方式的）开发
• 整个软件工程的开发活动被组织成一系列时间长度确定的小的工程开发活动，每个小的过程称之为一个迭代
• 每个迭代有它自己的需求分析，设计，实现和测试活动

　通过迭代使系统向用户的真实需求收敛

需求用例模型

• 需求的基本概念
• 用例建模（Use-Case Modeling）
• 用例的种类和书写格式
• Actors，Goals和用例的发现
• 用例图

理解需求

• 定义：需求就是系统必须提供的能力和必须遵守的条件
  　– 能力 ＝》 功能
  　– 条件 ＝》 约束
• 需求获取中的挑战
  　– 如何发现需求
  　– 如何进行需求的交流
  　– 如何记录需求
  　– 如何管理需求
• 软件开发中的一个独特事实是：软件的需求总是在变化的
• 需求的有效管理称为软件开发的一个关键问题
  　– 希望在分析和设计之前发现所有的需求被证明是不现实的
  　– 需求的变化是需要管理的
• 保证需求是朝着用户的真实需要而变化的
• 保证需求最终是可实现的

需求的类型

• 在UP中，需求是按照 FURPS+ 模型分类的
• FURPS+ 模型
  – 功能性需求 （Functional）
  – 非功能性需求
• 可用性（Usability）
• 可靠性（Reliability）
• 性能 （Performance）
• ‘＋’ 部分
  – Implementation，Interface，Operations，Packaging，Legal
• FURPS+ 模型可用作需求工作的 Check List（检查表）
• 需求的记录
  – 在UP中，需求主要是在用例模型（功能性需求）中记录的
  – 非功能性需求是在补充说明文档中记录的

用例模型

• 功能性需求主要是在用例模型中记录的
• 用例可以借助于目标（Goal）和情节（Scenario）引出

目标和情节

• 用户都有一些希望系统帮助实现的目标（Goal）
• 用例是描述如何使用系统来达到目标的一组情节
• 例：

收银员使用POS是为了达到对商品销售和用户支付进行跟踪管理的目标

• 处理销售（用例）：一个顾客携带采购的商品到达收费口。收银员使用POS系统记录每件商品。系统给出商品的清单和累加值。顾客输入支付信息，系统对信息进行验证和记录。系统给行库存信息。顾客从系统得到收据。顾客携带商品离开。

有关用例的一些背景情况

• 用例的概念最早是 Ivar Jacobson 在1986年提出来的
• 使用用例来记录需求已被软件界广泛接受
  – 简单实用
  – UML 的支持
  – UP 中 ’用例驱动‘ 的概念
• 《编写有效用例》，Alistair Cockburn，影印版，机械工业出版社，2002，是一本非常优秀的参考书，简明，易懂，和实用

用例和其增添的价值

• 有关用例的几个基本概念
• 参与者（Actor）：

具有行为能力的事物，可以是人，系统或组织

• 场景（Scenario）:

参与者和系统之间的一个特定的一系列交互

• 用例（Use Case）:

描述参与者使用系统来达成目标的一组成功和失败的场景

用例（Use Case）和场景（Scenario）之间的关系
　　– 场景是用例的一个特例
　　– 用例包含了一组相关场景

一个有效用例的两个显著特点
　　– 能给用户返回可观察到的价值
　　– 帮助用户达到他的一个目标

用例和功能性需求

• 用例是用来描述系统（功能性）需求的
• 用例主要是以文字方式记录下来的
• 用例图是系统用例，使用者，之间关系的图形表示
• 用例图是用例的抽象概括描述，仅有用例图是不够的

用例的类型和格式

• 用例的目的是记录系统作什么（What），而不是怎么做（How）
• 用例记录交互的重点在业务过程而不在技术特点
• 黑箱用例把要开发的系统看成一个黑箱子，只描述系统的职责

例：
　 　’系统记录销售信息‘ （黑箱用例的描述方式）
　　  ’系统将销售信息写入数据库‘ （不是黑箱用例）
　 　’系统为销售信息生成一条 SQL INSERT 语句‘ （更不是黑箱用例）

例：
　　 ’收银员用扫描器来读入每件商品的信息‘
　　 vs ’收银员使用POS系统记录每件商品‘

• 常用的用例书写格式
  – 简洁用例（brief，摘要形式）
• 通常在编写用例的早期用来记录主要成功场景，多由一个文字段落组成
  – 临时用例（casual）
• 非正式的由多个文字段落组成，记录成功和失败的场景
  – 详述用例（fully dressed）
• 最正式，详细的格式

详细用例示例：处理销售（Process Sale）

• 用例1：处理销售（见教材第35页）
• 详细用例的格式由下述几个大的部分组成
  – 绪言元素
  – 项目相关人员和其兴趣的列表
  – 前置条件和后置条件（成功保证）
  – 主要成功场景和步骤
  – 扩展部分（其它可能的分支）
  – 特殊需求
  – 技术和数据变更列表

用例格式的解释

绪言元素部分

• 主要参与者：调用系统服务来完成目标的主要参与者
  – 项目相关人员列表

例： 收银员：希望能够准确，快速的输入，而且没有支付错误。

售货员：希望自动更新销售提成

• 前置条件和后置条件：规定了用例开始时和结束时应该为真的条件

例：
　 – 前置条件：

收银员必须已经被识别和授权
　 – 后置条件：

存储了销售信息。准确计算了税金。更新了帐目和库存，记录了提成，和生成了收据

主要成功场景和步骤（基本流程）

• 能够满足项目利益的典型成功路径（Happy Path)

例：主要成功场景

顾客携带购买的商品到达 POS 收费口
　收银员开始一次新的销售
　收银员输入商品标识
　。。。
　收银员重复 3-4步，直到结束

5 。。。

扩展流程

• 扩展部分包括了除了’Happy Path’ 之外的所有其它可能的情况
• 扩展场景是从基本场景中分支出来的
• 一个扩展是由两部分组成：条件和处理

例1：扩展部分

3a 非法的标识

• 系统指示错误并拒绝输入

3b 有多个相同类别的商品，不需要跟踪每一个具体商品

• 收银员可以输入商品类别的表示和数量

在条件部分，应使用系统或参与者能够检测到的事务为条件

例2：5a 系统检测到与外部税金计算系统的通信故障

5b 外部税金计算系统不工作

例3：对在基本路径中多个步骤可能发生的扩展

3－6a 顾客要求收银员去掉一个已经输入的商品

1 收银员输入商品标识并删除该商品

2 系统显示更新后的累加值

3b 有多个相同类别的商品，不需要跟踪每一个具体商品

1 收银员可以输入商品类别的表示和数量

例4： 对在基本路径中任意一个步骤都可能发生的扩展（用 *a, *b, *c, …）

*a 当系统崩溃时（可在任意时间发生）

为了支持系统恢复和正确地记帐，要保证所有交易敏感的状态和事件可以从场景的任意一步中恢复出来

1 收银员重启系统，登录，要求恢复到上一个状态

2 系统重构上一个状态

用例的目标和范围

• 用例可在不同的抽象程度上写，可以包含不同范围的内容
• 在怎样的抽象程度写更好？一个用例的‘粒度’应怎样确定？

例： 那一个是有效的用例？

a 谈判一个供货合同

b 处理退货

c 登录系统（Log In）

子功能目标和用例

• ‘向系统证明我的身份并获得授权使用’ 不是一个用户（级）目标，它是一个子功能目标 － 辅助用户目标的子目标
• 为子功能目标写独立用例会使用例模型中的用例数大量增加
• 用例模型中用例的数量和粒度影响着对模型的理解，维护和管理
• 一般只当子功能目标对应的用例在多个用户级用例中出现，为了减少模型中的冗余，才将其定义为一个独立的用例
• 找出主要参与者，目标和用例
• 发现用例的基本途径是
  – 选择系统边界
  – 识别主要参与者和目标
  – 定义用例

参与者（Actor）

• 参与者事具有行为能力的事务
  – 人，系统，组织
• 三类参与者
  – 主要参与者：通过使用系统实现自己目标
• 如，收银员
• 是发现用户目标和用例的一个起点
  – 次要参与者：向系统提供服务
• 如，自动支付授权服务
• 明确外部接口和协议
  – 后台参与者：不是前两钟参与者，但是用例的行为和其利益有关
• 如，政府的税务机关
• 用例图（Use Case Diagram）
  – 稻草人标识参与者
  – 矩形表示（待开发）系统
  – 用椭圆标识用例
  – 连线标识使用或交流关系