学生成绩管理系统的分析及设计-应用UML建模.docx

学生成绩管理系统的分析及设计-应用UML建模.docx

《学生成绩管理系统的分析及设计-应用UML建模.docx》由会员分享，可在线阅读，更多相关《学生成绩管理系统的分析及设计-应用UML建模.docx（46页珍藏版）》请在冰点文库上搜索。

第1章系统需求

学生成绩管理系统的域E描述如下：

在学生成绩管理系统中，要为每个学生建立一个帐户，并给学生发放帐户（帐户可以提供帐户号、帐户初始密码），帐户中存储学生的个人信息、选课信息以及课程成绩。

持有帐户的学生可以登陆系统，只能查看本人的个人信息、选课信息、个人成绩。

在登陆时，需要输入自己的账号和密码，系统验证学生是否有效（在系统中存在帐户），若有效，则登陆系统，否则重新输入，超过三次，则不允许再次输入。

老师可以修改学生成绩信息，但仅限于学生选修的那门课程。

老师也有自己的个人帐户，权限比学生高，可以浏览学生信息。

学生成绩管理系统的管理员，可以编辑、添加、删除、学生信息。

对上述学生成绩管理系统的域描述进行分析，可以获得如下功能性需求：

＞学生持有帐户（帐户号和密码）。

＞学生可以登陆系统。

＞学生可以查看系统消息内的信息。

＞学生可以查看个人信息，个人成绩信息和选课情况。

＞在学期结束时，学生可以选课。

＞学生可以给管理员发消息。

＞老师可以修改选修自己课程的学生的成绩信息。

＞老师可以浏览选修自己课程的学生的信息。

＞学生成绩管理员可以创建新的学生帐户。

＞学生成绩管理员可以修改学生的帐户信息。

＞学生成绩管理员可以删除已存在的学生帐户。

＞学生成绩管理员可以在系统中添加学生信息。

＞学生成绩管理员可以编辑学生信息。

＞学生成绩管理员可以删除学生信息。

第2章需求分析

采用用例驱动的分析方法分析需求的主要任务是识别出系统中的参与者和用例，并建立用例模型。

2.1识别参与者

通过对系统需求的分析，可以确定系统中有三个参与者：

StudentActor（学生）、TeacherActor（教师）、AdminerActor（管理员）。

参与者的描述如下：

（1）Student

描述：

学生可以登陆、选课、查看系统信息、个人信息、提出意见，还可以取消选课。

示例：

持有帐户的任何人或组织。

（2）Teacher

描述：

可以修改学生部分信息，浏览学生信息。

示例：

持有帐户的任何人和组织。

（3）Adminer

描述：

学生成绩管理员维护系统，可以创建、修改、删除学生的信息，可以添加、编辑、删除学生信息，即维护目录。

示例：

学生成绩管理员。

2.2识别用例

前面已经识别出了参与者，通过对需求的进一步分析，可以确定系统中有如下用例存在：

（1）Reservecourse（选课）

本用例提供了选课的功能。

（2）Cancelcourse（取消选课）

本用例提供了取消选课的功能。

（3）inputscore（输入成绩）

本用例提供了教师上传学生成绩功能。

（4）updatescore（更改成绩）

本用例提供了修改成绩的功能。

（5）MaintainstudentInfo（维护学生信息）

本用例提供了创建、修改以及取消学生帐户的功能。

（6）MaintainteacherInfo（维护教师信息）

本用例提供了添加、修改、以及删除教师帐户的功能。

（7）MaintainsystemInfo（维护系统信息）

本用例提供了添加、修改以及删除系统信息的功能。

（8）LogIn（登录）

本用例描述了用户如何登录进入软件系统。

在识别出参与者⑶和用例后，要想建立用例图，还需要识别出他们之间的关系。

“Reservecourse”（选课）"Cancelcourse”（取消选课）这些动作是由"Student”执行的，"inputscore”（输入成绩）、“updatescore"（更、改成绩）是由"teacher”执行的,但是对于软件系统来说，这些操作是由“Adminer”通过系统赋予给他们的，也即以上操作实际上是操作者在允许条件下与系统的交互。

“Student”“teacher”和参与者"Adminer”之间存在着依赖关系，即“Student"借助"Adminer”完成这些工作。

用例"MaintainstudentInfo”（维护学生信息）、“MaintainteacherInfo”（维护教师信息）、“MaintainsystemInfo”（维护物系统信息）也是与参与者“Adminer”交互。

为了系统的安全性，系统还需要提供进行身份验证的功能，以确保只有具有权限的“Adminer”才可以使用系统的功能，所以“Adminer”必须与用例“登录”交互,也即“Adminer”在使用系统前，要使用用户名和密码进行登录，系统验证用户的密码正确后，用户才可以执行进一步的操作。

系统的用例图如下图所示:

图2.1系统用例图

2.3用例的事件流描述

用例的事件流⑷是对完成用例行为所需的事件的描述。

它描述系统应该做什么，而不是描述系统应该怎样做。

开始，只是对执行用例的常规流所需的步骤的简单描述。

随着分析的进行，通过添入更多的详细信息，步骤不断细化。

最后，将例外流添加到用例的事件流描述中。

学生成绩管理系统的用例事件流描述如下：

2.3.1选课

在这个用例开始前，student必须登录到系统中。

如果这个用例成功,在系统中建立并存储选课记录，否则，系统的状态没有变化。

当学生选课时，用例启动。

学生打开系统的选课系统，出现选课界面，支流s-1：

开课目录。

支流S-2：

选课情况。

S-1：

选课目录

（1）提供学期分类。

（2）检索课程类别（kind）（E-1）

（3）检索要选课程名（coursename）（E-2）,

（4）创建选课记录。

（5）存储选课记录。

S-2:

选课情况

（1）提供是否要书。

（2）是否加权分。

（3）是否撤销。

（4）查看选课记录。

E-1:

大方向总体分类。

E-2:

具体课程名。

2.3.2取消选课

在这个用例开始前，student必须登录到选课系统中。

如果这个用例成功，系统删除该选课记录。

否则，系统的状态没有变化。

当学生取消选课时，用例启动。

（1）检索选课程名（E-1）o

（2）删除选课记录。

E-1:

若选课记录不存在，系统显示提示信息，用例终止。

2.3.3输入成绩

在这个用例开始前，teacher必须登录到系统中。

如果这个用例成功,系统建立输入成绩记录。

否则，系统的状态没有变化。

当teacher输入成绩时，用例启动。

（1）检索学生。

（E-1）

（2）输入成绩。

（3）将选课成绩存储在系统中。

ET:

该学生不存在，系统显示提示信息，用例终止。

E-2:

系统中不存在该学生，系统显示提示信息，用例终止。

2.3.4更改成绩

在这个用例开始前，teacher必须登录到系统中。

如果这个用例成功,系统修改选课成绩。

否则，系统的状态没有变化。

（1）检索学生（E-l）o

（2）修改成绩记录。

（3）将修改记录存入系统

ET:

该学生不存在，系统显示提示信息，用例终止。

2.3.5维护学生信息

在这个用例开始前,Adminer必须登录到系统中。

如果这个用例成功,系统添加、修改或删除学生信息。

否则，系统的状态没有变化。

当Adminer想维护学生信息时，用例启动。

系统要求Adminer选择所想执行的活动（添加学生、删除学生、修改学生）。

如果所选的活动是“添加学生”，则执行分支流S-L添加学生。

如果所选的活动是“删除学生”，则执行分支流S-2：

删除学生。

如果所选的活动是“修改学生”，则执行分支流S-3：

修改学生。

S-1:

添加学生

（1）提供学生的信息，如姓名、学号等。

（2）系统存储学生信息（E-1）。

S-2:

删除学生

（1）提供学生的信息。

（2）查询学生（E-2）o

（3）查询学生的记录（E-3）o

（4）从系统中删除学生的信息，以及学生的选课记录。

S-3：

更改学生

（1）提供学生的信息。

（2）查询并显示学生的信息（E-2）,修改相应的信息。

（3）更新系统中学生的信息。

E-1:

若学生已存在，系统显示提示信息，用例终止。

E-2:

若查询不到学生，系统显示提示信息，用例终止。

E-3:

若无记录，系统显示提示信息，用例终止。

2.3.6维护教师信息

在这个用例开始前,Adminer必须登录到系统中。

如果这个用例成功,系统添加、修改或删除教师信息。

否则，系统的状态没有变化。

当Adminer想维护教师信息时，用例启动。

系统要求Adminer选择所想执行的活动（添加教师、删除教师、修改教师）如果所选的活动是“添加教师”，则执行分支流ST：

添加教师信息。

如果所选的活动是“删除教师”，则执行分支流S-2：

删除教师信息。

如果所选的活动是“修改教师”，则执行分支流S-3：

修改教师信息。

S-1:

添加教师信息

（1）提供教师名字、所教课程名等信息。

（2）在系统中添加该教师信息（E-l）o

S-2:

删除教师生信息

（1）提供所要删除的教师信息。

（2）查询所要删除的教师（E-2）o

（3）删除该教师的记录（E-3）o

（4）从系统中删除教师信息，以及相关的记录。

S-3：

更改教师信息

（1）提供教师信息。

（2）查询并显示教师信息（E-2）,并做相应修改。

（3）更新系统中的学生信息。

E-1:

若教师信息已存在，系统显示提示信息，用例终止。

E-2:

若查询不到该书老师，系统显示提示信息，用例终止。

E-3：

若无记录，系统显示提示信息，用例终止。

2.3.7维护系统信息

在这个用例开始前,Adminer必须登录到系统中。

如果这个用例成功,系统添加、修改或删除系统信息。

否则，系统的状态没有变化。

当Adminer想维护系统信息时，用例启动。

系统要求Adminer选择所想执行的活动（添加信息、删除信息、修改信息）。

如果所选的活动是“添加系统消息”，则执行分支流S-L添加系统信息。

如果所选的活动是“删除系统信息”，则执行分支流S-2：

删除系统信息。

如果所选的活动是“修改系统信息”，则执行分支流S-3：

修改系统信息。

S-1:

添加系统信息

（1）提供添加信息种类。

（2）查询信息种类（kind）,确定系统中已存在该书刊种类（E-l）o

（3）创建信息名。

（4）将系统信息存储到系统中。

S-2:

删除系统信息

（1）提供系统信息种类。

（2）查询信息名（newname）（E-2）。

（3）删除系统信息。

（4）从系统中删除系统信息后，并更新相关信息。

S-3：

修改物理学生信息

（1）提供系统信息种类。

（2）查询系统信息种类（kind）（ET）。

（3）查询并显示该系统信息的所有消息。

（4）选择信息名修改其信息。

（5）更新系统中系统信息的信息。

E-1:

若系统中不存在该信息种类，添加该书刊种类信息

E-2：

若存在该信息，则删除。

2.3.8登录

如果用例成功，参与者可以启动系统并使用系统所提供的功能。

反之，系统的状态不变。

当用户希望登录到系统中时，用例启动。

（1）系统提示用户输入用户名和密码。

（2）用户输入用户名和密码。

（3）系统验证输入的用户名和密码，若正确（ET）,则用户登录到系统中。

E-1:

如果用户输入无效的用户名和/或密码，系统显示错误信息。

用户可以选择返回基流⑹的起始点，重新输入正确的用户名和/或密

码；或者取消登录，用例结束。

第3章静态结构模型

进一步分析系统需求，发现类以及类之间的关系，确定它们的静态结构和动态行为，是面向对象⑺分析的基本任务。

系统的静态结构模型主要用类图和对象图描述。

3.1定义系统对象

系统对象的识别可以通过寻找系统域⑻描述和需求描述中的名词来进行。

从前述的系统需求描述中可以找到的名词有：

学生（student）、教师（teacher）管理员（adminer）,这些都是对象图中的候选对象。

判断是否应该为这些候选对象创建类的方法是：

是否有与该对象相关的身份和行为？

（1）学生（student）

学生是有身份的，具有相同名字和不同账号的两个人也是不同的。

在这个系统中，学生有相关的行为，学生可以选课、取消选课,所以学生应该成为系统中的一个对象。

（2）教师（teacher）

教师也有身份，具有相同名字和不同账号的两个人也是不同的。

在这个系统中，教师有相关的行为，教师可以上传成绩、修改成绩,所以教师应该成为系统中的一个对象。

（3）选课记录（courseload）

选课记录也有身份，选课记录可以被彼此区别，不会被搞混。

例如，同一个人关于不同课程的选课记录是不同的，同一门课程被不同学生的选课记录也是不同的。

（4）成绩记录（scoreload）

成绩记录也有身份的，成绩记录可以被彼此区别，不会被搞混。

例如，同一个人关于不同课程的成绩记录是不同的，同一门课程被不同学生的成绩记录也是不同的。

上述4个类都是实体类，都是持久性的，需要存储在数据库中。

本系统采用面向对象数据库⑼模型，为了便于从数据库文件中引用和检索对象，需要一个描述对象ID的类。

另外，由于上述4个类都是持久性类,因此还可以抽象出一个代表持久性的父类，该类实现了面向对象数据库文件的读、写、存储、检索、删除、更新等操作。

综上所述，系统中还应该有两个与数据库有关的类：

对象ID（OID）和持久类（Persistent）

（5）类Persistent

类Persistent是类student、teacher、courseload的父类。

类Persistent为商业对象的持久存储提供了支持，它的子类必须实现从数据库文件中读、写对象属性的操作。

（6）类0ID实现了对象ID。

类OID的对象可用来引用系统中的持久诬对象，使得从数据库文件中引用和检索对象变得容易。

抽象出系统中的类后，需要确定这些对象的属性和行为。

可以根据前述的系统需求分析、用例图、用例的事件流描述和描述脚本的交互作用图，来确定并细化系统中的类、类的操作和属性。

下面对系统中的类、类的属性及操作逐一进行描述。

（未标注返回值类型的方法使用缺省返回类型void）o

>类student属性、方法见下图3.1

>类teacher属性、方法见下图3.2

>类courseload属性、方法见下图3.3

>Scoreload属性、方法见下图3.4

>类Persistent属性、方法见下图3.5

>类0ID属性、方法见下图3.6

Student

RUM

Teacher

Name：

stnngstudentID:

stnngcourseloans:

OIDscorelloans:

OID

Name:

stnngteacherlD:

stnngcourseloans:

OIDscoreloans:

OIDNewteacherQFindteacherOGetteacherQAddcourseload（）GetcourseloansQDelcourseloansQWrite（）

ReadOSetcoursenameQSetcourselDOsetnameOgetIDOsetscore0

NewstudentOFindstudentOGetstudentOAddcourseload0GetcourseloansQDelcourseloans（）Write0ReadOSetcoursenameOSetcourselD。

setnameQgetIDOgetscoreQ

Courseload

NamestnngID:

integer

Newcourse0FindcourseODelcourse（）setIDOgetIDOwnte（）readO

图3.5类Persistent

图36类OID

在定义类、类的方法和属性时，建立动态模型的时序图是很有帮助的，类图和时序图的建立是相辅相成的，因为时序图中出现的消息基本上都会成为类中的方法，因此在设计阶段绘制系统的时序图时，要尽量使用类的已识别出的方法来描述消息，，若出现无法用类的已识别出的方法来描述的消息，就要考虑消息是否是类的一个待识别的方法，若是，就要将这个方法及时添加到类的操作类表中，并用这个新方法来描述消息。

3.2定义用户界面类

通过对系统的不断分析和细化，可识别出下述界面类、类的操作和属性。

（1）类MainWindow

MainWindow是系统的主界面，不同的用户登陆界面不一样。

系统的主界面具有菜单和菜单项，当选择不同的菜单项时，用户可以执行不同的操作。

当程序退出时，主界面窗口关闭。

（2）类studentDialog

界面类studentDialog是进行操作“添加学生”、“修改学生”或“删除学生”时所需的对话框。

当选择主窗口中的菜单项“添加学生”时，对话框弹出，学生成绩管理员输入学生信息，然后单击按钮“添加”，系统创建学生账户并将之存储在系统中。

当选择菜单项“修改学生”或“删除学生”时，对话框FindSDialog弹出，学生成绩管理员输入要修改或删除的学生的studentID,单击按钮“0K”提交。

系统查询数据库检索到学生信息后弹出对话框studentDialog,显示学生的详细信息，如若是“修改学生”，学生成绩管理员编辑修改学生的有关信息，然后单击按钮“更新”，更新系统中存储的学生信息；如若是“删除学生”，学生成绩管理员则单击按钮“删除"，系统删除所存储的该学生信息，当然，与该学生有关的其他信息业也一并删除。

（3）类FindSDialog

界面类FindSDialog是用来根据学生ID号查找学生的对话框。

当主窗口中的菜单项“删除学生”或“修改学生”被选择时，该对话框弹出，学生成绩管理员输入学生ID,单击按钮“0K”，系统查询数据库中具有指定ID号的学生信息。

（4）类teacherDialog

界面类teacherDialog是进行操作“添加教师”、“修改教师”或“删除教师”时所需的对话框。

当选择主窗口中的菜单项“添加

教师”时，对话框弹出，学生成绩管理员输入教师信息，然后单击按钮“添加”，系统创建教师帐户并将之存储在系统中。

当选择菜单项“修改教师”或“删除教师”时，对话框FindTDialog弹出，学生成绩管理员输入要修改或删除的教师，单击按钮“0K”提交。

系统查询数据库获取教师信息后弹出对话框teacherDialog,显示教师的详细信息，如若是“修改书种”，学生成绩管理员编辑修改教师的有关信息，然后单击按钮“更新”，更新系统中存储的教师信息；如若是“删除教师”，学生成绩管理员则单击按钮“删除”，该教师信息从系统中删除，与该教师有关的其他信息也一并删除。

（5）类FindTDialog

界面类FindTDialog是用来根据教师ID查找教师的对话框。

当主窗口中的菜单项“删除教师”或“修改教师”被选择时，该对话框弹出，学生成绩管理员输入教师ID,单击按钮“OK”，系统查询数据库中具有指定ID号的教师信息。

（6）类InpUDialog

界面类InpUDialog是进行输入成绩操作或更改成绩操作时所需的对话框。

当主窗口中的菜单项“输入”被选择时，该对话框弹出，教师输入分数，然后单击按钮“0K”，输入动作被确认，系统创建并保存成绩记录。

当选择菜单项“更改成绩”时，也弹出该对话框，教师输入学号,修改相应信息，然后单击按钮“更改”，系统中的更新记录。

（7）类ResCDialog

界面类ResCDialog是进行操作“选课”或“取消选课”时所需的对话框。

当主窗口中的菜单项“选课”被选择时，该对话框弹出，学生输入要选课的信息，然后单击按钮“选课”，选课动作被确认,系统创建并保存选课记录。

当选择菜单项“取消选课”时，也弹出该对话框，学生输入课程名及信息，然后单击按钮“取消选课”，系统中的选课记录被删除。

（8）类MessageWindow

信息窗口类LoginDialog是用来显示提示信息的对话框。

（9）类LoginDialog

界面类LoginDialog是用来输入用户名和密码的对话框。

>类MainWindow属性及方法见下图3.8

>类StudentDialog属性及方法见下图3.9

>类FindSDialog属性及方法见下图3.10

图3.8类MainWindow图3.9类BorrowerDialog图3.10类FindBwrDialog类TeacherDialog属性及方法见下图3.11

类FindTDialog属性及方法见下图3.12

类InpUDialog属性及方法见下图3.13

>类ResCDialog属性及方法见下图3.14

>类MessageWindow属性及方法见下图3.15

>类LoginDialog属性及方法见下图3.16

图3.11类TitleDialog图3.12类FindTDialog

图3.13类InpUDialog图3.14类ResCDialog

3.3建立类图

识别出了系统中的类后，还要识别出类间的关系，然后就可以建立类图了。

可将系统中的类分为3个包：

GUI包、adminer包和DB包。

包GUI由界面类组成，包Adminer由实体类组成，包DB由与数据库有关的类组成。

包GUI依赖于包Adminer和包DB,包Adminer依赖于包DB。

图3.18系统包图

3.3.1包GUI中的界面类关系

窗口MessageWindow和对话框studentDialog>FindSDialog>FindTDialog>teacherDialog>InpUDialog>ResCDialog是主窗口MainWindow的一部分。

它们之间存在组合关系。

类LoginDialog与类MainWindow之间存在"一对一”的关联关系。

类FindSDialog与类studentDialog之间是"一对一”的关联关系。

类FindTDialog与类teacherDialog之间的关系也是"一对一”的关联关系。

图3.19MainWindow

3.3.2包adminer中的实体类关系

类student、类teacher、类courseload、coreload都是永久类，它们都是包DB中的类Persistent的子类。

类teacher与类student之间存在“多对多”的关联关系，每个

teacher对象至少有一个student对象，每个student对象至少对应于一个teacher对象。

类teacher与类courseload之间存在“一对多的关系，tudent与类courseload之间存在“一对多”的关联关系，每个student对象可以没有或可有多个courseload（选课），每个courseload（选课）可由多个student选课，学