如何为给定的上下文绘制用例图？

Question

给出了对DHL的跟踪请求的如下描述

在电晕时代，我们在网上订购了很多东西。交付并不总是按计划进行，因此我们有兴趣获得(更多)有关交付的信息。DHL包服务有一个全面的web服务，它提供关于运送和接收包裹的信息。除其他外，页面访问者可以在DHL the服务上搜索联系信息。另一个选择是通过聊天联系DHL。聊天中的请求由DHL AI ( DHL网络服务的一个实例)自动回答。访问者可以发送请求(通过聊天)，其中还包括输入包裹的寄售号码给DHL AI。然后，为了获取有关货件的信息，访问者需要在webservice中进行身份验证，这可以将访问者提升到客户，并允许DHL AI回复聊天请求。如果DHL AI无法响应请求，则将请求转发给DHL员工。为了缩短等候时间，客户可以选择通过电话与DHL员工联系。

如何绘制用例图？这是否正确：

​

我将如何建立“.可选择通过电话联系DHL员工”的用例？这个用例会扩展前向请求用例吗？那么，我们是否可以将客户与扩展用例联系起来，如

​

​

但是，“通过聊天联系DHL”不包括“发送请求”用例吗？

Answer 1

一个用例通常应该与一个用户目标相对应，除非它是一个扩展，否则它也应该是独立于其他用例的。在这方面：

• Reply to request本身没有任何意义。因此，这个“用例”可能是用例Contact DHL的一个细节。然后，DHL AI将成为Contact DHL Contact DHL的第二个角色，似乎也是如何联系DHL代理的一个细节。
• 细节，如Enter consignment number或send request，是用户界面细节。用例不应用于建模用户界面。这是一个设计主题，将其放在用例中将强制使用一种特定的用户界面方法，而不考虑更好的alternatives.
• Authenticate不是用例。这是个限制。假设您有一个具有单点登录(SSO)的系统:然后身份验证用例就没有意义了，因为没有与参与者交互来实现它。

因此，用例尽可能简单：

如果你开始考虑场景的细节，以及接下来的步骤，你不再是在建模用例，而是一个控制流程:从这个层次上使用一个活动图。如果你开始使用一个用例，然后根据叙述将它分解成更小的案例，那么很有可能你会被误导去进行功能分解。这不建议用于用例，因为它会导致非常详细的图表。

现在到可选用例:可选通常建议使用扩展。但是Contact by phone真的扩展了Contact via chat吗？我相信这两种形式的接触是两种不同的东西。因此，我认为有两种办法：

1. 只是做一个用例Contact DHL，在对这个用例的描述中，您可以解释联系人可以通过电话或通过聊天。这是我最喜欢的approach.
2. Make --一般情况下的用例Contact DHL。使专门化的Contact DHL by chat和Contact DHL by phone都能以最适合的方式实现一般情况。这种方法比较复杂，但它允许考虑到专业之间更基本的区别，例如AI演员参与聊天，而人工操作员参与电话。