Naming standards are very important to the IFS Development methodology. Poorly named model items will result in poorly named database objects and will even reflect into client forms. Further naming information is provided in Naming Conventions section.
The name for a model is expressed in two different ways. When a new model is created and saved for the first time, the name chosen for the .mdl file becomes what is commonly thought of as the model name. In addition, the Logical View created will be named Main. This name may be changed to something more descriptive by selecting Logical View in the navigator section, and then using Right Mouse Button Specification – Detail Tab to rename Main to a meaningful name, such as IFS Foundation Demo (Main). Model files should be named to indicate their purpose, such as an IFS Solution name, or a development project or subproject name.
There is a plain text component name that the external world will know it by. Foundation1 Demo Order Entry, for example.
But behind the scenes, component names have an abbreviated form, limited to six characters. DEMORD, for example. Component names are also used as keys in a Foundation table, and will be limited to six characters. Component names are registered and must be unique across all IFS Applications.
The names used in the model will become the basis for automatic generation of database objects, such as tables, views, and Oracle packages. The LU name must be unique across a database schema. This means that a name must be unique across all applications, since they may be installed together in the same schema. A central registry of LU names is maintained by IFS R&D. Developers should check with their project leader to learn about local practice in registering names. The name should not be prefixed with the component name.Names should reflect the business objects being modeled in a simple, understandable way. A balance must be maintained between a name that is too specific or too general. For example, 'Overhead' is very generic and could apply to almost anything.
LU names must start with a capital letter followed by lower case letters. Additional words in the name must start with a capital letter with no intervening spaces or other special characters such as underscores and dashes.
Avoid the use of special characters in names. Database objects generated from an LU name will have an underscore inserted between words in the name. LU WorkOrder will have an Oracle view named WORK_ORDER, a table named WORK_ORDER_TAB, and an Oracle package named WORK_ORDER_API, for example. Be careful with abbreviations, such as Id. If you use ID, the resulting database objects will have …I_D, which is probably not what was desired. Abbreviations in general should be avoided. Numbers are treated as lower case characters and should be avoided.
LU names are limited to 25 characters. The actual hard limitation is for the generated name for Oracle objects, which may not exceed 30 characters. The useful limit then is that total characters in the name, plus uppercase characters in the name, plus 3 characters for the suffix, API for example, must not exceed 30 characters.
An LU derived from another LU using the Generalize relationship should be constructed by adding a prefix to the name of the superclass. SalesProduct is derived and inherits from Product.
In the case of an Aggregate relationship, it is common for the 'owned' LU to have a name constructed by adding a suffix to the name of the 'owning' LU. LU OrderItem, is 'owned' by LU Order, for example.
The attribute name should reflect its contents as exactly as possible. Do not add any prefix reflecting the class name. For example, Name in class Customer should be simply Name, not CustomerName. An exception is for attributes that will be designated as primary keys. These names may have a more descriptive name, such as CompanyId, to improve clarity in understanding code and arguments in Business Logic. Attribute names must be unique within a class.
Names should start with a capital letter. Additional words in the name should start with a capital letter with no intervening spaces or other special characters such as underscores and dashes. For example, CreditLimit, DeliveryDate, OrderId. The resultant Oracle view and table columns will have an underscore inserted between words in the name. DueDate will become due_date, for example.
Operations (methods) should be named to reflect their purpose. They should be named using the same conventions as items already described. Start with an uppercase letter, followed by lowercase. Additional words will start with uppercase with no intervening spaces or other special characters such as underscores and dashes. CheckCredit, GetDiscountedAmount, for example.