软件项目开发课程设计机关车辆管理系统说明书.doc

《软件项目开发课程设计机关车辆管理系统说明书.doc》由会员分享，可在线阅读，更多相关《软件项目开发课程设计机关车辆管理系统说明书.doc（38页珍藏版）》请在三一办公上搜索。

1、*实践教学*兰州理工大学计算机与通信学院2011年秋季学期软件开发综合训练课程设计题 目： 机关车辆管理系统 专业班级： 08级计算机科学与技术（3）班 姓 名： 刘 有 银 学 号： 08240311 指导教师： 张 红 成 绩： 目 录摘 要I序 言II1、可行性分析31.1问题描述31.2可行性分析研究31.2.1技术可行性31.2.2经济可行性41.2.3操作可行性41.3结论意见42、项目开发计划62.1编写目的62.2项目背景62.3项目概述62.4项目开发计划73、需求分析83.1任务需求分析83.2数据流图、数据字典及实体联系图93.2.1数据流图93.2.2数据字典123.2

2、.3实体联系E-R图144、系统概要设计184.1总体设计184.2系统功能模块图184.3数据库概念设计184.4数据库逻辑结构设计194.5连接数据库的特点235、详细设计235.1系统的主要功能235.2程序流程图255.3用户界面设计285.3.1一般交互设计285.3.2信息显示设计295.3.3数据输入设计295.4程序设计过程295.4.1登录界面及密码修改305.4.2信息添加操作315.4.3信息查询操作315.5 软件测试32设计总结33参考文献34致 谢35摘 要面对国内汽车数量的不断增加，在人们的生活中，机动车辆是我们每天都离不开的交通工具，因此，我们要想能更好的使用它

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

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

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

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

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

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

9、户群。所做软件的开发成本与客户提出的要求是否可达到双方都满意。并且，分析系统开发是否会对其它产品或利润带来一定影响。经过对上述几个方面的调查研究和分析，应用此系统将会在很多时候，很大程度节省人力，财力，提高效率，清晰明了的报表资料，高效的数据处理等，而开发时期并不耗费很多人力，财力，故在经济方面既不会有困难同时又有很大的价值。1.2.3操作可行性本系统的界面比较美观、友好、操作简单、方便，同时，系统运行速度较快，对计算机的硬件环境要求不是很高，能够完成汽车维修管理的大部分工作。系统提供了从维修业务到售后服务完整一体的功能，涵盖了订单管理，车辆管理，驾驶员管理，业务管理等管理功能，为企业的日常工

10、作管理提供一个功能齐全的平台。软件提供的各种业务运行数据，统计报表，辅助决策支持，综合查询等功能，为企业的经营决策提供了大量的实用信息。一体化的设计方案，突破了单一应用的局限实现了业务，资金，决策一体化，做到物流，资金流，信息流的统一。支持Internet远程数据传送，使软件在局域网应用的基础上，实现跨空间的信息管理，解决了企业规模扩大和经营模式改变对系统拓展性的要求，同时软件提供各种接口，能够将软件拓展为一个完整的企业管理平台。1.3结论意见 经过认真地可行性研究，系统基本上做到了在技术、经济、运行、法律上的可行。因此，相信在按照计划上实施的前提下，全系统的设计将会按时、高质量的完成。所以，

11、系统研制和开发是可以马上进行的。2、项目开发计划2.1编写目的 编写的目的是使独立运营的车队由单一的人工管理到计算机管理的飞跃，使车队的管理的效率得到很大的提高，使人工管理的出错的机会大大减少，实现数据的共享，便于查询自己的数据信息，使车队的业务的流程时间大大减少，从而可以提高该车队在同行业中的竞争性，在社会有立足之地。2.2项目背景在计算机不断发展的今天，计算机已经运用到各个领域，由手工的操作到计算机的操作是一个大的飞跃，代替了复杂的容易出错的人工操作，节省了大量的时间，提高了正确性，提高了数据的可靠性。因此每个公司使用计算机建立自己的业务是迫在眉睫，各种企业的汽车管理部门以及独立经营的车队

12、根据业务发展的需要，决定建立一个数据库管理系统，以代替单一的人工管理。这样使人工操作的管理方便，简单。2.3项目概述1、工作内容让计算机对车辆综合业务进行自动管理，用户可以直接在计算机上实现车辆综合业务的信息管理，并能在一定程度上实现自动化。 2、条件与限制开发该软件的条件比较简单，以开发单位目前的经济与技术条件已完全具备开发的条件。该系统可在用户要求的期限内完成。 3、产品1）、程序该项目因开发时间较短，这里只给出设计思想，具体程序没写。2）、文档文档内容包括：(1) 封面(2)目录(3)中文摘要100字左右；关键词3-5个(4) 序言(5)可行性分析(6)项目开发计划)7)需求规格说明（包

13、含需要的系统流程图、数据流程图、数据字典、E-R图）(8) 概要设计（包含总体软件结构图、总体数据结构）(9) 详细设计（对概要设计内容进行详细设计）(10) 设计总结、参考文献、致谢等4、验收标准软件的验收标准完全由用户提出的软件需求制定，能保证软件的基本符合用户的要求。 2.4项目开发计划1、任务分解分三个大的阶段进行开发第一阶段完成本系统的数据流图跟E-R图。第二阶段完成概要设计跟详细设计。第三阶段书写文档。 2、预算软件资金投入较少，具体预算分配简略。 3、关键问题各模块之间的联系和后台数据库的完成。使用目前的设备与现有开发技术完全可以开发出该系统，总的来说该项目没有较大的技术难点与其

14、他的一些风险因素。对于出现的一些小难点总都能得到解决。3、需求分析3.1任务需求分析退出系统系统初始化登陆主界面订单管理车辆管理业务管理驾驶员管理添加或删除客户信息修改订单信息查询订单信息按订单名称查询按订单编号查询添加或删除车辆信息修改车辆信息查询车辆信息按车辆编号查询按车牌号查询添加或删除业务记录修改业务记录查询业务记录打印维修记录单查询业务信息查询业务结算信息添加或删除驾驶员信息查询驾驶员信息修改驾驶员信息按驾驶员编号查询按驾驶员姓名查询在进行一个项目的设计之前，先要进行必要的需求分析，需求分析在软件的开发过程中至关重要。现独立运营的车队需要管理车队内的各种车辆的基本信息、不同客户的基本

15、信息、各种订单的基本信息以及驾驶员的情况，希望实现办公的信息化，通过建立一个车辆综合管理系统来有序的管理。经分析先给出该系统的系统流程图，如图3.1所示： 图3.1 系统流程图通过查询的到车辆管理的基本需求有:(1)建立车辆信息库，实现车辆基本情况和驾驶员基本信息的统一管理。(2)针对每辆车的派车、用车情况进行记录，实现车辆自动调度。(3)对每辆车的事故、违规情况进行记录。(4)对每辆车的保险、保养、加油等日常费用情况进行记录。(5)建立维修情况信息库，针对每辆车的维修情况进行记录。围绕上述要求，以下介绍如何利用计算机管理信息系统，建立车辆、驾驶员档案，对车辆营运、维修以及燃料消耗进行记录，为

16、专职管理人员对车辆的管理、跟踪车辆的相关信息资料提供极大的方便。系统不仅合理记录了所有车辆的进出、加油、维修等，还可随时了解每部车的经费支出情况，以及为车辆是否需要大修理和报废提供依据，对有关数据（成本、效益、单车、车型、油耗等）可以进行综合统计分析，生成相关的报表。3.2数据流图、数据字典及实体联系图3.2.1数据流图数据流图由四种基本的元素构成：数据流(Data Flow)，处理(Process)，数据存储和数据源（数据终点）。数据流(Data Flow)：为具有名称且有流向的数据，用标有名称的箭头表示，一个数据可以是记录、组合项或基本项。处理(Process)：表示对数据所进行的加工和变

17、换，在图中用矩形框表示。指向处理数据流为该处理的输入数据，离开处理的数据为处理的输出数据。数据存储：表示用文件方式或数据库形式所存储的数据，堆砌进行的存取分别以指向或离开数据存储的箭头表示。数据源及数据终点：表示数据的来源或数据的去向，可以是一个组织或人员，它处于系统范围之外，所以又称它为外部实体，它是为了帮助理解系统界面而引入的，一般只出现在数据流图的起点和终点。 ：圆或椭圆表示加工 ：双杠表示数据存储 ：方框表示数据的源点或终点 ：箭头表示数据流通过对系统的调查和可行性分析，画出系统的数据流程图如下：车辆信息录入流程图如图3.2所示：车辆存储车辆信息录入要求成功信息验证信息录入信息身份验证

18、确定能否登录是否进行车辆信息录入车辆信息录入图3.2 车辆信息录入流图客户信息操作流程图如图3.3所示：选择操作客户登陆添加要求删除要求修改要求添加订单信息删除订单户信息修订单信息进行操作插入结果删除结果修改结果订单信息图3.3客户订单操作流图管理员数据更改数据流图如图3.4所示：根据要求修改资料更新资料信息修改信息资料库存文件管理员图3.4 管理员更改数据流图各种信息综合查询流图如图3.5所示：检验身份确定能否登录确定查询要求进行查询是否能够统计打印进行统计打印身份验证验证信息成功信息查询要求资料文件统计打印要求统计打印图3.5 各种信息综合查询流图该系统总体数据流图如图3.6所示：图3.6

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

20、中驾驶员属性描述定义：驾驶员资料=驾驶员编号+姓名+性别工作类别+薪酬+身份证号码+工作单位+所属部门+家庭住址+联系电话+是否空闲位置：输出到打印机保存到磁盘名称：出车记录单别名：描述：每次出车时的记录定义：出车记录单=出车记录编号+车辆卡编号+驾驶员编号+记录状态+用车部门+用车人+同行人数+用车起始时间+预计用时+用车结束时间+备注位置：输出到打印机保存到磁盘名字：车辆保险单别名：描述：车辆交售是否保险记录单定义：车辆卡编号+保单号码+保险公司+保险起始日期+保险总额+办理日期+经办人+车辆损失险+第三者责任险+车辆停驶松损失险+自然损失险+不计免赔特约险+其他险种位置：输出到打印机保存

21、到磁盘名字：车辆费用记录别名：描述：车辆的费用和缴纳费用定义：车辆卡编号+费用名称+费用额+缴费日期+经手人+备注位置：输出到打印机保存到磁盘名字：车辆油耗记录表别名： 描述：记录车辆耗油定义：车辆卡编号+所加油种+加油单价+本次加油量+加油日期位置：输出到打印机保存到磁盘名称：车辆维修单记录单别名：描述：车辆维修时记录的单据定义：车辆卡编号+结算清单编号+进厂日期+出厂日期+修理厂名称+报修人+验收人+验收日期+报修费用+实付费用+发票日期位置：输出到打印机保存到磁盘名字：车辆事故登记单别名：描述：车辆发生事故登记表单定义：车辆卡编号+驾驶证号码+事故当事人+事故发生时间+事故地点+赔偿金额

22、+保险赔付金额+本单位负担金额+事故处理单位+事故概括+报案日期+结案日期+本单位处理意见+上级部门处理意见+备注位置：输出到打印机保存到磁盘3.2.3实体联系E-R图根据对数据流图和数据字典的分析，我们可以确定该应用中的实体，属性和实体之间的关系，并画出如下所示的E-R图。汽车实体图如图3.7所示：图3.7汽车实体图下图是是驾驶员实体E-R如图3.8所示：图3.8驾驶员实体E-R图下图是车辆保险实体E-R 图如图3.9所示图3.9车辆保险实体E-R 图下图是车辆费用实体E-R 图如图3.10所示图3.10车辆费用实体E-R 图下图是车辆油耗实体E-R 图如图3.11所示图3.11是车辆油耗实

23、体E-R 图下图车辆维修实体E-R 图如图3.12所示图3.12车辆维修实体E-R 图下图是车辆事故实体E-R 图如图3.13所示图3.13车辆事故实体E-R 图各实体之间的E-R图如图3.14所示：图3.14各实体之间的E-R图4、系统概要设计4.1总体设计通过这个阶段的工作将划分出组成系统的物理元素。系统概要设计的基本目的是用比较抽象的概括方式确定系统如何完成预定的任务，也就是要确定系统的配置物理方案。软件结构设计时应该遵循的最主要的原理是模块独立，让模块彼此间的接口关系应该尽量简单。4.2系统功能模块图可以根据模块独立原理对软件结构进行精化。为了合理的分解，得到尽可能高的内聚、尽可能松散

24、的耦合，最终要的是，为了得到一个易于实现、易于测试和易于维护的软件结构，应该对模块进行再分解或合并。系统功能模块图如图4.1所示：图4.1系统功能模块图4.3数据库概念设计数据库一般分为三级模式：外模式、概念模式和内模式。外模式也就是不同用户所对的数据视图，它将数据库内部抽象的数据及其互相之间的关系表示为简单、直观的应用界面。概念模式是数据库中全部数据的逻辑结构和特征描述，通常以某种数据模型为基础。内模式是对数据的物理结构和存储方式的描述。在这里我们将要设计的是数据库的概念模式，通过对车辆综合业务管理系统的数据字典和数据流程分析及E-R图，设计如下数据项和数据结构。车辆信息：包括牌照号码、车辆

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

26、称、费用额、缴费日期、经手人、备注。车辆油耗信息：包括车辆卡编号、所加油种、加油单价、本次加油量、加油日期。车辆修理信息：包括车辆卡编号、结算清单编号、进厂日期、出厂日期、修理厂名称、报修、+验收人、验收日、报修费用、实付费用、发票日期。车辆事故信息：包括车辆卡编号、驾驶证号码、事故当事人、事故发生时间、事故地点、赔偿金额、保险赔付金额、本单位负担金额、事故处理单位、事故概括、报案日期、结案日期、本单位处理意见、上级部门处理意见、备注。数据库概念结构设计，是在需求分析的基础上，设计出能够满足用户需求的各种实体，以及他们之间的关系，为后面的逻辑结构设计打下基础。4.4数据库逻辑结构设计在数据库设

27、计中相当重要的一步就是将概念模型转化为计算机上DBMS所支持的数据模型，例如，将E-R图模型转化为关系模型，道理很简单，我们设计概念模型基本上都是一些抽象的关系，在再数据库设计的实现过程中，在计算机上有效地表示出这些关系就成了数据库设计的关键。根据车辆综合业务管理系统的功能要求，选取SQL Server 2000作为后台数据库。在上面的实体和实体之间的E-R图设计基础上，形成数据库中的表格及表格之间的关系。可以得到：1. 车辆登记卡记录表如表4.1所示表4.1车辆登记卡记录表2. 驾驶员基本情况表如表4.2所示表4.2驾驶员基本情况表3.出车记录情况表如表4.3所示表4.3出车记录情况表4.

28、车辆保险记录表如表4.4所示表4.4车辆保险记录表5. 车辆费用记录表如表4.5所示表4.5车辆费用记录表6. 车辆油耗记录表如表4.6所示表4.6车辆油耗记录表7. 车辆维修单记录表如表4.7所示表4.7车辆维修单记录表8. 车辆事故记录表如表4.8所示表4.8车辆事故记录表4.5连接数据库的特点当开发环境通过连接到数据库上之后，在设计中使用数据库画笔可实现对该数据库中表格，视图等的操作，如创建表,修改表，删除表，增加/删除记录。在应用程序中一般是在应用程序对象中书写连接数据库的程序代码，使得应用程序开始运行并实现与数据库的连接。5、详细设计详细设计阶段的根本目标是确定应该如何具体地实现所要

29、求的系统，包括了用户界面设计、程序过程设计等步骤。5.1系统的主要功能系统主要功能：1. 基础数据: 1）车辆基本资料数据维护子功能主要完成对车辆档案数据库的录入，用户可以增加、删除及修改数据库中的信息它包括 输入：用户输入的车辆基本资料信息。 处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。 输出：车辆登记卡记录表2）驾驶员基本情况数据维护子功能完成对本单位专职驾驶员基本情况数据的录入它包括 输入：用户输入的驾驶员基本情况数据。 处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。 输出：驾驶员基本情况表。2. 日常出车管理: 本功能模块主

30、要实现出车任务从提出申请、调度员的调度、任务的完成等全过程的跟踪管理，它可以为车辆的管理工作提供有力依据，能真正达到统一监控管理的目的它包括：1）录入派车单 输入：用户输入的用车申请有关数据。 处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。 输出：出车情况记录表。2）车辆调度列出当前已输入但尚未落实的派车单，用户可以根据自己的需要，任意选择字段名或操作符，系统将会把满足条件的车辆以表格的形式显示出“派车清单”， 该功能为车辆的调度工作带来了很大的方便，本功能同时支持多条件查询。用户查询空闲的车辆和人员资源，便可进行车辆和驾驶员的指派。 输入：用户对派车单的指派指令

31、。 处理：根据用户的输入对数据库进行查询和更新。 输出：出车情况记录表。3）撤销任务列出已指派但未执行的派车单，用户可撤销该项指派或更改指派内容。 输入：用户对派车单的更改指令。 处理：根据用户的输入对数据库进行查询和更新。 输出：出车情况记录表。）4）完成任务对已完成的出车任务，用户记录该次任务的完成情况。 输入：用户输入的本次出车任务的详细情况。 处理：根据用户的输入对数据库进行查询和更新。 输出：出车情况记录表。3. 车辆保险 ：记录车辆投保和保费的情况，此模块完成了车辆保险投保登记的功能。4. 事故管理 ：记录车辆在出车过程中发生的事故及处理情况，此模块完成了车辆的出险情况，包括出现地

32、点、状况、事故处理情况、索赔状况进行详细记录。可以根据特定条件进行查询。5. 维修和费用管理 ：记录每辆车从购置到报废每次维修的详细情况，以及车辆发生的各种费用，包括油耗、年审等。此模块完成了车辆年检、养路费、加油费用的缴纳和开支情况，以及车辆维修内容、工时、费用等信息，实现了车辆维修的信息化管理。6. 统计分析 :对每辆车进行详细的统计分析，实现单车核算成本核算。此模块完成了统计每辆车的使用和保养情况，包括用车记录、保险、费用缴纳情况、油耗记录等，还可以统计每位驾驶员的出车任务完成情况记录。1. 车辆基本资料数据维护子功能主要完成对车辆档案数据库的录入，用户可以增加、删除及修改数据库中的信息

33、。 输入：用户输入的车辆基本资料信息。 处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。 输出：车辆登记卡记录表2. 驾驶员基本情况数据维护子功能完成对本单位专职驾驶员基本情况数据的录入。 输入：用户输入的驾驶员基本情况数据。 处理：根据用户的输入对数据库进行维护，提交所做的操作。包括增加、删除、更新。 输出：驾驶员基本情况表。5.2程序流程图 程序流程图的优点是对控制流程的描绘很直观，易于掌握。系统总体程序流程图如图5.1所示：登录允许登录启动界面查看信息管理信息修理车辆购买零件订单信息汽车信息驾驶员信息费用信息添加信息修改信息删除信息打印退出图5.1 系统总体程

34、序流程图购买零件及零件进库程序流程图如图5.2所示：是否否是是管理员输入查询条件查询相应的零件是否存在该零件结 束是否购买零件否购买零件是否重新输入图5.2 购买零件程序流程图管理信息程序流程图如图5.3所示：主界面管理信息选择操作对象客户信息汽车信息零件信息供应商信息选择操作添加修改删除操作完成退出选择修改密码创建用户密码完成选择图4.2.4借还图书资料程序流程图图5.3管理信息程序流程图5.3用户界面设计5.3.1一般交互设计一般交互涉及信息显示、数据输入、和系统整体控制等方面。1、一致性为客户交互界面中的菜单选择、命令输入、数据显示以及众多的其他功能，使用一致的格式。在设计的过程中，基本

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

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

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

38、和输入信息之间的一致性5.4程序设计过程程序设计主要是在借助过程设计工具的情况下，对程序的具体实现过程进行设计。程序的主要部分设计在这个环节完成。其主要包括以下几个部分：5.4.1登录界面及密码修改1、登录界面盒图如图5.4所示用户名是否输入否 是 密码是否输入否 是 查找管理员表中对应密码的用户 否 存在？ 是 打开主窗体 检查输入次数3 关闭窗体 图5.4 登录界面盒图在用户登录时，在输入用户名和密码及用户类型的前提下将其与数据库中的数据进行对比，若一致，则打开主窗体，若不一致提示错误，并要求再次输入，若输入次数超过三次，则关闭系统。2、密码修改盒图如图5.5所示 两次输入的密码是否一致

39、否 是 原密码是否正确 否 是 对数据库中的相应字段进行更新 提示已更新并提交更新 关闭窗体 检查输入次数3 图5.5 密码修改盒图在用户更改密码时，系统首先判断输入的两次旧密码是否一致，若一致，则判断原密码是否正确，如果原密码正确，则对数据库中的相应字段进行更新。5.4.2信息添加操作信息添加操作盒图如图5.6所示：退出此窗口是否存在该信息是否输入要添加的信息进行添 加提示信息已经存在是否重新输入退出此窗口 图5.6 信息添加操作盒图管理员查询某货物时货物名及货物号与数据库中的数据不相一致，系统提示所查货物在仓库里为空，即仓库从没存储该货物。然后管理员可根据仓库管理的需求是否保存该货物。5.

40、4.3信息查询操作信息查询操作盒图如图5.7所示 输入查询信息否 是 是否存在该信息数据 否 是 提示没有 输出该信息 所要查询 的信息 确认信息 关闭窗体 图5.7 查询操作盒图在执行查询操作之前通常要先在单行文本框中输入被查询的条件，在单行文本框失去聚焦时将查询条件传递给查询按钮的单击事件中，然后过滤语句依据此过滤条件过滤得出相应的数据，并显示在其他数据窗体控件中。在通常情况下，用户可以在得到要查询的信息后，对它们的各个字段进行修改，经过修改后，在退出时系统会提示进行存储。在完成了用户界面设计和程序过程设计后，基本上完成了详细设计的内容。 5.5 软件测试一个软件开发完成后，并不能投入使用

41、，而需要有好长时间的测试。测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件中的错误。目前软件测试仍然是保证软件质量的关键步骤，它是对软件规格说明、设计和编码的最后复审。软件的测试方法有两种，一种是黑盒测试（功能测试），另外一种是白盒测试（结构测试）。黑盒测试把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程。也就是说，黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当的接受输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性。白盒测试的前提是可以把程序看成装在一个透明的白盒子里，测试者完全知道程序的结构和处理算法。这种方法按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否能按预定的要求正确工作。在本次软件的测试工作中，由于水平的限制，仅仅对软件的各个功能模块进行了测试，并对各个模块之间的接口进行了详细的测试（用黑盒测试法）。由于该系统是一个小系统，可以把整个系统作为一个单独的实体来测试。当然，在测试的过程中可以分模块、分阶段来进行。大型软件系统通常是有若干个子系统组成，且每