Cours de C++, en français, 2002 - Cours 1.1

Cours C++ (2002)
semaine 1
jour 1

Cours semaine 1, jour 1 Cours C++ (2002) 2
Plan du jour
 Présentation des langages orientés objets
 Messages et concepts objets
 Analyse et conception de systèmes, de
programmes
 eXtreme Programming, et après

Langages orientés objets
 Langages orientés objets ou langages à
objets sont une évolution significative par
rapport aux langages procéduraux
 Ex : Pascal, COBOL, C
 Un peu moins de mathématiques, un peu plus
naturel
 Du point de vue du programmeur : abandon du
simple enchaînement des appels de procédures
et de fonctions

Langages orientés objets (2)
 Du point de vue de l’analyse, l’homme a plutôt
tendance à utiliser des classifications (taxonomies)
 Elles permettent de diviser le monde en groupes et
sous-groupes : le monde devient plus facile à
appréhender et à modéliser
 Les classifications peuvent être variées et fondées sur
des analyses statistiques, par composantes principales,
ou, de façon moins formelle, par distinction de
caractéristiques littéraires communément admises

Messages
 Un programme à base d’objets comporte
des entités clairement identifiées,
responsables de certains traitements sur des
types de données clairement identifiées
 Un programme est composé d’instances de
classes, les instances pouvant communiquer
les unes avec les autres
 Pas d’appel de fonctions : juste des invocations

Messages (2)
 L’exécution d’une tâche correspond à
l’envoi d’un message à l’instance
responsable du traitement et à la réception
d’un message de réponse
 Après tout, on a la même chose avec un
empilement et un dépilement lors d’un appel de
fonction !?
 L’idée n’est pas la même 

Messages (3)
 Naissance officielle des langages à objets
 Simula 67, langage de programmation dédié à
la simulation
 Introduction de la notion d’objets
 Simula 67 était une amélioration d’Algol
 Première présentation en 1962
 Simula est principalement fait pour supporter
l’exécution d’univers basés sur des interactions
faites par l’intermédiaire d’évènements discrets

Messages (4)
 Événements discrets :
 Quelque chose arrive
 Quelqu’un s’en rend compte
 Il informe une ou plusieurs autres entités qui
réagissent en fonction de leurs états internes en:
 Fournissant l’information demandée
 Créant d’autres évènements
 C’est la base des langages de simulation et
l’idée initiale conduisant à leur définition

Messages (5)
 Les langages de simulation ont introduits la
notion d’entité indépendante ayant un
traitement autonome
 Cette idée a été reprise pour la (fausse)
création des langages à objets
 Les objets, entre eux, ne s’échangent que des
messages
 Un message peut être local ou distant (le
principe est le même, pas l’implémentation)

Principes de base en objet
 Les objets communiquent entre eux par
messages
 L’appelant (client) formate un message et
l’envoi au destinataire (serveur)
 Le destinataire vérifie qu’il sait traiter le
message reçu et le traite s’il peut
 Les objets ne sont pas monolithiques, ils
s’agglomèrent les uns les autres pour en
constituer des plus importants

Principes de base en objet (2)
 Les principes de base en objets peuvent être
résumés suivant la règle « Apple PIE »
 Abstraction
 Polymorphisme
 Héritage (Inheritance)
 Encapsulation
 Nous reviendrons en détail sur ces principes
tout au long du cours

Abstraction
 L’abstraction est une généralisation
 L’abstraction permet d’ignorer ou de cacher les
détails, permettant d’extraire des points communs
entre différentes entités
 Exemples
 « être humain » est une abstraction de « homme » et de
« femme »
 « animal » est une abstraction de « mammifère », qui
est une abstraction de « cheval », qui lui-même est une
abstraction d’ « ardennais »

Polymorphisme
 Les abstractions sont faites à partir de
caractéristiques partagées
 Exemple : « cheval » et « dauphin » sont des
« mammifères »
 Ces abstractions ne se font pas uniquement
sur les données mais également sur les
traitements
 Exemple : les « mammifères » se déplacent et
se reproduisent

Polymorphisme (2)
 Qu’une fonction soit disponible à un haut niveau
d’abstraction ne signifie pas que son
implémentation soit la même partout
 Un « cheval » ne se déplace pas de la même manière
qu’un « dauphin »
 Il est cependant possible de traiter un groupe
d’objets à un haut niveau en appelant des
fonctions finalement différentes
 DéplacerTousLesMammifères() = pour chaque
mammifère présent dans le système, appeler la fonction
déplacer(), quelque soit le traitement effectif

Héritage
 L’héritage est le mécanisme qui permet de
réaliser l’abstraction
 Exemple : si la taxonomie précise que
« dauphin » est un « mammifère », alors
« dauphin » héritera de toutes les
caractéristiques et de tous les comportements
des « mammifères »
 Du plus spécifique au plus général :
abstraction
 Du plus général au plus spécifique : héritage

Encapsulation
 Les langages orientés objet permettent de définir
des abstractions à partir d’un ensemble d’entités
connues
 Chaque entité élémentaire a des caractéristiques
(données) et des comportements (traitements). Les
classes abstraites en possèdent également.
 Considérer une entité comme le regroupement de
ses données et de ses traitements est une
encapsulation
 Les langages procéduraux ne permettent pas de
réaliser l’encapsulation

Généralisons…
 Pourquoi utiliser des langages orientés objet
plutôt que des langages procéduraux ?
 Les langages procéduraux sont, après tout,
utilisés depuis bien longtemps et sont
parfaitement connus et maîtrisés.
 Oui, mais…

Échecs des projets informatiques
 Échecs des projets informatiques
Types de projet Dépassement
des coûtsType 1 Type 2 Type 3
En moyenne 16,2 % 52,7 % 31,1 %
Gros projets 9 % 61,5 % 29,5 % 178 %
Projets moyens 16,2 % 46,7 % 37,1 % 182 %
Petits projets 28 % 50,4 % 21,6 % 214 %
Type 1 : respectent budget, délais et spécifications
Type 2 : dépassent délais et budget, respectent les spécifications
Type 3 : abandonnés au cours du cycle de vie

Analyse et conception
 La réalisation de systèmes et de programmes
orientés objets diffère du mode de réalisation suivi
par l’analyse fonctionnelle et technique
 Vrai pour l’analyse
 Vrai pour la conception
 Vrai pour l’évolution d’un projet
 Généralement, pour les systèmes procéduraux,
gestion de projet « à la MERISE »

Méthodologies
 Waterfall : le plus largement suivi
définition
analyse
design
développement
tests unitaires
tests intégration
tests système
livraison
maintenance

Méthodologies (2)
 Modèle en V : le waterfall revisité
développement tests unitaires
design tests intégration
analyse tests système
définition livraison maintenance

Méthodologies (3)
 Modèle en spirale : le « waterfall itératif »
 Incrémentations successives, les premières
pouvant être « purement » formelles
 Un des meilleurs modèles :
 Marche tout aussi bien pour de petits projets que
pour les grands
 Permet le prototypage durant toutes les phases : le
logiciel n’est pas fini mais fait « comme si »…
 Besoin important de management et d’analyse du
risque

Méthodologies (4)
planning
analyse de risque
ingénierie
développement et
déploiement
évaluation par
l’utilisateur
discussion avec
l’utilisateur
Modèle en spirale

Méthodologies (5)
 Une méthodologie ne suffit pas !
 Les méthodologies sont exposées dans les
livres,
 Elles sont toujours assez abstraites
 Elles sont assez peu pratique
 Elles sont presque toujours ressenties comme
imposées par ceux qui les utilisent
 Elles ne tiennent généralement pas compte de la
taille du projet (« one size fit all »)

Processus
 Besoin d’un processus de développement
 Ils sont mis en place en fonction de
l’existant de l’organisation
 Ils donnent des orientations claires et
utilisables car ils sont adaptés à la réalité
quotidienne d’une entreprise
 Ils permettent à chacun d’améliorer sa
manière de travailler et d’interagir

Processus (2)
 CMM, Capability Maturity Model, nous
vient du département de la défense
américain (comme toujours !)
 Il identifie différents niveaux de maturité
des processus informatiques dans
l’entreprise
 Il donne un guide (abstrait) à adapter à une
entreprise pour que celle-ci soit capable de
grandir (maturing) presque seule

Processus (3)
 La maturité d’une organisation peut être
analysée à travers cinq niveaux différents :
 Niveau 1 : initial, peu de processus définis, le
succès d’un projet dépend des efforts
individuels, « Je fais comme je veux » (76 %
des organisations informatiques)
 Niveau 2 : répétable, processus de base pour la
gestion de projets, « Je gère et je contrôle ce
que je fais, mais ect-ce que je le fais
correctement » (15 %)

Processus (4)
 Niveaux (suite) :
 Niveau 3 : défini, tous les projets utilisent la même
base d’activités qui sont documentées, organisées et
standardisées, « J’utilise les meilleures pratiques de
mon organisation mais je ne peux pas juger leur
qualité » (7 %)
 Niveau 4 : géré, gestion quantitative des processus, des
métriques sont définies et observées pour les processus
et la qualité, « J’utilise les meilleures pratiques de mon
organisation et je connais leur qualité » (> 1 %)

Processus (5)
 Niveaux (suite) :
 Niveau 5 : optimisé, amélioration constante des
processus grâce à l’analyse des métriques
définies, « J’utilise les meilleures pratiques de
mon organisation, je connais leur qualité et je
les améliore constamment » (< 1 %)

Processus (6)
Contrôle des
processus
Niveau 4
Géré
Mesure des
processus
Niveau 4
Défini
Définition de
processus
Niveau 2
Répétable
Contrôle de gestion
de projet de base
Niveau 1
Initial
Niveau 5
Optimisé
Pas de processus défini
Services répétables, mise en place de processus de base
Standardisation des services et
mise en place de processus de service
Contrôle quantitatif des
processus de services
Contrôle qualitatif des processus de
service, amélioration constante des
processus

Processus (7)
optimisé
géré
défini
répétable
initial
Gestion du changement dans les processus
Gestion des changements/évolutions technologiques
Prévention des erreurs et disfonctionnements
Gestion de la qualité du logiciel
Gestion quantitative des processus
Gestion des problèmes
Coordination inter-groupes
Service Delivery
Gestion de service intégrée
Mise en place d’un programme de formation
Définition des processus de l’organisation
Respect des processus de l’organisation
Définition des services de l’organisation
Gestion de configurations
Gestion des imprévus
Service d’assurance qualité
Gestion de la sous-traitance
Gestion du suivi
Gestion du planning de livraison
Gestion des objectifs et besoins

Processus (8)
 RUP, Rational Unified Process, provient de
chez Rational
 Il est basé sur l’Objectory Process de
Jacobson, modèle assez académique
 Il est intéressant et pleins de bonnes idées
 Mais beaucoup des outils le supportant sont
vendus par … Rational

Processus (9)
 4 grandes phases :
 Étude : établit les besoins
 Élaboration : besoins détaillés, analyse et
design de haut niveau pour créer une
architecture de départ et un planning
 Construction : plusieurs itérations pour produire
un logiciel testé et répondant aux besoins
 Transition : test système et formation des
utilisateurs

Processus (10)
Etude Elaboration Construction Transition
Itération
Préliminaire
Analyse
Design
Architecture
Implémentation
Plannification
Test / Acceptation
Itération
#1
Itération
#2…
Itération
#n+1
Itération
#…
Itération
#m
Itération
#m+1
Itération
#m+2
Intégration

Analyse et conception (suite)
 Avoir une référence méthodologique est une
bonne chose
 Mettre en place un processus de gestion de
projet est encore mieux
 Il faut cependant penser à disposer d’un
langage permettant d’effectuer une
modélisation

Modélisation
 Besoin d’une Lingua Franca
 Faire de la conception orientée objet ou utiliser
un langage orienté objet nécessite de faire une
analyse du monde de l’application à développer
 L’analyse doit être comprise par le client
 Il parle de son univers
 L’analyse doit être comprise par le développeur
 De plus : certains programmes antérieurs et
autres librairies doivent éventuellement être
intégrés

Modélisation (2)
 À la différence de Fortran, Basic, Pascal ou
encore C, commencer à programmer sans
analyse du monde se révèle très
 Dangereux
 Inefficace
 Les langages orientés objet doivent donc
être utilisés comme il se doit !
 Un objet, et sa définition, se respectent !

Modélisation (3)
 Différentes méthodes d’analyse orientée
objet existent, certaines étant spécialisées
comme, par exemple, pour le temps réel
 Méthodes générales : OMT, Booch, OOSE
 Temps réel : RTMM
 Une méthode particulière d’analyse
supplante désormais presque toutes les
autres :
 UML, Unified Modeling Language

UML
 UML n’est pas une invention ab nihilo
 UML est en fait la fusion de plusieurs
méthodologies orientées objet dont chacune
avait ses forces et ses faiblesses
 Au début du cycle de conception de l’UML, de
plus en plus de méthodologies ont été analysées
et le meilleur en a été gardé
 UML peut presque, aujourd’hui, être qualifié de
synthèse des modélisations objet

UML (2)
 UML est un VRAI standard
 La conception d’UML a commencé en dehors
du monde de la normalisation
 L’UML a ensuite été soumis à l’OMG, l’Object
Management Group
 L’OMG est également responsable, entre autre
chose, de CORBA…
 UML n’est cependant pas toujours implémenter
complètement, certains « oubliant » des types
de diagrammes

UML (3)
 UML n’est pas une langue morte
 Au delà du fait qu’elle soit de plus en plus
utilisée, cette langue évolue encore
 UML participe désormais à une intégration très
large au sein de l’OMG
 UML en XML : XMI, XML Metadata Interchange
 MDA : Model Driven Architecture ; UML/XMI
comme base pour la définition d’applications et
l’échange de modèles entre entreprises (CORBA,
J2EE, .Net, services web)

UML : élaboration
Méthode Booch
Méthode OOSE
Méthode OMT
Autres méthodes
Partenaires UML
OMG
Unified Method 0.8 - 1995
UML 0.9 - 1996
UML 1.0 – 1996/1997
UML 1.3 – 1999
UML 1.1 – 1997

Origines d’UML
 Les trois méthodes de base de l’UML sont :
 Méthode Booch : Booch
 Méthode OMT : Rumbaugh
 Méthode OOSE : Jacobson
 Booch, Jacobson et Rumbaugh travaillent
ensemble chez Rational
 Étonnamment, Rational Rose est pour l’heure le
produit leader de modélisation UML…

Composants d’UML
 UML comprend un ensemble de
diagrammes assez différents dont chacun a
un rôle
 Plus ou moins général
 Plus ou moins large
 Statique ou dynamique
 UML peut être vu à travers un diagramme
baptisé 4+1
 Une vue centrale, quatre vues annexes

Composants d’UML (2)
Vue
processus
Vue
déploiement
Vue
composants
Vue logique
(design)
Vue
Cas d’utilisation
Utilisateur final
- Fonctionnalités
- Vocabulaire
Développeurs
- Développement et gestion
du logiciel
Analystes/Testeurs
- Comportement
Intégration de système
- Performance
- Capacité d’extension
- Capacité de charge
Ingénierie de système
- Topologie
- Déploiement et installation
- Communication

Composants d’UML (3)
Vue
structurelle
Vue
d’implémentation
Vue
comportementale
Vue
environnementale
Vue utilisateur
Diagramme de classes
Diagramme objet
Diagramme de
cas d’utilisation
Diagramme de composants
Diagramme d’activité
Diagramme de séquence
Diagramme de collaboration
Diagramme d’états-transitions
Diagramme de déploiement

UML : Use Case
 Les Use Case (cas d’utilisation) permettent
de faire l’étude préalable des fonctionnalités
recherchées par dialogue avec l’utilisateur
 Les Use Case diagrams sont un support à la
modélisation et à la discussion
 L’information est surtout informelle
 Scénarios (documents texte d’explication), copies
d’écran, etc
 Statique et dynamique

UML : Use Case (2)
internaute
navigue
se connecte
paie son abonnement
« utilise »

UML : Class Diagram
 Les diagrammes de classes permettent de
définir la taxonomie (classification) des
différents objets nécessaires au bon
fonctionnement du système
 Les diagrammes de classes sont statiques
 Les diagrammes de classes permettent de
faire la distinction entre l’appartenance à un
groupe et la composition d’un objet

UML : Class Diagram, aparte
 Avant toute modélisation objet, il faut
clairement faire la distinction entre « est
un » (is-a) et « a un » (has-a)
 Un cheval est un mammifère, un homme est un
mammifère
 Un homme a des jambes
 Une fourmi a des pattes
 Ces deux mécanismes sont à la base de la
définition des classes

UML : Class Diagram (2)
VêtementCheval Homme
Animal
MammifèreInsecte Jambe
Famille
1 2,4
1 1..*
1
1..*

 Dans un diagramme de classe, on marque le
lien is-a par l’héritage
 Le lien has-a est beaucoup plus raffiné, il
est possible de noter :
 Une association
 Une aggrégation
 Une composition
 Il est également possible de marquer des
cardinalité et des sens de navigation

TripTarif
Enumeration getZones()
Price getPrice( Zone )
price
zone
TripLeg
* *
Association : deux objets sont liés mais de manière
relativement indépendante. La relation est très
relâchée.

1
ExhaustSystem
Muffler Tailpipe
0..2
Aggrégation : plus forte que l’association, elle marque
un lien de composition fort. Les constituant peuvent
exister sans l’aggrégat mais cela n’a alors plus
beaucoup d’intérêt.

3
DistributeurDeTickets
SélecteurDestination
Composition : il s’agit du lien le plus fort : les
constituants ne peuvent pas exister sans l’aggrégat.
Note : le choix entre une aggrégation et une composition
dépend généralement de l’univers dans lequel se fait la
modélisation

 Lors de la définition d’un héritage entre
classes, il faut toujours commencer par le
plus général pour descendre vers le plus
particulier
 Autrement dit : ne pas faire de hiérarchies
inversées
 La racine d’un arbre doit être un objet très
général
 C’est grâce à cela que l’on peut réutiliser

Directeur
Manager
Employé
Employé
Manager
Directeur
Note : un diagramme
de classes n’est pas
un organigramme de
fonctions !

 Des classes peuvent être regroupées en
package (paquetage)
 Un package est un groupe de classes dont le
rôle est similaire ou qui possèdent la même
appartenance
 Package des mammifères
 Package de connexion réseau
 Un package permet d’obtenir un niveau
d’abstraction (il cache la foule…)

Collaborations Statechart Activity
Éléments dynamiques
Gestion du
modèle
Foundation
Use Cases
Common
Behavior

UML : Exercice #1
 Créer un diagramme de classes dans le
domaine des transports en commun
 Définnissez une arborescence des moyens de
transport
 Définissez les constituants et l’environnement
de ces moyens de transport
 N’utilisez pas les packages…

UML : Exercice #2
 Système d’enregistrement d’une conférence
 Créez la hiérarchie incorporant :
 Les organisateurs
 Les orateurs invités
 Les orateurs principaux
 Les orateurs annexes
 Les participants inscrits industriels
 Les participants inscrits académiques (profs)
 Les participants inscrits étudiants

UML : Exercice #2 (2)
 Que se passe-t-il si
 Un organisateur est orateur annexe
 Un étudiant est orateur principal
 Un orateur principal décide de ne pas présenter
ses travaux mais assiste tout de même en tant
que participant inscrit académique

UML : Exercice #2 (3)
 Conclusions :
 Un héritage simple est parfois insuffisant mais
 L’héritage multiple apporte beaucoup de
complication et d’illisibilité
 L’introduction / la création d’associations peut
être bénéfique
 Mais certaines conditions devront alors être
respectées

UML : Object Diagram
 Les diagrammes d’objets montrent les
instances et les liens entre objets
 À la différence du diagramme de classes, le
diagramme d’objets est dynamique
 Il illustre des situations
 Il permet de présenter les structures des objets
et des données
 Il est en fait “presque” dynamique

UML : Object Diagram (2)
c : Compagnie
d1 : Département
nom = "ventes"
p : Personne
nom = "Dupont"
id = 2718
emploi ="vendeur"
d2 : Département
nom = " R&D"
: Adresse
addresse = "rue"

UML : Component diagram
 Les diagrammes de composants permettent
de représenter la structure physique de
l’implémentation
 Organisation du code source
 Compilation d’exécutables
 Bases de données physiques
 Ils sont proches des choix techniques
 Ils sont statiques

UML : Component diagram (2)
index.html
find.html
nateng.dll
find.exe
dbacs.exe

UML : Activity diagram
 Les diagrammes d’activité permette
d’obtenir une vision orientée métier d’un
processus
 Montre l’enchaînement des actions, les
synchronisations, les responsabilités des
acteurs
 Note : ils ont de plus en plus de succès pour
les modélisations dans les logiciels de
workflow

UML : Activity diagram (2)
Donner #
remboursement
Client Ventes StocksComptabilité
Renvoyer
article
Informer
du renvoi
Réception
article
Stockage
article
Rembourser
article
Article
[renvoyé]
Article
[disponible]

UML : Sequence diagram
 Les diagrammes de séquence permettent de
raffiner les Use Case diagrams en :
 Permettant d’identifier les objets participants
 Permettant de trouver des objets manquants
 Permettant de marquer les enchaînements
 Ils marquent également des durées
d’exécution
 Ils sont dynamiques

UML : Sequence diagram (2)
sélectionBoisson()
récupérationMonnaie()
récupérationBoisson()
introductionArgent()
Client
Distributeur
de boissons

UML : Collaboration diagram
 Les diagrammes de collaborations
permettent de représenter les interactions
entre classes
 Ils présentent les flux de contrôle
 Ils illustrent la coordination entre les objets de
structure et les objets de contrôle
 Ils sont dynamiques (orientés messages)

UML : Collaboration diagram (2)
p : ODBCProxy
1 : crée
2 : prépareAction( a, d, o )
3 : détruit
c : Client
d2 : Département
2.1 : affecte( d, 3.14 )
2.2 : affecte( a, "CO" )

UML : Statechart diagram
 Les diagrammes d’état-transition
correspondent à une version allégée des
diagrammes d’activité
 Plus de responsabilités, de synchronisation
 Ils pourraient typiquement être utilisé en
automatique pour modéliser le
comportement d’un automate
 Ils sont dynamiques (orientés évènements)

UML : Statechart diagram (2)
Heures
clignotent
Secondes
clignotent
Minutes
clignotent
touche 2
touches 1 & 2
touche 2
touche 2
touche 1
touche 1
touches 1 & 2
touches
1 & 2
Incrément
heures
Incrément
secondes
Incrément
minutes
Arrêt
clignotement

UML : Deployment diagram
 Les diagrammes de déploiement permettent
de capturer la topologie du système sur
laquelle est déployée l’application
 Permet de définir
 La distribution des composants
 De pré-identifier les éventuels goulots
d’étranglement

UML : Deployment diagram (2)
réseau
serveur serveur serveur
serveur
primaire
serveur
données
imprimante

UML de base et extensions
 Comme nous l’avons vu, UML comporte 9 types
de diagrammes différents
 Ces diagrammes ont TOUS leur utilité
 Certains peuvent cependant être inutiles dans un projet
 UML comporte également un ensemble de
fonctionnalités supplémentaires dans la notation
 Stéréotypes de classe : permettent de montrer
l’appartenance à un modèle « technique »
 Profils : extensions pour la persistance, le temps-réel,
etc.

Points forts d’UML
 Du fait de sa standardisation par l’OMG, la
méthode est supportée par de nombreux
outils. Grâce à cela, une course aux
fonctionnalités s’est instaurée
 Prise en compte des bases de données
existantes
 Génération automatique de squelettes de code
 Possibilité d’importer ou d’exporter dans un
vocabulaire XML

Un outil UML : Rational Rose

Un outil UML: Rational Rose (2)

Lourdeurs
 Les normes de modélisation, les processus
de gestion de projet, l’amélioration des
habitudes de travail par l’intermédiaire de
référentiels tels que CMM ou d’autres
 Tout ceci a un prix et demande du temps
 Tout ceci est lourd et difficile
 Tout ceci nécessite l’adhésion de tous
 Une fois en place, de telles méthodes se
révèlent gagnantes mais :

Lourdeurs (2)
 Tout ceci en vaut-il toujours « la chandelle »
?
 Une petite structure de développement ou
une petite société peut-elle s’autoriser de
mettre en place de telles procédures,
administrativement lourde ?
 Certains ont eu une réaction négative et ont
eu une volonté d’allègement des processus

eXtreme Programming
 XP (nom choisi avant que Microsoft ne lui
accorde une autre signification…) est une
méthodologie de développement objet
allégée d’un point de vue administratif
 D’un point de vue CMM, il s’agit d’un
niveau 1 très amélioré
 « À la mode » car prône pour une gestion
très réactive des projets, et des problèmes…

eXtreme Programming (2)
 Il faut considérer XP comme une
organisation de gestion de projet applicable:
 Aux petites équipes
 Aux équipes effectuant un travail assez
autarcique et ayant donc relativement peu
d’interconnections avec des équipes extérieures
 Aux équipes dont les travaux seront peu
réutilisés par l’extérieur et où différents niveaux
de documentation ne sont pas nécessaires

 Quatre valeurs mises en exergue :
 Communication
 Travail en groupe (2 programmeurs pour 1 poste)
 Simplicité
 Toujours faire au plus simple
 Temps de réponse
 Chacun doit répondre rapidement aux questions
 Courage
 Pour se remettre en question après les choix

 Principes de base :
 Faible temps de réponse de la part des
développeurs eux-même ET des clients
 Aller au plus simple (rasoir d’Occam)
 Changements incrémentaux comme dans la
méthode itérative
 Acceptation du changement
 Travail de qualité

 Activités de base :
 Codage, pour la communication et l’apprentissage
 Tests, automatisés, unitaires et système, « tout ce
qui ne peut pas être mesuré n’existe pas » (…)
 Écoute, des autres développeurs, des clients
 Design, tant du système à développer que de
l’équipe qui le développe

Pratiques XP
 Planning
 Le client définit les besoins, la date de livraison
 Les techniciens en présentent les conséquences
pour les coûts et le planning détaillé
 Il s’agit bien des techniciens, pas des commerciaux !
 Petites releases fréquentes
 Une métaphore générale par projet
 Une idée ou un comcept central par projet

Pratiques XP (2)
 Design simple
 Pas de réplication de la logique métier
 Le moins possible de classes et de méthodes
 Incorpore toutes les idées des développeurs
 Passe tous les tests
 Tests
 Procédures de test automatisé pour TOUTES
les fonctionnalités du système

Pratiques XP (3)
 Réécriture
 Est-il possible de réécrire un programme
existant pour rendre l’ajout de nouvelles
fonctionnalités plus simple ?
 Après un ajout d’une fonctionnalité, peut-on
rendre le programme plus simple
 Programmation à deux
 2 personnes, 1 écran, 1 clavier, 1 souris
 1 pour une vue globale, 1 pour ici et maintenant

Pratiques XP (4)
 Propriété collective
 Si un développeur trouve intéressant d’ajouter
une fonctionnalité dans un programme de
quelqu’un d’autre, il DOIT le faire
 Tout le monde peut simplifier les programmes
de tout le monde
 Intégration continue
 Le système est testé tous les jours, pas toutes
les semaines ou tous les mois

Pratiques XP (5)
 Semaine de 40 heures
 Les heures supplémentaires sont un symptôme
de problèmes graves
 Présence du client
 Un utilisateur final est intégré à l’équipe
 Respect de standards de codage
 Pas de code dupliqué
 Faire comme il faut ou ne pas faire du tout
 Développeur non identifiable par le code

Quelques défaut d’XP
 Les extrêmes auquels il ne faut pas aboutir :
 La conception est dans le code
 Ce genre de principe est naturel pour un logiciel
développé « à la maison »
 Les bidouilles et les GOTO à la Fortran/Basic sont
une des pires choses qui soient : les laisser aux
compilateurs et autres optimiseurs !
 La documentation est orale
 Personne n’est irremplaçable et
 Personne n’est éternel…

XP, et après ?
 L’eXtreme Programming prend le contre-
pied des méthodes plus lourdes comme
CMM, RUP (également ITIL, SPICE,
Objectory, etc)
 Un des accents est mis sur le besoin
constant de tests par l’intermédiaire de
petits programmes automatisés (framework)
 Tests unitaires, système, d’intégration

XP, et après ? (2)
 Cependant, les méthodologies plus lourdes
continuent à progresser tandis que la
recherche en génie logiciel essaie de
résoudre certains problèmes
 Question 1 : peut-on pousser plus avant les
capacités de génération de code ?
 Question 2 : peut-on prouver, au moins
partiellement, la correction d’un programme
donné ?

Conditions
 Les réponses sont affirmatives !
 Technique importante : les pré-conditions et
les post-conditions
 Elles ont pour la première fois été introduites
dans le langage orienté objet Eiffel de Meyer
 Il existait déjà des choses en C
 Elles peuvent se retrouver aujourd’hui, à des
degrés moindres, dans C++ ou Java
 Et surtout : elles peuvent être définies à l’étape
de modélisation d’un système

Conditions (2)
 En complément du langage Eiffel, Meyer a
mis au point une technique formelle de
conception orientée objet
 Design By Contract
 « Si tu promets d’appeler la méthode m en
respectant la pré-condition alors, en retour, la
méthode m promet de respecter la post-condition »
 La généralisation des contrats permet de définir
la responsabilité de chacun

Méthodes formelles
 Introduite lors des phases de modélisation,
de telles techniques sont qualifiées de
formelles
 Une méthode formelle permet de définir au
niveau de l’appel d’une fonction :
 Les pré-conditions qui donnent les conditions
internes nécessaires au bon déroulement
 Les post-conditions qui permettent de contrôler
l’état des lieux après exécution

Méthodes formelles (2)
 En complément des pré et post-conditions,
il est possible de définir l’algorithme de la
fonction de manière abstraite
 L’algorithmique définit ici est assez abstraite et
assez proche des mathématiques
 Cependant, il s’agit parfois presque de langages
de programmation !
 Il existe plusieurs méthodes. Nous en
présentons brièvement 2 : OCL et B

OCL
 OCL signifie Object Constraint Language
 OCL permet de définir des :
 Des pré-conditions
 Des post-conditions
 Des algorithmes au niveau de chaque méthode
de chaque objet
 Encore une fois, cela ressemble parfois à un
langage de programmation mais

OCL (2)
 OCL n’est pas un langage de
programmation (même s’il commence à
exister des compilateurs OCL…)
 Les contraintes OCL peuvent être analysées
automatiquement
 La totalité d’un système peut être modélisé
 Et enfin
 OCL fait partie de UML !

OCL : Exemple
<JobCategory> <Facility>
reqs
<Job>
when: TimeInterval <Resource>
0..*
type
allocated
provides 0..*
0..1
inv Job::allocated<>0 ==> allocated.provides->includesAll(type.reqs)
--Any allocated resource must have the required facilities
inv Resource::jo1, jo2: Job::
(schedule->includesAll({jo1,jo2}) ==> jo1.when.noOverlap(jo2.when)
-- no double-booking of resources
schedule
0..*

Méthodes formelles, conclusion
 Science-fiction ?
 Les logiciels des deux lignes de métro
dernièrement créés à Paris ont été conçus grâce à
la méthode B
 La RATP ne jure désormais plus que par B ! Ils
n’avaient jamais réussi à obtenir des logiciels de ce
niveau de qualité avant
 Tous les logiciels sensibles (avec des vies
humaines en jeu) seront très probablement conçus
avec de telles méthodes dans un avenir proche

Méthodes formelles, conclusion (2)
 Les méthodes formelles vont au delà des
simples notions des langages orientés objet.
Cependant :
 Elles sont par exemple INTÉGRÉES dans
UML (versions 1.1 et maintenant 1.3)
 De plus en plus de langages orientés objet
intègre des capacités d’assertion qui permettent,
grosso modo, de faire des vérifications de
qualité du code sans passer par un débogueur

Questions / Remarques

Cours de C++, en français, 2002 - Cours 1.1

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cours de C++, en français, 2002 - Cours 1.1

Similaire à Cours de C++, en français, 2002 - Cours 1.1 (20)

Plus de Laurent BUNIET

Plus de Laurent BUNIET (11)

Cours de C++, en français, 2002 - Cours 1.1