转自：http://www.uml.org.cn/UMLApplication/200509273.htm
UML软件工程组织 北京火龙果软件工程技术中心
--------------------------------------------------------------------------------
《UML:Java程序员指南》的读书笔记
来自：http://blog.csdn.net
1. 第一章 针对Java程序员的UML概述
1. UML(统一建模语言)的三个层次：
1. 概念层(Conceptual)
接近人类自然语言
有歧义
无严格的格式
2. 规格说明层(Specification)
3. 实现层(Implementation)
规格说明层和实现层接近代码、无歧义、有严格的格式
2. UML分三类：
1. 静态图（static diagrams）
描绘类、对象、数据结构以及存在于它们之间的逻辑关系。
2. 动态图（dynamic diagrams）
描绘运行期间，软件执行流程和软件实体状态改变的方式。
3. 物理图（physical diagrams）
描绘物理实体，如：源文件、库文件、字节文件、数据文件等，以及它们之间存在的逻辑关系。
3. 类图（静态图）
1. 长方形表示类，箭头表示关系。
2. 图中的所有关系叫关联（associatons），关联的命名对应引用的对象的变量名称。
4. 对象图（动态图）
可以看成是内存的一个快照，主要反应程序中的对象在运行期的信息。
1. 对象名称有下划线。冒号后面跟着对象类型的名称。
2. 对象之间的关系叫链接（links），链接的命名同样对应引用的对象的变量名称。
5. 序列图（动态图）
几个术语：
1. 监护（guards）
2. 构造（construction）
3. 数据标记（data token）
4. 活动（activation）
6. 协作图（动态图）
序列数的点结构
7. 协作图和序列图的异同点
同：它们包含的信息相同
异：协作图描述对象之间的关系，序列图描述消息被执行的前后顺序。
8. 状态图（动态图）
限定状态机（finate state machines）
图中的箭头被称为转换（transitions）
2. 第二章 使用图
1. 为何要制作模型？
制作模型的目的是为了证明模型是否可以正常工作。
一个模型必须有一个可用的检验标准。
2. 使用UML的时机：
1. 需要通过检验来确定某些东西是否可用的时候。
2. 使用UML来检验比用编码来检验更划算的时候。
3. 有效的使用UML
1. 使用UML在开发人员之间传达设计概念。
使用UML创建具体算法对应的图，并不方便。
UML对创建大型软件结构的“路线图”，比较有用。
通过UML图可以清楚的发现类与类之间的依赖关系和整个系统的结构。
2. 保留和舍弃
大多数的UML图都是短命的，应该舍弃的。只需记录在白板或白纸上。
但下列图应该保存下来：
1. 表现系统中一个通用设计的解决方案的UML图。
2. 记录了复杂的协议，难以通过代码了解的UML图。
3. 提供了较少涉及到系统范围内的“路线图”的UML图。
4. 比代码更易表述设计意图的UML图。
这些保存下来的UML图，应该经过多次迭代精化修改，最终版本应保存在团队都能访问的公共区域。
长期保存与临时创建的UML图应该分开存放。
3. 迭代精化
先研究动态场景，然后确定静态结构的内在含义。
对动态图（如：协作图）和静态图（如：类图）进行多次迭代并不断完善。
4. 最适合创建文档的时机：
团队完成了所有工作，项目即将结束的时候。
5. 使用Interface实现事件机制，避免了button对Dialler的依赖。
这样按下按键之后可以拨号，也可以做别的事。
6. 适配器
适配器也叫转接器，用于在一件或多件仪器的不同部件之间实现有效兼容性的装置。
适配器的作用：实现接口，转发消息。
7. 画UML图时应时刻想像着如何转化为代码。
8. UML图的目标并不是要如何正确，而是要讨论它的人都理解它，所以UML图应尽量简洁。
9. 什么时候画UML图：
1. 多人参与开发，且这些人需要理解一个系统的特定部分的设计结构时，开始画UML图。
所有人都声明已经理解了的时候，停止画UML图。
2. 两个或多人之间对某个设计点产生意见分歧，进行讨论时，需要画UML图。
讨论完毕，做出决定后，停止画UML图。
3. 思考一个设计时，画UML图会有所帮助。
思考成熟并完成相应的代码后，停止画UML图。
4. 向他人或自己解释一段代码的逻辑结构时，开始画UML图。
发觉看代码能理解的更清楚时，停止画UML图。
5. 当项目快要结束，客户需要UML图和文档时，开始画UML图。
10. 什么时候停止画UML图：
1. 画图并不是一个必经的过程。
2. 好的设计者只有在需要的时候才编码和画UML图。
3. 不要在编码之前的设计阶段，去为创建全面的文档而画UML图，这是浪费时间。
4. 不要为了其他人编码而去画图。
11. UML Case工具：
1. UML Case 工具的弊：
1. 正版价格贵
2. 需要学习周期
2. 自动绘制UML图的协作系统，应当在手动协作系统不够用的时候才去考虑它。
3. 项目中使用UML Case工具或集成于IDE的UML Case工具，应先进行效能实验，三思而后行。
12. 文档
必须建立文档，但必须谨慎地创建文档。
软件文档应该言简意赅
一个软件文档的价值通常与文档的大小成反比。
wiki是一个团队中协作编写文档的不错方法。
3. 第三章 类图
1. 类图描绘类本身的信息，以及类之间的关系。
2. 类使用正方形表示
"-"表示私有（private），"+"表示公有（public），"#"表示受保护（protected）
Figure UML-5-2-1
Figure UML-5-2-1 对应的代码
public class Dialler
{
private Vector digits;
int nDigits;
public void digit(int n);
protected boolean recordDigit(int n);
};
3. 关联
大多数情况下是表示对象实例持有着对其它对象的引用。
Figure UML-5-3-1
Figure UML-5-3-1 对应的代码
public class Phone
{
private Button itsButtons[15];
};
4. 多重性
Figure UML-5-4-1
Figure UML-5-4-1 对应的代码
public class Phonebook
{
private Vector itsPnos;
};
"*"表示数量非常多，所以PhoneBook的成员变量itsPnos的类型往往使用Vector、List或其它容器。
5. 继承
约定：为了便于区分，通常用垂直方向的箭头表示继承关系，用水平方向的箭头表示关联。
在UML中，继承箭头指在基类上。
Figure UML-5-5-1
Figure UML-5-5-1 对应的代码
public class Employee
{
...
};
public class SalariedEmployee extends Employee
{
...
};
虚线继承箭头表示实现一个接口。
虚线继承箭头指向被实现的接口。
白板上画虚线耗时，可以马虎一下用实线代替。
Figure UML-5-5-2
Figure UML-5-5-2 对应的代码
interface ButtonListener
{
...
};
public class ButtonDiallerAdapter implements ButtonListener
{
...
};
另外一种表示实现接口的方法：
Figure UML-5-5-3
6. 在一个UML图中，同时展现所有的方法会引起混乱，所以，只提供一批有代表性的方法会使UML图更清晰。
7. 细节
细节和修饰符大多数时候并不需要，但是有时候它们是很有用的。
1. 类的构造型
类的构造型显示在一对双角括号之间，放在类的名称上访。
Java有两种标准的构造型：
1. interface
interface的所有成员函数都是抽象的
2. utility（工具类）
utility的所有成员变量和成员函数都是静态的。
类的构造型可以自己定义，但必须所有阅读UML图的人都明白其含义。
2. 抽象类、抽象方法
用斜体字或用{abstract}属性，表示一个抽象类或一个抽象方法。
Figure UML-5-7-2-1
Figure UML-5-7-2-1 对应的代码
public abstract class Shape
{
private Point itsAnchorPoint;
public abstract void draw();
};
3. 属性
1. 属性不是类的一部分，但可用来代表额外的信息。
属性可被自定义。
2. 属性的形式：用逗号分隔，由名称、值对组成的列表。
如：{author=Matin,date=20020429,file=shape.java,private}
3. 一个属性的默认值是true，所以{abstract}等价于{abstract=true}
4. 属性被写在类名称的下方。
5. 一个非正式的约定：在白板上{abstract}可以简写成{A}
6. 一般只使用{abstract}属性。
4. 聚合（Aggregation）
聚合是关联的一种特殊形式，表示一种整体/部分（whole/part）的关系。
为了防止混淆，应避免使用聚合
Figure UML-5-7-4-1
Figure UML-5-7-4-1 对应的代码
public class Whole
{
private Part itsPart;
};
5. 组合（Composition）
组合是一种特殊的聚合形式
组合用的极少
涉及到一个深度复制的问题。
Figure UML-5-7-5-1
Figure UML-5-7-5-1 对应的代码
public class Owner
{
private Ward itsWard;
};
6. 多重性（multipicity）
对象能够持有其它对象的数组或向量，或者说它们能够持有许多同一类型但不同实例的对象。
多重性的表达式：
数字 精确的数量，使用数组作为容器。
*或0..* 0个或0个到无数个，使用Vector作为容器
0..1 0个或1个，在Java中通常用一个空的引用来实现。
1..* 1个到无数个，使用Vector作为容器
3..5 3个到5个，使用数组作容器
0,2..5,9..* 非法的表达式
Figure UML-5-7-6-1
Figure UML-5-7-6-1 对应的代码
public class BinaryTreeNode
{
private BinaryTreeNode leftNode;
private BinaryTreeNode rightNode;
};
7. 关联的构造型
1. < > 标准UML标记
源对象创建了目标对象，然后将目标对象传递给系统的其它对象。
这种关联可应用于工厂模式。
Figure UML-5-7-7-1
Figure UML-5-7-7-1 对应的代码
public class A
{
public B makeB()
{
return new B();
}
};
2. < > 标准UML标记
源对象的成员函数中创建了一个目标对象的实例，把这个实例当做一个本地变量。
Figure UML-5-7-7-2 同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >
Figure UML-5-7-7-2 对应的代码
public class A
{
public void f()
{
B b=new B();
//use b
}
};
3. < > 标准UML标记
源对象的成员函数把目标对象的实例作为参数使用，源对象不保存目标对象的实例。
Figure UML-5-7-7-3 同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >
Figure UML-5-7-7-3 对应的代码
public class A
{
public void f(B b)
{
//use b
}
};
4. < > 非标准UML标记
源对象传递目标对象的一个成员函数时，用到< >
< >可应用于多种涉及模式，如：Proxy、DECORATOR和COMPOSITE7。
Figure UML-5-7-7-4 同 Figure UML-5-7-7-1 ，图中关联的构造型改为< >
Figure UML-5-7-7-4 对应的代码
public class A
{
private B itsB;
public void f()
{
itsB.f();
}
};
8. 内部类
Figure UML-5-7-8-1
Figure UML-5-7-8-1 对应的代码
public class A{
private class B{
...
}
};
9. 匿名内部类
UML还未对匿名内部类提供官方支持
一种非官方的表示方法，用有一个< >构造型的嵌入类来表示。
Figure UML-5-7-9-1
Figure UML-5-7-9-1 对应的代码
public class Window
{
public void f()
{
ActionListener l = new ActionListener()
{
//implementation
};
}
};
10. 关联类
关联类能进一步的展示一个特殊的关联如何被实现。
比如：对于多重性关联使用何种容器
Figure UML-5-7-10-1
Figure UML-5-7-10-1 对应的代码
public class Address
{
private Vector itsLines;
};
关联类能够指明的特定形式的引用有
1. 不固定的引用（WeakReference ）
2. 松散的引用（SoftReference）
3. 幻影的引用（PhantomReference）
Java 2 引用类使用指南-学习如何有效地使用 SoftReference、WeakReference 和 PhantomReference
http://www-900.ibm.com/developerWorks/cn/java/j-refs/index.shtml
11. 关联限定符
源对象通过某种类型的关键字或标记与目标对象实例发生对应关联时，使用关联限定符。
Figure UML-5-7-11-1
Figure UML-5-7-11-1 对应的代码
public class LoginServlet
{
private String empid;
public String getName()
{
Employee e = DB.getName(empid);
return e.getName();
}
};
关联限定符使用较少
12. 少用UML远比多用UML好。
4. 第四章 序列图（sequence diagram） 动态图 P43
1. 要点：
1. 不要为每个类，每个方法建立序列图，这样太浪费时间。
2. 序列图应当用于表现对象间的连接而不是具体的算法细节。
3. 序列图不应有大量的对象和消息返回，而应该抓住本质。
4. 尽量不要用序列图去描述每一个小细节。
5. 代码能足够清晰的说明自己时，图是多余的，浪费的。
6. 应该努力是更多的代码能清楚的描述自己，更少的使用图。（即增强代码的可读性）
7. 小序列图比大序列图容易理解，所以更具有实用价值。
8. 高层图比低层图更有用，因为共性比差异多。
9. 白板上的序列图，用于与同事进行表达、交流。
文档中的序列图，用于捕获核心的突出的系统协作。
2. 相关术语：
对象、生命线（life lines）、消息、数据标记（data tokens）、时间（time）、活动（Activation）
3. 生命线
1. 垂立在对象、类或参与者下面的虚线，与时间同方向。代表对象或参与者的生命周期。
2. 区别对象和类的方法：
矩形框中对象名下方有横线，类名下方没有横线。
3. 参与协作的对象或类被放置在序列图的顶部横向排开。
4. 人样图
1. 表示匿名参与者，一般作为消息发起的起点和终点。
2. 并非所有的序列图都有人样图，但大部分都有。
5. 消息
1. 代表一个对象调用另一个对象（或类）的成员函数。
2. 生命线之间的横向箭头，箭头上方是消息名。
3. 消息的参数使用放在箭头下方的数据标记（data tokens）表示，或者放在消息名后面的括号里。
6. 活动（Activation）
1. 可选，大多数情况下不使用
2. 沿着生命线的竖向长条形小框
7. 返回值
表示返回值的横向向左的箭头无须标记名字。
8. 表示创建一个对象的方法：
一个没有标记名字的消息指向一个被创建的对象上。
9. 表示回收一个对象的方法：
一个对象的生命线终止在一个“X”上。
消息箭头指向这个“X”，表明一个对象被GC回收。
10. 表示“循环”的方法：
P49 Figure 4-8
循环表达式的前缀：
*[while id:=idList.next()]
11. 表示“分支”的方法：
P49 Figure 4-8
12. 费时间的消息
1. 不费时间的消息，完全水平的箭头。
2. 费时间的消息，与水平有个夹角的箭头。
13. 异步消息
1. 同步消息，使用实心箭头表示。
2. 异步消息，使用空心箭头表示，将消息发送后可立即获回控制权。
3. 序列图可以发现异步系统中的竞争条件（Race condition）。
14. 表示“多线程”的方法：
P54 Figure 4-12
消息名称前加上线程标记前缀，来显示几个不同的线程控制。
15. 表示“活动对象（active objects）”的方法：
活动对象使用粗体框来表示
16. 表示“向接口发送消息”的方法：
1. 给接口命名对象，然后就像使用一般对象一样来使用。
这里强调对象符合接口，而不是接口的实例化。
P55 Figure 4-15
2. 虽然明确知道对象的类类型，但仍要表示消息是被发送到一个接口上。
P55 Figure 4-16
5. 第五章 用例图 （Use Case） 静态图 P57
1. 概念：
1. 用例是有关动作性（行为性）需求的文本性描述。
2. 一个用例是有关一个系统的行为的一个描述。
这个描述是从一个用户的角度编写的。
3. 一个用例捕获一个事件的可视化序列。
这个事件是一个系统对单个用户的激励（stimulus）的响应过程。
4. 用例不描述系统隐藏着的机制，它只描述那些用户可见的事情。
2. 要点：
1. 诀窍是保持用例的简单。
2. 对于不断发生变化的事情，就不需要过早的去捕获细节。
3. 用例是编写出来的，而不是画出来的。
4. 过早地用用例去记录明天就会发生变化的细节并不值得。
除非这些用例在近几周内会被实现。
可以先将这些用例的名称记下来列成表格，维护着。当它们快被实现时，再填充细节。
5. 所有的UML图中，用例图最容易混淆，也是最没用的。但系统边界图除外。
3. Alistair Cockburn的《有效编写用例》
书中可了解参与者，次要参与者，前置条件，后置条件等用例的其它要素。
4. 系统边界图
1. 用途：
对开发人员提供的信息太少，但可作为向客户讲解的材料。
2. 要素：
1. 长方形表示系统边界。
2. 长方形里面的任何东西都是需要开发的系统的一部分。
3. 长方形外面是与系统交互的参与者（actors）。
4. 参与者是为系统提供激励的系统外实体。
5. 参与者通常是人类用户，也可以是其它系统，甚至是设备，如实时时钟。
6. 长方形里面的用例（带名称的椭圆形）与刺激它的参与者连接，连线上不带箭头。
7. 尽量忽略用例关系，因为用例关系会引起“扩展”还是“泛化”的争论。
6. 第六章 面向对象设计（OOD）原则 P61
1. 学习下面五个设计原则的目的
用来评估一组UML图或一批代码是否被适当地设计。
2. 适当设计的系统：
容易被理解、容易被改变、容易被重用。
表现为没有特别的开发困难，是简单的、扼要的和经济的。
3. 糟糕设计的臭味的不同成分：
1. 僵化性（Rigidity）
难以修改。对一个改动，要修改好几处地方。
2. 脆弱性（Fragility）
对某个部分的修改，会使不相干的部分出问题。
3. 牢固性（immobility）
很难拆分成能重用的组件。
4. 粘滞性（Viscosity）
模块之间结合太紧密，编辑、编译和测试都变得很麻烦。
5. 不必要的复杂性（Needless Complexity）
6. 不必要的重复（Needless Repetition）
存在大量的复制粘贴，代码看起来都很相似。
7. 晦涩性（Opacity）
代码无法清楚的描述自己。
4. 依存关系混乱的代码就像意大利式细面条般
5. 五种设计原则
1. 单一职责原则（SRP）
Single Responsibility Principle
P62
1. 一个类应当只有一个改变的原因
2. 一个类要处理的事情太多，就会散发出脆弱性的臭味。
3. 书中的例子是一个既要计算薪水，又要读写磁盘，还要打印报表的类Employee。
2. 开放－封闭原则（OCP）
Open－Close Principle
P64
1. 应当能够改变一个类的周边环境，而无须改变类本身。
2. 经常违反OCP原则的是GUI
违反OCP的实现，将所有的行为放入一个使用GUI API的类中。
遵循OCP的系统，将GUI的操纵与数据的操作分离。
3. 书中的举例是一个数据与操作分离的GUI实现
P65 Figure 6-6
4. 单元测试的self shunt模式
http://www.objectmentor.com/resources/articles/SelfShunPtrn.pdf
5. 设计遵循OCP原则，就可以改变dialog和model的周边环境到一个测试环境，而无须对dialog和model作任何修改。
6. 使用抽象（指接口和抽象类）是遵循OCP原则的一个关键。
7. 遵循OCP原则的方法：
通常是在编写实际代码之前，编写简单的单元测试。这个单元测试使用Test-First（测试优先）方法进行编写。
3. Liskov替换原则（LSP）
Liskov Substitution Principle
P77
1. 避免造成派生类的方法非法或退化，一个基类的使用者应当不需要知道这个派生类。
2. 基类的使用者，为了使用它们的派生类，应当无须做特别的处理。
这里的特别处理指的是使用instanceof或向下转型（DownCast）操作。
3. 违反LSP原则的两种情况：
1. 当调用一个派生类的成员函数时发生了非法使用，导致不得不抛出异常。
2. 使用一个退化的派生类的方法，退化是指这个方法什么都不实现。
4. 违反LSP问题的解决方法是：
为派生类另外寻找一个基类，而不是勉强从现有的基类派生。
5. 书中的举例是把志愿者类作为类Employee的派生类所产生的麻烦。
4. 依存关系倒置原则（DIP）
Dependency Invertion Principle
P79
1. 用依赖接口和抽象类来替代依赖容易变化的具体类。
2. 遵循DIP原则可以减少变化对系统的影响，减少系统的敏感度。
3. 从抽象类和接口派生出来的具体类比抽象类和接口的改变频繁得多，
所以宁可依赖抽象（指接口和抽象类），也不要依赖那些容易变化的具体类。
如果要继承一个类，就从一个抽象类继承。
如果要持有一个类的引用，就从一个抽象的类引用。
如果要调用一个函数，就从一个抽象函数调用。
4. 容易变化的具体类是：
1. 那些正在开发的具体的类。
2. 那些容易变化的捕获商业逻辑的类。
3. Vector类或String类不算容易变化的具体类。
5. 遵循DIP原则的方法：
为那些容易变化的具体类创建并依赖于接口。
5. 接口隔离原则（ISP）
Interface Separate Principle
P79
1. 给一个对象的每一个使用者一个接口，这个接口仅有使用者需要的方法。
2. 肥类（Fat Class）
一个有着成堆方法的类。
3. 肥类引起的麻烦：
肥类的使用者不使用类的大部分方法，却会因为这些方法的改变而受影响。
4. 遵循ISP原则的方法：
为肥类的使用者提供一个只包含它们需要的方法的接口。
6. 设计原则的应用方法：
1. 试图让系统时时刻刻遵循所有的原则是不明智的。
2. 应用这些原则的最好方法是反应式（reactively）方法:
当第一次觉察到代码里有一个结构性的问题存在时，
或当第一次意识到一个模块的改变被其它模块影响时，
尝试应用这些原则去解决问题。
7. 第七章 dX实践 P83
1. 何为dX实践？
1. dX实践是一套规则，轻量级的开发过程。
2. dX实践其实就是XP（极限编程）实践，XP倒过来就是dX。
3. dX实践是短周期迭代式处理所有事情。
所有事情包括需求分析、设计实现、测试和文档。
短周期（即迭代周期）就是两个星期。
2. 初始探索
1. 第一次迭代探索的是需求，一般不需要花费两周的时间。
2. 客户是负责需求和负责决策的人。
3. 与客户讨论的内容：
1. 系统怎样运作，一些必须的功能。
不用作详细记录，目标是搞清楚系统的整体状况。
2. 识别出用例（Use Case）
把用例名记录在索引卡片上，卡片就是User Story。
卡片上还可记些其它重要信息。
3. 功能特征评估：
1. 对User Story评估，计算系数。
2. 评估方法：
1. 以一个已知Story的评估结果作为基础，根据新的User Story的难易程度进行评估。
2. 用“完美编程”的天数作为标准。
“完美编程”就是不受任何干扰，在极其理想的环境下编程。
3. 评估之后要对User Story进行合并和拆分。
一个User Story的天数应控制在1天到4天之间。
避免高估自己实力，或评估太保守。
4. 花两到三天的时间，很快地粗糙地实现两、三个比较有趣的User Story。
目的是验证评估，获得点数和人天的对应关系。
这里的人天是粗糙实现得到的。保质保量的实现，一般是粗糙实现的3倍。
4. 探索
1. 计算初始速度
初始速度 ＝ （3 乘以 粗糙实现的人天）除以 被粗糙实现的Use Story的总点数。
5. 计划
以计算得到的速度作为标准，计算每次迭代周期中需完成的Story。
6. 发布计划
1. 典型的一次发布周期，包括六次迭代周期即三个月
如果团队有五人，一次迭代周期是两周（十个工作日），
那么一次迭代周期为50人天，一次发布周期为300人天。
2. 一次发布周期可完成的点数＝300人天 × 速度。
3. 客户挑出点数总数为（300人天×速度）的最重要、最有效的User Story，作为发布计划。
7. 迭代计划
1. 一次迭代周期为50人天。
2. 一次迭代周期可完成的点数＝50人天×速度。
3. 把User Story再细分成任务。
这里的任务是单个开发人员能够负责的简单任务，以4到10人小时为单位。
这个细分过程需要客户协助识别重要和次要的用户接口。
4. 细分结束，开发人员挑选符合自己预算的任务。
对于剩余任务要进行分摊。
最后的未决任务要和客户商量是否挪到下一个迭代周期。
直至所有的任务都分配出去。
8. 中点
根据前半段迭代周期中完成任务的点数，对后半段剩下的任务进行调整，取消或增加任务。
9. 速度反馈
1. 迭代周期结束的时间不能变更。
2. 根据实际完成的点数重新计算速度，作为下个迭代周期的依据。
3. 新速度是上一个迭代周期完成的实际点数。
10. 将迭代与管理阶段联系起来
1. “统一过程”项目的四个管理阶段：
1. 初始阶段
确定系统的可行性和商业案例。
2. 细化阶段
确定系统架构并创建一个比较可靠的实现计划。
3. 构造阶段
开始进行系统实现。
4. 移交阶段
安装系统，和用户一起测试（UAT测试）。
11. 一个迭代周期中包括了：
1. 分析需求
2. 设计解决方案
3. 实现解决方案
只考虑当前迭代期间需要处理的User Story。
12. 结对开发
两个开发人员用同一台机器工作，一起处理他们负责的任务。
13. 可验收测试
1. 每个迭代周期开始时，客户和QA一起把User Story充实到Use Case，并为之编写可执行的验收测试案例。
2. 对于程序员验收测试案例就是需求文档。
3. 整个迭代周期中，程序员持续的运行测试案例，以保证能正确的通过验收测试。
14. 单元测试
1. 代码未动，测试先行。
2. 如果有任何一个单元测试没有通过，就不能编写新的产品代码。
3. 极限迭代的过程：
1. 先写一段5到10行的单元测试代码。
2. 然后为了使这段单元测试代码能够编译通过，开始编写并不断充实产品代码。
3. 一旦单元测试通过之后，就可以添加新的代码，开始新的迭代。
4. 一个测试周期通常是1到10分钟。
4. 极限迭代的目的：
无论现在进展到什么程度，几分钟前的产品代码总是可以运行的。
5. 单元测试也是文档的一种形式。
6. 单元测试代码提供的信息有：
1. 如何去调用一个特定的API。
2. 如何创建一个特定的对象。
7. 这种形式的文档是明确的，准确的，可编译的和可执行的。
15. 重构：
1. 只要用大量的单元测试和验收测试作靠山，就可以放心大胆的去修改那些需要修改的任何部分。
2. 在不改变程序的行为的前提下，改进程序的内部结构就是重构。
3. 每小时左右的编程结束后，就是几分钟小碎步式的重构，然后测试。
4. 绝不能把烂代码留到第二天。
16. 开放式办公环境：
1. 成员之间有着非常频繁的交流和沟通，可以快速的互相提问，得到最快的响应和建议。
做到互相依靠，互看代码。
方便结对编程。
17. 持续集成：
1. check in的规则：
只有通过单元测试和验收测试的代码才能check in。
2. 持续性的集成可以避免项目进度到了尾声才来一个非常庞大的终极集成。
18. 文档：
1. Martin文档第一要律：
只编写那些真正需要的有意义的文档。
2. 不需要专门用类图来捕获所有的需求。
3. 不需要在序列图里捕获所有的Use Case。
4. 只有真正需要使用这些工具的时候才使用，否则就让它们一边歇着去。
8. 第八章 包（Packages）P92
1. Java的两类重要的包：
1. 源代码包。package
2. 二进制组件。.jar
2. Java Packages
1. Java Packages是名称空间（Name Spaces）
它们允许程序员创建小的私有空间，以便在其中声明类。
这些类的名字不会与其它包中同名的类发生冲突。
2. UML中表示一个包的几种方式：
1. 包的图标是一个矩形框，在其顶部有一个标签，像一个文件夹。
完整的包名显示在矩形框中间。
P92 Figure 8-1
2. 也可以将完整的包名写在矩形框上的标签中。
剩下大的矩形框中列出包中定义的所有类。
P92 Figure 8-2
3. 可以使用包含关系（contains）显示包的嵌套结构。
P93 Figure 8-3
3. 依赖（Dependencies）
在同一个包中的代码常常依赖另一个包中的代码。
在UML中用依赖关系（dependency）表示这种依赖性。
P93 Figure 8-4
import不会创建真正的依赖关系，只有调用函数才会创建依赖关系。
3. 二进制组件.jar文件（Binary Components）
1. UML中表示一个.jar组件的方式
P94 Figure 8-5
2. 一个组件常常包含一个或多个包，所以组件之间的依赖关系通常是包之间依赖关系的子集。
4. 包设计的原则（Principles of Package Design）
1. 遵循原则的作用：
1. 易变的类放在一起。
2. 将因为各种原因需要被改变的类分离开。
3. 将经常改变的类和不常变化的类独立开。
4. 分离系统的高层结构和底层实现细节。
2. 发布/重用等价原则（The Release/Reuse Equivalency Principle）（REP）
1. 被重用的一组类应该放到一个包中。然后这个包被那些重用它们的开发人员发布和跟踪。
2. 创建一个包是为了方便别人重用。
3. 重用的粒度就是发布的粒度。
重用的最小的东西，是值得别人去发布和跟踪的。
3. 公共闭合原则（The Common Closure Principle）（CCP）
1. CCP相当于OOD的单一责任原则（SRP）
2. 由于相同原因要被修改的类放在一个包中。
4. 公共重用原则（The Common Reuse Principle）（CRP）
1. CRP相当于OOD的接口隔离原则（ISP）
2. 应该尽可能地将只被一个客户使用的包与被多个不同客户使用的包分开。
3. 避免对包中某个类的修改会影响到其它没有使用该类的客户。
5. 非循环依赖原则（The Acyclic Dependencies Principle）（ADP）
1. 包的循环依赖将导致编译和开发方面的问题。
2. 应避免在依赖图中出现循环依赖。
3. 可以使用JDepend等工具，来检查是否存在循环依赖。
6. 稳定依赖原则（The Stable Dependencies Principle）（SDP）
1. 包不应该依赖那些比它们自己更不稳定（更易改变）的包。
2. 每个包所依赖的包应当比依赖它们的包更稳定。
3. 如果一个包有多个指向它的依赖，而它自己又依赖一个易发生改变的包，其结果就导致这个包很难改变。
7. 稳定抽象原则（The Stable Abstractions Principle）（SAP）
1. SAP相当于OOD的开放－封闭原则（OCP）
2. 为了保证稳定的包易被控制，稳定的包应该是抽象的。
越稳定的包应该越抽象。
抽象类和接口的比例越大的包就越抽象。
3. SDP原则和SAP原则相结合就成了包版本的依存关系倒置（DIP）原则。
4. 结合SDP原则和SAP原则可得出：
1. 稳定性随指向它的依赖的增多而增加。
2. 抽象性应该随稳定性的增加而增加。
3. 所以，抽象性应该随指向它们的依赖的增多而增加。
5. 包依赖图对于解决依赖循环问题和判断编译顺序都很有帮助。
9. 第九章 对象图（Object Diagrams） P98
1. UML对象图就像系统运行时的一个快照。
2. 对象图包含的信息有：
1. 系统在某个特定时刻，或者系统处于某个特定状态时的内部结构。
2. 对象和关系被实际使用的方式。
3. 系统根据不同输入的变化情况。
3. 对象图被使用的情况很少。
4. 对象图所用的标记与类图相同。
5. 对象图的另一个有用之处是在多线程系统中。
1. 主动对象（Active Object）
用粗线条框表示。
2. 主动对象就像是线程的控制者。
它们包含有控制线程的方法，如：Start、Stop、SetPrioring等。
P102 Figure 9-4
6. 在多线程系统中，对象图比类图更具有表达力的原因：
这段程序结构是在运行时建立的，这是一种关于对象的结构而不是关于类的结构。
7. 很多对象图能从类图直接推断出来，所以对象图应用的比较少。
10. 第十章 状态图（Stat Diagrams）P103
1. 状态转换图（State Transition Diagrams）（STD）
P103 Figure 10-1
1. 状态
使用圆形拐角矩形表示。
2. 状态的名字
放在圆形拐角矩形上面的框格中。
3. 进入或退出状态时触发的动作。
放在圆形拐角矩形下面的框格中。
4. 状态之间的转换
使用箭头表示，箭头指向表示从原状态到目标状态。
5. 状态转换箭头上标记：
1. 触发转换的每一个事件的名称。
2. 当转换被触发时执行的动作。
6. 初始伪状态（Initial Pseudo State）
使用实心的黑色圆圈表示。
标明了有限状态机生命周期的起始状态。
7. 超状态（Super State）
超状态适用于有多个状态要用相同的方式响应某些相同事件的情况。
画一个超状态把那些类似的状态括起来，然后只需从超状态画一个状态转换箭头，
来代替从每一个状态画转换箭头。
超状态的转换可以被子状态的转换重载。
P106 Figure 10-5
超状态和一般的状态一样有entry、exit和专用事件。
注意：超状态和其子状态的事件调用顺序。
P106 Figure 10-6
8. 专用事件
表示状态的圆形拐角矩形的下面框格中包含了多对事件和动作。
事件和动作的书写形式：event/action
两个标准的事件是entry和exit。
可以自定义事件。
9. 初始伪状态和结束伪状态。
初始伪状态不需要有事件，但可以有一个动作。
这个动作是在有限状态机被创建以后，第一个被调用的动作。
转换到结束伪状态时的动作是有限状态机最后执行的一个动作。
10. 有限状态机图的使用：
对于日趋完善中（即频繁变更中）的系统，
在文档中创建STTS（State Transition Tables）要好于使用STDS（State Transition Diagrams）。
在开发和维护有限状态机方面，使用文本语言比图形更加简单。
--------------------------------------------------------------------------------
版权所有：UML软件工程组织