| Foundation1 / Development Guide / Core Server / Services Layer Dev / Modeling / 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.
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.
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.
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.) |
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. |
|---|
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.
| 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. 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}. Syntax according to the Mixed Case
Identifier format. |
|---|
| 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. |
|---|
| 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. |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
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. |
|---|---|
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
|---|---|
| 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,
Syntax according to the Mixed
Case Identifier format. |
| 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. |
| 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. Syntax according to the Mixed Case
Identifier format. |
|---|---|
| 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. |
| 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. |
| 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. |
|---|---|
| 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. |
| Service Package Name |
... Syntax according to the Mixed Case
Identifier format. |
| 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. |
| 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. |
|---|---|
| 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. |
| Implementation Handler Name |
Named according to the handler's intent. Example: "SalesPriceCalculations", "WorkScheduleUtilities", "TravelExpenseTaxRules", etc. Syntax according to the
Mixed Case Identifier format. |
| 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. For service handlers, ... Syntax according to the
Mixed Case Identifier format. |
| 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. |
| 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. |
| 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. Syntax according to the
Mixed Case Identifier format. |
|---|---|
| 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. |
| 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. |
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. |
|---|---|
| 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. |
| 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. |
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. Syntax
according to the Database Identifier
format. |
|---|---|
| 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. |
| 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. Syntax
according to the Database Identifier
format. |
| 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. |
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.
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 |
