DCDs (Design Class Diagrams) by uig68777


									                                                                                   DCDs (Design Class Diagrams)
         Reference for today:                                                 Recall domain models and their class diagrams
                 Chap. 19 (2nd ed.), 16 (3rd ed.)                                They are closely related to Design Class Diagrams (DCDs)
                                                                                 See Figure 17.5 (2nd), 9.6 (3rd)
                 Chap. 20 (both ed.)
                                                                              Design class diagrams have similarities, but
                                                                              are different too
                          Design Class Diagrams                                  2nd ed.: see 19.2 (modified by me), then 19.2
                                                                                 3rd ed.: see 16.2 (modified by me), then 16.2
                                Implementations                                  (unmodified)

                  Things that can be in a                                                  Design Class Diagrams
                   Design Class Diagram                                                          in Context
Classes                                                                      The point:
Attributes                                                                      While with domain class diagrams we deal with
Navigability:                                                                   conceptual classes…
   “attribute visibility …exists when B is an attribute of A”                   in Design Class Diagrams (DCD) we deal with
       p. 281 2nd, 365 3rd
   See Figure 19.8 (2nd), then 16.5 (3rd) for another view                         software classes
Associations: iff navigability                                               Both are drawn using UML Class Diagrams
Interfaces: screens are done with classes
   Can interface classes be in                                               Design Class Diagrams have more details than
       a DCD?                                                                domain Class Diagrams
       a Domain model?
Dependency: said to exist when any type of visibility exists                 So naturally, Design Class Diagrams use more parts
   (Except the “main” kind, attribute visibility)                            of the UML class diagram sublanguage
       -- see Figure 19.11 (2nd) or 18.17 (3rd), then 16.1 (3rd)
                                                                             Let’s build a DCD on the board, step by step

                    Creating Design Class
                          Diagrams                                                               Creating DCDs II
We will account for:                                                          Method names are missing – let’s add
   Classes, Attributes, Methods, Associations, Interfaces, Navigability,
   Dependencies…                                                              Get many of them from the interaction diagrams
Start by identifying the classes                                                 (Which of the figures we’ve seen are interaction diagrams?)
   Simply use the classes found in the interaction diagrams
       Recall:                                                                Let’s scan the interaction diagrams for methods
            interaction diagrams include the logically equivalent:
                 sequence diagrams
                 collaboration diagrams
                                                                              Some might not be in the interaction diagrams
       See various Figures                                                       Accessor and mutator methods are examples
            Just make a list of classes! Let’s do it…
       Then, draw a very basic Class Diagram (rectangles, no arcs)               Java developers often use them
            Add in attribute names that might be found in the domain model          Declare the member variables private
                 (Figure 12.7 2nd, 9.7 3rd)
                 Let’s try it! Also consider adding attribute types                 Work with them only via accessor & mutator methods
                 (e.g., quantity : int)                                             Why?

                                                                                Creating DCDs IV
             Creating DCDs III
There is no need for a method called                         Methods for getting or changing attribute values…
“create()” in Java or C++                                      A convention (e.g. common in Java) is:
                                                                  Declare all attributes (member variables) private
  Objects in these languages are created with the                 Define for each
  ____ operator and a c________ call                                  A method to get the value
                                                                      A method to set the value
  “…it is common to omit [these] from a DCD” –
                                                               Example: attribute is trafficLightColor
  p. 290
                                                                  Define accessing methods
    Are there any? If so, let’s delete                                getTrafficLightColor(), setTrafficLightColor()

                                                             No need to have then in DCDs since convention
                                                             already accounts for them
                                                               Let’s check if there are any, and delete if so

              Creating DCDs V                                                   Creating DCDs VI
Collections are an interesting programming                   Add associations (“navigability”)
construct                                                      Put a solid arrow from class A to class B if:
                                                                  A sends a message to B, or
See Figure 19.6 (2nd), 15.16 (3rd)
                                                                  A creates or contains an object of class B
The find( ) message makes no sense as a                               (i.e. B is an attribute of A, i.e., B is a member of A)
member of any particular ProductSpec object                  Associations are found in the interaction
  (it is implemented in the collection class, not shown in   diagrams
  the DCD)
  What might the collection class be like?
                                                               Let’s add some to the DCD now…
  …so get rid of any such methods                              Label the arrows with the kind of association
                                                                  …usually not the same as the interaction diagram

            Creating DCDs VII                                   Implementation Notes
Dependency relationships                                           Reference: chapter 20 (both ed.)
  Solid arrows show attribute visibility                           Going from design to implementation
    (Recall previous chapter on visibility types)                  should be fairly mechanical, usually
  Use dotted arrows to show other kinds of                         Implementation can uncover design
  visibility                                                       defects
    Parameter (passed in as a method argument)
                                                                      Fix the design and then implement
    Local (e.g. returned by a method)
    Global (global variables
                                                                      The new design is an input to the next
                                                                      iteration (see Figure 20.1 2nd, 2.8 3rd)
  See Figure 19.11 2nd, 18.17 3rd
    Do any of these apply to ours?

Implementation II
 Let’s see how to go about implementing
 representative bits of our DCD…
 Also, note that exception handling is
 more of a focus in implementation…
 Section 20.8 recommends…
   implement least coupled classes first, and
   most coupled classes last


To top