【敏捷开发】论设计阶段如何画图
软件开发中，分析和设计时，文档的编写和思想的交流，经常要绘制各种各样的图。
相对于人类的自然语言，描绘复杂结构，图具有直观和整体的特征，有着不可替代的表现力。
软件开发是创造性的劳动，开发人员几乎在每一分钟都要做出某些选择，每一个选择都好像决定着最后的结果。
绘图的时候也是如此，脑中有完整或不完整的想法，要清晰的表现出来时相当不容易。
事实上，许多老手都不会画图。
在实践的过程中，总结了一些经验，得出了一些结论。
1. 不画没有必要的图
如果简单的文字就能说得很清楚，还画图干什么！
对代码级别的细节，不要画图来表现；
不要借助图来让你的文档得变大；画蛇莫要添足。
2. 忽略底层的细节
软件是一个多层的东西，一个图只展现恰当抽象层次之上的细节。
一个过细的图，大量的信息会掩盖真正重要的东西。
比如：在一个流程图上，不需要把“文件打开的错误判断”也作为一个分支画在图上，除非你“无聊到”要强调这个显而易见的异常处理；
3. 图不要太大
如果一个图上包含上百个对象，看起来不舒服，应该化整为零，使用多个图，每个图描述不同的部分。
4. 画纯种的图
图传递的信息应该明确，无歧义。
一定要明确图中的各个组成元素都是什么东西，整个图要表现什么。
尽量使用规范的图。比如：
- 流程图中，应关注控制的传递，不要有从文件中读取数据的数据流；
- 软件结构图中，描述模块之间的父子关系的同时，不要有模块之间的数据流。
- 常见到这样的图：在图中既有“控制流”，也有“数据流”，不伦不类，名之曰“示意图”。
- 交流时，这种示意图在白板上随手画画还可以，而不应该出现在正式的文档上。
- 这些图中的控制流，实是一个模糊概念，A->B可以表示：1)A调用B，把控制传递给B；2）A启动B,把控制传递给B；3）A向B传递一个控制信号；4)有一个第三者调用A完成后，马上调用B。
5. 图的布局要简洁，美观
我听说：书写大幅的毛笔字，特别讲究布局。
同样道理，画软件图，尽量密度分布均匀，减少连线的交叉。
为了减少连线的交叉， 同样的单元可以在图中出现多次。
6. 其实并不需要完备的图
使用UML有三种方式：
- UML as sketch(草图)，使用不完备的图进行系统某一部分或某一方面的内容进行交流；
- UML as blueprint（篮图），通过完备的UML图表现详细设计的所有决定；
- UML as programming language，自动精确的UML图，直接编译成可执行的代码（现在好像还没有实现）。
Martin Fowler说：使用UML绘制草图的人，真正关注UML的精髓（大师就是大师，说话就是不一样）。
所谓“不足胜有余”，不管什么图，图应该集中表现其关注的方面，恰当的忽略一些细节时必要的。
类图中，往往没有必要包含类的所有函数合成员说明；
在表现对象之间协作的顺序图中，大多时候也没有必要表现存在的分支和循环。
7. 所有的规则都是用来遵守和打破的
上面的所有道理，也并非是不变的真理。
但是，道理被打破以前，你应该了解它，熟悉它，批评它，忘记它（追求类似张三丰太极剑的境界）。
古人云：事有反道而适权，伪经而和道者。
笑傲江湖说：独孤九剑，无招胜有招。
萧大侠：删繁就简，取精用宏。
规劝朋友也规劝自己：连有招的境界尚未达到，应该知道自己该做什么。
