Chapter 20: Mapping Designs to Code

1
Chapter 20 Mapping Designs to Code

• 20.1. Introduction
• Using the interaction diagrams created (dynamic
  view) and the design class diagram summary
  (static view), we should be ready to produce some
  code.
• What weve done so far is language independent
  into C, Java, C, Python etc.
• 20.2 Agile Approach
• It is unlikely that our design documents are
  prefect as we do not strive for perfection in an
  agile approach...
• But most design decisions have been made during
  design coding, while unlikely to be
  straightforward, should be easier.
• We also have the benefits of a proper,
  maintainable design, that is documented
• UML modeling tools can generate skeleton code
  automatically and allow for round trip
  engineering

2

• Coding is likely to introduce changes to the
  design
• prototyping, design-while-programming and a
  number of other techniques (e.g. test-driven
  development, refactoring) can all be part of an
  agile approach
• Many low-level considerations have not been
  considered during our agile design e.g. error
  handling
• At the end of an iteration (including after
  demonstration and evaluation) documents can be
  synchronised to ensure consistency this way the
  benefits of modeling can be preserved for the
  next iteration.
• However, a minimum of up-front designing must be
  performed to ensure that we do not end-up with
  spaghetti-like code and end-up instead, at the
  end of each iteration, with code that is actually
  scalable on which further iterations can build
  upon.
• 20.3 Mapping Design to Code
• 2 activities
• class definition coding
• method coding

3

• 20.4 Creating Class Definitions from the DCD
• Can be done systematically (even automatically)
• E.g.

4

• 20.5 Creating Methods from Interaction Diagrams
• Skeleton code can be generated systematically.
• E.g. from

5

• And using the information of the design class
  diagram.

6

• We can systematically generate the code for the
  enterItem method of the Register class

7

• 20.6 Collection Classes in Code
• As mentionned many times, 1 to many associations
  in class diagrams hide the need for data
  structures to hold the many instances end of the
  association
• A data structure is needed to hold the references
  to the objects
• Data structure design is not specific to OO a
  crucial part of the designbut beyond this
  subject
• E.g.

8

• 20.7 Implementation Order
• Classes are usually implemented (and fully unit
  tested) from least-coupled to most-coupled (aka
  bottom-up)
• Testing is easier that way
• E.g.

9

• 20.8 Actual POS
• Not actually very interesting See Larmans book
  for details.
• Note that the code is not perfect (e.g. missing
  completedSales from Store class)