Designer/2000

for Oracle Forms Developers

AN INTRODUCTION TO MODELLING

AND GENERATION

VERSION 1.0: November, 1995
Part C10592

Part C10592
October 1995
Author: Helen Barnes
Contributors: Mark Pirie, Simon Stow
Copyright © 1995 Oracle Corporation.

All rights reserved. Printed in the U.S.A.

This document is provided for informational purposes only and the information herein is subject to change without notice. Please report any errors herein to Oracle Corporation. Oracle Corporation does not provide any warrants covering and specifically disclaims any liability in connection with this document.

Designer/2000 is a trademark of Oracle Corporation. All other company and product names mentioned are used for identification purposes only, and may be trademarks of their respective owners.

Contents

Introduction

Intended Audience

Summary

Evolution of Systems Development Tools

Stage 1 Paper Based Tools

Stage 2 First Generation CASE Tools

Stage 3 First Generation Application Building Tools

Stage 4 Second Generation Modelling and Development Tools

Designer 2000 toolset

Using Designer/2000 during Design and Build

Compliance with GUI standards

Increased Productivity

Team working

Quality end-product

Using Designer/2000 to Document and Maintain an Existing Database

The Value of Reverse Engineering

Reverse Engineering Systems

The Designer/2000 Database Utilities

Reverse Engineering Forms Applications

What Happens During Reverse Engineering?

Prerequisites for Reverse Engineering

The Reverse Engineering Process

Regeneration of Forms Applications

The Role of the Module Definition during Regeneration

Preferences Used In Regeneration

Regenerating a Non-Generated Form

Case study - Pennsylvania Power and Light

Summary

Introduction

Intended Audience

This paper provides an introduction to the features and functionality of Oracle Corporation's modelling and generation toolset, Designer/2000. It is particularly targetted at existing users of Forms (part of Developer/2000) and describes in detail the added advantages of productivity, team working, application wide GUI style compliance and quality that can be achieved when Forms is paired with Designer/2000.

Summary

Designer/2000 combines business and design modelling with generators. It fully exploits GUI client-server deployment platforms with the enterprise capability to deliver large scale systems. The whole development process is supported. Developers and designers can concentrate on design rather than detailed programming and systems are delivered rapidly and changed easily as new or changed circumstances arise.

The ability to reverse engineer both database and application designs into Designer/2000 safeguards investment made in the design of systems. Generating the application into Forms allows it to remain current with respect to GUI-style user interface and advanced database functions and features.

Designer/2000 safeguards your investment in systems design, while providing an integrated and efficient toolset for modelling and generating new applications.

Evolution of Systems Development Tools

The challenge for systems developers has remained largely unchanged in the last ten years; to build effective, performant applications that meet user and business needs in a timely and cost effective fashion. The challenge extends to keeping these applications in alignment with the business as both business and technology change.

We can see four stages in the evolution of the systems development tools used by development organizations to produce such applications.

Stage 1 Paper Based Tools

With few tools - other than those directly used to actually create program code - users, analysts and developers worked together in a fairly ad-hoc fashion to define, design and implement systems. Productivity was a constant challenge and systems often failed to meet user needs.

Stage 2 First Generation CASE Tools

Numerous vendors attempted to deliver lifecycle automation tools which provided modelling techniques to formalize the interaction with users. Early code generators automated some of the construction for programmers. Initially this technology was welcomed as a breakthrough in effective application delivery but issues soon surfaced.

As distributed client-server GUI systems became dominant, few traditional or first generation tools could deliver the kind of capability, productivity and ease of visualization required. The reasons for this include:

• many of the tools are prescriptive, that is, they mandate a method and require the development team to follow all of the steps in that method
• many of the tools support only a waterfall approach to systems development ie development can only proceed to design once analysis is complete and there is little support for iteration of design
• the tools do not support design for client/server architecture
• the build tools provided are often 3rd generation language code generators eg COBOL
• the tools themselves are hard to learn and use.

The move towards GUI applications led to a shift away from extended development lifecycles, where 'paralysis by analysis' was often encountered. Here, so much effort was invested in the early stages of the project, that by the time screens and reports were produced, the business requirement had changed. This led to disillusionment of users, and disenchantment in the development team.

The traditional (first generation) tools did not have sufficient flexibility to support a more interactive rapid application development (RAD) approach, where parts of the application are engineered from analysis through to build, with a high level of user interaction (user responsibility) [1].

Stage 3 First Generation Application Building Tools

Building on the 4GL approach, a new style of GUI client-server application building tool emerged. Characterized by tools like Powerbuilder and Visual Basic, they allowed rapid construction of GUI screens. They seemed to deliver the productivity and ease of use that programmers required, to rapidly deliver appropriate client-server applications to the business. They lacked, however, any modelling capability to provide abstractions from the code, thus still failing to automate the whole process of development. They also lacked many enterprise features such as portability and scalability for serious enterprise systems.

Drawbacks include:

• Team-working is not supported, as there is no central repository for design and standards information, so the implementation of larger-scale projects is difficult.
• Most GUI application build tools are simply that: they provide a build tool but no support for modelling business requirements.
• The tools do not provide an environment for capturing design information in existing systems (design recovery) and subsequent forward generation of applications.

In fact, it can be argued that using GUI application builders alone produces instant legacy systems, with development that is difficult to manage and code which is very difficult to support. It transpires that for a true corporate application systems development, repository-based modelling and generation tools are required.

Stage 4 Second Generation Modelling and Development Tools

Recently a new generation of tools has arrived which combines business and design modelling with generators. These tools fully exploit GUI client-server deployment platforms with the enterprise capability to deliver large scale systems. The whole development process is supported by such tool sets. Developers and designers can concentrate on design rather than detailed programming and systems are delivered rapidly and changed easily as new or changed circumstances arise.

For the last two years Oracle Corporation has been concentrating significant development resource (200+ product engineers) on the construction of just such a second generation toolset. Oracle's Designer/2000 and Developer/2000 are now the strategic development environment of choice for all enterprise application development.

The challenge of producing a repository-based toolset, with full support for team-working, business modelling and generation, and high quality GUI applications has been faced.

Designer 2000 toolset

The Oracle Designer/2000 toolset supports GUI applications design and build. Evolution from Oracle CASE has ensured a sound basis for the current product, allowing enhancements to meet demand for an integrated developers toolset which produces up-to-date applications.

The toolset is modular, so business analysts, designers, builders and database administrators may choose the appropriate set of tools to meet their specific needs and development methods.
Figure 1: The Designer/2000 toolset

 Designer/2000 has four types of tool:

• modelling tools to support analysis activity
• modelling tools to support design activity
• generators to automate the construction of Developer/2000 and Visual Basic applications
• administration tools to manage the repository and browse its contents

Analysis tools

• Process modeller
• Entity Relationshp Diagrammer
• Function Hierarchy Diagrammer
• Dataflow Diagrammer

Process Modeller

The Process Modeller enables you to produce a process diagram, a visual representation of a business process. Each symbol on this process diagram represents a particular stage of the process you are drawing.

The types of symbol are:

• Organization unit - the business division, department or unit responsible for a particular stage of the process
• Process step - task, activity or function that represents a particular stage of the process
• Flow - the movement of data or materials between stages of the process
• Store - a collection of information or materials used in the process
• Trigger - an event that initiates the process
• Outcome - an event that results from the process.

Entity Relationship Diagrammer

The Entity Relationship Diagrammer is a modelling tool used for defining the information needs of a business as an entity relationship model.

Entity relationship modelling involves identifying the things of importance in an organization (entities), the properties of those things (attributes) and how they are related to one another (relationships). The resulting information model is independent of any data storage or access method.

The Designer/2000 Entity Relationship Diagrammer provides:

• A diagramming tool for creating entity relationship diagrams
• Access to a multi-user Repository for creating and maintaining definitions of entities and relationships
• Access to the Database Design Wizard, which automates some of the tasks of system development by deriving a default database design from entity relationship diagrams
• Autolayout facilities for automating the improvement of the diagram layout

Function Hierarchy Diagrammer

The Function Hierarchy Diagrammer allows you to create hierarchies of all the functions that are performed by a business, and to identify which parts of the business can be automated.

The Function Hierarchy Diagrammer is used to:

• Decompose business functions
• Define elementary business functions
• Show how functions use data

A function hierarchy shows the activities carried out by your business. The high-level statement of your company's business function is refined into progressively more detailed functions. This process is called function decomposition.

When the function hierarchy is complete, it is composed of elementary business functions, that is, the lowest level of functions. These are defined in terms of the events that trigger them, the entities and the relationship between the entities and their attributes.

Dataflow Diagrammer

Dataflow diagramming involves the creation of diagrams to show how data flows through your organization. The Dataflow Diagrammer allows you to create and maintain business functions, datastores, dataflows and externals that are stored in the repository. Dataflow diagrams are drawn to represent data dependencies, system components or even the context of a project. Each dataflow diagram represents a single business function for an application system. This function may be a mission statement for an entire organization, or a small series of activities for an isolated part of the organization's business.

Design and build tools

• Data Diagrammer
• Module Data Diagrammer
• Module Structure Diagrammer
• Module Logic Navigator
• Preferences Navigator

Data Diagrammer

The Data Diagrammer is a graphical tool for modeling logical and physical database designs. The database objects can be represented graphically on data diagrams, to show the relationship between the tables, views and snapshots in the system, and the integrity constraints defined on those objects.

Each data diagram represents a collection of database objects that can be distributed physically between one or more databases. Distributed database systems can be modeled using multiple data diagrams, that show how data is to be distributed between databases at local and remote sites.

Using the Data Diagrammer, you can:

• Convert the entity relationship model to produce design-level tables and constraints that can be used as the basis of the database design. The process of converting analysis data into tables and foreign key constraints is automated by the Database Design Wizard
• Model parts of the database schema using data diagrams, that show how data structures are related in the database.
• Lay-out the diagram automatically, using the Autolayout facilities.
• Embed objects from third-party applications, using the OLE facilities.
• Maintain and manage existing design-level data centrally in the Repository and create new design elements.
• Model the distribution of data between local and remote databases, using multiple data diagrams.
• Reverse engineer design-level data, created using the Data Diagrammer, to analysis level. This process is automated by the Table to Entity Retrofit utility.

Module Data Diagrammer

The Module Data Diagrammer provides a way of quickly and easily creating detailed data usages for modules. These detailed data usages are used by the Generators to affect the structure, functionality and layout of generated modules.

The Module Data Diagrammer performs the following main tasks:

• Creates and maintains module definitions
• Creates and maintains module detailed data usages
• Creates and maintains links between detailed table usages
• Defines the layout of generated modules
• Creates and maintains module summary data usages

Generation, regeneration and reverse engineering of modules can also be performed from the Module Data Diagrammer.

What is a Module Data Diagram?

Each module data diagram is based on a module definition, and represents either a screen module or a report module. A module data diagram shows the module detailed data usages, the links between detailed table usages, and for screen modules, the layout placement of each detailed table usage.

Module Structure Diagrammer

The Module Structure Diagrammer is a graphical tool for creating and updating module definitions and for constructing and restructuring a module network.

Using the Module Structure Diagrammer, you can:

• Create modules from scratch or (using the Application Design Wizard) from a function hierarchy defined in the Systems Modeller stage.
• Change the definitions of existing modules in the Repository.
• Set up a new module network.
• Change an existing module network.

Module Logic Navigator

The Module Logic Navigator provides a graphical environment for developing application code for the PL/SQL development environment. PL/SQL code is stored against modules that are maintained centrally in the repository, enabling controlled access to stored procedures, functions, packages, triggers and cursors across development projects.

The Module Logic Navigator provides capabilities for entering, editing, importing, exporting and implementing PL/SQL code. From the definitions of PL/SQL modules, you can generate the data definition language (DDL) script files, using the DDL Generator, that can be used to implement the PL/SQL in the Oracle server.

Features of the Module Logic Navigator include:

• Drag and drop editing
• Syntax checking.
• Text formatting capabilities, such as keyword recognition and automatic indentation

Preferences Navigator

The Preferences Navigator provides you with a way of specifying which preferences are used when you generate forms and reports for an application system.

What Are Preferences?

Preferences are parameters that are used to control the appearance and behavior of generated forms and reports. For example, there is a block decoration preference that determines the type of block decoration that is generated. Every preference has a default that is used by the Generators if the preference is not explicitly set. Each preference is either mandatory or optional. A mandatory preference must always have a value.

Groups of preferences that can be used by an application system are held in named sets. The preference values that are held in named sets are applied to an application system by creating references from the required level on the Hierarchy Tree to the named sets.

Support tools

Repository Object Navigator

The Repository Object Navigator gives an overview of the information stored in the Repository. It can be used in the Process Modelling, Systems Modelling, Systems Design and Implementation stages of the business system life-cycle.

There are two sets of tasks that the Repository Object Navigator can perform:

• Editing tasks (e.g., entering, editing and deleting Repository information)
• Administration tasks (e.g., controlling access to the Repository or backing up data stored in the Repository)

The Repository Object Navigator should be used for checking and fine-tuning object definitions. The Navigator is also very useful for impact analysis, e.g., for checking what columns are in a domain. On the administration side, the repository Object Navigator relates to information in the Repository only. For example, to give a Repository user access to certain repository data, you must use the Repository Object Navigator and to give an Oracle user access to the repository, you must use the Repository Management Facility.

Repository Reports

The Repository Reports consist of around 150 predefined reports, each providing a different view of the contents of the Repository.

Matrix Diagrammer

The Matrix Diagrammer is a tool for cross-referencing, creating and manipulating Repository elements in the form of matrix diagrams. A matrix diagram consists of two axes, each displaying a different element type, and intersection cells, which indicate whether a relationship or association exists between two elements.

The Designer/2000 Matrix Diagrammer provides:

• Facilities for cross-referencing elements in the Repository
• The ability to view and update elements held in the multi-user Repository
• The ability to create new elements in the Repository
• Settings to control the appearance of the matrix, such as the font and justification for element properties
• Settings for filtering and automatically ordering elements on a matrix

Using Designer/2000 during Design and Build

The toolset has the following main advantages for application developers:

• Compliance with GUI standards
• Increased productivity
• Team working
• Quality end-product.

Compliance with GUI standards

The wide range of graphical objects that can be created for a GUI application places design pressures on developers. Choosing from GUI 'widgets' such as radio groups, pop lists, text lists, buttons and a wide set of fonts and colours leaves room for deviation from a consistent style. To further complicate the situation VBX controls can be used as a means of graphically displaying data. This is an issue because users want a consistent GUI across their application portfolio (e.g. they would like employee status displayed using a consistent control across all screens that display this data) and management want consistency for ease of training for new users. Consequently, definition of - and compliance with - site or project GUI standards is vital for building consistent and useable applications.

Using Designer/2000, there are two main aids to maintaining a consistent user interface - preferences and templates. Using the default GUI template and preferences, generation of applications produces a standard look-and-feel for all screens and reports. This can be changed by altering the preferences. At an individual module level, where developers have changed preferences, the preferences navigator will show this so that use of standards can be maintained and monitored.

Figure 2: The Preferences navigator

Increased Productivity

Designer/2000 provides productivity gains at both the personal and team or project level.

Personal productivity

• Generation of the repetitive part of programming applications is an immediate gain in personal productivity.
• The Designer/2000 tools are easy to learn and use.

Personal Productivity Explored - Use of the Module Data Diagrammer

Where developers and users are interacting to agree on the style and layout of a screen or report, the module data diagrammer is a highly productive tool. It allows design and generation of a working module on-line. If the user wishes to change the design, the diagrammer is used to make the change. A simple drag-and-drop action changes the data access of a module and the look of the generated form. This is a great advantage over previous design tools, which stopped short of graphical output and required most of the module level specification to be done on paper. If user sign-off for the design was required and the subsequent code was hand-crafted, then changes could take a long time to work through and delays in delivery of the project could easily arise.

For example, the application design wizard will generate a module data design based on the function-entity usage information in the repository, showing which tables and columns this module will use. Display information defaults from the database design, giving consistency throughout the generated application. The module data diagrammer will show the module with its table and columns, and how these will be displayed in a window.

In the example overleaf, the tables accessed in the module are generated into very different Forms. The difference in appearance is made by simply dragging the tables into a separate window in the module data diagrammer. Even this relatively simple example serves to illustrate the power of the Module Data Diagrammer for Rapid Application Development and increased productivity at the Forms design stage.

Figure 3: Module Data Diagrammer - tables in one window

Shown above are two tables, MAP_DEPARTMENTS and MAP_PEOPLE, in the Module Data Diagrammer. Each has a look-up table, and the tables are related with a foreign key. The box around the tables represents a window in the generated application .

Figure 4: Form generated from Module Data Diagram in Figure 3

Figure 5: Module Data Diagrammer: tables in 2 windows

Here the same table diagram has had one simple drag-and-drop operation performed, to draw a box round the tables MAP_PEOPLE and MAP_JOB. This causes the tables to appear in different windows in the generated Form.
Figure 6: Form generated from Module Data Diagram in Figure 5

Team productivity

Controlling, communicating and reviewing a project team can be simplified using a common repository, quality checks and documentation as provided in Designer/2000.

Modelling as a means of communication

Modelling is an efficient way of sharing information, as it does not rely on the ambiguity associated with many heavily loaded words and phrases in English. For example, 'each customer may be the owner of one or more accounts' can be easily represented using the semantics of the Oracle entity or table models, whereas reading a document where these rules are defined in English could be trying. Errors in the model are much more likely to be detected than errors in prose. Consequently, productivity and quality will rise if the team has access to modelling tools and a shared repository.

Figure 7: Entity relationship diagrammer: each customer may be the owner of one or more accounts

Team Productivity: Design Wizards

The Designer/2000 toolset provides two application wizards for productivity gains. The application design wizard and the database design wizard produce a default design for the application and the database respectively.

What is the database design wizard?

The database design wizard creates and maintains database designs based upon entity models recorded in your repository. Like the entity model, the database design that it generates is stored in the repository.

The Wizard gives you complete control over the scope of the design process, allowing you to choose the types of mappings used, the detail of those mappings, and the types of element that the process creates or modifies. It enables you to create consistent database models quickly in the manner best suited to your requirements.

You can develop the model as a whole, or concentrate on small areas of it. Similarly, you can create full working designs, with full detail in a single step, or you can progressively refine the model, adding detail as you go.

What is the application design wizard?

The application design wizard creates first-cut application designs based on an existing database design and on the functions, business unit definitions stored in the repository during analysis. The resulting modules and their usages can be used for generating applications using the generators.

Team productivity: RON - surfing the repository

The Designer/2000 Repository is an online storage area, accessible to all users, for all information concerning the modelling, design and generation of database applications by means of the Oracle Designer/2000 products. Based on an Oracle7 RDBMS, the Repository provides a structured, well-organized, central location in which to record the definitions of all the elements of a database application at every stage of its life-cycle, from first concepts to application generation. The repository contains the definition of all objects in the application, and a specific navigation tool: the Repository Object Navigator (RON). The tool is an efficient and quick means of navigating around the objects in the repository, and allows both creation of new objects and maintenance of objects already in the repository.

Figure 8: Repository Object Navigator drilling down to entities and tables

Generating code - supportable and maintainable

The ability to generate code from the models enhances immediate productivity, and also over time. As there is a requirement to support and enhance the delivered applications, the models and repository provide high quality documentation and the tools provide a means to change and edit into order to enhance the product for the future.

Team working

The repository

The repository underlying Designer/2000 allows teams to work with common data, process and module definitions. Support for multiple developers working from shared and consistent design models, cuts out repetition, improves re-use, improves manageability and control - all of these dramatically improve the speed of delivery of new applications.

With the ability to share and lock items the toolset is able to support team-working in a large team environment, ensuring control over items in the repository.

Table, module and logic reuse

Objects in the repository can be re-used. This means that design elements such as trigger logic can be designed, quality checked and stored in the repository as a re-useable, high quality element, increasing productivity through re-use.

Repository Reports

Limitations of Reverse Engineering

Prompts and Titles

In Oracle Forms, any boilerplate text which appears on the screen is not associated with any particular object. Thus it is not possible for Oracle Forms Generator to associate any particular text in the boilerplate with any particular item or block. Oracle Forms Generator is therefore unable to reverse engineer any boilerplate text.

Oracle Forms Generator will set the item prompts and the block titles based on the normal display attributes held on the table or column. It is therefore important to define these prior to reverse engineering.

Control Blocks

Designer/2000 has no concept matching that of the Forms control block. Oracle Forms Generator makes no attempt to reverse engineer these structures.

SQL, PL/SQL, Procedures, User Exits

Although Oracle Forms Generator examines SQL and PL/SQL to identify usages of tables and columns (see above section: Module Table Usages and Module Column Usages) it does not attempt anything more. There is currently nowhere in Designer/2000 to store these objects (indeed many of them may make no sense outside of the context of the form).

Non-Database Fields

Non-database fields are not reverse engineered. Note that some non-table fields in the form may be performing functionality for which the requirements may be recorded in Designer/2000. These can be defined in Designer/2000 manually and include:

• lookup items for foreign keys
• summary items
• items with values derived from other base table items in the block

Other non-table items may be providing functionality that Oracle Forms Generator will add, although no such concept exists in Designer/2000. These include:

• Page header date and user fields
• Copy context fields

Therefore, in many situations the required facility provided by the non-database fields is either generated automatically or can be logically recorded in Designer/2000 manually.

Global Variables

Global variables are not reverse engineered.

Module Network

Oracle Forms Generator makes no attempt to determine the modules which the form may call. Thus it does not reverse engineer any user exits which may be called, any forms which may be called and any HOST commands that may be issued within the form.

Allowed Operations on Table Usages

Unlike fields, Forms blocks have no declarative attributes which indicate whether Insert, Update, Delete or Query is allowed within that block. In addition there any many ways, using Forms, that these operations may be prevented. Oracle Forms Generator cannot reliably determine if any operations have been disallowed. Oracle Forms Generator therefore always sets the Insert, Delete and Query flags on the detailed table usage and sets the Update flag if any fields in the block are updateable.

Database Design

Oracle Forms Generator does not attempt to infer any element of the database design from the form e.g cascading foreign keys, cross-column validation, computed columns. It will only create (or update) parts of the module definition.

Regeneration of Forms Applications

When generating a form Oracle Forms Generator uses information from three distinct areas of Designer/2000:

• The Database Definition
• The Module Definition
• Standards Definition (i.e. User Preferences and Template Forms)

Up until the point at which any changes are made to the generated form (using the Forms Designer) these three components may be considered to be the source of the form. Once any change has been made to the generated form definition in Forms, that definition becomes the source of the form.

During regeneration Oracle Forms Generator uses information from the following:

• The Database Definition as recorded in the repository
• The form definition as recorded in the Forms tables or .fmb in the file system.
• The Standards Definitions recorded in the repository (i.e. User Preferences)

The primary focus of regeneration is Oracle Forms Generator continuing the responsibility for maintaining its own trigger code.The module definition as recorded in Designer/2000 is generally not used as input to regeneration.(There are exceptions discussed in the section below: Role of the Module Definition).

The module definition in Designer/2000 is updated to reflect the structure of the regenerated form as though the regenerated form had been reverse engineered (see previous section: Reverse Engineering of Forms Applications). That is, the Designer/2000 module definition is brought into line with the modified form.

When regenerating the form, previously generated triggers may be removed, amended or added to incorporate changes in the database design or in the form definition (e.g. new items or items moved between pages) or in preference settings. A critical point is that trigger code that was not generated will not be affected. In addition to this, generated code can be modified in the Oracle Forms designer and if name of the code group is modified it will not be touched by regeneration. The layout of all existing pages will not be affected, although new pages may be added.

The Role of the Module Definition during Regeneration

The module definition as recorded in Designer/2000 is generally not used as input to regeneration apart from the three exceptions noted below. It is, however, updated to bring it in line with the form definition (now considered to be the source of the form). This is achieved by automatically reverse engineering the form. For further details see previous section: Reverse Engineering of Forms Applications.

Exception 1: Allowed Operations on Blocks

The allowed operations flags on the detailed table usages are used during regeneration to determine which operations are allowed in each block. The trigger code is amended accordingly.

If the update flag is not set, but one or more fields are updateable, then the update flag will be automatically set.

Exception 2: Adding/Amending Foreign Key Lookups

Lookup table and column detailed usages are used during regeneration to determine the requirements for lookup data for foreign keys.

However, if a lookup column usage has been defined as displayed, but there is no corresponding non-database field in the form then the generator will create a new field but place it on a specially created "overflow page" which will appear at the end of the form. The generator will not change the layout of any existing page. The new item must be relocated using Oracle Forms designer. All trigger code associated with that new item will be generated.

Exception 3: Adding New Blocks

Where a detailed table usage has no corresponding block in the form and it is not used to supply lookup data Oracle Forms Generator will, optionally, create a new block. This block will be sequenced within the blocks according to the sequence of the detailed table usage. The new block will always be displayed on a new page (which may come before, after or in between existing pages, according to the block's sequence).

The generation of the new block will otherwise follow the same procedures and rules as for normal generation.

What Happens During Regeneration?

New Blocks

New blocks may be created if Oracle Forms Generator finds a detailed table usage which does not match any block and is not specifying look up requirements.

The block will be sequenced according to the sequence of the detailed table usage. The new block will be placed on a new page which as closely as possible corresponds to the sequence of the block in the form. Thus the new page may be before, after or in between existing pages.

New Non-Database Fields

New displayed, non-database fields may be created for look up detailed column usages which cannot be matched to a corresponding field. The new field will be placed on a specially created overflow page located after all other pages. The new field must be relocated using the Forms Designer after regeneration. All validation and other trigger code associated with this field will be generated as during generation.

New Pages

New pages may be created under two circumstances (see previous sections: New Blocks and New Non-Database Items).

Pages for new blocks will be laid out as defined by the template form. They will be located so that they match the sequence of the new blocks in the form as closely as possible.

Overflow pages for displayed, non-database fields will appear at the end of the form. More than one such field may appear on a single overflow page.

Triggers

Non-generated (i.e. user supplied) triggers and procedures will not be affected during regeneration. Code added to generated triggers (e.g. PRE-INSERT) will not be affected.

During regeneration. nearly all generated triggers may be amended or removed and new generated triggers may be added. There are three exceptions where existing generated trigger code will NOT be affected. These are:

• summary derivation code
• non-database field derivation code
• code to populate user, date and `context' fields.
•  

The scope of generated code that may be affected by regeneration may be further reduced by changing the setting of the user preferences governing regeneration.

Other than these exceptions Oracle Forms Generator is free to alter all previously generated code. Generated code is identified by a "special comment" e.g.

CGBS$MOVE_TO_NEXT_BLK

CGBS$DISABLE_PRVBLK

It is extremely inadvisable, therefore, to modify trigger code so identified.

Examples of why generated trigger code may be affected include:

• The addition of a foreign key
• Changes to column validation rules
• Changes to referential integrity rules (e.g. Cascade Delete for a foreign key altered from `X'-block to `C'-cascade)
• A change to the form layout (using Forms Designer) requires changes to block synchronization.
• Changes to preferences affect the style of block synchronization, coding style, etc.
• A change to the allowed operations on a table
• Changes to the key constraints or check constraints for a table
• Derivation rules for a column have changed
• A table is now to be journaled

Having said this, if it is important to change some generated code then this can be done by changing the code groups name to CG$<old_name>_MODIFIED. From this point this code is not touched during regeneration and any repository changes that may have altered or removed the original code generated will be ignored.

Block Attributes

Most block attributes remain unchanged. The following may be changed:

• The table owner attribute may be changed according to the setting of the TABOWN ('Table owner') preference.
• The column security attribute may be changed if the COLSEC ('Column sequence') preference is set.

Field Attributes

Most field attributes will not be affected by regeneration. There are exceptions though:

• The high and low value attributes may be set if the DVHILO ('Implement single range using field attributes') preference is set.
• The List Of Values Text may be changed unless a non-generated (i.e. user-supplied) SQL statement is found for the field's LOV.
• The `Copy Field' attribute of a block may be set or unset

Comments

Comments are amended as follows:

• A line is added to the MODIFIED section in the form comments
• Warnings raised during regeneration will be added to the form comments
• Table and column usage comments are updated in the form comments
• The referential integrity section of the form comments are updated

What Regeneration Does Not Do

Oracle Forms Inter-version Conversion

Oracle Forms Generator can only regenerate within the same version of Forms. That is, it is not a utility for converting between Forms 3.0 and Forms 4.5.

Layout of Existing Pages

No change of any kind will be made to the layout of existing pages.

New blocks and fields will be added to new pages (see above). This may result in the page numbers defined in the boilerplate text becoming wrong and out of sequence. For example, if the form to be regenerated has 2 pages and a new block is to be added by regeneration then the pages may be numbered as follows: Page 1 of 2, Page 2 of 2, Page 3 of 3. This will need to be corrected using the Forms Designer.

Existing pages will not pick up any changes to the template form, prompts, table display titles or module titles.

Ungenerated Triggers

Triggers which were not previously generated will be untouched during generation. Generated code `around' it may change but the position and content of the ungenerated trigger code will be maintained.

Base Table Items

No new base table fields will be added. If Oracle Forms Generator finds that there are `surplus' detailed column usages for a corresponding block it will remove them from the module definition rather than add them to the form. This is because if the regeneration option is being used the form itself is considered to be the definition source as discussed earlier.

No items will be removed from the form. If Oracle Forms Generator encounters a base-table item for which it has no corresponding detailed column usage it will create a detailed column usage rather than remove the item. Base table items can only be added or removed from the form using Forms Designer.

Block Attributes

With the exception of the TABOWN and COLSEC attributes no changes will be made to other attributes of any existing block.

New blocks will be generated as normal.

Item Attributes

Apart from those noted above (see Section 4.3.6 Item Attributes) no changes will be made to field attributes

Template Form

Changes in the template form will not be picked up by existing pages.

Where the template form is used in the layout of a new page (for a new block) only the layout will be used. That is, no other objects will be copied from the template form (as happens during generation).

Preferences Used In Regeneration

By default, Oracle Forms Generator will continue to be responsible for the maintenance of the vast majority of the code it generates. Thus when you regenerate the form, Oracle Forms Generator may modify, add or remove its own code. However, there are a number of regeneration-specific preferences which may reduce the scope of generation. They are named REGN. and there is one for each area of functionality. When set to N each prevents the regeneration of a specific area of generator functionality. Doing this effectively changes Oracle Forms Generator from being the maintainer of code to being a `first-cut code generator' in that particular area of functionality.

Regenerating a Non-Generated Form

It is still possible to regenerate a form that was not previously generated providing that the form is reverse engineered first. (See previous section: Reverse Engineering of Forms Applications.) However, generated code may be created that duplicates functionality already in the form as non-generated code (e.g. for block synchronization). The non-generated code in question may either be removed prior to regeneration or the appropriate regeneration user preference may be set to N (see above paragraph: Preferences Used In Regeneration).

Case study - Pennsylvania Power and Light

Pennsylvania Power and Light is the owner/operator of the Susquehanna Steam Electric Station, a two unit nuclear facility. PP&L is developing a suite of applications to support work processes for the station. This suite - the Nuclear Information Management system (NIMS) - promises to improve work quality, contributing to substantial reductions in operating and maintenance costs.

The following management expectations were set for the NIMS project:

• applications are owned by business managers and will support the achievement of business objectives
• fundamental business processes will be reengineered before applications are developed
• application development shall be cost-justified
• application development shall follow the software quality assurance guidelines
• from the IEEE for software used in nuclear power plants
• applications will be 100% generated
• applications will have a Microsoft Windows 'look and feel'

PP&L used the Oracle7 database, Designer/2000 and Oracle Forms for the project. The development team consists of:

• development manager
• 26 developers
• Designer/2000 DBA
• Oracle DBA
• systems manager
• 3 documentation/QA staff

The development hardware environment for the project is:

Sun Sparccenter/1000 with 4 x 60Mhz CPUs, 30 Gigabytes of disk

Oracle version 7.1.6

Application server

Compaq Pentiums/Netframe

Novell Netware v 4.1

Client

Dell Dimension XPS P90 with 90 Mhz pentium processors, 32megabytes of memory

Microsoft Windows v3.11

Since May 1995 the following projects have been completed:

completed

personnel profiles (100% generated)

fully functional prototype

radiation protection (100% generated)

component management (100% generated)

analysis

business planning and decision making

work management

training and qualifications

document management

Kurt Mitchell, Application Development manager of the NIMS development team said:

"The NIMS project has achieved its objectives of developing and deploying an application with a Microsoft "look and feel" while maintaining its goal of 100% generation. We have successfully used every aspect of Designer/2000, including the business process modeller, system modeller, system designer, design wizards and module generators."

Below are examples of screens generated from the PP&L application design, to produce 100% generated output.

Figure 10: 100% generated screen

Figure 11: 100% generated screen - master/detail style

The tabbed area on the screen below is a way for users to access different blocks of data.. The tool bar is enhanced from the default shipped with Designer/2000 - it includes a number of extra buttons to implement application-specific functionality. These are generated using the generator template mechanism. Also note the GUI widgets, including radio group, pop-list, scroll bar and fast-forward button.

Figure 12: 100% generated screen with multiple blocks

Summary

Designer/2000 is integrated with Developer/2000, and enhances productivity by providing modelling and generation tools for applications builders.

Using a repository to store design information and generating applications based on repository definitions produces a number of key benefits, including:

time-saving through generation of screens and reports

quality and consistency of user interface

improved teamworking and ease of use

better quality code and end product.

The applications which are generated are of the usability expected from an increasingly demanding user base, by now well versed in the look and feel of GUI products.

Using Designer/2000 to build applications from scratch, or reverse engineer existing applications, produces work which is high-quality, maintainable and reusable. The product safeguards your investment in systems design, while providing an integrated an efficient toolset for modelling and generating new applications.