[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] 11r.html Wed Jan 11 07:25:46 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?

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