Once sufficient information has been compiled to define the basic system operation, the model building activity can begin. While starting to build a model too early can be a wasted exercise, waiting until all of the information is completely gathered and validated may unnecessarily postpone the building of the model. Getting the model started before the data is completely gathered may even help identify missing information needed to proceed.
The goal of model building is to provide a valid representation of the defined system operation. Additionally, the model must be able to provide any other statistical or graphical representation needed to satisfy the objectives of the study. A model is neither true nor false, but rather useful or not useful. Once validated, a model is useful when it provides the needed information to meet the objectives of the simulation.
One nice feature of simulation is that models do not have to include all of the final detail before they will run. This allows a progressive refinement strategy to be used in which detail is added to the model in stages rather than all at once. Not only do models get built and running quicker this way, but it also makes models easier to debug. In the initial stages of a model, for example, attractive graphics are not very useful and, since they are likely to be changed anyway, should not be added until later when preparing for the final model presentation.
The complexity of model building should never be underestimated and it is always better to begin simple and add complexity rather than create an entire complex model at once. It is also easier to add detail to a model than it is to remove it from a model. Building a model in stages enables bugs to be more readily identified and corrected. Emphasizing the importance of applying progressive refinement to model building, Law and Kelton (1991) have advised:
Although there are few firm rules on how one should go about the modeling process, one point on which most authors agree is that it is always a good idea to start with a simple model which can later be made more sophisticated if necessary. A model should contain only enough detail to capture the essence of the system for the purposes for which the model is intended: it is not necessary to have a one-to-one correspondence between elements of the model and elements of the system. A model with excessive detail may be too expensive to program and to execute.
In addition to adding complexity to a model in stages, models that have a broad scope are sometimes easier to build in phases where additional sections are added incrementally to the model. This method of "eating the elephant one bite at a time" allows a portion of the model to be built, tested and debugged before adding new sections and makes a large task more manageable.
For unusually large models, it may be useful to identify definable boundaries within a model to permit model partitioning. Model partitioning is the process of subdividing a model into two or more modules that represent physically separate sections within the system. The purpose of model partitioning is to allow model sections to be built and debugged, possibly even by separate individuals, independently of each other. Once sections are finished, they can be merged together to create the overall model. This “divide-and-conquer” method of model building can greatly reduce the time and difficulty in building and debugging large models.
Once a model is defined using a selected software tool, the model must generally be debugged to ensure that it works correctly. The process of demonstrating that a model works as intended is referred to in simulation literature as model verification. It is much easier to debug a model built in stages and with minimal detail than to debug a large and complex model. Eliminating bugs in a program model can take a considerable amount of time, especially if a general purpose programming language (e.g., C++) in which frequent coding errors occur is used. Most simulation languages provide a trace capability in the form of audit trails, screen messages, graphic animation, or a combination of all three. A trace enables the user to look inside of the simulation to see if the simulation is performing the way it should. Good simulation products provide interactive debugging capability which further facilitates the debugging process. A thorough “walk-through” of the model input is always advisable.
During the process of model building, the modeler must be constantly concerned with how closely the model reflects the system definition. The process of determining the degree to which the model corresponds to the real system, or at least accurately represents the model specification document, is referred to as model validation. Proving absolute validity is a non attainable goal. As Neelamkavil (1987) explains, “True validation is a philosophical impossibility and all we can do is either invalidate or fail to invalidate.” For this reason, what we actually seek to establish is a high degree of face validity. Face validity means that, from all outward indications, the model appears to be an accurate representation of the system. From this standpoint, validating a model is the process of substantiating that the model, within its domain of applicability, is sufficiently accurate for the intended application (Schlesinger, 1979).
There is no simple test to establish the validity of a model. Validation is an inductive process through which the modeler draws conclusions about the accuracy of the model based on the evidence available. Gathering evidence to determine model validity is largely accomplished by examining the model structure (i.e., the algorithms and relationships) to see how closely it corresponds to the actual system definition. For models having complex control logic, graphic animation can be used effectively as a validation tool. Finally, the output results should be analyzed to see if the results appear reasonable. If circumstances permit, the model may even be compared to that actual system to see how they correspond. If these procedures are performed without encountering a discrepancy between the real system and the model, the model is said to have face validity.
|
|
© 2012 ProModel Corporation • 556 East Technology Avenue • Orem, UT 84097 • Support: 888-776-6633 • www.promodel.com |