SSD与SD分离用户交互与系统内部交互

在为架构性能仿真设计描述文档时，一个常见误区是把用户与系统的交互、和系统内部模块间的交互，都画在同一张顺序图里——这样做的问题是：一旦用户与系统的交互方式发生改变，即使系统内部功能块的交互逻辑完全没变，架构师也不得不重新设计整份混在一起的顺序图。为了解决这个问题，书中采用两类UML动态图分别描述这两层交互：系统顺序图（SSD，四元组(actor, system, message, fragment)）描述用户与整个系统之间的交互——把系统当作一个黑盒，交互的执行顺序由用户主导，架构师很难为其构建固定不变的模式；顺序图（SD，四元组(SDID, module, message, fragment)）描述系统内部各模块间的交互过程——完全由系统本身的设计决定，用户无法控制。两者的关键差异在于”谁说了算”：SSD偏向描述系统在用户层面的全局运行情况，其交互顺序受用户操作意图驱动，具有高度不确定性；SD偏向系统内部的局部运行情况，一旦架构设计确定，交互逻辑就是确定的。把两者分离带来的直接好处是：架构师可以自由设计各种用户与系统的交互场景，而无须修改系统内部的交互逻辑——如果某个用户操作已经有对应的SD，设计新场景时甚至无须重新设计该操作对应的SD，还能直接复用SD的仿真结果去加速SSD的仿真。这个设计思路的普遍价值超出了仿真本身：它揭示了一条通用的架构文档化原则——凡是”变化速率不同”的两类信息（用户交互模式经常变、系统内部实现逻辑相对稳定），都应该拆到不同的文档或模型里分别维护，而不是耦合在同一份描述中，否则任何一方的变化都会连累另一方被迫重做。