尧图网页设计 
简介UML学生宿舍管理系统实验报告文档面向软件工程、面向对象分析设计课程的学习者及需要完成课程设计的在校生。文档以学生宿舍管理系统为实践案例系统阐述如何利用UML统一建模语言开展需求分析与系统设计内容涵盖宿舍楼管理员、宿舍楼学生、系统管理员和其他用户四类角色的需求分析、用例模型及静态模型设计并配有参与者识别、用例图相关说明层次清晰、结构完整适合作为实验报告模板或期末综合作业参考。资源包内仅有1个doc文档整体压缩包452KB轻量易用便于直接阅读和编辑改写。目前已有228人学习/下载对正在撰写UML建模作业的学生具有较高参考价值。通过这份报告可获得一套完整的UML建模思路与文档组织方法从需求分析入手逐步过渡到用例建模和类图等静态模型搭建覆盖宿舍入住退宿、信息查询、系统配置与日志管理等典型业务场景能够帮助理解系统角色划分与功能边界的表达方式有效提升UML实践与文档写作能力。1. 学生宿舍管理系统 UML 文档真正值钱的是用例描述看到“UML-学生宿舍管理系统.doc”这类文件名多数人第一反应是又一个课程设计模板下载下来就完事。但把这份实验报告从头到尾拆开看它其实是一套完整的 UML 全流程案例从需求分析开始依次给出用例模型、类图、时序图、协作图、活动图、构件图和部署图每一步都有产物。真正值得反复读的不是图面效果而是每个用例都写了前置条件、后置条件、基本路径和扩展路径后面所有模型几乎都能从这些文字里推出来。适合正在写软件工程实验报告、做毕业设计前期建模或者想搞明白“用例图之后到底该画什么”的人对照着看。2. 从需求到用例模型先把四类参与者和用例边界定死2.1 四类参与者怎么识别需求分析里第一件事不是画用例图而是识别参与者。这份文档把系统拆成宿舍楼管理员子系统、宿舍楼学生子系统、系统管理员子系统、其他用户子系统对应四个参与者宿舍楼管理员、住宿学生、系统管理员、其他用户。判断依据不是“谁能打开系统”而是“谁在系统外部通过与系统交互达成目标”。因此学校/学院不是参与者公告只是由管理员录入的数据其他用户虽然是只读角色但会查看宿舍整体情况、生成报表所以也是参与者。参与者来源角色对应子系统核心诉求宿舍楼管理员负责某一栋楼的管理员宿舍楼管理员子系统查询/修改/删除学生信息、查看报修与夜归、登记维修解决时间、发布公告住宿学生住在宿舍的学生宿舍楼学生子系统查询宿舍、夜归、离返校记录插入报修信息填写离校、返校时间系统管理员平台维护人员系统管理员子系统注册和删除各类用户、设置用户权限其他用户领导或访客其他用户子系统查看各宿舍整体情况、生成报表参与者识别错了后面全错。比如把宿舍楼管理员和系统管理员合并成一个“管理员”修改学生信息和用户注册就会被混到一个用例集里后续类图和部署图的关系也会跟着乱。我一般先写一张参与者清单再开始画用例图尽量不在画图过程中临时加角色。2.2 用例描述表怎么写才不空这份文档里最容易被忽略但最有价值的是用例描述。每个用例都有六个要素用例名称、参与者、前置条件、后置条件、基本路径、扩展路径。很多网上下载的模板只画几个椭圆不写描述结果评审时一问“异常分支怎么处理”就答不上来。这里的“修改学生信息”用例就是一个标准样板前置条件是管理员已登录且学生已转专业或调宿后置条件是修改成功则数据库更新、失败则系统状态不变基本路径从请求修改到提交保存逐步编号扩展路径单独处理学号不存在的情况。字段本用例写法常见错误用例名称修改学生信息写成“学生管理”粒度过大参与者宿舍楼管理员把学生也写成参与者前置条件管理员已登录且学生已转专业或调宿不写或写成“无”后置条件成功时更新数据库失败时系统状态不变只写成功路径基本路径1 请求修改2 输入学号3 显示学生信息4 修改并提交5 系统保存没有步骤编号扩展路径A1 学号不存在提示重新输入或取消完全省略异常分支扩展路径是整套建模里最容易翻车的地方。以“查看住宿信息”为例基本路径只有三步输入学号、系统查询、显示住宿信息扩展路径则处理“系统没有该学号”的情况并给出“重新输入或取消”两个出口。把这些分支收集起来可以直接变成后续测试用例的异常场景来源。所以我通常建议先写用例描述再画用例图顺序不要反过来。2.3 用 PlantUML 快速生成用例图手工画用例图会在布局上浪费不少时间我更习惯用文本生成。PlantUML 语法很简短适合先把用例边界定下来。startuml 参与者放在系统边界外用例放在矩形内 left to right direction actor 宿舍楼管理员 as admin actor 住宿学生 as student actor 系统管理员 as sysadmin rectangle 宿舍楼管理员子系统 { usecase 登录系统 as UC_LOGIN usecase 查看住宿信息 as UC_VIEW_RES usecase 修改学生信息 as UC_MOD_STU usecase 删除学生信息 as UC_DEL_STU usecase 登记报修解决时间 as UC_FIX_TIME } admin -- UC_LOGIN admin -- UC_VIEW_RES admin -- UC_MOD_STU admin -- UC_DEL_STU admin -- UC_FIX_TIME rectangle 宿舍楼学生子系统 { usecase 插入返校时间 as UC_BACK_TIME usecase 插入报修信息 as UC_REPAIR } student -- UC_BACK_TIME student -- UC_REPAIR sysadmin -- UC_LOGIN enduml这段代码里actor定义参与者rectangle代表子系统边界内部放usecase。参与者与用例之间用--连接箭头方向表示谁发起操作。编译生成 PNG 或 SVG 的命令很简单java -jar plantuml.jar usecase.puml如果本机没有 Java 环境也可以按同样的结构在 draw.io 或 Visio 里重画。关键点是参与者一定在矩形外部用例一定在矩形内部否则系统边界就不成立。3. 静态模型类图、包图和 Visio 里的关系判定3.1 从用例描述中提取候选类类图不是凭空造出来的而是从用例描述里出现的名词和动词里挑出来的。以“登记报修解决时间”为例描述里有“报修信息”“报修单”“解决时间”于是RepairOrder类和resolveTime属性就有了出处在“修改学生信息”里出现学号、姓名、专业对应Student类。先有文字再有类这样建模才不容易漏。候选类核心属性来源用例StudentstudentId, name, major修改/删除学生信息DormitorybuildingNo, roomNo, capacity查看住宿信息RepairOrderorderId, content, reportTime, resolveTime登记报修解决时间ReturnRecordleaveTime, returnTime插入离校/返校时间Noticetitle, content, publishTime通知上级发布的公告类还可以按职责分组参与者类、实体类、控制类。比如Student、DormitoryAdmin属于参与者类RepairOrder、ReturnRecord是实体类LoginService、StudentInfoService是控制类。我不建议把所有类画在一张巨型类图里按子系统拆成包图会更容易评审。包图和类图是同一套模型的不同视图包关系可以理解为“这个包里的类依赖另一个包里的类”。3.2 类之间的关系组合、聚合还是关联UML 类图最容易画错的是关系类型。我的判断顺序是先看两个类是否存在生命期绑定。比如“宿舍”和“床位”床位的生命周期依附于宿舍用组合关系实心菱形“宿舍楼”和“宿舍”是整体与部分但宿舍楼拆除后宿舍这个概念仍然可以独立存在用聚合关系空心菱形“学生”和“报修单”只是使用关系报修单不因为学生删除而必须删除用普通关联。依赖关系一般保留给“类的方法参数里出现另一个类”的情况比如服务层依赖数据访问层。多重性也别写反。一个宿舍可以住 0..* 个学生那么宿舍那一端写 1学生那一端写 0..一个学生可以提交 0..条报修那么报修单那一端写 0..*。评审时先看多重性再看关系符号比看类名更有用。3.3 用 Visio 画 UML 类图的具体操作用 Visio 画 UML 类图有两条路新建时选“软件和数据库”分类下的“UML 模型图”或者直接找“UML 类图”模板。要点是不要只拖“类”形状然后手动打字要双击形状打开“UML 类属性”对话框在属性、操作里维护信息这样模型资源管理器里的数据才完整。操作步骤如下新建 UML 类图打开“模型资源管理器”从“UML 静态结构”模具中拖入“类”形状双击类形状在“UML 类属性”中添加属性与操作可见性用 表示 public- 表示 private使用“关联”连接线连接两个类双击连接线设置起止多重性。Visio 里常见问题是连接线拖出来了但看不到聚合或组合符号。原因多半是连接线类型仍是“关联”需要在“UML 关联属性”中把关系改成“聚合”或“组合”或者直接删除重拖对应的连接线。如果只是用文本块拼成的假类图后续想导出成代码骨架或反向工程会发现信息全部丢失。下面用 PlantUML 重画一份简化的类图便于对照关系符号。startuml class Student { - studentId : String - name : String - major : String getInfo() : String updateInfo() : void } class Dormitory { - buildingNo : String - roomNo : String - capacity : int } class RepairOrder { - orderId : String - content : String - reportTime : Date - resolveTime : Date setResolveTime() : void } Dormitory 1 -- 0..* Student : 入住 Student 1 -- 0..* RepairOrder : 提交 enduml逻辑上Dormitory和Student之间是关联关系1到0..*表示一个宿舍可以关联多个学生Student和RepairOrder之间也是关联表示一个学生可以提交多条报修记录。类图里的方法getInfo()、updateInfo()、setResolveTime()分别对应用例描述中的查询、修改、登记操作。提示PlantUML 中--是关联o--是聚合*--是组合多重性写在双引号里放在靠近目标类的一端。4. 动态模型时序图、协作图、活动图的建模顺序4.1 三种动态图的分工用例模型回答“有哪些功能”类图回答“有哪些对象”动态模型回答“对象之间怎么协作”。时序图强调消息在时间线上的先后顺序协作图强调对象之间的连接结构消息带编号活动图站在流程视角表现分支、循环和并行。文档里把“修改学生信息”同时画成时序图和协作图说明两者可以互相转换只是侧重点不同。图类型关注什么核心要素使用场景时序图消息先后顺序生命线、激活条、消息表现单个用例的交互细节协作图对象间连接结构对象、链、带编号消息强调对象拓扑关系时使用活动图业务流程分支初始节点、活动、决策、合并、分叉、汇合跨角色业务流程如报修处理如果某个用例对应的时序图消息超过二十条说明用例粒度过粗需要拆分。这也是评审时判断建模水平的一个快速标准。4.2 从用例基本路径画时序图以“登记报修解决时间”为例这条用例的基本路径是管理员选择报修单输入解决时间系统保存。时序图里至少要有管理员、报修管理界面、RepairOrder实体和数据库四个参与对象。startuml actor 宿舍楼管理员 as admin participant 报修管理界面 as ui participant RepairOrder as order participant 数据库 as db admin - ui: 打开报修列表 ui - db: 查询未解决报修() db -- ui: 返回报修记录 admin - ui: 选择报修单(orderId) admin - ui: 输入解决时间(time) ui - order: setResolveTime(time) order - db: update resolve_time db -- order: 更新成功 order -- ui: 保存成功 ui -- admin: 显示登记结果 endumlactor表示外部参与者participant表示系统内部对象或模块。实线箭头-表示同步消息调用虚线箭头--表示返回结果。这里每个消息都能对应用例基本路径中的一个步骤查询报修、选择报修单、设置时间、保存。如果漏掉返回消息时序图会失去完整性评审时一眼就能看出流程没有结果。用例描述里的扩展路径也要映射到时序图上。比如报修单不存在可以用alt片段包一段异常分支提示“无此报修单”。很多模板只画主流程不画异常分支这是动态模型和用例描述不一致的典型表现。4.3 活动图要素初始节点、决策和泳道活动图是动态模型中最容易画“飘”的图。要素包括初始节点、活动节点、决策节点、合并节点以及并行用的分叉和汇合。以住宿学生提交报修流程为例startuml start :登录系统; :获取学生住宿信息; if (是否有未处理报修?) then (是) :查看维修进度; else (否) :创建报修单; :填写故障描述; :提交报修申请; endif :等待维修结果; stop endumlstart和stop是流程起点和终点if/else生成决策节点endif把两个分支合并回同一条流程线。这里最容易犯的错是把互斥分支画成了并行分叉。互斥用菱形并行才用粗横线。文档里的宿舍楼管理员活动图、住宿学生活动图、系统管理员活动图都可以用同一套规则重画。如果活动图里有两个角色协作比如管理员处理报修、学生查看结果就加泳道。Visio 的“UML 活动图”模板里有“泳道”形状把活动分别拖进对应角色区域即可。5. 构件图与部署图之外交付前的一致性检查技巧5.1 从部署图判断系统边界这份文档的构件图和部署图看起来简单但能说明系统物理边界。构件图把系统拆成宿舍管理员操作构件、住宿学生构件、系统管理员构件表示三个子系统可以独立开发和部署部署图画出客户端、服务器和数据库之间的连接。课程设计阶段不需要画到源码文件级别画到“可以分模块部署”的程度就够。判断标准是别人拿到部署图能知道系统跑在哪些节点上客户端通过什么协议访问服务端数据存在哪里。5.2 答辩前十五分钟的核对方法面对这类模型文档我一般用三层核对来检查完整性。先把用例模型当索引第一每个用例是否至少对应一张时序图或活动图第二用例里的业务操作是否能在类图中找到对应方法比如“删除学生信息”对应Student.deleteInfo()第三活动图里的每个分支是否能回溯到用例描述中的扩展路径。三层核对都通过模型基本不会打架。检查项常见问题修正方式用例到动态图有用例但没有时序图按基本路径补画时序图用例到类图用例出现“登记报修”类图没有 RepairOrder补充类并关联 Student动态图到用例扩展时序图只画主流程异常分支缺失增加 alt/else 片段如果你拿到一份现成的宿舍管理系统 UML 文档准备改成自己的题目我建议不要先动图先把用例描述表里的参与者、前置条件和基本路径替换成自己的业务术语再回头改用例图。因为用例描述是所有模型共同的唯一数据源。可以试着做一个最小改动在“查看住宿信息”用例里加一条“扩展路径学号不存在时提示重新输入”然后在对应时序图上补一个alt片段。只做这一步整套 UML 模型的完整度就会明显改观。本文还有配套的精品资源点击获取 学生宿舍管理系统UML建模：用例描述驱动的完整实践
简介UML学生宿舍管理系统实验报告文档面向软件工程、面向对象分析设计课程的学习者及需要完成课程设计的在校生。文档以学生宿舍管理系统为实践案例系统阐述如何利用UML统一建模语言开展需求分析与系统设计内容涵盖宿舍楼管理员、宿舍楼学生、系统管理员和其他用户四类角色的需求分析、用例模型及静态模型设计并配有参与者识别、用例图相关说明层次清晰、结构完整适合作为实验报告模板或期末综合作业参考。资源包内仅有1个doc文档整体压缩包452KB轻量易用便于直接阅读和编辑改写。目前已有228人学习/下载对正在撰写UML建模作业的学生具有较高参考价值。通过这份报告可获得一套完整的UML建模思路与文档组织方法从需求分析入手逐步过渡到用例建模和类图等静态模型搭建覆盖宿舍入住退宿、信息查询、系统配置与日志管理等典型业务场景能够帮助理解系统角色划分与功能边界的表达方式有效提升UML实践与文档写作能力。1. 学生宿舍管理系统 UML 文档真正值钱的是用例描述看到“UML-学生宿舍管理系统.doc”这类文件名多数人第一反应是又一个课程设计模板下载下来就完事。但把这份实验报告从头到尾拆开看它其实是一套完整的 UML 全流程案例从需求分析开始依次给出用例模型、类图、时序图、协作图、活动图、构件图和部署图每一步都有产物。真正值得反复读的不是图面效果而是每个用例都写了前置条件、后置条件、基本路径和扩展路径后面所有模型几乎都能从这些文字里推出来。适合正在写软件工程实验报告、做毕业设计前期建模或者想搞明白“用例图之后到底该画什么”的人对照着看。2. 从需求到用例模型先把四类参与者和用例边界定死2.1 四类参与者怎么识别需求分析里第一件事不是画用例图而是识别参与者。这份文档把系统拆成宿舍楼管理员子系统、宿舍楼学生子系统、系统管理员子系统、其他用户子系统对应四个参与者宿舍楼管理员、住宿学生、系统管理员、其他用户。判断依据不是“谁能打开系统”而是“谁在系统外部通过与系统交互达成目标”。因此学校/学院不是参与者公告只是由管理员录入的数据其他用户虽然是只读角色但会查看宿舍整体情况、生成报表所以也是参与者。参与者来源角色对应子系统核心诉求宿舍楼管理员负责某一栋楼的管理员宿舍楼管理员子系统查询/修改/删除学生信息、查看报修与夜归、登记维修解决时间、发布公告住宿学生住在宿舍的学生宿舍楼学生子系统查询宿舍、夜归、离返校记录插入报修信息填写离校、返校时间系统管理员平台维护人员系统管理员子系统注册和删除各类用户、设置用户权限其他用户领导或访客其他用户子系统查看各宿舍整体情况、生成报表参与者识别错了后面全错。比如把宿舍楼管理员和系统管理员合并成一个“管理员”修改学生信息和用户注册就会被混到一个用例集里后续类图和部署图的关系也会跟着乱。我一般先写一张参与者清单再开始画用例图尽量不在画图过程中临时加角色。2.2 用例描述表怎么写才不空这份文档里最容易被忽略但最有价值的是用例描述。每个用例都有六个要素用例名称、参与者、前置条件、后置条件、基本路径、扩展路径。很多网上下载的模板只画几个椭圆不写描述结果评审时一问“异常分支怎么处理”就答不上来。这里的“修改学生信息”用例就是一个标准样板前置条件是管理员已登录且学生已转专业或调宿后置条件是修改成功则数据库更新、失败则系统状态不变基本路径从请求修改到提交保存逐步编号扩展路径单独处理学号不存在的情况。字段本用例写法常见错误用例名称修改学生信息写成“学生管理”粒度过大参与者宿舍楼管理员把学生也写成参与者前置条件管理员已登录且学生已转专业或调宿不写或写成“无”后置条件成功时更新数据库失败时系统状态不变只写成功路径基本路径1 请求修改2 输入学号3 显示学生信息4 修改并提交5 系统保存没有步骤编号扩展路径A1 学号不存在提示重新输入或取消完全省略异常分支扩展路径是整套建模里最容易翻车的地方。以“查看住宿信息”为例基本路径只有三步输入学号、系统查询、显示住宿信息扩展路径则处理“系统没有该学号”的情况并给出“重新输入或取消”两个出口。把这些分支收集起来可以直接变成后续测试用例的异常场景来源。所以我通常建议先写用例描述再画用例图顺序不要反过来。2.3 用 PlantUML 快速生成用例图手工画用例图会在布局上浪费不少时间我更习惯用文本生成。PlantUML 语法很简短适合先把用例边界定下来。startuml 参与者放在系统边界外用例放在矩形内 left to right direction actor 宿舍楼管理员 as admin actor 住宿学生 as student actor 系统管理员 as sysadmin rectangle 宿舍楼管理员子系统 { usecase 登录系统 as UC_LOGIN usecase 查看住宿信息 as UC_VIEW_RES usecase 修改学生信息 as UC_MOD_STU usecase 删除学生信息 as UC_DEL_STU usecase 登记报修解决时间 as UC_FIX_TIME } admin -- UC_LOGIN admin -- UC_VIEW_RES admin -- UC_MOD_STU admin -- UC_DEL_STU admin -- UC_FIX_TIME rectangle 宿舍楼学生子系统 { usecase 插入返校时间 as UC_BACK_TIME usecase 插入报修信息 as UC_REPAIR } student -- UC_BACK_TIME student -- UC_REPAIR sysadmin -- UC_LOGIN enduml这段代码里actor定义参与者rectangle代表子系统边界内部放usecase。参与者与用例之间用--连接箭头方向表示谁发起操作。编译生成 PNG 或 SVG 的命令很简单java -jar plantuml.jar usecase.puml如果本机没有 Java 环境也可以按同样的结构在 draw.io 或 Visio 里重画。关键点是参与者一定在矩形外部用例一定在矩形内部否则系统边界就不成立。3. 静态模型类图、包图和 Visio 里的关系判定3.1 从用例描述中提取候选类类图不是凭空造出来的而是从用例描述里出现的名词和动词里挑出来的。以“登记报修解决时间”为例描述里有“报修信息”“报修单”“解决时间”于是RepairOrder类和resolveTime属性就有了出处在“修改学生信息”里出现学号、姓名、专业对应Student类。先有文字再有类这样建模才不容易漏。候选类核心属性来源用例StudentstudentId, name, major修改/删除学生信息DormitorybuildingNo, roomNo, capacity查看住宿信息RepairOrderorderId, content, reportTime, resolveTime登记报修解决时间ReturnRecordleaveTime, returnTime插入离校/返校时间Noticetitle, content, publishTime通知上级发布的公告类还可以按职责分组参与者类、实体类、控制类。比如Student、DormitoryAdmin属于参与者类RepairOrder、ReturnRecord是实体类LoginService、StudentInfoService是控制类。我不建议把所有类画在一张巨型类图里按子系统拆成包图会更容易评审。包图和类图是同一套模型的不同视图包关系可以理解为“这个包里的类依赖另一个包里的类”。3.2 类之间的关系组合、聚合还是关联UML 类图最容易画错的是关系类型。我的判断顺序是先看两个类是否存在生命期绑定。比如“宿舍”和“床位”床位的生命周期依附于宿舍用组合关系实心菱形“宿舍楼”和“宿舍”是整体与部分但宿舍楼拆除后宿舍这个概念仍然可以独立存在用聚合关系空心菱形“学生”和“报修单”只是使用关系报修单不因为学生删除而必须删除用普通关联。依赖关系一般保留给“类的方法参数里出现另一个类”的情况比如服务层依赖数据访问层。多重性也别写反。一个宿舍可以住 0..* 个学生那么宿舍那一端写 1学生那一端写 0..一个学生可以提交 0..条报修那么报修单那一端写 0..*。评审时先看多重性再看关系符号比看类名更有用。3.3 用 Visio 画 UML 类图的具体操作用 Visio 画 UML 类图有两条路新建时选“软件和数据库”分类下的“UML 模型图”或者直接找“UML 类图”模板。要点是不要只拖“类”形状然后手动打字要双击形状打开“UML 类属性”对话框在属性、操作里维护信息这样模型资源管理器里的数据才完整。操作步骤如下新建 UML 类图打开“模型资源管理器”从“UML 静态结构”模具中拖入“类”形状双击类形状在“UML 类属性”中添加属性与操作可见性用 表示 public- 表示 private使用“关联”连接线连接两个类双击连接线设置起止多重性。Visio 里常见问题是连接线拖出来了但看不到聚合或组合符号。原因多半是连接线类型仍是“关联”需要在“UML 关联属性”中把关系改成“聚合”或“组合”或者直接删除重拖对应的连接线。如果只是用文本块拼成的假类图后续想导出成代码骨架或反向工程会发现信息全部丢失。下面用 PlantUML 重画一份简化的类图便于对照关系符号。startuml class Student { - studentId : String - name : String - major : String getInfo() : String updateInfo() : void } class Dormitory { - buildingNo : String - roomNo : String - capacity : int } class RepairOrder { - orderId : String - content : String - reportTime : Date - resolveTime : Date setResolveTime() : void } Dormitory 1 -- 0..* Student : 入住 Student 1 -- 0..* RepairOrder : 提交 enduml逻辑上Dormitory和Student之间是关联关系1到0..*表示一个宿舍可以关联多个学生Student和RepairOrder之间也是关联表示一个学生可以提交多条报修记录。类图里的方法getInfo()、updateInfo()、setResolveTime()分别对应用例描述中的查询、修改、登记操作。提示PlantUML 中--是关联o--是聚合*--是组合多重性写在双引号里放在靠近目标类的一端。4. 动态模型时序图、协作图、活动图的建模顺序4.1 三种动态图的分工用例模型回答“有哪些功能”类图回答“有哪些对象”动态模型回答“对象之间怎么协作”。时序图强调消息在时间线上的先后顺序协作图强调对象之间的连接结构消息带编号活动图站在流程视角表现分支、循环和并行。文档里把“修改学生信息”同时画成时序图和协作图说明两者可以互相转换只是侧重点不同。图类型关注什么核心要素使用场景时序图消息先后顺序生命线、激活条、消息表现单个用例的交互细节协作图对象间连接结构对象、链、带编号消息强调对象拓扑关系时使用活动图业务流程分支初始节点、活动、决策、合并、分叉、汇合跨角色业务流程如报修处理如果某个用例对应的时序图消息超过二十条说明用例粒度过粗需要拆分。这也是评审时判断建模水平的一个快速标准。4.2 从用例基本路径画时序图以“登记报修解决时间”为例这条用例的基本路径是管理员选择报修单输入解决时间系统保存。时序图里至少要有管理员、报修管理界面、RepairOrder实体和数据库四个参与对象。startuml actor 宿舍楼管理员 as admin participant 报修管理界面 as ui participant RepairOrder as order participant 数据库 as db admin - ui: 打开报修列表 ui - db: 查询未解决报修() db -- ui: 返回报修记录 admin - ui: 选择报修单(orderId) admin - ui: 输入解决时间(time) ui - order: setResolveTime(time) order - db: update resolve_time db -- order: 更新成功 order -- ui: 保存成功 ui -- admin: 显示登记结果 endumlactor表示外部参与者participant表示系统内部对象或模块。实线箭头-表示同步消息调用虚线箭头--表示返回结果。这里每个消息都能对应用例基本路径中的一个步骤查询报修、选择报修单、设置时间、保存。如果漏掉返回消息时序图会失去完整性评审时一眼就能看出流程没有结果。用例描述里的扩展路径也要映射到时序图上。比如报修单不存在可以用alt片段包一段异常分支提示“无此报修单”。很多模板只画主流程不画异常分支这是动态模型和用例描述不一致的典型表现。4.3 活动图要素初始节点、决策和泳道活动图是动态模型中最容易画“飘”的图。要素包括初始节点、活动节点、决策节点、合并节点以及并行用的分叉和汇合。以住宿学生提交报修流程为例startuml start :登录系统; :获取学生住宿信息; if (是否有未处理报修?) then (是) :查看维修进度; else (否) :创建报修单; :填写故障描述; :提交报修申请; endif :等待维修结果; stop endumlstart和stop是流程起点和终点if/else生成决策节点endif把两个分支合并回同一条流程线。这里最容易犯的错是把互斥分支画成了并行分叉。互斥用菱形并行才用粗横线。文档里的宿舍楼管理员活动图、住宿学生活动图、系统管理员活动图都可以用同一套规则重画。如果活动图里有两个角色协作比如管理员处理报修、学生查看结果就加泳道。Visio 的“UML 活动图”模板里有“泳道”形状把活动分别拖进对应角色区域即可。5. 构件图与部署图之外交付前的一致性检查技巧5.1 从部署图判断系统边界这份文档的构件图和部署图看起来简单但能说明系统物理边界。构件图把系统拆成宿舍管理员操作构件、住宿学生构件、系统管理员构件表示三个子系统可以独立开发和部署部署图画出客户端、服务器和数据库之间的连接。课程设计阶段不需要画到源码文件级别画到“可以分模块部署”的程度就够。判断标准是别人拿到部署图能知道系统跑在哪些节点上客户端通过什么协议访问服务端数据存在哪里。5.2 答辩前十五分钟的核对方法面对这类模型文档我一般用三层核对来检查完整性。先把用例模型当索引第一每个用例是否至少对应一张时序图或活动图第二用例里的业务操作是否能在类图中找到对应方法比如“删除学生信息”对应Student.deleteInfo()第三活动图里的每个分支是否能回溯到用例描述中的扩展路径。三层核对都通过模型基本不会打架。检查项常见问题修正方式用例到动态图有用例但没有时序图按基本路径补画时序图用例到类图用例出现“登记报修”类图没有 RepairOrder补充类并关联 Student动态图到用例扩展时序图只画主流程异常分支缺失增加 alt/else 片段如果你拿到一份现成的宿舍管理系统 UML 文档准备改成自己的题目我建议不要先动图先把用例描述表里的参与者、前置条件和基本路径替换成自己的业务术语再回头改用例图。因为用例描述是所有模型共同的唯一数据源。可以试着做一个最小改动在“查看住宿信息”用例里加一条“扩展路径学号不存在时提示重新输入”然后在对应时序图上补一个alt片段。只做这一步整套 UML 模型的完整度就会明显改观。本文还有配套的精品资源点击获取