基于UML的酒店视觉AI解决方案软件建模

刘志勇

（南华大学计算机学院，衡阳 420002）

0 引言

随着社会经济的发展，人们的生活水平和观念也日新月异，旅游业得到了迅速发展，酒店越来越多。但是随着人流量日益增多，旧的酒店管理系统已经不再适用。旅客在入住酒店时，需要进行前台登记，然后发房卡，接着在酒店进出房间、各类消费（含健身、保健、餐饮）等都需要进行身份验证，用户体验不太友善。

随着互联网的发展，人们希望利用互联网来改善旧的酒店管理系统，提出“酒店视觉AI解决方案”［1］，即利用人脸识别技术，使得旅客在进行各类消费的时候不再拘束于房卡，直接通过身份验证即可进入健身房等消费场所，打造不一样的酒店服务，提升酒店服务体验，增强酒店的竞争能力。

1 用例建模

1.1 用例图

（1）获取系统参与者过程如表1所示。

表1 获取系统参与者

由上可得出该系统存在四种参与者，如图1所示。

图1 “身份验证系统”参与者视图

（2）从参与者的角度获取用例如表2所示。

表2 从参与者的角度获取用例

（3）由前两步分析可得到身份验证系统的系统用例图如图2所示。

图2 “身份验证系统”用例图

1.2 用例文档

（1）“验证客户身份”用例文档如表3所示（见下页）。

表3 “验证客户身份”用例文档

（2）“识别身份”用例文档如表4所示（见下页）。

表4 “识别身份”用例文档

2 用例分析

2.1 架构分析

2.1.1 备选构架

●架构需求1：由于本系统需要用户与系统进行交互，即所选架构需为一种交互式软件架构模式；

●架构需求2：为了有效地分离用户界面和业务逻辑，分层策略需为三层模式。

综上两点考虑，本系统所选备选架构为BC-E三层架构，如图3所示。当前分层架构将为后续的用例分析提供基本结构和指导规则。

图3 “身份验证系统”备选架构

2.1.2 关键抽象

对于“身份验证系统”而言，其核心业务价值在于客户入住酒店时进行身份验证和客户进入酒店公共服务区时进行身份识别，因此有关客户信息的概念即作为系统的关键抽象而存在，如图4所示。

图4 “身份验证系统”关键抽象类图

而表5列出了关键抽象的简单描述。

表5 “身份验证系统”关键抽象说明

2.2 识别分析类

（1）针对参与者和用例之间的每一个关联关系定义一个边界类，如图5所示。

图5 “身份验证系统”初始边界类

（2）针对一个用例定义一个控制类，如图6所示。

图6 “身份验证系统”初始控制类

（3）按照用例流程识别实体类，从登录用例识别出了用户实体类，从剩余用例识别出了客户信息实体类，如图7所示。

图7 “身份验证系统”初始实体类

3 结语

（1）业务建模与用例建模［2］的联系与区别

联系：用例建模的需求可以从业务建模获取，从业务用例模型中寻找系统改进点结合系统愿景，获取系统用例来表达需求。从业务用例模型中获取系统需求，来构建系统用例模型。

区别：业务模型描述业务现状，这些业务可能存在问题，可将其作为业务待改进的改进点。用例建模正是在原来的业务上加以改进，从业务改进点入手，结合项目愿景，导出系统需求。

业务用例常常是以白盒形式编写，它描述了被建模的组织中的人和部门之间的交互。我们使用业务用例来说明在“现有”业务模型中组织如何工作。然后重构“现有”的业务用例模型，让其面向将要建模的组织的未来设计。

而系统用例往往是以黑盒形式编写，它描述了软件系统之外的参与者如何与将被设计的系统进行交互。系统用例详细阐明了系统需求。系统用例模型的目的是从涉众的角度说明需求，而不是设计如何满足需求。

（2）用例（Use Case）是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。我们通过此次用例建模，更加深刻地理解了在用例建模中如何确定系统的范围和边界，识别参与者、用例，以及用例间的关系。

（3）用例分析是从用例模型到分析模型的过程，是需求与设计之间的桥梁。用例分析把系统的行为分配给分析类，让分析类交互完成系统的行为。我们通过此次用例分析，对架构和用例进行了更深层次的分析，对用例文档进行了完善等，进一步掌握了利用用例分析进行面向对象分析的基本过程和实践技能。