鉴源论坛 · 观模丨形式化工程方法之需求建模(上)

作者 | 杨坤 上海控安可信软件创新研究院系统建模组

版块 | 鉴源论坛 · 观模

社群 | 添加微信号“TICPShanghai”加入“上海控安51fusa安全社区”

引言:需求建模是整个软件开发、测试验证与维护的基础。经过长期研究与实践,工业界与学术界均意识到,采用形式化方法精确地描述软件需求,并确认其充分而准确地反映了人们对软件功能和运行场景的预期,是一种从源头确保软件质量的重要手段。

01

为什么需要需求建模

嵌入式控制软件作为电子产品中的主体,广泛地应用于诸多领域的控制系统中。如军事国防领域的轰炸机和洲际导弹;工业控制领域的分布式控制系统;人类生活领域的智能穿戴设备和汽车控制系统。而这些系统的安全性和可靠性都依赖这些嵌入式控制系统,如果这些嵌入式设备没有按照预期设计工作,则会导致不可预估的财务损失和人员伤亡风险。在1996年6月4日,欧洲安丽雅娜5型火箭因为惯性一个数据转换问题导致了火箭在发射40秒时发生了爆炸,造成了合计25亿美元的经济损失56。2003年8月14日,在美国电力检测和控制管理系统中,因为同一资源同时被分布式计算机系统访问引发了软件失效,造成了美国大面积停电,损失合计超60亿美元。2011年7月23日,甬温线由于其列车控中心设备在设计时存在严重的缺陷,当雷雨天气下,保险管遭雷击熔断后,中心采集驱动单元的数据不再更新错误的控制信号而导致的,并最终导致了18人死亡,190人受伤。

需求分析作为经典V字模型的第一步,也是最关键的一步,直接影响V字模型中后续的设计、开发以及编码阶段。如何通过高质量的需求来为嵌入式控制系统的安全性和可靠性保驾护航也备受关注。美国曾在1995年做过一个调研,对全国合计8000个软件调查的追踪结果表明,所有失败的项目中因为需求引发的占到了45%。在另一项研究中也发现,能在软件开发过程中的需求阶段发现问题相比于在编码后发现问题再进行修改代价的十分之一。

基于软件工程的理论和实践,开发工程师认识到通过采用有效的软件需求描述,从源头上确保控制系统的安全性和可靠性是一种行之有效的方法。

02

是什么让需求建模变得困难

尽管形式化方法对保证软件可信性展示了令人鼓舞的前景,然而,在当前的嵌入式控制软件开发领域,例如航空航天领域和轨道交通领域,形式化方法的实际应用仍是一个巨大的挑战,大量深层次的问题有待解决:

1)原始需求控制逻辑不清晰,描述不完备

在原有的需求文档中,由于软件中某些具体功能未能表达准确,这使得其他工程师无法通过查看需求文档对整个系统的架构和控制逻辑有着清晰的认知。因此,其他工程师也难以将控制流以及其中数据流逻辑特征从需求中完整抽取出来并进行分析,导致其中存在的一些潜在问题无法被及时发现。

很多需求描述本身存在不完备的问题,比如对某些输入的取值范围定义不明确以及某些变量的取值空间模糊等问题。特别是在原有的需求文档中,存在许多变量在使用前未严格定义。而这些变量往往直接使用在其功能需求的描述,并且工程人员也难以准确地给出其类型或者初始值。另一方面,需求文档在经过多个需求工程师的撰写修改后,会引入一些明细的逻辑错误,尤其是自然语言撰写的需求本身就存在模糊性以及二义性,对需求规约是一大挑战。

2)领域专用需求建模语言的缺乏

如何使用一种方法将需求文档中的自然语言向需求模型进行转换,并且能够使用精准的需求建模语言对其进行描述,是将形式化方法工程化的核心关键。从软件工程的角度出发,需求描述的质量将直接影响到后续软件的正确性以及可靠性。如何设计具有高可读性的需求建模语言来精准描述整个汽车控制系统的需求,并且需要让不论是需求工程师还是开发人员都能够在无需形式化背景的人快速上手正确理解都是需要考虑的问题。

3)需求确认方法的局限性

需求确认通常侧重于检查需求描述是否充分且准确反映了用户对软件功能的期望。当前在工业界常用的需求确认方法主要是需求文档的审查,学术界提出的其他方法包括规约的测试和动画等。但是,这些方法缺乏严谨性和系统性,特别是缺乏和形式化理论的有机融合,使得需求确认的效果往往不如人意。

03

一种面向机载控制软件需求建模的形式化工程方法

针对上述问题,我们提出了一套以形式化方法理论为基础能够使用在嵌入式控制系统的工程化方法,该方法有助于需求工程师快速实现对嵌入式软件需求的精确描述以及实现需求工程师对需求模型的确认。

我们以机载控制系统为研究对象,将该形式化工程方法应用在航空领域,提出了一套用于引导机载控制系统的形式化规约和需求确认的形式化工程方法。

图一.png

图1 形式化工程方法框架

整体的形式化工程方法主要划分为两个模块:需求模型提取以及需求模型的确认。本文主要介绍需求模型的提取。

04

需求模型提取

需求模型提取总共经历三个阶段:

1) 由工程师根据其工程经验和专业知识使用自然语言人工编写原始的自然语言需求。

2) 根据具体的领域特征,研制一种具有针对性的形式化描述模板,此模板本质是对用户输入自然语言进行一定的规整化,形成特定的形式化需求呈现形式,方便工程人员在不需要学习形式化知识的前提下就可以使用形式化描述需求。

3) 对于目标系统的需求文档进行深度调研,提取该领域软件的特征,提出面向该领域的需求描述语言,该语言具有严格的形式化语法及语义,使用该语言将半形式化需求文档完全规约化,得到形式化需求规约,形式化需求规约可经由需求确认的方法来确保需求文档的正确性、有效性以及完备性。

图二.png

图2 需求模型提取

自然语言需求

基于模型开发的软件大部分的都是从需求的获取以及分析着手,但是因为对系统的预期功能在软件开发初期往往都不够明确,并且每个参与者的知识背景也不尽相同,因此采用易于人交流和理解的自然语言完成初期的需求文档的设计能够更加便于需求分析人员与领域工程人员的交流,其文档可读性也会比用符号表示的形式化文档有明显的优势。 

但自然语言在有着可读性高和易于理解的好处的同时也存在着模糊性以及二义性的问题,可能会存在对同一句话不同的人也有着不同的理解。比如,处于初始化状态连续执行超过250ms,则故障等级增加一级。对于这条需求就可能会引发一个歧义性,一旦处于初始化状态连续执行达到了一秒钟,那么风险等级应该增加一级还是应该增加四级呢,这种问题积累下来将为后续的开发和测试埋下了不少隐患。

半形式化需求

传统的使用自然语言撰写的需求因为其通俗易懂的特点而广泛使用,然而由于自然语言描述存在显而易见的二义性和模糊性,我们必须将其转换为更精确的半形式化需求模型。规定半形式化需求文档中,任何数据结构必须是形式化定义的,即变量的数据类型被精确描述。而变量之间的关系可以仍然是非形式化的。半形式化需求模型主要基于工程上可行性的考虑,为此我们提出了如图3所示的需求文档模板。该模板包含了对于数据结构或系统结构等易于形式化的系统特征的精确描述。

图三.png

图3 半形式化需求文档模板示例

从软件工程的角度来说,建模者对软件功能的理解往往是伴随着文档撰写而逐渐清晰,因此文档必然需要多次变更修改。如果直接撰写形式化需求,不仅技术上困难,其变更也会带来巨大的时间和成本损失。反之,我们提供半形式化需求阶段,建模者只需要先关注变量的数据结构特征,而暂时以自然语言表述其关联关系,待建模者确认需求文档确实已经充分描述了功能以后,再将其向完全形式化模型转化。在此过程中,即使系统功能发生变化,其修改的代价也是可以接受的。另一方面,当数据结构清晰之后,需求分析者对于功能的理解也随之深入,更有利于撰写需求规约。

形式化需求

考虑到嵌入式工业控制系统具有对功能正确性可靠性要求高、控制数据流结构复杂以及周期执行的特点,将这样的信息处理系统的需求定义包含以下特点:

1. 变量集合:ACSDL 软件需求将不同来源的信息和数据都定义为了对应的信息变量,根据这些信息变量的值,来进行相应的处理。因此,ACSDL软件需求是一系列变量的集合。

2. 面向计算:嵌入式工业控制系统每个模块都是结合实时的物理环境数据来执行的计算任务。其中涉及到包含逻辑操作以及数值的计算等大量的计算。

3. 周期性:工业软件的运作是一个连续的动态的过程,ACSDL 为了及时地对软件进行控制,需要不间断的获取各类信息,并及时的进行响应。然而机器本身是离散的,为了模拟这种连续性的要求,ACSDL 系统将物理时间切分成一些很短的时间间隔,即周期(Cycle)。并严格要求在一个周期内,需求变量的状态是不变的。

4. 状态机驱动:嵌入式工业控制系统的会根据每个周期所处的实际状态,来进行不同的计算任务以及状态间的切换来实现实际的控制效果。

考虑到嵌入式工业控制系统的特征,为了有效描述航空发动机的嵌入式控制软件需求,我们提出了一种轻量级的形式化建模语言ACSDL,用于撰写最终的形式化需求规约。ACSDL对于控制软件有良好的描述能力,包括支持时间周期等诸多领域特征。

在完成了对半形式化文档的检查之后,工程人员可以采用ACSDL语言将规约完全形式化,即通过ACSDL语言将每个功能输入和输出变量之间的关系予以精确化定义,并将所有全局约束条件等予以形式化定义。    

图四.png

图4 形式化需求文档实例

图4展示了图3所示功能的形式化描述。一般来说,构建形式化描述的过程,对工程人员来说是促使他们对需求内涵进行思考的过程。一些模糊的需求在这个过程中被逐步明晰。

05

总 结

本文主要介绍了形式化工程方法中的需求建模技术,该方法有助于需求工程师快速实现对嵌入式软件需求的精确描述以及实现需求工程师对需求模型的确认,从源头上保证软件的正确性。本文具体介绍了需求建模技术中的需求模型提取部分,剩下的需求确认部分将在后续文章中介绍。

主要参考文献:

[1] 佚名. 阿丽亚娜5型火箭——首发失利 空中爆炸[J]. 航空知识, 1996(7):50-50. 

[2] 席琳. 形式化方法在构件组装实时系统中的应用研究[D]. 郑州大学, 2012:1-1. 

[3] 程平, 刘伟, 陈艳. 我国可信软件产业的发展现状与应对策略[J]. 科技进步与对策, 2010(03):51-54. 

[4] 钟新文. 甬温铁路动车追尾 40人遇难[J]. 广东交通, 2011, 2011(4):48-48. 

[5] Filax M ,  Gonschorek T ,  Ortmeier F . Correct Formalization of Requirement Specifications: A V-Model for Building Formal Models[C]// International Conference on Reliability, Safety and Security of Railway Systems. Springer International Publishing, 2016. 

[6] 王知强. 管理信息系统入门与提高[M]. 清华大学出版社, 2005:190-190.

[7] Meditskos G ,  Bassiliades N . Structural and Role-Oriented Web Service Discovery with Taxonomies in OWL-S[J]. IEEE Transactions on Knowledge and Data Engineering, 2010, 22(2):278-290.

  • 20
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
在传统的软件工程中,需求分析阶段是软件开发生命周期的重要环节之一。在需求分析阶段,通常会使用一些模型来帮助理解、描述和规范软件系统的需求。以下是一些常用的传统需求分析模型: 1. 数据流图(Data Flow Diagram,DFD):数据流图是一种图形化的模型,用于描述系统中的数据流动和处理过程。它通过图形表示数据流、处理功能和数据存储之间的关系,帮助分析人员理解系统的功能和数据流动。 2. 数据字典(Data Dictionary):数据字典是一个集中管理和描述系统数据元素、数据结构和数据流的文档。它定义了系统中使用的各种数据项、数据类型、数据结构和数据流,帮助确保对数据的一致性理解。 3. 用例图(Use Case Diagram):用例图是一种行为模型,用于描述系统与外部参与者之间的功能交互。它通过图形表示参与者、用例和其之间的关系,帮助分析人员理解系统的功能需求和参与者角色。 4. 面向对象建模(Object-Oriented Modeling):面向对象建模通过使用类图、对象图和时序图等模型来描述系统中的对象、类和它们之间的关系。它强调对系统进行对象化的分析和设计,帮助理解系统的静态结构和动态行为。 5. 状态转换图(State Transition Diagram):状态转换图用于描述系统中对象或系统的状态及其之间的转换。它通过图形表示状态、事件和转换,帮助分析人员理解系统的状态变化和响应规则。 这些模型在传统软件工程中被广泛应用,可以帮助分析人员和利益相关者更好地理解和沟通系统的需求。它们提供了一种结构化的方法来描述和规范系统需求,以确保开发过程的准确性和一致性。然而,随着软件工程的发展,现代方法和技术也提供了更多灵活和交互式的方式来进行需求分析

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值