简介这份PDF面向软件工程课程设计、UML建模学习及考试复习人群围绕图书馆管理系统的需求分析与动态建模展开帮助读者掌握用例图、活动图、类图、时序图与状态图的规范画法与表达逻辑。资源包共1个PDF文件约1.55MB内容以图文结合方式呈现便于对照阅读与打印复习。文档从系统目标设计切入依次梳理读者管理、书籍管理、借阅管理、系统管理四大功能需求并给出管理员与读者的完整用例划分随后展开借书、还书、罚款三类时序图借书、还书、预订三类活动图以及书籍从新加、在库、借出到预订、可用的状态流转说明类图部分还细化了reader、admin、Title、Item等核心类的属性与操作。目前已有414人学习适合需要完整建模案例、撰写课程报告或备考UML相关内容的读者参考。1. 图书馆管理系统四张 UML 图从需求到可交付 PDF 的完整落地路径很多同学做课程设计或软考中级 UML 建模题时拿到「图书馆管理系统」这个题目第一反应是打开 StarUML 或者 draw.io 就开始画结果用例图画完发现活动图对不上类图里的方法在时序图里找不到调用关系最后四张图各说各话答辩时被老师一句「你这个借书流程的类图里怎么没有借阅记录类」直接问住。这个标题指向的其实是一套完整的面向对象分析交付物用例图锁定系统边界和参与者活动图描述业务流程的控制流类图定义静态结构时序图验证动态交互。四张图不是孤立的它们之间存在严格的追溯关系——用例图里的每个用例在活动图里要有流程展开在类图里要有类来承载在时序图里要有对象间的消息序列来验证。适合正在做课程设计、准备软考中级、或者需要给团队输出一份可评审的 UML 建模文档的从业者。接下来我按实际交付顺序把每张图的画法、参数设置、工具操作和四图一致性校验讲清楚。2. 用例图先行参与者、用例与系统边界的确定方法2.1 图书馆管理系统的参与者识别与用例粒度控制用例图是整个建模的入口画错了后面全白搭。图书馆管理系统的参与者常见有读者、图书管理员、系统管理员。有些同学会把「借书证」也画成参与者这是典型的把外部系统当人。参与者一定是与系统交互的角色不是被系统管理的对象。读者能做的用例包括查询图书、借阅图书、归还图书、续借图书、预约图书、查看借阅历史。图书管理员负责图书入库、图书下架、处理借还、管理读者账户、生成借阅报表。系统管理员负责用户权限管理、系统参数配置、数据备份。用例粒度怎么控制一个判断标准每个用例必须是一个完整的、对参与者有价值的目标。比如「输入图书 ISBN」不是用例它是「图书入库」这个用例内部的一个步骤。我一般会先列一张参与者-用例矩阵表确认每个参与者至少有一个用例每个用例至少被一个参与者触发。参与者核心用例扩展用例读者查询图书、借阅图书、归还图书续借、预约、查看历史图书管理员图书入库、处理借还、管理读者下架、报表、罚款处理系统管理员权限管理、参数配置数据备份、日志审计2.2 用 StarUML 画用例图的具体操作与 include/extend 判断打开 StarUML新建项目后选择 UML 1.4 或 UML 2.0 模板。在 Model 面板右键 Add Diagram → Use Case Diagram。从 Toolbox 拖入 Actor命名后拖入 Use Case用 Association 连线。系统边界用 System Boundary 矩形框住所有用例参与者放在框外。include 和 extend 是最容易用错的两个关系。include 表示基础用例一定会执行被包含用例比如「借阅图书」一定包含「验证读者身份」。extend 表示扩展用例在特定条件下才插入基础用例比如「续借图书」在读者有续借需求且未超期时扩展「借阅图书」的部分行为。箭头方向include 箭头从基础用例指向被包含用例extend 箭头从扩展用例指向基础用例。用例图关系速查 借阅图书 --include-- 验证读者身份 续借图书 --extend-- 借阅图书 处理罚款 --extend-- 归还图书画完后检查每个用例是否至少有一条关联到参与者系统边界内是否只有用例没有参与者include 链是否超过三层超过三层说明用例粒度太细需要合并。3. 活动图展开借书还书流程的泳道划分与决策节点3.1 借书流程的活动图建模从初始节点到结束节点活动图是把用例展开成可执行的业务流程。以「借阅图书」为例标准流程是读者提交借书请求 → 系统验证读者身份 → 判断是否超期或有罚款 → 判断图书是否可借 → 生成借阅记录 → 更新图书状态 → 通知读者借阅成功。用 StarUML 画活动图时初始节点用实心圆结束节点用带圈的实心圆动作用圆角矩形决策节点用菱形合并节点也用菱形分叉和汇合用粗横线。决策节点的每个分支必须标注监护条件用方括号括起来。比如判断读者状态的分支[无超期且无罚款] 和 [有超期或有罚款]。两个分支最终要能到达同一个合并节点否则流程会断。借书活动图关键路径 初始节点 → 读者提交请求 → 验证身份 → 决策[状态正常?] → 是 → 决策[图书可借?] → 是 → 生成借阅记录 → 更新图书状态 → 结束 → 否 → 提示不可借 → 结束 → 否 → 提示处理罚款 → 结束3.2 泳道划分与对象流让活动图能直接映射到类图泳道是活动图里最实用的组织工具。图书馆管理系统一般分三条泳道读者、图书管理员、系统。每个活动放在负责执行它的泳道里。比如「提交借书请求」在读者泳道「验证身份」在系统泳道「处理罚款」在图书管理员泳道。泳道划分的好处是后面画时序图时泳道里的每个活动天然对应一条消息。对象流用虚线箭头表示连接活动和对象节点。比如「生成借阅记录」活动后面接一个「借阅记录」对象节点这个对象节点在类图里必须有一个对应的类。这就是活动图和类图的追溯点。我一般会在活动图里把关键业务对象都标出来读者、图书、借阅记录、罚款记录。每个对象节点在类图里都要能找到。注意活动图里不要画成流程图。活动图支持并发分叉和汇合如果业务里有同时发生的动作比如「更新图书状态」和「发送通知」可以并发就用分叉节点。但图书馆借还流程大部分是顺序的不要为了用而用。4. 类图设计从活动图对象节点推导类、属性与关系4.1 核心类识别与属性方法填充类图是四张图里最需要严谨的。从活动图的对象节点出发图书馆管理系统至少需要这些类读者Reader、图书Book、借阅记录LoanRecord、图书管理员Librarian、罚款记录FineRecord、预约记录Reservation。每个类的属性从业务规则推导读者有 readerId、name、type、maxBorrowLimit、currentBorrowCount图书有 isbn、title、author、publisher、status、location借阅记录有 loanId、borrowDate、dueDate、returnDate、status。方法从活动图的活动推导「验证读者身份」对应 Reader 类的 validateStatus() 方法「生成借阅记录」对应 LoanRecord 类的 create() 方法「更新图书状态」对应 Book 类的 updateStatus() 方法。方法签名要写清楚参数和返回类型比如create(readerId: String, isbn: String): LoanRecord。4.2 类间关系关联、聚合、组合与依赖的箭头画法类图箭头含义是热搜里问得最多的。图书馆管理系统里常见的关系读者和借阅记录是关联关系一个读者可以有多条借阅记录用 1 对 * 的实线箭头箭头指向借阅记录。借阅记录和图书是关联关系一条借阅记录对应一本图书用 * 对 1。图书和图书分类是聚合关系用空心菱形指向分类表示分类可以独立存在。借阅记录和罚款记录是组合关系用实心菱形指向罚款记录表示罚款记录不能脱离借阅记录存在。图书管理员和图书入库操作是依赖关系用虚线箭头表示管理员使用入库功能。类图关系速查 Reader 1 --- * LoanRecord LoanRecord * --- 1 Book Book * --- 1 BookCategory (聚合) LoanRecord 1 --- * FineRecord (组合) Librarian --- Book (依赖入库操作)用 StarUML 画类图时在 Toolbox 里选 Class 拖入双击添加属性和方法。关系线选对应的 Association、Aggregation、Composition、Dependency。画完后用 Layout 自动排列再手动微调避免线交叉。5. 时序图验证借书场景的对象交互与消息编号5.1 借书场景的时序图对象与消息序列时序图用来验证类图里的方法调用是否合理。以「借阅图书」场景为例参与对象有读者Actor、借阅控制器LoanController、读者对象Reader、图书对象Book、借阅记录对象LoanRecord。消息序列读者 → 借阅控制器borrowBook(readerId, isbn)借阅控制器 → 读者对象validateStatus()读者对象返回 status借阅控制器 → 图书对象checkAvailability()图书对象返回 available借阅控制器 → 借阅记录对象create(readerId, isbn)借阅记录对象返回 loanRecord借阅控制器 → 图书对象updateStatus(borrowed)借阅控制器 → 读者借阅成功。每条消息在时序图里用实线箭头表示同步调用虚线箭头表示返回。激活条Activation Bar表示对象在执行操作的时间段。消息编号用 1、2、3 顺序标注嵌套调用用 1.1、1.2。5.2 用 PlantUML 代码生成时序图并校验与类图的一致性手画时序图容易漏消息我一般用 PlantUML 写代码生成改起来快也方便版本管理。startuml actor Reader participant LoanController as LC participant Reader as R participant Book as B participant LoanRecord as LR Reader - LC: borrowBook(readerId, isbn) LC - R: validateStatus() R -- LC: status LC - B: checkAvailability() B -- LC: available LC - LR: create(readerId, isbn) LR -- LC: loanRecord LC - B: updateStatus(borrowed) LC -- Reader: 借阅成功 enduml生成后逐条检查每条消息对应的方法是否在类图里存在消息的参数类型是否和类图方法签名一致返回消息是否对应方法的返回类型如果类图里 Reader 没有 validateStatus() 方法时序图里就不该出现这条消息。这就是四图一致性校验的核心。提示时序图里的对象名要和类图里的类名一致不要一个叫 Reader 一个叫 User。命名不一致是答辩被问最多的问题。6. 避坑与排查四张 UML 图交付前必须检查的 5 个问题6.1 用例图参与者与系统边界混淆现象把「借书证」或「数据库」画成参与者系统边界框把参与者框在里面。原因没有区分角色和外部系统。解决参与者一定是人或其他系统且必须在系统边界外。数据库是系统内部组件不是参与者。6.2 活动图决策节点缺少监护条件现象决策节点的分支没有方括号条件或者两个分支条件重叠导致流程歧义。原因画图时只关注流程走向忽略了条件标注。解决每个分支必须写监护条件且条件之间互斥。比如 [有罚款] 和 [无罚款]不能写 [有罚款] 和 [无超期]。6.3 类图关系箭头方向画反现象聚合关系的空心菱形指向整体组合关系的实心菱形指向部分很多人画反。原因对整体和部分的理解颠倒。解决菱形永远在整体那一端。图书分类是整体图书是部分菱形在图书分类端。6.4 时序图消息与类图方法不对应现象时序图里出现了类图中不存在的方法或者参数个数不一致。原因先画时序图后画类图没有回溯修改。解决以类图为唯一事实来源时序图里的每条消息都必须在类图里有对应方法。发现不一致时要么改类图加方法要么改时序图删消息。6.5 PDF 导出后中文字体乱码或图形错位现象StarUML 导出 PDF 时中文显示为方框或者图形被截断。原因默认字体不支持中文页面尺寸设置过小。解决在 StarUML 的 Preferences → Font 里把默认字体改成「微软雅黑」或「思源黑体」导出时选择 A4 横向缩放比例设为 Fit to Page。PlantUML 导出 PDF 需要在命令行加-charset UTF-8参数。7. 从四张图到可评审 PDF导出参数与一致性自检清单最后一章讲一个我反复用的技巧把四张图放在同一个 StarUML 项目里用 Model 面板的层级结构管理导出时选择 File → Export → PDF在导出对话框里勾选 All Diagrams页面设置选 A4 横向边距 10mm缩放 Fit to Page。这样导出的 PDF 每张图占一页图与图之间的追溯关系在 Model 面板里一目了然。导出前我会跑一遍自检清单用表格逐项打勾检查项通过标准常见不通过原因用例图参与者全部在系统边界外把数据库画成参与者用例 include/extend箭头方向正确include 箭头画反活动图决策节点每个分支有监护条件条件缺失或重叠活动图对象节点在类图中都有对应类漏画借阅记录类类图关系箭头菱形在整体端聚合组合画反类图方法签名参数和返回类型完整只写方法名不写参数时序图消息与类图方法一一对应消息名拼写不一致时序图返回消息虚线箭头方向正确返回消息画成实线PDF 中文字体无乱码无方框默认字体不支持中文PDF 页面布局图形完整无截断页面尺寸过小这个清单我用了三年每次交付前跑一遍答辩被问住的概率从十次有三次降到十次零次。血泪经验是不要等到导出 PDF 才发现字体问题画第一张图之前就把字体设好。另外PlantUML 和 StarUML 混用时注意 PlantUML 的类图语法和 StarUML 的模型不互通要么全用 StarUML要么全用 PlantUML 代码化混着来后期改图会非常痛苦。我现在的习惯是用例图和活动图用 StarUML 画类图和时序图用 PlantUML 写代码因为类图和时序图改动频繁代码化后 diff 清晰改一处不影响其他图。希望帮到你。本文还有配套的精品资源点击获取 图书馆管理系统四张UML图：从需求到可交付PDF的完整落地路径
简介这份PDF面向软件工程课程设计、UML建模学习及考试复习人群围绕图书馆管理系统的需求分析与动态建模展开帮助读者掌握用例图、活动图、类图、时序图与状态图的规范画法与表达逻辑。资源包共1个PDF文件约1.55MB内容以图文结合方式呈现便于对照阅读与打印复习。文档从系统目标设计切入依次梳理读者管理、书籍管理、借阅管理、系统管理四大功能需求并给出管理员与读者的完整用例划分随后展开借书、还书、罚款三类时序图借书、还书、预订三类活动图以及书籍从新加、在库、借出到预订、可用的状态流转说明类图部分还细化了reader、admin、Title、Item等核心类的属性与操作。目前已有414人学习适合需要完整建模案例、撰写课程报告或备考UML相关内容的读者参考。1. 图书馆管理系统四张 UML 图从需求到可交付 PDF 的完整落地路径很多同学做课程设计或软考中级 UML 建模题时拿到「图书馆管理系统」这个题目第一反应是打开 StarUML 或者 draw.io 就开始画结果用例图画完发现活动图对不上类图里的方法在时序图里找不到调用关系最后四张图各说各话答辩时被老师一句「你这个借书流程的类图里怎么没有借阅记录类」直接问住。这个标题指向的其实是一套完整的面向对象分析交付物用例图锁定系统边界和参与者活动图描述业务流程的控制流类图定义静态结构时序图验证动态交互。四张图不是孤立的它们之间存在严格的追溯关系——用例图里的每个用例在活动图里要有流程展开在类图里要有类来承载在时序图里要有对象间的消息序列来验证。适合正在做课程设计、准备软考中级、或者需要给团队输出一份可评审的 UML 建模文档的从业者。接下来我按实际交付顺序把每张图的画法、参数设置、工具操作和四图一致性校验讲清楚。2. 用例图先行参与者、用例与系统边界的确定方法2.1 图书馆管理系统的参与者识别与用例粒度控制用例图是整个建模的入口画错了后面全白搭。图书馆管理系统的参与者常见有读者、图书管理员、系统管理员。有些同学会把「借书证」也画成参与者这是典型的把外部系统当人。参与者一定是与系统交互的角色不是被系统管理的对象。读者能做的用例包括查询图书、借阅图书、归还图书、续借图书、预约图书、查看借阅历史。图书管理员负责图书入库、图书下架、处理借还、管理读者账户、生成借阅报表。系统管理员负责用户权限管理、系统参数配置、数据备份。用例粒度怎么控制一个判断标准每个用例必须是一个完整的、对参与者有价值的目标。比如「输入图书 ISBN」不是用例它是「图书入库」这个用例内部的一个步骤。我一般会先列一张参与者-用例矩阵表确认每个参与者至少有一个用例每个用例至少被一个参与者触发。参与者核心用例扩展用例读者查询图书、借阅图书、归还图书续借、预约、查看历史图书管理员图书入库、处理借还、管理读者下架、报表、罚款处理系统管理员权限管理、参数配置数据备份、日志审计2.2 用 StarUML 画用例图的具体操作与 include/extend 判断打开 StarUML新建项目后选择 UML 1.4 或 UML 2.0 模板。在 Model 面板右键 Add Diagram → Use Case Diagram。从 Toolbox 拖入 Actor命名后拖入 Use Case用 Association 连线。系统边界用 System Boundary 矩形框住所有用例参与者放在框外。include 和 extend 是最容易用错的两个关系。include 表示基础用例一定会执行被包含用例比如「借阅图书」一定包含「验证读者身份」。extend 表示扩展用例在特定条件下才插入基础用例比如「续借图书」在读者有续借需求且未超期时扩展「借阅图书」的部分行为。箭头方向include 箭头从基础用例指向被包含用例extend 箭头从扩展用例指向基础用例。用例图关系速查 借阅图书 --include-- 验证读者身份 续借图书 --extend-- 借阅图书 处理罚款 --extend-- 归还图书画完后检查每个用例是否至少有一条关联到参与者系统边界内是否只有用例没有参与者include 链是否超过三层超过三层说明用例粒度太细需要合并。3. 活动图展开借书还书流程的泳道划分与决策节点3.1 借书流程的活动图建模从初始节点到结束节点活动图是把用例展开成可执行的业务流程。以「借阅图书」为例标准流程是读者提交借书请求 → 系统验证读者身份 → 判断是否超期或有罚款 → 判断图书是否可借 → 生成借阅记录 → 更新图书状态 → 通知读者借阅成功。用 StarUML 画活动图时初始节点用实心圆结束节点用带圈的实心圆动作用圆角矩形决策节点用菱形合并节点也用菱形分叉和汇合用粗横线。决策节点的每个分支必须标注监护条件用方括号括起来。比如判断读者状态的分支[无超期且无罚款] 和 [有超期或有罚款]。两个分支最终要能到达同一个合并节点否则流程会断。借书活动图关键路径 初始节点 → 读者提交请求 → 验证身份 → 决策[状态正常?] → 是 → 决策[图书可借?] → 是 → 生成借阅记录 → 更新图书状态 → 结束 → 否 → 提示不可借 → 结束 → 否 → 提示处理罚款 → 结束3.2 泳道划分与对象流让活动图能直接映射到类图泳道是活动图里最实用的组织工具。图书馆管理系统一般分三条泳道读者、图书管理员、系统。每个活动放在负责执行它的泳道里。比如「提交借书请求」在读者泳道「验证身份」在系统泳道「处理罚款」在图书管理员泳道。泳道划分的好处是后面画时序图时泳道里的每个活动天然对应一条消息。对象流用虚线箭头表示连接活动和对象节点。比如「生成借阅记录」活动后面接一个「借阅记录」对象节点这个对象节点在类图里必须有一个对应的类。这就是活动图和类图的追溯点。我一般会在活动图里把关键业务对象都标出来读者、图书、借阅记录、罚款记录。每个对象节点在类图里都要能找到。注意活动图里不要画成流程图。活动图支持并发分叉和汇合如果业务里有同时发生的动作比如「更新图书状态」和「发送通知」可以并发就用分叉节点。但图书馆借还流程大部分是顺序的不要为了用而用。4. 类图设计从活动图对象节点推导类、属性与关系4.1 核心类识别与属性方法填充类图是四张图里最需要严谨的。从活动图的对象节点出发图书馆管理系统至少需要这些类读者Reader、图书Book、借阅记录LoanRecord、图书管理员Librarian、罚款记录FineRecord、预约记录Reservation。每个类的属性从业务规则推导读者有 readerId、name、type、maxBorrowLimit、currentBorrowCount图书有 isbn、title、author、publisher、status、location借阅记录有 loanId、borrowDate、dueDate、returnDate、status。方法从活动图的活动推导「验证读者身份」对应 Reader 类的 validateStatus() 方法「生成借阅记录」对应 LoanRecord 类的 create() 方法「更新图书状态」对应 Book 类的 updateStatus() 方法。方法签名要写清楚参数和返回类型比如create(readerId: String, isbn: String): LoanRecord。4.2 类间关系关联、聚合、组合与依赖的箭头画法类图箭头含义是热搜里问得最多的。图书馆管理系统里常见的关系读者和借阅记录是关联关系一个读者可以有多条借阅记录用 1 对 * 的实线箭头箭头指向借阅记录。借阅记录和图书是关联关系一条借阅记录对应一本图书用 * 对 1。图书和图书分类是聚合关系用空心菱形指向分类表示分类可以独立存在。借阅记录和罚款记录是组合关系用实心菱形指向罚款记录表示罚款记录不能脱离借阅记录存在。图书管理员和图书入库操作是依赖关系用虚线箭头表示管理员使用入库功能。类图关系速查 Reader 1 --- * LoanRecord LoanRecord * --- 1 Book Book * --- 1 BookCategory (聚合) LoanRecord 1 --- * FineRecord (组合) Librarian --- Book (依赖入库操作)用 StarUML 画类图时在 Toolbox 里选 Class 拖入双击添加属性和方法。关系线选对应的 Association、Aggregation、Composition、Dependency。画完后用 Layout 自动排列再手动微调避免线交叉。5. 时序图验证借书场景的对象交互与消息编号5.1 借书场景的时序图对象与消息序列时序图用来验证类图里的方法调用是否合理。以「借阅图书」场景为例参与对象有读者Actor、借阅控制器LoanController、读者对象Reader、图书对象Book、借阅记录对象LoanRecord。消息序列读者 → 借阅控制器borrowBook(readerId, isbn)借阅控制器 → 读者对象validateStatus()读者对象返回 status借阅控制器 → 图书对象checkAvailability()图书对象返回 available借阅控制器 → 借阅记录对象create(readerId, isbn)借阅记录对象返回 loanRecord借阅控制器 → 图书对象updateStatus(borrowed)借阅控制器 → 读者借阅成功。每条消息在时序图里用实线箭头表示同步调用虚线箭头表示返回。激活条Activation Bar表示对象在执行操作的时间段。消息编号用 1、2、3 顺序标注嵌套调用用 1.1、1.2。5.2 用 PlantUML 代码生成时序图并校验与类图的一致性手画时序图容易漏消息我一般用 PlantUML 写代码生成改起来快也方便版本管理。startuml actor Reader participant LoanController as LC participant Reader as R participant Book as B participant LoanRecord as LR Reader - LC: borrowBook(readerId, isbn) LC - R: validateStatus() R -- LC: status LC - B: checkAvailability() B -- LC: available LC - LR: create(readerId, isbn) LR -- LC: loanRecord LC - B: updateStatus(borrowed) LC -- Reader: 借阅成功 enduml生成后逐条检查每条消息对应的方法是否在类图里存在消息的参数类型是否和类图方法签名一致返回消息是否对应方法的返回类型如果类图里 Reader 没有 validateStatus() 方法时序图里就不该出现这条消息。这就是四图一致性校验的核心。提示时序图里的对象名要和类图里的类名一致不要一个叫 Reader 一个叫 User。命名不一致是答辩被问最多的问题。6. 避坑与排查四张 UML 图交付前必须检查的 5 个问题6.1 用例图参与者与系统边界混淆现象把「借书证」或「数据库」画成参与者系统边界框把参与者框在里面。原因没有区分角色和外部系统。解决参与者一定是人或其他系统且必须在系统边界外。数据库是系统内部组件不是参与者。6.2 活动图决策节点缺少监护条件现象决策节点的分支没有方括号条件或者两个分支条件重叠导致流程歧义。原因画图时只关注流程走向忽略了条件标注。解决每个分支必须写监护条件且条件之间互斥。比如 [有罚款] 和 [无罚款]不能写 [有罚款] 和 [无超期]。6.3 类图关系箭头方向画反现象聚合关系的空心菱形指向整体组合关系的实心菱形指向部分很多人画反。原因对整体和部分的理解颠倒。解决菱形永远在整体那一端。图书分类是整体图书是部分菱形在图书分类端。6.4 时序图消息与类图方法不对应现象时序图里出现了类图中不存在的方法或者参数个数不一致。原因先画时序图后画类图没有回溯修改。解决以类图为唯一事实来源时序图里的每条消息都必须在类图里有对应方法。发现不一致时要么改类图加方法要么改时序图删消息。6.5 PDF 导出后中文字体乱码或图形错位现象StarUML 导出 PDF 时中文显示为方框或者图形被截断。原因默认字体不支持中文页面尺寸设置过小。解决在 StarUML 的 Preferences → Font 里把默认字体改成「微软雅黑」或「思源黑体」导出时选择 A4 横向缩放比例设为 Fit to Page。PlantUML 导出 PDF 需要在命令行加-charset UTF-8参数。7. 从四张图到可评审 PDF导出参数与一致性自检清单最后一章讲一个我反复用的技巧把四张图放在同一个 StarUML 项目里用 Model 面板的层级结构管理导出时选择 File → Export → PDF在导出对话框里勾选 All Diagrams页面设置选 A4 横向边距 10mm缩放 Fit to Page。这样导出的 PDF 每张图占一页图与图之间的追溯关系在 Model 面板里一目了然。导出前我会跑一遍自检清单用表格逐项打勾检查项通过标准常见不通过原因用例图参与者全部在系统边界外把数据库画成参与者用例 include/extend箭头方向正确include 箭头画反活动图决策节点每个分支有监护条件条件缺失或重叠活动图对象节点在类图中都有对应类漏画借阅记录类类图关系箭头菱形在整体端聚合组合画反类图方法签名参数和返回类型完整只写方法名不写参数时序图消息与类图方法一一对应消息名拼写不一致时序图返回消息虚线箭头方向正确返回消息画成实线PDF 中文字体无乱码无方框默认字体不支持中文PDF 页面布局图形完整无截断页面尺寸过小这个清单我用了三年每次交付前跑一遍答辩被问住的概率从十次有三次降到十次零次。血泪经验是不要等到导出 PDF 才发现字体问题画第一张图之前就把字体设好。另外PlantUML 和 StarUML 混用时注意 PlantUML 的类图语法和 StarUML 的模型不互通要么全用 StarUML要么全用 PlantUML 代码化混着来后期改图会非常痛苦。我现在的习惯是用例图和活动图用 StarUML 画类图和时序图用 PlantUML 写代码因为类图和时序图改动频繁代码化后 diff 清晰改一处不影响其他图。希望帮到你。本文还有配套的精品资源点击获取