The model creation process and its deliverables2
2.5 Basic OOram role modeling concepts and notation
In a nutshell
OOram role model analysis helps the developer master object structures of any size. The object structure may exist. The purpose is then to understand it. Alternatively, the purpose may be to design a new object structure. The objects are then imaginary. In both cases, the OOram approach is to identify different concerns which are represented in the object structure and to create idealized object models, called role models, which focus on the selected area of concern and ignores everything else.
The essence of role modeling is that we always consider objects in context. An isolated object cannot do anything because a message must have both a sender and a receiver. It is only when we consider structures of collaborating objects that we can study cause and effect; and that we can reason about the suitability and correctness of the objects and their structure.
2.5.1 The Object
We have defined objects as being encapsulated. This is illustrated in figure 2.22. It means that we can observe some of its properties when we observe it from outside the object; while other properties can only be seen from inside.
External and internal observation Messages Attributes Encapsulation hides inside properties Methods Instance variables State Object Figure 2.22 External and internal object properties
2.5 Basic OOram role modeling concepts and notation 29 March 1995 23:05
External object properties
Observed from the outside, objects appear as indivisible atoms. Each object has its own unique identity, and is characterized by its behavior and attributes.
The behavior of the object is characterized by the messages it can receive, and also by the messages it can send to other objects. Many different message semantics have been proposed. Our selection is adopted from the Object Management Group in [CORBA 91]:
Messages
Synchronous. Only one object can be active at any time, and the
sender's actions continue only after the receiver's actions are completed. The receiver may return a result to the sender. 1.
2. Synchronous deferred. The sender object must be ready to send a
message and the receiver object must be ready to receive it before it can be transferred. The sender and receiver objects are
synchronized at the time of message transfer. The sender's actions continue after the receiver has accepted the message. A return value could confirm the receipt of the message.
3. Asynchronous. The sender can transmit a message at any time,
and the sender's actions continue immediately. The receiver manages a queue of incoming messages, and may need to wait for an acceptable message to arrive in the input queue. A return value to the sender could confirm that the message has been put into the receiver's input queue.
An Interface is a set of messages
The number of different messages understood by an object may be very large, and we find it convenient to group them: an OOram
interface is a named set of messages, or more precisely: message
types. This use of the term conforms with [CORBA 91], but some professionals use the term interface to denote signals going in both directions, i.e., both messages sent and received. The OOram
technology uses two interfaces to describe this: one for messages sent and another for messages received.
A role model consisting of at least two roles is needed to describe the object interaction in space and time.
2.5 Basic OOram role modeling concepts and notation 29 March 1995 23:05
An object may store information. To the outside observer, this information is described by the object's named attributes. Attributes are virtual in the sense that they do not say anything about how the object represents the information internally in the instance variables described below.
Attributes
Attributes are only visible to the outside observer through messages whose behavior depend on the current value of one or more attributes. (Usually, but not always, through a value returned from the receiving object.)
Internal object properties
As seen from the inside, the object realization is described by its
methods, its instance variables and its state.
A method defines the action taken by an object when receiving a message. The method may cause the object to send messages to one or more of its collaborator objects, it can create new objects, and it may have the side effect of causing a change to one or more of the object's instance variables.
Methods
The distinction between message and method is essential because it permits different objects to handle the same message with different methods; each object can "do the right thing" when they receive a message. This feature of object orientation is variously called
polymorphism and late binding in the literature.
The fancy names are unimportant, the ability to hide the details of an operation inside an object is essential. For example, different
graphical objects can respond to a display-command according to their individual characteristics; different bank account objects can compute accumulated interest according to the nature of the account; different TravelAuthorizer persons can follow different rules when they determine their response to a travel permission request.
Instance variables The instance variables represent attribute information. An instance
variable may hold the value of an attribute directly, or the object may have a method that enables it to compute the value of an attribute from the values of one or more instance variables.
2.5 Basic OOram role modeling concepts and notation 29 March 1995 23:05
Role Modeling ©Taskon 1992. Page 92
The distinction between attribute and instance variable is essential because it permits the analyst to think in terms of information without considering its representation. The attribute could for example be a person's age, the instance variable could hold the person's birth date so that the object could compute the age whenever needed. The object could even delegate the responsibility for maintaining the information to some other object; an instance variable could hold a reference to the other object and a method could know how to retrieve the required information from it. This possibility will be discussed in depth in section 3.2.1: Aggregation: Linking models on different levels of
abstraction.
The internal conditions of an object which affect the object's behavior are abstracted into the object's possible states, where a state
determines which messages the object is ready to receive and how it will process them. When the object receives a message, it performs an
action depending on the current state, and enters a next state which
may be different from the current state.
State
If the actions taken when the object receives a message are different in different states, the corresponding method will be a composite with different action branches for the different states.
Some practitioners use the terms instance variable and state
interchangeably. We find it useful to distinguish between these two terms in order to cater to the relatively few situations where it is necessary to study objects with state dependent behavior. More details in section 6.3: State Diagram view.