SIMSCRIPTⅢ的功能

《风险-收益分析：理性投资的理论与实践（第2卷）》SIMSCRIPTⅢ的功能,页面无弹窗的全文阅读!

SIMSCRIPTⅢ在SIMSCRIPTⅡ.5的基础上增加了一些受欢迎的现代计算机编程功能，例如子系统和多态性。它还增加了继承性，以一种马科维茨发现是令人不安的方式。本节的各子小节讨论SIMSCRIPTⅢ的某些功能是否合意。

多态性、引用变量和强数据类型

直到SIMSCRIPTⅡ.5的所有版本SIMSCRIPT在引用暂时性实体的属性（如一项作业的截止期）时，都是通过如下的表达式：

Due.date（J）

Due.date（JOB）

其中J和JOB是包含作业信息在内存中地址的整数变量。SIMSCRIPT编译器检查J和JOB是不是整数变量，但不检查它们是否指向作业。当J或JOB对作业属性的引用指向内存中某个不相关位置，特别是当数据被写入一个不相关位置时，这可能导致一个很难发现的程序错误。

在SIMSCRIPTⅢ中，J是用户定义的作业引用变量（reference variable）。这被称为强数据类型。与SIMSCRIPTⅡ相同，SIMSCRIPTⅢ自动定义一个名为“JOB”的全局变量，当具有该名称的暂时性实体类型被声明时。与SIMSCRIPTⅡ不同的是，SIMSCRIPTⅢ自动将JOB定义为一个作业引用变量，而非一个整数。

多态性一般是指一个词语的两种或多种使用方式。两种或多种实体类项具有相同名称的属性即是多态性的一个例子。例如，一个模拟程序或DSS可能包含Passenger、Suitcase和Observation等实体类型（最后一个是观察给定航线上之前的航空交通情况）。每一种实体类型可能都有一个名为“Weight”的属性，第一个和第二个Weight属性是物理重量，第三个Weight属性是用于某种加权平均的权重。前两个可能被存储为整数（磅），第三个则被存储为浮点数。这些属性的值能够位于记录（代表各实体类型的个体）中不同位置。当所指的是如Weight（I）中的“Weight”时，如果自变量“I”已被定义为Passenger、Suitcase或一个Observation引用变量，那么就不会引起什么问题，因为编译器将会知道属性的位置和数据类型。

永久性实体的属性被存储为一维数组。例如，如果Machine.Group是一个永久性实体，它拥有一个名为QUEUE的集合，那么在如下语句中：

N.QUEUE（MG）

MG一定是一个在以下范围内的整数

其中N.MACHINE.GROUP是一个变量（当被告知MACHINE.GROUP是一个永久性实体时由SIMSCRIPTⅡ自动定义），它等于当前模拟运行中的机组数量。SIMSCRIPTⅢ并没有考虑到MG被声明为MACHINE.GROUP引用变量的情形，但这一补充是有必要的。这样不仅编译器能够检查一个属性，例如N.QUEUE，事实上是否为MG引用的实体类型的属性，而且正在执行的程序能够检查当一个值被赋予MG时式（7-1）是否满足。

子系统和数据隐藏

SIMSCRIPT（Ⅰ）和Ⅱ的设计者没有想到SIMSCRIPT会被应用于大量的模型。这些模型由不同地方的团队开发，有着数千行的前导码（PREAMBLE，包含模型的全局定义）和数十万行的事件或进程程序及其子程序。对“子系统”的明确需求已有一段时间，最终SIMSCRIPTⅢ引入了子系统。每一个子系统都有自己的公开和非公开前导码。前者声明可用于主系统或其他子系统的全局信息，后者仅为子系统内部的程序所知。SIMSCRIPTⅢ模拟程序总是有一个“主”系统，它能够选择导入一个或多个子系统。

子系统一个有用但不包含在SIMSCRIPTⅢ中的功能，是（选择性地）允许子系统的例子具有自己的将发生事件的日程表。对子系统而言，这些事件中的一些是公开的，另一些则是非公开的。只有最迫近发生的公开事件需要排进主系统的日程表。这一功能可以促进不同子系统更好地运行于不同的（“并行的”）处理器。

继承性

用于状态描述的EAS视图最早出现在马科维茨、豪斯纳和卡尔（Mar-kowitz，Hausner，and Karr，1963）的文章中，而当前流行的面向对象的视图［object-oriented（OO）view］则是基于SIMULA语言，后者最先由达尔和尼加德（Dahl and Nygaard，1966）发布。OO视图可以被描述为增强版的EA视图。特别地，OO“对象”对应于EAS“实体”，OO“性质”对应于EAS“属性”，OO“类”对应于EAS“实体类型”。进一步的细节随着OO实现的不同而不同。特别地，我们将考虑两种这样的实现，即

（1）C++，微软公司的第一种OO语言，也是JLMSim用以编程的语言；

（2）OO视图的SIMSCRIPTⅢ版本。

集合的概念并非OO视图所固有的，不像它是EAS-E视图所固有的那样。微软基础类库（Microsoft’s foundation classes，MFC）为C++程序员使用某些种类的集合提供了帮助。以一种方式存储的接口集（interfacing sets）MFC规则，与那些以另一种方式存储的接口集MFC规则不同。并且，相较于如下的SIMSCRIPT命令

File J in QUEUE（MG）

所有这些MFC接口规则都很烦琐。就像字面意思说的一样，上述命令指示电脑将作业J排进机组MG的队列中。这一命令也用于将作业归到LIFO、FIFO或排序集中，而无论所涉及的实体是“永久性的”、暂时性的，还是数据库实体。改变QUEUE的集合准则，需要在程序前言中变更集合说明，并重新编译程序。

继承性是在OO语言中发挥重要作用的功能。它并非SIMSCRIPTⅡ.5及之前各版本的SIMSCRIPT的正式组成部分，而是在SIMSCRIPTⅢ中才引入的。例如，在SIMSCRIPTⅢ中，现在人们可以声明：

每个人都是哺乳动物。

在这种情况下，所有人都继承了（也即他们具备）哺乳动物的所有属性。由于SIMSCRIPTⅢ是面向EAS的语言，因而人们也继承了哺乳动物作为集合拥有者和集合成员所具有的功能。在这方面，结果就像是将哺乳动物的属性和集合定义复制粘贴到人类的相应定义中一样。

在理想的情况下，SIMSCRIPTⅢ原本应将继承性功能加到SIMSCRIPTⅡ的暂时性和永久性实体上，并利用SIMSCRIPTⅡ的同义词功能使“对象”和“实体”成为同义词。但实际上，SIMSCRIPTⅢ的设计者决定不对既有的暂时性或永久性实体功能进行调整。因此，SIMSCRIPTⅢ中的“对象”具有继承性，而“实体”不具有继承性。

马科维茨不赞同SIMSCRIPTⅢ将世界上的事物分成实体和对象两部分。从SIMSCRIPT（Ⅰ）开始的SIMSCRIPT操作的全部目的，是提供一条从有待模拟的眼中世界到执行程序的无缝路径。当一个人注视着与自己有关的事物时，例如书柜、书架和书，他是无法看出作为实体的事物与作为对象的事物之间的区别的。事物就是事物，仅此而已。

将OO式的编程加入SIMSCRIPT中是商业上的考量，是为了容纳那些习惯于OO视角的新用户或潜在用户。怎样将OO协议与EAS协议无缝融合，并非显而易见，因此为了完成任务，SIMSCRIPTⅢ允许程序员利用来自OO视图或EAS视图的SIMSCRIPTⅡ的许多工具（包括集合在内）。在当时，马科维茨同意这样做，因为SIMSCRIPTⅢ引入了非常理想的功能，如子系统和强数据类型，并且人们总是能够基于EAS视角而非OO视角来编程。这是一个可行的临时性解决方案，但并不理想。