|Help TOC > PLCS technical description > Templates|
|Templates||Date: 2010/02/10 16:32:29
A Capability provides usage guidance on how the ISO 10303-239 PLCS information model should be used to represent a particular set of concepts, such as parts or properties. The Templates have been defined to provide more precision to this usage guidance. They specify the exact instantiation of a collection of entities and attribute values, and external Reference Data required to represent a particular concept described within a Capability. It is an unambiguous specification of how to use a collection of ISO 10303-239 PLCS entities, attributes and reference data for a certain purpose within the context defined by a capability, thus ensuring consistent interpretation of use.
Each Capability may define more than one Template, each covering a different aspect of that Capability. An example of this is the Capability C032: representing_activity (NB Capabilities are not documented in this release of the PLCS standard) which contains a number of templates such as: assigning_activity, representing_typical_activity and representing_planned_activity.
See section Capability for details on capabilities.Definition: A Template is a precise specification of which entities (and attributes) in ISO 10303-239 PLCS should be instantiated, and which Reference Data should be used, to represent a concept providing documented functionality in a Capability. A Template defined and managed by the OASIS PLCS TC may be referred to as a "PLCS Template", as opposed to a "Business Template"
It is a "template for instantiation", which can be applied once, or several times - in a sense a partial instantiation of ISO 10303-239 PLCS; partial in that it makes explicit the instantiation of entities and specific attributes, but not all.
An example of a template is given in Figure 1.
A Template is explicitly defined to realize functionality expressed within a Capability (or Business Context ). The Capability documents the concepts and information necessary to understand their differences, dependencies and how each may be characterized for typical usage circumstances. The Templates define such usage as an explicit instantiation (or arrangement) of PLCS entities providing the typical usage context through external Reference Data. Templates are designed to be used (and extended - where relevant) by other Templates which may reside in other Capabilities; hence a Template may be used across others, e.g. the Template assigning_reference_data is used in most other Templates (assigning classification data is a fundamental part of ISO 10303-239 PLCS in OASIS). Here are some examples of Templates in OASIS PLCS:
A Template represents a named abstraction of a grouping of ISO 10303-239 entities that are to be instantiated in order to represent the concept. A Template is analogous to a procedure in procedural programming languages.
The Template will define:
This will be represented both graphically by a model diagram showing the exact entities and attribute values instantiated, and textually via a formal specification of the instantiation (through the instantiation path, a syntactical definition of the exact steps of instantiation).
Each DEX will specify the set of templates that required to represent the information represented by the DEX. The EXPRESS schema of a DEX is then built from the referenced Templates' instantiation paths, complemented by any additional entities the DEX has used directly.
Most templates belong to one of three basic types:
For each Template, there is a status shown on the front page of the Template in DEXlib, The status can be either of:
The statuses described are further explained on the pages describing the "Template development process".
An example of how a Template works can be made by looking at the Capability "assigning_reference_data", which represents the assignment of a class to something. The EXPRESS-G model diagram showing the entities that are to be instantiated are shown in Figure 2. A pattern like this is used throughout ISO 10303-239 to assign Reference Data. Therefor a number of EXPRESS-G and instance diagrams will have to repeat this pattern again and again, which will lead to complex and cluttered diagrams. Consequently a Template can be created that provides an abbreviation for this pattern. This is what is called a Template.
As well as specifying the group of entities to be instantiated, the Template can also specify values for the entity attributes. These values may be mandatory, in other words the attribute always has a given value, or may be specified when the Template is used. For example, the External_class_library description attribute shall always be set to '/IGNORE' wherever it is used. The Class name attribute however may be specified when the Template is used. For example, when identifying a part number Reference Data is assigned to an Identification_assignment entity and the Class name attribute is set of 'Part_identification_code'. The values are set on the attributes by defining parameters on the Template, which are set when the Template is used. This is analogous to arguments in procedures in procedural programming languages.
There may be situations in which it is necessary to assign an entity to an entity defined in the Template. For example, the Template "assigning_identification" specifies that the entity Identification_assignment should be instantiated to assign the identifier. There are cases when a date should be assigned to the Identification_assignment entity. For example to represent when the identifier was assigned. A Template can therefore have a reference parameter which is used to mark a particular entity in a Template as being referenceable from outside the Template. This is analogous to a global variable in procedural programming languages.
A Template can be used in an information model (EXPRESS-G diagram) to show a named abstraction of EXPRESS entities to be instantiated, (See Figure 3 and Figure 4 for an example) and can be used in an instance diagram to show an example of a Template being used (See Figure 6 for an example).
The graphical representation of a Template used in a DEX information model includes:
As the graphic for the Template may be large, a miniaturised symbol can be used for the Template. This comprises:
An example of the graphical form for Templates for use in a model diagram is shown in Figure 3.
The diagram shows an EXPRESS-G diagram representing the entities to be instantiated to assign an organization. The diagram shows a number of Templates that are assigning entities. For example, the mandatory Template "assigning_reference_data" is assigning to the entity "Organization_or_person_in_organization_assignment". The optional Template "assigning_calendar_date" is assigning a date to the same entity.
The diagram also shows the Organization and Organization_or_person_in_organization_assignment entities being being marked as reference parameters (^organization and ^organization_assgn respectively) that can be referenced from outside the Template. An example of the reference parameters being assigned to is given below in Figure 5.
The same example using miniaturised Templates is shown in Figure 4.
An example showing the assignment of an entity to an entity "in" the Template is given in Figure 5 below. The Template "assigning_calendar_date" is being assigned to the reference parameter ^organization_assgn on the "assigning_organization" Template. The reference parameter ^organization_assgn is bound to the Organization_or_person_in_organization_assignment entity in the "assigning_organization" Template.
Instance diagrams show example instantiations of the model, i.e. instances of entities. The diagrams have been extended to include a graphic representing the Template showing the instantiation of the Template. It includes:
As the graphic for the instantiated Template may be large, a miniaturised symbol can be used for the Template. This comprises:
Where miniaturised Templates are used, there may be a table below the instance diagram showing the values of the parameters used.
An example of the graphical form for Templates for use in an instance diagram is shown in Figure 6. The figure shows an instance diagram showing the entities instantiated to represent an organization owning a bicycle. The 'BikeHire Limited' organization is assigned to a bicycle (represented as a Product_as_realized) in the role of "Owner_of". The diagram shows two instantiated Templates. @1 assigning_classified_identification and @16 assigning_reference_data.
The following templates are instantiated in the diagram:
Templates are defined within a capability. This section describes the various section in the Template definition.
Each Template has a name, a description, a set of restrictions, a set of input and reference parameters and an instantiation path, where the instantiation path defines the EXPRESS entities that are to be instantiated. The Template also includes Model diagrams and Instance diagrams.
The name provides an identifier for the Template that is unique to DEXlib.
The description of the Template is a free text description of the purpose of the Templates.
The Template restrictions describe any constraints on the usage of the Template. E.g. State when the Template should not be used.
Each Template will define a set of input parameters. These allow values to be passed to the Template when used in an instantiation path. The values can then be set to attributes in entities specified in the instantiation path.
Input parameters are passed into the Template and their use in the path is indicated by @<param name>.
Each parameter may be marked as optional, indicating whether a value must be provided for the parameter.
A default value may be provided for the parameter.
The type of the parameter value may be specified as follows:
NOTE Where the type is a class, then a possible set of classes can be identified. These may the super classes i.e. the class and its sub classes are valid values, or an individual class, in which case just the individual class is valid.
EXPRESS entities specified in the instantiation path can be bound to reference parameters. The reference parameter can then be used elsewhere in the instantiation path, in effect providing local variables.
The binding of an entity in a instantiation path to a reference parameter is done by enclosing the reference parameter, marked by ^ and the entity in %%. For example the entity External_class, can be bound to the reference parameter ^ext_class as follows:
%^ext_class = External_class%
The External_class can then be used elsewhere in the path by the use of ^ext_class.
If these entities are to be referenced when the Template is used in the instantiation path of another Template, then they are declared in the Template heading as reference parameters.
There are some circumstances where a combination of attribute values can be used to uniquely identify an instance of an EXPRESS entity in a given data set. These circumstances are normatively declared by a uniqueness constraint.
There two ways in which the constraint can be defined. An entity can be identified by stating the fixed values of a set of attributes, or an entity can be identified by the values of the Template input parameters.
An example of a constraint based on the fixed values of a set of attributes is where is a requirement that any data set only contains one instance of the entity Product_category with the attribute name="Part". This would be defined by the following unique constraint:
Unique constraint: Unique product_category
There shall be at most one instance of the entity (Product_category) with the attribute (name="Part") instantiated in the data set.
An example of a constraint based on the parameter values of a Template is where a Template instantiates a View_definition_context. This shown in in Figure 8.
The Life cycle stage and application domain of the View_definition_context are then provided by assigning Reference Data. The values for the Reference Data are provided by the Template parameters: domain, domain_ecl_id, life_cycle_stage, life_cycle_stage_ecl_id. In any given dataset, there should only be one instance of a View_definition_context that has been classified with those parameter values. This would be defined by the following unique constraint:
Unique constraint: Unique view_definition_context
There shall be at most one instance of the entity (View_definition_context) within the data set uniquely identified by a combination of the following Template parameters: domain, domain_ecl_id, life_cycle_stage, life_cycle_stage_ecl_id. The instance is referenced by the following Template parameter: contxt.
The instantiation path defines the set of entities that are to be instantiated by the Template. It specifies:
for invocation is the name of the Template, plus the parameters. When using
the Template in a instantiation path, the signature is enclosed
in //. E.g.
/assigning_reference_data (items=^this, class_name=@date_class_name, ecl_id=@date_ecl_id)/
NOTE comments are on one line and prefixed by --, where the comment is terminated by the end of that line.
The instantiation path is derived from the ISO 10303 SC4 reference path syntax (SC4 Document: QCN241) so must follow an EXPRESS instantiation.
The instantiation path may invoke other Templates.
The following notational conventions apply for the definition of instantiation paths:
|||||enclosed section constrains the supertype entity;|
|->||the attribute, whose name precedes the -> symbol, references the entity or select type whose name follows the -> symbol;|
|<-||the entity or select type, whose name precedes the <- symbol, is referenced by the entity attribute whose name follows the <- symbol;|
|[i]||the attribute, whose name precedes the [i] symbol, is an aggregate; any element of that aggregate is referred to;|
|[n]||the attribute, whose name precedes the [n] symbol, is an ordered aggregate; member n of that aggregate is referred to;|
|=>||the entity, whose name precedes the => symbol, is a supertype of the entity whose name follows the => symbol;|
|<=||the entity, whose name precedes the <= symbol, is a subtype of the entity whose name follows the <= symbol;|
|=||the string, select, or enumeration type is constrained to a choice or value;|
|\||the instantiation path expression continues on the next line;|
|--||the text following is a comment;|
Enclosed section invokes a Template. The word following the
/ is the name of the Template. The parameters to the Template are name
value pairs defined in () . E.g.
The text following the @ is the name of a parameter that has been passed into the Template. E.g.
Enclosed section specifies that the entity is bound to a parameter,
indicated by ^, that can be referenced from outside the Template. E.g.
|^||The text following the ^ is the name of a reference parameter that can be referenced from outside the Template.|
The text following the $ identifies a reference parameter
in the preceding Template call. The syntax is
<template_name> is the name of the Template and
<reference_parameter> is the name of a reference parameter for that Template. E.g.
The Template assigning_organization has a reference parameter ^organization_assgn. This is identified by $assigning_organization.organization_assgn and has been bound to the local reference parameter ^org_assgn.
Table 1 — Instantiation path syntax
Figure 6 shows a Template assigning_organization. The Template has 5 input parameters:
These are shown in the diagram in bold blue italic text. The digram also shows how the parameters are used to set values on the instantiated entities.
The Template has two reference parameters:
The reference parameters are shown in the diagram in bold blue text prefixed by a ^.
The Template path for the assigning_organization Template shown above in Figure 9, is as below. The comments (lines starting with --) describes each line.
-- Instantiate an Organization -- NOTE - an organization entity should only be instantiated once for -- any organization Organization -- Bind the Organization to the parameter ^organization. -- The parameter is a reference parameter so the Organization -- entity can be referred to when this Template is used. %^organization = Organization% -- Set the Organization attributes id and name to be ignored Organization.id = '/IGNORE' Organization.name = '/IGNORE' -- Identify the Organization /assigning_classified_identification(items=^organization, id=@org_id, id_class_name=@org_id_class_name, id_ecl_id=@org_id_ecl_id)/ -- Instantiate an Organization_or_person_in_organization_assignment Organization_or_person_in_organization_assignment -- Bind the Organization_or_person_in_organization_assignment -- to the parameter ^organization_assgn -- The parameter is a reference parameter so the -- Organization_or_person_in_organization_assignment entity can be -- referred to when this Template is used. %^organization_assgn = Organization_or_person_in_organization_assignment% -- Set the Organization_or_person_in_organization_assignment -- role attribute to be ignored Organization_or_person_in_organization_assignment.role = '/IGNORE' -- Assign the organization to the -- Organization_or_person_in_organization_assignment Organization_or_person_in_organization_assignment.assigned_entity -> ^organization -- classify the Organization_or_person_in_organization_assignment /assigning_reference_data(items=^organization_assgn, class_name=@org_assgn_class_name, ecl_id=@org_assgn_ecl_id)/ -- Assign the Organization_or_person_in_organization_assignment.items -- to the instances passed into the Template through the @items -- input parameter Organization_or_person_in_organization_assignment.items -> @items