LabVIEW Craft
  • Blog
  • About
  • Contact
  • Tools
  • Resources

Simple UML

8/25/2015

6 Comments

 
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.  
Picture
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).
Picture
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.
Picture
We can give the bicycle an attribute like color, and accessor methods to get and set the color.
Picture
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.
Picture
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.
Picture
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.
Picture
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.
Picture
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
6 Comments
Matt Gould
8/21/2015 07:56:14 am

This is a great post. I looked at a couple of different websites and this post cuts right to the chase. I like it a lot!

I'm still a little unclear on the difference between association and aggregation.

I am assuming that composition means that the person who is on the black diamond side of the arrow is the person who has instantiated the class on the other side of arrow. The black side of the arrow person would keep the instantiated class in its own member data.

Then does association mean that the class who is using the class on the other side of arrow has taken the class in as the input a function and then can do things with it? I.E. The "commute" function of class "commuter" takes in a "bycycle" object as an input and can then do something with it?

Reply
Jon McBee
8/21/2015 09:16:55 am

Hi Matt,

Thanks for the feedback. I updated the UML to help out a bit (Should have gone through it again before I posted it) so that you can see that with aggregation the Bicycle class actually has a Bell object in its class data. Aggregation is saying that every Bicycle object in my application will have a Bell (and as such the Bicycle object will construct and deconstruct the Bell (not that those actions are explicit in LabVIEW)). With association we are saying that the Commuter uses a bike, but that there is no Bicycle object in its class data. We don't want to say that every Commuter has a Bicycle, it is probably more accurate to say that every commuter has a "Commute" method that uses some method of transportation. This may imply that the Commuter class has an abstract Transport object in its class data, and that Bicycle implements the abstract Transport class, but that is really context specific.

TLDR; Yes, the association means that the Commuter has a method that uses a Bicycle object, but does not have a Bicycle object in its class data.

Reply
Karin Hellqvist link
8/26/2015 07:25:57 pm

A good introduction article on UML and what parts of it that are useful when working with LVOOP. I use class diagrams for every project. Sequence diagrams I haven't used that much, but I can see that it's very useful when working with the actor framework.

I use the UML Modeller in the free NI GOOP Development Suite. It is a good tool capable of auto generating code from your diagrams and reverse engineer code for documentation.

Reply
Vadim
11/18/2015 08:24:12 am

I also use the UML from GOOP. It's only deficiency is that you cant open the UML diagrams, unless you have LV with GOOP add on

Reply
Vadim
2/27/2017 09:01:14 am

sorry, take this back, it's been now fixed

Vadim
2/27/2017 08:54:50 am

Any way to add GOOP add-on to LV 2016?

Reply



Leave a Reply.

    RSS Feed

    Tags

    All
    Abstract Messaging
    Actor Framework
    Agile
    AI
    Asynchronous Programming
    Best Practices
    C#
    Complexity
    Continuations
    Control Values By Index
    Craftsmanship
    Dependency Inversion
    Dependency Viewer
    Futures/Promises
    Genetic Algorithm
    Liskov Substitution
    Malleable VIs
    Mediator Pattern
    .NET
    Object Oriented
    Object-Oriented
    Packed Project Library
    Parallelism
    Polymorphism
    Pub/Sub
    RawCap
    Root Loop
    Scrum
    Task Parallel Library
    TCP/IP
    TDD
    Test Engineering
    UML
    Unit Test
    VI Scripting
    VI Server
    WireShark

    Archives

    April 2019
    July 2018
    October 2017
    March 2017
    February 2017
    January 2017
    December 2016
    July 2016
    June 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    December 2015
    November 2015
    October 2015
    August 2015
    February 2015
    January 2015

    LabVIEW Blogs

    Eyes on VIs
    LabVIEW Hacker
    VI Shots
    LabVIEW Artisan
    Software Engineering for LabVIEW
    ​Wiresmith Techology
Picture
Powered by the Panda Ant

  • Blog
  • About
  • Contact
  • Tools
  • Resources