建立用例模型(实例)
建模步骤
用例模型创建步骤
- 确定参与者
- 确定用例
- 确定用例之间的关系
- 绘制用例图
- 描述用例规约
用例模型的建模过程:
-
找出系统外部的参与者,确定系统边界;
-
确定每一个参与者所期望的系统行为,将其提炼为用例;
-
分解用例中的公共或扩展行为,提取新的用例;
-
考虑参与者之间是否存在泛化关系;
-
使用关联关系,表示出参与者直接启动的用例;
-
使用泛化、包含、扩展等关系,处理系统行为的公共或扩展部分;
-
选择工具,绘制用例图;
-
为每一个用例编制用例规约;
-
细化用例图,检查用例间是否存在重复与冲突的问题、关系是否完善等。
绘制用例图
根据描述,为“图书借阅自助系统”建立用例图。
• 系统为借阅者提供服务,系统的借阅者为学生和教师,系统提供服务如下表所示;
• 其他需求:出于系统安全考虑,要求在“借阅图书” 、“归还图书” 时,要先”验证借阅者的身份”。
查询图书: | 根据基本信息对图书信息进行查询 |
---|---|
借阅图书: | 对选定的图书进行借阅 其中:• 学生最多可借阅5本;• 教师最多可借阅20本。 |
归还图书: | 归还本人借阅的图书。如果超期,要缴纳罚款。 |
预约图书: | 若教师想借阅的书已被借空,教师可预约该书。预约后可优先借阅该书。 |
确定参与者
由
• 系统为借阅者提供服务,系统的借阅者为学生和教师,
可知参与者是:借阅者,且借阅者分为 学生和教师
确定用例
• 学生最多可借阅5本;• 教师最多可借阅20本。
属于业务规则,不应是用例
预约图书: | 若教师想借阅的书已被借空,教师可预约该书。预约后可优先借阅该书。
可以得出,教师可以预约图书,两者是关联关系。
预约后可优先借阅该书。
属于业务规则,不是用例
确定用例之间的关系
• 其他需求:出于系统安全考虑,要求在“借阅图书” 、“归还图书” 时,要先”验证借阅者的身份”。
易得 借阅图书” 和“归还图书” 对于 ”验证借阅者的身份” 是包含关系。
绘制用例图
例2
描述
在棋牌馆管理系统中,客户通过Internet进行“预订座位”操作,其中需要“检查座位信息”。如果没有空闲或满意的座位,则选择“处理等候队列”。
当客户到棋牌馆后,总台服务员“安排座位”,其中需要“检查座位信息”。
客户要离开棋牌馆时,总台服务员需“处理结账”,支持“处理现金结账”和通过银联POS系统“处理银行卡结账”两种方式。
要求根据描述画出描述该业务的用例图。
注意两点
- 客户不能和结账相连
- 客户不需要进入座位(题目没有给出)
描述用例规约
基础知识
名称
描述用例的意图或实现的目标,一般为动词或动宾短语
参与者
描述用例的参与者,包括主要参与者和其他参与者
前置条件
用例能够正常启动和工作的系统状态条件
后置条件
用例执行完毕后系统的状态条件
基本事件流
对用例中常规、预期路径的描述
扩展事件流
主要是对一些异常情况,选择分支的描述
特殊需求
描述用例实现时需考虑的业务规则,实现约束及非功能性需求等信息
例规约的基本事件流和备选事件流中对系统实现及界面设计细节描述的越详细、细致,越有助于后续软件开发活动的顺利开展。
错
例子
对美团外卖的“外卖下单”用例进行自主分析,按照链接中的模板,编写用例规约。
分析: 用户下单只包含下单,不包含支付,因此外卖下单部分不要写出支付过程。
简要说明
用例编号 UC01
用例名称 外卖下单
用例简述 用户通过该用例订餐生成外卖订单
参与者 用户
场景描述
前置条件
用户登录系统,并进入主界面
触发条件
用户选择要点餐的商家时,用例开始;
后置条件
下单成功,系统保存订单信息;
下单失败,不保存订单信息。
基本事件流
1.用户选择要点餐的商家,用例启动;
描述时要明确参与者,不能写“参与者”,要写出正确的参与者名字。
2.系统显示所选餐馆的信息界面,并显示餐品菜单(菜单分类、餐品名称、图片、价格、月售量、好评度等);
3.用户对菜品点击“添加”;
4.系统将该菜品添加入购物车;
要对用户的每次点击都写出。
重复操作步骤3、4,直到完成点餐;
5.用户选择结算;
6.系统显示结算界面,显示订单列表(餐品名称、单价、数量、打包费、配送费、总金额、优惠金额、配送参考时间等),并提示选择收货地址;
因为有用例支付订单,所以不需要写出支付细节
7.用户选择收货地址,点击“提交订单”;
8.系统确认订单信息无误,创建订单,并显示订单应支付金额,用例结束。
扩展事件流
3a.用户点击菜品图片,系统显示菜品详细信息(详情、描述、搭配推荐);点击返回,返回2。
4a.如果所选菜品余量不足,系统给出提示,返回2。
5a.如果用户点击购物车,系统显示购物车列表;用户可以删除已选菜品,或者增减某菜品的数量;点击返回,返回2。
7a.如果用户所选的收货地址超出商家配送范围,系统给出提示,返回6。
8a.系统检验订单信息有误,提示用户检查订单列表,返回6,并突出显示有误信息。
其他事项
特殊需求
特殊需求类似于制定的规则。
1.菜品添加购物车时,默认数量为1;
2.订单总金额 = Σ菜品单价×数量 - 优惠金额;
3.收货地址详细到门牌号,必须添加收货人手机;
4.订单放弃后,购物车信息自动保留20分钟,20分钟后清空;
5.订单超过30分钟未支付,自动取消订单。
扩展点
本用例执行基本事件流6时,可选择执行扩展用例“UC05新增收货地址”用例;
本用例执行基本事件流8后,可选择执行扩展用例“UC06 支付订单”用例。
例2:: 商品结算
用例名称:商品结算
用例编号:UC06
参 与 者:顾客、银行系统、管理员
用例简述:描述顾客选择商品后 对商品进行付款的过程
前置条件:顾客必须是系统的注册用户,并执行用户登录用例
事件流——基本流
顾客选择要购买的商品
系统计算优惠金额,并显示生成的用户付款订单
顾客确认用户付款订单
系统保存用户付款订单
系统显示付款方式
顾客选择付款方式,进行付款
系统启用银行系统,确认顾客的付款
系统显示顾客此次购买成功信息
顾客确认成功信息,结束此次购买
事件流——备选流
3a. 如果顾客取消付款订单,系统给出提示,结束
7a. 如果顾客没有付款,给出提示,保留该订单,返回步骤5
特殊需求:需要系统能与现有的银行系统连接,获取顾客付款信息
扩展点:商品优惠用例
总结
1. 构建结构良好的用例
-
为系统和部分系统中单个的、可标识的、合理的原子行为命名
-
将公共的行为抽取出来,放到一个被包含用例中,建立与基础用例间的包含关系
-
对于变化部分,将其抽取出来,放到一个扩展用例中,建立与基础用例间的扩展关系
-
清晰的描述事件流,使得读者能够轻而易举的理解
2. 构建结构良好的用例图
-
应给出一个表达其目的的名称
-
摆放元素时,应避免出现交叉线
-
对于语义上接近的行为和角色,位置上同样接近
-
充分使用注解和颜色等方式,突出图的重要特性
-
尽可能减少图中关系的种类
3. 根据系统实际情况控制用例粒度
- 用例应体现参与者完整的目标
- 同一需求阶段中用例粒度大小应该一致