Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

140.     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.

141.     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

142.     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.

143.     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.

Anchor
Specification_IVExtendingthemodel-
Specification_IVExtendingthemodel-

Anchor
_Toc343867686
_Toc343867686
Anchor
_Toc375075495
_Toc375075495
A. GSIM Extension Methodology


Namespaces

144.As part of the GSIM v1.1 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.

145.     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.

146.     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 Modernisation Committee). In other cases, they may be too organization-specific for this purpose.

147.     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

148.     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

149.     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.

150.     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.

151.     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:

152.     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.

153.     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:

154.     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.

155.     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.

156.     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

157.     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.

Box 1. Metamodel Template

Information Object Name
Version:
Package:
Definition:
Explanatory Text:
Synonyms:
Constraints:

Attributes

Name

Description

Cardinality

Value Type

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

...


158.     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.

159.     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.

160.     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.

Anchor
_Toc343869352
_Toc343869352
Table 3. Recommended Attributes

Name

Description

Mandatory

Value Domain

Identification attributes

 

 

 

Name

A term which designates a concept, in this case an information object. The identifying name will be the preferred designation. There will be many terms to designate the same information object, such as synonyms and terms in other languages.

Yes

Text

ID

The unique identifier of the information object; assigned by the owner agency.

Yes

Number

Governance attributes

 

 

 

Version

The version designator of the information object assigned by the owner agency.

Yes

Number

Owner Agency

The organization or legal entity that owns and maintains the information object.

Yes

Text

Organization Unit

The organization unit, within an agency, which owns (has rights to create, update, delete) the information object.

No

Controlled vocabulary

Valid From

The date on which the information object is effective or valid.

Yes

Date

Valid Until

The date on which the information object is no longer effective or valid.

Yes

Date

Created Date

The date on which the information object was created

Yes

Date

Created User Id

The person who created the information object

Yes

Controlled vocabulary

Last Update Date

The date on which the information object was last changed.

No

Date

Last Update User Id

The person who last changed the information object.

No

Controlled vocabulary

Administrative status

indicator for access to an item: under review, open for use, or removed

No

Controlled vocabulary

Life cycle status

indicator for the quality of an item: incomplete, valid, superseded, or retired

No

Controlled vocabulary

Content attributes

 

 

 

Description

A statement which describes an information object. It also delineates the information object's scope.

Yes

Text

Annotation

A comment or instruction which provides additional explanations about the information object and how to use it.

No

Text

Topic

The subject or theme the information object is related to. This is included to support search.

No

Controlled vocabulary

Keyword

Terms related to the information object. These are included to support search.

No

Controlled vocabulary

Technical implementation attribute

 

 

 

IsStructured

Identifies if the description can be executed by a machine.

No

Boolean

 

161.     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.

162.     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. 


Anchor
_Toc343867814
_Toc343867814
Anchor
_Toc343869397
_Toc343869397
Figure 1. 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.

...