Guidelines: Subscribes-Association
Explanation 
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 subscribes-association.
The subscribes-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 subscribes-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 activity. This also implies that a subscribing object can be added to, or removed from, the model without changing the object it subscribes to.
The subscribes-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 subscribes-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 subscribes-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 have been moved a hundred times, the Pallet Spot Checker creates a new Task.
The conditions of the subscribes-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 subscribes-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 subscribes-association, for example if the particular event happens to be the instantiation of the class.
Usage
Subscribes-associations from
Boundary Classes
Sometimes, it is necessary for a boundary object to be informed if an event takes place in an entity object. This calls for a subscribes-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 subscribes-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 subscribes-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 subscribes 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.
Subscribes-associations from
Entity Classes
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 subscribes-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 subscribes-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.
Subscribes-associations from
Control Classes
Example
In the example above, the entity object Station has a subscribes-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 subscribes-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 subscribes-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 subscribes-association may be an instance association.
Example
In the example above, the subscribes-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.
