Plan du cours <ul><li>Introduction </li></ul><ul><ul><li>Le problème, Les techniques objet, Genèse d’UML  </li></ul></ul><...
Le problème
Importance de l’expression des besoins Source Borland (Juin 2003  à Juin 2004)
Il faut une méthode
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 -...
UML
Les cycles de DVP <ul><li>Conceptualisation </li></ul><ul><li>Analyse </li></ul><ul><li>Conception </li></ul><ul><li>Codag...
<ul><li>Décrire ce que l’on doit faire(UC)  => langage commun </li></ul><ul><li>Langage commun => Glossaire </li></ul><ul>...
<ul><li>Les UC : </li></ul><ul><li>Décrire les acteurs et ce qu’ils attendent du système </li></ul><ul><li>Décrire l’ensem...
<ul><li>Partir des diagrammes de UC </li></ul><ul><ul><li>Trouver les classes d’analyse (Boundary et Control) </li></ul></...
UML & Méthode
<ul><li>XP propose une un ensemble de pratiques organisées autour des principes suivants : </li></ul><ul><li>Le client (ma...
Source :  the corporate Use Of Object Technology
Dvp = 20% Maintenance = 50%
Les Concepts Objet
<ul><li>Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité qui satisfont les ...
<ul><li>Un modèle contient : </li></ul><ul><li>Des éléments de modélisation </li></ul><ul><ul><li>Des classes (reliées à d...
<ul><li>Un modèle contient : </li></ul><ul><li>Un diagramme de Use Case </li></ul><ul><ul><li>Des diagrammes d’interractio...
Introduction
Les diagrammes pour la définition des besoins
Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants
Un stéréotype est une nouvelle classe d’un élément de  modélisation qui est introduit au moment de la  modélisation. Cela ...
{ceci est une contrainte} Rmq : On peut écrire des contraintes en OCL Une contrainte est raccrochée à un élément de modéli...
Diagramme de Use case
<ul><li>Un acteur parle au système (Acteur principal) </li></ul><ul><li>Le système parle à un acteur (Acteur secondaire) <...
Un  Cas d’utilisation  ( use case ) est une  fonctionnalité   importante pour un acteur  remplie par le système et qui se ...
<ul><li>Titre et numérotation </li></ul><ul><li>Résumé </li></ul><ul><li>Les acteurs </li></ul><ul><ul><li>Acteur principa...
Payer cash Payer par carte Manger Demander facture Maitre d'hotel Prendre la commande client Aller au restaurant <<include...
Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
User Stories et Use Cases formalisent  les besoins utilisateurs  et sont  orientés But Ils font facilement l'objet  d'atel...
Cas d'utilisation : Essentiellement un  ensemble d'interactions   Acteur:   Élément externe qui  interagit avec le système...
Une société de vente par correspondance vous demande de développer son système informatique. Ce système doit pouvoir prend...
La première étape de la définition d’un système d’information consiste donc à s’interroger sur   l’organisation (l’entrepr...
Selon  Alistair Cockburn , il existe trois niveaux principaux qu'il situe allégoriquement par rapport à un niveau de référ...
<ul><li>De quelle entreprise s'agit-il? </li></ul><ul><ul><li>Trouver les acteurs,  entités (objets),  use case, les emplo...
Diagramme de classe
<ul><li>Statique : </li></ul><ul><ul><li>Ne pas utiliser de verbes d'action pour relier les classes </li></ul></ul><ul><ul...
Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité...
Association & Dépendance <ul><li>Les associations (relations) connectent deux ou plusieurs classes. </li></ul><ul><li>Elle...
Nom d'association Nom de rôle Cardinalité-Multiplicité Personne employeur : Societe Societe employe : ListeOfPersonne Navi...
 
On peut montrer ce qu’il y a à l’intérieur du package Une classe appartient à un package et un seule, mais peut être utili...
Notion de package <ul><li>Un paquetage est un regroupement d’éléments de modélisation,  </li></ul><ul><li>mais aussi une e...
<ul><li>Cela signifie que : </li></ul><ul><li>Un élément de P0 au moins utilise un élément publique de P3 et de P1 </li></...
K L A B I E J G D H C F
Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Location Vente Nourriture Lapin Whisky Mari...
Diagrammes dynamiques
<ul><li>Diagrammes d'interaction (Séquence collaboration)  servent à  </li></ul><ul><ul><li>montrer comment les objets se ...
new
Un automate est accroché à une classe (ou un UC) et est composé d'états et de transitions. Les transitions permettent de p...
Événement qui déclenche la transition Garde Action effectuée sur la transition Envoie de Ev2 à un objet Cible Action en en...
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...
<ul><li>Les diagrammes d’interaction générale fusionnent  </li></ul><ul><li>les  diagrammes d’activité et de  </li></ul><u...
Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Componen...
Patron du dossier d'expression des besoins Projet <<nom du projet>> Version < ?. ?> Historique des révisions Introduction ...
Les besoins-exigences non fonctionnels Exigence en terme de qualité   Utilisabilité (Maniabilité) [ Par exemple: le temps...
Objectifs  : décrire les besoins d’un système informatique. La première description est faite par le client.   Cas de l’ét...
<ul><li>  Faire un diagramme de Use Case </li></ul><ul><li>Faire un diagramme d’activité, présentant les étapes pour créer...
Business Actor(client) Business Worker(employée) <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li><...
<ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li...
delete valider
Prochain SlideShare
Chargement dans…5
×

Definitiondesbesoinsuml

2 382 vues

Publié le

UML - MOA
Maitrise d'oeuvre ouvrage

Publié dans : Business
0 commentaire
1 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 382
Sur SlideShare
0
Issues des intégrations
0
Intégrations
14
Actions
Partages
0
Téléchargements
251
Commentaires
0
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Definitiondesbesoinsuml

  1. 2. Plan du cours <ul><li>Introduction </li></ul><ul><ul><li>Le problème, Les techniques objet, Genèse d’UML </li></ul></ul><ul><li>Intro UML </li></ul><ul><ul><li>Les 13 diagrammes, les diagrammes expression de besoin, notion de modèle </li></ul></ul><ul><li>Les cas d’utilisation (modélisation métier et application) </li></ul><ul><li>Les diagrammes statiques </li></ul><ul><ul><li>Le diagramme de classe et de package </li></ul></ul><ul><li>Les diagrammes dynamiques </li></ul><ul><ul><li>Séquence, automate, activité,… </li></ul></ul><ul><li>Etude de cas </li></ul>
  2. 3. Le problème
  3. 4. Importance de l’expression des besoins Source Borland (Juin 2003 à Juin 2004)
  4. 5. Il faut une méthode
  5. 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
  6. 7. UML
  7. 8. Les cycles de DVP <ul><li>Conceptualisation </li></ul><ul><li>Analyse </li></ul><ul><li>Conception </li></ul><ul><li>Codage </li></ul><ul><li>Tests unitaires </li></ul><ul><li>Intégration </li></ul>
  8. 9. <ul><li>Décrire ce que l’on doit faire(UC) => langage commun </li></ul><ul><li>Langage commun => Glossaire </li></ul><ul><li>Glossaire => Tout ce qui est mis dans un modèle doit avoir </li></ul><ul><ul><li>une définition associée </li></ul></ul>ExpertMetier ExpertObjet Train Oméoplasmose Sténotype Classe Polymorphisme Relinker Langage commun
  9. 10. <ul><li>Les UC : </li></ul><ul><li>Décrire les acteurs et ce qu’ils attendent du système </li></ul><ul><li>Décrire l’ensemble des messages entrant et sortant du système </li></ul><ul><li>Ne pas décrire comment on fait </li></ul><ul><li>Décrire l’ensemble des contraintes </li></ul><ul><ul><li>Réutilisation d’un autre système </li></ul></ul><ul><ul><li>Problème de capacité-volume (des chiffres) </li></ul></ul><ul><ul><li>Problème de temps de réponse (des chiffres) </li></ul></ul><ul><ul><li>Choix technique quelconque imposé </li></ul></ul>Architecte Analyste-Concepteur
  10. 11. <ul><li>Partir des diagrammes de UC </li></ul><ul><ul><li>Trouver les classes d’analyse (Boundary et Control) </li></ul></ul><ul><li>Partir de la description des UC </li></ul><ul><ul><li>Trouver les classes entity </li></ul></ul><ul><ul><li>Faire tourner le programme </li></ul></ul><ul><ul><ul><li>Diagramme de séquence </li></ul></ul></ul><ul><ul><ul><ul><li>Cas nominal </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Les cas d’exception </li></ul></ul></ul></ul><ul><ul><ul><li>Affiner le diagramme statique </li></ul></ul></ul><ul><ul><ul><ul><li>(attributs, opérations, nouvelles classes) </li></ul></ul></ul></ul><ul><li>Refaire des sous-systèmes </li></ul><ul><li>Affiner les classes complexes : Automate </li></ul><ul><li>RMQ : Ne pas se vautrer dans l’héritage </li></ul>
  11. 12. UML & Méthode
  12. 13.
  13. 14. <ul><li>XP propose une un ensemble de pratiques organisées autour des principes suivants : </li></ul><ul><li>Le client (maîtrise d'ouvrage) pilote lui-même le projet , et ce de très près grâce à des cycles itératifs extrêmement courts (1 ou 2 semaines). </li></ul><ul><li>L'équipe livre très tôt dans le projet une première version du logiciel, et les livraisons de nouvelles versions s'enchaînent ensuite à un rythme soutenu pour obtenir un feedback maximal sur l'avancement des développements. </li></ul><ul><li>L'équipe s'organise elle-même pour atteindre ses objectifs , en favorisant une collaboration maximale entre ses membres. </li></ul><ul><li>L'équipe met en place des tests automatiques pour toutes les fonctionnalités qu'elle développe, ce qui garantit au produit un niveau de robustesse très élevé. </li></ul><ul><li>Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides. </li></ul>Regis Medina
  14. 15. Source : the corporate Use Of Object Technology
  15. 16. Dvp = 20% Maintenance = 50%
  16. 17. Les Concepts Objet
  17. 18. <ul><li>Une bonne société qui développe des programmes est celle qui fabrique des programmes de qualité qui satisfont les besoins des clients (livraison à temps, utilisation des ressources humaines et matérielles optimales) </li></ul><ul><li>Le but principal n’est donc pas de produire de beaux documents, </li></ul><ul><li>ni de conduire de nombreuses réunions, ni de proclamer de beaux </li></ul><ul><li>slogans, ni de gagner des prix Pulitzer sur les lignes de code; </li></ul><ul><li>mais simplement de produire des programmes capables de </li></ul><ul><li>satisfaire le client aujourd’hui et demain. </li></ul><ul><li>Tout le reste est secondaire </li></ul><ul><li>UML est fait pour: </li></ul><ul><li>Spécifier </li></ul><ul><li>Comprendre </li></ul><ul><li>Communiquer </li></ul><ul><li>Documenter </li></ul><ul><li>source : UML-User Guide </li></ul>Un dvp Objet
  18. 19. <ul><li>Un modèle contient : </li></ul><ul><li>Des éléments de modélisation </li></ul><ul><ul><li>Des classes (reliées à d'autres classes) avec des opérations et </li></ul></ul><ul><ul><ul><li>des attributs </li></ul></ul></ul><ul><ul><li>Des informations supplémentaires sur le comportement des </li></ul></ul><ul><ul><ul><li>classes (automates, activité) </li></ul></ul></ul><ul><ul><li>Des informations concernant le cahier des charges (UC) </li></ul></ul><ul><ul><li>La description des fichiers et des machines supportant l'application </li></ul></ul><ul><li>Des dessins (vues) explicatifs liés les uns aux autres </li></ul><ul><ul><li>Des diagrammes de classes réduits </li></ul></ul><ul><ul><li>Des diagrammes montrant comment les objets se partagent le </li></ul></ul><ul><ul><ul><li>travail (interaction) </li></ul></ul></ul><ul><ul><li>Des diagrammes montrant les objets existant à un moment donné </li></ul></ul><ul><li>Toutes ces informations sont organisées dans des packages </li></ul>
  19. 20. <ul><li>Un modèle contient : </li></ul><ul><li>Un diagramme de Use Case </li></ul><ul><ul><li>Des diagrammes d’interraction </li></ul></ul><ul><ul><li>Des diagrammes d’automate </li></ul></ul><ul><ul><li>Des diagrammes d’activité </li></ul></ul><ul><ul><li>Des diagrammes de vues d’ensemble des interractions </li></ul></ul><ul><li>Des diagrammes de classes </li></ul><ul><li>Les contraintes techniques </li></ul><ul><li>Toutes ces informations sont organisées dans des packages </li></ul>
  20. 21. Introduction
  21. 22.
  22. 23. Les diagrammes pour la définition des besoins
  23. 24.
  24. 25.
  25. 26. Navigateur Définitions Boutons génériques Boutons Spécifiques Les diagrammes Classe Use Case Composants
  26. 27. Un stéréotype est une nouvelle classe d’un élément de modélisation qui est introduit au moment de la modélisation. Cela représente une sous classe d’un élément de modélisation existant avec la même forme, mais avec une intention différente. <ul><li>Exemple : un acteur est &quot;comme&quot; une classe, mais il ne fait pas </li></ul><ul><li>partie du système. Un acteur pourrait être un stéréotype d'une classe </li></ul><ul><li>On peut stéréotyper les classes, les associations, les packages, ….. </li></ul><ul><li>On peut associer un nouvel icône pour chaque nouveau stéréotype. </li></ul>
  27. 28. {ceci est une contrainte} Rmq : On peut écrire des contraintes en OCL Une contrainte est raccrochée à un élément de modélisation
  28. 29. Diagramme de Use case
  29. 30. <ul><li>Un acteur parle au système (Acteur principal) </li></ul><ul><li>Le système parle à un acteur (Acteur secondaire) </li></ul><ul><li>Un acteur est : </li></ul><ul><ul><li>Un humain (via une IHM) </li></ul></ul><ul><ul><li>Du soft </li></ul></ul><ul><ul><li>Du hard </li></ul></ul>Un acteur est un rôle d’un ou plusieurs objets situés à l’extérieur du système et qui interagissent avec lui pour remplir une fonctionnalité donnée de ce système. Un acteur caractérise le rôle joué par un objet à l’extérieur du système.
  30. 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
  31. 32.
  32. 33. <ul><li>Titre et numérotation </li></ul><ul><li>Résumé </li></ul><ul><li>Les acteurs </li></ul><ul><ul><li>Acteur principal </li></ul></ul><ul><ul><li>Acteurs secondaires </li></ul></ul><ul><li>Pré-conditions </li></ul><ul><li>Description </li></ul><ul><li>Exceptions </li></ul><ul><li>Post-conditions </li></ul>(3-5 pages) Ce n ’est pas une description formelle Mais doit être très détaillé Ceci est l ’usage mais ne fait partie de la norme UML
  33. 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>>
  34. 35.
  35. 36. Manger Distribuer le comportement des fonctionnalités aux méthodes des objets Descriptions
  36. 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)
  37. 38.
  38. 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 .
  39. 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.
  40. 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
  41. 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 .
  42. 43. <ul><li>De quelle entreprise s'agit-il? </li></ul><ul><ul><li>Trouver les acteurs, entités (objets), use case, les employés ….. </li></ul></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>
  43. 44. Diagramme de classe
  44. 45. <ul><li>Statique : </li></ul><ul><ul><li>Ne pas utiliser de verbes d'action pour relier les classes </li></ul></ul><ul><ul><li>Une classe isolée est une classe inutile </li></ul></ul><ul><ul><li>Doit être vrai tout le temps </li></ul></ul><ul><ul><li>Représente LE programme </li></ul></ul><ul><ul><li>On ne peut pas tout montrer sur un seul schéma </li></ul></ul>Un diagramme de classe montre la structure statique du modèle, les choses qui existent, leur structure interne et les relations aux autres choses.
  45. 46. Abstrait Nom : type [= Initialisation] Syntaxe libre Attribut dérivé Attribut de classe Opération de classe Responsabilité {abstract}
  46. 47.
  47. 48.
  48. 49. Association & Dépendance <ul><li>Les associations (relations) connectent deux ou plusieurs classes. </li></ul><ul><li>Elles peuvent porter un nom. </li></ul><ul><li>Si une association connecte une classe à elle-même, elle est dite réflexive. </li></ul><ul><li>Une classe peut simplement dépendre d’une autre classe </li></ul>
  49. 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
  50. 51.
  51. 52.
  52. 53.
  53. 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
  54. 56. Notion de package <ul><li>Un paquetage est un regroupement d’éléments de modélisation, </li></ul><ul><li>mais aussi une encapsulation de ces éléments. A l’image des </li></ul><ul><li>classes, les paquetages possèdent une interface et une réalisation . </li></ul><ul><li>Chaque élément contenu par un paquetage possède un paramètre </li></ul><ul><li>qui signale si l’élément est visible ou non à l’extérieur du paquetage. </li></ul><ul><li>Les valeurs prises par le paramètre sont : public ou implémentation (privé). </li></ul>
  55. 57. <ul><li>Cela signifie que : </li></ul><ul><li>Un élément de P0 au moins utilise un élément publique de P3 et de P1 </li></ul><ul><li>Un élément de P3 au moins utilise un élément publique de P1 </li></ul><ul><li>P0, P3 et P1 peuvent utiliser les éléments publiques de p2 </li></ul>
  56. 58.
  57. 59. K L A B I E J G D H C F
  58. 60. Environnement Métier Fonctionnel B C E Fonctionnel Métier Environnement
  59. 61.
  60. 62.
  61. 63. Immeuble Famille Appartement Pièce Cuisine Salon Gardemanger Chien Chat Animal Location Vente Nourriture Lapin Whisky Mariage CompteBanquaire Personne
  62. 64. Diagrammes dynamiques
  63. 65. <ul><li>Diagrammes d'interaction (Séquence collaboration) servent à </li></ul><ul><ul><li>montrer comment les objets se parlent les une aux autres. </li></ul></ul><ul><ul><li>Ils montrent le déroulement d'un ou d'une partie d'un Use case </li></ul></ul><ul><ul><li>(cas nominal, cas des exceptions, …) </li></ul></ul><ul><li>Automates servent à montrer le comportement d'une classe qui </li></ul><ul><ul><li>réagit différemment selon son état. </li></ul></ul><ul><li>Activités montrent le déroulement d'une méthode d'une classe ou </li></ul><ul><ul><li>celui d'un Use case </li></ul></ul>
  64. 66. new
  65. 67.
  66. 68.
  67. 69.
  68. 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 …
  69. 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é
  70. 72.
  71. 73.
  72. 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
  73. 75.
  74. 76.
  75. 77. <ul><li>Les diagrammes d’interaction générale fusionnent </li></ul><ul><li>les diagrammes d’activité et de </li></ul><ul><li>séquence en autorisant l’utilisation </li></ul><ul><li>de fragments (diagrammes de </li></ul><ul><li>séquence) avec des points de </li></ul><ul><li>décision et des flots de contrôle </li></ul><ul><li>(diagrammes d’activité).   </li></ul>
  76. 78. Interaction Diagram Requirements Sequence Collaboration Use Cases GUI Class diagram State Activity Implementation Component Deployment Code Code Code Code Tests
  77. 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)
  78. 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
  79. 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.
  80. 82. <ul><li>  Faire un diagramme de Use Case </li></ul><ul><li>Faire un diagramme d’activité, présentant les étapes pour créer, modifier et supprimer une affaire. </li></ul><ul><li>Faire un diagramme de classe </li></ul><ul><li>Faire un Automate concernant les affaires </li></ul><ul><li>Faire un diagramme de séquence </li></ul><ul><li>Dessiner l’IHM </li></ul>1 2 3 4 6 5
  81. 83.
  82. 84.
  83. 85.
  84. 86.
  85. 87.
  86. 88.
  87. 89.
  88. 90.
  89. 91.
  90. 92.
  91. 93.
  92. 94.
  93. 95.
  94. 96. Business Actor(client) Business Worker(employée) <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>
  95. 97. <ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul><ul><li>Voyageur </li></ul><ul><li>Métro </li></ul><ul><li>Station </li></ul><ul><li>Couloir </li></ul><ul><li>Client </li></ul><ul><li>Inspecteur </li></ul><ul><li>Wagon </li></ul><ul><li>Guichetier </li></ul><ul><li>Panneau publicitaire </li></ul><ul><li>Conducteur </li></ul><ul><li>Clochard </li></ul><ul><li>Commerciaux </li></ul><ul><li>Voyager </li></ul><ul><li>Acheter </li></ul><ul><li>Louer </li></ul>Business Entité(les objets) Business use case Les fonctions
  96. 98.
  97. 99.
  98. 100.
  99. 101.
  100. 102.
  101. 103.
  102. 104.
  103. 105.
  104. 106. delete valider

×