用例图中的关系(一)

  一、用例图概述

用例图,是一种客户与开发者之间可以沟通、理解的表现形式。可以认为用例图是开发者与客户之间的可视化契约。我认为最主要的一点就是,在这个用例模型中,一直是以用户的角度为主的,做为开发人员也要时刻站在用户的角度来看待整个系统。

从原则上来讲,用例之间都是独立、并列的,它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系,提高可维护性和一致性,用例之间可以抽象出包含(include)、扩展(extend)和泛(generalization)几种关系。

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


 二、用例图中的四个基本组件

          用例图包括:参与者或角色(actor)、用例(use case)、关系、系统。

         1、 参与者:是系统外的一个实体,它以某种方式参与用例我执行过程。参与者通过向系统输入或请求系统输入某些事件来触发系统的执行,所以参与者可以是人,可以是事物,可以是时间、气压等环境因素或者其他系统等。它在系统之外,与系统直接交互。用一个群体概念给参与者命名,反映该参与者的身份与行为(如客户、管理员等)。

         2、 用例:用例代表系统的某项完整的功能,是动作步骤的集合。系统的功能是通过参与者使用用例来实现的。在这里,我们把用例看做是一个“黑盒”,只反映的是系统的一项功能,不涉及实现细节。

                           用例的命名:用例是从用户的角度来描述系统的功能,也就是从参与者的角度出发进行命名(如,使用“登录”,而不用“身份验证“)。还有,用例最好使用行业专业术语。

           3、关系:除了参与者与用例之间的关联关系外,还可以定义参与者之间的泛化关系,用例之间的包含、泛化与扩展关系。应用这些关系的目的是从系统中抽取出公共行为及其变体。

         4、 系统:系统指一个软件系统、一项业务、一个商务活动、一台机器等等。系统的功能通过用例来表现,换句话说,就是所有的用例构成了整个系统。从这个角度来说,用例(use case)也可以称为系统的子功能。系统用矩形表示,也可以省略。


 三、用例图中的关系

        参与者之间的泛化关系

         例如,一个网上订购系统,可以有网上客户、电话客户、直接客户等。可以看出,他们有共同的行为特征,这就是可以用到面向对象的抽象,抽象出更为一般的化的参与者——客户。通过泛化来描述多个参与者之间的共同行为,不同的参与者以独特的方式来使用系统。


    用例与用例之间的关系

1、泛化关系

用例与用例之间也存在着泛化关系,通常用于表示同一业务目的(父用例)的不同技术实现(各个子用例)。

例如某购物系统为用户提供不同的支付方式,那么”支付”这个复杂用例就可以用泛化关系表示。


2、包含关系

在包含关系中,基本用例吸收了被包含用例的行为,如果没有后者它将是不完整的。

包含关系的划分有两个好处:一是被包含用例被抽取出来,基本用例得以简化;二是可以抽象出公共事件流,实现代码复用。


有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。如:


3、扩展(转)

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

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

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

四、包含关系与扩展关系

共同点:扩展用例与包含用例都是基用例的一部分

              基本用例不执行,扩展用例与包含用例都不会执行

              扩展用例可以扩展多个基本用例,包含用例可以被多个基本用例包含

区别:

            扩展关系中基本用例的基本流执行时,扩展用例不一定执行,即扩展用例只有在基本用例满足某种条件的时候才会执行。

            包含关系中基本用例的基本流执行时,包含用例一定会执行。

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

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


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

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

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


posted @ 2012-01-28 11:05  yjjm1990  阅读(11845)  评论(0编辑  收藏  举报