Tests dirigés par les modèles

Transcription

Tests dirigés par les modèles
De l’utilisation des modèles dynamiques
d’UML pour spécifier les tests
N. Trèves
[email protected]
N.Trèves / CNAM - SITI / Tests dirigés par les modèles – NFP209/ Vers. 2.0
Page 1
Sommaire
Rappels : concepts de modélisation
La problématique des tests et des modèles
Quelques rappels sur UML
Les diagrammes UML et les tests
• Les scénarios d’interaction
• Construction des scénarios, les diagrammes d’états transitions
Page 2
1
1ère partie
Concepts de modélisation
Page 3
Processus métiers vs. processus
informatisés
Processus métier
Flux
Cohérence globale du SI
Cohérence des processus
Processus
informatisés
Cohérence de
l’information
DONNÉES
Règles de typage
• Syntaxe du type
• Sémantique du type
(règles d’interprétation)
Cohérence de
l’information
DONNÉES
Contraintes ergonomiques
• Pragmatique
• Sémantique
Flux
Cohérence informatique
• Intégrité du modèle de données
• Caractéristiques non fonctionnelles (cf. ISO9126 - FURPSE)
• Architecture
Page 4
2
Du réel à l’ordinateur : genèse des
composants logiciels
Expression de besoin
Problèmes du monde réel
Identification de formes « brutes »
abstractions « métier »
→ collecte des cas (fonctions en extension)
Identification de formes dérivées
identification de méta-abstractions
propres au langage informatique
→ but : faire en sorte que
complication ≈ complexité
Abstraction de
niveau N°1
Conception
Importance cruciale du système de
représentation des abstractions et de la
notation la plus appropriée
Abstraction de
niveau N°2
Solution informatique
Composants logiciels :
→ Entités architecturales : modules, objets,
fichiers, etc.
Page 5
Modélisation (1/4)
Notion de système englobant
Le logiciel fait nécessairement partie d’un ensemble plus vaste qui
détermine tout ou partie des comportements attendus (contraintes)
Systèmes d’information ; systèmes informatisés ; systèmes hybrides
Notion de modèle
C'est une représentation abstraite plus ou moins rigoureuse de tout ou
partie d'un système en vue d'en étudier la structure et le comportement.
L'étude peut être :
Qualitative : existence de telle ou telle propriété
Le système est-il stable ?
Quantitative : on sait associer une mesure à la propriété
Quel et le temps de réponse moyen?
• Quelques mots clés
Représentation abstraite : syntaxe, sémantique, pragmatique
Isomorphisme / homomorphisme : règles de correspondance qui relie le
modèle à la réalité, d’où : fidélité → vérification, validation, test
Observable : état du système qui a un sens par rapport à la réalité
(observateur)
Page 6
3
Modélisation (2/4)
Intérêt des modèles
Pouvoir d’anticipation : c'est la capacité à prédire
Détection et contrôle
Contrôle aérien et spatial, météo…
Pouvoir d’accélération : le modèle va plus vite que la réalité
Calcul numérique, simulation, recherches sur critères…
Aides à la décision ; magasin de données ; données cartographiques ; etc.
Pouvoir de substitution : on remplace la réalité par un modèle
Un conducteur de train
Le modèle prend toutes les décisions à la place du conducteur
Les comptables et employés aux écritures dans les banques
Système d'information
Tout système informatique est, par définition, un modèle
Page 7
Modélisation (3/4)
En résumé, modéliser : rendre compte d’un ensemble de
phénomènes / d’observations dans les termes d’un
langage donné
• Comment :
mettre en place une structure
aspects statiques et dynamiques
pouvoir y faire de la preuve
si la sémantique l’autorise
• Pourquoi :
taille et complexité nécessitent une représentation abstraite d’un système avant
sa réalisation : l’architecture
• Dans quel but :
organiser le développement en entités
prédire les défauts
prendre en compte les contraintes techniques
maîtriser les évolutions
Page 8
4
Modélisation (4/4)
On considère
une problématique
un domaine métier
Modéliser un domaine / une problématique
• fournir, dans un but donné, une description de ce domaine dont les détails
ont été éliminé de façon systématique
• simplifier les données d’un problème, sans le dénaturer, pour en faciliter la
compréhension
• faire ressortir les traits importants ; exhiber les liens conceptuels entre les
entités modélisées ; expliciter la dynamique
Modèle
Abstraction
Problème dans le
domaine métier
Réification
Solution
logicielle implémentée
Page 9
Qualités d’un bon modèle
Cohérent : la modélisation n’engendre pas de paradoxe.
Clair : le modèle permet de raisonner.
Complet : le modèle capture les aspects essentiels du
problème.
Orthogonal : correspondance bijective entre les relations de
dépendance / indépendance dans le modèle et dans le problème
considéré.
Robuste : le modèle reste pertinent lorsque les données du
problème varient « peu ».
Entre deux modèles équivalents, le plus simple est le meilleur
Ockham : « Entia non sunt multiplicanda sine necessitate. »
Page 10
5
2è partie
La problématique des tests et des modèles
Page 11
Rappel : cycle de vie VVT
L'activité de VVT débute dès la phase EB/EC
Besoin
Besoin
Résultats des phases
concernant l'activité V&V
des phases suivantes
Plan et objectifs de tests
• Système
• Recette
Conception
Conception
Plan de tests
• Modules
• Intégration
Conception des tests
• Modules
• Intégration
• Système
• Recette
TESTS ET VÉRIFICATIONS
POUR LA NON RÉGRESSION
Développement
Développement
Scénarios de tests
• Modules
• Intégration
• Système
Cas à tester
• Modules
• Intégration
• Système
• Recette
Intégration
Intégration
Scénario de tests
• Recette
Recette
Recette
Installation
Installation
Construction de la courbe de maturité
Pour toutes les phases : collecte des Rapports d'Anomalies (RA) et des Actions Correctrices (AC) ; traçabilité
Cf. ANSI/IEEE Std 1012 Software verification and validation plans ; Std 1059 Guide VVT
Page 12
6
Rappel : méthodes agiles
cycle de vie XP
Software factory
Cas
d'emplois
Exploration
• Planning game
Planification
Architecture stabilisée
à la première itération
• Durée moyenne 1 à 4 semaines
• Tests fonctionnels de chaque
itération, faits par le client (TDD)
Itération
Durée de 2 à 6 mois
maximum
Mise en production
• The perfect time to tune
Maintenance
• The normal state of an XP
project
Terminaison
• The time to write a 5 to 10
pages tour of the system
Nominale
« mort »
Page 13
Unified process
Macro-processus:
• Modélisation des besoins, Analyse, Conception,
Codage, Tests
Micro-processus.
• Construction des modèles :
Modèle des besoins, modèle statique, modèle dynamique
Cycle de vie :
• Itératif / incrémental
Page 14
7
Élaboration des scénarios de test
De manière générale préalablement à la phase de
codage
• Expression de besoins, conception
• Par incréments
• Cas particulier des tests structurels
Comment
• Au cas par cas, en extension
On énumère l’ensemble des scénarios de tests possibles
• Par intention
Développement d’un programme construisant automatiquement les
scénarios de tests
Page 15
Tests et modèles
Principe
• S’appuyer sur la structure / sémantique d’un modèle
pour élaborer des scénarios de tests
Aspects dynamiques
Conformité de la conception avec la construction des
scénarios de tests
Catégories de tests
• Fonctionnels
• De pré intégration
• Boites blanches, échanges entre objets
Page 16
8
3è partie
Quelques rappels sur UML
Unified Modelling Language
Page 17
UML, un langage de modélisation à large
spectre
Filiation
Programmation objet (Smalltalk, Eiffel, etc.) et types abstraits de données
(Pascal, Ada) → Conception orientée objet (OMT) → Notation unifiée de
l’OMG : UML
Standard de l’ISO et de l’OMG, version 2.3
Largement diffusé/utilisé dans l’industrie
Méthode et/ou outil ?!
UML est un ensemble de langages/notations graphiques permettant de:
Spécifier, concevoir, documenter
UML peut être utilisé dans tous les domaines nécessitant une modélisation
Sans méthode, l’emploi de UML est voué à l’échec
Page 18
9
Concepts et notations UML (1/2)
Les diagrammes
Nomenclature statique (2 diagrammes)
Diagrammes de classes (modèle ERA + opérations permettant la
navigation)
Diagrammes objets (i.e. instance de classes)
Interactions avec le monde extérieur
scénarios (3 diagrammes)
Cas d’utilisation (use case)
Diagrammes de collaboration (échanges de « messages » entre objets)
Diagrammes de séquence (interactions temporelles entre objets)
S’appuient sur les diagrammes de collaboration
Page 19
Concepts et notations UML (2/2)
Les diagrammes
Machines à états finis
Enchaînements et contrôle du flot d’exécution (2 diagrammes)
Diagrammes d’activités
Diagrammes états-transitions
Cartographie
Localisation spatiale et réalisation (2 diagrammes)
Diagrammes de composants
Diagrammes de déploiement
Page 20
10
Classe, notation UML
Le nom de la classe
Les attributs
Les méthodes
UneClasse
attribut_privé : boolean = false
attribut_public : int = 0
attribut_protégé : byte
méthode_publique(entier : int = 0) : int
méthode_protégée(réel : double) : double
méthode_privée() : UneClasse
UneClasse()
UneClasse(x : UneClasse)
Notations pour le contrôle d’accès :
Privé :
- (standard) ou
(graphique divers outils)
Protégé :
# (standard) ou
Public :
+ (standard) ou
Page 21
Objet, notation UML
Le nom de l’objet
La valeur des attributs
(état à l’instant t)
Unobjet : UneClasse
attribut_privé : false
attribut_public : 0
attribut_protégé : 1
Page 22
11
4è partie
Les scénarios d’interaction
Page 23
Le besoin : tester des méthodes
Tests structurels « classiques », boites blanches
•
•
•
•
Graphes de contrôles
Couverture / tests minimaux
Interprétation sémantique
Génération des jeux de tests pertinents
Pas spécifiques à la modélisation objet
Page 24
12
Le besoin : tester la communication
entre objets
tests unitaires
Tout objet A peut communiquer avec un objet B par
envoi d'un message qui symbolise l'activation d'une
opération de B par A
• Diagrammes de collaboration
La réception du message par B est un événement qui change
l’état de l’objet B
On dit que les objets A et B interagissent entre eux
Activation
A
B
Retour
Page 25
Le besoin : tester l’interaction entre
composants
Interfaces entre
composants
diagrammes de
composants
• Envoi/réception de
messages
• Variables partagées
• Événements
Page 26
13
Le besoin : tester l’interaction système
utilisateurs
Diagrammes de cas
d’utilisation
• Liens entre acteurs et
systèmes
Page 27
Modèles dynamiques
Concepts et typologie
S’appuient sur les notions:
• Action/Activité
Une activité est une opération qui prend du temps.
N’est pas atomique: interruptible.
Une action est une opération instantanée.
Non interruptible.
• Message
Les objets communiquent en envoyant des messages. La réception du
message est un événement qui change l’état de l’objet.
Typologie
•
•
•
•
Diagrammes d’activités
Diagrammes de séquence
Diagrammes de collaboration
Diagrammes d’état-transition
Page 28
14
Diagrammes d’interaction
Expriment des scénarios d’interaction entre objets
• Diagrammes de séquence
Accent mis sur les séquences de messages échangés par les objets
• Diagrammes de collaboration
Accent mis sur les liens / flux entre les objets
On ne cherche pas à documenter tous les scénarii possibles
• On s’intéresse aux scénarii significatifs - nominaux
Problème : existence d’un cours normal des actions ?
• On veut communiquer sur les fonctions du système
Dans les deux types de diagrammes, on fait figurer
• Des classes ou des objets (instances de classes)
• Des messages et des stimuli (instances de messages)
« a Stimulus is a communication between two Instances that conveys information with the
expectation that action will ensue. A Stimulus will cause an Operation to be invoked, raise
a Signal, or an Instance to be created or destroyed. »
• Des associations et des liens (instances d’associations)
• Pour chaque catégorie on peut considérer soit des instances soit des ensembles
d’instances (multiobject)
Une interaction peut impliquer le changement d’état d’un objet
Page 29
(1/2)
éléments représentés
Des instances de classes (objets)
•
qui peuvent être créées ou détruites
« During the execution of an interaction some Instances and Links are created and some
are destroyed. The creation and destruction of elements can be marked. »
•
Qui sont « transient » si elles n’existent que pendant la durée de l’interaction
décrite
Des instances de messages (stimuli) qui peuvent être
•
Des appels de type synchrone
Typiquement, appel de procédure
Transfert du flot de contrôle / attente
•
Des appels de type asynchrone
Avec activation possible de l’objet appelé
Exécution concurrente
•
Des retours
opération_xy_de_la_cible()
pointillés
Pouvant être omis pour un appel synchrone
Page 30
15
exemple 1
Instance de la classe
Client nommée c
Un objet est dit transient si sa durée de vie
est réduite à l’interaction
Action de type
CreateAction
c : Client
p : ProxyODBC
{transient}
<<create>>
: Transaction
insertValues(a,b,c)
activation
insertValue(a.table,a.value)
Appel « procédural »,
synchrone
insertValue(b.table,b.value)
Retour d’un appel
de procédure
insertValue(c.table,c.value)
Appel asynchrone
commited
Marque l’activation
(focus of control)
<<destroy>>
Sauf indication
contraire, sens
du temps
Marque la destruction
de l’objet cible
du message (e.g. delete)
Ligne de vie
Page 31
exemple 2
xyz:Appelant
:Cabine
:Central
:Appelé
Téléphonique
Décrochage
Numéro
Numéro
Sonnerie
Décrochage
Décrochage C
Unité Téléphonique
Unité Téléphonique
Raccrochage
Raccrochage C
Raccrochage
Page 32
16
(2/2)
éléments représentés, subtilités
Des messages d’un objet vers lui même
récursion
Message réflexif
Récursivité
Des branchements conditionnels
Sur une condition
Éventuellement avec choix de chemin
Des itérations
[x]
[not x]
[y]
Rmq : contrairement
aux apparences, pas
d’ordre entre ces deux
blocs
* faire()
Itérative while
Itérative for
Avec exécution parallèle
* [i:=1..n] mettreAJour(i)
* [i:=1..n] || redessiner(i)
Rmq. : pour distinguer l’activation (active) de l’état de l’objet
en train de calculer (computing), on peut griser la ligne de l’objet
qui calcule (objet au sommet de la pile d’exécution).
Page 33
Construction d’un scénario des tests
Un diagramme de séquence = un scénario d’une
interaction un scénario de test
• On représentera plusieurs objets en interaction, un objet
pilotera l’interaction
• C’est à partir de ce pilote que l’on construit les scénarios
de tests
Cf. exemple 1: scénario de test de pré-intégration entre les
objets client et transaction
on vérifie qu’un message pour créer une transaction a été envoyé
les valeurs a,b,c ont été transmises
dès que l’on a reçu un commit, le message demandant de détruire la
transaction a été envoyé
Page 34
17
5è partie
Construction des scénarios d’interaction
Les diagrammes d’états transitions
Page 35
Diagrammes états transition
(1/2)
introduction
Les diagrammes d’activité et les diagrammes états/transitions (DET) présentent des
visions duales des phénomènes modélisés
•
Avec les DET on cherche à capturer les enchaînements d’actions
On veut, pour un objet donné
•
•
Les événements
Connaître ses états (intervalle de temps stable)
{e,f,g,h}
Connaître ses réactions à différents événements qui peuvent se produire à tout instant
Une approche simpliste est de considérer
•
un ensemble d’événements est associé à chaque transition
{e,f}
{h}
Évidemment, chaque transition identifie uniquement sa source et sa cible
Se déclenche quand l’un des événements se produit
•
un graphe orienté
Le graphe
Les nœuds du graphe sont les états
Les arcs du graphes sont les transitions
•
{h}
à chaque instant, un « état actif » (c-à-d courant) dans le graphe
Modus operandi
•
•
•
⇒
{f,g}
l’événement e se produit
L’automate est dans un état s
il existe une transition T : s → t associée à e
le nouvel état de l’automate devient t
1) Soudain e !!!
{e,f}
t
T
3) T qui reconnaît e est déclenchée
2) s est l’état actif
4) nouvel état actif t
s
s
T
t
Page 36
18
(2/2)
introduction
Appuyer sur
le bouton
L’exemple trivial : la lampe électrique
•
Un événement
•
Deux états
Appuyer sur le bouton
Allumée
Allumée
Éteinte
•
Deux transition déclenchées par l’événement « appuyer sur un bouton »
Éteinte
Appuyer sur
le bouton
Allumée → Éteinte
Éteinte → Allumée
Avec deux niveaux de luminosité
Donc trois états
Brillante
Appuyer sur
le bouton
Tamisée
Appuyer sur
le bouton
Éteinte
Appuyer sur le bouton
Page 37
Labels des transitions UML
La forme générale du label d’une transition entre deux états est
événement (paramètres) [condition de garde] / actions-associées*
Ex: retrait (montant) [solde≥montant] / solde=solde-montant; donner(montant);
« événement » est le stimulus qui déclenche la transition et peut être de quatre types
⇒
un signal « The specification of an asynchronous stimulus communicated between instances. »
un appel d’opération « represents the reception of a request to synchronously invoke a specific operation. »
L’expiration d’un certain délai, atteindre une date « A TimeEvent models the expiration of a specific
deadline. »
La modification d’un attribut / d’instance liées « A change event models an event that occurs when an explicit
boolean expression becomes true as a result of a change in value of one or more attributes or associations. »
Notion de thread qui surveillerait en permanence
« paramètres » le stimulus peut éventuellement être accompagné d’une liste de paramètres typés
(syntaxe OCL - Object Constraint Language)
« condition de garde » est une expression booléenne qui doit être évaluée pour que la transition
gardée soit activée
•
L’évaluation de la condition ne doit pas produire d’effet de bord
« actions associées » est une action qui doit être exécutée pendant la transition
•
•
•
•
Dans sa totalité avant qu’une autre action puisse être exécutée
« This model of execution is referred to as run-to-completion semantics. »
Peut-être une succession d’actions
Peut-être exprimée avec un formalisme (langage) ad-hoc
Peut générer des événements, envoyer des signaux, invoquer des opérations
Page 38
19
Pseudo-états
le début et la fin
On introduit des pseudo-états
•
État initial (ou défaut) : l’état dans lequel se trouve l’objet initialement
Unique. Existe toujours.
En émane une unique transition
•
État final (ou terminal) : état absorbant
Éventuellement plusieurs dans un même automate. Optionnel.
Ne peut en émaner aucune transition
Comme dans les diagrammes d’activité, ces états sont purement statiques
⇒ Pas d’activités / actions associées
État initial
ouvrirCompte( dépotInitial ) [dépotInitial >100 ] / solde=dépotInitial
débit( somme )[ somme<solde ]
/ solde-=somme
minuit / somme*=1.2
débit( somme )[ somme>=solde ]
/ solde-=somme
Compte
approvisionné
Compte à
découvert
dépot( somme )[ somme+solde>0 ]
/ solde+=somme
fermerCompte
dépot( somme )[ somme+solde=<0 ] / solde+=somme
crédit( somme ) / solde+=somme
État final
Page 39
un autre exemple
État Initial
Transition
Action : ici envoi d’événement
État
Décrochage /tend central.ouvertureLigne
Raccroché
Décroché
Raccrochage
Destruction
Événement
Destruction
État Final
Page 40
20
Actions/Activités
Des opérations sont attachées aux événements et
aux états.
• Actions aux événements
• Activités aux états, en général
Décrochage
Sonnerie
Raccroché
do: Sonner
Décroché
Raccrochage / rendreMonnaie
Activité
Action
Page 41
Détail des actions associées à un état
Un état représente à la fois
•
•
La satisfaction (généralement implicite) d’un invariant caractérisant cet état ⇒ vision
statique de l’état
La réalisation, optionnelle, d’une action / activité / tâche associée à cet état ⇒ vision
dynamique de l’état (cf. diagramme d’activités)
On a la possibilité de spécifier, pour un état donné, une action devant être exécutée à
chaque fois qu’on entre dans cet état
•
Dite « entry » ou pré-condition. Exécutée quelque soit la transition entrante
Similairement, on peut spécifier, pour un état donné, une action devant être exécutée
à chaque fois qu’on sort dans cet état
•
Dite « exit » ou post-condition. Exécutée quelque soit la façon dont l’état est quitté
L’état peut posséder une tâche de fond - activité
•
Dite « doactivity » (ou « do ») qui commence dès l’entrée dans l’état et prend fin au plus
tard à la sortie de l’état
Ex. sorte
de disque
en marche
Transition in
(allumer)
entry
doactivity
(placer tête)
(tourner)
Transition out
exit
(ranger tête)
Page 42
21
Élaboration des scénarios de test (1/2)
Chaque objet est potentiellement dans plusieurs états
différents
• Une transition fait passer un objet d’un état vers un autre
• Une transition est déclenchée par un événement
provenant de l’extérieur de l’objet (message)
Peut également effectuer des actions vers l’extérieur (envoi de
messages)
• On générera donc autant de scénarios de tests qu’il y aura
de scénarios d’interaction
Ces derniers sont construits en parcourant toutes les
possibilités du DET
Page 43
Élaboration des scénarios de test (2/2)
Un diagramme de séquence sera construit:
• A partir d’un état donné
Suite d’évènements reçus depuis /actions émises vers d’autres
objets permettant de reboucler vers l’état donné
Un diagramme de séquence fait figurer les états successifs d’un objets
parcourus par le scénario
Page 44
22
Quand spécifie-t-on les interactions?
On peut générer des scénarios de tests dès lors
que l’on sait décrire les interactions entre les
composants du système
• Dès l’expression de besoin
Interaction des acteurs avec le système vu comme une boite
noire
Tests fonctionnels à partir des cas d’utilisation
• Au cours de l’analyse et de la conception
Interaction entre les composants/objets
Tests de pré-intégration à partir des diagrammes de séquence
Tests unitaires : interaction entre objets
Page 45
Autres types de modèles
Automates étendus, réseaux de Petri
• Graphe des états
• Techniques de model checking
Preuves de programmes, B, COQ
• Solvers
Chaines de Markov
• Pour l’ordonnancement et la prise en compte du temps
Page 46
23
Conclusion
Attendre la phase de codage pour définir les
scénarios de tests est un leurre
Définir les scénarios de tests dès que l’on sait
décrire les interactions à plusieurs niveaux
d’analyse / conception
• Granularité du processus de développement itératif /
incrémental
Ne pas oublier les tests non fonctionnels
• Diagrammes de déploiement
Page 47
Bibliographie UML et objet
Ouvrages élémentaires et/ou introduction à UML
Très bonne
introduction dans
un style simple
P-A.Muller : Modélisation objet avec UML, Eyrolles
F. Vallée, P. Roque, UML 2 en Action, Eyrolles
G. Booch & al. Le guide de l’utilisateur UML, Eyrolles
Ouvrages d’approfondissement
L’ouvrage le plus
approfondi et le
plus complet
M. Fowler, K. Scott, UML Distilled: Applying the Standard Object
Modeling Language, Addison-Wesley, Reading MA, 1997
I.Jacobson : Le Génie Logiciel orienté objet, Addison Wesley
Object oriented software engineering (original en anglais)
I.Jacobson : The object advantage, Addison Wesley
B.Meyer : Conception et programmation objet, Eyrolles
M.Smith, Object oriented software in Ada 95, ITP
Gamma & al., Design patterns : Elements of Reusable Object
Oriented Software, Addison Wesley
Ouvrages théoriques
M.Abadi, L.Cardelli : A theory of objects, Spinger (1ère tentative
sérieuse de définition de la sémantique à l’aide du λ-calcul)
Page 48
24

Tests dirigés par les modèles

Transcription

Documents pareils

GE Capital Solutions, Fleet Services | Paperjam Guide

L`Abbé Joseph-Marie Trèves (1874

Chers participants, Une bonne et une mauvaise nouvelle: depuis

flughafen hahn

Licence Commerce Amiens - Bienvenue au Cnam Picardie

Séjour linguistique et culturel à Trèves

www.cnam-picardie.fr

SAINT AGRICE OU AGRY, EVEQUE DE TREVES

Cnam - Economie et gestion des services de santé

Trèves est situé au sud-ouest de l´Allemagne. Les aéroports les plus