UV LO43 - Bases fondamentales de la

Programmation Oriente Objet

Introduction lanalyse OO UML




1 Notion dobjet.............................................................................................................................................2
2 Les classes ...................................................................................................................................................3
3 Prsentation d'UML (Unifed Modeling Language).................................................................................3
4 Le modle conceptuel d'UML ...................................................................................................................4
4.1 Les lments.........................................................................................................................................4
4.2 Les relations .........................................................................................................................................4
4.3 Les diagrammes ...................................................................................................................................4
5 Diagrammes de classes...............................................................................................................................4
5.1 Les classes............................................................................................................................................4
5.2 Les classes abstraites............................................................................................................................5
5.3 Les interfaces .......................................................................................................................................6
5.4 Les relations entre classes ....................................................................................................................6
6 Diagrammes d'tats-transitions ................................................................................................................8
7 Diagrammes de cas d'utilisation ...............................................................................................................9
8 Diagrammes dactivits ...........................................................................................................................11
9 Diagrammes de squences .......................................................................................................................11
10 Bibliographie ............................................................................................................................................12

Introduction lanalyse OO UML
1 Notion dobjet
Lobjet est une unit atomique forme de lunion dun tat et dun comportement. Il fournit
une relation dencapsulation qui assure la fois une cohsion interne trs forte et un faible
couplage avec lextrieur. Lobjet sinsre dans un scnario de communication par
lintermdiaire de lenvoi de messages.
En informatique, les objets sont des abstractions des entits du monde rel ou des entits
virtuelles. Ils peuvent aussi bien reprsenter des composantes physiques avec leur masse, leur
taille ou leur forme, que par extension des entits abstraites auxquelles nous confrons une
importance particulire dans nos pratiques ou dcisions, tels que des comptes en banques, des
quations, des interfaces graphiques. La modlisation des objets permet de reprsenter le
cycle de vie des objets au travers de leurs interactions avec dautres objets. Un programme
orient objets consiste donc en la mise en relation dun ensemble dobjets.
Un objet est une abstraction qui possde les trois caractristiques suivantes :
Objet = tat + comportement + identit
- un tat
Un tat regroupe les valeurs instantanes de tous les attributs dun objet. Chaque attribut
prend ses valeurs dans un domaine de dfinition donne. Ltat volue au cours du temps, les
valeurs des attributs peuvent changer.
Exemple :
Une voiture

couleur = bleue
masse = 979 kg
puissance = 12 CV




- un comportement
Un comportement regroupe toutes les comptences dun objet et dcrit les actions et les
ractions de cet objet. Chaque comportement lmentaire est appel opration. Les oprations
dun objet sont dclenches suite une stimulation externe, reprsente sous la forme dun
message envoy par un autre objet. Ce oprations sont implantes dans les mthodes de
lobjet.
- une identit.
En plus de son tat, un objet possde une identit qui caractrise son existence propre.
Lidentit permet de distinguer tout objet de faon non ambigu, et cela indpendamment de
son tat. Ainsi, il est possible de distinguer deux objets dont toutes les valeurs dattributs sont
identiques. Chaque objet possde une identit attribue de manire implicite la cration de
lobjet et jamais modifie. Cette identit peut galement tre explicite et provenir du domaine
du problme (par exemple une immatriculation de vhicule).
2
Introduction lanalyse OO UML
2 Les classes
Une classe est une abstraction dcrivant le domaine de dfinition dun ensemble dobjets.
Chaque objet appartient une classe. Les gnralits sont contenues dans la classe et les
particularits sont contenues dans les objets. Un objet est appele instance de classe.
Les langages objet permettent de dcrire et de manipuler des classes et leurs instances. Cela
signifie que lutilisateur peut construire en machine une reprsentation informatique des
abstractions quil a lhabitude de manipuler. En principe, les langages objet rduisent la
distance entre notre faon de raisonner (par abstraction) et le langage compris par les
ordinateurs, ce qui rend leur utilisation plus aise et le programme plus gnrique et
modulaire. Dans un langage informatique, on dit galement quune classe met en oeuvre la
notion de type abstrait de donnes.
Le but de lanalyse et de la mthode UML est ainsi de permettre la modlisation dune
application ou dun domaine de problme, indpendamment dun langage de programmation
en particulier, par lutilisation de descriptions semi-formelles incorporant les aspects
essentiels de la description dun systme dobjets en interaction.
Nous rappelons ici les concepts principaux de lapproche objet dans le cadre de cette
mthodologie. Nous nous limitons ici la prsentation de trois types de modles de la
mthode UML, qui couvrent des aspect statiques et dynamiques du systme et qui prsentent
donc des points de vue complmentaires et essentiels de lapproche de modlisation.
3 Prsentation d'UML (Unifed Modeling Language)
Un modle est une reprsentation simplifie de la ralit permettant de mieux comprendre le
systme que l'on dveloppe. La construction de modles (appele modlisation) a quatre
objectifs principaux :
- les modles aident visualiser un systme tel qu'il est ou tel que nous voudrions qu'il
soit,
- les modles permettent de prciser la structure ou le comportement d'un systme,
- les modles fournissent un canevas qui guide la construction d'un systme,
- les modles permettent de documenter les dcisions prises.
Dans le cadre de la conception oriente objet, un langage unifi pour la modlisation a t
dvelopp, appel UML (Unifed Modeling Language). Il s'agit d'un langage graphique de
modlisation objet permettant de spcifier, de construire, de visualiser et de dcrire les dtails
d'un systme logiciel. Il est issu de la fusion de plusieurs mthodes dont Booch et OMT et est
adapt la modlisation de tous types de systmes. La modlisation d'un systme s'effectue
indpendamment de tout langage de programmation.
UML est un langage : il comprend un vocabulaire et un ensemble de rgles centrs sur la
reprsentation conceptuelle et physique d'un systme logiciel.
3
Introduction lanalyse OO UML
4 Le modle conceptuel d'UML
Le modle conceptuel d'UML comprend les notions de base gnriques du langage. Il dfinit
trois sortes de briques de base :
- les lments, qui sont les abstractions essentielles un modle,
- les relations, qui constituent des liens entre ces lments,
- les diagrammes, qui regroupent des lments et des liens au sein de divers ensembles.
4.1 Les lments
Il existe quatre types d'lments dans UML :
- les lments structurels (classe, interface, collaboration),
- les lments comportementaux (interaction, automate dtats finis),
- les lments de regroupement (paquetage),
- les lments d'annotation (note).
4.2 Les relations
Il existe quatre types de relations dans UML :
- la dpendance,
- l'association,
- la gnralisation,
- la ralisation.
4.3 Les diagrammes
Les diagrammes sont des reprsentations graphiques d'un ensemble d'lments et de relations
qui constituent un systme. UML dfinit neuf types de diagrammes diviss en deux grandes
catgories :
1. diagrammes statiques (appels aussi diagrammes structurels) : diagrammes de classes,
d'objets, de composants, de dploiements et de cas d'utilisation.
2. diagrammes dynamiques (appels aussi diagrammes comportementaux) : diagrammes
d'activits, de squences, d'tats-transitions et de collaborations.
5 Diagrammes de classes
Ils expriment de manire gnrale la structure statique d'un systme, en termes de classes et
de relations entre ces classes.
5.1 Les classes
Une classe est une reprsentation d'un ensemble d'lments partageant les mmes attributs, les
mmes oprations, les mmes relations et la mme smantique. En programmation oriente
objet, une classe dfinit une abstraction, un type abstrait qui permettra d'instancier des objets.
4
Introduction lanalyse OO UML
Reprsentation dune classe :
Nom en italique si la
classe est abstraite
Mthodes
Attributs
Nom de la classe





Reprsentation simplifie :

Nom de la classe
ou Nom de la classe



Graphiquement, une classe dcrite en UML peut tre plus ou moins prcise :

La premire classe (classe1) est dite visibilit rduite, tandis que les deux autres (classe2 et
classe3) sont dites visibilits dtailles.
Trois niveaux de visibilit sont possibles pour les attributs et les oprations dune classe :
- + : visibilit public. La caractristique peut tre utilise par n'importe quelle
instance dune autre ou de la mme classe.
- - : visibilit private. La caractristique ne peut tre utilise que par des instances de
la classe elle mme.
- # : visibilit protected. La caractristique ne peut tre utilise que par des instances
de la classe elle-mme ou bien par les descendants directs de cette classe.
5.2 Les classes abstraites
Une classe abstraite sert de spcification pour des objets instances de ses sous-classes. Elle
dfinit un mode daccs et de communication (interface) par dfaut pour la classe et
ventuellement un comportement (implmentation) par dfaut pour certaines oprations. Une
classe abstraite ne peut pas tre instancie directement, certaines de ces oprations ntant pas
ncessairement dfinies. Voici un exemple de reprsentation graphique d'une classe abstraite :

5
Introduction lanalyse OO UML
5.3 Les interfaces
Une interface dcrit un contrat d'une classe ou d'un composant sans en imposer
l'implmentation. Une interface ne dcrit aucune structure ni aucune implmentation. Elle ne
peut donc pas contenir d'attributs, ni de mthodes fournies sous la forme d'une
implmentation.
Voici un exemple de reprsentation graphique d'une interface :

5.4 Les relations entre classes
5.4.1 L'association
Les relations dassociation prcisent que des objets d'une classe sont relis aux objets d'une
autre classe. La reprsentation graphique d'une association indique le nom de lassociation,
prcise des rles attribus aux objets dans la relation, et les cardinalits de la relation. Il peut
sagir de relation de un (ou zro) un, de un plusieurs, de plusieurs plusieurs.
Multiplicits possibles : 1 un et un seul objet
0..1 de zro un objet
* de zro plusieurs objets
M..N de M N
Par exemple :

Dans cette relation une personne est lie au moins zro et au plus plusieurs entreprises par la
relation est employe par . Inversement, une entreprise emploie une ou plusieurs
personnes. Une personne joue le rle demploy, et une entreprise joue le rle demployeur.
5.4.2 La dpendance
La relation de dpendance est une relation smantique entre deux lments selon laquelle un
changement apport l'un peut affecter la smantique de l'autre. Par exemple :
6
Introduction lanalyse OO UML

5.4.3 La gnralisation
La relation de gnralisation relie un lment gnral et un lment driv de celui-ci par
spcialisation. Cette relation dfini une structure dinclusion entre classes, cest pourquoi elle
est aussi souvent appele relation est un . Une classe plus spcialise est une sous classe de
la premire. La relation de gnralisation est reprsente dans un langage objet par la relation
d'hritage.
Classe, sous-classe:

B
A





Un exemple classique d'une gnralisation est le suivant :

5.4.4 L'implmentation
La relation dimplmentation entre une classe et une interface spcifie que la classe
implmente les oprations dfinies par l'interface. Par exemple :

7
Introduction lanalyse OO UML
5.4.5 L'agrgation
Il sagit dune relation de type tout-parties dans laquelle une classe reprsente un lment
plus grand (le tout ) compos d'lments plus petits (les parties ). La relation
d'agrgation est souvent implmente en utilisant des membres privs. Dans ce type de
relation, les composants ont gnralement une existence indpendante de llment compos.
Par exemple :

5.4.6 La composition
Il sagit dune relation d'agrgation mettant en avant une notion de proprit forte et de
concidence des cycles de vie. Les parties sont cres et dtruites en mme temps que le
tout . Exemple :

6 Diagrammes d'tats-transitions
Ils servent reprsenter des aspects dynamique du systme, spcifier comment celui-ci se
comporte lors que loccurrence des vnements externes et internes. Ils sont spcifis par des
automates tats-finis imbriqus (statecharts) sous forme de graphes d'tats, relis par des
arcs orients qui dcrivent les transitions entre tats. Voici des exemples dtats et de
transitions :

Les diagrammes d'tats-transitions permettent de dcrire les changements d'tats d'un objet ou
d'un composant, en rponse aux interactions avec d'autres objets, composants ou acteurs. Un
tat se caractrise par sa dure et sa stabilit. Il reprsente un instantan des valeurs des
attributs d'un objet. Une transition reprsente le passage instantan d'un tat vers un autre.
Une transition est dclenche par un vnement. C'est donc l'arrive d'un vnement qui
conditionne la transition. Si l'on ne spcifie pas l'vnement qui la dclenche, une transition
peut tre galement automatique. En plus de spcifier un vnement prcis, il est aussi
possible de conditionner une transition l'aide de gardes qui sont des expressions
boolennes exprimes en langage naturel et places entre crochets.
8
Introduction lanalyse OO UML
Un super-tat est un lment de structuration de ce type de diagrammes. Il s'agit dun tat qui
englobe d'autres tats. Le super tat masque les dtails de ses sous-tats, ce qui facilite une
conception par raffinement successifs des sous-tats imbriqus. Voici un exemple dtat
imbriqu :

Il est possible d'associer une action l'vnement qui dclenche une transition. La syntaxe
consiste tiqueter les transitions avec le couple vnement/action. Ceci exprime que la
transition dclenche par l'vnement cit amne l'excution de l'action spcifie sur la
transition. De mme, on peut reprsenter la concurrence entre des tats, cest dire entre les
processus quils reprsentent. Dans lexemple suivant, le systme est la fois dans les tats A
et B. On parle alors dtats ET pour qualifier ces tats, et dtats OU pour qualifier les
autres tats comportant des transitions squentielles.

7 Diagrammes de cas d'utilisation

Les diagrammes de cas dutilisations sont souvent spcifis en amont de lanalyse et de la
conception pour dcrire les fonctionnalits gnrales de lapplication suivant les besoins
9
Introduction lanalyse OO UML
exprims par lutilisateur. Les cas d'utilisation du systme reprsentent les acteurs et les
relations existant entre eux sous la forme d'actions et de ractions. Ils permettent de dfinir les
limites du systme et les relations entre le systme et l'environnement. Ce type de diagrammes
peut servir de guide ensuite tout au long du cycle de dveloppement, depuis le cahier des
charges jusqu' la fin de la ralisation.
Un acteur reprsente un rle jou par une personne ou une chose qui interagit avec un
systme. Il est reprsent comme ainsi :

Un acteur peut galement participer des relations de gnralisation/spcialisation :

Le cas dutilisation proprement dit est une modlisation d'une fonctionnalit. Les cas
d'utilisation se dterminent en observant et en prcisant, acteur par acteur, les squences
d'interaction du point de vue de l'utilisateur. Ils se dcrivent en termes d'informations
changes et d'tapes dans la manire d'utiliser le systme. Un cas d'utilisation regroupe une
famille de scnarios d'utilisation selon un critre fonctionnel. Ils dcrivent des interactions
potentielles, sans entrer dans les dtails de l'implmentation. La reprsentation graphique est
la suivante :

Il existe trois types de relations entre cas d'utilisation :
- La relation de gnralisation : le cas d'utilisation enfant est une spcialisation du cas
d'utilisation parent.
- La relation d'inclusion : le cas d'utilisation source comprend galement le
comportement de son cas d'utilisation destination. Cette relation a un caractre
10
Introduction lanalyse OO UML
obligatoire ( la diffrence de la gnralisation) et permet ainsi de dcomposer des
comportements partageables entre plusieurs cas d'utilisation diffrents.
- La relation d'extension : le cas d'utilisation source ajoute son comportement au cas
d'utilisation destination. L'extension peut-tre soumise condition. Cette relation
permet de modliser des variantes de comportement d'un cas d'utilisation.
Les trois types de relations entre cas d'utilisation sont reprsents graphiquement de la
manire suivante :

8 Diagrammes dactivits
Il sagit dun variante des schmas Etat/Transition dans laquelle les transitions se font
automatiquement. Les tats reprsentent des activits du systme et les transitions leur
enchanement. Il peut y avoir des transitions conditionnelles (gardes), mais pas dvnement
externes dclenchant. Des reprsentations en traves parallles et des barres de
synchronisation permettent de prsenter des activits concurrentes et synchronises, par
exemple entre diffrents acteurs.
9 Diagrammes de squences
Ils servent exprimer des scnarios, des protocoles ou des exemples de dialogues et
dchanges de messages entre objets en modlisant leurs enchanements temporels suivant un
axe du temps.
11
Introduction lanalyse OO UML
12
10 Bibliographie

[1] Booch G., J. Rumbaugh et I. Jacobson1, The Unifed Modeling Language Reference
Manual, Addison-Wesley, 1999.
[1] G. Booch, Conception oriente objets et applications, Addison Wesley Publishing
Company, 1992.
[2] Muller P.A. et N. Gaertner, Modlisation objet avec UML, Eyrolles, 2000.
[3] J. Rumbaugh, OMT, Modlisation et conception orientes objet, Masson, Prentice Hall,
1996.
[4] Stevens P. et R. Pooley, Using UML, Software Engineering with Objects and
Components, Addison-Wesley, 2000.
[5] P. Coad, E. Yourdon, Analyse oriente objets, Masson, 1993.
[6] F. Bernardi, cours UML, http://spe.univ-corse.fr/bernardiweb/cours.htm. 2002.