SlideShare une entreprise Scribd logo
http://www.isima.fr/~loic
Juin 2017
2
Plan
1. Génie logiciel et historique
2. Concepts objets
Ces transparents ont été conçus originellement par Bruno-Laurent GARCIA, ISIMA
Améliorations successives de David HILL et Christophe DUHAMEL, ISIMA
1. Génie Logiciel
4
Plan
• Pourquoi avons-nous besoin du génie logiciel ?
• Les problèmes liés à la conception de logiciels
• Les qualités d’un bon logiciel
• L’évolution de la programmation au cours des
âges
5
But : améliorer la qualité des
logiciels
• Utilisateurs
 Logiciel répondant bien aux besoins
 Fiable et sûr
 Bonne documentation
• Développeurs
 Logiciel facile à faire évoluer et à maintenir
 Bonne documentation
6
Génie logiciel
• Résoudre les problèmes liés à la complexité
  Coûts de développement et de maintenance
 Obtenir des logiciels satisfaisants pour tous
• Comment ?
 Maîtriser la conception d’un logiciel
 Prévoir son évolution
• Outil fondamental : l'abstraction
• Problème : subjectivité de l’abstraction
7
Facteurs de qualité
• Fiable
 dès la conception !
• Efficace
• Modifiable
• Intelligible
• Interopérable
8
#include <stdio.h>
#include <math.h>
#include <unistd.h>
#include <sys/ioctl.h>
main() {
short a[4];ioctl
(0,TIOCGWINSZ,&a);int
b,c,d=*a,e=a[1];float f,g,
h,i=d/2+d%2+1,j=d/5-1,k=0,l=e/
2,m=d/4,n=.01*e,o=0,p=.1;while (
printf("x1b[Hx1B[?25l"),!usleep(
79383)){for (b=c=0;h=2*(m-c)/i,f=-
.3*(g=(l-b)/i)+.954*h,c<d;c+=(b=++
b%e)==0)printf("x1B[%dm ",g*g>1-h
*h?c>d-j?b<d-c||d-c>e-b?40:100:b<j
||b>e-j?40:g*(g+.6)+.09+h*h<1?100:
47:((int)(9-k+(.954*g+.3*h)/sqrt
(1-f*f))+(int)(2+f*2))%2==0?107
:101);k+=p,m+=o,o=m>d-2*j?
-.04*d:o+.002*d;n=(l+=
n)<i||l>e-i?p=-p
,-n:n;}}
Ce qu’il ne faut pas faire ….
Peter Eastman
IOCCC 2011
9
Réutilisabilité (1)
• Temps de développement
 Ne pas réinventer la roue à chaque étape
 Même algorithme sous diverses formes
• Différents langages de programmation
• Différentes structures de données
• Différents environnements
• Obstacles
 Documentation inadéquate
 Problèmes de diffusion
 Interfaçage avec le code local
10
Réutilisabilité (2)
• Avantages
 Plus un code est utilisé, plus il devient fiable
 Détection précoce des bogues et manquements
• Coûts de maintenance inférieurs
• Un module validé n’a plus à être vérifié !
• Réutiliser le code c’est bien ...
• Réutiliser la conception c’est mieux !
 Éliminer certaines étapes de conception sur des problèmes
semblables
 Englober en une unité fonctionnelle unique les travaux de
conception et d’implémentation
11
Evolution du logiciel
• L’époque héroïque
• Les premiers langages évolués
• La notion de sous-programme
• La programmation modulaire
• Les types abstraits de données
• Les objets
12
L’époque héroïque
• Ordinateurs peu nombreux et réservés aux
institutions gouvernementales
 Peu de choses demandées aux ordinateurs
 Interface sommaire voire inexistante
 Petits programmes en langage machine puis en
assembleur
 Un seul concepteur ou une très petite équipe
IBM Mark I
13
mov ah, 00h
mov al, 13h
int 10h
mov ax,0a000h
mov es,ax
mov ax,320
mul 100
add ax,160
mov di,ax
mov al, 255
mov es:[di],al
0100010001010010
0001000111001110
1111010001010100
0101010010000101
1111000010101001
1010100101011010
1011101011111000
0101010101010101
1011011111110100
1010101010101010
0101010101111101
1001010101010101
Les ordinateurs se démocratisent
• Formalismes plus simples
 Premiers langages structurés (FORTRAN)
 Règne du « spaghetti »
• Programmes plus ambitieux
 Premières équipes de travail
 Découpage en plusieurs programmes reliés
 Premiers problèmes liés à la communication
•Découpage / Interfaçage
• Première idée : abstraction de l’implémentation =
description des interfaces
14
15
PL(I,J)=(2*I-1)*4*PL(I-1,J)/I-(I-1)*PL(I-2,J)/I
http://pagesperso.lina.univ-nantes.fr/info/perso/permanents/vailly/Enseignement/EMIAGE/EnDev/ModuleA206EMiageV2.4/c2/A206_2.html
16
Sous-programme (1)
• Motivation :
 traitement des tâches apparaissant de manière
répétitive dans les programmes
• Boîte noire
 L’utilisateur ne connaît que le prototype :
• Paramètres
• Fonctionnalités
17
Sous-programme (2)
• Abstraction procédurale
 Tout appel de sous programme apparaît atomique
• Problèmes :
 Nommage des identificateurs
 Collisions possibles entre les identificateurs de
l’utilisateur et ceux des sous-programmes.
18
Module (1)
• Apparition de "gros" logiciels de gestion
• Chaque module lié à une fonctionnalité
 gestion client, gestion compte, …
• Communication par messages
• Extension naturelle des sous-programmes
19
Module (2)
• Entité indépendante regroupant les sous-programmes et les
données sur lesquelles ils travaillent
 Séparation entre partie publique et partie privée
 La partie publique définit l’interface ou contrat d’utilisation
• Problèmes majeurs
 Impossible de dupliquer un module
 Une seule copie des données sur lesquelles un module est capable
de travailler
 Attention au découpage ! il est tentant de vouloir faire des
modules trop petits et de perdre ainsi en efficacité
20
Type abstrait de données (1)
• Abstraction des données
• Structure de données avec traitements associés
• Apparition du schéma modèle/instance
 Autant d’instances que nécessaire :
 Les données sont dupliquées
• Notion d’interface / contrat
 Liste des opérations disponibles
 Implémentation cachée des données
"On connaît une donnée au travers
des opérations disponibles dessus"
Type abstrait de données (2)
La pile
21
Sommet ?
créer()
empiler()
dépiler()
estVide()
Autres exemples : une file, une liste chaînée …
2. Concepts objets
23
Plan
• Définitions
 Objet
 Classe
• Notation (UML)
• Relations
 Héritage
 Agrégation
 Association
24
Réification ?
Définition
Un objet est une capsule logicielle oblative
avec un tropisme conatif dont l’hétéronomie
est la marque de la durée de l’éphémère et
de la hoirie !
25
-- Serge Miranda, Université de Nice
26
Objet
• Entité cohérente rassemblant des données
et le code travaillant sur ces données
• Données :
 Attributs
 Données membres
• Code :
 Méthodes
27
Classe
• Moule / Modèle / Fabrique à objets :
 donnée qui décrit des objets
• Expression de la notion de classe
d’équivalence
• Comment représenter ?
 Unified Modeling Language
Représentation UML
28
Voiture
# NombreDeVoitures : entier
# Marque : chaine
# Immatriculation : chaîne
# VitesseCourante : réel
# VitesseMaximale : réel
+ démarrer()
+ accélérer(pourcentage : réel)
+ arrêter()
+ reculer()
+ Créer une voiture()
+ Détruire une voiture()
Nom de la classe
Description des attributs
ou données membres
Description des méthodes = code
associé aux données
29
Relation d’instanciation
• Permet d’obtenir un objet à partir de la classe
 La classe décrit un objet
• Données membres
• Méthodes
 L’objet est un état de la classe
• Tous les objets d ’une même classe ont la même structure
• Les données prennent des valeurs significatives pour un
objet particulier
• C’est une instance de la classe
30
Exemples d’instanciation
Voiture
# NombreDeVoitures : entier
# Marque : chaine
# Immatriculation : chaîne
# VitesseCourante : réel
# VitesseMaximale : réel
# Couleur : Gamme
+ démarrer()
+ accélérer(pourcentage : réel)
+ arrêter()
+ reculer()
+ Créer une voiture()
+ Détruire une voiture()
Classe Instances
Instanciation
"Porsche"
"ISI 063 FAST"
180.1
270.0
"Renault"
"ISI 063 NORM"
50.0
160.0
31
Membres de classe/instance (1)
• Attributs d’instance = une valeur par objet
 vitesse d’un véhicule
 couleur d’un véhicule
• Attributs de classe = partagés par tous les objets d’une
même classe
 nombre de véhicules présents à un instant donné
 gamme de couleurs disponibles
32
Membres de classe/instance (2)
• Méthode d’instance = agit sur un objet particulier
 Accélérer, freiner
 Donner la vitesse courante
 Donner la couleur
• Méthode de classe = agit sur toute la classe
 Créer ou détruire une voiture
 Donner la gamme de couleurs disponibles
 Donner le nombre de voitures créées
33
Principe d’encapsulation (1)
• Séparation forte Interface/Implémentation
• Interface = partie visible d ’un objet
 Ensemble de messages paramétrés
 Communiquer avec un objet
= envoi de messages
= appel direct de méthode (en pratique)
• Implémentation cachée
 Attributs / Méthodes
 Implémentation d’un objet modifiable sans que l’utilisateur
ne s’en aperçoive : il suffit de ne pas modifier l’interface
34
Principe d’encapsulation (2)
• Abstraction procédurale
Un appel de message est atomique
 Les objets agissent comme des boîtes noires
 L’utilisateur n’a aucun contrôle sur les traitements associés
à son message
• Abstraction de données
Un objet n’est accessible que via ses messages
 L’utilisateur n’a aucun renseignement sur la structure
interne d’un objet
Principe d'encapsulation (3)
35
attributs
méthodes
privées
méthodes
publiques
interface
messages
Implémentation
Privée
Interface
Publique
36
Principe de Demeter
• On ne parle qu'à ses amis !
• Une méthode accède exclusivement aux éléments
suivants :
 Ses arguments et les variables temporaires créés qu'elle crée
 Les attributs de l’objet courant
 Les attributs de la classe de l’objet courant
 Les variables globales
37
Des interfaces multiples ?
• Certains langages permettent à un objet de disposer
de plusieurs interfaces
Choix d’interface avant d’accéder aux messages
Chef de projetDéveloppeurs Big boss
38
Notion de logiciel orienté objet
• Collection d’objets en interaction !
Une nouvelle abstraction : l’exécution
Un système d’objets doit toujours donner l’impression
d’être monolithique
• Un objet cible peut être :
 Situé sur la machine courante ou distante
 Actif / en sauvegarde (persistance) / pas encore
créé
39
Créer un logiciel orienté objet (1)
• 5 grands principes de BOOCH
1. Décomposable
 Partitionner le logiciel en modules d’objets
indépendants ne nécessitant que de connaître les
interfaces
2. (Re)Composable
 Les différents modules doivent pouvoir s’assembler
pour former de nouveaux modules
40
Créer un logiciel orienté objet (2)
3. Compréhensible
 Fondé sur la qualité de la documentation
 Chaque module doit pouvoir être compris par une
personne n’appartenant pas à son équipe de
développement.
 Les dépendances entre modules doivent être claires
41
Créer un logiciel orienté objet (3)
4. Continu
 Un changement faible de spécification doit
entraîner le minimum de modifications dans les
modules
5. Protégé
 Lorsqu’une erreur apparaît dans un module, celui-ci
doit s’en rendre compte et avertir les autres
42
Typage des objets
• une classe = un type
• Deux catégories de langages à objets
 Typage fort (et statique)
[C++ , JAVA]
 Typage faible (et dynamique)
[Objective C, Javascript, PHP]
43
Typage fort (et statique)
• Un objet est affecté à une classe à la compilation
• Vérification de l’adéquation objet/message à la
compilation
• Impossible d’envoyer un message non traitable
• Facile à déboguer et à mettre au point
• L’information de type est liée au nom (identificateur)
de l’objet et donc à son adresse mémoire
44
Typage faible (et dynamique)
• L’information est liée non à l’adresse mais au contenu
de l’objet
• Possible de modifier le typage de l’objet au cours du
temps
• Grande souplesse notamment lors du prototypage
d’une application
• Vérification de l’adéquation objet/message à
l ’exécution
 Erreur
 Transmission ou délégation vers un autre objet
45
Les relations fondamentales
• Héritage
Concept de Généralisation/spécialisation
Relation : Est une version spécialisée de (Is A)
• Composition / agrégation
Concept de composition
Relation : Contient, regroupe, possède (Has A)
• Association
Concept d’objets communiquants
Relation : communique avec (Uses A)
46
Héritage
• Concept naturel de
Généralisation / Spécialisation
 classes représentées sous forme d’arbres généalogiques
• Vocabulaire :
 Classe spécialisée : sous classe, classe fille, classe dérivée
 Classe générale : super classe, classe mère
 La classe spécialisée dérive de sa classe mère
• Idée fondamentale :
 La sous classe hérite de toutes les méthodes et tous les attributs
de sa classe mère auxquels elle rajoute les siens
M
F
47
Forme
# NombreDeFormes : entier
# couleur : Couleur
# x : entier
# y : entier
+ afficher()
+ getX() : entier
+ setX( valeur : entier)
+ Créer une forme()
+ Détruire une forme()
Rectangle
# largeur : entier
# hauteur : entier
+ afficher()
+ Créer un rectangle()
+ Détruire un rectangle()
Cercle
# rayon : entier
+ afficher()
+ Créer un cercle()
+ Détruire un cercle()
Concept de base
Concepts
spécialisés
Omission des
getters/setters
Une classe Point ?
48
Propriétés de la classe fille
• Reprend les caractéristiques de la super classe
 Attributs
 Méthodes
• Ajoute les siennes
 Attributs (instance ou classe)
 Méthode (instance ou classe)
• Possibilité de répondre à de nouveaux messages
• Possibilité de répondre de manière différente aux
messages de la super classe
49
Comment travailler avec l’héritage ?
• Construire un système ex nihilo
 Identifier tous les composants
 Procéder par généralisation en factorisant les
caractéristiques communes
• Etendre un système
 Ajouter les nouvelles classes dans le graphe
d’héritage en identifiant les différences avec les
classes existantes
 « programmation différentielle »
50
Un parc de véhicules
• On souhaite fournir un modèle de parc de véhicules
pouvant fournir :
 des voitures
 des camions
 des bateaux
 des hélicoptères
• Tous sont des véhicules
 Factorisation au plus haut par une classe Véhicule
 Les voitures et les camions sont des véhicules terrestres
pouvant découler d’une même classe
51
VéhiculeRoulant
Véhicule
Modélisation possible d'un parc
hétérogène de véhicules
Ajouter un avion ???
52
VéhiculeRoulant
Véhicule
Première approche
53
VéhiculeRoulant
Véhicule
Deuxième approche
VéhiculeVolant
54
Classe abstraite
• Modélisation d’un concept plutôt que d’objets réels
 Pas d’instance
 Définit des méthodes abstraites
• Pas d’implémentation : uniquement une spécification
 Peut définir des attributs
• Utilisée comme super classe d’une hiérarchie
 Exemples : Véhicule, Forme
 Aucun intérêt d’avoir des instances  classes dérivées
• Définit un cadre de travail pour le polymorphisme
 Une même méthode prend plusieurs formes !
55
Polymorphisme
• Forme faible
 Surcharge de méthode – overloading
 Méthodes de signatures différentes
Voiture
+ avancer(temps : entier)
+ avancer(distance : réel)
Voiture
+ afficher();
Véhicule
+ afficher();
• Forme forte
 Redéfinition – overriding
 Actions différentes pour des classes d'une même hiérarchie
• Une même méthode prend plusieurs formes
56
Exemple (1)
• Méthode à différencier selon les objets graphiques [
Forme ] : l’affichage
• Code sans la notion d’objet :
Pour chaque forme :
Selon (TypeObjet)
cas CERCLE
AffichageCercle(Objet)
cas RECTANGLE
AffichageRectangle(Objet)
Fin Selon
Fin Pour
57
Exemple (2)
• Des méthodes spécifiques
• Chaque classe définit le comportement qui lui est
propre
• Elle peut hériter du code de la classe mère si bon lui
semble
• Code très simplifié :
Pour chaque forme :
[ objet Afficher]
Fin Pour
Mise en œuvre
58
méthode 1
méthode 2
…
…
méthode n
Afficher
méthode 1
méthode 2
…
…
méthode n
Afficher
méthode 1
méthode 2
…
…
méthode n
Afficher
Cercle
Ligne
Carré
pour chaque objet de la collection
[objet Afficher]
fin Pour
[cercle Afficher]
[ligne Afficher]
[carré Afficher]
objets de classeobjets code
ligne
carré
cercle
59
Avantages de l’héritage (1)
• Partage de code
 Réutilisabilité
 Fiabilité
 Le code des classes les plus hautes dans la
hiérarchie est utilisé le plus souvent : il gagne vite
en fiabilité
• Modélisation d’un concept très naturel
60
Avantages de l’héritage (2)
• Taille de code source plus faible (factorisation)
• Maintenance facilitée
 Modifier l’interface d’une classe dérivée n’impose
pas de recompiler toutes celles qui sont au dessus
 Modifier l’implémentation d’une classe n’impose
pas de recompiler la hiérarchie
61
Dangers de l’héritage
(1)
Base
Intermédiaire 1
Intermédiaire 2
Feuille 2 Feuille 3
Exemple d'une classe
intermédiaire superfétatoire
(Intermédiaire 1)
Feuille 1
• Attention à la hiérarchie !
• Trop lourde, elle nuit à l’efficacité
du code !
Dangers de l’héritage (2)
62
• Violation du principe d’encapsulation
 Règle : transmission intégrale
de la mère à la fille
 Erreurs sémantiques
( Manchot / penguin )
• Héritage sélectif avec
certains langages !
voler()
Choisir les méthodes ou
les attributs à faire hériter
63
Dangers de l’héritage (3)
• Héritage de construction
 Rajouter des méthodes sans conserver la notion de
généralisation/spécialisation
• Dériver rectangle de ligne en rajoutant une largeur
 Dériver là où une différence d’attribut suffirait
• Dériver des animaux en fonction de la couleur du pelage
 manque de discrimination fonctionnelle
Héritage multiple
• Modélisation de principes naturels
• Risques de collision de noms sur les classes parent
 Certains langages permettent de préfixer les noms des membres
• Se transforme très rapidement en héritage à répétition !
64
• Plusieurs super classes pour
une même sous classe !
65
Héritage
à répétition
• Duplication de V dans H
 (une fois via B et une fois via A)
 avancer() ?
 Immatriculation ?
• Très fréquent avec les
bibliothèques
• Mécanismes spécifiques (C++)
+ avancer()
Véhicule
avancer() ?
- immatriculation
ISI - 63 - FR
V
B A
H ISI - 63 - FR
Interface
• Formalisation de la notion d'interface
 Ensemble de méthodes virtuelles
 Similaire à une classe abstraite sans attribut
 Comportement de la classe
• Vocabulaire :
 Une classe implémente une interface
• Interfaces multiples
 Alternative à l’héritage multiple !
66
I
C
67
+ flotter()
+ avancer()
<<interface>>
Flottant
pas de conflit
+ avancer()
Véhicule
étend
implémente
étend
• Complémentarité de
l'héritage simple et
interfaces multiples
 Hériter du concept
primordial
 Implémenter des
interfaces
68
Radar Avion
Interface
Détecteur
Interface
MachineVolante
• Solution ?
 Besoins du logiciel
 Culture du concepteur
Composition / Agrégation
• Modélisation de la relation « est composé de »
 Composition, appartenance, groupage, « Has A »
• Composition
 Les constituants disparaissent avec le composé
• Agrégation
 Les composants survivent à l'agrégat
• Modélisation des conteneurs
• Notion de cardinalité
 Simple / multiple
69
70
Moteur Chassis Roue
Voiture
4
111
1
1
Cardinalités :
Une voiture agrège
quatre roues
Agrégateur
Objet agrégé
71
Alternative à l’héritage multiple ?
1
1
1 1
1
1
1 1
72
Association
• Modélise des concepts assez flous
 Uses A
 Est en association avec
 Communique avec
• Caractéristiques
 Habituellement nommée (auto documentation)
 Sens
 Cardinalités : 1 .. 4
• Souvent difficile à différencier de l’agrégation
 Concepts voisins
 Même implémentation
73
ZOO – V1
Zoo
Animal
Cage Gardien
1
*
1
*
1
*
*
*
nourrit
1
*
habite
*nettoie*
74
ZOO – V2
Zoo
Animal
Cage Gardien
1
*
1
*
*
*
nourrit
1
*
*nettoie*
70
80
90
60
généricité, exceptions
opérateurs
classes
base
Simula
Pascal
Algol
C
Smalltalk
Objective C
Eiffel
Delphi
Ada
Java
C++
C#Quelques langages…
Visibilité des attributs et des
méthodes en UML ?
+ public : tout le monde
 Méthodes de l'interface publique
- privé : classe seulement
 Attributs
 Méthodes privées
# protégé
 Privé pour l'extérieur - Attributs
 Transmis par héritage
 Notion dépendante du langage
~ package
76
Fourmi ZZ ?
77
Fourmiliere
+travailler()
+manger(entrée quantite : unsigned int)
-energie : unsigned int
-id : unsigned int
-energieMax : unsigned int = 10
Fourmi
+nourrirFourmi(entrée inFourmi : Fourmi &)
OuvriereReine
1 *
*
*

Contenu connexe

Tendances

Javascript un langage supérieur
Javascript un langage supérieurJavascript un langage supérieur
Javascript un langage supérieur
Fredy Fadel
 
Cours JavaScript
Cours JavaScriptCours JavaScript
Cours JavaScript
Olivier Le Goaër
 
Les fondamentaux du langage C
Les fondamentaux du langage CLes fondamentaux du langage C
Les fondamentaux du langage C
Abdoulaye Dieng
 
Javascript pour les Développeurs WEB
Javascript pour les Développeurs WEBJavascript pour les Développeurs WEB
Javascript pour les Développeurs WEB
Abbes Rharrab
 
Python avancé : Ensemble, dictionnaire et base de données
Python avancé : Ensemble, dictionnaire et base de donnéesPython avancé : Ensemble, dictionnaire et base de données
Python avancé : Ensemble, dictionnaire et base de données
ECAM Brussels Engineering School
 
Python For Data Science - French Course
Python For Data Science - French CoursePython For Data Science - French Course
Python For Data Science - French Course
Haytam EL YOUSSFI
 
Environnement de développement de bases de données
Environnement de développement de bases de donnéesEnvironnement de développement de bases de données
Environnement de développement de bases de données
ISIG
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
ECAM Brussels Engineering School
 
Initiation à l'algorithmique
Initiation à l'algorithmiqueInitiation à l'algorithmique
Initiation à l'algorithmique
Abdoulaye Dieng
 
Présentation de ECMAScript 6
Présentation de ECMAScript 6Présentation de ECMAScript 6
Présentation de ECMAScript 6
Julien CROUZET
 
Environnement de développement de bases de données
Environnement de développement de bases de donnéesEnvironnement de développement de bases de données
Environnement de développement de bases de données
ISIG
 
Programmation événementielle avec VB (ISIG)
Programmation événementielle avec VB (ISIG)Programmation événementielle avec VB (ISIG)
Programmation événementielle avec VB (ISIG)
ISIG
 
Cours VB 2012 seance 1
Cours VB 2012 seance 1Cours VB 2012 seance 1
Cours VB 2012 seance 1
ISIG
 
Vbisigk
VbisigkVbisigk
Vbisigk
ISIG
 
Développement de plug in sous eclipse
Développement de plug in sous eclipseDéveloppement de plug in sous eclipse
Développement de plug in sous eclipse
ISIG
 
Csharp1 : quelques elements de base
Csharp1 :  quelques elements de baseCsharp1 :  quelques elements de base
Csharp1 : quelques elements de base
Abdoulaye Dieng
 
Introduction à Python
Introduction à PythonIntroduction à Python
Introduction à Python
Abdoulaye Dieng
 
Visual studio
Visual studioVisual studio
Visual studio
ISIG
 
Nouveautés JavaScript dans le monde Microsoft
Nouveautés JavaScript dans le monde MicrosoftNouveautés JavaScript dans le monde Microsoft
Nouveautés JavaScript dans le monde Microsoft
davrous
 
Polymorphisme, interface et classe abstraite
Polymorphisme, interface et classe abstraitePolymorphisme, interface et classe abstraite
Polymorphisme, interface et classe abstraite
ECAM Brussels Engineering School
 

Tendances (20)

Javascript un langage supérieur
Javascript un langage supérieurJavascript un langage supérieur
Javascript un langage supérieur
 
Cours JavaScript
Cours JavaScriptCours JavaScript
Cours JavaScript
 
Les fondamentaux du langage C
Les fondamentaux du langage CLes fondamentaux du langage C
Les fondamentaux du langage C
 
Javascript pour les Développeurs WEB
Javascript pour les Développeurs WEBJavascript pour les Développeurs WEB
Javascript pour les Développeurs WEB
 
Python avancé : Ensemble, dictionnaire et base de données
Python avancé : Ensemble, dictionnaire et base de donnéesPython avancé : Ensemble, dictionnaire et base de données
Python avancé : Ensemble, dictionnaire et base de données
 
Python For Data Science - French Course
Python For Data Science - French CoursePython For Data Science - French Course
Python For Data Science - French Course
 
Environnement de développement de bases de données
Environnement de développement de bases de donnéesEnvironnement de développement de bases de données
Environnement de développement de bases de données
 
Qualité de code et bonnes pratiques
Qualité de code et bonnes pratiquesQualité de code et bonnes pratiques
Qualité de code et bonnes pratiques
 
Initiation à l'algorithmique
Initiation à l'algorithmiqueInitiation à l'algorithmique
Initiation à l'algorithmique
 
Présentation de ECMAScript 6
Présentation de ECMAScript 6Présentation de ECMAScript 6
Présentation de ECMAScript 6
 
Environnement de développement de bases de données
Environnement de développement de bases de donnéesEnvironnement de développement de bases de données
Environnement de développement de bases de données
 
Programmation événementielle avec VB (ISIG)
Programmation événementielle avec VB (ISIG)Programmation événementielle avec VB (ISIG)
Programmation événementielle avec VB (ISIG)
 
Cours VB 2012 seance 1
Cours VB 2012 seance 1Cours VB 2012 seance 1
Cours VB 2012 seance 1
 
Vbisigk
VbisigkVbisigk
Vbisigk
 
Développement de plug in sous eclipse
Développement de plug in sous eclipseDéveloppement de plug in sous eclipse
Développement de plug in sous eclipse
 
Csharp1 : quelques elements de base
Csharp1 :  quelques elements de baseCsharp1 :  quelques elements de base
Csharp1 : quelques elements de base
 
Introduction à Python
Introduction à PythonIntroduction à Python
Introduction à Python
 
Visual studio
Visual studioVisual studio
Visual studio
 
Nouveautés JavaScript dans le monde Microsoft
Nouveautés JavaScript dans le monde MicrosoftNouveautés JavaScript dans le monde Microsoft
Nouveautés JavaScript dans le monde Microsoft
 
Polymorphisme, interface et classe abstraite
Polymorphisme, interface et classe abstraitePolymorphisme, interface et classe abstraite
Polymorphisme, interface et classe abstraite
 

Similaire à Introduction à l'objet - Deuxième année ISIMA

Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
linasafaa
 
Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8
Arnaud Auroux
 
CoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalCoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-Total
Ahmed Mekkaoui
 
DDD FOR POs.pdf
DDD FOR POs.pdfDDD FOR POs.pdf
DDD FOR POs.pdf
Guillaume Saint Etienne
 
Lmo02.ppt
Lmo02.pptLmo02.ppt
Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4
Laurent BUNIET
 
Windev
WindevWindev
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
guest0032c8
 
Réussir son projet Drupal
Réussir son projet DrupalRéussir son projet Drupal
Réussir son projet Drupal
Adyax
 
Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022
Laurent Guérin
 
Projet+com02.ppt
Projet+com02.pptProjet+com02.ppt
Projet+com02.ppt
Yann-Gaël Guéhéneuc
 
python-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdfpython-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdf
trendingv83
 
Cours génie logiciel
Cours génie logicielCours génie logiciel
Cours génie logiciel
araddaoui
 
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
ekino
 
Plasticitérecherche2017
Plasticitérecherche2017Plasticitérecherche2017
Plasticitérecherche2017
Anne-Marie Pinna-Dery
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven Design
DNG Consulting
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
Normandy JUG
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
Mohamed Diallo
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
Clement Bouillier
 

Similaire à Introduction à l'objet - Deuxième année ISIMA (20)

Uml partie 1
Uml partie 1Uml partie 1
Uml partie 1
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
 
Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8
 
CoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-TotalCoursUML-SlimMesfar-Total
CoursUML-SlimMesfar-Total
 
DDD FOR POs.pdf
DDD FOR POs.pdfDDD FOR POs.pdf
DDD FOR POs.pdf
 
Lmo02.ppt
Lmo02.pptLmo02.ppt
Lmo02.ppt
 
Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4Cours de C++, en français, 2002 - Cours 1.4
Cours de C++, en français, 2002 - Cours 1.4
 
Windev
WindevWindev
Windev
 
Introduction au Génie Logiciel
Introduction au Génie LogicielIntroduction au Génie Logiciel
Introduction au Génie Logiciel
 
Réussir son projet Drupal
Réussir son projet DrupalRéussir son projet Drupal
Réussir son projet Drupal
 
Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022Microservices-DDD-Telosys-Devoxx-FR-2022
Microservices-DDD-Telosys-Devoxx-FR-2022
 
Projet+com02.ppt
Projet+com02.pptProjet+com02.ppt
Projet+com02.ppt
 
python-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdfpython-Cours Officiel POO Python-m103.pdf
python-Cours Officiel POO Python-m103.pdf
 
Cours génie logiciel
Cours génie logicielCours génie logiciel
Cours génie logiciel
 
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
Drupagora 2013 : Drupal8 et Symfony2, quel impact ?
 
Plasticitérecherche2017
Plasticitérecherche2017Plasticitérecherche2017
Plasticitérecherche2017
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven Design
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
Introduction au génie logiciel
Introduction au génie logicielIntroduction au génie logiciel
Introduction au génie logiciel
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 

Dernier

apprendre-a-programmer-avec-python-3.pdf
apprendre-a-programmer-avec-python-3.pdfapprendre-a-programmer-avec-python-3.pdf
apprendre-a-programmer-avec-python-3.pdf
kamouzou878
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
NadineHG
 
Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
Friends of African Village Libraries
 
A2-Critiques-gastronomiques activités critiques
A2-Critiques-gastronomiques activités critiquesA2-Critiques-gastronomiques activités critiques
A2-Critiques-gastronomiques activités critiques
lebaobabbleu
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
Txaruka
 
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
dokposeverin
 
Microbiologie: le monde microbien et les techniques de mise en évidence.
Microbiologie: le monde microbien et les techniques de mise en évidence.Microbiologie: le monde microbien et les techniques de mise en évidence.
Microbiologie: le monde microbien et les techniques de mise en évidence.
MahouwetinJacquesGBO
 
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
mcevapi3
 
Formation M2i - Attitude constructive : développer l'art de l'optimisme
Formation M2i - Attitude constructive : développer l'art de l'optimismeFormation M2i - Attitude constructive : développer l'art de l'optimisme
Formation M2i - Attitude constructive : développer l'art de l'optimisme
M2i Formation
 
A2-Faire-une-appreciation positive et/ou négative (A2)
A2-Faire-une-appreciation positive et/ou négative (A2)A2-Faire-une-appreciation positive et/ou négative (A2)
A2-Faire-une-appreciation positive et/ou négative (A2)
lebaobabbleu
 
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptxMARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
Martin M Flynn
 
Cours Gestion d’actifs BNP -- CAMGESTION
Cours Gestion d’actifs BNP -- CAMGESTIONCours Gestion d’actifs BNP -- CAMGESTION
Cours Gestion d’actifs BNP -- CAMGESTION
Sékou Oumar SYLLA
 
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaPrésentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
siemaillard
 
MS-203 Microsoft 365 Messaging Study Guide to prepare the certification
MS-203 Microsoft 365 Messaging Study Guide to prepare the certificationMS-203 Microsoft 365 Messaging Study Guide to prepare the certification
MS-203 Microsoft 365 Messaging Study Guide to prepare the certification
OlivierLumeau1
 

Dernier (14)

apprendre-a-programmer-avec-python-3.pdf
apprendre-a-programmer-avec-python-3.pdfapprendre-a-programmer-avec-python-3.pdf
apprendre-a-programmer-avec-python-3.pdf
 
1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire1eT Revolutions Empire Revolution Empire
1eT Revolutions Empire Revolution Empire
 
Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024Burkina Faso libraries newsletter for June 2024
Burkina Faso libraries newsletter for June 2024
 
A2-Critiques-gastronomiques activités critiques
A2-Critiques-gastronomiques activités critiquesA2-Critiques-gastronomiques activités critiques
A2-Critiques-gastronomiques activités critiques
 
Zineb Mekouar.pptx Écrivaine marocaine
Zineb Mekouar.pptx   Écrivaine  marocaineZineb Mekouar.pptx   Écrivaine  marocaine
Zineb Mekouar.pptx Écrivaine marocaine
 
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
Manuel-5.-Elevage-de-poisson-chat-africain-Clarias-gariepinus-en-bacs-hors-so...
 
Microbiologie: le monde microbien et les techniques de mise en évidence.
Microbiologie: le monde microbien et les techniques de mise en évidence.Microbiologie: le monde microbien et les techniques de mise en évidence.
Microbiologie: le monde microbien et les techniques de mise en évidence.
 
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
[218_phot_d'Autriche-Hongrie_et_des_[...]Vaffier_Hubert_btv1b8594559c.pdf
 
Formation M2i - Attitude constructive : développer l'art de l'optimisme
Formation M2i - Attitude constructive : développer l'art de l'optimismeFormation M2i - Attitude constructive : développer l'art de l'optimisme
Formation M2i - Attitude constructive : développer l'art de l'optimisme
 
A2-Faire-une-appreciation positive et/ou négative (A2)
A2-Faire-une-appreciation positive et/ou négative (A2)A2-Faire-une-appreciation positive et/ou négative (A2)
A2-Faire-une-appreciation positive et/ou négative (A2)
 
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptxMARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
MARTYRS DE HOLLANDE - La révolte hollandaise et les guerres de religion..pptx
 
Cours Gestion d’actifs BNP -- CAMGESTION
Cours Gestion d’actifs BNP -- CAMGESTIONCours Gestion d’actifs BNP -- CAMGESTION
Cours Gestion d’actifs BNP -- CAMGESTION
 
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaPrésentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Présentation3.pptxaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 
MS-203 Microsoft 365 Messaging Study Guide to prepare the certification
MS-203 Microsoft 365 Messaging Study Guide to prepare the certificationMS-203 Microsoft 365 Messaging Study Guide to prepare the certification
MS-203 Microsoft 365 Messaging Study Guide to prepare the certification
 

Introduction à l'objet - Deuxième année ISIMA

  • 2. 2 Plan 1. Génie logiciel et historique 2. Concepts objets Ces transparents ont été conçus originellement par Bruno-Laurent GARCIA, ISIMA Améliorations successives de David HILL et Christophe DUHAMEL, ISIMA
  • 4. 4 Plan • Pourquoi avons-nous besoin du génie logiciel ? • Les problèmes liés à la conception de logiciels • Les qualités d’un bon logiciel • L’évolution de la programmation au cours des âges
  • 5. 5 But : améliorer la qualité des logiciels • Utilisateurs  Logiciel répondant bien aux besoins  Fiable et sûr  Bonne documentation • Développeurs  Logiciel facile à faire évoluer et à maintenir  Bonne documentation
  • 6. 6 Génie logiciel • Résoudre les problèmes liés à la complexité   Coûts de développement et de maintenance  Obtenir des logiciels satisfaisants pour tous • Comment ?  Maîtriser la conception d’un logiciel  Prévoir son évolution • Outil fondamental : l'abstraction • Problème : subjectivité de l’abstraction
  • 7. 7 Facteurs de qualité • Fiable  dès la conception ! • Efficace • Modifiable • Intelligible • Interopérable
  • 8. 8 #include <stdio.h> #include <math.h> #include <unistd.h> #include <sys/ioctl.h> main() { short a[4];ioctl (0,TIOCGWINSZ,&a);int b,c,d=*a,e=a[1];float f,g, h,i=d/2+d%2+1,j=d/5-1,k=0,l=e/ 2,m=d/4,n=.01*e,o=0,p=.1;while ( printf("x1b[Hx1B[?25l"),!usleep( 79383)){for (b=c=0;h=2*(m-c)/i,f=- .3*(g=(l-b)/i)+.954*h,c<d;c+=(b=++ b%e)==0)printf("x1B[%dm ",g*g>1-h *h?c>d-j?b<d-c||d-c>e-b?40:100:b<j ||b>e-j?40:g*(g+.6)+.09+h*h<1?100: 47:((int)(9-k+(.954*g+.3*h)/sqrt (1-f*f))+(int)(2+f*2))%2==0?107 :101);k+=p,m+=o,o=m>d-2*j? -.04*d:o+.002*d;n=(l+= n)<i||l>e-i?p=-p ,-n:n;}} Ce qu’il ne faut pas faire …. Peter Eastman IOCCC 2011
  • 9. 9 Réutilisabilité (1) • Temps de développement  Ne pas réinventer la roue à chaque étape  Même algorithme sous diverses formes • Différents langages de programmation • Différentes structures de données • Différents environnements • Obstacles  Documentation inadéquate  Problèmes de diffusion  Interfaçage avec le code local
  • 10. 10 Réutilisabilité (2) • Avantages  Plus un code est utilisé, plus il devient fiable  Détection précoce des bogues et manquements • Coûts de maintenance inférieurs • Un module validé n’a plus à être vérifié ! • Réutiliser le code c’est bien ... • Réutiliser la conception c’est mieux !  Éliminer certaines étapes de conception sur des problèmes semblables  Englober en une unité fonctionnelle unique les travaux de conception et d’implémentation
  • 11. 11 Evolution du logiciel • L’époque héroïque • Les premiers langages évolués • La notion de sous-programme • La programmation modulaire • Les types abstraits de données • Les objets
  • 12. 12 L’époque héroïque • Ordinateurs peu nombreux et réservés aux institutions gouvernementales  Peu de choses demandées aux ordinateurs  Interface sommaire voire inexistante  Petits programmes en langage machine puis en assembleur  Un seul concepteur ou une très petite équipe
  • 13. IBM Mark I 13 mov ah, 00h mov al, 13h int 10h mov ax,0a000h mov es,ax mov ax,320 mul 100 add ax,160 mov di,ax mov al, 255 mov es:[di],al 0100010001010010 0001000111001110 1111010001010100 0101010010000101 1111000010101001 1010100101011010 1011101011111000 0101010101010101 1011011111110100 1010101010101010 0101010101111101 1001010101010101
  • 14. Les ordinateurs se démocratisent • Formalismes plus simples  Premiers langages structurés (FORTRAN)  Règne du « spaghetti » • Programmes plus ambitieux  Premières équipes de travail  Découpage en plusieurs programmes reliés  Premiers problèmes liés à la communication •Découpage / Interfaçage • Première idée : abstraction de l’implémentation = description des interfaces 14
  • 16. 16 Sous-programme (1) • Motivation :  traitement des tâches apparaissant de manière répétitive dans les programmes • Boîte noire  L’utilisateur ne connaît que le prototype : • Paramètres • Fonctionnalités
  • 17. 17 Sous-programme (2) • Abstraction procédurale  Tout appel de sous programme apparaît atomique • Problèmes :  Nommage des identificateurs  Collisions possibles entre les identificateurs de l’utilisateur et ceux des sous-programmes.
  • 18. 18 Module (1) • Apparition de "gros" logiciels de gestion • Chaque module lié à une fonctionnalité  gestion client, gestion compte, … • Communication par messages • Extension naturelle des sous-programmes
  • 19. 19 Module (2) • Entité indépendante regroupant les sous-programmes et les données sur lesquelles ils travaillent  Séparation entre partie publique et partie privée  La partie publique définit l’interface ou contrat d’utilisation • Problèmes majeurs  Impossible de dupliquer un module  Une seule copie des données sur lesquelles un module est capable de travailler  Attention au découpage ! il est tentant de vouloir faire des modules trop petits et de perdre ainsi en efficacité
  • 20. 20 Type abstrait de données (1) • Abstraction des données • Structure de données avec traitements associés • Apparition du schéma modèle/instance  Autant d’instances que nécessaire :  Les données sont dupliquées • Notion d’interface / contrat  Liste des opérations disponibles  Implémentation cachée des données "On connaît une donnée au travers des opérations disponibles dessus"
  • 21. Type abstrait de données (2) La pile 21 Sommet ? créer() empiler() dépiler() estVide() Autres exemples : une file, une liste chaînée …
  • 23. 23 Plan • Définitions  Objet  Classe • Notation (UML) • Relations  Héritage  Agrégation  Association
  • 25. Définition Un objet est une capsule logicielle oblative avec un tropisme conatif dont l’hétéronomie est la marque de la durée de l’éphémère et de la hoirie ! 25 -- Serge Miranda, Université de Nice
  • 26. 26 Objet • Entité cohérente rassemblant des données et le code travaillant sur ces données • Données :  Attributs  Données membres • Code :  Méthodes
  • 27. 27 Classe • Moule / Modèle / Fabrique à objets :  donnée qui décrit des objets • Expression de la notion de classe d’équivalence • Comment représenter ?  Unified Modeling Language
  • 28. Représentation UML 28 Voiture # NombreDeVoitures : entier # Marque : chaine # Immatriculation : chaîne # VitesseCourante : réel # VitesseMaximale : réel + démarrer() + accélérer(pourcentage : réel) + arrêter() + reculer() + Créer une voiture() + Détruire une voiture() Nom de la classe Description des attributs ou données membres Description des méthodes = code associé aux données
  • 29. 29 Relation d’instanciation • Permet d’obtenir un objet à partir de la classe  La classe décrit un objet • Données membres • Méthodes  L’objet est un état de la classe • Tous les objets d ’une même classe ont la même structure • Les données prennent des valeurs significatives pour un objet particulier • C’est une instance de la classe
  • 30. 30 Exemples d’instanciation Voiture # NombreDeVoitures : entier # Marque : chaine # Immatriculation : chaîne # VitesseCourante : réel # VitesseMaximale : réel # Couleur : Gamme + démarrer() + accélérer(pourcentage : réel) + arrêter() + reculer() + Créer une voiture() + Détruire une voiture() Classe Instances Instanciation "Porsche" "ISI 063 FAST" 180.1 270.0 "Renault" "ISI 063 NORM" 50.0 160.0
  • 31. 31 Membres de classe/instance (1) • Attributs d’instance = une valeur par objet  vitesse d’un véhicule  couleur d’un véhicule • Attributs de classe = partagés par tous les objets d’une même classe  nombre de véhicules présents à un instant donné  gamme de couleurs disponibles
  • 32. 32 Membres de classe/instance (2) • Méthode d’instance = agit sur un objet particulier  Accélérer, freiner  Donner la vitesse courante  Donner la couleur • Méthode de classe = agit sur toute la classe  Créer ou détruire une voiture  Donner la gamme de couleurs disponibles  Donner le nombre de voitures créées
  • 33. 33 Principe d’encapsulation (1) • Séparation forte Interface/Implémentation • Interface = partie visible d ’un objet  Ensemble de messages paramétrés  Communiquer avec un objet = envoi de messages = appel direct de méthode (en pratique) • Implémentation cachée  Attributs / Méthodes  Implémentation d’un objet modifiable sans que l’utilisateur ne s’en aperçoive : il suffit de ne pas modifier l’interface
  • 34. 34 Principe d’encapsulation (2) • Abstraction procédurale Un appel de message est atomique  Les objets agissent comme des boîtes noires  L’utilisateur n’a aucun contrôle sur les traitements associés à son message • Abstraction de données Un objet n’est accessible que via ses messages  L’utilisateur n’a aucun renseignement sur la structure interne d’un objet
  • 36. 36 Principe de Demeter • On ne parle qu'à ses amis ! • Une méthode accède exclusivement aux éléments suivants :  Ses arguments et les variables temporaires créés qu'elle crée  Les attributs de l’objet courant  Les attributs de la classe de l’objet courant  Les variables globales
  • 37. 37 Des interfaces multiples ? • Certains langages permettent à un objet de disposer de plusieurs interfaces Choix d’interface avant d’accéder aux messages Chef de projetDéveloppeurs Big boss
  • 38. 38 Notion de logiciel orienté objet • Collection d’objets en interaction ! Une nouvelle abstraction : l’exécution Un système d’objets doit toujours donner l’impression d’être monolithique • Un objet cible peut être :  Situé sur la machine courante ou distante  Actif / en sauvegarde (persistance) / pas encore créé
  • 39. 39 Créer un logiciel orienté objet (1) • 5 grands principes de BOOCH 1. Décomposable  Partitionner le logiciel en modules d’objets indépendants ne nécessitant que de connaître les interfaces 2. (Re)Composable  Les différents modules doivent pouvoir s’assembler pour former de nouveaux modules
  • 40. 40 Créer un logiciel orienté objet (2) 3. Compréhensible  Fondé sur la qualité de la documentation  Chaque module doit pouvoir être compris par une personne n’appartenant pas à son équipe de développement.  Les dépendances entre modules doivent être claires
  • 41. 41 Créer un logiciel orienté objet (3) 4. Continu  Un changement faible de spécification doit entraîner le minimum de modifications dans les modules 5. Protégé  Lorsqu’une erreur apparaît dans un module, celui-ci doit s’en rendre compte et avertir les autres
  • 42. 42 Typage des objets • une classe = un type • Deux catégories de langages à objets  Typage fort (et statique) [C++ , JAVA]  Typage faible (et dynamique) [Objective C, Javascript, PHP]
  • 43. 43 Typage fort (et statique) • Un objet est affecté à une classe à la compilation • Vérification de l’adéquation objet/message à la compilation • Impossible d’envoyer un message non traitable • Facile à déboguer et à mettre au point • L’information de type est liée au nom (identificateur) de l’objet et donc à son adresse mémoire
  • 44. 44 Typage faible (et dynamique) • L’information est liée non à l’adresse mais au contenu de l’objet • Possible de modifier le typage de l’objet au cours du temps • Grande souplesse notamment lors du prototypage d’une application • Vérification de l’adéquation objet/message à l ’exécution  Erreur  Transmission ou délégation vers un autre objet
  • 45. 45 Les relations fondamentales • Héritage Concept de Généralisation/spécialisation Relation : Est une version spécialisée de (Is A) • Composition / agrégation Concept de composition Relation : Contient, regroupe, possède (Has A) • Association Concept d’objets communiquants Relation : communique avec (Uses A)
  • 46. 46 Héritage • Concept naturel de Généralisation / Spécialisation  classes représentées sous forme d’arbres généalogiques • Vocabulaire :  Classe spécialisée : sous classe, classe fille, classe dérivée  Classe générale : super classe, classe mère  La classe spécialisée dérive de sa classe mère • Idée fondamentale :  La sous classe hérite de toutes les méthodes et tous les attributs de sa classe mère auxquels elle rajoute les siens M F
  • 47. 47 Forme # NombreDeFormes : entier # couleur : Couleur # x : entier # y : entier + afficher() + getX() : entier + setX( valeur : entier) + Créer une forme() + Détruire une forme() Rectangle # largeur : entier # hauteur : entier + afficher() + Créer un rectangle() + Détruire un rectangle() Cercle # rayon : entier + afficher() + Créer un cercle() + Détruire un cercle() Concept de base Concepts spécialisés Omission des getters/setters Une classe Point ?
  • 48. 48 Propriétés de la classe fille • Reprend les caractéristiques de la super classe  Attributs  Méthodes • Ajoute les siennes  Attributs (instance ou classe)  Méthode (instance ou classe) • Possibilité de répondre à de nouveaux messages • Possibilité de répondre de manière différente aux messages de la super classe
  • 49. 49 Comment travailler avec l’héritage ? • Construire un système ex nihilo  Identifier tous les composants  Procéder par généralisation en factorisant les caractéristiques communes • Etendre un système  Ajouter les nouvelles classes dans le graphe d’héritage en identifiant les différences avec les classes existantes  « programmation différentielle »
  • 50. 50 Un parc de véhicules • On souhaite fournir un modèle de parc de véhicules pouvant fournir :  des voitures  des camions  des bateaux  des hélicoptères • Tous sont des véhicules  Factorisation au plus haut par une classe Véhicule  Les voitures et les camions sont des véhicules terrestres pouvant découler d’une même classe
  • 51. 51 VéhiculeRoulant Véhicule Modélisation possible d'un parc hétérogène de véhicules Ajouter un avion ???
  • 54. 54 Classe abstraite • Modélisation d’un concept plutôt que d’objets réels  Pas d’instance  Définit des méthodes abstraites • Pas d’implémentation : uniquement une spécification  Peut définir des attributs • Utilisée comme super classe d’une hiérarchie  Exemples : Véhicule, Forme  Aucun intérêt d’avoir des instances  classes dérivées • Définit un cadre de travail pour le polymorphisme  Une même méthode prend plusieurs formes !
  • 55. 55 Polymorphisme • Forme faible  Surcharge de méthode – overloading  Méthodes de signatures différentes Voiture + avancer(temps : entier) + avancer(distance : réel) Voiture + afficher(); Véhicule + afficher(); • Forme forte  Redéfinition – overriding  Actions différentes pour des classes d'une même hiérarchie • Une même méthode prend plusieurs formes
  • 56. 56 Exemple (1) • Méthode à différencier selon les objets graphiques [ Forme ] : l’affichage • Code sans la notion d’objet : Pour chaque forme : Selon (TypeObjet) cas CERCLE AffichageCercle(Objet) cas RECTANGLE AffichageRectangle(Objet) Fin Selon Fin Pour
  • 57. 57 Exemple (2) • Des méthodes spécifiques • Chaque classe définit le comportement qui lui est propre • Elle peut hériter du code de la classe mère si bon lui semble • Code très simplifié : Pour chaque forme : [ objet Afficher] Fin Pour
  • 58. Mise en œuvre 58 méthode 1 méthode 2 … … méthode n Afficher méthode 1 méthode 2 … … méthode n Afficher méthode 1 méthode 2 … … méthode n Afficher Cercle Ligne Carré pour chaque objet de la collection [objet Afficher] fin Pour [cercle Afficher] [ligne Afficher] [carré Afficher] objets de classeobjets code ligne carré cercle
  • 59. 59 Avantages de l’héritage (1) • Partage de code  Réutilisabilité  Fiabilité  Le code des classes les plus hautes dans la hiérarchie est utilisé le plus souvent : il gagne vite en fiabilité • Modélisation d’un concept très naturel
  • 60. 60 Avantages de l’héritage (2) • Taille de code source plus faible (factorisation) • Maintenance facilitée  Modifier l’interface d’une classe dérivée n’impose pas de recompiler toutes celles qui sont au dessus  Modifier l’implémentation d’une classe n’impose pas de recompiler la hiérarchie
  • 61. 61 Dangers de l’héritage (1) Base Intermédiaire 1 Intermédiaire 2 Feuille 2 Feuille 3 Exemple d'une classe intermédiaire superfétatoire (Intermédiaire 1) Feuille 1 • Attention à la hiérarchie ! • Trop lourde, elle nuit à l’efficacité du code !
  • 62. Dangers de l’héritage (2) 62 • Violation du principe d’encapsulation  Règle : transmission intégrale de la mère à la fille  Erreurs sémantiques ( Manchot / penguin ) • Héritage sélectif avec certains langages ! voler() Choisir les méthodes ou les attributs à faire hériter
  • 63. 63 Dangers de l’héritage (3) • Héritage de construction  Rajouter des méthodes sans conserver la notion de généralisation/spécialisation • Dériver rectangle de ligne en rajoutant une largeur  Dériver là où une différence d’attribut suffirait • Dériver des animaux en fonction de la couleur du pelage  manque de discrimination fonctionnelle
  • 64. Héritage multiple • Modélisation de principes naturels • Risques de collision de noms sur les classes parent  Certains langages permettent de préfixer les noms des membres • Se transforme très rapidement en héritage à répétition ! 64 • Plusieurs super classes pour une même sous classe !
  • 65. 65 Héritage à répétition • Duplication de V dans H  (une fois via B et une fois via A)  avancer() ?  Immatriculation ? • Très fréquent avec les bibliothèques • Mécanismes spécifiques (C++) + avancer() Véhicule avancer() ? - immatriculation ISI - 63 - FR V B A H ISI - 63 - FR
  • 66. Interface • Formalisation de la notion d'interface  Ensemble de méthodes virtuelles  Similaire à une classe abstraite sans attribut  Comportement de la classe • Vocabulaire :  Une classe implémente une interface • Interfaces multiples  Alternative à l’héritage multiple ! 66 I C
  • 67. 67 + flotter() + avancer() <<interface>> Flottant pas de conflit + avancer() Véhicule étend implémente étend • Complémentarité de l'héritage simple et interfaces multiples  Hériter du concept primordial  Implémenter des interfaces
  • 68. 68 Radar Avion Interface Détecteur Interface MachineVolante • Solution ?  Besoins du logiciel  Culture du concepteur
  • 69. Composition / Agrégation • Modélisation de la relation « est composé de »  Composition, appartenance, groupage, « Has A » • Composition  Les constituants disparaissent avec le composé • Agrégation  Les composants survivent à l'agrégat • Modélisation des conteneurs • Notion de cardinalité  Simple / multiple 69
  • 70. 70 Moteur Chassis Roue Voiture 4 111 1 1 Cardinalités : Une voiture agrège quatre roues Agrégateur Objet agrégé
  • 71. 71 Alternative à l’héritage multiple ? 1 1 1 1 1 1 1 1
  • 72. 72 Association • Modélise des concepts assez flous  Uses A  Est en association avec  Communique avec • Caractéristiques  Habituellement nommée (auto documentation)  Sens  Cardinalités : 1 .. 4 • Souvent difficile à différencier de l’agrégation  Concepts voisins  Même implémentation
  • 73. 73 ZOO – V1 Zoo Animal Cage Gardien 1 * 1 * 1 * * * nourrit 1 * habite *nettoie*
  • 74. 74 ZOO – V2 Zoo Animal Cage Gardien 1 * 1 * * * nourrit 1 * *nettoie*
  • 76. Visibilité des attributs et des méthodes en UML ? + public : tout le monde  Méthodes de l'interface publique - privé : classe seulement  Attributs  Méthodes privées # protégé  Privé pour l'extérieur - Attributs  Transmis par héritage  Notion dépendante du langage ~ package 76
  • 77. Fourmi ZZ ? 77 Fourmiliere +travailler() +manger(entrée quantite : unsigned int) -energie : unsigned int -id : unsigned int -energieMax : unsigned int = 10 Fourmi +nourrirFourmi(entrée inFourmi : Fourmi &) OuvriereReine 1 * * *