The Virtual Laboratory is an interactive environment for creating and conducting simulated experiments: a playground for experimentation. It consists of domain-dependent simulation programs, experimental units called objects that encompass data files, tools that operate on these objects. Current release is focused on graphical applications of L-systems, with an emphasis on the generation of fractals and the modeling of plants. The objects are organized, accessed and manipulated using domain-independent vlab system programs. The user can expand the laboratory by adding new objects, creating new experiments and creating hyperobject copies of objects.
The domain-independent framework for the Virtual Laboratory consists of:
A laboratory object is a directory containing files that define the object and a subdirectory extension. The following table 1 shows the file types included for an object.
|*.txt, *.map, *.mat, *.dat, *.s, *.l, *.v, *.a,
|Data files contain our knowledge of a particular model. Each object will vary in the type and number of data files that describe it.|
|specifications||Defines the data files which make up the object and the tools which apply to them.|
|icon||A graphical representation (140x140 pixel screenshot) of the experiment.|
|.id||Contains a unique identification number for the object in the database.|
|ext||A subdirectory of extensions (lists objects which inherit some features of the current object).|
This definition is compatible with the Linux hierarchical file system. Thus the object-oriented file structure (object database) which provides the basis for lab operation can be represented by a hierarchy of directories and files, as shown in figure 1 below.
The path of subdirectories leading to an object establishes the inheritance structure of the lab. Inheritance is based on the idea of specifying new objects in reference to objects which already exist. The old object is the prototype and the new one is its extension. The extension contains only those files which are different from the corresponding files in the prototype. Files that remain the same are inherited from the prototype using symbolic links. Thus the object directory contains those files that are unique to the object, and links to files that are inherited from its prototype. This approach saves space, facilitates creation of objects similar to the prototype and allows a single change in the prototype to propagate through all descendents. Figure 2 below illustrates an example.
In this example model 1.1 is an extension of model 1, while model 1.1.1 is an extension of model 1.1. model 1.1 has different specifications file and data1 file. Additionaly, it also contains a file data3. Since icon and data2 remain the same, they are stored as symbolic links to model 1 files, denoted with yellow arrows. Therefore if data2 was to be changed in model 1, it would affect model 1.1 as well. Notice that such change would also affect model 1.1.1.
Hyperobjects are links to objects in the database. The following information is stored with each hyperobject:
|node||Contains a hyperlink to an object in an
oofs database. Not all hyperobjects need to point to an object in an oofs
database. Those that do not contain a hyper-link are used as place-holders
for other hyperobjects.
Also contains the name of the hyperobject. This description is usually related to the object the hyperlink points to under the given context.
Also contains the order of children. The order of children in a parent can be changed, which affects the traversal of hyperobject databases.
|text||Contains a textual description of the hyperobject.|
|A subdirectory of children (other hyperobjects inheriting from this one).|
The hyperlink in a hyperobject is specified as the ID of the object to which the hyperobject points, allowing hyperlinks to stay intact as long as the objects to which they point remain in the oofs database. Quick access to objects from hyperobjects is made possible by using the object lookup table.
A user may browse through the objects and hyperobjects in the lab by following the hierarchy induced by the prototype-extension relation. The browser provides a visual interface for navigating through the hierarchy. The browser also makes it possible to move, copy, delete and rename objects. At any time, the user may request that the browser invoke the object manager to place a selected object on the lab table. The browser also facilitates the presentation of a VLAB object in several different contexts, as hyperobjects, while keeping the main database intact.
|Note:||In vL1.0, unlike versions for other platforms, the browser and the hyperbrowser are incorporated into one application. The OOFS database contains objects as well as hyperobjects.|
Upon invocation of the object manager, all files that make up the selected object are copied to a temporary location called the lab table. Consequently, manipulation of object parameters does not affect the stored version. When the experiment is completed, the user may save the results by overwriting the original object or by creating an extension. In the latter case, the files on the lab table are compared with those in the prototype object; those files that differ from the prototype are saved, and links to the remaining files are established automatically.
Objects are manipulated using a vlab system program called the object manager, manifested as an icon with an associated menu of operations. The menu lists the tools and utilities available for experimenting with the object, and allows the user to select them dynamically. The user may manipulate the object as a whole, without detailed knowledge of the programs involved or the component files. The content of the menus is given in the specifications file, which is a mandatory file in each object.
The ability to easily manipulate the parameters of an experiment is an important feature of the Virtual Laboratory. All parameters of an experiment are represented in the object's data files. Parameter modification can be performed using virtual control panels. A general-purpose panel manager creates panels according to definition files also included in the object. A panel definition file itemizes the appearance of each control button or slider in the panel, and the format of the message to be sent as a result of control manipulation. These messages are used to edit the data files. As a control on the panel is manipulated, the corresponding parameter in the data file will be updated. The application may then reread the data file to obtain the new values.
The vlab daemon is invoked automatically by other processes, and thus remains invisible to the end-user. However, the information on its operation and the format of messages is essential to implementing extensions of the Virtual Laboratory framework. Main functions are: support of communication between components and launching of objects (i.e.: invocation of the object manager).
Communication between vlab system programs and the vlab daemon is shown in Figure 4. Each process has a separate communication channel to the daemon. The daemon transparently forwards any message sent by an active vlab component to multiple receivers, which simplifies communication patterns compared to direct bilateral communication between pairs of components.
L. Mercer. The Virtual Laboratory. Master's thesis, University of Regina, Regina, Canada, 1991.
L. Mercer, P. Prusinkiewicz, J. Hanan. The concept and design of a Virtual Laboratory. In Graphics Interface '90 Conference proceedings, pages 149-155. Canadian Information Processing Society, 1990.
E. Lowe - Extensions to the Virtual Laboratory. Master's thesis, University of Calgary, Calgary, Canada, 1995.
H. Lieberman. Using prototypical objects to implement shared behavior in object oriented systems. In Proceedings of the ACM Conference on Object-Oriented Programming Systems, Languages and Applications, pages 214-223, New York, 1986, Association for Computing Machinery.
L. Mercer, P. Prusinkiewicz, J. Hanan - the concept of the Virtual Laboratory
L. Mercer - the first vlab implementation
E. Lowe - redesign of communication centered on the vlab daemon
I. Hernadi, L. Mercer, P. Prusinkiewicz - Virtual Laboratory Environment documentation
Browser and Hyperbrowser utilities are combined in vL1.0.
Hyperobjects are stored in the same database as objects, and are located in a directory named <parentdirname>_<#>, for example, oofs_0 is a directory containing hyperobjects under the extension of oofs.
In the browser, hyperobjects are denoted with a triangle, and objects with a box. Hyperobjects behave just like objects in the browser.