公交车管理系统实现与设计.docx
《公交车管理系统实现与设计.docx》由会员分享，可在线阅读，更多相关《公交车管理系统实现与设计.docx（32页珍藏版）》请在冰豆网上搜索。
公交车管理系统实现与设计
《软件工程导论》课程设计报告
公交车管理系统的设计与实现
学生姓名：
张勇
学号：
090403010063
年级专业：
09信息管理与信息系统
指导教师：
龙海
第一章绪论
针对公交车传统作业流程中的种种弊端，结合现代迅速发展的信息技术，我运用所学的信息管理及系统分析与设计的知识开发出了公交车的管理信息系统。
一个计算机管理系统必须有一个正确的设计指导思想，通过合理的选择数据结构，操作系统以及开发环境，构成一个完善的网络系统，才能充分发挥计算机信息管理优势。
现代化的车站售票是集预定车票、售票、退票、车次查询、报表及其他各种服务，车站售票组织庞大，服务项目多，信息量大，要想提高劳动生产，降低成本，提高服务质量和管理水平，进而促进经济效益，必须借助计算机来进行现代化的信息管理。
此系统包括四大块：
1、可行性研究报告：
从系统的总统出发，对经济、技术、社会、管理多方面进行综合分析，即经济可行性分析、技术可行性分析、社会可行性分析和管理可行性分析，是项目在开始阶段必须进行的一项工作。
2、系统分析报告：
它反映的是系统分析阶段调查分析的全部情况，是系统分析员与用户在一起，充分了解用户需求后所编写，作为后续开发工作的依据，也是衡量一个信息系统优劣的依据。
3、系统设计报告：
在已获准的系统分析报告的基础上，结合实际条件，可想而、合理地设计出得系统解决方案，是系统设计阶段工作的成果的总结，也是系统实施阶段的重要依据。
4、系统测试报告：
将系统最主要的功能模块进行逐一的检测，对说明书中列举的功能进行排查，对系统实现各功能的正常运行做充分的测试，输入合理及不合理的测试数据检验功能的运行及出错处理情况。
此系统的开发，主要是给管理工作者带来工作上的便利。
运用科学、系统的方法有步骤、有目的、循序渐进的开发完成。
第2章系统分析
根据对用户的需求，对公交车的业务活动的进行全面的调查分析，详细掌握了相关工作流程，收集票据、账单、报表等资料，分析现行系统的局限性和不足之处，并根据公交的条件，找出可行方案。
2.1.组织结构分析：
公交车队的高层领导由一名总队长、三名副队长组成。
总队长负责总体事务的决策，副队长负责主要事务的决策，三个副队长分别负责客运部、售票部、纠纷协调部、财务部。
其具体职能如下：
客运部主要职能是负责公交班次安排，负责司机行为规范，负责站点监督和指导。
售票部主要职能是负责售票员的售票，负责车票价格的协调与制定。
纠纷协调部得主要职能是负责临时突发事件，例如，乘客闹事，交通堵塞，客车故障，交通事故等等。
财务部主要职能是负责收银，负责会计，负责财务分析，负责报表。
2.2.业务流程分析
2.2.1收费监控流程：
根据系统中设定的路段收费标准，当公交驶入某收费路段售票员判断车辆所属地，同时，售票员根据不同路段的不同价位在收费划单中操作，根据收费单中的价格告知乘车顾客，并进行收费，乘客将公交车费交给售票员后，售票员将撕一张已打印好的交款凭证给顾客。
如果售票员工作失误，多撕了、少撕了或者撕错了凭证，可以继续给下一位乘客交款凭证（少撕的凭证可以即时补给），先完成收费工作，然后要将废票的票据出示给监控员，监控员依据废票的票据号进行废票的处理工作（监控员只是登记废票的票据号，做一个删除登记，不能彻底删除），处理完后记录废票信息。
每天每班车工作完成后，售票员将收费单和剩余收款凭证交至会计人员进行审核，确定无误后登记，每日会计统计出日报表和客人流数据交给收银员；月末收银员审核过数据后将月报表、年报表交至财务部由财务分析员对这些报表数据进行分析，以便做好进一步的规划预算，同时还需将月报表、年报表和客流量汇总表及时交给总队长。
其业务流程图如图：
2.2.2会计记账流程：
会计人员根据售票员提供的剩余凭证和收费划单及监控员提供的作废凭证在电脑上进行登记账单，形成日报表，再将日报表交由收银员审核，审核通过则收银员根据会计做的日报表，月末形成月报表，年末形成年报表。
不通过，则返回日报表给会计令其纠正。
其业务流程图如图：
2.3.数据流程分析
2.3.1财务管理流程：
每天每班车工作完成后，售票员将收费单和剩余收款凭证交至会计人员进行审核，确定无误后登记，每日会计统计出日报表和客人流数据交给收银员；月末收银员审核过数据后将月报表、年报表交至财务部由财务分析员对这些报表数据进行分析，以便做好进一步的规划预算，同时还需将月报表、年报表和客流量汇总表及时交给总队长。
2.3.2数据字典
（一）数据流的描述
数据流编号：
D--1
数据流名称：
购票单
简述：
由工作人员帮助乘客填好购票单
数据流来源：
乘客
数据流去向：
登记处审核处理
数据项组成：
乘客名称+票价+车票类型+经手人+购买时间
数据流量：
约8张/日
高峰流量：
约15张/日
数据流编号：
D--2
数据流名称：
收款凭证
简述：
经登记处填好的收款凭证
数据流来源：
登记处审核处理
数据流去向：
售票员
数据项组成：
乘客名称+票价+车票类型+经手人+购买时间
数据流量：
约8张/日
高峰流量：
约15张/日
数据流编号：
D--3
数据流名称：
收费单
简述：
由售票员填好的收费单
数据流来源：
售票员
数据流去向：
会计人员审核登记处理
数据项组成：
乘客名称+票价+车票类型+经手人+购买时间
数据流量：
约2张/周
高峰流量：
约4张/周
（二）处理逻辑的描述
处理逻辑编号：
P--1
处理逻辑名称：
购票单审核
简述：
审核购票单
输入的数据流：
购票单
处理描述：
审核购票单，填写收款凭证
输出的数据流：
收款凭证
处理频率：
8次/日
处理逻辑编号：
P—2
处理逻辑名称：
会计人员审核登记处理
简述：
根据收费单将数据记入日报表
输入的数据流：
收费单
处理描述：
根据收费单将数据记入日报表，并更新相关数据
输出的数据流：
客流数据
处理频率：
8次/日
（三）数据存储的描述
数据存储编号：
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
小于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在输入数据不符合定义时
升级会员 