用例图

标签：

很多软件项目失败最常见的原因，都集中在“项目关键干系人”之间沟通不佳或缺少沟通。当开发机构和业务提出者之间缺乏联盟时，就更加关键。业务人员可能知道他们有某个问题需要解决，但是开发组长却只收到了关于业务需求的一般描述和一些具体的需求。

UML建模语言中，“用例图”既可以让开发组织能够理解业务的目标，也可以不会很麻烦业务人员。用例图展示待建系统的上下文范围以及它提供的功能。它们描述了谁与系统交互，外部世界希望系统做些什么。

基本概念：执行者

执行者是与系统交互的实体，可以是人或其他系统。执行者位于他们使用的系统之外。用棍状小人表示。如下图所示：

当然，在考虑执行者时，考虑最多的还是思考执行者所扮演的角色。角色不同，那么他对应的表示就不同。

基本概念：用例

用例代表了执行者希望系统为他们做什么。用例在UML“用例图”中，我们用一些椭圆表示。用例不仅仅是系统可以提供的功能，从“执行者的观点”来看，用例必须是一个“完整”的活动流程，它为执行者提供了“价值”。用例是通过某部分功能来使用系统的一种具体的方式……因此，用例是相关事务的一个具体序列，执行者和系统以对话的方式来执行这些事务……从用户的观点来看，每个用例都是系统中的一个完整序列的事件。

如下图所示：

“管理花园”、“修改农作物百科书”

基本概念：用例图

将执行者与用例利用基本的关联连接起来，就构成了一张用例图。在“用例图”中，这种关联使用实线来表示。用例图中的关联表明是哪个用户发起的哪个用例。如在下图：

用例图中的关联表明哪个用户发起哪个用例。例如上图中，只有执行者Gardener才可以维护储水箱，但是所有的执行者都可以查看报告。

1、确定用例细节

确定用例提供的功能细节，或者指定完整序列的事件时，较好的办法就是使用其他

的UML模型（如活动图）和文本规格说明。在UML用例图中，用例规格说明有许多不同的形式。但大多数都包含以下信息：

用例的名称、

关于它的目的的一段简短描述

乐观流程（即一切正常，用例中发生的事件流）

一个或多个更实际的流程（即事情如果没有按照愿望发生时的流程）

2、用例规格说明示例

举例说明，如“维护保养车辆”用例的例子。

用例规格说明

用例名称：维护保养车辆”

用例目的：本用例提供了维护车辆的保养功能。本用例让执行者维护车辆的保养，维护。

乐观流程：

1、执行者检查车辆的当前状态。

2、执行者决定对车辆进行保养（清洗，更换机油……）。

3、执行者决定对车辆损坏的地方进行维护（补漆，更换零件……）。

4、保养完成、维护完成

5、执行者对下一台车辆进行维护与保养

实际流程：

条件触发对的可选流程如下：

条件1：1、水不够，不足以完成洗车的操作。

提示：提醒执行者水不够，不能达到洗车所需的水量，并显示可用的原料。提醒执行者选择终止保养或重新设置加注水量。

选择：如果选择终止保养，执行“乐观流程”的第5步。

   如果选择重新设置加注水量，完成加水后，执行“乐观流程”的第2步。

条件2：……

当然其他有用的信息也可以被加入到规格说明中，但是要表述清楚，如进入条件（在执行这个用例之前什么条件必须为真）、退出条件（在执行这个用例之后什么条件必须为真）、限制条件、假定等。

例外，就是用例规格说明不应该太长……它应该只有几页。如果规格说明非常长，要么就是你用例做的事太多，要么就是你设计的用例实际上是多个用例，一切根据自己的具体情况去做。

高级概念：《include》和《extend》关系

有两种主要用于组织用例模型的关系……《include》和《extend》：

1、《include》关系

例如，这张图表明，Update Crop Encyclopedia用例包含了View Reports用例。这意味着在执行Update Crop Encyclopedia时，View Reports必须被执行。如果没有View Reports,  Update Crop Encyclopedia就不能被看作是完整的。

当一个被包含的用例执行的时候，它在用例规格说明中就体现为一个包含点。包含点指明了在外层用例的什么位置执行被包含的用例。

2、《extend》关系

《extend》关系，在用例图中，一般表示某些活动可以作为用例的一部分执行，但是并不一定要运行它，用例也能成功的这种情况。如上图中，当执行者Gardener执行Manage Garden用例时，他可能想看下某些报告，那么他就会执行View Reports用例。但是在执行Manage Garden时，View Reports并不是必需的，Manage Garden本身就是完整的。所以我们《extend》表明View Reports用例扩展了Manage Garden用例。

当一个扩展的用例被执行时，它在用例规格说明中就体现为一个扩展点。扩展点指明了在外层用例的什么位置执行扩展的用例。

当不知道在用例中到底需要采用哪个关系时，可以借用下面的表格来区分：

高级概念：泛化

泛化这个概念除了可以在类图中体现以外，也可以在用例中来进行展示，用例也可以有一些共同的行为，其他用例（子用例）可以通过添加步骤或精华其他方面来修改这些共同的行为。如：下图中的购买门票的用例

Purchase Ticket包含了购买任何门票所需的基本步骤，而子用例针对具体的门票的种类对Purchase Ticket进行了特化。

用例图

标签：

原文地址：http://blog.csdn.net/pu_xubo565599455/article/details/51191898