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. 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
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
7 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!
Reply
Jon McBee
8/21/2015 09:16:55 am
Hi Matt,
Reply
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.
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
Siobhan Straver
4/30/2021 10:53:35 am
Great post, I laughed out loud at the 'do something'..*do*.. 'I'm on fire'
Reply
Leave a Reply. |
Tags
All
Archives
October 2019
LabVIEW Blogs |