Modélisation avec UML : Introduction générale

David Célestin FAYE

UFR SAT/UGB
Plan 2

1 Présentation générale d’UML

2 Modélisation objet élémentaire avec UML

Objectifs du cours 3

Z Introduire la modélisation orientée objet

Z Connaître les concepts du langage UML
Différents types de diagrammes avec leurs notations
Rôles complémentaires des types de diagrammes
Cohérence entre diagrammes de même type ou de types
différents
Z Présenter des éléments méthodologiques d’utilisation des
différents types de diagrammes dans un processus de
développement
Z Illustrer les concepts et la modélisation avec un AGL(Atelier de
génie logiciel)
Le prérequis est la maîtrise des principes de la programmation
orientée objet.
 Présentation générale d’UML
Modélisation objet élémentaire avec UML

Plan 4

1 Présentation générale d’UML

2 Modélisation objet élémentaire avec UML

David Célestin FAYE Modélisation avec UML 4/107

Introduction 5

Z Les systèmes deviennent de plus en plus complexes

Z Complexité architecturale : Client/serveur, Intranet, Corba
(Common Object Request Broker Architecture), Systèmes
distribué...
Z Le recours à un modèle conceptuel s’avère indispensable pour
les comprendre
Z modèle
représentation abstraite d’un système, qui facilite l’étude et la
communication entre intervenants au sein d’un projet
utilisé et progressivement enrichi dans toutes les étapes d’un
projet : spécification, analyse, conception, test, intégration et
rétro-ingénierie
Z UML est le standard industriel de modélisation orientée objet
La complexité des logiciels 6

Z Le logiciel est complexe de par sa nature

Z les systèmes peuvent être décomposés selon
ce qu’ils font(approche fonctionnelle)
ce qu’ils sont(approche objet)
Z L’approche objet gère plus efficacement la complexité
Introduction 7

Z UML = Unified Modeling Language

Langage unifié pour la modélisation objet
Langage de modélisation des applications construites à l’aide
d’objets, indépendant de la méthode utilisée
Z Normalisé par l’OMG (Object Management Group)
Z Notation standard pour la modélisation d’applications à base
d’objets (et de composants depuis la version 2)
Z UML utilisable dans de nombreux autres contextes de
conception ou spécification
Exemple : Conception schéma de Base de Données
Introduction 8

Z Langage utilisant une notation graphique

Z Langage Vs Méthode
Langage de modélisation =notations,grammaire, sémantique
Méthode : comment utiliser le langage de modélisation (recueil
des besoins, analyse, conception, mise en œuvre, validation...)
Pourquoi modéliser ? 9
Z Objectif principal de la modélisation = maîtriser la complexité
Z Le modèle est une représentation abstraite de la réalité qui
exclut certains détails du monde réel.
Abstraction de ce qui est intéressant pour un contexte donné
Vue subjective et simplifiée, mais pertinente d’un système
Z Utilité des modèles
Faciliter la compréhension d’un système
Définir, voire simuler le fonctionnement d’un système
Z Le modèle, outil de communication
diagrammes de modélisation : instruments de communication.
Communiquer autour d’un modèle pour évaluer et comparer
des solutions, c’est avant tout « reconnaître »la réalité perçue.
si un modèle est « reconnu », c’est parce qu’il était « connu ».
Z Le modèle doit être relié au monde réel
Par exemple : l’existant avant les travaux, le réalisé, le restant
à réaliser
Principes de la modélisation 10

Z Le modèle doit être relié au monde réel

↱ Par exemple : l’existant avant les travaux, le réalisé, le
restant à réaliser
Z Un modèle peut être exprimé avec différents niveaux
d’abstraction / raffinement
↱ Par exemple : répartition électrique de l’université, du centre
de calcul, de la salle des serveurs
Z Une seule « vue »du système n’est pas suffisante
↱Par exemple : Les intervenants multiples du projet de
construction possèdent des préoccupations multiples : plan de
masse, vues de face et de côté, schéma électrique, plan de
plomberie,
Exemples de modèles 11

Z Modèle météorologique : à partir de données (nuage, vents,

pression atmosphérique), permet de prévoir les conditions
climatiques pour les jours à venir
Z Modèle économique : à partir d’hypothèses
macro-économiques (évolution du chômage, taux de
croissance...), permet de simuler l’évolution de cours boursiers
Z Modèle démographique : définit la composition d’un panel
d’une population et son comportement, dans le but
d’augmenter l’impact de démarches commerciales, etc...
Caractéristiques d’un modèle 12

Z Le caractère abstrait d’un modèle doit notamment permettre :

de faciliter la compréhension du système étudié : il en réduit la
complexité.
de simuler le système étudié : il représente le système étudié et
reproduit ses comportements
Z Un modèle réduit (décompose) la réalité, dans le but de
disposer d’éléments de travail exploitables par des moyens
mathématiques ou informatiques
Les Langages de modélisation 13

Z Un langage de modélisation doit définir :

La sémantique des concepts ;
Une notation pour la représentation de concepts ;
Des règles de construction et d’ utilisation des concepts.
Z Plusieurs langages de modélisation :
systèmes procéduraux (MERISE...) ;
systèmes temps réel (ROOM, SADT...) ;
systèmes à objets (OMT, Booch, UML...).
Z Le rôle des outils (Ateliers Génie Logiciel) est primordial pour
l’utilisabilité en pratique des langages de modélisation.
Les méthodes d’analyse 14

Z Une méthode définit un processus d’information, possède un

champ d’étude et décrit une démarche à suivre.
Z Composants d’une méthode :
1 Modèles
2 Langage
3 Démarche
4 Outils et techniques
Les méthodes d’analyse 15

Modèles : ensemble de concepts et de règles destinés à

expliquer et construire la représentation de phénomènes
organisationnels.
Langages : spécifier et simplifier la communication
Démarche : processus à suivre pour effectuer les travaux
demandés, découpée en étapes.
Outils et techniques : aide à la mise en œuvre des modèles,
langages, et démarche.
Les méthodes d’analyse 16
Z Méthodes orientées comportement
on s’intéresse à la dynamique du système
ex : réseaux de Pétri
Z Méthodes fonctionnelles :
on s’intéresse aux fonctions du système
ex : SADT
Z Méthodes orientées données :
on ne s’intéresse pas aux traitements
ex : MERISE
Z Méthodes orientées objets :
on ne sépare pas les données et les traitements
ex : Booch, OMT
Z Les méthodes agiles (Agile Modeling ) :
développer une version minimale, puis intégrer les
fonctionnalités par un processus itératif basé sur une écoute
client et des tests tout au long du cycle de développement.
Les méthodes d’analyse 17

Z Une méthode étant un assemblage d’une démarche et d’un

langage de modélisation.
Z Exemples de démarches :
Processus Unifié(UP)
eXtreme Programming(XP)
RUP(Rational Unified Process)
L’unification des méthodes d’analyse 18

Z Recherche d’un langage commun unique

Utilisable par toutes les méthodes
Adapté à toutes les phases du développement
Compatible avec toutes les techniques de réalisation
Z Objectifs :
Réduire la complexité de la modélisation ;
créer un langage de modélisation avec des représentations
graphiques mais disposant de qualités formelles suffisantes
pour être traduites automatiquement en code source ;
Z Officiellement UML est né en 1994.
Unified Modeling Language 19

Z Langage= syntaxe +sémantique

Syntaxe : Règles selon lesquelles les éléments du langage (ex.
les mots) sont assemblés en des expressions (ex.
phrases,clauses).
Sémantique : Règles permettant d’attribuer une signification
aux expressions syntactiques
Z UML est un langage qui permet de représenter des modèles,
mais il ne définit pas le processus d’élaboration des modèles.⇒
UML n’est pas une méthode ou un processus
Z UML fournit une notation/syntaxe pour les diagrammes et
modèles définis pendant tout le cycle de développement
Z UML permet de définir des modèles de niveaux
différents(Analyse, Conception, Spécification
d’implémentation,etc.)
Unified Modeling Language 20

Z UML est un langage de modélisation orientée objet

Z UML n’est pas une méthode
Z UML a été adopté par toutes les méthodes orientées objet
Z UML est dans le domaine public ; c’est un standard
Z UML est un langage pour :
Visualiser : Chaque symbole graphique possède une sémantique
Spécifier : De manière précise et complète, sans ambiguïté
Construire
Une partie du code des classes peut être généré
automatiquement
Documenter : Les différents diagrammes, notes, contraintes,
exigences sont conservés dans un document
Unified Modeling Language 21

Z UML est avant tout un support de communication, qui facilite

la représentation et la compréhension de solutions objet.
Z L’aspect formel de sa notation limite les ambiguïtés et les
incompréhensions
Z Son indépendance par rapport aux langages de
programmation, aux domaines d’application et aux processus,
en font un langage universel.
Z La puissance et l’intérêt d’UML, c’est qu’il normalise la
sémantique des concepts qu’il véhicule
Unified Modeling Language 22

UML et les domaines d’utilisation

Z Systèmes d’information des entreprises
Z Les Banques et les services financiers
Z Télécommunications
Z Transport
Z Scientifique
Z Applications distribuées par le WEB
Z etc.
Unified Modeling Language 23

Points forts d’UML

Z UML est un langage formel et normalise
un gain de précision
un gage de stabilité
l’utilisation d’outils
Z UML est un support de communication performant
cadre l’analyse et facilite la compréhension de représentations
abstraites complexes.

Points faibles d’UML

Z nécessité un apprentissage et par période d’adaptation.
Z UML ne couvre pas le processus de mise en œuvre d’un projet
Quelques AGLs de conception UML 24

Libres
ArgoUML (http ://argouml.tigris.org/)
Papyrus (http ://www.papyrusuml.org)
StarUML (http ://staruml.sourceforge.net)
BOUML (http ://bouml.free.fr/)
...
Commerciaux
Rational Rose
Borland Together Enterprise Architect PowerDesigner
...
et aussi les plugins des outils de développement (en particulier
Eclipse)
Liste plus complète :
http ://en.wikipedia.org/wiki/List_of_Unified_Modeling_Language_tools
Pourquoi et comment modéliser en orienté objet 25

Z Relier le modèle au monde réel par la notion d’objet

Z Orienté objet = abstraire et décomposer le système
informatique en objets
Le monde réel est constitué d’objets physiques ou immatériels
Tracer les objets virtuels de modélisation depuis les objets du
monde réel
▶ Relier les objets (réels) du problème et les objets (virtuels)
de la solution
Favoriser les abstractions naturelles du monde réel utilisables
en modélisation
▶ Objets vus comme des « boîtes noires » : seules les
propriétés visibles de l’extérieur intéressent
▶ Objets possédant un nom, qualifiables, classables,
polymorphes, (dé)composables, interagissants avec d’autres
objets, etc.
Technologies à objets 26

UML

Modélisation
présentation stockage
Java Les objets Java

Distribution

CORBA
Avant les objets...la programmation procédurale 27
Z Programme = suite d’instructions exécutées par une machine.
Z Son exécution = ces instructions agissent sur des données.
DONNÉES

Fonction 1

Fonction 2

Fonction 3

Z Système = ensemble hiérarchique d’unités en interaction,

ayant chacune une fonction bien définie
Z Fonctions/procédures travaillent « à distance »sur les données.
Z Accent mis sur les actions. Il s’agit de répondre à la
question :Que veut on faire ?
Z Dissociation entre données et fonctions⇒ problème lorsqu’on
change les structures de données.
Avant les objets...la programmation procédurale 28

Z Appels entre les procédures

Z Elles peuvent modifier les mêmes données⇒problème lorsqu’on
veut modifier une procédure : comment avait elle été appelée ?
Grande sensibilité à l’évolution des besoins
Z Appels de procédures entremêlés
Z Fonctions interdépendantes : une simple mise à jour du logiciel
à un point donné, peut impacter en cascade une multitude
d’autres fonctions.
Z Solution : faire de telle sorte que les parties de programmes
s’occupent de données bien précises
Programmation par objets 29
Z Un programme = une société d’entités
Z Son exécution : les entités collaborent pour résoudre le
problème final en s’envoyant des messages.
Z une entité = un objet qui prend en compte sa propre gestion
DONNÉES

Fonction opérant
Sur les données

Messages
DONNÉES

DONNÉES Fonction opérant

Sur les données

Fonction opérant
Sur les données

Z La question est : De quoi parle t - on ? Approche dirigée par

les données.
Z Quelles sont les entités qui interviennent dans mon problème ?
Approche objet vs Approche fonctionnelle 30
Approche fonctionnelle
C’est la fonction qui donne la forme du système

Approche orientée objets

C’est la structure du sytème qui lui donne sa forme
Qu’apporte la modélisation objet 31

Plus grande indépendance du modèle par rapport aux

fonctionnalités demandées.
Des fonctionnalités peuvent être rajoutées ou modifiées, le
modèle objet ne change pas.
Plus proche du monde réel.
Fournir une solution au problème de la séparation
données/traitement.
Un type de données contient aussi les traitements qui lui sont
propres.
Quelques notions sur les objets 32

Objet
Un objet est une entité hermétique qui contient à la fois des
données et des traitements (les données sont appelées attributs et
les traitements, opérations ou méthodes).
Un object a une identité. Sa durée de vie est limitée. Il joue un ou
plusieurs rôles dans le système.

Z Objet = représentation du problème basée sur des entités

(concrètes ou abstraites) du monde réel dans le but de les
piloter ou de les simuler.
Z Objet
État
Comportement
Identité
Z Communication entre objets
Quelques notions sur les objets 33

Z Un objet est une entité aux frontières précises

Il est identifié (avec un nom)
Il est insécable (il doit être complet)
Z Un ensemble d’attributs caractérise son état
Son état peut agir sur l’état d’autres objets
Z Un ensemble de méthodes (d’opérations) définissent son
comportement
Z Un objet est une instance de classe (une occurrence d’un type
abstrait)
Notions fondamentales 34

Z La notion d’objet et de classe (d’objets)

Z L’encapsulation (les interfaces des objets)
Z L’héritage (les hiérarchies d’objets)
Z L’agrégation (la construction d’objets à l’aide d’autres objets)

Principes
Modularité La logique interne de l’objet est décorrélée de son
utilisation.
Encapsulation La seule façon d’influer sur l’état d’un objet est
de lui envoyer des messages.
Abstraction Les objets sont généralement classifiés suivant une
relation de généralisation.
L’état 35

Z L’État regroupe les valeurs instantanées de tous les attributs

d’un objet
Z L’État évolue au cours du temps
Z L’État d’un objet à un instant donné est la conséquence de ses
comportements passés
Z L’État conditionne son comportement futur
Le comportement 36

Z Décrit les actions et les réactions d’un objet

du point de vue externe (opérations)
Du point de vue interne (méthodes)
Z L’état et le comportement sont liés
Le comportement dépend de l’état
L’État est modifié par le comportement
Chaque opération est déclenchée par l’envoi d’un message
(Exécution d’une méthode)
L’identité 37

Z Tout objet possède une identité(OID) qui lui est propre et qui
le caractérise
OID ("Object identifier") est l’identifiant (interne) unique de
l’objet
Au niveau programme, l’OID est le plus souvent un pointeur
(au besoin persistant)
Z Identité attribuée implicitement à la création de l’objet
Z L’identité permet de distinguer tout objet de façon non
ambiguë, indépendamment de l’état
Z 2 objets différents peuvent avoir le même état
Z L’identité d’un objet est immuable tout au long de sa vie
Z Attention : identité̸= nom de la variable qui référénce l’objet
Communication entre objets 38

Z Application = société d’objets collaborant

Z Les objets travaillent en synergie afin de réaliser les fonctions
de l’application
Z Le comportement global d’une application repose sur le
comportement commun des objets qui la composent
Les Classes 39
Classe
Z La classe est une description abstraite d’un ensemble d’objets
« de même type »
Z La classe peut être vue comme la factorisation des descriptions
communes à un ensemble d’objets
Z Classes abstraites : classes sans instances

Etudiant
Nom
Datenaissance
Diplôme
ChangerNom
VerifierDateNaiss
changerDiplome
Les instances 40

Instances
Les objets appartenant à celle-ci sont les instances de cette classe.

Z L’instanciation est la création d’un objet d’une classe

Nom : Sidi Nom : Soda

Datenaissance: 12/06/90 Datenaissance: 24/01/91
Diplôme : licence info Diplôme : licence eco

ChangerNom ChangerNom
VerifierDateNaiss VerifierDateNaiss
changerDiplome changerDiplome

Z Deux instances d’une même classe peuvent avoir des attributs

avec des valeurs différentes mais partagent les mêmes
méthodes.
Les messages 41

Message
Un message équivaut à un appel d’une méthode.

Z Lorsqu’un objet reçoit un message :

si le message correspond à un traitement défini dans la classe
de l’objet , la méthode correspondante est exécutée. L’objet
répond ainsi au message.
si le message ne correspond pas, l’objet refuse le message et
signale une erreur.
Z Un objet gère lui même son comportement il peut :
soit de traiter des messages en exécutant les méthodes
correspondantes
soit de rejeter des messages en signalant des erreurs.
Les messages 42

Message simple
message dont on ne spécifie aucune caractéristique d’envoi ou
de réception particulière
Z Exemple : Publicité (papier, radio, télé, Internet, ...)

Message asynchrone
Message qui n’interrompt pas l’exécution de l’expéditeur.
Le message envoyé peut être pris en compte par le récepteur à
tout moment ou jamais traite
Z Exemple : Courrier (poste, répondeur, messagerie, ...)
Les messages 43

Message synchrone
Message qui bloque l’expéditeur jusqu’à prise en compte du
message par le destinataire
Le flot de contrôle passe de l’émetteur au récepteur
L’émetteur devient passif et le récepteur actif la prise en
compte du message
Z Conversation (orale, téléphone, chat, ...)

Message dérobant
Message qui n’interrompt pas l’exécution de l’expéditeur
Il ne déclenche une opération chez le récepteur que s’il s’est
préalablement mis en attente de ce message
Z Avertissement (alerte, autorisation, ...)
L’Encapsulation 44

Encapsulation
L’encapsulation est le fait qu’un objet renferme ses propres
attributs et ses méthodes.

Nom : Sidi
Datenaissance: 12/06/90
Diplôme : licence info

ChangerNom
VerifierDateNaiss
changerDiplome

Une classe encapsule les propriétés (attributs et méthodes) des

objets qu’elle regroupe.
L’Encapsulation 45

Encapsulation et modularité
Z La modularité est souvent laissée à la charge du développeur.
Z Dans l’approche Objet : celle-ci est prise en compte par
l’encapsulation.
Z L’unité de modularité est la classe.
Z Les classes peuvent être regroupées en packages ou en sous
systèmes (granularité supérieure).
L’Encapsulation 46
Z Consiste à masquer les détails d’implémentation d’un objet, en
définissant une interface
Z L’interface est la vue externe d’un objet, elle définit les services
accessibles (offerts) aux utilisateurs de l’objet
Z On peut modifier l’implémentation des attributs d’un objet
sans modifier son interface
Z L’encapsulation garantit l’intégrité des données, car elle
permet d’interdire l’accès direct aux attributs des objets

La seule façon d’accéder à l’état d’un objet est de lui envoyer un

message qui va déclencher l’exécution de l’une de ses méthodes.
Il n’est possible d’utiliser une voiture qu’à travers son volant,
son frein, son accélérateur, etc.
L’accès au carburateur est impossible sauf par l es méthodes
qui le font de manière cohérente (méthode accélérer de
l’accélérateur)
L’Encapsulation 47
Intérêt de l’encapsulation :
On peut protéger le contenu des classes d’une manipulation
maladroite et ou mal intentionnée.
L’abstraction 48

abstraction
L’abstraction est la caractérisation d’un objet par une partie
publique, une partie privée et une partie implémentation.

Z L’accès public :
Tout ce qui est accessible par les autres objets. Les méthodes
publiques représentent l’interface de l’objet.
Les données publiques n’imposent aucun contrôle ni sur leur
structure ni sur la nature des valeurs qu’elles peuvent recevoir.
Z L’accès privé :
Les données privées ne sont modifiables qu’à travers les
méthodes publiques qui peuvent les contrôler ainsi.
Z La partie implémentation :
Elle est définie par un ensemble de méthodes accessibles que
par les autres méthodes de la même classe.
L’abstraction 49

Données
On dit que les données ont un accès privé, i.e, seuls les
traitements de cet objet peuvent, modifier ces données
Les données peuvent être aussi publiques mais cela n’a aucun
intérêt.
Traitement
Les traitements ont un accès privé ou public.
Si les traitements sont publics, ceux-ci appartiennent à l’objet
et peuvent être appelés et modifier les données.
Si les traitements sont privés, alors seuls des traitements
publics appartenant à l’objet pourront déclencher l’exécution
des traitements privés
Les traitements privés sont appelés méthodes d’implémentation
L’abstraction 50
Exemple :
Nom='Aly' ChangerNom('Aly')
Nom='Aly'
Nom='ALY'

Diplome
Diplome
NomEnMajuscule

ChangerNom(UnNom) ChangerNom(UnNom)

Les attributs et les méthodes sont publics.
Les attributs peuvent être modifi és directement
sans passer par les méthodes.
Les attributs sont privés. Les attributs
ne peuvent être modifi és que par la
méthode publique (ici «ChangerNom»)
qui fait appel à une méthode
d’implémentation (ici «NomEnMajuscule»)
L’abstraction 51

Exemple :
La donnée diplome n’est modifiable que par la méthode
changerDiplome.
Ce concept d’abstraction engendre deux catégories d’acteurs :
Z les concepteurs des classes
ils peuvent modifier la structure interne des méthodes des
classes.
Z les utilisateurs des objets
ils peuvent utiliser les méthodes d’une classe indépendamment
de leurs structures internes.
Ils n’utilisent que les signatures des méthodes (interface de
l’objet) .
L’Héritage 52
Etudiant EtudiantSalarié

Nom
Nom Datenaissance
Datenaissance Diplôme
Diplôme LieuExercice

ChangerNom ChangerNom
VerifierDateNaiss VerifierDateNaiss
changerDiplome ChangerDiplome
ChangerLieuExercice

Z L’objet EtudiantSalarié a les propriétés (attributs et

méthodes) de l’objet Etudiant mais en plus possède d’autres
propriétés.
Z La classe EtudiantSalarié est une spécialisation/ sous classe
de la classe Etudiant
Z Les objets de la sous classe EtudiantSalarié héritent des
attributs et des méthodes de la classe Etudiant. La sous
classe EtudiantSalarié pourra, si cela est nécessaire pour ses
besoins, redéfinir une méthode héritée.
L’Héritage 53

Z Chaque sous classe peut avoir une ou plusieurs sous classes

formant ainsi une hiérarchie d’objet. On parle de classe ancêtre
(ou mère) et de classes descendant (ou fille).
Z L’héritage permet une réutilisation variable réutilisation des
objets.
Z La spécialisation et la généralisation permettent de construire
des hiérarchies de classes
Z Il existe deux techniques liées à l’héritage : les classes
abstraites et l’héritage multiple

L’héritage multiple
L’héritage multiple permet à une classe d’avoir plusieurs classes
antécédents et d’hériter ainsi de tous les attributs et méthodes de
ces ancêtres.
Les classes abstraites 54
Les classes abstraites
C’est un type de classe ayant des propriétés qui ne permettent pas
de préciser des instances. Ces classes mettent en commun un
certain nombre de propriétés à des objets.
Jeune
adresse
telephone
sexe
redigerCV
AfficherCV

Etudiant EtudiantSalarié
Nom
Nom
Datenaissance
Diplôme Datenaissance
Diplôme
VerifierNom LieuExercice
VerifierDateNaiss VerifierNom
changerDiplome VerifierDateNaiss
ChangerDiplome
ChangerLieuExercice

Z La Classe Jeune a des propriétés communes aux classes

Etudiant et EtudiantSalarie. Mais on ne peut l’instancier.
Le polymorphisme 55

Le polymorphisme
mécanisme qui permet à une sous classe de redéfinir une méthode
dont elle a hérité tout en gardant la même signature de la méthode
héritée.

=⇒ on peut avoir une méthode avec la même tête (même

signature) et des corps différents (codes différents) :
polymorphisme.
=⇒ Un même message peut ainsi déclencher des traitements
différents selon l’objet auquel il fait appel.
Le polymorphisme 56
Exemple

Vehicule

+seDeplacer()

Train Voiture Bateau

SeDéplacer( "sur des rails" ) SeDéplacer( "sur la route" ) SeDéplacer( "sur l'eau" )
Le polymorphisme 57

Intérêt du polymorphisme
Le polymorphisme permet de donner le même nom à des
traitements différents
Ou encore, permet le choix dynamique d’un traitement en
fonction de l’objet auquel il est appliqué
en effet le choix de la méthode polymorphe à exécuter est
déterminé à l’exécution du programme.
C’est pour cela qu’on dit qu’elle est dynamique, par opposé à
statique qui est déterminé lors de la compilation
Le polymorphisme augmente la généricité du code.
Covariance 58
covariance
La covariance est la propriété d’une hiérarchie de classes d’avoir des
parties isomorphes

Exemple
Les animaux peuvent être classés par rapport au critère de station
Animal

Bipède Quadrupède

Herbivore Carnivore Herbivore Carnivore

Covariance
Covariance 59
Covariance
La covariance est la propriété d’une hiérarchie de classes d’avoir des
parties isomorphes

Exemple
Les animaux peuvent être classés par rapport à leur type de
nourriture
Animal

Herbivore Carnivore

Bipède Quadrupède Bipède Quadrupède

Covariance
Covariance 60
Aucune des solutions précédentes n’est satisfaisante car la
covariance introduit de spoint de maintenance multiple dans le
modèle
solution⇒ généralisation multiple
Exemple Animal

n
io

n
nourriture

tio
at
st

ec
ot
pr
Bipède Quadrupède Herbivore Carnivore A plûmes A poils A écailles

Lion
Délégation 61
Délégation
La délégation permet de contourner le problème de la covariance en
romptant toutefois le mécanisme d’héritage entre classe et
sous-classes
Exemple

Animal
discriminant

Station Nourriture

Bipède Quadrupède Herbivore Carnivore

Quelques méthodes "classiques" 62

Constructeur
méthode qui permet de construire et d’initialiser un objet
(instanciation d’un objet)

Destructeur
méthode qui permet de détruire un objet instancié

Accesseur
méthode qui permet de récupérer la valeur d’un attribut d’un objet
(get... et is...)
Quelques méthodes "classiques" 63

Modificateur
méthode qui permet de modifier la valeur d’un attribut d’un objet
(set...)

Observateur
méthode qui permet de retrouver des informations sur l’histoire
(l’état) d’un objet

Itérateur
méthode qui permet d’appliquer à chaque partie d’un objet (par
exemple dans le cas d’un objet de type collection)une action
déterminée
Surcharge de méthode 64

Surcharge de méthode
Mécanisme permettant de déclarer plusieurs constructeurs ou
plusieurs fois une même méthode (même nom) dans une classe, à
condition que tous aient une signature différente (valeur de retour
et/ou paramètres différents)
Inconvénients de l’approche objet 65

Inconvénients de l’approche objet

moins intuitive que l’approche fonctionnelle.
L’application des concepts objets nécessite une grande
rigueur : le vocabulaire est précis (risques d’ambiguïtés,
d’incompréhensions).
Inconvénients de l’approche objet 66

Solutions
Langage pour exprimer les concepts objet pour
représenter des concepts abstraits
limiter les ambiguïtés (parler un langage commun).
faciliter l’analyse (simplifier la comparaison et l’évaluation de
solutions).
Il faut également une démarche d’analyse et de conception objet,
pour :
ne pas effectuer une analyse fonctionnelle et se contenter
d’une implémentation objet, mais penser objet dès le départ.
définir les vues qui permettent de couvrir tous les aspects d’un
système, avec des concepts objets.
Rappel Cycle de vie 67

Une démarche de développement repose sur :

Z Un formalisme,
Z Une méthode,
Z Un processus et un cycle de vie,
Z Des buts.

La qualité du processus de fabrication est garante de la qualité du

produit. Pour obtenir un logiciel de qualité, il faut en maitriser le
processus d’élaboration.

Z La vie d’un logiciel est composée de différentes étapes.

Z La succession de ces étapes forme le cycle de vie du logiciel.
Z Il faut contrôler la succession de ces différentes étapes.
Rappel Cycle de vie : 68

Les étapes du cycle de vie d’une application : :

Z Expression des besoins : Il traduit l’apport du futur système.
Z Spécifications : Précision avec schémas, modèles et
enchaînements d’écrans.
Z Analyse : Détermination des éléments du système
Z Conception : Comprend tous les choix techniques.
Z Implémentation : Génération des squelettes d’une application
Z Tests de vérification : test unitaires et finaux
Z Validation : Utilisation d’un cahier de recettes
Z Maintenance et évolution : Suivi du logiciel en production
NB : Il est important de déterminer chaque cycle de vie étape par
étape Pour bien réaliser une application
Rappel Cycle de vie : 69
Cahier des charges

Expression
Expression des
des besoins
besoins S ’accorder sur ce qui doit être fait dans le système

Analyse
Analyse Comprendre les besoins et les décrire dans le système

Conception
Conception S ’accorder sur la manière dont le système doit être construit

Implémentation
Implémentation Codage du résultat de la conception

Test
Test Le système est-il conforme au cahier des charges ?

Code exécutable

NB : Il est important de déterminer chaque cycle de vie étape par

étape Pour bien réaliser une application
Rappel Cycle de vie : 70

Les différents cycles de vie

Z le modèle linéaire
Z le modèle en " V ".
Z Modèle en spiral
Z Le cycle en cascade
Rappel Cycle de vie 71

Expression des besoins :

Permettre une meilleure compréhension du système
Comprendre et structurer les besoins du client
Une fois identifiés et structurés, ces besoins :
Définissent le contour du système à modéliser
Précisent le but à atteindre
Permettent d’identifier les fonctionnalités principales du
système
Rappel Cycle de vie 72
Spécification : Ce que le système doit être et comment il peut être
utilisé
La spécification général e consiste à identifier :(
Objectifs à atteindre
Contraintes (utilisation du matériel et outils existants)
Règles de gestion à respecter
Spécification fonctionnelles : description des fonctionnalités du
futur logiciel de manière détaillée
Spécification d ?interface décrit les interfaces du logiciel avec
le monde extérieur : homme (IHM), autres logiciel
(Middleware), machines
Spécification technique :(Etude de l’existant)
Moyens d’accès (local, distant, Internet,etc)
Temps de réponse acceptable
Plateforme (Windows, Unix,...)
Taille des informations à stocker (choix du SGBDR,..)
Rappel Cycle de vie 73
Analyse :
Z déterminer les éléments intervenant dans le système à
construire, ainsi que leur structure et leurs relations. Elle doit
décrire chaque objet selon 3 axes :
Axe fonctionnel : : savoir-faire de l’objet.
Axe statique : : structure de l’objet.
Axe dynamique : : cycle de vie de l’objet au cours de
l’application (Etats et messages de l’objet).
Z Elle sert d’interface, avec l’expression des besoins, aux
dialogues avec les clients et les utilisateurs
Z L’analyse doit servir de support pour la conception,
l’implantation et la maintenance
Z Le modèle de l’analyse décrit le problème (ce que doit faire le
système et comment il le fait tel que vu d’un point de vue
métier) sans spécifier la solution technique (avec les canevas
logiciels)
Z Analyse = LE-QUOI
Rappel Cycle de vie 74
La conception :
Elle consiste à apporter des solutions techniques aux
descriptions définies lors de l’analyse : architecture technique ;
performances et optimisation ; stratégie de programmation.
On y définit les structures et les algorithmes.
Le modèle de la conception décrit la solution (comment le
problème est résolu)
Conception = LE-COMMENT
La conception doit servir de support pour l’implantation et la
maintenance
Le plus souvent, le modèle de la conception n’est pas destiné à
être compréhensible par les utilisateurs mais par les
développeurs
Cette phase sera validée lors des tests.
Rappel Cycle de vie 75

L’implémentation : C’est la réalisation de la programmation.

Les tests de vérification
contrôles pour la qualité technique du système.
relever les éventuels défauts de conception et de
programmation
Validation
vérifier la conformité de cahier de charge qui a été rédigé avec la
collaboration de l’utilisateur
Maintenance et évolution
maintenance corrective, qui consiste à traiter les "bugs".
maintenance évolutive, qui permet au système d’intégrer de
nouveaux besoins ou des changements technologiques.
Rappel Cycle de vie : linéaire 76

Expression des Spécification Analyse

besoins

Tests de vérification Implémentation Conception

Validation Maintenance et
Evolution

Z chaque phase est traitée complètement avant que la suivante

ne soit entamée.
Z Ce qui renvoie les tests de vérification et la validation en fin du
processus de développement.
Rappel Cycle de vie : modèle en cascade 77
Plan de développement à moyen
Schéma directeur
terme des systèmes d’informations

Etude préalable Dossier de choix avec proposition

et évaluation de plusieurs solutions

Spécifications fonctionnelles
Etude détaillée complètes futur S.I. (vue utilisateur)

Spécifications techniques complètes du

Etude technique
futur S.I. (vue info.) pour la réalisation

Réalisation logicielle

Application informatique installée

Mise en service dans la nouvelle organisation

Maintenance
Rappel Cycle de vie : modèle en cascade 78

Pour applications simples, ne prend pas en compte les

applications complexes que l’on décompose en sous-sytèmes,
Une erreur détectée à la fin oblige à tout reconcevoir ⇒ très
coûteuse
Rappel Cycle de vie : Théorie vs réalité 79
L’informatique a créé beaucoup de "lois" pour décrire le décalage
entre la théorie et la réalité
Loi de Brooker : dix grammes d’abstraction valent des tonnes
de bricolage
Loi de Klipstein : les défauts n’apparaissent qu’après que le
système ait passé (avec succès) la phase d’intégration
Loi de Brook : doubler le nombre de programmeurs sur un
projet en retard ne fait que doubler le retard
Loi de Weinberg : si les architectes construisaient les maisons
comme les programmeurs écrivent les programmes, le premier
pivert venu détruirait la civilisation
Loi de Myers : on passe la moitié de son temps à refaire ce que
l’on n’a pas eu le temps de faire correctement
Rappel Cycle de vie : modèle en V 80
amélioration du modèle en cascade, prend en compte les
sous-systèmes,
Les retours en arrière en cas d’erreur restent coûteux.
Expression des Validation
besoins des besoins

Spécification Validation
fonctionnelles fonctionnelle

Conception Test du
Du système système

Processus de Conception des Test des Validation

développement composants composants montante
descendant

Implémentation
Rappel Cycle de vie : modèle en V 81
Autre représentation de cycle en V
Validation des
Etude préalable
besoins

Etude détaillée Validation fonctionnelle

Etude technique Test d'intégration

Réalisation logicielle

Le modèle en "V" permet une organisation modulaire.

A chaque étape de l’analyse et de la conception correspond
une étape de tests ou de validation.
A chaque étape fonctionnelle correspond ainsi une étape
technique.
Rappel Cycle de vie : modèle en V 82

Le processus s’accomplit en deux phases :

Une phase descendante : de spécifications et de conception.
Une phase ascendante : de tests et de validation.

Inconvénient
Comme pour le modèle linéaire, l’inconvénient est que la validation
et les tests interviennent tardivement.
Rappel Cycle de vie : modèle en spiral 83
Analyse

Spécifications
Conception

v1.0 v1.2 v1.3

Implémentation

Tests

Evaluation Evaluation 2

Prototype 1 Prototype 2

Spécifications Spécifications 2
Rappel Cycle de vie : modèle en spiral 84

le développement se fait de manière itérative.

On commence par faire un système avec peu de
fonctionnalités : le prototype1, qui va suivre les étapes
d’analyse, conception, codage, tests, ...
Puis on augmente les fonctionnalités pour obtenir le
prototype2, etc jusqu’à aboutir à un prototype complet qui
représente tout le système (ou presque ....)
Le cycle de vie Objet 85
Problèmes du cycle linéaire Risques élevés et non contrôlés :
1 Identification tardive des problèmes ;
2 Preuve tardive de bon fonctionnement ;
3 « Effet tunnel ».
=⇒ Amélioration par construction itérative du système : Dans un
projet Objet, le cycle de vie répond à 3 caractéristiques
essentielles :
1 La traçabilité entre les étapes
2 Un cycle itératif
3 Un cycle incrémental
Le cycle de vie Objet 86

La traçabilité entre les étapes :

Les concepts utilisés au cours des différentes étapes sont
quasiment identiques (Classes, Objets, Attributs, Méthodes,
Héritage, Polymorphisme, ...).
Ce qui n’est pas le cas dans les approches traditionnelles, où
l’on utilise une méthode d’analyse et de conception avec des
concepts et un langage de programmation avec d’autres
concepts.
Ceci permet de conserver le même discours lors de toutes les
étapes : « Analyse - Conception - Implémentation ».
Le cycle de vie Objet 87

Un cycle itératif : Validation

des besoins

Tests de
vérification Expression des
besoins

Spécifications
Implémentation
fonctionnelles

Conception
Analyse

A chaque itération, on refait :

Spécification ;
Conception ;
Implémentation ;
Tests.
Le cycle de vie Objet 88

Un cycle incrémental :
Lors du développement, une maquette doit être réalisée pour
valider l’ergonomie de l’application et l’enchaînement des
écrans.
Plusieurs versions peuvent être développées. Lors de chacune
d’elle, chaque fonctionnalité est amélioreée jusqu’à
optimisation rendant ainsi le système progressivement robuste.
Comment modéliser avec UML ? 89

Un cycle incrémental :
UML est un langage qui permet de représenter des
modèles,mais il ne définit pas le processus d’élaboration des
modèles
Pour modéliser une application informatique, les auteurs
d’UML préconisent d’utiliser une démarche
itérative et incrémentale
guidée par les besoins des utilisateurs du système
centrée sur l’architecture logicielle
A chaque itération de la phase d’analyse,conception et de test,
on affine, veille à la prise en compte on vérifie les besoins des
utilisateurs,
Limites 90

Le langage de modélisation ne remplacera jamais la

compétence de l’analyste-concepteur
Une bonne conception illégale en UML est préférable à une
mauvaise conception légale en UML.
Mieux vaut chercher à se perfectionner en conception qu’en
UML !
 Présentation générale d’UML
Modélisation objet élémentaire avec UML

Plan 91

1 Présentation générale d’UML

2 Modélisation objet élémentaire avec UML

David Célestin FAYE Modélisation avec UML 91/107

 Présentation générale d’UML
Modélisation objet élémentaire avec UML

Modèle d’UML 92

modèle de classe : capture la structure statique

modèle d’état : exprime le comportement dynamique des
objets
modèle de cas d’utilisation : décrit les besoins des utilisateurs
modèle d’interaction : représente les scénarios et flots de
messages
modèle de réalisation : montre les unités de travail
modèle de déploiement : précise la répartition des processus

David Célestin FAYE Modélisation avec UML 92/107

Diagrammes et vues externes 93

Les modèles sont regardés et manipulés par les utilisateurs au

moyen de vues graphiques
De nombreuses vues peuvent être construites à partir de
modèles de base. elles peuvent monter tout ou une partie des
modèles
A chaque vue correspondent un ou plusieurs diagrammes
Diagramme
Un diagramme UML est une représentation graphique, qui
s’intéresse à un aspect précis du modèle. C’est une perspective du
modèle, pas "le modèle".
Chaque type de diagramme UML possède une structure (les types
des éléments de modélisation qui le composent sont prédéfinis).
Les Diagrammes d’UML 94
Vues statiques
Les diagrammes de classes
Les diagrammes d’objets
Les diagrammes de cas d’utilisation
Les diagrammes de composants
Les diagrammes de déploiement
Vues dynamiques
Les diagrammes de séquence
Les diagrammes de collaboration
Les diagrammes d’états-transition
Les diagrammes d’activités
Les diagrammes seuls ne permettent pas de définir toutes les
contraintes de spécification requises
Utilisation du langage textuel de contraintes OCL en
complément
Les S’applique sur les éléments de la plupart des diagrammes
de collaboration
Les Diagrammes d’UML 95
Diagramme

Diagramme Diagramme
De structure comportemental

Diagramme Diagramme Diagramme Diagramme Diagramme de

de classes de packages de d'objets d'activités Cas d'utilisation

Diagramme Diagramme Diagramme de Diagramme Diagramme de

de composants de déploiement Structure composite d'interaction Transition d'état

Diagramme Diagramme de
De séquence communication

Diagramme Diagramme
Vue d'ensemble De timing
Des interactions
Les Diagrammes d’UML 96

Diagrammes d’activité
représentent le comportement d’une opération, d’un cas
d’utilisation ou un processus métier.

Diagrammes de cas d’utilisation

représentent les fonctions du système du point de vue de
l’utilisateur.
Qui interagit avec le système, et dans quel but ?

Diagrammes de classes
représentent la structure statique en terme de classes et de
relations.
Les Diagrammes d’UML 97

Diagrammes de collaboration
Représentation spatiale des objets, des liens et des interactions.

diagrammes de composants
représentent les composants physiques d’une application.

diagrammes de déploiement
représentent le déploiement des composants sur les dispositifs
matériels
Les Diagrammes d’UML 98

Diagrammes d’états-transition
représentent le comportement d’un classificateur ou d’une
opération en terme d’états.
Comment évoluent les états des objets ?

diagrammes d’objets
représentent les objets et leurs relations et correspondent à des
diagrammes de collaboration simplifiés, sans représentation des
envois de messages.

diagrammes de séquence
représentation temporelle des objets et de leurs interactions.
Comment interagissent les objets du système ?
Les Diagrammes d’UML & Phase de conception 99

Découverte des besoins

Diagramme de cas d’utilisation : décrit les fonctions du
système (point de vue de ses futurs utilisateurs)
Diagramme de séquence : représentation des dinteractions
temporelles entre objets dans la réalisation d’une IHM
Les Diagrammes d’UML & Phase de conception 100

Analyse
Diagramme de classes : structure des données
Diagramme d’objets : illustration
Diagramme collaboratif : représentation des interactions entre
objets
Diagramme d’états : représentation du comportement des
objets d’une classe en terme d’états et de transitions d’états
Diagramme d’activités : structure d’une opération en actions
Les Diagrammes d’UML & Phase de conception 101

Conception
Diagramme de séquence : représentation des temporelles entre
objets dans la réalisation d’une opeération
Diagramme de déploiement : description du déploiement des
composants sur les dispositifs matériels
Diagramme de composants : architecture des composants
physiques d’une application
Les Diagrammes d’UML & Phase de conception 102
Les trois composantes d’une modélisation 103
Modèle Fonctionnel

Que fait le système?

Aspect dynamique :
diagrammes d'interaction Aspect fonctionnel :
(séquences, collaboration), diagrammes des cas d'utilisation
d'états-transitions et d'activité

Séquencement des actions

dans le système

Modèle structurel (objet)

Aspect statique :
diagramme de classes et d'objets
Modèle temporel

Sur quoi le système agit

Les trois composantes d’une modélisation 104

1 Fonctionnel
Cahier des charges : diag. cas d’utilisation → scénarios écrits
Scénarios formels : diag. seq / comm → objets/classes
2 Statique
classes : diag. classes
3 Dynamique
dynamique chaque objet : diag. états/transitions dynamique
globale : diag. activités
Une démarche centrée sur l’architecture 105
5 façons de voir un système informatique : vue « 4+1 »de
Kruchten CONCEPTUEL PHYSIQUE

Vue
Vue logique
logique Vue
Vue
statique
statique Implémentation
Implémentation
Structuration
Structuration Composants
Composants
Diagramme
Diagramme Diagramme
Diagramme
des
des objets
objets logiciels
logiciels
classes,
classes, objets,
objets, composants
composants
collaborations,
collaborations,
séquences
séquences
Vue
Vue externe
externe
Fonctions
Fonctions du
du cas
cas
système
système d'utilisation
d'utilisation
Vue
Vue logique
logique Vue
Vue
dynamique
dynamique Déploiement
Déploiement
Dynamique
Dynamique Architecture
Architecture
Diagrammes
Diagrammes Diagramme
Diagramme
des
des objets
objets physique
physique
états
états déploiement
déploiement
activités,
activités,

Vision de l’extérieur du système, le problème :

Vue cas d’utilisation = ce que fait le système, les
fonctionnalités
Vue processus = ce que fait le système, les règles de gestion
Diagrammes communs à l’analyse et à la conception 106

Vue logique
Aspects statiques = structure du problème et de la solution
→ Diagrammes de classes et d’objets
Aspects dynamiques = comportement des éléments de la
structure
→ Diagrammes de séquence, de communications et de
machine à états
Une démarche d’application de UML 107

Étape 1 : élaboration d’un diagramme de contexte du système

à étudier
Étape 2 : identification et représentation des cas d’utilisation
Étape 3 : description et représentation des scénarios
Étape 4 : identification des objets et classes
Étape 5 : élaboration du diagramme de classe
Étape 6 : élaboration du diagramme état-transition
Étape 7 : consolidation et vérification des modèles