Search

Programming systems such as DRAFT1 and ECSL2generate a discrete-event simulation program from the user's response to a man-computer dialogue or questionnaire about a life-cycle diagram. This paper examines the function of a program generator in the light of in formation with which it must be supplied. This in formation is classified into information which is fundamental to the structure of the model and that which is dependent on a particular simulation program ming language or the details of a particular program run. The language-independent information is summar ised in an activity-based descriptive unit. An inter active program generating system10 is described in which a file of descriptive units forms a link between two on-line questionnaires. The first asks the user to define the underlying structure of his model, while the second asks for information which is pecu liar to the simulation programming language in which a program is to be generated and for information about a particular run.The system differs from others in offering the user a choice between three questionnaires, each of which incorporates the terminology of a different model ling scheme. They enable the user to define his model in terms of (a) event routines appropriate to a two-phase event-oriented simulation programming language such as SIMSCRIPT,5(b) bound and conditional events as for a three-phase language like SIMON,6and (c) life-cycle diagrams.4The system can easily be extended to generate programs in any simulation pro gramming language for which a compiler becomes available. [ABSTRACT FROM PUBLISHER]

In this paper a review of the approaches to modelling adopted by programming languages currently available for discrete-system simulation leads to a close look at some of the advantages of languages which employ an "activity scan." These advantages include faster run-times for highly interrelated systems, simpler event routines, and increased security for the model. Decision tables provide a clear and concise format for specifying a complex set of conditions and the various consequent courses of action. They are therefore ideal for describing the conditions for interaction between component parts of a model as specified in the user-defined event routines. A preprocessor to make decision tables computer- readable would greatly enhance the process of modeZ ling and would allow a considerable extension of the range of conditioned statements to be used in the condition stubs of the table. A decision-table facility would form a useful extension to the many event-oriented simulation programming languages. [ABSTRACT FROM PUBLISHER]