[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] 18r.html Wed Jan 11 07:26:04 PST 2012


    Review Questions 18 -- Refining the Domain Model

  1. Draw diagrams showing each of these facts using the UML
    1. A is associated with B.
    2. A is a generalization of B and C.
    3. A is an aggregation of B and C.
    4. A is a composition of B and C.
    5. A plays role a in class B.

  2. Give a real life (not from text or my notes) of a generalization using the UML notation.
  3. When is it worth adding a subclass to a class in the domain model?
  4. When is it worth adding a superclass to the domain model?
  5. What is an abstract class?
  6. What effect does having an abstract superclass have on the objects in the class's subclasses'
  7. Draw a UML diagram that shows the relationship between two people being controlled by a class called "Relationship".
  8. Why should you avoid aggregation in a domain model?
  9. Give a simple guideline for using composition in a domain model.
  10. Draw a diagram of a real life domain (not in the text or my notes) of a role name on an association between two classes.
  11. How do you show in the UML that a class Circle has an area that is determined by its radius?
  12. Invent a new example of a reflexive relationship -- like figure 31.25 but from your own experience.
  13. Distinguish a Package from a Class -- how to draw them and what they mean.
  14. Explain how you can make an object appear to change its behavior from one class to another in a language like C++ or Java that does not allow dynamic typing.

    Standard Definitions

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

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

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

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

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

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

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

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

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

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

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

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