1.简答题

1.1 用例的概念

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

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

• 用例是一些相关的场景的集合，这些场景是用于描述一个actor使用系统去实现一个目标。
• 主场景或happy path是用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合
• 主成功场景应该包括以下信息：
  • 两个执行者之间的交互。如，用户提交了订单。
  • 为保证主成功场景得以继续的确认。如，系统确认用户密码。
  • 主成功场景推进过程中的内部变化。如，系统扣除用户账户余额。

1.3 用例有哪些形式？

• 摘要：简洁的一段式概要，通常用于主成功场景。在早期需求分析过程中，为快速了解主题和范围，通常花费少量时间快速编写。
• 非正式形式：非正式的段落格式，用几个段落覆盖不同的场景。
• 详述：详细编写所有步骤和各种变化，同时具有补充部分，如前置条件和成功保证。确定并以摘要形式编写大量用例后，在第一次需求讨论中，详细地编写其中少量的具有重要架构意义和高价值的用例。

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

复杂业务的场景较多，场景较为复杂。在前期的考虑中，很难不遗漏一些业务条件和需求，且这些需求条件还可能发生变化。所以对于复杂业务，编制完整用例且不遗漏情景、良好地安排每个场景、场景内元素地关系非常困难。

1.5 什么是用例图？

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

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

• 参与者（Actor）
  表示的是一个系统用户，也就是与应用程序进行交互的用户、组织或者外部系统。
  

• 用例(Use Case)
  表示的是对系统提供的功能、服务的一种描述。
  

• 系统边界
  指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。在UML图中用一个矩形表示。
  

• 关系

  • 关联：表示参与者和用例之间的交互。为通信途径，任何一方都可发送或可接收消息。箭头指向：指向消息接收方。在UML中用直线表示。
    

  • 包含：包含关系用来把一个较复杂的用例所表示的功能分解成较小的步骤。包含用例是必须的，如果缺少包含用例，基用例就是不完整的。包含关系最典型的应用就是复用。这种情况类似与在过程设计语言中，将程序的某一段算法封装成一个子过程，然后在从主程序中调用这一子过程。在UML中，包含关系用带箭头的虚线段加《include》表示，箭头指向被包含的用例。
    

  • 扩展：扩展关系是指用例功能的延伸。与包含关系不同的是，扩展用例是可选的，如果缺少扩展用例。不会影响到基用例的完整性。在UML中，扩展关系用带箭头的虚线段加《extend》表示，要注意的是箭头指向基用例。
    

  • 泛化：用例的泛化指的是一个父用例可以被特化形成多个子用例，用我们熟悉的语言来说就是继承关系。在UML中，泛化关系用空心箭头表示，箭头指向的是父用例。
    

1.7 用例图的画法与步骤

• 确定参与者
  • 主要参与者：谁将使用系统的主要功能、谁将需要系统的支持以完成工作等。
  • 协作参与者：谁将提供对应的系统功能、谁将维护系统，保证系统处于工作状态等。
  • 幕后参与者：谁会对系统产生的结果感兴趣。
• 识别用例
  从分析系统的参与者开始，考虑每一个参与者是如何使用系统的。
• 识别用例间的关系
• 建立 Actor 和 Use Cases 之间的关联

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

• 对于利益相关人：
  • 可以直观看到系统的结果和用户的功能体验，保证系统按照用户的需求进行设计。
  • 用例能够根据需要对复杂程度和形式化程序进行增减调节，即能够响应用户（利益相关人)提出的需求，而用例图则使得这种调节更加便利，可以通过修改图形间的关系实现。
• 对于开发者来说：
  • 用例图是设计者设计过程的结论与参考，设计者与开发者之间的交流工具，开发者开发过程的蓝图。
  • 用例图使得开发者能够更明确地获得需求，更好地理解需求。
  • 用例图可以指导开发和测试，同时可以在整个过程中对其他工作流起到指导作用。

---

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

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

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

2.2 回答下列问题

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

因为相似系统面对的参与者和用例是相似的，用例之间的关系也是相似的，用户预期的功能都是相似的。即使是不同的同类系统也具有一致的基本功能以及带有自己特色的扩展功能。所以体现在用例图上也是相似的。

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

针对不同时代，我们可以从技术入手，实现过去时代无法实现的功能，将业务过程和技术结合，创新表现形式，此外，还可以从新技术入手，增加应用场景。比如可以根据用户之前的消费记录，推荐适合用户价位的旅馆。

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

用例图可以呈现系统现有的模块功能，给项目经理对系统直观的认识，当有新技术或新需求时，项目经理（或设计者）可以根据用例图进行拓展和补充。

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

ID	Name	Imp	Est	How to Demo
1	筛选酒店	10	8	用户根据自己的要求对酒店进行筛选
2	预定酒店	8	7	筛选好了酒店以后用户可以对该酒店的其他信息进行查看和选择
3	提交订单	9	7	根据已选情况下订单，订单信息应同步到用户和旅馆双方
4	订单管理	7	5	允许用户查看并操作自己的订单
5	支付订单	9	6	使用支付平台进行支付

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

用例	事务	计算	原因	UC权重
筛选酒店	7	7		一般
预定酒店	5	5		简单
提交订单	6	6		一般
订单管理	6	6		一般
支付订单	3	3		简单