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

Séance 2 — TP : Spécification et préparation des tests de validation

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.

pendant la séance, vous dessinez un ou plusieurs diagrammes UML et complétez le fichier « readme.md ». À la fin de la séance, vous fournissez (1) le fichier « readme.md » avec la spécification remplie, (2) les fichiers sources PlantUML (« *.pu ») et les fichiers images correspondantes (« *.svg » et « *.png »).

(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.

Spécification

définir le ou les acteurs du système,
définir les fonctionnalités du système dans un ou des diagrammes de cas d'utilisation,
définir la priorité des cas d'utilisation,
écrire les préconditions et postconditions d'au moins 3 cas d'utilisation de priorité haute ( ·· ··).

La spécification est écrite dans le fichier readme.md à la racine de votre projet GitLabEns avec les diagrammes *.pu dans le répertoire Diagrammes.

$ # positionnement dans le répertoire du projet
$ cd ...../csc4102-projet
$ # écriture du fichier Markdown readme.md avec le squelette de la spécification
$ emacs readme.md & # en arrière plan pour l'avoir toujours ouvert
$ # visualisation du fichier Markdown readme.md (pour les « \ », les tableaux, etc.)
$ ghostwriter readme.md & # en arrière plan pour l'avoir toujours ouvert
$ # ouverture du premier diagramme de cas d'utilisation
$ emacs Diagrammes/minisocs_uml_diag_cas_utilisation.pu & # aussi en arrière plan
$ # ouverture de la fenêtre PlantUML GUI de visualisation des diagrammes
$ (cd Diagrammes; ./visualiser.sh &) # encore en arrière plan
$ # à tout moment, génération des images *.svg et *.png
$ (cd Diagrammes; ./generer.sh)

Acteurs et cas d'utilisation

La première étape consiste à comprendre les aspects métier du système à réaliser en étudiant attentivement la section « 2 Cahier des charges » (et uniquement cette section avec l'annexe A) du cahier des charges. Cette lecture, que vous avez commencée avant la séance, doit permettre de délimiter les contours du système à réaliser : la méthode générale consiste à retrouver le ou les acteurs qui interagissent avec lui. Ensuite, recherchez les fonctionnalités du système par la définition de ces cas d'utilisation. Il est très important de fixer des frontières au problème en excluant les potentiels cas d'utilisation des fonctionnalités qui ne seraient pas demandées.

les diagrammes que vous ajoutez dans le document de spécification et de modélisation doivent être lisibles et toujours en mode portrait pour que nous effectuions des retours en lisant à l'écran le fichier readme.md. Pour ce faire, faites plusieurs diagrammes lorsque le nombre de cas d'utilisation devient tel que la lecture est mal aisée. Par ailleurs, veuillez respecter la structure du projet : les fichiers images des diagrammes sont à ajouter dans le répertoire Diagrammes.

Pour cette étape, aidez-vous de la méthodologie présentée dans la diapositive « 2.3 Éléments de méthodologie » du cours. Pensez aussi à parcourir les cas d'étude exemples dans le projet csc4102-exemples (le fichier de la spécification et de la modélisation e01-mediatheque.md et les diagrammes dans le répertoire Diagrammes).

Parmi vos cas d'utilisation, vous devez avoir les trois qui suivent (formulés tel quel ou avec vos mots) :

: « »,
: « »,
: « »,

Générer les images des diagrammes des cas d'utilisation avec make ou (cd Diagrammes; ./generer.sh) et insérez les images des nouveaux diagrammes des cas d'utilisation dans le fichier readme.md.

dans la suite des TP, nous ne rappellerons pas de manière systématique (1) que vous pouvez vous aider des exemples qui sont dans le projet csc4102-exemples, (2) qu'il faut que vous mettiez à jour votre fichier readme.md, et (3) qu'il faut que vous pensiez à ajouter à votre dépôt Git les images des diagrammes *.svg et *.png.

Priorités des cas d'utilisation

Il est déraisonnable de développer tous les cas d'utilisation dès les premières séances. Pour faire le choix, fixez une priorité (haute, moyenne, basse) à chaque cas d'utilisation. Voir le cours pour les règles d'établissement des priorités. Elles sont aussi rappelées dans le document de modélisation.

Dans le fichier readme.md, gardez la trace (sous forme textuelle) de toutes vos décisions concernant les priorités.

Préconditions et postconditions

Une fois que le choix des cas d'utilisation prioritaires a été fait, il est temps de préciser le rôle de chacun d'eux en définissant les données en entrée avec la précondition d'exécution ainsi que les données en sortie avec la postcondition.

Pour au moins trois cas d'utilisation de priorité « haute », dont (« »), (« »), et (« »), écrivez les préconditions et les postconditions.

Aidez-vous de la méthodologie présentée dans la diapositive « 3.3 Éléments de méthodologie » du cours.

Préparation des tests de validation

préparer les tests de validation d'au moins 3 cas d'utilisation ( ·· ··) , c'est-à-dire au moins 3 tables de décision ( ·· ··).

Tables de décision

Lorsque les préconditions et les postconditions des cas d'utilisation sont définies, les cas d'utilisation peuvent être développés. Avant de nous lancer dans ces développements, nous préparons les tests de validation qui permettront de vérifier que la mise en œuvre correspond à la spécification.

Pour au moins trois cas d'utilisation, dont (« »), (« »), et (« »), construisez la table de décision correspondante. Pensez à utiliser le menu Markdown de emacs : insertion de table, tabulation et alignement automatique, ajout de colonne, etc.

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.