Cours uml

1,944 views

Published on

cours uml

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,944
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
186
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cours uml

  1. 1. Modélisation objet avec UML Pierre-Alain Muller pa.muller@essaim.univ-mulhouse.fr ESSAIM, 12 rue des Frères Lumière 68093 Mulhouse CedexVersion 2.0 1 Pierre-Alain Muller
  2. 2. Au menu• La genèse d’UML• Un survol d’UML• La notation UML• Vers un processus unifié• La suite de l’histoireVersion 2.0 2 Pierre-Alain Muller
  3. 3. La genèse d’UMLVersion 2.0 3 Pierre-Alain Muller
  4. 4. Complexité des logiciels• Les tendances – Programmation sans programmer – Micro-architectures (patterns) – Importance de l’architecture – Informatique distribuée – MultimédiaVersion 2.0 4 Pierre-Alain Muller
  5. 5. De quoi a-t-on besoin ?• Un langage de modélisation – Notation claire – Sémantique précise• Un processus de génie logiciel Système Langage ProcessusVersion 2.0 5 Pierre-Alain Muller
  6. 6. Langage de modélisation• Générique• Expressif• Flexible (configurable, extensible)• Syntaxe et sémantique• Unification par convergence aujourd’huiVersion 2.0 6 Pierre-Alain Muller
  7. 7. Processus• Générique• Impossible à standardiser – Personnes, applications, cultures...• Cadre configurable• Unification par convergence dans le futurVersion 2.0 7 Pierre-Alain Muller
  8. 8. Comment modéliser ?• La manière de modéliser influence fortement – La compréhension du problème – La solution• Il n’existe pas de modèle universel – Jeux de modèles faiblement couplés – Multiplicité des niveaux d’abstraction• Les meilleurs modèles sont en prise sur le monde réelVersion 2.0 8 Pierre-Alain Muller
  9. 9. Evolution des méthodes• D’abord des méthodes structurées• A partir des années 80 émergence des méthodes orientées-objets• Les principales méthodes objets convergent – Différences superficielles – Notation, terminologie• L’expérience permet de séparer le bon grain de l’ivraieVersion 2.0 9 Pierre-Alain Muller
  10. 10. La prolifération des méthodes objet• Une cinquantaine de méthodes objet dans les cinq dernières années – Confusion, attentisme• Consensus autour d’idées communes – Objets, classes, associations, sous-systèmes, cas d’utilisationVersion 2.0 10 Pierre-Alain Muller
  11. 11. Rapprochement de Booch et OMT• Booch’93 et OMT-2 sont plus ressemblantes que différentes – Booch’93 adopte les associations, les diagrammes dHarel, les traces d’événements – OMT-2 introduit les flots de messages et retire les diagrammes de flot de données• Booch-93 construction• OMT-2 analyse et abstraction Version 2.0 11 Pierre-Alain Muller
  12. 12. L’unification des méthodes• La guerre des méthodes ne fait plus avancer la technologie des objets• Recherche d’un langage commun unique – Utilisable par toutes les méthodes – Adapté à toutes les phases du développement – Compatible avec toutes les techniques de réalisationVersion 2.0 12 Pierre-Alain Muller
  13. 13. Différentes sortes de systèmes• Logiciels – Ingénierie des logiciels• Logiciels et matériels – Ingénierie des systèmes• Personnes – Ingénierie des affairesUnification sur plusieurs domaines d’applications Version 2.0 13 Pierre-Alain Muller
  14. 14. La notation unifiée• Basée sur les méthodes de BOOCH, OMT et OOSE• Influencée par les bonnes idées des autres méthodes• Mûrie par le travail en communVersion 2.0 14 Pierre-Alain Muller
  15. 15. Principales influences • Souvent une histoire imbriquéeBooch Catégories et sous-systèmesEmbley Classes singletons et objets compositesFusion Description des opérations, numérotation des messagesGamma, et al.Frameworks, patterns, et notesHarel Automates (Statecharts)Jacobson Cas d’utilisation (use cases)Meyer Pré- et post-conditionsOdell Classification dynamique, éclairage sur les événementsOMT AssociationsShlaer-MellorCycle de vie des objetsWirfs-Brock Responsabilités (CRC) Version 2.0 15 Pierre-Alain Muller
  16. 16. Portée de la notation unifiée• Standardiser les artefacts du développement – Modèles, notation et diagrammes• Ne pas standardiser le processus – Dirigé par les cas d’utilisation – Centré sur l’architecture – Itératif et incrémentalVersion 2.0 16 Pierre-Alain Muller
  17. 17. Les objectifs• Représenter des systèmes entiers• Etablir un couplage explicite entre les concepts et les artefacts exécutables• Prendre en compte les facteurs d’échelle• Créer un langage de modélisation utilisable à la fois par les humains et les machinesVersion 2.0 17 Pierre-Alain Muller
  18. 18. Approche retenue• Identifier la sémantique des concepts de base• Classer les concepts• Construire un métamodèle• Choisir une notation graphique• Regrouper par niveau d’abstraction, complexité et domaineVersion 2.0 18 Pierre-Alain Muller
  19. 19. Métamodèle• Identification des concepts fondamentaux – Définition de la sémantique de ces concepts – Choix d’une représentation graphique• Métamodélisation d’UML avec UML – Description formelle des éléments de modélisation• Austère, pas pédagogique – Méthodologistes – Constructeurs d’outils Version 2.0 19 Pierre-Alain Muller
  20. 20. Les modèles et les vues• Un modèle est un quanta de développement – Cohérence interne forte – Couplage faible avec les autres modèles – Relié à une phase de développement• Une vue est une projection au travers des éléments de modélisation – Graphique – Peut englober plusieurs modèlesVersion 2.0 20 Pierre-Alain Muller
  21. 21. Exemples de modèles• Un système possède plusieurs modèles Système Modèle Modèle Modèle Modèle d’analyse de conception de réalisation de déploiementVersion 2.0 21 Pierre-Alain Muller
  22. 22. Les étapes• Octobre 95 – Unified Method V0.8• Octobre 96 – UML V0.91 (The Unified Modeling Language for Object-Oriented Development)• Janvier 97 – UML 1.0 est soumise à l’OMG• Septembre 97 – Approbation par le comité technique de l’OMGVersion 2.0 22 Pierre-Alain Muller
  23. 23. Evolution de UMLVersion 2.0 23 Pierre-Alain Muller
  24. 24. Acceptation de UML• UML est dans le domaine public• Soutenue par le marché – Microsoft, HP, IBM, Oracle...• Successeur naturel des méthodes de Booch, OMT et OOSE• UML est le fruit de l’expérience et des besoins de la communauté des utilisateursVersion 2.0 24 Pierre-Alain Muller
  25. 25. Les partenaires• Courant 96 UML devient un enjeu stratégique• Consortium de partenaires – DEC, HP, i-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI et Unisys – IBM, Platinum, Data Access Technologies, Reich Technologies, Softeam, Taskon A/SVersion 2.0 25 Pierre-Alain Muller
  26. 26. En résumé• 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 dans le domaine publicVersion 2.0 26 Pierre-Alain Muller
  27. 27. Un survol d’UMLVersion 2.0 27 Pierre-Alain Muller
  28. 28. Eléments de modélisation• Briques pour capturer la sémantique des applications• Pas accessibles directement aux utilisateurs• Représentation interne (outils)• Représentation externe (échange entre outils)Version 2.0 28 Pierre-Alain Muller
  29. 29. Eléments de modélisation• Les objets – Une entité d’un monde réel ou virtuel• Les classes – La description d’un ensemble d’objets• Les états – Une étape de la vie d’un objet• Les tâches – Un flot de contrôle indépendantVersion 2.0 29 Pierre-Alain Muller
  30. 30. Eléments de modélisation• Les cas d’utilisation – Une manière dont un acteur utilise le système• Les collaborations – La réalisation d’un cas d’utilisation par une société d’objets collaborants• Les micro-architectures (patterns) – Un générateur pour la structure et l’interaction d’une société d’objetsVersion 2.0 30 Pierre-Alain Muller
  31. 31. Eléments de modélisation• Les composants – Un module contenant des entités d’implémentation• Les noeuds – Un dispositif matériel capable d’exécuter du logiciel• Les paquetages – Une partition du modèle• Les notes – Un commentaire, une explication ou une annotation Version 2.0 31 Pierre-Alain Muller
  32. 32. Relations• L’association – Une connexion sémantique entre instances• La généralisation – Une relation de classification• La dépendance – L’utilisation d’un élément par un autre• La trace – Dépendance inter-modèlesVersion 2.0 32 Pierre-Alain Muller
  33. 33. Mécanismes communs• Les stéréotypes <<stéréotype>> – Extension des classes du métamodèle• Les étiquettes – Paire (nom, valeur)• Les notes – Commentaire textuel• Les contraintes {contrainte} – Relation sémantique entre élémentsVersion 2.0 33 Pierre-Alain Muller
  34. 34. Types primitifs Booléen Liste Expression Multiplicité Point Chaîne Temps Nom Non interprétéVersion 2.0 34 Pierre-Alain Muller
  35. 35. La notation UMLVersion 2.0 35 Pierre-Alain Muller
  36. 36. Notation • Manipulée par les utilisateurs • Simple, intuitive, expressive, cohérente • Vues graphiques (multiples) des éléments de modélisationVersion 2.0 36 Pierre-Alain Muller
  37. 37. Les diagrammes d’UML• 9 types de diagrammes Diagramme Composants Classes Séquence Activité Objets Déploiement Cas d’utilisation Etats-Transitions CollaborationVersion 2.0 37 Pierre-Alain Muller
  38. 38. Diagrammes• Les diagrammes de classes – Les classes et les relations statiques• Les diagrammes d’objets – Les objets et les liens• Les diagrammes de séquence – Vision temporelle des interactions• Les diagrammes de collaboration – Vision spatiale des interactions Version 2.0 38 Pierre-Alain Muller
  39. 39. Diagrammes (suite)• Les diagrammes de cas d’utilisation – Les acteurs et l’utilisation du système• Les diagrammes d’états-transitions – Le comportement des objets• Les diagrammes d’activités – Le flot de contrôle interne aux opérationsVersion 2.0 39 Pierre-Alain Muller
  40. 40. Diagrammes (suite)• Les diagrammes de composants – Les composants d’implémentation et leurs relations• Les diagrammes de déploiement – La structure matérielle et la distribution des objets et des composantsVersion 2.0 40 Pierre-Alain Muller
  41. 41. Paquetages• Organisation des modèles Nom de paquetage Cat Sub <<Catégorie>> <<Sous-système>>Version 2.0 41 Pierre-Alain Muller
  42. 42. Diagrammes de classes • Les classes Nom de classe Nom de classe Nom de classe Véhicule <<Utilitaire>> <<Stéréotype>> Etat = testé Propriété Auteur = pamVersion 2.0 42 Pierre-Alain Muller
  43. 43. Diagrammes de classes• Les attributs et les opérations Nom de classe A Nom : type = valeur initiale +Attribut public #Attribut protégé Nom( ) -Attribut privé Attribut de classe +Opération publique( ) #Opération protégée( ) -Opération privée( ) Opération de classe( )Version 2.0 43 Pierre-Alain Muller
  44. 44. Diagrammes de classes• Les associations A B A B C D EVersion 2.0 44 Pierre-Alain Muller
  45. 45. Diagrammes de classes• Décoration des associations <Travaille pour Société Personne Pilote Société Employeur Personne Avion Personne Employé PassagersVersion 2.0 45 Pierre-Alain Muller
  46. 46. Diagrammes de classes• Multiplicité des associations –1 un et un seul – 0..1 zéro ou un – m..n de m à n –* de zéro à plusieurs – 0..* de zéro à plusieurs – 1..* d’un à plusieursVersion 2.0 46 Pierre-Alain Muller
  47. 47. Diagrammes de classes• Exemples Personne Parents 2 Personne Compte Enfants * 1 0..* {Ordonnée} Parents délèves Classe Personne * {Sous-ensemble} * DéléguésVersion 2.0 47 Pierre-Alain Muller
  48. 48. Diagrammes de classes• Restriction des associations (qualification) A Clé B Echiquier Ligne Ligne Case Colonne Colonne 1Version 2.0 48 Pierre-Alain Muller
  49. 49. Diagrammes de classes• Les classe-associations A B C attributs D opérations( )Version 2.0 49 Pierre-Alain Muller
  50. 50. Diagrammes de classes• Les agrégations – Connexions bidirectionnelles non symétriques 1 Voiture Moteur 1 Parent Propriétaire Personne 1..* Personne Immeuble * 0..* Enfants * 0..1 Agrégat Composant <S’occupe de *Version 2.0 50 Pierre-Alain Muller
  51. 51. Diagrammes de classes• Généralisation simple et multiple Super-classe Classe plus générale Sous-classe Classe plus spécialiséeVersion 2.0 51 Pierre-Alain Muller
  52. 52. Diagrammes de classes• Les discriminants partitionnent les sous-classes Animal Station Protection Nourriture Bipède Quadrupède Herbivore Carnivore A plumes A poils A écailles LapinVersion 2.0 52 Pierre-Alain Muller
  53. 53. Diagrammes de classes• Exemple de contrainte Champignon {Exclusif} Agaricus Boletus Pas de mélange des dimensions Pied bleu Bolet de loupVersion 2.0 53 Pierre-Alain Muller
  54. 54. Diagrammes de classes• Relation de dépendance Liste <<Instanciation>> BAL <<Friend>> ItérateurVersion 2.0 54 Pierre-Alain Muller
  55. 55. Diagrammes de classes• Les interfaces – Jeu d’opérations ICommon IStyle Client StyleAgent ISpelling IGrammar {remote} StyleAgentVersion 2.0 55 Pierre-Alain Muller
  56. 56. Diagrammes d’objets• Représentation des objets Nom de l’objet Nom de l’objet : Classe : Classe BoutonOK : IHM::Contrôles::BoutonPoussoirVersion 2.0 56 Pierre-Alain Muller
  57. 57. Diagrammes d’objets• Représentation des objets et des liens Voiture Moteur : Voiture : Moteur 1 1 1 4: Roue : Roue : Roue : Roue RoueVersion 2.0 57 Pierre-Alain Muller
  58. 58. Diagrammes d’objets• Décorations Passagers : Personne : Bus Conducteur : Personne : DestinationVersion 2.0 58 Pierre-Alain Muller
  59. 59. Diagrammes de collaboration• Représentation spatiale d’une interaction : Ascenseur 1: Monter : Cabine 3: Fermer 2: Allumer : Porte : LumièreVersion 2.0 59 Pierre-Alain Muller
  60. 60. Diagrammes de collaboration• Représentation des messages Message Argument Argument A BVersion 2.0 60 Pierre-Alain Muller
  61. 61. Diagrammes de collaboration A• Exemples *[i :=1..n] : Message A.1, B.3 / Message B :X A B B p := Question [X>Y] : Message A AVersion 2.0 61 Pierre-Alain Muller
  62. 62. Diagrammes de collaboration• Syntaxe des envois de message – 4 : Afficher (x, y) -- message simple – 3.3.1 : Afficher (x, y) -- message imbriqué – 4.2 : âge := Soustraire (Aujourd’hui, DateDeNaissance) -- message imbriqué avec valeur retournée – [Age >= 18 ans] 6.2 : Voter () -- message conditionnel – 4.a, b.6 / c.1 : Allumer (Lampe) -- synchronisation avec d’autres flots d’exécution – 1 * : Laver () -- itération – 3.a, 3.b / 4 *||[i := 1..n] : Eteindre () -- itération parallèleVersion 2.0 62 Pierre-Alain Muller
  63. 63. Diagrammes de collaboration• Les objets actifs : Traitement de texte 2 : Ecrire 1 : Lire : Imprimante : ScannerVersion 2.0 63 Pierre-Alain Muller
  64. 64. Diagrammes de collaboration• La place de l’utilisateur 1: Venir me chercher au RDC : Personne : Ascenseur : Cabine 2: Ajouter destination RDCVersion 2.0 64 Pierre-Alain Muller
  65. 65. Diagrammes de collaboration• Représentation des patterns handler KeyboardHandler successor Chain of handler MIDIHandler Responsibility successor client handler EventHandler SequencerVersion 2.0 65 Pierre-Alain Muller
  66. 66. Diagrammes de séquence• Représentation temporelle d’une interaction Un objet Un autre objet Encore un objet Un message Un autre messageVersion 2.0 66 Pierre-Alain Muller
  67. 67. Diagrammes de séquence Un objet Un objet Un autre objet• Exemples Message Un message réflexif A B Un objet Message synchrone Créer Un autre objet Message asynchrone Détruire XVersion 2.0 67 Pierre-Alain Muller
  68. 68. Diagrammes de séquence Un objet A B C• Exemples x Message Récursion {y-x < 3 s} y Message A B {z-y < 1 s} Message z t Message {t’-t < 2 s} t’ A B while X Message loop end loopVersion 2.0 68 Pierre-Alain Muller
  69. 69. Diagrammes d’états-transitions• Représentation des automates – Statecharts (David Harel) Classe Automate 1 0..1 Etat intermédiaire Etat initial Etat final A BVersion 2.0 69 Pierre-Alain Muller
  70. 70. Diagrammes d’états-transitions A• Exemples Il fait trop chaud[ été ] Il fait trop chaud[ hiver ] Climatiser Aérer / Op1 Un état C entry: Op2 do: Op3 D2 exit: Op4 In on UnEvénement: Op5 A X Y / Op6 Out D1 HVersion 2.0 70 Pierre-Alain Muller
  71. 71. Diagrammes d’états-transitions• Exemples Téléviseur Basculé Attente Arrêt Basculé Télécommande Bouton enfoncé ^Téléviseur.Basculé AttenteVersion 2.0 71 Pierre-Alain Muller
  72. 72. Diagrammes d’activités• Représentation d’un automate du point de vue des activités E1 do: Activité Activité finie E2Version 2.0 72 Pierre-Alain Muller
  73. 73. Diagrammes d’activités• ExemplesVersion 2.0 73 Pierre-Alain Muller
  74. 74. Les diagrammes de cas d’utilisation• Formalisés par I. Jacobson (Use Case) Système Cas dutilisation X Acteur A Acteur B Cas dutilisation YVersion 2.0 74 Pierre-Alain Muller
  75. 75. Les diagrammes de cas d’utilisation• Relations entre cas d’utilisations Virement <<Etend>> par minitel Client distant Client local <<Utilise>> Virement IdentificationVersion 2.0 75 Pierre-Alain Muller
  76. 76. Les diagrammes de cas d’utilisation• Transition vers les objetsVersion 2.0 76 Pierre-Alain Muller
  77. 77. Diagrammes de composants• Représentation des éléments de réalisation Spécification Générique Main TâcheVersion 2.0 77 Pierre-Alain Muller
  78. 78. Diagrammes de composants 2: load The extension is called 1: invoke (URL) 3: doit via a server thread, Client Server selected from a thread pool. 4: create L 5: create ISAPI Extension 10: write response 9: write response COM Server Object COM Object 8: do some operation 6: send a message Legacy DLL Message Queue 7: handle messageVersion 2.0 78 Pierre-Alain Muller
  79. 79. Diagrammes de déploiement• Architecture matérielle et répartition du logiciel TX Console Serveur X <<TCP/IP>> Serveur 3 1 SGBD 1 1 * Imprimante PC <<RNIS>> <<Dispositif>> 1 Pilote 1 Maître Porte 1..10 *Version 2.0 79 Pierre-Alain Muller
  80. 80. Diagrammes de déploiement Node1 Node1 Module A Module B xyz abc <process> ProcWVersion 2.0 80 Pierre-Alain Muller
  81. 81. Vers un processus unifiéVersion 2.0 81 Pierre-Alain Muller
  82. 82. Objectifs• Construire des modèles de systèmes• Organiser le travail• Gérer le cycle de vie de A à Z• Gérer le risque• Obtenir de manière répétitive des produits de qualité constanteVersion 2.0 82 Pierre-Alain Muller
  83. 83. Caractéristiques du processus• Dirigé par les cas d’utilisation• Centré sur l’architecture• Itératif• IncrémentalVersion 2.0 83 Pierre-Alain Muller
  84. 84. Dirigé par les cas d’utilisation• Fil conducteur de toutes les activités Analyse Conception et Test Capturer, clarifier Réalisation Vérifier que les et valider les Réaliser les cas d’utilisation cas d’utilisation cas d’utilisation sont satisfaits Les cas d’utilisation relient ces tâches ensembleVersion 2.0 84 Pierre-Alain Muller
  85. 85. Dirigé par les cas d’utilisation Cas 1 <<Utilise>> Cas 2 Cas 3Version 2.0 85 Pierre-Alain Muller
  86. 86. Les cas d’utilisation et les tests• En Analyse – Modélisation en cas d’utilisation – Définition des cas de test• En conception – Génération des cas de test depuis les diagrammes d’interaction et les automates d’états finisVersion 2.0 86 Pierre-Alain Muller
  87. 87. Organisation du travail• Découpage par cas d’utilisation Analyse Conception et Test réalisation Architectes Intégrateurs Experts du et Concepteurs domaine Testeurs ProgrammeursVersion 2.0 87 Pierre-Alain Muller
  88. 88. Centrage sur l’architecture• Recherche de la forme générale du système dès le début• Approche systématique pour trouver une “bonne” architecture – Support des cas d’utilisation – Adaptation aux changements – Pour et avec la réutilisation – Compréhensible intuitivementVersion 2.0 88 Pierre-Alain Muller
  89. 89. Architecture logicielle• Architecture = Eléments + Formes + Motivations• Architecture = Stratégie + TactiqueVersion 2.0 89 Pierre-Alain Muller
  90. 90. La vision de l’architecte• Il n’existe pas une seule manière de regarder un système – Philippe Kruchten, le modèle 4 + 1 vues, IEEE Software, Nov. 95Version 2.0 90 Pierre-Alain Muller
  91. 91. Le modèle 4 + 1 vues• La vue logique• La vue de réalisation• La vue des processus• La vue de déploiement• La vue des cas d’utilisationVersion 2.0 91 Pierre-Alain Muller
  92. 92. La vue logique• Aspects statiques et dynamiques• Les éléments – Les objets – Les classes – Les collaborations – Les interactions – Les paquetages <<Catégorie>>Version 2.0 92 Pierre-Alain Muller
  93. 93. La vue de réalisation• Organisation des modules dans l’environnement de développement• Les éléments – Les modules – Les sous-programmes – Les tâches (en tant qu’unités de programme, comme en Ada) – Les paquetages <<sous-système>>Version 2.0 93 Pierre-Alain Muller
  94. 94. La vue des processus• Décomposition en flots d’exécution et synchronisation entre ces flots• Les éléments – Les tâches – Les threads – Les processus – Les interactionsVersion 2.0 94 Pierre-Alain Muller
  95. 95. La vue de déploiement• Les ressources matérielles et l’implantation du logiciel dans ces resources• Les éléments – Les noeuds – Les modules – Les programmes principauxVersion 2.0 95 Pierre-Alain Muller
  96. 96. La vue des cas d’utilisation• La colle entre les autres vues• Les éléments – Les acteurs – Les cas d’utilisation – Les classes – Les collaborationsVersion 2.0 96 Pierre-Alain Muller
  97. 97. Récapitulatif 9 XH GH V FD V 9 X H OR J LT X H 9 XH GH 9 XH GH V 9 XH GH G ·X WLOLV D WLR Q U p D OLV D WLR Q S UR F H V V X V G p S OR LH P H Q W LD J U D P P H $ F WH X U V GH FDV &DV G ·X WLOLV D WLR Q G ·X WLOLV D WLR Q LD J U D P P H & OD V V H V G H F OD V V H V 5 H OD WLR Q V LD J U D P P H 2 E MH WV & OD V V H V G ·R E MH WV / LH Q V 2 E MH WV / LH Q V LD J U D P P H $ F WH X U V $ F WH X U V 2 E MH WVGH Vp TXH QFH 2 E MH WV 2 E MH WV 0 H VVD JH V 0 H VVD JH V 0 H VVD JH V LD J U D P P H $ F WH X U V $ F WH X U V 2 E MH WV GH 2 E MH WV 2 E MH WV / LH Q VF R OOD E R U D WLR Q / LH Q V / LH Q V 0 H VVD JH V 0 H VVD JH 0 H VVD JH V Version 2.0 97 Pierre-Alain Muller
  98. 98. Récapitulatif (suite) 9 XH GHV FDV 9 XH ORJLTXH 9 XH GH 9 XH GHV 9 XH GH G·XWLOLVDWLRQ UpDOLVDWLRQ SURFHVVXV GpSORLHPHQW LDJUDPPH ( WDWV ( WDWV ( WDWV G·pWDWV 7UDQVLWLRQV 7UDQVLWLRQV 7UDQVLWLRQV WUDQVLWLRQV LDJUDPPH $FWLYLWpV $FWLYLWpV $FWLYLWpV G·DFWLYLWp 7UDQVLWLRQV 7UDQVLWLRQV 7UDQVLWLRQV LDJUDPPH RPSRVDQWV RPSRVDQWV RPSRVDQWV GH FRPSRVDQWV LDJUDPPH 1 RHXGV GH /LHQV GpSORLHPHQWVersion 2.0 98 Pierre-Alain Muller
  99. 99. Architecture, processus et organisation• Les processus et l’organisation doivent être adaptés à l’architecture – Un processus pour l’architecture générale – Un processus par application, composant système ou couche – Un processus par type de systèmeVersion 2.0 99 Pierre-Alain Muller
  100. 100. Une bonne architecture facilite• L’assemblage des composants pour des besoins génériques• Le partage de composants réutilisables• La navigation depuis les besoins jusqu’au code et réciproquement• La responsabilisation des développeurs• L’adaptation et l’évolutionVersion 2.0 100 Pierre-Alain Muller
  101. 101. Approche itérative et incrémentale• Segmentation du travail• Concentration sur les besoins et les risques• Les premières itérations sont des prototypes – Expérimentation et validation des technologies – Planification• Les prototypes définissent le noyau de l’architectureVersion 2.0 101 Pierre-Alain Muller
  102. 102. Approche itérative et incrémentale• L’ordonnancement des itérations est basée sur les priorités entre cas d’utilisation et sur l’étude du risqueVersion 2.0 102 Pierre-Alain Muller
  103. 103. Vue de l’encadrement• Des phases – Inception (étude d’oportunité) – Elaboration (architecture, planning) – Construction – Transition Inception Elaboration Construction Transition timeVersion 2.0 103 Pierre-Alain Muller
  104. 104. Vue technique• Des itérationsVersion 2.0 104 Pierre-Alain Muller
  105. 105. Synchronisation des deux vues• Itérations – Chaque cycle donne une génération – Chaque cycle est décomposé en phases – Chaque phase comprend des itérations• Incréments – Le logiciel évolue par incrément – Une itération correspond à un incrément – Les itérations peuvent évoluer en parallèleVersion 2.0 105 Pierre-Alain Muller
  106. 106. Synchronisation des deux vues Inception Elaboration Construction Transition Construction Construction Construction Architectural Architectural Generation 1 Conceptual Transition Prototype Prototype Release 1 Release 2 Release 3 Baseline Release Release Release Release Preliminary Architect. Architect. Devel. Devel. Devel. Transition Transition Iteration Iteration Iteration Iteration Iteration Iteration Iteration IterationVersion 2.0 106 Pierre-Alain Muller
  107. 107. Répartition des efforts Inception Elaboration Construction Transition Planning Analysis Architecture design Design Implementation Integration Test/assessment Preliminary Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration #1 #2 ... #n+1 #... #m #m+1 #m+2 ..Version 2.0 107 Pierre-Alain Muller
  108. 108. UML en résumé Un langage Vers un de modélisation processus unifié unifié • Convergence • Convergence dans aujourd’hui le futur • L’unification • Consensus autour conduit à la d’un cadre standardisation directeurVersion 2.0 108 Pierre-Alain Muller
  109. 109. La suite de l’histoireVersion 2.0 109 Pierre-Alain Muller
  110. 110. Prochaines étapes• 1 er semestre 97 – Consolidation de la proposition UML 1.0• Septembre 97 – Approbation du standard par le comité technique de l’OMGVersion 2.0 110 Pierre-Alain Muller
  111. 111. Pour en savoir plus• www.rational.com• otug@rational.com• www.essaim.univ-mulhouse.fr• uml@essaim.univ-mulhouse.fr – inscription automatique par mail à • majordomo@essaim.univ-mulhouse.fr • avec dans le corps du message : subscribe umlVersion 2.0 111 Pierre-Alain Muller
  112. 112. Pour en savoir plus• Modélisation objet avec UML – Pierre-Alain Muller, Eyrolles, 430 pages• Sommaire – Genèse d’UML – Approche objet – Notation UML – Encadrement des projets objet – Etude de cas Version 2.0 112 Pierre-Alain Muller

×