UML轻松入门.docx

1、UML轻松入门统一建模语言UML轻松入门之基本概念20 世纪80 年代，随着面向对象技术成为研究的热点，先后出现了几十种面向对象的软件开发方法。其中，Booch、OMT 和OOSE等方法得到了广泛的认可。然而，采用不同方法进行建模不利于开发者之间的交流。而UML则统一了Booch、OMT 和OOSE 的表示方法，而且对其作了进一步的发展。1997 年，UML 被国际对象组织OMG采纳为面向对象的建模语言的国际标准，它溶入了软件工程领域的新思想、新方法和新技术。UML不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。数年来，UML凭借其简洁明晰的表达方式、超凡脱俗的表达能力

2、，一路杀将出来，为业界所广泛认同！目前，在多数大型企业的正规化开发流程中，开发人员普遍使用UML进行模型的建立。作为一名软件开发人员，我们必须学会UML。因为UML就是那个统一的文字，统一的度、量、衡，不理解UML，作为软件设计统一王国的国民，将是艰难而痛苦的。作曲家会将其脑袋中的旋律谱成乐曲，建筑师会将其设计的建筑物画成蓝图，这些乐曲、蓝图就是模型(Model)，而建构这些模型的过程就称为建模(Modeling)。软件开发如同音乐谱曲及建筑设计，其过程中也必须将需求、分析、设计、实现、布署等各项工作流程的构想与结果予以呈现，这就是软件系统的建模。 那么为什么要建模呢？经典答案是：建立大厦和建

3、立狗窝的区别是建设狗窝不需要设计，要生产合格的软件就要有一套关于体系结构、过程和工具的规范。OMG官方发布的UML的当前最高版本为2.0，可以从http:/www.uml.org/上下载。UML由图和元模型组成，图是语法，元模型是语义。UML主要包括三个基本构造块：事物（Things）、关系（Relationships）和图（Diagrams）。本次连载我们将对UML的这些基本组成部分及UML工具和应用进行介绍，使读者对UML形成初步的整体印象。在其后的几次连载里，再以数个实例对这些内容逐步展开。1.1 UML的基本构造块1.1.1事物事物是是实体抽象化的最终结果，是模型中的基本成员，UML中

4、包含结构事物、行为事物、分组事物和注释事物。（1）结构事物（Structural things）结构事物是模型中的静态部分，用以呈现概念或实体的表现元素，是软件建模中最常见的元素，共有以下七种：类（Class）：类是指具有相同属性、方法、关系和语义的对象的集合；接口（Interface）：接口是指类或组件所提供的服务（操作），描述了类或组件对外可见的动作；协作（Collaboration）：协作描述合作完成某个特定任务的一组类及其关联的集合，用于对使用情形的实现建模；用例（Use Case）：用例定义了执行者（在系统外部和系统交互的人）和被考虑的系统之间的交互来实现的一个业务目标；活动类（Ac

5、tive Class）：活动类的对象有一个或多个进程或线程。活动类和类很相象，只是它的对象代表的元素的行为和其他的元素是同时存在的；组件（Component）：组件是物理的、可替换的部分，包含接口的集合，例如COM+ 、JAVA BEANS等；结点（Node）：结点是系统在运行时存在的物理元素，代表一个可计算的资源，通常占用一些内存和具有处理能力。（2）行为事物（Behavioral things）行为事物指的是UML模型中的动态部分，代表语句里的动词，表示模型里随着时空不断变化的部分，包含两类：交互（ineraction）：交互是由一组对象之间在特定上下文中，为达到特定的目的而进行的一系列消

6、息交换而组成的动作；状态机（state machine）：状态机由一系列对象的状态组成。（3）分组事物（Grouping things）可以把分组事物看成是一个盒子，模型可以在其中被分解。目前只有一种分组事物，即包（package）。结构事物、动作事物甚至分组事物都有可能放在一个包中。包纯粹是概念上的，只存在于开发阶段，而组件在运行时存在。（4）注释事物（Annotational things）注释事物是UML模型的解释部分。1.1.2关系关系是将事物联系在一起的方式，UML中定义了四种关系：（1）依赖（Dependencies）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的

7、语义；（2）关联（Association）：一种描述一组对象之间连接的结构关系，如聚合关系（描述了整体和部分间的结构关系）；（3）泛化（Generalization）：一种一般化-特殊化的关系；（4）实现(Realization) ：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约。1.1.3图图是事物集合的分类，UML中包含多种图：（1）类图(Class Diagram)：类图描述系统所包含的类、类的内部结构及类之间的关系；（2）对象图(Object Diagram)：对象图是类图的一个具体实例；（3）包图（Package Diagram）：包图表明包及其之间的依赖类图；（4）组

8、件图(Compoment Diagram，也称构件图)：组件图描述代码部件的物理结构以及各部件之间的依赖关系；（5）部署图(Deployment Diagram)：部署图定义系统中软硬件的物理体系结构；（6）用例图(Usecase Diagram)：用例图从用户的角度出发描述系统的功能、需求，展示系统外部的各类角色与系统内部的各种用例之间的关系；（7）顺序图(Sequence Diagram)：顺序图表示对象之间动态合作的关系； （8）协作图(Collaboration Diagram)：合作图描述对象之间的协作关系；（9）状态图(Statechart Diagram)：状态图描述一类对象的所

9、有可能的状态以及事件发生时状态的转移条件；（10）活动图(Activity Diagram)：活动图描述系统中各种活动的执行顺序。上述十种图可归纳为五类，如表1.1。表1.1 UML图分类类型包含静态图类图、对象图、包图行为图状态图、活动图用例图用例图交互图顺序图、协作图实现图组件图、部署图1.2 UML工具与应用工欲善其事，必先利于器，为了有效的利用UML，我们需要首先获得一个UML工具软件。当前，业界使用最广泛的UML建模工具为Rational Rose。Rational Rose中可实现正向（为模型产生相应的代码）、逆向（从用户原来的软件系统导出该系统的模型）和双向工程（实现模型和代码之

10、间的循环工程），从而保证模型与代码的高度一致。Rational Rose支持C+、Visual C+、Java、Smalltalk、Ada、Visual Basic、PowerBuilder等语言和开发工具，并能为CORBA 应用生成接口定义语言（IDL），为数据库应用生成数据库描述语言（DDL）等。另外，Rational Rose为团队开发和规范的开发过程管理提供了良好的支持。对于小规模应用，我们可以使用微软公司Office套件中的Visio，其中提供了对UML各种图的绘制支持。从应用的角度上来讲，面向对象的系统设计一般需要完成如下工作：（1）描述需求；（2）根据需求建立系统的静态模型；（3

11、）描述系统的行为。（1）和（2）中所建立的模型是静态的（采用用例图、类图、对象图、组件图和部署图等），是标准建模语言UML中的静态建模机制；而（3）中所建立的模型则表示执行时的序列、状态或交互关系（以状态图、活动图、顺序图和协作图描述），是标准建模语言UML中的动态建模机制。由此可以看出，标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。 此外，需要说明的是，UML只是一种建模语言，它独立于具体的建模过程。因此，利于它建模时，可遵循任何类型的建模过程。尽管如此，UML的作者们为我们推荐了RUP（Rational Unified Process）。RUP由Rational

12、软件公司首创，其最重要的特点有三：（1）软件开发是由用例驱动的；（2）软件开发是以体系结构设计（Architectural Design）为中心；（3）软件开发是个迭代过程。RUP包括四个阶段，每个阶段又分为若干次迭代，每次迭代都有一个核心工作流，如图1.1所示。图1.1 RUP的流程统一建模语言UML轻松入门之用例目前，在的内地版神雕侠侣中，杨过和小龙女有一份不为人知的默契与浪漫，那就是他们所绘制的并肩小人图。这样的小人图，是UML用例图的一部分，被称为参与者。2.1 用例与用例图用例是需求分析中最重要的概念，需求表征了一个系统的设计特性、特征和行为，描述一个系统的需求意味着描述了建立在该系

13、统外部的事物与系统之间的契约，契约上声明了期望系统做什么。需求获取(Requirement Elicitation) 是需求工程的主体，其主要工作是建立待开发系统的模型，而用例就是用于建立这种模型的良好方法。用例最初由Ivar Jackboson博士提出，后被综合到UML规范之中，成为需求表述的标准化体系。前文已经提到，整个RUP流程都是用例驱动的，各种类型的开发活动包括项目管理、分析、设计、测试、实现等以用例为主要输入工件，用例模型奠定了整个系统软件开发的基础，用例被认作第二代面向对象技术的标志，可见其重要性非同一般。我们先来给出一个具体而简单的用例图，即图书管理系统用例图，如图2.1。在用

14、例图中主要涉及到参与者（又称角色、执行者）、用例以及二者之间的通讯关联。图2.1 图书管理系统用例图参与者参与者是与系统、子系统或类发生交互的外部用户、进程或其他系统。参与者可以是人、另一个计算机系统或一些可运行的进程。在图2.1中，读者和管理员即为参与者。参与者之间可以存在泛化关系，例如，在图2.1所示图书馆管理系统用例图中，可以认为读者是学生读者和教师读者的泛化，而学生读者还可以具体化为本科生读者和研究生读者；同样，图书管理人员也是采购员、编目员及借阅人员的泛化。图2.2表示出了参与者之间的泛化关系。图2.2 参与者泛化关系用例用例是外部可见的一个系统功能，这些功能由系统所提供，并通过与参

15、与者之间消息的交换来表达。用例的用途是在不揭示系统内部构造的情况下定义行为序列，它把系统当作一个黑箱，表达整个系统对外部用户可见的行为。 鉴于用例的特点，用例一般被命名为一个能够说明目标的动名词组。如图2.1中的借书、还书和管理图书皆为动名词组。用例之间也可以存在包含、扩展和泛化等关系：（1）包含关系：用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为做为自身行为的一部分，这被称作包含关系。（2）扩展关系：扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。在以下几种情况下，可使用扩展用例：a.表明用例的某一部分是可选的系统行为（这样，您就可以将模型中的可选行为和必选行为分开）；b.表明只在特定条件（如例外条件）下才执行的分支流； c.表明可能有一组行为段，其中的一个或多个段可以在基本用例中的扩展点处插入。所插入的行为段和插入的顺序取决于在执行基本用例时与主角进行的交互。图2.3给出了一个扩展关系的例子，在还书的过程中，只有在例外条件（读者遗失书籍）的情况下，才会执行赔偿遗失书籍的分支流。图2.3用例扩展关系（3）泛化关系：用例可以被特别列举为一