meeting -*- Outline -*-

        copy figure 20.6 and figure 17.7

* Implementation Model: Mapping Designs to Code (Chapter 20)

  The payoff: use the designs to help create the code.

** Programming and the Developement Process (20.1)

   Do a small amount of visual design before programming, and some
   during programming.

   Recommendation: don't get carried away with using tools for design,
                   best to use paper and a scanner or some such.

   Design is incomplete and a first step.

   Coding gives a lot of feedback on the design, which can be used
   both during an iteration and in the next iteration.

** Mapping Designs to Code (20.2)

*** Creating class definitions (20.3)

    Can create a basic class definition from a DCD:
        class name, attributes, method with empty bodies

    Need to add constructors it didn't include them before

*** Add reference attributes

    Add preference attributes as suggested by associations and
    navigability

------------------------------------------
     ADDING REFERENCE ATTRIBUTES

    |------------------------|
    |       Register         |
    |------------------------|
    |                        |
    |------------------------|
    | endSale()              |
    | enterItem(ItemID, int) |
    | makePayment(Money)     |
    |------------------------|
             | 1
             |
             |  Captures
             |
             |
             | 1
             v
    |-----------------------|
    |        Sale           |
    |-----------------------|
    | date : Date           |
    | isComplete: boolean   |
    | time: Time            |
    |-----------------------|
    | makeLineItem(         |
    |  ProductSpecification,|
    |  int)                 |
    |-----------------------|

Suggests that Register have a Sale field:

  public class Register {
     private Sale capturedSale;
     ...
  }
------------------------------------------

        Reference attributes are often implied, rather than explicit,
        because we did not want to cluster the diagram with them

*** mapping attributes
    Q: We have both date and time attributes in Sale,
       but Java has a built-in class Date that holds both,
       so what should we use for a field in a Java implementation?
          a single field dateTime of class Date

*** creating methods from interaction diagrams (20.4)

    Write up the code based on figure 20.6 and the contract for enterItem.

------------------------------------------

public class Register {
  private ProductCatalog catalog;
  private Sale sale;

  public enterItem(ItemID id, int qty) {
     ProductSpecification spec
          = catalog.getSpecification(id);
     sale.makeLineItem(spec, qty);
  }

  // ...
}

public class Sale {
   private ArrayList lineItems
      = new ArrayList();

   public makeLineItem(
         ProductSpecification spec,
         int qty) {
      lineItems.add(
         new SalesLineItem(spec, qty));
   }

   // ...
}
------------------------------------------



*** Container/Collection Classes in Code

    Multiobjects implemented with some sort of container/collection
    class.  For example,...

------------------------------------------

import java.util.HashMap;

public class ProductCatalog {
   private HashMap map = new HashMap();

   public ProductSpecification
            getSpecification(ItemId id) {
     ProductSpecification ret
      = (ProductSpecification)map.get(id);
     if (id != null) {
        return id;
     } else {
       // no errors this iteration
       System.err.println(
                "got bad product id");
       System.exit(1);
     }
   }
}
------------------------------------------


** Order of implementation (20.8)

   Implement from the bottom up (least to most coupled),
    so can test as you go.

   Q: What order would you implement the classes for the POS system in?

   E.g., implement Payment first, then ProductSpecification,
         then either

   Q: Which ones could happen in parallel?

   Q: If you implemented from top down, what stubs would you have to
   write?

** Test-first programming (20.9)

   Write unit tests first, before code.

   Advantages:

      - the unit tests get written this way
      - maor satisfying to pass tests as you go, more fun
      - clarifies interface and behavior to write tests
      - helps correctness
      - allows one to confidently refactor

   For Java, see www.junit.org

** example listings (see section 20.11)