刘建芳 李培然 史丽珂

摘要：结合毕业设计选题双选管理业务流程中学生、教师、教研室主任的实际工作任务，使用UML对软件开发生命周期中的软件需求分析过程进行分析和建模，主要完成了业务建模和用例建模两个阶段的工作，为后续系统设计与开发打下夯实的基础。

关键词：毕业设计双选；UML建模；需求分析

中圖分类号：TP311.52 文献标识码：A 文章编号：1009-3044（2018）09-0083-03

Abstract： Combining with the actual tasks of students， teachers and Director of the teaching and research section in the dual selection management business process of graduation design，using UML to analyze and model the software requirements analysis process in the software development life cycle，this paper mainly completed two phases of work including the business modeling and use case modeling ， which lays a solid foundation for the follow-up system design and development.

Key words： graduation-design dual-selection； UML modeling； demand analysis

1 概述

近年来，随着平顶山学院办学规模的扩大，毕业生人数的增加，对于毕业生的毕业设计选题的管理难度也在逐年上升。长期以来，我校的教学管理工作人员使用人工方式进行毕业设计选题的管理，存在着许多缺点，如：效率低、容易出错，实时性和互动性不强、选题过程难以得到很好的保留等，同时也给学校的工作带来很大的不便。结合管理办法，开发毕业设计双选系统将有效的解决这一问题。本文将使用UML（United Modeling Language，统一建模语言）对系统开发过程中的需求分析工作展开建模。

2 业务建模

能否满足用户需求，是判定一个软件产品是否符合标准的重要依据，而如何深入理解需求、定义需求便是需求分析阶段的任务[1]。本部分将根据用户的需求给出实际业务的详细分析，最后根据实际业务需求导出系统需求。在需求的基础上，对系统的功能进行描述，最后进行用例建模。

对实际业务的分析是软件开发过程中的一个必要阶段，将为后期的开发奠定良好的基础。本部分将使用软件建模方法，针对平顶山学院毕业设计的选题过程进行业务建模。

2.1业务现状

毕业设计是在指导老师的指导下，学生利用所学的知识和技能，结合实际应用中的某一选题进行分析、研究和解决问题的过程。我校毕业设计选题的业务流程如下：每学年开始选题之前，由每个院系的教师申报课题，院系教研室主任进行审核，审核未通过的课题本学年将不再进行第二次申报，审核通过的课题进行发布，可由学生选择。学生在课下选择课题，指导老师则为该课题的出题老师，最后统一上报给院系，选题过程完成。

2.2识别业务参与者

业务参与者：在业务边界之外，与业务进行交互的人或组织，它接受业务提供的服务，并关注业务产生的结果[2]。

从业务描述中可以看出，对于毕业设计选题这一业务，教师负责申报课题，教研室主任对申报的课题进行审核，学生进行选题，他们都直接参与到业务流程中，因此本业务中的参与者为：教师、学生和教研室主任。

2.3业务用例图

业务用例：展示了业务的外部视图，它确定了业务为了向业务参与者交付期望结果，需要执行什么流程；同时还确定了，在执行业务用例时，业务与业务参与者之间需要进行哪些交互[3]。从教研室主任角度，作为教研室的负责人，需要审核教师申报的课题，此业务可以以作为一个业务用例。从教师角度，作为课题的提供者，教师有申报课题的业务，此业务可以作为一个业务用例。从学生角度，作为选题业务的主要参与者，其主要业务为选择毕业设计课题，此业务可以作为一个业务用例。

由以上分析已经得出毕业设计选题业务中存在三个业务用例，下面将使用用例图来描述业务用例，该模型能够直观清晰的反映业务的本质特征。

学生用例图：业务参与者是学生，为该业务参与者提供的业务服务为选择课题。业务用例图如图1所示。

教师用例图：业务参与者是教师，为该业务参与者提供的业务服务为申报课题。业务用例图如图2所示。

教研室主任用例图：业务参与者是教研室主任，为该业务参与者提供的业务服务为审核课题。业务用例图如图3所示。

2.4业务用例描述

活动图是一种行为模型，用于对系统的动态方面进行建模。它通过活动来组织，主要用于描述某一方法、机制或用例的内部行为特征，它强调的是从活动到活动的控制流[4]。

毕业设计选题业务包含了三个业务用例，学生选题用例是在教师进行申报课题和教研室主任审核课题之后进行的，而审核课题以及学生选题都伴随着各种活动和分支，而活动图是一种很好的体现复杂的业务流程的图形，因此为了更为清晰的描述整个选题业务的业务流程，下面将使用活动图对选题业务进行描述，如图4所示。

3系统用例建模

从业务到需求是定义一个系统要“做什么”的重要阶段，该阶段将为系统的开发指明方向。根据业务阶段的分析，可以得出系统要实现以下功能。

在开始毕业设计选题之前，系统需要为教师提供申报课题的功能，用以完成课题的上传；在申报课题时间段内，系统应该为教师提供修改课题、删除课题、查看课题的功能；为了满足业务需求并且体现人性化理念，系统应该提供教师选择学生的功能；为了利于选择学生，系统还应该为教师提供查看学生信息的功能。在申报课题时，教师还可以查看历年申报的课题；

教研室主任充当系统的管理员，因此系统状态的设置由教研室主任来实现。系统需要为教研室主任提供审核课题的功能，用以完成课题的审核，在审核过程中，还应该提供查看课题功能；为了使所有学生成功选到课题，系统还应该提供调剂学生功能。

系统需要为学生提供选择课题的功能，用以完成课题的选择，在选题时间段内，学可以改选课题，为了方便选题，还应该提供查看课题，查看出题教师功能；选题之后还要提供查看已选课题功能。

为了用户能够使用系统，系统该需要为每个用户提供登录功能，此外，对于系统的三个参与者来说，应提供修改个人信息功能，确保用户的个人信息是真实有效的。

根据基本功能设计，对系统功能进行细化。细化后的系统功能的如下：

1）系统的状态由教研室主任设置：教师申报课题状态、教研室主任审核课题状态、学生选择课题状态、教师选择学生状态、教研室主任调剂学生状态。

2）教研室主任：教研室主任成功登录系统后，可以修改个人信息，进行系统状态设置，对教师上报的课题进行审核，在教师和学生完成双向选择之后，对没有选到课题的学生进行调剂，确保每个学生都成功的选到毕业设计课题。

3）学生：学生成功登录到系统后，可以修改个人信息，在规定时间内进行选择课题操作，选题过程中也可以对教师和课题信息进行查看，在规定时间内还可以对已选的课题进行改选。

4）教师：教师成功登录到系统后，可以修改个人信息，在规定时间内进行申报课题操作，申报过程中也可以对已申报的课题进行查看、修改、删除操作，在学生完成选择课题之后，可以对学生进行选择。

3.1识别系统参与者

系统参与者：在系统之外，透过系统边界与系统进行有意义交互的任何事物[5]。

在教研室主任设定了系统的状态后，是由时间来启动的，因此时间是此系统的一个参与者。故系统参与者有：教研室主任、教师、学生和时间。

3.2识别系统用例

系统用例：规定系统或部分系统的行为，描述系统所执行的动作系类集，并为执行者产生一个可观察的结果[6]。通过对需求的进一步分析，系统有7个用例，分别是：

1）登录：验证用户身份。

2）修改个人信息：用户修改个人基本信息。

3）申报课题：教师提供一些毕业设计课题供学生选择。

4）审核课题：教研室主任对教师申报的课题进行审核。

5）选择课题：学生选择毕业设计课题。

6）選择学生：教师对选择自己作为指导老师的学生进一步选择。

7）调剂学生：教研室主任对未选到课题的学生进行调剂。

3.3系统用例图

通过对系统需求和功能的分析，绘制出本系统的学生用例图如图5所示。

3.4编写用例规约

用例文档是用来描述用例与外界交互的规格说明书，通过交互过程最终实现外界参与者的目标。在完成用例图之后，对系统中的每一个用例采用用例文档进行详细描述[7]。下面以学生“选择课题”为例，进行用例规约如下所示。

用例名：选择课题

参与者：学生

简要描述：学生通过该用例完成选题操作

前置条件：学生成功登录到系统，系统状态为学生选择课题状态；

后置条件：如果选题成功，学生的选题信息被记录到系统中；

基本事件流：

1）该用例起始于学生需要通过系统进行选题；

2）学生查询所有可选课题（A-1）；

3）系统显示可选的课题；

4）学生选择一个课题查看课题详细信息（D-1）；

5）系统显示课题详细信息；

6）学生选择课题并提交选择结果；

7）系统保存本次选题信息，并提示学生选题成功，用例结束（A-2）（D-2）。

备选事件流：

A-*.学生在提交信息前，随时都可能中止本次选课

1.系统显示中止确认的消息。

2.学生可以结束该用例，也可以选择继续。

A-1.查询不到可选的课题

1.系统显示没有可选的课题。

2.学生可重新查询，也可以结束该用例。

A-2.系统保存信息失败

1.系统提示保存信息，并提醒学生重新提交。

2.学生可重新提交本次选课信息，也可以结束该用例。

补充约束-数据需求：

D-1 课题信息包括：课题编号，课题名称，出题教师编号，课题难度，选题所属学年，课题类型编号，适用专业，审核状态，选择状态，所属教研室编号，可带学生人数，课题内容，选题模式；

D-2 选题信息包括：选题编号，学号，课题编号，指导老师编号，状态；

补充约束-业务规则：

A-1 每个学生只能在可选题时间段选题，每个学生能选多个课题，每个课题能被多个学生选择。

下面以教师“申报课题”为例，进行用例规约如下所示。

用例名：教师申报课题

参与者：教师

简要描述：教师通过该用例为学生提供能选择的毕业设计课题，并通过系统上传。

前置条件：教师成功登录该系统。

后置条件：审核通过的课题可供学生选择。

基本事件流：

1）该用例起始于教师通过该系统申报课题（D-1）；

2）教师选择课题上传（A-1）（B-1）；

3）系统保存本次上传，用例结束。

备选事件流：

A-*教师在提交发布课题时可以随时结束本次发布。

1.系统显示终止确认消息。

2.教师可以选择结束本用例，也可以继续选择。

A-1系统保存失败

1.系统提示上传失败。

2教师可以重新提交本课题，也可以选择其他操作。

补充约束-数据需求：

D-1课题信息包括：课题编号，课题名称，出题教师编号，课题难度，选题所属学年，课题类型编号（课题性质），适用专业，审核状态，选择状态，可带学生人数，课题内容，选题模式

补充约束-业务规则。

B-1教师应该在学生选课之前申报课题，一个教师可以申报多个课题。

补充约束-非功能需求：

考虑到以后会添加在线留言与回复功能，要为留言回复功能预留接口。

4 總结

本文结合平顶山学院毕业设计过程中的双选工作流程，借助UML建模语言，使用Rational Rose建模工具，从业务建模和用例建模两个步骤完成系统的需求分析与建模，为后续系统的设计与开发打下基础。

参考文献：

[1] 冀振燕.UML系统分析与设计教程[M].北京：人民邮电出版社，2014.

[2] 张家浩.软件系统分析与设计实训教程[M].北京：清华大学出版社，2016.

[3] 谭火彬.UML2面向对象分析与设计[M].北京：清华大学出版社，2013.

[4] 窦万峰.软件工程方法与实践[M].北京：机械工业出版社，2013.

[5] 郑浩.基于SSH的毕业设计管理系统的设计与实现[J].电子设计工程，2012.

[6] 王河媛，刘明慧.基于UML的视频点播系统的设计要点分析[J].计算机与数字工程，2016（1）.

[7] 王忠波，罗喜伶，齐鸣，等.基于UML和XSD的航班信息交换模型研究与实现[J].计算机技术与发展，2017（3）.