ATELIER 2 PORTFOLIO MEDIATEK86

Objectifs : Tâches à réaliser
Récupérer le cahier des charges officiel qui concerne toute l’application (vous devez juste le récupérer pour l’insérer ensuite dans votre portfolio : une partie des besoins a été confiée à un autre développeur, c’est le dossier documentaire qui contient vos missions).
Récupérer le document missions qui présente les missions qui vous sont confiées.
Récupérer le schéma conceptuel de données au format looping (à ne pas exploiter pour générer du script mais juste pour utiliser et faire évoluer le schéma, pour l’insérer ensuite dans le compte rendu).
Si ce n’est pas déjà fait, installer les outils nécessaires pour gérer et tester l’API en local (NetBeans, WampServer, Postman).
Récupérer l’ API REST actuelle sur le dépôt distant (le zip).
Une fois le fichier zip du code récupéré, le dézipper dans le dossier www de wamp. Renommer le dossier en « rest_mediatekdocuments » (donc en enlevant « _master »). Ouvrir une fenêtre de commande en mode « admin », se positionner dans le dossier de l’api et taper « composer install ».
Récupérer le script metiak86.sql en racine du projet puis, avec phpMyAdmin, créer la BDD mediatek86 et, dans cette BDD, exécuter le script pour remplir la BDD.
Ouvrir l’API dans NetBeans pour pouvoir analyser le code et travailler dessus par la suite.
Si ce n’est pas déjà fait, installer Visual Studio et ajouter les extensions nécessaires : SonarQube for IDE, Specflow, newtonsoft.json. Pour ce dernier, voir l’article « Accéder à une API REST à partir d’une application C# » sur le dépôt de l’application C#. Consulter juste le début : la suite permet de comprendre le code existant.
Récupérer l’application C# actuelle sur le dépôt distant (le zip).
Lire le readme du dépôt qui contient la description de l’application actuelle et comment l’installer.
Une fois le fichier zip récupéré, le dézipper dans un dossier. Renommer le dossier en « mediatekdocuments » (donc en enlevant « _master »). Le dossier doit contenir le sln.
Ouvrir l’application sous Visual Studio et la lancer pour tester l’ensemble de ses fonctionnalités. Si vous obtenez une erreur sur HttpContent, ajoutez le package Nuget « Microsoft.aspnet.webapi.client ». Si avant de lancer l’application, des erreurs sur newtonsoft apparaissent, tenter tout de même de lancer l’application : les erreurs devraient disparaitre.
Prendre le temps de bien analyser le code existant car il va falloir respecter sa structure et être en mesure de réutiliser des méthodes existantes, voire de s’en inspirer pour créer de nouvelles méthodes.
Créer 2 dépôts sur votre propre compte GitHub, chacun lié à une application.
Dans votre compte GitHub, créer un projet Kanban et le lier au dépôt C#. Le remplir de toutes les tâches prévues (en insérant les tâches dans les « issues » et en les plaçant dans la colonne « to do »). Par la suite, au démarrage de chaque tâche, il faudra la faire glisser dans la colonne « In Progress » puis, une fois la tâche terminée, la faire glisser dans « done ».

Objectifs
L’application doit permettre d’ajouter, modifier ou supprimer des documents, sous certaines conditions. Les
documents concernés sont les livres, les DVD et les revues.
L’ajout d’un document ne suppose pas forcément une commande, même s’il intervient classiquement au moment
d’une commande. Dans cette mission, on ne s’occupe pas encore des commandes.
La modification d’un document ne peut pas porter sur son numéro.
La suppression d’un document n’est possible que s’il ne possède aucun exemplaire ni commande. Cela permet
d’éviter les accidents de suppression.

Objectifs
Tâche 1 : gérer les commandes de livres ou de DVD (8h)
Il doit être possible de commander un ou plusieurs exemplaires d’un livre ou d’un DVD et de suivre l’évolution
d’une commande.
Une commande passe par différents stades :
au moment de son enregistrement, elle est « en cours » ;
au moment de sa réception, elle est « livrée » ;
une fois livrée, le paiement est effectué, elle est alors « réglée » ;
dans le cas où la livraison tarde, la commande est « relancée » (ce qui provoque un envoi de mail au fournisseur :
cet aspect n’est pas à gérer) ;
La gestion des stades n’a pas encore été modélisée dans la base de données actuelle : vous devez donc vous en
charger.
L’application doit permettre de voir, pour les livres ou les DVD, la liste des commandes et gérer le suivi.
Lorsqu’une commande de livre ou de DVD est « livrée », il faut que les exemplaires concernés soient
automatiquement générés dans la BDD, avec un numéro séquentiel par rapport au document concerné.
Une commande doit pouvoir être supprimée si elle n’est pas encore livrée.
Tâche 2 : gérer les commandes de revues (4h)
Il doit être possible de commander une revue. Une commande de revue revient à réaliser un abonnement (ou un
renouvellement d’abonnement, ce qui revient au même).
L’application doit permettre de voir la liste des commandes, même pour les abonnements expirés. Une commande
ne peut être supprimée que si aucun exemplaire (parution) lié à cette commande n’est enregistré.
Au démarrage de l’application, une petite fenêtre doit s’ouvrir automatiquement pour afficher les revues dont
l’abonnement se termine dans moins de 30 jours.

Objectifs
L’application doit permettre de gérer l’état des documents physiques, donc des exemplaires.
Aussi bien pour les exemplaires de livres, de DVD et de revues (donc les parutions), leur création les met dans
l’état « neuf ». L’application doit permettre de changer l’état (« neuf », « usagé », « détérioré », « inutilisable »).
Il doit être possible de supprimer un exemplaire.

Objectifs
Il existe plusieurs services dont les employés ne doivent pas avoir les mêmes droits d’accès aux fonctionnalités de
l’application.
Les employés du service administratif gèrent les commandes. Ils ont aussi accès à la consultation et la mise à jour
du catalogue (livres, DVD, revues). Donc ils ont accès à toutes les fonctionnalités de l’application.
Les employés du service Prêts s’occupent des prêts de documents, des retours, de l’étiquetage et du rangement
dans les rayons. Ils ont accès en consultation seulement au catalogue (livres, DVD, revues) disponible.
Les employés du service Culture organisent divers évènements (conférences, expositions, lecture aux enfants,
etc..) et gèrent la venue d’intervenants pour ces évènements. Ils ne doivent donc pas avoir accès aux
fonctionnalités de cette application.
L’administrateur a accès à toutes les fonctionnalités de toutes les applications.
Dans le cadre d’une première version du système d’authentification, le but est de gérer les employés (avec
login/pwd) et les services directement dans la base de données.
L’application doit donc démarrer sur une authentification qui permet de déterminer si l’employé est reconnu et son
service d’affectation.
Suivant le service d’appartenance de l’employé, certaines fonctionnalités ne seront pas accessibles. Dans le cas
des employés du service Culture, un message doit les informer que cette application n’est pas accessible pour eux

Objectifs
Tâche 1 : corriger des problèmes de sécurité (2h)
Pour chaque problème, créer une « issue » dans le dépôt GitHub correspondant, affecter l’issue à un des
développeurs (si vous êtes 2, vous ou votre collègue, sinon vous-même), créer une branche pour proposer une
correction de code en expliquant la correction, faire un pull request, accepter le pull request si le résultat
correspond bien aux attentes.
Problème n°1 :
Actuellement, l’accès à l’API se fait en authentification basique, avec le couple « login:pwd » en dur dans le code de
l’application (dans le constructeur de la classe Access). Le but est de sécuriser cette information.
Problème n°2 :
Si, pour accéder à l’API directement dans un navigateur, on donne juste l’adresse de l’API sans mettre de
paramètres :
http://localhost//rest_mediatekdocuments/
on obtient la liste des fichiers contenus dans le dossier de l’API. Le but est d’avoir un retour d’erreur.
Tâche 2 : contrôler la qualité (1h)
Le code d’origine a été nettoyé en suivant les conseils de Sonarlint/SonarQube et des avertissements de Visual
Studio. Le seul point qui n’a pas été corrigé est le nom des méthodes événementielles, qui commencent par une
minuscule car les objets graphiques commencent par une minuscule.
Excepté ce point, les règles d’écriture de code sont les règles standards.
Le but est donc de nettoyer le code ajouté en suivant la même logique.
Il faut aussi transférer dabs App.config, les informations d’authentification pour l’accès à l’API en ligne (qui se
trouvent actuellement en clair dans Access).
Tâche 3 : intégrer des logs (1h)
Dans la classe Access, tous les affichages console doivent être aussi enregistrés dans un fichier de logs.

Objectifs
Tâche 1 : gérer les tests (5h)
Tests unitaires :
Écrire les tests unitaires sur les classes du package Model.
Tests fonctionnels :
Construire une collection de tests dans Postman pour contrôler toutes les fonctionnalités de l’API d’accès à la
BDD.
Tâche 2 : créer les documentations techniques (1h)
Générer les documentations techniques correspondant à l’application C# et à l’API REST.
Tâche 3 : créer la documentation utilisateur en vidéo (2h)
Créer une vidéo de 10mn maximum qui présente l’ensemble des fonctionnalités de l’application C#.

Objectifs
Tâche 1 : déployer le projet (3h)
Mettre en ligne l’API et la base de données (chez un hébergeur ou dans une VM Azure).
Créer un installeur de l’application C# pour qu’elle puisse s’installer facilement.
Tâche 2 : gérer les sauvegardes des données (1h)
Automatiser une tâche de sauvegarde quotidienne de la BDD.

Objectifs
Tâche 1 : construire le compte rendu
Tâche 2 : remplir le readme des deux dépôts
Tâche 3 : créer une page portfolio dédiée à cet atelier