3. Le problème

4. Importance de l’expression des besoins Source Borland (Juin 2003 à Juin 2004)

5. Il faut une méthode

6. 2005 2.0 DOC-PDF UML1.3 = 4,7MB DOC-PDF UML2.0 = 5.8 MB 2006 2.1 Booch-93 Rumbaugh( OMT2) Oct-95 0.8 Jacobson (use case - sdl) Juillet-96 0.9 Janv-97 1.0 Nov-97 1.0 Sept-97 1.1 (OMG) 2000 1.4

7. UML

12. UML & Méthode

15. Source : the corporate Use Of Object Technology

16. Dvp = 20% Maintenance = 50%

17. Les Concepts Objet

21. Introduction

23. Les diagrammes pour la définition des besoins

26. Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants

28. {ceci est une contrainte} Rmq : On peut écrire des contraintes en OCL Une contrainte est raccrochée à un élément de modélisation

29. Diagramme de Use case

31. Un Cas d’utilisation ( use case ) est une fonctionnalité importante pour un acteur remplie par le système et qui se manifeste par un ensemble de messages échangés entre le système et un ou plusieurs acteurs. Description

34. Payer cash Payer par carte Manger Demander facture Maitre d'hotel Prendre la commande client Aller au restaurant <<include>> <<include>> Caissier Payer <<include>> <<extend>> Sommelier Commander pinard <<extend>> Serveur Retourner plat en cuisine <<extend>>

36. Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions

37. User Stories et Use Cases formalisent les besoins utilisateurs et sont orientés But Ils font facilement l'objet d'ateliers de travail avec les utilisateurs pour les découvrir, les expliciter Ils vont être priorisés et vont ainsi guider les développements Ils mettent en avant les rôles, les différents profils d'utilisateurs Ils ne traitent que des exigences fonctionnelles (les aspects non fonctionnels sont décrits dans les spécifications supplémentaires (contexte UP) et dans les &quot;Constraints Cards&quot; (contexte XP)) Ils sont textuels et obéissent à des règles de construction très précises Ils ne traitent pas des aspects interface et ergonomie Ils aident à organiser le modèle Ils facilitent le choix du contenu des itérations Ils peuvent être rédigés par les analystes (UC) ou le client (US)

39. Cas d'utilisation : Essentiellement un ensemble d'interactions Acteur: Élément externe qui interagit avec le système (humain ou autre système) Scénario : Une lecture particulière d'un cas d'utilisation, son instanciation Relation de communication : Le vecteur de l'échange (l'interaction) entre acteur et système <<include>> : Relation qui, lorsqu'elle existe entre deux cas, est obligatoirement appliquée. C'est une dépendance entre le cas source qui inclut . <<extend>> : Relation de dépendance optionnelle. Il s'agit d'étendre les interactions d'un cas avec celles d'un autre. Spécialisation de cas : La même finalité, mais obtenue par des interactions différentes .

40. Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prendre en compte des commandes passées par la poste et des commandes passées par internet. Il doit suivre les expéditions qui ne sont effectuées que si le paiement est OK. Les paiements se font par carte bancaire dans le cas d'internet et par chèque dans le cas de la poste. Les paiements sont validés par un système bancaire appartenant à la société et existant. Il faut récupérer ce système. Le nouveau système est chargé aussi de la gestion de stocks, lorsqu'un article atteint un seuil minimal, alors il faut passer une nouvelle commande au fournisseur adéquat. A la réception de la commande, la mise à jour de la base est faite par un employé. Dans le cas d'un paiement accepté et de stock disponible, l'expédition est faite par un robot existant au quel il suffit de passer les coordonnées du client, et la liste des produits achetés. En cas d'indisponibilité, une lettre doit être envoyé au client.

41. La première étape de la définition d’un système d’information consiste donc à s’interroger sur l’organisation (l’entreprise) pour laquelle ce système d’information fonctionne, sur son identité, sur ce qui en fait partie et sur ce qui n’en fait pas partie Utilisé par L’entreprise Comment fait l’entreprise Les objets de l’entreprise Utilisateur Employés de L’entreprise Ce que fait l’entreprise

42. Selon Alistair Cockburn , il existe trois niveaux principaux qu'il situe allégoriquement par rapport à un niveau de référence qui est &quot;celui de la mer&quot;. Mouette : Au-dessus de la mer, représente plutôt des cas d'utilisation métier Mer: Le cas d'utilisation &quot;système&quot; dans son acceptation classique : une situation qui génère une bonne valeur ajoutée pour l'un des utilisateurs (acteurs) ; une fonctionnalité au sens habituel du terme (un micro-onde offre deux fonctionnalités principales qui sont &quot;Décongélation&quot; et la &quot;Cuisson&quot;). Crabe : Quelques interactions qui ne constituent pas vraiment une situation d'utilisation en tant que telle. Ce seront généralement des cas qui seront réinjectés dans le modèle via des relations include ou extend .

44. Diagramme de classe

46. Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}

50. Nom d'association Nom de rôle Cardinalité-Multiplicité Personne employeur : Societe Societe employe : ListeOfPersonne Navigabilité Societe Personne 1..* -employes 1..* Societe employes : Personne Personne

55. On peut montrer ce qu’il y a à l’intérieur du package Une classe appartient à un package et un seule, mais peut être utilisée dans d'autres package. Un package est un regroupement des éléments du model. Cela s’applique à tous les éléments UML ainsi qu’aux différents diagrammes. Les packages sont la base de la gestion de configuration

59. K L A B I E J G D H C F

60. Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement

63. Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Location Vente Nourriture Lapin Whisky Mariage CompteBanquaire Personne

64. Diagrammes dynamiques

66. new

70. Un automate est accroché à une classe (ou un UC) et est composé d'états et de transitions. Les transitions permettent de passer d'un état à un autre …

71. Événement qui déclenche la transition Garde Action effectuée sur la transition Envoie de Ev2 à un objet Cible Action en entrant dans l'état Action en sortant de l'état Action déclenchée sur réception de Ev1 Activité

74. E1 E3 E1 E3 E1 E2 E1 E2 E3 E1 ST1 entry: i = 0 exit: i++ ST2 entry: i++ exit: i++ on E4: i ++ E1 / i++ ST3 ST4 on E2: i = i - 2 E3[ i == 5 ] E2 E1 E1 E3 E3

78. Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Component Deployment Code Code Code Code Tests

79. Patron du dossier d'expression des besoins Projet <<nom du projet>> Version < ?. ?> Historique des révisions Introduction Présentation du document Objectifs du document Contenu du document Description du Métier (Optionnel)  Les entités métiers (diagramme de classe)  Les processus métiers (diagramme d’activité + états des objets) Description du produit  Les objectifs du produit, les avantages qu'apporte le produit  Les fonctionnalités du produit (UC)  Les utilisateurs du produit et leurs caractéristiques (acteurs humains)  Les contraintes du produit, règles métier  Les hypothèses (conditions d'utilisation) et les dépendances (acteurs système)

80. Les besoins-exigences non fonctionnels Exigence en terme de qualité  Utilisabilité (Maniabilité) [ Par exemple: le temps de formation nécessaire à la prise en main du produit, exigence de standardisation, …]  Fiabilité (Conformité) [ On trouve ici les caractéristiques principales de la fiabilité comme, par exemple: temps moyen entre 2 pannes, le temps moyen d'intervention,…]  Performance (Efficacité) [ Par exemple: Temps de réponse moyen et maximal pour une transaction, le nombre d'utilisateurs simultanés, les fonctionnements dégradés acceptables, l'utilisation des ressources (mémoire, disque, communications,...) ]  Documentation et aide en ligne Autres exigences  Contraintes de conception (langage, machine, BD persistence,…..)  Les composants non développés dans l'application (Réutilisation)  Les interfaces (API, Corba,….)  acteurs secondaires?  Les interfaces utilisateurs, érgonomie…..construites à partir des boundary

81. Objectifs : décrire les besoins d’un système informatique. La première description est faite par le client. Cas de l’étude : logiciel de Gestion d’Affaires (GA) demandé par un client tertiaire, 250 personnes, 10000 affaires). Le logiciel de gestion d’affaires doit permettre de gérer, par collaborateur, les affaires dont il s’occupe. Une affaire peut posséder un nom, un client, une date de création, une date de fin prévue, un état (en cours, en retard, en cours mais en retard, abandonnée, terminée), une description. Les actions possibles sur une affaire sont : création, modification, suppression. Les affaires devront être présentées en 4 listes : en cours et en retard, en retard, toutes, terminées. La sélection doit se faire par collaborateur, ou bien par client.

106. delete valider