Proceedings of the Huntsville Simulation Conference 2007, October 30November 1, 2007, Huntsville, Alabama
A General Model of Resources Using the Unified Modeling Language
Charles M. Jenkins and Stephen V. Rice The University of Mississippi jenkins@cs.olemiss.edu, rice@cs.olemiss.edu
Keywords: resources, resource modeling, UML
Abstract Models of resources are required in many simulations. We propose a general model in which resources are represented as active and engaging. Equal consideration is given to client and server, as they negotiate and exercise contracts with one another. A registry facilitates the discovery of resources. This model is presented using the Unified Modeling Language (UML).
1. INTRODUCTION Resource modeling is an essential component of many simulations. Yet many simulations portray resources (servers, suppliers, etc.) as passive entities, little more than names for stations through which active and more interesting customers or machine parts pass. GPSS/H facilities and SIMSCRIPT II.5 resources, for example, wait quietly for client entities to arrive, provide service for awhile, and then cease activity. While customers may balk or jockey, servers have no choice but to serve as demanded for as long as demanded. They exercise no judgment. They do not learn, nor do they weary. A few simulation programming languages, such as SIMAN V, permit servers to fail [Banks et al. 1995]. This onesided treatment of the players in a simulation gives the client responsibility for decisionmaking in the simulation and glosses over or minimizes important attributes and behaviors of the servers. We assert a need for more balanced and realistic representations. Resources drawn from different domains exhibit a variety of properties and behaviors. At the same time, they have much in common, and we have proposed a typology, or multidimensional categorization, of resource properties [Jenkins and Rice 2007]. This typology, depicted in Table 1, describes resources based on who they are (their existence characteristics), when they provide their services (their availability), what they do and how well they do it (their utility), and how they do what they do (their implementation). Existence properties include how a resource may be identified (perhaps a name or a serial number), where and when it came into being, and what other resources it contains. A farmer markets wheat of a particular strain, harvested from a certain field at a particular time. A battle Table 1: Resource Typology Category SubCategories Existence Identity, Origin, Living, Consumption, Makeup, Traits Availability Status, Location, Schedule, Delivery Mode, Failure Mode, Selectivity, Exclu- sivity Utility Competencies, Size, Performance (De- liverability, Reliability, Effectiveness, Efficiency, Cost, Quality), Cognition Implementation Adaptability, Activity, Interactivity, Autonomy, Coupling, Isolation, Discov- erability, Composition, Centralization, Mobility, Forgetfulness, Preemptibility, Standardization, Risk, Policy
tank manufactured by a particular defense contractor at a particular facility carries a unique serial number. Availability considers a resources location, its readiness to serve, and how it fails. The farmers wheat resides in a particular silo, ready for shipment, but may mold or become infested with insects. The tank may be at precise coordinates on a battlefield or under repair for battle damage. Utility encompasses a resources competencies, the amount of service it can provide, and various measures of its performance. The farmers thousand bushels of wheat may be fit for grinding into flour or only for mixing with animal feed. The tank travels at 45 miles per hour and accurately fires up to 40 rounds of projectiles at a range of 4,000 m without restocking. Implementation considers centralization of service, interactivity, standardization, composition, and statelessness. Wheat in a silo occupies a central location, but a large flour milling company may have stocks of wheat throughout the country. A tank interacts with friendly forces through standardized commandandcontrol systems. It carries a smoothbore cannon and machine guns of different calibers, and it forgets an old target while firing at a new one. This typology arose from our interest in designing customizable, reusable resource libraries for SIMSCRIPT III, a recentlyreleased, objectoriented update to the venerable SIMSCRIPT II.5 simulation language [Rice et al. 2005]. We knew that, to provide generally useful models, we had to consider the properties of resources in many areas of interest. In this paper, we report further progress in developing an expressive general model for resources that balances the treatment of clients and servers. In fact, we have dropped the distinction between clients and servers we consider a resource to be any (potentially) active entity in a simulation that has something of value to offer another resource. As supply chain managers know, whether a resource should be labeled as client or server depends on where one fits in the chain. The wheat farmer needs the flour mill as much as the flour mill needs the farmer. This work describes what might be called the dance among resources as they search for, negotiate contracts with, and ultimately exchange services with each other. We present this model of resources using version 2 of the Unified Modeling Language (UML) [Object Management Group, 2007]. Recent Winter Simulation Conferences have seen much discussion of standardizing the documentation and modeling of discrete event simulations. Robinson [2006] provided a thoughtful discussion of the present and future of conceptual modeling, including the need for better approaches for designing and documenting conceptual models. Richter and Mrz [2000] extolled the benefits of the UML, including language independence, objectorientation, visualization, and identification of reusable components. Anagnostopoulos and Dalakas [2005] applied RTUML, extensions to the UML for realtime applications, to faster thanrealtime simulations. Daum and Sargent [2002] used hierarchical control flow graphs to design their model and eXtended Markup Language (XML) to express it. Rhl [2006] used XML to specify model components and UML to express the behavior of the compositions. Chatfield, Harrison, and Hayya [2004] used XML to describe supply chains so that SILK simulation constructs may be created automatically. Others have employed the Web Ontology Language [Lacy 2004], event graphs [LeowSehwail 2005], control flow graphs [Sargent 2004], resource graphs [Hyden and Schruben 2001], and the techniques of knowledge representation [Zhou and Son 2004]. Like the work just cited, our efforts emphasize the use of a wellknown software engineering tool, the UML, for its benefits both in modeling and in documentation. Much of the work cited, however, involves single domains, active clients, and passive servers. Our work investigates the question, Is it possible to construct simulations that permit use in application domains with widely ranging objectives? [Rioux and Nance 2002]. Steele et al. [2002] demonstrated the utility of a generic simulation model in a single domain, modeling reusable launch vehicles. We seek to create an abstract, objectoriented model of resources that provides an intuitive architecture applicable to many domains.
2. GENERAL MODEL OF RESOURCES Our model revolves around three key entities: Resource, Contract, and Registry. First, Resource represents any potentially active entity that offers something of value to another entity (another Resource). A Resource may be composed of other Resources, and the something of value that a Resource offers is itself a Resource. Not every Resource must be active. A wheat farmer, for example, may actively market his crop (a wheat Resource), whereas the wheat itself is passive. Second, Contract represents a relationship between two Resources, in which each agrees to provide the other with a desirable Resource. Once accepted, a Contract becomes a Resource that may be exercised at a specified time or under specified conditions to gain the obligated Resource. Not every relationship among Resources, however, requires the machinery of a Contract. The wheat farmer and the flour mill must be able to contract a price for the wheat, but the farmer Resource may simply possess (contain) the wheat Resource, and the flour mill Resource may simply possess the cash with which it purchases the wheat. Finally, Registry represents a meansanother Resourcethrough which a Resource advertises its willingness to offer something of value and through which a Resource can seek a partner for Contract negotiations. A Registry may be as simple as a telephone book or as complicated as a commandandcontrol center through which battle tanks remain in touch with the officers orchestrating movements on the battlefield.
2.1. Dynamic Model We begin detailing the behaviors and interactions of these entities by creating use cases. In the UML, we apply use cases to capture the intended behavior of the system without having to specify how that behavior is implemented [Booch et al., 2005]. A single use case details a particular behavior and the actors that participate in that behavior. A use case diagram assembles related use cases to describe their context. Each behavior appears inside an oval, and the actors appear as stick figures connected by lines to the use cases in which they participate. A text description explains both the normal and exceptional or alternative flows of events. Ignoring for now how two Resources identify each other as attractive dance partners, we identify four fundamental steps in their dance. First, they may attempt to negotiate a Contract involving an exchange of Competences, the useful things they can do. Second, if these negotiations prove fruitful, they may accept the Contract, that is, put it in force by committing themselves to uphold their promises. Third, they may eventually exercise the Contract according to its negotiated terms. Finally, they may terminate the Contract by mutual agreement or after fully exercising its provisions. The Contract Use Case Diagram of Figure 1 depicts these interactions between First Party and Second Party, two examples of a specialized Resource called a Contractor. Figure 2 provides the normal flow of events associated with the Negotiate Contract use case, and Figure 3 lists one of the alternate flows of events possible in this use case.
Figure 1. Contract Use Case Diagram
1. First Party prepares an offer to provide some amount of one of its Competences in exchange for some amount of another Competence. 2. First Party delivers the offer to Second Party. 3. Second Party evaluates the offer and prepares a counteroffer involving the same Competences. 4. Second Party delivers the counteroffer to First Party. 5. First Party accepts the counteroffer. 6. First Party or Second Party prepares a Contract. 7. Progress may continue with the Accept Contract use case. Figure 2. Normal flow of events for the Negotiate Contract Use Case
This flow of events begins in step 3 of the Normal Flow of Events. 3. Second Party rejects the offer. 4. Second Party notifies First Party of its rejection, and the use case ends. Figure 3. An alternative flow of events for the Negotiate Contract Use Case
Turning our attention to the process whereby two Resources discover each other, we consider the interactions between Resources and Registries. A Resource may request registration with a Registry and then advertise specific Competences with that Registry. It can also seek partners for contract negotiations by requesting a list of other registered Resources capable of supplying a particular Competence. As its circumstances change, a Resource can add new competencies, remove old ones, or even cancel its registration. Besides responding to actions initiated by a Resource, a Registry may drop a Resources registration altogether or drop just a Competence it no longer wishes to advertise. The Registry Use Case Diagram of Figure 4 depicts these interactions between a Contractor and a Registry.
Figure 4. Registry Use Case Diagram
We next construct sequence diagrams to explore more fully the various flows of events. In the UML, a sequence diagram depicts the messages that pass between prototypical objects as they interact with each other. Time advances from top to bottom, without explicit scale, and each participating object has a lifeline depicted by a vertical rectangle extending through all or part of the diagram. Objects interact by sending messages, shown as labeled arrows from the sender to the receiver. Sequence diagrams, therefore, highlight not only messages exchanged, but also the time ordering of these messages [Booch et al., 2005]. Figure 5 shows the messages exchanged during the normal flow of events for the Negotiate Contract use case. First Party initiates the process by preparing an offer (via the prepareoffer selfmessage). First Party then sends this offer to Second Party via a consideroffer message. Upon receipt of this message, Second Party evaluates the offer (via the evaluateoffer selfmessage), prepares a response (via the preparecounteroffer selfmessage), and supplies this response to First Party. First Party similarly evaluates the response and accepts it, constructs a Contract, and records each partys commitment in the Contract. (Because only one Contract appears in this diagram, it is unnamed.) The diagram illustrates the symmetry in behavior of the two Contractors. A sequence diagram for the alternate flow in Figure 3 would effectively end with Second Partys evaluateoffer selfmessage.
Figure 5. Negotiate Contract Sequence Diagram
Figure 6. Accept Contract Sequence Diagram Figure 6 depicts the normal flow of events for the Accept Contract use case. First Party sends the Contract from the Negotiate Contract use case a setinforce message. The Contract, which knows of each partys commitments, instructs each one to accept the Contract. In response, each party verifies that it can still meet its commitments, that is, that it still possesses the promised Resources. The party then removes the obligated Resources from and adds the Contract to its list of Resources, a simple bit of bookkeeping that makes the obligated Resources unavailable for further negotiations. Finally, the Contract indeed sets itself in force. As in the Negotiate Contract sequence diagram, the Accept Contract sequence diagram emphasizes the symmetry in behavior of the two parties.
Figure 7. Exercise Contract Sequence Diagram
Figure 7 illustrates the normal flow of events for the Exercise Contract use case. First Party initiates the process by recovering its stored Contract resource, to which it sends an exercise message. The Contract then enforces its terms by instructing each party to accept delivery of the Resource to which it is entitled. Each party adds the new Resource to its list of Resources, and the Contract marks itself as fulfilled. The state diagram in Figure 8 depicts a state machine, a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its response to those events [Booch et al., 2005]. State machines predate the UML. This state diagram illustrates most of the resource statuses we identified in our typology and demonstrates how complicated the life of a Resource may be. Many transitions could be addedfor example, an idle Resource can fail and a busy Resource can be preempted by another client. We could add many substates. For example, a Resource may be inactive because it is starved, blocked, or deadlocked. Truly describing the behavior and status of Resource requires careful analysis and documentation of these states and transitions.
Figure 8. Resource Status Diagram
2.2. Static Model The class diagram in Figure 9 shows the most important classes involved in the Contract and Registry use cases. The abstract Resource class and concrete Consumable and Composite classes fit the Composite software design pattern [Gamma et al., 1995]. The open arrowheads depict inheritance, and the open diamond between Resource and Composite indicates aggregation.
Figure 9. Resource Class Diagram
Figure 10 lists attributes and behaviors of the three most important classes in the model. Accessors and mutators have been omitted to simplify the presentation.
Figure 10. Resource, Contract, and Registry classes
Consider again the resource statuses of Figure 8. These statuses can be represented by a collection of Boolean flags with names such as busy, active, and failed, but this approach presents three problems. First, any code that mutates the status of a Resource must maintain consistency among the flags. Second, adding new statuses requires extending and modifying this brittle consistency logic. Third, the operations of a Resource must ensure that the Resource responds to events in a manner compatible with its current state. To address these problems, we have modeled ResourceStatus as a class according to the State software design pattern [Gamma et al., 1995], and we have constructed a hierarchy of status classes. A Resource maintains a reference to its current status object and delegates to that object responsibility for any status dependent behavior. Besides implementing appropriate logic, the current ResourceStatus object also manages the state transitions of Figure 8 by providing the Resource a new ResourceStatus reference. Figure 11 shows part of the ResourceStatus hierarchy.
Figure 11. Partial ResourceStatus class hierarchy
Figure 10 shows that, in addition to ResourceStatus, Resource refers to other objects such as Competence and Measurement. In brief, a Competence encapsulates the enumerated or titular services provided by a Resource. Measurement provides an abstract way of quantifying, for example, the size and performance level of a Resource. A ResourceStrategy permits a Resource, in keeping with the Strategy design pattern [Gamma et al., 1995], to change its algorithms on the fly. In addition, a Resource may implement interfaces that enable it to have other attributes (such as a Location and an Origin). For example, by implementing the ILocatable interface, a Resource gains a Location, an abstraction of the many ways the position of a Resource can be specified longitude, street address, URL, and so forth. By implementing the IOriginating interface, a Resource gains an Origin, a class whose subclasses have names such as BiologicalOrigin, FinancialOrigin, MaterialOrigin, and ManufacturingOrigin. The attributes of these classes carry the traits (e.g., date of birth and place of manufacturer) of a Resource.
3. CONCLUSION Many resources, including clients and servers, actively engage each other in an interesting and complicated dance involving discovery, negotiation, contracting, and service. A domainindependent model of the dance partners and their steps, such as we have presented in this paper, is a starting point. The modeler in a simulation exercise may customize it where necessary and ignore irrelevant properties and behaviors. Modelers in a selected area, furthermore, may extend the abstract model into their own domain, leaving the details of a particular model to be fleshed out later. The simulations built upon such a common architecture should be easier to understand and to compose into new and larger simulations. We plan to develop the model further so that it better captures the properties spanned by our resource typology. As we move forward, we shall prove and refine the abstract model by developing prototype simulation models in objectoriented languages such as Java and SIMSCRIPT III. We envision an integrated process, fully supported by software tools, with which a simulationist can profile a resource using the typology, identify the properties relevant to the simulation at hand, identify the behaviors of interest, select the objectoriented model components necessary to represent those properties and behaviors, and then customize these components as necessary for the final simulation product.
4. REFERENCES
Anagnostopoulos, D., and V. Dalakas. 2005. Introducing a UML model for fasterthanrealtime simulation. In Proceedings of the 2005 Winter Simulation Conference, ed. M. E. Kuhl, N. M. Steiger, F. B. Armstrong, and J. A. Joines, 307316. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Banks, J., B. Burnette, H. Kozloski, and J. Rose. 1995. Introduction to SIMAN V and CINEMA V. New York: John Wiley & Sons. Booch, G., J. Rumbaugh, and I. Jacobson. 2005. The unified modeling language user guide. 2nd ed. Upper Saddle River, New Jersey: AddisonWesley. Chatfield, D. C., T. P. Harrison, and J. C. Hayya. 2004. XMLbased supply chain simulation modeling. In Proceedings of the 2004 Winter Simulation Conference, ed. R. G. Ingalls, M. D. Rossetti, J. S. Smith, and B. A. Peters, 14851493. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Daum, T. S., and R. G. Sargent. 2002. A webready HiMASS: Facilitating collaborative, reusable, and distributed modeling and execution of simulation models with XML. In Proceedings of the 2002 Winter Simulation Conference, ed. E. Ycesan, C.H. Chen, J. L. Snowdon, and J. M. Charnes, 634640. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. Design patterns: Elements of reusable objectoriented software. Boston: AddisonWesley. Hyden, P., and L. Schruben. 2001. Resource graphs for modeling largescale, highly congested systems. In Proceedings of the 2001 Winter Simulation Conference, ed. B. A. Peters, J. S. Smith, D. J. Medeiros, and M. W. Rohrer, 523529. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Jenkins, C. M., and S. V. Rice. 2007. A typology for resource profiling and modeling. In Proceedings of the 40th Annual Simulation Symposium, 194203. Los Alamitos, California: IEEE Computer Society. Lacy, L. 2004. Potential modeling and simulation applications of the web ontology language OWL. In Proceedings of the 2004 Winter Simulation Conference, ed. R. G. Ingalls, M. D. Rossetti, J. S. Smith, and B. A. Peters, 265270. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. LeowSehwail, Y.P. 2005. Qualitative discrete event simulation. In Proceedings of the 2005 Winter Simulation Conference, ed. M. E. Kuhl, N. M. Steiger, F. B. Armstrong, and J. A. Joines, 648653. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Object Management Group, Unified Modeling Language: Superstructure, Version 2.1.1, http://www.omg.org/docs/formal/07-02-05.pdf, referenced 14 July 2007. Rice, S. V., A. Marjanski, H. M. Markowitz, and S. M. Bailey. 2005. The SIMSCRIPT III programming language for modular objectoriented simulation. In Proceedings of the 2005 Winter Simulation Conference, ed. M. E. Kuhl, N. M. Steiger, F. B. Armstrong, and J. A. Joines, 621630. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Richter, H., and L. Mrz. 2000. Toward a standard process: The use of UML for designing simulation models. In Proceedings of the 2000 Winter Simulation Conference, ed. J. A. Joines, R. R. Baron, K. Kang, and P. A. Fishwick, 394398. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Rioux, G. P., and R. E. Nance. 2002. Generalizing: Is it possible to create allpurpose simulations? In Proceedings of the 2002 Winter Simulation Conference, ed. E. Ycesan, C.H. Chen, J. L. Snowdon, and J. M. Charnes, 327335. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Robinson, S. 2006. Conceptual modeling for simulation: Issues and research requirements. In Proceedings of the 2006 Winter Simulation Conference, ed. L. F. Perrone, F. P. Wieland, J. Liu, B. G. Lawson, D. M. Nicol, and R. M. Fujimoto, 792800. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Rhl, M. 2006. Composing simulations from XML specified model components. In Proceedings of the 2006 Winter Simulation Conference, ed. L. F. Perrone, F. P. Wieland, J. Liu, B. G. Lawson, D. M. Nicol, and R. M. Fujimoto, 10831090. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Sargent, R. G. 2004. Some recent advances in the process world view. In Proceedings of the 2004 Winter Simulation Conference, ed. R. G. Ingalls, M. D. Rossetti, J. S. Smith, and B. A. Peters, 293299. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Steele, M. J., M. Mollaghasemi, G. Rabadi, and G. Cates. 2002. Generic simulation models of reusable launch vehicles. In Proceedings of the 2002 Winter Simulation Conference, ed. E. Ycesan, C.H. Chen, J. L. Snowdon, and J. M. Charnes, 747753. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc. Zhou, M., and Y. J. Son. 2004. Knowledge representation for conceptual simulation modeling. In Proceedings of the 2004 Winter Simulation Conference, ed. R. G. Ingalls, M. D. Rossetti, J. S. Smith, and B. A. Peters, 450458. Piscataway, New Jersey: Institute of Electrical and Electronics Engineers, Inc.
Biographies
Charles M. Jenkins is a Ph.D. student and instructor in the Department of Computer and Information Science at the University of Mississippi. He worked in the petroleum industry in drilling operations, engineering, and computing for many years before returning to academia to teach and earn a doctorate. His research interests include simulation and software engineering. His web page can be found via <www.cs.olemiss.edu/~cmj>. Stephen V. Rice is an assistant professor in the Department of Computer and Information Science at the University of Mississippi. He is the lead designer of the SIMSCRIPT III extensions to SIMSCRIPT II.5. In the late 1980s, he co invented the MODSIM objectoriented simulation programming language and wrote the first MODSIM compiler. His research interests also include pattern recognition and audio retrieval. His web page can be found via <www.cs.olemiss.edu/~rice>.
Praveen Kumar, Mike Folk, Momcilo Markus, Jay C. Alameda - Hydroinformatics - Data Integrative Approaches in Computation, Analysis, and Modeling-CRC Press (2005)