用因果图辅助代码分析

发表于三月 5, 2018

MFQ&PPDCS不仅可以用作“黑盒”的需求分析(可以参考上一篇:破石计划 -如何应用MFQ&PPDCS进行需求开发),也可以用于“白盒”的代码分析 - 有的时候可能找不到很好的需求描述文档、有的时候不得不阅读别人写的一段代码、有的时候不得不通过阅读代码来了解需求。。。


最近有机会做了这样一个练习:被分析的函数,处理的是员工打卡所发生的迟到或早退的记录,由于保密需要,这里就不附原代码了,总之,一眼就能看出来,这段代码写得大而冗长,并且逻辑复杂,if else层层嵌套,注释混乱并常有错误,可读性很差。


只好先试着用因果图原封再现了代码的意图(为了降低复杂度,已经剥离掉了可以被重构的子函数),注意这仅仅是初稿,不精确的分析:



尽管如此,也不难判断,我们遇到了一个复杂的“怪兽”:仅中间节点就用了10个,这是一个很深的Nested If结构。


小提示:如果对应的因果图看起来很复杂,代码中多半会有逻辑错误,值得多问一些What About的问题。


与基于“黑盒”的需求建模相比,基于代码建模,要谨防“被代码误导”的问题,对分析人员要求更高,要时刻跳出代码的逻辑,多问为什么


比如,对于这个图,可以问:

  • 为什么需要如此多的if嵌套,各逻辑判断,前后的顺序是否必须如此?

  • 为什么这个逻辑关系中需要判断这个参数?

  • 这个逻辑关系中是否还需要考虑其他参数?(防止出现Stuck=0或1的错误)

  • Primary Causes之间的关系是?

  • 有没有什么Termination Masking、Sequential Masking的关系?


这样一问,就发现其实多个原子的逻辑关系之间无所谓先后顺序,用Peer Level Ifs就可以了,再补充上必要的约束关系以及Masking的关系,几易其稿,最终的因果图如下:


建模的过程,对需求理解会愈发深刻,顺便发现几个bug也就不足为奇了,如果可以据此重构代码,逻辑就清晰多了。


感兴趣的话,可以继续花点时间,得出测试条件,上述因果图需要覆盖的Function Variation有19个,我设计了12个Test Conditions。

Comment Box is loading comments...