«Les Diagrammes de Séquence en phase de conception»

Transcription

1 Année Polytech Paris-Sud 4ème année Département Informatique «Les Diagrammes de Séquence en phase de conception» Frédéric VOISIN Département Informatique

2 Diagrammes de séquence en analyse Ils correspondent à des «diagrammes système» ou des «scenario» le système est vu comme une «boite noire» Échanges de messages entre les acteurs et le système jamais entre acteurs (pas du ressort du système!) ni entre éléments internes au système (conception) Représentation de la chronologie des échanges Pas de boucle, conditionnelle,...! Un chemin principal, des alternatives, des cas d exception, des commentaires, complétés par des descriptions textuelles Usages : Illustrer chaque cas isolément (diagramme très simple) : fournit les paramètres, des détails d'interaction, les exceptions et erreurs... Illustrer les interactions entre cas d utilisation (scenario) : décrit des exemples possibles de la dynamique du système

3 Un exemple de «Diagramme des Cas d Utilisation»

4 Diagramme «système» (détails d interaction) Secr. Adm. entrerid(nom, NumeroEtu) Choix diplôme? Gestion-LMD Ordonnancement temporel des évènements Système Bancaire entrerdiplome(codediplome) Choix Paiement? cartecb(nocarte, code) Nom, numero etudiant et Code diplome validés debit(nocarte,tarif) retourcb(boolean) Code validé Carte Etudiant «réinscrire administrativement» : cas principal

5 Un exemple de «scenario»

6 Diagrammes de séquence en conception Description diagrammatique des appels de méthodes et de la coopération entre instances et méthodes Permet de donner une vue «en largeur» du déroulement d une opération : Quels sont les objets impliqués? Quelles méthodes de quelles classes sont concernées? D'où viennent les paramètres? etc. utile pour comprendre la mécanique d ensemble et la répartition des responsabilités, avant de rentrer dans le détail Choix à faire sur les appels qu on fait apparaître (omettre certains détails pour améliorer la compréhension) Pas du pseudo-code qui donne une vue «en profondeur» d une opération: donnerait plus de détail sur la façon dont cette méthode procède mais vision limitée à l opération courante, sans compréhension globale des interactions entre objets Utile aussi bien comme outil de «conception» que comme «documentation»

7 Diagrammes de séquence (en conception) objet intervenant dans le diagramme Classe (ou structure) du système message asynchrone : émetteur non bloqué, continue ses traitements Message entre l extérieur et le système activation nom1:acteur nom( ) nom2:classe1 nom ( ) nom3:classe2 Message, opération autoappel() ligne de vie (temps) message synchrone : émetteur bloqué, attend retour

8 Diagrammes de séquence «conception» Diagramme de séquence «orienté conception» pour le traitement d'une commande «UML 2.0, Guide de référence» Rumbaugh & alli, CampusPress

9 Diagrammes de séquence «conception» (2) Opérateurs de contrôle: loop, par, alt, opt, ref (ou sd) Utile si on veut engendrer du code automatiquement Utile pour décrire à assez haut niveau des aspects algorithmiques mais ont tendance à obscurcir les diagrammes et ne traitent pas tous les aspects (ex: gestion des exceptions?) Se demander si cela apporte plus d information que de bruit Se demander si le diagramme reste suffisamment lisible On peut recourir à des commentaires UML pour préciser certains aspects, si besoin (ex: «Pour tous éléments dans monobjet.sacollection»

10 Diagramme de séquence pour «Retrait» Client :LecteurCarte :Ecran :Clavier :IntC GestTrans insere cartelue(no) starttrans(no) OK demandepin() Saisir PIN PINLu(pin) Valider(no, pin) c:= getcompte(no) :Retrait c:compte demandemontant() OK Créer(date) Interaction en dehors du système Interaction entre objets du système Ici: appel synchrone Objet Temporaire

11 Diagramme de séquence pour «Retrait»(2) Client :LecteurCarte :Ecran :Clavier :IntC GestTrans :Retrait c:compte montantlu(val) possible(val) retrait?(val) OK OK setmontant(val) Ici, il manque le détail de l obtention des billets en fonction du stock, l émission d un ticket, la confirmation par l automate que le retrait s est bien déroulé, etc fin() fintrans(no) OK Confirme() majsolde(-val) Destruction d une instance

12 Analyse du diagramme de séquence de «Retrait» Identification des classes nécessaires et de leur visibilité: À partir de InterfaceClient, on a besoin de pouvoir retrouver l instance de GestionnaireTransaction GestionnaireTransaction doit pouvoir retrouver un compte à partir d un numéro de CB. Donc besoin d une méthode statique de recherche dans Compte? On a besoin de créer des instances temporaires de Retrait, mais pas d un lien permanent etc Identification d un certain nombre de méthodes avec leurs paramètres, valeur de retour Choix d une manière d enchaîner les opérations Choix d une répartition des responsabilités entre classes

13 Diagramme de séquence pour «Consulter une note» :InterfaceNote :Set(Epreuve) ep:epreuve Secrétaire consulter :Set(Etudiant) et:etudiant menuep() choixep(n) getepreuve(n) menuet() ep choixet(n2) getetudiant(n2) A qui confie-t-on la responsabilité de consulternote()? Comment est représentée l association Etudiant/Epreuve/Note? et consulternote(ep) consulternote(ep)

14 Exercices pour «Consulter une note» Hypothèses: Il n y a pas de Set(Etudiant), ni de Set(Epreuve) mais une base de données qui stocke les résultats Les cas d utilisation comportent une opération pour calculer la moyenne d une épreuve Les cas d utilisation comportent une opération pour calculer la moyenne d un étudiant Les cas d utilisation comportent les deux opérations précédentes Cela change-t-il quelque chose? Certains choix deviennent-ils meilleurs que d autres?