问题描述
上下文
想象一个活动管理网站，活动策划者可以在该网站上发布活动。假设我们有三个演员：non-registered user，registered user和Event Planner。活动策划者可以发布可以公开（非注册用户可以看到）或私人（只有注册用户可以看到）的事件。
问题
我该如何描绘一个事实，即所有用户都可以看到公共事件，而只有注册用户可以看到私人事件？
其他问题：我应该将“ 查看即将发生的事件”和“ 查看过去的事件”分为两个不同的用例，还是应该将一个“ 查看事件” ”用例？
我有一些想法
以下图表是我想到的一些潜在解决方案，但我不确定它们的正确性。
具有单独的用例
使用扩展
将“查看事件”作为总体用例
解决方法
您要么接受Geert的建议，仅使用See events用例，要么您应该保留第一个用例。是否将See events划分为私有/公共，在很大程度上取决于您正在设计的系统。因此，考虑到需要进行分割（因为两个事件的看待方式会大不相同），您应该使用第一个草图。在这里很明显，谁可以处理哪个UC。只需一个UC，您就可以附加{only registered user can see private events}之类的约束。
您的第二个人似乎没有道理。 {@ {1}}是多余的，因为参与者已经与用例有直接关系。这种关系意味着扩展用例是在事件过程中最终执行的。因此，在观看私人活动的某个地方，也有看到公共活动的途径。
最后一个建议只是功能分解。与参与者没有关系的用例不是用例，因为它不会带来附加值。您可以使用通用的用例（专用/公用是«extend»的专用），但我始终建议不要使用该构造。 UC的泛化有些矛盾。 UC必须显示给正在考虑的系统的参与者带来的独特增值。但是，如果可以将其概括化，那么它并不是唯一的。而且与类归纳法（其中明确定义了属性/操作替代）不同，UC缺少此类描述，并且需要做很多解释。