Architecting an Application to Avoid Spaghetti

[Elijah_K]

One of the most appealing things about LabVIEW is that you don't need to be a computer scientist to write fairly large and complex software. For many, their journey with LabVIEW starts in school or at a benchtop with a simple application to quickly acquire some data. Once they're hooked on the ease of graphical programming, it's only a matter of time beforethe ideas start flowing, and pretty soon they're off developing amazing applications like a mind-controlled wheel chair, the world's largest particle accelerator, or how about a 3D Space Ship that flies through a starflied.

The problem is that the same approach people use when throwing together a prototype or a proof of concept will land them in a world of pain if they don't ever stop and consider fundamental questions like, "how should I architect this application?" All too often, I see the tangled mess of spheghetti code emerge as the result of thoughtless, or ill-planned development.

For most people, their very first experience with LabVIEW leads to messy, un-readible code.  Even LabVIEW gurus have humble beginnings.  The expert G developer, D Natt, was kind enough to send me a screenshot of his very first LabVIEW program. Let the image on the right serve as an example of what not to do. If you find yourself wishing you had 8 more screens to see a single block diagram, or if your block diagram looks anything at all like this one, you may want to consider giving more thought to the architecture of your application. As an exercise, see how long it takes to determine what the VI on the right actually does.

It's important to realize that spaghetti code is not unique to LabVIEW. As someone who started with text-based languages, I've seen plenty in all sorts of different languages. The difference is that it's a lot easier to write graphical code that will run, even if it's completely illegible. When the result doesn't work correctly or yields unexpected performance, it can be very difficult to debug and many prefer to point the finger at LabVIEW rather than acknowledge their own lack of foresight or experience.

So lets turn our attention to how we can architect our LabVIEW application. Start with the main problem you're trying to solve and figure out what the software needs to be able to do in order to be considered 'succesful.' The criteria that emerges from this assessment will help you make informed decisions about how the code should be structured. This is, in many cases, the product of experimenting, prototyping and developing proof of concepts that highlight the areas of difficulty and help you understand what type of information or data will need to be shared between different 'pieces' of an application.  At this point, we need to take a step back and make sure we understand design patterns.

A 'Design pattern' refers to a template that serves as the building blocks for software. If you have an application that requires a responsive user interface, consider how many other developers have been faced with the exact same requirement. You're not alone, and there's no reason you should be starting from scratch. Design patterns are universal to programmers in any programming language. They save you time by helping you avoid reinventing the wheel and give us the solutions to common problems that have evolved over time to be the best, and most appropriate solution. If you're new to design patterns, check out the File >> New dialog in LabVIEW (show on the left). This is a great place to get started with some basic design patterns that are very specific to LabVIEW. Be sure to read the descriptions to understand exactly what problemsthey can best help you solve.

I also recommend visiting expressionflow.com. Anthony Lukindo wrote an excellent, indepth article on the QSM-PC (Queued State Machine - Producer / Consumer) design pattern, which is a fairly common and very useful pattern for a-sychronous computations in a fairly large application.

For those of you familiar with text-based design patterns, AristosQueue posted a great article filled with examples of how to map classics like the Factory Des...

The JKI State Machine also serves as another great template for developing clean code.

Architecting a high-quality piece of code ensures that it's readible, scalable, maintainable and reduces the chance that errors or incorrect behavior will occur. I've focused a lot on design patterns, but don't lose sight of the fact that just is one small piece of the puzzle. You'll also want to think about how the application can be modularized and design APIs early on. Oh and of course, documentation is paramount.

One final word of caution: keep it simple and pick the archicture best suited to what you're doing. But as always, have fun