[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] 10x.html Wed Feb 8 15:25:14 PST 2012


    Exercises 10 UML Interaction diagrams

    1. Name the two types of interaction diagrams and give very simple example of the same interaction using one type of diagram and the other.
    2. Copy the following diagram and label an object and a message. What does it tell you about the operations in the classes.

      [Example communication diagram]

    3. Redraw the above diagram as a sequence diagram.
    4. How do you show that one class is responsible for creating an object? Show notation for both types of interaction diagram.
    5. How do you show that a class is responsible for executing an operation rather than an object?
    6. How do you show an operation that will be static in C++ or Java?
    7. How can you show an array and an element in an array?
    8. What is a found message? What does it mean?
    9. How do you show a returned object in a sequence diagram?
    10. Explain these structures: alt, loop, and opt.
    11. How do you show an action (x=x/2.0; for instance) in a sequence diagram?
    12. Explain ref and sd and the relation between them.
    13. In a communication diagram -- how many messages per link? How are the sequenced?
    14. I have messages numbered 1, 2, 3, 2.1, 1.1, 3.1, 1.2, 3.2. In what sequence are they actually sent?
    15. What does this mean in a communication diagram: [gender = male]? And what does *[i=1..20]?

    16. Explain these diagrams....

      [Use case to interaction]

    17. The interaction diagram above tells you that the program will have a class called C that has a particular operation in it. What can you deduce about this operation?

    18. What do the interaction diagrams below tell you about the operations in class Die?

      [Two interaction diagrams]

    19. Redraw the above sequence diagrams as comunication diagrams. [ 10xDiceCommunication.png ]

    20. What interaction diagrams might be drawn for this SSD? [ 09SSD060208.jpg ] (Don't draw the diagrams ... just decide how many and what each would do).

    21. Here is the declaration of a member function in C++ & Java translate it into a (1) sequence diagram, and (2) a communication diagram:
       		C++:  void A::f ( B* b) { b->g(this); C* c = new C; c->h(b); }
       		Java class A: public void f ( B b) { b.g(this); C c = new C; c.h(b); }

      Answers: [ 10ExAf.png ]

    22. Here is some more C++ and Java code.... fit it into both your interaction diagrams
       		C++: void B::g ( A *a) { a->k(); }
       		Java class B: public void g ( A  a) { a.k(); }

      [ 10ExAfBk.png ]

    23. Given an incomplete pair of diagrams of the same set of events/messages -- one communication and one sequence -- use the given information to fill in the blanks.

    24. Act out a given interaction diagram.

    25. Read a given diagram aloud -- read out what steps does it does.

    26. Given a dictation of a set of steps.... draw the diagram.

    . . . . . . . . . ( end of section Exercises 10 UML Interaction 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 and Engineering School, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

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

  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.