examen de mai 2014 - Master informatique

Université Pierre et Marie Curie (UPMC) Master d'Informatique M1/STL/CPS
1
Examen de MI047 - CPS
Frédéric Peschanski
Mai 2014
Durée
: 2 heures
Documents autorisés
Barème
donné à titre indicatif.
: Notes de cours
Exercice 1 : Spécications et tests (≈ 7-8 points)
L'objectif de cet exercice est de spécier une version simpliée de la partie serveur du protocole
(IRC).
Voici le squelette de spécication du service IRC :
Internet Relay Chat
service : IRC
types : Boolean, Integer, enum UserRole { ADMIN, USER }, Set
observators :
userIds : [IRC] -> Set<Integer>
hasNick : [IRC] * Integer -> Boolean
userNick : [IRC] * Integer -> String
pre : userNick(S,id) require hasNick(S,id)
userId : [IRC] * String -> Integer
pre : userId(S,n) require hasNick(S,n)
userRole : [IRC] * Integer -> UserRole
pre : userRole(S,id) require id ∈ userIds(S)
channels : [IRC] -> Set<String>
channelAdmin : [IRC] * String -> Integer
pre : channelAdmin(S,chan) require chan ∈ channels(S)
userJoins : [IRC] * Integer -> Set<String>
pre : userJoins(S,id) require id ∈ userIds(S)
chanUsers : [IRC] * String -> Set<Integer>
pre : chanUsers(S,chan) require chan ∈ channels(S)
// A COMPLETER (si besoin)
constructors :
init : -> [IRC]
operators :
connect : [IRC] * Integer * UserRole -> [IRC]
pre : connect(S,id,role) require // A COMPLETER : Question 1.2
nick : [IRC] * Integer * String -> [IRC]
pre : nick(S,id,user) require // A COMPLETER : Question 1.3
create : [IRC] * String * String -> [IRC]
pre : create(S,user,chan) require // A COMPLETER : Question 1.4
join : [IRC] * String * String -> [IRC]
pre : join(S,user,chan) require // A COMPLETER : Question 1.5
observations :
[invariants]
// A COMPLETER : Question 1.1
...
// A COMPLETER : Observations des opérations, Questions 1.2, 1.3, etc.
...
Le service de IRC enregistre :
les identiants numériques (id) des utilisateurs du service,
les pseudos (nick names ou nick) de ces
mêmes utilisateurs, sachant qu'un utilisateur a au plus un nick name,
le rôle de chaque utilisateur : simple utilisateur (rôle USER) ou administrateur
(rôle ADMIN),
les canaux de discussion identiés par
des chaînes de caractères (channels),
les utilisateurs administrateurs de canaux, sachant que chaque canal a exactement un administrateur,
les abonnements (joins) des utilisateurs
aux canaux de discussion. Un même utilisateur peut s'abonner à plusieurs canaux.
Les opérations principales du service sont :
la connection (connect) d'un nouvel utilisateur au service avec un identiant unique et un rôle spécié,
l'association d'un nick name (nick) à un identiant d'utilisateur,
la création d'un canal de discussion par son administrateur (create),
l'abonnement (join) d'un utilisateur à un canal de discussion existant.
Dénir les invariants de la spécication, en particulier les invariants de minimisation (au moins trois
dans cette spécication) ainsi qu'au moins :
Invariant utile : deux utilisateurs d'id diérents ne peuvent avoir le même nick name.
Invariant utile : les canaux auxquels sont abonnés des utilisateurs sont bien des canaux existants.
Question 1.1
Compléter la spécication pour ajouter l'opération connect de connexion d'un nouvel utilisateur au
service IRC. Il faut préciser la précondition de l'opération ainsi que les observations associées.
Question 1.2
Université Pierre et Marie Curie (UPMC) Master d'Informatique M1/STL/CPS
2
: si le domaine et le codomaine d'un observateur OBS restent inchangés, alors on écrira simplement OBS
inchangé. S'il ne reste que des observateurs inchangés, alors on peut écrire le reste inchangé.
Remarque
Question 1.3
Même question pour l'opération nick.
Question 1.4
Même question pour l'opération
canal de discussion.
create.
Même question pour l'opération
plusieurs canaux de discussion.
join.
Question 1.5
Nous rappelons que seul un administrateur peut créer un
Nous remarquons qu'un même utilisateur peut s'abonner à
Question 1.6 Par sécurité, les opérations connect, create et join devraient être convergentes. Est-ce le cas dans notre
spécication ? Si c'est le cas, donner le critère de convergence pour chaque opération, sinon modier la spécication
pour corriger ce problème. On pourra notamment ajouter des observateurs si nécessaire.
Remarque : la décroissance stricte du critère de convergence sera justiée de manière informelle.
Exercice 2 : Modélisation de systèmes concurrents (≈ 5-6 points)
Dans cet exercice, nous utilisons le langage FSP pour modéliser une version simpliée de protocole de communication
sur canal non-able.
Question 2.1
Un premier modèle de notre système est exprimé en FSP de la façon suivante :
const N = 3
SENDER = SENDER[1],
SENDER[i:1..N] = (send[i] -> SENDER[i+1]),
SENDER[N+1] = STOP.
RECEIVER = RECEIVER[1],
RECEIVER[i:1..N] = (recv[i] -> RECEIVER[i+1]
|pass[i] -> RECEIVER[i+1]),
RECEIVER[N+1] = STOP.
CHANNEL = CHANNEL[1],
CHANNEL[i:1..N] = (input[i] -> CHOICE[i]),
CHOICE[i:1..N] = (success -> output[i] -> CHANNEL[i+1]
| fail -> lost[i] -> CHANNEL[i+1]),
CHANNEL[N+1] = STOP.
||SYSTEM = ( SENDER || RECEIVER || CHANNEL )/send[i:1..N]/input[i],
recv[i:1..N]/output[i],
lost[i:1..N]/pass[i].
||SPEC = (SYSTEM)\{success,fail}.
Dessiner l'automate de la spécication ||SPEC une fois minimisée.
Le système précédent perd des messages. Introduire un protocole de réémission de message fonctionnant de la façon suivante :
L'émetteur (SENDER) réemet le message courant tant qu'il ne reçoit pas le paquet de conrmation (action ack)
de la part du receveur. S'il reçoit le ack alors il passe au message suivant.
Le récepteur émet le paquet ack s'il reçoit bien le message courant, sinon il se remet en attente du message
courant.
Le processus CHANNEL est légèrement modié de la façon suivante :
Question 2.2
Université Pierre et Marie Curie (UPMC) Master d'Informatique M1/STL/CPS
3
CHANNEL = CHANNEL[1],
CHANNEL[i:1..N] = (input[i] -> CHOICE[i]),
CHOICE[i:1..N] = (success -> output[i] -> CHANNEL[i+1]
| fail -> lost[i] -> CHANNEL[i]),
CHANNEL[N+1] = STOP.
On suppose également que la spécication est modiée :
||SPEC = (SYSTEM)\{success,fail,ack}.
Donner les dénitions modiées des processus SENDER et RECEIVER.
Question 2.3 (bonus) Le protocole de conrmation par ack suppose que la communication des paquets de contrôle
est able. Proposer, de façon informelle, une modication du protocole qui permette la communication able avec
perte potentielle des paquets ack.
Exercice 3 : Logique de Hoare (≈ 7-8 points)
Question 3.1
Faire la démonstration de correction du triplet de Hoare suivant :
def
{P RE = tab.length > 0}
{
var n
a = tab[0]
b = tab[0]
n = 1
while(n < tab.length) {
if (tab[n] < a) {
a = tab[n]
} else if (tab[n] > b) {
b = tab[n]
} else skip
n = n + 1
}
}
def
{P OST = tab.length > 0
∧ ∀i ∈ [0..tab.length−1], a≤tab[i]≤b
∧ ∃j ∈ [0..tab.length−1], tab[j ]=a
∧ ∃k ∈ [0..tab.length−1], tab[k]=b }
:
1. l'opération skip est une opération silencieuse dont la caractérisation en logique de Hoare est simplement l'axiome
Remarques
(skip)
suivant : {Q} skip {Q}
2. Dans la preuve l'étape (invariant ∧ condition vraie =⇒ precondition du corps) pour la boucle while ( ... ) doit
être clairement détaillée. Normalement c'est l'étape [9] dans le raisonnement (si on saute les blocs lexicaux
sans déclaration de variable locale).
3. Nommer chaque condition non-triviale dans la preuve (comme P RE et P OST ci-dessus) pour pouvoir y faire
référence sans tout recopier.
Si on appelle PROG1 le programme de la question précédente, alors on s'intéresse maintenant au
programme suivant :
Question 3.2
def
{P RE = tab.length > 0}
PROG1
def
{P OST = tab.length > 0
∧ ∀i ∈ [0..tab.length−1], a≤tab[i]≤b
∧ ∃j ∈ [0..tab.length−1], tab[j ]=a
∧ ∃k ∈ [0..tab.length−1], tab[k]=b }
// suite ...
Université Pierre et Marie Curie (UPMC) Master d'Informatique M1/STL/CPS
n = 0;
while(n < tab.length) {
if(tab[n] < a) {
cpy[n] = a ;
} else if (tab[n] > b) {
cpy[n] = b ;
} else {
cpy[n] = tab[n] ;
}
n = n + 1;
}
{P OST 2}
Proposer une dénition intéressante 1 pour la postcondition P OST 2.
Question 3.3 (bonus)
1.
false
Faire une démonstration du triplet {P OST } n=0 ; while(. . . ) . . . {P OST 2}.
est un exemple de postcondition inintéressante.
4