公交车管理系统实现与设计.doc

软件工程导论课程设计报告 公交车管理系统的设计与实现 学生姓名： 张勇 学 号： 090403010063 年级专业： 09 信息管理与信息系统 指导教师： 龙海 2 目目 录录 第一章 绪论. 第二章 系统分析. 2.1.组织结构分析. 2.2.业务流程分析. 2.3.数据流程分析. 2.4.系统需求分析. 2.5.需求规格说明书. 2.6.处理逻辑说明. 第三章 可行性研究. 3.1 引言. 3.2 现行公交车管理概况. 3.3 拟建立的信息系统. 3.4 经济可行性分析. 3.5 技术可行性分析. 3.6 社会可行性分析. 3.7 可行性研究结论. 第四章 系统设计. 4.1.引言. 4.2.系统设计方案. 第五章 公交车管理系统的功能实现. 5.1 登陆界面编码设计. 5.2 人员整体信息管理界面编码设计. 5.3 财务信息管理界面编码设计. 5.4 客运信息查询. 第六章 系统测试计划. 6.1.引言. 6.2.计划. 6.3.测试设计说明. 6.4.评价准则. 第七章 总结. 3 第一章第一章 绪论绪论 针对公交车传统作业流程中的种种弊端，结合现代迅速发展的信息技术， 我运用所学的信息管理及系统分析与设计的知识开发出了公交车的管理信息系 统。 一个计算机管理系统必须有一个正确的设计指导思想，通过合理的选择数 据结构，操作系统以及开发环境，构成一个完善的网络系统，才能充分发挥计 算机信息管理优势。现代化的车站售票是集预定车票、售票 、退票、车次查询、 报表及其他各种服务，车站售票组织庞大，服务项目多，信息量大，要想提高 劳动生产，降低成本，提高服务质量和管理水平，进而促进经济效益，必须借 助计算机来进行现代化的信息管理。 此系统包括四大块： 1、可行性研究报告：从系统的总统出发，对经济、技术、社会、管理多方 面进行综合分析，即经济可行性分析、技术可行性分析、社会可行性分析和管 理可行性分析，是项目在开始阶段必须进行的一项工作。 2、系统分析报告：它反映的是系统分析阶段调查分析的全部情况，是系统 分析员与用户在一起，充分了解用户需求后所编写，作为后续开发工作的依据， 也是衡量一个信息系统优劣的依据。 3、系统设计报告：在已获准的系统分析报告的基础上，结合实际条件，可 想而、合理地设计出得系统解决方案，是系统设计阶段工作的成果的总结，也 是系统实施阶段的重要依据。 4、系统测试报告：将系统最主要的功能模块进行逐一的检测，对说明书中 列举的功能进行排查，对系统实现各功能的正常运行做充分的测试，输入合理 及不合理的测试数据检验功能的运行及出错处理情况。 此系统的开发，主要是给管理工作者带来工作上的便利。运用科学、系统 的方法有步骤、有目的、循序渐进的开发完成。 第第 2 章章 系统分析系统分析 根据对用户的需求，对公交车的业务活动的进行全面的调查分析，详细掌 4 握了相关工作流程，收集票据、账单、报表等资料，分析现行系统的局限性和 不足之处，并根据公交的条件，找出可行方案。 2.1.组织结构分析： 公交车队的高层领导由一名总队长、三名副队长组成。总队长负责总体事 务的决策，副队长负责主要事务的决策，三个副队长分别负责客运部、售票部、 纠纷协调部、财务部。其具体职能如下： 客运部主要职能是负责公交班次安排，负责司机行为规范，负责站点监督 和指导。 售票部主要职能是负责售票员的售票，负责车票价格的协调与制定。 纠纷协调部得主要职能是负责临时突发事件，例如，乘客闹事，交通堵塞， 客车故障，交通事故等等。 财务部主要职能是负责收银，负责会计，负责财务分析，负责报表。 2.2.业务流程分析 2.2.1 收费监控流程： 根据系统中设定的路段收费标准，当公交驶入某收费路段售票员判断车辆 所属地，同时，售票员根据不同路段的不同价位在收费划单中操作，根据收费 单中的价格告知乘车顾客，并进行收费，乘客将公交车费交给售票员后，售票 员将撕一张已打印好的交款凭证给顾客。 如果售票员工作失误，多撕了、少撕了或者撕错了凭证，可以继续给下一 位乘客交款凭证（少撕的凭证可以即时补给） ，先完成收费工作，然后要将废票 的票据出示给监控员，监控员依据废票的票据号进行废票的处理工作（监控员 只是登记废票的票据号，做一个删除登记，不能彻底删除） ，处理完后记录废票 信息。 每天每班车工作完成后，售票员将收费单和剩余收款凭证交至会计人员进 行审核，确定无误后登记，每日会计统计出日报表和客人流数据交给收银员； 月末收银员审核过数据后将月报表、年报表交至财务部由财务分析员对这些报 表数据进行分析，以便做好进一步的规划预算，同时还需将月报表、年报表和 客流量汇总表及时交给总队长。 其业务流程图如图： 5 2.2.2 会计记账流程： 会计人员根据售票员提供的剩余凭证和收费划单及监控员提供的作废凭证 在电脑上进行登记账单，形成日报表，再将日报表交由收银员审核，审核通过 则收银员根据会计做的日报表，月末形成月报表，年末形成年报表。不通过， 则返回日报表给会计令其纠正。 其业务流程图如图： 售票 员 员 收费标准 交款凭证 乘客 日收费单剩余收 款凭 证 废票 废票处理 单 会计 日报表客流量数据 收银员 月报表、年 报表 总队长 财务分析员 预算规划 售票员剩余凭证 收款单 监控员 作废凭证 会计 合格日报表 收银员 月报表、年报表 出错日报表 6 2.3.数据流程分析 2.3.1 财务管理流程： 每天每班车工作完成后，售票员将收费单和剩余 收款凭证交至会计人员进行审核，确定无误后登记，每日会计统计出日报表和 客人流数据交给收银员；月末收银员审核过数据后将月报表、年报表交至财务 部由财务分析员对这些报表数据进行分析，以便做好进一步的规划预算，同时 还需将月报表、年报表和客流量汇总表及时交给总队长。 2.3.2 数据字典 （一）数据流的描述 数据流编号：D-1 数据流名称：购票单 简述：由工作人员帮助乘客填好购票单 数据流来源：乘客 数据流去向：登记处审核处理 数据项组成：乘客名称+票价+车票类型+经手人+购买时间 数据流量：约 8 张/日 高峰流量：约 15 张/日 数据流编号：D-2 数据流名称：收款凭证 简述：经登记处填好的收款凭证 数据流来源：登记处审核处理 数据流去向：售票员 数据项组成：乘客名称+票价+车票类型+经手人+购买时间 数据流量：约 8 张/日 高峰流量：约 15 张/日 数据流编号：D-3 数据流名称：收费单 简述：由售票员填好的收费单 数据流来源：售票员 7 数据流去向：会计人员审核登记处理 数据项组成：乘客名称+票价+车票类型+经手人+购买时间 数据流量：约 2 张/周 高峰流量：约 4 张/周 （二）处理逻辑的描述 处理逻辑编号：P-1 处理逻辑名称：购票单审核 简述：审核购票单 输入的数据流：购票单 处理描述：审核购票单，填写收款凭证 输出的数据流：收款凭证 处理频率：8 次/日 处理逻辑编号：P2 处理逻辑名称：会计人员审核登记处理 简述：根据收费单将数据记入日报表 输入的数据流：收费单 处理描述：根据收费单将数据记入日报表，并更新相关数据 输出的数据流：客流数据 处理频率：8 次/日 （三）数据存储的描述 数据存储编号：F-2 数据存储名称：汇总台账 简述：记录车票销售的情况 数据存储组成：销售数量+乘客名称+票价+车票类型+经手人+购买时间 关键字：乘客名称+票价 相关联的处理：P1，P2，P3 （四）外部实体的描述 外部实体编号：S-1 8 外部实体名称：售票员 简述：填写收费单 输入的数据流：D2，D3，D4 输出的数据流：D2 2.4.系统需求分析 2.4.1 计算机和处理器 处理器 800MHz 以上（如果开启视频至少 1GHz） 2.4.2 内存 128MB 以上（如果开启视频至少 256MB） 2.4.3 硬盘 安装需要 100MB 的硬盘空间，运行需要 50MB 空余空间 2.4.4 显示器 最小 800 x 600 （建议使用 1024 x 768）屏幕分辨率 2.4.5 浏览器 计算机上应该安装了 Microsoft Internet Explorer 6 或更高版本，但是不一 定要设置为默认浏览器。 2.4.6Internet 连接 互联网接入（宽带接入效果最佳，无线接入质量降低，模拟线路不建议使 用） 。 2.4.7 管理人员的支持 管理人员对该系统充分理解与支持，并要求其员工进行系统操作培训 。 2.5.需求规格说明书 2.5.1 引言 2.5. 1.1 编写目的 目的是提高工作效率,节约人力资源,并作为软件设计人员设计依据和使用单 位的验收标准。 预期的读者是软件设计人员还有组织高层人员。 2.5.1.2 背景 此待开发系统的名叫公交车信息管理系统，是公交车高层管理人员提出需 9 要开发此项目，进行研究开发，供车队指定工作人员使用。 2.5.1.3 定义 Xml：XML（Extensible Markup Language）即可扩展标记语言，它与 HTML 一样，都是 SGML(Standard Generalized Markup Language,标准通用标记语言)。 Xml 是 Internet 环境中跨平台的，依赖于内容的技术，是当前处理结构化文档 信息的有力工具。扩展标记语言 XML 是一种简单的数据存储语言，使用一系列 简单的标记描述数据，而这些标记可以用方便的方式建立，虽然 XML 占用的空 间比二进制数据要占用更多的空间，但 XML 极其简单易于掌握和使用。 XML 与 Access,Oracle 和 SQL Server 等数据库不同，数据库提供了更强有 力的数据存储和分析能力，例如：数据索引、排序、查找、相关一致性等，XML 仅仅是展示数据。事实上 XML 与其他数据表现形式最大的不同是：他极其简单 。这是一个看上去有点琐细的优点，但正是这点使 XML 与众不同。 XML 与 HTML 的设计区别是：XML 是用来存储数据的，重在数据本身。而 HT ML 是用来定义数据的，重在数据的显示模式。 XML 的简单使其易于在任何应用程序中读写数据，这使 XML 很快成为数据 交换的唯一公共语言，虽然不同的应用软件也支持其它的数据交换格式，但不 久之后他们都将支持 XML，那就意味着程序可以更容易的与 Windows、Mac OS, Linux 以及其他平台下产生的信息结合，然后可以很容易加载 XML 数据到程序 中并分析他，并以 XML 格式输出结果。 2.5.2 任务概述 2.5.2.1 目标 本系统通过强大的网络技术给组织的工作人员带来方便，本系统能实现客 运管理、售票管理、协调纠纷管理、财务管理，提高工作人员的工作效律，为 工作人员提供了极大方便，即使不出门也可以进行工作上的处理。 2.5.2.2 用户特点 最终用户可分为操作人员、维护人员。 其中，操作人员要求对计算机有一 定了解的人员。维护人员要求对本系统有较深的了解，同时对系统相关信息及 工作流程有所了解的技术人员。本系统需要在资源的动态更新，这时候也是本 系统最需要维护的时候，所以在这时候要对本系统进行必要的检修，防止数据 10 出错 2.5. 2.3 假定与约束 设计的约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。 其并不是要取代设计（实现）过程，只是说明用户或环境强加给项目的限制条 件项目投入的最晚时间。 2.5.3 需求规定 2.5.3.1 对功能的规定 输入输出输入限 制 输出 限制 并行用 户数 支持终 端数 后台处 理 登录 账号 密码 文本首页汉字、 数字、 英文字 母 小于 255 小于 255 进入首 页界面 进入 工作 中心 管理 模块 进入指 定工作 界面 用户登 录执勤 数据 更新 文本列表存储 登录 注册 文本文本存储 修改文本文本修改， 存储 查询文本列表文本列表查询， 输出 后台管 理 资源 添加、 文本文本存储， 修改 11 删除 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 其他专门要求 12 2.6.处理逻辑说明 由于最底层数据流程图中的加工不能再通过子图做进一步的描述，因此必 须有处理逻辑说明来定义底层数据流图中的加工。如：售票员收费对在不同路 段，乘客到达目的的不同路程收取不同票价。在此处我们用判断树法来表示售 票员售票过程。 第三章第三章 可行性研究可行性研究 此可行性研究报告是在制定项目前对公交管理项目实施的可能性、有效性、 技术方案及技术政策进行具体、深入、细致的技术论证和经济评价，报告的主 要内容如下： 3.1 引言 3.1.1 目的：为了更加便于公交车系统的管理，提高工作效率，尤其是完善 财务管理与提高公交财务会计等的管理。 3.1.2 背景：现行的公交体系仍旧是一个不完整的、分散的、相互竞争的没 有统一的系统。 3.2 现行公交车管理概况 3.2.1 组织目标与战略:提高公交员工的工作效率，尽可能减少成本提高效益， 以最小的成本获取最大的收益。通过建立一个完善的公交管理信息系统，利用 先进的设备提高记账效率，完善工资核算体系，明确分工，明确各个司机的路 线，对不遵守路线规则恶意竞争者予以惩处，以建立一个完善，和谐，系统， 高效的公交车管理信息系统。 3.2.2 存在的主要问题：记账只是传统的手工记账，设备也是简单的计算器。 司机之间有相互的竞争，司机经常不遵守发车秩序和时间，经常误点、踩点。 公交监控几乎没有，只是落后的人工监控。 3.3 拟建立的信息系统 3.3.1 简要说明：建立一个高效率的集账务管理系统，员工管理系统，工资 管理系统和监控奖惩系统于一体的信息系统。 13 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 技术可行性分析 已经学习了 SQL SERVER，对网络技术和操作系统也有系统的了解，有些 成员熟悉计算机原理，能解决常见的硬件故障和硬件选择。而且，网上有许多 关于 VISUL BASIC 编程的资料和 SQL SERVER 方面的资料。 所以从技术上来说，此次开发是可行。 14 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 系统总体结构设计 公交管理系统集合了原本车队的四个子系统：客运管理，售票管理，纠纷 协调管理，财务管理。车队的管理人员可以同时查询和了解四个子系统的工作 情况，使得车队的管理层能够更好的了解和监督工作情况，保证工作高效进行。 在子系统中有自己的管理模块。 模块功能图如图： 15 4.2.1.1 客运管理 公交人员管理 该模块针对公交管理系统的基层工作人员和管理层工作人员的基本信息进 行管理，基层工作人员基本信息包括姓名、性别、所属部门、联系方式，管理 层工作人员的基本信息除了包括姓名、性别、所属部门、联系方式等以外，还 记录该工作人员的登录密码、编号和级别，方便权限管理。在模块中可实现对 信息的增加，修改，删除，查询，打印等功能。 公交车信息管理 该模块针对车队里的 13 辆公交车的基本信息进行管理，包括车型，发动机 类型，重量，载客数，功率，车牌号，车辆制造厂。在模块中可实现对信息的 增加，修改，删除，查询，打印等功能。 耗油管理 该模块针对车队的 13 辆车每辆每日的耗油量信息管理，需每日更新。 公交管理系统 客运管理售票管理纠纷协调管理财务管理 人员管理 车辆管理 日耗油管理 维修管理 票价管理 收费管理 事故处理管理 乘客反馈管理 收银管理 报表统计管理 16 维修管理 该模块针对车队的 13 辆公交车的维修状况进行管理。记录每次维修的基本 信息，包括维修车辆车牌号，维修部位，维修日期，维修地点，维修费。 4.2.1.2 售票管理 票价管理 该模块针对不同路段的售票价格进行管理。 收费管理 该模块记录着售票员的日常工作，每个售票员一日有十班次，记录包括每 个班次的人流数、每班次售出的每种票价的票数、每班次收入总数，最后统计 出整日的人流、票数、总收入。 废票管理 该模块记录了再收费过程中由于操作失误而产生的作废车票信息，底层员 工无权处理，高权限监督管理人员方可进行处理。 4.2.1.3 纠纷协调管理 意外事故处理管理 该模块记录每次事故处理的基本信息，包括事故发生时间、地点、肇事人、 事故发生原因、事故处理支出。 乘客反馈管理 该模块记录任何乘客们的反馈以及提出的有益建议。 4.2.1.4 财务管理 收银管理 该模块由收银员进行操作，记录着每个售票员的每班次的收入，同时也记 录了每个班次的人流数、每班次售出的每种票价的票数。每日最后一班车后， 收银员要作出最后统计每个售票员一日的工作情况，包括整日的人流、票数、 总收入。 报表统计管理 该模块由财务管理人员进行操作，对基本数据进行统计，最后输出报表， 包括日报表、月报表、年报表。 17 4.2.2.处理流程设计 4.2.2.1 系统流程设计 依据上面系统分析报告的财务管理分析数据流程图，对公交管理信息系统 的财务管理子系统进行系统流程设计，同系统流程图来描述各数据在计算机存 储介质间的流动、转换、和存储情况。其系统流程图如图 2.1： 4.2.2.2 模块处理过程描述 我们对收费监控流程的程序用程序流程图来描述系统设计的程序。 4.2.3.代码设计 购票单 登记处理 收、交款凭证 收费标准 收费单 剩余收款凭证 会计审核 登记 客流量表日报表 收银员审核 月报表、年报表 财务数据分析 预算规划表汇总台账 18 在 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.输入界面设计 19 4.2.5.1 该管理系统的用户是车队的全体工作人员，工作人员先登录该车 队的网站，然后在那网站首页选择自己所在的部门，然后就会弹出登录界面。 登录账号就是工作人员自己的代码，密码可以自己设置，如若忘记密码， 可以点击界面的“找回密码”文字来找回密码。 4.2.5.2 进入部门的管理系统后，根据权限的高低可对系统内部的信息进 行查询或更新、修改、删除。 4.2.6.数据库设计 4.2.6.1 概念结构设计 通过对系统业务及原始数据的分析，本系统的数据库文件设计结果见表如 下： 数据名称乘客 名称类型宽度小数位 数 说明 姓名字符10-乘客的姓名 性别逻辑1-F/T=男/女 电话号码数值9 整数联系电话 车票票号字符6-车票的类型 组成 电子邮件字符12-联系的内部 Email 数据名称售票员 名称类型宽度小数位 数 说明 姓名字符10-售票员姓名 性别逻辑1-F/T = 男/女 编号字符6售票员的编号 车票票号字符6-车票的类型 组成 车票收据字符12-收据编号 20 表 1.5 财务人员基本信息表 数据名称财务人员 名称类型宽度小数位 数 说明 姓名字符10-财务人员名称 性别逻辑1-F/T = 男/女 编号字符6-财务人员的编号 组成 车票收据字符12-收据编号 其 E-R 关系图为： 乘客与售票员为多对一关系，售票员与财务人员为多对一关系。 4.3.6.2 逻辑结构设计 将图的 E-R 图转换为关系模型： 乘客（姓名，性别，车票号，） 此为乘客实体对应的关系模式，该关系模式已经包含联系“购票”所对应 的关系模式。车票号是关系的主码。 售票员（姓名，编号，车票号，收据，） 此为售票员实体对应的关系模式，该关系模式已经包含联系“上交”所对 应的关系模式。编号是主码，车票号是候选码。 财务人员（姓名，性别，收据，编号） 此为财务人员实体对应的关系模式，主码是编号。 3.2.6.3 物理结构设计 常用的物理存取方法主要有三类：第一类是索引方法，目前主要是 B+树索 引方法；第二类是聚簇方法；第三类是 HASH 方法。我们这里主要采用的是索 引存取方法中的唯一索引。 4.2.7.安全保密设计 为使本系统可以安全、准确地运行，防止机密数据被泄露，防止无权者使 用、改变或有意破坏他们无权使用的数据以及保护数据结构不受损害，保证数 据的正确性、有效性和一致性，我们需要对系统进行安全性保护和完整性保护 21 的安全保密设计。在技术方面，我们从以下方面入手来提高系统的安全性与完 整性。 4.2.7.1 硬件方面 选用可靠性较高的硬件设备，选用性能优良的服务器 和工作站，服务器有完善的容错能力，允许带电热拔插，有智能 I/O 性能，并 且配有不间断电源、稳压器、防病毒卡等。 4.2.7.2 软件方面 访问控制。进入系统时，在终端上采用凭“用户名”和“密码”进入系 统，以防非法侵入，密码必须要长于 6 位，且是于数字，字母，字符等混合。 选择性访问控制。对用户分级，不同级别的用户访问权限不同，可使用 功能也不同。 加密。将原有可读信息（程序、数据）进行翻译，译成密码或译文的代 码形式，以保护信息安全。 4.2.7.3 网络方面 调制调解器安全。防止对网络拨号设备的非授权访问，限制只有授权的 用户才可对系统进行访问。 为防止传输介质受到电磁干扰或被截获窃听，用防电磁泄漏的防护措施， 利用加密方法对抗截获窃听。 防火墙。在网络中心处建成专用防火墙以防止非法人员的攻击。 4.2.7.4 数据库方面 访问限制。设立 DBA,数据库用户及其访问权限应由 DBA 根据 DBMS 所提 供的功能进行控制。 数据加密。 跟踪审查。建立监视软件，对某些保密的数据实施跟踪，记录有关数据 的访问活动，一旦发现潜在的窃密企图，采取相应措施。 建立相关的备份程序，定期对系统中的数据进行备份。 22 镜像技术。执行时可用逻辑镜像，也可用物理镜像。 归档。将文件从在线存储器上复制到磁盘或光学介质上，以便长期保存。 4.2.8.物理配置方案设计 4.2.8.1 计算机网络的设计与选择 网络类型根据传输距离短选择局域网，网络拓扑结构选择星型结构，网络 协议选择企业内联网中应用广泛的 TCP/IP 协议。 4.2.8.2 计算机硬件设备选择 对于一般面向企业的管理信息系统，其应用本身一般是分布式的，故采用 微机网络，这样更灵活、经济。 由于现在微机在性能上已经有了很大的提高，甚至超出了早期大型机的水 平，而价格又相对较低，所以选择微机作为硬件支撑环境。 4.2.8.3 计算机软件配置选择 a、 中文的使用 b、 操作系统：Windows XP c、 数据库：关系型。 d、 常用程序设计语言：C+, VC, VB, Java. e、 第四代程序生成语言：Intellect、Clout、SQL、Focus. f、 工具：需求分析工具。 g、 应用系统设计开发环境：CASE. h、 图形软件：PS. i、 应用软件包：统计分析软件包、数学规划软件包。 4.2.8.4 费用预算 在经济可行性分析中，已预算计算机硬件费用约 4.3 万元，软件费用约 1.6 万元，计算机年维护费用约 3.5 万元，五年总计预算为 23.4 万元。 4.2.9.系统实施方案及说明 4.2.9.1 开发环境 本系统在 Windows XP 操作系统上开发，用 Visual Foxpro 6.0 进行前台界 23 面设计，SQL Sever 2000 进行后台数据库设计，Microsoft office visio 2003 进行 业务流程和数据流程设计。 Visual FoxPro 6.0 在开发上和实施过程中都体现了优越性，主要的特点表 现在以下几个方面： 易于使用； 可视化开发； 事件驱动； 面对对象编程； 应用向导和生成器； Visual Foxpro 6.0 基础类和组件库； 支持网络功能，编译速度更快； 支持 OLE 拖放和嵌入活动文档； SQL Server 2000 能够提供数据库之间的数据复制功能，可代替现有系 统数据的手工传递工作，降低出错率，提高数据的可用性。 Microsoft office visio 2003 能够进行业务流程和数据流程的设计。 4.2.9.2 调试和测试过程 测试是一个应用程序开发过程中的必要步骤，也只有通过测试，系统才能 确定其所拥有的功能是否已经具备，是否有不足之处，有哪些未知的错误以及 通过设置断点，用单步调试来确定有错误的代码，或者对可能发生异常的代码 短进行抛出、捕获异常，进而解决问题。 第五章第五章 公交车管理系统的功能实现公交车管理系统的功能实现 下面给出系统开发出来的详细界面以阐述售票管理系统的具体功能 5.1 登陆界面编码设计 首先是进入登陆界面。 sele 人员登录表 if allt(thisform.text1.value)= messagebox( 请输入账号！,64, 提示 ) thisform.text1.setfocus else if allt(thisform.text2.value)= 24 messagebox( 请输入登录密码！,64, 提示 ) thisform.text2.setfocus else locate for (allt(账号)=allt(thisform.text1.value) .and.; allt(密码)=allt(thisform.text2.value) ) if found() thisform.release clear event do qcmenu.mpr else if n1 messagebox(系统登录密码错误，请重新输入!,64, 提示 ) thisform.text1.value= thisform.text2.value= thisform.text1.setfocus n=n-1 else thisform.text1.enabled=.f. thisform.text2.enabled=.f. mand1.enabled=.f. messagebox(系统登录密码严重错误，请退出系统!,64, 提示 ) endif endif endif endif 5.2 人员整体信息管理界面编码设计 增加记录： thisform.grid1.enabled=.t. sele 工作人员表 append blank thisform.refresh thisform.grid1.setfocus 删除记录： if messagebox(确定要删除该条记录吗？,1+32,信息)=1 select 工作人员表 delete thisform.refresh thisform.grid1.setfocus else thisform.grid1.setfocus endif 修改记录：thisform.grid1.enabled=.t. 25 thisform.refresh 查询记录：thisform.grid1.enabled=.T. thisform.refresh 5.3 财务信息管理界面编码设计 5.4 客运信息查询 sele * from 客车信息表 into cursor temp thisform.grid1.columncount=-1 thisform.grid1.recordsource=temp 第六章第六章 系统测试系统测试计划计划 系统设计完成后，还有一项重要的工作，那就是系统测试和调试，找出不 足，进行系统完善。系统测试报告的主要内容和格式如下： 6.1.引言 6.1.1 编写目的 对项目进行测试，详细记录测试过程，对软件的质量进行评估，同时提供 了更正系统漏洞的依据。 6.1.2 定义 A.黑盒测试：黑盒测试也称功能测试，它是通过测试来检测每个功能是否 都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑 程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能 是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而 产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构， 主要针对软件界面和软件功能进行测试。 B.白盒测试：白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部 的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规 定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。 这一方法 是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息， 设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序 的状态，确定实际的状态是否与预期的状态一致。 6.2.计划 26 6.2.1 软件说明 名称功能输入输出 系统登录测 试 判别用户身份 是否合法 用户名、密码、权 限 显示相应子系统 财务管理测 试 财务流入支出 管理 财务收支信息修改、添加、删除财 务信息 职工信息查 询测试 职工各种信息职工号所需查询的职工相关 信息 会员测试帮助市民公交 卡充值、查询 用户 id 和公交卡 id公交卡余额显示，修 改、添加、删除会员 信息 客运信息测 试 查询客运的信 息 公交车牌号、查询 日期 该公车的司机与搭档 用户、管理 员管理测试 管理用户管理员登录系统查询、添加、删除、 修改、锁定用户 6.2.2 测试内容 测试 1： 名称：系统登录测试 目的：测试系统操作界面 内容：输入用户名、密码、权限，检查用户是否合理、合法 测试 2： 名称：财务管理测试 目的：测试公交系统财务管理功能 内容：查询、添加、删除、修改每日财务信息 测试 3： 名称：职工信息查询测试 目的：测试系统查询职工工资、职位等信息 内容：输入职工号和密码，进行职工信息查询 27 测试 4： 名称：会员测试 目的：会员公交卡充值功能和查询余额修改信息功能 内容：输入会员身份证和公交卡号，进行公交卡充值和查询 测试 5： 名称：客运信息测试 目的：明确公交负责人，查询公交出问题时由谁负责 内容：查询出所要查询的日期的公交是那个职工负责 测