如果条件的UML状态机图

Question

考虑到这样的情况：

...当一个订单时有可用性检查，如果传递的准备工作将启动其他的顺序被拒绝。

如果客户决定启动订单的价格被锁定在信用卡上的准备之前，用信用卡支付。

当准备完成的订单交付，并且如果从所述顺序的放置30分钟以上已通过有50％的折扣。

我的疑问是如何建模的，如果在一个状态机图状态，我会把它以下列方式模型，但我不知道这是正确的方式：

http://f.cl.ly/items/29250u032k0d3d3U0i0p/state2.jpg

如何我应该模拟如果状态机图中的条件？

Answer 1

在UML状态机图上，条件与转换关联。该转换具有“trigger-signature [guard]/activity”形式的3部分标签。 Guard是有条件的，并且为了进行转换必须评估为真。转换标签的所有3个部分都是可选的。

从您的问题描述，我可以定义3种状态为“等待命令”，“准备命令”和“交付订单”。从“等待订单”过渡到“准备订单”，并且该过渡可以标记为“order placed [order is available] /”。我选择放弃这项活动，因为从问题描述中，我没有看到与此转换相关的任何活动。你可以画另一个标签为“order placed [order is unavailable]/refuse order”的转换。然而，这种转变将从“等待订单”开始，并返回到“等待订单”，因为当订单被拒绝时我们不会更改状态。在此转换中，我包含了refuse order活动，因为我认为有一些实际活动与拒绝订单相关。

或者，我已经看到了包含决策钻石的过渡，其中钻石的箭头标有trigger，钻石中的一个箭头标记为[guard]/activity，而钻石外的另一个箭头标有[else]/activity。但我不确定这是否是技术上正确的UML。

我认为您在准备和交付状态的条目活动中放入的条件非常好。因为这些条件似乎与它们进入这些状态时发生的活动相关联，而不是任何状态转换。

Answer 2

这个图（从here拍摄）可能会帮助：

因此，要回答你的问题，你没有这样做是错误的，它只是一个风格和可读性问题。据我所知，UML并没有真正定义表示条件的标准方式。所以，只要看看最好的和合理的。

Answer 3

不可能在状态机的状态元素内定义条件。复习你的图。我想，你应该把一些信息放在图上。例如，使用choice元素来定义替代转换路径。或从准备和交货状态中为“准备订单”和“付款”行为绘制详细图表。

并不总是可以将所有信息都放在一张图上。