系统设计与分析（四）

目录

• 简答题
  • 1. 用例的概念
  • 2. 用例和场景的关系？什么是主场景或 happy path？
  • 3. 用例有哪些形式？
  • 4. 对于复杂业务，为什么编制完整用例非常难？
  • 5. 什么是用例图？
  • 6. 用例图的基本符号与元素？
  • 7. 用例图的画法与步骤
  • 8. 用例图给利益相关人与开发者的价值有哪些？
• 建模练习题

简答题

1. 用例的概念

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

---

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

用例在实际执行的时候会有很多的不同情况发生，称之为用例场景；也可以说场景是用例的实例，我们在描述用例的时候要覆盖所有的用例场景，否则就有可能导致需求的遗漏。在用例规约中，场景的描述可以由基本流和备选流的组合来表示。场景既可以帮助我们防止需求的遗漏，同时也可以对后续的开发工作起到很大的帮助：开发人员必须实现所有的场景、测试人员可以根据用例场景来设计测试用例。

主场景或者happy path是指触发事件开始，逐步执行直至满足用户利益的步骤集合。

---

3. 用例有哪些形式？

• Brief

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

• Casual
  非正式的段落格式，包含多种场景的多个段落。

• Fully

  所有的步骤和变化都写得很详细，有支持部分，如先决条件和成功保证。在确定了许多用例并简要地编写之后
  格式，然后在第一次需求研讨会上一些(这样作为10%)的重要和高价值的建筑使用案例写得很详细。

---

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

因为对于复杂业务，设计到的场景会非常多，场景之间的相互关联也会使得用例建模变得复杂。同时，用例建模也需要对场景非常熟悉，需要对场景之间的相互关系有一定的了解，对于建模者的建模能力要求也更高，因此编制完整用例便变得非常难。

---

5. 什么是用例图？

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

---

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

用例图的基本符号与元素包括参与者、用例、子系统、关系

参与者：表示与您的应用程序或系统进行交互的用户、组织或外部系统，常用小人表示。

用例：外部可见的系统功能，对系统提供的服务进行描述，常用椭圆表示。

子系统：用来展示系统的一部分功能，这部分功能联系紧密。

关系：包括关联<>、泛化<>、包含<>、扩展<>

• 关联：表示参与者与用例的关系，符号为直线，由参与者指向用例。
• 泛化：表示继承关系，符号为带箭头的直线，由子用例指向父用例。
• 包含：表示当前用例包含其他用例的功能，符号为带箭头虚线，指向被包含用例。
• 扩展：表示用例功能的延伸，符号为带箭头的虚线，指向基础用例。

---

7. 用例图的画法与步骤

1. 确定研讨的系统

   使用用例图 System框 表示一个待研究的系统

2. 识别 Actors

   识别使用系统的主要参与者（primary actors）/角色(roles)

   识别系统依赖的外部系统

3. 识别用例（服务）

   识别用户级别用例（user goal level）

   识别子功能级别的用例（sub function level）

4. 建立 Actor 和 Use Cases 之间的关联

   使用 无方向连线，表示两间之间是双向交互的协议

---

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

• 用例图给利益相关人的价值：

  用例图能够清晰地展现系统的功能与设计，能够保证系统的设计满足客户的需求，同时能够让客户参与到其中，充分与客户沟通，理解客户的需求，完善系统的功能。

• 用例图给开发者带来的价值：

  用例图能够清晰地给开发者展示系统的设计过程，更加清晰地了解客户的需求，明确系统的功能与边界，进而确定软件开发的方法和迭代周期，对软件的管理和完善起到比较好的作用。

---

建模练习题

• 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
  • 请使用用户的视角，描述用户目标或系统提供的服务
  • 粒度达到子用例级别，并用 include 和 exclude 关联它们
  • 请用色彩标注出你认为创新（区别于竞争对手的）用例或子用例
  • 尽可能识别外部系统和服务
• 然后，回答下列问题：
  1. 为什么相似系统的用例图是相似的？
  2. 如果是定旅馆业务，请对比 Asg_RH 用例图，简述如何利用不同时代、不同地区产品的用例图，展现、突出创新业务和技术
  3. 如何利用用例图定位创新思路（业务创新、或技术创新、或商业模式创新）在系统中的作用
  4. 请使用 SCRUM 方法，选择一个用例图，编制某定旅馆开发的需求（backlog）开发计划表
  5. 根据任务4，参考 使用用例点估算软件成本，给出项目用例点的估算

---

1. 万达电影App
   

2. 百词斩App
   

回答问题：

1. 因为相似系统需要应对的场景往往都是相似的，如订票和买东西都需要支付，涉及到预定的往往都需要定位到特定的地点，这些都需要找位置，需要实现找位置的功能，这些都是必须要实现的，因此用例图往往都是相似的。

2. 不同时代，不同地区的用户对酒店的需求不相同，因此随着时代的演进，可以更新酒店的评论系统和推荐系统的算法，不同地区，如宗教地区，旅游文化地区等等，可以根据地方特定增加一些适当的筛选功能。

3. 若创新思路是用例图中的父节点，则创新的突破性和作用比较大，如果是被包括的用例或者是子用例，则创新性较小。

4. 课上酒店用例图的backlog

Id	Name	Imp	Est
1	Find hotel	30	5
2	Make reservation	30	10
3	Manage basket	90	16
4	Pay	70	8
5	Login	80	16

1. 根据用户点方法，对用例分配权重的标准是：

• 简单用例：1 到 3 个事务，权重=5
• 一般用例：4 到 7 个事务，权重=10
• 复杂用例：多于 7 个事务，权重=15

用例	事务	计算	原因	UC权重
1 Find hotel	3	5		简单
2 Make reservation	5	10		一般
3 Manage basket	5	7		一般
4 Pay	2	5		简单
5 Login	4	8		一般