CN112214401A - 一种基于模型检测的标准模型分析方法 - Google Patents
一种基于模型检测的标准模型分析方法 Download PDFInfo
- Publication number
- CN112214401A CN112214401A CN202011006772.8A CN202011006772A CN112214401A CN 112214401 A CN112214401 A CN 112214401A CN 202011006772 A CN202011006772 A CN 202011006772A CN 112214401 A CN112214401 A CN 112214401A
- Authority
- CN
- China
- Prior art keywords
- model
- state
- diagram
- message
- sequence
- 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
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
- G06F11/3608—Software analysis for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/10—Text processing
- G06F40/166—Editing, e.g. inserting or deleting
- G06F40/186—Templates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F40/00—Handling natural language data
- G06F40/20—Natural language analysis
- G06F40/253—Grammatical analysis; Style critique
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/31—Programming languages or programming paradigms
- G06F8/315—Object-oriented languages
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/35—Creation or generation of source code model driven
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computational Linguistics (AREA)
- General Health & Medical Sciences (AREA)
- Health & Medical Sciences (AREA)
- Audiology, Speech & Language Pathology (AREA)
- Artificial Intelligence (AREA)
- Computer Hardware Design (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Debugging And Monitoring (AREA)
- Stored Programmes (AREA)
Abstract
本发明公开了一种基于模型检测的标准模型分析方法,其特点是采用四类子问题结构的形式化模型的检测方法,对类图模型中存在变量一致性问题、类图及对象图模型中存在约束一致性问题、状态图及顺序图模型中存在行为一致性问题,以及状态图模型中存在状态逻辑错误问题进行分析,其模型的构建及检测具体包括:1.)根据模板设计标准模型;2)构建子问题结构的形式化模型;3.)对子问题形式化模型施加待分析性质条件;4)分析子问题模型是否满足性质条件。本发明与现有技术相比具有高度自动化和可信、可靠的分析结果,有效替代替低效率地人工审查标准的过程,进一步提升了标准设计的科学性和规范性以及工作效率。
Description
技术领域
本发明涉及模型自动化分析检测技术领域,具体的说是一种基于模型检测对标准模型设计研发过程中产生的逻辑设计错误及特定语法语义错误进行自动化分析检测校准的标准模型分析方法。
背景技术
随着科技的飞速发展,各个领域的建设和发展呈现多样化形态,使得制定本领域统一的标准成为必然趋势。从国际标准,国家标准,行业标准乃至企业标准的制定都需要有一套完善的制度和体系支撑。所谓标准是在一定范围内获得最佳秩序,经协商一致制定并由公认机构批准,共同使用和重复使用的一种规范性文件。标准宜以科学、技术和经验的综合成果为基础,以促进最佳的共同效益为目的。标准的制定路线也首先由相关的技术委员会负责协商一致制定。标准设计制定的每个阶段的工作,都是非常具体的工作、计划和保证完成的措施。标准的制定过程和进度是由工作组向技术委员会定期提交阶段性报告和举行定期会议以控制进度来保障的。而国际标准的编制原则就是站在国际立场上充分协调和一致,这反映在国际标准编制过程中的每一个阶段是否被接受与否,唯一的根据就是委员会或者分委员会成员的投票决定。从整个流程中来看,会发现整个标准制定流程上是很大程度上依赖了专家的主观和自身的专业背景,虽然在流程上已经尽量保证了国际标准的规范管理,但是仍然面临着一个很大的技术挑战:1)如何在撰写标准过程中,更为规范的撰写标准,制定出的标准是能够通过审查的正确标准;2)如何确保自己负责撰写的内容与整个标准的其他部分内容是一致的;3)人工审查后的标准是否还存在不易发现的错误。
标准模型是类图模型、对象图模型、状态图模型和顺序图模型四种类型的UML图模型的总称,是使用UML语言为载体的形式进行模型设计的。四种标准模型蕴含了四种子问题,即类图模型中存在变量一致性问题;类图及对象图模型中存在约束一致性问题;状态图及顺序图模型中存在行为一致性问题;状态图模型中存在状态逻辑错误问题。类图模型中的变量一致性问题指的是在特定的应用场景下,需保证类图模型中定义的变量标识必须与其表达的物理意义唯一绑定,不可存在其他匹配情况。类图及对象图模型中的约束一致性问题指的是对象图模型状态需完全满足类图模型中定义的对象约束条件,不可存在任何不满足情况。状态图及顺序图模型中的行为一致性问题指的是顺序图模型中表达的行为动作应与状态图模型的每一项状态保持一致。状态图模型中的状态逻辑错误问题指的是当前模型中不应存在死锁,无限循环,不可到达某一状态的情况。
基于这样的标准设计流程及其产生设计错误的根本原因,开发标准分析技术,将形式化方法模型检测的理论与标准建模设计相结合,提高建模过程的自动化程度,充分发挥模型检测的优势,自动化地分析检测标准设计生产中的逻辑矛盾错误,特定语法语义错误等问题,具有重要的现实意义。
发明内容
发明的目的是针对现有技术的不足而设计的一种基于模型检测的标准模型分析方法,采用形式化模型检测的方法对标准模型的指定性质条件进行分析,将形式化方法模型检测的理论与标准建模设计相结合,提高建模过程的自动化程度,充分发挥模型检测的优势,自动化地分析检测标准设计生产中的逻辑矛盾错误,特定语法语义错误等问题,精准高效地分析标准模型中存在的变量一致性、约束一致性、行为一致性和状态逻辑四类错误问题,方法简便,具有高度自动化,高度可信可靠的分析结果,有效替代了低效率地人工审查标准的过程,进一步提升了标准设计的科学性和规范性以及工作效率。
本发明的目的是这样实现的:一种基于模型检测的标准模型分析方法,其特点是采用四类子问题结构的形式化模型的检测方法,对类图模型中存在变量一致性问题、类图及对象图模型中存在约束一致性问题、状态图及顺序图模型中存在行为一致性问题,以及状态图模型中存在状态逻辑错误问题进行分析,其各问题形式化模型的构建及检测具体包括以下步骤:
步骤1:根据模板设计标准模型
标准模型是对现实场景下真实应用问题的主观描述,由类图模型,对象图模型,状态图模型及顺序图模型四种类型的UML图模型所构成,使用UML语言为载体的形式进行模型设计。其中,状态图模型根据软件工程领域内UML2.x规定的语法语义形式进行建模设计,其余三种标准模型没有特别格式要求。对于状态图模型,并发程序的每个进程都用一个状态图来表示,每个状态图中的状态节点只包含基本状态节点、初始伪状态节点和终止状态节点。所述状态图的语句中可以使用局部变量、共享变量、同步事件和异步事件,触发条件只能使用事件接收语句,守卫条件为布尔语句,动作可以包含事件发送语句、算术语句和赋值语句,事件接收语句格式为一个问号后接变量名或者两个问号接变量名。其中一个问号为接收异步事件,两个问号为接收同步事件,事件发送语句为状态图名接感叹号接异步事件名或者状态图名接两个感叹号接同步事件名。
步骤2:构建子问题结构的形式化模型
针对四种标准模型按下述步骤分别构建对四类子问题结构形式化模型:
2-1:针对变量一致性问题需要构建类结构模型,该模型主要特征为:需使用指定关键字语法格式明确定义类名,变量标识名及物理意义说明串信息。物理意义说明串用于描述当前类块中的变量标识名所表示的物理含义。
建模方法:将类图模型中的类名作为模型的索引编码,类图模型中的变量标识名及物理意义说明串构造成一个二元组模型(索引编码(类名),(变量标识名:物理意义)),此模型为类结构模型。
2-2:针对约束一致性问题构建类-对象组合结构模型,该模型主要特征为:需使用规定的关键字字段明确定义模型名,类名,类中属性名及属性值类型,类间关系类型及类间关系名,对象名及对象值这些模型主要状态。
建模方法:首先需获取类图模型中的各项属性,将类图看作是某段时间内要求系统持续运行着的状态,将对象图看作是某一时刻的系统状态,使用关键字结合各项属性构造出该状态模型类-对象组合结构模型,对象是类的具体体现,所以类中定义的约束要求,对象必须全部满足。
2-3:针对行为一致性问题构建自动机模型,该模型的主要特征为:
对于顺序图模型,需要明确定义生命线名,消息名,消息状态。定义时,将每条生命线看作是一个模型,生成多个以状态为节点,消息名为边的自动机模型。对于顺序图中每一条生命线,都有很多的消息传送,每一条消息都会有对应的名字以及发送前和发送后的状态。所以就取该生命线的生命线名作为模型的名字,消息发送前和发送后的状态作为模型的节点,并从一个状态节点画一条线指向该状态经过消息的传输后到达的另一个状态节点,并且以该条消息的名字作为连接线的名字。以此形成一个点边图的模型自动机。
对于状态模型,需要明确定义消息名以及状态名,从状态图中取出所有的状态名作为节点,之后取出状态转移的边,根据状态转移的信息一一对应,用带有箭头的线段将所有的节点连接起来,线段的名字就是这两个状态转移时的消息名,以此形成一个点边图的模型自动机。
2-4:针对状态逻辑错误问题首先需要构建层次自动机模型,由于状态图与层次自动机的结构相似,可通过一一对应关系可以实现转换。其中,状态图的每一个并发子状态机对应一个顺序自动机,子状态机中的状态全部包含在对应的顺序自动机中。子状态机中的边放在源和目的状态的最下层公共的顺序自动机中。随后,一个并发程序模型的所有层次自动机会被转换成一个验证工具的输入文件,该文件使用验证工具的输入语言书写。
所述转换首先对层次自动机的所有顺序自动机做一些调整,对于所有最上层的顺序自动机,保留初始伪状态并在该初始伪状态的唯一出边上添加触发条件,触发条件的开始事件为顺序自动机的名称接下划线接开始字符串。对于所有的非最上层顺序自动机,删除该顺序自动机的初始伪状态和该初始伪状态的唯一出边,其转换方法的主要步骤如下:
a、为每个层次自动机定义边的候选条件。候选条件包括层次自动机取出的事件与边的触发条件事件相同以及边的守卫条件为真。这里需要区分有触发条件的边和无触发条件的边。对于有触发条件的边,需要考虑所有优先级高于它的边,这些边必须都不满足执行条件。对于无触发条件的边,则不需要考虑其他的边。
b、定义事件挑选语句,对同步事件和异步事件进行区分。
c、定义边的挑选与执行语句,该部分只对有触发条件边进行定义。对于同一个顺序自动机的所有边,以可以随机选择的并列关系表示。当边在a步骤中定义的候选条件满足时,便可以执行该边的动作语句。同时,该自动机的所有下层顺序自动机使用进程来实现,每个顺序自动机都是一个进程,若该自动机的所有下层顺序自动机中存在满足候选条件的边便可以执行所有下层顺序自动机对应的进程,只有当所有这些进程都执行完成时,该顺序自动机才算完成一次执行。此外,发送同步消息的边发送完同步事件后需要阻塞自身。当边接收的是同步事件时,执行完动作语句后需解除发送同步事件的边的阻塞状态。
d、定义执行无触发条件边的语句,需要先判断状态是否是完备的,判断依据是该状态在状态图中是活跃的并且该状态下层所有的顺序自动机的终止状态也是活跃的。每次执行完有触发条件的边之后都需要循环的判断是否有完备的状态和执行相应的无触发条件边,直到不存在完备的状态。
e、为每个层次自动机定义进程,进程需要循环的挑选事件和执行边。
f、初始化包括以下几个部分:每个层次自动机的初始状态的设置;为每个层次自动机发送开始事件,若层次自动机中的最上层有多个顺序自动机,这些顺序自动机的开始事件按随机顺序发送;开始每个层次自动机对应的进程。
步骤3:对子问题形式化模型施加待分析性质条件
根据子问题类型的不同,分别对各子问题形式化模型施加指定形式的待分析性质条件:
3-1:针对变量一致性问题,需要构建类结构模型,在类结构模型中定义性质条件规则:标准模型中的变量标识名应与物理意义说明串唯一对应,即标准模型中相同的变量标识名仅存在唯一且相同的物理含义解释。性质条件公式为:变量标识名#物理意义说明串,#代表任意特殊字符符号。
3-2:针对约束一致性问题,需要构建类-对象组合结构模型,以对象约束语言的形式对该子问题形式化模型施加约束条件。定义约束需满足对象约束语法:使用关键字“约束”表示约束体开端,关键字“上下文”表示约束头部。约束内应定义被施加约束的类名,该条约束的类型以及约束演算公式或布尔表达式。
3-3:针对行为一致性问题,需要分别对顺序图和状态图构建模型,并且从两个模型中分别提取相应的所有消息路径。其中,顺序图提取消息路径,是根据每条生命线进行提取,所以一张顺序图会对应若干个消息路径。定义顺序图和状态图具有行为一致性规则:在顺序图模型中存在一条生命线的消息序列,使得状态图模型中的消息路径中消息出现的顺序与该条生命线中的消息序列保持一致。
4-4:针对状态逻辑错误问题,为了保证验证过程的自动化,该部分验证的性质为死锁、循环和状态可达性。死锁和循环通过固定的命令可以实现,若要验证状态可达性,需要在文件中为每个状态定义线性时序逻辑公式,公式表达含义为状态节点表示的变量始终为初始值,意为某状态总是不可达。
步骤4:分析子问题模型是否满足性质条件
通过模型检测的方式按下述验证子问题形式化模型是否满足各项已定义的性质条件:
4-1:针对变量一致性问题,获取每一个元组,搜索是否存在元素位于不同元组中,若存在则不满足变量一致性。
4-2:针对约束一致性问题,将构造完成的类-对象组合结构模型及对子问题形式化模型施加的约束相结合,使用模型检测工具USE演算对象模型中的当前具体真实状态与约束性质条件之间是否存在可满足解,若不存在可满足解,则证明当前形式化模型不满足约束性质条件,违反了约束一致性,由此可知标准类模型及标准对象模型之间存在逻辑矛盾错误,可通过USE工具查询错误原因。
4-3:针对行为一致性问题,需要对顺序图模型和状态图模型分别进行消息路径的提取,并将提取出来的消息路径比对,如果消息顺序一致,则是顺序图和状态图是行为一致的,若消息序列不一致,则两图不具有行为一致性。主要操作步骤如下:
a、从顺序图模型中提取消息路径。
b、从状态图模型中提取消息路径。
c、依照顺序,在状态图对应的消息路径中寻找顺序图对应的消息路径中的第一条消息,若不存在该消息,则切换至下一条顺序图所对应的消息路径,遍历该条顺序图对应的消息路径,并将状态图对应的消息路径和该路径进行比对,查看状态图对应的消息路径的消息顺序是否和顺序图模型的消息路径的消息顺序是一致的,若不一致,则进行下一条顺序图模型对应的消息路径的判断;若所有的消息路径都不一致,则两图不具有行为一致性;若一致,则两图具有行为一致性;若遍历完所有的消息路径都不存在,则两图是行为不一致的;若存在,则继续往后寻找顺序图模型的下一条消息。
4-4:针对状态逻辑错误问题,在步骤2得到验证工具的输入文件,可以通过命令行输入命令或者图形界面进行验证。当存在死锁和循环时,验证工具会生成对应的错误路径文件保存错误路径,当存在状态不可达时,根据该状态对应的线性时序逻辑公式是否被满足来判断,若满足,则状态不可达,反之可达。
本发明与现有技术相比具有以下有益的技术效果:
1)在大规模的标准设计过程中,一份完整的标准中包含大量的UML图模型,而现有标准设计技术中,绘制UML图模型,设计标准,审核标准模型完全依赖人工完成,人为导致的逻辑错误,语法语义错误较多,精准度及自动化程度低。
2)本发明可以针对变量不一致错误、约束不一致错误、行为不一致错误及状态逻辑错误四种类型逻辑错误问题进行高精准度自动化分析检测错误,使用本方法可以帮助用户从低效繁琐的分析验证工作中解放出来并且得到更精准更可信的分析结果。
3)方法简便,具有高度自动化,高度可信可靠的分析结果,有效替代了低效率地人工审查标准的过程,进一步提升了标准设计的科学性和规范性以及工作效率。
附图说明
图1为本发明流程示意图;
图2为实施例的行为一致性顺序图;
图3为实施例的行为一致性状态图;
图4为共享服务系统状态图;
图5为数据生产分系统状态图;
图6为终端用户状态图。
具体实施方式
为了使本发明所要解决的技术问题、技术方案、有益效果及操作方式更加清楚明白,以下结合附图和具体实施例,对本发明作进一步详细说明。实施本发明的过程、条件、实验方法等,除以下专门提及的内容之外,均为本领域的普遍知识和公知常识,本发明没有特别限制内容。应当理解,此处所描述的具体实施例仅仅用以解释本发明,并不用于限定本发明。
实施例1
参阅附图1,本发明按下述步骤进行标准模型分析的:
步骤1:根据模板设计标准模型
基于标准建模工具设计完成标准模型,标准模型根据问题类型划分为标准类模型,标准对象模型,标准状态模型及标准活动模型,用户需根据指定的模板规范要求使用标准建模工具进行标准模型的设计研发。
针对变量一致性问题及约束一致性问题设计实施例,例如,标准类模型信息包括但不限于类名、类成员属性名、属性数据类型、类间关系、类间关系名、约束性质条件等。标准对象模型信息包括但不限于对象名、对象所属类名、对象间关系及对象包含各属性值等。
在本实例中设定,用户在标准类模型中设计了两个类:类名1:部署位置类(Deployment Location),类名2:传感器精度类(SensorAccuracy)。其中部署位置类包含类成员属性数据类型为实型的部署高度(DeploymentHeight:Real)及数据类型为实型的部署精度(DeploymentAccuracy:Real,物理意义为accuracy)。传感器精度类包含类成员属性数据类型为实型的重启时间(RestartTime:Real)及数据类型为实型的定位精度(PositionalAccuracy:Real,物理意义为accuracy)。两个类的类间关系定为association,类间关系名为transform。定义约束条件如下:
1)部署位置类中的部署高度值应在[500,700]区间内。
2)传感器精度类中的重启时间值应使用实型数值表示,不可用其他类型数值表示。
3)属性名与其物理意义具有唯一一致性,相同的属性名必须具有相同的物理意义,相同的物理意义必须赋予相同的属性名。
根据上述两个标准类设计了两个标准对象模型:部署位置类对应对象:位置(Location),传感器精度类对应对象:SAR传感器(SARSensor)。其中位置对象的部署高度值定为735(千米),SAR传感器对象的重启时间定为5(秒)。
参阅附图2,对于顺序图的行为一致性问题,从该图中提取出了ServiceNode、HumanBeing、DataNode这三条生命线,以及ProductionTask、ProductionTask、Lv0DataCatalogInfo、Lv1Data、BasicData、ProductionAndMetaDataInfo这六条消息以及他们相对应的发送方和接受方。
参阅附图3~图5,对于状态逻辑错误问题,设计了包括:终端用户TUser、共享服务系统Service和数据生产分系统DataProduct三个并发的状态图模型,它们之间的消息交互主要为如下表1所述:
表1消息交互表
序号 | 消息名称 | 发送方 | 接收方 |
1 | 用户数据请求 | 终端用户 | 共享服务系统 |
2 | 服务数据请求 | 共享服务系统 | 数据生产分系统 |
3 | 数据请求接收状态 | 数据生产分系统 | 共享服务系统 |
5 | 数据请求接收状态回执 | 共享服务系统 | 数据生产分系统 |
6 | 分发数据提交完成通知 | 数据生产分系统 | 共享服务系统 |
7 | 数据获取情况回执 | 共享服务系统 | 数据生产分系统 |
在完成建模后,需使用XMI文件格式存储并导出标准模型数据信息,对该数据进行信息抽取、重构,作为后续步骤的元数据,模型分析的基础。
步骤2,构建子问题结构的形式化模型
根据子问题划分,使用步骤1中抽取、重构的标准模型数据信息构建子问题形式化模型。
2-1:针对变量一致性问题构建类结构模型:使用Class关键字区分类名,使用Attributes关键字定义类中成员变量及该变量物理意义说明串,使用冒号或其他符号将两者分割。
2-2:针对约束一致性问题根据发明内容中步骤2的描述使用各类关键字定义构建类-对象组合结构模型:使用model关键字声明当前所述模型,使用关键字class区分类块,使用attributes关键字及冒号定义类中成员变量及其数据类型。在本实例中使用association关键字定义当前类间关系,between关键字描述被类间关系链接的两类。使用!create关键字及冒号定义各类的对应对象,使用!set关键字定义对象变量属性值。
2-3:针对行为一致性问题,根据发明内容中步骤2的描述根据图中的消息构建顺序-状态模型如下:
2-3-1:对于顺序图,将每个生命线都看作是一个模型,状态作为节点,消息作为边将所有的状态连接起来,形成自动机。
2-3-2:对于状态图,将状态作为节点,消息作为边将其连接起来形成自动机。
2-4:针对状态逻辑错误问题,生成的pml文件包括三个进程:DataProduct进程、TUser进程和Service进程。每个进程使用do循环语句模拟状态图依次选择边来执行的过程,do语句内部首先使用if语句表示事件的挑选,该if语句有两个分支,第一个表示start事件通道不为空时,选择start事件,否则,从event事件通道中挑选事件,如果事件是同步事件(使用0表示),则需要再次从SynEventQueue中取出同步事件。随后再使用if语句表示边的随机挑选和执行,if语句的每个分支表示一个边,分支的第一个语句表示边的候选条件,当条件满足时,便可以执行后续的action语句。
步骤3:对子问题形式化模型施加待分析性质条件
3-1:针对变量一致性问题的类结构形式化模型施加指定性质条件:类结构模型中的属性名与物理意义说明串构成一个二元组,唯一绑定。若元组中的元素出现不同的组合即为变量不一致。
3-2:针对约束一致性问题的类-对象组合结构形式化模型以OCL对象约束语言的形式施加约束条件:针对本实施例,使用constraints关键字表示约束体开端,context表示OCL约束头部,其后指向被约束类块,使用inv关键字表示该条约束类型为不变量约束,最后给出约束表达式或演算式。部署位置类中的部署高度值应在[500,700]区间内,表达式为:DeploymentHeight>=500 and DeploymentHeight<=700;传感器精度类中的重启时间值应使用实型数值表示,不可用其他类型数值表示,演算式为:RestartTime.oclIsTypeOf(Real)。
3-3:针对行为一致性问题,需要判断的是状态图所描绘的消息序列,在顺序图中是否存在一条消息序列与之相同。
3-4:针对状态逻辑错误问题的状态模型,需要定义的是表示每个状态的可达性的LTL公式。图中共包括12个状态,因此定义12条LTL公式,以Service的SubmitFailure为例,LTL公式为:LTL SubmitFailureReachability{[]SSubmitFailure==0}。
步骤4:分析子问题模型是否满足应性质条件
在本实施例中,根据施加的性质条件对子问题形式化模型进行自动化分析检测,在形式化模型状态空间中搜索求解不满足约束性质条件的状态,该状态对应错误情况。
例如,使用自研模型检测工具在类结构模型中搜索变量元组是否存在不同的组合;使用模型检测工具USE在类-对象组合结构模型中搜索当前模型是否存在某个状态使得OCL约束不被满足;根据模型检测的结果,性质条件是否被当前模型满足得到验证,或通过工具给出不满足原因。
在本例中,分析变量一致性时,通过模型检测工具分析类结构模型可知存在不满足状态,即部署位置类中存在(DeploymentAccuracy:accuracy),传感器精度类中存在(PositionalAccuracy:accuracy),两个元组中的物理意义说明串均为accuracy,不满足性质条件。
针对本例分析约束一致性时,首先使用USE工具读入解析类-对象组合结构模型,分析该形式化模型可知存在不满足状态,即位置对象中DeploymentHeight=735,不满足约束要求在[500,700]区间内。SAR传感器对象中RestartTime=5,不满足约束要求应为实型数值5.0。由此得出分析验证结果,并可通过USE工具查询具体错误原因。
在分析行为一致性问题时,按照下述所描述的操作步骤进行:
1)提取顺序图中的消息路径:
ServiceNode:[ProductionTask!,Lv0DataCatalogInfo!,Lv1Data!,BasicData!,ProductionAndMetaDataInfo?];
HumanBeing:[ProductionTask!];
DataNode:[ProductionTask?,ProductionTask?,Lv0DataCatalogInfo?,Lv1Data?,BasicData?,ProductionAndMetaDataInfo!]。
其中,“!”表示在该条生命线路径中,该消息为发送状态;“?”表示在该条生命线路径中,该消息为接收状态。
2)提取状态图中的消息路径:
[ProductionTask?,ProductionTask?,ReceiveTask,Lv0DataCatalogInfo?,IntelligentDecomposition,Lv0Data?,BasicData?,ProductionAndMetaDataInfo!];
3)依次匹配,发现ServiceNode中的第一条消息为ProductionTask!,在状态图路径中不存在这条边,所以进行下一条路径的匹配,第一条消息也为ProductionTask!,不匹配,进行DataNode生命线路径的匹配,发现第一条路径ProductionTask?和状态图消息路径中的第一条消息是匹配的,所以进行下述4)操作步骤。
4)遍历DataNode生命线对应的路径,发现直到Lv0DataCatalogInfo?消息都和状态图的路径匹配,而Lv1Data?在状态图路径中没有对应,所以这两条路径也不一致,而DataNode已经是最后一条生命线了,所以两图的行为不一致,不具有行为一致性。
针对状态逻辑错误问题的并发状态图模型实例进行分析,使用模型检测工具SPIN读取pml文件并添加验证性质进行验证能够得到两个错误。
第一种错误为存在逻辑不可达错误,分析验证出不可达状态SubmitFailure。
第二种错误为死锁,使用SPIN对产生死锁的错误路径进行仿真得到如下一个状态图的执行序列:
1、终端用户向共享服务系统发送消息“用户数据请求”,进入TUserFinalState状态。
2、共享服务系统接收消息“用户数据请求”,向数据生产系统发送消息“服务数据请求”,进入WaitResponse状态。
3、数据生产系统接收消息“服务数据请求”,向共享服务系统发送消息“数据请求接收状态”,进入waitReceipt状态。
4、共享服务系统接收消息“数据请求接收状态”,进入waitNotify状态。
5、共享服务系统进入HandleReceiptTimeout状态。
以上只是对本发明作进一步的说明,并非用以限制本专利,在不背离发明构思的精神和范围下,本领域技术人员能够想到的变化和优点都被包括在本发明中,凡在运用本发明的技术构思之内所作的任何修改、等同替换和改进,均应包含于本专利的权利要求范围之内。
Claims (4)
1.一种基于模型检测的标准模型分析方法,包括使用UML语言为载体的形式根据类图模型、对象图模型、状态图模型及顺序图模型设计的四种标准模型,其特征在于采用四类子问题结构的形式化模型的检测方法,对类图模型中存在变量一致性问题、类图及对象图模型中存在约束一致性问题、状态图及顺序图模型中存在行为一致性问题,以及状态图模型中存在状态逻辑错误问题进行分析,其模型的构建及检测具体包括以下步骤:
步骤1:根据模板设计标准模型
使用UML语言为载体的形式根据类图模型、对象图模型、状态图模型及顺序图模型进行四种标准模型的设计,所述状态图模型根据UML2.x规定的语法语义形式进行建模设计;
步骤2:构建子问题结构的形式化模型
2-1:变量一致性问题的形式化模型构建是将类图模型中的类名作为模型的索引编码,类图模型中的变量标识名及物理意义说明串构造成一个二元组模型;
2-2:约束一致性问题的类结构形式化模型构建是将类图看作是某段时间内要求系统持续运行着的状态,将对象图看作是某一时刻的系统状态,使用关键字结合各项属性构造出该状态模型类-对象组合结构模型;
2-3:行为一致性问题的形式化模型构建:对于顺序图模型,定义生命线名、消息名、消息状态,并将每条生命线看作是一个模型,生成多个以状态为节点,消息名为边的自动机模型,以消息发送前和发送后的状态为模型的节点,并从一个状态节点画一条线指向该状态经过消息的传输后到达的另一个状态节点,并且以该条消息的名字作为连接线的名字,形成一个点边图的模型自动机; 对于状态图模型,从状态图中取出所有的状态名作为节点,状态转移的边,根据状态转移的信息一一对应,并用带有箭头的线段将所有的节点连接起来,形成一个点边图的自动机模型;
2-4:状态逻辑错误问题的形式化模型是通过状态图的一一对应关系转换,得到的层次自动机模型,其中,状态图的每一个并发子状态机对应一个顺序自动机,子状态机中的状态全部包含在对应的顺序自动机中,子状态机中的边放在源和目的状态的最下层公共的顺序自动机中,所述每一个并发程序模型的所有层次自动机会被转换成一个验证工具的输入文件;
步骤3:对各子问题的形式化模型施加待分析性质条件
3-1:对变量一致性问题的形式化模型,施加变量标识名#物理意义说明串的待分析性质条件,其中,变量标识名与物理意义说明串唯一对应, #代表任意特殊字符符号;
3-2:对约束一致性问题的形式化模型,施加以对象约束语言形式的约束条件,该约束条件使用关键字“约束”表示约束体开端,关键字“上下文”表示约束头部,约束内应定义被施加约束的类名、类型以及约束演算公式或布尔表达式;
3-3:对行为一致性问题的形式化模型,施加待分析性质条件,需从状态图模型和顺序图模型中分别提取相应的所有消息路径,所述顺序图模型中提取所有消息路径是根据每条生命线进行提取;所述顺序图模型中提取所有消息路径是根据定义的顺序图和状态图具有行为一致性规则,使得状态图模型中的消息路径中消息出现的顺序与顺序图模型中存在一条生命线的消息序列一致;
3-4:对状态逻辑错误问题的形式化模型,施加死锁、循环和状态可达性的验证待分析性质条件,所述死锁和循环的验证通过固定的命令实现;所述状态可达性的验证需在文件中为每个状态定义线性时序逻辑公式,该公式表达含义为状态节点表示的变量始终为初始值;
步骤4:分析各子问题的形式化模型是否满足各项已定义的性质条件
4-1:对变量一致性问题的形式化模型,获取每一个元组,搜索是否存在元素位于不同元组中,若存在则不满足变量一致性;
4-2:对约束一致性问题的形式化模型,使用模型检测工具USE演算对象模型中的具体真实状态与约束性质条件之间是否存在可满足解,若不存在可满足解,则证明当前形式化模型不满足约束性质条件,违反了约束一致性,由此可知标准类模型及标准对象模型之间存在逻辑矛盾错误,并可通过USE工具查询错误原因;
4-3:对行为一致性问题的形式化模型,将顺序图和状态图提取的消息路径进行比对,如消息顺序一致,则是顺序图和状态图是行为一致的,若消息序列不一致,则两图不具有行为一致性;
4-4:对状态逻辑错误问题的形式化模型,将得到验证工具的输入文件,通过命令行输入命令或图形界面进行验证,当存在死锁和循环时,验证工具会生成对应的错误路径文件保存错误路径;当存在状态不可达时,根据该状态对应的线性时序逻辑公式判断是否被满足,若满足,则状态为不可达,反之为可达。
2.根据权利要求1所述基于模型检测的标准模型分析方法,其特征在于所述状态图模型根据UML2.x规定的语法语义形式进行建模设计,其并发程序的每个进程都用一个状态图来表示,其状态图中仅包含:基本状态节点、初始伪状态节点和终止状态节点;所述状态图的语句中可以使用局部变量、共享变量、同步事件和异步事件,触发条件只能使用事件接收语句,守卫条件为布尔语句,动作可以包含事件发送语句、算术语句和赋值语句,所述事件接收语句格式为一个问号后接变量名或两个问号接变量名,其中一个问号为接收异步事件,两个问号为接收同步事件,事件发送语句为状态图名接感叹号接异步事件名或状态图名接两个感叹号接同步事件名。
3.根据权利要求1所述基于模型检测的标准模型分析方法,其特征在于所述通过状态图的对应关系转换,得到的层次自动机模型,其具体操作步骤如下:
a、为每个层次自动机定义边的候选条件,其条件为:层次自动机取出的事件与边的触发条件事件相同,以及边的守卫条件为真;
b、定义事件挑选语句,对同步事件和异步事件进行区分;
c、对满足候选条件的有触发条件边,执行该边的动作语句;同时,该自动机的所有下层顺序,自动机使用进程来实现;
d、每次执行完有触发条件的边之后都需要循环的判断是否有完备的状态和执行相应的无触发条件边,直到不存在完备的状态,所述是否有完备的状态为该状态在状态图中是活跃的并且该状态下层所有的顺序自动机的终止状态也是活跃的;
e、为每个层次自动机定义进程需要循环的挑选事件和执行边;
f、对每个层次自动机进行初始化,并为每个层次自动机发送开始事件,开始每个层次自动机对应的进程,所述层次自动机中的最上层有多个顺序自动机,开始事件则按随机顺序发送。
4.根据权利要求1所述基于模型检测的标准模型分析方法,其特征在于所述顺序图和状态图提取的消息路径进行比对,其具体的操作步骤如下:
a、从顺序图中提取消息路径;
b、从状态图中提取消息路径;
c、依照顺序,在状态图对应的消息路径中寻找顺序图对应的消息路径中的第一条消息,若不存在该消息,则切换至下一条顺序图所对应的消息路径,遍历该条顺序图对应的消息路径,并将状态图对应的消息路径和该路径进行比对,查看状态图对应的消息路径的消息顺序是否和顺序图模型的消息路径的消息顺序是一致的,若不一致,则进行下一条顺序图模型对应的消息路径的判断;若所有的消息路径都不一致,则两图不具有行为一致性;若一致,则两图具有行为一致性;若遍历完所有的消息路径都不存在,则两图是行为不一致的;若存在,则继续往后寻找顺序图模型的下一条消息。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011006772.8A CN112214401B (zh) | 2020-09-23 | 2020-09-23 | 一种基于模型检测的标准模型分析方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202011006772.8A CN112214401B (zh) | 2020-09-23 | 2020-09-23 | 一种基于模型检测的标准模型分析方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN112214401A true CN112214401A (zh) | 2021-01-12 |
CN112214401B CN112214401B (zh) | 2023-05-09 |
Family
ID=74050695
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202011006772.8A Active CN112214401B (zh) | 2020-09-23 | 2020-09-23 | 一种基于模型检测的标准模型分析方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN112214401B (zh) |
Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101504605A (zh) * | 2009-03-06 | 2009-08-12 | 华东师范大学 | 一种基于性质规约模式生成ltl公式的uml模型检测系统和方法 |
CN101673198A (zh) * | 2009-03-06 | 2010-03-17 | 华东师范大学 | 一种验证uml模型中动态行为与时序契约的一致性的方法 |
CN102426521A (zh) * | 2011-10-28 | 2012-04-25 | 东南大学 | 基于HybridUML和定理证明的CPS自适应性验证方法 |
CN103065000A (zh) * | 2012-12-11 | 2013-04-24 | 南京大学 | 一种基于模型驱动工程进行SysML状态机图分析验证的方法 |
CN103488568A (zh) * | 2013-09-30 | 2014-01-01 | 南京航空航天大学 | 一种嵌入式软件可信属性建模与验证方法 |
CN104375842A (zh) * | 2014-12-05 | 2015-02-25 | 中国人民解放军理工大学 | 一种自适应软件uml建模及其形式化验证方法 |
CN105049420A (zh) * | 2015-06-23 | 2015-11-11 | 天津大学 | 基于扩展uml的轻量级安全协议形式化验证方法 |
WO2016004806A1 (zh) * | 2014-07-07 | 2016-01-14 | 西安交通大学 | 基于程序约束构建的多线程程序输出唯一性检测与证据生成方法 |
CN108830085A (zh) * | 2018-06-13 | 2018-11-16 | 天津大学 | 基于扩展UML的Web应用形式化建模及验证方法 |
US20190129724A1 (en) * | 2017-05-22 | 2019-05-02 | Analytical Graphics Inc. | Formalized Execution of Model Integrated Descriptive Architecture Languages |
-
2020
- 2020-09-23 CN CN202011006772.8A patent/CN112214401B/zh active Active
Patent Citations (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN101504605A (zh) * | 2009-03-06 | 2009-08-12 | 华东师范大学 | 一种基于性质规约模式生成ltl公式的uml模型检测系统和方法 |
CN101673198A (zh) * | 2009-03-06 | 2010-03-17 | 华东师范大学 | 一种验证uml模型中动态行为与时序契约的一致性的方法 |
CN102426521A (zh) * | 2011-10-28 | 2012-04-25 | 东南大学 | 基于HybridUML和定理证明的CPS自适应性验证方法 |
CN103065000A (zh) * | 2012-12-11 | 2013-04-24 | 南京大学 | 一种基于模型驱动工程进行SysML状态机图分析验证的方法 |
CN103488568A (zh) * | 2013-09-30 | 2014-01-01 | 南京航空航天大学 | 一种嵌入式软件可信属性建模与验证方法 |
WO2016004806A1 (zh) * | 2014-07-07 | 2016-01-14 | 西安交通大学 | 基于程序约束构建的多线程程序输出唯一性检测与证据生成方法 |
CN104375842A (zh) * | 2014-12-05 | 2015-02-25 | 中国人民解放军理工大学 | 一种自适应软件uml建模及其形式化验证方法 |
CN105049420A (zh) * | 2015-06-23 | 2015-11-11 | 天津大学 | 基于扩展uml的轻量级安全协议形式化验证方法 |
US20190129724A1 (en) * | 2017-05-22 | 2019-05-02 | Analytical Graphics Inc. | Formalized Execution of Model Integrated Descriptive Architecture Languages |
CN108830085A (zh) * | 2018-06-13 | 2018-11-16 | 天津大学 | 基于扩展UML的Web应用形式化建模及验证方法 |
Non-Patent Citations (5)
Title |
---|
DAMIANO TORRE: "Verifying the consistency of UML models", 《2016 IEEE INTERNATIONAL SYMPOSIUM ON SOFTWARE RELIABILITY ENGINEERING WORKSHOPS (ISSREW)》 * |
XIAORAN ZHU等: "Toward a Unified Executable Formal Automobile OS Kernel and Its Applications", 《IEEE TRANSACTIONS ON RELIABILITY》 * |
刘静: "基于形式规格说明的统一软件建模系统的研究", 《中国优秀博硕士学位论文全文数据库(博士)信息科技辑》 * |
应云辉,张民: "基于SMT的时钟约束语言CCSL的形式化分析方法与工具", 《软件学报》 * |
许涵斌: "面向开源代码的UML模型库构造方法", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》 * |
Also Published As
Publication number | Publication date |
---|---|
CN112214401B (zh) | 2023-05-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
Torlak | A constraint solver for software engineering: finding models and cores of large relational specifications | |
Olivé | Conceptual schema-centric development: A grand challenge for information systems research | |
Halkidi et al. | Data mining in software engineering | |
CN107783758B (zh) | 一种智能合约工程方法 | |
Wang et al. | Formalizing and integrating the dynamic model within OMT | |
Bollig et al. | Learning communicating automata from MSCs | |
Flouris et al. | A Classification of Ontology Change. | |
Le et al. | Interactive program synthesis | |
Losemann et al. | MSO queries on trees: enumerating answers under updates | |
CN116661756B (zh) | 一种基于低代码dsl的对象解析方法及装置 | |
Oluwagbemi et al. | Automatic generation of test cases from activity diagrams for UML based testing (UBT) | |
Deutch et al. | A structural/temporal query language for business processes | |
Dubslaff et al. | Enhancing probabilistic model checking with ontologies | |
CN110633084B (zh) | 基于单个样例的代码转换推导方法和装置 | |
CN115469860B (zh) | 基于指令集的需求到软件领域模型的自动生成方法及系统 | |
Abid et al. | A Real-Time Specification Patterns Language | |
CN116776981A (zh) | 基于大型预训练语言模型的api关系推理方法及系统 | |
CN115080448B (zh) | 一种软件代码不可达路径自动检测的方法和装置 | |
CN112214401A (zh) | 一种基于模型检测的标准模型分析方法 | |
Wißmann et al. | Quasilinear-time computation of generic modal witnesses for behavioural inequivalence | |
Tatale et al. | A Survey on Test Case Generation using UML Diagrams and Feasibility Study to Generate Combinatorial Logic Oriented Test Cases. | |
Otto et al. | A flow graph based approach for controlled generation of aas digital twin instances for the verification of compliance check tools | |
Krogmeier et al. | Synthesizing axiomatizations using logic learning | |
CN113434658A (zh) | 火电机组运行问答生成方法、系统、设备及可读存储介质 | |
Tukaram | Design and development of software tool for code clone search, detection, and analysis |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant |