CONCEPTION des SYSTÈMES d INFORMATION UML

CONCEPTION des SYSTÈMES d INFORMATION UML 2 : Analyse Fonctionnelle Epitech 3 Automne 2007 Bertrand LIAUDET SOMMAIRE LES CAS D UTILISATION 2 1. Présentation intuitive de la notion de cas d utilisation 2 2. Les cas d utilisation du logiciel Approche par l exemple 4 3. Les cas d utilisation du logiciel Formalisme 10 4. Méthode de construction d un diagramme des cas d utilisation 15 5. TP-PROJET : Diagramme des cas d utilisation avec VISIO 17 LES SCENARIOS ET LEURS SEQUENCES 18 1. Les scénarios des cas d utilisation et leurs séquences 18 2. TP-PROJET : Séquence des scénarios avec VISIO 21 LE DIAGRAMME D ACTIVITE DES SCENARIOS 22 1. Les diagrammes d activité dans l analyse fonctionnelle 22 2. Diagramme d activité d un cas d utilisation 24 3. Diagramme d activité d un traitement MERISE 25 4. TP-PROJET : Séquence des scénarios avec VISIO 26 EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 1/26- Bertrand LIAUDET

LES CAS D UTILISATION Il est facile de décrire la méthode encore que son application exige à coup sûr savoir et pratique. 1. Présentation intuitive de la notion de cas d utilisation Diagramme UML ANALYSE FONCTIONNELLE Cas d utilisation Séquence Activités Cas d utilisation Un cas d utilisation est, comme son nom l indique : Un cas d utilisation est : Par exemple : un usage du système (du programme), une fonctionnalité du système. une fonctionnalité complète du système. Dans le système «guichet automatique d une banque», «retirer de l argent» est un cas d utilisation. C est une fonctionnalité complète du système qui va de l insertion de la carte de retrait par le client jusqu à la récupération de la carte de retrait par le client. Du point de vue de l utilisateur, un cas d utilisation est : un ensemble d activités du système qui produit un résultat intéressant pour un utilisateur Du point de vue du système lui-même, un cas d utilisation est : un ensemble d activités qui part d un système au repos pour arriver de nouveau à un système au repos. Acteur Les cas d utilisation sont initiés par des acteurs. Un acteur est à l extérieur du système. Il interagit avec le système. Par exemple : EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 2/26- Bertrand LIAUDET

Dans le système «guichet automatique d une banque», le client qui vient retirer de l argent est un acteur du système. Acteur et cas d utilisation contiennent des instances concrètes Les cas d utilisation peuvent être considérés comme des classes (des ensembles ou des types) dont instances concrètes (les éléments de l ensemble) seront les scénarios. Par exemple : Il y aura plusieurs scénarios pour retirer de l argent : si le code de la carte de retrait est faux ; si le client n est pas autorisé à retirer de l argent ; si le guichet n a plus de billets ; etc. De même, les acteurs peuvent être considérés comme des classes dont les instances concrètes sont des personnes concrètes. Par exemple : M. Dupond qui vient retirer de l argent est un acteur concret. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 3/26- Bertrand LIAUDET

2. Les cas d utilisation du logiciel Approche par l exemple Reverse engineering : cas d utilisation du logiciel WORD : les menus Partons du logiciel Word et décrivons les cas d utilisation. Les cas d utilisation sont donnés par les menus. Les cas d utilisation abstraits sont les menus qui contiennent des sous-menus. Les cas d utilisation concrets sont les menus qui conduisent à une activité. Arborescence des menus Menu général Fichier Edition Affichage Insertion etc. New Ouvrir Save Save as Envoyer vers Destinataire Dossier exchange etc. Les cas d utilisation concrets correspondent aux feuilles de l arbre. Ils sont soulignés. Les cas d utilisation abstraits correspondent aux nœuds non-feuilles. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 4/26- Bertrand LIAUDET

Cas d utilisation des menus Affichage Edition Utilisateur Gestion des fichiers Nouveau Ouvrir Sauver Sauver sous Envoyer vers Destinataire Dossier exchange Cas d utilisation abstraits Il y a 4 cas d utilisation abstraits : «Edition», «Affichage», «Gestion de fichier» et «Envoyer vers». Ces cas d utilisation abstraits regroupent des cas d utilisation concrets. Cas d utilisation concrets Il y a 6 cas d utilisation concrets : «Nouveau», «Ouvrir», «Sauver», «Sauver sous», «Destinataire», et «Dossier exchange». Les cas d utilisation concrets correspondent à un usage concret du logiciel. Niveaux de présentation des cas d utilisation On peut proposer un seul diagramme des cas d utilisation : il risque d être très embrouillé. On aura donc intérêt à présenter plusieurs diagrammes d utilisation par niveau d abstraction descendant. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 5/26- Bertrand LIAUDET

Cas Cas d utilisation du menu général Utilisateur d utilisation du menu Gestion de fichier Cas d utilisation du menu général Gestion des fichiers Affichage Edition Gestion des fichiers Etc. Utilisateur Nouveau Ouvrir Sauver Sauver sous Envoyer vers Destinataire Dossier exchange Cas d utilisation du menu Gestion de fichier EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 6/26- Bertrand LIAUDET

Cas d utilisation d une borne de retrait d argent : inclusion et extension Système Borne interactive de banque «extends» (si demandé) Demander un ticket Retirer argent Tout porteur de carte «uses» Faire virement «uses» S'autenthifier «uses» Porteur de carte de la banque Consulter compte Cas d utilisation concret Il y a trois cas d utilisation concrets: «retirer de l argent», «effectuer un virement» et «consulter le compte». Sous-cas d utilisation inclus Ces trois cas d utilisation incluent le sous-cas d utilisation «s authentifier». Sous-cas d utilisation étendu Le cas d utilisation «retirer de l argent» est étendu par le sous-cas d utilisation «demander un ticket» à la condition que ce soit demandé. Inclusion de cas d utilisation Un cas d utilisation correspond au «film» du déroulement du programme pour une utilisation donnée. Un cas d utilisation inclus est un morceau de ce film. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 7/26- Bertrand LIAUDET

Il faut éviter de mettre trop de cas d utilisation inclus pour éviter d alourdir inutilement le diagramme des cas d utilisation. On met des cas d utilisation inclus dans 3 cas : 1. Quand on pense que cela apporte quelque chose à la compréhension du diagramme 2. Quand le cas d utilisation inclus est partagé par plusieurs cas d utilisation. 3. Quand le cas d utilisation inclus est aussi un cas d utilisation pour un acteur. Extension de cas d utilisation C est le même principe que pour les inclusions : Un cas d utilisation correspond au «film» du déroulement du programme pour une utilisation donnée. L extension d un cas d utilisation inclus est un morceau de ce film. Mais ce morceau ne s exécute que sous condition. Il faut éviter de mettre trop d extension de cas d utilisation pour éviter d alourdir inutilement le diagramme des cas d utilisation. On met des cas d utilisation étendus dans 3 cas : 1. Quand on pense que cela apporte quelque chose à la compréhension du diagramme. 2. Quand le cas d utilisation étendu est partagé par plusieurs cas d utilisation. 3. Quand le cas d utilisation étendu est aussi un cas d utilisation pour un acteur. Sur les acteurs Généralisation des acteurs Les acteurs peuvent être généralisés et inversement spécialisés. L intérêt de la généralisation, c est de montrer que certains acteurs héritent de tous les cas d utilisation d autres acteurs, et qu ils ont en plus leur cas d utilisation spécifiques. Dans l exemple traité, l acteur «porteur de carte de la banque» peut consulter son compte et faire des virements. En plus de cela, il peut faire ce que peuvent faire tous les porteurs de carte, à savoir retirer de l argent. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 8/26- Bertrand LIAUDET

Version Version avec héritage Tout porteur de carte Porteur de carte de la banque équivalente sans héritage Retirer argent Faire virement Consulter compte Retirer argent Tout porteur de carte Faire virement Porteur de carte de la banque Consulter compte Différents types d acteurs On peut distinguer entre : Acteur primaire vs Acteur secondaire l acteur primaire, c est l acteur principal : l utilisateur, etc. L acteur secondaire, c est par exemple l administrateur du système. Acteur actif vs Acteur passif : l acteur actif est à l origine du cas d utilisation. L acteur passif n est pas à l origine du cas d utilisation. Acteur humain vs Acteur mécanique : les personnes ou les services par opposition aux périphériques ou aux logiciels. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 9/26- Bertrand LIAUDET

3. Les cas d utilisation du logiciel Formalisme Description des cas d utilisation Exemple Borne interactive d une banque Retirer de l argent Effectuer un virement Client Consulter les comptes UML2, p.3 Cas d utilisation <<stéréotype>> Nom du cas Liste de propriétés Ou bien Nom du cas Liste de propriétés Le petit ovale symbolise le stéréotype <<cas d utilisation >> Ou bien <<cas d utilisation>> Nom du cas Liste de propriétés Stéréotype Un stéréotype est une utilisation particulière d un élément de modélisation. L élément stéréotypé a un parent non stéréotypé. La syntaxe est la même pour l élément stéréotypé et pour son parent, mais la sémantique est différente. Le rectangle (qui est un classeur) est stéréotypé en <<cas d utilisation >> EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 10/26- Bertrand LIAUDET

L ovale (qui est un cas d utilisation) peut être stéréotypé si on en voit l utilité. Le classeur Un classeur est un élément de modélisation qui décrit une unité comportementale ou structurelle. C est la forme la plus simple du regroupement. Un classeur se représente par un rectangle. Le système complet est un classeur. Borne interactive d une banque Retirer de l argent Effectuer un virement Consulter les comptes L acteur Ou bien Nom de l acteur <<acteur>> Nom de l acteur L association C est un lien entre l acteur et le cas d utilisation. Par défaut, l association n est pas orientée : cela signifie que la communication se fait dans les deux sens. En orientant l associant dans un sens, on signifie la priorité d un sens de communication sur un autre. Par exemple : en cas d acteur passif, on pourra orienter l association vers l acteur. Les 3 relations entre les cas d utilisation 3 relations possibles entre les cas d utilisation : EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 11/26- Bertrand LIAUDET

généralisation inclusion extension La relation relie deux cas d utilisation par une flèche. Du côté du départ de la flèche, on parle de source, du côté de l arrivée de la flèche, on parle de destination. Source destination La généralisation Le cas d utilisation source est une espèce du cas d utilisation destination. Le cas d utilisation destination est un genre pour le cas d utilisation source. Par exemple Le cas d utilisation «consulter le compte carte bleue» est une espèce du cas d utilisation «consulter les comptes» Formalisme Ce formalisme vaudra pour toutes les relations de généralisation / spécialisation. Consulter les comptes Consulter le compte CB L inclusion Le cas d utilisation source comprend le comportement du cas d utilisation destination. Donc la destination est une partie nécessaire de la source : D inclut dans S. On peut aussi dire que la destination est une étape obligée de la source. Donc : si S alors D si non D alors non S L inclusion, comme la généralisation, sont des relations structurelles et nécessaires. Par exemple EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 12/26- Bertrand LIAUDET

Le cas d utilisation «Retirer de l argent» inclut le cas d utilisation «s authentifier». «S authentifier» est une étape obligée de «retirer de l argent». Formalisme Retirer de l argent <<inclut>> S authentifier L extension Le cas d utilisation source ajoute son comportement au cas d utilisation destination. Il l ajoute sous condition. Remarque : S il n y avait pas de condition, alors l extension serait une inclusion inversée : le cas d utilisation destination comprendrait le comportement du cas d utilisation source. Mise à part la condition, l extension peut être vue comme équivalente à l inclusion (mais à l envers). Ce qui distingue les deux, c est le caractère nécessaire de l une (inclusion) et le caractère accidentel de l autre (extension). Par exemple Le cas d utilisation «Acheter un billet» est étendu par le cas d utilisation «établir une facture». En effet, le cas d utilisation «établir une facture» sera effectué uniquement à la demande du client. Formalisme Condition : si le client le demande Acheter un billet <<étend>> établir une facture Relation entre les acteurs : la généralisation Il n y a qu une seule relation possible entre les acteurs : la généralisation EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 13/26- Bertrand LIAUDET

L acteur source est une espèce de l acteur destination. L acteur destination est un genre de l acteur source. Exemple et formalisme affichage utilisateur paramétrage administrateur MO.UML, p. 154 L administrateur est une espèce d utilisateur. Tous les administrateurs sont des utilisateurs. Donc les administrateurs accèdent aux cas d utilisation des utilisateurs : ils accèdent à «affichage». Par contre, les utilisateurs n accèdent pas au paramétrage. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 14/26- Bertrand LIAUDET

4. Méthode de construction d un diagramme des cas d utilisation Recherche des acteurs - distinction entre acteur principal et acteur secondaire Est acteur du système tout ce qui est à l extérieur du système et qui interagit avec le système. Les principaux acteurs sont les utilisateurs du système. Mais il ne faut pas oublier ceux qui l administrent d une façon ou d une autre. Ni les acteurs mécaniques : Des périphériques manipulés par le système (imprimantes, système de télétransmission, etc.) Des logiciels interfacés ou intégrés au système (SGBD, etc.) L acteur principal d un cas d utilisation est celui pour qui le cas d utilisation produit le résultat utile. En général, l acteur principal initie le cas d utilisation, mais ce n est pas toujours vrai. Les autres acteurs du cas d utilisation sont dits secondaires. Recherche des cas d utilisation Les cas d utilisation sont les finalités du système : ses objectifs, ce qu on veut qu il permette de réaliser. Les cas d utilisation doivent couvrir tous les besoins fonctionnels du système. Par exemple : Un logiciel de réservation de billet de train sur internet à trois cas d utilisation : La recherche des voyages possibles La réservation des places (on peut réserver et payer plus tard). Le paiement Autre exemple : Dans le cas des retraits d argent, le système interagit avec le système central qui donne les autorisations. Ce système central doit être représenté comme un acteur. Dans ce système il y a trois cas d utilisation : Le retrait d argent La consultation de compte EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 15/26- Bertrand LIAUDET

Les virements de compte à compte Si on distinguait entre consultation du solde et consultation des opérations, on aurait deux espèces de cas d utilisation pour le genre consultation de compte. Mais il n y a pas d acteur qui soit spécifiquement associé à l un de ces cas d utilisation sans être associé aussi au cas général. Donc, la précision des cas d utilisation espèce sera ici inutile au niveau d abstraction le plus élevé. Cas d utilisation principaux Seuls les cas d utilisation directement associés à un acteur sont les cas d utilisation principaux du modèle. C est la liste des cas d utilisation principaux qui doit couvrir exhaustivement toutes les fonctionnalités du système (inclusion et extension peuvent être considérées comme implicites). Les extensions et les inclusions de cas d utilisation sont des précisions apportées, mais qui, le plus souvent, n augmentent pas le nombre des cas d utilisation principaux. Il en va de même pour les généralisations / spécialisations. Recherche des cas d utilisation par la recherche des événements Pour trouver tous les cas d utilisation du système, on peut aussi lister tous les stimulus qui peuvent être envoyés au système. Ces stimulus sont des événements. Evénements externes : ceux qui sont initiés par un acteur externe Evénements temporels : moments qui déclenchent une action dans le système Evénements décision : événements déclenchés par une décision On peut aussi s intéresser aux résultats produits par le système. En effet, les résultats peuvent être à l origine de nouveaux cas d utilisation du système. Recherche par le diagramme des flux et les diagrammes d activité Pour déterminer les cas d utilisation et les acteurs externes, on peut reprendre la technique de l analyse des flux : diagramme des flux et diagrammes d activité par processus. Diagramme des cas d utilisation abstraits - Diagramme des cas d utilisation détaillés On peut produire un diagramme des cas d utilisation principaux : c est le diagramme le plus abstrait. C est celui qui donne la vision fonctionnelle du système la plus globale. Ensuite, pour chaque cas d utilisation abstrait, on peut entrer dans le détail et produire un diagramme des cas d utilisation détaillés. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 16/26- Bertrand LIAUDET

5. TP-PROJET : Diagramme des cas d utilisation avec VISIO Faire la description textuelle des cas d utilisation concrets sous Word. 1. Le dossier «Dossier analyse fonctionnelle» étant sélectionné : bouton droit : créer un soussystème. Renommer ce sous-système en «Logiciel». 2. Le sous-système «Logiciel» étant sélectionné : bouton droit : créer un diagramme des cas d utilisation. Une page de dessin apparaît à droite (si elle reprend un diagramme déjà existant, créer un autre diagramme des cas d utilisation, puis supprimer le premier). 3. Mettez les acteurs qui sont dans l explorateur dans la page de dessin. 4. Mettez les cas d utilisation que vous trouverez dans l explorateur : Formes/Cas d utilisation. 5. Mettez les liens «communication» entre les acteurs et les cas d utilisation. Bouton droit sur le lien : option d affichage, supprimer les options de terminaison : nom 1 er et 2 ème term, et Mult. Terminaison. Double clique sur le lien : supprimez les noms de terminaison et sélectionnez un «is navigable». 6. Mettez les liens d inclusion si nécessaire. Flèche «utilise» dans Formes/Cas d utilisation. Le lien d inclusion se fait du cas incluant vers le cas inclus. 7. Mettez les liens d extension si nécessaires. Flèche «extend» dans Formes/Cas d utilisation. Double clique sur le lien : mettez la condition dans le nom, entre parenthèses. Bouton droit, option d affichage sur le lien : sélectionner nom. Le lien d extension se fait du cas extension vers le cas général (sens inverse du lien d inclusion). 8. Mettez les liens de généralisation si nécessaire. Flèche «généralisation» dans Formes/Structure statique. 9. Mettez les bornes du système. «Limite de système» dans Formes/Cas d utilisation. Modifier le nom et la taille du bloc. On peut courber les liens : bouton droit, lien en arc. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 17/26- Bertrand LIAUDET

LES SCENARIOS ET LEURS SEQUENCES Il est facile de décrire la méthode encore que son application exige à coup sûr savoir et pratique. 1. Les scénarios des cas d utilisation et leurs séquences Diagramme UML ANALYSE FONCTIONNELLE Cas d utilisation Séquence Activités Cas d utilisation et scénarios Un cas d utilisation est une abstraction. Les scénarios correspondent aux instances concrètes d un cas d utilisation. Le scénario nominal est le scénario pour lequel le cas d utilisation est conçu. Les scénarios alternatifs sont les scénarios alternatifs au scénario nominal. Il faut décrire chaque scénario. On peut pour cela soit faire une fiche écrite, soit faire un diagramme UML de séquence. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 18/26- Bertrand LIAUDET

Diagramme de séquence d un scénario : exemple du «save as» Diagramme de séquence du scénario nominal du cas d utilisation : «save as» UC : save as But: sauver sous un nouveau nom Scénario Nominal Pré condition : fichier ouvert Post condition: fichier ouvert Système Word::Utilisateur Entrez nom et répertoire() OK Message synchrone : une fois le message envoyé, l expéditeur est bloqué jusqu à ce que le destinataire accepte le message. Message asynchrone : le message envoyé n interrompt pas l exécution de l expéditeur. Autre représentation d un message asynchrone On s intéresse au logiciel d une banque : un client vient retirer de l argent sur son compte. C est le guichetier qui gère l opération. Description textuelle du cas d utilisation : «save as» On peut aussi décrire les scénarios de façon uniquement textuelle. En général dans ce cas, on décrit à la fois le cas nominal et les cas alternatifs. On n utilisera pas cette méthode. Identification Nom du cas : Save as But : sauvegarder dans un autre fichier Acteur principal : l utilisateur Acteur secondaire : aucun Séquencement Le cas d utilisation se trouve dans le menu Fichier Pré-conditions (état du système avant l opération). Fichier ouvert Enchaînement nominal 1.0 L utilisateur entre le nom et le répertoire du nouveau fichier et valide. 2.0 L application renvoie un message de confirmation de l opération. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 19/26- Bertrand LIAUDET

Post-conditions (état du système après l opération) Fichier sauvegardé ouvert Alternative n 1 1.1 Annulation en cours de saisie (1.1 est une alternative à 1.0).Post-conditions (état du système après l opération) Fichier ouvert et non sauvé. Alternative n 2 2.1 Problème de sauvegarde Post-conditions (état du système après l opération) Retour en 1.0 Diagramme de séquence d un scénario : exemple du «retirer de l argent» Diagramme de séquence du scénario nominal du cas d utilisation : retirer de l argent. On s intéresse au logiciel d une banque : un client vient retirer de l argent sur son compte. C est le guichetier qui gère l opération. UC : retirer de l argent But : retirer de l argent Cas nominal Pré condition : rien Post condition : rien Guichetier : Système Système central Saisie du numéro de compte Demande de type d opération Retrait d espèces de 200 euros Autorisation de délivrer 200 euros Demande de validité du compte Compte valide Demande de débit du compte Compte débité UML2, p. 11 Description textuelle du cas d utilisation : retirer de l argent. On peut aussi décrire les scénarios de façon uniquement textuelle. En général dans ce cas, on décrit à la fois le cas nominal et les cas alternatifs. On n utilisera pas cette méthode. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 20/26- Bertrand LIAUDET

Identification Nom du cas : retirer de l argent But : opération de retrait d argent par un guichetier de banque Acteur principal : le guichetier Acteur secondaire : le système central Séquencement Le cas d utilisation commence quand un client demande un retrait d espèces. Pré-conditions (état du système avant l opération). Système central en état de marche Enchaînement nominal 1.0 Le guichetier saisit le numéro de compte client 2.0 L application valide le compte auprès du système central 3.0 Le système central valide le compte 4.0 L application demande le type d opération au guichetier 5.0 Le guichetier sélectionne un retrait d espèces 6.0 L application demande au système central de débiter le compte. 7.0 Le système central valide la demande 8.0 Le système notifie au guichetier qu il peut délivrer le montant demandé. 9.0 Le guichetier ferme le compte. Post-conditions (état du système après l opération). Aucune Alternative n 1 3.1 Le système central ne valide pas le compte (alternative à 3.0).Post-conditions (état du système après l opération) Retour en 1.0 Alternative n 2 7.1 Le système central ne valide pas le retrait (alternative à 7.0) Post-conditions (état du système après l opération) Retour en 6.0 2. TP-PROJET : Séquence des scénarios avec VISIO Faire les diagrammes de séquences des cas d utilisation sou VISIO. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 21/26- Bertrand LIAUDET

LE DIAGRAMME D ACTIVITE DES SCENARIOS Il est facile de décrire la méthode encore que son application exige à coup sûr savoir et pratique. 1. Les diagrammes d activité dans l analyse fonctionnelle Diagramme UML ANALYSE FONCTIONNELLE Cas d utilisation Séquence Activités 1. Présentation Le diagramme d activité montre l enchaînement des actions (une action est un partie de l activité) et des décisions au sein d une activité du système, ou au sein de tout le système (d où son utilisation en analyse fonctionnelle et en analyse architectonique). 2. Eléments des diagrammes d activité et formalisme UML Action et Activité Une activité est l exécution d un comportement. Une action est une partie de l activité. Une activité est par exemple constituée de plusieurs actions qui se déroule l une après l autre : elles seront reliées par des transition. Transition ou Flux de contrôle Une transition relie deux actions entre elles (source - destination). Une transition peut être réflexive. Elle montre le passage d une activité à l autre. En général, elle est déclenchée par la fin du comportement de l activité source. Etat initial EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 22/26- Bertrand LIAUDET

L état initial montre le point de départ de la première activité. Il n y a qu un seul état initial par activité. Etat final L état final montre le point d arrivée de la dernière activité. Il peut y avoir plusieurs états finaux pour une activité. Transition conditionnelle = décision C est un aiguillage dans une transition. condition On précise la condition de l aiguillage. non oui Attention : la transition conditionnelle indique que le flux peut partir d un côté ou de l autre. Mais attention : il n y a pas de choix à ce niveau. Le choix a été fait au niveau de l action. Synchronisation fourche ou Transition fourche Certaines activités peuvent se dérouler en parallèle : Synchronisation jonction ou Transition jonction Certaines activités peuvent être déclenchées par la fin coordonnée de plusieurs autres Travée ou Couloir Les travées répartissent les activités par responsable des activités (personnes ou service). On peut aussi représenter les acteurs dans les travées. Transition à objet objet : Classe [valeur] On peut faire apparaître les objets dans une transition entre deux activités Les objets représentés sont ceux qui initient des activités, qui sont utilisés par des activités, ou qui sont modifiés par des activités. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 23/26- Bertrand LIAUDET

Transition à signal : envoi et réception Envoi : Recption : On peut faire apparaître l envoi ou la réception d un signal entre deux activités Etat à sous-activité Un état à sous-activités «encapsule» un diagramme d activité. 2. Diagramme d activité d un cas d utilisation On peut représenter tous les scénarios d un cas d utilisation dans un diagramme d activité. On utilisera cette possibilité dans le projet. Exemple : le save as Annulation Activité du save as. Affichage de la fenêtre Sauvegarde EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 24/26- Bertrand LIAUDET

3. Diagramme d activité d un traitement MERISE On peut représenter un traitement au sens MERISE dans un diagramme d activité. On n utilisera pas cette possibilité dans le projet. Exemple : diagramme d activité du traitement PasserCommande Client Service comptable Service livraison Passer Commande Etablir devis Vérifier disponibilité [modifier] Calculer le prix Devis Valider Annuler valider Facture [émise] établir la facture préparer la commande Régler la facture Facture [réglée] valider le paiement Livrer commande Clôturer dossier Etat initial Etat final Synchronisation UML2, p. 165 Activité transition Classe / Objet EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 25/26- Bertrand LIAUDET

4. TP-PROJET : Séquence des scénarios avec VISIO Faire un diagramme d activité pour tous les scénarios de quelques cas d utilisation sous VISIO. 1. Créez un diagramme d activité dans le sous-système logiciel (dans l explorateur). 2. Mettez un état initial : Etat initial pris dans Formes/Activités. 3. Mettez une activité : Etat action pris dans Formes/Activités. 4. Mettez un lien entre l état initial et l activité : Flux de contrôle pris dans Formes/Activités. 5. Mettez des décisions si nécessaire. EPITECH - CSI - UML Analyse Fonctionnelle - 2007-2008 - page 26/26- Bertrand LIAUDET