在这个用例中我对继承和扩展构造型的使用是否正确
Is my use of inheritance and extended stereotype correct in this Use Case
用例应该描述这种情况：
船员可以通过无线电向 VL、DM 或 WL 提问。根据问题，他们需要在 APIC（一种软件工具）中查找，但情况并非总是如此。他们都是 apic 操作员，但根据他们的角色，他们有自己的专长，只有在 apic 中才能访问。
船员提出的问题可能与船闸执行、航海天气等有关...但都归结为相同的问答形式。
我的用例正确吗？
这里有三个问题：
- extends 箭头方向错误。
- UC 的泛化通常不是一个好主意。
- 顺便提一句：你的演员想念他们的腿。这样它就是一个女性符号（金星的镜子）。
让我们在 2 日详细说明一下。为什么这是个坏主意？ UC 表示正在考虑的系统将为参与者提供的单一附加值。所以每个 UC 都是独一无二的（想想独特的销售主张）。 USP 的推广仅在特许经营中有效。因此，除非您在这里模仿麦当劳，否则这很可能是一种错误的方法。看看主UC"ask question"。您是否考虑过系统的附加值？我不会。当查看后面的气泡时，它们看起来更像是主要用例。所以，把那个一般的"ask question"去掉，把后面的泡泡直接用Shipman连起来就可以了。
关于 UC 问题一如既往：Bittner/Spence 关于 UC 是我推荐的最佳读物。
提出问题通常不是用例。船员的目的可能不是问问题，而是得到一些答案。所以询问和回答是一个用例。
在分析用例时，会出现几种可能性，例如在APICS系统中查找信息。我只会在用例中描述这一点（可能使用 Activity 图）。在这里使用扩展有什么好处？ （我同意另一个答案，箭头方向错误。另外它应该是一个空心箭头）。
每个目标都是一个自己的用例，即使它们有很多共同点。在描述了用例的基本步骤之后，可能会节省一些工作来查看它们并找到那些在基本步骤中有很大重叠的部分，然后创建一个包含共性的抽象用例。但这只能在 描述用例之后完成。
永远记住，用例分析的主要目标是找到系统的所有功能需求，尤其是那些不是很明显的功能需求。如果您的用例只是您已知功能的包装，那么它们不会获得太多洞察力。
用例应该描述这种情况：
船员可以通过无线电向 VL、DM 或 WL 提问。根据问题，他们需要在 APIC（一种软件工具）中查找，但情况并非总是如此。他们都是 apic 操作员，但根据他们的角色，他们有自己的专长，只有在 apic 中才能访问。
船员提出的问题可能与船闸执行、航海天气等有关...但都归结为相同的问答形式。
我的用例正确吗？
这里有三个问题：
- extends 箭头方向错误。
- UC 的泛化通常不是一个好主意。
- 顺便提一句：你的演员想念他们的腿。这样它就是一个女性符号（金星的镜子）。
让我们在 2 日详细说明一下。为什么这是个坏主意？ UC 表示正在考虑的系统将为参与者提供的单一附加值。所以每个 UC 都是独一无二的（想想独特的销售主张）。 USP 的推广仅在特许经营中有效。因此，除非您在这里模仿麦当劳，否则这很可能是一种错误的方法。看看主UC"ask question"。您是否考虑过系统的附加值？我不会。当查看后面的气泡时，它们看起来更像是主要用例。所以，把那个一般的"ask question"去掉，把后面的泡泡直接用Shipman连起来就可以了。
关于 UC 问题一如既往：Bittner/Spence 关于 UC 是我推荐的最佳读物。
提出问题通常不是用例。船员的目的可能不是问问题，而是得到一些答案。所以询问和回答是一个用例。
在分析用例时，会出现几种可能性，例如在APICS系统中查找信息。我只会在用例中描述这一点（可能使用 Activity 图）。在这里使用扩展有什么好处？ （我同意另一个答案，箭头方向错误。另外它应该是一个空心箭头）。
每个目标都是一个自己的用例，即使它们有很多共同点。在描述了用例的基本步骤之后，可能会节省一些工作来查看它们并找到那些在基本步骤中有很大重叠的部分，然后创建一个包含共性的抽象用例。但这只能在 描述用例之后完成。
永远记住，用例分析的主要目标是找到系统的所有功能需求，尤其是那些不是很明显的功能需求。如果您的用例只是您已知功能的包装，那么它们不会获得太多洞察力。