uml les cas dutilisation (use cases). 2 identification des acteurs et des cas dutilisation...
TRANSCRIPT
UML
Les cas d’utilisation (use cases)
2
Identification des acteurs et des cas d’utilisation
• Identification des acteurs– entité externe qui interagit avec le système
• Identification des cas d’utilisation– modélisation d’un service rendu par le système
• Construire le diagramme de cas d’utilisation
3
Les acteurs
• Entité externe qui interagit avec le système– attend des services de la part du système– l’interaction : envoi/réception de messages– peut être une personne ou un autre système
• Sont décrits par leur rôle et leur relation avec les cas d’utilisation
« acteur »autre système
4
Les cas d’utilisation
• Un CU modélise un service rendu par le système– exprime les interactions acteurs/système
– apporte une valeur ajoutée « notable » aux acteurs concernés
– la façon dont le système réalise le service est masquée
• Le déroulement du CU est contrôlé par les acteurs– l’événement déclencheur vient d’un acteur
– acteur principal : bénéficiaire du CU
5
Diagramme de cas d ’utilisation
Pilote
Conduire
Ravitailler
Mécanicien
Envoyer infos
Réparer
Formule 1
« acteur »système detélémesure
6
Identification des CU
• Pour chaque acteur identifié– rechercher les façons dont il utilise le système
– rechercher dans le cahier des charges les services attendus du système
• Pour chaque CU– vérifier qu’il fournit un service notable aux acteurs
– vérifier qu’il est déclenché par un événement externe
• Uniformiser le niveau d’abstraction des CU
7
Description d’un cas d’utilisation
• Description textuelle (non normalisée)– sommaire d ’identification (titre, résumé, acteurs,
responsable…)
– description des enchaînements (enchaînements nominaux, alternatifs, exceptions...)
• Un CU contient un ou plusieurs scénarios.– Les scénarios seront décrits par des diagrammes de
séquence, de collaboration etc.
8
Relations entre cas d’utilisation
VendreCalculer TVA
« inclut »
Faire rabais
«étend »Montant > 500 Francs
Vendre en gros
Points d ’extension•Faire rabais quand quantité déterminéePoints d ’inclusion•TVA suivant prix global
9
Exemple :le guichet automatique de banque
• Le guichet automatique offre les services suivants:– distribution d’argent pour tout porteur de carte de crédit
– consultation de compte, dépôt en numéraire et dépôt de chèques pour les porteurs d’une carte de cette banque
• Le guichet a besoin d’être rechargé régulièrement.
Construire le diagramme de cas d’utilisation pour le guichet automatique de banque
10
Diagramme de CU
Retirer de l’argent
Consulter le solde
Déposer du numéraire
Déposer deschèques
« acteur »SA Visa
« acteur »SI Banque
Porteur C.B. Visa
Client de la banque
11
Relations entre cas d ’utilisation
• Objectif : organiser les C.U., factoriser les parties communes
• Les types de relation standardisés :– inclusion
– extension
– généralisation/spécialisation
• Classification des acteurs
12
Inclusion
• Le cas de base incorpore explicitement un autre, à un endroit spécifié.
• Le CU inclus n’est jamais exécuté seul, mais seulement comme partie d’un cas de plus vaste
Retirer de l’argent
Authentifier client
Consulter le solde
« inclut » « inclut »
13
Extension
• Le cas de base incorpore implicitement un autre• Les deux cas peuvent fonctionner seuls• Le cas source ajoute son comportement au cas
destination– L’extension peut être soumise à une condition
d’extension
– point d’extension : décrit, dans le cas destination, l’emplacement ou le comportement du cas source est inséré.
14
Extension - suite
Consulter le solde
« étend »(vérification montant)Retirer argent
Point d ’extension: vérif montant, etc.
• Dans le cas « Retirer argent », le client peut vouloir vérifier son compte
• Attention au sens des flèches dans les relations inclut/étend
15
Généralisation/spécialisation
• Permet de hiérarchiser les CU– les CU descendants héritent le fonctionnement des
parents.
– le descendant peut ajouter ou modifier des interactions par rapport à son père.
Déposer des chèques
Déposer de l ’argent
Déposer du numéraire
16
Diagramme de CU - version 2
17
Diagrammes dynamiques pour les cas d’utilisation
• L’objectif des CU est de faciliter le dialogue avec les utilisateurs– la description textuelle peut devenir complexe,
ambiguë…
– description graphique : vue plus synthétique
• Quelques conditions :– description du système en tant que boite noire
– favoriser la lisibilité
18
Diagrammes dynamiques - suite• Le cas d’utilisation se décompose en scénarios
– scénario nominal, enchaînements alternatifs
– chaque scénario et chaque CU description textuelle
• Descriptions graphiques des CU– diagrammes d’activité (organigramme, compréhensible)
– diagrammes d’états (automates d’états; utilisé dans certains
cas)
• Descriptions graphiques des scénarios– diagramme de séquence (axe temporel, très simple)
– diagramme de collaboration (dimension « spatiale »)
19
Diagrammes de séquence
• Diagrammes de séquence « système »– illustre la succession temporelle des communications,
par messages acteurs/système
– acteur principal (à gauche), système, acteurs secondaires (à droite)
• Très facile a comprendre pour les utilisateurs
• On peut faire aussi des diagrammes de séquence entre objets
20
Différents flots
Objet A Objet B Objet C
message 1
message 2
Flèche pleine : messages synchrones, avec attente
Demi-flèche : messages asynchrones (environnement concurrent)
21
Différents flotsObjet A Objet B
Objet A Objet B
Objet
Récursion()
Objet
Message réflexif
22
Contraintes temporelles
{y-x<3s}x
y
23
Structures de contrôle
Objet A Objet B
while Xloop
end loop
Objet A Objet B
*[X] MessageMessage
Objet A Objet B
if
elseend if
Message
Objet C
Message
Objet A Objet B
[X]
[Y]
24
Diagramme d’activités
• Représente les étapes d’une procédure• Graphe : les sommets sont les activités, les arcs
sont les transitions• Des activités peuvent se dérouler en parallèle.
Afficher (i)/i=0
[i<10]/i++
[sinon]
25
Diagramme d’activité - travéesEnseignant Etudiant Jury
EcouterEnseigner
Composer
Apprendre
Contrôler
Evaluer
26
Diagramme d’états
• Représente les transformations des états d’un système ou d’un objet
• la classe Personne a un attribut Emploi qui vaut En Activité, Au chômage ou A la retraite.
En activité
Au chômage
A la retraitePerte emploi Embauche
Quand(Age>60)
Quand(Age>60)
27
Diagrammes de collaboration• Diagrammes d’interaction entre objets• Ensemble de rôles dans un contexte particulier• Liens entre les objets (complète le diagramme d’objets)
• Représentation d’envois de messages• Dimension spatiale plus que temporelle
– permet de fixer une partie du diagramme de classes,correspondant à la collaboration étudiée
28
Exemple/Locataire:Personne
:Coût
/Maison:Logement
:Lieu
/Propriétaire:Personne
*1
1
1
1
1
* 1
Loueur/Propriétaire:Personne
:Coût/Maison:
Logement
1:revenu location (pour les maisons)
1.1*[i=1..n]:loyer()
1.1.i:valeur()
:Conseiller
29
Notions complémentaires
appel procédure
asynchrone
1.2.1
1.2.2
1.2.a
1.2.b
consécutifs parallèles
[condition] *[itération] retour:=opération
1.2,2.4/5: op
30
Paquetages
• Partitionnement des éléments en ensembles– Couplage « fort »
• 4 Stéréotypes– Façade : vue simplifié d’un ensemble de paquetages– Framework– Souche (partie publique)– Racine (le + haut niveau)
31
Paquetages : notation
Nom paquet
32
Notions sur les paquetages• Espace de nommage
– ::
– unicité des noms
• Dépendances– « importe » import complet
• permet de redéfinir les visibilités (transitivité)
– « accède » possibilité de référencement
– Précaution• éviter les graphes cycliques
• Généralisation
33
Diagrammes de composants
Nom Stéréotypes :•« document »•« exécutable »•« fichier »•« bibliothèque »•« table »
34
Diagrammes de déploiement
Nœud Nœud Nœud« support »
Nœud 1 Nœud 2« RS232 »