在uml中视图主要分为两类，一类主要描述结构性特征，使用静态视图来表示，一类描述行为型特征，使用动态视图来表示。
静态视图
静态视图主要有三种，就是用来表达静态事物的，描述事物的静态结构，而不描述动态行为，将要介绍的包括用例图，类图和包图。
1、用例图
用例图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求，用例视图是了解系统的第一个关口。前提条件是参与者和用例已经获取了。但是常见的是，在一边绘制用例图一边修改参与者和用例。
分类
一、业务用例视图:使用业务主角和业务用例展现建模的结果，业务用例视图展示了业务系统的功能性需求。比如一个借图书的例子，从两个视觉展示:
业务用例实现视图
业务用例实现视图是展示业务用例有哪几种实现方式的途径，比如还是借阅图书的业务用例，那么可以列出有3种用例。
这时候我们使用业务对象和业务过程来实现这两个实现的途径，会发现有很多重叠和复用的对象，这些信息就是概念用例视图的来源了。
概念用例视图
概念用例视图是用于展示从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系，一般来说有拓展、包含、精化的关系(可以看我上一篇，了解用例之间的关系)。
还是以我们借阅图书业务的概念用例视图为例，它表达的含义是借阅图书业务必须经过检查借阅证、接触图书、归还图书这三个关键业务单元，同时可能还需要缴纳费用。
系统用例视图
这个是展示系统范围的，对业务用例分析后得到的系统用例展现出来，可以表达从系统需求向业务需求的映射，保证过程的可追朔性。
它表达的含义主要是计算机系统将开发视图列出的系统用例，但是手工的不能列入系统范围。
2、类图
在UML中解决面向对象困难的方法源于面向对象方法中对于类的理解的三个层次的观点: 概念层、说明层、实现层。在UML中，从开始的需求到最终的设计类，类图也是围绕这三点进行建模。
使用类图建模是从概念层到说明层，再到实现层随着抽象层次逐步降低而细化的过程。
概念层类图
通常这个图以领域进行建模，也就是业务实体来表达，类名称通常会是问题领域中的实际事物的名称。比如我们网上购物的实体图，会分为几个: 商品、订单、支付卡、账户等构成，这几个交互能完成网上购物的业务目标。
说明层类图
这个层次的类图考察类的接口而不是实现，类图中表达的类和类的关系应当是对问题领域在接口层次抽象的描述。我们只关心这些类，通过什么接口进行交互，然后完成了业务目标。
这个阶段，类描述还非常粗略，是以分析类和分析模型来表示的，我们可以参考看下还是网上购物的说明层类图，这视图从计算机角度表达了，网上购物这个业务目标由哪些类来完成。
实现层
实现层处在设计阶段，这阶段的类图已经相当于伪代码了，甚至使用工具可以直接生成可执行的代码了。
3. 包图
包图一般用来展示高层次的概念。包也几乎可以用在任何阶段。
动态视图(活动图、状态图、协作图)
动态视图就是描述事物动态行为的，他不能独立存在，必须指定一个静态视图或UML元素，说明在静态视图规定的事物结构下他们的行为。
4. 活动图
活动图是描述为了完成某一个目标需要做的活动以及这些活动的执行顺序。UML中有两个层面: 一种用于描述用例场景，一种用于描述对象交互。活动图实际上描述的是业务流程。
用例活动图
用例活动图是最常见的。用例表达了参与者的一个目标，用例场景则描述了如何来达到这个目标，活动图用来描述用例场景，也就是通常说的业务流程。
业务流程一般包括一个基本业务流程和多个备选业务流程，而业务流程则通过多个活动按照一定的条件和顺序来推进，活动可以是手动执行的任务，也可以是自动执行的任务，每个活动完成一个工作单元。
我们来对几个活动图中的关键词进行讨论:
- 起始点
起始点标记业务流程的开始，一个活动图或者说一个业务流程有且仅有一个起始点。
- 活动
活动是业务流程的一个执行单元，在UML中，活动被赋予了四个特定的事件。entry指进入活动时要执行的动作(或类方法)，do指活动执行过程中要进行的动作。event事件指活动在执行中接收到的某个事件时执行的动作。exit指活动在退出时要执行的动作。
3.判断
判断根据某个条件进行决策，执行不同的流程(分支)。
- 同步
同步分为同步起始和同步汇合。同步起始表示从它开始多个支流并行执行，同步汇合表示多个支流同时到达后再执行后续动作。 -
结束点
组合活动可以用嵌套的活动来表示，不过比较复杂，不建议使用。
表示业务流程的终止。一个活动图可以有一个或多个结束点。
6.基本流
表示最主要的、最频繁使用的默认业务分支。
7.支流
表示不经常使用的，由某个条件触发的，非默认的业务流程分支。
8.异常流
表示不正常的、不是业务目标期待的，容错性的，发生意外情况的业务主流分支。
。
对象活动图
用来表示对象的交互，比如查询商品的对象交互图。
，使用这个来查询对象的交互没有那么清晰，比较活动图主要是描述业务流程。
在活动图中，我们可以清晰的看见执行的顺序，但是不清楚谁在执行这些活动。因此就涉及到了泳道。
泳道
泳道，就像一个游泳运动员只能在一个泳道里进行比赛一样，一个对象也只能在一个业务流程中担任一个职责。泳道代表了一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动集合构成了他们的职责。
我们可以看下上面的图加入泳道后的样子。
泳道最主要的用途是在分析用例场景时用来获取角色职责。
活动图的主要应用
活动图主要应用于业务场景建模和用例场景建模:
业务场景建模： 在实际中，客户的业务通常以业务流程的形式存在，从单个客户的代表处得到的需求不足以说明业务的全貌。这时候，我们经常以业务主角作为泳道，以从业务主角处获取的业务用例作为活动来编排活动图。这种活动图对我们获取正确的业务用例和检查已获得的业务用例有着很好的帮助。
业务建模只是一种手段，在最终模型中可能不包括它，但在发现和定义业务初期能起很大的作用。
用例场景建模：在用例场景建模中，获得业务目标后，得到了参与者的业务目标，我们通过用例场景来说明如何达到业务目标。我们经常以业务主角和业务工人作为泳道，以工作单元为活动来编排活动图来描述用例场景，这种活动图对我们获得概念用例、角色和业务对象，建立领域模型有很好的帮助。
5. 活动图
状态图用于对模型元素的动态行为进行建模，我们使用状态图来说明业务角色或业务实体可能存在的状态---包括导致状态转换的事件和状态转换引起的操作。使用状态图来描述业务实体对象、分析类对象和设计类对象。以下是图书业务实体的状态图。
图中包含了一些关键元素:
1.初始状态： 状态图的起始位置，不需要触发。
- 状态
参考活动图的活动概念。
- 复合状态: 具有子状态的状态称为复合状态，同样包含一个初始状态和终止状态。
4.转移: 指一个状态因为满足指定事件和条件，转成另一种状态。
5.事件: 特定的行为或动作。
6终止状态: 对象的生命周期结束或状态执行结束。
状态图通常只描述单个对象的行为，如果要描述对象间的交互，最好采用时序图或协作图。
6.时序图
时序图用于描述按时间排序的对象之间的交互模式。在时序图中包含对象和主角实例以及他们如何交互的消息。时序图描述了参与对象中所发生的事件，以及这些对象如何通过相互发送消息进行通信，可以为用例事件流的不同形式来制作时序图。
我们在类图中把类分为三个阶段或者说层次: 概念层、说明层、设计层，分别对应业务建模阶段、概念建模阶段和设计建模阶段，起始我们也可以根据这三个层次分别对业务实体对象、分析类对象和设计类对象绘制时序图。这三个层次分别为业务模型时序图、概念模型时序图、设计模型时序图。
业务模型时序图
业务模型时序图用于为领域模型中的业务实体交互建校，其目标是实现业务用例。在绘制业务实体时序图之前，你应当已经绘制了业务用例实现过程的活动图。
下面对使用到的一些UML元素做解释:
1.对象:表示参与交互的对象，一个对象都带有一条生命周期线，对象被激活(创建或者被引用时，生命周期线上会出现一个长条(会话)，表示对象的存在。
2.生命周期线:生命周期线表示对象的存在，当对象被激活(创建或者被引用)时，生命周期线上出现会话，表示对象参与了这个会话。
3.消息:消息由一个对象的生命周期线指向另一个对象的生命周期线。
如果指向空白的生命周期线，将创建一个新的会话。
消息有许多不同的类型:
简单消息，适用于大多数情况，表示一个交互。
返回消息，为原消息的返回体，而非新的消息，一般来说不需要为每个原消息都返回消息，一个是默认都有返回，另一方面返回太多会导致图变得更复杂。
同步消息表示发出消息的对象将停止后续动作一直等到接收方消息响应。会阻塞，最为常用。
4.会话: 表示一次交互，在会话过程中所有对象共享一个上下文环境。
5.销毁: 销毁绘制在生命周期上，表示对象的终止。
最后在绘制业务模型时序图时需要注意以下几点:
1.时序图以达到业务目标为准则
2.该阶段尽量采用业务术语，因为处于业务阶段。
概念模型时序图
这个时序图会采用分析类来绘制，目标同样是实现业务用例的。依据业务模型场景来绘制，将业务模型场景用分析类重新绘制一遍，即保留业务需求又得到计算机的基本理念。绘制后如下图所示:
设计模型时序图
这个是使用设计类作为对象来绘制了。目标是实现概念模型中的某个事件流，一般以一个完整的交互为单位，消息会细致到方法级别。
但是实际工作中很少用到，工作量太大了。
时序图和协作图是可以互相转换的，与协作图不同的是，时序图强调事件的发生顺序，更方便于阐述事件流的过程，但是时序图难以表达对象之间的关系。
7.协作图
协作图描述了对象间交互的一种模式，它通过对象之间的连接和他们的相互发送消息来显示参与交互的对象。通过说明对象间如何通过交互发送消息来实现通信，可以为用例事件流的每一个变化形式制作一个协作图。
协作图的建模结果用于获取对象的职责和接口，协作图展示了对象之间的关系，使得更适用于对对象结构的理解，而时序图更适合对调用顺序的理解。本质上，两者可以互换。
如果更在意对象间的结构关系可以使用协作图，如果是执行顺序可以使用时序图。
同样可以根据概念层、说明层和实现层对业务实体对象、分析类对象和设计类对象绘制协作图。
同时在ROSE中提供了把时序图直接转化为协作图的工具。在时序图中，直接按F5建就可以直接切换完成。这时候再调整下图元位置，就可以了。绘制一个时序图，就可以同时得到协作图。
业务模型协作图
采用业务实体来绘制，目标也是实现业务用例场景。以下是一个案例:
分析下包含的元素:
对象: 表示参与协作的对象，对象可以指定他的类。
对象关联: 连接两个对象，表示两者之间相互关联。
Rose中定义了对象关联的几种可见属性:
域可见，表示关联的对象在交互域一直可见。
参数可见，表示关联的对象仅在交互过程可见，他们是通过参数传递产生关联。
消息: 与时序图的消息的定义一样。
消息序号: 表示消息传递的顺序。
概念模型协作图，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。
总结
静态视图表示事物的结构性观点，而动态视图表示事物的行为性观点，一个好的建模，两者缺一不可，互补。熟能生巧，只有多使用，才能多理解建模的真正本质和使用。