阅读 8082

UML 用例图详解

用例图 (Use Case Diagram) 是用来显示一组用例、参与者以及它们之间关系的图。它描述了用户希望如何使用一个系统。通过用例图可以知道谁是系统相关的用户,他们希望系统提供哪些服务,以及他们需要为系统提供什么样的服务。

用例图能给我们带来什么?

  1. 用来描述要开发的系统的功能需求和系统的使用场景。
  2. 促进开发过程中各个阶段工作的进展。
  3. 用来验证与确认系统需求。

用例建模是实现系统需求分析的一个很好的方法,通过它可以使得系统分析员和客户之间能够更好地沟通系统的需求。

用例图的组成

在介绍中我们说到用例图是显示一组用例、参与者之间关系的图。接下来的内容详细的阐述了什么是用例、什么是参与者以及他们之间有什么样的关系。

参与者 (Actor)

参与者也叫角色,它表示了系统的用户。这里需要注意的是:这里的用户并不特指人,如果我们开发的是公共 API 项目,那么这个时候,API 的调用者就是我们的用户。

参与者指的不是用户本身,而是它在系统中所扮演的角色。举个例子来说,张三是淘宝店的店主,这个时候他参与淘宝的交互时,他既可以是店主这个角色,也可以作为买家在淘宝上购买东西,这个时候张三在系统中扮演了两个角色,这两个角色是两个不同的参与者即买家卖家

参与者的作用是:

  • 建立系统的外部用户模型
  • 对系统边界之外的对象进行描述

我们先来看两个案例:

例:销售员每天下班前将当日销售情况通过邮件发送给销售经理,由销售经理将总的销售记录进行汇总录入到系统中。

这个时候和系统进行交互的人是销售经理,所以销售经理是系统的参与者。

参与者在我们代码中,本质上还是类,所以在参与者中也存在继承的关系(分析阶段一般用泛化关系来表示继承)。泛化关系 (Generalization) 表示一个一般性的参与者(父参与者)和另一个特殊参与者(子参与者)之间的联系。参与者之间的泛化关系用带空心箭头的实线来表示,箭头端表示父参与者。

在上面的图中,我们可以发现,管理员和普通用户都是用户的特殊化,所以可以抽象出一个父参与者来,管理员和普通用户都拥有用户的全部特性,同时还具有自己特殊的特性。

用例(Use Case)

需求分析是软件开发流程中必不可少的一个环节,其主要目的就是建立待开发系统的模型,而用例则是建立这些的最好方法。

用例是对一组动作的描述,系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或者功能。

在 UML 中,用例通常用一个椭圆形符号来表示:

在电商系统中,“加入购物车”就是一个用例,在社交软件中,“发送消息给某人”就是一个用例。

使用用例进行系统需求分析的特点:

  • 用例是从系统的使用者角度来描述系统中的信息,即在系统的外部所能看到的系统的功能,而不考虑系统内部对该功能的具体实现
  • 用例描述了一下可见需求,对应一个具体的用户目标。使用用例可以用来划分系统与外部实体的界限。
  • 用例通常由某个参与者来执行。
  • 用例把执行结果返回给参与者。
  • 用例在功能上具有完整性。它从参与者接受输入,再将产生的结果输出给参与者。

一般情况下,我们如果向其他人描述一个一个功能的具体信息呢?我们通过文字来对功能进行讲解。用例图只是简单的用图形方式描述系统,关于功能的完整解说还是需要用文字来表达。所以,对于用例,我们需要由详细的说明,这样才能让其他人更加清楚的了解这个系统。这个时候我们就需要编写用例描述了。

通常不会对用例描述做硬性规定,但是一些复杂的或者是重要的用例还是要编写用例描述。用例描述一般包括用例编号、用例说明、前置条件、基本事件流、其他事件流、异常事件流和后置条件等。

下面是“加入购物车”用例的详细描述:

元素 描述
用例名称 加入购物车
用例标识 UC001
简要说明 将商品添加到用户购物车中
前置条件 用户已经登录
基本事件流 用户向系统发送加入购物车的请求,系统需要对商品的库存、用户购物车数量进行验证来判断是否能够加入到购物车中
其它事件流
异常事件流 如果商品库存不足,则告知用户库存不足无法添加;如果用户购物车已达上限,则告知用户购物车已满,需要删除部分商品后才能添加
后置条件 添加成功后,需要对用户购物车数量重新进行统计
注释

说完用例,我们来说说用例之间的关系

用例之间的关系

包含关系

包含关系指的是两个用例之间,其中一个用例(基本用例)的行为包含了另外一个用例(包含用例)。

在 UML 图中,包含关系用带箭头的虚线表示,并且线上标有<<include>>,箭头的方向是从基本用例到包含用例。

扩展关系

扩展关系是对基本用例的扩展,基本用例是一个完整的用例,即使没有子用例参与,也可以完成一个完整的功能。扩展的基本用例中存在一个扩展点,只有扩展点被激活时,子用例才会被执行。扩展关系是从扩展用例到基本用例的关系,它说明扩展用例如何插入到基本用例中。

扩展用例的使用场景:

  • 表明用例的某一部分是可选行为
  • 表明只在特定条件下才执行的分支
  • 表明可能有一组行为,其中的一个或多个行为可以在基本用例中的扩展点处插入。所插入的行为和顺序取决于在执行基本用例时与主角进行的交互。

在 UML 图中,使用带箭头的虚线表示,并且虚线上标有 <<extend>>:

泛化关系

泛化关系指的是一般(父用例)与特殊(子用例)的关系。当多个用例共同拥有一种类似的结构和行为时,可以将它们的共性抽象为父用例,其他的用例作为泛化关系中的子用例。

分组关系

在一些用例图中,用例数量可能很多,这个时候就需要把这些用例组织起来。

用例图建模及应用

创建用例图模型主要包含3部分内容:

  • 识别系统中的角色和用例
  • 区分用例之间的先后次序
  • 创建用例图模型结构

识别系统中的角色和用例

这部分工作通常由系统分析员通过和客户沟通来完成。

要获取系统的用例,首先要找出系统的角色。

要获取系统角色可以在与客户沟通时,询问用户一些问题来识别角色。可以参考下列问题:

  • 谁将使用系统的主要功能?
  • 是需要系统的支持以完成日常工作?
  • 谁负责维护、管理系统并保持系统正常运行?
  • 系统需要与哪些外部系统交互?
  • 系统需要处理哪些硬件设备?
  • 谁对系统运行产生的结果比较感兴趣?

当我们获取到系统角色后,我们可以通过角色来列出它的用例。可以通过回答下列问题来识别用例:

  • 每个角色执行的操作有什么?
  • 什么角色将要创建、存储、改变、删除或者读取系统中的信息?
  • 什么用例会创建、存储、改变、删除或读取这个信息?
  • 角色需要通知外部系统的突然变化嘛?
  • 系统需要通知角色正在发生的事情吗?
  • 什么用例将支持和维护系统?

区分用例优先次序

某些用例必须在其他用例完成之前完成,因为它们是相互依赖的。例如在购买商品前,用户必须先登录。

构建用例图模型

将已经确定并细化的角色和用例放入用例图。再借助包含、扩展和泛化的关系给出用例之间的结构模型。

在系统需求分析中需要考虑系统用例图模型需要哪些视图、每个视图包含什么内容,以及视图中成员是否需构成包。

小结

用例建模是实现系统需求分析的一个很好的方法,使得系统分析员和用户之间能够更好地沟通系统的需求。