5.2.8 Object-Oriented role analysis and modeling (OOram)
OOram (Reenskaug, 1996) is intended to be a generic methodology for software
engineering. The principles advocated can be applied to any area of interest,
and a main idea is that there is no single, ideal method for modeling.
A specialized method must be developed and adapted to each particular organization
A main reason for including OOram in the discussion is their focus on
modeling of the system environment (the "real world") as a part of software
engineering (ibid.:25), using the phrase enterprise modeling explicitly
(ibid.:184). In addition, OOram provides a number of guidelines for practical
OOram is object-oriented. An object has state (i.e., attributes)
providing memory; it has behavior, supporting dynamic aspects; and
it is encapsulated to hide complexity. Objects are structured according
to their interactions (note that object relations are not stressed). Objects
play various roles. A role model is an abstraction of an
object structure. Hence, relationships become important in role models,
and not in object models.
The purposes of enterprise modeling in OOram are development of human
understanding and simulation.
Enterprise models created according to OOram may have a number of views,
with each view presenting certain aspects of a model. The following ten
views are proposed (Reenskaug, 1996:60):
Hence, OOram suggests a varied mix of formal and informal notations and
languages for representing and communicating models. Which view to use
depends upon the needs in a particular situation.
Area of concern view: Textual description of a phenomenon represented
in the role model.
Stimulus-response view: Describes how environment roles may trigger
activities in the organization (stimulus), together with the effect (response).
Role list view: List describing all roles of a role model together
with attributes and textual explanation.
Semantic view: Describes meaning of roles and relationships between
Collaboration view: Describes patterns of roles and message paths.
Interface view: Describes all messages that can be sent along a
Scenario view: Provides a sample sequence of messages flowing between
roles (a concrete example).
Process view: Describes data flow between roles and associated activities
performed by the roles.
State diagram view: For each role, the legal states can be described
together with messages that triggers transitions.
Method specification view: Describes what messages to send for each
method belonging to a role. May also specify procedures to perform.
The OOram process of enterprise modeling adheres to the generic modeling
process (ibid.:184). Reenskaug repeatedly stresses that the suggested method
is a rational presentation of an irrational process, and that iteration
and adaptations are necessary to make practical modeling succeed (ibid.:184):
"We believe that the optimal process is opportunistic: we should
at all times work on the model and the view that offer the best opportunities
to improve our insights."
However, a method can be presented as a rational process:
Finally, one may question whether OOram advocates an objectivistic or a
constructivistic worldview. There are indications of both (but no explicit
discussion): On the objectivistic side, the modeling process is pictured
relatively simplistic concerning the reality that is modeled. OOram speaks
Determine the area of concern.
Describe the bounds of the study in free form prose. The modeler is
advised to reread this description frequently, as he gains more understanding
of the phenomena that are modeled.
Understand the problem and identify the nature of the objects.
Identify the actors in the organization and find the various roles
in the enterprise. A practical advise when communicating with actors is
to use free text and informal diagrams instead of formal notations.
Determine environment roles and stimulus/response.
Among the roles identified previously, there are some that trigger
activities in the organization. These are environment roles.
Identify and understand roles.
Analysis of actors and systems provide a number of roles.
Determine the work processes.
Work processes describe how roles pass products between each other
and carry out activities to produce or manage the products.
Determine the collaboration structure.
Based on the work processes, the modeler may define more elaborate
This step includes specification of all messages a role may send to
"identification of the nature of the objects"
as if objects and their states/behavior are something objectively given
and with an easily identifiable, inherent nature (identification and
construction are fundamentally different words). Team-based modeling
is neither discussed to any significant degree.
On the constructivistic side, there is some evidence in OOram literature
of a view in which the world is perceived subjectively by all actors. When
talking about manifest, or explicit, models (ibid.:34), they claim that
"the interpretation is in the mind of the beholder, and people
may (and will) interpret the same manifest model in different ways..."
In the same discussion, they speak of the need for shared mental models
in communication. But how to effectively arrive at shared models when interpretations
differ are not discussed properly. Another feature consistent with constructivistic
ideas is the notion that any object can play several roles, and that combination
of various models may be done through synthesis. Hence, local realities
may be modeled separately and then combined (as long as similar objects
and interpretations of objects are used). OOram also lends itself well
to description of communication between actors. This is also a main characteristic
of the next approach, SAMPO.