《UML for Java Programmers》记

 1 当你做图的时候能够想象到你的代码是极其重要的。我们把图当作了解代码的一条捷径，并不是替代代码。如果你画着图但是不能想像出它代表着什么样的代码，你是正在空气中建筑着城堡。停下来你正在做的，想想如何如能将它可以转化成代码。不要为了图而画图，你必须时时刻刻记得，代码才是你要表现的。

--- 设计师从Coder进化来的，Coder的经验（代码-->重复的代码习惯-->模式） --> 设计师

     设计师在设计的时候，正好是上面过程的反方向。领域具体问题 --> 抽象的模式 -- >曾经类似的经验 -->曾经写过的代码（实现）。

2 使用白板的目的不是为了正确地标出图上序列号的点，而是使每个围在白板前讨论的人都理解它，最终目标是停止在白板上画而开始编写代码。

--- 项目的目的是为了结束项目。

    UML（沟通方式--设计与开发人员）的目的是实现，设计的实现，沟通理解是过程。

 

3 什么时候开始画图？

   多人开发时，需要每个人都理解特定部分，开始画图；每个人都理解了，停止画图。

   对某处设计存在不同意见是画图，讨论作出决定时停止画图，擦掉这些图。

   当你需要探讨一个设计的想法时，画图能够帮你更好的地思考。当你得到了能够帮助你完成思考的代码的要点的时候，扔掉这些图。

   当你需要向其他人或自己解释一部分代码的结构的时候，你可以画图。当你觉得其实最好看代码来进行解释的时候，停止画图。

   当醒目快结束，顾客需要时开始画图。

  什么时候停止画图？

   不是因为过程需要。

   不是为了做一个好的设计师而画图，仿佛说不画图就不是好的设计师。

   不是为了别人实现代码才画图，为了帮助自己的实现才画图。

---为了真正的需要才画图（需要就是画图的目标--实现）

4 依赖关系 java实现

 

  

 

  

5 代码真是能够用于描述系统的一部分吗？实际上，这应当是每个设计者和开发者的目标。团队应该努力去创建表述清楚和可读性强的代码，使更多的代码能够描述自己，更少地需要图，最好整个项目不需要图。

 

6 有关用例要留意的一件事情是：明天它们将要发生变化。

   如果有些事情明天将要发生变化，你今天就不需要真正去捕获细节。实际上，你要尽量推迟细节的捕获，直到最后可能的时刻。

 

7 Martin文档第一要律：只编写那些你真正需要的有意义的文档。