No, I'm not kidding. In fact, I think it's unreasonable to expect someone to learn the majority of a powerful and complex system before they can make use of any small part of it.
Taking Java as an example, for instance, it is not necessary to learn how gc is implemented or to memorize the entirety of the library classes, in order to begin writing code. For many people it is more practical and effective to simply see some worked examples of the sort of thing they're trying to do...
As a small, and perhaps imperfect, analogy to try and understand what you're asking for: "
You have just purchased an automobile and you want the quick start manual describing how to drive to the local movie theater, without complicating the issue with how to drive to a distant clothing store." The requisite driving skills to get to the theater are the same as those needed to get to the clothing store; you just apply them for an extended period.
Both Java and the UML are capable of expressing great and complex things. If you restrict the scope of the UML you wish to learn, you must also restrict the scope of the Java you wish to document.
I don't think a publisher, wishing to maximize profits, would allow an author to write book, such as the one you seek, with arbitrary content restrictions on either language; I'm just happy that they don't spend a lot of time on the history of the languages. The manual on changing a flat tire should not dwell on the history of rubber.
I think that if you select any good UML book (4 stars or better at Amazon.com) containing chapters on Use Case, Class, Activity, and State Machine diagrams and restrict your reading to the first 5 to 10 pages of each of those chapters, you'll come close to what you want, but at a price of reduced quality (i.e.; imperfect communication) in the UML model. The English language, stripped of its adjectives and adverbs, is not as expressive as the full language; so to is the UML. But, as you say, one must start somewhere...
