Uml 在用例图中正确使用include和extends
我正在为理发店系统创建一个用例图。我不确定Uml 在用例图中正确使用include和extends,uml,actor,diagram,use-case,use-case-diagram,Uml,Actor,Diagram,Use Case,Use Case Diagram,我正在为理发店系统创建一个用例图。我不确定添加产品库存用例是否应该包括购买产品用例 与理发店系统互动的参与者包括： 顾客 系统用户（即Barber） 系统管理员（即经理） 所有用户都需要能够登录，如果客户是第一次使用，则需要注册 客户将与系统交互以预订或购买产品，即凝胶、洗发水、蜡。预订可以扩展到取消约会，客户不太可能重新安排约会，而是取消约会并在其他时间再次预订 系统用户理发师需要能够查看预约时间表、查看客户联系方式和登录系统 系统管理员很可能是经理兼理发师，他还应该能够查看预约时间表、查看客
添加产品库存购买产品我不熟悉您场景中的业务规则，因此这只是一点猜测工作和一些假设，您可以验证 我假设“添加产品库存”用例是关于将产品添加到所有产品的库存中。为了回答您的问题，我认为这个用例是否涉及添加一个产品、多个产品、管理产品（例如编辑或删除产品）、库存是否已经存在，或者库存是否与产品无关，但是对这些问题的回答不是从你的模型中清楚的100%，你可以考虑澄清这些点。 我还假设产品需要在库存中才能购买。如果是这样的话，那么我想你要问的是关于这一点——我如何表示产品需要添加到库存中才能购买的事实？如果这就是您所要求的，那么您可以使用一个简单的“依赖关系”来表示，该关系将从购买产品用例运行到添加产品库存用例，如下所示。这表明产品购买在某种程度上依赖于添加产品，但没有进一步解释这种关系。或者，您可以使用Precedes关系，而不是从添加到购买。我不认为extend是正确的关系——添加产品的步骤不需要在每次购买产品时都考虑在内，依赖性取决于添加产品的目标是否首先实现，而不是步骤 我不确定添加产品库存用例是否应该包括购买产品用例 情况并非如此，否则，这意味着每次在库存中添加产品时，也会在添加期间购买该产品。还要注意的是，这两个用例中的参与者并不相同，但是具有include，这意味着购买也由管理员完成 也没有延伸 产品在购买前已添加到库存中这一事实是您在UC购买说明中提出的先决条件
图表中还有其他问题：
- 你所有的扩展都画错了方向，除了可能在登录和注册之间，这取决于你想说什么
- 将次要参与者放在右边是很常见的，所以客户似乎是次要参与者，但事实并非如此
- 管理员和巴伯无法登录（但他们可以注销），要想让这些角色中的一个成为一个真正的人之前成功登录所需的角色，就需要一个演员嘉宾或类似的角色
- 同样，客户不能注册（也不能登录）
- 但事实上，登录和注册（以及注销）是非常常见和简单的特性，可能没有足够的附加值成为用例
- 客户只能在约会创建期间取消约会，这不是您想要的
- 您需要允许客户以其他方式激活“取消约会”（直接或作为“可能查看自己的约会”的扩展，请参见下文）
- 对我来说，当约会正在构建时，它不存在，然后客户不能取消约会，但客户可以中止构建。所以对我来说，这些用例之间没有延伸。当然，在预约的描述中，你可以说流产是可能的，但我认为所有UC都是如此
- 很可能客户可以查看他/她的约会，因此必须添加UC（比如查看自己的约会）。注意，这与理发师可以激活的UC视图指定不同，因此这些UC不得具有相同的名称。将取消预约作为新UC的扩展似乎是一个好方法，在这种情况下，客户无法直接激活取消预约
- 缺少管理员可以激活的某些UCs，用于修改产品价格、删除产品、修改理发师详细信息、删除理发师