1 / 17

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

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. Plan. État de l’art Contexte des travaux Étape de l’analyse des besoins

diane
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related