简介这份PDF是图书馆管理系统的UML建模资料面向软件工程、系统分析与设计课程的学习者与课程设计者用于掌握用例图、活动图、类图、时序图等核心建模工具的实际运用。压缩包内共1个PDF文件大小1.55MB内容以图文方式呈现完整建模过程。资源从图书馆系统的需求分析入手先说明系统目标、功能需求与性能要求再围绕读者管理、书籍管理、借阅管理、系统管理展开随后重点讲解动态建模包括管理员与读者的用例图、借书/还书/罚款时序图、借书/还书/预订活动图、书籍状态图以及包括reader、admin、Title、Item等类的类图每个图都配有文字说明便于理解对象间交互和状态变化。全流程案例既能帮助读者快速看懂系统各模块的建模思路也可作为课程报告、毕业设计的参考模板。该资源已有414人学习适合需要借助具体案例熟悉UML建模方法的读者。1. 图书馆管理系统四张UML图为什么值得你认真画完“图书馆管理系统用例图、活动图、类图、时序图.pdf”——这个文件名几乎是软件工程课程设计和项目答辩里出现频率最高的交付物。我见过太多人拿到“图书馆管理系统”这个题目后第一反应是打开 IDE 写图书增删改查等代码写完了再回头补 UML 图结果要么四张图连不在一起要么图画出来只有自己能看懂。这里想先给一个反直觉的结论这四张图不是给老师交差用的几张纸而是把需求、数据结构和业务流程串成一条线真正先画图的人后面的代码基本不会翻车。这篇文章写给谁软件工程专业的学生、刚转开发的从业者以及维护老系统时补文档无从下手的人。2. 用例图与活动图先把“谁在用”和“流程怎么走”定死2.1 用例图先找参与者再列用例最后才画椭圆很多人拿到用例图第一笔画一个椭圆写“图书管理”再画一个椭圆写“借阅管理”最后在中间放一个“系统”小人。这张图拿去给老师看或者交到头歌这类软件工程实训平台上通常会被打回来你把功能菜单当成用例把系统自己当成了使用者。用例图建模的第一步永远是找参与者也就是系统边界外、直接和系统交互的人或外部系统。图书馆管理系统最典型的参与者是读者和图书管理员如果系统还承担逾期罚款计算、预约到馆通知定时任务这个外部触发源也可以画成一个参与者。判断标准就一句话它是发起点不是功能模块系统本身绝不能出现在参与者一栏。确定参与者之后再从每个参与者的业务目标列用例。读者关心的是查询图书、借书、还书、续借、预约图书管理员关心的是图书管理、读者管理、借阅记录管理、逾期罚款处理。用例一律用“动词名词”命名不要写“图书管理”这种名词短语因为用例描述的是业务目标不是功能模块。用例之间还有三个常用关系借书前必须做读者身份验证这个步骤每次都要且被多个用例复用用 include预约图书是借书到馆后的补充动作并不是每次借书都会发生用 extend如果读者还要区分学生、教职工可以画泛化关系子类继承父类参与的用例。这些关系才是用例图和功能清单之间最大的区别。谈到近几年的工具变化“用例图ai生成”确实能快速给你一版漂亮的图但它通常会把参与者边界画糊include/extend 也经常漏掉。我一般只用它出初稿最后人工逐个校一遍重点看“系统”有没有混进参与者、扩展方向有没有反。下面是一份可以直接抄走的 PlantUML 用例图包含两个参与者和一张带 include/extend 关系的用例清单startuml left to right direction actor 读者 as reader actor 图书管理员 as admin rectangle 图书馆管理系统 { usecase 查询图书 as UC_QUERY usecase 借书 as UC_BORROW usecase 还书 as UC_RETURN usecase 预约图书 as UC_RESERVE usecase 身份验证 as UC_AUTH usecase 管理图书 as UC_ADMIN_BOOK usecase 处理逾期罚款 as UC_FINE } reader -- UC_QUERY reader -- UC_BORROW reader -- UC_RETURN reader -- UC_RESERVE UC_BORROW . UC_AUTH : include UC_RETURN . UC_AUTH : include UC_RESERVE . UC_BORROW : extend admin -- UC_ADMIN_BOOK admin -- UC_FINE enduml语法上actor 定义参与者usecase 定义用例-- 表示参与者与用例之间的关联. 配合 include/extend 表示用例间关系。值得注意的参数是 include 的虚线箭头从主用例指向被包含用例extend 则从扩展用例指向被扩展用例方向一反过来语义就完全错了这也是工具自动生成时最常出的问题。left to right direction 控制图的横向布局参与者多时可以让用例图更紧凑。2.2 活动图一个用例一张图重点画“分支”和“并发”用例图回答“谁做了什么”不回答“具体步骤是什么”。活动图就是补这一步的一个核心用例配一张活动图图中出现开始节点、活动节点、判断节点、结束节点如果流程里有多条同时执行的路径还要用分叉和汇合节点表达并发。常见做法是图书馆管理系统只画借书、还书、预约三张活动图其余用例用文字描述带过。画活动图最容易踩的坑是把它当普通流程图。普通流程图允许分支各自收尾活动图不能这样画活动图强调分支之后必须汇合否则无法表达“这些分支最后都要回到主流程”。借书用例里既有读者证状态判断又有库存判断分支汇合点一旦画错后面类图和时序图会连锁出错。借书流程的主分支先列出来读者提交借书申请、系统校验读者证状态、查询图书库存如果读者证正常且库存充足创建借阅记录、扣减库存、通知读者取书否则分别提示读者证异常或库存不足。用 PlantUML 活动图表示startuml start :读者提交借书申请; :系统校验读者证状态; if (读者状态正常?) then (是) :查询图书库存; if (库存充足?) then (是) :创建借阅记录; :扣减库存; :通知读者取书; else (否) :提示库存不足; endif else (否) :提示读者证异常; endif stop enduml语法上start 和 stop 定义流程起点与终点以冒号开头、分号结尾的语句生成活动节点if/else/endif 生成判断节点和汇合节点。这里容易被忽略的参数是 if 后面括号里的文字它是判断条件会显示在菱形节点里“是”和“否”是分支标签会显示在分支箭头上。这类文字建议用业务语言写“库存充足”不要写“stock 0”否则业务方和答辩老师都看不懂。活动节点也是同理写“创建借阅记录”不要写“insert into borrow_record”活动图描述业务动作不是代码执行步骤。如果流程里需要并行比如“借书成功后同时扣减库存和发送通知”就用分叉线和汇合线把两条活动包在中间PlantUML 里是 fork 与 end fork。2.3 活动图画几张才够优先级排序以“分支多、状态多”为先很多同学交上来的活动图是把系统里每个功能全画一遍这既浪费时间答辩时还容易暴露漏洞。我一般按这个优先级排序借书流程必画它是系统核心且有读者证校验、库存校验两层分支还书必画它涉及逾期判断和罚款分支不画会漏掉业务规则预约图书如果系统功能里有建议画因为它有预约列表和到馆通知的状态流转查询图书、登录注册这类用例分支太少可以不画活动图。换个角度看网上商城用例图、学生成绩管理系统用例图的画法都是同一套用例图定范围活动图给主流程里分支最多的场景画到有判断、有汇合就比凑满十张无意义图更有说服力。我见过不少实训平台上的作业扣分点往往不是画得少而是每张图都停留在“三个框一条线”的水准既没有判断也没有并行。记住图的完整度比数量重要一张能讲清楚分支和异常的活动图比十张白开水图都值钱。3. UML类图怎么画才不返工实体类、三种箭头与可复现样例3.1 从用例和流程中筛出实体类图书、读者、借阅记录类图是四张图里最容易被过度设计的一张。很多人的类图画了十几个类每个类带二十个属性结果写代码时一个都没用上。图书馆管理系统的类图不需要大而全需要的是“能落库、能对应方法调用”。我画类图通常不从名词列表硬推而是从用例图和活动图倒着筛先看用例图里参与者操作了什么名词图书、读者、借阅记录、罚款、预约单再看活动图里出现过什么数据“创建借阅记录”“扣减库存”“生成预约”。这些名词和动词就是类图的第一批候选类和方法。筛类时我会用一个简单表格过一遍候选类关键属性关键方法是否保留图书ISBN、书名、作者、馆藏数量查询库存、扣减库存要核心实体读者读者证号、姓名、读者类型借书、还书、续借要核心实体借阅记录记录编号、借出日期、应还日期创建记录、更新还书要承载借还流程图书管理员工号、姓名管理图书、审核借阅按需有权限管理才保留出版社名称、地址、联系电话无可省避免类图膨胀图书管理--不是类是控制功能筛选标准是类必须同时有“属性可描述状态”和“方法可响应消息”。像出版社这种实体如果系统没有“按出版社统计馆藏”的需求就别让它进类图否则后续建表多一张表、代码多一套维护。属性类型也建议在设计阶段标清楚ISBN 用 String因为国家标准号可能带字母馆藏数量用 Integer日期统一写 Date不绑定具体语言类型。不管后端用 Java 还是 C类图都是“类名、属性、方法”三段式C 类图和 Java 类图画法没有区别差别只在类型映射方式。方法名尽量从活动图分支条件里来比如“库存是否充足”对应查询库存“创建借阅记录”对应创建记录这些方法名会被第 4 章的时序图直接引用命名必须全篇统一。3.2 类图的各种箭头关联、聚合、组合、依赖、继承怎么选类图的难点不在类本身在“类图的各种箭头”。很多人卡在工具里那一排关系按钮不知道选哪个尤其是一边搜 StarUML 类图怎么画一边对着代码反向生成。这里先把结论放出来真正能交作业、能指导建表的类图关系必须由业务语义决定不是由工具默认决定的。我平时判断关系用下面这张表关系UML 符号生命周期关系图书馆管理系统里的例子关联实线可加箭头双方独立只是发生业务联系读者与借阅记录之间的“拥有”聚合空心菱形实线菱形在整体端整体没了部分还能独立存在图书馆与图书馆撤了书还在流通体系里组合实心菱形实线菱形在整体端整体没了部分跟着没借阅记录与借阅明细记录删除明细没意义依赖虚线箭头指向被依赖方方法参数或返回值用到对方借阅控制器依赖数据库访问对象继承空心三角实线三角指向父类“是一种”的关系读者是父类学生、教职工是子类两个最容易翻车的地方第一聚合和组合的菱形必须画在“整体”那一端很多人拖关系时选反菱形跑到部分类那边答辩时一眼就会被看出来第二继承箭头是子类指向父类的空心三角不是实线直箭头实线直箭头是普通关联混用会让整张图含义全变。判断口诀我一般这么教同生共死是组合死后还活着是聚合只是认识是关联用到就走是依赖是一个就是继承。以借阅记录和借阅明细为例删除借阅记录时明细数据没有业务价值所以是组合图书和馆藏副本更接近聚合因为单本图书可以被调拨到其他馆馆不存在书本身仍能被其他机构接收。3.3 一份可复现的类图PlantUML 代码与表结构对照下面这份类图是图书馆管理系统最小可用版本包含三个核心实体和一个控制类。代码可以直接在 PlantUML 环境里跑得到一张带可见性标注和多重性关系的类图我平时给别人的建议是拿它当模板改属性、加方法比从空白画布开始快很多。startuml class 读者 { -读者证号 : String -姓名 : String -读者类型 : String -联系电话 : String 借书() 还书() 续借() } class 图书 { -ISBN : String -书名 : String -作者 : String -馆藏数量 : Integer 查询库存() 扣减库存() } class 借阅记录 { -记录编号 : String -借出日期 : Date -应还日期 : Date -归还日期 : Date 创建借阅记录() 更新还书() } class 借阅控制器 { 借书(读者, 图书) 还书(读者, 图书) } 读者 1 -- 0..* 借阅记录 : 拥有 图书 1 -- 0..* 借阅记录 : 被借 借阅控制器 .. 借阅记录 : 创建 endumlclass 关键字定义类类名后的大括号里先写属性再写方法“-”表示私有可见性“”表示公有可见性工具绘制时会在属性前面显示小锁或加号这也是评审时经常看的一个点。关系部分读者与借阅记录之间用一条普通关联线并标上多重性 1 和 0..表示一个读者可以有多条借阅记录借阅控制器对借阅记录用虚线箭头表示依赖而不是关联依赖是最弱的关系只发生在方法调用瞬间。多重性是最值得调的参数读者端写 1借阅记录端写 0..图书与借阅记录时同一本书有多个副本在流通借阅记录端写 0..图书端写 1..。多重性写错数据库外键设计会跟着错按 book_id 查历史借阅记录时会查出歧义数据。这张类图落到数据库的关系很直白实体类对应表属性对应字段关系对应外键借阅记录表要放 reader_id 和 book_id 两个外键就是上面两条关系线翻译来的。如果你用 StarUML 画操作步骤其实就三步左侧工具栏拖出 Class双击维护属性、类型和可见性再从关系面板选择 Association、Aggregation、Composition。不用在意版本差异这三个关系按钮在哪个版本都有。IntelliJ IDEA 里右键类名选 Diagrams 也能生成类图但那是代码现实是代码审查工具不适合当设计图交作业设计阶段的类图应该从需求推导而不是从代码反向生成。4. 时序图借书还书的时间轴按什么顺序画消息才不打架4.1 时序图的四个基本符号先和I2C时序图划清界限动态建模除了活动图另一张经常被要求交的就是时序图。时序图描述多个对象在时间轴上的一次交互回答的是“用例里的主流程代码里到底按什么顺序调用谁”。符号一共四类对象、生命线、激活条、消息。对象是参与交互的实例矩形里写“实例名:类名”例如“借书界面: JFrame”生命线是对象正下方的一条竖虚线表示对象在这段时间里存在激活条是生命线上的窄长矩形表示对象正在执行逻辑消息是对象之间的横线箭头实线箭头表示同步调用虚线箭头表示返回结果。这里要专门提醒一句在搜索引擎里输入“时序图”三个字时最先跳出来的很可能是 I2C 时序图、IIC 时序图这类硬件时序图画的是时钟线和数据线上的电平高低随时间变化和 UML 时序图完全是两回事。UML 时序图的横轴是参与交互的对象纵轴才是时间硬件时序图的横轴是时间纵轴是电压。画图前先认清自己建的是软件对象交互还是硬件波形选错模板会让整张图白画。网上有不少把“时序图”三个字当成硬件概念的资料这也是我每次画图前都会确认一句“这里说的是 UML 时序图”的原因。4.2 借书主流程的时序图画法一份可以抄的 PlantUML 示例以“借书”这个用例为例典型三层结构是读者、借书界面、借阅控制器、借阅记录、图书。按时间顺序走一遍读者在界面上提交申请界面把借书请求发给控制器控制器先查图书库存库存充足时创建借阅记录、扣减库存界面最后把结果展示给读者。下面代码可以直接跑出一张可用时序图startuml actor 读者 as R boundary 借书界面 as UI control 借阅控制器 as C entity 借阅记录 as BR entity 图书 as BK R - UI : 提交借书申请 UI - C : 借书(读者证号, ISBN) C - BK : 查询库存() BK -- C : 库存数量 alt 库存充足 C - BR : 创建借阅记录() BR -- C : 记录编号 C - BK : 扣减库存() C -- UI : 借书成功 else 库存不足 C -- UI : 库存不足 end UI -- R : 显示借书结果 endumlactor、boundary、control、entity 分别定义参与者、边界对象、控制对象和实体对象生成图里会显示为不同图标比全用矩形更专业。- 表示同步消息-- 表示返回消息alt/else/end 生成一个带分支名的交互片段。消息命名要写“动词对象”例如“查询库存()”不要写“数据查一下”因为时序图里的每条消息最终要对应到类图中某个类的方法命名不一致两张图就对不上。激活条这里最容易出错C 收到“借书(读者证号, ISBN)”后一直到返回结果前生命线上会有一段窄长矩形规范是进入消息就开激活发出返回消息就关激活。如果激活条没有覆盖业务处理过程或者一个对象连续被调用两次却只有一段激活条说明你还没分清同步调用和异步通知。4.3 每个用例画一张时序图就够了先分层再对齐活动图时序图不需要满屏都是。图书馆管理系统最常见、最省力的做法是选“借书”和“还书”各画一张答辩时再决定要不要补“预约”和“续借”。一张时序图对应一个用例主流程活动图里的分支统一用 alt 片段表达不要把这些分支画成多条独立消息线。画时序图之前先把参与对象分成三层显示层是借书界面业务层是借阅控制器数据层是借阅记录和图书读者在层外作为发起者。分完层后消息方向只能是“请求向下、返回向上”如果出现数据层直接跳回显示层的线基本就是分层错了。活动图在这里的作用是检验时序图有没有漏步骤活动图的每个活动节点对用时序图里的一个或多个消息活动图上的判断条件对应时序图里的 alt/else 分支。两张图连起来能讲通建模才算闭环。我自己的习惯是先画活动图再画时序图画完时序图回去改类图——时序图最容易暴露出哪个类缺方法、哪个方法少参数这个后遗症是画图过程中最值钱的部分。5. UML图常见问题排查五个让图纸直接返工的踩坑现场5.1 用例图画成了功能清单参与者一栏写着“系统”现象用例图上全是“图书管理”“借阅管理”“读者管理”参与者画了一个系统小人整张图看起来像后台功能菜单截图。原因把系统模块当成了外部参与者又把模块名当成了用例名。用例必须由参与者发起并产生参与者能感知的结果系统自己不会给自己派活。解决把参与者改成读者和图书管理员用例改成动词短语比如“借书”“还书”“查询图书”。如果一个用例找不到任何外部发起者那它不是用例是后台定时任务可以单独用注释说明不要混进用例图。5.2 活动图只分叉不汇合现象借书流程在“读者状态正常”处分成“是”和“否”两条路“否”直接走到结束“是”走到库存判断后也直接结束整张图看不到任何汇合节点。原因把活动图画成了普通流程图判断分支的各路没有汇合图无法表达“分支结束后流程继续往哪个方向走”。解决在每段 if/else 结束后补一个汇合节点如果有两条路径并行执行用水平分叉线和汇合线把并发区包起来。修正后借书流程在读者证判断之后必须有汇合再进入库存判断否则整张图看起来像流程在半路散架。5.3 类图箭头方向画反聚合组合全用成继承现象整张类图画满空心三角箭头读者和借阅记录之间的关系也画成继承组合的实心菱形出现在部分类那一端。原因很多工具里关系按钮形状接近拖拽时默认方向是从当前选中类指向目标类画完不检查语义菱形就被放错边。解决画完关系后用生命周期口诀复核一遍同生共死是组合死后还活着是聚合只是认识是关联用到就走是依赖是一个就是继承。菱形永远画在整体端继承三角指向父类依赖虚线指向被依赖类。只要出现一个方向错误的箭头整页类图都会被判定为语义理解有误。5.4 时序图的激活条和消息顺序对不上现象消息线从图书对象直接跳回借书界面跳过了借阅控制器或者控制器生命线上的激活条覆盖了两次互不连续的处理过程。原因把时序图画成了数据流图或者没有理解同步调用的开始和结束。解决请求按“界面→控制器→实体”逐层向下返回值按原路向上激活条从方法进入时开始到方法 return 时结束。如果激活条中间断开又再开说明对象实际上执行了两次独立方法应该拆成两条消息段而不是一条长线。检查顺序的方法是从第一笔消息开始沿生命线往下走每个激活条都要能找到对应的进入消息和返回消息。5.5 PDF导出翻车中文方块字与模糊位图现象从绘图工具直接截图贴进 Word再导出 PDF放大后全是锯齿或者从 PlantUML 默认配置导出 PDF中文全部变成方块。原因位图导出丢清晰度工具没有正确加载中文字体。解决优先用矢量导出。PlantUML 导出时指定 SVG 或 PDF 格式StarUML 和 Draw.io 也支持 SVG 导出把 SVG 插入文档后再导出 PDF文字边缘是矢量路径不会模糊。中文字体问题在 PlantUML 里通常要检查本地字体配置必要时显式指定一个带中文的字体导出后把 PDF 放大到 200% 逐张看一遍边缘和汉字这是最笨但最有效的检查办法。6. 把四张图合成一份能交付的PDF布局、导出与自检技巧四张图画完之后真正的交付难点在“合成一份 PDF”。我习惯的目录顺序就是标题里的顺序用例图在最前接着活动图然后类图时序图收尾。这个顺序不是随意的它暗合从需求分析到概要设计的推进先告诉读者谁在用系统再告诉他主流程怎么走然后告诉他对象结构是什么最后展示一次完整交互的时序。页面布局上我一般守三条一页只放一张图横向 A4 或接近方形的画布避免时序图换行错位每个图下方加图注例如“图 2-1 图书馆管理系统借书活动图”。导出 PDF 最稳妥的路径是先让每张图单独导出 SVG再插入文档统一导出 PDF如果赶时间在 PlantUML 里直接导出 PDF 再合并也可以接受。无论哪种方式都不要用系统截图当交付图那是所有模糊和失真的源头。交付前我会做最后一轮自查直接套下面这个检查表自查项检查方法合格标准参与者边界把系统参与者拿掉看用例图是否成立每个用例有外部发起者无“系统”参与者活动图分支从 start 沿每条路径走到 stop每条分支都能到达结束节点无悬空路径类图关系逐个关系套生命周期口诀菱形在整体端继承三角指向父类虚线为依赖时序图分层从发起到返回追踪一次借书请求逐层向下返回值逐层向上激活条连续命名一致性对照类图方法名与时序图消息“借书()”“查询库存()”等出现在同一套类里最后说一个我自己的习惯交付前一晚我会按“借一本书”的真实路径把四张图连起来讲一遍。用例图告诉我读者能借书活动图告诉我借书有哪几步类图告诉我哪个类有哪个方法时序图告诉我每一步调用谁。如果讲着讲着发现某个环节在下一张图里找不到对应物那一定是图要改通常改的是类图方法或者时序图消息顺序。这套“图纸对账”的功夫比单独检查每一张图有效得多也是我这些年少返工的原因。希望帮到你。本文还有配套的精品资源点击获取