Chapitre 1 Introduction au langage de modlisation Unifi

Chapitre 1 Introduction au langage de modélisation Unifié UML

Introduction n Des Modèles plutôt que du Code ¨ Guinier : « La modélisation n’est qu’une représentation d’un système réel quelle qu’en soit sa forme: physique, graphique, mathématique, verbale ou mentale. Cette représentation intelligible est indispensable pour assurer la compréhension de systèmes naturels complexes » ¨ Un modèle est la simplification/abstraction de la réalité 2 UML

Introduction n Des Modèles plutôt que du Code ¨ Nous construisons donc des modèles afin de mieux comprendre les systèmes que nous développons ¨ Nous modélisons des systèmes complexes parce que nous somme incapables de les comprendre dans leur totalité ¨ Le code ne permet pas de simplifier/abstraire la réalité 3 UML

I. Historique Objet Ø Approche procédurale : "Que doit faire mon programme ? " Ø Approche orientée-objet : "De quoi doit être composé mon programme ? " Ø Cette composition est conséquence d'un choix de modélisation fait pendant la conception Exemple: Gestion d'une bibliothèque Germinal E. Zola Le Monde 4 Le seigneur des anneaux J. R. R. Tolkien Alice Dupont Directrice Michel Martin Bibliothécaire Anne Durand Lectrice Arsène Deschamps Lecteur UML

I. Historique Classe Des objets similaires peuvent être informatiquement décrits par une même abstraction : une classe Ø même structure de données et méthodes de traitement Ø valeurs différentes pour chaque objet Classe Livre -titre, auteur Classe Journal -titre Classe Employé -nom, prénom, statut Classe Lecteur -nom, prénom Germinal E. Zola Le Monde 5 Le seigneur des anneaux J. R. R. Tolkien Alice Dupont Directrice Michel Martin Bibliothécaire Anne Durand Lectrice Arsène Deschamps UML Lecteur

I. Historique n Des Méthodes de modélisation ¨ L’apparition du paradigme objet à permis la naissance de plusieurs méthodes de modélisation n OMT, OOSE, Booch, Fusion, … ¨ Chacune de ces méthodes fournie une notation graphique et des règles pour élaborer les modèles ¨ Certaines méthodes sont outillées 6 UML

I. Historique Vers un langage unifié pour la modélisation n Booch, Jacobson et Rumbaugh se fixent 4 objectifs: ¨ représenter des systèmes entiers (au-delà du seul logiciel) par des concepts objets, ¨ établir un couplage explicite entre les concepts et les artefacts exécutables, ¨ prendre en compte les facteurs d’échelle inhérents aux systèmes complexes et critiques, 7 UML

I. Historique Vers un langage unifié pour la modélisation n Booch, Jacobson et Rumbaugh se fixent 4 objectifs: ¨ créer un langage de modélisation utilisable à la fois par les humains et les machines. 8 UML

I. Historique n. L’unification ¨Les créateurs d’UML insistent tout particulièrement sur le fait que la notation UML est un langage de modélisation objet et non pas une méthode objet. ¨ UML n’est pas une notation propriétaire; elle est accessible à tous et les fabricants d’outils ainsi que les entreprises de formation peuvent librement en faire usage. 9 UML

I. Historique n. L’unification ¨En français, UML pourrait se traduire par langage unifié pour la modélisation objet, mais il est plus probable qu’UML se traduise plutôt par notation unifiée, voire notation UML… 10 UML

I. Historique Définition en cours par une commission de réIIIsion Soumission à l’OMG UML 2. 0 UML 1. x UML 1. 2 Standardisation par l’OMG Soumission à l’OMG Version bêta OOPSLA’ 96 OOPSLA’ 95 Autres méthodes Novembre 1997 Septembre 1997 UML 1. 0 Jan. IIIer 1997 UML 0. 9 Juin 1996 Méthode unifiée 0. 8 Booch’ 93 11 Juin 1998 UML 1. 1 Soumission à l’OMG Booch’ 91 1999 -2002 Octobre 1995 OMT-2 OMT-1 OOSE UML Partenaires

II. Les concepts communs d’UML La note n La contrainte n Le paquetage n La dépendance n 12 UML

II. 1 La note n n De même qu’un fichier source doit être commenté, un diagramme doit être annoté. Peut-on imaginer un fichier source sans commentaire ? Certains commentaires peuvent être gérés par un outil : auteur, version, date, etc. La difficulté du « bien commenter » est réelle : ¨ le 13 commentaire est-il simplement un bruit ? ¨ Est-il adapté au lecteur ? ¨ Est-il obsolète ? UML

II. 1 La note n Une note permet de présenter : ¨ Des commentaires ¨ Des contraintes ¨ Des valeurs marquées n n 14 Fournit des explications, des observations ou des renvois vers des documents Ne véhicule pas de contenu sémantique UML

II. 1 La note n 15 Par ailleurs, les notes de UML pallient à une méconnaissance du formalisme ou un manque de l’outil. UML

II. 2 La contrainte n n 16 Relation sémantique quelconque entre éléments de modélisation Définit des propositions qui doivent être vraies Exprimée en OCL (Object. Constraint. Language) ou en langage naturel {contrainte} : chevauchement, complet, détruit, disjoint, incomplet, nouveau, ou-exclusif (xor), transitoire UML

II. 3 Le paquetage n Mécanisme général pour : partitionner des modèles ¨ Regrouper des éléments de modélisation ¨ n 17 Représentation graphique : UML

II. 3 Le paquetage La relation de possession entre le paquetage et les éléments de modélisation est une composition n Destruction du paquetage => destruction des éléments n Un élément de modélisation ne peut appartenir que à un seul paquetage n 18 UML

II. 3 Le paquetage Objectif : cohérence forte entre les éléments d’un même paquetage, et faible entre paquetages n Un paquetage est un élément de modélisation, il peut contenir d’autres paquetage (niveaux illimités) n Le paquetage de plus haut niveau est la racine : base de la hiérarchie, le stéréotype « racine » permet de le désigner n 19 UML

II. 3 Le paquetage 20 UML

II. 3 Le paquetage Par souci de clarté le contenu d’un paquetage n’est pas IIIsualisé n La IIIsibilité de ses éléments peut-être précisée. n un paquetage peut-être : +public, -privé ou #protégé n 21 UML

II. 3 Le paquetage n Plusieurs stéréotypes : ¨ Façade : vue simplifiée d’autres paquetage, lui-même ne possède pas d’éléments ¨ Framework : contient une charpente applicative ¨ Souche : fournit uniquement une partie publique ¨ Racine : le plus haut niveau dans la hiérachie 22 UML

II. 3 Le paquetage n 23 Les éléments des paquetages sont différents même s’ils ont des noms identiques UML

II. 4 La dépendance n Relation unidirectionnelle entre deux éléments de modélisation : entre source et cible n Un changement au niveau de la cible implique un changement au niveau de la source 24 24 UML

III. Les diagrammes UML n Diagrammes statiques : ¨ Mettent en évidence des liens structurels entre les entités qui constituent l’application n Diagrammes dynamiques : ¨ Mettent en évidence le comportement des entités qui constituent cette application. n 25 UML définit au total 9 diagrammes en UML 1. X et 13 en UML 2. 0 UML

III. Les diagrammes UML 1. 5 n Diagramme de cas d’utilisation ¨ Scénario d’un cas d’utilisation : chronologie des opérations relation Acteur 26 Cas d ’utilisation UML

III. Les diagrammes UML n Diagramme de séquences ¨ exprime la séquence des interactions entre objets du système selon un point de vue temporel, pour réaliser le cas d’utilisation. 27 UML

III. Les diagrammes UML n Diagramme de séquences Objet 1 1 : [condition A] message Objet 2 2 : message synchrone 3 : message de création Evénement / Communication entre objets 5: message Objet 3 4: message 6 : [condition B] message Période d’acti. IIIté de l’objet 28 9 : message asynchrone 7 : message réflexif 8 : message de destruction UML

III. Les diagrammes UML n Diagramme de collaboration ¨ Scénario 29 d’un cas d’utilisation: activités des objets et des messages échangés ¨ Interactions entre objets du système avec un accent particulier sur la structure spatiale statique des objets (contexte des objets). ¨ Les messages sont numérotés pour indiquer l ’ordre des envois. ¨ Devenu diagramme de communication dans UML 2. UML

III. Les diagrammes UML n Diagramme de collaboration : ascenseur 1: monter Objet 1 1: message 4: message Objet 3 30 2: message Objet 2 3: message 5: message : cabine 3: fermer : porte 2: allumer : lumière UML

III. Les diagrammes UML n Diagramme de classes statique d’un système, en termes de classes et de relations entre ces classes. classe 2 classe 1 généralisation n tio cia so as classe 3 spécialisation ¨ Structure agrégation classe 4 31 UML

III. Les diagrammes UML n Diagramme d’objets ¨ Structure statique d’un système, en termes d’objets et de liens entre ces objets. ¨ Un objet est une instance de classe et un lien est une instance de relation. Etienne : personne Personne âge : entier collaborateur âge = 35 patron * patron 1 Diagramme de classes 32 Jan-Luc : personne âge = 25 Diagramme d ’objets UML

III. Les diagrammes UML n Diagramme d’états-Transition ¨ Description des séquences possibles d’états et d’actions par lesquelles un objet peut passer tout au long de sa vie. Ces séquences résultent de sa réaction à des événements discrets. Etat A …. état initial 33 action do: opération Evénement [garde] / Action Etat B …. état final UML

III. Les diagrammes UML n Diagramme d’Activités ¨ Variante des diagrammes d’états-transition, organisé par rapport aux actions et destiné à représenter le comportement interne d’une opération ou d’un cas d’utilisation. 34 UML

III. Les diagrammes UML n Diagramme d’Activités Mesurer température Chauffer Refroidir « synchronisation » Arrêter chauffage 35 Aérer UML

III. Les diagrammes UML n Diagramme des composants ¨ Représentation des composants logiciels d’un système : représente l’architecture logicielle ¨ Décrit les spécifications des modules qui vont contenir le code des classes ainsi que le programme principal. L’identification des modules est réalisée pour chaque soussystème du système global. 36 UML

III. Les diagrammes UML n Diagramme de déploiement ¨ Description de l’architecture technique du système : représente l’architecture matérielle ¨ Décrit la disposition physique des différents nœuds (processeurs) dans la composition d’un système et la répartition des programmes principales du diagramme des composants, sur ces processeurs. 37 UML