问具有相似特征的对象的UML思想。

EN

首先，用例图通常用于描述系统的需求，从用户的角度来看。“管理联系人”和“管理事件”是您的用例是很好的，但是用例模型应该独立于表示联系人和事件的类。(较低级别的细节在其他图表中描述得更好)

其次，扩展关系指定“如何以及何时可以将扩展用例中定义的行为插入到扩展用例中定义的行为中”。扩展的用例是箭头所指的。那么箭头应该反转，因为“添加联系人”扩展了管理联系人:在执行“管理联系人”的某个时刻，如果满足某些条件(例如，用户选择了“添加”)，则执行“添加联系人”的行为。

事实上，为了适应你的模型，这是对扩展关系的一种非常强制的解释。我认为可以更好地概括它：“管理联系人”是一个抽象的用例，由“添加联系人”、“编辑联系人”和“删除联系人”(以及事件、作业等)专门化。

如果您想对每个“添加/编辑/删除”用例进行建模，使其具有与其他用例相同的，那么您可以将其建模为抽象用例。那么"Add Contact“不仅是"Manage Contact”的专门化，也是"Add“(定义添加某些实体的行为)的专门化。

​

​

作为一个经验法则，“管理X”永远不应该是一个用例。用例是您的应用程序的特定功能，从用户的角度来看，它具有确切的用途。“管理”对于用例来说总是太模糊了。

实际上，"Manage X“在这里显然是一个包，并将被命名为"X management”。这些包将允许您将应用程序的各个部分分开。并且不需要对Add X、Add Y、Add Z进行分组，它们唯一的共同点是您最终都会在数据库中执行insert。虽然对这些使用继承是有效的，但我认为不值得这样做。

因此，在我看来，您应该将独立的用例分组到包中。

还有一个建议:我不会对Login使用插入关系。当然，这些关系是正确的，但它们挤满了您的图表，并且很可能是隐含的。区分需要登录的用例和其他用例的典型方法是使用两个参与者，一个是匿名“用户”，另一个是您的“学术”。