Contrôle Continu / Examen Diplôme et Filière

Contrôle terminal 2021-2022 Licence L3 Informatique

Unité d’Enseignement - UE Élément Constitutif - EC
AGL
Campus de Pau
Durée de l’épreuve : 4h K. Ouriachi, Professeur des universités

Date Conditions d’évaluation

06/05/2022 :
14h- 18h Présentiel en salles B208, B206 et B215 -Notes de cours et de Tp autorisées

Evaluation de la compétence: (4 points - durée conseillée 30 mn)

1-Rappeler l’objectif recherché par l’ingénieur en développement en

recourant à une Méthode Formelle ?
Citer les tâches d’un cycle de développement formel qui s’inscrivent
directement dans cet objectif.
Evaluation de compétence:

1-Rappeler l’objectif recherché par l’ingénieur en développement en

recourant à une Méthode Formelle ?
.

En développement formel, l’ingénieur logiciel poursuit au

moins 4 objectifs:

1- la sureté de fonctionnement du système : c’est la

qualité première qui ne peut être atteinte qu’au prix de
développement de logiciels sûrs:qui satisfont la spécification
initialement établie.
 2-la performance: les logiciels d’application sont
générés de façon automatique par des générateurs qui
produisent des codes optimisés d’un haut niveau de qualité,

3-rationnalisation du coût de développement : bien

que cet objectif n’était pas initialement déterminant dans le
choix d’une méthode formelle, avec l’automatisation
croissante des tâches proposées par les AGL, il est devenu
un facteur économique important en ingénierie logicielle.
Citer les tâches d’un cycle de développement formel qui s’inscrivent
directement dans cet objectif.

Un cycle de développement formel distingue 4 tâches(étapes)

Analyse Génération
Modélisation Validation de
du
de code
système
modèle (automatisée)
(

Etape 1 Etape 2 Etape 3 Etape 4

2- En analysant les AGL étudiés en travaux pratiques, citer (en les
justifiant) les principales fonctionnalités que doit assurer n’importe
quel AGL indépendamment de la Méthode Formelle déployée?

Un AGL doit offrir a minima les fonctionnalités suivantes :

1-Langage de spécification pour décrire un modèle du système et

procéder à sa transformation durant les étapes de raffinage.

2-Un générateur automatique des obligations de preuves : un tel

système doit, en outre, être doté de la capacité de prouver directement
les obligations de preuves les plus «évidentes»,
 3-Prouveur automatique (solver) : un système de démonstration
automatique ou assistée qui agit à deux niveaux:
i)- vérifier la correction du modèle initial: prouver la
consistance et la complétude du dit modèle
ii)- vérifier le raffinage: prouver qu’à l’issue de chaque
raffinage, toutes les propriétés précédemment énoncées sont
préservées.

4-des générateurs de code : un atelier doit fournir les traducteurs

nécessaires pour transformer le modèle raffiné (implémentable) en
code dans un langage de programmation classique : Java, C++,Ada,…
 5-Un « animateur » dont la fonction est d’exécuter directement le
modèle selon l’un des trois modes suivants :
-mode simulation : exécution sans interaction avec l’utilisateur,
-animation : exécution en interaction directe avec l’utilisateur
qui teste le modèle: validation dynamique,
- animation via une interface externe: programme externe qui
contrôle l’exécution du modèle.
3-Dans quelle mesure les Méthodes Formelles favorisent un
comportement agile

L’agilité de la méthode: elle est favorisée par au moins 2

facteurs :

1-la construction d’un modèle du système étudié :

le développeur et l’utilisateur peuvent coopérer et s’accorder
autour de ce modèle.

Ainsi, l’utilisateur peut mettre son expertise au service du

développeur chargé de construire le modèle du système
étudié.
Il peut aussi, aider à répercuter, très tôt, sur le modèle, toute
évolution ou changement du cahier des charges initial.

2-La possibilité d’animer le modèle : l’utilisateur

dispose de la possibilité d’expérimenter le futur logiciel en
exécutant directement certaines fonctions du modèle.
Exercice: (16 points) « Pilotage des compensations d’opérations sur un marché dérivé»
A la différence d’un marché actions classique, un marché dérivé est un marché sur lequel on achète ou vend non pas directement une action ou un titre, mais on
conclut, entre opérateurs (traders), des contrats de possibilités d'achat/vente à un terme différé. Cela consiste pour un opérateur à s’engager à acheter des
titres/actions (on dit «prendre position») à un prix convenu entre les contreparties contractantes, sans toutefois être en possession du montant nécessaire pour en
devenir le détenteur réel. Pour s’acquitter de ce montant, l’opérateur compte sur une hausse prochaine, sur le marché, de ces actions/titres afin de pouvoir les revendre
à un prix supérieur (à celui convenu) et, ainsi, engranger, au passage, une marge.
La principale caractéristique de ces marchés dérivés est de permettre aux opérateurs acheteurs d’anticiper en prenant des positions importantes à l'achat avec
une mise de fonds limitée à un «dépôt de garantie». Cette garantie est obligatoire. Elle est censée servir à compenser les pertes éventuelles si, entre temps, au lieu
d’enregistrer la hausse espérée sur le marché, les actions/titres engagés se déprécient (et le vendeur voit les titres/actions engagés perdre de leur valeur).
Pour fonctionner et prévenir les risques d’insolvabilités de l’acheteur - les opérateurs parlent de « risque de contrepartie » - des mécanismes sont mis en place
afin que les engagements pris par les contreparties contractantes soient tenus (l’acheteur s’acquitte du montant convenu au moment de la conclusion du contrat)
C’est là qu’intervient la chambre de compensation. Il s’agit d’un organisme financier ayant pour but d'éliminer les risques de contrepartie en assurant la
surveillance des positions.
Concrètement, la chambre de compensation est la contrepartie unique de tous les opérateurs : c’est l’acheteur de tous les vendeurs et le vendeur de tous les
acheteurs. Pour simplifier, le processus de compensation fonctionne selon le principe le suivant:
-enregistrer toutes les opérations réalisées dans le marché: une opération est la conclusion d'un contrat passé entre deux opérateurs,
-exiger la formation dans ses livres d'un dépôt de garantie le jour de la réalisation de l’opération.
Quotidiennement, pendant toute la durée de l'opération, les agents superviseurs du marché surveillent les différences entre le prix du titre/action convenu dans
le contrat et le cours actuel du marché. En cas de perte potentielle de l’acheteur, elle procède à un «appel à la marge»: elle exige de ce dernier une augmentation du
dépôt de garantie. C’est une marge censée représenter deux jours de pertes maximales. Si l'appel à la marge n'est pas suivi, elle dénoue d'office la position : elle
annule l’opération en cours et apure les pertes avec le dépôt de garantie.
Le problème est que dans l’hypothèse où les marges et les dépôts de garanties ne suffisent plus, la chambre de compensation, garante de la bonne fin des
opérations, voit ses fonds propres mis à contribution. Et, dans une situation de forte instabilité du marché, ces fonds propres risquent de ne plus suffire.
D’où la nécessité d’un contrôle automatique en temps réel qui incite à bien mesurer le risque et à optimiser le calcul des marges.
Une solution consiste à piloter le processus de compensation par un logiciel auquel est dévolu le contrôle en temps réel du déroulement des opérations (« prises
de de position ») du marché. Dans ce qui suit, on simplifie en se limitant aux six fonctionnalités suivantes:
1-enregistrer les opérations au fur et mesure des prises de positions sur le marché,
2-enregistrer les dépôts garantie,
3-valider une opération enregistrée lorsqu’il est constaté qu’elle est couverte par un dépôt de garantie,
4-faire rapidement un « appel à la marge » en cas de perte potentielle,
5-dénouer immédiatement une opération (si l’«appel à la marge» visant l’opération n’est pas suivi d’effet),
6-confirmer la bonne fin d’exécution d’une opération: l’acheteur s’acquitte du montant auprès du vendeur et se voit restituer le dépôt de garantie.
Par ailleurs, les agents superviseurs du marché souhaitent disposer en temps réel des informations suivantes :
-l’ensemble des opérations enregistrés,
 -l’ensemble des opérations validées (opérations couvertes par un dépôt de garantie),
-l’ensemble des opérations visées par un «appel à la marge»,
-l’ensemble des opérations dénouées,
-l’ensemble des opérations dont la bonne fin d’exécution est confirmée.

1-Exposer des arguments pour justifier, auprès de votre équipe de développeurs, le recours, dans le cadre de ce projet de contrôle du processus de compensation, à
une méthode formelle.
2-En choisissant la méthode vdmSl, proposer un cycle de développement en 4 étapes:
-étape 1: Proposer une analyse du système de pilotage des compensations.
-étape 2: Construire un modèle VdmSl pour ce système.
-étape 3: Valider le modèle VdmSl construit.
-étape 4: Générer, en partant de ce modèle validé, le code source (C++ ou Java) l’application cible.
1-Exposer des arguments pour justifier, auprès de votre équipe de
développeurs, le recours, dans le cadre de ce projet de contrôle du
processus de compensation, à une méthode formelle.

Trois arguments peuvent convaincre l’équipe du choix en faveur d’un

développement forme:

Argument 1:

Il s’agit d’un système critique de fonctionnement: les défauts

éventuels peuvent avoir des conséquences graves: crise systémique du
système financier
 Argument 2:

Les « tests classiques » sont difficilement réalisables compte tenu de

la nature du système,… par contre un modèle formel validé peut être
utilisé pour une simulation sur une plateforme.

Argument 3:

Le système est sujet à des maintenances correctives fréquentes

compte tenu du caractère évolutif du règlement du marché financier. Il
serait alors plus efficace de modifier un modèle de représentation
plutôt que le logiciel.
2-En choisissant la méthode VdmSL proposer un cycle de
développement en 4 étapes:

-étape 1: Commencer par une analyse du système.

-étape 2: Construire un modèle VdmSl pour ce système.
-étape 3: Valider le modèle VdmSl précédent.
-étape 4 Générer le code source C++ ou Java
 Etape 1 Etape 2 Etape 3 Etape 4

Construction Validation
Analyse du modèle
Génération
Orientée-modèle d’un modèle VdmSl de code
(ASM) vdmSl (fortement automatisée)
(automatisée)

Cycle de développement VdmSL

 Etape 1: Analyse du système

Plan d’analyse

1. Comment caractériser l’état du système ?

2.Quel est l’état initial du système ?
3. Quelles sont les entrées du système ?
4. Quels événements affectent l’état du système ?
5. Quelles sont les réactions du système ?
6. Proposer un modèle formel pour le système
 étape 1: Analyse du système

1. Comment caractériser l’état du système ?

La compensation des opérations est un système réactif.

Son état évolue en fonction de la dynamique du marché où des

opérateurs se voient accordés la liberté de conclure des contrats
d’achat/vente visant des titres mis sur ce marché.
Son comportement est déterminé par les événements/actions
suivants:

1- enregistrer une opération dans le registre des opérations,

2-souscrire une garantie censée couvrir les risques concernant
une opération,
3-valider une opération par une garantie,
4-viser une opération par un appel à la marge,
5-dénouer une opération si l’appel à la marge reste sans suite,
6-confirmer la bonne fin d’exécution d’une opération.
L’évolution de l’état du système est complètement
déterminée par les variables d’état suivantes:

1-l’ensemble des opérations enregistrées

registreOperations : set of OPERATION

2-l’ensemble des garanties souscrites par les opérateurs:

registreGaranties : set of GARANTIE
 3-l’ensemble des opérations visées par un appel à la
marge :
registreAppels: set of OPERATION

4- l’ensemble des opérations dont la bonne fin d’exécution

est confirmée :
registreConfirmations: set of OPERATION
 5- la fonction qui, à chaque opération enregistrée, associe
la garantie censée la couvrir :
validerPar : inmap OPERATION to GARANTIE
L’état est caractérisé par l’invariant:

dom validerPar subset registreOperations

and
rng validerPar subset registreGaranties

and
registreAppels subset dom validerPar

and
registreConfirmations subset dom validerPar
2- Quel est l’état initial ?

L’état initial du système est défini aléatoirement

comme suit :

registreOperations0 : set of OPERATION

= {op1,op2,op3,op4,op5,op6,op7,op8,op9};

registreGaranties0: set of GARANTIE

= {gr1, gr2, gr3,gr4, gr5, gr6, gr7};

validerPar0 : inmap OPERATION to GARANTIE

= {op1|->gr1, op2|->gr2 , op3|->gr3, op4|->gr4,op5|->gr5 , op6|->gr6 };
3. Quelles sont les entrées du système ?
L’entrée du système est constituée par:

- l’ensemble des opérations inscrites dans le registre

des opérations:
registreOperations : set of OPERATION

-l’ensemble des garanties souscrites par les

opérateurs:
registreGaranties : set of GARANTIE
4. Quels événements affectent l’état du système ?

L’état du système de compensation évolue sous l’effet

des événements/actions suivants :

1-enregistrer une opération

enregistrer: OPERATION ==> ETAT

pre operation not in set registreOperations

post registreOperations = registreOperations~ union {operation} ;
2-souscrire une garantie
souscrire: GARANTIE ==> ETAT

pre garantie not in set registreGaranties

post registreGaranties = registreGaranties~ union {garantie} ;
3-valider une opération enregistrée
valider: OPERATION * GARANTIE ==> ETAT

pre
operation in set registreOperations
and garantie in set registreGaranties
and operation not in set dom validerPar
and garantie not in set rng validerPar

post validerPar = validerPar~ munion {operation |-> garantie} ;

4-viser une opération par un « appel à la marge.
viser: OPERATION ==> ETAT

pre operation in set dom validerPar

post registreAppels = registreAppels~ union {operation};
5-dénouer une opération: l'invalider en conservant
la garantie.

denouer: OPERATION ==>ETAT

pre operation in set registreAppels

post operation not in set dom validerPar
6-confirmer la bonne fin d’exécution d’une opération.
confirmer: OPERATION ==>ETAT

pre operation in set dom validerPar

post
validerPar = {operation} <-: validerPar~
and registreConfirmations = registreConfirmations~ union {operation}
5. Quelles sont les réponses du système ?
Le déroulement des compensations est observé en se référant aux
données de sortie suivantes :

1-l’ensemble des opérations enregistrés

enCours: () ==> set of OPERATION

2-l’ensemble des opérations validées

validées: () ==> set of OPERATION
3-l’ensemble des opérations visées par un «appel à la marge»,
visées: () ==> set of OPERATION

4-l’ensemble des opérations dénouées: opérations appelées mais

invalidées.
denouées: () ==> set of OPERATION

post RESULT = registreAppels \ registreAppels inter dom validerPar ;

5-l’ensemble des opérations dont la bonne fin d’exécution est

confirmée.
confirmées: () ==> set of OPERATION
6. Proposer un modèle ASM

MACHINE SystemeCompensation

TYPES
OPERATION ; GARANTIE / types nécessaires
/ aspect statique du système

VARIABLES
/ variables d’état de la MA
registreOperations : set of OPERATION
registreGaranties : set of GARANTIE
registreAppels: set of OPERATION
registreConfirmations: set of OPERATION
validerPar : inmap OPERATION to GARANTIE
INVARIANT
dom validerPar subset registreOperations
and
rng validerPar subset registreGaranties
and
registreAppels subset dom validerPar
and
registreConfirmations subset dom validerPar
INITIALISATION
/ déterminer l’état initial du système

initialiser  ETAT

post initialiser ==
registreOperations = registreOperations0,
and registreGaranties = registreGaranties0
and registreAppels = {},
and registreConfirmations = registreConfirmations0
and validerPar = validerPar0
OPERATIONS
/ opérations de modification de l’état
enregistrer: OPERATION ==> ETAT

pre operation not in set registreOperations

post registreOperations = registreOperations~ union {operation} ;

souscrire: GARANTIE ==> ETAT

pre garantie not in set registreGaranties

post registreGaranties = registreGaranties~ union {garantie} ;
valider: OPERATION * GARANTIE ==> ETAT

pre
operation in set registreOperations
and garantie in set registreGaranties
and operation not in set dom validerPar
and garantie not in set rng validerPar

post validerPar = validerPar~ munion {operation |-> garantie} ;

viser: OPERATION ==> ETAT

pre operation in set dom validerPar

post registreAppels = registreAppels~ union {operation};
denouer: OPERATION ==>ETAT

pre operation in set registreAppels

post operation not in set dom validerPar

confirmer: OPERATION ==>ETAT

pre operation in set dom validerPar
post
validerPar = {operation} <-: validerPar~
and registreConfirmations = registreConfirmations~ union {operation}
and registreGaranties = registreGaranties~ \ {validerPar(operation)} ;
/ opérations d’observation de l’état

enregistrées: () ==> set of OPERATION

validées: () ==> set of OPERATION
visées: () ==> set of OPERATION
denouées: () ==> set of OPERATION
confirmées: () ==> set of OPERATION

FIN systemeCompensation
 2: Modèle VdmSl du système

Etape 1: définition des types nécessaires

types
--type des OPERATIONS
OPERATION =
<Op1>|<Op2>|<Op3>|<Op4>|<Op5>|<Op6>|<Op7>|<Op8>|<Op9>|<Op10>|<Op11
>|<Op12>;

--type des GARANTIES

GARANTIE=
<G1>|<G2>|<G3> |<G4>|<G5>|<G6>|<G7>|<G8> |<G9>| <G10>|<G11>| <G12>;
Etape 2: modélisation de l’état du système

-- définition de l'état du système

state ETAT of
registreOperations: set of OPERATION
registreGaranties : set of GARANTIE
registreAppels: set of OPERATION
registreConfirmations: set of OPERATION
validerPar : inmap OPERATION to GARANTIE
--invariant de l'état: très important!
inv mk_ETAT(registreOperations, registreGaranties, registreAppels,
registreConfirmations, validerPar) ==
dom validerPar subset registreOperations
and
rng validerPar subset registreGaranties
Etape 3: définition de l’état initial
--initialisation de l'état
init etatInitial ==
etatInitial = mk_ETAT(registreOperations0,
registreGaranties0 ,
{},
{} ,
validerPar0
)
end
registreOperations0 : set of OPERATION =
{op1,op2,op3,op4,op5,op6,op7,op8,op9};

registreGaranties0: set of GARANTIE =

{gr1, gr2, gr3,gr4, gr5, gr6, gr7};

validerPar0 : inmap OPERATION to GARANTIE

={
op1|->gr1,
op2|->gr2 ,
op3|->gr3,
op4|->gr4 ,
op5|->gr5 ,
op6|->gr6
};
--Etape 4 : Opérations modifiant l’état du système

--1-enregistrer les opérations au fur et mesure des prises de positions sur le

marché,
enregistrer: OPERATION ==> ETAT
enregistrer(operation) ==
(
registreOperations := registreOperations union {operation};
return mk_ETAT(registreOperations, registreGaranties,registreAppels,
registreConfirmations, validerPar)
)
pre true
post registreOperations = registreOperations~ union {operation} ;
--2-enregistrer un dépôt de garantie,
souscrire: GARANTIE ==> ETAT
souscrire(garantie) ==
( registreGaranties := registreGaranties union {garantie};
return mk_ETAT(registreOperations, registreGaranties, registreAppels,
registreConfirmations, validerPar)
)
pre true
post registreGaranties = registreGaranties~ union {garantie} ;
--3-valider une opération enregistrée par un dépôt de garantie,
valider: OPERATION * GARANTIE ==> ETAT
valider(operation, garantie) ==
(
validerPar:= validerPar munion {operation |-> garantie};
return mk_ETAT(registreOperations ,registreGaranties,registreAppels,
registreConfirmations, validerPar)
)

pre operation in set registreOperations and garantie in set

registreGaranties
and operation not in set dom validerPar
and garantie not in set rng validerPar
post validerPar = validerPar~ munion {operation |-> garantie} ;
--4-faire un « appel à la marge » en cas de perte potentielle sur une certaine
opération: la marge est calculée automatiquement
viser: OPERATION ==> ETAT
viser(operation) ==
(
registreAppels:= registreAppels union {operation};
return mk_ETAT(registreOperations,
registreGaranties, registreAppels,
registreConfirmations, validerPar)
)

pre operation in set dom validerPar

post
registreAppels = registreAppels~ union {operation};
--5-dénouer une opération (si l’«appel à la marge» visant l’opération n’est pas
suivi d’effet):l'invalider en conservant la garantie
-- pour indemniser la contrepartie
denouer: OPERATION ==>ETAT
denouer(operation) ==
(
validerPar := {operation} <-: validerPar ;
return mk_ETAT(registreOperation ,registreGaranties,
registreAppels, registreConfirmations, validerPar)

)
pre operation in set registreAppels
post
operation not in set dom validerPar
--6-confirmer la bonne fin d’exécution d’une opération: l’acheteur s’acquitte du
--montant auprès du vendeur et se voit restituer le dépôt de garantie

confirmer: OPERATION ==>ETAT

confirmer(operation) ==
(
validerPar := {operation} <-: validerPar ;
registreConfirmations := registreConfirmations union {operation};
registreGaranties := rng validerPar;
return mk_ETAT(registreOperations, registreGaranties,registreAppels,
registreConfirmations, validerPar)
)
pre operation in set dom validerPar
post validerPar = {operation} <-: validerPar~
and registreConfirmations = registreConfirmations~ union {operation}
and registreGaranties = rng validerPar ;
Etape 5: Opérations pour observer l’état du système

--l’ensemble des opérations enregistrés

enregistrées: () ==> set of OPERATION
enregistrées() ==
return registreOperations
pre true
post RESULT = registreOperations;

--l’ensemble des opérations validées (opérations couvertes par un dépôt de

garantie),
validées: () ==> set of OPERATION
validées()==
return dom validerPar
pre true
post RESULT= dom validerPar;
--l’ensemble des opérations visées par un «appel à la marge»,
visées: () ==> set of OPERATION
visées() ==
return registreAppels
pre true
post RESULT = registreAppels;

--l’ensemble des opérations dénouées: opérations appelées mais invalidées

(pour non réponse à l'appel à la marge)
denouées: () ==> set of OPERATION
denouées() ==
return registreAppels \ registreAppels inter dom validerPar
pre true
post RESULT = registreAppels \ registreAppels inter dom validerPar ;
--l’ensemble des opérations dont la bonne fin d’exécution est confirmée.
confirmées: () ==> set of OPERATION
confirmées() ==
return registreConfirmations
pre true
post RESULT = registreConfirmations;

end controleCompensations
 étape 3: Validation du modèle VdmSl

Phase 1 : Lancer le vérificateur d’intégrité pour la validation statique

L’opération consiste à vérifier toutes les obligations de preuves

générées automatiquement par l’atelier.
Phase2 : Lancer l’interpréteur pour la validation dynamique en exécutant
Les opérations du modèle

values

op1:OPERATION = <Op1>;
op2:OPERATION = <Op2>;
op3:OPERATION = <Op3>;
op4:OPERATION = <Op4>;
op5:OPERATION = <Op5>;
op6:OPERATION = <Op6>;
op7:OPERATION = <Op7>;
op8:OPERATION = <Op8>;
op9:OPERATION = <Op9>;
op10:OPERATION = <Op10>;
op11:OPERATION = <Op11>;
op12:OPERATION = <Op12>;
gr1:GARANTIE = <G1>;
gr2:GARANTIE = <G2>;
gr3:GARANTIE = <G3>;
gr4:GARANTIE = <G4>;
gr5:GARANTIE = <G5>;
gr6:GARANTIE = <G6>;
gr7:GARANTIE = <G7>;
gr8:GARANTIE = <G8>;
gr9:GARANTIE = <G9>;
gr10:GARANTIE = <G10>;
gr11:GARANTIE = <G11>;
gr12:GARANTIE = <G12>;

registreOperations0 : set of OPERATION =

{op1,op2,op3,op4,op5,op6,op7,op8,op9};
registreGaranties0: set of GARANTIE = {gr1, gr2, gr3,gr4, gr5,
gr6, gr7};
validerPar0 : inmap OPERATION to GARANTIE = {
op1|->gr1,
op2|->gr2 ,
op3|->gr3,
op4|->gr4 ,
op5|->gr5 ,
op6|->gr6
};
uneSituation:ETAT =mk_ETAT(registreOperations0 ,
registreGaranties0, {},{}, validerPar0);

end controleCompensations
 étape 4: Génération de code
On actionne le générateur Vdm/C++ ou Java(Overture) pour générer le
code source en C++. Ou Java.