UML轻松入门.docx

UML轻松入门.docx

《UML轻松入门.docx》由会员分享，可在线阅读，更多相关《UML轻松入门.docx（26页珍藏版）》请在冰豆网上搜索。

UML轻松入门

统一建模语言UML轻松入门之基本概念

20世纪80年代，随着面向对象技术成为研究的热点，先后出现了几十种面向对象的软件开发方法。

其中，Booch、OMT和OOSE等方法得到了广泛的认可。

然而，采用不同方法进行建模不利于开发者之间的交流。

而UML则统一了Booch、OMT和OOSE的表示方法，而且对其作了进一步的发展。

1997年，UML被国际对象组织OMG采纳为面向对象的建模语言的国际标准，它溶入了软件工程领域的新思想、新方法和新技术。

UML不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。

数年来，UML凭借其简洁明晰的表达方式、超凡脱俗的表达能力，一路杀将出来，为业界所广泛认同！

目前，在多数大型企业的正规化开发流程中，开发人员普遍使用UML进行模型的建立。

作为一名软件开发人员，我们必须学会UML。

因为UML就是那个统一的"文字"，统一的"度"、"量"、"衡"，不理解UML，作为软件设计统一王国的国民，将是艰难而痛苦的。

作曲家会将其脑袋中的旋律谱成乐曲，建筑师会将其设计的建筑物画成蓝图，这些乐曲、蓝图就是模型（Model），而建构这些模型的过程就称为建模（Modeling）。

软件开发如同音乐谱曲及建筑设计，其过程中也必须将需求、分析、设计、实现、布署等各项工作流程的构想与结果予以呈现，这就是软件系统的建模。

那么为什么要建模呢？

经典答案是：

建立大厦和建立狗窝的区别是建设狗窝不需要设计，要生产合格的软件就要有一套关于体系结构、过程和工具的规范。

OMG官方发布的UML的当前最高版本为2.0，可以从http:

//www.uml.org/上下载。

UML由图和元模型组成，图是语法，元模型是语义。

UML主要包括三个基本构造块：

事物（Things）、关系（Relationships）和图（Diagrams）。

本次连载我们将对UML的这些基本组成部分及UML工具和应用进行介绍，使读者对UML形成初步的整体印象。

在其后的几次连载里，再以数个实例对这些内容逐步展开。

1.1UML的基本构造块

1.1.1事物

事物是是实体抽象化的最终结果，是模型中的基本成员，UML中包含结构事物、行为事物、分组事物和注释事物。

（1）结构事物（Structuralthings）

结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，是软件建模中最常见的元素，共有以下七种：

类（Class）：

类是指具有相同属性、方法、关系和语义的对象的集合；

接口（Interface）：

接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的动作；

协作（Collaboration）：

协作描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模；

用例（UseCase）：

用例定义了执行者（在系统外部和系统交互的人）和被考虑的系统之间的交互来实现的一个业务目标；

活动类（ActiveClass）：

活动类的对象有一个或多个进程或线程。

活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的；

组件（Component）：

组件是物理的、可替换的部分，包含接口的集合，例如COM+、JAVABEANS等；

结点（Node）：

结点是系统在运行时存在的物理元素，代表一个可计算的资源，通常占用一些内存和具有处理能力。

（2）行为事物（Behavioralthings）

行为事物指的是UML模型中的动态部分，代表语句里的"动词"，表示模型里随着时空不断变化的部分，包含两类：

交互（ineraction）：

交互是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消息交换而组成的动作；

状态机（statemachine）：

状态机由一系列对象的状态组成。

（3）分组事物（Groupingthings）

可以把分组事物看成是一个"盒子"，模型可以在其中被分解。

目前只有一种分组事物，即包（package）。

结构事物、动作事物甚至分组事物都有可能放在一个包中。

包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。

（4）注释事物（Annotationalthings）

注释事物是UML模型的解释部分。

1.1.2关系

关系是将事物联系在一起的方式，UML中定义了四种关系：

（1）依赖（Dependencies）：

两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义；

（2）关联（Association）：

一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分间的结构关系）；

（3）泛化（Generalization）：

一种一般化-特殊化的关系；

（4）实现（Realization）：

类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。

1.1.3图

图是事物集合的分类，UML中包含多种图：

（1）类图（ClassDiagram）：

类图描述系统所包含的类、类的内部结构及类之间的关系；

（2）对象图（ObjectDiagram）：

对象图是类图的一个具体实例；

（3）包图（PackageDiagram）：

包图表明包及其之间的依赖类图；

（4）组件图（CompomentDiagram，也称构件图）：

组件图描述代码部件的物理结构以及各部件之间的依赖关系；

（5）部署图（DeploymentDiagram）：

部署图定义系统中软硬件的物理体系结构；

（6）用例图（UsecaseDiagram）：

用例图从用户的角度出发描述系统的功能、需求，展示系统外部的各类角色与系统内部的各种用例之间的关系；

（7）顺序图（SequenceDiagram）：

顺序图表示对象之间动态合作的关系；

（8）协作图（CollaborationDiagram）：

合作图描述对象之间的协作关系；

（9）状态图（StatechartDiagram）：

状态图描述一类对象的所有可能的状态以及事件发生时状态的转移条件；

（10）活动图（ActivityDiagram）：

活动图描述系统中各种活动的执行顺序。

上述十种图可归纳为五类，如表1.1。

表1.1UML图分类

类型

包含

静态图

类图、对象图、包图

行为图

状态图、活动图

用例图

用例图

交互图

顺序图、协作图

实现图

组件图、部署图

1.2UML工具与应用

"工欲善其事，必先利于器"，为了有效的利用UML，我们需要首先获得一个UML工具软件。

当前，业界使用最广泛的UML建模工具为RationalRose。

RationalRose中可实现正向（为模型产生相应的代码）、逆向（从用户原来的软件系统导出该系统的模型）和双向工程（实现模型和代码之间的循环工程），从而保证模型与代码的高度一致。

RationalRose支持C++、VisualC++、Java、Smalltalk、Ada、VisualBasic、PowerBuilder等语言和开发工具，并能为CORBA应用生成接口定义语言（IDL），为数据库应用生成数据库描述语言（DDL）等。

另外，RationalRose为团队开发和规范的开发过程管理提供了良好的支持。

对于小规模应用，我们可以使用微软公司Office套件中的Visio，其中提供了对UML各种图的绘制支持。

从应用的角度上来讲，面向对象的系统设计一般需要完成如下工作：

（1）描述需求；

（2）根据需求建立系统的静态模型；

（3）描述系统的行为。

（1）和

（2）中所建立的模型是静态的（采用用例图、类图、对象图、组件图和部署图等），是标准建模语言UML中的静态建模机制；而（3）中所建立的模型则表示执行时的序列、状态或交互关系（以状态图、活动图、顺序图和协作图描述），是标准建模语言UML中的动态建模机制。

由此可以看出，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

此外，需要说明的是，UML只是一种建模语言，它独立于具体的建模过程。

因此，利于它建模时，可遵循任何类型的建模过程。

尽管如此，UML的作者们为我们推荐了RUP（RationalUnifiedProcess）。

RUP由Rational软件公司首创，其最重要的特点有三：

（1）软件开发是由用例驱动的；

（2）软件开发是以体系结构设计（ArchitecturalDesign）为中心；

（3）软件开发是个迭代过程。

RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流，如图1.1所示。

图1.1RUP的流程

统一建模语言UML轻松入门之用例

目前，在的内地版《神雕侠侣》中，杨过和小龙女有一份不为人知的默契与浪漫，那就是他们所绘制的并肩小人图。

这样的小人图，是UML用例图的一部分，被称为参与者。

2.1用例与用例图

用例是需求分析中最重要的概念，需求表征了一个系统的设计特性、特征和行为，描述一个系统的需求意味着描述了建立在该系统外部的事物与系统之间的契约，契约上声明了期望系统做什么。

需求获取（RequirementElicitation）是需求工程的主体，其主要工作是建立待开发系统的模型，而用例就是用于建立这种模型的良好方法。

用例最初由IvarJackboson博士提出，后被综合到UML规范之中，成为需求表述的标准化体系。

前文已经提到，整个RUP流程都是"用例驱动"的，各种类型的开发活动包括项目管理、分析、设计、测试、实现等以用例为主要输入工件，用例模型奠定了整个系统软件开发的基础，用例被认作第二代面向对象技术的标志，可见其重要性非同一般。

我们先来给出一个具体而简单的用例图，即"图书管理系统"用例图，如图2.1。

在用例图中主要涉及到参与者（又称角色、执行者）、用例以及二者之间的通讯关联。

图2.1图书管理系统用例图

参与者

参与者是与系统、子系统或类发生交互的外部用户、进程或其他系统。

参与者可以是人、另一个计算机系统或一些可运行的进程。

在图2.1中，"读者"和"管理员"即为参与者。

参与者之间可以存在泛化关系，例如，在图2.1所示图书馆管理系统用例图中，可以认为"读者"是"学生读者"和"教师读者"的泛化，而"学生读者"还可以具体化为"本科生读者"和"研究生读者"；同样，"图书管理人员"也是"采购员"、"编目员"及"借阅人员"的泛化。

图2.2表示出了参与者之间的泛化关系。

图2.2参与者泛化关系

用例

用例是外部可见的一个系统功能，这些功能由系统所提供，并通过与参与者之间消息的交换来表达。

用例的用途是在不揭示系统内部构造的情况下定义行为序列，它把系统当作一个黑箱，表达整个系统对外部用户可见的行为。

鉴于用例的特点，用例一般被命名为一个能够说明目标的动名词组。

如图2.1中的"借书"、"还书"和"管理图书"皆为动名词组。

用例之间也可以存在包含、扩展和泛化等关系：

（1）包含关系：

用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。

（2）扩展关系：

扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。

它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。

在以下几种情况下，可使用扩展用例：

a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；

b.表明只在特定条件（如例外条件）下才执行的分支流；

c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。

所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。

图2.3给出了一个扩展关系的例子，在还书的过程中，只有在例外条件（读者遗失书籍）的情况下，才会执行赔偿遗失书籍的分支流。

图2.3用例扩展关系

（3）泛化关系：

用例可以被特别列举为一