校车运营系统(4).doc

[键入文字]

一．引言
重庆大学校车主要为重庆大学师生提供往返A、B、C、D 4个校区服务的交通工具。目前，校车的运营状况基本稳定，但离科学化，高效率的运营还远远不够，存在的主要问题有：1.没有设立统一的调度控制中心，缺乏宏观全局化的调控；2.调度作业基本人工完成，导致作业人员劳动强度高，效率较低，且调度人员工作辛苦；3.发车制度机械，缺乏机动性和灵活性，无法快速响应各种突发状况；4.无法对校车进行实时跟踪监控，不能有效处理紧急情况；5.校车管理机制不完善，导致学生和老师用车紧张；6.校车运行线路单一，一旦路面出现状况将会造成时间损失。正是因为以上存在的各种问题，导致学生对校车管理怨声载道。
为了解决现有校车运营系统中的各种缺陷，我们设计了智能化的校车管理信息系统，它能够实现以乘客需求为主导，通过采集乘客的需求信息，经计算机通信网络传输至监控中心供调度人员安排调度车辆，从而提供了整个系统的工作效率和服务质量。而且在数据记录方面也不需要再采用原始的手工记录，可以由信息系统自动生成，大大减少了管理人员的工作量。

二．需求分析
2.1任务描述
本系统功能及目标如下：
1）建立车队综合信息库，包括车辆信息、驾驶员信息等，将车队业务最大程度地实现电子管理；
2）提高工作效率，降低管理成本，简化流程操作，利用友好的界面和简易的操作，轻松高效地完成工作；
3）采集车辆运行信息，统计和分析数据，并据此发布客流量信息，方便师生员工有针对性地选择乘坐；
4）开通信息交流平台，提供包车预定服务，并接收师生员工反馈信息，提高服务质量。
2.2 用户特点
在本系统中用户主要是师生，他们只能通过可视化界面对数据库信息进行查阅并在允许的范围内增添相关预约记录，修盖个人密码，而不能在数据库中进行其他任何非法操作。只有管理人员经过身份验证才可以进入，并对其进行相关操作。本产品的维护人员需要具备和SQL Server2000数据库编程知识。
2.3需求获取
该受理操作分配及督办功能模块的编写目的是为了将所受理业务具体分配到各个工作人员，并做一些必要的处理。为了对该系统提出完整、准确、清晰、具体的要求，必须在这个阶段明确系统的功能结构，在高层功能及数据流图的基础上进一步细化系统的功能，开发出更精确的数据流图，同时建立数据字典，最主要的是明确该管理系统要完成哪些功能模块，即要明白“系统要做什么，用户需要什么”。需求分析的结果是系统开发的基础，关系到开发该系统的成败和质量。因此必须在用户提出的要求上抽象出该系统的功能结构。
2.4信息采集
在预约系统的查询功能模块中应录入单日发车的安排表，即每一车次所对应的发车时刻，在预约系统的预约功能模块中应录入重庆大学师生的基本信息（学号，姓名等），在预约系统的付费功能模块通过网络技术与校园卡系统相连接，只有从校园卡中扣费后才算预约成功。
在调度员操作系统中，显示器上将显示预约人员的基本信息，方便确认预约人员的身份。
在后台的调度监控中心录入了所有校车的基本信息（车牌号，车辆类型等），以及驾驶员的基本信息（姓名，编号等）和发车时刻表等。
2.5建议校车管理系统的功能
1）用户登录：分为乘车学生登录和工作人员登录，拥有不同的操作权限。
2）预约系统：车辆信息查询（车辆运行情况查询，时刻表查询），车辆预约等。
3）车辆管理：发车操作，回车操作，车辆调度和指挥，预约人数查询和统计，车辆荷载情况等。
4）统计功能：统计预约人数，统计发车数量。
5）系统操作：1.初始设置：对乘客信息和车辆信息的初始化
2.乘客和管理员档案管理：学生只能修改自己的密码，管理员不能增加和删除学生信息。

三．可行性分析
3.1技术和设备上的可行性
1）软件和硬件上的可行性
系统的软件：GSM，GIS，GPS，SQL Server等，技术有无线传输，RFID，C/S，B/S使用较为简单，技术易于掌握。
硬件：计算机，PDA，可利用学校已有的计算机进行软件重装，减少经费支出。
2）开发，维护：现有的开发技术水平完全能够胜任开发任务，并且维护工作也较为简便。
3.2经济上的可行性
1）设备费用
计算机和PDA等硬件费用。
2）开发费用
该系统并不十分复杂，因此开发费用不高。
3）经济效益
使用新的信息系统可以有效地节约人力、物力，
3.3管理上的可行性
使用新系统可以使管理人员的工作更为简单，减少了大量的手工信息输入。调度员的工作也可由户外工作，变为室内工作，而且对乘车人数及预约人数的统计使得他们能进行更好，更科学的发车，实现车辆的有效管理。

四．系统分析
4.1组织结构图
绘制校车运营系统的组织结构图如下：
1）在本系统中，校车主要是为教师和学生提供出行，故在乘客中只有教师和学生。考虑到教师要乘车去上课，不能迟到，故在乘客中，我们将教师的优先级提高，在班车的预约中，自动将教师的预约序号排在预约人群的前端（已上车乘客不属于预约人群）。
2）管理系统中的系统维护主要是进行各种信息的维护，包括车辆信息、用户信息、司机信息以及各行车历史数据。行车调度主要对车辆调度科学、灵活的控制，检查各站执行运行图情况和乘客的预约情况，发布调度命令，保证校车运营系统能够安全、均衡、有节奏地完成运送乘客的任务。在途监控则是为了保障校车运营的安全与可靠，相关管理人员能实时获取车辆运行的实时信息，在遇到突发事件时，能进行及时、有效的处理，将事件影响降到最低。驾驶员是车辆调度、运行命令的实际执行者，故对他们的管理也是十分重要的。

4.2业务流程图
绘制校车运营系统的业务流程图如下：

1）本系统设定了两种系统登录方式，为手机登陆和校园卡登录。手机登陆方式采用账号加密码登录，主要为乘客提供车辆调度信息查询和班车预约，方便在登车点以外的乘客的提前预约，行车调度部门也可以根据此预约信息，提前做好调度准备工作。校园卡登录方式则主要用于乘车点的乘客的预约，乘客可使用自己的校园卡在乘车点的使用终端上快捷登录信息系统实现班车预约，若乘车点已有班车等候，乘客也可直接刷卡登车。为了预约信息的有效性和实习性，我们规定只能预约当天的班车
2）车辆调度部门首先实行的是按班发车，在此基础上再根据乘客的预约信息决定是否加派车辆。当某一时刻的班车的预约人数已达到车辆准载人数而发车时间还没到时，车辆调度部门发出发车命令，驾驶员将校车开到乘车点。当实际登车人数达准载人数时，调度部门发出行车命令，驾驶员确认行车命令并执行。
注：乘客预约车辆时根据发车时刻表来选择具体的预约班车。
3）为方便集体活动出行时的车辆预约，本系统提供集体出行车辆预约选项。由集体负责人填写车辆预约申请，调度部门对申请信息进行审核并反馈，为通过审核的申请安排车辆，对不合格申请要填写具体的不合格原因。为了方便车辆的调度，我们规定包车预约必须提前三天以上才有效。
4）在途监控部门通过接受车载GPS的实时信息，并结合GIS得到车辆的准确位置及状态。可实现车辆导航，在途监测，方便对突发事件的处理。而且根据电子地图还可以预估车辆的返程时间，方便调度部门对车辆的安排。实行车辆在途监测也可以有效的提高对车辆资源的的管理程度，避免个别驾驶员用集体资源接私活。
4.3数据流程图
环境图：

零层图：

各级子图：

本系统的数据流程主要分四部分
1）乘客预约系统
乘客用自己的账号、密码登录信息系统，产生相应的登录信息。进行车辆预约时，会产生相应的预约信息，系统自动统计乘客的预约信息，当预约人数达到车辆准载数时，调度人员进行车辆调度。
2）集体出行车辆预约
当有集体活动需要校车接送时，首先由集体负责人填写车辆预约申请，调度部门对申请信息进行审核并反馈，为通过审核的申请安排车辆。
3）车辆在途跟踪控制
由车辆上的车载GPS终端给系统发送实时信息，结合GIS信息系统得到车辆的准确位置及状态，可实现车辆导航，在途监测等用途。
4）查询系统
方便乘客查询自己的私人乘车预约信息和包车预约信息。

4.4数据字典
车辆信息：
数据项
编号：DI01
名称：车辆编号
别名：
属于数据流：F3.1,F1.6
数据存储处：D1
简述：车辆的表示编号，每一辆车都有自己的编号
类型：字符串
长度：8
域值：00000000—99999999
数据元素构成
编号

乘客信息：
数据项
编号：DI02
名称：乘客编号
别名：
属于数据流：F1.1,F1.2,F1.3,F3.3
数据存储处：D3
简述：每个乘客都有自己的编号
类型：字符串
长度：8
域值：00000000—99999999
数据元素构成
编号

驾驶员编号：
数据项
编号：DI03
名称：驾驶员编号
别名：
属于数据流：
数据存储处：D2
简述：每个驾驶员都有自己的编号
类型：字符串
长度：8
域值：00000000—11111111
数据元素构成
编号

发车时间：
数据项
编号：DI04
名称：发车时间
别名：
属于数据流:F4.2
数据存储处：D4
简述：班车的发车时间
类型：字符串
长度：5
域值：00:00-23:00
数据元素构成
发车时间

管理员编号：
数据项
编号：DI05
名称：管理员编号
别名：
属于数据流：
数据存储处：
简述：每个管理员都有自己的一个编号
类型：字符串
长度：4
域值：0000—1111
数据元素构成
管理员编号

车辆使用记录：
数据结构
编号：DS01
名称:车辆使用记录
别名：
属于数据流：F1.7
数据存储处：D8
简述：记录车辆发车时间及随车驾驶员
数据结构组成

备注：

登陆信息清单：
数据结构
编号：DS02
名称:登陆信息清单
别名：
属于数据流：
数据存储处：
简述：记录乘客和管理者的登陆信息
数据结构组成

备注：

乘客信息表：
数据结构
编号：DS03
名称:乘客信息表
别名：
属于数据流：F1.3
数据存储处：D7
简述：已经预约的乘客信息
数据结构组成
　乘客姓名+学号+所定车辆发车时间+预约时间
备注：

GIS信息输入：
数据结构
编号：DS04
名称:GIS信息输入
别名：
属于数据流：
数据存储处：
简述：车辆运行是GIS跟踪监控信息
数据结构组成
　车辆位置+车辆运行状况+路面情况
备注：

GPS数据输入：
数据结构
编号：DS05
名称:GPS信息输入
别名：
属于数据流：
数据存储处：
简述：车辆运行时GPS导航定位信息
数据结构组成
车辆具体位置+行驶路径
备注：

登陆信息：
数据流
编号：F1.2
名称:登录信息
别名：
简述：乘客登录系统显示的身份信息
来源：乘客登录系统
去向：乘客预约系统
数据流组成
乘客姓名+学号
数据流量：2000人次/天
高峰流量：2500人次/天
备注：

乘客预约信息：
数据流
编号：F1.4
名称:乘客预约信息
别名：
简述：乘客进入预约模块进行预约操作
来源：乘客预约系统
去向：审核统计预约信息系统
数据流组成
乘客姓名+学号+预约信息
数据流量：1800条/天
高峰流量：2400条/天
备注：

预约统计信息：
数据流
编号：F1.5
名称:预约统计信息
别名：
简述：对预约乘客信息的统计
来源：审核统计预约信息
去向：发车命令
数据流组成
预约人数+预约人信息+预约时间
数据流量：1200条/天
高峰流量：30条/天
备注：

发车命令：
数据流
编号：F1.6
名称:发车命令
别名：
简述：把发车信息传递给驾驶员
来源：调度中心
去向：驾驶员
数据流组成
发车车序号+发车时间
数据流量：20次/天
高峰流量：25次/天
备注：

确认发车信息：
数据流
编号：F1.7
名称:确认发车信息
别名：
简述：把确认发车信息传递到监控中心
来源：驾驶员
去向：监控中心
数据流组成
车辆序号+车牌号+驾驶员编号+发车时间
数据流量：20次/天
高峰流量：25次/天
备注：

包车申请：
数据流
编号：F2.1
名称:包车申请
别名：
简述：获取集体包车信息
来源：某个集体
去向：调度中心
数据流组成
用车时间+目的地+出发时间+返回时间+人数
数据流量：2条/天
高峰流量：10条/天
备注：

包车审核信息：
数据流
编号：F2.2
名称:包车审核信息
别名：
简述：根据审核信息安排车辆
来源：包车预约系统
去向：调度中心
数据流组成
包车条件+包车用途
数据流量：5条/天
高峰流量：10条/天
备注：

录入车辆信息：
数据流
编号：F3.1
名称:录入校车信息
别名：
简述：录入校车信息
来源：校车本身信息
去向：系统数据库
数据流组成
车牌号+车型+准载人数
数据流量：
高峰流量：
备注：根据实际需要进行数据录入

录入驾驶员信息：
数据流
编号：F3.2
名称:录入驾驶员信息
别名：
简述：录入驾驶员信息
来源：驾驶员本身信息
去向：系统数据库
数据流组成
编号+姓名+年龄
数据流量：
高峰流量：
备注：根据实际需要进行数据录入

录入乘客信息：
数据流
编号：F3.3
名称:录入乘客信息
别名：
简述：录入乘客信息
来源：乘客本身信息
去向：系统数据库
数据流组成
编号+姓名+年龄
数据流量：
高峰流量：
备注：根据实际需要进行数据录入

车辆安排：
数据流
编号：F5.1
名称:车辆安排
别名：班车安排
简述：安排每日班车
来源：乘客需求
去向：系统数据库
数据流组成
序号+时间
数据流量：
高峰流量：
备注：原则上每天更新一次即可，但可根据实际需要进行数据录入

乘客系统预约：
处理逻辑
编号：P1.3
名称:乘客系统预约
简要说明：乘客登录系统预约后形成的信息
输入信息：登录信息
输出信息：乘客预约信息
数据存储
D7
激发条件：乘客预约
加工逻辑：根据乘客的登录信息和预约操作，形成乘客的预约信息，存入系统
出错处理：不进行预约登记
执行频率：600条/天

确认发车：
处理逻辑
编号：P1.6
名称:确认发车
简要说明：驾驶员发车后向调度中心进行反馈
输入信息：发车指令
输出信息：发车信息
数据存储
D8
激发条件：驾驶员发车
加工逻辑：根据调度中心的发车指令进行发车，并将发车操作报告调度中心
出错处理：禁止发车
执行频率：25条/天

包车预约审核：
处理逻辑
编号：P2.3
名称:包车预约审核
简要说明：根据包车条件对包车申请进行审核
输入信息：包车申请
输出信息：包车信息
数据存储
D6
激发条件：包车审核
加工逻辑：根据包车条件审核包车申请的合格性，并对通过的包车信息进行登记
出错处理：退回包车申请
执行频率：10条/天

信息录入：
处理逻辑
编号：P3.1
名称:信息录入
简要说明：对所有校车信息进行统计并录入数据库
输入信息：校车信息
输出信息：车辆信息表
数据存储
D1
激发条件：录入数据
加工逻辑：管理员根据校车信息在数据库中建立车辆信息表
出错处理：禁止录入
执行频率：

在途跟踪：
处理逻辑
编号：P4.1
名称:在途跟踪
简要说明：监控中心对车辆运行进行实时监控管理
输入信息：GIS、GPS信息
输出信息：车辆实时信息
数据存储
D11
激发条件：发车操作
加工逻辑：利用GIS、GPS采集的信息对在途的车辆进行实时管理，并登记实时信息
出错处理：无法监控
执行频率：25条/天

安排每日班车：
处理逻辑
编号：P5.1
名称:安排每日班车
简要说明：调度中心根据数据库的信息进行每日发车安排
输入信息：车辆安排
输出信息：每日发车表
数据存储
D4
激发条件：调度人员安排
加工逻辑：根据车辆信息和驾驶员信息和每日发车时刻表安排发车，形成每日发车表
出错处理：无法生成
执行频率：1条/天

车辆信息存储：
数据存储
编号：D1
名称:车辆信息
别名：
简述：所有校车的相关信息
组成：每辆校车的具体信息
若为数据存储
关键字：车辆编号
相关处理：车辆信息的维护
若为数据流
来源：
去向：
数据量：
峰值：
备注：

驾驶员信息存储：
数据存储
编号：D2
名称:驾驶员信息
别名：
简述：所有驾驶员的相关信息
组成：每个驾驶员的具体信息
若为数据存储
关键字：驾驶员编号
相关处理：驾驶员信息的维护
若为数据流
来源：
去向：
数据量：
峰值：
备注：

乘车信息存储：
数据存储
编号：D3
名称:乘客信息
别名：
简述：所有在校师生的相关信息
组成：每个师生的具体信息
若为数据存储
关键字：师生编号
相关处理：师生信息的维护
若为数据流
来源：
去向：
数据量：
峰值：
备注：

乘客登陆信息存储：
数据存储
编号：D5
名称:乘客登录信息
别名：
简述：乘客登录预约系统所显示的信息
组成：姓名+学号+登录时间
若为数据存储
关键字：师生编号
相关处理：查看乘客登录状态
若为数据流
来源：
去向：
数据量：300条/天
峰值：600条/天
备注：

包车信息存储：
数据存储
编号：D6
名称:包车信息
别名：
简述：集体包车的信息
组成：用车时间+目的地+出发时间+返回时间+人数
若为数据存储
关键字：包车条件
相关处理：对包车信息进行存储，方便查询
若为数据流
来源：
去向：
数据量：5条/天
峰值：10条/天
备注：

乘客预约信息存储：
数据存储
编号：D7
名称:乘客预约信息
别名：
简述：乘客预约后在系统中形成的信息
组成：预约人信息+预约乘车时间+预约时间
若为数据存储
关键字：预约乘车时间
相关处理：对预约信息进行统计和审核
若为数据流
来源：
去向：
数据量：500条/天
峰值：600条/天
备注：

每日发车表存储：
数据存储
编号：D4
名称:每日发车表
别名：
简述：每天的工作车辆和驾驶员信息
组成：校车编号+驾驶员编号+排车顺序号
若为数据存储
关键字：
相关处理：方便乘客查询
若为数据流
来源：
去向：
数据量：1条/天
峰值：1条/天
备注：

发车信息存储：
数据存储
编号：D8
名称:发车信息
别名：
简述：对乘客预约信息的统计
组成：每个乘客的预约信息+预约总人数
若为数据存储
关键字：
相关处理：利用统计信息来发车
若为数据流
来源：
去向：
数据量：20条/天
峰值：30条/天
备注：

乘客：
编号：S1
名称：乘客
别名：
简述：校车进行服务的人群
流入数据流
师生基本信息
输出数据流
登录信息

行车调度员：
编号：S2
名称：行车调度员
别名：
简述：对校车运行进行各种管理
流入数据流
车辆信息、驾驶员信息
输出数据流
车辆安排

驾驶员：
编号：S3
名称：驾驶员
别名：
简述：对校车进行驾驶的司机
流入数据流
发车指令
输出数据流
发车信息

系统管理员：
编号：S4
名称：系统管理员
别名：
简述：对校车系统基本信息的维护和管理
流入数据流

输出数据流

五．系统设计
5.1模块结构图
5.1.1根据系统分析画模块结构图如下：

1） 登录流程：

(1) 选择不同身份登录系统
本系统有三种类型的用户：调度人员、管理员、教师和学生即乘客。当不同的用户使用各自的账号登录系统时系统自动选择不同的用户类型，建立链接，他们就会分别拥有不同的权限。以保证系统信息的安全性和有效性。
(2) 修改密码
每个用户登录后，都可更改初始密码，以增强个人信息的安全性。
(3) 退出
用户登录系统后单击退出，就可退出系统。
2） 信息管理流程：

（1）车辆管理
对所有车辆的信息录入系统，并及时更新、修改车辆的信息。
（2）驾驶员信息管理
对所有驾驶员信息进行录入，并及时更新、修改驾驶员的信息。
（3）师生信息管理
对所有师生信息进行录入，并及时更新、修改师生的信息。
（4）对车辆使用记录的查询。
3） 调度中心作业模块
（1） 审核统计预约信息

调度中心将对每一发车时刻的预约信息进行审核统计，若在此时间段内，预约人数超过车辆的准载人数，就发出调车指令来进行发车；对于集体包车，需审核是否满足包车条件，若满足，则安排车辆。
（2）生成每日发车表
处理流程：

调度中心将根据数据库中的车辆信息、驾驶员信息进行适当安排，形成每日的发车表，即按照发车时刻表在每一具体规定发车时刻安排具体的车辆和驾驶人员。
（3）包车审核
调度人员从数据库中查询包车申请，并对其按相关规定进行审核，符合要求的包车申请，对不合格的予以驳回。
（4）发车管理

根据审核统计预约信息进行车辆调度。调度中心将根据某一时段的具体预约人数以及每日发车表来安排发车，若在规定下一发车时刻到来之前，预约人数达到车辆准载人数，就将下一发车时刻的车辆提前发出，满载后即可发车，这有可能打乱原有的发车秩序，但只要保持原有的车辆的发车顺序，则无较大影响 ；若达不到满载人数，则到规定发车时刻再发车。
对于集体包车，根据审核包车信息安排具体车辆用于包车业务。
（4）在途监控

车载GPS将车辆的实时信息传送到web服务器中，监控中心利用GIS信息系统完成对在途的车辆的准确定位，监控中心的电子地图将显示车辆的具体地理位置，周围的路况和车辆运行情况，确保车辆的安全运行以及及时处理各种突发状况，同时也可以进行回车管理。
4） 预约管理模块
（1） 个人乘车预约流程：

乘客通过登录预约系统进行预约当天班车的操作。在班车确认发车后，该班车的预约信息全部失效。
（2） 集体包车申请

用户可以提前3-7天对车辆进行包车预约，填写包车申请，用户需要说明包车用途等信息。
（3） 取消预约

乘客在预约后相关班车后，在驾驶员确认发车前5分钟都可以取消预约并返还预约款，但不实际乘车又不及时取消预约的乘客，预约款不返还；对于集体包车，提前至少1天取消包车业务。

5.1.2画事物型模块结构图如下：

1）信息输入主要包括乘客信息、发车时刻表、GPS信息、GIS信息。考虑到上课时间和周末的客流量有明显的差别，可采用两个发车时刻表，根据以往的客流量来进行车辆初步安排。考虑到期末教师去虎溪监考、毕业生回虎溪照相留念等都会使乘客数量有很大波动，所以我们建议也采用分析以往的客流量记录，制定合适的派车方案，使乘客有车可乘，而又不会浪费车辆资源。
2）班车预约主要是可以保证乘客有车可乘，在乘客数量超出车辆运载能力时，调度人员可以及时发现，并及时加派车辆。而乘客在发现校车乘坐人数过多，有可能需要等待时，也可以自行选用其他乘车方式。
3）调度人员进行车辆安排时，要将发车时刻表和各时刻的预约人数相结合。预约人数确实超过车辆准载人数时，可提前发车，而乘客实际上车人数达车辆准载人数时，驾驶员发车，并通过乘车点的终端发送确认发车消息。若直到正常发车时刻，实际上车人数未达车辆准载人数，驾驶员就按正常时刻发车，并发送确认发车消息。
4）包车提前期为3到7天，申请提交后，调度人员根据包车核实条件和车辆资源的使用情况来安排包车，并及时将包车信息发布到查询平台，供申请者查询。
5）在途监控可根据路况和车辆实时信息估算出车辆的回车时间，若出现堵车等情况不能及时回车的，可尽早做好其他替补车辆的安排。同时通过监控实时位置也能及时发现并处理紧急事务。而且通过监控实时位置还可更好地管理车辆资源，防止驾驶员使用车辆资源接私活。
6）在查询平台上，乘客可以查询自己的预约信息，也可以查询各时刻班车的已预约人数及发车时间。而包车信息的及时反馈，也可以在查询平台上体现出来。

5.2网络设计
画网络拓扑图：

产品选型及造价如下：

GPS系统：

5.3代码设计：
学生编号：统一采用学号
教师编号：可采用学校已编制的教师编号
管理员、调度员编号：
01
xx
xxxx
标志位
岗位代号
员工代号

驾驶员编号：
02
xx
xxxx
标志位
岗位代号
员工代号

班次编号：
00
xxxx
xx
xx
xxxxx
xxxxx
预留位
年
月
日
发车时刻
序号
注：1）发车时刻为司机每次发送确认发车信息时间，精确到分钟。
2）序号为当天发车的班次，取值范围为0000—99999，司机每发一次确认发车信息，序号自动加1.

5.4数据库设计：
5.4.1画E-R图如下：

5.4.2建立数据库

1)建立关系联系如下：

2）乘客信息表

输入乘客信息如下：

3）车辆信息表

录入信息如下：

4）驾驶员信息表

录入信息如下：

5）车辆使用信息表

信息录入由驾驶员确认发车后，系统自动完成。

6）工作日发车时刻表

插入发车时刻表如下：

5.4.3系统用户权限设计
如何根据功能划分用户类别对于一个需要安全性的系统非常重要，经过调研以及对校车运营系统现状的分析，将传统的车辆管理方式进行简化，可分为以下类别。
乘客——用户具有查询发车时刻表，以及各时刻的已预约人数的权利，同时他们还可以添加班车预约信息以及包车申请的权利和查询个人的班车预约和包车预约信息。
驾驶员——驾驶员具有查询车辆信息，和发车时刻表的权利，同时在每次发车时，他们都会提交确认发车信息。但是驾驶员没有添加车辆使用信息的权利，因为驾驶员没有权利公车私用，而所有车辆的使用都是由调度部门同意安排并发送发车指令的，然后由驾驶员执行的，所以驾驶员不允许也没有必要有添加车辆使用信息的权利。
调度人员——调度人员有查询班车预约信息和包车申请信息的权利，并有权对其进行处理，决定车辆的安排。调度人员在安排车辆后会提交相应的车辆使用信息，在司机进行确认发车后，车辆使用信息正式录入车辆使用信息表。
管理员——管理员有权删除、修改和增加除车辆、驾驶员和乘客的信息，实现系统的废旧信息的处理和新信息的更新。同时，管理员还有权查看车辆的使用信息，但不能对信息进行修改和删除，该设计符合系统信息安全性和有效性的要求。

5.5输入输出设计
5.5.1输入设计：
本系统中的班车时刻表是由调度人员采用键盘输入的方式输入，信息录入后以基本表的形式存在于数据库中，方便乘客查询，必要时，管理员也可对其进行更改。GPS、GIS，则是由网络传输自动输入，可以安全、可靠、快捷地传输数据。系统中的预约信息、查询信息、处理信息都采用网络传输方式。5.5.2
5.5.2输出设计：
本系统中信息输出格式较为固定，统一采用表格输出，在车辆实时信息中，GPS信息和GIS系统相结合则使用地图的方式输出。
5.6界面设计
登陆界面设计：

功能界面设计：

查询功能包括：班车时刻查询、班车预约查询、包车申请查询
班车预约包括：查询已预约人数、选择发车时刻、提交预约信息
包车申请包括：提交包车申请
包车审核包括：申请信息审核、包车回复

33