6. 退出系统，取回信用卡
在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。
有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。
4.2.2 扩展(extend)
扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。
例如对于电话业务，可以在基本通话(Call)业务上扩展出一些增值业务如：呼叫等待(Call Waiting)和呼叫转移(Call Transfer)。我们可以用扩展关系将这些业务的用例模型描述如下。
在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在一定的条件下（如应答方正忙或应答方无应答）才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。
值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。但是基本通话用例已经是一个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把一些可选的操作独立封装在另外的用例中。
4.2.3 泛化(generalization)
当多个用例共同拥有一种类似的结构和行为的时候，我们可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式，子用例继承了父用例所有的结构、行为和关系。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。
以下是一个用例泛化关系的例子，执行交易是一种交易抽象，执行房产交易和执行证券交易都是一种特殊的交易形式。
用例泛化关系中的事件流示例如下：
用例模型建成之后，我们可以对用例模型进行检视，看是否可以进一步简化用例模型、提高重用程度、增加模型的可维护性。主要可以从以下检查点(checkpoints)入手: 用例之间是否相互独立？如果两个用例总是以同样的顺序被激活，可能需要将它们合并为一个用例。 多个用例之间是否有非常相似的行为或事件流？如果有，可以考虑将它们合并为一个用例。 用例事件流的一部分是否已被构建为另一个用例？如果是，可以让该用例包含(include)另一用例。 是否应该将一个用例的事件流插入另一个用例的事件流中？如果是，利用与另一个用例的扩展关系(extend)来建立此模型。5. 管理用例模型复杂度
一般小型的系统，其用例模型中包含的参与者和用例不会太多，一个用例图就可以容纳所有的参与者，所有的参与者和用例也可以并存于同一个层次结构中。对于较复杂的大中型系统，用例模型中的参与者和用例会大大增加，我们需要一些方法来有效地管理由于规模上升而造成的复杂度。
5.1 用例包
包(Package)是UML中最常用的管理模型复杂度的机制，包也是UML中语义最简单的一种模型元素，它就是一种容器，在包中可以容纳其他任意的模型元素（包括其他的包）。在用例模型中，我们可以用构造型(Sterotype)<>来扩展标准UML包的语义，这种新的包叫作用例包(Use Case Package)，用于分类管理用例模型中的模型元素。
我们可以根据参与者和用例的特性来对它们进行分类，分别置于不同的用例包管理之下。例如对于一个大型的企业管理信息系统，我们可以根据参与者和用例的内容将它们分别归于人力资源、财务、采购、销售、客务服务这些用例包之下。这样我们将整个用例模型划分成为两个层次，在第一层次我们看到的是系统功能总共分为五部分，在第二层次我们可以分别看到每一用例包内部的参与者和用例。
个用例模型需要有多少个用例包取决你想怎么样来管理用例模型的复杂度（包括参与者和用例的个数，以及它们之间的相互关系）。UML中的包其实就类似于文件系统中的目录，文件数量少的时候不需要额外的目录，文件数量一多就需要有多个目录来分类管理，同样一组文件不同的人会创建不同的目录结构来进行管理，关键是要保证在目录结构下每一个文件都要易于访问。同样的道理存在于用例建模之中，如何创建用例包以及用例包的个数取决于不同的系统和系统分析员，但要保证整个用例模型易于理解。
5.2 用例的粒度
我的系统需要有多少个用例？这是很多人在用例建模时会产生的疑惑。描述同一个系统，不同的人会产生不同的用例模型。例如对于各种系统中常见的"维护用户"用例，它里面包含了添加用户、修改用户信息、删除用户等操作，这些操作在该用例的事件流可以表述成为基本流的子事件流(subflow)。
维护用户-基本事件流
该基本流由三个子事件流构成：
(1) 添加用户子事件流
…
(2) 修改用户 子事件流
…
(3) 删除用户子事件流
…
但是你也可以根据该用例中的具体操作把它抽象成为三个用例，它所表示的系统需求和单个用例的模型是完全一样的。
应该如何确定用例的粒度呢？在一次技术研讨会上，有人问起Ivar Jacoboson博士，一个系统需要有多少个用例？大师的回答是20个，当然他的意思是最好将用例模型的规模控制在几十个用例左右，这样比较容易来管理用例模型的复杂度。在用例个数大致确定的条件下，我们就很容易来确定用例粒度的大小。对于较复杂的系统，我们需要控制用例模型一级的复杂度，所以可以将复杂度适当地移往每一个用例的内部，也就是让一个用例包含较多的需求信息量。对于比较简单的系统，我们则可以将复杂度适度地曝露在模型一级，也就是我们可以将较复杂的用例分解成为多个用例。
用例的粒度不但决定了用例模型级的复杂度，而且也决定了每一个用例内部的复杂度。我们应该根据每个系统的具体情况，因时因宜地来把握各个层次的复杂度，在尽可能保证整个用例模型的易理解性前提下决定用例的大小和数目。
5.3 用例图
用例图的主要作用是描述参与者和用例之间的关系，简单的系统中只需要有一个用例图就可以把所有的关系都描述清楚。复杂的系统中可以有多个用例图，例如每个用例包都可以有一个独立的用例图来描述该用例包中所有的参与者和用例的关系。
在一个用例模型中，如果参与者和用例之间存在着多对多的关系，并且他们之间的关系比较复杂，如果在同一个用例图中表述所有的参与者和用例就显得不够清晰，这时我们可创建多个用例图来分别表示各种关系。
如果想要强调某一个参与者和多个用例的关系，你就可以以该参与者为中心，用一个用例图表述出该参与者和多个用例之间的关系。在这个用例图中，我们强调的是该参与者会使用系统所提供的哪些服务。
如果想要强调某一个用例和多个参与者之间的关系，你就可以以该用例为中心，用一个用例图表述出该用例和多个参与者之间的关系。在这个用例图中，我们强调的是该用例会涉及到哪些参与者，或者说该用例所表示的系统服务有哪些使用者。
总之在用例建模过程中，你可以根据自己的需要创建任意多个用例图，用不同的用例来强调参与者和用例之间不同的关系。但是最重要的是要考虑整个用例模型的可理解性，如果可以用一个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。
文章来源于领测软件测试网 https://www.ltesting.net/
