Schedules of Activity in the Swarm Simulation System Position Paper for OOPSLA ‘97 Workshop on OO Behavioral Semantics Roger Burkhart
[email protected] Deere & Company John Deere Road Moline, Illinois 61265
Abstract Behavioral specifications for object-oriented systems require specifying the actions that occur on objects in addition to any specifications for the objects themselves. The actions that trigger operations on objects can often be described better using specifications that are separate from the objects themselves, especially if complex sequences of actions that unfold over time are involved. This paper gives an overview of the variety of activity structures supported by the Swarm Simulation System, with particular attention to the precision of specification required to obtain repeatability of results in models involving large numbers of agents interacting over long periods in complex ways.
1. Introduction The need to specify behavior separate from the objects that participate in the behavior has been widely recognized in object modeling frameworks. Use cases and other forms of scenario-based design introduce behavior as explicit sequences of actions that affect objects, and object interaction diagrams, temporal logic, and pre and post conditions all provide various methods to declare constraints on the permissible sequences of actions. Previous contributions to the OOPSLA/ECOOP workshop series on OO behavioral semantics have described many examples of such specification, with particular attention to issues not always dealt with in classical OO systems, such as collective behavior and multi-object actions [1]. While objects remain extremely attractive as a means by which to organize the state of a business description, a previous contribution by the author [2] identified a series of difficult issues that must still be dealt with in the modeling of realistic business domains. Not least of these is concurrency: there is not just one “behavior” to be specified, but many autonomous behaviors of separate elements within a system, and these cannot always be assumed to define any single, globally consistent state. Moreover, the expected behavior can itself be established or modified as a result of its own execution. To cope with the challenge of expressing the realistic dynamics
-1-
that can occur in a business domain, the previous contribution proposed that an enterprise model should include the ability to build and run complete simulations of the behavior being modeled. Not only could the business perform these simulations as part of its normal operation, but they could be used in an off-line mode to specify behavior that is expected or permitted to occur. This paper describes ongoing work aimed at detailed forms of activity specification that could drive a realistic business simulation. This work is being implemented as part of the Swarm Simulation System [3], which is being developed at the Santa Fe Institute to provide a general-purpose framework for simulating concurrent, distributed artificial worlds. Swarm provides a suite of reusable tools both for building executable forms of simulated worlds and for running these simulations as part of controlled scientific experiments. Applications come from diverse domains ranging from physics to biology to economics, and typically involve large numbers of agents that interact dynamically in the context of a shared environment. The intended support for research on Complex Adaptive Systems [4] creates an especially rich environment in which to consider models of complex behavior. Swarm adopts an object-oriented representation for the state of a world to be modeled, but it balances this representation with an independent representation of the actions to occur on these objects. Like the event-oriented form of a traditional discrete-event simulation system [5], actions may be scheduled to occur at an explicit time, but actions may also be scheduled in which an explicit relative time is omitted. Explicit directives resolve the ordering of actions that are otherwise concurrent, and provide a basis for eventual distribution of the logically concurrent actions across parallel hardware. Remaining sections of this paper discuss selected aspects of the Swarm activity representation from a behavior specification perspective.
2. Object-oriented representation of state Swarm adopts a fairly conventional object-oriented representation of the entities that exist in a modeled world. The type of an object defines the operations that can performed on it, and the state of an object can be observed or changed only by means of these operations. From the point of view of the activity specification, these operations define the primitive action types by which the state of entities within a model may be changed. Once a model is running, the only changes of state that occur are those triggered by an independent representation of activity contained at the same level as the objects themselves. Unlike conventional objects, the type of an object in Swarm can change during its execution. This supports a form of dynamic classification [6] that changes the operations available on an object. Swarm adopts a strict separation of object interface from internal implementation that allows a change of type to be implemented merely by switching the
-2-
class that implements the supported methods. Changing the object type also supports a progressive specification of generic, reusable abstractions by giving them a separate, create-time-only phase, as detailed in a a previous OOPSLA workshop paper [7]. A further feature of the Swarm state representation is that objects are not allocated from a single global heap, but from an explicit container that can itself be allocated as a selfcontained unit within another such container. These containers, called zones, explicitly track the population of objects contained within them. These explicit populations can be searched at runtime to discover objects in the same or different populations, and also support a variety of practical needs including distribution, scaleability, query, debugging, and garbage collection.
3. Schedules of activity Swarm provides an assortment of building blocks for composing the sequences of actions to be triggered on objects within a model. These are called the activity structures of Swarm, and their basic form is an ordered collection of primitive action types. The constituent action types are primitive in the sense that their implementation (and associated specification) is assumed to be already correct. These elemental action types can be combined and sequenced to compose the overall succession of activity to occur within the model. Action types are defined by binding parameters of an available operation (either an operation on one or more objects or a free-standing function) to particular argument values. These bound action types are themselves represented by objects, as are the activity structures that contain them, but within the model they represent not the state of entities in a modeled world but rather events that are to occur during the lifetime of the entities. A schedule of pending events can be built once and then used repeatedly, or it can be built for a single use and then be discarded as soon as all its actions have completed. Schedules can be built and modified dynamically to represent behavior that is determined only at run time. Traversal of schedule structures, and the triggering of their actions on the model, is a built-in capability of the simulation framework. All schedules are executed in some overall merged sequence as a result of their inclusion in some single, top-level executing activity. A simulation model is continuously active; its internal activity need not occur in reaction to any external event from an environment, though such events can be included within a model. Swarm provides a variety of methods for ordering the constituent actions of an activity structure. The simplest, called an action group, is a simple collection of actions that are assumed to all execute either in linear sequence or at the same time. A specification of the actions as concurrent is a declaration that the observable results of the model do not
-3-
depend on the order in which the actions are executed, and further gives license to execute them in parallel if such hardware is available. If the actions are to be executed in linear sequence, the sequence can be either the fixed sequence in which they are contained in the group, or else a sequence built dynamically each time the action group is executed. Time-based activity structures define a mapping from the values of a defined time clock to selected points in the overall sequence of actions to be performed. When a time-based structure is traversed, a time clock is automatically incremented as successive sequence points are completed. The time clock itself is available to any of the objects being scheduled. Within multiple actions that all end up being scheduled at the same time, the sequence of actions can still be specified to be concurrent, sequential, or randomized based on the initial order in which they were scheduled, or it can be defined as any sequence established in a custom way according to actions that are actually present. These “concurrent groups” within a schedule permit an assumption of concurrency to be established as a default, which can then be overridden only if particular interfering actions are present. Beyond the basic sequence constraints of action groups and time-based actions, the specification framework of Swarm allows the assertion of arbritrary ordering constraints on actions that would otherwise be concurrent. All the built-in forms of concurrent, sequential, and time-based scheduling are actually just special, optimized cases of the general form of partial-order specification for the sequences of actions that are permitted to occur.
4. Swarm: a unit of composition for collective behavior A swarm is one of the kinds of activity structures which is executed by the Swarm simulation system. A swarm is defined as a collection of objects together with a schedule of activity over those objects. The schedule of activity within a swarm can itself be composed out of the time- or order-based specifications of any number of other activity structures. When a swarm is executed, it automatically traverses the actions of all its activity structures in such a way that all time- and order-based constraints are satisfied. This includes merging together actions scheduled at the same time to establish any special interpretation of the combinations of actions to be performed. A swarm is always the top-level unit of a Swarm simulation; the top-level swarm includes the population of all objects contained within a model along with the top-level activity structures that trigger actions within the model. Unlike other activity structures, a swarm can also define its own representation of an encapsulated object state. Such a swarm is itself an object, and can have operations that are triggered by other components of the system, even as it triggers internal actions on the objects it contains. Such a
-4-
swarm can be used to represent a cluster of objects that have closely related behavior and that define a unit of emergent behavior within the system. A swarm can be composed out of any arbritrary collection of objects within a model, and the same objects can be contained in any number of swarms. The time value used to traverse time-based schedules is maintained only within a containing swarm. Time values in different swarms are permitted to slip away from strict synchronization during intervals that restrict interaction across swarms. In this way, a swarm can serve as a unit of self-contained computation, in much the same way that a zone serves as a unit of self-contained state. Since a swarm also defines its own population, it serves as a basic unit of both state and activity. The structure of swarms and subswarms is entirely recursive. A common use of nested swarms is to separate the model of a simulated world from an independent model of observation and analysis events to be performed on the model as it runs. The “experimenter’s world” consists of user control and display objects that control an experiment and feed data into it, and that reduce and analyze data as it runs. The swarm that contains the experiment is like a lab bench containing probes and instruments that can be attached to a system under study.
5. Implementation The Swarm activity structures have a dual purpose both for specification and for runtime execution. Swarm activities are processed by a running intepreter that activates them as the virtual machine for an executable model. The two-level structure of activity structures and primitive action types allows an effective tradeoff between interpretation of modifiable specifications against compiled speed. Speed is nearly always a concern in a simulation model because the model runs continuously, often consuming all machine cycles that can be provided. Primitive action types can be implemented directly as compiled methods, while sequencing and selection of actions occur only within the interpreter-level activity structures. Even within the interpreter, the inherent overhead of traversing an activity structure can usually be reduced to little more than double the basic overhead of invoking an object operation. Swarm is implemented using the Objective C extension of the C programming language [8], as implemented in the freely available GNU C compiler. Objective C provides good compiled efficiency while permitting simple construction of the generic action objects that are contained in all activity structures. Swarm is available in a freely distributed release at http://www.santafe.edu/projects/swarm. The current Swarm version implements most of the features described above, but randomized sequences and the fully general form of partial orders mentioned above are still in progress for future releases.
-5-
REFERENCES [1]
Kurki-Suonio, R., Mikkonen, T., “Liberating Object-Oriented Modeling from Programming-Level Abstractions, in ECOOP ‘97 Workshop on Precise Semantics for Object-Oriented Modeling Techniques, Kilov, H., Rumpe, B., eds., Technische Universitaet Muenchen report TUM-I9725, 1997
[2]
Burkhart, R., “Effective Description of Enterprise Processes,” in OOPSLA ‘93 Workshop on Behavioral Semantics in Object-Oriented Information Modeling, Kilov, H., Harvey, W., eds., Institute for Information Management, Robert Morris College, 1993 (available at http://www.santafe.edu/~rmb/oopsla93.html)
[3]
Minar, N., Burkhart, R., Langton, C., Askenazi, M., The Swarm Simulation System: A Toolkit for Building Multi-Agent Systems, Santa Fe Institute Working Paper 96-06-042, Santa Fe, NM, 1996 (available at http://www.santafe.edu/projects/swarm/swarmdoc/swarmdoc.html)
[4]
Holland, J., Hidden Order: How Adaptation Builds Complexity, Helix Books, Addison Wesley, 1995
[5]
Pritsker, A., Pegden, C., Introduction to Simulation and SLAM, Halsted Press, John Wiley and Sons, 1979
[6]
Odell, J., “Dynamic and Multiple Classification,” in Object-Oriented Behavioral Specifications, Kilov, H., Harvey, W., Kluwer Academic Publishers, 1996
[7]
Burkhart, R., “Create-phase Protocols for Object Customization,” Position Paper for OOPSLA ‘95 Adaptable and Adaptive Software Workshop, 1995 (available at http://www.santafe.edu/~rmb/oopsla95.html)
[8]
Object-Oriented Programming and the Objective C Language, Next Software, Inc. Redwood City, CA, 1995
-6-
