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.