Internal Class Structure - Practices

The behavior of a class can be partly or fully described by a set of objects that the class references and/or owns. Each of these objects is called a property of the class.

Figure 1-17 shows that the GeneralLedger class has three properties: Posting is owned by composition, while PostingRule is “owned” by aggregation. (See the section “Aggregation” in Chapter 2 for definitions of these terms.)

Figure 1-17.  Properties

A GLAccount instance owns the Postings made to it, which is why that relationship is a composition. A PostingRule, on the other hand, exists independent of any particular GLAccount instance, which is why that relationship is an aggregation.

An object that is contained by composition is also referred to as a part. Figure 1-18 shows the GeneralLedger class as having two parts.

Figure 1-18.  Parts

Note that the notation for a part can also contain a multiplicity value (see the section “More About Attributes,” earlier in this chapter). This value can appear in the upper-right corner of the object box or in square brackets next to the object name.

Ports can be connected to parts within classes, as shown in Figure 1-19 (see the section “Interfaces, Ports, and Connectors,” earlier in this chapter). Each part provides the functionality that external entities request via the associated port.

Figure 1-19.  Ports and parts

Anyone in the Accounting department who needs the current balance of a given GLAccount accesses that instance via the Retrieve Balance interface. The software that handles the posting of journal entries goes through the Post Journal Entry interface in order to create an instance of the Posting class, which posts to a particular GLAccount.

Figure 1-19 is an example of a composite structure diagram. This type of diagram shows the internal structure of a class or a collaboration (see the next section, “Collaborations”).

A special kind of port, called a behavior port, passes requests for specific behavior to the instance of the given class itself, rather than to any instances that the class may contain. Figure 1-20 shows the symbol for a behavior port.

Figure 1-20.  Behavior port

A collaboration is a description of a named structure of classes. Instances of these classes each perform some specialized function (in other words, each serves a particular role). Taken together, these instances collectively accomplish some desired functionality that’s greater than the sum of the parts.

The name of a collaboration should be a simple noun phrase that communicates the essence of what the collaboration does. The symbol for a collaboration is an ellipse with a dashed outline. Figure 1-21 shows two example collaborations.

Figure 1-21.  Collaborations

You can also show the internal structure (in terms of instances) of a collaboration, as shown in Figure 1-22. The lines between instances represent connectors—and thus communication paths.

Figure 1-22.  Collaboration with internal structure

The Proxy collaboration is actually an example of a design pattern.6 The names before the colons are those that the pattern specifies; the names after the colons are names, defined by the modeler, for entities that are playing the specified roles.

A Customer retrieving information about his or her Order is presented with an OrderInterface in the form of an HTML page. This interface provides the Customer with an OrderProxy that stands in for the actual Order instance. This is necessary because Order instances are responsible for directing system processes (see the section “Active Classes,” earlier in this chapter) and thus shouldn’t be directly accessible by Customers. The OrderProxy does access the Order as necessary for information, without disrupting system operations.

Figure 1-22 is another example of a composite structure diagram.

A collaboration occurrence is the application of the pattern described by a particular collaboration to a specific situation that involves specific classes or instances playing the roles of that collaboration.

The notation for a collaboration occurrence is comparable to that of an object: the name of the occurrence, a colon, and the name of the collaboration. If the occurrence represents some behavior offered by a class, the occurrence is connected with the class using a represents dependency. Figure 1-23 shows an example of this dependency.

Figure 1-23.  Collaboration occurrence