本文利用Rational Rose建立用例模型，建立领域模型，建立数据模型，并利用Rational Rose进行Web建模。毕业设计是实现本科教学培养目标的重要环节，从选题到答辩一般需要四至六个月的时间，其间工作量很大，尤其需要保留大量的文件，以便于管理者对毕业设计工作进行监督。通过互联网和校园网进行各学院毕业设计选题、中期、答辩和后期的流程管理。各阶段都要教务长来开通和关闭，对整个毕业设计的流程进行管理。其中系统的用户信息来自于现教务管理系统。
基于UML的毕业设计管理系统的分析与设计
<本段与标题无关，自行略过 最近各种忙，天气不错，导师心情不错：“我们要写一个关于UML的专著”，一句话：“一个完整的系统贯穿整个UML的知识”；我：“--o---k--”。忙里偷闲，先回顾一下吧>
毕业设计是实现本科教学培养目标的重要环节，从选题到答辩一般需要四至六个月的时间，其间工作量很大，尤其需要保留大量的文件，以便于管理者对毕业设计工作进行监督。传统的、人工的方式管理各项事务和文件档案，存在着诸如效率低、准确性差等缺点，对高效、合理地安排毕业设计很不方便。
利用计算机和WWW网络技术实现高校毕业设计的管理势在必行，制作毕业设计期间的教学管理、频繁的师生交流，以及大篇幅的论文管理，现在只要通过计算机就可以方便快捷的来完成。因此毕业设计管理系统的应用能够为用户提供充足的信息和快捷的查询手段。
通过互联网和校园网进行各学院毕业设计选题、中期、答辩和后期的流程管理。各阶段都要教务长来开通和关闭，对整个毕业设计的流程进行管理。其中系统的用户信息来自于现教务管理系统。
一.毕业设计管理系统的总体需求
1.总体业务流程
毕业设计的管理流程划分为四个基本步骤，见图1-1。
图1-1 毕业设计管理流程
2.系统功能框图
系统总体功能框图见图1-2。系统按照工作流程划分出四个主要功能模块，另外该系统还应提供登录功能模块和系统维护功能模块,其中系统维护模块包括身份管理、数据维护和流程管理三个子模块。每个模块完成的功能见表1-1。
图1-2 系统总体功能框图
3.总体功能分类描述
系统总体功能分类描述见表1-1
表1-1 总体功能分类
| 功能类别/标识符 | 目标描述 |
| 选题管理 | 完成教师立题、学生选题的双向选择过程。最终达到每人一题。 |
| 进行过程管理 | 完成教师与学生交流、中期检查、教师与学生互评过程。 |
| 答辩管理 | 完成答辩准备工作，提交答辩结果。 |
| 后期处理 | 完成收集、上报材料，统计成绩，评优过程。 |
| 登录管理 | 提供用户登录验证及用户权限查询的功能。 |
| 系统维护 | 系统维护包括：身份管理、流程管理和数据维护三个子功能块。 |
二.建立用例模型
1.建模思想
用例是对一个活动者(actor)使用系统的一项功能时所进行的交互过程的一个文字描述序列。用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。软件的开发
过程可以分为需求分析、设计、实现、测试等阶段，用例把所有这些都捆绑在一起，用例分析的结果也为预测系统的开发时间和预算提供依据，保证项目的顺利进行。因此可以，软件开发过程是用例驱动的。
用例分析的步骤可以按下面的顺序进行：
(1) 找出系统外部的参与者和外部系统，确定系统的边界和范围。
(2) 确定每一个参与者所期望的系统行为。
(3) 把这些系统行为命名为用例。
(4) 使用泛化、包含、扩展等关系处理系统行为的公共或变更部分
(5) 编制每一个用例的脚本。
(6) 绘制用例图。
(7) 区分主事件流和异常情况的事件流，如果需要可以把表示异常情况的事件流作为单独的用例处理。
(8) 细化用例图，解决用例间的重复与冲突问题。
采用用例分析法捕获用户的需求，其中一个比较困难的工作是确定系统应该包含哪些用例，以及如何有效地发现这些用例。事实上，在做用例分析时，并没有一个固定的方式或方法来发现用例，而且对同一个系统，往往会同时存在多种解决方案，但其中某些方案会比另一些方案好。与设计和实现阶段相比，需求分析阶段更多的还是依赖于分析人员的个人经验和领域知识。
2.用例模型
2.1、用例定义
用例通过某种途径与系统交互。从系统外部执行者的角度来描述系统需要提供哪些功能,并指明这些功能的执行者(用例)是谁。确保所有角色都被完全识别出来。
本系统用户群分为四大类:教务管理员、毕业设计专家组、教师和学生。各类用户用不同的职责和权限。本系统的用例于表2-1中。
表2-1 系统的用例定义
| 用例名称 | 用力职能 |
| 教务管理员 | 完成拟题和选题公告、论文选题管理、优秀论文展示、手动操作选题、发布选题、分配答辩教师、管理答辩小组、论文推优、工作总结、处理论文材料、留言删除等相关管理功能 |
| 毕业设计专家组 | 审核论文题目、审核论文、参与答辩等 |
| 教师 | 参与拟题，指导学生、评审论文等相关功能 |
| 学生 | 参与选题、提交论文、进行答辩等功能 |
| 系统维护员 | 主要负责系统维护、系统公告、用户添加、数据维护等 |
2.2、系统顶层例图
用例是参与者与系统的交互过程,代表系统为其参与者所执行的有价值的操作,表达了系统的功能需求和行为。用例的用途是在不揭示系统内部构造的情况下定义连贯的行为。用例可以在执行过程中持续接受参与者的输入信息,可以描述系统向用户提供的有价值的功能。
用例不仅是描述需求的工具,还可以驱动开发过程,通过对用例的创建、整合,开发设计人员可以构建一系列实现这些用例的设计和实现模型。系统顶层用例的构建,可以使得系统整体性的呈现并被建模人员把握。通过前述需求分析的结果,可以得出顶层用例,其中涉及的参与者及其活动系统顶层用例图如图2-1所示:
图2-1：系统顶层用例图
2.3、用例的细化（主要模块的用例）
每一个用例都是一个参与者与系统在交互中执行的有关事务序列。从毕业论文指导交互系统的用例抽象,可以确定如下的主要模块的用例: 毕设选题管理、毕设进行过程管理、毕设答辩管理、毕设后期处理等。
从系统总的用例来建立用例图,这样设计在项目开始阶段对理解系统的要求和目标都有好处,但需要进一步细化,划分为更具体的一些用例,以便深入分析系统的要求和目标。
1）毕设选题管理
毕业设计选题管理中中的参与者包括教务、毕业设计专家、教师和学生。教务发布拟题要求、管理双向选题、发布题目和公布选题结果；专家组对论文题目进行评审，并给出意见；教师根据拟题要求拟题和提交题目的任务说明，并通过学生的选题情况选择学生；学生根据选题要求选择论文题目等。选题管理用例图如图2-2所示：
图 2-2 选题管理用例图
毕业设计选题部分各子功能描述见表2-2。
表2-2 选题管理功能及用例描述
| 名称、标识符 | 执行用例 | 描述 |
| 发布拟题要求 | 教务管理 | 根据毕业学生和学院要求发布本届毕业设计信息和拟题要求： ▪毕业班级、专业、人数； ▪毕业设计日程安排； ▪各环节的表格； |
| 确立题目 | ①指导教师根据拟题要求拟题并提交： 要求：不与他人重题；不与上届重题；不是网上抄袭； 题目：名称；实现功能；技术要求； ②专家组评审：毕业设计专家组对指导教师提交的题目进行评审，如不合格提出修改意见反馈给教师，指导教师重新拟题并提交； ③发布题目：教务人员对专家组提交的合格毕业设计题目进行发布。 | |
| 双向选题 | ①学生初选题目：学生对发布的论文题目进行初选，每人最多选择三个设计题目，每个设计题目可被三个学生备选； ②指导教师选择学生：指导教师可以查阅自己题目的初选结果，并初选学生一名。 ③初选结果调整：教务人员关闭双向选题，对没被选择的题目和没被选择的学生手工进行调整， 最终确定导师和学生。 | |
| 发布选题结果 | 发布最终选题结果。此后学生和教师都可查询到选题结果。 |
2）毕设进行过程管理
毕设进行过程管理中的参与者包括教务、毕业设计专家、教师和学生。教务开通指导园地，进行开题管理，教务存档中期报告等活动；毕业设计专家组对学生提交的开题报告进行评审，如不合格提出修改意见反馈给学生，学生重写开题报告并提交；指导教师收取中期报告并送审中期报告；学生与老师通过一下外部接口通信，学生提交开题报告和中期报告。毕业设计进行过程管理用例图如图2-3所示：
图 2-3 毕业设计进行过程管理用例图
毕业设计进行过程管理部分各子功能描述见表2-3。
表2-3 进行过程管理功能及用例描述
| 指导园地 | 教务人员开通指导园地，学生与老师通过一下外部接口通信：（目前只设计提交通信方式功能，带以后完善与外部系统的接口通信。） ▪毕设论坛 ▪电子邮件 ▪QQ群 | |
| 开题管理 | ①学生提交开题报告。 ②教务下载所有开题报告，并分派给各专家组审阅。 ③专家组评审：毕业设计专家组对学生提交的开题报告进行评审，如不合格提出修改意见反馈给学生，学生重写开题报告并提交； ④教务存档开题报告：教务人员上传开题报告到中期过程数据库。 ⑤教务关闭开题：关闭开题，同时开通中期检查。 | |
| 中期检查 | ①学生提交中期报告。 ②指导教师收取中期报告：指导教师可以离线审阅中期报告； ③指导教师送审中期报告 ④教务存档中期报告：教务人员上传中期报告到中期过程数据库。 ⑤教务关闭中期检查。 |
3）毕设答辩管理
毕设答辩管理中的参与者包括教务、毕业设计专家、教师和学生。其中教务教务人员安排答辩同时开通论文评审并分配评审论文，教务存档评审结果等；专家组对学生进行答辩并提交答辩记录和成绩评定；教师指导审查论文初稿并提出修改意见，学生依此修改并再次提交；学生修稿、提交论文，参加答辩，上传材料等。毕设答辩管理用例图2-4所示：
图2-4 毕设答辩管理用例图
毕业设计答辩管理部分各子功能描述见表2-4。
表2-4 答辩管理功能及用例描述
| 前期准备 | ①交收论文初稿：学生上交初稿，教师审查并提出修改意见，学生依此修改并再次提交。 ②答辩申请：进过教师同意后，学生可以提出答辩申请。 ③教务人员安排答辩，同时开通论文评审。 | |
| 论文评阅 | ①指导教师评审：指导教师对自己学生评审并提交评审意见。 ②教务分配评审论文：分配结果要求，审阅该论文的教师不该论文的指导教师。 ③审阅教师评审：审阅教师对该学生评审并提交评审意见。 ④教务存档评审结果：教务人员上传、浏览评审结果。 ⑤教务关闭论文评审：关闭论文评审，同时开通答辩过程。 | |
| 答辩过程 | ①学生答辩：专家组提交答辩记录和成绩评定。 ②教务关闭答辩过程。 |
4）毕设后期处理
毕设答辩管理中的参与者包括教务、教师和学生。教务统计分析成绩、发布成绩，教务归档论文，评审优秀教师、学生等；学生申请优秀论文；指导教师申请优秀指导。毕设后期处理用例图如图2-5所示：
图2-5 毕设后期处理用例图
毕业设计后期处理部分各子功能描述见表2-5。
表2-5 后期处理功能及用例描述
| 成绩管理 | ①教务统计分析成绩： ▪按教师指导学生论文成绩平均分统计。 ▪按教师指导学生数统计。 ▪按学生成绩统计。 ②教务人员发布成绩。 | |
| 论文归档 | ①教务归档论文:教务将论文入库，教务、教师与学生可浏览。 ②教务提交、浏览辅助材料。 ③教务文档备份清理。 | |
| 评优管理 | ①学生申请优秀论文：学生提交评优申请。 ②指导教师申请优秀指导：教师提交评优申请。 ③教务评审优秀教师、学生。 |
5）登录管理
登录管理中的参与者包括教务、毕业设计专家、教师和学生。毕业设计登录管理是所有合法用户进入系统的唯一路径。毕业设计登录管理根据用户的不同类型提供不同的功能服务。其中教务长与数据维护人员可进入系统的维护平台进行操作。普通用户只进入工作流程平台。登录管理用例图如图2-6所示：
图2-6 登录管理用例图
毕业设计登录管理部分各子功能描述见表2-6。
表2-6 登录管理功能及用例描述
| 专家 | ①数据维护人员和教务长登录时，即可登录到系统维护平台也可登录到工作流程平台。 ②教师、学生和普通教务登录后，进入工作流程平台。系统依据用户类别不同，提供的功能页面也不同。 |
6）系统维护
系统维护中的参与者包括教务长和系统数据维护员。系统维护模块分为三个子模块：①身份管理；②流程管理；③数据维护。身份管理又分为用户管理和角色管理。数据维护分为用户信息导入导出和备份清理毕设文档。系统维护用例图如图所图2-7和2-8所示：
2-7 系统维护（数据维护人员）用例图
2-8 系统维护（教务长）用例图
毕业设计管理中系统维护部分各子功能描述见表2-7。
表2-7 系统维护功能及用例描述
| 身份管理 | 教务长 | ①教务长登录后，可以对用户进行增、删、改、查操作。 ②教务长登录后，可为用户授权。无授权用户不能进入毕业设计管理系统。 ③教务长登录后，可以对角色进行增、删、改、查操作。 |
| 流程管理 | 教务长登录后，可对毕业设计工作流程进行全程的管理。流程管理的功能包括： ①开通选题管理 ②关闭选题管理 ③开通进行过程管理 ④关闭进行过程管理 ⑤开通答辩管理 ⑥关闭答辩管理 ⑦开通后期处理 ⑧关闭后期处理。 | |
| 数据维护 | 数据维护人员 | ①数据维护人员登录后，可导入导出用户信息。导入导出用户信息是数据库文件形式。 ▪导入用户信息包括： 导入学生信息； 导入教师信息。 ▪导出用户信息包括： 导出学生信息； 导出教师信息。 注：导出用户信息功能是为以后其他系统的信息导入设计的。 ②教务长登录后，可备份清除毕业设计文档,三年以上的毕设文档备份、清除。 |
3.总结
用例模型基本实现了所有的需求，并增加了部分需求，如在选题时，学生可能会根据兴趣及教师的研究方向进行选题，所以增加了教师信息、学生信息等；增加了相互留言功能。
下面的这些启发性原则可以帮助分析人员发现用例：和用户交互。寻找用例的一个途径就是和系统的潜在用户会面、交谈。可能不同的用户对系统的描述会是完全不同的，即使是同一个用户，他对系统的描述也可能是模糊的、不一致的，这时就需要分析员做出判断和抉择。把自己当作参与者，与设想中的系统进行交互。 确定用例和确定参与者不能截然分开。
一些原则来帮助发现用例，如通过回答下列问题来帮助发现用例：
． 参与者的主要任务是什么？
．参与考需要了解系统的什么信息，需要修改系统的什么信息？
．参与者是否需要把系统外部的变化通知系统?？
．参与者是否希望系统把异常情况的变化通知自己？
随着经验的不断积累，对于如何寻找用例会逐渐形成自己的也可以通过与其他人的交流来提高自己的分析水平。
三.建立领域模型
1.建模思路
概念模型是从用例模型映射到类的第一步。概念模型是将用例模型向计算机表示的进一步过渡。概念模型就是划分类的结果。主要表达用类图，辅以顺序图。类图建模是UML静态建模机制中的一个重点,信息结构和系统行为均需借助它来描述。类图创建工作主要包括创建类、标识类之间的结构关系。
首先确定类,其次再确定其属性和操作;最后将类与类之间的关联、依赖、继承、聚合关系在图中标示出来,就得到类图。
在寻找类时,可以根据功能把类分成三种类型:实体类、边界类和控制类。边界类位于系统与外界的交接处,包括所有窗体、报表、打印机等硬件接口以及其他系统的接口,边界类使角色能与系统交互,而每个角色要使用用例与系统交互至少要有一个边界类。实体类保存要放进永久存储体的信息,在系统运行时,实体类在内存中保存信息。控制类负责协调其他类的工作。实体对象类表示系统中的信息存储,它们一般用于表示系统所管理的核心概念。实体对象是被动和永久性的。它们的主要职责是存储和管理系统中的信息。
2.领域模型
根据建模思想对每个用例分别可以找出三种类：边界类、逻辑类和实体类；将所有找到的三种类集中综合在一起得到三大模型：视图模型、逻辑模型和实体模型。
原始类的划分可采用表格表示三大模型，根据要求再进一步细化。
根据《毕业设计管理系统需求描述》的选题过程可以得到三大模型如下：
表3-1 毕业设计管理管理系统划分出的视图模型（边界类）
| 用例 | 边界类 | 说明 |
| 登录 | LoginForm | 为用户提供登录界面，不同用户进入不同的界面 |
| 发布信息 | PublishInfoForm | 教务发布拟题要求、论文题目、最终选题结果等的发布界面 |
| 双向选题工程管理 | TopicseletionForm | 教务开启和关闭双向选题工程的界面 |
| 手工调整选题 | AdjustForm | 教务调整双向选题的界面 |
| 更新教师信息 | UpdateTeacherForm | 教师更新信息的界面 |
| 查看拟题要求 | DemandForm | 教师查看拟题要求界面，重要的一个过程 |
| 查询题目选情和选择学生 | TeaselectionForm | 教师查询自己题目的选择情况和选择学生界面 |
| 处理论文题目 | ManageTopicsForm | 教师提交论文题目、修改论文题目的界面 |
| 更新学生信息 | UpdateStudentForm | 学生更新信息的界面 |
| 学生选题 | StuselectionForm | 学生查看选题指南、查询题目、选择题目等的选题界面，进入界面会首先显示选题指南 |
| 文件管理 | File | 上传和下载文件的界面 |
| 评审题目 | ReviewTopicsForm | 毕业设计专家在线审核论文题目的界面 |
表3-2 毕业设计管理管理系统划分出的逻辑模型（逻辑类）
| 逻辑类 | ||
| Login_Operation | 通过Login为用户提供身份验证，验证成功才能进入系统 | |
| PublishInfo_Operation | 教务发布管理，通过Administrator，当发布题目时更新Topics一条记录等 | |
| Topicseletion_Operation | 教务开启和关闭双向选题工程，关闭实质是将选题功能屏蔽掉 | |
| Adjust_Operation | 教务调整双向选题，通过调用RegisterTopics修改选题情况 | |
| UpdateTeacher_Operation | 教师信息更新，通过Teacher的TUpdateInfo逻辑修改个人信息 | |
| Demand_Operation | 教师调用teacher类的ViewDmand查看拟题要求 | |
| Teaselection_Operation | 教师通过QuerySelected查询自己题目被选情况，通过SelecteStudent逻辑选择学生 | |
| ManageTopics_Operation | 教师通过teacher处理题目 | |
| UpdateStudent_Operation | 学生通过Student类SUpdateInfo操作更新信息 | |
| Stuselection_Operation | 学生选题逻辑，通过实体类Student，选择题目SelecteTopics向选题注册表单插入一条记录，ModifyTopics更新选题注册表单等 | |
| File_Operation | 上传和下载文件 | |
| ReviewTopics_Operation | 毕业设计专家在线审核论文题目，通过点击通过按钮，触发Topics类加入一条题目，不通过点击留言给教师 | |
| 留言 | Message_Operation | 处理用户之间留言逻辑类 |
表3-3 毕业设计管理管理系统划分出的实体模型（实体类）
| 实体类 | ||
| 登录类 | Login | 用户身份，用户的学号、工号，用户的姓名、密码等信息 |
| 学生类 | Student | 学生信息，学号、姓名、联系方式、班级等信息 |
| 教师类 | Teacher | 教师信息，工号、姓名、职称、个人简介等信息 |
| 毕设专家组类 | Expert | 专家信息，记录工号、专家简介等信息 |
| 教务类 | Administrator | 教务信息，教务的工号、教务的级别、教务的信息 |
| 毕设题目类 | Topics | 毕业设计题目，包含题目名称、所属专业、指导教师、任务说明等信息 |
| 题目登记类 | RegisterTopics | 题目登记，记录每一次学生选择论问题或教师选择题目的信息，并写入数据库 |
通过以上面向对象分析方法可以得到系统中完成选题功能的领域模型（初始类图）如图3-1所示：
图3-1 选题功能的初始类图
附：视图类、逻辑类和实体类表中的函数参看下图
图3-2 选题功能的初始类图（Eglish）
本实验很好的实现了领域模型和系统逻辑处理的对应，从而得到了边界类、逻辑类和实体类。找边界类时，注意边界类位于系统与外界的交接处；逻辑类主要是操作类；实体对象类表示系统中的信息存储,一般会有对应的表单。
类找到后，要用rose进行建模。UML中的类图具有充分强大的表达能力和丰富的语义，是建模时非常重要的一个图。
1．类之间可以有关联、聚集、组合、泛化、依赖等关系。
2．关联是类图中比较重要的一个概念，一些相关的概念有关联名、关联角色、关联类、关联上的角色、限定关联、自返关联、二元关联、N元关联等。
3．关联类是用于描述关联本身的特性。
4．带有限定符的关联称为限定关联，限定符的作用就是在给定关联一端的定符值以后，可确定另一端的一个对象或对象集。
5．派生属性和派生关联是指可以从其他属性和关联计算推演得到的届性和关联，在生成代码时，派生属性和派生关联不产生相应的代码。
6．抽象类和接口为oo设计提供了抽象机制。
7．版型是UMI‘相F常重要的一种扩展机制，uML之所以有强大而且灵活的表示能力，与版型这种扩展机制有很大的关系。
8．边界类、控制类和实体类是对类的一种划分，它们都是类的版型。
四.建立数据模型
逻辑结构设计阶段的任务就是将概念结构设计阶段完成的概念模型转化成能被特定数据库管理系统支持的数据模型,也即是关系模型。这些模型在功能、性能、完整性和一致性约束及数据库可扩充性都需要满足用户需求。
首先根据前面的实验，实体-联系图提供了表示实体型、属性和联系的方法,可用来描述现实世界的概念模型。对毕业设计管理系统的实体关系(E-R)分析是建立在UML系统模型基础上的。E-R分析的目的是确定系统中所有实体之间的关系和实体的属性,画出E-R图,为数据库建模打下基础。画E-R图通常使用自底向下的设计方法,首先对局部视图进行分析设计,然后再实现视图集成。画E-R图如下：
图4-1 毕设选题管理E-R图
图4-2 毕设进行过程管理E-R图
图4-3 毕设答辩及后期管理E-R图
2.实体类关系模型
由系统的实体类可以设计表如下：
DBMS：SQL server 2008 R2
数据库名称：graduation_project_management
表4-1 专家信息表
| 字段 | 数据类型 | 是否允许空 | 备注 | 注释 |
| expert_id | char(15) | 否 | 主键 | 专家的工号 |
| expert_name | char(10) | 专家的姓名 | ||
| expert_password | 专家的登录密码 | |||
| expert_introduction | nvarchar(MAX) | 专家的个人信息，为大值数据类型最多可以存储2^30-1个字节的数据，大数据类型可检索 | ||
| user_type | int | user_type=0 | user_type=0，身份为专家，登陆后进入专家页面 |
表4-2 教务员信息表
| admin_id | 教务员的工号 | |||
| admin_name | 教务员的姓名 | |||
| admin_ password | 教务员的登录密码 | |||
| admin_ introduction | 是 | 教务员的个人信息 | ||
| user_type=1或user_type=2 | user_type=1为普通教务员， user_type=2为教务长 |
表4-3 学生信息表
| stu_id | 学生的学号 | |||
| stu_ name | 学生的姓名 | |||
| stu_password | 密码，默认为学号后6位 | |||
| stu_ sex | char(2) | 学生性别 | ||
| stu_ department | char(20) | 学生系别 | ||
| stu_ class | 学生班级 | |||
| stu_ introduction | 学生个人简介 | |||
| stu_tel | char(11) | 学生联系方式 | ||
| user_type=3 | user_type=3代表学生 |
表4-4 教师信息表
| tea_id | 教师的工号 | |||
| tea_ name | 教师的姓名 | |||
| tea_password | 密码，默认为工号后6位 | |||
| tea_ sex | 教师的性别 | |||
| tea_title | 教师的职称 | |||
| tea_ introduction | 教师个人简介 | |||
| tea_tel | 教师联系方式 | |||
| user_type=4 | user_type=4代表教师 |
表4-5 论文题目信息表
| topic_ id | 论文题目的编号，教师拟题会上传至此表，不符合题目可被修改或删除 | |||
| topic_ name | 题目的名称 | |||
| 外键 | 命题教师的工号 | |||
| topic_note | 题目任务说明 |
表4-6 选题注册信息表
| choice_ id | 每个学生选择3个题目后选题注册信息表会增加3个choice_ id记录，当教师选中学生后，其他的记录会被删除，这样论文就被选定了 | |||
| 论文题目的编号 | ||||
表4-7 文件管理表
| file_id | Int(50) | 主键，自增长 | 文件的编号 | |
| use_id | 用户的编号，可以是工号或学号 | |||
| file_name | char(30) | 文件的名字 | ||
| file_discription | 文件的描述 | |||
| file_type | 文件的类型， 0示开题报告， 1示论文初稿， 2示论文终稿， 3示论文题目， 4.表示最终选题结果 5表示论文成绩 6论文进度 7拟题要求 8选题要求 | |||
| file_path | 文件的路径 | |||
| up_time | datetime | 文件上传的时间 | ||
| download_time | 文件下载的时间 |
表4-8 论文成绩表
| 论文题目 | ||||
| 论文对应的学生学号 | ||||
| all_grade | 答辩的各项成绩，以“,”隔开 | |||
| result | 答辩总成绩 | |||
| apprise | 是否为优秀论文 |
表4-9 留言信息表
| messgae_id | 主键,自增长 | 留言信息的编号 | ||
| messgae_title | char(50) | 留言信息的标题 | ||
| messgae_content | 留言信息的内容 | |||
| messgae_from | 发送留言者的工号或学号，需要表的连接显示姓名 | |||
| messgae_to | 接受留言者的工号或学号，需要表的连接显示姓名 | |||
| messgae_time | 留言发送的时间 | |||
| is_viewed | 标示位， 0表示留言已被查看 1表示未被查看 |
表4-10 权限管理表
| poedorm_id | int(50) | 权限的编号 | ||
| poedorm_name | 权限的名字 | |||
| poedorm_state | 权限的状态，0为禁用，1为启用 | |||
| poedorm_description | 权限的说明 | |||
| poedorm_date | 权限添加的时间 |
在rose中进行数据建模，模型中只给出了关键字字段和索引项，各表的全部字段请参考以上10个表。建立关系模型如下：
图4-4 毕设选题关系模型
图4-5 毕设答辩及后期处理关系模型
本实验实现了数据模型和系统处理数据的对照。首先应该画出E_R图，根据E-R图及前面的实验设计出系统的表，进而用rose画出相应的数据模型。
在rose中数据建模时一定要先在组件图上建立Database，再在逻辑视图中建立Schemas，然后在Schemas建立Data Model Diagram,最后双击在Data Model Diagram画表和建立表的关系。
五.进行Web建模
Web建模主要考虑两方面的问题，一是如何表示Web应用系统的体系结构，另一个是如何表示Web应用系统中一些特有的概念。
用UML对Web系统建模影响比较大的一种版型扩展方法称为WAE（Web Application Extension，Jim Conallen提出），已被多个UML建模工具采用。WAE定义了一些常见Web系统的建模元素，可以用这些版型对Web建模，并且Rose提供了Web系统的逆向工程。
Web建模的基本问题 ：
（1）Web应用系统采用的HTTP协议是一种客户、服务器间无状态、无连接协议，因此页面之间传递的信息需要使用Session或cookie对象来保存；
（2）Web的客户端多样化（不同浏览器、不同操作系统）；
（3）Web系统有特有的概念和元素：HTML、表单Form、网页框架Frameset，Jsp，Servlet等；
（4）Web应用系统的设计模式常用MVC模式。
MVC模式的思想：表示信息结构的数据是相对稳定的，而对数据的操作和表示是可变部分、常变部分。该模式支持软件可重用性。如图5-1：
图5-1 MVC模式
用Rose建模的主要过程如下（所有操作都应在Web Modeler 选项下进行）：
① Tools→Option→Notation中设置Web Modeler（可以根据模型产生jsp文件）；
② 创建虚拟目录：存放以后创建的所有页面，在Logical view下 右击鼠标，选择Web Modeler→New→Virtual Directory；
③ 创建服务器页：在虚拟目录名上右击，选择Web Modeler→New→Server page（Rose会同时创建对应服务器页，客户端页面）（Server-client由Server动态产生）；
④ 创建客户端页：在虚拟目录名上右击，选择Web Modeler→New→Client Page；
⑤ 创建表单：右击客户独立类的端页，选择Web Modeler→New→HTML Form在Title下创建Form表单；
⑥ 在表单中添加各种版型的HTML交互控件元素
⑦ 将Web元素拖入类图窗口，建立他们之间的关联关系。
2.WEB模型
2.1、首先创建虚拟目录（virtual directory）：
1) 在Logical View下，选Web Modeler→New→virtual directory
2）选择platform(平台语言)为 jsp
3) 设置URL Name为：http:/www.zstugpm.com
4）Virtual Directory Name为：zstugpm
这时虚拟目录为版型为《Virtual Directory》的包Demo (完成上述设置后，在URL地址为：http:/www.zstugpm.com的所有web 页面均放在zstugpm包内。)
5) Physical Location (物理路径名)可设置为：D:\code
2.2、WEB建模
按照实验要求和前面实验的基础，进行登录建模，学生主页、教师主页、教务主页和专家主页的建模，学生选题流程建模，教师选题流程建模，教务选题流程建模，专家选题流程建模。
1）登录WEB建模
用户输入用户名和密码，选择身份（学生，教师，教务，专家），验证成功进入对应的主页面。
图5-2 登录WEB建模
2）学生主页WEB建模
利用rose的拓展机制加入用于Frameset建模的版型。StudentMianPage类表示一个frameset（自己定义的版型）。Index类表示导航区。Content类表示点击导航区域中的不同链接时，不同的Web页面在Content中显示（教师主页、教务主页和专家主页的建模同学生主页的建模相同）。如图5-3所示：
图5-3 学生主页WEB建模
3）学生选题流程建模
学生先登录到学生主页面，可进入关于选题页面（SelectTopics）和个人信息管理页面（Infomation）。进入选题页面，可选择进入选题页面和修改选题页面；进入个人信息页面课添加或更新个人信息。
图5-4 学生选题流程建模
4）教师选题流程建模
登陆后进入教师主页面，可进入拟题页面和选择学生页面。进入拟题页面，继而会显示拟题的要求，可以拟新的题目和修改题目；进入选择学生页面选择自己敢兴趣的学生。
图5-5教师选题流程建模
5）教务选题流程建模
教务登录到教务主页面，可进入选题相关的发布页面、双向选题管理页面、调整选题页面。发布信息页面Publish可链接到发布拟题和选题要求页面PublishInfo、发布论文题目页面PublishTopics、发布最终选题结果页面PublishResult。调整选题页面，要提交表单到ManageSelectServer服务器页。管理选题过程有开启和关闭选题过程的按钮。
图5-6教务选题流程建模
6）专家选题流程建模
登录后进入专家主页面，链接进入评审页面，可进入未评审页面和编辑已评审页面。评审条目利用javabean技术建立listing.java从数据库获取。添加评价需要提交表单到AddReview服务器页，修改评价需要提交表单到EditReview服务器页。:专家选题流程建模如图5-7：
图5-7 专家选题流程建模
本实验实现了实验要求，使用Rational Rose进行Web建模的方法和步骤。
在Rose2003下对Web应用系统建模，需要先在Tools Options Notation 标签中设置Default为Web Modeler。这时可以根据模型特点分别生成 .jsp, .asp或.html文件。
Servlet建模:Servlet是用Java语言编写在服务器上运行的程序。它接受来自客户端的请求，并把处理结果返回客户端。编写Servlet类通常继承GenericServlet或HttpServlet类。因此Java中有两种类型的 Servlet在Rose中分别是用版型《Http_Servlet》或《Generic_Servlet》来表示。 在Rose中,用Tools→Java/J2EE→NewServlet 来创建Servlet类。
Web建模是UML扩展机制之一（版型）的应用、系统建模时根据需要可再利用该扩展机制创建新版型，满足建模需要。
建好模型后进行正向工程，产生代码框架，再进行代码开发，可减少开发工作量。Web应用模型的类图各页面关系清晰，便于分析、修改模型。
附：《基于UML的毕业设计管理的分析与设计》rose源文件。
完
欢迎转载。转载请注明转载字样，标注原作者和原博文地址。