Requirements Modelling and Specification for Service Oriented Architecture

7.5. Finding Services from State Models

In our running example, we discovered two potential process components: Deal and CreditSystem. It is the pink components which will implement these processes that are the ones most likely to have significant state models. We must now create and check the state models to see if all our use cases correspond to states and vice versa. Every state must correspond to a use case. As with process algebra-based models, state can be internal to the component as well as visible at the boundary.

As it turns out, the state model for an order can be immensely complex, especially for financial transactions in banks. In that case an order is Quoted, Agreed, Confirmed (by the bank), Affirmed (by the counterparty), Matched (to see if the confirmation and affirmation agree), Settled and so on. The matching process itself has a complex state model with substates like Matched and Mismatched which lead to different courses of action, a mismatched deal usually involving manual invention which finds out what has gone wrong and even negotiation or legal or regulatory (compliance) action. Luckily most of this complexity will be handled outside the typical deal entry system that we are considering here.

The pattern we use is simple enough: cross-reference states to use cases.

In implementation terms, in a Java environment, the pink components correspond to entity beans, but when implemented as an SOA or ESB co-ordinator they are session beans.

As I have said, there ...