meeting -*- Outline -*-

        Make copies of figures 19.9 and 19.11

* Creating Design Class Diagrams (DCDs) (Larman Ch. 19, Fowler Ch. 4)

  Design-level class diagrams summarize information
  from the interaction diagrams.

** When to create DCDs (19.1)

   These should be done concurrently with the creation of the
   interaction diagrams.

   They are an alternative to CRC cards

** Example DCD (19.2)

   Technically, in the UML, DCDs are supposed to be language-independent,
   but I think it's better, and clearer, to record actual design decisions
   using language specific types if necessary.

------------------------------------------
     EXAMPLE DESIGN CLASS DIAGRAM (DCD)

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

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

** differences from domain model (19.4)

        Q: What are the differences from deisgn model class diagram?
           shows navigation, methods, attribute type information

        Parameter information is optional, but if you show any of it,
        should show the types, optionally show parameter names.
               f(T) or f(x:T)

** Creating a NextGen POS DCD

   Get the classes from the interaction diagrams.

   For the POS system so far we have:

      Register               Sale

      ProductCatalog         ProductSpecification

      Store                  SalesLineItem

      Payment

   Omit classes that are not needed in this iteration.

*** adding method names

   Add method names, from the interaction diagrams.

   I recommend recording the type informtion for methods here,
     it's not on the interaction diagrams.

   See Figure 19.5 on p. 289 

*** method name issues
**** constructors
     You can add constructors to record their parameters
         these can be written as "create" methods or like:

               <<constructor>> Register()

     Larman recommends omitting them

**** accessing methods (get and set methods)
     e.g., getDate(), setDate(Date) for Sale.

     Best not to have dumb methods like these.

     If you do generate them for attributes, Larman recommends
     omitting them from the DCDs

**** multiobjects (collections/containers)

     Don't put methods center collection that contain instances of a
     class in the diagram for the class.

     E.g., find sent to collection of ProductSpecifications by
     ProductCatalog doesn't go in the ProductSpecification class,
     it's part of the Set or whatever class.

     Don't put predefined library classes in the DCD (they add noise).

**** adding type information

     Technically the notation uses colons (see Fig. 19.7)

     Do it if it's helpful.

     I think it's useful to record this, but not if it duplicates
     other stuff (contracts, or code header files).

     Larman recommends omitting it unless it's necessary for a CASE
     tool.

**** heading associations and navigability

     Navigability implies visibility, usually after the visibility

     The default interpretation of an association with navigability
     arrows is attribute visibility.

     Recommendation: put in navigability arrows on all associations in DCDs.

     Use need-to-know for the implementation,
         this may differ from the domain model.

     E.g., in POS system, consider the interaction for the StartUp
     case (fig. 19.9)

     Q: Since Store creates Register, which direction does navagation
     go on the "Houses" association?
        Store to register.

        Show outline of fig. 19.9 and 19.11 (on copies)

     Q: Why is there an association from Register to ProductCatalog?
        we need it for the enterItem system operation
        This wasn't in the domain model

**** adding dependency relationships
     
     Can indicate non-attribute visibility with a dependency arrow
     (dashed), see Fig 19.11

     But I don't really think this is that useful most of the time

** Notation for member details (19.6)

   Class (static) methods and attributes are underlined (confusing...)

   "+" means public attribute/method
   "#" means protected attribute/method
   "-" means private attribute/method

   There is technically no UML default for visibility,
         but a common convention is to assume that attributes are
         private and methods are public, unless explicitly noted otherwise.

   use "/name" for derived attribute 

   In C++ use virtual for all methods, or put {leaf} on the method
   In Java, the equivalent of virtual is the default, use {leaf} if final

   Can add method code in a UML note box if desired.

** DCDs and Case Tools (19.7)

   It's helpful to have a CASE tool to reverse engineer the DCD from
   code when starting the next iteration