Cours UML

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
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
UML

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.
UML

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

Polymorphisme
Factorisation de comportement (mthodes) commun dobjets
UML

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.
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.
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.
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?
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
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.
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
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.
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
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
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
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
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
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
UML
23
Et pourquoi une dmarche?
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
25
Passons aux choses srieuses !!!
MODELISATION OBJET AVEC UML
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
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
UML
28
Les diagrammes UML
UML
29
Les diagrammes UML
Diagramme des cas dutilisation

(Ivar Jacobson)
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
UML
31

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
UML
32

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
33
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
UML
34
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
UML
35

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
UML
36

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
UML
37
UML
38
UML
39
UML
40
Extension des acteurs
Employer
<< extends >>
Chef de service
UML
41
Exemple dun diagramme de cas dutilisation
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
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
UML
44
Les diagrammes UML
Diagramme de classes
UML
45
Diagramme de classes (1)

Les classes (1)
UML
46

Les classes (2)
UML
47

Associations entre les classes (gnralits)
UML
48

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)
UML
49

Associations entre les classes (classes dassociation)
UML
50

Associations entre les classes (qualifications)
UML
51

Associations entre les classes (hritage)
UML
52

Associations entre les classes (agrgation)
UML
53

Associations entre les classes (composition)
UML
54

Associations entre les classes (interfaces)
Comparable CollectionOrdonne
implements
UML
55

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
UML
56

Associations entre les classes (contraintes)
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
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).
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
UML
60
Les diagrammes
Diagramme de squence
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
UML
62

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
UML
63

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
UML
64
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
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.
UML
66
Les diagrammes UML
Diagramme dtats - transitions
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
UML
68
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
UML
69

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
70

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)
UML
71

tats, transition et vnement, notation :
transition conditionnelle :
[entre valide] saisieValeur [erreur saisie] confirmation
afficherProblme
UML
72
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
UML
74
Les diagrammes
Diagramme dactivits
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).
UML
76

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.
UML
77
Les diagrammes dactivits permettent de dcrire le comportement de:

une opration une classe cas dutilisation
Bas niveau
Haut niveau
UML
78

Notations
UML
79

Synchronisation
UML
80
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
UML
82
Les diagrammes
Diagramme de composants
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
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
SGBD
rechercher
Moteur de recherche
UML
85
Les diagrammes
Diagramme de dploiement
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.
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
UML
88
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.
UML
90
Synthse rapide
Diagramme de cas dutilisation
ce quon attend du systme
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
UML
91
Une classification
Vue statique du systme
cas dutilisation classes composants dploiement
Vue dynamique du systme

squence tats - transitions activits
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
UML
93
Conclusion: les diagrammes principaux

Diagramme de cas dutilisation
cest l o on assimile les fonctionnalits demandes par le client
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 !!!
UML
94

Cours UML

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours UML

Uploaded by

Copyright:

Available Formats

Cours Atelier UML

Tarak CHAARI (ISECS)

Prsentation gnrale du cours

Modlisation objet avec UML

Introduction gnrale et rappels

Tarak Chaari (ISECS)

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:

Tarak Chaari (ISECS)

Vision objet dun systme dinformation (2)

Tarak Chaari (ISECS)

Vision objet dun systme dinformation (3)

Tarak Chaari (ISECS)

Vision objet dun systme dinformation (4)

Tarak Chaari (ISECS)

Vision objet dun systme dinformation (5)

Tarak Chaari (ISECS)

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

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

Lapproche objet : une solution parfaites?

L'application des concepts objets ncessite une grande rigueur

Tarak Chaari (ISECS)

Remdes aux inconvnients de lapproche objet

Une dmarche d'analyse et de conception objet pour :

Tarak Chaari (ISECS)

Dans quel cas modliser et analyser?

Tarak Chaari (ISECS)

Mais pourquoi analyser et modliser?

Mais aussi pour

Tarak Chaari (ISECS)

Et cest quoi un modle?

Et UML dans tout a?

Tarak Chaari (ISECS)

Et dans quel cas lutiliser?

Systmes forte composante logicielle

Pas limit un domaine prcis

Tarak Chaari (ISECS)

UML: un peu dhistoire

UML 0.8 UML 0.9

Tarak Chaari (ISECS)

UML est un support de communication

Tarak Chaari (ISECS)

Alors UML, cest la solution tout?

Tarak Chaari (ISECS)

Et comment lutiliser alors?

Et pourquoi une dmarche?

Tarak Chaari (ISECS)

Les dmarches ou mthodes

Tarak Chaari (ISECS)

Passons aux choses srieuses !!!

MODELISATION OBJET AVEC UML

Tarak Chaari (ISECS)

Les lments de modlisation (1)

la description dune entit du monde rel ou virtuel

Les lments de modlisation (2)

Une manire dont un acteur utilise le systme

Les diagrammes UML

Tarak Chaari (ISECS)

Les diagrammes UML

Diagramme des cas dutilisation

Tarak Chaari (ISECS)

Diagramme de cas dutilisation (0)