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
 Avant la réalisationd’un logiciel,Il faut
 Comprendre, clarifier et structurer les attentes et les besoins du client.
 Le diagrammedescas d'utilisation(Use Case Diagram)constitue la première
étape de l’analyse UML en :
- Modélisant les besoins des utilisateurs.
- Identifiantles grandes fonctionnalitéset les limites du système.
- Représentantles interactionsentre le système et ses utilisateurs.
 Génie Logiciel
Exemple
Introduction
4
 Génie Logiciel
Remarques
Diagramme de cas d’utilisation
 Attention :
 Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument
pas une vision informatique. Il ne nécessite aucun connaissanceinformatique.
 Le diagramme des cas d’utilisation n’estpas un inventaireexhaustif de toutes les
fonctions du système.
 Il ne liste que des fonctions généralesessentielles et principalessans rentrer
dans les détails.
 Génie Logiciel 5
Concepts: Acteur
Diagramme de cas d’utilisation
La modélisation des besoins des utilisateurconsiste
1. à définir les limites du système (c.à.d. ce qui est inclusou 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 6
Concepts :Acteur
Diagramme de cas d’utilisation
 Représentation :
Les acteursse 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 externeau système. Cela peut être :
- Une personne.
- Du matériel (capteurs, moteurs, relais…).
- Un autre système.
 Génie Logiciel 7
Concepts: Acteur
Diagramme de cas d’utilisation
 Exemple :
 Identifier les acteurs du système DAB (énoncé de l’exercice 3 du TD).
 Les limites du système sont clairementdéfinies,il s’agitdes limitesphysiques
du DAB. Donc les acteurs sont :
 Génie Logiciel 8
 NB : Un acteur correspond à un rôle, pas à une personne physique
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
Le cas d’utilisationreprésente une fonctionnalité du système (visible de
l’extérieur du système).
 Représentation : Un cas d’utilisationse 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.
 NB : Les différents cas d’utilisationpeuvent être représentés à
l’intérieur d’un même rectanglereprésentant les limites du système.
 Génie Logiciel 9
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
 Exemple : Identifier les cas d’utilisation du système DAB.
• NB :Il ne faut pas faire apparaîtreles détails des cas d'utilisation, mais il faut
rester au niveau des grandes fonctions du système.
 Génie Logiciel 10
Concepts : Relationd’association
Diagramme de cas d’utilisation
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 11
Concepts : Cas d’utilisation
Diagramme de cas d’utilisation
 Exercice : Précisez les différents interactions entre les acteur et leurs cas
d’utilisation
 Génie Logiciel 12
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 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 13
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 Relation d’inclusion:
La relation d’inclusionsert à enrichir un cas d’utilisationpar un autre cas
d’utilisation(c’est une sous fonction).
• Formalisme:
 Génie Logiciel 14
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
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 15
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 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 16
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 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 17
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 Relation d’extension :
Comme la relation d’inclusion, la relation d’extensionenrichit un cas d’utilisati
par un autre cas d’utilisationde 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 18
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 Exemple: suite exemple de DAB
 un utilisateur du DAB peut imprimer un ticket s’il le veut
 Génie Logiciel 19
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 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 20
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
 Relationd’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 21
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
• Relation de généralisationou de spécialisation :
• il est égalementpossible de spécialiser un casd’utilisationen un autrecas
d’utilisation.
• Nous obtenons alors un sous-cas d’utilisation.
• Le sous-casd’utilisation hérite du comportementdu 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 22
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
• Relation de généralisationou 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 23
Les relations entre cas d’utilisation
Diagramme de cas d’utilisation
• Relation de généralisationou 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 24
Les relations entre acteurs
Diagramme de cas d’utilisation
• Relation de généralisation:
• La seule relation possible entre 2 acteurs est la généralisation (mêmecomportementet
même représentationgraphiqueque la relationde généralisationentre2 cas
d’utilisation).
• Exemple DAB : l’acteur Client banque est une spécialisation de l’acteur Porteurde carte.
• Formalisme :
 Génie Logiciel 25
Les relations entre acteurs
Diagramme de cas d’utilisation
• Relation de généralisation: Exemple DAB :
• l’acteur Client banque est une spécialisation de l’acteur Porteur de carte.
 Génie Logiciel 26
Acteur principaleet acteurs secondaires
Diagramme de cas d’utilisation
• Un acteur est principalpour le cas d’utilisation auquel il est lié si ce cas
d’utilisation lui rendun service.
• Les autres acteurs liés à ce cas d’utilisation sont dit secondaires.
• Normalement, Il ne peut y avoir qu’un seul acteur principalpar cas d’utilisation.
• En général,l’acteur principalsollicite le cas d’utilisation alors que l’acteur
secondaireest sollicité parle cas d’utilisation.
• Un acteur peut être principalpour un cas d’utilisation et secondaire pour un
autre cas d’utilisation.
• Si nous désirons indiquer si l’acteur est principalou secondairepour 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 27
Multiplicité
Diagramme de cas d’utilisation
• Lorsqu’un acteur peut interagirplusieurs fois avec un cas d’utilisation,il est
possible d’ajouter une multiplicité sur l’associationdu côté du cas d’utilisation.
• Le symbole * signifieplusieurs.
• Exactement n s’écrittout simplement n,
• n..m signifieentre n et m, etc.
• Préciser une multiplicité sur une relation n’implique pas nécessairementque les
cas sont utilisés en même temps.
 Génie Logiciel 28
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
• 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 : Exigencenon fonctionnelle.
 Génie Logiciel 29
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
 Partie1 : 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 ‘Retirerde l’argent’du DAB
 Génie Logiciel 30
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
 Partie2 : Descriptiondes 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 31
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
• Partie 2 :Exemple
 Génie Logiciel 32
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
• Partie2 :suite de l’exemple
 Génie Logiciel 33
Description textuelle des cas d’utilisation
Diagramme de cas d’utilisation
• Partie3 : 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
 Génie Logiciel 34

Contenu connexe

Similaire à 03GL-diagramme de cas dutilisation.pptx

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

Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
Uml : Diagrammes de Cas dutilisation -- Modele preliminaire -- 23
 
Expo diagramme cas d'utilisation
Expo diagramme cas d'utilisationExpo diagramme cas d'utilisation
Expo diagramme cas d'utilisation
 
Initiation à UML: Partie 2
Initiation à UML: Partie 2Initiation à UML: Partie 2
Initiation à UML: Partie 2
 
CM CU-cockburn
CM CU-cockburnCM CU-cockburn
CM CU-cockburn
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
Manuel uml-poweramc
Manuel uml-poweramcManuel uml-poweramc
Manuel uml-poweramc
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
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
 
Introduction à NetLogo
Introduction à NetLogoIntroduction à NetLogo
Introduction à NetLogo
 
2.diagram ucum lpdf_2
2.diagram ucum lpdf_22.diagram ucum lpdf_2
2.diagram ucum lpdf_2
 
Diagramme des cas d’utilisation.pdf
 Diagramme des cas d’utilisation.pdf Diagramme des cas d’utilisation.pdf
Diagramme des cas d’utilisation.pdf
 
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
 
Exposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptxExposé UC Ledu.pptx nouv.pptx
Exposé UC Ledu.pptx nouv.pptx
 
UML.pptx
UML.pptxUML.pptx
UML.pptx
 
SysML (Valtech Days 2008)
SysML (Valtech Days 2008)SysML (Valtech Days 2008)
SysML (Valtech Days 2008)
 
Introduction à Sysml
Introduction à SysmlIntroduction à Sysml
Introduction à Sysml
 
Les limites-de-l uml (1)
Les limites-de-l uml (1)Les limites-de-l uml (1)
Les limites-de-l uml (1)
 

Dernier

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
 
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
 
Copilot your everyday AI companion- OFFICE 365-
Copilot your everyday AI companion- OFFICE 365-Copilot your everyday AI companion- OFFICE 365-
Copilot your everyday AI companion- OFFICE 365-Majida Antonios, M.Ed.
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
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
 
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...Unidad de Espiritualidad Eudista
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneTxaruka
 

Dernier (17)

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...
 
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
 
Copilot your everyday AI companion- OFFICE 365-
Copilot your everyday AI companion- OFFICE 365-Copilot your everyday AI companion- OFFICE 365-
Copilot your everyday AI companion- OFFICE 365-
 
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
 
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
 
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
 
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
 
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
 
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
 
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)
 
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
 
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
 
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
 
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
 
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...
L'Unité de Spiritualité Eudiste se joint à toute l'Église Universelle et en p...
 
Chana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienneChana Orloff.pptx Sculptrice franco-ukranienne
Chana Orloff.pptx Sculptrice franco-ukranienne
 

03GL-diagramme de cas dutilisation.pptx

  • 3. Introduction 3  Avant la réalisationd’un logiciel,Il faut  Comprendre, clarifier et structurer les attentes et les besoins du client.  Le diagrammedescas d'utilisation(Use Case Diagram)constitue la première étape de l’analyse UML en : - Modélisant les besoins des utilisateurs. - Identifiantles grandes fonctionnalitéset les limites du système. - Représentantles interactionsentre le système et ses utilisateurs.  Génie Logiciel
  • 5. Remarques Diagramme de cas d’utilisation  Attention :  Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une vision informatique. Il ne nécessite aucun connaissanceinformatique.  Le diagramme des cas d’utilisation n’estpas un inventaireexhaustif de toutes les fonctions du système.  Il ne liste que des fonctions généralesessentielles et principalessans rentrer dans les détails.  Génie Logiciel 5
  • 6. Concepts: Acteur Diagramme de cas d’utilisation La modélisation des besoins des utilisateurconsiste 1. à définir les limites du système (c.à.d. ce qui est inclusou 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 6
  • 7. Concepts :Acteur Diagramme de cas d’utilisation  Représentation : Les acteursse 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 externeau système. Cela peut être : - Une personne. - Du matériel (capteurs, moteurs, relais…). - Un autre système.  Génie Logiciel 7
  • 8. Concepts: Acteur Diagramme de cas d’utilisation  Exemple :  Identifier les acteurs du système DAB (énoncé de l’exercice 3 du TD).  Les limites du système sont clairementdéfinies,il s’agitdes limitesphysiques du DAB. Donc les acteurs sont :  Génie Logiciel 8  NB : Un acteur correspond à un rôle, pas à une personne physique
  • 9. Concepts : Cas d’utilisation Diagramme de cas d’utilisation Le cas d’utilisationreprésente une fonctionnalité du système (visible de l’extérieur du système).  Représentation : Un cas d’utilisationse 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.  NB : Les différents cas d’utilisationpeuvent être représentés à l’intérieur d’un même rectanglereprésentant les limites du système.  Génie Logiciel 9
  • 10. Concepts : Cas d’utilisation Diagramme de cas d’utilisation  Exemple : Identifier les cas d’utilisation du système DAB. • NB :Il ne faut pas faire apparaîtreles détails des cas d'utilisation, mais il faut rester au niveau des grandes fonctions du système.  Génie Logiciel 10
  • 11. Concepts : Relationd’association Diagramme de cas d’utilisation 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 11
  • 12. Concepts : Cas d’utilisation Diagramme de cas d’utilisation  Exercice : Précisez les différents interactions entre les acteur et leurs cas d’utilisation  Génie Logiciel 12
  • 13. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  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 13
  • 14. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  Relation d’inclusion: La relation d’inclusionsert à enrichir un cas d’utilisationpar un autre cas d’utilisation(c’est une sous fonction). • Formalisme:  Génie Logiciel 14
  • 15. Les relations entre cas d’utilisation Diagramme de cas d’utilisation 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 15
  • 16. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  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 16
  • 17. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  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 17
  • 18. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  Relation d’extension : Comme la relation d’inclusion, la relation d’extensionenrichit un cas d’utilisati par un autre cas d’utilisationde 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 18
  • 19. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  Exemple: suite exemple de DAB  un utilisateur du DAB peut imprimer un ticket s’il le veut  Génie Logiciel 19
  • 20. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  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 20
  • 21. Les relations entre cas d’utilisation Diagramme de cas d’utilisation  Relationd’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 21
  • 22. Les relations entre cas d’utilisation Diagramme de cas d’utilisation • Relation de généralisationou de spécialisation : • il est égalementpossible de spécialiser un casd’utilisationen un autrecas d’utilisation. • Nous obtenons alors un sous-cas d’utilisation. • Le sous-casd’utilisation hérite du comportementdu 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 22
  • 23. Les relations entre cas d’utilisation Diagramme de cas d’utilisation • Relation de généralisationou 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 23
  • 24. Les relations entre cas d’utilisation Diagramme de cas d’utilisation • Relation de généralisationou 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 24
  • 25. Les relations entre acteurs Diagramme de cas d’utilisation • Relation de généralisation: • La seule relation possible entre 2 acteurs est la généralisation (mêmecomportementet même représentationgraphiqueque la relationde généralisationentre2 cas d’utilisation). • Exemple DAB : l’acteur Client banque est une spécialisation de l’acteur Porteurde carte. • Formalisme :  Génie Logiciel 25
  • 26. Les relations entre acteurs Diagramme de cas d’utilisation • Relation de généralisation: Exemple DAB : • l’acteur Client banque est une spécialisation de l’acteur Porteur de carte.  Génie Logiciel 26
  • 27. Acteur principaleet acteurs secondaires Diagramme de cas d’utilisation • Un acteur est principalpour le cas d’utilisation auquel il est lié si ce cas d’utilisation lui rendun service. • Les autres acteurs liés à ce cas d’utilisation sont dit secondaires. • Normalement, Il ne peut y avoir qu’un seul acteur principalpar cas d’utilisation. • En général,l’acteur principalsollicite le cas d’utilisation alors que l’acteur secondaireest sollicité parle cas d’utilisation. • Un acteur peut être principalpour un cas d’utilisation et secondaire pour un autre cas d’utilisation. • Si nous désirons indiquer si l’acteur est principalou secondairepour 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 27
  • 28. Multiplicité Diagramme de cas d’utilisation • Lorsqu’un acteur peut interagirplusieurs fois avec un cas d’utilisation,il est possible d’ajouter une multiplicité sur l’associationdu côté du cas d’utilisation. • Le symbole * signifieplusieurs. • Exactement n s’écrittout simplement n, • n..m signifieentre n et m, etc. • Préciser une multiplicité sur une relation n’implique pas nécessairementque les cas sont utilisés en même temps.  Génie Logiciel 28
  • 29. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation • 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 : Exigencenon fonctionnelle.  Génie Logiciel 29
  • 30. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation  Partie1 : 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 ‘Retirerde l’argent’du DAB  Génie Logiciel 30
  • 31. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation  Partie2 : Descriptiondes 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 31
  • 32. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation • Partie 2 :Exemple  Génie Logiciel 32
  • 33. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation • Partie2 :suite de l’exemple  Génie Logiciel 33
  • 34. Description textuelle des cas d’utilisation Diagramme de cas d’utilisation • Partie3 : 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  Génie Logiciel 34

Notes de l'éditeur

  1. ddddddd