Naming Standards

Naming things in the model can sometimes be a more challenging task then to design the model itself. However boring, tedious and difficult, naming is it is still one of the most important parts of modeling. If a bad name is decided upon early in a project, it tends to still be there when the project is finished and causing confusion for support and further upgrades.

So, please take the time early on to use good names that describes the model artifacts as closely as possible.

Contents

Special considerations when modeling for already existing logical units

Many of the modeling artifacts are based on already existing logical units. The naming rules, technical constraints and de-facto standards that were used when the logical units were modeled cannot be directly applied to these "newer" models.

Simply using the same name may be a good idea in some cases and a very bad idea in other cases. Please take some time to consider what the corresponding logical unit really contains, and set an appropriate name accordingly.

  1. Abbreviations, that are not obvious, should be spelled out. It is better with a long name then a cryptic one. For example "CustomerOrderReservationType" rather then "CustOrdReservationType".
  2. Avoid generic names, that implies that the content encompasses more information then it really does. Specify the name within the scope of the whole business, not just within the module or solution. For example, a "DayType" entity that really contains day patterns for work schedules should probably be named "WorkScheduleDay" instead.
  3. Prefix names with proper intent, if there is a chance for ambiguity. For example, "UserProfile" instead of just "Profile", in case there will be entities called "CustomerProfile" or "ProductProfile" later on.

It is also a good thing to do a data type cleanup. Data types should be specified according to their real intent, not the implemented LU data type. Since logical units don't support Booleans, there are many places where text or number attributes can be mapped into a distinct true/false value pair. There are also places where numbers are stored in text datatypes, etc.

Common naming formats

Some of the modeling artifacts follows the same formatting rules. The most common of them are found in the following list.

Mixed Case
Identifiers
Most names for modeling artifacts uses mixed case identifiers and follows the following rules:
 - Only letters A-Z, a-z and digits 0-9 are allowed, i.e. no spaces or special characters.
 - First character must be an uppercase A-Z.
 - Each name consists of one or more English words.
 - Each new word in a name begins with an uppercase letter. (i.e. "UseColor", "FirstSecondThirdLast", etc.)
 - Abbreviations in a name typically has only uppercase letters. (i.e. "ISOUnit", "EANCode", etc.)
Database
Identifiers
Database artifacts must use naming syntax that follows rules set by the database:
 - Only uppercase letters A-Z, underscore and digits 0-9 are allowed, (what about # $ and some other characters?)
 - First character must be an uppercase A-Z.
 - Each name consists of one or more English words.
 - Maximum length of 30 characters.
 - Words are delimited by an underscore. (i.e. "COLOR_CODE", "FIRST_SECOND_THIRD_LAST", etc.)
 - Abbreviations in a name are treated as a word. (i.e. "ISO_UNIT", "EAN_CODE", etc.)

Modules

A module and technical component is the same thing. Since we already have a lot of these, the naming of existing modules must be exactly as they are already named and spelled in IFS Applications.

Module Id For already existing modules, named exactly as lowercase of the corresponding module name in IFS Applications.
Example: "accrul", "mpccom", "timrep", etc.

For new modules, any lowercase identifier with one to six letters (probably need to be approved by steering committee).

Syntax is one to six lowercase letters a-z.
Must be unique within whole IFS Applications.

Logical Models

The logical models will be referenced and shown in many places where the application is documented and described. It is therefore very important to set logical and describing names on the artifacts within the logical models, especially for entities and activities.

Activities

Name Typically constructed as a combination of a verb and a noun.
Example: "RegisterCustomerOrder", "ReleaseCustomerOrder", "PlanMaterialRequisition", "ManageInternalCustomer", etc.

When an entity has a state machine, most of the state changing activities will follow an {action}{entity} syntax.
Example: "RegisterCustomerOrder", "PlanCustomerOrder", "ReleaseCustomerOrder", etc.

Managing basic data seldom has any detailed activities. In that case it's often sufficient with a single activity named Maintain{entity} or Maintain{entity group}.
Example: "MaintainISOCodes", "MaintainWorkSchedule", "MaintainSalesPart", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Diagrams

Name One or more words that describes the diagram contents.
Example: "Main", "Schedules", etc.
Note. One diagram must be named "Main".

Syntax according to the Mixed Case Identifier format.
Must be unique within the same module.

Entities, Aspects and Shared Details

Entity
Name
Typically constructed as noun that describes it's contents (in singular).
Example: "CustomerOrder", "MaterialRequisition", "InternalCustomer", etc.

When using an already existing logical unit, please do not change the name of the entity from the logical units' name.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications (since activity groups, entities, aspects and shared details typically are used as package name they share the same namespace).

Filter Name Typically constructed as a set of words that describes it's intent.
Example: "ReadyToProcess", "ValidForAquisition", "HasPaymentAllowed", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the entity and all of it's aspects.

State Name Typically named with an adverb that describes the entity's state.
Example: "Preliminary", "Cancelled", "Released", "Closed", "InProcess", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the entity.

Attribute Name One or more words that describes it's contents.
When connected to a logical unit, the attribute is named according to the corresponding column, but in mixed case.
Example: "OrderNo", "OrderClass", "Project", "DueDate", etc.

When using an already existing logical unit, please expand abbreviations and rename obvious naming flaws.

Syntax according to the Mixed Case Identifier format.
Must be unique within the information object (shares it's namespace with associations).

Association Name One or more words that describes the association's role.
When connected to a logical unit, the association is named according to the corresponding reference column, but in mixed case.
Example: "Customer", "Project", "Authorizer", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the information object (shares it's namespace with attributes).

Reports

Reports are always modeled using the Report Wizard, either through right-clicking and selecting "Report Wizard" when modifying an existing report or through right-clicking and selecting "New Report Schema" when modeling a report from scratch. This wizard will handle most of the naming for you, but still, there are a couple of naming conventions that are useful to be aware of.

Name The report id in mixed case, without underscores. The report id being the name of the Oracle view defined in the RDF for the particular report (the &VIEW variable in the RDF).
Example: For the report with id MODULE_REP the name would be "ModuleRep", for INSTANT_INVOICE_REP it would be "InstantInvoiceRep" and so on.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications and it always will be since it's derived from the Oracle view name.

Main View Name The wizard will always create a main view with the same name as the report. It's important that the main view name is the same as the report name. Remember that this name will be read and used by a person developing a report layout using Report Designer. This could be an IFS employee or a customer making a customization to an existing layout.
Example: For the report with id MODULE_REP the name would be "ModuleRep", for INSTANT_INVOICE_REP it would be "InstantInvoiceRep" and so on.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications and it always will be since it's derived from the Oracle view name.

Detail View Name Detail views are created to logically group information in the report. The detail view can be linked to a parent view two different types of relations. The type of relation affects the naming. It can either be an aggregate view or an aggregate array view to the parent view. For both relation types the view name should reflect the logical grouping. Remember that these names will be read and used by a person developing a report layout using Report Designer. This could be an IFS employee or a customer making a customization to an existing layout.
Example: "Address" and "PageFooterInformation" would be typical names of a detail views linked to a parent view using an aggregate relation. "OrderLine", "Customer" could be samples of detail views linked to a parent view using aggregate array relationship. See the detail view aggregate name below as well.

Syntax according to the Mixed Case Identifier format.
Must be unique within the report.

Detail View Aggregate Name The name of the aggregate very much depends on what the detail view is used to group. The type of the aggregate also affects the if it's an aggregate array, the most logical name is usually the same name as the detail view it self, but with the added plural s. If it's a normal aggregate it all depends on what information the detail view groups. Remember that these names will be read and used by a person developing a report layout using Report Designer. This could be an IFS employee or a customer making a customization to an existing layout.
Example: Considering the example names used for details views above, logical names for the aggregates could be "DeliveryAddress" and "PageFooter" for the ordinary aggregate ones. For the aggregate arrays, suitable names could be "OrderLines" and "Customers".

Syntax according to the Mixed Case Identifier format.
Must be unique within the report.

Report View Attribute Name A logical name that clearly describes its contents. Very often the view name it self describes the type of information stored in that particular view. The name of the attribute does not need to include this information as well, even if it can be from time to time to make things clearer. If the view name is "CustomerOrderLine" for instance, there's no need to name an attribute "CustomerOrderLineDescription". Simply naming it "Description" would work just fine. Remember that these names will be read and used by a person developing a report layout using Report Designer. This could be an IFS employee or a customer making a customization to an existing layout.
Example: "Description", "LineNo", "CustomerId", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the particular report view (main view or detail view).

Report Parameters Always imported from the report definition, same name as defined in the RDF. Never created/changed manually.
 
Report Texts Always imported from the report definition, same name as defined in the RDF. Never created/changed manually.

Enumerations

Name Typically constructed as a noun that describes it's intent (in singular).
Example: "CustomerOrderType", "PaymentMethod", "ComponentStructureStyle", etc.

When using an already existing logical unit, please expand abbreviations and rename obvious naming flaws.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Enumeration
Value Name
Typically constructed as a verb that together with the stereotype's name describes it's intent.
Example: "Direct", "Temporary", "ExtraBulk", etc.

Please note that,
Code generation for Java converts to uppercase with underscores between words.
Code generation for C# converts to lowercase with underscores between words.

Syntax according to the Mixed Case Identifier format.
Must be unique within the stereotype.

Default Storage
Value
Use an abbreviation of the value name.
For logical units, the storage value must be identical to the LU's database value.
Example: "D", "T", "E", etc.

Syntax is pretty free, but typically use only US-ASCII characters.
Must be unique within the stereotype.

Client Packages

Package Name Typically a name that describes the business area or functionality that the contained features performs.
Example: "InventoryBasicData", "MaterialRequisitionConsole", etc.

For activities that need fairly large clients, use the a same that reflects the activity it implements.
Example: "CustomerOrderRegistration", "CustomerOrderPlanner", "CustomerOrderControl", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Feature Name A short name that best describes the feature's contents and purpose in the context of it's package.
Example: "Details", "ReleasedOrders", "Notify", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the package.

PlugIn Name A short name that best describes the plugin's contents and purpose in the context of it's package.
Example: "ShortList", "Entry", "Show", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the package.

Packages

Entity
Package Name
Typically exactly the same as the entity name that it implements.
Example: "CustomerOrder", "MaterialRequisition", "SalesPart", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Activity
Package Name
Typically exactly the same as the activity group name that it implements.
Example: "InventoryBasicDataManagement", "MaterialRequisitionProcessing", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Service
Package Name
...

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Diagram Name One or more words that describes the diagram contents.
Example: "Main", "LineDetails", etc.
Note. One diagram in each package must be named "Main".

Syntax according to the Mixed Case Identifier format.
Must be unique within the same package.

Handlers

Entity
Handler Name
Same as the entity name that it implements with an added "Handler" suffix.
Example: "CustomerOrderHandler", "MaterialRequisitionHandler", "SalesPartHandler", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Activity
Handler Name
Same as the activity name that it implements.
Example: "RegisterCustomerOrder", "ReleaseCustomerOrder", "PlanMaterialRequisition", "ManageInternalCustomer", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Implementation
Handler Name
Named according to the handler's intent.
Example: "SalesPriceCalculations", "WorkScheduleUtilities", "TravelExpenseTaxRules", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

Operation Name For entity handlers, a standard set of generated names and optionally other operations that are modeled manually. Each name just specifies the verb and does not include the entity name itself.
Example: "Get", "Save", "Prepare", etc.

For activity handlers, a set of generated names for management, browse and list of values together with other operations that are modeled manually. Each name should use verb+noun and specify both the intent and the entity.
Example: "GetCustomerOrder", "SaveCustomerOrder", "ListCustomer", "ListSalesPart", etc.

For service handlers, ...

Syntax according to the Mixed Case Identifier format.
Must be unique within the handler.

Parameter Name For views, typically named as the view.
If the parameter is an array, use plural.
Example: "CustomerOrder", "CustomerOrders", "Condition", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the operation.

BizAPI Name Outbound messages are typically prefixed with "SEND_" and inbound messages with "RECEIVE_".
Example: "RECEIVE_SUPPLIER_INVOICE", "RECEIVE_CUSTOMER_ORDER_CHANGE", "SEND_INVOICE", etc.

Please note that these names are globally published to external applications and systems. Use names that can be preserved in future releases.

Syntax is underscore delimited uppercase words.
Must be unique within whole IFS Applications.

Documents

Document Name Views in entity packages (typically generated for you) uses the same name as the entity and it's information objects have. Each level in the information structure has it's own set of views.
 - The entity name is used for top level view (main view) that contains the complete structure.
 - One view prefixed with "Abstract" that contains only the key attributes.
 - One view per aggregate in the structure, typically named according to the corresponding information object.
 - One view per aggregate in the structure and the top level view, only containing it's own attributes,  suffixed with "Base".
Example: "Customer", "AbstractCustomer", "CustomerBase", "CustomerAddress", "CustomerAddressBase", etc.

Views in activity packages can be named freely according to the business case.
 - Extended entity views may well be named identical to the original entity view.
Example: "CustomerOrder", "SalesPart", "Customer",  etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the package.

Attribute Name Typically the same as the attribute name in the corresponding information object.
Example: "OrderNo", "DueDate", "Description", "SalesPrice", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the view.

Association Name Typically the same as the association name in the corresponding information object.
Example: "Customer", "Project", "Authorizer", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within the view.

Logical Units

Since the purpose of this part of the model is to describe the interface towards an already existing views and packages, the naming must conform to already set standards and to already existing names for logical units, views and packages.

Name Named exactly as the corresponding logical unit is named. Spelling should be identical.
Example: "ActualCost", "InternalCustomer", "InvPartForecastConsum", etc.

Syntax according to the Mixed Case Identifier format.
Must be unique within whole IFS Applications.

View Name Named exactly as the corresponding view is named in the Oracle dictionary, with uppercase letters, underscores and digits.
Example: "ACTUAL_COST", "INVENTORY_PART_IN_STOCK_NOPAL", etc.

Syntax according to the Database Identifier format.
Must be unique within whole IFS Applications (tables, views, indexes and packages share the same namespace).

PL/SQL Package Name Named exactly as the corresponding PL/SQL package is named in the Oracle dictionary, with uppercase letters, underscores and digits.
Example: "ACTUAL_COST_API", etc.

Syntax according to the Database Identifier format.
Must be unique within whole IFS Applications (tables, views, indexes and packages share the same namespace).

Database Objects

These modeling artifacts are descriptions of things that will be loaded into a database. Therefore, the naming should be exactly as the database dictionary will name the corresponding database object after the application is deployed.

View Name When creating a new view, typically named according to the corresponding information object, but in uppercase with underscores between each word.
Example: "APPLICATION_MESSAGE_SEQ", etc.

When using an already existing view, use the name exactly as it is spelled in the database dictionary.
Example: "ALL_TAB_PRIVS_MADE", "V$_PARAMETERS", etc.

Syntax according to the Database Identifier format.
Must be unique within whole IFS Applications (tables, views, indexes and packages share the same namespace).

Table Name Typically named according to the corresponding information object, but in uppercase with underscores between each word.
Example: "LDAP_CONFIGURATION_TAB", etc.

Syntax according to the Database Identifier format.
Must be unique within whole IFS Applications (tables, views, indexes and packages share the same namespace).

Column Name When creating a new view or table, typically named according to the corresponding attribute, but in uppercase with underscores between each word.
Example: "INTERVAL_VALUE", "DUE_DATE", "ORDER_NO", etc.

When using an already existing view or table, use the column name exactly as it is spelled in the database dictionary.
Example: "TNAME", "TYPE#", "OBJNO", "PINC", etc.

Syntax according to the Database Identifier format.
Must be unique within it's table or view.

Index Name Named after the table it indexes, with suffix _PK for primary key index, or suffix _IX, _IX2, _IX3, etc.  for additional query indexes.
Example: "LDAP_CONFIGURATION_PK", "LDAP_CONFIGURATION_IX", etc.

Syntax according to the Database Identifier format.
Must be unique within whole IFS Applications (tables, views, indexes and packages share the same namespace).

Reserved Words

Logical and implementation artifacts

Since most of these artifacts will manifest themselves in code (typically Java and/or C#) the reserved words also comes from these programming languages.

Java
Reserved Words
new main final for byte int float double void instanceof while if else import package return public private protected abstract try catch finally throw throws class extends static native synchronized volatile transient switch default boolean true false null
C#
Reserved Words
new main final for byte int float double void instanceof while if else import package return public private protected abstract try catch finally throw throws class extends static native transient sizeof interface switch default boolean true false null object explicit base out this fixed unchecked unsafe readonly implicit ref virtual volatile delegate lock enum string namespace decimal continue checked foreach typeof

Note that reports are excepted from reserved words checks, since they are only definitions and will not be used to generate any code.

Database artifacts

There are different sets of reserved words, depending on the type of artifact. Database objects (tables, views, indexes and packages) share the same namespace with SQL reserved words and with database dictionary artifacts. Database columns share namespace only with SQL reserved words.

None of the database artifacts should not use any of the SQL reserved words (listed below). Doing so, will result in syntax errors when executing SQL statements. For example, naming a table to "FROM" with a column named "FROM" would result in a (clearly invalid) SQL statement like "select FROM from FROM".

For Oracle we also have PL/SQL reserved words, but that should not be any problem, since we don't use any of the storage model artifact names directly to create PL/SQL code, only SQL statements. When generating PL/SQL variables an underscore is appended to the name, thus avoiding any conflict withy reserved words.

A more subtle issue is that artifacts can be named something that is part of the database dictionary. This is especially tricky, since the database dictionary may change in future database releases. A good design is to avoid all names that begins with the listed prefixes below as well as the most commonly used dictionary objects.

Oracle Reserved Words
(SQL)
ACCESS ADD ALL ALTER AND ANY AS ASC AUDIT BETWEEN BY CHAR CHECK CLUSTER COLUMN COMMENT COMPRESS CONNECT CREATE CURRENT DATE DECIMAL DEFAULT DELETE DESC DISTINCT DROP ELSE EXCLUSIVE EXISTS FILE FLOAT FOR FROM GRANT GROUP HAVING IDENTIFIED IMMEDIATE IN INCREMENT INITIAL INDEX INSERT INTEGER INTERSECT INTO IS LEVEL LIKE LOCK LONG MAXEXTENTS MINUS MLSLABEL MODE MODIFY NOT NOWAIT NULL NUMBER OF OFFLINE ON ONLINE OPTION OR ORDER PCTFREE PRIOR PRIVILEGES PUBLIC RAW RENAME REVOKE ROW ROWS ROWID ROWNUM SELECT SESSION SET SHARE SIZE SMALLINT START SUCCESSFUL SYNONYM SYSDATE TABLE THEN TO TRIGGER UID UNION UNIQUE UPDATE USER VALIDATE VALUES VARCHAR VARCHAR2 VIEW WHENEVER WHERE WITH
Oracle Commonly used dictionary objects CAT COL COLS DICT DICTIONARY DUAL TAB TABS
Oracle Public Synonym
Prefixes
ALL_ DBA_ DBMS_ HS_ LOADER_ NLS_ ORA_ OWA_ USER_ UTL_
Oracle Public Synonyms
(differs between versions)
ANYDATA ANYDATASET ANYTYPE AUDIT_ACTIONS CHANGE_SETS CHANGE_SOURCES CHANGE_TABLES CLU COLUMN_PRIVILEGES DATABASE_COMPATIBLE_LEVEL DATABASE_PROPERTIES DBJ_SHORT_NAME DBMSOBJGWRAPPER DBMSZEXP_SYSPKGGRNT DBURITYPE DEFCALL DEFCALLDEST DEFDEFAULTDEST DEFERRCOUNT DEFERROR DEFLOB DEFPROPAGATOR DEFSCHEDULE DEFTRAN DEFTRANDEST DICT_COLUMNS EXPLAINMVARRAYTYPE EXPLAINMVMESSAGE FTPURITYPE GLOBAL_CONTEXT GLOBAL_NAME HTF HTP HTTPURITYPE IND INDEX_HISTOGRAM INDEX_STATS JAVASNM JAVA_XA MAP_OBJECT OBJ ODCICONST OLAP_EXPRESSION OLAP_NUMBER_SRF OLAP_SRF_T OLAP_TABLE OUTLINE OUTLN_PKG PBSDE PLITBLM PRODUCT_COMPONENT_VERSION PRODUCT_PROFILE PRODUCT_USER_PROFILE PROXY_ROLES PROXY_USERS PROXY_USERS_AND_ROLES PUBLIC_DEPENDENCY QUEUE_PRIVILEGES REPCAT_REPCOLUMN_BASE RESOURCE_COST REWRITEARRAYTYPE REWRITEMESSAGE ROLE_ROLE_PRIVS ROLE_SYS_PRIVS ROLE_TAB_PRIVS SEQ SESSION_CONTEXT SESSION_PRIVS SESSION_ROLES STMT_AUDIT_OPTION_MAP SYN SYSTEM_PRIVILEGE_MAP SYS_XMLAGG TABLE_PRIVILEGES TABLE_PRIVILEGE_MAP TRUSTED_SERVERS URIFACTORY URITYPE WPG_DOCLOAD XDBURITYPE XMLAGG XMLFORMAT XMLSEQUENCE XMLSEQUENCETYPE XMLTYPE