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

Question

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

这里有什么要概括的吗？实现中的添加编辑和删除方法由一个类处理。但是每个对象的调用都是单独处理的。这个可以吗？

Answer 1

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

其次，扩展关系指定“如何以及何时将扩展用例中定义的行为插入到扩展用例中定义的行为中”。扩展用例是箭头所指的用例。然后箭头应该反转，因为 *Add Contact * extends Manage Contacts：在执行“ Manage Contact ”的某个时刻，如果满足某些条件（例如用户选择了“add”）“ Add Contact ”的行为被执行。

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

如果您想建模每个“添加/编辑/删除”用例与其他用例有共同点，您可以将其建模为抽象用例。那么“添加联系人”不仅是“管理联系人”的特化，也是“添加”的特化（定义了添加某个实体的行为）。

Answer 2

根据经验，“管理 X”永远不应该是一个用例。用例是应用程序的特定功能，从用户的角度来看具有精确的目的。对于用例来说，“管理”总是太模糊。

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

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

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