UML 精粹：标准对象建模语言思维导图模板

状态机图

系统行为

控制器举例

3个状态

Wait（等待）

Lock（上锁）

Open（打开）

图10.1 一个简单的状态机图

子主题

转换（transition）

一个状态到另一个状态的转移

内部活动

内部活动（internalactivity）

把事件、警戒条件和活动放在状态框里面

自转换（self-transition）

转回到同一状态的转换

一个文本域的typing（输入中）状态的内部事件展示

子主题

两个活动

入口活动

entry activity

无论何时进入一个状态都要执行

出口活动

exit activity

无论何时离开一个状态都要执行

内部活动不触发入口活动和出口活动

活动状态

activity state

持续进行的活动

do/

术语

do-活动

do-activity

图10.3 带活动的状态

子主题

超状态

若干状态共享共同的转换和内部活动

子状态

若干状态

超状态

共享行为

图10.4 带有嵌套子状态的超状态

子主题

并发状态

状态

被分解

若干正在并发运行

正交状态图

历史伪状态

history pseudostate

所指向的状态

没有历史时

第一次进入

应该进入哪个状态

图10.5 并发正交状态

子主题

实现状态图

3种方式

嵌套switch

子主题

状态模式

state pattern

创建状态类层次来处理状态的行为

每个状态都有一个状态子类

控制器

针对每一个事件的方法

转发给状态类

图10.7 图10.1的状态模式实现

子主题

层次

顶层

一个抽象类

具体状态

覆盖状态有转换的特定事件方法

状态表

state table

捕获状态图信息为数据

图10.1的状态表

子主题

运行时状态表

修改

无须重新编译

何时使用状态图

擅长

跨越若干用例的对象的行为

不擅长

涉及许多对象协作的行为

和其他技能结合很有用

例如

交互图

单个用例中的若干对象的行为

活动图

展示若干对象和用例的通用活动序列

更多资料

《UML用户指南》[Booch，UML user]

《UML参考手册》[Rumbaugh，UML Reference]

活动图

描述过程逻辑、业务流程和工作流的技术

类似于流程图

区别

支持并行行为

图11.1 一个简单的活动图

子主题

初始节点

initialnode

开始动作

分叉

fork

一个进入流

若干离开的并发流

序列不相关

可以

填写订单

发送发票

交付

接收付款

也可以

发送发票

接收付款

填写订单

交付

结合

join

所有进入流到达结合时

离开流才会执行

判断

decision

分支

单个进入流

若干带警戒的外向流

每个外向流有一个警戒条件

合并

多个输入流

单个输出流

由判断开始的条件行为结束

允许

该流程

任何人

选择做事情的次序

分解一个动作

子活动

动作可以分解为子活动

动作

可以实现为子活动或者类的方法

图11.2 一张次级的活动图

子主题

靶子符

子主题

耙子符号

展示子活动

方法上的调用

语法class-name：：method-name

被调用的行为不是单个方法调用

在动作符号里写一个代码片段

分区

展示谁做什么

哪一个动作由哪一个类或组织单元执行

把活动图划分为分区

图11.4 活动图上的分区

子主题

简单的一维分区

泳道

这种风格

二维网格

针对每一个维度层级划分行或列

信号

时间信号

time signal

因为时间的流逝而发生

可以指示

财务周期中的月末

实时控制器的每一微秒

信号

signal

该活动从一个外部进程接收一个事件

监听信号的活动

接收信号

图11.5 活动图上的信号

子主题

在航班离开前2个小时

开始打包

即使我收拾得足够快

还是不能离开

直到出租车到达

发送信号

不得不发送一个消息

等待回复才能继续

图11.6 发送和接收信号

子主题

两个流在竞赛

第一个到达终止状态

将获胜

终止其他流

接受

等待一个外部事件

展示

一个进入它们的流

流触发了接受

才开始监听

令牌

初始节点

创建一个令牌

传给下一个动作

动作执行

传给下一个

分叉处

一个令牌进入

每一个向外的流上产生一个令牌

结合处

每一个向里的令牌到达，没有任何事情发生，

直到所有令牌出现在结合处

流和边

两个动作之间
的连接

流

flow

一个简单的箭头

边

edge

沿着边传送对象

边上放一个类框

连接器

连线上有困难

不必画一条穿过整张图的线

必须成对使用

进入流一个

离开流一个

两者标签相同

尽可能避免使用连接器

破坏了控制流的可视化

图11.7 展示边的4种方式

子主题

针脚和变换

针脚

为动作

展示参数信息

确保

向外动作的输出参数

匹配

另一个动作的输入参数

转换

transformation

图11.8 流上的变换

子主题

扩展区域

expansion region

标记活动图的一个区域

在该区域里

动作为一个集合中的

每个条目执行一次

图11.9 扩展区域

子主题

输出集合的条目数和输入集合的条目数相同

条目变少

扩展区域

过滤器的角色

图11.10 扩展区域中的单个动作的速记

子主题

只有单个需要多次调用的动作

流结束

flow final

一个特定流的结束

不终止整个活动

图11.11 活动中的流结束

子主题

结合规格

默认的

所有输入流到达一个结合

执行通过它的向外流

正式的说法

当每个输入流上的令牌都到达时，

它释放出一个它的输出流上的令牌

结合规格

一个附加到结合上的布尔表达式

图11.12 结合规格

子主题

何时使用活动图

支持和鼓励并行行为

更多资料

http://www.daimi.au.dk/PetriNets/

通信图

communication diagrams

交互图的一种

强调

交互的各种参与者之间

数据链接

不像序列图

每一个参与者画成生命线并按垂直方向展示消息序列

允许自由放置参与者

通过画链接来展示参与者如何连接

使用编号来展示消息序列

UML 1.x中

被称为协作图

collaborationdiagrams

图12.1 中央控制的通信图

子主题

瞬时链接

展示关联实例的链接

只在交互上下文中出现

«local» 链接

一个局部变量

图12.2 嵌套小数编号的通信图

子主题

除了编号

也可以在消息上放置字母

代表不同的控制线程

何时使用通信图

依赖于个人偏好

序列图

强调调用序列时

通信图

强调链接时

组合结构

部件

part

把一个复杂的对象分解为部件

供给和需求接口

小球-球窝表示法

图13.1 展示TV Viewer及其接口的两种方式

子主题

图13.2 组件的内部视图（来自Jim Rumbaugh的例子）

子主题

类如何在内部分解为两个部件

发生器部件

generator

控制部件

control

部件

name：class的形式命名

不是实例规格

用粗体表示

不是用带下画线表示

图13.3 带多个端口的组件

子主题

何时使用组合结构

包和组合结构的区别

包

编译时分组

组合结构

展示运行时分组

组件图

图14.1 组件的表示法

子主题

图14.2 组件图例子

子主题

till（收银台）使用sales message（销售消息）接口，
通过消息队列连接到Sales Server（销售服务器）组件。
该消息队列既供应salesmessage接口来和收银台交流，
还需要该接口和服务器交流。服务器分解成两个主要组件，
transaction processor（事务处理器）组件实现sales message接口，
accounting driver组件和accounting system交流。

组件

不是一种技术

关注

顾客要如何与软件发生关系

顾客要能够每次购买一小片软件，
能够像升级音响一样升级软件

新的小片能无缝地和旧的小片一起工作

按照他们自己的进度升级

小心过细粒度的组件

太多组件

难以管理

“DLL地狱”

何时使用组件图

展示它们通过接口的相互关系

把组件分解为更低级别的结构

协作

命名体系

participant-name/role-name：class-name

图15.1 带角色类图的协作

子主题

拍卖中，
可以有一个卖家（seller）、
一些买家（buyer）、
许多要拍卖（lot）的货物
和一些出价（offer）

不是十分常见的类图

首先

被一个虚线的椭圆包围

椭圆代表拍卖协作

其次

协作中的所谓的类不是类

而是应用协作时要实现的角色（role）

图15.2 拍卖协作的序列图

子主题

图15.3 协作发生

子主题

从协作到那些类的链接表明类如何扮演协作定义的各种角色

何时使用协作

一种有竞争力的图形类型

图15.4 展示JUnit（junit.org）中模式使用的非标准方式

子主题

交互概述图

嫁接

活动图

序列图

活动图

其中的活动替换为了小的序列图

序列图

被活动图表示法打碎

展示控制流

何时使用交互概念图

图16.1 交互概述图

子主题

取决于哪一种图能更好地为你的目的服务

时间图

另一种形式的交互图

焦点

时间约束

场景

咖啡壶的泵和电炉

规则

泵开始工作和电炉开始工作之间的间隔至少要10秒

当盛水容器变成空的时，泵关闭

电炉不能继续打开超过15分钟

时间约束的可选方式

图17.1 展示状态为线的时间图

子主题

图17.2 展示状态为区域的时间图

子主题

何时使用时间图

展示不同对象上的状态改变之间的时间约束

简介

UML 是什么

统一建模语言

一组图形表示法

元模型

共同

帮助

描述和设计软件系统

特别是

面向对象（OO）风格建造的软件系统

比较开放的标准

由对象管理组织（OMG）控制

OMG

各公司组成的联盟

成立的目的

建立支持互操作性的标准

CORBA（通用对象请求代理架构）标准

使用 UML 的方式

三种模式

草稿

目的

帮助沟通想法

展示所要做事情的可选方案

蓝图

正向工程

编写代码之前画

逆向工程

从已有代码建造UML图

帮助理解代码

解释系统的某些部分如何工作

不用展示每一个类

只需展示那些令人感兴趣的、在深入到代码之前值得讨论的类

完整性

编程语言

工具

双程（round-trip）工具

可以做正向和逆向工程的工具

无转换（tripless）工具

使用源代码本身作为存储器

把图当做代码的图形视角

蓝图和草稿区别

草稿

不完整

强调重要信息

探索性的

蓝图

全面

目的

把编程缩减成简单的机械活动

定义性的

模型驱动架构和可执行UML

模型驱动架构

MDA

使用UML作为编程语言的标准方法

由OMG控制

MDA使用UML作为其基本建模语言

工作划分为两个

平台无关模型

Platform Independent Model

PIM

平台特定模型

Platform SpecificModel

PSM

针对特定执行环境

系统模型

是UML，也可以不是

完全自动化

从PIM到PSM再到最终代码的过程

可执行UML

Executable UML

类似于MDA

不使用完全的UML标准

架构型（archetype

如何把可执行UML模型转换到特定编程平台

三种行为建模方法

交互图

状态图

活动图

软件视角

software perspective

概念视角

conceptual perspective

对所研究领域概念的描述

UML 诞生史

首次引发

催化剂事件

Jim Rumbaugh离开GE加盟Grady Booch所在的Rational

“以微软的方式”达成标准化

在OOPSLA'95大会上

Grady和Jim

统一方法文档版本0.8

1997年1月

各种组织一起提交了方法标准的建议书

UML文档版本1.0

UML

第一次被

统一建模语言

OMG

1.1版本

官方的OMG标准

1.2完全是走走过场

1.3更加重要

1.4围绕组件和扩展机制添加了许多详细的概念

1.5添加了动作语义

UML

功劳

GradyBooch、

Ivar Jacobson

和Jim Rumbaugh

表示法和元模型

表示法

notation

在模型中看到的图形

建模语言的图形语法

元模型

meta-model

一张定义语言概念的图

类图

UML图

13种官方图形类型

图

结构图

类图

类、特性和关系

组件图

组件的结构和链接

组合机构图

类的运行时分解

部署图

工件部署到节点

对象图

实例的配置例子

包图

编译时层次结构

行为图

活动图

顺序和并性行为

用例图

用户如何和系统交互

状态机图

对象在生命期中如何被时间改变

交互图

序列图

对象之间的交互

强调顺序

通信图

对象之间的交互

强调链接

交互概念图

序列图和活动图的混合

时间图

对象之间的交互

强调时间

什么是合法的UML

UML的规则

描述性的

descriptive rules

人们在实践中如何使用该语言来理解它的规则

强制性的

prescriptive rules

官方控制

官方说明

什么是合法

什么是不合法

这门语言所发表言论的含义是什么

仅有 UML 是不够的

决策表

子主题

展示复杂逻辑条件

用活动图代替

情况比较复杂

决策表会更加精练和清晰

子主题

何处开始 UML

首先

基本形式的类图和序列图

掌握了上面

开始使用一些更高级的类图表示法

开发过程

从一堆OO分析和设计方法

混合了图形建模语言和描述如何开发软件的过程

Rational统一过程

RUP

一个过程

可以使用UML的过程框架

迭代和瀑布过程

瀑布风格

基于活动来分解项目

不得不做某些活动

需求分析

设计

编码

测试

迭代风格

根据功能子集来分解项目

把一年分解为3个月的迭代

第一个迭代

处理1/4的需求

对这1/4做完整的软件生命周期

分析、设计、代码和测试

结束时

拥有了一个做了1/4所需功能的系统

再做第二个迭代

6个月结束时

完成一半功能的系统

一个项目

多个发布（release）

每一个发布又分解到若干迭代（iteration）

许多名字

增量、

螺旋、

演进

和极可意（Jacuzzi）

阶段交付

McConnell

stageddelivery

先以瀑布风格做完分析和高级别设计

然后把编码和测试划分到迭代中

常见技能

时间盒（time boxing）

强迫每个迭代有固定长度的时间

自动化回归测试

automated regression test

快速检测任何可能引进的缺陷

xUnit家族测试框架

http://junit.org

重构

refactoring

有纪律地改变现有软件的技能

对代码基变换

一系列小的

行为保留

http://www.refactoring.com

持续集成

continuous integration

保持团队同步

避免痛苦的集成周期

核心

完全自动化的构建过程

预测性和自适应计划

敏捷过程

Rational 统一过程

遵循4个阶段

初始（inception）阶段

项目初始估计

决定是否投入足够的资金来做细化阶段

细化（elaboration）阶段

识别项目的首要用例

迭代建造软件

最后

构造（construction）阶段

继续建造

开发足够发布的功能

移交（transition）阶段

各种后期阶段的活动

部署到数据中心、用户培训等

为项目剪裁过程

因素

建造的系统的种类

使用的技术

团队的规模和分布

风险的本质

失败的后果

团队的工作风格

组织的文化

改编过程以适合你的特定环境

模式

UML

表达面向对象设计

模式

过程的结果

例子设计

书籍

Gang of Four

23种设计模式

POSA1

POSA2

Core J2EE Patterns

Pont

不只是模型

还包含

为什么这样做的原因

为过程裁剪UML

需求分析

用例

人们如何与系统交互

类图

概念视角画类图

活动图

组织的工作流

展示软件如何与人类活动交互

为用例展示其上下文

状态图

一个概念

一个有趣的生命周期

各种状态和改变状态的事件

设计

类图

从软件视角展示软件中的类

它们如何互联

序列图

常用场景的

从用例中挑选最重要和最有趣的场景

使用

序列图

CRC卡

弄清楚软件中发生了什么

包图

展示软件的大规模组织

状态图

有复杂生命历史的类

部署图

展示软件的物理布局

文档

UML

归档已经做的事情

包图

描绘系统的逻辑路线

帮助我理解系统的逻辑块

看到依赖并保持依赖受控

包内部

一张类图

不展示每个类上的每个操作，只展示帮助我理解内容的重要特性

一些交互图

支持这张类图

展示系统中最重要的交互

状态机图

如果一个类有复杂的生命周期行为

理解遗留代码

序列图

查看处理复杂的方法时多个对象如何协作

更多资料

敏捷社区

Highsmith

Cockburn，agile]

极限编程（XP）

http://xprogramming.com

http://www.extremeprogramming.org

Beck and Fowler

类图

描述系统中的对象类型

存在于它们之间的各种静态关系

展示类的

性质

操作

应用于对象连接方式的约束

特性（feature

UML

一个通用术语

覆盖

类的

性质（property）

操作（operation）

订单处理的例子

方框是类

分为三栏

类的名字（粗体）

类的性质

类的操作

类之间的两种关系

关联

和泛化

子主题

性质

类的结构特性

粗略看做

类中的字段

两种十分不同的表示法

属性

attribute

类方框中的一行文本

name

类如何引用属性

对应于编程语言中的字段名

visibility

公开的（+）

私有的（-）

type

一种对象可以被放进属性的限制

编程语言中的字段类型

multiplicity

default value

创建期间没有指定值时新创建对象的值

{property-string}

属性附加的性质

{readOnly}

客户不可以修改该性质

小的东西使用属性

和关联

同一性质的两种不同表示法

一根两个类之间的实线

方向

从源类到目标类

性质的名称及多重性放在关联的目标端

目标端

链接到性质所属类型的类

两种不同表示法

子主题

关联

更重要的类，使用关联

多重性

multiplicity

多少对象可以填充该性质

最常见的多重性

1

（一张订单必须有且只有一名顾客。）

0..1

一名企业顾客

可能有一名销售代表，

也可能没有销售代表

＊

一名顾客

不需要下订单

但顾客下的订单数量没有上限

零

或者更多张订单

更常见的多重性

一个下限

任何正整数

或零

一个上限

任何正整数

或*（无限）

如果下限和上限是同一个数

使用一个数

canasta纸牌游戏有2..4个玩家

多重性的术语

Optional

可选的

下限0

Mandatory

强制的

下限为1

可能更多

Single-valued

单值的

上限为1

Multivalued

多值的

上限大于1

通常是*

双向关联

子主题

一对性质

Car类有性质owner：Person[0..1]

Person类有性质cars：Car[＊]

cars性质

性质类型的复数形式

子主题

动词短语给关联加标签

关系可以用一句话来表达

子主题

操作

类知道如何执行的动作

操作的完整UML语法

visibility

公开的（+）

私有的（-）

name

一个字符串

parameter-list

操作的参数列表

direction name : type = default value

direction

输入（in）

输出（out）

兼有（inout）

默认

输入（in）

return-type

返回值的类型

如果有的话

property-string

应用到给定操作的性质的值

子主题

辨别操作

改变系统状态

修改器（modifier）

也称为命令

不改变系统状态

查询（query）

方法

获取方法（getting method）

返回来自字段的值

设置方法（setting method）

把值放进一个字段

操作和方法的区别

方法

知识完全在类的内部

修改器是不是设置方法

操作

对象上可以调用的某些东西

方法

例程体

多态情况

一个超类型有3个子类型

每一个子类型都覆盖超类型的getPrice操作

一个操作和4个实现它的方法

泛化

典型例子

做生意时的个人和企业顾客

差异

相似

超类

放进一个通用的Customer类（超类型）中

子类

Personal Customer（个人顾客）

Corporate Customer（企业顾客）

高效使用继承

重要原则

可替换性

substitutability

注释符和注释

注解符

图中的注释

可以单独存在

也可以通过虚线链接到所注释的元素

可以出现在任何类型的图中

依赖

dependency

如果改变一个元素的定义会导致改变其他类，两个元素之间就存在

各种原因

一个类发送消息给另一个类

一个类拥有另一个类作为其数据的一部分

一个类把另一个类当成操作的参数

如果一个类改变其接口

任何发送给该类的消息可能都不再有效

子主题

依赖只有一个方向

表示类到领域类

许多种依赖

每一种都有特定的语义和关键词

call

源调用目标元素的操作

create

原创建目标的实例

dervie

源从目标诞生

instantiate

源是目标的实例

permit

目标允许源访问目标的私有特性

realize

原生目标所定义的规格或接口的实现

refine

精化指不同语义级别的关系

源可能是射击类

目标对应分析类

substitute

源可以替代目标

trace

用于跟踪类似需求到类

或一个模型中的变更如何链接到其他地方

use

源的实现需要目标

通用规则

最小化依赖

避免环状依赖

阐述瞬时的关系

例如当一个对象被传递给另一个对象作为参数

约束规则

允许你使用任何东西来描述约束

唯一的规则

放进花括号（{}）

契约设计

核心

断言（assertion）

决不应该为假的布尔陈述

假的唯一原因是存在bug

3种特定的断言

后置条件

应用于操作

post-condition

操作执行后世界看起来应该像什么样子

我们做什么而不说我们怎么做的一种有用的方式

将接口从实现分离

前置条件

应用于操作

pre-condition

期望在执行操作前世界是什么样子

显式指出调用者负责检查

不变式

关于类的断言

对于类的所有实例来说，这个不变式“总是”为真

异常

exception

何时使用类图

UML的骨架

被过度使用提示

不要尝试使用所有可用的表示法

尽量把软件排除在讨论范围之外

不要为每个东西都画模型

集中于关键区域

序列图

交互图（interaction diagram）

描述对象组在某些行为中如何协作

序列图

捕获单个场景的行为

场景

我们有一个订单，打算调用其上的一个命令来计算它的价钱。
为此，需要查看订单上的所有订单行条目，决定它们的价钱，
价钱基于订单行的产品的定价规则。针对所有订单行条目做这个计算后，
订单需要计算出一个整体的折扣，折扣规则和顾客有关

子主题

每一个参与者有一条生命线

垂直地沿着页面朝下运行

消息也沿着页面向下排序

订单实例发送getQuantity和getProduct消息给订单行

每条生命线都有一根激活条

在交互中参与者何时是活动的

可选

称为寻获消息（found message）

没有发送它的参与者

来自一个不确定的源

参与者

participant

语法

name：Class

基础

创建和删除参与者

创建一个参与者

把消息箭头直接画进参与者方框

“new”来标记它

参与者的删除

大的×表示

一个参与者显式删除另一个

一个消息箭头指向×

删除自身

生命线末端的×

子主题

循环、条件等

交互框

标记一小块序列图的方法

子主题

每个框有一个操作符

每一个片断可以有一个警戒条件

循环

loop操作符

循环条件放在警戒条件的位置

条件逻辑

alt操作符

条件放在每一个片断之上

只有一个区域

opt操作符

只有警戒条件为真的片断会执行

交互框常见操作符

alt

多选的一个片断

只有条件为真会执行

opt

可选的

该片段旨在所有条件为真时执行

par

并行

每个片断并行运行

loop

循环

片断可以执行多次

警戒条件表示循环的条件

region

关键区域

片断一次只有一个线程执行

neg

否定

片断展示无效的交互

ref

引用

引用到另一张图中定义的交互

画一个框盖住交互涉及的生命线，可以定义参数和返回值

sd

序列图

全出一个完整的序列图

UML1

迭代标记

一个添加到消息名称的*号

iterationmarker

警戒条件

guard

放在方括号中的条件表达式

消息只有在警戒条件为真时发送

同步和异步调用

同步消息

synchronous message

必须等待，直到消息完成，就像调用一个子程序

异步消息

asynchronous message

继续进行其他处理

不必等待响应

多线程应用

面向消息的中间件中看到异步调用

更好的响应性，减少瞬时的耦合，但更难以调试

何时使用序列图

查看单个用例内若干对象的行为时

CRC卡

Class-Responsibility-Collaboration

子主题

进阶

关键词

UML接口

interface

一个类

只有公开的操作

没有方法体

带关键词«interface» 的类

关键词

展示为双尖括号之间的文本

«interface»

«I»

{abstract}

{A}

扩展机制

profile

为了特定目的使用一组相关的构造型

例如业务建模

扩展UML的某个部分

责任

子主题

作为注释字符串在自己的栏中展示

静态操作和属性

应用于类而不是实例的操作或属性称为静态的（static）

子主题

静态特性在类图中带下画线

聚合和组合

聚合

aggregation

是“……的一部分”的关系

例如

汽车有引擎和轮子作为它的部件

子主题

组合

composition

虽然一个类可以是许多其他类的组件

但任何实例都必须是唯一拥有者的组件

子主题

Point（点）的实例可以是Polygon（多边形）的一部分

或者可以是Circle（圆）的圆心

但不能二者皆是

“无分享”

如果你删除Polygon

应该自动地确保任何它所拥有的Point也被删除

聚合没有严格的含义

派生性质

derived property

基于其他值计算出来

指明计算值和存储值之间的区别

比如

日期范围

开始日期

结束日期

这段时期内的天数

存储值

开始日期和结束日期

计算值

日期长度

子主题

在名称上标记一个/

接口和抽象类

抽象类

abstract class

不能被直接实例化的类

有一个或多个抽象操作

把名称变成斜体

抽象操作

abstract operation

没有实现

纯声明

接口

没有实现的类

所有特性都是抽象的

关键词«interface» 来标记

类跟接口之间有两种关系

供给

类可以替换接口

类供给一个接口

provides an interface

需求

类需要一个接口的实例才能工作

类需要一个接口

requires an interface

ArrayList本身是AbstractList类的子类

完全表示法

子主题

简洁表示法

子主题

只读和冻结

只读

{readOnly}

只能读取不能更新的

冻结

{frozen}

性质在对象的生命期内不能改变

不可变的

可以标记个别性质为冻结

也可以把该关键词应用到一个类

指明所有实例的所有性质都是冻结的

引用对象和值对象

引用对象

reference object

值对象

value object

关键词

«value»

«struct»

数据类型

data type

限定关联

qualified association

UML里

数组

图

哈希

词典

子主题

在Order上每个Product有单个Order Line

限定符

表达Order（订单）和Order Line（订单行）类之间的关联的一种方式

在和一个Order的连接中，对于每一个Product（产品）实例，可能会有一个Order Line

分类和泛化

分类

classification

对象和它的类型之间的关系

泛化

generalization

传递性的

多重和动态分类

单个分类

single classification

对象属于单个类型

可能从超类型继承

多重分类

multipleclassification

对象可以由若干类型描述

这些类型未必通过继承连接

子主题

多重继承

一个类型可以有许多超类型

必须为每一个对象定义单个类型

泛化集

类图

泛化箭头上加上泛化集名称的标签

UML 1

鉴别器

把每一个泛化关系放进一个泛化集

默认不相交

任何超类型的实例可以是泛化集中唯一一个子类型的实例

类型结合

动态分类

dynamic classification

允许对象在子类型化结构内改变类

静态分类

static classification

不允许

类型和状态被分离

关联类

http://martinfowler.com/ap2/timeNarrative.html

association class

允许你给关联添加属性、操作和其他特性

子主题

一个人可以参加许多会议

如果

记录人们开会的时候有多清醒

给关联添加属性attentiveness（专注程度）

子主题

模板（参数化）类

参数化类

parameterized class

模板

template

子主题

绑定元素

子主题

Set<Employee>

派生（derivation）

形式

<parameter-name：：parameter-value>

«bind» 关键词

EmployeeSet会遵从Set接口

枚举

用于展示一个固定集合的值

除了它们的符号值没有其他任何性质

«enumeration»

子主题

主动类

active class

有实例

每个实例执行和控制它自己的控制线程

方法调用

客户的线程

或主动对象的线程

执行

子主题

例子

命令处理器

从外部接受命令对象

在它自己的控制线程内执行命令

可见性

visibility

简单认识

任何类都有公开和私有的元素

公开元素

被任何其他类使用

私有元素

只能被拥有它的类使用

每一种语言都有自己的规则

UML

可见性标记

+（公开）

-（私有）

～（包）

＃（保护）

消息

子主题

依赖箭头

关联类

实线箭头

非关联类

虚线箭头

不需要到类的关联来发送消息给类

标记说明

箭头上的标签

一个对象发送到另一个对象的消息

对象图

object diagram

某时间点上的对象在系统中的快照

展示实例

不是类

被称为

实例图

子主题

对象的配置案例

一组类

6.2 展示Party实例的对象图

对象之间的可能连接比较复杂时

元素是实例

名称带下画线

每个名称的形式都是“实例名 ∶ 类名”

元素

实例规格

不是真正的实例

实例规格

instance specification

部分定义的实例

可看做没有消息的通信图

何时使用对象图

展示连接在一起的对象

包图

包

一种分组构造

允许选择UML里的任何构造

把它的元素组织在一起

成为更高级别的单元

最常见的用法

组织类

UML模型中

每一个类都是单个包的成员

包也可以是其他包的成员

一个具有层级的结构

顶层包分解为子包

子包又有它们自己的子包等

直到层级的底部只有类

一个包中可以包含子包和类

编程术语

每个包代表一个命名空间（namespace）

每一个类在拥有它的包里必须有唯一的名称

7.1 在图上展示包的方式

包中的类

公有的

或私有的

两个原则

共同封闭原则

包中的类

相似的原因改变

共同复用原则

包中的类

一起被复用

包分组

包之间的依赖

包和依赖

包图

package diagram

包和包之间的依赖

控制系统的大规模结构

好的包结构

清晰的依赖流

7.2 企业应用包图

所有依赖运行在单个方向上

数据映射器

这个经验法则的一个异常

领域和数据库包之间的隔离层

映射器模式[Fowler，P of EAA]

无环依赖原则[Martin]

作者认为

环应该局限在一个范围内

不应该有跨层的环

稳定依赖原则[Martin]

有越多依赖进入一个包

该包的接口就需要越稳定

接口的任何改变都会波动到所有依赖于它的包

leasing data mapper（租赁数据映射器）包

assetdomain（资产领域）包需要更稳定的接口

依赖关系不是传递性的

如果一个asset domain包中的类改变了

可能要改变leasing domain（租赁领域）包内部的类

这个改变不一定波动到leasing presentation（租赁表现）包

«global»

包的分解

两种结构

图7.2

子主题

图7.3 把图7.2分离成两个部分

子主题

应用的分层结构

表现

领域

数据映射器

数据库

主题区域结构

租赁

资产

实现包

一个包定义了一个可以被许多其他包实现的接口

图7.4 被其他包实现的包

子主题

DatabaseGateway（数据库入口）

定义了一个接口

其他入口类提供实现

Database Gateway包所包含的接口和抽象类完全由其他包实现

何时使用包图

大规模系统

系统主要元素之间的依赖关系

绘制包和依赖的图

对应用依赖的控制

代表编译时的分组机制

更多资料

[Martin]

RobertMartin

部署图

展示系统的物理布局

揭示哪个软件运行在哪个硬件上

通信路径连接的节点

部署图说明

节点（node）

能驻留一些软件的环境

两种形式

设备（device）

硬件

计算机

硬件部件

更简单的、连接到一个系统的

执行环境（executionenvironment）

软件

包含其他软件

例如

操作系统

或容器进程

包含工件（artifact）

工件

软件的物理显现

通常是文件

可执行的

.exe文件，二进制、DLL和JAR文件，程序集或脚本

数据文件

配置文件

HTML文档等

表示方法

用类方框

添加一个文档图标

或者 «artifact» 关键词

或者通过列出节点内的名称

用标记值标记节点或工件，来表示各种关于节点的有趣信息

例如厂商、操作系统、位置或任何其他你感兴趣的事情

图8.1 部署图实例

number deployed

三个物理的Web服务器

子主题

何时使用部署图

什么地方部署了什么

复杂一点的部署

用例

用例介绍

捕获系统功能需求的技能

描述系统用户和系统本身的典型交互

系统如何被使用的说明

通过描述场景

场景（scenario）

描述用户和系统之间交互的步骤序列

用例（usecase）

通过共同用户目标绑在一起的场景集合

执行者（actor）
角色

用户扮演的跟系统相关的角色

执行用例

例如

顾客

客服代表

销售经理

产品分析师

单个执行者可以执行许多用例

一个用例可能有若干执行者执行

多人可以扮演一个执行者

一个人也可以扮演执行者

执行者不一定是人

系统为另一个计算机系统提供服务

其他系统就是执行者

合适的术语

角色

用例的内容

图9.1 用例文本实例

子主题

主成功场景（main success scenario）

挑选场景之一

书写用例体

把主成功场景书写为编号的步骤序列

书写其他场景作为扩展（extension）

描述主成功场景上的变化。

继续扩展——直到用户达到目标

每个步骤

执行者和系统之间的交互元素

用例中的扩展

命名了一个条件

描述

和主成功场景

不同交互

差异是什么

首先

条件被检测的步骤

提供短的条件描

之后

步骤

描述在何处返回到主成功场景完成这些步骤

用例结构

用头脑风暴法产生

用例中复杂步骤

变成另一个用例

第一个用例包含（includes）第二个用例

重复的步骤

被包含用例

不要使用功能分解方法

分解

用例为

子用例

和子子用例

用例

共同信息

前置条件（pre-condition

系统允许

用例开始之前

确保为真的东西

保证（guarantee）

用例结束

系统

确保的东西

例如

成功场景

成功保证

任何场景

最小保证

触发器（trigger）

规定

触发用例开始

事件

用例图

图9.2 用例图

子主题

方法

用例集内容的图形目录

展示系统边界和外部世界的交互

执行者、用例和它们之间的关系

哪个执行者执行哪个用例

哪个用例包含其他用例

用例的级别

系统用例

system use case

和软件的交互

业务用例

business use case

讨论业务如何响应顾客或事件

用例的级别结构

[Cockburn，use cases]建议

海平面级别

sea-level

主执行者和系统之间独立的交互

对主执行者有价值的东西

鱼级别

fish level

被海平面级别用例包含的用例

风筝级别

kite-level

比海平面级别更高级别的用例

用例和特性（或故事）

助描述需求

先开发用例

然后生成特性列表

特性可能是

整个用例

用例中的场景

用例中的步骤

或一些行为变体

例如

为你的资产评估添加另一个折旧方法

何时使用用例

帮助理解系统功能需求的有价值的工具

项目早期

粗略地描述每个用例

开发该用例之前

详细的版本

用例表达系统的外部视图

不要期望用例和系统内部的类之间有任何关联

更多资料

Ivar Jacobson的[Jacobson，OOSE]

，[Cockburn，use cases]

http://usecases.org

http://foruse.com