+1  A: 

hmm. Does it have to use UML models specifically?

As I understand your post it looks like a dataflow diagram (DFD) might be useful. It would allow you to show what data flowed from/to where. A level 0 DFD (Context diag) would let you illustrate your system and those it integrates with.

If you need to go to more precision, a sequence diagram would allow you to illustrate the interaction protocol between your system and those it integrates with.

sfinnie
A: 

If the subsystems are among different platform and device, you can use deployment diagram to show the interfaces(protocol e.g. http) and devices of different subsystem.

If you'd like to focus on the interface between different subsystems, you can use component diagram.

If you'd like to show the high level architecture, you can use package diagram.

Check UML example and see what you can use.

Red Koda Software
+2  A: 

Essentially we want to model the interactions between different components in the system.

Clearly, then, you want a component diagram. Lay out the components and their interfaces as the focal point of your presentation.

I agree that starting with use case is best because that helps define the requirements (although I do not think it is a replacement for a requirements spec.). Then create the component diagram. Note that components should be platform independent for as long as possible. Keep deployment decisions as late in the project as possible.

The next step would be to show the interaction between the components using sequence diagrams to define the major scenarios. Each component has a lifeline showing messages passed between them. Each sequence diagram describes one path through the system, i.e., one stimulus, one response, that accomplishes an important function. These can be time consuming to create so you want to choose them carefully. Each diagram should contain a summary, preconditions and postconditions. A good UML tool (like Enterprise Architect from SparxSystems) will add your interfaces to the components as you create them in the scenarios and will also make visible any interfaces that you add in the component view.

Bruce
I agree with the component diagram, but one useful tip on going from use cases to components. Subsystems are a type of component so you can show the components involved in the use cases, via association or some keyword <implementing>/<realizing> on a line of some type. This way you don't need actors/subsystems that are just representations of the components you are modeling. It is easier to keep things in sync.
Ted Johnson