[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] 11x.html Wed Jan 11 07:25:47 PST 2012


    Review Questions 11 -- UML Design Class Diagrams

    1. What is the purpose and form of a DCD? How does it relate to a Domain Model?
    2. Invent an example and use it to demonstrate three different ways of showing an attribute in a UML class diagram.
    3. What information can you attach to an operation in a UML DCD?
    4. How do you document the code for an operation in a UML DCD?
    5. Explain "keyword", "constraint", and "stereotype" as used in the UML.
    6. Draw a diagram that illustrates (using your own invented example) "generalization".
    7. What is an "abstract" class?
    8. How do you show that class A depends on class B. Give an two examples of a dependency between A and B.
    9. How do you show an "interface" in the UML? (several answers needed).
    10. Does aggregation <>----- mean anything -- discuss.
    11. What does "composition" mean in the standard for the UML?
    12. What does an association class do?
    13. On facebook you can specify that you are in a relationship and its status. How doe you use an assoication class "Relationship" to track the connections between Facebook "Users"?
    14. What is a singleton class?
    15. How do you show templatized classes in the UML?
    16. Give an example from C++ STL or Java.
    17. What is an "active class".

    18. Explain the following diagams and their parts...

      [Use case to DCD]

    19. A Widget has method called zark with data knobs:Number Draw a sequence diagram and a communication diagram showng that when a Widget gets a zark(knobs) message it creates a Wodget called kid with parameter knobs and then sends kid a foobar message. -- draw a partial DCD that supports this interaction.
    20. An object a:A gets a message m1 and as a result sends message m2 to b:B. Draw a sequence diagram that shows this. What does this tell us about the classes A and B -- list all the facts you can deduce from this interaction. Sketch a partial DCD that supports this interaction and shows as many facts as you can.
    21. How do DCDs and interaction diagrams relate?

      Exercises on Interaction Diagrams if time

    22. Translate given communication diagram to a sequence diagram. and vice versa.... and draw part of a DCD for both.

      [ 11XY.png ]

    23. Use interaction diagrams to develop a class diagram that supports the interactions.

    24. Use a pair of a communication and a sequence diagram of the same collaboration to fill in blanks.

      See [ 11Exs.png ]

    25. Here is a domain model and a communication diagram from the last class [ 10ExGetUnfilledInteract.html ] (thank you Visio). Redraw the Domain class diagram as a Design Class Diagram that supports the communications shown.

    26. Time to recall or reconstruct the domain model of the objects in a classroom for an inventory of the CSUSB campus. Add some generalizations and more general classes.

    . . . . . . . . . ( end of section Review Questions 11 -- UML Design Class Diagrams) <<Contents | End>>

    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 Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

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

  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.