系统分析与设计—hw4

简答题

1. 用例的概念

用例（Use Case），也叫使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。通俗地讲，用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。

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

用例是是一组相关的成功和失败的场景（success and failure scenarios），这些场景是用于描述一个actor使用系统去support一个目标（goal）。

我认为问题这里提到的主场景应该是指书上的主成功场景（Main Success Scenario），也叫做基本流程（基本事件流，basic flow)、理想路径场景（happy path），这是用例最基本的组成部分，它描述了满足涉众关注点的典型成功路径。

主场景通常不包括任何条件或分支，这是为了保持连贯性，并且将所有的条件处理都延迟到扩展部分。通常一个用例具有一个基本流和多个例外流。

3.用例有哪些形式？

• Brief (high level)
  • Terse one-paragraph summary, usually of the main success
    scenario.（简洁的一段式概要，通常用于主成功场景）
  • During early requirements analysis, to get a quick sense of subject and scope. May take only a few minutes to create.（在早期需求分析过程中使用，目的是为了快速了解主题和范围。可能只需要几分钟进行编写）
• Casual（简便格式）
  • Informal paragraph format. Multiple paragraphs that cover various scenarios.（非正式的段落格式。用几个段落覆盖不同场景）
  • When? As above.（时间点同上）
• Fully（详述）
  • dressed All steps and variations are written in detail, and there are supporting sections, such as preconditions and success guarantees.（详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证）。
    • After many use cases have been identified and written in a brief format, then during the first requirements workshop a few (such as 10%) of the architecturally significant and high-value use cases are written in detail.（在确定并以摘要形式白那些了大量用例后，在第一次需求讨论会中，详细地编写其中少量（例如10%）的具有重要架构意义和高价值的用例）

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

首先，整个用例编写过程当中，理想路径与扩展场景相结合也只能尽可能满足“几乎”所有涉众所关注的问题，因为有些问题最好是作为非功能性需求在补充规格说明中描述，而不是直接在用例中说明。
此外，由于业务的复杂性，在简单的需求讨论和短时间的开发迭代中，一定无法覆盖整个业务的所有需求，因此用例的增加也只能覆盖大部分已出现的情形，而无法完全覆盖所有情景，也就“不完整”。同时，用例可能会遗漏一些关键信息或包含错误的陈述。

5.什么是用例图？

用例图是一种优秀的系统语境图（context diagram），也就是说用例图可以展示系统边界、位于边界之外的事物以及系统如何被使用。同时，用例图可以作为沟通的工具，用以概括系统及其参与者的行为。

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

用例图主要用来描述用户、需求、系统功能单元之间的关系。用例图的基本符号及元素如下所示：

1. 参与者（Actor）：表示与系统或程序进行交互的用户、组织或外部系统。
2. 用例（Use Case）：外部可用的系统功能，对系统提供的服务进行描述。

3. 子系统（Subsystem）：用来展示系统的一部分功能，这部分功能一般具有紧密的联系。

   

4. 关系（relation）：用例图中涉及到的关系包括关联、泛化、包含、扩展。

• 关联（Association）：说明了参与者与用例之间的通信，任何一方都可以发送或接受信息，箭头指向的是消息的接收方

• 泛化（Inheritance）：就是通常理解的继承关系，子用例继承了父用例的所有结构、行为和关系，同时表现出更特别的行为。子用例可以选择使用或者重载父用例的一段行为，而父用例一般是抽象的。

• 包含（Include）：包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤，箭头指向分解出来的功能用例，旁边需要显式写出该关系（《包含》或者<Includes>）

• 扩展（Extend）：扩展关系是指当前用例功能的延伸，相当于给当前基础样例提供附加的功能。箭头指向原来的基础样例。

7.用例图的画法与步骤

1. 确认系统边界，包括系统名称以及系统的范围（方框所包含的东西)

2. 确定参与者，包括:
   • 主要参与者：谁将使用系统的主要功能、谁将需要系统的支持以完成工作等
   • 协作参与者：谁将提供对应的系统功能、谁将维护系统，保证系统处于工作状态等
   • 幕后参与者：谁会对系统产生的结果感兴趣

3. 根据用户需求识别和创作用例，主要重点在于：

   • 参与者希望系统提供什么样的功能（用例）
   • 系统具有哪些功能（用例），如是否支持存储和检索信息
   • 系统对应的功能由哪些参与者触发
   • 当系统状态改变时，参与者是否会得到通知
   • 参与者与事件的对应关系
   • 是否存在影响系统的外部事件

4. 确认用例间的关系，包括关联、包含、扩展和泛化

5. 确定外部接口，如API的调用
6. 根据上面已经确定的关系已经用例图规范进行用例图的绘制，可以借助例表来详细说明一个较复杂（可能无法只通过用例图说明清楚）的用例

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

• 用例强调了用户的目标和观点，使得用户能够更多地参与到系统的设计当中去，保证系统按照用户的需求进行设计。而用例图则将用例图形化、具象化了，使得整个系统中用例、参与者之间的关系更加清晰地表达出来。
• 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
• 用例图使得开发者能够更明确地获得需求，更好地理解需求。
• 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

2、建模练习题（用例模型）

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

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

这是一个在线民宿租赁网站的用例模型：

这是一个演出门票销售网站的用例模型：

然后，回答下列问题：

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

因为相似的系统中，用户预期的功能都是相似的，即不同的同类系统一定具有一致基本功能以及带有自己特色的扩展功能。以酒店预订系统为例，使用该系统的用户一般提供时间、地点、价格等信息，利用系统来搜索出符合信息的房间并进行预定，因此所有的系统都需要包括这样的功能，才能够满足用户的需求。因此，相似的系统一定会有相似的功能，也就具有相似的actor、use case和associate，因此也就具有相似的用例图。

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

对比Asg_RH与airbnb的用例图，可以对比发现技术的创新具有以下角度：

1. 可以从时代特性和对应的用户需求出发。如现在是一个快节奏的时代，用户追求效率和便利的操作。对比airbnb和asg_rh，airbnb的操作无疑更加简单快捷，且具有一个更优秀的过滤系统，提供了多种条件来供用户对房源进行过滤，使得用户更高效地挑选到自己心仪的房源，很大程度地提升了用户的使用体验。
2. 从业务创新出发。对比传统的酒店预定系统只能够预定房间，airbnb考虑到了用户属性的多样性，即他们本身也可能具有闲置的房源，扩充了软件使用者的属性，使user可以在租客和租户的身份之间自由切换，提供了更多的功能选择。
3. 从用户信息保护和反馈出发。首先，airbnb较传统的订旅馆业务而言，对用户的信息作出了更好的保护，如只有在预定房间之后才知道房间的准确定位，这无疑是对民宿类的房间信息有了更好的保护。其次，airbnb提供了双向的评价，即用户和提供住宿的组织在完成一次交易后是互相评价的，这样有效地筛选出了优质的用户和租赁方。
4. 从吸引用户的角度出发。airbnb通过合理分析用户的上传数据，提供了一些“猜你喜欢”的功能以及活动奖励，有效地提升了用户粘性以及软件对用户的吸引力。

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

使用不同颜色背景的用例图表示不同层次和方式的创新思路，使得其在系统中的作用能够直观体现。

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

Product Backlog 是 Scrum 的核心，也是一切的起源。从根本上说，它就是一个需求、或故事、或特性等组成的列表，按照重要性的级别进行了排序。它里面包含的是客户想要的东西，并用客户的术语加以描述。我们叫它故事（Story），有时候也叫做 Backlog 条目。 一般包括以下字段：

• ID：统一标识符，就是个自增长的数字而已。以防重命名故事以后找不到它们。
• Name（名称）：简短的、描述性的故事名。比如“查看你自己的交易明细”。它必须要含义明确，这样开发人员和产品负责人才能大致明白我们说的是什么东西，跟其他故事区分开。它一般由2到10个字组成。
• Importance（重要性）：产品负责人评出一个数值，指示这个故事有多重要。例如10或150。分数越高越重要。
• Initial Estimate（初始估算）：团队的初步估算，表示与其他故事相比，完成该故事所需的工作量。最小的单位是故事点（story point），一般大致相当于一个“一个人一天理想的工作量（man-day）”。
• How to demo（如何做演示）：它大略描述了这个故事应该如何在 sprint 演示上进行示范，本质就是一个简单的测试规范。“先这样做，然后那样做，就应该得到……的结果”。

ID	Name	Imp	Est	How to demo	Notes
1	搜索房源	90	20	用户输入目的地，选择入住和离开日期、入住人数、等信息，点击搜索，系统智能推荐房源	需要使用 GPS 定位系统的 API 来确定用户当前位置以及目的城市的位置；需要实现完善的表单提交功能。
2	预定房源	100	25	用户在推荐的房源中挑选出心仪的房源并输入信息进行预定	需要有优秀的筛选过滤算法。需要实现全面的排序功能。
3	支付订单	80	15	用户支付已经提交的订单，并获取房源的具体位置信息	需要有优秀的状态判断算法，能够实时更新用户订单状态并提供反馈。需要调用第三方的支付API。
4	评价订单	80	25	用户和房源方对已完成的订单进行双向评价。	需要使用完备的评价系统，注意保护双方评价的真实性和隐私性。

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

用例	业务	计算	原因	UC比重
查找酒店	3	3		简单
结果排序	3	3		简单
预定酒店	6	4		平均
付款	3	2		简单
查看定位	3	3		简单
推荐	5	3		平均
双方评价	4	3		平均

---

附录：一个简单的软件规模用例点数计算

（1）角色复杂度等级划分及计数

用例点估算法介绍

Total UAW 44

（2）用例复杂度等级划分及计数

用例点估算法介绍

Total UUCW 220

（3）计算未平衡用例点数

将UAW与UUCW相加得出未平衡用例点数（ Unadjusted Use Case Point ，UUCP）

UUCP=UAW+UUCW=44+ 220=264

（4）使用技术复杂度因子平衡

用例点估算法介绍
TCF = 0.6 + (.01*Total Factor). 图1中, TCF = 1.07

（5）使用环境复杂度因子平衡
用例点估算法介绍

ECF = 1.4 + (-0.03*Total Factor). ECF = 0.62

（6）软件规模用例点数计算公式如下

软件规模举例：UCP=TCFECFUUCP =1.07 0.62264=175