Good Introduction to UML
UML Distilled by Martin Fowler
Unified Modelling Language (UML) is a standard way of graphically describing and designing software. If you are like a lot of LabVIEW programmers (myself included) and are a physicist, scientist or engineer by training and not a computer scientist, you may not have been exposed to it much, if at all, in school. I first learned about it when I started using Object Oriented Programming in LabVIEW. I absorbed a bit from various websites and blogs but never had any formal training. That is why I was excited when I found this book.
Understanding UML can be a little daunting. The specification is rather long and covers a lot of areas. There are some schools of development that use UML as a blueprint. They model everything about their design up front in UML and then import it into a tool that generates code. That is part of what makes the specification so complicated. In order to support the use of UML as a blueprint, it has to contain lots of detail.
Fowler’s approach to UML is much more lightweight. He talks about using UML as a sketch. In this sense, it is used as a communication tool instead of as a building tool. This happens to be the way I see UML used most often, particularly in the LabVIEW community. Instead of trying to include every detail in a UML diagram, Fowler talks about pairing it down to the essential details you are trying to communicate. These UML diagrams become much more informal and dynamic.
Fowler talks about all the major types of UML diagrams. Unless you are already very familiar with UML, there are probably more than you realized. He does a good job of not getting bogged down in esoteric details but hits the most useful notations. He is also not legalistic. He mentions several popular alternative notations that are not officially part of the UML. He also does a very good job of pointing out the differences between the various diagrams and when to use one over the other.
Fowler also sprinkles a variety of design tips and tricks throughout the text. One of the more interesting ones is on page 62 where he introduces Class-Responsibility-Collaboration (CRC) cards. I haven’t tried it yet, but it seems like a good way to get a group of people together to collaborate on design decisions.
Lastly, probably the most useful part of the book is the inside of the front and back covers. It’s got one of each of the basic diagram types. All of the shapes and arrows are labeled as to what they represent. It’s a very good quick reference.
A basic understanding of UML is very useful when reading books and articles about software development. It provides a very clear and concise method of communication that transcends individual programming languages. For example, I don’t know anything about JAVA, but I recently read a book about refactoring where all the examples were written in JAVA. I could make a pretty good guess about what was going on, but the UML diagrams made everything very clear.
NI Week is less than a month away now. A lot of the presentations there will make use of UML diagrams, particularly class diagrams. If you are not familiar with them, it might be a good idea to brush up. I will likely bring my copy of this book with me so that if I don’t quite remember the difference between an open and closed arrow, I can quickly look it up.
