Notation UML.

Présentation au sujet: "Notation UML."— Transcription de la présentation:

1 Notation UML

2 Sommaire Historique La Modélisation Axe Statique Axe Dynamique
NOTATION UML Historique La Modélisation Axe Statique Axe Dynamique Références

3 Historique

4 BOOCH Pionnier de l ’Orienté-Objet Distingue 2 niveaux: NOTATION UML
Les Principales Méthodes Objet BOOCH NOTATION UML Pionnier de l ’Orienté-Objet Article en 1981: ‘ Object Oriented Development ’ Au début, méthode pour le développement d ’applications en Ada pour le ‘ Department of Défense ’ Etendue au C++ Distingue 2 niveaux: Logique Diagrammes de classes Diagramme d’instance Diagramme états/transitions Physique Diagrammes de modules Diagramme de processus Grady Booch Historique

5 OMT Object Modeling Technique 3 axes 4 phases de modélisation
Les Principales Méthodes Objet OMT NOTATION UML Object Modeling Technique Livre de James Rumbaugh (1991) 3 axes Statique Dynamique Fonctionnel 4 phases de modélisation Analyse Conception Système Conception Objet Implantation Un article signe J. Rumbaugh parait chaque mois dans JOOP James Rumbaugh Historique

6 OOSE Object Oriented Software Engineering 5 modèles
Les Principales Méthodes Objet OOSE NOTATION UML Object Oriented Software Engineering Souvent appelée Objectory 5 modèles Besoins Analyse Conception Implantation Test 3 types d ’objets (MVC en Design Paterns) entités contrôles interfaces Notion de Cas d’Utilisation: Use Cases Ivar Jacobson Historique

7 Méthodes Objets En 1994, plus de 50 méthodes OO
Les Principales Méthodes Objet Méthodes Objets NOTATION UML En 1994, plus de 50 méthodes OO Fusion, Shlaer-Mellor, ROOM, Classe-Relation, Wirfs-Brock, Coad-Yourdon, MOSES, Syntropy, BOOM, OOSD, OSA, BON, Catalysis, COMMA, HOOD, Ooram, DOORS... Les méta-modèles se ressemblent de plus en plus Les notations graphiques sont toutes différentes L’industrie a besoin de standards Historique

8 Naissance d’UML 1993-1994: Booch’93, OMT-2 Octobre 1994
La Convergence vers UML Naissance d’UML NOTATION UML : Booch’93, OMT-2 Les 2 méthodes sont leaders sur le marché Elles sont de plus en plus proches Octobre 1994 J. Rumbaugh (OMT) rejoint G. Booch chez Rational Annonce de l’unification des deux méthodes Octobre 1995: Méthode Unifiée v0.8 Fin 1995: le fondateur d ’Objectory, Ivar Jacoson, rejoint à son tour Rational Janvier 97 : Soumission à l’OMG de la version UML 1.0 OMG: Object Management Group Organisme à but non lucratif fondé en 1989 Plus de 700 entreprises y adhèrent Connu pour la norme CORBA Septembre 97 : UML 1.1 Historique

9 Conclusion UML: Prendre le meilleur de chacune des méthodes
La Convergence vers UML Conclusion NOTATION UML UML: Prendre le meilleur de chacune des méthodes OOSE (Jacobson): Use Cases OMT (Rumbaugh): Analyse Booch: Conception, Architecture UML est dans le domaine public Soutenu par le marché Microsoft, HP, Oracle, IBM... Les diagrammes d ’UML et leurs influences: Diagramme de Use Case (OOSE) : Représente les fonctions du système du point de vue de l’utilisateur. Diagramme de Classes (OMT, Booch) : Représente la structure statique en terme de classes et de relations. Diagramme d ’Objets (OMT, Booch) : Représente les objets et leurs relations. Diagramme d'Etats-Transitions (Harel) : Représente le comportement d ’une classe en terme d’états. Diagramme d'Activité (Harel, Workflow) : Représente le comportement d ’une opération en terme d’actions. Diagramme de Séquence (OMT OMSC) : Représentation temporelle des objets et de leurs interactions. Diagramme de Collaboration (Booch, Fusion) :Représentation spatiale des objets, des liens et des interactions. Diagramme de Composants (Booch) : Représente les composants physiques d ’une application. Diagramme de Déploiement (Booch) : Représente le déploiement des composants sur le dispositif matériel. Historique

10 La Modélisation

11 UML ? Est une notation, pas une méthode
Définition UML ? NOTATION UML Est une notation, pas une méthode Est un langage de modélisation objet Convient à toutes les méthodes objets Unified Software Development Process Catalysis Convient à tous les langages objets C++ (Héritage multiple, Template) Java (Interface) SmallTalk La Modélisation

12 Pourquoi Modéliser Propos tenus par Grady Booch « Dog House »
NOTATION UML Propos tenus par Grady Booch « Dog House » clous, planches, marteau, scie « House for your Family » clous, planches, marteau, scie, plans, fondation, lumière, chauffage, plomberie, équipe « High-Rise Office Building » maquette, planning, plusieurs équipes (communication), parallèlisation des taches, spécialistes, machines La Modélisation

13 Processus de développement
Cycle de développement Processus de développement NOTATION UML UML ne définit pas de processus standard de dévelopement Ce n’est le but ni d ’UML, ni de l ’OMG Ceux de Booch, OMT, et OOSE restent applicables Processus itératif et incrémental Segmentation du travail Les premières itérations sont des prototypes The Unified Software Development Process (addison-Wesley, 1999) La Modélisation

14 Axe de Modélisation Statique Fonctionnel Dynamique NOTATION UML
Cycle de développement Axe de Modélisation NOTATION UML Statique Diagramme de Classes Diagramme d’Objets Diagramme de Composants Diagramme de Déploiement Diagramme de Use Case Fonctionnel Dynamique Diagramme de Use Case : Représente les fonctions du système du point de vue de l’utilisateur. Diagramme de Classes : Représente la structure statique en terme de classes et de relations. Diagramme d ’Objets : Représente les objets et leurs relations. Diagramme d'Etats-Transitions : Représente le comportement d ’une classe en terme d’états. Diagramme d'Activité : Représente le comportement d ’une opération en terme d’actions. Diagramme de Séquence : Représentation temporelle des objets et de leurs interactions. Diagramme de Collaboration :Représentation spatiale des objets, des liens et des interactions. Diagramme de Composants : Représente les composants physiques d ’une application. Diagramme de Déploiement : Représente le déploiement des composants sur le dispositif matériel. Diagramme de Use Case Diagramme d'Etats-Transitions Diagramme d'Activité Diagramme de Séquence Diagramme de Collaboration La Modélisation

15 Design View Implementation Process Deployment Use Case Les 4+1 Vues
Cycle de développement Les 4+1 Vues NOTATION UML Classes Interfaces Collaboration => Les services du systèmes Composant Fichiers Source => Configuration du système Design View Implementation Process Deployment Use Case => Comportement du système Thread Process Concurrence Synchronisation => Performance du système Architecture Hardware Distribution => Topologie du système La Modélisation

16 L ’Axe Statique

17 Notation de base Classe Classe Objet Objet de type Classe NOTATION UML
Classes et Objets Notation de base NOTATION UML Classe Classe Une description d’un ensemble d’objets qui partage les mêmes attributs, opérations, méthodes, relations et contraintes Objet Une entité avec une limite et une identité bien définies qui encapsule de l'état et du comportement. L’état est représenté par des attributs et des relations, le comportement est représenté par des opérations et des méthodes. Un objet est une instance d’une classe. Objet de type Classe L ’Axe Statique

18 Attribut Attribut = propriété nommée d ’une classe Syntaxe Visibilité
Classes et Objets Attribut NOTATION UML Attribut = propriété nommée d ’une classe Syntaxe visibilité nom : type = valeur initiale Visibilité + public # protégé - privé package Attribut de classe la portée standard d’un attribut est limité à un objet quand cette portée s’applique à la classe elle même, on parle d’attribut de classe (représenté par le symbole $ ou souligné) Attribut dérivé attribut qui peut être déduit d’un ou plusieurs autres attributs (représenté par le symbole /) L ’Axe Statique

19 Classes et Objets Méthode NOTATION UML Méthode = service que l ’on peut demander à un objet pour réaliser un comportement Syntaxe visibilité nom (paramètres) : type retour Mêmes notions que l’attribut visibilité méthode de classe méthode dérivée L ’Axe Statique

20 } } Notation Complète Nom de la Classe Initialisation Visibilité
Classes et Objets Notation Complète NOTATION UML Nom de la Classe Initialisation } Visibilité Attributs Static } Dérivé Méthodes public class Fenetre { public Rectangle taille = 100,100; private Boolean visible = true; Color couleur = blue; protected static Rectangle tailleMax; protected static Rectangle tailleMin; public Position afficher() { } public void cacher() { } protected void setTaille(Rectangle taille) { } } Retour Paramètre L ’Axe Statique

21 Définition Association
Associations Définition NOTATION UML Association Exprime une connexion sémantique bi-directionnelle entre classes Abstraction des liens qui existent entre objets Le sens d ’une association peut-être précisé par une flêche Association binaire = Association entre 2 classes. Cas particulier d ’association n-aire Rôle = rôle joué par une classe dans une association Multiplicité = indique le nombre d’instances d ’une classe qui peut être mise en relation avec une seul instance de la classe associée 1 : obligatoire 0..1 : optionnel 0..* ou * : quelconque 1..* : au moins 1 1..5, 10 : entre 1 et 5, ou 10 1 public Classe m_Classe; 0..1 0..* public Vector m_Classe = new Vector(); 1..* L ’Axe Statique

22 Exemple Rôle Nom Sens Classe Multiplicité NOTATION UML Associations
public class Entreprise { private String Raison_Sociale; private String Activité; private Personne employé[]; } public class Personne { private String Nom; private String Prénom; Classe Multiplicité L ’Axe Statique

23 Sémantique NOTATION UML Associations L ’Axe Statique
Dans la relation ‘marié avec’, l ’homme joue le rôle du mari et la femme joue le rôle de l’épouse. L ’Axe Statique

24 Note Note = Commentaire placé sur un diagramme NOTATION UML
Associations Note NOTATION UML Note = Commentaire placé sur un diagramme L ’Axe Statique

25 Contrainte Contrainte
Associations Contrainte NOTATION UML Contrainte = relation sémantique entre éléments de modèle qui spécifie des conditions ou propositions devant rester vraies pour que le modèle soit valide { contrainte } Contraintes Pré-Définies Inclusion Exclusion Inclusion : Le président d ’un club est lui aussi un membre du club Exclusion : Le titulaire d ’un compte est, soit une personne, soit une société La version 1.1 d ’UML apporte un langage pour spécifier des contraintes : OCL (Object Constraint Language) Contrainte L ’Axe Statique

26 Contraintes Pré-définies
Associations Contraintes Pré-définies NOTATION UML Ordre Chemins Contrainte Ordre : Un pays possède un nombre ordonné de département (01, 02, 03…) Chemins : L ’entreprise qui emploie le chef est la même que celle qui emploie un employé Contrainte L ’Axe Statique

27 Associations dérivée Dérivée Contrainte
NOTATION UML Une association dérivée est une association qui peut se déduire des associations existantes Dérivée Comme pour les attributs dérivés, les associations dérivées sont redondantes mais aident à la compréhension du modèle. Les associations dérivées sont peu utilisées en analyse; en revanche, elles seront introduites en conception pour améliorer la vitesse d ’accès aux données. Contrainte L ’Axe Statique

28 Attribut d’Association
Associations Attribut d’Association NOTATION UML Attribut d’association = propriété du lien entre deux objets Attribut Attribut L ’Axe Statique

29 Classe d’Association Classe
Associations Classe d’Association NOTATION UML Classe d’association = Elément ayant à la fois les propriétés d ’une classe et d ’une association travaille public class Contrat_de_Travail { private Date m_date; private Number m_salaire; private Société m_SociétéRef; private Personne m_PersonneRef; } Classe L ’Axe Statique

30 Associations Association n-aire NOTATION UML Association n-aire = Une association parmi 3 classes ou plus. Chaque instance de l’association est un n-tuple de valeurs des classes respectives. Professeur Elève Salle Heure de début Heure de fin Cours lieu 1 1..* Pour lire les cardinalités if faut dire: pour un professeur et un élève on a une salle pour un professeur et une salle on a n élèves pour une salle et une élève on a un professeur public class Cours { private Date m_Heure_Debut; private Date m_Heure_Fin; public Salle m_lieu; public Professeur m_Professeur; public Vector m_Eleve = new Vector(); } L ’Axe Statique

31 Agrégation et Composition
Définitions NOTATION UML Agrégation = association particulière spécifiant une relation ‘tout - partie’ entre l’agrégat et un composant Inclusion Propagation Composition = forme forte d’agrégation avec un cycle de vie des parties lié à celui du composite Inclusion : Un livre ‘ inclus  ’ des chapitres. Un chapitre ‘ inclus ’ des mots. Propagation : Si on pose la question ‘nombre de caractère ?’ à la classe Livre, celle-ci propage la même question à la classe Chapitre qui la propage à la classe Mot. public class Livre { public Vector m_Chapitre = new Vector(); } public class Chapitre { public Livre m_Livre; public Vector m_Mot = new Vector(); public class Mot { public Chapitre m_Chapitre; L ’Axe Statique

32 Exemples Multiplicité Agrégation Composition NOTATION UML
Agrégation et Composition Exemples NOTATION UML Multiplicité Agrégation Composition Il n’est pas toujours évident de choisir entre une composition, agrégation et association. Dans le cas de la Voiture, si l ’on veut pouvoir remplacer une Roue ou un Moteur, la relation ne doit pas être une composition. Par contre, du point de vue d’un vendeur d’automobiles, une Voiture sans Moteur ne peut plus être vendu, c’est alors une composition. Dans le second exemple, le cycle de vie de la Tête est lié au cycle de vie de l ’Homme. L ’Axe Statique

33 Généralisation, Spécialisation
Définitions NOTATION UML Généralisation = relation ente un élément plus général et un élément plus spécifique qui est entièrement conforme avec le premier élément, et qui ajoute de l ’information supplémentaire Spécialisation = mécanisme par lequel des éléments plus spécifiques incorporent la structure et le comportement d’éléments plus généraux (notion d’héritage). Discriminant Généralisation Il est possible d’ajouter un discriminant. Celui-ci sert à préciser le critère de classification utilisé. C’est indispensable pour pouvoir différencier un même arbre de classification découpé sur plusieurs diagrammes à des fins de lisibilité. Ainsi, le Planeur et l ’AvionAMoteur peuvent être classifiés dans la catégorie ‘motorisation’ (avec ou sans moteur). public class AvionAMoteur extends Avion { } public class MoyenCourrier extends Avion { Spécialisation Héritage multiple L ’Axe Statique

34 Interface Stéréotype Implements Extends Notations
Généralisation, Spécialisation Interface NOTATION UML Notations Hériter d’une interface Stéréotype public class Planneur extends Avion implements Wind_Listener { } public class AvionDeChasse extends Avion implements Missile_Listener { Implements Extends L ’Axe Statique

35 Généralisation Contraintes NOTATION UML Les seules contraintes pré-définies en UML pour la généralisation sont : disjoint (un moyen courrier ne peut être long courrier) / overlapping complete (liste éxhaustive de classe) / incomplete Exemple de contrainte {complete} : la liste des Pièce d ’un jeu d ’échec (Roi, Dame, Tour, Fou, Cavalier, Pion : héritant de la classe Pièce). Il ne peut y avoir d ’autres pièces dans un jeu d’échec, la liste est donc complète L ’Axe Statique

36 Classe Abstraite Avion Avion Ou Italic Contrainte
Généralisation Classe Abstraite NOTATION UML Classe Abstraite = classe que l ’on ne peut pas instancier Notation : Avion Avion {abstract} Ou Italic Contrainte public abstract class Avion { } L ’Axe Statique

37 Stéréotype et Valeur Etiquetée
Extensibilité Stéréotype et Valeur Etiquetée NOTATION UML Deux mécanismes d ’extensibilité d ’UML, applicables à tout élément de modèle : Stéréotypes = nouveau type d ’élément de modélisation qui étend la sémantique du méta-modèle (peut avoir une représentation visuelle) : << stéréotype>> Valeur Etiquetée = définition explicite d ’une propriété sous la forme d ’une contrainte : {étiquette = valeur} <<actor>> Client Client Exemple de stéréotypes visuels: les 3 types d ’objets d ’Ivar Jacobson (MVC) Modèle Vue Contrôleur Exemple de stéréotypes visuels: les 3 types d ’objets d ’Ivar Jacobson (MVC) Modèle Vue Contrôleur {phase=analyse} {fait par=Antonio} Client {version=2.3} Client L ’Axe Statique

38 Pour Structurer Package = Regroupement d’éléments de modèle
NOTATION UML Package = Regroupement d’éléments de modèle Les Packages divisent et organisent les modèles de la même manière que les répertoires organisent les systèmes de fichiers Les Packages eux-mêmes peuvent être imbriqués à l ’intérieur d ’autres Packages L ’Axe Statique

39 Diagramme de Classes Notation NOTATION UML L ’Axe Statique

40 L ’Axe Dynamique

41 Que représente-t-on dans le modèle dynamique ?
Introduction Que représente-t-on dans le modèle dynamique ? NOTATION UML Le modèle dynamique représente les séquences d’événements, d’états et de réactions qui doivent survenir dans le système. Il est intimement lié au modèle objet et décrit les aspects de contrôle d’un système en prenant compte du temps, du séquencement des opérations et des interactions entre objets Deux diagrammes fondamentaux : Diagramme de Séquence Diagramme Etats-Transitions L ’Axe Dynamique

42 Diagramme de Séquence Scénario NOTATION UML Il y a autant de diagrammes de séquence qu’il y a de scénarios Un Scénario montre une séquence particulière d’interactions entre objets, dans un seul contexte d’exécution du système Un scénario peut être vu comme une des instances possibles des Use Cases. On y fait intervenir des objets, des messages et des événements Objets de type Classe Messages L ’Axe Dynamique

43  Diagramme de classes Exemple de l’ascenseur Scénario NOTATION UML
Diagramme de Séquence Diagramme de classes NOTATION UML Exemple de l’ascenseur Scénario Deux usagers situés à des étages différents empruntent le même ascenseur pour se rendre au troisième étage Trois usagers situés au même étage empruntent le même ascenseur pour se rendre au troisième et cinquième étage  L ’Axe Dynamique

44 Objet Notation Graphique Méthode NOTATION UML Diagramme de Séquence
L ’Axe Dynamique

45 Diagramme de Séquences
Notation NOTATION UML L ’Axe Dynamique

46 Définition Un diagramme Etats-Transitions (ou Automate) :
NOTATION UML Un diagramme Etats-Transitions (ou Automate) : décrit l’évolution au cours du temps d’une instance d’une classe en réponse aux interactions avec d’autres objets est forcément associé à une classe, mais toutes les classes n’en ont pas besoin est un graphe orienté d’états (noeuds) connectés par des transitions (arc orientés) Source: Les Statecharts de David Harel David Harel L ’Axe Dynamique

47 Etats Chaque objet est à un moment donné dans un état particulier :
Diagramme Etats-Transitions Etats NOTATION UML Chaque objet est à un moment donné dans un état particulier : Etat Initial : état d’une instance juste après sa création (un seul état initial) Etat Intermédiaire : un objet est toujours dans un état donné pour un certain temps Etat Final : état d’une instance juste avant sa destruction (un automate infini peut ne pas avoir d’état final) L ’Axe Dynamique

48 Transition, Condition Etat initial Etat final Condition Evénement
Diagramme Etats-Transitions Transition, Condition NOTATION UML Transition : relation entre 2 états indiquant qu’un objet dans le premier état va exécuter une action et entrer dans le deuxième état quand un événement apparaîtra Condition : expression booléenne devant être vérifiée pour permettre la transition Etat initial Etat final Condition Evénement Transition L ’Axe Dynamique

49 Action, Activité Action Activité
Diagramme Etats-Transitions Action, Activité NOTATION UML Action : opération atomique (non interruptible) déclenchée par une transition Activité : opération qui dure un certain temps (interruptible) dans un état particulier entry : action exécutée chaque fois que l’on rentre dans l’état exit : action exécutée chaque fois que l’on quitte l’état Action Activité L ’Axe Dynamique

50 Notation Complète Evénement Etat initial Activité Action
Diagramme Etats-Transitions Notation Complète NOTATION UML Exemple : fonctionnement d’une montre digitale Evénement Etat initial Activité Action L ’Axe Dynamique

51 Généralisation d’états
Diagramme Etats-Transitions Généralisation d’états NOTATION UML Dans le cas d’un comportement dynamique complexe, les diagrammes d’états sur un niveau deviennent rapidement illisibles Pour éviter ce problème, il est nécessaire de structurer les diagrammes d’états en: super-états : états généraux sous-états : héritent des caractéristiques des états généraux = Même evt Super-état Sous-état L ’Axe Dynamique

52 Notation Complète Super-état Sous-état
Diagramme Etats-Transitions Notation Complète NOTATION UML Exemple : transmission d’une automobile Super-état Sous-état L ’Axe Dynamique

53 Historique H Historique Par défaut, un automate n’a pas de mémoire
Diagramme Etats-Transitions Historique NOTATION UML Par défaut, un automate n’a pas de mémoire La notation H offre un mécanisme pour mémoriser le dernier sous-état qui l’englobe Exemple : cycle de lavage d’un lave vaisselle H Historique L ’Axe Dynamique

54 Diagramme Etats-Transitions
Notation NOTATION UML L ’Axe Dynamique

55 Références

56 Pour en Savoir Plus Livres NOTATION UML The Unified Modeling Language User Guide , G. Booch, J. Rumbaugh, I. Jacobson, 1999, Addison Wesley Object-Oriented Modeling and Design, J. Rumbaugh, 1991, Prentice-Hall Object Solution, G. Booch, 1996, Addison-Wesley Object-Oriented Software Engineering: A Use Case Driven Approach, I. Jacobson, 1992, Addison-Wesley Modélisation Objet avec UML, P. A. Muller, 1997, Eyrolles UML Distilled, M. Fowler, 1997, Addison-Wesley UML La notation unifiée de modélisation objet, M. Lai, Masson Designing Object Systems: Object-Oriented Modeling with Syntropy, S. Cook, J. Daniels, 1994, Prentice-Hall Références

57 Pour en Savoir Plus Articles NOTATION UML Getting started: using use case to capture requirements, J. Rumbaugh, Sept 1994, JOOP Formalizing use-case modeling, I. Jacobson, Juin 1995, JOOP OMT: The object model, J. Rumbaugh, Jan 1995, JOOP A search values: Attributes and associations, J. Rumbaugh, Juin 1996, JOOP A matter: How to define subclasses, J. Rumbaugh The life of an object model: How the object model changes during development, J. Rumbaugh, Mars 1994, JOOP Statecharts: a visual Formalism for Complex Systems, D. Harel, 1987, Science of Computer Programming vol 8 Executable Object Modeling with Statecharts, D. Harel, Juillet 1997, Computer OMT: The dynamic model, J. Rumbaugh, Fev 1995, JOOP Références

58 Sur le Web Rational Software / UML Resource Software NOTATION UML OMG
Pour en Savoir Plus Sur le Web NOTATION UML Rational Software / UML Resource Software OMG Groupe UML France Carrefour Cetus : Orienté Objet Using Use Cases (Tutorial) Object Constraint Language David Harel ’s Home Page I-Logix (société de Harel): produit Rhapsody La documentation UML 1.1 (01/09/1997) disponible sur le site de Rational contient les documents suivant: UML Semantics UML Notation Guide UML Extension for the Objectory Process for Software Engineering UML Extension for Business Modeling Object Constraint Language Specification UML Meta-Model Références