软件系统分析与设计 | 用例模型

一、用例相关概念

1、什么是用例/h3>

use case is a collection of related success and failure scenarios that describe an actor using a system to support a goal.

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

2、用例和场景的关系么是主场景或 happy path/h3>

• 用例(use case)和场景(scenario)的关系：用例表示一组场景(a collection of scenarios)，场景属于用例的实例。
• 主场景(the primary scenario)或happy path：用例从触发事件开始，一步一步执行，最终满足用例利益的步骤集合；应该包含以下信息：
  • 两个执行者之间的交互。如，用户提交了订单。
  • 为保证主成功场景得以继续的确认。如，系统确认用户密码。
  • 主成功场景推进过程中的内部变化。如，系统扣除用户账户余额。

3、用例有哪些形式/h3>

• Brief(high level): 一段简单的概要，通常是主要成功案例。主要在早期需求分析中，快速了解主题和范围，创作可能只需几分钟
• Casual(简便格式): 非正式格式，涵盖各种场景的多个段落，主要在早期需求分析中使用
• Fully: 所有的步骤和变化都写得很详细，并有支持部分，如前提条件和成功保证。主要在确定了许多用例并以简短格式编写后，详细编写了一些具有架构意义和高价值的用例

4、对于复杂业务，为什么编制完整用例非常难/h3>

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

5、什么是用例图/h3>

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

6、用例图的基本符 与元素/h3>

• 用例之间的关系
• 扇贝单词
  

A、为什么相似系统的用例图是相似的/p>

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

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

不同时代、不同地区用户习惯、需求法规以及其他 会环境的不同，使得技术和业务需求方面有所差距，这些差异会体现在用例图中，可以用不同的色彩标注他们来突出创新之处。

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

用例图中的每个用例之间的关系都是明确的，我们可以对其中相对独立，即入度出度都比较小的用例进行创新，这样对系统整体的影响就不会很大。创新的角度可以是删去这个用例或者是给这个用例添加新功能。

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

E、根据任务4，参考使用用例点估算软件成本，给出项目用例点的估算。
根据用户点方法，对用例分配权重的标准是：

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