CSC 4102 – Introduction au génie logiciel pour applications orientées objet

Séance 6 — TP : Suite de la programmation du logiciel

Pour réaliser le projet, vous avez besoin de connaître la méthodologie présentée en cours. En outre, vous pouvez vous inspirer des exemples du cours ainsi que des deux études de cas complètes fournies dans le projet GitLab csc4102-exemples. Si ce n'est pas déjà fait, clonez le projet GitLab (cd ~/CSC4102/; git clone git@gitlabens.imtbs-tsp.eu:enseignants.csc4102/csc4102-exemples.git; cd csc4102-exemples) et prenez connaissance du fichier readme.md. Ou, mettez à jour le dépôt que vous avez cloné (les exemples évoluent [même si c'est peu]) : cd ~/CSC4102/csc4102-exemples; git fetch; git pull origin main.

(Re-)Positionnement dans le dépôt `Git` de `GitLab`

Voici la procédure que nous proposons (dans tous les cas « par défaut »). « En cas de panique », veuillez vous reporter à celle qui suit celle-ci.

Procédure « repositionnement »
- on repart d'un dépôt mis à jour et on continue dans la branche develop
  - cd ~/CSC4102
    cd csc4102-projet
    git fetch # prendre connaissance des nouveautés
    git branch # quelle est la branche courante ?
    si pas déjà dans la branche develop alors « git checkout develop » # se positionner dans la branche
    git pull origin develop # accepter les modifications de la branche
    si conflit et besoin d'une fusion, « git mergetool --tool=meld » puis « git commit »

« En cas de panique », veuillez suivre la procédure qui suit :

Procédure « nouveau clonage »
- on clone à nouveau le dépôt et on continue dans la branche develop :
  - cd ~/CSC4102
    mv csc4102-projet csc4102-projet_old # garder une copie au cas où du contenu n'ait pas été poussé
    git clone URL_DE_VOTRE_PROJET
    cd csc4102-projet
    git checkout develop # positionnement dans la branche develop

En fin d'énoncé de ce TP, nous proposons une procédure pour la tâche duale consistant à clore une phase de travail en validant et poussant les modifications sur le dépôt Git de GitLab.

(optionnel) Révision du concept des exceptions

révision du concept d'« exception ».

Avant d'ajouter la « programmation des exceptions », nous reprenons un exercice d'apprentissage du module CSC3101. C'est pour cela que cette étape est optionnelle.

Exception simple

Dans Eclipse, ouvrez la classe classe ArrayErrors du paquetage eu.telecomsudparis.csc4102.cours.seance6.exception.tp dans le projet GitLabEns csc4102-exemples que vous avez cloné. Exécutez la classe ArrayErrors : dans le menu contextuel de la classe, Run As > Application.

Vérifiez que vous comprenez clairement la relation entre l'affichage et l'exécution :

Exception in thread "main"  *** catch java.lang.ArrayIndexOutOfBoundsException: -1
After try-catch; res value =0
java.lang.ArrayIndexOutOfBoundsException: -1
	at eu.telecomsudparis.csc4102.cours.seance6.exception.tp.ArrayErrors.main(ArrayErrors.java:17)

Voici une explication de l'exécution :

Le programme ArrayErrors contient deux tentatives d'accès à l'entrée d'indice -1 d'un tableau d'entiers. Ces deux tentatives lèvent une exception de type ArrayIndexOutOfBoundsException. La première tentative est placée dans un bloc try-catch, ce qui permet de traiter l'exception correspondante. La seconde tentative n'est pas placée dans un bloc try-catch et provoque l'arrêt de l'exécution du programme.

Exemple plus complet

Testez l'exemple de traitement d'exception suivant pris dans le même paquetage :

la définition de l'exception HorsBornes ;
la classe UneLevee : le constructeur de cette classe lève une exception de type HorsBornes lorque le paramètre qui lui est passé n'est pas entre 0 et 3 ;
la classe UneInterception contient une méthode main qui construit plusieurs objets de type UneLevee. L'exception est traitée une fois grâce à un bloc try-catch.

Exécutez la classe UneInterception. Comprenez les affichages :

1 : execution avec 2 en argument
2 : passage en sequence sans exception
3 : Execution avec 4 en argument 
5 : nous sommes dans la partie catch, nous n'avons pas execute le 4eme println
6 : apres le bloc try-catch
7 : appel avec -1 en argument
Exception in thread "main" eu.telecomsudparis.csc4102.cours.seance6.exception.tp.HorsBornes: Exception Hors borne levee
	at eu.telecomsudparis.csc4102.cours.seance6.exception.tp.UneLevee.(UneLevee.java:8)
	at eu.telecomsudparis.csc4102.cours.seance6.exception.tp.UneInterception.main(UneInterception.java:24)

Vérifiez que vous comprenez bien l'utilisation des trois parties : 1) déclaration de levée d'exception avec throws, 2) levée d'exception avec throw new et 3) surveillance et traitement d'exception respectivement dans les blocs try et catch.

Continuation du développement du noyau fonctionnel de l'application

utiliser la gestion des exceptions pour ajouter la détection des cas d'erreur avec leur traitement.

Programmation des cas d'erreur

Utilisez la gestion des exceptions pour ajouter la détection des cas d'erreur avec leur traitement. D'après la stratégie « programmation défensive » présentée dans les diapositives du cours de la séance 4 (à partir de la diapositive « 3.2 Précondition, postcondition, et algorithme d’une opération ») ainsi que dans les diapositives du cours de la séance 6 (diapositive « 2.1 Pratiquement, dans ce module »), il s'agit de :

tester en début de méthode la validité des préconditions,
vérifier l'invariant en fin de méthode si l'état de l'objet a été modifié.

Les postconditions sont quant à elles vérifiées dans les tests.
pour faciliter la programmation des cas d'erreur, nous proposons la classe OperationImpossible montrée dans les exemples du cours. Dans le module, vous pouvez, soit utiliser cette exception pour toutes les exceptions sous contrôle, soit choisir de créer des classes enfants de Exception pour les différents types de cas d'erreur. Dans les deux cas, mettez des messages d'erreur pertinents.

Méthode `invariant()`

Lors de la conception détaillée, vous avez calculé l'invariant de la classe (). Programmez la méthode invariant() et utilisez-la dans le constructeur et dans les méthodes qui modifient l'état des objets de la classe.

Programmation et exécution des tests

programmation des tests unitaires,
programmation des tests de validation.

c'est la remontée du classique « cycle en V » avec les tests unitaires, puis les tests d'intégration, et ensuite les tests de validation. Pour rappel, dans le module, nous ne faisons pas de tests d'intégration.

Exécution des tests dans Eclipse

Exécutez les tests déjà écrits en JUnit : dans le menu contextuel du paquetage ...tests.unitaires ou ...tests.validation, Run As > JUnit Test. La partie gauche montre la fenêtre JUnit avec le résultat de l'exécution des méthodes de test. Une barre verte indique que tous les tests passent et une barre rouge qu'au moins un test est en erreur. Plus précisément, une méthode de test est en vert lorsqu'elle passe (vrai négatif et vrai positif), avec une croix rouge lorsqu'elle ne passe pas parce que l'exécution de la méthode de test lève une exception qui ne doit pas être levée (faux positif), et avec une croix bleue lorsqu'elle ne passe pas parce que l'exécution de la méthode de test ne lève pas une exception qui est attendue (faux négatif).

Tests unitaires

Lors de la préparation des tests unitaires, vous avez construit des tables de décision pour les opérations (« ») et (« ») de la classe (). Programmez une classe de tests par table de décision de tests unitaires, cette classe contenant des méthodes annotées @BeforeEach, @AfterEach et @Test.

Tests de validation

Lors de la préparation des tests de validation, vous avez construit des tables de décision , et pour les tests de validation des cas d'utilisation (« »), (« »), et (« »). Pour chacun de ces cas d'utilisation, (« »), (« ») et (« »), programmez une classe de tests, cette classe contenant des méthodes annotées @BeforeEach, @AfterEach et @Test.

Mise à disposition du travail effectué dans le dépôt `Git` de `GitLab`

Systématiquement, avant de terminer une séance de travail, que ce soit en salle TP ou chez vous, mettez à jour votre dépôt local (au cas où vous ayez travaillé en parallèle), validez et poussez votre travail :

git fetch # charger les modifications non encore connues localement
git pull origin develop # mettre à jour votre branche develop
et si conflit et besoin d'une fusion, git mergetool --tool=meld
git status # connaître l'état de votre arborescence
selon les besoins, pour préparer la zone de transit pour la validation du prochain instantané, git add, git mv, git checkout --, etc.
git commit -m "je dis ce que contient le nouvel instantané" # valider les modifications de la zone de transit
git push origin develop# pousser pour mettre à disposition
connectez-vous à GitLab et vérifiez que votre travail a été poussé.

À LA FIN DU TP DE LA SÉANCE

Avant de quitter le TP, veuillez s'il vous plaît remplir dans la page Partage de votre groupe le tableau d'avancement de votre binôme-projet :

C'est aussi le moment de parcourir la grille d'auto-évaluation de la séance.