Requirements Modelling and Specification for Service Oriented Architecture

5.4. Conversations as Components

If business processes are networks of conversations then it follows that the components of a process are precisely components; in other words conversations can be regarded as reusable, pluggable objects. As such they define services, just as components implement the latter.

We have just seen the utility of permitting OO-style message passing in our models of conversations. It turns out that conversations can also be classified and (de)composed. For example, the scripts for paying one's electricity, gas and water bills can be generalized into a 'pay bill' task script. In other words, they can be regarded as objects within an object model of the business process world. It also happens that we can find uses for the idea of associations between objects. To represent these concepts we use well-known UML notations, as shown in Figure 5-5.

Figure 5-5(a) shows a conversation script with three specializations, while Figure 5-5(b) shows a script with three components. Note that the semantics of this figure is exactly the same as the <<uses>> relationship between use cases (or <<include>> as it was originally called), with the arrows pointing down to the components.

Figure 5-5(c) shows an association between scripts. There is no restriction on what kind of association there can be, but we can pick out four canonical ones that are particularly useful for business process modelling:

• Enables. The first conversation must conclude successfully before the second ...