1. Introduction

It is perhaps true that the phrase 'a well thought out plan is half the battle' also applies to computer simulation projects. In simulation modelling, we select a certain portion of the real-world system to be simulated for specific objectives. The process of capturing the essential elements of the system is referred to as conceptual modelling and the resulting model is referred to as a simulation conceptual model (Pidd, 2004). In a typical simulation modelling process, the conceptual modelling stage is followed by computer implementation, validation, experimentation, and implementation on a real system (Pidd, 2004).

The fact that conceptual modelling precedes most activities in a simulation modelling process shows the significance of a simulation conceptual model (or conceptual model for brevity). It shows that the conceptual model affects the subsequent stages in a simulation modelling process. People may argue that advances in computer simulation software, especially with the introduction of Visual Interactive Modelling System (VIMS), allow simulation modellers to build simulation models directly without any need to produce a conceptual model. Robinson (2006) disagreed and argued that VIMS enabled more rapid model development, but it neither reduced nor removed the importance of model design. Despite its significant role, there is a paucity of research into conceptual modelling. The Journal of Simulation, however, recently released a special issue on conceptual modelling for simulation to raise awareness and interest in conceptual modelling. Robinson (2006) listed a number of possible areas for research in conceptual modelling. One of them is conceptual model representation.

Since there is no single accepted definition of what a conceptual model is, it is not surprising to see that various representations have been proposed. However, most conceptual model definitions agree that a conceptual model comprises a number of components. Hence, it is unlikely that a single diagram can be used to represent completely a conceptual model. This paper proposes a multi-faceted conceptual model representation that uses a set of graphical and textual notations to specify all components in a conceptual model. At this initial stage, we do not aim to set a definitive standard for conceptual model representation. Instead, we hope that this paper will initiate discussion on unified conceptual model representation and lead to the development of a standard conceptual model representation. Standardization is essential for communicating conceptual models effectively.

In this paper, we use examples taken from a project called the District General Hospital Performance Simulation (DGHPSim) to demonstrate how the proposed unified conceptual model representation is used in practice. DGHPSim is a collaborative research project that involves three British universities. The project aims to develop generic simulation models of entire acute hospitals so as to understand how hospital performance can be improved (Gunal and Pidd, 2006).

The rest of this paper is organized as follows: Section 2 outlines the related works; Section 3 discusses the proposed unified conceptual model representation; finally, we present our conclusions and future work plans in Section 4.

2. Related works

Conceptual model representation is important in a simulation project because it is used as a tool for communicating about conceptual models between stakeholders (simulation modellers, clients, and domain experts). There is a point in the simulation project when the conceptual modelling process happens inside the individual stakeholder's mind. This 'thinking' process includes reflection on how to structure the problem and how the simulation model should be designed to help decision makers solve the problem at hand subject to certain constraints. Wang and Brooks (2007) conducted empirical investigations on conceptual modelling processes and, in particular, highlighted the difference between expert and novice modellers. However, in general, empirical research to understand this 'thinking' process is scant. At some stage in the simulation project, the conceptual model needs to be communicated to other stakeholders (see Figure 1). Hence, the role of conceptual model representation is crucial. Moreover, different stakeholders may have different views on the system for reasons such as different levels of understanding of the system, prior experience, and personal objectives. Nance (1994) referred to the conceptual model representation for this purpose as the communicative model. When communication involves different types of stakeholders, a standard representation that can be understood by all stakeholders is essential. The fact that communication between stakeholders is important for the success of a simulation project (Robinson and Pidd, 1998) makes the need for a good conceptual model representation become even more essential.

Figure 1.

Communication in a simulation project.

Full figure and legend (46K)

The main challenge in designing a conceptual model representation is to devise a representation that can be understood by all stakeholders and yet which should be expressive enough to handle the varying levels of complexity in the conceptual model. To complicate matters further, there is no single accepted definition of what a conceptual model is. What is to be represented will affect its representation. In this paper, we highlight three definitions.

Banks et al (2005) define a conceptual model as a collection of assumptions about simulation elements, the structure of the system, and hypotheses about the values of model input parameters. A conceptual model according to Pace (2000) includes more than just the assumption, model structure, and model input. It is a collection of information that describes a simulation developer's concept about the simulation and its components. In this definition, a conceptual model comprises components that can be categorized into two groups: simulation context and simulation concept. The simulation context provides information about the problem domain (such as: assumptions, algorithms, characteristics, relationships, and data) and constraints the simulation concept components. The simulation concept specifies the simulation developer's concept for the entire simulation applications, such as: simulation elements (entities, tasks, actions, etc) and their interaction.

Robinson (2008a, 2008b) provides a definition that emphasizes the independence of a conceptual model from its software implementation. He defines it as a software-independent description of the simulation model to be developed. In this definition, a conceptual model consists of components that can be grouped into problem domain and model domain. The problem domain is closely related to the problem structuring activity. It includes the specification of objectives, outputs, inputs, model content, assumptions and simplifications. These components are independent of any simulation modelling paradigm (such as discrete-event, system dynamics, and agent-based). At this stage, if it has been decided that simulation is appropriate for a given objective, an appropriate simulation modelling paradigm should be chosen. The chosen simulation modelling paradigm affects the specification in the model domain. For example, if discrete-event simulation is chosen, then in the model domain, we need to specify components such as: events and system state. Interested readers can find a good discourse on different definitions of conceptual models in Robinson (2008a, 2008b).

Given the different definitions for a conceptual model, it is not surprising to see that a wide variety of conceptual model representations have been proposed. One of the surveys conducted by Wang and Brooks (2007) listed the popularity of a number of conceptual model representations. They are, in order of popularity, textual representations (list of assumptions and simplifications, component list, and text description), process flow diagram, logic diagram, activity cycle diagram, and UML.

The survey shows that many respondents document the assumptions, simplifications, and components of their simulation models. It also implies that simulation modellers often use textual representations. The most popular graphical representation in the survey is the process flow diagram (Robinson, 2004). This diagram provides symbols to represent processes, flows, and queues to give a visual representation of the process flow in a simulation model. Hence, it is suitable for representing the structure of simulation models. The logic diagram is a flow chart showing the logic of a model. It is commonly used to describe the algorithms used in a simulation model. An activity cycle diagram (Hills, 1971) is commonly used to represent a process-oriented worldview in discrete-event simulation. A process-oriented worldview, such as three-phase and process-interaction, specifies a simulation model using a set of processes. When an entity arrives at the system, it must go through a set of processes that may change the state of the entity (eg, in service or waiting) until the entity leaves the system. Another widely used worldview in discrete-event simulation is event-oriented worldview. This worldview specifies a simulation model as a set of events and states. When an event occurs, it may schedule a set of other events and it may also change the state of the system. An event graph (Schruben, 1983) can be used to represent this world-view.

There are other representations that are not mentioned in the survey. Van Der Zee (2006) used Booch's object model to represent the structure of manufacturing simulation models. Recently, Ryan and Heavey (2006) proposed the simulation activity diagram to represent the structure of discrete-event simulation models in general. The authors showed that their diagram could model complex process interactions and capture both physical and information flows in a real system.

Despite the differences in definitions of a conceptual model, researchers agree that a conceptual model comprises a number of components. The conceptual model representations discussed earlier have focused specifically on one or two components of a conceptual model. Some of them are used to represent model-dependent components; hence they are suitable only for a specific modelling paradigm such as discrete-event simulation or system dynamics.

One of the main motivations of this paper is to promote the use of multi-faceted conceptual model representation. A set of diagrams is used to represent conceptual model components. Multi-faceted representation has been used widely in software engineering. One of the most widely used multi-faceted representations in software engineering is UML. UML 2.0 defines 13 types of diagrams to represent three aspects of software system: static application structure, behaviour, and interactions (http://www.uml.org). Not surprisingly, Richter and Marz (2000) proposed the use of UML for documenting a simulation project (which includes the conceptual modelling process). Interaction between users and the simulation can be represented using a use case diagram. The structure of a model is represented using a class diagram. The dynamics of the model is represented using an interaction diagram and a state diagram. A multi-faceted representation such as UML can provide a more comprehensive representation. The author argues that this is the way forward for research into conceptual model representation.

Another motivation for this paper is to initiate discussion on the development of a standard conceptual model representation. Pooley (1991) noticed that when graphical workstations became more affordable, the use of diagrams in simulation modelling increased. He then argued that a standard representation was important to avoid unnecessary divergence between those diagrams. Further, he added that a standard model representation should be independent of any software implementation and proposed an extended version of an activity diagram. Pooley's work focuses only on one aspect of simulation conceptual model (ie the structure of a simulation model) and process-oriented worldview in discrete-event simulation.

3. Unified conceptual model representation

Before proposing a standard multi-faceted conceptual model representation, we need to specify what a conceptual model and its components are. This paper uses Robinson's conceptual model definition: 'a conceptual model is a non-software specific description of the simulation model that is to be developed' (Robinson, 2008a, 2008b). It comprises problem-domain components and model-domain components. The problem-domain components are used as a means of communication mainly between clients/domain experts and a simulation modeller, between clients, or between domain experts (see Figure 1). These components include objectives, inputs, outputs and model contents (scope, level of detail, assumptions and simplifications). The model-domain components are mainly used as a means of communication between simulation modellers. These components are model dependent; for example, events and system state in discrete-event simulation, stocks and flows in system dynamics, or agents and environment in agent-based simulation.

Table 1 shows our initial proposal for a unified conceptual model representation. The first column gives the categories of a conceptual model's components. The second column lists the components of a conceptual model. To initiate prompt discussion on a standard multi-faceted conceptual model representation, we choose a number of widely known diagrams (although some are used in areas other than simulation). The last column gives the diagrams selected to represent the conceptual model's components. We evaluate each diagram based on the expressiveness (ability to model complex systems), simplicity (easy of understanding), scalability (ability to cope with complexity), and ability to conduct a plausibility check. At this stage, our objective is not to demonstrate that these diagrams are the best but to demonstrate that they are good enough for the unified conceptual model representation based on the four criteria.

Table 1 - Diagrams in the unified conceptual model.

Full table

4. Objectives component

The objective is the most important component in any modelling process, including simulation. Simulation is commonly used in the larger context of a problem-solving exercise. In this context, objectives are used to judge the success of the exercise and to compare the quality of various decision alternatives. Therefore, the first component in a conceptual model is rightfully given to the objectives of the study. In this section, we will discuss two diagrams that can be used to represent the objectives component.

The first diagram, objective diagram (Keeney, 1992), is commonly used to structure objectives in decision science. It classifies objectives into fundamental objectives and means objectives. The fundamental objectives are the end result that we want to achieve and they are organized into hierarchies. In an objective diagram, each fundamental objective is represented as a node in a tree. The higher-level fundamental objectives represent the more general objectives and their measurement can be obtained from the lower-level fundamental objectives. Thus, the lowest-level fundamental objectives provide the basis on which various design alternatives are measured. Consequently, the highest-level fundamental objective provides the ultimate measurable consequence that will be used to evaluate and compare various design alternatives. Figure 2 shows an example of fundamental objectives from our case study. The ultimate objective is to improve overall hospital performance. Let us assume that the performance refers to waiting times of patients at the hospital, which is the average of waiting times of patients in its various departments: Accident & Emergency (A&E), outpatient and in-patient. This measurement will be used to compare alternatives. The second-level fundamental objectives can be further expanded if necessary. For example, the A&E performance is obtained from two components: patient total time (98% of patients must not spend more than 4 h in A&E) and staff utilization.

Figure 2.

A&E—objective diagram.

Full figure and legend (12K)

Means objectives are important because they help us to achieve fundamental objectives and they are often used when the fundamental objectives are difficult to measure directly. In some cases, identifying means objectives can help us to characterize new alternatives. In the objective diagram, means objectives are organized into networks. Two examples of means objectives are shown in Figure 2. Maximizing the number of day cases and reducing patient lengths of stay are important because they increase the number of available beds. Hence, it may reduce the waiting times for both emergency and elective admissions. The fundamental objectives can be differentiated from means objectives by continuously asking the question why an objective is important. The objective is a means objective if it is important because it helps achieve another objective. The same question is repeated until we find an answer where an objective is important because it is important. Detailed explanation on the objective diagram can be found in Clemen and Reilly (2005).

The objective diagram is chosen for a number of reasons. First, it has been used in decision science for more than a decade. It is expressive enough to represent the hierarchical structure of fundamental objectives and the network structure of means objectives. Second, it is simple and can be understood without significant training effort. Note that the target audience includes clients who may not have any training in quantitative skills. Third, the tree structure of the fundamental objectives makes it scalable. Special care must be taken when the number of means objectives is large (because they may form a complex network structure). Finally, it is possible to carry out a plausibility check on the diagram (eg a fundamental objective will never be put below a means objective).

The objective diagram, however, only considers the structure of the objectives. It may be useful to show the conditions under which the structure is made. Kotiadis (2007) presented an interesting work on using Soft Systems Methodology to determine simulation objectives. In particular, she presented steps to extract simulation objectives from the purposeful activity model (PAM). This work implies that PAM can be used to complement the objective diagram to show the condition under which the objective diagram is made. PAM has been used in conjunction with the well-known Soft Systems Methodology. PAM is simple and commonly used in the communication between modellers and their clients. Its modular structure implies that PAM is relatively scalable. A plausibility check can also be carried out, for example, if one factor is not connected to others then it can be removed from the diagram.

5. Inputs and outputs component

Once the objectives have been defined, we need to translate them into output variables that can be quantified, and to identify the different alternatives (input variables) to achieve the objectives. The controllable input variables are sometimes referred to as the decision variables. The inputs, outputs, and contents (the subject of the next section) represent the top-level conceptual model where inputs are transformed into outputs, as shown in Figure 3. The outputs can be directly inferred from the objectives. The inputs are sometimes specified explicitly in the objectives; otherwise, they can be obtained from the clients.

Figure 3.

Top-level conceptual model.

Full figure and legend (4K)

The influence diagram (Howard and Matheson, 1984) is commonly used to structure decisions by representing the relationship between key variables. An influence diagram consists of certain elements as follows. Decision variables represent the decisions to be made (symbolized as rectangles in the diagram). Uncontrollable variables represent uncertainty or chance events (ovals). Outputs represent final consequences or payoffs (diamonds). Intermediary variables including calculation nodes and constants are used to compute the outputs (rounded rectangles). Relationships between nodes are represented using arcs. All arcs pointing to a rectangle (decision variable) show sequences. It means that the node at the beginning of the arc must be known before the decision can be made. All arcs pointing to ovals, diamonds or rounded rectangles (non-decision variables) show the relevance relations. The node at the beginning of the arc is relevant for the node at the end of the arc.

Figure 4 shows the representation of inputs and outputs component from the A&E department in our case study using an influence diagram. The output of the A&E simulation model is the A&E performance. The A&E performance is calculated from two intermediary variables, namely, the total number of patients who spend 4 h or less in the A&E department and staff utilization. The decision variables are the numbers of doctors, nurses, and clerks. The uncontrollable variables (shown as ovals) are the arrival rate and severity of condition of the patients. The objectives hierarchy is reflected in the sequence of output and intermediary variables in the influence diagram. From Figure 4 we know that the top-level objective is to maximize the performance of the A&E department. This is followed by the second-level objectives, that is, patient total time and staff utilization.

Figure 4.

A&E—influence diagram.

Full figure and legend (13K)

The influence diagram is very expressive because it can model three main variables in system modelling: outputs (objectives), inputs (decision variables), and chance/stochastic variables. It is relatively simple. The sequence and relevance relationships shown in the diagram are intuitive. An influence diagram exhibits the same level of scalability as the objective diagram. This is because the output variables in an influence diagram must be consistent with the tree structure of the given fundamental objectives. Similar to the objective diagram, when the number of variables (other than the output variables) is large, they may form a complex network structure and make it less scalable. Some plausibility checks can be carried out, for example, an intermediary variable must be influenced by at least one variable.

A decision tree (Holloway, 1979) can be used as an alternative to represent inputs and outputs in a conceptual model. It shows more information than an influence diagram, for example, the probability of a condition (chance event). In our opinion, this diagram is less suitable for inputs and outputs representation for two reasons. Firstly, as the level of detail is increased, the inputs and outputs become more complicated and the decision tree tends to become muddled much faster than the influence diagram. Secondly and most importantly, an influence diagram is easier to understand for people without mathematical training. Having said that, influence diagrams and decision trees are isomorphic, hence they can be converted to each other.

6. Contents component

Once the inputs and outputs have been specified, the next step is to specify the transformation processes or the contents. The contents component of a conceptual model describes the scope of the model, the level of detail, assumptions, and simplifications. The scope of the model specifies all relevant processes and their interactions within the boundary of the model. The level of detail specifies the required degree of detail for each process in the model and the required input data. Both scope and level of detail are determined based on the modelling objectives. Assumptions are necessary to address the uncertainty or unknown factors that may be important to the processes in the model. Simplifications are needed to handle the complexity of processes and other important elements (such as resources) in the model. Hence, the contents component needs to specify four elements. One of the possible diagrams that can be used to represent the contents component is the business process diagram (BPD).

BPD is the diagram that is specified by Business Process Modelling Notation (BPMN). BPMN is a standard that has been developed to provide a notation that is understandable by all business stakeholders (business people, business analysts, and technical developers) to model business processes. Figure 5 shows four of the BPD's elements: activities, events, gateways, and connectors. BPD's activities are used to model processes in the real world. These processes can be further decomposed into sub-processes that are important in representing level of detail. The lowest-level process is called a task. BPD's events are used to model events that happen in the real world. An event can start the processes, be intermediary, or end the processes. BPD's connector is used to represent a sequence of processes. BPD's gateways are used to represent decisions in the process flow, that is, joins, forks, and mergers. BPMN (http://www.bpmn.org/) provides a more detailed explanation on each element and other elements that are not mentioned here, such as pool and lane.

Figure 5.

BPD's main elements.

Full figure and legend (4K)

The scope of a conceptual model can easily be represented by specifying the relevant processes, events that start these processes and the process flows (including decisions or branching of flows). Figure 6 shows the scope of a hospital simulation model in which only three processes (A&E, outpatient, and in-patient) are modelled. Patients arrive in the system through A&E and outpatient. Depending on the condition, a patient can be admitted to hospital (in-patient) or discharged. The figure shows that the general practitioner is outside the scope of this model.

Figure 6.

Hospital—business process diagram.

Full figure and legend (13K)

Figure 6 also shows the level of detail of the processes. It considers A&E, outpatient, and in-patient as three black boxes. As a process in the diagram can contain sub-processes (which can be shown by another BPD), it is possible to show a more detailed model for each process in Figure 6. The appropriate level of detail must be consistent with the influence diagram. For example, the decision variables in the influence diagram (Figure 4) shows that the simulation model will be used to analyse the effect of changes in the number of different medical staff on A&E performance. This experiment cannot be done if the A&E department is represented as a black box. Instead, we need to increase the level of detail of the A&E model as shown in Figure 7. The figure shows that the process in the A&E department starts with patient arrivals. There are two types of patient arrival: voluntary and by ambulance. A patient who arrives voluntarily at the A&E department will need to register before being evaluated by a nurse (triage) to determine the severity of the patient's condition. One who arrives by ambulance, however, may bypass the registration process (the triage is done on the way to the A&E department). Next, the patient will be seen and treated by a doctor and/or nurse (either in the resuscitation room or cubicle). After treatment, patients will either be discharged or admitted to the hospital. Some patients may need some tests and X-rays and these patients then need a second session with a doctor and/or nurse before discharge or admission.

Figure 7.

A&E—business process diagram.

Full figure and legend (21K)

BPMN provides three artefacts that can be used to provide additional information about a process that is not directly related to the structure of the process flow. One of them is text annotation that is suitable for representing assumptions and simplifications used in the conceptual model. For example, in Figure 7, we can attach a text annotation to the process 'triage' that provides a list of assumptions such as 'the severity of condition of patients is modelled as a simple top hat sampling'. Similarly, we can attach a text annotation to process 'test' that provides a list of simplifications such as 'the service time for tests does not differentiate between the types of test (X-Ray, blood test, etc)'.

We chose the BPD for a number of reasons. First, despite its simplicity, BPD has the ability to model complex business processes. Second, its process-centric approach is intuitive and easy to understand especially to business analysts and business users. Third, it is scalable by supporting hierarchical decomposition of the processes. The hierarchical process decomposition is also useful to show the level of detail used in the model. Fourth, it is possible to carry out a plausibility check on the diagram. For example, all processes must be reachable from the start event. Finally, it is designed with web services in mind, which make it very useful for supporting component-based simulation, web-based simulation, and any distributed simulation environment.

7. Model-dependent component

The literature shows that two simulation modelling paradigms dominate the healthcare modelling, namely, discrete-event simulation and system dynamics. Therefore, in this section, we only discuss representations used in discrete-event simulation and system dynamics. We choose diagrams that have been widely known such as stock and flow diagram in system dynamics and activity cycle diagram in discrete-event simulation. The quality of these diagrams can be implied from their usage in simulation courses worldwide as well as in practice for many years.

The representation of components in system dynamics has been influenced by the notation given by Forrester (1961). Nowadays, stock and flow diagram and causal loop diagram (both are independent of software implementation) are widely accepted as standards in representing system dynamics models (Sterman, 2004). This explains why many system dynamics VIMS use similar diagrams to represent the system dynamics models. For example, Figure 8 shows the diagram of the outpatient simulation drawn using Vensim™ (http://www.vensim.com), which has a slightly different notation from the Forrester version. The rectangles represent the states of the system (ie, population size), the valves represent the flow rate and the double line arrows show the direction of flow. The single line arrow shows that the node at the start of the arrow affects the node at the end of the arrow. VIMS translates the diagram into a computer program and executes it. The translation and execution process is transparent to the modellers although some VIMS allow users to choose the numerical algorithms used in the simulation.

Figure 8.

A&E—activity cycle diagram.
Resources: (C)lerk, (D)octor, (L)ab staff, and (N)urse

Full figure and legend (26K)

The story is different in discrete-event simulation. A number of implementation-independent diagrams have been proposed to model discrete-event simulation models such as ACD (commonly used in the process-oriented worldview) and event graph (commonly used in the event-oriented worldview). These diagrams do not have the same level of influence as Forrester's diagrams in system dynamics. Many discrete-event VIMS use proprietary notations to represent discrete-event simulation models. Interestingly, some researchers have developed VIMS that uses implementation-independent diagrams such as: ACD and event graph (Araujo and Hirata, 2004; Pidd and Carvalho, 2006).

The choice between the different simulation modelling paradigms depends on the objective of the simulation project. System dynamics is suitable when the population of entities and the rates of entities moving from one place to another are more important than the individual entities. Discrete-event simulation is suitable when it is necessary to track entities from their arrival in the system until they leave the system (or until the simulation is completed). The results from individual entities are aggregated in the simulation outputs.

The healthcare system dynamics models reported in the literature, such as Brailsford et al (2004), mostly include the social factors in the community served by the healthcare system. The reported objectives are aimed mainly at studying the effect of different policies or external factors on the capacity of healthcare system providers. In our case study, the objective for the A&E department is to study the departmental performance given a limited number of resources. Specifically, the performance is measured based on the percentage of patients leaving the department within 4 h or less. In this case, discrete-event simulation is more suitable because we need to track each patient and resource in the system. The ACD of the A&E simulation model is shown in Figure 9. In ACD, an oval corresponds to a dead state that represents conditional waiting (until the required resources are available). A rectangle corresponds to an active state that represents a process with a specific duration (it may be sampled using a predefined distribution function). Each process in the BPD (Figure 7) is mapped onto an active state in the ACD. The diagram shows the main cycle, that is , patient cycle. The cycle for each resource, such as a doctor, is not shown in order to avoid cluttering the figure unnecessarily. Note that the use of ACD indicates that the model uses the process-oriented worldview. If the event-oriented worldview is chosen, we may use an event graph that is equivalent to the ACD shown in Figure 9.

Figure 9.

Outpatient—stock and flow diagram.

Full figure and legend (30K)

8. Summary

The main contribution of this paper is to propose a unified conceptual model representation. We have shown how conceptual model components can be represented using various diagrams. The proposed diagrams are chosen based on their expressiveness, simplicity, scalability, and support for plausibility check as summarized in Table 2. At this stage, we cannot give diagrams that work best in representing the conceptual model components. Instead, we hope this paper may initiate discussion that will eventually lead to a standard unified conceptual model representation.

Table 2 - Evaluation of unified conceptual model diagrams.

Full table

Apart from the individual strengths, the diagrams are chosen because they complement each other well in a multi-faceted representation as shown in Figure 10. The objective diagram can be used to validate the output and intermediary variables given in the influence diagram. The input and chance variables in the influence diagram can be associated with elements in the BPD. For example, clerks are required at the registration process. Although it is not shown in the figure, the BPD can be used to validate the diagram representing the model-dependent components. For example, each process in the BPD should be mapped onto an active state in the activity cycle diagram. Due to limitations on space, we do not draw all text annotations in the BPD, but we give one example of text annotation for process 'test'. For the same reason, we do not separate the chance variables into different ovals in the influence diagram. This figure shows that on top of the plausibility check at the component level, a plausibility check at conceptual model level is also possible.

Figure 10.

Unified conceptual model representation—plausibility check.

Full figure and legend (97K)

A few points need further analysis. Firstly, we need to evaluate critically a number of possible representations for each conceptual model component so as to develop a standard multi-faceted representation of a conceptual model. Secondly, in the representation of model-dependent components, we need to address other popular simulation modelling paradigms, such as agent-based simulation. Finally, a standard conceptual model representation can be used in the design of a simulation model repository system. In relation to this, we need to explore the use of mark-up languages such as XML to exploit the full potential of conceptual model documentation. This could complement research into simulation model reusability, composability, and interoperability.

References

1. Araujo WLF and Hirata CM (2004). Translating activity cycle diagrams to java simulation programs. In: Proceedings of the 37th Annual Simulation Symposium. IEEE: Piscataway, NJ, pp 157–164.
2. Banks J, Carson JS, Nelson BL and Nicol DM (2005). Discrete-Event System Simulation, 4th edn. Pearson Education: Upper Saddle River, NJ.
3. Brailsford SC, Lattimer VA, Tarnaras P and Turnbull JC (2004). Emergency and on-demand health care: Modelling a large complex system. J Opl Res Soc 55: 34–42. | Article |
4. Clemen RT and Reilly T (2005). Making Hard Decisions with DecisionTools®, 2nd edn. Duxbury, Thomson Learning: Belmont, CA.
5. Forrester J (1961). Industrial Dynamics. MIT Press: Cambridge, MA.
6. Gunal MM and Pidd M (2006). Understanding accident and emergency department performance using simulation. In: Perrone LF, Wieland FP, Liu J, Lawson BG, Nicol DM and Fujimoto RM (eds). Proceedings of the 2006 Winter Simulation Conference. IEEE Computer Society Press: Piscataway, NJ, pp 446–452.
7. Hills PR (1971). HOCUS. P-E Group: Egham, Surrey, UK.
8. Holloway CA (1979). Decision Making under Uncertainty: Models and Choices. Prentice-Hall: Englewood Cliffs, NJ.
9. Howard RA and Matheson JE (1984). Influence diagram. In: Howard RA and Matheson JE (eds). The Principles and Applications of Decision Analysis Vol. II. Strategic Decisions Group: Palo Alto, CA, pp 719–762.
10. Keeney RL (1992). Value-Focused Thinking. Harvard University Press: Cambridge, MA.
11. Kotiadis K (2007). Using soft systems methodology to determine the simulation study objectives. J Simul 1(3): 215–222. | Article |
12. Nance RE (1994). The conical methodology and the evolution of simulation model development. Ann Opns Res 53: 1–45. | Article |
13. Pace DK (2000). Ideas about simulation conceptual model development. J Hopkins APL Tech Dig 21(3): 327–336.
14. Pidd M (2004). Comput Simulat Mngt Sci, 5th edn. John Willey and Sons: Chichester, England.
15. Pidd M and Carvalho A (2006). Simulation software: Not the same yesterday, today or forever. J Simulat 1(1): 7–20. | Article |
16. Pooley RJ (1991). Towards a standard for hierarchical process oriented discrete event simulation diagrams. Trans Soc Comput Simulat 8(1): 1–20.
17. Richter H and Marz L (2000). Towards a standard process: The use of UML for designing simulation models. In: Joines JA, Barton RR, Kang K and Fishwick PA (eds). Proceedings of the Winter Simulation Conference. IEEE: Piscataway, NJ, pp 394–398.
18. Robinson S (2004). Simulation: The Practice of Model Development and Use. Wiley: Chichester, UK.
19. Robinson S (2006). Conceptual modelling for simulation: Issues and research requirements. In: Perrone LF, Wieland FP, Liu J, Lawson BG, Nicol DM and Fujimoto RM (eds). Proceedings of the 2006 Winter Simulation Conference. IEEE Computer Society Press: Piscataway, NJ, pp 792–800.
20. Robinson S (2008a). Conceptual modelling for simulation Part I: Definition and requirements. J Opl Res Soc 59(3): 278–290. | Article |
21. Robinson S (2008b). Conceptual modelling for simulation Part II: A framework for conceptual modelling. J Opl Res Soc 59(3): 291–304. | Article |
22. Robinson S and Pidd M (1998). Provider and customer expectations of successful simulation projects. J Opl Res Soc 49(3): 200–209. | Article |
23. Ryan J and Heavey C (2006). Requirements gathering for simulation. In: Robinson S, Taylor S, Brailsford S and Garnett J (eds). Proceedings of the 3rd Operational Research Society Simulation Workshop. The Operational Research Society: Birmingham, UK, pp 175–184.
24. Schruben L (1983). Simulation modeling with event graphs. Commun ACM 26(11): 957–963. | Article | ISI |
25. Sterman JD (2004). Business Dynamics: Systems Thinking and Modeling for a Complex World. McGraw-Hill: Boston, MA.
26. Wang W and Brooks R (2007). Empirical investigations of conceptual modeling and the modeling process. In: Henderson SG, Biller B, Hsieh, M-H, Shortle J, Tew JD and Barton RR (eds). Proceedings of the 2007 Winter Simulation Conference. IEEE Computer Society Press: Piscataway, NJ, pp 762–770.
27. Van Der Zee D-J (2006). Building communicative models—a job oriented approach to manufacturing simulation. In: Robinson S, Taylor S, Brailsford S and Garnett J (eds). Proceedings of the 3rd Operational Research Society Simulation Workshop. The Operational Research Society: Birmingham, UK, pp 185–194.

Acknowledgements

I am grateful for the constructive comments from Professor Stewart Robinson (Warwick Business School, UK), Murat Gunal (Lancaster University Management School, UK), and the anonymous referees.