École Supérieure d’Informatique

Analyse et conception orientée

objet

BELEM Mahamadou

1
 Objectifs du cours

 Objectifs du cours

 Introduire le concept orienté objet

 Comprendre le principe de l’analyse et
de la conception orientée objet
 Comprendre la place du langage UML
pour l’analyse et la conception d’une
solution informatique

2
 Analyse et conception orientée
objet
 Analyse orientée objet:
 Elle vise à clarifier et à documenter les besoins d’un
système informatique
 Le terme analyse est vaste et nécessite des
précisions. On parle ainsi d’analyse des besoins
(investigation des besoins) et d’analyse orientée
objet (investigation des objets du domaines).
 Met l’accent plus sur la compréhension du problème
et l’identification des besoins plutôt que la recherche
d’une solution
 L’objectif principal est d’identifier et documenter les
concepts liés aux problèmes

3
 Analyse et conception orientée
objet
 Exemple
• Système d’information d’une université: Etudiant, Enseignant,
Cours, Classe, Devoir, etc.
• Système d’information d’une bibliothèque: Abonné, Livre, Auteur,
Emprunt, Prêt, etc.
• Système d’information d’une banque: Client, Compte, Transaction

4
Analyse et conception orientée
objet
 Conception orientée objet:
 est centrée sur la définition des objet logiciels et sur
la façon dont ils collaborent pour satisfaire les
besoins.

 Met l'accent sur la définition solution conceptuelle

qui remplit les exigences plutôt sa mise en œuvre.

 Permet de s’accorder sur la manière dont le système

doit être construit.

 Le modèle d’analyse est raffiné et adapté à

l’environnement

5
Analyse et conception orientée
objet
 Conception orientée objet:
 définit les objets métiers, leur responsabilité et
comment ils collaborent pour réaliser les exigences.

 Met l'accent sur la définition solution conceptuelle

qui remplit les exigences plutôt sa mise en œuvre

 Permet de s’accorder sur la manière dont le système

doit être construit

 Le modèle d’analyse est raffiné et adapté à

l’environnement

6
 Analyse et conception orientée
objet

Analyse Conception
Basée sur la compréhension du Basé sur la recherche d’une
système solution logicielle
La structure du système La structure du système
Un modèle réduit basé sur les Un modèle large basé sur la
concepts du domaine d’étude représentation dynamique et
statique du système

7
Analyse et conception orientée
objet
 Les étapes et les artefacts

8
Analyse et conception orientée
objet
 Modèle de cas d’utilisation
 C’est l’ensemble des diagrammes des
cas d’utilisation, d’interaction
système qui décrivent le
comportement attendu du future
système

9
Analyse et conception orientée
objet
 Modèle de domaine
 C’est une représentation visuelle des
concepts du domaine, similaire à un
modèle statique des entités du
domaine.

 Il peut inspirer la conception d’un

certain nombre d’objets logiciels et il
servira de source pour plusieurs
artéfacts abordés dans les études de
cas. 10
Analyse et conception orientée
objet
 Modèle de conception
 C’est l’ensemble de diagrammes qui
décrivent la conception logique. Il
comprend les diagrammes de classes
logicielles, les diagrammes
d’interaction entre objets, les
diagrammes de packages, etc.

11
Analyse et conception orientée
objet
 Document d’architecture du
logiciel
 Aide pédagogique qui résume les
principaux problèmes d’architecture
et la façon dont ils sont résolus dans
la conception. C’est un condensé de
tous les principes importants et de
leur raison d’être dans le système.

12
Analyse et conception orientée
objet
 Modèle de données
 Il comprend le schéma de base de
données, ainsi que les stratégies de
correspondance entre les
représentations objet et non objet

13
Le concept orienté objet
 S’appuie sur la recherche des objets du monde réel
décrits à travers

 leurs caractéristiques (attributs),

 leurs comportements (méthodes)

 leurs relations avec les autres objets du système

14
Qu’attendre de l’approche objet ?
 Modularité
 Réduction de la complexité des systèmes
 Réduction du coût de développement
 Réduction du coût de maintenance

 La réutilisabilité
 Réutilisation des composants

 L’évolutivité
 Apport de nouveaux éléments sans une remise en cause
des éléments déjà existants. Exemple: L’héritage

 L’hétérogénéité
 Intégration des systèmes d’information existants
 La gestion de l’interopérabilité. Exemple: La technologie
Corba

15
UML et l’approche
orientée objet

16
 Modélisation avec UML
 UML un langage mais pas une
méthodologie
 UML propose une démarche
 Itérative et incrémentale
 Guidée par les besoins des utilisateurs
 Centrée sur l’architecture
Logique Implantation
Scénarios
Processus Déploiement
Les 4+1 vue de UML

17
Historique
 Plus de 50 méthodes objet durant la période 90-
95: Booch, Classe-Relation, OMT, OOA, OOD,
OOM,...
 Seules 3 méthodes ont véritablement émergé:
 La méthode OMT de James Rumbaugh : OMT 1990-1991

– "Object Modeling Techniques"

– General Electric
 La méthode BOOCH'93 de Grady Booch : OOD, BOOCH'93
(Société RATIONAL)
– 1987 pour ADA,
– 1990 générale
 La méthode OOSE d’Ivar Jacobson : Objectory 1992,
– Ericsson,
– suite de OOSE "Object Oriented Software Engineering"
 Regroupement de BOOCH-OMT puis Objectory
18
Historique
 Accepté par l’OMG – 1997
 Un langage commun unique :
 Un meta-modèle
 Un langage moins ambiguë
 Une notation graphique simple,
– Même compréhensible par des non-informaticiens
– Permet la communication entre les acteurs
 Indépendance du domaine d’application et des
langages d’implémentation

 Devenu LA référence en terme de

modélisation objet

19
 Les diagrammes UML
 Les modèles statiques
 diagramme de classes
 diagramme d’objets
 diagramme de composants
 diagramme de déploiement
 diagramme de paquetage
 diagramme de structure composite
 Les modèles dynamiques
 diagramme des cas d’utilisation
 Le diagramme d’états-transition
 Le diagramme d’activités
 Les modèles d’interaction
• Le diagramme de séquence
• Diagramme de communication
• Diagramme global d’interaction
• Diagramme de temps

20
Utilisation de UML

 UML en mode esquisse

 Diagrammes informels et incomplets (souvent tracés à la main)
créées pour expliciter des parties délicates de l’espace du
problème ou de la solution en exploitant la puissance des langages
graphies
 UML en mode plan. Diagramme de conception
relativement détaillés utiles
 La pro-ingénierie (génération de code à partir des diagrammes)
 La rétro-ingénierie, qui permet de visualiser et de mieux
comprendre le code existant en générant des diagrammes UML
 UML comme langage de programmation

21
Trois perspectives pour UML

 Point de vue conceptuel. Les diagrammes sont

interprétés comme décrivant des entités du monde réel
ou du domaine d’intérêt
 Point de vue des spécifications (logicielles). Les
diagrammes (utilisant la même notation que dans la
perspective conceptuelle) décrivent des abstractions ou
des composants logiciels avec des spécifications et des
interfaces, sans préciser une implémentation
particulière
 Point de vue de l’implémentation (logicielle). Les
diagrammes décrivent des implémentations logicielles
dans une technologie particulières (java, C#, etc.)

22
Exercice
 Définir la notion d’analyse
 Définir la notion de conception
 Dire la différence entre l’analyse et la
conception orientée objet
 UML est-il un langage ou une
méthodologie
 Donner les étapes et les artéfacts de
l’analyse et de la conception orientée
objet

23
Bibliographie
 http://fr.wikipedia.org/wiki/
Unified_Modeling_Language#Les_diagrammes?
 http://laurent-piechocki.developpez.com/uml/tutoriel/lp/
cours/i-p7.html
 Pierre Bommel, Cours UML,
 Pascal Roques, UML 2 par la pratique
 Eric Cariou, OCL:Object Constraint Language, 2003
 Michel Tollenaeré, Management des Systèmes
d’Information (MSI)
 Laurent Henocque, UML2: Les diagrammes
 Craig Larman, (2007) UML2 et les design patterns, Analyse
et conception orientées objet et développement itératif.

 Pascal Roques, UML 2 par la pratique

24