SlideShare une entreprise Scribd logo

AnalyseEtConceptionChapire1.pptx

Ceci est une introduction au cours analyse et conception

1  sur  114
Télécharger pour lire hors ligne
Introduction
Processus de développement logiciel
2
Développement en cascade
3
Développement itératif
4
Développement itératif
5
Modèle de développement en cascade
6
Conception
Analyse des
besoins
Spécification
Codage
Test
Validation
Recette
Fin des années
90

Recommandé

CoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalCoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalAhmed Mekkaoui
 
Chp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionChp1 - Introduction aux méthodologies de Conception
Chp1 - Introduction aux méthodologies de ConceptionLilia Sfaxi
 
Présentation cours UML.pptx
Présentation  cours UML.pptxPrésentation  cours UML.pptx
Présentation cours UML.pptxPrinceLankoand
 
Support de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfSupport de cours Conception orientée objets - partie 1.pdf
Support de cours Conception orientée objets - partie 1.pdfYasushiTsubakik
 
Cours génie logiciel
Cours génie logicielCours génie logiciel
Cours génie logicielaraddaoui
 

Contenu connexe

Similaire à AnalyseEtConceptionChapire1.pptx

Similaire à AnalyseEtConceptionChapire1.pptx (20)

Methodo support
Methodo supportMethodo support
Methodo support
 
Prototype rapport
Prototype rapportPrototype rapport
Prototype rapport
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
SI_MCC_2020_21.pptx
SI_MCC_2020_21.pptxSI_MCC_2020_21.pptx
SI_MCC_2020_21.pptx
 
Introduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMAIntroduction à l'objet - Deuxième année ISIMA
Introduction à l'objet - Deuxième année ISIMA
 
Lmo02.ppt
Lmo02.pptLmo02.ppt
Lmo02.ppt
 
Uml 2
Uml 2Uml 2
Uml 2
 
Objets métier
Objets métierObjets métier
Objets métier
 
01-introduction (2).ppt
01-introduction (2).ppt01-introduction (2).ppt
01-introduction (2).ppt
 
01-introduction.ppt
01-introduction.ppt01-introduction.ppt
01-introduction.ppt
 
Definitiondesbesoinsuml
DefinitiondesbesoinsumlDefinitiondesbesoinsuml
Definitiondesbesoinsuml
 
presentationcoursbd.pdf
presentationcoursbd.pdfpresentationcoursbd.pdf
presentationcoursbd.pdf
 
Projet+com02.ppt
Projet+com02.pptProjet+com02.ppt
Projet+com02.ppt
 
Rattrapage uml
Rattrapage umlRattrapage uml
Rattrapage uml
 
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt1_Assurance_Qualit_et_Gnie_Logiciel.ppt
1_Assurance_Qualit_et_Gnie_Logiciel.ppt
 
CM uml-intro
CM uml-introCM uml-intro
CM uml-intro
 
Modelisation agile 03122011
Modelisation agile  03122011Modelisation agile  03122011
Modelisation agile 03122011
 
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptxProcessus_Unifie_et_Approche_Agile chapitre 1.pptx
Processus_Unifie_et_Approche_Agile chapitre 1.pptx
 
Introduction à Sysml
Introduction à SysmlIntroduction à Sysml
Introduction à Sysml
 
UML Part1-Introduction Mansouri
UML Part1-Introduction MansouriUML Part1-Introduction Mansouri
UML Part1-Introduction Mansouri
 

Dernier

Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiques
Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiquesJournée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiques
Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiquesInstitut de l'Elevage - Idele
 
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone Institut de l'Elevage - Idele
 
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...Institut de l'Elevage - Idele
 
Présentation de la station de Trévarez - 20 Février 2024
Présentation de la station de Trévarez - 20 Février 2024Présentation de la station de Trévarez - 20 Février 2024
Présentation de la station de Trévarez - 20 Février 2024Institut de l'Elevage - Idele
 
Rapport de fin d'étude en sur le dimensionnement solaire .pdf
Rapport de fin d'étude en sur le dimensionnement solaire .pdfRapport de fin d'étude en sur le dimensionnement solaire .pdf
Rapport de fin d'étude en sur le dimensionnement solaire .pdfZakaria156221
 
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génisses
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génissesJournée Technique Trévarez - 20 février 2024 - Atelier 3 génisses
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génissesInstitut de l'Elevage - Idele
 
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projets
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projetsJournée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projets
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projetsInstitut de l'Elevage - Idele
 

Dernier (7)

Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiques
Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiquesJournée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiques
Journée Technique Trévarez - 20 février 2024 - Atelier 4 leviers agronomiques
 
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone
Journée Technique Trévarez - 20 février 2024 - Atelier 1 système bas carbone
 
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...
Journée Technique Trévarez - 20 février 2024 - Atelier 2 Réduire l’âge au vêl...
 
Présentation de la station de Trévarez - 20 Février 2024
Présentation de la station de Trévarez - 20 Février 2024Présentation de la station de Trévarez - 20 Février 2024
Présentation de la station de Trévarez - 20 Février 2024
 
Rapport de fin d'étude en sur le dimensionnement solaire .pdf
Rapport de fin d'étude en sur le dimensionnement solaire .pdfRapport de fin d'étude en sur le dimensionnement solaire .pdf
Rapport de fin d'étude en sur le dimensionnement solaire .pdf
 
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génisses
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génissesJournée Technique Trévarez - 20 février 2024 - Atelier 3 génisses
Journée Technique Trévarez - 20 février 2024 - Atelier 3 génisses
 
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projets
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projetsJournée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projets
Journée Technique Trévarez - 20 février 2024 - Atelier 5 groupes-projets
 

AnalyseEtConceptionChapire1.pptx

  • 6. Modèle de développement en cascade 6 Conception Analyse des besoins Spécification Codage Test Validation Recette Fin des années 90
  • 8. Les activités du projet 8 Elles sont identiques quelque soit le modèle: Cascade, incrémental….
  • 10. Analyse et Conception 10  Analyse:  Processus consistant à se familiariser avec le domaine dans lequel le système sera intégré: Contexte, Utilisateurs, Contraintes, Coûts, performance, etc.  Conception:  Processus par lequel diverses techniques et principes sont appliqués dans le but de définir un système avec un niveau de détail suffisant pour permettre sa réalisation physique.
  • 12. Les activités du projet 12 Analyse du besoin Analyse du problème Etude préalable Implémentation Conception de la solution Gestion de projet
  • 13. Les activités du projet 13  ETUDE PRÉALABLE : ANALYSE DU CONTEXTE  ANALYSE ET SPÉCIFICATION DES BESOINS Fonctionnalités du système d’information  ANALYSE DU PROBLÈME OU MÉTIER OU SYSTÈME  Étude de la logique du système informatique (= Indépendamment des technologies)  Modélisation métier (vue logique)  CONCEPTION DE LA SOLUTION  Décisions technologiques  Affinement de la vue logique  Implémentation (Algorithmes, diagramme de composants)  Déploiement (Diagramme de déploiement) Analyse
  • 14. Etude préalable 14 On souhaite construire un système informatique pour répondre à un besoin  Qui a ce besoin?  Quel est ce besoin (à un niveau stratégique)?  Est-il justifié?  Activités principales du contexte étudié  Bilan gains-coûts estimés On modélise le périmètre du projet et son contexte : Analyse du contexte Analyse du besoin Analyse du problème Etude préalable Implémentation Conception de la solution
  • 15. Analyse des besoins 15 Exprimer les fonctionnalités demandées (selon la vision du client) + autres besoins non fonctionnels BNF (performance, sécurité, flexibilité…) Analyse du besoin Analyse du problème Etude préalable Implémentation Conception de la solution
  • 16. Analyse du problème ou métier ou système 16 Exprimer la structure (Entités; données) et la dynamique ( Processus de traitements) du système désiré Analyse du besoin Analyse du problème Etude préalable Implémentation Conception de la solution Indépendamment de la technologie
  • 17. 17 Paquetage Modéliser l’architecture technique ou physique (structurer le logiciel) La visibilité entre les paquetages est limitée. Conception de la solution Accès Réseau Accès Base BD IHM Métier Conception architecturale
  • 18. Conception de la solution 18 Que fait le système informatique?  Comportement des objets  Demandes de service Commande Article [s’il y a du stock] Réserver un article J’ai réservé réservation Contrôle stock Objet Conception détaillée
  • 19. Activités du projet: Modélisation 19 Analyse du besoin Analyse du problème Etude préalable Implémentation Conception de la solution - Toutes ces activités du projet ont une part de modélisation. - La modélisation est au centre de la démarche d’Analyse et de Conception. - La modélisation intervient tout au long du processus de développement, comme un outil de description et de communication entre les acteurs.
  • 20. • Un modèle est une représentation abstraite et non-ambiguë de la réalité dans un langage donné. • Une maquette, un plan, une photo, un organigramme sont des modèles. • Les modèles servent à : • Communiquer : vérifier que l’analyste a bien compris les besoins des utilisateurs grâce à des modèles du problème (modèles d’analyse), • Préparer la réalisation : grâce à des modèles de la solution (modèles de conception). La notion de modèle 20
  • 21. La modélisation 21 La modélisation d’une manière générale permet de faciliter la communication entre humains. Un modèle est une abstraction de la réalité.  Il doit faciliter la compréhension du phénomène ou système étudié: il réduit la complexité. Il doit permettre de simuler le phénomène ou système étudié: il reproduit ses comportements.
  • 22. La modélisation 22  La modélisation est finalement une activité de projection :  d’un sujet réel,  sur le plan d’un langage de modélisation,  selon un angle de considération résultant de l’utilisation attendue du modèle,  pour obtenir une vision abstraite, partielle et formalisée du sujet : le modèle.
  • 23. Historique: Approches de modélisation 23  Approche fonctionnelle (SADT)  1960 – fin 1970  l'important c'est les traitements  Séparation nette des données et traitements  Approche systémique (Merise)  (années 80)  Approche conceptuelle globale du système  Basée sur la recherche d’éléments pertinents du système: données, actions, évènements.  Emergence des méthodes objet  1980 – début 1990 : premières génération  Plus de 50 méthodes objets (dont OMT, OOSE)  L'important c'est l'objet  Objet = données + traitements  Langage de modélisation orienté objet: UML
  • 24. Approches de modélisation: Approche fonctionnelle 24  La fonction donne la forme du système
  • 25. Approches de modélisation: Approche objet 25  Les activités « orientées-objet » reposent, comme leur nom l’indique, sur le concept d’objet.  Dans ce contexte, l’objet constitue la brique élémentaire à partir de laquelle ces activités se construisent. Dans une activité « orientée-objet », tout est objet.  Un objet est donc une entité identifiée qui possède un comportement propre (des fonctions spécifiques) dépendant de son état interne et avec laquelle on peut interagir (échange de messages).
  • 26. Approches de modélisation: Approche objet 26  Chaque module représente un objet du domaine de l’application.  Les objets sont des entités autonomes qui collaborent afin de réaliser un projet global
  • 27. Approches de modélisation 27  La fonction est réalisée par des objets collaborants Lumière Porte Bouton Cabine 1: Aller au RDC 2: Clignoter 3: Ouvrir
  • 28. Approche objet 28  En fait, trois avantages prépondérants sont mis en général en avant lorsque l’on choisit une approche objet :  La modularité : Par construction, étant donné que l’on conçoit des classes.  La réutilisabilité  La maintenance de chaque classe est en soi plus simple à réaliser que celle d’un logiciel unique traitant toutes les données d’un système.  Il importe bien entendu dans l’approche objet de construire son système en veillant à minimiser le nombre de relations entre classes.
  • 29. UML 29  UML est une notation, pas une méthode  UML est un langage de modélisation objet  UML convient pour toutes les méthodes objet  UML est un standard UML est la notation pour documenter les modèles objets
  • 30. UML 30 Booch method OMT Unified Method 0.8 OOPSLA ´95 OOSE Other methods UML 0.9 Web - June ´96 public feedback Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 UML 1.0 UML 2.0 2005 UML 2.2 2009 Rumbaugh Jacobson Booch 2011 UML 2.4.1 UML 2.5.1 2018
  • 32. 32 3 Axes de modélisation d ’un système • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Statique (ce que le système EST) • diagramme de séquence • diagramme de communication • diagramme d’états- transitions • diagramme d’activités Fonctionnel (ce que le système FAI Dynamique (comment le système EVOLUE) • diagramme de cas d’utilisatio
  • 33. Définitions: Normes et Standards 33  Ces deux termes sont souvent utilisés l'un à la place de l'autre alors qu'ils relèvent d'instances fort différentes. Cette confusion est essentiellement liée au fait qu'en anglais, il n'existe qu'un seul mot, le terme "standard" pour désigner les deux concepts. Norme  Les normes sont des ensembles de règles approuvées par des instances officielles (un organisme, national ou international) en charge de la normalisation: ISO, AFNOR, INNORPI, etc.  Elles offrent une certaine garantie de stabilité et de pérennité.
  • 34. Normes et Standards 34 Standards  sont définis par des groupes qui n’ont pas de mandats officiels des gouvernements.  Ces groupes peuvent être :  Industriel ou commerciaux : par exemple PostScript ou PDF sont des standards de fait qui sont définis par la société Adobe,  Groupe d’experts :  le W3C (World Wide Web Consortium)  le consortium Unicode,  OMG (Object Management Group),  Un standard est aussi un procédé ou un service qui est largement répandu.
  • 35. 35  Créé en 1946  118 pays, siège à Genève  La Tunisie représentée par l’ INNORPI (Institut National de la Normalisation et de la Propriété Industrielle )  La France représentée par l ’AFNOR (Association Française de NORmalisation) l'organisation officielle en charge des normes en France.  Couvre tous les secteurs à l ’exception de l ’électricité et de l ’électronique  Plus de 10000 normes International Organization for Standardization (ISO)
  • 36. Chapitre 2: UML: Diagramme comportementaux: Diagramme de cas d’utilisation
  • 37. Les activités du projet 37  Etude préalable : Analyse du contexte  Analyse et spécification des besoins  Analyse du problème ou métier ou système  Conception de la solution
  • 38. UML 2 38 UML 2.5.1: 14 diagrammes
  • 39. Diagramme complémentaire: Diagramme de contexte 39  Le diagramme de contexte permet de positionner le système dans son environnement selon le point des communications.  Le diagramme de contexte n’est pas un diagramme UML.  Il précise les échanges d’informations qui sont réalisés entre le système et son environnement extérieur: son contexte.  Ses composants:  Le système étudié,  Les acteurs externes: entités externes au système étudié qui interagit avec le système,  Echange entre le système étudié et son environnement.
  • 40. 40
  • 41. 41
  • 43. Diagramme des cas d’utilisation 43  Permet de définir les limites du système et ses relations avec l’environnement.  Utilisé pour modéliser les exigences (besoins) du client.
  • 44. Concepts de base: Cas d’utilisation 44  Les cas d’utilisation constituent un moyen de recueillir et de décrire les besoins des acteurs du système.  Ils peuvent être aussi utilisés ensuite comme moyen d’organisation du développement du logiciel:  structuration et le déroulement de la conception, du codage et des tests logiciels.
  • 45. Objectifs: Cas d’utilisation - Capturer le comportement désiré du système, - Servir d’entente entre les différents intervenants (développeurs, utilisateurs et experts) sur les fonctions disponibles et sur la façon d’interagir avec le système. - Spécifier ce que le système fait (fonctions), mais pas comment il le fait. 45
  • 47. Cas d’utilisation 47  Un cas d’utilisation (use case) décrit:  Une fonctionnalité du système suivant le point de vue de l’utilisateur.  Les interactions entre les acteurs et le système,  Un comportement attendu du système du point de vue d’un ou de plusieurs acteurs,  Un service rendu par le système.
  • 48. Cas d’utilisation: Scénario 48  Un cas d’utilisation = Ensemble de « chemins d’exécution » possibles  Un scénario = Un chemin particulier d’exécution  Un scénario = Instance de cas d’utilisation  Exemple:  Cas d’utilisation : Acheter un objet sur internet  Mais il peut y avoir des scénarios tels que: • échec lors du paiement • Article non disponible
  • 49. Cas d’utilisation 49  La représentation d’un cas d’utilisation met en jeu trois concepts :  l’acteur,  le cas d’utilisation,  l’interaction entre l’acteur et le cas d’utilisation.
  • 50. Diagramme de cas d’utilisation 50  Un diagramme de cas d’utilisation :  décrit  les acteurs  les cas d’utilisation  le système  contient  des descriptions textuelles
  • 51. UML : Diagramme De Cas D’utilisation 51 Acteur CU1 CU2 CUn Acteur Association Système Cas d’utilisation
  • 52. Le système 52  Le système est un ensemble de cas d’utilisation  Le système ne comprend pas les acteurs. Nom du système Nom du système
  • 53. Cas d’utilisation 53  Use Case :  Ensemble de séquences d’actions réalisées par le système et qui produisent un résultat intéressant pour un acteur particulier.
  • 54. Acteurs 54  UML n’emploie pas le terme d’utilisateur mais d’acteur.  Le terme acteur ne désigne pas seulement des utilisateurs humains mais également les autres systèmes (machines, programmes, …)
  • 55. Acteurs 55  Un acteur est un rôle joué par une entité externe qui est en interaction avec le système (échange de l’information en entrée et/ou en sortie):  des utilisateurs humains,  matériels,  logiciels.
  • 56. 56
  • 57. Acteur 57  Est représenté par:  Un petit bonhomme (stick man) avec son nom dessous ou  Par un rectangle contenant le mot-clé << actor>> avec son nom dessous ou  Par un mélange de ces 2 représentations. Nom acteur <<actor>> Nom de l’acteur Nom de l’acteur
  • 58. UML : diagramme de cas d’utilisation Acteurs vs Personnes : Ne pas confondre acteur et personne utilisant le système : • Une même personne peut jouer plusieurs rôles, • Plusieurs personnes peuvent jouer un même rôle, • Un acteur n’est pas forcément une personne physique. 58
  • 59. Cas d’utilisation 59  Représentation : Acteur humain 1 Acteur Y <<actor>> Acteur X Cas d’utilisation 1 Cas d’utilisation 2
  • 60. Acteurs principaux et secondaires 60  Acteur principal d’un CU  Celui pour qui le CU produit un résultat observable  A gauche des CU (généralement)  Acteur secondaire d’un CU  Celui pour qui le CU ne produit pas un résultat observable par l’utilisateur  Souvent sollicités pour des informations complémentaires  A droite des CU (généralement)  Ex. : système d’autorisation appelé par le distributeur de billets
  • 61. Description des acteurs 61  Pour chaque acteur :  choisir un identificateur représentatif de son rôle  donner une brève description textuelle (facultatif) Un guichetier est un employé de la banque. Interface entre le système informatique et les clients. Peut effectuer une série d’opérations: création d ’un compte, dépôt et retrait d ’argent, etc. Guichetier
  • 62. Utilité des acteurs 62  La définition d’acteurs permet d’identifier les cas d’utilisation. Exemple: que peut faire un guichetier ? un client ?
  • 63. Diagramme de cas d’utilisation acteur acteur Le système interaction cas d’utilisation X cas d’utilisation Y L’acteur est source et/ou destination d’une interaction Frontière du système • Un diagramme de cas d'utilisation regroupe plusieurs cas d'utilisation qui ont un fort lien fonctionnel. 63
  • 64. Relations entre acteurs et cas d’utilisation 64  Relation d’association (« participe à ») : Lien entre un acteur et un cas d’utilisation qu’il peut exécuter  Un cas d’utilisation doit être relié au moins à un acteur Guichetier Créer Un Compte
  • 65. 65
  • 66. Relations entre cas d’utilisation: Inclusion 66  Relation d’inclusion  Utilisation du stéréotype « include »  Un cas A (identifier le client) est inclus dans un cas B (retirer de l’argent) si le comportement décrit par le cas A est inclus dans le comportement de B  Le CU de base B incorpore explicitement le CU A de façon obligatoire à un endroit spécifié dans ses enchaînements.  Le CU inclus peut porter le stéréotype « fragment » « fragment » Identifier le client Retirer de l’argent « include » B A
  • 67. Relations entre cas d’utilisation: extension 67  Relation d’extension optionnelle :  le CU de base B incorpore un CU A de façon optionnelle :  Ex. Le CU ‘Consulter solde’ se fait uniquement sur demande du client de la banque; il étend le CU ‘Retirer de l’argent’  Utilisée pour décrire une variation du comportement normal  Souvent soumise à condition exprimée sous la forme d’une note  Utilisation du stéréotype « extend »  Une variation par rapport à un Cas d’utilisation de base  Exemple: Site d’annonceTayara.tn Consulter solde Retirer de l’argent « extend » Sur demande du client B A
  • 68. 68  Option: La relation « extend » peut spécifier à la fois :  la condition de l'extension,  le point d'extension, c’est-à-dire l'endroit où l'extension doit être faite dans le Use Case. Relations entre cas d’utilisation: extension «extend » {Montant > 500 Dinars} Vendre Calculer TVA « include » Faire réduction Vendre en gros Point d ’extension •Faire réduction quand montant déterminé
  • 69. 69 Consulter le solde « extend » Retirer argent Point d ’extension: Consulter solde • Dans le cas « Retirer argent », le client peut vouloir vérifier son solde. • Attention au sens des flèches dans les relations inclut/étend Relations entre cas d’utilisation: extension
  • 70. Relations entre cas d’utilisation 70 Ce point d’extension doit être déclaré dans la description textuelle, par exemple en modifiant comme ceci l’enchaînement nominal : ... 7. Le SI banque donne son accord et indique le solde hebdomadaire. 8. Le GAB demande au Client banque de saisir le montant désiré du retrait. Point d’extension : Consulter solde 9. Le Client banque saisit le montant désiré du retrait. 10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire. ...
  • 71. Relation entre cas d’utilisation 71 Client Commander Choisir articles Demander catalogue <<extend>> <<include>> Payer <<include>> attention au sens des flèches
  • 72. Relations entre cas d’utilisation: héritage 72  Relation de généralisation/spécialisation  Un cas A est une généralisation d’un cas B si B est un cas particulier de A  Déposer de l’argent est cas d’utilisation généralisé. Il devient abstrait (italique) car il ne s’instancie pas directement, mais uniquement par le biais de l’un des 2 cas spécialisés A B Déposer de l’argent Déposer du liquide Déposer des chèques
  • 73. Relations entre acteurs: héritage 73  Uniquement relation de généralisation/spécialisation  A est une généralisation de B si tous les CU accessibles à A sont accessibles à B, mais pas l’inverse. B A
  • 74. Structuration en package 74  Si les diagrammes de cas d’utilisation sont nombreux  les regrouper par acteur  Opérations client  Opérations administrateur  etc.  les regrouper par domaine fonctionnel  Gérer les contrats  Gérer les clients  Etc. Gérer les clients
  • 75. Exemple: Relation d'inclusion 75 <<include>> <<include>> <<include>> <<include>> Retirer de l'argent Déposer de l'argent Effectuer des virements Consulter solde S'authentifier Les cas d'utilisation "Déposer de l'argent", "Retirer de l'argent", "Effectuer des virements" et "Consulter solde" incorporent de façon explicite le cas d'utilisation "S'authentifier", à un endroit spécifié dans leurs enchaînements.
  • 76. 76 Exemple: Relation d’héritage Un ‘Guichetier Chef’ est un ‘Guichetier’ spécialisé qui peut faire tout ce que peut faire un Guichetier et, en plus, il peut annuler un compte. L’héritage simplifie le dessin (moins d’interactions à dessiner). ‘Déposer chèques’ et ‘Déposer numéraire’ sont 2 spécialisations de ‘Déposer de l’argent sur un compte’ (2 manières de faire). Guichetier Guichetier Chef Créer un compte Retrait argent Déposer de l’argent sur un compte Annuler un compte Déposer chèques Déposer numéraire
  • 77. Diagramme de cas d’utilisation 77 Il délimite le domaine d’étude en précisant: Ce qui est à la charge du système et En identifiant l’environnement extérieur au système étudié avec lequel ce dernier communique.
  • 79. Niveau de raffinement des DCU 79  Un DCU, comme tout diagramme UML, permet de décrire une réalité selon différents niveaux de raffinement.  Il convient d’indiquer le « niveau d'abstraction »:  Niveau stratégique: Présente le contexte général, les grandes fonctions du système (processus métier): DCU principal ou général ou global.  Niveau raffiné: Ce sont des cas d'utilisation qui participent au bon déroulement de cas d'utilisation: DCU raffiné
  • 80. Diagramme de cas d’utilisation 80  Un cas d'utilisation peut être raffiné par des diagrammes de cas d'utilisations, formant ainsi une arborescence.
  • 81. Description du modèle de cas d ’utilisation 81  Un modèle de cas d’utilisation peut contenir  Plusieurs diagrammes  Plusieurs descriptions textuelles  Permet d’avoir une vision globale du système  Permet de définir des priorités entre CU  Utile pour la planification détaillée
  • 82. Description des cas d’utilisation 82  Le diagramme de cas d’utilisation décrit les grandes fonctions d’un système du point de vue des acteurs.  Mais il n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation.  Nécessité de décrire ce dialogue
  • 83. Description des cas d’utilisation 83 Deux façons sont couramment utilisées pour décrire les cas d’utilisation :  Description textuelle,  Description à l’aide d’un diagramme de séquence ou diagramme d’activité
  • 85. Description textuelle de CU 85  Les cas d’utilisation sont développés par du texte dans des scénarios non représentés dans le diagramme.  CU = ensemble de scénarios.  Un scénario= une exécution particulière d’un CU.
  • 86. Description textuelle de Cas d’utilisation 86
  • 87. Description textuelle de haut niveau 87
  • 88. Description textuelle étendue 88 1. Identification : Titre, Résumé, Acteurs. 2. Description des scénarios: 1. Nominal, 2. Alternatifs, 3. D’erreur ou exception 4. Préconditions + postconditions 3. Optionnel : Exigences non-fonctionnelles (fiabilité, performance, intégrité, …) et besoins IHM.
  • 90. Description textuelle des cas d’utilisation 90  Les pré-conditions : Conditions garantissant que le cas d’utilisation peut démarrer correctement. Ex: Disposer d’un numéro de réservation pour acheter un ticket de cinéma via le distributeur (Ex4 du TD).  Des scénarios : On distingue  le scénario nominal, qui se déroule quand il n’y a pas d’erreur,  les scénarios alternatifs qui sont les variantes du scénario nominal  Branchement dans la séquence nominale (on y revient)  les scénarios d’exception ou d’erreurs qui décrivent les cas d’erreurs.  Le séquencement nominal s’interrompt, sans retour à la séquence nominale.  Les post-conditions : Ensemble de conditions qui doivent être satisfaites à la fin du cas (scénario nominal) pour garantir que le
  • 91. Exemple de description détaillée d’un CU: sommaire d’identification 91 Titre : Retirer de l’argent Résumé : CU qui permet à un client de la banque de retirer de l’argent Acteurs : client Précondition : Le distributeur contient des billets, il est en attente d’une opération, il n’est ni en panne, ni en maintenance Début : lorsqu ’un client introduit sa carte bancaire dans le distributeur. Fin : lorsque la carte bancaire et les billets sont sortis. Postcondition : Le GAB contient moins de billets qu’au début du CU. Transaction de retrait enregistrée par le GAB. Retirer de l’argent
  • 92. Exemple de description détaillée d’un CU: description des scénarios 92 Retirer de l’argent Scénario nominal = déroulement normal : (1) le client introduit sa carte bancaire (2) le système lit la carte et vérifie si la carte est valide (3) le système demande au client de saisir son code (4) le client saisit son code confidentiel (5) le système vérifie que le code correspond à la carte (6) le client choisit une opération de retrait (7) le système demande le montant à retirer … Scénarios alternatifs A1.Montant demandé supérieur au solde du compte (branchement à l’étape 7) A2.Code erroné (pour la 1ère ou 2ème fois) (branchement à l’étape 3) Scénarios d’erreurs (se terminent brutalement) : E1.Carte invalide : au cours de l ’étape (2) si la carte est jugée invalide, le système affiche un message d’erreur, rejette la carte et le cas d ’utilisation se termine. E2.Code erroné (pour la 3ème fois) : au cours de l ’étape (5) ...
  • 93. Exemple de description détaillée d’un CU: exigences non-fonctionnelles 93 Exigences non-fonctionnelles : (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes, quelle que soit l’action de l’utilisateur. (B) Résistance aux pannes : si une coupure de courant ou une autre défaillance survient au cours du cas d’utilisation, la transaction sera annulée, l ’argent ne sera pas distribué. Le système doit pouvoir redémarrer automatiquement dans un état cohérent et sans intervention humaine. (C) Résistance à la charge : le système doit pouvoir gérer plus de 1000 retraits d ’argent simultanément ... Retirer de l’argent
  • 94. Exemple de description détaillée d’un CU: besoins IHM 94 Besoins d’IHM : dispositifs d’entrée-sortie à la disposition de l’acteur principal: -Lecteur de carte bancaire -Clavier numérique -Ecran pour l’affichage des messages du GAB -Touches autour de l’écran -Distributeur de billets -Distributeur de tickets Retirer de l’argent
  • 96. 96  Sommaire d'identification   Titre : retirer de l'argent avec carte VISA  Résumé : ce cas d'utilisation permet à un porteur de carte VISA, de retirer de l'argent, si son crédit hebdomadaire le permet.  Acteurs : Porteur de carte VISA, Système d'autorisation;  Date de création : 20/02/2015  Version : 1.0  Responsable : YY   Description des scénarios   Pré-conditions: La caisse du GAB est alimentée (il reste au moins un billet) ; Aucune carte ne se trouve déjà coincée dans le lecteur.  Post-conditions:  - Les compte du client est débité, Enregistrement de la transaction  - Le distributeur est débité
  • 97. 97  Scénario nominal 1. Le porteur de carte introduit sa carte VISA dans le lecteur de cartes du GAB ; 2. Le GAB vérifie que la carte VISA introduite est bien une carte bancaire ; 3. Le GAB demande au porteur de carte VISA de saisir son code d'identification ; 4. Le porteur de carte saisit son code d'identification ; 5. Le GAB compare le code d'identification avec celui qui est codé sur la puce de la carte ; 6. Le GAB demande une autorisation au système d'autorisation ; 7. Le système d'autorisation donne son accord et indique le solde hebdomadaire ; 8. Le GAB demande au porteur de saisir le montant désiré du retrait ; 9. Le porteur de carte saisit le montant désiré du retrait ; 10. Le GAB contrôle le montant demandé par rapport au solde hebdomadaire ; 11. Le GAB demande au porteur de carte s'il veut un ticket 12. Le porteur de carte demande un ticket ; 13. Le GAB rend sa carte au porteur de carte ; 14. Le porteur de carte reprend sa carte ; 15. Le GAB délivre les billets et un ticket ; 16. Le porteur de carte prend les billets et le ticket ; 17. Le GAB enregistre la transaction de retrait.
  • 98.  Une présentation intéressante des scénarios consiste à séparer les actions des acteurs et du système en deux colonnes comme suit :
  • 99. 1. Le porteur de carte introduit sa carte VISA dans le lecteur de cartes du GAB ; 2. Le GAB vérifie que la carte VISA introduite est bien une carte bancaire ; 3. Le GAB demande au porteur de carte VISA de saisir son code d'identification ; 4. Le porteur de carte saisit son code d'identification ; 5. Le GAB compare le code d'identification avec celui qui est codé sur la puce de la carte ; 6. Le GAB demande une autorisation au système d'autorisation ; 7. Le système d'autorisation donne son accord et indique le solde hebdomadaire ; 8. Le GAB demande au porteur de saisir le montant désiré du retrait ; 9. Le porteur de carte saisit le montant désiré du retrait ; 10. Le GAB contrôle le montant demandé par rapport au solde autorisé ; 11. Le GAB demande au porteur de carte s'il veut un ticket 12. Le porteur de carte demande un ticket ; 13. Le GAB rend sa carte au porteur de carte; 14. Le porteur de carte reprend sa carte ; 15. Le GAB délivre les billets et un ticket ; 16. Le porteur de carte prend les billets et le ticket; 17. Le GAB enregistre la transaction de retrait.
  • 100. GAB: Scénarios alternatifs (attention, il ne s’agit pas des enchaînements d’erreur !) A1 : code d’identification provisoirement erroné L’enchaînement A1 démarre au point 5 du scénario nominal. 6. Le GAB indique au Porteur de carte que le code est erroné, pour la première ou deuxième fois. 7. Le GAB enregistre l’échec sur la carte. Le scénario nominal reprend au point 3. A2 : montant demandé supérieur au solde autorisé (hebdomadaire et le crédit du compte) L’enchaînement A2 démarre au point 10 du scénario nominal. 11. Le GAB indique au Porteur de carte que le montant demandé est supérieur au solde autorisé. Le scénario nominal reprend au point 8. A3 : ticket refusé L’enchaînement A3 démarre au point 11 du scénario nominal. 12. Le Porteur de carte refuse le ticket. Le scénario nominal reprend au point 13.
  • 101. GAB: Scénarios d’erreur ou d’exception E1 : carte non-valide L’enchaînement E1 démarre au point 2 du scénario nominal. 3. Le GAB indique au Porteur que la carte n’est pas valide (illisible, périmée, etc.), la confisque ; le cas d’utilisation se termine en échec. E2 : code d’identification définitivement erroné L’enchaînement E2 démarre au point 5 du scénario nominal. 6. Le GAB indique au Porteur de carte que le code est erroné, pour la troisième fois. 7. Le GAB confisque la carte. 8. Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec. E3 : retrait non autorisé L’enchaînement E3 démarre au point 6 du scénario nominal. 7. Le Système d’autorisation interdit tout retrait. 8. Le GAB éjecte la carte ; le cas d’utilisation se termine en échec. E4 : carte non reprise L’enchaînement E4 démarre au point 13 du scénario nominal. 14. Au bout de 10 secondes, le GAB confisque la carte. 15. Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec.
  • 102. GAB: Scénarios d’erreur E5 : billets non pris L’enchaînement E5 démarre au point 15 du scénario nominal. 16. Au bout de 10 secondes, le GAB reprend les billets. 17. Le cas d’utilisation se termine en échec. E6 : annulation de la transaction L’enchaînement E6 peut démarrer entre les points 4 et 12 du scénario nominal. 4 à 12. Le Porteur de carte demande l’annulation de la transaction en cours. Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.
  • 103. GAB: Diagramme de séquence
  • 104. 104
  • 105. Diagramme de séquence correct?  Remarque: La solution donnée ci-après est celle du cas d’utilisation « retrait avec carte visa ». Donc l’ acteur système d’information banque et remplacé par système d’ autorisation.
  • 106. Diagramme de séquence système (version1) Enregistrement transaction
  • 107. Diagramme de séquence système (version 2)
  • 108. Diagramme d’activité du cas d’utilisation « retrait argent » 108
  • 109. Description graphique des scénarios 109  Les scénarios peuvent être illustrés par des diagrammes de séquence ou diagramme d’activité.  Ces diagrammes sont issus de l’axe dynamique d’UML
  • 110. 110
  • 111. Diagramme de séquence « système » 111  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.
  • 114. Une notation peu informative 114 On peut ajouter des notes textuelles pour lever toute ambiguité