UML学习笔记.docx
《UML学习笔记.docx》由会员分享，可在线阅读，更多相关《UML学习笔记.docx（18页珍藏版）》请在冰豆网上搜索。
UML学习笔记
第一章为什么要建模
这一章的内容或许在应用过建模技术后才能有所领悟，对于我这种初学者而言感觉象是政治课本。
①为什么要建模？
人对复杂问题的理解能力是有限的，通过建模我们可以将复杂的问题分解成一系列的小问题，解决了这些小问题，最终就可以解决整个复杂的问题。
建模是为了使我们更好的理解正在开发的系统。
②建模要达到的目的
⑴模型帮助我们按照实际情况或按照我们所需要的样式对系统进行可视化。
⑵模型允许我们详细说明系统的结构或行为。
⑶模型给出一个指导我们构造系统的模板。
⑷模型对我们作出的决策进行文档化。
③建模的四项基本原理
⑴选择创建正确的模型。
⑵根据需要用不同精度级别来表示模型。
⑶模型要与现实相联系。
⑷单个模型是不充分的，对重要系统应用一组独立的模型去处理。
第二章UML介绍
UML（UnifiedModelingLanguag）统一建模语言
①UML概述
⑴UML用于对软件进行可视化、详述、构造和文档化。
⑵UML是一种图形化语言。
⑶UML是一种标准语言，可以精确的、无歧义的、完整的描述模型。
一个开发者用UML绘制了一个模型，另一个开发者可以无歧义的理解这个模型。
⑷UML绘制的图形可以用于制作文档。
⑸UML不限于对软件建模，也可以用于非软件系统建模。
②UML的概念模型
学习建模的三个主要要素：
⑴UML的基本构造块。
⑵支配这些构造块放在一起的规则。
⑶运用于整个UML语言的公共机制。
下面分别对三个要素进行介绍：
⑴UML的基本构造块
UML的基本构造块有3种：
Ⅰ、事物（thing）
Ⅱ、关系（relationship）
Ⅲ、图（diagram）
UML中包含4类事物，以下列出这些事物类别以及组成它们的具体事物：
Ⅰ、结构事物（structuralthing）：
类（class）、接口（interface）、协作（collaboration）、用况（usecase）、主动类（activeclass）、构件（component）、节点（node）
Ⅱ、行为事物（behavioralthing）：
交互（interaction）、状态机（statemachine）
Ⅲ、分组事物（groupingthing）：
包（package）
Ⅳ、注释事物（annotationalthing）：
注释（note）
UML包含4种关系：
Ⅰ、依赖（dependency）
Ⅱ、关联（association）
Ⅲ、泛化（generalization）
Ⅳ、实现（realization）
UML包含9种图：
Ⅰ、类图（classdiagram）
Ⅱ、对象图（objectdiagram）
Ⅲ、用况图（usecasediagram）
Ⅳ、顺序图（sequencediagram）
Ⅴ、协作图（collaborationdiagram）
Ⅵ、活动图（activitydiagram）
Ⅶ、状态图（statechartdiagram）
Ⅷ、构件图（componentdiagram）
Ⅸ、部署图（deploymentdiagram）
⑵UML的规则
（没看懂什么意思）
⑶UML中的公共机制
UML中包含4种公共机制：
Ⅰ、规格说明
也就是每种图形所代表的语义的文字叙述。
Ⅱ、修饰
UML中大多数元素都可以用图形对其最重要部分进行可视化表示，而修饰用于描述这些元素的其他细节。
例如描述一个类的某个操作的性质（公共操作、保护操作或私有操作）。
Ⅲ、通用划分
通用划分有两种：
对类和对象的划分、对接口和实现的分离。
UML的每一个构造块几乎都存在这两种划分法，因此称为通用划分。
Ⅳ、扩展机制
UML是可以以受控方式扩展的语言，它的扩展机制包括：
㈠构造型（stereotype）
用于扩展UML的词汇，创建新的构造块。
新构造块可以从现有构造块派生，用构造型来标记。
㈡标记值（toggedvalue）
用于扩展UML构造块的特性，创建元素的新信息。
㈢约束（constraint）
用于扩展UML构造块的语义，增加新的规则或修改现有的规则。
③体系结构
建议采用5个互连的视图来描述一个软件的体系结构：
⑴系统的用况视图（usecaseview）
⑵系统的设计视图（designview）
⑶系统的进程视图（processview）
⑷系统的实现视图（implementationview）
⑸系统的实施视图（deploymentview）
注意：
这里的视图并非前面提到的UML的基本构造块中的图（diagram），可以理解为从多个角度来观察系统的体系结构，每个视图包含多个图（diagram）。
第四章类（class）
这里的类的概念和面向对象中类的概念是一致的，代表的是一种类型的对象，而不是个体对象（实例）。
对类的描述可以从下面几个方面来进行：
⑴名称（name）
为类定义一个有别于其他类的名称，简单的名称叫SimpleName，带有包名的名称叫PathName。
⑵属性（attribute）
属性是类的一些特性，是对类的一种数据或状态的抽象。
⑶操作（operation）
在程序中体现为方法，是对类能做的事情的抽象。
可以通过操作的特征标记（参数的名称、类型、缺省值、返回类型）来详细描述操作。
⑷对属性和操作的组织
一个类可能包含众多的属性和操作，在画一个类时不必把每个属性和操作都显示出来，可以只显示一些与当前的图（diagram）相关的属性和操作。
当属性和操作的列表很长时，也可以利用构造型对属性和操作进行分类，使得列表更容易被浏览。
⑸职责
职责就是对类的功能的描述，详细描述一个类的职责是对类建模的一个好的开始点。
⑹其他特征
一般来说属性、操作和职责基本可以描述一个类的特征了，但有一些特殊类还需要其他的方式来描述它的特性，例如对异常的描述，这些被列为类的高级概念，在第9章讨论。
在UML中以上的特征都用图形的方式表现出来，在编程中我们也用程序代码来描述了这些特征，例如这里的属性对应程序中的属性，操作对应程序中的方法），职责对应对类的总描述（在Java中就是每个类的描述，写在publicclass...之前的注释），因此很多建模工具都可以通过UML图来直接生成程序代码。
类在建模技术中通常应用于：
⑴对系统词汇建模
也就是把系统中的对象抽象出来用类来描述。
⑵对系统中职责的分布建模
将系统的职责均衡的分布到各个类中，大概是用于设计控制类时。
⑶对非软件事物建模
通常是系统外部的事物，但参与系统内部的运作。
⑷对简单类型建模
例如自定义的枚举类型。
第五章关系（relationship）
这一章讲述了三种最重要的关系：
⑴依赖（dependency）
依赖用来表示类之间的使用关系，包括精化、跟踪、绑定。
通常当A类的某个操作中使用B类作为参数，那么称A依赖B。
此外对A事物进行了B注释时，A事物依赖B注释。
A类中如果引用（import）了B包（package）中的类，也称A类依赖B包。
可以为依赖定义一个名称来区别不同的依赖，通常是不需要的，我们可以使用构造型来区别依赖的不同含义。
（构造型是UML公共机制中扩展机制下的一种机制）
⑵关联（association）
关联用来表示对象之间的结构关系，它指明一个事物的对象与另一个事物的对象之间的联系。
书中强调关联是对象之间而非类之间的关系，面向对象中对象就是类的实例，所以它是表示实例之间的结构关系的。
关联相比依赖和泛化要复杂一些，可以用4种修饰来描述一个关联：
Ⅰ、名称
可以为关联定义一个名称，用来描述该关系的性质，同时该名称还可以定义一个方向，表明是从谁指向谁。
Ⅱ、角色
角色是关联中一端的对象对另一端的对象所呈现的职责。
如果有角色的修饰，通常就不需要名称的修饰了。
Ⅲ、多重性
这里的多重性指的是关联的另一端的类的每个对象要求在本端的类必须有多少个对象。
也就是通常的数量对应关系，1对1，1对多，多对1等等。
Ⅳ、聚合
聚合是一种特殊的关联，它描述的是整体/部分的关系。
⑶泛化（generalization）
泛化用来表示一般类/特殊类之间的关系。
它在编程中体现为继承，父类与子类的关系就是一种泛化关系。
依赖和关联是可以自连接（由自己连接到自己）的，而泛化不可以。
第六章公共机制
第二章的UML介绍中，提到了UML的公共机制，分别是规格说明、修饰、通用划分和扩展机制。
这一章针对修饰和扩展机制进行更详细的说明。
①注解（note）
注解是附加在元素或元素集上用来表示约束或注释的图形符号。
注解可以含有文字或图解或者URL。
使用原则：
⑴应放置在对应元素附件，并使用依赖关系连接注解和对应元素。
⑵只在需要的时候显示注解。
⑶如果注解很长，可以考虑放置在外部文本中，使用链接指定位置。
⑷适当的舍弃无保留价值的注解。
②其他修饰
例如用于修饰关联的角色、多重性等。
对于类、构件、节点等事物，也可以在图形底部增加分隔栏，以填写修饰信息。
③构造型（stereotype）
用于对UML的词汇的扩展，可以把构造型看作元类型，因为每一个构造型会创建一个相当于UML元模型中新类的等价物。
新构造块可以有自己的具体特性、语义和表示法。
最简单的构造型可以是在UML的事物图形上增加一个《name》。
使用原则：
⑴确认用基本的UML无法表达你要描述的事物。
⑵应从UML基本事物中选取最相似的图形来构造新构造块。
⑶通过定义一组标记值和约束来详述新构造块的特性和语义。
⑷为了更清晰的标出新构造块，可以对其使用新图标。
④标记值（toggedvalue）
最简单的标记值是在UML的事物图形的名称下增加一个用{内容}的标记。
例如指定枚举类型的值。
使用原则：
⑴确认用基本的UML无法表达你要描述的特性。
⑵泛化的应用规则是：
为一种元素定义的标记值可应用到它的子孙事物。
⑤约束
使用约束，可以增加新的语义或改变已存在的规则。
一个约束可以用{内容}标记起来放在相关元素的附近。
使用原则：
⑴确认用基本的UML无法表达你要描述的语义。
⑵将约束放到对应元素的附件，并使用依赖关系连接起来。
⑶如果需要把新语义描述得更精确和更形式化，可用OCL书写新语义。
（OCL不知道什么意思）
总的说来，使用基本的UML可以描述你的系统，在某些情况下可能不能完全满足你的需求，那么就可以使用扩展机制来弥补。
应该尽可能的使用UML定义好的基本元素，这样才能保证你的UML能被他人理解。
第七章图
这里再次提到对软件体系结构进行可视化、详述、构造和文档化，有5种最重要的互补视图：
用况视图（usecaseview）、设计视图（designview）、进程视图（processview）、实现视图（implementationview）、实施视图（deploymentview）。
每一种视图都包含结构建模（对静态事物建模）和行为建模（对动态事物建模）。
UML中包含9种图，这在第二章已经介绍过。
可以将这9种图分为两类，一类用于结构建模，称为结构图；一类用于行为建模，称为行为图。
①结构图
结构图有4种，分别是：
⑴类图（classdiagram）
类图显示一组类、接口、协作以及它们之间的关系。
类图可用于说明系统的静态设计视图。
包含主动类的类图可用于说明系统的静态进程视图。
⑵对象图（objectdiagram）
对象图显示一组对象以及他们之间的关系。
对象图是类图中发现的事物的实例的数据结构和静态快照。
对象图也可用于说明系统的静态设计视图和静态的进程视图，但它是从现实或原型的方面来透视的（因为是类的实例）。
⑶构件图（componentdiagram）
构件图显示了一组构件以及他们之间的关系。
构件图可用于说明系统的静态实现视图。
⑷实施图（deploymentdiagram）
实施图显示了一组节点以及他们之间的关系。
实施图可用于说明系统的静态实施视图。
这4种图还有一些常见的变体，例如子系统图实际就是一个类图。
②行为图
行为图有5种，分别是：
⑴用况图（usecase diagram）
用况图用于组织系统的行为，描述了一组用况和参与者以及他们之间的关系。
用况图用于描述系统的静态用况视图。
⑵顺序图（sequencediagram）和协作图（collaborationdiagram）
顺序图和协作图在语义上是等价的，它们可以互相转换。
顺序图和协作图又被统称为交互图（interactiondiagram）。
它们显示了一组对象和由这组对象发送和接收的消息。
顺序图强调消息的时间次序，协作图强调发消息的对象的结构组织。
⑶状态图（statechartdiagram）和活动图（activitydiagram）
状态图和活动图在语义上是等价的，它们可以互相转换。
状态图显示了一个由状态、转换、事件和活动组成的状态机，它强调一个对象按事件次序发生的行为，通常状态图用于对接口、类或协作的行为建模。
活动图显示了系统从活动到活动的流，它强调对象之间的控制流，通常活动图用于对系统的功能建模。
对于一个系统而言，前面提到的5种视图并非必须的，可以根据系统的需要进行裁剪或补充。
第八章类图
类图是面向对象系统的建模中最常见的图，它显示了一组类、接口、协作以及它们之间的关系。
类图用于对系统的静态设计视图建模。
其大部分涉及到对系统的词汇建模、对协作建模或对模式建模。
它是构件图和实施图的基础。
类图一般包含有：
⑴类
⑵接口
⑶协作
⑷依赖、泛化、关联等关系
⑸包、子系统
⑹注解和约束
类图用于对系统的静态设计视图建模，主要用于支持系统的功能需求。
通常以以下三种方式使用类图：
⑴对系统的词汇建模
哪些抽象是考虑中的系统的一部分，哪些抽象是处于系统边界之外，用类图详述这些抽象和它们的职责。
⑵对简单协作建模
协作是一些共同工作的类、接口和其他元素的群体，该群体提供的一些合作行为强于所有这些元素的行为之和。
用类图对这组类以及它们之间的关系进行可视化和详述。
对协作建模的原则：
Ⅰ、识别要建模的机制。
一个机制描述了正在建模的部分系统的一些功能和行为，这些功能起源于类、接口以及其他事物所组成的群体的相互作用。
Ⅱ、对每种机制，识别参与协作的类、接口和其他协作，并识别这些事物之间的关系。
Ⅲ、用脚本排演这些事物。
Ⅳ、要把元素和它们的内容聚集在一起。
⑶对逻辑数据库模式建模
用类图对数据库的模式建模。
从类图识别数据库结构，从行为来识别存储过程、触发器等等。
至此，第二部分的对基本结构建模的内容结束。
但对结构建模不止这点内容，还有对高级结构建模，也就是第三部分的内容了。
第九章高级类
从第四章到第八章讲述的是对基本结构建模的内容，从这一章开始进入了第三部分，对高级结构建模。
类是面向对象系统中最重要的构造块，但在UML中更一般的构造块是类元，类仅仅是一种类元。
类元包括有：
类、接口、数据类型、信号、构件、节点、用况和子系统。
在第四章讲述类的时候只讲述了基本特征（属性、操作等等），实际描述类元还有很多高级特性（多重性、可见性、特征标记、多态性和其他特征）。
①类元（classifier）
一般而言类元是有实例、具有结构特征和行为特征的建模元素。
除了类以外，UML还包含有以下的类元：
⑴接口（interface）
接口用文字描述是类或构件的一个服务的操作集，它和面向对象中的接口是一个概念。
⑵数据类型（datatype）
指其值没有任何标识的类型，包括简单的内置类型（如数值和串）以及枚举类型（如布尔）。
⑶信号（signal）
对实例之间的通信的异步激发的描述（不懂）。
⑷构件（component）
它遵循一组接口，并提供了该组接口的实现。
⑸节点（node）
一般用于描述运行时存在的物理元素，如硬件等。
⑹用况（usecase）
一组动作序列的描述，系统对它的执行将为特定的参与者产生可观察的结果值。
⑺子系统（subsystem）
如名字般解释。
②可见性
对类元的属性和操作进行详述的最重要的细节之一就是它的可见性。
在第二章说明修饰的时候曾提到，这里的可见性是修饰的一种。
UML中将可见性分为公有的（public）、受保护的（protected）、私有的（private）三种。
这对程序员而言很容易理解，大多数语言中都有这样的机制。
③范围
对类元的属性和操作进行详述的另一个重要细节是其拥有者的范围。
在UML中，可以说明两种范围：
⑴实例（instance）
对一个特征，类元的每个实例均有它自己的值。
⑵类元（classifier）
类元的所有实例只有该特征的一个值。
从程序的角度来描述就是该属性或方法是否为静态的。
④抽象、根、叶和多态性元素
实际讲的是关于抽象类，以及它的子类对其抽象方法实现的描述。
⑤多重性
并非每一个类元都可以有任意个实例，有的时候我们希望一个类只有一个实例，这在程序中也很多见，多重性用来描述类元可以拥有实例的个数。
⑥属性
属性的完整语法形式如下：
[可见性]属性名[多重性][:
类型][=初始值][{特性串}]
UML中定义了3种用于属性的特性：
⑴可变（changeable）
对修改属性值没有约束
⑵只增（addonly）
对于多重性大于1的属性，可以增加附加值，但一旦被创建，九不可对值进行消除或改变。
⑶冻结（frozen）
在初始化对象后，就不允许改变属性值。
在程序中表现为常量。
⑦操作
操作的完整语法形式如下：
[可见性]操作名[（参数表）][:
返回类型][{特性串}]
其中参数的语法形式如下：
[方向]参数名:
类型[=缺省值]（有关"方向"不理解，可能和编程语言有关）
有四种用于描述操作的特性：
⑴查询（isQuery）
执行该操作不会改变系统的状态。
⑵顺序（sequential）
执行该操作要保证在一个对象中一次仅有一个流，在多控制流下，不能保证对象的语义和完整性。
⑶监护（guarded）
在多控制流下也保证对象的语义和完整性。
⑷并发（concurrent）
不懂，总之它和上面两个特性来描述操作的并发特性。
⑧模板类
与Java无关，难懂。
⑨标准元素
UML定义了多种用于类的标准构造型：
元类、强类型、构造型、实用程序、接口、类型、实现类、参与者、异常事件、信号、进程、线程等。
实际这应该是属于UML已经存在的对类使用扩展机制形成的新构造块。
第十章高级关系
第二章提到了UML中最重要的四种关系分别是dependency、association、generalization、realization，在第五章也进一步学习了dependency、association和generalization。
而这一章讲述的是这几种关系的高级特性。
①dependency
dependency表明一个事物使用了另一个事物，在UML中定义了17种可用于dependency的构造型，这17种构造型可被分为6组，下面就详细说明这17种构造型：
⑴可应用到类图中的类和对象间的依赖关系
Ⅰ、绑定（bind）
表明源对目标模板使用给定的实际参数进行实例化，常应用于模板类。
（模板类的概念不了解）
Ⅱ、导出（derive）
表明可以从目标计算出源。
当对两个属性或关联之间的关系建模时，如果其中一个属性（关联）可以导出另一个属性（关联），就可以使用derive构造型。
例如生日和年龄。
Ⅲ、友元（friend）
表明源对目标的特定可见性。
常用于C++中的友元类建立的关系建模。
Ⅳ、的实例（instanceOf）
表明源对象时目标类元的一个实例。
Ⅴ、实例化（instantiate）
表明源创建目标的实例。
Ⅵ、强类型（powertype）
表明目标是源的强类型。
（强类型是一个类元，其对象都是一个给定父类的子类）当对覆盖其他类的类建模时，例如数据库建模时可能碰到这种依赖关系。
Ⅶ、精化（refine）
表明源比目标处于更精细的抽象程度上。
当对本质上相同但位于不同抽象层次的类建模时，要用精化。
Ⅷ、使用（use）
表明源元素的语义依赖于目标元素的公共部分的语义。
当要显式地把一个依赖标记为使用关系时，就可以应用使用（use）。
⑵可应用到包之间的依赖关系
Ⅰ、访问（access）
表明源包有权引用目标包中的元素。
Ⅱ、引入（import）
是一种访问，它表明把目标包的公共内容加入到源包的命名空间。
⑶可应用到用况之间的依赖关系
Ⅰ、延伸（extend）
表明目标用况延伸了源用况的行为。
Ⅱ、包含（include）
表明源用况在其指定的位置上显式地合并了另一个用况的行为。
⑷可应用到对象之间的依赖关系
Ⅰ、变成（become）
描述了目标对象与源对象是相同的，但在后续的时间点上属性值、状态或角色可能会不同。
Ⅱ、调用（call）
表明源操作调用目标操作。
Ⅲ、复制（copy）
表明目标对象是源对象的精确复制，但目标对象是独立的。
⑸可应用到状态机的语境中的依赖关系
发送（send）
表明源操作向目标发送事件。
⑹可应用到把系统的元素组织成子系统和模型的语境中的依赖关系
跟踪（trace）
表明目标是源的历史上祖先。
②generalization
generalization表明了一般/特殊的事物之间的关系。
在程序中体现为父类/子类，在UML中定义了应用到泛化关系上的一个构造型和4个约束。
一个构造型：
实现（implementation）
表明子类继承父类的实现，但既不公布也不支持父类的接口，因此它是违背可替换性的。
在C++中私有继承建模时用到这种构造型。
4个约束：
Ⅰ、完全（complete）
表明已经在模型中给出了泛化关系的所有子类，不允许再有更多的子类。
Ⅱ、不完全（incomplete）
表明没有完全给出所有子类，可以在增加子类。
Ⅲ、互斥（disjoint）
表明父类的对象最多以给定的子类中的一个子类作为类型。
Ⅳ、重叠（overlapping）
表明父类的对象可能以给定的子类中的一个以上子类作为类型。
③association
是一种结构关系，它详述一个事物的对象与另一个事物的对象相联系。
关联的4种基本修饰：
名称、角色、多重性和聚合，在第二章有描述。
对于它的高级用法，从下面几个方面描述：
Ⅰ、导航
关联的导航默认是双向的，但有些情况下是单向导航的，例如user和password，只能从user导出password，而不能从password导出user，这样的导航需要使用箭头标出其单向性。
Ⅱ、可见性
可见性用于限制关联对于外部对象的可见性。
例如password是user私有的，对group而言，password是不可见的。
Ⅲ、限定
给定关联一端的对象，识别另一端的对象或对象集，可以使用限定来描述。
Ⅳ、接口说明符
这个说不清楚，可以看书中的例子。
Ⅴ、组合
组合是聚合的一种特殊情况，它具有强的拥有关系，整体与部分的生命周期是一致的。
一个对象在一个时间内只能是一个组合的一部分。
Ⅵ、关联类
是关联关系的两端的对象之间的产生关系的类的描述。
看书更明白意思。
Ⅶ、约束
UML中定义了5中可以用于关联关系的约束：
⒈隐式（implicit）
表示关系不是显式的，而仅是概念性的。
例如两个父类有关联关系，那么这两个父类的子类之间就可以有隐式的关联关系。
⒉有序（ordered）
表明关联
升级会员 