业务逻辑越来越复杂，用什么方式/工具来描述好？

[sayhier]

我不是软件从业人员，这个问题可能问的比较业余。使用者应该是产品经理，如何准确的把客户的业务逻辑描述清楚，转达给开发人员。

当业务逻辑越来越复杂的时候，特别是牵扯到很多交互、与底层设备的通讯、状态等待的时候，如果全写出来基本也是很难的，很多时候就是先写各大概，然后边做边搞清楚。等到最后，全部把这些逻辑写出来基本也是跟天书一样，没人再去看了。

想跟大家交流一下，这方面比较好的实践是什么。

[cigarzh]

U M L

[Yanickkk]

分层 + 模块化
-----

分层：把相对独立的一层当成一个黑盒处理，比如写 Java 的时候，你可以认为操作系统那是一个黑盒。先把最大的分层搞出来，每个分层里面还有自己分层，俄罗斯套娃。

模块化：每次就讲一个小模块，分层之后里面总是有几个模块，分开讲，模块很复杂的话，里面再分层+模块。

[sayhier]

有时候还要处理不同任务之间的连锁交互。我在想关于这个是不是应该有一套理论指导，查了一下状态机之类的处理现实问题还是显得无力了点

[xuanbg]

多画几个思维导图，把层次结构和关系先理理清楚，然后把不必要的都干掉，剩下的就是简单的了。

[imn1]

不是技术人员应该很难写 UML，简单讲还是抓住 5W1H

大部分程序是按顺序执行，所以业务有顺序的话，按时间分开步骤
有些业务无关时间，只是不同状态之间切换（例如颜色不同引发不同业务），这种情况就按状态分
如果你有能力把大任务拆分为小任务，那其他都是小事

[ljpCN]

@sayhier 不知道你说的状态机是不是指形式语言与自动机理论中的状态机。如果是的话，我想状态机应该是表达能力最强的了，为什么会无力？是指繁琐吗？

[JasonSTA]

泳道流程图或者时序图比较合适

[harde]

脑图 -> 流程图 + 时序图

[across]

Axure ？

[kiroter]

ddd

[sayhier]

看来没啥好办法，就是大拆小，指望一个文档写清楚不可能的还是要靠多交流

[sayhier]

@ljpCN 当状态多了，或者动态过程，就很难了。感觉状态机这东西也就平时针对具体问题整理一下思路的时候有用

[sleepm]

excel