OOAD引论和用例模型(二)

迭代开发和统一过程

 

             简       介

 

•         现代软件的两个突出特点是复杂和多变

•         软件规模变得越来越大

•         从软件的构思开始至软件停止使用充满了变化

•         迭代开发是能很好地适应这两个特点的一种巧妙的方法

•         主动迎接变更，不断反馈和调整

•         统一过程（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)

例：主要成功场景

1. 顾客携带购买的商品到达 POS 收费口
2. 收银员开始一次新的销售
3. 收银员输入商品标识
4. 。。。

收银员重复 3-4步，直到结束

5     。。。

扩展流程

•         扩展部分包括了除了’Happy Path’ 之外的所有其它可能的情况

•         扩展场景是从基本场景中分支出来的

•         一个扩展是由两部分组成：条件和处理

 

例1：扩展部分

       3a 非法的标识

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

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

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

 

 

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

例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）

–     稻草人标识参与者

–     矩形表示（待开发）系统

–     用椭圆标识用例

–     连线标识使用或交流关系