- Introduction
- 20.1 Programming and Iterative, Evolutionary Development
- 20.2 Mapping Designs to Code
- 20.3 Creating Class Definitions from DCDs
- 20.4 Creating Methods from Interaction Diagrams
- 20.5 Collection Classes in Code
- 20.6 Exceptions and Error Handling
- 20.7 Defining the Sale.makeLineItem Method
- 20.8 Order of Implementation
- 20.9 Test-Driven or Test-First Development
- 20.10 Summary of Mapping Designs to Code
- 20.11 Introduction to the NextGen POS Program Solution
- 20.12 Introduction to the Monopoly Program Solution
20.3 Creating Class Definitions from DCDs
At the very least, DCDs depict the class or interface name, superclasses, operation signatures, and attributes of a class. This is sufficient to create a basic class definition in an OO language. If the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams.
Defining a Class with Method Signatures and Attributes
From the DCD, a mapping to the attribute definitions (Java fields) and method signatures for the Java definition of SalesLineItem is straightforward, as shown in Figure 20.1.
![](/content/images/ch20_9780131489066/elementLinks/th20fig01.jpg)
Figure 20.1 SalesLineItem in Java.
Note the addition in the source code of the Java constructor SalesLineItem(ノ). It is derived from the create(desc, qty) message sent to a SalesLineItem in the enterItem interaction diagram. This indicates, in Java, that a constructor supporting 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.