Information Technology Reference
In-Depth Information
1.3.1
Object Model
ODP system specifications are expressed in terms of objects. Objects are
representations of the entities we want to model, including physical elements
(mobile phones), human beings (John, the repair centre clerk) or more abstract
entities (a pending repair order). An object contains information and offers
services. In other words, an object is characterized by its state or, dually,
by its behaviour . Depending on the viewpoint and the style of the notation
used, the primary emphasis may be placed either on behaviour or on state.
The use of the object paradigm provides abstraction and encapsula-
tion, two important properties for the specification and design of complex
systems. Abstraction allows highlighting of those aspects of the system rel-
evant from a given perspective, while hiding those of no relevance. Encap-
sulation is the property by which the information contained in an object is
accessible only through interactions at the interfaces supported by the object.
Because objects are encapsulated, there are no hidden side effects outside the
object arising from the interactions. It also implies that the internal details
of an object are hidden from other objects, which is crucial in ensuring the
interchangeability of alternative implementations, and in providing the basis
for dealing with heterogeneity, interoperability and portability.
Behaviour is expressed as a collection of actions. Actions can be anything
that may happen, and can be classified into interactions (which involve
participation from the object's environment) and internal actions (which
take place without such participation). An example of an internal action is
the one that models the sudden breakdown of a mobile phone. Interactions
are used to model, for instance, a customer's request to the PhoneMob clerk to
have his handset repaired, or the act of transferring the data from one phone
memory card to another. Each of the objects involved in an interaction plays
a particular action role characterized by the information it contributes or
accepts and by whether or not it originated the action.
A system is composed of a configuration of interacting objects. Objects
interact at interfaces, which are subsets of their possible interactions with
other objects, together with the set of constraints on when they may occur. An
event is the fact that an action has taken place. When an event occurs, the
information about the action that has happened becomes part of the state of
the system and may thus subsequently be communicated in other interactions.
Such a communication is called an event notification.
The specification of an interaction concentrates on the objects participat-
ing in it. However, in some circumstances, we may want to focus on exactly
where the interaction takes place and how it might be observed. This is done
by introducing the concept of an interaction point , which is concerned with
where, in time and space, the interaction happens. We shall see later, in chap-
ter 8, how this concept leads to the more specific ideas of reference point
and conformance point when we are concerned with ensuring that some
interactions are observable during testing.
