基于UML_ARENA的建模与仿真方法研究_方绍强

第31卷　第3期系统工程与电子技术Vol.31　No.32009年3月SystemsEngineeringandElectronicsMar.2009

文章编号:1001-506X(2009)03-0691-06

收稿日期:2008-01-17;修回日期:2008-03-25。作者简介:方绍强(1978-),男,博士研究生,主要研究方向为系统仿真与优化。E-mail:fangsq@gmail.com

基于UML-ARENA的建模与仿真方法研究方绍强1,卫　克1,2,陈伟鹏1,2,赵尚弘1,胥　杰1(1.空军工程大学电讯工程学院,陕西西安710077;2.空军后勤部,北京100720)

摘　要:为开发出便于复用、扩展的离散事件仿真系统,提出了一种新的建模与仿真方法———UML-ARE-NA。该方法利用统一建模语言UML对系统建模,利用仿真软件ARENA对所建模型进行仿真。该方法不仅规定了仿真系统的开发步骤,还设计了对象模型转换规则以及ARENA映射规则。整个开发过程分为建模与仿真两个阶段。在建模阶段,首先通过对系统进行概念分析,设计出系统的功能模型和动态模型。然后利用对象模型转换规则将功能模型和动态模型转化为对象模型。在仿真阶段,利用ARENA映射规则将对象模型转化为ARE-NA仿真程序。通过飞行保障过程的一个仿真实例对该方法的有效性进行了检验。关键词:统一建模语言;仿真;飞行保障过程中图分类号:TP391.9 文献标志码:A

ApproachtomodelingandsimulationbasedonUML-ARENA

FANGShao-qiang1,WEIKe1,2,CHENWei-peng1,2,ZHAOShang-hong1,XUJie1(1.TheTelecommunicationEngineeringInst.,AirForceEngineeringUniv.,Xi'an710077,China;2.LogisticsDept.ofAirForce,Beijing100720,China)

Abstract:Inordertodevelopreusableandextendiblediscrete-eventsimulationsystems,anewmodeling

andsimulationapproach,UML-ARENA,isproposed.Inthisapproach,asystemismodeledwiththeunifiedmodelinglanguage(UML)andsimulatedinthediscrete-eventsimulationplatformARENA.Thedesignproce-dureofUML-ARENAiscomposedoftwosteps:modelingandsimulation.Firstly,throughaconceptionanaly-sisofthesystem,thefunctionalmodelanddynamicmodelaredesignedbyUML.Boththetwokindsofmodelsaretransformedintoanobjectmodelbyobjectivemodeltranslationrules.Then,ARENAmodelsareobtainedbyobjectmodelingtransformingaccordingtoARENAmappingrules.FinallytheUML-ARENAmethodisver-ifiedthroughthesimulationexampleofaflightsupportingprocess.Keywords:unifiedmodelinglanguage;simulation;flightsupportingprocess

0　引　言 计算机仿真技术对探索复杂系统深层次的运行机理并揭示其规律性具有十分重要的意义。统一建模语言(uni-fiedmodelinglanguage,UML)是一种面向对象、有严格语法定义、易于表达、可视化的图形建模语言。通过一整套的图形符号和相应的方法学来系统地反应现实世界的客体。用UML建立起的系统模型是独立于系统实现语言的模型,具有更大的通用性,以便于不同人之间有效地共享和交流设计成果[1-2]。但是,UML建立的系统概念模型如果不能与仿真工具联合起来,概念模型的程序实现将是一项困难的工作。仿真软件ARENA是在早期的SIMAN/CINEMA仿真系统基础上发展起来的,不仅保留了SIMAN/CINEMA的强大功能和灵活性,而且对其功能和解决问题的范围进行了重大扩充。ARENA软件具有友好的用户接口和方便的动画元素。此外,还可以与VisualBasic或C通用程序集成,大大增强了建模能力。ARENA提供了多种建模模板和刻画模型的层次结构,既可以在较高层次上快速建立模型,也可以在较低层次上描述模型的各种细节,从而为用户提供了更大灵活性[3-4]。ARENA软件是对过程中实体流

进行抽象和建模,属于面向业务(transaction-oriented)的离散事件语言。面向业务的开发过程在很大程度上是基于直觉的,很难将系统需求与仿真程序完全贯穿在一起[5]。

结合面向对象建模语言UML和面向业务仿真软件A-RENA的优点,为开发出便于复用、修改以及扩展的离散事件仿真软件,设计一种将两者集成起来的方法具有意义[5-6]。基于此,本文提出了一种新的建模与仿真方法———

·692　·系统工程与电子技术第31卷　

UML-ARENA。目的是通过基于规则的方法提高软件开发的效率,并且在ARENA的环境下增加面向对象的原理。1　UML-ARENA步骤1.1　组件和用例UML-ARENA概念有组件和用例(usecases)2个基本术语。系统可以看成是一组相互交互的组合在一起的组件,这些组件能够根据自己的角色和作用触发一系列事件。当组件与其它组件进行交互或是对事件做出响应时,需要输入、资源以及输出。另外,组件自身的内部状态也会作为交互的结果随着改变。仿真系统模拟这些交互并记录它们的影响。用例描绘了一个组件在一个特定的事件中的活动以及活动的顺序。活动是组件能够履行的离散的行为,通常会引起组件状态的改变。UML-ARENA要完成3种功能:一是系统的概念分析;二是根据一系列规则将实际系统的模型转化为面向对象的模型;三是将各个对象类转化为ARENA程序。UML-ARENA可分为建模和仿真2个步骤实现其功能。在建模阶段利用UML完成功能模型设计、动态模型设计和对象模型设计。在仿真阶段,利用仿真软件ARENA对所建模型进行仿真(见图1)。图1　UML-ARENA实现步骤1.2　UML-ARENA建模1.2.1　功能模型功能模型描述了系统要做的工作(如对飞机的各项保障活动),并不指定系统如何工作。在UML-ARENA中,用例图用来描述系统的高层功能。飞行保障过程是指航空兵场站各保障单元(如加油保障、充氧保障、充氮保障等)对担负战斗或训练任务的飞机的保障需求做出积极响应,并对其进行及时保障,使其能够快速起飞(或再次起飞)执行任务的过程[7-11]。航空兵场站飞行保障过程包含三种流:一是物理流,表示车辆、物资、飞机等装、设备的活动;二是信息流,表示与系统功能相关信息的传输与通信;三是决策流,表示对物理流的控制。通常,功能模型描述的是系统内部的信息流:数据的源、目标以及传输活动。在UML-ARENA中,通过用例图表示系统组件及组件间的交互规则。用例图描述参与者与系统组件之间的交互。系统组件用类表示,每个组件在整个系统和每个用例中都有特定的角色。每一个组件在系统中担当一个角色,但是在不同的用例中扮演不同的角色。组件和用例是通过系统的物理流以及信息的流区分的。组件包括:外部组件(UML参与者)、内部组件、接口组件(见表1)。

表1　UML-ARENA中的组件a素材:向用例提供输入或接收用例输出的组件;a1物理素材:用例的物理输入或输出;a2信息素材:用例的信息输入或输出;b资源:为其它组件提供资源(如车辆)来完成某项活动的组件;c指挥员:在用例中提供管理的组件。

功能模型设计阶段包含4个步骤:(1)物质流确定:通过自顶向下的分析以及功能分解,利用物质流来区分系统特定活动中的输入输出关系。为完成某项活动所需的资源也要在功能模型中指出。(2)协作确定:所有含有两个或多个资源的活动(如用例)必须分解为更详细的子活动,称为协作。(3)决策流确定:协作的指挥员通过决策流分析确定。(4)信息流确定:通过信息流确定完成物质流的分析。指挥员通过信息流控制用例。图2是用于系统分析UML-ARENA概念的示意图。

图2　功能模型设计工具1.2.2　动态模型动态模型利用UML交互图(包括时序图和协作图)通过活动和消息表示用例图中组件间的动态行为。时序图描述了组件间传送消息的时间顺序,表示用例中的行为顺序。时序图将交互关系表示为二维图。纵轴是时间轴,时间沿生命线向下延伸;横轴代表了各个独立的组件。组件间的消息用一个对象的生命线到另一个对象的生命线的箭头表示。协作图描述了组件间的交互以及与组件结构相关的信息。两个图的不同点在于,协作图描述了组件之间的关系,时序图指明了消息传送的时间顺序。交互图能够详细描述系统的动态行为规范。因此,UML-ARENA在本阶段不需要其它的UML视图。交互图由组件(对象)和交互(消息和活动)组成,描述了用例是　第3期方绍强等:基于UML-ARENA的建模与仿真方法研究·693　·　如何通过组件间的交互来实现的。当然为更全面深入地分析系统,还可以选择其它的UML工具,如状态转换图[11-12]。状态转换图描述了组件的状态转换、引起组件状态转换的事件、以及导致状态变化和交互活动的顺序。1.2.3　对象模型对象模型利用类图来描述组件的内部关系和结构,是功能模型和动态模型的扩展。基于规则和通用的类框架,对象模型设计阶段将前面提到的功能和动态规范集成起来,为每个对象指定名字、属性、方法、与其它类的关系(比如依赖、关联和泛化等),以及对象的内部结构,从而得到准确的对象类组。通过从功能模型和动态模型中提取对象的属性和方法,类框架能够定义系统元素以及对象模型之间的联合。对象模型设计阶段需要确定以下3点:一是类,由于还没有标准的划分系统中类的规范,类的划分与开发者关注的细节不同而不同。在UML-ARENA中,类是通过用例图和交互图来确定的。二是类之间的关系,利用恰当的泛化和聚合等关系可以实现类的复用以及应用于新定义的类,从而缩短开发时间。三是类结构,包括类的属性和方法。属性主要来自于用例图,方法主要来自于交互图。可按照以下连续的7个规则建立对象模型,见表2。表2　对象模型转换规则R1　IF组件是内部要素 THEN组件映射为对象类或对象类属性。　R1.1IF组件是指挥员或资源 THEN组件映射为对象类R2IF组件是接口要素 THEN组件映射为对象类方法R3IF是协作用例 R3.1IF协作用例的输入输出均为信息 THEN映射为完成某项功能(如决策)的对象类 R3.2ELSE映射为R1.1中对象类的方法。R4IF组件为输入的素材THEN R4.1IF是物质素材 THEN映射为对象类 R4.2ELSE映射为对象类属性R5IF组件为输出的素材THEN R5.1IF是物质素材 THEN映射为对象类 R5.1ELSE映射为对象类属性R6两个组件间的交互映射为将两个组件联合起来的对象类方法,这个对象类方法接收交互R7其他必须确定的类属性和类方法7个规则集成在一起,构成对象模型设计的总体框架。飞行保障过程中的类包括资源、素材以及指挥员。图3为类与类间的关系。资源是能够完成特定工作(如加油)的系统组件。在框架中,资源能够在三个层面上表现:第一层是资源的状态(如空闲、忙等),第二层指静态资源和动态资源,分别指固定资源(如机器)、非固定资源(如运送素材的车辆)。静态资源特指第三层中提到的场所资源(如存放素材的场所)。例如,可以表示成存放货物的缓冲器或者等待服务的队列。素材表示仿真过程中,完成飞行保障过程的对象类。第二层是将素材划分为物理素材和信息素材两类,第三层是将信息素材按照在仿真中的角色划分为输入信息和输出信息。指挥员类是仿真环境中的活动对象。系统的决策控制由一组指挥员类以及指挥员间的合作表示。