Guideline: UMF Naming Conventions
This guideline describes the naming conventions for naming method elements in the Unified Method Framework (UMF).
Relationships
Main Description

The Unified Method Framework (UMF) defines a naming convention for each library element: method plug-ins, method configurations, plug-in projects, configuration projects and tag groups.

The UMF naming convention divides the element names into name parts, where each name part is separated by a dot (‘.’). For example, the plug-in name "core.tech.com.base" has four name parts.

The benefits of UMF's naming convention is that it takes advantage of Method Composer support for a hierarchical library view where a new level is introduced for each name part. The resulting hierarchy is defined to optimize configuration of the method. The most important categorization for someone configuring the process is listed first: the plug-in or configuration type.  Licensing level is applied as a suffix and no suffix means open source (in other words, open source method elements do not have a licensing level suffix).

UMF plug-in naming conventions

UMF plug-in naming convention: <plug-in type>.[<context>].<descriptive name>.<plug-in part>[_<part qualifier>][-<source/licensing level>]

Where:

  • Plug-in type:  The following are the possible values for the plug-in type.  For more information on the plug-in types, see Concept: Practice Library Plug-In Types.
    • core = Core
    • practice = Practice
    • process = Process
    • publish = Publish
    • meth_mgmt = Method Management

  • Context: Not required (some plug-ins are "context-free" meaning that they are not specific to any context).  The following are some examples of contexts: 
    • gen = general purpose (general purpose means applies across multiple contexts.  This is NOT the same as context-free)
    • tech = technology
    • bus = business
    • mgmt = management
    • legacy = legacy
    • mdev = method development 
    • sdpl = solution deployment

Note: If you would like to implement "nested" contexts, you can break the context name into multiple "parts", where each of those parts are separated by a dot (period) so that Method Composer creates a hierarchical view of the related plug-ins. For example: You could define an authoring (auth) context that is a sub-context of method development (mdev). In such a case, the name of the context would be "mdev.auth".   

  • Descriptive name: The following conventions apply to the Descriptive name part of of a plug-in name:
    • Actual names will vary, but the name should be descriptive of what the plug-in contains, should be pretty close to the presentation name for the plug-in, using UMF Approved Acronyms.  
    • For example: Descriptive name: pracitice_auth; Presentation name: Practice Authoring.
          
  • Plug-in part: The following are the possible values for the plug-in part.  For more information on the plug-in parts, see Concept: Practice Library Plug-In Types.
    • base = base plug-in
    • assign = assign plug-in
    • extend = extend plug-in
         
  • Part qualifier: Not required. This can be used to provide some additional information about the plug-in part.  This is most applicable for Extend plug-ins, where the part qualifier can be used to indicate the reason for the extension.  For example, UMF-specific extensions to an existing plug-in may be indicated with a "_umf" part qualifier (e.g., "<some plug-in>.extend_umf").   Another exmple of a qualifier is "gbl" for globalization".
  • Source/licensing level suffix.  Can be used to indicate the company that the plug-in applies to and/or the licensing level of the plug-in. Open source plug-ins do not include a licensing level in their names.
    Note: The use of a hyphen (-) rather than a dot or perioed (.) is intentional because the source/licensing level is not intended to be another hierarchical level.  Do no use a hyphen in any other place in the name except to separate the actual plug-in name from the suffix.

Figure 1 provides examples of UMF plug-in names that use these conventions:

Figure 1: Example: Method authoring practice naming conventions

umf_plugin_name_examples

Notice the following points shown in Figure 1:

  • All practices are grouped together because the first part of their names is “practice”
  • All the practices that support a specific context are grouped under the content name (“mdev” in this example)
  • All plug-ins that support method authoring are grouped together because a new name level was introduced in the descriptive name (“auth” in this example)
  • All plug-in “parts” for a practice are grouped together because the practice descriptive name is the same
  • The reason for the extension is included as part of the Extend plug-in name, separated from the word "extend" with an underscore and not a hyphen. For example: practice.mdev.auth.practice_auth.extend_umf and practice.mdev.auth.practice_auth.extend_umf-ibm
  • The licensing level is separated from the rest of the plug-in name with a hypen.  For example: practice.mdev.auth.practice_auth.extend_umf-ibm and practice.mdev.auth.practice_auth.extend_umf-ibm_int.

UMF plug-in project naming conventions

Plug-in projects should be named exactly the same as the plug-ins they contain. See the earlier section on plug-in naming conventions for more information.


UMF configuration naming conventions

UMF configuration naming convention: <configuration type>[.context].<descriptive name>[-<source/licensing level>]

Where:

  • Configuration type: The following are the possible values for the configuration type. For more information on UMF configuration types, see Concept: Practice Library Configuration Types.
    • publish = Publish Configuration
    • zconstruct = Process Construction Configuration
  • Context: Same as for plug-ins.
  • Descriptive name: The following conventions apply to the Descriptive name part of of a configuration name:  
    • For Publish configurations, the Practice Configuration name being published makes a good descriptive name
    • For Process Construction configurations, the name of the plug-in that contains the process makes a good descriptive name
  • Source/licensing level: Same as for plug-ins.

The following are some examples of UMF configuration names that use these conventions:

Figure 2 provides an example of UMF onfiguration names that use these conventions.

Figure 2: Example: UMF configuration naming conventions

umf_config_name_examples

Notice the following points shown in Figure 2:

  • All configurations of the same type are grouped together because the first part of the configuration name is the configuration type
  • All configurations that support a specific context are grouped under the content name (“mdev” in this example)
  • The publish configurations for a specific configurations are easy to spot because the configuration name is in the descriptive name
  • The configuration to be used as the default configuration when constructing a process in a plug-in is easy to spot because the owning plug-in name is in the descriptive name
  • The unique identifier suffix is used to indicate the licensing level of the configurations (e.g., -ibm for commercial content and -ibm_int for internal IBM content)

UMF configuration project naming conventions

UMF configuration project naming convention: configs[-<descriptive name>][-<source/licensing level>]

Where:

Descriptive name: This is optional (i.e., you may only have one tag group per licensing level).  If you use one, the descriptive name should be a name that represents a specific set or category of configurations.  For example:

  • mdev: Method Development
  • mdev.auth: Method Aurhoring (s sub set of method development)
  • mdev.meth_mgmt: Method Development Method Management

Source/licensing level: Same as for plug-ins.

Figure 3 provides some examples of UMF configuration project names that use these conventions.

Figure 3: Example: UMF configuration project naming conventions

umf_config_proj_name_examples


UMF tag group naming conventions

UMF tag group naming convention: tags-<descriptive name>[-<source/licensing level>]

Where:

  • Descriptive name: A name that represents a specific set or category of tags.  For example: mdev: Method Development
  • Source/licensing level: Same as for plug-ins.

Figure 4 provides some examples of UMF tag group names that use these conventions.

Figure 4: Example: UMF tag group naming conventions

umf_tag_group_name_examples
 

More Information