企业官网建设流程全解析

简介：UML学生宿舍管理系统实验报告文档，面向软件工程、面向对象分析设计课程的学习者及需要完成课程设计的在校生。文档以学生宿舍管理系统为实践案例，系统阐述如何利用UML统一建模语言开展需求分析与系统设计，内容涵盖宿舍楼管理员、宿舍楼学生、系统管理员和其他用户四类角色的需求分析、用例模型及静态模型设计，并配有参与者识别、用例图相关说明，层次清晰、结构完整，适合作为实验报告模板或期末综合作业参考。资源包内仅有1个doc文档，整体压缩包452KB，轻量易用，便于直接阅读和编辑改写。目前已有228人学习/下载，对正在撰写UML建模作业的学生具有较高参考价值。通过这份报告可获得一套完整的UML建模思路与文档组织方法，从需求分析入手，逐步过渡到用例建模和类图等静态模型搭建，覆盖宿舍入住退宿、信息查询、系统配置与日志管理等典型业务场景，能够帮助理解系统角色划分与功能边界的表达方式，有效提升UML实践与文档写作能力。

1. 学生宿舍管理系统 UML 文档，真正值钱的是用例描述

看到“UML-学生宿舍管理系统.doc”这类文件名，多数人第一反应是又一个课程设计模板，下载下来就完事。但把这份实验报告从头到尾拆开看，它其实是一套完整的 UML 全流程案例：从需求分析开始，依次给出用例模型、类图、时序图、协作图、活动图、构件图和部署图，每一步都有产物。真正值得反复读的不是图面效果，而是每个用例都写了前置条件、后置条件、基本路径和扩展路径；后面所有模型几乎都能从这些文字里推出来。适合正在写软件工程实验报告、做毕业设计前期建模，或者想搞明白“用例图之后到底该画什么”的人对照着看。

2. 从需求到用例模型：先把四类参与者和用例边界定死

2.1 四类参与者怎么识别

需求分析里第一件事不是画用例图，而是识别参与者。这份文档把系统拆成宿舍楼管理员子系统、宿舍楼学生子系统、系统管理员子系统、其他用户子系统，对应四个参与者：宿舍楼管理员、住宿学生、系统管理员、其他用户。判断依据不是“谁能打开系统”，而是“谁在系统外部，通过与系统交互达成目标”。因此学校/学院不是参与者，公告只是由管理员录入的数据；其他用户虽然是只读角色，但会查看宿舍整体情况、生成报表，所以也是参与者。

参与者识别错了，后面全错。比如把宿舍楼管理员和系统管理员合并成一个“管理员”，修改学生信息和用户注册就会被混到一个用例集里，后续类图和部署图的关系也会跟着乱。我一般先写一张参与者清单，再开始画用例图，尽量不在画图过程中临时加角色。

2.2 用例描述表怎么写才不空

这份文档里最容易被忽略但最有价值的是用例描述。每个用例都有六个要素：用例名称、参与者、前置条件、后置条件、基本路径、扩展路径。很多网上下载的模板只画几个椭圆，不写描述，结果评审时一问“异常分支怎么处理”就答不上来。这里的“修改学生信息”用例就是一个标准样板：前置条件是管理员已登录且学生已转专业或调宿，后置条件是修改成功则数据库更新、失败则系统状态不变，基本路径从请求修改到提交保存逐步编号，扩展路径单独处理学号不存在的情况。

扩展路径是整套建模里最容易翻车的地方。以“查看住宿信息”为例，基本路径只有三步：输入学号、系统查询、显示住宿信息；扩展路径则处理“系统没有该学号”的情况，并给出“重新输入或取消”两个出口。把这些分支收集起来，可以直接变成后续测试用例的异常场景来源。所以我通常建议：先写用例描述，再画用例图，顺序不要反过来。

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类。先有文字，再有类，这样建模才不容易漏。

类还可以按职责分组：参与者类、实体类、控制类。比如Student、DormitoryAdmin属于参与者类；RepairOrder、ReturnRecord是实体类；LoginService、StudentInfoService是控制类。我不建议把所有类画在一张巨型类图里，按子系统拆成包图会更容易评审。包图和类图是同一套模型的不同视图，包关系可以理解为“这个包里的类依赖另一个包里的类”。

3.2 类之间的关系：组合、聚合还是关联

UML 类图最容易画错的是关系类型。我的判断顺序是：先看两个类是否存在生命期绑定。比如“宿舍”和“床位”，床位的生命周期依附于宿舍，用组合关系，实心菱形；“宿舍楼”和“宿舍”是整体与部分，但宿舍楼拆除后宿舍这个概念仍然可以独立存在，用聚合关系，空心菱形；“学生”和“报修单”只是使用关系，报修单不因为学生删除而必须删除，用普通关联。依赖关系一般保留给“类的方法参数里出现另一个类”的情况，比如服务层依赖数据访问层。

多重性也别写反。一个宿舍可以住 0..* 个学生，那么宿舍那一端写 1，学生那一端写 0..；一个学生可以提交 0..条报修，那么报修单那一端写 0..*。评审时先看多重性，再看关系符号，比看类名更有用。

3.3 用 Visio 画 UML 类图的具体操作

用 Visio 画 UML 类图有两条路：新建时选“软件和数据库”分类下的“UML 模型图”，或者直接找“UML 类图”模板。要点是不要只拖“类”形状然后手动打字，要双击形状打开“UML 类属性”对话框，在属性、操作里维护信息，这样模型资源管理器里的数据才完整。操作步骤如下：

1. 新建 UML 类图，打开“模型资源管理器”；
2. 从“UML 静态结构”模具中拖入“类”形状；
3. 双击类形状，在“UML 类属性”中添加属性与操作，可见性用 + 表示 public，- 表示 private；
4. 使用“关联”连接线连接两个类，双击连接线设置起止多重性。

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: 显示登记结果 @enduml

actor表示外部参与者，participant表示系统内部对象或模块。实线箭头->表示同步消息调用，虚线箭头-->表示返回结果。这里每个消息都能对应用例基本路径中的一个步骤：查询报修、选择报修单、设置时间、保存。如果漏掉返回消息，时序图会失去完整性，评审时一眼就能看出流程没有结果。

用例描述里的扩展路径也要映射到时序图上。比如报修单不存在，可以用alt片段包一段异常分支，提示“无此报修单”。很多模板只画主流程，不画异常分支，这是动态模型和用例描述不一致的典型表现。

4.3 活动图要素：初始节点、决策和泳道

活动图是动态模型中最容易画“飘”的图。要素包括初始节点、活动节点、决策节点、合并节点，以及并行用的分叉和汇合。以住宿学生提交报修流程为例：

@startuml start :登录系统; :获取学生住宿信息; if (是否有未处理报修?) then (是) :查看维修进度; else (否) :创建报修单; :填写故障描述; :提交报修申请; endif :等待维修结果; stop @enduml

start和stop是流程起点和终点，if/else生成决策节点，endif把两个分支合并回同一条流程线。这里最容易犯的错是：把互斥分支画成了并行分叉。互斥用菱形，并行才用粗横线。文档里的宿舍楼管理员活动图、住宿学生活动图、系统管理员活动图都可以用同一套规则重画。如果活动图里有两个角色协作，比如管理员处理报修、学生查看结果，就加泳道。Visio 的“UML 活动图”模板里有“泳道”形状，把活动分别拖进对应角色区域即可。

5. 构件图与部署图之外：交付前的一致性检查技巧

5.1 从部署图判断系统边界

这份文档的构件图和部署图看起来简单，但能说明系统物理边界。构件图把系统拆成宿舍管理员操作构件、住宿学生构件、系统管理员构件，表示三个子系统可以独立开发和部署；部署图画出客户端、服务器和数据库之间的连接。课程设计阶段不需要画到源码文件级别，画到“可以分模块部署”的程度就够。判断标准是：别人拿到部署图，能知道系统跑在哪些节点上，客户端通过什么协议访问服务端，数据存在哪里。

5.2 答辩前十五分钟的核对方法

面对这类模型文档，我一般用三层核对来检查完整性。先把用例模型当索引：第一，每个用例是否至少对应一张时序图或活动图；第二，用例里的业务操作是否能在类图中找到对应方法，比如“删除学生信息”对应Student.deleteInfo()；第三，活动图里的每个分支是否能回溯到用例描述中的扩展路径。三层核对都通过，模型基本不会打架。

如果你拿到一份现成的宿舍管理系统 UML 文档，准备改成自己的题目，我建议不要先动图，先把用例描述表里的参与者、前置条件和基本路径替换成自己的业务术语，再回头改用例图。因为用例描述是所有模型共同的唯一数据源。可以试着做一个最小改动：在“查看住宿信息”用例里加一条“扩展路径：学号不存在时提示重新输入”，然后在对应时序图上补一个alt片段。只做这一步，整套 UML 模型的完整度就会明显改观。

本文还有配套的精品资源，点击获取