UML学习笔记

第一章为什么要建模这一章的内容或许在应用过建模技术后才能有所领悟，对于我这种初学者而言感觉象是政治课本。

①为什么要建模？人对复杂问题的理解能力是有限的，通过建模我们可以将复杂的问题分解成一系列的小问题，解决了这些小问题，最终就可以解决整个复杂的问题。

建模是为了使我们更好的理解正在开发的系统。

②建模要达到的目的⑴模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。

⑵模型允许我们详细说明系统的结构或行为。

⑶模型给出一个指导我们构造系统的模板。

⑷模型对我们作出的决策进行文档化。

③建模的四项基本原理⑴选择创建正确的模型。

⑵根据需要用不同精度级别来表示模型。

⑶模型要与现实相联系。

⑷单个模型是不充分的，对重要系统应用一组独立的模型去处理。

第二章 UML介绍UML（Unified Modeling Languag）统一建模语言①UML概述⑴UML用于对软件进行可视化、详述、构造和文档化。

⑵UML是一种图形化语言。

⑶UML是一种标准语言，可以精确的、无歧义的、完整的描述模型。

一个开发者用UML绘制了一个模型，另一个开发者可以无歧义的理解这个模型。

⑷UML绘制的图形可以用于制作文档。

⑸UML不限于对软件建模，也可以用于非软件系统建模。

②UML的概念模型学习建模的三个主要要素：⑴UML的基本构造块。

⑵支配这些构造块放在一起的规则。

⑶运用于整个UML语言的公共机制。

下面分别对三个要素进行介绍：⑴UML的基本构造块UML的基本构造块有3种：Ⅰ、事物（thing）Ⅱ、关系（relationship）Ⅲ、图（diagram）UML中包含4类事物，以下列出这些事物类别以及组成它们的具体事物：Ⅰ、结构事物（structural thing）：类（class）、接口（interface）、协作（collaboration）、用况（use case）、主动类（active class）、构件（component）、节点（node）Ⅱ、行为事物（behavioral thing）：交互（interaction）、状态机（state machine）Ⅲ、分组事物（grouping thing）：包（package）Ⅳ、注释事物（annotational thing）：注释（note）UML包含4种关系：Ⅰ、依赖（dependency）Ⅱ、关联（association）Ⅲ、泛化（generalization）Ⅳ、实现（realization）UML包含9种图：Ⅰ、类图（class diagram）Ⅱ、对象图（object diagram）Ⅲ、用况图（use case diagram）Ⅳ、顺序图（sequence diagram）Ⅴ、协作图（collaboration diagram）Ⅵ、活动图（activity diagram）Ⅶ、状态图（statechart diagram）Ⅷ、构件图（component diagram）Ⅸ、部署图（deployment diagram）⑵UML的规则（没看懂什么意思）⑶UML中的公共机制UML中包含4种公共机制：Ⅰ、规格说明也就是每种图形所代表的语义的文字叙述。

Ⅱ、修饰UML中大多数元素都可以用图形对其最重要部分进行可视化表示，而修饰用于描述这些元素的其他细节。

例如描述一个类的某个操作的性质（公共操作、保护操作或私有操作）。

Ⅲ、通用划分通用划分有两种：对类和对象的划分、对接口和实现的分离。

UML的每一个构造块几乎都存在这两种划分法，因此称为通用划分。

Ⅳ、扩展机制UML是可以以受控方式扩展的语言，它的扩展机制包括：㈠构造型（stereotype）用于扩展UML的词汇，创建新的构造块。

新构造块可以从现有构造块派生，用构造型来标记。

㈡标记值（togged value）用于扩展UML构造块的特性，创建元素的新信息。

㈢约束（constraint）用于扩展UML构造块的语义，增加新的规则或修改现有的规则。

③体系结构建议采用5个互连的视图来描述一个软件的体系结构：⑴系统的用况视图（use case view）⑵系统的设计视图（design view）⑶系统的进程视图（process view）⑷系统的实现视图（implementation view）⑸系统的实施视图（deployment view）注意：这里的视图并非前面提到的UML的基本构造块中的图（diagram），可以理解为从多个角度来观察系统的体系结构，每个视图包含多个图（diagram）。

第四章类（class）这里的类的概念和面向对象中类的概念是一致的，代表的是一种类型的对象，而不是个体对象（实例）。

对类的描述可以从下面几个方面来进行：⑴名称（name）为类定义一个有别于其他类的名称，简单的名称叫Simple Name，带有包名的名称叫Path Name。

⑵属性（attribute）属性是类的一些特性，是对类的一种数据或状态的抽象。

在程序中体现为方法，是对类能做的事情的抽象。

可以通过操作的特征标记（参数的名称、类型、缺省值、返回类型）来详细描述操作。

⑷对属性和操作的组织一个类可能包含众多的属性和操作，在画一个类时不必把每个属性和操作都显示出来，可以只显示一些与当前的图（diagram）相关的属性和操作。

当属性和操作的列表很长时，也可以利用构造型对属性和操作进行分类，使得列表更容易被浏览。

⑸职责职责就是对类的功能的描述，详细描述一个类的职责是对类建模的一个好的开始点。

⑹其他特征一般来说属性、操作和职责基本可以描述一个类的特征了，但有一些特殊类还需要其他的方式来描述它的特性，例如对异常的描述，这些被列为类的高级概念，在第9章讨论。

在UML中以上的特征都用图形的方式表现出来，在编程中我们也用程序代码来描述了这些特征，例如这里的属性对应程序中的属性，操作对应程序中的方法），职责对应对类的总描述（在Java中就是每个类的描述，写在public class ...之前的注释），因此很多建模工具都可以通过UML图来直接生成程序代码。

类在建模技术中通常应用于：⑴对系统词汇建模也就是把系统中的对象抽象出来用类来描述。

⑵对系统中职责的分布建模将系统的职责均衡的分布到各个类中，大概是用于设计控制类时。

⑶对非软件事物建模通常是系统外部的事物，但参与系统内部的运作。

⑷对简单类型建模例如自定义的枚举类型。

第五章关系（relationship）这一章讲述了三种最重要的关系：⑴依赖（dependency）依赖用来表示类之间的使用关系，包括精化、跟踪、绑定。

通常当A类的某个操作中使用B类作为参数，那么称A依赖B。

此外对A事物进行了B注释时，A事物依赖B 注释。

A类中如果引用（import）了B包（package）中的类，也称A类依赖B包。

可以为依赖定义一个名称来区别不同的依赖，通常是不需要的，我们可以使用构造型来区别依赖的不同含义。

（构造型是UML公共机制中扩展机制下的一种机制）关联用来表示对象之间的结构关系，它指明一个事物的对象与另一个事物的对象之间的联系。

书中强调关联是对象之间而非类之间的关系，面向对象中对象就是类的实例，所以它是表示实例之间的结构关系的。

关联相比依赖和泛化要复杂一些，可以用4种修饰来描述一个关联：Ⅰ、名称可以为关联定义一个名称，用来描述该关系的性质，同时该名称还可以定义一个方向，表明是从谁指向谁。

Ⅱ、角色角色是关联中一端的对象对另一端的对象所呈现的职责。

如果有角色的修饰，通常就不需要名称的修饰了。

Ⅲ、多重性这里的多重性指的是关联的另一端的类的每个对象要求在本端的类必须有多少个对象。

也就是通常的数量对应关系，1对1，1对多，多对1等等。

Ⅳ、聚合聚合是一种特殊的关联，它描述的是整体/部分的关系。

⑶泛化（generalization）泛化用来表示一般类/特殊类之间的关系。

它在编程中体现为继承，父类与子类的关系就是一种泛化关系。

依赖和关联是可以自连接（由自己连接到自己）的，而泛化不可以。

第六章公共机制第二章的UML介绍中，提到了UML的公共机制，分别是规格说明、修饰、通用划分和扩展机制。

这一章针对修饰和扩展机制进行更详细的说明。

①注解（note）注解是附加在元素或元素集上用来表示约束或注释的图形符号。

注解可以含有文字或图解或者URL。

使用原则：⑴应放置在对应元素附件，并使用依赖关系连接注解和对应元素。

⑵只在需要的时候显示注解。

⑶如果注解很长，可以考虑放置在外部文本中，使用链接指定位置。

⑷适当的舍弃无保留价值的注解。

②其他修饰例如用于修饰关联的角色、多重性等。

对于类、构件、节点等事物，也可以在图形底部增加分隔栏，以填写修饰信息。

③构造型（stereotype）用于对UML的词汇的扩展，可以把构造型看作元类型，因为每一个构造型会创建一个相当于UML元模型中新类的等价物。

新构造块可以有自己的具体特性、语义和表示法。

最简单的构造型可以是在UML的事物图形上增加一个《name》。

使用原则：⑴确认用基本的UML无法表达你要描述的事物。

⑵应从UML基本事物中选取最相似的图形来构造新构造块。

⑶通过定义一组标记值和约束来详述新构造块的特性和语义。

⑷为了更清晰的标出新构造块，可以对其使用新图标。

④标记值（togged value）最简单的标记值是在UML的事物图形的名称下增加一个用{ 内容 }的标记。

例如指定枚举类型的值。

使用原则：⑴确认用基本的UML无法表达你要描述的特性。

⑵泛化的应用规则是：为一种元素定义的标记值可应用到它的子孙事物。

⑤约束使用约束，可以增加新的语义或改变已存在的规则。

一个约束可以用{ 内容 }标记起来放在相关元素的附近。

使用原则：⑴确认用基本的UML无法表达你要描述的语义。

⑵将约束放到对应元素的附件，并使用依赖关系连接起来。

⑶如果需要把新语义描述得更精确和更形式化，可用OCL书写新语义。

（OCL不知道什么意思）总的说来，使用基本的UML可以描述你的系统，在某些情况下可能不能完全满足你的需求，那么就可以使用扩展机制来弥补。

应该尽可能的使用UML定义好的基本元素，这样才能保证你的UML能被他人理解。

第七章图这里再次提到对软件体系结构进行可视化、详述、构造和文档化，有5种最重要的互补视图：用况视图（use case view）、设计视图（design view）、进程视图（process view）、实现视图（implementation view）、实施视图（deployment view）。

每一种视图都包含结构建模（对静态事物建模）和行为建模（对动态事物建模）。

UML中包含9种图，这在第二章已经介绍过。

可以将这9种图分为两类，一类用于结构建模，称为结构图；一类用于行为建模，称为行为图。

①结构图结构图有4种，分别是：⑴类图（class diagram）类图显示一组类、接口、协作以及它们之间的关系。