UML课程设计汽车租赁系统的需求分析与设计讨论报告.doc

汽车租赁系统需求分析与设计

1． 目
UML统一建模课程是一门面向对象开发措施设计语言。UML统一建模课程设计试验课，着重加强面向对象建模技术。使用UML统一建模语言，用需求模型简化业务领域；用分析模型验证用例对性，一致性，完备性，可行性；用设计模型标识处理方案。通过模型实现了从业务领域到软件领域映射。通过建模，使问题可视化，形式化。通过一序列建模和迭代活动，对于提高学生综合素质十分必要。
UML统一建模课程是本科类计算机专业一门骨干课程，技术复杂，应用范围广。本课程设计试验重要内容：构建系统分析模型、设计模型。本次课程设计重要目如下：
1. 掌握面向对象分析技术、设计技术；
2. 构建“汽车租赁系统”需求分析模型和设计模型；
2． 描述和规定
“汽车租赁系统需求分析与设计”是基于现实需要，综合全面考虑，用UML统一建模语言，简化业务领域，验证用例对性，一致性，完备性，可行性等措施来实现！
2．1 系统目
系统整体目是：运用互联网和信息化技术，结合汽车租赁经营实际运作状况，建设一种覆盖汽车租赁经营所有业务“汽车租赁系统”，通过该系统提高企业信息化水平，完善经营管理体系，提高员工素质，深入加强企业市场竞争能力。
2．2 功能规定
“汽车租赁系统”中功能需求可以包括如下几种方面：
Ø 客户可以通过不一样方式（包括电话、前台、网上）预订车辆；
Ø 可以保留客户预订申请单；
Ø 可以保留客户历史记录；
Ø 工作人员可以处理客户申请；
Ø 技术人员可以保留对车辆检修成果。
满足上述需求系统重要包括如下几种模块：
Ø 基本数据维护模块：该模块提供了使用者录入、修改并维护基本数据途径。
Ø 基本业务模块：在系统中，客户可以填写汽车租赁申请表，工作人员处理这些 表格；同步，技术人员还可以提交每辆车状态，以便工作人员根据这些资料决定与否同意客户祈求。
Ø 数据库管理模块：在系统中，对所有客户、工作人员以及车辆信息都要进行统一管理，车辆租赁状况也要进行详细登记。
Ø 信息查询模块：该模块重要用于查询有关信息。
3． 课程设计汇报内容
3．1 各系统功能模块详细内容及重要功能模块
基本数据维护模块包括重要功能模块：
Ø 添加车辆信息
Ø 修改车辆信息
Ø 添加员工信息
Ø 修改员工数据
基本业务模块包括重要功能模块：
Ø 顾客填写预定申请
Ø 工作人员处理预定祈求
Ø 技术人员填写服务记录
Ø 工作人员处理还车
数据库模块重要功能模块：
Ø 客户信息管理
Ø 车辆信息管理
Ø 租赁信息管理
Ø 职工信息管理
信息查询模块重要功能模块：
Ø 查询客户信息
Ø 查询职工信息
Ø 查询车辆信息
Ø 查询客户记录
下图为该汽车租赁系统重要功能模块图：
汽车租凭系统

基本数据维护
模块

基本业务模块

数据库模块

信息查询
模块

顾客填写预定申请

添加车辆
信息

修改车辆信 息

添加员工信 息

修改员工数 据

工作人员处理预定祈求

技术人员填写服务记录

工作人员处理还车

客户信息管理

车辆信息管理

租凭信息管理

职工信息管理

查询客户信息

查询职工信息

查询车辆信息

查询客户记录

3．2 系统重要参与者
通过系统分析和实际需求，汽车租赁系统中参与者重要有如下两类：
客户
企业职工
3．3 系统用例图
1、 客户参与用例图
客户在整个活动重要进行“预定车辆（reserve the car ）”、“获得车辆(get the car)”、“偿还车辆(return the car)”这三种行为。其中预定车辆可以通过不一样方式来进行，重要归为“电话联络（by call）”、“网上预定(on the web)”两种形式。
假如车辆发生意外，客户在偿还车辆时，还需要进行有关罚款，因此“罚款(return with fine)”作为“偿还车辆(return)”一种扩展用例。
假如采用进行“网上预定”形式，则需要在网上进行有关表格填写！因此“fill the order form（填写指定表格）”是“网上预定(on the web)一种扩展例。
因此整个用例模型图如下所示：

2、 企业职工参与用例图
相对客户行为而言，企业员工所要进行行为就比较多，可以分为如下几类：
Ø system login（系统登陆）
Ø reserve（处理客户预定信息）
Ø give the car to customer（取车给客户）
Ø end the bussiness（结束交易）.
reserve（处理客户预定信息）可以通过〈〈use〉〉措施来进行“Querry customer order record ”、“refuse request”、“accept request”进行有关操作。
因此整个用例模型图如下所示：

3．4 系统次序图
系统次序图重要从如下几方面进行描述：
• 管理人员开展工作次序图
• 客户预订车辆次序图
• 客户取车次序图
• 客户还车次序图
1、 管理人员开展工作次序图
管理人员需要进行有关工作记录审核工作和跟员工交流沟通，并没有直接跟客户有直接关系，因此管理人员开展工作次序图重要波及到这三个类：
l Managers
l RentRecords
l Employees
注：由于Employees（员工）不只一人，因此他们之间会有互相理解、影响和合作，因此不能忘掉了他们之间内部活动。员工与经理之间也是一种互动过程。
详细次序图如下所示：

【次序图阐明】
（1） checkRecord():查看记录
（2） checkWorkInfo():查看工作信息
（3） calculate():核算
（4） return result():返回成果

2、 客户预订车辆次序图
客户申请车辆时，要进行个人息填写等、通过有关合法检测后，才可以成功预定到车辆。
详细类有如下五个：
l Customers（顾客）
l Requests（祈求表）
l CommmonWorkers（一般员工）
l CustomerRecord(顾客登记表)
l Cars（车辆）
详细流程：顾客需要在祈求表中填写信息，再由一般工作人员审核，一般工作人员在以往顾客表中审核有关信息，看与否顾客有损坏车辆不好记录，若无不良状况，检查车辆状态，假如有合适话，进行顾客租车信息记录，并在祈求中填写“容许”，并把这个祈求成果告知顾客！
详细次序图如下所示：

【次序图阐明】
（1）fillOrder():填写规定
（2）checkRequest():查看客户祈求
（3）check():查看
（4）no problem():没有问题
（5）Inserviced():与否可使用
（6）ok():可以
（7）creat new customer recored():进行客户信息新记录
（8）Allow():容许
（9）isHandled():处理并发送
（10）notify():告知

3、 客户取车次序图
客户取车次序图包括如下几种类：
l Customers（顾客）
l Requests（祈求表）
l CommmonWorkers（一般员工）
l WorkRecord(工作登记表)
l Cars（车辆）
只要认真分析，不难理解客户取车过程,要注意取车同步要付款。
详细次序图如下所示：

【次序图阐明】
（1）show notice():提供身份
（2）check ():核查
（3）ok():没有问题
（4）pay():付款
（5）fillWorkRecord():填写员工自己工作记录
（6）update_carstatus():把车状况进行转换
4、 客户还车次序图
这个次序图将跟上面对象有些不一样，基于实际需要，重要还波及：进行汽车检查技术工作人员（SkillWorkers）、汽车状况登记表(ServiceRecords)、租用登记表(RentRecords)等类！
详细波及类：
l Customers（顾客）
l SkillWorkers（技术工作人员）
l CommmonWorkers（一般员工）
l CustomerRecord(顾客登记表)
l Cars（车辆）
l RentRecords (租用登记表)
l 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、系统中重要类，可分为如下两类：
l 客户和企业职工类
l 某些其他类
Ø 客户和企业职工类
通过全面分析和考察，可以找到系统中如下几种类：
l Customer(顾客)
l Manager(经理)
l SkillWorker(技术工作人员)
l CommonWork(一般工作人员)
其中它们之间关系可以融合成：
l Manager(经理)、SkillWorker(技术工作人员)、CommonWork(一般工作人员)可以归为Employee（员工）.
Employee（员工）和l Customer(顾客)是Person（人）泛化.
上述类，详细关系如下所示：

Ø 某些其他类
系统中还会波及某些其他类，这些类不可忽视，经分析，有如下几种类：
l CustomerRecord(客户记录)
l Car(车)
l serviceRecord(维修记录)
l RequestOrder(祈求登记表)
l WorkRecord(工作登记表)
详细类图属性和措施如下所示：

Ø 各个类之间关系
上面列举是这个系统进行交互类图，这些类图彼此之间是联络着，缺乏了一种都会不完整，都不利于工作开展！
详细分析：
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）和进展汇报（progress Report）等属性，重要操作包括填写记录（fillRecord()）等。

3．8 系统配置与实现
系统配置与实现离不开构件图，而构件图小波及到构件、关系和接口。通过度析可知：整个系统分为五大构件：
l Rend Application
l Employee Record”“CarRecord
l Work Record
l Service Record
其中根据需要可知：
“Rend Application”是要被“Employee Record”、 “Work Record”所引用。
“CarRecord”是要被“Rend Application”、 “Service Record”、 “Work Record”所引用。
详细配置图如下所示：

3．9 系统配置图
系统配置图必不可少是布署图，而布署图最为关键元素是“节点”。节点重要分为五大类：
l Database Application（数据操作系统）
l Application Server（运行服务器）
l Common Worker（一般接员工）
l Manager Interface（经理接口）
l Skill Worker（技术员工）
它们之间关系分别是：
Skill Worker（技术员工）、Manager Interface（经理接口）、l Common Worker（一般接员工）分别与Application Server（运行服务器）关联，也就是说：这三个类都要与服务器来工作。
Application Server（运行服务器）与l Database Application（数据操作系统）相连，进行有关数据通信和数据记录等等操作。
详细关联关系如下图所示：

4 课程设计小结
1、在进行课程需求分析与设计前，必须结合汽车租赁经营实际运作状况，在全面考虑现实需要和后来发展前提下，才可以建设出一种覆盖汽车租赁经营所有业务“汽车租赁系统”；才能通过该系统来提高企业信息化水平，完善经营管理体系，提高员工素质，深入加强企业市场竞争能力。
2、在进行课程设计时，面向对象系统分析要从系统需求出发，首先要识别出活动者，然后对系统事件进行列表，再从事件表中识别用例，并描述一种完整功能，并一定要验证用例对性，一致性，完备性，可行性。
3、在本个课程设计中，设计实体类模型，最困难工作是识别类，我们是铭记“名词动词法”，不仅找出类，还找出了其属性和措施。
4、次序图和协作图，让我明白了怎样完整地捕捉出类行为、责任以及它们之间交互，而这些正是系统运行机制。在整个课程设计中，交互模型在系统分析和设计阶段重要性极大，两种交互图也是可以互相转换！
5、在做好用例图、类图、交互图后，状态图和活动图就轻易多了，但也要全面理解和掌握好状态图和活动图使用措施和功能后才能更好为系统所用。某些触发机制、转换条件等细节并没有所有描述，但大体方向还是相称明确！
6、在整个系统中，运用构件图可以对类模型进行有效融合，让我明白了哪些是可执行构件块构成，从而从类森林里投身出来
7、要很好理解布署图作用，必须先对系统拓扑构造有很好掌握！要明白节点是怎样进行互相关联和工作！~
8、通过这次课程设计让我收获了很大，也从中发现了自己局限性之处，但愿在后来学习中更深点理解理论知识，并用深厚理论指导自己实践！