DC's blog
DC
2024-08-31
目录

UML养成记

该篇博文总结自b站UML图的绘制的视频合集:
https://space.bilibili.com/401005217/channel/collectiondetail?sid=2783244

★★★ UML各种图的应用场景(我自己的理解,不一定正确

需求分析: 用例图 [关联｜泛化｜包含｜扩展]
数据表设计: 根据需求分析/用例图 分析得到 类图! [泛化｜关联(n:n 聚合 组合)｜依赖｜实现]
请求的链路: 时序图 eg系统中的登陆模块
某个功能(用例图中的某个用例)实现的具体逻辑: 活动图<可简单理解为流程图>
类图中某个类的状态: 状态图 <类对象的状态和状态转换关系>

- 一定要清楚,类图的类属性和操作,它是动态的,会根据需求的细化动态调整!!
- 强调, 应对复杂性, 鉴于用例可能包含多种事件流, 单一顺序图难以覆盖所有分支和循环逻辑.   
  因此根据不同事件流构建多个顺序图是常见的做法, 确保所有场景被细致描绘! <顺序图也叫做序列图>
1
2
3
4
5
6
7
8
9

★★★ 一些画图经验

★ 关于用例图, 一般自己画, 用语雀的文本绘图来画用例图 其语法有点麻烦, 画出来的图也不好看,不好调整.   
  用例图, 不要过分纠结严格的关系, ["能通过用例图将项目需求讲清楚即可!!"] 这是画用例图的目的. 
★ 关于时序图中 约束条件, 复杂的就不用画了,那些都是代码细节,画了反而不利于图的阅读.. ["在图中表明好请求调用的链路即可!!"]    
  所以时序图 我们一般会用 语雀来画..   
★ 关于通信图, 有了时序图就没必要画通信图了, 在对象交互方面, 时序图更能简单明了的体现项目流程是怎么调用的.
★ 关于活动图, 若用例图中用太多的文本来描述复杂的业务流程会让人难以阅读和理解.这时,使用活动图能清晰明了的描述业务的活动流程!
★ 关于状态图, 状态图描述一个对象在生命周期里的行为. 状态图相较于活动图,有明确的状态转换关系时,用状态图更便于理解!!
1
2
3
4
5
6
7

# 介绍两个工具

# draw.io

官网地址: drawio.com
一个使用小技巧, 可以把常用的元素 放到便签里.. 方便画图!!

# 下载

image-20240831170101823

# 使用模版

(3种方式) - 以时序图为例.
-1- 在下载的软件中创建.
-2- 在官网中, 选择后, 离线使用.
-3- 在官网中, 下载, 利用本地下载好的draw.io软件打开.

image-20240831170156041

# 官网的使用介绍

image-20240831170530965

# 语雀

码即是图, 图亦是码!!
若想深入plantuml的语法,可以访问 https://plantuml.com/zh/sequence-diagram

步骤: 打开语雀-新建文档后-选择文本绘图-PlantUML(选择一个UML图 eg:序列图).

# 类图

# 类的结构与可见性

类是对一组具有相同属性、操作、关系和语义的对象的抽象.
主要包括名称部分（Name）、属性部分（Attribute）和操作部分（Operation）. 在UML中类用一个矩形框表示, 它包含3个区域, 最上面是类名,中间是类的属性,最下面是类的方法.

+-------------------+
|     Person        |
+-------------------+
| - name: String    |
| - age: int        |
+-------------------+
| + getAge(): int   |
+-------------------+
1
2
3
4
5
6
7
8

类中操作的可见性主要包括: 公有(Public)、私有(Private)、受保护(Protected) 和 包内公有(Package).
在UML中, 公有类型用+表示, 私有类型用 - 表示, 受保护类型则用 # 表示, 而包内公有类型用 ～ 表示.

- 私有的属性和方法只能在其所在的类中被访问;
- 公共的属性和方法则可以被任何类访问;
- 受保护的属性和方法只能被同一个类或其子类访问;
- 默认的属性和方法可以在同一个包中的任何类中被访问.
1
2
3
4

# 类的关系

# 概念层面的类图

◎ 何为概念图? 即图中没有把类字段描述出来.

image-20240903082001754

  • 泛化关系/继承关系
    子类指向父类, 这些子类可以继承父类的属性和方法, 并添加自己特有的属性和方法.
    eg: 书籍分为小说和非小说
  • 关联关系
    • 1:1 、 1:n 、n:n
    • 聚合 大难临头各自飞. 表示整体和部分关系的关联,但部分可以独立于整体存在.
      eg:一个图书馆可以有很多本书,但书可以在没有图书馆的时独立存在.
    • 组合 同生死,共进退. 表示部分不能独立于整体存在.
      eg:图书馆里有很多房间,图书馆没了,这些房间也就没了.
  • 依赖关系 eg: 书籍依赖于图书分类系统来决定图书的类别
  • 实现关系 有点抽象类的概念/多态. eg: 定义一个接口Fly(表示会飞),然后定义一个类Bird实现该接口.
- 若类A仅在其方法 Method1 中定义并使用了类B的一个对象,类A其他部分的代码都不涉及类B
  那么类A与类B的关系应为 _（依赖）_
- 若类A 的某个属性是 类B的一个对象,并且类A 对象消失时,类B对象也随之消失
  则类A与类B 的关系应为 _(组合）_
1
2
3
4
# 图书管理系统类图

image-20240903084951670

Ps: 那个writes表示, 作者与书之间联系的动词是 写与被写.

- 继承关系: 用子类指向父类的空心三角型表示.
- 关联关系:
  - UML使用星号 * 来代表多个(many). 两点代表或关系, 例如:
    - 1 : 一个
    - * : 零个或多个
    - 1..* : 一个或多个
    - 0..1 : 零个或一个
  - 聚合关系 空心棱形表示
  - 组合关系 实心棱形表示
- 依赖关系: 虚线表示
- 实现关系: 图中没有,是用 虚线加空心三角形表示. （继承是实线加空心三角形
1
2
3
4
5
6
7
8
9
10
11

# 用例图 - 图书管理系统

图书管理系统需求描述

1. 图书借阅功能: 系统支持线上线下无缝对接的借阅流程,读者可通过线上平台预约选书,并可在指定地点完成线下取书手续;
               同时保留传统现场借书方式,确保各类用户群体的便捷使用.
2. 图书归还管理: 系统实时跟踪图书归还状态,允许用户在线预约归还时间并提醒,同时也支持图书馆内直接办理归还手续.
3. 图书检索服务: 提供详尽的图书查阅功能,用户可以按照书名、作者、分类等多种维度快速定位所需书籍.
               获取书籍基本信息、馆藏位置以及当前借阅状态等.
4. 逾期提醒与罚款机制: 系统具备智能逾期提醒功能,自动发送短信或邮件通知用户及时归还图书;
                    对于超过规定期限未归还的图书,系统将依据预设规则计算超期罚款,并协助执行相应扣款流程.
5. 图书遗失与损坏处理.
1
2
3
4
5
6
7
8

如何图形化的把需求点简单明了的列举出来呢? 用UML用例图.. 接下来,先生硬的了解一些UML用例图的概念.

# 用例图 - 参与者

-1- 参与者是系统外的一个实体, 它代表了与系统交互的用户、设备或另一个系统.
-2- 参与者是系统服务的对象,通过向系统输入信息或系统为参与者提供信息来进行交互,以实现系统功能.
-3- 在用例图中,参与者由固定的图形表示,并在参与者下面列出参与者的角色名.

那么如何辨别有哪些参与者呢? 通过思考一下几个问题来判定:
1> 系统的服务对象是谁 / 也就是谁会使用系统?
2> 谁来管理系统?
3> 系统需要与哪些其他系统进行交互?

# 用例图 - 用例

-1- 用例是一个叙述型的文档, 用来描述参与者使用系统完成的事件. -2- 在UML中, 用例用一个椭圆来表示, 用例的名称写在椭圆的内部.

# 用例图 - 关系

-1- 关联关系: 参与者与用例间的关系.
-2- 泛化关系: 参与者间或用例间的关系, 类似于 继承 关系, 可以重载. 分为泛化用例、泛化参与者.
-3- 包含关系: 用例与用例的关系, 将复杂的用例分解成小的步骤用例. 相当于拆分 可重用 的功能.
-4- 扩展关系: 用例间的关系.
扩展关系是一种依赖关系, 它指一个用例可以增强另一个用例的功能, 是把新的行为插入到已有用例中的方法.
严谨点来说 包含关系: 必须做的; 扩展关系: 特定条件下触发的..

image-20240902111520992

注: 上方的用例图是基于借阅人的角度的用例.. 其实整个系统还有很多参与者的哦!

简单注意几点:

1. 思考借阅人通过图书管理系统能完成什么功能? - 还书、借书、查询图书.
2. 还书和借书里拆分出一个可重复利用的单独实例. - 超期处理（若超期了就不能借书了;还书时,超期了也需要处理!
3. 借书的两种种类. - 线上借书、线下借书 (继承关系
4. 对超期处理的扩展功能/增强功能. - 通知超期、缴纳罚款.
   类似于设计模式中的装饰器模式.这里的通知超期和缴纳罚款都不是超期处理必须执行的,只有当符合条件时才会执行.
1
2
3
4
5

# 时序图

UML 时序图也叫做 顺序图、序列图..

# 示例一 锁车

image-20240902145154337

简单阐述下逻辑

CarOwner对象、CarKey对象、Car对象 -- 车主人、车钥匙、车
> 车主人 getButtonPress(b)  获取车钥匙的按钮信息,这里按的是b, 将该交互信息给了 车钥匙.
> 车钥匙 PressKeyMessage(b) 将按下的b传递给 车.
> 车 判断 若传的b是block,那么会自调用,调用lock锁车操作.
  车 返回给车主人 两个信号,闪灯和轰鸣 表示锁车成功!!
1
2
3
4
5

# 示例二 搜索商品

image-20240902093343549

注: 图中,商品界面对象使用矩形包裹的, 别误会了..

# 示例三 前后端分离架构

这里我们用语雀 画一个 前后端分离的架构图..

image-20240902145836464

示例中的PlantUML代码如下: 

@startuml

autonumber

actor "用户" as User
participant "浏览器" as Browser
participant "前端服务器" as Front_Server #orange      
participant "后端服务器" as Back_Server #green 
database "数据库" as DB #lightblue    


activate User
User -> Browser: 输入 URL
activate Browser

Browser -> Front_Server: 发送请求
activate Front_Server

Front_Server --> Browser: 返回 HTML、css、js
note left of Front_Server: 页面空荡荡的,没有数据
deactivate Front_Server

Browser -> Back_Server: 发送ajax请求
activate Back_Server

Back_Server -> DB: 访问数据库
activate DB

DB --> Back_Server: 返回数据
deactivate DB

Back_Server -> Back_Server: 进行数据处理
Back_Server --> Browser: 返回json  
deactivate Back_Server

Browser -> Browser: 将得到的数据\n渲染在页面上     
Browser --> User: 展示页面
deactivate Browser

@enduml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# 示例四 招考公务员

某市进行招考公务员工作, 分行政、法律、财经3个专业. 
【市人事局】<公布>所有【用人单位】<招收>各专业的人数,【考生】<报名>,【招考办公室】<发放>准考证. 
<考试>结束后,【招考办公室】<发放>考试成绩单,<公布>录取分数线,针对每个专业,分别将考生按总分从高到低<排序>. 
【用人单位】根据排序名单<录用>,<发放>录用通知书给考生,并给【招考办公室】<留存>备查. 
请根据以上情况进行分析,画出顺序图.

- 解题良策: 【】找名次; <> 找动词.
1
2
3
4
5
6
7

image-20240903110958276

# 通信图 - 锁车

表示对象间的交互关系, 除了时序图, 还有通信图.. 时序图情调交互的时间顺序; 通信图强调交互的情况..
一般情况下, 在系统开发过程中, 有了时序图就没必要画通信图了, 所以, 对于通信图,简单了解下就行啦!!

通信图相较于时序图, 通信图无生命线, 没有对象的创建和撤销..

image-20240902115424103

# 活动图

先来简单认识下 活动图中的这些元素代表啥意思.

image-20240902151850216

简单的举三个生活中的例子, 快速了解怎么画活动图.

image-20240902152147514

# 状态图

简单的举三个生活中的例子, 快速了解怎么画状态图.

两步骤:
-1- 确认对象的主要状态.
-2- 确认状态直接的转换关系.

image-20240902185330465

对上图中使用手机的状态图进行一个阐述.

当手机开机时,它处于空闲状态,当用户使用电话呼叫某人时,手机进入拨号状态.
如果呼叫成功,即电话接通,手机就处于通话状态;如果呼叫不成功,例如,对方线路有问题或关机,则拒绝接听,这时手机停止呼叫,重新进入空闲状态.
手机在空闲状态下被呼叫,手机进入响铃状态;如果用户接听电话,手机处于通话状态;
如果用户未做出任何反应,可能他没有听见铃声,手机一直处于响铃状态;如果用户拒绝来电,手机回到空闲状态.
1
2
3
4

# 综合案例 - 机票预定系统

# 系统概述

机票预订系统是一个允许用户在线查询航班、购票、管理行程及退票的平台.
- 系统区分了访客（未登录用户）与注册用户的功能权限: 
  访客仅能浏览航班信息,而注册用户在登录后,还能进行购票、查看已购机票以及退订操作.
- 此外,系统内置了与 外部信用评价系统 的接口,该接口用于监控用户退票行为.
  若用户一个月内退票超过两次,其在信用评价系统中的等级会下调,信用等级过低时m系统将限制其继续购票.
1
2
3
4
5

# 用例图

三步走: 确定参与者 - 确定用例 - 确定用例间关系

image-20240903100207667

# 类图

三步走: 确定类元素 - 添加类的属性与操作 - 确定关系.

image-20240903103241058

★ 通过用例图 分析出类元素/确定系统的核心类
  - user用户: 代表使用系统的个人.具有查询、购票、退票等功能.
  - Adminstrator管理员: 负责管理航班信息,具有最高权限.
  - Airport机场: 提供航班起降点信息.
  - Flight航班: 包含航班的具体信息,出发地、目的地、时间等.
  - Ticket机票
  - TicketManagement票务管理系统
  TicketManagement作为控制器协调系统中各个实体用户、管理员、航班等之间的工作.
★ 定义类的属性与操作以及确定类关系.
1
2
3
4
5
6
7
8
9

☆一定要清楚, 图中未添加类属性和操作,根据业务场景自行添加 且它是动态的,会根据需求的细化动态调整!!

# 顺序图

顺序图是强大的可视化工具,它表达了用例和类之间的交互序列.. 系统的设计和功能实现往往需要多个顺序图.
接下来. 我们详细探讨下如何为 "机票预定系统的登陆功能" 绘制顺序图. 借此加深对系统交互流程的理解.

image-20240903105407711

☆ 再次强调, 应对复杂性, 鉴于用例可能包含多种事件流, 单一顺序图难以覆盖所有分支和循环逻辑.
因此根据不同事件流构建多个顺序图是常见的做法, 确保所有场景被细致描绘!

# 状态图

状态图是一种描述复杂状态以及行为(转换关系)的重要工具. 以机票预定系统中的 Flight航班类 为例, 逐步解析状态图的创建步骤.

image-20240903112217548

# 活动图

活动图作为一种强大的可视化工具, 可以清晰的展示系统中各参与对象的活动序列以及控制流.
该案例中, 我们聚焦于机票预定系统的购票流程, 为其绘制活动图.

image-20240903114110505

# 构件图

image-20240903114529900

# 部署图

image-20240903114612503

大模型
one

← one→

最近更新
01
卷积神经网络
01-17
02
过拟合与欠拟合的处理
01-16
03
Mnist分类任务
01-16
更多文章>
Theme by Vdoing | Copyright © 2023-2025 DC | One Piece