Pour aller plus loin : Spécification et préparation des tests
Denis Conan
avec Chantal Taconet et Christian Bac
CSC4102
Pour aller plus loin : Spécification et préparation des tests
Table des matières
Pour aller plus loin : Spécification et préparation des tests
Denis Conan, avec Chantal Taconet et Christian Bac, Télécom SudParis, CSC4102
Janvier 2022 1
1 Complément sur les relations entre cas d’utilisation 3
2 Diagrammes d’activité 4
2.1 Actions et choix . . . 5 2.2 Concurrence . . . 6 2.3 Autres notations du diagramme d’activité . . . 7
# 2
'
&
$
%
1 Complément sur les relations entre cas d’utilisation
■ «include»=réutilisation complète sans changement,
■ généralisation spécialisation ou héritage=spécialisation de certaines actions du cas d’utilisation d’origine,
■ «extend»a =ajout de fonctionnalité facultative.
Créer un scrutin Voter
Authentification M1
Enregistrement tentatives Vérifier droits
relation d’inclusion
d’extension relation
généralisation spécialisation relation de
<<include>>
<<include>>
<<extend>>
a. Sémantique très controversée, donc évitez d’utiliser«extend»
Les relations entre cas d’utilisation ont pour but de décomposer le système en fonctionnalités à granularité plus fine, suivant ainsi l’adage « diviser pour régner ». Il existe trois types de décompositions ou relations entre cas d’utilisation, les deux principales étant l’inclusion et l’héritage, la troisième (l’extension) étant d’utilisation mal aisée et déconseillée1.
La relation la plus simple à comprendre entre deux cas d’utilisation est l’inclusion notée par une dépen- dance stéréotypée ««include»». L’inclusion exprime le fait qu’un cas d’utilisation comprend une séquence d’actions consécutives qu’il est possible de factoriser avec d’autres cas d’utilisation. Dans l’exemple de la diapositive, la vérification des droits est similaire, à quelques paramètres près, et peut être factorisée pour la création d’un scrutin et le vote/la participation à un scrutin. Lorsque le système modélisé atteint une cer- taine taille, il est important de montrer les relations d’inclusion qui définissent alors des parties du système réutilisables par d’autres parties.
La relation de généralisation spécialisation ou héritage est utile pour montrer qu’un cas d’utilisation est un type spécial d’un autre : le cas d’utilisation le plus spécialisé diffère quelque peu de l’original. Le premier spécialise certaines étapes de la séquence d’actions du second en les remplaçant par des « versions » plus spécialisées. Ainsi, toutes les étapes du cas d’utilisation original doivent être exécutées, certaines étant remplacées par des « versions » plus spécialisées. Dans l’exemple, nous pouvons imaginer que le client demande de concevoir l’authentification comme une « brique » générique spécialisable selon les protocoles existants. Par exemple, nous spécialisons le cas d’utilisation « vérifier droits » en utilisant la méthode M1 et créons le nouveau cas d’utilisation « authentification M1 ».
La relation d’extension entre cas d’utilisation est très controversée. Les concepteurs du langage UML ont voulu montrer qu’un cas d’utilisation peut réutiliser un cas d’utilisation complet, de manière similaire à
Pour aller plus loin : Spécification et préparation des tests
# 3
'
&
$
%
2 Diagrammes d’activité
2.1 Actions et choix . . . 4 2.2 Concurrence . . . 5 2.3 Autres notations du diagramme d’activité . . . 6
Un cas d’utilisation montre ce que fait ou doit faire le système pour une fonctionnalité donnée. Lorsqu’un cas d’utilisation est « complexe » au sens où le scénario est « complexe », il peut être intéressant de modéliser le scénario dans un diagramme d’activité. Ce qui suit sert donc à aller au-delà de ce que nous modélisons dans notre étude de cas pour laquelle les scénarios ne requièrent pas vraiment ce type de modélisation.
Deux types de diagrammes sont utiles ici : le diagramme d’activité et le diagramme de séquence. Le second type de diagramme étant présenté lors de la séance 3, nous présentons dans la suite le diagramme d’activité.
Un diagramme d’activité permet par exemple de décomposer un cas d’utilisation en actions, avec l’objectif de valider la modélisation avec le « client ». Un diagramme d’activité montre les actions à un très haut niveau d’abstraction avec les interactions entre elles. Dans la pratique, les diagrammes d’activité sont bien adaptés à cette phase de l’analyse qui consiste en l’expression des processus métier comme un ensemble d’actions coordonnées pour atteindre un but. Un processus métier peut aussi être l’enchaînement d’un ensemble de cas d’utilisation. Notez qu’un diagramme d’activité ressemble dans ses objectifs et, comme nous le verrons dans les diapositives qui suivent, dans sa forme à un diagramme BPMN, que vous avez étudié dans le module CSC3601.
Nous présentons les diagrammes d’activité dans les pages qui suivent, mais n’aurons pas le temps de les pratiquer lors des bureaux d’étude.
# 4
'
&
$
%
2.1 Actions et choix
décision
fusion
terminal noeud garde
initial noeud
arête sélection type scrutin
[scrutin type plages horaires] [scrutin type préférences]
entrer listes plages horaires entrer liste préférences
validation création du scrutin
Les diagrammes d’activité visualisent les étapes des cas d’utilisation et plus particulièrement les enchaî- nements et les branchements. Une activité débute par unnœud initial représenté par un disque noir. Cette action marque le début de l’activité et est suivi d’arêtesreprésentant le passage à l’action suivante. À l’autre extrémité du diagramme, lenœud terminalou final signifiant la fin de l’activité est représenté par un disque noir entouré d’un second disque. Entre les deux extrémités, les actions importantes du scénario sont reliées entre elles de façon à montrer le flot de l’activité : les enchaînements ou séquences et la concurrence (parallé- lisme). Le premier type de losange est appelée unedécisionet simule le début d’une instruction «si-alors».
Les conditions sont appelées des gardes. Le second type de losange signifie la fusion des branches à la fin du «si-alors». Bien sûr, une attention particulière doit être apportée aux conditions pour qu’elles soient mutuellement exclusives et complètes. Le standard UML indique que si plusieurs gardes sont valides alors une seule branche est parcourue et le choix de la branche est aléatoire. Ce comportement ne correspond que très rarement au souhait de l’auteur du diagramme. En outre, les conditions doivent être complètes pour éviter que l’activité ne soit bloquée ou gelée indéfiniment parce qu’aucune des conditions n’est valide. Par analogie avec les instructions « switch » des langages de programmation, il est ainsi judicieux de penser à ajouter une garde « sinon » représentant le chemin par défaut à emprunter si aucune des autres gardes n’est vraie.
Cf. le glossaire pour la définition du terme « action ».
Pour aller plus loin : Spécification et préparation des tests 2 Diagrammes d’activité
# 5
'
&
$
%
2.2 Concurrence
« join »
« fork » recherche scrutin
calcul résultat scrutin calcul liste adresses courriels
envoi résultat scrutin
Les actions qui se déroulent en même temps sont dites concurrentes. Elles sont modélisées entre deux traits épais comme des chemins parallèles, le premier de ces traits étant appelé «fork » et le second «join ».
Les séquences d’actions en parallèle débutent en même temps, sont toutes exécutées, mais par définition ne finissent pas au même instant. La fin de l’action join intervient lorsque toutes les actions en parallèle se terminent ;join est donc un point de synchronisation.
# 6
'
&
$
%
2.3 Autres notations du diagramme d’activité
activité appel autre
informations transmises date / heure de démarrage attente X secondes
Signal X reçu par le système
X Y Signal Y émis par le système
Le diagramme d’activité possède d’autres notations que nous citons pour information mais n’illustrons pas. Le diagramme d’activité permet d’exprimer le passage du temps avec le symbole du sablier. Il est ainsi possible de modéliser une activité qui s’exécute périodiquement en remplaçant l’action initiale par un sablier.
Il est aussi possible, à partir d’une activité, d’appeler une autre activité et d’indiquer entre deux actions les informations transmises (montrant ainsi les flux d’informations en plus des flots d’actions).
Les interactions entre le système et les acteurs sont modélisées sous la forme de signaux émis et reçus.
Enfin, le langage UML fournit d’autres notations que nous ne montrons pas : la fin d’un chemin, le partitionnement, les connecteurs, lesexpansion regions. Pour plus d’information, nous invitons les curieux à se référer à la bibliographie du module, dont le standard UML.
