Analyse et Conception objet du logiciel

L’approche Orientée Objet et UML

© Rémy Courdier – V2.8 1

 Analyse et Conception objet du logiciel

Plan du cours

■  Introduction au Génie Logiciel

■ L’approche Orientée Objet et UML

■  Les diagrammes de modélisation

■  Relations entre les différents diagrammes

■  De l’analyse à la conception

■  Relation entre les notations OMT et UML

■  Les Design Pattern

© Rémy Courdier – V2.8 2

 Analyse et Conception objet du logiciel

Conception et Objet

© Rémy Courdier – V2.8 3

 Analyse et Conception objet du logiciel 2. L’approche orientée objet

Chapitre 2 : L’approche Orientée Objet

■  Rappel des principes de l’orienté objet

■  Les Objets

■  Les messages ou la communication entre objets

■  Les classes

■  Les relations entre les classes

■  L’héritage entre classes

■  Les architectures à base d’objets

© Rémy Courdier – V2.8 4

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.1 Rappels des principes de l’orienté objet

2.1. Rappels des principes de l’orienté objet

■  Calquer le découpage de la représentation

informatique sur les entités physiques et virtuelles
mises en jeu dans les processus réels que l’on
cherche à modéliser ou à automatiser
■  Privilégier une approche architecturale pour
implémenter des solutions à des problèmes plutôt
qu’une approche fonctionnelle visant à résoudre un
problème posé
ü Stabilité de la modélisation par rapport aux entités du monde réel
ü Construction itérative facilitée par le couplage faible entre
composants
ü Possibilités de réutiliser des éléments d’un développement à un
Autre
ü ...

© Rémy Courdier – V2.8 5

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.2 Les Objets

2.2 Les Objets

■  Définition :
ü Un objet définit une représentation d’une entité atomique réelle
ou virtuelle, dans le but de le piloter ou de le simuler.
Les objets encapsulent une partie des connaissances du monde
dans lequel ils évoluent.
ü Un objet associe données et traitements en ne laissant visible
que l’interface de l’objet, c’est à dire les traitements que l’on
peut faire dessus
■  Objet = Identité + Etat + Comportement
ü L’Identité : En plus de son état un objet possède une identité qui
permet de le distinguer de manière non ambiguë
indépendamment de son Etat.
ü L’état : regroupement des valeurs instantanées de tous les
attributs d’un objet
ü Le comportement : regroupe toutes les compétences d’un objet
et décrit les actions et les réactions de cet objet

© Rémy Courdier – V2.8 6

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.2 Les Objets(2)

Notations

■  En UML un objet se représente sous la forme d’un

rectangle; le nom de l’objet est souligné
■  Le rectangle dont le coin en haut est replié
représente une information de clarification
optionnelle appelée note
■  Les deux points précisent qu’il s’agit d’objets
anonymes
Trois Héros
de jeux
:Héros

0,5 m
Batman
Taille et 5
niveau de rapidité 2,00 m :Héros
5 1,50 m
3
© Rémy Courdier – V2.8 7
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.3. Les messages

2.3. Les messages

■  Les objets d’un système informatique travaillent en

synergie pour réaliser les fonctions de
l’application.
ü Le comportement global d’une application repose sur la
communication entre les objets qui la compose
ü Il existe un grande richesse de communication entre les objets

■  Le message est la représentation des interactions

entre les objet
ü il relie de façon dynamique les objets qui ont été séparés par le
processus de décomposition
ü il est un intégrateur dynamique qui permet de reconstituer une
fonction de l’application par la mise en collaboration d’un groupe
d’objets

© Rémy Courdier – V2.8 8

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.3. Les messages(2)

Notations

■  Les messages sont représentés par des flèches

placées le long des liens qui unissent les objets
élimine
:Héros :Ennemi

■  Notion de synchronisation
:Expéditeur :Destinataire

envoi simple (un seul objet à la fois est actif)

envoi synchrone (expéditeur bloqué jusqu’à acceptation du destinataire)

envoi dérobant (destinataire bloqué jusqu’à réception du message)

envoi minuté (bloque l’expéditeur pendant un temps donné)

envoi asynchrone (n’interrompt pas l’exécution de

l’expéditeur)
© Rémy Courdier – V2.8 9
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.4. Les classes

2.4. Les classes

■  Définition :
ü La classe décrit le domaine de définition d’un ensemble
d’objets : C’est un modèle qui définit les données et les
traitements communs à une collection d’objets similaires
ü Chaque objet appartient à une classe
ü Les généralités sont contenues dans la classe et les particularités
dans les objets
■  Terminologie orientée objet
ü Les traitements sont appelés méthodes ou opérations de l’objet
ü Les données sont appelées variables, données membres,
attributs ou propriétés
ü Les objets informatiques sont construits à partir de la classe par
un processus appelé instanciation
ü Tout objet est instance d’une Classe

© Rémy Courdier – V2.8 10

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.4. Les classes (2)

Notation

■  Chaque classe est représentée sous la forme d’un

rectangle divisé en 3 parties
Nom de classe Héros
:Héros
attributs nom Instanciation
taille Batman
opérations() marcher() 2,00
...
coucher() Instance

■  Les parties peuvent êtres supprimées pour alléger

les diagrammes
Nom de classe Héros

© Rémy Courdier – V2.8 11

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.4. Les classes (3)

L’encapsulation

L’occultation des détails de réalisation est appelée

encapsulation
ü Par défaut les valeurs des attributs d’un objets sont encapsulées
dans l’objet et ne peuvent pas être manipulées directement par
un autre objet

Un accès « libre »
a des attributs
peut conduire
rapidement à des
données mal
gérees

© Rémy Courdier – V2.8 12

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.4. Les classes (3)

L’encapsulation

L’occultation des détails de réalisation est appelée

encapsulation
ü Des règles de visibilité précisent la notion d’encapsulation
;  assouplissement du degré d’encapsulation et de protection au profit
de certaines classes bien particulières
;  intérêt : réduire le temps d’accès aux attributs
Nombre complexe
ü Trois niveaux d’encapsulation : - partie imaginaire
;  privé (-): attribut non vu de l’extérieur de l’objet - partie réelle
en C++ les classes amies peuvent + addition()
encore accéder aux attributs + soustraction()
;  protégé (#): attribut vu par des classes dérivées + multiplication()
;  public (+): attribut visible pour toutes les classes + division()

© Rémy Courdier – V2.8 13

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes
2.5 Les relations entre les classes
La relation d’association

Une association représente une relation sémantique entre les objets,

elle correspond à une abstraction des liens qui existent entre les
objets instances

association
:Combat Batman :Héros Combat Héros

Zoro :Héros une association se représente par une ligne

continue tracée entre les classes

Nommage d’une association Rôle d’une association

met en jeux > Héros
Combat Héros
Combat Personnage

Combat < s’engage dans
le nommage des associations facilite
la compréhension des modèles
© Rémy Courdier – V2.8
Spectacle Public
Héros
Le rôle décrit comment une classe voit une
autre classe au travers d’une association
Le rôle prend tout son intérêt lorsque plusieurs
associations existent entre 2 classes
14
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(2)

Multiplicité et Contraintes

■  La multiplicité précise le nombre d’instances (et non de

liens comme dans Merise) qui participent à la relation

Trop d’instances
peuvent conduire
à une
catastrophe !

Imaginez le
même type de
problème avec
un A380…
© Rémy Courdier – V2.8 15
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(2)

Multiplicité et Contraintes (2)

■  Toutes sortes de contraintes peuvent être définies sur

une relation ou un groupe de relations
exemple : {ordonnés} ; {Sous-ensemble} ; (Ou-exclusif}

Héros
0..1 2..*
Combat {Ou-exclusif} Personnage
1 *
Spectacle Public
Un combat met en jeu différents personnages ; certains joueront
le rôle du public et d’autres le rôle de Héros de combat. Un
Héros donné peut s’engager dans un combat ou non. Un
personnage du public est toujours spectateur d’un combat.

© Rémy Courdier – V2.8 16

 Analyse et Conception objet du logiciel

Navigabilité et association récursive

■  Navigabilité d’une association

Manager s’occupe de Héros Restriction de la navigabilité
d'une association à un seul sens
à l'exécution.
flèche

Le manager peut transmettre des message au Héros mais le Héros ne

peux pas prendre l’initiative de communication avec le Manager

■  Association récursive
Personnage Manager

Héros
*

< s’occupe de

© Rémy Courdier – V2.8 17

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(3)

Les classes-associations

■  Une association peut être représentée par une

classe pour ajouter des attributs et des opérations
ü Une telle classe peut participer à plusieurs relations
ü Une telle classe qui ne participe pas à d’autres relations est
appelée association attribuée et ne porte pas de nom
■  La notation UML utilise une ligne pointillée pour
attacher une classe à une association
< s’engage dans Combat < s’engage dans Héros
Combat Héros * 2..*
* 2..*
Contrat Techniques
prime type
prime challenger grade
niv. challenger
1..* *

association attribuée classe association

© Rémy Courdier – V2.8 18
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(4)

Les restrictions ou qualification

Une qualification consiste à sélectionner un sous-

ensemble d'objets parmi l’ensemble des objets qui
participent à une relation
ü réduction du nombre d’instances qui participent à une
association (multiplicité ou cardinalité)
ü Une restriction est réalisée au moyen d’un attribut particulier
appelé “Clé“
ü La clé est représentée au niveau de la classe de départ dans un
compartiment rectangulaire
EspaceJeux
:C2
ligne
C1 C2 :C1 :C2
:C2 :C2 colonne
:C2
C1 clé C2 :C1 :C2 1
:C2
Position
© Rémy Courdier – V2.8 19
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(5)

La relation d’agrégation

■  Décrit une relation de contenance ou de composition

■  Il s’agit d’une variante de l’association portant la
sémantique suivante :
« Est inclus dans »
■  Propriétés
ü une classe fait partie d’une autre classe (composition)
ü les valeurs d’attributs d’une classe se propagent dans les
valeurs d’attributs d’une autre classe
ü une action sur une classe implique une action sur une autre
classe
ü les objets d’1 classe sont subordonnés à ceux d’1 autre classe
Note : L’agrégation n’implique par contre pas nécessairement ces critères !

■  Notation UML :
ü Une agrégation se représente avec un 1..* *
C1 C2
losange placé du coté de l’agrégat Inclus dans >

© Rémy Courdier – V2.8 20

 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.5. Les relations entre les classes(5)

La relation d’agrégation forte

ou de composition

■  Représente une contenance structurelle entre instances

Décrit la notion de « tout et parties » dans laquelle les parties sont
indissociables du tout.

■  Association portant la sémantique suivante :

« est composé de »

■  Propriétés
La cardinalité placé à coté de l’agrégat et facultative et correspond par
défaut à 1..1, elle peut être 0..1 mais jamais x.. .
*
Une partie d’un tout n’appartient qu’à un seul tout.

■  Notation UML :
0..1 *
Une agrégation se représente C1
est composé de >
C2
avec un losange plein placé
du coté de l’agrégat.
© Rémy Courdier – V2.8 21
 Analyse et Conception objet du logiciel

Agrégation et compostion

On utilise une composition et non une simple agrégation si :

■  La destruction de l’instance représentant « le tout »

implique obligatoirement la destruction des instances
représentant les parties (les composants)

■  La copie de l’instance représentant « le tout »

implique nécessairement la copie de ses composants car
ceux-ci ne peuvent faire partie que de ce « tout » et ne
peuvent pas être associés à d’autres « tout ».

© Rémy Courdier – V2.8 22

 Analyse et Conception objet du logiciel

2.7 La relation de Dépendance

■  Relation exprimant une dépendance sémantique entre les éléments

du modèle Cette relation est nécessairement orientée.

■  Cadre d’utilisation:
ü Dépendance d’interface : entre une classe et une interface que celle-ci
s’impose de respecter.
Sémantique « réalise » ou « implemente »
ü Dépendance de Stéréotype : Pour définir une classe générique
paramétrable.
Sémantique « bind »
ü Dépendance d’instanciation : Poir décrire une relation entre une classe
et ses instances
sémantique « instanceof »

■  Notation UML :
Représentée par une C1 C2
ligne pointillée orientée
© Rémy Courdier – V2.8 23
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.6. L’héritage entre classes

2.6 La relation d’héritage entre classes

Les hiérarchies de classes ordonnent les objets au

sein d’arborescences d’abstraction croissante
■  Généralisation
ü Factorisation des éléments communs d’un ensembles de classes
dans une classe plus générale appelée super-classe
■  Spécialisation
ü Capture des particularités d’un ensemble d’objets non
discriminés par les classes déjà identifiées
■  Notation UML
ü La généralisation est symbolisée par une ligne entre deux classe
terminée par une flèche qui pointe vers la classe la plus générale
Spécialisation

Super-classe < sorte de Sous-classe

Généralisation
© Rémy Courdier – V2.8 24
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.6. L’héritage entre classes(2)

Le polymorphisme

“caractéristique d’un élément qui peut prendre

plusieurs formes”
■  Chaque sous classe peut modifier localement le
comportement de ses opérations pour considérer
le particularisme de son niveau d’abstraction
Combat < s’engage dans
Héros
0..1 2..*
frapper()

L’opération frapper est

polymorphe car sa Monstre Superman Extraterrestre
réalisation peut prendre
plusieurs formes frapper() frapper() frapper()

frapper() frapper() frapper()

pattes poings ondes cosmiques
© Rémy Courdier – V2.8 25
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.6. L’héritage entre classes(3)

Notions avancées

■  Critères de généralisation
ü Spécialisation selon plusieurs critères simultanément
ü On associe des discréminants à la relation de généralisation
■  Contraintes
ü généralisation exclusives /inclusives
; {Exclusif} : par défaut une généralisation est exclusive ; une classe
descendante d’une classe A peut être descendante d’une seule sous-
classe de A
; {Inclusif} : Une classe descendante de la classe A appartient au
produit cartésien des sous-classes de la classes A
ü Généralisation complète / Incomplète
A
; {Complète} :
existence de toutes Critère1 Critère2 {Incomplète}
{Inclusif}
les sous-classes
A1.1 A1.2 A2.1 A2.2
; {Incomplète} :
généralisation extensible

A3
© Rémy Courdier – V2.8 26
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.6. L’héritage entre classes(4)

Les classes abstraites

■  Classe non instanciable

ü  Ne donne pas naissance à des objets
■  Classe de spécification générale
ü  Il s’agit de sorte de type de classe
■  Base pour les logiciels extensibles
ü  L’ensemble des mécanismes généraux est décrit dans les
classes abstraites sans tenir compte des spécificités
rassemblées dans les classes “concrètes“
■  Notation UML : Héros
ü  Le nom des classes
abstraites est en italique frapper()

Monstre Superman Extraterrestre

frapper() frapper() frapper()

© Rémy Courdier – V2.8 27
 Analyse et Conception objet du logiciel 2. L’approche orientée objet
2.7. Les architectures à base d’objets

2.8 Les architectures à base d’objets

■  Les mécanismes objets se retrouvent :

ü dans les langages de programmation, on parle alors de POO
ü au cœur de certaines Bases de Données
ü dans les environnements d’interface Homme-Machine
ü dans l’archi. des documents du World Wide Web et de l’Internet
ü comme base des modèles et méthodologies de développement
■  Langages orientés objets :
ü Smalltalk : Xerox Palo-Alto - Californie
ü C++ : Bell Laboratories d’AT&T
ü Java : Sun micro-système
ü Simula, Eiffel, Ada 95, Pascal Objet,...
■  Les objets distribués :
ü Corba et les ORB - (Common Object Request Broker Architecture)
ü OLE/DCOM et les ActiveX - (Object linking et embedding)
ü Java Beans - Java RMI (Remote Méthode Invocation)
© Rémy Courdier – V2.8 28
 Analyse et Conception objet du logiciel

Difficultés

Les principales difficultés que l'on rencontre quand

on commence UML sont généralement les suivantes :

■  Il faut découvrir à la fois le langage UML, une

méthode de mise en œuvre et un environnement de
modélisation.
■  On réalise une étude de très haut niveau donc
relativement abstraite qui doit malgré tout trouver
un sens dans le monde réel.
■  La sémantique des nouvelles technologies est très
faible et UML n'apportent pas encore assez de sens
aux termes employés. Il faut donc rester vigilant sur
le sens des choses.
© Rémy Courdier – V2.8 29
 Analyse et Conception objet du logiciel

Fin du Chapitre 2

L’approche Orientée
Objet et UML

© Rémy Courdier – V2.8 30