Vous êtes sur la page 1sur 135

Modlisation Orient Objet

UML

M.AFILAL
1

Objectif du cours
Objectif du cours:
la modlisation des logiciels, qui doivent rpondre un besoin dun client, en utilisant
UML
Cest pour cela, on commence par donner des dfinitions et certaines caractristiques
de ce que cest un logiciel.
Puis, de dfinir ce que cest la notion de gnie logiciel, ses problmatique et sa
relation avec la qualit de construction dun logiciel.
Puis, on parlera de cycle de vie dun logiciel avec ses diffrents types: traditionnel et
objet.
Et enfin, introduire la raison du choix de la modlisation en uml ainsi que ses
principaux diagrammes
qui permettent de capturer les caractristiques dun logiciel pour chaque phase de
son cycle de vie (son
cycle de dveloppement)
2
M.AFILAL

Logiciel ?
Dfinition :
Un logiciel (ou une application) est un ensemble de programmes, qui permet un
ordinateur ou un systme informatique d'assurer une tche ou une fonctionnalit
Physiquement, un logiciel est:
Une suite ditems ou dobjets
Une structure dinformations incluant programmes, donnes, documents,
Remarque:
Un logiciel nest pas seulement un ensemble de programmes, mais aussi de la
documentation pour :
linstallation,
lutilisation,
le dveloppement,
la maintenance.

M.AFILAL

Les diffrentes catgories de logiciel


Sur mesure
Pour un client spcifique
Gnrique
Vendu sur le march
un tableur (spreadsheet),
un outil de base de donne (database)
un outil de traitement de texte (word processor)

Embarqus
Excutent dans du matriel lectronique isol
machine laver, tlvision, lecteur DVD, tlphone mobile,
magntoscope, four micro-ondes, rfrigrateur, joueur MP3, ...
Difficile modifier
M.AFILAL

Les diffrentes catgories de logiciel


Logiciel temps rel (real time)
Systmes de contrle et de surveillance
Manipulent et contrlent le matriel technique
Raction immdiate requise
Environnement contraignant
Logiciel de traitement de donnes (data processing)
Ils stockent, recherchent, transforment et prsentent l'information aux utilisateurs
Grandes quantits de donnes avec des corrlations complexes, enregistres dans les
bases de donnes
Largement utiliss en administration des affaires
Fiabilit des rsultats
Scurit dans laccs aux donnes
Quelques fois les 2 aspects sont prsents dans un logiciel
M.AFILAL

La nature du logiciel
Le logiciel est facile reproduire (copier ou calquer)
Tout le cot se trouve dans son dveloppement
Pour dautres produits, la fabrication est souvent le processus le plus coteux
Le logiciel est intangible (impalpable, immatriel, invisible, abstrait )
Il est difficile d'estimer leffort de dveloppement
Le processus de dveloppement est difficile automatiser
Lindustrie du logiciel exige beaucoup de main doeuvre
Mme des informaticiens peu qualifis peuvent arriver bricoler quelque chose qui semble
fonctionner
La qualit dun logiciel nest pas apparente (validit, Robustesse, extensibilit,
rutilisabilit, portabilit, facilit dutilisation)

M.AFILAL

La nature du logiciel
Un logiciel semble facile modifier
La tentation est forte deffectuer des changements rapides sans vraiment en mesurer la
porte et les consquences
Un logiciel ne suse pas
Il se dtriore mesure que des changements sont effectus
en raison de lintroduction derreurs
ou par une complexification excessive
Remarque:
Beaucoup de logiciels sont mal conus et se dtriorent rapidement
La demande pour du logiciel est toujours croissante(donc croissance des difficults,
donc problmes dans les phases danalyse et de conception)
Un logiciel, comme le matriel, peut mourir (retrait de service) et devenir obsolte
(par exemple le passage lan 2000).
M.AFILAL

La nature du logiciel
Raisons pour lesquelles le logiciel vieillit :
Maintenance (bug fixes)
rosion architecturale (l'cart entre l'architecture prvue et son implmentation finale)
Des difficults techniques peuvent survenir pendant l'implmentation
Le dveloppeur se rend compte qu'un choix technologique , tablie au dbut pour
larchitecture prvue, ne parviendra pas atteindre les objectifs dsirs du projet.
Inflexibilit (rigide) ds le dbut
Documentation insuffisante ou inconsistante
Manque de modularit
Complexit croissante,
Un logiciel est fiable sil :
Rpond aux spcifications
La spcification tablit ce que le systme (ou logiciel) doit faire (le QUOI) et les contraintes
sous lesquelles il doit oprer
Ne produit jamais de rsultat erron
Ne jamais entrer dans un tat incohrent (Boucle infinie. Arrt brutale dun processus de calcul,
peut mener lutilisation de donnes non correctes, ce qui fait que les rsultats attendus par le
systme seront inexactes )
Ragir de faon sense et utile
en prsence dune situation inattendue 8
M.AFILAL

Le Gnie Logiciel ?
Art de produire du logiciel
Art de spcifier, concevoir, raliser, et de faire voluer, avec des moyens et dans des
dlais raisonnables, des programmes, des documentations, et des procdures de qualit
en vue dutiliser un ordinateur pour rsoudre certains problmes.
Art de bien faire de bons Logiciel
Art : technique, crativit, esthtique,
Bien faire : russite, rentabilit,
Bons : performance, fiabilit,
En gnie Logiciel, on parle de processus de dveloppement de logiciels et de gestion de
projets, dans les quels, on trouve:
Gestion du personnel :
Efforts ( travail fourni par les intervenants dans le projet)
Gestion des ressources :
Cots (cot associ au projet)
Aspects techniques :
Conception et Ralisation (des processus de dveloppement de logiciel)
Contraintes de ralisations :
9
M.AFILAL
Planification

Le Gnie Logiciel ?
Les points communs dans la construction des logiciels en Gnie Logiciel:
Travail de groupe et non dun individu isol
Besoins techniques et non-techniques
Connaissances informatiques.
Capacit de communication (non technique).
Gestion de projet.
Objectif du Gnie Logiciel
Dvelopper des logiciels considrs comme :
Logiciels fiables (srs).
Logiciels satisfaisant les besoins.
Logiciels maintenables (apte subir des modifications et des volutions
moindre cot ).
Logiciels exploitables dans diffrents environnement.

M.AFILAL

10

Le gnie logiciel - Origine


Origine : Apparu en 1968, devant les insatisfactions gnrales en matire de logiciel :
Fiabilit douteuse
Dpassement des dlais
Dpassement des cots
Erreurs rsiduelles persistantes (erreurs dans le codage par exemple: rsultat non
attendu par lutilisateur)
Sensibilit aux erreurs humaines, aux pannes matrielles
Difficults de conversion, de mise en uvre (mise en action dans la situation normale)
Difficults d'volution
+
Complexit croissante du logiciel (complexit dans lanalyse et la conception)
Cot croissant li en grande partie la maintenance (excessive)
+
Criticit des secteurs d'activit (secteur sensible: aviation, militaire, nuclaire)

M.AFILAL

11

Le gnie logiciel - Risques


Risques majeurs du dveloppement logiciel
Risques humains:
dfaillance du personnel;
surestimation des comptences;
travailleur solitaire, hrosme, manque de motivation
Risques processus
pas de gestion de projet
calendrier et budget irralistes ;
calendrier abandonn sous la pression des clients
composants externes manquants;
tches externes dfaillantes ;
insuffisance de donnes;
validit des besoins ;
dveloppement de fonctions inappropries;
dveloppement d'interfaces utilisateurs inappropries.
M.AFILAL

12

Le gnie logiciel - Risques


Risques majeurs du dveloppement logiciel
Risques technologiques
produit miracle, "plaqu or" : produit non rentable;
changement de technologie en cours de route;
problmes de performance;
exigences dmesures par rapport la technologie;
incomprhension des fondements de la technologie.

M.AFILAL

13

Quelques statistiques
tude du gouvernement amricain en 1979
Pays mais jamais livrs 45%
Livrs mais jamais utiliss 30%
Abandonns ou refaits 20%
Utiliss aprs modification 3%
Utiliss tel quel 2%

36%

Part des erreurs

erreurs de dfinition.
erreurs de codage

M.AFILAL

64%

14

Quelques statistiques
tude du gouvernement amricain sur 8380 projets de fabrication de logiciel en 1995
Succs: 16%
Problmatique: 53% (budget ou dlais non respects, dfaut de fonctionnalits)
chec: 31% (projets abandonns)
Remarque
Le taux de succs dcroit avec la taille des projets et la taille des entreprises

M.AFILAL

15

Les critres de qualit dun logiciel


Validit :
Conformit d'un logiciel avec sa spcification
Robustesse:
Capacit fonctionner mme dans des conditions anormales
Extensibilit:
Facilit d'adaptation des changements de spcifications
Rutilisabilit:
Capacit tre rutilis en tout ou partie dans un nouveau logiciel
Compatibilit:
Les lments du logiciel peuvent tre combins dautres logiciel sans problmes.
Efficacit:
Utilisation optimale des ressources matrielles (performant : temps de rponse; sans
gaspillage de ressources informatiques : mmoire, unit centrale)
Portabilit:
Facilit de transfert dans diffrents environnements
Vrifiabilit:
Facilit de prparation des procdures de validation
Intgrit:
Aptitude protger codes et donnes
Facilit d'utilisation:
installation, apprentissage, de voir ses rsultats rapidement compris,
16
M.AFILAL
interface utilisateur approprie : aide en ligne

Cycle de vie dun logiciel ?


Le dveloppement dun grand systme logiciel prend un temps considrable
Aussi, il est prvu pour tre utilis pendant longtemps
Cest pour cela, on identifie un certain nombre dtapes dans la priode de dveloppement
Ces tapes constituent le cycle de vie du logiciel
Dfinition (cycle de vie dun logiciel):
Cest le processus qui couvre le droulement des phases de dveloppement, de
distribution et de disparition dun logiciel
Donc, un logiciel est le rsultat dun processus dlaboration constitu
dune suite dtapes ou phases ayant pour objectifs de passer du QUOI (Spcification)
au COMMENT (Conception).
Chaque phase utilise des produits en entre et gnre des produits en sortie, qui
sont utiliss dans les phases ultrieures.
M.AFILAL

17

Cycle de vie dun logiciel ?


Remarque:
Il nexiste pas de processus idal.
La plupart des entreprises adapte les processus existants leurs besoins.
Ces besoins varient en fonction du domaine, des contraintes de qualit, des personnes
impliques.
Ce qui est essentiel, cest de comprendre quel est le rle de chacun dans ce
processus et den saisir les rouages.
Ltude et la pratique de processus existants doit permettre de forger un regard
aiguis (et mme critique) sur ces processus.

M.AFILAL

18

Cycle de vie dun logiciel


Objectifs
Matriser les cots en terme de dlai et de budget
Matriser les risques
Avoir une qualit conforme aux exigences
Cest la feuille de route du dveloppement logiciel
Le cycle de vie est fortement li lassurance qualit
Il faudra en permanence assurer la vrification et la validation
Vrification : Est-ce que nous construisons bien le produit ?
Permet d'assurer que la qualit planifie dans le logiciel est mise en uvre.
logiciel fait ce qui est attendu de lui pas dtat incohrent : ce qui est attendu
des fonctionnalits on le trouve comme rsultat final.
Validation : Est-ce que nous construisons le bon produit ?
Le logiciel rpond aux exigences fonctionnelles et non fonctionnelles des
utilisateurs donc la spcification demande.
M.AFILAL

19

Le processus idal pour le dveloppement dun logiciel


Le processus de dveloppement dun logiciel doit permettre de:
Bien comprendre les demandes et exigences des utilisateurs finaux.
Bien communiquer avec le client.
Tenir compte des changements possibles du cahier de charges.
Empcher la dcouverte tardive de dfauts srieux dans le projet.
Traiter au plutt tous les points critiques dun projet.
Vrifier les critres de qualit bien tablis et attendu pour le logiciel
Bien matriser la complexit.
Favoriser la rutilisation.
M.AFILAL

Dfinir une architecture robuste.

20

Le processus dun logiciel


le processus du logiciel (software process)
est un ensemble structur des activits (des tapes) et leurs rsultats mnent la
ralisation ou modification d'un produit logiciel.
Exemple des tapes:
Expression des besoins utilisateur
spcification,
analyse,
conception,
implmentation ou dveloppement,
intgration,
M.AFILAL

validation et vrification,

21

Dfinitions
Expression des besoins :
Tout ce quon dsire que le systme nous offre pour rpondre nos besoins du point de
vue de son utilisateur (humain ou autres systmes externes) .
Les donnes ou informations sont:
fournies par les experts/utilisateurs du domaine de lapplication, pour cela
Il faut tablir un dialogue entre les informaticiens et les experts/utilisateurs
du domaine
Rsultat:
Ensemble de document dcrivant lenvironnement du future systme,
ses principales fonctionnalits, ses frontires, son rle et sa future
utilisation (parfois un manuel dutilisation prliminaire, ou un dbut de
cahier des charges)
Permet davoir une ide de la faisabilit (lopportunit, le cot, la complexit
de lapplication) et de planification (dlais max de livraison) du systme
Remarque
Les besoins servent de rfrence pour lensemble des phases de fabrication
logicielle
22
M.AFILAL
Comprendre et structurer les besoins du client

Dfinitions
Spcification :
Ce que le systme doit tre, doit faire et comment il peut tre utilis (donne un manuel
dutilisation ):
Cest une description du future systme.
Les donnes:
Rsultat de lexpression des besoins + considrations
technique/faisabilit informatique
Rsultat:
Spcification technique des besoins (Exemple: l'environnement de
l'application, les cas d'utilisations de chaque fonctionnalits, la
normalisation des donnes, la modlisation du flux des donnes, les
maquettes d'crans ... etc...)
Point de dpart au dveloppement
Cest la version manuelle de rfrence + complment de manuel
dutilisation (voir partie dexpression des besoins)
Un cahier des charges finalis: sans ambigut et sans redondance
M.AFILAL

23

Dfinitions
Analyse ou < le quoi>:
Son objectif est de dterminer les lments intervenant dans le systme construire,
ainsi que leur structure et leurs relations.
Ce qui permet, lidentification des objets de gestion ou "objets Mtier".
Elle doit dcrire chaque objet selon trois axes :
Axe fonctionnel : le savoir-faire de lobjet.
Axe statique
: la structure de lobjet.
Axe dynamique : le cycle de vie de lobjet au cours de lapplication (tats et
messages de lobjet).
Ceci permet:
L'identification des objets
l'identification des structures
la dfinition des attributs
la dfinition des services
Remarque
En analyse, on ne tient pas compte de contraintes techniques et informatique.
M.AFILAL

24

Dfinitions
La conception : (ou < le comment>: prise en compte des contraintes techniques)
Permet didentifier la meilleur faon dimplmenter les exigences fonctionnelles du
systme tout en respectant les contraintes non fonctionnelles (budget, dlais, ..)
Elle consiste apporter des solutions techniques aux descriptions dfinies lors de
lanalyse :
Architecture technique (matriel et logiciel, ainsi que de l'organisation de ses
lments constitutifs), performances et optimisation, robustesse et stratgie de
programmation. (preuve de la qualit du logiciel)
On y dfinit les structures (les donnes, les classes), les algorithmes, les interfaces
(plus de dtailles que dans lanalyse).
Permet de revoir la notion de faisabilit du systme
Limplmentation :
Cest la ralisation de laM.AFILAL
programmation.

25

Dfinitions
Intgration :
Assembler tout ou une partie des composants logiciels afin dobtenir un systme
excutable.
Validation:
Permet de sassurer que le systme obtenu rpond lattente des utilisateurs et aux
contraintes de leur environnement.
Ceci via le rsultat de lanalyse des besoins effectue et linspection de la
spcification globale du systme

M.AFILAL

26

Dfinitions
Vrification
Permet de sassurer que le dveloppement est correcte via:
Des inspections des spcifications dfinies au dpart,
Des vrifications de programmes:
de preuve et de teste
Le Teste: consiste chercher des erreurs dans une spcification ou programme
par:
Examen ou analyse de texte (teste statique)
Par des excutions sur un sous-ensemble fini de donnes (teste dynamique):
Teste unitaire: tester des composants isols
Teste dintgration: tester un ensemble de composants venant dtre
assembls
Teste systme: tester le systme sur son future site dexploitation, dans
des conditions oprationnelles.
La preuve:
Porte sur une spcification dtaille ou programme et permet de prouver que
celui vrifie bien
la spcification de dpart
27
M.AFILAL

Les diffrents cycles de vie pour un logiciel


Dfinition:
Le cycle de vie pour un logiciel est lensemble des phases permettant sa construction,
en commenant par ltablissement des besoins du client
jusqu lachvement du logiciel en tant que produit commercial.
Il existe plusieurs approches du cycle de vie dun logiciel, parmi elles, on a:
lapproche traditionnelle,
lapproche objet.
Approche traditionnelle:
Pour cette approche, il existe deux types importants, de cycle de vie dun logiciel:
le modle en Cascade (le modle cascade d'eau ou linaire)
le modle en V .
Le modle en Cascade:
il dcrit un cycle de vie linaire.v
M.AFILAL

28

Version actuelle du cycle en Cascade


validation

Expression des
besoins

validation
Spcifications
Correction
validation

Analyse

Correction

vrification

Conception

Correction

Teste unitaire

Implmentation

Teste Dacceptation

Teste de
vrification

Correction

Teste Systme
Validation
Correction

M.AFILAL

Maintenance
et
29
volution

Cycle de vie en cascade ou linaire : caractristiques


Ce cycle est caractris par une sparation stricte des tapes
On a une interaction seulement entre les tapes successives
Le modle inclut litration et la rtroaction (feedback).
Les boucles de rtroaction permettent de modifier ltape prcdente.
Les flches montantes expriment quune phase ne remet en cause que la phase
prcdente:
En pratique: il y a toujours des problmes qui se propagent de bas en haut.
Chaque tape est complte une certaine date par:
La production de certains documents daccomplissement (ce qua tait fait) pour le
logiciel.
Les rsultats dune phase sont soumis une revue approfondie, et on ne passe la phase
suivante que quand ils sont jugs satisfaisants.
Sachant quune tape est structure en un ensemble d'activits pouvant s'excuter
en parallle par plusieurs personnes
M.AFILAL

30

Cycle de vie en cascade ou linaire : caractristiques


Facile grer
Le modle est facile comprendre et utiliser
Les systmes sont spcifis (leurs besoins) avant leur conception
Les composants du systme sont conus avant leur implmentation.
Les tapes cls sont bien dfinis (les tapes).
Facile maintenir
Dans chaque tape les accomplissements (ce qui fait) sont explicitement documents.

M.AFILAL

31

Cycle de vie en cascade ou linaire : les limites


la sparation des tapes est trop stricte et inflexible
On doit traiter compltement une tape avant de commencer ltape suivante.
Ceci renvoie les tests de vrification et de validation en fin du processus de
dveloppement.
Sil y a des erreurs, les retours seront compliqus et coteraient chers (en
argent et en temps).
Les tapes sont trs artificielles, il est souvent difficile de dterminer la fin dune
tape.
Le modle est seulement appropri quand les exigences (les besoins des utilisateurs) sont
bien dfinies.
Il est rares que le client puisse fournir toutes les spcifications ds le dbut du projet:
les exigences changent constamment
Cest difficile de changer les spcifications quand le processus est en cours

M.AFILAL

32

Cycle de vie en cascade ou linaire : les limites


Le modle ne permet pas la construction des prototypes (un excutable dune partie du
logiciel)
Le client ne voit pas le produit rsultant avant la fin du projet,
Le client ne peut rien utiliser avant que le systme soit complet
Trop tard pour des changements majeurs
Ce modle de cycle implique que, une fois que le produit est livr, tout ce qui reste est la
maintenance.

M.AFILAL

33

Cycle de vie en V dun logiciel


certification

Expression des besoins


Saccorder sur ce
qui doit tre fait
dans le systme

Validation des besoins


Le systme est il
conforme au cahier
des charges ?

Spcifications fonctionnelles

validation

Comprendre les
besoins, les dcrire
dans le systme

Validation fonctionnelle

vrification

Conception du systme

Tests du systme
(intgration)

Saccorder sur la manire


dont le systme doit tre
construit

vrification
Saccorder sur la
manire dont chaque
composant doit tre
construit

Le systme est il
Conforme lanalyse
Des fonctionnalits?

Conception des composants

Tests des composants

Les diffrentes parties


du logiciel fonctionnent
elles correctement
ensemble ?

Pour un objet, chaque


Opration fonctionnetelle
correctement ?

Implmentation
Phase de spcifications
et de conception

M.AFILAL

Phase de tests et de
validation

Cycle de vie en V dun logiciel


Le modle en V: (amlioration du modle en cascade)
Avant de terminer chaque tape danalyse ou de conception (tape fonctionnelle) une
tape de tests ou de vrification ou de validation (tape technique), via un document,
doit tre excute ou construite, ce qui donne une assurance de qualit
Toute description d'un composant est accompagne de tests qui permettront de
s'assurer qu'il correspond sa description .
Le processus saccomplit en deux phases :
Une phase descendante : de spcifications et de conception.
Une phase ascendante : de tests et de validation.

M.AFILAL

35

Cycle de vie en V dun logiciel


Il met en vidence:
La ncessit d'anticiper et de prparer dans les tapes descendantes les "attendus" des
futures tapes montantes :
Ainsi,
les attendus des tests de validation sont dfinis lors des spcifications,
les attendus des tests unitaires sont dfinis lors de la conception, etc.
Par exemple:
l'issue de la conception du systme, le protocole et les jeux de teste de
l'intgration doivent tre compltement dcrits.
Ceci vite dnoncer une proprit impossible vrifier objectivement une
fois le logiciel raliser
Comme pour le modle en Cascade, linconvnient est que :
La validation et les tests interviennent tardivement (phase dintgration).
Il faut que lensemble des besoins soit parfaitement connu et le problme
compltement compris par
les analystes.
36
M.AFILAL

Remarques pour les deux derniers type de cycle de vie


Pas de traabilit entre les tapes:
les concepts ou les discours utiliss dans les diffrentes phase (analyse, conception,
implmentation) du projet sont diffrents.
on utilise une mthode danalyse et de conception avec des concepts et un
langage de programmation avec dautres concepts.
Il est dmontr que:
Corriger une anomalie plus tard cote 10-100 fois plus que de la corriger son
origine.
Les produits avec le moins danomalies ont les dlais les plus courts.
La mauvaise qualit est la raison la plus courante de dpassement des dlais.
La correction des anomalies consomme 40-50 du cot total.
60% des anomalies existent au moment de la conception.
Conclusion:
Perte de temps, de largent et client mcontent ou insatisfait.
M.AFILAL

37

Le cycle de vie Objet


Dans un projet Objet, le cycle de vie doit rpondre trois caractristiques essentielles :
La traabilit entre les tapes.
Un cycle itratif et incrmental.
La traabilit entre les tapes :
Les concepts utiliss au cours des diffrentes tapes sont quasiment identiques (Classes,
Objets, Attributs, Mthodes, Hritage, Polymorphisme, ...).
Ceci permet de conserver le mme discours lors de toutes les tapes :
Analyse - Conception - Implmentation .

M.AFILAL

38

Le cycle de vie Objet: Les plus important concepts


de lapproche Objet
Un objet est une entit forme par:
Les donnes (les attributs avec leur valeur)
Des comportements (des mthodes ) qui agissent sur ces donnes (notion de
spcialisation des fonctions).
Objet = Mthodes + Attributs avec leur valeur un moment de lapplication "
Exemple dobjets de la vie courante:
un tlphone, ville, cafetire, fiches de paie, le bulletin de salaire, lemploy,
lemployeur, la date dmission, etc.. .

M.AFILAL

39

Le cycle de vie Objet: Les plus important concepts


de lapproche Objet

Rve
titi

123CDE91
garfield

mange

0605040302
grosminet

0102030405

parle
001-DF-YTR

poursuit

007BEJ06
Dupond

Dupont
poursuit

java 2
45BEJ91

milou
0203040506

M.AFILAL

40

Le cycle de vie Objet: Les plus important concepts


de lapproche Objet
Un objet est caractris par:
Les services proposs: se sont les mthodes de lobjet
ses champs, son tat et son nom.
les attributs
Information qui qualifie lobjet qui le contient;
Peut tre une constante.
tat (attributs + valeurs)
Valeurs instantanes de tous les attributs dun objet
volue au cours du temps
Dpend de lhistoire de lobjet

Attribu
variable

compte001 : CompteBancaire

Attribu

constant

M.AFILAL

Identit
dobjet

M.Afilal

solde : 10
41
DebitAutorise : 1

Le cycle de vie Objet: notion classe


Une classe est un type de donnes abstrait, caractris par des proprits (attributs et
mthodes) communes des objets et permettant de crer des objets possdant ces proprits.
Une classe est:
une description dun ensemble dobjets ayant des attributs, des mthodes et des
relations en communs.
Un modle partir duquel seront construit les objets cres par le systme.
Un objet est une instance dune classe.
Une classe est reprsente, en UML, par:
son nom, la liste de ses attributs et de ses mthodes,
chaque attribut ou mthode peut tre qualifi avec des symboles : les modificateurs
daccs
Nom de la classe

CompteBancaire

Attributs

- solde
# numCompte

private

+ deposer()
+ retirer()

public

Oprations

M.AFILAL

protected
42

Le cycle de vie Objet: Les plus important concepts


de lapproche Objet
Encapsulation des donnes.
Ceci signifie qu'il n'est pas possible pour l'utilisateur dun objet, d'accder directement
aux donnes (les modes daccs protected, private ou autres).
Lutilisateur doit passer par des mthodes spcifiques crites par le concepteur de
l'objet, et qui servent d'interface entre l'objet et ses utilisateurs.
L'intrt de cette technique est vident.
L'utilisateur ne peut pas intervenir directement sur les donnes dun objet, ce qui
diminue les risques d'erreur, ce dernier devenant une "bote noire".
Exemple:
Changer le sommet dune liste zro, sachant quon a dj des donnes
stockes dans cette liste ( perte dinformation)
En gnral, cela permet de protger les variables membres contre des modifications
incohrentes
Hritage.
43
M.AFILAL
Lhritage permet la dfinition
d'une nouvelle classe partir d'une classe existante.
Il est alors possible de lui adjoindre de nouvelles fonctions membres (mthodes)

Le cycle de vie Objet: Les plus important concepts


de lapproche Objet
Polymorphisme
Le polymorphisme reprsente la facult d'une mme opration de s'excuter
diffremment suivant le contexte de la classe o elle se trouve.
Ainsi, une opration dfinie dans une superclasse peut s'excuter de faon
diffrente selon la sous-classe o elle est hrite.
Exemple :
Excution d'une opration de calcul des salaires dans 2 sous-classes spcialises : une
pour les cadres, l'autre pour les non-cadres. (cration de tableau de Employes puis
appel de la fonction)
Remarque:
Le polymorphisme augmente la gnricit du code.

M.AFILAL

44

Le cycle de vie Objet


Le cycle de vie objet dun projet est divis en un ensemble de mini projets qui sont
appels des incrments.
Un incrment est un ensemble de cycles de dveloppements conduisant certaines
fonctionnalits comprhensibles et utilisables du logiciel construire
A la fin d'un incrment, certains scnarios et exigences ont t conus, ce qui permet
davoir une partie du logiciel
testable,
excutable
et qui sera intgre au noyau du logiciel
Chaque incrment est subdivis en un ou plusieurs itrations.
Une itration est un cycle de dveloppement d'un ou plusieurs cas d'utilisation (ou de
fonctionnalits)
A la fin d'une itration, plusieurs scnarios ou exigences ont t conus et raliss
(testable, excutable et intgrable)
Chaque itration comprend les phases de spcification des besoins, d'analyse, de
conception et des testes
Chaque itration correspond un mini cycle de vie en V par exemple .
M.AFILAL

45

Le cycle de vie Objet


Une itration se droule le plus souvent dans un temps limit
Une nouvelle itration peut tre cause, par exemple, par une modification des
spcifications pour un composant.
Lordonnancement (lordre) des itrations est bas sur les priorits entre les cas
dutilisation (ou scnarios) et ltude des risques.
Exemple de risques:
Dfaillance de personnel, calendrier et budget irralistes, dveloppement de fonctions
inappropries.
Dfaut de conceptions, Exceptions ou erreurs des scnarios, dveloppement
dinterfaces utilisateurs inappropries.
Technologie mal matrise, produits peu connus, problmes de performances
(simulation, modlisation, .. Non bien matrises ?), exigences dmesures par rapport
la technologie utilise ..
Remarque
L'ide de lutilisation des itrations
est de livrer au plus tt quelque chose qui puisse tre test par le client.
On peut en effet raliser plusieurs itrations sur une documentation telle que
46
M.AFILAL
l'architecture(classe,
interface, package, module .).

Le cycle dune itration

Validation des besoins

Tests de vrification

Expression des besoins

Implmentation

Spcifications fonctionnelles

Conception

M.AFILAL

Analyse

47

Cycle dun incrment

Itration: 1

Analyse

Conception

Itration: 2

Code+Test+Intgration

2 4 Semaines

Analyse

Conception

Code+Test+Intgration

2 4 Semaines

M.AFILAL

48

valuation dune itration


3
1
4

2
5

10

8
9

M.AFILAL

49

valuation dune itration


1- On regarde le plan de litration N: du point de vu des scnarios faire, leur cot en
temps, personnes et argent
2- On choisie ce que doit tre fait dans cette itration
3- Via ce qua t dcid dans -2-, on regarde le plan des risques (ce qui va tre enlev, ce
qui peut tre ajout, lordre des taches traiter)
4- Via cela, il y a percussion sur le
cot (ajout de formation ou de personnes qualifies ou quipes ou autres)
dlais (le temps que prend litration en fonction des risque et de la difficult des choix
des taches faire)
5- Le plan du projet est rvis car
le dlais peut tre augment ou diminu
le cot en argent et en personne peut tre augment ou diminu
le contenu des taches peut tre augment ou diminu
6- On regarde la qualit des travaux effectus concernant les taches de litration
7- On regarde les risques enlevs ou ajouts
8- Mise jour du plan gnrale (les taches termines et intgration si cest possible)
9- Construction des scnarios raliser pour la prochaine itration N+1
10- On regarde le plan N+1 et en recommence les mmes tapes cites avant.
M.AFILAL

50

Cycle itratif et incrmental


Le cycle de vie itratif et incrmental se base sur des itrations successives, issus de
chaque incrment.
Chaque incrment ajoute de nouvelles fonctionnalits
Le systme logiciel final grandit de faon incrmentale.
Le systme final sera complet aprs plusieurs incrments
Remarque:
Dans Le cycle itratif et incrmental, on a des versions excutables intermdiaires
frquentes.
L'ide est de livrer au plus tt quelque chose qui puisse tre test par le client, ce
qui lui permettra de voir ltat davancement du projet.
Comme les besoins du client changent ou, pour le moins, s'affinent au fil du
projet.
Ceci permet de dtecter ces changements au plus tt et de les intgrer
(intgration progressive des volutions ) dans lapplication.
M.AFILAL

51

Le cycle de vie itratif et incrmental est en phase avec la ralit car il permet la

Le cycle de vie Objet


Avantages:
Chaque dveloppement est moins complexe
Les intgrations sont progressives
Livraisons et mise en service possibles aprs chaque intgration dincrment.
Permet de mieux lisser dans le temps leffort de dveloppement et les effectifs.
Souvent utilis pour de grands projets.
Remarque:
Au dbut du projet, il faut faire:
Une spcification globale du noyau, des incrments et de leurs interactions.
Des incrments aussi indpendants que possible (aussi bien fonctionnellement
quau niveau des calendriers de dveloppement).
Lors du dveloppement, une ralisation dune maquette pour valider lergonomie
(clart et facilit dutilisation des interfaces par exemple) de lapplication et
lenchanement des crans.
Plusieurs versions peuvent
52 delle, chaque
M.AFILAL tre dveloppes. Lors de chacune
fonctionnalit est amliore jusqu optimisation rendant ainsi le systme
progressivement robuste (cycle itratif).

Langage de modlisation visuelle


Lapproche objet est donc une solution parfaite pour dvelopper un logiciel qui est en
adquat avec la ralit
Comment alors appliquer les concepts objet pour dcrire la structure objet dun systme ?.
La solution est un langage capable:
dexprimer les concepts objet quon va utiliser, pour pouvoir:
Reprsenter des concepts abstraits (graphiquement par exemples )
Limiter les ambiguts (parler un langage commun entre client et concepteur)
Faciliter lanalyse (simplifier la comparaison et lvaluation de solutions)
Davoir une mme dmarche danalyse et de conception objets, pour:
Ne pas effectuer une analyse fonctionnelle et se contenter dune implmentation
objet, mais penser objet ds le dpart (traabilit entre les tapes).
Dfinir les vues qui permettent de couvrir tous les aspects dun systme, avec des
concepts objets.
M.AFILAL

53

La solution UML
La solution est donc un langage qui permet denregistrer nos penses et communiquer en
utilisant des langages visuels et schmatiques:
Exemple: UML.
La raison du choix du langage visuels est quau moins 50% de notre cerveau est impliqu
dans le processus visuel.
Les langages visuels sont naturels et faciles pour notre cerveau.
Cest quoi et pourquoi UML ?.

M.AFILAL

54

La solution UML
UML (Unified Modeling Language) est un langage de construction de modle objet.
UML est un langage de modlisation (donc une notation) standard conu pour lcriture de
plans de construction de logiciels objet.
Il permet de capturer les caractristiques dun systme et de les exprimer laide de
notations prcises : des diagrammes.
Les mthodes objets OMT, Booch et OOSE (Objectory) sont lorigine de la cration du
langage UML en 1997
UML est adopt et standardis par le groupe Object Management Group.
UML n'est pas une mthodologie. Il ne prconise en effet aucune dmarche.

M.AFILAL

55

La solution UML
UML est une notation graphique conue pour:
reprsenter, spcifier, construire et documenter les systmes logiciels.
Ses deux principaux objectifs sont:
la modlisation de systmes en utilisant les techniques orientes objets, de la
conception jusqu la maintenance.
la cration dun langage abstrait comprhensible par lhomme et interprtable par les
machines.
Il permet de construire plusieurs modles dun systme, chacun mettra en valeur des aspects
diffrents:
fonctionnels, statiques, dynamiques et organisationnels

M.AFILAL

56

La solution UML
Les grandes qualits qui font que UML est un langage incontournable :
UML est un langage de modlisation objet.
UML est compos de modules (diagrammes) utilisables indpendamment les uns des
autres et qui expriment les caractristiques du systme au cours de son cycle de vie.
UML nest li aucune technologie ou aucun langage et peut donc tre utilis pour
nimporte quel type de dveloppement.
UML est dans le domaine public.
UML prend le meilleur de chacune des mthodes le prcdant :
OOSE (Jacobson) : cas dutilisation ;
OMT (Rumbaugh) : analyse ;
Booch : conception, architecture.
M.AFILAL

57

La solution UML et rappel


Le but de la construction dun logiciel est de rpondre aux besoins des utilisateurs qui
dfinissent en outre ces limites.
Toute erreur dans les phases danalyse, de spcification ou de modlisation se paie cher
la livraison.
Pour cela, il est ncessaire demployer des outils de modlisation reposant sur un
formalisme non ambigu et reconnu (facilite le dialogue entre concepteur et utilisateur).
Pour modliser un systme complexe, il faut sy prendre plusieurs fois en affinant
lanalyse chaque tape (le choix de type de cycle de vie est important).
Larchitecture systme doit tre adapte pour rendre le systme adaptable, performant,
fiable, .. (bien dfinir la spcification technique du systme)

M.AFILAL

58

Les 9 principaux diagrammes UML


Chaque systme modliser prsente des caractristiques de natures diffrentes au cours
de son cycle de vie, cest pour cela, on a:
un diagramme UML appropri qui est employ pour chaque phase.
Afin de pouvoir capturer, analyser et spcifier ses caractristiques.
Les neuf principaux diagrammes sont:
Diagramme des cas dutilisation
Diagramme de classes
Diagramme dobjets
Diagramme de communication
Diagramme de squences
Diagramme dactivits
Diagramme dtats-transitions
Diagramme de dploiement
Diagramme des composants

M.AFILAL

59

Les 9 principaux diagrammes UML


Diagramme des cas dutilisation:
Permet de dcrire les besoins de lutilisateur final du logiciel
Diagramme de classes:
description des entits du systme et de leurs relations (structure statique)
Diagramme dobjets:
description dinstances objets et des lien entre eux dans un cas particulier
Diagramme de communication collaborations :
description des interactions entre les objets
Diagramme de squences:
description des squences dvnements, tats et ractions qui doivent survenir dans le
systme (modle dynamique)
Diagramme dtats-transitions:
description de lvolution au cours du temps dune instance dune classe (cycle de vie
dun objet) en rponse des vnements.
M.AFILAL

60

Les 9 principaux diagrammes UML


Diagramme dactivit (Cas particulier de diagramme dtats : les tats reprsentent des
activits)
utilis pour dcrire lalgorithme dune opration
focalis sur les traitements internes et non sur la rception dvnements externes
il modlise le comportement interne
dune mthode
dun cas dutilisation
ou dun processus impliquant lutilisation dun ou plusieurs classificateurs
(hirarchie de classes)
Diagramme de dploiement:
Description de la configuration matrielle du systme (position pc, serveur, .)
Diagramme des composants:
Montre les lments physiques et leurs dpendances
(les lments physiques: fichiers sources, librairies, excutables, des codes, des
scriptes, un fichier de commandes, un fichier de donnes, une table).

M.AFILAL

61

Les 9 principaux diagrammes de UML


Les neuf diagrammes peuvent tre classs en quatre modles:
Le modle des classes (le diagramme de classes, diagramme dobjets.).
Permet de reprsenter les concepts usuels de lorient objet (classes,
interfaces, objet,.).
Le modle des tats et le modle dinteraction (diagrammes dtats-transitions,
diagrammes de communication et les diagrammes de squence.)
Permettent de reprsenter la dynamique des objets, sachant quun instant
donn un objet un tat.
Le modle des cas dutilisation.
Permet de dcrire les besoins de lutilisateur final du logiciel.
Le modle de ralisation et le modle de dploiement,
Pour la reprsentation de larchitecture globale du systme et son
dploiement sur les ressources matrielles utilises (processeurs, mmoire,
etc)
62
M.AFILAL
moins importants que les autres modles de UML.

Etapes du processus et diagrammes


A chaque tape du processus de dveloppement, on construit certains des diagrammes
prcdents :
Dcouverte des besoins :
Diagramme des cas dutilisation
Diagramme de squences
Analyse :
Diagramme de classes
Diagramme dobjets
Diagramme de communication
Diagramme dtats-transitions
Diagramme dactivits
Conception :
Diagramme de squence
Diagramme de dploiement
Diagramme de composants
M.AFILAL

63

les catgories des diagrammes en UML


On peut placer ses diagrammes dans trois catgories de modle :
Le modle statique reprsente la structure statique du systme, il contient :
Le diagramme des cas dutilisation.
Le diagramme de classes.
Le diagramme dobjets.
Le modle dynamique reprsente les diffrents tats, volutions, transitions du
systme au cours de son cycle de vie, il contient :
Le diagramme dtats.
Le diagramme dactivits.
Le diagramme de squences.
Le diagramme de communication
Le modle dimplantation reprsente larchitecture globale du systme et son
dploiement sur les diffrents matriels, il contient :
Le diagramme des composants.
Le diagramme de dploiements.
64
M.AFILAL

Diagrammes de UML

M.AFILAL

65

le modle des besoins: Acteur


Dfinition:
Un acteur est une entit externe (utilisateur humain, objet, machine, dispositif matriel, ou autre
systme) qui interagit directement avec le systme tudi afin de raliser une tche (une
fonctionnalit) propose par le systme.
Comment les identifier?
Les acteurs candidats sont systmatiquement:
Les utilisateurs humain directs: faites en sorte didentifier tous les profils possibles, sans
oublier ladministrateur, loprateur de maintenance, etc.
Les autres systme connexes qui interagit aussi directement avec le systme tudie (acteurs
secondaires: imprimante ).
Les entits qui bnficies de lutilisation du systme.

Lidentification des acteurs permet de dlimiter les frontires du systme.


Pour trouver les acteurs, demandez-vous qui
utilise, installe, dmarre, maintient ou arrte le systme. Qui obtient et/ou qui entre linformation?
Qui donne et/ou reoit des informations de lapplication ?
Est-ce que le systme tudi est utilis par dautres systmes?
Qui a besoin de faire quoi M.AFILAL
avec le systme ? etc.
66

le modle des besoins: Acteur


Remarques
La mme personne physique peut jouer le rle de plusieurs acteurs (Chef dagence est un client
de la banque).
Dautres part, plusieurs personnes peuvent jouer le mme rle, et donc agir comme un mme
acteur (plusieurs personnes peuvent jouer le rle dadministrateur).
Un acteur peut tre reprsent de deux manires diffrentes :
Petit personnage (stick man)
Nom Acteur

Classe strotype

<<Acteur>>
Nom Acteur
Remarque:
Du point de vue systme, il existe deux principaux catgories dacteurs:
les acteurs principaux : se sont les dclencheurs du cas dutilisation
les acteurs secondaires, se sont les autres acteurs
67
M.AFILAL
le matriel externe,
comme imprimante
les autres systmes.

le modle des besoins: Acteur


Les acteurs peuvent tre de trois types :
Humains : utilisateurs du logiciel travers son interface graphique, par exemple.
Logiciels : disponibles qui communiquent avec le systme grce une interface logicielle (API,
ODBC, )
Matriels : exploitant les donnes du systme ou qui sont pilots par le systme (Imprimante,
robots, automates, )

M.AFILAL

68

le modle des besoins:Acteur


Un acteur peut tre une spcialisation d'un autre acteur dj dfini.
Dans ce cas, on utilise la relation de gnralisation/spcialisation.

Acte u r g n ra l

Acte u r sp ci a l i s

M.AFILAL

69

le modle des besoins: cas dutilisation


Dfinition
Un cas dutilisation reprsente linteraction entre un acteur et le systme.
Il ralise un service de bout en bout, avec un dclenchement, un droulement et une fin pour
lacteur qui la initi.
Reprsente une fonctionnalit fonction mtier systme mais non une fonction systme,
demande par un acteur, qui sera construite dans le systme:
Cest un objectif mtier prcis.
Remarque:
les cas d'utilisation doivent avoir un sens pour le mtier des acteurs.
Pour identifier les cas d'utilisation, il faut donc se poser les questions :
Mais que va faire cet acteur avec le systme en arrivant le matin au travail?
Pourquoi lacteur dmarre t-il le systme, avec quel objectif mtier ?
Exemple de fonctions mtiers Systme
Grer une commande, consulter un catalogue
Exemple de fonction systme ( fonction )
choisir une commande, imprimer un catalogue
M.AFILAL

70

le modle des besoins: cas dutilisation


Exemple,
Crer une facture ou un bon de livraison. Cest un besoin pour un acteur et un objectif
atteindre pour le systme.
Comment les identifier
Pour chaque Acteur, il convient de:
Rechercher les diffrentes intention mtier (les taches raliser) avec lesquelles il
utilise le systme.
Dterminer dans le cahier des charges les services fonctionnels attendus du
systme.
Nommez les cas dutilisation par un verbe a linfinitif suivit dun complment, du point du
vue de lacteur et non de celui du systme.
Reprsentation:
Il se reprsente par une ellipse qui contient le nom du cas dutilisation
Un cas dutilisation peut inclure
la fonctionnalit dun autre cas dutilisation ou tendre la fonctionnalit dun autre
avec son propre comportement.
Crer facture

M.AFILAL

71

Crer bon Livraison

Diagramme des cas dutilisation


Le diagramme des cas dutilisation permet :
De dfinir le systme mettre en uvre
De recueillir, danalyser, de modliser et dorganiser les besoins du client
Dtablir la liste des acteurs et leurs rles respectifs dans le systme.
de capter les fonctionnalits du systme du point de vue de lutilisateur (observateurs
ou utilisateur extrieur au systme)
De dlimiter les frontires du systme (les services que propose le systme).
Dvaluer lutilit et des fonctionnalits dun systme.
Damliorer la communication dans/entre les quipes
M.AFILAL

De valider les spcifications du systme tudi

72

Diagramme des cas dutilisation


Dans un tel diagramme laccent est mis sur
Le quoi plutt que sur le comment (quoi comme fonctionnalit et non comment
implmenter la fonctionnalit).
Un tel diagramme est compos dacteurs relis des cas dutilisation de lapplication (ou
Systme). On y distingue donc :
Le systme tudi ( ou lapplication).
Les acteurs.
Les cas dutilisation.
Les liens entre acteurs et cas dutilisation
Quel acteur accde quel cas dutilisation ?
Les relations des cas dutilisation par les acteurs sont appels communications ou
associations (lignes)

M.AFILAL

73

Exemple de diagramme des cas dutilisation

M.AFILAL

74

Diagramme des cas dutilisation


Ce diagramme est utile :
Pour dterminer les besoins que doit satisfaire le systme.
Comme moyen de communication avec le client (non informaticien) du fait de sa
simplicit.
Pour gnrer des suites de tests sur le systme
afin de vrifier que le systme ralis rpond aux besoins exprims
Remarque
Un acteur reprsente un rle tenu par une entit (utilisateur, objet, autre application, ..)
situe l'extrieur du systme
Une mme entit (utilisateur, ..) peut jouer plusieurs rles :
Dfinir un acteur par rle
Associ au diagramme, on tablit la description du cas dutilisation :
Le nom du cas dutilisation.
Les acteurs.
Les conditions dentres.
Les vnements. (les scnarios possibles)
Les conditions de sortie.
75
M.AFILAL
Les besoins spciaux. (exp: connection, ..)

Exemple
Questions:
1- Reprsenter en UML les deux cas dutilisation : allumage ou extinction dune lampe
par un utilisateur.
2- Faites intervenir le rseau lectrique dans le cas dutilisation de lallumage de la
lampe
Rponse:
Le systme considr ou tudi est une lampe de chevet.
Les deux interactions lies aux fonctionnalits du systme sont lallumage de la lampe
et son extinction.
Lutilisateur de la lampe est un acteur primaire (ou principale).
Il est bien externe au systme qui est la lampe (lutilisateur ne fait pas partie
de la lampe).
Il interagit avec la lampe au travers de deux cas dutilisation : allumer et teindre
Il profite du service donn par les cas dutilisation car lallumage ou son
extinction de la lampe constituent bien des objectifs essentiels pour lui.
Lampe
Allumer

Utilisateur

M.AFILAL

teindre

76

Exemple
Le rseau lectrique est un acteur secondaire :

que lutilisateur de la lampe allume ou teigne cette dernire nest pas essentielle
pour le rseau lectrique,

mais il interagit avec la lampe lors de lallumage en fournissant de lnergie


lectrique ncessaire.

Il ne profite pas des deux cas dutilisation

Lampe

Allumer

teindre

Rseau
lectrique

Utilisateur
M.AFILAL

77

Relations entre cas dutilisation


Pour optimiser et clarifier un diagramme des cas dutilisation, on tablit des relations entre
les cas dutilisation:
La relation dinclusion.
La relation dextension.
La relation de gnralisation.

M.AFILAL

78

Gnralisation dans les cas dutilisation


Gnralisation :
On construit un nouveau cas en spcialisant un cas dj existant.
Le nouveau cas hrite le sens et les vnements du cas de base.
Utilisation: afin de faire de lhritage (simple).
Virement est une Opration

M.AFILAL

79

Inclusion dans les cas dutilisation


Inclusion
un cas utilise dautres cas comme sous tche (avec obligation dexcution des sous
taches)
Le cas dutilisation Virement utilise le cas dutilisation Validation pour son
traitement,
on doit excuter la cas Validation avant daccepter un virement
Lutiliser lorsquon a un cas dutilisation commun a plusieurs autres cas dutilisation, On
simplifie ainsi le diagramme par factorisation
Remarque:
Les inclusions permettent aussi de dcomposer un cas complexe en sous cas plus
simple
Exemple: Le cas utilisation Virement peut contenir validation, saisir information
compte, et autre cas dutilisation
Ce qui rend le cas de Virement assez complexe si on veut le traiter avec
toutes les scnarios possibles

M.AFILAL

80

Extension dans les cas dutilisation


Extension :
Un cas dutilisation est tendu par de nouveaux vnements dun autre cas
dutilisation.
Lextension est souvent utilise pour indiquer le droulement exceptionnel, anormal
ou optionnel dun cas dutilisation.
Lextension permet un enrichissement du comportement dun cas dutilisation.
Le point dextension indique quand le cas tendu est appliqu.
Virement en devise est un cas optionnel de virement ou cest une extension des
proprits (pas dobligation dexcution du cas virement en devise).

M.AFILAL

81

Extension dans les cas dutilisation


On utilise principalement cette relation
pour sparer le comportement optionnel (les variantes) du comportement obligatoire.
Exemple :
le cas dutilisation B tend le cas dutilisation A signifie que :
Une instance de A va engendrer une instance de B et lexcuter sous certaines
conditions, B sait o sinsrer dans A.
B connat A et non linverse, cest dire que B dpend de A
B nexiste pas tout seul et A existe sans B
Exemple:
Le client entre trois fois un code didentification false alors on appel le cas
dutilisation Retenir carte
Retenir carte est un comportement optionnel dauthentification

Sauthentifier

<<extend>>
M.AFILAL

Retenir carte
82

Exemple
Construire le diagramme des cas dutilisation et la description du cas dutilisation pour le
scnario suivant :
Un internaute ralise un virement entre 2 comptes via le guichet virtuel de sa
banque .
Application

Virement

Client

M.AFILAL

83

Systme
central

Rponse Exemple
tapes suivre:
Pour crer le diagramme des cas dutilisation, il faut commencer par:
Dfinir le systme tudi
Identifier les acteurs (principaux ou secondaires), puis
Les cas dutilisation associs pour chaque acteur, puis
Trouver les interactions qui puissent exister entre les cas dutilisation
et finir par
Donner une spcification ou description du cas dutilisation(avec les principaux
scnarios possibles).
Solution de lexemple:
Acteur(acteur principale): Un internaute.
Acteur (secondaire): Systme central.
Cas dutilisation: Virement
Description textuelle du cas dutilisation

M.AFILAL

84

Rponse Exemple
Cas dutilisation Virement
Titre : Virement
Rsum :
Ce cas dutilisation permet de faire un virement dune somme dargent dun
compte un deuxime compte via une liaison scurise et si la somme virer du
premier compte est valide par le systme central de la banque du client.
Acteurs : un internaute (principale), systme central (secondaire).
Date de cration : 29-12-2010
Date de mise jour : 14-10-2013
Version : 3.0
Responsable : Ahmed Ali

M.AFILAL

85

Rponse Exemple
Description des scnarios :
Prconditions :
Internaute se connecte au site Internet appropri.
Internaute clique sur le bouton Virement.
Client a fournit son nom dutilisateur
Client a fourni son code daccs
Le systme valide lidentification du client.
Scnario nominal (scnario le plus important)
On prsente ce scnario sous forme dun tableau, sparant les Actions des
acteurs et du systme (ou lapplication).

M.AFILAL

86

Rponse Exemple
Action Acteur

Action Systme ou application

1- Le systme central demande le code didentification de lInternaute.


2- Internaute entre son code didentification et clique sur le bouton valider
3- Le systme central vrifie le code entr.
4- Le systme central valide le code didentification de linternaute et
demande dentrer les numros du compte dbiter et du compte crditer
puis le montant du virement.

5-Affichage de la fentre virement

6- Internaute entre les numros du compte dbiter et du compte


crditer puis le montant du virement.
7- Le systme centrale vrifie les numro des comptes et si le montant
dbiter est autoris
8- Le systme centrale valide le virement, mit jour les deux comptes,
affiche un message que le virement sest bien droul.

9-Affichage de la fentre
remercment

9-Internaute clique sur le bouton FIN, puis le cas dutilisation se termine.

10-Affichage de la fentre
Identification Internaute

M.AFILAL

87

Rponse Exemple
Enchanements alternatifs et Enchanements des erreurs

3-a

Le code didentification de linternaute est invalide, le systme avertit linternaute et la troisime


tentative le cas dutilisation se termine

7-a

Si lun des numros de compte est erron, en demande de ressaisir le numro erron puis la troisime
tentative le cas dutilisation se termine.

7-b

Si le compte dbiter est bloqu, on affiche un message puis on reprend le scnario 6 ou en sort du cas
dutilisation se termine.

7-c

Si la somme dpiter est trop lev ou impossible car le solde du compte dbiter ne le permet pas, on
avertie linternaute, puis on reprend le scnario 5 ou en sort du cas dutilisation se termine.

4-a

Le systme valide le scnario 4, puis demande si le virement va se faire en devise, Linternaute choisit le
type de la devise puis le montant dbiter doit avoir la proprit de la devise choisit

Postconditions
Une transaction de virement a t enregistre par le systme central avec toutes
les informations pertinentes (montant dbiter, numros du comptes dbiter
crditer, la date et lheure de la transaction, etc.).
M.AFILAL

88

Exemple
Avec la description textuelle, on peut ajouter dautre cas dutilisation, qui vont optimiser
ou gnraliser dautres cas dutilisation. (dcomposer un cas complexe en des sous cas
moins complexes)
Les cas dutilisation ajouts dans le systme prcdant sont :
Identification et Validation
Se sont des cas dutilisation interne au systme (dans Virement),
Elles sont ajoutes pour montrer les liaisons entre cas dutilisation storotypes
include et puis extend .
Virement en devise est un cas particulier de virement ou cest une extension des
proprits de Virement.
Le lien entre ses deux cas dutilisation se fait via des instances de chaque cas
dutilisation.

M.AFILAL

89

Exemple
Application
Virement
SI choix devise

<<extend>>

<<include>>
<<include>>

Virement en
devises
Identification
client

Validation

Systme
central

Client
M.AFILAL

90

Exemple de syntaxe dune classe


Cercle2D
Attributs
-centre : Point
- rayon : float {gel}
/perimetre : float

Methodes
+ getCentre ( ) : Point
+ getRayon ( ) : float
+ $ surfaceTotale(list : Cercle2D[ ]) : float

Exceptions
rayonNonValideException

Remarque concernant le champ rayon


float {gel} rayon est une constante de type float (attribut non modifiable)
en gnrale rayon : float <<proprit>>, avec proprit ={gelee, variable,
ajoutUniquement}
91
M.AFILAL

Classe et objet
Une classe est:
une description dun ensemble dobjets ayant des attributs, des mthodes et des
relations en communs.
Un modle partir duquel seront construit les objets cres par le systme.
Un objet est une instance dune classe.
Une classe est reprsente, en UML, par:
son nom, la liste de ses attributs et de ses oprations (mthodes),
chaque attribut ou mthode peut tre qualifi avec des symboles : les modificateurs
daccs :
Remarque:
La dclaration dun attribut a la syntaxe suivante :
<modificateur daccs> [/]< Nom_Attribut >:< Type_attribut> ['['multiplicit ']']
[=valeur(s) initiale(s)] {proprit}
La dclaration dune opration a la syntaxe suivante :
<modificateur daccs>< NomDeLaMethode ([paramtres]) >:[<valeurRenvoye]
{proprit}
M.AFILAL

La syntaxe de la liste des paramtres:

92

Classe et objet
Remarque
Multiplicit := (Intervalle | nombre)
Intervalle := Limite_Infrieure ..Limite_Suprieure
Limite_Infrieure:= entier_positif | 0
Limite_Suprieure := nombre
Proprit, dans le cas de la syntaxe dun mthode est donne par:
{abstrait}: indique une opration non implmente dans la classe. Le nom dune opration
abstraite peut galement tre rendu par une fonte en italique
{estFeuille}: Indique que lopration ne peut tre redfinie dans une sous classe (la proprit
de type boolen)
{estRacine}: indique que lopration est dfinie pour la premire fois dans une hirarchie de
classes (la proprit est de type boolen)
{requete}: indique que lopration naltre pas ltat de linstance concerne (la proprit est
de type boolen; la valeur vraie peut tre omise)
{concurrence = valeur}: o valeur est squentiellement gard (Lintgrit de lobjet est
garantie par un mcanisme de synchronisation externe) ou concurrent
valeur est lobjet
ou le champs ou le paramtre sur lequel on applique
la
93
M.AFILAL
synchronisation

Autres prsentations: interface et classe abstraite


<<Exception>>
Forme2DNonValide

<<interface>>
Forme2D

+ getCentre ( ) : Point
+ getRayon ( ) : float
+ $ surfaceTotale(list : Cercle2D[ ]) : float

Cercle{abstract}

- centre : Point

+ getCentre ( ) : Point
M.AFILAL
+ * surface
( ) : float
+ $ * surfaceTotale(list : Cercle2D[ ]) : float

94

Classe implmentant une interface


Forme2D

<<interface>>
Forme2D

<<interface>>
Forme2D

Cercle

Cercle

Cercle

M.AFILAL

95

Reprsentation dun objet


On reprsente un objet par la notation suivante ,qui prcise le nom de la classe dont il est
une instance et la valeur de ses attributs.

titi : Voiture

marque = Citroen
modele = DS 21
immatriculation = 19 AS 01

M.AFILAL

96

Problmes de dtermination des classes et objets


La dtermination des classes lors de la phase danalyse nest pas vidente.
Elle suit une mthode plutt intuitive, base sur lexprience de lanalyste qui a (ou
na pas) lhabitude de reconnatre plus ou moins facilement:
les classes, les objets, les associations, les attributs et les mthodes des classes.
Lanalyste pourra se demander:
Quels sont les objets de gestion (les objets mtiers) dans le problme tudi afin
didentifier les objets rels.
Ainsi que leurs liens et les modliser sous formes de classes et
dassociations.
Aussi, dutiliser les descriptions textuelles des cas dutilisation afin de reprer les
objets mtiers et ainsi dduire les classes intgrer dans son analyse.

M.AFILAL

97

Diagramme de classes
Le diagramme de classe donne une vue densemble statique du systme en prsentant
toutes les classes dfinies dans le systme, leurs cooprations et leurs interactions.
Ces classes peuvent tre relies de multiples manires :
La dfinition des relations est aussi importante que la dfinition de chaque classe.
Il y a plusieurs types de relation entre les classes :
Lassociation.
Lagrgation.
La composition.
La gnration.
La spcialisation.
La dpendance.
Remarque:
Les diagrammes de classes UML constituent un surensemble de diagrammes entitsassociations (E-A).
Alors que les digrammes E-A classiques sont centrs sur les donnes, les diagrammes
de classes vont un peu plus loin et permettent galement la modlisation de
comportements.
98
M.AFILAL

Lassociation
Une association est une relation entre classes.
Une association modlise la connexion entre deux classes dont lune a besoin de lautre
pour tre dfinie ou pour exister (liaison).
Exemple :
Une personne peut possder des voitures.
la relation possde est une association entre les classes Personne et Voiture
Un employ commercial est en relation avec ses clients.
La classe Client a un champ type commercial ou simplement un identifiant
idCommercial
La classe Employ a un champ de type Client[ ] ou simplement un vecteur
contenant les idClients
Une association dcrit une relation entre les objets de deux classes (ou plus).
Une des classes doit avoir connaissance de lautre pour accomplir son traitement.
En gnral les associations sont binaires, cest dire quelles connectent deux classes.
M.AFILAL

99

Lassociation
On reprsente une association en traant une ligne entre les classes associes.
Les associations peuvent tre nomme par une forme verbale.
Le sens de lecture est prcis par un symbole < ou > .
par dfaut de gauche vers la droite
L'extrmit d'une association est appele rle.
Le rle dcrit comment une classe voit une autre classe au travers d'une association.
Le rle est un pseudo attribut de la classe source (utilis comme un attribut).
Enfin, chaque rle d'une association porte une indication de cardinalit (multiplicit) qui
montre combien d'objets d'une classe peuvent tre lis un objet de lautre classe.
ValeurMultiplicit
Signification
n
exactement n instances
n..m
de n m, valeurs incluses
*
valeurs quelconque, quivaut 0 . . n ou 0 . .
n..*
au moins n
n . . m, p . . q
liste de valeurs ou dintervalles
Entreprise
1..1
Employeur
M.AFILAL

Emploie >

1..*
Intrimaire

Personne
100

Contrainte dordre sur les associations


Les contraintes sur les associations
se reprsentent dans les diagrammes par des expressions places entre accolades.
La contrainte {ordered} {ordonn}
Elle peut tre place sur le rle pour spcifier quune relation dordre dcrit les objets
de la collection.
le modle ne spcifie pas comment les lments sont ordonns, mais seulement que lordre
doit tre maintenu durant lajout et ou la suppression des objets par exemple.
class Catalogue{
private List<Livre> obj = new ArrayListAvecOrdre<Livre>();
}
class Livre{ //.}

{ordered}

Catalogue
1..*

Livre

1..*

contient >
M.AFILAL

101

Contrainte dordre sur les associations


Ce diagramme exprime que :
Une personne est ne dans un pays, et que cette association ne peut tre modifie ceci
via la contrainte frozen (frozen = gele, elle peut tre associe un champ pour
exprimer quil est constant);
Une personne a visit un certain nombre de pays, dans un ordre donn, et que le
nombre de pays visits ne peut que crotre ;
Une personne veut visiter toute une liste de pays, et que cette liste est ordonne
(probablement par ordre de prfrence).

M.AFILAL

102

Contrainte dexclusion sur les associations


Exclusion entre association : Une seule relation est valide la fois pour un objet donn.
Exemple:
Une personne est employ soit par une entreprise prive ou par ltat.
Remarque:
Dans limplmentation (pour exprimer autrement cette contrainte), on peut utiliser un
champ dune classe mre abstraite dont drive les deux classes Entreprise et Etat.
class Personne{
private SocieteEmployeur objSociete;
}
SocieteEmployeur est la classe mre des deux classes Entreprise et Etat.
Employeur

Entreprise

private
{ XOR }

Etat

M.AFILAL

Employeur

public

Personne

Contrainte dinclusion sur les associations


La contrainte dinclusion ou sous-ensemble:
Elle relie un sous-ensemble dobjets lis par une autre association.
Exemple:
Une entreprise emploi des personnes, un dlgu gre les intrts des employs dans
lentreprise, ce dlgu est aussi un employ de cette entreprise
Cette association indique que les objets qui participent la relation dlgus
participent galement la relation employ.
Les dlgus dune entreprise sont aussi des employs de cette entreprise.
employ

Personne

Entreprise
{ Subset }

M.AFILAL

dlgu

104

Association rflexive
Association rflexive:
Deux objets de la mme classe sont impliqus dans la relation, il faut nommer les rles.
Cette relation permet de structurer les objets de la mme classe:
Crer une hirarchie entre objet, partitionner les objets, regrouper les objets en classe
dquivalence
Exemple

1- un manager dirige un plusieurs employs. Chaque employ est dirig par un seul manager
2- une personne a le mme age qua zro plusieurs personnes
3- une personne possde deux parents et de zro plusieurs enfants.

1
manager

Personne
Employ
1..*

<
dirige

Personne
Personne
0,*

Personne
0,*

< a le mme
age

0,*

2pare
nt
M.AFILAL

105

< est parent

<

0,*

est amie
de

Association rflexive
Association symtrique non transitive
Permet de partitionner les instances de la mme classe
Association symtrique et transitive
Permet de regrouper les objets, de la mme classe, en classe dquivalence.
Association asymtrique
Permet de crer un hirarchie (sorte darbre) entre les objets.
Exemple:
Ami de: est une relation symtrique non transitive, permet de partitionner les objets.
A le mme age: est une relation symtrique transitive, permet de crer une relation
dquivalence.
Parent de: est une relation asymtrique(anti-Symetrique), elle permet de crer un arbre
(une hirarchie) entre les objets.
M.AFILAL

106

Association rflexive
Remarque:
Il est conseill dajouter les rles des extrmits dans le cas des relations asymtriques.
Une relation rflexive se traduit, dans la dfinition dune classe, simplement par une
rfrence sur un objet de la mme classe
Exemple (avec java)
class Personne{
Private Personne manager;
Private Vector<Personne> employes;
}

M.AFILAL

107

Associations entre 2 classes et plus


Association ternaire: cest une relation entre trois classes.
Elle est trs peu utilise et trs dlicate, notamment quand on ajoute la multiplicit.
Les trois classes sont relies par un losange.
Remarque:
Il faut essayer de transformer cette association en des associations binaires avec des
contraintes (si cest possible).
Exemple:
On dfinit une Formation comme la rencontre dun intervenant avec des stagiaires
dans une salle.

Intervenant
1
Salle

1M.AFILAL

2..*

108

Stagiaire

Classe association
Si une association contient des proprits, on construit alors une classe association:
Cette classe association peut participer dautres relations avec dautres classes.
La notation utilise une ligne pointille pour attacher cette classe lassociation.
Remarque:
La multiplicit sur le lien de chaque classe sapplique sur une instance du losange.

Intervenant
1
Salle

2..*

Stagiaire

Formation
M.AFILAL

date
sujet

109

Exemple: transformation dune classe association


Remarque:
La multiplicit sur le lien de chaque classe sapplique sur une instance du losange

Intervenant
1
Salle

1
association ternaire
1
1
Formation

2.. *

date
sujet

M.AFILAL

110

Stagiaire

Classe association
Une classe association peut tre remplace par une classe intermdiaire et qui sert de pivot
pour une paire dassociations.
Exemple: Transformation dune classe-association en une classe et en associations binaires.
A = tudiant; B = Travail et C classe association C avec attribut = note
Un tudiant ralise m travail et un Travail est ralis par n tudiant,
chaque travail fait par un tudiant lui est associ une note,
Le champ note ne peut tre dans la classe tudiant (un tudiant peut effectuer
plusieurs travaux et chaque travail une note)
Ni dansRalise
la classe Travail (dans un travail, il y a autant de note que dtudiants).

M.AFILAL

111

La qualification dans lassociation


Afin de slectionner un sous ensemble des objets participant une relation,
On ralise ce quon appelle la qualification de la relation au moyen dune cl ou lment cible de
la classe (attribut ou ensemble dattributs: cest la valeur de qualification) appele qualifiant.
Permet didentifier un sous-ensemble des instances de la classe qui participent lassociation.
Une instance du couple {Banque , numCpt} est en association avec une instance de la classe
Compte.
La banque hberge un et un seul compte dont le numro de compte est donn sous forme de
qualifiant.
Les instances de la classe compte sont qualifiables grce au numro de compte.
Permet de spcifier un chemin prcis pour trouver un objet cible a partir dun objet source avec le
qualifiant est du cot source.
Permet de rduire la cardinalit maximale 1.

Banque

Compte

*
hberge

Banque
M.AFILAL

NumCpte:String

hberge

Compte
112

La qualification dans lassociation

0..1
Qualificatif: Q

public class A{
private Map< Q, B> BObj = new HashMap< Q, B >;
Ou
private Map< Q, B > BObj = new HashTable< Q, B >;
.
}
Avec: Q = type de la cl utilise
dans le Map
M.AFILAL

113

La qualification dans lassociation


Le diagramme ci-dessous exprime que :
Une instance du triplet {Echiquier, range, colonne} est en association avec une
instance unique de la classe Case.
Inversement, une instance de la classe Case est en association avec une instance unique
du triplet {Echiquier, range, colonne}.

M.AFILAL

114

La navigabilit dans les associations


Par dfaut les associations sont navigables dans les deux directions.
Dans certain cas, une seule direction de navigation est utile:
lextrmit de lassociation vers laquelle la navigation est possible porte une flche
(une demi association).
La navigabilit dans un sens:
Exprime que les objets dune classe A voient les objets dune classe B, mais les objets
de la classe B ne voient pas les objets de la classe A
Elle permet de rduire les couplages et dpendances entre classe.

M.AFILAL

115

La navigabilit dans les associations


Exemple:
Un polygone est dfini par un ensemble de points qui jouent le rle de sommets.
En gnral
elle est encombrant que les points aient un lien vers les figures (polygone) aux quelles
appartiennent.
La navigation est possible dans un seul sens, uniquement du polygone vers les points (le
polygone est dfini par des points et non linverse)
Remarque:
Un objet de la classe polygone a besoin pour exister des objets de type points
Un objets de type point na pas besoin dobjet de type polygone pour quil puisse
exister.
est dfini par

Polygone

Point
0..*

3..*

Modlisation de la navigation avec des attributs


Polygone
#sommet:Point[3..*]
M.AFILAL

116

Agrgation
L'agrgation est une association non symtrique
qui exprime lide quun objet fait partie dun autre objet.
qui exprime un couplage fort entre des classes, une des extrmits joue un rle
prdominant par rapport lautre extrmit.
Elle matrialise une relation de type:
compos et composant: "est-compos-de"
tout et parties: "est-une-partie-de"
matre-esclave: "appartient- "
Etc
Elle reprsente une relation dinclusion structurelle ou comportementale dun lment
dans un ensemble.
Le nom de la relation, en gnrale, est:
fait partie de ou contient ou compos de ou possde ou appartient , etc
Le compos(le tout) est lagrgat et les composants (les parties) sont les instances
agrges.
117
M.AFILAL
lagrgat joue le rle
dominant dans lassociation.

Agrgation
Remarque:
En pratique, l'identification d'une relation d'agrgation de celle d'association n'est pas
vidente.
Exemple : Un document est un ensemble de paragraphe.

Document

M.AFILAL

Paragraphe

118

Agrgation
Proprits de lagrgation:
Le tout est responsable de la gestion de ses parties.
Laction sur le compos(agrgat) entrane une action sur le composant(lagrg).
Un composant peut tre partag par plusieurs agrgats :
la multiplicit cot agrgat peut avoir une valeur suprieur 1.
Exemple:
une phrase peut tre dans plusieurs paragraphes.
La relation est transitive :
Exemple: un paragraphe est compos de phrases, les phrases sont composes de
mots et donc un paragraphe est compos de mots
La relation ne peut tre symtrique :
un composant ne peut contenir le compos.
Les valeurs sont propages de lagrgat au composant :
Exemple:
la mise en italique du paragraphe entrane la mise en italique des phrase.
Remarque:
La dure de vie de lagrgat est indpendante des lments qui le constituent (cas o
un composant est partag par plusieurs agrgats)

M.AFILAL

119

Agrgation
Autres critres qui indiquent une agrgation:
Une classe fait partie dune autre classe,(classe interne)
Les valeurs dattributs dune classe se propagent dans les valeurs dattributs dune
autre classe
La modification dun attribut dun objet agrgat porte aussi sur les attributs des
objets agrgs.
Une action sur une classe implique une action sur une autre classe.
La suppression dun objet agrgat ferait disparatre les objets agrgs.
Les objets dune classe sont
Subordonns (secondaires, dpendants) aux objets dune autre classe,
contrls par les objets dune autre classe.
La dfinition dune mthode de lobjet agrgat repose sur celles des objets agrgs
M.AFILAL

120

La composition
La composition est une agrgation pour laquelle les composants (partie) possdent une
dure de vie incluse dans celle de lagrgat(ne peut exister sans lui.).
Le composant ne peut exister sans lagrgat et ne peut appartenir qu un seul agrgat.
La valeur de la multiplicit du cot de lagrgat ne peut prendre que les valeurs 0 ou 1
car le composant ne peut tre partag par plusieurs agrgat.
La valeur 0 du ct du composant indique un attribut non renseign.
La suppression dun objet agrgat ferait disparatre les objets agrgs.
Une relation de composition est une agrgation qui vrifie de plus:
l'opration de destruction de lagrgat entrane la destruction de lagrg.
la multiplicit du ct agrgat est infrieur ou gale a 1.
Elle est reprsente en ajoutant un petit losange noire du ct de lagrgat.
M.AFILAL

121

Exemple de la composition
Universit

Facults

1,*

Dpartements

1,*

gre

Etudiants

M.AFILAL

122

Relation composition et attributs


La composition et les attributs sont smantiquement quivalents.

possde

M.AFILAL

123

La gnralisation
Elle exprime un lien dhritage reliant une classe enfant une classe parent
La classe enfant possde les mmes attributs, opration, associations que sa classe
parent.
La classe enfant ajoute des descriptions spcifiques
La spcialisation est la relation inverse.
Une classe peut hriter de plusieurs classe

Vehicule

A moteur

A voile
M.AFILAL

124

La gnralisation
Contraints sur les gnralisations:
{disjoint}:
Une sous classe de la hirarchie ne possde quune seule classe parent (contraints
par dfaut).
{overlapping}:
Une classe peut possder plusieurs classe parent.
{complete}:
La gnralisation est complte. On ne peut ajouter dautres sous classes la
hirarchie.
{incomplete}:
La gnralisation est incomplte. On peut ajouter dautres sous classes la
hirarchie.

M.AFILAL

125

La gnralisation
Vehicule

{disjoint}
(milieu)

(motorisation)

A_Moteur

A_Voile

Terrestre

Maritime
{overlapping}

{overlapping}

Trimaran
Voiture

M.AFILAL

126

La dpendance
Cest une relation unidirectionnelle, exprimant une dpendance non structurelle, de la
classe source vers la classe cible.
Elle indique que la modification de la cible implique un changement de la source.
Exemple :
Un composant graphique a besoin dune couleur pour pouvoir safficher.(choix dune
nouvelle couleur entrane un changement de couleur du composant)
Le droulement des cours dpend de lemploi de temps
Elle reprsente une relation sur les classes uniquement, sans induire de liens sur les objets
instance de ces classes
La dpendance exprime la situation o une classe utilise une autre classe,
par exemple, en appelant une mthode de la 2me classe.
Remarque:
Lusage de telles relations est dconseill dans un diagramme car source dimprcision
et de couplage entre les classe (trop de classe)
M.AFILAL

127

La dpendance

Cible

Source

ComposantGraphique

Cours

Couleur

EmploiDeTemps
M.AFILAL

128

Interface et association

Quand une classe dpend dune interface pour raliser ses oprations, elle est dite classe
cliente de linterface .
Graphiquement, cela est reprsent par une relation de dpendance entre la classe et
linterface.

<<interface>>
NomInterface

NomClasse

M.AFILAL

129

Exemple de cas

Un microprocesseur est constitu de portes logiques. Ces portes logiques sont composes
de transistors qui fonctionnent comme des interrupteurs. On trouve deux sortes de portes
de base : les portes MOS et les portes CMOS.
Les microprocesseurs sont cadencs par une horloge caractrise par sa vitesse.
Les microprocesseurs sont bass sur deux mthodes doptimisation: la technologie CISC et
la technologie RISC
Tracez le diagramme de classe correspondant la description ci-dessus

M.AFILAL

130

Exemple de cas
La phrase un microprocesseur est constitu de portes logiques met en vidence deux notions
importantes ce qui permet davoir deux classes: Microprocesseur et PorteLogique
Les deux classes sont lies par une relation de composition, puisquune porte nappartient qua un seul
microprocesseur et son existence dpend de celui-ci
La seconde phrase met en vidence une nouvelle classe Transistor.
Chaque porte logique est compos de transistors , ce qui correspond une relation de composition.
La cardinalit * est ajoute aux extrmits des objets composant (les agrges)
Le diagramme initiale est donn par:
Microprocesseur

*
PorteLogique
M.AFILAL

Transistor
131

Exemple de cas
Les portes MOS et CMOS sont des spcialisations de la classe PorteLogique qui devient
une classe abstraite

Microprocesseur

*
*

PorteLogique
{abstract}

PorteMos

Transistor

PorteCMOS

M.AFILAL

132

Exemple de cas
La phrase Les microprocesseurs sont cadencs (rythms) par une horloges caractrise
par sa vitesse dcrit le lien existant entre la classe Microprocesseur et la classe Horloge,
lien est prsent par lassociation cadensPar.
La frquence est un attribut de la classe Horloge

Microprocesseur

Horloge

cadensPar >
1

M.AFILAL

- frquence:Integer

133

Exemple de cas
La dernire phrase Les microprocesseurs sont bass sur deux mthodes doptimisation: la
technologie CISC et la technologie RISC
Or, un microprocesseur ne peut tre modlis que sur lune des deux mthodes
La dernire phrase peut tre modlise de deux faon diffrentes
par deux associations qui sexcluent mutuellement:
Ou bien construire une classe abstraite qui gnralise les deux classes TechnologieCISC et
TechnolgieRISC
TechnologieCISC
< basSur
1
TechnologieRISC

{XOR}

Microprocesseur
*
*

TechnologieCISC

Technologie
{abstract}
1

TechnologieRISC
M.AFILAL

Microprocesseur

< basSur
*
134

Exemple de cas
Le diagramme complet est:
Technologie
{abstract}

< basSur
1

Horloge

cadensPar >

Microprocesseur

- frquence:Integer

TechnologieCISC

PorteLogique
{abstract}

TechnologieRISC

PorteMos

M.AFILAL

PorteCMOS

135

Transistor

Vous aimerez peut-être aussi