Arcadia建模方法与SysML建模方法比较研究

鞠文煜 付 昕 /

(上海飞机设计研究院，上海201210)

0 引言

系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自功能之和[1]。按照系统的概念，强调的是实体和实体之间的关系，实体构成了系统的表现形式。更为重要的是，系统是为了实现功能而被建立，系统的功能主要由一系列的文档来描述和定义，通过系统工程的流程保证相关需求和功能被正确实施。然而，由于文档被自然语言书写，表达不直观，对于不同角色对系统的理解将存在差异，进而产生错误。对于复杂系统所包含的信息，其信息量巨大，超过了人们理解。这时就需要一种方法将复杂系统表现出来，将表现出的系统特征进行研究。基于模型的系统工程就是解决该问题的方法之一。

系统模型是现实系统的应用、模仿和抽象，它以某种确定的形式，提供关于该系统的信息，反应系统某一方面的属性和特征[2]。本文定义的基于模型的系统工程建模，并不是替代目前所有的建模方法和建模技术。基于模型的系统工程建模，强调的是模型的系统集成者，通过基于模型的系统工程建模，将不同领域的模型整合在一起，通过系统的方法从不同的视角，综合评估系统，以得到系统的最优解决方案。

1 基于模型的系统工程背景简介

一个复杂系统工程项目的成功，需要众多背景不同的人员参与其中。比如，系统工程师主要解决如何彻底地理解客户的需要，并将客户的需要转化成为系统的需求与功能；根据系统需求与功能，以及系统设计的约束，选取最佳的解决方案，确定系统给出的架构。软件工程师关心的则是软件需要完成的任务、功能及软件的约束。硬件工程师考虑的是硬件的运行环境，子硬件模块的成本、质量、功耗等硬件物理特性。用户则关心系统如何帮助用户解决问题，是否满足客户的需要，系统使用是否简洁明了等直接感受。由于不同的角色关心的问题不同，表达方式、文化背景差异大，因此需要一套有效的方法将系统通过不同的视角，以简洁明了的形式展现给相关人员，在系统实际被生产出来前，各方面充分了解需求，进行沟通，并形成最佳的系统解决方案。

系统模型用于表现物理实体的特征和细节，根据表现方式的不同，一般系统模型可分为图形模型、数学模型、逻辑模型等方式。系统模型一般用于描述系统的运行场景，系统的需求、组成、架构、行为等方面；通过不同形式的系统建模帮助系统设计人员更好地表现系统，分析系统，确认需求，让不同专业的工程师一起更好地沟通，支持系统更好的设计。

系统建模不仅能解决传统系统工程沟通等问题，还可以清楚地表征系统给的各方面特性，评估系统设计，分析系统性能需求和其他特性，在早期确认系统设计满足需求，利用模型对用户展开虚拟培训，并缩短系统开发时间。对于成熟系统，系统模型在做更改影响分析、协同设计及维护系统需求追溯性方面也有着优势。

2 基于SysML建模方法介绍

基于模型的系统工程近年来有了很快的发展，对象管理组织(Object Management Group，简称OMG)和系统工程国际委员会(International Council on System Engineering，简称INCOSE)推荐使用系统建模语言(System Modeling Language,以下简称SysML)[3]进行系统建模，描述系统的架构、需求、行为以及特性。SysML规范定义了系统建模语言的语法，以及所有图像所代表的意义，这样就保证了所有系统工程师使用准确的清晰无误的语言对系统进行统一描述。系统建模语言关系如图1所示[4]。

图1 SysML九种视图关系

基于SysML建模首先定义系统的范围，通过用例设计明确系统的活动。在需求捕获阶段识别干系人，并通过用例图(黑盒)的方式，明确干系人的使用场景，针对每个使用场景，根据系统的行为编制系统的活动图(黑盒)，在活动图编制过程中识别系统外部的输入和输出。通过用例图和活动图的编制，完成功能定义。在完成了用例图(黑盒)和活动图(黑盒)后，系统的行为和系统外部输入输出已被初步定义，这时就可以形成系统的框图，使用用例图、活动图和框图这三种类型的建模模型就可以完成对上一层级需求的确认。

经评审后的框图、用例图、活动图，作为系统设计的输入，重新识别干系人和用例，把用例和活动分解，在系统内部设立不同的功能模块，并明确每个功能模块的作用，形成系统的内部框图，根据系统内部框图的模块将系统活动图重新定义，完成整个系统的活动定义。然后根据系统化的系统活动图设计系统的时序图，定义系统内部各模块的功能和系统的运行机制；在定义系统时序图后，完成系统状态机图定义，检查每个系统状态是否合理并符合预期，当系统状态机图完成后，已基本可以确认系统设计是否满足功能要求，总结其他系统需求，形成系统需求图。以上工作完成后，就可以将设计好的系统架构、系统内部模型、系统用例模型、系统活动模型、系统时序模型、系统状态机模型和系统需求模型进行初步设计评审。

在详细设计阶段，软硬件设计人员和系统设计人员将针对初步设计阶段形成的系统模型，完成系统功能分配，将系统功能分配至软硬件及补充系统的包图。针对系统运行的各种内部和外部参数，采用系统参数图进行定义，形成标准的基于XMI(XML-based Metadata Interchange，简称XMI)的参数集，以及接口的逻辑框图。最后根据完成的系统包图和系统参数图，对之前形成的系统架构、系统内部模型、系统用例模型、系统活动模型、系统时序模型、系统状态机模型和系统需求模型进行更新和细化。

在生产和制造阶段，由于SysML和统一建模语言(Unified Modeling Language，简称UML)有一定的共通性，软件设计人员可以利用之前建立的系统模型，进而继续建立软件模型，建立好的软件模型可以提供给系统作为软件设计确认的证据。另外由于SysML采用基于XMI的架构性语言，一般建模工具对于SysML建立的模型均提供XMI接口，可以利用工具生成基于XMI架构的测试脚本。

如果在系统改进阶段，由系统建模工具提供统一的管理方法，确定优化项目后，可以很方便地确定受影响的模块，分析更改影响的结果，并提供初步的确认和验证。

3 Arcadia方法介绍

随着基于模型的系统工程的迅速发展，各公司对系统工程建模均有一定的研究，其中，泰勒斯公司基于IEEE 1220标准，开发并定制了其特有的系统建模工具Capella，并形成了符合其自身特点的架构分析和设计集成方法，即Arcadia方法论。

Arcadia方法将系统建模的过程分为运营分析、系统分析、逻辑分析、物理分析和终端产品结构分解共五层[5]，如图2所示。Arcadia方法在SysML的基础上做了扩展和定制，从而形成了具有定制特征的建模语言，通过SysML的拓展和定制，Arcadia方法补充了运营理念、目标和系统任务分析。

图2 Arcadia方法建模关系图

与SysML不同，通过使用Arcadia方法建模，无需明确系统边界。Arcadia方法结合了美国国防部架构框架(Department of Defense Architecture Framework，简称DoDAF)[6]的相关理念，首先定义的是用户需要系统完成的任务，也就是用户需要具备的运行能力。在运行分析阶段，只分析用户遇到的问题、用户的需要以及用户的潜在需求。这时并不需要确定系统的边界，当系统出现在运营分析中，就限定了给用户的解决方案，也就没有办法评估相关方案是否是最佳的解决方案。运营分析的对象是用户、用户在运营中的角色、用户完成的活动，分析的内容是用户活动是否存在问题和不足、是否有改进的空间。

运行分析完成后，系统工程师需要将不同用户的需求进行整理和分析，分析后得到统一的系统需求和系统模型。在系统分析阶段，研究的是系统如何满足用户的需求，提供具体的解决方案，通过运行能力的细化，明确系统在用户运营分析中需要完成的任务，总结抽象系统需要具备的能力，定义系统需要完成的活动，考虑运行约束给系统活动带来的限制，最终形成系统需求。在系统分析阶段，还需要考虑系统活动完成所需的输入条件，也就是系统的外部接口。

逻辑分析是系统功能的细化，将系统功能分解为子功能，并在系统层面实现系统子功能的整合与分配。逻辑分析还解决系统内部约束、系统内部功能、功能关系、具体实现的技术以及潜在技术等方面问题。在逻辑层面，实现详细的系统分析，考虑系统的约束，平衡系统性能、安全性和可靠性等指标，以求得到最佳的系统方案。系统分析和逻辑分析共同完成系统功能定义，系统需求分解与分配，形成系统定义。

物理分析是定义系统的具体实现方式，考虑系统的物理特性，以达到系统在质量、功耗、成本等物理层面的最优设计。物理分析和终端产品分析适用于不同的系统对象和系统组织形式。物理分析过程考虑的是系统如何实现，包括物理约束的系统架构选择，物理连接形式，各部件实现的功能等。

物理层向下分解，还可以将物理实现再分解至各个构型项的物理实现，也就是终端产品分解结构定义，这个层级解决的是软硬件分配和集成的过程，一般是软、硬件工程师关注的重点。

4 Arcadia方法与基于SysML方法建模对比分析

基于SysML方法建模与Arcadia方法建模对比分析见表1。

表1 基于SysML方法建模与Arcadia方法建模对比分析表

使用Arcadia方法的建模工具Capella建模，无需对系统建模理论做研究，仅需按照Arcadia方法本身以及工具提供的建模思路进行，对于经验不足的系统设计者，更容易掌握并开展系统建模设计。

SysML系统建模语言，由软件面向对象设计的UML语言演化而来，为了保证系统和软件良好的兼容性，部分SysML中的定义与沿用了UML语言的图形和表现形式。然而由于系统工程师和软件工程师的视角不同，背景知识也不同，使用SysML进行系统建模对系统工程师要求较高。由于SysML对UML的继承性，SysML提供了更严格的定义和丰富的关系，但是在系统层面，相关定义过于复杂，不利于不同专业人员之间打破壁垒进行沟通。

航空系统多数为大型复杂系统，在建模时，应考虑系统的复杂度，而系统建模工作能帮助系统管理复杂度。Arcadia方法将系统模型分成不同的视角，不同的分析角度，这样就可以让不同专业的人以不同的复杂度进行评估。

基于SysML建模使用用例图和活动图定义系统，明确系统的范围；使用Arcadia方法进行建模，不仅关注系统如何实现需求，而且可以分析系统的运行理念，让系统设计者更好地理解用户的需要，并定义系统运行理念，为后续用户培训、文档编制打好基础。

5 建模工具对比分析

基于SysML的建模工具相对于Arcadia方法的建模工具更为丰富，本文对IBM(International Business Machines Corporation，简称IBM)公司的Raphsody工具和Capella工具进行对比，具体见表2。

表2 Raphsody工具与Capella工具对比分析表

SysML建模有严格的层级定义，不能支持不同层级的建模分析嵌套。使用Arcadia方法只需考虑最终实现，方法更为灵活。Capella工具提供高效精准的模型自动转化功能和追踪功能，最终系统模型将不同的功能统一到一张图中，表达更为直观。而Raphsody工具不支持不同分析模型的转换，需要建模人员进行分解和定义。

在系统建模初期，应建立系统建模的目标，并定义哪些系统模型需要被定义，这些系统模型解决什么问题，各个模型之间的关系是什么。Arcadia给出了各个分析之间的关系，而SysML由于适用于更广泛的用途，针对不同分析的模型，各种图之间的关系并不清楚。

Capella工具基于Java编制，提供了丰富的接口，用户可以根据具体实际需要进行灵活定制。Raphsody本身功能丰富强大，但是可扩展性较差。部分其他基于SysML工具提供高于Raphsody的可扩展性，如EA(Enterprise Architect)工具。

Capella将系统建模方法Arcadia融入到工具设计中，工具使用者在建模过程中学习和实践Arcadia建模方法。而其他基于SysML的建模工具，并没有将建模方法指导融入到建模工具中，工具使用者需要建立一套适合自己的建模方法，将SysML定制化以限定系统建模的范围和约束。

6 结论与展望

系统工程建模强调的是模型的系统集成，通过基于模型的系统工程建模，将不同领域的模型整合在一起，通过系统的方法和不同的视角，综合评估系统，以得到系统的最优解决方案。好的系统模型应该能清楚直观地表示系统设计，特别通过系统模型显示出可能发生的设计缺陷；打破系统设计者、用户和系统实现者之间的壁垒，从而有效沟通；应具有标准的、统一的术语和格式定义；另外，通过建模，不同的用户可以从自己的视角找到问题所在，比如建模一致性，系统性能和软、硬件实现的冲突，系统性能与项目成本的冲突，技术成熟度和项目进度的冲突等。

配合已有的业务流程，系统模型还应可以从模型转化成为其他工作的输入，比如转化成为系统需求文档，方便需求的传递；可以通过不同层级的仿真或建模确认系统可否实现。通过系统模型逐渐积累设计经验，可以降低风险。

本文对比发现Arcadia方法建模在系统架构和系统运行方面有着较好的优势，对系统建模者本身要求也较低，比较适合解决系统层面的问题。通过Arcadia方法和基于SysML方法建立的系统模型，无法实现高仿真度的运行，后续还需开展工作结合特定领域的模型进行系统仿真。