[答疑]同事认为应该先画序列图，强烈反对先画类图

（匿） 2023-8-28 17:19

***团队分享会，我和同事分享了学习软件方法下的心得。我说根据需求规格说明书画出类图，再画时序图添加类的方法。有一个高开就说应该先通过画时序图得到有哪些类，这是敏捷建模强调的，而且我感觉他言辞比较激动，很反对先画类图。

我想询问您的专业意见，用什么理由向他解释得清楚一些。我翻了软件方法下电子版，还没有找到合适的内容。

UMLChina潘加宇

《软件方法》在一个迭代周期中的推荐做法是：

从用例规约提炼分析类图，再把分析类图和用例规约结合，通过分析序列图把用例规约上的系统责任分解和分配到类的操作上。当然，这期间各环节可以互动，例如，在画分析序列图时，发现类图需要加一个类。

那么，可不可以改成：从用例规约画分析序列图，在这个过程中得到类图和类的操作？

其实这两条路线都可以，对于真正熟练掌握面向对象建模技能的人来说，并没有太大区别。

**********

但是，对没有“真正熟练掌握”的人，我还是推荐先画类图，因为这背后的思考是最艰难的。

类似你说的疑问，已经很多人和我提到过了，以前我还和稀泥，说“都可以”，但现在我的观点变了。

没有“真正熟练掌握”的人，如果先画序列图，很容易得到一一对应的“or”、“er”类。

例如，“系统规划合适的排程”，“规划排程”是哪个类的责任，好办，“排程规划器”类呗！

特别是，像你提到的“言辞比较激动，很反对先画类图”的人，背后更有可能隐藏着一个巨大的脓包，他缺少画类图的技能！不会提炼抽象，不会寻找关系，所以他害怕，于是极力反对画类图，求助于画序列图得到一一对应的“or”、“er”类——你感兴趣可以留心一下他做的东西，是不是有类似脓包。

更可恨的是，有的国外国内的网红，为了迎合这些无能之辈，就会以敏捷、DDD为名，炮制一些帮助他们逃避这些艰难思考的“伪创新”，你问题里提到的“敏捷建模提到”有可能就属于这种情况。

**********

还有一种常见的情况：

建模人员感觉很难画出类图，画序列图倒是比较容易——因为他手上根本没有用例规约，只有一个小人圈圈的用例图。

这时候，表面上他是在画分析序列图，实际上他是在补用例规约（主要是路径步骤部分）。

更巧妙的是，通过这样的方式，转移了焦点——从“面向对象建模”转到了“补用例规约”。当他忙完，长出一口气，“补用例规约”部分有成果，他已经很满意了。至于“面向对象建模”做得怎么样，就无所谓了，毕竟不能求全责备嘛。

把这种伎俩发挥到极致，就是直接编码。表面上是在编码，其实在大脑里朦朦胧胧地把业务建模、需求、分析、设计一并做了，这同样起到转移焦点的效果。你看，我大脑里想这么多事情，其中只要有一件做好了，就是收获，毕竟不能求全责备嘛。

**********

正确的做法应该是：用例规约没做好，就把用例规约做好。在形式上要完备，内容上要平衡涉众利益。

上面说的假装画分析序列图实际上是补用例规约的情况，得到的“用例规约”在形式上既不完备（缺少字段列表、业务规则、质量需求、设计约束），内容也无法保证正确性（涉众利益在哪里？）。