ANALYSE ET

CONCEPTION
ORIENTÉES OBJET
(II2)
LA MISE EN PLACE D’UN SYSTÈME

2
 Analyse Conception
Quoi-Faire ? Comment-Faire ?
Description de la solution d’un
Description d’un problème : CONCEPTION
problème :
ANALYSE

3
 LA COMPLEXITÉ DES LOGICIELS

 Les systèmes peuvent être décomposés selon

 ce qu’ils font (approche fonctionnelle)
 ce qu’ils sont (approche objet)

 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  maintenance , réutilisabilité

4
 INTÉRÊT DES OBJETS?

Structure d'une application objet => flots de messages entre un certain

nombre d'objets, les objets sont " presque " indépendants les uns des
autres. O b je t 1 M essage

O b je t 3

O b je t 2

- Cette indépendance (l'une des grandes forces de l'approche O.O.)

permet la réutilisation des objets par de nombreuses applications.
- Les objets sont plus stables que les spécifications qui définissent
leurs interactions => les applications sont plus simples à écrire et à
faire évoluer.

5
 HISTORIQUE DES LANGAGES OO

 Langages de programmation orientés objets

 Simula (1967)
 Smalltalk (1970)
 C plus Classes (1980)
 C++ (1985)
 Eiffel (1988)
 Java (1995)
 C#, …
 SGBD orientés objets
Utilisation des BDs avec un langage OO

 Genèse des méthodes d’analyse :

Implémentation
 Conception (solution informatique)
 Analyse (comprendre et modéliser le problème)  …

6
 LES MÉTHODES D’ANALYSE

 Méthodes orientées comportement :

on s’intéresse à la dynamique du système ; ex : réseaux de Pétri

 Méthodes fonctionnelles :
s’inspirent de l’architecture des ordinateurs
on s’intéresse aux fonctions du système ; ex : SADT

 Méthodes orientées données :

on ne s’intéresse pas aux traitements ; ex : Merise

 Méthodes orientées objets :

on ne sépare pas les données et les traitements ; ex : Booch, OMT

7
 L’UNIFICATION

 des méthodes
 La guerre des méthodes ne fait plus avancer la technologie des objets
 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

 sur plusieurs domaines d’applications

 Scientifique
 Industriel
 Gestion
 Multimédia
 …

8
 UML ?

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

 C’est:
 Un langage de modélisation des applications construites à l’aide d’objets,
indépendant de la méthode utilisée
 Une notation, un langage de modélisation objet
 Une description complète, évolutive, publique
 Un standard

 Ce n’est pas :
 Une méthode

9
 GENÈSE D’UML
OMT
 U t i l i s a t i on d ’u n s t a n d a r d d e mo d é l i s a t i o n « u n i v e r s e l »
Booch  A u d é p a rt , p l u s d e 1 5 0 mé t h o d e s ! !
OOSE  U n i fi c a t i o n p r o g r e s s i v e d e p l u s i e u rs mé t h o d e s , d e r e ma r q u e s d e s
u t i l i s a t e ur s , d e s p a r t e n ai re s
Fusion  1 9 8 9 : c r é a t i o n d e l ’O M G ( O b j e c t M a n a g eme n t g r o u p ) ; g r o u p e c r é é à
l ’ i n i t i a t i v e d e g r a n d e s s o c i é t é s i n f o rm a t i q ue s a mé r i c a i n e s a f i n d e
Classe-Relation n o r m a l i s e r l e s s y s t è m e s à o b j e t s ; 1 è r e r é a l i s at i o n d e l ’O M G : C O R B A
( c o mmu n i c a t i on e n t r e a p p l i c a t io n s o b j e t s d a n s u n s ys t è m e d i s t r i b u é
ROOM h é t é r ogè ne )
HOOD
 L a d e r n i è re v e r s i o n d e l a s p é c i f i c a t i o n v a l i d é e p a r l ' O M G e s t U M L
2 .5 . 1 ( 2 0 17 )
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.

10
DEVANT ET DERRIÈRE, AVANT ET
APRÈS ...

Méthode = Langage(s) + Démarche + Outils

OMT
procédés UML SA/RT
SADT
industriels
de production ERD
Merise
de logiciels et
de systèmes. DFD
etc.
JSD
 LES OUTILS UML

Fonctionnalités courantes
 Edition des modèles et diagrammes UML
 Gestion du dictionnaire de données
 Génération de code C++, Java,...
 Rétro-conception à partir de code existant
 …

Quelques exemples
 Rational Rose de Rational Software (www.rational.com)
 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)
 STARUML, …

12
 PRÉSENTATION DU COURS

 Module 45h.

 Cours

 Travaux dirigés/Travaux pratiques

13
 OBJECTIFS DU COURS

 Présenter les différents diagrammes UML2.5

 Apprendre la modélisation objet

 Connaître et utiliser les patrons de conception

14
 PLAN DU COURS

Introduction
Les diagrammes d’analyse

Diagrammes de conception architecturale

Les diagrammes de conception détaillée

Les patrons de conception

Etude de cas récapitulatifs

15
 ÉVALUATION

Examen Final (65 %)

Contrôle continu (35%)

 Devoir surveillé
 Tests oraux et/ou écrits
 Devoirs à la maison

16
 RÉFÉRENCES

 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)

17
 II2-ENSI
INTRODUCTION
 INTRODUCTION
Plan

 Sensibilisation à la modélisation
 Importance de la modélisation
 Principes de modélisation
 Intérêt et limites des modèles
 UML
 Définition
 Historique
 Buts d’UML
 Diagrammes

19
 MODÉLISATION DES OBJETS

• Objectif :
Représenter certains aspects de la réalité d’intérêt
pour l’organisation

Monde Réel Monde de l’information

{Colette skie vite,

Elle porte des pantalons rouges
Et un pull bleu}

Un objet réel Représentation de l’objet réel

 MODÉLISATION DES OBJETS

• Approche
Représenter les objets réels, leurs propriétés et leurs
relations par leurs équivalents O&R dans le monde de
l’information
Monde de l’information
Monde Réel

Observer le monde réel, Représenter les O&R réels

Identifier les
objets & relations pertinentes,
Selectionner les propriétés
d’intérêt
par des objets informationnels
en relation les uns avec les autres
Leur associer les propriétés
de leurs homologues réels
Stocker les valeurs des propriétés
VUES MULTIPLES (ASPECTS D'UN SYSTÈME
LOGICIEL)

Vue du
plombier Vue de
l'électricien Vue du
locataire

Vue du
maçon

Vue du
propriétaire

Vue de
l'architecte
LA MAPPEMONDE EST UN MODÈLE
DE LA TERRE

modelOf

System represents Model

ask() ask()
L’IMPORTANCE DE LA MODÉLISATION

Qu’est ce qu’un modèle?

Un modèle est une simplification de la réalité
• Abstraction de la réalité
• Description de tout ou partie d’un système dans un langage bien défini.
• Ensemble de concepts, règles, un formalisme
• Vue subjective mais pertinente de la réalité

Pourquoi modéliser?
Les modèles permettent de mieux comprendre le système que l’on développe
• Fournir des spécifications claires : produire, exploiter
• Clarifier les objets, les concepts, les référentiels, les processus.

Nous construisons des modèles pour les sy stèmes complexes parce que nous
ne sommes pas en mesure d’appréhender de tels systèmes dans leur
intégralité.

Des Modèles plutôt que du Cod e: L e cod e ne permet pas de

simplifier/abstraire la réalité

24
 LES QUATRE PRINCIPES DE
MODÉLISATION

1. Le choix des modèles à créer a une forte influence sur la

manière d’aborder un problème et sur la nature de sa
solution.
2. Tous les modèles peuvent avoir différents niveaux de
précision.
3. Les meilleurs modèles ne perdent pas le sens de la
réalité.
4. Parce qu’aucun modèle n’est suffisant à lui seul, il est
préférable de décomposer un système important en un
ensemble de petits modèles presque indépendants.

25
 DIFFÉRENTES SORTES DE MODÈLES
System represent s Model

ask() ask()

Dynamic StaticSystem Dy namic StaticModel

System Model

modèle
La carte est un modèle statique S D
d'un système statique.
S o n
Autre exemple, un recensement.
D o o
26
 INTÉRÊT DU MODÈLE

 Le modèle est important pour :

° Comprendre un problème
° Supporter un travail coopératif d'ingénierie
° Prévoir et simuler la réalisation d'un développement
° Identifier et suivre les lots de travaux
° Guider, contrôler, automatiser la production
 Construire un bâtiment sans plan : Est ce possible?
 Evolution de la CAO
° Représentation des pièces mécaniques
° Vérification de la compatibilité de pièces
° Emission de plans de fabrication
° Pilotage des chaînes de production
 Et le logiciel?

27
LIMITES ET DANGERS DES MODÈLES
Tout modèle est faux, toute abstraction est
fausse!--- Ne pas confondre le modèle et le système
 La pipe de Magritte
 L'image de la pipe ne permet
pas de fumer
 L'image de la pipe permet de
raisonner sur la pipe (design,
constitution, etc.) au niveau
de l'instance ou du concept.

modelOf
28
LA MAPPEMONDE EST UN MODÈLE
DE LA TERRE

 Permettant de poser  mais pas d'autres.

certaines questions …
 PERSPECTIVES D’UN SYSTÈME
Statique (ce que le système EST)

Dynamique
(comment le système Fonctionnel
EVOLUE) (ce que le système FAIT)
 EMPLOI DES MODÈLES: LIMITES ET
DANGERS
 Besoin de modèles pertinents et adaptés
° Adaptés au domaine
° Compréhensibles par les intervenants
° Apportant une plus value d'abstraction suffisante (ex :
Action semantics)
 Un modèle est un outil, dont il faut toujours mesurer
la plus value : Pragmatisme sur le choix et l'usage des
modèles
 Complémentarité avec d'autres approches (ex : prototypage,
approche incrémentale, etc.)
 La "culture UML" doit se mettre en place dans les
organisations

31
VERS UN LANGAGE UNIFIÉ POUR LA
MODÉLISATION
Booch, Jacobson et Rumbaugh se fixent 4 objectifs:
 représenter des systèmes entiers (au-delà du seul logiciel) par des
concepts objets (plusieurs vues) ,
 établir un couplage explicite entre les concepts et les artefacts
exécutables,
 prendre en compte les facteurs d’échelle inhérents aux systèmes
complexes et critiques,
 créer un langage de modélisation utilisable à la fois par les humains
et les machines.

32
 UML: DÉFINITION

UML : Unified Modeling Language

(langage de modélisation unifié)

Constat :

 Né de plusieurs méthodes (Booch, Oose…)

 UML est désormais la référence en modélisation objet

But :
Modéliser un problème de façon standard

33
 L’UNIFICATION

Les créateurs d’UML insistent tout particulièrement sur le fait que

la notation UML est un langage de modélisation objet et non pas
une méthode objet.
UML n’est pas une notation propriétaire; elle est accessible à tous
et les fabricants d’outils ainsi que les entreprises de formation
peuvent librement en faire usage.
En français, UML pourrait se traduire par langage unifié pour la
modélisation objet, mais il est plus probable qu’UML se traduise
plutôt par notation unifiée, voire notation UML…

34
 UML: HISTORIQUE

 Création en 1995 (fusion des méthodes Booch et OMT,

puis par la suite Oose)
 1996 : Proposition à l’OMG (Objet Management Group)
 1997 : Standardisation OMG
 Aujourd’hui, nous sommes à la version 2.5

35
 Les CONTRIBUTIONS À UML

Booch
Rumbaugh Jacobson
Fusion
Meyer
La description des opérations,
Conception par
Le nombre de messages
contrat - invariants

Embley
Harel
Les classes singletons,
Diagrammes à état

Gamma, et.al
Wirfs-Brock
Frameworks, patterns,
Les responsabilités
notes Shlaer - Mellor Odell

Les cycles de vie Les classification

 Les CONTRIBUTIONS À UML

Le développement d’UML à été fait par un large

échantillon de l’industrie :

HP, ICON Computing, IBM, I-Logix, Intellicorp, MCI

Systemhouse, Microsoft, ObjectTime, Oracle, Platnium,
Technology, Ptech, Reich Technologies, Softeam, Sterling
Software, Taskon, et Unisys.
 UML - LANGAGE
 UML comble une lacune importante des technologies
objet. Il permet d'exprimer et d'élaborer des modèles
objet, indépendamment de tout langage de programmation.

 UML normalise les concepts objet .

 Un lang age de mod él is atio n des app li cat io ns cons t ru i tes à l ’aide d ’obj ets ,
indépendamm en t de la méthod e utilis ée

 C’est :
 Une notation
 Une description complète, évolutive, publique
 Un standard

 Ce n’est pas :
 Une méthode
 Une méthodologie
 Un processus de modélisation
 Une démarche de modélisation

38
 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

39
OBJECTIFS D’UML

UML est un langage conçu pour:

• Visualiser
• Chaque symbole graphique a une sémantique
• Spécifier
• de manière précise et complète, sans ambiguïté
• Construire
• les classes, les relations, ….
• Documenter
• les diagrammes, notes, contraintes, exigences
les artefacts d’un système à forte composante
logicielle

40
 MODÉLISATION ORIENTÉE OBJET

Domaine de l’application Domaine de la solution

Modèle du système (Concepts) (Analyse) Modèle du système (Concepts)

Package (Conception)
UML Summary
MapDisplay Display
TrafficControl
FlightPlanDatabase
Aircraft TrafficController
TrafficControl
Airport FlightPlan
 LES PRÉOCCUPATIONS EN UML

 il n’existe pas une seule manière de regarder 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).

 UML permet de représenter les systèmes informatiques

selon plusieurs préoccupations partielles et
complémentaires.

42
 LES PRÉOCCUPATIONS EN UML

 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
43
LES NIVEAUX D’ABSTRACTIONS

44
 LES BRIQUES DE BASE

 Les briques de base de UML sont :

 Les éléments de modèle (classes, interfaces,

composant, etc.)
 Les relations (associations, généralisation,
dépendences, etc.)
 Les diagrammes (diagramme de classe, diagramme de
cas d’utilisation, diagramme d’interaction, etc.)

 Les briques de base simples sont utilisés pour construire

des structures plus complexes et plus grandes

45
LES REPRÉSENTATIONS POSSIBLES

46
LES REPRÉSENTATIONS POSSIBLES

47
LES REPRÉSENTATIONS POSSIBLES

48
LES REPRÉSENTATIONS POSSIBLES

49
LES REPRÉSENTATIONS POSSIBLES

50
LES REPRÉSENTATIONS POSSIBLES

51
LES REPRÉSENTATIONS POSSIBLES

52
 LE LANGAGE UML
 Les mécanismes généraux
 Les paquetages
 Les stéréotypes
 Les étiquettes
 Les notes
 Les contraintes
 Les diagrammes de base
 Les diagrammes de classes avec la contribution
 Les diagrammes d’objets de Pierre-Alain Muller
 Les diagrammes de cas d'utilisation
 Les diagrammes de séquence
 Les diagrammes de communication
 Les diagrammes d'états/transitions
 Les diagrammes d'activités
 Les diagrammes de composants
 Les diagrammes de déploiement

53
 PRINCIPAUX DIAGRAMMES D’UML

State
State
Diagrams
Diagrammes
Diagrams
Use-Case De Classes
Use-Case
Diagrammes
Diagrams State
Use-Case Diagrams
de cas State
Diagrams
Use-Case Diagrammes
Diagrams
Diagrams
Diagrammes d’utilisation D’objets
Diagrams
D’activités

Scenario State
Scenario
Diagrams State
Diagrams
Diagrammes
Diagrams Diagrammes
Diagrams
De séquences Modèles D’états

Scenario Component
Scenario
Diagrams
Component
Diagrams
Diagrammes
Diagrammes
Diagrams Diagrammes Diagrams
De collaboration De déploiement De composants
 MODÈLES D’UML

 Le modèle des classes qui capture la structure

statique
 Le modèle des états qui exprime le comportement
dynamique des objets
 Le modèle des cas d’utilisation qui décrit les
besoins des utilisateurs
 Le modèle d’interaction qui représente les
scénarios et les flots de messages
 Le modèle de réalisation qui montre les unités de
travail
 Le modèle de déploiement qui précise la répartition
des processus
55
 LES DIAGRAMMES D’UML 2.5
 Diagramme de cas d’utilisation: montre les interactions fonctionnelles entre les acteurs et le
s ys t èm e à l ’ét ude.
 Diagramme de classes: montre les briques statiques (classes, associations, opérations,…)
 Diagramme d’objets: montre les instances des éléments structurels et leurs liens.
 Diagramme de packages: montre l’organisation logique du modèle et les relations entre packages.
 Diagramme de séquence: montre la séquence verticale des messages passés entre éléments au sein
d’une interaction.
 Diagramme de communication: montre la communication entre éléments dans le plan au sein d’une
interaction.
 Diagramme d’états: montre les différents états et transitions possibles des objets d’une classe à
l’exécution.
 Diagramme d’activités: montre l’enchainement des actions au sein d’une activité.
 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.
 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.
 Diagramme de structure composite: montre l’organisation interne d’un élément structurel
complexe.
 Diagramme de composants: montre des structures complexes avec leurs interfaces fournies et
requises.
 Di agram m e de dépl oi em ent : m ont re l e dép l oi em ent ph ys i qu e des art éfact s s ur l es res s ources
matérielles.
 Diagramme de profil: définit un profil spécifique à un domaine ou une problématique par
e x t e n s i o n d u m é t a m o d è l e U M L . C e 1 4 ème t y p e d e d i a g r a m m e i n t r o d u i t o f f i c i e l l e m e n t p a r U M L 2 . 3
n’est utilisé que par ceux qui souhaitent définir une varaiante d’UML pour un domaine spécifique(
S ys M L : S ys t e m s M o d e l i n g L a n g u a g e e s t u n e x e m p l e d e p r o f i l U M L 2 ) .

56
 LES DIAGRAMMES D’UML 2.5

 Diagramme de profil Diagramme de vue globale d’interaction

Diagramme de temps

Diagramme de
structure
composite

57
LES MODÈLES UML / PAR VUE

58
 PROCESSUS BASÉ SUR LA
RÉALISATION DE MODÈLES
1
Capture des 2
exigences Analyse Modèle de conception

Modèle de déploiement

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

59
CHAÎNE COMPLÈTE D’UNE DÉMARCHE DE
MODÉLISATION DU BESOIN JUSQU’AU CODE
 PHASES NON OUTILLÉES PAR UML
 Codage
 Transcription dans un langage de programmation objet des objets du
dossier de conception
 Tests
 Réaliser les tests unitaires des classes
 Faire les tests des modules correspondant aux paquetages
 Tester les scénarios
 Valider le système du point de vue externe
 Intégration
 Introduction des classes ou paquetages par étapes

61
CONCLUSION - LES BÉNÉFICES D’UML

62