Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
FUTURE COMPUTING ENVIRONMENTS FOR MICROSIMULATION MODELING 215 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 80 See Sadowsky (1977:77â82) for a more detailed discussion of the conditions for such consistency that could be associated with another model, MASH. 81 ADA subprograms are called program units. Each unit consists of two parts, the specification and the body. The specification contains interface information that must be visible to other subprogram units; the body, which contains the implementation details, need not be visible. This structure is a strong one in the ADA language and was explicitly included to ensure that very complex programs, consisting of many program units written independently by different groups of programmers, would function correctly when combined.