maj 2016

Conception des Programmes et Orienté-Objet

Principes et fondamentaux

Présentée par Dr. Samia GAMOURA-CHEHBI

 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 1. Conception : Pourquoi ?

Objectif : Logiciel, Programme, SI, :…Construction, réalisation, …

Objectif

Moyen : Conception Moyen : Schéma, plan, …

 1. Conception : Pourquoi ?

Mais aussi :
Apparition de besoins nouveaux (années 80)
Domaines d'application de plus en plus nombreux
Applications de plus en plus complexes, notamment en interactions homme-machine (IHM)
La réutilisabilité des logiciels devient une nécessité économique
Besoin d'abstraction des données
Besoin de modularité, d'évolutivité
Besoin de communication
Besoin de maintenance, qui devient, de plus en plus couteuse
 1. Conception : où est le problème ?

1. Initialiser stock = 0
2. Décharger camion
3. Stock = Stock + 1
4. Si Camion est vide alors aller à étape 6
5. Sinon aller à l’étape 2
6. Imprimer « le stock déchargé est : » Stock
7. Fin du programme

Conception à la SPAGHETTI
• Complexité de conception
• Complexité de maintenance et de suivi
• Pas facile à comprendre et à communiquer
 1. Conception : Histoire, évolution des idées et réflexions

1968. Dijkstra : A case against the GOTO

Pas de GOTO !
Modularité plutôt que des blocks procéduraux

1970. Alan Kay : … Designing by pieces

sous-classification
polymorphisme

1972. Lorge Parnas : … To be used in decomposing systems into modules

Découpage en modules
Encapsulation
 1. Conception : Histoire, évolution des idées et réflexions

1968. Dijkstra : A case against the GOTO

Pas de GOTO !
Modularité plutôt que des blocks procéduraux

Décomposition en objets :
1970. Alan Kay : … Designing by pieces
sous-classification
polymorphisme Orienté-Objet

1972. Lorge Parnas : … To be used in decomposing systems into modules

Découpage en modules
Encapsulation
 1. Conception : Notions et définitions

Un programme ?
est un ensemble de procédures
• Qui utilisent des données
• Qui modifient des données

Programmer ?
c’est concevoir des traitements
• Elaboration d’algorithmes

Programmation structurée ?
séparation des données et des traitements
• Exemple : Évolution d’une application de gestion de bibliothèque pour gérer une
médiathèque
 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 2. Orienté objet : c’est quoi ?

Programmation orientée-objet ?
Centralisation des données et des traitements, au sein d’une même entité : l’objet
• Un objet est une entité
• Qui possède une identité (un nom)
• Dont les attributs décrivent l’état
• Dont les opérations (méthodes) décrivent le comportement
• Un objet communique avec un autre objet par envoi de messages
 2. Orient objet : Concept

Classe
Marque
Puissance fiscale
Vitesse maximale
Vitesse courante

Objet 1 Objet 2 Objet 3

Marque : Citroën Marque : Renault Marque : BMW
Puissance fiscale : 7 Puissance fiscale : 6 Puissance fiscale : 4
Vitesse maximale : 230 Vitesse maximale : 220 Vitesse maximale : 210
Vitesse courante : 50 Vitesse courante : 90 Vitesse courante : 120
 2. Orienté objet : c’est quoi ?

Il n’y a plus de programme au sens strict

Chaque entité est conçue indépendamment

Modéliser la réalité telle qu’elle est conceptualisée

On pense système avant de penser traitement

L’objet existe et vie, il est donc modélisable.

Dans un système, réussir à identifier les acteurs = les objets = les entités = ...
 2. Orienté objet : Pourquoi ?

l’Objet

Gains ?
Maîtrise des interactions

Modularité

Facilité de maintenance

Réutilisabilité

Facilité de codage

Evolutivité du système

Utilisation de la mémoire :
Dans les langages procéduraux, il est nécessaire de définir toutes les données dont on va
avoir besoin ; Le compilateur réserve systématiquement toute la place en mémoire,
nécessaire à ces données, et durant toute l’exécution du programme.
En programmation objet, l’utilisation de la mémoire est dynamique : fonction des
instances qui sont utilisées à un moment donné.
2. Orient objet : Pourquoi ?
 2. Orienté objet : Comment décomposer ?

Principe : Décomposer le système en objets (classes) ?

Sur critère fonctionnel ? Sur critère structurel ?

Fonction
A
- -
D - C
Sous-fonction 1 Sous-fonction 2
- - E

Sous-fct 1.1 Sous-fct 1.2 Sous-fct 2 Sous-fct 2 B - F - -

Si la fonction change et évolution Si la fonction évolution, modifier les
(souvent le cas) alors revoir tout le méthodes. Si la structure évolue
modèle ! alors modifier les attributs : Plus
facile à maintenir.
 2. Orienté objet : Histoire, évolution des idées et réflexions

1967. SIMULA:
1er langage de programmation à implémenter le concept de type abstrait, à l’aide de
classes

1968-1976. Intelligence Artificielle :

SMALLTALK (1976) était le 1er langage à implémenter les concepts fondateurs de
l’objet (encapsulation, agrégation, héritage)

1983. Génie Logiciel:

ADA …
 2. Orient objet : Histoire, évolution des idées et réflexions

1986. C++ :
Par Bjarne Stroustrup

1988. Langages objet académiques :

Eiffel, Objective C, Loops, …

1994. Java :
Par Sunsoft, langage de classe «à la smalltalk» avec syntaxe de type C++
 2. Orienté objet : Classes & objets

Héritage :
Relation qui permet la transmission des propriétés d'une classe (ses attributs et
méthodes) vers une sous-classe :
• Une sous-classe est une spécialisation de sa super-classe ou classe mère
• Une super-classe est une généralisation de ses sous-classes

Engin

est-un
Véhicule Avion

Moto
Voiture Camion
 2. Orient objet : Classes & objets

Généralisation :

On dit qu’une sous-classe hérite de sa super-classe

• Elle hérite de sa structure
• Elle hérite de son comportement
Remarque : on hérite aussi des grands-parents…

La super-classe
La sous-classe

Est-un
 2. Orienté objet : Classes & objets

Spécialisation :

Une sous-classe spécialise

• Elle ajoute des éléments de structure (attributs)
• Elle ajoute de nouveaux comportements (opérations)
• Elle peut modifier les comportements hérités :
• Substitution
• Surcharge
• Plusieurs classes peuvent être généralisées en une classe qui les factorise
• La super-classe regroupe ainsi les caractéristiques communes d’un ensemble de
classes
Remarque : L'héritage évite la duplication et encourage la réutilisation

CompteCourant

Méthodes héritées déposer (uneSomme)

solde ()
Méthode surchargée retirer (uneSomme)
estADecouvert ()
Méthode ajoutée
 2. Orienté objet : Relations entre classes

Une relation est une connexion sémantique entre des classes

On distingue :
• Les associations de classes
• Les relations de classification (ou d’héritage)

CompteCourant Client

numéro Société
nom
solde courant prénom Nom
âge Adresse siège
Code SIRET
UnCompte

950445123
+ 12001
UnClient

Montale
UnAutreCompte
Fabien
43
950445675
- 31789
 2. Orienté objet : Relations entre classes

Associations :
Les associations entre classes peuvent être :
• Structurelles
• composition, agrégation
• Situatives
• dans le temps (avant, pendant, après, ...)
• dans l’espace (sur, sous, à gauche de, …)
• Significatives d’un rôle, d’une possession
• directeur de, maire de, piloté par,
• etc.
 2. Orienté objet : Relations entre classes

Agrégation :
• Représente une connexion bidirectionnelle non symétrique
• Exprime un couplage plus fort entre classes
• Permet de définir une relation type composé/composants :
• Définit des objets composés d’autres objets
• Permet d’assembler des objets de base, pour construire des objets plus
complexes

Agrégation
Agrégation réflexive type composé / composants
 2. Orienté objet : Relations entre classes

• Héritage : répond à la question «est une sorte de ?» ou «est un ?»

• Agrégation : répond à la question «est composé de ?» ou «a des ?»

Une roue n’est pas une

Voiture
sorte de voiture !
Une voiture a des roues !
Roue Moteur
 2. Orienté objet : Polymorphisme

Le polymorphisme :
• poly - plusieurs
• morphisme – forme
Jouer Rembobiner

Arrêter Dérouler

... Symboles
polymorphes

Cassette USB

Lecteur CD
 2. Orienté objet : Polymorphisme

Le polymorphisme :
• C’est la faculté d'une opération à pouvoir s'appliquer à des objets de classes
différentes
• C’est la propriété de donner le même nom (sélecteur dans le message) :
• À des comportements analogues
• Qui vont donner lieu à des réalisations plus ou moins différentes
• Selon le receveur du message

En termes informatiques
Vehicule convoi[3] =
{
Train("TGV"),
Voiture("twingo"),
Bateau("Titanic")
};

for (int i = 0; i < 3; i++)

{
convoi[i].seDeplacer();
}
 2. Orienté objet : Encapsulation

Encapsulation :
• Consiste à masquer les détails d'implémentation d'un objet, en définissant une
interface
• C’est la vue externe d'un objet,
• Elle définit les services accessibles (offerts) aux utilisateurs de l'objet
• Elle facilite l'évolution d'une application car elle stabilise l'utilisation des objets
• Garantit l'intégrité des données, car elle permet d'interdire l'accès direct aux
attributs des objets

Individu

interface Opérations : Attributs :

donneMoiTonAge
dateNaissance
esTuMajeur esTuMajeur ageMajorité
poids
donneMoiTonPoids donneMoiTonPoids

booléen esTuMajeur ()
{Retourne (self.donneMoiTonAge () >= self.ageMajorité() }
 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 3. UML : Un peu d’histoire …

1984. Knuth :
Utilisation des commentaires
Inconvénient : illisibilité et structure non apparente

1990. Rumbaugh:
Diagrammes

1993 Booch :
Diagrammes et légendes
 3. UML : Un peu d’histoire …

1984. Knuth :
Utilisation des commentaires
Inconvénient : illisibilité et structure non apparente

1990. Rumbaugh:Un langage unifié standardisé :

Diagrammes
Unified Modeling Language

1993 Booch : … To be used in decomposing systems into modules

Diagrammes et légendes
 3. UML : Fondements

UML (Unified Modeling Language, traduisez "langage de modélisation objet unifié")

Né de la fusion : OMT, Booch et OOSE

Résultat d'un large consensus : L’OMG centralise et normalise les évolutions

Un standard incontournable

Langage de modélisation ouvert

De nombreux outils supportent UML

 3. UML : Fondements

UML n’est ni une méthode, ni un processus

UML est un langage qui définit : les éléments de la modélisation et leur sémantique

UML définit différentes vues (perspectives) d’un système d’information

Les perspectives guident l’utilisation des concepts objets

UML est un support de communication

Un langage de notations graphiques

 3. UML : Fondements

UML rassemble plusieurs vues (perspectives) complémentaires pour modéliser au mieux

le SI

Vue de déploiement

Vue des
composants Vue des processus
Vue des cas
d’utilisation

Vue Logique
 3. UML : Fondements

Chaque acteur a une vue

différente sur le projet

exprime ses besoins

exprime les concepts du métier
Utilisateur Expert métier

évalue le coût de la réalisation

Chef de projet gère les risques du projet

interroge les utilisateurs

et les experts métier précise les éléments du
Commercial
contrat avec le client
Analyste
 3. UML : Fondements

Chaque acteur a une vue

différente sur le projet

Architecte constitue l'architecture logique du système

orienté logiciel

Concepteur constitue le modèle de la solution =modèle de

conception

Développeur réalise une partie du système

Architecte Architecture au niveau :

orienté matériel / • ressources matériels
réseau • répartition du logiciel dans ces
ressources
Testeur teste le système selon le
(validation modèle des besoins
fonctionnel)
 3. UML : Fondements

Vision statique Vision dynamique

• Diagramme de classes • Diagramme d’états-transitions

• Diagramme d’objets • Diagramme d’activités
• Diagramme de cas d’utilisation • Diagramme de collaboration
• Diagramme de composants • Diagramme de séquence
• Diagramme de déploiement
 3. UML : Fondements

• Le diagramme de classe permet

• D’illustrer les structures des classes
• de préciser le comportement générique et les responsabilités des objets
représentés
 UML : Diagrammes ?

• Le diagramme d’objet permet

• D’illustrer les structures des objets et des liens dans un état donné
• De préciser des points de vue particuliers (snapshot)
 3. UML : Diagrammes d’état transition ?

• Le diagramme d’états-transition
• Permet de décrire les changements d'états d’une classe, en réponse aux interactions
avec d'autres classes ou avec des acteurs

• Principe :
• Automate d'états finis, sous forme de graphes d'états, reliés par des arcs orientés qui
décrivent les transitions
 3. UML : Diagrammes de cas d’utilisation ?

• Le diagramme de cas d’utilisation

• Présente les besoins des utilisateurs vis à vis du système
• Le Use-case correspond à la séquence d’interactions réalisées par un acteur, en
vue d’obtenir un résultat précis.
 3. UML : Diagrammes de séquences ?

• Diagramme de séquence
• Présente les collaborations entre objets selon un point de vue temporel :
• L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical
du diagramme
• Le temps s'écoule "de haut en bas" de cet axe
• Pour illustrer un cas d'utilisation ou pour représenter les messages échangés
entre objets
 3. UML : Diagrammes de collaboration ?

• Le diagramme de collaboration
• Spécifie le comportement dynamique du système suivant la vision des messages
échangés.
• Modélise les flux de contrôle et illustre la coordination entre objets (instances de
classes) et/ou entre objets et acteurs
 3. UML : Diagrammes d’activité ?

• Diagramme d’activités
• Présente le comportement interne d'une opération ou le déroulement d'un cas
d'utilisation
 3. UML : Diagrammes de composants ?

• Diagramme de composants
• Permet de décrire l'architecture physique et statique d'une application en terme
de modules (fichiers sources, librairies, exécutables, etc…)
• Montre la mise en oeuvre physique des modèles de la vue logique avec
l'environnement de développement
• Les composants peuvent être organisés en paquetages, qui définissent des sous-
systèmes
 3. UML : Diagrammes de déploiement ?

• Diagramme de déploiement
• Montre la disposition physique des matériels qui composent le système et la
répartition des composants sur ces matériels
• Correspond à la vue de déploiement d'une architecture logicielle
• Les ressources matérielles sont représentées sous forme de noeuds
 3. UML : Diagrammes ?

Que veut-on ? Dans quel

environnement ?

Modèle des besoins des

acteurs Diagramme de cas d’utilisation
Diagramme de séquence
QUE doit-on Modèle d’analyse des Diagramme de collaboration
modéliser ? besoins Diagramme d’activité
Diagramme d’état-transition
Modèle de conception Diagramme de classe
COMMENT le Diagramme d’objet
réaliser ?
Diagramme de composant
Modèle
d ’implémentation Diagramme de déploiement
 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 4. Pratique

Question ?

Cette girafe, est elle :

- une classe
- une instance
?
 4. Pratique

Réponse

Cette girafe, est :

- une classe
- une instance
 4. Pratique

Question ?

Quelles sont les classes et quelles sont les instances ?

• Le chat
• Garfield
• Felix the cat

• La tulipe
• Les tulipes de mon jardin
• La fleur
 4. Pratique

Réponse

Classes et quelles sont les instances :

• Le chat : une classe

• Garfield : une instance de la classe chat
• Felix the cat : une instance de la classe chat

• La tulipe : une classe qui hérite de la classe fleur

• Les tulipes de mon jardin : instances de la classe tulipe
• La fleur : une classe
 4. Pratique

Question ?

Ces arbres de généralisation, sont ils corrects ?

Voi tu re

C offre Rou e M ote u r

 4. Pratique

Réponse

Arbres de généralisation :

Non, un moteur n’est pas une sorte de Voitu re

voiture, une voiture possède un moteur
=> relation d’agrégation
C offre Rou e M ote u r

Non, ce sont les états d’un individu

=> attribut « état »
 4. Pratique

Question ?

• L’autruche est un oiseau

• L’oiseau sait voler
• L’autruche ne sait pas voler

Où est le problème ?
 4. Pratique

Réponse :

• L’autruche est un oiseau

• L’oiseau sait voler
• L’autruche ne sait pas voler

L’autruche est un exemple d’héritage « sémantique » qui fonctionne

mal.
Solutions : surcharge de l’opération « se déplacer », modèles ci-
dessous,
mais qui ne sont pas non plus satisfaisants dans l’absolu
(mais cela dépend du contexte de la conception)

Oiseau Oiseau

marcher()

OiseauVolant OiseauNonVolant

Pigeon Autruche

voler() courir() Pigeon Autruche

 4. Pratique

Question ?

Représenter avec les concepts objet :

• Un fichier : Un fichier est caractérisé par un nom, une taille
• Un répertoire : Un répertoire porte un nom. Il peut contenir des répertoires
ou des fichiers
 4. Pratique

Réponse

Représenter avec les concepts objet :

• Un fichier : Un fichier est caractérisé par un nom, une taille
• Un répertoire : Un répertoire porte un nom. Il peut contenir des répertoires
ou des fichiers

La création d’une classe « Entité », permet

• de généraliser l’attribut « nom »
• de représenter la récursivité (un répertoire peut contenir des
fichiers et des répertoires)
 4. Pratique

Question ?
Le secrétaire de mairie veut informatiser la gestion de l’état civil : enregistrement des actes de
naissance, de mariage, de décès.
• Pour une naissance, on enregistre les nom, prénom, date naissance, lieu de naissance de
l’individu.
• Pour un mariage : date de mariage, nom du conjoint et lieu de mariage, éventuellement
date décès.
• Pour un décès, date et lieu décès.
• Lors de la publication du journal annuel de la commune, le secrétaire veut pouvoir
éditer la liste des individus, triés par nom, nés dans l’année écoulée.

Construire le diagramme de classes ?

 4. Pratique

Réponse
Le secrétaire de mairie veut informatiser la gestion de l’état civil : enregistrement des actes de
naissance, de mariage, de décès.
• Pour une naissance, on enregistre les nom, prénom, date naissance, lieu de naissance de
l’individu.
• Pour un mariage : date de mariage, nom du conjoint et lieu de mariage, éventuellement
date décès.
• Pour un décès, date et lieu décès.
• Lors de la publication du journal annuel de la commune, le secrétaire veut pouvoir
éditer la liste des individus, triés par nom, nés dans l’année écoulée.
 Plan

1. Conception : C’est quoi et … Pourquoi ?

2. Orienté Objet : Qu’est ce que c’est ? … Pourquoi ?

3. UML : Qu’est ce que c’est ? … Comment ?

4. Pratique : OO et UML, c’est quoi dans la pratique ?

5. Avenir : OO, c’est quoi dans l’avenir ?

 Avenir : Orienté Agent

• Tâche 2: Disposer objet C sur A

• Tâche 1: Prendre objet A
•Tâche 3: Disposer les objets B sur A

B B

Agent : Objet évolué : Objet passif : manipulable

intelligent (évolue dans le par les agents
temps et s’adapte) et actif
qui manipule les objets
passifs et communique
avec ses semblables
 Avenir : Orienté Agent

Rôle A : Client

Rôle B : Fournisseur de
produit final

Entreprise qui négocie des contrats pour

acheter de la matière première

Rôle C : Négociateur de
contrat
Rôle D : Producteur de
matière première
Avenir : Orienté Agent

Rôle

Interaction

fournisseur Client
Producteur

Agent-Acteur
Rôle Client Rôle Fournisseur Rôle Producteur

Rôle Client
Rôle Producteur
Acheter() Rôle Fournisseur
Fabriquer()
Passer_Commande() Vendre()
Calculer_Coût_Production()
Calculer_coût_Achat() Recevoir_Commande()
Livrer()
Calculer_coût_Vente()
Avenir : AUML

UML AUML
Merci …