Mapping Design to Code

Implementation in an object-oriented programming language requires writing source code for:

- class and interface definitions

- method definitions 

Creating Class Definitions from DCDs

At the very least, DCDs depict the class or interface name, superclasses, method signatures, and simple attributes of a class. This is sufficient to create a basic class definition in an object-oriented programming language.

Defining a Class with Methods and Simple Attributes

From the DCD, a mapping to the basic attribute definitions (simple Java instance fields) and method signatures for the Java definition of SalesLineItem is straightforward, as shown in Figure 20.2.

Note the addition in the source code of the Java constructor SalesLineItem(...). It is derived from the create(spec, qty) message sent to a SalesLineItem in the enterItem interaction diagram. This indicates, in Java, that a constructor sup- porting these parameters is required. The create method is often excluded from the class diagram because of its commonality and multiple interpretations, depending on the target language.

Adding Reference Attributes

A reference attribute is an attribute that refers to another complex object, not to a primitive type such as a String, Number, and so on.

The reference attributes of a class are suggested by the associations and navigability in a class diagram. 

For example, a SalesLineItem has an association to a ProductSpecification, with navigability to it. It is common to interpret this as a reference attribute in class SalesLineItem that refers to a ProductSpecification instance (see Figure 20.3).

In Java, this means that an instance field referring to a ProductSpecification instance is suggested.

For example, although we have added an instance field to the Java definition of SalesLineltem to point to a ProductSpecification, it is not explicitly declared as an attribute in the attribute section of the class box. There is a suggested attribute visibility—indicated by the association and navigability—which is explicitly defined as an attribute during the code generation phase.

Reference Attributes and Role Names

The next iteration will explore the concept of role names in static structure dia- grams. Each end of an association is called a role. Briefly, a role name is a name that identifies the role and often provides some semantic context as to the nature of the role.

If a role name is present in a class diagram, use it as the basis for the name of the reference attribute during code generation, as shown in Figure 20.4.

Mapping Attributes

The Sale class illustrates that in some cases one must consider the mapping of attributes from the design to the code in different languages. Figure 20.5 illustrates the problem and its resolution.

Creating Methods from Interaction Diagrams

An interaction diagram shows the messages that are sent in response to a method invocation. The sequence of these messages translates to a series of statements in the method definition. The enterltem interaction diagram in Figure 20.6 illustrates the Java definition of the enterltem method.

In this example, the Register class will be used. A Java definition is shown in Figure 20.7.

The enterltem message is sent to a Register instance; therefore, the enterltem method is defined in class Register.

public void enterltem ( ItemID itemID, int qty)

Message 1: A getSpecification message is sent to the ProductCatalog to retrieve a ProductSpecification.

ProductSpecif ication spec = catalog. getSpecif ication( itemID ); Message 2: The makeLineltem message is sent to the Sale.

sale .makeLineltemf spec, qty);

In summary, each sequenced message within a method, as shown on the interac- tion diagram, is mapped to a statement in the Java method.

The complete enterltem method and its relationship to the interaction diagram is shown in Figure 20.8.

Container/Collection Classes in Code

It is often necessary for an object to maintain visibility to a group of other objects; the need for this is usually evident from the multiplicity value in a class diagram—it may be greater than one. For example, a Sale must maintain visi- bility to a group of SalesLineltem instances, as shown in Figure 20.9.

In OO programming languages, these relationships are often implemented with the introduction of a intermediate container or collection. The one-side class defines a reference attribute pointing to a container/collection instance, which contains instances of the many-side class.

For example, the Java libraries contain collection classes such as ArrayList and HashMap, which implement the List and Map interfaces, respectively. Using ArrayList, the Sale class can define an attribute that maintains an ordered list of SalesLineltem instances.

The choice of collection class is of course influenced by the requirements; key-based lookup requires the use of a Map, a growing ordered list requires a List, and so on.