课程设计-UML-支持校园卡的食堂消费管理信息系统

课程设计-UML-支持校园卡的食堂消费管理信息系统

————————————————————————————————作者：————————————————————————————————日期：

统一建模语言

UML课程设计报告

——支持校园卡的食堂消费管理信息系统

目录

第1章系统需求分析 (2)

1.1 系统功能分析 (2)

1.1.1功能需求 (2)

1.1.2非功能需求 (2)

1.2 数据库管理模块 (3)

1.3 基本业务模块 (4)

1.4 信息查询模块 (4)

第2章系统的UML基本模型 (6)

2.1 UML初始模型 (6)

2.2 系统的用例图 (6)

2.3 系统的时序图 (7)

2.4 系统的协作图 (9)

2.5 系统的状态图 (10)

2.6 系统的活动图 (11)

第3章系统中的类 (15)

3.1 类图的生成 (15)

3.2 各类之间的关系 (16)

第4章系统的配置与实现 (18)

4.1 系统的组件图 (18)

4.2 系统的配置图 (20)

第5章小结 (21)

附录参考资料 (23)

第1章系统需求分析

1.1 系统功能分析

1.1.1功能需求

对于支持校园卡的食堂消费信息管理系统来说，应该至少包括如下几部分功能：（1）信息查询

系统在验证用户身份之后，允许用户根据需要进行查询。查询搜索的分类只要有三种：

对账号的基本信息查询时，主要通过连接数据库查询用户的账号、姓名、性别、卡类、单位、专业、备注信息。

对消费明细的查询时，可以查询最近30天内制定时期内消费明细，包括消费日期、具体时间、消费地点、消费金额、余额。

对充值明细的查询时，可以查询4年内制定时期内的充值明细，包括充值时间、交易金额、交易类型（柜台充值、网银充值、充值地点等）、操作员或交易号等。

（2）校园卡管理

挂失和解挂；

通知学生事务中心补办新卡，学生事务中心通知客户取新卡；

使用网上银行为校园卡充值，必须与网上银行连接，实现充值功能。

1.1.2非功能需求

（1）操作需求

系统可以在任何主流web浏览器上运行；

系统可以进行后台数据库管理。

（2）性能需求

系统可以满足每天24小时全年365天持续工作；

系统每天会在晚10点以后进行更新；

在8：00—22：00时段支持300位并发用户使用，其余时间支持150位。

（3）安全需求

由于系统涉及到个人财产安全问题，所以系统要求有很高的安全性；

系统包含对病毒、蠕虫和木马等病毒的防卫；

系统系统对登录用户进行身份验证，管理员对网站和后台数据库进行管理。

功能需求分析以后，可知满足上述需求的系统需要包括以下几个模块：

（1）数据库管理模块。数据库管理模块提供了使用者录入、修改并维护数据的途径。比如学生和老师都可以修改自己的基本信息，然后保存到数据库中；也提供了系统管理员进行用户信息维护的功能。

（2）基本业务模块。可以用校园卡消费、充值、也可以挂失和解挂，并在遗失以后旧卡的所有信息保留到新卡。

（3）信息查询模块。主要是对校园卡用户的基本信息查询，也可以对消费和充值的相关记录进行查询、浏览。

支持校园卡的食堂消费管理

信息系统

基本业务模块

数

据

库

管

理

模

块

信

息

查

询

模

块图1-1 系统功能需求

1.2 数据库管理模块

数据库模块包括如下图所示的几个方面：

数据库模块

用户注册信息管理消

费

明

细

信

息

管

理

充

值

明

细

信

息

管

理

图1-2 数据库管理模块功能

（1）用户注册的信息管理，包括教师和学生在系统上进行注册信息的更新操作，操作者可以是用户，也可以是系统管理员。

（2）消费明细信息管理，系统管理员在教师离职，或者学生学籍不存在时可以进行删除或者清空消费信息。

（3）充值明细信息管理，系统管理员在教师离职，或者学生学籍不存在时可以进行删除或者清空充值信息。

1.3 基本业务模块

基本业务模块包括如下图所示的几个方面：

补办新卡

基本业务模块

银

行

转

账

挂

失

解

挂图1-3 基本业务模块功能

（1）在校园卡丢失之后可以登录系统补办新卡。

（2）到指定的地方可以为校园卡充值，也可以进行网上转账。

（3）校园卡丢失以后可以挂失，防止别人用自己的卡消费。

（4）校园卡找到之后可以解挂，卡的状态从停用变为正常。

1.4 信息查询模块

信息查询模块主要用于网页上的信息浏览和查询，包括如下图所示几个方面：

信息查询模块

用户注册信息查询

用

户

消

费

明

细

查

询

用

户

充

值

明

细

查

询

用

户

账

户

余

额

查

询

图1-4 信息查询模块功能

（1）用户注册信息，通过网页登陆浏览、查询。

（2）用户消费信息，通过给定日期进行查询。

（3）用户充值信息，同样通过给定提起进行查询。

（4）用户账户信息，在查询消费信息和充值信息的时候在网页上都同时显示账户余额。

第2章系统的UML基本模型

2.1 UML初始模型

选择菜单【File->New】可以打开如下图所示的“Create New Model”对话框，选择J2SE模式，点击【ok】按钮，表示此系统将用Java语言来开发。

接下来开始设计自己的模型，在此之前先保存，将模型命名为“基于校园卡的食堂消费信息管理系统”，如下图所示：

图2-1 UML建模初始模型

2.2 系统的用例图

根据系统的需求可以确定四类参与者，分别是学生和教师、营业员、数据库、银行，参与者的详细信息如下：

学生和教师：是持有校园卡的任何个人，由于学生和教师登录系统之后只是浏览到的自己信息不同，所以可以将两者统称为用户，可以通过本系统查询个人的基本信息、某时间段的消费明细或者充值明细；可以办理校园卡挂失和解挂；可以通知注册中心补办新卡；可以到指定的地点为一卡通充值。

管理员:是校园卡的管理者，通过校园卡的服务器端进行管理工作。在客户端方面，接收用户充值的请求，并且接收系统的为用户办理新卡的通知。

数据库：是服务器端的数据库存储器，负责接收用户输入的信息，并将相应的信息显示给用户。

银行：是任何在网上开通网上银行的银行网上系统，可以接收用户输入的信息，并执行相应的数据处理服务，之后将处理结果传递给服务器端的数据库。

根据以上描述，可以确定系统用例图包括三部分登录系统、充值业务、其他业务。其中，用户登录的是客户端系统，管理员所登陆的是服务器系统。

识别用例：校园卡客户端系统的功能简单，只需要一层用例即可表示。根据系统的需求可以确定用例包括6个：查询信息（包括查询用户信息、查询消费信息、查询充值信息、查询余额四类信息）、挂失和解挂、补办新卡、银行转账充值、维护用户信息。

银行查询信息

挂失解挂

维护用户信息银行转账用户

数据库

补办新卡系统管理员

图2-2 系统参与者总的用例图

【用例说明】：

（1）查询信息：在用户登陆系统之后，查询注册信息、消费信息还有卡上余额信息用例，而且此用例的执行时依赖于后台数据库的。

（2）银行转账充值：可以根据卡号为校园卡直接进行网上银行转账充值。

（3）挂失和解挂：在用户登陆系统之后，可以办理挂失和解挂，在系统中提交办理挂失和解挂。

（4）补办新卡：在用户登录系统之后，提交补办新卡的请求，而在系统管理员进入系统之后可以受理用户补办新卡的请求将旧卡的信息完整复制到新卡上面去。

（5）维护用户信息：在系统管理员进入系统之后，对数据库中的用户信息进行更新操作，对离职的教师、毕业的学生信息做删除或者清空操作。

2.3 系统的时序图

本系统的时序图包括以下几个：

（1）查询信息时序图：

查询功能在用户打开查询界面后，对于基本信息查询，系统接收到学号后执行查询，并直接将数据库的信息显示给学生，相对的收到工号后执行查询，并将数据库中的信息显示给老师；对于消费明细查询和充值明细查询，用户输入开始和结束时间并确定查询后，数据库接收学号或工号、查询的开始时间和结束时间，执行查询，并将信息显示给用户。

: 用户登陆主界面查询界面输入信息界

面

数据库

1: 输入姓名密码

2: 进入主界面

3: 进入查询

4: 输入信息

5: 录入数据库

6: 信息显示

图2-3 用户查询信息时序图

（2）网银转账时序图：用户打开转账界面后，输入转账金额，然后确定转账，系统接收学号和金额跳到网银界面，当用户在网上银行转账成功后，网银将成功信息传给数据库，数据库保存数据成功后，将信息回显给用户。

: 用户登陆主界面转账界面转账信息输

入界面

网银数据库

1: 输入姓名密码

2: 进入主界面

3: 进入查询

4: 输入金额

5: 输入网银密码

7: 信息显示

6: 录入数据库

图2-4 网银转账时序图

（3）补办新卡、挂失解挂顺序图：用户打开挂失和解挂界面并确定该业务后，系统根据学号修改数据库信息，并将信息回显该用户。

: 用户登陆主界面挂失解挂界

面

补办新卡界

面

数据库

1: 输入姓名密码

2: 进入主界面

3: 挂失解挂

4: 补办新卡

5: 录入数据库

6: 信息显示

图2-5 补办新卡、挂失解挂时序图

2.4 系统的协作图

（1）用户登陆以后查找消费充值信息的协作图：

: 用户登陆查询消费充值

信息

: 数据库

1: 输入用户名密码2: 输入查询日期3: 查找信息

4: 返回要查找的信息内容

图2-6 查找信息的协作图

（2）用户登陆以后挂失、解挂校园卡的协作图：

: 用户登陆挂失解

挂

: 数据库

1: 输入用户名密码

4: 显示卡的状态

2: 输入身份证号3: 更改数据库中卡的状态

图2-7 办理挂失解挂的协作图

（3）用户登陆后进行网银转账的协作图

: 用户登陆银行转

账

: 数据库

1: 输入用户名密码2: 输入银行卡号3: 更改账户余额

4: 显示账户余额

图2-8 进行网银转账充值的协作图

2.5 系统的状态图

（1）数据库的状态图：数据库的状态比较复杂，刚开始处于空闲状态，接收到查询请求的时候进入查询状态，接收到更新数据请求的时候进入到更新数据的状态，这些操作都是在数据库中存储的表上进行操作的，当对表的操作结束，查询的信息提交给系统，数据库又恢复到空闲的状态。 正在更改数据信息更改卡余更改用户entry/ 接收更新数据请求

exit/ 更新数据结束无任务的空闲状态

exit/ 接收系统服务请求

entry/ 查询信息已提交系统...

正在查询

查询消费查询充值entry/ 接收查询请求

exit/ 查询结束查询用户信息信息

信息

查询余额额

信息接收查找用户信息的请求 / 查找存放用户信息的表

接收查找消费信息的请求 / 查找存放消费信息的表接收查找充值信息的请求 / 查找存放充值信息的表接收查询余额的请求 / 查找存放余额信息的表提交信息给系统

entry/ 对数据库表的操作结束

exit/ 信息已提交给系统[ 通过身份验证 ][ 网银转账成功 ]有查询信息的请求[ 登陆成功 ] / 查询

系统有更改数据的请求[ 登陆成功 ] / 更新数据

图2-9 数据库状态图

（2）校园卡的状态图： 校园卡从正常使用到已被删除，总共经历了如下几个状态。

未补办

exit/ 提交挂失请求

entry/ 解挂成功

entry/ 补办新卡成功

exit/ 账户不存在

挂失

entry/ 挂失请求被受理

exit/ 提交解挂请求

exit/ 提交补办新卡请求补办新卡entry/ 补办新卡请求被受理exit/ 新卡补办成功解挂

entry/ 解挂请求被受理

exit/ 解挂成功已被删除entry/ 账户信息被删除

图2-10 校园卡状态图

2.6 系统的活动图

在本系统中，用到的活动图有以下5个，所有的活动图均分为用户和系统两个泳道：

（1）登陆系统活动图：用户申请登录系统，接着系统要求输入密码，然后用户输入密码，最后系统判断用户名和密码的正确性，并由此响应是进入系统还是保留申请登陆状态。

提交登录申

请

输入用户名和密码

成功登陆

提示用户输入

姓名和密码

用户信息输

入错误 / 显

示登录失败

信息

输入正确 / 显示登录成功信息

系统

用户

图2-11 登陆系统的活动图

（2）转帐充值活动图：在成功登陆之后，首先用户申请转帐，然后系统要求用户输入转帐金额并选择银行，然后进入网银系统进行转帐操作，之后后，若转帐成功，系统修改数据库，最后将转帐成功信息提示给用户，否则提示用户失败信息。

进入到转账

页面

输入转账金

额

选择转账银

行

输入网银密

码

注销登录

提示用户输

入转账金额

提示用户选

择银行

提示用户输

入网银密码

输入密码错误 / 继续提示输入密码

增加校园卡中

相应的余额

提示用户转

账成功

减少银行卡

中的余额

银行

系统

用户

图2-12 转账充值的活动图

（3）查询消费信息的活动图：在成功登陆系统之后，先进入到查询消费信息的页面，输入指定的日期，系统开始查找数据库中的信息，显示给用户。

进入到信息

查询页面

输入要查询的开始日期和截止日期

合并

浏览返回信

息

注销登录

提示用户输

入日期

将查找请求提交

给数据库服务器

显示数据库

中的信息

提示用户对应

信息不存在

查找对应日期的数据

信息并提交给系统

分支

[ 信息存在 ]

[ 信息不存在 ]

数据库

系统

用户

图2-13 查询消费信息的活动图

第3章系统中的类

3.1 类图的生成

本系统所需要的类的确定只要考虑一下几点：

主要功能中，查询功能只需要通过学号访问数据库，转账业务、补办新卡和挂失解挂业务只需要通过学号修改数据库。

查询界面的功能只需要取学生卡号和查询信息的时间段（包括开始时间和结束时间）；补办新卡和挂失解挂界面只需要取学号即可；转账界面需要用到学号和金额信息；办理定期转账界面需要用到卡号和银行卡号、每次转账的金额。因此这些界面的功能都非常简单，所有的功能只要写在一个控制类里面即可。

对于用户的数据取得，需要用到数据库，由于数据库的查询修改删除工作所要编写的类本身就有一定量，故本系统的关于数据库的类都另外定义在实体类里面。

（1）定义系统控制类

控制类是主要负责其它类工作的类。如：主程序类、主窗体类。

本系统中的实体类有：用户登陆类（Login）和主程序类（Main）。

（2）定义系统边界类

边界类位于系统与外界的交界处。如：窗体类、报表类、描述通信协议的类、直接与外设交互的类、直接与外部系统交互的类。

本系统较简单，各个界面要实现的功能均由主程序实现，不需要专门的边界类。

（3）定义系统实体类

实体类描述要保存到持久存储体中的信息。如：数据库、各种形式的数据文件中的信息。

实体类有以下几个：

DataBase-负责连接数据库：

UserInfo、CostInfo、SaveInfo-查询基本信息、消费明细以及充值明细的数据库处理类

GetNewCard-补办新卡的数据库处理类

LostAndBack-挂失和解挂的数据库处理类

BankTransfer-银行转账的数据库处理类

Login-用户登录的类

3.2 各类之间的关系

各个类的操作都是依赖于数据库类的，所以在绘制类图的时候，把数据库类BataBase放置在中间，其他类围绕在其周围，与它都是依赖关系。

图3-1 系统类之间的关系图

【类图说明】：

上述的所有类中都包含有共同的参数，那就是String类型的传递给数据库的参数sql，里面存放的是传递给数据库的信息。

UserInfo是查询基本信息的类，可以查询数据库中的用户基本信息，属性包括用户的账户号等，操作包括查找用户信息的方法userInfoSearch()；

CostInfo是查询消费信息的类，里面新增了两个属性那就是开始日期和结束日期，用来确定所要查询的信息所在的时段，而操作函数costInfoSearch()的调用可以显示出消费信息和账户余额；

SavaInfo是查询充值信息的类，其构造和CostInfo类类似，也需要加入开始日期和结束日期，用来确定所要查询信息的时段，而操作函数costInfoSearch()的调用，可以显示出消费信息和账户余额；

Login是用户登陆类，必须包括的属性有用户名和密码，操作方法check()里面需要有连接到数据库的操作，验证登陆的用户是否存在于数据库中，验证用户输入的密码是否与数据库中的密码匹配；

LostAndBack是为用户办理挂失和解挂校园卡的类，必须包括的属性有State类型的参数，代表校园卡当前的状态，类里面还有两个操作方法get()、lost()分别调用，用来办理挂失和解挂；

GetNewCard是补办新卡的类，里面有的操作方法newCard()是用来将原来挂失的卡上的信息复制到新卡上的方法；

BankTransfer是办理网上银行转账的类，其中的属性bankName、bankID、Date是用来记录交易信息的，如交易银行的名字、交易号、交易时间，里面的操作方法bankTransfer()的调用可以为校园卡充值，并将余额信息存入到数据库当中；

DataBase是系统用来连接到数据库的类，里面有四个操作方法，openConnection()和closeConnection()者两个操作方法的设计是为了防止多个的用户并发访问数据库的时候出错，而Query()和Update()两个方法则是对数据库表中数据的操作，分别是查询和更新数据。