2015/03/21 - 16:12

【声明】欢迎转载，但请保留文章原始出处：http://blog.csdn.net/yelangjueqi/article/details/44724765

1，UML概述

1.1，统一建模语言（Unified Modeling Language,UML）是一种绘制软件蓝图的标准语言。可以用uml对软件密集型系统的制品进行可视化、详述、构造和文档化。

1.2，要学习uml,一个有效的出发点是形成该语言的概念模型，这要求学习三个要素：uml的基本构造块， 支配这些构造块如何放置在一起的规则以及运用于整个语言的一些公共机制

1.3，UML不仅只是一组图形符号。确切地讲，UML标志法中的每个符号都有明确的意义。这样，一个开发者可以用uml绘制一个模型，而另一个开发者（甚至工具）可以无歧义地解释这个模型。

1.4，UML是一种可用于详细描述的语言，详细描述意味着所建的模型是精确的，无歧义的和完整的。特别是，UML适用于对所有重要的分析，设计和实现决策进行详细描述，这些是软件密集型系统在开发和部署时所必需的。

1.5，UML是一种用于构造的语言，对于一个事物，如果表示为图形方式最为恰当，则用UML；而如果表示为文字方式最为恰当，则用编程语言。

1.6，UML是一种用于文档化的语言。

一个健康的软件组织除了生产可执行的源代码之外，还要给出各种制品。这些制品包括（但不限于）：

（1），需求

（2），体系结构

（3），设计

（4），源代码

（5），项目计划

（6），测试

（7），原型

（8），发布

这些制品不但是项目交付时所要求的，而且无论是在开发期间还是在交付使用后对控制，度量和理解系统也是关键的。UML适于建立系统体系结构及其所有细节的文档。

UML不限于对软件建模。事实上，它的表达能力对非软件系统也是足够的。

2，UML的概念模型

为了理解UML，需要形成该语言的概念模型，这要求学习建模的3个要素：UML的基本构造块，支配这些构造块如何放在一起的规则和一些运用于整个UML的公共机制。如果掌握了这些思想，就能够读懂UML模型，并能建立一些基本模型。当有了较丰富的应用UML的经验时，就能够在这些概念模型之上使用更高深的语言特征进行构造。

2.1，UML的构造块

UML的词汇表包含下面三种构造块：

（1），事物

（2），关系

（3），图

事物是对模型中首要成分的抽象；关系把事物结合在一起；图聚集了相关的事物

2.1.1，UML中的事物

在UML中有4中事物：

（1），结构事物

（2），行为事物

（3），分组事物

（4），注释事物

这些事物是UML中基本的面向对象的构造块，用它们可以写出结构良好的模型

2.1.2，结构事物

结构事物是UML模型的名次。它们通常是模型的静态部分，描述概念元素或物理元。结构事物总称为类目（classifier）

第一，类（class）是对一组具有相同属性，相同操作，相同关系和相同语义的对象的描述。类实现一个或多个接口。在图形上，把类画成一个矩形，矩形中通常包括类的名称，属性和操作。

第二，接口（interface）是一组操作的集合，每个操作描述了类或构件的一个服务。因为接口描述了元素的外部可见行为。一个接口可以描述一个类或构件的全部行为或部分行为。接口定义了一组操作规约（即操作的特征标记），而不是操作的实现。接口的生命看上去是在名称的上方标注着关键字<<interface>>的类；除非有时用来表示常量，否则不需要属性。然而，接口很少单独出现。把由类提供的对外接口表示成用线连接到类框的一个小圆圈，把类向其他类请求的接口表示成用线连接到类框的半个小圆圈。

第三，协作（collaboration）定义了一个交互，它是由一组共同工作以提供某种协作行为的角色和其他元素构成的一个群体，这些协作行为大于所有元素的各自行为的总和。协作具有结构，行为和纬度。一个给定的类或对象可以参与几个协作。这些协作因而表现了系统构成模式的实现。在图形上，把协作画成虚线椭圆，有时仅包含它的名称。

第四，用况（use case）是对一组动作序列的描述，系统执行这些动作将产生对特定的参与者有价值而且可观察的结果。用况用于构造模型中的行为事物。用况是通过协作实现的。在图形上，把用况画成实现椭圆，通常仅包含它的名称。

剩余的三种事物----主动类，构件和结点， 都和类相似，就是说它们也描述了一组具有相同属性，相同操作，相同关系和相同语义的实体。然而，这3种事物与类的不同点也不少，而且对面向对象系统的某些方面的建模是必要的，因此对这几个术语需要单独处理。

第五，主动类（active class）是这样的类，其对象至少拥有一个进程或线程。因此它能够启动控制活动， 主动的类的对象所表现的元素的行为与其他元素的行为并发，除了这一点之外，它和类是一样的。在图形上，把主动类绘制成类图符，只是它的左右外框是双线，通常它包含名称，属性和操作。

第六，构件（component）是系统设计的模块化部件，将实现隐藏在一外部接口之后。在一个系统中，共享相同接口的构件可以相互替换，只要保持相同的逻辑行为即可。可以通过把部件和连接件接合在一起表示构件的实现；部件可以包括更小的构件。在图形上，构件的表示很像类，只是在其右上角有一个特殊的图标。

剩下的两种元素是制品和结点，它们也是不同的。它们表示物理事物，而前6种事物表示概念或逻辑事物。

第七，制品（artifact）是系统中物理的而且可替代的部件，它包括物理信息（"比特"）。在一个系统中，会遇到不同类型的部署制品，如源代码文件，可执行程序和脚本。制品通常代表对源码信息或运行时信息的物理打包。在图形上，把制品表示成一个矩形，在起名称的上方标注着关键字<<artifact>>

第八，结点（node）是在运行时存在的物理元素，它表示一个计算机资源，通常至少有一些记忆能力和处理能力。一组构件可以驻留在一个结点内，也可以从一个结点迁移到另一个结点。在图形上，把结点画成一个立方体，通常在立方体中只写它的名称。

这些元素----类，接口，协作，用况，主动类，构件，制品和结点，是UML模型中可以包含的基本结构事物。它们也有变体，如参与者，信号，使用程序（一种类），进程和线程（两种主动类），应用，文档，文件，库，页和表（一种制品）等。

2.1.3，行为事物

行为事物（behavioral thing）是UML模型的动态部分。它们是模型中的动词，代表了跨越时间和空间的行为。共有3类主要的行为事物。

第一，交互（interaction）是这样一种行为，它由在特定语境中共同完成一定任务的一组对象或角色之间交换的信息组成。一个对象群体的行为或者单个操作的行为可以用一个交互来描述。交互涉及一些其他元素，包括消息、动作和连接件（对象间的连接）。在图形上，把消息画成一条有方向的直线，通常在其上总是带有操作名。

第二，状态机（state machine）是这样一种行为，它描述了一个对象或一个交互在生命期内响应事件所经历的状态序列以及对这些事件的响应。单个类或一组类之间的协作行为可以用一个状态机来描述。状态机涉及到一些其他元素，包括状态、转移（从以状态到另一个状态的流）、事件（触发转换的事物）和活动（对一个转移的响应）。在图形上，把状态机画成一个圆角矩形，通常在其中含有状态的名字及其子状态（如果有的话）

第三，活动（activity）是这样一种行为，它描述了计算过程执行的步骤序列。

交互所注重的是一系列相互作用的对象，状态机所注重的是一定时间内一个对象的生命周期，活动所注重的是步骤之间的流而不关心哪个对象执行哪个步骤。活动的一个步骤称为一个动作，在图形上，把动作画成一个圆角矩形，在其中含有指明其用途的名字。 状态和动作靠不同的语境得以区别。

交互，状态机和活动这样三种要素是可以包含在UML模型中的基本行为事物，在语义上，这些元素通常与各种结构元素（主要 是类、协作和对象）相关。

2.1.4，分组事物

分组事物（grouping thing）是UMK模型的组织部分。它们是一些由模型分解成的"盒子"。主要的分组事物是包

包（package）是用于对设计本身进行组织的通用机制，与类不同，类是用来组织实现构造物。结构事物、行为事物甚至其他的分组事物都可以放进包内。包不像构件（构件在运行时存在），它纯粹是概念上的（即它仅在开发时存在）。在图形上， 把包画成带标签的文件夹（一个左上角带有一个小矩形的大矩形），在矩形中通常仅包含有包的名称，有时还含有其内容。

包是用来组织UML模型的基本分组事物。它也有变体，如框架，模型和子系统（它们是包的不同种类）。

2.1.5，注释事物

注释事物（annotational thing）是UML模型的解释部分。这些注释事物用来描述、说明和标注模型的任何元素。有一种主要的注释事物，称为注解。注解（note）是依附于一个元素或一组元素之上对其进行约束或解释的简单符号。在图形上，把注解画成一个右上角是折角的矩形，其中带有文字或图形解释。

该元素是可以包含在UML模型中的基本注释事物。通常可以用注解中所含的约束或解释来修饰图，当然最好是把注释表示成形式或非形式的文本。这种元素也有变体，如需求（从模型的外部来描述一些想得到的行为）。

2.1.6，UML中的关系

在UML中有4种关系：

（1）依赖

（2）关联

（3）泛化

（4）实现

这些关系是UML的基本关系构造块，用他们可以写出结构良好的模型

第一，依赖（dependency）是两个模型元素间的语义关系，其中一个元素（独立元素）发生变化会影响到另一个元素（依赖元素）的语义。在图形上，把依赖画成一条可能有方向的虚线，偶尔在其上还带有一个标记。

第二，关联（association）是类之间的结构关系，它描述了一组链，链是对象（类的实例）之间的连接。聚合是一种特殊类型的关联，它描述了整体与部分之间的结构关系。在图形上，把关联画成一条实线，它可能有方向，偶尔在其上还带有一个标记，而且它还经常含有诸如多重性和端名这样的修饰。

第三，泛化（generalization）是一种特殊/一般关系，在其中特殊元素（子元素）基于一般元素（父元素）而建立。用这种方法，子元素共享了父元素的结构和行为。在图形上，把泛化关系画成一条带有空心箭头的实线，该实线指向父元素。

第四，实现（realization）是类目之间的语义关系，其中的一个类目指定了由另一个类目保证执行的合约。在两种地方会遇到实现关系：一种是在接口和实现它们的类或构件之间；另一种是在用况和实现它们的协作之间。在图形上， 把实现关系画成一条带有空心箭头的虚线，它是泛化和依赖关系两种图形的结合。

这4种元素是UML模型中可以包含的基本关系事物。它们也有变体，例如：精化、跟踪、包含和扩展。

2.1.7，UML中的图

（1），类图（class diagram）展现了一组类、接口、协作和它们之间的关系。在面向对象系统的建模中所建立的最常见的图就是类图。类图给出系统的静态设计视图。包含主动类的类图给出系统的静态进程视图。构建图是类图的变体。

（2），对象图（object diagram）展现了一组对象以及它们之间的关系。对象图描述了在类图中所建立的事物的实例的静态快照。和类图一样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。

（3），构件图（component diagram）展现了一个封装的类和它的接口、端口以及由内嵌的构件和连接件构成的内部结构。构建图用于表示系统的静态设计实现视图，对于由小的部件构建大的系统来说，构建图是很重要的。

（4），用况图（use case diagram）展现了一组用况、参与者（一种特殊的类）及它们之间的关系。用况图给出系统的静态用况视图。这些图在对系统的行为进行组织和建模上是非常重要的。

（5），顺序图和通信图都是交互图。交互图（interaction diagram）展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图（sequence diagram）是强调消息的时间次序的交互图；通信图（communication diagram）也是一种交互图，它强调收发消息的对象或角色的结构组织。顺序图和通信图表达了类似的基本概念，但每种图强调概念的不同视图，顺序图强调时序，通信图强调消息流经的数据结构。定时图展现了消息交换的定时时间。

（6），状态图（state diagram）展现了一个状态机，它由状态、转移、事件和活动组成。状态图展现了对象的动态视图。它对于接口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对系统反应式建模。

（7），活动图（activity diagram）将进程或其他计算的结构展示为计算内部一步步的控制流和数据流，活动图专注于系统的动态视图。它对于系统的功能建模特别重要，并强调对象间的控制流程。

（8），部署图（deployment diagram）展现了对运行时的处理结点以及在其中生存的构件的配置。部署图给出了体系结构的静态部署视图。通常一个结点包含一个或多个制品。

（9），制品图（artifact diagram）展现了计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品常与部署图一起使用。制品也展现了它们实现的类和构件。（UML把制品图视为部署图的变体）

（10），包图（package diagram）展现了由模型本身分解而成的组织单元以及它们的依赖关系。

（11），定时图（timing diagram）是一种交互图，它展现了消息跨越不同对象或角色的实际时间，而不仅仅是关心消息的相对顺序。

并不限定仅使用这几种图，开发工具可以用UML来提供其他种类的图。 但到目前为止，这几种图在实际使用过程中是最常见的。

2.2，UML中的公共机制

（1），详述：UML不仅仅是一种图形语言，实际上，在它的图形表示法的每部分背后都有一个详述，这个详述提供了对构造块的语法和语义的文字叙述。

（2），UML中的大多数元素都有唯一的和直接的图形表示符号，这些图形符号对元素的最重要的方面提供了可视化表示

（3），通用划分，在面向对象的系统建模中，通常有几种划分方法：

第一：对类和对象的划分。类是一种抽象，对象是这种抽象的一个具体实现。在UML中，可以对类和对象进行建模。在图形上，UML是这样辨别对象的：用与类同样的图形符号来表示对象， 并且在对象名的下面画一道线。

UML的每一个构造块都几乎都存在像类/对象这样的二分法。

第二：接口和实现的分离。接口声明了一个合约，而实现则表明了对该合约的具体实施，它负责如实地实现接口的完整语义。在UML中，既可以对接口建模又可以对它们的实现建模。

在这个图中，有一个名称为SpellingWizard.java的构件，它实现了接口IUnknown和接口ISpelling， 并且还需要一个由其他构件提供的名为IDictionary的接口。

几个每一个UML的构造块都有像接口/实现这样的二分法。

第三：是对类型和角色的分离。类型声明了实体的种类（如对象、属性或参数），角色描述了实体在语境中的含义（如类、构件或协作等）。任何作为其他实体结构中的一部分的实体（例如属性）都具有两个特性：从它固有的类型派生出一些含义，从它的语境中的角色派生出一些含义。

具有类型和角色的部件：

3，HellO World

3.1，关键抽象

在UML中，像数学表达式这样的事物最好用文字性的编程语言语法来写，而像类层次这样的事物最好以图形的方式来可视化。

逆向工程是从代码创建模型