CN108196827B - 非形式化需求规约模板到形式化设计模型的自动转换方法 - Google Patents

Abstract

本发明公开了一种非形式化需求规约模板到形式化设计模型的自动转换方法，通过基于限定自然语言的需求规约模板，以层次化的组织形式、限制的语言描述系统或构件，在此基础上进行需求规约形成非形式化的设计说明文档，并实现整个设计说明到AADL形式化设计模型的转换。本方法能够实现对需求描述的限定，减少因自然语言二义性而产生的人为因素造成的错误，规约形成非形式化的设计说明，并自动生成AADL初始设计模型。

Description

非形式化需求规约模板到形式化设计模型的自动转换方法

技术领域

本发明涉及一种非形式化设计说明的形式化转换方法，具体涉及一种非形式化需求规约模板到形式化设计模型的自动转换方法。

背景技术

随着嵌入式软件在航空电子、汽车工业、通信、核工业等安全关键领域的广泛应用，这类嵌入式系统必须保证系统的可靠性、安全性等相关性质，这类系统被称为安全关键系统(Safety Critical System)。保障这类系统的安全性、可靠性已经成为当前软件工程研究领域一个非常重要的课题。

安全性是指软件运行不引起系统危害的能力。当软件可以引起危害或者控制危害发生，则该软件是危险的。安全性分析(safety analysis)是保障安全性的一种广泛接受的方法。当前，针对软件的安全性分析工作主要集中在软件需求规约和软件设计阶段。然而在安全关键系统开发过程中，在需求描述阶段基本是采用自然语言文档来驱动。这种方式极大消耗人力和时间成本，且随着需求规模的扩大，需求文档也越发难以管理。自然语言文档最大的弊端在于，自然语言描述存在二义性、不完整性等问题，而设计完全依赖设计人员对自然语言需求文档的理解，由此导致需求和设计存在不一致，无法正确将安全性分析的结果及处理方法妥善表达在设计中，并造成最终交付的软件系统存在缺陷。这也是造成软件设计缺陷以及影响软件/系统安全性的根本原因之一。需求规约和设计建模作为软件开发过程中两个关键活动，如何实现两者之间的自动化转换受到了学术界和工业界的广泛关注。

岳涛教授等人针对传统UML用例规约描述存在的不足提出了一种限定用例建模(Restricted Use Case Modeling，RUCM)方法。它在UML用例模型的基础上，综合了自由文本和形式化语言的特点，即保证了需求的易理解性和精确性，同时又能够支持对需求进行自动化分析与验证.此外，在文献基于中间元模型UCMeta实现了RUCM到类图、顺序图、活动图的转换，并自动建立两者之间的追踪关系。此外，针对RUCM无法描述机载嵌入式软件的安全性需求的不足。吴际等对RUCM进行了扩展，添加相应的模板与限制规则，形成SafetyRUCM，使其支持安全性需求的规范化描述.然而这些工作主要从用例的角度进行需求描述，描述范围不全面，且不能充分反映嵌入式软件系统的需求特征。

为了能够清晰且无二义地描述航天型号软件的需求，董云卫等提出了航天需求描述语言SPARDL。SPARDL包括数据字典、模块和模式图三个部分，其中核心为模式图。经实践证明，SPARDL能在航天型号研究过程中有效地提高航天嵌入式软件的质量。但是SPARDL方法采用形式化需求描述方法，在实践过程中具有较大难度，且SPARDL是专门针对航天型号软件而设计，其通用性较差。

Alistair Mavin等人针对需求难以描述和表达的难题，在大量工程经验基础上，提出了一种EARS(Easy Approach to Requirements Syntax)[27]方法进行需求规约。该方法将需求大致分为Ubiquitous、Event-Driven、Unwanted Behavior、State-Driven、Optional Feature、Complex六类，并分别给出相应的需求表达模式。该方法可以有效简化需求的描述与表达难度，同时能够有效降低自然语言需求的相关缺陷，但这种需要描述方式主要针对的是功能需求，且描述范围具有一定的局限性。

安全关键软件领域常用的建模语言有UML/SysML、航空电子系统描述语言MetaH和HOOD(Hierarchical Object Oriented Design)、汽车电子系统描述语言EAST-ADL、分析设计与建模语言AADL等。

UML(Unified Modeling Language)统一建模语言，是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持。UML因其简单、统一的特点，而且能表达软件设计中的动态和静态信息，目前已成为可视化建模语言的工业标准。对象管理组织OMG通过对UML2.0的子集进行重用和扩展，提出一种新的系统建模语言——SysML(Systems Modeling Language)，作为系统工程的标准建模语言。但其相对而言更支持系统架构层面的描述，而无法更深入地表达设计。

复杂嵌入式实时系统的体系结构设计与分析语言标准——AADL(ArchitectureAnalysis and Design Language，AADL)是由美国汽车工程师协会SAE在MetaH、UML、HOOD的基础上，于2004年提出的一种嵌入式系统体系结构分析与设计语言，并发布为SAE AS5506标准。目的是提供一种标准而又足够精确的方式，设计与分析嵌入式系统的软、硬件体系结构及功能与非功能性质，采用单一模型支持多种分析的方式，将系统设计、分析、验证、自动代码生成等关键环节融合于统一框架之下。AADL具有语法简单、功能强大、可扩展的优点，具有广阔的应用前景，得到了欧美工业界，特别是航空航天领域的支持。

同步语言(Synchronous Languages)是嵌入式实时系统设计与分析中的一类重要的形式化建模语言。这类系统需要不间断地与周围的环境进行交互，包括物理设备或人工操作。因此也被称为反应系统。同步语言主要分为两类：命令式语言(imperativelanguage)，如Esterel，SyncCharts以及Argos等；声明式语言(declarative language)，如Lustre、Signal等。其中命令式语言适合对控制系统的描述而声明式语言适合描述数据流。但这两类都不适用于软硬件耦合紧密特性的系统描述。

发明内容

为解决现有技术的不足，本发明的目的在于提供一种非形式化需求规约模板到形式化设计模型的自动转换方法，通过基于限定自然语言需求模板的需求规约，实现对需求描述的限定，减少因自然语言二义性而产生的人为因素造成的错误，规约形成非形式化的设计说明，并自动生成AADL初始设计模型。

为了实现上述目标，本发明采用如下的技术方案：

一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，基于AADL开源工具环境OSATE使用Eclipse插件开发技术，包括如下步骤：

1)基于限定自然语言进行需求模板的组织与建立；

2)采用XML技术进行需求模板的存储；

3)使用模板方法模式实现需求模板到Req2AADL中间模型的转换；

4)使用访问者模式将Req2AADL中间模型转换成AADL设计模型。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤1)需求模板的组织与建立包括建立数据字典、领域词库和需求模板；

所述数据字典用于描述存储在需求规约过程中用到的所有数据形式，包括系统中的静态数据、系统内交互用到的动态数据、系统内数据存储单元的数据描述；单个数据的描述包括：数据中文名、数据英文名、数据来源地和目的地、数据的类型和组成、数据的精度、数据的范围、数据的频率、数据的单位以及数据的描述；

所述领域词库用于描述在需求规约过程中用到的领域名词，包括需求模板的名字、需求描述中模式的名字和整个系统中出现的硬件的名字；每个名词需要在领域词库中注册其中文名、英文名及其类型；

所述数据字典和领域词库的前端通过Eclipse插件技术扩展Editor，设计对应的编辑页面，并以JFace的Dialog对话框实现对数据字典和领域词库的数据增删改查操作；后台设计数据和词的原型类，包括对应的属性；定义对数据字典和领域词库的存储数据操作工具类，实现对数据字典和领域词库的存储及相应的增删改查功能；

所述需求模板的输入界面通过Eclipse插件扩展中的View扩展点进行实现，实现在cn.edu.nuaa.osate.view.RequirementView中，界面分为两个部分，左半边为需求树的结构及操作，包括增加、修改、删除树节点，右半边为选中需求树的编辑部分，编辑部分的界面绘制及操作由模板原型类提供。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述需求模板分为四类，包括系统需求模板、子系统需求模板、功能需求模板、子功能需求模板；所述系统需求模板为类SystemRequirement实现；所述子系统需求模板为类SubSystemRequirement实现；所述功能需求模板为类FunctionRequirement实现；所述子功能需求模板为类SubFunctionRequirement实现，上述四个类均继承自AbstractRequirement父类；

所述系统需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、模式变换、硬件约束、接口需求及功能构件描述；

所述子系统需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、模式变换、硬件约束、接口需求及功能构件描述；

所述功能需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、模式变换、接口需求及功能构件描述；

所述子功能需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、接口需求及功能构件描述；

对应上述各层次功能构件的需求模板，各类功能通过限定自然语言的方式加以约束，约束规则包括：

约束规则1：句子的主语必须是领域词库中定义的词；

约束规则2：只能使用陈述句；

约束规则3：只能使用现在时；

约束规则4：只能使用主动语态而不能使用被动语态；

约束规则5：不能使用情态动词、代词以及表示否定含义的副词、形容词；

约束规则6：只能使用简单句；

约束规则7：必须准确描述各功能构件间的交互，不能丢失主语和宾语；

约束规则8：不能使用分词短语做状语修饰语；

约束规则9：以一致方式使用词语，使用固定的名词来描述个功能构件；

针对各类需求，定义不同的约束语句，包括：

输入数据/事件表示某个功能构件的输入端口，输出数据/事件表示某个功能构件的输出端口，事件为某触发事件，数据为具有某种数据结构的具体数据，事件/数据均为数据字典中定义的类型；

功能需求包括5种句型，分别表示时间约束和条件约束下的功能行为：<TimeRestrain>+<Condition>+<Behavior>+[<else>+<Behavior>]，其中：

TimeRestrain表示时间上的约束；Condition表示触发条件或判断条件；Behavior表示具体的功能行为；

<Behavior>：表示一个简单句，单纯执行一个功能行为；

<Condition>+<Behavior>：表示在某种条件下完成一个功能行为的执行；

<TimeRestrain>+<Behavior>：表示在一定时间范围内完成一个功能行为；

<Condition>+<Behavior>+<else>+<Behavior>：表示在一定条件下完成一个功能行为，若不满足条件则执行另一个功能行为；

<TimeRestrain>+<Condition>+<Behavior>；表示在连续时间范围内一直满足某些条件，执行一个功能行为；

性能需求：分为时间性能和空间性能，分为两类句式：

时间性能：<TimeProperty>+<Num>+<Unit>，其中：TimeProperty表示时间属性的对象；Num为具体数值；Unit为时间单位；时间属性描述为对功能构件的某一属性的数值描述；

空间性能：<SpaceProperty>+<Num>+<Unit>，其中：SpaceProperty表示空间属性的对象；Num为具体数值；Unit为时间单位；空间属性描述为对功能构件占用某些资源的数值描述；

模式变换：表示在该功能构件下存在的模式迁移情况，包括模式组成和迁移两种：

模式组成：<Mode>+[Mode]*，Mode为该构件中存在的模式；模式组成用来说明某一功能构件中存在的所有模式；

模式迁移：<SrcMode>+<Guard>+<DestMode>，SrcMode为源模式，表示模式迁移的起点；DestMode为目的模式，表示模式迁移的终点；Guard为该迁移的条件；模式迁移表示一条具体的状态迁移；

所属模式：<ModeBelongs>*，表示该功能构件在父构件中起作用的模式，若全都作用则为null；

硬件约束：<HardWare>*，表示该功能构件下存在的硬件信息，该硬件必须是在领域词库中注册过的专有词汇；

接口需求：

<Bus>+<WorkType>+<Speed>+<Bias>；

<In/Out>+<Start>+<Send/Receive>+<End>+<Unit>；

<In/Out>+<Speed>；

其中：Bus表示某总线；WorkType表示总线工作方式；Speed表示总线数据传输速率；Bias表示总线误差；In/Out表示输入输出事件/数据端口；Start表示端口传输的起始时间；Send/Receive表示端口发送/接收过程时间；End表示端口数据传输结束时间；Unit表示时间单位；接口需求通过在传输过程中总线和传输过程节点端口处对特殊的传输性能上做约束，用以描述对接口性能的特殊要求；

功能构件描述：通过自然语言描述该功能构件的功能和结构的设计理念，方便后期工程师查阅。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤2)中需求模板的存储包括基于dom4j的开源库实现的XML格式文件的读写，具体存储内容为：

<Requirements>：表示整个系统，包括：XML元素<SyetemRequirement>*；

<SystemRequirement>：表示系统层需求，包括：

XML属性：ZhName：系统中文名；EnName：系统英文名；Description：系统描述；

XML元素：<Input>：系统输入；<Output>：系统输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<HardWareData>：硬件设计约束；<ModeTransition>：模式变换；

其中：<Input>和<Output>包括：

XML元素：<Data>：数据；<Event>：事件；

<SubRequirement>包括：

XML元素：[<SubSystemRequirement>*]：子系统需求；[<FunctionRequirement>*]：功能需求；

其中<SubSystemRequirement>包括：

XML属性：ZhName：子系统中文名；EnName：子系统英文名；Description：系统描述；XML元素：<Input>：子系统输入；<Output>：子系统输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<HardWareData>：硬件设计约束；<ModeTransition>：模式变换；<ModeBelongs>：所属模式；

其中<SubRequirement>包括：

XML元素：[<SubSystemRequirement>*]：子系统需求；[<FunctionRequirement>*]：功能需求；其中<FunctionRequirement>包括：

XML属性：ZhName：功能中文名；EnName：功能英文名；Description：功能描述；

XML元素：<Input>：功能输入；<Output>：功能输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<ModeTransition>：模式变换；<ModeBelongs>：所属模式；

其中<SubRequirement>包括：

XML元素：[<SubFunctionRequirement>*]：功能需求；

其中<SubFunctionRequirement>包括：

XML属性：ZhName：子功能中文名；EnName：子功能英文名；Description：子功能描述；

XML元素：<Input>：子功能输入；<Output>：子功能输出；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<ModeBelongs>：所属模式；

以上<Input>、<Output>、<Rpm>、<PerformanceRequirement>、<InterfaceRequirement>、<HardWareData>、<ModeTransition>、<ModeBelongs>均只包括一种XML元素：<sentence>表示对个类组成成分的封装。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤3)中需求模板到Req2AADL中间模型的转换是基于遍历的思想将层次化的需求模型插入到Req2AADL中间模型：

包括如下步骤：

31)遍历需求模板生成Model/Component框架：从需求模型的最顶层概念开始，实例化一个Req2AADL中间模型的最顶层概念Model，从最顶层需求开始调用generateModel函数，每层的该函数内都会调用下一层的generateModel函数，从而实现自顶向下的需求树遍历，该函数会在中建模型中实例化该模板对应的Component构件，并将输入输出数据事件转换到Component的inport和outport的List中；

32)针对31)中搭建起来的中间模型的基本框架和各Component构件的端口情况自动创建静态的数据交互路径，基于以下两点规则：

a)若在整个中间模型中能够找到匹配的输入输出端口，即存在不是同一构件内的两个端口，名称相同，类型相反，则在整个中间模型中生成这两个端口间的connection，即不断寻找父节点直到两端口找到共有祖先构件，以此为最高层的connection，其余按照层次关系将port和connection创建出来；

b)若在整个中间模型中存在落单的端口，则默认为该端口的匹配端口未完全建模，默认在最顶层系统中增加该端口数据类型的表示全局数据的Component，并将该端口该数据构件连接起来，采用互斥访问的机制实现该端口的交互，增加数据构件的subProperty为“Concurrency_Control_Protocol＝>Semaphore；”；

33)在32)中自动创建完port和connection之后，分别对功能需求、性能需求、接口需求、硬件设计约束、模式变换的进行转换，转换通过各层模板类中的parseOther(Model,Component)方法实现的，该方法中对该层所拥有的需求的所有原子语句的gen(Model,Component)方法调用一遍，并调用下一层的parseOther(Model,Component)方法；

所述Req2AADL中间模型在转换过程中抽取AADL的层次化结构及自动机、连接、属性作为中间模型的功能单元的内部结构：

最顶层概念Model：表示最顶层系统的集合，即整个模型，包括：

<Component>*：表示整个系统中的最顶层系统，可以是一个或多个；

[<Connection>*]：表示整个系统中存在的所有数据交互连接，可以是0，1，或多个；

[<StateMachine>*]：表示整个系统中存在的所有自动机，可以是模式变换的自动机或功能需求的自动机，可以是0，1或多个；

其中Component表示某一功能构件，可以是系统、子系统、进程、线程、硬件、外设、端口，包括：

<ZhName>：功能构件中文名；

<EnName>：功能构件英文名；

<ComponentType>：功能构件类型；

<Component>*：表示该功能构件中存在的子构件，可以是0，1或多个；

[<Connection>*]：表示整个功能构件中存在的子构件间的数据交互连接，可以是0，1，或多个；

[<StateMachine>]：表示整个功能构件中存在的自动机，即模式变换的自动机，可以是0或1个；

<Parent>：表示该功能构件的父构件，没有即为null；

[<BHVStateMachine>]：表示行为附件的自动机，即功能需求转换出的自动机，可以是0，或1个；

ModeBelongs：表示该构件在父构件中起作用的模式，可以是空，即表示都起作用；

[<Mode>*]：表示该构件中存在的可能的模式，可以是0，1或多个；

[<Inport>*]：表示输入的端口，可以是数据或事件端口，可以是0，1或多个；

[<Outport>*]：表示输出的端口，可以是数据或事件端口，可以是0，1或多个；

<PortType>：若该功能构件的类型为端口，则表示该端口的类型，可以是输入数据、输入事件、输出数据、输出事件、数据访问、数据赋值等；

[<Property>*]：表示该功能构件的属性，如周期、WCET、硬件绑定、调度机制等；

[<SubProperty>*]：若该构件是端口或总线，表示该构件在父构件中实例化对象的接口需求，如端口输入时间、总线传输速率、工作方式等；

其中Connection包括：

<Name>：表示该数据交互的名字，即唯一标识符；

<Source>：表示该数据交互中的数据来源方，为某一功能构件；

<Dest>：表示该数据交互中的数据接收方，为某一功能构件；

<ConnectionType>：表示该数据交互的类型，可以是端口数据交互，总线访问，数据访问等；

[<Property>*]：表示该数据交互的属性，如数据访问中存在的互斥访问方式，访问权限等，可以是0，1或多个；

其中StateMachine包括：

<Name>：表示该自动机的名字，即唯一标识符；

[<Variable>*]：表示该自动机中存在的临时变量，可以是0，1或多个；

[<State>*]：表示该自动机中存在的状态，可以是0，1或多个；

[<Transition>*]：表示该自动机中存在的状态迁移，可以是0，1或多个；

其中State包括<ZhName>：中文名；<EnName>：英文名；<Type>：状态类型；状态类型可以是Initial、Complete、Final三种或任意组合；

其中Transition包括：

<SrcState>：状态迁移的起始状态；

<DestState>：状态迁移的目标状态；

<Condition>：状态迁移的条件；

<Action>：状态迁移成功的动作；

<TimeOut>：状态迁移的时间约束；

需求模型到Req2AADL中间模型转换规则：

转换规则1：整个需求树，即整个进行需求规约后的需求模板，转换到中间模型中的Model，即整个Model表示一个完整的需求模型；

转换规则2：系统需求SystemRequirement、子系统需求SubSystemRequirement、功能需求FunctionRequirement、子功能需求SubFunctionRequirement转换到中间模型的Component构件，子需求层次关系SubRequirement转换到Component之间的父/子构件关系，四种需求模板转换出的Component构件分别的ComponentType为System、SubSystem、Process和thread；

转换规则3：各层次需求模板中的输入Input输出Output转换到中间模型中Component构件的Inport和Outport，数据事件分别转换到表示Inport和Outport的Component构件中的PortType属性；

转换规则4：各层次需求模板中的功能需求Rpm转换到中间模型Component中对应的BHVStateMachine，抽取其中的功能行为，针对功能执行情况转换生成State和Transition；

转换规则5：各层次需求模板中的性能需求PerformanceRequirement转换到中间模型中对应Component构件中的Property，每一条性能需求转换到对应的中间模型性能表达；

转换规则6：各层次需求模板中的接口需求InterfaceRequirement转换到中间模型中对应的Component构件中Inport或Outport中对应的SubProperty中，或转换到表示总线等硬件构件中的Property中；

转换规则7：各层次需求模板中的硬件设计约束HardWareData转换到中间模型中相应表示硬件的Component构件中的Property中；

转换规则8：各层次需求模板中的模式变换ModeTransition转换到中间模型中对应Component中的Mode和StateMachine中，Mode表示涵盖的模式类型，StateMachine中表示所有的模式及其之间的转换；

转换规则9：各层次需求模板中的所属模式ModeBelongs转换到中间模型中对应的Component中的ModeBelongs。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤4)中，Req2AADL中间模型到AADL设计模型的转换是在Req2AADL中间模型对构件的通用性表达的基础上逐个异化成AADL设计模型中各类构件实现的；

转换步骤为：

41)抽取中间模型最顶层概念，在项目工程中生成包，生成文件，即AADL设计模型的工作空间；

42)数据字典的转换：数据字典是直接从需求模型直接到AADL设计模型的，针对数据字典创建一个DataType.aadl文件，其中每个数据词条均生成一个Data构件的声明和实现，在实现中将数据组成转换为subcomponents，需求模板生成的AADL模型需引用此文件；

43)抽取Component扁平化：通过访问者的方式遍历所有的Component构件，并将所有Component抽取到一个List中，消除Component间的嵌套关系；

44)针对每一个Component生成对应AADL构件的声明：遍历整个Component的List，为每一个Component生成AADL构件声明，声明中包含features，Component中的inport和outport按照类型在features中生成端口；

45)针对每一个Component生成对应的AADL构件实现：遍历整个Component的List，为每一个Component生成AADL构件实现，实现中包括subcomponents、connections、modes、properties、annex behavior_specification；

Component中细节成分的转换规则如下：

规则1：若Component中的subcomponents中存在bus、memory、processor时，需要同时生成该构件中其他所有软件构件，如process、thread对硬件的绑定属性；

规则2：Component中的connections存在三种情况，同一层次构件间的数据交互，这种只需在父构件中定义两个构件间的端口的connection即可；父构件和子构件的数据交互，端口的方向需一致，且在父构件中定义connection；通过向最高层全局数据访问的方式实现的数据交互，端口永远是requires data access。

前述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述AADL设计模型：通过线程、进程、数据等构件以及连接来描述系统的软件体系结构；通过处理器、存储器、外设、总线等构件以及连接来描述系统的硬件体系结构；通过分发协议、通信协议、调度策略、模式变换协议以及分区机制等属性来描述系统的运行时环境；通过系统构件进行组合，层次化地建立系统的体系结构模型；

中间模型到AADL设计模型的转换规则：

转换规则1：中间模型中的最顶层概念Model转换到AADL设计模型中的Package概念，表示整个系统的设计模型，即其工作空间；

转换规则2：中间模型中的Component构件按照ComponentType转换到AADL设计模型中的System、Process、Thread、Port、Device、Bus、Processor、Memory构件；

其中成分：

ZhName、EnName转换到AADL构件的注释和id；

Component转换到AADL构件的subcomponent；

Inport、Outport转换到AADL构件声明的features；

PortType转换到features中port的类型声明；

Connection转换到AADL构件实现中的Connection；

ModeBelongs转换到AADLsubcomponent的属性中；

StateMachine转换到AADL构件实现中的mode和transition；

BHVStateMachine转换到AADL构件实现中的Behavior Annex；

Property转换到AADL构件实现中的properties；

SubProperty转换到AADL subcomponent或features的属性中；

转换规则3：中间模型中的Connection数据交互到AADL各构件实现中的connection；

其中：

Name转换到connection的标识符；

Source和Dest转换到connection的数据来源和目的地端口；

ConnectionType转换到connection的数据交互类型，包括port、data access、busaccess；

Property转换到connection的属性，包括模式in mode；

转换规则4：StateMachine转换到AADL构件的模式变换mode和transition中，BHVStateMachine转换到AADL构件实现中的Behavior Annex；

其中：

Variable是针对BHVStateMachine设计的，转换到Behavior Annex中的variables，表示在用行为附件表达功能行为时使用到的临时数据变量；

State在StateMachine和BHVStateMachine中均存在，其中StateMachine中的State转换到Component中的mode，分为正常模式和初始模式两种；BHVStateMachine中的State转换到Component构件实现中的行为附件中的mode，包括初始、完成、结束三种属性，三种属性可相互组合；

Transition在StateMachine和BHVStateMachine中也都存在，SrcState和DestState转换到transition的源模式和目标模式，其中StateMachine中Transition的Condition只能是端口名，且没有Action、TimeOut特征；BHVStateMachine中的Transition中的Condition为表达式，且可以有时间约束条件。

本发明所达到的有益效果：本方法是基于AADL开源工具环境OSATE使用Eclipse插件开发技术实现的，通过提供需求模板并引导用户输入进行需求规约，后台实现需求规约模型到形式化的结构分析与设计语言AADL的自动转换；由于在需求模板填写过程中，为了尽量满足现有工程师的习惯，需求规约是基于限定自然语言进行的，这种限制性也一定程度上避免了由自然语言二义性带来的需求设计不一致问题，保障了从需求到设计模型的过程安全性。

附图说明

图1是非形式化设计说明的形式化转换方法的模块化体系结构示意图；

图2是需求模板部分元模型示意图；

图3是工具设计Java包间结构关系示意图；

图4是需求模板到Req2AADL中间模型转换示意图；

图5是Req2AADL中间模型到AADL设计模型的转换示意图。

具体实施方式

下面结合附图对本发明作进一步描述。以下实施例仅用于更加清楚地说明本发明的技术方案，而不能以此来限制本发明的保护范围。

AADL语言能够对嵌入式系统软硬件耦合紧密、层次结构鲜明等特点进行良好的表达，因此本案中选用AADL作为嵌入式系统的设计建模语言，设计并提出一套基于限定自然语言的模板进行需求规约，并转换到AADL设计模型，以此来减少人工建模过程中出现的问题并保证设计模型的安全性。

AADL设计模型：嵌入式实时系统体系结构分析与设计语言AADL是2004年由美国机动工程师协会SAE在MetaH、UML、HOOD的基础上提出的，并发布为SAE AS5506标准。安全关键实时系统是应用软件、运行时环境以及硬件平台深度融合的复杂系统，AADL语言与之对应地提供了软件体系结构、运行时环境以及硬件体系结构的建模概念。通过线程、进程、数据等构件以及连接来描述系统的软件体系结构；通过处理器、存储器、外设、总线等构件以及连接来描述系统的硬件体系结构；通过分发协议、通信协议、调度策略、模式变换协议以及分区机制等属性来描述系统的运行时环境；最后，通过系统构件进行组合，层次化地建立系统的体系结构模型。AADL能够基于进程构件、处理器构件以及虚拟处理器构件对基本的分区机制建模，具有广阔的应用前景，得到了欧美工业界，特别是航空航天领域的支持。众多大学及研究机构对AADL展开了深入的研究和扩展。

本发明涉及到非形式化设计说明的形式化转换方法，转换过程是基于AADL开源工具环境OSATE使用Eclipse插件开发技术实现的，通过提供需求模板并引导用户输入进行需求规约，后台实现需求规约模型到形式化的结构分析与设计语言AADL的自动转换。由于在需求模板填写过程中，为了尽量满足现有工程师的习惯，需求规约是基于限定自然语言进行的，这种限制性也一定程度上避免了由自然语言二义性带来的需求设计不一致问题，保障了从需求到设计模型的过程安全性。

本附图2中的箭头表示关联关系，*代表有多个对象，1代表一个对象，0..1表示0或1，比如箭头两端都有*表示多对多，箭头两端中箭头处有*，另一端为1，表示1对多。

图2中Functional Req.对应Rpm，表示文中定义的功能需求。

Performance Req.对应Performance Requirement，表示文中定义的性能需求，

Interface Req.对应Interface Requirement，表示文中定义的接口需求，

Design Constraint对应<HardWareData>：表示文中定义的硬件设计约束，

Overallsystem关系表示Model包含整个由System和Task组成的结构模型，

System指的是SystemRequirement和SubSystemRequirement，表示系统级需求

Task指的是FunctionRequirement和SubFunctionRequirement，表示功能/任务级需求

signal指的就是数据交互，包括输入/输出的数据或事件；

subsystem关系表示system可以是system的子系统，即有一个迭代的关系，如SystemRequirement的子系统可以是SubSystemRequirement，SubSystemRequirement的子系统还是SubSystemRequirement，

subtask关系表示task可以是task的子任务，与subsystem类似，

Boolean，Enumerated，Double，Integer分别表示bool型，枚举型，浮点型，整型，表示Data可能的数据类型，这里只是列举几个示意一下，

Value是一个抽象概念，表示值，IntegerValue、DoubleValue、StringValue、BooleanValue分别表示一类值，对应到上面的Boolean、Enumerated、Double、Integer等数据类型，

max和min表示具体类型的值域。

图3中的代码包均是现有的基于此方法实现的工具代码中的Java包间关系，不作一一说明。

本方法基于模块化结构设计技术，将整个过程分为需求模板的组织与建立、需求模板的存储、需求模板到Req2AADL中间模型的转换、AADL模型生成这四个模块，详细见图1。我们采用基于元模型的转换技术设计需求规约模型到AADL的转换规则，需求模板部分元模型详见图2，并采用Eclipse插件开发技术和SWT/JFace技术实现该工具，中间模型采用XML技术实现存储。

1)需求模板的组织与建立：

需求模板的组织与建立主要包括三个部分，数据字典、领域词库和需求模板，数据字典主要用于对需求模型中涉及到的所有数据信息进行细节描述，包括全局数据、即时通信数据等；领域词库主要是用于对需求模型中所有的构件、模式等名词的“注册”，包括系统、硬件、模式等；而需求模板则是用于整个需求模型的规约。

数据字典和领域词库的设计主要遵循MVC设计思想，前端通过Eclipse插件技术扩展Editor，设计对应的编辑页面，辅以JFace的Dialog对话框实现对数据字典和领域词库的一些数据操作，如增删改查等；后台设计数据和词的原型类，包括对应的属性；此外定义对数据字典和领域词库的存储数据操作工具类，实现对数据字典和领域词库的存储及相应的增删改查功能。

原型类(cn.edu,nuaa.osate.dic.wordtype)：

DataWord(数据)：

ZhName：String类型，表示数据中文名；

EnName：String类型，表示数据英文名；

DataType：String类型，表示数据类型；

DataSourceDest：String类型，表示数据来源地和目的地；

Accuracy：String类型，表示数据精度；

Range：String类型，表示数据范围；

Frequency：String类型，表示数据频率；

Unit：String类型，表示数据单位；

DataDescription：String类型，表示数据描述；

DcList：ArrayList<DataWord>类型，表示数据成分，支持嵌套式定义数据；

FieldNoun(词)：

ZhName：String类型，表示领域词汇中文名；

EnName：String类型，表示领域词汇英文名；

DataType：String类型，表示领域词汇类型；

工具类(cn.edu.nuaa.osate.dic.util)：

DataDicUtil/WordDicUtil：(此处设计相同，以～代替DataWord和FieldNoun)

file：File类型，初始化时传入，指定对应的存储文件；

dlist：ArrayList<～>，初始化时读入所有的文件数据并存储在内存中；

hasChanged：Boolean类型，表示生命周期中文件中读入内存的数据是否被改变过；

add～(～)：增加函数，增加一个数据或词到字典或领域词库中；

delete～(～)：删除函数，按照传入的对象匹配唯一标识符即中文名删除文件中的对应数据；

Change～(～)：修改函数，按照传入的对象匹配中文名修改属性值；

get～ByZhName(String zhname)：按照中文名查找对应的数据或词；

get～ByEnName(String enname)：按照英文名查找对应的数据或词；

getAll～()：查找所有的数据，即返回dlist；

close()：调用finalize()函数，将内存中的数据写回对应文件；

需求模板的设计同样遵循界面与数据分开的设计思想，界面方面，需求模板的输入界面是通过Eclipse插件扩展中的View扩展点实现的，实现在cn.edu.nuaa.osate.view.RequirementView中，界面分为两个部分，左半边为需求树的结构及操作，包括增加、修改、删除树节点等，右半边为选中需求树的编辑部分，编辑部分的界面绘制及操作由模板原型类提供。

模板原型类(cn.edu.nuaa.osate.model)：

需求模板分为四类：系统需求模板、子系统需求模板、功能需求模板、子功能需求模板，这四类模板的实现分别为SystemRequirement、SubSystemRequirement、FunctionRequirement、SubFunctionRequirement四个类实现，而这四个类均继承自AbstractRrquirement父类。

AbstractRequirement类是所有模板的基类，该类实现了对界面的差异性描绘，因为不同模板具有不同的属性组成，同时也实现了对模板中记录数据，即各层次的需求模型成分的定义，同时定义了设计到需求模型的数据操作的虚函数；

zhName：String类型，功能构件中文名；

enName：String类型，功能构件英文名；

Description：String类型，功能构件描述；

Mode：String类型，功能构件所属模式；

inputDataList：ArrayList<DataPort>类型，输入数据模块，DataPort为数据端口定义的类，同sentence，第三部分模块会提到；

outputDataList：ArrayList<DataPort>类型，输出数据模块；

inputEventList：ArrayList<EventPort>类型，输入事件模块，EventPort为事件端口定义类；

outputEventList：ArrayList<EventPort>类型，输出事件模块；

RpmList：ArrayList<sentence>类型，功能需求模块，sentence为需求原子单句的基类，第三部分模块会提到；

modeTransition：ArrayList<sentence>类型，模式变换模块数据结构；

hardwareDataList：ArrayList<HardWare>类型，硬件约束模块，HardWare为硬件定义类；

InterfaceReq：ArrayList<sentence>类型，接口需求模块；

PerformanceRequirement：ArrayList<Property>类型，性能需求模块；

针对这些模板的模块化，在界面中设计了一套基于JFace的Table构件扩展的界面模块，实现对例如输入输出数据、功能需求、性能需求等不止一条的模块的操作，定义在cn.edu.nuaa.osate.model.table中，基类RequirementTable，实现基本的Table绘制、数据传递、增删改上下移动等功能；SentenceTable、HardWareTable、HardWareTable、InOutDataTable、InOutEventTable、PerformanceTable等继承RequirementTable并针对各自处理数据对象(sentence、DataPort、EventPort、Property、HardWare等)具体化实际操作。

由于需求模板中的填写是基于限定自然语言实现的，因此模板中的需求语句需要基于限定的方式填写，即针对各种类型的需求需要设计不同的语句模板，这些通过SWT的Wizard构件实现多页输入，与Table相似，针对不同类型的数据，设计不同的Wizard实现单条原子需求的输入，这些实现在cn.edu.nuaa.osate.wizard包中，主要包括dataWizard、hardwareWizard、reqWizard三个子包。

SystemRequirement、SubSystemRequirement、FunctionRequirement、SubFunctionRequirement四个需求模板的实现类主要负责承担具体到每一类模板上的操作，主要包括：

增加子需求：

add_new_element()：在需求树上增加一个该需求节点下的子需求；

需求模型存储与读写的操作：

addElement(Element)：将该需求模板写入XML节点；

readElement(Element)：从XML节点读出该需求模板；

需求模板到中间模型转换的操作：

generateModel(Model,Component)：将该模板的输入输出转换到中间模型；

parseOther(Model,Component)：将该模板的其他需求转换到中间模型；

2)需求模板的存储

需求模板的存储主要是基于dom4j的开源库实现的XML格式文件的读写，由2)中已经说明，四个层次的模板是基于SystemRequirement、SubSystemRequirement、FunctionRequirement、SubFunctionRequirement四个需求模板类实现的，而各个层次模板的存储读写等操作也是在这四个类中完成的，针对不同类型的需求，除了在模板层面需求设计了存储的框架外，还需要对每一种单个的原子需求语句进行设计，并转换成XML格式进行存储。

这些单个原子需求语句主要是在cn.edu.nuaa.osate.parse包中设计的。

所有的原子需求语句均继承了sentence抽象类，该抽象类定义了一些核心的操作方法，由继承了该类的子类实现：

SentenceClass：String类型，存储了继承了该类的子类的完整类名，用于读取过程中的Java反射机制；

toXMLString()：将继承了该类的子类拼接成XML格式的字符串，用于各层次模板的单个语句存储内容；

getContent()：返回继承了该类的子类拼接成的中文字符串，即返回到前端界面中表格里显示的内容；

getSentence(String)：该方法为静态方法，在抽象基类中无法定义成虚函数，但需在子类中实现，传入一段XML格式的字符串，返回解析出的子类对象；

gen(Model,Component)：用于解析该类句型并将该句内容转换到中间模型；

功能需求部分(cn.edu.nuaa.osate.parse.sentence.functionReq)：

由第一部分中介绍的功能需求部分表达式，将功能需求的结构拆分成如下的几个元素：

Functions类，继承sentence类，表示单个的功能需求语句，包含：

hasTimeRange：boolean类型，表示是否有时间约束属性；

hasConditions：boolean类型，表示是否有条件约束；

hasElse：boolean类型，表示是否有否则，若hasConditions为false则恒为false；

time：int类型，表示时间约束的数值；

unit：String类型，表示时间约束的单位；

若hasTimeRange为false，则time与unit为空；

condition：Condition类型，表示约束条件；

YaList：List<sentence>类型，表示在hasConditions为true的条件下的执行动作组；

NaList：List<sentence>类型，表示在hasElse为true的条件下的否则分支的执行动作组；其中Condition类表示功能需求中可能存在的条件语句，分为值判断条件和触发判断条件两种；

Condition类，继承sentence类，包括：

cType：ConditionType类型，有Variable和Dispatch两种；

conditionList：ArrayList<sentence>类型，表示条件的组合；

其中值判断条件由VariableCondition类实现，继承sentence类，包括：

object：String类型，存储值判断的对象名，限制为数据字典中定义的数据；

relation：String类型，表示二元数值关系运算符，包含>＝、<＝、＝＝、！＝、>、<等；

Variable：String类型，表示比较的数值，一般为整型或浮点型；

其中触发判断条件由DispatchCondition类实现，继承sentence类，包括：

condition：String类型，表示某端口名，必须为该构件中定义过的端口；

执行动作组由Actions类实现，继承sentence类，包括：

times：int类型，表示该组动作需执行的次数；

aList：ArrayList<sentence>类型，表示该组动作中的单个原子动作集合；

单个原子动作由Send类实现，继承sentence类，包括：

object：String类型，表示要发送的数据或对象，可以是0,1等整型、浮点型或String类型字段，也可以是某个端口名，表示当前该端口上现有的数据；

dest：String类型，表示要发往的目的地，可以是某个输出端口名；

性能需求部分(cn.edu.nuaa.osate.parse.sentence.performanceReq)：

性能需求的抽象基类为Property类，与sentence一样，该类具有几个抽象方法：

SentenceClass：String类型，存储了继承了该类的子类的完整类名，用于读取过程中的Java反射机制；

toXMLString()：将继承了该类的子类拼接成XML格式的字符串，用于各层次模板的单个语句存储内容；

getContent()：返回继承了该类的子类拼接成的中文字符串，即返回到前端界面中表格里显示的内容；

getSentence(String)：该方法为静态方法，在抽象基类中无法定义成虚函数，但需在子类中实现，传入一段XML格式的字符串，返回解析出的子类对象；

gen(Model,Component)：用于解析该类句型并将该句内容转换到中间模型；

性能需求部分的描述由于一般都是指标型的具体要求，因此相对较为简单，不存在类似功能需求的层次关系，主要包括一些数值属性的表示：

Cycle类：表示当前需求模板对应的构件的执行周期；

Deadline类：表示当前模板对应的构件的最坏执行时间WCET；

MemorySize类：表示当前模板对应的构件占用的内存空间大小；

SourceLanguage类：表示当前构件适合的编程语言；

接口需求方面(cn.edu.nuaa.osate.parse.sentence.interfaceReq)：

接口需求的抽象基类为sentence，与功能需求一样，因此接口需求对应的语句类也应实现上述的抽象方法。接口需求主要包括对端口的需求及对传输总线的需求：

对总线的需求类BusProperty，包含：

busName：String类型，表示总线的名称；

workType：String类型，表示总线的工作方式，包括pull和push两种；

sendTimePerByteLow：int类型，表示总线每字节传输的最短时间的数值；

sendTimePerByteHigh：int类型，表示总线每字节传输的最长时间的数值；

deviationLow：int类型，表示总线传输时间误差的下界的数值；

deviationHigh：int类型，表示总线传输时间误差的上界的数值；

sendTimeUnit：String类型，表示上述数值对应的单位；

对端口的需求类有两个，一是PortTime，包括：

portName：String类型，表示该条需求对应的端口名，必须是该需求所在模板定义过的端口；

startLow：int类型，表示开始时间的最低值，即反应时间的最低数值；

startHigh：int类型，表示开始时间的最高值，即反应时间的最高值；

dispatchLow：int类型，表示实际数据发送或接受时间的最低值；

dispatchHigh：int类型，表示实际数据发送或接受时间的最高值；

deadlineLow：int类型，表示单次数据结束时间的最低值；

deadlineHigh：int类型，表示单次数据结束时间的最高值；

unit：String类型，表示上述数值的单位；

二是PortRate，包括：

portName：String类型，表示该条需求对应的端口名，必须是该需求所在模板定义过的端口；

speedLow：int类型，表示每发送一组数据的最慢速度值；

speedHigh：int类型，表示每发送一组数据的最快速度值；

speedUnit：String类型，表示上述速度值的单位；

模式变换方面(cn.edu.nuaa.osate.parse.sentence.modeTransition)：

模式变换主要描述功能构件基于模式的状态的变化，最终表现在整个功能构件的功能行为的变化，模式变换的需求语句主要包括三个，模式声明、模式初始化、模式迁移，模式变换的所有需求原子语句类也继承了sentence抽象基类，所需实现虚函数不再赘述；模式声明由ModeCount类实现，包括：

modes：List<String>类型，表示该模板对应功能构件包含的所有模式；

模式初始化由InitialState类实现，包括：

initialstate：String类型，表示该句子设置的为初始模式的模式名；

模式迁移由ModeTransiton类实现，包括：

src：String类型，表示迁移对应的源模式名；

dest：String类型，表示迁移对应的目标模式名；

type：String类型，表示该模式变换条件端口的类型，为event或data；

condition：String类型，表示该迁移的条件端口名；

除了上述的几种原子需求设计，还有对输入输出端口的设计(cn.edu.nuaa.osate.parse.sentence.inout)、硬件设计约束(cn.edu.nuaa.osate.parse.sentence.hardware)等，这些设计都相对简单，输入输出端口是由DataPort和EventPort实现的，这两个类共同继承Port基类，硬件约束是由HardWare类实现的，也都需实现toXMLString()、getPort()、getContent()、gen()等抽象方法，作为后端细节的原子语句与前端模板的衔接，以支持存储、实例化对象、向中间模型转换等功能。

由以上可知，所有的原子需求语句自带拼接成XML格式及从XML格式解析出语句类实例的方法，这些方法与四个层次的需求模板类的基于dom4j的存储与解析的方法组合起来，共同实现整个需求模型的XML文件读写。

3)需求模板到Req2AADL中间模型的转换

需求模板到Req2AADL中间模型的转换是基于模板方法的设计模式实现的，如1)、2)中所述，转换的架构与存储类似，模板层面的框架转换由四个层次的模板类实现，主要是基于generateModel(Model,Component)和parseOther(Model,Component)方法实现，而原子需求语句层面的转换则是由各个语句类中的gen(Model,Component)方法实现的。

整个转换触发后，首先是在cn.edu.nuaa.osate.importer.requirement包中实现转换的启动，主要流程如图4所示。转换共分为3步：

第一步，从需求模型的最顶层概念开始，实例化一个Req2AADL中间模型的最顶层概念Model，从最顶层需求开始调用generateModel函数，每层的该函数内都会调用下一层的generateModel函数，从而实现自定向下的需求树遍历，该函数会在中建模型中实例化该模板对应的Component构件，并将输入输出数据事件转换到Component的inport和outport的List中；

第二步，针对第一步中搭建起来的中间模型的基本框架和各Component构件的端口情况自动创建静态的数据交互路径，主要基于两点规则：

第一点，若在整个中间模型中能够找到匹配的输入输出端口，即存在不是同一构件内的两个端口，名称相同，类型相反，则在整个中间模型中生成这两个端口间的connection，即不断寻找父节点直到两端口找到共有“祖先”构件，以此为最高层的connection，其余按照层次关系将port和connection创建出来。

第二点，若在整个中间模型中存在落单的端口，则默认为该端口的匹配端口未完全建模，因此默认在最顶层系统中增加该端口数据类型的表示全局数据的Component，并将该端口该数据构件连接起来，采用互斥访问的机制实现该端口的交互，增加数据构件的subProperty为“Concurrency_Control_Protocol＝>Semaphore；”；

第三步，在第二步自动创建完port和connection之后，分别对功能需求、性能需求、接口需求、硬件设计约束、模式变换的进行转换。该转换主要是通过各层模板类中的parseOther(Model,Component)方法实现的，该方法中对该层所拥有的需求的所有原子语句的gen(Model,Component)方法调用一遍，并调用下一层的parseOther方法。对于不同的需求，gen方法的实现也不尽相同：

功能需求：

功能需求主要包括5中句型：

(1)<Behavior>：

表示一个简单句，单纯执行一个功能行为；

(2)<Condition>+<Behavior>：

表示在某种条件下完成一个功能行为的执行；

(3)<TimeRestrain>+<Behavior>：

表示在一定时间范围内完成一个功能行为；

(4)<Condition>+<Behavior>+<else>+<Behavior>：

表示在一定条件下完成一个功能行为，若不满足条件则执行另一个功能行为；

(5)<TimeRestrain>+<Condition>+<Behavior>；

表示在连续时间范围内一直满足某些条件，执行一个功能行为；

这些句型的转换主要遵循以下规则：

转换规则1：功能需求中的所有内容转换到各层次Component的BHVStateMachine中；

转换规则2：每一条功能需求语句的转换源状态均为上一条转换的目的状态，目的状态一定是新状态；

转换规则3：若某一条功能语句存在分支结构，则生成两条具有相同源状态和目的状态的transition，且condition相反；

转换规则4：TimeRestrain时间约束转换到Transition中的TimeOut属性，Condition条件转换到Transition的condition属性，Behavior行为转换到Transition中的Action属性；

转换规则5：若同时存在TimeRestrain、Condition，则创建一条条件相反的状态转换，通过标志位的方式判断是否原始条件成立；

性能需求：

性能需求的转换相对简单，由于性能需求语句间不存在层次结构，直接将每一条性能需求原子语句独立转换即可：

Cycle类：表示周期，转换到对应Component构件中的Porperty，增加“Period＝>xms”；

Deadline类：表示最坏执行时间，与Cycle相同，增加“Deadline＝>x ms”；

其他性能需求类似，这里不再赘述；

接口需求：

接口需求主要对应转换到中间模型中表示端口和总线的Component的subProperty中，如：BusPorperty类：

转换到该需求模板对应的Component构件中的子构件相应的Bus中的subProperty，可直接拼接成AADL中的Transmission_Type和Transmission_Time两个属性；

PortRate类：

转换到该需求模板对应的Component构件中端口的subPorperty中，可直接拼接成AADL中的Input_Rate和Output_Rate属性；

PortTime类：

与PortRate类似，转换到AADL的Input_Time和Output_Time属性，放在对应Component构件的SubProperty中；

硬件约束：

Hardware类，直接转换到模板对应构件的subcomponent中，作为一个子构件Component加入到中间模型中；

模式变换：

模式变换主要转换到模板对应的Component中的Mode和Transition中：

ModeCount类：转换到Mode对应的List中，表示该构件拥有的模式数；

InitialState类：转换到该模板对应的Component中指定状态的IsInitial属性；

MdsTransition类：转换到模板对应Component中的Transition，src转换到Transition的源状态，dest转换到Transition的目的状态，condition和type转换到Condition；

通过上述转换规则即实现了需求模型到Req2AADL中间模型的转换。

4)AADL设计模型的生成

AADL设计模型的生成部分是基于访问者模式的设计思想实现的，在3)的基础上，得到了完整的Req2AADL中间模型，利用访问者类将中间模型中的所有Component构件抽取出来依次生成AADL构件。

AADL模型生成步骤如下：

1)抽取中间模型最顶层概念，在项目工程中生成包，生成文件，即AADL设计模型的工作空间；

2)数据字典的转换：数据字典是直接从需求模型直接到AADL设计模型的，针对数据字典创建一个DataType.aadl文件，其中每个数据词条均生成一个Data构件的声明和实现，在实现中将数据组成转换为subcomponents，需求模板生成的AADL模型需引用此文件；

3)Component构件扁平化：通过访问者的方式遍历所有的Component构件，并将所有Component抽取到一个List中，消除Component间的嵌套关系；

4)针对每一个Component生成对应AADL构件的声明：遍历整个Component的List，为每一个Component生成AADL构件声明，声明中包含features，Component中的inport和outport按照类型在features中生成端口；

5)针对每一个Component生成对应的AADL构件实现：遍历整个Component的List，为每一个Component生成AADL构件实现，实现中包括subcomponents、connections、modes、properties、annex behavior_specification等；

规则如下：

规则1：若subcomponents中存在bus、memory、processor时，需要同时生成该构件中其他所有软件构件，如process、thread对硬件的绑定属性；

规则2：connections存在三种情况，同一层次构件间的数据交互，这种只需在父构件中定义两个构件间的端口的connection即可；父构件和子构件的数据交互，端口的方向需一致，且在父构件中定义connection；通过向最高层全局数据访问的方式实现的数据交互，端口永远是requires data access。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和变形，这些改进和变形也应视为本发明的保护范围。

Claims (6)

1.一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，基于AADL开源工具环境OSATE使用Eclipse插件开发技术，包括如下步骤：

1)基于限定自然语言进行需求模板的组织与建立；

2)采用XML技术进行需求模板的存储；

3)使用模板方法模式实现需求模板到Req2AADL中间模型的转换；

4)使用访问者模式将Req2AADL中间模型转换成AADL设计模型；

所述步骤1)中需求模板的组织与建立包括建立数据字典、领域词库和需求模板；

所述数据字典用于描述存储在需求规约过程中用到的所有数据形式，包括系统中的静态数据、系统内交互用到的动态数据、系统内数据存储单元的数据描述；单个数据的描述包括：数据中文名、数据英文名、数据来源地和目的地、数据的类型和组成、数据的精度、数据的范围、数据的频率、数据的单位以及数据的描述；

所述领域词库用于描述在需求规约过程中用到的领域名词，包括需求模板的名字、需求描述中模式的名字和整个系统中出现的硬件的名字；每个名词需要在领域词库中注册其中文名、英文名及其类型；

所述数据字典和领域词库的前端通过Eclipse插件技术扩展Editor，设计对应的编辑页面，并以JFace的Dialog对话框实现对数据字典和领域词库的数据增删改查操作；后台设计数据和词的原型类，包括对应的属性；定义对数据字典和领域词库的存储数据操作工具类，实现对数据字典和领域词库的存储及相应的增删改查功能；

所述需求模板的输入界面通过Eclipse插件扩展中的View扩展点进行实现，实现在cn.edu.nuaa.osate.view.RequirementView中，界面分为两个部分，左半边为需求树的结构及操作，包括增加、修改、删除树节点，右半边为选中需求树的编辑部分，编辑部分的界面绘制及操作由模板原型类提供。

2.根据权利要求1所述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述需求模板分为四类，包括系统需求模板、子系统需求模板、功能需求模板、子功能需求模板；所述系统需求模板为类SystemRequirement实现；所述子系统需求模板为类SubSystemRequirement实现；所述功能需求模板为类FunctionRequirement实现；所述子功能需求模板为类SubFunctionRequirement实现，上述四个类均继承自AbstractRequirement父类；

所述系统需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、模式变换、硬件约束、接口需求及功能构件描述；

所述子系统需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、模式变换、硬件约束、接口需求及功能构件描述；

所述功能需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、模式变换、接口需求及功能构件描述；

所述子功能需求模板包括：系统中文名，系统英文名，是否为安全关键功能构件、输入数据/事件、输出数据/事件、功能需求、性能需求、所属模式、接口需求及功能构件描述；

对应上述各层次功能构件的需求模板，各类功能通过限定自然语言的方式加以约束，约束规则包括：

约束规则1：句子的主语必须是领域词库中定义的词；

约束规则2：只能使用陈述句；

约束规则3：只能使用现在时；

约束规则4：只能使用主动语态而不能使用被动语态；

约束规则5：不能使用情态动词、代词以及表示否定含义的副词、形容词；

约束规则6：只能使用简单句；

约束规则7：必须准确描述各功能构件间的交互，不能丢失主语和宾语；

约束规则8：不能使用分词短语做状语修饰语；

约束规则9：以一致方式使用词语，使用固定的名词来描述个功能构件；

针对各类需求，定义不同的约束语句，包括：

输入数据/事件表示某个功能构件的输入端口，输出数据/事件表示某个功能构件的输出端口，事件为某触发事件，数据为具有某种数据结构的具体数据，事件/数据均为数据字典中定义的类型；

功能需求包括5种句型，分别表示时间约束和条件约束下的功能行为：<TimeRestrain>+<Condition>+<Behavior>+[<else>+<Behavior>]，其中：

TimeRestrain表示时间上的约束；Condition表示触发条件或判断条件；Behavior表示具体的功能行为；

<Behavior>：表示一个简单句，单纯执行一个功能行为；

<Condition>+<Behavior>：表示在某种条件下完成一个功能行为的执行；

<TimeRestrain>+<Behavior>：表示在一定时间范围内完成一个功能行为；

<Condition>+<Behavior>+<else>+<Behavior>：表示在一定条件下完成一个功能行为，若不满足条件则执行另一个功能行为；

<TimeRestrain>+<Condition>+<Behavior>；表示在连续时间范围内一直满足某些条件，执行一个功能行为；

性能需求：分为时间性能和空间性能，分为两类句式：

时间性能：<TimeProperty>+<Num>+<Unit>，其中：TimeProperty表示时间属性的对象；Num为具体数值；Unit为时间单位；时间属性描述为对功能构件的某一属性的数值描述；

空间性能：<SpaceProperty>+<Num>+<Unit>，其中：SpaceProperty表示空间属性的对象；Num为具体数值；Unit为时间单位；空间属性描述为对功能构件占用某些资源的数值描述；

模式变换：表示在该功能构件下存在的模式迁移情况，包括模式组成和迁移两种：

模式组成：<Mode>+[Mode]*，Mode为该功能构件中存在的模式；模式组成用来说明某一功能构件中存在的所有模式；

模式迁移：<SrcMode>+<Guard>+<DestMode>，SrcMode为源模式，表示模式迁移的起点；DestMode为目的模式，表示模式迁移的终点；Guard为该迁移的条件；模式迁移表示一条具体的状态迁移；

所属模式：<ModeBelongs>*，表示该功能构件在父构件中起作用的模式，若全都作用则为null；

硬件约束：<HardWare>*，表示该功能构件下存在的硬件信息，该硬件必须是在领域词库中注册过的专有词汇；

接口需求：

<Bus>+<WorkType>+<Speed>+<Bias>；

<In/Out>+<Start>+<Send/Receive>+<End>+<Unit>；

<In/Out>+<Speed>；

其中：Bus表示某总线；WorkType表示总线工作方式；Speed表示总线数据传输速率；Bias表示总线误差；In/Out表示输入输出事件/数据端口；Start表示端口传输的起始时间；Send/Receive表示端口发送/接收过程时间；End表示端口数据传输结束时间；Unit表示时间单位；接口需求通过在传输过程中总线和传输过程节点端口处对特殊的传输性能上做约束，用以描述对接口性能的特殊要求；

功能构件描述：通过自然语言描述该功能构件的功能和结构的设计理念，方便后期工程师查阅。

3.根据权利要求1所述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤2)中需求模板的存储包括基于dom4j的开源库实现的XML格式文件的读写，具体存储内容为：

<Requirements>：表示整个系统，包括：XML元素<SyetemRequirement>*；

<SystemRequirement>：表示系统层需求，包括：

XML属性：ZhName：系统中文名；EnName：系统英文名；Description：系统描述；

XML元素：<Input>：系统输入；<Output>：系统输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<HardWareData>：硬件设计约束；<ModeTransition>：模式变换；

其中：<Input>和<Output>包括：

XML元素：<Data>：数据；<Event>：事件；

<SubRequirement>包括：

XML元素：[<SubSystemRequirement>*]：子系统需求；[<FunctionRequirement>*]：功能需求；

其中<SubSystemRequirement>包括：

XML属性：ZhName：子系统中文名；EnName：子系统英文名；Description：系统描述；

XML元素：<Input>：子系统输入；<Output>：子系统输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<HardWareData>：硬件设计约束；<ModeTransition>：模式变换；<ModeBelongs>：所属模式；

其中<SubRequirement>包括：

XML元素：[<SubSystemRequirement>*]：子系统需求；[<FunctionRequirement>*]：功能需求；

其中<FunctionRequirement>包括：

XML属性：ZhName：功能中文名；EnName：功能英文名；Description：功能描述；

XML元素：<Input>：功能输入；<Output>：功能输出；<SubRequirement>：子需求；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<ModeTransition>：模式变换；<ModeBelongs>：所属模式；

其中<SubRequirement>包括：

XML元素：[<SubFunctionRequirement>*]：功能需求；

其中<SubFunctionRequirement>包括：

XML属性：ZhName：子功能中文名；EnName：子功能英文名；Description：子功能描述；

XML元素：<Input>：子功能输入；<Output>：子功能输出；<Rpm>：功能需求；<PerformanceRequirement>：性能需求；<InterfaceRequirement>：接口需求；<ModeBelongs>：所属模式；

以上<Input>、<Output>、<Rpm>、<PerformanceRequirement>、<InterfaceRequirement>、<HardWareData>、<ModeTransition>、<ModeBelongs>均只包括一种XML元素：<sentence>表示对个类组成成分的封装。

4.根据权利要求1所述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤3)中需求模板到Req2AADL中间模型的转换是基于遍历的思想将层次化的需求模型插入到Req2AADL中间模型：

包括如下步骤：

31)遍历需求模板生成Model/Component框架：从需求模型的最顶层概念开始，实例化一个Req2AADL中间模型的最顶层概念Model，从最顶层需求开始调用generateModel函数，每层的该函数内都会调用下一层的generateModel函数，从而实现自顶向下的需求树遍历，该函数会在中建模型中实例化该模板对应的Component构件，并将输入输出数据事件转换到Component构件的inport和outport的List中；

32)针对31)中搭建起来的中间模型的基本框架和各Component构件的端口情况自动创建静态的数据交互路径，基于以下两点规则：

a)若在整个中间模型中能够找到匹配的输入输出端口，即存在不是同一Component构件内的两个端口，名称相同，类型相反，则在整个中间模型中生成这两个端口间的connection，即不断寻找父节点直到两端口找到共有祖先构件，以此为最高层的connection，其余按照层次关系将port和connection创建出来；

b)若在整个中间模型中存在落单的端口，则默认为该端口的匹配端口未完全建模，默认在最顶层系统中增加该端口数据类型的表示全局数据的Component构件，并将该端口该数据构件连接起来，采用互斥访问的机制实现该端口的交互，增加数据构件的subProperty为“Concurrency_Control_Protocol＝>Semaphore；”；

33)在32)中自动创建完port和connection之后，分别对功能需求、性能需求、接口需求、硬件设计约束、模式变换的进行转换，转换通过各层模板类中的parseOther(Model,Component)方法实现的，该方法中对该层所拥有的需求的所有原子语句的gen(Model,Component)方法调用一遍，并调用下一层的parseOther(Model,Component)方法；

所述Req2AADL中间模型在转换过程中抽取AADL的层次化结构及自动机、连接、属性作为中间模型的功能单元的内部结构：

最顶层概念Model：表示最顶层系统的集合，即整个模型，包括：

<Component>*：表示整个系统中的最顶层系统，是一个或多个；

[<Connection>*]：表示整个系统中存在的所有数据交互连接，是0，1，或多个；

[<StateMachine>*]：表示整个系统中存在的所有自动机，是模式变换的自动机或功能需求的自动机，是0，1或多个；

其中Component表示某一功能构件，是系统、子系统、进程、线程、硬件、外设、端口，包括：

<ZhName>：功能构件中文名；

<EnName>：功能构件英文名；

<ComponentType>：功能构件类型；

<Component>*：表示该功能构件中存在的子构件，是0，1或多个；

[<Connection>*]：表示整个功能构件中存在的子构件间的数据交互连接，是0，1，或多个；

[<StateMachine>]：表示整个功能构件中存在的自动机，即模式变换的自动机，是0或1个；

<Parent>：表示该功能构件的父构件，没有即为null；

[<BHVStateMachine>]：表示行为附件的自动机，即功能需求转换出的自动机，是0，或1个；

ModeBelongs：表示该功能构件在父构件中起作用的模式，是空，即表示都起作用；

[<Mode>*]：表示该功能构件中存在的可能的模式，是0，1或多个；

[<Inport>*]：表示输入的端口，是数据或事件端口，是0，1或多个；

[<Outport>*]：表示输出的端口，是数据或事件端口，是0，1或多个；

<PortType>：若该功能构件的类型为端口，则表示该端口的类型，是输入数据、输入事件、输出数据、输出事件、数据访问或数据赋值；

[<Property>*]：表示该功能构件的属性，是周期、WCET、硬件绑定或调度机制；

[<SubProperty>*]：若该功能构件是端口或总线，表示该功能构件在父构件中实例化对象的接口需求，是端口输入时间、总线传输速率或工作方式；

其中Connection包括：

<Name>：表示该数据交互的名字，即唯一标识符；

<Source>：表示该数据交互中的数据来源方，为某一功能构件；

<Dest>：表示该数据交互中的数据接收方，为某一功能构件；

<ConnectionType>：表示该数据交互的类型，是端口数据交互，总线访问或数据访问；

[<Property>*]：表示该数据交互的属性，是数据访问中存在的互斥访问方式或访问权限，是0，1或多个；

其中StateMachine包括：

<Name>：表示该自动机的名字，即唯一标识符；

[<Variable>*]：表示该自动机中存在的临时变量，是0，1或多个；

[<State>*]：表示该自动机中存在的状态，是0，1或多个；

[<Transition>*]：表示该自动机中存在的状态迁移，是0，1或多个；

其中State包括<ZhName>：中文名；<EnName>：英文名；<Type>：状态类型；状态类型是Initial、Complete、Final三种或任意组合；

其中Transition包括：

<SrcState>：状态迁移的起始状态；

<DestState>：状态迁移的目标状态；

<Condition>：状态迁移的条件；

<Action>：状态迁移成功的动作；

<TimeOut>：状态迁移的时间约束；

需求模型到Req2AADL中间模型转换规则：

转换规则1：整个需求树，即整个进行需求规约后的需求模板，转换到中间模型中的Model，即整个Model表示一个完整的需求模型；

转换规则2：系统需求SystemRequirement、子系统需求SubSystemRequirement、功能需求FunctionRequirement、子功能需求SubFunctionRequirement转换到中间模型的Component构件，子需求层次关系SubRequirement转换到Component构件之间的父/子构件关系，四种需求模板转换出的Component构件分别的ComponentType为System、SubSystem、Process和thread；

转换规则3：各层次需求模板中的输入Input输出Output转换到中间模型中Component构件的Inport和Outport，数据事件分别转换到表示Inport和Outport的Component构件中的PortType属性；

转换规则4：各层次需求模板中的功能需求Rpm转换到中间模型Component构件中对应的BHVStateMachine，抽取其中的功能行为，针对功能执行情况转换生成State和Transition；

转换规则5：各层次需求模板中的性能需求PerformanceRequirement转换到中间模型中对应Component构件中的Property，每一条性能需求转换到对应的中间模型性能表达；

转换规则6：各层次需求模板中的接口需求InterfaceRequirement转换到中间模型中对应的Component构件中Inport或Outport中对应的SubProperty中，或转换到表示总线硬件构件中的Property中；

转换规则7：各层次需求模板中的硬件设计约束HardWareData转换到中间模型中相应表示硬件的Component构件中的Property中；

转换规则8：各层次需求模板中的模式变换ModeTransition转换到中间模型中对应Component构件中的Mode和StateMachine中，Mode表示涵盖的模式类型，StateMachine中表示所有的模式及其之间的转换；

转换规则9：各层次需求模板中的所属模式ModeBelongs转换到中间模型中对应的Component构件中的ModeBelongs。

5.根据权利要求1所述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述步骤4)中，Req2AADL中间模型到AADL设计模型的转换是在Req2AADL中间模型对构件的通用性表达的基础上逐个异化成AADL设计模型中各类构件实现的；

转换步骤为：

41)抽取中间模型最顶层概念，在项目工程中生成包，生成文件，即AADL设计模型的工作空间；

42)数据字典的转换：数据字典是直接从需求模型直接到AADL设计模型的，针对数据字典创建一个DataType.aadl文件，其中每个数据词条均生成一个Data构件的声明和实现，在实现中将数据组成转换为subcomponents，需求模板生成的AADL设计模型需引用此文件；

43)抽取Component扁平化：通过访问者的方式遍历所有的Component构件，并将所有Component构件抽取到一个List中，消除Component构件间的嵌套关系；

44)针对每一个Component构件生成对应AADL构件的声明：遍历整个Component构件的List，为每一个Component构件生成AADL构件声明，声明中包含features，Component构件中的inport和outport按照类型在features中生成端口；

45)针对每一个Component构件生成对应的AADL构件实现：遍历整个Component构件的List，为每一个Component构件生成AADL构件实现，实现中包括subcomponents、connections、modes、properties、annex behavior_specification；

Component构件中细节成分的转换规则如下：

规则1：若Component构件中的subcomponents中存在bus、memory、processor时，需要同时生成该构件中其他所有软件构件，如process、thread对硬件的绑定属性；

规则2：Component构件中的connections存在三种情况，同一层次构件间的数据交互，这种只需在父构件中定义两个构件间的端口的connection即可；父构件和子构件的数据交互，端口的方向需一致，且在父构件中定义connection；通过向最高层全局数据访问的方式实现的数据交互，端口永远是requires data access。

6.根据权利要求5所述的一种非形式化需求规约模板到形式化设计模型的自动转换方法，其特征是，所述AADL设计模型：通过线程、进程、数据以及连接来描述系统的软件体系结构；通过处理器、存储器、外设、总线以及连接来描述系统的硬件体系结构；通过分发协议、通信协议、调度策略、模式变换协议以及分区机制来描述系统的运行时环境；通过系统构件进行组合，层次化地建立系统的体系结构模型；

中间模型到AADL设计模型的转换规则：

转换规则1：中间模型中的最顶层概念Model转换到AADL设计模型中的Package概念，表示整个系统的设计模型，即其工作空间；

转换规则2：中间模型中的Component构件按照ComponentType转换到AADL设计模型中的System、Process、Thread、Port、Device、Bus、Processor、Memory构件；

其中成分：

ZhName、EnName转换到AADL构件的注释和id；

Component构件转换到AADL构件的subcomponent；

Inport、Outport转换到AADL构件声明的features；

PortType转换到features中port的类型声明；

Connection转换到AADL构件实现中的Connection；

ModeBelongs转换到AADLsubcomponent的属性中；

StateMachine转换到AADL构件实现中的mode和transition；

BHVStateMachine转换到AADL构件实现中的Behavior Annex；

Property转换到AADL构件实现中的properties；

SubProperty转换到AADL subcomponent或features的属性中；

转换规则3：中间模型中的Connection数据交互到AADL各构件实现中的connection；

其中：

Name转换到connection的标识符；

Source和Dest转换到connection的数据来源和目的地端口；

ConnectionType转换到connection的数据交互类型，包括port、data access、busaccess；

Property转换到connection的属性，包括模式in mode；

转换规则4：StateMachine转换到AADL构件的模式变换mode和transition中，BHVStateMachine转换到AADL构件实现中的Behavior Annex；

其中：

Variable是针对BHVStateMachine设计的，转换到Behavior Annex中的variables，表示在用行为附件表达功能行为时使用到的临时数据变量；

State在StateMachine和BHVStateMachine中均存在，其中StateMachine中的State转换到Component中的mode，分为正常模式和初始模式两种；BHVStateMachine中的State转换到Component构件实现中的行为附件中的mode，包括初始、完成、结束三种属性，三种属性可相互组合；

Transition在StateMachine和BHVStateMachine中也都存在，SrcState和DestState转换到transition的源模式和目标模式，其中StateMachine中Transition的Condition只能是端口名，且没有Action、TimeOut特征；BHVStateMachine中的Transition中的Condition为表达式，且有时间约束条件。

Images