Test dans les objets DESS Andrés Farias –

Plan Introduction Quest-ce quun objet? Quest-ce quune classe? Descriptions des comportements Méthodologies formelles Propriétés dintérêt à les objets Les tests dans les objets avec une description comportementale.

Quest-ce quun objet? Un objet est composé de : Interface Implémentation Collaborateurs Documentation Documentation écrite Commentaires dans le code Documentation formelle.

Quest-ce que le type dun objet? Le « type » dun objet Le type dun objet contient tout linformation nécessaire pour pouvoir parler du comportement dun objet. pile push(Elem) Elem pop() InterfaceImplémentation Visible Pas visible

Quest-ce que le type dun objet? Mais les types dans les langages comme Java nous disent « juste » : Les messages quun objet peut recevoir. Les types de paramètres de ce message. Le type de lobjet rendu par le message. Les attributs (et leurs types!!!) publics et privés!

Quest-ce que le type dun objet? Les problèmes: Les types déterminés par les classes rompent lencapsulation de lobjet! Les types déterminés par les interfaces (en Java) ne nous disent pas tous les moyens pour communiquer avec lobjet. Ex: les attributs dun objet.

Documentation dun objet La documentation contient plusieurs éléments : Description de chaque service dans linterface Spécification des contraintes expliquant la dynamique du composant, i.e., le comportement Description des relations de dépendance entre les services offerts Description des services requis

Exemple : le Buffer put(objet)get(): objet unObjet Buffer put(objet) get(): objet) estVide(): boolean

Spécification dun composant (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 limplementation : int pop(){ If (this.isEmpty()) throw new StackNotReadyForPopingExeption; … } void push(int e){ if (this.isFull()) throw new StackNotReadyForPopingExeption; … }

Spécification dun composant (3) Les choses gênantes : La spécification reste séparée de la structure «physique » dun composant Des 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 dun objet Développement Assemblage Déploiement Exécution

Les 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 lencapsulation, le sous typage et le polymorphisme.

Les approaches formelles -Calculus Hérite directement du Lamda-calculus Notion dun « 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 formelles Cest 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 objets 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 objets actives Disponibilité de Services nest 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 objets 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 (1/4) Les types des services ne spécifient pas quand les services sont disponibles. Les séquences de requêtes quun objet est capable de répondre constituent le protocole de lobjet. Les objets peuvent être vus comme un système à transitions.

Substituabilité des Requêtes (2/4) Traces sont toutes les séquences valides. Première condition pour la substituabilité : p :< q alors traces q traces p Deuxième condition pour la substituabilité : Après avoir accepté une séquence s traces q le protocole p ne devrait pas refuser une transition que le protocole q ne refuse pas. a a ab b pq

Substituabilité des Requêtes (3/4) Défaillances: décrivent les transitions qui sont refusées après acceptation dune séquence valide. Dans lexemple, 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 ab b pq

Substituabilité des Requêtes (4/4) Deuxième condition: Protocole p ne doit pas introduire de nouvelles défaillances qui nexistent pas dans q. failures(p) failures(q) a a ab b p q b b p aa b

Lintégration semble nécessaire! Les avantages possibles : Une vérification statique ou dynamique peut être faite Spécifications liées à limplé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

Lintégration semble nécessaire! Extraction et vérification : Nous définissons un protocole au niveau du design. Nous extractions le protocole à partir de limplémentation. Nous comparons et modifions le protocole au niveau de limplémentation relativement au protocole au niveau de spécification. Nous modifions limplémentation en fonction du nouveau protocole au niveau dimplémentation. ab a a b Protocole au niveau de la spécification Protocole au niveau de limplémentation

Conclusions Une interface plus riche peut nous dire bien plus de choses sur le comportement dun objet. Avec des protocoles au niveau de linterface 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 Sur les langages à objets : Les langages à objets ( Langages de classes, langages de frames, langages dacteur ) : G. Masini, A. Napoli, D. Colnet, D. Léonard et K. Tombre InterEditions (1991 : 3 ème édition) Langages à objets : JF. Perrot Techniques de lingénieur, traité informatique Sur le concept de package : Java les packages