关联关系：参与者与用例之间的关系
用例图中，关联关系描述参与者与用例之间的关系，表示 参与者和用例之间的通信。
如果参与者启动了用例，箭头指向用例；如果参与者利用 了用例提供的服务，箭头指向参与者；如果二者是互动的， 则是直线。
“系统边界” 用来定义系统的界限，系统用例都置于其 中，参与者置于边界外。
储数据？如果是，如何来完成这些操作的？ 参与者是否会将外部的某些事件通知给该系统？ 系统是否会将内部的某些事件通知该参与者？
泛化关系
包含关系（Include）
一个用例（基用例，基本用例）可以包含其他用例（包含 用例）具有的行为，并把它所包含的用例行为作为自身用 例的一部分，这被称为包含关系。
用例是一个事件流的集合，当某个事件流片段在多个用例 中出现时，可以将这个事件流片段抽取出来，放在一个单 独的包含用例中，简化基用例的描述。
扩展关系（Extend）
扩展关系表示基本用例（扩展用例）的行为。
基本用例不知道扩展用例的任何细节，没有扩展用例，基 本用例是完整的。只有在特定条件下，它的行为可以被扩 展用例的行为扩展，因此扩展关系处理事件流的异常或者 可选事件。
参与者之间的关系
参与者实际上是版型化的类，因此多个参与者之间 可以具有与类之间相同的关系。用例图中，使用泛化关 系来描述多个参与者之间的公共行为。
参与者的泛化
订餐系统参与者泛化
定义 用例定义了一组用例实例，其中每个实例都是系 统执行的一系列动作，这些动作可以对参与者产生有一 定价值的可观察到的结果。
部对该功能的具体实现。 3、用例描述了用户提出的一些可见需求，对应一个具
体的用户目标，即用例的执行结果对参与者有意义。 4、用例是对系统行为的动态描述，属于动态建模部分
此外，用例不是全部的系统需求，只是功能性的需求。
发现用例 用例的来源是参与者对系统的期望，所以识别用例
最好的方法是从客户的需求入手。识别用例过程中，以 下的问题可以帮助发现用例： 参与者为什么要使用该系统？ 参与者打算在这个系统里做些什么事情？ 参与者是否会在系统中创建、修改、删除、访问、存
第4章
用例和用例图
4.1 概述 4.2 建模参与者 4.3 用例 4.4 用例间的关系 4.5 边界 4.6 事件流与用例描述 4.7 用例图建模要点 4.8 用例图建模实例
用例模型是表达系统外部事物与系统之间交互的可视化 工具。当用例模型在外部事物面前出现时，它捕获到系 统、子系统或类的行为，将 系统功能划分成对系统用户 有用的需求。交互部分或功 能被表示成用例。
2、用例描述
用例描述模板
用例编号 [用例唯一标识符，通常格式为UCxx，在文档别处可以用标识符来引用该用例]
用例名称 [表明用户意图或用例的目标，一般是动词短语]
用例描述 参与者
前置条件 后置条件
[对用例目标的一个概要性的描述] [列出该用例的参与者，尤其是主要参与者] [即启动该用例所应该满足的条件。] [即该用例完成之后，将执行什么动作。]
系统实际运作中，一个实际用户可能对应系统的多个参与 者。如，一个人可以既是一个商店的售货员又是顾客
actor1
Icon形式
<<Actor>>
actor2
Label 形式
actor3
Decoration形式
寻找和确定参与者 获取用例前，首先要确定系统的参与者。询问以下
问题帮助确定参与者： 谁使用系统的主要功能？ 谁改变系统的数据？ 谁从系统获取数据？ 谁需要系统的支持以完成日程工作任务？ 谁负责支持和维护系统？ 系统需要控制哪些外部资源或硬件设备？ 系统需要和哪些外部系统交互？ 谁对系统运行结果感兴趣？
边界决定了抽象的层次。
用例描述的是一个系统做什么的信息，并不说明怎么 做。用例是对使用场景进行抽象的总结，形成一组事件流。 1、事件流
前置条件：用例执行前系统和参与者应处于做什么状态。 后置条件：用例结束后系统处于什么状态。 基本事件流：对用例中常规、预期路径的描述，是大部分
的时间所遇到的场景。 扩展事件流：对一些异常情况、选择分支进行描述。
主要流程 (基本事件流)
步骤 1 2
活动 [在这里写出触发事件到目标完成以及清除的步骤。] ……(其中可以包含子事件流，以子事件流编号来表示)
替代流程 (扩展事件流)
[表示是对1的扩展，其中应说明条件和活动] 1b ……(其中可以包含子事件流，以子事件流编号来表示)
子事件流 [对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。]
采用用例进行需求分析的特点： 1、用例由一组用例实例组成。用例实例也称为场景，
是参与者和系统之间一系列特定的活动和交互。场景是 使用系统的一个特定情节或用例的一条执行路径。
例 商场购物“付款”的用例 场景一：使用现金成功付款 场景二：银行卡付款被拒绝，付款失败。
采用用例进行需求分析的特点： 2、用例站在系统外部察看系统功能，而不考虑系统内
用例图展示了系统边界、 参与者（系统外部事物）、 用例以及它们之间的关系， 描述了参与者与系统交互的 情况以及系统的功能。
参与者（actor）：在系统外部与系统交互的人或事物， 它以某种方式参与系统内用例的执行。
位于系统（边界）之外
表示的是人或事物与系统交互时所担任扮演的角色
参与者不仅可以由人承担，还可以是其他的外部系统， 甚至是时间等。
规则与约束 [对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]
2、用例描述 常见用例描述错误：
只描述系统的行为，没有描述参与者的行为 只描述参与者的行为，没有描述系统的行为 在用例描述中就设定对用户界面的设计要求 描述过于冗长
编写用例描述应遵循以下几点：
使用简单的语法，主语明确，语义易于理解；在事件流描 述中让读者直观地了解是参与者在控制还是系统在控制；
从第三者观察的角度指出参与者的动作，以及系统的响应； 显示参与者的意图而非动作 显示过程向前推移，每一步都有前进感；
构建结构良好的用例