Random Ramblings on LabVIEW Design

There is a popular misconception that the LCOD methodology described in our book ("A Software Engineering Approach to LabVIEW") is in some way related to FGVs (Functional Global Variables). This is because the construction of what we call components is superficially similar. i.e. you have an enumerated command, permanent data held internally to the VI (usually in a shift register). This has been used as a stick to beat us with and IT ENDS HERE!!! (to use a Hollywood cliche).

First of all let's take a look at a classic FGV...

This is no different than doing this with globals...

Or this in OOP....

I could carry on with different ways of storing and accessing data globally, but I have to earn a living.

So why is this a bad thing?

Global data in software is bad because it is Common coupling.

Common coupling (also known as Global coupling) is when two modules share the same global data (e.g., a global variable).

If a lot of VI's are poking around in the same data space it becomes hard to predict what the program is doing, hard to maintain and hard to read. In short it ends up a difficult to debug, inflexible and confusing mess.

How does our methodology differ from this?

We clearly state that a component should have local memory that is private, so while you can make access to the data public (as you can with OOP) it's not a good design idea.

We use the term components, others use the action engines but they are not FGVs!!!

Code Smell #2: Too much global data.

LabPHEW!!!

When you go to a restaurant and the rest-rooms are unhygienic it is fair to assume that the food will be rubbish. The same intuition can be applied to software designs. This feeling that something is wrong or going wrong is a code smell and it's grown up sibling is an anti-pattern.

An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context. http://sourcemaking.com/antipatterns

http://ackandnak.com/comics/your-code-smells.html

Some work has been done on this by the OOP community and the thing that chimed with me is that I have been called into rescue projects and these are large programs, superficially architected using known techniques and yet they are design failures.

With LabVIEW we have an advantage because of it's graphical nature, so a simple test of a design is can you read the block diagram and understand the functionality of the source-code. If not something smells!

I apply some very simple rules when reviewing code, the simplest of which is Make the block diagram understandable!

This example is used as an example as why LabVIEW is a bad language, I find this annoying as it is a poorly designed small application. I would suggest examples like this could be found in any language. The more interesting question is why is it bad?

One technique used when estimating a software designs complexity is called Function Point Analysis and it essentially involves identifying functional decisions and adding them up, each function point can then be described as a lump of work. The code above doesn't have many function points but is almost entirely unreadable.

Training and certification has improved the situation greatly and we are not called in to rectify bad code as often as we were used to, instead the increasing power of LabVIEW has led to more complex code.

With regards bad vs complex I would suggest that complex is worse for the following reasons....

Bad code will usually become unwieldy before it becomes unusable, so if you are fixing bad code it is usually a smaller functioning item.

Complex code is usually on larger systems (and therefore I would suggest more important to a business) and will therefore have a larger weight of expectation about it.

This I think makes a large project more likely to fail and the impact of that failure much more painful.

The link below gives the best measurement of your code when being reviewed http://www.osnews.com/story/19266/WTFs_m

Writing code … is not an exercise in manliness— Mark Hahn

Code Smell #1: Can an experienced LabVIEW programmer understand the block diagram? If not, something is up....

In future blogs I'll be looking at complexity in greater depth. A final pithy quote and that'll do for me!

"The majority of the cost of software is incurred after the software has been first deployed. Thinking about my experience of modifying code, I see that I spend much more time reading the existing code than I do writing new code. If I want to make my code cheap, therefore I should make it easy to read.” – Implementation Patterns by Kent Beck

We've been banging on about the advantages of using proper design techniques in LabVIEW for well over 10 years and I'm not about to stop now. To start my blogging career I thought it might be a good idea to describe what we mean by good design.

A good design....

1. Simple things are easy to change, more difficult things do not make the system unstable.
2. Can be understood by an average LabVIEW programmer.
3. Is robust enough for the customers requirement.
4. Performs to customers expectations.
5. As much as possible can be reused.
6. Is predictable in the way it works.
7. The block diagram represents and describes what the source code is doing.

I also want to establish some separation between the tools and the design.

1. OOP -->tool
2. LCOD -->tool

The key is if you can make a bad design with it,  then it is a tool. A tool is used to express your design. So saying you are a good designer because you use OOP is like saying I'm a good architect because I use concrete!

I would also like to put some distance between declarations not backed up by evidence .

The following are common statements.

• Globals are bad --> not for storing globally required data they are not, unlimited use of global data is bad!
• LabVIEW Functional Globals are bad --> see above
• Sequence structures are as bad as gotos --> again for enforcing a sequence of events they are OK, there are better ways to do it but let's keep it in perspective, there are bigger fish to fry.

It is better to use a technique knowing the consequences than not knowing the risks at all.

On the coming subjects I really want a discussion, there are elements to these ideas that will need properly exploring.

For many decades the following ideas have contributed most to the design arena (in whatever language you use). Get a feeling for these concepts and you'll make your programming life less stressful, guaranteed!

Coupling

http://en.wikipedia.org/wiki/Coupling_%28computer_programming%29

Example: Using globals is bad because global memory is very tight coupling. If any subroutine can access and change data at any time it doesn't take a genius to work out that this will make the code hard to understand.

Cohesion

http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29

Example: Keep all like functionality encapsulated into one VI. The encapsulation needs to be done at block diagram level, using references, lvlibs, classes is not as helpful.

Take the following Use Case.

An instrument is used throughout a test system, it has 50 functions that can be set by sending text commands via a serial port. A non-cohesive method is to send commands at each point in the test via VISA. The implications of this design choice (and believe me we've seen it) is that if you change the instrument you will have to find every VISA call related to this instrument and change the text.

Information Hiding

http://en.wikipedia.org/wiki/Information_hiding

Hiding the implementation detail behind a defined interface allows changes to be made internally without affecting the rest of your code. I've come to the conclusion that this is probably the most important thing to understand.

Things I'm going to be discussing in future blogs (as and when I get the time and energy)

• LabVIEW Anti-Patterns (code smells).
• Coupling and Cohesion with regards to state machines.
• Dynamic Design consequences.
• Ways to simplify your code.
• anything else I can think of..

Lots of Love

Steve Watts

Sales pitch....I'm always interested in really really easy work with large budgets