Retro-Engineering Medium Scale Client-Server Applications
Peter A. Cooper, Ph.D.
Jamie L. Hebert, Ph.D.
Sam Houston State University
Abstract
It is easier to impose a coherent organizational structure on an application
when the user requirements for the development are both well understood and
relatively stable through the life of the project. This paper describes an
experience of retro-engineering an application in which the user specifications
were not well defined and were relatively unstable. The resulting application,
while functional suffered from a number of problems, not the least of which was
the difficulty in extending the application. The application was a web-based,
client server application written using Java 1.02. With the rapid development
of both Java and the browsers that support web-based applications, it became
clear that the application would require re-engineering in order to remain
function in the current environment. This paper describes the purpose and
characteristics of the original application and results of the restructuring process
and offers some comments concerning the benefits of the retro-engineering the
application.
Introduction
Web Imaging and Remote Sensing (WIARS) is a web-based, client-server application providing
large image analysis facilities integrating tools for boundary, cluster and change detection supporting image
comparisons and change assessment. The application was developed as part of a SERDEP funded project
supporting the monitoring of threatened and endangered species habitat on Department of Defense
installations. For fiscal year 1999, the research team, including new team members, was presented with
the task of rationalizing the interface, integrating an image registration module, and rewriting some
problematic SAS routines in either C or FORTRAN. A surface examination of the existing code uncovered
the need to perform a complete re-engineering of the application.
Analysis phase
The analysis phase involved a number of components. First an examination of the existing code
was performed in order to determine a number of attributes including the functional structure of the code
and the data structures employed. Data flow diagrams were developed to identify data flow and data
storage requirements. Analysis of the communications requirements was also performed. The analysis
phase provided the researchers with a clear picture of the original project as one that employed traditional
functional decomposition, minimal data structures and data storage mechanisms, with a simple
communications mechanism. The project consisted of a client and a server module implemented using
Java 1.02 communicating through the socket and DataInput and PrintStream abstractions. The client
functional and procedural structure consisted primarily of a single class with a large number of supporting
methods enabled through one comprehensive event handler. The server module comprised a master
process, distributing clients to slave processes. The slave process handled incoming data and processing
requests and provided data storage functions. The primary function of the slave threads was to spawn
external processes, typically SAS, MATLAB, FORTRAN and C routines that performed mathematical and
statistical functions on large-scale graphical images. The second component involved the user interface.
The interface consisted of a series of panels displayed in a main browser window, together with a large set
of supporting frames. As a result of shifting user requirements over the life of the original project there
was a lack of consistency in the organization, structure and presentation of each of the supporting frames.
The limitations of the application development and client deployment environments were evident in the
lack of coherence of the interface. The third component of the analysis phase involved examining the
communications flow. Two forms of communication were identified, string communication, and image
communication. The URL class was the primary vehicle for image communication. User identified images
are identified through publicly accessible URL’s and then ftp’ed to the server for processing. The final
component of the analysis consisted of identifying the data storage requirements of the project. Data
storage was performed only on the server. User and project information is stored at the server site in
sequential files for user/password lists and project status reports. Direct access files are used to store
project state information so users can resume projects without having to restart.
Object Modeling
Having completed the analysis phase and given the current project requirements, a decision was
made to utilize the data flow information and data storage requirements from the original project but
completely redesign the user interface, data communications and data storage mechanisms. Central to the
redesign was the utilization of a coherent object model that encompassed all three areas and allowed for
rapid extension of the project functionality. The design of the object model reflected the major areas of
concern. Independent class structures were developed for the user interface, for communication and for
data storage.
The GUI was designed with three main requirements; first, all the main controls for the interface
had to be available within a few clicks or key presses from any other point in the project, second, the
controls should be consistent across all segments of the interface and intuitive for the user, and third, the
interface should be contained within a single frame to reduce the complexity of the presentation.
The client side can be structured into a sequence of tasks; login, project and image management,
GIS attribute specification, process specification and output specification. As a result the GUI was
constructed with major controls for accessing. Accessibility to the later controls is managed by a login
mechanism. After successful login, existing or new projects can be managed. Image attributes can be set,
analyses performed and output requirements specified. A status screen displays the current project state
and logs project activities.
Within each tabbed panel, an indeterminate number of screens may be required in order to capture
all the data required by one segment of the application. To accommodate this each tabbed panel acts as a
container for a wizard object. The wizard, selected because it is a familiar mechanism to many users,
provides a framework for display, controlling and navigating through multiple panels. The final
component of the interface is the Panel extended to provide title and placeholder components and to
provide consistency across all Panels in the interface. Much of the development process of the user
interface consists of designing appropriate panels and the sequencing of the panels within the framework.
Three primary data classes were identified, a user class, a project class and an image class . Each
of the classes functions as a data storage module with facilities for controlled retrieval of the data. The user
class contains basic user data to allow login and project management. Typically the user class is used to
retrieve information about current projects. The project class manages project status information. The
project class includes owner information, image information and status information on the project. The
project class allows a partially completed project to be stored. The image class contained information
concerning the location, type and attributes of images used within a project.
All three data classes are communicated between client and server at intervals through the
processing of a project. For example during the login phase, a user object is populated with login
information and then passed to the server for verification along with a processing request. The server
responds with potentially additional user information, project information and other control information.
The primary medium for communication is the ObjectInputStream and ObjectOutputStream. To allow
objects to be sent though a socket both client and server need at least a common object prototype. A
communication object was designed comprising service request information and a generic object container
that utilized polymorphic capabilities to allow user, project and image objects to be passed within the same
communications object. This approach allowed the researchers to consolidate all communication on a
single port. The generic Object class provides facilities for interrogating an incoming object to determine
its source class for appropriate casting.