Simple UML

Jon McBee

I am by no means a UML guru, however I do believe that UML can help me communicate complex ideas.  In order for this communication of ideas to be useful everyone taking part in the conversation needs to be speaking the same language, but don't panic, not everyone taking part in the conversation needs to be fluent.  

UML stands for Unified Modeling Language.  Wikipedia* provides good detail about the history and details of UML, so I won't duplicate it here.  For our purposes all we care about it is the fact that UML defines a set of rules that define how we visualize the systems we design.  What I want to cover is how I use UML Class Diagrams and UML Sequence Diagrams to help visualize relationships between classes in my LabVIEW code.  These are the two types of UML diagram that I find most useful day-to-day because with these two types of diagrams I can visualize the flow of control of my application (Sequence Diagram) as well as object composition and inheritance (Class Diagram).

Disclaimer: I use UML like a physicist uses math, approximately correctly.  I don't use it with the rigor of a true software engineer, I use it to the point of enabling communication of ideas.  This works for me because the people I communicate with aren't fluent in the language either, if they were I suspect they would get annoyed and walk away.  Everything I talk about below is in the context of how I use UML, which is approximately correctly.

Aside:  Real quickly, there is a joke in this book that I will reproduce here for you:

An astronomer, a physicist and a mathematician are on a train in Scotland.
The astronomer looks out of the window, sees a black sheep standing in a field, and remarks, “How odd. All the sheep in Scotland are black!”
“No, no, no!” says the physicist. “Only some Scottish sheep are black.”
The mathematician rolls his eyes at his companions’ muddled thinking and says, “In Scotland, there is at least one sheep, at least one side of which appears to be black from here some of the time."

Lets take a look at Class Diagrams first.  The class diagram shows how the classes in your software use and inherit from each other.  You can also use them to show the class data and methods of the class, but I usually end up using the diagrams to help me see the bigger picture.  To get started lets look at a very simple Bicycle class.

We can give the bicycle an attribute like color, and accessor methods to get and set the color.

For the sake of making a more interesting UML diagram lets suppose that our bicycle has a bell.  That has a relationship shows object composition, and we denote object composition on the diagram by using a line with a black diamond attached to the end linked to the object that has a something.

Aside: You may also see a line with a white diamond, this denotes aggregation.  There is a subtle difference between composition and aggregation that has to do with whose job it is to create and destroy the contained class (Bell, in the example above).  If you want a better description of the difference between aggregation/composition/association read this.  

But wait, what kind of bell does our bike have?  We could either have a mechanical bell or an electrical bell, and we most likely don't want our Bike to care what kind of bell it has.  We can show this in the UML by making the Bell class an abstract class and giving it two concrete implementations.  Our goal is to show that we can either have an electrical bell that is a type of bell, or a mechanical bell that is a type of bell.  The is a relationship shows inheritance, and we denote inheritance on the diagram by using a line with a triangle pointing towards the abstraction.

The last piece of the Class Diagram that I want to show you is the association arrow.  Lets add a Commuter class to the diagram and show how a Commuters can use a Bicycle.  This uses relationship shows run time dependency, and we denote it on the diagram by using a line with an arrow pointing towards the object being used.

To sum it up, we can use Class Diagrams to show

1. The data and methods of our classes
   
2. The composition of our classes
   
3. The inheritance of our classes
   
4. The run time dependency between our classes
   

Next up is the Sequence Diagram.  The sequence diagram is much simpler and is a very handy way to illustrate how actors interact with each other.

In this diagram time flows from top to bottom and we are actually looking at how our actors interact with each other throughout their lifetimes.  In the case of the Actor Framework, the message arrows going between actors actually map directly to message classes, making this type of diagram extremely useful for visualizing Actor Framework applications.

And that's about it.  I spend most of time in the UML world working with these two types of diagrams.  There are other useful ones out there (checkout Statechart Diagrams and Activity Diagrams) but when it comes to LVOOP the Class and Sequence diagrams are the tools I use.

So what do you think, does UML have a place in your toolbox?  

---

Jon McBee is a Principal Software Engineer at Cambridge NanoTech and is a Certified LabVIEW Architect, Certified LabVIEW Embedded Developer, Certified TestStand Developer, an NI Certified Professional Instructor, and a LabVIEW Champion