Analyse des travaux de l’état de l’art

Afin de récapituler, comparer et analyser les travaux de l’état de l’art, concernant l’élaboration des systèmes décisionnels via une architecture MDA, nous avons établi des critères de comparaison relatifs à chaque phase du cycle de conception du DSS. Le tableau 2.1 récapitule et synthétise l’analyse de ces travaux selon les critères retenus:

- Type de la démarche adoptée : Dirigée par les données (Données), dirigée par les besoins utilisateurs (BU), dirigée par les buts (Goal) ou mixage des besoins utilisateurs et des sources de données (Mixte)

- Modélisation des exigences de haut niveau (ER) - Modélisation des exigences de bas niveau (LR)

- Passage ER à LR : peut être automatique(A), semi-automatique (SA) ou manuelle (M) - Restriction des relations dans les modèles ER et LR

- Représentation du modèle PIM (conceptuel)

- Traitement de la relation plusieurs-à-plusieurs dans le modèle PIM

- Passage CIM à PIM : peut être automatique(A), semi-automatique (SA) ou manuelle (M) - Représentation du modèle relationnel

- Représentation du modèle OLAP

- Traitement de la relation plusieurs-à-plusieurs dans les modèles PSMs

- Passage PIM à PSM : peut être automatique(A), semi-automatique (SA) ou manuelle (M) - Description de la plateforme cible

54

- Implémentation OLAP

- Méthode de génération du code final : peut être automatique(A), semi-automatique (SA) ou manuelle (M)

- Collecte des métadonnées pour la traçabilité et la documentation du système: peut être automatique(A), semi-automatique (SA) ou manuelle (M)

Le caractère «-» désigne que l’aspect en question n’a pas été traité.

Tableau 2.1 Récapitulatif des travaux de l'état de l'art

Critères de comparaison Lujan Mora et al Mazon, Pardillo et al Zepeda et al Blanco et al Neil et al Atigui et al Soler et al

Type de démarche BU Goal Mixte BU Données Mixte BU

Niveau CIM

Modélisation ER - Modèle SD graphe GRT - - - i*

Modélisation LR - Modèle SR Diagramme d’activité

- - - -

Passage ER à LR - SA M - - - -

Restriction des relations - Oui Non - - - -

Niveau PIM

Métamodèle UML UML MD CWM UML Graphe

temporel

UML UML

Traitement de la relation plusieurs-à-plusieurs

Oui Oui Non Non Non Non -

Passage CIM à PIM - SA A - A M -

Niveau PSM

Modèle Relationnel - CWM - - CWM E/A CWM

Modèle OLAP - MD CWM - Secure

OLAP-CWM - - - Traitement de la relation plusieurs-à-plusieurs - - - - - - - Passage PIM à PSM - A - A A A A Description de la plateforme cible - - - - - - - Implémentation Relationnelle SQL SQL SQL SQL SQL - SQL OLAP - - - Fichiers XML - - -

La MDA dans le développement des projets décisionnels

55

2.8. Conclusion

Etant donné tous ses avantages, l’architecture MDA est l’une des approches les plus utilisées dans la littérature pour la conception et la mise en place des projets décisionnels. En effet, en plus de l’automatisation du processus de développement, la MDA garantit la portabilité et l’interopérabilité des applications en plus de l’amélioration de la productivité des développeurs et la réduction des tâches de maintenance. Elle permet ainsi de réduire le coût et le délai de mise en place et de maintenance des projets.

On constate, toutefois, l’absence d’une approche globale qui traite tous les aspects de mise en place d’un DSS. En effet, au niveau de la définition des besoins utilisateurs, la description des sources de données dans toutes les méthodes proposées, n’est pas intégrée dans le modèle CIM. La réconciliation avec les sources de données se fait alors en postériori, ce qui peut entraîner une révision des besoins utilisateurs après leur validation. De plus, les méthodes utilisées, comme i* et GRT, présentent l’inconvénient de complexité et d’illisibilité une fois les besoins utilisateurs s’élargissent. Ajoutant aussi l’absence de mécanisme de contrôle de bonne forme du modèle conçu. D’une autre part, au niveau de la phase de modélisation logique et physique, on constate que toutes les approches proposées se sont focalisées sur le modèle relationnel du DW, en générant le schéma des tables ainsi que le code SQL relatif à la création de ces dernières, alors que le modèle OLAP a été négligé. Le seul travail ayant traité l’implémentation des cubes OLAP a traité, cependant, la génération des fichiers système relatifs au cube, dimensions et rôles au lieu de générer le code d’implémentation. De plus, les fichiers générés ne contiennent pas la description relationnelle nécessaire à la création des composants OLAP comme la table, la colonne et la taille associées à chaque attribut de dimension. On cite également l’absence de modèle décrivant la plateforme OLAP cible pour permettre le passage automatique du PSM vers le code d’implémentation ainsi que la migration rapide d’une plateforme vers une autre. On remarque aussi que la traduction de la relation plusieurs-à-plusieurs au niveau du modèle logique n’a pas été traitée. Enfin, à l’exception de l’approche proposée par (Jovanovic et al, 2014) (voir chapitre 1), toutes les autres approches n’ont pas traité la collecte et la sauvegarde des métadonnées pour assurer la documentation et la traçabilité dans les DSS.

Collecte des Métadonnées et documentation du système

56

Pour remédier à tous ces problèmes, nous proposons une approche de modélisation et de mise en place des systèmes décisionnels, basée sur l’architecture MDA. Notre approche mixte, orientée buts, a pour objectif de fournir les outils permettant d’assister les décideurs à définir leurs besoins en termes d’analyse par rapport à leurs buts stratégiques. Elle a pour but aussi, de surpasser les verrous technologiques et les outils BI représentant des boites noires, grâce à l’automatisation du processus de développement en allant jusqu’à la génération du code final. Notre approche traite aussi l’exploitation des modèles de l’architecture MDA pour la collecte des métadonnées et la documentation du DSS.

57

Chapitre 3