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

Introduction 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é UML

Introduction 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é UML

Le seigneur des anneaux 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 Le seigneur des anneaux J.R.R.Tolkien Germinal E. Zola Le Monde Alice Dupont Directrice Michel Martin Bibliothécaire Anne Durand Lectrice Arsène Deschamps Lecteur Exemple: Gestion d'une bibliothèque UML

Le seigneur des anneaux 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 Le seigneur des anneaux J.R.R.Tolkien Germinal E. Zola Le Monde Alice Dupont Directrice Michel Martin Bibliothécaire Anne Durand Lectrice Arsène Deschamps Lecteur UML

I. Historique Des Méthodes de modélisation L’apparition du paradigme objet à permis la naissance de plusieurs méthodes de modélisation 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 UML

I. Historique Vers un langage unifié pour la modélisation 14/11/01 I. Historique Vers un langage unifié pour la modélisation 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 UML 01 V1-1

I. Historique Vers un langage unifié pour la modélisation 14/11/01 I. Historique Vers un langage unifié pour la modélisation 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 UML 01 V1-1

I. Historique L’unification 14/11/01 I. Historique 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 UML 01 V1-1

I. Historique L’unification 14/11/01 I. Historique 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 UML 01 V1-1

I. Historique Autres méthodes Booch’91 OMT-1 OOSE Partenaires Booch’93 Méthode unifiée 0.8 UML 0.9 UML 1.0 UML 1.1 UML 1.2 UML 1.x UML 2.0 1999-2002 Juin 1998 Novembre 1997 Septembre 1997 JanIIIer 1997 Juin 1996 Octobre 1995 Définition en cours par une commission de réIIIsion Soumission à l’OMG Standardisation par l’OMG Version bêta OOPSLA’96 OOPSLA’95 UML

II. Les concepts communs d’UML 14/11/01 II. Les concepts communs d’UML La note La contrainte  Le paquetage  La dépendance UML UML 01 V1-1

II.1 La note 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 commentaire est-il simplement un bruit ? Est-il adapté au lecteur ? Est-il obsolète ? UML

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

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

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

II.3 Le paquetage Mécanisme général pour : Représentation graphique : partitionner des modèles Regrouper des éléments de modélisation 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 Destruction du paquetage => destruction des éléments Un élément de modélisation ne peut appartenir que à un seul paquetage UML

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

II.3 Le paquetage UML

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

II.3 Le paquetage 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 UML

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

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

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

III. Les diagrammes UML 1.5 Diagramme de cas d’utilisation Scénario d’un cas d’utilisation : chronologie des opérations Cas d ’utilisation Acteur relation UML

III. Les diagrammes UML 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. UML

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

III. Les diagrammes UML Diagramme de collaboration Scénario 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 Diagramme de collaboration : ascenseur : cabine : porte : lumière 1 : monter 3 : fermer 2 : allumer Objet 1 Objet 2 Objet 3 1 : message 3 : message 2 : message 4 : message 5 : message UML

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

III. Les diagrammes UML 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 âge = 35 Jan-Luc : personne âge = 25 patron Personne âge : entier patron collaborateur 1 * Diagramme de classes Diagramme d ’objets UML

III. Les diagrammes UML 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 action do:opération Etat B Evénement [garde] / Action …. état initial état final UML

III. Les diagrammes UML 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. UML

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

III. Les diagrammes UML 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 sous-système du système global. UML

III. Les diagrammes UML 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. UML