Development and Deployment Strategies

Top  Previous  Next

Multi-Programmer Development

One-Piece EXEs

EXE Plus DLLs

 

Overview—EXEs, .LIBs, and .DLLs

The way you organize your application files can have a significant impact on the efficiency of your work processes throughout the life cycle of the application. For example, developing all of your procedures within a single .APP file keeps everything under one roof. This can be a benefit for smaller applications—keeping all files in a single directory makes finding and backing up the files quite easy if there are reasonably few files. This benefit can become a problem for larger applications—backing up or compiling hundreds of files at once can be time consuming and tricky. So you can see how organization affects the development phase of your application.

The ultimate size and number of your application’s executable files affects your ability to quickly and easily distribute upgrades and bug fixes to your end users. This is one way that organization affects the maintenance phase of your application.

This appendix discusses of some of the factors you should consider when deciding how to structure your application files, both for the development and maintenance phases of the application. This includes instructions on how to implement the organization that best suits your needs.

Generally speaking, the benefits of breaking large programming projects into smaller logically related pieces are:

 

Development Phase

·

Smaller, more manageable problems.

·

The ability to test and debug smaller pieces of code. The smaller the code, the easier it is to isolate problems.

·

Faster compile and link times.

·

The ability to make your code generic and reusable.

·

The ability to delegate programming tasks to multiple programmers.

 

Maintenance Phase

·

The ability to sell and distribute discrete application components.

·

The ability to deploy bug fixes and upgrades with small files.

·

For reused code, the ability to affect many procedures by changing a single source file.

These benefits are most easily realized by creating multiple .APP files that are used to make separate .DLLs or .EXEs that are developed and tested independently. As the project nears completion the executable files are linked together and tested as a whole.

 

 

Some problems associated with breaking large programming projects into smaller pieces include:

Development Phase

·

Managing more files: backing up, naming conventions, and synchronization of files becomes a bigger job.

·

Correctly linking together related pieces of executable code.

 

Maintenance Phase

·

Managing more files: version control is more difficult. The end user must have a complete set of compatible files.

·

For reused code, unintentionally affecting many procedures by changing a single source file.

·

Accidentally omitting a required file during deployment.

 

 

Multi-Programmer Development

Clarion’s modular approach to source code management, its procedure-oriented language, and its ability to produce .DLL and .LIB files allows your team to split the work on big programming projects.

Our recommended methods for group development assume the team is linked by a LAN, which supports the ability to grant read-only or read-write privileges to individual developers. It doesn’t matter whether the LAN is peer-to-peer or a more traditional network operating system. We also assume the project will have a Team Leader or Project Manager to coordinate the overall efforts of the team. Finally we assume, as per our license agreement, each Clarion programmer has a licensed copy of Clarion.

The first step to prepare for a team-development project is to create a data dictionary available to all developers, but which only the team leader may edit. An Application Generator option (Open Dictionary Files and Template Registry as Read-Only check box under Tools  Application Options) provides support for opening the Data Dictionary and TemplateRegistry.TRF in read only mode, so that many developers working with separate .APP files can work with the same dictionary. Prior to beginning the project, all team members should synchronize their TemplateRegistry.TRF and their template source files. The Team Leader should be responsible for the dictionary and the template set.

Once the data dictionary is created, there are three basic approaches your team can take to use Clarion as a group development tool:

·

Procedure-oriented:

The team divides the application into procedures, as listed in the Application Tree. These should be organized around the various windows, dialog boxes, menu items, and command buttons that form the user interface.

The Team Leader prepares a "shell .APP," (or master) upon which all the others build. Each team member receives a copy of the .APP file, then works on a procedure (or procedures). The Team Leader imports the completed procedures into the master .APP file for compiling. This approach is suitable for small to medium size projects.

·

Module-oriented:

The team divides the application into its target-file-level components (.DLL’s, .LIB’s, and executables). Each team member creates a single target file. Separate project files (.PRJ) compile the individual components. A master project file may include all the other project files, building all target files at once. This approach is suitable for medium to large size projects.

·

Sub-Application:

The team divides the application into its target-file-level components (.DLL’s). Each team member creates a single application or Dynamic Link library (.DLL). A master application calls each .DLL. This approach is suitable for medium to large size projects. This method provides the most flexibility and minimizes version control concerns.

 

Enabling and Organizing Team Projects

This section describes how to set up the Clarion Development Environment at each workstation, and where to store the files necessary for all three group development approaches:

1.

Create the data dictionary in a shared directory.

All team members working on the project must have read rights to the directory. Those permitted to edit the dictionary should also have write privileges, though it may be best that only the Team Leader be allowed to edit it.

2.

Create a shared directory for resource files.

Provide read rights for all team members to icon, cursor, bitmap, and other resource files.

3.

Within Clarion, at each workstation, choose Tools  Application Options.

This opens the Application Options dialog.

4.

Check the Open Dictionary Files and Template Registry as Read-Only checkbox.

This specifies that when working in the Application Generator, the copy of Clarion residing at each workstation opens the dictionary file on the network in read-only mode. The purpose is to ensure that no one accidentally deletes a field, file, or key needed by other team members. For this reason, we recommend that only the Team Leader have write privileges to the directory containing the dictionary. To modify the dictionary, all team members must close all applications that use the dictionary. The Team Leader must clear the Open Dictionary Files and Template Registry as Read-Only box in order to modify the dictionary and, upon completion, check the box again.

5.

Press the OK button to close the dialog.

6.

Create a directory on each workstation’s local drive to hold each team member’s individual .APP and source files.

The real work is planning how to split the development project, which is what the remainder of this chapter discusses.

 

If your application’s .DLLs use your application files, the FILE definitions and all Global variables must be declared in a .DLL (not the .EXE) and exported. See the Sub-Application Approach for more information.

 

Procedure Oriented Approach

The Application Generator lets you import and export procedures from other .APP files. With careful management, a Team Leader can organize development so that each team member can compile and test a copy of the application that includes the parts he or she works on. Each views the entire menu and the application’s most important dialog boxes, yet executes only the procedures for which that team member is responsible.

 

This approach is only necessary If your team members are not using Enterprise Edition, or do not have Version Control/team Developer.

To accomplish this, each team member requires a copy of a "master" .APP file, containing the MAIN procedure (which would most likely be an Application Frame procedure), plus other procedures inserted below it as "ToDo" procedures. Each team member then "plugs in" the procedures he or she is responsible for.

To assemble the complete application, using the Application  Import from Application command, the Team Leader imports each finished procedure into the master .APP file.

The following outlines a possible implementation of the procedure-oriented approach:

1.

Create the data dictionary and set up the workstations as described above.

2.

Create a "master" .APP file in a directory to which only the Team Leader has write privileges.

3.

Within the .APP file, edit the MAIN procedure’s most important user interface elements and declare its global variables.

The user interface elements may include any dialog boxes or windows of particular importance to the application. As you specify procedure calls to menu items and/or toolbar controls, the Application Generator automatically adds "ToDo" procedures the application tree.

4.

Save and copy the .APP file to each team member’s local drive.

If the team prefers, you can rename each copy; for example, MASTER01.APP, MASTER02.APP, etc. or JIM.APP, JANE.APP, etc.

5.

Team members work on the procedures for which they are responsible, using their own copy of the .APP file.

With the .APP file containing the complete user interface, each team member can compile an interim build locally, to test their own procedures while under development.

6.

Each team member synchronizes their local directory with an equivalent directory on the network at the end of each work session, or copies renamed .APP files to a "master" directory.

7.

To update the master .APP file with the latest work from a developer, the Team Leader replaces a "To Do" procedure in the Application Tree with a completed procedure in a team member’s .APP by importing it. The Team Leader chooses Application Import from Application, indicating the same procedure in the .APP file in the developer’s network directory.

Any sub-procedures added by the team members will be brought along as new "To Do" procedures. When the Team Member completes these, they can be imported in the same manner. As the Team Leader’s master .APP file "grows", it can be copied back to team members’ individual directories (but only if all the work done by the individual team member was imported). This way, each team member has access to all the work completed by other members of the team. Keep in mind that each of the other member’s modules will need to be compiled on the member’s local drive.

If the Team Leader is also a team member—i.e., also responsible for coding procedures—it’s best to maintain a completely separate directory and copy of the master .APP file for that work.

8.

After importing the updated procedure, the Team Leader checks to see if it added any new "To Do" procedures to the tree, and imports those, if ready.

Communication at this step is vital. In fact, based on E-Mail messages within the team, the Team Leader could optionally import "works in progress."

9.

The Team Leader compiles the project, so that it now includes each team member’s work added through importing procedures.

10.

The Team leader repeats the last three steps on a periodic basis until all work by all team members is complete, and the entire application can be tested.

 

Module Oriented Approach

With this approach, each team member creates a separate target file. This requires splitting the application into a "Main" executable and "secondary" executables or dynamic link libraries. The individual team members maintain separate project files (.PRJ) for each component. The Team Leader creates a master project file to build all target files at once.

The key to successfully implementing this strategy is extensively pre-planning the "division of labor" between the various target files created by the application. The Notes section below provides a few helpful suggestions.

The following outlines a possible implementation of this strategy:

1.

Create the data dictionary and set up the workstations as described above.

2.

Each team member creates their own .APP and .PRJ files, specifying the dictionary file on the network as the data dictionary, and a directory on the local drive as the default directory for the .APP file. Each team member specifies a different target file.

One particular .APP or .PRJ file creates the executable which launches or calls library functions or procedures in the others. To the end user, this is the .EXE program to start when working with the complete application.

3.

Each team member synchronizes their local directory with an equivalent on the network at the end of each day.

4.

The Team Leader creates a master .PRJ file which includes all the other .PRJ files, in a network subdirectory.

The Team Leader inserts the name of each .PRJ file (previously copied to the network) in the Projects to Include item in the Project Tree.

5.

The Team Leader compiles the master project, which in turn compiles all the target files one by one.

6.

The Team leader repeats the last step on a periodic basis until all work by all developers is complete, and the entire application can be tested.

 

Notes on Splitting the Project

There are probably as many ways to split a project, as there are projects; this section provides a few general suggestions.

·

If a task associated with a menu command requires extensive coding, store it in its own external .DLL, so that only a single developer can work on it.

A typical example might be an accounting program, which could store all procedures and functions associated with accounts receivable in one .DLL file, accounts payable in another, and so forth.

·

Organize .DLL’s by function; for example, place utility procedures and functions such as backups and file exports in a UTILITIES.DLL.

·

Store user defined functions in .LIB files; distribute the compiled .LIB files to each team member as they become available so that each may test any functions required in their own work.

 

Notes on File Management

Each multi-developer project has its distinct properties, so you’ll undoubtedly adapt the following suggestions to fit your needs:

·

Create a subdirectory for each team member on the network drive, either at the same level or below the one holding the data dictionary file. Give each developer write privileges only to their own directory, and use a network utility to synchronize the directories at the end of the day.

This not only serves as a backup, but provides the Team Leader access to the latest work done by all members of the team.

·

If the application under development creates an .INI file, a copy of it should reside in a network directory to which all team members have write privileges, so that if anyone should need to add a variable to the file, other members of the team can see it.

 

Sub-Application Approach

This section describes the steps to create a program using one main application and several sub-applications compiled and linked as external .DLLs. Dividing a large project into multiple .DLLs provides many benefits:

·

Each sub-application can be modified and tested independently.

·

Developers can work on their portion of the project without interfering with others on the development team.

·

Each sub-application can be compiled as a .DLL and tested in the main program without recompiling the entire project. This reduces compile and link time.

·

Dynamic Pool Limits are avoided in large projects.

·

Future updates can be deployed by shipping a new .DLL, reducing shipping costs.

 

The Clarion runtime libraries assume the .EXE or .DLL where a window was most recently opened is where any referenced icons are located.

With this approach, each Team Member creates a separate .DLL that is called by a "master" application. This requires splitting the application into a "Main" executable and "secondary" .DLLs. The individual team members maintain separate application files for each component. The Team Leader creates a master application that calls the sub-applications and a "data" application that contains (and exports) all the File definitions and Global variables. Optionally, members can call procedures from another member’s .DLL.

This method also requires extensive pre-planning of the "division of labor" between the various target files created by the application. The previous section provides a few helpful suggestions.

The following outlines a possible implementation of this strategy:

1.

Create the data dictionary and set up the workstations as described above.

2.

Create a "data" application to store and export all data declarations. All Global variables or structures and all file definitions are defined (and exported) in this application. Use the following settings:

In the Application Properties dialog:

Dictionary File:

master dictionary

First Procedure:

none

Destination Type:

.DLL

 

In the Global Properties dialog General tab:

Generate template globals and ABCs as External:     OFF

 

In the Global Properties dialog File Control tab:

Generate All File declarations:

ON

External:

NONE EXTERNAL

Export All File declarations:

ON

 

You do not need (and should not have) OWNER, NAME or PASSWORD on those FILES which have the EXTERNAL attribute. These attributes should only be on FILEs not declared EXTERNAL.

3.

Team member create their own sub-application .APP files, specifying the dictionary file on the network as the data dictionary, and a directory on the local drive as the default directory for the .APP file. Each team member specifies a different target file using the following settings:

In the Application’s Module Tree:

Choose Application Insert Module, then in the Select Module Type dialog, select ExternalDLL, then in the Module Properties dialog, select the corresponding .LIB for the .DLL containing the data definitions.

 

In the Application Properties dialog:

Dictionary File:

master dictionary

Destination Type:

.EXE for development

 

.DLL for release

 

Changing the Destination Type enables procedures to be exported. Make sure that every procedure that is called by the master application or another .DLL has the Export Procedure check box in the Procedure Properties checked (the check box is only available after changing the destination type).

 

In the Global Properties dialog General tab:

Generate template globals and ABCs as External:     ON

 

In the Global Properties dialog File Control tab:

Generate All File declarations:

OFF

External:

ALL EXTERNAL

All Files declared in another .App:

ON

Declaring Module:

(Leave this blank)

 

In the Global Properties dialog External Module Options tab:

Standard ABC LIB/DLL?     ON

One particular .APP creates the executable which launches or calls library functions or procedures in the others. To the end user, this is the .EXE program to start when working with the complete application.

4.

Team members synchronize their local directory with an equivalent on the network at the end of each day.