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

Content preview from A Software Engineering Approach to LabVIEW™

Preface

There are many ways of designing and implementing a system. We are not trying to say that you should immediately adopt the techniques presented in this book in place of how you currently design and write software. Specifically, what we are saying is that this is how we design and implement software in real-world applications. We want you, the reader, to draw your own conclusions.

It's important to note that the authors are working engineers who pay their mortgages by writing software, not by writing books.

The Test Engineer's Perspective

Steve Watts writes—

As a normally trained test engineer I've been programming test systems for years and using many different programming languages (HPBasic, UCLA Pascal, Turbo Pascal, Visual Basic, and QuickBasic). ...