在 UML 状态图中明确表明活动的顺序无关紧要答案

【问题标题】：Make explicit in UML state diagram that order of activities does not matter在 UML 状态图中明确表明活动的顺序无关紧要
【发布时间】：2021-12-06 04:34:09
【问题描述】：

有一个 UML 状态图，通过显示用户和系统执行用例的交互来描述系统的行为。此图用作与系统开发人员的协议（要求）。

当用户请求执行一个用例时，系统向用户请求信息，如果信息无效则显示错误消息。系统还会对用户进行身份验证，如果他未通过身份验证，则会向他显示错误。

但先完成哪个活动并不重要。它是，首先显示哪个错误、信息或验证错误。我们希望向开发人员明确说明，尽管所有活动都应该完成，但活动的顺序并不重要。我们如何做到这一点？我认为状态图中的“fork”项是为了这个？

【问题讨论】：

用例中没有顺序。活动是用例中的场景和订单操作发生的细节。状态图详细说明了某个元素（类、组件、节点等）的行为。
用例是特定参与者和系统之间的一系列操作，包括其变化，这些操作会产生对该参与者有价值的可观察结果。用例图将参与者与用例联系起来（用用例的名称）。可以使用状态图来传达用例的规范，该状态图包含执行状态更改的状态和活动。当然，状态图中从初始状态到最终状态的活动是有序的，在任何搜索引擎中查找状态图。
UC 由 n 活动描述各种场景。每个 Activity 都有 m 动作，您可以在其中定义它们对某些逻辑采取的顺序。你可以通过活动图来做到这一点。使用状态机会很奇怪。但也许你有一个 UC？

标签： uml requirements state-diagram

【解决方案1】：

您似乎将状态机图与活动图（可能还有序列图）混淆了。后者有 fork（并且在序列图中有一种方法可以显示事件是并行发生的）。

状态机图确实显示了状态及其触发器的变化，但不是显示相关动作及其流程的主图。此外，一个实体的整个状态机通常会受到不止一个用户故事的影响。换句话说，状态变化的触发器可能是由不同的用例引起的。所以状态机跨越多个用户故事，而不是仅仅描述一个。

如果您尝试使用状态机图记录用例流程，您很可能做错了。

【讨论】：

状态图和活动图是等价的。两者都有状态和活动。不同的是，状态图中的箭头是活动，方块是状态，与活动图正好相反。并且状态图有fork (uml-diagrams.org/state-machine-diagrams.html#)。
我不明白“受用户故事影响的实体的整个状态机”是什么意思。用例是作为黑盒的参与者和系统之间的交互，它通常使用状态图来指定用例。对于给定的用例，活动从初始状态过渡到在这些活动之间具有中间状态的最终状态。用户请求系统执行用例，然后系统向用户请求信息，然后用户填写信息，然后系统向用户显示消息以确认操作。
描述actor与系统的交互就是指定用例。你可以使用状态图来做到这一点。该交互具有活动（系统向用户请求一些信息，或向用户显示一些信息......），因此您拥有这些活动之间的状态（显示的信息，请求的信息......）。
您可以在状态机和活动图上表示状态和活动这一事实并不能使它们等效。你有完全不同的重点和细节层次。状态机不显示活动的详细信息，您无法将那里的活动分解为更详细的活动（如果您尝试，则无法显示整个相应的逻辑）。此外，状态机图中的箭头不是活动，它们是转换。一个活动可以在过渡期间执行，但不是必须的。
状态机旨在显示对象的整个生命周期以及其状态如何随时间变化。现在，虽然在单个用例中创建和销毁了一些对象，但它们是例外而不是规则。即使是典型的 CRUD 类型的用例也表明在 UC 上有创建对象、更新对象、删除对象等等。该对象的状态机应在一个图中显示创建、更新（并非总是）和删除。以在线商店的订单为例。