UML - The Unified Modeling Language

The What and the Why

As the Object Management Group's website explains:
The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.

What does all that mean? Mainly, that there is now a standard method of illustrating (modeling) the components and processes that comprise software systems. It's really more flexible than that: you can use it to model just about anything. Once upon a time various notational and diagramming methods abounded; now you should simply LEARN UML.

I won't attempt to teach the UML and will only address it in general terms beyond this document, but I cannot stress its importance to you enough. For one thing, using the UML means that you can describe projects to anyone. Following the processes that create those diagrams assists you in the critical thinking that is required to manage successful projects. And your knowledge of the UML gives you credibility when you're working with established contractors. I strongly urge you to get a good book on UML and perhaps download the from the .

I will say this: the UML is far more flexible than many references let on: and, there is no tool specifically designed for UML modeling that takes full advantage of its flexibility (that includes Rational Rose). If you want to use UML mechanically, as part of a process that includes the automatic creation of software classes, use the tools and be prepared to live with their limitation. I'll provide you with a list of good ones. However, If you want to use the UML expressively, you're better off with a drawing tool like Visio, or Dia, or SmartDraw, or Kivio.

The minimum: At a minimum you need to learn the following types of UML diagrams:

1. Use Cases: These are instrumental in defining your requirements. Learn Use Cases inside out.
2. Class Diagrams: These are essential. Most people think of class diagrams as defining your software components, and that's exactly how products like Rational Rose treat them. You can be a lot more imaginative with them.
3. Activity Diagrams describe how the components of your system will work together. There are a number of different ways do this, and they all have different strengths. Activity diagrams and swimlanes are fairly close to what you might be used to if you've used flowcharts.
4. Sequence Diagrams are most useful show complex interactions between a limited number of classes. I use these all the time. The trick is not to have too many classes on the diagram. If you need to diagram complex interactions between a large number of classes, break the problem down and represent parts of it as packages.
5. Collaboration Diagrams are useful to show limited interactions between a large number of classes. These are nice because in many cases you can simply modify existing class diagrams to produce them.

But Wait! There's More! In addition to the minimum diagrams listed above you should know a few more:

1. State Diagrams I despise these, but they can actually be useful. For a component, a State diagram shows the various states that the component can be in, and the transitions that get it from one state to another. If it sounds confusing it can be. I don't ever recommend showing one of these to a user; for one thing, they're usually used when you're deep in the details of technical design. Limit your users to Use Cases, Sequences, and maybe Collaboration Diagrams.
2. Package Diagrams are similar to a class diagrams. A package is a number of classes grouped together by some common criteria (usually dependencies) and treated as a single component (components and packages are often interchangeable). In addition to pure package diagrams, the nice thing about packages is that once you've identified their interfaces you can substitute them for a bunch of classes in any other UML diagram that needs to be simplified.
3. Component Diagrams illustrate the physical interconnectedness of the components that make up your system. They're often used in conjunction with deployment diagrams.
4. Deployment Diagrams show which components are physically located on which boxen. Say you want to show that when this system is deployed, component A resides on an AIX box called Jumper, while components B and C are on an NT web server called Thumper. The physical locations and physical interfaces are shown on a deployment diagram.

Tools:

1. The following tools are useful for integrating the UML into advanced system development.
   1. Rational Rose. This is the market leader, and a major black hole in your pocketbook as well. It also creates some of the most aesthetically disappointing diagrams of any tool. Can you tell I'm not impressed? Try Rhapsody or Describe.
   2. Embarcadero Describe. Formerly GDPro, this product has high interoperability with whatever Java IDE you might use, as well as the ability to produce nice, presentable diagrams. However, they don't list prices on the website. According to common wisdom, if you have to ask, you can't afford it.
   3. ILogix Rhapsody. You can't beat the price on this one. It's a nice, professional product. It's free for personal use, and I highly recommend it. This product is specifically geared toward creating embedded systems, but it's more flexible than their sales staff will admit.
2. The following drawing tools are useful for expressively diagramming difficult concepts. Since they don't have the restrictions of the programming tools you can get very creative and even mix and match elements of different types of diagrams (useful and encouraged if it helps to get a point across).
   1. Visio This is a solid general-purpose drawing tool that provides UML templates. Hope you don't mind spending money: Visio Professional runs $499. You can get a cheap version for about $199, but then you'd have to create your own UML diagram components. I use it when someone throws at it me, but if I had to buy a tool it would be SmartDraw.
   2. SmartDraw If you use Windows, use this product. It's cheap (it starts at $49) it's as solid as Visio, and I think it's easier and faster.
   3. Dia is exceptional for two reasons, even though its diagrams look a bit clunky and unprofessional to me. First it runs under Linux and is free. Second, it handles its drawing objects far more intelligently that the Windows drawing tools. For instance, when you right-click on a class it doesn't just give you properties of the diagram component; it allows you to enter properties for the class itself. Fantastic! Third, it stores its information in XML, which makes it possible to extend the tool with code generators and all of the bells and whistles that exist in tools like Rational. Those tools don't exist yet, but the open design makes it inevitable.
   4. Kivio is a part of the KDE project. This program is as close to Visio as you can get on Linux, and it generates beautiful diagrams. It's a component of KOffice 2.2. Even though Kivio is free, TheKompany generates a buck or two selling the templates (I mean that literally: the UML template is only five dollars.)

Before We Begin Important Tips