UML课程设计汽车租赁系统的需求分析与设计讨论报告Word文件下载.docx

UML课程设计汽车租赁系统的需求分析与设计讨论报告Word文件下载.docx

《UML课程设计汽车租赁系统的需求分析与设计讨论报告Word文件下载.docx》由会员分享，可在线阅读，更多相关《UML课程设计汽车租赁系统的需求分析与设计讨论报告Word文件下载.docx（21页珍藏版）》请在冰豆网上搜索。

2．2功能要求

“汽车租赁系统”中的功能需求可以包括以下几个方面：

Ø

客户可以通过不同的方式（包括电话、前台、网上）预订车辆；

能够保存客户的预订申请单；

能够保存客户的历史记录；

工作人员可以处理客户申请；

技术人员可以保存对车辆检修的结果。

满足上述需求的系统主要包括以下几个模块：

基本数据维护模块：

该模块提供了使用者录入、修改并维护基本数据的途径。

基本业务模块：

在系统中，客户可以填写汽车租赁申请表，工作人员处理这些表格；

同时，技术人员还可以提交每辆车的状态，以便工作人员根据这些资料决定是否批准客户的请求。

数据库管理模块：

在系统中，对所有客户、工作人员以及车辆的信息都要进行统一管理，车辆的租赁情况也要进行详细的登记。

信息查询模块：

该模块主要用于查询相关信息。

3．课程设计报告内容

3．1各系统的功能模块详细内容及主要功能模块

基本数据维护模块包括的主要功能模块：

添加车辆信息

修改车辆信息

添加员工信息

修改员工数据

基本业务模块包含的主要功能模块：

用户填写预定申请

工作人员处理预定请求

技术人员填写服务记录

工作人员处理还车

数据库模块的主要功能模块：

客户信息管理

车辆信息管理

租赁信息管理

职员信息管理

信息查询模块的主要功能模块：

查询客户信息

查询职员信息

查询车辆信息

查询客户记录

下图为该汽车租赁系统的主要功能模块图：

3．2系统主要参与者

经过系统分析和实际需求，汽车租赁系统中的参与者主要有以下两类：

客户

公司职员

3．3系统的用例图

1、客户参与的用例图

客户在整个活动主要进行“预定车辆（reservethecar）”、“取得车辆（getthecar）”、“归还车辆（returnthecar）”这三种行为。

其中预定车辆可以通过不同的方式来进行，主要归为“电话联系（bycall）”、“网上预定（ontheweb）”两种形式。

如果车辆发生意外，客户在归还车辆时，还需要进行相关罚款，所以“罚款（returnwithfine）”作为“归还车辆（return）”的一个扩展用例。

如果采取进行“网上预定”的形式，则需要在网上进行相关表格填写！

所以“filltheorderform（填写指定表格）”是“网上预定（ontheweb）的一个扩展例。

因此整个用例模型图如下所示：

2、公司职员参与的用例图

相对客户行为而言，公司员工所要进行的行为就比较多，可以分为以下几类：

systemlogin（系统登陆）

reserve（处理客户预定信息）

givethecartocustomer（取车给客户）

endthebussiness（结束交易）.

reserve（处理客户预定信息）可以通过〈〈use〉〉方法来进行“Querrycustomerorderrecord”、“refuserequest”、“acceptrequest”进行相关操作。

3．4系统的顺序图

系统的顺序图主要从以下几方面进行描述的：

•管理人员开展工作的顺序图

•客户预订车辆的顺序图

•客户取车的顺序图

•客户还车的顺序图

1、管理人员开展工作的顺序图

管理人员需要进行相关工作记录的审核工作和跟员工交流沟通，并没有直接跟客户有直接关系，因此管理人员开展工作的顺序图主要涉及到这三个类：

●Managers

●RentRecords

●Employees

注：

因为Employees（员工）不只一人，所以他们之间会有相互了解、影响和合作，所以不能忘记了他们之间的内部活动。

员工与经理之间也是一个互动过程。

具体顺序图如下所示：

【顺序图说明】

（1）checkRecord（）:

查看记录

（2）checkWorkInfo（）:

查看工作信息

（3）calculate（）:

核算

（4）returnresult（）:

返回结果

2、客户预订车辆的顺序图

客户申请车辆时，要进行个人息的填写等、通过相关合法检测后，才能够成功预定到车辆。

具体类有以下五个：

●Customers（顾客）

●Requests（请求表）

●CommmonWorkers（普通员工）

●CustomerRecord（顾客记录表）

●Cars（车辆）

具体流程：

顾客需要在请求表中填写信息，再由普通工作人员审核，普通工作人员在以往顾客表中审核相关信息，看是否顾客有损坏车辆的不好记录，若无不良状况，检查车辆状态，如果有合适的话，进行顾客租车的信息记录，并在请求中填写“允许”，并把这个请求结果通知顾客！

（1）fillOrder（）:

填写要求

（2）checkRequest（）:

查看客户请求

（3）check（）:

查看

（4）noproblem（）:

没有问题

（5）Inserviced（）:

是否可使用

（6）ok（）:

可以

（7）creatnewcustomerrecored（）:

进行客户信息的新记录

（8）Allow（）:

允许

（9）isHandled（）:

处理并发送

（10）notify（）:

通知

3、客户取车的顺序图

客户取车的顺序图包括以下几个类：

●WorkRecord（工作记录表）

只要认真分析，不难理解客户取车过程,要注意取车的同时要付款。

（1）shownotice（）:

提供身份

（2）check（）:

核查

（3）ok（）:

（4）pay（）:

付款

（5）fillWorkRecord（）:

填写员工自己的工作记录

（6）update_carstatus（）:

把车的状况进行转换

4、客户还车的顺序图

这个顺序图将跟上面的对象有些不同，基于实际需要，主要还涉及：

进行汽车检查的技术工作人员（SkillWorkers）、汽车状况登记表（ServiceRecords）、租用登记表（RentRecords）等类！

具体涉及类：

●SkillWorkers（技术工作人员）

●CustomerRecord（顾客登记表）

●RentRecords（租用登记表）

●ServiceRecords（服务登记表）

顾客把车返还给普通员工，普通员工把车交给技术员工，技术员工进程车辆状态检查，并填写相关车辆状态情况，作好记录后在交给普通员工，若车辆出现问题，普通员工会通知顾客进行相关赔偿；

顾客财产保险后，普通员工进行车辆保修情况进行记录，并登记顾客把车返还等相关信息，并更新相关租用信息，使得这辆车能够投入下一轮回的使用！

【顺序图说明】

（1）returnback（）:

还车

（2）check_carstatus（）:

检查车的情况

（3）fillRecord（）:

填写车的相关情况表

（4）return（）:

返回车情况表

（5）notify_payment（）:

通知付款

（6）pay（）:

（7）update_carstatus（）:

进行车辆信息的转换（空闲、不空闲、维修）

（8）end（）:

取消客户记录

（9）updateRecord（）:

更新当前工作记录

3．5系统的协作图

系统的协作图按流程和时间段主要分为三部分：

•客户预订的协作图

•客户取车的协作图

•客户还车的协作图

1、客户预订的协作图，如下所示：

跟上面的客户预订的顺序图有相似之处，并可以相互转换。

2、客户取车的协作图，如下所示：

跟上面的客户取车的顺序图有相似之处，并可以相互转换。

3、客户还车的协作图，如下所示：

跟上面的客户还车的顺序图有相似之处，并可以相互转换。

3．6系统的状态图

系统的状态图主要思路：

客户发送请求——工作人员处理请求——工作人员审核客户的相关资料，基于资料是否真实，当审核通过后，接受客户的请求——记录并保存相关信息——客户取车——客户还车——技术人员进行车辆检查——成功交易——结束；

当审核未通过后，工作人员不接受客户请求——停止这场交易——结束。

具体状态图所下所示：

3．7系统的活动图

尽管活动图与状态图、交互图有类似之处，工作人员和客户的行为表示也差不多，但亦有不同之处，活动图是可以把不同对象同时进行相关事情操作的，可以进行分支描述！

根据现实的需要和综合考虑，可以把活动图分成以下“客户”“工作人员”这两个分支来进行描述的！

主要思路：

一方面，顾客进行车辆租用申请表填写，并发送保存；

另一方面，员工定时进行请求查看，当有新的请求时，员工会先查看顾客以往记录，如果顾客以往记录良好，又有车辆空闲的话，会向顾客发送接受请求的信息，顾客去取得车辆，使用后并归还！

如果当员工并没有及时向顾客发送接受请求的信息，会终止交易！

当车辆已全部投入使用，并没有空闲的车辆，也会终止交易！

如果顾客的以往记录很差，员工拒绝租车给顾客，不再进行交易！

具体活动图如下所示：

3．8系统中的类

1、系统中主要的类，可分为以下两类：

●客户和公司职员类

●一些其他的类

客户和公司职员类

经过全面分析和考察，可以找到系统中以下几个类：

●Customer（顾客）

●Manager（经理）

●SkillWorker（技术工作人员）

●CommonWork（普通工作人员）

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

Manager（经理）、SkillWorker（技术工作人员）、CommonWork（普通工作人员）可以归为Employee（员工）.

Employee（员工）和Customer（顾客）是Person（人）的泛化.

上述类，具体关系如下所示：

一些其他的类

系统中还会涉及一些其他类，这些类不可忽视，经分析，有以下几个类：

●CustomerRecord（客户记录）

●Car（车）

●serviceRecord（维修记录）

●Req