The design of your system has important implications throughout the life of the project. LabVIEW is a software language like any other, the rules and lessons learned by other software
Your source code is a reflection of your programming ability and a public document of your
The costs of poor design are:
High maintenance costs
Unpredictable application behavior
If you have not
Object Orientation is good because you can model real-world objects using it. These principles are so easy to understand you probably
The picture in Figure 4.2 explains it all, now go forth and write great software. But, you could also have dogs and cats as:
class : pet
class : animalsThatSitInYourGarden
class : thingsThatMakeMeSneeze
subclass : Canis and Felis
Although the picture and description accurately model the complexities of my dog, she is exceptionally stupid, and they do little to
Flippancy aside, OO Design, Analysis, and Programming have brought a lot to the table of software design. The characteristics of OO
So what do we do with OO in LCOD? We use the
How do we identify possible components? A technique often employed for identifying classes is something called a
Another technique that is more relevant to the projects you will most likely be working on (test, monitoring, or control systems) is to look at the physical entities that will exist in your system. Measuring devices, environmental control, and
A great benefit to us is that when we have identified our components, future change (and there will be plenty as the project progresses) is confined to the components
The one thing that OO does is it allows us to look at the problem at a high level of abstraction, but is not so good when coming to low-level structuring.
Top-down design sounds like you start at the very top of your application and start decomposing it into routines. This can be the case, but it is just as applicable when we take our components, which we have identified using OO techniques, and want to decompose them into the modules and inner components that will make them function. The main thing here is that we as mere
The basic way we use top-down design is to take whatever we want to decompose and look at it from the top, split it into components and look at those new components, then split them, and so on. When do you stop? Probably when it would become easier to write the code than carry on decomposing.
A prime example of where top-down design comes into its own is in designing
We consider this to be the
Either way, both bottom-up and top-down are extremely useful in attacking the design problem. Sometimes you can try and tackle the problem using OO, not get it right, then try top-down, not get it right, and then try bottom-up. Essentially, they all give you the tools to attack the problem from all angles.
So, we've covered a little OOD, a little top-down, a little bottom-up, but what about a little experience?
How many times have you had a design d j vu ”that feeling that you have
solveda problem before not knowing where or how? 
” E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software
 From Gamma, Helm, Johnson, Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software , 1995 by Addison-Wesley Publishing Company. Reprinted by permission of Pearson Education.
Experience is something, in our
Recognizing patterns in software is something most people will do quite naturally without realizing it. However, realizing it, documenting it, and then using it has huge payback. Most discussions of patterns in software are confined to OO, which is a shame since patterns are applicable to any software and design methodology.
So what is a pattern?
Pattern ” A model or original used as an
archetype. A plan, diagram, or model to be followed in making things.
Design Pattern ” A pattern is the repeated occurrence of a solved problem.
Giving your software modules a limited interface by using message sending gives
There are low-level patterns (a state machine is a design pattern), but we are going to concentrate on the higher level patterns that can be applied to complete systems.
So what do you get from the identification and use of patterns? It has been said that the difference between good and bad designers is that a good design does not solve every problem by applying first principles. They cheat!
Following is a list of what using patterns can do for you:
Reuse of design
Reuse of components
Questions to ask (helps with requirements gathering)
Cycle of reuse. The use of patterns encourages the reuse of components. (You can add more functionality to reused components because they are identified as useful and usable, and you already have the context in which they are going to be used.)
Take a test system for example, if you break it down right you will find it is very similar in structure to most other test systems. Each test system has a lot of scope for reusing code. For example handling the User Interface, Handling Data, Reporting, Error Handling, and executing the program. To illustrate the advantages this
It is much easier to edit a design than to create a new design. Most
Reusing the design
This is a good one. If you have a design pattern and a set of components that have actions and attributes to define you can use this as a basis to ask very specific questions of your customer. Requirements are far easier to gather when based on specifics.
Applying a reusable design encourages the reuse of components, and reusing components
Top Level : User Interface>> System>>Hardware
User Interface : Menu Submenu Tree Pattern
Data Handling : Section Keyed Data Handling Pattern
Hardware : Control>>Drive>>Read
One of the problems with LabVIEW is that it is difficult to decouple the display from the actual program execution. This tends to make diagrams flatter and larger than they should be. It also encourages the passing of data down the hierarchy where it isn't necessary. This results in inflexibility in design. The UI Controller>>Message Queue Pattern (Figure 4.4) draws its inspiration from the tried-and-
The display can be changed more or less
The User Interface can be designed and tested isolated from the rest of the program (by using a simple test stub).
The definition of the display is a matter of describing all the different states of the display.
Adding new functionality does not weaken the structure of the program. It's just another message and corresponding action.
Regarding the method, Figure 4.5 describes the Hardware actions in gradually more detail, starting with the Hardware VI, which has commands that describe the tests or actions being
Going to the next level then introduces the Control, Drive, and Read VIs. Sometimes you won't need all of them, so exclude any that aren't applicable, we don't mind. Again the commands you define for these components will look toward the system. So in the example mentioned previously the Control component would have commands for connecting the Unit, the PSU, Signal Generator, and the selected measuring equipment to the test system. The Drive component would have commands to provide the signal and set the PSU. Finally, the Read component would have commands to return the required measurement.
Control : Environmental Control, Switching
Drive : Signal Generation, Power supply setting
Read : Multimeter, Oscilloscope, Thermometer
A complete discussion of patterns would fill a whole other book (see the footnote at the beginning of this section). However, understanding that they exist and applying them should become second nature.