用例建模
这里的文章除了特别说明为 [转载] 之外，均为本人原创，转载请说明出处
1.用例建模
a. 阅读 Asg_RH 文档，绘制用例图。 按 Task1 要求，请使用工具 UMLet，截图格式务必是 png 并控制尺寸
b. 选择你熟悉的定旅馆在线服务系统（或移动 APP），如绘制用例图。并满足以下要求：
- 对比 Asg_RH 用例图，请用色彩标注出创新用例或子用例
- 尽可能识别外部系统，并用色彩标注新的外部系统和服务
c. 对比两个时代、不同地区产品的用例图，总结在项目早期，发现创新的思路与方法
原则为一切以用户为中心，明确用户群体，从用户需求的出发考虑问题，把困难留给自己，把简单留给用户。项目早期首先要根据“二八定律”抓住功能重点，然后达成快速上线的目标，再根据用户反馈来顺应需求的动态变化。本人总结的具体思路和方法大致如下：
- 考虑新技术，能否应用新型技术来提高用户使用产品的效率，从而为用户带来更好的操作体验？如新增基于地理信息服务的地图搜索功能。
- 考虑业务逻辑，现有的流程和方法是否能够进一步改善？例如：之前提供了搜寻结果排序的功能，但是如果增加筛选的功能，可以使用户更快地获得自己想要的信息。
- 考虑拓展模块，用户是否有进一步的需求？是否应该为用户提供更多的信息，帮助用户更好的达成自己的目标？如添加评论区，不但让用户更多地获取了他们想了解的信息，也增强了用户的参与度。
d. 请使用 SCRUM 方法，在（任务b）用例图基础上，编制某定旅馆开发的需求 （backlog）
- 去哪儿预定酒店模块的BACKLOG
| ID | Name | Imp | Est | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | 搜索酒店 | 90 | 12 | 输入目的地，选择入住日期，离店日期，点击搜索按钮开始搜索酒店，可添加酒店名，地标等进行组合搜索。可直接选择地图搜索 | 地图搜索基于地理信息服务的接口，目前不需要考虑用户登录的问题 |
| 2 | 预定酒店 | 100 | 14 | 选择旅馆，可对搜索结果中的旅馆进行排序和筛选。选择住房类型，可查看评论和提出问题。填写订单，确认预定信息，填写入住信息 | 需要UML顺序图。使用分页技术避免大规模的数据库查询 |
| 3 | 管理个人信息 | 70 | 8 | 可收藏酒店，点评社区，查看订单，查看我的问答 | 需要用户登陆，建立个人账户，依赖短信服务 |
| 4 | 支付订单 | 50 | 6 | 填写订单后进入支付订单状态，可选择微信，支付宝，或者添加银行卡进行支付 | 依赖微信，支付宝等第三方支付服务 |
2、业务建模
a. 在（任务b）基础上，用活动图建模找酒店用例。简述利用流程图发现子用例的方法
利用流程图发现子用例的方法： 因为子用例与父用例的关系一般用include和extend来描述，所以我们可以通过寻找父用例之间的共同包含动作来发现子用例，也可以通过寻找父用例的扩展点来发现子用例。利用流程图对业务活动的流程进行建模，可以帮助我们清晰快速地发现基用例的共同点和扩展点，从而发现子用例。
b. 选择你身边的银行 ATM，用活动图描绘取款业务流程
c. 查找淘宝退货业务官方文档，使用多泳道图，表达客户、淘宝网、淘宝商家服务系统、商家等用户和系统协同完成退货业务的过程。分析客户要完成退货业务，在淘宝网上需要实现哪些系统用例
客户要完成退货业务，在淘宝网上需要实现的系统用例：
- 处理退货申请
- 审核凭证
- 处理退款
3、用例文本编写
在大作业基础上，分析三种用例文本的优点和缺点
-
摘要 优点：编写所需时间很短，在项目的早期需求分析过程中，可快速帮助了解主题和范围。 缺点：只包含主成功场景，无法说明用例的详细业务过程，不利于深入分析需求。
-
非正式 优点：在摘要的基础上添加了交替场景，编写所需时间短，在早期需求分析过程中，可快速帮助了解主题和范围。 缺点：不够详细全面，缺少足够的用例细节。
-
详述 优点：结构化，展示了更多细节，更为深入，用于详细编写具有重要架构意义和高价值的用例，有利于进行详细的需求分析。 缺点：编写所需时间很长，需要考虑各种繁琐的细节。