European Simulation Symposium, 1997
SIMOO - An Environment for the Object-Oriented Discrete Simulation Copstein, Bernardo1,3
Wagner, Flavio R.1
Pereira, Carlos E.2
1
Informatics Institute 2Eletrical Engineering Department Universidade Federal do RioGrande do Sul Caixa Postal 15064 91501-970, Porto Alegre, RS, Brasil
3
Informatics Institute - Pontif’cia Universidade Cat—lica do RGS Caixa Postal 1429, 90619-900, Porto Alegre, RS, Brasil
E-mail:
[email protected]
[email protected]
[email protected]
KEYWORDS Discrete Simulation, Object Oriented Simulation, Interactive Simulation. ABSTRACT This paper describes SIMOO, an object-oriented framework for discrete simulation. Simulation entities in SIMOO are mapped to autonomous elements, that are objects with their own thread. Objects communicate with each other through non-typed messages. SIMOO models are built using a graphical editor called MET. MET uses a hierarchical class diagram, enriched with specific features for simulation. For instance, it allows the specification of the simulation paradigm which is more adequate for each entity. Besides a hierarchical class diagram, instance diagrams are also described, where the generic specifications of class diagrams are particularized. From the specified diagrams and from the description of the entitiesÕ behavior, MET generates an executable model which uses a class simulation library. 1.
INTRODUCTION
The use of object orientation in simulation is widely discussed in the literature [ARO93, CHA94]. In fact, SIMULA [BIR73], which, as the name indicates, was oriented towards simulation, was the first language to use objectorientated concepts. This symbioses between object orientation and simulation can be mainly explained by the fact that simulation models are usually considered as a collection of interacting entities, so that the use of object orientation in the construction of such models is quite natural. The description of a simulation entity includes static aspects, such as the definition of its characteristics and state, as well as dynamic aspects, such as how an entityÕs state evolves along time. The static part is represented as a collection of data objects and their possible values [COT92], while the dynamic structure is more complex and involves aspects such as the representation of the events that modify the system state, the resources for the communication between entities, and the viewpoint from which the entitiesÕ behavior is described. These three aspects are orthogonal to each other and various combinations of their implementation alternatives can be used to describe the behavior of a particular simulation entity. When mapping entities to objects, some aspects must be considered. According to Booch [BOO94], the state of an object is described by the set of its data attributes and their possible values. Abell and Judd [ABE93], however, signal that the state of a simulation entity is defined by the subset of the attributes of the object which are specifically used to describe the entityÕs behavior. Regarding the messages, in object-oriented models a message usually corresponds to the activation of a process within the object receiving this message. In simulation models, however, message exchanging is more complex. Messages must have time stamps to allow the scheduling of future events. Nontimed messages are useful only for querying object attributes or for triggering actions that do not imply time advancing. Complex message queuing systems and the use of selection primitives may be found in the simulation literature (see e.g. [BAE91]). Considering these two aspects, Cota [COT92] defines two types of entities: passive receiver entities, where the message sender determines the time point when the receiver must process the message, and active receiver entities, where messages are stored in a buffer for later processing. Several simulation environments which try to explore object-oriented concepts have been presented in the literature. SMOOCHES [BAR96] is a general-purpose simulation environment which offers a high-level language for representing hierarchical, object-oriented system characteristics. It uses graphical notations for both the class model and the behavior description of the entities. ExSim [ZHE93] uses a programming model based on a block diagram for representing system components and classes for representing the components behavior. Information exchange between blocks is done by messages that flow through communication channels defined by input / output ports. Finally, VMSS [KAM96] explores VIM (Visual Interactive Modeling) and VIS (Visual interactive Simulation) in an environment oriented towards the simulation of flexible manufacturing systems.
Most of the authors, however, present their ideas based on a single simulation modeling paradigm, such as message orientation [CHA94], queue orientation [VAU91], or event orientation [BAR96, ABE93]. There is no concern in distinguishing the paradigm adopted for model design/implementation, which is object orientation, from the simulation paradigm. As a consequence, these approaches do not offer the flexibility to choose the simulation paradigm according to the problem to be solved. Furthermore, it can be observed that the highest degree of interaction between the user and the model is found in environments with specific purposes. When the generality of the environment increases, the degree of interaction usually decreases. Considering all those aspects, SIMOO, a framework [GAM95] specially oriented towards the development of discrete simulation models, has been designed. SIMOO differs from other approaches, because it allows the selection of the most adequate simulation paradigm for each particular entity in the model. This selection takes into account the different aspects that compose each simulation paradigm. SIMOO makes a clear distinction between the paradigm for model design, which is object orientation, and the various traditional simulation paradigms (such as event and process orientation) it supports [COP96]. Besides that, SIMOO explores meta-classes [BOO94] and meta-objects as a way to achieve a maximum degree of interaction between the user and the model, without forcing the model developer to consider and implement this interaction. This paper is organized as follows. Section 2 discusses the modeling principles of SIMOO, that are implemented in a class library. Section 3 introduces a graphical tool for model building. Finally, Section 4 draws conclusions and discusses future directions of research. 2. SIMOO MODELING PRINCIPLES SIMOO is an integrated environment for modeling and simulation of discrete systems. It is composed by two main modules: the class library and the model editor. The editor supports the description of static and dynamic aspects of the model. In the current version of SIMOO, structural aspects are described graphically, while the dynamic behavior of each entity is described in C++ using library resources. From model description, the editor automatically generates the necessary executable code. It also supports the construction of a library of autonomous elements, which may evolve as new models are developed. Figure 1 presents this main software architecture. SIMOO uses object-oriented concepts and enforces a hierarchical modeling of the system to be simulated. At the highest abstraction level there is a single entity representing the whole system under simulation. This entity is further necessarily refined at lower abstraction levels, thus building an aggregation hierarchy. Such modeling strategy aims at an easier reuse of entities, as well as a progressive refinement when it is needed.
Figure 1 - SMOO architecture A model is assembled by Òinterface elementsÓ and Òautonomous elementsÓ. Interface elements allow the tracking of the simulation execution, supporting the visualization of simulation results, the interactive input of data, and the dynamic modification of parameters during experimentation. Autonomous elements, on the other side, are used to model entities. An autonomous element is an active object [WIL94], i.e., an object with its own execution thread and a message queue. Autonomous elements may interact with other autonomous and interface elements only through message passing. The model does not support shared variables, so that it may be also used in distributed environments. Messages have an identifier which is unique only in the context of the class where it is defined. There is no previous type checking in message exchange. When an autonomous element receives a message, it only verifies if there is a handling procedure defined for the received identifier. This approach eases the reuse of entities, because no restrictions are imposed on the types of autonomous elements that may communicate with each other. Therefore, each autonomous element may communicate with any other element. Indeed, since all possible relationships between classes of autonomous elements are defined in the so called class diagram, one is able to verify consistency during simulation. Messages sent to a particular entity are queued and served when the entity is available. The concurrent execution of several autonomous elements is synchronized by the simulation clock. Either the way how an entity communicate with others, as well as how its behavior is described, depends on the simulation paradigm which is individually chosen for each entity. The current version of SIMOO allows a combination of the following approaches: event orientation or process orientation for the description of the entity
behavior, and messages or ports for the communication between entities. These approaches may be extended or specialized by inheritance (for more details on the simulation approaches see [COP96]). SIMOO also uses the concepts of meta-classes and meta-objects, specially for visualization. Meta-classes describe the structure of a class while meta-objects concentrate on the individual aspects of each object. By making reflexive all the autonomous elements, we build an structure that considerably ease the interaction between the user and the model during experimentation, while keeping separated two distinct domains: the autonomous elementsÕ behaviors and the degree of interaction they accept. At any given moment, the user may inspect or modify the contents of entity attributes and of the event list, may insert or remove relationships, and may create or destroy entities. Even the entity behavior may be modified during simulation, by replacing the object method which responds to a given message. This functionality is also extended to the interface elements, so that the user may not only configure the kind of information he/she wants to track during experimentation, but also the visual aspect to be associated to this information. This configuration, which may be dynamically modified, can be defined independently from the original model built by the user. Finally, SIMOO contains the usual facilities one expects from simulation environments, such as random number generators, probability distributions, and gathering of statistics. 3. THE MODEL EDITOR TOOL MET (ÒModel Editor ToolÓ) is a tool for building complex simulation models which offers an interactive programming environment, supports the construction of hierarchical, object-oriented models, and stimulates reuse both of code and design. Since the main objective of SIMOO is the generation of executable models, features that are specific to discrete simulation models must be expressed using MET. Among those features, one can highlight the possibility of choosing different modeling paradigms for each entity (ports or messages, processes or events), since this choice impacts the way how we describe the entity behavior and the communication between entities. MET proposes some extensions to those diagrams that are usually proposed by object-oriented methodologies, such as class and behavior diagrams, in order to better handle simulation-related features. In its current version, structural information is depicted graphically in SIMOO by means of a class diagram and an instance diagram. The behavioral model is described by filling pre-defined templates and by generating C++ code for the methods for each object. The executable simulation code is then automatically generated by the editor. 3.1 The Class Diagram In MET a model specification always starts with the definition of the corresponding class diagram. This diagram is similar to those usually employed in object-oriented analysis methodologies. It allows the classification of the several entities that are described in the model, as well as the relationships between these classes. SIMOO, however, extends these diagrams so as to allow the graphical specification of simulation-related aspects. The class diagram of a SIMOO model is built in a hierarchical way. Different hierarchy types may be identified: aggregation, inheritance, and refinement. Classes that are defined at a given level are considered to be components of the upper class which is being detailed.
Figure 2 - Neander class diagram As example, Figure 2 presents the first refinement level of the class diagram of a small, hypothetical processor called Neander. In this diagram we may recognize rectangles identifying classes (such as ALU, MPX, etc.), as well as the relationships between classes. Icons on the right-hand side of a rectangle indicate the simulation paradigm which has been chosen for that particular class. Figure 3 shows the repertory of icons corresponding to the various modeling
approaches available. A rectangle with a thicker margin indicates that the class contains components that are refined in a sub-diagram.
Figure 3 - Simulation Modeling Approaches The class diagram allows the representation of four types of relationships: inheritance, aggregation, acquaintance, and creation. The meaning of these relationship types is based on the usual definitions found in objectoriented methodologies (e.g. [BOO94,GAM95]). Inheritance is a relationship among classes wherein one class shares the structure and/or behavior defined in one or more classes. Aggregation implies that an entity aggregates componentclasses that are Òpart ofÓ the aggregator class. Acquaintance relationships denote that objects of a given class know objects from another class (and in this way they can communicate with each other). This kind of relationship is sometimes called ÒassociationÓ or ÒuseÓ. At last, creation relationships denote the relationship between a class X and the class which generates objects of class X. The arcs corresponding to acquaintance relationships are not directly connected to the classes in the diagram. Connections are done through connection points. These points may be of two different types, messages and ports, depending on the communication approach selected for the entity, and reflect the behavior we expect from the approach they represent. Referenced classes are another facility for building class diagrams. Class declarations are graphically visible only in the context where they are declared. However, any class may be referenced (reused) in different sub-diagrams. When this need arises, a meta-level is created, where the referenced classes are represented. Once defined at this metalevel, a class may be referenced from within any sub-diagram, as it had been declared there. Finally, the editor offers facilities for the creation of libraries of autonomous elements. Any autonomous element of a model may be "exported" at any moment during the model construction. An exported element is stored in a separate place, together with its ancestral classes (classes from which it is derived). Classes in this condition may be "imported" by any other model. The "import" operation checks whether classes already belong to the model, importing only those that are still unknown. In this way, two or more classes that are derived from a common ancestor and have been separately exported may be imported by a same model, but the common ancestor will be loaded only once. 3.2 The Instance Diagram Although it presents some particular features, the class diagram is very similar to those usually found in object-oriented methodologies. However, a special characteristic of SIMOO is that the user must also necessarily create an instance diagram, from which the executable simulation model will be generated. Considering again Figure 2, one can easily recognize that from this single diagram many different processors may be generated. One can for instance vary the number and function of the registers. In order to simulate the model, it is necessary to create a particular processor. This is achieved with an instance diagram. In this diagram, entities of a particular model are specified and their relationships are detailed. Figure 4 shows the instance diagram of the Neander processor, containing one memory, four registers of class REGISTER and one register of class IR, one ALU, etc.
Figure 4 - Neander instance diagram Another aspect reinforcing the need for an instance diagram is the utilization of parameterized classes. In general, sets of classes sharing common attributes, but differing in some aspects, are described by inheritance hierarchies, such as in the case of the hierarchy headed by the class FUNCT_ELEM, in Figure 2. In certain cases, however, the differences do not justify such hierarchy and are more easily modeled by instantiation parameters. The size of a memory and the clock frequency are examples of such parameters, in the example of the Neander processor. The class is described by general parameters in the class diagram, and concrete values must be assigned to these parameters when the class is instantiated in the instance diagram.
Figure 5 - Ambiguous class diagram Finally, there are situations where the class diagram may result in different structures when the instantiation is defined. Figure 5a presents a class diagram where class C1 has a 1-to-2 relationship regarding class C2. The instance diagrams shown in Figures 5b and 5c may be both generated from this same class diagram, but have different structures that are due to different interpretations of the relationship between C1 and C2. The need for an instance diagram is based on the fact that concrete simulation entities correspond to objects, and not to classes. 3.3 Describing Behavior As already mentioned, in the current version of MET the behavior of the classes is described in C++. The window for editing the behavior (see Figure 6) is activated from the class diagram by a double click of the mouse upon the class whose behavior one wants to specify or modify. The window for editing the class behavior contains three forms: Routines, Attributes, and Inherited Routines and Attributes. The Routines form may be seen in Figure 6. It allows the definition of the routine headings (upper left box), the corresponding activation messages (upper right box), and the routine code itself (lower box). In the case of a routine which is not activated by a message, the constant NULL is indicated in the upper right box. The Attributes form support the edition of the attributes that are needed for specifying the class behavior. Finally, the Inherited Routines and Attributes form allows the visualization (but not the modification) of the routines and attributes that are inherited from ancestor classes.
Figure 6 - Behavior editing window 4. CONCLUSIONS AND FUTURE WORK SIMOO is a general-purpose, discrete simulation framework, which explores different modeling approaches, computational reflection, and autonomous entities for building simulation models. The choice of the most adequate modeling approach for each entity of the same model and the use of object orientation considerably increases the reuse of entities. The utilization of autonomous elements besides easing the modeling of real world concurrency allows the execution of the model also in distributed environments. Finally, computational reflection allows a more powerful interaction between user and model and an easier implementation of this interaction.
SIMOO has been applied as a modeling and simulation tool in different applications, varying from processor to manufacturing systems. Such experiences have allowed the validation of its generality and usefulness. Additional work is underway for generating code for the language of autonomous objects AOC++, thus supporting the simulation of systems in real time. An application in this direction will be the construction of "virtual experiments" for the Industrial Automation Laboratory of the Electrical Engineering Department of the UFRGS. In the continuation of this research several aspects are being considered, such as an improvement of the mechanism for distributed simulation, looking for a less conservative approach for the synchronization of entities; extension of the set of modeling paradigms; implementation of persistent objects so as to save and restore the simulation status; control of model versions; and better support for statistical analysis. Bibliography [ARO93] Arons, Henk de Swaan. Object Orientation in Simulation. European Simulation Syposium, SCS, 1993. [ABE93] Abell,Jefferey A., Judd, Robert P. Reusable Simulation Object Specification Through Arbitrary Message Passing and Aggregation Scheme. Object Oriented Simulation, SCS, 1993. [BAE91] Baezner, Dirk; Lomow, Greg. A Tutorial Introduction to Object-Oriented Simulation and Sim++. In: Winter Simulation Conference, Phoenix, Arizona, SCS, 1991. [BAR96] Barcio, B. T., Ramaswamy, S., Macfadzean, R & Barber, K. S. Object Oriented Analysis, Modeling and Simulation of a National Air Defense System. Simulation 66:1, 5-21, USA, 1996. [BIR73] Birtwistle, G. M. - SimulaBegin. Lund Student Littrature, N.Y., 1973. [BOO94] Booch, Grady. Object Oriented Analysis and Design. The Benjamin/Cummings Publish Company, Inc., New York, 1994. [CHA94] Chang, W; Jones, L. R. Message Oriented Discret Event Simulation. Simulation, august 1994, pgs. 96 a 104. [COP96] Copstein, Bernardo; Pereira, Carlos Edardo; Wagner, Flavio R. The Object Oriented Approach and the Event Simulation Paradigms. In: 10th European Simulation Multiconference. SCS, Budapest, Hungary, june 2-6, 1996 [COTA92] Cota, Bruce A.; Sargent, Robert G. A Modification of the Process Interaction Wold View. ACM Transactions on Modeling and Computer Simulation, vol. 2, nro. 2, april 1992, pgs. 109-129. [GAM95] Gamma, Erich; Helm, Richard; Johnson, Ralph e Vlissides, John. Design Patterns - Elements of Reusable Object Oriented SoftwareÓ. Addison Wesley. USA, 1995. [KAM96] Kamigaki, T., Nakamura, N. An Object-Oriented Visual Model_Building and Simulation System for FMS Control. Simulation 67:6, 357-385, USA, 1996. [VAU91] Vaughan, P. W. PRISM: An Object Oriented System Modeling Enviroment in C++. Object Oriented Simulation, SCS, 1991. [WIL94] Wilhelm, Bob. Structural Implications of Concurrent Execution Models for OO Real Time Systems. In: OOPSLAÕ94 - Workshop Proceedings, Portland, october, 1994. [ZHE93] Zheng, Q., Chow, P. A General Purpose Object-Oriented Enviroment for Discret-Event Simulations Obect Oriented Simulation, SCS, 1993.
