Unified Modeling Language (UML) Element Conventions¶

Packages¶

Before creating a package, search for intended package name and add a prefix if the package already exists.
Create a package that is peer (sibling) to the IEC packages, e.g., MyPackage.
Create a class within that package called MyPackageCIMVersion and copy date and version attributes from IEC61970CIMVersion into it and update the values to fit your context.
If there are a large number of class extensions, create sub-packages within MyPackage.
Document each package with a sentence or two.

Before creating a class, search for the intended class name and add a prefix to the extension if a class already exists.
Class names start with upper case and should not end with 's'.
Document the purpose of the class.
Use TagValues or Stereotypes: enumeration, Datatype or Compound (you should not be defining other Primitive types than standard ones).
Stereotyped classes are types that never participate in relationships (i.e., no associations, no inheritance), but are used as types for attributes.
Datatype may have attributes whose types are Primitive or enumeration (example: IEC61970::Domain::ActivePower).
Compound may have attributes whose types are Primitive, enumeration, Datatype or Compound (example: IEC61968::Common::StreetAddress).
Never use association class (too exotic UML feature, poor tool support).

Attribute names start with lower case and should not end with 's'.
Document the purpose of the attribute.
Change default multiplicity - all attributes in CIM are optional.
Set default Private visibility to Public - all attributes in CIM are public.
When choosing type, ensure you select it from the list of types. Attention on Primitives: use CIM Primitive datatypes (e.g., String, Boolean), not default UML ones (string, boolean).
Inherent dependency between the attribute's type and the class owning the attribute is uni-directional: Class knows about the attribute's type, but not vice versa.

Important: draw the association from your extension class towards a standard CIM class and never vice versa.
Ensure you specify multiplicity for both association ends ([1], [0..1], [1..] or [0..]).
Ensure both ends have navigability 'unspecified'.
Give names starting with upper case to both association ends; if multiplicity ends with * (i.e., more than one), append 's' to that association end name.
Document the purpose of each association end (avoid "A is related to one or more B" - UML shows it already).
For WG14: avoid aggregation (we currently have none); for WG13: aggregation has special meaning in the context of naming hierarchy for PowerSystemResources.
Inherent dependency between the two classes participating in association is bi-directional: Both classes know about each other.
Minimize associations from extension classes to high-level standard CIM classes - try to add association between your extension classes that derive from standard CIM classes.

Stereotyped classes never participate in inheritance.
CIM does not allow multiple inheritance.
Existing standard CIM classes can be used as supertypes for your extension classes, never vice versa.
Inheritance is the strongest possible dependency; it is often misused and should be used with care (note: everything that can be expressed through inheritance could also be expressed through composition).
No UML tool currently draws dependencies automatically (although they could).
UML tools sometimes use explicit dependency relationship in strange ways during model merges, therefore the importance of what are source and target ends.
IEC61970 (base CIM) must NOT depend on anything.
IEC61968 depends on IEC61970 and nothing else.
Important: draw the dependency from your extension package(s) towards standard CIM package(s) and never vice versa.
Currently, top-level packages other than those starting with IEC are obsolete - do not use classes from them, as they will be replaced with a package of WG16.