What is the Optimal Development Environment Using Designer/2000 and Developer/2000?

Dr. Paul Dorsey, Dulcian, Inc.

Overview

What is the Optimal Development Environment? The number of options that a developer has to build within the Oracle environment is very large. In addition to Oracle products, there are developers building applications with PowerBuilder, Visual Basic, C++, and JAVA. Each product and development environment has its fanatical devotees, each claiming that they have found the ideal development environment. In our shop, we have elected to use Designer/2000 and Developer/2000 together. One would think that once we have made the decision about which products to use, the optimal environment would be easy to define. This is not the case. Anyone who monitors any of the numerous Oracle lists or forums is well aware of the ongoing debate concerning 100% Designer/2000 generation. The purpose of this paper is not to try to provide the “right” answer to the question, but to walk through the thought process we used in determining how to use Designer/2000 and Developer/2000 together.

Striving for 100% Generation is Not Advisable

To produce high quality, state-of-the-art applications that meet the needs of an organization, building them entirely within Designer/2000 is not the best method. Like any single tool, Designer/2000 accomplishes some system development tasks particularly well, and others not so well. Trying to build a robust, complex module entirely in Designer/2000 is an arduous task that can consume great quantities of resources. Some modules that are worth building can’t be generated by Designer/2000 at all. Shops that insist upon all development work being done within Designer/2000 with 100% generation of all modules produce modules that are less sophisticated and functional with higher development costs than shops not restricted by the capabilities of the Designer/2000 generators.

This is not to say that the Designer/2000 generators are not useful. Some modules can be 100% generated. However, a fanatical devotion to the idea of 100% generation of all modules in a complex application is a bad decision.

Exclusive Use of Developer/2000 is Also a Bad Idea

State-of-the-art module development using Developer/2000 involves the use of sophisticated Forms templates. (For a full description of Forms templates, see “VRAD with Developer/2000: The Next Generation” by Dr. Paul Dorsey and Peter Koletzke in these proceedings). Using high-quality, sophisticated templates, it is possible to build applications just as quickly as they can be specified and generated in Designer/2000. In order to achieve that speed of development, you must use a sophisticated template. However, developers who insist that Designer/2000 specification and generation can be accomplished five times as fast as the same form can be built in Developer/2000, are uninformed with respect to the capabilities of Developer/2000 using the VRAD techniques discussed in the paper mentioned above. In addition, developers have greater control of the visual layout of a form built by hand. In the hands of a skilled GUI developer, forms can be more aesthetically pleasing and efficiently laid out when built by hand.

However, it is just as irrational to attempt a development project using Developer/2000 exclusively as it is to use Designer/2000 exclusively. The reason for this is that the cost of the project consists of more than just the initial development costs. In the absence of using Designer/2000 throughout the project life cycle, the development team must enforce their own development method. I am not going to assert that, simply by using Designer/2000, good development methodology is enforced. However, for a team that is methodologically weak, Designer/2000 will, at least, enforce a modicum of sound developmental strategy. This alone gives significant value to the use of the Designer/2000 product. In cases where the team brings a solid development methodology to the project, Designer/2000 does integrate very well with a traditional SDLC approach as described at length in The Designer/2000 Handbook by Dr. Paul Dorsey & Peter Koletzke. Designer/2000 also nicely integrates with RAD projects as described in the paper “Prototyping with Designer/2000 – Using CADM to Support RAD” by Dr. Paul Dorsey included in these proceedings.

The real value of using the Designer/2000 generators becomes apparent as changes to the data model occur. These changes will inevitably occur throughout the development process as well as the life of the project. As such changes are made to the data model, modification of the associated modules can be achieved much more quickly if they have been generated using Designer/2000.

Performing all module development with Developer/2000 will probably have the same development costs for the building of Version 1. However, even during the project development itself, a Developer/2000-centric approach will have a much higher cost because of the continual rewriting of modules. Long term maintenance of these modules will also come at a higher cost.

Using both Designer/2000 and Developer/2000

The best development method is to use Designer/2000 and Developer/2000 together. Use Designer/2000 for generating simple and moderately complex applications. Use Developer/2000 for building key complex applications. Every project will have some number of simple and some number of complex modules. The key to successful overall development is to use the appropriate tool for the appropriate task.

Generation Options

We advocate different approaches for different types of modules. Some modules will be 100% Designer/2000 generated. Others will not use the generators at all. We have developed a 4 level approach:

Level 1: 100% Designer/2000 generated modules

These modules must be relatively straightforward. It should be easy to specify preferences and usages to generate more or less cleanly the first time. All modifications to the module specifications are made within the Designer/2000 repository. The module is then iteratively generated.

Level 2: Generate in Designer/2000 and make modifications in Developer/2000 to the Form-specific template and/or attached libraries so that the module could be 100% generated.

If you allow developers to make modifications to module-specific templates and attached libraries, then the capabilities of what can be generated out of Designer/2000 are greatly enhanced. With highly skilled developers and good underlying templates, a large percentage of applications can be generated using the Level 1 and Level 2 strategies.

Level 3: Generate and break the link

This level involves generating modules in Designer/2000 and making modifications directly to the generated Developer/2000 modules, thus breaking the link to Designer/2000. The problem with this approach is that the ability to regenerate is lost. The best you can do is to document the post-generation modifications so that when the module is regenerated, someone can follow that script to bring the application to production. This is not a highly desirable solution. Changes should be documented in the repository so that the repository is an accurate reflection of the modules. The repository must be accurate so that impact analysis for system modifications, system documentation and potentially even user documentation can be automatically generated.

Level 4: No Generation

Some modules should be developed entirely outside of the Designer/2000 environment. For example, we have a highly complex flexible reporting front-end template that took many months to develop. We then went through a genericization process, which enabled us to build flexible reporting front-ends where users can pass arbitrarily complex sorts, breaks and filters to every report using lexical parameters. (A complete discussion of this module is available from the authors in “Building a Flexible Reporting System Template Using Developer/2000” by Joseph Strano and Dr. Paul Dorsey – email request to cfisher.dulcian@worldnet.att.net)

This module is more complex than anything that Designer/2000 can generate now or is likely to be able to generate in the foreseeable future. However, this module brings enough value to a project and decreases the overall project development time so significantly that its use is warranted even though the module is unable to take advantage of any of Designer/2000’s capabilities.

Presumably, the only time that development should take place entirely outside of Designer/2000 is when the module represents some level of specific module template such as the one described here. Even the largest and most complex modules can usually benefit from the Designer/2000 generators as well as having information about the modules stored in the repository for documentation purposes.

Project Plan to Determine the Ideal Development Environment

In order to determine what development environment is appropriate for a given project, a detailed project plan should be developed including the following steps:

1) Answer Specific questions about the Environment

Some important questions should be asked before the start of the project to guide the development team in making appropriate choices.

A. What are the GUI design standards? In order to be able to take advantage of the Designer/2000 generators, you cannot insist on GUI design standards based upon applications developed in C++. You cannot even insist on a standard based upon modules developed by hand using Designer/2000. To insist on such a GUI standard will prevent any module from being 100% generated.

B. How large should the development team be? Ideally, in order to adopt the approach outlined here, you must have development team members who are both Designer/2000 and Developer/2000 experts. In addition, both skilled Forms and Reports developers are also needed on the design team. Individuals with these types of talents should not be doing data entry or simple application development. Some lower-level developers are also needed. The absolute minimum size of a Designer/Developer project is 8-10 people. Small 1-2-person shops should not even attempt projects requiring both of these products.

C. How large is the project? Larger projects are much more difficult to organize and keep coding and GUI standards consistent across all modules. Using Designer/2000 coupled with a strong application development methodology such as CADM (CASE Application Development Method) greatly increases the likelihood of project success. This is not to say that smaller projects do not also benefit from greater rigor; however, it may be that these projects benefit more from a prototyping environment as described in the Prototyping paper mentioned above.

D. How complex are the modules? Highly complex modules require more sophisticated templates and frequently benefit much less from the use of the Designer/2000 generators. It is important to perform careful initial analysis to determine the best way to build the key modules.

E. What is the potential longevity of the project? Occasionally, there are projects that will have a very short or clearly defined lifetime. For example, the software used to support the Olympic games is only used for a finite period of time. If the project has a finite lifetime, maintenance costs and versioning are irrelevant. Doing more of the work on these types of projects in Designer/2000 makes less sense since there are no long-term maintenance costs to minimize.

F. How long until the development products being used become obsolete? Investing in templates and development methods is, in itself, a project with a finite lifetime. Once the next versions of Designer/2000 and Developer/2000 are released, you will need to rethink, perhaps drastically, the template development methods being used.

G. What is the project deadline? Unfortunately, it is usually the case that a project must be completed as quickly as possible and the deadline cannot slip. It is not feasible to spend six months determining the ideal development environment and expect to use it on a project with a four-month rollout deadline. Having a documented, stable development environment in place can greatly speed future projects.

2. Set GUI Standards and Determine module types

Typically within organizations, the so-called GUI standards consist of a 5-page document of suggestions.

Setting down precise GUI standards is a large task. There may be many types of modules. This step will outline the look and feel of the module types. Questions to answer include:

· What will these applications look like? (Fonts, colors, etc.)

· How will the applications function? (Navigation between modules, etc.)

The GUI Standards document should allow a developer to storyboard an application that is consistent with the corporate standard. It has been my experience that few GUI standards documents meet that criterion.

3. Classify Modules

Modules to be built must be classified according to the four levels of generation options. This often involves a re-examination of the GUI standards. During this phase, developers should ask themselves whether such a rigorous GUI standard is truly necessary. The goal is to classify as many modules as possible within Levels 1 and 2. Decisions must be made about whether to sacrifice some GUI standards or functionality in order to do this. By carefully examining what the Designer/2000 generators can do, it may be possible to modify modules without sacrificing either GUI standards or functionality.

4. Develop and test the modules

At this stage, the real development work begins. All of the Designer/2000 generator preferences must be set and appropriate templates built. Even during this stage, your decisions with respect to module classification will be changing. This is an ongoing, iterative process that evolves along with the developer’s depth of understanding of the tools being used.

After successfully using a template for over a year, we decided to fundamentally re-architect major portions of our template in order to reflect changes in our development methodology. The most difficult aspect of this step is determining when to stop. The template can always be improved or made more efficient. At some point, it is incumbent upon developers to deliver a first version of the project. Setting up templates and an appropriate development environment will be an ongoing process. Development should continue until an adequate set of templates and sets of preferences are in place to build a few projects. At this point, developers will have an improved understanding of the best development environment for their organization and can revisit the development architecture every year or so, or when new products become available.

5. Determine Specific roles

With good templates and well set-up preferences, the skill level needed to generate modules can be lower. The four minimum roles needed by a Designer/Developer project are:

· Builder of forms in Designer/2000

· Builder of reports in Designer/2000

· Builder of forms in Developer/2000

· Builder of reports in Developer/2000

6. Document the development method

It doesn’t help to have a good development method that no one can use or follow. The development environment created should be well documented and understood by the team. Some development strategies may be very complex. Without clear documentation, only the experienced developers will be familiar with the methodology making it very difficult to bring new people onto the team and maintain consistent standards.

7. Develop and execute the training plan

The final step is to ensure that developers can follow the specified development methodology. Training developers in necessary skills must take place in order for the project to move forward successfully.

Critical Success Factors for Building Applications with Both Designer/2000 and Developer/2000

The following factors are necessary in order to use the combined approach outlined above:

1. Personnel with in-depth knowledge of the Designer/2000 generators are important. It is critical to know what the generators can and cannot do along with the easiest methods of doing development. The goal is to achieve the maximum number of modules which are Level 1 (100% generated) and Level 2 (generated and modifiable).

2. Developer/2000 experts are also required. Successful Level 2 Developer/2000 manipulation is important for Levels 2, 3, and 4 type modules. Avoiding a large percentage of Level 3 modules requires skilled Developer/2000 manipulation and coding.

3. An Application architect is needed to determine, at a high level, the appropriate modularization of the application(s) in order to minimize overall project development and maintenance costs while maintaining acceptable quality standards of the applications.

4. Experienced developers who have worked on similar projects can greatly increase the chances of project success.

5. Formal GUI and coding standards will maximize the percentage of modules that fall within Level 1 and 2 types. Some sacrifices will have to be made in GUI look and reel as well as functional standards to take full advantage of the Designer/2000 generators and keep as many modules as possible in Levels 1 and 2.

6. High-quality templates are needed to support each level of module. You will not be able to achieve a high percentage of Level 1 and 2 modules without multiple templates. Minimizing development time with Level 3 and 4-type modules will require still further templating. The higher the quality and sophistication of the templates, as well as an appropriate number of them to handle different styles and types of modules, the higher percentage of modules will be able to be placed in Levels 1 and 2 types.

7. The appropriate project roles must be carefully determined and assigned. Development team skills must be assessed and appropriate training arranged. These steps are critical to a successful project. A full description of these roles is well beyond the scope of this paper. What is required is a skilled development team including an application architect, template developers, Designer/2000 generator experts and developers capable of making modifications within Developer/2000. There are higher and lower level tasks to be performed within each special area.

8. Designer/2000 and Developer/2000 both have “object-inspired” architecture. However, frequently within development teams, I see little evidence of these concepts being embraced. It is all well and good to use a product which has object-oriented capabilities, but if the development team does not think in those terms, these capabilities are wasted. Every project should take less time than the previous one. Each time tasks are repeated, there should be some level of object reuse. One of my greatest surprised continues to be the speed of payback of generic development.

9. Quality Assurance is important for a successful project. It is very common for development methods to be carefully set up and then ignored by other developers with different ideas. This leads to inconsistent and potentially unmaintainable code. You do not want to stifle proposed changes to the development methodology but you do want to enforce that all modules are developed according to the established standard.

Conclusion

Using either Developer/2000 and Developer/2000 exclusively to build modules results in higher costs, lower quality applications or both. The right way to consider this is that Designer/2000 and Developer/2000 are not two isolated products. Rather, they should be considered as two parts of a unified development suite. It is only by taking advantage of the strengths of both products that development costs can be minimized and project success can be achieved.