UML从需求到实现----用例、UML用例图中包含、扩展和泛化三种关系详解

转载自： http://blog.csdn.net/lsh6688/article/details/6236291

 

关于用例图的概念相信不用我去说了 .能看到这篇文章的都是知道用例图概念的人.

UML 中最重要的是什么图呢 ?毫无疑问应该是用例图 ,用例是后期时序图 和实际开发的重要依据.

说明一下用例图是怎么产生的.了解他的产生对我们了解它本身有很大帮助,

首先用例产生在需求分析阶段 ,这这个阶段系统分析人员对用户对系统要求的理解 .也就是用户的愿望的描述.有时候我们习惯把用例说成系统的功能.
但是.用例一定是系统的功能.但是功能不一定是系统的用例

比如系统要求我在断电的时候要把数据保存起来.但是这个能写在用例里面吗?当然不能

这只不过是系统的一个限制.不能算是一个完整的愿望.

接着说明一下用例的特点.然后根据特点来说明用例的建立过程

用例特点:

一:用例是相对独立完整的.一个用例不需要其他用例来完成和它进行交互.也就是说.我在实现这个用例的过程中.不能出现做完用例1,然后才能做用例2.

比如

我们去买菜

显然第一个不是一个用例.给钱只是买菜的一部分.不能单独成为一个用例

二:用例的执行结果对于参与者来说是可见的.有意义的.

这句话的意思就是说.一个用例必须有一个确定的结果.这个结果是有意思的.比如到银行取钱.

显然第一个不是一个用例.因为输入密码以后到底是什么结果.密码正确?还是错误.这些结果都是未知的.一个结果未知的过程.不能算做一个用例.

三:一个用例必须是由一个参与者发起.不存在没有角色的用例.用例也不该自动启动.

这个也是我们经常遇到的一个问题.

解决这个问题的时候.我们要首先确定用例边界.我们在那个范围之外去寻找用例.不同的范围会产生不同的用例.

比如我们要以系统为边界去确定用例.那么角色就应该是系统之外的东西.不应该是系统.

比如:

显然ATM不是一个角色,我们设计的用例也不应该包括ATM出钱这个用例.ATM是我们系统的一个部分.他最终出现在部署图上.就像是我们的一台PC 一样.不在边界之外.

四:用例一定是动宾短语

比如:喝水 取钱 买菜 做饭等

因为这样才能构成一个完整的事件.角色是主语.动宾短语是动作和动作的受体.这样主,谓,宾都有了,才是一个完整的事件.

五:一个用例是一个需求单元,分析单元,设计单元,开发单元,测试单元.

设计完一个用例.我们接下来的工作都要以单个用例为主线去开发.测试.这样就印证了开篇的那句话.用例对于开发来说是相当重要的.

那么用例是如何确定的呢?

一:确定系统的边界

二:确定业务主角.这个是最重要的,也是常常困扰我们的地方.业务主角是与系统交互的人和事物.

让我们常常困惑的是.有些业务人员.他明明参加了业务.但是他却是被动参加的.不好说明他有什么目的.但是又确实是在系统中做了事情.

这样的业务人员.我们把它叫做业务工人 .不是业务主角.

区别他的办法就是回答下面三个问题.

1:他是主动向系统发出请求的吗?

2:他是完整的业务目标吗?

3:系统为他服务吗?

三:参与者到角色的过度.

参与者是一个具体的概念.角色是一个抽象的概念.从众多的参与者当中,抽象出相同的一部分.就形成一个角色.

比如:教授,副教授都可以讲课 ,把它们抽象出来.做出老师讲课.

 

 

最后.检查是否找到了所有的参与者.

通过下面这些问题来做出测试:

1:是否对系统中的所有角色都进行了建模和说明

2:每个参与者是否至少涉及到一个用例

3:你是否列出至少两名可以作为特定参与者的人员

4:是否有两个参与者担任与用力相关的角色

5:参与者是否有直观的描述性名称

最后将参与者和他们的愿望结合起来.就形成了用例图.记得最后形成的一定是一个完整的事情.由参与者做主语.用例做谓语和宾语.

PS:

用例图只是一些符号.抽象程度较高.一百个人看了也不一定结果相同.所以用例要附加相关的用例文档加以说明.

用例形成映射基本就是用户界面(UI).这一点大家要清楚.不要做了用例.再回头从新找界面.

 

 

UML用例图中包含、扩展和泛化三种关系详解

本文转自：http://www.cnblogs.com/shinings/archive/2009/04/21/1440765.html

 

UML用例图中包含(include)、扩展(extend)和泛化(generalization）三种关系详解

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

1、包含(include)

 

    包含关系：使用包含（Inclusion）用例来封装一组跨越多个用例的相似动作（行为片断），以便多个基（Base）用例复用。基用例控制与包含用例的 关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果，但是双方都不能访问对方的属性。

   包含关系对典型的应用就是复用，也就是定义中说的情景。但是有时当某用例的事件流过于复杂时，为了简化用例的描述，我们也可以把某一段事件流抽象成为一个被包含的用例；相反，用例划分太细时，也可以抽象出一个基用例，来包含这些细颗粒的用例。这种情况类似于在过程设计语言中，将程序的某一段算法封装成一个子过程，然后再从主程序中调用这一子过程。　

   例如：业务中，总是存在着维护某某信息的功能，如果将它作为一个用例，那新建、编辑以及修改都要在用例详述中描述，过于复杂；如果分成新建用例、编辑用例和删除用例，则划分太细。这时包含关系可以用来理清关系。

 

对于一个扩展用例，可以在基用例上有几个扩展点。   

例如，系统中允许用户对查询的结果进行导出、打印。对于查询而言，能不能导出、打印查询都是一样的，导出、打印是不可见的。导入、打印和查询相对独立，而且为查询添加了新行为。因此可以采用扩展关系来描述：

4、泛化(generalization)

 

泛化关系：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例如，业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以做成泛化关系表示：

上面是我参考的一篇文章，觉得将三种关系的区别讲得很清晰，在此基础上结合自己的系统，对项目(在线购物系统)的用例做了整体的描绘。

    *****************************************************************

    (1)系统整体用例图

 

 

 

 

 

 

按照先整体用例，后子系统用例来进行描绘的，欢迎大家提出好的建议!

转：UML中扩展和泛化的区别

         泛化表示类似于OO术语“继承”或“多态”。UML中的Use Case泛化过程是将不同Use Case之间的可合并部分抽象成独立的父Use Case，并将不可合并部分单独成各自的子Use Case；包含以及扩展过程与泛化过程类似，但三者对用例关系的优化侧重点是不同的。如下：
          ●泛化侧重表示子用例间的互斥性；
          ●包含侧重表示被包含用例对Actor提供服务的间接性；
          ●扩展侧重表示扩展用例的触发不定性；详述如下：

        既然用例是系统提供服务的UML表述，那么服务这个过程在所有用例场景中是必然发生的，但发生按照发生条件可分为如下两种情况：
         ⒈无条件发生：肯定发生的；
         ⒉有条件发生：未必发生，发生与否取决于系统状态；

         因此，针对用例的三种关系结合系统状态考虑，泛化与包含用例属于无条件发生的用例，而扩展属于有条件发生的用例。进一步，用例的存在是为Actor提供服 务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。

         另外一点需要提及的是：泛化中的子用例和扩展中的扩展用例均可以作为基本用例事件的备选择流而存在。

2、扩展(extend)

扩展关系：将基用例中一段相对独立并且可选的动作，用扩展（Extension）用例加以封装，再让它从基用例中声明的扩展点（Extension Point）上进行扩展，从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性，因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。