Chapter 4. LabVIEW Component Oriented Design (LCOD)

   

---

Why LCOD? LCOD is just an acronym. It provides a convenient label that encompasses what we are trying to get across. So let's start with a statement. In our opinion Component Oriented Design (COD) is the best approach for developing software in LabVIEW.

COD is applicable to all software design, and certainly the same problems present themselves when beginning the design process ”irrespective of the chosen language that will be used to express the design. The problem we have to solve is to take the requirements for a system and create the application. This book is about using LabVIEW to express the design, and that design being a component oriented approach, hence LCOD. So why use components at all?

Often, at project inception, there is no clear definition of the boundaries that exist in the pieces that will make up the application. So, developers naturally will pick on the interesting bits. What happens is that the bits that get picked become the driving force for the rest of the application. What transpires is not elegant.

If scant attention is paid to all components that could make up a system, clarity in the solution is diminished, if not lost. Have you ever looked at a program in which it is not obvious where one function ends and another begins? All the software is intertwined, and as it grows the relationships become more complex and the application more brittle. Eventually, even minor changes cause catastrophic failures. Identification of offending code or problems is no trivial task, and most importantly where to look is not obvious, meaning the whole application may have to be scanned to locate the problem.

Our task is to identify the cooperating components that will make up the system, then make them as autonomous as possible. The strength in the application is built on the loose coupling that we define between our components. This point is probably hard to grasp if you haven't used it before, and often with simple ideas it is hard to appreciate the benefit until used.

At this stage you may well think, "Well, that's okay for small projects, but we work on large projects and a couple of components aren't going to help us!" This is true, a couple of components aren't going to solve the whole problem, but they will solve a small part of it. What you will get at the highest level are three maybe four components. Then, each component is further decomposed into components within components, and so on.

From what has been stated previously, we know that components that are cohesive and loosely coupled are our best bet for a robust application. Well that's all fair enough, but how the heck do we go about identifying the components? Well, a little OOD, a little top-down, a little bottom-up, and a little experience.

First let us look closer at the components themselves.

---

Top