UML建模学成在线管理系统

《软件建模技术》实验报告
题 目： 学成在线管理系统
学 期： 2021-2022第二学期
班 级： 21级软工专升本3班
姓 名： 张婷
学 号： 202105930306
组 员： 吴玉萍 郭晶晶
教 师： 刘凤华

2022年5月
目录
第一章 项目分析 1
1.1 项目背景 1
1.2 项目现状 1
1.3 项目目标 1
1.4 社会可行性 2
1.5 技术可行性 2
1.6 操作可行性 2
1.7 经济可行性 2
第二章 需求分析-用例模型 3
2.1 需求分析 3
2.2 功能需求分析 3
2.2.1 用户功能 3
2.2.2 教师功能 3
2.2.3 管理员功能 4
2.3 用例规约 4
2.3.1 注册账户 5
2.3.2 登录系统 5
2.3.3 修改登录密码 5
2.3.4 找回密码 6
2.3.5 查看个人信息 6
2.3.6 修改个人信息 7
2.3.7 选购课程 7
2.3.8 购置课程后进行评价 8
2.3.9 上架课程 8
2.3.10 管理评价 9
2.3.11 管理账户 9
2.3.12 审批申请教师请求 10
2.3.13 发布网站公告 10
2.4 用例图 11
2.4.1 用户用例图 11
2.4.2 教师用例图 11
2.4.3 管理员用例图 12
第三章 系统分析-逻辑模型 12
3.1状态图 12
3.1.1账号的状态图 12
3.1.2发布网站公告的状态图 13
3.1.3购置课程的状态图 13
3.1.4审批申请教师请求的状态图 14
3.2活动图 15
3.2.1系统主页务活动图 15
3.2.2注册的活动图 16
3.2.3登录的活动图 17
3.2.4修改密码的活动图 18
3.2.5找回密码的活动图 19
3.2.6查看个人信息的活动图 20
3.2.7修改个人信息的活动图 21
3.2.8选购课程的活动图 22
3.2.9购置课程评价的活动图 23
3.2.10审批申请教师请求的活动图 24
第四章 类图和包 24
4.1类的定义 24
4.2架构分析 25
4.3识别分析类 26
4.4构造分析类图 27
4.5顺序图 28
4.5.1注册用户顺序图 28
4.5.2. 登录顺序图 30
4.5.3修改个人信息 31
4.5.4修改密码顺序图 32
4.5.5教师发布课程顺序图 33
4.5.6评价课程顺序图 34
4.6协作图 34
4.6.1注册用户协作图 35
4.6.2登录账户协作图 35
4.6.3修改密码协作图 36
4.6.4修改个人信息协作图 36

第一章 项目分析
1.1 项目背景
受互联网+概念的催化，当今中国在线教育市场的发展可谓是百花齐放、如火如荼。 按照市场领域细分为：学前教育、K12教育、高等教育、留学教育、职业教育、语言教育、兴趣教育以及综合平台，其中，职业教育和语言教育的市场优势突出。根据Analysys易观发布的数据显示，预计2022年中国互联网教育市场交易规模将达到3718亿元人民币，未来三年互联网教育市场规模保持高速增长。学成在线借鉴了MOOC（大型开放式网络课程，即MOOC（massive open online courses））的设计思想，是一个提供IT职业课程在线学习的平台，它为即将和已经加入IT领域的技术人才提供在线学习服务，用户通过在线学习、在线练习、在线考试等学习内容，最终掌握所学的IT技能，并能在工作中熟练应用。
1.2 项目现状
互联网正在以摩尔指数式发展，在线教育就是其催生产物之一。在线教育,即以网络为介质的教学方式，通过网络开展远程教学活动。随着互联网的渗透进人们的生活与工作当中,同时也推动了我们学习方式和教育方式的改革和进步。在线教育由此应运而生，并逐渐收到人们的认可与追捧。
在线教育的发展打破了高校物理空间的围墙，为高校国际化发展开辟了全新网络空间。通过在线教育的平台，在主观能动性的驱使下，可以选择适合自己的学习节奏，这意味着可以随时随地学习，这大大提升了学习的效率。而且在线教育可以省一大笔生活开销。在很多国家，通过学习各名校提供的在线学位课程所得到的学位证都是和线下传统教育所获得的都是完全一样的。
随着全球一体化的发展，中国也加快脚步进入了在线教育的领域，中方与世界性的名校产生连接，中国在线教育行业也会产生一定的影响。
1.3 项目目标
随着未来人才结构的变化，在线教育的服务对象也不再是传统意义上的学习者，在线教育的目标便成为需要进一步研究的问题。
在线教育软件开发支持多种形式：比如图文，音频，ppt等，也可以自主上传视频，通过课程目标定位人群，向目标人群进行推送。免费试看，可以为学生提供专业的视频点播体验，而不是仅仅的上课而已。这也是在线教育软件开发的重点。支持电脑，软件，手机端等的使用，充分利用碎片化时间。在线教育系统APP软件开发能够帮助我们的用户，在需要查看信息的时候直接能够帮助我们的用户查看相关的信息，让我们的用户能够最快速地查询到自己想要的信息，这就是在线教育系统APP软件开发的目的。其实在线教育软件开发不仅仅能够帮助我们的用户查找资料，还可以帮助我们的用户分享自己的教育资源，当用户的权限为老师时就可以将自己的教育资源分享到我们在线教育系统软件上，让我们每一个用户都能够更快地使用到用户分享的资源，这就是在线教育系统APP软件开发的一个核心。
1.4 社会可行性
随着计算机技术和互联网的发展，网民数量的不断上升，以及终生教育观念的深入人心，在线教育已经成为网上的一股新风气并普遍为人们所接受。与此同时，在线教育可以使用户充分的利用闲暇时间学习,我们可以相信在不久的将来，用户就可以在线上体验到和线下同等甚至更为优越的教育资源《学成在线的实现》主要目的是进行在线学习，进行知识的传播，并且严格按照国家法律法规来进行研究和实践，并无法律和政策方面的限制，是促进人类精神文明积极发展的健康网站。
1.5 技术可行性
本系统采用的是JSP、MySQL和SSH即Spring boot框架的整合开发，结合Windows 10操作系统，用VUE编辑器进行前台网页界面设计，客户端不直接与数据库交互，而是通过组件与中间层建立连接，再由中间层与数据库打交道，完成数据的添加、修改、删除、查询等功能。由于Spring boot是JAVAEE应用开发的主流体系，具有高度的可拓展性和可维护性，而MySQL灵活易维护在开发方面具有方便快捷、使用灵活的特点，因此使用JSP、SSH、MySQL是开发轻平台的最佳组合从而说明本系统在技术方面可行硬件方面，在这个科学技术迅猛发展的时代，硬件在更新过程中呈现出速度快，容量大，可靠性高等特点，价格相.对以前来说较为低廉，其硬件平台完全能满足此系统的需要。
1.6 操作可行性
目前，大多数计算机都能运行该系统，并且该系统界面简单，提示信息完整。该系统的主要使用者是学习者和教学者，伴随着计算机的普及，大多数人都已无形中具备了使用计算机的能力。用户在操作上是不存在障碍的，所以是可行的。
1.7 经济可行性
经济可行性主要是指我利用已有资源实现该系统的可能性并且该系统的经济效益是否可以超过其开发成本。本系统开发主要用的是Vue和IDEA，数据库使用Mysql，电脑等工具，这些并不会超出我们已有的资源，所以是行的通的。

第二章 需求分析-用例模型
2.1 需求分析
前后端完全分离，前端基于Vue框架，后端使用Spring boot框架，前端展示课程，允许用户购买，为用户、教师、管理员分别设计3个平台。
1).用户角色功能：
注册、登录、购买课程、支付宝和微信接入
在线视频播放、评价、提问题
2).教师角色功能：
对用户进行跟进、回复学员问题
3).管理员角色功能：
查看用户注册趋势图、订单量报表
增删改查课程
为学员分配教师
创建、管理资讯文章
追踪学员学习进度
教师跟进管理
订单管理
为主要的功能开发单元测试
2.2 功能需求分析
2.2.1 用户功能
1）注册功能
2）登录功能
3）修改个人密码功能
4）查看个人信息功能
5）修改个人信息功能
6）找回个人密码
7）选购课程
8）付款功能
9）购置课程后的评价功能

2.2.2 教师功能
1）注册功能
2）登录功能
3）查看个人信息功能
4）修改个人信息功能
5）找回密码
6）发布课程功能
2.2.3 管理员功能
1）登录功能
2）查看个人信息功能
3）修改个人信息功能
4）找回个人密码
5）管理账户功能
6）管理课程评价功能
7）对教师的课程进行审批功能
8）发布系统公告功能
2.3 用例规约
S-用户（Student）
T-教师（Teacher）
A-管理员（Administrator）
编号 用例编号 用例名称 参与者
1 US-01 注册账户 S T
2 US-02 登录账户 S T A
3 US-03 修改登录密码 S T A
4 US-04 找回密码 S T A
5 US-05 查看个人信息 S T A
6 US-06 修改个人信息 S T A
7 US-07 选购课程 S
8 US-08 购置课程后进行评价 S
9 US-09 上架课程 T
10 US-10 管理评价 A
11 US-11 管理账户 A
12 US-12 审批申请教师请求 A
13 US-13 发布网站公告 S A
2.3.1 注册账户
用户，教师通告本用例进行注册账户，经管理员审批通过后，可以登录使用系统。用例规约如表2-1所示。
用例编号 US-01
用例名称 注册账户
用例描述 用户，教师在注册界面注册属于自己的账户，从而使用系统
参与者 用户，教师
前置条件 无
后置条件 用户，教师注册成功，跳转到登录界面
基本路径 1.参与者启动系统
2.参与者选择注册账户
3.参与者输入个人或详细信息
4.系统检测信息完整性及用户身份合法性
5.系统注册成功，返回到登录界面
扩展点 注册时加手机号安全验证
表2-1 用户注册系统用例规约
2.3.2 登录系统
用户，教师使用本用例登录系统，然后改变自己的状态，要求输入合法的用户名和密码。用例规约如表2-2所示。
用例编号 US-02
用例名称 登录系统
用例描述 输入自己的账号和密码，登录系统
参与者 用户，教师，管理员
前置条件 用户，教师成功注册账户
后置条件 用户，教师登录成功，跳转到首页
基本路径 1.参与者启动系统
2.系统显示用户端子系统登录界面
3.参与者输入用户名和密码
4.用户输入提交的信息
5.系统记录并显示当前登录用户
6.系统检测信息完整性及用户身份合法性
7.系统登录信息，隐藏登录界面
扩展点 登陆时需要邮箱验证
表2-2 登录系统用例规约
2.3.3 修改登录密码
用户，教师，管理员使用本用例进行修改密码，并向系统发送修改密码申请，在用户，教师，管理员信息中修改新的登录密码，要求输入合法的旧密码和新密码。用例规约如下表2-3所示。
用例编号 US-03
用例名称 修改登录密码
用例描述 系统验证用户身份合法后进入修改密码界面
参与者 用户，教师，管理员
前置条件 已经成功登录系统
后置条件 修改密码成功，重返回登录界面
基本路径 1.参与者提出修改密码请求
2.系统进入修改密码界面
3.参与者输入旧密码，并输入两次新密码
4.系统验证用户身份以及新密码的合法性
5.系统验证新密码的合法性
6.参与者登录密码修改成功，返回登录界面
扩展点 安全验证
表2-3修改登录密码用例规约
2.3.4 找回密码
用户，教师，管理员使用本用例进行找回密码，并向系统发送找回密码申请，找回密码用例规约如下表2-4所示。
用例编号 US-04
用例名称 找回密码
用例描述 系统验证身份合法后设置新密码界面
参与者 用户，教师，管理员
前置条件 有账号
后置条件 密码重新设置成功，重返回登录界面
基本路径 1.参与者填写用户名
2.验证身份
3.参与者设置新密码
4.参与者成功找回密码，返回登录界面
扩展点 安全验证
表2-4找回密码用例规约

2.3.5 查看个人信息
用户，教师，管理员通过本用例查看个人信息。用例规约如下表2-5所示。
用例编号 US-05
用例名称 查看个人信息
用例描述 用户，教师，管理员登录系统后可以查看个人信息
参与者 用户，教师，管理员
前置条件 已经成功登录系统
后置条件 显示个人信息
基本路径 1.参与者提出查看个人信息的请求
2.系统显示个人信息界面
3.参与者退出个人信息界面
扩展点 无
表2-5查看个人信息用例规约
2.3.6 修改个人信息
用户通过本用例进行个人信息的修改，并向系统发送修改个人信息的请求，在用户信息中修改新的个人信息。用例规约如表2-6所示。
用例编号 US-06
用例名称 修改个人信息
用例描述 登录系统后可以修改个人信息
参与者 用户，教师，管理员
前置条件 已经成功登录系统
后置条件 显示修改后新的个人信息
基本路径 1.参与者提出修改个人信息的请求
2.系统显示修改个人信息界面
3.参与者提交修改内容
4.系统验证修改内容的合法性
5.系统完成修改
6.显示修改后的个人信息
扩展点 提示修改内容不合法，重新输入修改内容
表2-6用户修改个人信息用例规约
2.3.7 选购课程
用户通过本用例进行选购课程，并将选购的课程请求发送给系统，系统将所选购的课程添加到购物车中。用例规约如表2-7所示。
用例编号 US-07
用例名称 选购课程
用例描述 用户登录系统后可以选购课程并将其加入购物车中
参与者 用户
前置条件 用户已经成功登录系统
后置条件 用户对购物车内的课程进行付款或删除
基本路径 1.用户在输入框内查找课件名称
2.系统根据输入内容进行检索
3.系统显示除符合条件的课件的内容
4.用户对该课程进行浏览或下载
5.将所选购的课程添置于购物车中进行付款
扩展点 1.系统没有找到任何符合条件的课件
2.显示查询不到符合条件的课件的提示
表2-7选购课程用例规约
2.3.8 购置课程后进行评价
用户使用本用例对购置课程后进行评价，要求用户已购买课程。用例规约如表2-8所示。
用例编号 US-8
用例名称 购置课程后进行评价
用例描述 用户对已购买的课程进行评价
参与者 用户
前置条件 用户已购买商品
后置条件 无
基本路径 1.用户提出打开评价界面申请
2.系统显示评价界面
3.用户提出评价申请
4.系统验证评价合法性
5.系统发表评论
扩展点 学员评价内容不合法
学员评价内含有敏感词汇 ，返回评价界面
表2-8购置课程后进行评价用例规约
2.3.9 上架课程
学员使用本用例上架课程，要求课程符合标准。用例规约如表2-9所示。
用例编号 US-9
用例名称 上架课程
用例描述 教师上架学员需要的课程
参与者 教师
前置条件 教师已经成功登陆系统
后置条件 显示已上架的课程
基本路径 1.教师启动系统
2.系统显示用户端子系统登录界面
3.教师输入用户名
4.教师输入密码
5教师提示登录申请
6.系统检测信息完整性及用户身份合法性
7.系统登录信息，隐藏登录界面
8.教师提出上架课程
9.系统验证课程的合法性
10.系统上架课程
扩展点 系统显示课程不合法，返回上架页面，提示修改课程内容
表2-9上架课程用例规约
2.3.10 管理评价
管理评价教师使用本用例管理评价，要求教师按照评价条例管理评价。用例规约如表2-10所示。
用例编号 US-10
用例名称 管理评价
用例描述 教师管理学员对的评价
参与者 教师，用户
前置条件 教师已经成功登陆系统
后置条件 回复评价或移除评价
基本路径 1.教师启动系统
2.系统显示用户端子系统登录界面
3.教师输入用户名
4.教师输入密码
5教师提示登录申请
6.系统检测信息完整性及用户身份合法性
7.系统登录信息，隐藏登录界面
8.教师提出打开评价界面申请
9.系统显示评价界面
10.教师提出修改评价申请
11.系统验证评价合法性
12.系统发表评论
扩展点 学员评价内含有敏感词汇 ，返回评价界面
表2-10管理评价用例规约
2.3.11 管理账户
管理员使用本例进行管理账户，可以对账户信息进行操作。用例规约如表2-11所示。
用例编号 US-11
用例名称 管理账户
用例描述 管理员在账户管理界面管理所有账户信息
参与者 管理员
前置条件 管理员已成功登录系统
后置条件 无
基本路径 1.参与者启动系统
2.参与者选择账户界面
3.参与者调整个人信息
4.系统检测账户信息更改是否合理
5．系统改变成功，返回账户界面
扩展点 系统显示用户信息不合理，返回原界面
表2-11管理账户用例规约
2.3.12 审批申请教师请求
管理员使用本用例审批申请教师请求。用例规约如表2-12所示。
用例编号 US-12
用例名称 审批申请教师请求
用例描述 管理员对用户所提交的申请教师请求做出审批
参与者 管理员
前置条件 管理员已成功登录系统
后置条件 系统通过审批用户收到信息
基本路径 1.用户提交申请教师请求
2.系统收到用户教师审批信息
3.管理员根据相应标准对请求进行批复
4.系统根据相应标准检验用户是否能够成为教师
5．用户收到通知信息
扩展点 用户由于某些原因未能符合标准
用户身份认证程度过低
表2-12审批申请教师请求用例规约
2.3.13 发布网站公告
管理员使用本用例发布网站公告，管理员在主界面发布网站的公告。用例规约如表2-13所示。
用例编号 US-13
用例名称 发布网站公告
用例描述 管理员在主界面发布网站的公告
参与者 教师，管理员
前置条件 管理员已经成功登录系统
后置条件 系统主页面显示公告
基本路径 1.教师提交活动公告申请
2.系统检测信息的价值性与合法性
3.管理员对申请进行审批
4.系统在主页面发布公告
扩展点 公告申请中含有敏感信息，提示重新输入公告申请
公告申请中含有虚假信息，返回界面
表2-13发布网站公告用例规约
2.4 用例图
2.4.1 用户用例图

图2-14用户用例图

2.4.2 教师用例图

图2-15教师用例图

2.4.3 管理员用例图

图2-16管理员用例图

第三章 系统分析-逻辑模型
3.1状态图
3.1.1账号的状态图

图3-1 账号的状态图

3.1.2发布网站公告的状态图

图3-2发布网站公告的状态图

3.1.3购置课程的状态图

图3-3购置课程的状态图

3.1.4审批申请教师请求的状态图

图3-4审批申请教师请求的状态图

3.2活动图
3.2.1系统主页务活动图

图3-5 系统主业务活动图
3.2.2注册的活动图

图3-6 注册活动图

3.2.3登录的活动图

图3-7 登录活动图

3.2.4修改密码的活动图

图3-8 修改密码活动图
3.2.5找回密码的活动图

图3-9找回密码活动图

3.2.6查看个人信息的活动图

图3-10查看个人信息活动图

3.2.7修改个人信息的活动图

图3-11修改个人信息活动图

3.2.8选购课程的活动图

图3-12选购课程活动图

3.2.9购置课程评价的活动图

图3-13购置课程评价活动图

3.2.10审批申请教师请求的活动图

图3-14审批申请教师请求活动图

第四章 类图和包
4.1类的定义
类之间的关系是类图中比较复杂的内容。有关联、聚合、组合、泛化、依赖。
关联：是模型元素之间的一种语义联系，是类之间的一种很弱的联系。关联可以有方向，可以是单向关联，也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个对象参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束，以加强关联的含义。如下图4-1所示：

图4-1关联图

聚合是一种特殊的关联，聚合表示整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如舰队是由一系列的舰船组成。需求描述中“包含”、“组成”、“分为….部分”等词常意味着聚合关系。
组合也是一种特殊的关联，也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。
聚合和组合的区别：聚合关系是“has－a”关系，组合关系是“contains－a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。
有两个元素如果修改X的定义可能会导致对Y的定义，则认为Y依赖X。依赖关系可能由各种原因引起，如一个类向另一个类发送消息，或者一个类是另一个类的数据成员类型，或者一个类是另一个类的操作的参数类型等。有时依赖关系和关联关系比较难区分。如果类A和类B有关联关系，它们之间必然有依赖关系。如果两个类之间有关联关系时不用再表示出这两个类之间的依赖关系。

4.2架构分析
架构（Architecture）在面向对象的系统中扮演着越来越重要的角色，从某种意义上来说，面向对象的分析和设计都是以架构为中心进行的。在分析和设计的不同阶段，软件系统的架构被一步步细化和完善，最终形成一个规范的、稳定的、符合设计要求的架构模型。架构分析的过程就是定义系统高层组织结构和核心架构机制的过程。在早期迭代中，架构分析的主要目标是建立系统的备选架构，以用于组织后续的用例分析所获得的分析模型，该备选架构通过架构设计进行细化和调整，从而获得软件系统的基础架构。
本案例的早期架构选型时，采用流行的分层结构，其架构如图4-2所示。

图4-2架构图

在U-B-D三层架构的定义过程中，采用包图进行架构建模。包是一种通用的模型分组机制，为了有效地表示分层的概念需要引入构造型，并在层和层之间建立了依赖关系。通过U-B-D这三层划分系统三类处理逻辑，其中:
 表示层：主要对用户的请求接受，以及数据的返回，为客户端提供应用程序的访问。
 业务逻辑层：主要负责对数据层的操作。也就是说把一些数据层的操作进行组合。
 数据访问层：主要看数据层里面有没有包含逻辑处理，实际上它的各个函数主要完成各个对数据文件的操作。而不必管其他操作。
目前只是给出了这三个层次的基本定义，而各层的内部还没有任何元素，后续过程将对架构中的各个层次进行填充。

4.3识别分析类
在对象系统中，系统的所有功能都是通过相应的类来实现的;因此首先需要从用例文档中找出这些可用的类，之后再将其所描述的系统行为分配到这些类中。面向对象的分析是对这个过程的第一次尝试，这是一个从“无”到“有”的跨越，也是整个分析过程中最难的一部分任务之一。而分析阶段所定义的类称之为分析类。
分析类代表了系统中具备职责和行为的事物的早期概念模型，这些概念模型最终会演化为设计模型中的类或子系统。分析类关注系统的核心功能需求，用来建模问题域对象。此外，分析类主要用来表现“系统应该提供那些对象来满足需求”，而不关注具体的软硬件实现的细节。
架构分析中所定义的U-B-D三层备选架构为识别分析类提供了很好的思路，按照该备选架构，系统中的类相应地对应三个层次，即表示层、业务逻辑层和数据访问层。识别分析类的过程就是从用例文档中来定义这三个层次分析类的过程。
学成在线系统中分析类较多，根据备选架构识别了三种分析类
一．边界类

1. 申请界面类
2. 首页界面类
3. 课程界面类
4. 个人中心类
5. 订单接口支付类
6. 购物车界面类
   二． 控制类
7. 申请界面控制类
8. 首页界面控制类
9. 课程界面控制类
10. 个人中心控制类
11. 订单接口支付控制类
12. 购物车界面控制类

三．实体类

1. 管理员
2. 教师
3. 学生
4. 课程
5. 支付
6. 课程评价
7. 网站公告

本系统目前初步定义了7个实体类，该类记录了系统的用户信息，如用户名、密码等。关键抽象的提取更多的是凭借着对业务的理解和相关项目的经验;而此阶段对实体类的提取还可以按照前面所提到的名词筛选法来进一步明确并获得更多的实体类。
4.4构造分析类图
通过构造用例实现验证了需求的可实现性:即可以利用识别出的分析类和它们之间的交互来达到用例的目标；这是整个分析过程最核心的工作。然而，对于面向对象的系统来说，所描述的这些交互最终都应在相应的类中来定义并由类的对象来实现。虽然在构造用例实现的过程中已经获得了类的基本定义，但那是在一个个用例实现的基础上完成的，主要关注的是用例事件流的交互过程，而对单个类自身的特征和行为缺少统一的考虑。因此，下一阶段就需要将注意力集中到每一个分析类本身，在关注类自身定义的基础上再重新评估每个用例实现的需要。此外，一个类及其对象常常参与多个用例实现，此时更需要从类整体角度去协调用例的行为。
构造分析类图的最终目标就是从系统的角度明确说明分析类的职责和属性以及类之间的关系;并根据这些视图来描述和理解目标系统，从而为后续的设计提供基本的素材。下图展示了“学成在线系统”实体类类图该图中涉及到类、类的职责、属性和关系如图4-3所示：

图4-3类图

4.5顺序图
顺序图强调的消息时间顺序的交互图，描述类系统中类与类之间的交互，它将这些交互建模成消息互换，顺序图描述了类与类之间相互交换以完成期望行为的消息。顺序图的特点是清晰，一个设计很好地顺序图从左到右、从上到下可以很好地表示出系统数据的流向，以帮助我们对照检查每个用例中描述的用户需求，是否能够实现。
4.5.1注册用户顺序图

图4-4注册用户顺序图

4.5.2 登录顺序图

图4-5登录用户顺序图
4.5.3修改个人信息

图4-6修改个人信息顺序图
4.5.4修改密码顺序图

图4-7修改密码顺序图

4.5.5教师发布课程顺序图

图4-8教师发布课程顺序图
4.5.6评价课程顺序图

图4-9评价课程顺序图

4.6协作图
协作图 含一组对象和以消息交互为联系的关联，用于描述系统的行为是如何由系统的成分合作实现的。在协作图中，类元角色描述了一个对象，关联角色描述了协作关系中的链，并通过几何排列表现交互作用中的各个角色。协作图是表现对象协作关系的图，它表示了协作中作为各种类元角色的对象所处的位置，在图中主要显示了类元角色和关联角色。类元角色和关联角色描述了对象的配置和当一个协作的实例执行时可能出现的连接。当协作被实例化时，对象受限于类元角色，连接受限于关联角色。
4.6.1注册用户协作图

图4-10注册用户协作图

4.6.2登录账户协作图

图4-11登录账户协作图

4.6.3修改密码协作图

图4-12修改密码协作图

4.6.4修改个人信息协作图

图4-13修改个人信息协作图

4.7件图

图4-14组件图
4.8部署图

图4-15配置图
心得体会
通过本学期的学习，使我认识到了UML建模课程这门课的重要性，在开发软件的过程中它起到了很重要的作用，也可以说是领头的作用。在做设计的时候同时也遇到了很多困难，比如有很多的概念都不是很清楚，也不会灵活运用这些理论，需要看书查资料，即使这样，做出来的设计也有着这样那样的问题，好在经过老师的指导，解决了这些问题。经过这次课程设计培养了我的自学能力以及合作能力，使我能够更好的学习。也让我认识到了这门课应该做到灵活运用才可以为以后的学习及工作打下基础，以后会更努力的学习这门课。
写到最后，感谢刘凤华老师的悉心指导，设计的每个阶段，从选题到查阅资料，以及最后的确定，期间文档的修改，格式的调整等各个环节中都给予了我悉心的指导。在此谨向刘凤华老师致以诚挚的谢意和崇高的敬意！
感谢在整个设计期间和我密切合作的吴玉萍和郭晶晶同学，和曾经在各个方面给予过我帮助的伙伴们，在此，我再一次真诚地向帮助过我的老师和同学感谢！