用例视图 之 用例之间的关系

本身在画用例视图的时候，总要在用例间的关系问题上费不少的时间，虽然用例之间的关系无外乎泛化、包含和扩展三种，但仍是常常会在用例间关系属于哪种的问题上产生迷惑，索性集中分析整理一下，之后再迷惑的时候，找出来看看。

 

首先从原则上来说，用例相互之间都是独立、并列的，它们之间并不存在着从属的关系。然而，之因此要将它们之间定义泛化、包含和扩展等关系，主要是为了体现用例之间的业务联系。这三种关系的一个共性就是：都是从现有的用例中抽取出公共的那部分信息，做为一个单独的用例，而后经过不一样的方法来复用这个公共的用例，以减小模型维护的工做量。

一、这三种关系是如何来区分的呢？通常来说，能够用is a 和 has a来判断使用那种关系，泛化和扩展表示的是用例之间的is a 关系，包含关系表示的是用例之间的has a 关系；而扩展关系和泛化关系相比又多了扩展点的概念，就是说，一个扩展用例之可以在基本用例的扩展点上进行扩展。

二、分别就这三种关系进行分析说明：

（1）泛化关系：

一个用例能够被特别列举为一个或多个子用例，这被称为用例泛化。用例间的泛化关系和类间的泛化关系相似，即在用例泛化中，子用例表示父用例的特殊形式，子用例从父用例处继承行为和属性，还能够添加行为或覆盖，改变已继承行为。

当系统中具备一个或多个用例是较通常用例的特化时，就使用用例泛化。

举例：

理解：基本用例是通常的抽象的，而泛化用例则是特殊的具体的；同时，泛化用例在抽象的概念上和基本用例相同。如上面例子：基本用例Search Person，泛化用例Search Teacher和Search Student，Search Person （找人）是一个通常的抽象的概念，而Search Teacher （找老师）和 Search Student（找学生）相对而言就是特殊的具体的概念了，将（找人）具体化特殊化了。然而就（找老师）和（找学生）这两个泛化用例的抽象的概念上来说仍是“找人”，也就是说一我的在找老师或者找学生的时候，也能够说他在找人，由于老师和学生都是人。

  （2）包含关系：

使用包含 用例来封装一组跨越多个用例的类似动做（行为片段），以便多个基本 用例复用。基本用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基本用例的事件流中。基本用例能够依赖包含用例执行的结果，可是双方都不能访问对方的属性。基本用例执行时，必定要执行包含用例。

举例：

理解：若是单独使用一个“注册用户管理”用例来描述业务的话，不可以很好的描述注册用户管理都有哪些内容，计算机没法将注册用户管理员的业务模拟出来，因此在系统用例阶段，用“注册用户管理”include“增删改查用户信息”来表示这个实现关系，有利于详细分析模拟“注册用户管理”这一行为的细节，不至于混淆；同时，若是有多个相似于“注册用户管理”这样的用例，可让“增长用户信息”和“增长XX信息”等等用例来继承一个抽象出来的“增长数据”用例。

如图：

  （3）扩展关系：

将基用例中一段相对独立而且可选的动做，用扩展用例加以封装，再让它从基用例中声明的扩展点上进行扩展，从而使基用例行为更简练和目标更集中。基本用例没必要知道扩展用例的任何细节，仅为其提供扩展点，事实上基本用例没有扩展也是完整的，这一点和包含关系不一样，一个用例能够有多个扩展点，每一个扩展点也能够出现屡次，一般状况下基本用例不会涉及到扩展用例的行为，只有在特定的条件发生时，扩展用例的行为才被执行，也就是说基本用例执行时，扩展用例可执行也能够不执行。

举例：

理解：借了图书馆的书，到期了还书，这很正常，“还书”用例就能够描述，可是若是逾期还书呢？在逾期的状况下就要交纳罚金，虽然也是“还书”，但是它多了一个“交纳罚金”固然若是你在期限以内还书，交纳罚金就不会发生。在这里扩展点就是：逾期还书。

 

终于完成了，疏漏之处网友监督指正，你们共同进步。