第16章 对象图
有时，呈现出系统在某个特定时刻的状态是非常有用的。和一个正在运行系统的快照类似。UML对象图展示了在一个给定时刻获取到的对象、关系和属性值。
不过，你应该对花太多的对象图保持警惕。在大部分的情况下，它们都可以从相应的类图中直接推导出来，因此没有多少用处。
第17章 用例
在所有的UML图中，用例图是最令人迷惑也是最没有用处的。我建议出来系统边界外，忽略掉所有其他的图。系统边界图示例如下：
大矩形是系统边界。矩形内的所有东西都是将要开发的系统的组成部分。矩形外面是操作系统的参与者。参与者可以是人也可以是其他系统或设备。
第18章 顺序图
顺序图示UML用户最常绘制的动态模型。但是不要为每个方法都创建顺序图。 当你需要立即向某个人解释一组对象的协作方式或者当自己想要把这种协作关系可视化时，才使用顺序图。把顺序图当作一种偶尔使用以磨练自己分析能力的工具，不要把它们当作必须的文档。
18.1 基础知识
18.1.1 对象、生命线、消息及其他
典型的顺序图：
时间轴是垂直方向的，消息出现的位置越低，就越晚发送。注意GetEmployee消息中e变量的使用，Employee和e其实是同一个对象。GetEmployee的返回值就指向Employee对象的引用。EmployeeDB是一个类，所以它的名字下面没有下划线。这意味着GetEmployee只能是一个静态方法。
18.1.2 创建和析构
创建一个对象，画一条线终结在要创建的对象，如下：
对应的代码：
public class ShapeFactory { public Shape MakeSquare() { return new Square(); } }
把一个对象释放给垃圾回收器：
对应代码：
public class TreeMap { private TreeNode topNode; public void Clear() { topNode = null; } }
18.1.3 简单循环
画简单循环的方法是在需要重复发送消息的周围画一个框。然后在一个中括号中包含循环条件。
18.1.4 时机和场合
不要绘制具有大量对象和消息的顺序图。没人能够理解，也没有人愿意去看。这是一种巨大的时间浪费。如果觉得顺序图是必要的，问一下自己是否能够把它分解成以小组场景。
团队应该致力于创建出具有表达力、易读的代码。代码越是能够描述自己，你就越不需要图示，整个项目就越好。
一般来讲，高层试图要比低层试图更有用一些。
18.2 高级概念
18.2.1 循环和条件
18.2.2 耗费时间的消息
以电话呼叫为例子，正常的呼叫电话如下：
失败的电话呼叫如下：
18.2.3 异步消息
示例如下：
18.2.4 多线程
示例如下，T1,T2是线程的名字：
18.2.5 主动对象
一个具有独立内部线程的对象，这种对象叫做主动对象。它们显示为粗体边框，如下所示：
18.2.6 向接口发送消息
示例如下：
通过接口向其派生类型发送消息：
18.3 结论
顺序图就是一个工具。要按照其设计意图使用。在白板前使用它们来实时地和他人进行沟通。在简短的文档中使用它们记录系统中的那些核心、重要的协作。
就顺序图而言，过少比过多要好。你总可以在以后需要时再画一幅顺序图。
摘自：《敏捷软件开发：原则、模式与实践(C#版)》Robert C.Martin Micah Martin 著
转载请注明出处：