- 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.
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.