ICCS.MD.050 - Module Technical Documentation

ICCS.MD.050 - Module Technical Documentation

	OMG = Oracle Method Guideline
	OMS = Oracle Method Standard

General

OMG-10042:

Document any unusual design decisions including the reasons in the Notes property of the respective object.

Rationale	This helps your team members understand the decisions that have been made. It is also valuable information for anyone performing QA on the project.

OMS-61518:

When a secondary access element or secondary access controlled element (SAC) is deleted, this should be recorded in the notes of the primary access element or Primary access controlled (PAC) element.

Rationale

Analysts or developers might want to know what happened to the SAC. If this kind of information is not recorded, the person that can explain, might not be available on the project, if at all.

Example	The deletion of an attribute is recorded in the notes of the entity.

OMS-61537:

Document any deviations of the CDM Standards in the respective Notes, including the OMS Standard code and the reason.

Rationale	Documenting these deviations helps your team members understand the decisions that have been made. This is also valuable information for anyone performing QA on the project.

Note: If you deviate from any OMS standards on a project level, do not include the deviation for every object. If there is only one Application System involved, then document these deviations in the Description property of the Application System. When there are more Application Systems involved, then it is recommended to document the deviations in a separate document.

Logical Database Design

OMG-10060:

Make separate Server Model diagrams for every subsystem

Rationale	To understand what data is used by what subsystem, it is convenient to have a diagram that shows all tables that are used by that subsystem with their foreign key relationships. This is especially true for large or multi-application systems.

Note: If a diagram with all tables and foreign key relations is already available, it is recommended to start from a copy of that diagram. Remove the superfluous tables and foreign key relationships, so that the basic layout is kept intact.

Window Management

	Modal Window

OMS-58034:

A modal window must at least contain an OK-button (or language equivalent). Choose one of the following button combinations:

Buttons	Usage

OK & Cancel	OK closes the window. In some cases, it may perform a commit as well (see 'Implicit Commits'). Cancel clears the data without asking for confirmation,, and closes the window. Note that usually only very simple modal windows can be modeled this way, and Save, Clear, etc. must be disabled.
OK	Closes a window. Typically used for a window that is display only.
OK, Apply & Cancel	OK closes the window and applies the changes. Apply processes the data, but does not close the window. Cancel closes the window, and clears any pending changes since the last Apply.

Rationale	This is according to standard UI conventions.

Block Layout

OMS-58004:

When showing only one block in a window, do not provide a block border.

Rationale	A block border consumes too much space unnecessarily

Form Generator: This is governed by the BLKDEC preference.

	Block Specific Buttons

OMS-58112:

Buttons within a window should be sized similarly and spaced consistently.

Rationale	This provides a consistent look and feel throughout the application.

Form Generator: The sizing of buttons is governed by the preference AIBBWD (Action Item Button Width).

Navigation within a Form

	Block Navigation

OMS-60054:

Always provide a button to navigate to a detail block if the detail block is rendered in another window.

Rationale	This is the most intuitive way to point out to the user that it is possible to navigate to another window.

PL/SQL Standards

OMS-60062:

Prevent messages from being hard-coded into the application.

Rationale	This offers you the flexibility to easily change message text online and implement multi-lingual messaging.

Application Systems

	Notes

OMS-61517:

Record the deletion of primary objects such as entities, modules, etc. as revision history in the Notes of the Application System. Add new entries on top.

Rationale

Analysts or developers might want to know what happened to the object. If this kind of information is not recorded, the person that can explain, might not be available on the project, if at all.
Putting new entries on top gives quick insight into the latest change.

Example	REVISION HISTORY Label Date Name Description 1.1 12-11-1999 S. Muller Removed function 31 and module ASP0050F 1.0 06-07-1998 L. Jellema Removed entity STATUS 1.1 ---- Removed function 31 and module ASP0050F because their functionality was dropped as result of tighter planning. 1.0 ---- Removed Entity STATUS, functionality now in domain STATUS

PL/SQL Definitions

OMS-45033:

For packages, include in the package specification, at the top of the PL/SQL text, a header with the following items:

Purpose of the package
Usage of the package
Remarks
For each public routine, an explanation of parameters used, a purpose, usage and remarks

Include in the package body, at the top, a header with the following items:
Revision history including the date, who performed the change, what has changed and the construct. The newest entries should be at the top. The first (oldest) line should state 'Creation' in the appropriate language.
For each private routine, an explanation of parameters used, a purpose, usage and remarks

For independent PL/SQL routines (that is those not included in a package), add at the top of the PL/SQL text a header with the following items:
Purpose of the routine
Purpose and Use of each argument
Remarks
Revision history including the date, who performed the change and what has changed. The newest entries should be at the top. The first (oldest) line should state 'Creation' in the appropriate language.

Rationale

In this way, it is properly documented what is the purpose of the routines. This makes it easier during development and maintenance.

Keeping track of what is changed can explain a lot of what happened during the Development. Questions such as, "Why was this changed and who did it?" are easily answered.
Putting new entries on top gives quick insight into the latest change.

Example	Package Specification ======================== package my_package is /*********************************************************************************** Purpose:..Package for file IO. A package level description of the purpose of the package. Usage:....Explaining the usage of the package Remarks:..Package level remarks. *********************************************************************************/ -- -- public program units -- procedure open_file ( p_file_name in varchar2 -- Name of file (including path) ); -- Purpose: Opens file p_file_name. When the file does not exist the file is -- created. When the file exists, the file is opened and the position -- is set to end of the file. A program unit level description of the -- purpose of the program unit. -- -- Usage: p_file_name must be a valid path and file name. The usage of the -- program unit. -- -- Remarks: Any remarks, including known limitations and enhancements, for this -- program unit. end my_package; Package Body Specification ============================= package body my_package is /************************************************************************************* Revision History When.........Who............................Construct ..Revision...What 31-12-1980...Richard Voss...................wrap_line_when_too_long ..1.1........Added rendering algorithm, using a variation of classic mid-point .............displacement. 01-01-1978...Allan Turing ..1.0........Creation ***************************************************************************************/ -- -- private program units -- procedure do_something -- -- Purpose A description of the purpose of this private program unit. -- -- Usage - -- -- Remarks Any remarks, including known limitations and enhancements. is begin null; end do_something; end my_package;

Server Generator: The text entered here is used by the Generate Database from Server Model utility to generate create statements for stored PL/SQL objects.

	Name

OMS-61558:

The name of the PL/SQL definition for a trigger should be the same as the name of the trigger itself.

Rationale	This makes it easier to quickly locate the belonging trigger definition in the repository.

Modules

	Short Title

OMS-43309: When the module is used in a menu or in a button calling the module, then the Short Title must consist of a one or two-word expression. The preference is a one-word expression of the following form:
[noun]
If a two-word expression is used, it should have the following form:
[verb noun]
If any abbreviations are used, these must be self-explanatory.

Rationale	In this way, a short and meaningful indication of the module usage is provided. This is useful as the Short Title is used on menus, buttons, and hyperlinks generated to navigate to this module.

OMS-60058:

Provide each module that is used in a Forms menu with a mnemonic access letter, which is unique within the sub-menu the entry belongs to.

Rationale

Allows the user to choose between the keyboard and the mouse to perform their task.

Example	E&xit -- Shown as Exit in generated menu

Exception: This standard does not apply to Menu Separator Modules, that is Modules where the Language property is empty.

Form Generator: The short title of screen and menu modules is used as the label for the menu entry in a pull-down menu. The mnemonic access letter can be indicated by placing the ampersand (&) in front. If no & is indicated, then the first letter becomes the mnemonic access letter.

Attention: The mnemonic access letter is currently only working for Client Server forms, not for Web Forms. However, this will be fixed in Developer 6i. Enforcing this standard now will avoid problems when upgrading to Developer 6i.

	Runtime Path

OMS-42231:

Do not specify a hardcoded Runtime Path. Define a set of logicals if supported.

Rationale

This makes it easier to port the module from one environment to another.

Example	%%AIF_SRCE%%

	Source Path

OMS-44165:

Do not specify a hard-coded Source Path.

Rationale

This makes it easier to port the module from one environment to another.

Example	%%AIF_SRCE%%

	Help File Name

OMS-60101:

Use the three-letter application code as the help file name when you use an application wide help file.
Use the module short name as the help file name when you use a help file per module.

Rationale	This makes it easier to determine to which application and/or module the help file belongs when viewing the help files outside the context of the application.

	User/Help Text

OMS-44162:

For default modules (that is, not for libraries or menus), the user help text should at least contain a brief description of the module, summarizing the functionality.

Rationale	The user help text is targeted towards the users of the application under development. This makes it possible for the users to understand what is the intended purpose of the module. Help text for libraries or menus is generally not generated into the end user help system, so it is not necessary to include help text for these types of module.

Note: Copy the Function Description as the starting point for the User Help Text.

OMS-44166:

Specific actions performed by the module must be presented here, in a form understandable by the future users of the application for assessment purposes.
(Later on, the user help text can be finalized and refined by a technical writer to make it suitable as online help text.)

Rationale

The future users must be able to assess the usefulness and correctness of a module through the user help text.

Example	By using this module, you can select a department, together with the employees working for that department. You can change the columns containing salaries and commission. You cannot enter or delete employees here.

Generation: Oracle Headstart provides guidelines on how to generate on line context sensitive help text. As an alternative to MS Help, also HTML Help can be generated using the Headstart Utilities. View the Oracle Headstart User Guide for more information.

	Notes

OMS-60064:

Revision History of a Module (and its subobjects like module components and items) must be recorded in the Notes, stating the date of creation, the date and the reason for the change, and the change itself.
Add new entries on top.

Rationale

Keeping track of what is changed can explain a lot of what happened during the Development. Questions such as "Why was this changed and who did it?" are easily answered. It is advised to also record new entries when the deliverable is offered to the client for approval. Putting new entries on top gives quick insight into the latest change.

Example	REVISION HISTORY Label Date Name Description 1.1 06-01-1999 L. Jellema Lookup table usage L_VER added 1.0 06-07-1998 L. Jellema Initial Creation 1.1 ---- Added lookup table usage L_VER in Module Component PRD to enable users to select existing versions for the Product. 1.0 ---- Initial Creation

	Description

OMS-61544:

For modules that are generated using Oracle Generators, the module description should contain

a detailed list of the post-generation activities performed (if any) including a reason
module specific generator settings
special constructions required, for example work arounds for bugs
special template/library objects used

Rationale

This makes it possible for the team to reproduce a module with post-generation steps whenever required. In addition it is clear for the developer why the post-generation steps were required, as well as why specific generator settings were required for the specific module.

Example	POST-GENERATION ACTIVITIES Activity - Reason ------------------------------------------- GENERATOR SETTINGS Activity - Reason ------------------------------------------- SPECIFIC CONSTRUCTIONS Activity - Reason ------------------------------------------- SPECIFIC TEMPLATE/LIBRARY OBJECT USAGES Activity - Reason -------------------------------------------

OMS-61545:

Do not include functional description in the module description when the module implements a business function.
When the module does not implement a business function, but has user interaction, then functional description should be provided in the User Text.
For other modules, functional description should be documented in the Module Description.

Rationale	This prevents duplication of data, and therefore decreases the risk of inconsistencies.

Application Design Transformer: When you run the Application Design Transformer, the Function Description is copied into the Module Description. Cut and Paste this text into the User Help Text property to provide a good starting point for the user help.

	User/Help Text

OMS-61546:

When the module does not implement a business function, but has user interaction, then the functional description should be provided in the User Text, and not in the Module Description.

Rationale	This prevents duplication of data, and therefore decreases the risk of inconsistencies.

Arguments

OMS-61631:

Do not use the Allowable Values for Arguments.

Rationale	The use of domains is preferred. This allows for reuse. If no suitable domain exists, consider creating one.

	Name

OMS-44350: Name parameters using the convention, p_[logical name] .
For parameters that are related to a database column, the logical name element of the parameter should include the column name.

Rationale

This makes it easily visible that it concerns a parameter, and also what kind of information the parameter carries. When the parameter refers to a column normally the logical part of the name should be equal to the column name, but when you have more than one parameter referring to the same column, some kind of qualifier is also needed in the name.

Example	p_airport_code p_civil_state p_old_civil_state

	Input Output

OMS-44354:

For PL/SQL Definitions, always specify whether a parameter is IN, OUT, or IN/OUT (modify).

Rationale	When it is not explicitly defined, the generator uses IN as default. This is not obvious when viewing the argument when this has not been explicitly defined.

	Position

OMS-44352:

For PL/SQL Definitions, always specify a sequence indicating the position of the parameter when calling the routine.

Rationale	This ensures that the parameters are generated in the order as expected, and thereby there is no risk for confusion when positioning the parameters when calling the module.

	Datatype

OMS-44353:

For Forms and Reports Modules, only use the following datatypes for arguments:

VARCHAR2
NUMBER
DATE

Rationale	Oracle Forms and Oracle Reports only support the Datatypes Char, Number and Date for parameters.

OMS-61597: For PL/SQL Definitions where the argument is based on a column, use the PL/SQL construct [table name].[column name]%type .

Rationale	In case the datatype or dimension of a column changes, you do not need to change the definition of the parameter in case the %type construction is used.

Exception: When the %type expression exceeds 70 characters (the maximum length of the property), use a datatype from the pop list.

Note: You do not have to choose a value from the pop list of this property, you can also type in your own value which does not need to occur in the pop list.

	Prompt

OMG-10047:

The first letter of any word in a prompt is capitalized, except for prepositions and other small words, such as and and or.

Rationale

This is a commonly used standard in window applications. By using this standard your application becomes more consistent with the look and feel of other applications.

Example	Name of Mother: Telephone Number:

Module Networks

OMS-61582:

The module network should be complete. That is also including the calls from module specific forms libraries or PL/SQL blocks to other modules.

Rationale	This enables better impact analysis.

Windows

	Title

OMG-10051: If the form does not perform a specific task, then the title is the name of the first object displayed within the Window.

If the form performs a specific task, the title is of the form, [verb] [noun].
The verb may be a contrived or "marketing-ese" word. Avoid the terms Maintain, Update, Define or View, unless the terms substantially clarify the use of the forms that act on the same objects.

The Window Title should be plural where the number of records displayed is larger than one, otherwise the Window Title should be singular.

Rationale

This makes the titles consistent with the users activities and perception

Example	Titles for windows with no specific tasks: Sales Orders Journal Entries QuickCodes Periods Titles for windows with specific tasks: Transfer Items Post Journals Import Receipts

OMS-58505: If the context of the primary window is displayed in the secondary window, then use the following format: [fixed window title detail window] ([context],[context],..) .

Rationale

This makes it easier for the end user to remember to which master data the details belong when working within a detail window.

Example	Journal Lines (NOV93.123) Assignment: OrgA 12-JUN-1992 (John Doe) Benefits (John Doe, Development) Shipments (123, A27-K12)

Generation: Oracle Headstart contains a feature to easily generate window context. See the Headstart User Guide for more information.

	Scrollable ?

OMS-60039:

Set the Scrollable? Property to No.

Rationale	Windows should show the full width and height of the content canvas. This is more user friendly as no items will be unexpectedly hidden for the user.

	Width

OMS-61551:

Use the Canvas width and height of the Module Component rather than the Window width and height in the Window object.

Rationale	The Form Generator automatically sizes the window according to the content canvas width, which is specified through the width and the height of the first Module Component visible in the window.

All Module Components

	Name

OMS-61549: When the Module Component has a base table usage that is based on a true table or a view (that is a table or view that is true to the business), then use the same Module Component name as the table alias for that table usage. If there is more than one Module Component within the same module with the same base table usage, express the purpose of the module component in the name with a few letters: [table alias base table](_[purpose module component])

Rationale

In this way it is immediately obvious what the base table usage is of that Module Component. The Module Component name becomes the block name when it is generated, and thereby it is also immediately visible what the base table usage is of the block.

Example	DEP EMP_UNASSIGN EMP_ASSIGN

	Title

OMS-58044:

Display Titles of Module Components containing a Table Usage of Base Usage Type are singular only if the user commonly works with a single instance of data within the block; otherwise they are plural.
Add a verb to the Display Title, only if it otherwise is not obvious to the user what is the usage.

Rationale	This ensures that the block title is consistent with the users activities and perception.

	Rows Displayed

OMG-10049:

Determine a standard for the number of rows displayed for multi-record blocks

for the number of detail records in a window including both the master and detail block
for the number of records in window with only one block included

Determine a number of alternatives to choose from.

Rationale	This ensures a consistent look throughout the application.

	Overflow

OMG-10050:

Limit the use of Spread Table as overflow style. Consider to use Tab Sheets. Use Overflow Area below or Overflow Area right instead.

Rationale	The Spread Table is experienced to be less user friendly, as the user has to scroll back and forth to view data.

	Width

OMS-60037:

Use the Canvas width and height of the Module Component rather than the Window width and height in the Window object.

Rationale	Form Generator automatically sizes the window according to the content canvas width, which is specified through the width and the height of the first Module Component visible in the Window.

OMS-60038:

Make the Canvas size "just-to-fit".

Rationale	The Window looks better with no large amount of empty spaces. Also using smaller windows enables the user to view more windows at the same time.

Module Component Table Usages

OMS-61618:

If a lookup table has a surrogate primary key (a sequence without meaning to the end users), the items displayed in an LOV must include all columns in the unique key of the lookup table.

Rationale

Surrogate keys are usually not shown to the end users, so for identification of a row of the lookup table, something else is needed. OMS-61617 already states that you need a Unique Key for this.
If you do not display all columns of the unique key in the LOV, it would be possible to have duplicate values in the LOV, and that makes it impossible to validate the foreign key from the display values.

Example	If the table HSD_DEPARTMENTS has a surrogate key (the ID column), do not show that ID in the List of Values (it is meaningless to the user), but show the columns of the Unique Key (NAME and LOCATION). There will never be two departments with the same combination of NAME and LOCATION, so the LOV will not show duplicate rows and the correct DEP_ID will be stored in HSD_EMPLOYEES.

	Usage Alias

OMS-60103: Use the same alias for a base table usage as defined for the table or view on which the usage is based.
For a lookup table usage, use the following naming convention:
L_[table/view alias](#)
where the table/view alias is identical to the alias of the table or view on which the usage is based, and the # is a sequence number starting with 1. This sequence number is only required when there are more lookup table usages based on the same table or view within the same Module Component.

Rationale	This makes it immediately obvious on which table or view the usage is based, and ensures uniqueness of table usages within one Module Component.

	Where/Validation Condition

OMS-60040:

Always enclose the WHERE clause in brackets when using the OR operator.

Rationale	The Form and Report Generators sometimes add their own code to the generated WHERE-clause. Using the OR operator without brackets can lead to unexpected behavior of the query.

OMS-60067:

If the Where Clause of Query implements a documented business rule, provide a reference to this business rule as a comment in the Where Clause of Query property.

Rationale

This provides a reference for the team, and thereby makes it easier to understand why the where clause has been included.

Example	/* BR_ORD023_RER */ code = 'PR';

	Validation Where Clause

OMS-61552:

If the Lookup Validation Where Clause implements a documented business rule, provide a reference to this business rule as a comment in the Lookup Validation Where Clause property. If the business rule is not yet described, do so in this description.

Rationale

This provides a reference for the team, and thereby makes it easier to understand why the where clause has been included.

Example	/* BR_EMP023_RER */ code = 'PR';

OMS-61598:

Always enclose the WHERE clause in brackets when using the OR operator.

Rationale	The Form and Report Generators sometimes add their own code to the generated WHERE-clause. Using the OR operator without brackets can lead to unexpected behavior of the query.

Items

	Prompt

OMG-10052:

The first letter of any word in a prompt is capitalized, except for prepositions and other small words, such as and and or.

Rationale

This is a commonly used standard in window applications. By using this standard your application becomes more consistent with the look and feel of other applications.

Example	Name of Mother : Telephone Number :

Form Generator: You can specify post-field prompts by placing a post-prompt marker in the prompt text. The value for the post-prompt marker can be set by preference ITMPPM. You can specify multiple line prompts by placing a split-prompt marker in the prompt text. The value for the split-prompt marker can be set by preference ITMSPM.

OMG-10053:

Button labels are always short and succinct.

Do use
Lines
Print
Margins
Apply Notes

Do not use
Enter Order Lines
Run Print Report
Set Document Margins
Automatically Apply Notes

Rationale	The button size does not allow for long labels. Keeping the text concise makes it easier for the user to understand their purpose.

OMG-10054:

Buttons that perform an action, but require some other piece of information from the user, always end with an ellipsis (...).

A button that is used to navigate to a detail block does not end with an ellipsis, even if the block is in a modal window. This is because the button action is to navigate, not to enter data in the destination block. The navigational action can be performed without the user supplying additional information.

Buttons that open a confirmation window, because they are potentially destructive or instigate irreversible actions, but do not require additional information, do not end with an ellipsis.

A button without an ellipsis may open a modal dialog box, but a button with an ellipsis must always open a modal dialog box.

Rationale

This provides a consistent look and feel for buttons throughout the application, and thereby makes it easier for the user to understand the meaning of the button.

Example	Choose Options... Print...

	Width

OMG-10055:

When the preference ITMBIF = Y (Base Item Sizes on the Font), a proportional font is used, and the preference TXTSCA = 20 (Scale Factor for DATE, NUMBER and Uppercase Items), then use the following guideline to set the width of an item:

Column Length	Display Length

Non-GUI items 1 to 4 positions long	Column length + 2
Non-GUI items 5 to 8 positions long	Column length + 1
Non-GUI items more than 9 positions long	Default column length, change only in case of character columns when necessary
Pop lists, combo-boxes and text-lists	At least maximum column length + 4
Check boxes in a multiple record group	2
Check boxes in a single record group	At least the length of the prompt + 3
Radio groups	At least the maximum column length + 3
Pop list abbreviation, combo-boxes abbreviation, test-lists abbreviation	At least the maximum abbreviation length
Pop list meaning, combo-boxes meaning, test-lists meaning	At least the maximum meaning length
Current records indicators	1

Rationale	All data should be visible on the screen when possible. You should reserve space for the list handler in case of list items.

	Format Mask

OMS-61627:

Do not use the Format Mask property for Date or Datetime items.

Rationale	This makes it possible to alter the date or datetime format without the need to generate the forms again, and to set the date(time) format dynamically, by using date related variables. Use the following runtime registry settings for Forms: - forms60_output_date_format - forms60_user_date_format - forms60_output_datetime_format - forms60_user_datetime_format - nls_date_format If a forms date item is generated without a format, at runtime it uses the format setting forms60_output_date_format or forms60_user_date_format. If these are not set, it uses nls_date_format. Because of this dynamic setup, changing the date format is simply changing the registry variable.

Warning: This only works if you also comply with OMS-61569.

	Default Value

OMS-45007:

When a check box is defined as the display type, the default value must be set, unless the check box column is optional.

Rationale	A check box can have only two values (checked or unchecked), it should not be 'undefined'. To the end user the difference between unchecked and 'undefined' is invisible.

Form Generator: When the check box column is optional, this implies that the domain must have only one allowable value. An optional column with more than one allowable value cannot be implemented as a check box.

OMS-61553:

When a default value has been defined on table level, you must also define a default on module level.

Rationale	The Oracle Server only applies default values not included in the insert statement. When a column is included in a form (even when it is non-displayed) it is always included in the insert statement, even when the value is NULL.

	Hint

OMG-10083:

Do not include key stroke references in the hint text.

Rationale

This is dependent on the individual keyboard mapping.

Example	Do not use: Hit F9 for a List of Values.

OMS-61628:

Do not include the allowable values for an item in the hint text.

Rationale	Then the hint text must be changed when the allowable values are changed which is often forgotten, and the user should be able to see the allowable values anyway: for example in a pop list or list of values.

Bound Items

	Display Type

OMS-61580:

Never use a pop list or text list as the first item in a multiple record block.

Rationale	Using a pop list or text list as the first item in a multiple record block makes navigation with the arrow keys more difficult.

Unbound Items

OMS-61630:

Do not use the Allowable Values for Unbound Items.

Rationale	The use of domains is preferred. This allows for reuse. If no suitable domain exists, consider creating one.

Application Logic

OMS-61639:

Do not put actual validation code in event triggers. Rather, in the event trigger make calls to routines that have been defined as named routines, custom CAPI services, or pl/sql library routines. This should always be a single call.

Rationale

Application logic that is entered at event level is not reusable. By putting the application logic in a separate procedure or function, this logic can be called from other events, procedures and functions.

Example	The following code might be entered for the When-Validate-Record event. emp.when_validate_record;

OMS-61641:

If you are adding named routines to the module in Oracle Designer, put all named routines at module level.

Rationale	In this way all named routines will be accessible from one place, giving a good overview of the module logic and hence supporting maintenance.

All Lists of Values

	Title

OMG-10048:

The LOV Title is used as the title in the list of values window. Such titles should start with the verb Find (or a language equivalent), followed by the object name.

Rationale

Lists of values are always used to find objects, and the window title should reflect that.

Example	Find Departments

Application Logic

	Event - Name

OMS-61640:

Name the user defined code segment of a module event after the procedure or function that is being called. In the rare case that there is no such call use a logical name expressing the purpose of the user defined code segment.

Rationale	This makes it easy to identify the purpose of user defined code segments of events, without needing to open the PL/SQL logic editor.

	Named Routine - Routine Name

OMS-61642:

Give a module named routine, as entered in Designer, a logical name expressing the purpose of the routine.

Rationale

This allows the routines to be easily identified, without needing to review the code.

Example	emp_increase_salary dep_call_employee_report

OMS-61643:

Do not include the name of the event trigger in the name of a named routine, unless it is an event handling routine.

Rationale

If you need to move the call to another event or to multiple events, the name becomes invalid.

Example	Do not use: emp_increase_salary_wbp (when-button-pressed) emp_chk_hire_date_wvi (when-validate-item)

	Named Routine - Type

OMS-61645:

Do not create packages as named routines in a module in Designer.

Rationale	The only way to find out what is in such a package would be to open the PL/SQL logic editor.

	Named Routine - Routine Name

OMS-61647:

Name a package in a module specific library that is specific to a module component, after that module component. Name the package that contains the other routines after the form module.

Rationale

By using this naming convention it will be easy to identify to what level, and in case of a module component specific package, to what module component a package relates to.

Example	EMP package for the module component EMP DEP package for the module component DEP HSD0001F package for the form HSD0001F