1、简答题

1.用例的概念

在软件和系统工程中，用例是一种对系统如何反应外界请求的描述，通常通过用户的使用场景来获取需求。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

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

关系：每个用例提供了一个或多个场景。其中场景是指使用场景，用来说明系统可以做什么，系统是如何和用户或其他系统交互的，从而获得一个明确的业务目标。
主场景：也被称为 happy path，每一个用例中都包含一个主场景，主场景对应于系统主要的交互，通常是成功的场景，是最常用的直接地实现用户目标的场景。

3.用例有哪些形式？

• Brief（high level）：通常是简短的一段总结，描述主场景，在早起需求中可以快速了解主题和范围，方便快速创建。
• Casual：非正式的段落格式，涵盖各种场景的多个段落。
• Fully：所有的步骤和变化都写得很详细，并有支持部分，如先决条件和成功的保证。

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

复杂业务涉及到的场景比较多，业务流程复杂繁琐，场景之间也有各种关联，如果要编制完整的用例，需要熟悉各种业务场景和流程，还需要建模相关知识，注意用户交互的细节，并且增加了提取一个场景中的主要元素的难度。

5.什么是用例图？

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

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

• 参与者（Actor）：符号是一个小人。参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
• 用例（Use Case）：符号是一个圆框。用例是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
• 子系统(Subsystem)：符号是一个方框。用来展示系统的一部分功能，这部分功能联系紧密。
• 关系：用例图中涉及的关系有：关联、泛化、包含、扩展。
  • a. 关联(Association)：符号是一个虚线箭头：---->，箭头指向消息接收方。表示参与者与用例之间的通信，任何一方都可发送或接受消息。
  • b. 泛化(Inheritance)：符号是一个实线箭头，箭头是个小三角，指向父用例。就是通常理解的继承关系，子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。
  • c. 包含(Include)：符号是一个虚线箭头，有< includes >标识。箭头方向指向被包含者。包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。
  • d. 扩展(Extend)：符号是一个虚线箭头，有< extends >标识，箭头方向指向被继承者。扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。
  • e. 依赖(Dependency)：但VS2010的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。箭头指向被依赖项。
• 项目(Artifact)：用例图虽然是用来帮助人们形象地理解功能需求，但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强，VS2010中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。
• 注释(Comment)

 

7.用例图的画法与步骤

1.确定系统边界
2.确定参与者：如谁将使用该系统的主要功能、谁将需要该系统的支持以完成其工作、谁将需要维护、管理该系统，以及保持该系统处于工作状态等。
3.识别用例：如特定参与者希望系统提供什么功能、系统是否存储和检索信息，如果是，由哪个参与者触发、当系统改变状态时，是否通知参与者、是否存在影响系统的外部事件等。
5.确定用例间的关系：如包含关系、扩展关系和泛化关系。应用这些关系的目的是为了从系统中抽取出公共行为和其变体。
6.确定关联的外部支持系统，放在系统框右边。

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

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

 

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

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

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

马蜂窝预定酒店

美团外卖

 

• 然后，回答下列问题：

 

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

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

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

创新的思路与方法在于，要发现早期项目中不足的地方，结合新时代技术上的发展，将项目需求更加细致化，更贴合人们的使用习惯，以及创新出更加方便的功能供人们使用。

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

在用例图中对创新用例使用某种颜色进行高亮标记。可以很方便地让需求方、开发人员快速了解该系统的创新功能，以及该模块相关依赖和输入输出结果。

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

ID	需求名称	重要性	工作量	需求目标	注意事项
1	预定旅馆	100	15	可以查看旅馆详情以及可以根据日期预留房间	需要考虑房间容量及空闲情况
2	搜索旅馆	90	10	可以通过关键字以及日期、城市名称进行旅馆搜索	需要通过筛选功能对酒店进行优先级排序
3	确定订单	80	8	可以修改房间的预订信息，如时间、房间号等	必须把订单全部详情显示出来
4	支付订单	70	7	可以选择不同支付方式支付订单	注意支付异常反馈

 

 

 

 

 

 

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

用户点方法对用例分配权重的标准：
简单用例：1 到 3 个事务，权重=5
一般用例：4 到 7 个事务，权重=10
复杂用例：多于 7 个事务，权重=15

用例	`事务	计算	UC权重
预定旅馆	3	2	简单
搜索旅馆	4	4	一般
确定订单	2	3	简单
支付订单	2	1	简单