UML图总结-需求分析阶段用例图的使用

Posted 2023-04-20

参考技术A

最近过年因为新冠病毒的肆虐各公司都开始放长假了，初步估计都是要出了元宵才能回成都上班，虽然返岗之前要在家办公（上班），但是还是得做点欠着的事情舍，其中比较重要的一个就是我的毕业设计嘞，一两个月就要交初稿了，但是我还没开始嘞

由于毕业设计需要用到各种UML图，所以就趁这个机会好好复习和总结一下软件工程课程有关UML图的相关内容吧，毕竟这个在软件设计和分析的流程中还是占据比较重要的地位，也是软件分析的利器，能帮助我们快速分析我们要做的事情，也能使我们要做的东西一目了然，接下来就直接开始总结和复习吧，就以我的毕业设计——一个简单的在线考试系统为例开始我们的学习之旅

用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。
例如我们在线考试系统的业务用例图：

简单来说就是：用例图是由参与者（Actor）、用例（ Use Case ）、 系统边界 、箭头组成，用画图的方法来完成的一个表达系统功能的图示。
接下来分别介绍其成分。

参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象。

简单来说就是： 一个系统的使用者，可能涉及的角色就是一个参与者

每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。
在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。

简单来说就是： 用例 是对包括变量在内的一组动作序列的描述，系统执行这些动作，并产生传递特定参与者的价值的可观察结果。

系统边界 是用来表示正在 建模 系统的边界。边界内表示系统的组成部分，边界外表示系统外部。系统边界在画图中用方框来表示，同时附上系统的名称，参与者画在边界的外面， 用例 画在边界里面。因为系统边界的作用有时候不是很明显，所以我个人理解，在画图时可省略。

要创建用例，我们需要分析哪些可以作为用例，如何识别，可以从以下几点来确定用例：

简单来说就是：如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。

比如在我们的考试系统中：我们的老师可以对试卷进行管理，那么展示出来的粒度较大的用例可以是这样：

如果我们按照具体的操作把它抽象成多个用例（粒度变小），它也可以是这样的：

它展示的系统需求和单个用例是完全一样的。

用例之间的关系包括以下几种：

UML之用例图

用例图

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

 

用例图的基本组成元素：参与者、用例、元素之间的关系。

 

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

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

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

 

用例图的基本概念

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

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

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

如：

 

参与者的概念

1、参与者是与系统主体交互的外部实体的类元，描述了一个或一组与系统产生交互的外部用户或外部事物。

2、参与者位于系统边界之外，而不是系统的一部分。

3、参与者是从现实世界中抽象出来的一种形式，却不一定确切对应的现实中的某个特定对象。

符号：

 

 

如何确定参与者？

通过对参与者进行关注和分析，我们可以把重点放在如何与系统交互这一问题上，便于进一步确定系统的边界。另外，参与者也决定了系统需求的完整性。

确定参与者可以从以下几个角度来考虑：

1）为系统提供输入的人或事物

2）接收系统输出的人或事物

3）需要接入的第三方系统或设备

4）时间是否会触发某些事件

5）负责支持或维护系统中信息的人

 

系统中的参与者一般可以分为四类：

主要业务参与者：主要从用例的执行中获得好处的关联人员。

主要系统参与者：直接同系统交互以发起或触发业务或系统事件的关联人员。

外部服务参与者：响应来自用例的请求的关联人员。

外部接收参与者：从用例中接收某些价值或输出的非主要的关联人员。

 

参与者的泛化关系

当系统中的几个参与者既扮演自身的角色，同时也有更一般化的角色时，可以通过建立泛化关系来进行描述。

与类相似，父参与者可以是抽象的，即不能创建一个父参与者的直接实例，这就要求属于抽象父参与者的外部对象一定能够属于其子参与者之一。

 

 

用例的概念

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

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

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

符号：

 

 

 

用例与参与者的关系

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

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

 

 

用例的特征

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

1）用例是动宾短语

2）用例是相对独立的

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

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

5）一个用例是一个单元

 

 

用例之间的关系

1．泛化关系

2.依赖关系（包含、扩展）

 

泛化关系：与参与者的泛化关系相似，用例的泛化关系将特化的用例与一般化的用例联系起来。子用例继承了父用例的属性、操作和行为序列，并且可以增加属于自己的附加属性和操作。父用例同样可以定义为抽象用例。

用例之间的泛化关系表示为一根实线三角箭头，箭头指向父用例一方。

 

 

依赖关系——包含

包含指的是一个用例（基用例）可以包含其他用例（包含用例）具有的行为，其中包含用例中定义的行为将被插入基用例定义的行为中。

包含的两个基本约束：

1）基用例可以看到包含用例，并需要依赖于包含用例的执行结果，但是它对包含用例的内部结构没有了解；

2）基用例一定会要求包含用例执行。

包含表示为一个虚线箭头附加上《include》的构造型，箭头从基用例指向包含用例。

 

 

 

依赖关系——扩展

扩展指的是一个用例（扩展用例）对另一个用例（基用例）行为的增强。

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

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

 

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

基用例：需要被扩展的用例，“注册”用例。

扩展用例：提供所添加的行为序列的用例，如图5-10中的“检查实名信息”用例。

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

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

 

 

 

包含、扩展的区别：

根本区别，包含是无条件执行，扩展是有条件执行。图的起点不同，终点也不同。

 

特性	include	extend
作用	增强基用例的行为	增强基用例的行为
执行过程	包含用例一定会执行	扩展用例可能被执行
对基用例的要求	在没有包含用例的情况下，基用例可以是也可以不是良构的	在没有扩展用例的情况下，基用例一定是良构的
表示法	箭头指向包含用例	箭头指向基用例
基用例对增强行为的可见性	基用例可以看到包含用例，并决定包含用例的执行	基用例对扩展用例一无所知
基用例每执行一次，增强行为的执行次数	只执行一次	取决于条件（0到多次）

 

 

用例描述与文档

用例描述概述：一个完整的用例模型应该不仅仅包括用例图部分，还要有完整的用例描述部分。

 

一般的用例描述主要包括以下几部分内容：

用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。

用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。

参与者：描述用例的参与者，包括主要参与者和其他参与者。

用例描述：对用例的一段简单的概括描述。

触发器：触发用例执行的一个事件。

前置条件：用例执行前系统状态的约束条件。

基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。

扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。

结论：描述用例何时结束。

后置条件：用例执行后系统状态的约束条件。

补充约束：用例实现时需要考虑的业务规则、实现约束等信息。

 

前置条件与后置条件

前置条件指的是用例执行前系统和参与者应处于的状态。前置条件是用例的入口限制，它便于我们在进行系统分析及设计的时候注意到，在何时何地才可以合法地触发这个事件。

后置条件是用例执行完毕后系统处于的状态。后置条件是对用例执行完毕后系统状况的总结，用来确保用户理解用例执行完毕后的结果，并非其他用例的触发器。

前置条件与后置条件分别是用例在开始和结束时的必要条件。

 

事件流

事件流是对用例在使用场景下的交互动作的抽象，应该包括用例何时以及怎样开始和结束，用例何时与参与者交互，该行为的基本流和可选择的流。

基本事件流：描述的是用例中最核心的事件流，是用例大部分时间所进行的场景。

扩展事件流：描述的是用例处理过程中的一些分支或异常情况。

 

补充约束

补充约束用来描述用例在系统功能之外的内容，例如非功能需求、业务规则等等。

数据需求：与该用例相关的一些数据项的说明。

业务规则：与业务相关的逻辑和操作规则。

非功能性需求：例如性能、支持的并发量等。

设计约束：是从多个角度对用例或系统的约定。

 

 

用例文档实践

用例名称	提交订单
用例编号	UC002
参与者	会员
用例描述	该用例描述一个系统会员提交一份订单的行为
触发器	当订单被提交时，用例触发。
前置条件	提交订单的一方需要完成登录操作
后置条件	如果订单中的商品有库存，则发货；否则提示用户当前缺货
基本事件流	1 参与者将订单信息提交至系统。 2 系统验证用户信息及订单信息合法后作出响应。 3 对于订单中的每种产品，系统根据订单中的数量检查产品库存数量。 4 系统统计订单中产品的总价格。 5 系统从会员的系统账户余额中扣除相应金额。 6 系统生成并保存订单信息并将订单发送至分销中心。 7 系统生成订单确认页面并发送给会员。
扩展事件流	A-2 如果订单信息非法，系统通知会员并提示重新提交订单。 A-3 如果订单中产品数量超过产品库存量，则提示会员库存不足，暂无法购买，取消订单同时终止用例。 A-5 如果会员账户余额不足，系统给出相应提示，取消订单并终止用例。
结论	当会员收到系统发送的订单确认页面或其他异常信息时，用例结束。
数据需求	D-1 订单信息包括订单号、参与者的会员账户名、商品种类数量、商品种类名称以及每种商品的数量。
业务规则	B-1 只有当订单中商品信息确认无误后才能要求会员进行支付。

 

 

用例图使用要点

1.构建结构良好的用例。用例图中应该只包含对系统而言必不可少的用例与相关的参与者。

2.用例的名称不应该简化到使读者误解其主要语义的程度。

3.摆放元素时应尽量减少连接线的交叉，以提供更好的可视化效果。

4.组织元素时应使在语义上接近的用例和参与者在图的位置上也同样接近，便于读者5.理解用例图。

5.可以使用注解或给元素添加颜色等方式突出图中相对重要的内容。

6.用例图中不应该有太多的关系种类。

 

 

用例图建模技术

对系统的语境建模

　　识别系统边界。

　　识别参与者。

　　如果需要，将具有相同特征的参与者使用泛化关系加以组织。

　　如果需要，对某些参与者应用一个构造型以便加深理解。

　　将参与者应用到用例图中，并描述参与者与用例间的通信路径。

对系统的需求建模

　　识别参与者。

　　对于某个参与者，考虑其期望系统提供的行为或与系统的交互。

　　将行为提炼成用例。

　　完善其他用例。分解用例中的公共行为与扩展行为，放入新的用例中以供其他用例使用。

　　创建用例图。

　　如果需要，在用例图中添加一些注解或约束来陈述系统的非功能需求。

 

案例（1）学生选课系统

某学校的网上选课系统主要包括如下功能：

      管理员通过系统管理界面进入，建立本学期要开的各种课程，将课程信息保存在数据库中并可以对课程进行改动和删除。

      学生通过客户机浏览器根据学号和密码进入选课界面，在这里学生可以进行三种操作：查询已选课程，选课以及付费。

      同样，通过业务层。这些操作结果存入数据库中。

 

步骤：1。确定系统边界。2.确定参与者（名词）。3.确定用例（动宾结构）。4.确定关系（联系）

 

参与者：学生、教务人员、数据库

用例：选课、查询、支付课时费用、登陆、修改课程、添加课程、删除课程

关系：关联关系、泛化关系