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

DDD领域驱动设计批评文集

“软件方法建模师”不再考查基础题

《软件方法》各章合集

(匿) 2023-8-28 17:19

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

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

UMLChina潘加宇

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

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

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

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

**********

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

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

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

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

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

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

**********

还有一种常见的情况:

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

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

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

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

**********

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

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