学生管理系统_系统概要设计说明书

学生管理系统

系统概要设计说明书

乐山师范学院计算机科学系Attract工作室

2003/07/30

编写说明

标题：系统概要设计说明书

密级：内部

编辑软件：Microsoft Word 2000 中文版

版本历史：

编写目的：

为规范项目开发，对系统总体概要设计进行详细描述。

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

目录

第1章引言 (1)

1.1.项目说明 (1)

1.2.项目定义 (1)

1.3.编写目的 (1)

1.4.参考资料 (1)

第2章总体设计 (2)

2.1概述 (2)

2.1.1设计目标 (2)

2.1.2业务处理范围 (2)

2.1.3性能要求 (2)

2.2运行环境 (3)

2.2.1软件环境 (3)

2.2.2硬件环境 (3)

2.3基本设计概念 (3)

2.4系统总体数据流图 (6)

2.5整体结构说明 (6)

2.6公用模块：系统登陆数据流 (7)

2.7相关业务工作数据流设计 (7)

2.7.1. 新生管理 (9)

2.7.2. 在校生管理与社团组织管理 (12)

2.7.3. 毕业生与校友信息管理 (17)

2.8运行设计 (20)

2.8.1运行模块组合 (20)

2.8.2运行控制 (20)

2.8.3运行时间 (20)

2.9人工处理过程 (20)

2.10外部接口设计 (20)

2.10.1用户界面设计 (20)

2.10.2硬件接口设计 (24)

2.10.3数据库接口设计 (24)

2.11系统出错处理设计 (24)

2.11.1出错信息 (24)

2.11.2补救措施 (24)

2.11.3系统维护设计 (24)

第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）加工名称：更新数据

激发条件：团员信息入库。

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

15

16