UML概念模型

概述

UML概念模型(体系结构)由构造块、规则和公共机制三个部分构成。
UML概念模型是 一些代表事物的构造块，按某种规则，通过代表关系的构造块连接在一起组成图 , 所有的构造块在使用时, 必须遵循公共机制。

构造块
是UML的基本要素，包括事物、关系、图。
规则
用于支配这些构造块如何放在一起。
公共机制
是运用于整个UML的具有公共特征的模式。

构造块

构造块，也称为构造符号、模型元素，指的是UML的基本建模元素，就是用来构造图形的基本符号。

构造块包括事物、关系、图。

事物
是对模型中关键元素的抽象体现；
关系，是事物之间联系的方式；
图，是相关的事物及其关系的聚合表现。

在UML中，图以一种可视化的方式聚集了相关需要表达的事物，并且表达了这些事物之间的关系。

事物

在UML中，事物是对模型中最具有代表性的成分的抽象，代表了一些面向对象的基本概念。
在UML中，定义了四种基本的事物，分别是

1. 结构事物(structural thing)、
2. 行为事物(behavioral thing)
3. 分组事物(grouping thing)
4. 注释事物(annotational  thing) 。

(1)结构事物

是UML模型的静态部分，用于描述软件系统中的概念元素或物理元素，描述了事物的静态特征。

常见的结构事物主要有7种：
类+对象、接口、用例、协作、主动类、构件（组件）、节点。

类+对象
类(Class)是对具有相同属性、相同操作、相同关系和相同语义的一组对象的描述。

接口(Interface)
由一组对操作的定义组成（不包括对操作的详细描述），描述了元素的外部可见操作。
很少单独存在，往往依赖于实现接口的类或构件。

接口分为两种：

• 供给接口——只能向其它类(或构件)提供服务
• 需求接口——使用其它类(或构件)提供的服务

用例和协作
用例(Use Case)是对一组动作序列的抽象描述，这些动作序列将作为服务，由特定的参与者触发或执行，会产生一个有价值、可观察的结果。

协作(Collaboration)是一组对象为了完成某个任务而协同工作、相互配合进行的交互。从本质上说，协作就是用例的实现。

用例用实线椭圆表示，协作用虚线椭圆表示

主动类(Active Class)
主动类是一种特殊的类，该类的对象至少拥有一个进程或线程，可以启动控制活动。
主动对象由自身的事件 驱动控制线程，而被动对象被动等待其他对象发出请求。

主动类的表示与一般类相似，只是最外框是粗线描述
UML2中改为左右外框是双线。

构件(Component)
构件是指系统中封装好的、相对独立的模块化软件部件，仅将外部接口暴露出来，功能实现部分被隐藏在内部。
构件对外声明了一组接口(包括供给接口和需求接口)，接口相同的部件可以互相替换。

构件通常采用带有两个小框的矩形表示。

节点(Node，结点)
节点(Node，结点)是指硬件系统中的物理部件，通常具有存储空间或处理能力 。例如，PC机、打印机、服务器、键盘、鼠标等。

在UML中，用一个立方体表示一个节点。
Rose中分为处理器节点和设备节点。

(2)行为事物

是UML模型的动态部分，用于描述描述事物之间的交互行为或事物的状态变化，在模型中经常用动词来表示。

常见的行为事物主要有3种:

1. 交互
2. 状态机
3. 活动

交互(interaction)
是指为了完成某个任务的一组对象之间相互协作，这种协作是通过消息的发送和接收来完成。

消息用一条有向直线来表示，源自消息发送者，指向接收者；有向直线上方要标注消息名称。

状态机(state machine)
是指在某个对象生命周期内，在事件驱动下，对象从一种状态迁移到另一状态的状态序列，这些状态序列构成了状态机。
状态机由状态、转移、事件、动作等组成。
在UML模型中，状态通常表示为一个圆角矩形，并在矩形内标识状态名称。

活动(activity)
描述了一个操作执行时的步骤序列。

在UML1中，将活动表示为一个大圆角矩形，并在图形内标识活动名称。 在UML2中，将活动表示为与状态类似的小圆角矩形，二者依靠语义区别。

(3)分组事物

分组事物是UML模型的组织部分，是用来对模型中各种组成部分进行分组的一种机制。

UML主要用 包(Package) 来对模型进行分组管理，一个包中包括多个相关的模型元素。

(4)注释事物

注释事物（annotation thing）是UML模型的解释部分，用来进一步描述、说明和标注模型的任何元素。简言之，就是对UML中元素的注释。

最主要的注释事物是注解(Note) ，用一个右上角折起来的矩形表示，解释的文本写在矩形中，用虚线连接到被解释的元素。

关系

UML模型是由各种事物以及这些事物之间的各种关系构成的。
关系是事物元素之间具体化的语义连接，负责联系UML的各类事物，构造出结构良好的UML模型。

四种基本关系

1. 关联
2. 泛化
3. 依赖
4. 实现

关联(Association)关系

是一种事物之间的结构关系，仅指出事物之间存在联系，
是所有关系中最通用、最弱的关系。
分类及其表示：
关联关系使用实线

普通关联关系

• 双向关联
  （无箭头）
• 单向关联。
  （有箭头）

特殊关联关系：

1. 聚集（聚合）：整体与部分间的松散关系
   （可以分离）
2. 组成（组合）：部分完全依赖于整体，关系密切
   （不可分割）
   表示
   

泛化(Generalization)关系

是事物之间的一种特殊/一般关系。特殊元素（子元素）的对象可替代一般元素（父元素）的对象。

泛化是继承的反动作。

表示
用带空心箭头的实线表示

例如

依赖(Dependency)关系

指的是两个事物之间的一种语义关系，当其中一个事物（独立事物）发生变化就会影响另外一个事物（依赖事物）的语义。

（一般就是指一个事物通过某种形式使用了另一个事物）

表示
用带实心箭头的虚线表示

实现(Realization)关系

描述了一组操作的规格说明和一组对操作的具体实现之间的语义关系。

使用实现关系有两种情况：

• 接口和实现接口的类或构件之间
• 用例和实现用例的协作之间

表示
用带空心箭头的虚线表示

图

图（Diagram）是一组模型元素的图形表示，是模型的展示效果。

分类
UML图根据基本功能和作用，可分为：

1. 结构图：捕获事物与事物之间的静态关系，用来描述系统的静态结构模型。

2. 行为图：捕获事物的交互过程如何产生系统的行为，用来描述系统的动态行为模型。

结构图（structure diagram）

(1) 类图（Class Diagram）
(2) 构件图（Component Diagram ，组件图/部件图）
(3) 对象图（Object Diagram）
(4) 部署图（Deployment Diagram ，配置图）
(5) 复合结构图（Composite Structure Diagram ，组合结构图/合成结构图）
(6) 包图（Package Diagram ）

行为图（behavior diagram）

(1) 用例图（Use Case Diagram ，用况图）
(2) 活动图（Activity Diagram）
(3) 状态机图（State Machine Diagram）
UML1中，被称作状态图（State Chart Diagram）。
(4) 通信图（Communication Diagram ，通讯图）
UML1中，被称作协作图(Collaboration Diagram，合作 图 ) 。
(5) 顺序图（Sequence Diagram ，序列图）
(6) 定时图（Timing Diagram ，时序图/计时图/时间图）
(7) 交互概述图（Interactive Overview Diagram ，交互概观/概况/概览图）

不同图 用于 不同开发阶段

• 分析: 通过用例捕获用户需求，创建用例图来描述系统的功能要求；对现实世界进行抽象，创建简单的概念类图，以描述它们的存在和关系；创建简单的活动图，以描述系统的业务流程。
• 设计：进一步细化类图，考虑系统中类的定义和细节；为实现用例、类之间的协作，用顺序图、通信图描述系统的动态模型。
• 实现：用面向对象编程语言，将设计阶段的类转换成实际的代码。
• 测试: 用UML 图作为测试依据，用类图指导单元测试，用组件图和通信图指导集成测试，用用例图指导系统测试。

注意

1. 在实际进行系统建模时，几乎没有人使用UML标准中定义的所有图。

2. UML 1.x与UML 2.x规范所包含的图数量不同，名称也有所变动。

最常用的UML图包括：
用例图、类图、顺序图、状态机图、活动图、包图、构件图和部署图。

UML 1.4的9种图
（必学）

（状态图和协作图名称改变）

UML 2.0的13种图
（必学包图）

状态图-->状态机图
协作图-->通讯图

用例图

描述了系统提供的一个功能单元。

类图
表示了不同的实体（人、事物和数据）是如何彼此相关联起来。

对象图

是描述对象及其关系的图，可以看作是类图在某一时刻的实例。由于对象存在生命周期，因此对象图只能在系统某一时间段存在。

顺序图
显示了一个具体用例或者用例的一部分的一个详细流程。
有两个维度：

• 垂直维度，也称时间维度，从上到下代表时间的延伸；
• 水平维度显示消息被发送到的对象实例。
  

通信图

侧重于描述各个对象之间存在的消息收发关系（交互关系），而不专门突出这些消息发送的时间顺序。

状态机图

表示某个类的对象所处的不同状态，以及该对象在这些状态中的转换过程。

（框中不应该写“状态”两个字，因此上面的“删除状态”表达是错的，应该删去“状态”两字）

活动图

用来表示两个或更多的对象之间 在处理某个活动时的过程控制流程。

(8) 包图****
是描述包及其关系的图，是一种维护和描述系统总体结构的模型，展现出系统的模块与模块之间的依赖关系。

构件图
根据系统的代码构件，显示了系统代码的物理结构。

部署图
表示该软件系统如何部署到硬件环境中，显示系统中的不同构件在何处运行以及如何通信。
可以利用这种图来部署实际的系统。

定时图

是一种特殊的顺序图。如果要表示的交互具有很强的时间特性，

常用于实时控制系统中。

（体现在门只开30秒）

交互概述图
是将活动图和顺序图嫁接在一起的图。

组合结构图
组合结构图用来描述系统中某一部分（即“组合结构”）的内部结构，以及该部分与系统其它部分的交互点（如端口和协议）。

规则

不能简单地把UML的构造块随意地放在一起。UML有一套规则，描述如何构建一个结构良好的模型。

规则是指用 UML描述事物时，每个元素应该遵守的规定，即用 UML 构造块描述软件系统中事物时应该遵守的规定。

常见规则：

1. 名称。 为事物、关系和图起的名字。
   （关系可以省略名称）

2. 范围。 使名称具有特定含义的语境，即每个元素符号使用的范围。
   （类似于程序设计中变量的作用域）

3. 可见性。 元素符号被访问的级别或者权限，例如public、private。
   （类似于程序设计中的访问修饰符）

4. 完整性。 元素符号应该代表完整的含义，即事物如何正确、一致地相互联系。

5. 可执行。 元素符号能够运行或模拟一个动态模型。

公共机制

在UML语言中，有4种贯穿整个语言且一致应用的公共机制：

1. 规格说明(规约/详述)
2. 修饰
3. 通用划分
4. 扩展机制
   扩展机制可以再划分为 构造型(衍型) 、 标记值 和 约束。

注意通常，把1.规格说明、2.修饰 3.通用划分 看作是UML的通用机制。

规格说明

规格说明(Specification)
就是对模型元素的图形符号，用属性或文字形式进行详细描述。

属性： 使用 名称和标记值 定义。

文字
对图形符号以文字形式进行详细描述，例如：用例规约”

修饰(Adornment)

模型元素的符号对事物最重要的方面提供可视化表示。在规格说明的基础上，要把元素的细节方面表示出来，必须通过文字或图形对元素进行修饰。

注解是一种非常重要且能单独存在的修饰符。

通用划分(General Division)

通用划分是一种保证不同抽象概念层次的机制。

通常可以采用两种方式进行通用划分，

1. 类和对象的划分
   是指类是一个抽象，而对象是这种抽象的一个实例化(一个类型可以有多个实例)。

2. 接口和实现的分离
   是指接口声明了一组操作，告知外界其可以提供的服务，但是却不负责实现其内容；而实现则表示了对该操作的具体实现过程。

扩展机制

扩展机制包括构造型、标记值和约束。

构造型(StereoType)

构造型是基于一个已存在的模型元素，进行修改或精化，创造出一个新的模型元素。
构造型的一般表现形式为使用“<<”和“>>”括起来构造型的名称。
例如<<use>>、,<<extends>>。

标记值(Tagged Value)

标记值用来为事物(元素)添加新特征。

表现形式：标记名=标记值

约束(Constraint)

扩展UML模型元素的语义，允许用户增加新的语义条件或限制，表达了附加在元素上的额外语义信息。
表现形式：{ 约束的内容 }
表达方式

1. 使用自然语言进行描述
2. 利用规范的对象约束语言表达
   对象约束语言(Object Constraint Language, OCL)
   OCL是一种能够使用工具进行解释的表达UML约束的标准方法。

“4+1”架构

视图（View）

一个图只能反映系统中某个侧面和特征，多个图结合在一起可以反映系统的某些侧面和多个特征。
定义
能反映系统某些侧面和特征的多个图的集合称为视图。

UML利用模型来描述系统的结构(静态特征)和行为(动态特征)，它从不同的视角为系统的架构建模形成系统的不同视图。

通常将UML视图模型划分为4大领域8种视图，如表所示。

RUP“4+1”架构方法
采用用例驱动,在软件生命周期的各个阶段对软件进行建模,从不同视角对系统进行解读,从而形成统一软件过程(Rational Unified Process)架构描述。

在“4+1”视图模型中，软件开发者从五个不同视角描述软件体系结构的一组视图模型。

组成

1. 逻辑视图——类图
   分解系统功能，负责反映出系统内部是如何组织和协作来实现功能的。

2. 开发视图——组件图
   用来描述软件的各个模块的组织方式，包括源程序、程序包、第三方库等。

3. 进程视图——顺序图、协作图(通信图)、状态(机)图、活动图
   主要描述系统的运行特性，关注进程、线程、并发、同步等运行时概念。

4. 物理视图——部署图
   主要描述硬件配置，综合考虑软件系统和安装、运行环境。

5. 场景视图——用例图
   从项目需求入手，将四个视图结合为一个整体，是所有视图的核心。
   逻辑视图、开发视图、进程视图、物理视图，这四个视图的元素需要协同工作以实现场景视图中给出的用例。

场景视图是距离用户需要最近的视图，也是软件开发中的重要驱动要素。

“4+1”架构要解决的问题

从工程上简化一个问题，一种首要的思路就是分而治之。通常使用的分而治之策略有分层法、模块法等等。
其中，对于模块法而言，对于每个模块实行不同的较为单一的操作，透明化模块内部的信息，是一种重要的方法论。

“4+1”视图方法是一种架构设计的多重视图方法，属于一种特殊的模块法。

运用“4+1”视图方法进行软件架构设计

1. 首要问题：需求
2. 首要视图：场景视图
3. 逻辑视图：细化场景描述问题
4. 进程视图、开发视图、物理视图：针对不同方面，解决问题