一、实验目的及要求
对汽车租赁系统进行分析，利用 UML 工具进行建模。
二、实验环境
微型计算机、Rational Rose
三、实验内容

  1. 对汽车租赁系统进行需求分析，并确定其基本模块，如基本数据维护模块、基本业务
    模块、数据库模块、信息查询模块。
  2. 确定系统中的类，并生成类图和各个类之间的关系。
  3. 确定 UML 模型框架，并作出以下各图：
    （1）系统的用例图
    （2）系统的时序图
    （3）系统的协作图
    （4）系统的活动图
    四、实验步骤
    1．分析系统，写出系统的功能需求分析描述。
    （1）基本数据维护模块应包括：
    添加车辆信息；修改车辆信息；添加员工信息；修改员工信息等。
    （2）基本业务模块应包括：
    用户填写预定申请；工作人员处理预定请求；技术人员填写服务纪录；工作人员处理还
    车请求；
    （3）数据库模块应包括：
    客户信息管理；车辆信息管理；租赁信息管理；员工信息管理；
    （4）信息查询模块应包括：
    查询客户信息；查询员工信息；查询车辆信息；查询客户租车记录等；
  4. 建立 UML 模型
    包括用例图、类图、时序图、活动图、协作图、状态图的构建。

具体分析：

1.需求分析部分：

1.系统的功能需求分析

（1）基本数据维护模块应包括：

添加车辆信息；修改车辆信息；添加员工信息；修改员工信息等。

（2）基本业务模块应包括：用户填写预定申请；工作人员处理预定请求；技术人员填写服务纪录；工作人员处理还车请求；
（3）数据库模块应包括：客户信息管理；车辆信息管理；租赁信息管理；员工信息管理；

（4）信息查询模块应包括：查询客户信息；查询员工信息；查询车辆信息；查询客户租车记录等；

2.基本数据维护模块

基本数据维护模块是汽车租赁系统中的基础功能模块，主要用于管理与系统运行相关的基础数据，包括车辆信息与员工信息的添加、修改等操作。该模块的良好设计有助于保持数据一致性和系统稳定性，为后续业务操作提供数据支持。

（1）添加汽车信息：汽车租聘处的车辆信息全部保存在数据库中，确保后续租赁、维护、查询等操作能准确定位目标车辆。
应包括以下字段：

  • 车辆编号（唯一标识）
  • 品牌型号（如：丰田凯美瑞）
  • 车牌号码
  • 颜色
  • 类型（轿车/越野车/商务车等）
  • 日租金
  • 当前状态（空闲/租赁中/维护中）

功能需求：

  • 信息提交后，应自动存入车辆信息表中。
  • 系统管理员登录后可通过图形界面填写车辆信息。
  • 系统应对车辆编号、车牌号进行唯一性校验。

（2）修改车辆信息：由于车辆信息可能发生变更（如状态变更、日租金调整等），系统应支持对已有车辆信息的修改。

功能需求：

  • 系统提供按车牌号或车辆编号的查询功能。
  • 支持对车辆状态、日租金等字段的修改。

（3）添加员工信息：为支持系统操作、客户服务等功能，所有员工的信息需录入系统。

应包括以下字段：

  • 员工编号（唯一标识）
  • 姓名
  • 岗位（如：管理员、技术人员、客服人员）
  • 联系电话
  • 入职日期

功能需求：

  • 信息验证后保存至员工信息表中。
  • 由管理员添加员工信息。
  • 员工编号自动生成或手动录入，确保唯一性。

（4）修改员工信息

为应对员工岗位调整、联系方式变更等情况，系统应支持员工信息的维护与更新。

功能需求：

  • 修改记录应自动存档以备追踪。
  • 支持通过员工编号查询目标员工。
  • 可修改姓名、联系方式、岗位等内容。

3.基本业务模块

基本业务模块是汽车租赁系统中最核心的功能板块，涉及用户与系统之间的交互行为，覆盖租赁全过程的操作，包括预定、车辆服务、还车等环节。

（1）用户填写预定申请：

用户在系统中发起租车请求，填写所需租赁的车辆类型、起止时间等信息，系统将记录并等待工作人员处理。

功能需求：

  • 预定信息可由用户随时查看和取消（在审核前）。
  • 用户登录后可进入“车辆预定”界面；
  • 填写预定表单内容：租车人信息、租赁时间段、所需车型、用途说明等；
  • 系统自动检索对应时间段内可租车辆；
  • 提交成功后，系统自动生成预定记录，状态为“待处理”；

（2）工作人员处理预定请求：

工作人员负责审核用户预定请求，确认车辆状态，并将状态变更为“已预定”或“拒绝”。

功能需求：

  • 审核通过的预定会锁定对应车辆的时间段状态。
  • 工作人员登录后可查看所有“待处理”的预定申请；
  • 支持按日期、用户、车辆类型等条件筛选；
  • 可进行“通过”或“拒绝”操作，并添加处理备注；
  • 处理完成后，系统将通知用户审核结果；

（3）技术人员填写服务记录：

技术人员在车辆使用前/后进行检查，填写车辆维护与检测记录，保障车辆安全与状态信息准确。

功能需求：

  • 登录系统后，可查询并选择需要维护记录的车辆；
  • 填写内容包括：检查日期、检查人、车辆状况、建议维修、是否可租等；
  • 提交后，系统更新车辆状态（可租/需维护）；
  • 服务记录保存至车辆服务历史中。

（4）工作人员处理还车请求：

租赁期结束，用户归还车辆，工作人员需核对车辆状况，并更新车辆使用信息及租赁记录。（根据租赁时间和车辆使用状态收取租赁费，如果车辆有损坏收取一定的罚金）

功能需求：

  • 归还信息同步到租赁历史记录中。
  • 系统提供“还车处理”界面；
  • 工作人员输入车辆编号或租赁单号查询；
  • 核对车辆归还时间、油量、车况、违章等情况；
  • 计算最终租赁费用（按日租金×天数+其他费用）；
  • 如若车辆无误系统自动将租赁记录归档，车辆状态更新为“空闲”；
  • 如若车辆有损坏，收取一定的罚金，将车辆送往维修厂，车辆状态更新为“维护中”

4.数据库模块

数据库模块是整个汽车租赁系统的数据核心，负责系统中各类信息的存储、管理和调用。通过科学的数据结构设计与数据表管理，确保系统高效、稳定、安全运行，为业务模块提供支撑。

（1）客户信息管理：

用于存储和管理客户的基本资料，是租赁流程中用户识别与信用追踪的重要依据。

主要字段包括：

  • 客户编号（唯一标识）
  • 姓名
  • 性别
  • 身份证号/驾照号
  • 联系方式
  • 注册日期
  • 租赁历史记录
  • 备注（如违章记录、黑名单等）

功能需求：

  • 支持添加、查询、修改客户信息；
  • 客户信息在注册或首次租赁时录入；
  • 系统可根据客户编号或证件号进行唯一性校验；
  • 敏感信息应加密存储，保障数据安全。

（2）车辆信息管理：

用于维护系统中所有车辆的详细资料，是支撑预定、还车、查询、服务等模块的关键数据来源。

主要字段包括：

  • 车辆编号
  • 品牌型号
  • 车牌号码
  • 类型
  • 当前状态（空闲/租赁中/维护中）
  • 日租金

功能需求：

  • 所有车辆在录入系统时自动生成记录；
  • 状态字段根据业务流程动态更新；
  • 支持按车型、状态、编号等条件查询；
  • 可对车辆信息进行更新（如租金调整、状态更改）。

（3）租赁信息管理：

用于记录每一次租赁交易的完整数据，包括客户、车辆、时间段、费用等，是统计、报表、追责等功能的依据。

主要字段包括：

  • 租赁编号（唯一标识）
  • 客户编号
  • 车辆编号
  • 起租时间
  • 归还时间
  • 实际归还时间
  • 总费用
  • 租赁状态（已完成/未还车/逾期等）
  • 违章或损坏记录（如有）

功能需求：

  • 每次成功预定后生成租赁记录；
  • 记录车辆的实际归还情况与费用；
  • 可按客户、车辆、时间段等查询历史租赁记录；
  • 重要字段不允许擅自修改，保障数据一致性。

（4）员工信息管理：

用于维护系统中所有工作人员的数据，分为不同岗位权限，为后台管理操作和分工协作提供依据。

主要字段包括：

  • 员工编号
  • 姓名
  • 联系电话
  • 岗位（管理员/客服/技术人员等）
  • 登录账号
  • 密码（加密存储）
  • 入职时间

功能需求：

  • 管理员具备添加、修改员工信息权限；
  • 系统登录需根据员工账号进行权限验证；
  • 支持岗位权限管理，不同岗位访问系统不同模块；
  • 可按员工编号、姓名等条件检索。

5.信息查询模块

信息查询模块为用户与工作人员提供高效、便捷的数据检索服务，支持对客户、员工、车辆及租赁记录等信息的多维度查询，确保系统数据的可访问性和透明度。本模块是系统操作过程中的重要辅助功能。

（1）查询客户信息：

工作人员或管理员可根据客户信息进行快速定位与核查。

功能需求：

  • 支持按客户编号、姓名、身份证号/驾照号等条件模糊或精确查询；
  • 展示客户基本信息、联系方式、注册时间、累计租赁次数等；
  • 可查看该客户所有历史租赁记录；
  • 提供黑名单或违章记录的标注提示。

（2）查询员工信息：

管理员用于管理员工的身份、岗位、权限等信息。

功能需求：

  • 可根据员工编号、姓名、岗位进行查询；
  • 展示员工基本资料、联系方式、所属岗位及入职日期；
  • 提供岗位权限信息，判断员工是否具备某项操作权限；
  • 可导出员工信息表作为管理资料。

（3）查询车辆信息：

便于用户选择合适车辆及工作人员掌握车辆运营状态。

功能需求：

  • 支持按车辆编号、品牌型号、车牌号、车辆类型、当前状态等查询条件；
  • 展示车辆的基本信息、当前状态、是否可租、日租金等；
  • 提供车辆历史服务记录及维修记录查看接口；
  • 支持状态筛选（仅查看“空闲”车辆、仅查看“维修中”车辆等）；
  • 可将车辆查询结果导出为表格或打印。

（4）查询客户租车记录：

用于客户服务、信用评估、异常交易追踪等目的。

功能需求：

  • 可按客户编号、姓名进行查询；
  • 展示所有历史租车记录，包括租赁时间段、车辆信息、费用、归还情况；
  • 支持对租赁状态（已完成/逾期/未还）进行筛选；
  • 记录中应包含每次租车的服务情况、是否存在违章或损坏；
  • 可导出租赁记录明细用于对账、备份或追责。

2.用例图设计

1.1 参与者（Actors）

系统中主要的参与者有：

  • 客户（Customer）：使用系统提交预定、查询租车记录等。
  • 工作人员（Staff）：负责审核预定、处理还车等。
  • 技术人员（Technician）：负责填写服务记录，更新车辆状态。
  • 管理员（Admin）：负责系统数据维护，包括添加/修改员工和车辆信息。

1.2 系统主要用例（Use Cases）

将前面分析过的功能模块转化为用例：

（1）基本数据维护

  • 添加车辆信息
  • 修改车辆信息
  • 添加员工信息
  • 修改员工信息

（2）基本业务操作

  • 填写租车预定申请
  • 审核预定请求
  • 填写车辆服务记录
  • 处理还车请求

（3）信息查询

  • 查询客户信息
  • 查询员工信息
  • 查询车辆信息
  • 查询客户租车记录

1.3 参与者与用例之间的关系

参与者 可执行的用例
客户 填写租车预定申请、查询客户租车记录
普通工作人员（客服） 审核预定请求、处理还车请求、查询客户/车辆信息
技术人员 填写车辆服务记录
管理员 添加/修改车辆信息、添加/修改员工信息、查询员工信息

1.4可视化建议（在Rational Rose中建图）：

整体用一个系统边框（System）包住所有用例，命名为“汽车租赁系统”

创建4个Actor，分别命名为：

  • 客户
  • 工作人员
  • 技术人员
  • 管理员

创建12个用例（Use Case）：

每个功能点用椭圆表示，用线连接Actor与他们能够使用的用例

模块 用例（功能）名称 所属角色
数据维护模块 添加车辆信息 管理员
数据维护模块 修改车辆信息 管理员
数据维护模块 添加员工信息 管理员
数据维护模块 修改员工信息 管理员
业务模块 填写租车预定申请 客户
业务模块 审核预定请求 工作人员
业务模块 填写服务记录 技术人员
业务模块 处理还车请求 工作人员
查询模块 查询客户信息 工作人员/管理员
查询模块 查询员工信息 管理员
查询模块 查询车辆信息 工作人员/管理员
查询模块 查询客户租车记录 客户/工作人员

总结：

  • “参与者”是使用系统的人或角色
  • “用例”是系统提供的某项功能或服务
  • 一个参与者可以参与多个用例
  • 一个用例也可以被多个参与者使用（例如查询车辆信息）

3.类图设计

类图说明系统的静态结构：有哪些类（实体），它们有哪些属性（字段）、方法（功能），以及类之间的关系（关联、继承、依赖等）。

系统中的核心类

类名 上层继承/从属关系 关联对象 主要属性字段 主要方法（功能）
Person（抽象类） - - name、ID、address、phoneNo getName()、setName() 等
├─ Customer（客户类） Person Rental（1对多） 编号、证件号、联系方式、租赁历史记录 提交预定申请()、查询租赁记录()
└── Employee（抽象类-员工） Person 无 编号、岗位、电话、账号密码 登录()、操作功能（由子类具体实现）
├── *Admin*（管理员） Employee 无 是否为高级管理员 添加员工()、添加车辆()
├── CommonWorker（一般员工-客服） Employee 无 处理租赁流程 处理预定()、处理还车()
└── SkillWorker（技术人员） Employee ServiceRecord（1对多） 技能项、资格证书、服务记录 填写服务记录()
Vehicle（车辆类） - Rental、ServiceRecord 编号、车牌、品牌、类型、状态、租金、维修记录 更新状态()、计算租金()
Rental（租赁类） - Customer、Vehicle 租赁编号、客户编号、车辆编号、起止日期、费用、状态 创建租赁记录()、计算费用()
ServiceRecord（服务记录类） - Vehicle、SkillWorker 服务编号、车辆编号、技术员编号、检查时间、状况、建议维修 提交服务记录()

思路：分两个类图画，一个客户及公司员工类图，一个汽车租赁系统类图

4.时序图设计

展示“对象间在某个业务过程中的交互顺序”。

时序图（Sequence Diagram）用于展示对象之间在某一用例中的交互过程，关注消息发送顺序。

基本元素包括：

  • 参与对象（Actor 或类的实例）：上方水平排列
  • 生命线（Lifeline）：垂直虚线，表示对象的存活期
  • 消息（Message）：对象之间发送的请求，用箭头标示，按时间从上到下

（1）管理员查看工作记录时序图

该图描述了管理员在系统中查看普通工作人员的工作记录及其任务完成率的流程。该操作用于管理监督和绩效评估。

参与对象：

  • 管理员（Admin）
  • 普通工作人员（CommonWorker）
  • 服务记录（ServiceRecord）

交互顺序：

  1. 管理员可根据任务情况进行评估与记录。
  2. Admin 登录系统并进入“员工管理”功能界面；
  3. 系统展示可查询员工列表；
  4. Admin 选定某位 CommonWorker，调用其方法 查看工作记录()；
  5. CommonWorker 返回其历史 ServiceRecord；
  6. Admin 要求评估任务完成情况，调用 calculate() 方法计算 commissionRate；
  7. CommonWorker 返回任务完成率给 Admin；

（2）客户预订车辆时序图

该图描述了客户通过系统发起租车申请并由工作人员处理的全过程。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 车辆（Vehicle）
  • 租赁记录（Rental）

交互顺序：

  1. Customer 填写并提交租赁申请（调用 提交预定申请() 方法）；
  2. CommonWorker 接收申请并调用 处理预定() ；
  3. CommonWorker 通过 Vehicle 查询所需车型是否可租（调用 更新状态()、查询 当前状态 属性）；
  4. 若车辆空闲，则创建一个新的 Rental 实例；
  5. Rental 记录客户、车辆、起止时间等信息，并由 CommonWorker 完成预定处理；
  6. 返回预定结果给 Customer。

（3）客户取车时序图

该图展示了客户在预定成功后前往门店取车的业务流程。涉及对租赁状态确认、付款、车辆状态更新等关键操作。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 车辆（Vehicle）
  • 租赁记录（Rental）
  • 服务记录（ServiceRecord`）（填写工作记录）

交互顺序：

  1. Customer 按约定时间到店取车；
  2. CommonWorker 校验客户的身份和租赁状态；
  3. 若验证成功，提示 Customer 进行付款；
  4. 付款完成后，CommonWorker 填写 ServiceRecord（调用 填写服务记录() 方法，记录取车信息）；
  5. CommonWorker 调用 Vehicle 类方法 更新状态()，将车辆状态更新为“租赁中”；
  6. Rental 对象状态设置为“进行中”，系统完成租赁激活；
  7. 系统通知客户取车完成。

（4）客户还车时序图

该图展示了客户完成用车后归还车辆的完整流程，包括车辆检查、费用结算、服务记录填写、状态更新等操作。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 技术人员（SkillWorker）
  • 车辆（Vehicle）
  • 租赁记录（Rental）
  • 服务记录（ServiceRecord`）

交互顺序：

  1. Customer 按约定时间归还车辆；
  2. SkillWorker 对 Vehicle 进行检查，确认车况并调用 填写服务记录()；
  3. 若车辆存在损坏，记录在 ServiceRecord 中，并提交维修建议；
  4. CommonWorker 根据 Rental 中的起止时间与车辆状态，计算费用（调用 计算费用() 方法）；
  5. 若有损坏或违章，额外费用一并计算；
  6. Vehicle 状态通过 更新状态() 方法设为“空闲”或“维护中”；
  7. Rental 状态设为“已完成”，交易结束；

5.协作图设计

协作图（Collaboration Diagram）用于描述在某个用例场景中，参与对象之间为了完成任务所进行的交互行为。它重点突出对象之间的结构关系与消息传递顺序。

本系统协作图设计覆盖三个典型场景：

（1）客户预订车辆协作图

该图描述客户发起租车请求并由系统处理的过程，突出“客户—工作人员—车辆—租赁记录”之间的协作关系。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 车辆（Vehicle）
  • 租赁记录（Rental）

协作过程：

  1. Customer 发起租车请求；
  2. CommonWorker 接收并检查请求；
  3. 向 Vehicle 查询当前状态（是否可租）；
  4. 如果可租，生成 Rental 记录并存储租期、费用等信息；
  5. 返回处理结果给 Customer。

（2）客户取车协作图

客户在门店取车，由工作人员完成验证、记录与状态更新。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 车辆（Vehicle）
  • 服务记录（ServiceRecord）
  • 租赁记录（Rental）

协作过程：

  1. Customer 到达前台，出示身份信息；
  2. CommonWorker 校验信息与租赁状态；
  3. 要求付款并调用 ServiceRecord 填写记录；
  4. 修改 Vehicle 的状态为“租赁中”；
  5. 将 Rental 状态设为“进行中”；
  6. 通知 Customer 成功取车。

（3）客户还车协作图

客户完成使用后归还车辆，系统进行检查、结算与状态同步。

参与对象：

  • 客户（Customer）
  • 普通工作人员（CommonWorker）
  • 技术人员（SkillWorker）
  • 车辆（Vehicle）
  • 服务记录（ServiceRecord）
  • 租赁记录（Rental）

协作过程：

  1. Customer 提交还车；
  2. SkillWorker 检查车辆，填写 ServiceRecord；
  3. CommonWorker 根据 Rental 计算费用；
  4. 如有异常（如车辆损坏），加入额外罚金；
  5. 调用 Vehicle 更新状态为“空闲”或“维护中”；
  6. 更新 Rental 为“已完成”，关闭流程；
  7. 通知 Customer 交易结束。

6. 活动图设计

活动图（Activity Diagram）用于表示系统中某个用例或业务流程的控制流程与状态流转，强调操作的执行顺序与并发结构。以下选取三个典型业务流程进行建模。

（1）客户预订车辆活动图

该图描述了客户租车申请从填写表单到系统生成预定记录的全过程。

流程说明：

  • 初始节点：客户登录系统；
  • 填写租车申请表（车型、时间等）；
  • 系统校验字段完整性；
  • 系统检查该时间段内是否有可租车辆；
    • 若无车辆 → 流程结束，提示“预定失败”；
    • 若有车辆 → 进入下一步；
  • 系统生成预定记录；
  • 将预定状态设为“待审核”；
  • 返回“预定提交成功”提示。

（2）客户取车活动图

展示客户前往门店领取车辆的完整操作流程。

流程说明：

  • 初始节点：客户到达门店；
  • 出示身份信息；
  • 工作人员验证预订状态；
    • 若状态异常 → 结束流程，提示“验证失败”；
    • 若验证成功 → 进入下一步；
  • 系统提示付款；
  • 客户付款；
  • 工作人员填写服务记录；
  • 更新车辆状态为“租赁中”；
  • 结束流程，客户完成取车。

（3）客户还车活动图

描述客户用车结束后归还车辆的业务流程。

流程说明：

  • 初始节点：客户提交还车；
  • 技术人员进行车辆检查；
  • 系统记录服务检查结果；
  • 工作人员根据租期与车况计算费用；
  • 客户付款（含额外罚金）；
  • 系统更新车辆状态（空闲/维护中）；
  • 租赁记录设为“已完成”；
  • 流程终止。

7. 状态图设计

状态图（State Diagram）用于描述系统中某一对象在生命周期中所经历的状态变迁，以及引起这些状态变化的事件或条件。它对于理解对象行为及其触发逻辑尤为重要。

本系统重点绘制以下两个状态图：

（1）车辆（Vehicle）状态图

车辆在租赁生命周期中会经历多个状态变化，状态图可清晰展示其状态切换逻辑。

状态节点：

  • 空闲（Idle）
  • 已预定（Reserved）
  • 租赁中（Rented）
  • 检修中（Under Maintenance）

触发事件：

  • 客户提交预定申请 → 状态由“空闲”变为“已预定”
  • 客户取车 → 状态变为“租赁中”
  • 客户还车后车辆正常 → 状态变为“空闲”
  • 客户还车后车辆损坏 → 状态变为“检修中”
  • 检修完毕 → 状态恢复为“空闲”

（2）租赁记录（Rental）状态图

Rental 对象代表一次租赁交易，其状态流转反映交易的执行进度与完成情况。

状态节点：

  • 待审核（Pending）
  • 已批准（Approved）
  • 进行中（Ongoing）
  • 已完成（Completed）
  • 被拒绝（Rejected）

触发事件：

  • 用户提交申请 → 状态设为“待审核”
  • 工作人员审核通过 → 状态变为“已批准”
  • 客户取车后 → 状态设为“进行中”
  • 客户还车并结算完成 → 状态设为“已完成”
  • 审核不通过 → 状态变为“被拒绝”

以下附上实验报告

计本2204 202214024112 王磊下载