简介面向软件工程专业学生与UML课程设计初学者的课程设计资源以停车场管理系统为载体完整呈现软件系统分析与设计从需求到模型的推进过程可作为选题参考、建模思路借鉴及说明书写模板。压缩包共1个doc文档整包大小249KB内容涵盖功能性需求分析、系统用例图、分析包、类图与对象图以及动态模型中的顺序图、协作图、状态图、活动图并延伸至数据库设计等核心部分章节组织完整目录层级清晰便于按需查阅。已有3474人学习浏览实践参考价值较高。借助文档中的图表与说明文字读者能快速理解UML各类视图在真实业务场景中的落地方式掌握从需求分析到静态与动态建模的完整思考路径也可参照其结构逻辑撰写自己的课程设计说明书完成停车场或同类信息管理系统的分析实践。1. 停车场管理系统是最适合用UML课程设计跑一遍软件系统分析与设计的对象之所以把“停车场管理系统”拿来做 UML 课程设计不是因为业务功能简单而是因为它恰好把软件系统分析与设计中最有价值的几个动作都覆盖到了外部参与者稳定、角色边界清楚、入场到离场的状态流转直观最难得的是计费规则和数据一致性问题足够真实。很多课设项目不是输在不会画图而是把 UML 用成了涂色板类图画得规整却和时序图对不上用例图画得很多却找不到对应的业务对象。这个题目如果按“需求分析 → 静态建模 → 动态建模 → 一致性校验”的顺序来做新手能真正理解 UML 图之间的关系熟手则能快速把一套可评审的设计文档整理出来。2. 从需求边界到UML用例图停车场的参与者、用例描述与include/extend关系2.1 把参与者找全UML用例图才不会画成一锅粥软件系统分析与设计的第一步不是打开 Visio 拖用例图而是站在系统边界之外把所有需要与系统交互的角色列清楚。停车场管理系统的参与者通常有四类车主、值班员、系统管理员和支付网关。车主是发起入场、出场、缴费的主参与者值班员负责处理无牌车、识别异常、手工抬杆和现场巡检系统管理员配置收费标准、车位分区、节假日策略并维护基础数据支付网关作为外部系统承担充值、扣费、退款等动作。数据库不能画成参与者它是系统内部组件但支付网关必须画成参与者因为它的接口行为不受我们控制并且真实存在于系统边界之外。UML用例图表达的是系统对外提供的可观测价值不是内部函数。如果为了让图显得丰富而添加“保存数据”“打印小票”这样的事件系统边界就被破坏了“打印小票”只是“出场缴费成功”这个动作的结果不能独立成为用例。一个典型的课程设计误区是画了二十几个用例语义高度重叠比如“车辆入场登记”和“车辆信息录入”其实是同一个业务事件的两个阶段应该合并成一个用例。下面这张参与者清单可以作为分析起点。参与者交互目的典型业务事件车主进场、离场、支付、查询车辆入场登记、出场缴费值班员处理异常、现场收费、手动抬杆无牌车登记、补缴处理系统管理员配置费率、管理车位、查看统计费率调整、数据报表支付网关资金交易、退款同步在线支付、退款通知2.2 用“车辆入场登记”用例把功能需求写成可评审的文档UML用例图只能放名字和关系真正的业务约束必须靠用例描述来补充。课程设计评审时老师通常不会只看一张用例图而是会追问某个用例的主流程、前置条件和异常分支。针对“车辆入场登记”我会把它写成下面的形式这比直接在图上堆文字更适合归档。用例名: 车辆入场登记 主要参与者: 车主 支持参与者: 入口控制器、支付网关 前置条件: - 入口通道可用 - 车位剩余数量已知 后置条件: - 生成一条有效的停车记录 - 闸机抬杆放行 主流程: - 1. 车主将车辆驶入入口通道 - 2. 入口控制器调用车牌识别服务 - 3. 系统查询当前剩余车位数 - 4. 系统生成“已入场”停车记录 - 5. 系统向闸机发送抬杆指令 - 6. 车主通过闸机落杆 扩展流: - 3a. 剩余车位为0: 系统不抬杆并提示停车场已满 - 4a. 车牌识别失败: 系统转入人工录入并要求抓拍一张车辆照片这段描述里的前置条件和后置条件就是实现阶段事务边界要处理的状态扩展流则直接决定类图和时序图里需要增加哪些分支保护。例如“剩余车位为0”这个分支要求业务层先做并发核对再更新车位数量不能只靠前端按钮置灰。把用例描述写到这个粒度后续画 UML 类图时就不会漏掉方法写代码的人也不需要再猜隐藏规则。2.3 include 和 extend 的关系怎么画停车计费场景怎么连UML用例图的难点不在画图而在 include 和 extend 的取舍。include 表示主用例一定会调用被包含的用例作为复用片段出现extend 表示在满足扩展点条件时才插入一段补充行为。“车辆入场登记”必须检查剩余车位所以“查询剩余车位”是被 include 的车辆停在免费时间内不需要走“计费”分支只有超过免费时段才触发“停车计费”因此计费相对“出场缴费”是一个 extend 扩展。用 PlantUML 表达这段关系能让关系更紧凑startuml left to right direction actor 车主 as D actor 值班员 as A rectangle 停车场管理系统 { usecase 车辆入场登记 as UC1 usecase 查询剩余车位 as UC2 usecase 出场缴费 as UC3 usecase 停车计费 as UC4 usecase 无牌车人工登记 as UC5 } D -- UC1 D -- UC3 A -- UC5 UC1 .. UC2 : include UC1 .. UC5 : extend UC3 .. UC4 : include enduml注意这里的箭头方向include 指向被包含的用例extend 从扩展用例指向基础用例。很多初学的课设都把 extend 画反了导致“人工登记”反过来依赖“入场登记”语义混乱。实际开发时扩展点需要在基础用例中声明例如在“车辆入场登记”的第 2 步之后插入“车牌识别异常”扩展点如果不用 extend值班员入场和车主入场就是两条完全独立的消息系统的可复用性会下降。对于停车场管理系统我一般只保留两到三组 include/extend 关系其他分支交给时序图和状态图去表达避免用例图信息超载。3. 用UML类图和UML包图把停车场管理系统的静态结构定下来3.1 用名词筛选法从需求描述中找UML类图的根类从用例描述进入类设计时最简单的方式是做名词筛选把需求文本里的业务名词全部抄出来再去掉纯属性词剩下的就是候选类。比如“车牌号”“入场时间”“金额”适合做成属性“停车位”“停车记录”“计费规则”适合做成类。停车场管理系统常见的实体类有 ParkingLot、ParkingSpace、ParkingTicket、Vehicle、ChargeRule控制类有 EntryController、ParkingService、BillingService边界类有登录窗口、入场界面、管理看板。课程设计如果想体现编程语言视角可以给核心类写一个精简骨架UML类图上只保留签名级别的内容。对比下面的代码和对应的类图可以快速理解属性与方法如何映射。public class ParkingSpace { private String spaceId; // 车位编号例如 A01 private SpaceState state; // 空闲、占用、锁定 private ParkingTicket currentTicket; // 当前占用凭证 public boolean occupy(ParkingTicket newTicket) { if (this.state ! SpaceState.IDLE) { return false; } this.currentTicket newTicket; this.state SpaceState.OCCUPIED; return true; } public ParkingTicket release() { ParkingTicket finished this.currentTicket; this.currentTicket null; this.state SpaceState.IDLE; return finished; } }这段代码解释了状态设计的关键ParkingSpace 不直接操作车位状态而是通过 occupy 和 release 来保证车位从空闲到占用是原子变化。UML类图里给 ParkingSpace 标记state: SpaceState时SpaceState 要作为枚举类型画成独立依赖而不是写成String state否则状态机表达会失真。release 方法返回当前停车记录是为了让计费服务可以继续调用结算逻辑也避免了让外部直接篡改 ParkingTicket 引用。3.2 UML类图的关联、聚合和组合在停车场里到底怎么区分UML 类图里关联、聚合和组合容易混。关联是平等对象之间的引用比如 EntranceGate 调用 ParkingService两者谁都不拥有谁聚合是整体与部分的关系但部分可以独立存活比如 ParkingLot 持有 1..* 个 ParkingSpace车位拆除后停车场还在组合也是整体与部分但部分不能离开整体独立使用比如 ParkingTicket 包含多个 PaymentRecord删除停车记录时支付明细也一起删除。关系类型停车场场景例子图示标记判断依据关联EntranceController - ParkingService普通实线只传递消息生命周期无关聚合ParkingLot - ParkingSpace空心菱形车位可以单独存在并分配组合ParkingTicket - PaymentRecord实心菱形支付明细依赖票据生命周期绘制 UML 类图时关联的箭头指向被调用方多重性标注在两端。一个 ParkingLot 里有 1..* 个 ParkingSpace一个 ParkingSpace 同一时刻只能被 0..1 张 ParkingTicket 占用这些多重性最终会翻译成数据库外键、列表字段和非空约束。很多课设把聚合和组合滥用明明只是“订单包含商品”这种弱关联也画实心菱形在停车场项目里判断标准很简单删除整体时部分是否必须删除。是则组合否则聚合两个对象仅仅协作则关联。3.3 UML包图课程设计的分层分包与依赖方向UML类图画到十个类以上就需要用包图来管理组织。一个常见的停车场管理系统分层是表示层、业务层、数据访问层、领域模型层。包图不是简单把类塞进文件夹而是要定义包之间的依赖方向避免出现环。startuml package 表示层 { [登录窗口] [管理看板] [入场登记界面] } package 业务层 { [停车服务] [计费服务] } package 数据访问层 { [停车记录仓储] [车位仓储] } package 领域模型 { [ParkingLot] [ParkingSpace] [ParkingTicket] } 登录窗口 -- 停车服务 入场登记界面 -- 停车服务 管理看板 -- 计费服务 停车服务 -- 停车记录仓储 计费服务 -- 车位仓储 停车记录仓储 -- 领域模型 车位仓储 -- 领域模型 enduml依赖方向要保持单一走向表示层只依赖业务层业务层只依赖数据访问层接口领域模型不放业务逻辑。如果出现“数据访问层依赖表示层”的箭头说明数据库层里混入了界面回显逻辑需要把常量或 DTO 抽到领域模型或独立契约包。在课程设计文档中包图还可以配合表格说明每个包内应包含哪些类以及允许被谁依赖。包名主要成员允许的依赖表示层登录窗口、入场登记界面只依赖业务层业务层停车服务、计费服务依赖数据访问层接口数据访问层车位仓储、停车记录仓储依赖领域模型领域模型ParkingLot、ParkingTicket不依赖任何上层4. UML时序图与状态图让停车流程和车位生命周期可执行4.1 UML时序图入场登记过程的消息顺序和激活条UML 类图回答“谁认识谁”时序图回答“谁在什么时刻调用了谁”。停车场管理系统至少要画两张时序图一张给入场登记一张给出场缴费。入场流程建议把外部参与者和内部组件分离避免把数据库访问混在人类角色之间。startuml actor 车主 as D participant 入口控制器 as EC participant 停车服务 as PS database 数据库 as DB D - EC: 车辆驶入车道 EC - EC: 抓拍并识别车牌 EC - PS: 查询剩余车位空间 PS - DB: 读取空闲车位列表 DB -- PS: 返回可用车位 PS - PS: 创建停车记录 PS - EC: 返回入场许可 EC - D: 抬杆放行 enduml这个时序图里需要注意三个细节第一D - EC是外部参与者向系统发起事件是异步进入不必画成数据库访问第二EC - EC表示自调用用小鱼图形标在同一个生命线上表示入口控制器内部做了图像识别第三DB -- PS是虚线返回消息对应同步调用的返回值。Visio 里画这些元素时每条消息都要箭头上写方法名否则这张图就退化成泳道图评审时不如直接看代码列表。从软件系统分析与设计角度看时序图里的每一个参与者都应该是类图里出现过的对象。比如这条消息PS - PS: 创建停车记录对应的应该是 ParkingService 的createParkingTicket()方法而不是凭空冒出一个名叫“记录服务”的生命线。如果类图没有这个方法补充方向优先改类图因为这个时序行为是被用例驱动出来的真实业务路径。4.2 停车位状态图从空闲到占用再到锁定的迁移条件停车场最能体现状态机价值的是停车位的生命周期。UML状态图专门用来描述一个类的状态变化这里以 ParkingSpace 为例状态包含空闲、占用、锁定三个主状态同时把免费时段作为一个守卫条件嵌入。startuml state 空闲 as IDLE state 占用 as OCCUPIED state 锁定 as LOCKED [*] -- IDLE IDLE -- OCCUPIED : vehicleEnter(plateNo) / 记录入场时间 OCCUPIED -- IDLE : vehicleExit() / 产生停车记录 OCCUPIED -- LOCKED : adminLock(spaceId) LOCKED -- OCCUPIED : adminUnlock(spaceId) LOCKED -- IDLE : 清空锁定位 IDLE -- LOCKED : 检修维护 OCCUPIED -- OCCUPIED : timeOverTick() / 更新计费时长 enduml状态迁移写法是事件名[守卫条件]/动作例如vehicleEnter(plateNo) / 记录入场时间表示发生车辆入场事件后状态变为占用并调用类方法记录时间。让车位从占用回到占用而不是直接回空闲是因为超时长计费需要持续刷新当前票据金额状态没有跳回空闲。这个自迁移常常被课程设计漏掉结果状态图只能画出“进一次出一次”的直线无法表达“停车超时”这种业务规则。判断一个状态是否值得画进图里要看它是否影响系统行为空闲车位可被预约占用车位不能重复入场锁定车位计费暂停。如果只是想表达“车停好了”这种瞬时动作不要设状态否则状态图会被事件撑爆。4.3 跨图一致性时序图消息要对应类图方法状态图动作不能悬空画完 UML 用例图、类图、时序图和状态图后最重要的不是单张图好看而是四张图能够互相印证。一致性检查通常会做三条时序图里的每条消息类图对应类要有一个可访问的方法状态图的每个状态至少要被一个类属性承载用例图中的每个用例都应该有一张时序图或活动图作为支撑。检查项从哪张图出发关闭到哪张图高频问题消息到方法时序图类图calculateFee()无目标状态到枚举状态图类图state 字段用了字符串用例到流程用例图时序图用例无交互描述事件到操作状态图类图转移动作找不到方法我在检查时会按“消息名方法名”来做时序图中的PS - PS: 创建停车记录必须能在类图 ParkingService 中找到createParkingTicket。如果暂时没有对应方法先不要删时序图而是回看类图把缺失方法补上如果这个方法会让类承担过多职责就需要拆分控制类。状态图里的动作也一样vehicleExit()需要对应到 ParkingSpace 的 release 操作而不是直接改状态属性这样状态机才是在驱动设计而非事后作图。5. 用Visio画UML类图的实操顺序与课程设计一致性自检5.1 在Visio里画UML类图的操作路线“用Visio怎么画UML类图”这个搜索词背后通常是模板选错。Visio 里不要从“基本框图”拖几个矩形出来当类矩形没有属性区和操作区后续举多重性时还要手工画线既慢又容易散。我会按下面的顺序操作打开 Visio在类别里选“软件和数据库”找到“UML 模型图”模板从“UML 静态结构”模具中拖入“类”形状双击形状进入属性编辑在“属性”和“操作”列表里直接输入字段和方法签名可见性用-、、#表示私有、公有和受保护再拖出“关联”“聚合”或“组合”连接线把两个类连接起来双击连接线设置端点多重性和角色名。提示Visio 的 UML 模型图不是画布它能保留类名、属性类型和操作签名修改类名时连接线仍会保持引用。如果只是画矩形加直线后续调整属性就需要全部重画这也是很多课设图前后对不上的根源。画完一组类后建议把关联线上的箭头方向统一为“调用方指向被调用方”多重性写清楚这样可以直接对照后续的时序图。例如 ParkingSpace 与 ParkingTicket 的关联箭头从 ParkingSpace 指向 ParkingTicket多重性写0..1表示一个车位对应 0 到 1 张未结算票据这块如果漏了数据库设计时外键就容易放错位置。5.2 课程设计交稿前的一致性自检交稿前我会做一遍“图名互查”重点检查三处第一用例图的主流程关键词是否和时序图的生命线名称一致“车辆入场登记”不能一会儿写成“入场登记”一会儿写成“车辆登记”第二时序图中的每个方法名是否能在类图对应类中找到找不到就补类图第三状态图里的每个状态动作类图成员方法是否绑定。对于 UML 包图还要检查依赖方向只要出现数据访问层依赖表示层就要回看类名把界面相关的 DTO 移到领域模型或独立契约包。用同一套命名把图形串起来是这套设计里最便宜的改进。我一般会建一个术语映射表比如“停车记录”是所有图中统一名称字段名用ParkingTicket状态用已入场/已离场把别名叫法全部替换掉Visio 里只改一次就能保证文档在答辩时不出现自相矛盾。整理出一张只有十几行的术语对应表评审老师在这个表上停留的时间往往比看完整套图还要长。本文还有配套的精品资源点击获取 停车场管理系统UML课程设计：用例图、类图、时序图与状态图建模全解析
简介面向软件工程专业学生与UML课程设计初学者的课程设计资源以停车场管理系统为载体完整呈现软件系统分析与设计从需求到模型的推进过程可作为选题参考、建模思路借鉴及说明书写模板。压缩包共1个doc文档整包大小249KB内容涵盖功能性需求分析、系统用例图、分析包、类图与对象图以及动态模型中的顺序图、协作图、状态图、活动图并延伸至数据库设计等核心部分章节组织完整目录层级清晰便于按需查阅。已有3474人学习浏览实践参考价值较高。借助文档中的图表与说明文字读者能快速理解UML各类视图在真实业务场景中的落地方式掌握从需求分析到静态与动态建模的完整思考路径也可参照其结构逻辑撰写自己的课程设计说明书完成停车场或同类信息管理系统的分析实践。1. 停车场管理系统是最适合用UML课程设计跑一遍软件系统分析与设计的对象之所以把“停车场管理系统”拿来做 UML 课程设计不是因为业务功能简单而是因为它恰好把软件系统分析与设计中最有价值的几个动作都覆盖到了外部参与者稳定、角色边界清楚、入场到离场的状态流转直观最难得的是计费规则和数据一致性问题足够真实。很多课设项目不是输在不会画图而是把 UML 用成了涂色板类图画得规整却和时序图对不上用例图画得很多却找不到对应的业务对象。这个题目如果按“需求分析 → 静态建模 → 动态建模 → 一致性校验”的顺序来做新手能真正理解 UML 图之间的关系熟手则能快速把一套可评审的设计文档整理出来。2. 从需求边界到UML用例图停车场的参与者、用例描述与include/extend关系2.1 把参与者找全UML用例图才不会画成一锅粥软件系统分析与设计的第一步不是打开 Visio 拖用例图而是站在系统边界之外把所有需要与系统交互的角色列清楚。停车场管理系统的参与者通常有四类车主、值班员、系统管理员和支付网关。车主是发起入场、出场、缴费的主参与者值班员负责处理无牌车、识别异常、手工抬杆和现场巡检系统管理员配置收费标准、车位分区、节假日策略并维护基础数据支付网关作为外部系统承担充值、扣费、退款等动作。数据库不能画成参与者它是系统内部组件但支付网关必须画成参与者因为它的接口行为不受我们控制并且真实存在于系统边界之外。UML用例图表达的是系统对外提供的可观测价值不是内部函数。如果为了让图显得丰富而添加“保存数据”“打印小票”这样的事件系统边界就被破坏了“打印小票”只是“出场缴费成功”这个动作的结果不能独立成为用例。一个典型的课程设计误区是画了二十几个用例语义高度重叠比如“车辆入场登记”和“车辆信息录入”其实是同一个业务事件的两个阶段应该合并成一个用例。下面这张参与者清单可以作为分析起点。参与者交互目的典型业务事件车主进场、离场、支付、查询车辆入场登记、出场缴费值班员处理异常、现场收费、手动抬杆无牌车登记、补缴处理系统管理员配置费率、管理车位、查看统计费率调整、数据报表支付网关资金交易、退款同步在线支付、退款通知2.2 用“车辆入场登记”用例把功能需求写成可评审的文档UML用例图只能放名字和关系真正的业务约束必须靠用例描述来补充。课程设计评审时老师通常不会只看一张用例图而是会追问某个用例的主流程、前置条件和异常分支。针对“车辆入场登记”我会把它写成下面的形式这比直接在图上堆文字更适合归档。用例名: 车辆入场登记 主要参与者: 车主 支持参与者: 入口控制器、支付网关 前置条件: - 入口通道可用 - 车位剩余数量已知 后置条件: - 生成一条有效的停车记录 - 闸机抬杆放行 主流程: - 1. 车主将车辆驶入入口通道 - 2. 入口控制器调用车牌识别服务 - 3. 系统查询当前剩余车位数 - 4. 系统生成“已入场”停车记录 - 5. 系统向闸机发送抬杆指令 - 6. 车主通过闸机落杆 扩展流: - 3a. 剩余车位为0: 系统不抬杆并提示停车场已满 - 4a. 车牌识别失败: 系统转入人工录入并要求抓拍一张车辆照片这段描述里的前置条件和后置条件就是实现阶段事务边界要处理的状态扩展流则直接决定类图和时序图里需要增加哪些分支保护。例如“剩余车位为0”这个分支要求业务层先做并发核对再更新车位数量不能只靠前端按钮置灰。把用例描述写到这个粒度后续画 UML 类图时就不会漏掉方法写代码的人也不需要再猜隐藏规则。2.3 include 和 extend 的关系怎么画停车计费场景怎么连UML用例图的难点不在画图而在 include 和 extend 的取舍。include 表示主用例一定会调用被包含的用例作为复用片段出现extend 表示在满足扩展点条件时才插入一段补充行为。“车辆入场登记”必须检查剩余车位所以“查询剩余车位”是被 include 的车辆停在免费时间内不需要走“计费”分支只有超过免费时段才触发“停车计费”因此计费相对“出场缴费”是一个 extend 扩展。用 PlantUML 表达这段关系能让关系更紧凑startuml left to right direction actor 车主 as D actor 值班员 as A rectangle 停车场管理系统 { usecase 车辆入场登记 as UC1 usecase 查询剩余车位 as UC2 usecase 出场缴费 as UC3 usecase 停车计费 as UC4 usecase 无牌车人工登记 as UC5 } D -- UC1 D -- UC3 A -- UC5 UC1 .. UC2 : include UC1 .. UC5 : extend UC3 .. UC4 : include enduml注意这里的箭头方向include 指向被包含的用例extend 从扩展用例指向基础用例。很多初学的课设都把 extend 画反了导致“人工登记”反过来依赖“入场登记”语义混乱。实际开发时扩展点需要在基础用例中声明例如在“车辆入场登记”的第 2 步之后插入“车牌识别异常”扩展点如果不用 extend值班员入场和车主入场就是两条完全独立的消息系统的可复用性会下降。对于停车场管理系统我一般只保留两到三组 include/extend 关系其他分支交给时序图和状态图去表达避免用例图信息超载。3. 用UML类图和UML包图把停车场管理系统的静态结构定下来3.1 用名词筛选法从需求描述中找UML类图的根类从用例描述进入类设计时最简单的方式是做名词筛选把需求文本里的业务名词全部抄出来再去掉纯属性词剩下的就是候选类。比如“车牌号”“入场时间”“金额”适合做成属性“停车位”“停车记录”“计费规则”适合做成类。停车场管理系统常见的实体类有 ParkingLot、ParkingSpace、ParkingTicket、Vehicle、ChargeRule控制类有 EntryController、ParkingService、BillingService边界类有登录窗口、入场界面、管理看板。课程设计如果想体现编程语言视角可以给核心类写一个精简骨架UML类图上只保留签名级别的内容。对比下面的代码和对应的类图可以快速理解属性与方法如何映射。public class ParkingSpace { private String spaceId; // 车位编号例如 A01 private SpaceState state; // 空闲、占用、锁定 private ParkingTicket currentTicket; // 当前占用凭证 public boolean occupy(ParkingTicket newTicket) { if (this.state ! SpaceState.IDLE) { return false; } this.currentTicket newTicket; this.state SpaceState.OCCUPIED; return true; } public ParkingTicket release() { ParkingTicket finished this.currentTicket; this.currentTicket null; this.state SpaceState.IDLE; return finished; } }这段代码解释了状态设计的关键ParkingSpace 不直接操作车位状态而是通过 occupy 和 release 来保证车位从空闲到占用是原子变化。UML类图里给 ParkingSpace 标记state: SpaceState时SpaceState 要作为枚举类型画成独立依赖而不是写成String state否则状态机表达会失真。release 方法返回当前停车记录是为了让计费服务可以继续调用结算逻辑也避免了让外部直接篡改 ParkingTicket 引用。3.2 UML类图的关联、聚合和组合在停车场里到底怎么区分UML 类图里关联、聚合和组合容易混。关联是平等对象之间的引用比如 EntranceGate 调用 ParkingService两者谁都不拥有谁聚合是整体与部分的关系但部分可以独立存活比如 ParkingLot 持有 1..* 个 ParkingSpace车位拆除后停车场还在组合也是整体与部分但部分不能离开整体独立使用比如 ParkingTicket 包含多个 PaymentRecord删除停车记录时支付明细也一起删除。关系类型停车场场景例子图示标记判断依据关联EntranceController - ParkingService普通实线只传递消息生命周期无关聚合ParkingLot - ParkingSpace空心菱形车位可以单独存在并分配组合ParkingTicket - PaymentRecord实心菱形支付明细依赖票据生命周期绘制 UML 类图时关联的箭头指向被调用方多重性标注在两端。一个 ParkingLot 里有 1..* 个 ParkingSpace一个 ParkingSpace 同一时刻只能被 0..1 张 ParkingTicket 占用这些多重性最终会翻译成数据库外键、列表字段和非空约束。很多课设把聚合和组合滥用明明只是“订单包含商品”这种弱关联也画实心菱形在停车场项目里判断标准很简单删除整体时部分是否必须删除。是则组合否则聚合两个对象仅仅协作则关联。3.3 UML包图课程设计的分层分包与依赖方向UML类图画到十个类以上就需要用包图来管理组织。一个常见的停车场管理系统分层是表示层、业务层、数据访问层、领域模型层。包图不是简单把类塞进文件夹而是要定义包之间的依赖方向避免出现环。startuml package 表示层 { [登录窗口] [管理看板] [入场登记界面] } package 业务层 { [停车服务] [计费服务] } package 数据访问层 { [停车记录仓储] [车位仓储] } package 领域模型 { [ParkingLot] [ParkingSpace] [ParkingTicket] } 登录窗口 -- 停车服务 入场登记界面 -- 停车服务 管理看板 -- 计费服务 停车服务 -- 停车记录仓储 计费服务 -- 车位仓储 停车记录仓储 -- 领域模型 车位仓储 -- 领域模型 enduml依赖方向要保持单一走向表示层只依赖业务层业务层只依赖数据访问层接口领域模型不放业务逻辑。如果出现“数据访问层依赖表示层”的箭头说明数据库层里混入了界面回显逻辑需要把常量或 DTO 抽到领域模型或独立契约包。在课程设计文档中包图还可以配合表格说明每个包内应包含哪些类以及允许被谁依赖。包名主要成员允许的依赖表示层登录窗口、入场登记界面只依赖业务层业务层停车服务、计费服务依赖数据访问层接口数据访问层车位仓储、停车记录仓储依赖领域模型领域模型ParkingLot、ParkingTicket不依赖任何上层4. UML时序图与状态图让停车流程和车位生命周期可执行4.1 UML时序图入场登记过程的消息顺序和激活条UML 类图回答“谁认识谁”时序图回答“谁在什么时刻调用了谁”。停车场管理系统至少要画两张时序图一张给入场登记一张给出场缴费。入场流程建议把外部参与者和内部组件分离避免把数据库访问混在人类角色之间。startuml actor 车主 as D participant 入口控制器 as EC participant 停车服务 as PS database 数据库 as DB D - EC: 车辆驶入车道 EC - EC: 抓拍并识别车牌 EC - PS: 查询剩余车位空间 PS - DB: 读取空闲车位列表 DB -- PS: 返回可用车位 PS - PS: 创建停车记录 PS - EC: 返回入场许可 EC - D: 抬杆放行 enduml这个时序图里需要注意三个细节第一D - EC是外部参与者向系统发起事件是异步进入不必画成数据库访问第二EC - EC表示自调用用小鱼图形标在同一个生命线上表示入口控制器内部做了图像识别第三DB -- PS是虚线返回消息对应同步调用的返回值。Visio 里画这些元素时每条消息都要箭头上写方法名否则这张图就退化成泳道图评审时不如直接看代码列表。从软件系统分析与设计角度看时序图里的每一个参与者都应该是类图里出现过的对象。比如这条消息PS - PS: 创建停车记录对应的应该是 ParkingService 的createParkingTicket()方法而不是凭空冒出一个名叫“记录服务”的生命线。如果类图没有这个方法补充方向优先改类图因为这个时序行为是被用例驱动出来的真实业务路径。4.2 停车位状态图从空闲到占用再到锁定的迁移条件停车场最能体现状态机价值的是停车位的生命周期。UML状态图专门用来描述一个类的状态变化这里以 ParkingSpace 为例状态包含空闲、占用、锁定三个主状态同时把免费时段作为一个守卫条件嵌入。startuml state 空闲 as IDLE state 占用 as OCCUPIED state 锁定 as LOCKED [*] -- IDLE IDLE -- OCCUPIED : vehicleEnter(plateNo) / 记录入场时间 OCCUPIED -- IDLE : vehicleExit() / 产生停车记录 OCCUPIED -- LOCKED : adminLock(spaceId) LOCKED -- OCCUPIED : adminUnlock(spaceId) LOCKED -- IDLE : 清空锁定位 IDLE -- LOCKED : 检修维护 OCCUPIED -- OCCUPIED : timeOverTick() / 更新计费时长 enduml状态迁移写法是事件名[守卫条件]/动作例如vehicleEnter(plateNo) / 记录入场时间表示发生车辆入场事件后状态变为占用并调用类方法记录时间。让车位从占用回到占用而不是直接回空闲是因为超时长计费需要持续刷新当前票据金额状态没有跳回空闲。这个自迁移常常被课程设计漏掉结果状态图只能画出“进一次出一次”的直线无法表达“停车超时”这种业务规则。判断一个状态是否值得画进图里要看它是否影响系统行为空闲车位可被预约占用车位不能重复入场锁定车位计费暂停。如果只是想表达“车停好了”这种瞬时动作不要设状态否则状态图会被事件撑爆。4.3 跨图一致性时序图消息要对应类图方法状态图动作不能悬空画完 UML 用例图、类图、时序图和状态图后最重要的不是单张图好看而是四张图能够互相印证。一致性检查通常会做三条时序图里的每条消息类图对应类要有一个可访问的方法状态图的每个状态至少要被一个类属性承载用例图中的每个用例都应该有一张时序图或活动图作为支撑。检查项从哪张图出发关闭到哪张图高频问题消息到方法时序图类图calculateFee()无目标状态到枚举状态图类图state 字段用了字符串用例到流程用例图时序图用例无交互描述事件到操作状态图类图转移动作找不到方法我在检查时会按“消息名方法名”来做时序图中的PS - PS: 创建停车记录必须能在类图 ParkingService 中找到createParkingTicket。如果暂时没有对应方法先不要删时序图而是回看类图把缺失方法补上如果这个方法会让类承担过多职责就需要拆分控制类。状态图里的动作也一样vehicleExit()需要对应到 ParkingSpace 的 release 操作而不是直接改状态属性这样状态机才是在驱动设计而非事后作图。5. 用Visio画UML类图的实操顺序与课程设计一致性自检5.1 在Visio里画UML类图的操作路线“用Visio怎么画UML类图”这个搜索词背后通常是模板选错。Visio 里不要从“基本框图”拖几个矩形出来当类矩形没有属性区和操作区后续举多重性时还要手工画线既慢又容易散。我会按下面的顺序操作打开 Visio在类别里选“软件和数据库”找到“UML 模型图”模板从“UML 静态结构”模具中拖入“类”形状双击形状进入属性编辑在“属性”和“操作”列表里直接输入字段和方法签名可见性用-、、#表示私有、公有和受保护再拖出“关联”“聚合”或“组合”连接线把两个类连接起来双击连接线设置端点多重性和角色名。提示Visio 的 UML 模型图不是画布它能保留类名、属性类型和操作签名修改类名时连接线仍会保持引用。如果只是画矩形加直线后续调整属性就需要全部重画这也是很多课设图前后对不上的根源。画完一组类后建议把关联线上的箭头方向统一为“调用方指向被调用方”多重性写清楚这样可以直接对照后续的时序图。例如 ParkingSpace 与 ParkingTicket 的关联箭头从 ParkingSpace 指向 ParkingTicket多重性写0..1表示一个车位对应 0 到 1 张未结算票据这块如果漏了数据库设计时外键就容易放错位置。5.2 课程设计交稿前的一致性自检交稿前我会做一遍“图名互查”重点检查三处第一用例图的主流程关键词是否和时序图的生命线名称一致“车辆入场登记”不能一会儿写成“入场登记”一会儿写成“车辆登记”第二时序图中的每个方法名是否能在类图对应类中找到找不到就补类图第三状态图里的每个状态动作类图成员方法是否绑定。对于 UML 包图还要检查依赖方向只要出现数据访问层依赖表示层就要回看类名把界面相关的 DTO 移到领域模型或独立契约包。用同一套命名把图形串起来是这套设计里最便宜的改进。我一般会建一个术语映射表比如“停车记录”是所有图中统一名称字段名用ParkingTicket状态用已入场/已离场把别名叫法全部替换掉Visio 里只改一次就能保证文档在答辩时不出现自相矛盾。整理出一张只有十几行的术语对应表评审老师在这个表上停留的时间往往比看完整套图还要长。本文还有配套的精品资源点击获取