文档介绍：该【软件工程用例图 】是由【niuwk】上传分享，文档一共【27】页，该文档可以免费在线阅读，需要了解更多关于【软件工程用例图 】的内容，可以使用淘豆网的站内搜索功能，选择自己适合的文档，以下文字是截取该文章内的部分文字，如需要获得完整电子版，请下载此文档到您的设备，方便您编辑和打印。学习内容
什么叫用例图
用例图的构成要素
用例的重要元素
用例之间的关系
使用Rose创建用例的步骤说明
第1页/共27页
什么叫用例图
由参与者(Actor)、用例(UseCase)以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。要在用例图上显示某个用例,可绘制一个椭圆,然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。
要在用例图上绘制一个参与者(表示一个系统用户),可绘制一个人形符号。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述,箭头表示在这一关系中哪一方是对话的主动发起者,箭头所指方是对话的被动接受者。
第2页/共27页
什么叫用例图
在用例建模中,为了更加清楚的描述用例或者参与者,会使用到注释。
第3页/共27页
什么叫用例图
用例图是需求分析中的产物,主要作用是描述参与者和用例之间的关系,帮助开发人员可视化的了解系统的功能。借助于用例图,系统用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨,减少了大量交流上的障碍,便于对问题达成共识。
用例图可视化地表达了系统的需求,具有直观、规范等优点,克服了纯文字性说明的不足。
用例方法是完全从外部来定义系统功能,它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的,系统对于我们来说就是一个黑箱子。
第4页/共27页
用例图的构成要素
参与者(Actor)是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。
每个参与者可以参与一个或多个用例,每个用例也可以有一个或多个参与者。
在用例图中使用一个人形图标来表示参与者,参与者的名字写在人形图标下面。
第5页/共27页
用例图的构成要素
由于参与者实质上也是类,所以它拥有与类相同的关系描述,即参与者与参与者之间主要是泛化关系(或称为“继承”关系)。
泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为,并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系,在UML图中,使用带空心三角箭头的实线表示泛化关系。
第6页/共27页
用例图的构成要素
在项目开发过程中,边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。
系统同时又是相对的,一个系统本身又可以是另一个更大系统的组成部分,因此,系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分,称之为系统环境。
第7页/共27页
用例的重要元素
任何用例都不能在缺少参与者的情况下独立存在。同样,任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始,在这个过程中往往会发现新的参与者。
可以通过以下问题来寻找用例:
(1)参与者希望系统提供什么功能?
(2)参与者是否会读取、创建、修改、删除、存储系统的某种信息?如果是的话,参与者又是如何完成这些操作的?
(3)参与者是否会将外部的某些事件通知给系统?
(4)系统中发生的事件是否通知参与者?
(5)是否存在影响系统的外部事件。
第8页/共27页
用例的重要元素
用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大,用例包含的功能越多,反之则包含的功能越少。
如果用例的粒度很小,得到的用例数就会太多。反之,如果用例的粒度很大,那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大,不便于进一步的充分分析。
第9页/共27页
用例的重要元素
比如:网站后台管理系统中的会员信息维护用例,管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。
我们还可以根据具体的操作把它抽象成3个用例,它展示的系统需求和单个用例是完全一样的。
第10页/共27页