技术领域
[0001] 本发明涉及一种需求模型到仿真模型的模型转换方法。
相关背景技术
[0002] 需求建模是软件需求工程中的一项重要的活动，需求工程师通过采用不同的建模方法识别、理解、挖掘需求提供者对系统的期望，从而构建软件系统的结构模型，行为模型，或者其他各种对展示待开发软件的不同特性的模型。如何验证需求模型的正确性，可以采用形式化的方法，但是形式化的方法对难以理解、同时要求软件开发人员有较强的数学功底。为此我们采用仿真的方式验证需求模型的正确性。如何从需求模型过渡到仿真模型，通常是软件开发人员根据需求模型手工完成仿真模型。软件开发人员在软件开发过程中完成各种模型，这势必增加开发人员工作量；另一方面，由于都是手工完成各种模型，开发人员难以保证各类模型的一致性。因此，如何从需求模型转换到仿真模型已经成为软件开发的重要问题。
具体实施方式
[0028] 本发明的具体步骤如下：
[0029] 1建立模型转换框架
[0030] 模型转框架如图1所示，分为三层。最顶层M3层是元元模型层，M2是元模型层，M1是模型层。按照模型驱动理论中各类模型间的关系，元元模型可以生成元元模型和元模型，根据元模型可以生成模型。元元模型可以通过自身定义，同时可以生成需求模型元模型、仿真模型元模型、ATL语言。需求模型元模型生成需求模型，仿真模型元模型生成仿真模型，ATL语言生成ATL模型。对于使用者而言，只需要输入需求模型，通过一系列转换，自动转换成仿真模型。
[0031] 2建立需求模型元模型
[0032] 在模型转换元元模型的基础上，根据用户选择的需求模型的语义和语法，构造需求模型元模型。需求模型分类三类，数据类型模型、对象模型和连接模型。
[0033] 数据类型模型表示需求模型中所涉及的数据类型，例如boolean,double,single,int8,uint8,int16,uint16,int32,and uint32等；
[0034] 对象模型表示需求模型的客观对象，包括类和注释；其中类包括属性和操作，建立属性与数据类型、枚举类型的关联，建立操作与属性的关联；
[0035] 连接模型表示类之间关系、类与注释之间的关系，其中类之间关系包括组合、聚合、引用和继承，类与注释之间的关系采用注释链接描述；
[0036] 提取需求模型元模型时，仅关注和仿真相关的需求模型，换句话说，这里的需求模型元模型只是需求模型的子集。如果仿真模型中某个元素无法与需求模型中的某一元素对应，需要对需求模型建立Profile(扩展)，建立与仿真模型对应的需求模型元素，使它们之间可以映射。
[0037] 3建立仿真模型元模型
[0038] 这里仿真模型元模型的建立过程与需求模型元模型类似，但是仿真模型元模型不需要Profile。
[0039] 4建立需求模型元模型和仿真模型元模型的映射关系
[0040] 第二、三步建立的元模型的目的是为了使它们之间存在有映射关系。映射关系也包含三部分，需求模型元模型的数据类型映射到仿真模型元模型的数据类型；需求模型元模型的类映射到仿真模型元模型的类，需求模型元模型的类的属性映射到仿真模型元模型的类的属性，需求模型元模型的类的操作映射到仿真模型元模型中类的操作，需求模型元模型中类与类之间的关系映射到仿真模型元模型中类与类之间的关系。
[0041] 以下以UML需求模型到Simulink仿真模型的转换为例进一步详述本发明。使用KM3语言建立模型转换框架元元模型，在此基础上建立UML需求元模型、Simulink仿真元模型，进而撰写UML到Simulink转换规则。
[0042] 1转换框架元元模型-KM3
[0043] KM3为元元模型如图2所示。KM3元模型结构中，KM3元模型由一系列Package(包)构成，一个Package由一些抽象ModelElement(模型元素)实体组成。ModelElement是一个元模型，拥有name属性，其他元素都继承于ModelElement。ModelElement的子类包括Enumliteral(枚举值)、Classifier(分类器)、Annotation(注释)、DataType(数据类型)、TypedELement(类元)等。Annotation由一系列AnnotationLink(注释关联)组成。Enumeration(枚举)至少包括一个Enumliteral。DataType(数据类型)和Class(类)继承于Classifler。Classifler和Class至少包括一个TypedELement类型元素。TypedElement定义了lower、upper、isOrdered和isUnique属性。StucturalFeature(结构特征)和Operation(操作)继承于TypedElement。
[0044] 2 UML状态机元模型
[0045] 状态机是一个类/对象可能经历的所有历程的模型图。状态机由对象的各个状态和连接这些状态的转换组成。每个状态对一个对象在其生命期中满足某条件的一个时间段建模。当一个事件发生时，它会触发状态间的转换，导致对象从一种状态转化到另一新的状态。当转换开始时，会发生与转换关联的某种效果(动作或者活动)。
[0046] 根据《OMG Unified Modeling LanguageTM(OMG UML)，Superstructure》版本2.4.1。UML状态机的简化元模型如图3所示。一个状态机由仅有的一个顶级的状态机元素，一系列状态元素和转移元素组成。ModeleElement是所有元素的基类。其中虚状态、状态、终止状态继承顶点状态。初始状态、连接状态、分叉状态继承虚状态。顶点状态由执行活动、进口活动、出口活动组成。转移由监护条件、触发条件、效果组成。顶级状态和转移存在对应关系，一个顶级状态对应一个或者多个转移。
[0047] 3 Simulink状态机元模型
[0048] Stateflow是MATLAB产品体系中非常重要的一个分支，它是在基于框图的动态系统建模仿真环境。Stateflow能够对基于有限状态机理论的事件驱动系统进行建模和仿真，也能够针对复杂逻辑系统进行建模和仿真。UML有严格的语法、语义，然而Stateflow不同，需要对其元素仔细分析，从而创建Stateflow元模型。
[0049] Stateflow的基本概念包括：
[0050] 1)状态机(State Machine)包含在模型中的所有Stateflow块的集合。一个Simulink模型中包含的所有Stateflow模型统称为一个Stateflow状态机；
[0051] 2)图块(Chart)包含状态图的模块，即模型中的Chart。
[0052] 3)框图(Diagram)状态图的图形化表述，即具体的图块所包含的内容。
[0053] 4)状态是Stateflow状态图中最重要的元素之一，在有限状态机里，状态描述的是系统的一种模式。状态具有布尔行为，可以把状态看作为高级编程语言中的布尔类型变量，任何给定的时刻，状态要么是活动的要么是非活动的，不可能出现第3种情况。
[0054] 5)状态动作的关键字主要有2种，分别为entry，当状态被激活时执行相应的动作。During，当状态保持其活动状态时执行相应的动作。
[0055] 6)转移是Stateflow框图中最常见的图形元素之一，转移描述的是有限状态系统内的逻辑流。当转移发生时，源状态变为非活动的状态，目标状态变为活动的状态。
[0056] 7)状态转移标识的一般格式为：event[condition]{condition_action}/transition_action。事件是Stateflow非图形对象的一种。在有限状态机中，只有在事件发生时，才可能去执行相应的转移。“[]”中的内容是条件，用于转移决策的逻辑判断。只有在相应的事件发生且条件也满足时，相应的转移才可能执行。紧接在条件后面“{}”中的内容就是条件动作，条件动作是在条件满足时就立即执行的某些表达式，例如赋值运算等"。转移动作是整个转移标签的最后一个部分，位于“/”后面的内容都是转移动作。转移动作只有在整个转移通路都有效时才能够执行。
[0057] 依据上述1)-7)内容，本文设计出Stateflow的元模型，如图4所示。
[0058] 4元模型间的映射规则
[0059] 由UML状态机元模型和Stateflow元模型可知，二者具有较高的相似性。都是由状态、转移、状态动作、时间、效果、条件等元素组成。依据UML状态机和Stateflow元模型，设计UML状态机和Stateflow的映射规则：
[0060] U2S1：ModelElement映射到SimulinkElement
[0061] ModelElement是UML状态机所有元素的基类，对应的设计Stateflow所有元素的基类SimulinkElement。ModelElement映射到SimulinkElement。
[0062] U2S2：StateMachineDiagrams映射到StateMachine
[0063] 对 于 状 态 机 这 个 词，UML和 Simulink 的 理 解 略 有 偏 差。UML 的StateMachineDiagram由StateMachine组成。Simulink的StateMachine由Chart组成。因此UML的StateMachineDiagram与Simulilnk的StateMachine含义基本相同。
[0064] U2S3:StateMachineDiagram映射到Chart
[0065] 与U2S2不同，这里的StateMachineDiagram指单个状态图，对应到Simulink中的Chart。
[0066] U2S4：StateMachine映射到State
[0067] UML的StateMachine由State、Transition等组成，Simulink的State中也包含嵌套State、Transition等元素。
[0068] U2S5：State映射到State
[0069] 与U2S4不同，这里UML的State指非嵌套的状态。UML和Simulink中的State含义相同，可以直接映射。
[0070] U2S6：Transition映射到Transition
[0071] UML和Simulink中的转移含义基本相同，直接映射。
[0072] U2S7：DoActivity映射到DoActivity
[0073] UML和Simulink中的持续活动含义基本相同，直接映射。
[0074] U2S8：Entry映射到Entry
[0075] UML和Simulink中的进口活动含义基本相同，直接映射。
[0076] U2S9：Conditon映射到Condition
[0077] UML和Simulink中的条件含义基本相同，直接映射。
[0078] U2S10：Effect映射到Effect
[0079] UML和Simulink中的效果含义基本相同，直接映射。
[0080] U2S11：Trigger映射到Trigger
[0081] UML和Simulink中的事件含义基本相同，直接映射。
[0082] 本发明以自动驾驶仪系统的自动飞控软件为模型，构建UML需求模型到Simulink仿真模型转换场景，作实例说明。具体步骤如下：
[0083] (1)UML模型
[0084] 使用UML状态图对自动飞控软件的状态进行建模。根据自动驾驶仪当前的故障类别，自动驾驶仪的状态分为正常状态、瞬时故障状态、伪正常状态、永久故障状态。其中根据故障的危险程度，永久状态又分为第一类永久状态、第二类永久状态、第三类永久状态。具体的状态图如图5所示。
[0085] (2)模型转换引擎配置
[0086] 利用Eclipse中ATL插件完成UML状态机到Stateflow模型转换的配置。在运行配置界面需要添加ATL映射规则(.atl)，UML元模型，Simulink元模型(.ecore)，源模型(.xmi)，目标模型(.xmi)的相关路径。需要注意的是本文使用的UML源模型是uri:http://www.eclipse.org/uml2/3.0.0/UML，Matlab版本是2011a。源模型和和目标模型都是标准XMI格式。
[0087] (3)Simulink模型
[0088] 使用脚本语言对模型转换引擎生成的Simulink XMI文件进行解析生成图6所示的Simulink模型。
