简介这份南京邮电大学软件工程课程设计实验报告面向软件工程专业学生及需要完成面向对象分析与设计作业的开发者聚焦教务管理系统的需求分析与UML建模全过程。资源包内含1个docx文档压缩包约208KB以实验报告正文形式呈现便于直接参考与整理。报告完整覆盖RationalRose环境使用、需求分析说明书编写以及用例图、活动图、类图、序列图、协作图、状态图等UML图表的绘制思路并给出管理员、教师、学生三类参与者在账号、课程、班级、选课与成绩管理中的具体建模实例。读者可借此掌握从需求梳理到模型落地的完整流程理解User基类与Administrator、Teacher、Student等子类的继承关系以及Course、Grade、Class等管理类的职责划分同时对照结构化方法体会面向对象设计的差异。目前已有3103人学习下载适合作为课程设计、实验报告撰写与UML建模练习的参考范本。1. 从一份 DOCX 实验报告说起教务管理系统的 UML 建模到底交付了什么如果你正在搜「软件工程课程设计 教务管理系统 UML」大概率是两种情况要么课设选题撞上了教务系统要么导师要求用 RationalRose 把用例图、类图、顺序图全画一遍而你手里只有一份不知道能不能用的 DOCX 报告。我拿到这份南邮的《软件工程课程设计实验报告-教务管理系统》时第一反应也是先翻目录——它到底是一份纯文档还是能照着复现的建模作业。结论是它是一份完整的实验报告文档核心价值不在代码而在「需求分析说明书 UML 全套图 面向对象与结构化方法对比」这条完整链路。报告里明确写了实验目的掌握需求分析方法、掌握 UML 设计方法、实验环境RationalRose 的浏览器/文档工具/工具栏/框图窗口/日志五大部分、以及从用例图到状态图的建模步骤。换句话说它解决的是「课设不知道怎么下手、UML 图不知道画几张、需求文档不知道写什么」的问题适合软件工程课程的本科生、需要交面向对象设计作业的从业者以及想复习 UML 建模流程的人。下面我按「这份资源是什么 → 怎么照着做 → 坑在哪」的顺序拆开讲。2. 需求分析说明书怎么落地从参与者到六大功能模块的拆解2.1 先定参与者再切功能边界报告里最值得抄的不是图是它的需求拆解逻辑。教务管理系统的参与者只有三类管理员、教师、学生。这三类人对应六大用例登录管理、账号管理、班级管理、课程管理、选课管理、成绩管理。这个划分不是拍脑袋来的它遵循了一个原则——每个参与者至少主导一个用例且用例之间不重叠。具体对应关系是这样的参与者主导用例参与用例管理员账号管理、课程管理、班级管理登录管理教师成绩管理、选课管理登录管理学生选课管理、成绩管理登录管理这张表看着简单但它是后面所有 UML 图的根。用例图画错了类图里的方法就会多出莫名其妙的接口。我见过太多课设翻车就是因为一开始把「查看成绩」和「录入成绩」塞进同一个用例结果类图里 Student 和 Teacher 都挂了 GradeManager逻辑直接乱掉。2.2 需求规格说明书的四段式结构报告附录里的需求说明书分了四块引言、任务概述、需求规定、运行环境规定。这个结构可以直接套用到任何课设文档里。我把它拆成可执行的写作步骤第一步写引言。交代编写目的、背景范围、术语定义、参考文献。报告里写的是「为全校教务管理提供方便平台」你换成自己的选题就行但「编写目的」必须点明文档给谁看、起什么指导作用。第二步写任务概述。包括目标、用户简介、组织结构和职责。目标要写成可验证的条目比如「操作响应时间控制在 1~2 秒内」「支持 2000 人同时访问」别写「提高效率」这种没法验收的话。第三步写需求规定。这是重头戏分功能需求、性能需求、数据管理。功能需求按模块写每个模块列出增删改查四类操作。性能需求写数据精确度、时间特性、适应性、保密性。报告里提到的「直接查询和模糊查询两种方式」就是数据精确度的具体落地。第四步写运行环境。客户端最低配置、服务器要求、操作系统版本、数据库选型。报告里写的是 Access 做数据库、Windows 系列系统你按自己实际环境改。提示需求说明书不是写完就锁死的。后面画用例图时如果发现某个功能找不到归属回头改需求文档比硬塞进图里更省事。2.3 功能需求点列表的写法报告里有一节叫「功能需求点列表」虽然正文没展开但这是课设评分的关键。我的做法是给每个模块建一张表列四列功能编号、功能名称、输入、输出。比如登录管理模块编号功能名称输入输出F-01用户登录账号、密码登录成功/失败提示F-02修改密码旧密码、新密码更新结果F-03退出登录无清除会话这张表后面直接喂给用例图一个功能点对应一个用例不会漏也不会重。很多人画用例图时凭感觉加用例最后跟需求文档对不上答辩时被问「这个用例在需求里哪一条」就卡住了。3. RationalRose 画 UML 图用例图、活动图、类图、顺序图的实操顺序3.1 环境准备与四个视图的分工RationalRose 的界面分五块浏览器、文档工具、工具栏、框图窗口、日志。新手最容易懵的是浏览器里的四个视图——UseCase 视图、Logical 视图、Component 视图、Deployment 视图。它们不是随便分的每个视图管一类模型元素UseCase 视图放参与者、用例、用例图。需求分析阶段的主战场。Logical 视图放类、类图、顺序图、协作图、状态图。设计阶段的核心。Component 视图放组件、包。如果课设要求画组件图在这里建。Deployment 视图放节点、部署图。一般课设选做。操作路径是右键视图 → New → 选对应的模型元素。比如建用例图就在 UseCase 视图右键 New → Use Case Diagram然后从工具栏拖 Actor 和 Use Case 进去。注意Rose 里改框图元素浏览器会自动更新改浏览器框图也会同步。这个一致性机制是 Rose 的卖点但也意味着你删一个类的时候所有引用它的图都会跟着变删之前想清楚。3.2 用例图从主用例图到子用例图的拆分报告里画了七张用例图一张主图六张子图班级管理、成绩管理、登录管理、课程管理、选课管理、账号管理。这个拆法值得学——主图只放参与者和顶层用例子图展开每个用例的内部关系。主用例图的画法三个 Actor管理员、教师、学生放在左侧和右侧六个 Use Case 放中间连线表示参与关系。登录管理连三个 Actor账号管理只连管理员成绩管理连教师和学生。子用例图的关键是include 和 extend 的区分。报告里成绩管理的「查看成绩」泛化为「按学期查询」和「按学年查询」这是典型的泛化关系用空心三角箭头指向父用例。而「录入成绩」之前必须先「登录」这是 include 关系用虚线箭头加include。我一般会跟学生说先画主图定边界再画子图抠细节最后回头检查每个用例是否至少有一个 Actor 关联。孤立用例是课设最常见的扣分点。3.3 活动图用泳道区分责任人活动图在报告里出现了四次管理员添加课程、管理员修改课程、学生选择课程、学生退选课程。活动图的核心是活动流的方向和泳道。以「学生选择课程」为例步骤是登录 → 查询课程 → 选择课程 → 判断是否已选 → 是则提示重复否则加入选课列表 → 更新课程表。用泳道的话学生放一条泳道系统放一条泳道动作归属一目了然。Rose 里画活动图在 Logical 视图右键 New → Activity Diagram。起始状态用实心圆结束状态用牛眼图标活动用圆角矩形判断用菱形分叉汇合用粗黑线。提示活动图不要画成流程图。区别在于活动图可以加泳道、可以处理并发分叉汇合而流程图只是单向步骤。课设里如果只画了单向步骤导师可能会问「并发选课怎么处理」。3.4 类图User 基类与继承体系的设计类图是整份报告里信息密度最高的部分。报告里定义了 10 个类User、Administrator、Student、Teacher、Course、Elect选课、Account账号、Class、Grade、DataCase。继承关系是 Administrator、Student、Teacher 继承自 User。User 类的属性是 UserID、UserPassword方法是 getID()、modifyPassword()、getPassword()、User()。这个设计有个小问题——UserID 和 ID 属性在子类里重复出现了。Administrator 有 IDTeacher 有 IDStudent 有 stuID。严格来说如果 User 已经有 UserID子类不该再定义 ID。但课设层面这样写也能过只是答辩时可能被追问「为什么子类重复定义父类属性」。类之间的关系除了继承还有关联和依赖。Student 和 Course 是多对多关联通过 Elect 类拆解。Teacher 和 Course 是一对多关联。Grade 类依赖 Student 和 Course。画类图的顺序先画 User 基类 → 画三个子类并连继承箭头 → 画 Course、Class 等实体类 → 画 Elect、Grade 等关系类 → 补方法和属性 → 检查多重性标注。3.5 顺序图与协作图的互转报告里提到一个关键操作在序列图中按 F5 创建协作图在协作图中按 F5 创建序列图两者同构转换无信息损失。这是 Rose 的实用功能也是课设里容易拿分的小技巧。顺序图的画法顶部放 Actor 和对象垂直虚线是生命线水平箭头是消息消息按时间顺序从上到下排列。报告里的「教师录入成绩顺序图」就是教师发消息给成绩管理界面界面再调用 Grade 类的方法。协作图也叫通信图强调对象之间的链接关系消息用带序号的箭头表示。两者表达的是同一件事只是侧重点不同。课设如果要求两种都交画完顺序图直接 F5 转就行不用重画。4. 避坑与排查课设里最容易翻车的五个地方4.1 用例图里出现「系统」作为参与者现象画用例图时把「数据库」或「教务系统」也画成 Actor跟管理员、教师并列。原因没分清参与者和系统的边界。参与者是系统外部与系统交互的角色数据库是系统内部组件不该出现在用例图里。解决删掉系统类 Actor把数据库操作归到 DataCase 类的方法里在类图或顺序图中体现。4.2 类图属性与方法命名混乱现象有的类属性用中文有的用英文方法有的带括号有的不带getID() 和 getID 混用。原因画图时没统一命名规范想到哪写到哪。解决定一套规则——类名首字母大写属性小写驼峰方法动词开头加括号。画之前先在文档里列一张命名表画的时候照着填。4.3 顺序图消息顺序与活动图对不上现象活动图里学生先选课再判断是否重复顺序图里却先判断再选课。原因两张图分开画没有交叉检查。解决画完活动图后把每个活动节点映射成顺序图里的一条消息顺序必须一致。Rose 里可以用浏览器的模型一致性检查功能但最靠谱的还是人工对一遍。4.4 Rose 文件保存后打不开或图丢失现象保存 .mdl 文件后重新打开发现某些图不见了或者提示模型损坏。原因Rose 对文件路径和版本敏感跨版本打开或路径含中文可能出问题。解决保存时用英文路径文件名不带空格每次画完一个图就 CtrlS交作业前导出成图片或 PDF 备份。我一般会让学生把 .mdl 和导出的图片放同一个文件夹双保险。4.5 需求文档与 UML 图脱节现象需求说明书里写了「支持模糊查询」但用例图和类图里找不到对应功能。原因先写文档后画图画图时忘了回头补文档或者文档写得太虚没法映射。解决每画完一张图拿需求功能点列表对一遍确保每个功能点至少在一张图里出现。对不上的要么补图要么改文档。5. 从实验报告到可复现的建模流程我的检查清单与一个提速技巧这份报告最有价值的地方是它把「结构化方法 vs 面向对象方法」的对比写进了实验总结。报告里的结论是结构化方法自顶向下、逐步求精、强调功能抽象面向对象方法把问题分解成对象稳定性好、可重用、局部修改不影响整体。这个对比不是空话它直接决定了你画图的顺序——面向对象是先找对象类再定行为方法最后串流程顺序图结构化是先定功能再拆模块最后画流程图。我按这份报告复现过一遍完整流程总结出一个检查清单每次交课设前走一遍检查项通过标准参与者是否完整每个 Actor 至少关联一个用例用例是否覆盖需求需求功能点列表逐条能在用例图找到类图继承是否合理子类不重复定义父类已有属性顺序图与活动图是否一致消息顺序与活动流方向一致图与文档是否对应每张图能指向需求说明书的具体章节文件是否可恢复.mdl 和导出图片同时存在最后分享一个提速技巧先画类图再倒推用例图和顺序图。听起来反直觉但实操很顺——类图定好了每个类的方法就是用例的候选每个方法的调用链就是顺序图的消息流。报告里是从用例图开始画的那是教学顺序如果你时间紧从类图切入能省掉大量返工。从那以后我每次带课设都强制让学生先交一版类图草稿确认继承和关联没问题了再展开其他图。这样至少能避开「画了七张图最后发现类关系错了要全改」的血泪经验。希望帮到你。本文还有配套的精品资源点击获取
