学生管理系统概要设计

学生管理系统
系统概要设计说明书
编写说明
标题：系统概要设计说明书
密级：内部
编辑软件：Microsoft Word 2000 中文版
版本历史：
编写目的：
为规范项目开发，对系统总体概要设计进行详细描述。

本文档由系科综合管理信息系统项目组维护，供本项目组使用。

目录
第1章引言 0
1.1.项目说明 0
1.2.项目定义 0
1.3.编写目的 0
1.4.参考资料 0
第2章总体设计 (1)
2.1概述 (1)
2.1.1设计目标 (1)
2.1.2业务处理范围 (1)
2.1.3性能要求 (1)
2.2运行环境 (2)
2.2.1软件环境 (2)
2.2.2硬件环境 (2)
2.3基本设计概念 (2)
2.4系统总体数据流图 (5)
2.5整体结构说明 (5)
2.6公用模块：系统登陆数据流 (6)
2.7相关业务工作数据流设计 (6)
2.7.1. 新生管理 (8)
2.7.2. 在校生管理与社团组织管理 (11)
2.7.3. 毕业生与校友信息管理 (18)
2.8运行设计 (22)
2.8.1运行模块组合 (22)
2.8.2运行控制 (22)
2.8.3运行时间 (22)
2.9人工处理过程 (22)
2.10外部接口设计 (22)
2.10.1用户界面设计 (22)
2.10.2硬件接口设计 (26)
2.10.3数据库接口设计 (26)
2.11系统出错处理设计 (26)
2.11.1出错信息 (26)
2.11.2补救措施 (26)
2.11.3系统维护设计 (26)
第1章引言
1.1. 项目说明
项目名称：学生管理系统。

项目提出单位：乐山师范学院计算机科学系。

项目开发者：乐山师范学院计算机科学系。

项目使用部门：乐山师范学院各系科(学院)。

1.2. 项目定义
系科综合管理信息系统是为了适应现代化学校管理的需要，加快推进我校数字化校园建设、充分利用校园网，利用网络、多媒体等计算机应用技术和手段，提高办公效率、改善质量的高效管理信息系统。

学生管理系统是系科综合管理信息系统的重要组成部分。

1.3. 编写目的
本文档为“乐山师范学院学生管理系统概要设计说明书”，主要用于为实现系统的功能而进行的系统设计的概要说明，描述在计算机上实现系统的的结构框架、数据流图及数据流说明字典，以对以后系统的建设起到指导和约束作用。

1.4. 参考资料
《学生管理系统_系统软件需求说明书》。

第2章总体设计
2.1 概述
2.1.1设计目标
✧实现学生信息资料的集中化电子化处理；
✧实现学生成绩的电子化处理；
✧实现普通用户的前台多媒体自助查询功能，公用信息在校园网
上自动发布；
✧实现学生管理工作制度化、标准化、规范化；
✧实现学生管理的其它必要的管理功能。

✧建立关于学生数据比较全面详细的数据库。

✧实现决策支持。

2.1.2业务处理范围
进行学生基本信息、扩充信息、成绩信息、在校的其它各种信息的集中电子化处理，实现主要系务业务流程的计算机管理，实现系科学生管理工作的自动化管理和公用信息在校园网上自动发布。

2.1.3性能要求
2.1.
3.1 时间特性要求
✧查询服务部分：用户通过多媒体电脑提交命令到返回不超过5
秒钟。

✧数据管理部分：提交一笔录入到结果返回不超过5秒钟。

排课
对资源不能满足排课要求时应首先予以提示，不能出现死循环无限等待。

2.1.
3.2 可扩充性要求
✧各种字典数据的编码要尽可能采用行业标准，自行编码也应合
乎规范，征得相关业务部门认可；
数据库的设计应考虑可扩充性，以适应今后学校发展和系统升级的需要。

2.2 运行环境
2.2.1软件环境
学生管理系统的设计与运行基于采用C/S网络应用环境运行于校园网上。

后台操作系统为Microsoft Windows 2000，数据库为Microsoft SQL Server 2000 ；Web服务器运行环境为Windows NT Server（SP6），浏览器为IE4.0以上版本。

数据查询服务部分采用B/S网络应用环境。

2.2.2硬件环境
服务器端包括一台标准服务器(也可用性能较好的普通PC服务器，数据库服务器、WEB服务器也可运行在同一台服务器上)。

PC 服务器要求CPU：PIII 600MHZ以上，内存容量大于或等于512M，硬盘容量大于或等于20G。

客户端包括多媒体电脑、PC客户机，要求多媒体电脑和PC客户机与上述PC服务器物理上连接畅通；
系科业务工作站桌面到校园网带宽要求至少为10M，保证连接畅快，最好有100M带宽。

2.3 基本设计概念
本系统主要业务在学生管理办公室进行，但也有部分业务在校园内其他部门进行（如查询等），或在校园外远程进行（如网上公开信息发布、信息查询等），所以本系统应是一个分布式、规模可变的系统。

数据集中在一个数据库服务器上，处理可能分布到应用程序的各层上，借助于校园网，各业务人员无障碍地实现分工协作，公共完成目标任务。

根据系统总体目标及技术成熟型、一般企业流行的体系结构，学生管理系统采用分层体系结构，具体划分为三层：表现层、业
务层和数据层，如下图所示：
1．表现层：用户和系统进行交互地层次。

通过键盘、显示器、鼠标、打印机等进行人工交互。

提供校园网内/外任何时间地点的访问支持（校园内借助于校园网；校园外借助于拨号上网）。

①应用基于网页的解决方案：即所谓的“瘦客户机”解决方案。

应用则借助于免费的浏览器如Internet Explore、NetScape等，仅需设计服务器端网页文件，勿需设计专用的前台的应用程序。

本解决方案主要应用于速度要求不高的简单场合，如一般的公共查询等。

②基于网络的EXE解决方案：即所谓的“胖客户机”解决方案。

编写前台源程序，编译成目标代码（EXE）文件。

本方案是本系统的主要解决方案，完成各种数据管理、数据处理以及速度要求高的特殊查询。

工作平台选用WIN9X，开发工具选用Inprise公司的Delphi 以及Microsoft公司的Visual Foxpro等。

2．业务层：即事务逻辑层或中间层，完成事物处理规则和业务流程约束数据的处理。

考虑到本系统问题的规模以及复杂程度、难度等，本系统业务层应用Microsoft IIS、FTP等完成业务层的功能。

3．数据层：即数据资源管理层，本层完成数据资源等的插入、
删除、更新修改等数据存储管理工作，还包括定义各种存储过程、数据约束等控制、触发器定义等。

更多的数据处理工作在“胖/瘦客户机”上进行。

在本系统中采用RDBMS来完成数据层功能，应用Microsoft SQL Serve来实现。

细化的系统结构图如下：
2.4 系统总体数据流图
系统总体数据流见下图：
系统中所有数据都存放在数据库Server中，客户机中要保存的数据必须上传到Server，交给Server来处理、保存。

Server与各前台终端是通过企业网总线通信的，主要机制是TCP/IP和HTTP协议，对用户名和密码的传输要采用SSL或其它加密机制（默认为DES算法）。

Server和后台数据库通过ADO、JDBC、T3协议（Weblogic默认的通信协议）进行通信，某些重要信息（如帐户、密码等）需要进行加密（DES）。

2.5 整体结构说明
整个系统主要有三大部分，前端主要管理活动，包括系统管理终端，数据操作终端，多媒体查询终端；中间是Web Server层，具体处理HTTP/ASP/SERVLET请求；后台是运行于Windows 2000下的数据库，包含操作员录入的数据、系统规定的对数据的约束和限制、系统管理用数据。

系统涉及到的各个子模块需求见《学生管理系统_系统
软件需求说明书》，设计重点是在后台数据库和数据管理程序模块。

各个模块的功能大不一样，涉及到的操作也不一样,但许多功能都是有相似之处的，除了多媒体查询终端以外，每个模块都有录入、修改、查询、删除、打印。

各模块均有登录机制、数据加密/解密,可将其做成公用模块。

由于管理需要，毕业学生的相关信息是不允许修改的，所以这里设计了结构完全相同两个数据库：当前库Dep_Computer和历史库Backup_Dep_Computer。

当前库中仅存储在校学生相关信息，历史库中存储各届毕业学生相关的全部信息。

这样做也使得当前库中数据永远不会太多，从而保证对当前库中数据增删改的速度。

历史库中数据会逐渐变大，但由于仅允许浏览且访问机会不多，所以不会影响系统运行响应速度。

2.6 公用模块：系统登陆数据流
各程序模块都将涉及登陆系统数据库问题，登陆时进行权限验证：从权限表中读取权限数据，与用户输入账号比较并确定其权限，将权限数据加密后发送到各数据管理功能模块。

说明：用户账号必须加密存储；非匿名用户的账号都不能是Windows 2000和SQL Server 2000的真实账号。

各功能模块必须、也只能通过系统总控模块的调用才能加载执行。

2.7 相关业务工作数据流设计
整个系务涉及的业务工作主要包括：新生录取报到处理、在校生基本管理、学生成绩处理与查询、学生社团组织管理、毕业生管理等方面，由此整个系统可划分为如下子系统/功能模块：
✧新生报到管理相关业务(系学生工作助理、辅导员等)；
✧在校生基本管理相关业务(系辅导员、班主任等)；
✧学生成绩汇总与查询相关业务(相关教师、教务干事)；
✧党团组织管理相关业务(学生工作助理、辅导员等);
✧毕业生信息管理相关业务(系主任、学生工作助理、辅导员、教务干事等)
✧校友信息管理相关业务（系主任等）
各子系统/模块数据流图分别设计描述如下：
2.7.1. 新生管理
1.数据流字典
(1)加工名称：招生数据转入
激发条件：招生工作完毕，新生数据下载到本地。

加工逻辑：将新生基本数据、体检信息和成绩导入在籍学生数据库中，并分配临时学号。

(2)加工名称：新生编班
激发条件：新生数据基本入库。

加工逻辑：将新生按专业进行分班，分班结果写回学生基本信息表中。

(3)加工名称：新生寝室安排
激发条件：新生数据入库
加工逻辑：按学校分配的寝室可用资源，将新生分配到可用寝室里，提供手工修改功能，并将结果写加数据库。

(4)加工名称：新生报到处理
激发条件：新生到校后，现场报到
加工逻辑：将新生报到情况记录在案，包括签到、组织关系转入否、户口交办否、体检完成否、饭卡、收费（欠费）情况等；以备进行欠费统计和报到统计。

(5)加工名称：欠费统计
激发条件：需要更新或查询新生的欠费情况
加工逻辑：更新或查询报到情况表，可以统计学生的欠费情况。

(6)加工名称：新生录取信息查询统计
激发条件：新生数据入库后，需要查询与统计新生的各种参数，包括统计性别、籍贯、民族、政治面貌、投档志愿和成绩等。

2.7.2. 在校生管理与社团组织管理
1．数据流字典
数据流图见后
2．加工说明部分
（1）加工名称：导出
激发条件：新生学号分配下来后，新生转为在校生。

加工逻辑：将新生临地库中数据导出为在校生基本信息库和扩充信息库。

（2）加工名称：困难学生信息入库
激发条件：收到学生递交的困难补助申请表并进行资格审查。

加工逻辑：将困难学生信息转入困难学生信息库。

（3）加工名称：勤工俭学信息入库
激发条件：收到学生递交的勤工俭学申请表并进行岗位分配。

加工逻辑：将学生勤工俭学信息转入勤工俭学信息库。

（4）加工名称：异动处罚
激发条件：学生受到相应处罚并产生异动情况。

加工逻辑：根据学生所受处罚后果进行异动信息记载。

（5）加工名称：欠费补交入库
激发条件：收到学生补交的欠费。

加工逻辑：根据学生补交欠费信息更新欠费信息表。

（6）加工名称：团员信息入库
激发条件：学生成为团员。

加工逻辑：将学生入团信息转入团员信息库。

（7）加工名称：党员信息入库
激发条件：学生成为预备党员。

加工逻辑：将学生入党信息转入党员基本信息库。

（8）加工名称：更新数据
激发条件：团员信息入库。

加工逻辑：更新团组织信息表和学生基本信息表相关内容。

16
社团组织管理数据流图
17
2.7.
3. 毕业生与校友信息管理
1．数据流字典（数据流图见后）
2．加工说明部分
（1）加工名称：择业意向统计
激发条件：学生毕业时，统计学生的择业意向
加工逻辑：通过网页形式发布或发放统计单，然后交由操作员将数据录入数据库。

（2）加工名称：就业去向处理
激发条件：学生就业去向已确定
加工逻辑：记载学生的毕业去向单位。

（3）加工名称：就业去向统计
激发条件：学生就业去向确定
加工逻辑：输出学生的就业去向表，并可按职业类别进行统计。

（4）加工名称：毕业档案档案材料记载
激发条件：需要清理学生的毕业所需档案
加工逻辑：记载学生的毕业档案情况，并完成统计。

（5）加工名称：毕业证书发放管理
激发条件：教务处毕业证书发放完毕
加工逻辑：记载学生的毕业证、学位证的发放情况，并记载相
应的发放日期、证书编号，如果未发放，记载原因。

（6）加工名称：学生综合情况（与校友）查询
激发条件：需要查询毕业生或校友的综合信息。

加工逻辑：查询毕业生的在校所有信息。

（7）加工名称：校友数据维护
激发条件：校友信息发生变化时。

加工逻辑：根据所掌握信息，及时修改校友信息。

系统概要设计说明
毕业生与校友管理数据流图
2.8 运行设计
2.8.1运行模块组合
系统运行需要后台数据库、WEB Server、系统总控、完成特定数据管理功能程序模块和HTML显示控制几个部分协同工作。

2.8.2运行控制
系统需要先启动数据库服务器，然后启动中间的WEB Server，启动无误后，各个用户就可以登录进入系统开始各种操作。

如前所述，为控制各数据管理用户对特定数据进行管理，各数据管理功能模块完全独立开发编译，但各数据管理功能模块不允许独立运行，只能在系统总控程序调度下执行。

2.8.3运行时间
后台DB服务器单独占用一个服务器，WEB&APP Server的事务处理量也比较大，需要一台单独的PC服务器。

前端用户需要的系统开销较小，普通的微机就可以了。

多媒体终端需要安装JRE运行环境，内存应该不小于128M。

正常情况下后台DB服务器、WEB&APP Server和浏览器终端是始终处于运行状态，其它终端可以随时起停。

2.9 人工处理过程
本系统需要人工处理的地方有数据库的建立和维护，数据表的建立和删除，这些需要有系统管理员的权限。

2.10 外部接口设计
2.10.1用户界面设计
①系统总控程序界面：系统总控程序相当于Windows的桌面，完成用户
身份验证，启动各数据管理程序。

②新生管理程序界面：完成新生从录取到进校报到的整个处理。

完成招生数据的导入、新生学号预分配、新生编班、寝室安排、报到入学现场办理、新生分布、新生成绩统计分析等。

③在校生管理程序界面：数据管理程序主界面是一个MDI窗体，以后的
每一项处理功能在子窗体中完成。

④党团组织管理程序界面：该程序界面也采用MDI窗体，所有功能在子
窗体中完成。

⑤学生成绩查询与汇总程序界面：该程序界面同样使用MDI来实现，既
可以实现多任务操作，也可以合理有效美观地安排界面。

⑥毕业生信息管理程序界面：采用简单界面设计。

系统概要设计说明
2.10.2硬件接口设计
要处理触摸屏接收触摸事件，将之转化为鼠标事件。

2.10.3数据库接口设计
采用ADO连接方式。

2.11 系统出错处理设计
2.11.1出错信息
建立系统运行日志，用于记录系统在运行过程中出现的可以预知的或无法判断的系统错误信息。

硬件的出错处理需要检查网络环境。

2.11.2补救措施
系统软件出错很容易在出错日志里看到，我们对可能发生的错误会有一个错误编号以及相应的处理方式，以手册的方式提供。

用户可以根据系统的提示信息进行相应的排错处理。

2.11.3系统维护设计
为便于维护，设计了三种日志：系统运行日志、操作日志、出错日志。

三种日志根据不同的重要程度采取存放在文件和数据库的方式，系统管理员可以很轻松地监控系统运行情况。

数据表的建立和删除有数据库系统管理员予以维护。