|
|
|
|
 |
Communications are part of use case diagrams. But objects and activities are not. |
|
|
 |
Actors are the stick figures in use case diagrams. Messages are not in use case diagrams. And the word "activity" is used in activity diagrams, but not here. |
|
|
 |
Objects are not part of use case diagrams (actors are). Use cases are, of course. But activities are not. |
|
|
 |
That's correct. Actors are the stick figures, use cases are the labeled ovals, and communications are the associations connecting actors and use cases. Actors represent the things in the actual environment that initiate the events making up the use cases. |
|
|
 |
No. At the very least, the multiplicities are reversed. With an aggregation, the "many multiplicity" should go at the end opposite the diamond. |
|
|
 |
No. The multiplicities are reversed. This diagram indicates that every teacher advises exactly one student, and that a student can have many advisers. |
|
|
 |
No. The multiplicities are correct, but the aggregation is not. The diamond is at the wrong end. One can argue that there should not be any aggregation at all! |
|
|
 |
That's correct. The diagram shows possibly many students getting advice from one teacher. (Note: The diagram could have used the notation 0..* instead of *.) |
|
|
 |
No. The names are underlined instead. (This is true for other kinds of UML diagrams too.) |
|
|
 |
No -- this isn't quite right. If package A changes, then B maybe forced to change, but not necessarily. |
|
|
 |
No. The class diagram is an abstraction of the object diagram, which shows particular instances. |
|
|
 |
That's correct. Packages are an excellent way to eliminate some of the complicated detail in a class diagram. |
|
|
 |
No. The names are underlined instead. (This is true for other kinds of UML diagrams too.) |
|
|
 |
No. This diagram fails to show that B exists before it is sent messages. |
|
|
 |
No. Where are the activation bars? |
|
|
 |
No. This notation is simply not used (it's much more awkward than the correct UML alternative.) |
|
|
 |
Correct. The asterisk means the message is sent multiple times. |
|
|
|
|
 |
No. Sequence numbers are needed to show the order in which messages are sent. |
|
|
 |
No. Iteration is an important part of the dynamic aspect of collaboration diagrams. Our collaboration diagram shows iteration on the self link. |
|
|
 |
No. A message from an object to itself appears as a loop on the vertex corresponding to the object. The example diagram shows aHotel sending itself messages. |
|
|
 |
Correct. A collaboration diagram is not a static view of the system. It shows objects in action. |
|
|
|
|
 |
No. Actions may be written inside a state. The example below show the Moving state with three internal actions: show timer occurs when the object first enters the state, transfer files occurs as the object is in the state, and kill timer occurs when the object leaves the state.

|
|
|
 |
No. Our example shows transitions moving back and forth between the two states, Getting PIN and Getting SSN. |
|
|
 |
No. Transitions may not overlap. States may not overlap. Statechart diagrams do not allow any ambiguities. |
|
|
 |
Correct. Self-transitions indicate actions on an object that do not change its state. |
|
|
|
|
 |
No. Either C will be done, or A and B, but not all three. |
|
|
 |
No. The fork and join bars indicate that A and B are to be done at the same time. It does not mean to neglect one and do the other. |
|
|
 |
No. The order in which A and B are done does not matter. The code indicates that A is to be done before B. |
|
|
 |
Correct. A and B will be done if OK is false .. and the order in which this is done does not matter. |
|
|
|
|
 |
No. Components are the code modules installed in the physical system nodes of deployment diagrams. |
|
|
 |
No. It's a rectangular shape, but it is not identified by rounded corners. |
|
|
 |
No. The box shape is used for physical nodes. |
|
|
 |
Correct. The component shape is tabbed rectangle. |
|
|