An interface definition is a named collection of property definitions. Every interface definition is realized by one or more class definitions. Interface definitions expose the property definitions for class definitions. By sharing specific interface definitions, class definitions can also share property definitions, but not the data associated with the properties.
Interface Definitions as Roles
An interface definition represents a role for a class definition. The role defines both the properties and relationships of an object. Some interface definitions are defined to carry properties, and some are defined to carry relationships. Others may be defined merely to indicate a role.
Different class definitions can share the same interface definitions and, therefore, the same role. For example, every class definition in the schema shares the IObject interface, which means that every class definition in the schema has the role of an object. When a class definition has this role, it has an object name, an object description, an object identifier, and any other property definitions exposed by the IObject interface.
However, class definitions that share the IObject interface also realize other interface definitions that define other roles for them. These interface definitions expose other property definitions for the objects.
IObject
Every persistent object must be identified by a unique identifier (UID) which is a property on the IObject interface for that object.
Every relationship and relationship definition has a property UID1 that identifies the UID of the object at end 1 of the relationship and a second property UID2 that identifies the object at end 2 of the relationship.
The description of an interface definition includes its properties, methods and relationships. Since any interface definition is a potential end for a relationship or relationship definition, the extended definition of an interface, which includes the interface definitions directly or indirectly implied by that interface definition, must include IObject. Therefore, every interface definition must directly or indirectly Imply IObject.
For every interface definition that doesn't directly or indirectly imply IObject, an error will be reported during validation.
Interface Definitions and Relationships
Interface definitions define the relationships in which an object participates. There are no relationships between class definitions, only between interface definitions. That is because only the interface definitions are exposed to the outside world. The underlying reason for modeling class definitions and interface definitions instead of class definitions and relationships is because of the complexity of the relationships that can be formed.
In a traditional class data model, relationships go directly from one class definition to another. When the class hierarchy gets moderately deep, however, the relationships become very hard to understand. The consequence is that the modeler moves the relationships up in the hierarchy, which causes ambiguity in defining just what the relationship represents. By grouping similar characteristics together and exposing them as an abstract entity called an interface definition, it is easier to maintain precision in the relationships.
There are two relationships defined between class definitions and interface definitions:
-
Realizes relationship
-
Primary Interface relationship
Realizes Relationship
The first and most common relationship between class definitions and interface definitions is the Realizes relationship. A class definition Realizes an interface definition. The Realizes relationship may be required or optional. If it is required, the Schema Component will require that an instance of that class definition realize an instance of the required interface definition.
Primary Interface Relationship
The second relationship defined between class definitions and interface definitions is the Primary Interface relationship. The primary interface definition defines the set of possible roles for a class definition and should imply everything that is known about that class definition. Primary interface definitions, rather than class definitions, actually define the objects in the schema. Class definitions fulfill a subset of the roles defined by the primary interface definition.
The most important purpose for the primary interface definition is to define the complete set of roles for an object. It defines what an object is and everything that is known about it. For example, the IEquipmentOcc interface definition defines what a piece of equipment is in the schema, and IInstrumentOcc defines what an instrument is.
A class definition does not necessarily include all the roles of the primary interface definition because the class definition is the view that a single authoring tool or component schema has of that object. For instance, PIDProcessEquipment does not realize all the interface definitions in the implies hierarchy for IEquipmentOcc because Smart P&ID does not manage all those interfaces, properties, and relationships, only a subset of them.
This complete set of roles for a class definition, defined by the primary interface, is used in several ways in an integrated environment:
-
Validation - Class definitions may not realize any interface definition outside of the implies hierarchy of the primary interface definition.
-
Sharing - Class definitions that are shared must have the same primary interface definition or must imply the same primary interface definition. For example, PFDProcessEquipment and PIDProcessEquipment have the same primary interface definition and are defined as shared. EQDReactorVessel does not have the same primary interface definition, but it does imply the same primary interface definition (IReactorVesselOcc implies IEquipmentOcc). Therefore, EQDReactorVessel is defined as shared with PFDProcessEquipment and PIDProcessEquipment.
-
Mapping - You can map the SmartPlant schema to an authoring tool schema using class definitions. However, you might end up mapping the same interfaces and properties over and over. For example, if your application retrieved equipment tags, you would want to retrieve PFD, P&ID, and EQD. To map by class definition, you would end up mapping to PFDProcessEquipment, PIDProcessEquipment, and dozens of EQD* class definitions. If you map to the primary interface definition for these class definitions (IEquipmentOcc), you only have to map to it once, and you can retrieve any object that realizes that interface definition.
-
The primary interface is used for schema modeling; it bears no relation to instantiation in SmartPlant Foundation. Only Realizes relationships are instantiated in SmartPlant Foundation.
-
An interface must be realized to be used on a form in SmartPlant Foundation.
-
In the SmartPlant schema, primary interfaces typically end in "Occ".
Implies Relationship
The definition of an object is completed through Implies relationships between interface definitions. When you consider the complete hierarchy of Implies relationships for the primary interface definition that a class definition realizes, you know everything about that object in an integrated environment.
If an interface definition implies another interface definition, then any class definition that realizes the first interface definition can also realize the implied interface definition. For example, IEquipmentOcc implies the IDrawingItem. Therefore, any class definition, such as PIDProcessEquipment, that realizes IEquipmentOcc can also realize ISolidItem. If an Implies relationship between two interface definitions is required, then all class definitions that realize the first interface definition must also realize the second.
Properties Categories
The property category helps organize properties in the Properties window in SmartPlant Foundation. Property categories can be defined by the interface definition or edge definition. If no property definition is defined for the edge definition, properties across the edge definition are assigned a property category based on the property category defined for the interface definition that exposes the properties.
Special Handling for PropCategory Property Definition
Property Category is a special property definition in that it is a consolidated enumerated value in which the individual enumerated values are separated by semi-colons (;). When you create or edit an interface definition, select the Browse next to the Property category box. The Values for PropCategory dialog box allows you to define this property value.
Value - Displays enumerated values separated by the semi-colon delimiter for property value.
Unused enumerated values - Lists all the entries in the enumerated list that have not been used as part of the Property Category value
Used property values - Lists all the enumerated values that have been used as part of the Property Category value.
A number of options exist for editing the Property Category value:
-
The value can be keyed into the Value box.
-
Unused enumerated values can be selected and then by clicking Add inserted into the list of used enumerated values.
-
Used enumerated values can be selected and then by clicking Remove deleted from the list of used enumerated values
-
The order of the used enumerated values can be changed by selecting a value from this list control and then clicking Move Up or Move Down
In addition, this dialog box allows the addition of a new combination of values (or simply a new value) to the enumerated list by clicking the Add to List.
Interface Definitions in SmartPlant Foundation
In SmartPlant Foundation, interface definitions are used to define which methods are available and which workflows are appropriate for objects that realize the interface definition.