4.1 需求
软件开发生命周期包含需求、设计、编码和测试四个过程阶段，其中需求过程是第一个也是最重要的一个阶段。
软件需求包括三个不同的层次：
- 业务需求：说明了提供给客户和产品开发商的新系统的利益，反映了组织机构或客户对系统、产品高层次的目标要求，它们将在项目视图与范围文档中予以说明。
- 用户需求描述了用户使用系统必须要完成的任务，这在使用实例文档或方案脚本说明中予以说明。
- 功能需求和非功能需求定义了开发人员必须实现的软件功能，从而使得用户能顺利完成他们的任务，满足业务需求。
软件需求过程包括5个主要活动：需求获取、需求分析和确认、编写需求规格说明书、需求管理 。
4.2 用例分析
从本质上讲，一个用例是用户与计算机之间为达到某个目的而进行的一次典型交互作用。与典型用户进行交谈是找出用例简单而有效的途径。 整个系统的需求是由一系列用例的集合组成的。这是一个由个体到一般，即由分析到综合的过程。 需要注意的是用例能捕获功能性需求，它描述的是关于系统将做什么。
用例模型四部分：系统边界、参与者、用例、关系。
典型用例建模方法如下：
- 找出系统边界；
- 找出参与者；
- 找出用例；
- 说明用例；
-
4.3 用户目标和系统交互功能
在实际工作中，首先应将注意力集中在用户目标上，然后提供用例来满足这些目标。
- 到细化阶段末期，再对每个已经识别的用户目标，定义一系列规定系统交互功能的用例。
- 用户目标是目的，因此首要任务是开发满足用户目标的用例。
系统交互功能是达到目的的手段，也是不容忽视的，否则开发出的系统不能达到预定的目的。
4.4 用例图
由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的视图称为用例图。其中用例和参与者之间的对应关系又叫做通信关联（Communication Association)，它表示了参与者使用了系统中的哪些用例。
作用：用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化地了解系统的功能。借助于用例图，系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。
- 用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。
- 用例方法是完全从外部来定义系统功能的，它和设计完全分离开来。不用关心系统内部是如何完成各种功能的，系统就好像一个黑箱子。
- 用例图可视化地描述了系统外部的使用者（抽象为参与者）和使用者使用系统时，系统为这些使用者提供的一系列服务（抽象为用例），并清晰地描述了参与者和参与者之间的泛化，关系、用例和用例之间的包含关系（泛化关系、扩展关系）以及用例和参与者之间的关联关系，所以从用例图中可以得到对于被定义系统的一个总体印象。
用例关系：包含关系、扩展关系、泛化关系 ，活动者与活动者之间也存在泛化关系。
系统边界：
- 所谓系统边界是指系统与系统之间的界限。通常所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。系统同时又是相对的，一个系统本身可以是另一个更大系统的组成部分，因此系统与系统之间需要使用系统边界进行区分，把系统边界以外的同系统相关联的其他部分称之为系统环境。
用例图中的系统边界用来表示正在建模系统的边界。边界内表示系统的组成部分，边界外表示系统外部。
4.4.1 参与者(活动者)
参与者(Actor)是指存在于系统外部并直接与系统进行交互的人 、系统、子系统或类的外部实体的抽象。 每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。 需要注意的是，参与者虽然可以代表人或事物，但参与者不是指人或事物本身，而是表示人或事物当时所扮演的角色。
一个用例的参与者可以划分为发起参与者和参加参与者。 一个用例只有一个发起参与者，但可以有若干个参加参与者。在用例中标出发起参与者是一个有效的做法。
参与者还可以划分为主要参与者和次要参与者： 主要参与者指的是执行系统主要功能的参与者； 次要参与者指的是使用系统次要功能的参与者。 标出主要参与者有利于找出系统的核心功能，往往也是用户最关心的功能。
由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。 泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。 泛化关系表示的是参与者之间的一般／特殊关系，在UML图中使用带空心三角箭头的实线表示泛化关系。4.4.2 用例
用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例定义一组用例实例，用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景 ； 用例应该给参与者带来可见的价值，这点十分关键 。
用例特点：用例总是由活动者开始。用例总是从活动者的角度来编写的。
用例命名：动名词4.4.3 项目词汇表
4.4.4 事件流
要建立实际的系统，还需要更多的细节，这些细节写在事件流文档中。事件流的目的是在建档时说明用例的逻辑流程。在这个文档中，详细描述系统用户的工作和系统本身的工作。事件流独立于实现方法，它通常包括：简要说明、前提条件、主事件流、其他事件流、事后条件。4.4.5 用例规约
用例图只是在总体上大致描述了系统所提供的各种服务，让用户对系统有一个总体的认识。但对于每一个用例还需要有详细的描述信息，以便让其他人对于整个系统有一个更加详细地了解，这这些信息包含在用例规约之中。 而用例模型指的也不仅仅是用例图，而是由用例图和每一个用例的详细描述——用例规约所组成的。
每一个用例的用例规约都应该包含以下内容：简要说明：对用例作用和目的的简要描述。
- 事件流：事件流包括基本流和备选流，基本流描述的是用例的基本流程，是指用例“正常”运行时的场景；备选流描述的是用例执行过程中可能发生的异常和偶尔发生的情况。基本流和备选流组合起来应该能够覆盖一个用例所有可能发生的场景。
- 用例场景：同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，用例场景就是用例的实例，用例场景包括成功场景和失败场景。在用例规约中，由基本流和备选流的组合来对场景进行描述。在描述用例的时候要注意覆盖所有的用例场景，否则就有可能遗漏某些需求。此外场景还能帮助测试人员进行测试，帮助开发人员检查是否完成所有的需求。
- 特殊需求：特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等，例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。设计约束可以包括开发工具、操作系统及环境、兼容性等。
- 前置条件：执行用例之前系统必须所处的状态，例如前置条件是要求用户有访问权限或是要求某个用例必须已经执行完。
后置条件：用例执行完毕后系统可能处于的一组状态，要求在某个用例执行完后，必须执行另一个用例。
4.5 用例图内元素的关系
活动者和活动者之间可以存在泛化（Generalization）关系。 用例之间的关系：包含关系(Include)、扩展关系 (Extend) 、泛化关系 ( Generalization)。
4.5.1 泛化关系
可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系。
4.5.2 包含关系
被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现。
主要有两种情况需要用到包含关系：多个用例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。
- 某一个用例的功能过多、事件流过于复杂时也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。
包含关系的划分有两个好处： 一是被包含用例被抽取出来，基本用例得以简化； 二是可以抽象出公共事件流，实现功能代码的复用。
4.5.3 扩展关系
基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展，如果在完成某个功能的时候有时会执行另一个功能，则用扩展关系来表示。扩展关系表示为虚线箭头加“<
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使使用。
扩展关系和包含关系具有以下不同点：
- 基础用例的执行并不一定会涉及到扩展用例，扩展用例只有在满足一定条件下才会被执行。而在包含关系中，当基础用例执行后，被包含用例是一定会被执行的。
即使没有扩展用例，扩展关系中的基础用例本身也是完整的，而对于包含关系，基础用例在没有被包含用例的情况下就是不完整的存在。
4.6 如何绘制用例图（一般步骤）
确定系统边界；
- 识别参与者；
- 识别用例；
- 区分用例的优先次序；
- 书写用例文档；
- 通过关系整理用例（确定泛化、包含、扩展关系）。
4.7 用例图设计实例
若有收获，就点个赞吧
0 人点赞
