尧图网站建设 
简介《图书馆管理系统UML设计》是一份面向高校信息管理与信息系统相关专业的统一建模语言课程设计文档呈现了从需求分析到用例建模的完整过程。围绕图书馆业务梳理出读者、图书管理员、系统管理员三类参与者并分别绘制读者用例图、图书管理员用例图和系统管理员用例图覆盖图书查询、借还、续借、罚款处理、书目与读者信息维护、权限管理等功能。同时文档还讨论了系统安全性视图机制、权限分配、平台安全与完整性主外键、检查约束、触发器要求并给出了部分用例的事件流描述对理解统一建模语言在信息系统设计中的应用具有直接参考价值。资源包仅包含一个PDF格式文档大小约八百零三KB内容紧凑完整。目前已有134人学习浏览适合作为课程设计、毕业设计或自学时的参考样例。1. 图书馆管理系统UML设计先定边界再画流程图书馆管理系统是UML建模最典型的练兵场角色分明读者、图书管理员、系统管理员主流程清晰借书、还书、续借、预约状态离散在馆、借出、预约保留、损坏、丢失全部建模对象都能用一张用例图、一张类图、一组动态图覆盖。很多设计文档的毛病在图多但没对齐——用例图画了十个类图里找不到对应实体顺序图消息满天飞对象类上却没有方法。下面按一线工程顺序展开先用例图圈边界再类图定实体与关系接着用顺序图、活动图和状态图验证流程最后用包图与部署图收口到工程结构并给出Visio绘制与验收技巧。2. 用UML用例图与类图锁定图书馆管理系统边界2.1 用例图先圈参与者与系统边界用例图是图书馆管理系统 UML 设计的第一张图它的作用是回答谁在用、做什么、做到什么程度。实践中先列参与者再为每个参与者列用例。图书馆管理系统的基础参与者有三类读者、图书管理员、系统管理员。如果业务范围包含馆际互借或分馆调拨还需要增加馆际管理员角色。用例图的一种常见文字表示如下--------------------- ----------------------- | 读者 | | 图书管理员 | --------------------- ----------------------- | 登录/注册 | | 图书编目 | | 查询图书 | | 图书上架/下架 | | 借书 | | 办理借书/还书 | | 还书 | | 处理预约 | | 续借 | | 催还与罚款管理 | | 预约 | | 读者证管理 | | 缴纳罚款 | | | --------------------- -----------------------用例之间用 include 和 extend 表达关系。借书用例包含校验读者资格和更新图书状态两个强制步骤用include还书时缴纳超期罚款只在超期时发生用extend挂在还书用例下。判断用例图画没画反的简单标准是include 连的是每次必须执行的公共步骤extend 连的是可选分支。用例图设计阶段最容易出现的两个问题一是把查询图书和高级检索图书拆成两个用例实际后者只是前者的扩展合并即可二是把图书编目拆成录入ISBN、录入书名、录入作者等细碎用例正确的做法是编目作为一个用例字段差别留给类图讨论。2.2 类图核心实体与借阅关系建模用例图里的名词落到类图上就形成了图书馆管理系统的主干实体。最核心的三个类是读者User、图书Book和借阅记录BorrowRecord。在 UML 类图中描述这三个类时属性不必列全关键方法和关键属性应保留public class User { private String userId; // 读者证号 private String name; // 姓名 private UserType userType; // TEACHER / STUDENT / ADMIN private int maxBorrowCount; // 最大可借册数 private int maxBorrowDays; // 最长借期天 public boolean hasBorrowPermission() { /* 校验是否冻结 */ return true; } } public class Book { private String bookId; // 馆藏条码号唯一 private String isbn; // 国际标准书号多本书可相同 private String title; private BookStatus status; // 在馆/借出/预约保留/损坏/丢失 private String shelfLocation; // 馆藏位置 public void changeStatus(BookStatus target) { /* 状态迁移 */ } } public class BorrowRecord { private String recordId; private String userId; private String bookId; private LocalDate borrowDate; private LocalDate dueDate; private LocalDate returnDate; // 为 null 表示未归还 public boolean isOverdue() { return false; } }注意bookId与isbn的差别isbn对应书目信息一本书目可以存在多本复本bookId对应单本馆藏。类图上若不区分这两个标识后端的书目检索和馆藏管理会出现数据不一致。类图里关系线决定了持久层设计。User与BorrowRecord之间是1 --- *的一对多关联Book与BorrowRecord之间同样是1 --- *但在建模当前借出状态时需要把这条记录是否已归还作为限定条件。常见做法是增加一个派生属性current通过查询未归还记录来获得而不是在 Book 类里冗余一个借出状态字段。2.3 类图关系连线的选型与常见误用类图中关系线种类多误用概率最高的是聚合与组合。图书馆管理系统中Book与BorrowRecord适合用聚合关系图书被注销后借阅历史仍然保留两个类的生命周期不同步空心菱形画在整体Book一侧。BorrowRecord与Fine罚款单则适合组合关系罚款单脱离借阅记录没有业务意义删除记录时应一并处理罚单实心菱形画在记录一侧。关系符号UML 语义图书馆例子关联普通直线对象间存在调用/持有引用User 与 Reservation聚合空心菱形整体消失部分仍独立存在Book 与 BorrowRecord组合实心菱形整体消失部分同时销毁BorrowRecord 与 Fine泛化空心三角继承关系Student/Teacher 继承 User依赖虚线箭头临时使用不持有引用BorrowService 依赖 MailUtil泛化关系同样要谨慎只有行为差异明显的子类型才画泛化。如果 Student 和 Teacher 只是借阅数量不同用一个userType字段加配置表就能解决不必建两个子类只有当不同角色拥有不同业务行为时泛化才有建模价值。提示聚合与组合的判据是生命周期。整体没了部分还在是聚合整体没了部分必须一起没是组合。图书馆场景里书注销但借阅流水保留这条规则直接决定了 Book 与 BorrowRecord 之间是聚合。3. UML顺序图与活动图把图书馆借还流程变成时序与分支3.1 借书流程顺序图的消息与返回类图给出了对象顺序图给出对象之间的消息序列。图书馆管理系统的借书流程顺序图是整套 UML 设计中信息量最大的一张图它的消息顺序代表了接口调用顺序读者 - 界面层: 提交借书请求(读者证号, 图书条码号) 界面层 - 图书服务: borrowBook(readerId, bookId) 图书服务 - 读者服务: validateReader(readerId) 读者服务 -- 图书服务: ReaderValid(true/false) 图书服务 - 馆藏服务: queryBookStatus(bookId) 馆藏服务 -- 图书服务: BookStatus(可借/借出/预约保留) 图书服务 - 借阅记录服务: createRecord(readerId, bookId, dueDate) 借阅记录服务 - 馆藏服务: updateBookStatus(bookId, BORROWED) 馆藏服务 -- 图书服务: 更新成功 图书服务 -- 界面层: 借书成功与应还日期 界面层 -- 读者: 展示结果顺序图上的每个消息名都应能对应到类图接收对象的方法名。例如validateReader(readerId)对应User.hasBorrowPermission()createRecord对应BorrowRecord的构造函数或工厂方法。若消息名与类方法对不上要么改顺序图要么改类图最终交付时两张图必须一致。顺序图中的返回消息用虚线箭头调用消息用实线箭头。返回消息上只写返回值不写动作。很多初版顺序图把返回也画成实线箭头一眼看去全是调用实际执行顺序反而看不出来。3.2 还书与续借的活动图分支活动图适合表达分支密集的业务过程。还书流程的活动图是图书馆管理系统中分支最多的图也是容易漏分支的图开始 - 读者提交还书 - 校验是否超期 - 是 - 计算超期罚款 - 否 - 跳过罚款 - 登记还书时间与图书状态 - 检查该书是否有预约 - 有 - 将图书置为预约保留并通知预约者 - 无 - 将图书置为在馆 - 检查读者欠款总额 - 超过阈值 - 冻结读者借书权限 - 未超过 - 保持不变 - 结束至少有三个分支是初稿中常被遗漏的。第一还书时若登记损坏状态不能走在馆分支第二预约者在还书后才被通知通知动作是异步任务活动图里应当用单独的泳道表达而不是和还书登记挤在同一条泳道第三读者累计欠款超过阈值会触发冻结这个动作发生在还书之后属于登记的副作用不画出来的话后续读者服务无法解释明明刚还完书却不能再借的现象。续借的活动图是借书流程的简化版本先检查借出状态再检查是否超期和是否被预约两个验证通过后延长截止日期并记录操作日志。续借分支中被预约的判断往往被遗忘导致预约者长时间等不到书这一点在活动图评审时值得单独点名。3.3 状态图覆盖图书与读者的生命周期图书馆管理系统适合用状态图建模的核心对象是图书。图书的状态迁移如下[在馆] --借出事件-- [借出] [借出] --还书事件-- [在馆] [在馆] --预约事件-- [预约保留] [预约保留] --借出事件-- [借出] [在馆] --损坏登记-- [损坏维修] [损坏维修] --修复完成-- [在馆] [借出] --丢失申报-- [丢失] [丢失] --赔偿处理-- [注销]状态图上的每一个迁移事件必须能在用例图或顺序图中找到触发者。例如预约保留→借出由图书管理员的办理预约借书用例触发在馆→损坏维修由还书活动图中的损坏分支触发。建立这种映射关系之后状态图就具备了校验能力找不到触发者的状态迁移说明业务规则或用例图存在缺口。状态迁移触发事件对应用例对应代码位置在馆 → 借出读者借书成功借书BorrowService.borrowBook借出 → 在馆还书且无预约还书BorrowService.returnBook在馆 → 预约保留读者预约成功预约ReservationService.reserve借出 → 丢失管理员登记丢失丢失处理BookService.markLost读者状态同样需要建模冻结、正常、注销之间有明确的触发关系但通常并入读者类图的状态属性即可不需要单独画一张状态图。只有当状态之间出现多条迁移路径时才值得为读者单独建模。4. UML包图与部署图拆解图书馆管理系统的工程结构4.1 包图按分层依赖组织模块图书馆管理系统发展到一定规模后单张类图已经放不下所有类必须用包图组织宏观结构。最常见的图书馆管理系统包图采用分层架构com.example.library |-- interfaces # 接口层REST 控制器、消息监听器 |-- application # 应用层用例编排事务边界 |-- domain # 领域层实体、值对象、领域服务 |-- infrastructure # 基础设施层数据库、缓存、外部接口 -- common # 公共模块工具类、常量、异常定义包图最重要的约束是依赖方向。interfaces 依赖 applicationapplication 依赖 domaindomain 不依赖 infrastructureinfrastructure 反向依赖 domain 的接口。这种四层划分比传统的 controller-service-dao 三层在 UML 设计中更常见因为它把业务规则和技术实现隔离开图书馆的核心借阅规则不会因为更换数据库或消息队列而改变。包图里还应当体现接口与实现的分离domain 层定义BorrowRecordRepository接口infrastructure 层提供JpaBorrowRecordRepository实现包图用虚线箭头表示依赖。如果包图只画实现而漏了接口后续做单元测试时要用 mock 替换 repository 的工作就找不到依据。4.2 部署图确定节点与通信连接部署图是图书馆管理系统 UML 设计中容易被忽略但项目落地时必须有的图。一套典型的部署结构包含四个节点部署节点承载制品连接方式说明读者客户端浏览器或小程序HTTPS无状态访问不需持久化管理员终端桌面浏览器、扫码枪内网 HTTPS扫码枪通过 USB 输入应用服务器Web 服务、定时任务HTTP/内部 RPC无状态可水平扩展数据服务器书目库、借阅流水库JDBC 连接池主备复制每日备份部署图中的每条连线都要标注协议。数据库连接要注明连接池大小与事务隔离级别消息通知要注明队列名称和失败重试策略。这些内容虽然不是 UML 规范强制要求但标注之后运维才能根据部署图配置监控和告警而不是重新问开发要一份接口文档。实际项目中有一个常见争议图书馆管理系统是否需要一个独立的文件存储节点。建议至少在部署图上预留一个对象存储节点用于存放封面图片和电子资源全部扔在应用服务器本地磁盘的话应用做水平扩展时会出现图片资源不一致。4.3 包图与代码目录的对照验证包图交付后最直接的验证方式是和代码目录逐层对比。以下命令用于检查目录结构和依赖方向# 列出项目的顶层目录对比包图主包结构 find src/main/java -maxdepth 4 -type d | sort # 检查是否出现反向依赖infrastructure 引用了 interfaces grep -r import.*interfaces src/main/java/com/example/library/infrastructure/ 2/dev/null echo 存在反向依赖 || echo 依赖方向正常第一段命令把目录树输出来和包图对比第二段命令用 grep 扫描基础设施包里是否出现接口层的引用。对于更大规模的代码库建议用 ArchUnit 把包图约束写成单元测试每次构建自动执行但 UML 设计评审阶段两条 grep 命令已经足以发现九成以上的依赖越界。5. 用Visio把UML类图画规范并反推设计闭环5.1 Visio绘制UML类图的连线与样式控制用 Visio 绘制 UML 类图的完整路径是新建页选择类别 → 软件和数据库 → UML 类图。进入画布后从左侧模具拖出类形状右键选择形状显示选项勾选属性和操作分区。属性前加-表示 private加表示 public加#表示 protected这直接遵循 UML 规范。关系连线使用模具中的二元关系。连线两端分别粘到两个类别形状的锚点上再通过右键设置端点样式泛化选空心三角且箭头指向父类聚合选空心菱形组合选实心菱形依赖选虚线箭头。多重性直接在线上键入1、0..*、1..*文本。画完需要验证线条是真实连接而非装饰线拖动一个类形状关系线应跟随移动。完成后的图可以直接用文件 → 另存为 → PDF导出配合标题与用例摘要页就是一份可交付的 UML 设计文档。导出前把画布设置为横向并选中所有形状后使用设计 → 大小 → 适应绘图调整画布边界避免 PDF 里出现大片空白。5.2 用核对表反向验证整套 UML 设计画完所有图后用一张核对表完成 UML 设计的最终闭环核对项操作方式常见失败用例图 ↔ 类图每个用例的名词在类图中找实体预约无对应类顺序图 ↔ 类图每个消息名在接收类中找方法消息调用了不存在的方法状态图 ↔ 用例图每个状态迁移找触发用例丢失无赔偿用例包图 ↔ 代码目录目录与包结构逐步对比infrastructure 依赖 interfaces这四组关系全部核对通过后UML 设计文档就可以作为后续开发、测试用例编写和部署评审的基线。把顺序图中的消息签名提取成接口清单把状态图迁移表整理成交互逻辑整套图书馆管理系统的 UML 设计才算真正闭环。本文还有配套的精品资源点击获取 图书馆管理系统UML设计全攻略：用例图到部署图实战
简介《图书馆管理系统UML设计》是一份面向高校信息管理与信息系统相关专业的统一建模语言课程设计文档呈现了从需求分析到用例建模的完整过程。围绕图书馆业务梳理出读者、图书管理员、系统管理员三类参与者并分别绘制读者用例图、图书管理员用例图和系统管理员用例图覆盖图书查询、借还、续借、罚款处理、书目与读者信息维护、权限管理等功能。同时文档还讨论了系统安全性视图机制、权限分配、平台安全与完整性主外键、检查约束、触发器要求并给出了部分用例的事件流描述对理解统一建模语言在信息系统设计中的应用具有直接参考价值。资源包仅包含一个PDF格式文档大小约八百零三KB内容紧凑完整。目前已有134人学习浏览适合作为课程设计、毕业设计或自学时的参考样例。1. 图书馆管理系统UML设计先定边界再画流程图书馆管理系统是UML建模最典型的练兵场角色分明读者、图书管理员、系统管理员主流程清晰借书、还书、续借、预约状态离散在馆、借出、预约保留、损坏、丢失全部建模对象都能用一张用例图、一张类图、一组动态图覆盖。很多设计文档的毛病在图多但没对齐——用例图画了十个类图里找不到对应实体顺序图消息满天飞对象类上却没有方法。下面按一线工程顺序展开先用例图圈边界再类图定实体与关系接着用顺序图、活动图和状态图验证流程最后用包图与部署图收口到工程结构并给出Visio绘制与验收技巧。2. 用UML用例图与类图锁定图书馆管理系统边界2.1 用例图先圈参与者与系统边界用例图是图书馆管理系统 UML 设计的第一张图它的作用是回答谁在用、做什么、做到什么程度。实践中先列参与者再为每个参与者列用例。图书馆管理系统的基础参与者有三类读者、图书管理员、系统管理员。如果业务范围包含馆际互借或分馆调拨还需要增加馆际管理员角色。用例图的一种常见文字表示如下--------------------- ----------------------- | 读者 | | 图书管理员 | --------------------- ----------------------- | 登录/注册 | | 图书编目 | | 查询图书 | | 图书上架/下架 | | 借书 | | 办理借书/还书 | | 还书 | | 处理预约 | | 续借 | | 催还与罚款管理 | | 预约 | | 读者证管理 | | 缴纳罚款 | | | --------------------- -----------------------用例之间用 include 和 extend 表达关系。借书用例包含校验读者资格和更新图书状态两个强制步骤用include还书时缴纳超期罚款只在超期时发生用extend挂在还书用例下。判断用例图画没画反的简单标准是include 连的是每次必须执行的公共步骤extend 连的是可选分支。用例图设计阶段最容易出现的两个问题一是把查询图书和高级检索图书拆成两个用例实际后者只是前者的扩展合并即可二是把图书编目拆成录入ISBN、录入书名、录入作者等细碎用例正确的做法是编目作为一个用例字段差别留给类图讨论。2.2 类图核心实体与借阅关系建模用例图里的名词落到类图上就形成了图书馆管理系统的主干实体。最核心的三个类是读者User、图书Book和借阅记录BorrowRecord。在 UML 类图中描述这三个类时属性不必列全关键方法和关键属性应保留public class User { private String userId; // 读者证号 private String name; // 姓名 private UserType userType; // TEACHER / STUDENT / ADMIN private int maxBorrowCount; // 最大可借册数 private int maxBorrowDays; // 最长借期天 public boolean hasBorrowPermission() { /* 校验是否冻结 */ return true; } } public class Book { private String bookId; // 馆藏条码号唯一 private String isbn; // 国际标准书号多本书可相同 private String title; private BookStatus status; // 在馆/借出/预约保留/损坏/丢失 private String shelfLocation; // 馆藏位置 public void changeStatus(BookStatus target) { /* 状态迁移 */ } } public class BorrowRecord { private String recordId; private String userId; private String bookId; private LocalDate borrowDate; private LocalDate dueDate; private LocalDate returnDate; // 为 null 表示未归还 public boolean isOverdue() { return false; } }注意bookId与isbn的差别isbn对应书目信息一本书目可以存在多本复本bookId对应单本馆藏。类图上若不区分这两个标识后端的书目检索和馆藏管理会出现数据不一致。类图里关系线决定了持久层设计。User与BorrowRecord之间是1 --- *的一对多关联Book与BorrowRecord之间同样是1 --- *但在建模当前借出状态时需要把这条记录是否已归还作为限定条件。常见做法是增加一个派生属性current通过查询未归还记录来获得而不是在 Book 类里冗余一个借出状态字段。2.3 类图关系连线的选型与常见误用类图中关系线种类多误用概率最高的是聚合与组合。图书馆管理系统中Book与BorrowRecord适合用聚合关系图书被注销后借阅历史仍然保留两个类的生命周期不同步空心菱形画在整体Book一侧。BorrowRecord与Fine罚款单则适合组合关系罚款单脱离借阅记录没有业务意义删除记录时应一并处理罚单实心菱形画在记录一侧。关系符号UML 语义图书馆例子关联普通直线对象间存在调用/持有引用User 与 Reservation聚合空心菱形整体消失部分仍独立存在Book 与 BorrowRecord组合实心菱形整体消失部分同时销毁BorrowRecord 与 Fine泛化空心三角继承关系Student/Teacher 继承 User依赖虚线箭头临时使用不持有引用BorrowService 依赖 MailUtil泛化关系同样要谨慎只有行为差异明显的子类型才画泛化。如果 Student 和 Teacher 只是借阅数量不同用一个userType字段加配置表就能解决不必建两个子类只有当不同角色拥有不同业务行为时泛化才有建模价值。提示聚合与组合的判据是生命周期。整体没了部分还在是聚合整体没了部分必须一起没是组合。图书馆场景里书注销但借阅流水保留这条规则直接决定了 Book 与 BorrowRecord 之间是聚合。3. UML顺序图与活动图把图书馆借还流程变成时序与分支3.1 借书流程顺序图的消息与返回类图给出了对象顺序图给出对象之间的消息序列。图书馆管理系统的借书流程顺序图是整套 UML 设计中信息量最大的一张图它的消息顺序代表了接口调用顺序读者 - 界面层: 提交借书请求(读者证号, 图书条码号) 界面层 - 图书服务: borrowBook(readerId, bookId) 图书服务 - 读者服务: validateReader(readerId) 读者服务 -- 图书服务: ReaderValid(true/false) 图书服务 - 馆藏服务: queryBookStatus(bookId) 馆藏服务 -- 图书服务: BookStatus(可借/借出/预约保留) 图书服务 - 借阅记录服务: createRecord(readerId, bookId, dueDate) 借阅记录服务 - 馆藏服务: updateBookStatus(bookId, BORROWED) 馆藏服务 -- 图书服务: 更新成功 图书服务 -- 界面层: 借书成功与应还日期 界面层 -- 读者: 展示结果顺序图上的每个消息名都应能对应到类图接收对象的方法名。例如validateReader(readerId)对应User.hasBorrowPermission()createRecord对应BorrowRecord的构造函数或工厂方法。若消息名与类方法对不上要么改顺序图要么改类图最终交付时两张图必须一致。顺序图中的返回消息用虚线箭头调用消息用实线箭头。返回消息上只写返回值不写动作。很多初版顺序图把返回也画成实线箭头一眼看去全是调用实际执行顺序反而看不出来。3.2 还书与续借的活动图分支活动图适合表达分支密集的业务过程。还书流程的活动图是图书馆管理系统中分支最多的图也是容易漏分支的图开始 - 读者提交还书 - 校验是否超期 - 是 - 计算超期罚款 - 否 - 跳过罚款 - 登记还书时间与图书状态 - 检查该书是否有预约 - 有 - 将图书置为预约保留并通知预约者 - 无 - 将图书置为在馆 - 检查读者欠款总额 - 超过阈值 - 冻结读者借书权限 - 未超过 - 保持不变 - 结束至少有三个分支是初稿中常被遗漏的。第一还书时若登记损坏状态不能走在馆分支第二预约者在还书后才被通知通知动作是异步任务活动图里应当用单独的泳道表达而不是和还书登记挤在同一条泳道第三读者累计欠款超过阈值会触发冻结这个动作发生在还书之后属于登记的副作用不画出来的话后续读者服务无法解释明明刚还完书却不能再借的现象。续借的活动图是借书流程的简化版本先检查借出状态再检查是否超期和是否被预约两个验证通过后延长截止日期并记录操作日志。续借分支中被预约的判断往往被遗忘导致预约者长时间等不到书这一点在活动图评审时值得单独点名。3.3 状态图覆盖图书与读者的生命周期图书馆管理系统适合用状态图建模的核心对象是图书。图书的状态迁移如下[在馆] --借出事件-- [借出] [借出] --还书事件-- [在馆] [在馆] --预约事件-- [预约保留] [预约保留] --借出事件-- [借出] [在馆] --损坏登记-- [损坏维修] [损坏维修] --修复完成-- [在馆] [借出] --丢失申报-- [丢失] [丢失] --赔偿处理-- [注销]状态图上的每一个迁移事件必须能在用例图或顺序图中找到触发者。例如预约保留→借出由图书管理员的办理预约借书用例触发在馆→损坏维修由还书活动图中的损坏分支触发。建立这种映射关系之后状态图就具备了校验能力找不到触发者的状态迁移说明业务规则或用例图存在缺口。状态迁移触发事件对应用例对应代码位置在馆 → 借出读者借书成功借书BorrowService.borrowBook借出 → 在馆还书且无预约还书BorrowService.returnBook在馆 → 预约保留读者预约成功预约ReservationService.reserve借出 → 丢失管理员登记丢失丢失处理BookService.markLost读者状态同样需要建模冻结、正常、注销之间有明确的触发关系但通常并入读者类图的状态属性即可不需要单独画一张状态图。只有当状态之间出现多条迁移路径时才值得为读者单独建模。4. UML包图与部署图拆解图书馆管理系统的工程结构4.1 包图按分层依赖组织模块图书馆管理系统发展到一定规模后单张类图已经放不下所有类必须用包图组织宏观结构。最常见的图书馆管理系统包图采用分层架构com.example.library |-- interfaces # 接口层REST 控制器、消息监听器 |-- application # 应用层用例编排事务边界 |-- domain # 领域层实体、值对象、领域服务 |-- infrastructure # 基础设施层数据库、缓存、外部接口 -- common # 公共模块工具类、常量、异常定义包图最重要的约束是依赖方向。interfaces 依赖 applicationapplication 依赖 domaindomain 不依赖 infrastructureinfrastructure 反向依赖 domain 的接口。这种四层划分比传统的 controller-service-dao 三层在 UML 设计中更常见因为它把业务规则和技术实现隔离开图书馆的核心借阅规则不会因为更换数据库或消息队列而改变。包图里还应当体现接口与实现的分离domain 层定义BorrowRecordRepository接口infrastructure 层提供JpaBorrowRecordRepository实现包图用虚线箭头表示依赖。如果包图只画实现而漏了接口后续做单元测试时要用 mock 替换 repository 的工作就找不到依据。4.2 部署图确定节点与通信连接部署图是图书馆管理系统 UML 设计中容易被忽略但项目落地时必须有的图。一套典型的部署结构包含四个节点部署节点承载制品连接方式说明读者客户端浏览器或小程序HTTPS无状态访问不需持久化管理员终端桌面浏览器、扫码枪内网 HTTPS扫码枪通过 USB 输入应用服务器Web 服务、定时任务HTTP/内部 RPC无状态可水平扩展数据服务器书目库、借阅流水库JDBC 连接池主备复制每日备份部署图中的每条连线都要标注协议。数据库连接要注明连接池大小与事务隔离级别消息通知要注明队列名称和失败重试策略。这些内容虽然不是 UML 规范强制要求但标注之后运维才能根据部署图配置监控和告警而不是重新问开发要一份接口文档。实际项目中有一个常见争议图书馆管理系统是否需要一个独立的文件存储节点。建议至少在部署图上预留一个对象存储节点用于存放封面图片和电子资源全部扔在应用服务器本地磁盘的话应用做水平扩展时会出现图片资源不一致。4.3 包图与代码目录的对照验证包图交付后最直接的验证方式是和代码目录逐层对比。以下命令用于检查目录结构和依赖方向# 列出项目的顶层目录对比包图主包结构 find src/main/java -maxdepth 4 -type d | sort # 检查是否出现反向依赖infrastructure 引用了 interfaces grep -r import.*interfaces src/main/java/com/example/library/infrastructure/ 2/dev/null echo 存在反向依赖 || echo 依赖方向正常第一段命令把目录树输出来和包图对比第二段命令用 grep 扫描基础设施包里是否出现接口层的引用。对于更大规模的代码库建议用 ArchUnit 把包图约束写成单元测试每次构建自动执行但 UML 设计评审阶段两条 grep 命令已经足以发现九成以上的依赖越界。5. 用Visio把UML类图画规范并反推设计闭环5.1 Visio绘制UML类图的连线与样式控制用 Visio 绘制 UML 类图的完整路径是新建页选择类别 → 软件和数据库 → UML 类图。进入画布后从左侧模具拖出类形状右键选择形状显示选项勾选属性和操作分区。属性前加-表示 private加表示 public加#表示 protected这直接遵循 UML 规范。关系连线使用模具中的二元关系。连线两端分别粘到两个类别形状的锚点上再通过右键设置端点样式泛化选空心三角且箭头指向父类聚合选空心菱形组合选实心菱形依赖选虚线箭头。多重性直接在线上键入1、0..*、1..*文本。画完需要验证线条是真实连接而非装饰线拖动一个类形状关系线应跟随移动。完成后的图可以直接用文件 → 另存为 → PDF导出配合标题与用例摘要页就是一份可交付的 UML 设计文档。导出前把画布设置为横向并选中所有形状后使用设计 → 大小 → 适应绘图调整画布边界避免 PDF 里出现大片空白。5.2 用核对表反向验证整套 UML 设计画完所有图后用一张核对表完成 UML 设计的最终闭环核对项操作方式常见失败用例图 ↔ 类图每个用例的名词在类图中找实体预约无对应类顺序图 ↔ 类图每个消息名在接收类中找方法消息调用了不存在的方法状态图 ↔ 用例图每个状态迁移找触发用例丢失无赔偿用例包图 ↔ 代码目录目录与包结构逐步对比infrastructure 依赖 interfaces这四组关系全部核对通过后UML 设计文档就可以作为后续开发、测试用例编写和部署评审的基线。把顺序图中的消息签名提取成接口清单把状态图迁移表整理成交互逻辑整套图书馆管理系统的 UML 设计才算真正闭环。本文还有配套的精品资源点击获取