[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [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 Wed Jan 11 07:25:51 PST 2012


    CSci 375/14 Design and Code

    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous13Object Design320-362Q6(271-362)-
    Next15More Analysis401-434Q7(1-434)-

    (Close Table)

    Revision History

    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)

    Message of the day

    The wise way of doing something is seldom the quick and dirty way that we would like when learning a discipline.

    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
      privateone object
      publicAll objects (bad)
      protectedOne object and objects derived from it

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

      (Close Table)

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

      Out of the types of visibility (attribute, static 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 visibility 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.


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

    5. ++ Visibility implies a coupling.

    6. +++ You can also apply an operation to a visible object to get to other objects.

      Chapter 19 pages 366 -- visibility

      Can you explain more detail about types of visibility? Also what is the difference between the diagram on the book page 366 figure 19.2,3,4,5 / attribute visibility and local visibility, Parameter visibility and Parameter to attribute visibility?

      Walkthrough in class.

      Error in Figure 19.4

      There are two messages numbered "2". This one
       			desc = getProductDescription(id)
      should be number 1.

      20 Mapping Design to Code

    7. Introduction
    8. 20.1 Programming as iterative and evolutionary
    9. 20.2 Design to code
    10. ** 20.3 DCD to Class Definitions
    11. ** 20.4 Interactions to Methods
    12. ** 20.5 Collection Objects.
    13. +++ Aim high:
      1. Declare object variables as pointers.
      2. Declare type of object variables as general as possible.
      3. 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.

    14. ** 20.6 Exceptions and Errors
    15. 20.7 Example: Sale.makeLineItem method
    16. ** 20.8 Order of Implementation
    17. 20.9 Test First Development
    18. =~= Test Driven Development -- (TDD)
        My experience with TDD:
      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.
      4. +++ As a rule, when coding a class -- start by coding a unit test of the class, then make the class pass the test.

    19. Simple example: develop a function that tests for primality -- [ tprime.cpp ] (first version), [ tp1.cpp ] (2nd), [ tp2.cpp ] (3rd), etc..
    20. * 20.10 Summary

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

      21 Test-Driven Code and Refactoring

    23. Introduction
    24. *** 21.1 Test Driven Code: USE IT (no quiz/final question)
    25. +++++ In C++ master using the assert function to test classes/objects.
    26. +++ Get into the habit of writing unit tests before you write the class.
    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, and 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 immediately 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

    [ 14x.html ]

    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. Artifact::="Anything that is created in the course of a project".
  7. artifact::=see above.
  8. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  9. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  10. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  11. GoF::="Gang of Four", [ patterns.html#GoF ]
  12. 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 ]
  13. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  14. 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.

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

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

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

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

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

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

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

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

  26. 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 now. In this class it also means "It won't be on the final or in quizzes".

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