1 UML : Unified Modelling Language Historique : Grady Booch 1981, ADA, « Object Oriented Development » James Rumbaugh 1991, OMT, JOOP (Journal of OO programming) Ivar Jacobson, OOSE sept 97, UML 1.1. Références : site en français en France Pierre Alain Muller (U-Mulhouse) et Valtech Outils : Objecteering Rational ROSE, plus de 30 outils de modélisation et de CASE (Computer Aided Software Engineering)

2 Booch methodOMT Unified Method 0.8 OOPSLA ´95 OOSE Other methods UML 0.9 Web - June ´96 public feedback Final submission to OMG, Sep ‘97 First submission to OMG, Jan ´97 UML 1.1 OMG Acceptance, Nov 1997 UML 1.3 UML 1.0 UML partners Creating the UML

3 Meyer Before and after conditions Harel Statecharts Gamma, et al Frameworks and patterns, HP Fusion Operation descriptions and message numbering Embley Singleton classes and high-level view Wirfs-Brock Responsibilities Odell Classification Shlaer - Mellor Object lifecycles Rumbaugh OMT Booch Booch method Jacobson OOSE Contributions to the UML

4 diagramme de classes diagramme d’objets diagramme de composants diagramme de déploiement Statique (ce que le système EST) diagramme de séquence diagramme de collaboration diagramme d’états-transitions diagramme d’activités Fonctionnel (ce que le système FAIT) Dynamique (comment le système EVOLUE) diagramme de cas d’utilisation diagramme de collaboration Axes de modélisation d ’un système

5 Conceptuel Organisationnel Logique Physique En UML, les mêmes modèles peuvent être utilisés à différents niveaux d ’abstraction du plus conceptuel à l’implantation. On peut donc appliquer des mécanismes de transformation continue. Niveaux d’abstraction d’un SI

6 diagramme de cas d’utilisation diagramme de collaboration diagramme de classes diagramme d’objets diagramme de composants diagramme de déploiement diagramme de séquence diagramme d’états-transitions diagramme d’activités (nous utiliserons IDEF 0) Les 9 diagrammes UML

7 Cas d’utilisation une fonctionnalité attendue du système (VEGA2) par les différents acteurs. Exemples : Quelques diagrammes : acteur (intéragissant avec VEGA2) Système (VEGA2) message Diagramme de séquence Chaque cas d'utilisation apparaît comme un scénario, décrit par un ou plusieurs diagrammes de séquence. Un diagramme de séquences montre les interactions entre les acteurs et le système selon un point de vue temporel pour accomplir une fonctionnalité attendue du système (un cas d ’utilisation). C’est un ensemble de messages échangés entre les acteurs et le système, ordonnés chronologiquement. Diagramme de Classes

8 Modèle Fonctionnel Use Cases : cas d ’utilisation diagramme de collaboration

9 Représente les fonctions du système de point de vue de l ’utilisateur. Cas d ’utilisationActeur relation Eléments du diagramme : acteur : un rôle joué par une personne, un service, etc. qui interagit avec le système étudié cas d’utilisation : manière spécifique d ’utiliser un système. Image d’une fonctionnalité attendue, déclenchée en réponse à la stimulation d’un acteur relations entre cas d’utilisations et acteurs Ceci est un cas d’utilisation Ceci est une relation Ceci est un acteur Diagramme de cas d’utilisation

10 Trois types de relations : relation de communication : entre un acteur et un cas d’utilisation. Exprime l’échange d’informations entre l’acteur et le système. virementclient déclenche relation d’utilisation : entre deux cas d ’utilisation. Exprime que le cas d’utilisation source comprend également le comportement décrit par le cas d’utilisation destinataire (utile pour la factorisation de cas). virementidentification « use » relation d’extension : entre deux cas d’utilisation. Exprime que le cas d’utilisation source étend le comportement du cas d’utilisation cible (utile pour la spécialisation de cas). Virement par Internet virement « extend » Relations entre cas d ’utilisations

11 Récupère les Acteur humain : il s ’agit ici d ’un rôle et non d ’un acteur identifié. Acteur non humain : exemple un logiciel de comptabilité ou d’ERP avec lequel le système interagit Exemple Définit les contraintes mécaniques Conçoit les schémas et nomenclatures Gère la création et les révisions des dossiers variantes Gère la création et les révisions d ’un job Développeur Gestion des schémas Responsable CFAO Gestion des jobs Gestion des contraintes Gestion des dossiers > Responsable BE schémas Récupère les contraintes Acteurs : diagramme de cas d’utilisation

12 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. Permet de situer le contexte du système. Message: Simple, Asynchrone, Synchrone, Minuté : 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 Diagramme de Collaboration

13 Modèle Statique diagramme d ’objets Diagramme de classes

14 Objet : une entité concrète avec une identité bien définie qui encapsule un état et un comportement. L ’état est représenté par des valeurs d’attribut et des associations, le comportement par des méthodes. Un objet est une instance d ’une classe. Classe : une description d’un ensemble d’objets qui partagent les mêmes attributs, opérations, méthodes, relations et contraintes. Une classe peut posséder des attributs ou des méthodes « de classe ». Objets et classes MaVoiture : Voiture marque = Renault Modèle = Nevada Immatriculation = 648ADX38 AnnéeModele = 1992 Kilométrage = Voiture marque : chaîne Modèle : chaîne Immatriculation : chaîne (8) AnnéeModele : date Age_moyen : entier Rouler ( ) Kilometrage_annuel_moyen ( )

15 Structure statique d’un système, en termes d’objets et de liens entre ces objets. Ces objets et ces liens possèdent des attributs qui possèdent des valeurs. Un objet est une instance de classe et un lien est une instance d’association. Personne âge : entier patron collaborateur 1 * Diagramme de classes Nom de l’objet : Classe Attributs = valeurs Diagramme d’Objets Etienne : personne âge = 35 Jean-Luc : personne âge = 25 patron Diagramme d ’objets collaborateur emploie>

16 Structure statique d’un système, en termes de classes et de relations entre ces classes. Nom de classe Attributs Opérations () Voiture Couleur Cylindrée Vitesse max Démarrer () Accélérer () Freiner () Visibilité : trois niveaux de visibilité pour les attributs et les opérations: public (+) : élément visible à tous les clients de la classe protégé ( #) : élément visible aux sous-classes de la classe privé (-) : élément visible à la classe seule Syntaxe: nom_attribut : type_attribut = valeur initiale nom_opération (nom_argument : type_argument = valeur_par_défaut, …) : type_retourné exemple : Diagramme de classes

17 Agrégation : quand une classe fait partie d’une autre classe (agrégat - composant) Association : toute relation structurelle entre classes, autre que l ’agrégation et la généralisation Généralisation : factorisation des éléments communs d’un ensemble de classes dits sous- classes dans une classe plus générale dite super-classe. Elle signifie que la sous-classe est un ou est une sorte de la super-classe. Le lien inverse est appelé spécialisation classe 4 classe 3 classe 2 classe 1 agrégation association généralisation spécialisation véhicule voiturecamionavion moteur constructeur 1 1..* 1 Diagramme de classes : Relations entre classes

18 Agrégation: Association transitive : si voiture est composée de moteur et si moteur est composé de courroie alors voiture est composée de courroie Association non systémique : si voiture est composée de moteur, moteur ne peut pas être composé de voiture Association qui peut être réflexive : une fonction peut être composée d ’autres fonctions Rôle et multiplicité : Une classe a un rôle dans une association. Les rôles portent une information de multiplicité précisant le nombre d ’associations auquel une instance d ’objet peut être associée. Les multiplicités les plus courantes sont : 1 / 0..1 / m..n / * /0..* / 1..* Associations

19 Nommage des associations véhiculeconstructeur <construit par Construire> fabricant produit véhiculepersonne Conduit> conducteurvéhicule Possède> propriétairevéhicule <Transporte passagervéhicule entreprisepersonne Dirige> directeursociété Possède> actionnaire société <Emploie employéemployeur

20 PersonneSociétéEmployeur Employé1 0..* m.. n * ou 0.. * 1.. * Un et un seul (obligatoire) Zéro ou un (optionnel) De m à n (entiers) quelconque Au moins 1 Multiplicité des associations

21 Arité des associations Salle EnseignantEtudiant Début Fin Cours lieu Association d’arité 3

22 Placement des attributs et des associations Diplôme TravailEtudiant Chambre Réalise > Note Numéro Mention 0..* * 1

23 Contraintes comptepersonne {Ordonnée} Est_titulaire> * classepersonne {Sous ensemble} 0.. * Parent d ’élève Délégués universitépersonne {Ou-exclusif} 0.. * Enseignants Etudiants

24 Agrégation ChapitreLivre {Ordonnée} * Paragraphe {Ordonnée} 1.. *

25 Composition TêteHomme 1 1 La composition traduit une dépendance existentielle forte.

26 Navigation

27 1..* 1 0..* EstResoluPar 1 0..* 1..* 1 Induit 1..* LesProblèmes LesProjets 1..* LesEtudes 0..1 ComplétéePar 0..* * 0..1 Suivant 0..* * Exemple de diagramme de classes

28 Modèle Statique Passage d ’un diagramme de classe à un modèle relationnel

29 Relation / Table Produit (Réf-produit, Libellé-p, Prix-vente-p) Fournisseur (Code-fournisseur, Adresse, Téléphone) Règle 0 & 1: attribut et classe produit Réf-produit Libellé-p Prix-vente-p fournisseur Code-fournisseur Adresse Téléphone Classe Passage du modèle statique UML au relationnel : les associations

30 Produit (Réf-produit, Libellé-p, Prix-vente-p, Code-fournisseur, remise) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table Règle 2 : relation de multiplicité (1) fournisseur Code-fournisseur Adresse Téléphone Classe < fournir 1 produit Réf-produit Libellé-p Prix-vente-p remise Passage du modèle statique UML au relationnel : les associations

31 Classe Produit (Réf-produit, Libellé-p, Prix-vente-p, remise, Code-fournisseur) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table Règle 3 : relation de multiplicité (0-1) fournisseur Code-fournisseur Adresse Téléphone < fournir 0-1 produit Réf-produit Libellé-p Prix-vente-p remise Passage du modèle statique UML au relationnel : les associations *

32 Produit (Réf-produit, Libellé-p, Prix-vente-p) Fournisseur (Code-fournisseur, Adresse, Téléphone) Relation / Table Fournir (Réf-produit, Code-fournisseur, remise) Règle 4 : relation de multiplicité (0..*) (1..*) fournisseur Code-fournisseur Adresse Téléphone < fournir 0..* ou 1..* produit Réf-produit Libellé-p Prix-vente-p remise Classe Passage du modèle statique UML au relationnel : les associations

33 Père (nom-fils, nom-père) Relation / Table Personne nom père de > Classe 0..* 1 Règle 5 : relation réflexive orientée Passage du modèle statique UML au relationnel : les associations

34 Personne nom frère de Classe Personne (Nom) Frère (nom, nom) Relation / Table Règle 6 relation réflexive symétrique Passage du modèle statique UML au relationnel : les associations Attention, la relation étant transitive, des traitements devront être associés au modèle.