如何针对DHL追踪请求绘制用例图？相关建模疑问咨询

问题1：如何绘制该场景的用例图？提供的用例图是否正确？ #

首先，构建该场景的用例图需明确核心参与者与用例逻辑：

• 参与者：访客、客户、DHL AI、DHL员工（注：访客完成身份验证后转换为客户，二者是同一角色的不同状态）
• 核心用例及关联关系：
  • 访客可执行：查询包裹收发信息、查询联系信息、发起DHL聊天、发送聊天请求（含输入运单编号）
  • 访客完成「身份验证」用例后成为客户，可触发：DHL AI回复聊天请求
  • 当DHL AI无法解答时，触发「转发请求给DHL员工」用例
  • 客户可选执行：电话联系DHL员工

若提供的用例图存在以下任一问题，则判定为不正确：

• 未区分「访客」与「客户」的角色状态转换
• 用例关系错误（例如未体现「身份验证」是客户获取货运信息的前置条件）
• 遗漏核心用例（如「发送聊天请求」「身份验证」）
• 参与者与用例的关联逻辑不符合场景描述

问题2：如何建模“可选通过电话联系DHL员工”这一用例？该用例是否应扩展“转发请求”用例？能否将客户与扩展用例关联？ #

• 建模方式：将「电话联系DHL员工」设为扩展用例，通过<<extend>>关系关联到「转发请求给DHL员工」基础用例。
• 是否扩展“转发请求”用例：是的。该操作是客户在请求被DHL AI转发给员工后，为缩短等待时间选择的可选分支，完全符合UML扩展用例的定义——基础用例执行过程中，可触发扩展用例替代或补充原有流程。
• 能否将客户与扩展用例关联：可以。「电话联系DHL员工」的发起者是客户，直接关联能清晰体现参与者与用例的交互关系，结合<<extend>>关系，可完整表达该操作是「转发请求」流程的可选扩展路径。

问题3：“通过联系DHL聊天”用例是否应包含“发送请求”用例？ #

是的，二者应使用<<include>>包含关系。因为「发送聊天请求（含输入运单编号）」是「通过联系DHL聊天」的核心必要步骤——聊天交互的核心目的就是向DHL AI发送请求，缺少该步骤的聊天用例不具备完整业务意义，符合UML包含用例的定义：基础用例必须调用包含用例才能完成其功能。

内容的提问来源于stack exchange，提问作者Unistack