Introduction rapide à 'objet et à UML

3,977 views

Published on

Version simple de l'introduction au cours.

Published in: Education
  • Be the first to comment

Introduction rapide à 'objet et à UML

  1. 1. ACSIModélisation par Objets À destination des étudiants de1e année IUT Nice-Sophia Antipolis (S2) Mireille Blay-Fornarino IUT Nice-Sophia Antipolis blay@unice.fr http://www.polytech.unice.fr/~blay Site web du module : http://anubis.polytech.unice.fr/iut/ 1
  2. 2. Intro. Intro. UML Démarche Plan Problèmes du développement logiciel Histoire brève jusqu’aux limites de la programmation structurée Du bidouillage au Génie logiciel Introduction à UML Un peu d’histoire Survol Présentation du Module : démarche générale09/10 2
  3. 3. I. Quels sont les problèmesdu développement logiciel? 3
  4. 4. I. Quels sont les problèmesdu développement logiciel? Un peu d’histoire 4
  5. 5. Intro. ✓histoire Intro. UML Démarche La gestion progressive de la complexité Premiers programmes en langage machine  Les premiers programmes, écrits en langage machine, dépendaient fortement de larchitecture des ordinateurs utilisés. sub     $sp, $sp, 4 sw      r,0($sp)09/10 5
  6. 6. Intro. ✓histoire Intro. UML Démarche La gestion progressive de la complexité Programmation en langages évolués  Lorsque le nombre darchitectures différentes a augmenté, un premier effort a été produit pour séparer les concepts manipulés dans les langages de leur représentation dans la machine et a abouti à la création de langages comme FORTRAN. PROGRAM DEGRAD ! ! Imprime une table de conversion degrés -> radians ! ================================================= ! ! Déclaration des variables INTEGER DEG REAL RAD, COEFF ! ! En-tête de programme WRITE ( *, 10) 10 FORMAT ( ,20(*) / & & * Degres * Radians * / & & , 20(*) ) ! ! Corps de programme COEFF = (2.0 * 3.1416) / 360.0 DO DEG = 0, 90 RAD = DEG * COEFF WRITE ( *, 20) DEG, RAD 20 FORMAT ( * ,I4, * ,F7.5, *) END DO ! ! Fin du tableau WRITE ( *, 30) 30 FORMAT ( ,20(*) ) ! ! Fin de programme STOP09/10 6 END PROGRAM DEGRAD
  7. 7. Intro. ✓histoire Intro. UML Démarche La gestion progressive de la complexité Méthode d’analyse par décomposition  La complexité croissante des programmes a de nouveau suscité un effort pour mieux structurer les programmes (abandon du goto et de la programmation spaghetti)  Les méthodes danalyse consistait alors à «diviser pour mieux régner», i.e. à découper les tâches en modules indépendants.  Niklaus Wirth va plus loin : les programmes sont la «somme» dune structure de données et dun ensemble distinct dalgorithmes chargés de les manipuler. ➡ La programmation structurée étaient alors synonyme de programmation dirigée par les traitements. function ConstruitPhrase(phrase:string):string; var s : string; begin readln(s); ConstruitPhrase:=phrase+, +s; end; var Phrase : string; begin Phrase:=; {initialiser à chaîne vide} {premier mot} writeln(Entrez un mot :);09/10 7 Phrase:=ConstruitPhrase(Phrase);
  8. 8. Intro. ✓histoire Intro. UML Démarche La gestion progressive de la complexité L’explosion des besoins  Le coût du matériel informatique a fortement décru et ce matériel est devenu un bien de consommation courant (tant dans des entreprises et des universités que chez les particuliers).  La clientèle sest diversifiée, les besoins ont explosé.09/10 8
  9. 9. Intro. ✓histoire Intro. UML Démarche Limites de la programmation structurée La diffusion de la structure des données dans le code  La programmation structurée nécessite de faire des hypothèses sur les données à traiter. La structure physique des données à traiter est diffusée dans une part importante du code.  Une simple modification des exigences des utilisateurs ou une modification des données peut entraîner dimportantes modifications au niveau des codes chargés de les traiter.  Par exemple, en 1982, les postes américaines sont passés du code postal à 5 chiffres à celui à 9 chiffres. Beaucoup de programmes gérant des fichiers dadresses ont dû être récrits à grands frais.09/10 9
  10. 10. Intro. ✓histoire Intro. UML Démarche Et après Encapsuler, assembler, réutiliser Pour répondre à ces besoins croissants, la programmation a connu une évolution et une montée en abstraction encore plus importante :09/10 10
  11. 11. Intro. ✓histoire Intro. UML Démarche Et après Encapsuler, assembler, réutiliser Pour répondre à ces besoins croissants, la programmation a connu une évolution et une montée en abstraction encore plus importante : Objets, Composants, Services, Composants as Services, Génération des codes à partir de modèles, Frameworks, Usines logicielles, ....09/10 10
  12. 12. Intro. ✓histoire Intro. UML Démarche Et après Encapsuler, assembler, réutiliser Pour répondre à ces besoins croissants, la programmation a connu une évolution et une montée en abstraction encore plus importante : Objets, Composants, Services, Composants as Services, Génération des codes à partir de modèles, Frameworks, Usines logicielles, .... Mais le plus important des changements de «méthodes» de développement...09/10 10
  13. 13. I. Quels sont les problèmesdu développement logiciel? Du bidouillage au génie logiel 11
  14. 14. Intro. Intro. UML Démarche Problématique du génie logiciel ➡ Programming-in-the-Small Problème de la qualité interne dun composant ➡ Programming-in-the-Large Faire face à la construction de systèmes de plus en plus gros : non spécifique au logiciel, mais aggravé par sa “mollesse”. Problème de gestion de la complexité, de communication, etc. Maîtrise du processus de développement: délais, coûts, qualité. Programming-in-the-Duration Problème de la maintenance corrective et évolutive. Notion de ligne de produits. Pr. Jean-Marc Jézéquel09/10 12
  15. 15. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche Programming-in-the-Small Problème de la validité du logiciel Acquérir une valeur positive n Tant que n > 1 faire si n est pair alors n := n / 2 Prouver que le prog. termine pour tout n? sinon n := 3n+1 -> Indécidabilité de certaines propriétés Sonner alarme; Recours au test – ici, si machine 32 bits, 2^31 = 10^10 cas de tests – 5 lignes de code => 10 milliards de tests ! Pr. Jean-Marc Jézéquel09/10 13
  16. 16. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche Programming-in-the-Small Produire des programmes prouvés C’est possible… On peut construire des programmes de tel manière qu’ils soient prouvables En partie automatisable (Atelier B, etc.) Outils spécifiques …mais coûteux Preuve au moins aussi complexe que le code Autant de chances de se tromper dans la preuve… En pratique : Réservé à des (petits) sous-systèmes (très) critiques Recours aux tests pour le reste09/10 14
  17. 17. Intro. ✓Prog. Small ✓Validation Intro. UML Démarche Programming-in-the-Small Syntaxe JML Préconditions : /** Ce qui doit être satisfait * @param double x réel positif pour appeler la méthode * @result double racine carrée de x */ /*@ @ requires x >= 0.0 ; Assertions @ ensures x == result * result ; @*/ public static double sqrt(double x) { Postconditions : Ce qui est satisfait en cas de retour normal Invariant = propriété toujours vraie quelque soit l’état du système09/10 15
  18. 18. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche Programming-in-the-Large Gérer la complexité due à la taille a) c) b) d) Si lautomobile avait suivi le même développement que lordinateur, une Rolls-Royce coûterait aujourdhui 100$, pourrait rouler un million de kilomètres avec un litre dessence, et exploserait une fois par an en tuant tout le monde à bord. Robert Cringely. Pr. Jean-Marc Jézéquel09/10 16
  19. 19. Intro. Intro. UML Démarche Exemple Windows Vista … 65 millions de lignes de code, 6 années de développement, 9000 développeurs (54 000 années développeurs) http://www.clubic.com/article-66145-1-microsoft-windows-vista-rtm-dossier.html … sur les vingt années dexistence de Windows, Vista aura été le système dexploitation dont le cycle de développement fut le plus long ! Et pour cause, puisquaprès avoir démarré le développement de Longhorn en 2001, Microsoft a du remettre à plat lintégralité du projet en 2004, réalisant alors que celui-ci était par trop complexe et tentaculaire. En repartant de zéro, Microsoft a entièrement révisé son cahier des charges en supprimant au passage certaines fonctionnalités pourtant très attendues de Vista ; on pense bien sûr au système de fichiers WinFS qui est ainsi tombé purement et simplement aux oubliettes. Cest au maître dœuvre de Vista, Jim Allchin, que lon doit cette décision, certainement très difficile à prendre vu ses implications pour lépoque. Lorsque, fin 2004, les équipes à la tête de Microsoft décident de repartir de zéro, cest pratiquement tout le travail des 9 000 développeurs mobilisés sur Windows Vista qui est à recommencer…09/10 17
  20. 20. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche Programming-in-the-Large Augmentation exponentielle de la taille du logiciel09/10 18
  21. 21. Intro. ✓Prog. Large ✓Complexité Intro. UML Démarche Programming-in-the-Large Echecs logiciels Premier vol d’Ariane 5 (1996) ATT (1990): interruption du service téléphonie pendant 5 heures à lEst des Etats-Unis. Aéroport de Denver, 1993-1995: logiciel de suivi des bagages, coût 3 milliards de $, retard de 18 mois. National Cancer Institute, Panama City,2000 : Logiciel non adapté aux médecins => 8 morts, 20 personnes Out of range “surexposées”. etc., etc.09/10 19
  22. 22. Intro. ✓Prog. Large ✓Diviser Intro. UML Démarche Gestion de la complexité due à la taille : diviser pour résoudre Aspects techniques en sappuyant techniquement sur la modularité « Encapsulation et masquage dinformation, faible couplage » Importance de la notion d’Objets Aspects organisationnels S’organiser au delà de la réalisation : méthodes « Analyse, conception » « Validation et vérification » Ingénierie de la conduite de projet = compromis entre respect des délais respect des coûts réponse aux besoins/assurance qualité Problèmes de gestion de ressources (humaines, etc.) et de synchronisation entre tâches09/10 20
  23. 23. Intro. ✓Prog. Durée Intro. UML Démarche Programming-in-the-Duration Gestion de l’évolution dun système D’après Swanson & Beath (Maintaining Information Systems in Organizations, 1989) Durée de vie moyenne d’un système : 6.6 ans 26% des systèmes sont âgés de plus de 10 ans Problème de la maintenance corrective et évolutive Adaptation aux changements des besoins Adaptation aux changements de l’environnement Support nouvelles plateformes, bug « an 2000 »09/10 21
  24. 24. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche Programming-in-the-Duration Problème de la maintenabilité Exemple critique dû à M. Jackson Barques à louer sur un lac Enregistrement des départs (S) et retours (E) sur un terminal, avec horodatage automatique On veut chaque jour un rapport avec : le nombre de sessions la durée moyenne dune session09/10 22
  25. 25. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche Programming-in-the-Duration Approche « droit au but » Décomposition fonctionnelle en 1980 Structured Analysis and Design technique : SADT Le système a une fonction… Décomposée récursivement en sous-fonctions… Jusqu’à tomber sur des fonctions élémentaires Reliées par flots de données ∑(09/10 23
  26. 26. Intro. ✓Prog. Durée ✓Maintenance Intro. UML Démarche Programming-in-the-Duration Réalisation currentTime; currentTime;09/10 24
  27. 27. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche Programming-in-the-Duration Maintenance Demandes de modifications : durée de la session la plus longue un état pour le matin, un autre pour le soir corriger la perte de S ou de E09/10 25
  28. 28. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche Programming-in-the-Duration Maintenance Demandes de modifications : durée de la session la plus longue un état pour le matin, un autre pour le soir corriger la perte de S ou de E Dans la réalité, c’est pire! Nokia rapporte à propos de son infrastructure GSM 50% des exigences (besoins numérotés) ont changé après le gel du cahier des charges 60% de ceux-ci ont changé au moins 2 fois! C’est le cas général plutôt que l’exception Cahier des charges figé = rêve des années 7009/10 25
  29. 29. Exemple Windows Vista …Vista prêt à en découdre avec les failles de sécurité!Cest inévitable. La découverte de failles devrait saccélérer avec le lancement engrandeur réelle de Windows Vista. Microsoft sy prépare……«  Les failles sont inhérentes au développement logiciel. Elles reposent sur deserreurs de programmation. Or, détecter absolument toutes les erreurs estimpossible même avec des moyens financiers comme ceux dont disposeMicrosoft »…8 000 dollars pour chaque trou de sécurité!… Idefense Labs, une filiale de Verisign, va encore plus loin. Elle promet8 000 dollars (assortis dun bonus oscillant entre 2 000 et 4 000 dollars selon laqualité des explications fournies) à qui découvrira une faille critique dans Vista ouInternet Explorer 7…… « La démarche est pertinente dans la mesure où elle permet de mobiliser leschercheurs du monde entier à moindre frais »… 26 Grimaldi 2010
  30. 30. Intro. ✓Prog. Durée✓Maintenance Intro. UML Démarche Programming-in-the-Duration Coût de la Maintenance09/10 27
  31. 31. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche La découpe fonctionnelle dun problème informatique : une approche intuitive Factorisation09/10 28
  32. 32. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Le revers de la médaille : maintenance complexe en cas dévolution09/10 29 ->
  33. 33. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Le revers de la médaille : maintenance complexe en cas dévolution La séparation des données et des traitements : le piège !09/10 29 ->
  34. 34. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Réunir données et traitements : Programmation par objets09/10 30
  35. 35. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Vision objet du système informatique (1) ➡ Le système d ’informatique est modélisé comme un ensemble d ’objets, avec leurs propriétés et leurs comportements, qui collaborent entre eux• Un objet est une entité aux frontières précises• Un ensemble dattributs caractérise létat de lobjet.• Un ensemble dopérations (méthodes ou comportements) en définit lecomportement.09/10 31
  36. 36. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Vision objet du système informatique (2) ➡ Un objet est une instance de classe (une occurrence dun type abstrait). ➡ Une classe est un type de données abstrait (modèle) , caractérisé par des propriétés (attributs et méthodes) communes à des objets et permettant de créer des objets possédant ces propriétés.09/10 32
  37. 37. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Vision objet du système informatique (3) ➡ Héritage (et polymorphisme) Lhéritage est un mécanisme de transmission des propriétés dune classe (ses attributs et méthodes) vers une sous- classe.09/10 33
  38. 38. Intro. ✓Prog. Durée ✓Vers l’objet Intro. UML Démarche Vision objet du système informatique (4) ➡ Héritage (et polymorphisme) Le polymorphisme représente la faculté dune méthode à pouvoir sappliquer à des objets de classes différentes.09/10 34
  39. 39. Intro. Intro. UML Démarche Approche orientée-objet Illustration de Jean-Marc Estay (IMA)09/10 35
  40. 40. Intro. ✓Prog. Durée Intro. UML Démarche Programming-in-the-Duration Solution : approche par modélisation Aspects techniques Assurer une meilleure continuité entre Domaine du problème Domaine des solutions Définir les fonctionnalités Prévoir les scénarios de tests Maintenance traitée comme le développement initial Aspects organisationnels Traçabilité Utilisation de Gestion contrôlée des changements Méthodes «Agiles»09/10 36
  41. 41. Intro. Intro. UML Démarche Problématique du génie logiciel WHAT IS SOFTWARE ENGINEERING? The IEEE Computer Society defines software engineering as “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).” http://www.swebok.org/09/10 37
  42. 42. III. Introduction à UML 38
  43. 43. III. Introduction à UML UML, histoire, généralité 39
  44. 44. Intro. Intro. UML ✓Histoire Démarche Pourquoi UML ? ➡ Objectifs : spécifier, construire, visualiser et documenter les systèmes à base de logiciel Pour communiquer, travailler à plusieurs Pour comprendre la « big picture » Par approche orientée objets Avec différents modèles pour différentes vues ➡ UML : Langage et non simple notation graphique (ni méthode) ➡ UML est Indépendant des méthodologies09/10 40
  45. 45. Intro. Intro. UML ✓Histoire Démarche Un peu d’histoire : La guerre des Méthodes Booch, OMT, Coad/Yourdon, Fusion,SADT, OOSE, Schlaer/Mellor, HOOD… UML: un méta-langage de modélisation pour unifier les modèles utilisés dans les méthodes09/10 41
  46. 46. Intro. Intro. UML ✓Histoire Démarche Et un langage unique, un ! Un cocktail de notations éprouvées. (...mais pas toutes, p. ex. RdP, SADT/IDEF0, DFD, etc.) Auteurs : Grady Booch, Ivar Jacobson, James Rumbaugh. Standardisation OMG (Object Management Group) en 1997 Promoteurs : Rational Software, Oracle Hp, Microsoft, IBM09/10 42
  47. 47. Intro. Intro. UML ✓Histoire Démarche http://www.omg.org/spec/UML/2.3/Superstructure/PDF/ 758 pages UML 2.3 May 2010 Commentaires du public09/10 43
  48. 48. Intro. Intro. UML ✓Histoire Démarche Ingénierie Électrique Ingénierie du Bâtiment Ingénierie Ingénierie09/10 Mécanique 44 Logicielle Grimaldi 2010
  49. 49. Intro. Intro. UML Démarche Qu’est-ce qu’UML ? un support à la modélisation ➡ Modèle : simplification de la réalité dont les buts sont Visualiser Spécifier la le système structure et le comportement du système Aider à la construction Documenter du système les décisions09/10 45
  50. 50. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? ➡ UML est un langage «visuel» ➡ Il supporte La visualisation La spécification La construction La documentation Jean-Paul Rigault 200509/10 46
  51. 51. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? ➡ UML est un langage «visuel» ➡ Il supporte La visualisation Syntaxe et sémantique La spécification Descriptions graphiques et textuelles La construction Architecture et comportement Génération de code La documentation Jean-Paul Rigault 200509/10 46
  52. 52. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? ➡ UML est un langage «visuel» ➡ Il supporte La visualisation Syntaxe et sémantique La spécification Descriptions graphiques et textuelles La construction Architecture et comportement Génération de code La documentation On ne décrit pas l’univers tout entier… Le logiciel joue un rôle majeur Jean-Paul Rigault 200509/10 46
  53. 53. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? ➡ UML est un langage «visuel» ➡ Il supporte La visualisation Syntaxe et sémantique La spécification Descriptions graphiques et textuelles La construction Architecture et comportement Génération de code La documentation On ne décrit pas l’univers tout entier… Le logiciel joue un rôle majeur  UML n’est pas une méthodologie de développement, contrairement à RUP (Rational Unified Process). Jean-Paul Rigault 200509/10 46
  54. 54. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? Axes de modélisation d’un système Statique (ce que le système EST) Dynamique (comment le système Fonctionnel EVOLUE) (ce que le système FAIT)09/10 47
  55. 55. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? Axes de modélisation d’un système Statique (ce que le système EST) • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Dynamique (comment le système Fonctionnel EVOLUE) (ce que le système FAIT)09/10 47
  56. 56. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? Axes de modélisation d’un système Statique (ce que le système EST) • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Dynamique (comment le système Fonctionnel EVOLUE) (ce que le système FAIT) • diagramme de cas d’utilisation • diagramme de collaboration09/10 47
  57. 57. Intro. Intro. UML ✓Histoire Démarche Qu’est-ce qu’UML ? Axes de modélisation d’un système Statique (ce que le système EST) • diagramme de classes • diagramme d’objets • diagramme de composants • diagramme de déploiement Dynamique (comment le système Fonctionnel EVOLUE) (ce que le système • diagramme de séquences FAIT) • diagramme de collaboration • diagramme de cas d’utilisation • diagramme d’états-transitions • diagramme de collaboration • diagramme d’activités09/10 47
  58. 58. Intro. Intro. UML ✓Histoire Démarche Les points forts dUML UML est un langage normalisé gain de précision gage de stabilité encourage lutilisation doutils UML est un support de communication performant Il cadre lanalyse. Il facilite la compréhension de représentations abstraites complexes. Son caractère polyvalent et sa souplesse en font un langage universel.09/10 48
  59. 59. Intro. Intro. UML ✓Histoire Démarche Les points faibles dUML La mise en pratique dUML nécessite un apprentissage et passe par une période dadaptation. Le processus (non couvert par UML) est une autre clé de la réussite dun projet.09/10 49
  60. 60. III. Introduction à UML survol 50
  61. 61. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes des cas d’utilisation Ce diagramme montre ce que que fait le système et qui l’utilise Entrer DébloquerLesPortes PorteurDeCarte Capteur AIncendie Sortir ListerLes TentativesDeFraudes GérerLesCartes Gardien Administrateur SystèmeDeContrôleDAcces09/10 51
  62. 62. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes de séquence Ce diagramme montre les flots de communications paul le distrib. la carte de P. la reserve la banque le compte de P. retirer(500) lireN°Compte() retirerDeLArgent(500,88219) débiter(500) sortirDesBillets(5) sortirBillets ()09/10 52
  63. 63. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes de collaboration 6 : prendreBillet() la reserve de billets 5 : sortirDesBillets(5) 1 : retirer(500) 3 : retirerDeLArgent 4 : débiter(500) le distributeur (500,88219) la banque paul 88219 2 : lireN°Compte() le compte de paul la carte de P.09/10 53
  64. 64. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes de classes Compte Banque 1..4 1..* 1..* 1..* Client numéro titulaires numéro solde nom 1 signataire ... 0..* 1 Consortium CarteBleue 0..* 0..* 1 Code retraitMax AcceptéPar> 0..* Distributeur 1..* Ce diagramme montre les classes et les relations entre elles09/10 54
  65. 65. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes d’objets EstAcceptéPar> : Distributeur : CarteBleue signataire titulaires fred : Client c4 : Compte : Banque : Consortium : CarteBleue signataire paul : Client c1 : Compte : Banque titulaires titulaires pierre : Client c2 : Compte : Consortium titula ires titulaires marie : Client c3 : Compte : Banque signataire : CarteBleue EstAcceptéPar> Ce diagramme montre les instances sophie : Client EstAcceptéPar> : Distributeur et les liens entre elles à l’exécution.09/10 55
  66. 66. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Diagrammes d’états carte insérée En attente En attente du code carte retirée mauvais code code frappé En attente retrait carte En vérification code bon Pour expliciter les attentes montant incorrect En attente du montant d’évènements & les différents montant correct états d’un objet. billets retirés En distribution09/10 56
  67. 67. Intro. Intro. UML ✓Survol Démarche Qu’est-ce qu’UML ? Divers modes d’utilisation ➡ Mode esquisse (sketch) Informelle, incomplète Souvent manuelle (tableau) ➡ Mode plan (blue print) Diagrammes détaillés Production de documents Pro- et rétro-ingénierie ➡ Mode langage de programmation Spécification complète et exécutable Pas vraiment disponible actuellement ! Jean-Paul Rigault 200509/10 57
  68. 68. Intro. Intro. UML ✓Survol De Merise à UML Unified Process (UP) ➡ UML se veut indépendant de toute méthodologie ➡ Cependant, il est mieux adapté à un processus (tel le RUP) dirigé par les cas d’utilisation (use-case driven) centré sur l’architecture (architecture centric) itératif et incrémental ➡ Le UP propose en outre des techniques de modélisation pour les différentes phases et activités une organisation des rôles et des flots lors du processus de développement A venir dans09/10 58 le cours
  69. 69. V. Démarche générale suivie dans le cadre de ce module 59
  70. 70. Intro. Intro. UML Démarche Approche dirigée par les cas09/10 60
  71. 71. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire09/10 60
  72. 72. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier.09/10 60
  73. 73. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire.09/10 60
  74. 74. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système09/10 60
  75. 75. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système 5. Capturer les concepts du domaine09/10 60
  76. 76. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système 5. Capturer les concepts du domaine 6. A chaque flux sera associé un diagramme de séquence qui mettra en avant laspect temporel des interactions entre les objets de lapplication qui participent au scénario09/10 60
  77. 77. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système 5. Capturer les concepts du domaine 6. A chaque flux sera associé un diagramme de séquence qui mettra en avant laspect temporel des interactions entre les objets de lapplication qui participent au scénario 7. Ces diagrammes serviront alors de base à la construction des diagrammes de séquence de conception et des diagrammes de classes qui visualisent larchitecture du logiciel, la hiérarchie et les associations entre classes09/10 60
  78. 78. Intro. Intro. UML Démarche Approche dirigée par les cas 1. Établir le dictionnaire 2. Identification des acteurs qui agissent sur le système à étudier. 3. Définition et description des cas dutilisation qui montreront les interactions entre les acteurs actifs externes et le système vu comme une boîte noire. 4. Pour chaque cas dutilisation seront décrits les principaux flux qui visualisent la chronologie des échanges entre les acteurs et le système 5. Capturer les concepts du domaine 6. A chaque flux sera associé un diagramme de séquence qui mettra en avant laspect temporel des interactions entre les objets de lapplication qui participent au scénario 7. Ces diagrammes serviront alors de base à la construction des diagrammes de séquence de conception et des diagrammes de classes qui visualisent larchitecture du logiciel, la hiérarchie et les associations entre classes 8. La structure de la BD peut alors être abordée.09/10 60
  79. 79. Exemple: Une ludothèque 61
  80. 80. Intro. Intro. UML Démarche Ludothèque Les adhérents peuvent emprunter des jeux en s’adressant à un conseiller qui enregistre l’emprunt. Les jeux empruntés sont rendus à un conseiller.... Un adhérent peut réserver des jeux. Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Pour organiser un événement le conseiller spécialisé doit alors donner les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Un adhérent peut s’inscrire pour participer à un événement à condition qu’il y ait encore de la place. Un adhérent peut payer sa cotisation en ligne par un système de paiement externe Un internaute peut consulter les jeux et s’inscrire.09/10 62
  81. 81. Intro. Intro. UML Démarche Ludothèque Les adhérents peuvent emprunter des jeux en s’adressant à un conseiller qui enregistre l’emprunt. Les jeux empruntés sont rendus à un conseiller.... Un adhérent peut réserver des jeux. Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Pour organiser un événement le conseiller spécialisé doit alors donner les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Un adhérent peut s’inscrire pour participer à l’événement en en faisant la demande à un conseiller spécialisé, à condition qu’il y ait encore de la place. Un adhérent peut payer sa cotisation en ligne par un système09/10 de paiement externe 63
  82. 82. Intro. Intro. UML Démarche Ludothèque : Dictionnaire Adhérents : Personne connue du système par son nom, prénom, date de naissance, adresse postale, date du dernier paiement de la cotisation et adresse email éventuelle. Conseiller : Personne identifiée qui a des droits sur le système. Réservation : Une réservation précise l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti quand le jeu revient en rayon. Evénement : temps de démonstration et de jeux organisé à l’avance. Il précise les informations suivantes : les jeux à tester, le nombre maximal et minimal de participants attendus, la date, et l’heure de début de l’événement. Jeux : Un jeu est caractérisé par un identifiant, un nombre de joueurs, ...09/10 64
  83. 83. Intro. Intro. UML Démarche Acteurs et diagramme de contexte09/10 65
  84. 84. Intro. Intro. UML Démarche Diagramme de cas d’utilisation09/10 66
  85. 85. Intro. Intro. UML Démarche 4) Description complète dun cas d’utilisation Emprunter un jeu Acteurs : Conseiller Objectif : Décrire l’emprunt d’un jeux par un Conseiller Aperçu : Un Conseiller passe le lecteur de code barre sur le jeu; Le Conseiller saisit l’identifiant de l’adhérent. Le système vérifie la droit d’emprunter de l’adhérent. Il enregistre l’emprunt.09/10 67
  86. 86. Intro. Intro. UML Démarche 5) Capturer les concepts du domaine Emprunter un jeu Acteurs : Conseiller Objectif : Décrire l’emprunt d’un jeux par un Conseiller Aperçu : Un Conseiller passe le lecteur de code barre sur le jeu; Le Conseiller saisit l’identifiant de l’adhérent. Le système vérifie la droit d’emprunter de l’adhérent. Il enregistre l’emprunt.09/10 68
  87. 87. Intro. Intro. UML Démarche 5) Capturer les concepts du domaine09/10 69
  88. 88. Intro. Intro. UML Démarche Scénarios : Niveau Analyse09/10 70
  89. 89. Intro. Intro. UML Démarche Scénarios : Niveau Conception09/10 71
  90. 90. Intro. Intro. UML Démarche Diagramme de classes : Niveau Conception09/10 72
  91. 91. Intro. Intro. UML Démarche Diagramme de classes : Niveau Conception : Tables (partiel)09/10 73
  92. 92. Exemple: Une galerie d’art virtuelle 74
  93. 93. Intro. Intro. UML Démarche Bibliographie Ce cours a été monté en utilisant de nombreux supports dont je remercie chaleureusement ici les auteurs D’autres références se trouvent sur le site du module. Merise: 5ème Partie Dossier "SAM lInformaticien" du 5 Mars au 18 Mars 2001 par Stéphane Lambert http://www.vediovis.fr/index.php?page=merise5 Introduction au langage UML, SUPINFO De Merise à UML, Nasser Kettani, Dominique Mignet, Eyrolles http://www.compucycles.com/nouveausite/articles/Merise/Article_07.htm UML-MERISE Etude Comparative, OSITEC-Consultants, 2004-2005 Modélisation Orientée objet, M.Grimaldi – janvier 201009/10 75

×