Académique Documents
Professionnel Documents
Culture Documents
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
28
28
28
29
31
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
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
14
15
16
17
18
18
19
19
20
21
5.1
5.2
23
25
6.1
6.2
7.1
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
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].
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
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
3.1.1
Le schma
3.1.2
Les entits
3.1.3
Les contraintes
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
3.1.5
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
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
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
3.3.2
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.
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.
(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 .
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
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
4.1.1
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());
Composant
dimport/export
Systme B
4.1.2
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.
#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.
4.2
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
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
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.
17
4.2.2
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
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 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:?]
4.2.4
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
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
5.2
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.
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
5.3
5.3.1
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
5.3.3
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.
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
6.2
La spcification de lAIM
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
Modle interprt 1
interprtation des IR
interprtation des IR
Modle de rfrence 1
Modle de rfrence 2
Modle interprt 2
6.2.1
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
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
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.
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
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.
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
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
9.2
9.3
Les utilisateurs
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.
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