UML与设计模式

1、关联关系

        关联关系用于描述不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。关联关系是一种静态关系，通常与运行状态无关，而是由“常识”、“规则”、“法律”等因素决定的，因此关联关系是一种强关联的关系。关联关系用来定义对象之间的静态、天然的结构。在最终的代码里面，关联对象通常是以实例变量（成员变量）的形式实现的。与下述的依赖关系相比，关联的两个对象通常不会直接使用，尽管它们相互指导对方的的存在，但一般都是由外部对象来访问的。

2、依赖关系

        依赖关系是一条带箭头的虚线表示的，它描述一个对象在运行期间会使用到另一个对象的关系。与关联关系不同的是，依赖关系是一种临时性关系，通常都是在运行期产生，并且随着场景的不同，依赖关系也可能发生变化。依赖关系表达的是对象之间临时性的、动态的关系。一般而言，依赖关系在最终的代码里面体现为类构造方法、类方法等的传入参数。与关联关系相比，依赖关系除了临时知道对方外，还会使用对方的属性或者方法。从这个角度讲，被依赖的对象改变会导致依赖对象的修改。

3、实现关系

        实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现（或称用例实例）来表示，而用例实现与基本用例之间就构成了实现关系。换言之，每个实现途径都实现了基本用例的业务目标。

4、泛化关系

        泛化关系是用一条带空心箭头的直线表示的。泛化关系可用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。泛化关系表示一个类对另一个类的继承。继承而得的类称为后代。被继承的类称为祖先。继承意味着祖先的定义（包括任何特征，如属性、关系或对其对象执行的操作）对于后代的对象也是有效的。泛化关系是从后代类到其祖先类的关系。

5、聚合关系

        聚合关系是用一条带空心菱形箭头的直线表示的，聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语义，与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。

6、组合关系

组合关系是用一条带实心菱形箭头的直线表示的，组合关系用于类图，特别用于表示实体对象关系，表达整体拥有部分的语义，组合关系是一种强依赖的特殊聚合关系，如果整体不存在了，则部分也将消亡。

        节点是带有至少一个处理器、内存以及可能还带有其他设备的处理元素。在实际工作中，一般说来服务器、工作站或客户机都可以称为一个节点。节点是应用程序的部署单元。节点元素特别用于部署视图，描述应用程序在物理结构上是如何部署在应用环境中的，是一种包括软、硬件环境在内的拓扑结构描述。

        实际上，由于人脑对信息的处理能力是有限度的，如果信息量超过了人脑的处理能力，人就会失去对这个事物的理解能力。因此，越是具体的表达信息量越大，越接近人脑的处理极限，人们的理解能力越是下降（这也是面向过程方法为什么困难的原因之一）。对面向对象方法来说，这时就需要提高抽象层次，用一个新的概念来概括一部分相关的信息，一旦人们像接受了光年概念一样消化了这个新的概念，理解起来就变得容易了。同时，这个新的概念就屏蔽了（或者说封装了）更多具体的信息。抽象层次越高，被屏蔽的信息也就越多，信息量越少，也就越容易理解和处理。这就是面向对象比面向过程具有优势的原因。

        抽象有两种方法，一种是自顶向下，另一种是自底向上。自顶向下的方法适用于让人们从头开始认识一个事物，自底向上的方法适用于在实践中改进和提高认识。在软件开发过程中，主体上应当采用自顶向下的方法，用少量的概念覆盖系统需
求，再逐步降低抽象层次，直到代码编写。同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验来改进较高层次的概念以提升软件质量。

7、对象分析方法

7.1 一切皆是对象

        在面向对象的眼里，一切有名字的东西都是对象，都应当使用对象的观点来看待它、分析它。哪怕这个东西的名字叫某某业务流程，它也仍然应当看作是一个对象，而不是一个过程。这意味着，无论什么时候都应当采用接下来讲述的一些观点和方法来看待和分析事物。

7.2对象都是独立的

        独立性是面向对象的一大特点，承认对象的同时就接纳了这一观点。对象与对象 之间是天然独立的，只是在某个特定的场景下，它们的某一个特定的实例才相互联系 在一起。我们获取和分析对象的手段经常是通过分析某个场景，但是需要知道，对象是离散的，它不是因为该场景而存在的。场景中的对象只是对象“映射”到该场景中的一个侧面，我们称之为对象实例。换言之，通过一个场景，我们仅能得到对象的一个侧面的信息，如图2.4所示，如果以每一个场景为坐标（维度），那么对象实例就是对象在该坐标上的投影。

7.3、对象都具有原子性

        无论在什么时候，在同一抽象层次上，在分析过程中都应当将对象视为一个不可分割的原子，哪怕这个对象的规模很大。例如在分析一个商业过程的时候，对象的规模（粒度）大到如银行、工厂、商场的程度，不论它有多么巨大，只要我们认为它是对象，它与其他对象交互时就是一个整体，不能分割。原子性是抽象层次有意义的重要保证，一旦破坏了原子性，则表示在同一抽象层次上的对象不具备同样的粒度，这使得分析工作陷入混乱。我们应当将分析过程中得到的所有对于对象的认识附加在对象边界上，在实现这个对象之前不理会其内部的细节。这称之为面向接口编程。

7.4、对象都是可抽象的

        对象有着很多个不同的方面。一般来说，对象参与一个场景时会展现出某一个方面。总可以将对象的某一个方面抽象出来，让其作为对象的一个代表来参与场景交互。通常这种抽象会以接口来命名。在分析过程中，得到的任何一个对象都有特定的方面可作为抽象。因为对象总是从场景分析中得到的，它在场景中肯定展现了一个方面。对象所具有的方面，或者说对象所参与的场景越多，对象越有抽象价值，反之则越没有抽象价值。因此在分析过程中，应当关注于那些参与了很多场景的对象，它们往往是分析设计中的重点以及成败关键。

7.5、对象都有层次性

        对象是有着抽象层次的。层次越高，其描述越粗略但适应能力越广；层次越低则描述越精确但适应能力越下降。在分析过程中，应当根据问题领域的复杂程度设定多个抽象层次，在每个层次上使用适合的抽象程度的对象描述。这将有助于显著地减少分析的难度和工作量。不论是在需求、分析还是设计过程中，都应当具备抽象层次的观点。从需求到设计的过程已经是几个不同的抽象层次。

以上内容摘自《大象 Thinking in UML》