[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] 14.html Fri Oct 23 13:13:52 PDT 2009

Contents

    CSci 375/14 Design and Code
    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous13Object Design320-362Q6(271-362)-
    Today14Design..Code363-398-W6(GRASP)
    Next15More Analysis401-434Q7(1-434)-

    (Close Table)

    Revision History
    Table
    Version#DateDescriptionAuthor
    02005-01-03Used boiler plate to make templateRJB
    12005-01-17Added section headings one or two notesRJB
    22006-02-16Updated to 2006 format RJB
    32006-02-23Added some notes RJB
    42006-12-05Added tools RJB
    52007-01-10Added link to project RJB

    (Close Table)

    From Design into code

      19 Design for Visibility
    1. Introduction: How does this object know about the other objects?
    2. ++ Common error: declaring parameters as attributes.
    3. 19.1 Visibility between Objects - Example
    4. ** 19.2 What is visibility -- definitions and types
      Table
      VisibilityLifeScopeNote
      Attribute=object
      Table
      NameScope
      privateone object
      publicAll objects (bad)
      protectedOne object and objects derived from it Very common. Keep private.

      (Close Table)
      Static Attribute=programOne classShared by all objects in a class.
      Parameterone operation callmethodcommunication between call and callee
      Localone operation callone block(C++)/method(Java)Needs initialization.
      GlobalFor everAny objectJust say NO to global variables. Use either [ patterns.html#Singleton ] or public a class with a static getter operation.

      (Close Table)

      Chapter 19 pages 363-368 -- popularity of different types of visibility

       Out of the four types of visibility (attribute, parameter, local, and global) which one is the most commonly used in object-oriented programming?

      It is not a matter of popularity! You must not think that you can guess the most popular visibillity for a particular item of data. You must discover the right one.

      Worse -- a particular piece of data will have different visibilities to different classes, and at different times. For example: the Widget class may keep a local "knobs" attributes, but pass it to another class as a parameter. The receiving class could then store it in a variable that is local to the method...

      But -- as a rule -- the smaller the scope of a variable the less trouble you will have with accidental usage. So, most experienced programmers will prefer local to parameter, parameter to attribute, attribute to global. In deed most will reject globally visible data, out of hand.

      So:

      1. Local -- safest
      2. Parameter
      3. Attribute
      4. Global -- worst

    5. Error in Figure 19.4. There are two messages numbered "2". This one 
       			desc = getProductDescription(id)
      should be number 1.
    6. ++ Visibility implies a coupling.
    7. +++ You can also apply an operation to an object to get to some data.

      20 Mapping Design to Code
    8. Introduction
    9. 20.1 Programming as iterative and evolutionary
    10. 20.2 Design to code
    11. ** 20.3 DCD to Class Definitions
    12. ** 20.4 Interactions to Methods
    13. ** 20.5 Collection Objects.
    14. +++ Aim high:
      1. Declare type of objects as general as possible.
      2. Declare pointers(C++, objects in Java) at the most abstract class and then they can actually point at lots of different types of low level objects.

    15. ** 20.6 Exceptions and Errors
    16. 20.7 Example: Sale.makeLineItem method
    17. ** 20.8 Order of Implementation
    18. 20.9 Test First Development
    19. =~= Test Driven Development -- (TDD)
        My experience:
      1. It is a lot more fun than Test-Last development. (And fun = motivation = productivity).
      2. It guides you to simple and elegant solutions that "Do the simplest thing that could possible work".
      3. The tests are excellent live (tested) documentation of the software.
    20. Simple example: develop a function that tests for primality -- [ tprime.cpp ] (first version), [ tp1.cpp ] (2nd), [ tp2.cpp ] (3rd), etc..
    21. * 20.10 Summary

    22. 20.11 NextGen Code (not on any quiz/final)
    23. 20.12 Monopoly code (ditto)

      21 Test-Driven Code and Refactoring
    24. Introduction
    25. *** 21.1 Test Driven Code: USE IT (no quiz/final question)
    26. +++++ In C++ master using the assert function to test classes/objects.
    27. *** 21.2 Refactoring: USE IT (no quiz/final question)
    28. ++ These two disciplines fit together.
      1. You can't refactor easily without tests.
      2. Test driven code needs to be refactored to maintain a clean design.
      3. A clean design is easier to change -- and things will change.
    29. 21.3 Resources
    30. ++ Only wear one hat at a time!
      • Either refactor or extend, not both.
      • Either work on interfaces or implementations, not both.
    31. ++ A key idea: DRY Don't repeat yourself!
    32. A very good study of refactoring is Uncle Bob Martin's "Clean Code" book.

    22 UML Tools and UML as Blueprint
  1. 22.1 Forward, Reverse, an Roundtrip
  2. -- 22.2 Tools can get in the way
  3. 22.3 What to look for in a tool
  4. 22.4 Updating sketches
  5. 22.5 Recommended Resources

    Example -- Implementing the Account class

     UML diagram of the Account class from Deitel and Deitel's ATM example. Found in the CSUSB's Library->EBooks->Safari->Deitel->... page306. This is part of an ATM program running at a bank. Typical scenario involves the customer providing a PIN and inputting money and getting money. These effect the customer's account.

    [UML class Account]

    Note 1: credits from the ATM are not immediatly available but are added to the total balance until confirmed by a separate application run inside the bank...

    Note 2: The Account does not verify that the Customer has available funds. This responsibility is allocated to the "Withdrawal" class which acts as a session Controller for Customer withdrawals.

    Note 3: The Account will need a constructor... and for testing something like this 

     	Account ( int acctN, int PIN, double aBal, double tBal);
    will fit the class diagram well. The resulting file looks like: [ Account.cpp ]

    Here is the TDD test: [ test.Account.cpp ] which fails to even compile.

    We will now "Do The Simplest Thing That Could Possibly Work" and so develop the code for the class.

    Exercises on Mapping Diagrams to Code

    Questions and Answers

     [ 14q.html ]

    Next -- Back to Analysis again

     [ 15.html ] for reading etc.

    Next Iteration of project -- Find examples of GRASP in your project

     [ w6.html ] due at start of class 15.

    Review Questions

     [ 14r.html ]

    Standard Definitions
  6. CS202::= See http://cse.csusb.edu/dick/cs202/.
  7. CS372::= See http://cse.csusb.edu/dick/cs372/.

  8. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  9. DRY::XP="Don't Repeat Yourself".

  10. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  11. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  12. GoF::="Gang of Four", [ patterns.html#GoF ]
  13. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  14. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  15. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  16. OO::shorthand="Object-Oriented".

  17. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  18. patterns::="Documented families of problems and matching solutions", see Patterns.
  19. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  20. Process::="How to develop software".

  21. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  22. RUP::Process="Rational UP", a proprietary version of UP.

  23. SSD::="System Sequence Diagrams", see chapter 10.

  24. TBA::="To Be Announced".

  25. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  26. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  27. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it means "It won't be on the final or in quizzes".

  28. XP::="Extreme Programming", the ultimate iterative code-centric, user-involved process.

End