ENSTA : cours IN204 Introduction à JAVA et UML Olivier Sigaud LIP6/AnimatLab olivier.sigaud@lip6.fr 01.44.27.88.53

Plan du cours 9 Cas d'utilisation UML : diagrammes de séquence UML : diagrammes états-transitions Démarche d'utilisation d'UML Cohérence entre les vues Organisation du projet (2)

Diagrammes de séquence

Le diagramme de séquence Application Simulateur Population Genome création création création création soumission évaluation Permet d'identifier les interactions entre objets concernés

Conceptualisation Il faut conceptualiser le problème du point de vue du client Identifier les acteurs (entités externes agissant sur le système) Use case : séquence d’actions réalisées par le système produisant un résultat observable par un acteur Diagramme des cas : ensemble des Use cases, doit décrire les exigences fonctionnelles du système Permet de : développer orienté utilisateur découper les grandes tâches communiquer entre équipes et clients Orienté SSII

Cas d’utilisation Description textuelle : Diagramme des cas : nom, résumé, contexte, description, exceptions, acteurs, effets… on en extrait les objets, actions, états... de la modélisation Diagramme des cas : Client Traitement de commande Facturation Comptable Réceptionniste Gestion de compte client Livreur A chaque Use case correspond un diagramme d’objets participants

aux diagrammes de séquence (1) Des cas d’utilisation aux diagrammes de séquence (1) Un diagramme de séquence décrit un scénario d’interaction entre objets du système et acteurs externes Un scénario peut être vu comme une des instances d’un cas d’utilisation La description doit être suffisamment générale et exhaustive pour identifier tous les algorithmes

aux diagrammes de séquence (2) Des cas d’utilisation aux diagrammes de séquence (2) Problème : la combinatoire des interactions peut être immense. décrire quelques scénarios dans les cas nominaux décrire les scénarios aux limites décrire les scénarios d’anomalie Un analyste programmeur doit pouvoir coder en lisant des diagrammes de séquences

Le diagramme de séquence Identifier les classes et méthodes d'interface concernées

A éviter absolument… A un ensemble de diagrammes de séquence doit correspondre un algorithme (simple)…

Usage du diagramme de séquence En tant que document d’analyse : sert à représenter de plus en plus précisément la dynamique du système En tant que document de conception : sert à figer les interactions entre les sous-parties du logiciel En tant que document d’implémentation : sert à décrire les algorithmes (la partie interaction) Peut conduire à des re-découpages des vues statiques Essentiel pour le passage de l’analyse à la conception

Automates

Le diagramme états-transitions Source : Statecharts (David Harel) Etat final Etat initial Evénement Contrainte anniversaire [age=18ans] Mineur Majeur Permet de représenter sous forme d’automates les objets dotés d’une dynamique complexe Très utile pour les applications interactives Délicat à utiliser => Ne pas en abuser

Exemple : réveil matin 3 boutons : alarme on/off, arrêt sonnerie, réglage alarme Transition automatique à la fin de la sonnerie Constat : notation très compacte pour décrire toute la dynamique alarme on(H alarme) [heure = H alarme] Désarmé Armé do/sonner alarme off arrêt sonnerie alarme off

Actions et activités Envoi d’événement : déclenchement d’une transition. Action : opération instantanée déclenchée par une transition. Activité : opération durable, interruptible, associée à un état. Action interne : action qui n’entraîne pas de transition Transition automatique : transition sans événement, déclenchée à la fin de l’activité. Transition propre : transition vers le même état (on en sort et on y retourne) E3[cond Y]/action2 Etat do/activité action1 /action3 E1/action0

Action en entrée et en sortie Action en entrée : action exécutée à chaque entrée dans l’état Exemple : redessiner le contenu de la fenêtre quand la souris y entre Action en sortie : action exécutée à chaque sortie de l’état Exemple : mettre à jour un compteur de passage à la sortie Intérêt de factoriser les actions de sortie dans le cas hiérarchique Etat Etat entry/a1 exit/a2 E1/a1 E1 E3/a2 E3 E2/a1 E4/a2 E2 E4

Ordonnancement Entrée : Dans l’état : En sortie : Transition propre : action sur la transition d ’entrée (a0) action d’entrée (a1) activité (activité) Dans l’état : interruption de l’activité (activité) exécution de l’action interne (a4) reprise de l’activité En sortie : arrêt de l’activité (activité) action de sortie (a2) action sur la transition de sortie (a3) Transition propre : ordre de sortie (activité,a2), (a5), puis ordre d’entrée (a1,activité) Etat entry[cond In]/a1 e2/a4 do/activité exit [cond Out]/a2 E1[(cond X)]/a0 E4[cond Z]/a3 E3[cond Y]/a5

Automates hiérarchiques Les diagrammes d’états à plat deviennent rapidement illisibles, il faut structurer hiérarchiquement. Raffiner : décomposer en sous-états Synthétiser : regrouper dans un même état Etat père do/A E1 E2 E1 E3 E2 do/A1 do/A2

Automates hiérarchiques Première Troisième Transmission Point mort Marche arrière Seconde Marche avant S F R U D Un sous-état hérite de son sur-état des actions internes, des transitions de sortie, il n’hérite pas des transitions en entrée ni des activités.

Hiérarchie et ordonnancement Quand on entre dans l’état englobant, on entre dans l’état interne initial On commence par entrer dans l’état le plus englobant pour aller vers le plus interne On commence par sortir de l’état le plus interne pour sortir d’un état englobant Interne entry/a2 exit/a3 Ein Eout Englobant entry/a0 exit/a1 Ein => a0,a2 Eout => a3,a1

Exercice Indiquez les séquences d’actions pour chaque événement reçu selon que l’automate est dans l’état B ou C E3/x3 Etat A entry/A_In E4/A_Interne exit/A_Out E1/x1 E2/x2 Etat B entry/ B_In exit/ B_Out E5 Etat C entry/ C_In exit/ C_Out E6

Parallélisme et synchronisation Etat composite do/ A1 do/ A2 do/ A3 do/ A4 do/ A5 do/ A6 Activation de A1, A3 et A5 en même temps Transition quand A2, A4 et A6 sont toutes finies

Dynamique de l’élève Eveillé Endormi En cours Eveillé Endormi Réveil sonne [heure=en retard] Pause !!! En cours [durée>10mn] Eveillé Endormi Prof crie

Diagramme d’activité Chercher du café Mettre un filtre Remplir le réservoir d’eau Prendre une tasse Mettre du café Allumer la cafetière Le café passe Servir

Démarche UML

Démarche d’ensemble Utiliser la redondance entre les vues Travailler les différentes vues en parallèle Vérifier la cohérence à chaque étape Nombreux allers-retours Faire valider régulièrement Use Cases Objets Dynamique

Processus d'analyse Le découpage en packages doit être fait tôt, mais nécessite des réaménagements Diagramme des cas => différents cas (et retours) use case => diagrammes des classes (et retours) use case => diagrammes de séquences/ajouts de classes identifier les automates nécessaires diagrammes de séquences => automates (synthèse)

Processus de conception Partir d'un modèle en analyse partager le travail détailler le contenu, les échanges compléter les diagrammes de classes compléter les diagrammes de séquence identifier les doublons, les problèmes modifier le partage (itérations) Figer les interfaces Classes et méthodes d'interface Paramètres échangés, valeurs de retour Passage à l'implémentation

Interaction classes-séquences Les objets concrets représentés dans un scénario sont des acteurs ou des instances de classes Construire le scénario peut faire apparaître de nouvelles classes Cela fait surtout apparaître les méthodes et éventuellement les attributs Attention, les classes abstraites n’apparaissent pas -> ne pas se contenter des diagrammes de séquence !

Attention ! Les contraintes d’efficacité peuvent entraîner des modifications importantes entre analyse et conception Quand c’est le cas, il faut faire évoluer la documentation et consulter les partenaires concernés S’efforcer de concevoir les interfaces de telle façon qu’elles ne soient pas concernées par les modifications S’efforcer de faire les modifications de façon à ne pas toucher aux interfaces

Gestion de la documentation Tout diagramme doit indiquer clairement ce qu’il représente Rassembler les diagrammes représentant différentes instances d’un même scénario Assurer la traçabilité entre cas d’utilisation, diagrammes de classe, diagrammes de séquence, et code produit Recours intensif aux liens hypertextes

Organisation du projet

Travail à effectuer Définir toutes les classes utiles (vu précédemment) Identifier les traitements qui impliquent plusieurs classes Faire des diagrammes de séquences pour mettre en évidence les interactions Définir la signature des méthodes, ce qu’elles font Identifier puis figer les interfaces en figeant les signatures Cela définit le contrat engageant chaque équipe

Etape 3 (formalisation) Pour chaque entité identifiée lors de l’analyse, finaliser la conception de l’interface avec les équipes environnantes Réaliser les diagrammes de séquences, nommer les méthodes, les paramètres, les valeurs de retour… Objectif séance 3 : chaque équipe devient capable de travailler de façon autonome

Etape 4 Pour chaque entité identifiée lors de l’analyse, conduire la conception détaillée en interne Réaliser les diagrammes de classes, de séquences et éventuels automates détaillés Penser la généricité, la réutilisabilité Objectif séance 4 : chaque équipe sait de façon détaillée comment elle va faire

Etape 5 Pour chaque entité identifiée lors de l’analyse, validation définitive des interfaces avec les autres équipes Recherche des incohérences, redondances, conflits… Objectif séance 5 : validation globale de la conception : tout le monde peut se mettre à coder