公交车管理系统实现与设计Word文件下载.docx
《公交车管理系统实现与设计Word文件下载.docx》由会员分享，可在线阅读，更多相关《公交车管理系统实现与设计Word文件下载.docx（38页珍藏版）》请在冰点文库上搜索。
月末收银员审核过数据后将月报表、年报表交至财务部由财务分析员对这些报表数据进行分析，以便做好进一步的规划预算，同时还需将月报表、年报表和客流量汇总表及时交给总队长。
其业务流程图如图：
2.2.2会计记账流程：
会计人员根据售票员提供的剩余凭证和收费划单及监控员提供的作废凭证在电脑上进行登记账单，形成日报表，再将日报表交由收银员审核，审核通过则收银员根据会计做的日报表，月末形成月报表，年末形成年报表。
不通过，则返回日报表给会计令其纠正。
2.3.数据流程分析
2.3.1财务管理流程：
2.3.2数据字典
（一）数据流的描述
数据流编号：
D--1
数据流名称：
购票单
简述：
由工作人员帮助乘客填好购票单
数据流来源：
乘客
数据流去向：
登记处审核处理
数据项组成：
乘客名称+票价+车票类型+经手人+购买时间
数据流量：
约8张/日
高峰流量：
约15张/日
D--2
收款凭证
经登记处填好的收款凭证
售票员
数据流编号：
D--3
收费单
由售票员填好的收费单
会计人员审核登记处理
约2张/周
约4张/周
（二）处理逻辑的描述
处理逻辑编号：
P--1
处理逻辑名称：
购票单审核
简述：
审核购票单
输入的数据流：
处理描述：
审核购票单，填写收款凭证
输出的数据流：
处理频率：
8次/日
P—2
根据收费单将数据记入日报表
根据收费单将数据记入日报表，并更新相关数据
客流数据
（三）数据存储的描述
数据存储编号：
F--2
数据存储名称：
汇总台账
记录车票销售的情况
数据存储组成：
销售数量+乘客名称+票价+车票类型+经手人+购买时间
关键字：
乘客名称+票价
相关联的处理：
P—1，P—2，P—3
（四）外部实体的描述
外部实体编号：
S--1
外部实体名称：
填写收费单
输入的数据流：
D—2，D—3，D—4
输出的数据流：
D—2
2.4.系统需求分析
2.4.1计算机和处理器
处理器800MHz以上（如果开启视频至少1GHz）
2.4.2内存
128MB以上（如果开启视频至少256MB）
2.4.3硬盘
安装需要100MB的硬盘空间，运行需要50MB空余空间
2.4.4显示器
最小800x600（建议使用1024x768）屏幕分辨率
2.4.5浏览器
计算机上应该安装了MicrosoftInternetExplorer6或更高版本，但是不一定要设置为默认浏览器。
2.4.6Internet连接
互联网接入（宽带接入效果最佳，无线接入质量降低，模拟线路不建议使用）。
2.4.7管理人员的支持
管理人员对该系统充分理解与支持，并要求其员工进行系统操作培训。
2.5.需求规格说明书
2.5.1引言
2.5.1.1编写目的
目的是提高工作效率,节约人力资源,并作为软件设计人员设计依据和使用单位的验收标准。
预期的读者是软件设计人员还有组织高层人员。
2.5.1.2背景
此待开发系统的名叫公交车信息管理系统，是公交车高层管理人员提出需要开发此项目，进行研究开发，供车队指定工作人员使用。
2.5.1.3定义
Xml：
XML（ExtensibleMarkupLanguage）即可扩展标记语言，它与HTML一样，都是SGML（StandardGeneralizedMarkupLanguage,标准通用标记语言）。
Xml是Internet环境中跨平台的，依赖于内容的技术，是当前处理结构化文档信息的有力工具。
扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便的方式建立，虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。
XML与Access,Oracle和SQLServer等数据库不同，数据库提供了更强有力的数据存储和分析能力，例如：
数据索引、排序、查找、相关一致性等，XML仅仅是展示数据。
事实上XML与其他数据表现形式最大的不同是：
他极其简单。
这是一个看上去有点琐细的优点，但正是这点使XML与众不同。
XML与HTML的设计区别是：
XML是用来存储数据的，重在数据本身。
而HTML是用来定义数据的，重在数据的显示模式。
XML的简单使其易于在任何应用程序中读写数据，这使XML很快成为数据交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不久之后他们都将支持XML，那就意味着程序可以更容易的与Windows、MacOS,Linux以及其他平台下产生的信息结合，然后可以很容易加载XML数据到程序中并分析他，并以XML格式输出结果。
2.5.2任务概述
2.5.2.1目标
本系统通过强大的网络技术给组织的工作人员带来方便，本系统能实现客运管理、售票管理、协调纠纷管理、财务管理，提高工作人员的工作效律，为工作人员提供了极大方便，即使不出门也可以进行工作上的处理。
2.5.2.2用户特点
最终用户可分为操作人员、维护人员。
其中，操作人员要求对计算机有一定了解的人员。
维护人员要求对本系统有较深的了解，同时对系统相关信息及工作流程有所了解的技术人员。
本系统需要在资源的动态更新，这时候也是本系统最需要维护的时候，所以在这时候要对本系统进行必要的检修，防止数据出错
2.5.2.3假定与约束
设计的约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
其并不是要取代设计（实现）过程，只是说明用户或环境强加给项目的限制条件项目投入的最晚时间。
2.5.3需求规定
2.5.3.1对功能的规定
输入
输出
输入限制
输出限制
并行用户数
支持终端数
后台处理
用户登录执勤
登录账号密码
文本
首页
汉字、数字、英文字母
小于255
进入首页界面
进入工作中心
管理模块
进入指定工作界面
数据更新
列表
存储
后台管理
登录注册
修改
修改，存储
查询
查询，输出
资源添加、删除
存储，修改
2.5.3.2对性能的规定
a.精度
要求查询切换之间的时间控制以秒为单位，输入数据为文本，无精度要求。
查询数据能够符合用户的要求，没有冗余数据。
输出数据精度要求为尽量符合资源特征。
b.时间特性要求
ⅰ.响应时间：
小于2秒；
ⅱ.更新处理时间：
即时更行；
ⅲ.数据的转换和传送时间：
小于2秒;
c.灵活性
可在任意平台下运行，当操作方式、数据结构、与其它软件接口等发生变化时，设计的软件要基本无调整，灵活性非常大。
但资源需放到指定位置，需及时更新索引。
2.5.3.3输入输出要求
输入数据类型，具体要求见上表，输出为资源列表。
2.5.3.4数据管理能力要求
需要管理的文卷和记录大约有100来份，占用内存大致1MB
2.5.3.5故障处理要求
a.如果界面打不开或是登录失败，应检查系统防火墙是否关闭，更新索引。
b在输入数据不符合定义时提示正确类型并重;
新输入；
c数据在数据库中已有备份，系统出错时可以靠数据库恢复
2.5.3.6其他专门要求
2.6.处理逻辑说明
由于最底层数据流程图中的加工不能再通过子图做进一步的描述，因此必须有处理逻辑说明来定义底层数据流图中的加工。
如：
售票员收费对在不同路段，乘客到达目的的不同路程收取不同票价。
在此处我们用判断树法来表示售票员售票过程。
第三章可行性研究
此可行性研究报告是在制定项目前对公交管理项目实施的可能性、有效性、技术方案及技术政策进行具体、深入、细致的技术论证和经济评价，报告的主要内容如下：
3.1引言
3.1.1目的：
为了更加便于公交车系统的管理，提高工作效率，尤其是完善财务管理与提高公交财务会计等的管理。
3.1.2背景：
现行的公交体系仍旧是一个不完整的、分散的、相互竞争的没有统一的系统。
3.2现行公交车管理概况
3.2.1组织目标与战略:
提高公交员工的工作效率，尽可能减少成本提高效益，以最小的成本获取最大的收益。
通过建立一个完善的公交管理信息系统，利用先进的设备提高记账效率，完善工资核算体系，明确分工，明确各个司机的路线，对不遵守路线规则恶意竞争者予以惩处，以建立一个完善，和谐，系统，高效的公交车管理信息系统。
3.2.2存在的主要问题：
记账只是传统的手工记账，设备也是简单的计算器。
司机之间有相互的竞争，司机经常不遵守发车秩序和时间，经常误点、踩点。
公交监控几乎没有，只是落后的人工监控。
3.3拟建立的信息系统
3.3.1简要说明：
建立一个高效率的集账务管理系统，员工管理系统，工资管理系统和监控奖惩系统于一体的信息系统。
3.3.2对组织的意义和影响：
提高了公交工作效率，员工工作热情，完善了对司机员工的监管，公交秩序井然，服务质量提高，收益大大增加，成本减少，使得净利润增加。
3.4经济可行性分析
3.4.1支出（包括系统开发费用和系统运行费用）
系统开发费用：
a.人员费用。
b.硬件设备费,
c.软件费用
d.耗材费用
假定本系统运行期为5年，每年系统耗费如下：
a.系统维护费。
b.设备维护费。
c.消耗材料费。
3.4.2收益
本系统获得的直接经济效益可以从以下几个方面计算。
a.提高工作效率，减少工作人员。
本系统投入运行后，可以提高人力资源管理、财务预算管理、车辆运行管理，累计可以提高工作效率10%。
b.及时获取信息，减少决策失误。
提高工作人员上班的准时性，减少车次延误的可能；
分析年数据信息，及时推出相关政策，以提高工作效益。
c.直观了解每班车次的客流，便于以后做统计报表，分析趋势，作出最优决策。
d.提高工作效率，减少工作人员的工作量。
3.5技术可行性分析
3.5.1技术可行性分析
已经学习了SQLSERVER，对网络技术和操作系统也有系统的了解，有些成员熟悉计算机原理，能解决常见的硬件故障和硬件选择。
而且，网上有许多关于VISULBASIC编程的资料和SQLSERVER方面的资料。
所以从技术上来说，此次开发是可行。
3.6社会可行性分析
3.6.1社会法律政策可行性：
目前已有很多成功开发公交车管理信息系统的先例，社会需要公交车管理的现代化和信息化。
此信息系统开发和运行并不违背国家的法律政策。
3.6.2社会公共环境可行性：
公交所走路线的公路都是符合质量要求的，顾客也多。
3.6.3操作可行性：
此信息系统所采用的操作和工作方式符合工作人员和读者的日常习惯，而且操作方便灵活，简单、便于学习。
综上所述，该系统具有社会可行性。
3.7可行性研究结论
通过经济、技术、社会等方面的可行性分析，可以确定本系统的开发完全必要，而且是可行的，可以进行开发。
第四章系统设计
将设计过程中所形成的各种文档资料进行编辑处理，编写成系统设计报告，主要内容和格式如下：
4.1.引言
4.1.1目的：
4.1.2背景：
4.2.系统设计方案
4.2.1系统总体结构设计
公交管理系统集合了原本车队的四个子系统：
客运管理，售票管理，纠纷协调管理，财务管理。
车队的管理人员可以同时查询和了解四个子系统的工作情况，使得车队的管理层能够更好的了解和监督工作情况，保证工作高效进行。
在子系统中有自己的管理模块。
模块功能图如图：
公交管理系统
客运管理
售票管理
纠纷协调管理
财务管理
人员管理
车辆管理
日耗油管理
维修管理
票价管理
收费管理
事故处理管理
乘客反馈管理
收银管理
报表统计管理
4.2.1.1客运管理
<
1>
公交人员管理
该模块针对公交管理系统的基层工作人员和管理层工作人员的基本信息进行管理，基层工作人员基本信息包括姓名、性别、所属部门、联系方式，管理层工作人员的基本信息除了包括姓名、性别、所属部门、联系方式等以外，还记录该工作人员的登录密码、编号和级别，方便权限管理。
在模块中可实现对信息的增加，修改，删除，查询，打印等功能。
<
2>
公交车信息管理
该模块针对车队里的13辆公交车的基本信息进行管理，包括车型，发动机类型，重量，载客数，功率，车牌号，车辆制造厂。
3>
耗油管理
该模块针对车队的13辆车每辆每日的耗油量信息管理，需每日更新。
4>
该模块针对车队的13辆公交车的维修状况进行管理。
记录每次维修的基本信息，包括维修车辆车牌号，维修部位，维修日期，维修地点，维修费。
4.2.1.2售票管理
该模块针对不同路段的售票价格进行管理。
该模块记录着售票员的日常工作，每个售票员一日有十班次，记录包括每个班次的人流数、每班次售出的每种票价的票数、每班次收入总数，最后统计出整日的人流、票数、总收入。
废票管理
该模块记录了再收费过程中由于操作失误而产生的作废车票信息，底层员工无权处理，高权限监督管理人员方可进行处理。
4.2.1.3纠纷协调管理
意外事故处理管理
该模块记录每次事故处理的基本信息，包括事故发生时间、地点、肇事人、事故发生原因、事故处理支出。
该模块记录任何乘客们的反馈以及提出的有益建议。
4.2.1.4财务管理
该模块由收银员进行操作，记录着每个售票员的每班次的收入，同时也记录了每个班次的人流数、每班次售出的每种票价的票数。
每日最后一班车后，收银员要作出最后统计每个售票员一日的工作情况，包括整日的人流、票数、总收入。
该模块由财务管理人员进行操作，对基本数据进行统计，最后输出报表，包括日报表、月报表、年报表。
4.2.2.处理流程设计
4.2.2.1系统流程设计
依据上面系统分析报告的财务管理分析数据流程图，对公交管理信息系统的财务管理子系统进行系统流程设计，同系统流程图来描述各数据在计算机存储介质间的流动、转换、和存储情况。
其系统流程图如图2.1：
4.2.2.2模块处理过程描述
我们对收费监控流程的程序用程序流程图来描述系统设计的程序。
登记处理
收、交款凭证
收费标准
剩余收款凭证
会计审核登记
客流量表
日报表
收银员审核
月报表、年报表
财务数据分析
预算规划表
4.2.3.代码设计
在MIS中，每种实体都必须有代码。
代码是代表事物名称、属性、状态等的符号，是数据的重要组成部分，它唯一标识实体，节省存储空间单元，提高数据处理效率，便于数据的存储和检索。
代码字符设置精准合理，无论记录、记忆，还是存储，都可以节省时间和空间。
根据系统所涉及的数据特点，将代码设计如下：
4.2.3.1车辆车牌号码的代码设计
车牌号码的确定遵循原有的统一编号方法，即分为车牌所属地简称和车辆排序号，两者组合成为统一的车牌编号。
在系统中，直接采用该方法，便于工作上的操作和识别。
4.2.3.2人员编号的代码设计
无论是财务管理方面的人员还是车票销售的工作人员，都统一编号，以便于公司统一管理。
人员编号分为两个部分，包括人员所在部门名称的拼音缩写，比如：
售票部的拼音缩写为sb，财务部的拼音缩写为cb；
还包括人员的排序编号，参考公司下属工作人员的人数，编号长度设为4位，即第一位员工编号为0001，以此类推。
综上所述，若一名工作人员是在财务部的，则其编号为cb×
×
。
4.2.3.3车票票号的代码设计
由于车票的种类有票价和编号决定，故其代码设计包括这两部分，这有利于售票员的工作需求。
前半部分是票价，如1元；
后半部分是顺序号，若为今天第一位乘客购买的票，则编号为0001，以此类推。
两者结合到一起，则成为完整的车票号。
4.2.3.4车票收据的代码设计
车票收据是一天中乘客数的表现，也是公司收益的体现，为了方便售票员上缴数据和财务部的工作，采取日期和收据所印刷的号码进行登记。
4.2.4.输出设计
本系统的输出设计主要是根据输入设计中高层管理人员登录系统查询数据而输出的各类数据，主要是报表、表格、图表等。
当登录人员账号记错或者密码错误时，系统会自动生成对话框，提示用户所犯错误。
4.2.5.输入界面设计
4.2.5.1该管理系统的用户是车队的全体工作人员，工作人员先登录该车队的网站，然后在那网站首页选择自己所在的部门，然后就会弹出登录界面。
登录账号就是工作人员自己的代码，密码可以自己设置，如若忘记密码，可以点击界面的“找回密码”文字来找回密码。
4.2.5.2进入部门的管理系统后，根据权限的高低可对系统内部的信息进行查询或更新、修改、删除。
4.2.6.数据库设计
4.2.6.1概念结构设计
通过对系统业务及原始数据的分析，本系统的数据库文件设计结果见表如下：
数据名称
组成
名称
类型
宽度
小数位数
说明
姓名
字符
10
-
乘客的姓名
性别
逻辑
1
F/T=男/女
电话号码
数值
9
整数
联系电话
车票票号
6
车票的类型
电子邮件
12
联系的内部Email
售票员姓名
F/T=男/女
编号
售票员的编号
车票收据
收据编号
表1.5财务人员基本信息表
财务人员
财务人员名称
财务人员的编号
其E-R关系图为：
乘客与售票员为多对一关系，售票员与财务人员为多对一关系。
4.3.6.2逻辑结构设计
将图的E-R图转换为关系模型：
①乘客（姓名，性别，车票号，…）
此为乘客实体对应的关系模式，该关系模式已经包含联系“购票”所对应的关系模式。
车票号是关系的主码。
②售票员（姓名，编号，车票号，收据，…）
此为售票员实体对应的关系模式，该关系模式已经包含联系“上交”所对应的关系模式。
编号是主码，车票号是候选码。
③财务人员（姓名，性别，收据，编号）
此为财务人员实体对应的关系模式，主码是编号。
3.2.6.3物理结构设计
常用的物理存取方法主要有三类：
第一类是索引方法，目前主要是B
升级会员 