本文介绍了UML用例图的概念，适用于描述系统的功能，而非异常行为或步骤序列。UML用例图包含角色、系统、用例和它们之间的关系。主要元素包括演员、系统、用例及它们的交互线。应当避免用用例图表示异常行为，而使用序列图或流程图。此外，文章还讨论了如何识别演员、系统中的内容以及何时使用箭头和扩展箭头等。
什么是UML用例图（UCD），何时应该使用它？
UML用例图可用于以水平方式描述系统的功能。也就是说，UCD不仅仅代表系统各个功能的细节，还可以用来显示其所有可用功能。但值得注意的是，UCD与序列图或流程图根本不同，因为它们不会尝试表示系统操作和子操作应执行的次序或次数。本常见问题解答中有许多图形示例; 你可能想看看它们以熟悉它们的外观。
UCD只有4个主要元素：您描述的系统与之交互的角色，系统本身，用例或系统知道如何执行的服务，以及表示这些元素之间关系的线。
您应该使用UCD从上到下的角度来表示系统的功能（也就是说，系统的功能很明显，但所有描述都处于非常高的水平。稍后可以将更多详细信息添加到图表中阐明系统行为中的有趣点。）
示例： UCD非常适合描述可以使用数据库系统完成的所有事情的任务（所有可能使用它的人员（管理员，开发人员，数据输入）人员。）
您不应该使用UCD来表示异常行为（发生错误时）或尝试说明为完成任务必须执行的步骤序列。使用序列图显示这些设计功能。
示例： UCD不太适合描述TCP / IP网络协议，因为有许多异常情况，分支行为和条件功能（当数据包丢失或延迟时会发生什么，连接何时死亡？）
你怎么知道演员在UCD中是谁？
在Action / Response表中工作时，对actor进行操作非常简单：行为出现在“Actor's Actions”列中的实体是actor，其行为出现在“System's Response”列中的实体是系统中的组件。
如果您使用非正式叙述，序列图或场景描述，则actor通常是那些行为无法控制或更改的实体（即，不是您正在构建或描述的系统的一部分的代理。）最明显的演员候选人是系统中的人; 除非在极少数情况下，您所描述的系统实际上是一个人为过程（例如与员工应该遵循的客户打交道的具体方法），您必须与之互动的人才都是演员。如果您的系统与其他系统（数据库，由其他人维护的服务器，遗留系统）进行交互，您最好将这些视为演员，因为您不想描述他们的行为。
例： 在添加新的数据库系统来管理公司的财务时，您的系统可能必须与现有的库存管理软件进行交互。由于您没有编写此软件，不打算替换它，只使用它提供的服务，因此该系统成为一个actor是有意义的。
你怎么知道在“系统”框中输入什么？
系统框仅出现在顶层图上（请记住，典型的UML用例描述将由许多图表和子图组成），并且应包含用例椭圆，一个用于系统提供的每个 顶级服务对其演员。任何一种内部行为，你的系统可能有一个只能使用该系统的其他部分应该不会出现在系统框。考虑这些顶级服务的一种有用方法如下：如果用例表示顶级服务，那么与其交互的参与者在单个会话中仅请求您的系统服务是有意义的（无论何种意义上，“会话”在您的系统中都是可理解的。）
示例：在下图中，我们想要表示相机的用例。假设我们选择“Open Shutter”，“Flash”和“Close Shutter”作为顶级用例。当然这些都是相机所具有的行为，但没有摄影师会拿起相机，打开快门，然后放下它，对当天的摄影时间感到满意。要认识到的重要一点是，这些行为不是孤立进行的，但相当一部份更高层用的情况下，“拍照”的。（请注意，摄影师在使用相机的会话期间只拍摄一次“拍照”确实有意义。） 
我的图表中的演员有互动。我该如何代表他们？
如果系统中的actor之间存在交互，则无法在与系统相同的图表中表示这些交互。您可以做的是绘制一个单独的UCD，将其中一个演员本身视为系统，将原始系统（以及其他演员）视为此新图表上的演员。
例： 假设您想要绘制用户，Web浏览器和它所联系的服务器之间的交互图。由于图表上只能有一个系统，因此必须选择一个明显的“系统”，例如服务器。然后你可能会试图在演员之间绘制交互线，但这是一个问题，因为不清楚交互意味着什么，所以在这里展示它没有帮助。更有用的解决方案是绘制两个图表，显示所有交互，如下所示。 
我试图表示系统执行的一系列操作。我该怎么做？
使用UML用例图，你不能。UCD应该是一种自上而下的，横向的功能描述，而不是一种逐行的行为解释。在大多数情况下，尝试使用用例图表示操作序列并不是一个好主意。您应该使用序列图或传统流程图。（可以用UCD表示简单的分支条件，如下所述，但是你应该谨慎使用这种技术，因为它可以使图表不可读。）
UML用例图与传统流程图有何不同？
如上所述，UCD以自上而下的方式表示功能，而流程图以线性，基于时间的方式表示行为。而且，你开发它们的方式是完全不同的。
示例:(此文本引用下图。）构建UCD时，初始步骤是识别所有顶级行为。一旦你完成了这个（不是一个非常棘手的过程），你已经描述过，至少在高级方面，系统知道如何做的所有事情。然后，您可以继续你的用例分解成更用例来添加细节 使用由顶级用例组成。但是，在开发的每个阶段，您的UCD都是对系统功能的完整描述：它可能缺乏细节，但它不会缺少功能集元素。如果在项目的整个生命周期中添加或删除功能或行为，则需要进行的更改范围与系统本身的更改范围和模型的成熟度成正比。这很有用，因为这意味着当你的模型非常年轻（只绘制高级图表）时，对系统进行彻底的更改并不需要投入大量的工作。但是，在完成绘制之前，流程图无法正确描述系统，即使这样，系统中的微小更改也会导致流程图的重新修改。一般来说， 
我何时使用使用箭头？
的用途箭头（或使用边缘，因为它会在传统的图形理论联系被调用）从用例X另一种用途如果Y绘制以指示总是进行X的过程涉及进行Y至少一次（虽然它可能涉及做很多次，“至少一次”是这个符号保证的唯一关系。）这个符号可以称为聚合 运算符，因为它表示给定的用例是一个聚合（由部分组成），其组成部分是它使用的用例。如果某个用例使用其他几个，这意味着所有组件用例必须在完成聚合用例的过程中完成，尽管UCD中没有规定完成这些用例的顺序。考虑使用箭头的一种简短的记忆方式是它可以被读取X使用Y意味着“X 有一个 Y”作为其行为的一部分。
示例：假设您要将详细信息添加到下面显示的图表中，表示航空公司预订系统。首先，您将为顶级服务创建单独的图表，然后添加构成顶级服务的新用例。从“登记乘客”到“称行李”，从“登机乘客”到“指定座位”有一个使用边缘; 这表明了为了登记乘客，必须对行李进行称重并且必须分配座位。类似地，该图表示为了向系统添加预留，必须检查可用空间并且必须记录乘客的信息。您可以想象进一步打破这些用例以显示更多细节。 
我什么时候使用延伸箭头？
该扩展箭头（或延伸边缘）从用例X的使用如果Y绘制，以表明进程X是相同类型的特殊情况下的行为更普遍的过程Y.你会在情况下使用您的系统有许多用例（进程），它们都有一些共同的子任务，但是每个用例都有不同之处，这使得你无法将它们全部集中到同一个用例中。
例：假设您想在下面显示的图表中添加细节，代表航空公司预订系统。具体来说，你想要展示的是，并非飞机上的所有座位都是完全相同的（一些窗户和一些过道座位），有时乘客会表示偏好这些类型的座位而不是另一个座位。但当然，他们不能马上给予他们的偏好，因为他们想要的座位可能无法使用。因此，分配靠窗座位的过程涉及检查靠窗座位的可用性，而指定过道座位的过程涉及检查过道座位的可用性。但即使这些过程不同，它们在许多其他方面也非常相似，所以忽略它们的相似之处是没有意义的。幸好，这两个过程都扩展了一个共同的，更一般的过程（分配席位。） 
使用和延伸有什么区别？
考虑这些图元素的最佳方法可能如下：
- “X 使用 Y”表示任务“X” 具有 子任务“Y”; 也就是说，在完成任务“X”的过程中，任务“Y”将至少完成一次。
- “X extends Y”表示“X” 是与“Y”相同类型的任务，但“X”是执行“Y”的特殊，更具体的情况。也就是说，做X很像做Y，但X有一些额外的进程，超出了为了完成Y必须完成的事情。
示例：表示为了成功“办理登机手续”，您必须按照某种顺序“称重行李”和“分配座位”一些次数。但关键是，在用例被认为完成之前，用例使用的所有UC必须完成。一旦你意识到有几种类型的座位分配，你可能会试图使用下面的使用边缘绘制图表 ，但这没有意义：这个图表说，为了分配一个座位你必须分配窗户座位和乘客的过道座位。但是，不要害怕; 这种情况由extends 关系正确处理。使用extends关系（如下图所示），我们可以表达出来分配座位有两种方式：分配一个靠窗的座位并指定一个过道座位，但在为乘客分配一个座位的过程中只需要完成一个。 
我想描述的场景分为几种可能的结果，或者有一些错误条件。如何用Use Case Diagrams表示？
表示故障和分支条件通常最好使用序列图或流程图完成，但是当不清楚用例图是否合适时，存在一些灰色区域情况。根据经验：如果在用例图中表示分支操作，则必须添加更多用例椭圆，并且生成的图表混乱或混乱，请考虑使用不同的图表样式。
话虽如此，有可能用UCD表示简单的分支行为，尽管我想再次强调UCD不是流动图。这是通过认识到如果您尝试表示的用例或进程可能具有两个显着不同的结果（例如，成功和失败），那么这意味着您确实有两个不同的用例：一个用于进程成功，进程失败。当然，这两个用例的相关之处在于它们都是 原始用例的扩展，因此您将使用从其扩展的两个分支绘制原始用例。我认为这几乎是滥用延伸的含义边缘，因为它实际上并没有在这里用来表示用例的分类（这是它的目的），而是利用UCD风格的黑客流程图行为的关系的特定抽象定义。再次，谨慎使用这项技术; 它可以快速制作一个无法比拟的图表。
例：假设我们想要表示普通CD播放器的用例。当一切顺利时，CD播放器缩回CD所在的托盘，读取并开始播放。（此行为的用例如下所示。顶级图表已被省略。）不幸的是，即使托盘中没有CD，某些用户也会命令系统播放CD。因此，我们有一个失败的条件，系统必须做除了播放CD之外的其他事情（即，提示用户提供CD）。为了表示这一点，我们用一些额外的用例修改了法线图，其中存在CD已经过 验证。播放CD 的行为扩展了验证CD存在的行为，因为它是 特殊情况验证CD存在CD 的存在。验证CD存在的另一个特例是这样做并且CD 不存在，因此提示用户输入CD。我将最后一次说这种扩展的使用有点触及，但是当这种行为的数量很少时，它是表达单个用例的多个行为的优雅方式。 
扫一扫
677
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
