Improving Information for Social Policy Decisions -- The Uses of Microsimulation Modeling: Volume II, Technical Papers (1991)
Chapter: Simulation Module Consistency
strong; they provide promise for both a better conceptual framework for many projects and increases in programming productivity.
In a sense the microanalytic simulation model paradigm has always had an object orientation. The objects in such models can be thought of as individuals, families, and other groups. Input messages to such groups consist of exogenous factors such as the passage of time, inflation rate, administrative regulations, and changes in tax rates. These inputs produce some changes in the state of objects, such as a change in age, total after-tax income and transfer payments received during the time period, and participation rates in various programs. Outputs for static models consist of these changes in states, so that they can be aggregated and distributed for analysis. Changes of state and outputs for dynamic models have a greater range, including the exchange of messages between objects during the simulation to effect income transfers, marriages, and micropopulation entity formation and dissolution.
At this moment the appearance of object-oriented languages does not appear to be more important for constructing microanalytic simulation models than for performing any other computer-related task. Taking into account overall cost, productivity of the environment, and the platform and user interface, if the best programming language for expressing and using such models is object oriented, then it should be used. More important than object-oriented programming per se is the notion of object orientation of the system as a whole, and the construction kit paradigm incorporates this notion directly and explicitly.
Simulation Module Consistency
The approach outlined above for the specification of microanalytic simulation models is not complete. Each of the modules to be combined into an integrated model has built-in assumptions regarding the state of the input variables, and each module makes specific changes in those variables. In order for the modules to be combined into a coherent whole, the assumptions at each intermodule interface must be consistent.80
The modules defined in Figures 3–5 represent the executable code segment of the subprocess to be included in the simulation. Another segment, the identification segment, is required to define the entry and exit interfaces of each module in such a manner that (1) the entire model can be checked and validated for internal semantic consistency and (2) the separate code segments can be checked for syntactic consistency both individually and together. Such techniques are well within the capabilities of software engineering techniques available today. In particular, the first technique is a formal part of the ADA language.81
