Outils et mthodes de la norme STEP

(Standard ISO 10303)

Alain Plantec
http://dossen.univ-brest.fr
Lab-STICC/CNRS UMR 6285
Universit de Bretagne Occidentale

ii

Contents
1 Introduction

2 Larchitecture de la norme

3 Le langage EXPRESS
3.1 La premire version dEXPRESS . . . . . . . . . . .
3.1.1 Le schma . . . . . . . . . . . . . . . . . . . .
3.1.2 Les entits . . . . . . . . . . . . . . . . . . . .
3.1.3 Les contraintes . . . . . . . . . . . . . . . . .
3.1.4 Lhritage . . . . . . . . . . . . . . . . . . . .
3.1.5 Les fonctions prdfinies . . . . . . . . . . . .
3.1.6 La rutilisation entre schmas . . . . . . . . .
3.2 Le langage EXPRESS-G . . . . . . . . . . . . . . . .
3.2.1 Les dfinitions . . . . . . . . . . . . . . . . . .
3.2.2 Les relations . . . . . . . . . . . . . . . . . . .
3.3 Vers une deuxime version du langage . . . . . . . . .
3.3.1 La spcification du comportement . . . . . . .
3.3.2 Un schma EXPRESS pour dcrire EXPRESS

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.

5
5
5
6
6
6
7
8
8
9
9
9
9
10

4 Mise en uvre des schmas EXPRESS

4.1 Lchange des donnes . . . . . . . . . . . . . . . .
4.1.1 Les processus dchange . . . . . . . . . . .
4.1.2 Le format des fichiers STEP . . . . . . . . .
4.2 Une interface logicielle pour le partage des donnes
4.2.1 La mise en uvre . . . . . . . . . . . . . . .
4.2.2 La gestion des instances . . . . . . . . . . .
4.2.3 La description des instances . . . . . . . . .
4.2.4 Larchitecture dune application . . . . . . .

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

13
13
14
14
16
17
18
19
20

.
.
.
.
.
.

22
22
22
24
26
26
26

5 Lenvironnement de modlisation
5.1 Le point de vue fonctionnel . . . . . . . . . . . .
5.2 Le point de vue conceptuel . . . . . . . . . . . . .
5.3 Les modles mis en uvre . . . . . . . . . . . . .
5.3.1 Les ressources intgres . . . . . . . . . . .
5.3.2 Les constructions interprtes . . . . . . .
5.3.3 Les constituants du protocole dapplication
i

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

6 Le processus de construction dun protocole dapplication

6.1 La spcification de lAAM et de lARM . . . . . . . . . . . . . . . . . . .
6.2 La spcification de lAIM . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Les processus dintgration et dinterprtation . . . . . . . . . . .

28
28
28
29

7 La validation dun protocole dapplication

31

8 Les environnements STEP

33

9 En conclusion
9.1 Les points forts . . . . . . . . . . .
9.1.1 Lindpendance de la norme
9.1.2 Le langage EXPRESS . . .
9.2 Les points faibles . . . . . . . . . .
9.3 Les utilisateurs . . . . . . . . . . .

35
35
35
35
36
36

ii

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

List of Figures
2.1

Larchitecture de STEP

. . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1
3.2
3.3
3.4

Une hirarchie complexe . . . . . . . . . . . . . .

La rutilisation entre chmas . . . . . . . . . . . .
La reprsentation des dfinitions en EXPRESS-G
La reprsentation des relations en EXPRESS-G .

4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10

Les processus dchange par fichier STEP . . . . . . . . . . . . . . . . . .

Instanciation de deux entits complexes . . . . . . . . . . . . . . . . . . .
Une instance dfinissant un contexte . . . . . . . . . . . . . . . . . . . .
Reprsentation dune SDAI gnrique et dune SDAI spcialise . . . . .
Cration dune instance avec une SDAI gnrique . . . . . . . . . . . . .
Cration dune instance avec une SDAI spcialise . . . . . . . . . . . . .
Traitement sur un ensemble dinstances avec une SDAI gnrique en C .
Traitement sur un ensemble dinstances avec une SDAI spcialise en C++
Reprsentation en EXPRESS-G du schma SDAI_dictionary_schema . .
Larchitecture dune application qui utilise la SDAI . . . . . . . . . . . .

14
15
16
17
18
18
19
19
20
21

5.1
5.2

Une prsentation du formalisme IDEF0 . . . . . . . . . . . . . . . . . . .

Une spcification formelle dun attribut EXPRESS . . . . . . . . . . . . .

23
25

6.1
6.2

La rutilisation de ressources conceptuelles pour le dveloppement dun AP 29

Reprsentation du processus dinterprtation dun AIM en IDEF0 . . . .
30

7.1

Le traitement des tests abstraits . . . . . . . . . . . . . . . . . . . . . . .

32

8.1

Un environnement STEP . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

iii

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

4
7
11
12
12

iv

Chapter 1
Introduction
Le standard STEP1 est la norme ISO 10303 labore par le sous-comit ISO TC 184/SC4.
Lobjectif de cette norme est de permettre aux applications informatiques industrielles
dchanger et de partager des donnes indpendamment des spcificits des diffrents
systmes informatiques changeant ou partageant des informations [ISO94a].
Les travaux de normalisation comprennent dune part le dveloppement dune technologie fournissant des mthodes et outils informatiques neutres pour la description, la
validation et la manipulation des informations de dfinitions de produits, et dautre part,
la spcification de modles de donnes standards, appels protocoles dapplication et
organiss par mtiers industriels. Ces protocoles dapplication sont dvelopps dans le
cadre strict de la technologie STEP. Ils sont spcifis dans le langage de modlisation
EXPRESS [ISO94b] et constituent une librairie de concepts rutilisables pour dvelopper des modles de donnes dans diffrents secteurs industriels [Bou95a]. Les protocoles
dchanges et de partages des donnes dfinissent un format neutre dchange de donnes
[ISO94c] et une interface standard daccs aux donnes [ISO94d].
La nature de STEP est double. En tant que norme ISO dont la finalit est la standardisation de la reprsentation des produits, elle sadresse principalement aux groupes industriels dont le processus utilise les techniques de CAO ou CFAO. En tant que technologie,
STEP prsente un champ dutilisation beaucoup plus large puisquelle peut sappliquer
dautres informations que les donnes de dfinition de produits [Aa94].
Les travaux concernant la norme STEP sont mens depuis 1983 par lISO, le secrtariat
tant assur par le NIST2 . Cet effort de standardisation sest rapidement internationalis
avec notamment la participation de PROSTEP en Allemagne et de lassociation GOSET
en France. Lactivit amricaine, (celle du PDES3 et du NIST) demeure prpondrante.
Les travaux de normalisation sont toujours trs actifs.
La suite de ce chapitre sintresse plus particulirement la technologie STEP. La premire partie dcrit larchitecture de la norme, la deuxime partie dcrit les principales
1

STandard for the Exchange of Product model data

National Institute of Standards and Technology
3
Product Data Exchange using STEP
2

caractristiques du langage EXPRESS [ISO94b], la troisime partie explicite la mthode de mise en uvre dun protocole dapplication, les quatrime et cinquime parties
dcrivent les mthodes de mise en uvre des schmas EXPRESS, respectivement le format
dchange des donnes [ISO94c], et linterface daccs aux donnes, la SDAI4 [ISO94d].

Standard Data Access Interface

Chapter 2
Larchitecture de la norme
STEP consiste en un ensemble de standards internationaux dont lobjectif est soit la
spcification dune mthode de description, de validation ou de mise en uvre, soit la
dfinition de schmas de donnes standards. Chaque standard compose une partie de la
norme et est dveloppe au sein dune srie. Les sept sries actuellement mises en uvre
sont dcrites dans [ISO94a], la numrotation des parties reflte la structure de la norme :
la partie 1 dcrit la norme ISO 10303 et ses principes fondamentaux,
les parties 11 19 dcrivent les mthodes de description; il sagit de la spcification du langage de modlisation textuel EXPRESS, du langage de modlisation graphique EXPRESS-G et du langage dinstanciation de modles conceptuels
EXPRESS-I,
les parties 21 29 dcrivent les mthodes de mise en uvre; elles consistent en
la spcification du format dchange des donnes, dune spcification neutre de
linterface daccs aux donnes (SDAI) et des spcifications de la mise en uvre de
la SDAI dans des langages cibles tel que C, C++ [Str92] ou IDL [Obj95],
les parties 31 39 dcrivent les mthodes de validation et de tests de conformit
des mise en uvre des modles de donnes standards,
les parties 41 99 dcrivent les ressources intgres gnriques qui sont des schmas de donnes de porte trs gnrale puisque indpendants de tout contexte
dutilisation particulier,
les parties 101 199 dcrivent les ressources intgres dapplication qui regroupent
des schmas de donnes plus spcifiques un ensemble de domaines dapplication,
les parties 201 232 dcrivent les protocoles dapplication qui exploitent les
ressources intgres pour la spcification de modles de donnes spcifiques des
domaines dapplication particuliers.
La figure 2.1, extraite de [War94] schmatise larchitecture technique de STEP. De
par sa finalit, STEP est exploite au travers des protocoles dapplication. Ces modles
conceptuels standards sappuient sur les ressources intgres pour la spcification des
concepts. Les protocoles dapplication sont mis en uvre pour lchange ou le partage
3

des donnes laide du format dchange et de la SDAI. Toutes les ressources standards
et les mthodes de mise en uvre sont dcrites en partie avec les langages EXPRESS et
EXPRESS-G et sont valides suivant les mthodes de test de conformit.

Principes fondamentaux
Mthodes
de description

Protocoles dapplication

Ressources Intgres

EXPRESS

Ressources dapplication

EXPRESS-G

Tests de
conformit

Ressources gnriques
EXPRESS-I
Mthodes de mise en oeuvre
Format
dchange

SDAI

Figure 2.1: Larchitecture de STEP

Chapter 3
Le langage EXPRESS
La norme STEP est compose de plusieurs standards parmi lesquels la spcification du
langage de description de modles de donnes, EXPRESS [ISO94b]. Ce langage joue un
rle central pour la description et la mise en uvre de la norme [Bou95b] : les outils de
la norme et les protocoles dapplication sont dcrits en grande partie avec EXPRESS. Ce
langage est le rsultat dune synthse entre les langages de modlisation de donnes tels
que NIAM et IDEF1X, les constructions impratives des langages de programmation tels
que Pascal, ADA et C++ et certains lments du langage SQL. Le manuel de rfrence
du langage EXPRESS [ISO94b] contient aussi la spcification dEXPRESS-G qui est la
forme graphique dEXPRESS.
La premire version dEXPRESS est, depuis 1994 le standard ISO 10303-11 [ISO94b].
Cette premire version est prsente dans le chapitre 3.1. Depuis, de nombreuses extensions du langage ont t tudies et mises en uvre. Ces extensions ont principalement comme objectifs de permettre lexpression du comportement des donnes [ISO94e, ISO95d] et lexpression de vues logiques dans la description de modles
de donnes [ISO96]. Ces diffrents travaux sont actuellement exploits pour la spcification dune nouvelle version du langage. Les volutions principales du langage sont
prsentes dans le chapitre 3.3.

3.1

La premire version dEXPRESS

EXPRESS est dfini comme un langage de modlisation de concepts et des contraintes

appliques ces concepts. Ce nest pas un langage de programmation, un modle EXPRESS nest pas excutable. Lobjectif est de disposer dun langage pour la description
des donnes et lexploitation automatique de cette description par des outils informatiques. Cet objectif justifie le choix dun langage textuel, spcifi par une grammaire
exploitable par un analyseur syntaxique.

3.1.1

Le schma

Lunit de modlisation des donnes est le schma. Un schma constitue un contexte de

dclaration de constantes, de types, de classes dobjets et de contraintes.
5

3.1.2

Les entits

La description dune classe dobjets ou entit associe un nom dentit un ensemble de

proprits. Les cardinalits attribues ces proprits peuvent tre spcifies par des
aggrgations. De plus, une proprit peut tre dfinie comme obligatoire ou facultative.
Les proprits se dcrivent sous la forme dattributs explicites, drivs ou inverses :
un attribut explicite reprsente une proprit dont la valeur doit tre dfinie lors de
la cration dune instance de lentit,
un attribut driv reprsente une proprit dont la valeur est calcule par
lvaluation dune expression,
un attribut inverse peut tre spcifi dans le cas ou une autre entit est associe
lentit courante par un attribut explicite; un attribut inverse dfinit la cardinalit
de lassociation dans le contexte de lentit courante.

3.1.3

Les contraintes

EXPRESS permet la spcification de contraintes. Il est ainsi possible de contraindre

individuellement ou globalement le domaine de valeur des attributs, et des instances
dentits :
une contrainte dunicit est spcifie dans le contexte de la dfinition dune entit; elle spcifie un ensemble dattributs pour lesquels il est invalide de crer deux
instances ayant les mmes ensembles de valeurs,
une contrainte de domaine est spcifie dans le contexte de la dfinition dun type
ou dune entit; elle contraint le domaine de valeur dun type ou dun attribut dune
instance; elle est vrifiable individuellement sur chaque entit,
une contrainte globale est spcifie dans le contexte dun schma; elle exprime une
contrainte portant sur lensemble des instances dune ou de plusieurs entits du
schma.
Pour la spcification des contraintes et du calcul des attributs drivs, EXPRESS
dispose dun langage procdural qui autorise lutilisation des oprateurs classiques de
construction dexpression arithmtiques et logiques, des instructions classiques telles que
laffectation, une instruction conditionnelle et plusieurs instructions itratives. Les traitements procduraux peuvent tre dcrits dans des procdures ou des fonctions.

3.1.4

Lhritage

Une entit peut hriter dune ou de plusieurs autres entits. Un sous-type hrite de toutes
les proprits et contraintes locales de ses super-types. De plus, les contraintes globales
qui sappliquent aux super-types, sappliquent aussi aux sous-types. Un sous-type peut
redfinir un attribut hrit. Il est notamment possible de redfinir un attribut explicite
en attribut driv, sa valeur pouvant tre calcule dans le contexte du sous-type. Cette
redfinition doit cependant toujours respecter les contraintes dfinies dans le super-type.
6

ENTITY flotteur ABSTRACT SUPERTYPE

OF (ONEOF((ONEOF(bathy, syscan) AND (diag ANDOR tx)), (surdrif
AND tx)));
message_len : integer;
END_ENTITY;
ENTITY bathy SUBTYPE OF (flotteur);
balises : array[1:4] of integer;
END_ENTITY;
ENTITY syscan SUBTYPE OF (flotteur);
balise : integer;
END_ENTITY;
ENTITY surdrif SUBTYPE OF (flotteur);
balises : array[1:4] of OPTIONAL integer;
END_ENTITY;
ENTITY diag SUBTYPE OF (flotteur);
END_ENTITY;
ENTITY tx SUBTYPE OF (flotteur);
END_ENTITY;
Cet ensemble dentits est extrait dun schma qui dcrit diffrents types de flotteurs effectuant des mesures
physiques en milieu marin. Lentit flotteur spcifie le concept abstrait de flotteur. Cette classification montre
une hirarchie dentits complexes, spcifie par la dfinition des sous-types de flotteur. Un flotteur bathy est
aussi soit un diag, soit un tx, soit les deux. Un flotteur syscan est aussi soit un diag, soit un tx, soit les deux.
Un flotteur surdrif est aussi obligatoirement un tx.

Figure 3.1: Une hirarchie complexe

Une spcificit du langage EXPRESS est la possibilit de contraindre la relation
dhritage dans la dfinition du super-type, par la spcification dune expression pouvant utiliser trois oprateurs dassociation entre le super-type et les sous-types : AND
pour le et, ONEOF pour le ou inclusif et ANDOR pour le ou exclusif. Lalgorithme de
composition est dfini dans [ISO94b]. Ces oprateurs contraignent la composition des
entits au sein de la hirarchie et permet la spcification implicite de nouvelles entits,
compositions boolennes des sous-types. Les entits dcrites dans une telle hirarchie sont
dites entit complexes. Lexemple 3.1 montre la spcification dune hirarchie dentits
complexes.

3.1.5

Les fonctions prdfinies

EXPRESS dispose dun ensemble de fonctions prdfinies. Ces fonctions permettent

deffectuer les calculs arithmtiques et trigonomtriques classiques sur des donnes mais
7

aussi de requrir des informations sur le type des attributs et des variables. Dans cette
seconde catgorie de fonctions est notamment dfinie la fonction TypeOf, qui retourne
lensemble comprenant le nom du type de la variable qui lui est passe en argument, ainsi
que ceux de tous ses super-types.

3.1.6

La rutilisation entre schmas

Un schma peut utiliser dautres schmas, de sorte quil est possible de dcrire des schmas
gnraux, destins tre rfrencs ou spcialiss par dautres schmas plus spcifiques.
Comme le montre lexemple 3.2, la rutilisation des types, fonctions et entits peut
sexprimer de deux manires conceptuellement distinctes, soit par utilisation, soit par
rfrence. Lutilisation sexprime par le mot cl USE et la rfrence par REFERENCE.
Ces deux possibilits de rutilisation se distinguent par la manire dont sont considres les entits dfinies dans le schma utilis ou rfrenc par le schma qui utilise ou
rfrence :
dans le cas de lutilisation les entits spcifies dans le schma utilis peuvent tre
exploites indpendamment, soit directement, soit par hritage, soit comme type
dun attribut; le statut des lments (types, fonctions, contraintes ou entits) utiliss
est identique celui des lments spcifis dans le schma qui utilise,
dans le cas de la rfrence, les entits spcifies dans le schma rfrenc ne peuvent
tre exploites que dans le contexte dune autre entit, comme type dun attribut.
Lutilisation est introduite pour faciliter la redfinition et lenrichissement des schmas.
De ce fait, lutilisation est souvent lie lhritage. La rfrence est plus particulirement
lie lassociation dentits : les entits et les types rfrencs sont les types des attributs
des entits construites par association.

3.2

Le langage EXPRESS-G

EXPRESS-G est un formalisme graphique utilis pour la reprsentation dun sousensemble des constructions du langage EXPRESS. Un schma peut tre spcifi en
EXPRESS-G indpendamment dune dfinition textuelle en EXPRESS. Cependant,
la spcification des contraintes et du calcul des attributs drivs est impossible en
EXPRESS-G. Le langage comprend trois catgories de symboles graphiques :
1. les dfinitions sont utilises pour reprsenter les types simples, les types nomms,
les types construits et la dclaration des schmas,
2. les relations sont utilises pour reprsenter les relations entre dfinitions,
3. les compositions permettent aux schmas dtre reprsents sur plusieurs pages.
Ces symboles peuvent tre utiliss pour reprsenter les lments constitutifs dun schma.
Ces spcifications sont alors dites de niveau entit. Les relations de dpendance et de
rutilisation entre schmas sont elles reprsentes par des spcifications dites de niveau
schma. La suite de cette partie prsente les caractristiques principales de ce langage.
La spcification complte est donne dans [ISO94b].
8

3.2.1

Les dfinitions

Une dfinition est reprsente par une boite. Le nom du type ou du schma reprsent
est indiqu dans la boite. Comme le montre la figure 3.3, le style de cette boite diffre
suivant le type reprsent, notamment par la nature du trait (pointill ou plein).
Les dfinitions de fonctions, de procdures ou de contraintes ne peuvent pas tre
reprsentes en EXPRESS-G.

3.2.2

Les relations

Une relation est spcifie par une ligne. Le style de la ligne varie suivant la nature de la
relation. Une ligne discontinue est utilise pour relier un attribut facultatif son entit.
Une ligne trait pais est utilise pour la relation dhritage. Toutes les autres relations
sont spcifies par une trait continu simple. La direction de la relation est indique par
un cercle. Par exemple, pour un trait reliant une entit un de ses attributs, un cercle
est dessin du cot de la boite qui reprsente lattribut. Pour la relation dhritage, le
cercle est spcifi du cot des sous-types.
Comme le montre la figure 3.4, une relation peut tre annote pour notamment prciser les cardinalits dans le cas daggrgations ou dattributs inverses, pour qualifier la
relation dhritage ou pour indiquer le nom dun attribut.

3.3

Vers une deuxime version du langage

Une premire proposition dvolution dEXPRESS vers une deuxime version standard
est dcrite dans [ISO97]. Les volutions remarquables sont principalement, la possibilit
dassocier un comportement aux entits dun schma et une proposition de normalisation
dun schma EXPRESS qui dcrit les langages EXPRESS et EXPRESS-G.

3.3.1

La spcification du comportement

La spcification du langage introduit les concepts daction, dvnement et de raction. Un

schma ne consiste plus exclusivement en la spcification de donnes et de contraintes. La
deuxime version dEXPRESS considre un schma comme la spcification dun ensemble
dobjets inter-ractifs.
Une action spcifie un ensemble de modifications apportes la base de donnes. Une
action est une suite dinstructions EXPRESS ventuellement associe des pr ou post
conditions. Une action peut crer, supprimer ou modifier les instances des entits dun
schma.
Le comportement des entits dun schma sexprime sous la forme dvnements et de
ractions ces vnements. Un vnement peut tre dclench explicitement ou implicitement lorsque quune condition spcifie dans la dclaration de lvnement est vrifie.
On distingue les vnements globaux des vnements locaux :
9

 un vnement global est dfini relativement un schma; une occurrence

dvnement global est mise toutes les instances de toutes les entits du schma;
du point de vue dun schma, la provenance dun vnement global est soit interne
soit externe suivant que la description de son dclenchement (dans la spcification
dune action ou dune raction) appartienne ou non au schma,
un vnement local est dfini relativement une entit; une occurrence dvnement
local est mise par une instance et vers une ou plusieurs autres instances de lentit;
il sagit alors dun vnement interne; une occurrence dvnement local peut aussi
tre mise par une instance vers le schma, il sagit alors dun vnement externe.
Une raction un vnement est dfinie relativement une entit et consiste en la
rfrence aux vnements dclencheurs et en la spcification du comportement. Une
raction peut soit excuter un ensemble dinstructions, soit mettre des vnements.

3.3.2

Un schma EXPRESS pour dcrire EXPRESS

La mise en uvre doutils informatiques qui analysent et exploitent des schmas EXPRESS ncessite la consultation et la mise jour dune reprsentation interne des schmas
analyss. Cette reprsentation interne consiste en des donnes dcrites par un modle
de donnes communment appel mta-modle. Pour faciliter la mise en uvre de ce
mta-modle et surtout favoriser une bonne interoprabilit entre outils, il est ncessaire
de disposer dune spcification commune du mta-modle. Pour ces raisons, la prochaine
version standard du manuel de rfrence du langage intgre la spcification dun ensemble
de schmas dont lobjectif est de dcrire les donnes ncessaires au stockage et lchange
des informations contenues dans un schma EXPRESS.

10

SCHEMA coreWidget;
ENTITY graphic ABSTRACT SUPERTYPE;
name
: STRING;
x,y,w,h
: INTEGER;
END_ENTITY;
END_SCHEMA; coreWidget
SCHEMA widgetContainer;
REFERENCE FROM coreWidget;
ENTITY container ABSTRACT SUPERTYPE;
name
: STRING;
owned_graphics
: LIST [1:?] OF graphic;
END_ENTITY; ...
END_SCHEMA; widgetContainer
SCHEMA tk_widgetContainer;
USE FROM widgetContainer(container);
TYPE tk_border = ENUMERATION OF (tk_top, tk_bottom, tk_left,
tk_right); END_TYPE;
ENTITY tk_container SUBTYPE OF (container);
packing_border : tk_border;
END_ENTITY;
ENTITY tk_inputs;
input_graphic_list : list [0:?] of graphic;
END_ENTITY; ...
END_SCHEMA; tk_widgetContainer
Cet exemple prsente trois extraits de schmas utiliss pour la modlisation des concepts dobjets graphiques
et de conteneurs dobjets graphiques classiquement mis en uvre par les outils de construction dinterfaces
homme-machine. Les objets graphiques lmentaires sont spcifis par le schma coreWidget. Le schma
widgetContainer dcrit les entits conteneurs dobjets graphiques. Ce schma rfrence coreWidget. En
effet, un objet graphique lmentaire ne peut exister que dans le contexte dun conteneur. Le schma
tk_widgetContainer utilise lentit container du schma widgetContainer, lobjectif tant de spcialiser cette
entit pour ladapter la spcification des conteneurs mis en uvre par un outil particulier de construction
dinterfaces graphiques.

Figure 3.2: La rutilisation entre chmas

11

entit

type simple

union de types

numr

schma

type dfini

Pour un type simple, le trait est plein et le trait du cot droit est doubl. Pour un type construit, le trait est
en pointills. Un des traits de cot est doubl, gauche pour une union de types et droite pour un numr.
Un type dfini est reprsent par une boite en pointills. Un schma est reprsent par une boite trait plein,
coup horizontalement. Une entit est reprsente par une boite simple traits pleins.

Figure 3.3: La reprsentation des dfinitions en EXPRESS-G

(1)
entit

nom-attribut

(3)
type simple

type dfini

type simple

sous-type 1

(2)

entit

nom-attribut A[1:10]

(4)
type simple

super-type

1
sous-type 2

Voici quatre exemples de relations reprsentes en EXPRESS-G. (1) reprsente le cas dun attribut de type
simple reli son entit. Le trait est annot avec le nom de lattribut. (2) reprsente un attribut, facultatif
reli son entit. Lannotation prcise le nom de lattribut, laggrgation utilise (en loccurrence A pour
ARRAY ) et les cardinalits. (3) reprsente la relation entre un type dfini et son domaine. (5) reprsente
une relation dhritage entre un super-type et deux sous-types. Lannotation prcise quil sagit dun hritage
ON EOF .

Figure 3.4: La reprsentation des relations en EXPRESS-G

12

Chapter 4
Mise en uvre des schmas EXPRESS
La norme STEP dfinit non seulement une mthode de description essentiellement base
sur le langage EXPRESS mais aussi des mthodes de mise en uvre pour lexploitation
informatique des schmas EXPRESS. Les objectifs principaux de ces mthodes de mise
en uvre sont de dcrire les protocoles dchange et de partage des instances des schmas
entre systmes htrognes. Lchange de donnes seffectue par fichiers dchanges standards et le partage de linformation par une interface logicielle standard dite Interface
Standard dAccs aux Donnes ou SDAI.
Ces deux mthodes de mise en uvre ne sont lheure actuelle dcrites que pour
la premire version standard du langage EXPRESS. La suite de ce chapitre est donc
uniquement corrle cette version du langage.

4.1

Lchange des donnes

Pour la plupart des applications informatiques, une des mthodes les plus couramment
employes pour interagir entre systmes est lchange dinformation par fichier. Cette
mthode est en effet souvent trs satisfaisante car les donnes sont persistantes et peuvent
tre manipules par des systmes et langages htrognes.
Principalement deux approches sont exploites pour la mise en uvre de
linteroprativit entre deux systmes [Weg96, Bou95a] : par une liaison spcifique ou
par une interface standardise :
une interface spcifique est directement adapte au besoins des systmes communicants; pour n systmes communicants, n n interfaces doivent tre dveloppes,
une interface standardise est base sur la rutilisation dun protocole normalis;
pour n systmes communicants, 2 n mises en uvre du protocole normalis sont
ncessaires.
Bien que permettant la mise en uvre de composants dchanges trs efficaces en terme
de rapidit dexcution, la premire solution est souvent problmatique : la smantique
des donnes stockes dans les fichiers est dans la plupart des cas implicite et spcifiquement reconnu par les applications. Les algorithmes de lecture/criture des donnes sont
difficilement rutiliss et maintenus.
13

La norme STEP met en uvre la seconde approche : un format neutre et standard

de reprsentation des informations est spcifi, le langage EXPRESS est utilis pour
dcrire les informations transportes. Chaque fichier dchange constitue une instanciation dun schma EXPRESS. Les avantages principaux de cette mthode sont de favoriser
lintelligibilit des informations contenues dans les fichiers, de diminuer les problmes de
maintenance des systmes communicants et de rendre la mthode dchange indpendante
des spcificits des applications et des systmes.

4.1.1

Les processus dchange

Deux systmes communicants mettent chacun en uvre un composant dimport/export

de donnes. Le schma EXPRESS qui dcrit les donnes changes est partag par les
deux systmes communicants. Il reprsente un consensus sur la dfinition des donnes
changes.
Etant donn le schma EXPRESS, lencodage des donnes est explicitement dcrit
par le document standard [ISO94c]. De plus, les contraintes dcrites dans le schma
EXPRESS peuvent tre vrifies par les composants dimport/export.

SCHEMA flotteurs_rafos;
ENTITY flotteur
END_ENTITY; ...
END_SCHEMA;

Schema EXPRESS
partag

Composant
dimport/export

Systme A

#1=balise(32, Atlantique);
#2=(flotteur(...)syscan(...)diag());
#3=(flotteur(...)syscan(...)tx());
#4=(flotteur(...)surdrif(...)tx());

Fichier dchange STEP

Composant
dimport/export

Systme B

Figure 4.1: Les processus dchange par fichier STEP

4.1.2

Le format des fichiers STEP

La spcification du format dchange STEP est le standard ISO 10303-21 [ISO94c]. Un

fichier STEP contient les instances dun schma EXPRESS auquel il se rfre explicitement. Un fichier est structur en deux sections. La premire section identifie lorigine du
fichier et du schma EXPRESS. La seconde section contient la liste des instances.
Chaque instance possde un identifiant numrique entier unique dans le contexte
dun fichier, le nom de lentit correspondante et une liste de valeurs dattributs. Seules
les valeurs des attributs explicites sont changes. Les valeurs des attributs drivs, les
contraintes et les algorithmes dcrits dans le schma EXPRESS ne sont pas contenus dans
un fichier dchange STEP. La table 4.1 prsente des valeurs valides par type dattribut.
La liste de valeurs dattributs est construite dans lordre dfini par celui des attributs de
lentit EXPRESS correspondante. Le type des valeurs est implicitement exprim par le
format textuel de la valeur. Dans le cas dune valeur dont lattribut correspondant est
14

Types dattribut
Integer
Real
String
Binary
Boolean
Logical

Valeurs possibles
4523
5.456 ou 2.3E2
des caracteres
"12A5E4"
.T. ou .F.
.T., .F. ou .U.

Types dattribut
Enumeration
Aggrgation
Identifiant dinstance
Valeur qualifie
Valeur inexistante
Attribut redfini

Valeurs possibles
.deg_celsius.
(ab,dhf)
#945823
un_type(6)
$
*

Table 4.1: Des exemples de valeurs dattributs contenues dans un fichier STEP
#1=(flotteur(32)
#2=(flotteur(22)
#3=(flotteur(22)
#4=(flotteur(32)
#5=(flotteur(26)

bathy((56,345,2,8)) diag()) ;
syscan(7) diag()) ;
syscan(4) diag() tx()) ;
bathy((76,45,1,16)) tx()) ;
surdrif ((14,$,$,$)) tx()) ;

Cette liste contient des instances des entits prsentes dans lexemple 3.1. Etant donn la relation dhritage
entre lentit flotteur et ses sous-types, la correspondance externe est utilise pour linstanciation des flotteurs.
Par exemple, linstance #1 est une combinaison entre les valeurs dattributs de flotteur, bathy et diag. Il
sagit dun flotteur bathy&diag.

Figure 4.2: Instanciation de deux entits complexes

une union de types (en EXPRESS un type select), il est possible de qualifier explicitement
le type de la valeur. Ceci permet dassurer dans tous les cas un typage fort.
La syntaxe du langage dinstanciation prvoit deux algorithmes pour la cration de la
reprsentation dune instance dont lentit correspondante est un sous-type, la correspondance interne et la correspondance externe :
la correspondance interne est utilise sil ny a quune seule possibilit pour
lordre des valeurs dattributs; dans ce cas, la liste des valeurs de lentit soustype est concatne celle de ses super-types; lordre est donn par la relation
dhritage [ISO94c].
la correspondance externe est utilise sil existe plusieurs possibilits pour lordre
dinsertion des valeurs dattributs; cest le cas lorsque la hirarchie dentits comprend un ou des super-types spcifiant leurs sous-types avec les oprateurs AND ou
ANDOR; la liste des valeurs est alors produite sous la forme dune liste principale
contenant des sous-listes de valeurs; chaque sous-liste est associe un nom dentit
et reprsente une correspondance interne pour cette entit; lordre dinsertion des
sous-listes dans la liste principale peut varier dune instance lautre. Une telle
entit est dite une entit complexe.
Une instance peut constituer le contexte de dfinition dinstances dpendantes. La
dure de vie dune instance dfinit dans un contexte est dpendante de la dure de vie de
15

#1=&scope
#2=button(ok, 150, 5, 30, 15);
#3=entry(e112, 100, 5, 60, 15);
#4=frame(f156, 2, 2, 70, 50);
endscope /#2,#3/
tk_container(ask_path, (#2,#3,#4), .tk_top.);
#5=tk_inputs((#2,#3));
#1 est une instance de lentit tk_container, prsente dans lexemple 3.2. Elle contient un contexte dans
lequel sont dclares une instance de lentit button, une instance de lentit entry et une instance de lentit
frame qui sont des sous-types de graphic. Les instances #2 et #3 sont explicitement exportes. Elles peuvent
ainsi tre rfrences lextrieur du contexte, ce qui est le cas dans linstance #5.

Figure 4.3: Une instance dfinissant un contexte

linstance qui dfinit le contexte. De plus, une instance dclare dans un contexte nest
visible lextrieur du contexte que si elle est explicitement exporte.
La possibilit de crer des contextes peut tre utilise pour traduire des relations de
dpendance entre entits telle que celle de la rutilisation dentits entre schma par la
rfrence (cf. le chapitre 3.1.6 page 8). La norme [ISO94c] prcise que la cration de
contexte est la discrtion de loutil qui cre le fichier dchange. Il ny a donc pas
de rgle de correspondance explicite entre la description des entits et la cration de
contextes. En pratique, cette possibilit est peu utilise et devrait disparatre lors des
prochaines rvisions de la norme STEP.

4.2

Une interface logicielle pour le partage des donnes

Lobjectif de la norme STEP est de pouvoir dcrire et exploiter les donnes de produits
pendant tout le cycle de vie. A chaque phase du cycle de vie correspond un ensemble
de donnes, manipules par des applications et/ou des composants logiciels spcifiques.
Les informations mises jour au cours dune phase du cycle de vie peuvent tre rutilises directement ou indirectement au cours dune autre tape. Il existe essentiellement
deux protocoles pour le passage des informations entre diffrentes tapes du cycle de
vie [Che94] :
selon le protocole squentiel, les informations circulent dune tape ltape suivante
de faon unidirectionnelle,
selon le protocole de partage, toutes les tapes du cycle de vie sont gres de faon
concurrente par des applications ou composants logiciels qui partagent une base de
donnes commune.
Le second protocole est prfrable. En effet, le partage de linformation favorise
ladaptation et linteroprabilit des applications. La principale difficult une telle
organisation est de disposer dune interface standard pour mettre en uvre le partage de
linformation au sein dune base de donnes intgre pour toutes les phases du cycle de
vie [Che94].
16

La norme STEP prvoit un protocole de partage de donnes entre les diffrentes

phases du cycle de vie. Ce protocole est dcrit par la partie 22 [ISO94d] qui spcifie
une interface et le protocole daccs au donnes stockes dans une base de donnes.
Cette interface logicielle est communment appele SDAI1 . Cette spcification est donne
indpendamment des langages et des systmes : le langage EXPRESS est utilis pour
la description des entits structurelles de la SDAI et le comportement de ces entits est
dcrit informellement en langue anglaise.
Les mises en uvre de cette spcification dans des langages de programmation particuliers tel que le C++ [ISO95a], C [ISO95b] ou IDL [ISO95c], sont aussi dcrites.
Cependant, la SDAI est dite neutre car, quelque-soit le langage et le systme physique
de stockage, les donnes manipules par les applications sont accdes au travers de la
SDAI, telle quelles sont dcrites par les schmas EXPRESS qui spcifient ces donnes.
La SDAI dfinit une interface fonctionnelle entre les applications et lenvironnement de
stockage des donnes de sorte quelle permet lindpendance des applications vis vis des
spcificits lies au stockage des donnes.

4.2.1

La mise en uvre

Schmas de lapplication
Gestionnaire de
modle EXPRESS

SCHEMA flotteur_rafos;
ENTITY flotteur;

Gnrateur

message_len : integer;
END_ENTITY;

...

END_SCHEMA;

SDAI gnrique

SDAI spcialise

Gestionnaire de
modle EXPRESS

Interprteur

Reprsentation
interne du schma
de lapplication

class Flotteur : public SDAIAppInst {

public:
Flotteur (); ...
protected:
int message_len; ...
};

Reprsentation
interne du schma
de lapplication

La mise en uvre dune SDAI gnrique contient une reprsentation interne du schma EXPRESS source.
Les fonctions de la SDAI utilisent les informations contenues dans cette reprsentation interne. La mise en
uvre dune SDAI spcialise est gnre partir du schma source. Une reprsentation interne du schma
EXPRESS source est, dans ce cas, exploite par le gnrateur qui produit la SDAI. Par contre, les fonctions
de la SDAI nexploitent pas cette reprsentation.

Figure 4.4: Reprsentation dune SDAI gnrique et dune SDAI spcialise

La norme STEP prvoit deux possibilits pour la mise en uvre dune SDAI. Elle
peut tre soit spcialise, soit indpendante du schma EXPRESS qui dcrit les donnes
manipules (ou schma EXPRESS source) :
1

Standard Data Acces Interface

17

// Construction dune instance de l entit "syscan"

SDAIAppInstanceH appInstH;
appInstH = sdaiCreateInstanceBN(modelH,"syscan");
// Affectation de la valeur 5 a l attribut "syscan.message_len"
const SDAIEntityH itypeH = appInstH>getInstanceType();
const SDAIAttrH atypeH = itypeH>getAttrType("message_len");
appInstH>PutAttr("message_len", atypeH, 5);

Figure 4.5: Cration dune instance avec une SDAI gnrique

// Construction dune instance de l entit "syscan"
SDAISyscanH syscanH = new SDAISyscan(modelH);
// Affectation de la valeur 5 a l attribut "syscan.message_len"
syscanH>set_message_len(5);

Figure 4.6: Cration dune instance avec une SDAI spcialise

une mise en uvre indpendante est dite SDAI gnrique (ou tardive), car elle
permet laccs aux donnes, quelque-soit le schma EXPRESS source; comme le
montre lexemple 4.5, la rfrence aux constructions particulires du schma EXPRESS source seffectue par passage de paramtres aux fonctions de la SDAI,
une mise en uvre spcialise (ou prcoce) est dpendante du schma EXPRESS
source et peut tre automatiquement produite partir du schma EXPRESS source;
comme le montre lexemple 4.6, la rfrence aux constructions particulires du
schma EXPRESS source est explicitement spcifie par le nom des fonctions.

4.2.2

La gestion des instances

Du point de vue de lapplication qui utilise les services dune SDAI, les instances manipules sont accdes et cres dans un modle dcrit par lentit sdai_modle de la
partie 22. A un sdai_modle correspond un schma EXPRESS qui dcrit les donnes
manipules.
Un sdai_modle est cr dans un repository. Un repository tablit une correspondance
entre des sdai_modles et une ressource physique de stockage des donnes tels quune base
de donnes, un fichier ou encore la mmoire.
Un sdai_modle peut partager des donnes avec dautres sdai_modles et ce, quelque
soient leurs repository : une instance peut rfrencer dautres instances appartenant
des sdai_modles diffrents et une instance peut se dupliquer dun sdai_modle un
autre sdai_modle. Une application peut ainsi utiliser les services de plusieurs bases de
donnes au cours dune mme session. Les exemples 4.7 et 4.8 montrent la lecture dun
ensemble dinstances stockes dans un sdai_modle.
18

int main(int argc, char argv[]) {

/ Ouverture dune session, dun repository et dun modele /
SdaiSession session = sdaiOpenSession ();
SdaiRep repo = sdaiOpenRepositoryBN (session, "p21_step_file");
SdaiModel model = sdaiAccessModelBN (repo, "vitac", sdaiRW);
/ Rcupration des balises /
SdaiSet extent = sdaiGetEntityExtentBN (model, "balise");
SdaitIterator itor = sdaiCreateIterator (extent) ;
while (sdaiNext(itor)) { / Pour toutes les balises /
SdaiString aBaliseName = NULL;
SdaiInstance aBalise;
sdaiGetAggrByIterator (itor, sdaiINSTANCE, &aBalise);
sdaiGetAttrBN (aBalise, "name", sdaiSTRING, &aBaliseName);
fprintf (stdout, "%s\n", aBaliseName);
}
sdaiCloseSession ( session ) ;
}

Figure 4.7: Traitement sur un ensemble dinstances avec une SDAI gnrique en C
#include <flotteur_rafos.h>
int main(int argc, char argv[]) {
// Ouverture dune session, dun repository et dun modele
SessionH sessionH = Session:: OpenSession();
RepoH repoH = sessionH>OpenRepoRW("p21_step_file");
ModelH modelH = repoH>getModelRW("vitac");
// Rcupration des balises
SDAIAGGRH(Set,Balise) balisesH;
balisesH = Balise :: GetEntityExtents(modelH);
Iterator <Balise> baliseItor(balisesH) ;
while ( baliseItor .Next()) { // Pour toutes les balises
Balise aBaliseH = baliseItor .GetCurrentMember();
cout << (const char ) aBaliseH>getName() << endl;
}
sessionH>close();
}

Figure 4.8: Traitement sur un ensemble dinstances avec une SDAI spcialise en C++

4.2.3

La description des instances

La description des instances manipules par une SDAI est contenue dans un dictionnaire
dcrit par le schma SDAI_dictionary_schema. Son rle est de dcrire la smantique sta19

tique dun schma EXPRESS. Il contient la dfinition des concepts de schma, de type,
dentit et dattribut EXPRESS. Sa mise en uvre permet la SDAI de disposer de la description des objets quelle manipule. Ainsi, toute instance manipule par une SDAI peut
accder sa propre description et indirectement la description du schma EXPRESS
qui la spcifie. La figure 4.9 montre une reprsentation simplifie en EXPRESS-G du
schma SDAI_dictionary_schema.

L[0:?]

defined type

L[0:?]

where
rule
S[0:?]

schema
definition

S[0:?]

entity
definition

super-types

underlying
type

L[0:?]

simple type

L[0:?]

attribute

aggregation

L[1:?]
uniqueness
rule

constructed
type

S[0:?]

Un schma est associ un identifiant et contient la spcification de types dfinis et dentits:

Un type dfini se caractrise par un nom associ un type sous-jacent ou domaine et une liste de
contraintes locales. Le domaine du type est soit un type simple (integer, real, string, binary, logical
ou boolean), soit un type aggregation (list, set, bag ou array), soit un type construit (enumeration ou
select), ou soit un autre type dfini.
Une entit se caractrise par un nom, la liste de ses contraintes locales (where rule), la liste de ses
super-types, la liste de ses attributs et la liste des rgles dunicit (uniqueness rule) appliques aux
attributs de lentit ou de ses super-types.

Figure 4.9: Reprsentation en EXPRESS-G du schma SDAI_dictionary_schema

4.2.4

Larchitecture dune application

Comme le montre la figure 4.10, la SDAI est classiquement exploite par une application
comme une couche horizontale ddie la gestion des lectures et des critures des donnes
dans ou depuis un ou plusieurs repository. Une application qui utilise les services de la
SDAI accde aux donnes stockes dans les repository ouverts par la session courante.
Les donnes de lapplication peuvent tre lues ou modifies alors que les donnes du
dictionnaire ne sont accessibles quen lecture. Les donnes de session sont mises jour
par les fonctions de la SDAI pour le maintien de sa cohrence interne.

20

Application
Interface de la SDAI

Donnes de session

Repository
Donnes de lapplication

Donnes du dictionnaire

Figure 4.10: Larchitecture dune application qui utilise la SDAI

21

Chapter 5
Lenvironnement de modlisation
La norme STEP constitue principalement un environnement comprenant les mthodes et
les outils pour la spcification et la mise en uvre de schmas de donnes. Lobjectif est
de fournir des schmas de donnes standards suffisamment consensuels pour recouvrir le
besoin de tous les utilisateurs potentiels. La description dun schma de donnes standard
est un protocole dapplication. Chaque protocole dapplication constitue une partie de la
norme et comprend des spcifications formelles dans le langage EXPRESS et informelles
pour lexplication du sens et le rle des modles de donnes.
Lenvironnement de modlisation de STEP autorise la spcification des donnes par des
modles fonctionnels et des schmas conceptuels [Dan93]. Du point de vue fonctionnel, les
donnes sont dcrites par rapport aux fonctionnalits qui les exploitent. Les dfinitions
de donnes sont ainsi exprimes dans leur contexte dutilisation. Les notations utilises
ce niveau sont semi-formelles telles que IDEF0 [Fed93a]. La signification standard des
donnes ncessaires aux fonctionnalits est dfinie au niveau conceptuel sous la forme de
schmas EXPRESS [ISO94b].

5.1

Le point de vue fonctionnel

La reprsentation de la signification de types de donnes ncessite la comprhension de

leurs contextes dutilisation. La dfinition de ce contexte comprend la dfinition des
fonctions ou activits et des flots de donnes exploites ou produites par ces fonctions.
Linformation exploite par chaque activit constitue un groupe de donnes fonctionnel qui identifie les donnes qui sont transformes, les donnes qui sont produites par ces
transformations et les autres donnes ncessaires lexcution des fonctions. Le formalisme utilis est le langage graphique IDEF0 [Fed93a]. Un exemple de schma IDEF0 est
prsent par la figure 5.1.

5.2

Le point de vue conceptuel

Un protocole dapplication reprsente un schma de donnes dont la signification doit

tre consensuelle et correctement comprise par tout utilisateur potentiel. Ceci implique
un accord sur la signification des donnes, sur lutilisation qui est faite du langage de
22

Controle

Entres

Nom de
fonction A

Sortie

Nom de
fonction B
Ressources

Appel
externe

Cet exemple montre deux reprsentations de fonctions en IDEF0. Chaque reprsentation comprend le nom de
la fonction encadre. Les donnes en entre sont transformes alors que les donnes en sortie sont produites par
la fonction. Les donnes de contrle sont ncessaires lexcution de la fonction. Les ressources reprsentent
des outils utiliss et les appels externes sont des rfrences des fonctions dcrites dans un autre modle
fonctionnel.

Figure 5.1: Une prsentation du formalisme IDEF0

modlisation et sur les schmas conceptuels construits pour expliciter la signification des
donnes avec le langage de modlisation choisi [Dan93].
Les lments conceptuels dfinis dans STEP pour la description de la signification
des informations sont spcifis dans un schma conceptuel. Un schma conceptuel est un
rseau de concepts et de relations entre ces concepts. Lensemble des lments conceptuels
utiliss dans un schma conceptuel comprend le concept, la relation et la proprit :
un concept est une catgorie dobjets, dvnements ou dtats qui peut tre clairement spcifie par une identifiant unique; un concept peut tre soit indpendant soit
dpendant dun autre concept; un concept peut tre construit par la composition
dautres concepts,
une relation est reprsente dans un concept par un lien vers un autre concept; le
rle dcrit les occurrences dun concept qui participe une relation; une association
est un concept prsentant au moins deux relations,
une proprit reprsente un aspect caractristique dun concept dcrit qualitativement et quantitativement, un domaine est la spcification des valeurs autorises
pour une proprit; des contraintes peuvent tre utilises pour cette spcification,
Le langage de conception utilis par STEP pour reprsenter les lments conceptuels
est le langage EXPRESS et son sous-ensemble graphique EXPRESS-G. Ces deux langages
sont dcrits par une norme ISO [ISO94b].
La correspondance entre les lments conceptuels et les constructions
dEXPRESS est tablie pour spcifier lutilisation de ce langage pour la reprsentation des lments conceptuels. Lapplication stricte de cette correspondance est fondamentale dans le cadre de la standardisation de schmas de donnes. Cette correspondance
est dcrite formellement par la norme, en EXPRESS-G dans [Dan93] et en EXPRESS
23

dans [Spi94]. La table 5.1 montre les lments conceptuels pour lesquels une construction
syntaxique du langage EXPRESS permet une correspondance explicite.
Elments conceptuels
schma conceptuel
concept et association
composition de concepts
rle et proprit
contraintes

EXPRESS
schema
entity
hritage ou type select
attribut dune entity
contraintes locales ou globales

Table 5.1: Correspondance entre lments conceptuels et EXPRESS

Un schma conceptuel est reprsent par un ou plusieurs schmas EXPRESS intgrs

par la dclaration de leur interface.
Lorsque la relation inter-schmas U SE F ROM est utilise, lintgration consiste en
la copie des concepts dans le schma qui utilise. Avant la copie, le schma qui utilise est
dit en f orme courte alors quaprs la copie, le schma est dit en f orme longue. Cette
copie peut tre automatise. Elle est spcifie par lalgorithme ShortToLongForm. Aprs
lexcution de cet algorithme il ne subsiste aucune relation U SE F ROM .
Lorsque la relation inter-schmas REF EREN CE F ROM est utilise, les schmas
qui participent la relation ne sont pas modifis par lintgration.
Une entity EXPRESS est utilise pour la reprsentation dun concept. Un attribut
dune entity peut tre utilis soit pour la spcification dune proprit, soit pour la spcification dun rle dune relation.
Une proprit est implicitement spcifie par un attribut dont le type est un type
simple, ou une aggrgation dlments dont le type est un type simple.
Un rle est implicitement dclar par un attribut dont le type est une entity ou une
aggrgation dlments dont le type est une entity.
Un attribut peut reprsenter la fois un rle et une proprit si le type de lattribut
est un type select dont la liste des types rfrence la fois un type simple et un type
entity.
Lextrait du schma EXPRESS dcrit dans [Spi94] et prsent dans la figure 5.2
montre la spcification formelle de la dfinition dun attribut EXPRESS.

5.3

Les modles mis en uvre

La conception dun protocole dapplication standard procde de la mise en uvre de

plusieurs catgories de schmas : les ressources intgres, les constructions interprtes
par domaine dapplication et les schmas constitutifs du protocole dapplication.
Les ressources intgres et les constructions interprtes sont des parties normalises
de STEP. Ils sont le rsultat dun processus dintgration de plusieurs schmas refltant
24

ENTITY attribute ABSTRACT SUPERTYPE

OF (ONEOF((ONEOF(explicit_attribute, derived_attribute) AND (
relationship ANDOR property)),
(inverse_attribute AND relationship)));
attribute_name : name;
defining_entity : EXPRESS_entity;
representation : base_type;
END_ENTITY;
ENTITY explicit_attribute SUBTYPE OF (attribute); END_ENTITY;
ENTITY inverse_attribute SUBTYPE OF (attribute); END_ENTITY;
ENTITY derived_attribute SUBTYPE OF (attribute);
derivation : expression;
END_ENTITY;
ENTITY property SUBTYPE OF (attribute);
WHERE non_entity_type_in_representation : not_entity_in_base_type(
representation);
END_ENTITY;
ENTITY relationship SUBTYPE OF (attribute);
WHERE entity_type_in_representation : entity_in_base_type(representation);
END_ENTITY;
FUNCTION entity_in_base_type (input : base_type) : boolean;
if ATTRIBUTE.EXPRESS_ENTITY in typeof(input) then
return (true);
else if ATTRIBUTE.EXPRESS_TYPE in typeof(input) then
return (entity_in_base_type(input\express_type.based_on));
else if (ATTRIBUTE.AGGREGATION_TYPE in typeof(input) then
return (entity_in_base_type(input\aggregation_type.element_type));
else ...
end_if; end_if; end_if;
return (false) ;
END_FUNCTION; entity_in_base_type
Dans ce schma, le rle est reprsent par lentit relationship. Un attribut est soit un attribut explicite, soit
un attribut driv, soit un attribut inverse. Un attribut explicite ou driv est aussi soit une proprit, soit un
rle, soit les deux. Un attribut inverse est aussi obligatoirement un rle.

Figure 5.2: Une spcification formelle dun attribut EXPRESS

le besoin dans diffrents domaines dapplication. Ils constituent la source fondamentale
de rutilisation et dintgration des modles de donnes standard.
25

Lexploitation des ressources intgres et des constructions interprtes est un exemple

de rutilisation au niveau conceptuel. Leur mise en uvre par STEP permet de minimiser le problme du recouvrement possible entre plusieurs modles standards et favorise
lintelligibilit, la maintenabilit et lhomognit des diffrents protocoles dapplication
de la norme.

5.3.1

Les ressources intgres

Les ressources intgres ou IR1 sont des schmas EXPRESS constituant des librairies
de descriptions de concepts rutilisables pour plusieurs applications. STEP distingue les
ressources intgres totalement gnriques des ressources gnriques par application.
Les ressources intgres totalement gnriques sont des descriptions de concepts indpendants de toute catgorie dapplications alors que les ressources gnriques par application sont des descriptions de concepts classes par catgorie dapplication.
Les entits EXPRESS dcrites dans les ressources gnriques par application compltent et spcialisent les entits dcrites dans les ressources intgres totalement gnriques
pour amliorer leur adquation des catgories dapplications. Le grain de rutilisation
permi par les IR est principalement celui de lentit.

5.3.2

Les constructions interprtes

Les constructions interprtes ou AIC2 sont spcifies par catgories dapplications et

sont des schmas EXPRESS qui dcrivent des utilisations couramment mises en uvre
des mmes ressources intgres. Lutilisation des AIC permet dviter le recouvrement
entre les protocoles dapplication dune mme catgorie dapplications. Le grain de rutilisation est moins fin que celui permis par les IR puisquil sagit de rutiliser des ensembles dentits inter-dpendants, cette inter-dpendance tant spcifique dune catgorie
dapplications.

5.3.3

Les constituants du protocole dapplication

Un AP est principalement dvelopp sur la base des documents suivants : un modle

fonctionnel, appel modle dactivit, un modle de rfrence, un modle interprt et une
table de correspondances entre les informations contenues dans le modle de rfrence et
les entits quivalentes spcifies dans le modle interprt.
Le modle dactivits ou AAM3 dcrit le contexte dutilisation des donnes dun point
de vue fonctionnel. Ce modle contient la spcification des processus de transformations
de donnes et des flots de donnes en IDEF0 [Fed93a].
Le modle de rfrence ou ARM4 contient la description semi-formelle ou formelle
et la documentation des groupes de donnes fonctionnels. Lensemble de ces descriptions
1

Integrated Resources
Application Interpreted Constructs
3
Application Activity Model
4
Application Reference Model
2

26

compose la spcification des donnes qui doivent tre changes ou partages. Pour
la spcification dun ARM, trois langages de modlisation sont autoriss : EXPRESS,
IDEF1X [Fed93b] et NIAM [NH89]. La terminologie employe est celle du domaine du
protocole dapplication dvelopp.
Le modle interprt ou AIM5 constitue le principal rsultat du processus de mise
en uvre dun protocole dapplication. Il procde dune intgration entre lARM, les
ressources intgres et les constructions interprtes. Un AIM est spcifi avec le langage
EXPRESS. Il constitue le schma de rfrence normalis pour les changes ou le partage
des donnes relatif un domaine dapplication.
La table de correspondance tablit formellement lorigine des composants dun AIM.
Chaque entit et attribut dentit de lAIM est spcifi dans cette table avec son correspondant de lARM. Cette table de correspondance conserve la trace du processus
dintgration dont lAIM est issu.

Application Interpreted Model

27

Chapter 6
Le processus de construction dun
protocole dapplication
Un protocole dapplication ralise le lien entre un besoin exprim par des utilisateurs dune
catgorie dapplications et les mises en uvre informatiques des systmes dinformation.
Lutilisateur, considr comme lexpert du domaine, est le principal intervenant au dbut
du processus de dveloppement dun AP. Lutilisateur tablit les exigences et le vocabulaire lis au domaine. Les intervenants issus des groupes de travail de STEP interviennent
ensuite pour tablir les modles conceptuels cohrents dun point de vue dfinition dun
systme dinformation.
Le processus de dveloppement dun AP commence par la spcification de lAAM qui
dfinit les activits et les flots de donnes caractristiques du domaine dapplications.
Sur la base des groupes de donnes fonctionnels mis en vidence dans lAAM, lARM
est dvelopp pour dcrire plus prcisment les donnes et les contraintes appliques aux
donnes. LAIM est ensuite construit par une intgration entre lARM, les ressources
gnriques et les constructions interprtes.

6.1

La spcification de lAAM et de lARM

La premire partie du dveloppement dun AP consiste en la spcification dun cahier des

charges en langue anglaise. Ce cahier des charges constitue une description informelle
pour laquelle une connaissance approfondie du mtier est fondamentale. Une premire
classification des concepts dcrits est effectue par la mise en vidence des groupes de
donnes fonctionnels. Les processus de traitement de linformation et les groupes de
donnes fonctionnelles spcifiques au domaine sont ensuite formaliss tout dabord en
IDEF0 dans lAAM puis en IDEF1X, NIAM ou EXPRESS dans lARM.

6.2

La spcification de lAIM

Comme le montre la figure 6.1 le dveloppement de lAIM procde dune rutilisation

des ressources intgres et des constructions interprtes de STEP pour rpondre aux
exigences des utilisateurs formules dans lARM. La spcification de lAIM saccompagne
28

de lcriture dune table de correspondance entre les entits de lARM et les ressources et
constructions utilises pour les reprsenter dans lAIM. Les constructions des AIC utilises
sont intgres sans modification alors que les IR peuvent tre intgres par spcification
de sous-types, ajout de nouvelles contraintes et de nouvelles relations. Lintgration des
IR est considre par STEP comme un processus dinterprtation.

11
00
00
11
Rutilisation

Ressources gnriques

Constructions interprtes

Table de
correspondance

Table de
correspondance

Slection des AIC et

Modle interprt 1

Slection des AIC et

interprtation des IR

interprtation des IR

Modle de rfrence 1

Modle de rfrence 2

Modle interprt 2

Figure 6.1: La rutilisation de ressources conceptuelles pour le dveloppement dun AP

6.2.1

Les processus dintgration et dinterprtation

Comme le montre la figure 6.2, la conception dun AIM intervient aprs une analyse
informelle de lAAM et le dveloppement du modle de lARM.
La premire activit est un processus dintgration des AIC. Lobjectif est de slectionner parmi les AIC disponibles, les constructions adquates pour reprsenter le besoin de
lapplication.
La deuxime activit consiste en lanalyse de lensemble des concepts de lARM non
intgrs lors de la premire activit. Lobjectif est de dfinir de nouvelles AIC. Une
nouvelle AIC est dfinie si elle reprsente un besoin conceptuel rutilisable en ltat dans
plusieurs AIM.
La troisime activit est le processus dinterprtation des IR. Elle consiste en lanalyse
de lensemble des concepts de lARM non intgrs lors de la deuxime activit et en
linterprtation des IR pour la reprsentation de ces concepts.
Linterprtation seffectue par une adaptation des entits spcifies dans les IR. Cette
adaptation peut consister en :
la cration de sous-types spcifiques lapplication; un sous-type peut contenir
de nouvelles proprits ou de nouveaux rles, des attributs hrits peuvent tre
redfinis en attributs drivs,
29

AAM

Slection
des AIC

Rsidu de lARM
et de lAAM

Les AIC slectionns

Dfinitions
de nouvelles
AIC

ARM

Rsidu de lARM
et de lAAM

Interprtation
des IR
AIC

Version courte
et
version longue

Nouvelles AIC
IR

AIM

Les IR interprts

Figure 6.2: Reprsentation du processus dinterprtation dun AIM en IDEF0

la spcification de nouvelles contraintes locales ou globales pour limiter le domaine
de validit des valeurs dattribut,
la spcification de contraintes globales pour le contrle de rgles dintgrit de
rfrences.
LAIM est spcifi pendant la quatrime activit tout dabord sous la forme dun
schma dit au format court qui rfrence les schmas contenant les AIC intgrs et les
IR utiliss. Ce schma au format court ne contient donc dans un premier temps que ce
qui est spcifique lapplication. Les AIC et les IR sont ensuite copis dans ce schma
pour la spcification dune version de lAIM dite au format long. Le passage de la forme
courte la forme longue peut tre effectu automatiquement par la mise en uvre de
lalgorithme ShortToLongForm [Pal95].

30

Chapter 7
La validation dun protocole
dapplication
La spcification dun protocole dapplication est une activit danalyse et de conception
trs complexe et trs peu automatise. Les possibilits derreur sont donc nombreuses.
Ce problme est trait par STEP. La norme dfinit les procdures pour la vrification et la
validation des modles. Ces procdures se constituent des mthodes de test de conformit
spcifies dans les parties 31 34 de la norme [ISO92].
Les tests de conformit font partie intgrante dun protocole dapplication et
doivent tre dfinis ds le dbut de sa conception. Chaque constituant dun protocole
dapplication doit tre valid par des experts diffrents de ceux qui lont conu. Les
experts du domaine, de STEP et de la mise en uvre des systmes dinformation interviennent au cours de la validation.
La procdure de validation dun protocole dapplication est base sur la mthode des
tests dits abstraits car indpendants de la mise en uvre de ces tests. Le dveloppement
des tests abstraits est une tche complexe qui nest pas spcifie strictement. La dfinition des tests mettre en uvre est spcifique chaque protocole dapplication. La
norme fournit les guides qui indiquent lapproche mettre en uvre et non la dfinition
exhaustive des tests [PK96].
Le principe dun test abstrait est de spcifier les moyens par lesquels un protocole
dapplication et plus particulirement lAIM, doit tre test. Un test est considr comme
une mise en situation dexploitation dun AIM.
La base dune srie de tests abstraits consiste en la description dune architecture
comprenant un prprocesseur et un postprocesseur, en la description des donnes traiter
et en la spcification des rsultats attendus aprs le traitement des donnes.
Le prprocesseur et le postprocesseur traitent des donnes encodes dans un format
spcifique la srie de tests. Le format spcifique doit tre dcrit. Il peut sagir par exemple dun format textuel que lutilisateur peut directement interprter. Comme le montre
la figure 7.1, les donnes encodes dans ce format sont consommes par le prprocesseur
qui doit produire les donnes correspondantes au format STEP ou bien produire les appels fonctionnels de la SDAI ncessaires linstanciation de lAIM. Le postprocesseur
31

Entres

Analyses

Donnes au
format
spcifique

Ensemble
doprations avec
la SDAI

Prprocesseur

ou
Fichier au
format standard
STEP

Ensemble
doprations avec
la SDAI
ou

Postprocesseur

X X X

Donnes au
format
spcifique

X
Smantique

Syntaxique

Structurelle

Fichier au
format standard
STEP

X X X

Une srie de tests abstraits est traite par une environnement comprenant un prprocesseur et un postprocesseur. Le prprocesseur consomme des donnes dans un format spcifique la srie de tests et produit un
rsultat analys syntaxiquement, structurellement et smantiquement :
lanalyse syntaxique consiste vrifier le produit suivant les rgles de reprsentation des donnes
spcifies par la partie 21 ou suivant les rgles dutilisation des oprations de la SDAI spcifies dans
la partie 22,
lanalyse structurelle consiste vrifier que les donnes sont correctement construites par rapport
lAIM; en particulier, toutes les contraintes globales et locales doivent tre respectes,
lanalyse smantique consiste valider les donnes suivant leur cohrence et leur adquation vis vis
du domaine; lARM est ici plus particulirement exploit.
Le postprocesseur consomme des donnes encodees au format standard STEP ou excute des oprations de
la SDAI. Le produit du traitement consiste en la description des donnes encodes dans le format spcifique.
Pour le postprocesseur, seule lanalyse smantique du rsultat est significative.

Figure 7.1: Le traitement des tests abstraits

doit pouvoir soit lire les donnes au format STEP soit excuter les oprations de la SDAI
et encoder les donnes ainsi consommes au format spcifique.

32

Chapter 8
Les environnements STEP
Lexploitation de la norme STEP dans un systme particulier ncessite au minimum la
mise en uvre de la SDAI. Cette mise en uvre constitue la base logicielle minimale
ncessaire au dveloppement des composants dimport et dexport des donnes encodes
dans le format dchange standard STEP. La production de ces composants est gnralement automatique. Cette possibilit constitue un argument essentiel pour lutilisation
de la norme STEP et en particulier du langage EXPRESS pour la description des donnes [HLG94].
Par la capacit changer des donnes dans un format standard, lutilisation de STEP
est un facteur puissant dintgration inter-applications.
Les environnements STEP industriels actuellement disponibles tel que, par exemple
celui commercialis par la socit STEP Tools1 , se composent dun ensemble doutils
de conception et de gnration de code et dun ensemble de librairies spcifiques aux
systmes et la base de donnes utilise :
les outils de conception sont des diteurs soit graphiques pour la spcification de
schmas EXPRESS-G, soit textuels, pour la spcification de schmas EXPRESS; ces
outils comprennent des gestionnaires de bibliothque de schmas conceptuels, constitus par des butineurs de schmas; un outil de traduction de schmas graphiques
EXPRESS-G peut tre utilis pour la gnration vers une reprsentation quivalente
en EXPRESS,
un ensemble de traducteurs associs des gnrateurs de code peuvent tre utiliss pour au minimum, la gnration de la SDAI spcialise et dun composant de
lecture/criture de fichiers au format standard STEP; les environnements plus complets proposent des gnrateurs pour les interfaces graphiques de consultation/mise
jour des donnes dans la base de donnes et, pour les applications de gestion
dobjets techniques, des interfaces graphiques de visualisation en deux ou trois dimensions des donnes de description de produits,
les descriptions conceptuelles spcifies avec des extensions dEXPRESS telles que
EXPRESS-P ou EXPRESS-X sont exploites par des gnrateurs pour la production de composants plus spcifiques tels que la gestion des donnes dans une base de
1

http://www.steptools.com

33

donnes rpartie, la gnration de vues logiques des donnes ou encore la gnration

de composants de migration de donnes entre deux bases de donnes,
les bases de donnes cibles peuvent tre soit relationnelles, soit orients-objet; elles
sont de toute faon toujours manipules indirectement, par le biais de la SDAI; les
outils proposs sont spcialiss pour des systmes et environnements cibles particulier.

Schma EXPRESS-G

Schma EXPRESS
ENTITY drawing_revision SUBTYPE OF (presentation_set);
revision_identifier : identifier;
drawing_identifier : drawing_definition;
intended_scale : OPTIONAL text;
INVERSE
sheet : SET [1:?] OF drawing_sheet_revision FOR in_sets;
END_ENTITY;

presentation_set

drawing_definition
(OPT)

drawing_revision
(OPT)

string

Schma EXPRESS-X
VIEW our_drawing;
FROM drawing_revision
WHEN TRUE;
VIEW_ASSIGN
id := drawing_revision.revision_identifier;
def := drawing_revision.drawing_identifier;
END_VIEW;

Ensemble de gnrateurs
Gnrateur

Schma logique
pour le SGBD

Structures de donnes
pour la gestion
de la base de donnes

Composant
Composant de
dimport/export consultation/mise jour
de fichiers STEP (i.e. butineur dinstances)

SDAI

SGBD

Librairies
de la SDAI
spcifiques
au SGBD

Composant spcifiques
aux protocoles dapplication
(i.e. visualisation 3D, 2D)

Librairies spcifiques
lenvironnement STEP
Compilateur

Librairies spcifiques
au systme et lapplication

PROGRAMME
Pour la construction dune application, un environnement STEP est exploit ds la phase conceptuelle du
cycle de vie. Les schmas EXPRESS-G, EXPRESS et de ses extensions sont exploits par un ensemble de
gnrateurs qui produisent les schmas logiques des donnes pour le systme de gestion de base de donnes
cibles et des composants logiciels dans le langage de programmation cible, pour principalement, la gestion
des donnes. Ces composants, associs aux composants spcifiquement lis au domaine de lapplication, sont
compils pour produire le programme cible.

Figure 8.1: Un environnement STEP

34

Chapter 9
En conclusion
La norme STEP est mise en uvre pour rpondre au besoin grandissant dchange
dinformation et dinter-oprabilit des applications industrielles. Loriginalit de ce standard ISO est de sintresser non seulement aux moyens techniques mettre en uvre pour
lchange et le partage des donnes, mais aussi la dfinition normalise des informations
changes. Cette normalisation sapplique la spcification du contenant (les schmas
EXPRESS) mais aussi lintgration et linterprtation du contenu des modles de dfinition des donnes. La norme STEP comprend en effet une liste grandissante de schmas EXPRESS standards, normaliss par mtier industriels, les protocoles dapplication.
STEP permet ainsi la rutilisation standard au niveau conceptuel.

9.1
9.1.1

Les points forts

Lindpendance de la norme

La norme STEP est un standard international dvelopp en partie par et intgralement

pour les utilisateurs. STEP est une norme ISO indpendante des fournisseurs doutils
informatiques et des prestataires de services. Cette caractristique assure au standard un
fort niveau dindpendance vis--vis des technologies et de leurs volutions [Lof98].

9.1.2

Le langage EXPRESS

La norme STEP est ouverte, elle est base sur le langage de modlisation EXPRESS
qui peut tre utilis pour tout mtier industriel. De fait, le nombre de protocoles
dapplications standardiss et dutilisateurs de la norme saccrot. Cette vitalit assure
une certaine prennit la norme [Lof98].
Etant donn la nature en partie imprative du langage, EXPRESS permet la spcification de contraintes relativement simplement. Lutilisation de ce langage dans lindustrie
est de plus facilite par lapproche trs pragmatique suivie pour sa dfinition.
EXPRESS est un langage textuel quil est possible danalyser automatiquement, sans
ambiguit, avec un analyseur lexical et syntaxique. De plus, EXPRESS, la SDAI et le
format dchange standard constituent les lments dune technologie trs cohrente. Ces
caractristiques permettent une exploitation automatique des modles et la construction
35

doutils de gnration dapplication : le format dchange valide pour un schma tant

implicitement dfini, les constituants dchange des donnes (comprenant notamment la
SDAI) peuvent tre produits automatiquement partir dEXPRESS.

9.2

Les points faibles

Le processus dinterprtation des protocoles dapplication est dcrit de faon informelle.

Les mmes concepts peuvent tre interprts diffremment dun protocole dapplication
un autre. En consquence, lorsque plusieurs protocoles dapplication standards doivent
tre exploits par une mme application, les difficults dintgration peuvent tre trs
grandes. En effet, la rutilisation conceptuelle ne sopre quau niveau de lentit. Les
conflits de type qui peuvent rsulter des diffrences dinterprtation peuvent aboutir
une impossibilit dintgrer plusieurs protocoles dapplication.

9.3

Les utilisateurs

La technologie dveloppe par STEP est principalement exploite pour la dfinition,

lchange et le partage de la dfinition des donnes de produits industriels dans les domaines de la CAO et de la CFAO. De part sa nature et de part le cot de mise en uvre
des protocoles dapplication standards, les utilisateurs sont en premier lieu, les grands
groupes industriels (General Motors, Boing, Hitachi ou encore Dassault). Pour ces grands
groupes, la gestion cohrente et optimise des informations tout au long du cycle de vie
des produits est un enjeu stratgique fondamental.
Comme le montrent les nombreuses applications de STEP dcrites dans [War98,
EUG94, EUG95], cette technologie peut tre utilise pour la gestion des donnes, dans le
cadre dapplications de natures trs diverses. Notre propre exprience de lutilisation de
STEP, pour la gestion de donnes scientifiques [SYS96b, Pla96, SYS97] ou dans le cadre
dune application plus modeste [SYS96a]1 , confirme ce point de vue.

environ quatre mois ingnieur

36

Bibliography
[Aa94] S. Arbouy and al. STEP Concepts fondamentaux. AFNOR, 1994.
[Bou95a] M. Bouazza. La norme STEP. Herms, Documentation multimdia, 1995.
[Bou95b] M. Bouazza. Le langage EXPRESS. Herms, Documentation multimdia, 1995.
[Che94] R. Chen. The ISO STEP Pilot Product Logistic Support Application Protocal Suite,
Developmental Plan. Technical report, Carderock Division, Naval Surface Warfare
Center, Bethesda, Maryland 20084-5000, 1994.
[Dan93] W. F. Danner. STEP Data Specification Methodology.
TC184/SC4/WG5 N50, 1993.

Technical report, ISO

[EUG94] EXPRESS Users Group, EUG94 Conference Notes, 1994.

[EUG95] EXPRESS Users Group, EUG95 Conference Notes, 1995.
[Fed93a] Federal Information Processing Standard Publication 183, editor. Integration Definition for Function Modeling (IDEF0), FIPS PUB 183. National Institute of Standards
and Technology, December 1993.
[Fed93b] Federal Information Processing Standard Publication 184, editor. Integration Definition for Information Modeling (IDEF1X), FIPS PUB 184. National Institute of
Standards and Technology, December 1993.
[HLG94] Lynwood E. Hines, Craig T. Lanning, and Anthony J. Gradient. Conceptual vs Implementation Schemata in STEP: Religious Argument, Pragmatic Reality or Something
Else? In EUG94 [EUG94].
[ISO92] ISO TC184/SC4/WG6 N29. Part 31: Conformance testing methodology and framework:
general concepts, 1992.
[ISO94a] ISO 10303-1. Part 1: Overview and fundamental principles, 1994.
[ISO94b] ISO 10303-11. Part 11: EXPRESS Language Reference Manual, 1994.
[ISO94c] ISO 10303-21. Part 21: Clear Text Encoding of the Exchange Structure, 1994.
[ISO94d] ISO 10303-22. Part 22: Standard Data Access Interface, 1994.
[ISO94e] ISO TC184/SC4/WG5 WD. PISA Information Modelling Language: EXPRESS-C,
1994.
[ISO95a] ISO 10303-23. Part 23: C++ Programming Language Binding to the Standard Data
Access Interface Specification, 1995.

37

[ISO95b] ISO 10303-23. Part 24: C Programming Language Binding to the Standard Data Access
Interface Specification, 1995.
[ISO95c] ISO 10303-23. Part 24: IDL Programming Language Binding to the Standard Data
Access Interface Specification, 1995.
[ISO95d] ISO TC184/SC4/WG5 N230 WD. The Process Modelling Language EXPRESS-P,
1995.
[ISO96] ISO TC184/SC4/WG5 WD. EXPRESS-X Reference Manual, 1996.
[ISO97] ISO TC184/SC4/WG11 N041 WD. EXPRESS Language Reference Manual, 1997.
[Lof98] David Loffredo. Efficient Database Implementation of EXPRESS Information Models.
PhD thesis, Rensselaer Polytechnic Institute, Troy, New York, May 1998.
[NH89] G. M. Nijssen and T. A. Halpin. Conceptual Schema and Relational Database Design:
A Fact Oriented Approach. Prentice Hall, 1989.
[Obj95] Object Management Group. The Common Object Request Broquer: Architecture and
Specification, revision 2.0, 1995.
[Pal95] M. Palmer. Guidelines for the development and approval of STEP application protocols.
Technical report, ISO TC184/SC4/WG4 N511, 1995.
[PK96] T. A. Phelps and J. D. Kindrick. Guidelines for the development of STEP abstract test
suites. Technical report, ISO TC184/SC4/WG6 N100b, 1996.
[Pla96] Alain Plantec. Utilisation de la norme STEP pour la mise en oeuvre de la structure
daccueil VITAC. Le bulletin technique, SYSECA, 66, rue Brossolette, 92240, Malakoff,
France, 4(3), October 1996.
[Spi94] P. Spiby. EXPRESS Semantic Meta-model for ISO 10303-11. Technical report, ISO
TC184/SC4/WG5 N228, 1994.
[Str92] B. Stroustrup. Le langage C++. Addison-Wesley, 1992.
[SYS96a] SYSECA. Lapplication portdxf. Technical report, SYSECA, 32 quai de la douane,
29200, Brest, France, 1996.
[SYS96b] SYSECA. Lapplication vitac. Technical report, SYSECA, 32 quai de la douane,
29200, Brest, France, 1996.
[SYS97] SYSECA. Lapplication rafos. Technical report, SYSECA, 32 quai de la douane, 29200,
Brest, France, 1997.
[War94] Barbara D. Warthen. STEP Architectures. In PDI 03/1994 [War98], page 7.
[War98] Barbara D. Warthen, editor. Product Data International. Warthen Technology Info.
Services, 1995-1998.
[Weg96] Peter Wegner. Interoperability. ACM Computing Surveys, 28(1), 1996.

38