问题描述
WorkCoordinator 并且它根据传递给它的事件调用不同的服务类，因此如果事件是 trackIssue，则有一个 TrackService 类专门处理一些用于跟踪的操作，并且也是一个 Track 对象。所以你可以有以下
WorkCoordinator -- (track issue) --> TrackService (has a list of Track objects)
您将如何在 UML 图中正确表示这三个？一切都从使用 TrackService 和 TrackService 的工作协调器开始，它可能具有类似 add(Track track) 的函数，您可以在其中传递一个 Track 对象以添加到其中的数组列表中说：
private ArrayList<Track> tracks;
感谢任何见解，我正在考虑这样的事情，但可能完全错误。
解决方法
我有三个类，一个叫做
与操作相反，类不能调用，但可以使用。
WorkCoordinator -- (track issue) --> TrackService
当事件字符串是 trackIssue 时，WorkCoordinator 类使用 TrackingService 类，但是如何呢？因为在您的图表中，TrackingService 类只有操作 add 这意味着该操作被调用，即使我对此有些怀疑，更多的是我们不知道的事实参数中给出的 Track 实例来自哪里。如果调用了其他操作，请将其添加到图表中。
关于你的图表：
-
WorkCoordinator 和 TrackingService 之间的线的作用是未知的，然后无效。由于 trackingService 属性，您可能还想将其显示为关系，在这种情况下，关系必须完成。
-
TrackingService有两个Track列表，一个通过属性trackItems，另一个通过关系tracks 。这可能不是您想要的，trackItems 必须重命名为 tracks 或相反。
-
通过属性和关系来表示相同的东西在 UML 中是合法的，但相当繁重，因为读者必须检查它们是否是相同的东西，我鼓励你只使用它们中的一个，并支持绘制两个类时的关系。
-
您的聚合说 TrackingService 由 Track 组成，您确定是这种情况并且必须使用聚合吗？
您将如何在 UML 图中正确表示这三个？
类图根本没有表明当处理的事件是trackIssue时，add（或其他）操作会应用于trackingService（有正确的论据）。当然，您可以添加注释来说明这一点，但该注释是自由文本，只有人类才能理解。
要在图表中显示，您可以使用序列图或活动图，具体取决于您要显示的内容。
显示进程执行过程中发生的事情的序列图可以是（假设创建了一个 Track 的新实例，并在 add) :
event 应该是 process 的参数，用来命名 TrackingService 的实例我使用了 trackingService是属性的名称，item 表示创建的 Track 实例以在消息 add 中使用它。
所有这些看起来都很模糊，但这很正常，因为交互不是行为，而序列图侧重于生命线之间的消息交换。
如果您想对操作过程的行为进行完全建模而没有歧义，您可以使用活动，并且图表可以是：
补充说明：
一个事件通常不仅仅是一个像trackIssue这样的名字，所以process的参数不是一个字符串，或者那个字符串是一个复杂的形式。
-
Track 有 getter/setter 作为 id 而不是 name，看起来很奇怪.您确定 id 不仅在创建实例时设置（带有 name）？