计算机管理信息系统-10章UML建模语言

10.1模型的作用

10.2统一建模语言UML

10.3UML模型

10.4常见图的用法与内容

第10章UML建模语言

10.1模型的作用

借助于模型实现对复杂系统的认识，是一种有效手段;

■实际的管理信息系统是一个复杂的系统，我们要开发以计算机处理为基础的现

代管理信息系统，首先就得认识、理解原有的系统或手工业务，经过反复讨论

和修改以后，构造出新的管理信息系统方案。在这一过程中，模型起着非常关

键的作用。

模型可以帮助我们以化简的形式捕捉现实系统中问题的本质;

通过模型可以把被讨论的概念可视化，把你心目中的系统实现方案勾勒出来，把它

变成大家能够看

模型有助于在由

♦结论：学习建模

2012-9-20第8章运行与维护2/56

10.1模型的作用

B♦io.i.i什么是模型

'♦：♦10.1.2建模的价值

2012-9-20第8章运行与维护3/56

10.1.1什么是模型

。模型并不深奥。

-在你和别人讨论问题时，把你想表达的东西以简化的形式画到纸上，这就是模

型，哪怕是随便勾画了几笔，只要有助于表达问题，它就是模型了。

r模型可以描述系统的静态结构，也可以描述系统的动态行为；可以描述系统的宏观

面貌，也可以描述系统内的微观交互场景。

简单地讲，模型是对现实的简化、或者说，模型是简化的现实；

模型会先于方案而存在，模型提供了营造方案的蓝图。

2012-9-20第8章运行与维护4/56

建模是有目的

建模的目的，是为了认识复杂的问题（或系统）；简化是认识复杂系统的一种有

效方法；而建模是简化问题的有效手段；

♦“简化”是有目的的进行的

・准确地讲，一个具体的模型是人对现实系统抽象认知的结果，这一结果取决

于人和他观察问题的角度。人是认知活动的主体，他在认识一个事物的时候,

往往是带有主观意志的，即他会从自己的立场或角度来看问题。

—从某个角度看问题，排除不必要的干扰，把问题化简，抓住主要矛盾和事物的本

质，这就是建模的目的。

・打一个比方，一座大楼在土木设计师眼里可能是一堆钢筋混凝土和表面材质;

在管道设计师眼里可能是一堆管子和接头；在网络工程师眼里可能是一堆网

络设备和布线。不同主体对同一客体的认识结果有赖于各自的视角，即看问

题的角度。这样能更好地集中注意力，从而有效地解决关键问题。

2012-9-20第8章运行与维护5/56

建模是有原则的

<*在建立模型的过程中，建模者的主观立场或认识问题的角度，被强调为认知活动的

原则，这很重要。

=❖建模过程就是简化问题的过程，就是要把某些主要的关键的东西勾勒出来，把对讨

——论问题无关紧要的东西暂时略去，以免干扰视线。

r■因此，在讨论一个系统中的某个问题的时候，我们不是把整个系统都详细地表

述出来以后再进行讨论，而习惯于从某个角度整理出一个从某个侧面观察的问

题模型，这就是建模的原则。

对于一个系统，基于不同的简化动机（目的）和简化水平（原则），可以得到多个

模型，这样有助于更深刻和更准确地把握系统的本质。

2012-9-20第8章运行与维护6/56

对模型的评价

。利用价值高的模型就是好模型；

-针对特定的建模“动机”和“原则（抽象层次）”，我们通常会忽略那些与特

定抽象层次无关的次要因素，而强调那些具有广泛影响力的主要因素，这就是

在追求模型的使用价值。

——r■换言之，内容多的模型未必是好模型，因为价值高的内容有可能被价值不高的

内容淹没了。

・模型的的好坏，取决于两个因素，即建模的“视角（动机）”和“抽象层次”，

这两个因素决定了模型有没有把握问题的本质和有没有洽到好处的排除掉干挠

视线的次要因素，便于清晰的认识问题。

2012-9-20第8章运行与维护7/56

模型的表述

，模型是一组具有完整语义的信息，包括两个方面的含义：

'■一方面，模型是对现实的简化；

・另一方面，模型反映了认知主体（开发人员）对问题域认识的视角和抽象层

次。不同的视角，表现为各种类型的图（Diagram）及其包含的元素和关联；

不同的抽象层次，表现为不同类型的视图（View）。两者都是模型不可或缺的

要素。

—尽管说模型是简化的现实，并强调化简价值，但这并不意味着可以片面地夸大图示

信息的作用，好的模型应该是图文并茂，其关键是可用和易用。

2012-9-20第8章运行与维护8/56

10.1.2建模的价值

。建模(Modeling)是捕捉问题本质的过程。为了降低风险和获得高回报，建模活动

_普遍应用于各种行业，信息系统(软件)开发更不例外。为了说明建模的价值，

GradyBooch曾经给出过一个经典的类比：

■盖一个宠物窝棚、修一个乡间别墅和建一座摩天大楼，三种工作对建筑规划图

r纸的依赖程度有质的差异。建立一个简单的系统，模型可有可无；建立一个比

较复杂的系统，模型的必要性增大；建立一个高度复杂的系统，模型则不可缺

少。应用处理简单系统的方法对待复杂系统通常是行不通的，这好比用搭建一

个宠物窝棚的方法来营造一座摩天大厦。

建模的意义随着系统复杂程度的增加而越发显著，从起初借助于模型以更好地理解

系统，到后来不得不借助模型来理解系统。人脑对复杂问题的理解能力是有限的，

与模型相应的特定视角和抽象层次是简化复杂问题的有效出发点。

2012-9-20第8章运行与维护9/56

建模对于复杂软件系统的开发是必要的

-目前，我们开发的软件，特别是商业软件，通常一开始就很不简单，并且复杂性随着时间

的演进和技术的发展持续上升。一个复杂软件系统的开发必须面对多种未知因素、多个开

发人员、复杂的开发工具和永远不够用的时间。开发人员不可能、更没有必要去了解从问

题到方案的所有细节。他们需要那些基于特定视角的、有助于解决问题的并且是完整的某

一部分信息，即所谓的模型。总之，建模对于复杂软件系统的开发是必要的。

♦建模活动是有意识的、有目的、有原则、有计划的严密工作

-广义上讲，无论出于何种动机，只要在问题到方案之间做出一些过渡性的努力，哪怕只是

在草稿或白板上画了几笔，实际上就是在建模了。不过有意识和无意识的建模活动对模型

的质量或价值的影响很大。有意识的建模活动通常是有计划的、有准备的和早动手的。通

过这样的建模活动，得到的模型通常是完整的、一致的和可复用的。无意识的建模活动，

通常是随机的、无准备的和补救性的，得到的模型往往是零散的、混乱的和一次性的。

准确地讲，建模活动直观地记录下认知和求解过程，支持团队成员之间的有效沟通，为重复利

用各个阶段积累的智力成果创造了有利的条件。

概括地讲，建模简化了认知过程，化简了求解过程。V

2012-9-20第8章运行与维护10/56

10.2统一建模语言UML

。为了表达问题，你可以使用任何能够说明问题的图形符号、文字、表格、线条等，

_只要能说明问题，所有这些都可以作为建模的工具。

在管理信息系统的开发过程中，建模是必不可少的。在结构化的系统分析与设计过

程中，我们学过的主要建模工具包括数据流图、数据字典、结构图等；UML则是面

r向对象的开发方法中使用的主要建模工具之一。

♦统一建模语言UML,全称是UnifiedModelingLanguageo

掌握UML的建模技术，是面向对象分析与设计的基本技能之一。

2012-9-20第8章运行与维护11/56

JimRumbaugh是IBM杰出的工程师，如今他

正领导IBMRational分部的软件建模工作。

他和GradyBooch>IvarJacobson并称为

发明UML的“三友”，UML在1997年被国际

对象组织接收为建模标准。他也参与了RUP

的开发并且曾经是面向对象分析与设计方

面的0MT的主要开发者。上周，InfoWorld

编辑在在SantaClara召开的SDWest2005

会议上对Rumbaugh进行了访谈，讨论了UML、

SOA(service-orientedarchitectures)

和ESB(enterpriseservicebus)技术。

Rumbaugh对微软及其在U肛上的骑墙姿势表

示了不屑。

2012-9-20第8章运行与维护12/56

UML的来历

。20世纪90年代初，很多面向对象的方法已经拥有自己的符号体系，其中有三种比较

___突出：

■JimRumbaugh的0MT方法，

r■GradyBooch的Booch方法

■IvarJacobson的OOSE方法。

♦不同的方法和符号体系各有所长：0MT擅长分析，Booch擅长设计，00SE则擅长业务

_建模。那个时期的面向对象技术人员没有我们这么幸运，为了建立比较丰满的模型

并进行有效的沟通，他们需要掌握不同的符号体系，并且花费一些精力去翻译和转

述用不同符号体系表述的模型。

2012-9-20第8章运行与维护13/56

UML的来历

。在后来的几年中，上述三位大师在各自的著作中自然而然地融入了其他两种方法的

技术内容。

JimRumbaugh于1994年离开GE加入GradyBooch所在的Rational公司，开始和

GradyBooch协同研究一种统一的方法。一年后,UnifiedMethod0.8诞生了。

r♦3同年，Rational收购了IvarJacobson所在的Objectory公司，IvarJacobson从此

也成为Rational的一■员。UnifiedMethod不久更名为UML。

仰仗三位面向对象方法学大师的威望，基于数十位业内重量级人物历时两年的通力

合作，并充分考虑到多个合作伙伴的反馈意见，UML一步步趋于成熟。1997年9月，

=UML1.1被提交到国际对象管理组织，同年11月被该组织认定为标准的建模语言。

统一建模语言，顾名思义有三个要点：统一(Unified)、建模(Modeling)和语

言(Language)。---1

2012-9-20第8章运行与维护14/56

把握UML的优势和学习方法

。“统一”是UML的核心。它提升了开发团队的沟通效率，节约了以往用于翻译和转

_述的开销，屏蔽了藏匿于含糊语义中的风险。

■在传统的方法中，它们各自拥有专用的符号系统，这也是长期以来潜在的沟通

壁垒，而使用UML表述的内容能被各类人员所理解，包括用户、领域专家、分

r析师、设计师、程序员、测试人员和培训师等。通过UML,他们可以充分地理

解并表述自己所关注的那部分内容。

一“建模”体现了UML的使用价值。UML在制定过程中汲取了多种建模方法的精华，包

—括业务建模和数据建模等。

■UML的使用价值不可能脱离特定类型的建模活动。对于学习者而言，如果以掌

握UML的符号和规则为最终目的，你将所获甚微。尽管UML所表述的内容可以贯

穿系统开发的整个生命周期，但UML不同于普通的程序设计语言，.以仅仅汇

握UML的符号和规则并不能得到实际的解决方案。工<

2012-9-20第8章运行与维护15/56

把握UML的优势和学习方法

。“语言”是UML的普遍价值的表现

■语言的一层基本含义是一套按照特定规则和模式组成的符号系统，被拥有相同传统和习惯

的人群所使用。我们在日常生活中将“拥有共同语言”看做是能够有效沟通的必要条件。

近年来，软件开发所涉及的技术飞速发展，不同技术门类所使用的建模语言自成体系，同

r时也具有很大的局限性，表现形式的差异往往掩盖了本质内容的相通。幸好，与人类的自

然语言不同的是，在软件开发过程中使用的建模语言不涉及宗教和文化等诸多历史或地域

障碍。在博采众长的基础上，UML作为一种共通的和可扩展的语言，其描述能力适用于软

件开发中各种技术门类的建模活动。自然语言是人类对客观世界建模最直接有效的表述形

式；类似地，UML是迄今为止，软件开发人员进行统一建模活动最直接有效的表述形式。

不仅如此，UML还是能被软件开发环境所理解的语言。

通常，我们没必要在掌握所有的词汇和语法之后才开始使用一种语言。掌握语言的关键在于有

目的地使用，学习UML的情况很类似。在开始阶段，基于一个明确目标，集中精力理解一些必要

的词汇和语法，在使用中深入体会才是事半功倍的做法。V一■'———

2012-9-20第8章运行与维护16/56

10.3UML模型

。下面以实用为目标，简单介绍一些UML的基本语义、内容组织与表述规则，内容包

括三小节：

10.3.1模型的基本内容

r♦10.3.2UML的语义扩展

10.3.3模型的组织结构

2012-9-20第8章运行与维护17/56

10.3.1模型的基本内容

B概念上，UML用于描述模型的基本词汇有三类：要素、关系和图。

’■“要素”是模型中的核心内容，可以形象地理解为“点”；

■“关系”在逻辑上将要素联系在一起，可以形象地理解为“线”；

—■“图”将一组要素和关系展现出来，可以形象地理解为“面”。

-总体上看，由这些“点”、“线”、“面”组成了“立体”的模型。

2012-9-20第8章运行与维护18/56

.第一类词汇——要素

UML中有四种类型的要素。

(1)表述结构的要素，包括“UseCase"、“类(Class)”、“接口

(Interface)”和“协作(Collaboration)”。

(2)表述行为的要素,包括“交互(Interaction)”和“状态机(State

Machine)”。

(3)用于组织模型内容的要素，即“包(Package)”。

(4)用做辅助说明的要素，即“注释(Notes)”。

2012-9-20第8章运行与维护19/56

2.第二类词汇——关系

*>u肛中有四种类型的关系。

♦(1)关联关系(Association),表达两个类的实例之间存在连接。聚集关系

(Aggregation)与组合关系(Composition)是关联关系的两种强化形式。

♦(2)依赖关系(Dependency),依赖者“使用”被依赖者的关系。

r❖(3)泛化关系(Generalization),表达“特殊的”与“一般的”的关系。

❖(4)实现关系(Realization),“被实现者”是要求的说明，“实现者”是针对要求

的解决方案。

2012-9-20第8章运行与维护20/56

3.第三类词汇——图

。UML中有九种图，实践中常用的有六种，包括两种静态图和四种动态图。

♦(1)UseCase图：UseCase图是一种静态图，主要用于展示UseCase、Actor及其关系。

♦(2)类图：类图也是一种静态图，主要用于展示类、接口、包及其关系。

(3)序列图(Sequence)：序列图是一种动态图，用于按时序展示对象间的消息传递场景。

r♦(4)协作图(Collaboration)：协作图是一种动态图，其核心内容与序列图相对应，与序列图

表示的是相同的内容，但它并不是关注对象之间消息传递的场景，而是强调对象间由于收发消息

而关联起来的一种组织结构。序列图和协作图统称交互图(InteractionDiagram)0

(5)状态图(StatechartDiagram)：状态图也是一种动态图，主要用于展示对象在其生命周期

中可能经历的状态，以及在这些状态上对事件的响应能力。

(6)活动图(ActivityDiagram)：活动图也是一种动态图，用于展示系统从一个活动流转到另

一个活动的可能路径与判断条件。

其他三种静态图分别为对象图(ObjectDiagram)＞构件图(ComponentDiagram］和鄢署用

(DeploymentDiagram)。//

2012-9-20第8章运行与维护21/56

10.3.2UML的语义扩展

”作为一种语言，UML除了提供基本词汇，还给出了对自身描述能力的三种扩展机制，

即构造型(Stereotype)、标注值(Taggedvalue)和约束(Constraint)。

本书实例中主要使用“构造型”扩展基本模型词汇的语义，来表达新的概念。在后续

的分析与设计活动中，主要用到以下几种。

r(1)类的构造型。在系统分析阶段的“提取分析类”活动中将使用实体类

〈〈entity〉》、控制类〈〈control〉和边界类＜＜boundary＞＞；在"确定核心元素”活动

中将使用“子系统代理”〈〈subsystemproxy»；在“引入外围元素”活动中将使用

角色＜＜role＞＞。实质上，接口也是类的一种构造型＜。111642©6＞＞。

(2)包的构造型。在“选用构架模式”活动中将使用层次＜＜layer＞＞；在“确定核心

元素”活动中将使用子系统＜＜subsystem＞＞。

2012-9-20第8章运行与维护22/56

10.3.2UML的语义扩展

。(3)UseCase的构造型。“UseCase实现"〈〈usecaserealization〉〉是Use

Case的一种构造型，表述用分析或设计元素实现局部需求的协作内容；“设计机

制"〈〈mechanism〉》，表述解决特定技术问题的协作模式。

上述构造型是UML应用建模中常见的语义扩展形式，在后面章节结合特定应用场合

r会具体讲到相关的概念和用法。

2012-9-20第8章运行与维护23/56

10.3.3模型的组织结构

。总体上，模型的内容通过包以及包的层层嵌套组织在一起。

白。UseCaseView

■模型中的包类似于Windows系统管理磁盘文件的巨录结构，®OUseCase模型

如图10.1所示。包将一堆零散的模型内容简单地组织在一®O业务模型

起，目的是更易于理解和管理。族Main

三Associations

模型应该能够反映建模者和使用者的特定视角，它就是建模动机,El-CjLogicalView

国门类

表现为的模型中的''构架视图”(ArchiectureView)o

®o设计模型

r■正如在土木设计师眼里的大楼可能是一堆钢筋混凝土和表

@Mam

面材质，同样一座大楼，在管道设计师眼里可能是一堆管g：设计模型整体组织结构

子和接头，在网络工程师眼里可能是一堆网络设备和布线:国一mAssociations

不同主体对同一客体的认识结果有赖于各自的视角，即看[+)-ComponentView

0；DeploymentView

问题的角度。这样能更好地集中注意力，从而有效地解决@ModelProperties

关键问题。

在模型中，构架视图用包的形式表达。每一种特定的“视角”对图10.1模型的组织结构

应一种类型的构架视图，在RationalRose建模工具中，用Use

Case视图(UseCaseView)描述需求模型；用逻辑视图

(LogicalView)描述设计模型。还有组件视图和部署视图分别

用于描述实施模型和系统整体部署。

2012-9-20第8章运行与维护24/56

10.4常见图的用法与内容

。UML中的主要“词汇”包括：“要素”、

“关系”和“图”；

“图”UML的主要“词汇”之一，是为了实

现建模目的而使用的一种表现手段，有时一

r种图可用于不同场合以满足特定的要求。图

不仅表述了建模的最终结果，同样记录了认

知求解的轨迹。

基于“以用为本”的原则，本节概念性地说

明几种图，其中着重强调两方面的内容恭

-第一，图的用法及其在模型中的位置；

・第二，包含的关键内容。

2012-9-20第8章运行与维护25/56

10.4.1UseCase图

2012-9-20第8章运行与维护26/56

.用于描述系统与外部环境交互关系的UseCase图

(1)用法及在模型中的位置

UseCase图主要用于描述系统和外部环境

的交互关系，如图10.2所示。概念上，Use

Case的集合表达了拟建系统的全部，Actor

的集合表达了外部环境，UseCase和Actor

之间的连线的集合则表达拟建系统和外部

环境的边界。影院售票系统UseCase图如

图10.2描述拟建系统与外部环境的UseCase图

2012-9-20第8章运行与维护27/56

BLJUseCaseView♦：♦这种用法的UseCase图通常位于"UseCase

Ei□UseCase模型

BOActors模型”的“UseCases"包内，如图10.4所

s□被动要素

0-O主动要素示。

B吴电话订票

国'客户♦：♦通常将Actors和UseCase放在不同的包中。

三Associations

三Associations

日□UseCases

题系统与外部的交互

0O达到目标1

O达到目标2

图10.4UseCase图在模型中的位置

2012-9-20第8章运行与维护28/56

（2）关键内容。

①ActoroActor在图中表现为火柴棍儿。简单讲，Actor代表拟建

系统外部和系统进行交互的某类人或系统，可以称为与系统有交互

的外部实体。

②UseCase。UseCase在图中表现为一个椭圆。UseCase定义了一

组相关的由系统执行的动作序列，将有价值的可见结果提供给Actor。

UseCase与外部的交互活动中可能涉及若干个Actor,但是只有一个

主动要求得到有价值的可见结果，常被称之为主导（Primary）

Actoro主导Actor触发交互活动，它到相应的UseCase的连线是标

有箭头的。与该UseCase相连的其他Actor则为被动Actor,相应的

连线不标箭头。

❖③通信关联。Actor和UseCase之间的连线称为通信关联，表示

Actor和相应的UseCase之间的交互。无论有没有箭头，通信关联都

表示介于Actor和相应UseCase之间的双向会话，用箭头仅表示

Actor触发UseCase的执行。

2012-9-20第8章运行与维护29/56

2.用于描述需求模型与设计模型关系的UseCase图

(1)用法与相对位置

<♦这里使用UseCase图描述功能需求部分的

UseCase与相应的设计内容，"UseCase

实现”之间的可追溯关联如图10.5所示。

概念上，“UseCase实现”是指用拟定的

方案实现用户提出的需求(用usecase表

达到目标2一方式B达的需求)，如图10.6所示。

图10.5用UseCase图表示可追溯的关联

2012-9-20第8章运行与维护30/56

（2）关键内容。

①UseCase实现。"UseCase实现”用虚线边框的椭圆表示，EQUseCaseView

臼OLogicalView

其中描述的是设计内容，即如何用设计方案实现UseCase描述

国门类

的需求。描述这些设计内容使用的图般包括“序列图”、B□设计模型

BOUseCase实现

“协作图”、“活动图”、“类图”等。臼口达到目标1

②实现关系。实现关系是“UseCase实现"至UUseCase之间E达到目标1一方式A

二Associations

的连线。设计工作完成时，UseCase模型中的每个UseCase在E口达到目标2

达到目标2少式A

设计模型中至少有一个"UseCase实现”与之对应，“Use达到目标2H式B

3Associations

Case实现”和“UseCase"之间有可能是多对一的关系。通俗|一除赢溯关联

地讲，一种要求可以通过多种办法解决。

通常，在设计模型的“UseCase实现”包中，对应每一个Use图10.6描述需求模型与设计模型关系的UseCase图

Case建立一个以该UseCase命名的包，在此放置对应该Use

Case的“UseCase实现”的模型内容，如图10.6所示。

2012-9-20第8章运行与维护31/56

10.4.2表述类、接口和子系统之间关系的类图

♦：♦1.用法与相对位置

♦类图是应用最广泛的一种图，描述

拟建系统各个层面的静态结构，主

要用于表述类、接口和子系统之间

的关系，如图10.7所示。

♦这种用法的类图可以进一步划分为

三种不同的情形，尽管表现形式相

图10.7描述类、接口和子系统之间关系的类图似，但是它们通常位于模型的不同

位置。

2012-9-20第8章运行与维护32/56

■厂♦（1）第一种情形，用于描述参与某一特定协作的类、接口和子系统之间的关系。这种情形的类

f图被称为“参与类图”。“UseCase实现”与“构架机制”是两种典型的协作，“参与类图”

是隶属于这两种类型的协作内容，如图10.8、图10.9所示。构架机制指的也是一组对象的协作

关系，在后面章节会具体讲到。

3CjUseCaseViewE）ULogicalView

国口类

白CjLogicalView

设计模型

国口类ED

ISC3UseCase实现

El0设计模型

ED层次构架

日OUseCase实现

EO构架机制

曰a达到目标i

；eO构架机制x

日Y二：达到目标1一方式A

ORoleClassA

目类与参与类

奥协作图国本事件序列）ORoleClassB

麻序列图（备选事件序列1）*RoleClassC

标序列图（备选事件序列2）SO机制的协作描述

I氤序列图（备选事件序列Q画参与类图

遮序列图（典型时序

赧序列图性本事件序列）1）

而序列图（典型时序2）

图10.8''UseCase实现”中的“参与类图”图10.9''构架机制”中的“参与类图”

2012-9-20第8章运行与维护33/56

。(2)第二种情形，表述同一包中的

臼CjLogicalView

田门类

类、接口和子系统之间的关系。这种日O设计模型

国(2jUseCase实现

类图通常出现在相应的包中，如图白Ul层次构架

SO«layer»特定应用层

10.10所示。SO通用服务层

SO«Layer»系统服务层

一(3)第三种情形，针对上述两种情BO«layer»一般应用层

rEJ□ClaimArtifacts

SEz3courseDB

形以外的其他目的，表述类、接口和S(Z)externalinterface

BJEz3teackerDB

子系统之间的关系。这种情形的类图aO关建抽象

a包之间的依赖关系

可以出现在需要的任何位置。美援抽象概念间的关系

图10.10表述包内部关系的类图

2012-9-20第8章运行与维护34/56

B❖2.关键内容

'(1)类。类用于描述一组具有相同属性、操作、关系和语义的对象。如图10.11所

示，上面是类的名称，通常其首字母大写，中间是属性，下面是类的操作。

StudentTeacher

工

号

学号

职

编

名

姓名

姓

业

性别

专

别

专业

系

/缺得选课清单()+提交学生成绩0

图10.11类的UML表述

2012-9-20第8章运行与维护35/56

o(2)接口(Interface)。接口用来说明一个类

或子系统应该提供的服务。在形式上接口是一组

操作的集合。如图10.12所示，是接口的两种UML

表述形式：第一种是简略的表述，只有一个圆圈

和接口的名称，没有显示接口中定义的操作；