ArcView Application Programming with Multiple Developers

Introduction
As the developers at Eagle Information Mapping prepared to begin work on
their first large-scale Avenue-base application development project, it 
became apparent that ArcView projects were not intended to be edited by more
than one person at a time.  This limitation posed a major obstacle to a
successful and timely completion of their project which was first designed
to have a team of four developers working together.  The decision was made 
to scope out any additional obstacles and develop a system which allowed 
the team to proceed with the application project in the most efficient manner.


Obstacles
Analysis of the task at hand revealed the need for a system that could support
the developer's work while not becoming an insulating buffer between them
and Avenue.  They also needed a tool that would be useful and readily available
yet not so intertwined with the application under construction that it could 
not be separated when the project is finished.  The old applications design 
problem of how-much-functionality vs. how-much-user-freedom was very apparent 
(especially when developing an application for applications developers).  

The following obstacles to cooperative development were identified: 

    
 The need to prevent simultaneous edits on the same script.
 A check-out check-in procedure like those in most source code control
 systems would be at the heart of managing developer cooperation.
    
 The need to share scripts between developers.
 The development team would be creating and editing scripts constantly 
 and the ability to share up to the minute work was essential.
    
 The need to provide script protection from unwanted ArcView termination. 
 Loosing all development work done since the last save whenever ArcView
 unexpectedly terminated was already bothersome.  The new system would 
 have to save a developer's work more often.
    
 The need to allow project management and tracking.
 A log file to show what scripts were added or changed and by whom plus 
 a way for a project manager or developer to see what scripts were 
 currently checked out.
    
 The need to support version control.
 When a version was ready for testing, it needed to be free of any 
 signs of the script development environment.  Separate versions of 
 the project under development need to be saved.


Solutions
In order to share scripts, all the project scripts are stored as files on 
disk. When a developer logs-in, the scripts are read into the project.  The 
scripts are managed by a virtual table recording the name, filename on disk, 
and check-out information for each script.  Likewise, the developers on the 
project are managed by another virtual table recording log-in and update 
information.  

    
 Check-in check-out. 
 A script check-out operation sets the status of the script's record in 
 the virtual table.  When another developer tries to check out the same 
 script, the check-out operation checks the check-out status of that 
 scripts record in the scripts table preventing a check-out if the 
 script is already checked out.  A check-in operation removes the flag 
 from the script's record in the table.
    
 Script sharing capabilities. 
 Scripts are shared by add and update operations. Adding a script 
 creates a record in the scripts table and writes the script file to 
 disk.  Likewise, deleting a script removes the record and file on disk.  
 Other developers can use the new script by updating their environment.  
 This operation loads all new scripts and updates those that have been 
 checked in by other developers.
    
 Scripts saved on compile. 
 Since scripts are stored as files on disk and not within the project, 
 the system saves the script to disk before each compile to create a 
 safe and recent copy of each script in the system.  If an unexpected 
 ArcView termination occurs, the system will load the most recent 
 version of the script from disk when starting up again. 
    
 Project database files and log file. 
 All project scripts and their current status (including which developer
 has it checked out for editing) are stored in the scripts table.  It 
 can be viewed by any manager or developer by opening the table just 
 like viewing any other table.  The developer table can also be viewed
 to examine developer actions.  All critical actions involving the 
 development environment are also written to a log file which can be 
 viewed by anyone on the project.   
    
 Shrink wrap. 
 A shrink wrap script to save to a new project and remove all environment
 functionality is used to create user versions of the product.  The
 development version of the project remains untouched and the user
 or test versions are extracted from it.  Shrink wrapping a project can
 be done even while other developers continue working on checked out
 scripts.  


Boulevard
The name Boulevard was selected for the development environment manager 
because it implies a high traffic volume avenue.  It is a name that reflects 
the nature and purpose of the system.  When designing Boulevard,
additional features not related to multiple developers were planned to make 
the system an even more useful tool for developers.

Additional features of the system include:
 
 Find, next and replace. 
 Script editing functions. 
  
 Update.  
 Reloads all the scripts that have been checked-in since the developer's 
 last update.
  
 Show opened.  
 Pop-up a report of the checked out scripts listing them by developer.
  
 Show stale. 
 Pop-up a report of the scripts that have been checked-in since the 
 developer's last update.
  
 Header.
 Insert a standard script header at the top of the current script.
  
 Variable catalog.
 Documentation tool that parses a script and prompts the user for 
 descriptions of all the local and global variables found in the 
 script. 
  
 Unembed.
 Deletes an embedded script.  

Boulevard was developed completely in Avenue on a Unix platform.  The only 
alterations to the project are the Boulevard scripts, startup and shutdown 
scripts, a menu, and a row of buttons in the scripts GUI. Boulevard scripts 
are embedded to keep them separate from the project scripts under development.
The startup and shutdown scripts load and unload the project scripts and set 
the developers logged-in status in the developer table to true or false. 
The menu items and buttons for the scripts GUI provide the developer access 
to all the functions described above.

Recently, Boulevard was ported to a PC network for another development 
project.  Except for changing the length of a temporary file name, the entire 
system ported without any problems.  Currently the system is being used by 
over a dozen developers on several projects and has become the core managment
utility for all Eagle Information Mapping ArcView projects.  

A testimony to the success of the system is the little attention it receives
from the developers while working on their projects.  Little time is spent
by new developers learning the system and Boulevard related problems are
rare meaning the developers can spend their efforts on developing applications
for clients and not continually trying to fix their environment.  

Future growth of the system will come in the form of added capabilities and
functionality.  The first step will be to allow for development on any project
by developers in windows or Unix.  Other plans are for a project bug reporting
and tracking tool and a tool for tracing script calling sequences creating a
graphic depiction of the scripts and calls.  Eagle Information Mapping 
predicts Boulevard will remain a key tool for large scale application 
development for many years to come.