UML用户指南笔记1-------对基本结构建模

UML包含13种图：

1.
类图(class diagram). 类图展现了一组类、接口、协作和它们之间的关系。构件图是类图的变体。

2.
对象图(object diagram). 对象图展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。

3.
构件图(component diagram). 构件图展现了一个封装的类和它的接口、端口以及由内嵌的构件和连接件构成的内部结构。

4.
组合结构图. 和构件图类似。

5.
用况图(use case diagram). 用况图展现了一组用况、参与者(一种特殊的类)及它们之间的关系。

6.
顺序图(sequence diagram).

7.
通信图(communication diagram). 顺序图和通信图都是交互图(interaction diagram)。交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。顺序图强调时序，通信图强调消息流经的数据结构。定时图(timing diagram)展现了消息交换的实际时间。

8.
状态图(state diagram). 状态图展现了一个状态机，它由状态、转移、事件和活动组成。

9.
活动图(activity diagram). 活动图将进程或其他计算的结构展示为计算内部一步步的控制流和数据流。

10.
部署图(deployment diagram). 部署图展现了对运行时的处理节点以及在其中生存的构件的配置。制品图(artifact diagram).
制品图展现了计算机中一个系统的物理结构。UML把制品图视为部署图的遍体。

11.
包图(package diagram). 包图展现了由模型本身分解而成的组织单元以及它们的依赖关系。

12.
定时图(timing diagram)。定时图是一种交互图，它展现了消息跨越不同对象或角色的实际时间，而不仅仅是关心消息的相对顺序。交互概览图(interaction overview diagram)是活动图和顺序图的混合物。

13.
交互概览图(interaction overview diagram)



第二部分对基本结构的建模

1 类

类是对一组具有相同属性、操作、关系和语义的对象的描述。一个类可以实现一个或多个接口。

UML为类提供了图形表示，并强调抽象的最重要的部分：名称、属性和操作。



名称(name)：每个类都必须有一个有别于其他类的名称。名称是一个文字串。单独的名称叫简单名(simple name),用类所在的包的名称作为前缀的类名叫做限定名(qualified name)。绘制的类可以仅显示它的名称。



属性(attribute)：属性是已明明的类的特性，它描述了该特性的实例可以取值的范围。类可以有任意数目的属性，也可以根本没有属性。属性描述了正被建模的事物的一些特性，这些特性为类的所有对象所共有。



操作(operation)：操作是一个服务的实现，该服务可以由任何类的对象来请求以影响其行为。换句话说，操作是能对一个对象所做的事情的抽象，并且它由这个雷的所有对象共享。类可以有任意数目的操作，也可以根本没有操作。



对属性和操作的组织：

当画一个类时，不必同时把所有的属性和操作都显示出来。通过在列表的末尾使用省略号(…)，可以明确地表示出实际的属性和操作比所显示的要多。

为了更好地组织属性和操作的长列表，可以利用衍型在每一组属性和操作之前加一个描述其种类的前缀。

职责(responsibility)：职责是类的合约或责任。当创建一个类时，就声明了这个类的所有对象具有相同种类的状态和相同种类的行为。在较高的抽象层次上，这些相应的属性和操作正是要完成类的职责的特征。

在图形上，把职责列在类图符地步的单独的栏中。



提示和技巧：

对最终用户或实现者来说，各个类都应该映射到某个有形的活着概念性的抽象。一个结构良好的类，应符合如下条件：

1.
为取自问题域或者解域的词汇中的事物提供明确的抽象。

2.
嵌入一个小的、明确定义的职责集，并且能很好地实现它们。

3.
把抽象的规约和它的实现清楚地分开。

4.
简单而且可理解，并具有可适应性和可扩展性。

当用UML绘制一个类时，要遵循如下的策略：

1.
仅显示在该类的语境中对于理解抽象较为重要的类的特性。

2.
按属性和操作的种类进行分组，以更好地组织其长列表。

3.
把相关的类显示在同一个类图中。



2 关系

在面向对象的建模中，有3种特别重要的关系：

1.
依赖(dependency)，它表示类之间的使用关系(包括精化、跟踪和绑定关系)；

2.
泛化(generalization)，它把一半类连接到它的特殊类(继承)；

3.
关联(association)，它表示对象之间的结构关系。



依赖：

依赖是一种使用关系，说明一个事物使用另一个事物的信息和服务，但反之未必。在图形上，把依赖画成一条有向的许仙，指向被依赖的事物。当要指明一个事物使用另一个事物时，就选用依赖。

在UML中，也可以在很多其他的事物之间创建依赖，特别是注解和包。



泛化：

泛化是一般事物(称为超类或父类)和该事物的较为特殊的种类(称为子类或子)之间的关系。有时也称泛化为”is
a kind of”关系：一个事物时更一般的事物的“一个种类”。泛化意味着子类的对象可以被用在父类的对象可能出现的任何地方，反之则不然。换句话说，泛化意味卓子类可以替换父类的生命。子类继承父类的特性，特别是父类的属性和操作。在图形上，把泛化画成一条带有空心三角形大箭头的有向实线，指向父类，当要表示父/子关系时，就使用泛化。

一个类可以有0个、1个或多个父类。没有父类并且最少有一个子类的类称为根类或基类；没有子类的类成为叶子类。如果一个类只有一个父类，则说它使用了单继承；如果一个类有多个父类，则说它使用了多继承。

在大多数情况下，用类或借口之间的泛化来表明继承关系。在UML中，也可以在其他类目之间创建泛化，比如结点之间。



关联：

关联是一种结构关系，它知名一个事物的对象与另一个事物的对象间的联系。给定一个连接两个类的关联，可以从一个类的对象联系到另一个类的对象。关联的两端都连到同一个类是完全合法的。这意味卓，从类的给定对象能连接到该类的其他对象。恰好连接两个类的关联叫做二元关联。尽管不常见，但可以有连接多余两个类的关联，叫做n元关联。在图形上，把关联画成一条连接相同类或不同类的实现。当要表示结构关系时，就使用关联。除了这种基本形式外，还有4种应用于关联的修饰：

1.
名称 关联可以有一个名称，用以描述该关系的性质。为了消除名称的歧义，可提供一个指出读名称方向的三角形，给名称一个方向。

2.
角色当一个类参与了一个关联时，它就在这个关系中扮演了一个特定的角色。角色是关联中靠近它的一端的类对另一端的类呈现的面孔。可以显示地命名一个类在关联中所扮演的橘色。把关联断电扮演的角色成为端点名(角色名)。

3.
多重性 关联表示了对象间的结构关系。在很多建模问题中，说明一个关联的实例中有多少个相互连接的对象是很重要的。这个“多少”被称为关联角色的多重性，它表示一个整数的范围，指明一组相关对象的可能个数。

4.
聚合 两个类之间的简单关联表示了两个同等地位类之间的结构关系，这意味卓这两个类在概念上是同级别的，一个类并不比另一个类更重要。有时要对“整体/部分”的关系建模，其中一个类描述了一个较大的事物(“整体”)，它由较小的事物(“部分”)组成。这种关系称为聚合，它描述了“has
a”关系，意思是整体对象拥有部分对象。其实聚合只是一种特殊的关联，它表示为在整体的一端用一个空心菱形修饰的简单关联。



提示和技巧：

在用UML对关系建模时，要遵循如下策略：

1.
仅当被建模的关系不是结构关系时，才使用依赖。

2.
仅当关系是”is a kind of”关系时，才使用泛化。往往可以用聚合代替多继承。

3.
小心不要引入循环的泛化关系。

4.
一般要保持泛化关系的平衡；继承的层次不要太深(不超过5层)，也不要太宽(代之以寻找可能的中间抽象类)。

5.
关联主要用于对象间有结构关系的地方。不要用关联来表示暂时关系，例如过程的参数或局部变量。

在用UML绘制关系时，要遵循如下策略：

1.
要一致地使用平直的线或斜线。平直的线给出的可视化提示强调了相关事物之间的连接都集中到一个共同事物。在复杂的图中斜线则经常有更好的空间效果。在同一个图中使用两种线型，有助于把人们的注意力引导到不同的关系组上。

2.
除非绝对必要，否则要避免连线交叉。

3.
仅显示对理解特定的成组事物必不可少的关系。避免使用多余的关系(特别是多余的关联)。



3 公共机制

UML由于存在着4种运用于整个语言的公共机制而得以简化，它们是：规约、修饰、公共划分和扩展机制。本章讨论修饰和扩展。

注解是一种最重要的能单独存在的修饰。注解是附加在元素或元素集上，用来表示约束或注释的图形符号。用注释为模型附加一些信息(如需求、观察资料、评论和解释)。

UML的扩展机制允许以受控的方式对语言进行扩展。这些机制包括衍型、标记值和约束。衍型扩展UML的词汇，允许创建一些新的构造块，这些新的构造块是从已有的构造块派生出来的，但针对特定问题。标记值扩展UML衍型的特性，允许在元素的规约中创建新的信息。约束扩展UML构造块的语义，允许增加新的规则或修改已存在的规则。




注解(note)
注解是富家在元素或元素集上用来表示约束或注释的图形符号。在图形上，把注解画成带有一个折叠角的矩形，在矩形中填写文字的活着图形的注释。

衍型(stereotype)
衍型是对UML的词汇的扩展，允许用于创建与已有的构造块相似但针对特定问题的新种类的构造块。在图形上，把衍型表示成用双尖括号(即<<和>>)括起来的名字，放在其他的元素名之上。作为一种选择，可以用一种衍型相联系的新图标表示被衍型化元素。

标记值(tagged value)
标记值是衍型的一种特性，允许在带有衍型的元素中创建新的信息。在图形上，把标记值表示成形如 name = value
的串，放在一个附加到对象上的注解中。

约束(constraint)
约束是对UML元素语义的文字说明，允许增加新的规则或修改已有的规则。在图形上，把约束表示成勇花括号扩起来的串，并把它放在关联的元素附近，或者通过依赖关系连接到这个(或这些)元素。作为一种选择，可以在注解中表示约束。



对注释建模，要遵循如下策略：

1.
把注释文本放入注解内，并把注解放于它所对应的元素附近。可以用依赖关系把注解与对应的元素相连接，从而更明确地表明其关系。

2.
要记住，可以根据需要隐藏或显示模型中的元素。这意味卓不必到处显示依附到可视元素上的注释，而只有在语境中需要交流这种信息时才显露图中的注释。

3.
如果注释冗长或者包含比纯文本更复杂的事物，可考虑把注释放在外部文档中，并且把文档链接或嵌入到依附于模型的相应注解中。

4.
随着模型演化，保持那些记录着不能从模型本身中导出的重要决策的注释，其他的都舍弃，除非有历史价值。



提示和技巧：

当用注视修饰模型时，要遵循如下策略：

1.
仅使用注解来表达那些不能简单或有意义地使用现有的UML特征来表达的需求、观察资料、评论和解释。

2.
把注释作为一种电子粘贴便签，用以跟踪工作的进展。

当绘制注解时，要遵循如下策略：

1.
注意不要因使用大块的注释而弄乱模型。如果确实需要长的注释，宁可把注解作为一个占位符，用来链接或潜入包含全部注释的文档。



4 图

在软件方面，有5种互补视图对于软件体系结构的可视化、详述、构造和文档化是最重要的，分别是：用况图、设计图、交互图、实现图和部署图。每一种视图都包含结构建模(对静态事物建模)和行为建模(对动态事物建模)。这些不同哦给你的视图一起捕获了系统的最重要的决策。

可以用两种基本的方式使用UML的图：详述用于构造可执行系统的模型(正向工程)和从可执行系统的部件重新构造模型(逆向工程)。



术语和概念：

系统(system):
系统是为完成一定目的而组织起来的，并由一组模型可能从不同观点来描述子系统的集合。

子系统(subsystem):
子系统是一组元素的组合，其中的一些元素构成了由其他被包含的元素所提供的行为的规约。

模型(model):
模型是系统的语义闭合的抽象，这一位卓它表示对现实的完整而又自我一致的简化，是为了更好地理解系统而建立的。

视图(view)：
视图是对系统模型的组织和结构的投影，注重于系统的一个方面。

图(diagram)：
图示一组元素的图形表示，通常表示成由定点(事物)和弧(关系)组成的连通图。

通常用下列几种图之一来观察系统的静态部分：

1.
类图 类、接口和协作。类图展示了一组类、接口、协作以及它们之间的关系。

2.
构件图 构件。
展示了实现构件的内部部件、连接件和端口。当实例化构件时，也实例化了其内部部件的副本。

3.
组合结构图(composite structure diagram) 内部结构。展示了类或协作的内部结构。构件和组合结构差别很小，本书都看作构件图。

4.
对象图 对象。展示了一组对象以及它们之间的关系。用对象图说明在类图中所发现的事物的实例的数据结构和静态快照。对象图也像类图那样表达系统的静态设计视图或静态交互视图，但它是从现实或原型方面来观察的。

5.
部署图 结点。部署图展示了一组结点以及它们之间的关系。用部署图说明体系结构的静态部署视图。部署图与构件图相关之处是，一个结点通常包含一个或多个构件。

6.
制品图 制品。制品图展示了一组制品以及它们与其他制品、与它们所实现的类之间的关系。可以用制品图来展示系统物理实现单元(UML把制品图当作部署图的一部分)。

经常使用以下5种图观察系统的动态部分：

1.
用况图 组织系统的行为。描述了一组用况和参与者(一种特殊的类)以及它们之间的关系。

2.
顺序图 注重于消息的时间次序。顺序图展示了一组角色和扮演这些角色的实例发送和接收的消息。

3.
通信图 注重于收发消息的对象的结构组织。展示了一组角色、这些角色间的连接件以及由把烟这些角色的实例所收发的消息。

4.
状态图 注重由事件驱动的系统状态变化。状态图展示了一个由状态、转换、事件和活动组成的状态及。状态图强调一个对象按事件次序发生的行为。

5.
活动图 注重于从活动到活动的控制流。活动图展示了计算中的一步步的活动流。活动图展示了一组动作，从动作到动作的顺序的流或分支的刘，以及由动作产生或消耗的值。



对系统的不同视图建模：

当用不同的属兔对系统建模时，实际上就是同时从多个维度构造系统。通过选择一组恰当的视图，就设立了一个过程，该过程促使对系统提出适当的问题并暴露出需要攻克的风险。如果选择视图的工作没有做好，或者以牺牲其他视图为代价而只注重一个视图，就会冒掩盖问题和延误解决问题的风险。

由不同的视图对系统建模，要遵循如下的策略：

1.
决定需要哪些视图才能最好地表达系统的体系结构，并暴露项目的技术风险。

2.
对这样的每种视图，决定需要创建哪些制品来捕获该视图的基本细节。在大多数情况下，这些制品由各种UML图组成。

3.
作为过程策划的一部分，决定将把哪些图置于某种形式或半形式的控制之下。对这些图要安排复审，并把它们作为项目的文档保存。

4.
允许保留废弃的图。这些临时的图仍然有助于探究决策的意图，也有助于对变化情况进行实验。

当创建图时，要遵循如下的策略：

1.
图的目的不是为了绘制漂亮的图画，而是为了进行可视化、详述、构造和文档化。图始终是一种部署可执行系统的手段。

2.
不是所有的图都是值得保存的。通过对模型中的元素提出问题，考虑绘制一些草图，并用这些草图去思考正在构造的系统。很多这样的图达到其目的后就要被丢弃。

3.
避免无关的或冗余的图。这些图会使得模型混乱。

4.
在每个图中只显示足以表达特定问题的细节。无关的信息会使读者把握不住想要表达的要点。

5.
另一方面，不要使图过于简化，除非确实需要在很高的抽象层次上表达某些事物。过分简化会隐藏对理解模型来说是重要的细节。

6.
在系统中的结构图和行为图之间保持平衡。很少有哪个系统是完全静态或完全动态的。

7.
不要使图过大，也不要使图过小(小图合并)。

8.
给每个图一个能清楚地表达其意图的有意义的名称。

9.
要对图进行组织。根据视图把它们组织到包中。

10.
不熬为图的形式所困扰。用工具来帮助公主。

一个结构良好的图，应满足如下要求：

1.
注重表达系统视图的一个方面。

2.
仅包含对于理解这个方面所必需的元素。

3.
提供的细节与它的抽象层次一直(仅显示对于理解这个方面所必须的修饰)。

4.
不过分简化，以免读者误解重要的语义。



5 类图

类图通常包含下述内容：

1.
类

2.
接口

3.
依赖、泛化和关联关系

像所有的其他图一样，类图可以包含注解和约束。

类图还可以含有包或者子系统，二者都用于把模型元素聚集成更大的组块。

正向工程(forward engineering)是通过到实现语言的映射而把模型转换为代码的过程。

对类图进行正向工程，要遵循如下的策略：

1.
确定映射到实现语言或所选择的语言的规则。

2.
根据所选择语言的语义，可能要限制对某些UML特性的使用。(比如UML允许多继承，但有些编程语言仅允许单继承)

3.
用标记值来指导在目标语言中对实现的选择。

4.
用工具生成代码。

逆向工程(reverse engineering)是通过从特定实现语言的映射而把代码转换为模型的过程。逆向工程会导致大量的多余信息，其中的一些信息属于比需要建造的游泳的模型低的细节层次。同时，逆向工程师不完整的。

对类图进行逆向工程，要遵循如下的策略：

1.
确定从实现语言或所选的语言进行映射的规则。

2.
使用工具，指向要进行逆向工程的代码。

3.
使用工具，通过查询模型来创建类图。

4.
人工地为模型增加设计信息，以表达在代码中丢失或隐藏的设计意图。



提示和技巧：

在UML中创建类图时，要记住各个类图仅仅是系统静态设计视图的图形表示。不必用单个类图去表达系统设计视图的所有内容。而是用系统的所有视图共同表达系统的全部静态设计视图；耽搁类图仅表达系统的一个方面。

一个构造良好的类图，应满足如下的要求：

1.
注重表达系统静态设计视图的一个方面。

2.
仅包含对理解该方面必要的元素。

3.
提供与抽象的层次一致的细节，仅带有对理解系统必要的修饰。

4.
没有过分地压缩内容以致使读者对重要的语义产生误解。

当绘制类图时，要遵循如下的策略：

1.
要给出一个能反映出类图的用途的名称。

2.
安排各个元素，尽量减少线段交叉。

3.
在空间上组织元素，使得在语义上接近的事物在物理位置上也接近。

4.
用注解或颜色作为可视化提示，把关注点引向类图的重要特性。

5.
尝试不显示太多种的关系。通常，每个类图应往往由一种关系支配。