UML 的形式化描述语义【转】

UML 的形式化描述语义【转】

http://www.educity.cn/se/casepanel/201004291616281656.htm

1           引言

随着模型驱动软件开发方法的发展,建模语言如UML 的语义问题引起关注。人们广泛认为具有清晰严格的语义的建模语言才能用来进行严格的建模。因此,虽然在UML 的形式化语义方面已经开展了很多研究工作,但依然存在许多尚未解决的问题。本文提出一种新的方法来定义建模语言的形式化语义。我们将此方法应用于定义UML 的类图、交互图和状态图的语义,并以此为理论基础,设计并实现了一个软件工LAMBDES (Logical Ana2 lyser ofModels/ Metamodels Based on DEscriptive Seman2tics) 。LAMBDES自动地将UML 模型转换成逻辑系统,然后用定理证明器SPASS[1 ] 来对模型进行推理。我们将此方法应用于模型的一致性检查。

2 　形式化语义的定义

2. 1 　关于模型的概念

Seidewitz 在文献[ 2]中指出,软件模型如同其它任何科学领域中的模型,是一组描述被研究系统的语句,每个语句可以被建模系统判断真假。Seidewitz 进一步指出,模型的意思有两个方面,一方面是模型与被建模系统的关系,另一方面是被建模系统的功能和性质。在“此模型的意思是被建模J ava 程序包含了这些类”这句话中,“模型的意思”指的是模型与被建模系统的关系。一个模型描述了主体域中的一些系统。这里主体域指建模语言意图描述的一组系统,例如UML 的主体域可能是所有Java 系统,也可能是现实世界中所有能用面向对象概念描述的系统。在这些主体域中,一个语句如“系统包含了这些类”的真假值是可以判断的。

另一方面,当说“继承关系意味着每个子类的实例也是父类的实例”的时候,模型的意思与一些基本概念相关,如什么是类,什么是类的实例的行为等。这个方面的语义决定了满足模型的系统的功能与性质,以及两个不同模型描述的系统是否行为上等同。

为了区分这两个方面,我们将模型与被建模系统的关系这个方面的语义称为描述语义,模型所描系统的功能和性质这方面的语义称为功能语义。

从这个角度,我们可以看到UML 的语义定义中存在的不足。UML 语言规约[3 ] 中的语义部分解释了每个元类(Metaclass) 的性质和结构,但并没有明确定义模型与系统之间的满足关系,即如何判断一个系统是否满足一个模型。举一个简单的例子:一个类图仅包含一个命名为A 的类节点。这个模型可以以如下任一方式解释:

(1) 系统中仅有一个名为A的类;

(2) 系统中至少有一个名为A的类,也可能有其他类;

(3) 系统中仅有一个类,不论这个类的名字是什么;

(4) 系统中至少有一个类,不论这个类的名字是什么。

UML 语言定义并没有说明上述哪种解释是对的。

Kent 指出[4 ] ,一个UML 模型可以有不同的实现,语义定义必须体现模型对系统的不充分规约。我们认为,对UML描述语义做形式化定义需要解决以下五大难题:

(1) UML 被设计为不仅可以用来建模软件系统,也可以建模现实世界中的系统、组织和业务过程。任何可以用面向对象概念描述的领域都可以成为UML的主体域。此特征使得UML 模型成为连接问题域和计算域的桥梁,也使得UML 可以用来建模不同的问题域,包括软件、硬件、业务过程等等。形式化的UML 语义必须支持在多种不同问题域中对模型进行不同的解释。

(2) 完整的UML语言包含大量相互关联的语言成分。因此,即便是针对一个特定的主体域,定义UML的语义也相当困难。这要求语义定义方法具有很强的表达能力。

(3) UML 采用多视图原则进行建模,用户可以创建多种图来从不同角度描述一个系统。每种图在UML 中由一个元模型定义,这些元模型之间通过引用和继承关系相互关联。元模型之间的这些关系使得UML 的语义更加复杂,并且带来了多视图模型的一致性问题。如何在同一个框架下定义不同视图的语义并将他们联系起来是UML 语义定义中尚未解决的问题,也是难点。

(4) 定义UML语义的一个主要困难来自模型本身的抽象特性。UML 被设计为可以用来在软件工程的不同阶段、在不同抽象层次上描述系统。例如,需求阶段产生的模型比设计阶段产生的模型更抽象。UML 语义的形式化必须反映语言在不同抽象层次上的使用。

(5) UML 的一个重要特征是灵活性。这一特征通过两种机制实现:一是扩展机制。通过定义profiles ,用户可以定义新的元类。二是语言元素本身的多义性。UML 语言规约中保留了多处语义变化点( SemanticVariationPoint) ,允许用户进行精化和定制并选取不同的解释。

2. 2 　相关工作

针对UML 语义中的不充分定义和不精确的问题,在过去的十年中人们已经开展了大量研究工作来定义UML的形式化语义。但是,现有工作都以功能语义为研究对象,或者以“更深刻的理解面向对象概念”为目的。以下列出相关工作中较著名的一些。

类图是UML 中最重要的一种图。在类图的形式化语义方面,Evans 等在文献[5 ]中提出一种方法,用Z schemas表示Classifier、Association、Generalization、Att ribute 等元素,用公理定义Object和Classifier 之间的关系。用图形化的转换规则作为推理规则来推理UML 模型的性质。文献
[6 ]综述了用Z 或Object2Z 定义类图的形式化语义的不同方法。一阶逻辑和描述逻辑也被用来定义类图的形式化语义。通过用描述逻辑知识库表示UML 的类图,可以用描述逻辑推理系统来推理类图。文献中也有对其他类型的图的形式化语义的研究。文献提出了一种用规则定义的状态图的操作语义。文献也为状态图定义了一种操作语义。

有一些研究是在一个语义框架下定义不同种类的图。文献将一个UML模型看作一组结构化的过程,将类图和状态机映射为用Casl2ltl描述的代数规约。另一个工作是基于图转换( Graph Transformation) 集成类图、对象图和状态机图的语义。

一些研究者利用UML 的扩展机制profile 来定义UML 的语义。文献定义了一个profile UML2B ,通过把profile 中定制的UML 元素翻译成B 而定义这些元素的语义。文献提出一种集成的形式化方法,用一种集成了进程代数CSP 和规约语言Object2Z的语言CSP2OZ 作为连接UML 和J ava 的中间语言。为了从特定的UML 模型生成部分CSP2OZ 规约, 定义了一个针对CSP2OZ的UML profile。上述UML 形式化语义的工作将模型映射到一个特定的语义域,如用形式语言Z 规约的面向对象软件系统。用公理来规约面向对象系统的性质,对UML 模型进行推理。

换句话说,现有工作都是针对UML 的功能语义的。每种方法关注面向对象系统的某些性质,对UML 的某个子集做形式化的语义定义。然而,这些方法并不能应用在整个UML 语言上。更重要的是,这些方法没有解决UML 语义定义方面的上述五大难题。这些形式化语义定义方法都对描述语义做了显式或者隐式的假设。此外,现有方法不能将UML 模型自动翻译为形式化规约。

2. 3 　方法概述

本文提出一种新方法来定义UML 模型的形式化语义,显式区分并分别定义描述语义和功能语义。

语义定义为从UML模型到一组一阶逻辑语句的映射。这些一阶逻辑语句用一组基本谓词以及逻辑连接词和量词构造而成。基本谓词与建模语言中的基本概念相对应。例如,一元谓词Class ( x)与UML 中的Class 概念相对应,表示系统中的元素x的类型是Class。UML 元模型用元类表示这些基本概念,并用元类之间的元关联(Meta2Association) 定义基本概念之间的相互联系。我们用一组公理来表示这些联系,称为“描述语义公理”。给定如何对这些基本谓词求值,则可以对一个模型相对应的所有逻辑语句求值,从而可以判断一个系统是否满足此模型,一个系统满足模型当且仅当该模型的所有语句对于该系统为真。

第二,我们将UML的功能语义定义为基本谓词的性质,由一组公理刻画,称为“功能语义公理”。一个模型的功能语义决定了满足此模型的系统的功能和运行时行为。关于UML形式语义的相关工作都旨在定义UML 的功能语义。与相关工作相比较,我们的方法有以下特点:

(1) 区分建模语言的描述语义和功能语义,使得对描述语义的定义独立于主体域。这体现了UML 在实践中的应用,即用一个模型可以同时描述真实世界和信息系统。

(2) 通过在语义定义中引入语境的概念,体现UML的语义的灵活性,即同一语言可以用作软件开发的不同阶段。

(3) 通过将此方法应用于定义UML类图、交互图和状态机图,展示了方法的实际用途。我们的方法提供了一个自然而有效的途径来定义多视图的建模语言,其中多个视图分别由不同而相互关联的元模型定义。

(4) 严格地定义了从UML模型到语义的翻译,实现了对UML 类图、交互图和状态图的翻译工具。虽然我们还没有给出对UML 的完整的语义定义,但其表达能力已进得到了充分的展示。因此,该方法可以同时解决对UML形式化的五大难题。

(5) 语义定义为形式化和自动的对模型的推理提供了逻辑基础。我们将此方法应用到建模中的一个重要问题一致性检查上。

未来工作包括对UML 的功能语义的定义,分析语义定义的逻辑性质,等等。