6 Concepts de définition de type dans le SDL
6.4 Exemples
Grammaire concrète
Les syntaxes des transitions et sauvegardes virtuelles sont définies aux 2.4.6 (départ de procédure virtuelle), 2.6.2 (départ de processus virtuel), 2.6.4 (entrée virtuelle), 2.6.5 (sauvegarde virtuelle), 2.6.6 (transition spontanée virtuelle), 4.10 (entrée prioritaire virtuelle), 4.11 (signal continu virtuel) et 4.14 (entrée et sauvegarde de procédure distante virtuelle).
Les transitions ou sauvegardes virtuelles ne doivent pas apparaître dans les définitions (d'ensemble d'instances) de processus ou dans les définitions (d'instances) de service.
Un état ne doit pas avoir plus d'une seule transition spontanée virtuelle.
Une redéfinition dans une spécialisation marquée après le mot clé redefined peut être définie de manière différente dans d'autres spécialisations, tandis qu'une redéfinition marquée par le mot clé finalized ne doit pas avoir de nouvelles définitions dans d'autres spécialisations.
Une entrée ou une sauvegarde avec <virtuality> ne doit pas contenir <asterisk>.
Sémantique
La redéfinition de transitions/sauvegardes virtuelles correspond étroitement à la redéfinition des types virtuels (voir 6.3.2).
Une transition de départ virtuelle peut être redéfinie en une nouvelle transition de départ.
Une entrée prioritaire ou une transition d'entrée virtuelle peut être redéfinie en une nouvelle entrée prioritaire, une nouvelle transition d'entrée ou une nouvelle sauvegarde.
Une sauvegarde virtuelle peut être redéfinie en une entrée prioritaire, une transition d'entrée ou une sauvegarde.
Une transition spontanée virtuelle peut être redéfinie en une nouvelle transition spontanée.
Une transition continue virtuelle peut être redéfinie en une nouvelle transition continue. La redéfinition est indiquée par le même couple (état, [priorité]) que la transition continue redéfinie. Si plusieurs transitions continues virtuelles existent dans un état, chacune d'elles doit avoir une priorité distincte. Si une seule transition continue virtuelle existe dans un état, la priorité peut être omise.
Une transition d'une transition d'entrée de procédure distante virtuelle peut être redéfinie en une nouvelle transition d'entrée de procédure distante ou en une sauvegarde de procédure distante.
Une sauvegarde de procédure distante virtuelle peut être redéfinie en une transition d'entrée de procédure distante ou en une sauvegarde de procédure distante.
La transformation des transitions d'entrée virtuelles s'applique également aux transitions d'entrée de procédure distante virtuelle.
La transformation des transitions et sauvegardes virtuelles dans les états astérisques est élaborée dans l'étape 14 du 7.1.
sr2 [ss]
[ss]
sr1
[ss]
c2
sr3 [ss]
c1 [ss]
P2
T1007880-93/d25 P1
packagelib
block type B<signal ss(Integer, Real)>
FIGURE 6.4.1/Z.100 Diagramme de progiciel (SDL/GR)
FIGURE 6.4.1/Z.100...[D25] = 7.5 CM (118%)
P1 P2
T1007890-93/d26 sr6 P3
[sig]
sr4 [sig]
sr5 [sig]
c1 use lib/ B; use slib/ sig ;
package Bxlib
block type BX inherits B <sig>
use lib/ B; use slib/ sig ;
FIGURE 6.4.2/Z.100
Diagramme de progiciel avec une clause use (SDL/GR)
FIGURE 6.4.2/Z.100...[D26] = 9 CM (118%)
T1007900-93/d27 [sig]
[sig]
[sig]
B1:B<sig>
c1 c2
v
u
x B2:BX c2
c1
c1 B3:BX c2
use lib /B; use BXlib/BX; use slib /sig;
system S
FIGURE 6.4.3/Z.100
Diagramme de système avec une clause use (SDL/GR) FIGURE 6.4.3/Z.100...[D27] = 9 CM
sr2 [ss]
sr1
[ss]
g2
sr3 [ss]
g1 [ss]
P2
T1007910-93/d28 P1
[ss]
block type B
atleast B
FIGURE 6.4.4/Z.100
Type de bloc avec accès g1 et g2 (SDL/GR) FIGURE 6.4.4/Z.100...[D28] = 7.5 CM
block type B;
gate g1 out with ss;
gate g2 in from atleast B with ss;
signalroute sr2 from p1 to p2 with ss;
signalroute sr1 from env via g2 to p1 with ss;
signalroute sr3 from p2 to env via g1 with ss;
process p1 referenced;
process p2 referenced;
endblock type B;
FIGURE 6.4.5/Z.100
Type de bloc avec accès g1 et g2 (même type que celui de la Figure 6.4.4) (SDL/PR)
La Figure 6.4.6 représente en SDL/GR un type de bloc BX qui est un sous-type de B avec une définition de processus supplémentaire, et avec des références aux ensembles de processus existants (P1 et P3) afin de leur connecter le processus supplémentaire. La Figure 6.4.7 représente le même exemple en SDL/PR.
P1 P2
T1007920-93/d29
sr6 [ss] P3 sr4 [ss]
sr5 [ss]
g1 block type BX inherits B adding
FIGURE 6.4.6/Z.100 Définition d'un sous-type (SDL/PR) FIGURE 6.4.6/Z.100...[D29] = 7 CM
block type BX inherits B adding ;
signalroute sr4 from p3 to p2 with ss;
signalroute sr5 from p3 to env via g1 with ss;
signalroute sr6 from p1 to p3 with ss;
process p3 referenced;
endblock type BX;
FIGURE 6.4.7/Z.100
Définition d'un sous-type en SDL/PR
Les Figures 6.4.8 et 6.4.9 montrent l'utilisation des types de bloc B et BX pour spécifier des instances de bloc et des connexions aux accès.
T1007930-93/d30
B1:B g1
g2
v
u [ss]
x B2:BX
B3:BX
B BX
[ss]
[ss]
g1 g2
g2 g1
system S
signal ss;
FIGURE 6.4.8/Z.100
Définition d'un système utilisant les types de bloc (SDL/GR) FIGURE 6.4.8/Z.100...[D30] = 10 CM
system S;
signal ss;
block type B referenced;
block type BX referenced;
block B1:B;
block B2:BX;
block B3:BX;
channel u from B1 via g1 to B2 via g2 with ss endchannel;
channel v from B3 via g1 to B1 via g2 with ss endchannel;
channel x from B2 via g1 to B3 via g2 with ss endchannel;
endsystem S;
FIGURE 6.4.9/Z.100
Définition d'un système utilisant les types de bloc (SDL/PR) Des exemples de types virtuels sont donnés dans la Figure 6.4.10 ci-dessous:
procedure Proc; fpar i,j Integer ... endprocedure;
process type P
virtual procedure VProc1 atleast Proc inherits Proc ... endprocedure;
virtual procedure VProc2 ... endprocedure;
... call VProc1(1,2) ; call VProc2; ...
endprocess type ;
process type P1 inherits P;
redefined procedure VProc1 atleast VProc1 inherits << process type P >> VProc1;
...
endprocedure;
finalized procedure VProc2 ... endprocedure;
...
endprocess type ;
process type P2 inherits P1;
finalized procedure VProc1
inherits << process type P1 >> VProc1;
...
endprocedure;
...
endprocess type ;
FIGURE 6.4.10/Z.100
Exemples de types virtuels (SDL/PR)
Dans P, la procédure VProc1 est virtuelle et doit être une spécialisation de Proc, et la définition de VProc1 hérite de Proc. Si un processus P est généré, ou si un processus spécialisé ne fournit pas de définition de VProc1, cette définition s'applique. VProc2 est aussi virtuelle dans P avec une contrainte implicite qui est elle-même, c'est-à-dire que les redéfinitions de VProc2 dans les sous-types de P doivent être des sous-types de VProc2.
Dans P1, la procédure VProc1 reste virtuelle et contrainte par elle-même, alors que la procédure VProc2 n'est pas virtuelle. Les définitions s'appliquent dans le cas où un processus P1 est généré pour les appels effectués dans la définition de P. La définition de VProc1 est une spécialisation de VProc1 définie dans le processus P, et a par suite un qualificateur (process type P).
Dans P2, une nouvelle définition de VProc1 est donnée. Cela est possible étant donné que VProc1 est virtuelle dans P1.
Une redéfinition de VProc2 n'est pas autorisée ici car elle a été finalisée dans P1.
Les Figures 6.4.11 à 6.4.16 représentent des exemples de types correspondant à l'exemple représenté par les Figures 2.10.5 à 2.10.10.
R4
R1
R2
R3
T1007940-93/d31
1(1)
g3
g1 g2
Gameover
Newgame block Game
signal
Gameover(PId); Game
Monitor (1,1) Games (0, ):
Game Probe,
Result, Endgame
Gameid, Win, Lose, Score Gameserver.in
FIGURE 6.4.11/Z.100
Bloc avec type de processus (SDL/GR)
Gameserver.out
FIGURE 6.4.11/Z.100...[D31] = 10 CM block Game;
signal Gameover(PId);
connect Gameserver.in and R1,R2;
connect Gameserver.out and R3;
signalroute R1 from env to Monitor with Newgame;
signalroute R2 from env to Games via g1 with Probe, Result, Endgame;
signalroute R3 from Games via g2 to env with Gameid, Win, Lose, Score;
signalroute R4 from Games via g3 to Monitor with Gameover;
process type Game referenced;
process Monitor (1,1) referenced;
process Games (0,) : Game referenced;
endblock Game;
FIGURE 6.4.12/Z.100
Bloc avec type de processus (SDL/PR)
T1007950-93/d32 1(1)
g1 g2 g3
process type Game fpar player PId
dcl count Integer := 0;
/*counter to keep track of score */
Gameid to player
*
Result End
game none
even
Probe
Score(count) to player
Gameover
(player) odd Lose to
player
Probe none count :=
count–1
Win
to player even
count:=
count+
The hyphen means that the state is not changed
[Probe, Result, Endgame]
[Gameid, Win, Lose, Score]
[Gameover]
FIGURE 6.4.13/Z.100
Processus de jeu (Game) en tant que type de processus (SDL/GR)
–
FIGURE 6.4.13/Z.100...[D32] = 19 CM