简介《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 建模这门课学到的东西和工作里的系统设计是一脉相承的先想清楚用例边界再落类图最后用动态模型验证行为这套顺序就是面向对象分析设计的主线。希望这份梳理能帮到你。本文还有配套的精品资源点击获取