In some cases, an object is dependent upon a specific event occurring in another object. If the event is taking place
within a boundary or control object, this object simply informs the other object about what has happened. But if the
event is taking place within an entity object, the situation is somewhat different. An entity object may not be able to
inform other objects about anything if it is not specifically asked to do so.
Assume that a system has been modeled with the possibility of withdrawing money from a bank account via transferals. If
an attempted withdrawal causes a negative balance in the account, a notice must immediately be written and sent to the
customer. The account, which is modeled as an entity object, should not be concerned with whether the customer is
notified or not. Instead, a boundary object should notify the customer.
In the example above, the boundary object would have to pose the question "has the event I am waiting for happened?"
repeatedly to the entity object. To make the situation clearer, and to postpone the implementation details until the
design phase, there is a special association used to express this, namely the subscribe-association.
The subscribe-association, which associates an object of any type with an entity object, expresses that the associating
object will be informed when a particular event takes place in the entity object. We recommend that you use the
association only to associate entity objects, since it is the passive nature of the entity objects that causes the need
for the association. Interface- and control objects, on the other hand, are both allowed to initiate communication.
Therefore, they do not need to be "subscribed to", but can perform their responsibilities in other ways.
The subscribe-association associates an object of any type with an entity object. The associating object will be
informed when a particular event takes place in the associated entity object.
Note that the direction of the association shows that only the subscribing object is aware of the relation between the
two objects. The description of the subscription is entirely within the subscribing object. The associated entity
object, in turn, is defined in the usual way without considering that other objects might be interested in its task.
This also implies that a subscribing object can be added to, or removed from, the model without changing the object it
The subscribe-association is assigned a multiplicity that indicates how many instances of the targeted object the
associating object can associate simultaneously. Then one or more conditions are described on the association, which
indicate what must occur in order for the associating object to be informed. The event might be a change in an
association's or attribute's value, or (some part of) the evaluation of an operation. When the event takes place, the
subscribing object will be informed that something has happened. Note that no information concerning any result of the
event is transmitted, only the fact that the event has happened. If the associating object is interested in the
resulting state of the entity object after the event, it will have to interact with the entity object in the ordinary
way. This means that it will need a link to it as well.
In the Depot-Handling System, spot checks must be made on pallets, to gauge their life expectancy. Therefore, upon
every hundredth move of a pallet from one place in the depot to another, the pallet is checked at a special testing
station. This is modeled by a subscribe-association from the control class Pallet Spot Checker to the entity class
Pallet. Each instance of Pallet counts the number of times it is moved, using a counter attribute. When it has been
moved a hundred times the Pallet Spot Checker is informed due to the condition of the subscribe-association. The Pallet
Spot Checker then creates a special Task, which transports the pallet to the testing station. The Pallet Spot Checker
does not need any link to Pallet, but must have one to Task in order to initiate it.
After a pallet has been moved a hundred times, the Pallet Spot Checker creates a new Task.
The conditions of the subscribe-association should be expressed in terms of abstract characteristics, rather than in
terms of its specific attributes or operations. In this way, the associating object is kept independent of the contents
of the associated entity object, which may well change.
The subscribe-association does not always associate two object instances. It is also valid from a class to an instance,
a meta relation. This is described in subsections below. There are also cases where the class of an object is
associated by a subscribe-association, for example if the particular event happens to be the instantiation of the
Sometimes, it is necessary for a boundary object to be informed if an event takes place in an entity object. This calls
for a subscribe-association.
Consider a withdrawal from a bank account by means of transferals. Here, it is the control object Transferal Handler
that performs operations on the entity object Account. If the balance of Account turns negative, the customer will be
sent a notice prepared by the boundary object Notice Writer. This object has, therefore, a subscribe-association
to Account. The stated condition is that the balance goes below zero. As soon as that event takes place, Notice Writer
is informed. This particular subscribe-association is an instance association, inasmuch as an instance of Notice
Writer is constantly on the look-out for overdrafts in instances of Account.
If the customer is not to receive any more information than that his balance is low, then this is sufficient. But if he
should also be told how low, then Notice Writer must perform an operation on Account to learn the exact amount.
To do this, Notice Writer must have a link to Account.
The boundary class Notice Writer subscribe to the event of the balance falling below a certain level in the entity
object Account. If Notice Writer also needs to know the exact sum of the deficit, it must have a link to Account.
An example of a meta-association from a boundary class is when an event in an entity object causes a new window to be
presented to the user. Then an interface-object class subscribes to instances of the entity object.
In a system handling a network there are stations that function as nodes in the network, and there are lines
interconnecting them. Each station is connected to other stations via a number of lines. The capacity of a station is
determined by how many of its lines are functioning. If over 80% of them are functioning the capacity of the station is
high, if less than 20 % are functioning it is low, and anything in between is medium. In our model of the system, we
have two entity objects, Station and Line, where Station has a subscribe-association to Line. The condition of
the association is that Station should be informed when the status of Line, which may be enabled or disabled, is
Furthermore, a control object that subscribes to Station will be informed if the capacity of the station becomes low.
This is described below, where this example is continued.
A Station instance is informed as soon as the status of one of its instances of Line is changed.
A subscribe-association between entity classes is almost always an instance association, since what is involved,
usually, is already-existing instances. However, there may be cases where an instance of the subscribing entity object
is created when the specified event takes place in the associated entity object. In such cases, the association goes
from a class to an instance, i.e., it is a meta association. One can also imagine that an instance of a particular
entity object would like to know when a new instance of another entity object is created.
In the example above, the entity object Station has a subscribe-association to the entity object Line. Thus,
Station will be informed each time the status of a Line instance is changed. Such a change of status will change the
capacity of the Station. If the capacity becomes low, i.e., less than 20% of its lines are functioning, the system must
find suitable new ways through the network so that this station is avoided. This, of course, is no task for Station,
but must be performed by the control object Station Supervisor, which has a subscribe-association to each instance of
The control object Station Supervisor subscribes to the entity object Station, which in turn subscribes to the entity
Most often, a subscribe-association from a control object will be from a class to an instance, or vice versa,
i.e., a meta association. Usually, the instance of the control object that will deal with the event in the entity
object is not created until the event actually takes place. But one can also imagine, for example, that an instance of
a control object would like to know when a new instance of a certain entity object is created. Thus, in some few cases
the subscribe-association may be an instance association.
In the example above, the subscribe-association from Station Supervisor to Station has the characteristics of a
meta association, i.e., it is the class Station Supervisor that is informed when the capacity of the Station has run
low. When Station Supervisor receives this message, it creates an instance which deals with the event.