• 步步为营UML建模系列三、用例图(Use Case)


    转载自:http://www.cnblogs.com/springyangwc/archive/2011/12/27/2303105.html

    概述

    用例试图描概括了用例中角色和系统之间的关系,描述了系统功能需求,角色和系统的交互以及系统的反应。

    官方定义:用例定义了一组用例示例,其中每个示例都是系统所执行的一系列操作,这些操作生成特定主角可以观测的值.

    简单的说法:一个用例就是与参与者交互的,并且给参与者提供可观测的意义的结果的一系列活动的集合,所谓的用例就是一件事情,要完成这件事情,需要做的一系列的活动;而做一件事情可以有很多不同的办法和步骤,也可能会遇到各种各样的意外情况,因此这件事情是由很多不同情况的集合构成的,在UML中称之为用例场景。一个用例场景就是一个用例的实例。

    用例的特征

      1.用例是相对独立的,就是说他不与其他用例交互,而是独自完成参与者的目的。

      2.用例的执行结果对于参与者来说是可观测的和有意义的。例如系统中有个删除前自动备份数据的操作,这个操作结果对与参与者是透明的,参与者不是直接受益人,所以他不能称之为用例。

      3.事件必须由一个参与者发起,不存在没有参与者的用例,用例不应该自动启动,或启动其他的用例。

      4.用例必然是以动宾短语形式出现的、例如“喝水”是一个有效的用例,而“喝”不是。

    用例的粒度

      用例的粒度是根据建模的抽象层次所决定的。

      1.在业务建模阶段,用例的粒度是以每个用例能够说明一件完整的事情为宜。

      2.在概念建模阶段,用例的粒度是以每个用例能够描述一个完成的事件流为宜。

      3.在系统建模阶段,用例的粒度是以每个用例能够描述操作者与计算机的一次完整的交互为宜。

    用例和功能的误区

      功能和用例是有本质的区别的。

      1.功能是脱离使用者的愿望而存在的。例如我们描述一个自行车的功能就是他能骑和载物,并无谁来使用它。

      2.功能是孤立的,在系统中,给一个输入就能得到一个输出。而用例是一个系统性的工作,这个系统的工作非常明确的去为某个参与者达成一个特定的目标。

      3.如果非要从功能的角度去解释用例,那么用例可以解释为一系列完成一个特定目标的功能的组合。

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

    1、包含关系:使用包含(Inclusion)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base)用例复用。基用例控制与包含用例的 关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。
    包含关系对典型的应用就是复用,也就是定义中说的情景。但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子过程,然后再从主程序中调用这一子过程。

    例如:管理员管理文章,就包含增加、修改和删除几种功能。

    image

    2、扩展(extend)

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

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

    例如:在管理员提交申请之后,就可以打印申请单和查看申请单。

    image

    4、泛化(generalization)

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

    image

     

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

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

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

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

     

    最后再呈现一个用例图示例

    image

     


    作者:spring yang

    出处:http://www.cnblogs.com/springyangwc/ 

  • 相关阅读:
    jquery同步请求
    js换空格为别的元素
    获取页面的checkbox,并给参数赋值
    jQuery判断checkbox是否选中的3种方法
    opencv基础知识------IplImage, CvMat, Mat 的关系和相互转换
    Opencv基础知识-----视频的读取和操作
    OpenCV 基础知识------图像创建、访问、转换
    windows消息钩子注册底层机制浅析
    Windows内核遍历驱动模块源码分析
    VC 快速创建多层文件夹
  • 原文地址:https://www.cnblogs.com/colder/p/2381613.html
Copyright © 2020-2023  润新知