前段时间上了个比较大的需求，也一直没有大块的时间来思考，零零散散的考虑了很久，终于在前两个礼拜，整体构思完成，目前已基本上完成了整体的设计规划。
整体来说，决定抛弃之前的想法，使用因果图的设计方法来设计整体流程用例。主要原因有几个
1、我们的条件太多。从登录之后，到下单完成，总共有近十大类的前提条件，大类下还有细分，这条件整体算下来有四五十，对于正交表来说，这条件数量太多
2.条件彼此之间的联系太过紧密。这近十大类的前提条件，彼此相互关联，相互影响，彼此之间的关系过于错综复杂，比如，能不能下单，他们的前提条件就至少存在5个左右的判断：是否因公、是否有权限、是否违规、是否允许违规、是否审批等等，一环套一环，均会影响到最后的订单是进入审批流程还是支付流程。而对于正交表来说，要尽可能的避免各个条件之间彼此影响，否则，就会陷入无尽的条件的关系处理中去。而因果图则是最合适不过的，它本身就是处理各个条件之间、条件与结果之间的关系的，此处正是他的用武之地。
那么，问题来了。
这么多条件，即使使用因果图来处理，那么也需要有一个比较好的方法，来处理这么多条件，尤其是处理条件与条件之间的先后层次、要求、因果等关系
在这里，我借鉴了一个分层的思想
首先，理清条件起作用的真正的先后顺序。由于技术方面的原因，有些在整体流程靠后时才起作用的条件，被人为的前置了，准确的说，在前面的流程中，能看到该条件出现在眼前，而真正要使用该条件的地方，确实在后面，当然，也有前面的条件被后置了。比如审批规则，真正要使用的地方，是在下单前，而却被放在一开始下单的时候，就显示了审批规则是怎样的，这样容易形成一种错觉，以为这个条件是前置的。要理清的这种内在的逻辑（那是一段痛苦的日子啊，一次又一次的下单，都快要被客服妹子给neng死了）。
其次，按照条件出现的真正顺序，确定每个条件应该处于整体流程中哪个位置。这个时候，就需要
从搜集到的资料来看，正交表和因果图都是在条件太多的时候所使用的不错的方法，不过也有一点区别
正交表所要求的条件，彼此之间不能有太多的交叉影响，应该是彼此独立，也可以重复选择，或者即使条件之间有影响，也应该是比较小的影响
而对于因果图来说，这个方法本身就是处理条件与条件之间的关系的一个方法，条件之间有各种互为依存的关系，若是彼此独立，用这个方法反倒更加复杂了
正交表使用的详细说明
http://www.blogjava.net/qileilove/archive/2014/11/10/419848.html
——尾声：后来一直在忙，把项目上线后，就离职了，入职新单位一直忙到现在。文章比较早就写完了，一直没发布，今天才发布
网友评论