我对面向对象编程的目标从来就不是复用。相反，对我来说，对象提供了一种处理复杂性问題的方式。这个问題可以追溯到亚里士多德：您把这个世界视为过程还是对象？在面向对象兴起运动之前，编程以过程为中心，例如结构化设计方法。然而，系统已经到达了超越其处理能力的复杂性极点。有了对象，我们能够通过提升抽象级别来构建更大的、更复杂的系统——我认为，这才是面向对象编程运动的真正胜利。

  作者本人认同这个世界的本质是由对象组成的，平时看上去相互无关的独立对象在不同的驱动力和规则下体现出不同的运动过程，然后这些过程便展现出了我们这个生动的世界。在面向过程的眼中，世界的一切都不是孤立的，它们相互地紧密联系在一起，缺一不可，互相影响，互相作用，并形成一个个具有严格因果律的小系统； 而更多的小系统组成了更大的系统， 所有小系统之间的联系也是紧密和不可分割的。

闲话：今天你 OO 了吗？
  如果你的分析习惯是在调研需求时最先弄清楚有多少业务流程，先画出业务流程图，然后顺藤摸瓜，找出业务流程中每一步骤的参与部门或岗位，弄清楚在这一步参与者所做的事情和填写表单的结果，并关心用户是如何把这份表单传给到下一个环节的。那么很不幸，你还在做面向过程的事情。
  如果你的分析习惯是在调研需求时最先弄清楚有多少部门，多少岗位，然后找到每一个岗位的业务代表，问他们类似的问題：你平时都做什么？这件事是谁交办的？做完了你需要通知或传达给谁吗？做这件事情你都需要填写些什么表格吗？…那么恭喜你，你已经 OO 啦！

一 概述

  UML这三个字母的全称是Unified Modeling Language，直接翻译就是统一建模语言，简单地说就是一种有特殊用途的语言。
  UML 又称标准建模语言，是始于1997年的一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。UML 感兴趣的可以阅读UML 1规 范，包含了 UML 的所有知识内容。
  注：OMG，Object Management Group 对象管理组织
  UML 是一种建模用的语言，而所有的语言都是由基本词汇和语法两个部分构成的，UML 也不例外。UML 定义了一些建立模型所需要的、表达某种特定含义的基本元素，这些元素称为元模型，相当于语言中的基本词汇，例如用例、类等。另外，UML 还定义了这些元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界；这些规则和图形称为表示法或视图(View)，相当于语言中的语法。如同我们学习任何一种语言一样，学习 UML 无非是掌握基本词汇的含义，再掌握语法，通过语法将词汇组合起来形成一篇有意义的文章。UML与其他自然语言和编程语言在原理上并无多大差别，无非是 UML 这种语言是用来写说明文的，用自然界和计算机逻辑都能够理解的表达方法來说明现实世界。

二 从现实世界到业务模型

  那么 UML 是不是提供了这样的元素来为现实世界建立模型呢？是的。
  第一，UML 采用称之为参与者(actor)的元模型作为信息来源提供者，参与者代表了现实世界的“人”。参与者是模型信息来源的提供者，也是第一驱动者。换句话说，要建立的模型的意义完全被参与者决定，所建立的模型也是完全为参与者服务的，参与者是整个建模过程的中心。UML 之所以这样考虑，是因为最终计算机的设计结果如果不符合客户需求，再好的设计也等于零。与其在建立计算机系统后因为不符合系统驱动者的意愿而推到重来，还不如在一开始就从参与者的角度为将来的计算机系统规定好它必须实现的那些功能和必须遵守的参与者的意志，由驱动者来检验和决定将来的计算机系统要如何运作。
  第二，UML 采用称之为用例(use case)的一种元模型来表示驱动者的业务目标，也就是参与者想要做什么并且获得什么。这个业务目标就是现实世界中的“事”。而这件事是怎么做的，依据什么规则，则通过称之为业务场景(business scenario)和用例场景(use case scenario)的 UML 视图来描绘的，这些场景便足现实世界中的“规则”。最后，UML 通过称之为业务对象模型(business object model)的视图来说明在达成这些业务目标的过程中涉及到的事物，用逻辑概念来表示它们，并定义它们之间的关系。业务对象模型则代表了现实世界中的“物”。

三 从业务模型到概念模型

  现实世界被业务模型映射并且记录下来，但这只是原始需求信息，距离可执行的代码还很遥远，必须把这些内容再换成一种可以指导开发的表达方式。UML 通过称之为概念化的过程(Conceptual)来建立适合计算机理解和实现的模型，这个模型称为分析模型(Analysis Model)。分析模型介于原始需求和计算机实现之间，是一种过渡模型。分析模型向上映射了原始需求，计算机的可执行代码可以通过分析模型追溯到原始需求；同时，分析模型向下为计算机实现规定了一种高层次的抽象，这种抽象是一种指导，也是一种约束，计算机实现过程非常容易遵循这种指导和约束来完成可执行代码的设计工作。
  事实上分析模型在整个分析设计过程中承担了很大的职责，起到了非常重要的作用。绘制分析模型最主要的元模型有：

• 边界类(boundary)。边界是面向对象分析的一个非常重要的观点。从狭义上说，边界就是大家熟悉的界面，所有对计算机的操作都要通过界面进行。从广义上说，任何一件事物都分为里面和外面，外面的事物与里面的事物之间的任何交互都需要有一个边界。比如参与者与系统的交互，系统与系统之间的交互，模块与模块之间的交互等。只要是两个不同职责的簇之间的交互都需要有一个边界，换句话说，边界决定了外面能对里面做什么“事”。在后续的章节中，读者会感受到边界的重要性，边界能够决定整个分析设计的结果。
• 实体类(entity)。原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML 采用实体类来重新表达业务实体。实体类可以采用计算机观点在不丢失业务实体信息的条件下重新归纳和组织信息，建立逻辑关联，添加那些实际业务中不会使用到，但是执行计算机逻辑时需要的控制信息等。这些实体类可以看作是业务实体的实例化结果。
• 控制类(control)。边界和实体都是静态的，本身并不会动作。UML 采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。从 UML 的观点看来，边界类和实体类之间，边界类和边界类之间，实体类和实体类之间不能够直接相互访问，它们需要通过控制类来代理访问要求。这样就把动作和物体分开了。考虑一下，实际上在现实世界中，动作和物体也是分开描述的。

  分析类也是应用这个道理来把业务模型概念化的。由于所有的操作都通过边界类来进行，能做什么不能做什么由边界决定，所以边界类实际上代表了原始需求中的“事”；实休类则由业务模型中的领域模型转化而来，它代表了现实世界中的“物”；控制类则体现了现实世界中的“规则”，也就是定语；再加上由参与者转化而来的系统的“用户”，这样一来，“人”也有了。

四 从概念模型到设计模型

  在大多数情况下，实现类可以简单地从分析类映射而来。在设计模型中，概念模型中的边界类可以被转化为操作界面或者系统接口；控制类可以被转化为计算程序或控制程序，例如工作流、算法体等；实体类可以转化为数据库表、XML文档或者其他带有持久化特征的类。

五 建模

  建模(Modeling)，是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。
  建模包含两个问题，一个是怎么建，另一个是模是什么。
  第一个问题“怎么建”，依赖于方法论，再上升一点到哲学高度就是认识论。
  在软件建模上，试图为现实世界建模的时候，首先要决定的是抽象角度，即建立这个模型的目的是什么。一旦抽象角度确定，剩下的事情就变得顺理成章，而不再是杂乱无章。
  不论在需求分析、系统分析还是系统设计上，一定要学会采用面向对象的方法，在面对问题领域的时候首先不要决定去通盘考虑，而是找出问题领域里包含的抽象角度。如果你把抽象角度都找全了，并且这些角度都分析淸楚了，问题领域也就解决了。里然这些抽象角度在思考的时候可能是互不关联的。
  具体来说，做需求的时候，首要目标不是要弄清楚业务是如何一步一步完成的，而是要弄清楚有多少业务的参与者？每个参与者的目标是什么？参与者的目标就是你的抽象角度。与分析一个复杂的业务流程相比，单独分析参与者的一个个目的要简中得多。实际上，这就是用例！这也就是为什么用例会成为业务建模的方法的原因之一。
  第二个问题“模是什么”，则依赖于确定了抽象角度下的场景模拟。
  一个由抽象角度确定了的目标需要由静态的事物加上特定条件下产生的一个特定的场景来完成，即静态的事物(物)+特定的条件(规则)+特定的动作(参与者的驱动)=特定的场景(事件)。

问题领域 = ${\sum }_1^n$ 抽象角度
抽象角度 = 问题领域边界之外的参与者的业务目标 = 业务用例
业务用例= ${\sum }_1^n$特定场景
特定场景 = 静态的事物 + 特定的条件 + 特定的动作 或者
特定的事 = 特定的事物 + 特定的规则 + 特定的人的行为

六 用例驱动

  用例驱动是统一过程的重要概念，或者说整个软件生产过程就是用例驱动的。用例驱动软件生产过程是非常有道理的。让我们再次回顾建模公式，很容易得出一个推论，要解决问题领域就要归纳出所有必要的抽象角度(用例)，为这些用例描述出可能的特定场景，并找到实现这些场景的事物、规则和行为。再换个说法，如果我们找到的那些事物、规则和行为实现了所有必要的用例，那么问题领域就被解决了。总之，实现用例是必须做的工作，一旦用例实现了，问题领域就解决了。这就是用例驱动方法的原理。
  在实际的软件项目中，一个软件要实现的功能通过用例来捕获，接下来的所有分析、设计、实现、测试都由用例来驱动，即以实现用例为目标。在统一过程中，一个用例就是一个分析单元、设计单元、开发单元、测试单元甚至部署单元。在统一过程中用例能够驱动的不仅仅是分析设计，如图的用例驱动视图，它来自统一过程。

  在统一过程中，用例捕获了系统的功能性需求。参照建模公式，我们确定它代表了软件系统要解决的问题领域。以下内容部分摘自统一过程的官方文档，用例可以驱动的内容包括：
■ 逻辑视图
  系统只有一个逻辑视图，该视图以图形方式说明关键的用例实现、子系统、和类，它们包含在构架方面具有重要意义的行为，即建模公式中的那些“人”、“事”、“物”、“规则”是如何分类组织的。
■ 进程视图
  为了便于理解系统的进程组织，在“分析设计”工作流程中使用了名为进程视图的构架视图。系统只有一个进程视图，它以图形方式说明了系统中进程的详细组织结构，其中包括类和子系统到进程和线程的映射，即建模公式中的那些“人”、“事”、“物”、“规则”是如何交互的，它们的关系如何。这个视图便是我们常说的分析设计视图。
■ 部署视图
  系统只有一个部署视图，它以图形方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布，即建模公式中的那些“人”、“事”、“物”、“规则”是如何部署在物理节点(主机、网络环境)上的。
■ 实施视图
  实施视图的作用是获取为实施制定的构架决策。实施视图通常包括以下内容：
  > 列举实施模型中的所有子系统。
  > 描述子系统如何组织为层次和分层结构的构件图。
  > 描述子系统间的导入依赖关系的图解。
  实施视图用于：
  > 为个人、团队或分包商分配实施工作。
  > 估算要开发、修改或删除的代码数量。
  > 阐明大规模复用的理由。
  > 考虑发布策略。
  也就是：建模公式中的那些“人”、“事”、“物”、“规则”如何构成系统的“零部件”，以及我们如何组织人力生产和组装这些“零部件”以建成最终系统。

七 抽象层次

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

八 视图

  用很多个不同的视图去展示软件这些不同的方面——静态的、动态的、结构性的、逻辑性的等——才能够说建立了一个完整的模型。为了说明这些不同的方面，UML 里定义了用例图、对象图、类图、包图、活动图等不同的视图。这些视图从不同的方面描述了一个软件的结构和组成，所有这些视图的集合表达了一个软件的完整含义。所以，建模最主要的工作就是为软件绘制那些表达软件含义的视图来完整地表达软件的含义。
  视图和视角是两个被忽略的关键概念，对建立一个好的模型起着很重要的作用。为特定的信息
选择正确的视图，为特定的干系人展示正确的视角并不容易，需要因时因地因人制宜。

九 对象分析方法

  ■ 一切都是对象
  在面向对象的眼里，一切有名字的东西都是对象，都应当使用对象的观点来看待它、分析它。
  ■ 对象都是独立的
  独立性是面向对象的一大特点，承认对象的同时就接纳了这一观点。对象与对象之间是天然独立的，只是在某个特定的场景下，它们的某一个特定的实例才相互联系在一起。
  获取和分析对象的手段经常是通过分析某个场景，但是需要知道，对象是离散的，它不是因为该场景而存在的。场景中的对象只是对象“映射”到该场景中的一个侧面，称之为对象实例。
  要深入了解对象，经常需要分析很多个该对象的实例所参与的场景，以获得对象的多个侧面，再通过归纳整理这些对象的多个实例抽象出对象的一般特性。这就是对象的分析方法，同时也是使用 UML 来为对象建模时所采用的方法。对象来源于场景分析，场景分析越多，我们对对象的了解越多，越精确。
  从每个场景看到的仅是对象映射到该场景的一个方面，或者说是一个实例，它仅仅是对象分析的开始。请记住，当采用面向对象的方法时，在需求、分析、设计过程中，你所得到的任何一个有名字的东西，不论是用例、类、包、组件等都是独立于那个场景的，不要将对象局限在那个场景中。对象的独立性带来的正是对象的可抽象能力和可扩展能力。
  ■ 对象都具有原子性
  ■ 对象都是可抽象的
  对象有着很多个不同的方面。一般来说，对象参与一个场景时会展现出某一个方面。总可以将对象的某一个方面抽象出来，让其作为对象的一个代表来参与场景交互。通常这种抽象会以接口来命名。在分析过程中，得到的任何一个对象都有特定的方面可作为抽象。因为对象总是从场景分析中得到的，它在场景中肯定展现了一个方面。
  对象所具有的方面，或者说对象所参与的场景越多，对象越有抽象价值，反之则越没有抽象价值。因此在分析过程中，应当关注于那些参与了很多场景的对象，它们往往是分析设计中的重点以及成败关键。
  ■ 对象都有层次性
  对象是有着抽象层次的。层次越高，其描述越粗略但适应能力越广；层次越低则描述越精确但适应能力越下降。

十 UML 核心元素

1 版型

  在 UML 里有一个概念叫版型(stereotype)，有些书里也称为类型、构造型。这个概念是对一个 UML 元素基础定义的扩展，在同一个元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。

2 参与者

  actor 是在系统之外与系统交互的某人或某事物。
  参与者位于边界之外
  参与者可以非人
  查找参与者时请注意，参与者一定是直接并且主动地向系统发出动作并获得反馈的，否则就不是参与者。
  业务主角(business actor)是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。业务主角是与业务系统有着交互的人和事物，他们用来确定业务范围。业务主角是参与者的一个版型，所以业务主角必须遵守参与者的所有定义。

  所以在初始需求阶段，请务必使用业务主角，时时牢记业务主角是客户实际业务里的参与者，没有计筇机系统，没有抽象的计算机角色。业务主角必须在实际业务里能找到对应的岗位或人员。
  业务工人的作就是完成主角的业务目标，因此不需耍为他们建立业务模型，他们只在主角的业务模型中出现。业务工人虽然不需要建立业务模型，但是他们是业务模型中非常重要的部分，经常出现的地方是领域模型和用例场景。缺少了他们业务模型就不完整，甚至不能运行。

  涉众(stakeholder)，也称为千系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。涉众虽然与这个系统有利益相关，但并不是所有的涉众都是系统的参与者。参与者是涉众代表。参与者对系统的要求直接影响系统的建设，他们的要求就是系统需求的来源。参与者通过对系统提出要求来获得他所代表的涉众的利益。
  用户(user)，是指系统的使用者，通俗一点说就是系统的操作员。用户是参与存的代表，或者说是参与者的实例或代理。并非所有的参与者都是用户，但是一个用户可以代理多个参与者。
  角色(role) 是参与者的职责。角色是一个抽象的概念，从众多参与者的职责中抽象出相同的那一部分，将其命名而形成一个角色。一个角色代表了系统中的一类职责。角色一般适合用在概念阶段的模型里，以表达业务的逻辑理解。另外，由于一个用户可以代理多个参与者，因此一个用户可以拥有多个职责，也就是可以被指定多个角色。

3 用例

  用例是一种把现实世界的需求捕获下来的方法。官方文档对用例是这样定义的：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。
  ■ 用例是相对独立的
  ■ 用例的执行结果对参与者来说是可观测的和有意义的
  ■ 这件事必须由一个参与者发起。 不存在没有参与者的用例， 用例不应该自动启动， 也不应该主动启动另一个用例
  ■ 用例必然是以动宾短语形式出现的
  ■ 一个用例就是一个需求单元、 分析单元、 设计单元、 开发单元、 测试单元， 甚至部署单元
  在业务建模阶段，用例的粒度以每个用例能够说明一件完整的事情为宜，即一个用例可以描述一项完整的业务流程。这将有助于明确需求范围。
  在用例分析阶段，即概念建模阶段，用例的粒度以每个用例能描述一个完整的事件流为宜。可理解为一个用例描述一项完整业务中的一个步骤。需要注意的是，这个阶段需要采用一些面向对象的方法，归纳和抽象出业务用例中的关键概念模型并为之建模。
  在系统建模阶段，用例视角是针对计算机的，因此用例的粒度以一个用例能够描述操作者与计算机的一次完整交互为宜。实际上，用例粒度的划分依裾(尤其是业务用例）最标准的方法是以该用例是否完成了参与者的某个完整目的为依据的。请记住一点，用例分析是以参与者为中心的，因此用例的粒度以能完成参与者目的为依据。不论粒度如何选择，必须把捤的原则是在同一个需求阶段，所有用例的粒度应该是同一个量级的。
   用例的定义就是由参与者(actor)驱动的，并且给参与者提供可观测的有意义的结果的一系列活动的集合，用例的来源就是参与者对系统的期望。所以发现用例的前提条件是发现参与者；而确定参与者的同时就确定了系统边界。
  用例是捕获功能性需求的，但是有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。把用例当作功能点的做法实际是在做面向过程的分析。抛开面向对象还是面向过程不说，虽然功能和用例很类似，但是从本质上来说功能和用例是完全不同的。
  使用者观点告诉需求收集人员，他希望这个系统是什么样，他将怎样使用这个系统，希望获得什么结果。那么软件只需耍按照使用者的要求提供一个实现，就不会偏离使用者的预期。至于功能性观点和结构性观点，则可以通过使用者观点推导出来。使川者观点实呩上就足用例的观点。一个用例是一个参与者如何使用系统，获得什么结果的一个集合，通过分析用例，得出结构性的和功能性的内容，最终实现用例，也就实现了使用者的观点。
  在实际应用中，对用例使用的另一个误区是混淆目标和完成目标的步骤。一个用例是参与者对目标系统的一个愿望，一个完整的事件。为了完成这个事件需要经由很多步骤，但这些步骤不能够完整地反映参与者的目标，不能够作为用例。
  但是，步骤也是可以作为用例的。在概念建模阶段，由于需求已经捕获，在对需求进行分析时，实际上我们己经进入了用例的内部。进入用例的内部意味着边界己经改变，而边界的改变必然导致参与者也在改变。
  业务用例(business use case) 是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时应当使用这种版型。请注意业务用例业务用例只是普通用例的一个版型，并不是另一个新的概念，因此业务用例具有普通用例的所有特征。

  业务用例实现(business use case realization)，也称为业务用例实例，是用例版型中的一种，专门用于需求阶段的业务建模。在为业务领域建立模型时采用这种版型。

  概念模型用来获取业务模型中的关键概念，分析出业务模型中的核心业务结构以得到一个易于理解的业务框架。作为概念模型中的核心元素，概念用例用来获取业务用例中的核心业务逻辑，这些核心业务逻辑揭示了业务模式，成为业务架构的重要指导。

  系统用例是用来定义系统范围、获取功能性需求的。因此，系统用例的含义就足，系统用例是软件系统开发的全部范围，系统用例是我们得到的最终需求。

4 业务实体

  业务实体是类(class)的一种版型，特别用于在业务建模阶段建立领域模型。业务实体是业务模型中非常重要的一个因素，它为问题领域中的关键概念建立概念化的理解，是人们认识问题领域的重要手段。

5 包

  领域包

  子系统包

  组织结构包

  层包

5 分析类

  分析类用于获取系统中主要的“职责簇”。它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。 如果期望获得系统的“高级”概念性简述，则可对分析类本身进行维护。分析类还可产生系统设计的主要抽象–系统的设计类和子系统。分析类说起来也很简单，加起来总共也只有三个，分别边界类(boundary)、控制类(control)和实休类(entity)，这些分析类都是类(class)的版型。
  边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。这种交互包括转换事件，并记录系统表示方式(例如接口)中的变更。在从需求向实现的转换过程中，任何两个有交互的关键对象之间都应当考虑建立边界类。
  ■ 参与者与用例之间应当建立边界类
  ■ 用例与用例之间如果有交互，应当为其建立边界类
  ■ 如果用例与系统边界之外的非人对象有交互，例如第三方系统，应当为其建立边界类
  ■ 在相关联的业务对象有明显的独立性耍求，即它们可能在各自的领域内发展和变化，但又希望互不影响时，也应该为它们建立边界类
  最后，从架构角度上来说，边界类主要位于展现层。边界类的获取对架构设计中的展现层有着重要的指导意义。

  控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象(控制类的实例)通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。

  实体类是用于对必须存储的信息和相关行为建模的类。实体类通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。从架构角度上来说，实体类主要位于数据持久层。实体类的获取对架构设计中的数据持久层有着重要的指导意义。

  分析类是从业务需求向系统设计转化过程中最为主要的元素，它们在高层次抽象出系统实现业务需求的原型，业务需求通过分析类被逻辑化，成为可以被计算机理解的语义。分析类的抽象层次有三高的特点，正是因为这些特点，使得分析类成为比设计类“更好用”的元素。
  ■　高于设计实现
  ■　高于语言实现
  ■　高于实现方式
  设计类是系统实施中一个或多个对象的抽象；设计类所对应的对象取决于实施语言。设计类用于设计模型中，它直接使用与编程语言相同的语言来描述。

6 关系

1. 关联关系
     关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关是一种静态关系，通常与运行状态无关，而是由“常识”、“规则”、“ 法律” 等因素决定的，所以关联关系是一种“强关联”的关系。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。
     关联又可以分为单向关联，双向关联，自关联。
   1、单向关联
   
     在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。
   2、双向关联
   
     从上图中我们很容易看出，所谓的双向关联就是双方各自持有对方类型的成员变量。
     在UML类图中，双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List<Product>，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。
   3、自关联
   
     自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量，也就是“自己包含自己”。
2. 依赖关系
     依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类(被依赖类)中的某些方法来完成一些职责。它描述一个对象在运行期会使用到另一个对象的关系。与关联关系不同的是，依赖关系是一种临时性的关系，它通常都是在运行期产生，并且随着运行场景的不同，依赖关系也可能发生变化。
     在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图，司机驾驶汽车：
   
3. 扩展关系
   
     它特别用于在用例模型中说明向基本用例中的某个扩展点插入扩展用例。一般来说，扩展用例是带有抽象性质的，它表示了用例场景中的某个“支流”，由特定的扩展点触发而被启动。所以严格来说扩展用例应当用在概念用例模型中，通过分析业务用例场景抽象出关键的可选核心业务而形成扩展用例。不过，在业务模型当中使用也是可以接受的，它可以更显式地表示出一个复杂业务用例的各个“分支”。
     与包含关系不同的是，扩展表示的是“可选”，而不是“必需”，这意味着即使没有扩展用例，基本用例也是完整的；如果没有基本用例，扩展用例是不能单独存在的；如果有多个扩展用例，同一时间用例实例也只会使用其中的一个。
4. 包含关系
   
     它特别用于用例模型，说明在执行基本用例的用例实例过程中插入的行为段。
     包含用例总是带有抽象性质的，基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用例都不能访问对方的属性。从这种意义上讲，包含用例是被封装的，它代表可在各种不同基本用例中复用的行为。因此，与扩展用例一样，包含用例也应当用在概念用例模型中，通过分析业务用例场景而抽象出关键的必选的核心业务而形成包含用例。同样，在业务模型中使用也是可以接受的，它可以显式地表示出那些可复用的业务过程。
5. 实现关系
     它特别用于在用例模型中连接用例和用例实现，说明基本用例的一个实现方式。
     实现所代表的含义是，基本用例描述了一个业务目标，但是该业务目标有多种可能的实现途径，每一种实现途径可以用用例实现（或称用例实例）来表示，而用例实现与基本用例之间就构成了实现关系。换言之，每个实现途径都实现了基本用例的业务目标。
     实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。
     在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具。
   
6. 精化关系
   

  它特别用于用例模型，一个基本用例可以分解出许多更小的关键精化用例，这些更小的精化用例更细致地展示了基本用例的核心业务。精化关系用来连接基本用例和精化用例，说明精化用例是由基本用例精化得来的。
7. 泛化关系(继承关系)
  泛化关系可用于建模过程中的任意一个阶段，说明两个对象之间的继承关系。
  继承关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系。
  在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如下图所示：

8. 聚合关系
  聚合关系是关联关系的一种，是强关联关系，是整体和部分之间的关系。聚合关系用于类图，特别用于表示实体对象之间的关系，表达整体由部分构成的语义。例如一个部门由许多人员构成。与组合关系不同的是，整体和部分不是强依赖的，即使整体不存在了，部分仍然存在。
  聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。
  在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。下图所示是大学和教师的关系图：

9. 组合关系
  组合表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系。
  在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。
  在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。下图所示是头和嘴的关系图：

十一 UML核心视图

  在UML里，结构性特征是用静态视图来表达的，行为性特征是用动态视图来表达的。
  故名思义，静态视图就是表达静态事物的。它只描述事物的静态结构，而不描述其动态行为。将要介绍的静态视图包括用例图、类图和包图。
  故名思义，动态视图是描述事物动态行为的。需要注意的是，动态视图不能够独立存在，它必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为。动态视图包括活动图、状态图、时序图和协作图。

1. 用例图(Use Case Diagram)：从用户角度描述系统功能。
2. 类图(Class Diagram)：描述系统中类的静态结构。
3. 对象图(Object Diagram)：系统中的多个对象在某一时刻的状态。
4. 状态图：是描述状态到状态控制流，常用于动态特性建模
5. 活动图(Activity Diagram)：描述了业务实现用例的工作流程
6. 顺序图(Sequence Diagram)：对象之间的动态合作关系，强调对象发送消息的顺序，同时显示对象之间的交互
7. 协作图：描述对象之间的协助关系
8. 构件图(Component Diagram)：一种特殊的UML图来描述系统的静态实现视图
9. 部署图(Deployment Diagram)：定义系统中软硬件的物理体系结构
10. 包图(Package Diagram)：对构成系统的模型元素进行分组整理的图
11. 组合结构图(Composite Structure Diagram)：表示类或者构建内部结构的图
12. 交互概览图：用活动图来表示多个交互之间的控制关系的图

5类UML图的分类法：

• 用例图：对系统提供提供功能的描述；
• 静态图：描述系统的静态结构，包括 类图 和 对象图；
• 行为图：描述系统的动态行为和组成系统的对象间的交互关系，包括 状态图 和 活动图；
• 交互图：描述对象间的交互关系，包括 顺序图 和 协作图；
• 实现图：提供关于系统实现方面的信息，包括 构件图 和 部署图；

1 用例图

  用例视图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。用例视图是了解系统的第一个关口，人们通过用例视图得知一个系统将会做什么。对客户来说，用例视图是他们业务领域的逻辑化表达，对建设单位来说，用例视图是系统蓝图和开发的依据。
  业务用例视图使用业务主角和业务用例展现业务建模的结果。大多数情况下，业务用例视图需要从业务主角和业务模块两个视角进行展示。
  ■　业务主角视角
  从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标。这个视角有利于向业务主角确认其业务目标是否都已经齐全，以此来检查是否有遗漏的业务用例没有发现。
  ■　业务模块视角
  从业务模块视角来展示业务领域的业务目标，将参与了达成这一业务目标的业务主角与业务用例展现在这个视图中。
  概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。一般来说这些关系有扩展、包含和精化。
  系统用例视图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来。
  一般来说系统用例视图是以业务用例为单位展现的，即将视图名称命名为业务用例名称。这样做本身就表达了从系统需求向业务需求的映射，保证了过程的可追溯性，因此可以省略从系统用例向业务用例的追溯视图。
  系统用例视图就是系统的开发范围。

2 类图

  类图用于展示系统中的类及其相互之间的关系。
  本质上说，类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。实际上，UML解决面向对象的困难的方法源于面向对象方法中对类理解的三个层次观点，这三个层次是概念层、说明层和实现层。在UML中，从开始的需求到最终的设计类，类图也是围绕着这三个层次的观点进行建模的。类图建模是先概念层而说明层，进而实现层这样一个随着抽象层次的逐步降低而逐步细化的过程。
  概念层的观点认为，在这个层次的类图描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。需要注意的是，概念层类图中的类和类关系与最终的实现类并不一定有直接和明显的对应关系。在概念层上，类图着重于对问题领域的概念化理解，而不是实现，因此类名称通常都是问题领域中实际事物的名称。概念层的类图是独立于实现语言和实现方式的。
  说明层的观点认为，在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。
  实现层观点认为，类是实现代码的描述，类图中的类直接映射到可执行代码。

1. 类(Class)在UML中表示
     在UML类图中，类使用包含类名、属性(field) 和方法(method) 且带有分割线的矩形来表示，比如下图表示一个Employee类，它包含name，age和address这3个属性，以及work()方法。
   
     属性/方法名称前加的加号和减号表示了这个属性/方法的可见性，UML类图中表示可见性的符号有三种：+：表示 public；-：表示 private；#：表示 protected。
     属性的完整表示方式是： 可见性 名称 ：类型 [ = 缺省值]
     方法的完整表示方式是： 可见性 名称(参数列表) [ ： 返回类型]

注意：
​ 1，中括号中的内容表示是可选的
​ 2，也有将类型放在变量名前面，返回值类型放在方法名前面

  上图Demo类定义了三个方法：

• method() 方法：修饰符为 public，没有参数，没有返回值。
• method1() 方法：修饰符为 private，没有参数，返回值类型为 string。
• method2() 方法：修饰符为 protected，接收两个参数，第一个参数类型为 int，第二个参数类型为 string，返回值类型是 int。

2. 注释(comment)
     对类图的补充说明，可以附加在任何元素上，通过虚线连接被注释元素 。
   
3. 接口(Interface)
     接口是一种特殊的类，具有类的结构但不可被实例化，只可以被实现(继承)。在UML类图中，接口有两种表示方式：普通接口表示法(飞翔)；棒棒糖表示法(讲人话)。接口名称通常以大写字母I(interface)开头。
   

3 包图

  包图一般都用来展示高层次的观点。

4 活动图

  活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。
  在使用活动图时，要随时保持清醒的头脑，活动图只是我们用来描述业务目标的达成过程并借此来发现对象的工具，它不是我们的分析目标，也不是编程的依据，它只是对象的应用场景之一。我们使用活动图来描述用例场景，帮助我们认识问题领域，从问题领域中发现关键的对象，然后就应该把活动图中的流程忘掉，而专心研究关键对象的特性。最后，再来验证一下这些关键对象的某个交互结果是否的确能够达到用例场景所描述的业务目标。
  用例活动图是最经常使用的。用例表达了参与者的一个目标，用例场景则描述了如何来达到这个目标。活动图用来描述用例场景，也就是通常所说的业务流程。业务流程一般包括一个基本业务流程和一个或多个备选业务流程，而业务流程则通过多个活动按照一定的条件和顺序执行来推进。活动可以是手动执行的任务，也可以是自动执行的任务，每个活动完成一个工作单元。
  对象活动图用于展示对象的交互。不过，用对象活动图来描述对象交互的感觉并不是那么清晰，这一点也不奇怪，因为活动图是面向过程的视图，用它来绘制面向对象的交互图当然会显得格格不入。尽管UML允许用活动图绘制对象交互，但是实际工作中实在没什么理由要使用它。因为UML有其他更好的工具来绘制对象交互图，例如状态图、时序图和协作图。
  不论是上述的用例活动图还是对象活动图，如果说它是一个业务流程，我们总觉得差了点什么。是的，我们只知道活动的执行顺序，却不知道谁在执行这些活动。这就是下一节将要引入的概念：泳道。
  活动图描述了业务流程中活动的执行顺序，却没有描述出谁来执行这些活动，即执行业务流程的职责被遗漏了。在面向过程的分析观点里，对象职责是不重要的，重要的是业务的执行过程；而在面向对象的分析观点里则与之相反，业务的执行过程不是重要的，对象职责才是最重要的。泳道技术的引入多多少少解决了活动图不能描述对象职责的遗憾。
  泳道，顾名思义，就像一个游泳运动员只能在一个泳道里进行比赛一样，一个对象也只能在一个业务流程中担任一个（或一类）职责。泳道代表了一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动集合构成了它们的职责。泳道最主要的用途是在分析用例场景时用来获取角色职责。
  业务场景建模，虽然面向对象的方法从客户代表的角度获取需求，但在实际中，客户的业务通常是以业务流程的形式存在的，仅从单个客户代表处得到的需求不足以说明业务的全貌。这时，我们经常以业务主角（客户代表）作为泳道，以从业务主角处获取的业务用例作为活动来编排活动图。这种活动图对我们获取正确的业务用例和检查已经获得的业务用例有着很好的帮助。业务场景建模是一种辅助手段，在最终模型里可能并不包括它。但在发现和定义业务用例的初期，它能起到很大的帮助作用。
  用例场景建模，获得业务用例之后，我们得到了参与者的业务目标，我们通过用例场景来说明如何达到业务目标。我们经常以业务主角和业务工人作为泳道、以工作单元作为活动来编排活动图来描述用例场景。这种活动图对我们获得概念用例、角色和业务对象（业务实体）有着很好的帮助。

5 状态图

  状态图显示一个状态机。状态机用于对模型元素的动态行为进行建模，更具体地说，就是对系统行为中受事件驱动的方面进行建模。通常使用状态图来说明业务角色或业务实体可能的状态——导致状态转换的事件和状态转换引起的操作。状态图常常会简化对类的设计的确认。对于类的对象所有可能的状态，状态图都显示它可能接收的消息、将执行的操作和在此之后类的对象所处的状态。
  状态机主要用于描述对象的状态变化以确定何种行为改变了对象状态，以及对象状态变化对系统的影响。我们可以用状态机来描述业务实体对象、分析类对象和设计类对象。通常，状态机用于描述实体类对象的整个生命周期内的状态变迁以获得对这个实体对象的理解，同时获得系统和实体对象相互影响的关系。需要注意的是，状态图通常只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。

6 时序图

  时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。
  通常我们使用时序图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的。使用时序图来描述用例实现是一种从现实世界到对象世界的映射方法，它对我们确定对象职责和接口有着显著的作用。而对象的核心就是职责和接口。
  时序图与协作图是可以互相转换的，与协作图不同的是，时序图强调消息事件的发生顺序，更方便于阐述事件流的过程；但是时序图却难以表达对象之间的关系。
  业务模型时序图用于为领域模型中的业务实体交互建模，其目标是实现业务用例。
  概念阶段的时序图采用分析类来绘制，目标同样是实现业务用例。但是，由于分析类本身代表了系统原型，所以这个阶段的时序图已经带有计算机理解。
  概念用例时序图通常是依据业务模型场景图来绘制的，它将业务模型场景用分析类重新绘制一遍，这样，既保留了实际业务需求，又得到了计算机实现的基本理念。
  设计模型时序图使用设计类作为对象绘制。目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。

7 协作图

  协作图描述了对象间交互的一种模式；它通过对象之间的连接和它们相互发送的消息来显示参与交互的对象。

十二 UML核心模型

如何用好产品经理必备技能UML
  模型提出了论点，静态图是论据，动态图则是论证，建立模型的过程，就是采用论据来论证论点的过程。

1 用例模型概述

产品经理这样画UML用例图，3步让你做需求分析有理有据
  ■　它是面向对象软件过程的骨架——开发过程中一切工作的组织框架；
  ■　它是面向对象软件过程的神经系统——用例驱动过程；
  ■　它也是面向对象软件过程的血肉——需求的来源，测试的依据……
  用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。
  统一过程是一种演进式的软件过程，在整个产品生命周期之内充满了许多小规模的迭代，而每一次迭代的开始几乎都是从识别用例开始，从用例被实现而结束。

2 业务用例模型

  业务用例模型的目的是为现存的或客户预想中的真实业务建立模型，是我们为了理解客户的业务，并与客户达成业务理解上的共识而建立的模型，它不需要考虑计算机环境。相对于系统模型来说，业务模型是对现实业务的一种直观的理解，而没有加入其他的因素，因而更容易在客户和开发双方达成共同理解。
  另外，业务用例模型要准确而完备地描述客户的现存或预想业务，而系统用例模型则可能只是业务的片断或者部分。

3 系统用例模型

  系统用例模型位于统一过程中先启阶段的末期以及精化阶段的早期。实际上，系统建模就是我们通常所说的需求获取。一般来说，系统二字可以省略，所谓的系统用例就是我们熟悉的用例，系统用例模型也就是我们熟悉的用例模型。

4 领域模型

  首先，单纯从领域模型的基本概念上讲，本书中的领域模型与大家熟知的领域驱动设计（DDD）的定义是一致的，都是通过抽象现实世界当中的事物，以概念化的手段，以模型的方式给予定义。
  领域模型是采用业务对象建立起来的一种模型，我们把领域模型当中使用到的业务对象称为领域类。

5 分析模型

DFD图

ER模型

RUP方法

  统一软件开发过程（Rational Unified Process,RUP)是一种面向对象且基于网络的程序开发方法论。
  根据Rational(Rational Rose和统一建模语言的开发者)的说法，好像一个在线的指导者，它可以为所有方面和层次的程序开发提供指导方针，模版以及事例支持。RUP和类似的产品–例如面向对象的软件过程（OOSP），以及OPEN Process都是理解性的软件工程工具–把开发中面向过程的方面（例如定义的阶段，技术和实践）和其他开发的组件（例如文档，模型，手册以及代码等等）整合在一个统一的框架内。
  统一软件开发过程(RUP)的概念和方法

CMM