企业官网建设流程全解析

简介：《UML面向对象分析与设计.docx》是一份面向计算机、软件工程及相关专业学生的课程设计资料，围绕“简易教学管理系统”展开UML分析与建模，帮助学生掌握面向对象程序设计、数据结构、数据库与软件工程基础。资源为单一Word文档，约3.44MB，覆盖需求陈述、设计目的与理论基础、具体步骤及模型图，包括顶层用例图、选课与成绩管理用例图、顺序图、类图、状态图、活动图、组件图等，可完整了解从需求到建模再到正向工程实现的流程。文档同时给出教师、学生、教学管理人员的职责分工和数据表建议，并附有项目任务分解与知识点说明，适合课程实践、期末大作业或自学参考。目前已有185人学习下载，可作为UML课程设计与Rational Rose工具应用的直接参考资料。

1. UML 面向对象分析与设计大作业：难点不在画图，在模型一致性

做《UML 面向对象分析与设计》的课程设计作业，最常见的心态是“用例图、类图、顺序图各画一张就交差”。我拆过几份简易教学管理系统这类题目的作业，发现老师真正在意的不是某张图好不好看，而是模型之间能不能互相追溯：用例里的每个功能有没有落到类图的操作，顺序图里发出的每条消息能不能在类图上找到对应的方法。这份资源是一份完整的课程设计任务书，需求陈述、建模步骤、模型示例和报告模板都齐。它最适合正在做相关课程设计、备考软考中级 UML 建模，或者想系统补一遍面向对象建模流程的人。跟着它完整走一遍，能少踩很多我当年踩过的坑。

2. 三层用例图拆解：先把角色权限边界定死，再动笔

2.1 角色与权限矩阵：三个使用者加一个外部系统

用例图是需求视图，它的边界完全取决于“谁能干什么”。简易教学管理系统里直接用户有三个——学生、教师、教学管理人员，另外还有一个外部参与者：财务系统。财务系统在用例图里用参与者表示，它只接收选课注册信息用来计算费用，不需要向教学系统反馈，所以只画一条指向“传送选课注册信息”用例的关联就行了，不要画成双向。

权限边界是这门作业最容易忽略的点。任务陈述里写得很清楚：学生只允许查询自己的选课信息和考试成绩，不允许查别人的；教师和教学管理人员可以按课程名、教师名、学分、班级、职称等关键字做查询。这个“自己”两个字直接决定用例的划分粒度——“查询学生选课信息”和“查询自己的选课信息”是两个不同颗粒度的用例。我在复现时先列了一张角色权限矩阵，再动笔画图，后面基本没返工。

这里有一个常见做法值得说明：直接把“查询”拆成“查询课程信息”“查询选课信息”“查询师生信息”“查询成绩”四个用例，而不是画一个笼统的“查询”用例。因为每个查询对应的操作对象和权限规则都不一样，合并成一个会让后续顺序图和类图没法画。权限粒度粗了，后面类图里的方法归属就会乱。

2.2 三层用例图：顶层、选课管理、成绩管理怎么组织

任务书要求定义顶层 Use Case 图、选课管理的 Use Case 图、成绩管理的 Use Case 图，注意这不是让你画三张完全独立的图，而是三层递进关系。顶层图把系统边界画出来：参与者（学生、教师、管理员、财务系统）和两个用例包——选课管理、成绩管理。第二层才在每个包内部展开具体用例。

选课管理子图至少包含这几项：录入与生成新学期课程表、学生选课注册（允许修改和取消）、课程/选课/师生信息查询、选课注册信息统计与报表生成、传送财务系统。成绩管理子图包含：成绩录入、成绩查询、成绩统计与报表生成。有一个细节：查询在选课和成绩两个包都会出现，但操作的业务对象不同，查询规则也不同，不要强行合并成一个用例。我在给学员看参考模型时，经常提醒他们把查询相关用例按“对象+权限”拆开，而不是按“功能”合并。

用例之间的关系是这里的考点。选课注册用例会使用到“验证学生身份”这类公共行为，用<<include>>包含关系表达；而“选课人数已满”“超过个人选课上限”这类在正常流程之外的分支，用<<extend>>扩展关系挂在主用例上。很多作业翻车就翻在把include和extend画反了——包含是主用例必然要执行的一部分，扩展是可选的异常分支，语义完全不同。

2.3 用例描述：业务规则必须写进流程，而不是留在文字里

这个项目的评分重点不在那张用例图，而在用例描述。选课管理里三条硬规则经常被当成“说明文字”忽略：每门课实际选课人数少于 10 人则停开、多于 60 人停止选课、每个学生选课不超过 4 门。这三条如果不写进用例描述或活动图，模型就是残缺的。

以“学生选课注册”为例，用例描述的主事件流一般写成：学生登录系统 → 查询本学期可开课程 → 提交选课申请 → 系统校验该课程是否已满 60 人 → 写入选课记录 → 返回选课成功。备选流处理：课程已满、学生已选 4 门、修改注册、取消注册。前置条件是当前处于选课注册窗口期。注意两条人数规则的触发时点不同：停开（少于 10 人）发在课程表维护阶段，停选（多于 60 人）发生在学生选课注册阶段。所以停开规则挂在“录入与生成新学期课程表”用例下，停选规则挂在“学生选课注册”用例下，挂错位置就是理解不到位。

3. 类图与包图：从顺序图抽操作，把六张数据库表映射出来

3.1 从顺序图抽操作：类不是拍脑袋想的

任务书把建模顺序规定得很清楚：先做用例分析，再画交互行为图（顺序图），然后从顺序图抽取类的操作，最后绘制类图。这个顺序和很多人的习惯相反——大多数人上来就画类图，画到一半发现没有操作可填。正确路径是反过来的：顺序图里每条消息都是发送方调用接收方的一个操作，把若干条消息汇总去重，类的方法就出来了。

以选课注册顺序图为例，消息序列大致是：学生登录 → 系统验证身份 → 学生查询课程表 → 学生提交选课 → 系统校验选课人数 → 系统写入选课记录 → 返回结果。这些消息落到类上，“提交选课”成为选课记录（Enrollment）的创建操作，“校验选课人数”成为课程（Course）的人数校验方法，“查询课程表”成为课程目录（CourseCatalog）的查询方法。我一般会先画一张“消息到类操作”的映射表，确保类图上的每个操作都能在顺序图里找到出处。这样画出来的类图不会出现“类有了、方法全是空的”这种尴尬情况。

3.2 类图关系与箭头含义：这是作业批改的重灾区

UML 类图箭头含义是基础，也是扣分大户。很多作业把聚合（空心菱形）、组合（实心菱形）、关联（实线箭头）混着用，老师一眼就能看出来是硬凑的。为方便对照，我把本项目会出现的几类关系整理成一张表：

简易教学管理系统里真实存在的关系是：学生与选课记录是一对多关联，课程与选课记录是一对多关联，教师与课程通过任课表构成多对多关联。选课记录本质上是学生和课程多对多关系拆出来的关联类，这是类图上最值得写清楚的地方。组合关系不要硬加，教学管理和人事信息之间没有“部分随整体销毁”的强生命周期绑定，画成聚合就足够。如果需要扩充功能，可以增加“用户”抽象基类，让学生、教师、管理员三个角色继承它，公共属性（姓名、账号）放到父类里。

3.3 包图与六张数据库表：把模型落到表结构上

包图用来组织复杂系统，任务书里已经给了“教学管理包图”的结构：教学管理包下挂课程管理、人事信息等子包，人事信息包内含学生和教师。包图本身的画法不难，难的是把包里的类与数据库表一一对应起来。附录里明确要求建立学生表、教师表、课程表、选课表、任课表、成绩表六张表，这正是类图关系落到物理存储的直接结果。

我给课程表和选课表写了一个参考建表语句：

CREATE TABLE course ( course_id INT PRIMARY KEY, course_name VARCHAR(50) NOT NULL, credit DECIMAL(3,1), teacher_id INT, max_students INT DEFAULT 60, min_students INT DEFAULT 10 ); CREATE TABLE enrollment ( student_id INT NOT NULL, course_id INT NOT NULL, status VARCHAR(10) DEFAULT 'registered', PRIMARY KEY (student_id, course_id) ); CREATE TABLE score ( student_id INT NOT NULL, course_id INT NOT NULL, score DECIMAL(5,2), PRIMARY KEY (student_id, course_id) );

这段 SQL 里有两个关键设计。max_students 和 min_students 字段把 60 人上限、10 人下限这两条业务规则落成了数据库约束，后续统计报表直接基于这两列做判断。选课表的主键是 (student_id, course_id) 联合主键，这符合“一个学生同一门课只能有一条选课记录”的业务约束，同时也体现了它是学生和课程之间多对多关系的关联表。成绩表同样以联合主键关联学生和课程，表示一次考试对应一个学生在一门课上的成绩。类图上的每个类、每条关联，最终都能在这六张表上找到落点，模型和实现才对得上。

4. 动态行为建模：顺序图、状态图、活动图按什么标准选

4.1 顺序图：消息时序体现用例实现

顺序图是用例实现的主要表达方式，它描述了对象之间按时间顺序传递的消息。任务书要求对主要用例绘制顺序图，选课注册是必画的一张。画顺序图的关键不是把 lifeline 画得多漂亮，而是消息顺序要和用例描述的主事件流严格一致。

我在画选课注册顺序图时，一般会先列消息序列：学生发送登录请求 → 系统验证身份 → 学生查询课程目录 → 学生提交选课记录 → 系统检查课程人数 → 系统保存选课记录 → 系统返回结果。每条消息标注序号，消息名要和后续类图上的操作名匹配。这里有一个经验：不要把“数据库”画成一条 lifeline，而是把数据读写操作放在系统或课程对象上。因为这是分析模型，不是实现方案，过早引入数据库会污染设计。协作图（通信图）和顺序图语义等价，只是排列方式不同，任务书要求顺序图即可，协作图在软考里有考概念，理解两者可互相转换就够。

4.2 状态图：选课登记的四种状态

状态图适合描述单个对象的生命周期变化。任务书里有一张“选课学生登记状态图”，这是很多人不会画或者画不出内容的一张图。学生的选课登记状态至少应该包含：未注册、已注册、已取消，如果考虑选课结束后的锁定，还可以加一个已确认状态。

触发事件要一一对应：提交选课使状态从未注册变为已注册；在选课窗口内取消注册，状态从已注册变为已取消；选课结束后管理员锁定选课结果，状态变为已确认。状态图的价值在于能发现用例描述里没写清楚的行为——比如“学生能否修改选课”在状态图上就表现为已注册状态收到“修改”事件后重新执行选课流程，这比文字描述直观得多。我在检查作业时，会重点看状态图里的事件有没有在用例描述里出现，两边对不上说明对象行为分析是凑的。

4.3 活动图：设置开设课程的流程与人员协作

活动图用来描述业务流程，它的特点是能用泳道表达不同参与者之间的职责划分，用分支表达业务规则。设置开设课程是本项目最值得画活动图的一个用例，因为两条人数规则在这里有明确的分支判断。

活动流程大致是：教学管理人员登录系统 → 录入新学期课程 → 提交审核 → 系统校验课程信息 → 发布课程目录 → 选课窗口开启后监控选课人数 → 若某门课选课人数少于 10 人，停开并删除该课程；若某门课选课人数达到 60 人，停止该课程的选课。用泳道图来表示，教学管理人员管录入和发布，系统管人数监控和状态变更，两条泳道之间的信号就是这个系统最核心的业务逻辑。活动图的分支判定条件正好对应用例描述里的两条业务规则，这样一来文字规则真正进入了模型。

4.4 动态图选择标准：一张表决定画什么

很多新手的问题是不知道什么时候该画哪种动态图。UML 中的动态结构图包括顺序图、协作图、状态图和活动图四类，选型的标准不是“越多越好”，而是看你要表达什么。我一般用这样一张表来判断：

判断方式很简单：一条消息接一条消息的交互过程，用顺序图；一个对象有多种状态且状态受事件驱动，用状态图；一个业务流程涉及多个角色、多个步骤，用活动图。这张判断表在软考中级 UML 建模里也是通用的，做一遍这个项目基本就记住了。

5. 避坑：Rational Rose 从建模到报告的高频翻车点

5.1 画图阶段最常见的三个模型错误

第一个高频坑：include 和 extend 画反。现象是选课注册用例上画了一条指向“验证身份”的<<extend>>，或者把“课程人数已满”画成了<<include>>。原因是没有理解两种关系的语义——include是主用例执行过程中必定调用的公共步骤，extend是满足特定条件才触发的可选扩展。解决方法是画之前先问一句：这一步是不是所有场景都必须走？是则 include，否则是 extend。验证身份是每次选课都要走的，是 include；人数已满是异常分支，是 extend。

第二个高频坑：类图箭头含义混用。现象是把学生和选课记录之间画成聚合，把课程和选课记录之间画成组合。原因是对关联、聚合、组合的区别只停留在“名词解释”层面，没有结合业务判断。解决办法是用生命周期检验：选课记录从属于学生和课程吗？学生注销了选课记录还在不在？在这个系统里选课记录是独立业务数据，用普通关联就够，不需要聚合更不需要组合。

第三个高频坑：模型不一致。现象是顺序图里发送了“查询成绩”消息，但类图上学生类根本没有这个操作；或者类图上有“统计报表”方法，但所有动态图里都找不到它的调用场景。原因是画图顺序混乱，先画类图再补动态图，导致两边对不上。我在该项目里强制自己的流程是：用例图 → 用例描述 → 顺序图 → 从消息提取操作 → 类图 → 状态图/活动图，每一张动态图都能在类图上找到对应方法才算通过。

5.2 Rose 工具本身的老毛病

第四个坑：正向工程生成不了代码。现象是选中类以后，Tools 菜单下的 C++ 或 Java 代码生成选项是灰色的，或者生成了但只有空类名没有方法。原因通常是两个：一是 Rational Rose 对语言版本配置有要求，Java 环境要选择对应的 JDK 版本选项，C++ 要设置 ANSI C++ 还是 MSVC 的映射；二是类的属性或操作没有赋值类型，Rose 无法推断参数类型就跳过生成。解决方法是先检查类的属性和操作是否都填了类型和可见性，再检查 Toolset 的版本配置。这个环节是典型的“黑匣子”，我当年第一次生成失败时以为是工具坏了，后来才发现是配置问题。

第五个坑：Rose 在新系统上装不上或频繁崩溃。现象是安装完成后启动闪退，或者画图时鼠标操作卡顿。原因是这个工具停止维护太早，对高版本 Windows 兼容性差。常见的解决办法是：安装时选择完整版而非典型版，右键 exe 属性里设置兼容模式运行，绘图时把自动保存间隔调短。如果图已经画了很多，记得定期导出 mdl 文件备份，我自己就吃过一次文件损坏的亏，那之后每画完一张图就导出一次。

第六个坑藏得很深：业务规则只在文字里，模型里没有。现象是需求文档里写了“少于 10 人停开”，但用例图、类图、状态图、活动图里完全看不到这条规则的痕迹。原因是默认了文字描述会被检查，忽略了模型要完整覆盖需求。解决方法是每一条业务规则都找一个模型落点——人数上限落到课程表的 max_students 字段和选课注册用例的备选流，人数下限落到活动图的分支判断里。规则在模型里找不到落点，这个模型就是不合格的。

6. 用 Rose 做正向工程：把类图生成 C++ 骨架后怎么验证

当类图、包图都稳定下来以后，就可以做正向工程了。Rational Rose 的位置在 Tools 菜单下，选择 C++ 或 Java 的 Code Generation，然后在弹出的窗口里勾选要生成的类。对于简易教学管理系统，我会在报告里附上课程类和选课记录类生成的框架代码，以证明模型是可实现的。

// course.h 由 Rose 正向工程生成的骨架 class Course { public: Course(); virtual ~Course(); int GetCourseId() const; void SetCourseId(int value); string GetCourseName() const; void SetCourseName(const string& value); bool checkCapacity(int currentCount); private: int m_courseId; string m_courseName; float m_credit; int m_maxStudents; int m_minStudents; };

生成的代码只是骨架，业务逻辑肯定要自己补，但结构是对的：属性类型来自类图，checkCapacity 方法对应了 60 人上限的校验操作。正向工程真正的价值是验证模型的可实现性——如果 Rose 能顺利生成代码，说明类图的属性、操作、可见性设置都是完整的，这门课最核心的“建模到实现”链路就通了。

我拿到生成结果后，会强制走一遍四个一致性检查：第一条，用例图上的每个用例，在顺序图或活动图里至少出现一次；第二条，每张顺序图里的消息，在类图上都能找到对应操作；第三条，类图上的每个多对多关联，都拆出了关联类或在数据库里有中间表；第四条，用例描述里的每一条业务规则，在活动图分支、状态图事件或类图字段里有明确落点。信息完整性和一致性都通过，这份模型才算可以交付。

从那以后，我每次做完一个系统模型都会强制走一遍这四个检查点，省下的返工远比多画的图值。UML 建模这门课学到的东西和工作里的系统设计是一脉相承的，先想清楚用例边界，再落类图，最后用动态模型验证行为，这套顺序就是面向对象分析设计的主线。希望这份梳理能帮到你。

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