La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

1 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 dinformatique.

Présentations similaires


Présentation au sujet: "1 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 dinformatique."— Transcription de la présentation:

1 1 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 dinformatique de Franche-Comté COPS mars 2007 Nancy, LORIA

2 2 Sommaire 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

3 3 Sommaire 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 dhébergements Relations entre services Compositions Dépendances temporelles Une plateforme de test Un modèle unique

4 4 Introduction Services 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 dun service

5 5 Introduction La 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 6 Introduction La confiance dans les SW - Réseau Perte ou altération des données : Résultats justes à lenvoi 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 7 Introduction La 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 8 Introduction La confiance dans les SW - Supports dhé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 Couche matérielle Système dexploitation Autres applications Serveur web Service web

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

10 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 11 Introduction Dépendance temporelle - Définition Un service ne peut être appelé que si un autre la 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 lappel à y Base de données insertionlecture Client Envoi du résultatréutilisation

12 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 sen contenter

13 13 Introduction La 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 dun modèle UML Service Serveur UDDI 1 - Déclaration Testeurs 2 : Exécution des test 3 : envoi du modèle Client 4 : recherche de services 5 : envoi des résultats et des notes

14 14 Introduction Un modèle unique Trois buts: Représentation du fonctionnement Description des compositions Description des dépendances temporelles Avantages du choix dUML: 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 15 Sommaire 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

16 16 Modélisation pour le test Repré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 Employee level Mission status Group

17 17 Modélisation pour le test Repré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 18 Modélisation pour le test Services réels et services modélisés Division des services pour arriver à des relations « constantes » Le service « cancel » permet dannuler 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 19 Modélisation pour le test Fonctionnement des services Utilisation dOCL Deux choix de modélisation: Offensive Défensive Offensive: Pas de gestion derreurs 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 answer then self.mission.status = validated else self.mission.status = refused endif ifthen ifthen result = ok else result = autoValidation endif else result = unvalidableMission endif

20 20 Utilisation dun 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 dutilisation Modélisation pour le test Evolution dans le temps userLoggedIn wsDeployed tmpValidate validateOk errorType1errorType6 errorType2errorType5 errorType3errorType4 errorType7 tmpGrant tmpRemove missionCreated

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

22 22 Sommaire 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

23 23 Modélisation des relations Composition - utilisation dOCL Solution la plus « logique » Lappel à 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()

24 24 Modélisation des relations Composition - 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 ClientAgencyCompanyBank 1:confirm 1.1:confirm 1.1.1:ok 1.2.1:ok 1.2:pay 1.3:log

25 25 Modélisation des relations Composition - 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 self.reservation.status = confirmed and self.bankWS.pay() and self.companyWS.confirm() and self.log() ClientAgencyCompanyBank 1:confirm 1.1:confirm 1.1.1:ok

26 26 Modélisation des relations Dé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 27 Modélisation des relations Dé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 28 Modélisation des relations Dé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 » Client Self 1: register 2: login 3: login userLoggedInuserRegistered

29 29 Sommaire 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

30 30 Utilisation du modèle Dé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 31 Utilisation du modèle Notion de groupe 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 dun service sont ajoutés à son groupe principal Permet de calculer lordre de passage des tests

32 32 Utilisation du modèle Test 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 loracle

33 33 Utilisation du modèle Notation des services 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

34 34 Sommaire 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

35 35 Conclusion et travaux futurs Avantages 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 quil va utiliser Point négatifs: Moins efficace que trois modèles différents Ne couvre quune partie des problèmes de confiance

36 36 Conclusion et travaux futurs Perspectives Terminer loutil 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


Télécharger ppt "1 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 dinformatique."

Présentations similaires


Annonces Google