(21) – SSD

最后更新于:2022-04-01 07:29:28

## 连载:面向对象葵花宝典:思想、技巧与实践(21) - SSD 用例图是用来描述系统的,而SSD(系统序列图)又是来描述用例的,oh my god,这不是在玩我们么?![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-20_569f5cca18ca1.gif) System Sequence Diagram,缩写为SSD(注意不要与SSD硬盘混淆),中文翻译为“**系统顺序图**”,主要用于描述某个用例的某个分支场景下,外部参与者与系统的交互过程。简单来说:SSD就是用例的可视化描述。   细心的朋友可能会发现,前面我们在介绍“用例方法”的时候说不需要画图,这里又说SSD是用来描述用例的,这不是互相冲突了么?   事实上并不冲突,原因在于:用例方法分析需求的时候,确实不需要图;但用例方法分析完成后得到的用例,我们可以使用SSD让用例更直观一些。   SSD有几点需要特别注意: 1)SSD不是标准的UML图形:UML只有顺序图、用例图,但是没有一个专门的“系统顺序图”;之所以叫做“系统”顺序图,是因为这个顺序图中只有两类对象:系统、与系统交互的对象; 2)SSD是用来描述某个用例的某个分支,而不是描述系统的结构; 3)画SSD的时候,整个系统被当做一个黑盒,不涉及系统的分解; 4)不需要为每个用例每个分支都画一个SSD,挑出关键的用例和分支即可;   有的朋友可能会有疑问:如何知道哪些用例的哪些分支是关键的呢?   我的答案是:你认为是关键的你就画,你认为不是关键的你就不画;如果你认为所有的用例都很关键,那么所有的用例你都画即可,只要你不怕麻烦或者工作量太大;如果你认为所有的用例都很简单,那么一个都不画也可以。至于你的判断是否正确,主要靠经验积累,当经验不够的时候,也可以求助有经验的人。   以POS机为例,假如我们认为POS机的正常处理流程是关键分支,则对应的SSD如下:  ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2016-01-20_569f5cca29524.jpg) 仔细对照SSD和POS机的用例,我们会发现SSD和用例基本上是对应的,但并不完全对应,例如: Ø 用例中第1步是“顾客携带选择好的商品到收银台”,但SSD中第1步是开始交易; Ø 用例中“顾客将钱交给收银员”,但SSD中并没有对应的步骤; Ø 用例中最后一步是“买单完成,顾客携带商品和小票离开”,但SSD中最后一步是“交易结束”;   为什么会出现这种不对应的情况呢? 主要原因在于:用例是整个业务的流程,而SSD是站在系统的角度来描述系统与外部对象的交互,这就需要我们在画SSD的时候做一些技巧性的处理: Ø 删除系统无关的业务步骤 例如上述的“顾客将钱交给收银员”,这个步骤和POS机没有关系,因此无需体现,再说了,就算你想体现,你也体现不了; Ø 将业务语言转换为系统语言 例如用例中是描述“顾客携带选择好的商品到收银台”,但对应系统来说,这就意味了“交易开始”;同样,“买单完成,顾客携带商品和小票离开”意味着“交易结束”。   有的朋友可能会认为,应该在用例分析的时候就应该详细写清楚。例如,“买单完成,顾客携带商品和小票离开,收银员告诉POS机交易结束”。 这种想法本身没错,但问题在于,理想和现实总是有差距的,用例不可能那么完善,甚至有的时候用例可能都存在错误,如果我们自己没有一定的分析和理解能力,完全依赖原始的用例,这样做是不可能设计出优秀的系统的,甚至连合格的系统都可能做不到。   综合上面的分析,我们可以看到,SSD虽然来源于用例,但还需要在用例的基础上稍微加工一下,使得SSD能够更加聚焦于“系统”这个主角。   最后小小吐槽一下:**用例图是用来描述系统的,而SSD又是来描述用例的,oh my god,这不是在玩我们么?**
';