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