Interaction diagrams are the next step of the UML design process. Interaction diagrams concentrate on showing how objects or things in the system interact with each other to give a dynamic view of the system. There are two basic types of interaction diagram:
> sequence diagrams
> collaboration diagrams
Essentially these both model the same information, except that sequence diagrams emphasize time ordering whereas collaboration diagrams spatial or structural organization.
For the most part, you choose to create either collaboration diagrams or sequence diagrams. For the sake of completeness, this appendix discusses both but we only use sequence diagrams in this book.
This type of diagram can be used to convert the written use case models that we saw in the previous section into a clearer visual model. This visual model will show how the objects associated with a particular use case communicate with each other and with users over time. Sequence diagrams are very general. For example, they may show that some Object 1 passes a message to some other Object 2, and that Object 2 then performs some operation within itself and finally returns the message back:
The internal workings of Object 1 that led to the creation of the message, and the internal workings of Object 2 that led to the return message, are not shown in sequence diagrams. (Details of the inner workings of the objects are represented in another type of diagram called an activity diagram - which we'll see in the next phase of the UML design process.)
Sequence diagrams map out every possible sequence of events that can be performed within each use case, including correct and incorrect paths. The correct paths in the sequence diagrams can be used to design the GUI of the project as they show what the user will need to do to interact with the application. Incorrect sequences will later be used to map out errors and how to handle these errors.
Sequence diagrams also show what public methods and properties our components must have. You can compare the sequence diagrams for one or more components and attempt to find patterns that exist that can be used to simplify the coding of the components.
Collaboration diagrams are also built from the use cases - but this time the emphasis is on the spatial distribution of the objects involved. This is not to say that there are no temporal elements in collaboration diagrams, since the sequence of events is mapped using numbers:
Obiectl: Class name
Actor Name: Actor Class
3. Operation (parameter list)
5. Operation (parameter list)
6. Operation (parameter list)
Personally, I often find this type of diagram quite confusing in comparison with the equivalent sequence diagrams. This particular collaboration diagram presents the same situation as the sequence diagram we just looked at - Object 1 and Object 2 with exactly the same relationships as before. However, it should be said that there are times when collaboration diagrams can make good sense - especially if we find that we want to emphasize a set of objects themselves rather than any sequence of events between them.
Was this article helpful?