基于模型的软件需求验证方法研究与应用

陈弘博

(北京全路通信信号研究设计院集团有限公司，北京 100070)

1 软件需求验证

1.1 软件需求验证的必要性

软件从开始开发到报废的全过程称为软件生命周期，主要包括问题定义及规划、需求分析、软件设计、程序编码、软件测试和运行维护六个阶段，其中需求分析阶段是一个非常重要的阶段，它是问题定义及规划阶段成果的汇总，是后续各阶段开展的依据，良好的软件需求分析将为整个软件开发项目的成功打下良好的基础，因此验证软件需求的正确性、完备性等变得尤为重要。

本文拟采用基于模型的软件需求验证工具ZIPC开展需求验证工作，从而验证基于模型的软件需求验证方法的可行性。

1.2 ZIPC工具及STM技术简介

ZIPC工具（简称ZIPC）是日本嵌入式应用领域计算机辅助软件工程（CASE）工具，在业界有二十多年的应用，能够提供高效的开发环境和高可靠质量保证。ZIPC应用在“分析-设计-测试”各阶段中，同时为顶层设计和底层开发提供无缝集成的开发环境。

ZIPC进行软件需求验证采用的重要技术为状态转移矩阵（State Transfer Matrix，STM）技术，ZIPC使用STM作为基本的输入，采用STM的方法用户可以在ZIPC环境下方便进行仿真、实现和系统测试；不仅于此，应用EHSTM（可扩展分层STM）技术ZIPC可以处理复杂而庞大的系统。通过STM技术，可以更易于查找缺陷。设备电源上下电的STM状态迁移矩阵示例如图1所示。

图1 设备电源上下电STM状态转移矩阵示例图Fig.1 STM Demonstration as equipment power on/off

1.3 基于模型的软件需求验证原理

基于模型的软件需求验证重点在于验证软件需求中早期遗漏的问题，尤其是软件需求中或程序编码中未考虑的异常情况的处理。在软件项目开发的过程中，需要根据理解并描述的需求进行软件开发，由于表达方式的限制、传达方法的问题，或者是价值观的不同，经常存在研制方与用户之间传递和解释的需求不一致的情况发生，导致最终开发出的程序与用户需求存在差异，或者是存在遗漏未考虑的情况。通过借助ZIPC构建STM图，理清软件中所有的状态、事件以及状态之间的迁移，部署在STM表格中，可以及时发现需求中的遗漏问题。构建STM图的过程如图2所示。将文本格式的软件需求规范部署在状态迁移矩阵中，发现其中遗漏的软件需求，同时仿真验证软件需求中遗漏部分的处理情况，达到不断完善软件需求规范的目的。软件需求规范验证过程如图3所示。

图2 状态迁移矩阵STM构建过程Fig.2 Build Process of STM

2 基于模型的软件需求验证实践与应用

2.1 应用对象选取

本文选取临时限速服务器（TSRS）软件适配“CTCS-3级列控系统增加自动驾驶（ATO）功能”作为基于模型的软件需求验证项目。为满足CTCS-3级列控系统增加ATO功能的系统需求和安全需求，TSRS软件修改及新增涉及以下功能需求：系统启动、车地通信、屏蔽门联控、列车运行计划和折返信息发送、数据配置、安全层适配、异常处理等功能需求，因TSRS软件功能较多且复杂，除新增ATO相关功能外，还有既有的临时限速管理等功能，试用时重点针对车地通信（包括列车注册、列车注销、车地周期通信机制、站台门联动控制通信机制等）的软件需求进行验证。

图3 软件需求规范验证过程Fig.3 Verification process of software requirement specification

2.2 软件需求验证建模过程

由TSRS软件需求规范构建ZIPC所需的STM状态转移矩阵的过程共包含2个阶段：首先由流程图转换为状态图STD，之后由STD图转换为STM图。因TSRS软件车地通信功能需求包含较多的流程，下面选取其中的车门和站台门联动控制流程作为示例演示。

1) 由软件需求规范中流程图转换为状态图STD。

车门和站台门联控车地通信流程如图4所示，通过对站台门联动控制通信机制的分析和理解，提取得到TSRS主机软件涉及的状态有6个，分别为：注册状态（login）、正常通信状态(wait_position)、开屏蔽门状态（OpenDoors）、关屏蔽门状态（CloseDoors）、连接中断状态(M136_interrupt)、连接断开状态(idle)；所涉及的事件有8个，分别为：列车注册成功（login_succeed）、 收到消息M136(M136_CTCS26)、发送消息M24(timer_M24==T_ATP)、收到开屏蔽门命令(M136_CTCS24_open)、检查屏蔽门状态定时器到时(timer_M24CTCS23==6)、 收到屏蔽门打开消息(doorsOpen)、收到关屏蔽门命令(M136_CTCS24_close)、收到屏蔽门关闭消息(doorsClose)，进而得到车门的站台门联动控制过程的状态图，STD如图5所示。

图4 车门和站台门联控车地通信数据Fig.4 Train-ground communication data for linkage control of train doors and platform screen doors (PSD)

图5 车门与站台门联动控制功能模块STD状态图Fig.5 STD state diagram of linkage control function modules of train doors and PSDs

2）由STD状态图转换为STM状态转移矩阵。

将STD状态图中的事件和状态，以及状态之间的转换关系部署在状态转移矩阵中得到STM表如图6所示。

3 应用结果分析

通过使用ZIPC基于模型的软件需求验证工具，对TSRS软件的车地通信（包括列车注册、列车注销、车地周期通信机制、站台门联动控制通信机制等）的软件需求进行验证，在部署STM图的过程中发现如下两处潜在的死循环的隐患，如下：

图6 屏蔽门联动状态迁移表Fig.6 State transfer table of PSD doors linkage operation

1）列车注册过程中若在等待M146确认消息包的过程中，列车与TSRS设备通信中断，列车发送任意消息通信恢复，重复之前的注册流程，注册过程中仍会存在列车与TSRS设备通信中断的可能，导致列车与TSRS设备在通信连接与通信中断之间无限循环的隐患，如图7所示。

2）车地联动控制过程中，若TSRS通过列控中心驱动屏蔽门开门或关门过程中，屏蔽门开、关门异常，无法正常开关门，则列车和TSRS设备会持续处于等待列车开门或关门的状态，如图8所示。

通过STM图可发现存在某些状态缺少对部分事件响应的异常处理的情况， 另外通过分析部署的多个STM图，以及不同STM图之间的交互关系，能够发现未考虑的不同的流程之间数据交互的异常情况，如TSRS与列车处于正常周期通信状态，若列车发送数据出错，TSRS接收到注册过程中消息时的处理情况等。

4 总结

图7 通信中断状态下收到任意消息可能导致死循环Fig.7 Any message received in communication interruption state may cause endless loop

图8 无法正常开关门可能导致持续等待Fig.8 Fail to open/close doors may cause continuous waiting

软件需求分析的正确性和完备性是确保轨道交通信号控制产品安全稳定运行的重要前提。本文通过对基于模型的软件需求验证原理分析，提出了一种对软件需求进行建模并验证的方法，并结合具体应用，验证的该方法的有效性。此外，基于模型的软件需求验证方法及应用方案，不但可以有效提升需求分析的质量，还能够通过借助STM图全面了解软件中事件和状态的所有组合情况，有利于辅助设计测试用例，且设计的测试用例尽可能多的涵盖被测软件的可能情况，提升测试用例的全面性。

根据以上基于模型的软件需求验证的应用分析结果进行优化改进，有效的完善了TSRS软件关于车地通信及车门和站台门联动控制模块的需求，提升软件需求的正确性和完备性。相比传统的需求验证及评审方法，基于模型的软件需求验证方法能够更早的发现需求的缺陷，而这些缺陷，以往在软件研发周期的后续环节是很难发现或要付出更大的成本才能发现的。因此借助于本文所提出的软件需求验证方法能够有效提升需求验证工作的质量，降低项目需求风险。