网上游戏充值系统设计与实现Word格式文档下载.docx

网上游戏充值系统设计与实现Word格式文档下载.docx

《网上游戏充值系统设计与实现Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《网上游戏充值系统设计与实现Word格式文档下载.docx（42页珍藏版）》请在冰豆网上搜索。

第1章前言

1.1系统开发的背景和目标

1.1.1系统开发的背景

伴随着21世纪的到来以及互联网的高速发展，互联网技术的进步也促使人们对网上消费的需求与日俱增，无奈人们所追寻的传统支付模式在日常需求上已难以满足，人们迫切的寻找更加方便高效的支付模式，电子商务在这样饱受期待的形势下诞生了。

以传统支付形式的银行为例，若在电子商务诞生之前，人们想进行消费，必须从银行的自动柜员机（AutomaticTellerMachine）进行现金提款等多种冗杂的手续，因此，通过互联网进行优化的金融服务诞生，众多的网络支付平台代替了传统的银行，在现代电子商务中有着举足轻重的地位。

目前各大企业都拥有自己的网上游戏充值系统，比如腾讯的微信以及阿里巴巴的支付宝，网上游戏充值同可以通过数字化的游戏充值管理模式对传统的游戏充值进行优化。

传统的游戏充值需要通过点卡或者电话卡的渠道进行充值，相对来说不是特别便捷，当用户想要更快的进行充值而又不想出门购买点卡，网上游戏充值系统就体验了其便捷性，用户可以做到足不出户的完成充值，并且网上游戏充值系统对于充值的稳定性、安全性具有一定的保障，免除了纸质充值会出现的诸如二次使用、点卡消失等问题。

一个好的网上游戏充值系统对于充值的规范管理相当严格，加快充值速度、充值处理过程、跟踪充值进度、查看充值情况等都具有不可估量的意义。

但是某些游戏仍存在进行点卡出售的充值情况，已经无法满足该游戏用户的高效充值需求。

而且在如今快节奏的生活下，人们或许会更少的去指定的店面购买点卡，所以该网上游戏充值系统的目的就是为了方便这类仍在使用点卡充值的玩家，做到足不出户即可充值。

1.1.2系统开发的目标

本系统以充值用户群体为主要服务对象，以管理员辅助为辅，实现用户的登录、注册、充值、查询的一系列功能选择，在足不出户的情况下，也能够自由方便的完成充值活动，并且保护用户的个人信息不被外泄，保证系统的安全性、可靠性，促进玩家对网上游戏充值的良好体验，提升玩家的普遍满意度。

包括登录注册功能、充值功能、订单查询功能、管理员后台登录功能、管理员发布充值项目以及修改充值项目功能、管理员查看用户个人信息功能。

1.2系统的主要功能和特点

网上游戏充值系统主要以用户（充值用户）和管理员两类服务对象分为两大界面。

1.用户（充值用户）

以用户为角色，用户拥有登录注册功能、充值功能、修改个人信息功能、联系管理员功能、查询订单功能。

用户的充值功能包括账户充值以及游戏充值。

由于用户初始账户余额为0，则需要先往自己账户中进行充值，才可进行接下来的操作，否则在进行游戏充值的时候，会显示账户余额不足导致充值失败。

用户的查询订单功能可以通过关键词搜索充值订单。

关键词搜索包括用户名、邮箱、充值时间等。

2.管理员管理功能

以管理员为主要角色，管理员拥有登录功能、数据分析功能、管理用户功能、管理充值功能、修改管理员密码功能、管理联系功能。

登录功能需要在后台中创建超级管理员，并输入指定代码对数据库表进行更新，再使用创建时的账号密码进行后台登录。

数据分析功能通过对数据库数据的导入来进行排序、绘图等操作。

管理用户的个人信息：

帐号、密码、充值项目、充值金额、充值订单、性别、邮箱

管理充值功能包括查看用户的充值订单记录，充值订单信息包括用户名、邮箱、充值金额等。

1.3设计开发的方法和工具的选择

了解用户对网上充值的需求，按照需求分析、系统分析、系统设计的步骤，并以完成系统实现为目标进行开发一个网上游戏充值系统。

本系统利用python语言作为编程语言和MySql数据库，有效地解决了网上游戏充值系统对于数据稳定性、数据统一性以及其系统运行效率等功能性的问题。

而本系统使用的开发软件是时下比较流行的pycharm，数据库软件是Navicat，开发环境则是普遍应用的微软Windows操作系统；

对于系统的后端开发，本系统使用的是python中的Django框架进行设计，并且巧妙结合bootstrap、html、css的前端页面设计开发，对网上游戏充值系统进行搭建设计。

第2章系统规划

2.1初步需求分析

网上游戏充值系统将利用计算机技术对充值内容进行高度整合，降低管理成本，更加便捷用户的操作使用，实现对充值过程的管理，大幅度地降低用户所需的充值时间，提高用户充值效率。

解决了传统线下充值、购卡充值等时间耗费大的问题，使用户从有充值需求到充值活动完成所需时间大幅度缩短，提升客户的充值体验。

2.1.1功能需求

从对用户的需求分析来设定系统的目标要求，从而得到系统所需实现的主要功能包括对用户的信息管理、用户的充值管理、管理员后台管理等信息进行管理。

对于系统而言，用户的权限分为管理员、用户（指充值用户），以下是从管理员和用户两个不同角色对系统的功能需求进行详细介绍。

（一）admin管理员对系统的功能需求：

1登录系统

管理员需要在开发软件中建立一个超级管理员，通关对数据库表的更新后来使用创建时的用户名以及密码登录管理员后台。

2用户信息管理

管理员可对各个用户信息进行增删改查的功能操作，可修改的用户信息包括用户名、邮箱、手机号、性别、用户权限、余额但不包括密码。

管理员可进行编辑余额、用户权限禁用/启用（通过1/0显示）、删除操作，数据库中的用户表也会进行数据更新。

③充值管理

管理员对充值订单进行添加、删除、查看、修改的充值管理功能模块。

可修改的充值订单信息包括用户名、充值金额、邮箱、手机号、充值项目，数据库中的充值表也会进行数据更新。

④修改密码

管理员对管理员自身账户密码进行修改的功能。

修改密码的同时会在生成的超级管理员表里更新。

⑤网站联系管理

管理员对联系信息进行添加以及删除的联系信息模块。

联系信息包括管理员在后台设置的邮箱以及电话。

⑥数据分析

管理员通过从数据库中读取到数据进行分析，并在开发软件中对数据进行可视化操作的过程。

（二）用户对系统的功能需求：

1　账户充值

用户在进行其它充值操作之前，必须先对自己的账户进行充值的功能模块。

包括用户名、邮箱、手机号、充值金额、充值方式。

2　游戏充值

用户对游戏项目进行充值的功能模块。

包括充值项目、用户名、邮箱、手机号、充值金额。

3　查看充值订单

用户对充值订单查询的功能模块。

查询的信息包括用户名、充值项目、充值金额、邮箱、充值时间。

4　个人信息修改

用户对个人信息进行修改的功能模块。

用户修改完成个人信息后会提示要求重新登录。

5　联系网站开发人员（管理员）

用户进行联系管理员的功能模块。

用户可以看到管理员的邮箱以及电话。

2.1.2非功能性需求

非功能性需求是指用户对于系统功能以外的需求，覆盖面比较广，本系统主要包括安全可靠性、可维护性与可扩展性以及有效性。

为了确保系统能够在一定时间内稳定运行，设计开发人员必须从系统设计开发环节对系统进行全方面的优化改良。

网上游戏充值系统除了提供必要的功能需求外，还应该满足可维护性、可扩展性和稳定性的性能需求。

（1）安全可靠性

随着信息化时代的到来，用户对个人的隐私信息问题更加的看重。

由于网上充值系统涉及到用户们的经济利益，因此有一个优秀的安全性可以给予用户极大的信息安全感。

本系统分为用户登录和管理员登录两个登录模块，在用户注册时系统将会设定不同的用户权限进入到相对应的页面，例如用户只能登陆对应的用户充值主页，而不可直接进入管理员后台；

而管理员也需要认证自己是否是系统的超级管理员，才可进入后台进行管理活动。

用户通过填写自己的账号和密码登录来验证用户身份，以此来确保网上游戏充值系统的准确性以及安全可靠性。

（2）可维护性与可扩展性

网上游戏系统能让用户通过互联网的自由性以及高效性，大幅度提高充值效率。

但倘若用户在使用时若系统出现错误，将会对用户造成很大的充值体验影响；

因此，拥有一个良好的可维护性，是本系统在开发过程中所不能忽视的重要环节之一。

并且若日后用户对系统有更加迫切的需求，在管理员必须对系统进行扩展的情况下，系统是否具有可扩展性将决定一个系统的上限，所以本系统将会围绕可维护性和可扩展性进行设计。

（3）稳定性

系统在一定时间内保持良好的运行，避免因为系统自身原因导致崩溃以至于用户无法进行充值，所以本系统将具有一定的稳定性。

2.2可行性分析

2.2.1技术可行性

本系统使用的是python作为开发语言，加以使用python内的Django框架来设计系统。

在windows系统环境下进行开发，数据库使用的是xampp的MySql，并且以JSPCSS为前端作为技术支持。

2.2.2经济可行性

该系统就是以节省充值用户群体时间为主要目的而设计的，虽然在该系统的开发过程中需要耗费一定的时间精力，但是在系统实现之后，将大大地减少充值用户群体时间的消耗，提高充值效率，减少充值过程中的漏洞，通过人、财、信息的统一管理，有效提高网上游戏充值管理效率，为用户群体带来明显的时间收益。

2.2.3操作可行性

该系统的界面设计为电脑端（网页端）。

用户可以从任意一个浏览器访问本系统，其UI设计与操作上手度都与大部分充值网页类似,让用户有一种熟悉感，以便于更好的轻松掌握，不会导致用户因为操作起来感受到困难而放弃使用本系统。

第3章系统分析

3.1功能分析

3.1.1系统用例图

用例图体现参与者从外界使用系统时与用例的关联关系，用例则是以实现参与者的功能需求为目标而生成的。

网上游戏充值系统主要有管理员、用户两个参与者。

（1）管理员是从后台对网上充值系统的信息进行管理，包括登录系统（需验证权限）、数据分析（从后台爬出数据并绘制图形）、用户管理（查看用户列表、增删改查用户信息）、充值管理、修改密码、联系管理。

管理员用例图，包括用例的扩展以及包含关系进行设计，如图3-1所示。

图3-1管理员用例图

（2）用户主要是使用网上游戏充值系统进行充值的过程，包括登录系统、账户充值、游戏充值、查看个人订单、修改个人信息、联系管理员的功能。

用户的用例图，如图3-3所示。

图3-2用户用例图

3.1.2用例规约

用例规约是对用例进行阐述的一个步骤，优秀的用例规约能够更加精确展示出用例的详细内容，让用户和开发人员能够更清晰地了解用例。

以下用例规约中的层次主要分为风筝层和海平面层。

（1）管理员对用户信息进行管理操作的用例规约，如表3-1所示。

表3-1管理员对用户信息进行管理操作用例规约

用例名称：

管理员对用户信息进行管理操作

主参与者：

管理员

层次：

风筝层（概要）

利益相关者：

管理员、用户

前置条件：

管理员访问系统

最低保证：

回滚任何未完成的事务

成功保证：

管理员成功登录进入系统

触发器：

系统中有用户信息生成

主要的成功情节：

管理员对用户信息进行修改

相应的用户账号信息发生改变

扩展：

1.a修改用户信息失败

1.a.1事务回滚，重新进行修改

2.a网页突然出现异常

2.a.1网页回滚到异常前的页面。

3.a管理员退出系统

3.a.1网页回滚到管理员退出前的页面。

（2）用户充值（账户充值以及游戏充值）的用例规约，如表3-2所示。

表3-2用户充值的用例规约

用户充值

用户

海平面层

用户访问系统

用户成功登入系统

用户打开充值页面

1.充值项目对应的充值订单生成。

2.用户的账上余额减少。

1.a用户充值失败

1.a.1用户余额不变，事务回滚至充值前

2.a网页出现错误

2.a.1用户余额不变，网页回滚至充值页面

（3）管理员对充值信息编辑的用例规约，如表3-3所示。

表3-3管理员对充值信息编辑的用例规约

管理员管理充值订单信息

风筝层

用户充值成功

管理员成功登入后台系统

管理员打开充值订单信息管理界面

1.管理员对充值订单信息成功编辑。

2.用户对应的充值订单信息发生变化。

1.a编辑信息失败

1.a.1事务回滚，重新进行编辑。

2.a网页出现异常

2.a.1事务回滚，回到管理员编辑前的界面。

（4）用户查询充值订单信息的用例规约，如表3-4所示。

表3-4用户查询充值订单信息的用例规约

用户查询充值订单信息

海平面

用户成功查看到充值订单信息

用户打开充值订单信息界面

1.用户点击查询按钮

2.用户核对充值订单信息

3.用户进行核查结束并退出系统。

1.a数据保存失败

1.a.1事务回滚，回到上一个操作页面。

1.a.2数据保存失败，用户退出系统。

（5）用户对个人信息进行修改行为的用例规约，如表3-5所示。

表3-5用户对个人信息进行修改行为的用例规约

用户修改个人信息

用户、管理员

用户成功注册并登入系统

用户成功修改个人信息

用户打开修改个人信息界面

1.用户对个人信息进行修改并点击保存。

2.用户信息成功更新到数据库并在网页上显示

1.a修改个人信息失败。

1.a.1用户重新加载页面并再次进行修改。

1.a.2页面加载失败，用户退出系统。

3.2UML静态建模

3.2.1概念数据模型

概念数据模型是面向对系统有需求的用户而生成的，可以让用户了解到信息世界对于某一个单位的概念化结构描述；

而对于数据库设计人员来说，可以在开发初期阶段对整个现实大致的进行了解，对每一个用例之间的关系进行整合归纳，以便于后期数据库设计时更好的开发。

（1）网上游戏充值系统的概念数据模型，如图3-5所示。

图3-5网上游戏充值系统的概念数据模型

3.2.2对象关系模型

从概念数据模型得到各类类名以及其属性，通过面向对象和三范式的设计方法，从而映射到对象关系模型中，目的是能够让数据库结构设计能够更简单明了。

在对象关系模型中，括号外的是类名，括号内是类的属性，主键为下划线部分，外键为波浪线部分。

User（name,password,email,phone,sex,user_role,balance,c_time）

Login_user（id,name,password,email,phone,sex,user_role,balance,c_time）

Auth_user（id,password,last_login,is_superuser,username,first_name,

last_name,email,is_staff,is_active,date_joined）

Crawl_recharge（id,name,amount,email,phone,project,c_time）

Django_admin_log（id,action_time,object_id,object_repr,action_flag,change_message,conteng_type_id,user_id）

Contact（id,email,phone）

Captcha_captstore（id,challenge,response,hashkey,expiration）

3.3动态建模

3.3.1顺序图（时序图）

顺序图是一种描述参与者与用例之间交互关系的二维图，能够用来表示用例中的行为顺序以及参与者在使用这些用例时会产生的事件流的接受和传递过程，还表示了对象之间传递消息的时间顺序，称之为顺序图（时序图）。

（1）用户进行充值用例的参与者是：

用户，用户将登陆请求传递给了边界类:

充值界面。

控制类为：

Crawl_rechargeController，控制对象将更新数据的任务传递给了实体类：

User。

用户充值的顺序图，如图3-6所示。

图3-6“用户进行充值”用例的顺序图

（2）“管理员对用户信息进行管理操作”用例的参与者是：

管理员，管理员将登陆请求传递给了边界类:

管理员主页。

django_admin_loginControl，控制对象将管理员确认修改信息的请求传递给了实体类：

User、Auth_user。

管理员修改信息的顺序图，如图3-7所示。

图3-7“管理员对用户信息进行管理操作”用例的顺序图

3.3.2通信图

（1）用户充值的通信图，如图3-8所示。

图3-8“用户充值”用例的通信图

（2）管理员修改信息的通信图，如图3-9所示。

图3-9“管理员修改信息”用例的通信图

3.3.3分析类图

（1）网上游戏充值系统分析类图，如图3-10所示。

图3-10网上游戏充值系统分析类图

3.3.4活动图

（1）管理员修改信息活动图，如图所示。

（2）用户充值活动图，如图所示。

第4章系统设计

4.1功能结构设计

本系统的对象主要分为管理员以及用户。

管理员和用户都具有最基础的登录功能，不同的是，管理员主要通过后台对前端数据进行管理处理操作，所以在登录时会有权限验证；

而用户主要是通过登录入前端界面实现自己的目标功能需求操作。

两者的功能模块如下所示。

网上游戏充值系统的功能结构图，如图4-1所示。

图4-1网上游戏充值系统的功能结构图

4.2数据库设计

数据库的设计是系统设计过程中最关键的一环，数据库的设计是否合理将决定一个系统的各个类或者功能能否紧密并且有逻辑的结合起来。

因此，我们要遵守数据库设计的最基本原则，每一个实体要唯一对应一个表，每个表要确定其属性的数据类型和字段大小，清楚表与表之间的关联。

从系统需求分析部分，数据库中建立的表如下所示，主要有系统生成的账户表User,登录注册表Login_user，超级管理员表Auth_user，用户充值表Crawl_recharge，联系表Contact，验证码表Captcha_captchastore,管理员修改个人信息表django_admin_log,它们的具体设计分别如各数据表所示。

（1）系统User数据库表的设计，如表4-1所示。

表4-1User表

字段名称

数据类型

是否为空

大小

描述

Name

varchar

否

255

用户名

Password

用户密码

Email

邮箱

Phone

电话

Sex

性别

User_role

用户权限

Balance

varch