自己画得状态图，请大家拍砖

张恂

五老星2011 发表于 2011-12-23 10:23
在实现环节，我决定可以通过建立“作废”的接口，然后构造不同的实现。
从状态图的角度来说，一个状态如 ...

>>从状态图的角度来说，一个状态如果包括三种不同的处理，在状态图上是否应该被独立出来？（表示清晰）还是该合并到一个状态？

从本案看，不同的作废处理可以抽象成三种不同的变迁事件（客户作废、客服作废、系统自动作废），它们的后继结果是同一个状态-已作废。

张恂

blackjade777 发表于 2011-12-22 17:30
我觉得，新蛋作废这个状态应该也是在“待审核”转过去的吧
从你的描述中，当开始后的第一个状态应该只可能 ...

对！

张恂

blackjade777 发表于 2011-12-23 12:47
一般我的做法是：状态还是一种，就是作废，因为无论你是根据什么操作到达这个状态的，但是对于这个对象来说 ...

>>从待审核到作废，实际中间的箭头是2个，一个标注客户作废，另一个标注新蛋作废。

张恂

我画的，是不是好点？

五老星2011

张恂 发表于 2012-1-10 17:26
我画的，是不是好点？

吸取了一些建议，重新画了状态图。不过我个人观点，作废还是保留了各种作废，原因是激活的条件和产生的动作不相同。

lodge

恩，ＬＳ的分析角度偏重于开发一侧，把较为繁杂的作废处理做成了核心处理。
这张图给我的感觉是，订单的状态迁移路线过于复杂，看不清主要迁移路线和结束条件。
个人认为，作废属于异常处理，可在图中留下接口另行分析。
简而言之，ＬＳ的设计大幅提升了系统的复杂度，会为开发留下不少隐患。

五老星2011

lodge 发表于 2012-1-17 09:31
恩，ＬＳ的分析角度偏重于开发一侧，把较为繁杂的作废处理做成了核心处理。
这张图给我的感觉是，订单的状 ...

个人觉得，这个是状态图，而非流程图。所以确实没有按照主干、分支和异常的思路处理。不过你的回答，倒让我感到：在状态图中，是否每个状态是均等的，不存在主干、分支，有待讨论。
另外，有一点，我觉得值得商榷，就是复杂度应该来源于业务本身。
不过，我目前正在尝试用状态模式，进行实现，换句话，即用状态机实现状态图。

lodge

整体设计涉及到对业务的理解，不便深究。下面说说细节吧。
图上很多状态和事件的名称比较混乱
如，状态名称 客户作废 感觉是个条件名， 改成已作废更容易理解成是个状态。
还有 状态名称 提交 似乎写成已提交更容易理解
条件名称 支付成功/支付失败 感觉是个状态， 写成 完成支付/拒绝支付 似乎比较妥当
还有 条件名称 货到付款 写成 要求货到付款 等等

简单地说， 状态要用能够反应状态的名词 而条件要使用动词进行表述。

五老星2011

lodge 发表于 2012-1-17 13:28
整体设计涉及到对业务的理解，不便深究。下面说说细节吧。
图上很多状态和事件的名称比较混乱
如，状态名 ...

恩，命名上确实是没注意到。“状态要用能够反应状态的名词 而条件要使用动词进行表述”，很不错的建议！回头改改。
关于客户作废改为已作废，正是本贴讨论的一个话题：就是客户作废、电商作废、系统作废是三种不同的作废方式，有可合并为“已作废”的前提。但是问题也恰恰在这里，三者对应的触发条件不同，且后续如果有数据分析，也不同，那么到底是不是合并呢？

lodge

五老星2011 发表于 2012-1-17 14:47
恩，命名上确实是没注意到。“状态要用能够反应状态的名词 而条件要使用动词进行表述”，很不错的建议！回 ...

状态识别的确是比较让人纠结的地方。从概念上说，设计时应当选择同业务功能直接产生关系的状态进行分析。
所谓直接产生关系就是说当出现这一状态时，业务功能势必发生变化。
上面的图应该是分析订单处理过程的，显然对该流程来说三种作废方式是没有区别的（因为它们都指向了结束），所以偶认为对所分析的业务来说作废方式是没有区分开来的必要的。
当然，如果是给订单分析数据画状态图，那么就有必要分开来了。