Re: Design Standards

Steven,
Here is a loose collection of things we developed on my last Forms 5 project, an Assembly
Tracking system. There were about seven people (2 DBAs, 4 programmers, 1 functional user).

Generally speaking, we found it difficult to control the source code and not step on each other.... From past experience, we wanted to avoid "no control" where versions get pushed to users destroying working code, inability to go backwards, etc.

But, admittedly, there seemed to be a lack of good management tools. So, therefore, we came up with our own set of ground rules.

1. A network directory tree was prepared on an NFS mounted Unix box. (could have been any box, really). \Project
   \Forms
   \Master \TestUser (simulates the production rollout) \Bob \Kyle \etc....
   \Procs
   \Views
   \DDL
   \etc...
   

Master is the current, shared, most recent code. TestUser is a copy of this code without source, to simulate the production environment.
Each user may make copies of the code into their own directory.

1a) All Source code was kept outside Oracle and in the directory trees, including stored procs, etc. The rule being: The Subdirectories are the REAL, MASTER code. If you forget to put your code into the subdirectory and it gets overwritten in the database, it's your loss. (This rule was modified by the DBA, so that Tables, Triggers, Views, and DDL were given to DBA who controlled them)

1b) Gentle-people's file locking agreement: When a person takes control of a forms module in Master and wants to warn others not to touch it, they make a copy for themselves, then are allowed to rename the master copy and add their name or initials: MyModule.fmb --> MymoduleBOB.fmb When the person finishes their work, they "migrate" their test code back into the public master area.

Sure, this is elementary and one could still overwrite someone else's code, but this system worked well for us.

2) Oracle Database.
At the request of the DBA, we came up with a methodology for the database
design. Tables and Views and Triggers on tables were controlled by the DBA, who was also responsible for the physical implementation. This was
in the OATS schema. Since the developers needed free access to compile procedures and functions, there was another schema OATSAPP. Then each developer had a local schema, BOB, KYLE, etc. A developer could create a local table to develop a concept, either in OATSAPP or BOB/Kyle/etc. When this piece of work was finished, it was handed over to the DBA for formal completion of design (physical implementation, which tablespace,
questions about Ref. Integ. etc.) ...then, the DBA would create the OATS table and destroy the local table.

2a) Public synonyms were used to prevent having to explicitly declare table names in every Forms module.

2b) We made a rule. Every Table would have by definition a base view. All developer code would by written against base VIEWS not tables. This would guarantee a layer between physical tables and Forms. MyTable_T gets a view named MyTable_V.
Messier to maintain, but more flexible in the long run. We had a situation once where we wanted to replace a table temporarily... easily done by pointing the view to the temp table and ALL the FORMs code stays the same....Problem solved, and we point the view back to the real table again.

3) Naming standards. Our naming conventions were by agreement, and we weren't especially strict on style...it was an evolving process. There are so many styles of naming, we just eventually came to some agreements...
  Tables ended in _T, Views in _V
  Forms: prefixes were generally used:
    CNV_ canvas, DB_ data block, BTN_ button, etc.

3a) Unique data.
Sequence generated keys were given additional characters to uniquely identify the number value, so that if databases would ever be merged, there would not be duplicate numbers. Example: xx=location, such as city or division, etc.

      yy = type of key, such as userid, callboard id, etc. Thus, sequence 12345 becomes xxyy000012345, as in LBUI000012345. These types of keys were designed to be completely hidden from the user: The user would always see the fields that relate to the business rules, never the internal number (no need to confuse them).

4) Local and public libraries.
This was a multi-module project. As standards developed so did complexity.
Globally useful functions and procedures were put into a library, which was connected to all modules. At the developer's discretion, local procedures and functions

5) Documentation:
We published a technical document describing the names and usage of procedure and function calls, for internal use by the developers:

MyFunc             Location:  Library - ATSLIB  (where it is located)
                              Stored Procedure, etc

         Function MyFunc(parm type, parm type....etc)

Description: This function blah, blah, blah.... The business rules are etc etc etc....

Probably there are much better methodologies available, but these rules evolved and worked very well for us, A small team, with easy access to one another...we worked well together, trusted each other...etc.

We did regret not having a tool which could "read" Forms object code and compare to point out differences...because the only alternative whenever there was doubt was to read EACH property side-by-side and compare...Very messy! But we only had to do this maybe twice...

There are many little details to numerous to write, but this is a start anyway

Hope this helps,
Feel free to write if you have questions. Robert Proffitt
Beckman Coulter
Brea California
(RTProffitt AT Beckman DOT com)

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't. Received on Wed Jul 14 1999 - 19:27:12 CEST