5 用例建模

提交成绩 教师
10
什么是用例
Use Case Name
一个用例
定义系统的一系列行为，通过此可为参与者提
供有价值且可观测的结果。
• 定义一个参与者要用到的系统功能 • 描述系统为实现参与者价值所开展的行为序列
• 对参与者与系统之间的交互活动进行建模
• 从特定的用户角度出发是完整的，实现特定用户价值的事件 流
1: 填写个人信息 2: 提交
选课管理员
线性代数
线性代数 A段
3: 将马小跳加入线代选课名单 4: 添加马小跳 5: 还有位置吗? 6: 如果有，添加马小跳
顺序图建模元素--对象（Object）及其生命线（Lifeline）

对象以某种角色参与交互
可以是人、物、其他系统或者子系统

生命线：表示对象存在的时间
[All items checked & &some itemsnot in stock] Waiting Item Received [some items not in stock]
Dispatching do: initiate delivery Delivered
Item Received [all items available]
状态建模--什么是状态?
• 所有的对象都有“状态”
• 对象存在或者不存在
• 对象不存在也是一种状态
• 如果对象存在，则具有相应表示其属性的 值 • 每一种状态表示一种可能的状态赋值 • 对于大部分对象而言，状态空间是非常庞大的 • 状态空间大小是对象每个属性取值空间的乘积加1 • 例如. 具有5个布尔值属性的对象有 2 5 +1 个状态 • 例如. 具有5个整数值属性的对象有(max int)5+1个状态 • 例如. 具有5个实数值属性的对象具有？？个状态 • 如果忽略计算机表示的局限性，状态空间是无限的


Self-message 自关联消息
Time-out 超时等待 Uncommitted／Balking 阻塞
绘制顺序图
1. 在顺序图顶端绘制矩形框，定义参与交互的类实例（对象）名； 2. 在每个对象下面绘制竖直虚线，表示该对象的生命线；
3. 在对象间添加箭头表示各种类型的消息，跟踪对象间的控制流；
11
交互--关联（Association）
Actor 1
• 参与者与用例之间的交互通道 • 用一条直线表示交互——关联
Use Case
• 有箭头的关联指出是谁发起的交互 • 没有箭头则表明双方都可以发起交互
Actor 2
Actor 3
12
用例建型的步骤
(1) 找出系统外部的参与者和外部系统，确定系统的边
• 没有实际价值的用例 • 通过底层操作进行命名
• “操作”+“对象” • “功能” + “数据”
• 从一个用户的角度出发
• 例如：“插入卡片”
” ”
• “这个用例背后的用户故事是什么？
25
‹#›
‹#›
详细的用例规约
28
顺序图举例
• 顺序图用来刻画系统实现某个功能的必要步骤
小明: 学生
选课登记表
简要描述：使用ATM系统提取现金、转移资金和存款的所有 用户，这些用户持有相应的银行卡且知道银行卡对应账号的密 码。
15
参与者建模的检查项
• 是否找全所有的参与者？是否对系统环境中所有的角
色进行了描述和建模？
• 每个参与者是否至少与一个用例发生了交互？ • 是否可以为每一个角色找到至少两个实例？ • 不同参与者与系统的交互是否一致，扮演的角色是否 相似？如果有，则应该要合并这些参与者作为同一种 角色
8
参与者的定义：关注角色
• 与系统交互的人 • 与系统交互的硬件组件
• 或者其他的外部系统
关注的重点是所承担的“角色” 参与者的名字要明确定义其角色
9
参与者定义与角色划分
韩蕾: 数学系的教师 软件学院的博士生
张跃和李玫都
具有学生角色
李明: 软件学院本科生
注册课程
学生
张跃同时也具
有教授的角色
状态图建模
• 状态图用来表示一个类的全生命周期过程
• 建模元素 • 状态 • 事件 • 状态转移 • 状态图的绘制
new() Push()
empty
Pop()
1item
…
状态（State）
定义： 一个对象生命期的一个阶段，该阶段中对象要满足 一些特定的条件、执行特定的活动或等待某个（些）事 件的发生 • 体现为对象属性的取值
23
走出功能分解：正确的用例建模
转账 (Transfer Funds)
24
如何避免功能性分解
问题现象 • 非常细小的用例 修改思路 ： • 寻找更大的应用场景
“为什么要构建这个系统？ ”
• “用户希望达到什么目的？” • “这个用例可以满足谁的目标？” • “这个用例的意义是什么？有什么价值？
• 用例过多
控制焦点/激活期(Focus of Control/Activation)：表示对象 进行操作的时间片段

顺序图建模元素--消息（Message）
消息（Message）用于描述对象间的交互操作和值传递过程

消息类型:

Synchronous 同步消息（调用消息）
Asynchronous 异步消息 Return 返回消息
• 包含状态入口或出口、行为描述
• 从不同的抽象层次分析对象，因此其状态是可嵌 套（组合）的 • 在给定的场景下，对象状态是确定的，可满足或 不满足某个状态
状态迁移
迁移包括五部分：
• 源状态(source state)、触发事件 (event trigger), 警戒条件(guard condition), 动作(action), 目标状态(target state).
Delivered
系统必须知道哪些外部事件？参与者如何通知系统这 些事件？
系统需要进行哪些维护工作？
18
用例的描述
• 用例简述: 一段简洁的摘要，主要 描述用例的成功场景
• 下订单:
客户带着要购买的货物到收款处，收银员使用POS机
扫描记录每一种预购买的货物。系统计算总价并打印清
单。客户付款，系统验证并保存销售记录。系统更新库
用例建模
1
用例建模 用例建模概念 用例建模过程 用例建模精讲
建模工具介绍
2
用例模型的表示--用例图
自动提款机(ATM)
取款
转账
银行客户
银联
存款
收取存款
柜员
日常维护
系统维护人员
3
系统
系统是指待开发的任何事物，包括软件、硬件或者过程。 系统边界:
一个系统所包含的所有系统成分与系统以外各种事物的分界线 • 系统边界会对用例以及Actor的定义有所影响 考虑用于零售店销售管理的系统的用例图 ：
13
寻找参与者
• • • • 谁使用系统的功能？ 谁需要系统支持他们的日常工作？ 谁来维护、管理系统使其正常工作？ 哪些其他系统使用该系统？
•
• • •
系统需要与其他哪些系统交互？
系统需要控制哪些硬件？ 对系统产生结果感兴趣的是哪些人或物？ 是否有事情在预计的时间自动发生？
14
参与者的描述
参与者规格说明 参与者名称：顾客 是否抽象参与者：否
• 系统的任何一个特性都可以找到对应的用例
• 用例模型并不包含多余的行为；所有的用例可以追溯 到系统的功能性需求作为验证。 • 去掉所有的CRUD 类的用例
创建(Create),查找(Retrieve),更新(Update),删除(Delete)
22
功能分解
选择转入账号 选择“取款” 选择“查询余额”
• 信号事件(Signal events) 当给定对象收到某实时信号
例：订单处理
Start
Order
getnext item [Not all items checked]
/getfirst item [All items checked && all items available]
Checking do: check item
状态的抽象表示
• 但往往状态空间中的局部更有探究的价值 • 有一些状态是不可能出现的状态 • 整数或实数值属性往往只在一定范围内取值 • 通常，我们只关注特定约束下的对象及其
行为
例如，对于年龄, 我们经常选择以下的范 围：
age< 18；18≤age≤65；age> 65
例如，对于费用信息,我们更关注的约束划分为： cost ≤ budget，cost=0，cost >budget，cost >(budget+10% )
4. 生命线加竖直矩形定义对象激活期，表明对象正在执行某操作； 5. 根据需要添加框的组合与关联，表示复杂的控制结构。
‹#›
顺序图的作用
• 帮助分析人员对照检查用例中描述的需求是否已经 落实给具体对象去实现 • 提醒分析人员去补充遗漏的对象类或操作 • 帮助分析人员识别哪些对象是主动对象 • 通过对一个特定的对象群体的动态行为建模，深入 地理解对象之间的交互
零售店销售管理系统
4
系统边界定义之一
5
系统边界定义之二
6
系统边界定义之三
7
用例图的主要元素
参与者（Actor） 与系统交互的人或外部系统 用例（Use case） 系统为参与者提供的有价值的服务功能 关联（Association） 用例图中用例与参与者之间的交互关系
Actor
Actor
Use Case
源状态
事件名[‘(’用逗号分隔的参数表‘)’][警戒条件 ]‘/’动作表达式
目标状态
• 对于给定的状态，最终只能产生一个迁移，因此从相同的 状态出来的、事件相同的几个迁移之间的条件应该是互斥 的。
事件（Events）
• 事件(Events)的意义在于系统需要了解正在发生什么
• 状态图中，事件仅需和系统或当前建模的对象相关 • 从系统角度出发，事件必须建模成一个瞬间可完成的动作
界和范围； (2) 确定每一个参与者所期望的系统行为； (3) 把这些系统行为命名为Use Case； (4) 使用泛化、包含、扩展等关系处理系统行为的公共或
变更部分；
(5) 编制每一个Use Case的脚本； (6) 绘制Use Case图； (7) 区分主事件流和异常情况的事件流，可以把表示异常情况的事 件流作为单独的Use Case处理；
• 例如. 完成工作，考试未通过，系统崩溃
• 在 OOD( 面向对象设计 )中通过传递消息的方式实现事件
• 在 UML 中，有四种类型的事件
• 变更事件(Change events) 当给定条件成立时就会发生变更事件
• 调用事件(Call events) 当给定对象的操作被调用执行时会发生调用事件 • 时间事件(Elapsed-time events) 表明时间段过去，或某个特殊时间点的触发
存，客户得到收条并带着货物离开。
19
用例的描述
20
用例的描述
客户代表
1. 收到一个取消订单的请求 2. 输入订单的标识号
系统
记帐系统
3. 显示订单内容 4. 选择取消
5. 给该订单打上取消标记
6. 向客户账号增加订单 支付的资金
21
用例建模过程中的检查项
• 用例建模是为了表示系统的行为。通过模型可以很容 易理解系统进行的操作 • 应该识别出所有的用例，用来表达所有的需求。
16
寻找用例
基本策略：把自己当作参与者，与设想中的系统进行交互。
我想通过这个系统达到什么目的？
目标 1
Hale Waihona Puke Baidu
参与者
目标 2
注意：寻找用例和寻找参与者的过程是不能截然分开的
17
识别用例
参与者希望系统提供哪些功能？ 系统存储信息吗？参与者将要创建、读取、更新或删 除什么信息？ 系统是否需要把自身内部状态的变化通知给参与者？