🎓 总站 🏠 本课目录 01 概述 02 软件过程 03 需求工程 04 系统建模 05 概要设计 06 报告与高可信
软件系统综合课程设计 · 第4章

系统建模与 UML

从 UML 概念出发,系统讲解活动图、用例图、数据流图、类图、对象图、构件图与部署图的元素、关系与画法。

📚 学习进度
0%

🎯学习目标

  • 理解系统建模的概念,掌握统一建模语言 UML 的构成与五种视图;
  • 掌握活动图的元素(起点/终点、活动、转移、分支、分叉汇合、泳道、对象流)与建模方法;
  • 掌握用例图的参与者、用例及三种关系(包含/扩展/泛化)与用例描述;
  • 掌握数据流图 DFD 的四要素与分层画法;
  • 掌握类图(属性/操作/可见性、六种关系、多重性)、对象图、构件图、部署图的阅读与构建。

1系统建模与 UML 概述

模型是对现实世界的简化,是对系统完整的抽象表示。建模是在不同层次上对系统的描述——由于建模者认识、观察角度、建模目的不同,同一事物的模型并不唯一

💡 为什么建模建模是为了更好地理解正在开发的系统。鉴于软件系统复杂性和规模不断增大,需要建立不同的模型对系统各个层次进行描述。

系统模型——对系统全方位、各个方面、不同角度表示的一个集合。系统建模——对系统建立抽象模型的过程,最终用一组规范化的图形符号对系统进行全方位表示:

角度建模内容
外部对系统上下文或系统环境建模
交互对系统与环境之间、或系统各组成部分之间的交互建模
结构对系统的体系结构和系统处理的数据结构建模
行为对系统的动态行为和它对事件的响应方式建模

UML(统一建模语言)

UML(Unified Modeling Language)是软件和系统开发的标准建模语言,主要以图形方式对系统进行分析、设计,是面向对象开发中最常用的建模语言。

🅻

Language 语言

要遵循语法规则的图形语言,贯穿软件开发生命周期,可描述系统不同视图。

🅼

Modeling 建模

表达系统简化视图,便于面向对象软件系统的分析和设计。

🆄

Unified 统一

统一标准的建模语言,被广泛使用;它不是方法论或开发过程,而是语言工具。

⭐ UML 三大用途可视化(利于交流)、构造(可映射成 Java/C++ 代码或数据库表)、文档化(建立需求、体系结构、设计、测试等详细文档)。UML 由 Booch、OMT、OOSE 方法集大成而来,三大创始人为 Booch、Rumbaugh、Jacobson。UML1.0 于 1997 年完成,UML2.0 于 2004 年完成。

常用建模工具:Rational Rose、MS Visio、PowerDesigner、Argo UML、StarUML、Draw.io 等。

2UML 模型构成与五种视图

UML 模型图的构成(三要素)

构成说明
事物最基本的构成元素:结构事物(类、接口、构件)、行为事物(交互、状态机)、分组事物(包)、注释事物(注释)
关系把事物联系在一起:关联、依赖、泛化、聚合、实现
事物和关系的可视化表示

按图的作用可分为:功能描述——用例图;静态结构——类图、对象图;动态行为——时序图、状态图、通信图、活动图;物理架构——构件图、部署图

💡 构造型元素在基元素基础上增加新定义构造的新模型元素,用括在双尖括号 << >> 中的字符串表示,UML 提供 40 多个预定义构造型,如包含 <<include>>、扩展 <<extend>>

UML 的五种视图

视图视图内容静态表现观察角度
用户模型视图(用例视图)系统行为、动力用例图用户、分析员、测试员
结构模型视图(设计视图)问题及解决方案类图、对象图类、接口、协作
行为模型视图(进程视图)性能、可伸缩性、吞吐量类图、对象图线程、进程
实现模型视图(实现视图)构件、文件构件图配置、发布
环境模型视图(实施视图)部件的发布、交互、安装配置图拓扑结构的节点

3活动图(动态视图)

活动图是 UML 动态视图之一,描述参与行为的对象所进行的各种活动的顺序关系,本质上是一种流程图,但有区别:

对比流程图活动图
着重处理过程对象活动的顺序关系所遵循的规则、系统的行为
并发不能表示并发能表示并发活动
面向面向过程面向对象

用途:描述操作执行过程所完成的工作;显示用例实例如何执行动作及改变对象状态;描述哪些步骤顺序执行、哪些并行执行。可用于业务过程、工作流、用例实现乃至程序实现的建模。

活动图基本元素

起点(初始节点,一般唯一) 活动原子活动(圆角矩形) 分支条件判断(菱形) 同步条(分叉/汇合,表并发) 转移(带箭头直线) 终点(一个或多个) 泳道(责任区分组)
图1 · 活动图核心符号:起点、活动、分支、同步条(分叉/汇合)、转移、终点、泳道
▶️

转移

Transition
一个活动结束时控制流马上传递给下一节点,用带箭头直线表示,可连接各活动及特殊活动(初态、终态、判断、同步线)。
🔀

分支

Branch
对同一出发事件,根据不同条件转向不同活动,每个可能的转移是一个分支(菱形判断)。

分叉与汇合

Fork/Join
分叉:一个控制流被两个或多个控制流代替,表示并发;汇合:多个控制流被一个控制流代替。
🏊

泳道

Swimlane
进一步描述完成活动的对象,并聚合一组活动。是分组机制,每个泳道代表一个责任区。
📦

对象节点

Object Node
对象可作为活动的输入或输出,由一个动作产生并被其他动作使用,代表对象在某时刻的值(对象流连接)。
📝

注释体

Note
附加信息,提供对图中元素的额外说明;注释连接明确指出注释体所指向的具体元素。
建模步骤与建议① 寻找业务过程中的活动(工作步骤、各参与者操作、启动事件);② 活动链接(执行顺序、前置条件、分支、并发、依赖);③ 绘制活动图。建议:最好和领域专家当面沟通、访谈中直接绘制;不研究活动细节,捕捉整体业务流程的"大方向"。

4用例图 ⭐(核心考点)

用例模型由 Jacobson 等于 1990 年代提出,主要用来为系统与外部参与者之间的交互建模,是"需求收集及整理"的工具。用例体现了能满足系统外部执行者对系统的"某一个完整期望"。

参与者 系统边界 查询商品 下订单 支付 «include»
图2 · 用例图:参与者(木头人)— 关联 — 用例(椭圆),含包含关系示意

三类基本元素

🧍

参与者 Actor

系统外部、需要使用系统或与系统交互的人或事物所扮演的角色。种类:① 系统用户(人)② 外部系统 ③ 设备。用木头人图标表示。参与者间用泛化描述公共行为。

用例 Use Case

对参与者有价值的功能单元,是一组动作序列的描述。用椭圆表示,是与实现无关的功能描述,一个用例对应一个功能性需求。识别用例最好从分析参与者开始。

用例间三种关系(必考)

🔗

包含 «include»

把若干用例的相同动作提取出来单独构成可重用用例。包含用例必选、无条件,缺少则基用例不完整。箭头由基用例指向被包含用例。

扩展 «extend»

一个用例增强另一用例的行为,用于插入"可选"或"异常"行为。扩展用例可选、有条件,其执行会改变基用例行为。箭头由扩展用例指向基用例。

泛化 Generalization

一般与特殊的关系,子用例是父用例的特殊形式("is a")。发出箭头的是特殊方,箭头指向一般方,子继承父并增加新特征。一个用例有几种变体时使用。
⭐ 包含 vs 扩展(极易混淆)包含:基用例无条件调用包含用例,缺包含用例基用例不完整;扩展:基用例本身完整,有条件调用扩展用例,扩展会改变基用例行为。注意:关联的方向显示的不是信息流动方向,而是谁启动的信息。

识别用例的方法

通过六个问题寻找角色:谁使用主要功能、谁需要系统支持完成日常工作、谁维护管理系统、系统应付哪些外部设备、与哪些外部系统交互、谁对系统结果感兴趣。通过两个问题寻找用例:角色需要系统提供哪些功能、角色是否需对信息进行读/创建/修改/删除/存储。也可将活动图中每个"活动"当作"用例"候选。

用例描述

每个功能按一个用例对待,依据用例模板描述,特别强调基本事件流和扩展事件流及子事件流脚本指贯穿用例的一条单一路径,用例定义可能会发生什么,脚本定义在给定条件下发生了什么。

描述项说明
用例名 / 标识符表明用户意图;唯一标识可被引用
参与者与本用例相关的参与者列表
前置条件 / 后置条件访问用例前 / 完成后必须满足的条件
主事件流(基本流)各项工作均正常时用例的工作方式
可选(扩展)事件流变更工作方式、异常、错误情况下所遵循的路径
被泛化/包含/扩展的用例对应关系的用例列表(子事件流对应包含,扩展事件流对应扩展)

5数据流图 DFD

DFD(Data Flow Diagram)表达了数据和处理的关系。DFD 设计过程就是将数据和处理逐层分解,形成若干层次的 DFD:顶层图、第一层、第二层、第三层图等。在需求分析中,数据驱动模型用来表示系统中端到端的过程(从输入处理开始到相关输出产生)。

四种基本元素

外部实体 加工/处理 数据存储 数据流
图3 · DFD 四要素:外部实体(矩形)、加工(圆/圆角)、数据存储(双线条)、数据流(箭头)
元素含义
外部实体系统外部的数据源点或终点(人、组织、其他系统)
加工(处理)对数据进行的变换处理
数据存储需要保存的数据(文件、数据库、日志等)
数据流数据在系统中流动的路径(带箭头)
分层 DFD 实例:病员监护系统系统功能:① 监视病员病症(血压、体温、脉搏)② 定时更新病例 ③ 异常情况报警 ④ 随机产生病情报告。
  • 顶层图:病员、护士为外部实体,"病员监护系统"为单一加工,"病员日志"为数据存储;数据流有病症信号、要求报告、报警、病症报告。
  • 第一层图:加工分解为"局部监视""中央监视""生成报告""更新日志"。
  • 第二层图:对"中央监视"再分解为"开解信号""计算超过极限值否""产生报警信息""格式化病员数据"。
分层逐步细化是 DFD 的核心思想:上层是下层的抽象,下层是上层的细化。

6类图(静态视图)⭐

UML 中通常用"类图"表达领域模型:分析阶段显示角色和实体职责;设计阶段捕获组成系统体系结构的类结构;编码阶段据此实现系统功能。

类的表示与可见性

类是具有相似结构、行为和关系的一组对象,用三栏矩形表示(类名 / 属性 / 操作)。命名采用 CamelCase(大写字母开头)。

属性格式:[可见性]属性名[:类型]['['多重性[次序]']'][=初始值][{特性}]
操作格式:[可见性]操作名[(参数列表)][:返回类型][{特性}]
例:#visibility:Boolean=false   points:Point[2..* ordered]   +hide():Boolean
符号可见性说明
+公共 public可被任何类访问,提供公共接口
-私有 private只能被定义它们的类访问,封装内部实现
#受保护 protected可被本类及其子类访问
~包级私有 package只能被同一包中的类访问

类的种类:抽象类(不能实例化,名字用斜体,可实现多态)、接口(无具体实现)、关联类(多对多、属性不属于关联两端任何一个类,用虚线连接)、嵌套类(类定义在另一类内部)。

六种关系 ⭐

关联 聚合 组合 泛化 实现 依赖 语义联系(实线) 整体-部分(空心菱形,弱包含) 强聚合(实心菱形,同生命周期) 继承(空心三角,指向父类) 类实现接口(空心三角+虚线) 一方变化影响另一方(虚线箭头)
图4 · 类图六种关系的图形符号与含义

关联

模型元素间的语义联系。有名称(动词)、角色(名词)、多重性、导航性(箭头表示,单/双向关联)。可分一元(自返)、二元、多元关联。

聚合(聚集)

类之间松散的整体-部分关系(特殊关联)。空心菱形。"弱包含":整体没了,部分仍可独立存在。

组合

更强形式的聚合(强聚合)。实心菱形。每个部分只能属于一个整体,整体和部分有相同生命周期;"强包含":整体没了部分也不存在。

泛化

事物间一般与特殊(继承)关系。空心三角箭头指向更一般的类。子类继承超类的属性和操作。

实现

说明元素与实现元素之间的关系;类和接口之间是实现关系(虚线空心三角)。

依赖

一个元素(提供者)的变化将影响另一元素。分四类:使用 «use/call/parameter/send/instantiate»、绑定 «bind»、抽象 «trace/refine/derive»、授权 «access/import/friend»。

多重性

表示含义表示含义
0..10 或 11..*(1..n)1 个或多个
1恰好 18恰好 8
0..*(0..n)/ *0 或多个5,7..105 或 7~10
💡 约束与限定符约束:加在花括号内加强关联含义(如 {ordered} 表有序)。限定符:紧靠源类图标处,将多对多关联转化为多对一关联,是关联的属性而非类的属性。

建立类图的步骤

① 分析问题域,确定需求 → ② 寻找类(用例模型中找名词,借助边界类/控制类/实体类)→ ③ 定义属性和操作 → ④ 确定结构关系(泛化、组合聚合、关联依赖实现)→ ⑤ 精化 → ⑥ 绘制类图。

🚪

边界类

位于系统与外界交界处(窗体、对话框、报表、通讯协议、设备接口类)。每个 actor 至少对应一个边界类,主要位于展现层。

🗄️

实体类

对必须存储的信息和行为建模。通常每个实体类在数据库中有相应表,主要位于数据持久层。

🎛️

控制类

对一个或几个用例特有的控制行为建模,像乐队指挥控制其他对象,向其他类发出很多消息。

7对象图与包图

对象图

对象图是类图的实例,表示一组对象之间的联系,用于各类系统(信息管理、数据库、Web、实时控制)。表示法:对象名后跟冒号加类型名,并使用下划线与类区分(如 张三:Student)。

  • 对象名:矩形框顶端显示;类型:具体的类目;状态:由对象所有属性及运行时当前值组成。
  • 是关联关系的实例,是对象间的独立连接,主要用来导航——链一端的对象可得到另一位置的对象并向其发送消息。

包图

包是 UML 中对模型元素进行组织管理的通用机制,可包含类、用例、接口、组件、节点及其它包等。把语义相近、可能一起变更的元素组织在包里,便于理解复杂系统。

包间联系表示说明
包依赖虚线箭头一个元素定义改变引起另一元素相应改变,虚箭线从依赖包指向独立包
包泛化实线箭头两个包间一般-特殊关系
💡 包名简单名(仅含名称)与路径名(外部包名称::本包名称)。不显示内容时名字放主方框内;显示内容时名字放左上角小方框,内容放主方框。

8构件图与部署图(物理实现图)

UML 中的物理实现图包括构件图部署图两种类型。

构件图

构件图用于静态建模,表示构件类型的组织以及各构件之间的依赖关系,可估计修改构件给系统带来的影响。构件可包括源代码文件、二进制文件、脚本、可执行文件,是系统中可替换的物理部件。

事物含义
构件系统中可替换的物理部分,提供一组接口实现(矩形)
接口外部可访问到的服务
构件实例节点实例上构件的一个实例(冒号后是实例名)
实现关系构件向外提供的服务
依赖关系构件依赖外部提供的服务(由构件到接口)

部署图(配置图)

部署图用于静态建模,表示运行时处理节点结构、构件实例及其对象结构,帮助了解软件各组件驻留在什么硬件上及硬件间关系。含依赖关系的构件实例放在不同节点上时,可展示执行瓶颈。部署图通常包含 2 个元素:节点关联关系

客户机 Web 服务器 数据库服务器 «HTTP» «TCP»
图5 · 部署图:节点用立方体表示,节点间用关联关系(实线)连接,连接方式用构造型标注
节点分类说明举例
处理器 Processor能执行软件、具有计算能力的节点PC 机、服务器、工作站
设备 Device没有计算能力的节点,通过接口提供服务打印机、扫描仪、路由器

关联关系:表示各节点间通信路径(一条实线),一般不用名称而用构造型表示连接方式,如 «Ethernet»«local»«TCP»«HTTP» 等。

重点例题

例题1:画学生成绩管理用例图 用例:登录、找回密码、录入、修改、保存、查询、删除成绩;参与者:教师与学生。 分析:① 教师与学生通过泛化抽取公共用例(登录、查询);② "登录"与"找回密码"可建立扩展关系(找回密码是登录失败时的可选行为);③ 录入/修改成绩都需要"保存",可抽取为包含用例。 关键点:先识别参与者再识别用例;公共行为用泛化或包含提取;可选/异常行为用扩展。
例题2:ATM 取款用例描述 主事件流:① 输入提款金额(每日不超 3000 元、单次不超 1500 元)② 提取现金 ③ 退卡。 扩展事件流:1.a 金额超 1500 元;1.b 当日超 3000 元;1.c 账户余额不足;1.d ATM 现金不足;1.e 任意步骤可取消退出。 关键点:主事件流写"各项工作正常"路径,每句用肯定句;扩展流是主干的"分支"(如 2a、2b),异常和限额校验都属扩展流。
例题3:判断类图关系类型 给出"汽车—车轮""公司—部门""学生—课程""动物←狗"四组: 汽车-车轮:组合(实心菱形,车轮随汽车销毁);公司-部门:聚合(空心菱形,部门可独立重组);学生-课程:多对多关联(多重性 *..*);动物←狗:泛化(空心三角,狗 is-a 动物)。 判断口诀:"整体没了部分还在"=聚合;"同生共死"=组合;"is a"=泛化;"实现接口"=实现(虚线三角)。

🎯自测(点击展开)

UML 模型图由哪三要素构成?
事物(结构/行为/分组/注释事物)、关系(关联、依赖、泛化、聚合、实现)、图(事物和关系的可视化表示)。
活动图与流程图的本质区别是什么?
活动图能表示并发活动、是面向对象的、着重表现系统行为;流程图不能表示并发、面向过程、着重处理过程。活动图用分叉和汇合建模并发。
用例图中"包含"和"扩展"关系有何区别?
包含:基用例无条件调用,缺包含用例则基用例不完整;扩展:基用例本身完整,有条件调用扩展用例,扩展会改变基用例行为(用于可选/异常行为)。
DFD 的四种基本元素是什么?
外部实体、加工(处理)、数据存储、数据流。DFD 通过逐层分解形成顶层图、第一层、第二层等分层结构。
类图中聚合和组合有何区别?
聚合是松散的整体-部分(空心菱形),整体消失部分可独立存在;组合是强聚合(实心菱形),部分只属于一个整体,整体和部分有相同生命周期。
UML 中四种可见性符号分别代表什么?
+ 公共(任何类可访问)、- 私有(仅本类)、# 受保护(本类及子类)、~ 包级私有(同包内的类)。

📝强化题库

选择题点选即时判分;填空题输入后"检查"或"显示答案"。

已答 0/0答对 0正确率
已答 0/0答对 0