:: Enseignements :: Master :: M1 :: 2016-2017 :: Programmation Orientée Objet - Design Patterns ::
[LOGO]

Exam de Design Patterns ( ENTRAINEMENT )

Ce TP noté dure 4h (aujourd'hui, 2h !).

Les schéma UML vous permettent d'obtenir des points, n'oubliez pas :

Exercice 1 - Console, Voyelle, ...

Votre entreprise veut développer une nouvelle gamme de routeurs configurables uniquement en console et vous avez été choisi (désigné/dénoncé) pour implanter l'application gérant la console permettant d'intéragir avec le matériel.
Dans la suite de l'exercice, on ne s'intéressera pas réellement aux fonctionnalités de la console en elle même mais à la façon dont il faut organiser le code autour des fonctionnalités suivantes
  • Autorisation d'accès à la console en fonction d'un login/mot de passe
  • Gestion de l'accès aux commandes, un administrateur devant accéder à plus de commandes qu'un utilisateur de base.
  • Mode debug qui permet d'avoir une sorte de mot de passe par défaut pour pouvoir tester la console

Un collègue a déjà réalisé un prototype utilisant le principe de signature SHA-256 pour authentifier les utilisateurs; ayant été affecté à un autre projet, il n'a malheureusement pas eu le temps de finir
Votre collègue mentionne aussi le fait que son code ne marche pas dans la console d'Eclipse car celle-ci n'est pas capable lire un mot de passe (sans l'afficher). Par contre, le code marche très bien dans un terminal.
Voilà les 3 classes qu'il a implantées
Dans le but de faciliter la correction, on vous demande de dupliquer le code en le mettant dans un package Java différent pour chaque question, console1 pour la question 1, console2 pour la question 2, console3 pour la question 3, etc.

  1. Dans un premier temps, on cherche à mettre en place l'authentification des utilisateurs. L'idée pour vérifier si un utilisateur a le droit de se connecter est d'utiliser un fichier qui contient par ligne un nom de login d'un utilisateur ainsi que son mot de passe haché en utilisant l'algorithme SHA-256 (écrit en hexadécimal).

    On vous rappel que en Java, lire un fichier ligne à ligne ce fait de la façon suivante: 
         try(Stream<String> lines = Files.lines(path)) {
      ...
     }

    Ecrire une classe UserManager avec une méthode qui vérifie qu'un utilisateur existe et qui si son mot de passe est correct renvoie un objet User correspondant. Modifier le Main pour tester que votre code marche.
    En terme de design, vous devez faire en sorte que, quelque soit la façon dont on utilise votre code, celui-ci ne doit pas permettre de créer un User sans que son login/mot de passe ait été vérifié.
    Le code que vous devez produire doit être dans le package "console1".
  2. On veut pouvoir déboguer l'application en lançant celle-ci dans un mode spécial en changeant la variable d'environnement CONSOLE_LOGIN_DEBUG à vrai. 
          export CONSOLE_LOGIN_DEBUG=true
    Dans ce cas, au lieu d'avoir la vérification standard de mot de passe basée sur le fichier passwords.txt, le code ne devra accepter qu'un seul login "root" avec le mot de passe vide "".
    Faite un diagramme UML de l'architecture que vous voulez mettre en place pour répondre à cette nouvelle problèmatique.
    Puis implanter ce que vous avez prévu dans le package "console2".
    Rappel, en Java, lire une variable d'environement se fait en utilisant System.getenv. 
          Boolean.parseBoolean(System.getenv("CONSOLE_LOGIN_DEBUG"));
  3. En fait, le problème du fonctionnement actuel est que l'on ne peut pas tester avec un autre utilisateur que "root" si la variable d'environement CONSOLE_LOGIN_DEBUG est vrai.
    On veut modifier le fonctionnement pour que si CONSOLE_LOGIN_DEBUG est vrai, l'authentification des utilisateurs se fasse comme habituellement et que si celle-ci echoue, alors l'authentification en utilisant l'utilisateur "root" avec le password vide est possible.
    L'idée ici est d'essayer une authentification et si celle-ci échoue, d'essayer une autre authentification.
    Proposer un design (avec le diagramme UML correspondant) permettant de répondre à ce problème.
    Si votre design est correct, vous devriez aussi être capable de gérer le cas où les logins/passwords sont répartis dans deux fichiers passwords1.txt et passwords2.txt.
    Implanter votre design dans le package "console3".
  4. En fait, certaines commandes comme release sont accessibles à l'administrateur ("admin") mais pas aux autres utilisateurs.
    Pour mettre ce nouveau comportement, l'idée est dans un premier temps, d'enregistrer les commandes puis dans un second temps de ne permettre d'exécuter que les commandes précédemment enregistrées. Puis, en fonction de l'utilisateur (administrateur ou non) d'enregister uniquement les commandes auxquelles cet utilisateur a accès.
    Dupliquer votre implantation dans le package "console4" et implanter les modifications.
  5. On veut avoir un fichier de log (si CONSOLE_LOGFILE est un Path) qui contient le résultat de l'ensemble des commandes exécutées lors d'une session,
    Le design devra aussi permettre d'afficher le résultat des commandes à la fois sur STDOUT et STDERR.
    Et il faudra aussi pouvoir donner le nombre d'appels pour chaque commande (en commençant par les commandes appelées le plus fréquemment). Note de Java : si on ne veut pas être embêté avec les IOException lors de l'affichage, on peut utiliser un PrintWriter (avec autoflush à true).
    Que doit-on modifier au niveau du design ?
    Faites le schéma UML définitif et implantez la solution que vous avez retenue dans le package "console5". Avez-vous mis un oeuvre un Design Pattern ?
© Université de Marne-la-Vallée