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>.