简答题

用例的概念

用例（use case），是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。广泛应用于需求的发现和记录工作中。

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

用例和场景的关系：每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。

主场景（happy path）：典型的、无条件的、理想方式的成功场景。描述了满足涉众关注点的典型成功路径。通常不包括任何条件或分支。

用例有哪些形式

1. 摘要形式：简洁的一段式概要，通常用于主成功场景。在需求分析的早期，我们可以通过它来快速了解项目的主体和范围。
2. 简便形式：非正式的段落格式，用几个段落覆盖不同场景。
3. 详述形式：详细编写所有步骤及各种变化，同时具有补充部分(如：前置条件和成功保证)。它是在确定并以摘要形式编写了大量用例后，在第一次需求讨论会中详细地编写的其中少量的具有重要架构意义和高价值的用例。

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

   一个复杂的业务，其系统边界常常是很难界定清楚的。除此以外，它涉及的主要参与者也很多，故确定每个主要参与者的目标也会变得非常困难，毕竟我们需要做大量的研究和调查才能了解不同类型参与者的需求。综上，对于复杂业务，编制完整的用例是非常困难的。

   什么是用例图？

   用例图是指由参与者、用例、边界以及它们之间的关系构成的用于描述系统功能的视图。

基本符号与元素

• 参与者：参与者不是特指人，是指系统以外的，在使用系统或与系统交互中所扮演的角色。因此参与者可以是人，可以是事物，也可以是时间或其他系统等等。还有一点要注意的是，参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
• 用例：是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。
• 系统边界：系统边界是用来表示正在建模系统的边界。
• 箭头：箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。常见的关系有includes和extends。
  • includes：表示一个用例的存在依赖与另一个用例。
  • extends：表示一个用例是另一个用例的可选拓展功能。

    用例图的画法与步骤

    1. 确定系统边界;
    2. 识别系统的参与者：参与者包括主要参与者和系统依赖的外部系统。参与者画在系统边界以外，且主要参与者一般画在系统的左边，依赖的外部系统一般画在系统的右边；
    3. 识别用例：用例的命名要以动词开始。另外，用例还分为用户级别用例和子功能级别的用例，两种用例之间存在<< includes >>和<< extends >>关系。
    4. 建立参与者和用例之间的关联：用无方向的连线将相关联的两者连接起来。 ### 用例图给利益相关人与开发者的价值有哪些？
    1. 使领域专家或需求提供者自己编写（或参与编写）用例成为可能，并使这项工作难度降低。
    2. 强调了用户的目标和观点，能够根据需要对复杂程度和形式化程度进行增减调节。 ## 建模练习题 ### 选择2-3个你熟悉的类似业务的在线服务系统（或移动 APP），如定旅馆（携程、去哪儿等）、定电影票、背单词APP等，分别绘制它们用例图。并满足以下要求：
    

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

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

  用例图反映的是系统的功能和使用者与系统的交互方式，相似的系统有着相似的功能和交互方式，因此其用例图也是相似的。

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

  可以利用不同颜色的标注来定位创新点。

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