Novell is now a part of Micro Focus

Visual AppBuilder Architectural Overview

Articles and Tips: article

JOE FIRMAGE
Vice President
AppWare Systems Group

01 May 1994


Visual AppBuilder is a fifth-generation language (5GL) development environment that enables developers to build applications from highly functional interfaces. Visual AppBuilder assists developers in creating applications by linking AppWare Loadable Modules (ALMs). ALMs provide access to the functionality provided by both local operating systems and network services. Visual AppBuilder offers several advantages to developers because they do not have to code to any distributed architecture or API.

Introduction

In recent years there has been increasing pressure on software developers to work more closely with users in designing software with greater functionality and usability. Several factors prevent developers from delivering usable software in a timely manner:

  • Interface design and testing can be quite time consuming.

  • Changing business needs result in changes to the functional requirements of software applications.

  • Heterogeneous desktop environments require applications to ported to several desktop operating systems.

The Novell Visual AppBuilder is a fifth-generation language (5GL) development environment that enables developers to build applications from highly functional interfaces. Visual Appbuilder allows developers to graphically design and implement complex applications without writing code. Visual AppBuilder is intended principally for programmers who want to create applications without writing code or for application designers who have a basic knowledge of programming principles or have used macro or scripting languages. However, Visual AppBuilder can also greatly increase the efficiency of application developers still using third-generation languages (3GLs).

The traditional application development process usually requires writing code using 3GLs such as C or C++. This has been the typical method of application development for most companies, resulting in a development cycle that can extend into years. Visual AppBuilder can dramatically simplify the complexity of building and maintaining software by representing objects visually rather than textually. It is a component-based development environment that allows the reusability of software objects with a visual interface. The AppWare Bus is the underlying engine that governs each component at run time. The bus is based on an event-driven API that guarantees interoperability and simplifies application development.

AppWare Loadable Modules

Visual AppBuilder links software components called AppWare Loadable Modules (ALMs). An ALM is a software object comprising a group of associated functions. ALMs can range from simple graphical utilities and spreadsheet modules to network services such as multimedia engines, SQL client/server connections, and messaging. ALMs are represented by icons, and developers build applications by combining different ALM icons.

Linking Components

In terms of modularity and flexibility, software components span the gap from highly modular yet inflexible applications to flexible but rather non-modular components. At one end of the spectrum are huge, modular, high-level applications such as WordPerfect and Lotus 1-2-3. Technologies such as Dynamic Data Exchange (DDE), Object Linking and Embedding (OLE), Apple Events, and Publish and Subscribe allow interapplication links at this level. At the other end of the spectrum are flexible components such as the C++ class, which offers a much narrower measure of functionality. Using C++, as many as 500 to 1000 different classes might be required to construct a single application.

As software components become more intelligent and functional (which means larger and more modular), visual programming becomes more appropriate. Replacing a single line of C code with an icon, for example, would result in the mass confusion of trying to work with thousands of icons. However, representing 1000 or 10,000 lines of code with a single icon makes visual programming powerful and efficient. Developers can link twenty or thirty such icons to construct a complex application.

ALMs are large-grained, high-level software objects--they are much larger and more automatic than C++ classes, but they are also smaller and more flexible than large, off-the-shelf applications. ALMs thus strike a balance between the two extremes--maintaining programming that is effective and modular and yet also giving developers a good deal of flexibility.

Figure 1 shows how a high-level function call can replace perhaps hundreds of lines of C or C++ code in a Windows or Macintosh application. When the user chooses the Quit Item in the File Menu, the front Window is retrieved and passed to Close Window. After closing the Front Window, the program loops back to retrieve the new Front Window, until there is no front window, at which time Quit is executed. Whenever the user chooses the Quit Menu Item, the application closes all windows and quits.

Figure 1: Sequence of high-level function calls.

ALMs provide access to the functionality provided by both local operating systems and network services.The objects and functions can be thought of as nouns and verbs, respectively. In an ALM, the object type contains an auto-error correction routine to correct most commonly made mistakes in object connections and settings. A "signal" lister routine returns a dynamic list of runtime occurrences that can initiate function chains at run time. Through ALM development, services such as telephony, workflow, imaging, multimedia, and directory services become much more accessible to vertical and corporate developers.

Many interface builders such as Visual Basic allow the user to graphically manipulate window objects such as buttons and edit fields. The developer then attaches scripts or code to each object. The problem with this approach is that certain types of structures are not window objects but can still be treated as such. Databases, communication engines, data structures, and network services are not displayed as items or controls in windows but could still be represented as objects. Thus, while GUI development software allows for the rapid creation of interfaces, the majority of many applications must still be implemented with code because no method of visually representing data-management structures is provided. But if objects of all kinds can be represented as icons, then all objects can be used alike.

Figure 2 shows a database engine and picture/text fields in which a person's name, address, phone, and portrait can be displayed. But these objects have no visual representations in any window at run time and may operate entirely under program control.

Figure 2: An AppBuilder Database object.

All objects types in Visual AppBuilder are visually programmable, not just those visually represented at run time. In addition, once an object is initiated in Visual AppBuilder, its attributes can be edited. Figure 3 shows the Database object and its attribute editor.

Figure 3: The Database object and its attribute editor.

Functions or Verbs

Software components do not offer functions or "verbs" at the same high level that they offer "nouns" or objects. Even though it may be easy to create windows and menus using interface objects, you have to use traditional coding to support the functionality behind the interface. Both objects and functions must be represented at a high level, using a visual model to connect the two. In Visual AppBuilder the "verbs" called functions are connected in chains to object signals. These signals are high-level events issued by objects at run time to initiate function chains.

Figure 4 shows how the user adds a record to the Rolodex database by pressing the Add button. The total number of records is then counted. Within the ALM functions, program logic flows from left to right and data flows from top to bottom.

Figure 4: Adding a record to the Database.

Intercomponent Communication

In process-flow programming, program flow from function to function is completely disconnected from data flow in the application. The function-by-function specifics of input, output, and flow are determined when a function is created. A "wrapper" around the raw code actually executes the function operation. Visual AppBuilder provides organizational tools for large, complex applications. The AppWare Bus provides two levels of component control and communication: one is at the disposal of component (i.e., ALM) creators and is invisible to component users; the other is at the disposal of component users and is invisible to component creators. The AppWare Bus uses queued events for both of these communication systems because of its ability to address the diverse requirements of components such as transaction processing, timed processes, notification, and redundance avoidance.

The AppWare Bus event engine routes events to one of two places: object methods specified by the component developer, or functions specified by the component user. The attribute of the event which determines whether it should trigger functions or methods is the "signal" flag. Handling of events forwarded to object methods is usually transparent to the application designer. Visual AppBuilder users are exposed to a set of high-level events that are visible as visual links between object and function icons. Usually the ratio of events to signals in a typical application is 100 to 1. One can thus see how this architecture offers sophisticated inter-ALM communication but at the same time shields the developers from complexity.

This model for component communication supports (1) simultaneous self-control of large-grained objects and functions and (2) presentation of such objects and functions to application designers for visual high-level programmatic control.

Users of Visual AppBuilder organize their projects into subprojects or "subjects." Subjects allow a large, complex program to be broken down into reusable, smaller pieces. To connect subjects, the user "aliases" objects from one subject into another. The AppWare Bus compiler resolves the object aliases and produces a single application. The distributed AppWare Bus allows the user to set a compiler option, and compiles the subjects or groups of subjects into separate applications.

Figure 5 shows two subjects, one for a client process and another for a server process. A query button is set up in the client subject and is aliased in the server subject, appearing in italic typeface. Functions are connected to the query button alias in the server subject.

Figure 5: Client process subject aliased in server process subject.

When compiled, this project can produce two executables that can arbitrarily be distributed locally or on a network. The object alias establishes an automatic connection in both data and control, and whenever the user of the client application presses the query button, the query process executes entirely on the server. All data and control communication between the application pieces is specified automatically by the object aliases. The AppWare Bus handles this process transparently by sending events across the network.

This model offers advantages to developers because they do not have to code to any distributed architecture or API. All existing ALMs will support this architecture because they have been written to the AppWare Bus event engine. By using Visual AppBuilder, developers do not have to design for specific client or server environments but can create subjects within the projects. Over-the-wire communication is highly efficient and organized because of the makeup of the ALMs. Since the ALMs run on each side of the connection, the content of the communication, not simply the network plumbing, is standardized, and heterogeneous connections are provided.

Summary

Successful visual programming should possess the following attributes: proper granularity of the software building blocks, effective presentation of both functions and objects, and a core system of IPC technology that allows software components to work together. Enabling object orientation and implementing the concepts of visual programming will be the wave of the future.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates