Determining Visibility

Visibility is the ability of one object to see or have reference to another. 

The designs created for the system events (enterItem, and so on) illustrate mes- sages between objects. For a sender object to send a message to a receiver object, the sender must be visible to the receiver—the sender must have some kind of reference or pointer to the receiver object.

For example, the getSpecification message sent from a Register to a ProductCat-a/og implies that the ProductCatalog instance is visible to the Register instance, as shown in Figure 18.1.

When creating a design of interacting objects, it is necessary to ensure that the necessary visibility is present to support message interaction.

Visibility

In common usage, visibility is the ability of an object to "see" or have a reference to another object. More generally, it is related to the issue of scope: Is one resource (such as an instance) within the scope of another? There are four common ways that visibility can be achieved from object A to object B:

• m.Attribute visibility—B is an attribute of A.
• Parameter visibility—B is a parameter of a method of A.
• Local visibility—B is a (non-parameter) local object in a method of A. 
• Global visibility—B is in some way globally visible.

For an object A to send a message to an object B, B must be visible to A.

For example, to create an interaction diagram in which a message is sent from a Register instance to a ProductCatalog instance, the Register must have visibility to the ProductCatalog. A typical visibility solution is that a reference to the Pro- ductCatalog instance is maintained as an attribute of the Register.

Attribute Visibility

Attribute visibility from A to B exists when B is an attribute of A. It is a relatively permanent visibility because it persists as long as A and B exist. This is a very common form of visibility in object-oriented systems.

To illustrate, in a Java class definition for Register, a Register instance may have attribute visibility to a ProductCatalog, since it is an attribute (Java instance variable) of the Register.

Parameter Visibility

Parameter visibility from A to B exists when B is passed as a parameter to a method of A. It is a relatively temporary visibility because it persists only within the scope of the method. After attribute visibility, it is the second most common form of visibility in object-oriented systems.

To illustrate, when the makeLineItem message is sent to a Sale instance, a ProductSpecification instance is passed as a parameter. Within the scope of the makeLineItem method, the Sale has parameter visibility to a ProductSpecification (see Figure 18.3).

It is common to transform parameter visibility into attribute visibility. For example, when the Sale creates a new SalesLineItem, it passes a ProductSpecifi-cation in to its initialization method (in C++ or Java, this would be its constructor).

Local Visibility

Local visibility from A to B exists when B is declared as a local object within a method of A. It is a relatively temporary visibility because it persists only within the scope of the method. After parameter visibility, it is the third most common form of visibility in object-oriented systems.

Global Visibility

Global visibility from A to B exists when B is global to A. It is a relatively permanent visibility because it persists as long as A and B exist. It is the least com- mon form of visibility in object-oriented systems.

One way to achieve global visibility is to assign an instance to a global variable, which is possible in some languages, such as C++, but not others, such as Java.

Illustrating Visibility in the UML

The UML includes notation to show the kind of visibility in a collaboration dia- gram (see Figure 18.6). These adornments are optional and not normally called for; they are useful when clarification is needed.