简介一份武汉理工大学UML建模技术课程实验报告主题为图书管理系统建模适合软件工程专业学生、UML初学者及需要完成课程设计或实验报告的学习者。报告基于StarUML工具完整呈现从系统需求分析、参与者与用例识别、用例文本编写到用例模型建立的整个流程内容覆盖学生管理、书籍管理、系统管理三个功能模块并针对“借阅图书”“归还图书”等核心用例详细写出主成功场景与扩展/异常分支还绘制了对应用例图。资源规模为1个PDF文件约563KB包含实验目的、实验方案、调试过程、用例图、实验结果分析及实验小结结构完整、可直接阅读适合作为实验参考或答辩备查材料。目前已有792人学习下载有助于读者理解UML静态建模方法并学会用StarUML将需求转化为规范、可验证的用例模型。1. 为什么一本UML实验报告还值得翻如果你手里正好有一份《武汉理工UML实验——图书管理系统.pdf》大概率是冲着两个目的来的要么是软件工程课程作业需要“参考”用例图和类图画法要么是想搞明白StarUML在一套完整建模流程里到底怎么用。这份实验报告的价值不在结论有多高级而在于它完整走了一遍“需求分析→用例建模→领域模型→顺序图→设计类图”的软件工程主链路而且用的是图书管理系统这种边界清晰、规则不复杂的业务域非常适合用来验证你对UML符号语义的理解是否准确。我见过不少人画用例图时把“数据库”画成参与者或者把“系统维护”当成一个普通用例堆在系统边框里然后在答辩时被问住。这份报告里有一个很容易被忽略的正确示范系统维护被放进了扩展流程的“超控模式”而不是当成并列用例。这种细节才是值得反复琢磨的地方。文章后面我会把实验里借阅图书用例的主成功场景和备选流拆开讲并给出StarUML里对应的操作要点以及把它翻译成PlantUML文本时的等价写法方便你对照着画自己的图。2. 从用例文本到用例图先把“借阅图书”写清楚2.1 识别参与者与用例别把“系统维护”塞进角色里实验报告里给出的参与者只有三个学生、图书管理员、系统管理员。没有把“数据库”或者“时间”当作参与者这是对的。参与者必须是与系统交互并期望获得价值的角色数据库是系统内部的实现组件不是外部角色。学生在这里是间接参与者因为学生不直接操作系统而是通过图书管理员完成操作但用例图里学生依然画在系统外面因为借阅这项服务最终服务于学生。用例的识别要跟着参与者的目标走。报告里归纳出四个顶级用例借阅图书、归还图书、查询借阅信息、系统维护。其中系统维护其实是系统管理员的目标但它被处理成扩展流里的“超控模式”而不是一个高性能的独立用例。这样设计的好处是借阅图书的主流程不会被“管理员中途插入操作”这类分支打断主成功场景保持线性推进备选流专门记录异常和穿插行为。画用例图时这种“主场景干净、扩展场景挂分支”的策略值得直接抄。我用下面这个表格整理实验一识别出的核心元素画图前先列这个表比直接开画更不容易漏。元素类型名称说明参与者学生携带借阅证委托管理员完成借阅和归还参与者图书管理员操作系统的核心角色负责借阅、归还、查询参与者系统管理员维护系统处理借阅证和管理员账户用例借阅图书主成功场景 4个备选分支用例归还图书主成功场景 3个备选分支用例查询借阅信息报告略写但通常包含按学号/按图书查询用例系统维护通过超控模式进入属于系统管理员的操作集合2.2 用例文本里的主成功场景与备选流写用例文本最容易犯的错是把“系统怎么做”写在主流程里而不是写“用户与系统之间的交互”。实验报告里借阅图书的主成功场景是九步从学生携带书籍到达办理处开始到管理员输入借阅证号系统验证账户再录入图书信息最后更新账户完成借阅。每一步都是可观察、可验证的交互动作没有出现类似“系统计算剩余可借数量”这种内部逻辑。关注点在于备选流的编号方式。报告里用了4a、5a、5b这样的编号对应主成功场景的第4步和第5步失败的情况。4a是系统验证借阅证无效5a是借阅数量超限5b是有超期未归还图书。这种编号法的好处是当需求变更时比如新增“借阅证被挂失”的判断你可以在主流程第4步后追加一个4b而不需要重新编号整个文档。如果你用工具管理用例建议从编号规则上就保持这种“主步骤号字母”的约定。写备选流时还要注意两点。第一备选流也要描述完整的交互回路包括系统显示什么、参与者做什么、然后流程如何结束。报告里每个备选流都写清了“系统显示…→管理员告知学生…→学生离开→管理员结束操作”这样就避免了“系统提示错误”这种半截描述。第二全局性的备选流用a和b表示比如系统管理员要求超控、系统任意时刻失败。这些分支不属于某一步而是覆盖整个用例的生命周期用带星号的编号和普通备选流区分开阅读时不会产生歧义。2.3 用StarUML绘制用例图的几个设置StarUML画用例图本身不复杂但要画得规范有四个细节值得注意。首先系统边界框要用矩形用例放在矩形内部参与者放在矩形外部。StarUML的Toolbox里有一个“System”组件拖出来后会自带一个带名称的矩形框别用普通矩形代替因为普通矩形没有语义。其次参与者和用例之间的关联线用Association不需要加箭头UML用例图的Association就是一根无向线表示参与者发起用例。很多初学者会在关联线上加箭头表示“调用”这不符合用例图的语义。第三扩展关系使用Extend类型的连线方向从扩展用例指向基础用例箭头指向被扩展的那个用例。实验里超控模式本质上是从借阅图书用例扩展出去的如果你单独画了一个“系统维护”用例那么应该用扩展线从系统维护指向借阅图书并标注extend。第四包含关系使用Include方向相反箭头从基础用例指向包含用例表示基础用例一定会执行被包含用例。图书管理系统的用例粒度较粗没有强制拆出公共步骤如果后续要加“校验借阅证有效性”这样的复用步骤就可以考虑用Include把它从多个用例里抽出来。StarUML默认画出的用例是椭圆形加名称如果你觉得字号太小可以在“Format”菜单里统一调整字体。另一个常见问题是用例图里的文字重叠我一般会先调整画布里对象的自动布局再手动拖拽关联线的拐点。导出图片时在Diagram上右键选择“Export as Image”分辨率默认只有96dpi用于文档打印最好把Scale调大比如填2倍否则文字会发虚。3. 领域模型与设计类图类、属性、关联怎么定3.1 从用例文本里“抠”出领域类实验二的核心任务是把用例文本中的名词和动词转换成领域类以及关联关系。报告从借阅用例中挑出了图书、账户、借阅证、学生、图书管理员、系统管理员这几个概念。这个挑选过程有两条经验规则一是名词不一定都是类只有那些具备独立状态和行为的业务概念才值得建模“学生姓名”不是类但“学生”是类因为学生有借阅记录和借阅证。二是动词往往提示关联比如“学生注册账号”说明学生和账户之间存在建立关系的关联“图书管理员验证账户”说明管理员和账户之间有验证关系。领域模型阶段的类通常只有属性和关联不写操作方法。报告里给出的图书属性是“书名、在馆信息”账户属性是“账号、密码、借书数目、借书时间、借书书名”。这里有一个建模上的小缺陷“借书书名”放在账户属性里会导致重复存储因为图书本身已有书名账户里应该只关联借阅记录。但在领域模型中这种冗余属性也被接受因为领域模型是为了理解业务概念而不是数据库设计。等到设计类图阶段就需要把这类重复信息消除改成通过关联访问。我在实际建模时会用下面的判据过滤候选类这个名词实例是否需要被单独识别和引用。如果只需要知道数量或名称就当作属性处理如果有多条记录且需要独立操作就升级为类。按这个标准“借书时间”更像借阅记录的属性而不是账户的属性所以更合理的做法是增加一个“借阅记录”类由账户持有。不过实验报告是学生作业能识别出核心实体已经达标。3.2 属性与关联的粒度控制领域类图的属性只写业务属性不写主键、外键、创建时间这类工程属性。报告里“借阅证”类给了姓名、系别、借阅证号这些是业务上有意义的字段。关联方面报告列出的是动词性短语“学生注册账号”“账号生成借阅证”“图书管理员验证账户”“系统管理员添加账户”等。画到类图上时这些短语应该转换成关联线上的角色名和多重性。报告里的关联没有标注多重性这是一个需要补强的点。按业务常识一个学生可以注册一个账户一个账户对应一张借阅证所以这两条关联的多重性都是1对1。一个账户可以同时借多本书所以账户和图书之间的“借阅”关联是1对多。如果手头有实验要求强制画多重性建议在关联线两端写明1和1..*这样类图的信息量会大很多。绘制领域类图时StarUML里的类图标默认分为上下两栏上栏写类名下栏写属性。如果只想显示属性不显示操作可以在类上右键选择“Format→Stereotype Display”或者直接删掉操作栏。关联线使用Association类型双击关联线可以添加角色名和多重性。角色名放在靠近目标类的一侧用来解释该类型在当前关联中扮演的角色比如学生注册账户账户侧的角色名可以是“注册账户”学生侧可以是“拥有者”。多重性写在角色名的对面更符合UML规范。3.3 设计类图补充操作给出代码骨架实验四已经属于设计阶段类需要增加操作。设计类图里的操作来自顺序图中的消息比如借阅图书用例中系统要能验证借阅证、记录借阅信息、更新账户状态。把这些职责分配给合适的类就能得到类似下面的Java代码骨架public class LibraryManagementSystem { private StudentRepository studentRepository; private BookRepository bookRepository; public boolean borrowBook(String studentId, String bookId) { Student student studentRepository.findById(studentId); if (student null || !student.hasValidLibraryCard()) { return false; } if (student.hasOverdueBooks()) { return false; } Book book bookRepository.findById(bookId); if (book null || !book.isAvailable()) { return false; } book.setAvailable(false); student.addBorrowingRecord(new BorrowRecord(bookId, LocalDate.now())); return true; } }这段代码对应主成功场景的第4步验证借阅证有效、第5步检测超借限额与超期、第8步记录借阅信息并更新账户。方法borrowBook本身是一个门面操作真正的验证逻辑分布在Student和Book类内部符合高内聚低耦合的原则。参数说明studentId是学生的唯一标识bookId是图书的唯一标识两者都来自用户输入返回boolean表示借阅是否成功失败的详细原因可以进一步通过异常或错误码区分。设计类图与领域类图的差异就在这里领域类图只表达“学生可以借阅图书”这种概念性关联设计类图则要明确Student类上有addBorrowingRecord方法、Book类上有setAvailable方法。如果后续要用Spring Boot实现Repository可以变成JpaRepository接口但类图的职责划分基本不变。画设计类图时StarUML需要在类的第三栏添加操作格式为borrowBook(studentId: String, bookId: String): boolean。访问修饰符表示public参数类型和返回类型要有这是设计类图和领域类图最直观的区别。建模阶段类的内容主要关系用途领域模型属性 关联概念性关联无操作与业务专家对齐词汇和概念设计类图属性 关联 操作 可见性依赖、实现、组合指导编码和测试4. 顺序图把用例里的消息变成生命线交互4.1 顺序图的时间轴与激活条顺序图是动态模型的核心实验三要求围绕用例画出借书和还书的交互。理解顺序图只需要抓住三个元素生命线、激活条、消息箭头。生命线是一条竖直虚线代表一个对象实例在交互过程中随时间的存在顶部画对象框里面写类名或实例名。激活条是生命线上的细长矩形表示该对象正在执行某个操作通常和调用栈对应。消息箭头从发送方指向接收方水平方向表示调用、返回或异步信号。画顺序图最忌讳的是把消息画成对象之间的数据流比如“书名”从学生流向管理员。顺序图表达的是行为传递消息应该是“输入借阅证号”“验证账户”这样的操作请求而不是数据本身。实验报告里的借书顺序图流程是学生把书交给管理员管理员向系统输入借阅证号系统验证后提示输入图书信息管理员输入图书信息系统记录借阅信息并更新账户。每一步都是一次消息交互。4.2 借书顺序图的拆解按照实验报告的主成功场景借书顺序图可以拆成下面这些消息我用表格列出来方便对照StarUML里的画法顺序编号发送方接收方消息内容说明1学生:图书管理员提交图书与借阅证物理动作建模时可省略或作为外部事件2:图书管理员:系统输入借阅证号(借阅证号)触发系统校验3:系统:系统验证借阅证有效性自调用消息表示内部处理4:系统:图书管理员显示学生信息返回结果使用返回消息5:图书管理员:系统输入图书信息(图书编号)第二笔核心输入6:系统:系统校验图书可借状态自调用7:系统:账户添加借阅记录(图书信息)跨对象调用8:系统:图书管理员显示借阅成功返回确认画图时注意两点。第一自调用消息在激活条上会画出一个稍短的激活条叠在原激活条上用于表示递归或内部方法调用。很多学生漏掉这条消息导致顺序图里系统验证过程变成一个空操作。第二返回消息使用虚线箭头通常可以省略但如果要强调返回值比如“返回学生信息”就必须画出来并标注返回值名称。顺序图的时间顺序是自上而下的。为了保持主成功场景清晰备选流不应并排堆在一起而是单独画一张图或者用交互片段表示。StarUML支持在顺序图里添加alt交互片段用来表达条件和分支。借书用例的4a借阅证有效、5a借阅超限、5b超期未还都可以用alt片段包裹但一个图里塞太多alt会变得难以阅读。我一般遵循“一张图只画一条主场景附带一个备选分支”的原则这也是实验报告阅卷时比较认可的粒度。4.3 从顺序图反推设计类图的操作顺序图画完之后设计类图的操作来源就很清楚了。顺序图中每个接收消息的对象都要在类图上有一个对应的操作。以借书顺序图为例系统收到“输入借阅证号”消息系统对象就需要一个validateLibraryCard(cardId: String): boolean操作系统收到“输入图书信息”消息系统对象需要checkBookAvailable(bookId: String): boolean系统给账户发送“添加借阅记录”账户类需要有addBorrowingRecord(record: BorrowRecord): void。这里有一个很容易犯的建模错误把顺序图中的消息全部堆到系统类上导致系统变成上帝类。正确的做法是让职责尽量分散到业务对象上。比如“验证借阅证有效”应该由借阅证对象自己判断而不是由系统类编写一大段if逻辑。所以在设计类图时我倾向于给借阅证类添加isValid(): boolean方法给账户类添加canBorrow(): boolean方法这样后续实现单元测试时每个类的行为都能独立验证。5. StarUML里容易被忽略的校验与导出技巧5.1 用模型校验检查关联端点StarUML除了画图还自带模型校验功能但很多学生不知道去哪找。菜单栏依次打开“Tools→Check Model”它会检查模型中存在的UML规范问题比如关联端点是否连接到类或组件、属性类型是否存在、操作返回值是否定义。图书管理系统实验里最常见的校验错误是关联线没有连接到类的边而是连接到空白的画布位置这种情况在视觉上几乎看不出来但模型校验会直接报错。如果你把类图导出成XMI文件交给其他工具导入模型规范性问题会导致导入失败。所以画完类图后第一件事就是跑一次模型校验。如果发现警告“Attribute type not specified”说明属性栏里的类型没填写StarUML允许属性只有名字没有类型这在领域模型阶段可接受但在设计类图阶段应该补上类型。可以用String、int、Date这类Java类型也可以自定义业务类型如BorrowRecord。另一个经常被忽略的设置是关联端点角色名和多重性的可见性。默认情况下StarUML的关联线不会自动显示角色名需要在右侧属性面板里给rolenames填值。填完之后关联线两端会显示名称比如“学生”端显示“owner”“账户”端显示“account”。多重性字段填1或*之后就会显示在线的端点旁边。我建议在设计类图阶段就把角色名和多重性全部标注完整这份实验报告里没有标注正好是你超越它的机会。5.2 导出图片与文档的常见问题把UML图放到实验报告里最直接的途径是导出PNG。StarUML的“Export as Image”支持PNG、JPG、SVG等格式但我建议优先导出SVG因为SVG是矢量格式插入Word或PDF时放大不会模糊。在导出设置中有一项“Zoom”或“Scale”默认值是100%。如果画布上的内容比较紧凑可以调成150%或200%这样导出的位图分辨率会更高直接插入报告时文字依然清晰。如果你有多张图需要一起导出比如用例图、领域类图、顺序图、设计类图可以使用“File→Export All Diagrams”批量导出它会把所有打开或保存的画布输出为文件。导出的文件名默认是图名称如果你在实验开始阶段没有给每张图命名导出后会出现一堆“Untitled”文件整理起来很麻烦。所以我习惯在画第一笔之前就把每个Diagram重命名用“01_use_case”“02_domain_class”这种带编号的前缀方便后期归档。关于把UML图复制到Word的另一个技巧先复制为位图再粘贴比直接嵌入StarUML对象更稳妥。因为实验报告可能交给不同版本Office的老师批阅嵌入对象经常出现“容器打开时未找到关联程序”的提示。位图虽然不能二次编辑但展示效果稳定配合前面提到的2倍缩放导出打印出来也不会模糊。5.3 对比PlantUML文本化建模的替代方案如果你嫌StarUML的鼠标拖拽效率低或者想把模型存进版本库里方便diff可以试试PlantUML。它是纯文本绘制模式下面是一段对应实验一用例图的PlantUML代码startuml left to right direction actor 学生 actor 图书管理员 actor 系统管理员 rectangle 图书管理系统 { usecase 借阅图书 as UC1 usecase 归还图书 as UC2 usecase 查询借阅信息 as UC3 usecase 系统维护 as UC4 } 学生 -- UC1 图书管理员 -- UC1 图书管理员 -- UC2 图书管理员 -- UC3 系统管理员 -- UC4 UC4 . UC1 : extend enduml这段代码生成的图与StarUML手工绘制的逻辑等价。说明一下actor定义参与者usecase定义用例--是关联线.是扩展实线加虚线箭头extend是扩展关系的构造型标注。用PlantUML的好处是所有模型内容都是文本出现异议时可以直接对比代码 diff评审时非常方便。PlantUML对顺序图的支持也同样直白借书流程可以翻译成类似下面的文本startuml actor 学生 participant 图书管理员 as Librarian participant 图书管理系统 as System 学生 - Librarian: 提交图书与借阅证 Librarian - System: 输入借阅证号(借阅证号) activate System System - System: 验证借阅证有效性 System -- Librarian: 显示学生信息 Librarian - System: 输入图书信息(图书编号) System - System: 校验图书可借状态 System - System: 记录借阅信息并更新账户 System -- Librarian: 显示借阅成功 deactivate System enduml注意自调用消息写入System - System而返回消息使用--虚线箭头。activate和deactivate用来控制激活条的长度如果没有这两个语句所有消息都在同一水平线上看不出时间开销和调用深度。这是PlantUML新手经常漏掉的部分。我在实际讲解UML建模时会让学生先用StarUML画图再用PlantUML重绘一遍。两套工具对照下来对UML符号的理解深度会比只用一个工具好得多。这份实验报告里的用例文本和顺序图描述已经足够当作PlantUML练习的输入素材你可以试着把归还图书流程也用文本描述出来然后和实验报告里的图对比看看消息序号和分支条件有没有缺失。本文还有配套的精品资源点击获取