Modélisation UML pour le test et la découverte des dépendances

1. COPS - 29-30 mars 2007 Nancy, LORIA Modélisation UML pour le test et la découverte des dépendances Vincent Pretre Sous la direction de Fabrice Bouquet et Christophe Lang Laboratoire d’informatique de Franche-Comté

2. Introduction Modélisation pour le test Représentation des données utilisées Représentation des SW Evolution dans le temps Etat initial Modélisation des relations Compositions Dépendance temporelles Utilisation du modèle Découverte Notion de groupe Test des services Notation des services Conclusion et travaux futurs Sommaire

3. Introduction Modélisation pour le test Modélisation des relations Utilisation du modèle Conclusion et travaux futurs Services et services web Confiance dans les SW Réseau Développement & fournisseur Supports d’hébergements Relations entre services Compositions Dépendances temporelles Une plateforme de test Un modèle unique Sommaire

4. IntroductionServices et services web • Système client serveur • Echanges XML • Service web: ensemble de services proposés par un même fournisseur ayant une cohérence fonctionnelle • Service: opération proposée par un service web • Comportement: exécution particulière d’un service

5. IntroductionLa confiance dans les services web • Dépend de deux éléments • La qualité des résultats • La gestion des données • Reposent sur quatre facteurs : • Le réseau utilisé pour l’échange des messages • Le soin apporté au développement du service • L'hébergement du service • Les services liés

6. IntroductionLa confiance dans les SW - Réseau • Perte ou altération des données : • Résultats justes à l’envoi mais erronés à la réception • SW payants: coûts doublés • Attaques des données échangées : • Suppression ou corruption • Vol de données confidentielles

7. IntroductionLa confiance dans les SW - Développement & fournisseur • Soin apporté dans le développement : • Comportements inaccessibles • Résultats incorrects et/ou incomplets • Mauvais comportement vis à vis des autres services • Backdoors / failles de sécurités • Honnêteté du fournisseur : • Divulgation des données personnelles • Utilisation de ces données

8. IntroductionLa confiance dans les SW - Supports d’hébergement • Hébergement physique : • Perte des données • Fonctionnement discontinu • Hébergement logiciel : • Fonctionnement discontinu • Vol, perte ou corruption de données • Librairies buggées • Backdoors/failles de sécurité • Incompatibilités entre versions Service web Serveur web Autres applications Système d’exploitation Couche matérielle

9. Introduction Composition - Définition • Composition: utilisation d’un service par un autre • Trois critères : • Locale/distribuée • Synchrone/asynchrone • Statique/dynamique Client WS Agence WS Companie WS banque WS Hôtel

10. Introduction Composition - Problèmes • Calculs basés sur des données fausses • Propagation des erreurs • Quelques cas particuliers • Propagation des temps de calcul (compositions synchrones) • Appels qui ne terminent pas • Utilisation de services inconnus (composition dynamique) • Qualité des résultats • Temps de calcul

11. Introduction Dépendance temporelle - Définition • Un service ne peut être appelé que si un autre l’a déjà été • Deux causes : • Partage de données coté serveur • Partage de données devant être manipulées par le client • Deux types : • Le service x doit être appelé au moins une fois pour que le service y fonctionne • Le service x doit être appelé chaque fois avant l’appel à y Base de données insertion lecture Envoi du résultat réutilisation Client

12. Introduction Dépendance temporelle - Problèmes soulevés • Dysfonctionnements amenant à des appels impossibles • Le service « login » dépend du service « register » • Si « register » ne fonctionne pas, « login » ne fonctionnera pas • Fonctionnement sur des données fausses/incomplètes • « createBooking » dépend de « searchFlights » • Si « searchFlights » ne renvoie pas la bonne liste de vol, « bookFlight » devra s’en contenter

13. IntroductionLa plate-forme de test • Vérifie la qualité apporté dans le développement • Basée sur un serveur UDDI • Notation des services enregistrés • Test générés à partir d’un modèle UML Serveur UDDI Service 1 - Déclaration 2 : Exécution des test 3 : envoi du modèle Testeurs 4 : recherche de services Client 5 : envoi des résultats et des notes

14. IntroductionUn modèle unique • Trois buts: • Représentation du fonctionnement • Description des compositions • Description des dépendances temporelles • Avantages du choix d’UML: • Plusieurs vues • Langage répandu • Un seul modèle à mettre à jour • Inconvénient: • Peut être moins efficace que des modèles spécialisés

15. Introduction Modélisation pour le test Modélisation des dépendances Utilisation du modèle Conclusion et travaux futurs Représentation des données utilisées Représentation des SW Evolution dans le temps Etat initial Sommaire

16. Modélisation pour le testReprésentation des données utilisées • Diagramme de classes • Principalement pour les services accédant à une base de données • Peut être utilisé pour les données complexes • Modélisation « classique » des objets: • Uniquement les données utiles sont modélisées • Pas de méthodes validationRights Mission status Employee level Group

17. Modélisation pour le testReprésentation des services web • Chaque service web est représenté par une classe • Deux attributs identifient le service web : • Son URL • Son port • Chaque service est représenté par une opération services

18. Modélisation pour le testServices réels et services modélisés • Division des services pour arriver à des relations « constantes » • Le service « cancel » permet d’annuler une réservation, avant ou après paiement • Modélisé en deux services • « cancelBeforePaiment » • « cancelAfterPaiment », qui compose un service web bancaire pour le remboursement

19. Modélisation pour le testFonctionnement des services • Utilisation d’OCL • Deux choix de modélisation: • Offensive • Défensive • Offensive: • Pas de gestion d’erreurs • Cas impossibles gérés en pré-condition • Défensive: • Pas de pré-condition • Erreurs possibles modélisées Pré-condition: self.mission.status = waitingValidation and self.mission.employee != self.user Post-condition: if then if answer then self.mission.status = validated else self.mission.status = refused endif if then result = okelse result = autoValidationendifelse result = unvalidableMissionendif

20. Modélisation pour le testEvolution dans le temps • Utilisation d’un diagramme d’états-transitions • Utile uniquement pour les service utilisant des données évoluant dans le temps • Chaque appel à un service est représenté par une transition • Les états du modèle ne font pas toujours référence à des états existants • Doit représenter tous les cas d’utilisation missionCreated tmpRemove wsDeployed tmpGrant userLoggedIn tmpValidate validateOk errorType7 errorType1 errorType6 errorType2 errorType5 errorType3 errorType4

21. Modélisation pour le testEtat initial • Diagramme d’instances • Représente l’état du système avant l’exécution des tests • Echantillon représentatif des données utilisées • De bons choix facilitent la génération des tests Group::blue ValidationRight::blue Employee::blueMember1 level=4 Employee::blueLeader level=3 Mission::mission1 status = waitingValidation Mission::mission2 status = empty Mission::mission3 status = empty Employee::fakeEmployee level=0

22. Introduction Modélisation pour le test Modélisation des relations Utilisation du modèle Conclusion et travaux futurs Compositions OCL Diagrammes de séquencew Méthode choisie Dépendances temporelles Diagramme d’états-transitions Diagramme de séquences Méthode choisie Sommaire

23. Solution la plus « logique » L’appel à un autre service est modélisé comme un appel de fonction Placé dans les post-conditions Les compositions sont toutes considérées comme synchrones Exemple: confirmation de paiement self.reservation.status = confirmed and self.bankWS.pay() and self.companyWS.confirm() and self.log() Modélisation des relationsComposition - utilisation d’OCL

24. Modélisation des relationsComposition - diagramme de séquences • Représentation plus visuelle • Permet de gérer les compositions asynchrones • Un diagramme par service • Nécessite un ajout de services • De nombreuses adaptations sont nécessaires pour un passage sous LTD Client Agency Company Bank 1:confirm 1.1:confirm 1.1.1:ok 1.2:pay 1.2.1:ok 1.3:log

25. Modélisation des relationsComposition - solution choisie • Mélange des deux solutions précédentes • OCL permet de modéliser les appels aux autres services • Le diagramme de séquences indique si la composition est synchrone • Peu de modifications pour un passage dans LTD • Permet de découvrir les compositions sans effet • Nécessite une double modélisation Client Agency Company Bank 1:confirm 1.1:confirm 1.1.1:ok self.reservation.status = confirmed and self.bankWS.pay() and self.companyWS.confirm() and self.log()

26. Modélisation des relationsDépendances temporelles - diagramme d’état-stransitions • Déjà présent dans le modèle • Découverte des relations: • Transformation du diagramme en graphe • États -> Arcs • Transition -> Sommets • Suppression des chemins directs redondants • Chaque arc restant est une dépendance temporelle login searchFlight createBooking confirmBooking cancelBooking1 cancelBooking2

27. Modélisation des relationsDépendances temporelles - diagramme de séquences • Un diagramme par service • Permet de séparer les deux types de dépendances temporelles • Nécessite une double modélisation Client Self 1: register 2: login 3: login 1: searchFlights 2: createBooking

28. Modélisation des relationsDépendances temporelles - solution choisie • Le diagramme d’états-transitions permet de découvrir les relations • Le diagramme de séquences établi leur type • Double modélisation pour les dépendances de type « au moins une fois » userRegistered userLoggedIn Client Self 1: register 2: login 3: login

29. Introduction Modélisation pour le test Modélisation des relations Utilisation du modèle Conclusion et travaux futurs Découverte des relations Notion de groupe Test des services Notation des services Sommaire

30. Utilisation du modèleDécouverte des relations • Exportation du modèle en XMI (XML Metadata Interchange) • Outil écrit en Python : • Découverte des services • Découverte des dépendances • Fusion des différents modèles

31. Chaque service possède un groupe principal composé des services dont il dépend Un service peut appartenir à plusieurs groupes Calcul des groupes: Création du graphe de dépendances Services -> sommets Dépendances -> arcs Calcul de la fermeture transitive Tous les voisins d’un service sont ajoutés à son groupe principal Permet de calculer l’ordre de passage des tests Utilisation du modèleNotion de groupe

32. Utilisation du modèleTest des services • Exportation du modèle UML en projet LTD (Leirios Test Designer) • Calcul des cibles de test: • Etats du diagramme d’états-transitions • Comportements du service • Génération, puis exécution des tests • Verdict par comparaison avec l’oracle

33. Pour chaque service, le résultat des tests permet de donner une note Echelle non linéaire Dans le cas de services séparés à la modélisation, la note la plus basse compte Une fois tous les services notés, on ajuste la note en fonction des dépendances 0 - Service non testé 1 - Mauvais typage 2 - Typage partiellement incorrect 3 - Typage correct 4 - Réponses fausses 5 - Réponses partiellement fausses 6 - Réponses correctes Utilisation du modèleNotation des services

34. Introduction Relations entre services Modélisation pour le test Modélisation des relations Utilisation des dépendances Conclusion et travaux futurs Avantages et inconvénients Travaux à réaliser Sommaire

35. Conclusion et travaux futursAvantages et inconvénients de cette méthode • Points positifs: • Modèle unique • Langage connu et répandu • Permet de prendre en compte la plupart des cas • Le client peut évaluer la qualité du service qu’il va utiliser • Point négatifs: • Moins efficace que trois modèles différents • Ne couvre qu’une partie des problèmes de confiance

36. Conclusion et travaux futursPerspectives • Terminer l’outil de découverte des dépendances • Mettre en place la fusion des modèles • Valider la plate-forme de test • Réfléchir sur des solutions aux autres sources du manque de confiance