问题描述
我正在为理发店系统创建用例图。我不确定 Add Product Inventory 用例是否应包括 Purchase Product 用例。
将与理发店系统交互的演员是：
客户将与系统交互以进行预订或购买产品，例如凝胶、洗发水、蜡。预订可以延伸到取消预约，客户不太可能重新安排预约，而是取消预约并在不同时间再次预订。
系统用户，即理发师，需要能够查看预约时间表、查看客户联系方式并登录系统。
系统管理员（可能是经理兼理发师）还应该能够查看约会时间表、查看客户联系方式并将产品库存添加到商店。产品库存还将包括设置产品规格、产品颜色或尺寸以及设置价格。
解决方法
我不确定“添加产品库存”用例是否应包括“采购产品”用例。
事实并非如此，否则这意味着每次将产品添加到库存中时，它也会在添加期间购买。另请注意，这两个用例的参与者并不相同，但包含意味着购买也是由管理员完成的。
也没有扩展。
在购买之前将产品添加到库存中的事实是前提您在 UC 购买 的描述中放入的。
您的图表中还有其他问题：
-
你所有的扩展都画错了方向，除了可能在登录和注册之间，这取决于你想说什么
-
把次要角色放在右边是很常见的，所以客户似乎是次要角色，但事实并非如此。
-
Admin 和 Barber 不能登录（但他们可以退出），要拥有这些角色之一，一个真人需要之前成功登录，这是通过演员Guest或类似的东西完成的。
-
以同样的方式，客户不能注册（也不能登录）
但实际上登录和注册（和注销）是非常常见和简单的功能，可能没有足够的附加价值作为用例。
-
客户只能在创建过程中取消约会，这不是您想要的。
- 您需要允许客户以其他方式激活取消约会（直接或作为可能的查看自己的约会的扩展，见后）
- 对我来说，在构建约会时它不存在，然后 客户 无法取消约会，但客户可以中止构建。所以对我来说，这些用例之间没有扩展。当然在Make Appointment的描述中你可以说中止是可能的，但我认为所有UC都是这种情况。
很可能客户可以查看他/她的约会，因此必须添加 UC（比如说查看自己的约会）。请注意，这与 Barber 可以激活的 UC View Appointmenst 不同，因此这些 UC 不能具有相同的名称。将取消预约作为这个新 UC 的扩展似乎是一个好方法，在这种情况下，取消预约不能由 客户直接激活。
某些管理员可以激活的 UC 缺失，用于修改产品价格、移除产品、修改理发师详细信息、移除理发师、...
我不熟悉您的场景中的业务规则，因此这是您可以验证的一些猜测和一些假设。
我假设“添加产品库存”用例是关于将产品添加到所有产品的库存中。为了回答您的问题，我认为此用例是否与添加一个产品、多个产品、管理产品（例如编辑或删除它们）、库存是否已存在或库存是否相关都无关紧要与上面的产品不同，但这些问题的答案并非 100% 从您的模型中明确，您可以考虑澄清这些要点。
我还假设产品需要在库存中，才能购买。如果是这种情况，那么我认为您要问的是关于这一点 - 我如何表示产品需要添加到库存这一事实在它可以购买之前？如果这就是您要问的，那么您可以使用简单的“依赖”关系来表示该关系，该关系将从 Purchase Product 用例运行到 Add产品库存 用例如下。这表明产品购买在某种程度上依赖于添加产品，但并没有进一步解释这种关系。或者，您可以使用从 Add 到 Purchase 运行的 preceedes 关系。我不认为extend是正确的关系——添加产品的步骤不需要在每次购买产品时都考虑在内>，依赖于首先实现添加产品的目标，而不是步骤。
