1 modélisation uml pour le test et la découverte des dépendances vincent pretre sous la direction...

1

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

dépendances

Vincent PretreSous la direction de Fabrice Bouquet

et Christophe Lang

Laboratoire d’informatique de Franche-Comté

COPS - 29-30 mars 2007Nancy, LORIA

2

Sommaire

Introduction

Modélisation pour le testReprésentation des données utilisées

Représentation des SW

Evolution dans le temps

Etat initial

Modélisation des relationsCompositions

Dépendance temporelles

Utilisation du modèleDécouverte

Notion de groupe

Test des services

Notation des services

Conclusion et travaux futurs

3

Sommaire

Introduction

Modélisation pour le test

Modélisation des relations

Utilisation du modèle


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

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émentsLa 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

Couche matérielle

Système d’exploitation

Autres applications

Serveur web

Service web

9

Introduction Composition - Définition

Composition: utilisation d’un service par un autre

Trois critères :Locale/distribuée

Synchrone/asynchrone

Statique/dynamique

WS Agence

Client

WS Companie

WS banque WS Hôtel

10

Introduction Composition - Problèmes

Calculs basés sur des données faussesPropagation 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é serveurPartage 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 fonctionneLe service x doit être appelé chaque fois avant l’appel à y

Base de données

insertion lecture

Client

Envoi du résultat réutilisation

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

ServiceServeur UDDI

1 - Déclaration

Testeurs

2 : Exécution des test

3 : envoi du m

odèle

Client

4 : recherche de services

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

Sommaire

Introduction


Modélisation des dépendances



Représentation des données utilisées

Représentation des SW

Evolution dans le temps

Etat initial

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

Employee

level

Mission

status

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’OCLDeux choix de modélisation:

OffensiveDéfensive

Offensive:Pas de gestion d’erreursCas impossibles gérés en pré-condition

Défensive:Pas de pré-conditionErreurs possibles modélisées

Pré-condition:

self.mission.status = waitingValidationand

self.mission.employee != self.user

Post-condition:

if answer then self.mission.status = validatedelse self.mission.status = refusedendif

if thenif then

result = ok else result = autoValidation endif else result = unvalidableMissionendif

20

Utilisation d’un diagramme d’états-transitionsUtile uniquement pour les service utilisant des données évoluant dans le tempsChaque appel à un service est représenté par une transitionLes états du modèle ne font pas toujours référence à des états existantsDoit représenter tous les cas d’utilisation

Modélisation pour le testEvolution dans le temps

userLoggedIn

wsDeployed

tmpValidate

validateOk

errorType1 errorType6



errorType7

tmpGrant

tmpRemove missionCreated

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

Mission::mission1status = waitingValidation

Mission::mission2status = empty

Mission::mission3status = emptyEmployee::fakeEmployee

level=0

Employee::blueLeaderlevel=3

Group::blue

Employee::blueMember1level=4

ValidationRight::blue

22

Sommaire

Introduction





Compositions• OCL

• Diagrammes de séquencew

• Méthode choisie

Dépendances temporelles• Diagramme d’états-transitions

• Diagramme de séquences

• Méthode choisie

23

Modélisation des relationsComposition - utilisation d’OCL

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()

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.1:ok

1.2:pay

1.3:log

25

Modélisation des relationsComposition - solution choisie

Mélange des deux solutions précédentesOCL 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 LTDPermet de découvrir les compositions sans effetNécessite une double modélisation

self.reservation.status = confirmed and

self.bankWS.pay() and

self.companyWS.confirm() and

self.log()

Client Agency Company Bank

1:confirm

1.1:confirm

1.1.1:ok

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

confirmBookingcancelBooking1

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 relationsLe diagramme de séquences établi leur typeDouble modélisation pour les dépendances de type « au moins une fois »

Client Self

1: register

2: login

3: login

userLoggedInuserRegistered

29

Sommaire

Introduction




Conclusion et travaux futursDécouverte des relations

Notion de groupe

Test des services

Notation des services

30

Utilisation du modèleDécouverte des relations

Exportation du modèle en XMI (XML Metadata Interchange)

Outil écrit en Python :Découverte des servicesDécouverte des dépendancesFusion des différents modèles

31

Utilisation du modèleNotion 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 d’un service sont ajoutés à son groupe principal

Permet de calculer l’ordre de passage des tests

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

Utilisation du modèleNotation 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

Sommaire

Introduction

Relations entre services



Utilisation des dépendances

Conclusion et travaux futurs Avantages et inconvénients

Travaux à réaliser

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

1 modélisation uml pour le test et la découverte des dépendances vincent pretre sous la direction...

Documents