Ce document traite de la méthode UML et des diverses techniques de modélisation pour définir les besoins d'un système informatique. Il détaille les différents types de diagrammes UML, y compris les diagrammes de cas d'utilisation, de classes et d'interaction, tout en soulignant l'importance de la communication et de la collaboration dans le développement logiciel. En outre, il explore les exigences fonctionnelles et non fonctionnelles, ainsi que les pratiques de l'architecture orientée objet.

2. Plan du cours Introduction Le problème, Les techniques objet, Genèse d’UML Intro UML Les 13 diagrammes, les diagrammes expression de besoin, notion de modèle Les cas d’utilisation (modélisation métier et application) Les diagrammes statiques Le diagramme de classe et de package Les diagrammes dynamiques Séquence, automate, activité,… Etude de cas

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

8. Les cycles de DVP Conceptualisation Analyse Conception Codage Tests unitaires Intégration

9. Décrire ce que l’on doit faire(UC) => langage commun Langage commun => Glossaire Glossaire => Tout ce qui est mis dans un modèle doit avoir une définition associée ExpertMetier ExpertObjet Train Oméoplasmose Sténotype Classe Polymorphisme Relinker Langage commun

10. Les UC : Décrire les acteurs et ce qu’ils attendent du système Décrire l’ensemble des messages entrant et sortant du système Ne pas décrire comment on fait Décrire l’ensemble des contraintes Réutilisation d’un autre système Problème de capacité-volume (des chiffres) Problème de temps de réponse (des chiffres) Choix technique quelconque imposé Architecte Analyste-Concepteur

11. Partir des diagrammes de UC Trouver les classes d’analyse (Boundary et Control) Partir de la description des UC Trouver les classes entity Faire tourner le programme Diagramme de séquence Cas nominal Les cas d’exception Affiner le diagramme statique (attributs, opérations, nouvelles classes) Refaire des sous-systèmes Affiner les classes complexes : Automate RMQ : Ne pas se vautrer dans l’héritage

12. UML & Méthode

14. XP propose une un ensemble de pratiques organisées autour des principes suivants : 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). 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. L'équipe s'organise elle-même pour atteindre ses objectifs , en favorisant une collaboration maximale entre ses membres. 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é. Les développeurs améliorent sans cesse la structure interne du logiciel pour que les évolutions y restent faciles et rapides. Regis Medina

15. Source : the corporate Use Of Object Technology

16. Dvp = 20% Maintenance = 50%

17. Les Concepts Objet

18. 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) Le but principal n’est donc pas de produire de beaux documents, ni de conduire de nombreuses réunions, ni de proclamer de beaux slogans, ni de gagner des prix Pulitzer sur les lignes de code; mais simplement de produire des programmes capables de satisfaire le client aujourd’hui et demain. Tout le reste est secondaire UML est fait pour: Spécifier Comprendre Communiquer Documenter source : UML-User Guide Un dvp Objet

19. Un modèle contient : Des éléments de modélisation Des classes (reliées à d'autres classes) avec des opérations et des attributs Des informations supplémentaires sur le comportement des classes (automates, activité) Des informations concernant le cahier des charges (UC) La description des fichiers et des machines supportant l'application Des dessins (vues) explicatifs liés les uns aux autres Des diagrammes de classes réduits Des diagrammes montrant comment les objets se partagent le travail (interaction) Des diagrammes montrant les objets existant à un moment donné Toutes ces informations sont organisées dans des packages

20. Un modèle contient : Un diagramme de Use Case Des diagrammes d’interraction Des diagrammes d’automate Des diagrammes d’activité Des diagrammes de vues d’ensemble des interractions Des diagrammes de classes Les contraintes techniques Toutes ces informations sont organisées dans des packages

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

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. Exemple : un acteur est "comme" une classe, mais il ne fait pas partie du système. Un acteur pourrait être un stéréotype d'une classe On peut stéréotyper les classes, les associations, les packages, ….. On peut associer un nouvel icône pour chaque nouveau stéréotype.

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

30. Un acteur parle au système (Acteur principal) Le système parle à un acteur (Acteur secondaire) Un acteur est : Un humain (via une IHM) Du soft Du hard 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.

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

33. Titre et numérotation Résumé Les acteurs Acteur principal Acteurs secondaires Pré-conditions Description Exceptions Post-conditions (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

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 .

43. De quelle entreprise s'agit-il? Trouver les acteurs, entités (objets), use case, les employés ….. Voyageur Métro Station Couloir Client Inspecteur Wagon Guichetier Panneau publicitaire Conducteur Clochard Commerciaux Voyager Acheter Louer

44. Diagramme de classe

45. Statique : Ne pas utiliser de verbes d'action pour relier les classes Une classe isolée est une classe inutile Doit être vrai tout le temps Représente LE programme On ne peut pas tout montrer sur un seul schéma Un diagramme de classe montre la structure statique du modèle, les choses qui existent, leur structure interne et les relations aux autres choses.

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

49. Association & Dépendance Les associations (relations) connectent deux ou plusieurs classes. Elles peuvent porter un nom. Si une association connecte une classe à elle-même, elle est dite réflexive. Une classe peut simplement dépendre d’une autre classe

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

56. Notion de package Un paquetage est un regroupement d’éléments de modélisation, mais aussi une encapsulation de ces éléments. A l’image des classes, les paquetages possèdent une interface et une réalisation . Chaque élément contenu par un paquetage possède un paramètre qui signale si l’élément est visible ou non à l’extérieur du paquetage. Les valeurs prises par le paramètre sont : public ou implémentation (privé).

57. Cela signifie que : Un élément de P0 au moins utilise un élément publique de P3 et de P1 Un élément de P3 au moins utilise un élément publique de P1 P0, P3 et P1 peuvent utiliser les éléments publiques de p2

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

65. Diagrammes d'interaction (Séquence collaboration) servent à montrer comment les objets se parlent les une aux autres. Ils montrent le déroulement d'un ou d'une partie d'un Use case (cas nominal, cas des exceptions, …) Automates servent à montrer le comportement d'une classe qui réagit différemment selon son état. Activités montrent le déroulement d'une méthode d'une classe ou celui d'un Use case

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

77. Les diagrammes d’interaction générale fusionnent les diagrammes d’activité et de séquence en autorisant l’utilisation de fragments (diagrammes de séquence) avec des points de décision et des flots de contrôle (diagrammes d’activité).

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.

82. Faire un diagramme de Use Case Faire un diagramme d’activité, présentant les étapes pour créer, modifier et supprimer une affaire. Faire un diagramme de classe Faire un Automate concernant les affaires Faire un diagramme de séquence Dessiner l’IHM 1 2 3 4 6 5

96. Business Actor(client) Business Worker(employée) Voyageur Métro Station Couloir Client Inspecteur Wagon Guichetier Panneau publicitaire Conducteur Clochard Commerciaux Voyager Acheter Louer Voyageur Métro Station Couloir Client Inspecteur Wagon Guichetier Panneau publicitaire Conducteur Clochard Commerciaux Voyager Acheter Louer

97. Voyageur Métro Station Couloir Client Inspecteur Wagon Guichetier Panneau publicitaire Conducteur Clochard Commerciaux Voyager Acheter Louer Voyageur Métro Station Couloir Client Inspecteur Wagon Guichetier Panneau publicitaire Conducteur Clochard Commerciaux Voyager Acheter Louer Business Entité(les objets) Business use case Les fonctions

106. delete valider