简介这份演示文稿资源面向软件工程、系统分析与设计课程师生以超市进销存系统为案例完整展示UML建模过程。内容围绕销售、库存、订货、统计四大业务域展开销售部分拆解从开单、输入商品、计算总价到打印清单、保存购买记录的完整流程并讨论包含关系与商品、购买记录两个实体类的属性设计库存部分覆盖盘点、报损、入库及查询场景并用扩展、包含关系表达例外流程订货部分涉及供应商数据库更新和订货单生成统计部分讨论促销与调价策略。资源还演示了销售场景中边界类、控制类与实体类的协作划分以及“订货单”对象的状态图帮助读者理解由需求描述推导用例图、顺序图、类图、状态图的完整路径。压缩包内为1个pptx文件容量仅369KB已有271人学习浏览可作为课程作业、UML复习或系统设计实践的参考。1. 超市进销存系统进行UML建模先立边界再画图需求评审会上店长说“我要能看库存”于是团队给出一张库存表等系统上线才发现店长要的是“进货时能扫条码自动入库、退货时能走红冲、盘点时能一键复制账面数”。超市进销存系统的问题从来不是表格不够多而是角色、流程、状态各说各话。UML建模在这里的价值不是交出一套好看的图而是强迫你把“谁在什么场景下做哪件事、这件事牵动哪些数据与状态”逐一说清。本文以一套单店总部两级的超市进销存为贯穿案例按用例图、类图、状态图、时序图、活动图、包图的顺序走完一遍建模并给出PlantUML与Visio两种落地写法。适合正在做课程设计、毕业设计或真实进销存立项的开发者参考即使你打算用现成框架开发先跑一遍UML流程也能把需求文档里的漏洞提前炸出来。2. 用例图先行把超市进销存的业务边界定下来2.1 角色识别谁在向系统发起动作先别急着画图把角色竖着列在系统边界框外面。超市进销存最常见的角色有收银员、采购员、仓库管理员、店长、财务以及系统外部的供应商。每种角色在用例图里是一个小人名称用业务称谓而不是平台账号因为建模要的是“谁拥有这个动作”不是“谁登录了系统”。收银员销售、退货、挂单、交班结算。采购员创建进货单、提交订货申请、验收入库。仓库管理员盘点、报损、库位调整、库存预警处理。店长调价、审批采购单、查询毛利、导出日报。供应商对账、处理退货。要注意一个容易犯的边界错误把“系统管理员”当成用例图里的超级角色。系统管理员只负责账号和权限不参与业务动作它应该出现在部署图或组件图里而不是进销存的用例视图里。用例图一旦塞进“管理用户”这类用例业务边界就被打散了。2.2 用例粒度用“一句业务价值”检验用例是否合格用例的粒度没有一个绝对标准但有一个很实用的检验办法每个用例必须能用一句话说清它给角色带来的业务价值。比如“进货入库”可以拆成“采购员将到货商品登记入库”这是合格用例“数据库写入”就不是业务用例“维护商品信息”也偏模糊。典型的新手问题是把系统操作当用例例如“扫条码”“打印小票”“点击按钮”这些属于步骤应该被归进用例的描述里而不是独立成用例。真正需要独立成用例的通常是带独立业务规则、独立触发条件、独立结果的工作流。在超市进销存里我一般会拆出这样一组核心用例角色用例触发条件业务结果采购员进货验收供应商送货到店库存增加生成入库流水采购员采购退货到货质量不合格库存不增退货单传给供应商收银员销售结算顾客结账库存扣减生成销售明细收银员售后退货顾客凭小票退货库存回调退款登记仓管库存盘点周期盘点或抽查账面数与实盘数差异生成盘点差异单店长调价审批促销或临期处理价格变更生效覆盖收银终端2.3 画用例图的三个关系include、extend、泛化怎么选用例之间不是画几条线就行。这三个关系用错后续看图的开发就会误解流程。include包含表示每次执行都必须走的一步。“销售结算”始终要“计算会员优惠”吗如果会员系统是必选模块就用include箭头从主用例指向被包含用例。如果有些分店不支持会员就不应写成include而该写成可选的决策分支。extend扩展表示在特定条件下才会走的补充流程。“销售结算”在“商品无库存导致下单失败”时会触发“缺货登记”这就是extend。扩展点在用例描述里要标注清楚什么条件、插在哪个步骤之后。这里的判断标准是去掉这段扩展路径主流程依然能独立成立。泛化则用于角色或用例的继承关系。“收银员”与“仓库管理员”都是“门店员工”可以抽象出一个父参与者但要注意如果两者共享的只是“登录系统”这一动作那不值得做泛化直接让它们各自关联自己独有的用例即可。进销存系统里最容易出现泛化滥用的是“商品”这类概念生鲜商品、非生鲜商品、赠品确实存在差异但差异只在类图层面体现用例层面一般不需要拆泛化。2.4 用例图落地方案PlantUML还是Visio用例图是沟通图不是交付图所以工具选择取决于团队习惯。如果项目在Git仓库里管理我习惯用PlantUML文本化、可diff评审时改起来快startuml left to right direction actor 采购员 as p actor 收银员 as c actor 仓库管理员 as w actor 店长 as s rectangle 超市进销存 { usecase 进货验收 as UC1 usecase 采购退货 as UC2 usecase 销售结算 as UC3 usecase 售后退货 as UC4 usecase 库存盘点 as UC5 usecase 调价审批 as UC6 UC3 .. UC4 : extends p -- UC1 p -- UC2 c -- UC3 w -- UC5 s -- UC6 } enduml这段语法里actor定义参与者usecase定义用例rectangle内是系统边界..表示扩展关系--表示参与者与用例的关联。需要注意箭头是从参与者发向用例方向错了读起来就别扭。Visio画法类似新建“UML用例”模具把参与者拖到边界框外用例拖到框内用“扩展”连接线连接用例对用“关联”连接参与者和用例。用例图完成后要一起评审重点看两个问题角色是否真能完成它关联的用例用例之间是否包含了流程分支。评审过了才进入领域模型设计否则类图改起来成本更高。3. 类图与状态图让商品、库存、单据落地为领域模型3.1 从用例图提取候选类的两种方法类图不是照抄数据库表设计目标是让阅读者一眼看出业务规则落在哪个类上。提取候选类有两种常用做法名词法从用例描述中圈出业务名词职责法从每个用例中找出“谁发出动作、谁记录结果”。对超市进销存两者结合效果更好。商品描述SKU的基本档案含名称、规格、条码、零售价、进货价。库存流水记录每次入库、出库、盘点的数量变化。库存按商品仓库维度保存当前结存数、冻结数。进货单与进货明细采购员提交的进货主体明细保存每行商品数量。销售单与销售明细结算时的主体与明细。供应商、客户往来对象。盘点单记录盘点时间、盘点人、账面数、实盘数、差异数。报损单记录破损、过期商品的处理结果。提取完成后先别急着画线把每个类的职责写成一两句注释。比如“库存”类的职责是“维护商品在指定仓库的实时数量与可用数量进货增加、销售扣减、盘点调整”。如果两个候选类职责重叠说明它们该合并或其中一个只是另一个的属性。3.2 关联、聚合、组合的取舍一张表说清进销存类图里最常错的是把关联关系全部画成实线箭头。画连线前先用业务事实判断生命周期如果整体不存在时部分同时失去意义就是组合如果整体与部分可以各自存活只是逻辑归属就是聚合如果只是临时产生引用就是普通关联。以进货单与进货明细为例删除进货单时明细必然一并删除这是组合商品与库存则是聚合删除商品档案不意味着删除历史库存流水审计要求流水永久保留。关系生命周期约束进销存案例图示记号组合部分随整体销毁进货单与进货明细实心菱形在整体端聚合整体与部分独立仓库与库存记录空心菱形在整体端关联临时引用互相独立销售单引用收银员普通实线或箭头依赖仅方法参数级引用报表服务使用库存查询结果虚线箭头多重性标识也要按业务仔细写一个商品可以对应0到多条库存流水记为1..*一张进货单对应至少一条明细记为1..*一个商品只归属一个主分类记为*..1。新手常把多重性方向写反务必记住数字写在离谁近就表示谁这一侧的基数。3.3 状态图必须盯住订单与库存类图给出静态结构状态图补上动态约束。进销存里最值得画状态图的不是“商品”而是“进货单”“销售单”“盘点单”。以进货单为例状态机可以定义为草稿 → 已提交 → 已审核 → 部分入库 → 完成入库 → 已冲销。状态图的每个转移都要标注事件与守卫条件比如从“已审核”到“部分入库”需要触发“到货验收”事件守卫条件是“当前入库数量小于单据数量且大于0”。如果只画一张状态图优先画“库存”的状态演化可用、冻结、已出库、已报损。销售下单时先冻结、结算成功才真正扣减这是避免超卖的关键状态设计。很多超市系统把库存状态省成一个整数导致并行下单和退货时数据错乱根因就是状态欠建模。3.4 用Visio怎么画UML类图三个步骤和两个坑热搜里“用visio怎么画uml类图”指向的其实是具体操作路径。Visio最关键的环节不在画线在于加载对模具打开Visio点击“类别 → 软件和数据库 → UML类”拖出“类”形状双击填入属性与方法选中类形状右键可添加属性属性区用-表示私有、表示公有、#表示受保护。类画好后从“UML类”模具拖出“关联”“聚合”“组合”等连接线从一个类拖到另一个类线性连接后右键“设置多重性”把基数设为1、*等。两个常见坑需要提醒。第一不要用手绘的箭头代替“UML关联”模具否则导出图片后箭头形状不标准别人无法判断关系类型。第二多重性默认显示在两端但很多人改完一端忘记改另一端读图时把1..*看反导致代码生成时外键放错表。画完后建议把所有“组合”线用实心菱形确认一遍再把图上每个多重性与数据库外键策略比对一次。类图和状态图评审时邀请开发与测试一起看重点问如果销售单已结算、正在退货此时库存被冻结还是被回调如果两个答案不一致说明状态机缺失事件。这一步值得多花时间后面写代码时少一次返工。4. 时序图与活动图验证核心流程是否走得通4.1 时序图销售结算与进货入库的两种典型交互类图定完结构后时序图负责回答“面向对象的调用顺序到底长什么样”。画时序图的要点是选对参与者参与者和系统之间是业务消息系统内部是方法调用二者不要混在同一层。以“销售结算”为例标准时序是收银员发起结算销售单创建随后系统扣减库存、记录流水最后收银员完成收款系统回写支付结果。用PlantUML表达如下startuml actor 收银员 as C participant 销售单 as SO participant 库存 as ST participant 库存流水 as FLOW C - SO: 扫描商品并创建销售单 SO - ST: 扣减库存(商品, 数量) ST - FLOW: 写入出库流水(数量, 类型销售) SO -- C: 返回可用库存结果 C - SO: 提交收款完成 enduml这段图要重点检查一个细节扣减库存前是否查询可用数。在时序图里应当体现为“查询冻结库存”再“扣减”如果直接一步扣减就要在评审时指出并发风险。第二个细节是库存流水必须在库存扣减成功后写入顺序反了会导致流水比实际库存多一条。进货入库的时序则简单一些但要注意“验收”与“入库”两步之间的回滚语义。完整的时序是采购员提交到货信息系统核对进货单状态逐项写入库存流水更新库存结存最后标记进货单为“部分入库”或“完成入库”。时序图的价值就是把这三步的顺序和回滚条件画清楚避免把更新状态写到流水之前。4.2 活动图退货与盘点要画分支泳道活动图适合表达带分支、并发、循环的流程。超市进销存最典型的是“售后退货”和“库存盘点”。画退货活动图时按角色分泳道收银员、系统、财务。收银员录入退货单后系统先判断该销售单是否存在且未完全退货再判断退货商品是否有库存异动最后走“原路退款”或“线下退款”两个分支。画分支的要点在每个判断节点都写清决策条件不能只画一个菱形写“是否有效”。盘点活动图则要体现并发仓库管理员提交盘点单后系统同时做两件事——冻结库存快照、生成盘点明细实盘数录入完成后系统比较账面数与实盘数生成差异单再走店长审批。活动图里用水平粗线表示并发开始、粗线合并表示汇聚这两处要核对是否成对出现否则执行模型会卡死或提早结束。在活动图与用例图的关系上活动图可以补充用例描述里的备选流但仍应以用例图为纲一个用例只对应一张主活动图。不要把“进货验收”和“采购退货”画进同一张活动图里除非它们共享同一个流程分支混在一起后阅读者很难判断入口条件。4.3 视图一致性时序图与类图之间的对应规则绘制时序图的另一个重要任务是反向验证类图而不是把时序图当作独立图种看待。验证规则有两条时序图里出现的方法名必须存在于类图对应类的方法区时序图里的对象名必须能在类图的实例化关系中找到。如果不满足说明类图缺少方法或关联方向错了。反过来说如果类图里某个类的方法很多却没有出现在任何时序图里那大概率是设计掩埋了业务逻辑。比如“库存调整”方法在类图中存在但所有流程都没有调用它应该回查是遗漏了“报损”用例还是这个方法是多余的。画完核心流程的时序图与活动图后建议做一次“流程回读”不看代码按时序图走一遍手工模拟角色执行一步按类图更新一次状态。这个动作能找出时序上无法到达的死路比任何静态检查都有用。5. 建模收尾包图、组件图与可验证的建模纪律用例、类、状态、时序都齐了接下来划分模块边界。超市进销存按业务域可以拆成四个包catalog商品档案与调价、inventory库存流水、盘点、报损、purchase进货单与供应商、sales销售单与退货。拆包原则是包间依赖单向、循环依赖为零。让inventory包不反向依赖purchase包——即使进货单需要更新库存调用方向也是purchase指向inventory底层包独立于上层。验证依赖关系有个很实用的清单先看用例图里的角色是否都被类图覆盖再看每个用例的主流程能否在时序图中走通接着检查每个类的生命周期是否由组合关系表达最后看包图依赖是否有环。我一般用CRC卡片做一轮快速走查每张卡片正面写类名、背面写职责与协作对象把卡片按流程排列检查每个协作对象是否真实需要。CRC卡不需要工具几张便签就够了但能减少后续重构成本。工具选型上团队协作建议用PlantUML或Mermaid管理文本图源配合Git记录改动最终交付设计文档时再用Visio产出正式图因为Visio的线型、字号、页面排版能力更强。如果直接用Visio建模记得开启“UML验证”功能可以检测出关联未命名、多重性缺失等基础问题并设置“工具 → 加载项 → UML验证”完成后导出PDF归档。散落各处的截图不算版本建模成果应当与需求文档、数据库设计文档一样纳入同一版本管理目录。UML图如果有新评审意见先改用例图再改类图最后调整时序图顺序反了会让图与图之间的矛盾难以追踪。图不是越多越好够覆盖业务边界即可。本文还有配套的精品资源点击获取