Algorithmique Programmation FIP - Techniques de Programmation

Transcription

Algorithmique Programmation FIP
Techniques de Programmation en Java
ING39
Septembre 2016
Cours 1 : Introduction
1. Objectifs & organisation
Objectifs
I
Capacité à écrire des programmes Java de taille
conséquente
I
Fluidité dans la conceptions de programmes :
I
I
I
développement guidé par les tests (eXtreme programming).
décomposition modulaire et objet.
travailler avec différents paradigmes de la programmation :
orienté objet, impératif, événementiel, web
I
Utiliser les bibliothèques Java.
I
Travailler avec un IDE et un gestionnaire de versions.
Enseignants
I
Pierre Courtieu
I
Serge Rosmorduc
I
M.V Aponte (responsable du module)
Pré-requis
I
Connaissance d’un langage de programmation de haut
niveau (pas forcément Java) ;
I
Vous êtes capables d’écrire un programme simple avec
boucles (entre 10 et 100 lignes).
Organisation
I
Cours : les matins, ≈ 1h30 à 2 heures (salle change selon
semaines).
I
TPs : les après-midi, parfois débutent en fin de matinée
(salle des Marchés).
I
Environnement de programmation : Netbeans + JUnit4.
I
Gestion de ressources :
I
I
I
serveur distant + logiciel gestionnaires des versions
cette année sera Git.
Attention : Pas de machine autorisée pendant les cours.
Evaluation
I
1 ou 2 TPs notés par semaine.
I
Un examen final.
I
Note du module : somme pondérée notes de TP &
d’examen.
I
Les Tps notés porteront souvent sur une extension/
modification du sujet de TP de la veille ou de la semaine.
I
⇒ vous avez intérêt à programmer de manière
suffisamment générale pour faciliter les modifications !
Les Tps
I
I
pas de rattrape, pas de corrigés, mais un debiefring après
chaque TP noté.
Majoritairement notés par tests automatiques :
I
I
I
note dépend du % de tests réussis.
on vous en donnera quelques uns avec l’énoncé.
vous devrez écrire les autres.
I
Soumission sur le serveur distant (via Netbeans +
gestionnaires des versions). Pas de soumission en retard.
I
Tps notés + examens → individuels. Copie interdite.
2. Approche de développement adoptée dans
ce cours
Pratiques de développement
Nous adoptons quelques principes de l’eXtreme Programming
1. communication ⇒ programmation en binôme ;
2. simplicité ⇒ la méthode la plus simple d’arriver au résultat
est retenue à priori ;
3. le feed-back via les tests ⇒ programmation guidé par les
tests ;
4. la qualité du code ⇒ meilleure assurance de la
robustesse, diminution de coûts de maintenance ;
5. les tests sont effectués au plus tôt ;
Tests unitaires & programmation guidée par les tests
Avant de coder une fonctionnalité :
I
le programmeur écrit un jeu de tests pour tester son
comportement comme prévu ;
I
ces test sont conservées jusqu’à la fin du développement ;
I
ils sont ré-jouées à chaque chaque évolution du code :
I
I
très importan ⇒ assurer que la fonctionnalité reste correcte
au cors des changements,
cela s’appelle : tests de non régression
Nous utiliserons JUnit 4 pour réaliser des tests unitaires.
Notre méthode de conception
1. Comprendre le problème :
Concepts caractéristiques du problème, leur
inter-dépendances ?
2. Formaliser les fonctionnalités :
Interactions programme / son environnement ?
Type de réponses attendues (fonctionnalités) ?
3. Écrire un jeu de tests :
Réponses concrètes sur des entrées typiques (ou érronées) ?
4. Implanter fonctionnalités :
Décomposer problème en sous-problèmes plus simples et itérer
dessus cette méthode.
5. Jouer les tests + corriger code : jusqu’à obtenir comportement
correct du programme.
Illustration (un exemple vraiment trivial !)
Calculer la date du lendemain
. . . en partant d’une date : numéro de jour , mois et année.
Cette illustration a pour but de mettre l’accent dur le
développement guidé par les cas de test.
Pas 1 : Comprendre le problème
I
Concepts caractéristiques :
I
I
I
I
I
I
date : numéro de jour + mois + année ;
la date tombe en fin de mois et/ou en fin d’année ?
fin d’année : 31 décembre ;
fin d mois : dépend du mois (30 ou 31), sauf pour février ;
si année bissextile : la fin février tombe le 29, sinon le 28 ;
But : déterminer le numéro du jour, mois et année du lendemain
de la date donnée.
Pas 2 : Formaliser les fonctionnalités
I
Comment représenter les données ?
I
jour, mois et année ⇒ entiers
I
contraintes/hypothèses :
I
I
on suppose que la date de départ est bien formée ⇒ donc,
pas de tests sur des dates fantaisistes.
Quelles fonctionnalités ?
I
3 fonctions :
I
I
I
test (booléan) si une année est bissextile ;
calcul du nombre de jours d’un mois ET une année ;
calcul de la date du lendemain ⇒ un tableau dentiers ;
Pas 2 : Formaliser fonctionnalités en Java
Nous utilisons :
I
des méthodes Java (sous-programmes) pour écrire les
fonctions
I
ce seront des méthodes statiques (sans objets),
I
Important :
I
nous leurs donnons un corps vide ou presque pour
permettre la compilation.
I
Pourquoi ? Nous écrirons le vrai code (corps de la
méthode) après avoir conçu tous les tests.
Pas 2 : exemple 1
Fonctionnalité → ”tester si année bissextile” :
I
les commentaires décrivent le rôle des paramètres (format
javadoc).
I
le corps contient le minimum pour que cela compile.
/**
* @param annee: l’annee d’une date
* contrainte: annee est une annee correcte
* @return true si a est bissextile
*/
static boolean isBissextile(int annee) {
return true;
}
Remarque : l’implantation correcte reste à écrire !.
Pas 2 : exemple 2
Fonctionnalité → «calculer nbe jours mois dans une année» :
/**
* @param mois: le no. de mois d’une date
* @param annee: l’annee d’une date
* contrainte: @param mois et
* @param annee sont corrects
* @return nombre de jours de @param mois pour l’ann
*/
static int nbeJours(int mois, int annee){
return 0;
}
Remarque : l’implantation correcte reste à écrire !.
Pas 3 : Écrire un jeu de test (fonction isBissextile)
Elaborer une liste de résultats pour des valeurs typiques des
entrées.
année
2000
2001
2100
1400
1600
2004
résultat attendu
true
false
false
false
true
true
(∗) les exemples pourront nous alerter sur des cas non compris : une
année est bissextile si elle divisible par 4 mais pas par 100, ou si elle
divisible par 400.
Qu’est-ce qu’un cas de test ?
Cas simple : tester une fonction f qui prend 2 paramètres x, y ;
I
un cas de test pour f est une ligne de la forme : :
x
vx
I
I
y
vy
résultat attendu
result
vx et vy : valeurs concrètes à tester en paramètre de f ,
result : résultat attendu en retour de l’appel f (vx , vy ).
Jeu de tests pour f
Table contenant plusieurs cas de test pour f (1 par ligne).
Jouer un cas de test (à la main)
Juons un seul cas de test :
x
vx
y
vy
résultat attendu
result
1. Invoquer f sur les entrées données pour ce cas...
2. ... tout en récupérant le résultat retourné :
result = f (vx , vy );
3. comparer résultat obtenu result avec résultat attendu
result ;
4. signaler un rapport d’échec si différents.
Appliquer cette méthode pour chaque cas de test du tableau.
Pas 3 : Écrire un jeu de test (fonction nbeJours)
Ici, la fonction prend 2 paramètres : le tableau contient 3
colonnes.
mois
12
2
3
2
2
année
2000
2000
2001
2001
1400
résultat attendu
31
29
30
28
28
(∗) les exemples pourront nous alerter sur des cas non compris.
Pas 3 (suite) : automatiser les tests
Plusieurs cas de tests × plusieurs fonctions
⇒ écrire des programmes qui réalisent ces tests.
I
Solution : une méthode pour chaque cas de test
I
I
qui invoque la méthode à tester sur entrées du cas de test ;
et compare le résultat retourné avec celui attendu .
I
Très fastidieux à faire à la main et pour chaque méthode à
tester !
I
Alternative : JUNIT4
I
I
I
Nous écrivons les jeux de tests ;
la plateforme invoque la méthode à tester sur entrées de
chaque cas de test, compare le résultat retourné avec celui
attendu.
et produit un rapport de succès/échec.
Pas 3 : Écrire les cas de test en JUnit4
@Test
public void testIsBissext1() {
System.out.println("isBissext");
int annee = 2001;
boolean expResult = false;
boolean result = SampleStaticDate.isBissext(annee);
assertEquals(expResult, result);
}
1. fixe les valeurs des entrées : annee = 2001
2. fixe le résultat attendu pour ces entrées : expResult=false
3. obtenir le résultat calculé par la méthode ( result)
4. tester si ( expResult == result), donner un rapport d’erreur sinon.
Pas 3 (fin)
Nous jouns ce cas de test sur notre implantation "vide” : elle
doit échouer.
Pas 4 : Implanter le comportement des méthodes
Important
Écrire les cas de tests avant d’écrire le code des méthodes !
Pas 5 : Jouer les tests sur le code implanté
... puis modifier le code si nécessaire...
Répeter
1. Appliquer cette recette sur toutes les méthodes du
programme ;
2. Jouer les cas de test.
3. S’assurer qu’il ne manque pas de fonctionnalités
(méthodes).
4. Ajouter des tests pour les nouvelles fonctionnalités, mais
ne jamais enlever ceux pour les + anciennes :
I
toujours ré-jouer les tests pour les anciennes
fonctionnalités (tests de non-régression) ;
5. Itérer autant que nécessaire . . .

Algorithmique Programmation FIP - Techniques de Programmation

Transcription

Documents pareils

Télécharger le pdf

Lettre d`information aux Investisseurs

Lettre d`information FIP Entrepreneurs

Lettre d`information aux Investisseurs

Lettre d`information aux Investisseurs

EVENEMENT Radio France partenaire de la 34 Fête de la Musique

FIP > album semaine frix

2700056 - 27270002 - Informatique 1 (C2i)

Télécharger

Voir l`article