Good experience for both PC and avionics products (Score 2, Informative)

I am currently a software technical lead at a well-established avionics company and have been involved with many UML-related discussions, training classes, meetings, and FAA certified projects, in addition to smaller at-home PC-based projects. I have taught UML and the Unified Process in house for more than a year and have also read and applied many of the key books on object-oriented design, business modeling, use-case modeling, the Unified Modeling Language (UML), and the Unified Process. I've seen and used UML used in quite a variety of ways (pc game, web-based genealogy database, quality system business modeling, embedded product design, embedded graphics driver design), with a variety of goals in mind, with engineers ranging from hardcore embedded avionics guys to throw-it-together PC app developers. On some projects UML has been very successful, and on others it has failed, but before I mention why, let me first address a misconception I've seen as I've read the posts above.

Many engineers new to UML mistakenly think that the UML dictates a process. However,

The UML is not a process, it is a modeling language

In other words, it isn't UML that dictates the activities and process of your software development. That is instead the job of a process like the Unified Software Development Process, or the standard waterfall, or rapid prototyping, or Extreme Programming, or DARTS/CODARTS, or structured analysis & design, or some other customized process. UML is a language for capturing the models and views of a system independent from any process your project may choose to follow. A process (such as the Unified Process) will customize and extend the available UML modeling elements and define the activities and resources necessary for developing those models. So, when you are having process issues (such as using too much of the UML or fleshing out too much design before starting implementation), don't assume that it's the fault of the UML--it is probably instead the result of a bad choice of development processes.

Strengths and Weaknesses of the UML

From my experience, UML excels at specifying requirements, documenting high level design, describing both the static and dynamic architecture of the system, highlighting core structures and key interfaces, bridging the gap between requirements and design, bridging the gap between business modeling and application design, bridging the gap between database design and application design, and facilitating communication between software developers and the users of the system. (I've actually used it in all of these ways.) UML encourages engineers to think through the problem before hacking together a solution. This doesn't mean that the design should be set in stone first. The requirements and design can and will change, sometimes significantly, over the course of a project. However, I've seen enormous gains in both quality and efficiency when the project team has done a prelimary design of the core structures first in UML, then tried to code them up in C++, learned more about the problem, revised the design in UML, then tried again. Sure there's a cost to documentation but it's cheap relative to the cost of getting the design wrong in C++. One last strength--UML is capable of supporting the development of a multiple layered system, even when that system spans business processes, multiple embedded products that must be integrated together, individual cards with separate software in those products, the layered subsystems in those cards, and on down as far as you care to go. Few if any other modeling languages could say the same.

UML is not so good at documenting low level design except when a certain complex key area needs to be discussed in depth with multiple engineers; "self-documenting" code with appropriate comments is much better at documenting low level design. I have also not seen much use yet for node or component diagrams.

In all the projects I've worked on from avionics to PC apps, the diagrams we used the most were use-case, class, and sequence diagrams. Object, collaboration, activity, and state diagrams have also been occasionally useful.

Successful UML Projects

From my experience, UML-based projects are successful when

The UML and the process are both scaled and customized appropriately to the project.

There is a seasoned mentor on the project with experience on previous successful projects that used UML. This is critical! (We didn't start with one and it took around three years for us to properly understand UML, use cases, the Unified Process, and how to customize them.)

The engineers have been properly trained and much of the UML training is just-in-time where the applicable skills can be used immediately and only the relevant skills are trained.

The first UML project is not high profile and not critical.

A good UML tool is chosen. Round trip engineering is possible with some of these tools. We use both Together (for embedded development) and Enterprise Architect (for pc tool, business modeling, and database modeling.)

Many of the negative UML posts I've read above may be due to the engineer being on a project where one or more of these elements was missing.

Use-case driven development

If you do choose the Unified Process you'll find it is very use-case oriented, so you need to get your use-case modeling correct. I've read quite a few books on the subject and have tried many different ways of writing use cases, having seen a lot of bad use cases and well-intentioned but unsuccessful modeling attempts. Of the books I've read, the best book was Advanced Use-case Modeling. We've gone down a lot of dead ends with use-case modeling, and I'd say it's a tough thing to get right unless you're trained correctly from the start, but five years of hard experience has taught me it's incredibly valuable. The requirements that come from use-case modeling are more complete and concrete than those from any other method I've seen yet.

Finally, customize!!

The need for customization has been mentioned in other postings, but what I'd like to stress is the extreme customization that is usually necessary. If there's anything I've learned from the UML projects I've done it's that it is essential that the UML and the chosen process be customized to the project. This usually means stripping UML down to 1/3 or 1/4 of its size and doing the same to the process (e.g. the Unified Process). I have also found the need on occasion to add a new view or model to the UML. For example, there are new books on business modeling and database modeling both which add new models not defined in the standard UML and Unified Process manuals. You certainly wouldn't want to flesh out these models unless they were useful to your project, nor would you want to ignore them and their potential power in creating and communicating your system if they are indeed relevant to your project.

One last word on process. As software engineers we have watched and are still participating in the maturing of a new engineering discipline; however, as evidenced by some of the postings above, there is still a ways to go yet. It is simply too easy to hack together software with little concern for requirements, design, or well-engineered interfaces with a resultant predictably hard-to-maintain low-quality design. UML is not a silver bullet but when properly applied it strongly encourages and facilitates more rigorous software development and fills a hole which can never be completely filled by self-documenting source code and text-based comments.