In UML version 1.4 there were 9 diagrams.
In UML 2.2 there are now 14 diagrams. There are seven structure diagrams and seven behavior diagrams. Within the behavior diagrams four of them are interaction diagrams.
But, this entry isn't really about the number and type of UML diagrams. It is about lean-modeling using UML. As I mentioned in my entry on Modeling Philosophies, over-modeling is worse than under-modeling. What you really want to achieve is just-what-is-needed-just-in-time modeling.
You have been asked to develop the software architecture for a new system and to document it for presentation and review. And, by the way, use UML diagrams. What do you do? Throw your hands up in exasperation and complain that you don't have enough time to do 100's of pages of documentation?
To start with, let's assume that you were going to do some analysis and design before you started coding. The UML models should flow naturally from your analysis and design process.
You are going to need to determine what things/nouns/objects/entities you are going to be working with. Document them in a class diagram.
You are going to need to determine what actions the user or other systems can cause or trigger. Document them in a use case diagram. If the actions are not self-evident then provide more detail using activity diagrams.
If an action is complex and requires coordination between multiple objects then you may want to create a sequence diagram to illustrate the interaction between the objects.
If you have a process flow with a number of states and each state can transition to multiple other states then a state machine diagram is very useful.
I also recommend that you develop a package diagram for your system. It will help you determine how to structure your code/solution, group your objects together for deployment (dll / jar files), and avoid cyclical references.
Finally, I am not saying that you shouldn't use any of the other diagrams. Depending upon your application type, its complexity, and your audience, additional diagram types may also be very useful.