面向对象分析与设计 课件 第2章 统一建模语言概述

第2章统一建模语言概述学习目标

理解和掌握统一建模语言的基本概念

理解和掌握UML模型的基本结构

理解和掌握UML中的元素、关系、图和通用机制的概念和表示法

理解和掌握对象约束语言概念的使用方法第1章面向对象开发方法本章的主要内容：面向对象方法的基本概念，及其内涵与外延。软件开发方法的发展过程和典型的面向对象开发方法。概括性地介绍面向对象的软件开发过程，如面向对象分析和面向对象设计等。第2章统一建模语言概述任何行业都有其特定的表示法，用来表示这个行业中的人们创造出的各种制品。在面向对象方法中，人们通常使用统一建模语言作为标准的表示法，应用统一建模语言建模贯穿了软件开发的全过程。可以说，面向对象的系统分析与设计过程实质上也就是应用统一建模语言对软件进行建模的过程。第2章统一建模语言概述90年代中期，Booch、Rumhaugh和Jacobson等人将他们各自的研究成果融合，创建出第一个版本的统一建模语言（UML，UnifiedModelingLanguage）。1997年11月，OMG把UML宣布为标准的面向对象建模语言。从此，OMG承担了UML的组织管理和继续开发的责任。随后的数年中，UML曾连续发布过多种不同的版本。目前的最新版本为UML2.5。本教材将主要使用UML2.0作为模型语言，并详细介绍其使用方法。第2章统一建模语言概述对于软件模型的构建者和使用者来说，他们当然期望能够以较高的保真度来建模要构建的软件系统，但任何一种语言都不可能仅在一张图纸上就能绘制出一个复杂软件系统的所有细节。本章将概要介绍统一建模语言的基本概念、结构和主要构成要件，具体的建模方法和建模细节将在后续章节中陆续介绍。2.1UML的基本概念2.1.1UML的定义建模是大型软件项目中必不可少的组成部分，即使是对中小型项目也很有帮助。图纸和其它各种计划（如站点地图、海拔高度和物理模型等）在摩天大楼的建造中起着十分重要的作用，模型在软件开发中也起着类似的作用。对于软件项目来说，软件模型可以保证项目业务功能的正确和完整，并使最终用户的需求得到满足。不仅如此，软件模型甚至还可以支持人们通常所要求的诸如软件的可扩展性、可靠性、安全性和可维护性等方面的质量属性。2.1UML的基本概念2.1.1UML的定义有调查表明，大型软件项目有很大的失败概率。事实上，大型软件应用程序更可能在预算和时间上无法满足所有要求。运作这样的软件项目时，人们当然需要尽可能增加项目成功的几率，而在大量的项目编码工作开始之前，建模是能够可视化设计和检查需求的惟一方法。2.1UML的基本概念2.1.1UML的定义对于统一建模语言，OMG规范给出了如下的定义。统一建模语言（UML）是一种用于说明、构造和记录软件密集型系统中人工制品（artifacts）的图形语言。UML提供了一种编写系统蓝图（blueprints）的标准方式，它既能描述软件开发过程中的业务流程、用例和系统功能等概念性的事物，也能够描述像程序语句、数据库模式和软件组件等具体的事物。2.1UML的基本概念2.1.1UML的定义重要的是，OMG将UML定义成一种语言，而不是一种方法或一个过程。其主要用途是定义软件系统、详细描述系统中的工件以及记录文档和构造软件系统蓝图。而UML就是用于实现这些用途或书写这个蓝图的建模语言。UML可以用多种方式支持不同的软件开发方法学（如Rational统一过程），但它本身并不指定具体的方法学或过程。2.1UML的基本概念2.1.1UML的定义UML为软件开发的不同领域或不同过程定义了不尽相同的符号和语义。以支持软件开发的不同领域的建模。这些领域模型包括：用例模型、交互模型、动态模型、逻辑模型、构件模型和物理部署模型等。2.1UML的基本概念2.1.1UML的定义1）用例模型（UseCaseModel）用例模型也称为用户交互模型，该模型描述了系统的参与者与系统之间的交互，当然也描述里系统的边界。这种模型也对应了需求模型的某些方面。2）交互模型（InteractionModal）交互模型也称为通讯模型，主要用于描述系统中的对象之间的交互，以及如何通过对象之间的交互以完成特定的系统工作或任务。2.1UML的基本概念2.1.1UML的定义3）动态模型（DynamicModel）动态模型的内容则主要包括两个方面，一方面，使用状态图描述系统对象在某个时间段内的状态及其变化；另一方面，使用活动图描述系统需要完成的工作流。4）逻辑模型（LogicalModel）逻辑模型也称为类模型（ClassModel），主要用于描述构成系统所需要的类以及这些类之间隔关系，这个模型描述的是系统的逻辑结构。2.1UML的基本概念2.1.1UML的定义5）构件模型（ComponentModel）构件模型主要用于描述构成系统所需要的软件构件及其相互关系，它所表示的是软件系统的物理结构。6）物理部署模型（DeploymentModel）部署模型用于描述系统的物理架构（physicalarchitecture）和构件在硬件架构上的部署情况，它所表示的是整个系统的物理结构。2.1.2UML的主要特点UML具有如下几个方面的特点。1）提高抽象层次UML使开发人员可以在更高的抽象层次上进行工作，从而为他们提供帮助。一个模型可以通过隐藏或掩盖细节、展现大图、或者聚焦于原型的不同方面来实现这一点。使用UML，可以将应用程序的详细视图缩小到它执行的环境中，可视化到其它应用程序的连接，或者进一步扩展到其它站点。或者可以使人们关注应用程序的不同侧面，如它自动化的业务流程或业务规则视图等。2.1.2UML的主要特点使用UML可以建模任何类型的应用软件，包括运行在任何类型硬件及其组合上的、运行在不同操作系统环境下的、使用不同程序设计语言实现的和运行在各种网络环境下的应用软件。UML的灵活性使您可以建模使用任何中间件的分布式应用程序。由于UML是基本的面向对象的概念基础之上的模型语言，它当然适用于面向对象的程序设计语言，如C++、Java以及C#等。但它也可以用来建模非面向对象的应用程序。如FORTRAN、VB或COBOL等。UML中的概要文件（profile，即针对特定目的而定制的UML子集）可以帮助你以自然的方式建模具有事务性、实时性和容错性系统。2.1.2UML的主要特点2）使用UML做其它有用的事情使用UML也可以做一些软件建模以外的事情，如分析源代码，将它反向转换成一组UML类图。又如，市场上的某些工具也可以运行UML模型，这些工具可以分成模型分析器和代码生成器两类。模型分析器用于分析UML模型，以帮助用于确认模型中不满足性能需求的部分。代码生成器的目标则是从UML模型生成程序语言代码，生成无错误、运行速度快并且可部署的应用程序。例如，事务数据库操作或其它常见的编程任务等。（OMG成员正在研究可执行UML的规范）。2.1.2UML的主要特点3）UML和OMG的模型驱动体系结构凭借中间件的独立性，UML形成了OMG的模型驱动体系结构包（MDA，ModelDrivenArchitecture）的基础。这使得UML模型可以是平台独立（PIM，Platform-independent）的也可以是平台相关的（PSM，Platform-specfic）的，MDA开发过程支持两种模型的使用。凭借中间件的独立性，UML形成了OMG的模型驱动体系结构包（MDA，ModelDrivenArchitecture）的基础。这使得UML模型可以是平台独立（PIM，Platform-independent）的也可以是平台相关的（PSM，Platform-specfic）的，MDA开发过程支持两种模型的使用。2.1.2UML的主要特点3）UML和OMG的模型驱动体系结构标准情况下，每个MDA标准或应用均是基于平台独立模型（PIM）的，这意味着其业务功能和行为可以非常精确但不包括技术方面。从平台独立模型（PIM），MDA开发工具遵循OMG规范启用映射来产生一个或多个平台相关模型（PSM）。这个转换步骤是高度自动化的，在工具生成平台相关模型（PSM）之前，开发人员必须对基本的平台独立模型（PIM）进行注释，以生成一个更具体但仍与平台无关的模型，其中包含所需语义的详细信息，并指导工具不得不做出的选择。由于特定类型的中间件平台之间的相似性，例如对于基于组件的或基于消息的中间件平台，这种指导可以被包含在平台独立的模型（PIM）中而不提供特定于平台的特性。进一步，开发人员将不得不在一定程度上调整（fine-tune）产生的平台相关模型（PSM），这样的调整对与早期的MDA较多，但随着工具和算法的进步则变得越来越少了。2.1.2UML的主要特点3）UML和OMG的模型驱动体系结构平台相关模型（PSM）虽然包含了与实现相关的信息，但UML模型并不能代替运行代码。在下一步中，工具可以从平台相关模型（PSM）生成可运行的代码及其它必要的文件（包括必要的接口定义文件、配置文件、生成文件和其它类型的文件）。在给开发人员一次手工调整代码的机会之后，该工具可以执行makefile生成和部署最终应用。2.1.2UML的主要特点3）UML和OMG的模型驱动体系结构MDA应用也是可以组合的，如果向开发工具中引进平台独立模型（PIM）、服务、或其它MDA应用，则可以使用任何必要的接口和协议直接调用，即使跨平台运行。并且，MDA应用程序的未来可以证明：当一个新的产品上市时，OMG成员将生成并标准化它的映射，并且供应商将升级其MDA工具以包含它。利用这些发展的优势，你将能够产生对新平台的跨平台调用，甚至将现有的MDA应用连接到这个新的平台，从而自动使用现有的资源。2.1.3如何使用UMLUML通常被作为软件开发过程的一个组成部分。在软件开发过程中，可以使用适当的CASE工具来定义目标系统中的需求、交互和各种元素。下面，我们给出一个比较常见的开发过程。1）建模系统的业务流程业务流程模型可用于定义业务系统中发生的高层次的业务活动和流程，并为用例模型提供基础。通常情况下，业务流程模型捕获的内容往往多于目标软件系统将要实现的内容，例如业务流程模型中可能会包括人手工的处理或其它的处理等。业务建模可以有效地确定和控制系统的目标和范围，从而避免需求不足或过分的情况发生。2.1.3如何使用UML2）建立用例模型，并明确用例模型到业务模型之间的链接建立用例模型可以确切地定义系统应提供的功能，还需要进一步明确这些功能所实现的业务需求。当添加一个用例时，都要创建一个从适当的业务流程到这个用例的可追溯的链接。这个链接可清楚地说明新系统提供的功能满足了业务流程模型中描述的哪一项业务需求。它还可以确保用例模型中的每一个用例都是符合明确的业务需求。2.1.3如何使用UML3）细化用例——包括每个用例的需求、约束、复杂度、注释和场景用例细化准确地描述了用例的作用、执行方式以及执行时需要遵守的约束。确保用例能够满足业务流程需求。包括定义每个用例的系统测试以及每个用例的合格标准。还包括定义一些用户验收测试脚本，还要定义用户将如何测试这个功能及其验收标准。2.1.3如何使用UML4）构建系统的业务对象模型、顺序图、通讯图和用户界面等模型从业务流程模型的输入和输出以及用例的细节出发，开始构建系统的领域模型（即高层业务对象模型）、顺序图、通讯图和用户界面模型。这些模型描述了新系统中的构成元素、这些元素交互的方式以及用户执行用例场景所使用的接口。2.1.3如何使用UML5）从领域模型、用户界面模型和场景图（Scenariosdiagram）创建系统的类模型类模型是系统中对象以及对象的行为和属性的精确描述（specification）。建模时，可以使用继承和聚合将模型中的类抽象为类（或对象）的层次结构，将场景图中的消息映射到类中的操作。对于每个类，还可以定义单元测试和集成测试以测试类的功能以及类与其相关类和组件的之间的交互。2.1.3如何使用UML6）构件模型建模随着建模过程的继续，类模型还有可能被分解成一些离散的包和组件。组件表示一个可部署的软件块，它收集一个或多个类的行为和数据，并向其服务的其它用户公开严格的接口。因此，建立组件模型可以定义类的逻辑包装。还可以为每个组件定义集成测试可以确定组件的接口是否满足规范或与其它软件元素的关系了。2.1.3如何使用UML7）记录额外需求与开发过程同步，额外的系统需求也应该被捕获并记录下来。例如，系统的非功能需求、性能要求、安全性要求、职责、发布计划等。在模型中收集这些信息，并随着模型的成熟而不断更新。2.1.3如何使用UML8）建立部署模型部署模型定义了系统的物理体系结构。这项工作可以提前开始，捕捉物理部署的特点是硬件、操作系统、网络功能、接口和支持软件将构成新的系统，它将部署和所使用的参数的可靠性、灾难恢复、备份与支持。随着模型的开发，物理架构将被更新，以反映实际系统正在被提议。2.1.3如何使用UML9）将模型的离散部分分配给一个或多个开发人员，以构建整个系统在用例驱动的开发方法中，这意味着向开发团队分配用例，让他们构建用于执行该用例所需的边界对象、业务逻辑对象、数据库表和相关组件。当每个用例被构建完成之后，应该伴随完成的内容应包括构成单元、集成测试和系统测试。组件驱动的开发可以得到的是分配给开发团队的离散软件组件。2.1.3如何使用UML10）跟踪测试中出现的缺陷如系统测试缺陷所针对的模型元素通常是对应的用例，单元测试缺陷针对的模型元素可能是类等。跟踪相关模型元素的任何变更以便管理项目中可能出现的“范围蠕变”。11）随着工作进展不断更新和完善模型开发过程中，不断评估变更和模型改进对后续工作的影响。使用迭代方法完成在离散块中进行的设计，总是评估当前的构建、下一步的需求和在开发过程的任何发现。12）提交经过测试的软件，生成产品环境对于分阶段交付的项目来说，提交可能会多次进行。2.1.3如何使用UML10）跟踪测试中出现的缺陷如系统测试缺陷所针对的模型元素通常是对应的用例，单元测试缺陷针对的模型元素可能是类等。跟踪相关模型元素的任何变更以便管理项目中可能出现的“范围蠕变”。11）随着工作进展不断更新和完善模型开发过程中，不断评估变更和模型改进对后续工作的影响。使用迭代方法完成在离散块中进行的设计，总是评估当前的构建、下一步的需求和在开发过程的任何发现。2.1.3如何使用UML12）提交经过测试的软件，生成产品环境对于分阶段交付的项目来说，提交可能会多次进行。上述过程只是一个概括性的过程，实际的开发过程可能会有所不同，但这个描述仅仅说明一个应用UML开发软件的基本过程。2.2UML模型的基本结构作为一种模型语言，UML主要由三种基本要素构成，它们分别是UML基本构造块、构造块的组织规则和运用于整个语言的公用机制。2.2.1UML基本构造块1.设施（Infrastructure）设施是对UML模型中最具有代表性的语法成分的抽象，UML定义了结构、行为、分组和注释（Note）等四种设施。结构设施通常包括类（Class）、接口（Interface）、协作（Collaboration）、用例（UseCase）、主动类（ActiveClass）、组件（Component）和结点（Node）等；行为设施则包括交互（Interaction）和状态机（Statemachine）等分组设施用于对模型元素分组，UML主要是用包(package)来实现分组机制。注释设施用于为模型提供一个基于文本的注释（注解，Note）。2.2.1UML基本构造块2.关系（Relationship）这里的关系主要指模型中各种设施之间的关系，用于将设施结合在一起，以组成更高一层的设施。UML主要定义了四种关系依赖（dependency）关联（association）泛化（generalization）实现（implementation）2.2.1UML基本构造块3.图（Diagram）图（Diagram）可以看成是模型中某些模型元素及其相互关系的图形表示，每一张图都是由以表示模型元素的图形符号为结点，图形元素之间的连接关系为边构成的图。2.2.2构造块的组织规则一个完整的UML模型通常由一组模型元素组成的，模型中的所有元素通过视图(View)和包（package）的形式构成了一个具有层次结构的元素集合。一个UML模型首先被分解成若干个视图，每个视图还可以分解成若干个包组成的嵌套结构，这些包也可以进一步分解成若干个包。每个包都可以由若干个模型元素构成。2.2.2构造块的组织规则视图(View)用于描述目标系统在某一方面的特征，是在某种抽象层次或侧面上对系统的抽象表示。每张图（diagram）都需要存放在某个特定的包中。图与视图之间存在着某种对应关系。某些图一般只存放在特定的视图中。模型元素(ModelElement)是对对象模型类、对象、消息和关系等概念模型语言描述，是构成模型的基本要素。它既是构成模型的实体要素，也是目标系统中某个程序实体的模型表示。2.2.3通用机制通用机制(GeneralMechanism)用于表示模型元素相关的信息或附加信息，如元素规约（specifaction）、构造型（stereotype）、修饰符(modifier)、约束（constraint）和注释（Note）等。其中，UML提供的构造型（stereotype）等扩展机制，使UML语言能够有效地适应特殊的方法（或过程），或扩充至一个组织或用户。2.2.3通用机制通用机制(GeneralMechanism)用于表示模型元素相关的信息或附加信息，如元素规约（specifaction）、构造型（stereotype）、修饰符(modifier)、约束（constraint）和注释（Note）等。其中，UML提供的构造型（stereotype）等扩展机制，使UML语言能够有效地适应特殊的方法（或过程），或扩充至一个组织或用户。图2-1UML模型的基本结构2.2.4视图为了简明、准确、清晰地表达一个完整的软件模型，UML定义了多种不同的模型或视图，以便使建模人员可以从不同的视角对软件进行建模。为了描述软件开发过程中使用的各种领域模型，UML中定义了五种基本视图来描述一个完整的软件系统结构。这些视图包括用例视图（UseCaseView）、逻辑视图（LogicalView）、动态视图（DynamicView）、构件视图（ComponentView）和部署视图（DeploymentView）等五种基本视图。2.2.4视图另外，UML还定义了业务过程模型（TheBusinessProcessModel）、需求模型（RequirementModel）和测试模型（TestingModel）等其它多种不同用途的软件模型。其中，五种基本视图具有重要的核心作用，它将其它各种视图有机地连接到一起，共同构成完整的软件模型。图中的五个视图并不直接对应于一个特定的软件模型的逻辑结构，也不直接对应于软件的物理结构，其划分的意义在于每个视图对应的是一种特定的研究系统的观点。不同的视图突出的是特定的人员所关注的系统的不同方面，通过合并所有五个视图中得到的信息就可以形成系统的完整描述。当然，对于某些特殊的领域或过程，可能只考虑某一个视图或某几个视图中包含的信息可能就足够了。2.2.4视图1.用例视图(Usecaseview)用例视图主要用于定义系统的外部行为，是最终用户、分析人员和测试人员所关心的视图。用例视图的主要内容包括参与者、用例以及它们之间的关系。其具体内容还可以包括从用例导出的类、为描述用例或场景所建立的活动图、通讯图和状态图等。总之，用例视图描述了系统的用户需求，因此也约束了描述系统设计和构造的所有其它视图。因此，在用例驱动的开发方法中，用例视图在UML占据了模型中最重要中心位置。2.2.4视图2.逻辑视图(Logicalview)逻辑视图也称为类视图，主要用于描述构成系统所需要的类或对象，其具体内容包括类、类所持有的数据、类的行为以及类之间交互的说明组成。这个视图中的信息是程序员特别关心的，如何实现系统功能所需要的细节都将在这个视图中描述和展现。3.动态视图（DynamicView）动态视图合并了前面描述的动态模型（DynamicModal）和交互模型(InteractionModal),用于描述系统中的过程或线程，重点关注系统的非功能性需求。行为视图通常由顺序图、通讯图、状态图和活动图等组成。2.2.4视图4.构件视图（ComponentView）构件视图用于描述构造系统的物理构件。这些构件不同于逻辑视图中描述的逻辑构件，这些构件包括如可执行文件、代码库和数据库等内容。这个视图中包含的信息与配置管理和系统集成这类活动有关。5.部署视图(Deploymentview)描述系统的物理结构以及构件如何在系统运行的实际环境中分布。这两个视图处理的是系统的非功能性需求，例如容错性和性能等问题。动态视图和部署视图在UML中相对地未充分开发，尤其是与逻辑视图相比。在逻辑视图中包含了大量非正式地被当作是与设计有关的符号。2.2.4视图6.其它视图除了上述五种视图以外，UML2.0以后的版本还定义了其它一些可选的视图。这些视图源于不同的建模方法或开发方法，当使用不同的开发方法，或将UML用于某中特定的目的时，可选择与之对应的视图模型。这些模型包括业务过程模型（TheBusinessProcessModel）、需求模型(RequirementsModel)、领域模型（DomainModel）、测试模型(TestModel)、和分析视图(AnalysisView)等多种不同的视图。2.3模型元素UML中定义的包含某种特定语义的元素都是模型元素。UML中定义了很多模型元素，用来表达对象模型框架中的各种概念。例如类、对象、属性、操作和消息等模型元素。模型元素通常被作为图的组成部分，任何一个图都是有多个模型元素组成的。而且，同一个模型元素也可以出现在多个不同类型的图中，当然，模型元素是否可以出现以及用什么方式出现需要遵循一定的UML规则。由于模型元素的数量较多而且种类也比较复杂，所以有必要为其做进一步的分类。UML将模型元素划分为实体、交互、分组和注释等四大类。2.3模型元素1．实体（entity）元素实体元素是指UML中用来描述上下文中具有明确建模意义的概念或者实体元素，这些元素将被映射成目标系统中的实体对象。常见的实体元素通常包括类、接口、协作、用例、构件和结点等六种元素。这些元素均属于UML的静态元素。2．交互（interaction）元素交互元素用于描述对象和对象之间的交互，对象间的交互通常指对象之间交换的消息。对象之间的消息可分成同步消息、异步消息和消息等模型元素。2.3模型元素3．组织（orgnzation）元素指UML中用于表示模型组织结构的模型元素。UML模型中，最主要的组织元素就是指视图和包等元素。就像前面介绍过的，视图既是一种由建模工具软件按照其特定标准预先定义的结构机制，它们本身也是一种包，只不过普通用户不能随意改变。包则是一种用户可随意设定的一种元素分组机制。逻辑上，包可被视为是一组模型元素构成的集合，并且包还可以包含其它的包。2.3模型元素4．注释（comment）元素用于描述和标注任何模型的模型元素，注释元素里面的信息以文本方式描述，并且是面向人的。2.4关系在面向对象概念框架中，最值得关注关系可以分为的对象之间关系和类之间的关系两大类。对象之间的关系包括依赖、链接、聚合和组合等四种关系，UML中使用类图来描述对象之间的这些关系。类之间的关系则主要是指继承关系。UML中定义的这些关系不仅用于描述对象和类之间的类，而且把这些关系推广到各种模型元素之间，从而使这些关系具有广泛的含义。图2-11列出了UML中依赖、关联、聚合、组合、继承和实现等关系的符号表示。2.4.1依赖关系（dependent）UML中，依赖用来表示两个模型元素（如类、用例等）之间存在的某种语义关系。对于两个模型元素来说，如果一个模型元素的改变将影响另一个模型元素，那么就说，这两个模型元素之间存在着某种依赖关系。例如：一个类使用另一个类的对象作为操作的参数，一个类使用另一个类的对象作为它的属性，一个类的对象向另一个类的对象发送消息等，这样的两个类之间都存在着一定的依赖关系。2.4.1依赖关系（dependent）依赖关系一方面表示了对象之间的某种协作，这种协作显然是构建一个系统所不可缺少的；另一方面依赖也反映了系统元素之间的耦合，这又要求系统中的依赖关系也必须是可控的。UML使用带有箭头的虚线表示依赖。图2-12给出了两个类之间的依赖。图中类A依赖类B，即类B内容的改变将引起A中相应内容的改变。图2-12依赖关系2.4.1依赖关系（dependent）依赖关系不仅存在于各个类之间，很多其它模型元素之间也存在着各种各样的依赖关系，如构件之间的依赖以及包的依赖等，不同的元素之间的依赖关系表示的含义是不同的。其它依赖关系将在后面章节中陆续介绍。2.4.2关联关系（Assosiation）关联关系是一种存在于模型元素之间的结构性的关系，指的是一种模型元素和另一种模型元素之间的语义联系。对于对象（或类）来说，关联意味着在一个对象（或类）内部的任何地方均可以访问到与之相关联的另一个对象（或类）的全部服务。关联关系可以是单向也可以是双向的，单向关联表示对象之间的访问是单向的关联，双向关联表示对象之间的关联可以是双向的关联。与关联相关的概念还有关联的名字、角色、多重性、关联限定符和关联类等概念。这些细节将在类图建模部分详细介绍。2.4.2关联关系（Assosiation）图2-13给出了这单向关联和双相关联的符号表示。

图2-13关联的图形符号表示2.4.3组合与聚合

（CompositionandAggregation）

关联关系中，如果在两个关联对象之间，还具有整体与部分之间的关系时，即一个对象是另一个对象的组成部分时，则称这种关系为聚合(aggregation)关系。

如果整体对象与部分对象还具有相同的生存期，则把这个聚合关系称为组合(composition)关系。图2-14对象之间的组合与聚合2.4.3组合与聚合

（CompositionandAggregation）例如，图2-14给出了对象之间的组合和聚合关系的例子。聚合一般代表逻辑上的包含，当然包括物理上的包含，而组合则代表了物理意义上的包含。如图2-14a表示了飞机与机翼、机身、引擎和起落架等各种对象之间的组合关系。而图2-14b表示了股票持有人与其持有的股票之间的关系则是一种聚合关系。图2-14对象之间的组合与聚合2.4.4继承（Inherit）继承关系（Inherit）也称为泛化或特化关系，是模型元素之间的一种强耦合的关系。对于两个类来说，如果一个类拥有另一个类的所有属性和方法，同时前者还可以拥有自己特殊的属性和方法，并且还可以修改或重新定义后者的方法。则称这两个类之间存在泛化关系。称前者为派生类或子类，后者为基类或父类。继承的表示非常简单，UML使用一个带有三角形箭头的实线表示。如图2-15表示了一个带有继承关系的类图，图中A是超类或父类，也称为基类，B是子类也成为派生类。2.4.4继承（Inherit）图2-15表示继承关系的类图实例特殊地，如果把继承关系中的父类替换成一个接口时，子类则被称为接口的一个实现。此时，二者之间的关系则称为实现关系。实现的图形符号一般使用带有三角形箭头的虚线表示，如图2-11所示。UML为接口提供了带有构造型的类图和带有直线的小圆圈两种图形表示，如图2-4中给出了名为IUnkown的接口的两种图形表示，前者隐藏接口中定义的操作，后者则包含了接口中的操作列表，二者的语义是相同的，只不过在某种上下文中前者更加简洁。2.4.5关于上述各种关系的讨论在依赖、关联、聚合、组合以及泛化等五种关系中，密切程度最高的关系是继承关系，最弱的则是依赖关系。把这些关系按照耦合度从低到高排列，得到的顺序就是：依赖、关联、聚合、组合、继承。如果进一步考虑类与接口之间的实现，实现关系将是一种比继承耦合度更高的关系。但由于接口仅仅描述了一组没有实现的操作，或者说接口并不会被映射成目标系统中的实际模块。所以讨论接口与实现之间的耦合问题将是毫无意义的。但从实现却可以派生出一种新的、类之间的关系被称为接口依赖的关系。接口依赖关系显然是所有这些关系中耦合度最弱的一种关系2.5图UML模型中，图(diagram)是一种更为重要的模型元素，图可以看成是以一组模型元素为结点，元素之间的连接关系为边构成的图。UML用图形的方式表示图。图可以用来表达软件系统或其片段在某一方面的特征，如通常表示系统的静态结构和动态行为。每种图都有其特定的构造规则和语义信息，这些规则规定了图的构造规则和方法，其语义也决定了这些图的使用范围、适用规则和使用方法。2.5图UML定义了九种图，我们称为基本的UML图。序号图所属视图1用例图(Usecasediagram)用例视图(Usecaseview)2对象图(Objectdiagram)用例和逻辑视图(UsecaseandLogicalView)3顺序图(Sequencediagram)用例和逻辑视图(UsecaseandLogicalView)4通讯图(Communicationdiagram)用例和逻辑视图(UsecaseandLogicalView)5类图(Classdiagram)逻辑视图(LogicalView)6状态图(Statechartdiagram)设计和行为视图(Designandprocessview)7活动图(Activitydiagram)设计和行为视图(Designandprocessview)8构件图(Componentdiagram)构件视图(lmplementationview)9部署图(Deploymentdiagram)部署视图(Deploymentview)表2-1UML定义的九种图2.5.1用例图(Usecasediagram)用例图是一种由参与者、用例以及它们之间的连接关系组成的图。一个用例用于表示系统所具有的某一个功能或对外提供的一种服务。每个用例都可以分解成一个或一组动作序列，这些动作序列描述了参与者与系统之间的交互，也表示了系统对这些交互的反应和行为。从用户的角度来看，一个用例完成了对其具有某种价值的工作，也代表了系统应具有的某项功能。完整的用例模型则表达了系统应具有的所有功能。用例图一般是从参与者使用系统的角度来描述系统中的信息，即在系统外部查看系统应该具有的功能，并不描述这些功能的内部实现。2.5.1用例图(Usecasediagram)一张用例图可以包括于整个系统的用例，也可以仅包含系统的部分用例，如某个子系统的用例，甚至也可以仅仅单个用例。另外，用例不仅用于描述期望的系统行为，还可以作为开发过程中设计测试用例的基础。图2-17给出了一个用例图的示例，图中列出了若干个参与者、用例、参与者与用例之间的关联以及用例之间的包含或扩充关系等。2.5.1用例图(Usecasediagram)图2-17用例图的示例2.5.2类图(Classdiagram)类图是由若干个类以及这些类之间的关系组成的图。通常用于描述系统或系统的某个局部的静态结构，也称为软件的结构模型。类图通常属于UML模型的结构视图，也是UML中最重要的模型，是系统建模所必须完成的最重要的工作结果。如图2-18给出了某销售系统的实体类类图，包含了这个系统中的各种实体类，如账户(Account)、商品(StockItem)、订单(Order)、订单明细(Lineitem）、事务(Transaction)、购物车(ShoppingBasket)和等多个类，以及这些类之间的关联关系。2.5.2类图(Classdiagram)图2-18类图实例2.5.2类图(Classdiagram)这张类图清晰地描述了这样一个系统中包含的主要实体，例如，账户表示该系统的全体用户构成的集合；商品代表了该系统销售的商品目录集合；订单描述了的该系统的销售记录；订单明细表示了每张订单的商品销售记录；事务代表了用户与系统之间的一次交易；购物车是一个与用户相关联的实体，用于存储用户选择的那些商品。这张类图不仅描述了销售系统的相关概念，对这样的类图的进一步细化还可以得到这个销售系统的实体结构模型和数据模型，并可以以此为依据构建整个系统。2.5.2类图(Classdiagram)一个典型的系统模型中通常需要建模多张类图。一个类图不一定要包含系统中所有的类，通常仅用于建模系统的某个局部。一个类也可以出现在多个不同的类图中。2.5.3对象图(Objectdiagram)对象图可以看成是类图的实例，用来描述系统在某个特定时刻某些对象之间的关系。创建对象图时，并不需要描述系统中的每一个对象。事实上，绝大多数系统中都会包含大量的对象，描述所有对象以及它们之间的关系一般并不现实。因此，建模人员可以选取所感兴趣的对象及其之间的关系来描述。2.5.3对象图(Objectdiagram)图2-19对象图实例图2-19给出了一个对象图的例子，图中包含了一个账户对象、一个订单对象、两个订单明细以及对应的商品对象。可以看出，图中的对象可以被别看成是图2-18中的各个类的实例。图中的连线（链接）就是图2-18中的各类关联的实例。2.5.4顺序图(Sequencediagram)顺序图和通讯图被统称为交互图。其中，顺序图用来描述对象之间消息发送的先后次序，阐明对象之间的交互过程以及在系统执行过程中的某一具体时刻将会发生什么事件。如图2-20中的顺序图描述了图书管理系统中借书用例的主要场景。2.5.4顺序图(Sequencediagram)图2-20借书用例的顺序图实例2.5.4顺序图(Sequencediagram)顺序图是一种强调时间顺序的交互图，其中对象沿横轴排列，消息沿纵轴按时间顺序排列。顺序图中的对象生命线是一条垂直的虚线，它表示一个对象在一段时间内存在。顺序图中的大多数对象都存在于整个交互过程中，因此这些对象全部排列在图的顶部，它们的生命线从图的顶部画到图的底部。每个对象的正下方有一个矩形条，它与对象的生命线相重叠，它表示该对象的控制焦点。顺序图中的消息通常不带有序号，由于这种图上的消息已经在纵轴上按时间顺序排序，因此顺序图中消息的序号通常都被省略掉了。2.5.5通讯图

(Communicationdiagram)通讯图(Communicationdiagram)是一种描述对象之间的链接关系和收发消息的图，它强调的是收发消息的对象的组织结构。通讯图和顺序图是语义等价的，它们可以互相转换，它们统为称交互图。在大多数情况下，通讯图主要用来对单调的、顺序的控制流建模，但也可以用来对包含迭代、分支和并发在内的复杂控制流进行建模。2.5.5通讯图

(Communicationdiagram)一般情况下，建模人员可以创建多张交互图，它们可以是用例、用例的场景、用例的可选流或扩充流等。建模人员可以使用包来组织这些通讯图，并给每张图命名一个合适的名字，以便与其它图相区别开。图2-21给出了一个典型的通讯图，容易看出它与图2-20所示的顺序图是语义等价的。2.5.5通讯图

(Communicationdiagram)图2-21通讯图举例2.5.6状态图

(Statechartdiagram)状态图(Statechartdiagram)是一种由状态、变迁、事件和动作组成的状态机模型。状态图描述的是一个对象在其生存期或某个生存期片段中的状态以及状态变迁的控制流，主要用于对系统的动态特性建模。在大多数情况下，它主要用来对反应型对象的行为进行建模。在UML中，状态图可用来对一个对象按事件发生的顺序所触发的行为进行建模。2.5.6状态图

(Statechartdiagram)例如，图2-22中就包含了为用户界面对象定义的多个状态，其中包括了一个初始态、两个终止态，以及输入用户名和输入验证码等多个状态。其中初始态和终止态是伪状态，分别表示状态图表示的过程开始之前和之后的状态。输入用户名状态和输入验证码状态是用户界面对象的两个不同的工作状态，每个状态的内部，还包含了必要的状态属性和相关动作，如入口动作、出口动作和动作等。在所有状态之间，还定义了若干个状态变迁，每个变迁都定义了触发变迁的事件、守卫条件和变迁时需要完成的动作。2.5.6状态图

(Statechartdiagram)图2-22登录用户界面的状态机模型2.5.6状态图

(Statechartdiagram)一般而言，状态图是对类所描述的模型元素的补充说明，它描述了这个类的对象可能具有的状态、引起状态变化的事件以及状态变迁时需要完成的动作。2.5.7活动图(Activitydiagram)与状态图不同的是，活动图通常描述的是多个对象共同参与的一项活动。图2-23给出了一个描述用户登录过程的活动图，它与图2-22中的状态图一样均讨论了登录问题，但二者的建模角度和描述方式却均不相同。状态图可视为对系统中某个特定对象（如登录用户界面）的动态行为的设计，而活动图描述的这是一个过程（如登录过程）中的参与角色和职责分配这样的问题。二者即相互联系，又相互区别。2.5.7活动图(Activitydiagram)图2-23用户登录过程的活动图2.5.8构件图(Componentdiagram)构件图(Componentdiagram)用于描述系统的构件组织和构件之间的各种依赖关系，主要用于建模系统的静态构件视图。构件图中也可以包括包或子系统，它们都用于将模型元素组织成较大的组块。构件可以是任何一个以可执行程序文件、库文件、数据库表、数据文件和文档等形式表示的系统构成成分。构件通常具有可更换性和可执行性，它实现特定的功能，符合一套接口标准并实现一组接口。2.5.8构件图(Componentdiagram)图2-24构件图的例子2.5.8构件图(Componentdiagram)图2-24给出了一个构件图的例子，图中列出了Firewall、LANSQLServer、MSExchangeServer、OrdersDatabase和BookStoreOrderApplication等五个构件。还列出了它们之间存在的聚合、关联和依赖关系。2.5.9部署图(Deploymentdiagram)部署图用来描述系统具有处理能力的结点以及构件在这些结点上的配置。部署图主要用于对系统的环境模型视图建模。换句话来说，部署图主要用于描述系统硬件的拓扑结构。一般情况下，每个模型中通常只需要绘制一张构件图。例如，图2-25给出了一个图书管理系统的部署图。图中的结点描述了图书管理系统需要的各种处理机或设备，它们分别是数据库服务器(DatabaseServer)、应用服务器(ApplicationServer)、读者终端(ReaderTerminal)、图书借阅终端(BookBorrowingTerminal)、信息查询终端(InformationinquiryTerminal)和信息采集终端(InformationCollectionTreminal)等处理机。。2.5.9部署图(Deploymentdiagram)图中还包括了条码扫描器(Barcodescaner)、读卡器(CardReader)和条码打印机(Barcodeprinter)等多种不同的设备。2.5.9部署图(Deploymentdiagram)图2-25图书管理系统的部署图2.5.9部署图(Deploymentdiagram)图2-25给出的部署图，清楚地描述了这个图书管理系统的物理结构。2.5.10其它除了上述9种基本的UML图之外，UML2.0及其后续版本还定义了多种不同的UML图，它们包括复合结构图(CompositeStructuresdiagram)、交互概览图(InteractionOverviewDiagrams)和时序图(TimingDiagrams)等。2.6通用机制UML提供了一些通用机制，为模型中的模型元素添加必要的附加信息。常用的UML通用机制包括：1）模型元素规约（Specification）2）修饰符（Decoration）3）扩展机制（ExtensionMechanism）2.6.1规约（Specification）对于任何一个UML模型元素，UML都定义了一个元素规约（Specification）特性，该特性为模型元素给出了一个描述性的文字说明，这个说明一般不出现在模型元素的图形表示当中。事实上，UML的图形表示可直观地描述系统，而元素规约则可以用来描述其更多的建模细节。例如，类的图形符号表示中包括了类名、操作、属性以及类关系等方面的信息。如果需要描述类概念以及类定义等方面的信息，则可能将这些信息保存在类的规约之中。2.6.2修饰符（Decorator）UML中，除了是用图形符号表示特定的模型元素之外，还是用各种修饰符表示模型元素的具体细节。例如图2-26中给出的CAnimateImage类的图形符号中，就使用了一些修饰符。例如，类图中使用斜体的类名表示抽象类；+、-和#等符号表示属性和操作的可见性；斜体的操作名表示抽象方法；带下划线的属性名或方法名表示类作用域等。类图中的修饰符既可以修饰类，如抽象类和具体类。也可以用于修饰属性和方法等，如属性和方法的可见性和作用域等。2.6.2修饰符（Decorator）图2-26某图像浏览器程序中的CAnimateImage类2.6.3扩展机制

（ExtensionMechanism）所谓UML扩展机制是指在使用现有模型元素的基础上，使用某种方式定义具有某种特定含义的模型元素的机制，从而建立具有某种新的语义的模型。UML扩展机制包括构造型和标记值等两种方式。构造型的作用是对UML模型元素所表示的概念的扩展，主要用于根据已有的模型元素创建新类型的模型元素。UML为不同的模型元素预定义了不同的构造型，称为预定义的构造型，例如为类指定的构造型«interface»表示接口，为用例间的关系指定的构造型«include»和«extend»表示用例间的包含和扩充关系等。UML通过这些构造型定义了多种不同的模型元素。2.6.3扩展机制

（ExtensionMechanism）另外，UML还可以允许用户定义自己的构造型，这将使得用户可以按自己的方式定义模型元素或将UML应用扩展到其它领域。标记值也是对UML模型元素特性的一种扩展，增加标记值是指在模型元素规约创建新的信息。其具体形式是为模型元素增加一个属性名和相应的属性值，以增加模型元素的表现力。与构造型类似，标记值也分为预定义的标记值和自定义的标记值。如类的预定义标记包括：位置、文档、持久性、语义和职责等。2.6.2修饰符（Decorator）图2-26某图像浏览器程序中的CAnimateImage类例如：图中的{Version=1.0}为类增加了一个的自定义的标记值，其含义是说明了这个类的版本。2.6.3扩展机制

（ExtensionMechanism）例如：图2-26中的类CAnimateImage中标注的{Version=1.0}就为这个类增加了一个的自定义的标记值，其含义是说明了这个类的版本。2.6.4约束（Constraint）约束（Constraint）也是UML的一种公共机制，用于表示模型元素应该满足的某个特定条件。建模时，用户可以使用约束表示软件需要满足的业务规则。UML中，约束的描述方式很随意，常见的方式可以是用自然语言编写的短语或句子，也可以使用对象约束语言编写的OCL表达式。也可以是其它任何能够接受的形式。在UML图中，约束使用带花括号的文本的方式加以描述。如图2-26中的{version=1.0}就是附加在类CAnimateImage上的一个约束。2.7对象约束语言简介对象约束语言（ObjectConstraintLanguage,OCL）是UML中专门用于编写约束和业务规则的一种形式语言。1995年，IBM公司的JosWarmer和SteveCookdailing带领的一个小组开发了对象约束语言，并将其作为业务建模项目的一部分，它后来成为IBM提交给对象标准化组织（OMG）的统一建模语言的一个部分，并将其视为定义模型中约束的推荐语言，并成为UML版本1.1规范的一部分开始被正式采用。2.7.1对象约束语言的特点OCL是一种简单、规范的描述性语言，它具有如下主要特点：1规范性OCL是一种即简单又规范的语言。这使得OCL即易于理解和使用，又能够更容易地为UML模型编写出含义明确且不容易引起误解的规则和约束。规范性是指这种语言具有严格的语法，同时也具有严格的使用规则。使用这种语言时，模型工具通常提供了严格的语法检查机制。2描述性OCL是一种说明性的描述语言，对模型描述的结构或功能没有任何副作用。使用OCL语句不会实质性地改变模型中的任何东西（如对象属性和方法）。2.7.1对象约束语言的特点3非过程性通常，人们并不使用OCL表达式描述模型中的过程（或活动）。例如，违反了某个特定规则时应执行的动作，这样的活动仍然UML模型元素（如活动图中的动作等）描述。4强类型OCL是一种严格的强类型的语言，所有运算符都要求其操作数必须符合指定的类型要求，同时每个操作也都只能适用于于特定的操作数类型。这使得使用这种语言可以严格、无二义性地描述建立的UML模型。这些特性使得这种语言既便于使用，又有助于建立概念清晰、结构严谨、表达明确，无二义性的软件模型。尽管UML不强制使用OCL，但理解和掌握这种语言的使用方法，仍然是很有意义。2.7.2OCL的主要用途OCL最主要的用途就是为UML模型中的各种模型元素指定需要的规则和约束，而这些规则或约束则可以大致划分为以下几种情形。1类不变量类不变量（Invariantsforclasses）是指对一个类的任何实例在任何情况下必须成立的条件。它指定了一个类的所有对象都必须遵守或满足的条件。2构造型的类型不变量类型不变量（Typeinvariantsforstereotypes）是一个与类型有关的不变量。在定义一个构造型时，可以用它指定一个适用于该构造型的所有类必须满足的条件。2.7.2OCL的主要用途3操作的前置条件和后置条件前置条件（Pre-conditions）或后置条件（Post-conditions）是一种约束，它指定了执行一个类操作之前或者之后需要满足的条件。在OCL表达式中，可以用分别«precondition»和«postcondition»构造型表示。4警戒条件警戒条件（Guards）用于指定是否执行某个特定的活动（或处理），或者当存在多种替代方案时如何选择某一个方案的条件。2.7.2OCL的主要用途5模型中的导航规则导航规则（Navigationalrules）是指OCL表达式中，如何通过上下文访问与上下文相关联的对象的规则，则使得OCL表达式可以用来描述上下文中的关联有关的规则和约束。6派生规则或约束派生规则（Derivationrules）指定的是如何通过其它值计算一个特定的值的规则。2.7.3OCL类型与操作OCL数据类型分为预定义的基本类型、集合类型和用户自定义数据类型三种情况。1基本数据类型OCL基本数据类型包括整数（integer）、布尔(boolean)、实数(real)和字符串（string）等数据类型，这些类型独立于任何对象模型，也是对象约束语言的基本组成部分。使用于任何UML模型。OCL的基本类型、相关操作符及取值的例子如表2-2所示。2.7.3OCL类型与操作数据类型运算符及结果类型取值相关运算符结果类型

Booleanand,or,not,xor,=,<>,impliesBooleantrue,falseifb1then<e1>else<e2>Typeofe1ore2Integer

=,<>,<,>,<=,>=Boolean1,-5,2,34,26524,...+,-,*Integer/Realmod,div,abs,max,minIntegerReal=,<>,<,>,<=,>=Boolean0.5,3.14,...+,-,*,/Booleanround,floorIntegerStringSubstring,concatString'Tobeornottobe...'toLower,toUpperStrings1=s2Boolean表2-2OCL基本类型及其运算符2.7.3OCL类型与操作2集合类型（Collection）OCL定义了Set、Bag、和Sequence等三种具体的集合类型，它们都是抽象集合类型（Collection）的子类型，Collection类型包含了对所有集合都通用的操作。图2-27描述了OCL集合类型之间的关系。图2-27OCL集合类型2.7.3OCL类型与操作其中，Collection是抽象的集合类型，用于定义所有集合类型的公共属性和公共操作。Bag是无序集合类型，可以包含重复元素。Set类型表示一个无序集合，但其元素不允许重复。Sequence则表示一个即有序，又可以包含重复元素的集合。类型操作及其结果类型说明操作操作结果类型CollectionsizeInteger集合中的元素个数count(Object)IntegerObject类型的元素个数includes(Object)Boolean是否包含对象Object.includesAll(ObjColl)Boolean判断当前是否包含指定集合isEmptyBoolean判断当前集合是否空notEmptyBoolean判断当前集合是否非空sum()IntegerorReal计算集合中所有元素的和=Boolean判断两个集合是否相等union(Collection)Collection返回当前集合与指定集合的并including(Object)Collection返回当前集合与指定元素合并得到的集合excluding(Object)Collection返回移除指定元素后得到的集合intersection(Collection)Collection返回当前集合与指定集合的交iterate(InitExpr;Expr)Expr遍历当前集合并执行指定的操作select(Expr)Collection返回当前集合中满足指定条件的元素集合reject(Expr)Collection返回当前集合中不满足指定条件的元素集collect(Expr)Collection返回当前集合中指定类型的元素集合exists(Expr)Boolean判断当前集合是否含有满足指定条件元素forAll(Expr)Boolean判断当前集合所有元素是否满足指定条件BagasSet()Set返回由Bag类型集合转换的Set类型集合asSequence()Sequence返回由Bag类型集合转换的Sequence集合Sets1-s2Set返回S1与S2的差集symmetricDifference(s2)Set返回S1与S2的对称差集asBag()Bag返回由Set类型集合转换的Bag类型集合asSequence()Sequence返回由Set类型集合转换的Sequence集合SequencefirstTypeinCollection返回当前序列中第一个元素lastTypeinCollection返回当前序列中最后一个元素at(Integer)TypeinCollection返回当前序列中指定位置的元素append(Type)Sequence返回在当前序列追加了指定元素的序列prepend(Type)Sequence返回在当前序列起始位置添加指定元素的序列asBag()Bag将Sequence类型对象转换成Bag类型对象asSet()Set将Sequence类型对象转换成Set类型对象表2-3集合类型及其操作2.7.3OCL类型与操作需要注意的是，抽象集合类型（Collection）的操作对其所有子类型都是适用的；同时，没有哪个操作可以更改集合的内容；如Append操作虽然返回一个添加了某个元素的新集合，但它并不更改原有集合的内容。一般情况下，可以将UML类图中的关联视为Set类型的集合，有序关联可以被当作是一个Sequence类型的集合。2.7.3OCL类型与操作3用户定义的类型用户在UML模型中定义的任何一种类型（如用户定义的类等）均可以看成是OCL的用户定义类型。UML模型中定义的大多数类型或符号均出现OCL表达式中，它们或者作为OCL类型，或者作为OCL变量。2.7.4OCL表达式对象约束语言的主要使用方式就是编写OCL表达式（OCLExpressions），并使用它们描述UML模型元素所需要的规则和约束。OCL表达式可以看成是一个由运算符和操作数组成的表达式，每个表达式均具有一个类型并返回一个结果。需要注意的是，为了明确OCL表达式与UML模型元素之间的关系，每个OCL表达式都必须具有明确的上下文（Context）。在OCL表达式中，上下文可以看成是对模型中，某个特定的UML模型元素的一个引用，通过这个引用可以为模型元素定义期望的规则或约束。2.7.4OCL表达式上下文可以是UML模型中的任何类、属性、方法以及类之间的关联等。上下文为表达式指明了表达式希望约束或描述的目标。没有明确上下文的表达式将毫无用处。图2-28给出了一张类图，图中包含了两个类及其关联关系。后面介绍的部分例子中将会以这张图中的内容为上下文定义需要表示的业务规则。2.7.4OCL表达式上下文可以是UML模型中的任何类、属性、方法以及类之间的关联等。上下文为表达式指明了表达式希望约束或描述的目标。没有明确上下文的表达式将毫无用处。图2-28给出了一张类图，图中包含了两个类及其关联关系。后面介绍的部分例子中将会以这张图中的内容为上下文定义需要表示的业务规则。2.7.4OCL表达式图2-28给出了一张类图，图中包含了两个类及其关联关系。后面介绍的部分例子中将会以这张图中的内容为上下文定义需要表示的业务规则。图2-28类图实例2.7.4OCL表达式OCL表达式通常可以分成不变量、操作约束、初始或派生规则以及导航等多种形式。1.不变量（Invariant）不变量表达式通常以模型中某个特定的类为上下文，描述这个类的所有实例应该满足的约束条件。2.7.4OCL表达式例如：对于图中的Company类，定义“员工数大于50”这样的约束时，可以使用如下的OCL表达式表示。contextCompanyinv:Company.numberOfEmployees>50图2-28类图实例2.7.4OCL表达式例如：对于图中的Company类，定义“员工数大于50”这样的约束时，可以使用如下的OCL表达式表示。contextCompanyinv:numberOfEmployees>50图2-28类图实例2.7.4OCL表达式第一行中context是一个OCL关键字，表示其后面的类名Company是整个表达式的上下文。其含义是表达式的作用范围是Company类的所有实例。符号inv是一个关键字，表示该表达式是一个不变量表达式。第二行定义了一个用布尔表达式（numberOfEmployees>50）表示上下文需要满足的条件，其中numberOfEmployees被隐含地解释成Company类的属性。两行语句组成了一个完整的OCL表达式，它表达的语义是：“Company类的numberOfEmployees属性值必须大于>50”或“公司员工数＞50”。这个表达式为Company类定义了一个约束。2.7.4OCL表达式下面列出了三个使用了不同表示法的等价表达式：1）使用了self关键字contextCompanyinv:self.numberOfEmployees>50self关键字表示上下文（Company类）的一个实例，其作用是明确了numberOfEmployees是Company类的属性。2）使用实例变量作为上下文contextc:Companyinv:c.numberOfEmployees>50使用Company类的实例变量c作为上下文，c被视为Company类的一个实例，表达式明确了numberOfEmployees是实例变量c的属性。3）使用表达式名字contextc:CompanyinvenoughEmployees:c.numberOfEmployees>50将enoughEmployees定义为OCL表达式的名字，这使得可以在其它地方使用这个名字引用这个约束。2.7.4OCL表达式2.操作约束（OperationConstraint）OCL表达式可以定义模型中与类操作有关的约束，操作约束可以分为操作的前置条件、后置条件和操作体约束。前置条件和后置条件表示了作在执行前或执行后必须满足的条件。因此，这两种约束实际上也是一种不变量约束。前置条件通常是对其输入参数的约束。后置条件则主要是对操作输出的结果的约束。定义前置条件或后置条件的方法就是使用pre和post关键字表示前置条件和后置条件。另外，关键字result表示操作的返回结果。2.7.4OCL表达式2.操作约束（OperationConstraint）定义操作约束的语法格式定义如下：contextTypename::operationName（）:Typepre:--post:--例如，为Person类的InCome操作定义前置和后置条件。contextPerson::InCome():Personpre:self.isUnemployed=falsepost:result>15002.7.4OCL表达式2.操作约束（OperationConstraint）操作体约束使用body作为表达式条件的前缀。一般情况下，表示一个查询操作的结果。表达式的类型必须与操作的结果类型相一致。与前置条件和后置条件一样，可以在表达式中使用操作参数。前置条件、后置条件和操作体表达式可以是混合在一个操作上下文中。2.7.4OCL表达式3.初始和派生规则（InitialandDerivedValues）OCL表达式可以通过初始和派生规则为属性或关联角色指定初始值和派生值。OCL定义了init和derive两个关键字来定义初始和派生规则；定义初始和派生规则的语法规则的语法形式如下：contextTypename::attributeName:Typeinit:--someexpressionrepresentingtheinitialvalue2.7.4OCL表达式3.初始和派生规则（InitialandDerivedValues）OCL表达式可以通过初始和派生规则为属性或关联角色指定初始值和派生值。OCL定义了init和derive两个关键字来定义初始和派生规则；定义初始和派生规则的语法规则的语法形式如下：contextTypename::assocRoleName:Typederive:--someexpressionrepresentingt