UML and SOA a beginners guide

One of the most common questions I get asked is how Business SOA works with UML. How do you capture Use Cases in an SOA world? How do you do activity diagrams, sequence diagrams etc.

The first point is that you should define the Business Service Architecture first, before you start into the IT project elements. This is the bit that gives the SOA context to everything else.

Now lets look at UML and in particular those pesky Use Cases. The simple rule here is that

• Service => Use Case Package
  
• Capability => Use Case.
  

In other words the requirements for each service need to be gathered within the bounds of that service, not from end to end of the application. The point here is that when doing the Use Case for a service the actor doesn't need to be a person the actor is any external entity which wishes to interact with the service. The interaction with other services can be done by <> statements to the capability definitions from another service package. The good thing about this is that you can use Use Case stubs (i.e. no actual detail) where the service is implemented using another approach (e.g. when using BPMN to implement SOA). This means that your Use Case model is complete for the services that it defines and still allows the flexibility of choosing different approaches for different services.

So that is how I'd say to do UML Use Cases with Business SOA.

Next up there are sequence diagrams and activity diagrams. For these I'd say sticking to the same rules for BPMN is a must, namely have a core thread within one service and only make invocations and requests to other services. This makes it much easier to enforce the separation of concerns and also helps to stop the leaking complexity that often comes into these diagrams.


The business SOA gives the structure, the UML the definition. This is the power as it gives context to the rest and enables different approaches to work together.

Technorati Tags: SOA, Service Architecture