考虑到这种情况：
...下订单时会检查可用性，如果通过，则开始准备工作，否则订单将被拒绝。
如果客户在开始准备之前决定使用信用卡付款，则订单的价格将锁定在信用卡上。
准备工作完成后，订单即送达，如果下单后超过 30 分钟，则可享受 50% 的折扣。
我的疑问是如何在状态机图中对 if 条件进行建模，我会按照以下方式对其进行建模，但我不确定它是否正确：
我应该如何对状态机图中的条件进行建模？
【问题讨论】：
标签： uml state-machine
这张图（取自here）可能会有所帮助：
所以回答你的问题，你没有做错，这只是风格和可读性的问题。据我所知，UML 并没有真正定义表示条件的标准方法。因此，只需选择看起来最好且有意义的东西。
【讨论】：
无法在状态机的状态元素内定义条件。查看您的图表。我想，你应该把一些信息放在图表上。例如，使用选择元素来定义替代转换路径。或者从准备和交付状态绘制“准备订单”和“付款”行为的详细图表。
并非总是可以将所有信息都放在一张图表上。
【讨论】：
在 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。
我认为您在准备和交付状态的输入活动中设置的条件非常好。因为这些条件似乎与进入这些状态时发生的活动相关联，而不是与任何状态转换相关联。
【讨论】：