系统分析与设计作业六

系统分析与设计作业六

王晶 16340217

一、简答题

1. 用例的概念

用例（use case），是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

2. 用例和场景的关系？什么是主场景或 happy path？

场景是参与者和系统之间的一系列特定的活动和交互，也称为用例实例。场景是使用系统的一个特定情节或用例的一条执行路径。例如使用现金成功购买商品的场景，或使用信用卡付款被拒造成购买失败的场景。

而用例就是一组相关的成功和失败场景的集合，用来描述参与者如何使用系统来实现其目标。

主场景就是参与者在用例中所遵循的主逻辑路径。因为它描述了当各项工作都正常时用例的工作方式，所以通常也称为成功路径(happy path)

3. 用例有哪些形式？

• Brief：简短的一段总结，通常是主要的成功场景。在早期的需求分析中，为了快速了解主题和范围，可能只需要几分钟就可以创建。

• Casual：非正式段落格式。涵盖各种场景的多个段落。

• Fully：详细写出所有步骤和变化都，并且有支持部分，如前提条件和成功保障。

4. 对于复杂业务，为什么编制完整用例非常难？

复杂业务的子用例非常多，流程复杂，且需要处理的场景很多。因此很难考虑完全所有子用例和场景，且绘制的用例图繁杂，容易出错。而完整用例需要将所有步骤和变化都详细写出，实际难以覆盖现实世界的全部业务情况和流程情况，并且会耗费大量人力物力，且容易出错。

5. 什么是用例图？

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。

6. 用例图的基本符号与元素？

1. 参与者(Actor)——与应用程序或系统进行交互的用户、组织或外部系统。用一个小人表示。

2. 用例(Use Case)——用例就是外部可见的系统功能，对系统提供的服务进行描述。用椭圆表示。

3. 子系统(Subsystem)——用来展示系统的一部分功能，这部分功能联系紧密。

二、用例图所包含的的关系

用例图中涉及的关系有：关联、泛化、包含、扩展。

如下表所示：

a. 关联(Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

【箭头指向】：无箭头，将参与者与用例相连接，指向消息接收方
　　
　　

b. 泛化(Inheritance)

就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

【箭头指向】：指向父用例
　　
　　

c. 包含(Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那添加、修改以及删除都要在用例详述中描述，过于复杂；如果分成添加用例、修改用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

【箭头指向】：指向分解出来的功能用例
　　
　　

d. 扩展(Extend)

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例，可以在基用例上有几个扩展点。

【箭头指向】：指向基础用例
　　
　　

7. 用例图的画法与步骤

1. 确定系统的范围和边界，通过方框表示
2. 确定系统的参与者，用小人表示
3. 确定和描述用例，通过椭圆框表示，在方框内则表示系统的内部功能
4. 对用例分类，并确定用例之间的关系
5. 参与者与用例的联系用实线连接
6. 建立用例图，并定义用例图的层次结构
7. 确认用例间的关系，包括包含和扩展
8. 评审用例模型

8. 用例图给利益相关人与开发者的价值有哪些？

对于利益相关者：

1. 可以直观看到系统的功能和操作过程，保证系统按用户的需求进行设计
2. 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关者）提出的需求，而用例图则使得这种调节更加便利，可以通过修改修改用例图来实现。

对于开发者：

1. 明确系统的业务范围、服务对象（角色）、外部系统与设备
2. 帮助识别技术风险，提前实施关键技术原型攻关与学习
3. 易于评估项目工作量，合理规划迭代周期，规划人力需要

---

建模练习题（用例模型）

选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：

• 请使用用户的视角，描述用户目标或系统提供的服务

• 粒度达到子用例级别，并用 include 和 exclude 关联它们

• 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例

• 尽可能识别外部系统和服务

1. 淘票票

2. 携程订酒店

---

然后，回答下列问题：

1. 为什么相似系统的用例图是相似的？

相似系统面对的参与者和用例是相似的，用例之间的关系也是同构的。用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。

2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术

首先，对于用户来说，简单的操作逻辑无疑更能增加用户的体验，而将复杂的流程缩短，或者运用智能技术为用户提供更合理的参数，都能提高用户的体验。
除此之外，用户对服务的要求会不同，而不是“能住就行”，用户除了需要对酒店的客观等级评价之外，还需要能了解到其他用户对酒店的主观评价。
然后可以利用新的算法和技术，以及数据，来给为用户提供的更加合适，更加拟合需求的酒店，并且除了酒店之外，可以提供额外的延伸服务。

3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用

通过判断创新点在用例图中的位置。如果创新点属于直接与用户关联的用例，则在系统中的作用很重要。如果是子用例，则看与父用例的关系，如果是包含关系，则作用较大，如果是扩展用例，则作用较小，然后不同类型的创新可以通过不同的背景色来区别。

4. 请使用SCRUM方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表

ID	Name	Imp	Est	How to Demo	Notes
1	查找酒店	40	5	输入城市，入住日期，退房日期，房间价格即可搜索到相关酒店	通过调用GPS的API来确定用户当前的位置
2	选择酒店	50	5	通过选择星级，评价，价格等可以进行结果排序。用户选择酒店后，筛选出想要预定的房间类型，填写个人信息并确定无误后即可下单	需要合适的算法对筛选结果进行排序，或者增加足够的筛选因素供顾客选择
3	支付订单	30	3	提供多种支付方式来满足不同类型的人群，包括微信/支付宝支付，银行卡支付，以及到店现金支付	通过调用各平台API，接入用户支付借口
4	评价体验	40	4	促使对自己住过的酒店进行评价，打分，以及让用户可以看到其他人对酒店的评价，帮助用户更好地选择酒店	对评论分类，并提取有用的数据，对酒店排序提供更加有效的分析

5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算

用例	业务	计算	原因	UC权重	估算
1	查找酒店	4	3		平均
2	预定酒店	8	6		困难
3	支付订单	3	2		简单
4	评价体验	6	5		平均