SlideShare une entreprise Scribd logo
1  sur  34
Télécharger pour lire hors ligne
 Génie Logiciel
Vues UML
UML
1
DCU
Diagramme de cas
d’utilisation
-Use case diagram-
2
Introduction
3
 Génie Logiciel
 Avant la réalisation d’un logiciel, Il faut
 Comprendre, clarifier et structurer les attentes et les besoins du client.
 Le diagramme des cas d'utilisation (Use Case Diagram) constitue la
première étape de l’analyse UML en :
- Modélisant les besoins des utilisateurs.
- Identifiant les grandes fonctionnalités et les limites du système.
- Représentant les interactions entre le système et ses utilisateurs.
Exemple
Introduction
4
 Génie Logiciel
 Génie Logiciel
Remarques
Diagramme de cas d’utilisation
5
 Attention :
 Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument
pas une vision informatique. Il ne nécessite aucun connaissance informatique.
 Le diagramme des cas d’utilisation n’est pas un inventaire exhaustif de toutes
les fonctions du système.
 Il ne liste que des fonctions générales essentielles et principales sans
rentrer dans les détails.
 Génie Logiciel
Concepts : Acteur
Diagramme de cas d’utilisation
6
La modélisation des besoins des utilisateur consiste
1. à définir les limites du système (c.à.d. ce qui est inclus ou pas dans le
système),
2. Identifier les différentes entités intervenants sur le système. Ces
entités sont appelés acteurs.
 Génie Logiciel
Concepts : Acteur
Diagramme de cas d’utilisation
7
 Représentation :
Les acteurs se représentent sous la forme d’un petit personnage
(stick man) ou sous la forme d’une case rectangulaire (appelé classeur)
avec le mot clé « actor ».
• Un acteur est un utilisateur externe au système. Cela peut être :
- Une personne.
- Du matériel (capteurs, moteurs, relais…).
- Un autre système.
 Génie Logiciel
Concepts : Acteur
Diagramme de cas d’utilisation
8
 Exemple :
 Identifier les acteurs du système DAB (énoncé de l’exercice 3 du TD).
 Les limites du système sont clairement définies, il s’agit des limites
physiques du DAB. Donc les acteurs sont :
 NB : Un acteur correspond à un rôle, pas à une personne physique
 Génie Logiciel
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
9
 Représentation : Un cas d’utilisation se représente par une ellipse
contenant le nom du cas d’utilisation (phrase commençant par un verbe à
l’infinitif) et optionnellement un stéréotype au dessus du nom.
Le cas d’utilisation représente une fonctionnalité du système (visible de
l’extérieur du système).
 NB : Les différents cas d’utilisation peuvent être représentés à
l’intérieur d’un même rectangle représentant les limites du système.
 Génie Logiciel
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
10
 Exemple : Identifier les cas d’utilisation du système DAB.
• NB : Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut
rester au niveau des grandes fonctions du système.
 Génie Logiciel
Concepts : Relation d’association
Diagramme de cas d’utilisation
11
A chaque acteur est associé un ou plusieurs cas d’utilisations,
 Représentation : Elle est représentée par un trait reliant l’acteur et le cas
d’utilisation.
 Génie Logiciel
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
12
 Exercice : Précisez les différents interactions entre les acteur et leurs
cas d’utilisation
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
13
 Le DCU permet de compléter le diagramme par d’autres cas d’utilisation
(non lié à des acteurs mais à d’autre cas d’utilisation) qui préciseront le
diagramme.
 Deux type de relations entre cas d’utilisation :
 Relation d’inclusion
 Relation d’extension
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
14
 Relation d’inclusion :
La relation d’inclusion sert à enrichir un cas d’utilisation par un autre cas
d’utilisation (c’est une sous fonction).
• Formalisme :
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
15
Relation d’inclusion :
 La relation d’inclusion est impérative et donc systématique.
 Permet de partager une fonctionnalité commune entre plusieurs cas d’utilisation
 Décomposer un cas d’utilisation complexe en décrivant ses sous fonctions.
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
16
 Exemple : suite exemple de DAB
Prendre en compte le faite de s’authentifier systématique à chaque Retrait de
l’argent, Consultation des soldes ou Virement)..
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
17
 Exemple : suite exemple de DAB
Prendre en compte le faite de s’authentifier systématique à chaque Retrait de
l’argent, Consultation des soldes ou Virement)..
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
18
 Relation d’extension :
Comme la relation d’inclusion, la relation d’extension enrichit un cas
d’utilisation par un autre cas d’utilisation de sous fonction mais celui-ci est
optionnel.
• Formalisme :
• Exemple :
 NB : Une note peut être ajoutée à la représentation du cas d’utilisation pour
expliciter la condition.
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
19
 Exemple : suite exemple de DAB
 un utilisateur du DAB peut imprimer un ticket s’il le veut
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
20
 Relation d’extension : Point d’extension
 L’extension peut intervenir à un point précis du cas étendu.
 Ce point s’appelle le point d’extension.
 Il porte un nom, qui figure dans un compartiment du cas étendu sous la
rubrique point d’extension, et est éventuellement associé à une contrainte
indiquant le moment où l’extension intervient.
 Une extension est souvent soumise à condition.
Graphiquement, la condition est exprimée sous la forme d’une note.
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
21
 Relation d’extension : Point d’extension
 Exemple : une vérification du solde du compte éventuelle n’intervient
que si la demande de retrait dépasse 20 euros.
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
22
• Relation de généralisation ou de spécialisation :
• il est également possible de spécialiser un cas d’utilisation en un autre cas
d’utilisation.
• Nous obtenons alors un sous-cas d’utilisation.
• Le sous-cas d’utilisation hérite du comportement du sur-cas d’utilisation. Le
sous-cas d’utilisation hérite aussi de toutes les associations du sur-cas (relations
d’association avec les acteurs, relations d’inclusions, et relations d’extensions).
• Formalisme : La relation de généralisation est représentée par une flèche avec
une extrémité triangulaire.
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
23
• Relation de généralisation ou de spécialisation :
• NB : Quelquefois, le sur-cas d’utilisation est abstrait (c’est-à-dire qu’il ne peut pas être
instancié). Il correspond à un comportement partiel et sert uniquement de base pour les
sous-cas d’utilisation qui en hériteront.
• Le nom d’un cas d’utilisation abstrait est écrit en italique (ou accompagné du stéréotype
« abstract »).
 Génie Logiciel
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
24
• Relation de généralisation ou de spécialisation :
• Exemple : il est à préciser que le DAB sera situé dans une zone internationale et devra
donc pouvoir fournir la somme d’argent en Dollars ou en Euros.
 Génie Logiciel
Les relations entre acteurs
Diagramme de cas d’utilisation
25
• Relation de généralisation :
• La seule relation possible entre 2 acteurs est la généralisation (même comportement et
même représentation graphique que la relation de généralisation entre 2 cas
d’utilisation).
• Exemple DAB : l’acteur Client banque est une spécialisation de l’acteur Porteur de carte.
• Formalisme :
 Génie Logiciel
Les relations entre acteurs
Diagramme de cas d’utilisation
26
• Relation de généralisation : Exemple DAB :
• l’acteur Client banque est une spécialisation de l’acteur Porteur de
carte.
 Génie Logiciel
Acteur principale et acteurs secondaires
Diagramme de cas d’utilisation
27
• Un acteur est principal pour le cas d’utilisation auquel il est lié si ce cas
d’utilisation lui rend un service.
• Les autres acteurs liés à ce cas d’utilisation sont dit secondaires.
• Normalement, Il ne peut y avoir qu’un seul acteur principal par cas
d’utilisation.
• En général, l’acteur principal sollicite le cas d’utilisation alors que l’acteur
secondaire est sollicité par le cas d’utilisation.
• Un acteur peut être principal pour un cas d’utilisation et secondaire pour un
autre cas d’utilisation.
• Si nous désirons indiquer si l’acteur est principal ou secondaire pour un cas
d’utilisation, nous pouvons ajouter les stéréotypes « primary » ou « secondary
» sur la relation d’association entre l’acteur et le cas d’utilisation.
 Génie Logiciel
Multiplicité
Diagramme de cas d’utilisation
28
• Lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est
possible d’ajouter une multiplicité sur l’association du côté du cas d’utilisation.
• Le symbole * signifie plusieurs.
• Exactement n s’écrit tout simplement n,
• n..m signifie entre n et m, etc.
• Préciser une multiplicité sur une relation n’implique pas nécessairement que
les cas sont utilisés en même temps.
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
29
• Il est recommandé de rédiger une description textuelle de chaque cas afin de
les détailler.
• Mais ce n’est pas obligatoire
• L’utilisation Une description textuelle classique se compose de trois parties :
• Partie 1 : Identification.
• Partie 2 : Description des scénarios.
• Partie 3 : Exigence non fonctionnelle.
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
30
 Partie 1 : Identification.
- Titre : Nom du cas d’utilisation
- Résumé : description du cas d’utilisation.
- Acteurs : descriptions des acteurs principaux et secondaires.
- Dates : Date de création et date de mise à jour.
- Responsable : Noms du ou des responsables.
- Version : Numéro de la version.
Exemple : Description du cas d‘utilisation ‘Retirer de l’argent’ du DAB
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
31
 Partie 2 : Description des scénarios.
 Les pré-conditions : État du système avant que le cas d’utilisation puisse être
déclenché.
 Les Scénarios (un scénario est une instance d’un cas d’utilisation dans lequel tous
les paramètres ont été fixés). Il y a plusieurs types de scénarios :
 Le scénario nominal qui correspond à un déroulement normale d’un cas
d’utilisation.
 Les scénarios alternatifs qui sont des variantes du scénario normale.
 Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une erreur.
 Les post-conditions : Elles décrivent l’état du système après l’issue de chaque scénario.
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
32
• Partie 2 : Exemple
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
33
• Partie 2 : suite de l’exemple
 Génie Logiciel
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
34
• Partie 3 : Exigence non fonctionnelle.
La partie 3 peut être omise, mais si elle est présente, elle permet de préciser des
spécifications non fonctionnelles (fréquence, fiabilité, type d’interface homme-
.machine...).
• Exemple

Contenu connexe

Similaire à 03GL-diagramme de cas dutilisation (1).ppsx

UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriMansouri Khalifa
 
Initiation à UML: Partie 2
Initiation à UML: Partie 2Initiation à UML: Partie 2
Initiation à UML: Partie 2DIALLO Boubacar
 
Expo diagramme cas d'utilisation
Expo diagramme cas d'utilisationExpo diagramme cas d'utilisation
Expo diagramme cas d'utilisationaminooovich
 
Marzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcMarzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcabderrahim marzouk
 
Legal Risks In Erp Projects Paris 2007
Legal Risks In Erp Projects Paris 2007Legal Risks In Erp Projects Paris 2007
Legal Risks In Erp Projects Paris 2007Andre Meillassoux
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
DefinitiondesbesoinsumlVINOT Bernard
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetAmine Chkr
 
Introduction à NetLogo
Introduction à NetLogoIntroduction à NetLogo
Introduction à NetLogoAlvaro Gil
 
Cours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfCours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfbahajzouhair
 
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...IHM'10
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011agnes_crepet
 
Diagramme des cas d’utilisation.pdf
 Diagramme des cas d’utilisation.pdf Diagramme des cas d’utilisation.pdf
Diagramme des cas d’utilisation.pdfYasushiTsubakik
 
Les limites-de-l uml (1)
Les limites-de-l uml (1)Les limites-de-l uml (1)
Les limites-de-l uml (1)Samah Dekhil
 
Exposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptxExposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptxMoussaESSANHAJI1
 

Similaire à 03GL-diagramme de cas dutilisation (1).ppsx (20)

UML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouriUML Part2- diagramme des uses cases_mansouri
UML Part2- diagramme des uses cases_mansouri
 
Initiation à UML: Partie 2
Initiation à UML: Partie 2Initiation à UML: Partie 2
Initiation à UML: Partie 2
 
Expo diagramme cas d'utilisation
Expo diagramme cas d'utilisationExpo diagramme cas d'utilisation
Expo diagramme cas d'utilisation
 
CM CU-cockburn
CM CU-cockburnCM CU-cockburn
CM CU-cockburn
 
Marzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvcMarzouk architecture encouches-jee-mvc
Marzouk architecture encouches-jee-mvc
 
Legal Risks In Erp Projects Paris 2007
Legal Risks In Erp Projects Paris 2007Legal Risks In Erp Projects Paris 2007
Legal Risks In Erp Projects Paris 2007
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
U M L Analyse Et Conception Objet
U M L Analyse Et Conception ObjetU M L Analyse Et Conception Objet
U M L Analyse Et Conception Objet
 
Uml
UmlUml
Uml
 
UML3
UML3UML3
UML3
 
Introduction à NetLogo
Introduction à NetLogoIntroduction à NetLogo
Introduction à NetLogo
 
Cours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdfCours1IntroUseCaseDiagram.pdf
Cours1IntroUseCaseDiagram.pdf
 
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...
Méthode d’implémentation efficace des modèles PAC et PAC-Amodeus à l’aide de ...
 
2.diagram ucum lpdf_2
2.diagram ucum lpdf_22.diagram ucum lpdf_2
2.diagram ucum lpdf_2
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
Diagramme des cas d’utilisation.pdf
 Diagramme des cas d’utilisation.pdf Diagramme des cas d’utilisation.pdf
Diagramme des cas d’utilisation.pdf
 
Manuel uml-poweramc
Manuel uml-poweramcManuel uml-poweramc
Manuel uml-poweramc
 
Les limites-de-l uml (1)
Les limites-de-l uml (1)Les limites-de-l uml (1)
Les limites-de-l uml (1)
 
UML v2
UML v2UML v2
UML v2
 
Exposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptxExposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptx
 

Dernier

La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfbdp12
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursStagiaireLearningmat
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Gabriel Gay-Para
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfSylvianeBachy
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfAtelier Canopé 37 - Tours
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Atelier Canopé 37 - Tours
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxJCAC
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAmar LAKEL, PhD
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 
Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilfrizzole
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film françaisTxaruka
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxMartin M Flynn
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfAtelier Canopé 37 - Tours
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film françaisTxaruka
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24BenotGeorges3
 

Dernier (16)

La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdfLa Base unique départementale - Quel bilan, au bout de 5 ans .pdf
La Base unique départementale - Quel bilan, au bout de 5 ans .pdf
 
Apprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceursApprendre avec des top et nano influenceurs
Apprendre avec des top et nano influenceurs
 
Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)Faut-il avoir peur de la technique ? (G. Gay-Para)
Faut-il avoir peur de la technique ? (G. Gay-Para)
 
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdfVulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
Vulnérabilité numérique d’usage : un enjeu pour l’aide à la réussitepdf
 
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdfBibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
Bibdoc 2024 - Sobriete numerique en bibliotheque et centre de documentation.pdf
 
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
Bibdoc 2024 - L’Éducation aux Médias et à l’Information face à l’intelligence...
 
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptxPrésentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
Présentation - Initiatives - CECOSDA - OIF - Fact Checking.pptx
 
Aux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècleAux origines de la sociologie : du XIXème au début XX ème siècle
Aux origines de la sociologie : du XIXème au début XX ème siècle
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 
Calendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avrilCalendrier de la semaine du 8 au 12 avril
Calendrier de la semaine du 8 au 12 avril
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx      Film   françaisPas de vagues.  pptx      Film   français
Pas de vagues. pptx Film français
 
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptxDIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
DIGNITAS INFINITA - DIGNITÉ HUMAINE; déclaration du dicastère .pptx
 
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdfBibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
Bibdoc 2024 - Les intelligences artificielles en bibliotheque.pdf
 
Pas de vagues. pptx Film français
Pas de vagues.  pptx   Film     françaisPas de vagues.  pptx   Film     français
Pas de vagues. pptx Film français
 
Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024Bulletin des bibliotheques Burkina Faso mars 2024
Bulletin des bibliotheques Burkina Faso mars 2024
 
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
Newsletter SPW Agriculture en province du Luxembourg du 10-04-24
 

03GL-diagramme de cas dutilisation (1).ppsx

  • 3. Introduction 3  Génie Logiciel  Avant la réalisation d’un logiciel, Il faut  Comprendre, clarifier et structurer les attentes et les besoins du client.  Le diagramme des cas d'utilisation (Use Case Diagram) constitue la première étape de l’analyse UML en : - Modélisant les besoins des utilisateurs. - Identifiant les grandes fonctionnalités et les limites du système. - Représentant les interactions entre le système et ses utilisateurs.
  • 5.  Génie Logiciel Remarques Diagramme de cas d’utilisation 5  Attention :  Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une vision informatique. Il ne nécessite aucun connaissance informatique.  Le diagramme des cas d’utilisation n’est pas un inventaire exhaustif de toutes les fonctions du système.  Il ne liste que des fonctions générales essentielles et principales sans rentrer dans les détails.
  • 6.  Génie Logiciel Concepts : Acteur Diagramme de cas d’utilisation 6 La modélisation des besoins des utilisateur consiste 1. à définir les limites du système (c.à.d. ce qui est inclus ou pas dans le système), 2. Identifier les différentes entités intervenants sur le système. Ces entités sont appelés acteurs.
  • 7.  Génie Logiciel Concepts : Acteur Diagramme de cas d’utilisation 7  Représentation : Les acteurs se représentent sous la forme d’un petit personnage (stick man) ou sous la forme d’une case rectangulaire (appelé classeur) avec le mot clé « actor ». • Un acteur est un utilisateur externe au système. Cela peut être : - Une personne. - Du matériel (capteurs, moteurs, relais…). - Un autre système.
  • 8.  Génie Logiciel Concepts : Acteur Diagramme de cas d’utilisation 8  Exemple :  Identifier les acteurs du système DAB (énoncé de l’exercice 3 du TD).  Les limites du système sont clairement définies, il s’agit des limites physiques du DAB. Donc les acteurs sont :  NB : Un acteur correspond à un rôle, pas à une personne physique
  • 9.  Génie Logiciel Concepts : Cas d’utilisation Diagramme de cas d’utilisation 9  Représentation : Un cas d’utilisation se représente par une ellipse contenant le nom du cas d’utilisation (phrase commençant par un verbe à l’infinitif) et optionnellement un stéréotype au dessus du nom. Le cas d’utilisation représente une fonctionnalité du système (visible de l’extérieur du système).  NB : Les différents cas d’utilisation peuvent être représentés à l’intérieur d’un même rectangle représentant les limites du système.
  • 10.  Génie Logiciel Concepts : Cas d’utilisation Diagramme de cas d’utilisation 10  Exemple : Identifier les cas d’utilisation du système DAB. • NB : Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester au niveau des grandes fonctions du système.
  • 11.  Génie Logiciel Concepts : Relation d’association Diagramme de cas d’utilisation 11 A chaque acteur est associé un ou plusieurs cas d’utilisations,  Représentation : Elle est représentée par un trait reliant l’acteur et le cas d’utilisation.
  • 12.  Génie Logiciel Concepts : Cas d’utilisation Diagramme de cas d’utilisation 12  Exercice : Précisez les différents interactions entre les acteur et leurs cas d’utilisation
  • 13.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 13  Le DCU permet de compléter le diagramme par d’autres cas d’utilisation (non lié à des acteurs mais à d’autre cas d’utilisation) qui préciseront le diagramme.  Deux type de relations entre cas d’utilisation :  Relation d’inclusion  Relation d’extension
  • 14.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 14  Relation d’inclusion : La relation d’inclusion sert à enrichir un cas d’utilisation par un autre cas d’utilisation (c’est une sous fonction). • Formalisme :
  • 15.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 15 Relation d’inclusion :  La relation d’inclusion est impérative et donc systématique.  Permet de partager une fonctionnalité commune entre plusieurs cas d’utilisation  Décomposer un cas d’utilisation complexe en décrivant ses sous fonctions.
  • 16.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 16  Exemple : suite exemple de DAB Prendre en compte le faite de s’authentifier systématique à chaque Retrait de l’argent, Consultation des soldes ou Virement)..
  • 17.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 17  Exemple : suite exemple de DAB Prendre en compte le faite de s’authentifier systématique à chaque Retrait de l’argent, Consultation des soldes ou Virement)..
  • 18.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 18  Relation d’extension : Comme la relation d’inclusion, la relation d’extension enrichit un cas d’utilisation par un autre cas d’utilisation de sous fonction mais celui-ci est optionnel. • Formalisme : • Exemple :  NB : Une note peut être ajoutée à la représentation du cas d’utilisation pour expliciter la condition.
  • 19.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 19  Exemple : suite exemple de DAB  un utilisateur du DAB peut imprimer un ticket s’il le veut
  • 20.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 20  Relation d’extension : Point d’extension  L’extension peut intervenir à un point précis du cas étendu.  Ce point s’appelle le point d’extension.  Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient.  Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note.
  • 21.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 21  Relation d’extension : Point d’extension  Exemple : une vérification du solde du compte éventuelle n’intervient que si la demande de retrait dépasse 20 euros.
  • 22.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 22 • Relation de généralisation ou de spécialisation : • il est également possible de spécialiser un cas d’utilisation en un autre cas d’utilisation. • Nous obtenons alors un sous-cas d’utilisation. • Le sous-cas d’utilisation hérite du comportement du sur-cas d’utilisation. Le sous-cas d’utilisation hérite aussi de toutes les associations du sur-cas (relations d’association avec les acteurs, relations d’inclusions, et relations d’extensions). • Formalisme : La relation de généralisation est représentée par une flèche avec une extrémité triangulaire.
  • 23.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 23 • Relation de généralisation ou de spécialisation : • NB : Quelquefois, le sur-cas d’utilisation est abstrait (c’est-à-dire qu’il ne peut pas être instancié). Il correspond à un comportement partiel et sert uniquement de base pour les sous-cas d’utilisation qui en hériteront. • Le nom d’un cas d’utilisation abstrait est écrit en italique (ou accompagné du stéréotype « abstract »).
  • 24.  Génie Logiciel Les relations entre cas d’utilisation Diagramme de cas d’utilisation 24 • Relation de généralisation ou de spécialisation : • Exemple : il est à préciser que le DAB sera situé dans une zone internationale et devra donc pouvoir fournir la somme d’argent en Dollars ou en Euros.
  • 25.  Génie Logiciel Les relations entre acteurs Diagramme de cas d’utilisation 25 • Relation de généralisation : • La seule relation possible entre 2 acteurs est la généralisation (même comportement et même représentation graphique que la relation de généralisation entre 2 cas d’utilisation). • Exemple DAB : l’acteur Client banque est une spécialisation de l’acteur Porteur de carte. • Formalisme :
  • 26.  Génie Logiciel Les relations entre acteurs Diagramme de cas d’utilisation 26 • Relation de généralisation : Exemple DAB : • l’acteur Client banque est une spécialisation de l’acteur Porteur de carte.
  • 27.  Génie Logiciel Acteur principale et acteurs secondaires Diagramme de cas d’utilisation 27 • Un acteur est principal pour le cas d’utilisation auquel il est lié si ce cas d’utilisation lui rend un service. • Les autres acteurs liés à ce cas d’utilisation sont dit secondaires. • Normalement, Il ne peut y avoir qu’un seul acteur principal par cas d’utilisation. • En général, l’acteur principal sollicite le cas d’utilisation alors que l’acteur secondaire est sollicité par le cas d’utilisation. • Un acteur peut être principal pour un cas d’utilisation et secondaire pour un autre cas d’utilisation. • Si nous désirons indiquer si l’acteur est principal ou secondaire pour un cas d’utilisation, nous pouvons ajouter les stéréotypes « primary » ou « secondary » sur la relation d’association entre l’acteur et le cas d’utilisation.
  • 28.  Génie Logiciel Multiplicité Diagramme de cas d’utilisation 28 • Lorsqu’un acteur peut interagir plusieurs fois avec un cas d’utilisation, il est possible d’ajouter une multiplicité sur l’association du côté du cas d’utilisation. • Le symbole * signifie plusieurs. • Exactement n s’écrit tout simplement n, • n..m signifie entre n et m, etc. • Préciser une multiplicité sur une relation n’implique pas nécessairement que les cas sont utilisés en même temps.
  • 29.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 29 • Il est recommandé de rédiger une description textuelle de chaque cas afin de les détailler. • Mais ce n’est pas obligatoire • L’utilisation Une description textuelle classique se compose de trois parties : • Partie 1 : Identification. • Partie 2 : Description des scénarios. • Partie 3 : Exigence non fonctionnelle.
  • 30.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 30  Partie 1 : Identification. - Titre : Nom du cas d’utilisation - Résumé : description du cas d’utilisation. - Acteurs : descriptions des acteurs principaux et secondaires. - Dates : Date de création et date de mise à jour. - Responsable : Noms du ou des responsables. - Version : Numéro de la version. Exemple : Description du cas d‘utilisation ‘Retirer de l’argent’ du DAB
  • 31.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 31  Partie 2 : Description des scénarios.  Les pré-conditions : État du système avant que le cas d’utilisation puisse être déclenché.  Les Scénarios (un scénario est une instance d’un cas d’utilisation dans lequel tous les paramètres ont été fixés). Il y a plusieurs types de scénarios :  Le scénario nominal qui correspond à un déroulement normale d’un cas d’utilisation.  Les scénarios alternatifs qui sont des variantes du scénario normale.  Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une erreur.  Les post-conditions : Elles décrivent l’état du système après l’issue de chaque scénario.
  • 32.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 32 • Partie 2 : Exemple
  • 33.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 33 • Partie 2 : suite de l’exemple
  • 34.  Génie Logiciel Description textuelle des cas d’utilisation Diagramme de cas d’utilisation 34 • Partie 3 : Exigence non fonctionnelle. La partie 3 peut être omise, mais si elle est présente, elle permet de préciser des spécifications non fonctionnelles (fréquence, fiabilité, type d’interface homme- .machine...). • Exemple