Step: Describe attributes and associations

In order to carry-out their responsibilities, classes frequently depend on other classes to supply needed behavior. Associations document the inter-class dependencies and help us to understand class coupling; better understanding of class coupling, and reduction of coupling where possible, can help us build better, more resilient systems.

The following steps define the attributes of classes and the associations between classes:

• Define attributes
• Establish associations between analysis classes
• Describe event dependencies between analysis classes

Define attributes

Attributes are used to store information by a class. Specifically, attributes are used where the information is:

• Referred to "by value"; that is, it is only the value of the information, not it's location or object identifier which is important.
• Uniquely "owned" by the object to which it belongs; no other objects refer to the information.
• Accessed by operations which only get, set or perform simple transformations on the information; the information has no "real" behavior other than providing its value.

If, on the other hand, the information has complex behavior, is shared by two or more objects, or is passed "by reference" between two or more objects, the information should be modeled as a separate class.

The attribute name should be a noun that clearly states what information the attribute holds.

The description of the attribute should describe what information is to be stored in the attribute; this can be optional when the information stored is obvious from the attribute name.

The attribute type is the simple data type of the attribute. Examples include string, integer, number.

Establish associations between analysis classes

Start by studying the links in the collaboration diagrams produced in Step: Distribute Use Case Behavior to Classes. Links between classes indicate that objects of the two classes need to communicate with one another to perform the Use Case. Once we start designing the system, these links may be realized in several ways:

• The object may have "global" scope, in which case any object in the system can send messages to it
• One object may be passed the second object as a parameter, after which it can send messages to the passed object
• The object may have a permanent association to the object to which messages are sent.
• The object may be created and destroyed within the scope of the operation (i.e. a 'temporary' object) - these objects are considered to be 'local' to the operation.

At this early point in the "life" of the class, however, it is too early to start making these decisions: we do not yet have enough information to make well-educated decisions.  As a result, in analysis we create associations and aggregations to represent (and "carry") any messages that must be sent between objects of two classes.  (Aggregation, a special form of association, indicates that the objects participate in a "whole/part" relationship (see Guidelines: Association and Guidelines: Aggregation)).

We will refine these associations and aggregations in the Activity: Class Design.

For each class, draw a class diagram which shows the associations each class has to other classes:

Example analysis class diagram for part of an Order Entry System

Focus only on associations needed to realize the use cases; don't add association you think "might" exist unless they are required based on the collaboration diagrams.

Give the associations role names and multiplicities.

• A role name should be a noun expressing what role the associated object plays in relation to the associating object.
• Assume a multiplicity of 0..* (zero to many) unless there is some clear evidence of something else. A multiplicity of zero implies that the association is optional; make sure you mean this; if an object might not be there, operations which use the association will have to adjust accordingly.
• Narrower limits for multiplicity may be specified (such as 3..8).
• Within multiplicity ranges, probabilities may be specified. Thus, if the multiplicity is 0..*, is expected to be between 10 and 20 in 85% of the cases, make note of it; this information will be of great importance during design.   For example, if persistent storage is to be implemented using a relational database, narrower limits will help better organize the database tables.

Write a brief description of the association to indicate how the association is used, or what relationships the association represents.

Describe event dependencies between analysis classes

Objects sometimes need to know when an event occurs in some "target" object, without the "target" having to know all the objects which require notification when the event occurs. As a short-hand to show this event-notification dependency, a subscribes-association allows us to express this dependency in a compact, concise way.

A subscribes-association between two objects indicates that the subscribing object will be informed when a particular event has occurred in the subscribed object. A subscribes-association has a condition defining the event that causes the subscriber to be notified. For more information, see Guidelines: Subscribes-Association

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.

A subscribes-association is needed:

• If an object is influenced by something that occurs in another object.
• If a new object must be created to deal with some event, for example, when an error occurs, a new window must be created to notify the user.
• If an object needs to know when another object is instantiated, changed or destroyed.

The objects which are 'subscribed-to' are typically entity objects.  Entity objects are typically passive stores of information, with any behavior generally related to their information-storage responsibilities. Many other objects often need to know when the entity objects change.  The subscribes-association prevents the entity object from having to know about all these other objects - they simply 'register' interest in the entity object  and are notified when the entity object changes.

Now this is all really just 'analysis sleight-of-hand': in design we have to define how exactly this notification works.  We may purchase a notification framework, or we may have to design and build one ourselves.  But for the moment, simply noting that the notification exists is sufficient.

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 to which it subscribes.