Chap1 Introduction ACOO

Ecole Nationale des Sciences de l’Informatique
ANALYSE ET II2-ENSI
CONCEPTION
ORIENTÉES OBJET
Objectifs de module ACOO-II2
Apprendre la modélisation objet
Cours « GL-ACOO » ENSI

Comprendre les différents diagrammes UML2.5
Connaître et utiliser les patrons de conception
2
PLAN DU MODULE ACOO-II2
Introduction à UML
Diagrammes d’analyse

Diagrammes de conception architecturale
Diagrammes de conception détaillée
Patrons de conception
Etude de cas récapitulatif
3
RÉFÉRENCES ACOO-II2
 Fowler Martin, UML Distilled: A Brief Guide to the Standard

Object Modeling Language (3rd ed. ed.). Addison-
Wesley. ISBN 0-321-19368-7.
 Hugues BERSINI, "L'orienté objet Cours et exercices en

UML2 avec Phyton, Java, C# et C++", EYROLLES,
2004, Bibliothèque ENSI ( A-824.3).
 Craig Larman, UML 2 et les Design Patterns - (3 ème édition)
(ISBN 2-7440-7090-4)
 Internet
 Cours sur le web : http://uml.free.fr
 Site : www.uml.org (OMG)
4
École Nationale des Sciences de l’Informatique
CHAPITRE 1
II2-ENSI
PLAN DU COURS ACOO-II2
1. Sensibilisation à la modélisation objet

 Importance de la modélisation
 La notion d’objet
 Principes de la modélisation objet


Avantages du modèle objet
2. UML
1. Définition
2. Historique
3. Objectifs d’UML
4. Les outils d’UML
5. Les préoccupations en UML
6. Diagrammes d’UML 2.5
6
Chapitre 1 Sensibilisation à la
Introduction à UML modélisation
La mise en place d’un système

7
La mise en place d’un système

8
Importance de la modélisation
 Modèle :
 Abstraction de la réalité
 Description de tout ou partie d’un système dans un
langage bien défini.

 Vue subjective mais pertinente de la réalité
 Le modèle est important pour :
 Comprendre et maîtriser la complexité d’un problème
 Supporter un travail coopératif d'ingénierie
 Prévoir et planifier la réalisation d'un développement
 Réutilisation et réutilisabilité
 Et même générer du code
Modèle = représentation simplifiée d’une réalité …

Réalité
Modèle
10
Autant de modèles que de buts, de lecteurs, de notations, de

concepteur (une vue subjective), etc.
.

Modèle pour touriste
Modèle pour technicien
11
représente

Système
réel
Plusieurs
modèles
possibles
Approches
 Les systèmes peuvent être décomposés selon
 ce qu’ils font (approche fonctionnelle)
 ce qu’ils sont (approche objet)

13
Exemple
Approche fontionnelle : Qu’est ce que le système

doit faire?
 Raisonnement en terme de fonctions du système

 Séparation des données et des traitements
 Diffusion des responsabilités (intégrité des données
non garantie) Héros Struct Heros{
 Exemple: Nom char*;

Int taille;
Marcher Courir Sauter Tomber
….};
……
Courir
Application « Jeu » (heros……)
…… 14
De l’approche procédura le vers

l’approche objet
 Exemples: SADT, SASD qui regroupe Structured Analysis

(SA) et Structured Design (SD) sont des exemples bien
connus de méthodes fonctionnelles d ’analyse et conception.

Ces méthodes datent des années 70.
15

l’approche objet
Approche fonctionnelle: Bilan
 Réutilisation de fonctions

 Les fonctions sont souvent interdépendantes :
une simple mise à jour du logiciel à un point donné, peut
impacter en cascade une multitude d'autres fonctions.
 Intégrité des données non garantie: diffusion des
responsabilités
16

l’approche objet
Approche orientée objet: Sur quoi porte le système?

 Raisonnement en termes d’objets manipulés par le système
 Regroupement des données et des traitements
 Localisation des responsabilités (encapsulation)

 Diminution de l’écart entre le monde réel et sa représentation
informatique (approche naturelle)
Héros class Heros{

Nom
Taille Nom char*;
….
Sauter
Int taille;
Marcher ……
Application « Jeu »
Courir
Heros hero1= new Heros() Courir
Hero1.courir(…) Tomber (heros……)
17
….};
C’est quoi un objet ?

 OBJET
 Une abstraction informatique d'une entité du monde
réel
 Un ensemble d'attributs caractérise l'état de l'objet.

 Un ensemble d'opérations (méthodes) en définissent le
comportement.
 Un objet est une instance de classe (une occurrence d'un type
abstrait).
 Une classe est un type de données abstrait, caractérisé

par des propriétés (attributs et méthodes) communes à
des objets et permettant de créer des objets possédant ces
propriétés.
18
Caractéristiques du modèle objet
 La modularité : les objets offrent des modules

compacts regroupant un ensemble de données sur
lesquelles on peut appliquer un ensemble

d’opérations ce qui facilite la mise au point et la
maintenance des projets.
 L’abstraction : c'est la capacité d'ignorer les détails

d'un élément pour en avoir une vision globale.
 La réutilisabilité : les objets offrent des modules

qu’il est possible d’utiliser dans différentes
applications.
19
 L’approche objet gère plus efficacement la

complexité

 Modèles basés sur le monde réel  stabilité
 Structure indépendante des fonctions 
évolutivité
 Approche modulaire  maintenabilité ,
réutilisabilité
20
PLAN DU COURS ACOO-II2
1. Sensibilisation à la modélisation objet

 Importance de la modélisation
 La notion d’objet
 Principes de la modélisation objet


2. UML
1. Définition
2. Historique
3. Objectifs d’UML
4. Les outils d’UML
5. Les préoccupations en UML
6. Diagrammes d’UML 2.5
21
Chapitre 1 Section 2
Introduction à UML UML
Définition
UML = Unified Modeling Language
 Un langage de modélisation des applications

construites à l’aide d’objets, indépendamment de la
méthode utilisée
 C’est :
 Une notation
 Une description complète, évolutive, publique
 Un standard
 Ce n’est pas une méthode

22
Genèse d’UML
 Au départ, plus de 50 méthodes !!

 MAIS:
 Divers concepts sont utilisés
 Divers démarches suivies

 Divers notations graphiques supportées
 Divers sémantiques accordées au mêmes concepts
 Unification progressive de plusieurs méthodes, de

remarques des utilisateurs, des partenaires
 Standardisation : en 1997 par l’OMG (Object Management

group) ; groupe créé à l’initiative de grandes sociétés
informatiques américaines pour normaliser les systèmes à
objets ;
Genèse d’UML
Un besoin d’Unification: Unified

Pour la modélisation: Modelling
Sous forme de langage: Language

OMT Genèse d’UML

Booch
OOSE
Fusion
Classe-Relation

ROOM
HOOD
Normalisation en 1997
etc... UML 2.5
Rational OMG Mars 2015
Fin 1990 UML 1.4
1995 Fin 2001
OMT UML 1.3
(Rumbaugh et al.) Unified Method
0.8 1996 Juin 1999
Booch UML 1.1
UML 0.9 Nov. 1997
OOSE
(Jacobson et al.)
Catalysis ROOM etc. 25

Genèse d’UML
 Le standard pour l’analyse et la conception OO
 N’est pas une méthode mais un langage : définit des diagrammes et

des notations mais n ’impose pas de méthode.

 Convient pour toutes les démarches et langages de programmation
objet.
 Utilise la notation graphique :

 limite les ambiguïtés
 Support de communication
 Supporte les activités de développement d ’un logiciel: Analyse,

conception, implémentation et test
 UML évolue mais reste stable

 Un noyau stable: Concepts de base
 Des mécanismes d’extension des concepts de base
26
Le s o u t ils U ML
Fonctionnalités courantes
 Edition graphiques des diagrammes UML
 Génération de code C++, Java,...
 Rétro-conception à partir de code existant

…
Quelques exemples
 Rational Rose de Rational Software (www.rational.com)
 StarUML, ArgoUML, Papyrus,
 Software Through Pictures d’AONIX (www.ide.com)
 Cayenne Class Designer de Cayenne Software
(www.cayennesoft.com)
 AMC Designer, Poseidon, Visual Design, Spark
(www.cayennesoft.com)
…
27
Objectifs d’UML
• Représenter des systèmes entiers (plusieurs vues)

• Prendre en compte les facteurs d’échelle
• Créer un langage de modélisation

Utilisable par les hommes & machines
 Compatible avec toutes les techniques de
réalisation
 Adapté à toutes les phases du développement
Sans rejeter les méthodes existantes
Indépendant des langages de programmation
Objectifs d’UML
• Visualiser
• Chaque symbole graphique a une sémantique
• Spécifier

• d’une manière complète et la moins ambiguë
possible
• Construire / Modéliser / Méta-Modéliser
• les entités, les classes, les relations, …
• Documenter
• les diagrammes, notes, contraintes, exigences
 Générer du code
Le s pré o ccu p ation s e n UML
 UML permet de représenter les systèmes

informatiques selon plusieurs préoccupations
partielles et complémentaires.

 Il n’existe pas une seule manière de voir un système
informatique (le point de vue de l’analyste, du
concepteur, d’architecte…).
 Il n’existe pas un seul axe d’intérêt pour représenter
un système informatique (sa vue fonctionnelle,
structurelle et comportementale).
30
 Les préoccupations (facettes) de modélisation

d’UML peuvent être catégorisées selon plusieurs
classifications :

 Classification selon le point de vue de l’acteur qui
va modéliser (analyste, architecte, concepteur,
développeur..)
 Classification selon l’axe de modélisation
(fonctionnel, structurel ou comportemental)
 Classification selon le modèle des 4+1 vues
 Tous les diagrammes d’UML vont être catégorisés

selon ces classifications
31

Classification selon le point de vue

Algorithme du monde réel Algorithme du logiciel
(scénario) (scénario)
Objets du
monde Objets du Objets du
réel logiciel langage
De quoi parle-t-on ? Comment ‘logique’ ? Comment ‘physique’ ?

Analyse Conception Code
Modèle conceptuel Modèle logique Modèle physique 32
Structurel (ce que le système EST)
Classification selon l’axe de modélisation

du système
Fonctionnel
Comportemental
(ce que le système
(comment le
FAIT)
système EVOLUE)
33
Classification selon le modèle des 4+1 vues
Comment découper
Quelles sont les

le système pour Vue de
Vue logique briques logicielles
le développer développement nécessaires?
Vue des cas

d’utilisation
Comment découper Comment déploie-t-on
Vue de
le système en des Vue physique l’application?
Processus, les synchroniser Processus Quels sont les contraintes?
34
Le modèle des 4+1 vues a pour objectif de :

 Représenter un système sous différents angles
 Vérifier la cohérence entre les différentes vues

 Valider les quatre vues par la vue centrale
 permettre la gestion d'un projet de développement du
début à la fin.
 Bien couvrir tous les aspects d'un cycle de
développement.
35
1. La vue logique
 découpage des services à rendre aux clients hors de tout contexte
d’exécution
2. La vue de réalisation ou d’implémentation

 découpage prenant en compte le contexte d’exécution et l’environnement
de développement (l’organisation du code de l’application)
3. La vue des processus ou procédurale
 Représentation du comportement et décomposition en flots d’exécution et
synchronisation entre ces flots
4. La vue physique, de déploiement ou de distribution
 Description des ressources matérielles et la distribution de la partie
logicielle sur la partie matérielle
5. La vue des cas d’utilisation
 Descriptions des fonctionnalités du systèmes (les cas d’utilisation)
 La colle et le coordinateur entre les autres vues
36
Chaque vue ou facette utilise ses propres

notations et modèles. Il en résulte donc
 une simplicité de modélisation (chaque vue isolant

une seule facette du problème) et
 un meilleur travail en groupe (chaque spécialiste
d’une facette d’un système concevant son modèle en
utilisant des solutions adaptées).
L’utilisation de toutes les vues n’est pas

obligatoire (ex. pour un système centralisé, on
utilise pas la vue physique)
37
Les diagrammes d’UML 2.5

Avec UML 2.5 (2015), on a 14
Diagrammes
38
1) Diagramme de cas d’utilisation: montre les
fonctionnalités à rendre aux acteurs du système.
2) Diagramme de classes: montre les briques statiques
(classes, associations, opérations,…)
3) Diagramme d’objets: montre les instances des éléments
structurels et leurs liens.
4) Diagramme de packages: montre l’organisation logique
du modèle et les relations entre packages.

5) Diagramme de séquence: montre la séquence verticale
des messages passés entre éléments au sein d’une
interaction.
6) Diagramme de communication: montre la
communication entre éléments dans le plan au sein
d’une interaction.
7) Diagramme d’états: montre les différents états et
transitions possibles des objets d’une classe à
l’exécution. 39
8) Diagramme d’activité: montre l’enchainement des
actions au sein d’une activité.
9) Diagramme de vue globale d’interaction: combine les
diagramme d’activité et de séquence pour organiser des
fragments d’interaction avec des décisions et des flots.
10)Diagramme de temps: combine les diagrammes d’états
et de séquence pour montrer l’évolution de l’état d’une
ligne de vie au cours du temps et les messages qui

modifient cet état.
11)Diagramme de structure composite: montre
l’organisation interne d’un élément structurel complexe.
12)Diagramme de composants: montre les composants du
système avec leurs interfaces fournies et requises.
13)Diagramme de déploiement: montre le déploiement
physique des artéfacts sur les ressources matérielles.
14)Diagramme de profil: définit un profil spécifique à un
domaine. (SysML est un exemple de profil UML2). 40
Exemple d’utilisation des

1 Les diagrammes d’UML 2.5
Capture des
diagrammes d’UML dans un
2
exigences Analyse processus de développement
Modèle de déploiement
Modèle de conception

3
Consolidation
des exigences 4
Modèle d’analyse
Conception
5
Réalisation
Modèle d’exigences
6
Tests
Modèle de tests
Modèle de réalisation
41
Exemple d’utilisation des

Les diagrammes d’UML 2.5 diagrammes d’UML dans un
processus de développement

42

Chap1 Introduction ACOO

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Chap1 Introduction ACOO

Transféré par

Droits d'auteur :

Formats disponibles

Ecole Nationale des Sciences de l’Informatique

Apprendre la modélisation objet

Cours « GL-ACOO » ENSI

Connaître et utiliser les patrons de conception

Cours « GL-ACOO » ENSI

Diagrammes de conception détaillée

Etude de cas récapitulatif

 Fowler Martin, UML Distilled: A Brief Guide to the Standard

Cours « GL-ACOO » ENSI

1. Sensibilisation à la modélisation objet

Cours « GL-ACOO » ENSI

La mise en place d’un système

Cours « GL-ACOO » ENSI

La mise en place d’un système

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

Modèle = représentation simplifiée d’une réalité …

Cours « GL-ACOO » ENSI

Autant de modèles que de buts, de lecteurs, de notations, de

Cours « GL-ACOO » ENSI

Modèle pour technicien

Cours « GL-ACOO » ENSI

Cours « GL-ACOO » ENSI

Approche fontionnelle : Qu’est ce que le système

Cours « GL-ACOO » ENSI

 Exemple: Nom char*;

De l’approche procédura le vers

 Exemples: SADT, SASD qui regroupe Structured Analysis

Cours « GL-ACOO » ENSI

De l’approche procédura le vers

Approche fonctionnelle: Bilan

Cours « GL-ACOO » ENSI

De l’approche procédura le vers

Approche orientée objet: Sur quoi porte le système?

Cours « GL-ACOO » ENSI

Héros class Heros{

C’est quoi un objet ?

Cours « GL-ACOO » ENSI

 Une classe est un type de données abstrait, caractérisé

Caractéristiques du modèle objet

 La modularité : les objets offrent des modules

Cours « GL-ACOO » ENSI

 L’abstraction : c'est la capacité d'ignorer les détails

 La réutilisabilité : les objets offrent des modules

Avantages du modèle objet

 L’approche objet gère plus efficacement la

Cours « GL-ACOO » ENSI

1. Sensibilisation à la modélisation objet

Cours « GL-ACOO » ENSI

UML = Unified Modeling Language

 Un langage de modélisation des applications

Cours « GL-ACOO » ENSI

 Ce n’est pas une méthode

 Au départ, plus de 50 méthodes !!

Cours « GL-ACOO » ENSI

 Unification progressive de plusieurs méthodes, de

 Standardisation : en 1997 par l’OMG (Object Management

Un besoin d’Unification: Unified

Cours « GL-ACOO » ENSI

Sous forme de langage: Language

OMT Genèse d’UML

Cours « GL-ACOO » ENSI

Catalysis ROOM etc. 25

 N’est pas une méthode mais un langage : définit des diagrammes et