1 / 19

Graphical Object-Oriented Programming

Graphical Object-Oriented Programming. Jörgen Jehander - ENDEVO Stepan Riha - LabVIEW Software Engineer Thu 10:15a, 12:45p, and 3:30p Red River (4B). Overview. Problems with monolithic applications Conventional development Component-based development Using components in LabVIEW

lucian
Download Presentation

Graphical Object-Oriented Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Graphical Object-Oriented Programming Jörgen Jehander - ENDEVO Stepan Riha - LabVIEW Software Engineer Thu 10:15a, 12:45p, and 3:30p Red River (4B)

  2. Overview • Problems with monolithic applications • Conventional development • Component-based development • Using components in LabVIEW • Implementing OOP in LabVIEW

  3. Problems with Monolithic Applications • Difficulties we face: • Design can quickly become confusing • Numerous developers increase problems • Testing is not straightforward • Difficulty finding and correcting bugs • Expensive to add functionality

  4. Conventional Development • Top-down design • Functionality abstracted into subVIs • GUI often designed first • SubVIs often created from sections of virtual instruments (VI) • State information stored in global variables • Data dependencies • Race conditions

  5. Conventional Development • Case study – climate control system • Maintain a desired temperature using a heater, cooler, fan, and temperature sensor

  6. Conventional Development • Climate control system

  7. Component Program Component A Component B Component C Component D Component E Component-Based Development Monolithic Program

  8. Component-Based Development • Design begins by identifying components • Look at the problem description • Think in higher level terms • Decide on responsibility and behavior of each component • Test each component on its own • Application is built up from components • They snap together like Lego blocks • You can add new pieces in the future

  9. Component-Based Development • Case study – climate control system Controller Heater Cooler Fan Temp

  10. Component-Based Development • Climate control system

  11. Designing Components • Responsibility first • Determine component behavior • Decide on component responsibilities • Interface second • Select which functions you should use to control the component • Implementation third • Test component

  12. Using Components in LabVIEW • Queue VIs • Responsibility • Passing data between diagrams running in parallel • Using FIFO buffer for string data • Interface • Create queue • Insert queue element • Remove queue element • Destroy queue

  13. Classes, Methods, and Objects • Classes • Implementation of components • Methods • Public interface to component • Objects • Instances of class data

  14. Implementing OOP in LabVIEW • Should use the same as built-in components • No direct language support in LabVIEW • Object management implemented on diagram • Class Wizard • Automatically generates class and method VIs

  15. Implementing OOP in LabVIEW Class New Creates an object Class Delete Destroys the object Class Get Data Reads object state information (read-only) Class Get Data to Modify Class Set Modified Data Reads and writes object state information

  16. Implementing OOP in LabVIEW • Class Methods • Implemented using Get Data or Get Data to Modify and Set Modified Data VIs

  17. Class Wizard Demo

  18. Graphical Object-Oriented Programming Conclusion • GOOP and Components improve: • Reusability • Testability • Maintenance • Scaleability • Team development • GOOP is built on: • Classes, objects, and methods

  19. Questions?

More Related