OpenGOOP - a component framework

1. OpenGOOP - a component framework As presented by Jim Kring June 3rd, 2003

2. Presentation Outline • LabVIEW Components • What is GOOP? • How is OpenGOOP different? • Advanced GOOP design patterns and building the patterns into the framework OpenG Group Meeting

3. LabVIEW Components • A set of VIs that allow you to instantiate and interface with an “object”. • Abstracts the implementation and the hides its data • Operate by reference (Refnum) OpenG Group Meeting

4. LabVIEW Component Examples • Queues • File I/O • Config File I/O OpenG Group Meeting

5. Why Components? Encapsulation • Benefits of Encapsulation • Maintainable • Scalable • Useable (and therefore Reusable) • Testable • Enable Multiple Developer Collaboration OpenG Group Meeting

6. What is GOOP? • GOOP Toolkit from NI (Endevo) • JörgenJehander & Stepan Riha • An Object and Data Manager (CIN) • A Class Template and Wizard • Object Inspector OpenG Group Meeting

7. The GOOP Core • <Class> New.vi • Creates an object • <Class> Delete.vi • Destroys the object • <Class> Get Data.vi • Reads object state information (read-only) • <Class> Get Data to Modify.vi • Locks and then Reads object state information • <Class> Set Modified Data.vi • Writes object state information and releases lock OpenG Group Meeting

8. Locking – Synchronous Write Access • Two parallel processes want to write data to the object. • Allowed Sequences 1) A  B  C  D 2) C  D  A  B • Else, Race Cond’n • B • A • C • D OpenG Group Meeting

9. The Class Template • <Class>Create.vi • Allocates space for, and allows initialization of, object data • <Class>Read Data.vi • Reads the object data • <Class>Modify Data.vi (Write Data) • Allows you to modify object data • <Class>Destroy.vi • Deallocates the object data OpenG Group Meeting

10. Object Data Store • NI GOOP • ?? Password Protected • OpenGOOP • Reentrant LV-2 Global Called By Reference • Object Refnum is a VI Reference OpenG Group Meeting

11. Reentrant LV-2 Global Called-by-Ref Call-by-Reference Wrapper Reentrant LV-2 Global Reentrancy of the data-store allows multiple concurrent object instances to be created. OpenG Group Meeting

12. Benefits of RLV2GCBR data store • Multiple object instances • LabVIEW (VI Server) handles the memory management, housekeeping, and garbage collection, etc. • When the top-level VI goes idle, the object is destroyed (as with all VI server object references). OpenG Group Meeting

13. Locking the Data Store Acquire Semaphore Release Semaphore OpenG Group Meeting

14. Generating the Semaphore • Named Semaphore “<ObjName> - 0xFFFFFFFF” OpenG Group Meeting

15. 2 3 1 OpenGOOP Wizard • Instantiates a Class Template, adding a name prefix to the new class. OpenG Group Meeting

16. New Class Main VI Tree Core VI Tree OpenG Group Meeting

17. Advanced GOOP Design Patterns • Object State Persistence and Initialization • Saving and restoring object data to and from file • Encapsulation of Processes • Make the class responsible for starting and stopping its processes • Encapsulation of User Interfaces • Build User Interfaces into Class • Component Abstraction • Define a class’s “abstract” interface at edit-time, but choose the “concrete” implementation at run-time OpenG Group Meeting

18. Object State Persistence - Write • Write object data cluster to ini file using OpenG variant configuration file I/O OpenG Group Meeting

19. Object State Persistence - Read • Read object data cluster from ini file using OpenG variant configuration file I/O OpenG Group Meeting

20. Encapsulation of Processes • Users of components should NOT have to interact with process VIs • Processes should run asynchronously • Spawning should be done behind the scenes during object instantiation • Processes should be killed automatically when object is destroyed OpenG Group Meeting

21. 1 2 6 3 4 5 The Old Way – User Interaction Req’d Temp Controller Obj • Create New Obj • Start Process(Blocked until 5) • Set Temp • Monitor Process • Stop Process • Destroy Obj loop OpenG Group Meeting

22. A Better Way – Hide the Process • “Spawn” within constructor • “Kill” within destructor • Non-blocking “enable” & “disable” controller methods are still an option OpenG Group Meeting

23. Spawning Processes • Process VIs are reentrant (multi-instance) • 1st Pass process the object reference • 2nd Run the process OpenG Group Meeting

24. Killing Processes (1) Send Kill Signal (2) Wait on not running (3) Force Kill (abort) OpenG Group Meeting

25. User Interface Encapsulation • Many user interfaces, especially component configuration panels, are not application specific. • LV7 subpanels open up new options for class UIs. • LV7 Express nodes are a good example of how UIs can be part of a component. • Other examples – XY Stage Control Pad, User manager, etc. OpenG Group Meeting

26. FYI - Express Nodes User Interfaces double-click OpenG Group Meeting

27. Component User Interfaces How can we build user interfaces into classes? • User Interfaces can be just like processes except that their Front Panels are designed for user interaction • UI framework should support calling UIs synchronously (blocking) or asynchronously (non-blocking) • Framework should support multi-instance User Interfaces (cloning) • Object Destructor should kill open UIs OpenG Group Meeting

28. Launching Component UIs • We can encapsulate the management of user interfaces within the class • Open UI, Close UI, UI Position, etc. • We can modify the template to accept UI names as Enums OpenG Group Meeting

29. Example - MyComponent OpenG Group Meeting

30. Component Abstraction • An “Abstract Class” defines an interface, but not an implementation. • A “Concrete Class” has both an interface and an implementation. • The Interchangeable Virtual Instruments (IVI) framework is a perfect example… so is VISA OpenG Group Meeting

31. Abstraction using proxy VIs (CBR) • An abstract class is merely a set of Call-by-Reference proxy VIs. • At run-time, a concrete class is loaded, by the abstract class, to fulfill its implementation. • Loading requires checking for correct interface. OpenG Group Meeting

32. Example Abstract and Concrete VIs Abstract VI obtains a reference to the concrete VI and calls it dynamically OpenG Group Meeting

33. Loading a concrete class • Many methods may be used • Abstract class must know which concrete class (or instance) to load • Concrete class (or instance) should tell Abstract class what its interface looks like. • Abstract class can then choose to continue loading concrete class OpenG Group Meeting

34. EXAMPLE – Conc & Abs Class OpenG Group Meeting

35. Recap • LabVIEW Components are a good way of approaching application and reuse code development • GOOP is a good way to implement components • OpenGOOP is OpenG’s GOOP implementation • OpenG developers are working to push the limits of component based design by identifying component design patterns and building them into the OpenGOOP framework. OpenG Group Meeting

36. Other GOOP References • App Note 143 - Graphical Object Oriented Programming (Jorgen Jehander) http://zone.ni.com/devzone/conceptd.nsf/appnotebynumber/1A7B60096CE0CDA986256A9A0074E4EC?OpenDocument&node=dz52000_us • Graphical Object-Oriented Programming with LabVIEW - NI Week 1999 Presentation by Jörgen Jehander and Stepan Riha http://zone.ni.com/devzone/devzoneweb.nsf/Opendoc?openagent&958B0EEC7BE032B986256863000A6B64 • Object-Oriented Techniques in LabVIEW - Pure G examples from LV 4.1 http://sine.ni.com/apps/we/niepd_web_display.display_epd4?p_guid=B45EACE3EB6B56A4E034080020E74861&p_node=DZ52067&p_source=external OpenG Group Meeting