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

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

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):

  1. Area of concern view: Textual description of a phenomenon represented in the role model.
  2. Stimulus-response view: Describes how environment roles may trigger activities in the organization (stimulus), together with the effect (response).
  3. Role list view: List describing all roles of a role model together with attributes and textual explanation.
  4. Semantic view: Describes meaning of roles and relationships between roles.
  5. Collaboration view: Describes patterns of roles and message paths.
  6. Interface view: Describes all messages that can be sent along a message path.
  7. Scenario view: Provides a sample sequence of messages flowing between roles (a concrete example).
  8. Process view: Describes data flow between roles and associated activities performed by the roles.
  9. State diagram view: For each role, the legal states can be described together with messages that triggers transitions.
  10. Method specification view: Describes what messages to send for each method belonging to a role. May also specify procedures to perform.
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.

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:
  1. Determine the area of concern.

    2. 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.
  2. Understand the problem and identify the nature of the objects.

    3. 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.
  3. Determine environment roles and stimulus/response.

    4. Among the roles identified previously, there are some that trigger activities in the organization. These are environment roles.
  4. Identify and understand roles.

    5. Analysis of actors and systems provide a number of roles.
  5. Determine the work processes.

    6. Work processes describe how roles pass products between each other and carry out activities to produce or manage the products.
  6. Determine the collaboration structure.

    7. Based on the work processes, the modeler may define more elaborate collaboration diagrams.
  7. Determine interfaces.

    8. This step includes specification of all messages a role may send to a collaborator.
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 of
"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.