Capturing the Collaboration s Design
Capturing the Collaboration’s Design
Each step you take to add detail and flesh out the steps in the communication diagram captures more information on how the collaboration works. Some of this design detail requires the underlying classes or associations to change their definitions. You have to go back to the class diagram and make sure that the features from the communication diagram map to the features of your class diagrams, as detailed in Table 14-1. Your tool may automate some of this mapping—updating one diagram may automatically update the others. You want to be sure that the communication diagrams and the class diagrams are consistent; they should be different views of the same underlying model. So in the table below we list several of the possible communication diagram design features, and we tell you what these features would be in the class diagram. By looking at Figures 14-8 and 14-9, you’ll see how we did the mapping in practice.
Figure 14-9: Class model arising from communication diagram and design.
| Communication | Mapping to Class Design Diagram Feature |
|---|---|
| Message name | Target class must have an operation (or a signal reception) by that name. |
| Argument list | Argument lists on the class’s operations/signals must match the communication diagram, in direction, type, number, name, and order. It’s not required that the argument list be duplicated. Argument values may be used on the communication diagram if they can be matched directly and are compatible with the arguments of the class. |
| Return assignments | If you assign a named value, the results of a message return value must match the type of the return value from the operation. The named value must be an attribute or local variable of the calling class. If the named value is only used by that object within its current operation, you may use a local variable. If used in subsequent operations, or required to be persistent (live in a database), make it an attribute. |
| Selectors / qualifiers | Check to see if the relationship has a qualifier or is {ordered}. |
| Call direction | If during an operation on A, A invokes another operation on B, it must know about B. It can do this because of a link, or a parameter being passed to A that references B, a return value to A referencing B, or because B is in a well-known (global) location. If the knowledge about B needs to be remembered for other operations on A, or is persistent, the best solution is a link. Otherwise, it may be possible to store a reference to B locally for the duration of A’s operation. When in doubt, use a link. Only a unidirectional link is needed from A to B. The reverse direction is needed only if B calls an operation on A. |
In Figure 14-9, we’ve applied the guidelines of Table 14-1 to the details of the communication diagram shown earlier in Figure 14-8. Whenever there was a choice in identifying a feature as an attribute (as opposed to a local variable), we chose an attribute, primarily because it made it visible on the diagram. When you do this work of abstracting the design, you’ll need to be more discriminating. You only need to use attributes if the knowledge of the value or reference is persistent across calls.
If you have multiple interactions or scenarios to describe for this collaboration, incorporate the features from all the communication (and sequence or timing) diagrams used to detail the interactions.
EAN: 2147483647
Pages: 193