Le langage RDL peut être considéré comme une syntaxe accessible pour le formalisme RM. Le RDL permet de capturer plusieurs types d’informations. Plus précisément, il permet d’instancier les vues de niveau produit (M1) et instance (M0) du métamodèle RM (cf. Tableau 4). Il est spécialisé pour la spécification du domaine d’un système d’une part (exigences et assertions environnementales) et l’instanciation de configurations possibles du système (états du système) d’autre part. Il offre ainsi une expressivité suffisante pour les activités V&V de simulation et de vérification formelle. Bien que contraint, le RDL accepte une grande variété de phrases comme l’illustre la Figure 36. Dans son état actuel, le langage RDL autorise la description des types d’informations suivants (chaque type d’informations est associé à une ou plusieurs vue(s) du métamodèle RM, donnée entre parenthèses) :
Informations relatives aux entités du domaine, aux états possibles de ces entités et leurs relations (vue statique). Toutes les phrases de la Figure 36 comportent des informations de ce type. A titre
d’exemples : la phrase (1) définit l’existence des concepts de « participant », de « modérateur » et de « meeting », le deuxième étant un rôle pouvant être joué par le premier ; la phrase (2) définit la notion de « type » comme une propriété du concept de « meeting » ; la phrase (6) précise des valeurs possibles pour cette propriété.
Informations relatives aux actions pouvant être effectuées par les acteurs du domaine (vue fonctionnelle et vue logique). A titre d’exemples : la phrase (9) définit l’action de planification d’une
réunion par un participant ; la phrase (4) décrit la durée de l’action de « connexion au serveur externe » ; les phrases (2, 3, 8) définissent des conditions d’applications et effets (liens de causalité) des actions « planifier une réunion » et « entrer dans une réunion ».
Informations contraignant le comportement du domaine (vue non-fonctionnelle et vue logique).
A titre d’exemples : la phrase (5) spécifie qu’un participant ne peut avoir la parole plus de 3 minutes d’affilée dans une réunion ; la phrase (13) spécifie qu’une personne s’exprimant dans une réunion doit au préalable avoir la parole (ce qui n’est possible que si le modérateur la lui a donnée, cf. phrase (14)).
Informations sur une instance du domaine, c’est-à-dire un état particulier du domaine (vue configuration). Par exemple, la phrase (7) fait état de l’existence d’un individu Anne et décrit la
valeur de deux de ses relations. La phrase (12) décrit l’existence d’une réunion et lui donne un nom.
Information précisant si les propriétés non-fonctionnelles spécifiées sont indicatives ou optatives (vue analyse). Ce type d’informations permet de distinguer ce qui décrit l’environnement de ce qui
décrit les exigences. A titre d’exemple : l’utilisation de verbes modaux tels que « must » ou « shall » souligne le caractère optatif de l’information.
Chaque phrase RDL est instance d’un des patrons de spécification RDL, présentés dans le Tableau 5 (un exemple de phrase RDL est donné sous chaque patron). Ces patrons sont classés dans quatre catégories différentes : patron fonctionnel, non-fonctionnel, statique et de configuration. Cette classification correspond aux types d’informations cités plus haut (le dernier type d’informations n’est pas représenté car orthogonal aux autres61). Les trois premières catégories sont utiles pour la description du domaine, la dernière pour l’instanciation de celui-ci dans un but de validation par simulation par exemple. Les patrons non-fonctionnels sont un sous-ensemble des patrons proposés par Dwyer [8, 51-52] et Cheng [52]. Dans la suite, on appellera type d’une phrase RDL le patron dont elle est instance. Le Tableau 6 précise le type des phrases RDL de la Figure 36. Tous les patrons
61 Plus précisément, le caractère indicatif/optatif est orthogonal au caractère fonctionnel/non-fonctionnel (on a affaire à la tyrannie d’une décomposition, d’un partitionnement dans ce cas …).
fonctionnels et non-fonctionnels peuvent être instanciés avec un des champs d’application proposés par Dwyer.
Cat. Nom Description
ACTIONDECLARATI ON
Définit une action, son acteur et les concepts et/ou acteurs mis en jeu.
« A “participant” can “ask the word” to a “moderator”. »
ACTIONEFFECT Spécifie un effet d’une action sur l’état du domaine une fois l’action effectuée.
« A “participant” is the “manager” of a “meeting” after he did “plan” it. »
ACTIONCONDITION Spécifie une condition sur l’état du système devant être satisfaite pour autoriser un acteur à effectuer une action.
« When a meeting is private, a “participant” must be “connected” before he can “enter” in a “meeting”. »
ACTIONDURATION Spécifie la durée d’une action.
F O N C T IO N N E L L E
« It takes 30 seconds for a “participant” to “connect” to the “external server. »
CARDDESCRIPTION Spécifie les cardinalités possibles d’une relation entre entités du domaine.
« When a “meeting” is “private”, a “participant” must be “identified” before he can “enter” in this “meeting”. »
ENUMDESCRIPTION Spécifie les valeurs possibles d’une propriété statique.
S T A T IQ U E
« The “state” of a “camera” can be “setOn” or “setOff”. »
INSTANCIATION Fait état de l’existence d’une instance d’une entité du domaine. « There is a “participant” called “Jacques”. »
INSTANCESETTING Définit l’état d’une instance. « The “type” of “meeting1” is “private”. »
ACTIONTRIGGERING Déclare l’activation d’une action.
C O N F IG U R A T IO N
« “Jacques” does “give the word” to “Jean”. »
INVARIANT Spécifie une relation de causalité indicative entre états du domaine.
« A “participant” must not be “entered” in a “meeting” if this “meeting” is “closed”. » RESPONSE *
Spécifie le fait que si une condition (ou l’activation d’une action) est satisfaite, celle-ci est suivie de la satisfaction d’une autre condition (ou activation d’une action).
PRECEDENCE *
Spécifie le fait que si une condition (ou l’activation d’une action) est satisfaite, celle-ci est précédée de la satisfaction d’une autre condition (ou activation d’une action).
EXISTENCE * Spécifie le fait qu’une condition sur l’état du domaine (ou l’activation d’une action) est satisfaite au moins une fois.
ABSENCE * Spécifie le fait qu’une condition sur l’état du domaine (ou l’activation d’une action) n’est jamais satisfaite.
« A “moderator” of a “meeting” must not be the “manager” of this “meeting”. »
UNIVERSALITY * Spécifie le fait qu’une condition sur l’état du domaine est toujours vraie, pour un champ d’application donné.
« When a “meeting” is “private”, the “state” of the “camera” of a “participant” must be “setOn” if this “participant” is “entered” in this “meeting”. »
N O N -F O N C T IO N N E L L E BOUNDEDRESPONSE **
Spécifie la durée maximum séparant la satisfaction de deux conditions sur l’état du domaine (ou l’activation d’une action).
BOUNDEDINVARIAN CE **
Spécifie la durée minimum séparant la satisfaction de deux conditions sur l’état du domaine (ou l’activation d’une action). MINIMUMDURATIO
N **
Décrit la durée minimum pendant laquelle une condition sur l’état du domaine doit être satisfaite.
MAXIMUMDURATIO N **
Décrit la durée maximum pendant laquelle une condition sur l’état du domaine doit être satisfaite.
* : patron de spécifications de Dwyer, ** : patron de spécifications de Cheng
Tableau 5 - Les patrons de spécification RDL.
Phrase Type Phrase Type
(1) CARDINALITYDESCRIPTION (8) ACTIONCONDITION (2) ACTIONCONDITION (9) ACTIONDECLARATION
(3) ACTIONEFFECT (10) PRECEDENCE
(4) ACTIONDURATION (11) STATEINVARIANT (5) MAXIMUMDURATION (12) INSTANCIATION (6) ENUMERATIONDESCRIPTION (13) UNIVERSALITY (7) INSTANCESETTING
Tableau 6 - Types des phrases RDL de la Figure 36.
Tout comme pour les patrons de spécification de Dwyer et Cheng, une sémantique formelle est associée à chacun des patrons de spécification RDL. Cette sémantique est une instance du RM puisque ce dernier est le formalisme de la plate-forme R2A. Plus précisément, on peut représenter cette sémantique comme un modèle RM abstrait où certains fragments ne sont pas encore instanciés (ces fragments sont représentés par des variables). Ces modèles sont appelés motifs. La Figure 37 présente les motifs associés à trois patrons RDL (deux fonctionnels et un non-fonctionnel), présentés comme une expression de la syntaxe formelle du formalisme RM. Les variables des motifs sont en italiques. Le premier motif correspond à la sémantique du patron ACTIONCONDITION.
action name (Parameter) pre : scope
∧
conditionpost :
action name (Parameter) pre :
post : scope => effect.
invariant | constraint :
Quantifiers, scope => (logicalExpr1 => logicalExpr2)
ActionCondition ActionEffect Invariant : : :
Figure 37 - Motifs de trois patrons RDL.
On peut donc déterminer à partir des motifs associés aux patrons RDL la sémantique de chacune des phrases RDL de la Figure 36. Pour ce faire, on procède à une affectation de chacune des variables. Par exemple, la phrase (8) spécifie une condition sur l’activation de l’action « entrer dans une réunion » et cela lorsque cette réunion est privée (cette dernière condition est le champ d’application). C’est une phrase de type ACTIONCONDITION. Après affectation des variables du motif associé, on obtient la formule (a) de la Figure 38 représentant la sémantique de la phrase (8). La phrase (3) stipule que la planification d’une réunion par un participant signifie que celui-ci en devient le gestionnaire. Cette phrase est de type ACTIONEFFECT. Sa sémantique est donnée par la formule (b). La formule (c) est obtenue de la même manière par instanciation du motif associé au patron INVARIANT. Elle représente la sémantique de la phrase (11).
On peut remarquer que la formule (b) n’est pas exactement l’instance de la sémantique formelle du patron ACTIONEFFECT donnée en Figure 37. Premièrement, cette différence est due au fait que la phrase (3) ne définit pas de champ d’application, ce qui revient à considérer la propriété toujours vraie
(équivalant à un champ d’application « Globally » pour les patrons de Dwyer et Cheng). Deuxièmement, cette différence est due à l’utilisation du verbe « become » dans la phrase (3), ce qui signifie que le participant ne peut planifier une réunion s’il en est déjà le gestionnaire. On remarque ici que tout comme les patrons de Smith [53], chaque patron RDL comporte un ensemble de variations dépendant dans notre cas de la nature des valeurs affectées aux variables (dans le cas des patrons de Schmidt, les variations sont précisées par un ensemble de phrases). Enfin, on remarque que le RDL permet de décrire les phénomènes du système dans un langage naturel contraint, contrairement aux patrons de spécification proposés dans la littérature.
« When the "type" of a "meeting" is "private", a "participant" must be "identified" before he can "enter" in this "meeting". »
action enter(p : Participant, m : Meeting)
pre : type(m)= private ∧identified(p)
« A "participant" becomes the "manager" of a "meeting" after he does "plan" this "meeting" . »
action plan(p : Participant, m : Meeting)
pre : ¬manager(p, m)
post : manager(p, m)
«A "meeting" is "closed" if and only if it is not "opened". »
assertion
∀m : Meeting, closed(m) <=> ¬opened(m). (8) (a) (3) (b) (11) (c)
Figure 38 - Sémantiques des phrases (8,3,11) de la Figure 36, obtenues à l'aide des sémantiques associées aux patrons de spécification RDL.
action name (Parameter) pre :
post : scope => effect. action name (Parameter) pre :
post : true => effect. action name (Parameter) pre :
post : effect.
action plan (p : Participant, m : Meeting) pre :
post : manager(p, m).
action plan (p : Participant, m : Meeting) pre : ¬manager(p, m) post : manager(p, m). motif : 1 2 3 4
-Figure 39 - instanciation manuelle, étape par étape, du patron ACTIONEFFECT pour la phrase (3) de la Figure 37.
La Figure 39 montre une manière d’instancier manuellement le patron ACTIONEFFECT pour obtenir la sémantique de la phrase (3), soit la formule (b) de la Figure 38. Cette instanciation est présentée en quatre étapes. La modification du motif effectuée pendant une étape est soulignée dans le texte. La première étape consiste à affecter la variable scope, la deuxième à simplifier l’expression logique. La troisième étape consiste en l’affectation des variables action et effect et la dernière en la
mise à jour de l’expression pour prendre en compte la variation associée à l’utilisation du verbe « become ».