罗异
(重庆邮电大学软件工程学院,重庆400065)
2001年对象管理组织(Object Management Group,OMG)基于面向对象的思想提出了MDA(Model Driven Architecture)标准[1]。MDA标准强调了模型在软件开发过程中的重要性并将模型转换作为软件开发过程的核心。要使用模型对客观世界进行抽象,必须将模型表示出来。
模型的表示过程实质上完成建模工具的创建和使用建模工具建模两个过程。其中的建模过程基于元建模思想。元对象机制(Meta Object Facility,MOF)是MDA中描述元建模过程的标准。元建模拥有四层经典框架[2],MOF框架套用了经典的元建模四层框架,它将建模语言分为四个层次,分别为M0(信息层)、M1(模型层)、M2(元模型层)和 M3(元-元模型层)[3]。
统一建模语言(Unified Modeling Language,UML)是一种通用的可视化面向对象建模标准。它的目标是为系统架构师、软件工程师和软件开发人员提供分析设计和实现软件系统、建模业务和流程的工具[4]。它包含用于描述系统静态特性的结构模型和描述系统动态特性的行为模型[5]。在基于面向对象思想的建模过程中,UML建模人员使用结构模型中的类图对客观世界进行抽象并实现对象的重用。
面向对象思想将客观世界中的事物看作一个个单独的对象,它的根本目的是实现对象重用。客观世界中的对象数量庞大且复杂,如果对每一个对象进行标识和理解将十分困难。为了解决这个问题,人们往往采用分类和抽象两种基本的思维方式对客观世界中的对象进行认识和实现对象的重用。分类的结果体现了面向对象中继承的思想,抽象的逆过程体现了实例化的思想,因此分类和实例化方式都可以实现对象的重用。
既然继承和实例化两种方式都能实现对象的重用,那么什么情况下使用继承方式实现对象重用和什么情况下使用实例化方式实现对象重用是需要解决问题。
本文针对上述问题,分析了人们通过分类和抽象两种方式认识客观世界的过程以及两种方式与继承和实例化的对应关系。使用集合和映射表示出继承和实例化的数学模型,通过两种方式的数学模型语义相同,给出产生本文主要解决的问题的本质原因。结合类图和类图元模型,分析建模工具设计人员通过继承扩展类图元模型的场景和建模人员通过实例化类图元模型创建类图的场景。以程序自主学习系统中一个实例场景验证方法的可行性。
本节围绕因客观世界中对象数量庞大且复杂导致人们难以标识和理解对象的问题,首先介绍了人们认识客观世界的两种思维方式以及他们分别与继承和实例化的对应关系。然后使用集合和映射表示出继承和实例化的数学模型,最后比较两种方式的数学模型语义并给出在模型表示过程中存在的问题。
分类的方式将客观世界中当前关心的范围(即,论域)中具有相同特性的对象分为一类。每一类形成一个集合,集合中的元素就是客观世界中属于当前分类结果的对象。如果分类后形成的集合中的对象仍然难以理解,人们继续将当前集合中的对象按照上述分类方式,将具有相同特性的对象分为一类并形成新的集合,此时新集合是原集合的子集。理论上来说,根据上述分类过程可以完成任意多次的子集划分,但最终划分的粒度根据实际应用场景决定。
将客观世界中的对象进行分类后形成集合和子集的过程可以解释为面向对象思想中对象之间的继承关系。即当前集合的子集中的对象同时也是当前集合中的对象,但当前集合的子集中的对象除了拥有当前集合的特性外还拥有子集的特性。因此继承的方式使得当前集合的子集中的对象重用了当前集合中对象的特性。
客观世界中普遍存在这种通过分类认识对象的方式。例如,人们将“人”论域中的对象根据性别分为“男人”和“女人”两个集合,“男人”集合中的对象和“女人”集合中的对象都与“人”集合中的对象存在继承关系。再比如,人们将“教职员工”论域中的对象根据教职工类别分类为“任课老师”和“教学管理员”两个集合,“任课老师”集合中的对象和“教学管理员”集合中的对象都与“教职员工”集合中的对象存在继承关系。
使用FacullyStaff表示“教职员工”集合,用fs表示“教职员工”集合中的元素,用Teacher表示“任课老师”集合,用t表示“任课老师”集合中的元素,用Teaching-Manager表示“教学管理员”集合,用tm表示“教学管理员”集合中的元素。则使用集合论表示上述继承关系的语义如下。
如果用 FS表示集合 FacullyStaff,用 fsn(n=0,1,2,3…)表示FacullyStaff集合中的元素,用T表示集合Teacher,用 tn(n=0,1,2,3…)表示 Teacher集合中的元素,用TM表示集合TeachingManager,用tmn(n=0,1,2,3…)表示TeachingManager集合中的元素。可以将上述继承关系的语义通过集合间的包含关系进行表示,得到数学模型如图1所示。
图1 继承的数学模型
其中,t1、t2、t3是集合 T中的元素,tm1和 tm2是集合TM中的元素,fs1、fs2是集合TS中的元素。集合T和集合TM是集合FS的子集,集合TM和集合T中的元素也是集合FS中的元素。集合T中的元素不仅仅具有集合FS的特性,还具有集合T的特性,集合TM中的元素不仅仅具有集合FS的特性,还具有集合TM的特性。
分类的方式对客观世界中具有相同特性的对象分类并形成集合。而抽象的方式将分类形成的一个个集合分别看作一个整体,并将这些整体分别抽象为一个抽象层次更高一级的新对象。如果形成的各个新对象之间具有共同的特征,则可以继续根据上述抽象过程,将这些新对象形成的集合看作一个整体并抽象为抽象层次更高的新对象。理论上来说,可以完成任意多次的抽象过程,但最终抽象的粒度根据实际应用场景决定。
将对象分类后形成的集合看作一个整体并抽象为一个新对象的逆过程可以解释为实例化过程。即一个集合经过抽象形成了一个对象,一个对象经过实例化得到了一个集合且集合中的元素为该对象的实例。因此通过实例化方法使得一个对象可以创建多个新对象,从而实现了对象的重用。
客观世界中普遍存在这种通过抽象认识对象的方式。例如,人们将“人”集合看作一个整体并抽象为一个对象并用字符“人”标识,将其中“男人”子集和“女人”子集两个集合分别看作一个整体后抽象为“男人”对象和“女人”对象。再比如,人们将“教职员工”集合看作一个整体并抽象为一个对象并用字符“教职员工”标识,将其中“任课老师”和“教学管理员”两个子集合分别看作一个整体后抽象为“任课老师”对象和“教学管理员”对象。
用FacullyStaff表示“教职员工”集合,用fs表示“教职员工”集合中的元素,用fsnew表示“教职员工”集合抽象后形成的对象。用Teacher表示“任课老师”集合,用t表示“任课老师”集合中的元素,用tnew表示“任课老师”集合抽象后形成的对象。用TeachingManager表示“教学管理员”集合,用tm表示“教学管理员”集合中的元素,用tmnew表示“教学管理员”抽象后形成的对象。用FS2fsNew表示“教职员工”集合到“教职员工”对象的映射关系,用T2tNew表示“任课老师”集合到“任课老师”对象的映射关系,用TM2tmNew表示“教学管理员”集合到“教学管理员”对象的映射关系。用NewSET表示“教职员工”对象、“任课老师”对象和“教学管理员”对象组成的集合。则使用集合论表示上述实例化关系的语义如下。
用 FS表示集合 FacullyStaff,用 fsn(n=0,1,2,3…)表示FacullyStaff集合中的元素,用T表示集合Teacher,用 tn(n=0,1,2,3…)表示 Teacher集合中的元素,用TM 表示集合 TeachingManager,用 tmn(n=0,1,2,3…)表示TeachingManager集合中的元素。用NS表示集合NewSET,用 nsn(n=0,1,2,3…)表示 NewSET 集合中的元素。可以将上述抽象和实例化的语义可以通过集合和集合间的映射关系进行表示,得到数学模型如图2所示。
图2 实例化的数学模型
其中,ns1、ns2、ns3是集合 NS中的对象,t1、t2、t3是集合T中的对象,tm1、tm2是集合TM中的对象。ns1对象实例化得到集合T,T中的元素是ns1对象的实例;ns3对象实例化得到集合TM,TM中的元素是ns3对象的实例;ns2对象实例化得到集合FS,FS中的元素是ns2对象的实例。
上两节通过数学工具分析了继承和实例化的语义,通过将公式(4)、(5)与公式(9)-(14)比较发现,继承和实例化两种方式都可以表示为集合之间的包含关系,且两种方式的数学语义相同。既然两种方式语义相同并且都可以实现对象的重用,那么什么情况下使用继承方式实现对象重用,什么情况下使用实例化方式实现对象重用是基于MDA思想的软件开发过程中模型的表示环节需要解决的关键问题。
下文首先讨论建模人员建模和建模工具设计人员设计建模工具的方法,分析了建模工具设计人员创建建模工具过程和建模人员使用建模工具建模过程中继承和实例化两种方式实现重用的内容,从而解决了上述问题。
本节围绕模型表示过程中如何在适当的场景选用适当的方法的问题。首先介绍建模人员通过实例化类图元模型创建类图的场景,然后介绍建模工具设计人员通过继承或实例化方式扩展类图的表达能力的场景,最后根据建模人员和建模工具设计人员在模型的表示过程中的分工场景给出结论。
UML建模人员使用类图进行建模实际上完成了在M1模型层对M0信息层的抽象和在M1模型层实例化M2层的元模型两个过程。建模人员首先根据认识客观世界的思维方式对客观世界中的对象进行分类形成M0信息层的一个个集合并将每个集合抽象为M1层类图中一个概念,接着实例化M2层类图元模型中的元元素得到M1层类图中表示上述概念的一个个类、关联和属性等元素。图3展现了该思想。
建模人员将M0层“任课老师”集合抽象为类图中的一个概念并使用符号“任课老师”命名,然后实例化M2层的Class元元素得到M1层类图中代表“任课老师”概念的类;将M0层“教学管理员”集合抽象为类图中的一个类元素并使用符号“教学管理员”命名,然后实例化M2层的Class元元素得到M1层类图中代表“教学管理员”概念的类;将M0层“教职员工”集合抽象为类图中的一个概念并使用符号“教职员工”命名,然后实例化M2层的Class元元素得到M1层类图中代表“教职员工”概念的类;将M0层“学生”集合抽象为类图中的一个概念并使用符号“学生”命名,然后实例化M2层的Class元元素得到M1层类图中代表“学生”概念的类;将M0层“用户”集合抽象为类图中的一个概念并使用符号“用户”命名,然后实例化M2层的Class元元素得到M1层类图中代表“用户”概念的类。
UML是一种通用的可视化面向对象建模标准,它包含用于描述系统静态特性的结构模型和描述系统动态特性的行为模型[5]。为使得UML建模人员能够使用结构模型中的类图对基于面向对象的系统进行描述。必须解决如何对类图进行表示的问题。
元模型是一种建模工具,对于建模人员来说,也可以理解它是一种建模方法。建模人员根据建模方法完成模型的创建。UML建模工具设计人员通过实例化M3层元元模型中的八种元元元素,构建了属于M2层的UML中类图、用例图、时序图和状态图等建模工具。对于大多数场景来说,UML建模人员使用类图、状态图等UML建模工具就可以完成自己的建模工作。但对于特定领域建模,UML建模能力还不够,需要对其进行相应的扩展[5]。
图3 抽象和实例化过程
为使得用类图表示的领域模型中包含单表和主从表模式的语义,对类图的表达能力进行扩展。建模工具人员通过继承的方将对M2层类图的元模型中“Association”元元素进行扩展,增加“masterDetail”扩展属性,使得“Association”元元素的实例具有主从表模式的语义。图4给出扩展结果。
图4 扩展的Association元元素
扩展后的“Association”元元素拥有了“masterDetail”属性,该属性的数据类型为Boolean型,如果该属性值为“True”,表示当前领域模型中的关联实例具有主从表模式的语义;如果如果该属性值为“False”,表示当前领域模型中的关联实例具有单表模式的语义。
实际软件建模工具设计过程中,往往将继承和实例化两种方式结合起来使用。图5表现了实例化和继承两种方式扩展元模型的方式。
图5 实例化和继承的组合使用
M2层元模型通过M3层元元模型描述,如果当前存在的M3层元元模型存在描述能力不足,建模工具设计人员通过继承的方式扩展元元模型的语义。完成元元模型扩展后,建模工具设计人员实例化M3层扩展的元元素,在M2层元模型中得到扩展的元元素的实例。实例化M3层扩展的元元模型得到M2层元模型的过程,实际上实例化了M3层扩展前的元元模型。同理,如果M2层元模型不足描述M1层模型的语义,建模工具设计人员直接通过继承方式在其中的元元素中增加一个属性或增加一个新的元元素,这种方式不改变扩展前的元模型结构。实例化扩展M2层扩展的元模型得到M1层模型的过程,实际上实例化了M2层扩展前的元模型。
根据上述建模人员和建模工具设计人员在模型的表示过程中的分工场景可知,采用继承的方式时,重用者扮演软件建模工具设计人员的角色。他们在M2层通过继承的方式将具有新语义的元元素继承原有的元元素,实现对元模型语义的扩展以及被扩展元元素语义的重用;采用实例化的方式时,重用者扮演软件建模人员的角色。他们通过实例化M2层元模型建立M1层的模型,实现使用模型描述客观世界中的对象、对象的特性和对象与对象之间的关系等。因为实例化过程可以使用相同的建模工具描述不同的应用场景,所以实例化实现了建模工具的重用。建模工具设计人员有时也在M3层采用继承的方式扩展元元模型,然后实例化元元模型得到M2层的元模型,进而建立建模工具。这种方式中建模工具被看作一个模型,建模工具设计人员扮演了建模人员的角色。创建建模工具的过程实际上完成了建模人员通过实例化建立模型的过程。
综上所述,当在基于MDA的软件开发过程中完成实现模型的表示时,如果要对建模工具进行设计,则扮演建模工具设计人员角色,使用继承或继承结合实例化的方式实现重用;如果要对某个特定场景进行建模,则扮演建模人员的角色,使用实例化的方式实现重用。
本节通过程序设计自主学习系统中一个使用继承和实例化对模型进行表示的实例来具体说明如何在适当的情况选用适合的方式完成模型的表示。该实例主要分为两个部分,首先介绍在PD实现平台下建模工具设计人员通过UML Profile机制扩展类图元模型得到类图建模工具;然后介绍建模人员使用扩展后的类图建模工具建模。
《C++程序设计教程》是我校大部分理工科学生的公共基础课程,其教学目的是培养学生的计算思维能力和读程序基本能力。但通过任课老师课堂授课方式难以满足学生学习的要求并且当前存在的自主学习软件也不能完全体现我校教学的特色和重点。因此,根据我校学生的实际情况需设计一个程序设计自主学习系统,为对学习程序设计感兴趣的学生服务。
建模人员在PD中通过其支持的UML Profile机制,使用资源文件编辑器对类图元模型中Association元元素进行扩展,选择“Association”元元素并添加“masterDetail”扩展属性,设置其“Data type”值为“Boolean”。图6展示了扩展属性的创建结果。
图6 创建扩展属性
其次,再在“Association”元元素下添加一个Form,其“Type”值为属性选项卡,并将“masterDetail”扩展属性通过复选框的形式在Tab中进行表示,如果复选框被勾选,表示masterDetail”扩展属性值为True,反之为False,默认值为False。图7展示了添加“masterDetail”扩展属性到属性选项卡后的结果。
图7 在属性选项卡中添加扩展属性
通过上诉两个步骤,建模工具设计人员在PD实现工具中完成了对类图元模型中“Association”元元素的扩展,接下来建模人员就可以使用扩展后的建模工具进行建模。
建模人员在PD中通过实例化类图元模型中的元元素创建描述学生练习和任课教师出题的领域模型,得到的类图表示的领域模型如图8所示。
图8 学生练习和任课教师出题的领域模型
如图9所示,查看领域模型中关联元素的属性,领域模型中的关联元素拥有了主从表模式的语义。建模人员在建模时可以自主选择当前关联元素拥有的语义是主从表模式还是单表模式。
图9 扩展属性的结果展示
在基于MDA的软件开发过程中,分析继承和实例化两种方式的应用场景,进而指导模型的表示过程是本文工作的主要目的。目前国内外研究者在研究基于MDA的软件开发过程中模型的表示时使用到了继承和实例化两种方式。
文献[6]为解决如何在MDA框架下以设计模式为单元进行建模和转换两个问题,扩展CMOF元元模型后得到自己定义的模式单元元模型。通过RolePlay绑定机制,解决了业务模型与模式模型的组合问题和模式单元建模问题。另外,它们在该模式元模型的基础上定义了向EJB平台的转换规则,解决了以模式为单元的转换问题。
文献[7]为解决设计模式建模中存在模式消失和模式组合复杂化等问题,根据MDA和“角色”的建模思想,对设计模式中通用元素的元模型进行了扩展,提出了基于Ecore的设计模式建模以及模型转换的途径,为在MDA框架中围绕设计模式构建模型和实现模型转换提供了一种有效的指导。
文献[8]为解决安全苛求系统通常采用冗余配置来增强系统的可靠性,但是冗余结构增加了安全苛求系统的复杂度。为了解决这个问题,他们通过构造型扩展UML对系统冗余结构的描述并提供一个语义对照表,用来确定模型中的元素、关联和构造型语义以及相对应的故障树实现方法,提出一种与故障树生成相关的系统UML模型扩展方法。
文献[9]为解决统一建模语言的活动图是描述系统功能的强有力的语言,但它缺乏用于区别地捕获上下文感知系统的上下文感知需求的符号等问题,提出了具有新的符号的统一建模语言的活动图的扩展,其使得能够将系统功能进行分离。并通过使用一些真实世界的案例证明了提出的扩展方法的可行性。
文献[10]为了解决特征变更在建模过程导致的涟漪效应以及因此产生新的共性和可变性演化。他们认为现有的分析方法还无法解决这个问题,会导致丢失一些潜在的产品共性,从而影响复用的效率。为了解决上述问题,他们提出了一种特征模型扩展和演化分析方法,该方法通过扩展特征关联关系和模型演化元操作,实现对特征变更涟漪效应的分析,最后通过案例验证该方法的可行性。
上述研究者的研究过程只是讨论了在模型的表示过程中采用继承方式对元模型进行扩展和采用实例化的方式完成模型的创建过程。与上述研究内容相比,本文分析了在模型表示中什么情况下选择继承实现重用,什么情况下选择实例化实现重用,为基于MDA的软件开发过程中模型的表示方法的选择提供了理论基础。
MDA是一种基于模型驱动的软件开发思想,它将模型看作整个开发过程中一个重要的单元,因此完成模型的表示是使用模型推动MDA软件开发过程的前提。本文为了解决在模型表示过程中如何选择继承和实例化方式的问题,分析了人们认识客观世界的思维方式与继承和实例化的对应关系,分析了在模型的表示过程中建模工具设计人员设计建模工具和建模人员使用建模工具建模的场景,给出了合适选用继承,合适选用实例化实现重用的依据。
在下一步工作中,我们将研究如何将通过继承和实例化两种方式表示出的模型应用到基于MDA的模型转换中,使得转换过程能够根据源模型包含的语义转换为目标模型。