最近在看《Agile Principles,Patterns,and Practices in C#》, written by Robert C. Martin and his son Micah Martin. 其中写到他们关于UML、CASE使用的观点，有点颠覆传统的意味，觉得很好玩儿，贴出来和大家共享。我的理解也许还有偏差，不能完全代表Robert的观点，纯属标题党吸引眼球，呵呵。

1、要对完全掌握UML的n多种图形么？

UML有类图啊、状态图啊什么的好多种，但对程序员来讲，一般用到的也无非就那么几种：类图（Class Diagrams）、对象图（Objects Diagrams）、顺序图（Sequence Diagrams）、协作图（Collaboration Diagrams）和状态图（State Diagrams）；

2、为什么要建模？

有人可能说：架构设计师不用UML画上一大堆的图形那还叫架构师么？可Robert说，非也，架构师是用代码而不是一大堆乱七八糟的UML图形，UML图形只是用来交流的工具，是用来画在白板或者白纸上，用完就扔的，而不是把它弄成一段貌似正式的文档装订成册装点门面。

3、开发过程一定要建模吗？

非也，建模的目的是为了测试某个方案是否可行，既然是测试，当然那个成本低就用哪个，如果直接用代码和画复杂的UML图代价差不多的话，还不如直接用代码。

4、什么时候要画UML图，什么时候不用画？

需要画的情形：

• 几个人需要同事做某件事，从而他们都要了解整个结构，需要画UML图统一思想。大家达成共识了，这些图形也就功德圆满，可以擦掉扔掉了。
• 你想让团队达成共识，但有那么一两个不同意你的方案。你需要在固定的时间段内来讨论一下，讨论时间用完了就应该把结果定下来，不要总没完没了的讨论、扯来扯去的。可以通过投票或者权威人士判定。
• 当你在思考一个设计时，可以用UML来辅助思考，想清楚了就可以把这些图形扔掉了。
• 你要把你的代码解释给别人听时，需要画一些。
• 项目要结束了，客户非要你提交UML图当做文档时，得画吧。

下面的情形就不用画了：

• 貌似软件开发过程要求了要画UML然后在coding？
• 你觉得要不画点UML图什么就会觉得内疚，其实大可不必。
• 创建复杂的UML比写代码还麻烦呢，这种情况还不如不画

5、关于CASE工具

在你打算投资购买一套CASE工具之前，要仔细想想清楚哦～

• CASE工具不是能让我们在画UML图时更容易么？不，他只能是增加复杂度。因为你学习这个软件也得费半天劲。
• CASE工具不是能让一个大的团结在画UML图时能更方便的合作么？只是有时候是，但是一般一个很大的团队根本用不着画那么多那么复杂的UML图形。
• CASE工具不是能自动生产代码么？的确是，但是维护修改这些生产的代码估计和你自己写也省不了多少事，所以建议在花钱买CASE工具之前好好衡量一下到底能给你提高多少的生产力。
• 那把CASE工具和IDE集成在一起的怎么样？嗯，这个想法不错。但是坦率的说，我宁愿把投入到CASE的这部分钱花在IDE在编程方面的改进上。

6、有的时候使用文本格式的比图形更简单。还有机会使用自动化工具做进一步处理。比如针对State Transitions Tables的SMC（Statce Machine Compiler） 可以参考 http://www.objectmentor.com

嗯，结论：

不要为了UML而去UML；UML只是交流工具，交流清楚了就可以扔掉了；在画UML图形时应该能够想像到对应的代码实现，否则就别画了。