The book starts with an introduction to the language, along with what it is trying to accomplish. The use of written language as a metaphor for UML works well, as it breaks down UML into component parts, making it much easier to grasp. Differentiation is made between structural modeling and behavior modeling. Structure modeling deals primarily with the, what else, structure of the system. This includes classes, objects, use cases, and component diagrams. These concepts should be familiar to the object-oriented developer, and the information in the book does a good job in covering the subjects in depth. The behavioral modeling is used to show how the application should interact with the user(s) of the system, be they people or other system components. This includes sequence, state, and activity diagrams. These functions allow a user of the system to understand how everything relates together. When coupled together, you have a complete system to describe an application from all perspectives.

I think the author did a great job in walking the line between a too-simplistic approach which doesn't teach enough, and a highly academic approach which is too difficult to understand for a beginner. There are exercises at the end of each chapter to help you apply the concepts and start to integrate the learning into your everyday experience. When finished with this book, you should be familiar with nearly all the concepts of UML, and should also feel comfortable when you start to use it for real-life modeling.

For the typical Lotus Notes/Domino developer, you may well be thinking, "I don't need all this "stuff". After all, you've been building applications without it so far without it, right? Well, I would suggest that you need to alter your thoughts a little. For one, using a structured modeling approach on larger systems will lead to a better, more solid design as opposed to an ad-hoc "build as you go" approach. You can also use the behavioral structure to show and demonstrate the user's perspective of the system, as well as how the different processes of the system work together. And secondly, as you move into the world of Java and object-oriented systems, you will encounter the use of UML on a frequent basis. Now would be a good time to start learning it so that there is one less thing to learn later on.

Conclusion
If you've not had any exposure to UML (or if it's been very light), I highly recommend getting this book and working through it. The time you spend now learning this information will pay off down the road with better up-front system design, as well as gaining the ability to explain your design and application operation to others. I know that as I move deeper into the world of object-oriented design and analysis, this book will be referred to very often.

One of the things I really like about this book is how it builds from simple to complex examples. This is done in such a way that the reader can quickly understand the more complex example, which is useful in understand many real-world UML diagrams.

One of the things I really like about this book is how it builds from simple to complex examples. This is done in such a way that the reader can quickly understand the more complex example, which is useful in understand many real-world UML diagrams.

The value of a little book like Alhir's lies in slicing out the "heart" of the UML and giving you an overview of the territory, so you can read most any diagram, write the ones that are most important to you, and you feel you understand the lay of the land.

This book has not exactly done a bad job of that task, but the simple truth is that it has a few key weaknesses, and I think you can do better elsewhere if you're looking for a first book to introduce you to the UML.

The first substantive chapter in the book, which introduces the concept of the UML as a language with "words," "sentences," "paragraphs," etc., is really quite good as an overview and orientation, and the quick look at each of the types of UML diagrams will leave you with a pretty good feel for what sorts of things you do with the UML.

The trouble begins when he starts tackling each of the diagrams in more detail in subsequent chapters. I think it's fair to say that the narration plows into the mud somewhwere around page 70, as Alhir starts introuducing a veritable blur of diagram features: stereotypes, aggregations, dependencies, interfaces, and on and on. Models are redrawn and redrawn, now with this feature, now with that feature, and it's hard enough to keep up with the parade of syntax, let alone divine why you would want to use one form or the other.

To _learn_ the UML you have to gain some idea of how the representations work together, showing different aspects of a system in different ways, and you have to learn what representations and what levels of detail are most suitable for different purposes. And it's just that kind of guidance that seems to be lacking most in this book. On one page, we have a class diagram with all the accessors, mutators, constructors and destructors written in the methods section, with visibility, parameters, etc. On another, everything is abstracted out into package diagrams with interfaces and dependencies. Remember that lost and confused feeling I was talking about? There's where it started to set in for me.

Perhaps Mr. Alhir's shortcoming is that he has written this book after producing a couple of really nice _references_ on the UML (also from O'Reilly). Too much of this book has a reference flavor: long on details, short on reasons.

Rather than _Learning UML_, I would recommend a book such as Fowler's _UML Distilled_ or Schmuller's _Teach Yourself UML in 24 Hours_ if you are brand-spanking-new to the UML. I think that both of these books do a better job of picking out the most important aspects of UML and presenting them in a digestible manner. But, that said, you are going to need more than one short book before you can claim to know the language, and I think you might find Alhir's book a really suitable _second_ step on the road to mastery. You'll pick up a lot of details about the language and notation, and you'll find the extensive exercises (with solutions!) really valuable in increasing your skills.

The value of a little book like Alhir's lies in slicing out the "heart" of the UML and giving you an overview of the territory, so you can read most any diagram, write the ones that are most important to you, and you feel you understand the lay of the land.

This book has not exactly done a bad job of that task, but the simple truth is that it has a few key weaknesses, and I think you can do better elsewhere if you're looking for a first book to introduce you to the UML.

The first substantive chapter in the book, which introduces the concept of the UML as a language with "words," "sentences," "paragraphs," etc., is really quite good as an overview and orientation, and the quick look at each of the types of UML diagrams will leave you with a pretty good feel for what sorts of things you do with the UML.

The trouble begins when he starts tackling each of the diagrams in more detail in subsequent chapters. I think it's fair to say that the narration plows into the mud somewhwere around page 70, as Alhir starts introuducing a veritable blur of diagram features: stereotypes, aggregations, dependencies, interfaces, and on and on. Models are redrawn and redrawn, now with this feature, now with that feature, and it's hard enough to keep up with the parade of syntax, let alone divine why you would want to use one form or the other.

To _learn_ the UML you have to gain some idea of how the representations work together, showing different aspects of a system in different ways, and you have to learn what representations and what levels of detail are most suitable for different purposes. And it's just that kind of guidance that seems to be lacking most in this book. On one page, we have a class diagram with all the accessors, mutators, constructors and destructors written in the methods section, with visibility, parameters, etc. On another, everything is abstracted out into package diagrams with interfaces and dependencies. Remember that lost and confused feeling I was talking about? There's where it started to set in for me.

Perhaps Mr. Alhir's shortcoming is that he has written this book after producing a couple of really nice _references_ on the UML (also from O'Reilly). Too much of this book has a reference flavor: long on details, short on reasons.

Rather than _Learning UML_, I would recommend a book such as Fowler's _UML Distilled_ or Schmuller's _Teach Yourself UML in 24 Hours_ if you are brand-spanking-new to the UML. I think that both of these books do a better job of picking out the most important aspects of UML and presenting them in a digestible manner. But, that said, you are going to need more than one short book before you can claim to know the language, and I think you might find Alhir's book a really suitable _second_ step on the road to mastery. You'll pick up a lot of details about the language and notation, and you'll find the extensive exercises (with solutions!) really valuable in increasing your skills.

The book starts with an explanation of why we model code and then gives a brief introduction to UML. The author then discusses the most commonly used UML diagrams. Class and object, use case, component and deployment, sequence and collaboration, state, and activity diagrams are each given a chapter. How and why each diagram is used is explained with sample diagrams designed to show the most common usage. There are exercises at the end of the main chapters with solutions for the exercises in the back of the book. The exercises are designed to help you to check whether you have understood the information in each chapter.

If you are looking to become an expert in UML then there are other books that will serve that purpose. At a little over 200 pages, this book gives enough information for most students and developers without overwhelming them with the multitude of diagrams that are available in UML.