Requirements Modelling and Specification for Service Oriented Architecture

7.3. Describing Boundary Conversations or Use Cases

As we saw in Section 5.4, conversations can be modelled beneficially as bona fide objects and the models structured using the standard object connectives of UML: specialization (inheritance), composition, association and message passing. When we looked at this earlier I rather skipped over the issue of message passing, so I try to remedy that now.

The composition (diamond) link is entirely equivalent to the <<includes>> stereotype, with the dotted arrows pointing from the composite to the components. They are completely interchangeable as notations. There is thus no ambiguity about the semantics of <<includes>>; either can be used without harm. The only restriction is that some CASE tools disallow the diamond notation in use case diagrams, so that <<includes>> must be used. A similar remark applies to the notation for message passing used in Figure 5-4, which may only be permitted on collaboration diagrams by some tools. In that case we need to invent a new stereotype called <<send to>>, <<handle>> or some such. Figure 7-2 redraws Figure 5-4 in this way. Notice how, comparing with Figure 7-1, every exception adds only one use case - five use cases instead of eight in this example.

Message passing links give us a much better way of handling exceptions than is available with standard <<extends>> use cases, which suffer from the poor semantics referred to above and the proliferation of 'exceptional paths' in their documentation. ...