Accueil
 Sommaire
 1  Objectifs de ce cours de modélisation orientée objet
 2  Généralités sur la modélisation orienté objet et sur UML
 3  Analyse, vues cas d'utilisation et processus
 3.1  Modèle de l'analyse
 3.2  Diagrammes de cas d'utilisation
 3.3  Diagrammes d'activité
 3.3.1  Scénarios d'un cas d'utilisation
 3.3.2  Actions et choix
 3.3.3  Concurrence
 3.3.4  Autres notations du diagramme d'activité
 QCM
 4  Analyse et conception, aspects statiques de la vue logique
 5  Analyse et conception, aspects dynamiques de la vue logique
 6  Conception, aspects langage et technique
 7  Conception, vues développement et physique
 8  Conclusion
 9  Bibliographie

 Contacts

W3C validator

Département INF  
 Conception et programmation orientées objet


3.3.2 Actions et choix

Figures/notation_actions

    précédent     suivant 


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 un nœud initial représenté par un disque noir. Cette action marque le début de l’activité et est suivi d’arêtes représentant le passage à l’action suivante. À l’autre extrémité du diagramme, le nœud terminal ou 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 une décision et 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.

D. Conan, C. Taconet, C. Bac, Télécom SudParis, CSC 4002, Octobre 2014