[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] 17x.html Wed Mar 6 14:56:06 PST 2013


    Exercises for class 17 -- GoF Design Patterns and GRASP

    1. List the names of the nine GRASP patterns and their meanings.

    2. Copy the figure below and write on each icon what it means.

      [Nine classic UML Icons]

      Exercise on interfaces and the lollipop notation

      Teacher dictates a description of a set of classes and interfaces and how they interact.... class attempts to take draw the description either using the lollipop or the normal "box+stereotype" notation.

    3. Draw two diagrams, using the different interface notations that express the fact that class A use interface I to use class B.

    4. Here is a bad attempt at the Singleton pattern. Why doesn't it work? (long answer -- there are several things wrong with this code).
       	 class Singleton
       	 { static Singleton instance;
       	   public: Singleton() { return &instance; }

    5. What GoF pattern would you like to have explained?

      What GRASP patterns can you detect in the given GOF pattern

      1. Explain how the GoF Observer pattern fits with GRASP.
      2. Explain how the GoF Composite pattern fits with GRASP.
      3. Explain how the GoF Facade pattern fits with GRASP.
      4. Explain how the GoF Factory pattern fits with GRASP.
      5. Explain how the GoF Singleton pattern fits with GRASP.
      6. Explain how the GoF Adapter pattern fits with GRASP.

    6. Reverse Engineering: Draw a DCD of the classes in [ ID2Object.cpp ]

    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. [ 02DiceGameClasses.gif ] (example).
  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 set of objects and/or classes 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 has no value now, 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