Lesson 6 Use Case Modelling
2018, Apr 12
用例建模-实践3
1. 用例建模
Task 1.A
阅读Asg_RH文档， 按照Task1要求绘制用例图
Task 1.B
选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：
- 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
- 尽可能识别外部系统，并用色彩标注新的外部系统和服务
这里以携程网(ctrip.com)的酒店预订过程为例。
Task 1.C
对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法。
相比起Asg_RH， 携程网的主页直接提供了（基于各方面）的酒店推荐方便用户选择， 并且增加了对酒店评价系统， 当然也引导用户建立账户， 基于不同的私人账户，可以提供针对性的服务（往往使用户感到更加便利、保险）
发现创新的方法：
- 流程简化： 可以直接给用户推荐其可能感兴趣的酒店， 简化（甚至省去）了搜索过程， 同时可以给自身带来广告收入。
- 流程扩展： 在不对基本流程造成较大影响的情况下， 增加一些可选项， 提供更加针对性的服务
- 个性化服务： 开放用户注册， 团体可以针对不同的个人用户给出不同的出行方案， 提高服务质量&效率
- 寻求合作： 通过其他社交账号登陆 简化注册流程 提高注册用户量
后面2条看起来更像是对前面2条的进一步举例。
Task D
请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）
| ID | Name | Importance | Estimate | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | Choose Hotel | 17 | 16 | 主页搜索框可以通过各种条件搜索，结果中显示对应酒店；另外在主页显示推荐酒店 | 搜索条件除了基本条件，还包括通过地图点选位置 |
| 2 | Choose Room | 10 | 12 | 在酒店详情页中点选某房间，可以查看具体信息，同时也可以直接点击预订 | |
| 3 | Book a Room | 13 | 15 | 若未登录，则提示登陆或选择无账户预订，之后转到对应的预订信息填写页 | 提示登陆是一个完整的登陆过程，也包括注册 |
| 4 | Pay | 15 | 15 | 确认订单之后转到支付页面，先提示选择支付方式，再跳转到支付页面，支付完成后提示完成预订 |
2. 业务建模
Task 2.A
在（任务1.b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法。
利用流程图发现子用例： 该流程图中，每一个圆角矩形都代表过程的一个重要阶段。 将其与前后与其相关的图例相结合， 往往可以“提取”出子用例。 同时画流程图相当于大致模拟了整个过程的步骤和细节， 每一个重要的环节往往都可以提取为子用例。
Task 2.B
选择你身边的银行 ATM，用活动图描绘取款业务流程。 这里选择了校园里常见的中国银行ATM。 这里忽略了其他轻度相关的功能（如查询）。
Task 2.C
查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例。
图见下。 这里忽略了一些不能退款的情况， 只详细画了退款成功的过程。
分析在淘宝网上需要实现的系统用例： 清晰起见，还是按照4个主体来分析。
- 客户： 填写退货申请信息、 填写退货物流信息、 收到退款
- 淘宝网： 接收买家退货申请、 将退货申请转发给商家服务系统、 通知买家退货、 登记物流信息并通知商家服务系统、 标记买家订单为可退款、 货款退回买家、 协商买卖双方退货
- 淘宝商家服务系统： 接收淘宝网通知-提醒商家处理退货申请、 转达卖家不同意退货、 转达卖家同意退货、 通知卖家准备收货、 标记售后申请为可退款
- 商家： 收到并查看退货消息、 进行售后登记、 同意/不同意退货、 验货并确认、 卖家同意退款
3. 用例文本编写
- 摘要(brief)： 早期需求分析过程中、为快速了解主题和范围可以采用的方式。
- 优点： 完成速度快，可能只需要几分钟， 方便快速确定项目大致方向。 如， 讨论确定“树洞”的几大功能板块、初步规模大小、面向的用户群等。
- 缺点： 过于粗糙， 通常只适用于早期阶段， 到后面往往都需要更加详细的用例文本。
- 非正式(casual)： 非正式的段落格式。 用几个段落覆盖不同场景。 同样在早期需求分析时使用。当然，在“摘要”之后。
- 优点： 可以在相对较短的时间内完成较为细致的需求分析， 方便确定一些使用规范。 如我们的项目是“树洞”， 其中一个讨论结果确定我们不会允许用户可以修改自己已有的发言，但允许删除自己发表的帖子（主题）。
- 缺点： 此阶段产生的文档还难以直接落到具体开发。 此时直接开始进行开发，会发现有很多具体到细节的规定还未确定（如：一页显示多少条post/后台错误代码应有几种）。
- 详述(fully)： 详细编写所有步骤及各种变化，同时具有补充部分， 如前置条件&成功保证。 在确定并以摘要形式编写了大量用理智和，在第一次需求讨论会中， 可以详细地编写其中少量（如10%）的具有重要架构意义和高价值的用例。
- 优点： 足够详细。 可以作为开发时参照的文档。
- 缺点： 编写相对耗时， 查漏补缺过程繁琐。