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.
Example
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 subscribes to.
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.
Example
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 class.
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.
Example
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.
Example
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 changed.
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.
Example
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 Station.
The control object Station Supervisor subscribes to the entity object Station, which in turn subscribes to
the entity object Line.
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.
Example
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.
|