一个气泡（用例）代表一个 activity 图是真的吗？
Is that true that one bubble (use case) represent an activity diagram?
我曾制作 一个 activity 图表来表示具有 3 个参与者的用例 。我为每个演员制作了一个 泳道，所以我在一个 activity 图表 中有 3 个泳道。但是我的讲师说这是错误的，因为我应该有更多的 activity 图。他的意思是一个activity图基于用例图中的一个气泡（用例），而不是基于actor。不过我浏览多了，发现我讲师的话应该是时序图，而不是activity图。那么真实的说法是什么？我的第一个 activity 图表还是我的讲师的话？
Activity 图没有演员。
它们旨在显示从一个 activity（用例）到另一个的消息流。您可以阅读有关此 here.
的更多详细信息
activity 图有以下主要用途，它：
- 绘制系统的activity流程，
- 描述了从一个activity到另一个的序列，并且
- 描述系统的并行、分支和并发流程。
您的导师是对的：
- 用例图是关于系统为满足需求而必须提供的内容。每个用例对应于一组 行为集 ，可以在与参与者交互时执行这些行为以帮助他们实现目标。
- activity 图是关于系统如何执行基本行为或更复杂的行为集
用例与系统内部无关。这是关于它的目的和与外界的主要关系。此类图中显示的用例之间绝对没有顺序。用户可能会阅读它并得到“对我有什么帮助？”这个问题的答案。
Activity恰恰相反，不是关于外面的世界，也不是关于演员。它是关于系统的内部结构：它的内部流程，它遵循一个可以从控制和数据流语义中推导出来的顺序。开发人员可能会阅读它并得到“这将如何工作？”这个问题的答案。
如果您知道某些活动是在与某些参与者互动时执行的，并且您认为这很重要，则可以在模型中使用 activity partition 以图形方式表示为“泳道”来传达此知识。但请注意，分区并非旨在映射到参与者或环境的其他元素。分区允许直观地对具有某些共同特征的 activity 个节点进行分组。它们通常用于突出显示哪个组件或 class 在做什么。
总而言之，activity 和用例之间不一定存在直接映射，因为它们代表不同的现实。但是，如果存在这样的映射，则每个用例（气泡）至少有一个 activity 图。
P.S: 稍作编辑以避免术语混淆：“泳道”是一个非 UML 术语 coming from process modeling ，它描述了图形布局，“分区”是模型
中activity图的细分
没有一种方法可以指定用例。 UML 没有描述如何去做。因此，对于如何去做，很多作者都有不同的想法。因此，您使用分区（您称它们为泳道）来表示 Actors 的想法是有效的，只要它可以帮助您将用例传达给利益相关者。
但是，当您的讲师有不同意见时，这对您没有帮助。他或她可能有充分的理由发表此声明。可能它在他或她所经历的情况下效果很好。
一些作者建议使用交互图。由于用例描述了参与者如何使用系统，换句话说，他们如何与之交互，这可能是一个不错的选择。这里的问题是，大多数人只知道交互的顺序图，它们并不能很好地描述可以达到用例目标的所有不同方式。
因此，许多人使用 activity 图，尽管它们不能正式描述参与者与系统之间的交互。它们实际上是为了描述系统的内部运作（当然也可以是人的系统）。因此，您的 activity 图正式意味着 activity 调用参与者的行为。我不认为那是你的想法。
由于许多人仍然使用 activity 图来描述用例，我认为您对分区的解释并没有那么离谱。我个人认为，分区使建模器的生活变得不必要地更加困难并且不会使用它们。
如果您选择使用活动来描述用例，每个用例应该有一个 activity。
一个用例表示系统的单个功能，但不显示满足要求所涉及的过程，为了显示所涉及的过程，我们使用 activity 图。
我曾制作 一个 activity 图表来表示具有 3 个参与者的用例 。我为每个演员制作了一个 泳道，所以我在一个 activity 图表 中有 3 个泳道。但是我的讲师说这是错误的，因为我应该有更多的 activity 图。他的意思是一个activity图基于用例图中的一个气泡（用例），而不是基于actor。不过我浏览多了，发现我讲师的话应该是时序图，而不是activity图。那么真实的说法是什么？我的第一个 activity 图表还是我的讲师的话？
Activity 图没有演员。
它们旨在显示从一个 activity（用例）到另一个的消息流。您可以阅读有关此 here.
的更多详细信息activity 图有以下主要用途，它：
- 绘制系统的activity流程，
- 描述了从一个activity到另一个的序列，并且
- 描述系统的并行、分支和并发流程。
您的导师是对的：
- 用例图是关于系统为满足需求而必须提供的内容。每个用例对应于一组 行为集 ，可以在与参与者交互时执行这些行为以帮助他们实现目标。
- activity 图是关于系统如何执行基本行为或更复杂的行为集
用例与系统内部无关。这是关于它的目的和与外界的主要关系。此类图中显示的用例之间绝对没有顺序。用户可能会阅读它并得到“对我有什么帮助？”这个问题的答案。
Activity恰恰相反，不是关于外面的世界，也不是关于演员。它是关于系统的内部结构：它的内部流程，它遵循一个可以从控制和数据流语义中推导出来的顺序。开发人员可能会阅读它并得到“这将如何工作？”这个问题的答案。
如果您知道某些活动是在与某些参与者互动时执行的，并且您认为这很重要，则可以在模型中使用 activity partition 以图形方式表示为“泳道”来传达此知识。但请注意，分区并非旨在映射到参与者或环境的其他元素。分区允许直观地对具有某些共同特征的 activity 个节点进行分组。它们通常用于突出显示哪个组件或 class 在做什么。
总而言之，activity 和用例之间不一定存在直接映射，因为它们代表不同的现实。但是，如果存在这样的映射，则每个用例（气泡）至少有一个 activity 图。
P.S: 稍作编辑以避免术语混淆：“泳道”是一个非 UML 术语 coming from process modeling ，它描述了图形布局，“分区”是模型
中activity图的细分没有一种方法可以指定用例。 UML 没有描述如何去做。因此，对于如何去做，很多作者都有不同的想法。因此，您使用分区（您称它们为泳道）来表示 Actors 的想法是有效的，只要它可以帮助您将用例传达给利益相关者。
但是，当您的讲师有不同意见时，这对您没有帮助。他或她可能有充分的理由发表此声明。可能它在他或她所经历的情况下效果很好。
一些作者建议使用交互图。由于用例描述了参与者如何使用系统，换句话说，他们如何与之交互，这可能是一个不错的选择。这里的问题是，大多数人只知道交互的顺序图，它们并不能很好地描述可以达到用例目标的所有不同方式。
因此，许多人使用 activity 图，尽管它们不能正式描述参与者与系统之间的交互。它们实际上是为了描述系统的内部运作（当然也可以是人的系统）。因此，您的 activity 图正式意味着 activity 调用参与者的行为。我不认为那是你的想法。
由于许多人仍然使用 activity 图来描述用例，我认为您对分区的解释并没有那么离谱。我个人认为，分区使建模器的生活变得不必要地更加困难并且不会使用它们。
如果您选择使用活动来描述用例，每个用例应该有一个 activity。
一个用例表示系统的单个功能，但不显示满足要求所涉及的过程，为了显示所涉及的过程，我们使用 activity 图。