EN 12896-1:2016

SLOVENSKI STANDARD
01-januar-2017
1DGRPHãþD
SIST EN 12896:2006
-DYQLSUHYR]5HIHUHQþQLSRGDWNRYQLPRGHOGHO6SORãQLSRMPL
Public transport - Reference data model - Part 1: Common concepts
Öffentlicher Verkehr - Datenreferenzmodell - Teil 1: Gemeinsame Konzepte
Transports publics - Modèle de données de référence - Partie 1: Concepts communs
Ta slovenski standard je istoveten z: EN 12896-1:2016
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EN 12896-1
EUROPEAN STANDARD
NORME EUROPÉENNE
September 2016
EUROPÄISCHE NORM
ICS 35.240.60 Supersedes EN 12896:2006
English Version
Public transport - Reference data model - Part 1: Common
concepts
Transports publics - Modèle de données de référence - Öffentlicher Verkehr - Datenreferenzmodell - Teil 1:
Partie 1: Concepts communs Gemeinsame Konzepte
This European Standard was approved by CEN on 5 May 2016.

CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this
European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references
concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN
member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by
translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management
Centre has the same status as the official versions.

CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania,
Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2016 CEN All rights of exploitation in any form and by any means reserved Ref. No. EN 12896-1:2016 E
worldwide for CEN national Members.

Contents Page
European foreword . 5
0 Introduction . 6
0.1 Rationale for the Transmodel Standard . 6
0.2 Use of the Transmodel Standard . 6
0.3 Applicability of the Transmodel Standard . 7
0.3.1 General . 7
0.3.2 Specification of information architecture . 7
0.3.3 Specification of a database. 8
0.3.4 Specification of an interface . 8
0.4 Conformance statement . 8
0.5 Transmodel origins . 9
0.5.1 ENV 12896 . 9
0.5.2 Titan . 9
0.5.3 SITP and SITP2 . 9
0.5.4 CEN TC 278 WG 3 SG 4 . 9
0.6 Reference to the previous version and other projects and documents. 10
0.6.1 General . 10
0.6.2 SIRI . 10
0.6.3 IFOPT . 10
0.6.4 NeTEx . 10
0.7 Typographic conventions . 10
0.8 Methodology for conceptual modelling . 11
0.8.1 General . 11
0.8.2 Packages . 11
0.8.3 Class diagrams . 13
0.8.4 Classes and attributes . 14
0.8.5 Association relationships . 17
0.8.6 Reflexive association relationship . 17
0.8.7 Composition association relationship . 18
0.8.8 Aggregation association relationship . 18
0.8.9 Generalization association relationship . 19
0.9 Summary of rules for Transmodel representation . 19
1 Scope . 21
1.1 General scope of the Standard . 21
1.2 Functional domain description . 22
1.2.1 Public transport network and stop description. 22
1.2.2 Timing information and vehicle scheduling. 22
1.2.3 Passenger information . 23
1.2.4 Fare management . 23
1.2.5 Operations monitoring and control . 24
1.2.6 Management information . 24
1.2.7 Multi-modal operation aspects . 25
1.2.8 Multiple operators' environment aspects . 25
1.2.9 Personnel management: driver scheduling, rostering, personnel disposition . 25
1.3 Particular scope of this document . 26
2 Normative references . 26
3 Terms and definitions . 26
4 Abbreviations . 29
5 Common concepts domain . 29
5.1 Introduction to the common concepts . 29
5.2 Versions and validity . 31
5.2.1 Introduction. 31
5.2.2 Version and validity – Model overview . 32
5.2.3 Generic entity . 32
5.2.4 Generic version. 33
5.2.5 Generic version frame . 34
5.2.6 Generic validity . 36
5.2.7 Generic delta model . 37
5.3 Responsibility . 38
5.3.1 Introduction. 38
5.3.2 Responsibility – Model overview . 39
5.3.3 Generic responsibility . 39
5.3.4 Responsibility role . 41
5.3.5 Generic organization . 42
5.4 Explicit frames . 43
5.4.1 Composite frame . 44
5.4.2 General frame . 45
5.4.3 Resource frame. 46
5.4.4 Service calendar frame . 47
5.4.5 Other explicit frames . 48
5.5 Generic framework model. 49
5.5.1 General . 49
5.5.2 Generic framework – Model overview . 49
5.5.3 Location Model . 49
5.5.4 Generic grouping - Introduction . 50
5.5.5 Generic point and link. 52
5.5.6 Generic point and link sequence . 55
5.5.7 Generic zone and feature . 56
5.5.8 Generic projection . 58
5.5.9 Generic place . 63
5.5.10 Accessibility . 64
5.6 Reusable Components . 67
5.6.1 General . 67
5.6.2 Reusable components – Model overview . 67
5.6.3 Transport Mode . 68
5.6.4 Transport Submode . 69
5.6.5 Service calendar . 69
5.6.6 Availability condition . 71
5.6.7 Topographic place . 72
5.6.8 Transport organizations . 73
5.6.9 Additional organizations . 74
5.6.10 Generic equipment . 76
5.6.11 Vehicle type . 78
5.6.12 Actual vehicle equipment . 79
5.6.13 Vehicle passenger equipment . 80
5.6.14 Facility . 81
5.6.15 Train . 82
5.6.16 Schematic map . 85
5.6.17 Notice . 86
5.6.18 Service restriction . 87
5.6.19 Alternative name . 88
Bibliography . 132

European foreword
This document (EN 12896-1:2016) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This European Standard shall be given the status of a national standard, either by publication of an
identical text or by endorsement, at the latest by March 2017, and conflicting national standards shall
be withdrawn at the latest by March 2017.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document together with documents EN 12896-2:2016 and EN 12896-3:2016 supersedes
EN 12896:2006.
The series comprises the following documents:
Public transport - Reference data model - Part 1: Common concepts
Public transport - Reference data model - Part 2: Public transport network
Public transport - Reference data model - Part 3: Timing information and vehicle scheduling
Public transport - Reference data model - Part 4: Operations monitoring and control
Public transport - Reference data model - Part 5: Fare management
Public transport - Reference data model - Part 6: Passenger information
Public transport - Reference data model - Part 7: Driver management
Public transport - Reference data model - Part 8: Management information and statistics
Together these create version 6 of the European Standard EN 12896, known as “Transmodel” and thus
replace Transmodel V5.1.
The split into several documents is intended to ease the task of users interested in particular functional
domains. Modularisation of Transmodel undertaken within the NeTEx project has contributed
significantly to this new edition of Transmodel.
In addition to the eight Parts of this European Standard an informative Technical Report (Public
Transport – Reference Data Model – Informative Documentation) is also being prepared to provide
additional information to help those implementing projects involving the use of Transmodel. It is
intended that this Technical Report will be extended and republished as all the eight parts are
completed.
According to the CEN-CENELEC Internal Regulations, the national standards organizations of the
following countries are bound to implement this European Standard: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia,
France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta,
Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
0 Introduction
0.1 Rationale for the Transmodel Standard
Public transport services rely increasingly on information systems to ensure reliable, efficient operation
and widely accessible, accurate passenger information. These systems are used for a range of specific
purposes: setting schedules and timetables, managing vehicle fleets, issuing tickets and receipts,
providing real time information on service running, and so on.
This standard will improve a number of features of public transport information and service
management: in particular, the standard will facilitate interoperability between information processing
systems of the transport operators and agencies by using similar definitions, structures and meanings
for their data for the systems being part of one solution. This applies both to connecting different
applications within an organization, and also to connecting applications between interworking
organizations (for instance, a public authority and a transport operator).
The Transmodel standard presented in this European Standard provides a framework for defining and
agreeing data models, and covers the whole area of public transport operations. By making use of this
European Standard, and of data models derived from it, it will be possible for operators, authorities and
software suppliers to work together much more easily towards integrated systems. Moreover, the
breadth of the standard will help to ensure that future systems’ developments can be accommodated
with the minimum of difficulty.
0.2 Use of the Transmodel Standard
This European Standard presents version 6.0 of the European Standard EN 12896, known as
“Transmodel”. Transmodel 6.0 is a reference standard which provides a conceptual data model for use
by organizations with an interest in information systems for the public transport industry.
As a reference standard, it is not necessary for individual systems or specifications to implement
Transmodel as a whole.
It needs to be possible to describe (for those elements of systems, interfaces and specifications which
fall within the scope of Transmodel):
— the aspects of Transmodel that they have adopted;
— the aspects of Transmodel that they have chosen not to adopt.
Transmodel may prove of value to:
— organizations within the public transport industry that specify, acquire and operate information
systems;
— organizations that design, develop and supply information systems for the public transport
industry.
For an organization within the public transport industry wishing to specify, acquire and operate
information systems, Transmodel may be distilled, refined, or adapted to form a comprehensive data
model for the organization. This will enable the organization to specify its database structures and/or
its system interfaces, in such a way that separate modules can be openly tendered but will still integrate
easily. The organization also has a greater likelihood that information exchange interfaces with external
organizations will be easily achieved.
For an organization wishing to design, develop and supply information systems for the public transport
industry, Transmodel may be distilled, refined, or adapted to form a comprehensive data model for the
product suite. This will enable the organization to develop its products in such a way that separate
modules will integrate easily, but also so that they may be sold separately to clients seeking
Transmodel-compliant systems.
Transmodel is a large and complex model, and allows for great flexibility. Consequently it takes some
skills and resource to apply it effectively in order to develop the physical data model and its
implementations for a particular aspect, e.g. one particular functional domain, such as vehicle
scheduling or fare management or for a particular interface, as between a ticket machine and a
management system, or a particular organizational boundary, as between two connecting transport
operators.
For such situations, Transmodel provides a wider setting and a starting point. The specific elements of
Transmodel have to be refined, attributes and data formats will have to be completed, for a specific sub-
model of the Transmodel data model. The resulting specification, although specific, will facilitate the
built of a coherent overall systems framework, since it will coexist more readily with other Transmodel-
based specifications.
For all of these potential users, the adoption of Transmodel as a basis for development means that a
common language is being used. Thus, users will understand and assess the claims of suppliers better,
and specification developers will be more likely to be working in alignment with each other.
0.3 Applicability of the Transmodel Standard
0.3.1 General
Transmodel may be applied to any framework for information systems within the public transport
industry, but there are three circumstances to which it is particularly suited:
— specification of an organization’s ‘information architecture’;
— specification of a database;
— specification of a data exchange interface.
0.3.2 Specification of information architecture
An ‘information architecture’ refers to the overall structure of information used by an information
system, which is used to determine:
— the structure of data held in system databases;
— the structure of data exchanged across interfaces between systems.
It may be used as a strategic guide to system planning and evolution, and as the basis for the
specification and acquisition of individual systems.
An information architecture made up of independent modules with well-defined interfaces is easier to
maintain. A malfunctioning module can be taken out of service or completely replaced without
disrupting the rest of the system. This is particularly beneficial for online or safety critical systems. The
modules can also be more easily reconfigured on to hardware located elsewhere on the network to fit in
with changes in organizational arrangements for managing the business and data administration
processes.
The information architecture itself should be evaluated from time to time to make sure that it is still
meeting the needs of the organization. Technological changes in communications and computing are
continuously bringing forward new opportunities for evolving the systems supporting the business.
0.3.3 Specification of a database
At a more technical level, an organization’s systems will have a collection of data in one or more
databases, which may be associated with individual applications or may be common to many
applications.
In either case, Transmodel can serve as a starting point for the definition of a database schema, which
will be used for the physical implementation of databases. Whether applications access a common
database built to this schema, or have their own databases and exchange data built to consistent
schemas, the use of an overall reference data model assists integration.
Technical constraints (such as memory capacity restrictions of smart cards) may affect the detail and
complexity of the data models that can be used in particular data storage devices. Transmodel does not
itself specify a level of detail to adopt.
0.3.4 Specification of an interface
Public transport organizations may require different applications to exchange data with each other.
Also, public transport organizations may exchange data with other organizations. In either case, the
reference data model can be used to help design the interfaces.
Again, technical constraints (such as bandwidth limitations of radio communications links) may affect
the detail and complexity of the data models that can be used for particular interfaces. Transmodel does
not itself specify a level of detail to adopt.
0.4 Conformance statement
A specification which cites Transmodel needs to include comparisons of the specification against the
Transmodel reference data model in at least two conformance levels:
— level 1 (the global level) identifies which data domains within the specification are drawn from the
Transmodel data domains, and which are not;
— level 2 (the detailed level) compares the data model within the specification against the
Transmodel entities.
The level 1 conformance statement should be presented as a table based on one of the following:
— the Transmodel data domains as described in the normative part of the document: description of
the network, versions/validity/layers, tactical planning components, vehicle scheduling, driver
scheduling, schedules and versions, rostering, personnel disposition, operations monitoring and
control, passenger information, fare collection, management information, multi-modal operation,
multiple operators’ environment;
— alternatively, the corresponding UML diagrams as presented in this document.
The level 2 conformance statement shall be presented as a table in which the data concepts used in the
specification are described as:
— “Unmodified”: concepts in the specification which have the same definition, properties and
relationships as in the corresponding Transmodel domain;
— “Modified”: concepts in the specification which are similar to a Transmodel concept but which
differ in the details of certain attributes and/or relationships (e.g. attributes added);
— “Alternative”: concepts or groups of concepts in the specification which model the same concepts as
Transmodel but in a significantly different way;
— “Additional”: concepts in the specification which are not drawn from Transmodel;
— “Omitted”: concepts in Transmodel which are not used in the specification.
0.5 Transmodel origins
0.5.1 ENV 12896
The prestandard ENV 12896 was prepared by the work area Transmodel of the EuroBus project (1992-
1994) and by the DRIVE II task force Harpist (1995). The EuroBus/Transmodel and Harpist kernel team
was established as a subgroup (SG4) of CEN TC278 Working Group 3 (WG3) and led by TransExpert (F).
The results of these projects were based upon earlier results reached within the Drive I Cassiope
project and the ÖPNV data model for public transport, a German national standard. The prestandard
reflected the contents of deliverable C1 of the Harpist task force, published in May 1995, with
modifications resulting from the discussion process in CEN TC278/WG3 between May and October
1995.
The different organizations that have technically contributed to the preparation of the prestandard
ENV 12896 were the partners of EuroBus/Transmodel and the Harpist task force: Beachcroft Systems
(UK), CETE-méditerranée (F), CTA Systems (NL), Ingénieur Conseil Bruno Bert (F), Koninklijk
Nederlands Vervoer (NL), Leeds University (UK), Régie des Transports de Marseille (F), SNV
Studiengesellschaft Verkehr (D), Stuttgarter Straßenbahnen AG (D), TransExpert (F), TransTeC (D) and
VSN Groep (NL).
The sponsors of the project were the European Communities (EC, DG XIII, F/5, Drive Programme, 1992-
94), the French Ministry of Transportation, the Dutch Ministry of Transportation and the German
Federal Ministry of Research and Technology.
0.5.2 Titan
The EC project Titan concerned validation and further development of ENV 12896. The different
organizations that have technically contributed to the Titan project were: CETE-Méditerranée (F), Üstra
(D), OASA (GR), RATP (F), SLTC (F), Salzburger Stadtwerke AG (A), TransExpert (F), TransTeC (D),
Synergy (GR), TRUST EEIG (D).
The sponsoring partner was the French Ministry of Transport (DTT/SAE). The project was co-funded by
the European Communities and some of the partners, in particular the pilot sites – Lyon (F), Hanover
(D) and Salzburg (A).
0.5.3 SITP and SITP2
The French-led project SITP (Système d'Information Transport Public) was sponsored by the French
Ministry of Transport (Direction des Transports Terrestres – DTT), the companies Gemplus (F) and
Setec ITS (F), and the Transmodel Users’ Support Team EEIG (F and D).
SITP built on the prestandard ENV 12896 (issued May 1997) and the results of the EC project Titan
(1996-1998). SITP produced the extensions requested of ENV 12896; these were validated during
1999-2000. A successor project, SITP2, developed the standard further during 2001-2002.
0.5.4 CEN TC 278 WG 3 SG 4
During 2002-2003, CEN continued to convene SG4 of TC 278 WG3 to consider how Transmodel should
be taken forward. It considered responses to previous drafts of Transmodel as well as the work of
SITP/SITP2, the German VDV specifications, and a range of UK projects.
SG4 was led by the UK Department for Transport, with participants from VDV (D), RATP (F), HÜR (DK),
Setec (F), TRUST E.E.I.G. (Transmodel Users’ Support Team) (F and D) and Centaur Consulting (UK).
This group completed the work required for Transmodel v5.1 to be adopted as EN 12896.
Related documentation can be found (in French) at http://www.billettique.fr/spip.php?rubrique18.
0.6 Reference to the previous version and other projects and documents
0.6.1 General
Transmodel was published in 2006 as Transmodel V5.1 under the number EN 12896. It has been the
basis for the development of the SIRI, IFOPT and NeTEx standards and specifications.
0.6.2 SIRI
The project SIRI has used EN 12896:2006 as an input to develop standard interfaces as regards
exchanges of real-time data for passenger information. The present document does not intend to
consider the task to establish the link between SIRI data model and the evolution of EN 12896, as at the
time updates of Transmodel are under way, SIRI is proceeding to updates as well. However, possible
extension requests formulated by the SIRI group are intended to be taken into account in the relevant
parts of Transmodel 6.0.
0.6.3 IFOPT
The project IFOPT has used EN 12896:2006 as an input to develop a logical data model for the fixed
objects, relevant for public transport, in particular for stops and points of interest. IFOPT has
established an implicit link to EN 12896:2006 and has been published as EN 28701.
0.6.4 NeTEx
The project NeTEx developed 2009-2013 standard interfaces between systems aiming at the exchanges
of network topology and timetable data based on the models EN 12896:2006 and EN 28701.
One of the tasks of NeTEx was to bring together both models (Transmodel V5.1 and IFOPT). The result
of this task is one single conceptual model covering the domains network topology, timing information
and information on fares.
The part of Transmodel diagrams that relate to the scope of the NeTEx project have been modularised
within NeTEx. In some cases extensions or enhancements of the model have taken place. In order to
keep the coherence between the standards, the NeTEx conceptual diagrams have been incorporated in
the present version of the Public Transport Reference Data Model, generally without changes. The
informative Annex B clarifies the status of the changes in comparison to the NeTEx conceptual
diagrams.
The textual descriptions of this present version of the Public Transport Reference Data Model rely on
one hand on the textual descriptions as in Transmodel V5.1, and on the other hand on the new
descriptions as in NeTEx – Parts 1 and 2 and 3. The informative Annex B indicates the sources of the
textual description.
0.7 Typographic conventions
This Standard makes use of specific typographic conventions that have been adopted for previous and
related Standards and Technical Specifications. Unless the context dictates otherwise:
— Terms wholly in CAPITAL LETTERs refer to a concept which is defined in the Data dictionary in the
relevant part or in a part with a lower number, i.e. capitalised concepts in Part 1 are defined in the
Data dictionary of Part 1, capitalised concepts in Part 2 are defined either in the Data dictionary of
Part 2 or of Part 1, etc. Note that pluralisation of such an entity is indicated by the addition of a
lower case “s”. It is planned that a complete Data dictionary will be issued as a separate document,
updated as additional Parts of this Standard are published;
— Terms wholly in CAPITAL LETTERs and in italic characters appearing mainly in the diagrams
concern abstract classes, i.e. classes which cannot be instantiated directly. They represent common
characteristics of all their sub-classes (specializations);
— Terms wholly in lower case letters refer to the use of those words in their normal everyday context;
— Terms in italic characters are used for explanatory text, particularly related to the context in which
a defined entity may be found;
— Terms in UpperCamelCase are class attributes, such as PersonCapacity, AtCentre, IsExternal, etc.;
— The use of colours helps the reader to link the different classes with similar semantical meaning to
a particular package;
— The word “model” is written either “model”, or “Model”, or “MODEL”. The diagram notes marked
MODEL refer to the corresponding conceptual diagrams of the NeTEx documentation.
0.8 Methodology for conceptual modelling
0.8.1 General
Notation UML 2 is object–oriented modelling notation and is used for describing (specifying,
documenting and visualizing) the conceptual data model in Transmodel. The UML specification has
proved efficient because it facilitates common understanding and use of conceptual data model.
Transmodel uses a notation that bears some features of UML 1 (or E/R conceptual modelling), in
particular as regards the labelling of roles/relationship names.
The following section summarizes the UML features used in Transmodel and illustrates them with
corresponding example diagrams. Diagrams in Transmodel documents are designed with the modelling
tool Enterprise Architect version 10.0 (EA).
0.8.2 Packages
Transmodel EA model is structured into main packages corresponding to the different parts (Part 1,
Part 2, etc) containing sub-packages (models), which group classes according to a common functional
objective. Specific packages “Explicit Frames” in the different parts are created and details of the models
contained in them will be discussed in the relevant parts. The hierarchical modular structure is shown
in Figure 1.
A useful reference may be found at the following address:
http://www.sparxsystems.eu/resources/project-development-with-uml-and-ea/
Figure 1 — Transmodel hierarchy of packages
A prefix in front of each package name indicates the part if the standard where this package has been
introduced and described first, e.g.:
CC stands for common concepts
NT stands for network topology
ND stands for network description
FO stands for fixed objects
TP stands for tactical planning components
TI: timing information and vehicle scheduling
Etc
The classes are grouped together in a package for a specific task or functional purpose. Figure 2 shows
content of the package “generic organization model”, which contains 8 classes. Each class has one and
only one “home” package.
Figure 2 — Package content example
0.8.3 Class diagrams
Class diagram is a visual representation of the structure of a system by showing the system's classes,
their attributes, operations and the relationships among the classes. Class diagram shows how objects
in a system interact with each other. Figure 3 shows an example class diagram from the package
“generic organization model” (described in the common concepts part).
class Complex Diagram Example
CC Generic Organisation MODEL::
CONTACT DETAILS
CC Generic Organisation MODEL::
+ ContactPerson [0.1] CC Generic Organisation MODEL:
ORGANISATION
+for
:TYPE OF ORGANISATION
+ Email [0.1] +classified as
+ Fax [0.1]
+ Description [0.1]
0.*
0.* 0.1
+characterised «UID»
+ FurtherDetails [0.1]
+ LegalName [0.1]
+a classification
by + Id
+ Phone [0.1]
+ Name
for
+ Url [0.1]
+ Remarks [0.1]
+ ShortName [0.1]
«UID»
+ TradingName [0.1]
+ Id
+ Status [0.1]
+ ValidFromDate [0.1]
+in charge of
+ ValidToDate [0.1]
«UID»
+part of
+made up of
+ Id
1 0.*
CC Generic Organisation MODEL::
ORGANISATION PART
+assigned to
0.*
+ Name [0.1]
+in charge of
+delegated to
+ ShortName [0.1]
CC Responsibility Role
+ Description [0.1]
0.* 0.1
MODEL::RESPONSIBILITY
«UID»
ROLE ASSIGNMENT
+ Id
+managing
+delegated to 0.*
CC Generic Organisation
+managed by CC Generic Organisation
+in charge of
0.1 0.*
MODEL::DEPARTMENT
MODEL::ORGANISATIONAL
+part of
ZONE
UNIT
+ Name
CC Generic Organisation MODEL::
1.*
+comprising
«UID» «UID»
ADMINISTRATIVE ZONE
+ Id + Id
+ ShortName [0.1]
+classified as 0.*
«UID»
+ id
+a classification for 0.1
CC Generic Organisation
MODEL::TYPE OF OPERATION
«UID»
+ Id
Figure 3 — Complex diagram example - Generic organization model
0.8.4 Classes and attributes
Classes are represented by boxes that are divided into three parts: the top part contains name of the
class, the middle part contains the class's attributes and the bottom part shows possible operations that
are associated with the class. In Transmodel only the top and middle parts are used for class name and
attributes, respectively.
Figure 4 shows a class diagram containing a single class ORGANIZATION with its attributes.
class Class Example
CC Generic Organisation MODEL::
ORGANISATION
+ Description: MultilingualString [0.1]
+ LegalName: MultilingualString [0.1]
+ Name: normalizedString
+ Remarks: MultilingualString [0.1]
+ ShortName: MultilingualString [0.1]
+ TradingName: MultilingualString [0.1]
+ Status: boolean [0.1]
+ ValidFromDate: date [0.1]
+ ValidToDate: date [0.1]
«UID»
+ Id: OrganisationIdType
Figure 4 — Class example - ORGANIZATION
Table 1 describes some of the elements from the class “ORGANIZATION”:
Table 1 —
...