CONCEPTION des SYSTÈMES d`INFORMATION UML SOMMAIRE

Transcription

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.
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
Cas d’utilisation
ANALYSE
FONCTIONNELLE
Séquence
Activités
Cas d’utilisation
Un cas d’utilisation est, comme son nom l’indique :
un usage du système (du programme), une fonctionnalité du système.
Un cas d’utilisation est :
une fonctionnalité complète du système.
Par exemple :
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 :
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.
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
New
Fichier
Edition
Affichage
Insertion etc.
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.
Cas d’utilisation des menus
Affichage
Edition
Gestion des
fichiers
Utilisateur
«hérite»
Nouveau
Ouvrir
«hérite»
«hérite»
Sauver
«hérite»
«hérite»
Envoyer vers
Sauver sous
«hérite»
Destinataire
«hérite»
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.
Cas d’utilisation du menu général
Affichage
Edition
Gestion des
fichiers
Utilisateur
Etc.
Cas d’utilisation du menu général
Cas d’utilisation du menu Gestion de fichier
Gestion des
fichiers
«hérite»
«hérite»
«hérite»
«hérite»
«hérite»
Utilisateur
Nouveau
Ouvrir
Sauver
Envoyer vers
Sauver sous
«hérite»
«hérite»
Destinataire
Cas d’utilisation du menu Gestion de fichier
Dossier exchange
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»
«hérite»
«uses»
S'autenthifier
Faire virement
«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.
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.
Version avec héritage
Retirer argent
«hérite»
Faire virement
Consulter compte
Version équivalente sans héritage
Retirer argent
Faire virement
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.
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
Le petit ovale symbolise le stéréotype <<cas d’utilisation >>
Ou bien
<<cas d’utilisation>>
Nom du cas
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 >>
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
Effectuer un virement
L’acteur
Nom de l’acteur
Ou bien
<<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 :
•
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 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
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
<<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
Acheter un billet
Condition : si le
client le demande
<<é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
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.
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
•
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.
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 1er 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.
LES SCENARIOS ET LEURS SEQUENCES
pratique.
1.
Les scénarios des cas d’utilisation et leurs séquences
Diagramme UML
Cas d’utilisation
ANALYSE
FONCTIONNELLE
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.
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.
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
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 validité du compte
Compte valide
Demande de type d’opération
Retrait d’espèces de 200 euros
Demande de débit du compte
Compte débité
Autorisation de délivrer 200 euros
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.
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)
Retour en 6.0
2.
Faire les diagrammes de séquences des cas d’utilisation sou VISIO.
LE DIAGRAMME D’ACTIVITE DES SCENARIOS
pratique.
1.
Les diagrammes d’activité dans l’analyse fonctionnelle
Diagramme UML
Cas d’utilisation
ANALYSE
FONCTIONNELLE
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
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.
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
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
Passer Commande
Etablir devis
Service livraison
Vérifier disponibilité
[modifier]
Calculer le prix
Devis
Valider
valider
Annuler
Facture [émise]
établir la facture
Facture [réglée]
valider le paiement
préparer la commande
Régler la facture
Livrer commande
Clôturer dossier
UML2, p. 165
Etat initial
Activité
Etat final
Synchronisation
transition
Classe / Objet
4.
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.

CONCEPTION des SYSTÈMES d`INFORMATION UML SOMMAIRE

Transcription

Documents pareils

Laetitia Asse - Jose Antunes

Laetitia Asse - Jose Antunes

Le logiciel TABLEUR-GRAPHEUR Pour réaliser un diagramme :

GS/km/MM Le 3 février 2009 Changements de personnel – siège de

Diagrammes UML + outil - Membres du Departement d`Informatique

DM Génie Logiciel Projet Serious Game

TP UML - PolyDocs

Modlisation objet avec UML

Modélisation Des Besoins avec UML

Système de diagnostic de Mercedes-Benz XENTRY - Kjs