【转】识别用例之间的关系

关注

原创最新推荐文章于 2026-09-05 22:00:00 发布 311 阅读 AI 写同款· GEO 优化 ›

用例间的三种关系：
（1）扩展(extends)：用例B extends 用例A，表示用例B是用例A在某种特定情况下可能会出现的扩展用例。例如：老王进城办事，2小时就可以回去，在这2小时内内急时就会去上厕所。上厕所用例是进城用例的扩展，因为不上厕所老王进城办事也可完成。
（2）包含(includes)：用例A includes 用例B，表示没有了用例B，用例A本身也就不完整了。例如：还是老王进城，他从海南来北京办事，3天才能回去，那么这种情况下进城用例与上厕所用例的关系就应该是包含关系了。
（3）泛化：泛化关系指的是同一业务目的的不同技术实现。例如：老王进城，他可以坐飞机，可以坐火车，还可以走路，那么进城用例就泛化为坐飞机、坐火车和走路三个用例了，它们之间存在层级关系。
总的来看，扩展可以“冻结”基本用例以保持稳定（因为扩展用例通常是不确定的）；包含可以提供公共交互，提高“复用”；泛化是同一业务目的的不同技术实现。用例之间除了上述三种关系不再有其他关系，用例之间不能通讯。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

下面是另外一种解释，用例子来描述。

4.2 用例之间的关系

用例描述的是系统外部可见的行为，是系统为某一个或几个参与者提供的一段完整的服务。从原则上来讲，用例之间都是并列的，它们之间并不存在着包含从属关系。但是从保证用例模型的可维护性和一致性角度来看，我们可以在用例之间抽象出包含(include)、扩展(extend)和泛化 (generalization)这几种关系。这几种关系都是从现有的用例中抽取出公共的那部分信息，然后通后过不同的方法来重用这部公共信息，以减少模型维护的工作量。

4.2.1 包含(include)

包含关系是通过在关联关系上应用<<include>>构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。

包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)，如下图。

在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例"打印回执"，而原有的查询、取现、转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。

在基础用例的事件流中，我们只需要引用被包含用例即可。

查询-基本事件流

1. 用户插入信用卡

2. 输入密码

3. 选择查询

4. 查看帐号余额

5. 包含用例"打印回执"

6. 退出系统，取回信用卡

在这个例子中，多个用例需要用到同一段行为，我们可以把这段共同的行为单独抽象成为一个用例，然后让其他的用例来包含这一用例。从而避免在多个用例中重复性地描述同一段行为，也可以防止该段行为在多个用例中的描述出现不一致性。当需要修改这段公共的需求时，我们也只需要修改一个用例，避免同时修改多个用例而产生的不一致性和重复性工作。

有时当某一个用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。

4.2.2 扩展(extend)

扩展（extend）关系如下图所示，基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。