Modeling Concepts¶
This section is a technical introduction to the DEXPI Information Model.
Unified Modeling Language (UML)¶
The DEXPI Information Model is a class model in terms of the Unified Modeling Language (UML). Here, we give an informal overview on the UML concepts used in this specification and on their graphical notation.
Types and Instances¶
A type specifies a set of allowed values known as the instances of the type [UML:7.5.3.1].
The graphical notation of all types used in DEXPI is a rectangle with the type’s name in bold face. Depending on the type, the rectangle may contain additional information. An instance is represented by a rectangle with an underlined string that is composed of the instance’s name (if any) and the name of the instance’s type, separated by a colon. Depending on the type of the instance, additional information may be shown.
In DEXPI, two kinds of types are used: data types and classes.
Data types¶
A data type differs from a class in that instances of a data type are identified only by their value. All instances of a data type with the same value are considered to be equal instances [UML:10.2.3.1].
-
An enumeration is a data type that is specified by a list of its values [UML:10.2.3.3]. These values are called (enumeration) literals. They are identified by a name which must be unique within an enumeration.
The graphical notation for an enumeration contains contains the keyword
<<enumeration>>in the name compartment. There is a separate compartment with the names of the enumeration’s literals. -
A primitive type does not have any substructure (i.e., attributes). Its meaning is defined outside UML [UML:10.2.3.2].
The graphical notation of a primitive data type contains the keyword
<<primitive>>. The notation for an instance includes a suitable representation of its value, e.g., a literal.Example
The diagram shows the primitive type Double, a type for floating point numbers, and two instances: an anonymous instance with value 1.23 and an instance with name PI and value 3.14159.
-
There are further data types in DEXPI that are not primitive types or enumerations. They are either abstract base classes that implement nullable types, or they are structured data types, i.e., they have attributes.
The graphical notation for these data types also contains the keyword
<<dataType>>, and it has a compartment for the data type’s attributes, if applicable.
Classes¶
The purpose of a class is to specify a classification of objects and to specify [their] features [UML:10.4.1]. As the only features used in this specification are attributes, classes are similar to structured data types. However, the identity of values of classes (which are conventionally called objects) is handled differently: two objects that belong to the same class and that have equal attribute values (e.g, two instances of Nozzle, both with the SubTagName N1 and no value for all other attributes of Nozzle) are not identical.
Example
Burner is a class with an attribute DesignPower. The value of this attribute for the instance burner1 is power1, i.e., a Power of 100 kW.
Packages and Models¶
A package is a namespace for its members [UML:12.2.3.1]. In DEXPI, we use packages as containers for related elements in order to structure the information model. The DEXPI Information Model consists of 11 packages. Some of them cover basic data types (e.g., DataTypes and PhysicalQuantities) while others contain classes to describe various aspects of a P&ID (e.g., Equipment, Piping, and Instrumentation). The package DexpiModel provides the class DexpiModel, the root of the DEXPI composition-hierarchy.
A model is a special kind of package that describes an entire system [UML:12.2.3.11]. Thus, the DEXPI Information Model itself is a model in terms of UML. The system that it describes is the engineering and layout information in P&IDs.
Note that the names of all DEXPI data types and classes are unique. In consequence, data types and classes can be identified by their name, and it is not required to give a package name.
Example
There is only one class with name Tank. It is not required to give the name of the owning package (Equipment::Tank) or even to give a fully qualified name (Dexpi::Equipment::Tank) in order to identify the class.
Technical Note
Apart from the case described above, element names in DEXPI are not guaranteed to be unique if the named elements [UML:7.4.3.2] are owned by different name spaces [UML:7.4.3.1]. For example,
both the class Pump and the class Compressor have an attribute called
DesignVolumeFlowRate;all enumerations in the Enumerations have an enumeration literal called
NULL.
Patterns¶
Null Values¶
For several data types, the DEXPI Information Model defines an explicit null value.
Example
The data type NullablePower has two subtypes: Power is used to give an actual value with a mandatory numerical Value and a mandatory Unit. NullPower is the type of the null value NULL_POWER.
A null value for a data attribute indicates that in a certain information base (e.g., the information available in a P&ID tool) the attribute is known (“declared”), but no value is available.
In contrast, no value for a data attribute indicates that in a certain information base, the attribute is not known (“not declared”) - and in consequence, no value is available.
Example
The class Burner has a data attribute DesignPower. The type of the attribute is NullablePower.
If an exporting tool supports the attribute (e.g., because the tool has been configured accordingly) and a value for the attribute is known (e.g., because the user has entered a value), the DEXPI export should contain the known value.
If an exporting tool supports the attribute, but no value for the attribute is known (e.g., because the user has never entered a value), the DEXPI export should contain the null value.
If an exporting tool does not support the attribute (e.g., because the tool has not been configured accordingly), the DEXPI export should contain no value.