CN109815131B

CN109815131B - 轨道交通车载软件半形式化需求用的静态检查系统及方法

Info

Publication number: CN109815131B
Application number: CN201811611287.6A
Authority: CN
Inventors: 常鸣; 陈慧琍; 陈晓轩; 陈硕豪; 熊坤鹏
Original assignee: Casco Signal Ltd
Current assignee: Casco Signal Ltd
Priority date: 2018-12-27
Filing date: 2018-12-27
Publication date: 2022-06-24
Anticipated expiration: 2038-12-27
Also published as: CN109815131A

Abstract

本发明涉及一种轨道交通车载软件半形式化需求用的静态检查系统及方法，系统包括：语法分析模块对输入语法分析模块的需求进行检查分析，通过后生成抽象语法树；影响关系分析模块以语法分析模块产生的需求抽象语法树作为输入，分析各条需求之间的影响关系；类型检查模块，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值情况；量纲检查模块若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值情况。与现有技术相比，本发明具有能提高需求验证的效率，节省时间，降低成本等优点。

Description

轨道交通车载软件半形式化需求用的静态检查系统及方法

技术领域

本发明涉及一种静态检查系统及方法，尤其是涉及一种轨道交通车载软件半形式化需求用的静态检查系统及方法。

背景技术

软件开发过程中，需求是用户与产品提供商，或系统分析师与开发团队间的契约，其质量影响着最终产品的开发进度及其质量。一份精确、完整、一致、可追溯的需求规约，可避免开发人员的理解偏差，极大帮助后续的设计编码以及测试工作；并且，通过细致的需求分析，可以在开发的早期阶段发现潜在问题，及时修复，降低处理问题的代价。

近年来，随着我国轨道交通行业高速发展，车载控制器软件的功能需求日益复杂，而对于这类安全苛求软件的开发中，尤其应强调需求的质量。此类产品开发周期和使用寿命较长，同时对于安全和可靠性要求非常高，必须要做到软件的每一步都是可控、可预测和可验证的。

所以，软件需求规约的正确性分析检查对于整个软件质量保证体系显得尤为重要。根据铁路安全软件开发规范的要求，推荐安全软件使用式化、半形式化或建模的方式进行描述，一般采用状态机、真值表、或结构化语言等技术手段。但是，在需求阶段，尚无可执行的代码去观测和反馈需求本身是否正确，只能依靠人工对需求文档进行审核，效果依赖于验证人员的经验和精力的投入程度。如果想提高需求质量，必须投入较高人力成本，从而避免在设计或编码阶段才发现需求错误导致更大的返工。

传统的人工检查存在以下不足：

(1)依赖个人经验，缺少固定量化标准；安全苛求软件需求描述的业务专业，而半形式化的描述方式也相对晦涩，检查人员不仅要精通业务也要熟悉需求描述方式，同时，目前采样的检查单等工具往往是定性且概括的；

(2)工作量大，容易疏漏；安全苛求软件需求由于其精确性要求，条目多且内容多含工程计算，人工检查的工作量大，成本高，伴随检查周期的增加，出错率往往同步增加；

(3)周期较长，无法在线检查；一轮完整的人工检查往往持续数周，无法对每次需求升级都进行检查。

因此，基于车载控制器软件需求本身采用的形式化、半形式化描述方式，实现一种需求的静态检查系统，提供一套比人工检查更高效的正确性验证方法，对于降低铁路安全软件的开发成本、提高质量有巨大的帮助。

发明内容

本发明的目的就是为了克服上述现有技术存在的缺陷而提供一种轨道交通车载软件半形式化需求用的静态检查系统及方法。

本发明的目的可以通过以下技术方案来实现：

一种轨道交通车载软件半形式化需求用的静态检查系统，包括：

语法分析模块，用于将事先定义的半形式化需求语法以特定的范式形成词法器和语法器并作为语法分析模块的基础，对输入语法分析模块的需求进行检查分析，通过后生成抽象语法树；

影响关系分析模块，用于以语法分析模块产生的需求抽象语法树作为输入，分析各条需求之间的影响关系；

类型检查模块，用于根据影响关系分析模块产生的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值情况；对于事先没有定义变量类型的需求，则分析需求变量之间的类型转换以及赋值是否存在矛盾；

量纲检查模块，用于对通过类型检查模块的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值情况；对于事先没有定义变量量纲的需求，则分析需求变量之间的量纲转换以及赋值是否存在矛盾。

优选地，所述的语法分析模块对于违反词法器和语法器规则的输入需求则不能生成抽象语法树并提示报错。

优选地，所述的影响关系分析模块分析各条需求之间的影响关系包括需求之间的调用和被调用关系，形成影响关系图。

优选地，所述的类型检查模块分析过程中发现异常则提示报错。

优选地，所述的量纲检查模块分析过程中发现异常则提示报错。

一种所述的轨道交通车载软件半形式化需求用的静态检查系统的方法，包括以下步骤：

步骤S1：将事先定义的半形式化需求语法以设定的范式形成词法器和语法器，并作为语法分析模块的基础，对输入语法分析模块的半形式化需求进行语法检查分析；另外，当步骤S8提示错误并返回，则根据相应的错误提示，修改需求，再次进行语法检查；

步骤S2：判断步骤S1中的语法检查是否通过，如果检查失败，则通过步骤S8提示错误并返回，如果检查通过，则将步骤S1的输入需求生成抽象语法树传入步骤S3；

步骤S3：以语步骤S2产生的需求抽象语法树作为输入，分析各条需求之间的影响关系，包括需求之间的调用和被调用关系，形成影响关系图；

步骤S4：根据步骤S3产生的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值情况；对于事先没有定义变量类型的需求，则分析需求变量之间的类型转换以及赋值是否存在矛盾；

步骤S5：判断步骤S4中的类型检查是否通过，如果检查失败，则通过步骤S8提示错误并返回，如果检查通过，则进入步骤S6；

步骤S6：以通过步骤S5的需求影响关系图作为输入，对于相互间存在影响关系的需求，若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值情况；对于事先没有定义变量量纲的需求，则分析需求变量之间的量纲转换以及赋值是否存在矛盾；

步骤S7：判断步骤S6中的量纲检查是否通过，如果检查失败，则通过步骤S8提示错误并返回，如果检查通过，则结束整个需求静态检查过程；

步骤S8：提示错误并返回步骤S1。

与现有技术相比，本发明具有以下优点：

1、相较于传统的人工需求验证方式，本技术方案能提高需求验证的效率，节省时间，降低成本。

2、相较于传统的人工需求验证方式，本技术方案能通过分析结构化需求描述语言和功能点交互关系的方式，检查出更多的错误，提高需求规范的质量。

3、相对于形式化证明方法或者人工需求验证，该技术方案上手简单，便于系统分析、开发和测试人员掌握。

附图说明

图1为本发明的结构示意图；

图2为本发明的工作流程图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明的一部分实施例，而不是全部实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应属于本发明保护的范围。

本实施例中，将面向轨道交通车载软件半形式化需求的静态检查系统应用于测试车载控制器软件的列车信标初始化定位状态管理功能。

如图1所示，是本发明面向轨道交通车载软件半形式化需求的静态检查系统的结构示意图。本实施例中面向轨道交通车载软件半形式化需求的静态检查系统包括：语法分析模块M1，影响关系分析模块M2，类型检查模块M3以及量纲检查模块M4。

其中，语法分析模块M1将事先定义的半形式化需求语法以特定的范式形成词法器和语法器并作为语法分析模块的基础，对本模块的需求进行检查分析，通过后生成抽象语法树。这里，车载控制软件的半形式化需求的语法定义为：

影响关系分析模块M2以语法分析模块M1产生的需求抽象语法树作为输入，分析各条需求之间的影响关系，包括需求之间的调用和被调用关系，形成影响关系图。

类型检查模块M3根据影响关系分析模块M2产生的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值等情况，支持的类型包括但不限于整型、浮点型、布尔型以及枚举型等，例如，检查整型和浮点型之间是否被误转换；对于事先没有定义变量类型的需求，则分析需求变量之间的类型转换以及赋值是否存在矛盾；分析过程中发现异常则提示报错。

量纲检查模块M4对通过类型检查模块M3的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值等情况，通常在车载控制器软件需求中涉及到的量纲类型包括时间、距离、速度以及加速度等，例如，检查米和毫米之间是否正确转换；对于事先没有定义变量量纲的需求，则分析需求变量之间的量纲转换以及赋值是否存在矛盾；分析过程中发现异常则提示报错。

如图2所示，本实施例面向轨道交通车载软件半形式化需求的静态检查系统用于分析检查某一版本车载控制器软件需求的一具体过程，包括以下步骤：

步骤S1，以列车重定能功能中的某一条半形式化需求为例：

(VAR1(k-1)and VAR2(k))

and(VarOdo(k)＝＝INITIALIZED)and VarERF2(k)

and(VARRESULT＝(VAR3(k-1).Uncertainty-(VAR4(k)-

VAR5(k))))

or

(VAR1(k-1)and VAR2(k))

and(VarOdo(k)＝＝INITIALIZED)and(not VarERF2(k))

and(VARRESULT＝(VAR3(k-1).Uncertainty+(VAR4(k)

-VAR5(k))))

or

(VAR1(k-1)and VAR2(k))

and(VarOdo(k)！＝INITIALIZED)

and(VARRESULT＝(VAR3(k-1).Uncertainty+

abs(VAR4(k))+abs(VAR5(k))))

or

(not(VAR1(k-1)and VAR2(k)))

and(VARRESULT＝0)

对其进行检查分析，通过后生成抽象语法树如下：

步骤S2：判断步骤S1中的语法检查通过，将步骤S1的输入需求生成抽象语法树传入步骤S3；

步骤S3：分析步骤S2传入的需求抽象语法树中各条需求之间的影响关系，分析后发现示例需求与其它七条需求存在相互影响关系；

步骤S4：根据步骤S3产生的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值等情况；分析后发现示例需求中涉及的变量类型均已事先定义，类型包括整型、布尔型以及枚举型，涉及到的运算为整型变量间的运算，示例需求的变量类型转换正确；

步骤S5：判断步骤S4中的类型检查通过，进入步骤S6；

步骤S6：以通过步骤S5的需求影响关系图作为输入，对于相互间存在影响关系的需求，若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值等情况；分析后发现示例需求中涉及的变量量纲均已事先定义，涉及到的运算位距离量纲(毫米)，示例需求的变量量纲转换正确

步骤S7：判断步骤S6中的量纲检查通过，结束该示例需求的需求静态检查，继续下一条需求；

步骤S8：提示错误并返回步骤S1。

本实施例中，该版本的车载控制器软件半形式化需求，在本发明基面向轨道交通车载软件半形式化需求的静态检查系统中分析检查，结果显示存在两处量纲转换错误。

以上所述，仅为本发明的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到各种等效的修改或替换，这些修改或替换都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以权利要求的保护范围为准。

Claims

1.一种用于轨道交通车载软件半形式化需求用的静态检查系统的方法，其特征在于，所述静态检查系统包括：

语法分析模块M1，用于将事先定义的半形式化需求语法以特定的范式形成词法器和语法器并作为语法分析模块的基础，对输入语法分析模块的需求进行检查分析，通过后生成抽象语法树；

影响关系分析模块M2，用于以语法分析模块M1产生的需求抽象语法树作为输入，分析各条需求之间的影响关系；

类型检查模块M3，用于根据影响关系分析模块M2产生的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的类型，则据此分析需求变量之间的类型转换以及是否存在不同类型需求变量赋值情况；对于事先没有定义变量类型的需求，则分析需求变量之间的类型转换以及赋值是否存在矛盾；

量纲检查模块M4，用于对通过类型检查模块M3的需求影响关系图，对于相互间存在影响关系的需求，若事先已定义需求变量的量纲，则据此分析需求变量之间的量纲转换以及是否存在不同量纲的变量赋值情况；对于事先没有定义变量量纲的需求，则分析需求变量之间的量纲转换以及赋值是否存在矛盾；

所述的影响关系分析模块M2分析各条需求之间的影响关系包括需求之间的调用和被调用关系，形成影响关系图；

所述方法包括以下步骤：

步骤S8：提示错误并返回步骤S1。

2.根据权利要求1所述的方法，其特征在于，所述的语法分析模块M1对于违反词法器和语法器规则的输入需求则不能生成抽象语法树并提示报错。

3.根据权利要求1所述的方法，其特征在于，所述的类型检查模块M3分析过程中发现异常则提示报错。

4.根据权利要求1所述的方法，其特征在于，所述的量纲检查模块M4分析过程中发现异常则提示报错。