Vous êtes sur la page 1sur 94

Cours Atelier UML

Tarak Chaari
Matre assistant linstitut suprieur dlectronique et de communication
tarak.chaari@gmail.com

UML

Votre interlocuteur
Tarak CHAARI Matre assistant lISECS Membre de lunit de recherche RedCad (ENIS) Recherche: ladaptation dans les environnements dynamiques Enseignement: Ingnierie des systmes dinformation

Tarak CHAARI (ISECS)

UML

Prsentation gnrale du cours

Le nom du cours
Atelier UML

Volume horaire
10.5 heures Cours

Objectifs
Comprendre les fondements de base de UML Pouvoir utiliser et appliquer UML dans des cas rels
Tarak CHAARI (ISECS)

UML

Contenu du cours

Introduction gnrale
Rappels sur les fondements objet Importance de la modlisation Prsentation gnrale dUML

Modlisation objet avec UML


Notations Diagrammes UML et leurs utilits Exemples Exercices
Tarak Chaari (ISECS)

UML

En rodage !!!

Introduction gnrale et rappels

Tarak Chaari (ISECS)

UML

Vision objet dun systme dinformation (1)

Un SI = un ensemble dobjets qui collaborent entre eux

Un objet reprsente une entit du systme qui est caractrise par:


Des frontires prcises Une identit (ou rfrence) Un ensemble dattributs (proprits) dcrivant son tat Un ensemble de mthodes (oprations) dfinissant son comportement

Tarak Chaari (ISECS)

UML

Vision objet dun systme dinformation (2)


Un objet est une instance de classe (une occurrence d'un type abstrait) Une classe est un type de donnes abstrait(modle) , caractris par des proprits (attributs et mthodes) communes des objets et permettant de crer des objets possdant ces proprits.

Tarak Chaari (ISECS)

UML

Vision objet dun systme dinformation (3)


Hritage
Transmission de proprits (attributs et mthodes) dune classe une sous classe dobjets

Tarak Chaari (ISECS)

UML

Vision objet dun systme dinformation (4)


Polymorphisme
Factorisation de comportement (mthodes) commun dobjets

Tarak Chaari (ISECS)

UML

Vision objet dun systme dinformation (5)


Lagrgation
Une relation d'agrgation permet de dfinir des objets composs d'autres objets. L'agrgation permet d'assembler des objets de base, afin de construire des objets plus complexes.

Tarak Chaari (ISECS)

UML

10

Rsum des concepts fondateurs de l'approche objet (1)

L'hritage est un mcanisme de transmission des proprits d'une classe (ses attributs et mthodes) vers une sous-classe. Une classe peut tre spcialise en d'autres classes, afin d'y ajouter des caractristiques spcifiques ou d'en adapter certaines. Plusieurs classes peuvent tre gnralises en une classe qui les factorise afin de regrouper les caractristiques communes d'un ensemble de classes.
Tarak Chaari (ISECS)

UML

11

Rsum des concepts fondateurs de l'approche objet (2)

La spcialisation et la gnralisation permettent de construire des hirarchies de classes. L'hritage peut tre simple ou multiple. L'hritage vite la duplication et encourage la rutilisation. Le polymorphisme reprsente la facult d'une mthode pouvoir s'appliquer des objets de classes diffrentes. Le polymorphisme augmente la gnricit du code.
Tarak Chaari (ISECS)

UML

12

Lapproche objet : une solution parfaites?


L'approche objet est moins intuitive que l'approche fonctionnelle
Quel moyen utiliser pour faciliter lanalyse objet? Quels critres identifient une conception objet pertinente ?

L'application des concepts objets ncessite une grande rigueur


Le vocabulaire prsente des d'ambiguts et des dincomprhension Comment dcrire la structure objet d'un systme de manire pertinente? Comment dcrire linteraction entre ces objets de manire prcise?

Tarak Chaari (ISECS)

UML

13

Remdes aux inconvnients de lapproche objet


Un langage (ou modele) pour exprimer les concepts objet qu'on utilise, afin de pouvoir :
Reprsenter des concepts abstraits (graphiquement par exemple) Limiter les ambiguts (parler un langage commun) Faciliter l'analyse (simplifier la comparaison et l'valuation de solutions)

Une dmarche d'analyse et de conception objet pour :


Ne pas effectuer une analyse fonctionnelle et se contenter d'une implmentation objet, mais penser objet ds le dpart Dfinir les vues qui permettent de couvrir tous les aspects d'un systme, avec des concepts objets

Tarak Chaari (ISECS)

UML

14

Dans quel cas modliser et analyser?


Construire
une niche: cest facile une maison: cest un peu plus compliqu un immeuble: bon l, comment sy prendre?

Nombreux fabricants de logiciels veulent construire des immeubles mais abordent le problme comme dils devaient bricoler une niche Nous construisons des modles pour les systmes complexes parce que nous ne sommes pas en mesure dapprhender de tels systmes dans leur intgralit.
Le guide de lutilisateur UML, Grady Booch, James Rumbaugh et Ivar Jacobson Eyrolles, Octobre 20002.

Tarak Chaari (ISECS)

UML

15

Mais pourquoi analyser et modliser?


Pour viter les rsultats ngatifs suivant:
Les modules ne fonctionnent pas ensemble Le produit est non conforme avec les besoins Le produit est difficile maintenir et faire voluer Le produit prsente beaucoup danomalies et de bugs

Mais aussi pour


Simplifier la problmatique pose par le client Visualiser le systme Spcifier sa structure et son comportement Aider sa construction Travailler en quipe

Tarak Chaari (ISECS)

UML

16

Et cest quoi un modle?


Un modle est une abstraction de la ralit Il s'agit d'un processus qui consiste identifier les caractristiques intressantes d'une entit, en vue d'une utilisation prcise. L'abstraction dsigne aussi le rsultat de ce processus, c'est-dire l'ensemble des caractristiques essentielles d'une entit, retenues par un observateur. Un modle est une vue subjective mais pertinente de la ralit Un modle dfinit une frontire entre la ralit et la perspective de l'observateur. Ce n'est pas "la ralit", mais une vue trs subjective de la ralit. Bien qu'un modle ne reprsente pas une ralit absolue, un modle reflte des aspects importants de la ralit, il en donne donc une vue juste et pertinente.
Tarak Chaari (ISECS)

UML

17

Et UML dans tout a?

UML: langage standard de modlisation des systmes dinformation UML: langage visuel pour
comprendre le systme communiquer et travailler plusieurs aider spcifier, concevoir et dvelopper un systme dinformation avec diffrents modles et diffrentes vues

Tarak Chaari (ISECS)

UML

18

Et dans quel cas lutiliser?

Systmes forte composante logicielle


systmes dinformation pour les entreprises les services bancaires et financiers les tlcommunications les transports la dfense / larospatiale le commerce de dtail llectronique mdicale les services distribus et les applications WEB

Pas limit un domaine prcis


UML

Tarak Chaari (ISECS)

19

UML: un peu dhistoire


3 fondateurs principaux
Grady BOOCH (BOOCH) James Rumbaugh (OMT) Ivar Jacobson (OOSE)

Historique
En 1995: Mthode unifie 0.8 (intgrant les mthodes Booch'93 et OMT) En 1995: UML 0.9 (intgrant la mthode OOSE) En 1996: UML 1.0 (propose l'OMG) En 1997: UML 1.1 (standardise par l'OMG) En 1998: UML 1.2 En 1999: UML 1.3 En 2000: UML 1.4 En 2003: UML 1.5 En 2004: UML 2.0 En 2010: UML 2.3 beta
UML
20

OMT

BOOCH

OOSE

UML 0.8 UML 0.9


OMG

UML 1.0

Tarak Chaari (ISECS)

Caractristiques dUML
UML cadre l'analyse objet, en offrant
diffrentes vues (perspectives) complmentaires d'un systme, qui guident l'utilisation des concept objets, plusieurs niveaux d'abstraction, qui permettent de mieux contrler la complexit dans l'expression des solutions objets.

UML est un support de communication


Sa notation graphique permet d'exprimer visuellement une solution objet. L'aspect formel de sa notation limite les ambiguts et les incomprhensions. Son aspect visuel facilite la comparaison et l'valuation de solutions. Son indpendance (par rapport aux langages d'implmentation, domaine d'application, processus...) en font un langage universel.
UML

Tarak Chaari (ISECS)

21

Alors UML, cest la solution tout?


UML nest quun ensemble de formalismes dapprhender un problme et de le modliser Un formalisme nest quun outil Le succs = savoir utiliser les outils Ce nest pas un algorithme ou une mthode automatique appliquer UML laisse la libert de penser IMAGINATION IS MORE IMPORTANT THAN KNOWLEGDE (A. Einstein) permettant

Tarak Chaari (ISECS)

UML

22

Et comment lutiliser alors?


Avant tout, une bonne dmarche qui permet de : Bien comprendre les demandes et exigences des utilisateurs finaux Bien communiquer avec le client Tenir compte des changements du cahier des charges Empcher la dcouverte tardive de dfauts srieux dans le projet Traiter au plus tt tous les points critiques du projet Bien matriser la complexit Favoriser la rutilisation Dfinir une architecture robuste Faciliter le travail en quipe
Tarak Chaari (ISECS)

UML

23

Et pourquoi une dmarche?

Tarak Chaari (ISECS)

UML

24

Les dmarches ou mthodes


3 types de dmarches:
Itrative et incrmentale guide par lutilisateur centre sur larchitecture
Analyse des besoins Spcifications (cahier de charge) Conception / tude Dveloppement Ce nest pas la seule mthode de travail !!!
(VOIR COUR GENIE LOGICIEL)

Test/validation
UML

Tarak Chaari (ISECS)

25

Passons aux choses srieuses !!!

MODELISATION OBJET AVEC UML

Tarak Chaari (ISECS)

UML

26

Les lments de modlisation (1)

Les objets

jean : Personne

la description dune entit du monde rel ou virtuel

Les classes
la description dun ensemble dobjets

Personne

Les tats
une tape de la vie dun objet
Attente

Les acteurs
utilisateurs finaux du systme
administrateur
Tarak Chaari (ISECS)

UML

27

Les lments de modlisation (2)


Les cas dutilisation
ajouterUtilisateur

Une manire dont un acteur utilise le systme

Les noeuds
Un dispositif matriel
Serveur

Les paquetages
Une partition du modle
IHM

Les notes
Un commentaire, une explication ou une annotation
remarques
Tarak Chaari (ISECS)

UML

28

Les diagrammes UML

Tarak Chaari (ISECS)

UML

29

Les diagrammes UML

Diagramme des cas dutilisation


(Ivar Jacobson)

Tarak Chaari (ISECS)

UML

30

Diagramme de cas dutilisation (0)


Une rflexion sur les fonctionnalits attendues du futur systme avant la conception Avoir une ide (mme assez vague) sur les grands modules du systme Les fonctionnalits composant que doit fournir chaque

Ces fonctionnalits vont aider les utilisateurs effectuer leur mission

Tarak Chaari (ISECS)

UML

31

Diagramme de cas dutilisation (1)


La dtermination et la comprhension des besoins sont souvent difficiles il faut clarifier et organiser les besoins des clients (les modliser). Les use cases permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un systme Ils centrent l'expression des exigences du systme sur ses utilisateurs Ils se limitent aux proccupations "relles" des utilisateurs ; ils ne prsentent pas de solutions d'implmentation et ne forment pas un inventaire fonctionnel du systme Ils identifient les utilisateurs du systme (acteurs) et leur interaction avec le systme Ils permettent de classer les acteurs et structurer les objectifs du systme
Tarak Chaari (ISECS)

UML

32

Diagramme de cas dutilisation (2)


Le DCU dcrit sous la forme dactions et de ractions le comportement externe du systme Le comportement externe = du point de vue des utilisateurs Il permet de dfinir les frontires du systme et les relations entre le systme et lenvironnement Un DCU comprend les acteurs, le systme et les ses cas dutilisation.
UML

Tarak Chaari (ISECS)

33

Diagramme de cas dutilisation (3)

Quest ce quun cas dutilisation?


Un cas dutilisation (use case) reprsente un ensemble de squences dactions ralises par le systme et produisant un rsultat observable intressant pour un acteur particulier Un cas dutilisation modlise un service rendu par le systme. Il exprime les interactions acteurs/systme et apporte une valeur ajoute notable lacteur concern Exemples: Achat billet, Ouverture compte, Livraison Client, Traiter commande, tablir facture

Tarak Chaari (ISECS)

UML

34

Diagramme de cas dutilisation (4)

Quest ce quun acteur?


Un acteur reprsente le rle jou par quelque chose ou quelquun se trouvant dans lenvironnement du systme tudi Un acteur est en relation avec le mtier de lentreprise et interagit avec le systme dans diffrents cas dutilisation Il peut tre un lment de la structure de lentreprise tel quune direction, un service ou un poste de travail

Tarak Chaari (ISECS)

UML

35

Diagramme de cas dutilisation (5)


Types dacteurs
Par dfaut, le rle dun acteur est principal . Si ce nest pas le cas on peut indiquer le rle secondaire sur lacteur Si un acteur a pour rle unique de consommer des informations du systme sans modifier ltat de celui-ci au niveau mtier alors son rle est secondaire Un acteur peut aussi tre un priphrique externe ou un systme externe

Tarak Chaari (ISECS)

UML

36

Diagramme de cas dutilisation (6)


Les cas dutilisation: porte
Les Cas dutilisation interviennent tout au long du cycle de vie dun projet

Comprend

Exprime

Analyste
Conoit

Utilisateur

Architecte

Les cas dutilisation servent de fil conducteur pour lensemble du projet Testeur
Vrifie Ralise secondaire

Programmeur
Tarak Chaari (ISECS)

UML

37

Diagramme de cas dutilisation (3)

Tarak Chaari (ISECS)

UML

38

Diagramme de cas dutilisation (8)

Tarak Chaari (ISECS)

UML

39

Diagramme de cas dutilisation (9)

Tarak Chaari (ISECS)

UML

40

Diagramme de cas dutilisation (10)

Extension des acteurs

Employer

<< extends >>

Chef de service

Tarak Chaari (ISECS)

UML

41

Exemple dun diagramme de cas dutilisation

Tarak Chaari (ISECS)

UML

42

Synthse sur les diagrammes de cas dutilisation


Premire tape faire (capture des besoins) Cas dutilisation: chaque comportement du systme attendu par lutilisateur
Dfinir le primtre du systme : Paquetage Inventorier les acteurs (ceux qui utiliseront le futur logiciel) valuer les besoins de chaque acteur en CU Regrouper ces CU dans un diagramme prsentant une vue synthtique du paquetage Possibilit de documentation des CU complexes (cahier de charge) Na pas descendre trop bas et rinventer lanalyse fonctionnelle
Tarak Chaari (ISECS)

UML

43

A vous de jouer

laborez le diagramme des cas dutilisation dune agence de voyage. Pour organiser un voyage, lagent doit rserver au client une chambre dhtel, lui rserver un billet davion ou de train, lui rserver un taxi pour venir de laroport ou de la gare et enfin, lui tablir une facture. Certains clients peuvent demander une facture plus dtaille

Tarak Chaari (ISECS)

UML

44

Les diagrammes UML

Diagramme de classes

Tarak Chaari (ISECS)

UML

45

Diagramme de classes (1)


Les classes (1)

Tarak Chaari (ISECS)

UML

46

Diagramme de classes (2)


Les classes (2)

Tarak Chaari (ISECS)

UML

47

Diagramme de classes (3)


Associations entre les classes (gnralits)

Tarak Chaari (ISECS)

UML

48

Diagramme de classes (4)


Associations entre les classes (cardinalits)
n : exactement n instances de la classe (n entier >= 0) 0..1 : zro ou une instance m..n : de m n instances * : zro plusieurs instances 1..* : un plusieurs instances (maximum non fix)

Tarak Chaari (ISECS)

UML

49

Diagramme de classes (5)


Associations entre les classes (classes dassociation)

Tarak Chaari (ISECS)

UML

50

Diagramme de classes (6)


Associations entre les classes (qualifications)

Tarak Chaari (ISECS)

UML

51

Diagramme de classes (7)


Associations entre les classes (hritage)

Tarak Chaari (ISECS)

UML

52

Diagramme de classes (8)


Associations entre les classes (agrgation)

Tarak Chaari (ISECS)

UML

53

Diagramme de classes (9)


Associations entre les classes (composition)

Tarak Chaari (ISECS)

UML

54

Diagramme de classes (10)


Associations entre les classes (interfaces)

Comparable CollectionOrdonne
implements

Tarak Chaari (ISECS)

UML

55

Diagramme de classes (11)


Associations entre les classes (dpendances)
FenetreGraphique
instancie

BoiteDeDialogue

Triangularisation

utilise

OutilsMathBasiques
+ addition(int x, int y) + multiplication(int x, int y)

java.rmi

dpend de

java.net

Tarak Chaari (ISECS)

UML

56

Diagramme de classes (12)


Associations entre les classes (contraintes)

Tarak Chaari (ISECS)

UML

57

Diagramme de classes (Synthse)


Un diagramme de classes est une collection d'lments de modlisation statiques (classes, paquetages...), qui montre la structure d'un modle de donnes Un diagramme de classes fait abstraction des aspects dynamiques et temporels Pour un modle complexe, plusieurs diagrammes de classes complmentaires doivent tre construits Pour russir un diagramme de classes:
identifier les entits (ou classes) pertinentes identifier leurs interactions (relations et cardinalits) utiliser les designs patterns (singleton, hritage)
UML

Tarak Chaari (ISECS)

58

A vous de jouer (1)


Gestion de la cit U (diagramme de classes) Une Cit U est constitue d'un ensemble de btiments. Un btiment comporte un certain nombre de chambres. La cit peut employer du personnel et est dirig par lun des employs. Chaque chambre de la cit se loue un prix donn (suivant ses prestations). L'accs aux salles de bain est compris dans le prix de la location d'une chambre. Certaines chambres comportent une salle de bain, mais pas toutes. Les htes de chambres sans salle de bain peuvent utiliser une salle de bain sur le palier. Ces dernires peuvent tre utilises par plusieurs htes. Une personne peut louer une et une seule chambre et une chambre peut tre lou par une ou deux personnes. Les pices de la Cit U qui ne sont ni des chambres, ni des salles de bain (hall d'accueil, cuisine...) ne font pas partie de l'tude (hors sujet).
Tarak Chaari (ISECS)

UML

59

A vous de jouer (2)

laborer le diagramme de classes impliquant les entits suivantes:


Forme graphique (toute forme graphique est dessinable) Forme euclidienne (on peut calculer son aire) Ellipse, trapze, cercle, rectangle

Tarak Chaari (ISECS)

UML

60

Les diagrammes

Diagramme de squence

Tarak Chaari (ISECS)

UML

61

Diagramme de squence (1)


Les diagrammes de squences permettent de reprsenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages Contrairement au diagramme de collaboration, on n'y dcrit pas le contexte ou l'tat des objets, la reprsentation se concentre sur l'expression des interactions Les diagrammes de squences peuvent servir illustrer un cas d'utilisation L'ordre d'envoi d'un message est dtermin par sa position sur l'axe vertical du diagramme ; le temps s'coule "de haut en bas" de cet axe La disposition des objets sur l'axe du temps n'a pas de consquences pour la smantique du diagramme Les diagrammes de squences et les diagrammes d'tat-transitions sont les vues dynamiques les plus importantes d'UML
Tarak Chaari (ISECS)

UML

62

Diagramme de squence (2)


Prsente les interactions chronologiques entre les objets Focalise sur les
objets (les classes) les acteurs (en partie) change de messages scnarii dexcution ligne de vie des objets

Tarak Chaari (ISECS)

UML

63

Diagramme de squence (3)


Messages synchrones et asynchrones
messages synchrones
lmetteur est bloqu jusquau traitement effectif du message

Messages asynchrones
lmetteur nest pas bloqu et il peut poursuivre son excution

Tarak Chaari (ISECS)

UML

64

Diagramme de squence (4)

Problme de lascenseur (simplifi)


tmoinEtage utilisateur 1 : appelAscenseur() 2 : allumer() 4 : teindre() 5 : ouvrir() 6 : demandeEtage() 7 : allumer() 8 : fermer() 9 : dplacer() 3 : dplacer() contrleur Ascenseur Portes

Tarak Chaari (ISECS)

UML

65

A vous de jouer
Une entreprise dsire dvelopper un logiciel de gestion de formation de ses employs. Un employ saisie sa demande de formation dans un formulaire aprs avoir consult le catalogue des formations proposes par lentreprise. Le module de gestion des formations, ajoute cette demande dans la base de donnes et envoie une notification la direction par email (date de saisie, code de lemploy et le code de la formation). La direction consulte les dtails de la formation travers le mme catalogue et rpond lemail du module de gestion par un refus ou un accord. Cet email est transmis par ce module lemploy. En cas daccord, le module envoie les formulaires dinscription ncessaires avec le planning des sessions de formation lemploy.

Tarak Chaari (ISECS)

UML

66

Les diagrammes UML

Diagramme dtats - transitions

Tarak Chaari (ISECS)

UML

67

Diagramme dtat transition (1)


Un diagramme dtats transitions dcrit lvolution dans le temps dun objet et son comportement en rponse aux interactions avec les objets qui peuplent son environnement Les diagrammes d'tats - transitions permettent de dcrire les changements d'tats d'un objet, en rponse aux interactions avec d'autres objets ou avec des acteurs Un tat se caractrise par sa dure et sa stabilit, il reprsente une conjonction instantane des valeurs des attributs d'un objet Une transition reprsente le passage instantan d'un tat vers un autre

Tarak Chaari (ISECS)

UML

68

Diagramme dtat transition (2)

Associ chaque classe intressante du diagramme de classes Il permet de visualiser lvolution dun objet au cours de sa vie sous la forme dun automate. Il est une abstraction des comportements possibles limage des diagrammes de classes qui sont les abstractions de la structure statique

Tarak Chaari (ISECS)

UML

69

Diagramme dtat transition (3)


Chaque tat possde un nom qui lidentifie Les tats se caractrisent par la notion de dure et de stabilit. Un Objet est toujours dans un tat donn pour un certains temps et un objet ne peut pas tre dans un tat inconnu ou non dfini Un tat est toujours limage de la conjonction instantan des valeurs contenues par les attributs de lobjet, et de la prsence ou non de ses liens avec dautres objets
UML

Tarak Chaari (ISECS)

70

Diagramme dtat transition (4)


Une transition est dclenche par un vnement. En d'autres termes : c'est l'arrive d'un vnement qui conditionne la transition Les transitions peuvent aussi tre automatiques, lorsqu'on ne spcifie pas l'vnement qui la dclenche En plus de spcifier un vnement prcis, il est aussi possible de conditionner une transition, l'aide de "gardes" : il s'agit d'expressions boolennes, exprimes en langage naturel (et encadres de crochets)
Tarak Chaari (ISECS)

UML

71

Diagramme dtat transition (5)


tats, transition et vnement, notation :

transition conditionnelle :
[entre valide] saisieValeur [erreur saisie] confirmation

afficherProblme

Tarak Chaari (ISECS)

UML

72

Diagramme dtat transition (6)

Tarak Chaari (ISECS)

UML

73

A vous de jouer

Reprsentez par un diagramme dtats transitions les tats que peu prendre un individu vis--vis la scurit sociale: vivant, dcd, mineur, majeur, clibataire, mari, veuf et divorc Une porte munie dune serrure offre les oprations ouvrir, fermer, verrouiller (simple tour et double tour) et dverrouiller
reprsentez le diagramme tats-transitions dune serrure reprsentez le diagramme tats-transitions dune porte avec verrou

Tarak Chaari (ISECS)

UML

74

Les diagrammes

Diagramme dactivits

Tarak Chaari (ISECS)

UML

75

Diagramme dactivits (1)


UML permet de reprsenter graphiquement le comportement d'une mthode ou le droulement d'un cas d'utilisation, l'aide de diagrammes d'activits (une variante des diagrammes d'tats - transitions). Une activit reprsente une excution d'un mcanisme, un droulement d'tapes squentielles. Le passage d'une activit vers une autre est matrialis par une transition. Les transitions sont dclenches par la fin d'une activit et provoquent le dbut immdiat d'une autre (elles sont automatiques).
Tarak Chaari (ISECS)

UML

76

Diagramme dactivits (2)


Les diagrammes dactivits offrent un pouvoir dexpression trs proche des langages de programmation objet
dclarations de variables, affectation structures de contrles (conditionnelles, boucles) appel doprations, exceptions

Il peuvent aussi tre utiliss pour des descriptions dtailles de cas dutilisation En thorie, tous les mcanismes dynamiques pourraient tre dcrits par un diagramme d'activits, mais seuls les mcanismes complexes ou intressants mritent d'tre reprsents.
Tarak Chaari (ISECS)

UML

77

Diagramme dactivits (3)

Les diagrammes dactivits permettent de dcrire le comportement de:


une opration une classe cas dutilisation
Bas niveau

Haut niveau

Tarak Chaari (ISECS)

UML

78

Diagramme dactivits (4)


Notations

Tarak Chaari (ISECS)

UML

79

Diagramme dactivits (5)


Synchronisation

Tarak Chaari (ISECS)

UML

80

Diagramme dactivits (6)

Tarak Chaari (ISECS)

UML

81

A vous de jouer

Diagramme dactivits de validation dachat en ligne


Un site de vente en ligne propose des produits placs dans un panier virtuel. Pour valider ses achats, lutilisateur clique sur le bouton valider. On lui propose alors de se connecter un compte existant ou den crer un sil en a pas encore. Pour crer un nouveau compte, lutilisateur doit fournir une adresse de messagerie, qui sert galement de login, son nom et son adresse, ventuellement une adresse de livraison et ses coordonnes bancaires. On prvoit le cas o ladresse de messagerie est dj associe un compte. Si la validation de ces information russit, on propose lutilisateur une confirmation dfinitive de lachat
Tarak Chaari (ISECS)

UML

82

Les diagrammes

Diagramme de composants

Tarak Chaari (ISECS)

UML

83

Diagramme de composants (1)


Les diagrammes de composants permettent de dcrire l'architecture physique et statique d'une application en terme de modules : fichiers sources, librairies, excutables, etc Les dpendances entre composants permettent notamment d'identifier les contraintes de compilation et de mettre en vidence la rutilisation de composants Le composants peuvent tre organiss en paquetages, qui dfinissent des sous-systmes
Tarak Chaari (ISECS)

UML

84

Diagramme de composants (2)


Les diagrammes de composants sont gnralement utiliss pour identifier les diffrents modules dun systme dinformation et leurs interactions Notations
Interfaces offertes

Composant

Interfaces utilises

RequetesSQL

Tarak Chaari (ISECS)

SGBD

rechercher

Moteur de recherche

UML

85

Les diagrammes

Diagramme de dploiement

Tarak Chaari (ISECS)

UML

86

Diagramme de dploiement (1)

Les diagrammes de dploiement montrent la disposition physique des matriels qui composent le systme et la rpartition des composants sur ces matriels. Les ressources matrielles sont reprsentes sous forme de noeuds. Les noeuds sont connects entre eux, l'aide d'un support de communication. Les diagrammes de dploiement peuvent montrer des instances de noeuds (un matriel prcis), ou des classes de noeuds.

Tarak Chaari (ISECS)

UML

87

Diagramme de dploiement (2)

Les diagrammes de dploiement servent donner une ide sur larchitecture physique (matrielle) et logique (logicielle) dun systme dinformation Ils dcrivent sur quels dispositifs matriels on va dployer les composants logiciels (les diffrents modules de lapplication) Les natures des lignes de communication entre les dispositifs matriels peuvent tre prcises

Tarak Chaari (ISECS)

UML

88

Tarak Chaari (ISECS)

UML

89

A vous de jouer

Elaborez le diagramme de dploiement dune application impliquant une machine (serv1) hbergeant un systme de gestion de base de donnes (mysql), une machine (serv2) hbergeant un serveur HTTP (tomcat) et une application en JSP et une machine cliente disposant dun navigateur WEB (internet explorer). Les clients peuvent se connecter directement aux bases de donnes sans passer par le serveur HTTP en utilisant lapplication (mysql control center) via le protocole TCP/IP.

Tarak Chaari (ISECS)

UML

90

Synthse rapide
Diagramme de cas dutilisation
ce quon attend du systme

Diagramme de classes
les entits du systme

Diagrammes de squence et de collaboration


comment les entits interagissent

Diagrammes dtats - transitions et dactivits


les tats et les fonctionnalits de chaque entit

Diagrammes de composants et de dploiement


larchitecture du systme
Tarak Chaari (ISECS)

UML

91

Une classification
Vue statique du systme
cas dutilisation classes composants dploiement

Vue dynamique du systme


squence tats - transitions activits

Tarak Chaari (ISECS)

UML

92

Des redondances? Pas vraiment

Diagrammes de composants et de dploiement


ils sont vraiment complmentaires (mme insparables)

Diagrammes dactivits et diagramme dtatstransitions


niveaux dexpressions diffrents mais un diagramme dtats transitions est gnralement suffisant

Tarak Chaari (ISECS)

UML

93

Conclusion: les diagrammes principaux


Diagramme de cas dutilisation
cest l o on assimile les fonctionnalits demandes par le client

Diagramme de classes
le cur de la conception dun systme

Diagramme de squence
indispensable pour comprendre linteraction entre les classes

Diagramme tats- transitions et diagramme dactivits


Toute la dynamique du systme est l
Mais le diagramme de dploiement reste trs utile aussi !!!
Tarak Chaari (ISECS)

UML

94