Critical issues in the development of component-based discrete simulation

Simulation Modelling Practice and Theory 12 (2004) 495–514 www.elsevier.com/locate/simpat

Critical issues in the development of component-based discrete simulationq Noelia Oses, Michael Pidd *, Roger J. Brooks Department of Management Science, University of Lancaster, Bailrigg, Lancaster LA1 4YX, UK Received 29 October 2002; revised 1 June 2004; accepted for publication 17 June 2004

Abstract The development of computer simulation methods has proceeded in parallel with those in other areas of computing. Thus, interest in component-based approaches is evident both in general software engineering and in computer simulation, with advocates arguing that component-based approaches are far superior to more conventional ways of developing software and applications. Potential benefits are reduced cost and development time arising from reuse of components, as well as easier model adaptation due to the features of extensibility and evolvability. If these are to be realised, then organisations must develop ways to ensure that costs and benefits are shared and should ensure that suitable libraries and component distribution frameworks are available. In a simulation context it is also crucial to ensure that the issue of model credibility and validity is addressed even if the components are thought valid. Ó 2004 Elsevier B.V. All rights reserved. Keywords: Components; Simulation; Software architectures; Modular programming

q This is a revised version of the paper presented at the OR Society Simulation Workshop, Birmingham, 20–21 March 2002. * Corresponding author. E-mail addresses: [email protected] (N. Oses), [email protected] (M. Pidd), [email protected] (R.J. Brooks).

1569-190X/$ - see front matter Ó 2004 Elsevier B.V. All rights reserved. doi:10.1016/j.simpat.2004.06.005

496

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

1. Introduction Discrete computer simulation approaches emerged during the 1950s in the military and heavy industry, since when there has been much development in the applications tackled and in the approaches used. Initially, simulation programs were developed from scratch using low-level assemblers and machine code, which were the only available tools. As general purpose programming languages appeared and were used, the first hints of reusable routines appeared in the early 1960s. This evolution progressed as simulation languages, such as SIMSCRIPT, and block-structured systems, such as GPSS, were developed to make simulation programming simpler and less error-prone, allowing the modeller to focus on the system being simulated, rather than the computer programming. In the 1980s, the first Visual Interactive Modelling Systems (VIMS) appeared; graphical systems in which models are created using a point-and-click approach, with some limited programming to configure the model. As is clear from the market for simulation software, this evolution has increased the use of simulation methods, supporting the development of ambitious applications. Even in the 1970s it was clear that monolithic programs were difficult to test and to change, and that the co-operation of the original programmer was often needed if these were to be accomplished [30]. One approach then proposed was the use of modular programming, in which modules are separately programmed, debugged and compiled. Once properly tested, the modules are linked to form the required application. Zeigler [35] proposed a methodology that formalises the modular and hierarchical construction of simulation models. Pidd [25] argues that modular approaches to any modelling, including simulation, can be very beneficial. The aim is to cope with the growing size and complexity of simulation models. As an extension of this same argument, Kilgore et al. [17] suggests that such modules be developed as standardised simulation components as a way of reducing the complexities of the modelling task. Motivated by the search for easier and more efficient methods for software development (particularly effective reuse of software) there has been considerable interest recently in componentbased approaches both in general software engineering and in computer simulation. Nevertheless, component-based simulation modelling is still in its infancy. The aim of this paper is to examine its potential and the issues that may affect its development. Section 2 provides a basis by defining components, considers their interactions with the software architecture, and compares components and modules. One of the key benefits claimed for component standardisation is that it facilitates extensive reuse of code. Section 3 discusses the reuse of software in general and the specific issues relating to the reuse of components. Section 4 then focuses on use of a component-based methodology in simulation in order to identify the impacts on the simulation modelling process. Some examples of prototype component-based simulation systems are described. Finally, the key issues are summarised in Section 5.

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

497

2. Component-based software development 2.1. Components and architectures A component-based application consists of components linked together according to a defined architecture (see Section 2.2). The component-based software engineering (CBSE) literature contains several definitions for Ôsoftware componentÕ, of which Szyperski and PfisterÕs 1997 definition, quoted in [34], is probably the best known: ‘‘A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties’’. Jacobson et al. [15] is more concise and suggests that a component is ‘‘a standard building unit in an organisation that is used to develop applications’’. They go on to suggest that a component must have the following: 1. Application-independency, though it should be noted that application-dependent components can also be useful. 2. General abstraction of high quality, which is well tested, efficient and well documented. 3. A well-designed interface. Within this, the most important basis for component reuse is the implementation of a general and complete-enough interface. However, such a definition surely takes for granted that the components will be deployed within a defined architecture. The successful composition of components is extremely difficult without a predefined architecture, as is clear from the experience of Garlan et al. [13] when developing a component-based application without a well-defined architecture. They report the problems encountered when integrating four software subsystems that made different architectural assumptions—what they term Ôarchitectural mismatchesÕ. One difficulty was that components made different assumptions about the data that they were manipulating, leading to different interpretations. The most serious problem was different assumptions about the main thread of control. Problems with the final integrated system included: excessive code, poor performance, some external packages needed to be modified, some existing functions needed to be re-invented, the new system created unnecessarily complicated tools, and the construction of the system had been error-prone. Software architecture is important.

498

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

2.2. What is a software architecture? There is no single, widely accepted definition for software architecture. The specification of the Unified Modeling Language 1.3 (OMG, 2000) defines an architecture as: ‘‘the organizational structure of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts. Parts that interact through interfaces include classes, components and subsystems’’. Garlan and Perry [14] suggests that: ‘‘Software architecture is the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time’’. Bass et al. [6] states that: ‘‘The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them. By ‘‘externally visible’’ properties, we are referring to those assumptions other components can make of a component, such as its provided services, performance characteristics, fault handling, shared resource usage, and so on. The intent of this definition is that a software architecture must abstract away some information from the system (otherwise there is no point looking at the architecture, we are simply viewing the entire system) and yet provide enough information to be a basis for analysis, decision making, and hence risk reduction’’. In this paper, a software architecture is viewed as having five parts. 1. An interface specification. The term interface is used as in the Java language, referring to the declaration of a set of method definitions and, possibly, constants. In some programming languages this is known as a ÔprotocolÕ. In these terms, an interface includes no instance variables or implementation code. A component willing to implement an interface must provide the implementation code for all the methods defined by this interface, with exactly the same signature (the method name, argument types and return type), including the exceptions it might throw. 2. Documentation standards. 3. A set of rules for components that must include the following (a) Any direct reference from one component A to another component B is forbidden, unless B is a subcomponent of A. (b) Component A can only communicate with other components by implementing the appropriate interfaces from the Interface Specification.

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

499

(c) Components may only interact with the architecture by implementing the appropriate interfaces from the Interface Specification. (d) Components must be documented following the Documentation Standards provided by the architecture. 4. A precise definition of the services that any implementation must provide. 5. Guidelines for component distribution or packaging. Hence, the minimum requirement for a piece of code to be a component in an architecture is that it conforms to its rules and does not communicate directly with any other component other than its own sub-components. It does not matter whether this code implements a clear and useful functionality to determine if it is a component or not. It would certainly be desirable that it did, but even if a car breaks down and no longer moves it is still a car. 2.3. Ideal features of software components Components and their composition only make sense in the context of a pre-defined architecture and they must conform to the rules imposed by that architecture. They must, therefore, implement interfaces that serve as contracts offering guarantees. An interface tells a client how to access services provided by another component, and it also tells the provider how to make its services available to the clients. Conformance to standard interfaces means that components are replaceable and that they can interoperate. Components must be nearly independent and should implement a clear function. A component is independent if it requires little from the context and makes no direct references to other components. For example, a component that implements the functionality of a queue depends on other components to provide it with the objects to queue, and on others to make requests to queue objects. But this queue component must never have direct references to the components providing and requesting the objects. It may not be important if the component makes a few assumptions about the context, it depends on the purpose for which the component is designed. For example, the common core of an application family remains the same across all the applications in that family. A component could be built to implement part of the core functionality and, even if it relies on the environment, it could still be reused in other members of the family. Having a clear functionality is also important for reuse—components must make their requirements, functionality and output absolutely explicit. Finally, if they meet these conditions, components can be deployed independently and used in third-party composition. If the aim is extensive reuse, then the components should be developed with the awareness that they may be reused by third parties. That is, no assumptions should be made about what other components the user will be employing. Components are the unit of composition in the architecture and are managed as units even if they are composites of sub-components. Composite components can be decomposed into their sub-components, though this does not imply that

500

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

the behaviour of a composite component is the sum of the behaviours of the subcomponents; that is, emergent behaviour cannot be excluded. Thus, a component is seen by the architecture as a component, and should be seen as such by the developers and users, whether it is a composite or an atomic component. At composition time, any component coupling must make sense syntactically and semantically. The sole fact of abiding by the rules and interfaces of the architecture (syntactic agreement) does not mean that the composition of two components makes sense (semantic agreement). An analogy could be the following; even if two people speak the same language, this is no guarantee that they are interested and ready to talk about the same topics. Furthermore, different speakers of the same language may take the same word to have different meanings—a common way of getting an easy laugh in some films! Returning to component-based software composition, architectural coherence is not enough, it must make sense to link the components. If an existing component cannot fit into the software without modifications then, if its source code is available, the user might want to modify it. However, this is the creation of a new component since the user needs a component that does not exist and, consequently, needs to be created. The original component should never be made unavailable because some programs may be relying on it. Thus, in the case of modifying or extending a component the name should be changed so that it does not interfere with the original one. 2.4. The place of dynamic binding Discovering, loading and binding components at runtime allows an application to use components that were not known to the developer before the model started to run. Thus, the actual structure of the program can be changed, safely, at run-time. Dynamic binding is a feature of the architecture and implementation language. This in turn, affects the design and implementation of the components for that architecture. Dynamic binding differs from static or early binding; the latter is assigning types to variables at compile time. Some languages, like Smalltalk [16], Eiffel [20] and Java, allow for dynamic loading and binding of classes. Other languages either do not allow this or problems arise easily when doing so, as in C++ and the fragile superclass problem when, if the source code of a class is changed, all the classes referencing it have to be recompiled to make them work. With dynamic binding, components can be created (from scratch or otherwise) and then made dynamically available, probably via a server. 2.5. Components, modules, wrappers, adapters and mediators A component is, in effect, a module++ (a module with additional qualities). Components and modules are both independent pieces of software that are linked to others to build a system. As Stevens and Pooley [32] states: ‘‘a module might be any identifiable ÔbitÕ of a system which it makes sense to consider separately’’. Therefore, all components are modules.

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

501

One of the main pillars of CBSE is third-party composition—requiring components to be reusable, replaceable, evolvable and extensible by third parties. Standard interfaces, good documentation and the deployment approach are essential to achieve this. If modules do not fulfil these conditions then they are not components and so not all modules are components. Modules that are not components are those built without the context of an architecture. As an example, consider the NAG libraries, which contain useful functions, e.g. pseudo-number generators, which are used over and over again in a wide variety of contexts and domains. These functions are not components because they are not subject to an architecture that imposes rules on them. If they were components we would use the architectureÕs standard interface to access their services, as explained in the section about software architectures. By contrast, each NAG function has an individual signature that the user must invoke. Thus, it is the form and not the content that determines whether a module (or set of modules) is a component. According to Sommerville [31] wrappers solve the problem of reusing code (a module, a component in another architecture/language, etc.) that was not designed to be a component in a particular architecture. A wrapper is a container that, by itself, has no functionality; it merely provides an existing module with the implementation of the appropriate interfaces. A wrapped module becomes a component. Wrappers, like components, only make sense within an architecture. Adapter components solve the problem of reusing components that were designed within the framework of another architecture when this is not straightforward. These, unlike wrappers, are components not just containers, and are somewhat analogous to electrical adapters needed when using an electrical appliance in another country with a different plug system. Thus, staying with the idea that components have form as well as function, the adapter component changes the form in which a component shows itself to other components. Adapters are used to reduce the complexity of interactions between components that were designed for different architectures and may be organised into an adapter layer. More than one component may use the same adapter, which will occur if several components written for one architecture all need to be adapted for the same, other architecture. Even if they were built within the same architecture, components may not ÔunderstandÕ each other and so will need ÔtranslatorsÕ. Mediator components are middleware created to translate an interaction between two specific components. For example, component A generates ÔcarÕ objects and component B implements a queue. When component A generates a ÔcarÕ object it sends an interaction to the registered listeners with the interaction name ÔCarEventÕ. Component B can queue any type of object and it listens to interactions with the name ÔQueueObjectEventÕ. It is not possible to link A to B directly because B would not recognise the interaction. The solution is to create a mediator component, AtoBMediator, which will translate the interaction. When AtoBMediator gets an interaction from A with the name ÔCarEventÕ it will create an interaction with the name ÔQueueObjectEventÕ which carries the same object, that is, the generated car, and it will send this interaction to B. Now B will understand the interaction and it will queue the ÔcarÕ object.

502

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

3. Software reuse 3.1. Reuse, extensibility and evolvability Software reuse can take many different forms. At one extreme is an idealised plugand-play world in which components are used in an executable form and plugged together to produce an application. Java programs work in this way, though it is normal to distribute their source code as well. At the other extreme are situations in which source code is available and can be modified. That is, existing components may form the basis of customised components that are then linked to form an application. With such an approach, components can be extended with new functionality as needed, and then reused. As well as source code, other elements of a system can be reused, including elements from the requirements specification, the design, its implementation and its testing. In fact, for Reese and Wyatt [27] Ôsoftware reuse is the isolation, selection, maintenance and utilisation of existing software artefacts in the development of new systemsÕ. This is clearly rather broader than just source code or pre-compiled components. However, here the concern is with software components and will focus on the essential link between software components and software architectures. Szyperski [33] argues that although reuse and a consequent increase of productivity are important, the main driver for component technology is that it makes systems extensible and evolvable. An extensible system is one to which new parts can be added that will be able to interact with the existing parts of the system. Systems are evolvable if existing parts of the system can be replaced by new components to improve their quality or features, whilst retaining the same underlying functionality. The obvious analogy is with computer hardware that is both extensible and evolvable because new components (e.g. an Ethernet card) can be added, and other parts (e.g. video cards) can be upgraded and the other elements of the computer will still work. They will interact; for instance we might open a web page accessed via a LAN through the Ethernet card, and will see fast moving graphics that use the video card. But why do computer systems in general need to be extensible and evolvable? The answer is simple; the requirements of users change rapidly and computer systems need to change to meet these challenges. Software must be designed so that applications can be extended and can evolve to meet changing requirements. Furthermore, organisations have invested much money and resources building past applications, and it may not be sensible to completely discard these; extending the life of these investments may make commercial sense. Hence the enthusiasm for approaches which avoid the need to write everything from scratch every time. An additional potential feature of component-based software is the ability to build programs that can be re-configured at runtime using dynamic binding. 3.2. Object orientation Object orientation (OO) assumes that program code will be composed of modules, or objects, in which the code is encapsulated with the data. Computation proceeds by

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

503

message passing as one object requests the service of another. Objects are members of classes; the class defining the data and code of the objects. As objects are created, they are instantiated using constructor functions and, if no longer needed, may be de-referenced using destructor functions. Class inheritance allows a new class to be defined as a more specialised subclass of a parent class, which avoids the need to define each class from scratch. Thus a program consists of class definitions and code in which objects are instantiated, communicate with one another and may be de-referenced. Class definitions provide a public interface that defines the accessible variables of the class and the methods that other classes may call when sending a message. Java is probably the most widely used truly object oriented language. Others, such as C++, support many features of object orientation, but do not mandate their use. An OO approach has three well-known advantages. First, the computation is safe in that unintended side effects can be contained within a particular module. Secondly, it eases the process of program development by breaking down the computation into smaller units that can, in principle at least, be separately tested. Thirdly, new classes can inherit the features from their parent class(es) avoiding the need to edit the parent class to add new functionality. Object orientation provides the basis for most component-based approaches. Often, the main stated rationale for component-based approaches is to achieve extensive reuse, which is one of the unfulfilled promises of object-orientation (OO) [33]. Sommerville [31] argues that reuse has not been achieved with OO technology because single object classes are difficult to market. This is because many such classes are too detailed and specific and their reuse requires detailed knowledge of the class—which often means that the source code of the component must be available, a requirement that few component providers are keen to meet. If reuse of components were possible, this could increase productivity by cutting program development time and its resulting cost. 3.3. Factors affecting component reuse Trust is an important factor in component reuse. Jacobsen et al. (op cit) argue that people do not always trust code written by others, in part because they think they have more control over their own code. They may also believe that they can implement the code better. This may be justified, since large software systems often contain undetected bugs and it is easier to sort out oneÕs own bugs than those produced by other people. Hence, proper testing regimes and guarantees, with proper documentation, are crucial if components are to be reused without modification. Taking this argument further, poorly documented components are difficult to reuse. One reason that people like to see source code is that they can see the detail of a componentÕs operation. This desire is sensible, since for successful reuse a component has to be well understood. The need for source code is obvious when a component is to be adjusted or extended. Even if components exist, it will be difficult to use them if they cannot be found, which requires properly maintained libraries and directory services. Sommerville (op cit) regrets that some engineers do not regard the search for components as part of their job unless they know they are very likely to find components that suit their

504

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

needs. Though components provide for rapid development this does not imply that any software developer will, by using components, find that the development process is a lot easier and faster, for the system developer needs expertise in componentbased software development. This implies mastery of the architecture being used and significant knowledge of the components in the available libraries. If these requirements are not met the promise of faster development will not be fulfilled through component reuse. Proper training and specialised knowledge are needed, as ever, to achieve full potential. 3.4. What is gained from component reuse? Somerville (op cit), Jacobsen et al. (op cit) and Meyer (op cit) suggest that frequently used components should, eventually, be of higher quality than traditional software because they will be thoroughly tested by continued reuse. As a component is successively reused, bugs and/or weaknesses will be discovered by the component developer and users, allowing its correction for future use. This implies that overall system quality increases, but also raises the question of the component developerÕs responsibility for system integrators using its earlier versions. The development process for component-based systems needs to be quite different from that of ordinary software, since there are two quite separate stages; component development and component composition—which are usually carried out by different parties. Components are usually developed by domain experts, using a cyclic process in which components are planned, developed and reviewed. Commerciallyoff-the-shelf (COTS) components are usually delivered as black-box components, making it impossible for users to correct any mistakes, and therefore much care is put into their testing and validation by developers. The second stage, component composition, is typically carried out by software engineers who specialise in this task. If this two-stage process is not managed carefully, CBSE may not have any advantages over traditional software development. 3.5. The downside Systematic component reuse does not just happen but must be planned, organised and encouraged [15]. As discussed above, component specification, implementation and testing is crucial for safe and straightforward reuse. This can mean that the initial development of a component is more expensive than a monolithic software product. A third party developer who expects to sell the component repeatedly will bear this cost in the expectation of future returns. If components are to be reused in-house, then the budget that bears the cost of initial development may not receive the benefits of later, lower costs and increased reliability unless appropriate reward systems are in place. Since software projects often have tight budgets and time schedules, the above consideration may mean that, without a properly managed reuse programme, it may not be worthwhile to build components. There is also the Ônot-invented-hereÕ attitude since, as mentioned earlier, software engineers may not trust other peopleÕs

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

505

code—they believe they can do it better and may feel more productive when writing source code. Components can also increase the maintenance costs in some cases, especially if source code is not available. This is because the reused elements of the system may become increasingly incompatible as the system changes. This is especially so for black-box components, for which the system integrator has no access to the design considerations or to the source code, which limits the extent to which they can be adapted to complex needs. To cope with strict quality requirements, a component development process must allow for white-box customisation for critical aspects of a system. If components are to be widely used, they must be stored in accessible libraries and creating these can be expensive. Though the idea of a single worldwide component library exists as a gleam in enthusiastsÕ eyes, this is currently impossible, though creating organisation-wide repositories is certainly feasible. This does, however, rely on the issues of trust and cost-benefit sharing discussed above. Obviously, such libraries will only be used if software engineers are informed of their existence and if the components are readily available. As Jacobsen et al. (op cit) point out, someone must be in charge of developing new components and maintaining the library. Experienced designers together with a representative of the component department should act as a Ôsoftware component committeeÕ to review new component proposals and decide whether they should be built or not. Finally, there are issues related to intellectual property and system maintenance. Who will be responsible when an upgraded or modified component causes problems? Who has the rights to a component that has been developed by a third-party and then modified in-house? These questions cannot be ignored and need to be part of any contractual negotiations.

4. Component-based simulation How do the preceding arguments apply to computer simulation? Standard simulation texts suggest that there are several steps in any simulation study, including: problem formulation, setting of objectives and overall project plan, model conceptualisation, data collection, model translation, verification, validation, experimental design, model runs and analysis, documentation and reporting, and implementation [5,8,24]. Taking a component-based approach affects several of these, but the initial focus in this section is the development of a conceptual model and its translation into a computer program. Other aspects, for instance the way that component-based development affects validation, are also very important and will be discussed later. 4.1. Simulation modelling Firstly, since advocates of component-based approaches argue that their methods ease the task of simulation modelling, it is important to consider what is meant by ÔmodellingÕ. It is helpful to think of two types of models—the conceptual model

506

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

and the computer model. Brooks and Robinson [8] defines a conceptual model as Ôa software independent description of the model that is to be constructedÕ. Pidd [24] argues that a conceptual model is intended to capture the essential features of the system and is usually represented as flow diagrams, as a textual description or both. By contrast, the computer model is the translation of the conceptual model into computer code. Until the 1980s, the development of simulation models by writing source code was still the most common approach. Thus, there was a clear line dividing the development of the conceptual model and the development of the computer model. A conceptual model would be developed and then translated into computer code. This process would usually be cyclic, going back and forward to make changes in the conceptual model and implementing them in the code. In this style of working, ÔmodellingÕ usually refers to the task of developing the conceptual model, which should be implementation independent, in theory—though this is not always achieved. It could be argued that it is important not to be committed to any particular software or approach when building the conceptual model. However, an organization or individual may already have simulation software and expertise available and may be unwilling to invest more money and/or time in other approaches. Nowadays commercially available tools such as Visual Interactive Modelling Systems (VIMS), blur the line. VIMS users often start by building the model directly in the simulation environment. In a way, they are building the conceptual and computer models at the same time. VIMS allow a model to be visualised as a flow diagram as it is built, and are designed to support a trial-and-error approach in which it is reasonably easy, especially in the early stages, to make changes to the models. Since complexity is often best handled by starting with a simple representation that is successively refined, such an approach makes great sense. Writing code from scratch takes a lot more effort than constructing a model by point-and-clicking on the screen, so it is not feasible to start coding without having a clear idea of what is needed and what the structure should be. However, in both approaches, successive refinement is a sensible strategy. When using a VIMS, a clear separation of conceptual and computer modelling may be impossible. A hierarchical or component-based approach can be used to build the conceptual model and the computer model, alternating between the two. The system being studied can be modelled in a top-down manner, both conceptually and as a computer program, by first specifying which are the main parts of the structure and the relationships between them without worrying about the particular details. Then each part can be broken down into its constituent parts, recursively. This is a hierarchical model development approach for both the conceptual and computer models, which helps in managing the complexity of the system [12,24]. It encourages a focus on the appropriate level of detail in each step, and also helps testing the model at all the different stages. In each step the components can be built from scratch or reused if they already exist.

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

507

4.2. Motivations for component-based simulation modelling A simulation model should be easier to manage if it can be decomposed into a set of smaller parts that can be considered separately. This does not mean that any first-time simulation user will, by some magic, be able to build extremely complicated models by using a component-based approach. It does mean, though, that appropriately trained, experienced and skilled simulationists should find it easier to develop appropriate models. Object orientation offers an obvious way of implementing this modularity, though there are still some technical issues related to inheritance mechanisms and to entity interactions that require consideration [23]. It is a common view that simulation models are becoming increasingly large and complex in some domains [21]. If this is so, it increases the burden on the simulation programmer [26]. Pre-packaged software solutions (such as the VIMS tools available from various vendors) are a great help but are most effective when used in the application domains for which they were designed, otherwise they can be a hindrance. When modelling large systems or problems that are very different from those in the domain for which a VIMS was designed, there are obstacles to overcome if these tools are to be used. It seems reasonable to argue that these problems arise because these tools are not flexible, adaptable or extensible enough. Daum and Sargent (op cit) discusses three different modelling techniques to cope with this complexity. Firstly, the use of a hierarchical model specification that allows a model to be specified at different levels of abstraction. Secondly, the scaling of model elements to allow the combination of similarly structured and parallel operating model elements into arrays of fixed or dynamic sizes. Thirdly, they suggest the reuse of model elements and their specifications. They insist that hierarchical modelling and scaling are necessary to model complex systems and that reuse of model elements is needed to model systems effectively— that is a development process which is faster, easier and cheaper. Componentbased simulation allows for hierarchical modelling and reuse, and could be envisaged as a way of improving VIMS. Having plug-and-play components would make VIMS extensible and also more flexible. In addition, since components allow for hierarchical modelling, component-based VIMS would make modelling easier. Melao and Pidd [19] describes an extensible component-based VIMS for the simulation of business processes. In this context, what of the High Level Architecture (HLA) of the US Department of Defense (IEEE standard 1516). Many defence sector models were very expensive to build and need to be used over long time periods, possibly linked to other models. The HLA provides an architecture and a specification of wrappers, adapters and mediators that enables such models to inter-operate. In this way, older, existing models can become components within the HLA and new models may be written to abide by the rules of the HLA, becoming components (federates) of an HLA federation, or simulation run. However, these large models were built for very specific purposes and are not reusable without some

508

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

modification. Since the defence sector develops and uses massive simulation models, its simulation developers also employ code repositories. Whether smaller, nondefense applications need the full rigour of the HLA to inter-operate is another question altogether. 4.3. Architectures for component-based simulation Dynamic simulation models require specific services from their architectures. For example, all simulations, except static Monte Carlo models, mimic the behaviour of some system over time. As argued in Section 4.5, most discrete event simulations are developed to investigate aspects of the performance of the system being simulated. The dynamic aspects are important, since the interactions of the system entities produce the characteristic performance of the system. Many components of such models must execute activities, often at specific points of simulation time, and these activities will probably provoke interactions with other components. Thus, the dynamic components must declare their intention to execute an activity in the future, together with the simulation time at which it must be executed. Therefore, the architecture must keep track of those components and provide the means for those activities to be executed in the right time stamp order. This Time and Calendar Management must be implemented in every dynamic simulation architecture, though the detail will depend on the simulation worldview chosen. The choice of worldview will also have an effect on the rules that the architecture must impose on the implementation of the components. As is well known, simulations need not run sequentially but may, instead, be divided into different logical processes (LP) that run on parallel or distributed computer systems. The HLA utilises similar technology to allow the interoperation of simulation models that are distributed across several computers. In an HLA federation, the individual federates are analogous to LPs. In parallel and distributed implementations, causality errors may occur if one LP sends a message to another LP with time-stamp smaller than the current local time in the receiving LP. The architecture must either prevent these errors, or needs rollback mechanisms to recover from them so as to maintain causality. How this is implemented as part of the time and calendar management services for a parallel simulation will vary; for example, time might be implemented globally or locally, as might event calendars. 4.4. Pros and cons of component-based simulation The requirements for the components of a component-based simulation program are, dynamic aspects apart, much the same as for any program. Hence, the pros and cons of component-based simulation modelling are much the same as those for component based software engineering in general. The benefits promised are faster development and increased reliability through reuse; and extensibility and adaptability. However, these will only be realised through the effective management of simulation model development. As in general CBSE, there are two stages to be managed; component development and system composition from the components. In component

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

509

development, proper component testing and documentation are crucial if system integrators are to trust the components that are available for reuse. Componentbased simulation also offers the possibility of extensive visual programming, which should simplify the process of developing a model by allowing assembly of components by point-and-clicking. Libraries and associated directory services must be provided for effective system composition, otherwise developers will simply be unaware of what is already available. For reuse to succeed there must be a way to classify and distribute components efficiently. This is not an easy task especially because of validation and trust issues that are not present in other subjects like, for example, book or CD classification and distribution. The first step would be to define component classification standards and implement directory services for properly documented components. Even then, selecting a complete and correct set of components to develop a model could be very difficult, especially as the number of available components increases. In addition to these general CBSE issues, there are two issues affecting component-based simulation that are specific to simulation, namely model validation and time management, and these are discussed in Sections 4.5 and 4.6. 4.5. The importance of validity and credibility There is a major issue in simulation modelling that may not be so obvious in general CBSE. This is the vexing question of validation. This is not the place to explore the questions of model validity and credibility in great detail, for which see [1,28, 29]. However, the issue of model validity is always important when considering how simulation models might be constructed. There are many different reasons why simulation models are constructed, but most discrete event simulations are built to investigate the performance of the system being simulated. This may be to assess the effect of making changes to the system or to investigate possible system designs of policies for its operation. Whatever the actual reason for building the model it is important to realise that it is built for some purpose and it is against that purpose that the modelÕs validity and credibility must be assessed. No simulation model is ever valid for all purposes and if its use is stretched beyond the original reasons for its development then its validity must be in doubt. It is important to realise that this is as true of model components as it is of full models themselves. It seems widely agreed that absolute validation is impossible, especially when simulating systems and configurations that do not exist—there is no reference system against which to compare the model in a direct way. Instead, most people write of increased confidence that the model or simulation is fit for the purpose for which it is intended. Systems theory teaches that composites made up of sub-systems may display emergent behaviour. That is, they may behave in ways that are hard, if not impossible, to predict from the components themselves, since systems are components plus organisation. Though a component may be thoroughly tested, the organisation of the components may not be and nor may the behaviour of those components within that organisation. Validation also needs to be related to the objectives of the study as, for example, the accuracy required from a model can vary

510

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

considerably. Therefore, validation of individual components on their own can only provide limited confidence. Hence the problem of model validation looms just as large in component-based simulation as in any other simulation study. In general, there are two main approaches that can be used in assessing the validity of a simulation model—black box and white box (or open box) validation (see [24]). Black box validation involves a Turing test in which the output from the model is compared with observations from the system being simulated—if the latter exists. This can be done at component level and, also, for a model that has been put together from a set of components. In white box validation, on the other hand, the internal and static structure of the model is compared with what is believed to be the structure of the real system. This is clearly best done at component level if a component has a clearly identifiable counterpart in the system being modelled. Though model validation is only one part of simulation credibility assessment, it seems that a component-based approach might well ease the validation process. However, as suggested above, any validity must be assessed against an intended purpose. If a model or component is used beyond its intended experimental frame, then any prior views on validity must be taken with a pinch of salt. 4.6. Time and calendar management services Unlike general software, simulation is dynamic and so time and calendar management services are required. With component-based simulation there might be time management and coordination difficulties analogous to those from parallel and distributed simulation discussed earlier. If it is possible to specify fully the time management and coordination rules in the simulation architecture, then this is, in principle at least, solvable. 4.7. Successful efforts in component-based simulation This section presents some examples of individual efforts to achieve some of the goals of component-based simulation. The Visual Simulation Environment (VSE) [2–4] is a fully object-oriented discrete event simulation system with simulation models that are divided in static and dynamic parts. The static architecture, which generally represents the structure of a model, is composed of hierarchically decomposed components. The dynamic parts are dynamic objects, which are entities that move from one point to another of the model. VSEÕs own components are made available via the VSLibrary, all VSE models are developed by subclassing (extending) classes in VSLibrary, which has VSObject as its root class. Anyone wishing to add new components to a library must do in the VSE scripting language, which is designed to support discrete simulation. A VSE Editor is provided to ease the process of component production. In its execution, VSE employs a TCP/IP stack to enable communication between its simulation components as the model runs. This means that it can execute on a single computer, on a multi-processor compute-box or across a network of individual machines. It was originally written for the NextStepTM environment and

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

511

requires appropriate emulation software to be pre-installed if it is to run under Windows NT4. VSE support several models of model development. The first is by the reuse of model components from a library with no programming, which VSE supports by a drag and drop approach. Of course, this will often be impossible since the library may be incomplete for the task at hand, and the second approaches build on this by some programming, to extend, modify or add new methods to a component by subclassing. A third way is to reuse model components created during the model development process (components created in the Templates window). Finally a user may build a VSE model with no reuse where each model component is engineered from scratch. VSE is designed to support the development of reusable components and regards a library (a set of reusable model components) as a form of component in itself. Reusable components are created in the Templates window, and can be created, manipulated, and destroyed during model execution. Thus, a modeller could make use of VSE components developed by others to build a model for a particular application. Rather than providing a full simulation system, Lorenzo et al. [18] describes a component-based approach to the creation of sensor modelling environments, which permit reconfigurability and support scalability of complexity. Their hierarchical framework sits under the HLA so as to allow components to be nested within components and also to optimise communications between them and the federation. These hierarchically defined objects are known as Ôcomposable component federatesÕ, which are claimed to lead to higher fidelity models. This framework supports the reuse of large, expensive federates (i.e. components) and supports increased complexity by distributing some of the smaller, inexpensive, easily distributed component federates. Bradley et al. [7] model military planning and execution systems with a component architecture, now known as Simkit [9]. Components include those for displaying information in different formats (images, maps, etc.), accessing data, constructing and displaying models, and accessing and executing algorithms. Based on Java, SimKit permits the rapid and inexpensive linkage of components to construct seamless systems. SimKit supports dynamic, recursive composition and effectively enables the users of conforming components to assemble complex models from simple components rapidly. One interesting feature is the support for dynamic composition using Java reflection, remote method invocation and event management with sources and listeners via Listener Event Graph Objects (Lego) [10]. SimKit is intended to be useful to both planners and operators. Operators in a mission usually have smaller (in size and capacity), less powerful computer devices in which it is not possible to store all the components that might be needed at some point. Hence, the framework was designed to allow the operator to download and link algorithms to the executing system as and when needed. Cusack et al. [11] describes a simulation environment to support command and control research using a Java Component Federate Infrastructure (JCFI) component-based simulation framework. The aim was to support reuse and to provide a rapidly reconfigurable and extensible approach. There is also a related, customised visual environment for visual programming and assembly of simulation models.

512

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

The application described, the simulation of Command Information System (CIS), demonstrates that the framework allows for rapid, visual assembly of simulation models. Oses [22] describes the development of WBSS, a web-based discrete event simulation system using Enterprise JavaBeans (EJBs) and based on the Component Based Simulation Architecture (COSIMA). Enterprise JavaBeans is a server-side component architecture for distributed computing, in which an EJB bean exists within an EJB container, which itself exists within an EJB server. The EJB server is responsible for providing the container with services such as network connectivity, and the container provides support for persistence, security, multiple instances and transactions. The EJB bean contains the business logic and can be persistent (entity bean) or non-persistent (session bean). Usually, EJB beans provide the server components and regular beans the client-side. COSIMA assumes a three-phase discrete simulation worldview implemented in Java and employs remote method invocation (RMI). COSIMA compliant components can be discovered, linked and run in a distributed fashion or on a single processor machine. Component interaction is managed via Java listeners and sources and WBSS provides a prototype graphical environment within which COSIMA compliant components, whether distributed or local, can be composed into a simulation application.

5. Conclusions As is clear from the previous sections, many of the technical problems faced by component-based simulation modelling have been solved. Software systems exist in Java and other languages that enable simulation modellers to develop applications by linking together existing components, in part at least. In addition, the DoDÕs HLA allows existing models and components to interoperate. Thus, reuse and component-based development are already a reality. Component-based software engineering and component-based simulation promise extensive reuse, leading to reduced development time and cost, and extensibility and evolvability, which make systems more adaptable and easier to modify. For component technology to succeed the processes involved must be properly managed. Component developers must be domain experts and must master the architecture being used. The specialised component-based software engineers, who carry out the composition of components to build applications, must master the architecture being used and need a significant knowledge about the components in the available libraries. Even when the individuals possess the required knowledge, component reuse does not just happen but must be encouraged at an organisational level. However, it is important to recognise the differences between simulation and general software. Firstly, simulation models are dynamic and so careful time management and coordination of the components are required to avoid causality errors. Consequently, suitable control mechanisms must be built into the architecture. Secondly, a simulation model is a simplified representation of a system built for a particular objective and so validation is a vital part of a simulation project. The assessment

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

513

of the suitability of a component must compare its intended purpose with its actual use within the particular simulation model in the context of the project objectives. As with any simulation model, validation of parts of the model alone is not sufficient as this ignores the effects of the interactions between the components. As ever, there is no silver bullet, no panacea that will guarantee lower cost applications that are much more reliable. It is clear that component-based simulation approaches could have many benefits, but the obstacles are not, primarily, technical. The benefits can be achieved if organisations who sponsor simulation modelling ensure that proper systems are in place to ensure trust, to support component documentation and component access and if they develop ways to share the benefits between component developers and the model builders who use those components. Acknowledgments Noelia OsesÕ research was sponsored by the Basque Government under a grant from the ÔPrograma de Formacio´n de Investigadores del Departamento de Educacio´n, Universidades e Investigacio´nÕ. We are grateful to the anonymous referees who provided helpful feedback that led to the final version of this paper. References [1] O. Balci, Validation, verification and testing techniques throughout the life cycle of a simulation study, in: O. Balci (Ed.), Annals of Operations Research, 3, 53, Simulation and Modelling, J.C. Baltzer AC, Basel, Switzerland, 1994. [2] O. Balci, A.I. Bertelrud, C.M. Esterbrook, R.E. Nance, Developing a library of reusable model components by using the Visual Simulation Environment, in: Proceedings of the 1997 Summer Computer Simulation Conference, Arlington, VA, July 13–17, SCS, San Diego, CA, 1997. [3] O. Balci, A.I. Bertelrud, C.M. Esterbrook, R.E. Nance, Visual simulation environment, in: D.J. Medeiros, E. Watson, J. Carson, M.S. Manivannan (Eds.), Proceedings of the 1998 Winter Simulation Conference, Grand Hyatt, Washington, DC, 13–16 December, SCS, San Diego, 1998. [4] O. Balci, C. Ulusarac¸, P. Shah, E.A. Shaw, A library of reusable model components for visual simulation of the NCSTRL system, in: D.J. Medeiros, E. Watson, J. Carson, M.S. Manivannan (Eds.), Proceedings of the 1998 Winter Simulation Conference, Grand Hyatt, Washington, DC, SCS, San Diego, 13–16 December 1998. [5] J. Banks, J.S. Carson II, B.L. Nelson, D.M. Nicol, Discrete-event System Simulation, 3rd ed., Prentice-Hall Inc., Englewood Cliffs, NJ, 2001. [6] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, Addison-Wesley, New York, 1997. [7] G.H. Bradley, A.H. Buss, C.H. Shaw, An architecture for dynamic planning and execution using Loosely Coupled Components. Naval Postgraduate School Research Newsletter, Volume 8, Number 3, October Monterey, California, 1998. [8] R.J. Brooks, S.L. Robinson, Simulation, with Inventory Control (author C. Lewis). Palgrave, Basingstoke, 2001. [9] A.H. Buss, Component-based modelling with SimKit, in: J.M. Charnes, E. Yu¨cesan, C.-H. Chen (Eds.), Proceedings of the 2002 Winter Simulation Conference, San Diego CA, SCS, San Diego, CA, December 8–11 2002. [10] A.H. Buss, P.J. Sanchez, P.J., Building complex models with LEGOs (Listener Event Graph Objects), in: J.M. Charnes, E. Yu¨cesan, C.-H. Chen, (Eds.), Proceedings of the 2002 Winter Simulation Conference, San Diego CA, December 8–11 (SCS, San Diego, CA, 2002).

514

N. Oses et al. / Simulation Modelling Practice and Theory 12 (2004) 495–514

[11] M. Cusack, N. Exon, P. Hoare, R. Hoyle, Visual construction of JavaBean federates, 2000 Spring Simulation Interoperability Workshop, March 26–31. [12] T. Daum, R.G. Sargent, Scaling, hierarchical modelling, and reuse in an object-oriented modelling and simulation systems, in: P.A. Farrington, H.B. Nembhard, D.T. Sturrock, G.W. Evans (Eds.), Proceedings of the 1999 Winter Simulation Conference, Phoenix, AZ, December 5–8. SCS, San Diego, CA, 1999. [13] D. Garlan, R. Allen, J. Ockerbloom, Architectural mismatch: Why reuse is so hard, IEEE Software 12 (6) (1995) 17–26. [14] D. Garlan, D. Perry, Guest Editorial to the IEEE Transactions on Software Engineering, April 1995. ¨ vergaard, Object-oriented Software Engineering: A [15] I. Jacobson, M. Christerson, P. Jonsson, G. O Use Case Driven Approach, ACM Press, New York, NY, 1992. [16] A. Kay, The early history of Smalltalk, in Proceedings of 2nd ACM SIGPLAN history of programming languages conference. ACM SIGPLAN Notices 28(3) (1993) 69–75. [17] R.A. Kilgore, K.J. Healy, G.B. Kleindorfer, The future of Java-based simulation, in: D.J. Medeiros, E. Watson, J. Carson, M.S. Manivannan (Eds.), Proceedings of the 1998 Winter Simulation Conference. Grand Hyatt, Washington, D.C., 13–16 December. SCS, San Diego, 1998. [18] J.M. Lorenzo, K.L. Morse, P.D. Rizik P.D, Sensor simulation scalability using composable component federates, 2000 Fall Simulation Interoperability Workshop. [19] N. Melao, M. Pidd, Using component technology to develop a simulation library for business process modelling. Submitted to Euro Jnl Opl Res., 2003. [20] B. Meyer, Eiffel: The Language, Prentice-Hall, Englewood Cliffs, NJ, 1992. [21] J.-M Naud, Simulation models as components in an HLA world. 1999 Spring Simulation Interoperability Workshop, March 14–19, 1999. [22] N. Oses, Component based simulation. PhD thesis, Department of Management Science, Lancaster University, Lancaster, 2002. [23] M. Pidd, Object orientation, discrete simulation and the three-phase approach, J. Operat. Res. Soc. 46 (1995) 362–374. [24] M. Pidd, Computer Simulation in Management Science, 5th Edition., John Wiley & Sons Ltd., Chichester, 1998. [25] M. Pidd, Tools for Thinking: Modelling in Management Science, John Wiley & Sons Ltd., Chichester, 1996. [26] H. Praehofer, Object oriented modelling and configuration of simulation programs, 13th European Meeting on Cybernetics and Systems Research. (Austrian Society for Cybernetic Research, Vienna, 1996). [27] R. Reese and D.L. Wyatt, Software reuse and simulation, in: A. Thesen, H. Grant, W. D. Kelton (Eds.), Proceedings of the 1987 Winter Simulation Conference, 14–16 December 1987 SCS, San Diego, CA, 1987. [28] S.L. Robinson, M. Pidd, Provider and customer expectations of successful simulation projects, J. Operat. Res. Soc. 49 (3) (1998) 200–209. [29] R.W. Sargent, A tutorial on validation and verification of simulation models, in: M.A. Abrams, J.C. Comfort, P.L. Haigh (Eds.), Proceedings of the 1988 Winter Simulation Conference. SCS, San Diego, CA, 1988. [30] R.E. Shannon, Systems Simulation: The Art and Science, Prentice-Hall, Englewood Cliffs, NJ, 1975. [31] I. Sommerville, Software Engineering, 6th Edition., Pearson Education Limited, Harlow, 2001. [32] P. Stevens, R. Pooley, Using UML: Software Engineering with Objects and Components, AddisonWesley, New York, 1999. [33] C. Szyperski, Component Software: Beyond Object-oriented Programming, Pearson Education Limited, Harlow, 1999. [34] C. Szyperski, Beyond objects: point, counterpoint. Software Development Online, February, 2000. http://www.sdmagazine.com/articles/2000/0002/0002l/0002l.htm. [35] B.P. Zeigler, Multifacetted Modelling and Discrete Event Simulation, Academic Press, New York, NY, 1984.