UML核心视图

UML通过视图将基本元素组织在一起，形成有意义的句子。因此，视图，就是语法。

静态视图：用例图，类图，包图等，他们表达结构性特征

动态视图：活动图，状态图，时序图，协作图等他们表达行为性特征。

用例图

用例图以不同的视角展现系统的功能性需求，是了解系统的第一个关口。

常见的用例图有：

业务用例视图

即使用业务主角和业务用例展现业务建模的结果，大多数情况下，需要从业务主角和业务模块两个角度进行展示。

业务主角视角，用来展示业务主角在业务中使用那些业务用例来达成业务目标。这个视角有利于向业务主角确认其业务目标是否都已经齐全，以此来检查是否有遗漏的业务用例没有发现。

业务模块视角，从业务模块视角来展示业务领域的业务目标，将参与了达成这一业务目标的业务主角与业务用例展现在这个视图中。

也可以根据其他视角，来展示，例如部门，重要业务的生命周期。

也就是说，在建模过程中，可根据所定义的视角，来展示业务主角和业务用例用用例图。

业务用例实例视图

如果一个业务用例由多种实现，则才用该视图，否则多此一举。

如果进一步，从业务对象和业务过程来分析描述两个实现途径，会发现其中有重叠的过程和复用的对象。

概念用例视图

用于展现从业务用例中经过分析分解出来的关键概念用例，并表示概念用例和业务用例之间的关系，例如扩展，包含，精化。概念用例视图不是必须的，如果业务用例是一个复杂的业务，绘制概念用例视图有助于细化和更准确的理解业务用例。

系统用例视图

概念和系统用例，都是以业务用例为单位展现的。表达从系统需求向业务需求的映射，保证过程的可追溯性。

系统用例实例视图

类图

UML中从开始需求到最终的设计类，类图是围绕三个层次的关键建模的，即概念类，说明层，实现层。

概念层类图

问题领域的概念化理解，而非实现。独立于实现语言和实现方式的。位于业务建模阶段，以领域模型图，即业务实体来表示的。

说明层

考察类的接口，只关心接口交互，完成问题领域的业务目标，位于概念模型阶段。以分析类和分析模型图表示。

实现层类图

是直接映射到可执行代码的，位于设计阶段，类图可视为伪代码。

以上，也就是说，类图在不同的软件周期，有三种表达。

包图，可用于任何阶段，最自由，约束最小。

活动图

活动图用于表述用例场景和对象交互。

描述用例场景的是用例活动图，描述对象交互的是对象活动图，不推荐描述对象交互的对象活动图，而用例活动图通常就是所说的业务流程。

实际中，活动图主要用于业务场景建模和用例场景建模。

活动图主要描述为了完成某一目标需要做的活动以及这些活动的执行顺序。

业务场景建模是一种辅助手段，在最终模型中可能不包含它，但在发现和定义业务用例的初期，它能起到非常大的帮助作用。

由于单个客户得到的需求不足以说明业务的全貌，我们经常以客户代表作为泳道，以从业务主角处获取的业务用例作为活动来编排活动图，这种活动图可以帮助我们获取正确的业务用例和检查已经获得业务用例。

用例场景建模，以业务主角和业务工人作为泳道，以工作单元作为活动来编排活动图描述。它对我们发现概念用例，角色和业务实体有很好的帮助。

状态图

简化对类设计的确认，我们可以用状态机来描述业务实体对象，分析类对象和设计类对象，需要注意的是，状态机只用于描述单个对象的行为，如果要描述对象间的交互，最好采用时序图和协作图。建议仅对领域模型最为关键的业务对象，尤其是当其在一个或多个用例场景中参与了多个活动时，才对其建模。

时序图

我们用时序图来描述用例实现，通过贡献于该用例实现的对象之间的交互来说明用例是如何被对象实现的，时序图和协作图是可以相互转换的，时序图强调消息事件的发生顺序，更方便于阐述事件流的过程，但时序图难于表达对象间的关系。可以在分析类的三个层次上，对业务实体对象，分析类对象，设计类对象绘制时序图。

业务模型时序图

在绘制业务用例实例时序图之前，应该绘制了用例实例过程的活动图。

实际上，为了即保证软件实现需求，省略了大量设计模型时序图的同时，要求有更多的概念模型时序图，这样才能保证有足够的信息来说明需求和实现之间的过度。

协作图

协作图与时序图作用类似，但是协作图因为展示对象之间的关系，使得他更实用于获得对象结构的理解，而时序图更适于获得对于调用过程的理解。