软件工程与项目管理(第2版) 课件 第11章　统一建模语言(UML)

11.1概述

11.2UML概念模型

11.3UML的静态建模机制

11.4UML的动态建模机制

11.5UML面向实现机制

11.6UML建模工具11.1概述11.1.1什么是UMLUML是UnifiedModelingLanguage(统一建模语言)的简称，是基于对象管理组织(ObjectManagementGroup，OMG)进行标准化、软件成果的式样化和图形化的一种语言。Booch在其经典的一书TheUnifiedModelingLanguageUserGuide中对UML进行过详细的定义：UML是对软件密集型系统中的制品进行可视化、详细、构造和文档化的语言。其中的制品是指在软件开发过程中的各个阶段所产生的各种各样的成果物，如模型、源代码、测试用例等。UML代表着面向对象技术的软件开发方法的发展方向，在国际上越来越得到重视，现已成为国际软件行业建模语言的标准，目前已经占有面向对象技术市场的90%以上。11.1.2UML的发展史20世纪80年代中期至90年代初面向对象技术正逐渐被普及和广泛应用中，伴随着面向对象技术的迅猛发展，也相继出现了各种各样的方法论，如1988年RebeccaWirfsBrock提出的职责驱动(RCR)卡片法、1991年PeterCoad提出的OOA/OOD方法、1991年GradyBooch提出的Booch方法等。由于方法论的不同使得对同一个问题的描述表示法也有所不同，这样就在软件行业中系统开发者之间产生了很大的混乱。1994年10月，由GradyBooch和JimRumbaugh首先将Booch和OMT统一起来，并于1995年发布了成为统一方法的UM0.8版(UnifiedMethod)，1996年6月发布了统一建模语言UML0.9版(UnifiedModelingLanguage)，2002年11月出现了UML1.4版，此后，每隔几年就会进行版本更新，现在已经发布了最新的UML2.5版。UML的发展历史如图11.1所示。11.1.3UML的特点UML具有以下特点：(1)面向对象。UML支持面向对象技术的主要概念，提供了一批基本的模型元素的表示图形和方法，能简洁明了地表达面向对象的各种概念。(2)可视化，表示能力强。通过UML的模型图能清晰地表示系统的逻辑模型和实现模型，可用于各种复杂系统的建模。(3)独立于过程。UML是系统建模语言，独立于开发过程。(4)独立于程序设计语言。用UML建立的软件系统模型可以用Java、VC++、SmalltaIk等任何一种面向对象的程序设计来实现。(5)易于掌握使用。UML图形结构清晰，建模简洁明了，容易掌握使用。使用UML进行系统分析和设计，可以加速开发进程，提高代码质量，支持动态的业务需求。UML适用于各种规模的系统开发。能促进软件复用，方便地集成已有的系统，并能有效处理开发中的各种风险。11.1.4UML的应用领域UML的目标是以面向对象图的方式来描述任何类型的系统，具有很宽的应用领域。其中最常用的是建立软件系统的模型，但它同样可以用于描述非软件领域的系统，如机械系统、企业机构或业务过程，以及处理复杂数据的信息系统，具有实时要求的工业系统或工业过程等。总之，UML是一个通用的标准建模语言，可以对任何具有静态结构和动态行为的系统进行建模。UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。(1)在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。(2)在分析阶段，主要关心问题域中的主要概念(如抽象、类、对象等)和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。为实现用例，类之间需要相互协作，可以用UML动态模型来描述。在分析阶段，只对问题域的对象(现实世界的概念)建模，而不考虑定义软件系统中技术细节的类。这些技术细节将在设计阶段引入。(3)在设计阶段为构造阶段提供更详细的规格说明。编程(构造)是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据：(1)单元测试使用类图和类规格说明；(2)集成测试使用部件图、合作图；(3)系统测试使用用例图来验证系统的行为；(4)验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。总之，UML适用于以面向对象技术来描述任何类型的系统，而且适用于系统开发的不同阶段，从需求规格描述直至系统完成后的测试和维护。11.1.5基于UML的设计过程运用UML进行面向对象的系统分析设计，其过程通常由以下3个部分组成：(1)识别系统的用例和角色。首先对项目进行需求调研，依据项目的业务流程图和数据流程图以及项目中涉及的各级操作人员，通过分析，识别出系统中的所有用例和角色；接着分析系统中各角色和用例间的联系，再使用UML建模工具画出系统的用例图，同时，勾画系统的概念层模型，借助UML建模工具描述概念层的类图和活动图。(2)进行系统分析，并抽取类。系统分析的任务是找出系统的所有需求并加以描述，同时建立特定领域模型。建立域模型有助于开发人员考查用例，从中抽取出类，并描述类之间的关系。(3)系统设计，并设计类及其行为。设计阶段由结构设计和详细设计组成。①结构设计是高层设计，其任务是定义包(子系统)，包括包间的依赖关系和主要通信机制。包有利于描述系统的逻辑组成部分以及各部分之间的依赖关系。②详细设计就是要细化包的内容，清晰描述所有的类，同时使用UML的动态模型描述在特定环境下这些类的实例的行为。11.2UML概念模型11.2.1UML的构成UML主要由3类元素构成：基本构造块(BasicBuildingBlock)、规则(Rule)和公共机制(CommonMechanism)。11.2.2UML的基本构造块UML基本构造块包括3种类型：事物(Thing)、关系(Relationship)和图(Diagram)。事物又分为以下4种类型：(1)结构事物(StructuralThing)。UML中的结构事物包括类(Class)、接口(Interface)、协作(Collaboration)、用例(UseCase)、主动类(ActiveClass)、构件(Component)和节点(Node)。(2)行为事物(BehavioralThing)。UML中的行为事物包括交互(Interaction)和状态机(StateMachine)。(3)分组事物(GroupingThing)。UML中的事物是包(Package)。(4)注释事物(AnnotationalThing)。UML中的注释事物是注解(Note)。关系有以下4种类型：(1)依赖(Dpendency)：表示一个A对象发生变化，可能会引起另一个B对象的变化，则称B对象依赖于A对象。(2)关联(Association)：表示一种对象和另一种对象有联系，是一种结构化关系。(3)泛化(Generalization)：表示对象的一般类和特殊类之间的关系，相当于C++中的继承关系。(4)实现(Realization)：表示一种A模型元素(如类)与另一种B模型元素(如接口)连接起来，其中B模型只是行为的说明，而真正的实现则由A模型来完成。UML有4种视图和9种图：(1)用例视图(UseCaseDiagram)：从用户角度描述系统功能，并指出各功能的操作者。(2)静态视图(StaticDiagram)：包括类图、对象图和包图。(3)动态视图(DynamicDiagram)：描述系统的动态模型和组成对象间的交互关系，包括状态图和活动图；描述对象间的交互关系，包括时序图和合作图。(4)实现图(ImplementationDiagram)：包括组件图和配置图。在UML中建模主要分为静态建模和动态建模两类。(1)静态建模主要是对客观事物静态结构的一种抽象，它所反眏的是目标系统的静态数据。UML提供了丰富的静态建模机制，包括用例图、类图、对象图、包图等，其中尤以用例图和类图最为重要。(2)动态建模则强调的是系统的行为，它所建立的模型或者可以执行，或者表示执行时的时序状态或交互关系。动态建模包括协作图、时序图、活动图、状态图4个图形，是UML的动态建模机制。11.2.3UML的规则和其他语言一样，UML是有一套规则的，这些规则描述了一个结构良好的模型看起来应该像什么。一个结构良好的模型应该在语义上是前后一致的，并且与所有的相关模型协调一致。UML具有用于描述如下事物的语义规则：(1)命名：为事物、关系和图起名。(2)范围：给一个名称以特定含义的语境。(3)可见性：怎样让其他人使用或看见名称。(4)完整性：事物如何正确、一致地相互联系。(5)执行：运行或模拟动态模型的含义是什么。UML的规则鼓励(不是强迫)专注于最重要的分析、设计和实现问题，这些问题将促使模型随时间的推移而具有良好的结构。11.2.4UML的公共机制UML有4种贯穿整个语言并且一致应用的公共机制：(1)规格说明。规格说明提供了一个语义底版，它包含了一个系统的各模型的所有部分，并且各部分相互联系，并保持一致性。因此，UML的图只不过是对底版的简单视觉投影，每一个图展现了系统的一个特定的方面。(2)修饰。UML表示法中的每一个元素都有一个基本符号，可以把各种修饰细节加到这个符号上。(3)通用划分。在对面向对象系统建模中，至少有两种划分方法，一种是对类和对象的划分，一种是接口和实现的分离。(4)扩展机制。它包括构造型、标记值和约束。构造型扩展了UML的词汇，它允许创造新的构造块，这个新构造块既可从现有的构造块派生，又专门针对要解决的问题；标记值扩展了UML构造块的特性，允许创建详述元素的新信息；约束扩展了UML构造块的语义，它允许增加新的规则或修改现有的规则。11.3UML的静态建模机制11.3.1用例图无论在面向对象开发中还是在传统的软件开发中，人们总是根据典型的使用情景来了解用户需求。这些使用情景是非正式的，难以建立正式文档。在UML中可以通过用例图(UseCaseDiagram)来构造目标系统的用例模型，它通过用例来捕获用户需求，通过用例建模来描述对系统感兴趣的外部角色及其对系统(用例)的功能要求。它从系统外部观察系统，而不涉及技术上如何做这些事。1.用例模型用例模型(UseCaseModel)描述的是外部执行者(Actor)所理解的系统模型。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。首先，它描述了待开发系统的功能需求；其次，它将系统看作黑盒，从外部执行者的角度来理解系统；最后，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和UML的各个模型。在UML中，一个用例模型由若干个用例图描述，用例图的主要元素是用例和执行者。2.用例从本质上讲，一个用例(UseCase)是用户与计算机之间的一次典型交互过程。在UML中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。在UML中，用例表示为一个椭圆。概括地说，用例具有以下特点：(1)用例捕获某些用户可见的需求，实现一个具体的用户目标。(2)用例由执行者激活，并给执行者提供确切的值。(3)用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。3.执行者执行者是指用户在系统中所扮演的角色，其图形化的表示是一个小人。图11.2中有两个执行者：学生和管理员。在系统中有许多学生，但他们均起着同一种作用，扮演着相同的角色，所以用一个执行者表示。一个用户也可以扮演多种角色(执行者)，例如一个老师还可以是管理员。在处理执行者时，应考虑其作用，而不是人或工作名称。这一点是很重要的。不带箭头的线段将执行者与用例连接到一起，表示两者之间交换信息，称之为通信联系。执行者触发用例，并与用例进行信息交换，单个执行者可与多个用例联系；反过来，一个用例也可与多个执行者联系。对同一个用例而言，不同执行者起着不同的作用，他们可以从用例中取值，也可以参与到用例中。需要注意的是，尽管执行者在用例图中是用类似于人的图形来表示的，但执行者未必是人。通过实践，我们发现执行者对提供用例是非常有用的。面对一个大系统，要列出用例清单常常十分困难。这时可先列出执行者清单，再对每个执行者列出它的用例，这样问题就会变得很容易解决。4.使用和扩展除了执行者与用例之间的连接外，还有另外两种类型的连接，用以表示用例之间的使用和扩展关系。使用和扩展(UseandExtend)是两种不同形式的继承关系。当一个用例与另一个用例相似，但所做的动作多一些时，就可以用到扩展关系。当一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般来说，如果在若干个用例中有某些相同的动作，则可以把这些相同的动作提取出来单独构成一个用例(称为抽象用例)。例如，图11.3中学位课程的学习包括课程设计，因此二者构成了使用关系；学位课程的学习比专业课程的学习有更多的要求，因此二者构成了扩展关系。扩展与使用都意味着从几个用例中抽取那些公共的行为并放入一个单独用例中，而这个用例被其他几个用例使用或扩展，但使用和扩展的目的是不同的。5.用例模型的获取几乎在任何情况下都会使用用例。用例用来获取需求、规划和控制项目。用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生。随着工作的深入，更多的用例会被发现，这些用例都应及时增添到已有的用例集中。用例中的每个用例都是一个潜在的需求。(1)获取执行者。获取用例首先要找出系统的执行者。可以通过用户回答一些问题的答案来识别执行者。(2)获取用例。一旦获取了执行者，就可以对每个执行者提出问题以获取用例。11.3.2类图类图(ClassDiagram)专门用于捕获系统的词汇表。(1)类：具有相同属性、操作、关系的对象集合的总称。在UML中类通常被画成矩形。(2)类图：描述类和类之间的静态关系，在系统的整个生命周期都是有效的。与数据模型不同，它不仅显示了信息的结构，同时还描述了系统的行为。类图是定义其他图的基础。在类图的基础上，状态图、协作图等进一步描述了系统其他方面的特性。(3)名称：每个类都必须有一个名字，用来区分其他的类。类名是一个字符串，称为简单名字。(4)属性：指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。可以只写上属性名，也可以在属性名后跟上类型甚至缺省取值。根据图的详细程度，每条属性可以包括属性的可见性、属性名称、类型、缺省值和约束特性。UML规定类的属性的语法为：可见性属性名：类型 = 缺省值{约束特性}常用的可见性有Public、Private和Protected3种，在UML中分别表示为“+”“-”和“#”。类型表示该属性的种类。它可以是基本数据类型，如整数、实数、布尔型等，也可以是用户自定义的类型。一般它由所涉及的程序设计语言确定。约束特性则是一个用户对该属性性质约束的说明。(5)操作：是类的任意一个实例对象都可以调用的，并可能影响该对象行为的实现。该项可省略。操作用于修改、检索类的属性或执行某些动作。它们被约束在类的内部，只能作用到该类的对象上。UML规定操作的语法为：可见性操作名(参数表)：返回类型{约束特性}(6)约束：在UML中，可以用约束表示规则。约束是放在括号“{}”中的一个表达式，表示一个永真的逻辑陈述。(7)组织属性和方法：在画类图时没有必要将全部的属性和操作都画出来。实际上，在大部分情况下也不可能在一个图中将类的属性和操作都画出来，只将感兴趣的属性和操作画出来就可以了。可以用“...”表示还有属性或方法没有画出来。使用类图进行建模的几个建议如下：(1)不要试图使用所有的符号。在UML中，有些符号仅用于特殊的场合和方法中，只有当需要时才去使用。(2)根据项目开发的不同阶段，用正确的观点来画类图。如果处于分析阶段，则应画概念层类图；当开始着手软件设计时，应画说明层类图；当考察某个特定的实现技术时，则应画实现层类图。(3)不要为每个事物都画一个模型，应该把精力放在关键的领域。最好只画几张较为关键的图，经常使用并不断更新修改。(4)使用类图的最大危险是过早地陷入实现细节。为了避免这一危险，应该将重点放在概念层和说明层。11.3.3对象图对象图(ObjectDiagram)用于捕获实例和连接。UML中对象图与类图具有相同的表示形式。对象图可以看作是类图的一个实例。对象是类的实例。对象之间的链是类之间的关联的实例。链的图形表示与关联相似。对象与类的图形表示相似，即为划分成两个格子的长方形。下面的格子可省略，上面的格子显示对象名和类。对象名格式为 对象名：类名类名和对象名下面有下画线；下面的格子记录对象的属性以及值的列表，其格式为 属性：类型 = 值类型可以省略。对象图常用于表示复杂的类图的一个实例。11.3.4包图随着系统的逐渐变化，理解和修改这个系统也就变得更加困难，最好的方法是将复杂问题分解为多个简单的问题。包(Package)是一种组合机制，把许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。不仅仅是类可以运用包的机制，任何模型元素都可以运用包的机制(比如用例)。如果没有任何启发性原则来指导类的分组，则分组方法就会很随意。在UML中，最有用和强调最多的原则就是依赖性。通常，包图所显示的是类的包以及这些包之间的依赖关系。严格地说，这里所讲的包和依赖关系都是类图中的元素，因此包图仅仅是另一种形式的类图。包的图示类似于书签卡片的形状，由两个长方形组成。小长方形(标签)位于大长方形的左上角。如果包的内容(比如类)没被图示出来，则包的名字可以写在大长方形内，否则包的名字写在小长方形内，如图11.4所示。如果两个包中的任意两个类之间存在依赖关系，则这两个包之间也存在依赖关系。包的依赖有一个重要的特性，即不传递性。例如，若包C依赖于包B，包B依赖于包A，则包C不依赖于A，因为包A中的类的改变只直接影响到包B中的相应类，只要包B中被包C引用的类的接口不发生变化，包C就不会因包A的变化而受到影响。层次结构的这种非传递特性正是人们经常采用层次结构的原因之一。显然，如果依赖关系具有传递性，则当底层包被修改后，其可能波及的范围会非常大，从而使修改的范围变得难以控制。减小包与外界接口的一种方法是将包中与外界有联系的操作都取出来，组成一个小子集，对外只提供这个小子集。包的可见性限定了包中某些类只对本包中的类可见；同时，在包中可加入一些额外的公有类来表示包的公有行为。包的概念本身对于减少依赖关系并没有必然的帮助。但是，利用这种机制有助于更方便地发现在何处存在依赖，从而有助于通过适当的分组、打包等手段来减少依赖关系。此外，包还是保持系统整体结构简明、清晰的重要工具。对于一个已经存在的系统，通过查看包中的类就可以推断出包之间的依赖关系。包图是一个很有用的工具，特别是对于改进系统的结构非常有帮助。改进系统结构的基本步骤是：先将类划分成一些包并分析包的依赖关系，然后减少这些依赖关系。11.4UML的动态建模机制11.4.1协作图协作图(CollaborationDiagram)是动态视图的另一种表现形式，它强调参加交互的各对象的组织。协作图只对相互间有交互作用的对象和这些对象间的关系建模，而忽略了其他对象和关联。协作图可以被视为对象图的扩展，但它除了展现出对象间的关联外，还显示出对象间的消息传递过程。协作图包含以下3个元素：(1)对象(Object)。协作图中的对象与时序图的概念是一样的，但是在协作图中，无法表示对象的创建和撤销，所以对于对象在图中的位置没有限制。在协作图中用矩形表示对象，内部是对象的名字。(2)链(Link)。协作图中的链和对象图中的链所用的符号是一样的，即一条连接两个类角色的实线。(3)消息(Message)。协作图中的消息类型与时序图中的相同，但是为了说明交互过程中消息的时间顺序，可以在消息上添加顺序号，也可以添加箭头表示接收消息的对象。UML中的协作图如图11.5所示。11.4.2时序图时序图(SequenceDiagram)描述了对象之间传递消息的时间顺序，用来表示用例中的行为顺序，是强调消息时间顺序的交互图。时序图包含以下4种元素：(1)对象(Object)。对象代表时序图中的对象在交互中扮演的角色。将对象置于时序图的顶部意味着在交互开始时对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。(2)生命线(Lifeline)。生命线代表时序图中的对象在一段时期内的存在。每个对象底部都有一条垂直的虚线，用于表示该对象的生命线。(3)激活(Activation)。激活代表时序图中的对象执行一次操作的时期。每条生命线上的窄条矩形表示活动期。(4)消息(Message)。消息用于表示对象之间的交换信息的类。UML中的时序图如图11.6所示。11.4.3活动图活动图(ActivityDiagram)是一种描述系统行为的图，它用于展现参与行为的类所进行的各种活动的顺序关系，类似于程序流程图。活动图包括以下7种元素：(1)动作状态(ActionState)。对象的动作状态是活动图的最小单位的构成块，表示原子动作。动作状态使用平滑的圆角矩形表示，动作状态所表示的动作写在圆角矩形内部。(2)活动状态(ActivityState)。对象的活动状态可以被理解成一个组合，它的控制流由其他活动状态或动作状态组成。活动状态的表示图标也是平滑的圆角矩形，并可以在图标中给出入口动作、出口动作等信息。(3)动作流(ActionFlow)。所有动作状态之间的转换流称为动作流。与状态图的转换相同，活动图的转换也用带箭头的直线表示，箭头的方向指向转入的方向。(4)分支(Branch)与合并(Merge)。分支与合并描述了对象在不同的判断结果下所执行的不同动作。在活动图中分支与合并用小空心的菱形表示。(5)分叉(Fork)与汇合(Join)。分叉用于将动作流分成两个或者多个并发运行的分支，而汇合则用于同步这些并发分支，以达到共同完成一项事务的目的。分叉和汇合都使用加粗的水平线段表示。(6)泳道(Swimlane)。泳道将活动图中的活动划分为若干组，并把每一组指定给负责这组活动的业务组织即对象。泳道区分了负责活动的对象，明确地表示了哪些活动是由哪些对象进行的。每个活动只能明确地属于一个泳道。泳道用垂直实线绘出，垂直线分隔的区域就是泳道。(7)对象流(ObjectFlow)。对象流是动作状态或者活动状态与对象之间的依赖关系，表示动作使用对象或者动作对对象的影响。对象流用带有箭头的虚线表示。如果箭头从动作状态出发指向对象，则表示动作对对象施加了一定的影响。如果箭头从对象指向动作状态，则表示该动作使用对象流所指向的对象。活动图与状态图的区别如下：(1)活动图着重表现从一个活动到另一个活动的控制流，是内部处理驱动的流程。(2)状态图着重描述从一个状态到另一个状态的流程，主要有外部事件的参与。UML中的活动图如图11.7所示。11.4.4状态图状态图(StateDiagram)是描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应。通常，创建UML状态图是为了研究类、角色、子系统、或组件的复杂行为。状态图可由表示状态的节点和表示状态之间转换的带箭头的直线组成。状态图包括5种元素：状态(State)、转换(Transition)、初始状态(StartState)、终结状态(EndState)和判定(Decision)。UML中的状态图如图11.8所示。11.5UML面向实现机制11.5.1组件图组件图描述了软件的各种组件和它们之间的依赖关系。每一个组件图只描述系统实现中的某一方面，是系统的代码物理模块，当系统中的所有组件结合起来后，就可以完整地表示整个系统的实现视图。组件图中通常包含3个元素：组件(Component)、接口(Interface)和依赖关系(Dependency)。UML中的组件图如图11.9所示。(1)组件。组件是定义了良好接口的物理实现单元，是系统中可替换的物理部件。组件可以是源代码组件、二进制组件或一个可执行的组件。在UML中，组件用一个左侧带有突出两个小矩形的矩形来表示。(2)接口。接口是一个类提供给另一个类的一组操作。组件可以通过其他组件的接口来使用那些组件中定义的一些操作。组件的接口分为两种：①导入接口(ImportInterface)：提供给访问操作的组件使用。②导出接口(ExportInterface)：由提供操作的组件提供。接口和组件之间的关系分为两种：①实现关系(Realization)：接口和组件之间用实线连接表示实现关系。②依赖关系(Dependency)：接口和组件之间用虚线箭头连接。(3)依赖关系。依赖关系表示组件图中各组件之间存在的关系类型。UML的组件图中依赖关系的表示方法与类图中依赖关系的表示方法相同，都是一个由客户指向提供者的虚线箭头。组件图的依赖关系如图11.10所示。11.5.2配置图配置图描述了运行软件的系统中硬件和软件的物理结构。配置图中包含两个元素：节点(Node)和关联关系(Association)。配置图可以显示节点以及它们之间的必要连接，也可以显示这些连接的类型，还可以显示组件和组件之间的依赖关系，但是每个组件必须存在于某些节点上。UML中的部署图如图11.11所示。(1)节点是表示在运行时代表计算资源的物理元素。节点通常拥有一些内存，并具有处理能力(如处理器、设备)，在UML中是用一个立方体来表示的。(2)关联关系是表示各节点之间的通信路径，在UML中是用一条实线来表示的。11.6UML建模工具11.6.1RationalRoseRationalRose是由美国Rational公司开发的一种面向对象的统一建模语言的可视化建模工具。利用该工具可以建立用UML描述的软件系统模型，而且可以自动生成和维护C++、Java、VB、Oracle等语言和系统的代码。RationalRose包括了统一建模语言UML、面向对象的软件工程OOSE以及对象建模技术OMT。其中，统一建模语言UML是由UML业内的三位创始人、面向对象领域的大师级人物——Booch、Rumbaugh和Jacobson通过对早期面向对象技术的研究而创建的，而这三位大师都曾经担任过Rational公司的首席工程师。2002年，Rational软件公司被IBM公司收购，现已成为IBM的第五大品牌。RationalRose在建模方面具有以下特点：(1)保证模型和代码的高度一致，实现真正意义上的双向工程。(2)支持多种语言，如C++、VB、VC++、Java、PB等。(3)为团队开发提供了强有力的支持，提供了SCM软件配置管理功能。(4)支持模型的Internet发布，提供了基于HTML版本的发布功能。(5)生成使用简