In this chapter
Simple problems are easy to model with the UML. Hard problems are easy to model, too, especially after you've become fluent in the language.
Reading about using the UML is one thing, but it's only through using the language that you will come to master it. Depending on your background, there are different ways to approach using the UML for the first time. As you gain more experience, you will come to understand and appreciate its more subtle parts.
If you can think it, the UML can model it.
You can model 80 percent of most problems by using about 20 percent of the UML. Basic structural things, such as classes, attributes, operations, use cases, and packages, together with basic structural relationships, such as dependency, generalization, and association, are sufficient to create static models for many kinds of problem domains. Add to that list basic behavioral things, such as simple state machines and interactions, and you can model many useful aspects of a system's dynamics. You'll need to use only the more advanced features of the UML once you start modeling the things you encounter in more-complex situations, such as modeling concurrency and distribution.
A good starting place for using the UML is to model some of the basic abstractions or behavior that already exist in one of your systems. Develop a conceptual model of the UML so that you'll have a framework around which you can grow your understanding of the language. Later on, you'll better understand how the more advanced parts of the UML fit together. As you attack more-complex problems, drill down into specific features of the UML by studying the common modeling techniques in this book.
If you are new to object-orientation,
Start by getting comfortable with the idea of abstraction. Team exercises with CRC cards and use case analysis are excellent ways to develop your skills of identifying crisp abstractions.
Model a simple static part of your problem using classes, dependency, generalization, and association to get familiar with visualizing societies of abstractions.
Use simple sequence or communication diagrams to model a dynamic part of your problem. Building a model of user interaction with the system is a good starting place and will give you an immediate payback by helping you reason through some of the system's more important use cases.
If you are new to modeling,
Start by taking a part of some system you've already built—preferably implemented in some object-oriented programming language, such as Java or C++—and build a UML model of these classes and their relationships.
Using the UML, try to capture some details of programming idioms or mechanisms you used in that system, which are in your head but you can't put down directly in the code.
Especially if you have a nontrivial application, try to reconstruct a model of its architecture by using components (including subsystems) to represent its major structural elements. Use packages to organize the model itself.
After you become comfortable with the vocabulary of the UML and before you start cutting code on your next project, build a UML model of that part of the system first. Think about the structure or behavior you've specified, and only then, when you are happy with its size, shape, and semantics, use that model as a framework for your implementation.
If you are already experienced with another object-oriented method,
Take a look at your current modeling language and construct a mapping from its elements to the elements of the UML. In most cases, you'll find a one-to-one mapping and that most of the changes are cosmetic.
Consider some difficult modeling problem that you found clumsy or impossible to model with your current modeling language. Look at some of the advanced features of the UML that might address that problem with greater clarity or simplicity.
If you are a power user,
Be sure you first develop a conceptual model of the UML. You may miss its harmony of concepts if you dive into the most sophisticated parts of the language without first understanding its basic vocabulary.
Pay particular attention to the UML's features for modeling internal structure, collaboration, concurrency, distribution, and patterns—issues that often involve complex and subtle semantics.
Look also at the UML's extensibility mechanisms and see how you might tailor the UML to directly speak the vocabulary of your domain. Take care to resist the temptation to go to extremes that yield a UML model that no one but other power users will recognize.
This user guide is part of a larger set of books that, collectively, can help you learn how to apply the UML. In addition to the user guide, there are:
James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual, Second Edition, Addison-Wesley, 2005. This provides a comprehensive reference to the syntax and semantics of the UML.
Ivar Jacobson, Grady Booch, James Rumbaugh, The Unified Software Development Process, Addison-Wesley, 1999. This presents a recommended development process for use with the UML.
To learn more about modeling from the principal authors of the UML, take a look at the following references:
Michael Blaha, James Rumbaugh, Object-Oriented Modeling and Design with UML, Second Edition. Prentice Hall, 2005.
Grady Booch, Object-Oriented Analysis and Design with Applications, Second Edition. Addison-Wesley, 1993.
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Overgaard, Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1992.
Information about the Rational Unified Process can be found in:
Philippe Kruchten, The Rational Unified Process: An Introduction, Third Edition. Addison-Wesley, 2004.
The latest information about the UML can be found on the OMG Website at www.omg.org, where you can find the latest version of the UML standard.
There are many other books that describe UML and various development methods, in addition to the large number of books that describe software engineering practice in general.