简介武汉理工大学《UML建模技术》课程实验报告以图书管理系统为例记录了从系统需求分析、参与者与用例识别到用例文本编写、StarUML用例模型建立的全过程适合软件工程专业学生、UML初学者及需要完成类似课程设计的人群参考。报告将系统划分为学生管理、书籍管理、系统管理三大模块识别出学生、图书馆管理员、系统管理员三类参与者并围绕借阅图书、归还图书、查询借阅信息、系统维护等核心用例展开给出了详细的主事件流与备选事件流处理便于读者对照理解用例图落地时的细节。资源为单份PDF文件约563KB内容含实验目的、方案、调试过程、用例文本、用例图及小结结构完整可快速定位到建模每一步成果。目前已有792人学习可作为UML实验报告模板、StarUML工具实践参考或软件建模课程复习材料。1. 一份能照着复现的 UML 实验报告图书管理系统建模全流程如果你的 UML 课程作业正好落在“图书管理系统”上这份武汉理工的实验报告值得花半小时拆一遍。它记录的不是高深理论而是一个软件工程专业学生用 StarUML 完成图书管理系统建模的全过程先写用例文本再画用例图、领域类图最后落到顺序图和设计类图四轮实验一环扣一环。对还在纠结“用例图怎么画才规范”“类图要不要写操作”的人这份报告提供了可以直接照抄的答案也是期末和软考案例分析题的现成范本。它适合三类人正在被 UML 作业追赶的学生、准备期末考或软考的考生以及想把 UML 建模规范重新捡起来的一线开发。2. 用例文本先行参与者、事件流与用例图落地实验一叫“静态模型 1”做的却是用例模型这个命名是学校课程的叫法不用较真。真正值得学的是它的顺序先分析需求再识别参与者与用例然后写用例文本最后才打开 StarUML 画图。很多人在这一步就翻了车一上来就拖图元结果画出来的用例图逻辑站不住。这份报告给出的正确姿势是把用例文本当成核心产物图形只是它的可视化表达。2.1 需求拆解三大模块如何映射到参与者报告把图书管理系统的需求分成三大块学生管理、书籍管理、系统管理。这三个模块不是平行关系学生管理只负责生成借阅证书籍管理覆盖借阅、归还和查询借阅信息系统管理则是后台的“管理员的管理”包括办理借阅证、删除借阅证、添加或删除管理员、添加或删除图书和标题信息。注意这里有个小重叠学生管理里说生成借阅证系统管理里又出现办理借阅证复现时我会把借阅证的生成和办理统一归到系统管理避免用例归属扯不清。模块职责关键操作学生管理与学生相关的身份凭证生成借阅证书籍管理图书借还主流程借阅图书、归还图书、查询借阅信息系统管理后台数据和人员维护办理/删除借阅证、增删管理员、增删图书与标题信息基于这三块需求报告识别出三个参与者学生、图书管理员、系统管理员。参与者不是“人”本身而是人在系统里扮演的角色。学生是借阅业务的发起者但在用例图里他并不直接操作系统图书管理员是借还书两个核心用例的主要参与者系统管理员只在“超控模式”和系统维护时出现。搞清楚这个边界后面画用例图时才知道谁跟谁连线不会把学生直接连到“系统维护”上。判断参与者的最简标准是看两条他是否直接与系统交互他是否有独立于其他人的目标。按这个标准“图书”不是参与者它是被操作的对象“借阅证”也不是参与者它是学生身份的凭证。这三个参与者的划分直接对应到用例图里三个最外层的角色框。2.2 借阅用例文本主成功场景和五条扩展流报告最值钱的部分是实验一里的用例文本尤其是“借阅图书”这个用例。它完整写了范围、级别、主要参与者、涉众及关注点、前置条件、成功保证以及主成功场景的九个步骤。这个格式本身就是 UML 用例描述的规范模板期末卷子和软考案例分析里让你“补全用例描述”补的就是这些东西。用例 UC1借阅图书 前置条件图书管理员已经过确认与认证学生拥有借阅证 主成功场景 1 学生携带所借书籍与借阅证到办理处 2 图书管理员开始办理借阅手续 3 图书管理员向系统输入学生的借阅证号 4 系统验证借阅证号有效 5 系统检验该账户中的借阅信息验证成功 6 系统显示学生信息提示管理员输入图书信息 7 图书管理员输入要借阅的图书信息 8 系统记录借阅信息更新学生账户完成借书 9 学生携带书籍离开 扩展流 *a 系统管理员在任何时刻要求进入超控模式执行系统管理操作 *b 系统在任何时刻失败管理员重启系统并请求恢复上次状态 2a 恢复过程中检测到异常系统提示错误并进入初始状态 4a 系统验证借阅证无效提示不存在该账户管理员让学生重新注册 5a 系统检测到借阅数量超过规定提示并结束本次借阅 5b 系统检测到有超期未归还图书提示并结束本次借阅这段模板有两点值得抄。第一扩展流的编号直接挂到主流程的步骤号上比如 4a 挂在“系统验证借阅证号有效”这一步5a、5b 挂在“系统检验借阅信息”这一步。这样评审老师一眼就能看出异常发生在哪一个环节。第二扩展流分成了两类一类是环境和权限异常比如系统失败、管理员超控另一类是业务规则异常比如借阅证无效、借阅超量、超期未还。考试写用例文本时两类各写一到两条就足够拿分这份报告写了五类已经超出课程要求了。唯一的小瑕疵是编号嵌套2a 是挂在 *b 系统失败下的一层子扩展报告直接写成“2a”真正规范的写法应该是 *b 之下的 *b1 或 *b.1。复现时把这种子扩展单独编号清晰度会明显提升。2.3 StarUML 里把文本变成用例图用例文本写完后画用例图就是纯粹的搬运工作。常见做法是打开 StarUML新建一个 Use Case Diagram从左侧工具箱拖出 Actor 和 UseCase 图元再按文本里的关系连线。参与者“学生”“图书管理员”“系统管理员”放在矩形框外四个用例“借阅图书”“归还图书”“查询借阅信息”“系统维护”放在框内然后按参与者与用例的交互关系画关联线。借阅和归还都由图书管理员发起所以这两个用例只连图书管理员不直接连学生。系统维护连系统管理员。查询借阅信息这一类需要 include 关系标注成借阅流程的子流程扩展流用 extend 关系挂在主流程的扩展点上。include 和 extend 的方向不要画反——include 指向被包含的公共子用例extend 从扩展用例指向被扩展的基础用例具体判断方法放到避坑章细说。提示先写完用例文本再画用例图画图只是把文本搬到图形里。文本里一句话对应图上一条线文本里没有的流程图上也别硬加。3. 领域模型搭建把用例文本翻成类图的关键动作实验二的产出是领域模型用的是类图表达。这一步的核心不是画图而是从用例文本里抽领域类和关联。报告里已经给出了完整的结果但很多读者抄完类图却说不清这些类是怎么来的。这里拆一下推导过程。3.1 名词划线法从用例文本里捞领域类最常见的做法是“名词划线法”把用例文本里的业务名词全部圈出来去掉明显属于属性描述的词汇剩下的独立业务概念就是领域类。报告从借阅、归还、查询、维护这些用例里圈出了六个领域类图书、账户、借阅证、学生、图书管理员、系统管理员。领域类原文给出的属性复现时可以补充图书书名、在馆信息图书编号、作者、ISBN、馆藏数量账户账号、密码、借书数目、借书时间、借书书名账户状态、已借数量上限借阅证姓名、系别、借阅证号有效期、发证日期学生姓名、系别学号、联系方式图书管理员编号姓名、岗位系统管理员无原文为空编号、权限等级原文的属性粒度很粗糙但方向是对的。图书只给书名和在馆信息这是借用例文本本身出现过的词账户里放了借书数目、借书时间、借书书名严格说这三样东西应该拆成一个“借阅记录”类课程实验没拆可以接受但如果你要拿这套模型去做后续的设计我建议拆。借阅记录关联账户和图书两个类才是真正的借阅关系表达。3.2 关联如何提取从动词短语找出关系领域类的第二类是关联。报告列了十个关联全部是从用例文本的动词短语里找出来的学生注册账号、账号生成借阅证、图书管理员验证账户、图书管理员更新账户、系统管理员添加账户、系统管理员删除账户、系统管理员添加图书管理员、系统管理员删除图书管理员、系统管理员添加图书、系统管理员删除图书。这些短语可以直接转成类图上的关联线。规则很简单名词短语两端各对应一个类动词短语决定关联名方向由句子主宾决定。“学生注册账号”就是 Student 到 Account 的一条关联方向上学生是发起者“账号生成借阅证”就是 Account 到 LibraryCard 的关联。像“系统管理员添加图书管理员”这类后台维护操作在领域模型阶段也可以先不画因为它是权限操作而不是业务实体关系画多了会把类图搞乱。报告没有标关联的多重性这是比较吃亏的地方。正式类图里多重性是需要标注的我一般会补学生和账户是 1 对 1账户和借阅证是 1 对 1账户和图书是多对多一个账户可以借多本一本图书可以被多人借过图书管理员和图书之间是 1 对多一个管理员可以处理多本图书的借还。标上多重性这张图才算真正具备了面向对象建模的信息量。3.3 领域类图与设计类图的第一次分界实验二到实验四之间有一个很容易被忽略的分界领域类图只关心属性和关联不关心操作设计类图必须补上操作。报告在实验四里也点明了这一点——实验二的模型里每个类只有相应属性与类间关联每个类含有什么操作并没有明确。很多学生就是在这一步把两张图画成了一样的东西。领域模型回答的是“系统里有什么”设计模型回答的是“这些对象能做什么”。图书在领域模型里只有书名和在馆信息到了设计类图里就要有查询库存、更新在馆状态这类操作账户在领域模型里只有账号密码和借阅信息到了设计类图里就要有验证借阅证、增加借阅记录、删除借阅记录这些方法。如果在画领域类图的时候过早加操作图的层次就乱了。4. 动态模型补全顺序图、设计类图与消息的来回校验实验三和实验四合起来完成了动态模型。报告先用顺序图描述借书和还书的交互过程再把顺序图里的消息转成设计类图的操作。这两步是连在一起做的顺序图告诉你要有哪些操作设计类图告诉你要有谁来执行这些操作。4.1 借书顺序图和还书顺序图怎么读顺序图的读法在报告里写得很清楚纵向是时间轴时间沿竖线向下延伸横向是参与协作的对象的生命线。当对象存在时用一条虚线表示生命线当对象的过程处于激活状态时生命线变成双道线。理解了这个二维结构再看图和画图都不会跑偏。借书顺序图的消息序列可以还原成这样学生把书交给图书管理员图书管理员向系统输入借阅证号系统验证借阅证有效系统显示学生信息图书管理员输入图书信息系统记录借阅信息并更新学生账户。这一串消息和用例文本 UC1 的主成功场景几乎是一一对应的只是把文本里的自然语言换成了对象之间的消息。还书顺序图的消息序列则相对简单学生把书交给管理员管理员向系统输入图书信息系统验证该图书是本馆藏书系统删除相应的借阅信息系统更新学生账户。注意归还流程里没有“验证借阅证”这一步因为还书不强制要求验证学生身份但借书必须验证。这个差异很容易画错照抄文本时往往会把两套消息画成一模一样。4.2 从顺序图反推设计类图的操作顺序图画完设计类图的操作就有来源了。核心方法很机械顺序图里每个指向接收对象的入向消息几乎都会变成接收对象类上的一个操作。这是顺序图和设计类图之间的“翻译规则”。顺序图中的消息接收对象设计类图上对应的操作输入借阅证号账户validateLibraryCard()验证该图书是本馆藏书图书verifyInCollection()记录借阅信息账户addBorrowingRecord()删除相应的借阅信息账户removeBorrowingRecord()更新学生账户学生updateAccount()报告在实验四里把类图里的中文全部改成了英文还特别说了一句“希望能有助于与书本接轨”。这个动作看起来只是翻译实际上是一条必由之路类图一旦进入设计阶段类名、属性名、操作名必须按代码规范来写中文类名在后面的编码阶段没法直接用。所以你在复现的时候直接从设计类图阶段就用英文命名省得后面返工。4.3 顺序图和设计类图的协同校验静态模型和动态模型不是两张孤立的图。顺序图新增一条消息设计类图就要有对应的操作反过来如果设计类图上某个操作在顺序图里找不到任何消息来源说明这个操作是多余的要么删掉要么回顺序图里补交互。报告虽然没有把这条规则写出来但它的实验四是“完善顺序图并建立设计类图”这两个动作本来就应该交替进行。我做这类建模时有个习惯顺序图画完先不急着画类图而是先把消息清单列出来每个消息写成“接收对象.操作名”的格式再把清单贴到设计类图旁边逐条比对。这样两套图能做到消息和操作一一对上老师挑毛病也挑不出来。如果想进一步把扩展流也表达出来可以在顺序图里用 Combined Fragment 的 alt 框表示“借阅证无效”和“超期未还”这两个分支课程作业做到这一步已经属于加分水平了。5. StarUML 建模避坑四个最容易翻车的地方这一章写的是血泪经验。报告本身没有踩坑记录但凡是自己动手用 StarUML 画过一遍的人基本都在这几个地方栽过跟头。5.1 include 和 extend 方向画反现象用例图上“借阅图书”和“查询借阅信息”之间、以及借阅流程和超期处理之间的连线方向经常画反。查询借阅信息被 extend 到借阅图书上超期处理被 include 进来图看起来就特别别扭。原因include 和 extend 的语义容易混淆。include 表示基础用例在执行时必须包含某个子流程extend 表示在某些条件下可能会进入的扩展流程。查询借阅信息是借阅流程里必然要走的一个步骤所以是 include超期检测是满足特定条件才触发所以是 extend。解决画之前先问一句“这个用例是不是每次都会执行”。每次都会执行的用 include箭头从基础用例指向被包含用例有条件才触发的用 extend箭头从扩展用例指向基础用例。5.2 设计类图只画属性不画操作现象实验四交上去的设计类图老师看了一眼说“这不就是实验二的领域类图吗”。领域类和设计类连评价都没有直接被打回。原因很多人照抄实验二的类图属性照样填关联照样连就是忘了加操作。设计类图的价值就在于把顺序图里的消息沉淀成方法没有操作的方法类图就退回了领域模型。解决做完顺序图之后按照 4.2 的“消息转操作”规则逐个类去补。每个类至少有一个操作操作名用英文动词开头。补完再反向检查一遍顺序图里出现的每条消息是否都能在设计类图上找到对应操作。5.3 顺序图消息顺序和用例文本对不上现象顺序图画得很漂亮但一比对用例文本发现验证账号的步骤跑到了输入图书信息之后还书流程里多了一步验证学生身份消息顺序完全对不上文本。原因画顺序图时凭印象画没有再翻回用例文本逐步对照。顺序图的消息序列本质就是用例文本主成功场景的重新排版文本里的步骤顺序是不能随便调整的。解决画每条消息时都标注它对应主成功场景的第几步按编号从小到大排。还书顺序图尤其要注意UC2 里没有验证学生借阅证这个步骤别凭借书经验脑补进去。5.4 StarUML 版本差异导致导出图没法用现象同一个 .mdj 文件在旧版本 StarUML 里打开后中文变乱码导出图片时文字重叠图元位置全乱。换到新版打开又出现工具栏找不到的情况。原因StarUML 各个大版本的界面和渲染逻辑有差异早期版本对中文支持不完整导出图片的分辨率和比例控制也很差属于“能用但不好用”的级别。解决建模文件用哪个版本建的就一直用同一个版本打开。导出图片之前先在编辑器里把注释和文字字号统一调大再调整图元间距最后用 File → Export Diagram 导出不要直接截图。如果你用的是老版本且中文乱码可以全部改用英文命名这也是报告里实验四采用的思路。5.5 关联名偷懒把动词丢掉现象类图上的关联线只有一条线没有关联名或者直接写“关联”“关系”这种没有信息量的词。老师问这条线是什么意思答不上来。原因画关联线时只关心类之间“有关系”不关心具体是什么关系。关联名的价值在于精确表达关系语义“学生注册账号”和“系统管理员删除账号”虽然都连接学生和账户两个类但语义完全不同类图上必须区分。解决每条关联线都标上动词短语。如果一条线上有两三个动词并列比如“添加/删除”说明这个关联承载了太多职责应该把后台管理类操作从业务实体关联里拆掉保持类图的单一语义。6. 拿到手的验证路径按四步把报告复现一遍6.1 一周目复现清单拿到这份 PDF别急着从头到尾读一遍就完事。最有效的用法是把它当参考答案自己动手把四个实验完整走一遍。下面这份检查清单是我从报告里提炼的验收标准每完成一个环节就勾一项[ ] 用例文本每个重要用例都有前置条件、主成功场景、扩展流三件套 [ ] 用例图参与者和用例能对照文本逐条对上include/extend 方向正确 [ ] 领域类图每个领域类有属性类间有带动词的关联名 [ ] 顺序图消息顺序与用例文本主成功场景逐条对应 [ ] 设计类图每个类有操作操作来源可追溯到顺序图消息6.2 这套流程怎么变成课程设计和软考能力这套方法的可迁移性很强。下一次课程设计不管换成“学生选课系统”还是“网上商城订单管理”建模步骤都是这五步拆需求模块、识别参与者、写用例文本、画用例图、抽领域类、补动态模型。软考系统分析师和系统架构设计师的案例分析题里经常给一段需求描述让你补全用例图或类图答题范式跟这份报告完全一致——先在草稿纸上把参与者和用例列出来再写事件流最后才动笔画图。我后来做任何一个小系统的设计都强制自己先把用例文本写满一张 A4 纸再打开建模工具。这个习惯帮我避开了很多返工文本写清楚了图只是搬运文本没写清楚图一定是乱画。希望这份报告的拆解对你有用也希望你复现完之后能比照着抄多走一步——把图书管理系统换成你自己手头的项目重新走一遍这五步那才算真正把 UML 建模装进了自己的工具箱。本文还有配套的精品资源点击获取