系统分析与设计第六周作业

一、
1.是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。 每个用例提供了一个或多个场景,该场景说明了系统是如何和最终用户或其他系统互动,也就是谁可以用系统做什么,从而获得一个明确的业务目标.
2.场景是actors和系统之间特定的一系列动作和绘画，是用例的实例。一个用例是一些场景的集合。主成功场景或happy path是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合。
3.简洁： 一段简介，通常是主要的成功场景。在早期的需求分析中，可以获得对于主体和范围的快速认识，方便快速创建。
因果： 非正式的段落形式，使用多个段落包含多个场景
完整： 所有的步骤和变化都详细写明，有支持的部分，比如先决条件和成功的保证。
4.复杂的业务涉及到的场景非常多，且场景与场景之间也有各种各样的关联，要编制完整用例不但需要熟悉各种业务场景和流程，还要懂得建模相关的专业知识，如何分离和提炼一个场景的主要元素也是在复杂场景中显得尤为重要和困难。
5.用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图，也是外部用户所能观察到的系统功能的模型图。
6.参与者： 表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或外部系统。
用例： 表示的是对系统提供的功能、服务的一种描述。
包含关系： 表示用例可以简单地包含其他用例所具有的行为，并把它所包含的用例行为作为自身行为的一部分。
泛化关系： 泛化指的是一个父用例可以被特定化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
关联关系： 表示的是参与者与用例之间的关系。
扩展/延伸关系： 表示在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例，原有的用例叫做基础用例，相当于为基础用例提供一个附加功能。
7.
先确定用例、系统，然后识别参与者，识别参与者和用例间的关系
作图：
（1）使用参与者自身能够理解的名称重命名用例，不要使用与代码有关的名称
（2）从主要的事务开始，直到后面较小的交互为止
（3）将每个用例放入支持它的系统或主要子系统（忽略只与用户有关的外观或组件）
（4）可以在系统边界外绘制用例，表明系统不支持该用例
8.每个用例制定了系统提供给客户的有用功能单元，使得客户可以更加清晰地看到系统的用途
对于软件开发者，用例细化了用户的需求，以及软件的使用方式，可以使得软件架构的设计思路更加清晰
二、
携程

榛果民俗

1.业务相似，因此用户预期的功能相似，所以体现在用例图上也是相似的。
2.利用虚拟现实，让用户亲身感受酒店房间情况
3.

ID	Name	imp	est	how to demo	note
1	注册登录	15	2	打开软件后用户可以选择登录或者注册；登录时使用已注册的账号和密码进行登录；注册时使用手机+验证码的形式；
2	查询酒店	20	2	选择位置、日期，输入特征关键词，选择价格区间和酒店档次，选择酒店类型后，能够返回符合检索条件的酒店列表。
3	预定	25	3	用户点击预定房间时，判断是否有空房，然后进行下单预定	下单时会锁定，其他用户无法预定
4	支付	20	2	用户锁定房间后20分钟内需要进行支付
5	查看订单	10	1	查看订单详情
6	取消订单	10	1	入住前可以取消订单，取消后可退款

用例	事务	计算	权重
登录注册	2	1	简单
查询酒店	4	1	简单
预定	5	5	复杂
支付	6	5	复杂
查看订单	2	1	简单
取消订单	2	1	简单