简介这份《图书管理系统UML图》文档面向软件工程课程设计、毕业设计及UML建模学习者提供一套完整的图书管理系统建模案例。内容围绕读者管理、书籍管理、借阅管理与系统管理四大功能模块展开涵盖用例图、用例规约、类图、顺序图、协作图、活动图、状态图及项目部署图等九类UML视图并配有借书、还书、预订等典型流程的详细说明可直接作为课程作业或论文建模部分的参考模板。资源包内共1个docx文件约194KB以图文混排方式呈现各阶段建模成果便于对照学习与二次修改。目前已有2125人学习下载适合需要快速理解UML建模流程、补齐各类图形绘制思路的读者参考借鉴。1. 图书管理系统 UML 图文档11 页里藏着多少能直接抄的建模细节如果你正在做课程设计、准备软考 UML 图试题或者要给导师交一份能过关的图书管理系统设计文档这份 11 页的《图书管理系统 UML 图.docx》大概率能省掉你从零画图的两三天。它不是泛泛讲 UML 语法的科普而是拿一个完整的图书管理系统当靶子把用例图、用例规约、类图、顺序图、协作图、活动图、状态图、部署图一路画到底。参与者只有读者和管理员两个用例覆盖登录、书籍管理、借阅管理、读者管理、自动借书机连找回密码这种 extend 关系都标了。适合谁适合需要一份结构完整、关系清晰、能直接对照着改的 UML 案例的人。不适合谁不适合想找现成可运行代码的人——这份文档给的是设计图纸不是施工队。2. 用例图与用例规约从参与者到事件流的完整推演2.1 参与者识别与用例边界划分拿到一个系统先别急着画框第一步是找参与者。这份文档的做法很干脆图书管理系统的参与者就两个——读者和管理员。为什么不是三个因为自动借还机在文档里被归到系统管理功能下没有独立成参与者。这个判断在课程设计里很关键多一个参与者就多一组用例关系画错了后面全得返工。管理员的用例包括登录系统、书籍管理增删改查、书籍借阅管理借书、还书、预订、逾期处理、丢失处理、读者管理增删改查。读者的用例包括登录、借书、还书、查询个人信息和书籍信息、预订、逾期处理缴纳罚金、书籍丢失处理、自动借书机使用。这里有个容易翻车的地方读者和管理员的用例有重叠比如登录和查询。文档的处理方式是分开列但在用例图里通过系统边界来区分。常见做法是画一个系统框把管理员和读者分别放在左右两侧重叠用例只画一次用关联线连到两个参与者。如果你把登录画两遍用例图会显得很乱答辩时容易被问“这两个登录有什么区别”。文档里还标了两个 extend 关系找回密码 extend 登录缴纳罚金 extend 逾期处理。extend 的方向别画反了——是扩展用例指向基用例箭头从找回密码指向登录。这个细节在软考 UML 图试题里经常考画反了直接扣分。2.2 借书用例规约的字段拆解与异常流设计用例规约是很多人会跳过的一步觉得画完用例图就完事了。但这份文档把借书用例规约写得很完整基本事件流六步异常事件流三条。我把它拆成表格方便对照字段内容实操注意用例名称借书动词开头别写“借书管理”用例 IDUC01编号要唯一后面顺序图引用用例说明读者通过管理员借书一句话说清主角和目的前置条件管理员已登录不满足则用例无法启动基本事件流扫描借阅证→显示读者信息→显示借阅记录→扫描图书→加入借阅记录→更改馆藏数量步骤要可观测别写“系统处理”异常事件流扫描仪损坏手动输入借阅额度满终止有超期未还终止每条异常要有触发条件和处理动作后置条件无借书成功后馆藏数量已更新基本事件流里第 6 步“重复 3、4、5 直到借阅完成”是个循环画顺序图时要用 loop 组合片段表示。异常流 2a 和 2b 是条件分支顺序图里用 alt 片段。这些在文档的顺序图部分有对应体现但规约里先写清楚画图时才有依据。提示用例规约里的异常流不是凑数的。答辩时老师最爱问“如果扫描仪坏了怎么办”你规约里写了就能直接答。3. 类图与顺序图名词分析法落地与消息传递链路3.1 名词分析法提取类与关系标注文档明确写了类图的画法名词分析法。操作步骤两步——先从功能描述或事件流里找名词筛选后形成类再确定类和类之间的关系。从借书用例规约的基本事件流里能提取出这些名词借阅证、读者信息、图书信息、借阅记录、馆藏数量。结合功能描述里的读者、书籍、管理员、出版社、借阅信息最终形成的类包括读者、图书、借阅信息、管理员、出版社。关系标注是类图最容易出错的地方。文档里给了多重性读者和借阅信息是 1 对 n图书和借阅信息是 1 对 n管理员和借阅信息是 1 对 n出版社和图书是 1 对 n。这些多重性不是随便写的——一个读者可以有多条借阅记录一本书可以被多次借阅一个管理员可以处理多笔借阅一个出版社可以出版多本书。类的属性和方法也要落到具体。比如读者类属性有姓名、学号、班号、借书证号方法有查询读者信息、增加读者信息、修改读者信息、删除读者信息。图书类属性有编号、书名、价格、作者、出版社、出版时间方法有增加图书、修改图书信息、删除图书信息、查询图书信息、借书、还书、预定图书、续借。这里有个血泪经验方法名别写“操作图书”这种模糊词要写清楚是增删改查还是借还。不然后面画顺序图时消息名对不上类的方法图就断了。3.2 借书顺序图的消息编号与对象生命线顺序图是动态视图的核心。文档里借书顺序图的对象包括管理员、借书界面、借书处理管理器、读者、图书、借阅信息。消息传递链路是这样的1. 管理员 - 借书界面: 输入借书信息 2. 借书界面 - 借书处理管理器: 读取读者及借阅信息 3. 借书处理管理器 - 读者: 读取读者信息 4. 读者 - 借书处理管理器: 返回读者信息 5. 借书处理管理器 - 借阅信息: 读取借阅信息 6. 借阅信息 - 借书处理管理器: 返回读者借阅信息 7. 管理员 - 借书界面: 输入图书编号 8. 借书界面 - 借书处理管理器: 检索图书信息 9. 借书处理管理器 - 图书: 检索图书 10. 图书 - 借书处理管理器: 返回图书详细信息 11. 借书处理管理器 - 借阅信息: 记录借阅信息这段消息流对应借书用例规约的基本事件流。注意第 3 步和第 9 步的区别读取读者信息是同步消息检索图书也是同步消息但返回消息用虚线箭头。顺序图里同步消息用实心箭头返回消息用虚线箭头异步消息用开放箭头。这份文档的顺序图虽然没在正文里标箭头类型但按标准画法读取和检索都是同步调用。还书顺序图的结构类似但消息流不同扫描图书条形码→获取图书及借阅信息→获取图书信息→获取借阅信息→修改借阅信息→更新图书信息→还书成功。这里的关键是“修改借阅信息”和“更新图书信息”是两个独立操作前者改借阅记录状态后者改图书的馆藏数量。注意顺序图里的对象名要和类图里的类名一致。类图里叫“借阅信息”顺序图里别写成“借阅记录”不然后面协作图对不上。4. 协作图、活动图与状态图动态行为的三种视角4.1 协作图从顺序图转换的对象绑定文档里有一句很实用的话“按 F5 可以将顺序图转换为协作图”。这说明文档作者用的建模工具支持一键转换。协作图和顺序图表达的是同一件事只是视角不同——顺序图强调时间顺序协作图强调对象之间的结构关系。借书协作图的对象包括管理员、借书界面、借书处理管理器、读者、图书、借阅信息。消息编号和顺序图一致但布局方式不同对象之间用连线表示关联消息标在连线上。文档里还书协作图的消息流是扫描图书条形码→获取图书及借阅信息→获取图书信息→获取借阅信息→修改借阅信息→更新图书信息→还书成功。如果你手动画协作图注意消息编号的层级。比如 1、2、3 是顶层消息1.1、1.2 是嵌套消息。文档里的协作图没有标嵌套编号但顺序图里有循环和条件协作图里可以用编号前缀表示。4.2 借书与还书活动图的判定节点活动图是文档里画得比较细的部分。借书活动图的流程是扫描借书证→是否合法→显示读者及借阅信息→已借图书少于规定册数→没有过期未还图书→扫描图书信息→更新图书信息及读者借阅信息→借书成功。判定节点有两个是否合法、已借图书少于规定册数、没有过期未还图书。这三个条件任何一个不满足流程就终止或走异常分支。还书活动图的流程是扫描图书条形码→显示图书信息→是否过期→更新读者信息和图书信息→还书成功。如果过期走缴纳罚金分支。预定图书活动图的流程是扫描图书条形码→显示图书信息→是否过期→更新读者信息和图书信息→还书成功。这里文档里写的是“还书成功”但预定图书的活动图终点应该是“预定成功”可能是文档笔误。活动图的判定节点用菱形表示合并节点也用菱形。文档里的 Y/N 标注就是判定条件的分支。画活动图时每个判定节点要有明确的条件表达式别只写“是/否”要写“借阅额度已满/未满”这种具体条件。4.3 图书状态图的状态迁移与触发事件状态图是文档里比较短但很关键的一部分。图书状态有四个空闲、已借出、已预约、借阅预约续借还书借阅取消/超时。状态迁移关系是空闲→已借出借阅、已借出→空闲还书、已借出→已预约预约、已预约→已借出借阅、已预约→空闲取消/超时、已借出→已借出续借。这里有个细节续借是自循环迁移触发事件是续借动作是更新应还日期。取消/超时是从已预约回到空闲触发事件是取消或超时。状态图里每个迁移都要标触发事件不然状态图就没有意义。提示状态图适合描述单个对象的行为。图书的状态变化比读者简单所以文档只画了图书状态图。如果读者也有状态比如正常、冻结、注销也可以画一张。5. 部署图与建模避坑从视图层到数据库服务器的落地检查5.1 部署图的节点划分与构件分布部署图是文档的最后一类图。节点有三个客户端、Web 服务器、数据库服务器。客户端标注了 IE、FireFox、谷歌浏览器等Web 服务器标注了 Tomcat、JDK、Eclipse数据库服务器标注了 MySQL。构件分布是视图层、控制层、DAO、VO 在 Web 服务器和数据库服务器之间分布。这里有个容易混淆的地方视图层、控制层、DAO、VO 是构件不是节点。节点是客户端、Web 服务器、数据库服务器。构件部署在节点上。文档里的写法是把构件名写在节点框里这是标准画法。但要注意视图层通常在客户端和 Web 服务器都有——客户端是浏览器渲染Web 服务器是 JSP/Servlet 生成。文档里把视图层放在 Web 服务器侧这是合理的简化。部署图里节点之间的通信协议也要标。客户端到 Web 服务器是 HTTP/HTTPSWeb 服务器到数据库服务器是 JDBC。文档里没标协议但实际画的时候建议补上不然部署图不完整。5.2 用例关系与类图多重性的常见错误避坑部分来了。这份文档虽然结构完整但照着画的时候有几个地方容易翻车。现象一extend 和 include 用反。文档里找回密码 extend 登录缴纳罚金 extend 逾期处理。extend 是扩展关系基用例不知道扩展用例的存在include 是包含关系基用例必须执行被包含的用例。如果你把找回密码画成 include 登录意思是每次登录都必须找回密码逻辑就错了。解决方式记住 extend 是可选扩展include 是必须包含。现象二类图多重性标反。读者和借阅信息是 1 对 n意思是 1 个读者对应 n 条借阅信息。如果你标成 n 对 1意思是 n 个读者对应 1 条借阅信息那就成了多个读者共享一条借阅记录显然不对。解决方式从业务语义出发一个读者可以借多本书所以是 1 对 n。现象三顺序图消息编号跳号。文档里的顺序图消息编号是连续的但如果你自己加消息记得编号要连续。跳号会让读者以为漏了步骤。解决方式画完顺序图后从头到尾检查一遍编号。现象四活动图判定节点没有合并。借书活动图里“是否合法”判定后如果走 N 分支流程应该终止或回到起点。文档里没有明确画终止节点但实际画的时候要加。解决方式每个判定节点的每个分支都要有明确的去向要么继续要么终止。现象五部署图节点和构件混淆。把 Tomcat 画成节点把 Web 服务器画成构件就反了。节点是物理设备或运行环境构件是软件模块。解决方式节点用立方体构件用矩形加两个小矩形。6. 从 UML 图到代码骨架用类图生成 Python 实体类的验证方法最后一章落到一个具体技巧怎么用这份文档里的类图快速生成代码骨架验证你的类图设计是否合理。我一般会拿类图里的类、属性、方法直接翻译成 Python 类跑一遍看有没有逻辑漏洞。# 根据类图生成的图书管理系统实体类骨架 # 类名、属性、方法均来自文档中的类图描述 class Reader: 读者类对应类图中的读者 def __init__(self, name: str, student_id: str, class_id: str, card_id: str): self.name name # 姓名 self.student_id student_id # 学号 self.class_id class_id # 班号 self.card_id card_id # 借书证号 self.borrow_records [] # 借阅记录对应 1 对 n 关系 def query_info(self): 查询读者信息 return f{self.name} {self.student_id} def add_info(self): 增加读者信息 pass def update_info(self): 修改读者信息 pass def delete_info(self): 删除读者信息 pass class Book: 图书类对应类图中的图书 def __init__(self, book_id: str, title: str, price: float, author: str, publisher: str, publish_date: str): self.book_id book_id # 编号 self.title title # 书名 self.price price # 价格 self.author author # 作者 self.publisher publisher # 出版社 self.publish_date publish_date # 出版时间 self.status 空闲 # 状态对应状态图 def add_book(self): 增加图书 pass def update_book(self): 修改图书信息 pass def delete_book(self): 删除图书信息 pass def query_book(self): 查询图书信息 pass def borrow(self): 借书状态从空闲变为已借出 if self.status 空闲: self.status 已借出 return True return False def return_book(self): 还书状态从已借出变为空闲 if self.status 已借出: self.status 空闲 return True return False def reserve(self): 预定图书状态从空闲变为已预约 if self.status 空闲: self.status 已预约 return True return False def renew(self): 续借状态不变更新应还日期 if self.status 已借出: # 实际项目中这里要更新应还日期 return True return False class BorrowInfo: 借阅信息类对应类图中的借阅信息 def __init__(self, book_id: str, reader_id: str, borrow_date: str, due_date: str, operator: str): self.book_id book_id # 书号 self.reader_id reader_id # 借阅人 self.borrow_date borrow_date # 借阅日期 self.due_date due_date # 应还日期 self.operator operator # 操作员 def add_record(self): 增加借阅信息 pass def update_record(self): 修改借阅信息 pass def delete_record(self): 删除借阅信息 pass def query_record(self): 查询借阅信息 pass class Admin: 管理员类对应类图中的管理员 def __init__(self, admin_id: str, name: str, birth_date: str): self.admin_id admin_id # 工号 self.name name # 姓名 self.birth_date birth_date # 出生日期 def add_admin(self): 增加管理员 pass def update_admin(self): 修改管理员 pass def delete_admin(self): 删除管理员 pass def query_admin(self): 查询管理员 pass class Publisher: 出版社类对应类图中的出版社 def __init__(self, name: str, phone: str, address: str, contact: str): self.name name # 出版社名称 self.phone phone # 联系电话 self.address address # 联系地址 self.contact contact # 联系人 def add_publisher(self): 增加出版社信息 pass def update_publisher(self): 修改出版社信息 pass def delete_publisher(self): 删除出版社信息 pass def query_publisher(self): 查询出版社信息 pass这段代码的逻辑说明每个类对应类图里的一个类属性对应类图的属性方法对应类图的方法。借书、还书、预定、续借四个方法直接映射状态图里的迁移。参数说明book_id 是图书编号reader_id 是借阅人编号borrow_date 和 due_date 是日期字符串operator 是操作员工号。跑一遍这个骨架你会发现几个问题第一借阅信息类没有和读者类、图书类建立关联实际项目中需要用外键或对象引用关联。第二状态图里的“取消/超时”迁移没有对应方法需要补一个 cancel_reserve 方法。第三续借方法没有更新应还日期的逻辑实际项目中要加日期计算。验证方法很简单把类图里的每个类翻译成代码看有没有类之间无法关联、方法无法实现、状态无法迁移的情况。如果有说明类图设计有漏洞回去改图。这个习惯我每次做 UML 建模都强制走一遍比单纯看图靠谱得多。从那以后我每次画完类图都会先翻译成代码骨架跑一遍确认没有悬空的方法和断裂的关系再回头补顺序图和活动图。希望帮到你。本文还有配套的精品资源点击获取