目录
1需求分析 ................................................................................................................................................................... 2 1.1需求获取 .................................................................................................................................................................... 2 1.2业务建模 .................................................................................................................................................................... 2 1.3业务规则建模 ............................................................................................................................................................ 3 1.3.1管理人员开展工作顺序图 ................................................................................................................................. 3 1.3.2客户预订车辆的顺序图 ..................................................................................................................................... 4 1.3.3客户取车顺序图 ................................................................................................................................................. 5 1.3.4客户还车顺序图 ................................................................................................................................................. 6 1.3.5 客户预订车辆的协作图 .................................................................................................................................... 7 1.3.6客户取车协作图 ................................................................................................................................................. 7 1.3.7客户还车协作图 ................................................................................................................................................. 8 1.4业务过程建模 ............................................................................................................................................................ 8 1.4.1系统的状态图 ..................................................................................................................................................... 8 1.4.2系统的活动图 ..................................................................................................................................................... 9 2系统分析 .................................................................................................................................................................. 11 2.1概念用例 .................................................................................................................................................................. 11 2.1.1客户参与的用例图 ........................................................................................................................................... 11 2.1.2公司员工参与的用例图 ................................................................................................................................... 12 2.2分析类模型 .............................................................................................................................................................. 12 2.3组件模型 .................................................................................................................................................................. 14 2.4软件构架和框架建模 .............................................................................................................................................. 14 3系统设计 .................................................................................................................................................................. 15 3.1设计类模型 .............................................................................................................................................................. 15 3.1.1客户和公司员工类 ........................................................................................................................................... 15 3.1.2一些其他的类 ................................................................................................................................................... 16 3.2接口设计模型 .......................................................................................................................................................... 17 3.3包设计模型 .............................................................................................................................................................. 18 3.4部署模型 .................................................................................................................................................................. 18
1需求分析
这里介绍一个简单汽车租赁系统的需求分析。
1.1需求获取
本系统的功能性需求包括以下几个方面：
（1） 客户可以通过不同的方式（包括电话、前台、网上）预订车辆； （2） 能够保存客户的预订申请单； （3） 能够保存客户的历史记录； （4） 工作人员可以处理客户申请；
（5） 技术人员可以保存对车辆的检修结果；
为了满足上述需求，则系统主要包括以下几个模块：
（1） 基本数据维护模块。基本数据维护模块提供了使用者录入、修改并维护基本数据的途径。例如，
对客户的个人信息、租赁信息、车辆的基本信息等的录入和修改。
（2） 基本业务模块。基本业务模块中，客户可以填写汽车租赁申请表，工作人员负责处理这些表格。
同时，技术人员还可以提交每辆车的状态，以便工作人员根据这些资料决定是否批准客户的请求。
（3） 数据库管理模块。在汽车租赁系统中，对所有客户、工作人员以及车辆的信息都要进行统一管
理，车辆的租赁情况也要进行详细的登记。
（4） 信息查询模块。信息查询模块主要用于查询相关信息，例如工作人员查询车辆信息和客户信息
等。
图1所示表示汽车租赁系统的功能需求。
图1 功能需求
1.2业务建模
系统业务用例图如图2所示。
ＵＭＬ系统分析设计报告
uc 业务用例 system managementrent carcustomeremployeereturn car
图2 系统业务用例图
1.3业务规则建模
汽车租赁系统的顺序图主要有如下4个：
（1） 管理人员开展工作的顺序图。 （2） 客户预订车辆的顺序图。 （3） 客户取车顺序图； （4） 客户还车顺序图；
1.3.1管理人员开展工作顺序图
sd 管理人员时序图 theRentRecord：WorkRecord：Manager：CommonWorker1：viewRecord()2：viewWorkInfo()4：returnresult()3：calculate()
图3 管理人员开展工作的顺序图
3
顺序图说明：
（1） viewRecord（）：查看记录函数。 （2） viewWorkInfo（）：查看工作记录函数。 （3） calculate（）：计算工作人员的任务完成率的函数。
管理人员既可以查看汽车的租赁记录，又可以查看普通工作人员的工作记录和任务完成情况。
1.3.2客户预订车辆的顺序图
sd 客户预订车辆时序图 theRequest：RequestOrder：Customer：CommonWorkertheCustomerRecord：CustomerRecordtheCar:Car1：fillOrder()2：checkRequest()3：check()4：noproblem()5：InServiced()6：ok()7：create new customerrecord()8：allow()9：isHandled()10：notify()
图4 客户预订车辆的顺序图
顺序图说明：
（1） fillOrder（）：填写租赁申请表的函数。 （2） checkRquest（）：查看申请的函数。 （3） check（）：检查历史记录的函数。 （4） InServiced（）：判断车辆状态的函数。 （5） allow（）：允许客户租赁车辆的函数。 （6） isHandled（）：表明请求已处理。 （7） notify（）：通知客户前来取车的函数。
客户要租赁车辆，首先必须填写申请表。公司员工负责处理申请表，他们根据客户租赁的历史记录以及客户申请的车辆的状态决定是否接受客户请求。如果他们两个条件都满足，那么将接受请求并且为客户预留该车；否则就拒绝请求，处理过的申请表的状态都设为已处理，如果接受用户的租赁请求，首先为该客户添加一条记录，然后通知客户前来取车。
ＵＭＬ系统分析设计报告
1.3.3客户取车顺序图
sd 客户取车时序图 theRequestOrder：RequestOrder：Customer：CommonWorkertheWorkRecord：WorkRecordtheCar：Car1：show_notice()2：check()3：ok()4：pay()5：fillWorkRecord()6：update_carstatus()
图5 客户取车顺序图
顺序图说明:
（1） show_notice（）：向工作人员出示取车通知。 （2） check（）：工作人员检查取车通知的合法性。 （3） pay（）：客户付款。 （4） fillWorkRecord（）：公司员工创建工作记录。 （5） update_carstatus（）：更新汽车状态信息。
客户在约定的时间到前台取车，公司员工首先验证取车通知，验证通过后，将要求客户付款，然后填写一份工作记录，同时修改车辆状态。
5
1.3.4客户还车顺序图
sd 客户还车时序图 theCar：Car：Customer1：returnback()2：check_carstatus()3：fillRecord()4：return()5：notify_payment()6：pay()7：update_carstatus()8：end()9：updateRecord()：CommonWorker：SkillWorkertheServiceRecord：ServiceRecordtheCustomerRecord：CustomerRecordtheRentRecord：WorkRecord
图6 客户还车顺序图
顺序图说明：
（1） check_carstatus（）：检查车辆状况的函数。 （2） fillRecord（）：填写车辆检查记录的函数。 （3） notify_payment（）：通知客户支付租赁款项的函数。 （4） update_carstatus（）：更新车辆信息的函数。 （5） end（）：结束租赁交易的函数。 （6） updateRecord（）：更新工作记录的函数。
客户在规定时间将车返还给租赁商店，技术人员将对车辆进行检修以确定是否有损坏，并且填写一份服务记录，公司职员将根据记录确定客户应付的款项。与客户交易完成后，需要修改车辆的状态、客户记录以及工作记录等。
ＵＭＬ系统分析设计报告
1.3.5 客户预订车辆的协作图
6: isHandled（）1: fillOrder（）theCustomer：Customer7: notify（）theRequestOrder：RequestOrder2: checkRequest（）theCommonWorker：CommonWorker5: Allow（）/Deny（）3: check（）8: newCustomerRecordtheCar：Car4: InServiced（）theCustomerRecord：CustomerRecord
图7 客户预订车辆的协作图
协作图说明：
（1） fillOrder（）：申请表类中填写租赁申请表的函数。 （2） checkRequest（）：普通公司员工类中查看申请的函数。 （3） check（）：客户租赁历史记录类中的检查历史记录的函数。 （4） InServiced（）：车辆类中的判断车辆状态的函数。 （5） Allow（）：允许客户租赁车辆的函数。 （6） isHandled（）：判断预订表单是否被处理的函数。 （7） notify（）：通知客户前来取车的函数。
1.3.6客户取车协作图
1: show_notify（）theCustomer：Customer4: take_car（）theRequestOrder：RequestOrder2: check（）3: validatetheCommonWorker：CommonWorker5: fillWorkRecord()6: update_carstatustheCar：CartheWorkRecord：WorkRecord
图8 客户取车协作图
协作图说明：
（1） show_notify（）：向工作人员出示取车通知。 （2） check（）：工作人员检查取车通知的合法性。 （3） take_car（）：客户取车。
7
（4） fillWorkRecord（）：公司员工创建工作记录。 （5） update_carstatus（）：更新汽车状态信息。
1.3.7客户还车协作图
6: pay_money()1: return_car()theCustomer：Customer4: update_carstatus()theCar：Car2: check_carstatus()theCommonWorker：CommonWorker7: end()3: fillRecord()theServiceOrder：ServiceRecord5: show_payment()8: updateRecord()theCustomerRecord：CustomerRecordtheWorkRecord：WorkRecord
图9 客户还车协作图
协作图说明：
（1） return_car（）：客户还车的函数。 （2） check_carstatus（）：检查车辆状况的函数。 （3） fillRecord（）：填写车辆检查记录的函数。 （4） update_carstatus（）：更新车辆信息的函数。 （5） show_payment（）：通知客户相关费用。 （6） pay_money（）：客户付款。 （7） end（）：结束租赁交易的函数。 （8） updateRecord（）：更新工作记录的函数。
1.4业务过程建模 1.4.1系统的状态图
由于系统的几个对象，如客户预订申请表类、客户租赁历史记录类、工作记录类、维修记录类和车辆类的状态都很少，不需要用创建状态图，所以此处将建立整个系统的状态图，如图10所示。
ＵＭＬ系统分析设计报告
图10 系统状态图
状态图说明：
（1） customer send the request：客户提出租赁申请。
（2） employee handle the request：公司员工处理申请请求。 （3） search relating information：查找租赁的相关历史记录。 （4） accept the request：接受租赁请求。 （5） store information：存储交易信息。 （6） customer get the car：客户取车。 （7） customer return the car：客户还车。 （8） check the car：检查车辆状况。 （9） deny the request：拒绝租赁请求。 （10） end the business：结束交易。
从客户填写预订申请表开始，租赁商收到客户的申请并对其进行处理。根据客户的历史记录以及车辆的状态确定是否接受客户请求。如果某个条件不符合，就向客户发送一个拒绝通知，交易结束；如果条件都符合，则接受该请求并保存相关数据。客户在约定时间内来取车，取车需出示相关通知。车辆使用以后，客户必须在规定的时间将车返还给租赁商。还车后技术人员还会对车辆进行检查，根据车辆状况收取相应费用，如果车辆破损还要收取罚金。最后，交易结束。
1.4.2系统的活动图
汽车租赁系统的活动图如图11所示。要注意的一点就是，租赁者填写租赁申请表和公司员工处理申请可以并发执行。
9
图11 系统的活动图
活动图说明：
（1） customer request：客户填写租赁申请。 （2） store the request：存储申请表。
（3） employee check the request：公司员工查看租赁申请。 （4） handle new request：处理新的租赁申请。
（5） check the customer’s record：查看客户租赁的历史记录。 （6） deny request：拒绝租赁请求。 （7） the car is available：车辆为可用。 （8） send the message：发送取车通知。 （9） customer acquire the car：客户取车。 （10） customer give the car back：客户还车。
ＵＭＬ系统分析设计报告
2系统分析
2.1概念用例
2.1.1客户参与的用例图
图12 客户参与的用例图
用例图说明：
（1） reserve the car：预订车辆的用例。
（2） by phone：电话预订用例。这是从预订用例扩展出来的一种预订方式。
（3） on the web：网络预订用例。这是从预订用例扩展出来的另一种预订方式，用户可以在公司主页
上提交预订申请。
（4） fill the order form：填写预订申请表的用例。如果客户在网上预订，也必须完成预订申请表。 （5） get the car：取车用例。 （6） return the car：还车用例。
（7） return with fine：交纳罚金用例。客户如果不能够按时还车将要交纳罚金。
11
2.1.2公司员工参与的用例图
图13 公司员工参与的用例图
用例说明：
（1） system login：系统登录用例。 （2） reserve process：预订处理用例。
（3） query customer order record：查询客户预订历史记录用例。工作人员可以把客户的历史记录作为
判断是否接受客户请求的一个依据。
（4） refuse request：拒绝预订请求用例。工作人员可以根据情况拒绝客户的预订请求，例如客户历
史记录不良，没有所需车辆等。
（5） accept request：接受预订请求用例。工作人员在核对客户情况及车辆状态后，可以接受客户的
请求。
（6） give the car to customer：将预订的车交付客户用例。
（7） check the car：检查车辆状况用例。技术人员可以对车辆进行检查，以确定车辆是否被损坏。 （8） end the business：结束租赁业务用例。
2.2分析类模型
系统中各实体类、边界类、控制类之间的交互如图14、15、16所示。
ＵＭＬ系统分析设计报告
class 分析类类图 车辆信息查询按钮CarRecord顾客信息查询按钮CustomerRecord主窗口employee信息查询按钮按钮事件处理器查询主窗口工作记录查询按钮获得记录WorkRecord服务记录查询按钮ServiceRecord员工信息查询按钮EmployeeRecord 图14 查询的分析类类图
class 分析类类图2 车辆信息编辑按钮CarRecord增加按钮顾客信息编辑按钮CustomerRecord主窗口employee基本信息维护按钮按钮事件处理器信息维护主窗口工作记录编辑按钮获得记录删除按钮按钮事件处理器WorkRecord服务记录编辑按钮修改按钮ServiceRecord员工信息编辑按钮EmployeeRecord 图15 编辑基本信息的分析类类图
class 分析类类图3 生成通知单主窗口按钮事件处理器添加申请表按钮申请表填写界面提交按钮创建申请表业务处理主窗口employee业务处理按钮车辆状态及客户信息检查RequestOrderCarRecordCustomerRecord还车按钮获取租车记录更新记录ServiceRecordWorkRecord 图16 业务处理的分析类类图
13
2.3组件模型
汽车租赁系统是建立在一个含有过去租赁记录、汽车信息、服务记录以及客户和员工信息的中央数据库上。系统组件图如图17所示，包括租赁程序、员工记录、服务记录、工作记录和汽车记录5个组件。
图17 汽车租赁系统的组件图
2.4软件构架和框架建模
本系统采用CS架构的三层体系结构，如图18所示，应用JAVA语言辅以SQL Server数据库进行开发。 数据服务层 Server 业务服务层 功能层 Client 用户服务层 表示层
图18 系统CS三层架构图
ＵＭＬ系统分析设计报告
3系统设计
3.1设计类模型
类图的设计是系统设计最核心的部分，明确基本类以及基本类之间的相互的关系有助于开发的后续设计。此处将详细介绍汽车租赁系统的类图设计。
3.1.1客户和公司员工类
系统中客户和公司员工类图如图19所示。另外，这里省略了一些普通方法，例如get和set方法。
class 类图 Person- - - - + + + + + + + address: StringID: Stringname: StringphoneNo: StringgetAddress() : StringgetID() : StringgetName() : StringPerson() : voidsetAddress() : voidsetID() : voidsetName() : voidCustomer- - CarType: StringlicenseNo: String- - - EmployeedateHired: StringType: intWorkID: String+ Customer() : String+ print() : String+ Employee() : StringCommonWorkerManager- manager: boolean+ calculate() : float+ checkRequest() : boolean+ viewWorkInfo() : String- commissionRate: int- - SkillWorkerqualifications: Stringskills: String+ Manager() : String+ viewWorkInfo() : String+ SkillWorker() : String
图19 客户和公司员工类图
类图说明：
（1） Person类是所有类的父类，它包含4个属性：姓名（name），身份证号（ID），地址（address）
和电话号码（phoneNO）。它包含的方法都是用来设置和获取这些属性值。
（2） Customer类是包含客户信息的类，除了继承父类的属性和方法，它包括车辆类型（CarType）
和驾驶证号（licenseNo）等属性。
（3） Employee类是包含员工信息的类，其中包含了员工的聘用日期等信息。同时，它还是Manager、
15
CommonWorker、SkillWorker3个类的父类。
（4） Manager类是管理人员的类，管理人员可以查看工作人员的工作记录。CommonWorker类是普
通工作人员类，commissionRate属性是该员工完成任务率；方法calculate（）用来计算该工作人员完成的任务率；checkRequest（）用来查询是否有没处理的申请单。SkillWorker类是技术人员的类，skills属性代表该员工的技术特长，而qualifications属性则表示他的技术职称。
3.1.2一些其他的类
其他的类图如图20和图21所示。
class 类图 CustomerRecord- - - - - CarNumber: StringCarType: StringcustomerID: StringIsFinish: StringrentDate: String- - - - CarCarNumber: Stringcondition: Stringstatus: StringType: StringServiceRecord- - progressReport: StringserviceHistory: String+ check() : String+ end() : void+ InServiced() : boolean+ update_carstatus() : void+ fillRecord() : void
图20 其他类图1
class 类图 WorkRecordRequestOrder- - - + + + + CarType: StringIsAllow: StringRentDate: StringAllow() : voidcheck() : booleanfillOrder() : voidisHandled() : void- - - - - - - - CarNumber: StringCarType: StringCommonWorkID: StringCustomerID: Stringmoney: floatRentDate: StringReturnDate: StringSkillWorkID: String+ fillWorkRecord() : void+ updateRecord() : void+ viewRecord() : String
图21 其他类图2
类图说明：
（1） CustomerRecord类表示客户记录。customerID是客户的身份证号码，rentDate是租车日期，
CarType是所组车辆的车型，CarNumber是该车的车牌号码，IsFinish代表该交易是否结束。check（）用来得到该客户的记录，end（）用来结束该交易。
（2） Car类代表车辆记录。Type是该车的车型，CarNumber是车牌号码，status是指该车是否被预订、
正在使用中或空闲状态，condition是指该车的状态。InServiced（）用来判断该车是否空闲，update_carstatus（）用来修改车辆所处的状态。
（3） ServiceRecord类表示每一次租赁服务的记录。serviceHistory是服务的历史记录，progressReport
是指该过程中的报告。fillRecord（）用于填写表格。
（4） RequestOrder类表示的是填写客户申请资料的表格。CarType表示客户申请的车型，RentDate
ＵＭＬ系统分析设计报告
是租车的时间，IsAllow属性表示该客户的申请是否得到批准。Allow（）用来接受客户的请求，fillOrder（）是指客户填写表格，check（）用来检查是否存在这个申请，isHandled（）设置该申请已被处理。
（5） WorkRecord类是职员的工作记录。属性包括交易中涉及的员工、客户、车辆以及租赁信息。
fillWorkRecord（）用来填写这份记录，viewRecord（）用来查看这份记录，updateRecord（）用来修改这份记录。
3.2接口设计模型
类不是单独一个模块，各个类之间是存在联系的，本系统中不存在接口的实现。汽车租赁系统各个类之间的联系如图22所示。
class 类图2 WorkRecord- - - - - - - - CarNumber: StringCarType: StringCommonWorkID: StringCustomerID: Stringmoney: floatRentDate: StringReturnDate: StringSkillWorkID: String+theWorkRecord*1- EmployeeManagermanager: booleanCar- - - - CarNumber: Stringcondition: Stringstatus: StringType: String+ InServiced() : boolean+ update_carstatus() : void+theCar**+ fillWorkRecord() : void+ updateRecord() : void+ viewRecord() : String1..*+ Manager() : String+ viewWorkInfo() : StringCustomerRecord*EmployeeSkillWorker- - qualifications: Stringskills: String- 11EmployeeCommonWorkercommissionRate: int1*- - - - - CarNumber: StringCarType: StringcustomerID: StringIsFinish: StringrentDate: String+ SkillWorker() : String+theServiceRecord11+ calculate() : float+ checkRequest() : boolean+ viewWorkInfo() : String+ check() : String+ end() : void1+theCommonWorker1..*1ServiceRecord- - *RequestOrderPerson- - - *+ + + + CarType: StringIsAllow: StringRentDate: StringAllow() : voidcheck() : booleanfillOrder() : voidisHandled() : voidCustomer- - CarType: StringlicenseNo: String1progressReport: StringserviceHistory: String+ fillRecord() : void+ Customer() : String+ print() : String
图22 类之间的关系
类图说明：
从图中可以看出，工作人员（CommonWorker）可以查看所有客户（Customer）的租赁历史记录（CustomerRecord），可以处理几个客户的租赁申请（RequestOrder）。由于工作人员可以同时处理多个业务，那么他可以拥有多个服务记录（ServiceRecord）和工作记录（WorkRecord）。技术人员（SkillWorker）需要同时维护多辆车（Car），每辆车也需要多个人员进行维护。经理（Manager）可以查看多个职员的工作记录。
17
3.3包设计模型
这个系统可以看成页面显示（webPages）、业务逻辑（Business）、数据访问（DataAccess）三块，分别控制不同的应用。整体包图如下：
pkg 包图 BusinessDataAccessWebPages
图23 系统包图
各层的职责：
（1） 页面显示包
包含了系统所涉及到的所有页面显示，这样做的好处是再添加新的页面显示时就不会影响到别的包。 （2） 业务逻辑包
包含了所有的事务，如果在管理过程中需要增加某事务，那么只需在本包中添加相应的类即可。 （3） 数据访问包
包含了系统访问数据库的所有类操作。这样，当修改数据访问时就不会影响到界面或事务操作。
3.4部署模型
汽车租赁系统由5个节点构成，应用服务器负责整个系统的总体协调工作；数据库负责数据管理；前台工作人员负责处理客户请求以及进行租赁交易；管理人员管理界面主要是用来对员工信息进行查询；而技术人员界面则是用于技术人员查询、修改汽车的状态，系统配置图如图24所示。
ＵＭＬ系统分析设计报告
图24 汽车租赁系统的部署图
19
因篇幅问题不能全部显示，请点此查看更多更全内容