[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] 17.html Fri Mar 23 09:31:25 PDT 2012
Opening the PDF files on this page may require you to download Adobe Reader or an equivalent viewer (GhostScript).


    17 Gang of Four Patterns

      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)
      Next18Domain Model III501-539-W8(Model 3: model 2 improved)

      (Close Table)

      Revision History

      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
      92011-03-25Added notes on GoF PatternsRJB
      102012-03-02Added code for IDs to ObjectsRJB

      (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 are the GRASP patterns [ GRASP_(Object_Oriented_Design) ] on the Wikipedia.

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

      The GoF book in CSUSB Pfau Library

      [ ?searchtype=t&searcharg=design+patterns&searchscope=19&SORT=D&extended=0&SUBMIT=Search&searchlimits=&searchorigarg=tSoftware+design+patterns ]

      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.

        Make sure you know the patterns in this chapter

        They will appear in quizzes, finals, and your future career.

        26 Applying GoF -- Adapter Factory Singleton Strategy Composite Observer

      1. Introduction

      2. ** 26.1 Adapter (GoF) adapts an existing interface to be used by a different one. [ 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. But is it worth redrawing a doamin diagram?

      5. ** 26.4 Factory (GoF) [ patterns.html#Factory ]

      6. * The Adapter pattern in 26.1 needs a way to create the adaptor objects. The GRASP creator will not help because nobody in the domain owns an adaptor! They are Pure Fabrications. We get Higher Cohesion by having a specialized object that creates adaptors. This is called a factory.
      7. +++ Notice the separation of concerns principle -- first formulated By David L. Parnas in the 1970's and adopted by all good programmers.
      8. +++ On page 441 the code uses two Java techniques that do not easily map into C++.
        The first of these accesses a collection of named properties -- for example the "java.version" property. There exists a "System.setProperty(string key, value)" that can add new properties. These properties are available to any statement in a Java program. C++ does not provide anything like this.
        THe above uses the Java reflection technology which makes the names of clases, attributes, and functions available to a running program. Again C++ has nothing like this.
      9. ++ However you can still have a pointer that points at different classes depending on data computed at run time. Here [ testDiceGame3.cpp ] and [ DiceGame3.cpp ] show you how the number of arguments in the command line controls the number of loaded dice in the game... It use if-elses...
      10. + A common C/C++ technique is to place run time parameters in a simple text file with one line per property. Each line has the name of the property, some white space, and a value...
      11. + Modern designers tend to use XML to encode run time parameters as data.

      12. ** 26.5 Singleton (GoF)
      13. * For example, we need to have a single Factory object.... A global variable tends to incease coupling and is even illegal in some languages. The GoF Singleton is a pretty good solution.
      14. * For example we want a single Controller for a small application and choose to model it as the organization the software serves. "One is one, and all alone, and ever more shall be."
      15. * The GoF Singleton is a popular solution. [Implementing and using a Singleton class]

        [ patterns.html#Singleton ] Code: [ singleton.cpp ] [ test.singleton.cpp ] (C++), Diagrams: [ Singleton.pdf ] (PDF with two small errors to find). Exercise: translate into another OO language like Java.

      16. 26.6 Conclusion: handling many external services thru one interface
      17. ++++ Exercise. In which layer would you place this ServiceFactory? Why?
      18. ** 26.7 Strategy (GoF) [ patterns.html#Strategy ] Example: many ways of sorting... Associate the algorithms to little objects. Use different objects as needed.
      19. ++ Another example -- describing getting up. Some people drink tea and other drink coffee. We create an abstract "Beverage" class with specializations: "Tea" and "Coffee". These explain the different ways to "make()" a Beverage. We have a strategy pointer that determines the Beverage in your breakfast...
      20. ++ Draw the UML for the Beverage model.
      21. ++ extend it to handle Orange Juice.
      22. ** 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.`

      23. * 26.9 Facade (GoF) It often pays to hide complexity behind an intermediate object -- A Pure Fabrication that uses Indirection to protect clients from variations inside a package.
      24. +++ A facade is a kind of curtain used for dramatic effect. "The Wizard of Oz" ( [ watch?v=YWyCCJ6B2WE ] ) Pay no attention to the system behind the curtain. [ patterns.html#Facade ]
      25. * 26.10 Observer (GoF) means that an object keeps a list of clients that wish to observe it. When a change occurs a message is sent to all theobservers. Each observer can then request details from the observed object. The observed object adds and deletes observers as requested. [ patterns.html#Observer ] [ watch?v=Xxvpwmc-7io ]
      26. ++ Protected Variation -- Observer is not greatly effect if even 100 different observers subscribe.
      27. The observer pattern is often used in connecting to user interfaces. For example a controller object can register its interest in a particular button being clicked or the mouse rolling over a part of a page... To make sure that the observer/listener/subscriber is set up to receive the notifications, it must implement the right interface. See [ ../Luv4.java ] for a simple example in Java.
      28. +++ Sometimes known as the Hollywood Principle of "Don't call us, we will call you."
      29. **** 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 [ patterns.html#IDS_to_Objects ]

      30. ++ Finding objects given an ID
        1. Question: Who should find objects given their ID?
        2. Expert: who knows about the objects?
        3. Answer: The creator of the objects may know.
        4. Consequence 1: The creator will need to maintain a list of the objects it has created.
        5. Consequenc 2: The creator will need to be involved in destroying an object as well.

        You could claim that this is putting Information Expert to work.
      31. ++ Here [ ID2Object.cpp ] is some samples of this kind of code... only the names have been changed to protect the innocent.
      32. + Exercise -- fix ID2Object. The above code is good enough for a classroom example but it is not robust enough to be used in a real app. For example -- if a user does "input1(id)" with an id-string that is not correct the code misbehaves. and there is a similar problem with simpleInput. Here is another bug -- if the user does input2 before input1...
      33. * 26.11 Conclusion: GRASP supports GoF
      34. 26.12 Resources [ patterns.html ]

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

      Exercises on GoF Patterns

      [ 17x.html ]

      Project Work: Iteration 3

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

      Questions and Answers

      [ 17q.html ]

      How to learn all the GoF Patterns -- Painful Quiz

      [ patterns_quiz.html ]

      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

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