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.
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.