系统分析与设计第六周作业
简答题
用例的概念
用例是指一组用户使用一个系统实现一个目标的成功或失败的场景。是一种通过用户的使用场景来获取需求的技术。
用例和场景的关系？什么是主场景或 happy path？
用例和场景的关系：
每一个用例包括了许多个场景，场景中包含了用户是如何与系统进行交互，即谁可以利用系统做什么事情。
主场景：
每一个用例中都包含一个主场景，主场景对应于系统主要的交互，通常是指成功的场景。
happy path:
在测试用例时没有出现预期之外结果的场景。在用例建模中，happy path 是主执行者完成了目标，所有有关人员的需求都得到了满足。
用例有哪些形式？
Brief (high level)：一段总结，通常是主要的成功场景的建立，只需要几分钟的时间
Casual（简便格式）：不是很正式的形式，并且包括了不同的场景
Fully：完整的场景建立，完整的步骤以及用例的细节，以及一些可能发生的情况的应对以及如何确保一个成功的场景
对于复杂业务，为什么编制完整用例非常难？
对于复杂的业务来说，参与者（actor）的相对较多，系统交互也会非常复杂，需要考虑的备选流（alternate scenarios）也非常复杂，这将会是一个非常庞大，场景（scenario）众多的用例，因此对于这样的业务，我们要编制一个完整的用例是非常困难的，因为我们很难做到完整的覆盖所有可能的场景
什么是用例图？
用例图主要用来描述 用户、需求、系统功能单元之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。
用途：帮助开发团队以一种可视化的方式理解系统的功能需求。
用例图的基本符号与元素？
- 参与者(Actor)
表示与您的应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。
- 用例(Use Case)
用例就是外部可见的系统功能，对系统提供的服务进行描述。 用椭圆表示
- 子系统(Subsystem)
用来展示系统的一部分功能，这部分功能联系紧密。
关系
用例图中涉及的关系有：关联、泛化、包含、扩展；
如下表所示：
关联(Association)
表示参与者与用例之间的通信，任何一方都可发送或接受消息。
【箭头指向】：指向消息接收方
泛化(Inheritance)
就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
【箭头指向】：指向父用例
包含(Include)
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤；
【箭头指向】：指向分解出来的功能用例
扩展(Extend)
扩展关系是指 用例功能的延伸，相当于为基础用例提供一个附加功能。
【箭头指向】：指向基础用例
依赖(Dependency)
以上4中关系，是UML定义的标准关系。 但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示表示源用例依赖于目标用例；
【箭头指向】：指向被依赖项
项目(Artifact)
用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
用依赖关系把某个用例依赖到项目上
然后把项目-》属性 的Hyperlink 设置到你的文档上，这样当你在用例图上 双击项目时，就会打开相关联的文档。
注释(Comment)
包含(include)、扩展(extend)、泛化(Inheritance) 的区别：
条件性：泛化中的子用例和 include 中的被包含的用例会无条件发生，而 extend 中的延伸用例的发生是有条件的；
直接性：泛化中的子用例和 extend 中的延伸用例为参与者提供直接服务，而 include 中被包含的用例为参与者提供间接服务。
对 extend 而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
对 Inheritance 而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系；
用例图的画法与步骤
系统框放在中间，系统名写在上方正中间。
确定参与者，包括:
- 主要参与者：谁将使用系统的主要功能、谁将需要系统的支持以完成工作等
- 协作参与者：谁将提供对应的系统功能、谁将维护系统，保证系统处于工作状态等
- 幕后参与者：谁会对系统产生的结果感兴趣
确定参与者之间的关系（是否为泛化关系）
根据需求识别和创作用例。
确认用例间的关系，包括包含和扩展。
确认用例与参与者之间的关系，包括包含。
在用例的事件流中逐渐发现其他的支持系统，放置在系统框的右边。
用例图给利益相关人与开发者的价值有哪些？
对于利益相关人来说：
- 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
- 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
对于开发者来说：
- 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
- 用例图使得开发者能够更明确地获得需求，更好地理解需求。
- 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。
建模练习题（用例模型）
选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
- 请使用用户的视角，描述用户目标或系统提供的服务
- 粒度达到子用例级别，并用 include 和 exclude 关联它们
- 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
- 尽可能识别外部系统和服务
为什么相似系统的用例图是相似的？
相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。
如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
不同时代对预定的酒店的需求不同。可以让筛选算法与时俱进，满足一些不同的主流要求。且用户会需要更加优秀、好用、有参考价值的评价系统，也需要随时更新。而不同地区的消费特点不同，旅游胜地和普通城市用户对于酒店预订的需求有差别，可以在用例图上突出一些特点。
如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
通过判断创新点在用例图中的位置。如果创新点属于直接与用户关联的用例，则在系统中的作用很重要。如果是子用例，则看与父用例的关系，如果是包含关系，则作用较大，如果是扩展用例，则作用较小。
- 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
| ID | Name | Imp | Est | How to demo | Notes |
|---|---|---|---|---|---|
| 1 | 酒店查询 | 50 | 10 | 通过 GPS 或者用户自行选择位置，利用地图或者列表信息进行一定范围内酒店信息查询 | 通过 GPS API 进行用户位置的定位 |
| 2 | 酒店选择 | 20 | 2 | 用户可以利用酒店的房间数、房间大小、酒店评价等信息进行酒店的选定 | 需要注意酒店信息的实时更新，特别是房间数量的实时更新 |
| 3 | 房间预定 | 80 | 5 | 选定酒店后需要进行房间的预定，用户输入入住者的身份证号码、是否需要保险、手机号码等必要信息后创建订单 | 需要进行用户身份信息的核验，避免通过虚假信息预定房间 |
| 4 | 订单管理 | 30 | 10 | 用户在创建订单后可以对订单信息进行修改，比如取消订单，修改入住天数以及添加备注等 | 特价房间不能取消订单，只能提示用户通过保险公司理赔 |
| 5 | 费用支付 | 60 | 8 | 用户进行订单费用的支付 | 可以通过微信、支付宝、银联进行订单支付 |
| 6 | 账户管理 | 40 | 4 | 用户进行头像、昵称、身份信息、预留手机等个人信息的修改 | 需要核验昵称或图片是否含有非法信息 |
根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算
根据用户点方法，对用例分配权重的标准是：
- 简单用例：1 到 3 个事务，权重=5
- 一般用例：4 到 7 个事务，权重=10
- 复杂用例：多于 7 个事务，权重=15
| 用例 | 事务 | 计算 | 原因 | UC权重 |
|---|---|---|---|---|
| 酒店查询 | 3 | 3 | 利用已知的酒店信息进行排序，或者用户输入关键词进行模糊查询 | 简单 |
| 酒店选择 | 6 | 5 | 提供酒店客房数量、客房类型、是否含有早餐等信息，需要及时更新客房信息 | 平均 |
| 房间预定 | 3 | 2 | 进行用户信息录入，创建订单 | 简单 |
| 订单管理 | 5 | 3 | 用户修改订单信息或取消订单 | 简单 |
| 费用支付 | 1 | 1 | 用户支付订单费用，调用API即可 | 简单 |
| 账户管理 | 4 | 1 | 用户修改个人信息 | 简单 |
评论