A practical example using VisualAge for Smalltalk

ntroduction

The objective of this article is to describe my experiences as a first time user of VisualAge for Smalltalk and to try and emphasise the benefits of the object oriented approach in conjunction with VisualAge using a simple application as a example.

I plan to cover the following:

• A brief justification of why object orientation is important and why it needs to be supported by power tools such as VisualAge.
• A brief description of VisualAge.
• A description of the requirements for my example application.
• A description of the (completed) application from the viewpoint of an end user.
• A description of the approach I took to develop the application with examples of the VisualAge screens.
• A summary of my impressions of VisualAge and object oriented development.

Why Object Orientation and why VisualAge

Today's software developers are coming under increasing pressure to achieve three simultaneous goals:

1. To develop solutions in ever decreasing timescales (SCHEDULE).
2. To deliver ever increasing functionality with less resource (COST).
3. To 'delight' the end user YET avoid a nervous breakdown on the part of the maintenance personnel. (QUALITY).

The three conflicting dimensions of SCHEDULE, COST and QUALITY provide a major challenge which has driven the need to improve the way we develop software (methods, tools et al).

Conventional wisdom has evolved over time to establish a set of principles which are generally accepted as key to the successful delivery of software projects:

• The need to perform a careful and considered analysis of the problem domain to ascertain the TRUE requirements (ANALYSIS).
• The need to create a clear architectural 'blueprint' for any solution, based on 'building blocks' (both new and 'off the shelf') (ARCHITECTURE AND DESIGN).
• The need to deliver the solution in a series of self contained increments (INCREMENTAL DELIVERY).
• The use of tools that remove much of the manual effort from the solution delivery and provide the ability to create rapid early prototypes (POWER TOOLS).

These principles find their origin in the more mature engineering disciplines such as Civil Engineering. From a software viewpoint, the first three principles are embodied in the concepts of object orientation but until recently, power tools which provide TRUE support for object orientation have been conspicuous by their absence. A new generation of tools are starting to emerge in this area, one of which is VisualAge from IBM.

VisualAge - a brief description

For the sake of brevity, I do not intend to provide a complete description of VisualAge but a top level definition would seem appropriate (this one 'borrowed' from IBM):

• VisualAge is a client/server application development POWER TOOL. It focuses on business applications including both on-line transaction processing and decision support applications.
• VisualAge enables professional developers to quickly build the client portions of business applications, complete with a graphical user interface (GUI), application logic and both local and remote access to resources such as databases and legacy applications.
• VisualAge technology provides a pure object-oriented development environment, a set of interactive development tools, a library of prefabricated components and a set of tools for client/server computing.
• VisualAge provides portability across multiple platforms, currently OS/2, Windows and AIX.

Throughout the rest of the article I will 'dip into' the features of VisualAge used to develop my own particular application.

An example application - the requirements

As a keen jogger, I organise a series of races for the local Athletic Club. Until recently, I had been doing all the administration work manually and saw the opportunity to create a VisualAge Application to simplify the workload. In keeping with the principles espoused above (Analysis), I started with a statement of requirements (summarised below):

• Provide the ability to maintain a list of club members, their name, age and sex.
• Provide the ability to define a set of competitions that the club members can enter. More than one competition can be in progress at any point in time and each club member can take part in multiple competitions.
• Provide the ability to define a series of races for each competition.
• Provide the ability to record the results for a runner in a race.
• Provide the ability to create reports by competition, race and club member.
• Provide the ability to export the result data to an ASCII file for inclusion in the Club Newsletter, distributed via E-Mail.

The application from a users' viewpoint

Figure 1 shows the main application panel. All fields are blank until the user selects a competition from the drop-down list. Lists are then shown of the races and competitors associated with that competition . Each list has an associated push button to invoke panels to manipulate entries within the list (race details or competitor details).

The push-buttons within the results box provide the ability either to records results (Figure 4) or to display result data for a selected race, competitor or competition (Figure 5).

Figure 1 - Application Main Panel

To define and manage club members, the MEMBERS item is selected from the action bar to display the panel shown in Figure 2.

Figure 2 - Member Details Panel To define and manage each race, the RACE DETAILS button is selected to display the Race Details Panel as shown in Figure 3.

Figure 3 - Race Details View

Results are managed using the left panel of Figure 4. The runner name, position and time is entered and the relevant button selected. Certain races are run on a handicap basis to give the slower runners a chance of winning. In this case, the calculated data in the right panel is displayed after a result has been added or modified.

Figure 4 - Results recording view

Reporting is provided via a multi-purpose panel which can display results either by race, individual runner or competition. Figure 5 shows the results for Race 2 in finish order. The CALCULATE button is used to invoke logic which determines the race position and points for each runner after all results have been entered. The SORT button has not been implemented yet but my idea was to sort the list by finish position, (as shown), runner name or adjusted time. The Export BUTTON invokes logic which raises a file dialogue and then writes the result data to the selected file in ASCII format.

Figure 5- Race Results View

Development approach

Having described the application from an external viewpoint, I will now move onto some of the more technical details of HOW I approached the development.

Given a clear analysis of the system requirements, the first step is to create a clearly defined architecture for the solution. One of the best approaches to object oriented architecture is to divide the system into three main class types:

1. MODEL CLASSES which represent the 'real world' things upon which the application is based, such as people, races and competitions in my case..
2. VIEW CLASSES which represent the components of the user interface e.g. windows, menus, push buttons, etc.
3. CONTROLLER CLASSES which provide the 'glue' to link the view classes to the model classes.

With this approach in mind, the steps I took to architect, design and then implement the solution were as follows:

• To identify the model classes by performing 'noun analysis' on the problem statement described above.
• To define the responsibilities and relationships between the classes by running though a series of scenarios of how the user would interact with the system to define club members, competitions and races and then record, display and print results. I used Rumbaugh's Object Modelling Technique (OMT) to document the class relationships (see Figure 6).
• To design, code and test the model classes in isolation before writing the GUI code.
• To design the GUI interface on paper and then generate the classes using the VisualAge Builder (or Composition Editor).
• To link the GUI (or view) classes to the model classes by defining additional Smalltalk methods using the VisualAge code editor (or Script Editor).
• Steps 4-5 were performed incrementally, starting with a small subset of the application (the Member Details panel shown in Figure 2). At each stage, I completed testing within the VisualAge development environment before adding further panels.

The model classes which evolved from the initial CRC analysis are shown in Table 1.

The Object Model (using Rumbaugh's Object Modelling Technique) is as shown in Figure 6.

Figure 6 - Runner Application Object Model

Building and Testing the Model Classes

Prior to learning VisualAge, I started to write the application in a version of Smalltalk without a GUI builder. Given my plan to write and test the model classes first before moving onto the more difficult task of writing the view and controller classes, VisualAge appeared "as the cavalry over the horizon" to save me from the onerous task of coding up all the GUI code!

The first thing I did within VisualAge was to create a sub-application called RunnerApp to represent the model classes using the Application Manager facility . I then imported, the model class definitions from an ASCII text file - exported from my previous version of Smalltalk. Figure 7 below shows the VisualAge Application Browser open on the RunnerApp application. The top left window shows the class names with the person class highlighted. The right hand window shows the methods within the person class and the bottom window shows the person class definition.

Figure 7 - Visualage App Browser showing RunnerApp Model Classes

Testing the model classes was then easy as VisualAge (as do all implementations of Smalltalk) provides the ability to enter the messages that drive the classes manually. The instance data within the classes can be viewed using a Class Inspector (Figure 9) to prove that the logic is working successfully.

In Figure 8, the temporary code in the workspace window will create a person object and then set the name, age and status fields. The Class Inspector (Figure 9) then provides the ability to 'look inside' the person object.

Figure 8- Temporary code to create and update a Person Object

Figure 9 - Inspecting a Person object using a Class Inspector

Building and Testing the Controller/View Classes

The design process for creating the view (or GUI) classes was a bit more 'ad-hoc'. I had an outline design for the various windows but this changed as I became aware of the capabilities of VisualAge. It was extremely useful knowing the model classes in advance as this freed me up to concentrate on the user interface rather than the business logic. Designing the view classes was an iterative process with the later screens becoming more sophisticated as my knowledge and confidence in VisualAge improved.

I also found that for my simple application, there was no need for a set of distinct controller classes as VisualAge provides the ability to add your own methods to the view classes. These provide the interface to the model classes.

The sequence of events for creating the GUI classes was:

1. Create a sub-application called RunnerWindowsApp using the VisualAge Application Manager.
2. Create each class within the Application Manager. This automatically starts the Composition Editor (or GUI Builder for the given class).

Figure 10 shows the Application Browser open on the RunnerWindowsApp Application. Each of the view classes represents a particular window panel (e.g. RunCompMainView is the panel in Figure 1 above, RunCompPersonView is the panel in Figure 2 above etc.).

Figure 10 - Visualage App Browser showing RunnerWindowsApp View Classes

The Composition Editor

Figure 11 shows the VisualAge Composition Editor in action on the Race Details View. The Composition Editor provides the ability to create GUI components (windows, scroll bars, buttons, dialogue boxes, etc.) and then create connections associated with:

• EVENTS (such as 'button clicked')
• DATA VALUES (such as the contents of an entry of display field) and
• SCRIPTS (to execute a Smalltalk method, e.g. create a new Person Object).

Connections are indicated on the screen with arrows as shown in Figure 11.

The arrow between the CANCEL button and the window title bar is an EVENT TO ACTION connection, created by:

• Selecting the 'clicked' action for the button (right mouse on the button provides a list of actions).
• Dragging the system generated arrow to the window title bar (right mouse on the title bar provides a list of actions).
• Selecting the CloseWidget action on the titlebar.

The arrow extending to the left of the ADD button is an EVENT TO SCRIPT connection. The event is the ADD push-button being clicked. The script is a method called addRace - shown in Figure 12 that will send a message to the competition class to create a race.

The arrow extending from the Name data entry field to the arrow extending from the ADD button (described above) is an ATTRIBUTE TO ATTRIBUTE connection which ties the data value from the Name Field into the parameter used on the addRace method.

The scripts (or Smalltalk methods) described above are created by invoking the Script Editor. This is done by selecting the middle of the three 'ban the bomb' style buttons at the bottom right of the Composition Editor.

Figure 11 - Using the Composition Editor to build the Race Details View

Figure 12 shows the method used to create a race and Figure 13 shows the method used to set the data in the race object. The strange icons just under the FILE component of the action bar are used to provide automated assistance for generating methods (or scripts). The upper icon invokes a window that shows all the methods and attributes (field names, button names etc.) which can be used within the code. The lower icon provides a Smalltalk help facility giving details of the language syntax. These are extremely useful facilities.

The circular arrow on the left of the toolbar will cause VisualAge to execute that particular class in-flight . This is a particularly useful facility and provides strong support for the concept of incremental development as individual components can be built, tested, modified and then re-tested very quickly.

The Composition Editor is the real 'engine room' of VisualAge. It is a very powerful tool but like all GUI builders, it takes a bit of getting used to. There is a danger initially of trying to do too much within a single class, defining too many connections and ending up with a visualisation of "Custers' last stand". With experience, one learns how to divide the interface between a number of GUI classes, with fairly simple connections.

Figure 12 - Smalltalk method (Script) to create a new Race

Figure 13 - Smalltalk method (Script) to set the data in the Race Object

My impressions of VisualAge

My overriding impression is that VisualAge does indeed provide the power tool required to develop true object oriented applications quickly and effectively. It provides full support for incremental component based development and a superb integrated environment within which to develop, test and debug an application.

The close integration with Smalltalk would appear to provide the ability to scale up from the most trivial to large scale applications. The versatile GUI builder and extensive library of re-usable parts significantly reduce the workload on the application developer. It took me between four to six weeks to develop the above application which was quicker than I expected given the high learning curve. I believe that it would have taken me at least as long to develop an application in pure C - a language I have been using for 10 years.

One of the major benefits came about a few months after completing the application, when the following changes were required:

1. Add another competition type with different handicap rules.
2. Add a new report type (best result for each runner throughout a competition)
3. Speed up the results recording process by re-arranging the data on the panel and automatically generating the finishing position for the next runner.

The actual changes were very easy to make as the application was well structured in terms of methods and classes (a by-product of OO analysis and design coupled with the benefits of using VisualAge):

• Change 1 required a modification only to the competition class (two new instance variables and a method change).
• Change 2 required a modification to the general purpose results view class as shown in Figure 5 (new method)
• Change 3 required a minor change to a method in the Results Recording View as shown in Figure 4. The changes took me about 30 minutes. In a traditional application it would have taken far longer to locate and change the associated logic and to test for any side effects within the logic.

The one caveat is the difficulty I had 'getting to grips' with Smalltalk initially, having written code in procedural languages for so long (PL/1, C, Assembler). This is probably the biggest challenge for anyone with a traditional programming background. Every cloud has a sliver lining, however, and I believe that the pain sustained by switching to Smalltalk help gave me a better understanding of object oriented programming. I feel that if I had used C++ (which is now available with VisualAge), there would have been a tendency to 'cheat' and revert to procedural code which is easy to do in C++.

Summary

I was already a believer but this small project has convinced me of the power and benefits of the object oriented approach coupled with a powerful development tool.

I also believe that there is a strong inter-dependency between object oriented analysis, design and programming. It would be possible to 'hack' a VisualAge application without the analysis and design effort but I firmly believe that many of the benefits would be lost.

By focusing on careful analysiswith component based architecture/design coupled with incremental deliveryand by using a power tool such as VisualAge, we now have the capability to make real progress in the world of software development. The example above, although fairly simple illustrates many of these points. The three goals of SCHEDULE, COST and QUALITY may now be achievable but only if we Embrace the technology! (This is the subject of an entirely separate debate!)

Enjoy the article? Subscribe to Eye on Objects!

Colin Moon is an application developer with twenty years of experience developing real-time client/server software. He spent the first seventeen years working for IBM Manufacturing at IBM Havant. He then spent eighteen months with Xyratex following the management buy-out and is now a consultant application development specialist working for Platinum solutions. He can be contacted at cmoon@platinum.co.uk or 106223.1622@compuserve.com.

Home Page