Université Saad Dahleb de Blida

Faculté des Sciences

Département d’Informatique
Licence ISIL
Semestre 5 (3ème année)

Présenté par: Mme CHERIGUENE

Année Universitaire : 2019/2020

 Analyse et conception Orienté Objet:
Introduction
Décomposer le titre et faire de la terminologie
(littérature ) :
Analyse
Conception
Orienté Objet

2
 Analyse et conception Orienté Objet:
Introduction
• Réponse :
Analyse : analyser une problématique d’un
client.
Conception : concevoir une solution à la
problématique.
Orientée Objet : suivre une méthodologie
ou concept OO (apparemment efficace ?).

3
 Analyse et conception Orienté Objet:
Introduction
• Résultat :
je commence à me situer.
Quelqu’un dois me fournir ses besoins.
Je dois les analyser
Ensuite, concevoir une solution et la
communiquer
La solution doit se basée sur un modèle ou
méthode (choix Orienté Objet?)
4
 Analyse et conception Orienté Objet:
Introduction
• Chronologie:
• Comprendre les fondamentaux OO.
• Besoins client analyse et reformulation
valider et confirmer proposition d’une
solution après avoir décomposer la
problématique.
• Concevoir une solution basé sur le modèle
OO.

5
 Méthodes d'analyse et de conception

• Objectif : fournir des notations standards et des

conseils pratiques qui permettent d'aboutir à des
conceptions « raisonnables »
 Mais on fera toujours appel à la créativité du
concepteur.

6
 Méthodes d'analyse et de conception:
Classification des méthodes
• la distinction composition/décomposition :
 les méthodes ascendantes qui consistent à construire un logiciel
par composition à partir de modules existants.
 les méthodes descendantes qui décomposent récursivement le
un système jusqu'à arriver à des modules programmables «
simplement ».
• la distinction fonctionnelle /orientée objet:
 Les stratégies fonctionnelles (dirigées par le traitement)
 Exemple: SA, SADT, RAPID/USE, JSD, MASCOT, Automates;
RDP, MERISE…
 Les stratégies orientées objet.
 Exemple: OMT, UML

7
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle
• La forme la plus immédiate pour décrire un travail à effectuer est de lister
les actions à réaliser.
• On découpe une tâche complexe à effectuer en une hiérarchie d’actions à
réaliser de plus en plus simples, petites et précises (Pour décrire, on utilise
le verbe) : Décomposer la fonction globale jusqu’à obtenir des fonctions
simples à appréhender et donc à programmer.

8
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle: Exemple

9
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle: Exemple

10
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle
• Dans ce cadre de travail :
 L’analyse est une découpe fonctionnelle descendante des
fonctionnalités à pourvoir.
 La conception est une découpe du logiciel en une
hiérarchie descendante d’actions permettant de satisfaire
les fonctionnalités à pourvoir.
 L’implémentation est une programmation procédurale.

• Dans une programmation procédurale issue d’une découpe

fonctionnelle descendante, les données et les fonctions
travaillant sur ces données sont dispersées dans des
modules différents.
11
Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle

12
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle
• Dispersion données/fonctions : Lorsque le logiciel évolue, il
faut faire évoluer les structures de données et les fonctions
en parallèle (probablement dans des modules
différents). Maintenir cette cohérence est laborieuse parce
que données et fonctions sont dispersées.
La dispersion données/fonctions nuit à l’extensibilité !

13
 Méthodes d'analyse et de conception:
Conception par décomposition fonctionnelle

Comment évaluer la découpe fonctionnelle descendante et

la programmation procédurale en termes de couplage et
cohésion ?

Séparer données et fonctions sur ces données entraine :

Un fort couplage par les données,
Perte de cohésion (par dispersion).
Le code est donc peu extensible et peu réutilisable !

 Les questions qu’on peut poser dans ce cas :

1. Pourquoi privilégier les procédures sur les données
(Que veut-on faire ?) ?
2. Pourquoi ne pas considérer que les programmes sont avant tout
des ensembles objets informatiques caractérisé par les opérations
qu’ils connaissent?
14
 Méthodes d'analyse et de conception:
Fonctionnel versus Objet

Les méthodes orientés objets sont nés pour répondre à ces

questions.
15
 Méthodes d'analyse et de conception:
Méthodes orientées objet (OO)
 L'analyse orientée objet permet d'examiner un
problème en mettant en évidence les classes et les
objets correspondants, sous forme de composants
indépendants qui interagissent selon des modalités
bien définies.
 Le choix d'une méthode orientée objet n'est pas
simple car celles-ci sont nombreuses et toutes n'ont
pas été testées sur des applications suffisamment
importantes pour pouvoir être évaluées,

16
 Méthodes d'analyse et de conception:
Méthodes orientées objet (OO)
 Dans la plupart de ces méthodes, l'étude d'un problème est
réalisée suivant trois aspects:
 un aspect statique ou descriptif , où on identifie les
propriétés des objets et leurs liaisons avec les autres objets
 un aspect dynamique , où on précise le comportement des
objets, les différents états par lesquels ils passent et les
événements qui déclenchent ces changements d'états. (On
parle souvent de cycle de vie d'un objet).
 un aspect fonctionnel , dans lequel on précise les fonctions
réalisées par les objets par l'intermédiaire des méthodes.

17
 Avantages de l'Orienté Objet

 L'intérêt principal de l'OO réside dans le fait que l'on ne décrit

plus par le code des actions à réaliser de façon linéaire mais
par des ensembles cohérents appelés objets.
 Facilité d'organisation, réutilisation, méthode plus intuitive,
possibilité d'héritage, facilité de correction,projets plus faciles
à gérer.
 L'OO est facilement concevable car il décrit des entités
comme il en existe dans le monde réel.
 Les modèles à objets ont été créés pour modéliser le monde
réel. "Dans un modèle à objets, toute entité du monde réel
est un objet, et réciproquement, tout objet représente une
entité du monde réel".
18
 Rappel: Les objets

Objet:
Identité + Etat + Comportement

 Une identité deux objets différents ont des identités

différentes on peut désigner l’objet (y faire référence)
 Un état (attributs) ensemble de propriétés/caractéristiques
définies par des valeurs permet de le personnaliser/distinguer
des autres objets peut évoluer dans le temps
 Un comportement (méthodes) ensemble des traitements que
peut accomplir un objet (ou que l’on peut lui faire accomplir)

19
 Rappel: Classes et instances

 Les objets possédant la même structure de données

(attributs) et le même comportement (opérations) sont les
représentants d’une même classe.
 Une classe est une abstraction qui décrit les propriétés
pertinentes pour une application.
 Données et opérations traitant les données ne sont pas
séparées, mais réunies au sein d’un même module. Cohésion!
 Chaque objet est une instance d’une classe.

20
Rappel: Classes et instances

21
Rappel: Classes et instances

22
 Limites de l'Orienté Objet

 L'approche objet est moins intuitive que l'approche

fonctionnelle !
 Quels moyens utiliser pour faciliter l'analyse objet ?
 Quels critères identifient une conception objet pertinente ?
 Comment comparer deux solutions de découpe objet d'un
système ?

• L'application des concepts objets nécessite une

grande rigueur !
 Le vocabulaire est précis (risques d'ambiguïtés d'incompréhensions).
 Comment décrire la structure objet d'un système de manière
pertinente ?

23
 Solution

• il faut disposer d'un outil

 qui donne une dimension méthodologique à
l'approche objet
 qui permet de mieux maîtriser sa richesse :

UML (Unified Modeling Language ) se traduit en

français par langage unifié pour la modélisation

Fondations issues de diverses méthodes OO :

 Rumbaugh (OMT)
 Booch (OOD)
 Jacobson (OOSE) 24
UML: Principales étapes de la définition

25
 Objectifs du langages UML

 Langage visuel de modélisation

 Exploitable par des méthodes A/C différentes
 Adapté à toutes les phases du développement
 Compatible avec toutes les techniques de réalisation
 Mécanismes d’extension et de spécialisation en vue
d’étendre les concepts de base
 Indépendant des langages de programmation
 Base formelle pour la compréhension du langage
 Encourage l’utilisation d’outils OO
 Supporte les concepts de développement de haut niveaux :
patterns, composants et frameworks
26
 Diagrammes UML
 Différentes vues pour représenter un système :

 En UML : 9 principaux diagrammes (en réalité : 12)

 5 Diagrammes structurels (vue statique)

 Cas d’utilisation
 Classes
 Objets
 Composants
 Déploiement

 4 diagrammes comportementaux (vue dynamique)

 Séquence
 Activités
 Etats-Transitions
 Collaboration
27
Diagrammes UML

28
 Relation entre diagrammes et étapes du
processus
• Découverte des besoins :
 Diagramme de cas d’utilisation : décrit les fonctions du système selon
le point de vue ses futurs utilisateurs (Jacobson)
 Diagramme de séquence : représentation des interactions
temporelles entre objets dans la réalisation d’une interface Homme-
Système

• Analyse :
 Diagramme de classes : structure des données du système définies
comme un ensemble de relations entre classes
 Diagramme d’objets : illustration des objets et de leur relations
 Diagramme de collaboration : représentation des interactions entre
objets
 Diagramme d’états-transitions : 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
29
 Relation entre diagrammes et étapes du
processus
• Conception:
 Diagramme de séquences: représentation des interactions
 Diagramme de déploiement: description du déploiement
des composants sur les dispositifs matériels/physiques
d’une application

30
 Références
• Xavier blanc : bordeaux :
https://www.youtube.com/watch?v=1Yd5M9BEs
h4
• Jean-Bernard Crampes, Éditions Ellipses, coll. «
Technosup », 2003
• Grady Booch. "Object-oriented Analysis and
Design with Applications, 3rd edition.
• http://www.awprofessional.com/title/020189551
X Addison-Wesley 2007.
• HTTP://LAURENT-AUDIBERT.DEVELOPPEZ.COM/COURS-
UML/
31
 Références
• N. Lopez, J. Migueis et E. Pichon. (1997). Intégrer UML dans vos
projets. Eyrolles.
• M. Bouzeghoub, G. Gardarin, P. Valduriez (1997) Les objets.
Eyrolles.
• N. Kettani et al. (1999). De Merise à UML. Eyrolles
• I. Jacobson (1993) Le génie logiciel orienté objet : une approche
fondée sur les cas d’utilisation. ACM Press, Addison-Weslry
• P-A Muller et N. Gaertner (2000) Modélisation objet avec UML.
Eyrolles.
• M. Lai (2000). UML la notation unifiée de modélisation objet.
Dunod Informatiques.

• Cours sur le web : http://uml.free.fr

• Site : www.uml.org (OMG)

32