ISO 19103:2024

Geographic information - Conceptual schema language

This document specifies provisions for the use of a conceptual schema language within the context of modelling geographic information. The chosen conceptual schema language is a subset of the Unified Modeling Language (UML). This document specifies a UML profile for modelling geographic information. This document specifies a set of core data types for use in conceptual schemas. The standardization target type of this document is conceptual schemas describing geographic information.

Information géographique — Langage de schéma conceptuel

Le présent document spécifie des dispositions pour l’utilisation d’un langage de schéma conceptuel dans le contexte de la modélisation d’informations géographiques. Le langage de schéma conceptuel choisi est un sous-ensemble du langage de modélisation unifié (UML). Le présent document spécifie un profil UML destiné à la modélisation d’informations géographiques. Le présent document spécifie un ensemble de types de données de base à utiliser dans des schémas conceptuels. Le présent document a pour type de cible de normalisation les schémas conceptuels décrivant des informations géographiques.

General Information

• Status: Published
• Publication Date: 26-Sep-2024
• ICS: 35.240.70 - IT applications in science
• Technical Committee: ISO/TC 211 - Geographic information/Geomatics
• Drafting Committee: ISO/TC 211 - Geographic information/Geomatics
• Current Stage: 6060 - International Standard published
• Start Date: 27-Sep-2024
• Due Date: 16-Jul-2024
• Completion Date: 27-Sep-2024

Relations

• Revises: ISO 19103:2015 - Geographic information - Conceptual schema language
• Effective Date: 06-Jun-2022

Overview - ISO 19103:2024 (Conceptual schema language)

ISO 19103:2024 specifies provisions for using a conceptual schema language to model geographic information. The standard selects a subset of the Unified Modeling Language (UML) and defines a dedicated UML profile for conceptual schemas. It also publishes a set of core data types intended for consistent use across conceptual schemas describing geographic information. The standard targets the creation, exchange and conformance assessment of conceptual schemas in geospatial systems.

Key technical topics and requirements

• UML profile and subset: Defines how UML is restricted and profiled for geographic information modelling, including naming rules and allowed notation.
• Classifiers and features: Rules for modelling Classes, Data types, Enumerations, Interfaces, Properties and Operations.
• Relationships: Guidance for Associations, Generalizations, Realizations and Template bindings as used in conceptual schemas.
• Packages and diagrams: Provisions for package and class diagrams, comments and diagram usage specific to GIS conceptual models.
• Constraints and conformance: Formal conformance rules and a normative abstract test suite to validate conceptual schemas against the ISO 19103 profile.
• Reusable types / Core data types: A curated set of abstract data types (e.g., Date, DateTime, UUID, URI/IRI, Measure, Vector, Integer, Decimal, Boolean, etc.) tailored to geographic information modelling.
• Interoperability considerations: Mapping relations to ISO/IEC 11404 and informative annexes on backward compatibility, UML notation and conceptual schema representations.

Practical applications and benefits

• Standardizes how organizations express domain concepts in GIS data models, improving clarity and reusability.
• Enables consistent conceptual schema exchange between agencies, vendors and software tools.
• Supports interoperability between data models and implementations by prescribing core data types and UML modelling constraints.
• Facilitates automated conformance testing, model validation and model-driven engineering pipelines in geospatial software development.
• Useful as a foundation for designing metadata, data schemas, application schema transformations, and system integration.

Who should use ISO 19103:2024

• GIS data architects, geospatial modelers and domain analysts
• Software developers and system integrators implementing geospatial information systems
• Standards bodies, national mapping agencies and organizations developing interoperable geodata products
• Tool vendors providing UML-based modelling, validation and code-generation for GIS

Related standards and resources

• ISO/IEC 11404 (data type relations and mappings referenced in ISO 19103)
• Other ISO 191xx geographic information standards (for application schemas, metadata and services)
• Annexes in ISO 19103: normative test suite, UML notation reference, and mapping guidance for backward compatibility

Keywords: ISO 19103, conceptual schema language, UML profile, core data types, geographic information, GIS data modelling, conformance, interoperability.

Standards Content (Sample)

International
Standard
ISO 19103
Second edition
Geographic information —
2024-09
Conceptual schema language
Information géographique — Langage de schéma conceptuel
Reference number
© ISO 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.11
5 Conformance .12
5.1 Conformance overview . 12
5.2 Conceptual schemas modelled in UML . 12
6 Overview .12
7 Use of UML .13
7.1 General use of UML . 13
7.2 Classifiers . 15
7.2.1 General . 15
7.2.2 Classes .16
7.2.3 Data types .16
7.2.4 Enumerations .17
7.2.5 Interfaces .18
7.3 Features .19
7.3.1 General .19
7.3.2 Properties .19
7.3.3 Operations . 23
7.4 Relationships . 23
7.4.1 General . 23
7.4.2 Associations . 23
7.4.3 Generalizations . 25
7.4.4 Realizations . 25
7.4.5 Template bindings . 26
7.5 Packages . 26
7.6 Comments . 28
7.7 Constraints. 28
7.8 UML profile . 28
7.9 Naming provisions . 35
7.10 Diagrams . 38
7.10.1 General . 38
7.10.2 Package diagrams. 39
7.10.3 Class diagrams . 39
7.11 Reusable types . 40
7.11.1 General . 40
7.11.2 Core data types . 40
7.11.3 Common types . 40
8 Core data types .40
8.1 General . 40
8.1.1 Relation with ISO/IEC 11404 . 40
8.1.2 Modelling choice for the core data types .42
8.2 Contents of the Core Data Types abstract schema . 44
8.2.1 AnnualDate . 44
8.2.2 AnnualMonth . 44
8.2.3 Binary . 44
8.2.4 Bit .45
8.2.5 Boolean .45
8.2.6 Character .45

iii
8.2.7 CharacterString .45
8.2.8 Date . 46
8.2.9 DateTime . 46
8.2.10 Decimal . 46
8.2.11 Digit . 46
8.2.12 Integer .47
8.2.13 IRI .47
8.2.14 Measure .47
8.2.15 Number . 48
8.2.16 PositionInTime . 48
8.2.17 Rational. 50
8.2.18 Real . 50
8.2.19 RecurringPositionInTime . 50
8.2.20 Sign .51
8.2.21 Time .51
8.2.22 URI.51
8.2.23 UUID .52
8.2.24 Vector.52
8.2.25 Year . 53
8.2.26 YearMonth . 53
Annex A (normative) Abstract test suite .54
Annex B (informative) Backward compatibility .57
Annex C (informative) On conceptual schema languages .63
Annex D (informative) UML notation reference .64
Annex E (informative) Differences between UML 2.5.1 and UML 2.4.1 .71
Annex F (informative) Mapping between ISO 19103 and ISO/IEC 11404 data types .72
Annex G (informative) Conceptual schema representations .75
Annex H (informative) Code sets . 76
Bibliography .86

iv
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 technical committees. Each member body interested in a subject for which a technical committee
has been established 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.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO document should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 211, Geographic information/Geomatics, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC 287,
Geographic Information, in accordance with the Agreement on technical cooperation between ISO and CEN
(Vienna Agreement).
This second edition cancels and replaces the first edition (ISO 19103:2015), which has been technically
revised.
The main changes are as follows:
— conformance to UML 2.5.1 has been improved;
— the UML profile has been improved and the stereotypes Leaf, CodeList and Union have been
deprecated;
— the collection data types, the name data types, the extension data types and data type Any have been
removed;
— alignment with the data types described in ISO/IEC 11404:2007, Clause 8 and Clause 10 has been
improved;
— the conformance classes for conceptual schemas modelled in UML 1.x and for conceptual schemas
modelled in another conceptual schema language have been removed;
— the normative references have been updated, in particular:
— addition of UML 2.5.1 and removal of ISO/IEC 19505-2:2012 (equivalent to UML 2.4.1,
[4]
Superstructure );
— removal of the Object Constraint Language (OCL) specification.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
This document is concerned with the adoption and use of a conceptual schema language (CSL) for developing
computer-interpretable models, or schemas, of geographic information. Standardization of geographic
information requires the use of a formal CSL to specify unambiguous schemas that can serve as a basis for
data interchange. An important goal of the ISO 19100 family of documents is to create a framework in which
data interchange and service interoperability can be realized across multiple implementation environments.
The adoption and consistent use of a CSL to specify geographic information is of fundamental importance in
achieving this goal.
There are two aspects to this document. First, a CSL is selected that meets the requirements for rigorous
representation of geographic information. Several CSLs exist, of which two predominate in the geographic
domain: the Unified Modeling Language (UML), specified by the Object Management Group (OMG), on the one
hand, and the combination of the three Semantic Web specifications, the Resource Description Framework
Schema (RDFS), the Web Ontology Language (OWL) and the Shapes Constraint Language (SHACL), specified
by the World Wide Web Consortium (W3C), on the other hand. It was decided to continue using UML as it
has proven its capability within the ISO 19100 family of documents, it supports a model-driven approach
and it has a standardized graphical notation. This document identifies a subset of UML as the CSL for the
specification of conceptual schemas. It also specifies a UML profile for the specification of conceptual
schemas, and it specifies provisions on how to use UML and the UML profile to create conceptual schemas
that are a basis for achieving the goal of interoperability. In addition, this document defines a set of core data
type definitions for use in conceptual schemas.
One goal of the ISO 19100 family of documents using conceptual schemas specified in UML is that they will
provide a basis for model-based mapping to encoding schemas like those defined in ISO 19118, as well as a
basis for creating implementation specifications for implementation profiles for various other environments.
This document describes the general metamodel for the use of UML in the context of ISO geographic
information documents. Aspects specifically dealing with the modelling of application schemas are
described in ISO 19109.
In accordance with the ISO/IEC Directives, Part 2, 2021, Principles and rules for the structure and drafting
of ISO and IEC documents, in International Standards the decimal sign is a comma on the line. However, the
General Conference on Weights and Measures (Conférence Générale des Poids et Mesures) at its meeting in
2003 passed unanimously the following resolution: “The decimal marker shall be either a point on the line
[5]
or a comma on the line.” In practice, the choice between these alternatives depends on customary use in
the language concerned. In the technical areas of geodesy and geographic information it is customary for the
decimal point always to be used, for all languages. That practice is used throughout this document.
The name and contact information of the maintenance agency for this document can be found at
www.iso.org/maintenance_agencies.

vi
International Standard ISO 19103:2024(en)
Geographic information — Conceptual schema language
1 Scope
This document specifies provisions for the use of a conceptual schema language within the context of
modelling geographic information. The chosen conceptual schema language is a subset of the Unified
Modeling Language (UML).
This document specifies a UML profile for modelling geographic information.
This document specifies a set of core data types for use in conceptual schemas.
The standardization target type of this document is conceptual schemas describing geographic information.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements 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.
UML 2.5.1: OBJECT MANAGEMENT GROUP (OMG). Unified Modeling Language (UML) [online]. Version 2.5.1.
December 2017. Available at: https:// www .omg .org/ spec/ UML/ 2 .5 .1
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
abstract
filter out detail that is not within the scope of interest
Note 1 to entry: Abstracting facilitates the understanding of the essence of a concept (3.20) and allows for handling
complexity.
Note 2 to entry: An act of abstracting is designated as an “abstraction”. In the information technology domain, the
term “abstraction” also represents concept abstraction (3.4).
3.2
abstract classifier
classifier (3.16) that has no direct instances (3.42)
Note 1 to entry: UML 2.5.1, 9.2.3.2 requires that every instance of an abstract classifier is an instance of one of its
specializations.
Note 2 to entry: Adapted from UML 2.5.1, 9.2.3.2.

3.3
abstract schema
conceptual schema (3.23) that is not implementable without further specification
EXAMPLE The conceptual schemas for describing the spatial characteristics of geographic entities defined in
ISO 19107:2019.
Note 1 to entry: An abstract schema can be applied to many domains.
Note 2 to entry: An abstract schema can be realized by an application schema (3.8).
3.4
abstraction
result of an act of abstracting (3.1)
3.5
abstraction
dependency (3.30) that relates two named elements (3.50) or sets of named elements that represent
the same concept (3.20) at different levels of abstraction (3.45) or from different viewpoints
Note 1 to entry: Adapted from UML 2.5.1, 7.7.3.3.
3.6
aggregation
shared aggregation
binary association (3.12) that specifies a part-whole relation (3.58) where the whole does not have
responsibility for the existence of its parts
Note 1 to entry: A part can be included in more than one whole simultaneously.
Note 2 to entry: Adapted from UML 2.5.1, 9.5.3.
3.7
application
manipulation and processing of data in support of user requirements
[SOURCE: ISO 19101-1:2014, 4.1.1]
3.8
application schema
conceptual schema (3.23) for data required by one or more applications (3.7)
[SOURCE: ISO 19101-1:2014, 4.1.2]
3.9
association
semantic relationship (3.63) that can occur between instances (3.42) that have a type (3.70)
Note 1 to entry: An association is also a kind of classifier (3.16).
Note 2 to entry: Adapted from UML 2.5.1, 11.5.3.1.
3.10
attribute
property (3.61) owned by a classifier (3.16) other than an association (3.9)
Note 1 to entry: Adapted from UML 2.5.1, 9.5.3.
3.11
behavioural feature
feature (3.36) that specifies an aspect of behaviour
Note 1 to entry: Adapted from UML 2.5.1, 9.9.2.1.

3.12
binary association
association (3.9) having two member ends
Note 1 to entry: UML 2.5.1, 11.5.3.1 permits that the two member ends have the same type (3.70).
Note 2 to entry: Adapted from UML 2.5.1, 11.5.3.1.
3.13
cardinality
number of values
EXAMPLE The cardinality of a collection having three values is three.
Note 1 to entry: Cardinality is a characteristic of a collection.
Note 2 to entry: Adapted from UML 2.5.1, 7.5.3.2.
3.14
class
classifier (3.16) of a set of objects (3.54)
Note 1 to entry: Adapted from UML 2.5.1, 11.8.3.1.
3.15
class diagram
structure diagram where the primary symbols in the contents area are either class (3.14) symbols or
interface (3.43) symbols, or both
Note 1 to entry: Adapted from UML 2.5.1, Annex A.
3.16
classifier
classification of instances (3.42) according to their features (3.36)
Note 1 to entry: A classifier is a kind of type (3.70).
Note 2 to entry: Adapted from UML 2.5.1, 9.2.1.
3.17
code set
code element set
code
code list
result of applying a coding scheme to all elements of a coded set
EXAMPLE The three-letter representations of airport names.
Note 1 to entry: The term “code” also represents the concept defined in ISO 19118:2011, 4.3.
[SOURCE: ISO/IEC 2382:2015, 2121556, modified — An additional admitted term “code list” has been added,
the definition has been adjusted to use the terms used in Annex H, Note 1 to entry has been converted into
an Example, Notes 2 and 3 to entry have been removed and a new Note 1 to entry has been added.]
3.18
comment
note
textual annotation that can be attached to a set of elements
Note 1 to entry: Adapted from UML 2.5.1, 7.8.2.1.

3.19
composition
binary association (3.12) that specifies a part-whole relation (3.58) where the whole has responsibility
for the existence of its parts
Note 1 to entry: A part can only be included in at most one whole at a time.
Note 2 to entry: Adapted from UML 2.5.1, 9.5.3.
3.20
concept
unit of knowledge created by a unique combination of characteristics
Note 1 to entry: Concepts are not necessarily bound to particular natural languages (3.52). They are, however,
influenced by social or cultural background, which often leads to different categorizations.
Note 2 to entry: This is the concept “concept” as used and designated by the term “concept” in terminology work. It is a
very different concept from that designated by other domains such as industrial automation or marketing.
[SOURCE: ISO 1087:2019, 3.2.7]
3.21
conceptual formalism
set of modelling concepts (3.20) used to describe a conceptual model (3.22)
EXAMPLE Object-oriented modelling.
Note 1 to entry: One conceptual formalism can be expressed in several conceptual schema languages (3.24).
[SOURCE: ISO 19101-1:2014, 4.1.4, modified — Examples have been replaced.]
3.22
conceptual model
model (3.48) that defines concepts (3.20) of a universe of discourse (3.72)
Note 1 to entry: A model can include relations between concepts. A relation is a concept too.
[SOURCE: ISO 19101-1:2014, 4.1.5, modified — Note to entry added.]
3.23
conceptual schema
formal description of a conceptual model (3.22)
[SOURCE: ISO 19101-1:2014, 4.1.6]
3.24
conceptual schema language
formal language (3.37) based on a conceptual formalism (3.21) for the purpose of representing conceptual
schemas (3.23)
EXAMPLE UML, EXPRESS, IDEF1X.
Note 1 to entry: A conceptual schema language can be lexical or graphical. Several conceptual schema languages can
be based on the same conceptual formalism.
[SOURCE: ISO 19101-1:2014, 4.1.7]
3.25
constraint
condition or restriction expressed in natural language (3.52) text or in a machine readable language
for the purpose of declaring some of the semantics of an element or set of elements
Note 1 to entry: Adapted from UML 2.5.1, 7.8.3.1.

3.26
data type
set of distinct values, characterized by properties of those values, and by operations (3.55) on those values
EXAMPLE The data type “Boolean” with properties “unordered”, “exact” and “non-numeric”, and with operations
“equal”, “not”, “and” and “or”.
Note 1 to entry: Properties of data type values are ordered or unordered, exact or approximate, numeric or non-
numeric and, if ordered, bounded or unbounded, as described in ISO/IEC 11404.
[SOURCE: ISO/IEC 11404:2007, 3.12, modified — Note to entry and example added.]
3.27
data type
classifier (3.16) whose instances (3.42) are distinguished only by their value
Note 1 to entry: Adapted from UML 2.5.1, 10.2.1.
3.28
data value
instance (3.42) of a data type (3.27)
Note 1 to entry: Adapted from UML 2.5.1, 7.5.3.2.
3.29
definition
representation of a concept (3.20) by an expression that describes it and differentiates it from related
concepts
[SOURCE: ISO 1087:2019, 3.3.1]
3.30
dependency
directed relationship (3.32) which signifies that a single model element or a set of model elements
requires other model elements for their specification or implementation
Note 1 to entry: A dependency signifies a supplier/client relationship (3.63) between model elements where the
modification of a supplier can impact the client model elements. The complete semantics of the client element(s) are
either semantically or structurally dependent on the definition (3.29) of the supplier element(s).
Note 2 to entry: Adapted from UML 2.5.1, 7.7.1 and 7.8.4.
3.31
designation
designator
label
representation of a concept (3.20) by a sign which denotes it in a domain or subject
Note 1 to entry: A designation can be linguistic or non-linguistic. It can consist of various types of characters, but also
punctuation marks such as hyphens and parentheses, governed by domain-, subject-, or language-specific conventions.
Note 2 to entry: A designation can be a term including appellations, a proper name, or a symbol.
[SOURCE: ISO 1087:2019, 3.4.1, modified — An additional admitted term “label” has been added.]
3.32
directed relationship
relationship (3.63) between a collection of source model elements and a collection of target model
elements
Note 1 to entry: Adapted from UML 2.5.1, 7.8.5.1.

3.33
enumeration
data type (3.27) whose values are named individually in the model (3.48)
Note 1 to entry: The set of enumeration literals (3.34) owned by an enumeration is ordered.
Note 2 to entry: Adapted from UML 2.5.1, 10.5.3
3.34
enumeration literal
user-defined data value (3.28) for an enumeration (3.33)
Note 1 to entry: In this case, the user is the modeller.
Note 2 to entry: Adapted from UML 2.5.1, 10.5.4.1.
3.35
extension
association (3.9) which indicates that the properties (3.61) of a metaclass (3.46) are extended through
a stereotype (3.65)
Note 1 to entry: Adapted from UML 2.5.1, 12.4.1.1.
3.36
feature
characteristic
Note 1 to entry: Adapted from UML 2.5.1, 9.4.3.1.
3.37
formal language
language that is machine readable and has well-defined semantics
Note 1 to entry: Well-defined semantics will typically be model-theoretic semantics.
[SOURCE: ISO/IEC 21838-1:2021, 3.10]
3.38
generalization
taxonomic directed relationship (3.32) between a more general classifier (3.16) and a more specific
classifier
Note 1 to entry: The more general classifier is called the parent, or the superclass if the classifier is a class (3.14).
The more specific classifier is called the child. The generalization is directed from the child to the parent. The
classifiers that can be reached by following the generalizations from a given classifier in the direction towards the
more general classifiers are called the classifier’s generalizations. The classifiers that can be reached by following the
generalizations from a given classifier in the direction towards the more specific classifiers are called the classifier’s
specializations.
Note 2 to entry: Each instance (3.42) of the specific classifier is also an instance of the general classifier. The specific
classifier inherits the features (3.36) of the more general classifier.
Note 3 to entry: Adapted from UML 2.5.1, 9.2.3.2 and 9.9.7.
3.39
identifier
linguistically independent sequence of characters capable of uniquely and permanently identifying that with
which it is associated
[SOURCE: ISO 19135-1:2015, 4.1.5]

3.40
identity
inherent characteristic of an instance (3.42) that distinguishes it from all other instances
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1865, modified — The term “property” has been replaced by
“characteristic” in the definition, and the Note to entry has been removed.]
3.41
inheritance
mechanism by which more specific entities incorporate structure and behaviour
defined by more general entities
3.42
instance
individual entity
Note 1 to entry: The term “instance” represents the same concept as the term “particular” defined in
ISO/IEC 21838-1:2021, 3.3.
3.43
interface
classifier (3.16) that represents a declaration of a set of coherent public features (3.36) and obligations
that together constitute a coherent service
Note 1 to entry: An interface specifies a contract; UML 2.5.1, 10.4.3.1 requires that any instance (3.42) of a classifier
that realizes the interface fulfils that contract. The obligations associated with an interface are in the form of
constraints (3.25) (such as pre- and post-conditions) or protocol specifications, which can impose ordering restrictions
on interactions through the interface.
Note 2 to entry: Adapted from UML 2.5.1, 10.4.3.1.
3.44
keyword
reserved word that is an integral part of the UML notation
Note 1 to entry: Keywords normally appear as text annotations attached to a UML graphic element or as part of a
text line in a UML diagram. Keywords are enclosed in guillemets («keyword») and thus have the same notation as
stereotyped (3.65) model elements.
Note 2 to entry: Adapted from UML 2.5.1, Annex C.
3.45
level of abstraction
abstraction level
indication of the amount of detail that is outside the scope of interest
Note 1 to entry: A model (3.48) at a high level of abstraction has a relatively low amount of detail.
3.46
metaclass
class (3.14) in a metamodel (3.47)
EXAMPLE The class “Interface” is a class in the UML metamodel and is therefore a metaclass.
Note 1 to entry: Adapted from UML 2.5.1, 6.2.
3.47
metamodel
model (3.48) that defines a modelling language
EXAMPLE The UML metamodel.
Note 1 to entry: A model is an instance (3.42) of a metamodel, and a metamodel is an instance of a meta-metamodel.

[15]
Note 2 to entry: Adapted from the MDA Guide.
3.48
model
abstraction (3.4) of some aspects of reality
[SOURCE: ISO 19109:2015, 4.15]
3.49
multiplicity
specification of the valid cardinalities (3.13)
EXAMPLE An instance (3.42) of a collection specified as having a multiplicity of “1.3” has at least one value and
has not more than three values.
Note 1 to entry: A multiplicity is a definition of an inclusive interval of non-negative integers beginning with a lower
bound and ending with a (possibly infinite) upper bound.
Note 2 to entry: Adapted from UML 2.5.1, 7.5.3.2 and 7.8.8.1.
3.50
named element
element in a model (3.48) that can have a name
Note 1 to entry: Adapted from UML 2.5.1, 7.8.9.
3.51
namespace
named element (3.50) that either owns or imports, or both, a set of named elements that can be
identified by a name
Note 1 to entry: Adapted from UML 2.5.1, 7.8.10.1.
3.52
natural language
language which is or was in active use in a community of people, and the rules of which are mainly deduced
from usage
[SOURCE: ISO 5127:2017, 3.1.5.02, modified — The Note to entry has been removed.]
3.53
n-ary association
association (3.9) having more than two member ends
Note 1 to entry: An association with three members ends is called a ternary association.
Note 2 to entry: Adapted from UML 2.5.1., 11.5.3.1.
3.54
object
individual with a state and relationships (3.63) to other individuals
Note 1 to entry: An object is an instance (3.42) of a class (3.14).
Note 2 to entry: Adapted from UML 2.5.1, 6.3.1.
3.55
operation
behavioural feature (3.11) of an interface (3.43), data type (3.27) or class (3.14)
Note 1 to entry: UML 2.5.1, 9.6.3.1 permits that an operation is directly invoked on instances (3.42) of its featuring
classifiers (3.16). The operation specifies the name, type (3.70), parameters and constraints (3.25) for such invocations.
Note 2 to entry: Adapted from UML 2.5.1, 9.6.3.1.

3.56
package
element that is used to group elements, and provides a namespace (3.51) for the grouped elements
Note 1 to entry: Adapted from UML 2.5.1, 12.4.5.1.
3.57
package diagram
structure diagram that shows certain aspects of one or more packages (3.56)
Note 1 to entry: Adapted from UML 2.5.1, Annex A
3.58
part-whole relation
partitive relation
relation between two concepts (3.20) where one of the concepts constitutes the whole and the other concept
constitutes a part of that whole
Note 1 to entry: A part-whole relation exists between the concepts “week” and “day”, “molecule” and “atom”.
[SOURCE: ISO 5127:2017, 3.1.7.06, modified — The preferred term and the admitted term have exchanged
positions.]
3.59
primitive type
predefined data type (3.27) without any substructure
Note 1 to entry: A primitive type can have algebra and operations defined outside of UML, for example, mathematically.
Note 2 to entry: Adapted from UML 2.5.1, 10.2.3.2.
3.60
profile
package (3.56) that defines limited extensions to a reference metamodel (3.47) with the purpose of
adapting the metamodel to a specific platform or domain
Note 1 to entry: Adapted from UML 2.5.1, 12.4.7.
3.61
property
structural feature (3.66)
Note 1 to entry: A property is owned by a classifier (3.16), an association (3.9) or another property.
Note 2 to entry: In the UML metamodel (3.47), property is the only kind of structural feature. UML 2.5.1 does not
clearly specify the difference between a property and a structural feature that is not a property.
Note 3 to entry: Adapted from UML 2.5.1, 9.4.3.2, 9.5.3 and 9.9.17.1.
3.62
realization
abstraction (3.5) between two named elements (3.50) or sets of named elements, one representing a
specification and the other representing an implementation of the latter
Note 1 to entry: The supplier represents the specification and the client represents an implementation of the
specification.
Note 2 to entry: Adapted from UML 2.5.1, 7.8.14.1.
3.63
relationship
connection between elements
Note 1 to entry: Adapted from UML 2.5.1, 7.8.15.1.

3.64
schema
formal description of a model (3.48)
[SOURCE: ISO 19101-1:2014, 4.1.34]
3.65
stereotype
model element that extends an existing metaclass (3.46) and enables the use of platform- or domain-
specific terminology or notation in place of, or in addition to, the ones used for the ex
...

Norme
internationale
ISO 19103
Deuxième édition
Information géographique —
2024-09
Langage de schéma conceptuel
Geographic information — Conceptual schema language
Numéro de référence
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2024
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: [phone]
E-mail: [e-mail]
Web: www.iso.org
Publié en Suisse
ii
Sommaire Page
Avant-propos .v
Introduction .vii
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 1
4 Symboles et abréviations .11
5 Conformité .12
5.1 Aperçu de la conformité . 12
5.2 Schémas conceptuels modélisés en UML. 12
6 Vue d’ensemble .12
7 Utilisation de l’UML .13
7.1 Utilisation générale de l’UML . 13
7.2 Classificateurs . 15
7.2.1 Généralités . 15
7.2.2 Classes .16
7.2.3 Types de données .17
7.2.4 Énumérations .17
7.2.5 Interfaces .19
7.3 Fonctions.19
7.3.1 Généralités .19
7.3.2 Propriétés .19
7.3.3 Opérations . 23
7.4 Relations . 23
7.4.1 Généralités . 23
7.4.2 Associations .24
7.4.3 Généralisations . 25
7.4.4 Réalisations . 26
7.4.5 Liaisons de modèles . 26
7.5 Paquetages . 26
7.6 Commentaires . 28
7.7 Contraintes . 28
7.8 Profil UML . 29
7.9 Dispositions de nommage . 36
7.10 Schémas . 39
7.10.1 Généralités . 39
7.10.2 Diagrammes de paquetage . 40
7.10.3 Diagrammes de classe . 40
7.11 Types réutilisables .41
7.11.1 Généralités .41
7.11.2 Types de données de base .41
7.11.3 Types communs .41
8 Types de données de base .42
8.1 Généralités .42
8.1.1 Relation avec l’ISO/IEC 11404 .42
8.1.2 Choix de modélisation pour les types de données de base .43
8.2 Contenu du schéma abstrait des types de données de base .45
8.2.1 AnnualDate .45
8.2.2 AnnualMonth .45
8.2.3 Binary .45
8.2.4 Bit . 46
8.2.5 Boolean . 46
8.2.6 Character . 46

iii
8.2.7 CharacterString . 46
8.2.8 Date .47
8.2.9 DateTime .47
8.2.10 Decimal .47
8.2.11 Digit . 48
8.2.12 Integer . 48
8.2.13 IRI . 48
8.2.14 Measure . 48
8.2.15 Number . 49
8.2.16 PositionInTime . 49
8.2.17 Rational.51
8.2.18 Real .51
8.2.19 RecurringPositionInTime .52
8.2.20 Sign .52
8.2.21 Time .52
8.2.22 URI. 53
8.2.23 UUID . 53
8.2.24 Vector. 53
8.2.25 Year . 54
8.2.26 YearMonth . 54
Annexe A (normative) Suite de tests abstraits .55
Annexe B (informative) Rétrocompatibilité .58
Annexe C (informative) Sur les langages de schéma conceptuel .64
Annexe D (informative) Référence de notation UML .66
Annexe E (informative) Différences entre l’UML 2.5.1 et l’UML 2.4.1 .73
Annexe F (informative) Mise en correspondance entre les types de données ISO 19103 et ISO/
IEC 11404 . 74
Annexe G (informative) Représentations de schémas conceptuels .77
Annexe H (informative) Jeux de codets .78
Bibliographie .89

iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes nationaux
de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en général
confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit de faire
partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales et non
gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore étroitement avec
la Commission électrotechnique internationale (IEC) en ce qui concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier, de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a
été rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir
www.iso.org/directives).
L’ISO attire l’attention sur le fait que la mise en application du présent document peut entraîner l’utilisation
d’un ou de plusieurs brevets. L’ISO ne prend pas position quant à la preuve, à la validité et à l’applicabilité de
tout droit de brevet revendiqué à cet égard. À la date de publication du présent document, l’ISO n'avait pas
reçu notification qu’un ou plusieurs brevets pouvaient être nécessaires à sa mise en application. Toutefois,
il y a lieu d’avertir les responsables de la mise en application du présent document que des informations
plus récentes sont susceptibles de figurer dans la base de données de brevets, disponible à l'adresse
www.iso.org/brevets. L’ISO ne saurait être tenue pour responsable de ne pas avoir identifié tout ou partie de
tels droits de propriété.
Les appellations commerciales éventuellement mentionnées dans le présent document sont données pour
information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer un engagement.
Pour une explication de la nature volontaire des normes, la signification des termes et expressions
spécifiques de l'ISO liés à l'évaluation de la conformité, ou pour toute information au sujet de l'adhésion de
l'ISO aux principes de l’Organisation mondiale du commerce (OMC) concernant les obstacles techniques au
commerce (OTC), voir www.iso.org/avant-propos.
Le présent document a été élaboré par le comité technique ISO/TC 211, Information géographique/
Géomatique, en collaboration avec le comité technique CEN/TC 287, Information géographique, du Comité
européen de normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le CEN
(Accord de Vienne).
Cette deuxième édition annule et remplace la première édition (ISO 19103:2015), qui a fait l’objet d’une
révision technique.
Les principales modifications sont les suivantes:
— la conformité à l’UML 2.5.1 a été renforcée;
— le profil UML a été amélioré et les stéréotypes Leaf, CodeList et Union ont été déconseillés;
— les types de données de collection, les types de données de nom, les types de données d’extension et
le type de données Any ont été supprimés;
— l’harmonisation avec les types de données décrits dans l’ISO/IEC 11404:2007, Article 8 et Article 10 a été
renforcée;
— les classes de conformité pour les schémas conceptuels de l’UML 1.x et pour les schémas conceptuels
modélisés dans un autre langage de schéma conceptuel ont été supprimées;
— les références normatives ont été mises à jour, en particulier:
— ajout de l’UML 2.5.1 et retrait de l’ISO/IEC 19505-2:2012 (norme équivalente à l’UML 2.4.1,
[4]
Superstructure );
— suppression de la spécification du langage d’expression des contraintes orienté objet (OCL).

v
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes se
trouve à l’adresse www.iso.org/fr/members.html.

vi
Introduction
Le présent document porte sur l’adoption et l’utilisation d’un langage de schéma conceptuel (CSL) en vue du
développement de modèles, ou schémas, d’informations géographiques interprétables par des ordinateurs.
La normalisation des informations géographiques nécessite l’utilisation d’un CSL formel pour spécifier des
schémas sans ambigüité, pouvant servir de base à des échanges de données. L’un des buts importants de
la famille de documents ISO 19100 consiste à créer un cadre à l’intérieur duquel l’échange des données et
l’interopérabilité des services puissent être assurés au sein d’environnements d’implémentation multiples.
L’adoption et l’usage cohérent d’un langage CSL pour spécifier des informations géographiques sont d’une
importance capitale pour atteindre cet objectif.
Le présent document a deux aspects. Tout d’abord, un langage CSL est sélectionné pour répondre aux
exigences de représentation rigoureuse des informations géographiques. Il existe plusieurs langages CSL,
dont deux prévalent dans le domaine géographique: le langage de modélisation unifié (UML), spécifié
par le groupe de gestion d’objet (Object Management Group, OMG), d’une part et la combinaison des trois
spécifications du Web sémantique, à savoir le cadre de description de ressource (Resource Description
Framework Schema, RDFS), le langage d’ontologies Web (Web Ontology Language, OWL) et le langage de
contrainte des formes (Shapes Constraint Language, SHACL), spécifiées par le Consortium World Wide Web
(World Wide Web Consortium, W3C), d’autre part. Il a été décidé de continuer à employer la langage UML
car il a su prouver ses capacités au sein de la famille de documents ISO 19100, il permet une approche basée
sur la modélisation et possède une notation graphique normalisée. Le présent document identifie un sous-
ensemble du langage UML pour la spécification des schémas conceptuels. Il spécifie également un profil
UML pour la spécification des schémas conceptuels et présente des dispositions sur la manière d’utiliser le
langage UML et le profil UML pour créer des schémas conceptuels qui constituent le fondement de l’atteinte
de l’objectif d’interopérabilité. En outre, le présent document définit un ensemble de définitions des types de
données de base à utiliser dans des schémas conceptuels.
L’un des buts de la famille de documents ISO 19100 utilisant des schémas conceptuels spécifiés en
UML consiste à fournir une base pour établir des correspondances basées sur des modèles entre des
schémas de codage tels que ceux définis dans l’ISO 19118, ainsi qu’une base pour créer des spécifications
d’implémentation destinées à des profils d’implémentation dans d’autres environnements variés.
Le présent document décrit le métamodèle général d’utilisation de l’UML dans le cadre des documents
ISO relatifs aux informations géographiques. Les aspects ayant spécifiquement trait à la modélisation des
schémas d’application sont décrits dans l’ISO 19109.
Conformément aux Directives ISO/IEC, Partie 2, 2021, Principes et règles de structure et de rédaction des
documents ISO et IEC, dans les normes internationales le signe décimal est une virgule sur la ligne. Toutefois,
la Conférence Générale des Poids et Mesures a adopté à l’unanimité, lors de sa réunion de 2003, la résolution
[5]
suivante: « Le séparateur décimal doit être soit un point sur la ligne soit une virgule sur la ligne ». En
pratique, le choix entre ces alternatives dépend de l’usage courant dans la langue concernée. Dans les
domaines techniques de la géodésie et de l’information géographique, l’usage du point décimal est habituel,
dans toutes les langues. Cette pratique est utilisée tout au long du présent document.
Le nom et les coordonnées de l’autorité de mise à jour du présent document sont disponibles sur
www.iso.org/maintenance_agencies.

vii
Norme internationale ISO 19103:2024(fr)
Information géographique — Langage de schéma conceptuel
1 Domaine d’application
Le présent document spécifie des dispositions pour l’utilisation d’un langage de schéma conceptuel dans le
contexte de la modélisation d’informations géographiques. Le langage de schéma conceptuel choisi est un
sous-ensemble du langage de modélisation unifié (UML).
Le présent document spécifie un profil UML destiné à la modélisation d’informations géographiques.
Le présent document spécifie un ensemble de types de données de base à utiliser dans des schémas
conceptuels.
Le présent document a pour type de cible de normalisation les schémas conceptuels décrivant des
informations géographiques.
2 Références normatives
Les documents suivants sont cités dans le texte de sorte qu’ils constituent, pour tout ou partie de leur
contenu, des exigences du présent document. Pour les références datées, seule l’édition citée s’applique. Pour
les références non datées, la dernière édition du document de référence s'applique (y compris les éventuels
amendements).
UML 2.5.1: OBJECT MANAGEMENT GROUP (OMG). Unified Modeling Language (UML) [en ligne]. Version 2.5.1.
Décembre 2017. Disponible à l’adresse suivante: https:// www .omg .org/ spec/ UML/ 2 .5 .1.
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions suivants s’appliquent.
L’ISO et l’IEC tiennent à jour des bases de données terminologiques destinées à être utilisées en normalisation,
consultables aux adresses suivantes:
— ISO Online browsing platform: disponible à l’adresse https:// www .iso .org/ obp
— IEC Electropedia: disponible à l’adresse https:// www .electropedia .org/
3.1
abstraire
éliminer des détails qui ne relèvent pas du domaine d’intérêt
Note 1 à l'article: L’abstraction facilite la compréhension de l’essence d’un concept (3.20) et permet d’appréhender des
notions complexes.
Note 2 à l'article: L’acte d’abstraire est désigné une « abstraction ». Dans le domaine de la technologie de l’information,
le terme « abstraction » représente également le concept d’abstraction (3.4).
3.2
classificateur abstrait
classificateur (3.16) dépourvu d’instances (3.42) directes
Note 1 à l'article: L’UML 2.5.1, 9.2.3.2 exige que chaque instance d’un classificateur abstrait soit une instance d’une de
ses spécialisations.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 9.2.3.2.

3.3
schéma abstrait
schéma conceptuel (3.23) qui n’est pas déployable sans spécification supplémentaire
EXEMPLE Les schémas conceptuels permettant de décrire les caractéristiques spatiales d’entités géographiques
définies dans l’ISO 19107:2019.
Note 1 à l'article: Un schéma abstrait peut être appliqué à de nombreux domaines.
Note 2 à l'article: Un schéma abstrait peut être réalisé par un schéma d’application (3.8).
3.4
abstraction
résultat d’acte qui consiste à abstraire (3.1)
3.5
abstraction
dépendance (3.30) qui lie deux éléments nommés (3.50) ou ensembles d’éléments nommés qui
représentent le même concept (3.20) à différents niveaux d’abstraction (3.45) ou selon différents points de vue
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.7.3.3.
3.6
agrégation
agrégation partagée
association binaire (3.12) qui spécifie une relation partie-tout (3.58) dans laquelle le tout n’est pas
responsable de l’existence de ses parties
Note 1 à l'article: Une partie peut être appartenir à plusieurs touts en même temps.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 9.5.3.
3.7
application
manipulation et traitement de données supportant des besoins d’utilisateurs
[SOURCE: ISO 19101-1:2014, 4.1.1]
3.8
schéma d’application
schéma conceptuel (3.23) de données requis pour une ou plusieurs applications (3.7)
[SOURCE: ISO 19101-1:2014, 4.1.2]
3.9
association
relation (3.63) sémantique pouvant se vérifier entre des instances (3.42) d’un type (3.70) donné
Note 1 à l'article: Une association est également un genre de classificateur (3.16).
Note 2 à l'article: Adaptation de l’UML 2.5.1, 11.5.3.1.
3.10
attribut
propriété (3.61) possédée par un classificateur (3.16) autre qu’une association (3.9)
Note 1 à l'article: Adaptation de l’UML 2.5.1, 9.5.3.
3.11
fonction comportementale
fonction (3.36) qui spécifie un aspect de comportement
Note 1 à l'article: Adaptation de l’UML 2.5.1, 9.9.2.1.

3.12
association binaire
association (3.9) ayant deux extrémités de membre
Note 1 à l'article: L’UML 2.5.1, 11.5.3.1 permet aux deux extrémités de membre d’avoir le même type (3.70).
Note 2 à l'article: Adaptation de l’UML 2.5.1, 11.5.3.1.
3.13
cardinalité
nombre de valeur
EXEMPLE La cardinalité d’une collection de trois valeurs est trois.
Note 1 à l'article: La cardinalité est une caractéristique d’une collection.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 7.5.3.2.
3.14
classe
classificateur (3.16) d’un ensemble d’objets (3.54)
Note 1 à l'article: Adaptation de l’UML 2.5.1, 11.8.3.1.
3.15
diagramme de classe
diagramme de structure dont les principaux symboles dans la zone de contenu sont soit les symboles
de classe (3.14), soit les symboles d’interface (3.43) ou les deux
Note 1 à l'article: Adaptation de l’UML 2.5.1, Annexe A.
3.16
classificateur
classification d’instances (3.42) selon leurs fonctions (3.36)
Note 1 à l'article: Un classificateur est un genre de type (3.70).
Note 2 à l'article: Adaptation de l’UML 2.5.1, 9.2.1.
3.17
jeu de codets
jeu de combinaisons de code
code
liste de codes
résultat de l’application d’un schéma de codage à tous les éléments d’un jeu codé
EXEMPLE Les représentations composées de trois lettres désignant les noms d’aéroport.
Note 1 à l'article: Le terme « code » englobe également le concept défini dans l’ISO 19118:2011, 4.3.
[SOURCE: ISO/IEC 2382:2015, 2121556, modifié — Un terme admis supplémentaire « liste de codes » a été
ajouté, la définition a été modifiée de sorte à utiliser les termes employés à l’Annexe H, la Note 1 à l’article a
été convertie en Exemple, les Notes 2 et 3 à l’article ont été supprimées et une nouvelles Note 1 à l’article a
été ajoutée.]
3.18
commentaire
note
annotation textuelle qui peut être accolée à un ensemble d’éléments
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.8.2.1.

3.19
composition
association binaire (3.12) qui spécifie une relation partie-tout (3.58) dans laquelle le tout est
responsable de l’existence de ses parties
Note 1 à l'article: Une partie ne peut appartenir qu’à un seul tout à la fois.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 9.5.3.
3.20
concept
unité de connaissance créée par une combinaison unique de caractéristiques
Note 1 à l'article: Les concepts ne sont pas nécessairement liés à des langages naturels (3.52) particuliers. Ils sont
cependant soumis à l’influence du contexte socioculturel qui conduit souvent à des catégorisations différentes.
Note 2 à l'article: Il s’agit du concept « concept » tel qu’il est utilisé et désigné par le terme « concept » dans le cadre
du travail terminologique. Il est très différent du concept désigné par d’autres domaines tels que l’automatisation
industrielle ou le marketing.
[SOURCE: ISO 1087:2019, 3.2.7]
3.21
formalisme conceptuel
ensemble de concepts (3.20) de modélisation utilisés pour décrire un modèle conceptuel (3.22)
EXEMPLE Modélisation orientée objet.
Note 1 à l'article: Un formalisme conceptuel peut être exprimé dans plusieurs langages de schéma conceptuel (3.24).
[SOURCE: ISO 19101-1:2014, 4.1.4, modifié — Les exemples ont été remplacés.]
3.22
modèle conceptuel
modèle (3.48) définissant les concepts (3.20) d’un univers du discours (3.72)
Note 1 à l'article: Un modèle peut inclure des relations entre des concepts. Une relation est également un concept.
[SOURCE: ISO 19101-1:2014, 4.1.5, modifié — La note à l’article a été ajoutée.]
3.23
schéma conceptuel
description formelle d’un modèle conceptuel (3.22)
[SOURCE: ISO 19101-1:2014, 4.1.6]
3.24
langage de schéma conceptuel
langage formel (3.37) basé sur un formalisme conceptuel (3.21) destiné à représenter des schémas
conceptuels (3.23)
EXEMPLE UML, EXPRESS, IDEF1X.
Note 1 à l'article: Un langage de schéma conceptuel peut se présenter sous une forme lexicale ou graphique. Plusieurs
langages de schéma conceptuel peuvent être basés sur le même formalisme conceptuel.
[SOURCE: ISO 19101-1:2014, 4.1.7]
3.25
contrainte
condition ou restriction exprimée par un texte en langage naturel (3.52) ou dans un langage lisible
par une machine, afin de déclarer une partie de la sémantique d’un élément ou d’un ensemble d’éléments
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.8.3.1.

3.26
type de données
ensemble de valeurs distinctes, caractérisé par les propriétés de ces valeurs et par les opérations (3.55)
effectuées sur ces valeurs
EXEMPLE Le type de données « Boolean » ayant les propriétés « unordered », « exact » et « non-numeric » ainsi
que les opérations « equal », « not » et « or ».
Note 1 à l'article: Les propriétés des valeurs de types de données sont ordonnées ou non ordonnées, exactes ou
approximatives, numériques ou non numériques et, si elles sont ordonnées, liées ou non liées, comme décrit dans
l’ISO/IEC 11404.
[SOURCE: ISO/IEC 11404:2007, 3.12, modifié — La note à l’article et l’exemple ont été ajoutés.]
3.27
type de données
classificateur (3.16) dont les instances (3.42) se distinguent uniquement par leur valeur
Note 1 à l'article: Adaptation de l’UML 2.5.1, 10.2.1.
3.28
valeur de données
instance (3.42) d’un type de données (3.27)
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.5.3.2.
3.29
définition
représentation d’un concept (3.20) par une expression qui le décrit et le différencie des concepts associés
[SOURCE: ISO 1087:2019, 3.3.1]
3.30
dépendance
relation dirigée (3.32) signifiant qu’un élément unique de modèle ou un ensemble d’éléments de
modèle nécessite d’autres éléments de modèle pour sa spécification ou son implémentation
Note 1 à l'article: Une dépendance désigne une relation (3.63) client/fournisseur entre des éléments de modèle dans
laquelle la modification d’un fournisseur peut impacter les éléments de modèle du client. La sémantique complète du
ou des éléments du client dépend, sémantiquement ou structurellement, de la définition (3.29) du ou des éléments du
fournisseur.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 7.7.1 et 7.8.4.
3.31
désignation
étiquette
représentation d’un concept (3.20) par un signe qui le dénote dans un domaine ou sujet
Note 1 à l'article: Une désignation peut être linguistique ou non linguistique. Elle peut être constituée de différents
types de caractères, mais aussi de signes de ponctuation tels que des traits d’union et des parenthèses, régis par des
conventions spécifiques au domaine, au sujet ou au langage.
Note 2 à l'article: Une désignation peut être un terme, incluant les appellations, un nom propre ou un symbole.
[SOURCE: ISO 1087:2019, 3.4.1, modifié — Un terme admis supplémentaire « étiquette » a été ajouté.]
3.32
relation dirigée
relation (3.63) entre une collection d’éléments de modèle sources et une collection d’éléments de
modèle cibles
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.8.5.1.

3.33
énumération
type de données (3.27) dont les valeurs sont nommées une à une dans le modèle (3.48)
Note 1 à l'article: L’ensemble des libellés d’énumération (3.34) possedé par une énumération est ordonné.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 10.5.3
3.34
libellé d’énumération
valeur de données (3.28) définie par l’utilisateur pour une énumération (3.33)
Note 1 à l'article: Dans ce cas, l’utilisateur est le modélisateur.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 10.5.4.1.
3.35
extension
association (3.9) indiquant que les propriétés (3.61) d’une métaclasse (3.46) sont étendues par un
stéréotype (3.65)
Note 1 à l'article: Adaptation de l’UML 2.5.1, 12.4.1.1.
3.36
fonction
caractéristique
Note 1 à l'article: Adaptation de l’UML 2.5.1, 9.4.3.1.
3.37
langage formel
langage lisible par une machine, ayant une sémantique bien définie
Note 1 à l'article: Une sémantique bien définie est typiquement une sémantique de théorie des modèles.
[SOURCE: ISO/IEC 21838-1:2021, 3.10]
3.38
généralisation
relation dirigée (3.32) taxonomique entre un classificateur (3.16) plus général et un classificateur
plus spécifique
Note 1 à l'article: Le classificateur plus général est appelé le parent ou la superclasse si le classificateur est une classe
(3.14). Le classificateur plus spécifique est appelé l’enfant. La généralisation est dirigée de l’enfant vers le parent.
Les classificateurs qu’il est possible d’atteindre en suivant les généralisations d’un classificateur donné vers les
classificateurs plus généraux sont appelés les généralisations de classificateur. Les classificateurs qu’il est possible
d’atteindre en suivant les généralisations d’un classificateur donné vers les classificateurs plus spécifiques sont
appelés les spécialisations de classificateur.
Note 2 à l'article: Chaque instance (3.42) du classificateur spécifique est également une instance du classificateur
général. Le classificateur spécifique hérite des fonctions (3.36) du classificateur plus général.
Note 3 à l'article: Adaptation de l’UML 2.5.1, 9.2.3.2 et 9.9.7.
3.39
identifiant
séquence de caractères linguistiquement indépendante permettant d’identifier de manière exclusive et
permanente ce à quoi elle est associée
[SOURCE: ISO 19135-1:2015, 4.1.5]

3.40
identité
caractéristique inhérente d’une instance (3.42) qui la distingue de toutes les autres instances
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1865, modifié — Le terme « propriété » a été remplacé par
« caractéristique » dans la définition et la note à l’article a été supprimée.]
3.41
héritage
mécanisme par lequel des entités plus spécifiques intègrent une structure et
un comportement définis par des entités plus générales
3.42
instance
entité individuelle
Note 1 à l'article: Le terme « instance » désigne le même concept que le terme « élément » défini dans
l’ISO/IEC 21838-1:2021, 3.3.
3.43
interface
classificateur (3.16) représentant la déclaration d’un ensemble de fonctions (3.36) et d’obligations
publiques cohérentes qui constituent ensemble un service cohérent
Note 1 à l'article: Une interface spécifie un contrat; l’UML 2.5.1, 10.4.3.1 exige que toute instance (3.42) d’un
classificateur réalisant l’interface remplisse ce contrat. Les obligations associées à une interface prennent la forme
de contraintes (3.25) (telles que des conditions préalables et ultérieures) ou de spécifications de protocole, pouvant
imposer des restrictions de classement sur des interactions par l’intermédiaire de l’interface.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 10.4.3.1.
3.44
mot-clé
mot réservé faisant partie intégrante de la notation UML
Note 1 à l'article: Les mots-clés apparaissent normalement sous forme d’annotations textuelles accolées à un élément
graphique UML ou font partie d’une ligne de texte dans un diagramme UML. Les mots-clés sont présentés entre
guillemets («keyword») et ont donc la même notation que les éléments de modèle stéréotypés (3.65).
Note 2 à l'article: Adaptation de l’UML 2.5.1, Annexe C.
3.45
niveau d’abstraction
indication de la quantité de détails étant hors du domaine d’intérêt
Note 1 à l'article: Un modèle (3.48) ayant un fort niveau d’abstraction possède une quantité relativement faible de détail.
3.46
métaclasse
classe (3.14) dans un métamodèle (3.47)
EXEMPLE La classe « Interface » est une classe dans le métamodèle UML, il s’agit donc d’une métaclasse.
Note 1 à l'article: Adaptation de l’UML 2.5.1, 6.2.
3.47
métamodèle
modèle (3.48) qui définit un langage de modélisation
EXEMPLE Le métamodèle UML.
Note 1 à l'article: Un modèle est une instance (3.42) d’un métamodèle et un métamodèle est une instance d’un méta-
métamodèle.
[15]
Note 2 à l'article: Adaptation du Guide MDA.
3.48
modèle
abstraction (3.4) d’aspects de la réalité
[SOURCE: ISO 19109:2015, 4.15]
3.49
multiplicité
spécification des cardinalités (3.13) valides
EXEMPLE Une instance (3.42) d’une collection dont il est spécifié qu’elle a une multiplicité de « 1.3 » a au moins
une valeur et n’a pas plus de trois valeurs.
Note 1 à l'article: Une multiplicité est la définition d’un intervalle inclusif d’entiers non négatifs commençant par une
limite inférieure et se terminant par une limite supérieure (potentiellement infinie).
Note 2 à l'article: Adaptation de l’UML 2.5.1, 7.5.3.2 et 7.8.8.1.
3.50
élément nommé
élément dans un modèle (3.48) pouvant avoir un nom
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.8.9.
3.51
espace de noms
élément nommé (3.50) qui possède ou importe (ou possède et importe) un ensemble d’éléments
nommés pouvant être identifiés par un nom
Note 1 à l'article: Adaptation de l’UML 2.5.1, 7.8.10.1.
3.52
langage naturel
langage qui est ou a été utilisé activement dans une communauté de personnes et dont les règles sont
principalement déduites de l’usage
[SOURCE: ISO 5127:2017, 3.1.5.02, modifié — La note à l’article a été supprimée.]
3.53
association n-aire
association (3.9) ayant plus de deux extrémités de membre
Note 1 à l'article: Une association ayant trois extrémités de membre est appelée une association ternaire.
Note 2 à l'article: Adaptation de l’UML 2.5.1, 11.5.3.1.
3.54
objet
individu ayant un état et des relations (3.63) avec d’autres individus
Note 1 à l'article: Un objet est l’instance (3.42) d’une classe (3.14).
Note 2 à l'article: Adaptation de l’UML 2.5.1, 6.3.1.
3.55
opération
fonction comporte
...