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

Transcription

1 UML 2.0 H. Kadima 1

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

3 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

4 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

5 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

6 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

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

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

9 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

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

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

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

21 Exemple de diagramme de classes 21

22 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

23 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

24 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

25 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

26 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

27 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

28 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

29 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

30 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

31 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

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

33 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

34 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

35 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

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

37 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

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

39 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

40 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

41 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

42 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

43 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

44 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

45 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

46 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

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

48 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

49 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

50 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

51 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

52 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

53 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

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

55 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

56 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

57 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

58 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

59 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

60 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

61 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

62 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

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

64 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

65 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

66 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

67 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

68 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

69 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

70 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

71 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

72 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

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

74 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

75 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

76 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

77 Diagramme de séquence 77

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

79 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

80 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

81 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»

82 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

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

84 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

85 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

86 Exemples de diagramme de déploiement 86

87 Diagramme de déploiement 87

88 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

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

90 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

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

92 Diagramme de cas d utilisation 92

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

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

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

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

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

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

99 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

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

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

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

103 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

104 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

105 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