[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] 13.html Mon Sep 28 15:44:32 PDT 2009

Contents

    13 Object Design + GRASP


      Table
      Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
      Previous12GRASP271-319-W5(Class Diagrams)
      Today13Object Design320-362Q6(271-362)-
      Next14Design..Code363-394-W6(GRASP)

      (Close Table)

      Revision History
      Table
      Version#DateDescriptionAuthor
      02005-01-03Used boiler plate to make templateRJB
      12005-02-14Input chapter headlinesRJB
      32005-02-21Improved instructions and notesRJB
      42005-02-27Added questions and some answersRJB
      52006-02-142006 upgrade RJB

      (Close Table)

      Project W5 -- Interactions and class diagram

      Designing Objects with GRASP

        Introduction -- the No-Magic Zone
      1. * Design becomes more logical and less magic.

        18.1 Realizing a Use Case
      2. * Creating a set of objects that share the responsibilities implied by what a user needs to do.

        Figure 18.1 The big picture

        18.2 More on the artifacts

         Process= iterate the following
        1. SSD ->
        2. System Operations/events ->
        3. Contracts ( + tests ) ->
        4. Interactions & Classes ->
        5. Code

        Communications (Larman+MVC)

        1. UserInterface generates SystemEvents.
        2. SystemEvents feed the Controlers
        3. Controlers talk to each other and domain layer objects.
        4. Controlers return results to the UserInterface.
        5. Domain layer objects use lower layers as needed
        6. Domain layer objects notify the controlers if anything important happens.

        [ patterns.html#MVC ] Examples Stock taking at a depot (bring the handed out answers to the last quiz to class.

        18.3 Next -- Examples

        18.4 Example: NextGen Point of Sale

        How to connect UI to Domain?

        Initialization p347-349
        Table
        QuestionAnswer
        When to design it?LAST
        How to design it?Start another use case.
        What objects are created first?THINK

        (Close Table)

        18.5 Example: Monopoly
      3. Command-Query separation

        18.6 The Design Process

        1. Iterative
        2. Evolutionary
        3. Team
        4. Starts in inception and continues thru elaboration and construction.
        5. + Validate designs by peer review as you draw them.
        6. + Check designs by coding, compiling, and testing.
        7. + Improve designs and code by refactoring.

        Table 18.1 Review artifacts and disciplines.

      . . . . . . . . . ( end of section Designing Objects with GRASP) <<Contents | End>>

      Assigned Project work: GRASP

      [ w6.html ] will be due next week.

      Quiz on UML Class Diagrams

       Like the exercise in the last class [ 12.html#Exercises ]

      Questions and Answers

       [ 13q.html ]

      Next -- More Design and some Coding

       [ 14.html ]

    . . . . . . . . . ( end of section 13 Object Design + GRASP) <<Contents | End>>

    Review Questions

    [ 13r.html ]

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

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

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

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. 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 ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

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

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

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

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

  22. 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".

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

End