[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] 13.html Mon Dec 10 14:17:54 PST 2012

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 upgradeRJB
      62012-12-10Added C++ code for logins


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

        Many Interactions lead to one DCD

        We use the Design Class Diagram or DCD to gather the functions/operations discovered in all the interactions we study into a single collection of classes.

        Interactions show objects. DCDs show classes.

        An interaction that shows [a:A] sending a message f(x) to object [b:B] will require the function/operation f(x) to be in class [B]. A message from [c:C] to [d:B] will also go into class [B]. The objects b and d are different objects in the same class.

        All the messages in your interaction diagrams must appear in the targetted classes in your DCD.

        All the classes in your DCD should be the same as messages some interactions.

        Check the spelling, naming, and parameters of each interaction message with its matching DCD operation.

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

      Exercises

      [ 13x.html ]

      Assigned Project work: GRASP

      [ w6.html ] will be due next week.

      I will show how to do logins

      [ logins.cpp ]

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

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

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

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

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

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

  17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

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

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

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

  21. 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 also means "It won't be on the final or in quizzes".

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

( End of document ) <<Contents | Top