面向复杂系统需求分析的DSL构建

2022-10-29廖万斌曹云峰王新尧

系统工程与电子技术 2022年11期

廖万斌, 曹云峰, 王新尧

(南京航空航天大学航天学院, 江苏南京 211106)

0 引言

近年来,随着我国的科技水平不断提高,航空、航天领域的设计与研制技术都开始走在了世界前列,这意味着需要面临越来越多正向设计方面的难题。而航空航天领域中所涉及的系统和体系,都是十分庞大的,随着其复杂性的不断增加,其研发过程以及研发的组织团队的复杂性也不断上升,这又给整个工程带来了新的困难。

面对这个问题,国际系统工程学会(International Council on Systems Engineering, INCOSE)在2007年提出了基于模型的系统工程(model-based system engineering, MBSE)方法。其基于模型的特性,可以通过形式化的建模方法,更好地在团队中支持复杂系统整个生命周期的研发。

在系统的整个生命周期中,最重要的就是需求分析的部分,尤其是对于正向设计来说。整个系统的后续研发工作都是基于需求的牵引来进行的,一旦需求出错,后续的工作做得再好也失去了意义。

而传统的MBSE方法所提倡的是使用通用的建模语言,例如系统建模语言(system modeling language, SysML)来支持整个系统全生命周期的研发活动。但是,这种通用的建模语言通常是基于完整的方法论,内聚性很强,团队中不同领域的研发人员对其的学习过程很困难,这阻碍了MBSE方法在工业实践中的落地。同时,SysML中对于需求分析与建模的支持也不足。

系统工程中的很多方法都脱胎于软件工程领域。而在软件工程中,近些年对于领域特定语言(domain specific language, DSL)的关注也多了起来,但实际上DSL已经存在了很长时间。DSL是指针对特定领域需要而构建的语言,往往是形式化的,这意味着其可以由计算机处理。同时,领域特定的特点也使其更容易上手与使用，其提供一些通用语言所没有的功能,同时又因为较窄的适用范围而获得了更简洁的表示。这些优势使得DSL在模型驱动的需求工程中能得到很好的应用。

在需求分析方面,对模型驱动方法的研究并不多。2010年Ameller等指出,模型驱动的发展侧重于非功能性需求(non-functional requirement, NFR)是不够的,这种情况至今没有太大改善。在今年的研究中,Ameller等发现,在模型驱动的发展实践中,大多数人关注功能性需求(functional requirements, FR),而专注于NFR的研究很少使用模型驱动思维。在功能要求分析中,Karagoz等使用SysML模型支持系统需求的分析。目标图也是一种方法,Khan等和Chung等在相关研究中使用了以目标为导向的方法。

在系统工程中引入DSL和多架构建模、特定域的建模概念方面也取得了一些成果。Kurtev等研究了DSL在模型驱动工程中的应用,结果表明模型驱动工程及DSL方法在复杂系统中表现良好。王赞超等为系统工程中的需求建模而构建了DSL,但所构建的DSL非常简单,只针对需求建模的部分,对于SysML中使用的需求图没有太大优势。

本文将针对需求工程中对需求分析以及建模的需求,构建需求分析语言(requirement analyze language, RAL),以弥补SysML的不足。以下为本文的组织:第1节从下至上地分析RAL在模型驱动工程中的底层需求;第2节依据方法论从整体视点由上至下地分析RAL的需求;第3节为DSL的构建方法;第4节依托具体问题介绍所构建的DSL对模型驱动开发的支持以及其扩展性;最后是对本文的总结。

本文的主要贡献如下:

(1) 从具体的工程以及方法论,即自下而上与自上而下两个层面分析了模型驱动工程中进行需求分析的需要。

(2) 依托具体需求构建了相应的DSL,具有良好的对模型驱动开发的支持。

(3) 以RAL为例,提供了一种DSL的构建思路。

1 工程需求

本节中结合实际工程需求,从底层分析RAL在实际工程中应用时有哪些需要。

在民航领域,系统工程的实践已经有一定的积淀。根据ARP 4754A标准,在民航飞机的生命周期中,在需求分析之前与之后的环节分别是功能分析过程与设计综合过程。由此可以确定需求分析环节的输入与输出:输入为利益攸关方的需要以及功能清单、功能架构等,输出为产品需求集。尽管输入已经有了功能清单等,但依旧需要基于内部的需求分析来生成最终的功能性需求。

1.1 FR

对FR的分析需要将其形式化,这就涉及到过程建模。Shaked等联系开发过程设计(development process design, DPD)本体,对DPD工程方法提出了7点基于本体论的需求:

A1. DPD应由活动、工件、复合工件状态来组成过程;

A2. DPD应支持对活动的定性、无分支、程序性描述;

A3. DPD应支持对并行过程的详细描述;

A4. DPD应允许描述开发活动的附加/建设性观点;

A5. DPD应反映过程范围;

A6. DPD应鼓励多层次方法。即应支持不同层级方案之间的向前、向后一致性;

A7. DPD应适应变化以及不确定性和有目的的创造性。

同时,为了更好地定义过程模型,需要考虑过程模型本体。过程模型主要用于3个目的:描述实际事件、提供描述性过程、解释性地提供过程的原理。Rolland由此提出了过程模型应具有的理想特征:

B1. 理想状态下,过程模型应提供广泛的粒度;

B2. 过程模型应提供适应变化的机制;

B3. 开发过程模型应能够重用之前用于设计类似组件或系统的模型元素;

B4. 过程模型应与相关过程本体清晰对应。

而根据中国商用飞机有限责任公司在工程过程的系统工程实践,可以总结出需求分析过程中对FR的处理主要在于以下几个方面:

C1. 应定义影响需求的内外部约束;

C2. 应定义环境;

C3. 功能性需求定义中应列出所有的功能;

C4. 功能性需求定义中应列出产品或系统的特征;

C5. 功能性需求定义中应能联系功能与特征。

结合DPD过程方法的7点需求、过程模型应具有的4点理想特征,以及根据需求分析过程中对FR的分析要求对其进行适当裁剪与修正,可以导出RAL中对FR分析视点、视图构成的需求。综合需求将数个细分的简洁需求拆分,末尾的括号中标明了需求的来源。

应由活动、工件、复合工件状态来组成过程(A1,B4),REQ即requirements,表示需求。

REQ1. 视图应支持活动表示;

REQ2. 视图应支持工件表示;

REQ3. 视图应支持复合工件状态表示;

REQ4. 视图应支持影响需求的内外部约束表示(A4,B4,C1);

REQ5. 视图应支持环境表示(A4,B4,C2)。

应能提供不同层级的视点来描述产品或系统的功能以及特征(A5,A6,B1,C3,C4)。

REQ6. 视点应支持不同层级的表示;

REQ7. 不同层级的视点应指明适用范围;

REQ8. 不同层级的视点中应包含全部的功能;

REQ9. 不同层级的视点中应包含全部的产品或系统特征。

应能并行表示功能与特征并建立联系(A3,C5)。

REQ10. 视图应支持功能与特征的并行表示;

REQ11. 视图应支持工件之间的联系表示。

由此得到RAL在FR描述方面的需求集。

1.2 NFR

产品或系统的NFR跟随FR而产生,相互联系,NFR可以支持功能更好地实现。因此,在NFR描述方面,重点在于NFR与FR之间的联系。

在增量软件开发以及一些敏捷性工程中,FR的优先级需要重点考虑。但是在常规工程中,由于NFR间复杂的关系,NFR之间的优先级关系更值得讨论。

与FR不同,NFR之间可能会存在冲突。Roy等将NFR之间的冲突考虑进了对FR之间的排序中,并且基于此生成了集群图来表征其间的关系。同时,需求之间也会存在依赖关系。Martakis等进行的一项调查表明,很多项目中没有采取任何措施来应对这种依赖关系,使得这种需求依赖带来的风险被放大了。

面对这些问题,RAL在NFR分析方面的需求也就明确了:

REQ12. 视图应支持FR与NFR的并行表示;

REQ13. 视图应支持FR与NFR之间的关系表示;

REQ14. 视图应支持NFR之间的冲突表示;

REQ15. 视图应支持NFR之间的优先级表示。

1.3 需求管理

面对一个复杂系统,在设计阶段需求管理的重要性不言而喻。这一阶段许多需求尚未成型,不同层级的需求经常发生变动和修改。因此，基于需求管理的需要,总结出以下需求:

REQ16. 需求应具有唯一的标识符;

REQ17. 需求的来源应可识别;

REQ18. 需求应是可追溯的。

2 方法论需求

语言通常是与一套方法论相联系的。对一种语言来说,尤其是一种领域特定的语言,存在其想要描述的目标。例如,超文本标记语言(hyper text markup language, HTML)作为一种DSL,其目的为表示网络文档。而具体语言的组织方法则与其框架有关,其关系如图1所示。

图1 视点与视图Fig.1 Viewpoint and views

要明确需要构建什么样的语言,就要先确定框架以及对应的视点和视图。

构建语言的过程中,如果仅着眼于底层,试图依靠一点一滴的细节拼凑起整个框架的话,最后的结果将会不尽人意。在面对复杂系统时,这一点尤为明显，完全依靠还原论的思想是不严谨的。因此,需要同时进行自上而下的审视,兼顾整体论的思想对DSL的构建加以辅助。本节根据RAL承载的方法论,总结并确定RAL的需求,由此对模型元素进行形式化。

首先,为了更加地直观以及易于上手,RAL采用图形化的方式进行建模,即RAL采用图形化表示的具体语法。

尽管RAL在进行FR分析时需要进行过程建模,但是这与单纯的业务建模,例如业务流程建模与标注(business process modeling notation, BPMN),还是有着很大的不同的。RAL进行建模的最终目的是为了更好地确定FR,功能与过程是密不可分的,因此，RAL不应当将对象与过程割裂开来。也就是说,RAL不应是单纯的面向对象的语言,这一点与SysML不同,而这也将从根本上确定RAL的特征。

另一个明显的特征是,RAL需要描述过程,需要描述FR与NFR之间的关系,也就是说,RAL具有一种以上的视图。

作为一种建模语言,其是否形式化、形式化的程度有多深也是应当关注的议题。由于存在尽可能精确的要求,最大程度上的形式化是十分必要的。然而,并非所有的事物都可以形式化,涉及到需求时就尤为如此。因此,RAL在涉及具体的需求时仍需要自然语言在一定程度上的参与,在其他方面则需要以图形化的方式尽量地形式化。

综上,即得到了RAL整体视角上的4个特征。其要点在于确立了对象与状态并存的规范,赋予RAL更加丰富的表达。

2.1 功能分析视图

在系统功能的视点上,与之对应的是功能分析视图。

(1) 方法与视图

功能作为一种动态特征,可以进一步体现为通过某个过程来使对象的复合状态发生改变的行为。此过程的输入为系统的功能清单,所以在分析环节开始时,功能应以未细化的状态出现。因此,功能分析过程的第一步应为系统功能清单以及架构的形式化表示。

在此基础之上,应在同一层级完善系统的一些状态变化,确定功能的输入输出以及主体,为功能到过程的分解做准备。

下一步,在功能中用具体的过程填充,功能清单中的功能在这个阶段进一步细化,才能够生成FR。因此,功能/需求分解尤为重要。令decomposition(,)表示是的一个子功能需求,则功能需求分解应满足:

(∀,,)decomposition(,)∧decomposition(,)→decomposition(,)

(1)

(∀)～decomposition(,)

(2)

(∀,)decomposition(,)→～decomposition(,)

(3)

(∀,,)decomposition(,)∧decomposition(,)→=∨decomposition(,)∨decomposition(,)

(4)

且最重要的是,功能需求分解应符合以下原则:① 分解后产生的功能需求应与原需求保持语义一致;② 分解过程中无冗余功能需求产生。令exp()为功能需求的逻辑表达,即

(∀)decomposition(,)∧…∧decomposition(,)→exp()=exp()∧…∧exp()

(5)

因此,为了满足以上原则,分解须在单独的子视图中进行。并且,为了确保子视图中的分解在语义上与父视图保持一致,子视图的建立应首先确定功能的边界以及功能的输入输出,由此来限定子视图的语义。

最后,根据所建立的各级视图,提取系统的各级FR。

(2) 视图元素

设系统功能集为。同时,由REQ4与REQ5,视图中的实体元素还应包括环境因素与内外部约束,设其集合分别为与。

在对开发过程模型进行研究时,Browning发现需要非常多的属性来对开发情况进行描述。而根据Shaked等对BPMN、对象过程方法(object process methodology, OPM)以及软件开发过程元模型( software process engineering meta-model, SPEM) 3种较为先进的语言的研究评价,其在表达工件的复合状态方面都有明显的欠缺。作为MBSE 6种方法论之一,同样并非面向对象方法的OPM,其建模元素中仅包含3种实体:对象、状态与过程。并且对象仅能在不同的状态间切换,同时仅能处于一种状态,这对于复杂系统的功能表示是不够的。因此，RAL在支持复合状态表示的同时,过程的输入输出也应可以为复合态。若存在对象,其状态与属性分别属于其状态集与属性集。则其复合状态集CS=∪。那么仅涉及此对象的过程应可表示为

cs=(cs)

(6)

最后,由本视图得到的输出应是系统的FR。因需求管理的需要,亦即REQ18、REQ19,需求亦应作为一种实体加入视图当中,令其集合为FR。

除了实体之外,分析过程还涉及到关系,在视图中即表现为实体之间的连接。同OPM一样,连接应分为结构性连接以及过程性连接。结构性连接相对简单,表明实体之间基本的结构关系,例如包含关系、特化关系等,是一种静态的描述。而过程性连接则表现为一种动态的行为,主要包含支持性连接与变换连接。

由以上分析,结合需求集,可得系统功能视图的形式化表示:

(7)

式中：∈为环境因素;∈为内外部约束;∈为对象;cs∈CS为复合状态;∈为功能;∈为过程;sl∈SL为结构性连接;pl∈PL为过程性连接;∈FR为系统FR。

对应方法论的要求,这个视图需要分不同层级来表示,这与REQ6相对应。在不同的层级上对系统的功能进行表示,一定程度上也可以体现复杂系统的涌现性。依据REQ7,功能与过程实体应连接至各自的子视图。对应方法论有:

(8)

式中：∈为功能或过程的输入输出边界。同时,若令为不同层级视图的集合,则有:

={|∈N}

(9)

且因REQ8与REQ9,对应有:

=∪∪…∪

(10)

CS=CS∪CS∪…∪CS

(11)

2.2 NFR视图

通过系统功能视点的分析,系统的FR应当已经被提取出来。要继续则需要通过系统需求的视点,这个视点应包括由FR到NFR的NFR分析视图以及对NFR进行排序的优先级视图。

(1) 方法与视图

2010年曾有研究指出,模型驱动开发中对NFR的关注不足,至今这种情况依旧没有太大的改善。在模型驱动开发的实践中,人们多数关注的是FR,而关注NFR的研究又很少利用模型驱动的思想。

在分析NFR时,一部分来源于环境因素以及系统内外部约束的限制,在视图中需要体现这两种实体对系统的影响。另一部分NFR直接来源于FR,其目的在于支援FR更好地达成。在分析的过程中,这部分的视图在功能分析视图的基础上构建,这样能更直观地看到各个过程。同时,加入系统的边界以及非功能性需求元素,设其集合为SB与NFR,并且加入新的连接类型以支援需求间关系的表示。

(2) 视图元素

由以上分析,结合需求集,可得系统NFR分析视图的形式化表示:

(12)

式中：sb∈SB为系统边界;nfr∈NFR为系统NFR。

最后在优先级视图中,只需要展现需要排序的NFR,并且以连接体现其间的优先关系即可。即

(13)

式中：∈为优先关系连接。

3 DSL构建

DSL同样是一门语言,而任何语言的构成都需要定义语言的语义以及语法。如图2所示,形式化建模需要包含语义与语法,而语法分为具体语法与抽象语法,语义则分为语义映射与语义定义域。

图2 领域建模概念Fig.2 Domain modeling concepts

具体语法用于说明语言中特定部分所代表的含义,可分为文本化表示以及图形化表示。文本化表示的例子有Java中“import”代表导入包,而SysML中的火柴人则代表参与者就是一个图形化表示的例子。

抽象语法则更为重要,其定义了语言的结构,语言的组成元素及其组合的规则。通常这可以由元模型来定义。

语义的定义域指明模型的含义。语义的映射则指明这种含义的赋予规则。

确定视点与视图等后,就可以根据以上规则来进行RAL的构建。

3.1 抽象语法

为了进行图形化语言的构建,本文在GOPPRR(groph object properby port role relationship)的元元模型的基础上定义RAL的抽象语法,此元元模型来自于MetaCase公司。

GOPPRR的元元模型包含6种元素,如图3所示。

图3 GOPPRR元元模型Fig.3 GOPPRR meta model

其中，图由其他5种元素组合而成;对象是一种基本元素,可以与其他对象连接;属性不能单独存在,依附于其他元素以表达其特性;端口依附于对象上,表达对象用于连接的元素;角色依附于连接上,表达连接的对象在关系中充当的角色;关系通过角色连接对象的端口,表达对象之间的交互方式。

基于RAL的需要,在GOPPRR的基础上,加入重叠作为元元模型的一种元素。扩展后的元元模型即为GOPPRRE(extended)元元模型。

重叠是指通过对象之间的位置重叠,表达对象之间关系，如图4所示。

图4 重叠Fig.4 Overlapping

3.2 具体语法及语义

本节将介绍RAL中建模元素的具体语法以及对应的语义。具体语法的设计在MetaEdit+平台上完成。

RAL具有3大类实体,分别为对象、状态以及过程。对象类实体分为环境、内外部约束、物理实体、需求这4类。这4类实体可以借由属性元素直接包含各自的一些固有属性，如图5所示。

图5 对象类实体Fig.5 Object class entity

状态类实体则描述复合状态,分为相对稳定的属性实体以及状态实体，如图6所示。

图6 状态类实体Fig.6 State class entity

过程类实体则描述动态的过程，分为功能以及过程,过程类实体具有自己的子图，如图7所示。

图7 过程类实体Fig.7 Process class entity

除去实体之外的建模元素是连接，连接分为结构性连接以及过程性连接。具体语法、语义如表1与表2所示。

表1 结构性连接Table 1 Structural connection

表2 过程性连接Table 2 Process connection

具体语法与语义确定之后,依托RAL的分析方法也清晰了起来。

首先，依据功能清单,使用式(7)中的元素建立各级功能分析视图,这一步不涉及任何过程,忠于功能清单的表示。接下来将功能由过程细化,将涉及到的对象、关系等元素填充进视图中，然后从表达清晰的视图中提取系统功能需求。

接着,使用式(12)中的元素,依据系统功能需求建立需求分析视图,将环境因素与内外部约束添加进视图中,并分析其对功能实现的影响;然后依据视图提取NFR。

其中,功能/需求分解视图的优势在于,依据方法论,将子功能/需求视作黑盒,在实施分解工作之前优先确立系统边界以及输入输出,由此指引后续分解的进行,来确保分解过程符合式(1)～式(5)的规范。

4 实例分析

本节将使用RAL进行一些分析,通过具体问题来体现其对模型驱动设计的支持。

4.1 问题描述

RAL的构建初衷就是为了更好地支持模型驱动开发,也就是弥补MBSE中需求分析环节基于模型的需要。本节将使用RAL对有人机与无人机协同作战系统做实例分析,同时将Karagoz等使用SysML的方法作为比较。

具体描述为:乙方有两架战斗机入侵甲方领域,甲方派遣一架有人机指挥控制两架无人机执行拦截攻击任务为背景。其中,有人机只执行指挥任务,2架无人机携带中远距空空导弹实施对空拦截。作战任务清单如下:

在T0～T1时间段内,总指挥控制中心接受预警信息,并发布任务给有人机及无人机地面站;

在T1～T2时间段内,从有人机和无人机接受任务命令开始,对进行有人机和无人机执行任务飞行前准备和检测,同时进行机场的飞行前准备;

在T2～T3时间段内,有人机、无人机从有人机机场、无人机机场起飞、爬升至聚集点,无人机开始编队飞行,有人机以安全距离跟随飞行;

在T3～T4时间段内,无人机进入任务区,将探测到的乙方情报反馈给有人机,有人机保持远距战区,无人机在有人机的领导指挥下攻击对抗乙方战机;

在T4～T5时间段内,目标摧毁信息传回机载设备和地面指挥中心,进行评估。

4.2 具体分析

取T3～T4时间段进行分析。由功能架构可以初步建立如图8(a)所示功能分析图。这个阶段的视图由功能清单与架构直接转化而来,是输入的形式化表达。这一阶段的任务在使用SysML进行分析时尚可以由活动图完成,如图8(b)所示。

图8 顶层功能分解Fig.8 Top level function decomposition

在此基础上将进行功能的细化,如图9所示。在此阶段的视图中,加入了各个对象的状态,以及状态之间的转换,功能对状态之间的要求等。而这部分在Karagoz等的分析中是缺失的,因为SysML中状态与对象是分离开的,如果想要表示状态之间的转换,需要单独的状态图来完成,这使得对应关系在分析中缺失,这种分离对分析设计工作是不利的。由此可以体现出,RAL在针对需求分析的表达上因具有对象与状态并存的特性,对系统的描述更加清晰。

图9 功能分析图(阶段2)Fig.9 Functional analysis diagram (phase 2)

图10为图9中指挥功能的子视图。此视图依据前文所分析的分解过程原则对指挥功能加以分解。首先确立系统边界,并使输入输出与上一级功能严格对应。可以看到，视图中标明了功能的输入输出边界,并且与父视图严格对应。视图中左边的部分是功能的输入,右边的部分为功能的输出,这一步首先限定了子视图功能的语义,使得子图表示的功能在语义上能与上一层级的功能保持一致。依据输入输出进行子视图的构建,能避免分解不彻底或者产生冗余,体现了RAL针对功能/需求分解的辅助功能。

图10 功能分析子视图(阶段3)Fig.10 Functional analysis diagram (phase 3)

而使用SysML方法进行的分解工作，如图11所示。依旧使用活动图进行分解,同时只能进行简单的活动顺序表示,分解过程中难以保持功能分解的原则。同时可以看到,SysML的功能分解,重点在于完成任务的顺序,关注的是时间跨度上的变化;而本文采用的方法着眼点在于功能的实现,因为这是FR产生的根源。

图11 SysML的低层次功能分解Fig.11 Low level functional decomposition of SysML

最后,根据视图以及各层级的子视图,提取出系统的各层级功能性需求,完成功能分析视图。如图12为从指挥功能中提取的功能性需求。经过不同层级的缩放,可以实现不同层级需求的表示,越是高层级的需求便越不会限制具体的设计,这对正向设计来说十分关键。同时,每一层级的需求不仅能追溯至上一层级,也能追溯至具体的功能与过程。在产品开发早期,概念会经常发生变更,需求也能马上根据其进行迭代。

图12 功能分析视图(阶段4)Fig.12 Functional analysis view (phase 4)

在使用SysML的方法中,具体的需求使用需求图表示。需求图只能表示需求之间的关系,与上一过程是分离开的,在追溯性上有欠缺。同时也不支持多层级的缩放,面对复杂系统时会显得不清晰。

NFR则来自于FR以及环境因素、系统内外部约束。在Karagoz等的方法中,主要只考虑了外部约束,并且这部分的分析较为简单,使用表格的形式进行,没有模型的支持,如表3表示。但在RAL中,这3种因素都可以形式化地表示出来,如图13所示。在细化过程的基础上,添加进内外部约束和环境因素,及其与功能之间的关系，之后便可以更为直观地分析出NFR。