南方电网调峰调频发电公司 赵增涛 李定林 佘 俊 王小军
中国能源建设集团广东省电力设计研究院有限公司 赵 磊 唐 凯
一般将业务分析过程中的实体和约束条件称为问题域,业务复杂程度与问题域呈正相关;对问题域的建模需要建模语言具备良好的支持能力,能满足对各种情形的概念约束。UML作为通用建模语言,其所包含的大部分概念都来自面向对象编程语言,而不是应用系统的问题域,这导致UML中的概念与问题域这种的概念存在一定差距。因此很难借助UML满足某些领域业务方面建模的需求,更倾向于针对特定业务领域专项分析,强调从问题域出发,设计适用于业务域的领域特定语言(DSL)。
设计DSL是一项系统性的工作,从最开始的模型抽象层级划分、抽象语法设计,到形成建模驱动框架,开发专用建模工具完成对DSL理论的支撑;整个过程对模型设计人员是很大的挑战,既要具备对问题域的抽象能力,完成对建模的元素设计和语义法则定义形成建模理论;还要具备IT产品设计能力,完成专用建模工具的功能设计。不过,领域特定语言(DSL)方法论提供了理论指导,模型设计人员只需聚焦于问题域的复杂度,抽象出建模需求,然后对主流建模语言UML、MOF理论按需裁剪,便可完成基本的DSL理论雏形。然后基于DSL理论开展专用建模工具的功能设计,实现理论到应用的落地支撑。通常开发DSL的工具称为元建模工具,设计DSL所建的模型称为元模型,而建立DSL元模型并提供或生成支持DSL的建模工具的过程称为元建模。
为规范元建模过程,更好的使用元模型和元数据技术,OMG组织制定了元对象设施MOF(Meta Object Facility)。按照抽象层级将模型划分为四个层级,自上而下依次呈金字塔型分布M3、M2、M1、M0。元-元模型层(M3):是对元-元数据的结构和语义的描述,通俗说就是定义建模的抽象语法,完成语言模型的刻画[1];元模型层(M2):基于定义的抽象语法,完成对元-元数据的描述,由元-元数据非正式地聚合成为元模型;模型层(M1):定义一个具体的系统模型,实质上这个系统模型就是元模型的实例化;信息层(M0):是系统模型在现实中的应用实例,反映真实世界的事物逻辑。
四层元数据体系结构的优势在于通过自下而上的抽象、自上而下的验证原则,能够合理的设计框架。自下而上的抽象是指根据信息层的业务逻辑和数据抽象出共性特征,并对这些特征概念化、规则化形成模型元素;然后根据现有的类和关联向上抽象,概念提炼形成元模型,表征业务间的根本法则。自上而下的推演是指先设计元模型层的类和关联,再衍生定义模型层的类和关联,分析验证元模型的设计合理性。
基于四层元数据体系结构的抽象原则,提出了对应的建模驱动框架,实现从理论到落地的全程支持。整个框架由领域特定语言DSL(设计开发)-元建模工具(资产信息元模型、风险信息元模型、**业务元模型)-建模工具(资产信息模型、风险信息模型、**业务模型)-数字化应用组成。
领域特定语言DSL:元-元模型层(M3)的理论依据,主体采用MOF标准,根据领域自身的建模需求进行适应性裁剪和扩充形成一套完整的建模理论;元建模工具:DSL的开发工具,核心就是将DSL理论可视化、IT化,业务人员借助元建模工具设计产出相关业务元模型(M2);建模工具:实现对业务元模型的解析与实例化。受限于业务元模型的约束,产出对应业务模型(M1),这一步也被称为元模型的实例化;数字化应用:实例化产出的业务模型就是领域建模的终极产物,是数字化应用(M0)运转的依据,反映着现实世界的事物逻辑。
抽象语法定义语言的结构以及它们间的关系也称为语言模型[2]。抽象语法设计要满足对领域内模型概念、模型元素、以及关联法则的制定,形成一套适应于当前领域范畴的DSL理论,支撑领域建模。针对实际业务建模需求,在主流的MOF理论基础上进行了个性化扩充,最终完成抽象语法的设计。主要建模概念包括:
域:界定业务的领域边界。将支撑某类业务领域范畴所需的模型元素划分到一个域下,域内对象间的关联不受限制,不同域间的相互引用则借助跨域关联实现。采用此方式界定领域边界,实现业务的解耦、降低关联复杂度。域的基本特征:名称。领域名称是唯一的;描述。是对业务域的辅助性说明。
包:实现模块化分类,按照业务模块化的需要对模型元素分类整理。包的基本特征:名称。包名是唯一的;子包。支持建立子包,实现结构化分类整理。
类:用来模型化建模的对象。针对建模所处的抽象层级,将类概念进行了细分,M2层定义的类称为“元类”,M1层定义的类称为“类实例”,M1层的类实例是M2层元类的实例化。类的基本特征:名称。类范围内是唯一的;子类。支持生成子类,子类继承父类的属性和关联(为降低M2层模型复杂度,应用中限定M2层类对象无子类特征);是否抽象。用作分类,抽象类不作为关联的目标对象。
关联:用来模型化对象之间的二元联系,描述对象间的必然联系。针对建模所处的抽象层级,将关联概念进行了细分,M2层定义的关联称为“元关联”,M1层定义的关联称为“类关联”,M1层的类关联是M2层元关联的实例化。关联的基本特征:名称。关联范围内是唯一的;基数。描述关联的目标对象数量逻辑,可以是一对一或者一对多;源端。关联的发起方,是一个类对象;目标端。关联目标对象,是一个类对象。关联的基本操作:继承。子类继承父类的关联同时,默认继承父类关联的目标对象集;细化。子类进一步收敛目标对象集;终止。子类终止关联的目标对象。
属性:是对类的固有特征定义。针对建模所处的抽象层级将属性概念进行了细分,M2层定义的属性称为“元属性”,M1层定义的属性称为“类属性”,M2层的元属性是对M1层类属性的抽象定义,M1层类属性完成M1层类实例自身特征的可视化收集。属性的基本特征:名称。属性范围内是唯一的;值域。可以是一个类对象或数据类型。
结构:是以业务注焦点及组织规则为原则,按需的组织类对象搭建形成的业务框架,本质上是基于类和关联的衍生产物。针对建模所处的抽象层级,将结构概念进行了细分,M2层定义的结构称为“元结构”,M1层定义的结构称为“类结构”,M2层的元结构是M1层类结构的框架。结构的基本特征:根节点。一个结构只有一个根节点;节点对象。当前节点允许挂接多个目标节点。
数据类型:用来定义模块化数据,约束属性的值域。包含基本类型和枚举类型,基本类型主要包含常见的整型、串类型、布尔型、浮点型、日期型。枚举类型则是根据业务需求,自定义枚举类型、枚举值。
本案例基于上文的领域信息建模技术研究成果,先开发了一套建模工具,包括元建模及建模;在此基础上,针对电力企业设备设施台账,完成M2层设备设施台账元模型设计,并由设备设施台账元模型实例出M1层设备设施台账模型,自上而下的完成该领域模型设计。
业务上,设备设施台账从功能角度描述资产对象,对资产对象划分为设施类型、功能分组类型、设备类型、成套设备类型、组件类型、部件类型[3-4]。设施类型、功能分组类型、设备类型、成套设备类型间的聚合关联描述功能位置结构模型;组件类型、部件类型则用于描述产品的部件结构模型。其中设备类型、部件类型表示可安装物理设备的节点,其余类型节点主要发挥台账结构的组织作用。通过对业务概念的抽象、提炼,得出M2层的元类概念主要有设施类型、功能分组类型、设备类型、成套设备类型、组件类型、部件类型,并建立元类对象间的关联。
设备设施台账元关联中的元关联名称、源端、目标端分别为:构成设施台账的适用功能分组类型/设施类型/功能分组类型,构成功能分组的功能分组类型/功能分组类型/功能分组类型,构成功能分组的设备类型/功能分组类型/设备类型,构成功能分组的适用成套设备类型/功能分组类型/成套设备类型,构成成套设备的组件类型/成套设备类型/组件类型,构成成套设备的部件类型/成套设备类型/部件类型,构成组件的组件类型/组件类型/组件类型,构成组件的部件类型/组件类型/部件类型,其基数都为一对多。
基于产出的元类和元关联,进一步衍生出设备设施台账元结构(图1)。从而实现对设备设施台账业务的抽象概念定义、以及设备设施台账树的框架定义;最终确定设备设施台账建模的顶层设计,完成设备设施台账元模型设计。
图1 设备设施台账元结构
M2层设备设施台账元模型实现了对元类概念、关联关系、以及元结构框架的定义,M1层则是对这些概念实例化。以元类概念的划分原则,对电力行业设备设施的概念抽象和类型归类,产出M1层的类实例;并受限于元关系的关联法则,合理配置类实例间的联系,最终基于设备设施台账元结构定义的业务框架,产出对应的设备设施台账树,完成M1层设备设施台账模型设计(表1)。
本文基于电力行业领域建模特定需求,扩展了MOF元-元模型理论,完成建模驱动框架设计、元建模及建模的软件开发,并以设备设施台账业务建模为例,展示了领域模型的构建过程。结果表明,基于本文理论搭建的软件具备易用性、直观性、满足电力行业领域建模的支撑应用,并且在多场景下表现出良好的建模支持优势。未来将对元模型与模型同步演化以及版本管理开展进一步研究。
表1 类实例对象
图2 发电厂-设备设施台账树