[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] 17.html Wed Oct 28 15:25:09 PDT 2009
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).

Contents

    17 Gang of Four Patterns


      Table
      Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
      Previous16GRASP II413-435-W7(Model 2: use cases, domain, objects, classes)
      Today17GoF435-476Q8(1-476)
      Next18Domain Model III501-539-W8(Model 3: model 2 improved)

      (Close Table)

      Revision History
      Table
      Version#DateDescriptionAuthor
      02005-01-03Used boiler plate to make templateRJB
      12005-03-02Added chapter headings and outlinesRJB
      22005-03-08Added Notes and figuresRJB
      32005-03-09Added questions and some figuresRJB
      42006-03-06Update to new formats etcRJB
      52006-03-07Improved the notesRJB
      62007-12-07Removing Activity and State DiagramsRJB
      72007-03-02Added note on IDs to ObjectsRJB
      82007-03-04Added note on showing interfaces in lifelinesRJB

      (Close Table)

      Project Iteration 2 use cases, domain, interactions, classes

       [ w7.html ]

      Chapter 27: Requirements for Iteration 3

      Dynamics -- Chapter 28 and 29

       We won't be covering Activity diagrams and State Machines in this class. Activity diagrams were covered in [ ../cs372/r2.html ] and my old notes for this class are in [ 17dynamics.html ] and [ 17CoupleStateMachine.gif ] (Photo of chalkboard drawn in class 2005. Thank you Walter!). if you are interested.

    1. **** Be sure you know the following fact:
      1. An activity and a state is shown as a box with rounded corners. They are not boxes(classes or objects). They are not ovals, these are use cases. Actions do things and have rounded corners.

        Symbols to avoid confusing

      Review UML Icons

       [Nine classic UML Icons]

      Exercise: Write down what does each symbol above probably means... Answers: click the letter: A B C D E F G H I or select [ 17exans.html ] for all the answers + the diagram.

      Review GRASP Patterns

      Can you list all nine GRASP patterns without following the next link: [ 16answer.html ]

      Here is a PDF file from another university that reviews the previous GRASP patterns [ cs489-13ch18.pdf ]

      *** Interfaces

      The GoF patterns use a lot of interfaces. Here are some notes on them.

      An interface is a class that has not data but declares some operation. It does not give any implementation for the operations. If an object fits an interface then you know how to call its functions but the implementer can do different things with them. The client who uses the interface is restricted to just using the listed functions. It is said to depend on the interface or equivalently to require the interface. The classes that implement the interface are also said to require it.

      In UML there are two or three notations, and Larman covers them on pages 263 and 264.

      The lollipop notation is a very simple way to show that a class implements an interface. Here is an interface (Animate) and three classes that implement it.

      [UML interface o---[class] ]

      This shows three classes that all implement the same set of operations. Other classes can then use the operation.

      You can use the standard dependency arrow ( - - - - > ) to connect a class that requires the interface to the interface. This relation is shown with a dotted line or with a cup notation (new and rare).

      [ Registrar - - - >o----- Student ]

      Video Introducing the GoF Design Patterns

      [ watch?v=M9zUjF65sho ]

      GoF Key points

      1. GRASP helps you understand GoF Patterns
      2. The GoF patterns improve your grasp of GRASP.
      3. Good developers use the GoF names, so you need to know them.

      GoF Patterns

        The Gang of Four Patterns are all clever ways to use polymorphism to make it easier to change code. They are often modeled using the UML (class diagrams and interaction diagrams) plus English.

        26 Applying GoF -- Adapter Factory Singleton Strategy Composite Observer
      1. Introduction
      2. ** 26.1 Adapter (GoF) [ patterns.html#Adapter ] [ fig25_25_1.cpp ] [ test.fig25_25_1.cpp ]
      3. ** 26.2 GRASP supports and explains GoF See figure 26.3
      4. 26.3 Analysis in Design!? Development is "Research and Development".... embrace change.
      5. ** 26.4 Factory (GoF) [ patterns.html#Factory ]
      6. ** 26.5 Singleton (GoF) [ patterns.html#Singleton ] "One is one, and all alone, and ever more shall be." Probably the most hated GoF pattern. Code: [ singleton.cpp ] [ test.singleton.cpp ]
      7. 26.6 Conclusion: handling many external services thru one interface
      8. ** 26.7 Strategy (GoF) [ patterns.html#Strategy ] Example: many ways of sorting... Associate the algorithms to little objects. Use different objects as needed.
      9. ** 26.8 Composite (GoF) etc. [ patterns.html#Composite ]
        1. (The example on page 452 is just the kind of thing that happens when my wife (a senior 10% off) buys something with a Club Card (20% off!) on Tuesday nights (10% off) in a certain Department store in San Bernardino...
        2. Figure 26.14 page 454: count the relations connecting CompositePricingStrategy and ISalePricingStrategy.
        3. Figure 26.15 page 455 refers about a special way to indicate an object of an unknown class but that implements an interface. I can not find this notation anywhere in the latest (2007) standards. The standard lets you show a lifeline with the name of an interface or a class with no symbolic difference. Ambler shows a message that hits a little interface lollipop -- but I think KISS.
        4. Figure 26.16 page 456: missing italics!
        5. ++ Composite is a good way to handle complex and changing business rules.
        6. ++ Composite is a way of encoding formulae and expressions as a set of linked objects: [ Question 5 in 05a ]
        7. Figures 26.18 and 26.19, pages 458 and 459: a ref refers to a sd -- sequence diagram.`

      10. * 26.9 Facade (GoF) A facade is a kind of curtain used for dramatic effect. "The Wizard of Oz": Pay no attention to the system behind the facade. [ patterns.html#Facade ]
      11. * 26.10 Observer (GoF) [ patterns.html#Observer ] [ watch?v=Xxvpwmc-7io ]
      12. *** page 460 IDs to Objects I didn't pay much attention to this common practice until March 2008 when I linked it to designing logins (handout). I think (guess) that this should become a GRASP style pattern
        1. Who should find objects given their ID.
        2. The creator of the objects.

        You could claim that this is merely putting Information Expert to work.
      13. * 26.11 Conclusion: GRASP supports GoF
      14. 26.12 Resources [ patterns.html ]

      15. For a video introduction to a dozen design patterns see [ watch?v=oSSGDYJZ-m8 ] on YouTube.

      Exercises on GoF Patterns

      Chapter 30 Relating Use Cases -- YAGNI

    2. --- Don't spend time studying the relations between use cases. You Ain't Gonna Need them in the tests/quizzes/final for this class.
    3. Introduction: Don't waste time thinking about these! K.I.S.S.! If it is obvious do it. If it is not... don't.
    4. 30.1 Include: Shows shared logic
    5. 30.2 Terminology: concrete Abstract, base, addition
    6. 30.3 extend: Handy for extensions
    7. 30.4 generalize
    8. + You can also show that one actor is a special kind of another actor ... that it takes part in all the use cases that the general one but adds some others. This is a feature that can be helpful in a complex situation with many types of users.
    9. 30.5 Diagrams of relations

      Project Work: Iteration 3

      Correct errors, add GRASP, improve,... [ w8.html ]

      Questions and Answers

      [ 17q.html ]

    . . . . . . . . . ( end of section 17 Gang of Four Patterns) <<Contents | End>>

    Next -- Next iteration -- back to the domain model.

    [ 18.html ]

    Quiz 8 on interfaces and patterns

     Make sure you know all the UML notations for interfaces and the names of the GRASP and GoF patterns ready for this quiz.

    Review UML Icons -- Answers
    (A): Class
    (B): Class
    (C): Class
    (D): Actor
    (E): Object
    (F): Action/Activity/State
    (G): Use Case
    (H): Package
    (I): Comment Return to diagram: [ Review UML Icons ]

    Review Questions

     [ 17r.html ]

    Standard Definitions
  1. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  2. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  3. GoF::="Gang of Four", [ patterns.html#GoF ]
  4. 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 ]
  5. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

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

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

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

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

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

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

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

End