UML Weekend Crash Course™ - To Parent Directory

324
Appendix A
7. The Collaboration diagram numbers the events. The numbering scheme is not standardized,
so care should be taken to decide ahead of time on a consistent technique
for your team.
8. The Sequence diagram can illustrate when an object is created and destroyed. On a
Collaboration diagram, you have to depend on the event names to know that these
things have happened. Also, the Sequence diagram can show activation where a
Collaboration diagram cannot.
9. Use a self-reference. Draw a link that loops out of and back to the object. Place the
event along that loop.
10. There are two types of iteration. Iteration of a single event is modeled with the
iteration qualifier in front of the event name. Iteration through a set of events can
be modeled with a comment, referring to the sequence numbers of the events
involved.
11. Identify the objects that participate in the scenario or operation.
12. Arrange the objects on the diagram with enough space between them to write the
events. They do not have to be lined up across the top as in a Sequence diagram.
13. Use the Class diagram to determine the links that connect the participating
objects. Draw the links between the objects. The link names are not necessary
unless there is more than one valid type of link between the same pair of objects.
Then the name should be shown to distinguish the link that makes the interaction
possible.
14. Each event in the sequence becomes at least one horizontal arrow from the sending
object to the receiving object. The type of arrow depends on the type of event.
Regardless of the type, the arrow is placed parallel to the link.
15. For a synchronous event, or procedure call, that requires a reply, place a second
arrow parallel to the link running in the opposite direction. Replies use a dashed
line style arrow. The return is technically optional but strongly recommended.
16. Identify the condition of the object when it is first created. Draw the state. Then
draw a dot and an arrow from the dot to the state. This configuration identifies
the initial state of the object.
17. The state of the object reflects its condition as recorded in the values of one or
more of the attributes. A change to one or more of these values can redefine the
state of the object.
18. The transition itself is modeled as an arrow between two states. The event that
triggers the transition is written along the arrow. Any actions that are triggered by
the event are written after the event with a forward slash between the event and
the action.
19. A final state is a condition from which an object cannot change. You can spot a
final state as a state that has no outgoing arrows. No, a final state is not required
on every Statechart. In fact, they are rather rare.
20. Yes. There may be as many transitions as the problem statement dictates.