【UML】——用例图关系讲解

版权声明:本文为博主原创文章,未经博主允许不得转载。 如有不对,还请指教。 https://blog.csdn.net/z15732621736/article/details/48917463

 一.用例图简介

            用例图是需求分析的产物,描述了系统的参与者与系统进行交互的功能,是参与者所能观察和使用到的系统功能的模型图。它的主要目的就是帮助开发团队以一种可视化的方式理解系统的功能需求,包括基于基本流程的“角色”关系以及系统各个功能之间的关系。它通过用例(Use Case)来捕获系统的需求,再结合参与者(Actor)进行系统功能需求的分析和设计。

为了减少模型维护的工作量、保证用例模型的可维护性和一致性,可以在用例之间抽象出包含(Include)、扩展(Extend)和泛化(Generalization)这几种关系, 接下来以 用例图 来进行讲解。

二.关系讲解

1、包含(include)

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

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

        简单来说包含关系就是指用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为作为自身行为的一部分。    

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

                

2、扩展(extend)

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

         简单来说就是扩展关系就是指在一定条件下,把新的行为加入到已有的用例中,其中获得的新用例称为扩展用例(Extension),原有的用例称为基础用例(Base)。

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

          

3、泛化(generalization)

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

简单来说泛化关系是指一个父用例可以被特化形成多个子用例,而父用例和子用例之间的关系就是泛化关系。

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

        

猜你喜欢

转载自blog.csdn.net/z15732621736/article/details/48917463