• 30
• Using Designer/2000 with Developer/2000
• Why Use Developer/2000 Too?
• What If I Need to Make Changes to a Module?
• Creating and Tracking Module Documentation
• Summary

30

Using Designer/2000 with Developer/2000

Why Use Developer/2000 Too?

After months of analysis, modeling, and design, you finally generate the application system. You create the database and its tables. You generate and compile modules of forms, reports, and PL/SQL code. All that you need to do now is set up the client machines to run the run-time applications and give them access to the newly generated forms and reports. The client is overwhelmed and very impressed by how much you accomplished in such a short time and how close you actually came to what he wanted. Then, the requests come: "I really work better with graphs and charts such as my old spreadsheets; can my Oracle form do this?" Looking through Designer/2000, you see the Server Generation tools, the Form Generator, and the Report Generator, but no Graphics Generator. There is not even a menu, button, or toolbar available on any of the Designer/2000 diagrammers; however, you know you've seen examples of graphs being used in Oracle.

Remember what the Designer/2000 tool is supposed to do for you. As with any CASE tool, you use it to help ensure that you meet business rules and requirements and follow relational database rules. Designer/2000 provides an easy way to study the impacts of system changes and even offers some basic project management, change management, and version control capabilities. The report or form layouts might never come out exactly as intended, though. What Designer/2000 does not provide is a way to perform the debugging, tweaking, and tuning necessary to make an application development effort a complete success.

For this type of module designing and testing, the Developer/2000 tools pick up where Designer/2000 leaves off. With Developer/2000, you can actually create graphics or develop forms and reports to access legacy systems using ODBC drivers or one of Oracle's gateways. Developer/2000's other advantages include the debugging utilities and performance testing. With the new object-oriented capabilities of the tools, you can easily move a PL/SQL function that was running on the client side to the server and back again to see exactly where it runs faster. The speed at which you can create modules using the Developer/2000 tool might be a business saver, too. Any new development in Developer/2000 can be reverse engineered into the Designer/2000 repository definitions without much effort. You can find more information about using the Developer/2000 tools in Part VI, "Developer/2000."

What If I Need to Make Changes to a Module?

When you need to make any change to a form or report that has already been generated, you should use Designer/2000 first. If they are only cosmetic changes, there is no real functionality change. You need to document the changes in the repository so that when you need to make a major functionality change, you can restore the cosmetic changes.

As seen in Figure 30.1, the module properties include several documentation text fields. You can use a module generation history field to log when and why the module was regenerated from the repository. You can track module release notes along with any other documentation.

Figure 30.1. Module property sheet documentation.

The Designer/2000 tool provides an entire subcategory for tracking module change history. This is useful in tracking dates, directories, and descriptions of the changes that you make to a module, as shown in Figure 30.2. These changes do not necessarily correspond to a module generation—for example, you made a cosmetic change.

Figure 30.2. Module change history.

If you need more documentation items than what Designer/2000 provides, remember that you can extend the repository itself using the Repository Administration Tool. This enables you to add module subcategories and individual text fields for existing subcategories.

Creating and Tracking Module Documentation

You can also track detailed user, maintenance, interface, test, or any other documentation that you generate for the modules you create. There is actually an application category called Documents, as shown in Figure 30.3.

Figure 30.3. Repository documentation category.

In the Documents category, you can actually store documents or provide path names for the documents' locations. You can also store information about document creation and changes. Best of all, each document has a subcategory called Document Attachments that links the document to any of the following repository categories:

Any documentation you do on a system should be tracked in some way. The Designer/2000 tool provides a perfect solution for doing this by providing the beginnings of a simple document tracking system. As mentioned previously, the repository is not limited to what initially comes with the Designer/2000 product. There are always user extensions that you can add to meet your needs.

Summary

You can utilize both the Designer/2000 and Developer/2000 tools throughout the life cycle of an application, but it does require some effort. Although both tools work well together, they are still separate products that work just fine by themselves. All developers and designers should remember the effort it took to create all the definitions and specifications to model and meet the system requirements. You should also put the same effort into the entire maintenance life cycle to ensure that you meet the final goal of the repository. That goal is to provide the information systems staff with a tool to better gauge the impact of future system changes and enhancements—which also provides for an easier way to interface future applications into your existing applications.