ISO/TS 18876-2:2003

TECHNICAL ISO/TS
SPECIFICATION 18876-2
First edition
2003-11-01
Industrial automation systems and
integration — Integration of industrial
data for exchange, access and sharing —
Part 2:
Integration and mapping methodology
Systèmes d'automatisation industrielle et intégration — Intégration des
données industrielles pour l'échange, l'accès et le partage —
Partie 2: Méthodologie d'intégration et de «mapping»

Reference number
©
ISO 2003
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.

©  ISO 2003
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2003 — All rights reserved

Contents Page
1 Scope . 1
2 Normative references . 2
3 Terms, definitions, and abbreviations . 2
3.1 Terms and definitions. 2
3.2 Abbreviations . 6
4 Usage scenarios . 6
4.1 Integrating application models . 6
4.2 Integrating application models with an integration model . 7
4.3 Defining an application model and its mapping to an integration model. 9
4.4 Integrating an application model with two or more integration models. 10
4.5 Improving an integration model . 11
5 Methods for integrating application models. 12
5.1 Analysis of the requirements. 13
5.1.1 Pre-conditions. 13
5.1.2 Method description . 13
5.1.3 Post-conditions . 15
5.2 Defining and extending the integration model .15
5.2.1 Pre-conditions. 16
5.2.2 Method description . 16
5.2.3 Post-conditions . 18
5.3 Identifying a subset of the integration model . 19
5.4 Mapping between the application model and the identified integration model subset. 19
5.4.1 Pre-conditions. 20
5.4.2 Method description . 21
5.4.3 Post-conditions . 22
Annex A (normative) Information object registration. 23
Annex B (informative) Description of the integration process. 24
Annex C (informative) Checklist for integration and mapping processes. 32
Annex D (informative) Technical discussions . 38
Bibliography. 41
Index. 43
Figures
Figure 1 — Creating an integration model that integrates two application models . 7
Figure 2 — Integrating an application model with an existing integration model . 8
Figure 3 — Creating an application model and its mapping to an integration model . 9
Figure 4 — Integrating an application model with more than one integration model. 10
Figure 5 — Improving an integration model. 11
Figure 6 — Alternative mappings to an improved integration model. 12
Figure 7 — Analysis of application model. 14
Figure 8 — Creating a new integration model . 17
Figure 9 — Extending the integration model . 17
Figure 10 — Identifying a subset of the integration model. 19
Figure 11 — Mapping between the application model and the integration model subset. 21
Figure B-1 — Integrate application model (A-0). 24
Figure B-2 — Integrate application model (A0) . 26
Figure B-3 — Analyze requirements (A1) . 27
Figure B-4 — Create/extend integration model (A2). 29
Figure B-5 — Map application model to integration model subset (A4).30
Figure D-1 — Relationship between a model and its subject. 38

iv © ISO 2003 – All rights reserved

Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO tech-
nical committees. Each member body interested in a subject for which a technical committee has been estab-
lished has the right to be represented on that committee. International organizations, governmental and non-
governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the International
Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an Interna-
tional Standard requires approval by at least 75 % of the member bodies casting a vote.
In other circumstances, particularly when there is an urgent market requirement for such documents, a technical
committee may decide to publish other types of normative document:
— an ISO Publicly Available Specification (ISO/PAS) represents an agreement between technical experts in
an ISO working group and is accepted for publication if it is approved by more than 50 % of the members
of the parent committee casting a vote;
— an ISO Technical Specification (ISO/TS) represents an agreement between the members of a technical
committee and is accepted for publication if it is approved by 2/3 of the members of the committee casting
a vote.
An ISO/PAS or ISO/TS is reviewed after three years in order to decide whether it will be confirmed for a fur-
ther three years, revised to become an International Standard, or withdrawn. If the ISO/PAS or ISO/TS is con-
firmed, it is reviewed again after a further three years, at which time it must either be transformed into an Inter-
national Standard or be withdrawn.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO/TS 18876-2 was prepared by Technical Committee ISO/TC 184, Industrial automation systems and inte-
gration, Subcommittee SC 4, Industrial data.
This Technical Specification is organized as a series of parts, each published separately. The structure of this
Technical Specification is described in ISO/TS 18876-1.
0 Introduction
0.1 Overview of ISO 18876
This Technical Specification establishes an architecture, a methodology, and other specifications for integrating
industrial data for exchange, access and sharing. It supports:
— data sharing and data integration;
— specification of mappings between models;
— data transformation.
ISO/TS 18876-1 provides an overview of the architecture and methodology of this Technical Specification.
0.2 Organization of this part of ISO 18876
The organization of this part of ISO 18876 is as follows:
— clause 1 specifies the scope and field of application of this part of ISO 18876;
— clause 2 identifies additional standards that, through references in this part of ISO 18876, constitute provi-
sions of this part of ISO 18876;
— clause 3 defines terms used in this part of ISO 18876;
— clause 4 describes a number of usage scenarios for the application of the methods defined in this part of
ISO 18876;
— clause 5 specifies the methods for integrating application models, and is supported by a detailed activity
model presented in Annex B.
The methods specified in clause 5 are independent of modelling languages, mapping languages, and particular
integration models. Annex C provides a checklist that can be used to ensure that all required stages in the inte-
gration and mapping process have been followed.
0.3 Target Audiences
The target audience for this document is modellers, analysts, systems integrators, and systems developers with a
need to integrate application models across a range of systems and/or enterprise functions. The target audience
for the introduction to this document is technical managers responsible for integration projects with a need to
assess the applicability of this standard.
0.4 Conventions
This part of ISO 18876 includes provisions that indicate requirements strictly to be followed in order to con-
form to the standard. Such provisions are indicated through the use of the words “shall” and “shall not”. This
part of ISO 18876 also includes provisions that indicate that among several possibilities one is recommended as
particularly suitable. Such provisions are indicated through the use of the words “should” and “should not”.
Additional material that illustrates the provisions of this part of ISO 18876 is presented in the form of notes,
examples, and in the informative annexes B, C, and D.

vi © ISO 2003 – All rights reserved

TECHNICAL SPECIFICATION ISO/TS 18876-2:2003(E)
Industrial automation systems and integration —
Integration of industrial data for exchange, access and
sharing —
Part 2:
Integration and mapping methodology
1 Scope
This Technical Specification establishes an architecture, a methodology, and other specifications for integrating
industrial data for exchange, access and sharing. Together these support the following activities:
— integrating data which may be:
— from different sources or with different model contexts,
— described by different models, or
— defined in different modelling languages;
— sharing data among applications through systems integration architectures;
— resolving conflict between models developed with different objectives;
— translating data between different encodings;
— translating models between different modelling languages.
This part of ISO 18876 specifies methods for the following:
— creating and extending integration models;
— evaluating and selecting an integration model that can integrate two or more application models;
— creating an application model that is a constrained subset of an integration model to support particular ap-
plication domain requirements for exchange, sharing, or both;
— creating a mapping specification between an application model and an integration model.
The following are within the scope of this part of ISO 18876:
— modelling language independent methods for creating and extending an integration model;
— methods for integrating an application model with an integration model;
— mapping language independent methods for mapping an application model to an integration model;
— criteria for the selecting modelling languages and mapping languages that can be used within the specified
methods for integration and mapping.
The following are outside the scope of this part of ISO 18876:
— the structure and content of particular integration models;
— methods for creating and extending particular integration models;
— methods for mapping application models to particular integration models.
NOTE The specific methods that apply to mappings between particular application models and integration models de-
pend on the modelling paradigm(s) applied and on the structure and content of the models.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated references,
only the edition cited applies. For undated references, the latest edition of the referenced document (including
any amendments) applies.
ISO/IEC 8824-1:1998, Information technology — Abstract Syntax Notation One (ASN.1): Specification of basic
notation
ISO 10303-1:1994, Industrial automation systems and integration — Product data representation and
exchange — Part 1: Overview and fundamental principles
ISO/TS 18876-1:2003, Industrial automation systems and integration — Integration of industrial data for exchange,
access and sharing — Part 1: Architecture overview and description
3 Terms, definitions, and abbreviations
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply; those taken or adapted
from ISO 10303-1 and ISO/TS 18876-1 are repeated below for convenience.
NOTE 1 Definitions copied verbatim from other standards are followed by a reference to the standard in brackets, such as
“[ISO 10303-1]”. In these cases the definition in the referenced document is normative; its repetition here is informative and
in the case of any discrepancy the definition in the referenced document has precedence. An explanatory note follows
definitions that have been adapted from other standards. In these cases the definition given here is normative for the pur-
poses of this part of ISO 18876.
3.1.1
application model (AM)
model that represents information used for some particular purpose
NOTE 1 Some application models are also integration models (see 3.1.15).
2 © ISO 2003 – All rights reserved

NOTE 2 An application model is not necessarily a data model, but may be a model of some other sort, such as a logic
based model.
[ISO/TS 18876-1]
3.1.2
class
category or division of things
NOTE There are a number of ways that class can be defined. This definition is intended to be as broad as possible, and
is broader than that used in ISO 15926-2.
EXAMPLE Pump, power station, engineer, and fictional space vehicle are examples of classes.
[ISO/TS 18876-1]
3.1.3
concept
internal conception of some thing; general notion or idea of some thing
[ISO/TS 18876-1]
3.1.4
construct
representation of a concept in some formal notation system
NOTE A construct may be a part or the whole of a data model.
3.1.5
data
representation of information in a formal manner suitable for communication, interpretation, or processing by
computers and possibly human beings
[ISO 10303-1]
3.1.6
data model
set of constructs that procvides the definition, structure, and format of data, whether physical or abstract in the
sense of being bound to some recording medium
[ISO/TS 18876-1]
3.1.7
derived concept
concept in an integration model that is wholly defined in terms of primitive concepts
[ISO/TS 18876-1]
3.1.8
encoding transformation
transformation of the way data elements are represented for computer processing
EXAMPLE Conversion of data governed by an EXPRESS schema from an ISO 10303-21 file to an XML document is an
example of an encoding transformation.
[ISO/TS 18876-1]
3.1.9
extension
process or result of adding concepts to an integration model in order to increase the model scope, without
changing the concepts already represented
[ISO/TS 18876-1]
3.1.10
foundation concept
primitive concept that determines the underlying world viewpoint of an integration model
NOTE There can be a number of integration models. Each will have its own modelling paradigm which is characterised
by the primitive concepts that it contains.
EXAMPLE The concepts of class and individual are foundation concepts for a general integration model.
[ISO/TS 18876-1]
3.1.11
general concept
primitive concept that has very wide applicability, but is a specialization of some foundation concept
NOTE A concept may be considered to be a foundation concept by one community, while it is considered to be a gen-
eral concept by another.
[ISO/TS 18876-1]
3.1.12
individual
thing that exists in space and time
NOTE This includes things that actually exist, or have existed, and things that possibly exist in the past, present or fu-
ture.
EXAMPLE The pump with serial number ABC123, Battersea Power Station, Sir Joseph Whitworth, and the Starship
“Enterprise” are examples of individuals.
[ISO/TS 18876-1]
3.1.13
information
facts, concepts, or instructions
[ISO 10303-1]
3.1.14
integration
activity that creates, modifies, or extends an integration model
[ISO/TS 18876-1]
3.1.15
integration model (IM)
application model that can represent the information that is represented by two or more application models
NOTE Being an integration model is about the role one model plays with respect to one or more application models.
[ISO/TS 18876-1]
4 © ISO 2003 – All rights reserved

3.1.16
mapping
correspondence between instances of one model and instances of another model that represent the same mean-
ing
NOTE 1 A mapping can be uni-directional or bi-directional.
NOTE 2 A mapping is the result of applying a mapping specification to particular models.
[ISO/TS 18876-1]
3.1.17
mapping specification
specification of the transformations necessary to take information governed by one model and represent it by
information governed by another model with the same meaning
NOTE 1 A mapping specification can include data structure transformations, data value transformations, data encoding
transformations, and terminology transformations.
NOTE 2 Mapping specifications can be procedural, or declarative, or a combination of these.
[ISO/TS 18876-1]
3.1.18
model
limited information representation of something suitable for some purpose
NOTE A model can be data, or a data model, or take some other form. See Annex D for further discussion of the rela-
tionship between models, data, and data models.
[ISO/TS 18876-1]
3.1.19
model context
sum of constraints that limit the possibility of adding to a model without changing any existing declarations
NOTE 1 The model context is therefore the class of all possible extensions to a model.
NOTE 2 This term is more general than application context as defined in ISO 10303-1.
[ISO/TS 18876-1]
3.1.20
model scope
range of information that an application model can describe
[ISO/TS 18876-1]
3.1.21
primitive concept
concept in an integration model that is not wholly defined in terms of other concepts
[ISO/TS 18876-1]
3.1.22
structural transformation
type of mapping specification that is a transformation to the structure of data
NOTE The change in structure could be to the rearranging of attributes, the splitting of attributes across entity data
types, or the creation of new attributes.
[ISO/TS 18876-1]
3.1.23
terminology transformation
transformation of the term used to refer to a thing
NOTE This could be between synonyms in one language, or between different languages.
[ISO/TS 18876-1]
3.1.24
transformation
change of form
[ISO/TS 18876-1]
3.1.25
view
model that is a constrained subset of another model
[ISO/TS 18876-1]
3.2 Abbreviations
For the purposes of this document, the following abbreviations apply.
AM application model
NOTE In ISO 10303 the abbreviation AM is used for Application Module. An Application Module is not the same as an
Application Model.
IM integration model
4 Usage scenarios
The methodology defined in this part of ISO 18876 is designed to meet requirements typified by the following
usage scenarios:
— integrating two or more existing application models (see 4.1);
— integrating one or more existing application models with an existing integration model (see 4.2);
— defining an application model and its mapping to an integration model (see 4.3);
— integrating an application model with more than one integration model (see 4.4);
— improving an integration model (see 4.5).
4.1 Integrating application models
This component of the methodology integrates two or more application models by creating an integration model
that is capable of representing all of the concepts and constraints of the application models. Such an integration
model supports the communication of data between applications and users that operate using the application
models.
6 © ISO 2003 – All rights reserved

This requirement and its solution are illustrated in Figure 1 below.
Modelling
Paradigm and
Principles
Integration
Model
Mapping
Specifications
Application Application
Application Application
Model Model
1 2
Model Model
1 2
Figure 1 — Creating an integration model that integrates two application models
The inputs to the activity are as follows:
— two or more application models;
— the modelling paradigm and principles chosen for the creation of integration models.
NOTE The use of such principles is an important criterion in determining the future extensibility and reuse of an integra-
tion model.
The outputs of this activity are as follows:
— an integration model that represents the concepts and constraints of the input application models;
— mapping specifications that represent the relationships between constructs of each application model and
their corresponding subsets of the integration model.
The mapping specifications include any constraints that apply for the application models. The subset of the in-
tegration model that corresponds to each application model includes concepts that are not explicit in the applica-
tion model and have been discovered during the integration process.
4.2 Integrating application models with an integration model
This component of the methodology integrates one or more application models and an existing integration
model. The purpose of this activity may be either or both of the following:
— integrating the application models;
— improving the quality of the application models by representing their concepts and constraints in a more
consistent and extensible form and structure;
— To extend the model scope of the integration model.
The nature and results of this activity depend on the nature of the integration model and the other application
models that are to be integrated. This subclause describes the scenario in which the model context of the appli-
cation models to be integrated is a subset of the model context of the integration model.
NOTE 1 See 4.5 for a description of the scenario in which the model context of the application models to be integrated is
not a subset of the model context of the integration model. The relationship between scope and context of different models is
explained in ISO/TS 18876-1:2003, 5.1.2.
This requirement and its solution are illustrated in Figure 2 below.
Modelling
Paradigm and
Principles
Integration
Extended
Model
Integration Model
Mapping
Specifications
Application Application Application
Application Application Application
Model Model Model
1 2 n
Model Model Model
1 2 n
input output
Figure 2 — Integrating an application model with an existing integration model
The inputs to the activity are as follows:
— an existing integration model;
— one or more application models that are integrated with the integration model, including the mapping speci-
fications that relate each application model to its corresponding subset of the integration model;
— the modelling paradigm and principles used to create the integration model – these also determine how the
integration model is extended to meet the requirements of the application model.
The outputs of the activity are as follows:
— an extended integration model (if the input integration model does not precisely satisfy the requirements of
the application models);
NOTE 2 Extensions to an integration model do not make any change to the objects and relationships in the input inte-
gration model. The model scope of the integration model is increased. The context of a model cannot be increased ex-
cept by removing constraints. This would be a change to the existing integration model, so the change would not be an
extension.
— a mapping specification that represents the relationships between constructs of the application models and
the corresponding subsets of the extended integration model;
— improvements to the application model (if appropriate).
8 © ISO 2003 – All rights reserved

4.3 Defining an application model and its mapping to an integration model
This component of the methodology creates an application model together with its mapping to an integration
model. The purpose of this activity is to enable use of the integration model in order to achieve integration
amongst applications or a community of users that have common information requirements.
This requirement and its solution are illustrated in Figure 3 below.
Modelling
Paradigm and
Principles
Integration
Extended
Model
Integration Model
Mapping
Specifications
Information
Application
Requirements
Model
input output
Figure 3 — Creating an application model and its mapping to an integration model
The inputs to the activity are as follows:
— information requirements, described by one or more of the following:
— existing data;
— existing models;
— usage scenarios;
— paper documents and forms;
— results of interviews with users;
— existing applications.
— an existing integration model;
— the modelling paradigm and principles used to create the integration model – these also determine how the
integration model is extended to meet the stated information requirements.
The outputs of the activity are as follows:
— an extended integration model (if the input integration model does not precisely satisfy the stated
information requirements);
— an application model that satisfies the stated information requirements and is mapped to the integration
model;
NOTE The application model may use the structure and/or the terminology of the integration model. If it uses both,
then it is identical to a subset of the integration model and the mapping between them is trivial.
— a mapping specification that represents the relationships between constructs of the application model and
the corresponding subset of the extended integration model.
4.4 Integrating an application model with two or more integration models
An application model need not be integrated with only one integration model. As shown in Figure 4 below, an
application model can be integrated with two or more different integration models.
The inputs to this activity are as follows:
— one or more application models;
— two or more integration models with which the application models are to be integrated;
— the modelling paradigm and principles used to create the integration models.
Modelling Modelling
Paradigm and Paradigm and
Principles Principles
1 2
Integration Integration
Integration Integration
Model Model
1 2
Model Model
1 2
Mapping
Specifications
Application
Application
Model
Model
input output
Figure 4 — Integrating an application model with more than one integration model
For an application model to be integrated with two or more integration models, the following conditions shall be
satisfied:
— the model context of the application model must be a subset of the model context of each integration
model;
— the model scope of the application model must be a subset of the model scope of each integration model,
which may be extended to meet this requirement.
Integration with each integration model depends on the modelling principles and paradigm that apply to the
development and extension of that integration model.
The outputs of the activity are as follows:
10 © ISO 2003 – All rights reserved

— extended integration models (if one or more of the input integration models do not precisely satisfy the re-
quirements of the application model);
— mapping specifications that represent the relationships between constructs of the application model and the
corresponding subsets of the each of the integration models;
— improvements to the application model (if appropriate).
4.5 Improving an integration model
This aspect of the methodology creates a new integration model in the case that an existing integration model
does not satisfy the requirements of an application model, and cannot be extended to do so. This situation arises
when the model context of the integration model is insufficiently broad to meet the needs of the application
models that are to be integrated. This insufficiency may be observed as constraints in the structure of the inte-
gration model that do not apply for one or more application models that are to be integrated.
This requirement and its solution are illustrated in Figure 5 below.
Modelling
Paradigm and
Principles
Integration
New Integration
Model
Model
Mapping
Specifications
Integration
Model
Application Application Application
Application
Model Model Model
1 2 n
Model
n
Application Application
Model Model
1 2
input output
Figure 5 — Improving an integration model
The inputs to this activity are as follows:
— an existing integration model;
— one or more application models that are integrated with the integration model, including the mapping speci-
fications that relate each application model to its corresponding subset of the integration model;
— one or more further application models that are to be integrated but whose requirements cannot be satisfied
using the existing integration model.
The outputs of the activity are as follows:
— a new integration model that has a broader model context than that of the original integration model;
NOTE This new integration model may have to be developed on the basis of a more general modelling paradigm
than that used for the original integration model.
EXAMPLE If an integration model has a snapshot (current state) view of the world, a change in modelling paradigm
will be necessary if it is to support statements about the past and/or the future.
— mapping specifications that represent the relationships between constructs of each application model and
their corresponding subsets of the new integration model.
The scenario depicted in Figure 5 results in the creation of a mapping specification from the initial integration
model to the new integration model. This implies that in order to migrate data from application model AM to
application model AM it is necessary to consider three mappings: that from AM to the original integration
n 1
model, that from the original integration model to the new integration model, and that from AM to the new
n
integration model. Technical or economic considerations may result in an alternative approach, as shown in
Figure 6 below. Here mapping specifications are defined between the initial integrated application models AM
and AM and the new integration model. This reduces the number of mapping specifications to be considered
for pairwise combinations of application models, at the expense of additional analysis and mapping effort.
Modelling
Paradigm and
Principles
Integration
New Integration
Model
Model
Mapping
Specifications
Application Application Application
Application Application Application
Model Model Model
1 2 n
Model Model Model
1 2 n
input output
Figure 6 — Alternative mappings to an improved integration model
5 Methods for integrating application models
This clause presents the methods that shall be applied in order to integrate application models. These are di-
vided into four stages:
— analysis of the application model and other information requirements;
— extension of the integration model (if required);
— identification of the subset of the integration model that corresponds to the application model;
— definition of a mapping between the application model and the identified subset of the integration model.
Each stage is characterized by the necessary pre-conditions, a description of the methods to be applied, and the
post-conditions that determine the successful application of the methods.
NOTE An activity model for the integration process is shown in Annex B.
12 © ISO 2003 – All rights reserved

5.1 Analysis of the requirements
The purpose of this activity is to identify an integration model that is suitable for integrating the application
model(s) of interest, and to determine how the concepts that are represented by the application model(s) are
related to the concepts of the chosen integration model.
5.1.1 Pre-conditions
5.1.1.1 Application model
The following pre-conditions apply to analysis of application models:
— definitions, diagrams, and other specifications that describe the application model shall be available;
— example data populations that illustrate usage of the application model shall be available;
— application domain experts shall be available to provide information about the use of the model in different
implementations.
NOTE Additional information supplied by application domain experts is often needed to fully understand the model
context of the application model and to ensure that this implicit information is explicitly represented in the integration model
or in the application model’s mapping specification.
5.1.1.2 Modelling languages
No specific pre-conditions apply to the modelling languages used to describe application models. The documen-
tation that describes an application model should state any assumptions, usage practices, or other supporting
information that characterizes the way in which a modelling language represents the model.
NOTE 1 Although desirable, this information may not be available for some application models. Analysts should therefore
be familiar with different usage practices for modelling languages.
NOTE 2 In the absence of explicit documentation of the usage practices applied, analysts should not assume that a model-
ling language has been applied consistently within the description of an application model.
5.1.2 Method description
The methods that apply to analysis of requirements are as follows:
— selection of an integration model;
— analysis of application model concepts.
5.1.2.1 Selection of an integration model
Although creation of an integration model that solely integrates two or more integration models is possible (see
4.1) a more common requirement is to integrate one or more application models with an existing integration
model (see 4.2). The following criteria apply to the selection of a suitable integration model.
— The integration model chosen should have a model context that includes the model context of the applica-
tion model(s) being integrated.
NOTE 1 If the model context of an application model is not wholly contained in the model context of an integration
model, then the integration model cannot integrate all the concepts represented in the application model(s) without
change to the integration model.
NOTE 2 See Annex D.2 for a discussion of the techniques that can be used to determine the model context of an ap-
plication model.
— If more than one integration model is available with a suitable model context, the integration model chosen
should have a model scope that is closest to or overlaps with that that of the application model(s) to be inte-
grated. If more than one application model is to be integrated the model scope to be considered is the union
of the model scopes of the application models.
NOTE 3 Choice of an integration model whose model scope overlaps with that of the application model(s) to be in-
tegrated is likely to simplify the integration process and to reduce the need for extension of the integration model.
NOTE 4 Analysis of application models that have already been integrated with a candidate integration model, and
their associated mapping specifications, is good practice for determining overlaps of model scope. Similarly, analysis
of the derived concepts that are explicitly represented in an integration model is good practice for determining overlaps
of model scope.
5.1.2.2 Analysis of application model concepts
This analysis is illustrated in Figure 7 below.
analysis of application
model concepts
application integration
model concepts model concepts
Figure 7 — Analysis of application model
The nature of these relationships varies considerably, depending on the nature of the models involved. Some or
all of the following relationship types may be recognized during this analysis:
— synonyms: the same concept exists in the application model(s) and the integration model, but one or more
of the models uses a different name for the concept;
— homonyms: concepts exist within one or more of the application model(s) and the integration model that
have the same name but have different meanings;
— identical concepts: the same concept exists in the application model and the integration model, has pre-
cisely the same meaning, and has the same structure and constraints in both cases;
— compatible concepts: the same concept exists in the application model and the integration model, has the
same meaning, but has different structure or constraints that are not contradictory;
— incompatible concepts: the same concept exists in the application model and the integration model, has the
same meaning, but has different structure or constraints that are contradictory;
14 © ISO 2003 – All rights reserved

— complex concepts (in the application model): a group of one or more concepts in the application model
corresponds to one or more concepts in the integration model;
EXAMPLE 1 An application model includes the concept “red car” and is mapped to an integration model that
represents as separate concepts “red (thing)” and “car”. The application model concept is represented by a combination
of the two integration model concepts.
EXAMPLE 2 An application model includes an entity data type called product which can represent either
individual manufactured items (identified by serial numbers) or classes of manufactured items (identified by part
numbers). If these are recognized as separate concepts in the integration model as physical_object and
class_of_physical_object, then instances of product in the application model can correspond to instances of both
concepts in the integration model.
— partitioned concepts (in the application model): two or more concepts in the application model correspond
to a single general concept in the integration model.
EXAMPLE 3 An application model contains entity data types called customer and supplier. These may both
correspond to a general entity data type in the integration model called organization.
Lastly, it is possible that a con
...