[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] 13x.html Tue Feb 19 15:43:47 PST 2013

Contents


    Review Questions 13 -- Object Design

  1. Briefly describes the text's method for designing objects including the names of the artifacts that are used, developed or changed.
  2. What happens to a system operation in an SSD when you start to design objects to handle it.
  3. Explain operation contracts.
  4. What is the function of the domain model when you are designing objects?
  5. When is it best to design most of the initialization code?

  6. What are the relations between an interaction diagram and a DCD that supports it?

  7. How do you show iterations in an communication diagram?

  8. Explain the Command-Query Separation Principle

  9. An object a:A sends message m to b:B. Draw a communication diagram that shows this. What does this diagram tell us about the classes A and B -- list all the facts you can deduce.
  10. Class A is a generalization of of Class B and class B is associated with class C. Draw the DCD showing these facts. Are objects in class A also associated with objects of class C?

  11. Write down what the following diagram means as a set of true facts about the classes:

    [A,B,C,D]

    Standard Definitions

  12. Artifact::="Anything that is created in the course of a project".
  13. artifact::=see above.

  14. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code. [ 02DiceGameClasses.gif ] (example).
  15. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".

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

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

  21. OO::shorthand="Object-Oriented".
  22. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.

  23. patterns::="Documented families of problems and matching solutions", see Patterns.
  24. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

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

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

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

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

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

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

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

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

( End of document ) <<Contents | Top