本书主要讲的是UML的设计方法及如何把UML运用到实际的工作当中
第一部分：准备篇——需要了解
1. 为什么需要UML
简单来说随着业务越来越复杂面向过程的方法已经不能满足对这种业务的分析需求了，需要使用新的方法，也就是面向对象的分析方法对业务进行分析，但是面向对象也存在一下问题，比如对象是如何抽象出来的，对象世界的不容易理解等，要想更好的解决这些问题，我们就需要：
- 一种把现实世界映射到对象世界的方法。
- 一种从对象世界描述现实世界的方法。
- 一种验证对象世界行为是否正确反映了现实世界的方法。
而UML背后所代表的面向对象设计方法正式针对这些问题提出的。下面将详细介绍UML是如何解决这些问题的。
UML带来了什么
面向对象分析（OOA）方法中，其中最重要的就是UML的前身，后来发展成为UML这种统一建模语言，这种统一建模语言是为了让人们能够无障碍的交流，并且让人和机器都能够读懂，而且UML是可视化的，使用图形更能够形象的说明问题。为了便于建模，UML提供了一些元素来为现实世界建模：
- actor 参与者:信息来源的提供者，同时也是第一驱动者。
- use case用例:表示驱动者的业务目标。
UML通过被称为概念化的过程（Conceptual）来建立适合计算机理解和实现的模型，这个模型称为分析模型(Analysis Model),分析模型的主要元模型有：
- 边界类(boundary):是面向对象分析的一个非常重要的观点，是事物内外交互的一个介质。
- 实体类(entity):原始需求中领域模型中的业务实体映射了现实世界中参与者完成业务目标时所涉及的事物，UML采用实体类来重新表达业务实体。
- 控制类(control):边界和实体都是静态的，UML采用控制类来表述原始需求中的动态信息，即业务或用例场景中的步骤和活动。
通过从现实世界 -> 业务模型 -> 概念模型 -> 设计模型的过程便可以解决上一节提到的三个问题了。
统一过程简介
RUP是统一过程，统一过程是在很多实践中总结出来的软件工程的最佳实践。RUP是一个理论的指导，UML则是具体的语言实现。
2. 建模基础
建模
建模(Modeling):是指通过对客观事物建立一种抽象的方法用以表征事物并获得对事物本身的理解，同时把这种理解概念化，将这些逻辑概念组织起来，构成一种对所观察的对象的内部结构和工作原理的便于理解的表达。
建模需要关注的两点是：这么建立？模是什么？
做需求的时候，首先目标不是弄清楚业务是如何一步一步完成的，而是要弄清楚有多少个业务的参与者，每个参与者的目标是什么，参与者的目标就是你的抽象角度。实际上，这就是用例。
业务建模是什么，这个问题可以参考下面的几个公式来理解：
- \(问题领域＝ \sum_{1}^{n} 抽象问题 \)
- 抽象角度 ＝ 问题领域边界之外的参与者的业务目标 ＝ 业务用例
- \(业务用例＝ \sum_{1}^{n} 特定场景\)
- 特定场景 ＝ 静态的事物 ＋ 特定的条件 ＋ 特定的动作 或者
特定的事 ＝ 特定的事物 ＋ 特定的规则 ＋ 特定的人的行为
用例驱动
用例驱动是统一过程的重要概念，或者说整个软件的生产过程就是用例驱动的。如果我们找到的事物、规则和行为实现了所有必要的用例，那么问题领域就被解决了。统一过程中一个用例就是一个分析单元、设计单元、测试单元甚至部署单元。用例可以驱动的内容包括：
- 逻辑视图: 一个系统只有一个，它以图形的方式说明关键的用例实现、子系统、包和类。即建模公式中的那些“人”、“事”、“物”、“规则”是如何分类组织的。
- 进程视图: 一个系统只有一个，它以图形方式说明系统中进程的详细组织结构，其中包括类和子系统到进程和线程的映射。即建模公式中的那些“人”、“事”、“物”、“规则”是如何交互的，它们的关系如何。
- 部署视图: 一个系统只有一个，它以图形的方式说明了处理活动在系统中各节点的分布，包括进程和线程的物理分布。即建模公式中的那些是如何部署在物理节点（主机、网络环境）上的。
- 实施视图: 获取为实施指定的架构决策，即建模公式中那些是如何构系统的“零部件”，以及我们如何组织人力生产和组装这些“零部件”以建成最终系统。
抽象层次
抽象层次是面向对象方法中极其重要，但是又非常难以掌握的技巧。抽象层次越高，具体信息越少，越容易理解，反之亦然。抽象的方法有两种：
- 自顶向下： 适用于让人们从头开始认识一个事物。
- 自底向上： 适用于在实践中改进和提高认识。
软件开发中应该主体上采用自顶向下的方法，同时应当辅以自底向上的方法，通过总结在较低抽象层次的实践经验来改进较高层次的概念一提升软件质量。
视图
视图用于组织UML元素，表达出模型某一方面的含义。如何选择视图才是重点。视图另一个被人忽视重要概念是：视角。就是人们观察事物的角度。一方面，从信息的展示角度来说，恰当的视角可以让观察者更容易抓住信息的本质；另一方面，从观察者角度说，观察者只会关心信息中他感兴趣的那一部分视角。于是用很多个不同的视图去展示软件这些不同的方面——静态的、动态的、结构性的、逻辑性的等——才能够说建立了一个完整的模型。为了说明这些方面,UML定义了用例图、对象图、类图、包图、活动图等不同的视图。所以在实际工作过程中需要考虑的问题就是：
- 应该为哪些软件信息绘制哪些视图？
- 应给给哪些干系人展示哪些视角？
对象分析方法
使用好UML的前提条件就是掌握了面向对象的思想和方法：
- 一切都是对象
- 对象都是独立的
- 对象具有原子性
- 对象都是可以抽象的
- 对象都有层次性
- 对象分析方法总结
第二部分：基础篇——在学习中思考
3. UML核心元素
- 版型(stereotype):是对UML元素基础定义的一个扩展，在同一元素基础定义的基础上赋予特别的含义，使得这个元素适用于特定的场合。
参与者(actor):是系统之外与系统交互的某人或某事物。系统与参与者之间有一个明确的边界。如何确定系统之外和系统之内呢？主要通过下面两个问题来判断：
- 谁对系统有着明确的目标和要求并且主动发出动作？
系统是为谁服务的？
参与者又叫主角，这个叫法更形象，因为参与者很容易与其他的混淆，比如后面会提到业务主角（是参与者的一个版型）、业务工人(被动参与业务的参与者)、涉众（要建设的这个系统有利益相关的一切人和事）、用户（系统的使用者，是参与者的代表）、角色（参与者的职责，是一个抽象的概念，从众多的参与者中抽象出相同的那一部分。）等。
- 用例(use case):关于用例的一些知识点总结如下：
- 用例是系统所执行的一系列操作。
- 用例是一个相对独立的过程。
- 用例的执行结果对参与者来说是可观测的和有意义的。
- 这件事必须有一个参与者发起。
- 用例必须是以动宾短语形式出现的。如：喝水、取钱等。
- 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元。
- 用例粒度的控制：一般在业务建模阶段，以一个用例能够说明一件完整的事情为宜；在概念建模阶段，用例粒度应以能够描述一个完整的事件流为宜，即完成一项完整业务的一个步骤；在系统建模阶段，用例视角是针对计算机的，因此粒度应以能够描述操作者与计算机的一次交互为宜。
- 如何获得一个用例：主要应当确保：一个明确的目标才是一个用例的来源；一个真实的目标应当完备地表达主角的期望；一个有效的目标应当在系统边界内，由主角发动，并具有明确的后果。
- 区分用例与功能之间的误区：功能是脱离使用者的愿望而存在的；功能是孤立的；用例是一系列完成一个特定目标的“功能”的组合。确定用例要从用例的角度查找，而不是从功能的角度。
- 目标和步骤之间的误区：步骤是为了完成目标而做的，但是有时候步骤和目标却不是绝对的，主要是在不同的分析阶段如业务用例，概念用例，由于边界发生了变化，这些也都是可以转变的。
- 用例粒度的误区：这个误区就是用例粒度把握的不好，用例的层次不够清晰，导致依据用例进行设计的系统架构不能够满足需求，或者对需求的变动有很差的应变能力。
- 业务用例：专门用于需求阶段的建模，在为业务领域建模时应当使用这种版型。
- 概念用例：用于概念建模。作为概念模型的核心元素，概念用例用来获取业务用例中的核心业务逻辑。
- 系统用例：就是一般意义上的用例，是用来定义系统范围，获取功能性需求的。
- 边界: 是参与者和用例之间的一个界限。边界的定义要考多需求的把握。
- 边界决定视界。
- 边界决定抽象层次。
- 边界需要灵活使用。
- 业务实体:是类(class)的一种版型，特别用于在业务建模阶段建立领域模型。官方定义是：业务实体代表业务角色执行业务用例是所处理或使用的“事物”。
- 包:将某些信息分类，形成逻辑单元。包的目标是高內聚、低耦合。包的版型有：领域包、子系统、组织结构、层等。
- 分析类：用于获取系统中主要的“职责簇”。两个主要的性质：
－ 分析类代表系统中主要的法“职责簇”，这意味着分析类是从功能性需求向计算机实现转化过程中的“第一个关口”
－ 分析累可以产生系统的设计类和子系统，这意味着计算机实现是可以通过某种途径“产生”出来的 ，而不是拍脑袋拍出来的。
分析类有三个版型：边界类、控制类和实体类。
4. UML核心视图
静态视图
只描述事物的静态结构，而不描述其动态行为。
用例图
采用参与者和用例作为基本元素,用不同的视角展现系统的功能性需求。用例图是系统蓝图和开发的依据。主要包括：
业务用例视图: 从不同的角度来对业务用例视图进行不同的划分，来保证业务目标是否齐全，业务主角和用例是否齐全等。
业务主角视角：业务模块视角：
业务用例实现视图：上面展现了业务的功能性需求，这个视图则是描述这些需求的实现途径的。也就是说一个用例有多少个实现途径，需要描述一下。
概念用例视图：用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。一般这些关系有扩展、包含和精化。
系统用例视图：展现系统范围，将对业务用例进行分析后得到的系统用例展现出来，一般来说系统用例视图是以业务为单位展现的，即将视图名称命名为业务用例名称。下面是一个借阅图书系统用例视图：
系统用例实现视图
与业务用例实现视图类似，如果一个系统用例有多种实现方式，也应当为其绘制实现视图。
类图
是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。
- 概念层类图：概念层的观点认为，在这个层次的类图描述的是现实世界中问题领域的概念理解，即类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。说的通俗一点就是概念层类图与现实世界中的事物一一对应，类与类之间的关系也与现实世界中的事物之间的关系一一对应。
- 说明层类图：说明层的观点认为，在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类之间的关系应当是对问题领域在接口层次抽象的描述。
- 实现层类图：实现层观点认为，类是实现代码的描述，类图中的类直接映射到可执行代码。这个阶段必须明确用哪种语言，什么设计模式，什么通信标准，遵循什么规范等。
包图
一般用来展示高层次的观点，把繁多的元素通过包这个容器从大到小、从粗到细地建立关系。
动态视图
动态视图是描述视图动态行为的。
活动图
用例活动图：活动图用来描述用例场景，也就是通常所说的业务流程，活动图有几个关键的元素：
- 起始点：标记业务流程的开始，一个业务流程有且仅有一个起始点。
- 活动：活动是业务流程中的一个执行单元。
- 判断：判断根据某个条件进行决策，执行不同的流程分支。
- 同步：分为同步启示和同步汇合。同步起始表示从它开始多个分流并行执行；同步汇合表示多个支流同时到达后再执行后续活动。
- 结束点：表示业务流程的终止。
- 基本流：表示最主要、最频繁使用的、默认的业务流程分支。
- 支流
- 异常流
- 组合活动
对象活动图
- 泳道图
- 业务场景建模
- 用例场景建模
状态图
时序图
协作图