Modélisation adaptée aux besoins utilisateurs dans le développement des SID

1. Modélisation adaptée aux besoins utilisateurs dans le développement des SID Estella Annoni, Franck Ravat, Olivier Teste, Gilles Zurfluh IRIT – Toulouse {annoni, ravat, teste, zurfluh}@irit.fr

2. Plan • État de l’art • Contexte des travaux • Étape de l’analyse des besoins • Collecte des besoins utilisateurs • Formalisation des besoins utilisateurs • Règles de structuration • Conclusion et perspectives

3. Classification des méthodes • Approche ascendante (data-driven) • Lourde avec des sources volumineuses • Pas de prise de compte des besoins utilisateurs • Approche descendante (requirement-driven) • Schémas impossibles à mettre en œuvre • Approche mixte • Prise en compte des utilisateurs et des sources • Pas de méthode d’analyse des besoins utilisateurs

4. Contexte des travaux • Collaboration avec la société I-D6 spécialisée dans le décisionnel • Focalisation sur les besoins utilisateurs / {pilotage, équipement} • Expression de besoins analytiques • Table multidimensionnelle • expression intuitive et la moins informelle • expression inadaptée pour la confrontation • Besoin de formaliser les informations ainsi que les traitements

5. Contexte de la proposition

6. Collecte des besoins utilisateurs (1) • Entrée : Documentation projet {manuel utilisateurs, spécifications de l’application métier} • Sortie : {Dictionnaire décisionnel} • 1- Sélection • requêtes multidimensionnelles pertinentes exprimées en BI-Query Analyser Immobilisations.Valeur_vénale Analyser {S.Cr}+ QuandImmobilisations.Valeur_vénale >1000 Quand {Cond(S.Cr)}+ En Fonction Catégories.Familles, Catégories.Sous-familles En Fonction {Ai.EkAi} Temps.Année Pour Temps.Année Dans (2003, 2004, 2005); Pour {Cond(Ai.EkAi)}+ • tables multidimensionnelles pertinentes

7. Collecte des besoins utilisateurs (2) • Entrée : {Tables multidimensionnelles, interviews utilisateurs relatifs aux processus ETL} • Sortie : {Diagrammes décisionnels} • 2- Réalisation du dictionnaire décisionnel • Etude des lignes et des colonnes des tables multidimensionnelles • Définition des paramètres des traitements ETL (Extraction Transformation Chargement) Y : année courante y : année traitée

8. Formalisation des besoins utilisateurs (1) • Caractéristiques du modèle • Intégration des spécificités des besoins analytiques • Proche de la vision de l’information par les décideurs • Extension du diagramme de classes UML pour garantir la réutilisation des schémas • Prise en compte des informations et des traitements • Spécification des traitements ETL • Concept de propriété d’informativité • h : attribut historisé • a : attribut archivé • * : attribut rafraîchi • c : attribut calculé

9. Formalisation des besoins utilisateurs (2) • Association d’un comportement à un attribut • Attribut : une classe à part entière [luján-Mora et al, 2004] • Limite : impossibilité d’associer une méthode à une classe-attribut • Proposition : Définir des méthodes attribut avec le stéréotype <<attribut>> • Association d’un traitement à chaque propriété • Historiser(p, c, cond) Historiser (annee,Y>y-3 and Y<y) • Archiver (p, c, cond, fct) Archiver(annee, Null, Y>y-5 and Y<y-1,sum) • Rafraîchir (cond, m) Rafraîchir(y<>Y, merge) • Calculer ({vi}+) Calculer(Valeur_venale, Valeur_achat, amortissement) • Modèle du diagramme décisionnel (DD)

10. Règles de structuration • Règles de transformation • Passage de la table multidimensionnelle au DD • Règles syntaxiques • Validation de la cohérence et consistance des DD • Règles de fusion • Fusion des DD suivant l’environnement du projet

11. Règles de transformation • Environnement • Fait et mesures • Informations • Traitements • Dimensions et paramètres • Informations • Traitements

12. Règles syntaxiques • Informations • SDI1 & 2 : Une classe-dimension, classe-fait ne peut pas être reliée respectivement à une autre classe-dimension, classe-fait • SD3& 4: A tout paramètre et mesure est associé la propriété d’informativité d’ historisation sur l’exercice précédent • SD5: Si un attribut possède la propriété d’informativité « * » alors la classe possède la propriété aussi • Processus • SDP1: Si la propriété d’informativité porte sur tous les attributs de la classe et avec les mêmes paramètres alors la méthode est spécifiée au niveau de la classe • SDP2 : Si une des mesures du fait possède la propriété d’informativité « h » et « a » alors toutes les dimensions liées doivent posséder cette propriété

13. Règles de fusion • DD ayant la même classe-fait et des dimensions en commun • FUS1 : Fusionner les classes-dimension par ajout des attributs et des méthodes • FUS2 : Fusionner les classes-fait par ajout des attributs et des méthodes • DD ayant des classes de classes-fait différentes et des dimensions en commun • FDS1 : Fusionner les classes-dimension par ajout des attributs et méthodes

14. Conclusion • Proposition d’une méthode pour l’analyse des besoins utilisateurs • A partir de tables ou requêtes multidimensionnelles • Mécanisme basé un 3 types de règles • Diagramme décisionnel : • modèle proche de la vision des décideurs • Prise en compte des besoins • Information et Traitements • Possibilité de réutiliser les schémas générés

15. Perspectives • Analyse des besoins de Pilotage et Équipement • Automatisation de l’étape de l’analyse • Faciliter la tâche de confrontation • Prise en compte des hiérarchies dès l’étape de l’analyse des besoins

16. Merci • Contact : annoni@irit.fr