基于uml的汽车租赁管理系统

相关主题
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

基于u m l的汽车租赁管

理系统

Company number:【WTUT-WT88Y-W8BBGB-BWYTT-19998】

一、系统概述

目前有驾照但还没有买车的消费者对短期汽车租赁需求非常大。而这两年来,汽车租赁公司如雨后春笋般出现也印证了市场的潜力所在。不过,由于目前租赁业还未有统一的管理标准,整个行业乱象丛生。管理落后、价格较低、租赁陷阱随处可见,一些有实力的企业也苦于无序竞争而不敢扩张投入,因此制约了整个行业的发展。

在经济全球化快速发展的过程中,信息的快速收集,反应快速准确也越来越多的被企业应用,企业已经逐渐认识到了建立现代化的管理信息系统是影响企业发展的决定因素。但是目前,大多数的汽车租赁公司由于考虑成本等的问题,并没有采取存储量大、处理快速、及时便捷的计算机信息化管理模式,而是仍然采取了较为原始的手工管理模式。而利用计算机网络信息化管理的汽车租赁管理系统,就可以解决手工管理模式中存在的一些问题,形成一系列完整的同步管理。

本文正是对基于UML建模的汽车租赁管理系统的设计进行了深入的分析和研究,旨在寻求一种更加便捷、高效的汽车租赁管理途径。以汽车租赁管理系统开发为背景,利用UML建模语言,分析了系统的用户需求模型、静态模型、动态模型。并针对传统汽车租赁管理系统的局限性设计出一套基于UML 建模的汽车租赁管理系统。此系统能显着的提高软件开发管理,促进软件重用和提高汽车租赁行业的整体效益。

二、系统分析

可行性分析

可行性分析研究即在项目正式开发前对各种可能的风险进行充分的分析、估算,避免人力、物力和财力方面的浪费。对有风险的项目进行开发,提出具体开发方案,建立相应的开发模型,对各种风险的程度及应对策略进行详细论证,将因风险可能带来的损失降低到最小程度。

经济可行性分析

汽车是目前出行选择的便捷的交通工具,其经济成分比重很大,资金投入包括前期投入、日常保养和后期维护;收入主要是客户交付的租金。由于目前对汽车的需求较大,因此实施此系统对企业成功不可缺少,所以投入该系统势在必行。

技术可行性分析

技术可行性分析主要分析在现有技术条件下能否顺利完成开发工作;硬件、软件配置是否满足开发者的需求;相关技术人员的数量、水平和来源等。项目组通过分析,上述三个需求均能满足,因此该系统具有技术可行性。

社会可行性分析

当前信息技术飞速发展,计算机技术和软件技术的更新使机房管理完全有可能也有能力采用这种先进的管理技术。对租赁行业带来的影响:对传统手工管理是一次不小的震撼,带来整个汽车租赁行业的蓬勃向上;提高了对公司员工的要求,在可能的条件下精简了企业人员,迫使员工不断学习新的计算机知识;转变和扩充了计算机与用户之间的业务方式。

通过以上在经济、技术、社会三方面的可行性分析得知,汽车租赁系统是可行的,是可开发的。

需求分析

汽车租赁需要管理事务较多,为了减少开支,员工数量不能太多,因而公司员工工作量较大。因此,汽车租赁行业迫切的需要规范其管理流程以及日常重点工作,并借助相应的管理软件进行管理。

客户在整个活动主要进行预定车辆、取得车辆、归还车辆这三种行为。其中预定车辆可以通过不同的方式来进行,主要归为电话联系、租赁店预订和网上预订两种形式。客户在取车时还可以试驾一下车辆,因此试驾与取车时一个包含用例。如果车辆发生意外,客户在归还车辆时,还需要进行相关罚款,作为归还车辆的一个扩展用例。

如果采取进行网上预定的形式,则需要在网上进行相关表格填写!所以填写指定表格是网上预定的一个扩展例。因此整个用例图如图2-1所示:

图 2-1 客户租车子系统

公司职员参与的用例图

相对客户行为而言,租赁公司员工所要进行的行为就比较多,可以分为以下几类:处理客户预定信息,其中它的子用例为:查询客户预定信息、拒绝租车服务、接受租车服务;提车给客户,在客户取车时,可以给客户试驾,因此试驾是提车的扩展用例;归还车辆,归还车辆时对车辆的检查,如果损坏就应当作出相应赔偿,因此损坏赔偿是归还车辆的扩展用例.公司职员参与的用例图如图2-2所示:

图2-2 员工管理子系统

系统静态建模

在面向对象的分析与设计中,类图是由若干类的图形符号及表示其之间关系的图形符号组成。经过全面分析和考察,可以找到系统中以下几个类:客户、经理、技术员工、普通员工。

其中它们之间的关系可以融合成:

经理、技术员工、普通员工可以归为员工

上述类,具体关系如图 2-3所示:

图2-3 客户、员工类

下面列举的是这个系统进行交互的类图,这些类图彼此之间是联系着的,缺少了一个都会不完整,都不利于工作的开展。具体图示如图2-4所示:

图2-4交互类

工作记录表类是工作记录的类,它的属性很多,包括客户的编号、普通员工编号、技术员工编号、租车起止日期、车的编号和租金。其中主要操作有填写工作记录表和更新修改等。

经理类是管理员类,操作主要是管理和审核工作情况。

车类是车的类,属性包括车的编号、车的状况和目前是否在租。操作包括维护信息正在使用、修改车的状况等。

普通员工类是普通员工信息类,包括业务提成等属性,操作主要有查询订单、处理订单、取车、还车等。

技术员工类,技术水平、相关证书等属性,主要操作有汽车的日常维护等客户需求类是需求表类,主要包括请求的车类型、租车日期、价格等属性,主要操作包括填写表格、核查、处理等。

三、系统设计

功能设计

在系统中,只有管理人员才有权限使用本系统,才能对数据库进行操作。

公司员工对基本信息的管理,包括对汽车信息的增加、删除、修改和查询,车辆的维护和车况的检查。其中,车辆维护信息和车辆的状况由车辆维护表直接查询出来。

公司员工对客户信息的管理,主要是客户信息的增加、删除、修改和查询以及对客户对车辆需求表的管理。所以,有客户会员管理用例和客户信息管理用例。

公司员工对租赁业务的管理,包括车辆信息的查询;车辆返还信息的增加、删除、修改和查询;车辆出库信息的增加、删除、修改和查询;以及租金业务的查询、添加、修改等。

管理人员对系统用户的管理,包括系统用户的增加、删除、修改和查询和密码的修改;以及对系统的更新。

分析系统的使用对象和用户需求,设计系统的体系结构。系统的功能模块如图3-1所示。

图3-1 功能结构图

系统动态建模

客户申请车辆时,要进行个人息的填写等、通过相关合法检测后,才能够成功预定到车辆。具体类有以下五个:客户、需求表、普通员工、客户记录表、车辆信息。

具体流程:客户需要在需求表中填写信息,再由普通工作人员审核,普通工作人员在以往客户表中审核相关信息,看是否顾客有损坏车辆的不良记录,

相关文档
最新文档