Historique. UML est une méthode standardisée par l OMG permettant la modélisation de systèmes.



Documents pareils
basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB Olivier Augereau Formation UML

Diagrammes de Package, de déploiement et de composants UML

Ingénierie des Modèles. Méta-modélisation

IFT2255 : Génie logiciel

Expression des contraintes. OCL : Object C o n t r a i n t L a n g u a g e

Cours STIM P8 TD 1 Génie Logiciel

3. UML - Unified Modeling Language Diagrammes statiques

OCL - Object Constraint Language

Programmer en JAVA. par Tama

Langage propre à Oracle basé sur ADA. Offre une extension procédurale à SQL

UML Diagramme de communication (communication diagram) Emmanuel Pichon 2013

GOL502 Industries de services

Les diagrammes de modélisation

Java Licence Professionnelle CISII,

Conception des systèmes répartis

CC30 Certificat de compétence Conception, développement et animation de sites Web

Cycle de vie du logiciel. Unified Modeling Language UML. UML: définition. Développement Logiciel. Salima Hassas. Unified Modeling Language

Ingénierie Dirigée par les Modèles. Editeurs de modèles. (Eclipse Modeling Tools) Jean-Philippe Babau

Rappel. Analyse de Données Structurées - Cours 12. Un langage avec des déclaration locales. Exemple d'un programme

Diagramme de classes

Développement d un interpréteur OCL pour une machine virtuelle UML.

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml

Langage et Concepts de ProgrammationOrientée-Objet 1 / 40

Java Licence Professionnelle CISII, Cours 2 : Classes et Objets

Génie Logiciel Avancé Cours 3 Le modèle à objets

Formation : Modélisation avec UML 2.0 et Mise en pratique

LMI 2. Programmation Orientée Objet POO - Cours 9. Said Jabbour. jabbour@cril.univ-artois.fr

Table des matières Sources

Plan du cours. Historique du langage Nouveautés de Java 7

3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes

Tutoriel: Création d'un Web service en C++ avec WebContentC++Framework

La démarche MDA. Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti)*

UML (Diagramme de classes) Unified Modeling Language

Chapitre VI- La validation de la composition.

Remote Method Invocation (RMI)

Modélisation UML. Christine Solnon INSA de Lyon - 3IF 1/140.

UML. Diagrammes de classes (suite) Delphine Longuet.

Modèle Entité/Association

Cours de Génie Logiciel

Génie Logiciel avec Ada. 4 février 2013

Cette application développée en C# va récupérer un certain nombre d informations en ligne fournies par la ville de Paris :

Exceptions. 1 Entrées/sorties. Objectif. Manipuler les exceptions ;

Besoins utilisateurs. Quelle démarche pour passer des besoins au code? Code. chapitre1 UNIFIED MODELING LANGUAGE. package LogiqueMetier.

En vue de l obtention du. Discipline : Informatique. Présentée et soutenue par Mohamed HADJ KACEM. Le Jeudi 13 Novembre 2008

as Architecture des Systèmes d Information

Objets et Programmation. origine des langages orientés-objet

Chapitre I : le langage UML et le processus unifié

Générer du code à partir d une description de haut niveau

La persistance des données dans les applications : DAO, JPA, Hibernate... COMPIL 2010 francois.jannin@inp-toulouse.fr 1

openarchitectureware & transformation de modèle Yannick Lizzi Architecte Logiciel itemis France Mail: lizzi@itemis.de

Workflow et Service Oriented Architecture (SOA)

Une introduction à Java

MEMOIRE. Présenté à L École Nationale d Ingénieurs de Sfax. en vue de l obtention du MASTÈRE INFORMATIQUE NTSID. Par.

Encapsulation. L'encapsulation consiste à rendre les membres d'un objet plus ou moins visibles pour les autres objets.

Programmation des Applications Réparties. Parsers XML DOM et SAX

Design patterns. Design patterns - définition. Design patterns - avantages

Pour signifier qu'une classe fille hérite d'une classe mère, on utilise le mot clé extends class fille extends mère

Sommaire. G. Pujolle, F. Ravat, C. Soulé-Dupuy, G. Zurfluh

Patrons de Conception (Design Patterns)

TP n 2 Concepts de la programmation Objets Master 1 mention IL, semestre 2 Le type Abstrait Pile

Composants Logiciels. Le modèle de composant de CORBA. Plan

INITIATION AU LANGAGE C SUR PIC DE MICROSHIP

Rappel sur les bases de données

Meta Object Facility. Plan

Intergiciels pour la répartition CORBA : Common Object Request Broker. Patrice Torguet torguet@irit.fr Université Paul Sabatier

Introduction à Java. Matthieu Herrb CNRS-LAAS. Mars

TP JEE Développement Web en Java. Dans ce TP nous commencerons la programmation JEE par le premier niveau d une application JEE : l application web.

Aide mémoire UML & Java 1ère partie : Introduction. marc.lemaire@u-cergy.fr

Héritage presque multiple en Java (1/2)

Qualité du logiciel: Méthodes de test

BASES DE DONNÉES. CNAM Centre associé de Clermont-Ferrand Cycle A Année J. Darmont I. INTRODUCTION II. LES SYSTÈMES HIÉRARCHIQUES

Architecture d'entreprise : Guide Pratique de l'architecture Logique

Grandes lignes ASTRÉE. Logiciels critiques. Outils de certification classiques. Inspection manuelle. Definition. Test

NFP111 Systèmes et Applications Réparties

Projet Active Object

Institut Supérieur de Gestion. Cours pour 3 ème LFIG. Java Enterprise Edition Introduction Bayoudhi Chaouki

Modélisation de Lignes de Produits en UML *

Projet de programmation (IK3) : TP n 1 Correction

Université de Bangui. Modélisons en UML

INITIATION AU LANGAGE JAVA

RTDS G3. Emmanuel Gaudin

Vérifier la qualité de vos applications logicielle de manière continue

Architecture N-Tier. Ces données peuvent être saisies interactivement via l interface ou lues depuis un disque. Application

Urbanisation des SI. Des composants technologiques disponibles. Urbanisation des Systèmes d'information Henry Boccon Gibod 1

UML et les Bases de Données

Conventions d écriture et outils de mise au point

Exclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011

D une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.

Christian Soutou UML 2. pour les. bases de données. Avec 20 exercices corrigés. Groupe Eyrolles, 2007, ISBN :

Environnements de développement (intégrés)

TD/TP PAC - Programmation n 3

Quatrième partie IV. Test. Test 15 février / 71

Algorithmique et programmation : les bases (VBA) Corrigé

Un ordonnanceur stupide

Introduction au Génie Logiciel

Apprendre Java en 154 minutes

Systèmes d information et bases de données (niveau 1)

Bases de données. Chapitre 1. Introduction

Applet pour visualiser les variables «automate» notifiées

Langage Java. Classe de première SI

Transcription:

UML 2.0 H. Kadima 1

Historique UML est une méthode standardisée par l OMG permettant la modélisation de systèmes. 2

Introduction (1) Caractéristiques d UML C est un langage avec des notations graphiques pour: Spécifier Concevoir Construire Documenter Ce n est pas une méthode ou un processus C est un standard stable (OMG) Facilite l utilisation d outils d aide à la modélisation Ne résout pas tous les problèmes!!! 3

Introduction (2) Les diagrammes Diagramme Diagramme de structure Diagramme comportemental Diagramme de classes Diagramme de package Diagramme d objets Diagramme d activités Diagramme de cas d utilisation Diagramme de composant Diagramme de déploiement Diagramme de structure composite Diagramme d interactions Diagramme de transition d état Diagramme de séquence Diagramme de communication Diagramme vue d ensemble des interactions Diagramme de timing 4

Les 3 axes de modélisation Fonctionnel <<UML>> Diagramme de Cas d Utilisation Décrire les services rendus par le système <<UML>> Diagramme de Classes Diagramme d Objets Diagramme de Composants Diagramme de Déploiement Décrire les acteurs et les concepts structurant le système Statique Décrire le fonctionnement dynamique du système Dynamique <<UML>> Diagramme d Activités Diagramme de Séquence Diagramme de Collaboration Diagramme d États 5

Diagramme de classes Diagramme centrale du modèle du SI Montre les classes et leurs relations statiques Le plus riche en notations Les erreurs dans ce diagramme ont souvent un impact sur les autres diagrammes 6

Diagramme de classes Concepts fondamentaux Classe Nom Attributs Opérations Commande datederéception estprépayée lignes prix expédier() fermer() 7

Diagramme de classes Commentaires Commentaire Commande datederéception estprépayée lignes prix -- Commentaire commentaire expédier() fermer() 8

Diagramme de classes Attributs Visibilité nom:type multiplicité=valdefaut {contrainte} Visibilité : + public, - privé, # protégé Nom : nom d un champ Type : type d un champ Multiplicité : indique la nature du champ ([0..1] pointeur, [1] valeur, [x..*] conteneur) valdefaut : valeur par défaut Contrainte : information supplémentaire sur l attribut Exemple : -insee:string[1]="" {readonly} 9

Diagramme de classes Multiplicité Équivalent aux cardinalités du modèle E-A Attention au sens de lecture! 0..x : optionnel 1 : unique et obligatoire x..* : multiple A..B : borné 10

Diagramme de classes Opérations Visibilité nom(liste param):type_retour{propriété} Liste param : chaque paramètre peut être détaillé comme un attribut On ne modélise que les opérations qui correspondent à des responsabilités particulières de la classe (pas d accesseurs, etc.) Exemple : +fact(n:int):int {récursive} 11

Diagramme de classes Représentation détaillée (conception) Commande -datederéception[0..1] : Date #estprépayée[1] : Boolean = false -lignes[1..*] : LigneCommande -prix[1] +expédier() : Boolean +fermer() 12

Diagramme de classes Associations unidirectionnelles Permet de représenter les attributs dont le type est une classe du problème Supporte les mêmes informations qu un attribut (cardinalités, visibilité, contraintes, etc.) rôle Commande -datederéception[0..1] : Date #estprépayée[1] : Boolean = false -prix[1] +expédier() : Boolean +fermer() -lignes 1..* LigneCommande -quantité : Integer -prixunitaire : Double +calculertotal() : Double 13

Diagramme de classes Associations bidirectionnelles Lien structurel fort Nécessite la synchronisation des deux classes Personne -nom : String -propriétaire -voitures Voiture -modèle : String 1 * Ou bien Personne -nom : String -propriétaire 1 -voitures * Voiture -modèle : String 14

Diagramme de classes Possibilité de ne nommer que l association Utilisation d un verbe accompagné d un sens de lecture Personne -nom : String possède 1 * Voiture -modèle : String 15

Diagramme de classes Composition Exprime «une partie de» Une classe composant peut faire l objet de plusieurs compositions Un objet de la classe composant ne peut appartenir qu à un seul objet d un composé Cycles interdits! Durées de vie identiques (destructions synchronisées) La «navigabilité» peut être bidirectionnelle ou non Polygone -sommets 1 Point 3..* -centre Cercle 16

Diagramme de classes Agrégation Sémantique identique à la composition Le partage des objets composants est autorisé Durées de vie différentes Entreprise -salariés Personne * * Association 1 * -adhérents 17

Diagramme de classes Identification d une composition (ou agrégation) Assemblage-parties Collection-membres Contenant-contenu Modéliser autant que possible les compositions/agrégations Augmente la lisibilité du modèle Simplifie l implémentation 18

Diagramme de classes Généralisation = héritage Forme Polygone Cercle 19

Diagramme de classes Attention à ne pas confondre héritage et instanciation Voiture -modèle -cylindrée -couleur Ferrari NON! 20

Exemple de diagramme de classes 21

Diagramme de classes Concepts avancés Attributs et opérations statiques Correspondent aux membres static en C++ ou Java Indiqué par un souligné Réservation -identifiant : Integer -date : Date -compteur : Integer +getprochainidentifiant() : Integer 22

Diagramme de classes Classes utilitaires Structuration des variables (et constantes) globales Représentées par des classes stéréotypées Les données membres sont statiques «utility» VariablesGlobales -var1 -var2 23

Diagramme de classes Opérations et classes abstraites Notés en italique Les classes abstraites ont les mêmes relations que les autres classes Liste bool arrivé = begin(); int t = 0; while (next()) t++; return t; +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object 24

Diagramme de classes Concrétisation = héritage Liste +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object Element -valeur : Object -suivant : Element 1 -eltdébut ListeChainee +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean 25

Diagramme de classes Interfaces «Sorte» de classe définie exclusivement par des fonctions abstraites Sert à l implémentation d autres classes et non à leur structure Deux notations : «interface» Conteneur +get(in i : Integer) : Object +size() : Integer Conteneur 26

Diagramme de classes Une interface ne peut avoir d association Elle peut avoir: Des implémentations «interface» Conteneur +get(in i : Integer) : Object +size() : Integer Liste Liste Conteneur +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object 27

Diagramme de classes Des dépendances Commande -lignes[*] «interface» Conteneur +get(in i : Integer) : Object +size() : Integer Commande -lignes[*] Conteneur Commande -lignes[*] Conteneur Liste Liste Liste +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object +begin() : Boolean +next() : Boolean +getvalue() : Object +isempty() : Boolean +size() : Integer +get(in i : Integer) : Object 28

Diagramme de classes Association qualifiée Assimilable à une table associative Le qualificateur (ex: produit) permet d identifier 0 ou une ligne de la commande Pour manipuler (ajouter, consulter, etc.) une ligne d une commande, il faut obligatoirement un produit Commande -datederéception[0..1] : Date #estprépayée[1] : Boolean = false -prix[1] +expédier() : Boolean +fermer() produit -lignes 0..1 LigneCommande -quantité : Integer -prixunitaire : Double +calculertotal() : Double 29

Diagramme de classes Classes-associations Permet d ajouter des attributs, des opérations, etc. sur des liens Personne -numen -nom -adresse * * Emploi -numéro -composante -quotité Emploi occupé -date_début -date_fin 30

Diagramme de classes Implémentation équivalente à : Personne -numen -nom -adresse 1 * Emploi occupé -date_début -date_fin * 1 Emploi -numéro -composante -quotité 31

Diagramme de classes Association n-aire Créneau -date -heure -durée Salle Filière Enseignant 32

Diagramme de classes Contraintes Information supplémentaire sur un élément Placée entre accolade Peut être un texte en langage naturel Ou bien OCL (Object Constraint Language) Repose sur la logique propositionnelle Évite les ambiguïtés du langage naturel Il existe des outils pour OCL Permet de décrire les pré et post-conditions, ainsi que les invariants sur un élément du modèle (attribut, rôle, opération, etc.) 33

Diagramme de classes Exemples : soit le diagramme de classes 1 -directeur Hôtel -adresse : String -leschambres * Chambre -étage : Integer -numéro : Integer -nblits : Integer -lachambre 1 * -lesclients Personne -nom : String -prénom : String -age : Integer -lesrésidents * 34

Diagramme de classes On peut exprimer les contraintes : // Jamais de treizième étage context Chambre inv: self.étage <> 13 // Pas plus de résidents que de lits sauf s il y a un enfant de moins de 4 ans context Chambre inv: lesrésidents->size <= nblits or (lesrésidents>size = nblits + 1 and lesrésidents->exists(p : Personne p.âge < 4)) 35

Diagramme de classes Contraintes entre associations -affectation -lesenseignants 1 Université Enseigne {ou} étudie Personne * -lesetudiants 1 * 36

Diagramme de classes Contraintes de l héritage {incomplete} : les classes dérivées ne couvrent pas toute la classe de base {complete} : les classes dérivées couvrent toutes les possibilités de la classe de base {disjoint} : les classes dérivées sont disjointes donc pas d héritage multiple {overlapping} : l héritage multiple est possible 37

Diagramme de classes Exemples Equidé Cheval Cheval {incomplete} {overlapping } Ane Mâle {complete} {disjoint} Femelle 38

Diagramme de classes Dépendances Relation sémantique mais non structurelle La modification de la cible peut avoir des répercussions sur la source À éviter en analyse car faible intérêt sémantique Source Cible 39

Diagramme de classes Plusieurs stéréotypes : «call» : la source appelle une opération de la cible «create» : la source crée une instance de la cible «permit» : le source est amie de la cible «use» : la source a besoin de la cible pour être implémentée 40

Diagramme de classes Classe paramétrable Le type d un champ est un paramètre de la classe Doit être liée (bind) avec une classe qui instancie le paramètre ListePersonne -élément : Personne «bind»(personne) T Liste -élément : T 41

Diagramme de classes Attributs dérivés Attribut dont la valeur est calculée à partir d autres attributs Souvent associé à une contrainte qui donne la règle de calcul Produit -prixht -TVA -/prixttc {prixttc = prixht*tva} 42

Diagramme de classes Quelques anomalies Classes sans relations Classes sans attribut Classes sans opérations Relation 1-1 Pas forcément à supprimer, mais toujours se poser la question 43

Diagramme de classes La pratique Ne pas utiliser systématiquement toutes les notations En phase d analyse : concepts fondamentaux En phase de conception/implémentation : concepts avancés Bien utiliser UML ne veut pas dire bien modéliser! La théorie ne remplace pas l expérience Les design pattern peuvent améliorer le modèle de conception 44

Diagramme de classes Exemple : Un contrat d édition est un accord entre un auteur (éventuellement collectif) et un éditeur. Les conditions générales d un contrat sont stipulées dans un contrat type. Les clauses particulières sont ajoutées au contrat. Le contrat ne concerne qu un ouvrage, qui ne peut être édité chez un autre éditeur. 45

Diagramme de classes Auteur Editeur 0..* 0..* {disjoint, complete} * * /édite AuteurIndividuel 2..* regroupe 0..* AuteurCollectif ContratEdition porte sur Ouvrage {ordered } * 1 est régit par ContratType 1 46

Diagramme d objets Montre les objets et leurs relations L état des objets est indiqué Utile lorsque les structures de classe sont complexes 47

Diagramme d objets Grace : Personne -enfants 0..* nom = Kelly prénom = Grace mère conjoint 1 -père Personne -nom -prénom -conjoint 0..* -mère 1 Steph : Personne nom = de Monaco prénom = Stéphanie Régnier : Personne nom = de Monaco prénom = régnier Albert : Personne nom = de Monaco prénom = Albert père conjoint 48

Diagramme de packages Package = regroupement d éléments Package de classes, de cas d utilisation, de paquets, etc. Renforce la modularité et la cohérence du modèle global Un élément ne peut appartenir qu à un seul package Gestion des clients 49

Diagramme de packages Diagramme de package = dépendances entre les packages Gestion des comptes Gestion des clients Un package A dépend d un package B si au moins un élément de A dépend d un élément de B La modification du package utilisé peut entraîner la modification du package utilisateur mises à jour synchronisées 50

Diagramme de packages Intérêts: Conserver une vue synthétique Plus d une douzaine d éléments dans un diagramme décomposition en packages = découpage ascendant Organiser l analyse d un problème Montrer les parties (packages) cohérentes Chaque partie est ensuite raffinée = découpage descendant 51

Diagramme de packages Isoler des parties réutilisables Contribue à la vue architecturale Les paquets représentent les couches logicielles Ont parfois une traduction directe dans les LOO (package en JAVA, espace de noms en C++, etc.) 52

Diagramme de packages Décomposer n est pas simple Conserver la logique métier Les structures d un modèle guident la décomposition. Par exemple: Un arbre d héritage Une arborescence de composition de classes 53

Diagramme de packages Éviter les dépendances circulaires couplage fort entre les paquets Gestion des comptes Gestion des clients Gestion des produits 54

Diagramme de transitions d états Montre l évolution du comportement d un objet Un diagramme de T.E. par classe Le fonctionnement de certaines opérations dépend de l état de l objet 55

Diagramme de transitions d états État Un état représente une situation caractéristique d un objet à laquelle correspond un comportement donné Nom État initial État final 56

Diagramme de transitions d états Action Opération atomique instantanée non interruptible Peut être associé à l'entrée ou à la sortie d'un état Transition interne Identique à une auto-transition (voir ci-après) Ne déclenche pas les actions «entry» et «exit» État entry: Action exit : Action Transition interne 57

Diagramme de transitions d états Transition Une transition est provoquée par un événement (une opération) La durée d une transition est considérée comme nulle donc non interruptible 4 catégories d'événements Les appels d'opérations Les signaux (clic de souris, etc.) Les conditions (quand x>10) Les délais (après 5 sec.) 58

Diagramme de transitions d états L étiquette d une transition est composée de: un événement = opération qui provoque la transition une condition = indique s il faut accepter la transition ou pas une action = fonction non interruptible exécutée au moment de la transition Les "auto-transitions" sont possibles Utiles pour répéter les actions associées [Cond]Evénement/Action 59

Diagramme de transitions d états Exemple : alarme de voiture Construction() Neutralisée Activer() Desactiver() Activée Bip()/ Clignotement Bip()/ Clignotement Neutraliser() Bip()/ Clignotement En veille Effraction() Alarme 60

Diagramme de transitions d états Super état Disjoints État Parallèle État A B A B Un seul sous-état est actif Tous les sous-états sont actifs A et B peuvent être des super états 61

Diagramme de transitions d états État historique Lorsqu une transition s arrête à la frontière d un super état, l objet revient dans le dernier sous-état considéré Pseudo-état historique : indique l état lors de la première transition (lorsqu il n y avait pas d historique) 62

Diagramme de transitions d états Exemple Pseudo-état historique 63

Diagramme de cas d utilisation Donne une vue externe du comportement du système Décomposition du système en termes de cas d utilisation et d acteurs Utile pour inventorier les fonctionnalités du système 64

Objectifs du diagramme de cas d utilisation Capturer les besoins : modéliser et documenter les besoins Un cas d utilisation n est pas un besoin mais une fonctionnalité du système devant répondre à un besoin Les diagrammes de cas d utilisation ne permettent pas la spécification des besoins non-fonctionnels 65

Diagramme de cas d utilisation Acteur Ne fait pas partie du système Quelqu un ou quelque chose qui interagit avec le système En relation avec au moins un cas d utilisation Un acteur peut jouer plusieurs rôles Cas d utilisation Représente une fonctionnalité du système 66

Diagramme de cas d utilisation Relation «Communique» Relation non directionnelle entre un acteur et un cas d utilisation Exprime les fonctionnalités primaires du système 67

Diagramme de cas d utilisation Relation «Include» Le comportement de B est inclus dans le comportement de A La fonctionnalité B est nécessaire pour réaliser la fonctionnalité A Permet d exprimer une fonctionnalité commune à plusieurs fonctionnalités (factorisation) A «include» B 68

Diagramme de cas d utilisation Relation «Étend» Équivalent à l héritage entre classes B hérite du comportement de A, et le spécialise B hérite des relations de communication décrites pour A A «extends» B Rq : certains auteurs déconseillent d employer «uses» et «extends». Moi aussi! 69

Diagramme de cas d utilisation Description textuelle d un cas d utilisation : <titre> 1. Intention générale Résumé, acteurs concerné 2. Description détaillée 1. Pré-conditions 2. Scénario principal 1. Étape 1 : description 2. Étape 2 : description 3. Etc. 3. Extensions 1. Étape 2.1 : description 2. Étape 2.2 : description 3. Etc. 4. Post-conditions 5. Contraintes non fonctionnelles 1. Exigences de persistance 2. Exigences d IHM 3. Exigences de performances 4. Etc. Les descriptions textuelles sont plus utiles que les diagrammes!!! 70

Diagramme d activités Logique procédurale, enchaînement des activités (flot) Concepts principaux: Activité : peut correspondre à un message ou un cas d utilisation selon le niveau de détail Arc : matérialise le flot Débranchement : séparation d un flot en flots parallèles Jonction : synchronisation de flots parallèles Décision : aiguillage conditionnel du flot Fusion : marque la fin d un comportement conditionnel 71

Diagramme d activités Nœud Initial Recevoir Commande Activité Débranchement Décision Préparer Commande Envoyer Facture [commande urgente] Arc Livraison Expresse Livraison Normale Recevoir Paiement Fusion Jonction Clôturer Commande 72

Diagramme d activités Partition : montre qui est responsable de quelle activité 73

Diagramme d activités Les signaux La réception d un signal déclenche une activité Lors du déroulement d un flot, un signal peut être émis Un délai est un signal émis automatiquement Emission d un signal Réception d un signal Délai 74

Diagramme de séquence Montre la collaboration des objets impliqués dans un cas d utilisation Insiste sur la chronologie Permet de décrire le scénario principal et ses extensions Attention à conserver la lisibilité du diagramme! 75

Diagramme de séquence Concepts principaux : Les participants (le plus souvent des objets) Une ligne de vie Des zones d activation Les messages L opération et éventuellement ses paramètres Éventuellement son résultat Des structures de contrôle Alt : conditionnelle Loop : boucle Réf : référence à un autre diagramme de séquence (=appel de fonction) Etc. 76

Diagramme de séquence 77

Diagramme de séquence Création et destruction de participants 78

Diagramme de communication Idem diagramme de séquence Insiste sur les relations entre les objets Permet de montrer un scénario particulier Chronologie indiquée par la numérotation des messages Possibilité de faire apparaître des boucle, des conditions (à éviter) 79

Diagramme de communication Les objets Pas de ligne de vie associé à d'autres objets La nature de l'association est décrite par un stéréotype «association» «global» «local» «paramètre» message : l'objet est un attribut : l'objet est une variable globale : l'objet est une variable locale : l'objet est un paramètre d'un Les messages Un message ne peut être envoyé que si une association existe 80

Diagramme de communication 7: getinforemise unecommande unclient «association» uneligne 81 5: CalculerPrixBase 6: CalculerRemise 1: CalculerPrix «parameter» 4: getdétailstarification «association» 2: getquantité 3: getproduit unproduit «local»

Diagramme de composants Montre la répartition physique du code Souvent répartis dans des packages Les relations s expriment à travers leurs interfaces et des dépendances 82

Diagramme de composants Composant1 Composant2 Composant Interface Dépendance Composant3 83

Diagramme de composants Minimiser les dépendances augmente la réutilisabilité Des dépendances hiérarchiques facilitent le développement Les feuilles peuvent être développées en parallèle Permet de déduire le makefile 84

Diagramme de déploiement Montre la répartition des processus qui composent le système Important dans le cas d architecture distribuée Concepts fondamentaux: Les nœuds : dispositifs capables d héberger une partie du logiciel Les arcs : liens physiques connectant les noeuds 85

Exemples de diagramme de déploiement 86

Diagramme de déploiement 87

Diagramme de timing Montre l évolution de l état d un objet ou d un groupe d objets en fonction d évènements temporels 88

Diagramme de vue d ensemble des interactions Mélange du diagramme d activités et du diagramme de séquence 89

Exemples de mise en œuvre de diagrammes UML 2.0 Protocole de liaison de données d un équipement V76 (similaire au protocole LAPD) Trois phases : - Etablissement de la liaison de données - Transfert bidirectionnel - Libération 90

Rappel modèle de référence OSI 91

Diagramme de cas d utilisation 92

Diagramme de séquence alt: Permet de présenter des alternatives Nous pouvons aussi indiquer sous quelle condition la séquence aura lieu 93

Diagramme de séquence opt: Permet de montrer le caractère optionnel de la séquence 94

Diagramme de séquence loop: Permet d indiquer une possibilité de répétition de la séquence 95

Diagramme de séquence break: Décrit une séquence qui permet de sortir du diagramme 96

Diagramme de séquence par: Décrit l exécution parallèle de deux séquences 97

Diagramme de communication Le diagramme de séquence est isomorphe au diagramme de communication On passe de l un à l autre automatiquement 98

Diagramme de déploiement Il modélise l architecture physique du système Forte utilisation des stéréotypes pour les nœuds et les artefacts 99

Diagramme de structures composites Description de la structure interne d'un objet, donc ses points d'interactions avec le reste du système. 100

Diagramme de vue d ensemble des interactions Mixe entre les diagrammes d activités et de séquence 101

Diagramme de timing Description de l état d un élément UML en fonction du temps 102

Une vue simplifiée du métamodèle UML 2.0 A la lecture de ce diagramme, on peut remarquer que : - Toute entité dans UML est un ModelElement et a un nom.. - La métaclasse abstraite Classifier est une généralisation de Class, Interface et DataType. Ils ont en commun des propriétés communes et chacun dispose de quelques spécificités. - Une Class peut implémenter une Interface, mais un DataType ou une Interface ne le peuvent pas. - Un Feature (Attribut, AssociationEnd ou Operation) est une entité ayant exactement un Classifier, il ne peut jamais être une composante de plusieurs Classifiers. - Une association a au minimum deux association-ends, mais peut en avoir plusieurs. etc... 103

Outils UML 2.0 Ateliers de génie logiciel: Rational rose Objecteering WINDEV 9 Artisan RTS Together ArgoUML Tau Generation 2 Rhapsody StarUML Enterprise Architect 104

Interopérabilité entre outils de développement via XMI XMI (XML Metadata Interchange) permet l échange de modèles sérialisés en XML. XMI permet de sérialiser et d échanger des modèles basés sous forme de fichiers en utilisant un dialecte XML 105