车辆管理系统

1、目目 录录摘摘 要要.I序序 言言.II1 可行性分析可行性分析.11.1 问题描述.11.2 可行性分析研究.11.2.1 技术可行性.11.2.2 经济可行性.21.2.3 操作可行性.21.3 结论意见.22 项目开发计划项目开发计划.32.1 编写目的.32.2 项目背景.32.3 项目概述.32.4 项目开发计划.43 需求分析需求分析.53.1 任务需求分析.53.2 数据流图、数据字典及实体联系图.63.2.1 数据流图.63.2.2 数据字典.73.2.3 实体联系 E-R 图.84 系统概要设计系统概要设计.134.1 总体设计.134.2 系统功能模块图.134.3 数据库

2、概念设计.144.4 数据库逻辑结构设计.14i4.5 连接数据库的特点.175 详细设计详细设计.185.1 系统的主要功能.185.2 程序流程图.205.3 用户界面设计.235.3.1 一般交互设计.235.3.2 信息显示设计.235.3.3 数据输入设计.245.4 程序设计过程.245.4.1 各模块功能及截图.246 软件测试软件测试.286.1 测试目标和方法.286.2 测试用例.28设计总结设计总结.33参考文献参考文献.34致致 谢谢.35摘摘 要要面对国内汽车数量的不断增加，在人们的生活中，机动车辆是我们每天都离不开的交通工具，因此，我们要想能更好的使用它们，充分的发

3、挥它们的作用，使其能更好的服务于社会，就应该有一个良好的车辆管理系统。车辆综合业务管理系统的主要作用是对于一个中等规模的、独立运营的车队实现车辆调度和车队综合业务的有效管理。在对车队的车辆调度、驾驶员管理、车辆管理以及业务管理.本系统分为业务模块和系统模块。业务模块包括：订单管理模块、车辆信息管理模块、驾驶员管理模块，这三个模块都有各自的子模块，在每个子模块里都实现了相关信息的新建、保存、删除、查询功能;系统模块包括：数据备份模块、数据库恢复、修改密码模块、退出系统，这些为管理员提供更完善的系统管理支持。关键词关键词：机关车辆管理；VB; Access序序 言言随着现代化管理手段的进步和科学技

4、术的日益发展，用户对车辆管理的要求越来越高。过去的人工管理方式已经不适应现代化发展的需要，针对目前快节奏，高速度的工作模式，要求管理方法和制度要有一个根本的改善，这种改善要适应用拥有各种类型车辆的机关企事业单位，车辆的管理 成为日常事务中的一项重要工作。如何让事务管理人员及时了解每一辆车的情况，合理安排员工的车辆使用要求，提高车辆的使用效率，就成为各单位亟待解决的一个难题。针对这种状况，很多大型企业集团提出了车辆管理系统建设要求，希望通过系统建设实现有效的车辆档案管理、车辆调度管理、费用管理、司机管理、车辆成本核算、车务管理及智能预警等。本系统开发的主要目的就是要提高车辆及其业务管理质量及效率

5、，从而提高企业的经济效益。车辆综合业务管理是一项琐碎、复杂而又十分细致的工作。手工进行公司日常的车辆录入，订单订购，车辆调度等工作，很容易出现问题。正是车辆综合业务管理的这种重复性、规律性、时间性，使得车辆综合业务管理的 计算机信息化成为可能。让计算机进行以上所说的工作，不仅能够保证车辆的调度正确无误，而且还可以严格规范企业的应收应付管理，并利用先进的管理模式，推动企业的快速发展，实现企业管理工作的系统化、规范化和自动化。1 1 可行性分析可行性分析1.11.1 问题描述问题描述随着科学技术的发展，社会进步，计算机迅速的发展,车辆综合业务管理的方法也日新月异,以前全是由人工管理的方法现存在很多

6、的缺点：管理效率低，劳动强度大，信息处理速度低而且准确率也不够令人满意，车辆管理工作是商业管理工作中的一项重要内容，数据量庞大，这项工作原来一直是采用手工的方式进行记录与统计，是一项工作任务繁重、耗费大量人才和物力而且容易出现失误的工作。尤其现在经营规模越来越大，客户越来越多，这一问题愈加明显，因此在计算机飞速发展的今天，应用数据库技术实现客户信息的计算机管理是可行而必要的工作。在各大中小商业系统中，用计算机管理的信息已经越来越普遍了，不但可以提高工作效率，节省人力物力，而且还增强了客户资料的安全性，提高管理水平。1.21.2 可行性分析研究可行性分析研究并不是所有问题当接受一个软件开发任务，

7、就进入软件生命的第一个阶段，即进行可行性的研究。具有简单的解决办法，许多问题不能在预定的规模之内解决。因此通过可行性的研究分析可以知道问题。有无可行性的解决方法，进而避免人力、物力和才力的浪费。在现行系统初步调查的基础上就可以提出新系统目标，即新系统建立后所要求达到的运行指标，这是系统开发和评价的依据。系统目标应充分体现，直接为车辆综合业务管理系统服务，并且程序可以分期分批实现。但是需要指出的是，系统目标是不可能在总体规划阶段就提得非常具体，它还将在开发过程中逐步明确和定量化，以达到更加出色的程序系统。1.2.11.2.1 技术可行性技术可行性技术上的可行性分析主要分析现有技术条件能否顺利完成

8、开发工作，硬、软件配置能否满足开发者需要等。根据客户提出的系统功能、性能及实现系统的各项约束条件，根据新系统目标来衡量所需的技术是否具备。本系统是一个数据库管理和查询的系统，现有的技术已较为成熟，硬件、软件的性能要求、环境条件等各项条件良好，估计利用现有技术条件应完全可以达到该系统的功能目标。同时，考虑给予的开发期限也较为充裕，预计系统是可以在规定期限内完成开发。1.2.21.2.2 经济可行性经济可行性对车辆综合业务管理系统的经济效益进行评价，一方面是估算开发它的支出费用，其中包括设备购置费、软件开发费、管理和维护费、人员工资和培训费等。另一方面是估算车辆综合业务管理这个软件可能取得的收益中

9、可以用钱来衡量的那部分，并对目前的软件市场进行调查,所做软件是否有很大的销售市场和相当规模的用户群。所做软件的开发成本与客户提出的要求是否可达到双方都满意。并且，分析系统开发是否会对其它产品或利润带来一定影响。经过对上述几个方面的调查研究和分析，应用此系统将会在很多时候，很大程度节省人力，财力，提高效率，清晰明了的报表资料，高效的数据处理等，而开发时期并不耗费很多人力，财力，故在经济方面既不会有困难同时又有很大的价值。1.2.31.2.3 操作可行性操作可行性本系统的界面比较美观、友好、操作简单、方便，同时，系统运行速度较快，对计算机的硬件环境要求不是很高，能够完成汽车维修管理的大部分工作。系

10、统提供了从维修业务到售后服务完整一体的功能，涵盖了订单管理，车辆管理，驾驶员管理，业务管理等管理功能，为企业的日常工作管理提供一个功能齐全的平台。软件提供的各种业务运行数据，统计报表，辅助决策支持，综合查询等功能，为企业的经营决策提供了大量的实用信息。一体化的设计方案，突破了单一应用的局限实现了业务，资金，决策一体化，做到物流，资金流，信息流的统一。支持 Internet 远程数据传送，使软件在局域网应用的基础上，实现跨空间的信息管理，解决了企业规模扩大和经营模式改变对系统拓展性的要求，同时软件提供各种接口，能够将软件拓展为一个完整的企业管理平台。1.31.3 结论意见结论意见 经过认真地可行

11、性研究，系统基本上做到了在技术、经济、运行、法律上的可行。因此，相信在按照计划上实施的前提下，全系统的设计将会按时、高质量的完成。所以，系统研制和开发是可以马上进行的。2 2 项目开发计划项目开发计划2.12.1 编写目的编写目的编写的目的是使独立运营的车队由单一的人工管理到计算机管理的飞跃，使车队的管理的效率得到很大的提高，使人工管理的出错的机会大大减少，实现数据的共享，便于查询自己的数据信息，使车队的业务的流程时间大大减少，从而可以提高该车队在同行业中的竞争性，在社会有立足之地。2.22.2 项目背景项目背景在计算机不断发展的今天，计算机已经运用到各个领域，由手工的操作到计算机的操作是一个

12、大的飞跃，代替了复杂的容易出错的人工操作，节省了大量的时间，提高了正确性，提高了数据的可靠性。因此每个公司使用计算机建立自己的业务是迫在眉睫，各种企业的汽车管理部门以及独立经营的车队根据业务发展的需要，决定建立一个数据库管理系统，以代替单一的人工管理。这样使人工操作的管理方便，简单。2.32.3 项目概述项目概述1.工作内容让计算机对车辆综合业务进行自动管理，用户可以直接在计算机上实现车辆综合业务的信息管理，并能在一定程度上实现自动化。 2.条件与限制开发该软件的条件比较简单，以开发单位目前的经济与技术条件已完全具备开发的条件。该系统可在用户要求的期限内完成。 3.产品 （1）程序 该项目因开

13、发时间较短，这里只给出设计思想，具体程序没写。 （2）文档文档内容包括： 封面 目录 中文摘要 100 字左右；关键词 3-5 个 序言 可行性分析 项目开发计划 需求规格说明（包含需要的系统流程图、数据流程图、数据字典、E-R 图） 概要设计（包含总体软件结构图、总体数据结构） 详细设计（对概要设计内容进行详细设计） 设计总结、参考文献、致谢等4.验收标准软件的验收标准完全由用户提出的软件需求制定，能保证软件的基本符合用户的要求。 2.42.4 项目开发计划项目开发计划1.任务分解分三个大的阶段进行开发第一阶段完成本系统的数据流图跟 E-R 图。第二阶段完成概要设计跟详细设计。第三阶段书写文

14、档。 2.预算软件资金投入较少，具体预算分配简略。 3.关键问题各模块之间的联系和后台数据库的完成。使用目前的设备与现有开发技术完全可以开发出该系统，总的来说该项目没有较大的技术难点与其他的一些风险因素。对于出现的一些小难点总都能得到解决。3 3 需求分析需求分析3.13.1 任务需求分析任务需求分析在进行一个项目的设计之前，先要进行必要的需求分析，需求分析在软件的开发过程中至关重要。车队需要管理车队内的各种车辆的基本信息、不同客户的基本信息、各种订单的基本信息以及驾驶员的情况，希望实现办公的信息化，通过建立一个车辆综合管理系统来有序的管理。经分析先给出该系统的系统流程图，如图 3.1 所示：

15、 图 3.1 系统流程图通过查询的到车辆管理的基本需求有:1.建立车辆信息库，实现车辆基本情况和驾驶员基本信息的统一管理。2.针对每辆车的派车、用车情况进行记录，实现车辆自动调度。3.对每辆车的事故、违规情况进行记录。4.对每辆车的保险、保养、加油等日常费用情况进行记录。5.建立维修情况信息库，针对每辆车的维修情况进行记录。围绕上述要求，以下介绍如何利用计算机管理信息系统，建立车辆、驾驶员档案，对车辆营运、维修以及燃料消耗进行记录，为专职管理人员对车辆的管理、跟踪车辆的相关信息资料提供极大的方便。系统不仅合理记录了所有车辆的进出、维修等，还可随时了解每部车的经费支出情况，及为车辆是否需要大修理

16、和报废提供依据，对系统登陆普通管理员管理员数据恢复数据备份驾驶员档案清空运营表管理员设置系统初始化车辆档案车辆报废车辆维修车辆违章车辆事故车辆运营运营查询有关数据（成本、效益、单车、车型等）可以进行综合统计分析，生成相关的报表。3.23.2 数据流图、数据字典及实体联系图数据流图、数据字典及实体联系图3.2.1 数据流图数据流图数据流图由四种基本的元素构成：数据流(Data Flow)，处理(Process)，数据存储和数据源（数据终点） 。数据流(Data Flow)：为具有名称且有流向的数据，用标有名称的箭头表示，一个数据可以是记录、组合项或基本项。处理(Process)：表示对数据所进行

17、的加工和变换，在图中用矩形框表示。指向处理数据流为该处理的输入数据，离开处理的数据为处理的输出数据。数据存储：表示用文件方式或数据库形式所存储的数据，堆砌进行的存取分别以指向或离开数据存储的箭头表示。数据源及数据终点：表示数据的来源或数据的去向，可以是一个组织或人员，它处于系统范围之外，所以又称它为外部实体，它是为了帮助理解系统界面而引入的，一般只出现在数据流图的起点和终点。该系统总体数据流图如图 3.2 所示：图 3.2 系统总体数据流图机关内部其它部门驾驶员技术学院派车技术学院出车任务通知单出车任务记录车辆管理部门接受用车申请车辆管理部门记录出车情况车辆调度员进行车辆调度完成出车任务申请有

18、关人员填写执行任务3.2.23.2.2 数据字典数据字典数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。由于本次设计是小型软件系统的开发，所以采用卡片形式书写数据字典。每张卡片上保存描述一个数据的信息这样做更新和修改起来比较方便，而且能单独处理描述每个数据的信息。下面将列出若干数据元素的数据卡片信息。数据字典卡片：名字：车辆信息别名：描述：对于车辆属性的具体描述定义：车辆信息=牌照号码+车辆卡编号+车型+厂家型号+车辆名称+燃料种类+车架编号+出厂日期+载客人数+载货量+购车日期+购车单位+使用部门+资产所属部门+是否空闲位置：输出到打印机保存到磁盘名称：出车记录

19、单别名：描述：每次出车时的记录定义：出车记录单=出车记录编号+车辆卡编号+驾驶员编号+记录状态+用车部门+用车人+同行人数+用车起始时间+预计用时+用车结束时间+备注位置：输出到打印机保存到磁盘名称：驾驶员资料别名：描述：对于车队中驾驶员属性描述定义：驾驶员资料=驾驶员编号+姓名+性别工作类别+薪酬+身份证号码+工作单位+所属部门+家庭住址+联系电话+是否空闲位置：输出到打印机保存到磁盘名字：车辆费用记录别名：描述：车辆的费用和缴纳费用定义：车辆卡编号+费用名称+费用额+缴费日期+经手人+备注位置：输出到打印机保存到磁盘3.2.33.2.3 实体联系实体联系 E-RE-R 图图根据对数据流图和

20、数据字典的分析，我们可以确定该应用中的实体，属性和实体之间的关系，并画出如下所示的 E-R 图。汽车实体图如图 3.3 所示：图 3.3 汽车实体图名称：车辆维修单记录单别名：描述：车辆维修时记录的单据定义：车辆卡编号+结算清单编号+进厂日期+出厂日期+修理厂名称+报修人+验收人+验收日期+报修费用+实付费用+发票日期位置：输出到打印机保存到磁盘名字：车辆事故登记单别名：描述：车辆发生事故登记表单定义：车辆卡编号+驾驶证号码+事故当事人+事故发生时间+事故地点+赔偿金额+保险赔付金额+本单位负担金额+事故处理单位+事故概括+报案日期+结案日期+本单位处理意见+上级部门处理意见+备注位置：输出到

21、打印机保存到磁盘车辆车牌号车辆编号是否空闲燃料种类出厂日期车辆名称车辆型号下图是是驾驶员实体 E-R 如图 3.4 所示：图 3.4 驾驶员实体 E-R 图下图是车辆保险实体 E-R 图如图 3.5 所示图 3.5 车辆保险实体 E-R 图驾驶员性别车辆编号是否空闲驾驶员号驾驶证号姓名联系电话出车是否出行驾驶员号同行人数出车记录记录状态预计用时用车时间车辆编号用车部门下图车辆维修实体 E-R 图如图 3.6 所示图 3.6 车辆维修实体 E-R 图下图是车辆事故实体 E-R 图如图 3.7 所示图 3.7 车辆事故实体 E-R 图维修是否出行驾驶员号同行人数出车记录记录状态预计用时用车时间车辆

22、编号用车部门车辆事故车牌号事故时间事故情况事故类型车辆编号驾驶员下图是车辆费用实体 E-R 图如图 3.8 所示图 3.8 车辆费用实体 E-R 图下图是车辆保险实体 E-R 图如图 3.9 所示图 3.9 车辆保险实体 E-R 图车辆费用缴费人经手人缴费日期费用名称车辆编号费用额车辆保险缴费人经手人缴费日期保险时间车辆编号保险额总 E-R 图如图 3.10 所示：图 3.10 总 E-R 图11nn11111nnn11车辆车辆保险车辆费用车辆事故投保缴纳发生承担出车驾驶员车辆维修发生承担指派1n4 4 系统概要设计系统概要设计4.14.1 总体设计总体设计系统概要设计的基本目的是用比较抽象的

23、概括方式确定系统如何完成预定的任务，也就是要确定系统的配置物理方案。软件结构设计时应该遵循的最主要的原理是模块独立，让模块彼此间的接口关系应该尽量简单。4.24.2 系统功能模块图系统功能模块图可以根据模块独立原理对软件结构进行精化。为了合理的分解，得到尽可能高的内聚、尽可能松散的耦合，最终要的是，为了得到一个易于实现、易于测试和易于维护的软件结构，应该对模块进行再分解或合并。系统功能模块图如图 4.1 所示：图 4.1 系统功能模块图车辆档案管理车辆管理车辆运营管理机关车辆管理系统系统维护驾驶员管理车辆档案录入车辆档案查询车辆运营列表车辆运营查询车辆维修管理车辆违章管理数据备份驾驶员档案驾驶

24、员档案查询管理员设置4.34.3 数据库概念设计数据库概念设计数据库一般分为三级模式：外模式、概念模式和内模式。外模式也就是不同用户所对的数据视图，它将数据库内部抽象的数据及其互相之间的关系表示为简单、直观的应用界面。概念模式是数据库中全部数据的逻辑结构和特征描述，通常以某种数据模型为基础。内模式是对数据的物理结构和存储方式的描述。在这里我们将要设计的是数据库的概念模式，通过对车辆综合业务管理系统的数据字典和数据流程分析及 E-R 图，设计如下数据项和数据结构。车辆信息：包括牌照号码、车辆卡编号、车型、厂家型号、车辆名称、燃料种类、车架编号、出厂日期、载客人数、载货量、购车日期、购车单位、使用

25、部门、资产所属部门、是否空闲。驾驶员信息：包括驾驶员编号、姓名、性别工作类别、薪酬、身份证号码、工作单位、所属部门、家庭住址、联系电话、是否空闲。出车记录信息：包括出车记录编号、车辆卡编号、驾驶员编号、记录状态、用车部门、用车人、同行人数、用车起始时、+预计用时、用车结束时间、备注。车辆保险信息:包括车辆卡编号、保单号码、保险公司、保险起始日期、保险总额、办理日期、经办人、车辆损失险、第三者责任险、车辆停驶松损失险、自然损失险、不计免赔特约险、其他险种。车辆费用信息：包括车辆卡编号、费用名称、费用额、缴费日期、经手人、备注。车辆修理信息：包括车辆卡编号、结算清单编号、进厂日期、出厂日期、修理厂

26、名称、报修、+验收人、验收日、报修费用、实付费用、发票日期。车辆事故信息：包括车辆卡编号、驾驶证号码、事故当事人、事故发生时间、事故地点、赔偿金额、保险赔付金额、本单位负担金额、事故处理单位、事故概括、报案日期、结案日期、本单位处理意见、上级部门处理意见、备注。数据库概念结构设计，是在需求分析的基础上，设计出能够满足用户需求的各种实体，以及他们之间的关系，为后面的逻辑结构设计打下基础。4.44.4 数据库逻辑结构设计数据库逻辑结构设计在数据库设计中相当重要的一步就是将概念模型转化为计算机上 DBMS 所支持的数据模型，例如，将 E-R 图模型转化为关系模型，道理很简单，我们设计概念模型基本上都

27、是一些抽象的关系，在再数据库设计的实现过程中，在计算机上有效地表示出这些关系就成了数据库设计的关键。根据车辆综合业务管理系统的功能要求，选取 Access 作为后台数据库。在上面的实体和实体之间的 E-R 图设计基础上，形成数据库中的表格及表格之间的关系。可以得到：1.车辆登记卡记录表如表 4.1 所示表 4.1 车辆登记卡记录表序号字段名称类型长度备注说明1车辆编号char62车型char103车牌号char204车辆名称char205燃料种类char106厂家型号char208车驾编号 7char209出厂日期date82. 驾驶员基本情况表如表 4.2 所示表 4.2 驾驶员基本情况表序

28、号字段名称类型长度备注说明1驾驶员编号char62姓名char203性别char24身份证号码char205联系电话char206家庭住址char207驾驶证号char123.出车记录情况表如表 4.3 所示表 4.3 出车记录情况表4.车辆费用记录表如表 4.4 所示表 4.4 车辆费用记录表8是否空闲logic1序号字段名称类型长度备注说明1出车记录char62车辆编号char203驾驶员编号char104记录状态char20已指派 未指派5用车部门char206用车人char107同行人数int108用车开始时间data9预计用时int410用车结束时间data11是否出行char5.车

29、辆维修记录表如表 4.5 所示序号字段名称类型长度备注说明1车辆编号char62费用名称char203费用额int134交费日期data85经手人char206缴费人char4表 4.5 车辆维修记录表4.54.5 连接数据库的特点连接数据库的特点当开发环境通过连接到数据库上之后，在设计中使用数据库画笔可实现对该数据库中表格，视图等的操作，如创建表,修改表，删除表，增加/删除记录。在应用程序中一般是在应用程序对象中书写连接数据库的程序代码，使得应用程序开始运行并实现与数据库的连接。序号字段名称类型长度备注说明1车辆编号int102维修单号int103进厂日期data84出厂日期data85报修

30、人char206验收人char207验收日期data208报修费用int1029修理厂名称char2010发票日期data85 5 详细设计详细设计详细设计阶段的根本目标是确定应该如何具体地实现所要求的系统，包括了用户界面设计、程序过程设计等步骤。5.15.1 系统的主要功能系统的主要功能系统主要功能：1.基础数据: （1）车辆基本资料数据维护子功能主要完成对车辆档案数据库的录入，用户可以增加、删除及修改数据库中的信息它包括输入：用户输入的车辆基本资料信息。处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。输出：车辆登记卡记录表 （2）驾驶员基本情况数据维护子功能完成

31、对本单位专职驾驶员基本情况数据的录入它包括输入：用户输入的驾驶员基本情况数据。处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。输出：驾驶员基本情况表。2.日常出车管理: 本功能模块主要实现出车任务从提出申请、调度员的调度、任务的完成等全过程的跟踪管理，它可以为车辆的管理工作提供有力依据，能真正达到统一监控管理的目的它包括： （1）录入派车单输入：用户输入的用车申请有关数据。处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。输出：出车情况记录表。 （2）车辆调度列出当前已输入但尚未落实的派车单，用户可以根据自己的需要，任意选择字段名或操作符，

32、系统将会把满足条件的车辆以表格的形式显示出“派车清单”， 该功能为车辆的调度工作带来了很大的方便，本功能同时支持多条件查询。用户查询空闲的车辆和人员资源，便可进行车辆和驾驶员的指派。输入：用户对派车单的指派指令。处理：根据用户的输入对数据库进行查询和更新。输出：出车情况记录表。 （3）撤销任务列出已指派但未执行的派车单，用户可撤销该项指派或更改指派内容。输入：用户对派车单的更改指令。处理：根据用户的输入对数据库进行查询和更新。输出：出车情况记录表。 （4）完成任务对已完成的出车任务，用户记录该次任务的完成情况。输入：用户输入的本次出车任务的详细情况。处理：根据用户的输入对数据库进行查询和更新。

33、输出：出车情况记录表。3. 车辆保险 ：记录车辆投保和保费的情况，此模块完成了车辆保险投保登记的功能。4. 事故管理 ：记录车辆在出车过程中发生的事故及处理情况，此模块完成了车辆的出险情况，包括出现地点、状况、事故处理情况、索赔状况进行详细记录。可以根据特定条件进行查询。5. 维修和费用管理 ：记录每辆车从购置到报废每次维修的情况，以及车辆发生的各种费用，包括油耗、年审等。此模块完成了车辆年检、养路费、加油费用的缴纳和开支情况，以及车辆维修内容、工时、费用等信息，实现了车辆维修的信息化管理。6. 统计分析 :对每辆车进行详细的统计分析，实现单车核算成本核算。此模块完成了统计每辆车的使用和保养情

34、况，包括用车记录、保险、费用缴纳情况、油耗记录等，还可以统计每位驾驶员的出车任务完成情况记录。7. 车辆基本资料数据维护子功能主要完成对车辆档案数据库的录入，用户可以增加、删除及修改数据库中的信息。输入：用户输入的车辆基本资料信息。处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。输出：车辆登记卡记录表8. 驾驶员基本情况数据维护子功能完成对本单位专职驾驶员基本情况数据的录入。输入：用户输入的驾驶员基本情况数据。处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。输出：驾驶员基本情况表。5.25.2 程序流程图程序流程图程序流程图的优点是对控制

35、流程的描绘很直观，易于掌握。换零件及零件进库程序流程图如图 5.1 所示：图 5.1 换零件程序流程图否是否否是换零件结束是否重新输入查询相应的零件是否存在 该 零 件是否换零件管理员输入查询条件是管理信息程序流程图如图 5.2 所示：图 5.2 管理信息程序流程图选择选择操作对象添加 修改 删除操作完成退出主界面管理信息查询客户信息 汽车信息 供应商信 息零件信息选择操作对象否是否是5.35.3 用户界面设计用户界面设计5.3.15.3.1 一般交互设计一般交互设计一般交互涉及信息显示、数据输入、和系统整体控制等方面。1.一致性为客户交互界面中的菜单选择、命令输入、数据显示以及众多的其他功能

36、，使用一致的格式。在设计的过程中，基本上保持了系统的格式一致。2.信息的反馈向用户及时提供视觉和听觉的信息反馈，以保证在用户和系统之间及时地建立双向通信。在本系统设计过程中，基本做到了信息的及时反馈，在信息显示的大部分窗体中包括了刷新按钮，会对数据库中的数据进行及时地显示。另外，在进行错误操作时，会弹出提示窗口并发出警告提示音。3.执行有较大影响的操作前提示用户确认在设计过程中，如果用户要执行删除操作，以及对数据库的读写操作时，都会有窗体弹出询问继续操作或者予以提示。4.减少两次操作间需要记忆的内容为了避免用户为下一步操作而记忆大量数据，所以在设计过程中在需要数据传递的窗体中设置全局变量，来传

37、递数据。例如在入账和入库的模块的操作中都用到了这样的方法。5.对话、移动和思考的效率尽量减少用户击键的次数，在设计时考虑到了用户屏幕的布局以减少用户鼠标移动的距离，尽量避免用户在操作中发生疑问的情况。6.允许错误允许用户的误操作尽量不对系统造成伤害。7.按功能对动作分类，并据此设计屏幕布局屏幕布局尽量将软件所具有的所有功能在主页面展示，界面一目了然。5.3.25.3.2 信息显示设计信息显示设计 应当尽量为用户提供的界面显示时完整的、明确的和容易理解的。这样才能满足用户的需求。1.只显示与当前工作有关的信息在用户操作有关系统的特定功能的信息时，不必看到与之无关的数据、菜单和图形。2.使用一致的

38、标记、标准的缩写和可预知的颜色为了使系统所表达的含义准确、无误，就必须适用一致的标记、标准的缩写和可以预知的缩写，这样用户就无需参照其他信息源就能理解，而正确地适用软件。3.产生有意义的错误信息对于系统在运行过程中产生的错误尽量给用户返回一个容易理解的错误信息，以使用户保持对系统的信任，和系统的可用性。4.使用窗口分隔不同类型的信息使用不同的窗口显示、保存不同类型的信息。5.3.35.3.3 数据输入设计数据输入设计用户的大部分时间用在选择菜单命令、键入数据和向系统提供输入。在系统中，键盘是主要的输入介质，但是鼠标等设备也是重要的输入手段，所以，对于他们的数据输入操作有如下约定：1.保持信息显

39、示和数据输入间的一致性为了方便用户的使用，鼠标应当尽量减少操作的幅度。2.保持显示信息和输入信息之间的一致性5.45.4 程序设计过程程序设计过程程序设计主要是在借助过程设计工具的情况下，对程序的具体实现过程进行设计。程序的主要部分设计在这个环节完成。其主要包括以下几个部分：5.4.15.4.1 各模块功能及截图各模块功能及截图本系统一共五个模块，分别是车辆档案管理；车辆运营信息管理；车辆统计管理；驾驶员信息管理；车辆管理和系统维护。 系统登录窗口是操作用户进入系统的惟一入口，分为两种权限：管理员权限和普通用户权限. 操作用户的权限不同的功能模块也不同,管理员可以维护整个系统和系统操纵身分,而

40、普通用户只能对系统各别功能进行操作.1.登录界面截图如图 5.3 所示 图 5.3 登录界面截图2.在用户登录时，在输入用户名和密码及用户类型的前提下将其与数据库中的数据进行对比，若一致，则打开主窗体，若不一致提示错误，并要求再次输入，若输入次数超过三次，则关闭系统。系统功能界面截图如图 5.4 所示：图 5.4 系统功能界面截图3.车辆档案录入操作窗口用于添加，修改，删除车辆信息。车辆档案模块截图如图 5.5 所示图 5.5 车辆档案模块截图4.驾驶员管理分三个部分，分别是驾驶员档案查询、驾驶员奖罚、驾驶员事故记录查询。驾驶员档案查询可以按照姓名、驾龄、性别、证件有效期以及出生日期等信息。从

41、数据库中查询需要的驾驶员档案信息。驾驶员管理模块截图如图 5.6 所示图 5.6 驾驶员管理模块截图5.车辆维修管理模块截图如图 5.7 所示图 5.7 车辆维修管理查询模块截图6 6 软件测试软件测试一个软件开发完成后，并不能投入使用，而需要有好长时间的测试。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件的测试方法有两种，一种是黑盒测试（功能测试） ，另外一种是白盒测试（结构测试） 。黑盒测试把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说，黑盒测试是在程序接口进行

42、的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当的接受输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。黑盒测试又称为功能测试。现在对系统着重进行功能和性能测试。白盒测试的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否能按预定的要求正确工作。在本次软件的测试工作中，由于水平的限制，仅仅对软件的各个功能模块进行了测试，并对各个模块之间的接口进行了详细的测试（用黑盒测试法） 。由于该系统是一个小系统，可以把整个系统作为一个单独的实体来测试。当然，在测试的过程中可以分模块、分阶段来进行。大型软件系统通常是有若干个子系统组成，且每个子系统由许多模块组成。在设计模块时，应尽力向高内聚、低耦合的思想方面靠拢。6.16.1 测试目标和方法测试目标和方法测试是为了发现程序中的错误而执行的程序。好的测试方案是极可能发现迄今为止尚未发现的错误的方案，成功的测试是发现了至今为止尚未发现的错误的测试。6.26.2 测试用例测试用例系统登录模块测试系统登录成功界面截图如 6.1 所示图 6.1 系统登录系统登录失败界面截图如 6.2 所示图 6.2 系统登录失败系统登陆成功与失败测试，登陆成功则进入系统。登陆失败则显示错误信息，需要重新输入信息重新登陆。车辆信