CN102270137A - 一种获取体系结构描述语言的方法和一种建模工具 - Google Patents
一种获取体系结构描述语言的方法和一种建模工具 Download PDFInfo
- Publication number
- CN102270137A CN102270137A CN2011102288378A CN201110228837A CN102270137A CN 102270137 A CN102270137 A CN 102270137A CN 2011102288378 A CN2011102288378 A CN 2011102288378A CN 201110228837 A CN201110228837 A CN 201110228837A CN 102270137 A CN102270137 A CN 102270137A
- Authority
- CN
- China
- Prior art keywords
- interface
- adl
- dpospl
- attribute
- model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Landscapes
- Stored Programmes (AREA)
Abstract
本发明提供了一种获取体系结构描述语言的方法和一种建模工具,所述的方法包括:首先制定一种能描述产品线变化性的DPOSPL ADL元模型;然后,在DPOSPL ADL中引入变量定义和赋值语法;最后,根据体系结构模型的约束,制定DPOSPL ADL的描述规范;所述的体系结构描述语言支持领域分析后的需求特征模型到体系架构模型的转换,可针对需求特征模型中的可变点快速开发出针对特定需求的实际产品的体系架构。
Description
技术领域
本发明涉及软件工程领域,特别是涉及一种面向数据处理领域的体系结构描述语言和建模工具。
背景技术
当前软件复用的热门方法是领域工程方法,“领域”是指一组具有相似或相近软件需求的应用系统所覆盖的功能区域。领域工程通过对领域中若干成员系统的需求分析的基础上,识别应用系统的共性和可变特,获取一组具有足够可复用性的领域需求,并对其进行抽象,形成领域分析模型(domainanalysis model),依据领域分析模型产生出领域中一类应用系统共同具有的体系结构,即特定领域的软件体系结构(domain specific software architecture,简称DSSA),并以此为基础,识别、开发和组织可复用构件。这样,当开发同一领域中的新应用时,可以根据领域分析模型,确定新应用的需求规约,根据特定领域的软件体系结构形成新应用的设计,并以此为基础选择可复用构件进行组装,从而形成新系统。
数据处理(Data Processing)是对数据的采集、变换、加工、存储、检索,其基本目的是从大量的、杂乱无章的或是难以理解的数据中抽取并推导出有价值、有意义的信息。数据处理贯穿于社会生产和社会生活的各个领域。数据处理离不开软件和保密技术的支持,这些都需要通过数据处理软件来实现。如测绘制图管理软件、仓库管理软件、财会管理软件、交通运输管理软件,技术情报管理软件、办公室自动化系统等。在地理数据方面既有大量自然环境数据(土地、水、气候、生物等各类资源数据),也有大量社会经济数据(人口、交通、工农业等),这些数据采集后都需要进行综合性数据处理。故发展数据处理软件,充分利用数据库技术进行数据管理和处理具有十分重要的社会意义。
数据处理的典型应用场景中,往往要有针对性的数据清洗,把无关的数据、不重要的数据等处理掉。进行适当转换或分类后,就可以根据具体的分析需求选择模式分析的技术,简单的可以只是计算统计数据,也可以是复杂一些的如路径分析、兴趣关联规则、聚类等。最好得出有用的信息,以一个友好的界面如报表图表等,展示给用户。可见数据处理软件的行为是十分相似的,若能把数据处理的功能模块化,加入可定制性,构成数据处理软件产品线,不但能提高软件复用度,也能节约开发时间和开发成本。这也正是数据处理软件产品线(Data Process Oriented Software Product Line,简称DPOSPL)的研究意义所在。
软件体系结构最主要的核心元素有:构件、接口和结构布局。这些元素所组成的软件体系结构模型是对软件产品结构的抽象。形式化语言既能让计算机理解,又有利于分析和代码的生成,于是有了体系结构描述语言的研究。体系结构描述语言(Architecture Description Language,简称ADL)是一种文本的形式化体系结构描述方法。
体系结构描述语言目前还缺乏统一的标准,现有的ADL多应用于某一特定领域,跨领域使用会出现语言描述能力不足,支撑工具无法使用等问题。现有ADL大部分都不支持对产品线的描述,也不具备从产品线体系结构模型中衍生单个产品体系结构的能力。对于数据处理领域而言,目前还缺乏专有的ADL,因此无法快速地进行体系结构建模,若使用其他的通用建模语言如UML等,会导致特征模型转化的不平滑,也不利于后续的代码生成。因此目前需要一种能对数据处理领域软件体系结构进行建模的描述语言,这种ADL要能描述产品线体系结构,能在产品工程中衍生软件家族的产品,同时也要求ADL描述处理的体系结构模型能被DPOSPL所识别和使用,能配合DPOSPL生产过程。
发明内容
本发明所要解决的技术问题是提供一种获取面向数据处理领域的体系结构描述语言的方法,这种ADL能够描述产品线体系结构,能在产品工程中衍生软件家族的产品,同时这种ADL描述的体系结构模型还能被DPOSPL所识别和使用,能配合DPOSPL生产过程。
为了解决上述问题,本发明公开了一种获取面向数据处理领域的体系结构描述语言(Data Process Oriented Software Product Line ArchitectureDescription Language,简称DPOSPL ADL)的方法,包括
首先,制定一种能描述产品线变化性的DPOSPLADL元模型;
所述的DPOSPL ADL元模型覆盖一个体系结构模型的必要元素:构件、接口、构件依赖,同时在元模型中加入描述产品线变化性的元素;元模型中的各元素及元素之间的关系如下:
构件:构件是DPOSPL ADL元模型中最主要的元素,构件有自包含的属性,即构件可以包含若干子构件,形成一个组合结构,这样就实现了体系结构的层次组装;
接口:一个构件包含若干接口,一个接口的描述中包含该接口的生产接口和该生产接口的依赖接口,生产接口和依赖接口之间是一对多的关系;另外接口的描述中还包含xModel描述的URL,这个属性是可选的;
端口:内部构件的接口能通过端口提升到父构件的作用域,端口的描述里包含需要提升的接口以及对应的子构件引用;
构件实现:一个构件对应一个构件实现,组合构件并不需要提供构件实现,而没有组装结构的子构件则需要指定;若不指定,则表示这个构件在构件库里不存在或不确定,有待开发人员进一步指定或完成所缺构件的开发。
通过端口描述中的variability属性实现对于变化性描述的支持;
所述的端口是DPOSPL ADL中把内部构件的接口提升到父构件作用域的元素,传统ADL中它仅代表一种子构件接口的暴露,但在DPOSPL ADL中它还包含了构件组装的变化性的描述,要了解具体需要哪些描述,首先要分析一下体系结构可能出现的变化性;通常来说,构件流程变化性分为4种,可简单归纳为一对一,一对多,多对一和多对多,具体如下:
类型一、单个构件依赖其他的单个构件,这种流程是最直接的,不存在变化性;
类型二、后继多个构件的执行依赖于单个构件的接口,这里从一转多的流程里可以存在变化性,分为两种:1、后继构件之间互相互斥,体系结构绑定后只能存在一个后续构件,即变为类别一的连接状态;2、后继构件之间可共存,体系结构绑定后会有至少一个构件作为后续构件,这些构件在执行上可以不分先后并行执行;
类型三、多个前续构件的接口被单个后继构件所依赖,跟类别二类似,这里前续构件之间也存在两种可变性,互斥或多选;
类型四、多个前续构件的接口被多个后续构件所依赖,这里的变化性分为两组,前续构件为一组,后续构件为一组,这两组的组内再分为互斥和多选两种变化性,跟类别二和类别三类似;
以上所述的四种构件连接类型,分别对应下面的体系结构,这些结构也是DPOSPL ADL所支持和使用的组装结构;
对于类型一,可通过直接的构件结构供需连接完成,并不存在变化点;
对于类型二,单个前续构件的接口被后续若干构件所依赖,这些构件封装到一个父构件,其变化性通过父构件的端口来描述,要么互斥要么多选;另外,如果后续的多个构件均被绑定至产品体系结构时,加入一个父构件负责调用这些后续的构件,同时可以在端口的描述里指定这些后续构件是同时调用还是线性调用;
对于类型三,与类型二相似,把前续构件封装到一个父构件,父构件负责收集前续构件的运行结果,并返回给依赖接口和该接口的构件;
对于类型四,把前续构件与后续构件分别封装到不同的父构件,并以父构件的端口来描述变化性,父构件之间则直接通过接口连接;其中的父子构件组装原理跟类型二和类型三类似。
然后,在DPOSPL ADL中引入变量定义和赋值等语法,并规定其语法规则与JavaScript语法相同;
DPOSPL ADL对体系结构元素的描述是以对象的形式存在的,遵循JavaScript Object Notation规范,简称JSON规范;该规范是一种轻量级的数据交换格式,易于被人阅读和编写也易于被机器解析和生成;体系结构模型元素的具体描述如下:
Component对象:代表一个构件的描述,它包含如下属性:
name:构件的名字,同时也是ADL中对构件的引用名,是必须的属性,该属性为字符串;DPOSPL ADL规范对构件名字的字符没有限制,可以使用中文字符或英文字符,也可以使用标点符号;但考虑到与其他模块的兼容性问题,构件名字推荐只使用英文字符,标点只使用下划线;
description:构件说明,可选属性;这一属性是自由的文本,并不要求结构化;构件描述可以是构件功能的说明,也可以是构件的约束,用于帮助各个后续阶段的开发者了解构件行为;
interfaces:构件接口列表,类型为接口对象的数组;
ports:构件端口列表,类型为端口对象的数组,为可选属性,若构件没有子构件,则此属性应该被忽略;端口的描述实现了构件组装的变化性,是产品线描述的核心所在;
components:子构件列表,类型为构件对象的数组,为可选属性,若构件没有子构件,此属性可忽略;这个属性实现了构件的层次组装结构,为变化性提供基础;
instanceEntrance:构件实现,类型为构件实现的对象,为可选属性;对于一个构件,若构件库里已经包含该功能的构件,则可以把这个构件的实现在这里指定,代码生成时会自动绑定到对应的构件级构架入口;
mandatory:构件是否强制,类型为布尔型,默认为假;这个属性标示该构件在变化点绑定时的选择强制性,只对没有子构件的构件有效;如果该属性为真,变化绑定时必须把它选上,否则无法通过语义检查;
Interface对象:是构件接口的描述,它包含三个主要属性:
provide:生产接口的引用,类型为字符串,必要属性;DPOSPL ADL接口引用跟构件引用类似,规范中没有约束字符串里的字符,但推荐按照常规的程序变量命名规则;
requires:当前接口的依赖接口的列表,类型为接口引用的数组,可选属性,若当前接口没有依赖其他接口,这一属性可以忽略,否则,应该把它们指定出来;
xModel:xModel描述文档的URI,类型为字符串,可选属性,该属性若不指定,在模型转换成代码的时候会缺失接口的数据模型,这时,后续的开发人员应该另行指定;
Port对象:是子构件提升接口到父构件作用域,以及描述变化性的元素;它的属性如下:
promotion:要提升的子构件接口引用,类型为字符串,必要属性;接口可以是生产接口,也可以是依赖接口;
items:当前端口所涉及的子构件引用列表,类型为构件引用数组,必要属性;所有指定的子构件都必须包含promotion中声称的接口,否则无法通过语义检查;
relation:items中构件的关系,类型是变化性枚举,必要属性;实际使用时按字符串输入,但必须是以下三种之一:DIRECT,直接映射,即子构件直接不存在变化性,全部都需要提升到父构件;OR,多选映射,即子构件之间可以选择一个或者多个作为提升的构件,在变化绑定时没有被选择的构件和接口将被忽略;XOR,异或映射,即子构件之间只能选其中之一,它们之间互相排斥;同样的,在变化性绑定时没有被选择的构件和接口将被忽略;
concurrent:子构件调用顺序,布尔类型;Port变化点在绑定后,如果items中的构件存在多个的情况下,用concurrent属性来标示这些构件的调用方式,为真时构件会并行调用,否则线性调用,顺序按声明先后的顺序;
InstanceEntrance对象:是构件实例入口的描述,代表一个构件如何调用;它的属性有以下两个:
path:类路径,字符串类型,必要属性;
operation:方法名,字符串类型,必要属性;
最后,根据体系结构模型的约束,制定DPOSPL ADL的描述规范;所述的DPOSPL ADL的描述规范具体如下:
一个体系结构的描述必须且仅能包含一个根构件,根构件至少要包含一个接口,违反此两条规则,语义检查时将报错;
除根节点外,所有的子构件必须通过接口连接到其他构件或通过端口提升到父构件,否则该构件为游离构件,DPOSPL体系结构模型中允许游离构件的存在,但其所有行为将被忽略;语义检查时应对游离构件作出警告提示,游离构件的存在,允许架构师在设计体系结构的时候不必一次性的把构件完全连接,而是先把构件内部结构设计好,再连接到总的体系结构中,方便体系结构的逐步完善;
一个构件的接口不能依赖于同一个构件的接口,否则属于语义错误;如果实际应用中出现了这样的体系结构模型,正确的描述方法是把这样的构件描述为两个独立的对象,其中一个依赖另外一个构件的接口,这两个构件通过InstanceEntrance指向相同的构件实例;
构件的子构件列表、接口的依赖列表和端口的引用列表均不可以包含相同元素,否则属于描述错误;
端口的items中的项为构件引用,必须满足:1、这些引用必须指向有效的构件,2、这些构件为端口所在构件的子构件;若违反了任何一条,语义检查时会报错;
端口的items中若只包含一个元素,那么端口的relation属性将强制设置为DIRECT,若用户指定了其他值,该值将被忽略并在语义检查时提出警告;
体系结构绑定必须基于一个符合语法和语义规范的体系结构描述,否则最后得出的模型以及行为不可预知;
一个构件可能包含多个端口,而items是构件引用,所以这些端口中的items可能会出现指向同一个构件的引用;在变化绑定时,当一个端口的变化项被选择了而该变化项对应的构件引用在端口的items列表中时,对应的变化项也要被选中;若违反这一规则,绑定后可能会出现游离构件或游离构件群,致使产品绑定模型失效;
若端口类型为DIRECT,则所有items里的构件,均需要被选择,否则得出的绑定模型是错误的;
若端口类型为OR,则变化项只能选其中之一,若类型为XOR,则变化项可以选任意多个,但若选项中的构件的mandatory属性为真时,该项必须选中,否则错误。
相应的,本发明还提供了一种基于DPOSPL ADL的建模工具,所述的DPOSPL ADL建模工具按功能可分为四个主要模块:语言模型模块,解析模块,模型编辑模块,生成器模块。
所述的语言模型模块包含类Component、Interface、Instance和Port,分别对应DPOSPL ADL的元概念;DPOSPL ADL元概念中,构件支持层次组装,所以Component类是自包含的,有一个子构件列表,DPOSPL ADL中默认情况下的列表为空列表但不是null,其他类的列表结构,如没特别说明,都遵循这个规则;构件与子构件之间能产生接口提升,这是通过Port类实现的,一个构件能有多个端口,所以这里Component包含的是一个Port的列表,Port类中包含要提升的接口信息还有要提升的构件引用,同时,变化性信息也包含在Port里;一个构件能有多个接口,所以Component还包含一个Interface列表,对于一个Interface,包含生产接口和该生产接口的依赖接口列表,还包含xModel的信息;语言模块是其他模块的基础,具体表现为其他模块的类对Component类的依赖。
所述的解析模块包含解析器,解析器都遵循Parser接口,该接口里主要的方法是以ADL文本为输入,解析后返回一个Component的结构,即对象引用;目前DPOSPLADL提供两个解析器,分别是JavaScript解析器和JSON解析器,前者能运行一段JavaScript脚本,然后提取其中名为root的变量,形成Component结构;而JSON解析器则把一段JSON的描述文本转换成Component结构,不具备脚本执行功能;解析模块是模型编辑模块和生成器模块的基础,为它们提供可用的Component对象。
所述的模型编辑模块包含可视化编辑器和变化绑定器;DPOSPL ADL工具的可视化编辑器是基于Prefuse来开发的,目前仅具备模型查看的功能,还不能做到双向的模型查看和修改,但由于Prefuse是一个交互式的数据可视化工具,要实现模型可视化编辑是完全可以的,可以考虑在日后扩展中完善这部分功能;另一方面,变化绑定器负责把体系结构模型中的可变点显示出来,Binder里有一个树状机构能对体系结构模型以树状形式展现,同时这个树状结构还能把可变点以单选框和多选框的形式显示在相应的树结点上,这样架构师就能通过对这些选框进行选择,完成体系结构绑定;经过绑定后的体系结构模型同样以一个Component结构来表示,不同的是其里面的变化性已经消除,可以作为代码生成器的输入,进行代码生成。
所述的生成器模块包含各种代码生成器,它们都是Generator接口的实现,Generator接口里有一个主要的方法,它以Component对象的引用和文档输出路径为输入,执行后会把所生成的文档输出到指定路径上;DPOSPLADL建模工具目前实现了的生成器包括DPOSPLProjectGenerator,JavaGenerator,GraphMLGenerator;由于建模工具要应用于DPOSPL工程的生成流程里,所以DPOSPLProjectGenerator是最主要的代码生成器,它负责根据体系结构绑定模型生成DPOSPL IDE软件模型描述,这个描述主要包含三个XML文档,第一个是用户界面及数据模型描述文档,后缀名为gux,这个文档记录了软件中的界面元素属性,如界面中使用什么控件,控件的位置和数据模型的绑定路径等,而数据模型则是过程与界面之间数据交换的格式信息;第二个是过程文档,后缀名pex,它记录的是构件流程信息以及构件与构件实例的绑定信息;第三个是产品组装概览,扩展名cpx,在有了界面和过程之后,通过产品概览文档把它们之间的调用关系描述出来;DPOSPLProjectGenerator从体系结构绑定模型中提取接口的xModel信息,生成gux文件中的数据模型描述,根据构件连接信息,生成过程描述文档,即pex文件,再根据接口的生产依赖关系,生成产品组装概览,即cpx文件;DPOSPL IDE能产生两种类型的应用,分别是桌面应用和Web应用。
与现有技术相比,本发明具有以下优点:
第一、支持产品线描述。产品线体系结构变化性分为两个层次:体系结构级变化性和构件级变化性。体系结构级变化性是指产品线体系结构中包含变化构件,即具有结构变化性。构件级变化性是指其内部组件具有变化的行为语义或者结构。DPOSPL ADL能够同时描述这多种类型的产品线体系结构变化性,并对变化性关系进行约束;能够分析产品线体系结构内部变化组件之间的依赖、共存、互斥等多种相互约束关系。
第二、支持DPOSPL生产过程。DPOSPL ADL支持从DPOSPL特征模型到体系结构模型的转换,支持特征绑定模型到体系结构绑定模型的转换。支持代码生成,且支持DPOSPL体系结构模型到DPOSPL桌面应用和Web应用的软件模型的转化。在软件产品线环境下,根据体系结构描述,结合系统配置与约束,生成目标环境的代码框架,胶合代码,连接构件,进行组装。
第三、具有领域特定与领域独立相结合的描述能力。DPOSPL ADL既能适应特定领域的系统结构的描述,特别是数据处理领域软件系统的描述,同时不失一般性地,也能描述其他领域的软件产品。传统的面向某一领域的ADL,在识别出特定领域概念后,会把元模型实例化成特定领域概念模型,进而进行系统建模并描述,这样导致ADL位于上层的元模型也带有领域特性,虽然能更快捷地适应该领域的建模需求,但却丢失了ADL的通用性。而DPOSPL ADL除了能满足数据处理领域的建模需求外,还具备一般性,能让其他领域的架构师用于建模,提高了语言本身的可复用性。
第四、具有较长的体系结构模型生命周期。DPOSPL体系结构模型是一个产品家族的模型,这个模型能演化出产品家族内的任意一个产品。DPOSPL体系结构模型具备较长的生命周期,减小了因修改模型所带来的代价。
附图说明
图1是本发明实施例中DPOSPL ADL的元模型;
图2是本发明实施例中构件连接变化性的示意图;
图3是本发明实施例中变化性类型一对应的组装结构;
图4是本发明实施例中变化性类型二对应的组装结构;
图5是本发明实施例中变化性类型三对应的组装结构;
图6是本发明实施例中变化性类型四对应的组装结构;
图7是本发明实施例中一个Component对象的描述实例;
图8是本发明实施例中一个Interface对象的描述实例;
图9是本发明实施例中一个Port对象的描述实例。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本发明作进一步详细的说明。
首先,制定一种能描述产品线变化性的DPOSPL ADL元模型。
设计一种产品线描述语言,关键在于如何描述特征模型中的可变点以及如何实现可变点的绑定,实现经过产品线体系结构模型中变点的绑定到体系结构绑定模型的转换。
目前,传统的绝大部分ADL都不支持产品线建模。在DPOSPL ADL中,我们把变化性描述元素加入到元模型中,使它能支持产品线的描述。
参照图1,本发明实施例中的DPOSPL ADL的元模型。所述元模型覆盖了一个体系结构模型的构件,接口,构件依赖等必要元素,同时也加入了产品线变化性的描述元素。所述元模型中的各元素及元素之间的关系如下:
构件(Component):构件是DPOSPL ADL的元模型中最主要的元素,构件有自包含的属性,即构件可以包含若干子构件,形成一个组合结构,这样就实现了体系结构的层次组装。
接口(Interface):一个构件包含若干接口,一个接口的描述中包含该接口的生产接口(provide)和该生产接口依赖的接口(require),生产接口和依赖接口之间是一对多的关系。另外接口的描述中还包含xModel描述的URL,这个属性是可选的。
端口(Port):内部构件的接口能通过端口提升到父构件的作用域,端口的描述里包含需要提升的接口(promotion)以及对应的子构件引用(ComponentRef)。
构件实现(ComInstance):一个构件对应一个构件实现,通常情况下,组合构件并不需要提供构件实现,而没有组装结构的子构件则需要指定。若不指定,则表示这个构件在构件库里不存在或不确定,有待开发人员进一步指定或完成所缺构件的开发。
DPOSPL ADL元模型中对于变化性描述的支持是通过端口描述中的variability属性来实现的。而端口是DPOSPL ADL中把内部构件的接口提升到父构件作用域的元素,传统ADL中它仅代表一种子构件接口的暴露,但在DPOSPL ADL中它还包含了构件组装的变化性的描述,要了解具体需要哪些描述,首先要分析一下体系结构可能出现的变化性。
通常来说,构件流程变化性分为4种,可简单归纳为一对一,一对多,多对一和多对多。参照图2,具体如下:
类型一、单个构件依赖其他的单个构件,这种流程是最直接的,不存在变化性。
类型二、后继多个构件(构件2和3)的执行依赖于单个构件(构件1)的接口,这里从一转多的流程里可以存在变化性,分为两种:1、后继构件之间互相互斥,体系结构绑定后只能存在一个后续构件,即变为类别一的连接状态;2、后继构件之间可共存,体系结构绑定后会有至少一个构件作为后续构件,这些构件在执行上可以不分先后并行执行。
类型三、多个前续构件(构件1和2)的接口被单个后继构件(构件3)所依赖,跟类别二类似,这里前续构件之间也存在两种可变性,互斥或多选。
类型四、多个前续构件(构件1和2)的接口被多个后续构件(构件3和4)所依赖,这里的变化性应该分为两组,前续构件为一组,后续构件为一组,这两组的组内再分为互斥和多选两种变化性,跟类别二和类别三类似。
以上所述的四种构件连接类型,分别对应下面的体系结构,这些结构也是DPOSPL ADL所支持和使用的组装结构。
参照图3,对于类型一,可通过直接的构件结构供需连接完成,并不存在变化点。
参照图4,对于类型二,构件1的接口被后续若干构件所依赖,这些构件封装到一个父构件,其变化性通过父构件的端口来描述,要么互斥要么多选。另外,如果后续的多个构件均被绑定至产品体系结构时,如果不对其行为作出定义,这个体系结构就会含糊不清,后续构件没有一个调用顺序,也没有指定谁来调用。DPOSPL ADL的这种结构就是为解决这个问题而设计的,这里加入一个父构件负责调用这些后续的构件,同时可以在端口的描述里指定这些后续构件是同时调用还是线性调用。
参照图5,对于类型三,与类型二相似。把前续构件封装到一个父构件,父构件负责收集前续构件的运行结果,并返回给依赖接口和该接口的构件。值得注意的是,虽然这里存在一个父构件,但在DPOSPL平台中,类型二和类型三的这些构件间信息传递均由平台引擎完成,也就是说,这个父构件本质上代表了引擎的一部分功能。
参照图6,对于类型四,把前续构件与后续构件分别封装到不同的父构件,并以父构件的端口来描述变化性,父构件之间则直接通过接口连接。其中的父子构件组装原理跟类型二和类型三类似。
然后,在DPOSPL ADL引入了变量定义和赋值等语法,语法规则跟JavaScript语法相同。这是因为传统的ADL不管是自定义的语法格式还是XML的格式,当构件组装的层次很深的时候,会造成描述语言的嵌套结构过于复杂,虽然对机器识别影响不大,但却十分不利于语言的使用和修改。
DPOSPL ADL对体系结构元素的描述是以对象的形式存在的,遵循JSON(JavaScript Object Notation)规范;该规范是一种轻量级的数据交换格式,易于被人阅读和编写也易于被机器解析和生成;体系结构模型元素的具体描述如下:
Component对象:代表一个构件的描述,它包含如下属性:
name:构件的名字,同时也是ADL中对构件的引用名,是必须的属性,该属性为字符串。DPOSPL ADL规范对构件名字的字符没有限制,可以使用中文字符或英文字符,也可以使用标点符号。但考虑到与其他模块的兼容性问题,构件名字推荐只使用英文字符,标点只使用下划线。
description:构件说明,可选属性。这一属性是自由的文本,并不要求结构化。构件描述可以是构件功能的说明,也可以是构件的约束,用于帮助各个后续阶段的开发者了解构件行为。
interfaces:构件接口列表,类型为接口对象的数组。
ports:构件端口列表,类型为端口对象的数组,为可选属性,若构件没有子构件,则此属性应该被忽略。端口的描述实现了构件组装的变化性,是产品线描述的核心所在。
components:子构件列表,类型为构件对象的数组,为可选属性,若构件没有子构件,此属性可忽略。这个属性实现了构件的层次组装结构,为变化性提供基础。
instanceEntrance:构件实现,类型为构件实现的对象,为可选属性。对于一个构件,若构件库里已经包含该功能的构件,则可以把这个构件的实现在这里指定,代码生成时会自动绑定到对应的构件级构架入口。
mandatory:构件是否强制,类型为布尔型,默认为假。这个属性标示该构件在变化点绑定时的选择强制性,只对没有子构件的构件有效。如果该属性为真,变化绑定时必须把它选上,否则无法通过语义检查。
参照图7,是一个Component对象的描述实例。
Interface对象:是构件接口的描述,它包含三个主要属性:
provide:生产接口的引用,类型为字符串,必要属性。DPOSPL ADL接口引用跟构件引用类似,规范中没有约束字符串里的字符,但推荐按照常规的程序变量命名规则。
requires:当前接口的依赖接口的列表,类型为接口引用的数组,可选属性,若当前接口没有依赖其他接口,这一属性可以忽略,否则,应该把它们指定出来。
xModel:xModel描述文档的URI,类型为字符串,可选属性,该属性若不指定,在模型转换成代码的时候会缺失接口的数据模型,这时,后续的开发人员应该另行指定。
参照图8,是一个Interface对象的描述实例。
Port对象:是子构件提升接口道父构件作用域,以及描述变化性的元素。它的属性如下:
promotion:要提升的子构件接口引用,类型为字符串,必要属性。接口可以是生产接口,也可以是依赖接口。
items:当前端口所涉及的子构件引用列表,类型为构件引用数组,必要属性。所有指定的子构件都必须包含promotion中声称的接口,否则无法通过语义检查。
relation:items中构件的关系,类型是变化性枚举,必要属性。实际使用时按字符串输入,但必须是以下三种之一:DIRECT,直接映射,即子构件直接不存在变化性,全部都需要提升到父构件;OR,多选映射,即子构件之间可以选择一个或者多个作为提升的构件,在变化绑定时没有被选择的构件和接口将被忽略;XOR,异或映射,即子构件之间只能选其中之一,它们之间互相排斥。同样的,在变化性绑定时没有被选择的构件和接口将被忽略。
concurrent:子构件调用顺序,布尔类型。Port变化点在绑定后,如果items中的构件存在多个的情况下,用concurrent属性来标示这些构件的调用方式,为真时构件会并行调用,否则线性调用,顺序按声明先后的顺序。
参照图9,是一个Port对象的描述实例。
InstanceEntrance对象:是构件实例入口的描述,代表一个构件如何调用。它的属性有以下两个:
path:类路径,字符串类型,必要属性。
operation:方法名,字符串类型,必要属性。
为方便架构师编写,InstanceEntrance在编写时可使用一个整的字符串,如edu.tsinghua.www.dpospl.adl.operation,解析器将最后的operation解析出来,把之前的部分作为path属性的值。当然也可以使用正常的JSON结构来描述。
最后,根据DPOSPL体系结构模型的约束,制定DPOSPL ADL的描述规范。描述规范具体如下:
一个体系结构的描述必须且仅能包含一个根构件,根构件至少要包含一个接口,违反此两条规则,语义检查时将报错。
除根节点外,所有的子构件必须通过接口连接到其他构件或通过端口提升到父构件,否则该构件为游离构件,DPOSPL体系结构模型中允许游离构件的存在,但其所有行为将被忽略。语义检查时应对游离构件作出警告提示,游离构件的存在,允许架构师在设计体系结构时候不必一次性的把构件完全连接,而是先把构件内部结构设计好,再连接到总的体系结构中,方便体系结构的逐步完善。
一个构件的接口不能依赖于同一个构件的接口,否则属于语义错误。如果实际应用中出现了这样的体系结构模型,正确的描述方法是把这样的构件描述为两个独立的对象,其中一个依赖另外一个构件的接口,这两个构件通过InstanceEntrance指向相同的构件实例。
构件的子构件列表、接口的依赖列表和端口的引用列表(items)均不可以包含相同元素,否则属于描述错误。
端口的items中的项为构件引用,必须满足1、这些引用必须指向有效的构件,2、这些构件为端口所在构件的子构件;若违反了任何一条,语义检查时会报错。
端口的items中若只包含一个元素,那么端口的relation属性将强制设置为DIRECT,若用户指定了其他值,该值将被忽略并在语义检查时提出警告。
体系结构绑定必须基于一个符合语法和语义规范的体系结构描述,否则最后得出的模型以及行为不可预知。
一个构件可能包含多个端口,而items是构件引用,所以这些端口中的items可能会出现指向同一个构件的引用。在变化绑定时,当一个端口的变化项被选择了而该变化项对应的构件引用在端口的items列表中时,对应的变化项也要被选中。若违反这一规则,绑定后可能会出现游离构件或游离构件群,致使产品绑定模型失效。
若端口类型为DIRECT,则所有items里的构件(即变化项),均需要被选择,否则得出的绑定模型是错误的。
若端口类型为OR,则变化项只能选其中之一,若类型为XOR,则变化项可以选任意多个,但若选项中的构件的mandatory属性为真时,该项必须选中,否则错误。
本发明还提供了一种面向数据处理领域的建模工具。
所述DPOSPL ADL建模工具主要应用于领域工程中的产品线体系结构建模,以及产品工程中的体系结构绑定。
所述的DPOSPL ADL建模工具按功能可分为四个主要模块:语言模型模块,解析模块,模型编辑模块,生成器模块。
语言模型模块,其特征在于,该模块包含类Component、Interface、Instance和Port,分别对应DPOSPL ADL的元概念。DPOSPL ADL元概念中,构件支持层次组装,所以Component类是自包含的,有一个子构件列表,DPOSPLADL中默认情况下的列表为空列表但不是null,其他类的列表结构,如没特别说明,都遵循这个规则。构件与子构件之间能产生接口提升,这是通过Port类实现的,一个构件能有多个端口,所以这里Component包含的是一个Port的列表,Port类中包含要提升的接口信息还有要提升的构件引用,同时,变化性信息也包含在Port里。一个构件能有多个接口,所以Component还包含一个Interface列表,对于一个Interface,包含生产接口和该生产接口的依赖接口列表,还包含xModel的信息。语言模块是其他模块的基础,具体表现为其他模块的类对Component类的依赖。
解析模块,其特征在于,解析模块里包含解析器,解析器都遵循Parser接口,该接口里主要的方法是以ADL文本为输入,解析后返回一个Component的结构,即对象引用。目前DPOSPL ADL提供两个解析器,分别是JavaScript解析器和JSON解析器,前者能运行一段JavaScript脚本,然后提取其中名为root的变量,形成Component结构。而JSON解析器则把一段JSON的描述文本转换成Component结构,不具备脚本执行功能。解析模块是模型编辑模块和生成器模块的基础,为它们提供可用的Component对象。
模型编辑模块,其特征在于,该模块里包含可视化编辑器和变化绑定器。DPOSPL ADL工具的可视化编辑器是基于Prefuse来开发的,目前仅具备模型查看的功能,还不能做到双向的模型查看和修改,但由于Prefuse是一个交互式的数据可视化工具,要实现模型可视化编辑是完全可以的,可以考虑在日后扩展中完善这部分功能。另一方面,变化绑定器负责把体系结构模型中的可变点显示出来,Binder里有一个树状机构能对体系结构模型以树状形式展现,同时这个树状结构还能把可变点以单选框和多选框的形式显示在相应的树结点上,这样架构师就能通过对这些选框进行选择,完成体系结构绑定。经过绑定后的体系结构模型同样以一个Component结构来表示,不同的是其里面的变化性已经消除,可以作为代码生成器的输入,进行代码生成。
生成器模块,其特征在于,代码生成模块里包含各种代码生成器,它们都是Generator接口的实现,Generator接口里有一个主要的方法,它以Component对象的引用和文档输出路径为输入,执行后会把所生成的文档输出到指定路径上。DPOSPL ADL建模工具目前实现了的生成器包括DPO SPLProjectGenerator,JavaGenerator,GraphMLGenerator,但除第一个生成器外,其他生成器都已经日久失修,问题过多,不建议使用。由于建模工具要应用于DPOSPL工程的生成流程里,所以DPOSPLProjectGenerator是最主要的代码生成器,它负责根据体系结构绑定模型生成DPOSPL IDE软件模型描述,这个描述主要包含三个XML文档,第一个是用户界面及数据模型描述文档,后缀名为gux,这个文档记录了软件中的界面元素属性,如界面中使用什么控件,控件的位置和数据模型的绑定路径等,而数据模型则是过程与界面之间数据交换的格式信息。第二个是过程文档,后缀名pex,它记录的是构件流程信息以及构件与构件实例的绑定信息。第三个是产品组装概览,扩展名cpx,在有了界面和过程之后,通过产品概览文档把它们之间的调用关系描述出来。DPOSPLProjectGenerator从体系结构绑定模型中提取接口的xModel信息,生成gux文件中的数据模型描述,根据构件连接信息,生成过程描述文档,即pex文件,再根据接口的生产依赖关系,生成产品组装概览,即cpx文件。DPOSPL IDE能产生两种类型的应用,分别是桌面应用和Web应用。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。对于系统实施例而言,由于其与方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
以上对本发明所提供的一种面向数据处理领域的体系结构描述语言,以及一种面向数据处理领域的建模工具进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。
Claims (10)
1.一种获取面向数据处理领域体系结构描述语言DPOSPL ADL的方法,其特征在于,包括:
首先,制定一种能描述产品线变化性的DPOSPL ADL元模型;
然后,引入变量定义和赋值语法;
最后,根据体系结构模型的约束,制定DPOSPL ADL的描述规范。
2.如权利要求1所述的方法,其特征在于,制定的DPOSPL ADL元模型覆盖一个体系结构模型的必要元素:构件、接口、构件依赖,同时在元模型中加入描述产品线变化性的元素;
所述元模型中的各元素及元素之间的关系如下:
构件:构件是DPOSPL ADL元模型中最主要的元素,构件有自包含的属性,即构件可以包含若干子构件,形成一个组合结构,这样就实现了体系结构的层次组装;
接口:一个构件包含若干接口,一个接口的描述中包含该接口的生产接口和该生产接口的依赖接口,生产接口和依赖接口之间是一对多的关系;另外接口的描述中还包含xModel描述的URI,这个属性是可选的;
端口:内部构件的接口能通过端口提升到父构件的作用域,端口的描述里包含需要提升的接口以及对应的子构件引用;
构件实现:一个构件对应一个构件实现,组合构件并不需要提供构件实现,而没有组装结构的子构件则需要指定;若不指定,则表示这个构件在构件库里不存在或不确定,有待开发人员进一步指定或完成所缺构件的开发。
3.如权利要求2所述的方法,其特征在于,通过端口描述中的variability属性实现对于变化性描述的支持;
所述的端口是DPOSPL ADL中把内部构件的接口提升到父构件作用域的元素,传统ADL中它仅代表一种子构件接口的暴露,但在DPOSPL ADL中它还包含了构件组装的变化性的描述,要了解具体需要哪些描述,首先要分析一下体系结构可能出现的变化性;通常来说,构件流程变化性分为4种,可简单归纳为一对一,一对多,多对一和多对多,具体如下:
类型一、单个构件依赖其他的单个构件,这种流程是最直接的,不存在 变化性;
类型二、后继多个构件的执行依赖于单个构件的接口,这里从一转多的流程里可以存在变化性,分为两种:1、后继构件之间互相互斥,体系结构绑定后只能存在一个后续构件,即变为类别一的连接状态;2、后继构件之间可共存,体系结构绑定后会有至少一个构件作为后续构件,这些构件在执行上可以不分先后并行执行;
类型三、多个前续构件的接口被单个后继构件所依赖,跟类别二类似,这里前续构件之间也存在两种可变性,互斥或多选;
类型四、多个前续构件的接口被多个后续构件所依赖,这里的变化性分为两组,前续构件为一组,后续构件为一组,这两组的组内再分为互斥和多选两种变化性,跟类别二和类别三类似;
以上所述的四种构件连接类型,分别对应下面的体系结构,这些结构也是DPOSPL ADL所支持和使用的组装结构;
对于类型一,可通过直接的构件结构供需连接完成,并不存在变化点;
对于类型二,单个前续构件的接口被后续若干构件所依赖,这些构件封装到一个父构件,其变化性通过父构件的端口来描述,要么互斥要么多选;另外,如果后续的多个构件均被绑定至产品体系结构时,加入一个父构件负责调用这些后续的构件,同时可以在端口的描述里指定这些后续构件是同时调用还是线性调用;
对于类型三,与类型二相似,把前续构件封装到一个父构件,父构件负责收集前续构件的运行结果,并返回给依赖接口和该接口的构件;
对于类型四,把前续构件与后续构件分别封装到不同的父构件,并以父构件的端口来描述变化性,父构件之间则直接通过接口连接;其中的父子构件组装原理跟类型二和类型三类似。
4.如权利要求1所述的方法,其特征在于,在DPOSPL ADL中引入变量定义和赋值等语法,并规定其语法规则与JavaScript语法相同;
DPOSPL ADL对体系结构元素的描述是以对象的形式存在的,遵循 JavaScript Object Notation规范,简称JSON规范;该规范是一种轻量级的数据交换格式,易于被人阅读和编写也易于被机器解析和生成;体系结构模型元素的具体描述如下:
Component对象:代表一个构件的描述,它包含如下属性:
name:构件的名字,同时也是ADL中对构件的引用名,是必须的属性,该属性为字符串;DPOSPL ADL规范对构件名字的字符没有限制,可以使用中文字符或英文字符,也可以使用标点符号;但考虑到与其他模块的兼容性问题,构件名字推荐只使用英文字符,标点只使用下划线;
description:构件说明,可选属性;这一属性是自由的文本,并不要求结构化;构件描述可以是构件功能的说明,也可以是构件的约束,用于帮助各个后续阶段的开发者了解构件行为;
interfaces:构件接口列表,类型为接口对象的数组;
ports:构件端口列表,类型为端口对象的数组,为可选属性,若构件没有子构件,则此属性应该被忽略;端口的描述实现了构件组装的变化性,是产品线描述的核心所在;
components:子构件列表,类型为构件对象的数组,为可选属性,若构件没有子构件,此属性可忽略;这个属性实现了构件的层次组装结构,为变化性提供基础;
instanceEntrance:构件实现,类型为构件实现的对象,为可选属性;对于一个构件,若构件库里已经包含该功能的构件,则可以把这个构件的实现在这里指定,代码生成时会自动绑定到对应的构件级构架入口;
mandatory:构件是否强制,类型为布尔型,默认为假;这个属性标示该构件在变化点绑定时的选择强制性,只对没有子构件的构件有效;如果该属性为真,变化绑定时必须把它选上,否则无法通过语义检查;
Interface对象:是构件接口的描述,它包含三个主要属性:
provide:生产接口的引用,类型为字符串,必要属性;DPOSPL ADL接口引用跟构件引用类似,规范中没有约束字符串里的字符,但推荐按照常规的程序变量命名规则;
requires:当前接口的依赖接口的列表,类型为接口引用的数组,可选属性,若当前接口没有依赖其他接口,这一属性可以忽略,否则,应该把它们指定出来;
xModel:xModel描述文档的URI,类型为字符串,可选属性,该属性若不指定,在模型转换成代码的时候会缺失接口的数据模型,这时,后续的开发人员应该另行指定;
Port对象:是子构件提升接口到父构件作用域,以及描述变化性的元素;它的属性如下:
promotion:要提升的子构件接口引用,类型为字符串,必要属性;接口可以是生产接口,也可以是依赖接口;
items:当前端口所涉及的子构件引用列表,类型为构件引用数组,必要属性;所有指定的子构件都必须包含promotion中声称的接口,否则无法通过语义检查;
relation:items中构件的关系,类型是变化性枚举,必要属性;实际使用时按字符串输入,但必须是以下三种之一:DIRECT,直接映射,即子构件直接不存在变化性,全部都需要提升到父构件;OR,多选映射,即子构件之间可以选择一个或者多个作为提升的构件,在变化绑定时没有被选择的构件和接口将被忽略;XOR,异或映射,即子构件之间只能选其中之一,它们之间互相排斥;同样的,在变化性绑定时没有被选择的构件和接口将被忽略;
concurrent:子构件调用顺序,布尔类型;Port变化点在绑定后,如果items中的构件存在多个的情况下,用concurrent属性来标示这些构件的调用方式,为真时构件会并行调用,否则线性调用,顺序按声明先后的顺序;
InstanceEntrance对象:是构件实例入口的描述,代表一个构件如何调用;它的属性有以下两个:
path:类路径,字符串类型,必要属性;
operation:方法名,字符串类型,必要属性。
5.如权利要求1所述的方法,其特征在于,所述的DPOSPL ADL的描 述规范具体如下:
一个体系结构的描述必须且仅能包含一个根构件,根构件至少要包含一个接口,违反此两条规则,语义检查时将报错;
除根节点外,所有的子构件必须通过接口连接到其他构件或通过端口提升到父构件,否则该构件为游离构件,DPOSPL体系结构模型中允许游离构件的存在,但其所有行为将被忽略;语义检查时应对游离构件作出警告提示,游离构件的存在,允许架构师在设计体系结构的时候不必一次性的把构件完全连接,而是先把构件内部结构设计好,再连接到总的体系结构中,方便体系结构的逐步完善;
一个构件的接口不能依赖于同一个构件的接口,否则属于语义错误;如果实际应用中出现了这样的体系结构模型,正确的描述方法是把这样的构件描述为两个独立的对象,其中一个依赖另外一个构件的接口,这两个构件通过InstanceEntrance指向相同的构件实例;
构件的子构件列表、接口的依赖列表和端口的引用列表均不可以包含相同元素,否则属于描述错误;
端口的items中的项为构件引用,必须满足:1、这些引用必须指向有效的构件,2、这些构件为端口所在构件的子构件;若违反了任何一条,语义检查时会报错;
端口的items中若只包含一个元素,那么端口的relation属性将强制设置为DIRECT,若用户指定了其他值,该值将被忽略并在语义检查时提出警告;
体系结构绑定必须基于一个符合语法和语义规范的体系结构描述,否则最后得出的模型以及行为不可预知;
一个构件可能包含多个端口,而items是构件引用,所以这些端口中的items可能会出现指向同一个构件的引用;在变化绑定时,当一个端口的变化项被选择了而该变化项对应的构件引用在端口的items列表中时,对应的变化项也要被选中;若违反这一规则,绑定后可能会出现游离构件或游离构件群,致使产品绑定模型失效;
若端口类型为DIRECT,则所有items里的构件,均需要被选择,否则得出的绑定模型是错误的;
若端口类型为OR,则变化项只能选其中之一,若类型为XOR,则变化项可以选任意多个,但若选项中的构件的mandatory属性为真时,该项必须选中,否则错误。
6.一种DPOSPL ADL建模工具,其特征在于,所述的DPOSPL ADL建模工具按功能可分为四个主要模块:语言模型模块,解析模块,模型编辑模块,生成器模块。
7.如权利6所述的DPOSPL ADL建模工具,其特征在于,语言模型模块包含类Component、Interface、Instance和Port,分别对应DPOSPL ADL的元概念;DPOSPL ADL元概念中,构件支持层次组装,所以Component类是自包含的,有一个子构件列表,DPOSPL ADL中默认情况下的列表为空列表但不是null,其他类的列表结构,如没特别说明,都遵循这个规则;构件与子构件之间能产生接口提升,这是通过Port类实现的,一个构件能有多个端口,所以这里Component包含的是一个Port的列表,Port类中包含要提升的接口信息还有要提升的构件引用,同时,变化性信息也包含在Port里;一个构件能有多个接口,所以Component还包含一个Interface列表,对于一个Interface,包含生产接口和该生产接口的依赖接口列表,还包含xModel的信息;语言模块是其他模块的基础,具体表现为其他模块的类对Component类的依赖。
8.如权利要求6所述的DPOSPL ADL建模工具,其特征在于,解析模块里包含解析器,解析器都遵循Parser接口,该接口里主要的方法是以ADL文本为输入,解析后返回一个Component的结构,即对象引用;目前DPOSPL ADL提供两个解析器,分别是JavaScript解析器和JSON解析器,前者能运行一段JavaScript脚本,然后提取其中名为root的变量,形成Component结构;而JSON解析器则把一段JSON的描述文本转换成Component结构,不具备脚本执行功能;解析模块是模型编辑模块和生成器模块的基础,为它们 提供可用的Component对象。
9.如权利要求6所述的DPOSPL ADL建模工具,其特征在于,模型编辑模块里包含可视化编辑器和变化绑定器;DPOSPL ADL工具的可视化编辑器是基于Prefuse来开发的,目前仅具备模型查看的功能,还不能做到双向的模型查看和修改,但由于Prefuse是一个交互式的数据可视化工具,要实现模型可视化编辑是完全可以的,可以考虑在日后扩展中完善这部分功能;另一方面,变化绑定器负责把体系结构模型中的可变点显示出来,Binder里有一个树状机构能对体系结构模型以树状形式展现,同时这个树状结构还能把可变点以单选框和多选框的形式显示在相应的树结点上,这样架构师就能通过对这些选框进行选择,完成体系结构绑定;经过绑定后的体系结构模型同样以一个Component结构来表示,不同的是其里面的变化性已经消除,可以作为代码生成器的输入,进行代码生成。
10.如权利要求6所述的DPOSPL ADL建模工具,其特征在于,生成器模块里包含各种代码生成器,它们都是Generator接口的实现,Generator接口里有一个主要的方法,它以Component对象的引用和文档输出路径为输入,执行后会把所生成的文档输出到指定路径上;DPOSPL ADL建模工具目前实现了的生成器包括DPOSPLProjectGenerator,JavaGenerator,GraphMLGenerator;由于建模工具要应用于DPOSPL工程的生成流程里,所以DPOSPLProjectGenerator是最主要的代码生成器,它负责根据体系结构绑定模型生成DPOSPL IDE软件模型描述,这个描述主要包含三个XML文档,第一个是用户界面及数据模型描述文档,后缀名为gux,这个文档记录了软件中的界面元素属性,如界面中使用什么控件,控件的位置和数据模型的绑定路径等,而数据模型则是过程与界面之间数据交换的格式信息;第二个是过程文档,后缀名pex,它记录的是构件流程信息以及构件与构件实例的绑定信息;第三个是产品组装概览,扩展名cpx,在有了界面和过程之后,通过产品概览文档把它们之间的调用关系描述出来;DPOSPLProjectGenerator从体系结构绑定模型中提取接口的xModel信息,生成gux文件中的数据模型描述,根据构件连接信息,生成过程描述文档,即pex文件,再根据接口 的生产依赖关系,生成产品组装概览,即cpx文件;DPOSPL IDE能产生两种类型的应用,分别是桌面应用和Web应用。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110228837.8A CN102270137B (zh) | 2011-08-10 | 2011-08-10 | 一种获取体系结构描述语言的方法和一种建模工具 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201110228837.8A CN102270137B (zh) | 2011-08-10 | 2011-08-10 | 一种获取体系结构描述语言的方法和一种建模工具 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN102270137A true CN102270137A (zh) | 2011-12-07 |
CN102270137B CN102270137B (zh) | 2014-01-01 |
Family
ID=45052448
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201110228837.8A Active CN102270137B (zh) | 2011-08-10 | 2011-08-10 | 一种获取体系结构描述语言的方法和一种建模工具 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN102270137B (zh) |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103838581A (zh) * | 2014-03-18 | 2014-06-04 | 中山大学深圳研究院 | 一种分析结果的集成方法 |
WO2015196782A1 (zh) * | 2014-06-25 | 2015-12-30 | 成都普中软件有限公司 | 一种构造系统模型的可视建模编辑器 |
WO2015196784A1 (zh) * | 2014-06-25 | 2015-12-30 | 成都普中软件有限公司 | 一种基于软件元视图以构造软件视图的可视软件建模方法 |
CN106462563A (zh) * | 2014-05-28 | 2017-02-22 | 西门子产品生命周期管理软件公司 | 从绘图注释创建相关联的3d产品文档记录 |
CN106557569A (zh) * | 2016-11-14 | 2017-04-05 | 用友网络科技股份有限公司 | 基于元模型的非结构化文档的导入方法和导入装置 |
CN107145344A (zh) * | 2014-09-02 | 2017-09-08 | 起元科技有限公司 | 在基于图的程序中指定组件 |
CN108287713A (zh) * | 2017-12-22 | 2018-07-17 | 深圳康得新智能显示科技有限公司 | 文档功能的添加方法及装置、终端、存储介质、电子装置 |
CN109918050A (zh) * | 2019-02-01 | 2019-06-21 | 上海交通大学 | 一种软件需求描述规则语言与转换方法 |
US10885003B2 (en) | 2014-09-02 | 2021-01-05 | Ab Initio Technology Llc | Compiling graph-based program specifications |
CN113626026A (zh) * | 2021-07-21 | 2021-11-09 | 北京理工大学 | 一种支持复杂模型结构转换的代码生成方法 |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101281466A (zh) * | 2008-05-27 | 2008-10-08 | 北京中企开源信息技术有限公司 | 基于业务本体特征的业务对象建模方法 |
JP2010049439A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ソフトウェアモデルを用いたシステム構築方法およびモデリング装置 |
US7721252B2 (en) * | 2004-12-21 | 2010-05-18 | Electronics And Telecommunications Research Institute | Apparatus and method for product-line architecture description and verification |
-
2011
- 2011-08-10 CN CN201110228837.8A patent/CN102270137B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7721252B2 (en) * | 2004-12-21 | 2010-05-18 | Electronics And Telecommunications Research Institute | Apparatus and method for product-line architecture description and verification |
CN101281466A (zh) * | 2008-05-27 | 2008-10-08 | 北京中企开源信息技术有限公司 | 基于业务本体特征的业务对象建模方法 |
JP2010049439A (ja) * | 2008-08-21 | 2010-03-04 | Hitachi Ltd | ソフトウェアモデルを用いたシステム構築方法およびモデリング装置 |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103838581A (zh) * | 2014-03-18 | 2014-06-04 | 中山大学深圳研究院 | 一种分析结果的集成方法 |
CN106462563A (zh) * | 2014-05-28 | 2017-02-22 | 西门子产品生命周期管理软件公司 | 从绘图注释创建相关联的3d产品文档记录 |
WO2015196782A1 (zh) * | 2014-06-25 | 2015-12-30 | 成都普中软件有限公司 | 一种构造系统模型的可视建模编辑器 |
WO2015196784A1 (zh) * | 2014-06-25 | 2015-12-30 | 成都普中软件有限公司 | 一种基于软件元视图以构造软件视图的可视软件建模方法 |
CN105320504A (zh) * | 2014-06-25 | 2016-02-10 | 成都普中软件有限公司 | 一种基于软件元视图构造软件视图的可视软件建模方法 |
CN105320504B (zh) * | 2014-06-25 | 2018-08-17 | 成都普中软件有限公司 | 一种基于软件元视图构造软件视图的可视软件建模方法 |
CN107145344A (zh) * | 2014-09-02 | 2017-09-08 | 起元科技有限公司 | 在基于图的程序中指定组件 |
CN107145344B (zh) * | 2014-09-02 | 2020-12-04 | 起元科技有限公司 | 在基于图的程序中指定组件 |
US10885003B2 (en) | 2014-09-02 | 2021-01-05 | Ab Initio Technology Llc | Compiling graph-based program specifications |
US11301445B2 (en) | 2014-09-02 | 2022-04-12 | Ab Initio Technology Llc | Compiling graph-based program specifications |
CN106557569A (zh) * | 2016-11-14 | 2017-04-05 | 用友网络科技股份有限公司 | 基于元模型的非结构化文档的导入方法和导入装置 |
CN108287713A (zh) * | 2017-12-22 | 2018-07-17 | 深圳康得新智能显示科技有限公司 | 文档功能的添加方法及装置、终端、存储介质、电子装置 |
CN109918050A (zh) * | 2019-02-01 | 2019-06-21 | 上海交通大学 | 一种软件需求描述规则语言与转换方法 |
CN113626026A (zh) * | 2021-07-21 | 2021-11-09 | 北京理工大学 | 一种支持复杂模型结构转换的代码生成方法 |
Also Published As
Publication number | Publication date |
---|---|
CN102270137B (zh) | 2014-01-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN102270137B (zh) | 一种获取体系结构描述语言的方法和一种建模工具 | |
Tisi et al. | On the use of higher-order model transformations | |
Werbrouck et al. | Scan-to-graph: Semantic enrichment of existing building geometry | |
CN103761080B (zh) | 一种基于SQL的MapReduce作业生成方法及系统 | |
CN101819529A (zh) | 用于实现工作流任务界面可视化开发的系统和方法 | |
US8577652B2 (en) | Spreadsheet-based graphical user interface for dynamic system modeling and simulation | |
Fuchs et al. | Formal description of a generic multi-model | |
Karataş et al. | Mapping extended feature models to constraint logic programming over finite domains | |
CN105447253A (zh) | 一种三维工艺数据的集成方法 | |
CN104679511A (zh) | 基于MDE模型转换的MapReduce代码生成方法 | |
CN106372044A (zh) | 一种基于报表生成类型化维度xbrl报告的方法 | |
CN105260300B (zh) | 基于会计准则通用分类标准应用平台的业务测试方法 | |
CN109614093A (zh) | 可视化智能合约系统以及智能合约的处理方法 | |
CN103020400A (zh) | 基于复杂网络边介数的模块划分方法 | |
CN109857458B (zh) | 基于ANTLR的AltaRica 3.0的扁平化的转化方法 | |
Shrestha et al. | SLNET: A redistributable corpus of 3rd-party Simulink models | |
CN101706840A (zh) | 基于产品节点树的产品性能仿真信息的表示方法 | |
Moutinho et al. | Ecore representation for extending PNML for Input-Output Place-Transition nets | |
CN106777450A (zh) | 一种支持组合模型的模型描述及生成方法 | |
CN115713309A (zh) | 内审系统 | |
CN114281797A (zh) | 基于敏捷低代码平台快速创建基层数据汇聚仓库的方法 | |
CN111277650B (zh) | 一种结合功能指标和非功能指标的自动化微服务识别方法 | |
CN111291444B (zh) | 飞机装配的建模方法、装置、设备及存储介质 | |
Levytskyy et al. | Creating DEVS components with the meta-modelling tool AToM3 | |
CN104199660B (zh) | 水利软件中定制式输出及成果动态显示的方法 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant |