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

简答题

1.用例的概念

用例是行为或事件步骤的列表，通常定义角色和系统之间的交互以实现目标。它是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。用例一般是由软件开发者和最终用户共同创作的。

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

场景是一个事件或一系列行动和事件的概要拼接，是对用户角色和技术系统可预见的交互的叙述，通常包括计算机硬件和软件。用例是是一组相关的成功和失败的场景。
Happy path是一个没有异常或错误条件的默认场景。它让执行成果的能继续运行到最后，从而生成积极的响应。

3.用例有哪些形式？

1)摘要：简洁的一段式概要，通常用于主场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间编写.

2)非正式：非正式的段落格式，用几个段落覆盖不同的场景。

3)详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。

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

复杂业务的需求多，导致扩展部分较多，即除了主场景外的其他场景或分支，包括成功和失败路径。而在整个用例编写过程当中，理想路径与扩展场景相结合也只能尽可能满足“几乎”所有涉众所关注的问题，因为有些问题最好是作为非功能性需求在补充规格说明中描述，而不是直接在用例中说明。因此由于业务的复杂性，用例的增加也只能覆盖大部分已出现的情形，而无法完全覆盖所有情景，也就“不完整”。同时，用例可能会遗漏一些关键信息或包含错误的陈述。

5.什么是用例图？

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

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

参与者          用例	    箭头  	       系统边界

参与者：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
用例：用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
系统边界：系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。
箭头：箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方，箭头头部用来表示被启动的一方，其中用例总是要由参与者来启动。它涉及到关联、包含、扩展和泛化四种关系。

7.用例图的画法与步骤

第一步：确定参与者
在获取用例前首先要确定系统的参与者，开发人员可以通过回答以下的问题来寻找系统的参与者。
（1） 谁将使用该系统的主要功能。
（2） 谁将需要该系统的支持以完成其工作。
（3） 谁将需要维护、管理该系统，以及保持该系统处于工作状态。
（4） 系统需要处理哪些硬件设备。
（5） 与该系统那个交互的是什么系统。
（6） 谁或什么系统对本系统产生的结果感兴趣。
第二步：识别用例。用例图对整个系统建模过程非常重要，在绘制系统用例图前，还有许多工作要做。系统分析者必须分析系统的参与者和用例，他们分别描述了“谁来做”和“做什么”这两个问题。
识别用例最好的方法就是从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。使用这种策略的过程中可能会发现新的参与者，这对完善整个系统的建模有很大的帮助。用例建模的过程是一个迭代和逐步精华的过程，系统分析者首先从用例的名称开始，然后添加用例的细节信息。这些信息由简短的描述组成，它们被精华成完整的规格说明。
在识别用例的过程中，通过回答以下几个问题，系统分析者可以获得帮助。
（1） 特定参与者希望系统提供什么功能。
（2） 系统是否存储和检索信息，如果是，由哪个参与者触发。
（3） 当系统改变状态时，是否通知参与者。
（4） 是否存在影响系统的外部事件。
（5） 哪个参与者通知系统这些事件。
第三步：确认关系
用例除了与参与者发生关系外，还可以具有系统中的多个关系，这些关系包括包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。

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

(1)用例图模拟了参与者和系统之间的通信，并提供了系统使用和行为的摘要视图。此摘要视图提供了对总体需求的直接理解，然后读者可以深入了解特定参与者并使用感兴趣的案例。
(2)用例图可以通过显示系统的预期行为来组织需求。
(3)用例图可以有效地总结用户（参与者）与将为企业提供价值的系统之间所需的交互。
(4)用例图以图形方式显示重用用例的机会;此重用处于需求级别，并通过包含和扩展机制在用例图中建模。
(5)用例图可以帮助将大型系统划分为多个模块。每个模块本身可以由用例图表示。
(6)促进项目估算：用例图可用于估计项目规模和复杂性，因为它们显示了用例存在的上下文，并与其他用例和参与者相关。例如，涉及简单用户界面并且需要最少数据库交互的用例可以被归类为简单任务。另一方面，涉及复杂用户界面和多个数据库交互的复杂用例可以被归类为复杂任务，并在时间尺度中分配最高值。

建模练习题

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

• 请使用用户的视角，描述用户目标或系统提供的服务
• 粒度达到子用例级别，并用 include 和 exclude 关联它们
• 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
• 尽可能识别外部系统和服务
• 
• 然后，回答下列问题：

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

因为相似的系统需求是相似的，核心功能也是相似的。

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

Asg_RH仅仅满足了用户预约酒店的功能，与今天的软件相比，它缺少了评论这类社交功能。用户无法从其他用户那里得到反馈，因此也不能通过软件了解酒店的真实情况。其次就是定位，虽然酒店有提供地址信息，但也应该与第三方合作（如百度导航），方便用户在第三方软件上也能找到酒店的位置。

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

可以通过设置背景颜色显示出创新思路对其他部分的影响。也可以根据用例图的用户级别来判断其作用。

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

ID	Name	Imp	Est	How
1	搜索	20	10	根据关键字搜索匹配的酒店。选定时间地点后可获得相应匹配的酒店列表。
2	选择酒店	50	30	提供酒店列表。在满足关键字的前提下，给出可选酒店列表，并提供基本的酒店信息。
3	选择房间	20	10	选定酒店后，选择房间的类型。已满的房间会有提示。
4	确认订单	40	20	确认所选订单。重新显示所选信息，并选择支付渠道，如微信、支付宝。
5	用户评价	30	10	用户完成订单后可在7个工作日内进行评分

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

用例	业务	计算	UC比重
搜索酒店	3	2	简单
预订酒店	4	4	平均
确认支付	3	1	简单
用户评价	1	1	简单