分享

UML图详解(二)——用例图

 星光闪亮图书馆 2017-09-22

一、概念

用例图(Use Case Diagram):主要用于描述系统的行为及各种功能之间的关系,是描述参与者(Actor)与用例以及用例与用例之间关系的图。

用例图=参与者+用例+关系

二、用途

  • 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。

  • 用例图最常用来描述系统以及子系统。

通俗的来说:用例图与具体实现并不关联,从用户和外部系统的角度,分析和考察系统的行为,并通过参与者者与系统之间的交互关系描述系统对外提供的功能特性。

三、用例图包含的元素

1.参与者(Actor)

  • 参与者可以是人或其他外界系统。

  • 参与者时用力的启动者,参与者处于用例的外部并且能够初始化一个用例并参与用例的执行过程,但它并不是系统的一部分。

  • 每个参与者可以参与一个或多个用例。

表示方式:

(此种方式,参与者的名字写在下方。建议使用这种方式,形象易懂。)

UML2.O表示参与者的方法:

(此种方式,name是参与者的名字,《Actor》是一个构造型,表示当前的元素是参与者。)

发现参与者,可以根据以下问题来寻找系统的参与者:

  1. 谁或什么在使用系统;

  2. 交互中,他们扮演什么角色;

  3. 谁安装系统;

  4. 谁启动和关闭系统;

  5. 谁维护系统;

  6. 与该系统交互的是什么系统;

  7. 谁从系统获取信息,谁提供信息给系统;

参与者相关的注意问题:

  1. 参与者对于系统而言是外部的,它们在系统控制之外。

  2. 参与者直接同系统交互,可以帮助定义系统边界。

  3. 参与者表示人和事物与系统发生交互时所扮演的角色,而不是特定的人或事物。

  4. 一个人和事物与系统发生交互时,可以扮演多个角色。例:某个研究生担任某教授的助教,从职业的角度看,他扮演了两个角色----学生和助教。

  5. 每个参与者需要有一个具有业务语义的名字。

  6. 每个参与者必须有简短的描述,从业务角度描述参与者是什么。

  7. 参与者可以具有分栏,表示参与者属性和它可接受的事件。

  8. 参与者可以使用用泛化关系来描述多个参与者之间的公共行为。

2.用例(Use Case)

  • 用例是一组动作序列(业务工作流程)的描述,系统执行该动作序列为系统的参与者产生一个可观察的结果。

  • 用例反映用户的需求。

  • 用例是一个叙述型的文档,用来描述一个参与者使用系统完成某个事件时的事情发生顺序。(描述参与者与系统的交互)

  •  用例是系统的使用过程,是对系统的用户功能需求的描述,用例表达了系统的功能和所提供的服务。

表示方式:


识别用例的方法:从分析系统的参与者开始,考虑每个参与者是怎样使用系统的。

以下几个问题可以帮助识别用例:
<1>特定参与者希望系统提供什么功能;
<2>系统是否存储和检索信息,若是,这个行为由哪个参与者触发;
<3>当系统改变状态时,通知参与者吗;
<4>存在影响系统的外部事件吗;
<5>是哪个参与者通知系统这些事。

3.关联关系(Association)

是参与者与用例之间最简单常用的关系


4.包含关系(Include)

把几个用例的公共步骤分离成一个单独被包含用例;包含用例称为客户用例,被包含用例称为提供者用例。

用例A包含用例B,将A称为基用例,B称为被包含用例。

包含关系表示基用例会用到被包含用例。被包含用例的事件流在基用例的某个点处插入到基用例的事件流中。

包含关系表示:

基用例被连接在虚线箭头的尾部,箭头指向被包含用例,并在虚线处添加一个《include》标签以表示扩展关系。

使用场景:

  1. 如果两个用例有大量一致功能,则可以将这个功能分解到另一个功能。其他用例可以和这个用例建立包含关系;

  2. 一个用例的功能太多时,可以用包含关系建模两个小用例。

5.扩展关系(Extend)

扩展使得每个用例可以通过扩展用例向基用例中添加额外的行为来扩展基用例的功能。

用例A扩展了用例B,那么A称为扩展用例或子用例,B表示为基用例。

扩展用例A的事件流在一定的条件下按照相应的扩展点插入到及用例中,这就需要在及用例中定义一至多个已命名的扩展点。(这和继承关系不一样)

选用扩展关系可以把一些可选的操作独立封装在另外的用例中,避免基用例过于复杂。

表示方式:

扩展用例被连接在虚线箭头的尾部,箭头指向基用例,并在虚线处添加一个《extend》表示扩展关系。


6.泛化关系(Generalization)

泛化关系是两个用例或两个参与者之间的关系。

泛化关系其实可以通俗理解为面向对象关系中的继承。将拥有一种类似的结构和行为的多个用例中的共性抽象为父用例,子用例继承父用例中的所有。

表示方式:

用实线加上空心的箭头表示,其中子用例被连接在箭头的尾部,箭头指向父用例。


7.扩展关系与包含关系的区别

相同点:

  • 都是两个用例之间的关系。(只有泛化关系不仅可以表示两个用例,还可以是两个参与者之间)

不同点:

(1)条件性:

  • 包含关系是无条件的

  • 扩展关系是有条件的

(2)插入原则:

  • 包含关系中被包含用例的事件流一定插入到及用例中去。

  • 扩展关系可以根据一定条件来决定是否将扩展用例的事件流插入到基用例事件流。

(3)插入点:

  • 包含关系中插入点只有一个。

  • 扩展关系的插入点可以有多个。

四、系统边界

需求:一个系统中的每个功能都有它的所属范围。并且在决定参与者、设计一个系统、子系统或某个部件的时候,划分系统边界对于决定系统的规模和分配责任是十分重要的。

系统边界(System Boundary)的表示:

UML中使用矩形框来表达系统的边界,在矩形框的左上方防止系统的名字。


********************************************************************************结束语********************************************************************************************
  我在写这篇博客的时候也是一名初学者,有任何疑问或问题请留言,或发邮件也可以,邮箱为:577328725@qq.com,我会尽早的进行更正及更改。
在我写过的博客中有两篇博客是对资源的整理,可能对大家都有帮助,大家有兴趣的话可以看看!!
下载资料整理——目录:http://blog.csdn.net/fanxiaobin577328725/article/details/51894331
  这篇博客里面是我关于我见到的感觉不错的好资源的整理,里面包含了书籍及源代码以及个人搜索的一些资源,如果有兴趣的可以看看,我会一直对其进行更新和添加。
优秀的文章&优秀的学习网站之收集手册:http://blog.csdn.net/fanxiaobin577328725/article/details/52753638
  这篇博客里面是我对于我读过的,并且感觉有意义的文章的收集整理,纯粹的个人爱好,大家感觉有兴趣的可以阅读一下,我也会时常的对其进行更新。
********************************************************************************感谢********************************************************************************************

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多