4.2 Approche fonctionnelle : outil de spécification
4.2.3 Représentation formelle d’un IRD
Dans le but de tirer profit de cette représentation graphique, la sémantique de chaque élément de l'IRD a été définie en faisant appel au langage formel Maude. Mais pour cela, plusieurs modules objet doivent être définis. Certains d'entre eux sont décrits ci-dessous [73].
RV Accepter Cde. Rejeter Cde. Expédier Cde. Complété_Ok Expédié_Ok Cde. Annulée Cde. Complétée Accepter Paiement Rejeter Paiement Relancer Recevoir Cde. PR AS SP PP Assembler Cde. Demander Facture
Génération des cas de test fonctionnels et des cas de test structurels pour les agents
55 (omod DefELEMENT is
protecting MACHINE-INT . protecting QID .
sorts DefState ListVal Val NameState Attrib . subsorts Val < ListVal .
subsorts Qid < Oid NameState . subsorts MachineInt Bool < Val Atrib . class Elmt | State : DefState .
op null : -> DefState .
op Ste : NameState ListVal -> DefState . op <_;_> : ListVal Val -> ListVal .
op <_:_> : MachineInt MachineInt -> ListVal . ops <_:> <:_> : MachineInt -> ListVal . endom)
Le module DefELEMENT définit la classe Elmt et tous les éléments dans un IRD sont des instances de cette classe. Il possède un attribut Etat qui peut prendre la valeur NULL si l’élément n'en définit aucun état. Dans le cas contraire, il sera identifié par un nom et par une valeur ou une liste de valeurs possibles. Il définit également une sorte nommée Attrib qui est en fait un type générique et qui peut être utilisé pour définir n’importe quel attribut dans un élément spécifique si ce dernier n'utilise pas une des sortes prédéfinies.
(omod DefRELATION is protecting DefSET . protecting DefELEMENT .
sorts DefCons ListCons ListAct NotEvent Mode . class Relation | From : DefSet, To : DefSet, Constraint : DefCons .
op __ : ListCons ListAct -> DefCons . ops RM BoP EoP : -> NotEvent . op Event : NotEvent Msg -> ListCons . op Event_._ : Oid NameState -> ListCons .
op Event_._==_ : Oid NameState Val -> ListCons . op Event_._=/=_ : Oid NameState Val -> ListCons . op Eventnot_._: Oid NameState -> ListCons .
op Eventnot_._==_ : Oid NameState Val -> ListCons . op Eventnot_._=/=_ : Oid NameState Val -> ListCons . op <_or_> <_and_> : ListCons ListCons -> ListCons . ops sync async: -> Mode .
op Action : Msg Mode -> ListAct .
ops <_and_> <_or_> : ListAct ListAct -> ListAct . ops <_orthen_> <_;_>: ListAct ListAct -> ListAct . ops <_else_> <_xor_>: ListAct ListAct -> ListAct . endom)
Le module DefRELATION est utilisé pour définir des relations dans un IRD. Toutes les relations d'un IRD sont des instances de cette classe. Dans ce module, les attributs From et To indiquent les éléments origines et destinations de la relation, et l'attribut Constraint définit les conditions imposées par la relation.
Génération des cas de test fonctionnels et des cas de test structurels pour les agents
Enfin, dans DefIRD, la classe IRD est utilisée pour définir un IRD. Il possède deux attributs représentant l'ensemble des éléments et l'ensemble des relations dans l'IRD.
(omod DefIRD is protecting DefSET .
class IRD | ElmtSet : DefSet , RelSet : DefSet . endom)
Ayant défini les modules « ingrédients », il est important de rappeler qu’en Maude, la forme générale d’une règle de réécriture utilisée pour spécifier le comportement d'un système quelconque est la suivante:
M1….Mn <O1:C1|attrs1>…<Om:Cm|attrsm> => <Oi1:C’i1|attrs’i1>…<Oik:C’ik|attrs’ik>
<Q1:D1|attrs’’1>…<Qp:Dp|attrs’’p> M’1….M’q
If C
Tel que M’1….M’q sont les expressions de messages et C est la condition de la règle. Les
résultats après l’exécution d’une telle règle sont comme suit :
Les messages M1.... Mn disparaissent,
L'état et éventuellement la classe des objets Oi, ..., Ok peuvent changer,
Tous les autres objets Oj se dissipent,
De nouveaux objets Q1, ... Qp sont crées,
Et de nouveaux messages M'1, ... M'q sont envoyés.
Appliquant ceci à notre agent de traitement des commandes, les différents modules qui composent la spécification formelle du système sont définis. Le module ELMT_Receiver représente la classe de l'élément récepteur. Tous les autres éléments dans un IRD sont représentés au moyen de modules objet Maude dans lesquels une classe est définie comme étant une sous-classe de la classe Elmt (définie dans DefELEMENT) avec ses propres attributs et ses actions définies en tant que messages. Par exemple, Recvr est une sous-classe de Elmt définissant trois actions Receive_Order, Accept_Order et Reject_Order définies par des messages.
(omod ELMT_Receiver is protecting DefELEMENT . class Recvr
subclass Recvr < Elmt .
msgs receive_order accept_order reject_Order: Oid->Msg . var R : Oid .
rl[accept_Order]: receive_Order(R) <R:Recvr|OrderId:N>=><R:Recvr|OrderId:N+1> rl[accept_Order]: accept_Order(R) <R:Recvr|accepted:false)>=><R:Recvr|accepted:true)>
new(A:Assembler|OrderId:OrderId+1) .
rl[reject_Order]: reject_Order(R) <R:Recvr|State:Ste(‘accepted, false)>=> <R:Recvr|State:Ste(‘accepted, false)> .
Génération des cas de test fonctionnels et des cas de test structurels pour les agents
57
De la même manière, les modules ELMT_Assembler, ELMT_Shipper et
ELMT_Payment_Receiver sont définis avec leurs messages représentant leurs propres actions.
(omod ELMT_Assembler is protecting DefELEMENT . class Assbl | Assembled :Atrib. subclass Assbl < Elmt .
msgs Assemble_Order Request_Invoice: Oid -> Msg . var A : Oid .
rl[Assemble_Order]: Assemble_Order(A)<A:Assbl|Assembled:false>=> <A:Assbl|Assembled:true> new(S:Shpr|Start_Date:D, shipped:false)
Request_Invoice (A) Ship_Order (S) .
rl[Request_Invoice]: Request_Invoice(A)<A:Assbl|Assembled:true>=><A:Assmbl|Assembled:true> new(I:Invoicer|Inv_amnt:0) .
endom)
(omod ELMT_Shipper is protecting DefELEMENT .
class Shipr | Start-Date Shipped : Atrib . subclass Shipr < Elmt .
msg Ship_Order: Oid -> Msg .
rl[Ship_Order]:Ship_Order(S) <S:Shipr|Start_Date:D, Shipped: false>=> <S:Shipr|Start_Date:D, Shipped: true> . endom)
(omod ELMT_Payment_Receiver is protecting DefELEMENT .
class PRecvr | Completed :Atrib. subclass PRecvr < Elmt .
msg Receive_payment: Oid -> Msg . var Pr : Oid .
rl [Order_Completed]:Order_Completed(Pr) <Pr:PRecvr|Completed: false>=> <Pr:PRecvr|Completed: true>.
rl[Order_Aborted]:Order_Aborted(Pr) <Pr:PRecvr|Completed: false>=> <Pr:PRecvr|Completed: false> .
endom)
Un denier module d'objet représentant l'IRD complet est également défini en Maude. Il s’agit d’une instance de la classe IRD dans lequel l’ensemble des éléments et l'ensemble des relations sont spécifiés.
Génération des cas de test fonctionnels et des cas de test structurels pour les agents (omod IRD_Order-Processing is protecting DefIRD . protecting DefRELATION . protecting CONFIGURATION . protecting ELMT_Receiver . protecting ELMT_Assembler . protecting ELMT_Shipper . protecting ELMT_Payment_Receiver . subsort Qid < Oid .
op init : -> Configuration . eq init =
< 'RV : Receiver | State : null > < 'AS : Assembler | State : null > < 'SP : Shipper | State : null >
< 'PR : Payment_Receiver | State : null > < 'PP : Payment_Processor | State : null >
<'Ship_Ok:Relation|From:'RV 'AS, To:'SP, Constraint:<Event 'RV. 'Opened and Event(EoP, Assemble_Order('AS))> Action (Ship_Order('SP) and Request_Invoice('SP), sync) >
<'Completed_Ok:Relation|From: 'PP 'SP, To:'PR, Constraint: < Event ‘PP. ‘Paid and Event (EoP, Send_Payment('RV) and Event (EoP, Ship_Order('SP))> Action (Order_Completed('PR) else Action (Order_Aborted('PR)), sync ))>
<'Order_Processing: IRD|ElmtSet: 'RV 'AS 'SP 'PR’PP, RelSet:'Ship_Ok 'Completed_Ok> . endom)
Une fois la spécification fonctionnelle du système définie, nous allons dans ce qui suit se pencher sur l’approche structurelle du test unitaire de notre agent.