一、简答题

1. 用例的概念：

• 用例（英语：use case），或译使用案例、用况，是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。每个用例提供了一个或多个场景，该场景说明了系统是如何和最终用户或其它系统互动，也就是谁可以用系统做什么，从而获得一个明确的业务目标。编写用例时要避免使用技术术语，而应该用最终用户或者领域专家的语言。用例一般是由软件开发者和最终用户共同创作的。

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

• 用例场景是指实例化的用例，从一个用例实例化可以出来多个用例场景。简单讲，用例就是对全部用例场景的抽象，用例场景就是从用例中实例化出来的一组活动；
• 主场景：场景中最成功的一个，也就是用户与系统发生主要交互的那个。相对的可选场景则是不怎么频繁的交互和异常。
• happy path: 没有异常或错误条件的默认场景，即用户和系统可以很顺利、无误、符合预期地进行交互。

3. 用例有哪些形式？

• brief——简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围而进行使用的。
• Casua——非正式的段落格式，用几个段落覆盖不同场景。
• fully——详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证

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

• 复杂业务的场景多且复杂，并且其间关系复杂，需求多，会导致拓展部分也多，用例中很难全覆盖。对于单个场景，也难以考虑到所有的用户-系统的交互情况。

5. 什么是用例图？

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

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

 

• 参与者(Actor)参与者是系统外部与系统直接交互的人或事物，需要注意：参与者是角色，不是具体的某个人。参与者代表了用户与系统交互过程中所扮演的角色，所以在系统的实际使用中，一个用户可能对应着系统的多个参与者，一个参与者也可能对应多个真实的用户。参与者是作为外部用户与系统发生交互的，这是它的主要特征。UML中参与者用一个小人表示：
• 
  用例(Use Case)：用例是系统外部可见的一个系统功能单元，系统的功能是由系统功能单元组成和提供的，通过一系列的系统单元与参与者之间交换信息来表达。UML中用例用一个椭圆表示，椭圆中的文字描述系统的功能：
• 
  系统边界：系统边界表示正在建模系统的边界，边界内表示系统的组成部分，边界外表示系统外部。UML中系统边界用一个方框表示，并附上系统的名称，参与者在边界的外部，用例在边界内。
• 关系(Relationship)常见的关系包括：关联(Association)、泛化(Generalization)、包含(Include)和扩展(Extends)
  关联(Association)表示参与者与用例之间的通信，任何一方都可发送或接受消息。UML表示：用一条直线箭头指向消息接收方
• 扩展(Extends)扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。UML表示：用带箭头的虚线指向基础用例
• 包含(Include)包含关系用来将一个叫复杂用例所表示的功能分解成较小的部分。UML表示：用带箭头虚线指向分解出来的子功能用例
  
• 泛化(Inherits)泛化用来说明两个用例之间的继承关系，子用例继承父用例的所有结构、行为和关系，但是表现出更特别的行为。UML表示： 用空心箭头指向父用例。
  

7. 用例图的画法与步骤

• 语境建模
  • 识别系统外部的参与者。
  • 将类似参与者组织成泛化的结构层次。
  • 在需要加深理解的地方，为每个参与者提供一个构造型。
  • 将参与者放入到用例图中，并说明参与者与用例之间的通信路径。
• 需求建模
  • 识别系统的外部参与者来建立系统的语境
  • 考虑每一个参与者期望的行为或需要系统提供的行为。
  • 把公共的行为命名为用例。
• 确定提供者用例和扩展用例。
  • 对这些用例，参与者及其之间的关系建模。
  • 用注释修饰用例
     

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

1. 对于利益相关人

• 用例强调了用户的目标和观点，使得用户能够更多地参与到系统的设计当中去，保证系统按照用户的需求进行设计。而用例图则将用例图形化、具象化了，使得整个系统中用例、参与者之间的关系更加清晰地表达出来。
• 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。

2. 对于开发者

• 用例图使得开发者能够更明确地获得需求，更好地理解需求。
• 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

 

二、建模练习题

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

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

然后，回答下列问题：

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

• 相似系统的用例图的参与者是基本相同的；相似的系统由很多功能、服务是相同的，因此会出现相似甚至相同的用例

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

• 订旅馆业务可以结合用户曾经预定选择的周边要求来给用户推荐旅馆，同时可以设计新上线旅馆的优惠来增加旅馆的客户量和知名度。

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

• 根据用例图中创新业务和技术的位置，如果是直接于actor相连接，则是比较重要的创新点，甚至为一大板块；如果是子用例的拓展用例，则是具有一定局限性的创新点

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

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

用例事务	原因	计算	UC比重
注册	3	2	简单
登录	3	2	简单
寻找酒店	5	5	一般
预定房间	4	4	一般
管理订单	5	4	一般