Note: To translate this paper into over 50 languages, please see the Automatic translation option at the top of the screen

Annex A  Extending the model

109.     One of the GSIM design principles is that GSIM can easily be adapted and extended to meet users' needs. It is expected that some implementers may wish to extend GSIM, by adding detail and indicating which information objects are used, and exactly how.

110.     Examples of when this could be needed are:

(a)    A statistical organization wants to specify types of Rules (for example, Methodological Rules and Process Control Rules)
(b)   A statistical organization wants to add another specialization of Instrument

111.     Note that there are many points in GSIM where additional detail is expected to be added. These extensions can be done using the modelling techniques which GSIM itself uses. The following guidelines are intended to help modellers employ a common technique when extending and implementing the conceptual model, so that the use of GSIM itself within specific organizations is done in a common and understandable fashion.

112.     For people who have experience in modelling with the standard UML tools, the recommended technique should be straightforward. However, not all staff have this experience. For those with less familiarity, a 'metamodel template' is also provided which allows non-modellers to capture the same information in a form that relies on plain text.

A. GSIM Extension Methodology

Namespaces

113.As part of the GSIM v1.0 release, the Enterprise Architect file which contains the UML models will be released. In this file there are five 'namespaces' (or 'packages') – one for each of the GSIM Groups.

114.     Any organization extending GSIM should establish one or more namespaces which are specific to and owned/maintained by that organization. This provides a clean separation between GSIM itself, and the extensions that have been made to it.

115.     In many cases, the extensions might provide useful input to future development of GSIM itself, so should be made available to the maintenance agency (UNECE Standards Steering Group). In other cases, they may be too organization-specific for this purpose.

116.     The classes native to GSIM would be imported into the organization-specific namespace(s), and extensions made from them. Any new information objects would also be modelled in this namespace. In the same way that GSIM itself is organized into namespaces, it is recommended that if more than one organization-specific namespace is created by the extender, these should be organized along similar lines.  
New Classes

117.     New classes may be created using the same style of modelling as is found in GSIM itself. GSIM uses a fairly standard but restricted set of the features of UML. The best guide to this style is to study the GSIM UML models. Such things as multiple inheritances have been avoided, and there is a distinct style in terms of how relationship roles are named.  

Extensions/restrictions to existing classes

118.     Any class within GSIM can be imported and then extended/restricted. Classes can be extended with new properties and relationships, and the existing properties and relationships can be over-ridden.

119.     The extended classes inherit all properties and relationships from their parents, so these do not need to be explicitly modelled unless:

(a)    they are required for clearer understanding (they will appear proceeded by a slash ["/"]); or

(b)   they have been changed - that is, over-ridden.

120.     Extension and restriction in the UML models are shown with an open-headed arrow pointing from the extending/restricting class to the class that it inherits from, and of which it is a sub-type. The details of what is allowed are provided below:
 

Extension of existing classes:

121.     Create a new sub-type, with its own name, a definition, explanatory text, and examples, and then specify any additional type-specific additions to the set of properties or relationships which that information object possesses.

122.     Note: There are some common attributes, which exist for all GSIM information objects, and these will be present by inheritance. The same is true for administrative attributes added to the GSIM Base Administrative Details information object.
 

Restriction of classes:

123.     The information object to be restricted is imported into the organization-specific namespace and then sub-classed. Any existing relationships or properties may be over-ridden, unless they are required by the inherited cardinalities. This is done by simply re-stating the property or relationship, and changing its details.  Even within required cardinalities, so long as a restriction still produces a valid instance of its parent, the change is allowed. For example, a property with a cardinality of 1..* may be restricted to having a cardinality of 1, but not less than that, since at least one instance of that property is required.

124.     Note: If a class in GSIM is to be both extended and restricted, the same sub-type is used, with over-rides and additions made as desired.

125.     It is possible, using this mechanism, to express exactly what information objects within an organization are used and not used. If there is no relationship to an information object, or if its cardinality has been reduced to 0 for all properties and relationships, it is simply not used.  

Documentation

126.     GSIM itself should be used as an example of how to document extensions and restrictions. This means providing the information in the metamodel template (see below) and providing the definitions and descriptions/examples in tabular form, as well as providing an overall narrative of each UML diagram produced.
 

B. Administrative Attributes

127.     GSIM does not model the information used by statistical organizations to administer and maintain their metadata - there are too many potential differences. Such administrative attributes are also very dependent on implementation, and GSIM is a conceptual model.

128.     To support the use of administrative attributes, GSIM provides an information object - Administrative Details - which can be extended to include whatever set of administrative attributes are needed by an implementer of the GSIM.

129.     In order, to encourage commonality of practice, GSIM recommends a set of administrative attributes based on the ISO/IEC 11179 standard. The following table shows the set of recommended attributes for the administration of GSIM information objects.

Table 2. Recommended Attributes

130.     Implementers can use the GSIM extension methodology to include the recommended set of administrative attributes. The Administrative Details information object in GSIM has been purposefully left blank as a stub to be extended.

131.     In this case, all that is needed is to create a namespace and to import the Administrative Details information object into it. The Administrative Details information object is then sub-classed, and the attributes listed above are added. Figure 23 shows what would appear in a UML diagram if this is done. 

Figure 23. Extension of Administrative Details.

Note: The fields containing controlled vocabularies are shown in the diagram as text. These text strings would agree with a maintained list appropriate to the field which uses them.