Examen de Java

Ce document présente un examen de programmation Java portant sur la conception d’une application bancaire simple en réseau, utilisant des sockets. Il évalue les compétences en programmation orientée objet, gestion des flux, communication réseau bas niveau, et conception de protocoles d’échange de données.

Exercice 1 : Calculatrice

Il s'agit de réaliser une calculatrice simple en Java capable d'effectuer les opérations arithmétiques de base sur deux entiers, avec une interface en ligne de commande.

Le programme définit quatre méthodes statiques : somme, soustraction, multiplication, division, chacune prenant deux entiers en paramètres et retournant le résultat.

Dans la méthode main, une boucle infinie affiche un menu proposant les opérations, lit le choix de l'utilisateur, puis lit deux entiers. Selon le choix, l'opération correspondante est appelée et le résultat affiché.

Un point important est la gestion des entrées utilisateur avec BufferedReader et la conversion des chaînes en entiers avec Integer.parseInt. Le programme gère aussi la sortie lorsque l'utilisateur choisit "5".

Un problème dans le code est l'absence de "break" dans certains cas du switch, ce qui peut provoquer des erreurs d'exécution ou des résultats inattendus. Par exemple, dans le case 1, il manque un break avant le case 2, ce qui fait que la soustraction est aussi exécutée.

Réponse finale : Le programme fonctionne globalement mais nécessite l'ajout de "break" après chaque case pour éviter l'exécution en cascade des opérations.

Exercice 2 : Paquets à échanger

Il s'agit de concevoir une classe représentant un paquet de données pour le protocole bancaire utilisé dans la communication client-serveur par sockets.

La classe Account stocke les informations d'un compte bancaire : mot de passe, solde (balance) et historique des transactions (Vector transactions).

La classe BankSocketPacket contient les champs suivants :

• name : nom du compte
• operation : code de l'opération bancaire
• password : mot de passe
• amount : montant concerné

Les opérations sont codifiées par des constantes entières : OPEN = 0, CLOSE = -1, DEPOSIT = 1, WITHDRAW = 2, BALANCE = 3, QUIT = 4, etc. Les codes d'erreur sont aussi définis, par exemple EXISTANT = -1, NONEXISTANT = -2, INVPASSWORD = -3, NEGBALANCE = -4.

La méthode foldPacket transforme un objet BankSocketPacket en chaîne de caractères au format "name:operation:password:amount#", permettant son envoi sur le réseau.

La méthode unfoldPacket inverse cette opération en découpant la chaîne reçue pour remplir les champs de l'objet.

Un test est proposé (commenté) pour vérifier le fonctionnement du pliage et dépliage du paquet.

Réponse finale : La classe BankSocketPacket permet de sérialiser et désérialiser les paquets de données nécessaires à la communication bancaire par sockets.

Exercice 3 : Élaboration du serveur

Il s'agit de développer un serveur bancaire simple utilisant des sockets, capable de gérer plusieurs comptes et opérations bancaires.

Le serveur utilise une Hashtable pour stocker les comptes, identifiés par leur nom. Les méthodes principales sont :

• openAccount : ouvre un compte si le nom n'existe pas déjà, sinon renvoie une erreur EXISTANT.
• verify : vérifie l'existence du compte et la validité du mot de passe, renvoie l'objet Account ou null en cas d'erreur.
• closeAccount : ferme un compte après vérification, remet le solde à zéro et retourne le montant restant.
• deposit : ajoute un montant au solde et enregistre la transaction.
• withdraw : retire un montant si le solde est suffisant, sinon renvoie une erreur NEGBALANCE.
• getBalance : retourne le solde du compte.
• getTransactionHistory : retourne l'historique des transactions.
• sendPacket : envoie un paquet BankSocketPacket plié au client.

Le main crée une ServerSocket, accepte les connexions clients, puis lit les paquets reçus, les déplie et exécute l'opération demandée en appelant les méthodes correspondantes.

Le serveur gère les opérations OPEN, CLOSE, DEPOSIT, WITHDRAW, BALANCE, QUIT, en envoyant une réponse adaptée au client.

En cas de fermeture par le client, la socket est fermée proprement.

Réponse finale : Le serveur bancaire par sockets est capable de gérer les opérations de base sur les comptes en réseau, avec synchronisation pour éviter les conflits d'accès concurrent.

Exercice 4 : Élaboration du client

Il s'agit de développer un client Java capable de communiquer avec le serveur bancaire via sockets, en envoyant des paquets et en affichant les réponses.

Le client définit une classe FunnyMoney pour encapsuler un montant monétaire.

Des méthodes utilitaires permettent de saisir le nom du compte et le mot de passe depuis l'entrée standard, ainsi que de traiter les erreurs renvoyées par le serveur.

La méthode sendReceive envoie un paquet plié au serveur, attend la réponse, la déplie et affiche un message ou un message d'erreur selon le code reçu.

Dans la méthode main, le client se connecte au serveur (par défaut localhost:6789), puis entre dans une boucle où il demande une commande à l'utilisateur parmi open, close, deposit, withdraw, balance, history, quit.

Selon la commande, il demande les informations nécessaires (nom, mot de passe, montant), crée un paquet BankSocketPacket, l'envoie, et affiche la réponse.

La commande "history" affiche l'historique des transactions, mais cette partie semble incomplète dans le code fourni.

La commande "quit" ferme la connexion proprement.

Réponse finale : Le client permet d'interagir avec le serveur bancaire en réseau, en envoyant des commandes et en affichant les résultats ou erreurs, avec une interface en ligne de commande.

Méthode

Ce sujet récompense la maîtrise de la programmation orientée objet en Java, la gestion des flux d'entrée/sortie, la conception de protocoles simples pour la communication réseau via sockets, et la synchronisation pour la gestion concurrente des ressources partagées.

Il est essentiel de respecter la structure des paquets et les codes d'erreur définis, ainsi que de gérer proprement les exceptions et erreurs d'entrée utilisateur.

Les erreurs classiques à éviter sont :

• Oublier les "break" dans les switch, ce qui provoque des exécutions en cascade non voulues.
• Ne pas synchroniser l'accès aux données partagées (comptes), ce qui peut causer des incohérences.
• Ne pas gérer correctement les erreurs réseau ou les entrées invalides.
• Ne pas respecter le protocole d'échange des paquets (pliage/dépliage).

Enfin, la clarté du code, la gestion des exceptions et la robustesse face aux entrées utilisateur sont des critères importants pour la réussite.