基于C#的出租车管理系统的设计与实现毕业设计论文.docx
《基于C#的出租车管理系统的设计与实现毕业设计论文.docx》由会员分享，可在线阅读，更多相关《基于C#的出租车管理系统的设计与实现毕业设计论文.docx（48页珍藏版）》请在冰豆网上搜索。
基于C#的出租车管理系统的设计与实现毕业设计论文
毕业设计（论文）
题目：
基于C#的出租车管理系统的设计与实现
中国石油大学
毕业设计（论文）任务书
发给学员
1．设计（论文）题目：
基于C#的出租车管理系统的设计与实现
2．学生完成设计（论文）期限：
2009年4月20日至2009年5月15日
3．设计（论文）课题要求：
要求对出租车公司进行调查，根据公司提供的要求进行设计，要求基本的录入功能、查询功能、修改功能、统计及打印等。
在毕业设计中，使用自己掌握的C#语言做前台开发工具，用SQLServer或ACCESS做数据库做后台，进行C/S或B/S结构的编程。
在设计过程中，做到真正的C/S或B/S结构。
数据库的规范程序要求至少达到三范式。
4．实验（上机、调研）部分要求内容：
（1）实现用户管理（用户添加、删除、密码设置与修改）和用户权限管理；
（2）实现对论坛信息进行分类和管理；
（3）可实现对论坛信息进行各种查询（精确、模糊、组合）；
（4）管理员可对留言进行添加、删除、修改等操作；
（5）系统应做到页面美观，操作方便。
5．文献查阅要求：
（1）《SQLserver实用教程》，郑阿奇，电子工业出版社；
（2）《数据库原理与应用》，周中华，清华大学出版社；
（3）《数据库原理及设计》，陶宏才，清华大学出版社；
（4）《SQLServer2000实用教程》，范立南，清华大学出版社；
6．发出日期：
2009年4月20日
7．学员完成日期：
2009年5月15日
指导教师签名：
_
学生签名：
摘要
本论文主要介绍了出租车公司管理信息系统的开发过程，开发过程中遵循了软件工程的方法，运用管理信息系统开发的原理和方法，结合管理思想，设计和实现了出租车管理系统。
该系统主要采用C/S（客户端/服务器）模式，前台采用C#，后台采用sql2000数据库来实现。
论文详细论述了系统总体设计思想、数据库设计以及功能模块设计等，给出了出租车管理系统的一般流程，实现了营运汇总和打印报表等功能
该系统的开发和运用使用户从原有的手工操作方式转换为数字化的信息管理方式，大大提高工作效率和准确性。
本系统能够实现未来出租车管理规范化、系统化和自动化，并且在操作上实现简单、方便、快捷。
关键词：
出租车管理系统，出租车，windows应用程序，MIS,管理系统
第1章前言
随着生产社会化趋势的扩大、科学技术的进步以及市场竞争的日益激烈，人们对信息的认识产生了根本性的变化。
信息被列为与物质、能源并列的人类社会发展的三大资源之一。
信息化水平已成为衡量一个国家现代化水平和综合国力的重要标志。
我国也正处于改革开放进一步深化的环境下，因此我们应当抓住机遇，充分利用信息，扎实的做好信息管理系统的基础工作，建设开发较为先进的应用系统，加快我国信息化建设的步伐。
改革开放以来来，随着加入WTO，社会生活节奏日益加快，出租车行业使得人们以车代步，提高出行效率，同时也随之不断地发展。
为了更好地服务于广大乘客，各大出租车公司先后搭建了各类信息管理系统，诸如叫车系统，客服系统等，逐渐形成了数字化租车的管理概念。
即以网络化管理为基本模式，以信息为出租车行业发展的基本动力，以信息技术为增强出租车公司竞争实力的基本手段，以信息化建设为出租车公司发展的新增长点，以信息文化改变着人们教育、工作方式和思想观念。
从而根本上实现了服务于广大乘客，提高出租车公司各项工作的效率和质量，为出租车公司创造经济效益。
司机和出租车辆是出租车公司最主要的资源，是创造效益的源泉。
要想提高出租车公司的效益和服务质量，首先从做好对司机和车辆的管理着手。
一个是做好司机非现金营运收入的清算工作，司机的人身保险等福利工作，二是做好车辆的保险和维修工作。
基本此种需要出租车管理系统，将在很大程度上解决出租车公司在此工作上的难度。
本文所描述的“出租车管理系统”，是根据某出租车公司的管理系统需求为基础展开需求调研，并在一定程度上考虑了它的可扩展性，使系统开发完成后，通过少量的改造，可以适用于其他出租车公司。
第2章系统分析
系统分析主要是对现行系统进行充分的调查研究，细致了解现行系统的现状和业务流程，及其存在的主要问题，在此基础上提出新系统的逻辑模型。
系统分析主要包括以下几个步骤：
1.企业简介和基本情况
2.可行性研究
3.软件系统的总目标
2.1企业简介和基本情况
为了了解系统的基本情况，首先进行了初步调查。
初步调查的主要方式是参阅公司的相关文档资料，再与各分部的人员进行口头交谈，并了解业务流程。
2.1.1组织层次图介绍
企业管理是通过各级管理机构和人来实现的，MIS（管理信息系统）系统也是靠机构和人实现的。
为了实现有效管理必须了解管理模式，使系统分析员进一步了解调查的对象。
公司的组织层次如图2-1所示：
图2-1组织机构图
2.1.2系统开发的基本环境
出租车公司已有一套读卡系统，由出租车计价器厂商为其提供。
此读卡系统主要负责将司机的IC卡营运收入通过读卡系统读取，并生成司机当日的IC卡营运收入数据文件。
司机通过读卡系统自行将其IC卡营业收入读入到系统中，车队管理部负责对此信息进行处理。
其次，出租车公司也与保险公司和维护公司建立起合作关系，对司机、车辆进行保险和维修已建立起业务关系。
2.1.3目前面临的问题
1.没有专门的计算机信息管理系统，司机将IC卡营业收入读入到系统中之后，由财务部人员收集，通过手工的方式核对后发放现金。
2.司机等待核对的时间长，最后拿到营业收入往往需要等待较长时间。
3.对于司机和车辆的保险信息，完全由手工处理，没有进行电子化管理，不利于建立档案，信息跟踪和统计。
4.系统设计同时要考虑与银行的接口，和与保险公司、维修公司的接口。
2.2可行性分析
系统可行性分析的任务是在初步调查的基础上确定项目开发是否必要和可行。
此活动的主要目标是进一步明确系统的目标、规模与功能，对系统开发背景、必要性和意义进行调查分析并根据需要和可能提出拟开发系统的初步方案与计划。
可行性研究是针对系统进行全面、概要的分析，主要包括三方面：
技术可行性、经济可行性和营运可行性。
可行性研究报告是系统研制人员在可行性研究工作阶段的成果。
一经讨论、审定通过后，根据确定的系统方案对系统开发者下达系统设计任务书，对新系统开发工作的可行性做出结论或提出建议。
2.2.1经济可行性
主要是对项目的经济效益进行评价，一方面是支出的费用，其中包括设备购置费、软件开发费、管理维护费、人员工资和培训费等。
另一方面是取得的收益中可以用钱来衡量的那部分（收益的另一部分难以用钱来表示）。
该公司目前已有一套读卡系统，财务部现有的计算机及配套设备，可以作为新系统的设备，无需另行投资。
系统建成后，将大大减少重复性的手工劳动，降低办公费用，提高工作效率，与前期的投入相比，后期的收益将更为乐观。
2.2.2技术可行性
技术上的可行性分析主要分析现有技术条件能否顺利完成开发工作，软、硬件配置能否满足开发者需要等。
公司目前已有一套读卡系统，并能成生为新系统所使用的接口数据文件。
与银行的代发接口文件格式也与银行谈定，可以按照接口规范进行接口文件的生成。
公司已有的PC机及打印设备，其容量、速度能满足系统需要。
公司有专业的IT人员，对公司信息系统和IT设备有维护的能力。
本系统采用Windows操作系统平台，C#编程语言和sql2000数据库，采用MicrosoftVisualStudio2005作为开发平台。
2.2.3营运可行性
主要是管理人员对开发信息系统是否支持，现有管理制度和方法是否科学，规章制度是否齐全，原始数据是否正确等。
公司领导非常重视信息系统的建设，对于系统的开发给予了大量的支持，中层管理人员对此也有共识，最终操作人员对新系统也表示欢迎。
系统建成后，虽然将改变原有的工作方式，但系统操作简单、易于理解，操作人员经过短时间的培训就可以使用该系统。
2.2.4结论
综上所述，该出租车管理系统值得开发。
第3章需求分析
3.1功能需求
公司希望建立一套管理系统，以准确地采集出司机的营运收入，司机、车辆的保险记录和车辆的维修记录数据。
同时，又与银行达成协议，对于司机的营运收入，由公司出具代发文件，将其营运收入由银行代发至司机在银行开立的帐户中。
公司希望通过此系统，快速准确地将司机的非现金收入发放到司机的银行帐户中，以此做好司机的工作。
同时，希望利用此系统，将司机、车辆的保险记录信息和车辆的维修记录信息，以电子化的方面进行处理、存储，便于整理、归档、分析和统计，从而提高工作效率和规范管理。
通过以上的调查分析，新系统注重基础信息的采集，包括司机日营运收入数据的采集，司机基本信息、车辆基本信息的采集工作。
做好与银行、保险公司和维修公司的接口，规范工作流程，尽量减少财务人员的手工工作，提高各岗位的工作效率、充分利用公司资源，使其能为更多的司机和车辆提供优质的服务同时为公司创造更多的经济效益和社会效益。
这是本次系统开发目标。
3.2数据流图
数据流图（dateflowdiagram,DFD），是描述数据处理过程的工具，它从数据传递和加工的角度，以图形方式刻画数据流从输入到输出的移动变换过程。
由于图形描述简明、清晰，所描述的内容面向用户，是系统分析员和用户进行交流的有效手段。
数据流图的四种基本元素为：
外部实体：
系统外与系统有联系的人或单位
数据流：
流动的一向或一组数据，也表示数据文件的存储操作
处理：
也成为功能，它对输入数据流进行处理，形成输出数据流
数据存储：
用于存储数据的文件等
符号说明如下图：
图3-1数据流图符号说明
3.2.1关联图
系统关联图如图3-2所示，由图可知系统共涉及三个外部项。
图3-2系统关联图
3.2.2顶层数据流图
顶层数据流图如图3-3所示，由图可以看见整个系统的信息处理功能划分为三个主要部分，分别是：
日营运汇总，保险管理，车辆维修管理。
日营业汇总主要功能：
将司机的日营业收入通过读卡系统导出的数据文件导入到系统中，同车辆管理部递交的司机补充营运收入数据一起根据司机的银行帐号生成日营业汇总记录，并导出为日营业代发文件。
保险管理主要功能：
包括司机人身保险管理和车辆保险管理。
根据车辆管理部整理的司机基本信息和车辆基本信息，建立司机保单记录和车辆保单记录，生成保单给保险公司。
统计保单信息给总经理审核。
车辆维修管理主要功能：
根据车队管理部整理的车辆基本信息，建立车辆维修记录档案，生成维修申请单交给维修公司，同时统计出车辆维修统计报表给总经理审核。
D1：
司机营运记录表D2：
车辆营运里程记录表D3：
车辆保险记录表F1：
IC卡日营运记录
F2：
司机补充营运记录F4：
日营运汇总记录F7：
车辆基本信息F8：
司机保险记录
F5:
日营运代发文件F9：
司机保单F10：
车辆保险记录F12：
维修记录
F13：
司机营运里程记录F14：
车辆营运里程记录F18：
司机营运收入记录
F28：
维修记录统计报表F24：
车辆保险汇总记录F25：
车辆保险注销保单号
图3-3出租车管理系统顶层图
顶层图说明：
车队管理部将司机的IC卡营运收入和补充营运收入数据收集后交至财务部出纳员，出纳员根据银行返回的人员帐号文件，将营运数据与帐号配对后汇总成日营运汇总记录，并导出日营运代发文件，经校验无误后，发至银行。
由银行根据这份代发文件，将司机的IC卡营业收入代发至该司机的帐户中。
同时，日营运汇总统计出司机营运里程和车辆营运里程，供保险和维修管理参考。
对于司机人身保险，车队管理部将司机基本信息登记后，交给保险部，保险部根据每个司机的基本信息，结合该司机的营运里程信息建立每个司机的人身保险档案和保险单。
对于车辆保险，由车队管理部将车辆的基本信息整理后，交给保险部，保险部根据每部车辆的基本信息和车辆营运里程信息建立每部车辆的保险档案和保险单。
对于车辆维修，由车队管理部将车辆的基本信息整理后，交给维修部，维修部根据部车辆的基本信息和车辆营运里程信息建立每部车辆的维修档案。
3.2.3一层数据流图（日营运汇总）
系统的一层数据流图（日营运汇总）如图3-4所示：
D1：
司机营运里程记录表D2：
车辆营运里程记录表D3：
日营运汇总表
F1：
IC卡营运记录F2：
司机补充营运记录F4：
日营运汇总记录
F5：
日营运代发文件F9：
日营运汇总记录F13：
司机营运里程记录
F14：
车辆营运里程记录F15：
日营运导入记录
图3-4一层数据流图（日营运汇总）
3.2.4一层数据流图（保险管理）
如图3-5所示：
D1：
司机营运里程记录D2：
车辆营运里程记录D4：
司机保险记录表
D5：
车辆保险记录表F6：
司机基本信息F7：
车辆基本信息
F8：
司机保险记录F9：
司机保单F10：
车辆保险记录
F11：
车辆保单F13：
司机营运里程记录F14：
车辆营运里程记录
F22：
司机保险注销保单号F23：
司机保险汇总记录
F24：
车辆保险注销保单号F25：
车辆保险汇总记录
图3-5一层数据流图（保险管理）
3.2.5一层数据流图（车辆维修管理）
系统的一层数据流图（车辆维修管理）如图3-6所示：
P3.1
D2：
车辆营运里程记录D5：
车辆保险记录表D6：
维修记录表
F7：
车辆基本信息F10：
车辆保险记录F12：
维修记录
F14：
车辆营运里程F26：
车辆保险记录F27：
维修汇总记录
F28：
维修记录统计报表
图3-6一层数据流图（车辆维修管理）
3.3数据字典
数据字典的任务是对与系统相关的元素的一个定义、解释、说明，目的是为了便于用户和系统分析员理解系统。
编写数据字典要求定义严密、精确，不可半点含糊，不可有二义性。
本系统的数据字典如下：
文件名：
管理员文件
描述：
以序号为记录主键的关系型数据表
组成：
管理员=序号+用户名+密码+角色
文件名：
用户文件
描述：
以序号为记录主键的关系型数据表
组成：
用户=序号+用户名+密码+角色
文件名：
车队文件
描述：
车队编号为记录主键的关系型数据表
组成：
车队=车队编号+车队名称+车队地址+车队电话
文件名：
司机文件
描述：
以工号为记录主键的关系型数据表
组成：
司机=工号+姓名+性别+年龄+驾照号+车队编号#+保单号+保险公司编号＃+险种+金额
文件名：
车辆文件
描述：
以车辆编号为记录主键的关系型数据表
组成：
车辆=车辆编号、牌照号、车型、车队编号＃、保单号、保险公司编号＃、险种、金额
文件名：
保险公司文件
描述：
以保险公司编号为记录主键的关系型数据表
组成：
保险公司=序号+用户名+密码+角色
文件名：
维修公司文件
描述：
以维修公司编号为记录主键的关系型数据表
组成：
维修公司=维修公司编+名称+地址+电话+联系人
文件名：
营运文件
描述：
以营运单据号为记录主键的关系型数据表
组成：
营运=营运单据号+车辆编号＃+工号＃+日期+单价+里程+金额
文件名：
车辆维修记录文件
描述：
以维修单号为记录主键的关系型数据表
组成：
车辆维修记录=维修单号、车辆编号＃、维修公司编号＃、维修类型、维修日期、维修金额
第4章概要设计
4.1概述
系统设计是将系统分析阶段所提出的反映用户需求的逻辑方案转化为可供实施的物理方案。
根据系统分析提出的逻辑功能要求，结合实际经济、技术和环境条件。
确定系统总体结构和物理方案、合理选择硬件、确保系统目标得以实现。
系统设计是在系统分析的基础上由抽象到具体的过程。
系统设计的原则：
严格按照系统说明书所规定的目标、任务和逻辑功能进行设计工作，遵守信息管理和信息技术的有关规范，在充分尊重和理解用户要求的基础上，使设计尽可能满足用户操作使用方面的要求。
系统设计的目标：
系统分析阶段多提出的反映了用户信息需求的系统逻辑方案转换成可以实施的基于计算机与通信系统的技术方案。
系统设计的方法：
采用基于将系统分解成相对独立模块的结构化设计方法。
4.2系统总体布局方案
系统总体结构设计要完成的任务是确定整个系统由哪些组成部分，以及各部分在物理上、逻辑上的相互关系。
系统总体结构是指整个系统有哪些部分组成，以及各部分在物理上，逻辑上的相互关系，包括硬件部分和软件部分。
而系统的总体布局是指系统的硬软件资源的数据资源在空间上的分布特性，本系统采用集中式结构有利于资源的统一管理和共享。
4.3软件模块结构设计
系统软件功能结构的设计采用结构化设计方法（SD—StructuredDesign）。
SD是基于模块化、自顶向下逐层细化、结构化程序设计等技术发展而来的。
模块设计时主要考虑尽量提高模块功能的独立性与简化模块之间的接口，采用以变换为中心和以实物为中心相结合的分析方法进行模块设计。
总体结构图如4-1所示：
图4-1系统总体功能图
各子系统模块功能如下图：
图4-2日营运汇总
图4-3保险管理
图4-4车辆维修管理
图4-5系统维护
4.4数据库设计
数据库设计是在选定的数据库管理系统基础上建立数据库的过程。
经过系统分析阶段的工作，已对现行管理系统的信息处理步骤和方法都已掌握。
在对系统分析阶段的工作成果：
数据流图、数据字典进一步分析的基础上，使用实体关系图（E-R图）工具对整个系统的数据库结构进行设计。
E-R图是由实体、属性、联系三部分组成，其符号如图4-6所示：
图4-6E-R图符号说明
4.4.1E-R图的实体及其属性
本系统中有5个实体，每个实体的属性如下：
车队（车队编号、车队名称、车队地址、车队电话）
司机（工号、姓名、性别、年龄、驾照号）
车辆（车辆编号、牌照号、车型）
保险公司（保险公司编号、名称、地址、电话、联系人）
维修公司（维修公司编号、名称、地址、电话、联系人）
4.4.2实体之间的联系
实体之间的联系如下：
1.车队和司机是一对多的关系：
即车队可以有多个司机。
2.车队和车辆是一对多的关系：
即车队拥有多部车辆。
3.司机和保险公司是多对一的关系：
即多个司机在一家保险公司保险。
4.车辆和保险公司是多对一的关系：
即多部车辆在一家保险公司保险。
5.车辆和维修公司是多对一的关系：
即多部车辆在一家维修公司维修。
6.司机和车辆是多对多的关系：
即一个司机可以驾驶多部车辆，一部车辆可以被多个司机驾驶。
联系的属性如下：
1.司机人身保险（保单号、险种、金额）
2.车辆保险（保单号、险种、金额）
3.营运（营运单据号、日期、单价、里程、金额）
4.维修（维修单号、维修类型、维修日期、维修金额）
4.4.3系统的E-R图
图4-7E-R图
4.4.4关系转换规则
E-R图向关系模型的转化要解决的问题是如何将实体和实体间的联系转换为关系模式，如何确定这些关系模式的属性和码。
对于实体，将每个实体转换为一个关系，实体的属性即为关系的属性，实体的码即为关系的码。
对于实体间的联系，有以下三种不同的情况：
1.若实体间的联系是1：
1，可以在两个实体转换成的两个关系中任意一个关系的属性中加入另一个关系的码。
2.若实体间的联系为1：
n，则在n端实体转换成的关系中加入1端实体转换成的关系码。
3.若实体间的联系是n：
m，则将联系转换为关系，关系的属性为诸个实体的码加上联系具有的属性，而关系的码则为诸实体的码的组合。
4.4.5关系模式
由E-R图向关系模型的转换（主键用“__”表示，外键用“＃”表示）
1.车队（车队编号、车队名称、车队地址、车队电话）
2.司机（工号、姓名、性别、年龄、驾照号，车队编号＃、保单号、保险公司编号＃、险种、金额）
3.车辆（车辆编号、牌照号、车型、车队编号＃、保单号、保险公司编号＃、险种、金额）
4.保险公司（保险公司编号、名称、地址、电话、联系人）
5.维修公司（维修公司编号、名称、地址、电话、联系人）
6.营运（营运单据号、车辆编号＃、工号＃、日期、单价、里程、金额）
7.车辆维修记录（维修单号、车辆编号＃、维修公司编号＃、维修类型、维修日期、维修金额）
这个模式中，6个联系分别转换为以上6个关系。
车辆和维修公司是多对一的关系，但由于一部车辆可以在维修公司里进行多次维修，因此也转换为一个关系，共有7个关系。
第5章详细设计
5.1表设计
进一步确定以上关系模式中各个数据项的类型和长度，将每个关系转换为数据库中的二维表格，并确定了各个表的主码和外来码，得到以下表结构：
表5-1车队表
表5-2司机表
表5-3车辆表
表5-4保险公司表
表5-5维修公司表
表5-6营运表
表5-7车辆维修记录表
5.2程序流程图
5.2.1程序设计
在绘制程序框图时，使用的符号说明如下：
图5-8程序流程图符号说明
图5-9系统程序流程图
图5-10日营运统计子系统流程图：
5.2.2编程的过程及特色
程序的编写是按照详细设计阶段产生的程序设计说明书，及选定的程序设计语言书写程序。
在程序设计过程中，不仅要保证程序的正确性，而且要保证程序的可读性，为以后的维护提供方便。
本系统在主框架的模块上采用自顶向下的方式，把系统的功能按照模块化和逐步细分的方法分解到最小的控制。
在界面的设计上采用面向对象的方式，先设计底层模块，把有共性的界面设计，功能放在底层模块统一处理。
这样既保证了界面的统一性，减少了编程的工作量，同时也方便了修改。
许多修改只要在底层模块统一完成，不必一一修改。
本系统所采用的开发工具是MicrosoftVisualStudio2005它是目前国内外流行的前端开发工具，是目前开发Windows应用程序较好的工具之一。
MicrosoftVisualStudio2005采用可视化的程序设计方法，面向对象的程序设计思想，事件驱动的编程机制，具有高度的可扩充性，支持大型数据库的连接与存取操作。
MicrosoftVisualStudio2005还支持动态数据交换、对象的链接与嵌入等新型的编程技术。
5.3人机界面设计
界面设计是评价软件质量的一条重要指标,其目的是为了创造良好的用户环境，便于用户与系统交互。
界面设计应尽可能简单，便于非专业人员快速掌握系统的使用方法。
本系统在设计时充分考虑到操作易用性及准确性，采用了人机对话方式。
人机对话是计算机的一种工作方式，即计算机操作员或用户与计算机之间，通过控制台或终端显示屏幕，以对话方式进行工作。
操作员可用命令或命令过程告诉计算机执行某一任务。
人机对话的方式主要是键盘—屏幕方式。
本系统的登录界面如图5-11所示：
图5-11登陆界面
5.3.1主界面
图5-12主界面
5.3.2IC卡日营运导入界面
图5-13IC卡日营运导入界面
5.3.3日营运增加界面
图5-14日营运增加界面
5.3.4修改密码界面
图5-15修改密码界面
5.3.5锁定窗体界面
图5-16锁定窗体界面
5.3.6日营运汇总报表
图5-17日营运汇总界面
第6章系统实现
6.1概述
系统实现是在继承此前阶段系统分析与设计工作成果的基础上，将逻辑的设计转化为可以实际运行的物理系统的阶段。
6.2环境与工具
硬件环境：
P4以上主机
128M以上内存
10G以上硬盘空间
VGA高分辨率显
升级会员 