Diagrammes de CAS D’UTILISATION

Modélisation Orientée Objet / Cas d ’utilisation

Diagrammes deDiagrammes deCAS D’UTILISATIONCAS D’UTILISATION

Modélisation Modélisation FonctionnelleFonctionnelle


Besoins des

utilisateurs

Modélisation descas d’utilisation

Modélisation « Métier »

Maquette IHM

Aéroport

VolRegulier

numero_vol : integerjour : StringheureDepart : HeureduréeMoyenne : integer

programmer()

1..1+origine 1..1

depart

1..1 +destination1..1

arrivee

Vol

date : Date

differer()annuler()

0..*1 0..*1

instanciation

Avion

1

affretement

+avion_affrete 1

Modélisation de conception détaillée

ProgrammerVol

Affréteravion

Nommeréquipage

Prendreréservation

Réserver

AnnulerVol

[réservations insuffisantes]

[réservations terminées]

Débuterembarquement

ProgrammerVol

Affréteravion

Nommeréquipage

Prendreréservation

Réserver

AnnulerVol




Modélisation dynamique

Vol

destination : stringdate : stringheure : stringnumero : short

reserver()

(from IDL)

<<Interface>>

Compagnie

rechercherVol()

(from IDL)

<<Interface>>

+volsAssures

nn

Vols(from IDL)

<<CORBATypedef>>

VolImpl

destinationdateheurenumero

VolImpl()destination()destination()date()date()heure()heure()numero()numero()reserver()

(from serveur)CompagnieImpl

CompagnieImpl()vols_Assurés()vols_Assurés()rechercherVol()

(from serveur)

-vols_Assurés

nn

ApplicationClient

main()

(from client)

Modélisation objet

Modélisation des Scénarios d’utilisation

Structuration

groupe VidePrimaire enceinte

systeme de mise sous vide

dispositifs de vide

dispositif mise à l'air

canalisation

Modélisation de l’architecture

Modélisation des interactionsC TR L 1 :

C o n t ro le u rE : E n c e in te V P P : V a n n e V P S 1 : V a n n e V PS 2 : V a n n e V P S 3 : V a n n e C ry o1 : P o m p e

c ry oC ry o 2 : P o m p e

c ry oC r y o3 : Po m p e

c ry oC o m p 1 :

C o m p re s s e u r

1 : fa ire V id e S e c o n d a ire ( )

2 : fe rm e r( )

3 : o u vrir( )

4 : o u vr ir ( )

5 : o u vrir( )

F e rm e r la va n n e V PP e t o u vr ir le s tr o is V P S s im u lta n é m en t

C o m m e n t in d iq u e r le s é q u a t io n s d e s é c u rité ? ? ?

6 : s to p p e rV id e S e c o nd a i re ( )

7 : fe rm e r( )

8 : fe rm e r( )

9 : fe rm e r ( )

1 0 : a rrê te r( )

1 1 : a rrê te r( )

1 2 : a rrê te r ( )

class CompteClient{publicvoid imprimer();int numero;String nom;String adresse;

};...void CompteClient::imprimer(){

cout <<"numero:"<<numero<<endl;cout <<"nom:" << nom << endl;cout <<"adresse:"<<adresse<<endl;

};

Code

MODELISATION PAR CAS D’UTILISATION Place dans le processus de développementMODELISATION PAR CAS D’UTILISATION Place dans le processus de développement


MODELISATION FONCTIONNELLE Décider de ce qu'il faut faire MODELISATION FONCTIONNELLE Décider de ce qu'il faut faire

A quoi sert le logiciel?


MODELISATION PAR CAS D’UTILISATION GénéralitésMODELISATION PAR CAS D’UTILISATION Généralités

Technique formalisée par Ivar Jacobson.

Destinée à l ’expression du besoin.

Complète le modèle objet en offrant une vision « fonctionnelle » du système.

Centrée sur les utilisateurs.

Formalisme très simple.

Peut également servir à la conception des tests de validation.


Intégration

Réalisation

Validation

Conception Préliminaire

Spécifications

MODELISATION PAR CAS D’UTILISATION Lien avec le modèle objetMODELISATION PAR CAS D’UTILISATION Lien avec le modèle objet


MODELISATION PAR CAS D’UTILISATION DéfinitionMODELISATION PAR CAS D’UTILISATION Définition

Un cas d’utilisation « raconte » comment on doit utiliser le système pour atteindre un but particulier

Il correspond à une fonction du systèmeIl décrit les interactions entre le système et les utilisateursIl est exprimé en prose structuréeIl détermine un contrat à remplir par le systèmeIl induit des exigences fonctionnelles applicables au système et il peut être utilisé pour organiser la spécification


DIAGRAMMES DE CAS D ’UTILISATIONConceptsDIAGRAMMES DE CAS D ’UTILISATIONConcepts

ACTEUR représente un rôle joué par une personne ou une

chose qui interagit avec le système mais qui lui est extérieure.

est caractérisé par un nom qui exprime son rôle. une même personne physique peut être modélisée par

plusieurs acteurs.Etudiant

Inscription

CAS D ’UTILISATION unité fonctionnelle cohérente assurée par un

système ou une classe correspond à un certain type d’interaction entre le

système et les acteurs. doivent être vus comme des classes dont les

instances sont des scénarios.


DIAGRAMMES DE CAS D ’UTILISATIONUn premier exempleDIAGRAMMES DE CAS D ’UTILISATIONUn premier exemple

Consulter sa BAL

Lire un message reçu

Envoyer un message

Classer les messages reçus

Internaute

Enregistrer un contact


CAS D ’UTILISATIONIdentification des acteursCAS D ’UTILISATIONIdentification des acteurs

On distingue 4 catégories d ’acteurs:

les acteurs principaux (ex: usager, client, etc.)

les acteurs secondaires (ex: opérateur de maintenance, administrateur, etc.)

le matériel externe (capteurs, imprimantes, périphériques divers, etc.)

les autres systèmes (serveur central, service ou organisation, etc.)

Un Acteur peut hériter d’autres Acteurs.

Un Acteur peut posséder des Interfaces.

Cycliste

Facteur

Circuler à bicyclette

Distribuer le courrier


DIAGRAMMES DE CAS D ’UTILISATION Exemple de modélisation des acteursDIAGRAMMES DE CAS D ’UTILISATION Exemple de modélisation des acteurs

Atelier Carto<<Actor>>

Utilisateur autorisé

Usager Opérateur

Conducteur ControleurPassager Administrateur

Récepteur GPS<<Actor>>


DIAGRAMMES DE CAS D ’UTILISATION Exemple avec utilisation de stéréotypesDIAGRAMMES DE CAS D ’UTILISATION Exemple avec utilisation de stéréotypes

Operateur

(from Segment Sol)

Operateur de Maintenance

(from Segment Sol)

Opérateur de Commandement(from Segment Sol)

Organisme Coordination

communication

Operateur d'Administration(from Segment Sol)

Opérateur CU

(from Segment Sol)

Charge Utile(from Segment Air)

pilotage

Plate Forme Aeronautique(from Segment Air)

+porteur

Opérateur Contrôle/commande

(from Segment Sol)

contrôle

Source: Système Aéroporté de Surveillance Terrestre


DIAGRAMMES DE CAS D ’UTILISATION Modélisation des utilisateursDIAGRAMMES DE CAS D ’UTILISATION Modélisation des utilisateurs

Utilisateur

nom : StringmotPasse : StringniveauDroits : Integer

Utilisateur()identifier(nom : String, passwd : String) : IntegerattribuerDroits(niveau : Integer)nouveauMotPasse(passwd : String)

(from Logical View)

Administrateur Gerer utilisateurUtilisateur

S'identifier

Outils d'administration Application


CAS D ’UTILISATION Identification (1)CAS D ’UTILISATION Identification (1)

Les cas d ’utilisation correspondent• aux principales tâches de chaque acteur• à une valeur ajoutée pour l ’utilisateur• à des fonctionnalités ou à des services attendus• à des opérations sur les données du système• à des anomalies ou des cas particuliers.

Un cas d ’utilisation doit être simple (description de 1 ou 2 pages maximum).Le nombre d ’acteurs en relation avec un cas d ’utilisation ne doit pas être trop important.2 activités qui s ’enchaînent toujours font généralement partie du même cas d’utilisation.

La difficulté majeure est de trouver le bon niveau d’abstraction.


CAS D ’UTILISATION Identification (2)CAS D ’UTILISATION Identification (2)

Un cas d’utilisation représente un processus de « haut niveau » se déroulant de bout en bout et incluant plusieurs étapes successives.

Ce n’est pas une opération élémentaire ou une transaction.

Un cas d’utilisation peut être vu comme une collection de scénarios décrivant différentes façons d’utiliser le système pour atteindre un même but (avec ou sans succès).

Un cas d’utilisation ne se décompose pas en « sous-cas d’utilisation ».


CAS D ’UTILISATION Description caractéristiqueCAS D ’UTILISATION Description caractéristique

La description d’un cas d’utilisation

• débute par une phrase du type« Ce cas d’utilisation est déclenché quand <un acteur> <adresse un stimulus au système>

…»

• privilégie les interactions entre les acteurs et le système

• s’attache prioritairement à la séquence des événements qui conditionnent les interactions (flux nominal)

• se termine lorsque le but est atteint ou dans une situation d'exception.

Si cette description est impossible, c’est probablement parce que l’objet considéré n’est pas vraiment un cas d’utilisation …


CAS D ’UTILISATION ConstructionCAS D ’UTILISATION Construction

1) Identifier les acteurs (Qui utilise le système?)

2) Identifier grossièrement les cas d ’utilisation essentiels.

3) Identifier les cas d ’utilisation exceptionnels.

4) Décrire chaque cas d ’utilisation en quelques phrases.

5) Elaborer un diagramme.

6) Vérifier que tous les besoins identifiés ont été alloués à un cas d ’utilisation.

7) Recenser les principaux scénarios pour chaque cas d ’utilisation.


CAS D ’UTILISATION Niveaux de descriptionCAS D ’UTILISATION Niveaux de description

•Détaillé Description précise et

structurée Description des alternatives

•Général Brève description 3-5 phrases

Calculer un itinéraire

Titre: Calculer un itinéraireActeur: UsagerDescription: Ce cas d’utilisation commence lorsque l’usager se connecte au système pour obtenir un itinéraire à suivre. Il précise son lieu de départ et son lieu d’arrivée ainsi que les paramètres de calcul. Le système lui fournit une chronologie des étapes à suivre pour atteindre la destination dans les conditions souhaitées.


CAS D ’UTILISATION Description détailléeCAS D ’UTILISATION Description détaillée

CANEVAS:•nom explicite (= label UML)•acteurs concernés•brève description (entre 3 et 10 lignes)•pré-conditions•événement déclenchant•événement qui cause l ’arrêt•Résultats attendus / post-conditions•description du flot d ’événements principal

•interactions avec les acteurs•échanges d ’informations (paramètres des interactions)•chronologie et origine des informations•répétitions de comportement

•description des flots secondaires et des exceptions•contraintes et règles de gestion•exigences couvertes


CAS D ’UTILISATION Exemple: 1ère partieCAS D ’UTILISATION Exemple: 1ère partie

Titre : Edition d’un plan de réseau régional Version : 1.0 Auteur : P. Giroux Date : 02/09/03 Objet : Ce cas d’utilisation commence lorsque l’usager décide d’élaborer le plan du

réseau routier d’une région géographique. L’objectif est de faire figurer sur ce plan les différents sites (villes, villages, hameaux, lieux dits, carrefours, etc.) qui peuvent être pris en compte comme étape lors du calcul d’un itinéraire.

Acteur(s) : Opérateur Pré condition(s) : Un fond cartographique est disponible ( les cartes de la région ont été

numérisées et enregistrées dans la base de données) Evénement déclenchant : Prise en compte d’une nouvelle région,

Mise à jour d’une région Evénement qui cause l’arrêt : Décision de l’opérateur (Couverture de la région jugée suffisante) Résultat(s) attendu(s) : Raccordement avec les réseaux régionaux des régions géographiquement

attenantes.


CAS D ’UTILISATION Exemple: 2ème partieCAS D ’UTILISATION Exemple: 2ème partie

Enchaînement nominal : Les acteurs Le système

1.démarre l’application 3.définit la zone de travail Pour tous les sites de la région 5 désigne sur la carte un site d’étape 6. complète le formulaire et le valide 10.sort de l’application

2.ouvre la fenêtre d’édition et un formulaire pour définir la zone de travail 4.charge le fond cartographique 6.affiche un symbole graphique et ouvre un formulaire de description du site 7.enregistre le site dans la base de données 8.détermine automatiquement des routes de jonction avec les autres sites en fonction de la cartographie et calcule les distances entre sites en fonction de l’échelle de la carte. 9.enregistre les routes de jonction dans la base de données. 11. ferme la fenêtre d’édition

Exceptions :

Jonction impossible La route de jonction avec le site désigné ne peut être déterminée. Base de données saturée Espace disque insuffisant pour enregistrer les données dans la base Séquences alternatives :

Si il existe déjà des sites définis pour la région

4. Les sites existants sont lus en base de données et affichés avec la cartographie


DIAGRAMMES DE CAS D ’UTILISATION Liens entre cas d ’utilisationDIAGRAMMES DE CAS D ’UTILISATION Liens entre cas d ’utilisation

Communication – exprime le fait que l ’acteur participe à la réalisation d ’un cas d ’utilisation . C ’est la seule relation qui peut exister entre un acteur et un cas d ’utilisation. Consommateur

Payer

Régler par chèque

Payer

Régler par CB

Généralisation - un cas d ’utilisation « enfant » hérite du

comportement et de la sémantique du cas d ’utilisation parent

Régler par CB Composer Code

<<include>>

Relation « Include » – Une relation « include » du cas d ’utilisation A vers le cas d ’utilisation B signifie que le flot d ’événements de A contient une séquence d ’événements qui correspond à B.

Remplir ordre et montant automatiquement

Régler par chèque

<<extend>>Relation « Extend » – Une relation « extend » du cas d ’utilisation A vers le cas d ’utilisation B signifie que le flot d ’événements de A peut intervenir, de façon facultative, pendant le déroulement de B. B spécifie un comportement facultatif


DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « include »DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « include »

L ’existence d ’une relation « include » sur un cas d ’utilisation signifie qu’il inclut le comportement défini par un autre cas d ’utilisation.

La relation « include » permet de factoriser certaines parties d’un cas d ’utilisation

Usager

Rechercher une destination

Calculer un itineraire

Controleur

Visualiser sur fond de carte

<<include>>

<<include>>

Suivre les déplacements des véhicules

<<include>>


DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « extend »DIAGRAMMES DE CAS D ’UTILISATION Exemple de relation « extend »

Remplacer

Rechercher<<extend>> demande de remplacement

de chaque occurrence trouvéeExtension points

• définition du remplaçant: avant début de recherche• substitution: à chaque occurrence trouvée

mot clef (stéréotype)

Condition d’extension

Points d’extension

L ’existence d ’une relation « extend » sur un cas d ’utilisation signifie qu’il constitue une extension possible du comportement défini par le cas d ’utilisation désigné.

UML permet d’exprimer les conditions et les points d’extension.


DIAGRAMMES DE CAS D ’UTILISATION Exemple (1) DIAGRAMMES DE CAS D ’UTILISATION Exemple (1)

Usager

Rechercher une destination

Calculer un itinéraire

Controleur

Visualiser sur fond de carte

<<include>>

<<include>>

Suivre les déplacements des véhicules

<<include>>

Suivre les déplacements en convoi

<<extend>>


DIAGRAMMES DE CAS D ’UTILISATION Cardinalités du lien de communicationDIAGRAMMES DE CAS D ’UTILISATION Cardinalités du lien de communication

Emettre un appel Recevoir un appel

Usager Téléphoner*22 *

Usager Appeler un correspondant11 11

Téléphoner en mode conférence

<<extend>>

Correspondant

1

1

1

*

11


DIAGRAMMES DE CAS D ’UTILISATION Exemple (1)DIAGRAMMES DE CAS D ’UTILISATION Exemple (1)

Organisme Coordination(from Acteurs)

Opérateur de Commandement

(f rom Segment Sol)

Utilisateur(from Utilisateurs)

Plate Forme Aeronautique

(f rom Segment Air)

Opérateur Contrôle/commande

(f rom Segment Sol)

SIC de Théâtre(from Utilisateurs)

Recevoir Ordre

Prendre en compte la situationPréparer une Mission

<<include>>

<<include>>

Elaborer plan de vol

<<include>>

Reprogrammer un vol

<<include>>

Suivre et adapter un vol

<<extend>>

Recevoir un message electroniqueSaisir les données au clavier




Traiter les données IMINT

Traiter les données SIGINT

Charge Utile

(f rom Segment Air)

Opérateur CU

(f rom Segment Sol)

Utilisateur(from Utilisateurs)

Restituer la missionOpérateur de

Commandement(f rom Segment Sol)

Piloter la CU

Exploiter les données en TR

<<include>>

Exploiter les données en TD

Traiter les données d'observation

<<include>>

<<include>>




Suivi de Mission Réception de télémesures

Visualisation fil de l'eau

Archivage

Traitement

Acquisition de Télémétries

Météorologue Diffusion

Satellite<<Actor>>

Opérateur Centre de Mission

Emission de télécommandes

Programmation

Contrôle

<<include>>

<<extend>>

<<include>>

<<extend>>

<<include>>

<<include>>


CAS D ’UTILISATION Intérêt méthodologiqueCAS D ’UTILISATION Intérêt méthodologique

Edition Graphique

Edition de Situation

Commandement

Administrateur

Visualisation Carto/GéoGestion Données

Interprétation d'image

Photo Interprète

Edition de Plan Renseigné

Interprétation d'image

Edition de Plan Renseigné

Edition de Situation

Gestion Données

Edition Graphique

Visualisation Carto/Géo

Itération d ’architecture

Itération de développement 1




Proto

V1 = Proto +

V2 = V1 +

V3 = V2 +

V4 = V3 +

•Recentre le développement sur le besoin.•Délimite le système à étudier.•Permet d ’améliorer la compréhension du fonctionnement.•Assure la transition entre l’aspect fonctionnel du cahier des charges et l ’aspect objet de la conception technique.

•Permet de planifier le développement.


CAS D ’UTILISATION HiérarchisationCAS D ’UTILISATION Hiérarchisation

Il faut commencer par réaliser les cas d’utilisation les plus importants …

Critères de priorité d’un cas d’utilisation: Importance de la fonctionnalité pour l’utilisateur Impact sur l’architecture technique Complexité des fonctions mises en œuvre Poids des exigences et contraintes à satisfaire Nouveauté de la technologie utilisée Incidence économique


CAS D ’UTILISATION RecommandationsCAS D ’UTILISATION Recommandations

1. Ne pas présumer des choix de conception d’IHM

2. Ne pas considérer les cas d’utilisation comme de simples fonctions.

3. Ne pas chercher à spécifier le détail des cas d’utilisation "du premier coup"

4. Ne pas hésiter à compléter le cas d’utilisation par d'autres diagrammes UML.

5. Étudier alternativement les scénarios nominaux, alternatifs et d'exception


CAS D ’UTILISATION Organiser le travailCAS D ’UTILISATION Organiser le travail

Spécifications

Recueil desBesoins fonctionnels

Conception détaillée

Réalisation / Codage

Tests et recette

Livraison et déploiement

Recueil desBesoins techniques

Architecture

Études et prototypages

Besoins des

utilisateurs

Choix techniques




};

Vol


reserver()

(from IDL)

<<Interface>>

Compagnie

rechercherVol()

(from IDL)

<<Interface>>

+volsAssures

nn

Vols(from IDL)

<<CORBATypedef>>

VolImpl





(from serveur)

-vols_Assurés

nn

ApplicationClient

main()

(from client)

Le cycle de développement en YLe cycle de développement en Y


CAS D ’UTILISATION Cas d’utilisation « métier »CAS D ’UTILISATION Cas d’utilisation « métier »

Les cas d’utilisation peuvent être utilisés pour conduire une modélisation « métier »:

Un « Business Use Case » représente un processus métier de l’entreprise

Les « Business Actors » et « Business Workers » représentent des participants internes ou externes à l’entreprise.

Etudiant

EnseignantScolarité

Direction

processus de formation


DIAGRAMMES DE CAS D ’UTILISATION ExerciceDIAGRAMMES DE CAS D ’UTILISATION Exercice

Modéliser un système de type

« Lecteur/Enregistreur Vidéo »

( magnétoscope, DVD R/W, etc.)

Identifier et formaliser ses cas d’utilisation


DIAGRAMMES DE CAS D ’UTILISATION Jeu d'échecsDIAGRAMMES DE CAS D ’UTILISATION Jeu d'échecs

• Identifier et modéliser des cas d'utilisation du jeu d'échecs.• Proposez une stratégie de développement associée• Décrivez l'un des cas en utilisant le canevas suivant

nom explicite (= label UML) acteurs concernés brève description (entre 3 et 10 lignes) pré-conditions événement déclenchant événement qui cause l ’arrêt Résultats attendus / post-conditions description du flot d ’événements principal

• interactions avec les acteurs• échanges d ’informations (paramètres des interactions)• chronologie et origine des informations• répétitions de comportement

description des flots secondaires et des exceptions contraintes et règles de gestion exigences couvertes


Diagrammes de SEQUENCEDiagrammes de SEQUENCE

Modélisation de Modélisation de scénarii d’utilisationscénarii d’utilisation


Besoins des

utilisateurs

Modélisation descas d’utilisation

Modélisation « Métier »

Maquette IHM

Aéroport

VolRegulier

numero_vol : integerjour : StringheureDepart : HeureduréeMoyenne : integer

programmer()

1..1+origine 1..1

depart

1..1 +destination1..1

arrivee

Vol

date : Date

differer()annuler()

0..*1 0..*1

instanciation

Avion

1

affretement

+avion_affrete 1

Modélisation de conception détaillée

ProgrammerVol

Affréteravion

Nommeréquipage

Prendreréservation

Réserver

AnnulerVol




ProgrammerVol

Affréteravion

Nommeréquipage

Prendreréservation

Réserver

AnnulerVol




Modélisation dynamique

Vol


reserver()

(from IDL)

<<Interface>>

Compagnie

rechercherVol()

(from IDL)

<<Interface>>

+volsAssures

nn

Vols(from IDL)

<<CORBATypedef>>

VolImpl





(from serveur)

-vols_Assurés

nn

ApplicationClient

main()

(from client)

Modélisation objet

Modélisation des Scénarios d’utilisation

Structuration

groupe VidePrimaire enceinte

systeme de mise sous vide

dispositifs de vide

dispositif mise à l'air

canalisation

Modélisation de l’architecture

Modélisation des interactionsC TR L 1 :

C o n t ro le u rE : E n c e in te V P P : V a n n e V P S 1 : V a n n e V PS 2 : V a n n e V P S 3 : V a n n e C ry o1 : P o m p e

c ry oC ry o 2 : P o m p e

c ry oC r y o3 : Po m p e

c ry oC o m p 1 :

C o m p re s s e u r

1 : fa ire V id e S e c o n d a ire ( )

2 : fe rm e r( )

3 : o u vrir( )

4 : o u vr ir ( )

5 : o u vrir( )

F e rm e r la va n n e V PP e t o u vr ir le s tr o is V P S s im u lta n é m en t

C o m m e n t in d iq u e r le s é q u a t io n s d e s é c u rité ? ? ?

6 : s to p p e rV id e S e c o nd a i re ( )

7 : fe rm e r( )

8 : fe rm e r( )

9 : fe rm e r ( )

1 0 : a rrê te r( )

1 1 : a rrê te r( )

1 2 : a rrê te r ( )




};

Code

MODELISATION DES SCENARIOSPlace dans le processus de développementMODELISATION DES SCENARIOSPlace dans le processus de développement


MODELISATION DE SCENARIOS Étudier l'usage MODELISATION DE SCENARIOS Étudier l'usage

Comment utilisera-t-on le logiciel ?


MODELISATION DES SCENARIOSCas d ’utilisation et scénariosMODELISATION DES SCENARIOSCas d ’utilisation et scénarios

Un scénario est une série d ’événements ordonnés dans le temps, simulant une exécution particulière du système.

Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios dont la description permet d ’expliciter le comportement du système pour une situation donnée.

Usager Correspondant

Appeler un correspondant

communication directe

ligne occupée

sans réponse

communication par répondeur

ligne en dérangement

etc...


MODELISATION DES SCENARIOSExtrait du méta-modèleMODELISATION DES SCENARIOSExtrait du méta-modèle

Classifier(from Core)

Instance(from Common Behavior)

Acteur Cas d ’utilisation

Extension Point : list of StringScénario

réalisation

spécification

classifier

*

*

*1..*


DIAGRAMMES DE SEQUENCEGénéralitésDIAGRAMMES DE SEQUENCEGénéralités

Les diagrammes de séquences montrent les interactions entre objets selon un point de vue temporel.

tem

ps

: Correspondant : Usager : Telephone

decrocher( )

tonalité

composer numéro( ) sonnerie

decrocher( )

parler( )

ecouter( )

transmission voix


MODELISATION DES SCENARIOSDiagramme de séquence « système »MODELISATION DES SCENARIOSDiagramme de séquence « système »

Un diagramme de séquence « système » traite le système comme une « boîte noire »

représente les interactions entre les acteurs et le système

illustre la succession temporelle des événements qui influencent le fonctionnement du système

met en évidence les responsabilités élémentaires du système

permet de bien délimiter les frontières du système

: InternauteLogiciel de messagerie

Serveur de messages

s'identifier (login)se connecter()

recupérer nouveaux messages()lire BAL()


DIAGRAMMES DE SEQUENCEExerciceDIAGRAMMES DE SEQUENCEExercice

Modéliser un scénario d’utilisation du

« Lecteur/Enregistreur Vidéo »

Documents

Diagrammes de CAS D’UTILISATION