UML课程设计报告报告--汽车-租赁系统需求分析设计讨论报告_第1页
UML课程设计报告报告--汽车-租赁系统需求分析设计讨论报告_第2页
UML课程设计报告报告--汽车-租赁系统需求分析设计讨论报告_第3页
UML课程设计报告报告--汽车-租赁系统需求分析设计讨论报告_第4页
UML课程设计报告报告--汽车-租赁系统需求分析设计讨论报告_第5页
已阅读5页,还剩15页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、-PAGE . z.汽车租赁系统的需求分析与设计目的UML统模课程是一门面向对象开发方法的设计语言。UML统模课程设计实验课,着重加强面向对象建模技术。使用UML统模语言,用需求模型简化业务领域;用分析模型验证用例的正确性,一致性,完备性,可行性;用设计模型标识解决方案。通过模型实现了从业务领域到软件领域的映射。通过建模,使问题可视化,形式化。通过一序列的建模和迭代活动,对于提高学生综合素质十分必要。UML统模课程是本科类计算机专业的一门骨干课程,技术复杂,应用围广。本课程设计实验主要容:构建系统的分析模型、设计模型。本次课程设计的主要目标如下:1. 掌握面向对象的分析技术、设计技术;2. 构

2、建汽车租赁系统”的需求分析模型和设计模型;描述和要求汽车租赁系统的需求分析与设计”是基于现实需要,综合全面考虑,用UML统模语言,简化业务领域,验证用例的正确性,一致性,完备性,可行性等方法来实现的!21 系统目标系统的整体目标是:利用互联网和信息化技术,结合汽车租赁经营的实际运作情况,建设一个覆盖汽车租赁经营全部业务的汽车租赁系统”,通过该系统提高企业信息化水平,完善经营管理体系,提高员工素质,进一步加强企业市场竞争能力。22 功能要求汽车租赁系统”中的功能需求可以包括以下几个方面:客户可以通过不同的方式(包括、前台、网上)预订车辆;能够保存客户的预订申请单;能够保存客户的历史记录;工作人员

3、可以处理客户申请;技术人员可以保存对车辆检修的结果。满足上述需求的系统主要包括以下几个模块:基本数据维护模块:该模块提供了使用者录入、修改并维护基本数据的途径。基本业务模块:在系统中,客户可以填写汽车租赁申请表,工作人员处理这些 表格;同时,技术人员还可以提交每辆车的状态,以便工作人员根据这些资料决定是否批准客户的请求。数据库管理模块:在系统中,对所有客户、工作人员以及车辆的信息都要进行统一管理,车辆的租赁情况也要进行详细的登记。信息查询模块:该模块主要用于查询相关信息。课程设计报告容 各系统的功能模块详细容及主要功能模块 基本数据维护模块包括的主要功能模块:添加车辆信息修改车辆信息添加员工信

4、息修改员工数据 基本业务模块包含的主要功能模块:用户填写预定申请工作人员处理预定请求技术人员填写服务记录工作人员处理还车数据库模块的主要功能模块:客户信息管理车辆信息管理租赁信息管理职员信息管理 信息查询模块的主要功能模块:查询客户信息查询职员信息查询车辆信息查询客户记录下图为该汽车租赁系统的主要功能模块图:汽车租凭系统基本数据维护模块基本业务模块数据库模块信息查询模块用户填写预定申请添加车辆信息修改车辆信 息添加员工信 息修改员工数 据工作人员处理预定请求技术人员填写服务记录工作人员处理还车客户信息管理车辆信息管理租凭信息管理职员信息管理查询客户信息查询职员信息查询车辆信息查询客户记录系统主

5、要参与者经过系统分析和实际需求,汽车租赁系统中的参与者主要有以下两类:eq oac(,1)客户eq oac(,2)公司职员系统的用例图客户参与的用例图客户在整个活动主要进行预定车辆(reserve the car )”、取得车辆(get the car)”、归还车辆(return the car)”这三种行为。其中预定车辆可以通过不同的方式来进行,主要归为联系(by call)”、网上预定(on the web)”两种形式。如果车辆发生意外,客户在归还车辆时,还需要进行相关罚款,所以罚款(return with fine)”作为归还车辆(return)”的一个扩展用例。如果采取进行网上预定”的

6、形式,则需要在网上进行相关表格填写!所以fill the order form(填写指定表格)”是网上预定(on the web)的一个扩展例。因此整个用例模型图如下所示: 公司职员参与的用例图相对客户行为而言,公司员工所要进行的行为就比较多,可以分为以下几类: system login(系统登陆)reserve(处理客户预定信息)give the car to customer(取车给客户)end the bussiness(结束交易).reserve(处理客户预定信息)可以通过use方法来进行Querry customer order record ”、refuse request”、ac

7、cept request”进行相关操作。因此整个用例模型图如下所示:34 系统的顺序图系统的顺序图主要从以下几方面进行描述的:管理人员开展工作的顺序图 客户预订车辆的顺序图客户取车的顺序图 客户还车的顺序图管理人员开展工作的顺序图 管理人员需要进行相关工作记录的审核工作和跟员工交流沟通,并没有直接跟客户有直接关系,因此管理人员开展工作的顺序图主要涉及到这三个类:ManagersRentRecordsEmployees注:因为Employees(员工)不只一人,所以他们之间会有相互了解、影响和合作,所以不能忘记了他们之间的部活动。员工与经理之间也是一个互动过程。具体顺序图如下所示:【顺序图说明】

8、checkRecord():查看记录checkWorkInfo():查看工作信息calculate():核算return result():返回结果客户预订车辆的顺序图客户申请车辆时,要进行个人息的填写等、通过相关合法检测后,才能够成功预定到车辆。具体类有以下五个:Customers(顾客)Requests(请求表)mmonWorkers(普通员工)CustomerRecord(顾客记录表)Cars(车辆)具体流程:顾客需要在请求表中填写信息,再由普通工作人员审核,普通工作人员在以往顾客表中审核相关信息,看是否顾客有损坏车辆的不好记录,若无不良状况,检查车辆状态,如果有合适的话,进行顾客租车的

9、信息记录,并在请求中填写允许”,并把这个请求结果通知顾客!具体顺序图如下所示:【顺序图说明】(1)fillOrder():填写要求(2)checkRequest():查看客户请求(3)check():查看(4)no problem():没有问题(5)Inserviced():是否可使用(6)ok():可以(7)creat new customer recored():进行客户信息的新记录(8)Allow():允许(9)isHandled():处理并发送(10)notify():通知客户取车的顺序图客户取车的顺序图包括以下几个类:Customers(顾客)Requests(请求表)mmonWor

10、kers(普通员工)WorkRecord(工作记录表)Cars(车辆)只要认真分析,不难理解客户取车过程,要注意取车的同时要付款。具体顺序图如下所示:【顺序图说明】(1)show notice():提供身份(2)check ():核查(3)ok():没有问题(4)pay():付款(5)fillWorkRecord():填写员工自己的工作记录(6)update_carstatus():把车的状况进行转换 客户还车的顺序图这个顺序图将跟上面的对象有些不同,基于实际需要,主要还涉及:进行汽车检查的技术工作人员(SkillWorkers)、汽车状况登记表(ServiceRecords)、租用登记表(R

11、entRecords)等类!具体涉及类:Customers(顾客)SkillWorkers(技术工作人员)mmonWorkers(普通员工)CustomerRecord(顾客登记表)Cars(车辆)RentRecords (租用登记表)ServiceRecords(服务登记表)具体流程:顾客把车返还给普通员工,普通员工把车交给技术员工,技术员工进程车辆状态检查,并填写相关车辆状态情况,作好记录后在交给普通员工,若车辆出现问题,普通员工会通知顾客进行相关赔偿;顾客财产保险后,普通员工进行车辆保修情况进行记录,并登记顾客把车返还等相关信息,并更新相关租用信息,使得这辆车能够投入下一轮回的使用!具体

12、顺序图如下所示: 【顺序图说明】(1)returnback():还车(2)check_carstatus ():检查车的情况(3)fillRecord():填写车的相关情况表(4)return():返回车情况表(5)notify_payment():通知付款(6)pay():付款(7)update_carstatus():进行车辆信息的转换(空闲、不空闲、维修)(8)end():取消客户记录(9)updateRecord():更新当前工作记录35 系统的协作图系统的协作图按流程和时间段主要分为三部分: 客户预订的协作图客户取车的协作图客户还车的协作图客户预订的协作图,如下所示:跟上面的客户预订

13、的顺序图有相似之处,并可以相互转换。 客户取车的协作图,如下所示: 跟上面的客户取车的顺序图有相似之处,并可以相互转换。客户还车的协作图,如下所示: 跟上面的客户还车的顺序图有相似之处,并可以相互转换。系统的状态图系统的状态图主要思路:客户发送请求工作人员处理请求工作人员审核客户的相关资料,基于资料是否真实,当审核通过后,接受客户的请求记录并保存相关信息客户取车客户还车技术人员进行车辆检查成功交易结束;当审核未通过后,工作人员不接受客户请求停止这场交易结束。具体状态图所下所示:系统的活动图尽管活动图与状态图、交互图有类似之处,工作人员和客户的行为表示也差不多,但亦有不同之处,活动图是可以把不同

14、对象同时进行相关事情操作的,可以进行分支描述!根据现实的需要和综合考虑,可以把活动图分成以下客户”工作人员”这两个分支来进行描述的!主要思路:一方面,顾客进行车辆租用申请表填写,并发送保存;另一方面,员工定时进行请求查看,当有新的请求时,员工会先查看顾客以往记录,如果顾客以往记录良好,又有车辆空闲的话,会向顾客发送接受请求的信息,顾客去取得车辆,使用后并归还!如果当员工并没有及时向顾客发送接受请求的信息,会终止交易!当车辆已全部投入使用,并没有空闲的车辆,也会终止交易!如果顾客的以往记录很差,员工拒绝租车给顾客,不再进行交易!具体活动图如下所示:38 系统中的类 1、系统中主要的类,可分为以下

15、两类:客户和公司职员类一些其他的类客户和公司职员类经过全面分析和考察,可以找到系统中以下几个类:Customer(顾客)Manager(经理)SkillWorker(技术工作人员)monWork(普通工作人员)其中它们之间的关系可以融合成:Manager(经理)、SkillWorker(技术工作人员)、monWork(普通工作人员)可以归为Employee(员工).Employee(员工)和Customer(顾客)是Person(人)的泛化.上述类,具体关系如下所示:一些其他的类系统中还会涉及一些其他类,这些类不可忽视,经分析,有以下几个类:CustomerRecord(客户记录)Car(车)

16、serviceRecord(维修记录)RequestOrder(请求登记表)WorkRecord(工作记录表) 具体类图的属性和方法如下所示:各个类之间的关系上面列举的是这个系统进行交互的类图,这些类图彼此之间是联系着的,缺少了一个都会不完整,都不利于工作的开展!具体分析:每个经理可以有多工作记录表(一对多的关系)每个普通员工可以有多工作记录表(一对多的关系)每个普通员工有相应的多顾客记录表(一对多的关系)每个普通员工可以对多辆车辆进行分配和安排(一对多的关系)一辆车可以有多个技术工人进行维修,一个技术工作也可以对不同的车辆进行维修(多对多的关系)每个技术工人每次只能在记录表进行一次记录(一对

17、一的关系)一个普通员工可以收到不同的车辆保养记录表(一对多的关系)一个普通员工可以同时招待多个顾客(一对多的关系)每个顾客一次只能在一个请求登记表进行登记(一对一的关系)具体图示如下所示:【类图说明】 WorkRecord类是工作记录的类,它的属性很多,包括客户的身份ID(CustomerID)、普通员工身份ID(monWorkID)、技术员工身份ID(SkillWorkID)、借用日期(RentDate)、归还日期(ReturnDate)、车的 类型(CarType)、车牌号(CarNumber)、租金(money)等。其中主要操作有填写工作记录表(fillWorkRecord())、查看工

18、作记录(ViewRecord()和更新修改(updateRecord()等。 Manager类是管理员类,他有boolean(正负级)属性,操作主要是管理和审核工作情况。(3) CustomerRecord类是记录顾客信息的类,包括顾客的身份(customerID)、租车日期(rentDate)、车的类型(carType)、车牌号(carNumber),完成交易(IsFinish)属性等,操作主要有审查(check())、完成交易(end())。(4) Car 类是车的类,属性包括车的类型(carType)、车牌号(carNumber)、车的空闲状况(status)、车的良好情况(condit

19、ion)。操作包括正在使用(InServiced())、修改车的空闲状况(update_carstatus())等。(5) monWorker类是普通员工信息类,包括工资(missionRate)等属性,操作主要有核算(calculate())和检查客户请求(checkRequest())。(6) SkillWorker类是技术员工类,包括技术含量(skills)、技术水平(qualifications)等属性,主要操作有培训员工(SkillWorker())。(7) Customer类是顾客类,主要包括车的类型(CarType),(licenseNo)等属性(8) RequestOrder类

20、是请求表类,主要包括请求的车类型(CarType)、车号(Carnumber)、借用的日期(RentDate)、允许情况(IsAllow)等属性,主要操作包括允许(Allow())、填写表格(fillOrder())、核查(check())、正在处理(isHandled)等.(9) ServiceRecord类是维修登记表类,主要包括维修历史记录(serviceHistory)和进展报告(progress Report)等属性,主要操作包括填写记录(fillRecord())等。系统的配置与实现系统的配置与实现离不开构件图,而构件图小涉及到构件、关系和接口。通过分析可知:整个系统分为五大构件:

21、Rend ApplicationEmployee Record”CarRecordWork RecordService Record其中根据需要可知:Rend Application”是要被Employee Record”、 Work Record”所引用。CarRecord”是要被Rend Application”、 Service Record”、 Work Record”所引用。具体配置图如下所示:系统的配置图系统的配置图必不可少的是部署图,而部署图最为核心的元素是节点”。节点主要分为五大类:Database Application(数据操作系统)Application Server(运行服务器)mon Worker(普通接员工)Manager Interface(经理接口)Skill Worker(技术员工)它们之间的关系分别是:Skill Worker(技术员工)、Manager Interface(经理接口)、 mon Worker(普通接员工)分别与Application Server(运行服务器)关联,也就是说:这三个类都要与服务器来工作。 Application Server(运行服务器)与Databas

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论