Test dans les objetsTest dans les objets

DESSAndrés Farias – afarias@emn.fr

http://www.emn.fr/farias/dessgl/

PlanPlan

IntroductionQu’est-ce qu’un objet?Qu’est-ce qu’une classe?

Descriptions des comportements Méthodologies formelles

Propriétés d’intérêt à les objets Les tests dans les objets avec une

description comportementale.

Qu’est-ce qu’un objet?Qu’est-ce qu’un objet?

Un objet est composé de : Interface Implémentation

• Collaborateurs

Documentation• Documentation écrite• Commentaires dans le

code• Documentation

formelle.

Qu’est-ce que le type d’un Qu’est-ce que le type d’un objet?objet?

Le « type » d’un objet Le type d’un objet contient tout

l’information nécessaire pour pouvoir parler du comportement d’un objet.

pile

push(Elem)

Elem pop()

InterfaceImplémentation

VisiblePas visible

Qu’est-ce que le type d’un Qu’est-ce que le type d’un objet?objet?

Mais les types dans les langages comme Java nous disent « juste » : Les messages qu’un objet peut

recevoir. Les types de paramètres de ce

message. Le type de l’objet rendu par le

message. Les attributs (et leurs types!!!) publics

et privés!

Qu’est-ce que le type d’un Qu’est-ce que le type d’un objet?objet?

Les problèmes: Les types déterminés par les classes

rompent l’encapsulation de l’objet! Les types déterminés par les interfaces

(en Java) ne nous disent pas tous les moyens pour communiquer avec l’objet. Ex: les attributs d’un objet.

Documentation d’un objetDocumentation d’un objet

La documentation contient plusieurs éléments :Description de chaque service dans l’interfaceSpécification des contraintes expliquant la

dynamique du composant, i.e., le comportementDescription des relations de dépendance entre les

services offertsDescription des services requis

Exemple : le BufferExemple : le Buffer

put(objet) get(): objetunObjet

Buffer

put(objet)

get(): objet)

estVide(): boolean

Spécification d’un composant Spécification d’un composant (2)(2)

Ma documentation de mon buffer de taille 1 dit :On peut pas faire get() si le buffer est vide.On ne peut pas faire put() si le buffer est remplis.

Traduit dans l’implementation :

int pop(){If (this.isEmpty()) throw new StackNotReadyForPopingExeption;

… }

void push(int e){if (this.isFull())

throw new StackNotReadyForPopingExeption;… }

Spécification d’un composant Spécification d’un composant (3)(3)

Les choses gênantes :La spécification reste séparée de la structure

«physique » d’un composantDes outils sont nécessaires pour mieux «

spécifier » ou faire des vérifications : XML, UML, StateCharts

Vérification des erreurs coûteuse et compliquée, où erreur est définite comme : incohérence entre spécifications et implémentation

Le « cycle » de vie d’un objetLe « cycle » de vie d’un objet

Développement

Assemblage

Déploiement

Exécution

Les approaches formellesLes approaches formelles

Lambda-calculus : Dans la base de la théorie de la

programmation par objets. Les services sont représentés par de

fonctions. Permet de raisonner sur des concepts

abstraits telles que l’encapsulation, le sous typage et le polymorphisme.

Les approaches formellesLes approaches formelles

-Calculus Hérite directement du Lamda-calculus Notion d’un « objet actif » équivalent à

un objet concurrent, tournant dans son propre processus léger (thread).

Ces objets actifs ont une disponibilité non uniforme de ces services.

push

pop

Les approaches formellesLes approaches formelles

C’est devenu à la mode voir les objets comme de processus : CCS: Communication and Concurrency

Systems CSP: Communicating Sequential Processes

Type de services requête & réponse de messages

Types réguliers disponibilité de services

Types, Substituabilité et Types, Substituabilité et objets activesobjets actives

Les Types sont des spécifications partielles de comportement de valeurs dans un domaine spécifique.

Sous typage est un type particulier de spécialisation :S ≤ T ssi x:S alors x:T

Types, Substituabilité et Types, Substituabilité et objets activesobjets actives

Disponibilité de Services n’est pas forcement uniforme. Les Types devraient décrire la

disponibilité des services aussi! Avantage:

Les objets ne vont pas être susceptibles de deadlock à cause de erreurs de protocoles.

Types, Substituabilité et Types, Substituabilité et objets activesobjets actives

Les Objets sont considérés comme des processus avec de la communication.

Un objet accepte des requête de services, envoie des requêtes et envoie et reçoit des réponses.

Disponibilité des services changent dans le temps.

Accept requests

send requests

receive replies

send replies

Accept requests

Substituabilité des Requêtes Substituabilité des Requêtes (1/4)(1/4)

Les types des services ne spécifient pas quand les services sont disponibles.

Les séquences de requêtes qu’un objet est capable de répondre constituent le protocole de l’objet.

Les objets peuvent être vus comme un système à transitions.

Substituabilité des Requêtes Substituabilité des Requêtes (2/4)(2/4)

Traces sont toutes les séquences valides. Première condition pour la substituabilité :

p :< q alors tracesq tracesp

Deuxième condition pour la substituabilité :Après avoir accepté une séquence s tracesq

le protocole p ne devrait pas refuser une transition que le protocole q ne refuse pas.

a

a

a bbpq

Substituabilité des Requêtes Substituabilité des Requêtes (3/4)(3/4)

Défaillances: décrivent les transitions qui sont refusées après acceptation d’une séquence valide.

Dans l’exemple, les défaillances de q montrent que la transition a est refusée après avoir accepté la séquence a. Dans le protocole p, les transitions a et b sont refusées après avoir accepté la séquence a.

a

a

a bbpq

Substituabilité des Requêtes Substituabilité des Requêtes (4/4)(4/4)

Deuxième condition: Protocole p ne doit pas introduire de

nouvelles défaillances qui n’existent pas dans q.

failures(p) failures(q)

a

a

a bbpq

b

bp’

a a

b

L’intégration semble L’intégration semble nécessaire!nécessaire!

Les avantages possibles :Une vérification statique ou

dynamique peut être faiteSpécifications liées à

l’implémentation peuvent maintenant faire partie du composant

Des aspects tels que la composition peuvent être spécifiés dans le composant lui-même permettant une formalisation (enfin !) de notions qui jusqu’à maintenant restent floues

L’intégration semble L’intégration semble nécessaire!nécessaire!

Extraction et vérification :Nous définissons un protocole

au niveau du design.Nous extractions le protocole à

partir de l’implémentation. Nous comparons et modifions

le protocole au niveau de l’implémentation relativement au protocole au niveau de spécification.

Nous modifions l’implémentation en fonction du nouveau protocole au niveau d’implémentation.

a b

a

a

b

Protocole au niveau de la spécification

Protocole au niveau de l’implémentation

ConclusionsConclusions

Une interface plus riche peut nous dire bien plus de choses sur le comportement d’un objet.

Avec des protocoles au niveau de l’interface on peut rendre explicites des descriptions faite au niveau de la documentation. Ceci nous évite de réduire les test que nous devrions faire une fois que tous les objets ont été mis en relation.

Bibliographie Bibliographie

Sur les langages à objets :Les langages à objets (Langages de classes,

langages de frames, langages d’acteur) : G. Masini, A. Napoli, D. Colnet, D. Léonard et K. Tombre InterEditions (1991 : 3ème édition)

Langages à objets : JF. Perrot Techniques de l’ingénieur, traité informatique

Sur le concept de package : Java les packages http://www.commentcamarche.net/java