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

Séance 4 — TP : Conception détaillée et préparation des tests unitaires

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.

bien que les questions (ainsi que la présentation) figurent dans un certain ordre, revenez sur tous les éléments de spécification ou modélisation (diagrammes, etc.) pour les compléter ou les corriger. Il s'agit de l'élaboration d'une solution, qui passe nécessairement par une compréhension du problème tant d'un point de vue statique que d'un point de vue dynamique. Nous vous conseillons de noter les modifications/adaptations au fur et à mesure, mais d'attendre le hors présentiel pour les faire.

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

Conception détaillée

raffiner le diagramme de classes pour préparer la programmation,
dessiner le diagramme de machine à états d'au moins une classe, dont la classe (),
préparer la programmation des classes en parcourant les traductions (attributs et opérations).

1^er raffinement du diagramme de classes

nous vous suggérons de faire une copie de l'image de votre diagramme de classes de la conception préliminaire (copie du fichier source *.pu ainsi que des images *.svg et *.png) afin de vous permettre de visualiser en même temps les deux « versions ».

Reprenez le diagramme de classes de la conception préliminaire avec les raffinements suivants :

fixez les navigabilités pour, lorsque c'est pertinent, réduire la navigabilité de certaines associations. Pour ce faire, parcourez les diagrammes de séquence de la conception préliminaire pour repérer les associations que votre solution ne semble pas utiliser dans les deux sens. Les agrégations et les compositions sont les premières candidates naturelles : souvent, les agrégations et les compositions ne sont parcourues que de l'ensemble vers les éléments de l'ensemble ;
reprenez les agrégations pour savoir si les contraintes de la composition ne s'appliqueraient pas. Attention ! Ne les transformez en composition que si vous en êtes sûrs ;
si vous avez des classes d'association, traduisez-les pour faire apparaître les deux associations avec leurs multiplicités.

Remplacez le diagramme de classes de la séance précédente (conception préliminaire) par le nouveau diagramme (conception détaillée). Mettez à jour le fichier readme.md, etc.

Diagrammes de machine à états

Pour au moins une des classes importantes, dont la classe (), construisez un diagramme de machine à états (). Ne conservez que les états ayant une certaine stabilité dans le temps ou bien les états pendant lesquels de nombreuses et/ou importantes actions sont effectuées. Les états de type « en train de », « en cours de », etc., sont très intéressants car le comportement du système peut être spécifique : certaines actions sont déclenchées et d'autres sont interdites. Par ailleurs, rappelez-vous que les attributs booléens ainsi que ceux utilisant un type énuméré aident à déduire les états possibles.

si votre solution, c'est-à-dire votre diagramme de classes, ne comporte pas de classes correspondant à la classe (), discutez-en avec votre responsable de groupe pour choisir la classe la plus proche et en faire un diagramme de machine à états.

2^è raffinement avec la préparation de la programmation en parcourant les éléments de modèles à traduire et à programmer à la prochaine séance (attributs et opérations)

En guise de second raffinement avant le démarrage de la programmation :

pour au moins une des classes importantes, dont la classe (), collectez dans une fiche (dans le fichier readme.md) les attributs et les opérations de la classe en parcourant tous les diagrammes, et traduisez les associations, y compris les agrégations et les compositions, en attributs de la classe ;
traduisez les attributs dérivés si la classe en possède ;
fixez la visibilité ainsi que le type, voire les valeurs par défaut, des attributs.

les attributs traduisant les associations ne sont pas montrés dans le diagramme de classes. Ce raffinement est uniquement visible dans les fiches des classes du document readme.md.

Préparation des tests unitaires

construire les invariants ·· d'au moins une classe importante, dont la classe (),
construire les tables de décision des tests unitaires d'au moins deux opérations, dont les opérations (« ») et (« ») de la classe ().

Invariants

Pour au moins une classe, dont la classe (), écrivez la formule en logique propositionnelle de l'invariant de la classe.

Tables de décisions des tests unitaires

Pour au moins deux opérations, dont les opérations (« ») et (« ») de la classe (), construisez la table de décision des tests unitaires. Si vous n'avez pas d'opération (« »), discutez-en avec votre responsable de groupe : soit vous avez une opération équivalente soit votre modélisation ne se prête pas à la seconde table de décision.

Écrivez les tables de décision dans le fichier readme.md. (Rappelez-vous d'utiliser le menu Markdown de emacs pour l'écriture des tableau.)

Nous ne construisons pas les tables de décision de toutes les opérations de toutes les classes, soit parce qu'elles seraient relativement « triviales », soit par manque de temps. Mais, rappelez-vous le concept de dette technique : « developers sometimes accept compromises to meet an urgent demand [...] that such compromises incur a “debt” on which “interest” has to be paid ». Aussi, dans la suite du projet, lorsque la discussion sur l'algorithme ou sur la programmation d'une opération montre un désaccord, pensez à construire la table de décision et à programmer les tests unitaires de la méthode.

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.