This is the next entry in my series of tutorials on how to effectively use the Rational Software Architect (RSA) product to design, construct, and test software-centric systems.
In the last post, I talked about Rational's version 6.0 design and construction products, including how the different products relate to each other and the different features that each possess. RSA has many, many features and can be used for many different purposes, but for these tutorials we'll be focusing on using RSA to visually model software systems. In this particular tutorial, we'll discuss the reasons that we model visually and introduce the Unified Modeling Language, or UML.
Please note that discussions on modeling often get very abstract and theoretical. Though modeling theory is very interesting, I will keep this tutorial very concrete and basic, so as not to frustrate folks who are new to these topics.
If you're reading these tutorials I assume that you have some experience designing software-intensive systems. If this is the case, it is very likely that at some point you have drawn a diagram to represent aspects of your system. Why do you do this? Why do you draw diagrams of your system and its parts?
I'm serious, think about it for a minute.
We draw diagrams because it helps us to understand and reason about these very complex and very intangible things we call software systems. We draw diagrams because it helps us to capture knowledge that is hard to express verbally. We draw diagrams because it gives us something tangible to discuss with colleagues. We draw diagrams because, of the many moving parts inside a complex system, we only want to consider a few of them at the moment and ignore the rest.
So what sorts of diagrams do people draw to communicate software design? People often draw diagrams like the one below:
An example of a typical architectural diagram
At first glance this looks like a fairly useful diagram. But upon closer examination it has some major problems. What do the boxes represent? Applications? Components? What do the lines represent? Data flow? Service invocation? Why is one of the boxes blue while the others are yellow?
The problem is that all of the elements in this diagram - boxes, lines, arrows, and words - lack precise meaning. A reader of the diagram, for instance, may interpret the arrows to represent service invocation, while the author intended them to represent data flow. More likely, the author of the diagram never really considered what the lines meant.
There are a number of ways to avoid this ambiguity. The first way is to create a simple key that describes the meaning of each diagram element; like a roadmap will indicate which type of line represents an interstate highway and which type of line represents a country road. But if everyone invents their own notation, there is a learning curve to look at a diagram from anyone else because their notation is different from yours.
Members of the object-oriented (OO) software community found themselves in a similar situation in the early 1990s. The growing popularity of OO programming languages like Smalltalk and Objective-C led to the creation of a number of OO methods that documented techniques and best practices for OO design. Unfortunately, these different methods, though in basic agreement on the most important concepts and practices, used different terminology and notation, leading to a great deal of unnecessary confusion.
Grady Booch, Jim Rumbaugh, and Ivar Jacobson of Rational Software (now IBM Rational), three very popular and influential methodologists, decided to work together to unify their various methods and create a common set of concepts, terminology, and notation to describe software systems in a consistent way and make life easier for practitioners. They called this the Unified Modeling Language, or UML. The Object Management Group (OMG) adopted UML as its standard approach for object-oriented modeling in 1997 and has managed the development of UML since then.
UML defines a set of object-oriented software concepts (e.g. "class", "subsystem") and the relationships between these concepts (e.g. "association", "generalization") as well as a number of diagram types to visualize these concepts. Though UML is not formally defined using mathematics, it is "formal enough" to allow tool makers (such as Rational) to provide UML modeling and drawing tools and for practitioners from different teams to understand each others' UML diagrams.
Since UML's creation and standardization, it has emerged as the most popular general purpose language to model software systems. There are many tools that support UML and many books that describe its notation and how to apply UML to software projects.
Still, UML is not without its flaws. It is a very large language and it was created by a committee, so it's not always self-consistent. The OMG recognized some of the problems with UML and decided to give it a major overhaul. This resulted in the UML version 2.0 standard which was finally accepted last year. UML 2.0 cleans up many of the overlapping and incorrect concepts found in prior versions. Rational Software Architect and Software Modeler use UML2 and thus it will be the language that we use in these tutorials.
So going back to the diagram above, there is one very positive thing to say about it; it is easy to draw. Fire up PowerPoint, drop in a couple of boxes, some arrows, a few words, and in just a couple of minutes, you're good to go. But you must ask yourself: will the readers of your diagram understand what it's trying to convey if its notation is ambiguous? You could argue that your particular team already understands the systems involved so well that it will make sense to them, but in that case, why even draw it? Also, it is likely that your diagram and the system it represents will continue to be read after you have moved on from the project, so this argument doesn't really hold up.
Now just as the semantic-free diagram was easy but meaningless, UML is meaningful but challenging to the uninitiated. There are two reasons for this. The first is that you have to learn UML's collection of concepts and notation, which is rather large. The second reason is that specifying something with precise semantics involves more rigor than just drawing anything. For instance, PowerPoint won't spit out an error if you diagram something that doesn't make sense; RSA will.
Yet despite the learning curve, it is my opinion that understanding UML is worth the effort. In your effort to learn UML, you will gain a much deeper and more precise understanding of software concepts; you will also be conversant in the emerging lingua franca of software architecture.
So what's the best way to learn UML? First, it really helps to have a background in object-oriented analysis and design, since UML is built upon OO's foundations. If you're new to OO, a great book to start with is Craig Larman's Applying UML and Patterns (3rd edition). Not only does it provide a good introduction to OO, but also to UML and iterative development.
Once you understand OO fundamentals and are ready to focus on UML, I'd recommend a concise overview book like UML Distilled by Martin Fowler. You could be ambitious and dive into the thousand-odd-page UML2 specification, but you'd probably just end up discouraging yourself (it's really targeted at tool-vendors, not end-users). Another good learning mechanism is to experiment with modeling tools like RSA or RSM, which enforce UML rules and provide context-sensitive help on notation.
There's actually quite a bit more to say about UML, but I don't want these tutorials to bury you in theory before you've gained some practical experience using RSA. Be warned, we have only seen the tip of the UML iceberg, but this will be enough to get us going. In the next tutorial, we will gain some practical experience with RSA and UML by creating our first UML model and a basic class diagram within the model.
In the meantime, I highly recommend that you invest some time and money in the books mentioned above and below.
(Note - there are many books on the market that describe UML version 1.x. Because of the fact that RSA/RSM support UML2 and the fact that UML2 is very different from prior versions, favor UML books that have been updated for UML2. The editions of the books mentioned below have been).
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman.
UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition) by Martin Fowler.
The UML User Guide (2nd Edition) by Grady Booch, Jim Rumbaugh, and Ivar Jacobson.
Rational's UML Resource Center
"The Value of Modeling" by Gary Cernosek and Eric Naiburg.
Other IBMers who blog about UML
Thanks to Anand Narayanan, Bobby Woolf, Charles Rivet, Jim Rumbaugh, and Simon Johnston for providing feedback on earlier drafts of this article. Thanks to Grady Booch and Simon for their mentoring on visual modeling and UML over the past two years.
Intro to visual modeling and UML (Learning Rational Software Architect, part 2)