UML用例建模解析(二)---------用例执行者之间关系

(1) 关联关系

关联关系是指执行者与用例之间的关系,又称为通信关系,如果某个执行者可以对某个用例进行操作,它们之间就具有关联关系,如下图所示,“经理”有一个功能为“查看库存报表”,因此可以在执行者“经理”和用例“查看库存报表”之间建立一个关联关系,关联关系用实线表示。

(2) 泛化关系

执行者之间的关系只有一种,即泛化关系,用一个带有空心三角形的实线表示,如下图所示,在该图中,仓库管理员、系统管理员、经理都是员工的一种,因此员工拥有的功能这三者都拥有,如登录、修改个人信息等,为了减少用例的个数并且使系统更加符合面向对象设计规范,可以对执行者进行泛化,将各类执行者都具有相同的功能移至父执行者,而将每类执行者特有的功能保留在子执行者中。

常见的用例之间的关系有两种,分别是包含关系和扩展关系,下面介绍这两种关系的含义以及在用例图中如何表示。

(3) 包含关系

如果多个用例都具有一部分相同的行为,可以将这部分相同的行为作为一个单独的用例抽取出来,与原来的用例形成一个包含关系。如仓库管理员在进行入库、出库等操作之前需要先登录,登录是入库、出库流程的基本组成部分,因此用例“入库”和“出库”包含用例“登录”。为了更加清晰地描述多个用例的相同行为,在用例图中提供了用例与用例之间的包含关系。

在UML中,包含关系用依赖线(虚线)加一个<<include>>表示,由原始用例指向包含用例,如下图所示:

(4) 扩展关系

扩展关系又称为延伸关系,如果一个用例在执行时可能会使用到另一个用例,或者使用一个新的用例对原有用例的行为进行扩展时可以使用扩展关系,如仓库管理员在入库时发现某种商品在系统中暂不存在,则可以增加新的商品信息;如果入库商品均已存在,则无需增加商品信息,此时用例“增加商品信息”可以作为用例“入库”的扩展用例。在需要扩展的用例(原始用例)中需指定一个扩展点(即需扩展的位置),在下一节编写用例文档中将学习如何设置扩展点。

在UML中,包含关系用依赖线(虚线)加一个<<extend>>表示,由扩展用例指向原始用例,如下图所示:

关于包含关系和扩展关系箭头的指向,可以记住两句口诀:包含进来,箭头向外;扩展出去,箭头向里。

除了上述的包含关系和扩展关系外,用例之间还存在一种与执行者泛化类似的泛化关系,但不太常见,在这里不予以详细介绍。

时间: 2024-10-11 05:26:48

UML用例建模解析(二)---------用例执行者之间关系的相关文章

再学UML-UML用例建模解析(三)

2. 编写用例文档 绘制用例图只是完成了用例建模最基本也是最简单的一步,用例建模的核心在于编写用例文档,用例文档又称为用例规约或用例描述.顾名思义,用例文档是用于描述用例的文档,每一个用例对应于一个用例文档,在用例文档中需要用文字的方式描述用例的执行过程,即执行者与系统的交互过程. 用例文档需要通俗易懂,不仅项目的开发人员能够理解,系统的用户以及客户也能够看懂用例文档.一个完整的用例文档包括用例编号.用例名.执行者.前置条件.后置条件.涉众利益.基本路径.扩展路径.字段列表.业务规则.非功能需求

采用[ICONIX] 方法实践分析和设计之二 [用例建模](转)

在上一篇文章中我们了解并进行了域建模,换言之我们有了一个好的开始,起码开发人员对自己要开发的软件已有了初步的认识,且也得到了进行交流时可以使用的术语表. 本章将会在前一篇的基本上进一步阐述使用ICONIX方法实践用例建模,同样在文章的最后还会有在这个阶段最容易犯的10个错误,以给大家提醒或在分析过程中进行参照.     本文在ICONIX方法中所处的位置如下图(红圈标记的地方)     在开始进行用例建模之前,我们需要对这一过程有一些粗线条的认识,如果您以前做过或学习过这方面的知识,可以把下面的

Uml学习-用例建模简介

用例建模简介  用例建模是UML建模的一部分,它也是UML里最基础的部分.用例建模的最主要功能就是用来表达系统的功能性需求或行为.用例图重点描述用户需求. 它描述需求.用户和主要组件之间的关系. 它不会详细描述用户需求:在可链接到每个用例的其他关系图或文档中可详细描述这些需求.用例图是UML的九个图中较为重要和常用的一种图.常常用于软件开发的需求分析阶段,也能用于软件的系统测试阶段.简单的来说,用例图是描述系统的外部视图,为了搞清某个项目的大概需求,我们往往要问两个问题, 1.  这个系统有什么

第三项任务——用例建模

SRS文档——用例建模 一.spec概念 Specification, 又叫spec, 有两种: a) functional spec, 软件功能说明书, 主要用来说明软件的外部功能, 和用户的交互情况 (把软件当作一个黑盒子). b) technical spec, 软件技术说明书, 又叫 design doc, 设计文档, 主要用来说明软件内部的设计 (把软件当作一个透明的箱子). 二.用例建模 用例建模(Use Case Modeling)是使用用例的方法来描述系统的功能需求的过程,用例模

用例建模指南

用例建模指南 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模.用例方法最早是由Iva Jackboson博士提出的,后来被综合到UML规范之中,成为一种标准化的需求表述体系.用例的使用在RUP中被推崇备至,整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的,各种类型的开发活动包括项目管理.分析设计.测试.实现等都是以系统用例为主要输入工件,用例模型奠定了整个系统软件开发的基础. 1. 什么是用例? 在介始用例方法之

需求用例分析之二:级别设置

在<编写有效用例>(阿莱斯特-科伯恩著,下面用科伯恩用例来指代)一书中,赋予了用例不同的级别,科伯恩形象的设定了例如以下级别:海平面.云朵.风筝.蛤等等. 科伯恩建议用例级别分为多个个目标层次:概要.用户目标.子功能,书写需求用例时,仅仅能选择其一,以下对其详细说明: 概要:包含多个用户目标,它有"显示相关目标的生命周期顺序"和"为低层用例提供一个文件夹表"的功能,概要用例通常须要运行几个小时.几天.几个星期.几个月.甚至几年. 用户目标:它是主运行者努

Linux文件系统的用例建模

1 用例 用例(Use Case)是一种描述系统需求的方法,使用用例的方法来描述系统需求的过程就是用例建模. 1.1 参与者和用例 从用户的角度来看,他们并不想了解系统的内部结构和设计,他们所关心的是系统所能提供的服务,也就是被开发出来的系统将是如何被使用的,这就是用例方法的基本思想.用例模型主要由以下模型元素构成: 参与者(Actor)参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统,他们代表的是系统的使用者或使用环境. 用例(Use Case)用例用于表示系统所提供的服务,它定

三维地图漫游用例建模

一.建模背景 (1)工程实践项目需求 我的工程实践课题是基于室内地图数据,运用OpenGL渲染手段,构建并渲染三维空间模型,进一步可应用到虚拟现实的交互游戏场景. (2)用例建模意义 用例方法完全是站在用户的角度上(从系统的外部)来描述系统的功能的.在用例方法中,我们把被定义系统看作是一个黑箱,我们并不关心系统内部是如何完成它所提供的功能的. 用例方法首先描述了被定义系统有哪些外部使用者(抽象成为Actor),这些使用者与被定义系统发生交互:针对每一参与者,用例方法又描述了系统为这些参与者提供了

用例建模 Use Case Modeling

1.业务内容 我的工程实践项目是实现一个企业端的智能信息搜集与数据分析系统,具体来说就是利用网络爬虫技术获取企业所需要商品的报价以及部分商品的价格变化趋势,从而给与用户企业的生产与采购决策以信息支撑. 2.业务的用例建模及用例图. 本系统所要实现的核心功能有二:其一,是实现对商品网站信息的抓取与存储:其二,是实现对商品价格信息的提取与分析,从而将分析结果呈现给企业用户.据此,我们首先定义系统边界:系统包含将用户所需信息从互联网网站中提取的功能模块以及将用户所检索的关键信息及其相关内容呈现给用户的