活动图是否应该包含有关系统如何从应用程序开始运行的详细信息？
例如，我正在制作一个摇摆应用程序，其中应用程序在应用程序打开时加载带有图像的 JList，所以即使用户自己没有执行在 JList 中加载图像的任务，我也应该在活动图中指定这一点。
活动图中的泳道也应该根据我的挥杆应用程序可能具有的类进行划分。
例如，在一个简单的摇摆应用程序中，每个模型、视图和控制器都有 1 个泳道。下面是我制作的图片，
或者
我觉得即使第一个图像是正确的，第二个图像帮助我想象类图将如何以更好的方式形成。那么我应该使用第二张图片吗？
泳道绝对没有模型意义。他们只是一条线。我建议使用（BPMN 原型）UML 元素的池/通道。它们被相应地分类（通常与演员一起），并且单个动作进入每个动作。这使活动具有清晰的结构，并且还显示了责任。
与往常一样，答案是“视情况而定”。详细程度不是由图表的类型决定的，而是由使用图表的上下文决定的。
如果该图旨在显示一个用例的流程，它可能应该将自己限制为显示参与者和整个系统执行的活动，而不是系统的各个部分。
另一方面，如果活动图显示了通过用例实现的流程，它肯定应该显示系统的不同部分。
假设在项目进行到一半时，您决定更改设计而不使用 MVC。这意味着需要重新绘制图表。如果图表是用例实现的一部分，那是可以预料的（因为这就是您所做的，您决定以不同的方式实现用例）。但是作为用例本身一部分的图表不应该仅仅因为您更改了设计而需要重新绘制；参与者和整个系统之间的交互流程不应该改变。
也就是说，MVC 是一种众所周知的分解用户交互的方式，即使在用例中也可能允许进入该级别的详细信息。因此，假设您正在记录用例而不是实现，如果在您的项目或公司中，用户交互总是设计为 MVC，那么我说继续——但保持严格并使用“模型”而不是“影像服务”。如果在用例分析阶段无法决定使用 MVC 设计，我建议不要这样做。