-
Notifications
You must be signed in to change notification settings - Fork 17
Naming of packages, classes and attributes
In older UML editors there were “bugs” that would not allow different packages to contain elements with the same name. For this reason, ISO TC 211 at that time introduced, essentially, “namespace” prefixes to the classifier names, like “GM_” for geometry and “TP_” for topology. In the current UML editors, the separation of packages is handled correctly and therefore
the prefixes used in older standards are not longer needed. Where confusion in a diagram is possible, the namespace packages can be easily displayed to clarify the intent of the diagram.
However, in some cases there may still be a value in the prefixes - for human readability. But the main rule of thumb is to view namespaces in diagrams instead.
Here's a list of prefixes used in existing ISO/TC211 models: https://github.com/ISO-TC211/HMMG/wiki/Prefixes
ISO19103 - Conceptual Schema Language - have several rules and recommendations for naming of packages, classes, attributes and roles. The main rule is
Requirement 16: The names of UML elements shall be case-insensitive unique within their namespace and not contain white space.
For implementation in GML, ISO19136 - GML in addition require that the name shall be an "NCName" as defined by W3C XML Namespaces. An NCName is more restricted than the requirement above, and can only contain normal letters, numbers and a few other characters ("-",".","_"), but no special characters like "!","#","?" etc. Also, NCName can not begin with a number, "." or "-", although they can appear later in an NCName
Remark: For attributes and roles, the namespace is the class. So according to this rule, the same attribute name may be used on different classes. But in addition, ISO19109 - Rules for application schemas - have a recommendation saying
/rec/uml/property-name: The name of an ATTRIBUTE, OPERATION or ASSOCIATION end should be unique within an Application Schema, or should have the same intention with respect to the CLASS owning the property as any other property with the same name in the Application Schema.
This recommendations is closely related to the recommendation /rec/general/property-name in the same standard, which is a recommendation for the general feature model (GFM).
Also, these recommendations from ISO19103 should be followed:
Recommendation 8: Names of UML elements should use precise and understandable technical names for classifiers, attributes, operations and parameters.
Recommendation 9: Names of UML elements should use short parameter names when the parameter container or type carries meaning.
Example: If the name of the class is "Building", an attribute should not be named "buildingName", only "name".
Recommendation 10: Names of UML elements should combine multiple words as needed to form precise and understandable names without using any intervening characters (such as “_”, “-”or space).
Recommendation 11: For UML attributes and operation names, association roles and parameters, capitalize only the first letter of each word after the first word that is combined in a name. Capitalize the first letter of the first word for each name of a classifier, package, type specification and association names.
In other words: Lower camel case (camelCase) for attributes, operations, roles and parameters, Upper camel case (CamelCase) for packages, classes and associations.
Example: A class may be named TransportLink, and have attributes validFrom and validTo.
Recommendation 13: UML elements should keep names as short as practical. Use standard abbreviations if understandable, skip prepositions and drop verbs when they do not significantly add to the meaning of the name.
ISO19109 has some requirements on how to handle names in multiple languages. Packages with application schemas shall always have a tagged value with the primary language:
/req/multi-lingual/package: A PACKAGE containing an application schema shall use a TAGGED VALUE "language" to indicate the primary language used for names and definitions in the application schema. The TAGGED VALUE shall use a value taken from IETF RFC 5646.
A PACKAGE shall use a TAGGED VALUE "designation" to contain the name of the PACKAGE in an alternative language to the primary language.
The TAGGED VALUE may be repeated for multiple languages. The value shall be formatted according to the pattern:
“{Name}”@{language}
Where {Name} is the name in a desired language, and {language} is its language code, taken from IETF RFC 5646.
EXAMPLE “Observations et Mesures”@fr
Feature types, attributes, roles and operations may use tagged values for the name in alternative languages:
/req/multi-lingual/feature: A FeatureType or PropertyType shall use a TAGGED VALUE "designation" to record its name in an alternative language to the primary language.
A FeatureType or PropertyType shall use a TAGGED VALUE “definition” to record its textual definition in an alternative language to the primary language.
The TAGGED VALUEs “designation”, “definition” and “description” may be repeated for multiple languages.
The value of these TAGGED VALUEs shall be formatted according to the pattern:
“{Name}”@{language}
Where {Name} is the name in a desired language, and {language} is its language code, taken from IETF RFC 5646.
Example: "Committee"@en
Even though names of model elements shall be "precise and understandable technical names for classifiers", the fact that they shall not contain spaces and special characters often forces them to be different from real world names. For example, a transport link class will be "TransportLink", and functional road class will be "FunctionalRoadClass". For human readability, it may be good to have a real world name as an alias in addition.
There are no rules or recommendations in the ISO19100 standards for the use of aliases. In Enterprise Architect, the field "alias" in Classes, attributes and associations may be used for this purpose. If there is a need for several alias, a tagged value may be applied (for instance a tagged value named "alias").