近几年来，面向对象几乎成为软件技术的代名词。而UML是面向对象方法的一面旗帜，谈到面向对象的分析和设计就不能不谈到UML。如今UML也成为面向对象分析和设计事实上的行业标准。然而什么是UML，如何利用UML将一份原始需求经过层层分析和推导，最终形成可执行的代码？
¶为什么需要UML
面向过程还是面向对象？
¶面向过程方法
面向过程方法认为我们的世界是由一个个相互关联的小系统组成的，每个小系统都有着明确的开始和明确的结束，开始和结束之间有着严谨的因果关系。只要我们将这个小系统中的每一个步骤和影响这个小系统走向的所有因素都分析出来，我们就能完全定义这个系统的行为。
¶面向对象方法
面向对象（Object Oriented，简称OO）方法将世界看作一个个相互独立的对象，相互之间并无因果关系，它们平时是“鸡犬之声相闻，老死不相往来”的。只有在某个外部力量的驱动下，对象之间才会依据某种规律相互传递信息。这些交互构成了这个生动世界的一个“过程”。在没有外力的情况下，对象则保持着“静止”的状态。
- 对象是怎么被抽象出来的？现实世界和对象世界看上去差别是那么大，为什么要这么抽象而不是那么抽象呢？（Why）
- 一种把现实世界映射到对象世界的方法
- 对象世界由于其灵活性，可以任意组合，可是我们怎么知道某个组合就正好满足了现实世界的需求呢？什么样的组合是好的，什么样的组合是差的呢？（How）
- 一种从对象世界描述现实世界的方法
- 抛开现实世界，对象世界是如此的难以理解。如果只给我一个对象组合，我怎么才能理解它表达了怎样的含义呢？（What）
- 一种验证对象世界行为是否正确反映了现实世界的方法
¶什么是UML
统一建模语言（Unified Modeling Language）是一种建模用的语言，而所有的语言都是由基本词汇和语法两个部分构成的，UML也不例外。UML定义了一些建立模型所需要的、表达某种特定含义的基本元素，这些元素称为元模型，相当于语言中的基本词汇，例如用例、类等。另外，UML还定义了这些元模型互相之间关系的规则，以及如何用这些元素和规则绘制图形以建立模型来映射现实世界；这些规则和图形称为表示法或视图（View），相当于语言中的语法。
-
统一
- 秦始皇历史上的一大功绩便是统一语言和度量衡
- 统一的目标就是形成标准，任何一种组件化开发模式背后都有一个标准在规范和指导，可以说没有标准就没有工业现代化，没有标准就没有编程组件化，这就是标准的意义。
¶从现实世界到业务模型
这是把现实世界映射到对象世界的第一步。UML采用用例这一关键元素捕获了现实世界的人要做的事，再通过用例场景、领域模型等视图将现实世界的人、事、物、规则这些构成现实世界的元素用UML这种语言描述出来。
¶从业务模型到概念模型
这是从对象世界来描述现实世界的方法。用例所代表的现实的业务过程，被“边界”、“控制”、“实体”以及“包”、“组件”等概念替代。而这些概念是可以被计算机理解的，是抽象化了的对象。现实世界千差万别的业务，都用“边界”、“控制”、“实体”这几个固定的元素来描述，也就是说，现实具体的业务被“抽象”成几个固定的概念。同时，这些概念还可以用“包”、“组件”等这些与现实世界毫不相关的纯计算机逻辑术语包装。这说明概念模型是计算机视角，或者说是对象视角，而且这些对象视角的分析类所描述的信息是从映射了现实世界的业务模型转化而来的。
¶从概念模型到设计模型
这是验证对象世界是否正确反映了现实世界的方法。“边界”、“控制”、“实体”这些对象化的概念，虽然是计算机可以理解的，但它并不是真正的对象实例，即它们并不是可执行代码，概念模型只是纸上谈兵。真正的对象世界行为是由Java类、C++类、EJB、COM+等这些可执行代码构成的。设计模型是概念模型在特定环境和条件下的“实例”化，实例化后的对象行为“执行”了概念模型描述的那些信息，因此设计模型得以通过概念模型追溯到原始需求来验证对象世界是否正确反映了现实世界。
如果把三个模型的建立过程综合起来，如下图所示：
从中我们可以更清楚地看到面向对象的困难是如何在模型的转化过程中解决的。这一过程看来是有规律、可推导、可追溯的过程。
¶UML核心视图
¶静态视图
故名思义，静态视图就是表达静态事物的。它只描述事物的静态结构，而不描述其动态行为。静态视图包括用例图、类图和包图。
¶用例图
用例视图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。
¶业务用例视图
业务用例视图使用业务主角和业务用例展现业务建模的结果。
- 业务主角视图
从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标。如果业务主角认为其所有目标都已经齐全，则认为针对此主角的业务用例定义完成，以此来检查是否有遗漏的业务用例没有发现。
- 业务模块视图
从业务模块视角来展示业务领域的业务目标，将参与了达成这一业务目标的业务主角与业务用例展现在这个视图中。如果这项业务能够被这些业务主角和业务用例完整地说明，则认为针对此业务模块的业务用例定义完成，以此来检查是否有遗漏的业务用例没有发现。
¶业务用例实现视图
业务用例实现视图展现业务用例有哪些实现途径。业务用例是业务需求，而业务用例实现则是业务的实现途径，从软件工程的角度说，这个视图展示了需求的可追溯特点。
¶概念用例视图
概念用例视图用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系。一般来说这些关系有扩展、包含和精化。
¶系统用例视图
系统用例视图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来。系统用例视图就是系统的开发范围。
¶系统用例实现视图
如果一个系统用例有多种实现方式，也应当为其绘制实现视图。
在实际项目中，不是所有的用例视图都一定要采用。根据情况可进行适当裁减，例如只保留业务用例视图和系统用例视图。在许多项目中实际上只有系统用例视图，不论如何，我们应当知道用例图在不同的生命周期阶段还有不同的表达，从而选择适合自己项目的视图。
¶常用元素参考
¶类图
类图用于展示系统中的类及其相互之间的关系。本质上说，类图是现实世界问题领域的抽象对象的结构化、概念化、逻辑化描述。
¶概念层类图
概念层的观点认为，在这个层次的类图描述的是现实世界中问题领域的概念理解，类图中表达的类与现实世界的问题领域有着明显的对应关系，类之间的关系也与问题领域中实际事物的关系有着明显的对应关系。
¶说明层类图
说明层的观点认为，在这个层次的类图考察的是类的接口而不是实现，类图中表达的类和类关系应当是对问题领域在接口层次抽象的描述。
¶实现层类图
实现层观点认为，类是实现代码的描述，类图中的类直接映射到可执行代码。
¶常用元素参考
¶包图
在实际项目中，建模过程中获得的元素是非常多的，如果要将这些元素的关系都绘制出来，将如同蜘蛛网一样难以辨别。通过包这个容器来从大到小、从粗到细地建立关系是一种很好的办法。
在UML所有视图中，包图或许是最自由，约束最小的一种。除了特定的版型之外，包几乎可以用在任何阶段。
¶动态视图
故名思义，动态视图是描述事物动态行为的。需要注意的是，动态视图不能够独立存在，它必须特指一个静态视图或UML元素，说明在静态视图规定的事物结构下它们的动态行为。动态视图包括活动图、状态图、时序图和协作图。
¶活动图
活动图描述了为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面的活动图，一种用于描述用例场景，另一种用于描述对象交互。
¶用例活动图
用例活动图是最经常使用的。用例表达了参与者的一个目标，用例场景则描述了如何来达到这个目标。活动图用来描述用例场景，也就是通常所说的业务流程。
¶对象活动图
对象活动图用于展示对象的交互。
¶泳道
上面的活动图描述了业务流程中活动的执行顺序，却没有描述出谁来执行这些活动，即执行业务流程的职责被遗漏了。泳道技术的引入多多少少解决了活动图不能描述对象职责的遗憾。
状态图是很有用的技术，尤其在描述单个复杂对象的行为时非常有助于我们理解一个对象的行为。但是在建模时并不需要对每个对象都绘制状态图。建议，仅对领域模型中最为关键的业务对象，尤其是当其在一个或多个用例场景中参与了多个活动时，才对其建模。
¶常用元素参考
¶状态图
状态图显示一个状态机，通常使用状态图来说明业务角色或业务实体可能的状态——导致状态转换的事件和状态转换引起的操作。状态机主要用于描述对象的状态变化以确定何种行为改变了对象状态，以及对象状态变化对系统的影响。
¶常用元素参考
¶时序图
时序图用于描述按时间顺序排列的对象之间的交互模式；它按照参与交互的对象所具有的“生命线”和它们相互发送的消息来显示这些对象。在时序图中包含对象和主角实例，以及说明它们如何交互的消息。
¶业务模型时序图
业务模型时序图用于为领域模型中的业务实体交互建模，其目标是实现业务用例。在绘制业务实体时序图之前，你应当已经绘制了业务用例实现过程的活动图。
¶概念模型时序图
概念用例时序图通常是依据业务模型场景图来绘制的，它将业务模型场景用分析类重新绘制一遍，这样，既保留了实际业务需求，又得到了计算机实现的基本理念。
¶设计模型时序图
设计模型时序图使用设计类作为对象绘制。目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。
时序图的三种应用场合是在建模过程中经常使用的动态视图。除了这些场合，在任何时候需要表达对象间的交互时，或者想分析对象的职责和接口时都可以使用时序图。
¶常用元素参考
¶协作图
¶业务模型协作图
业务模型协作图同样采用业务实体来绘制，目标也是实现用例场景。不过有时候协作图并不要求实现完整的场景，只需要将影响对象的关键消息绘制出来即可。因为协作图更在意的是对象的结构及其相互的影响。
某些建模工具（rose powerdesigner）可以直接把时序图转化为协作图
¶概念模型协作图
与时序图相同，概念阶段的协作图采用分析类来绘制，目标是实现业务用例。同样这个阶段的协作图已经带有计算机理解。
¶设计模型协作图
与时序图相同，设计模型协作图使用设计类为对象来绘制。目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。
¶常用元素参考
¶参考文献
- 《大象：Thinking in UML（第二版）》