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

Question

事件，工作，自我和联系只不过是DTO对象，可以从数据库中添加，编辑和删除每个对象。我对用例图不太熟悉，所以我想知道这是否正确或是否可以改进。

这里有什么可以概括的吗？实现中的add edit和delete方法由一个类处理。但是对每个对象分别处理调用。这个可以吗？

Answer 1

首先，用例图通常用于描述系统的要求，从用户的角度来看 。 “管理联系人”和“管理事件”是您的使用案例，但用例模型应该独立于哪些类代表联系人和事件。 （较低级别的细节在其他图表中有更好的描述）

其次， extend 关系指定“扩展用例中定义的行为如何以及何时可以插入到扩展用例中定义的行为”。扩展用例是 指向箭头 。然后箭头应该反转，因为*添加联系人*扩展管理联系人：在执行“管理联系人”的某个时刻，如果满足某些条件（例如用户已选择“添加”）执行“添加联系人”的行为。

实际上，这是对扩展关系的强制解释，以适合您的模型。我认为可以通过概括更好地描述：“管理联系人”是一个抽象的用例，专门用于“添加联系人”，“编辑联系人“和”删除联系人“（对于事件，工作等也是如此）。

如果您想对每个“添加/编辑/删除”用例的共同点与其他用例进行建模，您可以将其建模为抽象使用案例。然后“添加联系人”不仅是“管理联系人”的专业化，而且还是“添加”的专业化（定义行为）添加一些实体）。

Answer 2

根据经验，“管理X”绝不应成为用例。用例是应用程序的特定功能，从用户的角度来看具有精确的用途。对于用例而言，“管理”总是过于模糊。

事实上，“管理X”在这里显然是一个包，并将命名为“X管理”。这些包允许您分离应用程序的各个部分。并且不需要对Add X，Add Y，Add Z进行分组，它们唯一的共同点就是您最终将在数据库中执行插入操作。虽然为这些使用继承是有效的，但我认为这不值得。

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

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