这是一个创建于 1931 天前的主题，其中的信息可能已经有所发展或是发生改变。
我不是软件从业人员，这个问题可能问的比较业余。使用者应该是产品经理，如何准确的把客户的业务逻辑描述清楚，转达给开发人员。
当业务逻辑越来越复杂的时候，特别是牵扯到很多交互、与底层设备的通讯、状态等待的时候，如果全写出来基本也是很难的，很多时候就是先写各大概，然后边做边搞清楚。等到最后，全部把这些逻辑写出来基本也是跟天书一样，没人再去看了。
想跟大家交流一下，这方面比较好的实践是什么。
 | 1 cigarzh 2020-06-27 22:03:17 +08:00 U M L |
 | 2 yannxia 2020-06-27 22:06:34 +08:00 分层 + 模块化 ----- 分层：把相对独立的一层当成一个黑盒处理，比如写 Java 的时候，你可以认为操作系统那是一个黑盒。先把最大的分层搞出来，每个分层里面还有自己分层，俄罗斯套娃。 模块化：每次就讲一个小模块，分层之后里面总是有几个模块，分开讲，模块很复杂的话，里面再分层+模块。 |
 | 3 sayhier OP 有时候还要处理不同任务之间的连锁交互。我在想关于这个是不是应该有一套理论指导，查了一下状态机之类的处理现实问题还是显得无力了点 |
 | 4 xuanbg 2020-06-27 22:24:24 +08:00 多画几个思维导图，把层次结构和关系先理理清楚，然后把不必要的都干掉，剩下的就是简单的了。 |
 | 5 imn1 2020-06-27 22:56:52 +08:00 不是技术人员应该很难写 UML，简单讲还是抓住 5W1H 大部分程序是按顺序执行，所以业务有顺序的话，按时间分开步骤 有些业务无关时间，只是不同状态之间切换（例如颜色不同引发不同业务），这种情况就按状态分 如果你有能力把大任务拆分为小任务，那其他都是小事 |
 | 6 ljpCN 2020-06-27 23:47:47 +08:00 via Android @sayhier 不知道你说的状态机是不是指形式语言与自动机理论中的状态机。如果是的话，我想状态机应该是表达能力最强的了，为什么会无力？是指繁琐吗？ |
 | 7 rocyhua 2020-06-27 23:52:34 +08:00 泳道流程图或者时序图比较合适 |
 | 8 harde 2020-06-27 23:56:34 +08:00 脑图 -> 流程图 + 时序图 |
 | 9 across 2020-06-27 23:58:00 +08:00 Axure ？ |
 | 10 kiroter 2020-06-28 10:13:08 +08:00 ddd |
| 11 sayhier OP 看来没啥好办法，就是大拆小，指望一个文档写清楚不可能的还是要靠多交流 |
| 12 sayhier OP @ljpCN 当状态多了，或者动态过程，就很难了。感觉状态机这东西也就平时针对具体问题整理一下思路的时候有用 |
 | 13 sleepm 2020-06-28 17:54:43 +08:00 excel |
Select Language