Previous | Table of Contents | Next
Page 386
querying tables. However, keep in mind that views are just stored
select statements and can be used post-generation for the minor changes requested by the users, such as
new reports or security changes to the application.
- Before the creation of modules, make sure that the default data is
entered. Before modules are created, default data should be entered in the table definitions. The following
defaults can be verified for every table: display datatype, display sequence, format, prompt,
hint, default order sequence, and display length and width. This will save a lot of time
when modules needed to be redeveloped.
- Display meaningful error messages. When users enter invalid information in fields, it
is better to provide meaningful error messages to them that indicate what the valid
values are rather than give them meaningless system-generated errors.
- Enforce standards. Standardization in development can lead to increased
development efficiency, reduction of maintenance, and reduction in the learning curve for
new developers. Designer/2000 provides many reports that enforce standards. It
also provides an API that consists of a set of views against the repository tables and a set
of PL/SQL packages that enable the repository to be updated. The API can be used
to generate reports that list/fix the violations in the standard.
- Learn about the generation preferences of forms and
reports. The time spent in understanding the preferences during generation pays off at the end by reducing
post-generation efforts.
- Set the default preferences for the application. Become familiar with the preferences
that can be set at the application level and should be left unchanged for the
generated modules. Other preferences can be used for each generated module as needed
to conform to the design standards.
- Learn and use the forms and reports generators. Many developers like to use the Designer/2000 generators to generate a skeleton form or report and do most of
their development using Developer/2000. However, the DES2K generators are quite
useful, and if you take the time to understand their capabilities, it will result in a high
percentage of generation.
- Involve users to a certain extent in the project. It definitely helps to get user approval
for the prototype, and constant communication with the users is essential. But after a
certain point the users should not be allowed to make suggestions; otherwise, the system will
be constantly changing, and user expectations can become very high.
- Post-generation should start after all the modules are
generated. If post-generation is started at an early stage, major changes in data design will be difficult to incorporate
in the final modules.
- Document post-generation steps. Use the DES2K repository to store a detailed
description of post-generation steps so that the developers can easily reapply these steps if there
is (and usually there is) a need to reapply the steps. You can use the module's text
fields like "notes" or create your own custom text fields to store this information.
- Customize the templates. DES2K provides a number of templates that can be
customized to implement specific needs.
Page 387
- PL/SQL should be placed in library functions, procedures, and
packages. This will simplify code maintenance of the modules. The template code can access these libraries, and
if there is any change to the code in the library, the modules will immediately reflect
the changes without recompilation.
Designer/2000 Release 2.0 provides a variety of new features. These features include:
Extended Server Generation:
- Support for Oracle7, Oracle RdB, Oracle Web Server
- Support for non-Oracle databases: MS SQL Server, Sybase, DB2/2, and Informix
- Support for ODBC databases
- API generation for DML and lock procedures for tables
Client Generation:
- Design Reuse: Once a module is defined, its components can be shared with
other modules.
- Application logic: Store PL/SQL, Visual Basic and Java code.
- Generators integration.
- Generation of database triggers based on declarative design information in the
repository.
- One hundred percent reverse engineering of application logic as well as one
hundred percent generation.
Design Editor:
- A single fully integrated design and generation environment.
- Maximize ease-of-use by means of wizards, drag and drop, edit-in-place, right
mouse menus, and synchronized updates.
Migration Paths to Designer/2000 R 2.0:
- Designer/2000 R 2.0 can perform upgrades on Designer/2000 R 1.x repositories.
- A separate utility will be provided for upgrading from CASE 5.0.x and 5.1.x to
Designer/2000 R 1.3.2. The repository can then be brought up-to-date with R 2.0.
Application Upgrades:
- The Restore facility in the RON can be used to upgrade a pre-existing Release 1
application or a set of applications to Designer/2000 R 2.0. A two-step process upgrades
the archived applications to be 1.3.2-compliant and then upgrades this to R 2.0.
- The disadvantage of this approach is that if the upgrade process is aborted due to
errors, it has to be restarted with the original archive. To prevent this from happening,
analyze the data before archiving it.
Page 388
Coexistence of Release 1.x and Release 2.0:
- 16-Bit Release 1.xYes, provided that the 16-bit Release 1.x and the 32-bit Release
2.0 are in separate Oracle homes.
- 32-Bit Release 1.xYes. Installing Release 2.0 on top of existing Release 1.x will not be
a problem, because the default directory names are different in Release 2.0.
Cautions:
- The NLS_LANG parameter in the Registry must match the
NLS_LANG parameter in the server; otherwise, it will cause problems when loading package definitions during
install and upgrade.
- A typical upgrade should take 2_3 hours to drop the existing API, and another 2_3
hours to load the new API and perform instance conversion and initialization.
- If the RAU has invoked SQL*PLUS, do not manually invoke SQL*PLUS; it can lead to process hands and even corruption of the repository.
The introduction of Oracle8 has taken the databases and the applications built on those
databases to a whole new level, both in the amount of data stored and the number of
users supported. Designer/2000 provides a complete set of modeling and generation tools for
the relational and object constructs of Oracle8.
Designer/2000 2.0 provides support for all the Oracle8 scalability features, including:
- Partitioning of tables
- BLOBs (binary large objects) and CLOBs (character large objects)
- Index organized tables (IOTs)
- Deferred constraint checking
- Type tables
- Collections
- Object views (represent a relational structure as though it were a type)
- Embedded types
- VARRAYS (multivalued columns)
- Nested tables (tables embedded within other tables)
- References (directly reference one object from another)
Designer/2000's schema modeler has been extended to use the scalability and object
features of Oracle8 without compromising ease of use. It allows you to design database schema or
load existing schema definitions into its repository. The server generator then translates the
graphical representation into the appropriate SQL DDL to implement it. Designer/2000 uses
unified modeling language (UML), an emerging open standard from the Object Management
Group (OMG) to represent its type models.
Previous | Table of Contents | Next
|