（匿） 2022-12-15 19:56

前些天您给我们开会分析项目的时候，好像只画了两张图，相比几个月前讲课的时候少了很多。

做项目时画什么图可以裁剪，我这样理解对吗？我们这样的项目，您特地画的这两张图是不是最重要的？

UMLChina潘加宇

其实这些都是课上说过的。

您问出这个问题，说明您之前上课没有好好听，后来也没有好好复习和做题，“开会”似乎也开了个寂寞。

得好好补课并且多向其他掌握得好的同事学习才行啊。

不过，针对您问题中提到的几个点，倒是可以展开说一下。

（1）只画了两张图，相比之前讲课的时候少了很多

讲课时，大家的（《软件方法》）基础较差，当然是按照步骤讲解知识，布置练习，案例示范……。

要是按照后来剖析项目那个节奏，原本14小时的课推导出来的模型，1-2个小时之内也可以得到的。

您所说的“开会分析项目”是我们的工件评审服务（补注：参见UMLChina服务指南）。

此时，团队的几个骨干都有了一定的基础，和我这边的交流效率高了很多，改进模式一二三，涉众利益，泛化关联，一听就有共识是什么东西，过程就显得快了，这不就是我们课上和书上讲的好处吗：基本共识上的沟通，提高沟通的效率和深度。

图1 摘自《软件方法》第1章

工件评审是按时间收费的。如果我为了照顾像您这样的同事，又把知识点给过一遍，操作示范一遍，把3个小时能解决的问题拉长到14小时，领导也没意见，我倒是挺乐意的。

（2）做项目时画什么图可以裁剪

对。不过，即使对，我猜测您也还没有理解里面的道理。

建模的推导过程是不能“裁剪”的：

图2 摘自《软件方法》第1章

但是，表达形式上可以是灵活的：

如果不需要和其他人交流，大脑又有足够的能力把握问题的复杂度，那建模在大脑里一闪而过可能就够了，不需要以其他形式表达。

其实往往卡就卡在第二点“大脑有能力把握问题的复杂度”，就算爱因斯坦压根不想和别人交流，他在思考问题的过程中，估计也要在纸张和黑板上写大量的演算公式，哪怕演算完了就立即扔垃圾桶。

如果需要表达出来，可以口头、文本、UML、其他……

我在“开会”时的表现，就可以用以上知识点来解释。您阅读完以下文字后，（如果领导允许）可以回看当时的开会录像对照一下。

首先，我建模的推导过程依然是完整的，需求从业务建模来，分析从需求来，设计从分析来，不会无凭无据。这个没有变化。

其次，我建模的表达形式是灵活的。

业务建模和需求，我感觉几位骨干掌握得还好，所以，主要是看着贵方的“****说明书”（严格来说只能算是建模的素材），一页一页翻下去，主要通过口头交流，然后我说一些建模的意见以及特别要注意的地方。

其实在探讨的过程中，也是有画图的，我也在屏幕上用笔画了一些简单的用例图、序列图，把要点画出来辅助探讨，只不过没有体现在我留下来的EA模型里面。

一旦我觉得几位骨干已经基本理解我的意思，就往下走。但是，我在会上也要求了，几位骨干回去按照我说的要点，认真用EA建模，然后发给我看。

我可以有资格“形式灵活”，他们目前可还不行。

我写这么一大通，最要紧的就是怕有的同学看到表面现象，说潘老师是这么干的，然后称赞我“敏捷”之类的。

“拍脑袋”和“在大脑里完成”不是一个东西。

绝大多数“敏捷”的人，是“拍脑袋”，而不是厉害到了“在大脑里完成”。

（3）我们这样的项目，您特地画的这两张图是不是最重要的？

不是！

“开会”的时候我说了，逐点改进技能，贵司的这个项目目前来看，改进业务建模技能可能收益最大，那就先聚焦于改进业务建模技能，其他工作流像以前一样搞就可以。

您说的那两张图，一张是系统的分析类图，一张是某个类的状态机图。

上面说过，如果我简单点一下要点，下面的同事就能心领神会去完成建模任务（主要是业务序列图），那就点出要点就行。

之所以我要画这两张图，是因为这个类图和状态机图需要更多的抽象能力，我估计我点了要点，下面的同事也搞不定的，所以我就自己上了。

刚才也说了，先聚焦于改进业务建模技能，而我画的分析类图、分析状态机图属于分析工作流，暂时置之不理即可。

如果分析设计按照以前的搞法，这两张图有参考价值，参考一下无妨。

如果纯粹是为了学习类图和状态机图的知识，拿来当学习资料也无妨。

但千万不要误解说，潘老师画这个就是让我们要学会用类图、状态机图来解决项目中的问题！然后把大量精力投进去——您的项目问题很多，但最大的问题不在这里。

---