静态视图就是表达静态事物的，值描述事物的静态结构，而不描述其动态行为。包括：
用例图类图包图用例图采用参与者和用例作为基本元素，以不同的视角展现系统的功能性需求。对于客户来说，用例视图是他们业务领域的逻辑化表达，对建设单位来说，用例视图是系统蓝图和开发的依据。 1、业务用例视图 使用业务主角和业务用例展现业务建模的结果，有
业务主角业务模块两个视角进行展示
A、业务主角视角 从业务主角视角来展示业务主角在业务中使用哪些业务用例来达成业务目标。这个视角有利于向业务主角确认其业务目标是否都已经齐全。 A、业务模块视角
用来展示业务领域的业务目标，将参与达成这一业务目标的业务主角与业务用例展现在这个属兔，有利于从业务的完整性角度出发，检查完成某个业务的所有业务主角和业务用例是否已经齐全，一次来检查是否有遗漏的业务用例没有发现。 2、业务用例实现视图 业务用例实现视图展示业务用例有哪些事项途径。
业务用例是业务需求，而业务用例实现则是业务的实现途径。如果只有一个实现途径，那么此视图意义不大 3、概念用例视图 用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例之间的关系，一般来说这些关系有扩展，包含和精化。
4、系统用例视图 系统用例视图展现系统范围，将对业务用例进行分析以后得到的系统用例展现出来。
系统用例视图是以业务用例为单位展现的，即将视图名称命名为业务用例名称。这样做本身就表达了从系统需求向业务需求的映射，保证了过程的可追溯性、
系统用例视图即是系统的开发范围
5、系统用例实现视图 如果一个系统有多种实现方式，也应当为其绘制实现视图。
为了扩展性好，即便只有一种实现方式，也最好绘制系统游泳实现视图
用于展示系统中的类及其相互之间的关系 类的三个层次：
概念层说明层实现层概念层类图 这个层次的类图描述的事现实世界中问题领域的概念理解。
注重对问题领域的概念化理解，而非实现。因此类名称通常都是问题领域中实际事物的名称。
概念成的类图是独立于实现语言和实现方式的。 说明层类图 这个层次的类图考察的事类的接口而不是实现。关心类通过接口进行交互，进而完成了问题领域中的业务目标。 实现层类图 类图中的类直接映射到可执行代码，必须明确采用说明语言实现。 在这个阶段，类图可以视为伪代码，甚至可以用工具直接将实现层类图生成可执行代码。
包图一般用来展现高层次的观点。包作为容器把建模元素从大到小，从粗到细的建立关系
动态视图是描述事务动态行为的，动态视图不能独立存在，必须特质一个静态视图或UML元素，说明在静态视图规定的事物结构下他们的动态行为。包括
活动图状态图时序图协作图两个层面活动图：
1，用于描述用例场景2，用于描述对象交互4.2.1.1 用例活动图 活动图用来描述用例场景，也就是通常说的业务流程。
业务流程一般包括一个基本业务流程和一个或多个备选业务流程，业务流程则通过多个活动按照一定的条件和顺序来推进。
每个活动完成一个工作单元。 包含：
起始点活动判断：同步：同步起始（郭大哥支流并行执行），同步汇合（多个支流同时到达后再执行后续活动）结束点：基本流：主要的，最频繁使用，默认的业务流程分支支流：异常流组合活动：太复杂，宁可另绘一幅活动图4.2.1.2 对象活动图 用户展示对象间的交互。对象活动图很少使用
4.2.1.3 泳道 解决了活动图不能描述对象职责的问题。 一个对象只能在一个业务流程中担任一个（或一类）职责。 用到代表了 一个特定的类、人、部门、层次等对象的职责区，这些对象在业务流程中负责执行的活动集合构成了他们的职责。 4.2.1.4 业务场景建模 以业务主角（客户代表）作为用到，以业务主角出获取的业务用例作为活动来编排活动图。有如下好处：
帮助发现业务用例（检查是否有遗漏）
帮助检查业务用例粒度
帮助检查业务主角
帮助检查业务用例
4.2.1.5 用例场景建模 我们经常以业务主角和业务工人作为泳道，以工作单元作为活动来编排活动图来描述用例场景。这种活动图对我们获得概念用例、角色和业务对象（业务实体）有着很好的帮助，能够：
帮助发现概念用例：发现的概念用例通常构成了业务加架构中的关键业务。帮助发现角色：同一个或同一类工作单元（活动）位于不同用到，即被不同的业务主角或业务工人使用，那么应该考虑为这些使用了同一活动的业务主角和业务工人抽象出更高级的角色。帮助发现业务实体：所有活动都有着动词+名词的命名规则，这些名词就是很好的业务实体（对象）的来源帮助建立领域模型：在多个用例场景的不同活动中发现某个名词重复出现，要重视，很可能这个名词就是一个关键的业务对象。这个业务对象在不同活动中的状态一级它与活动图中其他名词之间的关系很可能就决定了业务的结构，绘制出这个结构就能获得领域模型。状态图显示一个状态机，对模型 元素的动态行为建模，对系统行为中收时间驱动的方面进行建模。
通常使用状态图来说明业务角色或业务实体可能的状态——导致状态转换的时间和状态转换引起的操作。
状态机主要用于描述对象的状态变化以确定何种行为改变了对象状态，一级对象状态变化对系统的影响。
状态图只用于描述单个对象的行为，如果要描述对象间的教育，最好采用个时序图或者协作图
初始状态状态：对象执行某项活动或等待某个事件时的条件。UML赋予对象四个特定事件， 1.entery对象进入（激活）状态是执行的动作（或类方法） 2.do指对象状态保持不变时持续执行的动作（或类方法），不会因为event而停止 3.event事件：对象接收到某个事件时执行的动作，这个动作不会导致对象状态的变化， 4.exit值状态在退出（结束）时执行的动作。 复合状态：具有子状态（或者成为嵌套状态）的状态被称为符合状态。子状态如何变迁有复合状态决定。子状态的终止状态表示退出复合状态。转移：两个状态之间的关系，当发生指定时间并满足指定条件是，第一个状态的对象将执行某些操作进入第二个状态事件：一个特定的动作或行为，条件满足将触发一个转移条件，一个布尔表达式最终状态表示状态机执行结束，或者对象生命周期结束时序图用于描述按时间顺序排列的对象之间的交互模式，按照参与交互的对象所具有的“生命线”和他们相互发送的消息来显示这些对象，在时序图中包含对象和主角实例，以及说明他们如何交互消息的。
时序图描述了在参与交互的对象中所发生的事件（从激活的角度来说明），以及这些对象如何通过相互发送消息进行通信。
可以为用例事件流的各种不同形式制作时序图。 对象的核心就是指责和接口
4.2.3.1 业务模型时序图 业务模型时序图用于为领域模型中的业务实体交互建模，其目标是实现业务用例。 时序图中的关键元素
对象：参与交互的对象，每个对象都带有一条声明周期线，对象被激活（创建或者被引用）时，生命周期线上会出现一个长条（会话），表示对象的存在。生命周期线：表示对象的存在，当对象被激活（创建或者被引用）时，声明周期线上出现会话，表示对象参与了这个会话。消息：消息由一个对象的生命周期线指向另一个对象的生命周期线，如果消息指向空白的生命周期线，将创建一个新的会话，如果指到已有的会话，表示该对象延续已有的会话 消息的类型 简单消息 并不强调消息的类型，只表示一个交互返回消息 源消息的返回体，非新消息。默认返回，但基本不绘制
同步消息 表示发出的消息对象停止所有后续动作一直到接受消息方响应。同步消息将阻塞源消息对象的所有行为，同步消息最为常见
限时消息
是同步消息的一种特殊情况，消息发出后等待一段时间响应后，如果没有响应则取消原来的阻塞状态，而执行后续操作
异步消息 发出消息后不等待响应，直接继续执行其他操作，异步消息需要中间件的支持
会话：表示一次交互，会话过程中所有对象共享一个上下文环境销毁：销毁绘制在声明周期线上，表示对象声明周期的终止需要注意的三点
时序图以达成业务目标为准则
这个解毒处于业务阶段，使用的描述语言应当采用业务术语
时序图表达的内容会对将来的分析设计带来帮助，但对编码实现来说太粗略
4.2.3.2 概念模型时序图 概念阶段的时序图改用分析类来绘制，目标同样是实现业务用例。但是由于分析类本身代表了系统原型，锁一个这个阶段的时序图已经带有计算机理解。
通常依据业务模型场景图来绘制。
4.2.3.3 设计模型时序图 使用设计类作为对象绘制，目标是实现概念模型中的某个事件流，一般以一个完整交互为单位，消息细致到方法级别。
描述了对象间交互的一种模式:他通过对象之间的连接和他们相互发送的消息来显示参与交互的对象。
协作图可以有对象和主角实例，以及描述他们之间关系和交互的连接和消息。通过说明对象间如何通过相互发送消息来实现通信，协作图描述了参与对象中发生的情况，可以为用例事件流的每一个变化形式制作一个协作图。 4.2.4.1 业务模型协作图 采用业务实体来绘制，目标也是实现用例场景。只需要将影响对象的关键消息绘制出来即可。因为协作图更在意的事对象的结构及其相互的影响。 其中涉及到的UML元素
对象：表示参与写作的对象。对象可以指定它的类，也可以直接用空对象表示，在将来再指定它的类对象关联：连接两个对象，表示两者的关联。协作图中的对象关联是临时关联，即只在本次交互中存在；而类关系是永久关联。rose中定义对象关联的可见属性 消息：写作图中的消息与时序图中的消息定义完全一样。消息序号：消息序号也是消息的一部分，序号表明消息传递的先后顺序。4.2.4.2 概念模型协作图 与时序图相同，概念阶段的协作图采用分析类来绘制，目标是实现业务用例。
4.2.4.2 设计模型协作图 使用设计类为对象来绘制，目标是实现概念模型中的某个事件流。一般以一个完整交互为单位，消息细致到方法级别
