Download Introduction

V.3. Construction du réseau global
Cet indéterminisme sera d'ailleurs fréquemment levé par la structure même des ObCS (voir par
exemple l'ObCS d'implémentation de la classe Fichier_protégé), mais le concepteur peut fort bien
souhaiter conserver cet indéterminisme jusqu'à l'implémentation.
L'ObCS de la classe ServeurG, tel qu'il résulte de l'étape 2, est illustré en Figure V.7.
Etape 3 : Gestion de l'instanciation dynamique.
On pourrait croire, d'après le processus de construction tel qu'il a été décrit jusqu'ici, que la création
dynamique de nouveaux objets dans le système va entraîner la génération de nouveaux réseaux
représentant leurs ObCS, et que le système est donc modélisé par un ensemble de réseaux dont la
structure évolue, d'une manière comparable à l'extension dynamique des transitions d'invocation
décrite dans [Huber…89].
Nous ne voulons pas, cependant, gérer un ensemble de réseaux qui évolue dans le temps, parce que
c'est renoncer à la plupart des possibilités de validation formelle liées à la théorie des RdP (toutes
celles qui reposent sur l'analyse de la matrice d'incidence). Au contraire notre but est de fournir un
ensemble de réseaux déterminé statiquement qui produise le même comportement résultant.
L'étape 3 permet d'obtenir ce résultat en conservant un réseau pour chaque classe d'objets du système,
et en rassemblant par pliage le marquage d'un nombre quelconque d'instances de cette classe.
On a indiqué au chapitre III.3 que les attributs définis pour une classe d'objet sont utilisés comme
registres de son ObCS. Le chapitre II.2 a montré que les registres des RPO étaient une facilité
syntaxique pour désigner des jetons présents dans des places cachées du réseau.
L'ObCS de chaque classe est modifié de la manière suivante :
1° Introduction des places-attribut : une nouvelle place est ajoutée pour chaque attribut de la
classe, et le type de cette place est le même que celui de l'attribut. Chaque place-attribut est
connectée en entrée et en sortie à chaque transition où l'attribut associé est utilisé, et les arcs
sont étiquetés avec le nom de l'attribut. Par utilisation d'un attribut on doit entendre :
-
Affectation d'une valeur à l'attribut au sein de l'action de la transition ;
-
Utilisation de la valeur de l'attribut au sein d'une expression ;
-
Appel d'une opération interne qui utilise dans son code l'attribut ;
-
Test de la valeur de l'attribut dans une précondition ;
-
Utilisation de l'attribut comme paramètre réel d'un appel de service.
2°) Certaines transitions (TI ou transitions privées) peuvent n'avoir aucune place d'entrée dans
l'ObCS, décrivant ainsi des services ou des actions internes qui sont toujours activables. Si le
cas se présente, on ajoute à ces transitions une place en entrée et sortie, cette place possédant
un marquage initial d'un jeton simple ;
3°) Le type de la classe est ajouté à la définition du type de chaque place de l'ObCS (y compris les
places qui ont été ajoutée aux étapes précédentes) à l'exception des places paramètre et résultat
des TI et de places résultat des transitions de retour. On ajoute conformément la variable self
aux arcs adjacents ;
151