book

A Software Engineering Approach to LabVIEW™

by Jon Conway, Steve Watts

May 2003

Intermediate to advanced

240 pages

4h 27m

English

Pearson

Read now

Unlock full access

The Test Engineer's PerspectiveAcknowledgments
1.1. LabVIEW Sucks1.2. Don't Buy This Book1.3. The Soap Box1.4. What This Book Is
2.1. Why Does LabVIEW Rock?2.2. What Advantages Does This Bring to the Developer?2.3. How Can Good Design Leverage These Advantages?
3.1. Why is Software Complex?3.2. Coupling and Cohesion3.3. Information Hiding and Encapsulation3.4. Examples of Coupling, Cohesion, and Information Hiding3.4.1. Bad (Tight) Coupling3.4.2. Good (Loose) Coupling3.4.3. Bad (Weak) Cohesion3.4.4. Good (Strong) Cohesion3.4.5. Bad Information Hiding3.4.6. Good Information Hiding3.5. Abstraction
4.1. Components4.1.1. So What Is a Component?4.2. Design4.2.1. Object Oriented Design (OOD)Classic OO Lesson4.2.2. Top-Down Design4.2.3. Bottom-Up Design4.2.4. Design PatternsReuse of DesignReuse of ComponentsQuestions to AskCycle of Reuse4.2.5. Pattern ExamplesUI Controller>>Message Queue PatternControl>> Drive>>Read Pattern
5.1. Component Mechanisms5.2. Message Sending5.2.1. All About Enumerated Types5.2.2. 101 Things to Do with an Enumerated TypeFormat into StringScan from StringTypecastCasting and UncastingCase StructureFiring a Sequence of EventsState Machine5.2.3. Strict Type Definitions5.3. Persistent Local Storage5.4. The Basic Structure of a Component
6.1. State Machines6.1.1. State Machine Example—Washing Machine6.2. Graphical User Interface (GUI) Design and Prototyping (UI Controller>>Message Queue Pattern)6.2.1. Stack Queue Component6.2.2. User Interface Control Wrapper VI6.2.3. LCOD User Interface Example Diagram6.3. Abstraction in the Code, Detail Outside the Code6.3.1. Section Key FilesInvalidGetSetSaveLoadSave AllLoad AllReset6.4. Error Handling6.5. Pre- and Postconditions: Check What Comes In and What Goes Out6.5.1. Preconditions6.5.2. Postconditions6.5.3. Conclusion6.6. Reuse6.6.1. Opportunistic Reuse6.6.2. Planned Reuse6.6.3. Merge VIs6.6.4. VI Templates

Fairy TalesHorror Stories7.1. The Usual Suspects7.2. Requirements DocumentWho is the Real Customer?What Constraints Are There?How Do You Manage Expectations?What is the Big Picture?7.3. Quote/Project Validation7.4. Target Specification7.5. Test Plan7.6. Software Architecture Document7.7. Software Construction—Build7.8. Test—Customer Acceptance7.9. Pictures Tell a Thousand Words7.9.1. Diagrams—Data Flow Diagrams (DFDs)7.9.2. State Transition Diagrams7.9.3. Homemade Diagrams7.10. Checklists7.11. Code Reviews7.12. The Project Is Dead, Time for a Postmortem7.13. Metrics
8.1. Why Do We Need Standards Anyway?8.2. Block Diagram8.2.1. General Layout Standards8.2.2. Wiring Standards8.2.3. Labeling Standards8.2.4. Self-Documenting Example8.3. Front Panel8.3.1. General Front Panel Standards8.3.2. Public Front Panel Standards8.3.3. Private Front Panel Standards8.3.4. Icon and Connector Standards8.3.5. Organization of Files
9.1. Agreeing on the Destination (Requirements)9.2. Planning Your Route (Design)9.2.1. Code and Fix9.2.2. Abstracting Components from RequirementsDisplay HandlerTest SystemHardware ComponentReport ComponentData ComponentConfiguration ComponentInitialization9.2.3. Using Patterns to Help the Design ProcessUIUI StatesUI AttributesProgram Executive StatesHardware ActionsHardware Attributes9.2.4. Building the Prototype9.3. Build9.3.1. Code and Fix9.3.2. LCOD9.3.3. HardwareHardware ActionsControl ActionsDrive ActionsRead Actions9.3.4. Detail Outside the Code9.3.5. Error Handling9.3.6. State Machines9.3.7. ReusePatternsVIs With Little or No Modification9.3.8. Style9.4. Uh-oh We've Been Given the Wrong Directions9.5. Conclusions

Overview

Create more robust, more flexible LabVIEW applications—through software design principles!

Writing LabVIEW software to perform a complex task is never easy—especially when those last-minute feature requests cause a complexity explosion in your system, forcing you to rework much of your code! Jon Conway and Steve Watts offer a better solution: LCOD-LabVIEW Component Oriented Design—which, for the first time, applies the theories and principles of software design to LabVIEW programming. The material is presented in a lighthearted, engaging manner that makes learning enjoyable, even if you're not a computer scientist.

LCOD software engineering techniques make your software more robust and better able to handle complexity—by making it simpler! Even large, industrial-grade applications become manageable.

Design to embrace flexibility first, making changes and bug fixes much less painful

Pragmatic discussion of the authors' tried and tested techniques, written by—and for—working programmers

Covers design principles; LCOD overview, implementation, and complementary techniques; engineering essentials; style issues; and more

Complete with practical advice on requirements gathering, prototyping, user interface design, and rich with examples

Work through an example LCOD project (all code included on companion Web site) to tie the lessons together

This book is intended for test engineers, system integrators, electronics engineers, software engineers, and other intermediate to advanced LabVIEW programmers. None of the methods discussed are complex, so users can benefit as soon as they are proficient with the syntax of LabVIEW.Go to the companion Web site located at http://author.phptr.com/watts/ for full source code and book updates.