尧图网站建设 
简介这是一份基于UML的学生信息管理系统课程设计报告面向软件工程、计算机等相关专业学生以及需要完成UML建模作业或课程设计的开发者。资源以doc文档形式呈现压缩包内仅1个文件体积约213KB为可编辑的Word文档便于直接修改复用。报告内容覆盖系统需求分析、业务流程与功能模块分析、问题域分析、用例图、类图、状态机图、活动图与顺序图等核心UML视图并延伸至数据库设计E-R模型与关键表单。文档从学生、教师、管理员的真实用例出发详细展示如何将学生信息、课程信息、成绩信息及用户认证等需求转化为静态结构模型与动态行为模型脉络清晰、层层递进配有完整UML图例与文字说明。读者既可参照其方法完成同类信息管理系统的UML建模也可直接将其作为课程设计报告模板使用。目前已有9339人学习下载内容由浅入深适合作为UML系统设计入门与实战的参考材料。1. 这份基于 UML 的学生信息管理系统资源真正值得抄的是建模顺序这份资源不是代码工程而是一份把 UML 系统设计整个流程走完的学生信息管理系统课程设计报告。它的反直觉之处在于当成作业模板抄没有意义真正值钱的是藏在章节里的建模顺序——先梳理业务流程再画用例图从用例图推出类图用顺序图、状态图、活动图补上动态行为最后落到数据库表。这个顺序正是系统设计里需求分析、静态建模、动态建模、物理设计四次递进的骨架。适合三类人课程设计要做学生信息管理系统的在校生、备考软考中级 UML 建模题的人以及拿到一个业务系统不知从哪张图下手的刚入行开发。2. 需求分析与用例建模五条业务流程、八类角色、两层用例粒度2.1 五条业务流程是画用例图的起点拿到一个业务系统第一反应应该是搞清楚业务怎么流转而不是急着打开 StarUML 拖图。这份报告把学生信息管理拆成了五条业务线学籍管理、成绩管理、奖惩管理、学生党员干部管理、毕业管理。每条业务线对应一个生命周期阶段从入学注册一路走到就业统计。以成绩管理为例完整流程是这样的任课教师把期末成绩单交到系里系秘书按班级录入、核对打印成绩单后交教务处统一处理此时学生才能查询成绩。如果某个成绩需要修改不能直接改数据库任课教师要先提交修改理由到教务处教务处登记修改内容和时间后才允许修改。注意这里有个值得学习的细节成绩管理的结果会作为奖惩管理的依据也就是说两条业务线之间有数据依赖建模时不能把模块完全割裂开。我一般会建议先写一页纸的流程说明把每条业务线的起点、中间操作、终点和涉及角色圈出来再开始画用例图。原因很简单用例图里的用例不是凭空想出来的而是从流程步骤里抽象出来的。流程说明里出现一次“录入”背后就是一个用例出现一次“审批”背后又是一个用例。跳过了流程分析直接画图画出来的用例图大概率是功能清单。2.2 八类角色与权限边界角色识别的结果是八类参与者学生、教师、系秘书、系学生工作人员、教务管理人员、学生处管理人员、招生就业工作人员、系统管理员。这八类角色基本覆盖了高校学生管理场景里的所有操作主体而且每类角色的权限边界划分得很清楚。角色主要职责典型操作学生提出申请、查询信息查询成绩、申请学籍变动教师查询信息、限时修改成绩请求查询成绩、打印成绩单系秘书成绩录入、核对、打印录入成绩、成绩统计分析系学生工作人员录入学生基本信息、给出初步意见录入档案、审核学籍变动申请教务管理人员档案维护、学籍变动审核、成绩审核修改注册登记、修改成绩学生处管理人员审核奖惩、审批勤工助学审核奖学金、审批岗位招生就业工作人员就业信息录入、统计分析就业情况登记、生成分析报表系统管理员权限管理、数据维护添加用户、备份恢复数据库从这张表能看出来不同角色的差别主要体现在“能操作哪些数据”和“操作权限到什么级别”上。比如同样是成绩相关操作系秘书能录入和打印教师只能查询和打印教务管理人员才有修改权。这个权限边界的划分在后面的用例图里会直接影响用例与角色的连接关系在数据库设计里会直接影响用户登录表的权限字段设计。2.3 用例粒度从十大高层用例到子用例系统的高层用例可以抽象成十类录入信息、修改信息、查询信息、分析统计、打印信息、申请项目、审核项目、审批项目、管理权限、维护系统。这十个用例基本覆盖了系统的全部功能需求是建立顶层用例图的基础。但顶层用例太粗糙比如“查询信息”到底包含哪些查询按学号查、按班级查、按系查、按课程查这些都需要进一步细化。细化的常见做法是自顶向下四步走先选定一个用例然后做场景分析把主场景和异常场景都列出来接着做用例分解把场景中的每步看成一个小的子用例最后做用例判定判断子用例能不能归为参与者的一次简单行为。能归入就作为精细化用例保留不能归入就继续往下拆。以学籍管理子用例为例可以从“学籍管理”这个抽象用例拆出三组注册报到管理登记、统计、查询、打印、基本档案管理录入、修改、查询、打印、学籍变动管理申请、审核、审批、登记、查询、打印。其中“学籍变动”是典型的流程型用例学生提出申请、系学生工作人员审核、教务管理人员审批一环扣一环。这样拆完之后每个子用例都有明确的参与者粒度也到了可以指导类图设计的程度。2.4 include 与 extend 别用反成绩管理子用例图里有一个很容易被忽略的关系标记《include》和《extend》的使用。录入成绩这个用例执行前必须走身份验证身份验证是每次录入都要执行的公共片段这里用《include》连接。学籍变动管理里当变动原因是违纪处分时需要额外触发的处分登记流程属于满足特定条件才走的扩展路径这里用《extend》连接。判断口诀很简单必选、每次都要执行的公共步骤用 include可选、满足条件才触发的扩展流程用 extend。很多新手把这两个标反结果评审的时候被一问就露馅。另外注意用例图里的箭头方向也有约定include 是从基础用例指向被包含的公共用例extend 是从扩展用例指向被扩展的基础用例画反了语义就完全变了。3. 静态结构建模从用例图细化到类图推导的完整路径3.1 输入输出推导法识别类用例图画完下一步是识别类。这里有一个实用的推导思路如果一个输入可以作为关联角色的属性存在那它就不必转成类如果一个输出能找到对应的责任实体来包容它也不必转成类。反过来既不能归入角色属性、又没有现成实体能包容的数据就要识别为新的类。面向对象方法里把类分成三种实体类、边界类、控制类。实体类负责描述必须存储的信息通常是持久化的边界类对应窗口、接口这些外部交互界面控制类负责协调业务逻辑调度实体类和边界类之间的操作。学生信息管理系统里成绩、学生、课程这类有存储需求的概念就是实体类登录窗口就是边界类成绩录入背后的业务逻辑调度就是控制类的活。3.2 实体类的属性定义成绩管理子系统的实体类设计可以直接参考原报告的属性定义这些字段基本都是查询统计时的硬需求少了任何一个后续都会难受。实体类属性学生学号、姓名、性别、班级、系别、专业教职工职工号、姓名、性别、出生年月、职务、部门课程课程号、课程名、课程性质、学分成绩学号、课程号、学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩用户登录用户名、密码、权限、终止日期注意成绩实体类的属性设计它把学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩都列全了。这意味着一个学生可以对应多条成绩记录每学期每门课一条补考和重修单独记录。这个设计直接决定了后面成绩表的主键不能只拿学号得用学号加课程号加学期代码做复合主键这一点在数据库章节还会再讲。3.3 类图继承教职工父类与三个岗位子类类图里最有代表性的部分是教职工类的继承结构。父类是教职工属性包括职工号、姓名、性别、出生年月、职务、所属部门操作包括登录、查询成绩、打印成绩、退出系统。三个子类分别是教师、系秘书、教务人员。教师在父类基础上增加了成绩统计分析操作系秘书增加了录入成绩操作教务人员增加了修改成绩操作。也就是说三个子类复用了父类的公共属性和大部分操作只在各自职责范围内做扩展。这个设计是典型的重构思路先把公共能力上提到父类子类只写差异避免三个类里重复堆相同的属性和方法。顺带把类图的箭头语义说清楚类图里箭头含义是固定的空心三角实线箭头指向父类是继承空心三角虚线箭头指向接口是实现普通实线箭头是关联虚线箭头是依赖。画类图的时候把这些箭头用对从观感上就比一堆没有关系的矩形框专业一个档次。3.4 类图交付检查清单类图画完我一般会按五个问题过一遍每个用例是否至少由一个角色激活每个实体类是否至少被一个边界类访问父类的公共属性和操作是否被所有子类复用无关类之间有没有多余的关联线新增的实体属性是否已经同步到后续数据库设计里。这套检查能挡住大部分静态模型的低级问题。4. 动态行为建模顺序图、状态图、活动图的选择与画法4.1 顺序图录入成绩的十条消息UML 中的动态结构图包括顺序图、协作图、状态图、活动图。顺序图强调交互的时间顺序适合描述一个完整操作从发起到落库的消息流转。成绩录入场景的顺序图是报告里最完整的一张动态图参与对象有四个系秘书、登录窗口、成绩录入窗口、成绩信息数据库。消息序列按时间从上到下排登录、身份验证、验证通过、进入成绩管理窗口、录入、修改、删除、提交、写入数据库、退出。这里每一组箭头都是一次方法调用前四条是认证与导航中间三条是数据操作后面两条是提交与落库最后退出。画顺序图的时候每个对象下面要有垂直虚线表示生命线方法执行期间生命线上叠加矩形激活条同步调用用实心箭头。把控好这几点顺序图就不会画成流程图。4.2 状态图查询与登录的状态转移状态图用来描述一个特定对象在自己生命周期里的状态变化以及触发变化的事件。状态图不是所有对象都要画只画那些状态多、且行为受外部事件影响的对象。报告里给了两个典型的子状态图。查询子状态图请求查询状态输入合理查询条件后进入进行查询状态查找完进入返回查询结果状态此时可以再次查询回到请求状态也可以退出如果输入不合理的查询条件直接回到请求状态。这个循环逻辑用状态图表达比文字描述清晰得多。用户登录子状态图系统先处于等待用户输入账号密码状态数据传送后进入检测用户信息状态。输入合法就进入对应权限的用户界面输入不合法进入检查输入次数状态未超过允许次数就回到等待输入状态重试超过次数则结束登录。这里要特别提醒一句状态图上的守卫条件数字必须和需求文档保持一致图里写 5 次、文档里写 3 次这种前后矛盾是评审时的重灾区后面避坑章节会展开说。4.3 活动图查询成绩的工作流活动图本质上就是一种流程图描述从活动到活动的控制流。它和状态图的区别在于活动图适合表达跨越多个对象的业务流程状态图聚焦单个对象的状态变迁。所以像“学生查询成绩”这种完整流程用活动图更合适。活动图建模可以按七步走识别工作流目标用开始状态和终止状态描述前置和后置状态识别实现目标所需的所有活动并按逻辑顺序放置定义活动创建或修改的对象用对象流连接用变迁把所有元素连起来在需要分支的地方画可选流如果有并行工作流用同步条表示分岔和汇合。查询成绩的活动流程是学生进入系统输入用户名和密码系统检查信息错误就要求重新输入正确就进入选择查询类型环节输入关键词系统查询并显示成绩单然后询问是否继续查询不查询就退出继续查询就回到选择查询类型。这个流程里的“检查信息正确与否”就是分支点“是否继续查询”是又一个分支点两个分支点把整个流程切成三段逻辑很清楚。4.4 三张动态图怎么选画动态图之前先想清楚自己要表达什么。强调消息先后顺序选顺序图强调单对象的状态变化与事件触发选状态图强调跨对象的业务流程分支与并发选活动图。如果重点是多个对象之间的组织结构协作关系那就用协作图但在这种管理信息系统场景里顺序图的使用频率远高于协作图。动态图表达重点本系统典型场景顺序图消息的时间顺序系秘书录入成绩状态图单对象状态与事件查询循环、登录重试活动图流程分支与并行学生查询成绩完整流程5. 数据库设计中的常见问题与关键表单E-R 模型落表的三处硬伤5.1 数据库设计三段式流程数据库设计不是直接建表而是走三段先根据用户需求确定要保存哪些数据这是概念建模的基础再设计数据的概念模型也就是 E-R 模型用实体和联系表达现实世界最后做逻辑结构设计把概念模型转换成数据库管理系统支持的二维表结构。这个顺序和 UML 建模的顺序是呼应的实体类识别出来的信息需求到这一步变成具体的表和字段。5.2 E-R 模型的实体与联系报告里的 E-R 模型覆盖了系统的主要实体和联系。核心实体是学生、成绩、课程、奖惩、勤工助学、贷款、就业、基本档案实体之间的联系方式决定了关系表怎么建。联系类型说明学生与成绩1:N一个学生有多条成绩记录课程与成绩1:N一门课程对应多条成绩记录学生与奖惩1:N一个学生多条奖惩记录学生与勤工助学M:N一个学生可申请多个岗位一个岗位可由多个学生承担学生与就业1:1一个学生一条就业去向学生与贷款1:N一个学生可多次贷款教务人员与学籍变动1:N一个教务人员审批多条变动记录这里最容易出错的是 M:N 联系。学生与勤工助学是 M:N落表时不能直接靠加外键解决需要拆出一张关联表把岗位和学生的关系以及申请时间、审批状态这些属性挂在关联表上。如果直接在学生表里加一个岗位字段一个学生申请两个岗位时就只能覆盖写数据直接丢。5.3 关键表单的字段定义系统里最核心的几张表是学生基本信息表、成绩表、课程表、用户登录表。学生基本信息表的结构直接复用实体类的属性定义字段名数据类型键值说明学号varchar(20)主键学生唯一标识姓名varchar(20)非空学生姓名性别char(2)男/女班级varchar(30)行政班级系别varchar(30)所属系部专业varchar(30)所学专业成绩表是另一个关键表字段包括学号、课程号、学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩。主键必须用复合主键学号、课程号、学期代码否则一个学生同一门课只能存一条记录补考和重修数据就没地方放。课程表相对简单字段为课程号、课程名、课程性质、学分课程号作为主键。用户登录表则是用户名、密码、权限、终止日期用户名主键权限字段正好对应前面八类角色的划分。5.4 三个常见问题与纠正方法问题一用例图画成了功能树。现象是整个用例图就是“添加学生、删除学生、修改学生、查询学生”这种按钮级别的功能清单评审时被指出这不是用例而是操作步骤。原因是画图时没有从角色目标出发而是照着界面功能罗列。解决方法是套用例的三特征判断是否由角色激活、是否为角色提供可识别的值、是否具有完全性。以“修改成绩”为例正确写法是教务管理人员登录后在成绩管理界面选择记录、修改、提交、写入数据库整个流程走完才算完成一个用例而不是把“修改”两个字单独拎出来。问题二实体类属性直接当表字段漏了复合主键。现象是成绩表用学号当主键导致同一门课补考和重修的成绩存不进去。原因是跳过了 E-R 模型直接落表学生与成绩的 1:N 联系没有转成外键和复合主键。解决方法是先画 E-R 图把每个 1:N 联系的“1”方主键落到“N”方做外键成绩表用学号加课程号加学期代码做复合主键。这个坑几乎每个做课程设计的人都会踩一次数据库设计那一步偷懒后面写 SQL 的时候全得还回来。问题三状态图守卫条件与需求文档数字不一致。现象是登录状态图里画着“少于 5 次可继续输入、超过 5 次结束”需求文档里写的是最多尝试 3 次图与文档打架。原因是状态图画完没有回查需求文档。解决方法是状态图上每个守卫条件都要和需求文档做一次核对以验收文档为准图只是文档的图形化表达。6. 把 UML 模型转成可演示原型三件套落地与评审讲法这套模型的终点不是图而是能跑起来的原型。我通常会把三张图转成三件事类图转建表语句顺序图转接口调用链活动图转页面跳转逻辑。类图转表最直接每个实体类就是一张表属性转字段继承关系处理成公共字段放父表或子表冗余实体类里定义的属性几乎可以原样搬过去。顺序图转接口调用链把每条消息当成一次方法调用比如录入成绩的顺序图里录入、修改、删除、提交、写入数据库这五条消息落到代码就是成绩服务里的 saveOrUpdate、delete、submit、writeDB 四个方法顺序图的消息顺序就是接口的调用顺序。活动图转页面跳转每一个活动状态对应一个页面或一个操作分支判断落到前端或后端控制层。评审讲法也有技巧。每张图只讲一句话用例图说“系统给谁用、有哪些功能”类图说“系统里的数据长什么样”顺序图说“一次操作的消息怎么走”活动图说“流程在哪分叉”数据库表说“数据存到哪”。讲的时候按这条主线走评委基本不会被带偏。这套顺序我吃了不少亏才固定下来。以前我拿到业务系统就急着画用例图画到一半发现类图没法推又回头补需求分析图改了三轮数据库表还是漏了复合主键。从那以后我每次接 UML 建模的活都强制自己先花二十分钟写一页纸的业务流程说明把角色和动作圈出来再决定第一张图画什么。先流程后图先静态后动态最后落表这套顺序能少翻好几次车希望帮到你。本文还有配套的精品资源点击获取 UML建模顺序实战：从用例图到数据库设计的学生信息管理系统
简介这是一份基于UML的学生信息管理系统课程设计报告面向软件工程、计算机等相关专业学生以及需要完成UML建模作业或课程设计的开发者。资源以doc文档形式呈现压缩包内仅1个文件体积约213KB为可编辑的Word文档便于直接修改复用。报告内容覆盖系统需求分析、业务流程与功能模块分析、问题域分析、用例图、类图、状态机图、活动图与顺序图等核心UML视图并延伸至数据库设计E-R模型与关键表单。文档从学生、教师、管理员的真实用例出发详细展示如何将学生信息、课程信息、成绩信息及用户认证等需求转化为静态结构模型与动态行为模型脉络清晰、层层递进配有完整UML图例与文字说明。读者既可参照其方法完成同类信息管理系统的UML建模也可直接将其作为课程设计报告模板使用。目前已有9339人学习下载内容由浅入深适合作为UML系统设计入门与实战的参考材料。1. 这份基于 UML 的学生信息管理系统资源真正值得抄的是建模顺序这份资源不是代码工程而是一份把 UML 系统设计整个流程走完的学生信息管理系统课程设计报告。它的反直觉之处在于当成作业模板抄没有意义真正值钱的是藏在章节里的建模顺序——先梳理业务流程再画用例图从用例图推出类图用顺序图、状态图、活动图补上动态行为最后落到数据库表。这个顺序正是系统设计里需求分析、静态建模、动态建模、物理设计四次递进的骨架。适合三类人课程设计要做学生信息管理系统的在校生、备考软考中级 UML 建模题的人以及拿到一个业务系统不知从哪张图下手的刚入行开发。2. 需求分析与用例建模五条业务流程、八类角色、两层用例粒度2.1 五条业务流程是画用例图的起点拿到一个业务系统第一反应应该是搞清楚业务怎么流转而不是急着打开 StarUML 拖图。这份报告把学生信息管理拆成了五条业务线学籍管理、成绩管理、奖惩管理、学生党员干部管理、毕业管理。每条业务线对应一个生命周期阶段从入学注册一路走到就业统计。以成绩管理为例完整流程是这样的任课教师把期末成绩单交到系里系秘书按班级录入、核对打印成绩单后交教务处统一处理此时学生才能查询成绩。如果某个成绩需要修改不能直接改数据库任课教师要先提交修改理由到教务处教务处登记修改内容和时间后才允许修改。注意这里有个值得学习的细节成绩管理的结果会作为奖惩管理的依据也就是说两条业务线之间有数据依赖建模时不能把模块完全割裂开。我一般会建议先写一页纸的流程说明把每条业务线的起点、中间操作、终点和涉及角色圈出来再开始画用例图。原因很简单用例图里的用例不是凭空想出来的而是从流程步骤里抽象出来的。流程说明里出现一次“录入”背后就是一个用例出现一次“审批”背后又是一个用例。跳过了流程分析直接画图画出来的用例图大概率是功能清单。2.2 八类角色与权限边界角色识别的结果是八类参与者学生、教师、系秘书、系学生工作人员、教务管理人员、学生处管理人员、招生就业工作人员、系统管理员。这八类角色基本覆盖了高校学生管理场景里的所有操作主体而且每类角色的权限边界划分得很清楚。角色主要职责典型操作学生提出申请、查询信息查询成绩、申请学籍变动教师查询信息、限时修改成绩请求查询成绩、打印成绩单系秘书成绩录入、核对、打印录入成绩、成绩统计分析系学生工作人员录入学生基本信息、给出初步意见录入档案、审核学籍变动申请教务管理人员档案维护、学籍变动审核、成绩审核修改注册登记、修改成绩学生处管理人员审核奖惩、审批勤工助学审核奖学金、审批岗位招生就业工作人员就业信息录入、统计分析就业情况登记、生成分析报表系统管理员权限管理、数据维护添加用户、备份恢复数据库从这张表能看出来不同角色的差别主要体现在“能操作哪些数据”和“操作权限到什么级别”上。比如同样是成绩相关操作系秘书能录入和打印教师只能查询和打印教务管理人员才有修改权。这个权限边界的划分在后面的用例图里会直接影响用例与角色的连接关系在数据库设计里会直接影响用户登录表的权限字段设计。2.3 用例粒度从十大高层用例到子用例系统的高层用例可以抽象成十类录入信息、修改信息、查询信息、分析统计、打印信息、申请项目、审核项目、审批项目、管理权限、维护系统。这十个用例基本覆盖了系统的全部功能需求是建立顶层用例图的基础。但顶层用例太粗糙比如“查询信息”到底包含哪些查询按学号查、按班级查、按系查、按课程查这些都需要进一步细化。细化的常见做法是自顶向下四步走先选定一个用例然后做场景分析把主场景和异常场景都列出来接着做用例分解把场景中的每步看成一个小的子用例最后做用例判定判断子用例能不能归为参与者的一次简单行为。能归入就作为精细化用例保留不能归入就继续往下拆。以学籍管理子用例为例可以从“学籍管理”这个抽象用例拆出三组注册报到管理登记、统计、查询、打印、基本档案管理录入、修改、查询、打印、学籍变动管理申请、审核、审批、登记、查询、打印。其中“学籍变动”是典型的流程型用例学生提出申请、系学生工作人员审核、教务管理人员审批一环扣一环。这样拆完之后每个子用例都有明确的参与者粒度也到了可以指导类图设计的程度。2.4 include 与 extend 别用反成绩管理子用例图里有一个很容易被忽略的关系标记《include》和《extend》的使用。录入成绩这个用例执行前必须走身份验证身份验证是每次录入都要执行的公共片段这里用《include》连接。学籍变动管理里当变动原因是违纪处分时需要额外触发的处分登记流程属于满足特定条件才走的扩展路径这里用《extend》连接。判断口诀很简单必选、每次都要执行的公共步骤用 include可选、满足条件才触发的扩展流程用 extend。很多新手把这两个标反结果评审的时候被一问就露馅。另外注意用例图里的箭头方向也有约定include 是从基础用例指向被包含的公共用例extend 是从扩展用例指向被扩展的基础用例画反了语义就完全变了。3. 静态结构建模从用例图细化到类图推导的完整路径3.1 输入输出推导法识别类用例图画完下一步是识别类。这里有一个实用的推导思路如果一个输入可以作为关联角色的属性存在那它就不必转成类如果一个输出能找到对应的责任实体来包容它也不必转成类。反过来既不能归入角色属性、又没有现成实体能包容的数据就要识别为新的类。面向对象方法里把类分成三种实体类、边界类、控制类。实体类负责描述必须存储的信息通常是持久化的边界类对应窗口、接口这些外部交互界面控制类负责协调业务逻辑调度实体类和边界类之间的操作。学生信息管理系统里成绩、学生、课程这类有存储需求的概念就是实体类登录窗口就是边界类成绩录入背后的业务逻辑调度就是控制类的活。3.2 实体类的属性定义成绩管理子系统的实体类设计可以直接参考原报告的属性定义这些字段基本都是查询统计时的硬需求少了任何一个后续都会难受。实体类属性学生学号、姓名、性别、班级、系别、专业教职工职工号、姓名、性别、出生年月、职务、部门课程课程号、课程名、课程性质、学分成绩学号、课程号、学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩用户登录用户名、密码、权限、终止日期注意成绩实体类的属性设计它把学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩都列全了。这意味着一个学生可以对应多条成绩记录每学期每门课一条补考和重修单独记录。这个设计直接决定了后面成绩表的主键不能只拿学号得用学号加课程号加学期代码做复合主键这一点在数据库章节还会再讲。3.3 类图继承教职工父类与三个岗位子类类图里最有代表性的部分是教职工类的继承结构。父类是教职工属性包括职工号、姓名、性别、出生年月、职务、所属部门操作包括登录、查询成绩、打印成绩、退出系统。三个子类分别是教师、系秘书、教务人员。教师在父类基础上增加了成绩统计分析操作系秘书增加了录入成绩操作教务人员增加了修改成绩操作。也就是说三个子类复用了父类的公共属性和大部分操作只在各自职责范围内做扩展。这个设计是典型的重构思路先把公共能力上提到父类子类只写差异避免三个类里重复堆相同的属性和方法。顺带把类图的箭头语义说清楚类图里箭头含义是固定的空心三角实线箭头指向父类是继承空心三角虚线箭头指向接口是实现普通实线箭头是关联虚线箭头是依赖。画类图的时候把这些箭头用对从观感上就比一堆没有关系的矩形框专业一个档次。3.4 类图交付检查清单类图画完我一般会按五个问题过一遍每个用例是否至少由一个角色激活每个实体类是否至少被一个边界类访问父类的公共属性和操作是否被所有子类复用无关类之间有没有多余的关联线新增的实体属性是否已经同步到后续数据库设计里。这套检查能挡住大部分静态模型的低级问题。4. 动态行为建模顺序图、状态图、活动图的选择与画法4.1 顺序图录入成绩的十条消息UML 中的动态结构图包括顺序图、协作图、状态图、活动图。顺序图强调交互的时间顺序适合描述一个完整操作从发起到落库的消息流转。成绩录入场景的顺序图是报告里最完整的一张动态图参与对象有四个系秘书、登录窗口、成绩录入窗口、成绩信息数据库。消息序列按时间从上到下排登录、身份验证、验证通过、进入成绩管理窗口、录入、修改、删除、提交、写入数据库、退出。这里每一组箭头都是一次方法调用前四条是认证与导航中间三条是数据操作后面两条是提交与落库最后退出。画顺序图的时候每个对象下面要有垂直虚线表示生命线方法执行期间生命线上叠加矩形激活条同步调用用实心箭头。把控好这几点顺序图就不会画成流程图。4.2 状态图查询与登录的状态转移状态图用来描述一个特定对象在自己生命周期里的状态变化以及触发变化的事件。状态图不是所有对象都要画只画那些状态多、且行为受外部事件影响的对象。报告里给了两个典型的子状态图。查询子状态图请求查询状态输入合理查询条件后进入进行查询状态查找完进入返回查询结果状态此时可以再次查询回到请求状态也可以退出如果输入不合理的查询条件直接回到请求状态。这个循环逻辑用状态图表达比文字描述清晰得多。用户登录子状态图系统先处于等待用户输入账号密码状态数据传送后进入检测用户信息状态。输入合法就进入对应权限的用户界面输入不合法进入检查输入次数状态未超过允许次数就回到等待输入状态重试超过次数则结束登录。这里要特别提醒一句状态图上的守卫条件数字必须和需求文档保持一致图里写 5 次、文档里写 3 次这种前后矛盾是评审时的重灾区后面避坑章节会展开说。4.3 活动图查询成绩的工作流活动图本质上就是一种流程图描述从活动到活动的控制流。它和状态图的区别在于活动图适合表达跨越多个对象的业务流程状态图聚焦单个对象的状态变迁。所以像“学生查询成绩”这种完整流程用活动图更合适。活动图建模可以按七步走识别工作流目标用开始状态和终止状态描述前置和后置状态识别实现目标所需的所有活动并按逻辑顺序放置定义活动创建或修改的对象用对象流连接用变迁把所有元素连起来在需要分支的地方画可选流如果有并行工作流用同步条表示分岔和汇合。查询成绩的活动流程是学生进入系统输入用户名和密码系统检查信息错误就要求重新输入正确就进入选择查询类型环节输入关键词系统查询并显示成绩单然后询问是否继续查询不查询就退出继续查询就回到选择查询类型。这个流程里的“检查信息正确与否”就是分支点“是否继续查询”是又一个分支点两个分支点把整个流程切成三段逻辑很清楚。4.4 三张动态图怎么选画动态图之前先想清楚自己要表达什么。强调消息先后顺序选顺序图强调单对象的状态变化与事件触发选状态图强调跨对象的业务流程分支与并发选活动图。如果重点是多个对象之间的组织结构协作关系那就用协作图但在这种管理信息系统场景里顺序图的使用频率远高于协作图。动态图表达重点本系统典型场景顺序图消息的时间顺序系秘书录入成绩状态图单对象状态与事件查询循环、登录重试活动图流程分支与并行学生查询成绩完整流程5. 数据库设计中的常见问题与关键表单E-R 模型落表的三处硬伤5.1 数据库设计三段式流程数据库设计不是直接建表而是走三段先根据用户需求确定要保存哪些数据这是概念建模的基础再设计数据的概念模型也就是 E-R 模型用实体和联系表达现实世界最后做逻辑结构设计把概念模型转换成数据库管理系统支持的二维表结构。这个顺序和 UML 建模的顺序是呼应的实体类识别出来的信息需求到这一步变成具体的表和字段。5.2 E-R 模型的实体与联系报告里的 E-R 模型覆盖了系统的主要实体和联系。核心实体是学生、成绩、课程、奖惩、勤工助学、贷款、就业、基本档案实体之间的联系方式决定了关系表怎么建。联系类型说明学生与成绩1:N一个学生有多条成绩记录课程与成绩1:N一门课程对应多条成绩记录学生与奖惩1:N一个学生多条奖惩记录学生与勤工助学M:N一个学生可申请多个岗位一个岗位可由多个学生承担学生与就业1:1一个学生一条就业去向学生与贷款1:N一个学生可多次贷款教务人员与学籍变动1:N一个教务人员审批多条变动记录这里最容易出错的是 M:N 联系。学生与勤工助学是 M:N落表时不能直接靠加外键解决需要拆出一张关联表把岗位和学生的关系以及申请时间、审批状态这些属性挂在关联表上。如果直接在学生表里加一个岗位字段一个学生申请两个岗位时就只能覆盖写数据直接丢。5.3 关键表单的字段定义系统里最核心的几张表是学生基本信息表、成绩表、课程表、用户登录表。学生基本信息表的结构直接复用实体类的属性定义字段名数据类型键值说明学号varchar(20)主键学生唯一标识姓名varchar(20)非空学生姓名性别char(2)男/女班级varchar(30)行政班级系别varchar(30)所属系部专业varchar(30)所学专业成绩表是另一个关键表字段包括学号、课程号、学期代码、任课教师、平时成绩、期末成绩、总评成绩、补考成绩、重修成绩。主键必须用复合主键学号、课程号、学期代码否则一个学生同一门课只能存一条记录补考和重修数据就没地方放。课程表相对简单字段为课程号、课程名、课程性质、学分课程号作为主键。用户登录表则是用户名、密码、权限、终止日期用户名主键权限字段正好对应前面八类角色的划分。5.4 三个常见问题与纠正方法问题一用例图画成了功能树。现象是整个用例图就是“添加学生、删除学生、修改学生、查询学生”这种按钮级别的功能清单评审时被指出这不是用例而是操作步骤。原因是画图时没有从角色目标出发而是照着界面功能罗列。解决方法是套用例的三特征判断是否由角色激活、是否为角色提供可识别的值、是否具有完全性。以“修改成绩”为例正确写法是教务管理人员登录后在成绩管理界面选择记录、修改、提交、写入数据库整个流程走完才算完成一个用例而不是把“修改”两个字单独拎出来。问题二实体类属性直接当表字段漏了复合主键。现象是成绩表用学号当主键导致同一门课补考和重修的成绩存不进去。原因是跳过了 E-R 模型直接落表学生与成绩的 1:N 联系没有转成外键和复合主键。解决方法是先画 E-R 图把每个 1:N 联系的“1”方主键落到“N”方做外键成绩表用学号加课程号加学期代码做复合主键。这个坑几乎每个做课程设计的人都会踩一次数据库设计那一步偷懒后面写 SQL 的时候全得还回来。问题三状态图守卫条件与需求文档数字不一致。现象是登录状态图里画着“少于 5 次可继续输入、超过 5 次结束”需求文档里写的是最多尝试 3 次图与文档打架。原因是状态图画完没有回查需求文档。解决方法是状态图上每个守卫条件都要和需求文档做一次核对以验收文档为准图只是文档的图形化表达。6. 把 UML 模型转成可演示原型三件套落地与评审讲法这套模型的终点不是图而是能跑起来的原型。我通常会把三张图转成三件事类图转建表语句顺序图转接口调用链活动图转页面跳转逻辑。类图转表最直接每个实体类就是一张表属性转字段继承关系处理成公共字段放父表或子表冗余实体类里定义的属性几乎可以原样搬过去。顺序图转接口调用链把每条消息当成一次方法调用比如录入成绩的顺序图里录入、修改、删除、提交、写入数据库这五条消息落到代码就是成绩服务里的 saveOrUpdate、delete、submit、writeDB 四个方法顺序图的消息顺序就是接口的调用顺序。活动图转页面跳转每一个活动状态对应一个页面或一个操作分支判断落到前端或后端控制层。评审讲法也有技巧。每张图只讲一句话用例图说“系统给谁用、有哪些功能”类图说“系统里的数据长什么样”顺序图说“一次操作的消息怎么走”活动图说“流程在哪分叉”数据库表说“数据存到哪”。讲的时候按这条主线走评委基本不会被带偏。这套顺序我吃了不少亏才固定下来。以前我拿到业务系统就急着画用例图画到一半发现类图没法推又回头补需求分析图改了三轮数据库表还是漏了复合主键。从那以后我每次接 UML 建模的活都强制自己先花二十分钟写一页纸的业务流程说明把角色和动作圈出来再决定第一张图画什么。先流程后图先静态后动态最后落表这套顺序能少翻好几次车希望帮到你。本文还有配套的精品资源点击获取