 isualAge Visual Builder
Version 2.0 of VisualAge for COBOL (VA COBOL) introduced the
VisualAge Visual Builder (VB) to COBOL developers. It gave these developers the
power of visual programming that was previously only available to VisualAge
for Smalltalk,
VisualAge for C++, and VisualAge Generator users.
The GUI Designer that came with Version 1.0 of VisualAge for COBOL generated
traditional, procedural COBOL code. In contrast, the Visual Builder will
generate OO COBOL class definitions for the GUI and the connections. This
difference means anyone using the Visual Builder will have to understand the
rudiments of OO COBOL to totally appreciate and exploit its capabilities.
I do not intend to cover the mechanics of using the Visual Builder. I leave
it to you, the reader, to experience this. However, I will ask you to accompany
me on a study of a sample VA COBOL VB application to hopefully gather some
insights on its inner workings.
Notification Framework
Before we look at a sample application, let us review the notification
framework that undergirds any VisualAge Visual Builder application. The
notification framework plays a crucial role in the overall behavior of VB
applications. It is the vehicle through which parts (visual and non-visual)
communicate. It also makes the creation of user-defined events possible and
enriches the capabilities available to the developer for creating more complex
applications.
There are four players in the notification framework:
- Notifier - the subject being observed for changes in its state; it
is responsible for publishing notifications when changes occur.
- Observer - the observer is interested in changes to a subject; it
subscribes its interest to the subject in order to receive notifications.
- Notification ID - unique IDs are defined for parts enabled for
event notification; all visual parts have implicit notification IDs associated
with them.
- Notification event - the entity responsible for actually signaling
the event; it is the medium through which notifications are published.
People familiar with patterns will recognize this as the Observer,
one of the behavioral patterns discussed in the "gang of four" book,
Design Patterns: Elements of Reusable Object-oriented Software.
An Example of the Close Kind
We will use a very simple GUI application that displays a single window with
a single pushbutton labeled Close (see figure 1). There exists
one and only one connection, between the pushbutton and the window (see figure
2). Basically, when we click on the pushbutton, the pushbutton press event
triggers the firing of the connection and leads to the closing of the window.
Figure 1 - A simple GUI with a
close button.
Figure 2 - A visual
connection.
Listing 1 contains
the OO COBOL class definitions for the GUI and the single connection. I will
comment on some of the statements but do not intend to turn this into an
exhaustive analysis and commentary.
The statement labeled
[1] defines
the GUI class EyeObj and its lineage. It is clear that EyeObj
inherits the behavior of both CFrameWindow and CObserver (the observer class);
thus, it can contain other visual parts (controls) like the pushbutton (ClosePB
in statement [2]).
In addition, because it inherits the behavior of an observer, it can register
its interest in other objects. Since EyeObj is uninterested at the
moment on others, it does not exhibit this behavior. What is not explicit is the
fact that EyeObj is also a notifier. This is because CFrameWindow has as
one of its ancestors CNotifier, which defines the notifier protocol as used in
the VB notification framework (see figure 3). Thus, it can enable itself for the
signaling of events
[3]. An
example of this notification is when EyeObj is about to be destroyed
[4].
One characteristic of the visual builder is the use of visual connections to
relate parts together. These connections are represented as classes. For EyeObj,
there is only one connection, codified as EyeObjConn0
[5]. Note
that EyeObjConn0 inherits from both VisualConnection and CStandardNotifier.
Thus, we know that it is a notifier. What is unclear is the heritage that
VisualConnection brings to the relationship. Further examination of the VB
generated code for the GUI part shows an override for the method processNotification
[6].
This method is defined as part of the CObserver class. In addition, EyeObj
has delegated the task of observing the close pushbutton to EyeObjConn0
[7]. We
thus conclude that EyeObjConn0 is an observer.
Figure 3 - CNotifier
hierarchy.
What Next
Although the code generated by the Visual Builder for the GUI part (.cbl)
and the client program (.app) is not meant to be modified, it does not preclude
us from examining it and gaining a better understanding of how things are
cobbled together. I encourage you to study it for this purpose.
Are there areas of VisualAge for COBOL that you would like more information
on? Please write me a note at wilbert@us.ibm.com.
I would appreciate your comments and suggestions. Thanks!
References
Gamma, Erich, et. al., Design Patterns: Elements of Reusable
Object-Oriented Software, Addison-Wesley, Reading, MA, 1995.
IBM, VisualAge for COBOL Building Parts for Fun and Profit,
IBM, May 1997.
IBM Announcement Letter No. 297-142, May 6, 1997.
Trademarks VisualAge is a registered trademark of International
Business Machines Corporation in the United States or other countries or both.
| 
