Le backend

Le backend est codé en Java et se retrouve dans le cadre bleu de la figure 4. C’est lui qui est responsable de la logique métier. Les actions exécutées en base de données sont aussi exécutées par le backend. On distingue aussi trois couches dans cette partie du programme, les web-services, la logique métier et l’accès aux données.

FIGURE4 – Architecture logicielle d’e-Paprika La couche de services web

Cette couche permet de dialoguer avec le frontend. C’est la couche la plus proche de l’utilisateur, elle propose un certain nombre de services basés sur l’architecture REST (REpresentational State Transfer).

Cette architecture est construite autour du protocole HTTP pour dialoguer entre le client et le serveur. On utilise la requête HTTP et ses composantes pour interroger le web-service. Une réponse basée sur le protocole HTTP est utilisée pour récupérer les informations. Lors de la requête, le verbe du protocole HTTP est utilisé pour décrire le type d’action qui est associé à un web-service.

On dénombre 4 actions (ou verbes) différentes dans l’application dans ce fonctionnement. Les quatre sont utilisées dans e-Paprika. Cependant, ce n’est pas directement la couche de web services qui s’occupe de ces actions. Cette couche a juste pour vocation d’interpréter la requête et de fournir la réponse renvoyée par le modèle.

• L’action GET implique une opération sans effet sur l’application, elle est dite neutre. On re- trouve sous ce verbe essentiellement des accès aux données en lecture.

• L’action POST implique une création de ressource dans l’application. Ces actions initialise un identifiant pour la ressource créée de manière à pouvoir interagir avec.

• L’action PUT est le premier verbe qui permet d’interagir avec une ressource existante, il im- plique une mise à jour de la ressource. On retrouve donc un identifiant de ressources.

• L’action DELETE implique une suppression de ressource. On retrouve aussi un identifiant dans les données de la requête.

Les notions de création, de mises à jour ou de suppression peuvent se traduire par des actions en bases de données ou sur un système de fichiers.

En plus de l’action, il y a deux autres composantes principales dans la requête HTTP. L’URL identifie une ressource unique dans le logiciel, elle doit être le plus explicite possible quant à son utilité. Pour être plus précis, c’est le couple identifiant/verbe qui doit être unique.

Enfin, la ressource permet de véhiculer l’information. Dans e-Paprika, le format choisi est le JSON, qui permet un dialogue très facile entre les différents langages utilisés avec une structure qui est suffisamment verbeuse pour être comprise, mais qui offre de la souplesse et de la légèreté. Enfin, la couche Web-services gère la "sécurité", c’est-à-dire l’authentification et les autorisations d’un utilisateur. Chaque service vérifie les autorisations de l’utilisateur courant pour son action.

La réponse du web services s’articule autour de deux composantes essentielles. Le code réponse HTTP et le corps de la réponse. Le corps de la réponse est au format JSON et contient les informations utiles que l’utilisateur a demandées. Le code HTTP donne le statut de la réponse. On retrouve les codes les plus connus tels que

200 : Requête traitée avec succès

401 : Ressource non autorisée pour l’utilisateur actuel 403 : ressource interdite.

404 : URL non trouvée 500 : erreur du serveur 503 : service indisponible

La logique métier

La couche de logique métier implémente les fonctionnalités du logiciel. C’est un ensemble de classes Java qui est responsable de toute la logique du logiciel, les différents choix fonctionnels sont toujours pris à ce niveau.

C’est aussi la couche qui est la plus testée. Les tests dans e-Paprika se font essentiellement au- tour de la bibliothèque jBehave qui permet de scénariser les tests. De cette manière, le logiciel peut être développé selon le principe du développement dirigé par le comportement aussi appelé BDD (Behavior Driven Development).

L’accès aux données

e-Paprika se base sur deux sources de données. Une base MySql est utilisée pour les données métier. La solution Lucene/Solr, un moteur d’indexation de texte, est utilisé pour pouvoir faire des recherches plus rapidement. Les objets utilisés dans cette couche n’ont pas de comportement.

Dialogue entre les 3 couches

Le lien entre les trois couches se fait grâce à l’injection de dépendances. L’injection de dépen- dances est un patron de conception logiciel qui permet à un objet d’en utiliser un autre dynamique- ment plutôt que statiquement. En effet, l’injection de dépendances se fait au moment de l’exécution et non directement dans le code. Une classe peut en utiliser d’autres via une interface.

Par rapport à l’architecture décrite dans les paragraphes précédents, on retrouve donc principale- ment les injections suivantes.

• Les DAOs (i.e DAO = objet pour accéder aux données) dans les Services (i.e objet pour gérer la logique métier)

• des Services dans les Controllers (i.e objet pour exposer une fonctionnalité via HTTP-JSON) Cependant, il faut bien prendre en compte que le dialogue est unidirectionnel. En effet, la couche d’accès aux données ne peut pas utiliser les Services ni les Controllers tandis que la couche de logique métier ne peut pas utiliser les Controllers. Cet aspect unidirectionnel est le principe fondamental du backend. Ceci permet en effet de garder une cohérence dans les développements et une robustesse de l’application.

Pour résumer, l’injection de dépendances apporte trois aspects. En premier lieu, cela permet de réduire le couplage entre les différentes classes et d’augmenter la cohésion. En effet, chaque classe à une et une seule responsabilité, ce qui apporte aussi une meilleure réutilisation du code. En se- cond lieu, elle améliore la testabilité des classes. Il est en effet facile de fournir des collaborateurs fictifs à une classe afin de prédire son comportement dans un test unitaire. Enfin, le troisième point apporté est l’augmentation de la maintenabilité. Il n’y a pas d’effet de bord lors de la modification de l’implémentation puisque ce sont des interfaces qui sont injectées.