第3章系统实体结构基础
在这一章中,将会看到系统实体结构(SES)是如何帮助构建复杂系统模型的。实际上,SES可以让我们更好地了解构建模型的过程。建模仿真(M&S)指的是为不同的目的而开展的一系列活动,例如通过仿真建模可以从可选的方案中选出最合适的; 针对复杂的技术建立仿真器用于训练; 提供对搭建虚拟环境的支持以及提供对复杂系统的测试(正如第1章所讲的)。在学习基于离散事件仿真(DEVS)工具的建模仿真理论(本书的重点)之前,站在一定的高度弄明白建模仿真(M&S)过程中的活动是很有帮助的。
将活动可视化为一个过程或者是完成一项任务的一系列步骤(在某种程度上类似于软件开发过程),虽然有些简单,但的确是一个好的开始。这里讨论的M&S任务是利用仿真模型帮助我们从可选的方案中做出最好的决策。这一过程可以用以下步骤描述。
(1) 明确本次建模仿真任务的目标——用于决策选择的模型开发可能隐含多种不同的目标。
(2) 收集相关数据。
(3) 构建模型。
(4) 运行模型。
(5) 解释仿真结果。
这里需要注意,虽然构建模型和运行模型是这一过程的核心,其他的活动,例如基础工作(步骤1、2)和结果说明(步骤5)也是不能忽略的。作为一个建模仿真开发人员,成功很大程度上依赖于对这些次要活动的理解和与其他人的合作能力。
3.1建模仿真的简单流程
在这种简单的形式中,建模仿真过程可以用“瀑布”的形式来表示,它从开始运行一直到结束而不会中途返回到之前的步骤(如图3.1所示)。
接下来将使用这种建模仿真的活动形式来介绍系统实体结构(SES)和DEVS的建模支撑工具MS4 Me。在后面的第13章,将返回来讨论MS4 Me是如何支持更真实更灵活的建模仿真过程的。
本书将会使用MS4 Me环境中的相关工具,利用系统实体结构(SES)构建图3.1中描述的建模仿真过程。图3.2展示了利用MS4 Me开展图3.1所示建模仿真过程的架构图。可以看出在图3.2中,建模仿真过程被当作是一个实体MSProcessSystem,这个实体被分解成为图3.1中的各个步骤,这些步骤也分别对应于图3.2中具有相关名字的实体。
图3.1“瀑布”形式的建模仿真过程
图3.2建模仿真过程的系统实体结构图
我们将以这种形式分别介绍建模仿真的各种活动和系统实体结构的基本形式。基于上述过程,可以生成一个仿真过程的动画,在这个仿真动画中可以看到,代表仿真对象一系列活动的各个模
依次被激活和这些模块之间的消息流动。
3.2建模仿真过程组件的分解和耦合
SES的两个特性是分解和耦合。分解指的是如何将一个实体分解成为多个实体,这些分解出来的实体在后面可以代表一个模型中的各个组件。耦合指的是组件之间信息如何流动。接下来看看MS4 Me环境是如何帮助我们构建SES的。第一步,指定SES的顶级实体和它的子实体,如下所示:
From the process perspective,MSProcessSystem is made ofUser,ClarifyObjectivesStep,
DataGatherStep,ConstructModelStep,ExecuteModelStep,and InterpretResultsStep!
注意,这些子实体(忽略顺序)在“is made of”短语之后,它们作为组件在一个特殊的分解标签之后,例如“From the…perspective”短语的“process”标签。这句话的常数部分用加粗字体表示,用户消息部分用普通字体表示。“process”标签使我们能够将组件耦合在一起。例如下面这句话:
From the process perspective,User sends InitialObjectives to ClarifyObjectivesStep!
这句话说明了User组件能够发送名为InitialObjectives的消息给ClarifyObjectivesStep组件。一个模型在任何时间是否真正输出InitialObjectives依赖于模型本身。当然,在这种耦合语句中的实体必须在“made of”语句中已经声明。下一语句:
from the process perspective,ClarifyObjectivesStep sends ClearObjectives to DataGatherStep!
该语句说明了ClarifyObjectivesStep组件能够发送名为ClearObjectives的消息给DataGatherStep组件。从这两句耦合语句可以看出ClarifyObjectivesStep获得了一个输入InitialObjectives,处理这个输入的同时产生了ClearObjectives输出。这与这个组件的名字也是一致的。
接下来这些耦合语句的意思是比较明显的:
from the process perspective,DataGatherStep sends ValidData to ConstructModelStep!
from the process perspective,ConstructModelStep sends ValidModel to ExecuteModelStep!
from the process perspective,ExecuteModelStep sends ExperimentSummaries to InterpretResultsStep!
from the process perspective,InterpretResultsStep sends RankedAlternatives to user!
上述语句定义的耦合出现在SES的架构中: 耦合的这种展示方法相对于原始的自然语言文本更容易阅读理解。
下面这句话也是一个耦合语句,但是它把全部的过程关联到了一个组件:
From the process perspective,MSProcessSystem sends StartUp to User!
该语句意思是,包含模型MSProcessSystem(encompassing model)发送一个StartUp消息给User组件。
上述语句的语义在MS4 Me仿真可视化工具中可以清晰地展示(见图3.4)。
练习
回顾上面讨论的语句,核对它们是否符合表3.1中的输入输出。
表3.1组件的输入输出
组件输入输出
UserStartUpInitialObjectives
UserRankedAlternatives no output
ClarifyObjectivesPhaseInitialObjectivesClearObjectives
DataGatherPhaseClearObjectivesValidData
ConstructModelPhaseValidDataValidModel
ExecuteModelPhaseValidModelExperimentSummaries
InterpretResultsPhaseExperimentSummariesRankedAlternatives
如表3.1的输入输出表在由MS4 Me生成SES的仿真动画中发挥着重要的作用。由分析程序可导出各个实体之间的输入输出关系,通过分析参考这些表格的输入输出行为建立各个组件的模型。如果一个模型只有一个输入和输出,那么当这个模型接收到一个输入,它就生成一个输出来响应。如果一个模型有多个输入和输出,那么当这个模型接收到一个输入时将会产生多个输出,除非进行更改,这是因为SES的耦合特性,也可以理解为信息流,但是不能准确地指出哪些会输出。换句话说,只能推断实体模型的可能的输入输出关系(任何特定的输入可以产生任何特定的输出)。这种松耦合的行为不会按照你的意愿配对,所以你需要在模型中消除一些不希望出现的输入输出对。例如,在MSProcessSystem的SES中,User这个模块有两个输入: StartUp和RankedAlternatives,一个输出: InitialObjectives。表3.1列出了User组件在RankedAlternatives输入后没有输出,这是因为我们并不关心User是如何处理输入信号RankedAlternatives(产生输出信号或者返回M&S步骤)的,但是,在这个表中,这两个输入都生成了输出,所以需要移除不需要的输入输出对(RankedAlternatives和InitialObjectives)确保模型按照我们的意愿工作。
总结一下,如果这个模型可以按照实体所在的SES的耦合特性接收输入同时产生输出,那么我们说这个模型和这个实体是相容(Compatible)的。由于SES分析器仅能够分析与实体相关的耦合,因此它仅仅能够解决与这个实体相容的模型选择问题。
练习
针对以下描述提供一个反例,即总是有可能单独从一个SES的分析中推断出开发人员打算替换哪个模型作为实体中的一个组件。提示: 编写一个SES,包含一个实体,这个实体接收到两个不同的输入消息,产生两个不同的输出消息,要求至少有两个和实体的耦合特性相容的模型,但是要有不同的输入输出表。
3.3建模仿真过程的分层结构
接下来我们更加详细地研究建模仿真的全过程,将图3.1和图3.2的步骤按以下规则进行分解。
把“明确目标”分解为明确需求(指明建模应支持的决策功能)、明确值(如何测量模型的输出)和明确加权(如何对这些测量值进行加权)。
把“收集数据”分解为获取正确的数据、核对这些数据是否能代表被建模系统。
把“构建模型”分解为定义一个模型、实现模型、校准模型以及用未使用过的或者新收集的相关数据验证模型。
把“运行模型”分解为生成可选决策、运行仿真实验——用于对模型进行各种可选方案的评估。
把“解读仿真结果”分解为评估可选方案、对方案排序并提供给用户参考。
建模仿真过程更详细的描述可以在SES中表示,所以它不仅仅是一个一级结构,而是一个分层结构。对比图3.3中的扁平模型,一个分模型包含至少一个组件,同时它自己又是由各个子组件构成的。下面我们以数据收集步骤为例来展示SES是如何实现这一点的。考虑DataGather阶段包含两个组件,getData和validateData(注意这里由于转换会导致相同的名字出现,我们使用“阶段(Phase)”代替了“步骤(Step)”来避免两种类型模型——原子模型和耦合模型的冲突),对于MSProcessSystem,我们用以下语句表示它的组成:
From the dataGather perspective,DataGatherPhase is made of getData and validateData!
图3.3建模仿真过程的系统实体耦合结构图
图3.4SES生成的DEVS耦合模型的仿真查看器
这句话的作用是将添加图3.5中DataGatherPhase下面的实体。
图3.5分解DataGatherPhase的SES扩展结构图
考虑下面这些耦合语句(对照图3.5):
From the dataGather perspective,DataGatherPhase sends ClearObjectives to getData!
From the dataGather perspective,validateData sends ValidData to DataGatherPhase!
From the dataGather perspective,getData sends Data to validateData!
前两个语句提到父实体DataGatherPhase,而第三个语句只提到它的子实体。第一句话是“外部输入耦合”的例子,它的意思是DataGatherPhase能够发送一个ClearObjectives信号给它的子组件getData。第二句话是“外部输出耦合”的例子,它的意思是子组件validateData能够向它的父实体DataGatherPhase发送validData信号。第三句话是“内部耦合”的例子,它描述了子实体getData和validateData的耦合关系。
MSProcessSystem的分层耦合模型的可视化形式如图3.6所示,展示了DataGatherPhase的子结构的耦合模型。注意这里的耦合包括DataGatherPhase作为MSProcessSystem子组件的耦合和DataGatherPhase作为getData、validateData父组件的耦合,这就允许发送给DataGatherPhase的ClearObjectives消息向下传递给它的子组件getData,类似地,validateData组件向上发送消息给它的父组件DataGatherPhase。
通过上面的描述,我们得到一个分解特性中重要的耦合原则: 当分解一个实体时,要使外部输入和外部输出的耦合与父实体的内部耦合相一致。
MSProcessSystem的分层模型如图3.7所示。
练习
扩展MSProcessSystem的SES,添加DataGatherPhase以外其他组件分解后的子组件; 将下列字段添加到原始的SES中,修剪并生成仿真查看器和动画; 将生成的各个组件仿真查看器和下面的仿真查看器进行比较; 比较顶层模型的仿真查看器和本节最后给出的模型; 在每个仿真例子中,观察动画产生的消息流,并思考消息的传输是如何由耦合引发的,思考为什么耦合被规定为既定的方式,并且试验其他可选的耦合给消息流带来的影响。
分解ClarifyObjectivesPhase:
From the clarifyObjectives perspective,ClarifyObjectivesPhase is made of clarifyRequirements,clarifyValues,and clarifyWeights!
From the clarifyObjectives perspective,ClarifyObjectivesPhase sends InitialObjectives to clarifyRequirements!
From the clarifyObjectives perspective,ClarifyObjectivesPhase sends InitialObjectives to clarifyValues!
From the clarifyObjectives perspective,ClarifyObjectivesPhase sends InitialObjectives to clarifyWeights!
From the clarifyObjectives perspective,clarifyRequirements sends ClearObjectives to ClarifyObjectivesPhase!
From the clarifyObjectives perspective,clarifyValues sends ClearObjectives to ClarifyObjectivesPhase!
From the clarifyObjectives perspective,clarifyWeights sends ClearObjectives to ClarifyObjectivesPhase!
这可以产生图3.8的分解图。
图3.8ClarifyObjectivesPhase的分解图
分解ConstructModelPhase:
From the constructModel perspective,ConstructModelPhase is made of defineModel,implementModel,calibrateModel,and validateModel!
From the constructModel perspective,ConstructModelPhase sends ValidData to defineModel!
From the constructModel perspective,defineModel sends ModelDefinition to implementModel!
From the constructModel perspective,implementModel sends ImplementedModel to calibrateModel!
From the constructModel perspective,calibrateModel sends CalibratedModel to validateModel!
From the constructModel perspective,validateModel sends ValidModel to ConstructModelPhase!
这可以产生图3.9的分解图。
图3.9ContructModePhase的分解图
分解ExecuteModelPhase:
From the executeModel perspective,ExecuteModelPhase is made of generateAlternatives and runExperiments!
From the executeModel perspective,ExecuteModelPhase sends ValidModel to generateAlternatives!
From the executeModel perspective,generateAlternatives sends Alternatives to runExperiments!
From the executeModel perspective,runExperiments sends ExperimentSummaries to ExecuteModelPhase!
这可以产生图3.10的分解图。
图3.10ExecuteModelPhase的分解图
分解InterpretResultPhase:
From the interpretResults perspective,InterpretResultsPhase is made of evaluateAlternatives and rankAlternatives!
From the interpretResults perspective,InterpretResultsPhase sends ExperimentSummaries to evaluateAlternatives!
From the interpretResults perspective,evaluateAlternatives sends EvaluatedAlternatives to rankAlternatives!
From the interpretResults perspective,rankAlternatives sends rankedAlternatives to InterpretResultsPhase!