With a language as complex as the UML (Unified Modeling Language), which is described in a specification that is more than 700 pages long, we all can understand how parts of the UML and their use can be misunderstood. Even though thousands of books have been written on the UML, certain misunderstandings seem to still be floating around. Most of the confusion is not about a specific UML element or its meaning (although such confusion still does exist and fuels fiery debates in certain circles), but is about the application of the UML when modeling. The following is a list (in reverse order) of common misunderstandings that I am still hearing in our industry.
[login]
No. 10: The UML is only for software development
The UML is actually a very utilitarian language. I have known it to be used for varied, non-software development purposes from modeling biological systems to analyzing legal documents. It can be used to model businesses, enterprise architectures, and manufacturing processes just to name a few. With the advent of SysML, modelers have specialized diagrams for systems engineering. Also, the UML has built in extension capabilities (e.g. stereotypes, profiles) that allow you to customize it to your particular needs while staying compatible with the UML specification.
No. 9: You need to use all of the UML diagrams on your project
This is a particularly malicious misunderstanding exploited by some less scrupulous consultants (internal or external) at their clients’ expense — literally. Having used the UML since its inception, on projects large and small, I have never seen a system that MUST use ALL of the UML diagrams to be successful. Learn the purpose of the various diagrams that are available and use the ones that best suit your needs.
No. 8: If we use the UML we automatically get software reuse
Reuse — maybe. Automatically — no. There seems to be an unspoken assumption here that reuse will come automatically with the use of a standard language (the UML) and object-oriented development. Reuse does not come free. The often heard rule-of-thumb is that developing truly reusable assets requires three times the effort vs. not developing for reuse. Also, in order to fully recover that cost, the asset must be reused multiple times. Reuse is a serious practice. If you really are going for reuse, it must be a key project goal, not just something you want the developers to “do” along the way. You can develop quality reusable assets, but it takes a focused effort to do so.
No. 7: The UML is good just for ‘sketching’ diagrams
You
can use the UML for sketching diagrams. At least your team will have a common set of symbols to work with. However, the UML is not just for “sketching”. (This misunderstanding took hold a number of years ago fueled by an aggressive, anti-UML marketing program.) The UML enables designers to perform very robust analysis and design of their systems, even to the point of code generation if you wish to invest enough modeling time for that purpose. Even if you are not generating code, using object-oriented analysis and design techniques with the UML, in your modeling practice, is truly valuable.
No. 6: I can use whatever UML diagram I want (i.e. UML diagrams are interchangeable)
You could try this but it quickly will degrade into the old “Lipstick on a Pig” joke. While it is true that various UML diagrams share similar overarching purposes (i.e. some depict structure, some depict behavior), they are not necessarily interchangeable. Each has a particular viewpoint. For example, two behavioral diagram types, Activity and Sequence diagrams, both can depict behavior. However the “focus” of an Activity diagram is the
flow of a process, whereas the focus of a Sequence diagram is the
time ordered sequence of messages. Yes both can describe a behavior, but each approaches this from a different direction. Use what works for you, but understand the strengths of each diagram type before you choose to use it.
No. 5: I’ll go to a class or read a book to learn the UML
Most books the teach UML diagram by diagram, element by element. That is one way to learn the piece parts of the UML. But you don’t learn to write a great novel by reading a dictionary. During a job interview I was once asked by a VP of development why her people couldn’t do object-oriented (OO) development. After all, she had sent them to a C++ course! OO and the UML are not just about the implementation language or the individual UML elements. You also have to learn an effective approach to apply the UML and OO techniques. Courses can be a better approach (if taught by an experience practitioner and if the course is mostly hands-on problem solving). However, many people suffer from the “White Sheet of Paper Syndrome” afterward. They take the class, go back to their job, and try to apply what they learned. But they get stuck quickly. They look down at that empty white sheet of paper (or whiteboard or tool) and they realize that their real-world problem does not look anything like the contrived problem they worked on in their class. For example, ATM’s, making tea, and library checkout problems used in classes never seem to reflect the complexities of the real world.A total immersion program is the best way to absorb the UML notation, approach, and languages, if you are fortunate enough to be able to participate in one. They are rare, require companies to dedicate their people to the program full-time, and take quite a while (e.g. 2-3 months). But the results far exceed the investment. If you cannot participate in such a program, get a few good UML books, take a rigorous class that teaches the notation, approach, and (if you are a programmer) implementation language, and get your team an experienced UML coach to spend time working with your team. The coach is needed to fill in the blanks that courses and books do not address. Your coach will also help your team take all the theory they just learned and turn it into useful practices.
No. 4: UML is in the development mainstream — all my people should know it
“Should” is the operative word. The UML “should” be mainstream and development teams “should” know it. However, that is not the case. In a
recent survey I ran, nearly 50 percent of the respondents said they new little or were just learning the UML. Also, only a few of the UML diagrams are being used on projects: mostly use case, class, and activity diagrams. These results reflect the results of other studies and the experiential evidence my colleagues and I see in the marketplace. This indicates that the UML (after all these years) is still in the “early adoption” phase, not the mainstream. Project managers should not fall for this misunderstanding. You never know; half your team may have fallen into misunderstanding No. 5 (above).
No. 3: The UML is a process / methodology
The Unified Modeling Language is just that — a language. A standard language is a good foundation for developing common practices, processes, and methodologies, but a language is not a methodology. To be effective the UML must be coupled with an appropriate methodology (i.e. principles, methods, and tools), process, and implementation language, that all work together in a manner that is usable for your teams, in your particular development environment.
No. 2: Modeling isn’t Agile
When people say this, what they typically mean is “Modeling
can’t be Agile. So we’re not doing it.” Either they a.) don’t really understand how to use modeling, b.) don’t understand “agility”, c.) just don’t
want to model, d.) some of the above, or e.) all of the above. Remember that collaboration and effectively responding to change are goals of agility. It is much easier to discuss a diagram of your system at a whiteboard or with a modeling tool than trying to do so sitting in front of a multi-hundred page textual system specification. Plus with the current state of modeling tooling, finding all the elements of your system that may be impacted by a change to a specific element of your system is quite easy. Whether modeling is agile or not all depends on how you model. How broadly or deeply you model is your choice.
No. 1: We want to adopt modeling, so we’ll just buy a tool
A “tools first” approach often runs into difficulties. Tools are created to provide broad functionality to a wide marketplace of users. How the tool vendor expects the customer to use the tools often conflicts with how particular companies or teams work in the real world. Thus if tools are allowed to dictate process, they can over-constrain your team and block their success. A “process first” approach allows you to discover what really works for your project teams in your particular environment. Establish your approach to modeling first. Guidance for how the tooling should be used to support your process can then be established. And before you commit major dollars to a tool purchase, try out some of the free tools (http://rmaksimchuk.wordpress.com/2010/02/25/a-fool-with-a-tool/ ) and evaluation copies of the paid tools, to see how your teams will really use the tools. Your process must support they way your teams work and the tools must not get in the way. I hope you enjoyed these 10 misunderstandings (and have not suffered from any in the real world). If you have additional “favorite” misunderstandings, let us know.
