Prologue

If, like us, you’re a software developer or computer professional of some sort, you probably have to deal with the stereotype that developers can’t express themselves among normal humans about normal things. Unfortunately, this blog may not help you with that particular challenge, but it can help improve your ability to communicate with other developers about technical matters. UML (Unified Modeling Language) is a graphical language that is suit-able to express software or system requirements, architecture, and design. You can use UML to communicate with other developers, your clients, and increasingly, with automated tools that generate parts of your system.

If you’re already familiar with UML, you know how powerful and expressive it is — but don’t be surprised if you’re impressed all over again by the new features of UML 2. Perhaps you found some parts of UML too complicated or the apparent benefit too obscure. Well, the UML gurus have revamped UML in many areas — making easier to express yourself exactly and clearly — and they have also added fresh capabilities for the latest software- and system-development problems that you’re facing.

But because your problems are complex — and your solutions are some-times even more complex — UML is not always simple to learn. It’s a large and multifaceted language, capable of helping in all areas of development, from analysis to test as well as from database to embedded-real-time. To some, it’s a bewildering array of diagrams and symbols. Sometimes it might appear to you that the UML gurus purposely make it too complicated (and with UML 2, even more so) for the rest of us to understand.

 

So, with straightforward English and concrete examples, we give you a leg up on expressing yourself and being more creative on the job. (Hey, it could help you get a raise — just don’t expect us to help you get a date.)

There’s a right way and a wrong way to use this blog. Luckily (like its subject, UML 2), this blog is remarkably versatile. If you’re a traditionalist, you can read it from cover to cover (although you’ll probably stop at the index). That’s a great approach if you’re really new to UML. If you’re familiar with earlier versions of UML, you can skip around looking for the new UML 2 stuff. You may miss our (ahem) great insights into the rest of UML, but you know why you bought the blog — do what works. Using any of these techniques will get you familiar with your blog so that you can count on it to help unstick you if you hit a snag with UML.

After you make friends with your blog, you’ll probably find yourself taking advantage of its just-in-time features. With just a bit of page flipping, you’ll be at a section that’s full of examples, tips, techniques, and warnings that will help you with your UML modeling.

There are other ways to use this blog . . . and some of them are wrong ways. It’s not going to work that well as a doorstop (wrong size), and it probably won’t impress your date (unless you’re dating a developer who’s new to UML). However, it’ll look great on your bookshelf — silently conveying to your boss your desire to improve — but if you never open it, you won’t get the full benefit.

If you’re reading this, we can safely assume that not only have you already opened the blog, you’re probably also a developer of software, systems, or databases, and you want to read or write UML 2 diagrams. Perhaps you’re a manager or business analyst in the same boat.

We won’t assume that you know any particular computer language, although knowing one will certainly help. For the most part, we assume that you fall into one of two major categories: Either you’re a modeler (with a yen to communicate requirements or how you think the world works), or you’re a developer (looking to explore alternative designs or communicate your results). Either way, this blog is for you.

We assume that you’re capable of using a tool to draw UML diagrams — we don’t care which one. If the only tool that you have your hands on is in your hands (as opposed to on-screen), you won’t be at a disadvantage when you use this blog (although your diagrams won’t be quite as tidy if you’re drawing with a stick on wet sand). You may even be better off doing some diagrams by hand; electronic UML tools are often expensive and may not yet be up to date with all the neat UML 2 features that we cover.