DEVELOPPEMENT WEB & OBJET

MODELISATION ET CONCEPTION OBJET

Filire SMI (semestre 6)

MBARKI SAMIR Dpartement dInformatique

20112011 -2012

Contenu
Chap. Chap. Chap. Chap. Chap. Chap. Chap. Chap. Chap.
S. MBARKI

1 2 3 4 5 6 7 8 9

: : : : : : : : :

Introduction Approche objet Prsentation dUML Diagramme de cas dutilisation Diagramme dactivit Diagrammes de squence Diagramme de classes Diagramme dobjets Diagramme dtatsdtats-transitions
2

CHAPITRE 1

Introduction

S. MBARKI

Le logiciel
Le systme dinformation dune entreprise est compos de matriels et de logiciels Les investissements dans ce systme dinformation se rpartissent :
20% pour le matriel 80% pour le logiciel

Un logiciel est un ensemble de programmes qui assurent des fonctions bien dtermines
Logiciel de gestion de scolarit, logiciel de comptabilit

Un logiciel peut tre dvelopp par une personne ou bien par une quipe suivant sa taille
S. MBARKI 4

Pourquoi le gnie logiciel ?

Programmation petite chelle
Programmation individuelle de petits programmes Algorithmique, Algorithmique , langages de programmation, programmation, structures de donns Peu mthodologique : analyse dscendante

Programmation grande chelle

Travail en quipe sur des projets longs et complexes Traduction du cahier de charges en spcifications prcises Dialogue avec client/utilisateur client/utilisateur (ouverture vers d'autres domaines) domaines ) Besoins : gestion de projet, projet, organisation, organisation, outils, outils, thories, thories, mthodologies et techniques Dmarches dingnierie : gnie logiciel
S. MBARKI 5

Gnie logiciel
Dfinition
Mthodes et outils de production en quipe dun logiciel complexe et multiples versions Logiciel : ensemble de documents d'analyse, d'analyse, de conception et de programmes et documents de tests. Le gnie logiciel comporte galement des aspects de gestion de projets pour matriser le cot du logiciel, logiciel, ses dlais et les risques associs. associs . Le logiciel doit donner satisfaction aux clients.

Programmation vs Gnie logiciel

Programmation : activit personnelle Gnie logiciel : activit dquipe La partie programmation noccupe quentre 10% et 30% de leffort total du cycle de vie.
S. MBARKI 6

Cycle de vie dun logiciel

Il dcrit les diffrentes tapes du processus de dveloppement dun logiciel, depuis le cahier des charges jusqu la fin dexploitation. Le cahier des charges dsigne les caractristiques du systme et les services demands du point de vue client On distingue deux types de cycle de vie :
C.V linaire et C.V itratif

S. MBARKI

Les tapes du cycle de vie

Expression des besoins et analyse
Les fonctionnalits du systme et les contraintes sont tablies en consultant les utilisateurs. Elles doivent tre dfinies de faon comprhensible la fois pour les clients et les dveloppeurs.
Les besoins sont structurs par les cas dutilisation. Lanalyse sert comprendre la forme interne du logiciel et est structure par la ralisation des cas dutilisation en dfinissant les classes danalyse.

Conception du systme
Processus plusieurs tapes et qui consiste reprsenter les diverses fonctions du systme dune manire qui permettra dobtenir un ou plusieurs programmes ralisant ces fonctions. Met le point sur trois proprits : Architecture du logiciel, structures de donnes et le dtail procdural
S. MBARKI 8

Les tapes du cycle de vie (suite)

Ralisation et tests unitaires
Raliser un ensemble dunits de programme crites dans un langage de programmation. Les tests unitaires permettent de vrifier que les units de programme rpondent leurs spcifications

Tests dintgration
On intgre les units de programme et on ralise des tests globales pour tre sr que les besoins ont t satisfaits

Maintenance
Plus longue tape du cycle de vie. Elle consiste :
Corriger les erreurs non dcouvertes lors des tapes prcdentes Adapter le systme aux nouveaux besoins
S. MBARKI 9

Cycle de vie (cascade)

Cycle de vie linaire sans aucune valuation entre le dbut du projet et la validation
Analyse Conception Ralisation Tests Maintenance

S. MBARKI

10

Cycle de vie (spirale)

Flexibilit
modification des spcifications = nouvelle itration

Processus adapt la modlisation objet

S. MBARKI

11

CHAPITRE 2

Approche objet

S. MBARKI

12

Dveloppement procdural
La ralisation d'un logiciel passe par plusieurs tapes :
Le dveloppement constitue la premire partie La deuxime tape constitue la maintenance (corrective ou volutive) et qui occupe 70% du cot total du logiciel

La construction d'un systme informatique se rsume par la formule : Algorithmes + structures de donnes =

Programme
En programmation procdurale, la structure du systme est base sur la procdure (fonction)
S. MBARKI 13

Structure dun programme procdural

Les logiciels sont composs de :
Donnes reprsentant les lments manipuls Une hirarchie de fonctions

Dcoupage de lapplication en fonctions :

S. MBARKI

14

Inconvnients de lapproche procdurale

Les modules trouvs sont adapts uniquement au problme pos Dissociation entre donnes et fonctions Les structures de donnes se trouvent partages entre plusieurs fonctions Interdpendance des fonctions D'o la difficult de maintenance du systme

S. MBARKI

15

Structure dun programme objet

Les objets sont des entits autonomes qui collaborent afin de fournir les fonctionnalits du systme
objet1

Interaction
objet2

objet4

objet3

Interaction

S. MBARKI

16

Avantages du Concept Objet

L'orientation objet permet de modliser le systme sous forme d'objets interagissant les uns avec les autres
Approche plus proche de la ralit tant donn que notre environnement est constitu d'objets tels que : les personnes, les voitures, les maisons, Des programmes structurs en objets sont faciles comprendre Les objets sont indpendants les uns des autres grce au principe d'encapsulation (la communication entre objets est limite leur interface) d'o la recherche et la localisation des erreurs est simplifie Le principe de rutilisabilit et d'extensibilit est assur par le principe d'hritage et d'agrgation
S. MBARKI 17

Acteur principal : objet

En programmation procdurale, on a :
des donnes, qui sont passifs Des fonctions, qui peuvent manipuler ces donnes

Un objet contient la fois des proprits et des oprations qui manipulent ces proprits.
un objet est actif chaque objet est responsable de ses propres proprits.

Lobjet : est une entit fondamentale qui regroupe des propritsproprits -oprations.
S. MBARKI 18

Un objet a un tat
Un objet contient la fois des donnes et des mthodes qui manipulent ces donnes
les donnes reprsentent l'tat de l'objet les donnes peuvent galement dcrire les relations entre cet objet et les autres objets

Exemple : CompteBancaire a :
un solde (l'tat interne du compte) Un propritaire (un objet reprsentant une personne)
S. MBARKI 19

L'encapsulation
Principe d'encapsulation : Runir lintrieur dune mme entit les donnes et les mthodes Abstraction des donnes : la structure dun objet nest pas visible de lextrieur, son interface est constitue de messages invocables par un utilisateur, la rception dun message dclenche lexcution de mthodes Abstraction procdurale : du point de vue de lextrieur, on na aucune information sur la dfinition de la mthode
S. MBARKI 20

L'agrgation
L'agrgation est une association entre deux classes qui traduit la relation appartenir " ou faire partie de" Exemple moteur
voiture

chassis

Les attributs sont des objets appartenant d'autres classes (objets membres) Couplage fort entre abstractions (classes)
S. MBARKI 21

Hirarchie des classes

Permettent de grer la complexit des applications en ordonnant les objets au sein darborescence de classes dabstraction croissante. Les classes descendantes hritent des proprits des classes anctres (Gnralisation(Gnralisation -Spcialisation) La gnralisation permet la cration de classes de base regroupant les proprits et les comportements communs aux classes drives (factorisation). La spcialisation permet la cration de soussous-classes afin dajouter ou modifier certaines proprits ou mthodes dfinies dans les classes de base
S. MBARKI 22

Le polymorphisme
Une mme opration peut se traduire diffremment selon lobjet sur lequel elle sapplique. Objectif du polymorphisme: Pouvoir excuter un message par un objet dont le type varie de faon dynamique. Le systme doit dterminer dynamiquement limplantation de lopration excuter. Synonyme : Liaison dynamique :
Simplicit : Pas besoin de distinguer les cas selon les classes. Evolution : Programmes facilement extensibles (Hritage+Redfinition)
S. MBARKI 23

Prsentation dUML

CHAPITRE 3

S. MBARKI

24

Mthodologies d'analyse et de conception

Les premires mthodes d'analyse (annes 70)
Dcoupage hirarchique fonctionnel du systme (SADT)

L'approche systmique (annes 80)

Modlisation des donnes + modlisation des traitements (Merise)

L'approche objet (1990(1990-1995) : limportant ce sont les objets

Objet = donnes + traitements dbut 1990 : Premires gnrations des mthodologies objets Permet une analyse beaucoup plus fine que lapproche fonctionnelle Prolifration des mthodes: 1990 1990-1995: plus de 50 mthodes objets (OOA/OOD, HOOD, OMT, OOSE, FUSION, )
S. MBARKI 25

UML : fusion de notations

UML : un langage de modlisation standard propos par OMG (Object Management Group) en 1997 UML est une fusion et une synthse des mthodes dominantes :
OOA/OOD de G. Booch OMT (Object Modeling Technique) de Rumbaugh OOSE (Object (Object-Oriented Software Engineering) de Jacobson Autres (statecharts de Harel, Harel, design by contract de Meyer, ) )

UML est un ensemble de notations orientesorientes-objet, dont la syntaxe et la smantique sont (assez) prcisment dfinies UML : peut tre utilis toute tape du cycle de vie dun logiciel mais UML n'est pas une mthode
S. MBARKI 26

UML est un langage

langage = syntaxe + smantique syntaxe = notations graphiques consistant
essentiellement en des reprsentations conceptuelles dun systme smantique = sens prcis pour chaque notation

UML Notation Guide dfinit la syntaxe graphique

d'UML

UML Semantics dfinit la smantique d'UML

http://umlcenter.visualhttp://umlcenter.visual -paradigm.com/umlresources paradigm.com/umlresources/ /
S. MBARKI 27

UML est un langage de modlisation

Quest quun modle?
Un modle est une simplification de la ralit

Pourquoi modliser?
Mieux spcifier/comprendre la structure et le comportement souhaits du systme Mieux communiquer avec le client Documenter les dcisions prises Minimiser les risques dchec de dveloppement dun systme
S. MBARKI 28

Modliser toutes les vues du systme

Le dveloppement dun dun systme logiciel doit tre abord selon diffrentes vues Ces vues refltent les attentes/besoins des diffrents acteurs impliqus dans le dveloppement du systme
utilisateurs, client, analystes, programmeurs, chef du projet,

Ces vues seront prises en compte en se basant sur divers diagrammes

S. MBARKI 29

Les diagrammes d'UML

Les diagrammes UML sont utiliss pour visualiser le systme selon diffrents aspects Ces aspects sont :
Statique/structurel ou Dynamique/comportemental

Les diagrammes contiennent des lments de modlisation, un lment peut apparatre dans diffrents diagrammes
S. MBARKI 30

Les diagrammes d'UML (suite)

S. MBARKI

31

Les diagrammes structurels d'UML : vue d'ensemble

Diagrammes structurels logiques (au niveau danalyse) diagramme de classes diagramme dobjets Diagrammes structurels physiques (au niveau dimplantation) diagramme de composants
Il permet de dcrire l'architecture physique du systme en terme de modules : fichiers sources, librairies, excutables, etc.

diagramme de dploiement
Il montre la disposition physique des matriels qui composent le systme et la rpartition des composants sur ces matriels.
S. MBARKI 32

Les diagrammes dynamiques d'UML : vue d'ensemble

Diagramme de cas dutilisation (dcrit les besoins fonctionnels dun acteur interagissant avec le systme) Diagrammes de squences (interactions entre un ensemble dobjets + messages changs et leur ordre temporel) Diagramme de communication (interactions entre un ensemble dobjets + messages changs et l'ordre est reprsent par des numros) Diagramme de transition d'tat (dcrit les squences dtats quun objet peut parcourir durant sa vie en rponse aux vnements qui lui adviennent) Diagramme dactivit activits s (enchanement dactivits: squentiel, parallle, conditionnel)
S. MBARKI 33

Les mcanismes communs

UML dfinit des mcanismes communs qui assurent lintgrit conceptuelle de la notation :
Strotypes Valeurs marques Contraintes Notes commentaires Paquetages
S. MBARKI 34

Les strotypes
Mcanisme d'extensibilit d'UML. Il introduit de nouvelles classes (spcialisation des classes existantes) Un strotype est un mcanisme qui permet la classification dun lment dUML lorsque la smantique de base est insuffisante.
Notation: << <<strotype strotype>> >>
S. MBARKI 35

Quelques strotypes standards d'une classe

<<metaclass>> Domaine

ses instances sont des classes

<<interface>> Transaction

<<utility>> Maths

une classe dont tous les attributs/mthodes sont statiques

<<exception>> DivisionPar0

S. MBARKI

36

Cas des strotypes Entity, Boundary et Control

Classe <<Entity <<Entity>> >>
Modlise la catgorie d'objets qui ont une dure de vie importante dans le systme

Classe <<Boundary <<Boundary>> >>

Modlise la communication des classes entity avec l'extrieur du systme (l'utilisateur)

Classe <<Control>>
Sert coordonner les changes de messages entre les autres classes pour raliser un Use case
S. MBARKI 37

Cas du strotype Utility

Classe <<Utility>>
Contient un ensemble d'attributs et de mthodes accs libre Ces mthodes nappartiennent aucune instance En gnral, ces mthodes offrent un ensemble de fonctionnalits utiles dans plusieurs contextes:
Fonctions mathmatiques, Algorithmes de tri Algorithmes de recherche, Etc.
S. MBARKI 38

Les valeurs marques

C'est une paire (nom, valeur) qui permet d'ajouter une nouvelle proprit un lment de modlisation Spcification de la valeur marque : {nom = valeur}
classe A
{auteur = Alami}

Attributs Oprations
S. MBARKI 39

Les notes
Une note est un symbole graphique contenant du texte et/ou graphiques offrant un commentaire, une contrainte, le contenu dune mthode ou des valeurs marques propos dun lment du modlisation

Voir encrypt.doc

Voir http://www. doc.com

S. MBARKI

40

Les contraintes
Une contrainte est une rgle de gestion lie un lment du modle. Les contraintes sont formules en langage naturel ou en langage formel (OCL)
Classe C +racineCarre (valeur):reel
{valeur > 0}

S. MBARKI

41

Les commentaires
Un commentaire fournit des explications utiles, des observations de diffrentes natures ou des renvois vers des documents de description plus complets
Classe C +racineCarre (valeur):reel
valeur > 0 contrainte Renvoie valeur ^0.5 contenu de la mthode

S. MBARKI

42

Les packages
Pour les systmes comprenant plusieurs classes, il convient de regrouper cellescelles-ci en entits logiques, les

packages
Un package UML reprsente un espace de nommage qui peut contenir:
Des lments de modlisation Dautres packages
S. MBARKI 43

Les packages (suite)

Les lments contenus dans un package:
Doivent reprsenter un ensemble fortement cohrent Sont gnralement de mme nature et de mme niveau smantique

Le regroupement d'lments est un critre logique. L'objectif de dcomposition est d'avoir une forte cohrence interne et un faible couplage externe Un package est reprsent par un dossier (folder (folder) )
IHM

S. MBARKI

44

Les dpendances entre packages

Les classes contenues dans un paquetage embot voient les lments contenues dans leur paquetage englobant UML dfinit deux strotypes standard associs aux paquetages :
<<importe>> : ajoute les lments dans l'espace de nommage source <<accde>> : rfrencer des lments de destination
Destination1 Source

<<importe>>
Destination 2

<<accde>>
S. MBARKI 45

Diagramme de cas dutilisation

CHAPITRE 4

S. MBARKI

46

Dfinition (1)
Jacobson, 1992
une faon spcifique dutiliser le systme en utilisant une partie de sa fonctionnalit. [Un use case] constitue une squence complte dinteractions qui a lieu entre un acteur et le systme une interaction typique entre un utilisateur et un systme informatique [qui] capture une fonction dintrt pour lutilisateur [et qui] permet datteindre un but discret pour lutilisateur la spcification de squences dactions, pouvant inclure des variantes ou des squences derreur, quun systme, soussous-systme ou classe peuvent excuter en interagissant avec des acteurs extrieurs
47

Fowler, 1997

Rumbaugh et al, 1999

S. MBARKI

Dfinition (2)
Un cas dutilisation est une technique de description des besoins fonctionnels dun systme informatique Chaque besoin fonctionnel est indiqu par une srie dinteractions entre lutilisateur et le systme Un scnario est une squence dtapes de description dune interaction entre lutilisateur et le systme
S. MBARKI 48

Exemple (1)
Site de vente en ligne de matriel lectronique (www.microchoix.ma www.microchoix.ma) )
Use case : acheter un produit Description narrative du scnario : Le client consulte le catalogue, choisit des articles et les ajoute dans son panier virtuel. virtuel. Quand le client souhaite payer, il remplit, remplit, dans un formulaire, formulaire, ses coordonnes (adresse adresse), ), les informations de sa carte bancaire et confirme lachat lachat. . Le systme vrifie lautorisation de la carte bancaire et confirme lachat immdiatement et en envoyant un e e-mail au client
S. MBARKI 49

Exemple (2)
Ce scnario est ralisable et peut se drouler de faon normale Scnario 2 ( (scnario scnario alternatif) alternatif) : Un client fidle na pas besoin de fournir ni les informations de sa carte bancaire ni ses coordonnes Scnario 3 (scnario (scnario exceptionnel) exceptionnel) : Echec de lautorisation de paiement par carte bancaire Bien quils soient diffrents, ces trois scnarios sont similaires car ils ralisent le mme objectif (acheter un produit)
S. MBARKI 50

Elments de modlisation : Acteur (1)

Rle jou par une entit externe (humain, matriel, systme) qui interagit avec le systme tudi Les acteurs sont identifis en observant les utilisateurs directs du systme, ceux qui sont responsables de son exploitation ou de sa maintenance, ainsi que les autres systmes qui interagissent avec le systme tudi Une mme personne peut jouer les rles de plusieurs acteurs (client, vendeur) Plusieurs personnes peuvent jouer le mme rle (tous les clients)
S. MBARKI 51

Elments de modlisation : Acteur (2)

Notation :
uc system actor Client
uc system

Client

Exemple dacteurs :
Client, Repssentant du service client, directeur de ventes, ventes, administrateur de bases de donnes, donnes, matriel externe externe, , systme externe, externe ,

Tout acteur doit communiquer avec le systme

S. MBARKI 52

Elments de modlisation : Cas dutilisation (1)

Un cas dutilisation est une unit cohrente qui reprsente un ensemble de comportements fournis par un systme un ou des acteurs. Un cas dutilisation modlise un service rendu par le systme, sans dcrire le mode de ralisation de ce service Notation :
uc system Retirer argent

S. MBARKI

53

Description dun cas dutilisation (1)

Acheter un produit Scnario principal : 1. 2. 3. 4. 5. 6. 7. 8. Le Le Le Le Le Le Le Le client consulte le catalogue et choisit des articles client passe au paiement client remplit ses coordonnes et le mode de livraison systme affiche le prix total payer, livraison incluse client fournit les informations de sa carte bancaire systme vrifie si le client est autoris systme confirme lachat immdiatement systme envoie une confirmation par e-mail au client

Extensions : 3a: Le client est fidle .1: Le systme affiche les informations (articles choisis, prix, facture) .2: Le client accepte ou rectifie ces informations, passer ltape 6 6a: Le systme nautorise pas le client .1: Le client introduit les informations dune autre carte bancaire ou annule lopration
S. MBARKI 54

Description dun cas dutilisation (2)

On dcrit le cas dutilisation par le scnario principal comme une squence dtapes numrotes :
Chaque tape dans le cas dutilisation est un lment de linteraction entre lacteur et le systme

Dans la description du scnario scnario, , un cas dutilisation peut inclure un autre cas dutilisation (lien hypertexte) hypertexte) La partie extension ajoute une condition qui change les interactions du scnario principal et peut produire une erreur On peut aussi dcrire le cas dutilisation par :
Une prpr-condition : une condition qui doit tre vrifie avant dentamer le cas dutilisation
S. MBARKI 55

Relation entre acteur et cas dutilisation

Association
Relie un acteur un cas dutilisation montrant que lacteur participe au cas dutilisation
uc system

Retirer argent

Tlcharger un fichier Internaute effectuer un v irement

Client

S. MBARKI

56

Relations entre cas dutilisation (1)

Extension
Le Use Case est une spcialisation dun autre Use Case plus gnral. Le Use Case plus spcifique ninclut pas ncessairement tout le comportement du Use Case quil spcialise Elle associe un use case U1 un use case U2 (flche allant de U1 U2), spcifiant que le comportement de U1 peut tre occasionnellement insr dans U2 et U1 peut sexcuter de manire autonome
S. MBARKI 57

Relations entre cas dutilisation (2)

uc system

effectuer un v irement

extend

Vrifier solde Client

S. MBARKI

58

Relations entre cas dutilisation (3)

Inclusion
signifie quun Use Case utilise intgralement la fonctionnalit du Use Case plus gnral en plus de lui ajouter des fonctionnalits additionnelles Elle spcifie un lien dinclusion entre deux use cases. Si U1 inclut U2 (flche allant de U1 U2) alors U2 sera toujours inclus dans U1 et ne sera jamais excut de manire autonome
S. MBARKI 59

Relations entre cas dutilisation (4)

uc system

effectuer un v irement

include

S'authentifier Client

S. MBARKI

60

Relations entre cas dutilisation (5)

Gnralisation/Spcialisation
Un cas dutilisation U1 est une gnralisation dun cas dutilisation U2 si U2 est un cas particulier de U1 La consultation dun compte via internet est un cas particulier de consultation Cette relation ne se limite pas au diagramme de classe
uc system

Consulter compte

Client Consulter v ia Internet

S. MBARKI

61

Exemple de diagramme de cas dutilisation (Systme de gestion de commandes)

uc system Aj outer un client

include S'authentifier extend include Receptionniste Aj outer une commande include include

Facturer une commande

Liv rer une commande Aj outer une commande Express

Chauffeur Comptable

S. MBARKI

62

Etude de cas Systme dInscription Automatique

Au dbut de chaque session, les tudiants demandent un catalogue contenant une liste des cours disponibles durant la session. Pour aider les tudiants dans leurs choix, des informations sur chaque cours sont fournies (enseignant, dpartement, prpr-requis, etc.). Le systme permettra aux tudiants de choisir 4 cours dans une session. En plus, chaque tudiant choisit deux cours optionnels en cas dannulation ou de saturation dun cours parmi les 4 prcdemment choisis. Le nombre dtudiants dans un cours est entre 3 et 10. Un cours contenant moins de 3 tudiants est annul. Une fois le processus dinscription dun tudiant est valid, le systme envoie les informations au systme de paiement. Ltudiant peut donc payer ses frais de scolarit. Un enseignant peut indiquer les cours quil veut assurer, consulter la liste des tudiants inscris dans un cours donn 63 S. MBARKI

Diagramme de cas dutilisation SIA

Identifier tous les acteurs de lapplication SIA Identifier tous les cas dutilisation de lapplication SIA Donner le diagramme de cas dutilisation de lapplication SIA

S. MBARKI

64

Acteurs SIA
Etudiant Enseignant Systme de paiement Administrateur

S. MBARKI

65

Cas dutilisation SIA

Sinscrire un cours Choisir cours assurer Obtenir des informations sur un cours Maintenir les informations sur enseignants Maintenir les informations sur tudiants Maintenir les informations sur les cours Gnrer le catalogue

S. MBARKI

66

Diagramme de cas dutilisation SIA

uc system Choisir cours assurer Etudiant

S'inscrire un cours

Enseignant

Obtenir les informations sur le cours

Systme de paiement

Gnrer catalogue Maintenir les information sur tudiants

Maintenir informations sur cours

Maintenir informations sur enseignants

Administrateur

S. MBARKI

67

Diagramme dactivit

CHAPITRE 5

S. MBARKI

68

Diagramme dactivit (1)

Prsente la dynamique du systme dinformation. Reprsente les traitements effectuer, les acteurs impliqus et lutilisation des informations. Sert modliser un processus, un cas dutilisation ou une mthode. Un processus est lorganisation dun ensemble dactivits effectus par des acteurs et impliquant des entits, pour rpondre un type dvnement. On dcrit un processus ou variante par un diagramme dactivit.
S. MBARKI 69

Diagramme dactivit (2)

Un diagramme dactivit est un graphe orient qui dcrit un enchanement de traitements (flot de contrle). On peut faire figurer des objets impliqus dans les activits. La participation de ces objets reprsente un flot dobjets. Lenchanement des activits peut tre soumis des branchements ou des synchronisations. La visualisation des couloirs dactivits permet de reprsenter la rpartition de la responsabilit des activits entre diffrents acteurs. Les lements de modlisation du diagramme dactivit sont :
S. MBARKI 70

Action
UML propose une description des actions UML :
Action de type call : correspond un appel de mthode. Ce type dappel est bloquant : lappelant attend la rponse de lappel avant de continuer son excution. Action de type send : Correspond lenvoi de messages asynchrones : lappelant poursuit son excution sans attendre que lappel ait reu le message. Ce type dappel est adapt la modlisation des protocoles de communication (UDP, MPI), du multimulti -Threading. Laction symtrique ct rcepteur est accept event (rception dun signal). En Java, notify() de la mthode Object est asynchrone.
S. MBARKI 71

Flot de contrle (1)

Le diagramme dactivit prsente un squencement de traitements. Un traitement peut tre :
Une action (opration lmentaire). Une activit (peut tre dcrite plus finement).

Les actions/activits sont relies par des transitions. Les transitions sont dclenches par des vnements :
achvement de laction/activit prcdant la transition. rception dun signal. disponibilit dun objet dans un certain tat.
S. MBARKI 72

Flot de contrle (2)

Lensemble des transitions constitue le flot de contrle. Une transition peut tre en attente de la vrification dune condition de garde Exemple : lactivit Envoi de la commande nest effectue quaprs lactivit Prparation de la commande mais aussi en fin de journe
sd Dynamic View

Prparation de la commande

Env oi de la commande [fin de journe]

S. MBARKI

73

Action accept time event (1)

Un signal est une information provenant dune action externe lactivit en cours de description. On distingue trois types de signaux :
Signal temporel (accept time event) Signal mis Signal reu

Le signal temporel exprime le passage du temps

sd Dynamic View

Etablir la paie dernier jour ouvrable du mois

S. MBARKI

74

Action accept time event (2)

Un vnement temporel sans flot entrant (voir la figure prcdente) est un vnement rccurent :
Constitue une alternative pour dmarrer une activit. Modlise une activit qui est excute priodiquement.

Exemple : Envoyer la commande et attendre trois jours avant denvoyer la facture

sd Dynamic View Env oyer Commande Attendre trois jours Ev oyer facture

S. MBARKI

75

Actions send signal et accept event (1)

Des activits peuvent impliquer des interactions avec des personnes, systmes ou processus externes :
Pour autoriser une transaction avec une carte de crdit, crdit, On procde la vrification avec lmetteur (Banque Banque) ) par lintermdiaire de la socit de carte de crdit (Visa, MasterCard, etc).

Dans le diagramme dactivit, dactivit, un signal est un message qui peut tre mis ou reu :
Activit autorisation de carte de crdit : Le logiciel envoie une requte la socit de la carte de crdit pour obtenir lautorisation de la transaction du client et le logiciel reoit la rsponse de la socit de crdit. crdit.
S. MBARKI 76

Actions send signal et accept event (2)

Un signal reu dclenche lexcution dune activit Le receveur du signal sait comment ragir ds sa reception mais ne sait pas quand le signal arrive (message asynchrone) Exemple : Larrive dune commande dclenche le processus de traitement dune commande
sd Dynamic View Arrive commande Traitement de la commande

Exercice : Le clic sur un bouton active lexcution du code associ (activit : traitement de lvnement clic sur bouton)
S. MBARKI 77

Actions send signal et accept event (3)

Un signal emis est envoy un participant externe (personne ou systme). A sa rception, le participant ragit en rponse au signal mis, mais sa rponse nest pas modlise dans le diagramme dactivit. Exemple : Validation de carte de crdit
sd Dynamic View Send request for credit card approval

Calculate total

Receive response

Update order status

S. MBARKI

78

Exemple rcapitulatif

Action accept event Action send signal

Action time accept event

sd Dynamic View Appui bouton (lumire)

Eclairer Affichage Attendre 2s

Eteindre affichage

S. MBARKI

79

Flot dobjet (1)

Permet dindiquer quelle est la part prise par chaque objet dans lexcution dun travail. Exemple :
sd Dynamic View

Prparation de la commande

Env oi de la commande [fin de journe]

:Commande [ouverte]

:Commande [envoye]

Comptabilisation

S. MBARKI

80

Flot dobjet (2)

Les trois transitions de la figure mettent en jeu un objet Commande dans diffrents tats et font partie du flot dobjet. Les transitions du flot dobjet peuvent galement comporter des conditions de garde Remarques :
Chaque diagramme dactivit un noeud initial et un noeud final
sd Dynamic View

sd Dynamic View

Add itm to Cart

CheckOut

S. MBARKI

81

Flot dobjet (3)

Les actions, comme les mthodes, peuvent avoir des paramtres. Il nest pas ncessaire de reprsenter les informations concernant les paramtres dans un diagramme dactivit. Si cest le cas, on emploie des connecteurs (pins). Les connecteurs sont intressants pour visualiser les objets dont les actions ont besoin. Exemple :
sd Dynamic View Chercher client

Client

Client

Contacter client

S. MBARKI

82

Branchement conditionnel
Un flot de contrle peut comprendre des chemins alternatifs. Chaque branche est soumise une condition (condition de garde). Les chemins parallles fusionnent pour continuer lactivit. Exemple : Cas dune commande lctronique
sd Dynamic View Constitution du panier de la commande

[trop cher]

[montant acceptable]

Abandon de la commande

Env oi de la commande

Mmorisation de l'env ironnement client

S. MBARKI

83

Synchronisation
Un flot de contrle peut suivre deux chemins parallles (ouverture dune fourche ou fork) Ensuite, les deux chemins se rejoingnent dans une fermeture de synchronisation (join)
S. MBARKI

sd Dynamic View

Expression d'une demande de crdit

Recherche dans le catalogue

Ev aluation du risque client

Slection des produits proposer

Affichage de la rponse

84

Partition (1)
On dfinit des colonnes (partitions) pour dcrire les acteurs responsable de chaque activit. Chaque activit est place dans la partition de lacteur qui sen charge. Remarques :
Pour reprsenter une activit partage entre deux acteurs, on la dcompose en soussous-activits. Un diagramme dactivit peut impliquer plusieurs objets Une activit est un ensemble dactions lmentaires qui peut tre reprsente par un soussous-diagramme dactivits.
S. MBARKI 85

Partition (2)
sd Dynamic View Serv ice achats Responsable serv ice achats Application comptabilit

Prparation de la commande Env oi de la commande :Commande [ouverte] :Commande [envoye]

Comptabilisation

S. MBARKI

86

Exemple 1 : Cafetire
Construire un diagramme dactivit reprsentant lutilisation dune cafetire lctrique Les actions sont :
Chercher du caf Mettre un filtre Remplir le rservoir deau Mettre du caf Prendre une tasse Allumer la cafetire Servir le caf
S. MBARKI 87

Solution : Cafetire
sd Dynamic View Chercher du caf

Mettre un filtre

Remplir le rserv oir d'eau

Prendre une tasse

Mettre du caf

Serv ir le caf

Allumer la cafetire

S. MBARKI

88

Exemple 2 : Traitement dune commande

Use case : traitement dune commande: commande:

Quand on reoit une commande, on vrifie pour chaque ligne de la commande, si nous disposons de la quantit du produit demande en stock stock. . Si cest le cas, nous affectons la quantit demande la commande. commande. On rapprovisionne le stock en cas de rupture. rupture. Simultanment, nous vrifions si le paiement est en ordre ordre. . Si le paiement est ok et que tous les produits sont disponibles nous livrons la commande. commande. Si le paiement est ok mais nous ne disposons pas des produits, nous mettons la commande en attente. attente. Si le paiement nest pas ok, nous annulons la commande .
S. MBARKI 89

Solution : Traitement dune commande

retour
sd Dynamic View Recevoir une commande

Vrifier paiement

Vrifier la quantit

[rupture] Annuler la commande

Reapprov isionner le stock

[echec]

[disponible] Affecter la quantit la [Il reste des articles ?] commande

[succes] Liv rer la commande [plus d'articles]

S. MBARKI

90

Diagramme de classes

CHAPITRE 6

S. MBARKI

91

Dfinition
Un lment essentiel de l lapproche Oriente Objet Exprime laspect structurel/statique dun systme en termes de :
classes relations statiques entre les classes

Sert de base aux autres diagrammes du modle (tels que les diagrammes dtats, des objets ou les diagrammes de communication qui sont des diagrammes dynamiques) Diagramme de classes = Modle entit entit-association tendu
S. MBARKI 92

Dfinition (suite)
Une classe dfinit la structure commune dun ensemble dobjets et permet la construction dobjets instances de cette classe. Une classe est identifie par son nom Un objet est reli une classe de la mme manire quune variable est associe un type de donnes dans un langage de programmation procdurale On distingue deux catgories de classes :
Classes concrtes : instantiables Classes abstraites: non instantiables (notation: nom en italique)
S. MBARKI 93

Notation

la syntaxe dans les diffrents compartiments est indpendante des langages de programmation
S. MBARKI 94

Les proprits
Les proprits reprsentent les caractristiques structurelles dune classe Les proprits reprsentent un concept unique mais apparaissent dans deux notations diffrentes : les attributs et les associations Exemples : le client est une proprit de la commande, le produit est une proprit de la ligne de commande, le nom est une proprit de client,
S. MBARKI 95

Les attributs
Permet de dcrire une proprit comme une ligne de texte dans la classe
Private (-) Protected (#) Public (+)
S. MBARKI

type

Valeur par dfaut

96

Les attributs (suite)

Syntaxe : visibilit nom : type [multiplicit] [= [=valDefaut valDefaut] ] [{contrainte}]
Multiplicit : indique la nature du champ ([0..1] pointeur, [1] valeur, [x..*] collection) Contrainte : information supplmentaire sur lattribut

Exemple :
- nom : String [1]="Said [1]="Said" " {readonly {readonly} }

Smantique : dcrivent l'tat de l'objet Visualis ou pas, selon le niveau de dtail souhait
S. MBARKI 97

Associations unidirectionnelles
L'association constitue une autre mthode pour noter une proprit Une association unidirectionnelle est reprsente par un trait continu et orient entre deux classes Le nom de la proprit et la multiplicit sont reprsents sur l'association du ct de sa cible Dans l'exemple suivant, nous donnerons deux figures reprsentant de deux faons des proprits
S. MBARKI 98

Reprsentation des proprits

1
class system Date +dateLivr 0..1 * Commande Boolean

+prePay 1

+lignesComm

* {ordered} LigneCommande

class system

Commande S. MBARKI

dateLivr: Date [0..1] lignesComm: LigneCommande [0..n] {ordered} prePay: Boolean

99

Interprtation de la reprsentation
Dans la notation associations, on peut reprsenter les multiplicits dans les deux extrmits de l'association Quel est l'intrt d'une notation par rapport l'autre ?
Les attributs sont utiliss pour les types valeurs : dates, boolens, etc. Les associations sont plus significatifs pour les classes (clients, commandes, etc.)
S. MBARKI 100

Multiplicit
Equivalent aux cardinalits du modle EE-A Le sens de lecture nest pas le mme
0..x 1 x..* m..n : optionnel : un et un seul : multiple : born

La multiplicit par dfaut d'un attribut est [1]

S. MBARKI 101

Multiplicit (suite)
Une multiplicit suprieure 1 implique une collection d'objets Les formes les plus courantes d'associations sont :
1 vers 1 1 vers n n vers m
1 1 * *
102

classe A

1 *

classe B

S. MBARKI

Les associations bidirectionnelles

Une association bidirectionnelle est une paire de proprits relies entre elles
La classe Voiture a une proprit propritaire : Personne[1] La classe Personne a une proprit voitures : Voiture[*]

S. MBARKI

103

Nom dune association

Dcrit la nature de lassociation
emploi Personne Socit

Direction de lecture de lassociation

travaille pour

Personne

Socit

S. MBARKI

104

Rle dune association

Dcrit comment une classe source voit une classe destination travers lassociation Une classe peut jouer un mme rle ou diffrents rles au sein de diffrentes associations Les associations peuvent relier une classe elle mme
Personne
employ employeur
Personne

Socit

Chef Supervise
S. MBARKI

Nom NumAssurance Adresse

Subordonn
105

Les oprations
Permettent de manipuler les proprits et d'effectuer des actions. Elles sont appeles par des instances de la classe Syntaxe : visibilit nom(liste_paramtres nom(liste_paramtres) ): type_retour [{proprit}] Exemple :
+ deplacer( deplacer(u:Vecteur u:Vecteur) ) : void

Les oprations constituent linterface de la classe avec le monde extrieur Distinction entre opration et mthode :
Une mthode est l'implmentation d'une opration dans une classe Une mme opration peut s'appliquer sur plusieurs classes (polymorphe)
S. MBARKI 106

Exemple dune classe avec oprations

Oprations public

S. MBARKI

107

GnralisationGnralisation -spcialisation
Un exemple typique de gnralisation est celui de l'tudiant et l'enseignant. Ils ont des diffrences mais aussi des similarits. Ces dernires peuvent tre places dans une supersuper -classe Personne On dit que l'tudiant est un soussous-type (spcialisation) de personne La gnralisation permet la cration de supersuper-classes regroupant les proprits et les comportements communs aux soussous-classes (factorisation). La spcialisation permet la cration de soussous-classes afin dajouter ou modifier certaines proprits ou comportements dfinis dans les supersuper-classes
S. MBARKI 108

GnralisationGnralisation -spcialisation (suite)

Matriel Informatique Rfrence Prix

Unit Centrale Vitesse

Ecran Dimensions

Clavier NbrTouches

S. MBARKI

109

GnralisationGnralisation -spcialisation (suite)

Factorisation des relations
factorisation de l'association d'appartenance

vehicule terrestre 0..*

appartient

personne

voiture

camion tonnage

S. MBARKI

110

GnralisationGnralisation -spcialisation (suite)

Proprits de la gnralisation: non rflexive, non symtrique et transitive
A
A
A B

Impossible !!!

Impossible !!! B

Gnralisation vs Composition
Gnralisation = est un: un WindowWindow-avecavec-scrollbar est un Window Composition = a un: un WindowWindow-avecavec-scrollbar a un scrollbar
S. MBARKI 111

Dpendance
Un lien durable entre objets donne lieu une association unidirectionnelle Un lien temporaire (envoi de message, variable locale, paramtre) donne lieu une relation de dpendance Une dpendance existe entre deux classes si la modification de l'une (fournisseur) a des rpercussions sur l'autre (client)
Bibliothque Livre

client
S. MBARKI

fournisseur
112

Dpendances (suite)
Plusieurs strotypes :
call : la source (opration) appelle une opration de la cible instantiate : une opration de la source cre une instance de la cible send : la source envoie un signal la cible
S. MBARKI 113

Composition
Exprime une partie de Une classe composant peut faire lobjet de plusieurs compositions Un objet de la classe composant ne peut appartenir qu un seul objet dun compos Cycles interdits! Dures de vie identiques (destructions synchronises) La navigabilit peut tre bidirectionnelle ou non

S. MBARKI

114

Composition (suite)
La cration, modification et destruction des composants sont de la responsabilit du composite Du cot du composite, la multiplicit est un

Appartement

Chambre

S. MBARKI

115

Agrgation
Une agrgation est une association non symtrique : lune des extrmits joue un rle prdominant que lautre Smantique identique la composition Le partage des objets composants est autoris Dures de vie diffrentes
-salaris * *

Entreprise
1 *

Personne
-adhrents

Association

S. MBARKI

116

Composition / Agrgation
Identification dune composition (ou agrgation)
AssemblageAssemblage -parties
La porte est un composant de la voiture

CollectionCollection -membres
La personne est membre dans lassociation

ContenantContenant -contenu
Le polygone contient des sommets

Modliser autant que possible les compositions/agrgations

Augmente la lisibilit du modle
S. MBARKI 117

Membres statiques
Attributs et oprations statiques
Correspondent aux membres static en C++ ou Java Indiqu par un soulign

S. MBARKI

118

Interfaces
Type de classe dfinie exclusivement par des fonctions abstraites Sert limplmentation dautres classes Deux notations :

S. MBARKI

119

Interfaces (suite)
Une interface peut tre:
implmente

S. MBARKI

120

Contraintes
Information supplmentaire sur un lment
Place entre accolades Peut tre un texte en langage naturel Ou bien OCL (Object Constraint Language Language) )
Repose sur la logique mathmatique vite les ambiguts du langage naturel Il existe des outils pour OCL Permet de dcrire les pr et postpost-conditions, ainsi que les invariants sur un lment du modle (attribut, rle, opration, etc.)
S. MBARKI 121

Exemple de contraintes OCL

Soit le diagramme de classes suivant :
Chambre Htel -adresse : String * -lesChambres -tage : Integer -numro : Integer -nbLits : Integer

-laChambre * -directeur 1 Personne -nom : String -prnom : String -age : Integer *

S. MBARKI

-lesCLients

-lesRsidents

122

Exemple de contraintes OCL

On peut exprimer les contraintes :
// Jamais de neuvime tage

context Chambre inv inv: : self.tage <> 9

// Pas plus de rsidents que de lits sauf sil y a un enfant de moins de 4 ans

context Chambre inv inv: : lesRsidents sidents->size <= nbLits or (lesRsidents sidents->size = nbLits + 1 and lesRsidents sidents->exists exists(p (p : Personne | p.ge < 4))

S. MBARKI

123

Contraintes sur les associations

Une contrainte est une condition sur une association qui doit tre prserve. Elle est place dans une expression entre accolades
Personne
* {ordonn}

Compte

La contrainte dinclusion {sous ensemble} indique quune collection est incluse dans une autre collection
Parents d'lves

* *

Classe

{sous ensemble} dlgus

Personne
124

S. MBARKI

Contraintes sur les associations (suite)

La contrainte dexclusion {ou exclusif} indique que pour un objet donn, une seule association parmi un groupe est valide
Batterie PC portable
{ou exclusif}

Secteur

S. MBARKI

125

Classes association
On reprsente une association par une classe pour ajouter des attributs et des oprations dans lassociation Une classe dassociation est intressante pour les associations N vers M Pour les associations 1 vers 1 les attributs de lassociation peuvent tre dplacs dans lune des classes Pour les associations 1 vers N, le dplacement se fait vers la classe du ct N
S. MBARKI 126

Classes association (suite)

Etudiant

Travail

Evaluation
note

Classe association

Evaluation Etudiant
1

note

Travail

S. MBARKI

127

Restriction des associations

La restriction (qualification) dune association consiste slectionner un soussous-ensemble dobjets parmi lensemble qui participe lassociation Elle est ralise au moyen dune cl, ensemble dattributs particuliers. La cl appartient lassociation Le qualificateur (ex: n n Etudiant) permet didentifier 0 ou un tudiant Pour manipuler (ajouter, consulter, etc.) un tudiant, il faut obligatoirement un n n Etudiant
Universit
S. MBARKI

n Etudiant

0..1

Etudiant
128

Restriction des associations (suite)

A
cl

Chaque instance de la classe A accompagne de la valeur de la cl, identifie un sous ensemble des instances de B qui participent lassociation Une restriction rduit le nombre dinstances qui participent une association
:B :B :B :A avec cl :B :B
S. MBARKI 129

:B :B

:B :B

Associations ternaires
Une association ternaire entre Salle, Cours et Enseignant est reprsente par une classe Sance ayant deux attributs dbut et fin
Cours Enseignant

Salle

Sance date Heure dure

S. MBARKI 130

Diagramme dobjets

CHAPITRE 7

S. MBARKI

131

Dfinition
Le diagramme d'objets permet de reprsenter les instances de classes et liens entre elles Un diagramme d'objets est une instance de diagramme de classes :
Il montre l'tat du systme un instant donn La notation retenue est drive du diagramme de classes
S. MBARKI 132

Reprsentation des objets

Objet simple
mazda mazda : Voiture : Voiture

Groupe d'objets
: Voiture

Objet d'une classe strotype

<<Exception>>

: DivisionParZero

Objet avec valeurs des attributs

: Voiture
Vitesse = 60 Couleur = noir
S. MBARKI

: Voiture [ 60, noir ]

133

Reprsentation des liens

Les objets sont relis par des liens La reprsentation concrte d'une structure au moyen d'objets est plus parlante que celle par des classes
: Voiture : Moteur

: Roue

: Roue

: Roue

: Roue

Ce diagramme d'objets est une instance du diagramme de classes suivant :

Roue 4
1

Voiture

Moteur

S. MBARKI

134

Les objets composites

Reprsenter les objets composs de sous objets Exemple :
Soit le diagramme de classe suivant
Fentre
1 2

Ascenseur

Zone de texte

Reprsentation de l'objet composite

:Fentre :Zone de texte ascHoriz : Ascenseur
S. MBARKI 135

ascVertic : Ascenseur

Similitudes entre les diagrammes d'objets et les diagrammes de classes

Pour faciliter la comprhension du lien entre les deux diagrammes, il faut reporter dans le diagramme d'objets toutes les caractristiques des associations (nom, noms des rles, l'agrgation, la composition et la navigation)
passagers

: Personne

: Bus : Personne : Destination

S. MBARKI

136

Relation de dpendance entre objets et classes

Un objet est une instance d'une classe Un lien est une instance d'une association Ces relations entre le classificateur et son instance sont reprsents par des relations de dpendance strotyps par <<instance de>> Exemple :
ascHoriz : Ascenseur
<<instance de>>

Ascenseur

S. MBARKI

137

Diagramme d'objet : exemple

Soit le diagramme de classe reprsentant l'organisation des mtiers dans une entreprise
Nud * fils

0..1 parent Personne Mtier

Illustrer ce diagramme de classes par un diagramme d'objets correspondant

S. MBARKI

138

Exercices
Donner les diagrammes de classes associs aux rgles de gestion suivantes : Exercice 1
Un salari travaille dans un seul service, un service contient plusieurs salaris Exercice 2 Un salari travaille dans un ou plusieurs services, un service contient un ou plusieurs salaris Exercice 3 Une commande concerne un ou plusieurs produits, un produit figure dans 0 ou plusieurs commandes Exercice 4 Un tudiant a une seule note dans une matire donne
S. MBARKI 139

Exercices
Etude de cas : Soit les rgles de gestion :
un tudiant sinscrit dans une et une seule filire. Une filire est un ensemble de modules. Un tudiant a une seule note dans un module donn Un tudiant peut avoir plusieurs diplmes. Un module est enseign par un seul enseignant. Un enseignant enseigne plusieurs modules. Ladministration comptabilise les absences.
S. MBARKI 140

Exercices
Exercice 5
Une cole a dcid de btir des chambres (internat) et des rsidences lextrieur, un tudiant habite linternat ou la rsidence mais pas aux deux.

Exercice 6 Soit le problme suivant : les tudiants d'une cole mettent des souhaits concernant des stages un tudiant effectue au plus un stage un stage est effectu au plus par un tudiant un stage intresse 0 ou plusieurs tudiants un stage effectu par un tudiant doit tre un stage figurant dans les souhaits de cet tudiant Exercice 7 Un ordinateur est compos d'un cran, d'un ou plusieurs disques et diffrents priphriques
S. MBARKI 141

Exercices
public interface Observer { public void update(Observable o); } public class Observable { Collection observateurs; public void notify() notify() { Iterator it = this.iterator this.iterator(); (); while (it.hasNext()) it.hasNext()) { ((Observer) it.next it.next()).update( ()).update(this this); ); } } public void addObserver(Observer addObserver(Observer o) { observateurs.add(o); } ... } public class Bilan extends Observable { void setChange() setChange() { notify(); notify(); } ... } public class UIGraphe implements Observer { public void update(Observable o) { Bilan unbilan = (Bilan) o; double compteResultat = unbilan.getCompteResultat(); unbilan.getCompteResultat(); ... S. } MBARKI ... }

142

Diagramme de squences

CHAPITRE 8

S. MBARKI

143

Pourquoi interaction/collaboration dobjets

Les objets contiennent seulement les donnes et les mthodes qui relvent de leurs propres responsabilits Ils ne connaissent rien sur les donnes dautres objets Pour obtenir le genre de fonctionnalits exiges dun systme, les objets doivent travailler ensemble, collaborer Les objets collaborent en senvoyant des messages Seuls les objets lis entre eux (dune manire ou dune autre) peuvent schanger des messages
S. MBARKI 144

Messages
Un message modlise une communication unidirectionnelle entre objets, qui transporte de linformation avec lintention de dclencher une raction chez le rcepteur Il peut comprendre des paramtres qui transfrent des valeurs de lmetteur au rcepteur UML dfinit les messages suivants:
Call: appel dune opration sur un objet (synchrone) Return: renvoi dune valeur lmetteur Send: envoi dun signal un objet (asynchrone) Create: cration dun objet Destroy: destruction dun objet
S. MBARKI 145

Liens entre objets

Un lien spcifie le chemin par lequel un objet o1 peut envoyer un message un autre objet o2 (qui peut tre le mme) Diffrente Diffrent es formes de ce chemin :
Association: o2 est visible par simple association Self: o2 est visible car il est lui mme le dclencheur de lopration (o2=o1) Global: o2 est un objet global par rapport o1 Local: o2 est un objet local par rapport o1 Parameter: o2 est un paramtre dune opration de o1
S. MBARKI 146

Diagramme dinteraction
Dcrit comment des objets interagissent entre eux Typiquement, un diagramme dinteraction dcrit un

scnario possible dun seul use case

Deux sortes de diagrammes: Le diagramme de squences, qui met laccent sur la
chronologie des messages Le diagramme de communication, qui met laccent sur les relations structurelles entre les objets qui changent les messages

Les deux diagrammes sont smantiquement quivalents (lun peut tre obtenu partir de lautre).
S. MBARKI 147

Diagramme de squence
Les participants sont placs sur laxe horizontal et lchange de messages sur laxe chronologique verticale
sd system p:Person c:Company

assi gn(Dept R&D)

Dure de vie

Barre dactivation

S. MBARKI

148

Rapport entre DC et DS
Seuls les objets lis entre eux peuvent senvoyer des messages
class system

Person +employe 1..* + assign(Departement) : void 1 + +Employer -

Company

()

S. MBARKI

149

Diffrents types de messages

o1 s im p le p ro c e du re c a ll r et u rn m es s a g e to s e lf < < c re a te> > o2

de s tru c tio n m ark er

S. MBARKI

150

Exemple de diagramme de squence

Calcul du montant dune commande
La commande parcoure toutes ses lignes de commande :
Dtermine le prix de chaque ligne de commande

La commande calcule la rduction accorde au client

Consulter le client

S. MBARKI

151

Solution avec un contrle centralis

sd system uneCommande uneLigneDeCommande unArticle unClient

calculPrix()

getQuantit()

getArticle() :Article

getDetailsPrix()

calculPrixBase() getInfosRemise()

calculRemise()

S. MBARKI

152

Commentaires
Les messages sont envoys suivant un ordre chronologique getArticle est un appel de mthode qui retourne un rsultat (un article) Le premier message dans le diagramme na pas de participant (source indetermine), indetermine), on lappelle found message Diagramme incomplet car il ne montre pas litration
S. MBARKI 153

Solution avec un contrle distribu

sd system uneCommande uneLigneDeCommande unArticle unClient

calculPrix()

calculPrix()

getPrix(quantit)

getMontantRemise(uneCommande) :double

getPrixBase()

montantRemise()

S. MBARKI

154

Commentaires
Chaque style a ses avantages et ses inconvnients Dans le premier style, le traitement est centralis dans un seul endroit Dans le deuxime style, le traitement est distribus entre des participants qui collaborent entre eux Le style 2 est plus adapt au concept orient objet :
Chaque objet est responsable de ses propres donnes
S. MBARKI 155

Message de type cration

: P rofes s or

:Cour s eF orm

: Cours e M anager

s et c ours e info add c ours e < < c reate> >

:Cours e

S. MBARKI

156

Itration, Itration , condition

Le diagramme de squence nest pas adquat pour montrer les structures de contrles :
Il sinteresse sinteresse linteraction entre les objets et ne modlise pas le flot de contrle Utiliser un diagramme dactivit

Pour reprsenter une itration ou une condition, utiliser :

Interaction frames
S. MBARKI 157

Exemple
procedure dispatch foreach (lineitem lineitem) ) if (product.value (product.value>10k) >10k) careful.dispatch else regular.dispatch end if end for if (needsConfirmation (needsConfirmation) ) messenger.confirm End procedure
S. MBARKI 158

Interaction frames
sd system :Order careful:Distributor regular:Distributor :Messenger

dispatch()

loop [for each line item] alt [value>10000] dispatch()

Frame operator

[else] dispatch()

opt [needsConfirmation]

guard

confirm()

S. MBARKI

159

Quand utiliser un diagramme de squence ?

Pour comprendre et reprsenter les comportements de plusieurs objets dans un seul cas dutilisation
Montre la collaboration entre les objets Ne dfinit pas de faon prcise le comportement

Pour reprsenter le comportement dun objet dans plusieurs cas dutilisations :

Diagramme dtat

Pour reprsenter les comportements de plusieurs objets dans plusieurs cas dutilisations :
Diagramme dactivit
S. MBARKI 160

Exemple : gestion dune bibliothque

Les use cases principaux dun systme de gestion dune bibliothque sont:
Gestion des emprunts douvrages Gestion des retours douvrages emprunts Approvisionnement par de nouveaux ouvrages

Pour chacun de ces use cases, donner les diagrammes de squences de diffrents scnarios possibles
S. MBARKI 161

Scnario : emprunter un livre

sd bibliotheque ep0:Emprunteur bibliothecaire ex0:Exemplaire

emprunterLivre() getNombreEmprunts() n()

opt [n<MAX] emprunter(ep0, date)

bloquer()

ajouterExemplaire(ex0)

S. MBARKI

162

Scnario : rendre un livre

sd bibliotheque ex0:Exemplaire bibliothecaire ep0:Emprunteur

rendreLivre()

rendre(dateActuelle)

getEmprunteur()

supprimerExemplaire(ex0)

debloquer()

S. MBARKI

163

Scnario : rendre un livre avec pnalit

sd bibliotheque ex0:Exemplaire bi bl iothecai re ep0:Emprunteur

rendreLi vre()

rendre(dateActuelle)

getEmprunteur()

supprimerExemplaire(ex0)

debloquer()

getDateSortie()

ds()

opt [dateActuelle - ds >15]

penaliser()

S. MBARKI

164

Scnario : envoyer une lettre de rappel

sd bibliotheque ex0:Exempl ai re bibl iothecaire ep0:Emprunteur

lettreRappel()

loop [pour chaque Exemplaire]

getEtat()

etat() opt [etat=bloqu] ds() opt [dateActuell e - ds > 15] envoyerLettreRappel()

getDateSorti e()

getEmprunteur()

S. MBARKI

165

Scnario : approvisionnement
sd bibliotheque :Bibliotheque

approvisionner()

loop creer()

:Livre

setDescriptions()

loop creer()

:Exemplaire

setDescriptions() ajouterExemplaire()

ajouterLivre()

S. MBARKI

166

Diagramme dtatsdtats-transitions

CHAPITRE 9

S. MBARKI

167

Dfinition
Un diagramme dtats (ex. automate fini) sintresse au cycle de vie dun objet gnrique dune classe particulire au fil de ses interactions avec son environnement externe, en traitant tous les cas possibles Il dcrit les squences dtats dans lesquelles un objet peut tre durant son cycle de vie et les vnements qui dclenchent les transitions.
S. MBARKI 168

Quest ce quun tat ?

Un tat reprsente une situation durable dans laquelle peut se trouver un objet : Il satisfait une certaine condition Il excute une certaine activit Ou bien il attend un certain vnement Un tat est dtermin sur base des valeurs de ses attributs ou par lexistence de liens avec dautres objets
Socit Personne 1..* age En activit A la retraite

0..1

Au chmage
S. MBARKI 169

Changement dtats
Changement dtats la suite de loccurrence dun

vnement
Un vnement dclenche une transition dtat Une transition dtat : connexion unidirectionnelle reliant 2 tats assure le passage dun tat lautre est suppose instantane
retirer(somme)

Positif

Ngatif dposer(somme)

S. MBARKI

170

Changement dtats
Un vnement peut ou non changer un tat Transition reflexive (Self(Self -transition)
retirer(somme) retirer( somme ) dposer(somme)

Positif

Ngatif

dposer( somme )

S. MBARKI

171

Quest ce quun vnement ?

En UML, un vnement est une spcification dune occurrence significative qui a une localisation dans le temps et dans lespace Une instance dun vnement peut entraner lactivation dune fonctionnalit dun objet Il reprsente loccurrence dun fait qui peut dclencher une transition entre tats

S. MBARKI

172

Les quatre types dvnements en UML

La rception dun signal : envoy par un autre objet, ou
par un acteur (p.ex., envoi dune exception en Java)

Lappel dune opration (call event) sur lobjet rcepteur

(p.ex., dposer(somme))

Le passage du temps (time event) (p.ex., after 30 min) Un changement dans la satisfaction dune condition
(change event) (p.ex., when n>Max)
S. MBARKI 173

Exemple de time Event et change Event

S. MBARKI

174

Notations relatives un tat

Un tat est toujours nomm Il comporte : des actions dentre (entry/ ) des actions de sortie (exit/ ) des activits (do/) Etats particuliers : Etat initial Etat final
State name entry / entry-action do / activity-A exit / exit-action

S. MBARKI

175

Notions dactions et dactivits

Action :
Atomique (ininterruptible (ininterruptible, , instantane) Associe une transition Peut apparatre dans les clauses entry and exit au sein dun tat

Activit :
A une certaine dure (interruptible) Associe un tat

S. MBARKI

176

Exemples dactions et dactivits

Actions Go for dinner Go to sleep Go for breakfast Go for lunch Activits: Rest Sleep Take dinner Take breakfast Take lunch
S. MBARKI 177

Notations relatives une transition entre tats

Event(arguments)[condition]/action

State-A

State-B

event : vnement ou rien condition (de garde) = expression logique lie ltat
que lon quitte

action excute lors du franchissement de la transition

Chacune des trois parties peut tre omise

S. MBARKI

178

Les tats initial et final

Event(attribute) Initial state State-B

Start State End State

Start state
Obligatoire et un seul par diagramme

End state
Terminates a state machine Optionnel, Optionnel , plusieurs tats sont possibles
S. MBARKI 179

Diagramme dtat dune commande

[ not all items checked ] / get next item

vnement
[ All items checked && some items not in stock ]

Item received [ some items not in stock ]

Action
/ get first item Checking do: check item Waiting

[ All items checked && all items available ]

Activit

Item received[ all items available ]

Condition De garde

Dispatching do: initiate delivery

deliver

Delivered

S. MBARKI

180

Un tat composite
Un tat composite est un tat qui contient dautres tats, appels soussous- tats ou tats imbriqus Les sous tats peuvent tre: Squentiels ou Concurrents (aussi appels parallles) Les soussous-tats sont leur tour susceptibles dtre dcomposs

S. MBARKI

181

Cas : annuler une commande

On souhaite annuler, tout moment, une commande commande Solutions: Transitions partir de chacun des tats vers un nouveau tat cancelled cancelled Utiliser un tat composite et une seule transition vers ltat cancelled
S. MBARKI 182

Solution 1 : plusieurs transitions vers cancelled

[ not all items checked ] / get next item Item received[ some items not in stock ]

/ get first item

Checking do: check item

[ All items checked && some items not in stock ] Waiting Item received[ all items available ] cancel cancel

[ All items checked && all items available ]

Dispatching do: initiate delivery cancel Cancelled

deliver Delivered

S. MBARKI

183

Solution 2 : un tat composite avec des sous tats

Active
[ not all items checked ] / get next item
Item received[ some items not in stock ]

/ get first item

Checking do: check item

[ All items checked && some items not in stock ] Waiting cancelled Cancelled

[ All items checked && all items available ]

Item received[ all items available ]

Dispatching do: initiate delivery

deliver Delivered

S. MBARKI

184

Diagrammes dtats concurrents de la classe Commande Commande

order handling (voir diagramme dactivit)
Waiting

authorization
Authorizing do: check payment [ payment not ok ]

[ payment ok ]
Checking Dispatching

Authorized

Rejected

Delivered

S. MBARKI

185

Diagrammes dtats concurrents de la classe Commande Commande

Cancelled

order handling

Waiting

Checking

Dispatching Delivered

authorization
Authorizing do: check payment
Authorized

Rejected

S. MBARKI

186

Diagrammes dtats concurrents de la classe Commande Commande

Les deux statecharts order handling handling et authorization authorization se droulent en parallle Si un des deux statecharts arrive son tat final, il doit attendre, dans cet tat, la fin de son statechart concurrent Ltat cancelled peut tre atteint depuis chacun des tats du statechart order handling Ltat delivered (positionn exactement en face de la ligne pointille) est atteint automatiquement quand les deux statecharts se trouvent tous les deux dans leur tat final respectif (transition de synchronisation) Ltat Rejected (distinct de cancelled ) est atteint depuis ltat authorizing
S. MBARKI 187

Complmentarit entre diagrammes dtats et diagrammes dinteraction

Les diagrammes dtats apportent prcision et exhaustivit Ils permettent de valider et de complter les diagrammes dinteraction Ils peuvent galement inciter crer de nouveaux diagrammes dinteraction Si une interaction met en jeu deux objets a et b instances de classes A et B alors les diagrammes dtats des classes A et B doivent forcment tre cohrents avec cette interaction, mme sils intgrent de nombreux autres comportements

S. MBARKI

188

Exemple de cohrence entre diagrammes dtats et diagrammes dinteraction

[ autoris ] / emprunter()
e0 : Emprunteur [autoris] emprunter() [nbrcpEmpr<Max]ajouterCpyEmpr(c0) co : Copie

Copie Disponible remettre()

Copie Emprunte

[ autoris ET nbrcpEmpr<Max ] / ajouterCpyEmpr(c0)

remettre() supprimCpyEmpr(c0) [dlai dpass] pnaliser()

Emprunteur [ dlai remise dpass ] / pnaliser(2jours) after 2 jours Pnalis

S. MBARKI

189

Remarques
Un diagramme dtat est typiquement utilis pour dcrire un objet dune classe mtier Mais il est aussi utilis pour dcrire le cycle de vie dun sous systme ou le systme entier Pas toutes les classes ont besoin dun diagramme dtat

S. MBARKI

190