Phase de restructuration du code

Les remarques émanant de la phase d’analyse nous permettent d’envisager la restructuration du code ainsi que l’évolution de l’application.

Cette restructuration du code n’apporte pas de nouvelles fonctionnalités et ne modifie pas le fonctionnement du système en place. Elle va cependant largement faciliter l’intégration des nouveautés comme l’utilisation d’un Framework Web pour la partie interface graphique qui impose une certaine architecture.

5.1.1 Points de restructuration envisagés

• Vers un modèle en couches : afin d’assurer une meilleure évolutivité et modularité du système et de limiter le couplage entre les packages.

les souscriptions, les items et les termes.

• Découpage et renommage en plusieurs classes de la classe Matching.

• Éliminer les redondances de code : si nécessaire intégration de classes abstraites. • Intégration d’interfaces offrant notamment la possibilité d’avoir plusieurs

implémentations pour certaines parties du code.

5.1.2 Nouvelle architecture logicielle

L’architecture d’origine ayant subi beaucoup d’évolutions, nous nous limiterons à présenter des modèles simplifiés afin d’en améliorer la compréhension et la lisibilité.

Nous présentons l’architecture globale dans un premier temps pour ensuite zoomer sur certaines parties qui semblent assez pertinentes pour la compréhension.

Même si nous tentons de respecter les communications entre les couches comme cela est préconisé par les démarches d’architecture logicielle telles qu’elles ont été décrites précédemment, on reconnaîtra que la réalité de l’architecture proposée diverge en certains points avec la théorie. En effet vouloir se conformer strictement à la théorie nécessite, dans le cadre du projet, un alourdissement du code avec potentiellement des risques de baisser le niveau de performance de l’application. Cependant nous nous efforçons d’utiliser une interface pour toutes les communications inter-couches.

Comme nous l’avons évoqué dans la partie précédente, chercher à tous prix à s’abstraire du SGBD (MongoDB en l’occurrence), nécessite un gros effort de réécriture de code. Le système de notifications développé repose, dans sa forme actuelle, sur le framework MapReduce. Si le concept MapReduce est le même quel que soit le SGBD utilisé, la manière d’écrire les requêtes et le langage utilisé peuvent varier complètement d’un système à un autre. En outre, changer de SGBD reviendrait à réécrire complètement l’ensemble des requêtes MapReduce, faisant ainsi perdre la logique de ré utilisabilité du code. Chercher le plus haut niveau d’abstraction possible ne fait donc pas partie des objectifs du projet.

Le modèle d’architecture en couches du projet

la couche Service si besoin. Pour ce faire, les modifications interviendront alors au niveau de la couche de coordination.

Le diagramme de paquetages ci-dessous (illustration 22) va nous permettre d’illustrer nos différentes couches. Pour des raisons de lisibilité, ce diagramme est allégé. La priorité est mise sur la représentation des interfaces quand elles sont présentes. Dans ce cas il faut considérer qu’il existe aussi les classes « concrètes » les implémentant.

Remarque : l’organisation des paquetages illustre bien le sens unique d’utilisation des éléments du dessous. Par exemple le paquetage Beans, impliqué dans les couches Présentation et Coordination, s’il venait à être modifié ou supprimé, ne remettrait pas en question le fonctionnement des autres paquetages.

Composition des couches et des niveaux (tiers) mis en œuvre

• Présentation et coordination : ces couches vont gérer toute la partie Web. D’une part, le navigateur Web de l’utilisateur sur lequel nous n’intervenons pas. D’autre part, la partie contrôleur et modèle au sens Modele-Vue-Controleur tel que nous l’avons déjà présenté. C’est au niveau de ces deux couches que le framework JSF est mis en œuvre. Nous reviendrons plus en détail ultérieurement sur l’implémentation de JSF. C’est en l’occurrence le paquetage beans qui représente le Modèle. La partie contrôleur du MVC est masquée dans le framework.

• Domaine : c’est au travers de cette couche que l’on retrouve toute la logique métier de l’application. Elle est représentée par les paquetages matching, entity et converter. • Persistance : cette couche prend en charge toutes les interactions avec les supports de

stockage. Le package dao est le seul à accéder à la base de données pour réaliser toutes les opérations de bases (lecture, création, modification, suppression), ainsi que la création des index dans la base.

• Couches transverses : nous plaçons le paquetage util à ce niveau étant donné son rôle transverse.

Remarques concernant le diagramme de paquetages

Il ne semble pas nécessaire de revenir sur le rôle des paquetages qui existaient déjà dans la première architecture. Concentrons-nous plutôt sur les évolutions. Nous laissons de côté pour l’instant le paquetage beans, impliqué dans l’interface Web, puisque nous y reviendrons plus en détails quand on abordera le framework JSF.

pour éviter la redondance de code.

• I_TestMatching : c’est l’interface de TestMatching exposée pour être utilisée par les couches supérieures.

• MapReduce Request : toutes les commandes (requêtes) MapReduce présentes dans la précédente classe SimpleMatching sont regroupées dans cette classe. Cette classe est utilisée par TestMatching.

• MapReduce Function : on retrouve dans cette classe les fonctions MapReduce nécessaires au Matching. Cette classe ne produit que des chaînes de caractères qui sont utilisées par les commandes MapReduce.

Paquetage converter : l’évolution notable de ce paquetage est l’intégration d’interfaces. Cela a permis diverses implémentations. Ce paquetage est chargé du formatage des souscriptions, des items et des termes. Les diverses implémentations permettent la prise en charge des éléments provenant de plusieurs sources (par exemple d’un flux RSS) et non plus uniquement d’un fichier stocké dans un répertoire.

Paquetage entity : au-delà du fait que des interfaces représentant un item, une souscription ou un terme soient exposées, de nouvelles classes ont été créées. Nous ne les détaillerons pas maintenant car, elles font partie des nouvelles fonctionnalités présentées plus tard. Il s’agit des classes utilisées pour gérer les statistiques et les fonctions MapReduce. Elles permettent entre autres de déclencher des opérations MapReduce et de configurer un workflow de fonctions

MapReduce imbriquées.

Paquetage dao : ce paquetage est nouveau. Comme son rôle est essentiellement de s’interfacer directement avec la base de données, la classe de connexion à la base a été placée à ce niveau. Cette classe aà d’ailleurs été rendue générique permettant ainsi de se connecter à n’importe quelle base MongoDB et d’accéder à n’importe quelle collection.

Paquetage util : ce paquetage était déjà présent. Nous le conservons dans son rôle transverse. La classe de connexion à la base de données n’étant pas transverse, elle a été déplacée vers le paquetage dao.