CONCEPTION des SYSTÈMES d’INFORMATION...

EPITECH - CSI - UML – Analyse Fonctionnelle - 2007-2008 - page 1/26- Bertrand LIAUDET

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


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’uti lisation

Diagramme UML

Cas d’utilisation

Séquence ANALYSE

FONCTIONNELLE

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

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.


Cas d’utilisation des menus

Utilisateur

Gestion desfichiers

Nouveau Ouvrir Sauver Sauver sous Envoyer vers

«hérite»«hérite» «hérite»«hérite»

«hérite»

Destinataire Dossier exchange

«hérite» «hérite»

Edition

Affichage

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

UtilisateurGestion des

fichiers

Edition

Affichage

Etc.

Cas d’utilisation du menu général

� Cas d’utilisation du menu Gestion de fichier

Utilisateur

Gestion desfichiers

Nouveau Ouvrir Sauver Sauver sous Envoyer vers

«hérite»«hérite» «hérite»«hérite»

«hérite»

DestinataireDossier exchange

«hérite» «hérite»

Cas d’utilisation du menu Gestion de fichier


Cas d’utilisation d’une borne de retrait d’argent : inclusion et extension

Tout porteur de carte

Porteur de carte de la banque

«hérite»

Retirer argent

Faire virement

Consulter compte

S'autenthifier

«uses»

«uses»

«uses»

Demander un ticket«extends»(si demandé)

Système Borne interactive de banque

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



«hérite»

Retirer argent

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

Consulter les comptes

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 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


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 sous-systè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


1. Les scénarios des cas d’utilisation et leurs séq uences

Diagramme UML

Cas d’utilisation

Séquence ANALYSE

FONCTIONNELLE

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 »

Système

Word::UtilisateurEntrez nom et répertoire()

OK

UC : save asBut: sauver sous un nouveau nomScénario NominalPré condition : fichier ouvertPost condition: fichier ouvert

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 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 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) 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.


LE DIAGRAMME D’ACTIVITE DES SCENARIOS


1. Les diagrammes d’activité dans l’analyse fonctio nnelle

Diagramme UML

Cas d’utilisation

Séquence ANALYSE

FONCTIONNELLE

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

Activité du save as. Affichage de la fenêtre

Annulation

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 Service livraison

Passer Commande Etablir devis

Vérifier disponibilité

[modifier]

Calculer le prix

Devis

Valider

valider

Annuler

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

UML2, p. 165

Etat initial Etat final Synchronisation

Activité transition Classe / Objet


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.

CONCEPTION des SYSTÈMES d’INFORMATION...

Documents

Transcript of CONCEPTION des SYSTÈMES d’INFORMATION...