UML 用例图：提示和常见问题解答

UML 用例图可用于在水平道路。也就是说，不仅仅是表示细节对于系统的各个功能，可以使用 UCD 以显示其所有可用功能。这很重要不过，需要注意的是，UCD 有根本的不同从序列图或流程图中，因为它们确实如此不尝试表示顺序或编号系统 actions 和 sub actions 应该伏法。有许多图形示例在此常见问题解答中;您可能需要查看它们以熟悉你自己和他们的外表。

UCD 只有 4 个主要元素：您正在描述的系统交互的 Actor 与系统本身、用例或服务，系统知道如何执行，以及台词表示这些元素之间的关系。

您应该使用 UCD 来表示从自上而下的角度看系统的功能（也就是说，系统的功能一目了然很明显，但所有描述都处于非常高的级别。稍后可以将更多详细信息添加到图表中，以阐明系统行为中有趣的点。

例： UCD 很好适合描述所有事物的任务可以通过数据库系统完成，由所有人可能使用它的对象（管理员、开发人员、数据输入人员。

您不应使用 UCD 来表示异常行为（发生错误时）或尝试说明必须执行的步骤顺序才能完成任务。使用序列图可以展示这些设计特点。
示例：UCD 不太适合描述 TCP/IP 网络协议，因为有很多异常情况、分支行为和条件功能（数据包丢失时会发生什么情况或晚了，当连接中断时怎么办？

你怎么知道UCD里的角色是谁？

当使用 Action/Response 时表中，它很容易识别 Actor：其行为显示在 “Actor's Actions” 列是角色，以及其行为出现的实体在 “System's Response” 列中是组件在系统中。

如果您通过非正式会议叙述、序列图或场景描述、参与者通常是其行为无法控制或更改（即，不您正在构建或描述的系统的一部分。演员最明显的候选者是人类在系统中;除非在极少数情况下，当系统你正在描述的实际上是一个人工过程（例如作为与客户打交道的一种特定方法员工应该跟随）您必须互动的人 with 都将是 actors。如果您的系统与其他系统（数据库、由其他维护的服务器人，遗留系统）你最好对待这些作为演员，因为不是他们的行为您有兴趣描述。

例：添加管理公司财务的新数据库系统，您的系统可能必须与他们的现有的库存管理软件。既然你没有编写此软件，不打算替换它，并且只使用它提供的服务，这是有道理的让该系统成为一个参与者。

你怎么知道该在"System"框里填什么？

系统框仅显示在顶层图（请记住，典型的 UML 用例描述将由许多图表和子图表组成），并且应该包含用例椭圆，每个顶级一个您的系统为其参与者提供的服务。任何您的系统可能具有的内部行为仅由系统的其他部分使用未显示在系统框中。一种有用的思考方式的 API API 的 API API 的 API 是这样的：如果使用 case 表示顶级服务，那么它应该对与之交互的 Actor 请求有意义在单个会话中仅提供系统的该服务（无论从任何意义上说，“会话”是可理解的在您的系统中。

例：在图中下面我们想展示照相机。假设我们选择 “Open Shutter”， “Flash” 和 “Close Shutter” 为顶级用例。当然，这些都是行为相机有，但没有摄影师会选择打开相机，打开快门，然后放下，对他们当天的摄影感到满意。要意识到的关键是这些行为不是孤立地完成的，而是一个更高级的用例 “Take Picture”。（请注意，摄影师在会话期间仅“拍照”一次用他们的相机。

我图中的Actor 有相互作用。我如何表示它们？

如果 Actor 中，则无法表示这些交互与您的系统位于同一图表上。您可以做什么而是绘制一个单独的 UCD，将其中一个 Actor 本身作为一个系统，以及你的原始系统（与其他演员一起）作为 Actor 图。

例：假设你想要绘制用户之间的交互，则 Web 浏览器及其联系的服务器。由于您可以图上只有一个系统，您必须选择一个明显的 “系统”，例如服务器。然后，您可能会想绘制交互 lines 来执行，但这是一个问题，因为目前尚不清楚这种交互的含义，因此并非如此在这里展示它很有帮助。更有用的解决方案是绘制两个图，显示所有交互，如下。

我试图表示系统执行的一系列动作。我该怎么做呢？

使用UML用例图，您不能这样做。ucd应该是自上而下的、水平的功能描述，而不是逐条的行为描述。在大多数情况下，尝试用用例图表示操作序列并不是一个好主意。你应该使用顺序图或传统的流程图。（用UCD表示简单的分支条件是可能的，如下所述，但是您应该谨慎地使用这种技术，因为它会使图表变得不可读。）

UML用例图与传统流程图有什么不同？

如上所述，UCD 代表功能以自上而下的方式，而流程图表示行为以线性的、基于时间的方式。此外，您的开发方式它们完全不同。

示例：（此文本请参阅下图。在构建 UCD 时，第一步是确定所有顶级行为。完成此作后（不是很棘手 process）中，至少在高层次方式，您的系统知道如何做的所有事情。然后，您可以通过分解 use cases 转换为更多 use cases，这些用例由顶级用例。在开发的每个阶段，但是，您的 UCD 是系统对功能性：它可能缺乏细节，但不会缺乏 feature set 元素。如果功能或行为在项目的生命周期中添加或删除，则您需要进行的更改范围是成比例的既要考虑系统本身的更改范围，以及模型的成熟度。这很有用，因为这意味着，当您的模型非常年轻时（只有 high-level 绘制的图表）对系统进行彻底的更改不涉及扔掉很多工作。一个 flow 但是，图表并不能正确描述系统直到你画完它，即使那时很小系统更改将导致重大返工的流程图。通常，UCD 支持该过程的分析和设计比流程图好得多。

什么时候使用“使用”箭头？

使用 arrow （或使用 edge 在传统图 thoery 中被调用）是从一个用例 X 到另一个用例 Y，以指示执行 X 的过程总是至少涉及执行 Y 一次（尽管它可能涉及多次执行，“在 least once“是唯一保证的关系通过此符号。此符号可称为 aggregation 运算符，因为它表示给定的用例是其组件是它使用的用例。如果某个用例使用其他几个组件，这意味着所有组件用例必须在完成过程中完成聚合用例，尽管没有规范在 UCD 中，按照完成这些内容的顺序进行。一个考虑 Arrow 用途的简短、助记法是它可以被读取 X 使用 Y 表示“X 具有 a Y“作为其行为的一部分。

例：假设你想要向下图中添加细节，表示一个航空公司预订系统。首先，您将创建顶级服务的单独关系图，然后您将添加构成顶级的。“Check in Passenger” 有一个使用边到“称重行李”和从“办理登机手续” Passenger“改为”Assign Seat“;这表明为了为乘客办理登机手续，行李必须称重，并且必须分配一个座位。同样，图中指示为了添加预留对于系统，必须检查可用空间，并且必须记录乘客的信息。你可以想象一下，进一步分解这些用例以展示更多细节。

什么时候使用extends箭头？

extends 箭头（或 extends edge）从用例 X 绘制到用例 Y，以指示进程 X 是与更通用的进程 Y 的类型相同。您将使用这在您的系统具有许多所有 subtasks 中的用例（进程）常见，但每个都有不同之处这使得你不可能把它们都混为一谈一起集成到同一个用例中。

例：假设你想要向下图中添加细节，表示一个航空公司预订系统。具体来说，您想说明的是，并非所有的座位都上飞机完全一样（有些窗户和一些靠过道的座位），有时乘客会表达偏好这些类型的座位之一，但不是另一个。但当然，它们不能只是给出的因为他们想要的座位可能不可用。因此，分配过程靠窗的座位涉及检查可用性的窗口座位，而分配过道座位涉及检查是否有靠过道的座位。但是，即使这些过程不同，它们在许多其他方面非常相似，因此忽视它们的相似之处是没有意义的。幸运的是，UML 让我们两者兼得：我们编写了 assign 这两种类型的座位是不同的过程，但它们的相似之处在于两个进程都扩展了一个公共的更一般的流程（分配席位）。

使用和扩展的区别是什么？

这可能是最好的思考方式这些图表元素如下所示：

- “X 使用 Y”表示任务 “X” 有一个子任务 “Y”; 即在完成任务 “X” 的过程中，任务 “Y” 将至少完成一次。

- “X extends Y” 表示 “X” 是与 “Y” 类型相同的任务，但 “X” 是一个特殊的、更具体的例子执行 “Y”。也就是说，做 X 很像执行 Y，但 X 有一些额外的进程超越必须做的事情 order 完成 Y。

Example：表示为了成功“签到”，您必须 “称量行李”和“分配座位”，按某种顺序进行多次。不过，关键是是用例使用的所有 UC 都必须在该用例被视为完整。一旦您意识到有几种类型的座位分配，您可能很想使用 uses edge 的 edge 如下所示，但这没有意义：此图表明，为了分配席位，您必须同时分配靠窗座位和靠过道座位乘客。不过，不要害怕;这种情况是由 extends 关系正确处理。用 extends 关系（如下所示图），我们可以表示有两种方式分配座位：分配靠窗座位和分配一个靠过道的座位，但只需要在为乘客分配座位的过程。

我想描述的场景分为几个可能的结果，或者有一些错误条件。我如何用用例图来表示呢？

表示失败和分支条件通常最好使用 Sequence Diagram 或流程图，但是，在一些灰色地带的情况下，情况并不清楚用例图是否合适。一个经验法则：if in 表示分支作在 Use Case Diagram 中，您必须添加更多用例椭圆，并且生成的图表是 Muddy 或令人困惑，请考虑使用不同的图表样式。

话虽如此，可以表示 UCD 的简单分支行为，尽管我会想再次强调 UCD 不是流程图。这是通过意识到如果用例或进程你试图表示的可以有两个显著的不同的结果（例如成功和失败），那么这意味着你真的有两种不同的用途案例：一个流程成功，一个这个过程失败了。当然，这两个用例的区别在于它们都是原始用例，因此您将绘制原始用途 case 中，两个分支从它延伸出来。我认为这几乎是对 extends edge 的含义的滥用，因为它在这里真的没有被用来表示用例的分类法（这是它的目的），但它是而是利用特定的抽象定义与 hack 流程图类行为的关系 out UCD 风格。同样，请谨慎使用这种技术; 它很快就会使图表变得不可读。

例：假设我们想表示普通 CD 播放器的用例。当一切顺利时，CD 播放器会缩回托盘 CD 位于其上，读取它并开始播放。（此行为的用例如下所示。 brevety 省略了顶级图表。不幸的是，一些用户会命令系统即使托盘中没有 CD，也可以播放 CD。因此，我们具有故障条件，在此条件下，系统必须执行除播放 CD 以外的其他作（即 prompt CD 的用户。为了表示这一点，我们修改了普通图，其中包含一些额外的用例，其中验证 CD 的存在。播放行为 CD 扩展了验证 CD 存在，因为它是验证 CD 所在的 CD。另一个验证 CD 是否存在的特殊情况是此作已完成，并且 CD 不存在，因此用户提示输入 CD。我要最后一次说这种扩展的使用有点触手可及，但它确实如此一种优雅的方式来表达单个此类行为数量较少时使用的用例。

次浏览