第3章 用例图知识点全解析与实践应用指南

1,667 阅读8分钟

用例图基本概念

用例图(Use Case Diagrame)


用例图是用来描述系统功能的技术,表示一个系统中用例与参与者及其关系的图,主要用于需求分析阶段。

用例图使用范围:需求分析

1.捕获需求。描述功能需求、行为需求(系统要完成什么任务)

2.分析需求。明确类和对象,建立之间的关系

用例图的基本概念


1、用例图是表示一个系统中用例与参与者关系之间的图。它描述了系统中相关的用户和系统对不同用户提供的功能和服务。

2、用例图相当于从用户的视角来描述和建模整个系统,分析系统的功能与行为。

3、用例图中的主要元素包括参与者、用例以及元素之间的关系。此外,用例图还可以包括注解和约束,也可以使用包将图中的元素组合成模块。

用例图的基本组成元素


参与者、用例、元素之间的关系。

一、参与者

判断参与者的方法:

参与者不一定是人,也可以是任何的事,通常可以将参与者分为以下三类:

1)真实的人,即用户

这一类是最常用的参与者,几乎在每个系统中。在命名这一类参与者时,应该按照业务而不是位置命名,因为一个人有可能有多重身份。

比如:汽车租赁公司的客户服务代表,通常情况下是客户服务代表,但在她有租赁行为时,就变成了客户。因此,按照业务而不是位置命名可以获得更加稳定的参与者。

2)其他的系统

在有的系统中,还需要建立与其他系统的接口,依然以汽车租赁系统为例,它可能要与外部应用程序建立练习,比如:说外部信用卡应用程序,这时候外部信用卡应用系统就是一个参与者。

3)可运行的进程

以时间为例,当经过一定时间触发系统中的某个时间时,时间就成了参与者。比如:在汽车租赁系统中,到了还车时间客户仍未归还,系统便会提醒客户代表致电客户。由于时间不再在人的控制内,因此它也是一个参与者。

参与者间的关系

对于一些参与者来说,它既扮演者自己的角色,同时也扮演更一般的角色,在案例图中用泛化关系来描述他们(此点与上一节类图中介绍的泛化关系类似)。

假设汽车租赁系统可以接受客户的电话预定和网上预订,那么参与者“客户”就描述了参与者“电话客户”和“网上用户”所扮演的一般角色。泛化关系与类图一样都使用一个空心三角箭头表示,指向扮演一般角色的超类。

例如电话订票用例和网上订票用例指向订票用例,游客和vip指向用户用例。

在确定参与者当中,如果不考虑客户是如何与系统接触的,就使用一般角色参与者,即父类;如果强调接触发生的形式,则必须采用实际的参与者,即子类。

二、用例


用例是类元提供的一个内聚的的功能单元,表明系统与一个或多个参与者之间信息交换的顺序,也表明了系统执行的动作。

简单来说,用例就是某一个参与者在系统中做某件事从开始到结束的一系列活动的集合,以及结束时应该返回的可观测、有意义的结果,其中也包含可能的各种分支情况。

用例与用例图被广泛使用于系统的需求建模阶段,并在系统的整个生命周期中被不断细化。

用例的特征

用例的特征保证用例能够正确地捕捉功能性需求,同时也是判断用例是否准确的依据。

1)用例是动宾短语

2)用例是相对独立的

3)用例是由参与者启动的

4)用例要有可观测的执行结果

5)一个用例是一个单元

三、关系


用例与参与者的关系

一个用例可以隶属一个或多个参与者,一个参与者也可以参与一个或多个用例。用例与参与者之间存在关联关系。

主参与者与次参与者:通常来说主参与者是用例的重要服务对象,而次参与者处于一种协作地位。

用例之间的关系

1. 关联关系

这是最常使用的关系,用带箭头的实线来描述。以汽车租赁系统中的“客户”参与这以及和他交互的3个用例(预定、取车和换车)为例。

2.泛化关系(Generalization)

一个用例可以被列举为多个子用例,这就被成为用例泛化,这与类间的泛化关系类似。在用例泛化中,子用例表示父用例的特殊形式,可从父用例处继承行为和属性。泛化关系的图形用空心实线箭头表示,箭头指向父类。

如下图所示是汽车租赁公司用例图中的用例“预定汽车”,该用例有两个子用例“预定大巴中巴”和“预订小车”。

3.依赖关系:包含关系(Include)

包含: 指的是其中一个用例(称为基础用例)的行为包含了另一个用例(称为包含用例)。

基础用例包含用例并依赖包含用例的执行结果。但是二者不能访问对方的属性。包含关系的图形为虚线箭头加<>,箭头指向包含用例。

再举个例子:仍然是汽车租赁系统,客户无论是预定、取车还是还车,都需要用户登录,所有此时使用例“登录”被用例“预定”、“取车”和“还车”所包含,这样就能避免许多重复的动作。

4.依赖关系: 扩展关系(Extend)

扩展用例可以被定义为:基础用例的增量扩展,它俩之间为扩展关系。扩展指的是一个用例(扩展用例)对另一个用例(基用例)行为的增强。

简单来说,就是当某特定条件出现时,该扩展用例的行为才会被执行。扩展关系的图形为虚线箭头加上<<>>,箭头指向基础用例。

扩展使用一个附加了《enxtend》构造型的虚线箭头表示,箭头指向基用例。

注意:扩展与包含的箭头方向是相反的,这表明扩展取决于扩展用例而非基用例,扩展用例决定扩展的执行时机,基用例对此一无所知。

扩展用例的使用包括四个部分:

基用例:需要被扩展的用例,“注册”用例。

扩展用例:提供所添加的行为序列的用例,如图中的“检查实名信息”用例。

扩展关系:使用虚线箭头表示,箭头指向基用例。

扩展点:基用例中的一个或多个位置,表示在该位置会根据某条件来决定是否要中断基用例的执行从而执行扩展用例中的片段。

实验实训

实验一:QQ音乐用户及其相关用例(简易版)

实验二 企业进销存管理系统

通过实例解析企业进销存管理系统,展示用例图如何捕捉和分析需求,促进不同角色(采购员、仓库管理员、统计人员、销售员和系统管理员)与系统间的交互。了解用例图中参与者、用例及关系的构建,为实现高效业务流程提供蓝图。功能性需求包括以下内容:

  (1)采购员根据生产原料的使用情况判断采购用品,对需要订购产品信息统计订货的,并制作产品订单。最后根据订单进行采购活动。

  (2)仓库管理员负责产品的库存管理。包括产品入库管理、处理盘点信息、处理报损产品信息和一些信息的设置。这些设置信息,包括:供应商信息、产品信息。仓库管理员每天对产品进行一次盘点,当发现库存产品有损坏时,及时处理报损信息。当产品生产后,将产品进行入库。当产品销售后时,产品进行出库处理。

  (3)统计人员负责统计分析管理,包括:查询产品信息、查询销售信息、查询供应商信息、查询缺货信息、查询报表信息,并制作报表。统计分析员使用系统的统计分析功能,了解产品信息、销售信息、供应商信息、库存信息。

 (4)在销售员为客户提供售货服务时,接受客户购买产品,根据系统的定价计算出产品的总价,客户付款,系统自动保存客户购买记录。

(5)系统管理员负责本系统的系统维护。系统管理员负责员工信息管理、供货商信息管理以及系统维护等。每种管理者都通过自己的用户名称和密码登录到各自的管理系统中。