UML学习总结

UML中的4+1模型

UML的4+1模型是一个叫Kruchten的人发明的，但网上还有其它版本的4+1 模型:Use case view, Logic view, Process view, Impementation View and Deployment View。

Logic View:对系统各个组成部分进行抽象描述，其焦点在于系统是如何构成的以及构成系统的各个部分之间是如何互动的。我们常用的类视图(class digram)，对象图(object diagram)，顺序图(sequence diagram)/通信图(communication diagram)都属于Logic View。
Process View:描述系统中的各种活动，典型的视图为活动图(activity diagram)。个人认为活动图和流程图非常类似，且目的都是为了将系统中的活动描述清楚。
Development View:从开发者的角度描述系统的构成，典型的视图为构件视图(component diagram)
Physical View:该视图关注软件构件在硬件上的top结构，以及构件之间的通信。典型的视图为部署视图(deployment diagram)
Use case View:对系统用例进行描述，典型的视图为用例视图(use case diagram)

UML模型、视图、图

UML的概念和模型可以分成以下几个概念域：静态结构、动态行为、实现构造、模型组织、扩展机制
UML视图和图

静态视图

1、  类元

类元是模型中的离散概念，拥有身份、状态、行为和关系。有几种类元包括类、接口和数据类型。其他几种类元是行为概念、环境事物、执行结构的具体化。这些类元中包括用例、参与者、构件、节点和子系统。图列出了几种类元和它们的功能。元模型术语类元中包括了所有这些概念。

2、类元之间关系

类元之间的关系有关联、泛化、各种形式的依赖关系，包括实现关系和使用关系。

关联：对象通常要和其他对象发生关联，关联可以具有多层形式。多重性问题（一对一、一对多）。在UML中关联用一条直线来表示。

泛化：一个类继承了其他类的属性和操作。在UML中泛化用“从之类画一条带空心三角形箭头的连线指向父类”来表示。

依赖：一个类使用了另一个类。在UML中依赖用“从依赖类到被依赖的带箭头的虚线”表示。

聚集是关联的一种，聚集对象由部分对象组成。也就是整体与部分关联。在UML中用“整体和部分之间用带空心菱形箭头的连线连接”来表示。

组合是一种特殊的聚集，在一个组合对象中，部分对象只能作为组合对象的一部分与组合对象同时存在。在UML中用“整体和部分之间用带实心菱形箭头的连线连接”来表示。

实现：类和接口之间的关系被称为实现。在UML中实现关系用一个带空心三角形箭头加虚线来表示，箭头指向接口。

关系的种类

图举例：

1.关联

2.依赖

3.限定关联

4. 聚集和组成

5.泛化

6.实现关系

用例视图

当用例视图在外部用户前出现时，它捕获到系统、子系统或类的行为。它将系统功能划分成对参与者(即系统的理想用户)有用的需求。而交互功能部分被称作用例。用例使用系统与一个或多个参与者之间的一系列消息来描述系统中的交互作用。参与者可以是人,也可以是外部计算机系统和外部进程。

用例之间的关系：关联、扩展、泛化、包含。

图举例：

1.用例图

2.用例关系图
 

交互视图

交互视图描述了执行系统功能的各个角色之间相互传递消息的顺序关系。类元是对在系统内交互关系中起特定作用的一个对象的描述，这使它区别于同类的其他对象。交互视图显示了跨越多个对象的系统控制流程。交互视图可用两种图来表示：顺序图和协作图，它们各有不同的侧重点。协作图也展示对象之间的交互关系，强调交互的语境和参与交互的对象的整体组织。协作图按照空间组织布图（并行），而顺序图按照时间顺序布图（串行）。

1.顺序图

2.协作图

状态视图

状态视图是一个类对象所可能经历的所有历程的模型图。状态图由对象的各个状态和连接这些状态的转换组成。状态图是对单个对象的“放大”，它说明对象所经历的状态变化。强调单个对象内状态的变化。

活动视图

活动图是状态图的一个变体，用来描述执行算法的工作流程中涉及的活动。活动状态代表了一个活动：一个工作流步骤或一个操作的执行。活动图描述了一组顺序的或并发的活动。活动视图用活动图来体现。活动图很像流程图，它显示出工作步骤，判定点和分支。可用于表达一个对象的操作和一个业务过程。

物理视图

物理视图对应用自身的实现结构建模，例如系统的构件组织和建立在运行节点上的配置。这类视图提供了将系统中的类映射成物理构件和节点的机制。物理视图有两种：构件图和部署视图。

1.构件图

2.部署图

模型管理视图

模型管理视图对模型自身组织建模。一系列由模型元素（如类、状态机和用例）构成的包组成了模型。一个包(package)可能包含其他的包，因此，整个模型实际上可看成一个根包，它间接包含了模型中的所有内容。包是操作模型内容、存取控制和配置控制的基本单元。每一个模型元素包含于包中或包含于其他模型元素中。

扩展机制

UML提供了几种扩展机制，允许建模者在不用改变基本建模语言的情况下做一些通用的扩展。这些扩展机制已经被设计好，以便于在不需理解全部语义的情况下就可以存储和使用。由于这个原因，扩展可以作为字符串存储和使用。对不支持扩展机制的工具来说，扩展只是一个字符串，它可以作为模型的一部分被导入、存储，还可以被传递到其他工具。我们期望后端工具设计成能够处理各种扩展，这些工具会为它们需要理解的扩展定义特定的语法和语义。扩展机制包括约束、标记值和构造型。

约束是用文字表达式表示的语义限制。

标记值是一对字符串—一个标记字符串和一个值字符串—存储着有关元素的一些信息。标记值可以与任何独立元素相关，包括模型元素和表达元素。标记是建模者想要记录的一些特性的名字，而值是给定元素的特性的值。例如，标记可以是author，而值是对元素负责的人的名字，如Charles Babbage。

标记值

构造型是在一个已定义的模型元素的基础上构造的一种新的模型元素。构造型的信息内容和形式与已存在的基本模型元素相同，但是含义和使用不同。例如，商业建模领域的建模者希望将商业对象和商业过程作为特殊的建模元素区别开来，这些元素的使用在特定的开发过程中是不同的。它们可以被看作特殊的类—它们有属性和操作，但是在它们与其他元素的关系上和它们的使用上有特殊的约束。

各种图汇总