在这个用例中，我对继承和扩展原型的使用正确吗？

Question

用例应该描述这种情况：

船夫可以通过无线电向VL、DM或WL提出问题。根据问题的不同，他们需要在APIC (一种软件工具)中查找，但情况并不总是如此。他们都是apic运营商，但根据他们的角色，他们有自己的专长，只能进入apic。

船夫问的问题可能是关于船闸的执行，航海的天气等等。但这一切都归结为同样的问答格式。

我的用例正确吗？

​

​

Answer 1

这里有三个问题：

• 扩展箭头是错误的方向。
• 一般说来，推广UCs是个坏主意。
• 就像旁白:你的演员错过了他们的腿。这样它就成了女性的象征(金星的镜子)。

让我们在二号再详细阐述一下。为什么这是个坏主意？UCs代表了一个正在考虑的系统将提供的一个参与者的单一附加值。所以每个UC都是独一无二的(想想独特的销售主张)。USP的泛化只在特许经营中有效。因此，除非您在这里建模McDonalds，否则这可能是一个错误的方法。看看主要的UC“问问题”。你认为这是一个系统的增值吗？我是不会的，当看到气泡背后的时候，它们看起来更像是主要的用例。所以，只要去掉一般的“问问题”，直接将气泡与Shipman连接起来。

和以往一样，当谈到UC的问题时: Bittner/Spence是我能推荐的最好的读物。

Answer 2

问问题通常不是用例。船夫的目标可能不是问一个问题，而是得到一些答案。因此，询问和使用是一个用例。

在分析用例时，会出现几种可能性，例如在APICS-system中查找信息。我只想在用例中描述这一点(可能使用活动图)。在这里使用扩展有什么好处？(我同意另一个答案，那就是箭头的方向不对。另外，它应该是一个打开的箭头)。

每个目标都是自己的用例，即使它们有很多共同之处。在描述了用例的基本步骤之后，可能会节省一些工作来查看它们，找出那些在基本步骤中有很大重叠的步骤，然后创建一个包含共性的抽象用例。但是，只有在描述了用例之后才能这样做。

请始终记住，用例分析的主要目标是找到系统的所有功能需求，特别是那些不明显的需求。如果您的用例只是您已经知道的功能的包装器，那么它们并不能获得太多的洞察力。