This section introduces AVS/Express. providing an overview of the operation of the systems and describing basic concepts that will be used throughout this manual.
This chapter discusses:
- Overview, Section 1.1
- Project mechanism, Section 1.2
- Application components, Section 1.3
- Building applications and application components, Section 1.4
- AVS/Express object hierarchy, Section 1.5
AVS/Express is an object-oriented, visual development tool that enables you to build reusable application components and sophisticated visualization applications.
In AVS/Express, the term "visual" has two meanings:
- Visualizing data - AVS/Express provides hundreds of predefined application components for visualizing data: analyzing it, manipulating it, displaying it, and interacting with it. AVS/Express also offers lower-level, building-block components that you can assemble to create your own visual components.
- Visual development - AVS/Express offers a visual development environment called the AVS/Express Network Editor. In the Network Editor, application components appear as rectangular icons that you define, assemble, and manipulate through mouse-driven operations.
AVS/Express offers several ways to use components. You can:
- embed them in AVS/Express applications
- execute and control them in server mode from an external C or C++ routine
- create components that represent standalone applications
AVS/Express provides full support for C and C++. Fortran support is also provided. Components can perform their processing by calling a C or C++ routine. Code template generators enable you to import user code and user data with little modification. A C++ class generator enables Developer Edition users to use the power of C++ programming to access AVS/Express components.
AVS/Express' development approach is object-oriented. AVS/Express supports many object-oriented techniques: the encapsulation of data and methods; class inheritance; templates and instances; object hierarchies; and polymorphism. Through the Network Editor, AVS/Express provides a visual interface to these techniques. In AVS/Express terminology, all application components, from lowest level to highest, are objects.
1.1.1 Working with AVS/Express
The AVS/Express environment has three main interfaces:
22.214.171.124 The Network Editor
The primary AVS/Express development tool is the Network Editor (NE). In the Network Editor, objects appear as rectangular icons. Using the mouse, you can assemble the objects you want for your application and draw connection lines between objects to indicate data references. Here is a portion of the Network Editor:
- Note: This manual uses a white background in illustrations of the application workspace. The default background you will see when you start AVS/Express is a gray pegboard.
The top section of the Network Editor consists of libraries of objects. The bottom section is an application workspace, into which you drag and drop library objects to assemble an application or create new objects.
The Network Editor performs state save and restore operations using V language, which is described in more detail in the following section.
126.96.36.199 V language
AVS/Express offers a text-based alternative to the Network Editor, called V. Like the Network Editor, V lets you view, add, delete, and edit objects.
You can use V in several ways:
- You can enter V statements and commands interactively into AVS/Express through AVS/Express' V Command Processor (VCP). The VCP is particularly useful for examining and debugging applications.
- In a text editor, you can create a V file that defines a set of objects, then read the V file into AVS/Express.
- In the Network Editor, you can save objects into a V file, then later read the V file back into AVS/Express or edit the file.The VCP interprets the same language definition as V but provides a command prompt that shows the name of the object that you are editing. From this prompt, you can use V commands to traverse the object hierarchy, display and modify object values, and create and destroy objects.
- Note: V is not a traditional programming language like C, BASIC, and so on. It does not define procedural programming constructs like flow of control, conditional operations, etc. In AVS/Express, if you need to write this kind of programming construct, you do it in a programming language that you already know such as C or C++. V maintains the state of objects: what objects are instanced, what connections exist, and the current values of parameters.For more details about V and the VCP, see Chapter 3, V and the V Command Processor
188.8.131.52 The NE versus V
When and why should you spend the effort to learn the V programming language? The Network Editor provides an interface that allows you to perform almost all of the tasks that can be performed through V. As with any visual interface, it can become cumbersome to perform repetitive operations using a point-and-click interface. In particular, when you are importing large numbers of modules that require detailed specification of attributes and parameters it may become tedious and hard to manage in the Network Editor. V is better suited to this activity. The Network Editor, however, is much better suited for constructing and editing macro objects because the visual display of the layout of modules and connections makes these relationships much easier to understand.
184.108.40.206 Application Programming Interfaces
AVS/Express allows you to integrate user code into an application. You can do this in essentially two ways:
- Call a routine from an object - An AVS/Express object can call a C or C++ routine to perform its processing. In AVS/Express, an object that takes input data, performs processing, and produces output data is called a module.
- Manipulate instances of objects - A C or C++ routine can create, destroy, and modify instances of existing AVS/Express objects. This allows you, for example, to build an application that calls AVS/Express in server mode to carry out some aspect of the application, such as visualizing a set of data.
AVS/Express has several tools to help you integrate user code. For example, AVS/Express' C++ class generator enables Developer Edition users to generate a C++ class that controls an AVS/Express object.
1.1.2 AVS/Express kits
Component technology is the ability to create an application from reusable, modular pieces, or components. AVS/Express offers component technology through its wide assortment of predefined application components. AVS/Express enables you to create your own components or obtain components developed by others.
AVS/Express organizes its predefined components into collections called kits. AVS/Express offers these kits:
- User Interface Kit - Enables you to build platform-independent graphical user interfaces. User interface objects define windows, dialogs, widgets, interactors, and render views. AVS/Express' Layout Editor lets you modify user interfaces through direct manipulation.
- Data Visualization Kit - Enables you to read, manipulate, transform, and analyze multi-dimensional, multi-variate data. In addition to its many modules, the Data Visualization Kit includes an API for creating new visualization objects.
- Image Processing Kit (part of the Data Visualization Kit) - Enables you to read multi-banded image data and perform over 40 image processing functions (for example, blend, edge, dilate, and convolve).
- AVS5 Compatibility Kit - Enables previous users of AVS5 to use existing AVS5 modules.
- Graphics Display Kit (Developer Edition only)- Enables you to build interactive 2D and 3D graphics-display applications. The Graphics Display Kit offers pre-built data viewers that you can use out-of-the-box or customize.
- Annotation and Graphing Kit (Developer Edition only) - Enables you to build sophisticated graphs of multi-dimensional data. Annotation and graphing objects include titles, arrows, circles, charts (for example, bar, line, staircase), legends, and axes.
- Database Kit (Developer Edition only)- Enables you to interact with standard databases to import data in AVS/Express.
1.1.3 Object-oriented techniques in AVS/Express
AVS/Express supports many object-oriented techniques: the encapsulation of data and methods; class inheritance; templates and instances; object hierarchies; and polymorphism. Through the Network Editor, AVS/Express provides a visual interface to these techniques.
- Encapsulation of data and methods - Objects encapsulate (or bind together) both data and the methods that operate on the data. The major advantage of encapsulation is that a single entity can represent everything associated with a particular object. This provides the basis for component engineering, where newly developed components can be dropped into existing applications.
- Class inheritance - An object can inherit the characteristics of one or more other objects. This is called subclassing. The new object derives both data and methods from the inherited objects. The new object can modify its inherited data and define additional data and methods. Inheritance enables you to define a set of data and methods once and have those characteristics inherited by many objects.
- Templates and instances - AVS/Express separates the definition of an object-called the object's template-from executable instances of the object. In the Network Editor, templates appear in the Libraries section. To use a template object in an application, you instance it, dragging and dropping it into the application workspace. The template object remains in the Libraries section, enabling you to create multiple instances of a template.
- Object hierarchies - AVS/Express allows you to combine objects to form higher and higher-level objects. Most objects you see in AVS/Express are actually collections of other objects. By opening an object, you can view and modify its underlying definition.
- Note: The extent to which you can dig down into an object hierarchy by opening objects is dependent on whether you are using the Developer Edition (which provides unlimited access to an object's hierarchy) or the Visualization Edition (which provides only limited access to an object's hierarchy).In the Visualization Edition, when you reach the limit of your ability to dig down within an object, only exported parameters will be visible in the NE (in Display List mode).
- For example, isosurface, an object in the Data Visualization Kit, produces an isosurface of a set of field data. (An isosurface is a surface of constant value, similar to 3D contour lines.) isosurface includes a user interface for selecting the isosurface level. Here is what isosurface looks like in the Network Editor:
- By double-clicking on isosurface, you can maximize it to view its constituent objects:
- As you can see, isosurface is actually a collection of other objects, named IsoParam, IsoUI, Iso, and so forth. Many of these objects are themselves collections of objects. IsoUI, for example, contains objects from the User Interface Kit, assembled to define isosurface's user interface. If you wanted to change isosurface's user interface-for example, by replacing a slider with an entry field-you could open IsoUI and make the appropriate changes.
- Polymorphism - Polymorphism literally means many forms. In AVS/Express, it means that an object can operate on different types of data, and work differently depending on the data it receives.
1.1.4 Connections and object execution
An AVS/Express object can reference the data created by another object. This is called a connection. In the Network Editor, a connection typically appears as a line between two objects.
For example, here is a simple data-visualization application:
Read Geom reads a data file and creates an AVS/Express field. Viewer3D provides a full-featured data viewer. The connection line specifies that Viewer3D should display the data created by Read Geom. Viewer3D does not copy Read Geom's data; rather, it references it:
In AVS/Express, connections not only define how an object gets its data, they also drive the execution of the application. When data changes, objects that reference the data are notified of the change. Typically, this causes the object to execute.
For example, consider the data visualization application consisting of Read Geom connected to Viewer3D. Say you or your end used decides to read a new data file. This causes Read Geom's data to change. Viewer3D, through its connection, is notified of the change. The notification causes Viewer3D to execute and render the new data:
Order of execution is determined not by a set of procedural instructions or message-passing schemes that you would otherwise need to code, but rather by the connections you make among the application's objects.
When necessary, you can explicitly control execution. For example, you can indicate object dependencies, in cases where order of execution is important but ambiguous. Through a C or C++ routine, you can explicitly set notifications on objects to force their execution.
1.1.5 Object Manager
At the heart of AVS/Express is a powerful runtime engine called the Object Manager. You do not see it, but the Object Manager manages the definition and execution of your application.
The Object Manager:
- Validates objects as you build them.
- Executes objects.
- Manages an object's data.
- Manages the connections among objects and schedules their execution.
- Invokes an object's methods.
- Handles API calls from C or C++ routines to update objects and their data.
- Supports multi-process computing, whereby objects can be moved from process to process without modification. This provides a convenient debugging environment for isolating fault-prone or rapidly changing code as it is developed.
1.2 Project mechanism
AVS/Express has a sophisticated project mechanism. An AVS/Express project specified the collection of objects available for use during a session and thus defines your development and execution environment, including:
- Libraries - containing template objects including macros, modules, parameters, and other libraries.
- User code - the C and C++ routines associated with those objects
- Processes - the express executable, as well as any external processes
AVS/Express operates on a single project at a time. When you first use AVS/Express, you access the install area's project, with its full complement of template objects from licensed AVS/Express' kits. You do not modify the install project, but rather create your own project. The new project defines itself as being like the install project, with any additions and changes you make.
You can define chains of projects, whereby a project is a derivative of some other project, which in turn is a derivative of yet another project. This allows developers to share objects, and to work on specific objects that are unique to their own development tasks.
AVS/Express implements object-oriented programming using a prototype style. In this style, objects in a library are not active (their methods are not called) but instead serve as templates for the construction of objects that are part of the application. Objects that are actively part of the application are called instances.
To create an instance from a template, copy an object from a library into an application. Using the Network Editor, this is done by dragging an icon from the Libraries area and dropping it into the Applications area. Templates and instances are defined and edited using the same basic mechanisms. A template similar to a class in a class/instance object-oriented system.
To create a subclass of a template object, make a copy of it. The subclass starts out as an identical copy but usually some additions or modifications are then made to differentiate it from the superclass. Creating a subclass is the same operation as creating an instance. The only difference is that for a subclass the destination is another library; for an instance the destination is an application.
Both subclasses and instances keep track of the template from which they were created so that future changes to the template will be propagated to the new object. This is necessary for inheritance to work properly.
1.3 Application components
In most object-oriented systems, the interface to an object consists of a set of methods (also called "messages") that the object supports. You call these methods to access the functionality of the object.
In AVS/Express, you need not directly be aware of the existence of any methods on an object. Instead the interface to an AVS/Express object is a list of named parameters. These parameters can be simple primitive values such as an array of three numbers specifying a color or an integer specifying the height of a widget. They can also be aggregate objects themselves such as an image that might contain width, height, and data.
Parameters can be connected to other parameters. A connection provides a conduit for the sharing of information between two objects. In many cases, a connection represents a lasting relationship of equality between two parameters. For example, by connecting a width parameter to a height parameter, you are guaranteed that width will always equal height.
As with most object-oriented systems, an AVS/Express object has methods which implement the behavior of the object but these methods are not exposed to you. The system executes them in response to events that occur on the parameters of the object. Objects can send messages back and forth across connections to other objects without your needing to manage this communication explicitly. Thus you do not have to know of the existence of the methods and do not need to manage the execution of the object. This is called execution encapsulation. In AVS/Express objects that have parameters and methods and have their execution encapsulated are called modules.
A module may have some parameters that are designed to be connected to other objects. The programmer gives these parameters ports. A parameter can have an input port, output port, or both at the same time. Ports are colored based on the data type of the object. Multi-colored ports can be used to indicate polymorphic objects (objects that can be used for more than one purpose).
Once you have several modules connected together, you can encapsulate this group to create a macro. A macro can export parameters of its modules so that they become parameters to the macro. They become the interface to the macro. Parameters that are not exported are considered part of the implementation of the macro.
A macro can contain other macros as well as modules so applications can be constructed out of progressively higher-level building blocks. Groups of objects and their connections are called networks and are edited visually using the Network Editor.
Since each object manages its own execution, the programming process is simplified. You instance and delete objects, and change parameter values either by making/breaking connections or by changing parameter values directly. You traverse the structure of the application visually and edit it using direct manipulation techniques. By making good use of macros, you can subdivide an application into manageable units of complexity.
1.4 Building applications and application components
1.4.1 Building an application using AVS/Express
You can use AVS/Express to build a complete application. An application in AVS/Express is just a special kind of macro object that is not contained within other macros. The application object is usually created by AVS/Express when the process is started and is not destroyed until you exit the application.
One of the advantages of creating complete applications using AVS/Express is that your users can customize the application for a particular purpose using the Network Editor (of course, only if you provide them with this capability).
1.4.2 Building application components with AVS/Express
You can dynamically create and destroy an AVS/Express macro or module using traditional C, C++, or FORTRAN programming techniques. In this way, AVS/Express is useful as an environment for building libraries of component objects that are then used in traditional programming environments. Because the execution of the objects is still encapsulated, the programmatic interface to AVS/Express objects is just as easy from C, C++, or FORTRAN code as it is from the Network Editor. A program can create objects, make connections, and change parameter values. The execution of the underlying methods that are triggered by parameter changes are controlled by bracketing these changes with begin/end calls named OMpush_ctx and OMpop_ctx. The OMpush_ctx call puts execution of these methods on hold. When the OMpop_ctx call returns, the methods have all been executed.
For C++ programmers, AVS/Express will generate C++ wrappers for specified AVS/Express objects that provide simple and natural bindings for these objects.
For C programmers, the objects can be created, destroyed, and modified using the Object Manager programming library. This library provides a set of routines that provide complete flexibility over AVS/Express objects.
For FORTRAN programmers, the objects can be created, destroyed, and modified using the Object Manager FORTRAN programming library. This library provides a set of routines that provide comprehensive flexibility over AVS/Express objects.
1.4.3 Adding modules to AVS/Express
AVS/Express provides support for you to add your own modules to the system. When you add modules to the system, you define the list of parameters and methods for a particular module, then specify which events should cause which methods to execute. A module's methods can execute when the object is instanced, destroyed, or when one or more parameters are changed. When a method is executed, it can determine which parameters have changed since the last invocation and can change one or more other parameters.
By adding a collection of modules, you can use AVS/Express to provide a visual programming interface to an existing library of code.
1.5 AVS/Express object hierarchy
There are five different types of AVS/Express objects: macro, module, parameter, method, and library. Each of these objects is a subclass of a common object type called simply object. These objects are all stored in a single tree structure called the object hierarchy.
In the object hierarchy, each object may have a list of subobjects and a single parent object. The subobjects of a module are parameters and methods. The subobjects of a library are macros, modules, and other libraries. The subobjects of a macro are modules and other macros. Methods have no subobjects. If a parameter has subobjects, they are also considered parameters.
These objects are joined together to form a single object hierarchy with the Root object containing Templates and Applications subobjects.