[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] 18x.html Thu Mar 7 14:54:18 PST 2013


    Review Questions 18 -- Refining the Domain Model

  1. Review UML Notation.
  2. 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.

  3. Exercise: Here are some classes -- which is subclass of which?
    1. Animal
    2. Automobile
    3. Bicycle
    4. Cat
    5. Cockroach
    6. Dog
    7. Hamster
    8. Insect
    9. Pet
    10. Saloon
    11. Sports-car
    12. SUV
    13. Thing
    14. Vehicle

    Draw a UML diagram showing a single hierarchy.

  4. Work out your hierarchy and compare with other peoples. Discuss differences.

  5. Suppose that people (in class Person) can own zero or more of the items in the list above... how do you show this in a UML class diagram? Do you need to make any changes to the hierarchy?

  6. CSUSB like most domains has several hierarchies or people. For example by sex, by role (Student, Staff, Faculty), and students have ranks (fresh, ... graduate). Draw a diagram with Person as the most general object and reflecting all these distinctions...
  7. Give a real life (not from text or my notes) of a generalization using the UML notation.
  8. When is it worth adding a subclass to a class in the domain model?
  9. When is it worth adding a superclass to the domain model?

  10. What is an abstract class?
  11. What effect does having an abstract superclass have on the objects in the class's subclasses'
  12. An interface is an abstract class. What is special about interfaces vs abstract classes?

  13. Draw a UML diagram that shows the relationship between two people being controlled by a class called "Relationship".

  14. Why should you avoid aggregation in a domain model?

  15. Give a simple guideline for using composition in a domain model.

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

  17. How do you show in the UML that a class Circle has an area that is determined by its radius?
  18. Invent a new example of a reflexive relationship -- like figure 31.25 but from your own experience.
  19. Distinguish a Package from a Class -- how to draw them and what they mean.
  20. 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.

    Exam Questions from 2011

      Domain Models Question -- 20 points

      Suppose that you have to develop some software for a local Pizza shop. It allows customers to order their pizzas over the internet and collect them (and pay) at the store. A Pizza has a price derived from its size, type, and Toppings. A Pizza can have any number of Toppings. Toppings have prices. Customers have Orders and each Order is for one Customer. An Order is for a number Items, and has a collection time An Item is a Pizza or a Drink, The shop has a number of Special Pizzas that have a name (example "Hawaiian" ). Customers can order a Pizza by name or by listing the toppings. The diagram should have at least half-a-dozen classes with associations, some attributes, and some generalizations (correct UML 10 points, modeling the correct things 5 points, modeling the relations between them 5 points).

      Use Case Models -- 20 points

      1. Draw a simple use case diagram showing three(3) likely use cases for the local Pizza shop (10 points, UML 7 points, good names 3 points).
      2. Write a casual description of one(1) use case in your diagram. It should have at least two scenarios. Number the steps! (10 points)

      . . . . . . . . . ( end of section Use Case Models -- 20 points) <<Contents | End>>

      System Sequence Diagrams -- 20 Points

      Draw an SSD for one scenario in the casual format use case you wrote in the previous question for the local Pizza shop (correct UML 10pts, correct lifeline names (4 points), plausible message names 3 points, plausible meaningful data 2 points).

    . . . . . . . . . ( end of section Exam Questions from 2011) <<Contents | End>>

    Standard Definitions

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

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

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

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

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

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

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

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

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

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

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

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

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

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

( End of document ) <<Contents | Top