河北农业大学信息科学与技术学院

第五章UML设计技术Prof.GuifaTeng统一建模语言（UnifiedModelingLanguage,UML）

是一种整合多种模型的语言，由Rumbaugh、Booch和Jacobson三位大师提出。是第三代用来为面向对象开发系统的产品进行说明、可视化和编制文档的方法。UML(统一建模语言)设计技术UML得发展历程2001年（计划的重要修订）2000年（计划的较小修订）199919981997年9月最后提交给OMG1997年1月最初提交给OMG1996

1995文字上的修改没有显著的技术变化精化相关文档版类

什么是UMLUML是一种标准的图形化建模语言，它是面向对象分析与设计的一种标准表示。它：不是一种可视化的程序设计语言，而是一种可视化的建模语言；不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种表示的标准；不是过程，也不是方法，但允许任何一种过程和方法使用它；

UML的目标易于使用、表达能力强，进行可视化建模；与具体的实现无关，可应用于任何语言平台和工具平台；与具体的过程无关，可应用于任何软件开发的过程；简单并且可扩展，具有扩展和专有化机制，便于扩展，无需对核心概念进行修改；为面向对象的设计与开发中涌现出的高级概念（例如协作、框架、模式和组件）提供支持，强调在软件开发中，对架构、框架、模式和组件的重用；与最好的软件工程实践经验集成；可升级、具有广阔的适用性和可用性；有利于面对对象工具的市场成长。

UML的架构

UML是由图和元模型组成的。图是UML的语法，而元模型则给出的图的意思，是UML的语义。UML的语义是定义在一个四层（或四个抽象级）建模概念框架中的，这四层分别是：元元模型（meta-metamodel）层，组成UML最基本的元素“事物（Thing）”，代表要定义的所有事物；元模型（metamodel）层，组成了UML的基本元素，包括面向对象和面向组件的概念。这一层的每个概念都是元元模型中“事物”概念的实例（通过版类化）；

UML的架构

模型（model）层，组成了UML的模型，这一层中的每个概念都是元模型层中概念的一个实例（通过版类化），这一层的模型通常叫做类模型（classmodel）或类型模型（typemodel）；用户模型（usermodel）层，这层中的所有元素都是UML模型的例子。这一层中的每个概念都是模型层的一个实例（通过分类），也是元模型层的一个实例通（过版类化）。这一层的模型通常叫做对象模型（objectmodel）或实例模型（instancemodel）。UML的模型、视图、图与系统架构建模

UML是用来描述模型的，它用模型来描述系统的结构或静态特征、以及行为或动态特征。它从不同的视角为系统的架构建模形成系统的不同视图view包括：用例视图（usecaseview）,强调从用户的角度看到的或需要的系统功能，这种视图也叫做用户模型视图（usermodelview）或想定视图（scenarioview）；逻辑视图（logicalview）,展现系统的静态或结构组成及特征,也称为结构模型视图（structuralmodelview）或静态视图（staticview）；UML的模型、视图、图与系统架构建模

并发视图（concurrentview），体现了系统的动态或行为特征，也称为行为模型视图（behavioralmodelview）、过程视图（processview）协作视图（collaborative）、动态视图（dynamicview）；组件视图（componentview），体现了系统实现的结构和行为特征，也称为实现模型视图（implementationmodelview）和开发视图（developmentview）；展开视图（deploymentview），体现了系统实现环境的结构和行为特征，也称为环境模型视图（implementationmodelview）或物理视图（physicalview）；UML与面向对象的软件分析与设计（OOA&D）标准的表示方法

UML是一种建模语言，是一种标准的表示，而不是一种方法（或方法学）。方法是一种把人的思考和行动结构化的明确方式，方法需要定义软件开发的步骤、告诉人们做什么，如何做，什么时候做，以及为什么要这么做。而UML只定义了一些图以及它们的意义，它的思想是与方法无关。因此，我们会看到人们将用各种方法来使用UML，而无论方法如何变化，它们的基础是UML的图，这就是UML的最终用途----为不同领域的人们提供统一的交流标准。与软件开发的成功经验集成

在众多成功的软件设计与实现的经验中，最突出的两条:一是注重系统架构的开发，一是注重过程的迭代和递增性。尽管UML本身没有对过程有任何定义，但UML对任何使用它的方法（或过程）提出的要求是：支持用例驱动（use-casedriven）、以架构为中（architecture-centric）以及递增（incremental）和迭代（iterative）地开发。与软件开发的成功经验集成

注重架构意味着不仅要编写出大量的类和算法，还要设计出这些类和算法之间简单而有效地协作。所有高质量的软件中似乎大量是这类的协作，而近年出现的软件设计模式也正在为这些协作起名和分类，使它们更易于重用。最好的架构就是“概念集成（conceptualintegration）”，它驱动整个项目注重开发模式并力图使它们简单。迭代和递增的开发过程反映了项目开发的节奏。UML的应用领域在不同类型系统中的应用：UML的目标是用面向对象的方式描述任何类型的系统。最直接的是用UML为软件系统创建模型，但UML也可用来描述其它非计算机软件的系统或者是商业机构或过程。以下是UML常见的应用：信息系统（InformationSystem）：向用户提供信息的储存、检索、转换和提交。处理存放在关系或对象数据库中大量具有复杂关系的数据；技术系统（TechnicalSystem）：处理和控制技术设备，如电信设备、军事系统或工业过程。它们必须处理设计的特殊接口，标准软件很少。技术系统通常是实时系统；嵌入式实时系统（EmbeddedReal-TimeSystem）：在嵌入到其它设备如移动电话、汽车、家电上的硬件上执行的系统。通常是通过低级程序设计进行的，需要实时支持；分布式系统（DistributedSystem）：分布在一组机器上运行的系统，数据很容易从一个机器传送到另一台机器上。需要同步通信机制来确保数据完整性，通常是建立在对象机制上的，如CORBA，COM/DCOM，或JavaBeans/RMI上；系统软件（SystemSoftware）：定义了其它软件使用的技术基础设施。操作系统、数据库和在硬件上完成底层操作的用户接口等，同时提供一般接口供其它软件使用；商业系统（BusinessSystem）：描述目标、资源（人，计算机等），规则（法规、商业策略、政策等）和商业中的实际工作（商业过程）。要强调的是，通常大多数系统都不是单纯属于上面的某一种系统，而是一种或多种的结合。例如，现在许多信息系统都有分布式和实时的需要。在软件开发的不同阶段中的应用UML的应用贯穿在系统开发的五个阶段，它们是：需求分析。UML的用例视图可以表示客户的需求。通过用例建模，可以对外部的角色以及它们所需要的系统功能建模。角色和用例是用它们之间的关系、通信建模的。每个用例都指定了客户的需求：他或她需求系统干什么。不仅要对软件系统，对商业过程也要进行需求分析；分析。分析阶段主要考虑所要解决的问题，可用UML的逻辑视图和动态视图来描述：类图描述系统的静态结构，协作图、状态图、序列图、活动图和状态图描述系统的动态特征。在分析阶段，只为问题领域的类建模----不定义软件系统的解决方案的细节（如用户接口的类、数据库等）；设计。在设计阶段，把分析阶段的结果扩展成技术解决方案。加入新的类来提供技术基础结构----用户接口，数据库操作等。分析阶段的领域问题类被嵌入在这个技术基础结构中。设计阶段的结果是构造阶段的详细的规格说明；构造。在构造（或程序设计阶段），把设计阶段的类转换成某种面向对象程序设计语言的代码。在对UML表示的分析和设计模型进行转换时，最好不要直接把模型转化成代码。因为在早期阶段，模型是理解系统并对系统进行结构化的手段。测试。对系统的测试通常分为单元测试、集成测试、系统测试和接受测试几个不同级别。单元测试是对几个类或一组类的测试，通常由程序员进行；集成测试集成组件和类，确认它们之间是否恰当地协作；系统测试把系统当作一个“黑箱”，验证系统是否具有用户所要求的所有功能；接受测试由客户完成，与系统测试类似，验证系统是否满足所有的需求。UML设计技术Prof.GuifaTengUML语言概述

UML由视图(Views)、图（Diagrams)、模型元素(ModelElements)和通用机制(GeneralMechanism)等几个部分构成UML语言概述视图(Views)图(Diagrams)图片(Graph)用例图(Usecasediagram)类图(Classdiagram)对象图(Objectdiagram)序列图(Sequencediagram)协作图(Collaborationdiagram)状态图(Statediagram)活动图(Activitydiagram)组件图(Componentdiagram)展开图Deploymentdiagram模型元素(ModelElements)视图元素(符号)关联通用机制(GeneralMechanism)修饰(Adornment)

笔记(Note)规格说明(specification)扩展机制版类(stereotype)加标签值(taggedvalue)约束(constrains)视图用来表示被建模系统的各个方面（从不同的目的出发建立，为系统建立多个模型，这些模型都反映同一个系统，且具有一致性）。视图由多个图（Diagrams）构成，它不是一个图片（graph），而是在某一个抽象层上，对系统的抽象表示。如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面就可以了。另外，视图还把建模语言和系统开发时选择的方法或过程连接起来。UML中的视图包括：用例视图（Use-caseview）、逻辑视图（Logicalview）、组件视图（coopponentview）、并发视图（Concurrencyview）展开视图（Deploymentview）、等五种。能够使用的其他视图还有静态--动态视图、逻辑--物理视图工作流程（workflow）等视图但UML语言中并不使用这些视图它们是UML语言的设计者意识中的视图因此在未来的大多数CASE工具中有可能包含这些视图。图由各种图片（graph）构成，用来描述一个视图的内容。UML语言定义了9种不同的图的类型，把它们有机地结合起来就可以描述系统的所有视图。模型元素代表面向对象中的类、对象、消息和关系等概念，是构成图的最基本的常用概念。一个模型元素可以用在多个不同的图中，无论怎样使用，它总是具有相同的含义和相同的符号表示。通用机制用于表示其他信息，比如注释、模型元素的语义等。另外，它还提供扩展机制，使UML语言能够适应一个特殊的方法（或过程）或扩充至一个组织或用户。用例视图

用例视图（Use-caseview）用于描述系统应该具有的功能集。它是从系统的外部用户角度出发，对系统的抽象表示。用例视图中可以包含若干个用例（use-case）。用例用来表示系统能够提供的功能（系统用法），一个用例是系统用法（功能请求）的一个通用描述。用例视图主要为用户、设计人员、开发人员和测试人员而设置。用例视图静态地描述系统功能，为了动态地观察系统功能，偶尔也用活动图（activitydiagram）描述。逻辑视图

逻辑视图（Logicalview）用来显示系统内部的功能是怎样设计的，它利用系统的静态结构和动态行为来刻画系统功能。静态结构描述类、对象和它们之间的关系等。动态行为主要描述对象之间的动态协作，当对象之间彼此发送消息给给定的函数时产生动态协作，一致性（persistence）和并发性（concurrency）等性质，以及接口和类的内部结构都要在逻辑视图中定义。组件视图

组件视图（Componentview）用来显示代码组件的组织方式它描述了实现模块（implementationmodule）和它们之间的依赖关系。组件视图由组件图构成。组件是代码模块，不同类型的代码模块形成不同的组件，组件按照一定的结构和依赖关系呈现。组件的附加信息（比如，为组件分配资源）或其他管理信息（比如，进展工作的进展报告）也可以加入到组件视图中。组件视图主要供开发者使用。并发视图

并发视图（ConcurrencyView）用来显示系统的并发工作状况。并发视图将系统划分为进程和处理机方式，通过划分引入并发机制，利用并发高效地使用资源、并行执行和处理异步事件。除了划分系统为并发执行的控制线程外，并发视图还必须处理通信和这些线程之间的同步问题。并发视图所描述的方面属于系统中的非功能性质方面。并发视图供系统开发者和集成者（integrator）使用它由动态图（状态图、序列图、协作图、活动图）和执行图（组件图、展开图）构成。展开视图

展开视图（DeploymentView）用来显示系统的物理架构，即系统的物理展开。比如，计算机和设备以及它们之间的联接方式。其中计算机和设备称为结点（node）。它由展开图表示。展开视图还包括一个映射，该映射显示在物理架构中组件是怎样展开的。比如，在每台独立的计算机上哪一个程序或对象在运行。展开视图提供给开发者、集成者和测试者。图

图（diagram）由图片（graph）组成，图片是模型元素的符号化。把这些符号有机地组织起来形成的图表示了系统的一个特殊部分或某个方面。一个典型的系统模型应有多个各种类型的图。图是一个具体视图的组成部分，在画一个图时，就相当于把这个图分配给某个视图了。依据图本身的内容，有些图可能是多个视图的一部分。UML中包含用例图、类图、对象图、状态图、序列图、协作图、活动图、组件图、展开图共九种。用例图

用例图（use-casediagram）用于显示若干角色（actor）以及这些角色与系统提供的用例之间的连接关系，如下图所示。用例是系统提供的功能（即系统的具体用法）的描述。通常一个实际的用例采用普通的文字描述，作为用例符号的文档性质。当然，实际的用例图也可以用活动图描述。用例图仅仅从角色（触发系统功能的用户等)使用系统的角度描述系统中的信息，也就是站在系统外部察看系统功能，它并不描述系统内部对该功能的具体操作方式。用例图定义的是系统的功能需求。以后对用例图的图示方法、含义将进一步介绍。用例图示例签定保险单

销售统计资料

客户数据资料

客户

销售保险员casesactorsactors

用例图示例

类图

类图（classdiagram）用来表示系统中的类和类与类之间的关系，它是对系统静态结构的描述，如下图所示。类用来表示系统中需要处理的事物。类与类之间有多种连接方式（关系），比如：关联（彼此间的连接)、依赖（一个类使用另一个类）、通用化（一个类是另一个类的特殊化）或打包（packaged）（多个类聚合成一个基本元素）。类与类之间的这些关系都体现在类图的内部结构之中，通过类的属性（attribute）和操作（operation）这些术语反映出来。在系统的生命周期中，类图所描述的静态结构在任何情况下都是有效的。后面再详细讨论。类图示例客户1拥有1..*有价证券1..*处理1交易员仪器工具含有0..*0..*债券股票股票选择金融贸易类图示例对象图

对象图是类图的变体。两者之间的差别在于对象图表示的是类的对象实例，而不是真实的类。对象图是类图的一个范例（example），它及时具体地反映了系统执行到某处时，系统的工作状况。对象图中使用的图示符号与类图几乎完全相同，只不过对象图中的对象名加了下划线，而且类与类之间关系的所有实例也都画了出来，如下图所示。图（a）的类图抽象地显示各个类及它们之间的关系，图（b）的对象图则是图（a）类图的一个实例表示。对象图与类图示例

对象图没有类图重要，对象图通常用来示例一个复杂的类图，通过对象图反映真正的实例是什么，它们之间可能具有什么样的关系，帮助对类图的理解。对象图也可以用在协作图中作为其一个组成部分，用来反映一组对象之间的动态协作关系。1..*作家姓名:string年龄:integer计算机名称:string内存:integer丁一：作家（a）类图0..1使用姓名=丁一年龄=30丁一办公室中的pc:计算机名称=Dell466内存=64丁一家里的pc:计算机名称=长城p

IIMMX内存=64（b）对象图状态图

状态图是对类所描述事物的补充说明，它显示了类的所有对象可能具有的状态，以及引起状态变化的事件，如下图所示，事件可以是给它发送消息的另一个对象或者某个任务执行完毕（比如，指定时间到）。状态的变化称作转移（transition）。一个转移可以有一个与之相连的动作（action），这个动作指明了状态转移时应该做些什么。并不是所有的类都有相应的状态图。状态图仅用于具有下列特点的类：具有若干个确定的状态，类的行为在这些状态下会受到影响且被不同的状态改变。另外，也可以为系统描绘整体状态图。关于状态图将进一步的讨论。状态图示例大楼的一层上升楼层向上升到达一层移到一层向下升到达楼层下降楼层超时空闲上升楼层电梯的状态图示例序列图

序列图用来反映若干个对象之间的动态协作关系，也就是随着时间的流逝，对象之间是如何交互的，如下图所示。序列图主要反映对象之间已发送消息的先后次序，说明对象之间的交互过程，以及系统执行过程中，在某一具体位置将会有什么事件发生。序列图由若干个对象组成，每个对象用一个垂直的虚线表示（线上方是对象名），每个对象的正下方有一个矩形条，它与垂直的虚线相叠，矩形条表示该对象随时间流逝的过程（从上至下），对象之间传递的消息用消息箭头表示，它们位于表示对象的垂直线条之间。时间说明和其他的注释作为脚本放在图的边缘。对序列图的讨论将在以后介绍。

序列图示例打印（文件）计算机打印服务器打印机打印（文件）[打印机空闲]打印（文件）[打印机忙]存储（文件）队列

序列图示例协作图

协作图和序列图的作用一样，反映的也是动态协作。除了显示消息变化（称为交互）外，协作图还显示了对象和它们之间的关系（称为上下文有关）。由于协作图或序列图都反映对象之间的交互，所以建模者可以任意选择一种反映对象间的协作。如果需要强调时间和序列，最好选择序列图；如果需要强调上下文相关；最好选择协作图。协作图与对象图的画法一样，图中含有若干个对象及它们之间的关系（使用对象图或类图中的符号），对象之间流动的消息用消息箭头表示，箭头中间用标签标识消息被发送的序号、条件、迭代（iteration）方式、返回值等等。通过识别消息标签的语法，开发者可以看出对象间的协作，也可以跟踪执行流程和消息的变化情况。协作图中也能包含活动对象，多个活动对象可以并发执行。如图所示。以后将详细讨论协作图。：计算机：打印服务器：队列：打印机

111：打印（文件）

[打印机忙]1.2：存储（文件）

[打印机空闲]1.1：打印（文件）协作图示例协作图示例活动图

活动图（activitydiagram）反映一个连续的活动流，如下图所示。相对于描述活动流（比如，用例或交互）来说，活动图更常用于描述某个操作执行时的活动状况。活动图由各种动作状态（actionstate）构成，每个动作状态包含可执行动作的规范说明。当某个动作执行完毕，该动作的状态就会随着改变。这样动作状态的控制就从一个状态流向另一个与之相连的状态。活动图中还可以显示决策、条件、动作状态的并行执行、消息（被动作发送或接收）的规范说明等内容。

Printfile()

[磁盘满]

[空闲磁盘空间]

在屏幕上显示磁盘满

在屏幕上显示打印

产生附录文件

^Printer.Print(file)

擦除屏幕上的提示信息

活动图示例活动图示例组件图

组件图（componentdiagram）用来反映代码的物理结构。代码的物理结构用代码组件表示。组件可以是源代码、二进制文件或可执行文件组件。组件包含了逻辑类或逻辑类的实现信息，因此逻辑视图与组件视图之间存在着映射关系。组件之间也存在依赖关系，利用这种依赖关系可以方便地很容易地分析一个组件的变化会给其他的组件带来怎样的影响。组件可以与公开的任何接口（比如OLE/COM接口），一起显示，也可以把它们组合起来形成一个包（package），在组件图中显示这种组合包。实际编程工作中经常使用组件图（如下图所示）。后面将进一步详述组件图。

窗口控制（whnd.cpp）

通信控制（comhnd.cpp）

主控模块（main.cpp）

窗口控制（whnd.obj）

通信控制（comhnd.obj）

主控模块（main.obj）图形库（graphic.dll）

客户程序（client.exe）组件图示例组件图示例展开图

展开图（deploymentdiagram）用来显示系统中软件和硬件的物理架构。通常展开图中显示实际的计算机和设备（用结点表示），以及各个结点之间的关系（还可以显示关系的类型）。每个结点内部显示的可执行的组件和对象清晰地反映出哪个软件运行在哪个结点上。组件之间的依赖关系也可以显示在展开图中。展开图用来表示展开视图，描述系统的实际物理结构。用例视图是对系统应具有的功能的描述，它们二者看上去差别很大，似乎没有什么联系。然而，如果对系统的模型定义明确，那么从物理架构的结点出发，找到它含有的组件，再通过组件到达它实现的类，再到达类的对象参与的交互，直至最终到达一个用例也是可能的。从整体来说，系统的不同视图给系统的描述应当是一致的。客户A：CompaqProPc“Tcp/Ip”应用服务器：SiliconGraphicsO2数据库服务器：“DecNet”VAX客户B：

CompaqproPc“Tcp/Ip”展开图示例展开图示例静态建模用例和用例图

用例模型是把应满足用户需求的基本功能（集）聚合起来表示的强大工具。对于正在构造的新系统，用例描述系统应该作什么；对于已构造完毕的系统，用例则反映了系统能够完成什么样的功能。构建用例模型是通过开发者与客户（或最终使用者）共同协商完成的，他们要反复讨论需求的规格说明，达成共识，明确系统的基本功能，为后阶段的工作打下基础。用例模型的基本组成部件是用例、角色和系统。用例用于描述系统的功能，也就是从外部用户的角度观察，系统应支持哪些功能，帮助分析人员理解系统的行为，它是对系统功能的宏观描述。一个完整的系统中通常包含若干个用例，每个用例具体说明应完成的功能，代表系统的所有基本功能（集）。角色是与系统进行交互的外部实体，它可以是系统用户，也可以是其它系统或硬件设备，总之，凡是需要与系统交互的任何东西都可以称作角色。系统的边界线以内的区域（即用例的活动区域）则抽象表示系统能够实现的所有基本功能。在一个基本功能（集）已经实现的系统中，系统运转的大致过程是：外部角色先初始化用例，然后用例执行其所代表的功能，执行完后用例便给角色返回一些值，这个值可以是角色需要的来自系统中的任何东西。在用例模型中，系统仿佛是实现各种用例的“黑盒子”，我们只关心该系统实现了哪些功能，并不关心内部的具体实现细节（比如系统是如何做的？用例是如何实现的？）。用例模型主要应用在工程开发的初期，进行系统需求分析时使用。通过分析描述使开发者在头脑中明确需要开发的系统功能有哪些。用例模型由用例图构成。用例图中显示角色、用例和用例之间的关系。用例图在宏观上给出模型的总体轮廓，而用例的真正实现细节描述则以文本的方式书写。用例图所表示的图形化的用例模型（可视化模型）本身并不能提供用例模型必需的所有信息。也就是说，从可视化的模型只能看出系统应具有哪些功能，每个功能的含义和具体实现步骤必须使用用例图和文本描述（它记录着实现步骤）。在进行定义系统，发现角色和用例、描述用例、定义用例之间的关系，验证最终模型的有效性等工作时，需要建立用例模型。用例模型也就是系统的用例视图。用例视图在建模过程中居于非常重要的位置，影响着系统中其它视图（比如，逻辑和物理架构）的构建和解决方案（满足基本功能需求)的实现,因为它是客户和开发者共同协商反复讨论确定的系统基本功能(集).开发者既可以把用例视图用于构建一个新系统的功能视图，还可以把已有的用例视图修改或扩充后产生新的版本，也就是在现有的视图上加入新功能（即在视图中加入新的角色和用例）。用

例

图用例模型（也就是用例视图）是用例图描述的。用例模型可以由若干个用例图组成。用例图中包含系统、角色和用例等三种模型元素。图示用例图时，既要画出三种模型元素，同时还要画出元素之间的各种关系（通用化、关联、依赖），如图所示：客户保险销售员保险商务系统签定保险单销售统计资料客户数据资料图：用例图示意用

例

图用例内容（即该用例所代表功能的具体实现过程）通常用普通的文字书写。在UML语言中，用例内容被看作用例元素的文档性质。

系统系统是用例模型的一个组成部分，代表的是一部机器或一个商务活动等等，而并不是真正实现的软件系统。系统的边界用来说明构建的用例模型的应用范围。系统最初的规模应有多大也应该考虑。一般的作法是，先识别出系统的基本功能（集），然后以此为基础定义一个稳定的、精确定义的系统架构，以后再不断地扩充系统功能，逐步完善。这样作的好处在于避免了一开始系统太大，需求分析不易明确，从而导致浪费大量的开发时间。用例图中的系统用一个长方框表示，系统的名字写在方框上或方框里面，方框内部还可以包含该系统中的用符号表示的用例。比如，上图中的保险商务系统。表示该系统的方框内还包含了三个用例（签订保险单、销售统计资料、客户数据资料）。角色角色（actor）是与系统交互的人或事。所谓“与系统交互”指的是角色向系统发送消息，从系统中接收消息，或是在系统中交换信息。只要使用用例，与系统互相交流的任何人或事都是角色。比如，某人使用系统中提供的用例，则该人就是角色；与系统进行通信（通过用例）的某种硬件设备也是角色角色是一个群体概念，代表的是一类能使用某个功能的人或事，角色不是指某个个体。角色也可以分成主动角色和被动角色。主动角色可以初始化用例，而被动角色则不行，仅仅参与一个或多个用例，在某个时刻与用例通信。

角色发现角色

通过回答下列的一些问题，可以帮助建模者发现角色。

使用系统主要功能的人是谁（即主要角色）？需要借助于系统完成日常工作的人中谁？谁来维护、管理系统（次要角色）保证系统正常工作？系统控制的硬件设备有哪些？系统需要与哪些其它系统交互？其它系统包括计算机系统，也包括该系统将要使用的计算机中的其它应用软件。其它系统也分成二类，一类是启动该系统的系统，另一类是该系统要使用的系统。对系统产生的结果感兴趣的人或事是哪些？角色UML中的角色

UML中的角色是具有版类《角色》的类，该类的名字用角色的名字命名，用以反映角色的行为。角色类包含有属性、行为和描述角色的文档性质。UML中用一个小人形图形表示角色类，小人的下方书写角色名字，如图所示。图左侧的矩形是具有版类《角色》的类（即角色类）的另一种图示方式，右侧的标准图示图标一般用在用例图中。《角色》保险代理保险代理图：角色类的图示方法示例角色角色之间的关系

由于角色是类，所以它拥有与类相同的关系描述。在用例图中，只用通用化关系描述若干个角色之间的行为。通用化关系的含义是：把某些角色的共同行为（原角色中的部分行为），抽取出来表示成通用行为，且把它们描述成为超类（superclass）。这样，在定义某一具体的角色时，仅仅把具体的角色所特有的那部分行为定义一下就行了，具体角色的通用行为则不必重新定义，只要继承超类中相应的行为即可。角色之间的通用化关系用带空心三角形（作为箭头）的直线表示，箭头端指向超类。

角色电话申请客户类与个人登记客户类的基本行为与客户类一致，这两个类的差别仅仅在于申请的方式不同，于是，在定义这两个类的行为时，基本行为可以从客户类中继承得到（从而不必重复定义），与客户类不同的行为则定义在各自的角色类中。客户个人登记客户电话登记客户图：角色之间的通用化关系用例什么是用例

用例代表的是一个完整的功能。UML中的用例是动作步骤的集合。动作（action）是系统的一次执行（能够给某个角色输出结果值）。与角色通信，或进行计算，或在系统内工作都可以称作动作。用例具有以下的特征

用例总由角色初始化

用例为角色提供值

用例具有完全性不管用例内部的小用例是如何通信工作的，只有最终产生了返回给角色的结果值，才能说用例执行完毕。用例用例和角色之间也有连接关系，用例和角色之间的关系属于关联（association），又称作通信关联（communicationassociation）。这种关联表明哪种角色能与该用例通信。关联关系是双向的一对一关系，即角色可以与用例通信，用例也可以与角色通信。用例的命名方式与角色相似，通常用用例实际执行功能的名字命名，比如：签定保险单、修改注册人等。用例发现用例实际上，从识别角色起，发现用例的过程就已经已开始了。对于已识别的角色，通过询问下列问题就可发现用例：角色需要从系统中获得哪种功能?角色需要做什么？角色需要读取、产生、删除、修改或存储系统中的某种信息吗？系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件（功能）能干些什么？如果用系统的新功能处理角色的日常工作是简单化了，还是提高了工作效率？还有一些与当前角色可能无关的问题，也能帮助建模者发现用例，例如：系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？系统当前的这种实现方法要解决的问题是什么?（也许是用自动系统代替手工操作）

用例UML中的用例

UML中的用例用椭圆形表示，用例的名字写在椭圆的内部或下方。用例位于系统边界的内部。角色与用例之间的关联关系（或通信关联关系）用一条直线表示，如图所示。通信关联用例A用例B用例C系统名称用例名称角色名称图：用例图示例用例下图给出的是某自动售货系统的用例图。供货取货款卖饮料自动售货系统客户供货人收银员自动售货系统用例图用例用例之间的关系

用例之间有扩展、使用、组合三种关系。扩展和使用是继承关系（即通用化关系）的另一种体现形式。组合则是把相关的用例打成包（package），当作一个整体看待。扩展关系

一个用例中加入一些新的动作后则构成了另一个用例，这两个用例之间的关系就是通用化关系，又称扩展关系。后者通过继承前者的一些行为得来，前者通常称为通用化用例。后者常称为扩展用例。扩展用例可以根据需要有选择地继承通用化用例的部分行为。扩展用例也一定具有完全性。扩展用例的好处在于：便于处理通用化用例中不易描述的某些具体情况；便于扩展系统，提高系统性能，减少不必要的重复工作。用例之间的扩展关系可图示为带版类《扩展》的通用化关系，如下图所示。用例签定保险单《扩展》签定汽车购买合同图：扩展关系图示用例使用关系

一个用例使用另一个用例时，这两个用例之间就构成了使用关系。一般情况下，如果若干个用例的某些行为都是相同的，则可以把这些相同的行为提取出来单独作成一个用例，这个用例称为抽象用例。这样，当某个用例使用该抽象用例时，就好象这个用例包含了抽象用例的所有行为。

用例用例之间的使用关系被图示为带版类《使用》的通用化关系，如图所示：签定保险单《使用》《使用》签定汽车保险合同签定汽车保险合同图：使用关系图示用例比如，自动售货系统中，供货和提取销售款这两个用例的开始动作都是去掉机器保险并打开它，最后的动作一定是关闭机器并加保险，于是可以从这两个用例中把开始的动作抽象成“打开机器”用例，把最后的动作抽象成“关闭机器”用例，那么“供货”和“提取销售款”用例在执行时一定要使用上述的两个抽象用例，它们之间便构成了使用关系。使用关系用带版类《使用》的通用化关系表示，如下图所示用例卖饮料打开机器打开机器关闭机器关闭机器供货取货款自动售货系统《使用》《使用》《使用》《使用》收银员供货人客户自动售货系统用例模型描述用例图形化表示的用例本身不能提供该用例所具有的全部信息，因此还必需描述用例不可能反映在图形上的信息。通常用文字描述用例的这些信息。用例的描述其实是一个关于角色与系统如何交互的规格说明，该规格说明要清晰明了，没有二义性。描述用例时，应着重描述系统从外界看来会有什么样的行为，而不管该行为在系统内部是如何具体实现的，即只管外部能力，不管内部细节。描述用例用例的描述应包括下面几个方面用例的目标用例是怎样被启动的角色和用例之间的消息流用例的多种执行方案用例怎样才算完成并把值传给了角色描述用例需要强调的是，描述用例仅仅是为了站在外部用户的角度识别系统能完成什么样的工作，至于系统内部是如何实现该用例的（用什么算法等）则不用考虑，描述用例的文字一定要清楚，前后一致，避免使用复杂的易引起误解的句子，方便用户理解用例和验证用例。用例也可以用活动图描述，即描述角色和用例之间的交互（如下图所示）。活动图中显示各个活动的顺序和导致下一个活动执行的决策（decision）。对用户来说，用例视图更易于使用。

描述用例送出饮料向机器中投钱币检查钱币的数量显示可购买的饮料种类提示想购买的饮料缺货选择想买的饮料【无法送出饮料】购买饮料的顾客【得到饮料】图：活动图示例描述用例对某个用例的描述完成之后，可以用一个具体的活动跟踪一下，检查用例中描述的关系能否被识别。在执行这个活动时，可以通过回答下列问题找出不足之处。用例中的所有角色与该用例都有关联关系吗？若干个角色的通用行为与基类角色（从若干个角色的行为中抽象出的最普通的那部分）的行为是否相似？表示同一个活动流的多个用例之间是否存在相似性，它们是否能用使用关系描述为一个用例。用例扩展关系中描述的特殊情况存在吗？有没有存在无任何通信关联的角色或用例？如果有，那么用例一定存在问题，否则为什么还要这个角色。有没有遗漏与需求的功能相对应的用例？如果有，那么就要新建一个用例。注意，不要把所有的用例建好之后，再去识别用例中的关系是否正确。这种做法有时会导致错误。测试用例用例可用于测试系统的正确性和有效性。正确性表明系统的实现符合规格说明。有效性保证开发的系统是用户真正需要的系统。正确性测试保证系统的工作符合规格说明。常用的测试方法有二种，一种是用具体的用例测试系统的行为，又称“漫游用例”；另一种是用用例描述本身测试，或称定义测试。这两种方法相比，第一种方法更好一些。测试用例第一种测试方法的基本思想是用人模拟系统的行为。大致过程如下：指定一个人扮演具体用例中的角色，另一个人扮演系统。扮演角色的人首先说出角色应传给系统的消息，然后系统接收消息开始执行，在系统执行过程中，扮演系统的人说出他正在做的工作是什么。通过角色模拟，开发者可以从扮演者那里得知用例的不足之处。比如，发现哪些情况漏掉了，哪些动作描述得还不够详细。扮演系统行为的人洞察力越强，用例测试的效果就越好。因此可以让每个人分别多次扮演各个角色或系统，从而为建模者提供更多的信息，减少用例描述的遗漏和含糊不清。当所有的角色都被扮演，且所有的用例都以此方式执行过了，那么对用例模型的测试就算完成了。实现用例用例用来描述系统应能实现的独立功能，实现用例就是在系统内部实现用例中所描述的动作，通过把用例描述的动作转化为对象之间的相互协作，完成用例的实现。UML中实现用例的基本思想是用协作表示用例，而协作又被细化为用若干个图。协作的实现用脚本描述。具体内容是：用例实现为协作协作是实现用例内部依赖关系的解决方案.通过使用类、对象、类（或对象）之间的关系（协作中的关系称为上下文）和它们之间的交互实现需要的功能（协作实现的功能又称交互）。协作的图示符号为椭圆，椭圆内部或下方标识协作的名字。实现用例协作用若干个图表示

表示协作的图有协作图、序列图和活动图。这些图用于表示协作中的类（或对象）与类（或对象）之间的关系和交互。在有些场合，一张协作图就完全能够反映出实际用例的协作画面，而在另一些场合，只有把三种不同的图结合起来，才能反映协作状况。协作的实例脚本脚本是用例的一次具体执行过程，它代表了用例的一种使用方法。当把脚本看作用例的实例时，对角色而言，只需描述脚本的外部行为，也就是能够完成什么样的功能，而忽略完成该角本的具体细节，从而达到帮助用户理解用例含义的目的：当把脚本看作协作的实例时，则要描述脚本的具体实现细节（利用类、操作和它们之间的通信）。实现用例实现用例的主要任务是把用例描述中的各个步骤和动作变换为协作中的类、类的操作和类之间的关系。具体说来，就是把用例中每个步骤所完成的工作交给协作中的类来完成。实质上，每个步骤转换成类的操作，一个类中可以有多个操作。注意，一个类可以用来实现多个用例，也就是，一个类可以集成多种角色。比如，自动售货系统中，负责“供货”和“提取货款”的角色就可以定义为同一个类(当然,从安全角度讲,最好不要定义为同一个类)。实现用例用例和它的实现（即协作）之间的关系可以用精化关系表示（图示为带箭头的点画线）也可以用CASE工具中的不可见的超链实现。使用CASE工具中的超链，能方便地将用例视图转换为协作或脚本。下图表示一个用例的实现，从图中可以看出若干个类加到了协作中。为了实现用例，用例描述中的每个步骤的职责还需转换为类与类之间的协作（用关系和操作描述）。实现用例用例《实现》用例描述：1.角色按下按钮2.用例执行动作3.用例向角色发消息4.……《实现》类AOper1()Oper2()Oper3()协作《实现》《实现》类B类COper1()Oper2()Oper3()Oper1()Oper2()Oper3()图：协作实现的类示例实现用例若想成功地利用类表示用例描述，需要借助开发者的经验。通常，开发者必须反反复复地多次试验各种不同的可能情况，逐步完善解决方案，使该方案能够实现用例描述且灵活易扩展。如果将来用例描述改变了，只要将其对应的实现作简单地修改即可最后一点需要说明的是，并不是所有面向对象的方法都提供用例图。比如，有的方法只提供类和对象等静态结构，忽略系统开发过程中功能性和动态性方面的描述。小结用例模型是描述系统基本功能的工具。用例模型用角色、用例和系统描述。角色代表外部实体，比如用户、硬件或另一个与系统交互的外部系统。角色启动用例并与其通信，执行中的用例是一个动作序列。用例一定要给角色传递一个确切的（tangible)值。用例的具体执行过程用文本文件描述。角色和用例都是类，角色通过关联与一个或多个用例相连接，角色和用例都有通用化关系，这样超类中的通用行为可以被一个或多个专门化的子类继承。用例模型（即用例视图）由一个或多个UML用例图描述。小结用例图用协作实现。协作描述了类（或对象）、类与类之间的关系和交互（显示类之间怎样交互才能实现一个具体的功能）。协作用活动图、协作图和交互图描述。实现用例时，用例中的每个动作的责任交给协作中的类完成。通常是由类中的操作完成的。脚本是用例或协作的实例，用于显示一次具体的执行过程。当把脚本看作用例的例子时，脚本仅仅描述用例和外部角色之间的交互，不涉及交互的具体实现细节；当把脚本看作协作的实例时，则实现系统内部类（或对象）之间的交互，即实现具体的实现细节。静态建模类图和对象图

用面向对象的方法处理实际问题时，需要建立面向对象的模型。构成面向对象模型的基本元素有类（class）、对象（objects）、类与类之间的关系等等。用面向对象的思想描述问题，能够把复杂的系统简单化、直观化。而且易于用面向对象语言编程实现，还方便日后对系统的维护工作。本章主要讨论类、类图、对象、对象图、类与类之间的关系等概念。类和对象举例：捷达是小汽车中的一种车型，捷达与小汽车的关系我们可以抽象为对象与类的关系，即作为小汽车类产品，它应提供的功能至少有：启动、行驶、制动，对汽车的车身长度、汽缸容量等也有一定的要求。在符合小汽车类应有的功能和特征的前提下，具体生产出来的车型（比如，夏利，丰田等）则是该类的对象。其实，自然界中存在的事物大都具有类与对象的关系，于是，我们可以借用自然界中的类与对象的表示方法，在计算机的软件系统中实现类与对象，从而达到利用对象在计算机系统中表示事务、处理事务的目的。类和对象对象就是可以控制和操作的实体，它可以是一个设备，一个组织或一个商务。类是对象的抽象描述，它包括属性的描述和行为的描述二方面。属性描述类的基本特征（比如，车身的长度、颜色等）；行为描述类具有的功能（比如，汽车有启动、行驶、制动等功能），也就是对该类的对象可以进行哪些操作。就像程序设计语言中整型变量是整数类型的具体化，用户可以对整型变量进行操作（并不是对整数类型操作）一样，对象是类的实例化，所有的操作都是针对对象进行的。类和对象在计算机系统中，我们用类表示系统，并把现实世界中我们能够识别的对象分类表示，这种处理方式称作面向对象。由于面向对象的思想与现实世界中的事物的表示方式相似，所以采用面向对象的思想建造模型会给建模者带来很多好处。类和对象构建面向对象模型的基础是类、对象和它们之间的关系。在不同的系统中描述的类可以各种各样。比如，在某个商务信息系统中，可以包含的类有：顾客、协议书、发票、债务、资产、报价单；在工程技术系统中，常常会用到一些设备，该系统中则可以有这些类：传感器、显示器、I/O卡、发动机、按钮、控制类；在类似操作系统的软件系统中，类用来表示软件中的实体，可能有的类是：文件、执行程序、设备、图标、窗口、滚动条等。类图类图是用类和它们之间的关系描述系统的一种图示，是从静态角度表示系统的，因此类图属于一种静态模型。类图是构建其它图的基础，没有类图，就没有状态图、协作图等其它图。也就无法表示系统的其它各个方面。类图类图中允许出现的模型元素只有类和它之间的关系。类用长方形表示。长方形分成上、中、下三个区域。每个区域用不同的名字标识。用以代表类的各个特征。上面的区域内用黑体字标识类的名字，中间的区域内标识类的属性，下面的区域内标识类的操作方法（即行为），这三部分作为一个整体描述某个类，如下图所示。类的名字属性操作图：类的图示类图定义类在进行构造类图描述系统的工作时，首先要定义类，也就是将系统要处理的数据抽象成类的属性，将处理数据的方法抽象为操作。下面列出一些可以帮助建模者定义类的问题

有没有一定要存储或分析的信息？如果存在需要存储，分析或处理的信息，那么该信息有可能就是一个类。这里讲的信息可以是概念（该概念总在系统中出现）或事件或事务（它发生在某一时刻）。

类图有没有外部系统？如果有，外部系统可以看作类，该类可以是本系统所包含的类，也可以是本系统与之交互的类。有没有模版、类库、组件等？如果手头上有这些东西，它们通常应作为类。模版、类库、组件可以来自原来的工程、或别人赠送或从厂家购买的。系统中有被控制的设备吗？凡是与系统相连的任何设备都要有对应的类。通过这些类控制设备。类图有无需要表示的组织机构？在计算机系统中表示组织机构通常用类，特别是构建商务模型时用得更多。系统中有哪些角色？这些角色也可以看成类。比如：用户、系统操作员、客户等。类图名字、属性和操作名字

类的名字用黑体字书写在长方形的最上面，给类命名时最好能够反映类所代表的问题域中的概念。属性类的属性放在类名字的下方，用来描述该类的对象所具有的特征。类图属性有不同的可见性（visibility）。利用可见性可以控制外部事物对类中属性的操作方式。属性的可见性通常分为三种：公有的（public）、私有的（private）、和保护的（protected）。小汽车小汽车注册号日期速度方向注册号：String日期：Cardata速度：Integer方向：Direction图：类的名字和属性示例图：属性的类型示例类图在类图中，公有类型表示为加号（+），私有类型表示为减号（−），它们标识在属性名称的左侧，如果属性名称旁没有标识任何符号，表示该属性的可见性尚未定义。如左图所示。类属性的缺省值可以表示在类图中，如右图所示。这样，当创建该类的对象时，该对象的属性值便自动被赋以图示中的缺省值。

发货单发货单＋总计：Real＋日期：Data＋客户：String＋规格说明：String－管理员：String＋总计：Real＋日期：Data=当天日期＋客户：String＋规格说明：String－管理员：String=“未定”图：属性的可见性示例图：带有属性缺省值的类类图类的属性中还可以有一种能被该类的所有对象共享的属性，称之为类的作用域属性（class-scopeattribute），也称作类变量（classvariable）。类变量在类图中表示为带下划线的形式，如下图所示。图中“货单个数”属性用来统计总的货单数，在该类的所有对象中，这个属性的值是一致的。描述属性的语法格式为： 可见性属性名：类型名=初值{性质串}发货单＋总计：Real＋日期：Data=当天日期＋客户：String＋规格说明：String－管理员：String=“未定”－货单个数：Integer图：带有类作用域属性的类发货单＋总计：Real＋日期：Data=当天日期＋客户：String＋规格说明：String－管理员：String=“未定”－货单个数：Integer＋状态：Status＝unpaid{unpaid,paid}图：性质串示例类图其中属性名和类型名是一定要有的，其它部分可根据需要可有可无。花括号括起来的性质串，列出该属性所有可能的取值。枚举类型的属性经常使用性质串，性质串中的每个枚举值之间用逗号分隔。如图所示。当然性质串也可以用来说明该属性的其它信息，比如属性的持久性（persistent）。类图类可以使用面向对象语言的类结构描述实现，下面以JAVA语言为例，描述上图中类的实现代码：

publicclassinvoice{publicdoubleamount;publicDatedata=newDate();publicstringcustomer;publicstringspecification;publicstringadministrator=”unspecified”;staticprivateintnumber_of_invoices=0;publicinvoice()//构造函数{//部分初始化工作可在此进行number_of_invoices++;}//类的其它操作方法写在这里

}类图操作属性仅仅表示了需要处理的数据，对数据的具体处理方法的描述则放在操作部分。存取或改变属性值或执行某个动作都是操作，操作说明了该类能做些什么工作。操作通常又称为函数，它是类的一个组成部分，只能作用于该类的对象上。从这一点也可以看出，类将数据和对数据进行处理的函数封装起来，形成一个完整的整体，这种机制非常符合问题本身的特性。在类图中，操作部分位于长方形的最底部，一个类可以有多种操作，每种操作由操作名、参数表、返回值类型等几部分构成，标准语法格式为：可见性操作名（参数表）：返回值类型{性质串}类图其中可见性和操作名是不可缺少的。操作名、参数表和返回值类型合在一起称为操作的标记（signature）,操作标记描述了使用该操作的方式，操作标记必须是唯一的。注意，操作只能应用于该类的对象，比如，drive()只能作用于小汽车类的对象，如下图所示。小汽车＋注册号：String－日期：Cardata＋速度：Integer＋方向：Direction＋drive(speed:Integer,direction:Direction)＋getData():Cardata图：带有属性和操作的类类图操作的可见性也分为公有（用加号表示）和私有（用减号表示）两种，其含义等同于属性的公有和私有可见性。参数表由多个参数（用逗号分开）构成，参数的语法格式为：参数名参数类型名=缺省值其中省缺值的含义是，如果调用该操作时没有为操作中的参数提供实在参数，那么系统就自动将参数定义式中的缺省值赋给该参数。比如，下图描述了一个图画类，假设figure是图画类的对象，当执行figure.resize(10,10)时，由于给定了实在参数(10,10)所以 percentX=10,percentY=10;类图若执行figure.resize(37)，由于只给定了一个实在参数，按照参数位置。顺序一一对应的原则，percentX的值被赋与了37，而percentY没有对应的实在参数，故赋以省缺值25，最后结果为：percentX=37，percentY=25；若执行figure.resize（）；由于两个参数都没给出实在参数，所以它们分别获得缺省值15和25，最后结果为： percentX=15，percentY=25；类图图画大小：Size位置：Position+draw()+resize(percentX:Integer=15,percentY:Integer=25)+returnPos():Position图：参数的缺省值示例类图类也有类作用域操作，图示为带下划线的形式，如下图所示。引入类作用域操作的好处在于只有本类的对象才能使用该操作，一些通用的操作可以设计为类作用域操作，比如：产生对象和发现对象。需要注意的是，类作用域操作只能存取本类中的类作用域属性。图画大小：Size位置：Position图片个数：IntegerDraw()getCounter():Integer图：带有类作用域操作的类类图有一种特别的类，叫做持久类（persistentclass）。如下图所示的类就是一个持久类。当产生对象的程序draw运行结束时，所需的对象便生成了，同时生成的对象将自身存入数据库、文件或其它永久性的存储器中。通常该类还会有一个类作用域操作，用此操作完成对象的存储，通常这种操作表示为STORE()、LOAD()或CREATE()等。在类图中，如果某个类需要定义为持久的类，那么需要在类的名字旁边附加上{persistent}标志，如图所示。图画{persistent}-x:Integer=0-y:Integer=0+draw()图：持久的类示例类图上图的JAVA实现代码为

publicclassFigure{privateintx=0;privateinty=0;publicvoiddraw(){//实现画图的JAVA代码}}；产生图画对象的代码和调用draw操作的代码为：Figurefig1=newFigure();Figurefig2=newFigure();fig1.draw();fig2.draw();

关系类图由类和它们之间的关系组成。类与类之间通常有

关联、

通用化（继承）、

依赖和

精化等四种关系关联关系关联用于描述类与类之间的连接。由于对象是类的实例，因此，类与类之间的关联也就是其对象之间的关联。类与类之间有多种连接方式，每种连接的含义各不相同（语义上的连接）但外部表示形式相似，故统称为关联。关联关系一般都是双向的，即关联的对象双方彼此都能与对方通信。根据不同的含义，关联可分为普通关联、递归关联，限定关联、或关联、有序关联、三元关联和聚合等七种。普通关联普通关联是最常见的一种关联，只要类与类之间存在连接关系就可以用普通关联表示。比如，张三使用计算机，计算机会将处理结果等信息返回给张三那么，在其各自所对应的类之间就存在普通关联关系。普通关联的图示是连接二个类之间的直线，如图所示作家使用计算机图：普通关联示例普通关联由于关联是双向的，可以在关联的一个方向上为关联起一个名字，而在另一个方向上起另一个名字（也可不起名字），名字通常紧挨着直线书写。为了避免混淆，在名字的前面或后面带一个表示关联方向的黑三角，黑三角的尖角指明这个关联只能用在尖角所指的类上。通过直观的图示就可以很清楚地表达这种关联，比如，上图的意思就是“某位作家使用计算机”。就像给类起的名字应能代表问题域本身的含义一样，给关联起的名字最好使用能够反映类之间关系的动词。导航关联如果类与类之间的关联是单向的，则称为导航关联导航关联采用实线箭头连接两个类。只有箭头所指的方向上才有这种关联关系，如图所示，图中只表示某人可以拥有汽车，但汽车被人拥有的情况没有表示出来。拥有0..*

人小汽车图：导航关联示例重数除了上述的图示方式外，还可以在类图中图示关联中的数量关系——重数，比如，一个人可以拥有零辆车或多辆车。表示数量关系时，用重数说明数量或数量范围，也就是说，有多少个对象能被连接起来 例： 0..1表示

零到1个对象

0..*或*表示

零到多个对象

5..17表示5到17个对象

2表示2个对象

重数如果图中没有明确标识关联的重数，那就意味着是1。类图中，重数标识在表示关联关系的某一方向上直线的末端。下图中关联的含义是：人可以拥有零到多辆车，车可以被1至多个人拥有。而上图则只说明人可以拥有零至多辆车。类图简单直观地描述了类、对象及它们之间的关系。通过类图可以反映出哪些对象之间有关系，系统是如何运作的。1..*拥有

0..*被拥有

人小汽车图：关联的重数示例类图类图虽小，但包含了很多信息。下面我们以下图为例，用自然语言表述该图的含义。保险公司有0或多个保险合同，这些合同与1个或多个客户有关；客户有0或多个保险合同，这些合同都与1个保险公司有关；保险合同位于一家保险公司和一个或多个客户之间，用它建立保险公司和客户之间的保险关系；保险合同用0或1个保险单表示，也就是合同的书面表示；一个保险单表示一份保险合同。类图1有0..*涉及表达表示为0..11有0..*1..*涉及保险公司保险单保险合同客户图：保险业务的类图类图

在描述的保险业务类图中，保险合同用0或1个保险单表示，也就是保险合同可能有书面的保险单，可能没有书面的保险单。假如，某个客户打电话给某个保险公司请求保险他的汽车，若保险公司接受了他的请求，那么他与保险公司之间就有了保险合同，但是书面的保险单并不能马上得到，只能邮寄（或送达）。如果把这种模型当作真正的商务活动的描述，该模型是否可行呢？类图比如某人打电话请求保险他的汽车，这时他与保险公司之间就有了口头上的承诺。一分钟之后他的汽车撞坏了，这时，他并没有保险单。如果保险业务以保险单为依据进行索赔，显然这种特殊情况发生时，该模型无法解决。从这个例子可以看出建造一个真实业务的模型时，该模型一定要能够反映实际情况，而不能看起来“差不多”。一种解决上述问题的方法是开展网上业务，客户可以上网登记，获取另一种形式的保险单。对于建模者来说，只需在原来的类图上增加一个新的类——网上保险单用该类完善系统的行为。从这个示例本身也可以看出，面向对象的建模方法，非常适合发展变化的问题，当需求发生变化时，只要修改或扩充一下原来的模型即可，并不需要推翻原始方案重新来，这也意味着原始的实现代码不必重新编写，只要相应地修改一下即可。关联利用程序设计语言实现关联并不困难，比如，下图的JAVA实现大致为

publicclassInsurance_company { /*方法*/ privateInsurance_contractVectorcontracts; //Insurance_contractVector是一个向量类的具体化

//Vector是为动态数组提供的标准的类

} publicclassInsurance_contract { /*方法*/ privateInsurance_companyrefer_to; }

1有0..*保险公司保险合同涉及双向关联对于多对多的双向关联，可以转化为两个一对多的关联来实现，如图所示

转化为***11*ABACB图：双向多对多关联的转化示例对象图类图表示类和类与类之间的关系，对象图则表示在某一时刻这些类的具体实例和这些实例之间的具体连接关系。由于对象是类的实例，所以，UML对象图中的概念与类图中的概念完全一致，对象图可以看作类图的示例，帮助人们理解一个比较复杂的类图，对象图也可用于显示类图中的对象在某一点的连接关系。

对象图对象的图示方式与类的图示方式几乎是一样的。主要差别在于对象的名字下面要加下划线。 对象名有下列三种表示格式。

第一种格式形如：

对象名：类名 即对象名在前，类名在后，中间用冒号连接。 第二种格式形如： ：类名

这种格式用于尚未给对象命名的情况，注意，类名前的冒号不能省略。 第三种格式形如：

对象名 这种格式不带类名，即省略类名。对象图下图给出一个类图和一个对象图，其中对象图是类图的示例，比较一下两者之间有何异同。作家计算机姓名：String年龄：integer名称：string内存：integer使用0..*1..*(a)类图丁一：作家姓名＝丁一年龄＝30丁一办公室中的PC：计算机名称＝Dell466内存＝64丁一家里的PC：计算机名称＝长城PIIMMX内存＝64(b)对象图类图类图虽小，但包含了很多信息。下面我们以下图为例，用自然语言表述该图的含义。保险公司有0或多个保险合同，这些合同与1个或多个客户有关；客户有0或多个保险合同，这些合同都与1个保险公司有关；保险合同位于一家保险公司和一个或多个客户之间，用它建立保险公司和客户之间的保险关系；保险合同用0或1个保险单表示，也就是合同的书面表示；一个保险单表