Beruflich Dokumente
Kultur Dokumente
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
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.
S. MBARKI
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
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
S. MBARKI
10
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
S. MBARKI
14
S. MBARKI
15
Interaction
objet2
objet4
objet3
Interaction
S. MBARKI
16
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
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
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
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
Les diagrammes contiennent des lments de modlisation, un lment peut apparatre dans diffrents diagrammes
S. MBARKI 30
S. MBARKI
31
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 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
<<metaclass>> Domaine
<<interface>> Transaction
<<utility>> Maths
<<exception>> DivisionPar0
S. MBARKI
36
Classe <<Control>>
Sert coordonner les changes de messages entre les autres classes pour raliser un Use case
S. MBARKI 37
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
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
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
<<importe>>
Destination 2
<<accde>>
S. MBARKI 45
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
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
Client
Exemple dacteurs :
Client, Repssentant du service client, directeur de ventes, ventes, administrateur de bases de donnes, donnes, matriel externe externe, , systme externe, externe ,
S. MBARKI
53
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
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
Retirer argent
Client
S. MBARKI
56
effectuer un v irement
extend
S. MBARKI
58
effectuer un v irement
include
S'authentifier Client
S. MBARKI
60
Consulter compte
S. MBARKI
61
include S'authentifier extend include Receptionniste Aj outer une commande include include
Chauffeur Comptable
S. MBARKI
62
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
S. MBARKI
66
S'inscrire un cours
Enseignant
Systme de paiement
Administrateur
S. MBARKI
67
Diagramme dactivit
CHAPITRE 5
S. MBARKI
68
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
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
Prparation de la commande
S. MBARKI
73
S. MBARKI
74
S. MBARKI
75
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
Exercice : Le clic sur un bouton active lexcution du code associ (activit : traitement de lvnement clic sur bouton)
S. MBARKI 77
Calculate total
Receive response
S. MBARKI
78
Exemple rcapitulatif
Eteindre affichage
S. MBARKI
79
Prparation de la commande
:Commande [ouverte]
:Commande [envoye]
Comptabilisation
S. MBARKI
80
sd Dynamic View
CheckOut
S. MBARKI
81
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
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
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
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
Mettre du caf
Serv ir le caf
Allumer la cafetire
S. MBARKI
88
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
Vrifier paiement
Vrifier la quantit
[echec]
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
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
+prePay 1
+lignesComm
* {ordered} LigneCommande
class system
Commande S. MBARKI
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
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
S. MBARKI
103
Personne
Socit
S. MBARKI
104
Socit
Chef Supervise
S. MBARKI
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
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
Ecran Dimensions
Clavier NbrTouches
S. MBARKI
109
appartient
personne
voiture
camion tonnage
S. MBARKI
110
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
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
-lesCLients
-lesRsidents
122
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
Compte
La contrainte dinclusion {sous ensemble} indique quune collection est incluse dans une autre collection
Parents d'lves
* *
Classe
Personne
124
S. MBARKI
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
Travail
Evaluation
note
Classe association
Evaluation Etudiant
1
note
Travail
S. MBARKI
127
n Etudiant
0..1
Etudiant
128
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
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
Groupe d'objets
: Voiture
: DivisionParZero
: Roue
: Roue
: Roue
: Roue
Voiture
Moteur
S. MBARKI
134
Ascenseur
Zone de texte
ascVertic : Ascenseur
: Personne
S. MBARKI
136
Ascenseur
S. MBARKI
137
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
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
Diagramme dinteraction
Dcrit comment des objets interagissent entre eux Typiquement, un diagramme dinteraction dcrit un
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
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
Company
()
S. MBARKI
149
S. MBARKI
150
S. MBARKI
151
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
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
: P rofes s or
:Cour s eF orm
: Cours e M anager
:Cours e
S. MBARKI
156
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()
Frame operator
[else] dispatch()
opt [needsConfirmation]
guard
confirm()
S. MBARKI
159
Pour reprsenter les comportements de plusieurs objets dans plusieurs cas dutilisations :
Diagramme dactivit
S. MBARKI 160
Pour chacun de ces use cases, donner les diagrammes de squences de diffrents scnarios possibles
S. MBARKI 161
bloquer()
ajouterExemplaire(ex0)
S. MBARKI
162
rendreLivre()
rendre(dateActuelle)
getEmprunteur()
supprimerExemplaire(ex0)
debloquer()
S. MBARKI
163
rendreLi vre()
rendre(dateActuelle)
getEmprunteur()
supprimerExemplaire(ex0)
debloquer()
getDateSortie()
ds()
penaliser()
S. MBARKI
164
lettreRappel()
getEtat()
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
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
S. MBARKI
172
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
S. MBARKI
174
S. MBARKI
175
Activit :
A une certaine dure (interruptible) Associe un tat
S. MBARKI
176
State-A
State-B
event : vnement ou rien condition (de garde) = expression logique lie ltat
que lon quitte
S. MBARKI
178
Start state
Obligatoire et un seul par diagramme
End state
Terminates a state machine Optionnel, Optionnel , plusieurs tats sont possibles
S. MBARKI 179
vnement
[ All items checked && some items not in stock ]
Action
/ get first item Checking do: check item Waiting
Activit
Condition De garde
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
[ All items checked && some items not in stock ] Waiting Item received[ all items available ] cancel cancel
deliver Delivered
S. MBARKI
183
[ All items checked && some items not in stock ] Waiting cancelled Cancelled
deliver Delivered
S. MBARKI
184
authorization
Authorizing do: check payment [ payment not ok ]
[ payment ok ]
Checking Dispatching
Authorized
Rejected
Delivered
S. MBARKI
185
order handling
Waiting
Checking
Dispatching Delivered
authorization
Authorizing do: check payment
Authorized
Rejected
S. MBARKI
186
S. MBARKI
188
Copie Emprunte
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