高校竞赛信息管理系统
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据库原理与应用课程设计
题目:高校竞赛管理系统
院系:学院
专业:
学生姓名:
指导教师:
2014年12月10日
目录
一、设计名称 (4)
二、设计目的及背景 (4)
三、系统功能设计 (5)
四、用户需求 (6)
4.1 参赛学生 (6)
4.2 校方信息管理员 (7)
4.3 终端信息管理员 (7)
五、系统功能的基本要求 (8)
5.1 参赛队伍信息模块 (8)
5.2 校方信息管理模块 (8)
5.3 终端信息管理模块 (9)
六、可行性分析 (9)
七、系统的运行环境 (10)
八、系统设计 (10)
8.1 总体概况流图 (10)
8.2 实体E-R图 (10)
8.3 全局E-R图 (13)
九、数据库设计 (14)
9.1 数据库概念设计 (15)
9.2 E-R图转换成关系模式 (17)
9.3 数据库逻辑设计 (18)
十、系统安全设计 (23)
10.1 用户登录 (23)
10.2 密码设置模块设计 (24)
十一、软件设计 (24)
十二、小结 (24)
参考文献 (25)
一、设计名称
高校竞赛管理系统
二、设计目的及背景
随着国家教育体制的改革,全国各地举办的大学生竞赛活动数目也是逐年增加,报名参加各个竞赛的大学生数量也是逐年地大批增长。
面对如此大的数目的参赛方信息的录入,原始的数据采集系统已经远远不能满足要求,如何利用现代信息技术使得举办方拥有快速、高效的参赛者信息反馈能力和高度的效率,已经是竞赛举办方特别关心的问题。
尽快建立一个功能齐备的高校竞赛信息管理系统,已成为当今社会举办高校竞赛的当务之急。
通过开发这个高校竞赛信息管理系统,使参赛者信息的录入和管理工作系统化,规范化,自动化,从而达到提高管理效率的目的。
本系统开发设计思想是实现竞赛信息管理的数字化。
尽量采用现有软硬件环境,及先进的管理系统开发方案,提高系统开发水平和应用效果的目的;系统应符合企业管理的规定,满足日常管理的需要,并达到操作过程中的直观,方便,实用,安全等要求;系统采用模块化程序设计方法,这样既便于系统功能的各种组合,又便于未参与开发的技术维护人员补充,维护;系统应具备数据库维护功能,及时根据用户需求进行数据的添加,删除,修改等操作。
随着计算机技术的飞速发展,计算机在系统管理中的应用越来越普及,利用计算机实现各个系统的管理显得越来越重要。
对于一些大
中型管理部门来说,利用计算机支持管理高效率完成管理的日常事务,是适应现代管理制度要求、推动管理走向科学化、规范化的必要条件;而竞赛信息管理工作又是是一项琐碎、复杂而又十分细致的工作,参赛者信息数量之庞大,一般不允许出错,如果实行手工操作,每个参赛队伍的情况须手工填制大量的表格,这就会耗费竞赛举办方管理工作人员大量的时间和精力,如果利用计算机进行这些管理工作,不仅能够保证各种核算准确无误、快速记录,而且还可以利用计算机对有关的各种信息进行统计,同时计算机具有手工管理所无法比拟的优点,例如:检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低等。
这些优点能够极大地提高管理的效率,也是管理行业的科学化、正规化管理,与世界接轨的重要条件。
该内容主要是竞赛信息管理用来满足参赛学生,校方和终端三方的需求,旨在建立一个高效的高校竞赛信息管理系统。
应用所学的有关知识,更深入地学习SQL Server数据库技术,将所学的书面知识和实际应用结合起来,以达到学以致用的目的。
三、系统功能设计
参赛队伍信息模块包括:参赛队伍成员的登录,以及对密码的修改;参赛成员查看本队详细信息,并对其有修改、删除权限;提交竞赛作品;查看该队竞赛作品信息的修改、删除权限;访问查询本校其他参赛队伍基本信息。
校方信息管理模块:校方管理员的登录、以及对密码的修改;对本校参赛信息的查询、统计权限;对参赛队伍信息的查看、修改和删
除权限。
终端信息管理模块:对所有参赛队伍进行编号;对全部队伍的参赛信息的查看、修改和删除权限;对全部提交的作品信息进行查询、统计、分类;对参赛队伍成绩输入、查看、修改和删除权限;对参赛队伍按其成绩进行查询、筛选、统计操作。
图1 系统功能设计图
四、用户需求
高校竞赛管理系统所涉及的用户包括:参赛学生、校方信息管理员、终端信息管理员。
4.1 参赛学生
4.1.1 根据其在比赛终端注册的登录用户名和密码进行登录,及对密
码的修改;
4.1.2 可对系统内部关于本队的内容进行查看、修改和删除;
4.1.3 可对竞赛作品提交信息的输入;
4.1.4 可对竞赛作品提交信息的查看、修改和删除;
4.1.5 可对该校其他参赛队伍的参赛状态进行访问、并且可以按照一
定的条件进行查询.
4.2 校方信息管理员
4.2.1 根据其在比赛终端注册的登录用户名和密码进行登录,及对密
码的修改;
4.2.2 按照一定的条件,对于该校参赛队伍信息进行查询、统计符合
一定条件的队伍信息;
4.2.3 根据需要对参赛队伍进行查看、修改和删除操作。
4.3 终端信息管理员
4.3.1 对全部的参赛信息按照一定的条件,对其进行查询、统计、分
类;
4.3.2 对全部的参赛信息进行查看、修改和删除;
4.3.3 对全部的作品提交信息按照一定的条件,对其进行查询、统计、
分类;
4.3.4 对没有提交作品的参赛队伍进行一定要求的查询,并在需要的
情况下进行删除操作;
4.3.5 对参赛队伍所得成绩的输入、查看、修改和删除操作;
4.3.6 对参赛队伍按照一定要求对其成绩进行查询、筛选、统计。
五、系统功能的基本要求
5.1 参赛队伍信息模块
5.1.1 在校报名学生(默认为队长)根据其在终端注册的账号,凭借
用户名和密码进行登录。
5.1.2 参赛队长对各种报名信息的输入。
包括院校信息,参赛组别,
作品名称,参赛队员信息(除队长外至多有两名队员):参赛
队员的姓名、联系方式、邮箱,导师信息,导师信息包括:导
师姓名、职称、所在院系、联系方式、邮箱。
5.1.3 参赛队长对报名信息的查看和修改。
5.1.4 参赛队长对竞赛作品提交信息的输入。
包括院校信息,参赛组
别,队伍编号,参赛选手信息,参赛选手的姓名、联系方式、邮箱、导师信息,导师信息包括:导师姓名、联系方式。
5.1.5 参赛队长对竞赛作品提交信息的查看、修改和删除。
5.1.6 参赛队伍对该校其他参赛队伍的参赛状态进行访问、并且可以
按照一定的条件进行查询。
5.2 校方信息管理模块
5.2.1 校方信息管理员根据其在比赛终端注册的登录用户名和密码
进行登录,及对密码的修改。
5.2.2 校方信息管理员按照一定的条件,对于该校参赛队伍信息进行
查询、统计符合一定条件的队伍信息。
5.2.3 校方信息管理员根据需要对参赛队伍进行查看、修改和删除操
作。
5.3 终端信息管理模块
5.3.1 竞赛终端信息管理员对全部的参赛信息按照一定的条件,对其
进行查询、统计、分类和初始编号。
初始编号是根据报名提交
时间的顺序对各个队伍编制队伍编号。
初始编号按照一定的编
码规则编制,对于全部队伍,其队伍编号是非空且唯一的。
5.3.2 竞赛终端信息管理员对全部的参赛信息在必要的情况下进行
查看、修改和删除。
5.3.3 竞赛终端信息管理员对全部的作品提交信息按照一定的条件,
对其进行查询、统计、分类。
5.3.4 竞赛终端信息管理员对没有提交作品的参赛队伍进行一定要
求的查询,并在需要的情况下进行删除操作。
5.3.4 竞赛终端信息管理员对参赛队伍所得成绩的输入、查看、修改
和删除操作。
5.3.5 竞赛终端信息管理员对参赛队伍按照一定要求对其成绩进行
查询、筛选、统计。
六、可行性分析
可行性分析是在系统调查的基础上,针对新系统的开发是否具备必要性和可能性,对新系统的开发从技术、经济、社会的方面进行分析和研究,以避免投资失误,保证新系统的开发成功。
可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。
该系统的可行性分析包括以下几个方面的内容。
技术可行性:硬件和软件的要求都不是很高,目前市场上的一般
计算机都可以满足系统开发的要求,维护工作也很方便,有一定经验的操作人员可以在短时间内掌握维护工作。
经济可行性:系统开发的成本:开发成本非常低廉,界面友好,操作简单,不需要投入大系统运行维护费用:系统将开发得十分完整,维护费用低。
管理可行性:只要在参赛者,校方和终端三方均配有计算机及相应的操作人员就可以完成对竞赛信息的管理。
社会可行性:随着计算机网络和信息技术,电子商务的发展壮大,当前竞赛信息信息化特别是参赛者信息录入与管理系统化成为必然,那将大大节省时间和人力,大大减少不必要的重复性工作。
七、系统的运行环境
Microsoft Windows XP,SQL Server数据库软件,不与网络相连。
八、系统设计
8.1 总体概况流图
图2 总体概况图
8.2 实体E-R图
本系统涉及到以下实体:
图3 “队伍”实体ER图
图4 “队长”实体ER图
图5 “队员1”实体ER图
图6 “队员2”实体ER图
“导师”实体ER图
图7
图9 “成绩”实体ER图
图10 “终端管理员”实体ER图8.3 全局E-R图
管理队长队伍
队伍编号
队员2
队员1校方管理员
导师终端管理员
身份证号
姓名
邮箱
身份证号
姓名
邮箱邮箱
手机号
姓名所在院系职称
指导终极管理
邮箱
身份证号手机号姓名
参赛组别
作品名称参赛
参赛
竞赛成绩初赛成绩
决赛成绩
报名
审核
管理
参赛状态
决赛
初赛
院校名称
1
1
1
1
1
n 111p m
p
n
p
n
n
图11 全局ER 图
九、数据库设计
9.1 数据库概念设计
9.1.1 数据库分析
根据对系统的可行性研究与需求分析以后,我们可以对系统的数据库进行设计,得到如下结果:
高校竞赛管理系统关系到的实体:
在高校竞赛管理系统中,对竞赛有兴趣的同学会主动报名,并且会根据组队情况出现分工,由队长做领队工作,此外,有两名队员,所以实体有“队长”、“队员1”和“队员2”;报名队伍都会对应有一个唯一的队伍号,在以后的作品提交和成绩审核中起着至关重要的作用,所以有“队伍”实体;每个参赛队伍都会有一个指导老师进行指导工作,比赛期间还需要指导老师协助一些相关的工作,所以有“导师”实体;每个报名院校都有校方管理员对该校参赛队伍的信息进行管理等操作,所以有“校方管理员”实体;从竞赛开始,到竞赛结束,历经初赛和决赛,其中初赛包括机试和作品评审,所以有“成绩”实体;终端管理员对所有院校的所有参赛队伍的信息进行管理和操作,所以有“终端管理员”实体。
综上所述,高校竞赛管理系统涉及最主要实体:队长、队员1、队员2、队伍、导师、校方管理员、成绩、终端管理员。
9.1.2 实体属性:
实体集“队伍”的属性包括:队伍编号、参赛组别、该参赛队伍的作品名称、队长姓名、队员1的身份证号、队员2的身份证号、指
导老师姓名、该参赛队伍所归属的院校名称;
实体集“队长”的属性包括:队长姓名、手机号、邮箱、性别、年级、所在院系、身份证号码;
实体集“队员1”的属性包括:队员1姓名、手机号、邮箱、性别、年级、所在院系、身份证号码;
实体集“队员2”的属性包括:队员2姓名、手机号、邮箱、性别、年级、所在院系、身份证号码;
实体集“导师”的属性包括:导师姓名、手机号、邮箱、职称、所在院系;
实体集“校方管理员”的属性包括:院校名称、队伍号、队长姓名、队长手机号、队长邮箱;
实体集“成绩”的属性包括:队伍号、初赛机成绩、决赛成绩;
实体集“终端管理员”的属性包括:院校名称、队伍号、队长姓名、队长手机号、队长邮箱、导师邮箱、师手机号、初赛成绩、决赛成绩、参赛状态。
9.1.3 实体之间的联系:
该比赛有多个组别,一个参赛队伍只能参加一个组别,一个组别里可有多个不同参赛队伍;
一个参赛队伍只有一个队伍编号,并且对应一个队长,有两名队员;
队长和队员都有与之对应的院系和其归属的院校;
导师都有其归属的院系以及其工作的职称;
一个队伍只能有一名指导老师对其进行指导,一名知道老师可以对多个队伍进行指导;
队伍号对应该参赛队伍的作品名称和参赛组别;
一个院校中只有一个校方管理员对该校的参赛队伍进行信息管理,一个院校可以有多个参赛队伍;
一个参赛队伍只有一个初赛成绩和决赛成绩,如果成绩无效,则该成绩为0;
一个队伍的参赛状态会随着竞赛的进度,其参赛状态发生改变,若该参赛队伍没有进入下一轮比赛,则其会被淘汰,淘汰伴随着竞赛的信息更新;
终端有多个终端管理员对所有院校的参赛信息进行管理;
9.2 E-R图转换成关系模式
队伍(队伍编号、参赛组别、作品名称、队长姓名、队员1的身份证号、队员2的身份证号、参赛状态、指导老师姓名、院校名称) 队长(队长姓名、身份证号码、手机号、邮箱、性别、年级、所在院系)
队员1(队员1姓名、身份证号码、手机号、邮箱、性别、年级、所在院系)
队员2(队员2姓名、身份证号码、手机号、邮箱、性别、年级、所在院系)
导师(导师姓名、手机号、邮箱、职称、所在院系)
校方管理员(院校名称、队伍号、队长姓名、队长手机号、队长
邮箱)
成绩(队伍编号、初赛成绩、决赛成绩)
终端管理员(院校名称、队伍编号、队长姓名、队长手机号、队长邮箱、导师邮箱、师手机号、初赛成绩、决赛成绩、参赛状态) 9.3 数据库逻辑设计
由以上数据库的分析,以及最后得出的关系模式可以设计出系统具体需要用到的表项,为了设计的需要与方便,每个参赛队伍的队伍号会根据其添加的时间先后对其进行编号,号码属性为自增1。
使用SQL sever 2005得到数据库关系图如下:
数据库表由以下列出各表项的详细说明:
队伍表
字段名属性约束条件说明备注Lnumber Char(8)非空队伍编号主键Ltype Char(1) {A、B、C、D} 参赛组别
Wname Varchar(10) 非空作品名称
Lname Varchar(10) 非空队长姓名
Lid Char(18) 非空队员1身份
证号
Lid Char(18) 非空队员2身份
证号
Ltname Varchar(10) 非空导师姓名LSname Varchar(15) 非空院校名称
Lstard Char(2) {报名、初赛、决赛} 参赛状态
队长表
字段名属性约束条件说明备注Lid Char(18) 非空身份证号主键Lname Varchar(10) 非空队长姓名
Lphone Char(11)非空手机号
Laddre Varchar(15)非空邮箱
Lsex Char(1) {男,女} 性别
Lgrade Char(6) 年级
Lacademy Varchar(13) 非空所在院系
队员1表
字段名属性约束条件说明备注Lid Char(18) 非空身份证号主键Lname Varchar(10) 非空队员1姓名Lphone Char(11)非空手机号
Laddre Varchar(15)非空邮箱
Lsex Char(1) {男,女} 性别
Lgrade Char(6) 年级
Lacademy Varchar(13) 非空所在院系
队员2表
字段名属性约束条件说明备注
Lid Char(18) 非空身份证号主键Lname Varchar(10) 非空队员2姓名Lphone Char(11)非空手机号
Laddre Varchar(15)非空邮箱
Lsex Char(1) {男,女} 性别
Lgrade Char(6) 年级
Lacademy Varchar(13) 非空所在院系
导师表
字段名属性约束条件说明备注Tname Varchar(10) 非空导师姓名主键Tphone Char(11)非空手机号
Taddre Varchar(15)非空邮箱
Ttitle Varchar(10) 职称
Lacademy Varchar(13) 所在院系
校方管理员
字段名属性约束条件说明备注Lnumber Char(8)非空队伍编号主键LSname Varchar(15) 非空院校名称
Lname Varchar(10) 非空队长姓名
Lphone Char(11)非空队长手机号
Laddre Varchar(15)非空队长邮箱
成绩表
字段名属性约束条件说明备注Lnumber Char(8)非空队伍编号主键Lpreli Float >=0,<=100 初赛成绩
Lfina Float >=0,<=100 决赛成绩
终端管理员表
字段名属性约束条件说明备注Lnumber Char(8)非空队伍编号主键Lname Varchar(10) 非空队长姓名
Lphone Char(11)非空队长手机号
Laddre Varchar(15)非空队长邮箱
LSname Varchar(15) 非空院校名称
Taddre Varchar(15)非空导师邮箱
Tphone Char(11)非空导师手机号
Ltotal Float >=0,<=100 初赛成绩
Lfina Float >=0,<=100 决赛成绩
Lstard Char(2) {报名、初赛、决赛} 参赛状态队伍表:该表是用来存储报名队伍的基本信息。
报名的队长添加记录后,则该队伍的全部信息都会存储到该表中,其中包括:队伍编号、参赛组别、作品名称、队长姓名、队员1的姓名、队员2的姓名、参赛状态、指导老师姓名、院校名称。
其中,队伍编号是主键,非空且唯一;其余信息除参赛组别取值于{A、B、C、D}和参赛状态取值于{报名、初赛、决赛},其它皆为非空。
队长表:该表是用来存储报名队长的基本信息。
报名的队长添加记录后,则该队长的全部信息都会存储到该表中,其中包括:队长姓名、身份证号码、手机号、邮箱、性别、年级、所在院系。
其中,队长的身份证号是主键,非空且唯一;其余信息除性别取值于{男,女}和年级可为空外,其他皆为非空。
队员1表:该表是用来存储队员1的基本信息。
报名的队长添加记录后,则该组队员1的全部信息都会存储到该表中,其中包括:队员1的姓名、身份证号码、手机号、邮箱、性别、年级、所在院系。
其中,队员1的身份证号是主键,非空且唯一,该主码是引用队伍关系模式中“队员1身份证号”的外码;其余信息除性别取值于{男,女}和年级可为空外,其他皆为非空。
队员2表:该表是用来存储队员2的基本信息。
报名的队长添加记录后,则该组队员2的全部信息都会存储到该表中,其中包括:队员2的姓名、身份证号码、手机号、邮箱、性别、年级、所在院系。
其中,队员2的身份证号是主键,非空且唯一,该主码是引用队伍关系模式中“队员1身份证号”的外码;其余信息除性别取值于{男,女}和年级可为空外,其他皆为非空。
导师表:该表是用来存储报名队伍导师的基本信息。
导师信息添加记录后,则该队伍导师的全部信息都会存储到该表中,其中包括:导师姓名、手机号、邮箱、职称、所在院系。
其中,导师姓名是主键,非空;其余信息除职称、所在院系可空,其他皆为非空。
校方管理员表:该表是用来存储报名队伍所归属的校方的全部报
名信息概况。
该校报名队伍信息添加记录后,则该校报名队伍的主要信息都会存储到该表中,其中包括:院校名称、队伍编号、队长姓名、队长手机号、队长邮箱。
其中,队伍编号是主键,非空且唯一;其余信息都为非空。
成绩表:该表是用来存储全部报名队伍的初赛决赛成绩。
待终端管理员根据参赛队伍的比赛情况添加成绩记录后,则该队伍的全部成绩信息都会存储到该表中,其中包括:队伍编号、初赛成绩、决赛成绩。
其中,队伍号是主键,非空且唯一;成绩都为浮点型,其中,初赛成绩、决赛成绩都取值在0~100之间。
当成绩为空时,默认为0。
终端管理员表:该表是用来存储高校竞赛全部报名队伍的初赛决赛成绩。
待终端管理员根据参赛队伍的比赛情况添加成绩记录后,则该队伍的全部成绩信息都会存储到该表中,其中包括:院校名称、队伍编号、队长姓名、队长手机号、队长邮箱、导师邮箱、师手机号、初赛成绩、决赛成绩、参赛状态。
其中,队伍号是主键,非空且唯一。
其余信息除参赛状态取值于{报名、初赛、决赛}和初赛成绩、决赛成绩取值在0~100之间,其他信息皆为非空。
十、系统安全设计
10.1 用户登录
程序启动后,首先进入系统登陆界面验证操作员密码。
系统登陆模块主要实现如下功能:
1、支持鼠标和键盘操作。
2、操作员和密码验证成功后,进入主界面。
3、操作员错误或密码错误提醒并返回错误点。
4、输入三次错误的密码,系统自动退出。
10.2 密码设置模块设计
程序启动后,选择“系统设置”菜单下的“密码设置”项,将进入密码设置模块。
在密码设置模块中主要实现设置完成操作员密码的修改、保存。
十一、软件设计
系统实现用户登录模块,设计后台代码使其拥有用户名密码辨别功能,登录系统后进入高校竞赛信息管理信息系统,选择信息管理的功能,点增加参赛队伍,可以进入添加新的参赛队伍信息,对队伍信息必填的信息必须写入,然后会弹出窗口提示添加成功。
把添加的队伍信息加入到全体队伍信息表中(此步骤由后台代码实现),添加参赛队伍信息后,可以进行全体信息初始化,选择信息管理项目可以进行信息管理功能:首先进行全体信息进行初始化,并能在信息列表查看,也可以在队伍信息列表中进行修改甚至删除。
点修改队伍信息操作后,进行此数据修改,可以实现修改信息的录入操作,并根据需要可在此进行数据修改和删除。
点排序操作后,可以将全体参赛队伍根据得分的多少进行排序。
以上就为使用各种软件最后的实现软件开发的初步设计思想。
十二、小结
通过此次的课程设计报告,让我们对SQL Server以及运用VB开发软件的全过程有了更深一层的认识,这要求我们要有严密的逻辑思维能力和良好的软件开发能力。
开发前的准备工作非常重要,首先应该定义好问题,接着分析其可行性,是否确实可行,再进行分析,理清各要素之间的关系,设计出大体的框架,并对各模块进一步细化,逐一开发出软件框架。
再对软件的各部分进行细节开发。
最后将各模块连接起来,进行综合的测试,对错误的进行修改并改进,尽所能地使设计更加完备。
在此次设计过程中,给我们印象最深的是逻辑思维性的重要性,如果事先没有正确的规划好,它就会给我们的课题开发带来严重的麻烦。
在这次设计中的结构的合理安排给我们带来了不小的经验教训。
虽然在软件设计中由于无法根据现有知识做出用户界面,但是通过数据库的添加删除修改查询等操作指导该如何将其运用到实际制作中,并制作出数据流图与功能模块图,对其掌握的更加充分,从而完成了这份报告。
参考文献:
[1] 谢世亮.Visual C#.NET2003开发与技巧[M]. 北京:清华大学出版社,2004.5.
[2](美)内格尔,《C#高级编程(第4版)》,清华大学出版社,出版2006年10月.
[3](美)solid,《SQLServer2005从入门与精通(应用技术基础)》,清
华大学出版社,出版2006年09月.
[4] 吴晨,《+SQL Server-数据库开发与实例》,清华大学出版社,出版2006年7月.
[5]李春葆,曾慧.SQL Server 2000学习与上机指导[M]. 北京:清华大学出版社,2005.6.
[6]张曜,张青函数实用手册[M]. 北京:冶金工业出版社,2002.12.
[7]张华.Visual C#程序设计教程与上机指导[M]. 北京:清华大学出版,2005.12.
[8](美)保罗《 2.0经典教程C#篇》人民邮电出版社,出版2007年5月.
[9]崔巍.数据库系统及应用[M]. 北京:高等教育出版社,2003.6.
[10]陈钟.C#编程语言程序设计与开发[M]. 北京:清华大学出版社,2004.7.
[11]李勇平 Web应用开发教程[M]. 北京:北京希望电子出版社,2005.4.
[12]杨帆技术与应用[M]. 北京:高等教育出版社,2004.7.
[13]东方华人数据库开发[M]. 北京:清华大学出版社, 2004.6.
[14]田原程序设计教程[M].北京:清华大学出版社, 2004.6.
[15]明月创作室精彩变成百例[M]. 北京:人民邮电出版社,2002.5.。