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

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

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

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

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

基本数据维护模块：

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

基本业务模块：

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

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

数据库管理模块：

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

信息查询模块：

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

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（维修记录）

●RequestOrder（请求登记表）

具体类图的属性和方法如下所示：

各个类之间的关系

上面列举的是这个系统进行交互的类图，这些类图彼此之间是联系着的，缺少了一个都会不完整，都不利于工作的开展！

具体分析：

1.每个经理可以有多张工作记录表（一对多的关系）

2.每个普通员工可以有多张工作记录表（一对多的关系）

3.每个普通员工有相应的多张顾客记录表（一对多的关系）

4.每个普通员工可以对多辆车辆进行分配和安排（一对多的关系）

5.一辆车可以有多个技术工人进行维修，一个技术工作也可以对不同的车辆进行维修（多对多的关系）

6.每个技术工人每次只能在记录表进行一次记录（一对一的关系）

7.一个普通员工可以收到不同的车辆保养记录表（一对多的关系）

8.一个普通员工可以同时招待多个顾客（一对多的关系）

9.每个顾客一次只能在一个请求登记表进行登记（一对一的关系）

具体图示如下所示：

【类图说明】

（1）WorkRecord类是工作记录的类，它的属性很多，包括客户的身份ID（CustomerID）、普通员工身份ID（CommonWorkID）、技术员工身份ID（SkillWorkID）、借用日期（RentDate）、归还日期（ReturnDate）、车的类型（CarType）、车牌号（CarNumber）、租金（money）等。

其中主要操作有填写工作记录表（fillWorkRecord（））、查看工作记录（ViewRecord（））和更新修改（updateRecord（））等。

（2）Manager类是管理员类，他有boolean（正负级）属性，操作主要是管理和审核工作情况。

（3）CustomerRecord类是记录顾客信息的类，包括顾客的身份（customerID）、租车日期（rentDate）、车的类型（carType）、车牌号（carNumber），完成交易（IsFinish）属性等，操作主要有审查（check（））、完成交易（end（））。

（4）Car类是车的类，属性包括车的类型（carType）、车牌号（carNumber）、车的空闲状况（status）、车的良好情况（condition）。

操作包括正在使用（InServiced（））、修改车的空闲状况（update_carstatus（））等。

（5）CommonWorker类是普通员工信息类，包括工资（commissionRate）等属性，操作主要有核算（calculate（））和检查客户请求（checkRequest（））。

（6）SkillWorker类是技术员工类，包括技术含量（skills）、技术水平（qualifications）等属性，主要操作有培训员工（SkillWorker（））。

（7）Customer类是顾客类，主要包括车的类型（CarType），身份证

（licenseNo）等属性

（8）RequestOrder类是请求表类，主要包括请求的车类型（CarType）、车号（Carnumber）、借用的日期（RentDate）、允许情况（IsAllow）等属性，主要操作包括允许（Allow（））、填写表格（fillOrder（））、核查（check（））、正在处理（isHandled）等.

（9）ServiceRecord类是维修登记表类，主要包括维修历史记录（serviceHistory）和进展报告（progressReport）等属性，主要操作包括填写记录（fillRecord（））等。

3．8系统的配置与实现

系统的配置与实现离不开构件图，而构件图小涉及到构件、关系和接口。

通过分析可知：

整个系统分为五大构件：

●RendApplication

●EmployeeRecord”“CarRecord

●WorkRecord

●ServiceRecord

其中根据需要可知：

“RendApplication”是要被“EmployeeRecord”、“WorkRecord”所引用。

“CarRecord”是要被“RendApplication”、“ServiceRecord”、“WorkRecord”所引用。

具体配置图如下所示：

3．9系统的配置图

系统的配置图必不可少的是部署图，而部署图最为核心的元素是“节点”。

节点主要分为五大类：

●DatabaseApplication（数据操作系统）

●ApplicationServer（运行服务器）

●CommonWorker（普通接员工）

●ManagerInterface（经理接口）

●SkillWorker（技术员工）

它们之间的关系分别是：

SkillWorker（技术员工）、ManagerInterface（经理接口）、CommonWorker（普通接员工）分别与ApplicationServer（运行服务器）关联，也就是说：

这三个类都要与服务器来工作。

ApplicationServer（运行服务器）与DatabaseApplication（数据操作系统）相连，进行相关数据通信和数据记录等等操作。

具体关联关系如下图所示：

4课程设计小结

1、在进行课程的需求分析与设计前，必须结合汽车租赁经营的实际运作情况，在全面考虑现实的需要和日后的发展的前提下，才能够建设出一个覆盖汽车租赁经营全部业务的“汽车租赁系统”；

才能通过该系统来提高企业信息化水平，完善经营管理体系，提高员工素质，进一步加强企业市场竞争能力。

2、在进行课程设计时，面向对象的系统分析要从系统需求出发，首先要识别出活动者，然后对系统事件进行列表，再从事件表中识别用例，并描述一个完整的功能，并一定要验证用例的正确性，一致性，完备性，可行性。

3、在本个课程设计中，设计实体类模型，最困难的工作是识别类，我们是铭记“名词动词法”，不仅找出类，还找出了其属性和方法。

4、顺序图和协作图，让我明白了如何完整地捕获出类的行为、责任以及它们之间的交互，而这些正是系统运行的机制。

在整个课程设计中，交互模型在系统分析和设计阶段重要性极大，两种交互图也是可以相互转换的！

5、在做好用例图、类图、交互图后，状态图和活动图就容易多了，但也要全面了解和掌握好状态图和活动图的使用方法和功能后才能更好的为系统所用。

一些触发机制、转换条件等细节并没有全部描述，但大体方向还是相当明确的！

6、在整个系统中，利用构件图可以对类模型进行有效的融合，让我明白了哪些是可执行的构件块组成，从而从类的森林里投身出来

7、要很好了解部署图的作用，必须先对系统的拓扑结构有很好的掌握！

要明白节点是如何进行相互关联和工作！

~

8、经过这次课程设计让我收获了很大，也从中发现了自己的不足之处，希望在以后的学习中更深点了解理论知识，并用深厚的理论指导自己实践！

欢迎您的下载，

资料仅供参考！

致力为企业和个人提供合同协议，策划案计划书，学习资料等等

打造全网一站式需求