用例分析

27
事件流的详细程度 事件流之间的流转
15
示例：用例规约（include）
登录 现金支付 <<include>> <<include>> <<include>> 购买商品 支票支付 信用卡支付 CardProcessin gCompany
Cashier
CheckProcessi ngCompany
Inventory
Entity Classes 概念模型

21
模型的组织：由用例来组织

用例分析过程围绕着用例完 成，通过用例实现(use-case realization)来组织
该用例实现与用例模型中用例
之间的关系

Traceable Diagram
该用例的实现过程交互图 基本事件流 备选事件流 该用例的参与类类图 VOPC Classes Diagram
25
以系统作为实体类后的交互图
: 客户 : 客户预定房间接口 : 预定房间工作流 : 系统 : 定单 1. 客户登陆预定界面 2. 预定房间 3. 向系统提交预定 4. 系统生成定单
5. 显示定单给客户
这样的图有意义吗？达到分析的目标了吗？
26
: 服务员 : ReservationUI
: ReservationW...
Administrator
启动
退还商品
SystemAdmin
管理用户
16Biblioteka 示例：用例规约（extend）
17
系统用例图
<<include>> 预定房间 <<include>> 客户 取消预定 退还定金 计算总费用
查询房间信息 登录
时间
预定情况打印
18
用例规约：预定房间
…… 涉及的用例：计算总费用 前置条件：用户成功登录 正常事件流： 1.用户选择预定房间后启动该用例 2.系统显示用户可以预定的房间列表 3.用户选择某一个房间 4.系统启动“计算总费用”用例，来计算该房间的费用 5.用户确认本次预定业务 6.用户选择支付方式，以便预付定金 ……
22
实体类（entity class）

实体对象（类）体现系统的核心业务数据
识别出用例规约中的名词和名词短语，将它们
作为实体或属性的候选对象
来自用例规约 名词性短语

概念模型 实体类的完备性 实体类是后续数据库设计的基础
23
本系统实体类类图（概念模型）
24
实体类的典型问题

<<include>>
11
扩展关系的使用

使用扩展的一个潜在问题是创建过深的扩展依赖 层次
Jacobson博士建议永远不要扩展一个扩展

对于在描述用例的时候，什么时候用扩展，什么 时候用可选路径，Jacobson建议：
只有当扩展用例与被扩展用例完全分离（即它本身是
一个独立的具体用例或者是其他用例需要的一个小片 段）时，才使用扩展关系 基用例自身必须是完整的，它的正确执行不需要扩展。 否则，就应该用可选路径来描述附加行为
1
1. “时间”参与者的使用
时间：参与者，一 种习惯用法，用于激 活那些系统定期的、 自动执行的用例 “计算总费用”的 时候，时间仅仅是一 个条件，而不是参与 者，因为此时它是作 为系统的一部分
2
2. 参与者的泛化
参与者泛化：特化 的参与者会继承泛化 参与者所有的要素！ 外围系统表示是已 有的或计划中的外围 的独立的软件系统！ 使用英文时注意单 词的正确用法！
12
包含关系的使用

包含关系使用不当容易诱使人们进行攻能 分解，从而导致对用例的误用
Jacobson说，“事实上，今天一些人误用了
用例，把它们用来描述功能（注：指功能分解 式的分析）而不是对象，反过来又指责用例概 念存在问题”
13
泛化的危害
一个售货员可以终止任何交易，除了那些需要特殊的售 货员（高级代理）终止的超过了一定限制的交易
3
3. 用例关系-1：明显的错误
依赖关系：include, extend都是依赖关系 (dependency)的构造 型(stereotype)，带箭 头的虚线表示 “extend”关系的方 向，子用例对主用例的 扩展
4
3. 用例关系-2：什么关系？
5
3. 用例关系-3
6
4. 用例干什么？
: RoomCatalog
: Room
: Reservation : Payment
: Customer
1. //查询可预定房间信息
“预定房间”参考顺序图
1.1. //查询可预定房间信息 1.1.1. findRoom( ) 1.1.1.1. //可用房间列表 1.1.2. //[0..n]获取详细信息 1.1.3. //可用房间信息 1.2. //显示可用房间列表
“系统”实体类
系统是一个什么样的实体类？事实上，它应该是一个
全局的控制类，负责所有的核心流程，成了上帝类！ 它掩盖了实际的业务流程， 使得分析过程失去意义！

“数据库系统”实体类
在您做这个系统之前已经有现成的数据库吗？如果有
的话，那么它应该作为外围系统，对于本系统而言就 应该是一个接口．如果没有，您就应该做数据库设计， 而这是在分析之后工作的，分析是还没有数据，又谈 何数据库接口呢？
用例分析实例：旅店管理系统
某公司要开发一个旅店管理系统，该旅店可对外开放10 个双人间和10个单人间，房间费用视情况按季节调整， 但周一到周五半价（周末全价）折扣不变。对于外界请求， 该系统应能根据请求入住时间预定指定档次的房间，记录 旅客姓名、地址、联系电话、有效证件号、房间类型和预 定天数，并计算出总费用。预定的同时旅客按规定须提交 10%定金。六个小时之内旅店允许旅客取消预定，并退 回所有定金，超过六个小时定金不退还。每周一系统自动 打印一周预定情况清单。采用哪种费用支付方式和何种类 型操作界面尚不确定。
2. //选定预定房间 2.1. //预定房间 2.1.1. //计算总费用和定金 2.1.2. //总费用和定金
3. //确认预定房间 3.1. //确认预定的房间
3.1.1. //记录客户信息 3.1.2. //记录支付信息 3.1.3. //修改房间信息 3.1.4. //记录预定信息
3.1.5. //预定成功 3.2. //显示预定成功 3.3. //打印收据 3.3.1. 打印收据
“其他”、“打印清 单”用例和外围没有任 何有意义交互，和其他 用例也没有任何关系， 这样的用例有意义吗？ “其他”用例又代表什 么呢？想说明什么样的 功能需求？
7
6. 用例粒度
注意“管理用例”的使用！
8
看看这个用例图
参与者与用例的定义！
9
再看一个
10
用例关系
<<extend>>
Extend Include Generalization
终止一个基本交易
普通售货员
终止一个交易
普通售货员
终止一个小交易
终止一个大交易
高级代理
终止一个大交易
高级代理
14
用例规约

用例规约用来描述用例的，不是用例图 用例规约该写什么？ 用例规约需要与用例图相对应
用例的名称 用例描述：一句完整的话 用例间的关系 用例与参与者的关系

19
模型的组织：4+1视图
用例分析是面向对象的分析阶段，其产生的工件应该 都组织在逻辑视图（Logical View）中
20
模型的组织： 按候选体系构架组织

按MVC构架寻找相应的对象 （类）
边界类

Boundary Classes
控制类

Control Classes
实体（模型）类