【V2.0】「酒店 × 视觉 AI」项目 | UML 分析报告（软件工程概论 - 课程作业四）

【文章说明】

• 《软件工程概论》课程介绍与其他作业 👉《软件工程导论》笔记
• 本作业主要涉及的 UML 图表：
  • 系统用例图（图1）
  • 活动图（表1-6）
  • 类图（原始类图→增加属性后的类图→3.3节）
  • 时序图（3.4节）
  • 状态图（3.5节）
• 绘图工具：Microsoft Visio
• 文章版本：
  • V1.0 2020年6月 Word版本定稿
  • V2.0 2026年2月26日 Markdown 版本公开发布

第一部分 引言

近些年，人脸识别技术日益成熟，在日常生活中的应用也越来越多。为了更好地让其在实际生活中落地，虹软对外发布了开放平台产品，现已被各行各业采用。人们的消费水平在不断提升，在公务出行或旅游时，对酒店的服务升级也越来越期待。本项目的目标，就是将人脸识别与酒店的各项业务深度结合，打造“智慧酒店”，提升服务水平。

第二部分 任务概述

本项目由虹软科技股份有限公司提出并提供指导，由青青草原小组进行外包开发，为中国各大智慧酒店（包括具备基础环境及有智能化意向的酒店）及其住客提供服务，并与酒店的财务系统、点单系统、门禁相联系，与订房系统、支付平台等外部系统相连接，以达到为住客提供便利服务的目的。我们的目标是利用人脸识别技术，把顾客的脸变成“通行证”，实现酒店业务无卡（券）化。对系统的需求陈述见 附1。

团队在结构化的需求分析阶段产生的成果是《需求规格说明书》。接下来，团队将以此为基础，运用面向对象方法进行需求分析，对软件的需求规格说明进行补充，使用UML（Unified Modeling Language, 统一建模语言），建立对象模型、动态模型和功能模型。

为了进行准确的分析，团队仍需要全面调查用户对绿原酒店客户服务系统的需求，根据系统的业务分类、业务操作规程及其数据结构等具体要求，调查单位的组织结构、相关部门的业务范围、业务逻辑结构、业务操作规程。

第三部分 UML分析建模

3.1 系统用例图

• 代表系统的方框的边线表示系统的边界，用于划定系统的功能范围，定义了系统所具有的功能。
• 行为者是指与系统交互的人或其他系统，它代表外部实体。
• 使用用例并且与系统交互的任何人或物都是行为者。
  

3.2 系统用例说明

3.2.1 事务办理

3.2.2 订房处理

3.2.3 自助入住

3.2.4 门禁管理

3.2.5 点单与记账

3.2.6 统一结账

3.3 系统对象模型

3.4 时序图

3.5 状态图

在服务系统中，“终端”“中央计算机”都是主动对象，它们相互发送事件；而“场景”“人脸”“事务”和“房客数据”是被动对象，并不发送事件。“房客”虽然也是动作对象，但是，它是系统外部的因素，无须在系统内实现它们。因此，只需要考虑“终端”“中央计算机”的状态图。

3.5.1 终端类

3.5.2 中央计算机类

附件 建立对象模型的过程

附1 系统需求陈述

• 某酒店拟采用一个住客服务系统，它由中央计算机与各场景终端组成。酒店中有多个终端，分别设在酒店各场景中。
• 在酒店内有住宿消费的群体（即房客，也称住客、客户）是系统的主要用户，他们必须在入住时录入自己的人脸信息，之后凭借自己的脸就可以登录系统。目前仅限于房客刷脸入住、过门禁、退房、使用会员功能，或查看账单，将来还可能要求将系统的用户扩展到酒店的所有顾客，并在各种终端（包括手机、电脑）上处理现场订房、直接点单等事务。
• 房客使用终端处理事务，自行将事务提交、输进终端，终端与中央计算机通信，中央计算机具体处理针对某个房客的事务并维护相关数据。
• 当用户在终端上选择事务类型或终端感应到有人靠近后，终端就与用户交互，以获取有关这次事务的信息，并与中央计算机交换关于事务的信息。首先，终端接收用户选择的事务类型，或根据所处场景自动判断事务类型。接着，终端要求用户注视摄像头（并将身份证放在放在感应区），并把拍摄到的人脸照片（以及从身份证上读到的信息）传给中央计算机，请求中央计算机核对这些信息并处理这次事务。中央计算机验证房客身份，若验证通过，则进入下一步操作。
• 如果房客选择入住，终端显示入住成功的结果与房客的房间号；当房客在门禁旁的终端通过身份验证后，终端向门禁发出放行指令；如果是在支持点单的消费场景，终端跳转到点单系统，房客完成点单后，终端要求房客确认订单，房客可要求终端打印订单；如果房客选择退房，终端判断查房状态，若尚未通过（仍处在预约或查房状态），则要求房客确认或修改退房时间，若已通过，则要求房客选择账单查看方式，房客可要求终端打印账单，并通过移动支付平台进行统一结账。

附2 确定类与对象

• 从需求陈述中可找出以下名词，作为类与对象的初步的候选者：
• 酒店，房客，系统，中央计算机，场景，住宿，消费，用户，人脸信息，门禁，会员，账单，事务，事务类型，摄像头，身份证，感应区，人脸照片，房客身份，结果，房间号，放行指令，点单，消费场景，点单系统，订单，查房状态，退房时间，支付平台。
• 根据领域知识或常识，可进一步写出隐含的类与对象：自助机、门控终端、客房、房务、订房平台、通信链路。

• 剩余的类与对象：酒店，房客，中央计算机，场景，终端，自助机、门控终端。

附3 确定关联

1. 直接提取动词得出的关联
   • 中央计算机与各场景终端组成系统。
   • 酒店拥有多个终端。
   • 终端设在酒店各场景中。
   • 房客在酒店内有住宿消费。
   • 房客入住酒店。
   • 房客使用系统的刷脸过门禁、退房和会员功能。
   • 房客查看账单。
   • 房客输入事务。
   • 终端与中央计算机通信，交换关于事务的信息。
   • 中央计算机具体处理针对房客的事务
   • 中央计算机维护房客相关数据。
   • 终端与用户交互。
   • 中央计算机接收或判断事务类型。
   • 用户注视摄像头。
   • 用户把身份证放在放在感应区。
   • 终端拍摄房客的人脸照片。
   • 终端从身份证中读取信息。
   • 中央计算机核对房客信息。
   • 中央计算机验证房客身份。
   • 终端显示房间号。
   • 终端向门禁发出放行指令。
   • 终端跳转到点单系统。、
   • 终端打印订单。
   • 终端打印账单。
   • 房客通过支付平台结账。
2. 需求陈述中隐含的关联
   • 酒店由各个场景组成。
   • 中央计算机存储房客数据。
   • 酒店拥有中央计算机。
   • 系统提供必要的安全性。
   • 房客拥有人脸信息。
3. 根据问题域知识得出的关联
   • 用户以自己的人脸作为身份验证的凭证。

剩余的关联：

• 终端设在各场景中。→各场景拥有终端。
• 房客输入事务。
• 事务修改房客数据。
• 终端与中央计算机通信。
• 在终端上输入事务。
• 中央计算机具体处理针对房客的事务。
• 中央计算机维护房客相关数据。
• 中央计算机存储房客数据。
• 酒店由各个场景组成。
• 酒店拥有中央计算机。

进一步完善：

1. 正名：剩余关联中有“→”的，“→”之后的名字即为正名结果。

2. 分解

   • “用户以自己的人脸作为身份验证的凭证”应分解为“用户拥有人脸”和“人脸授权事务”。

   • “场景拥有终端”应分解为“场景拥有自助机与门控终端”。

   • “事务修改房客数据”应分解为“刷脸过门禁或其他事务修改房客数据”。

   • “在终端上输入事务”应分解为“在自助机与门控终端上输入事务”。

   • “人脸授权事务”应分解为“人脸授权刷脸过门禁或其他事务”。

3. 补充：暂无。

4. 标明重数。

经过上述分析过程，画出系统的原始类图如下。

附4 确定属性

一、分析

二、选择后剩余的属性（删除标准：误把对象当做属性、误把关联类的属性当作一般对象的属性、把限定误当成属性、误把内部状态当成了属性、过于细化、存在不一致的属性）

筛选后得到的限定：

• “场景代码”是关联“酒店拥有场景”上的限定词。
• “终端号”是关联“场景拥有终端”“中央计算机与终端通信”2个关联上的限定词。

增加属性后的类图如下。

附5 识别继承关系

在增加继承关系后的类图（对象模型）见本文的3.3节（系统对象模型）。