EDA 2006 1

Modélisation adaptée aux besoins utilisateurs dans le développement des SIDEstella Annoni, Franck Ravat, Olivier Teste, Gilles ZurfluhGilles Zurfluh

IRIT – ToulouseIRIT – Toulouse

{annoni, ravat, teste, zurfluh}@irit.fr{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

7

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-QueryAnalyser Immobilisations.Valeur_vénale Analyser {S.Cr}+ Quand Immobilisations.Valeur_vénale >1000 Quand {Cond(S.Cr)}+En Fonction Catégories.Familles, Catégories.Sous-familles En Fonction {Ai.EkAi}Temps.AnnéePour Temps.Année Dans (2003, 2004, 2005); Pour {Cond(Ai.EkAi)}+

tables multidimensionnelles pertinentes

8

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

9

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é

11

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)

12

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

13

Règles de transformation Environnement Fait et mesures

Informations Traitements

Dimensions et paramètres Informations Traitements

14

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é

16

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

17

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

18

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

19

Merci

Contact : annoni@irit.fr

20

Immobilisations.Valeur_Vénale Temps.Année

2003 2004 2005

Catégories.Famille Catégories.Sous-Famille

Immatériel Logiciels 115 999,26 69 059,42 173 170, 09

Progiciels 8 958,61 111 429, 69 63 769, 32

Postes Utilisateurs Ecrans 1 147,47 3 445,14 4624,12

PC 3 601,85 5 319,81 7 420,95

Terminaux 1 985,47 1 798,06 1 291,34

S.Cr Ai.El

Val1ElAi … ValmElAi

Ai.Ek

Val1EkAj {ValCrs(Val1EkAj, Val1ElAi)} {ValCrs(Val1EkAj, ValmElAi)}

Val2EkAj {ValCrs(Val2EkAj, Val1ElAi)} {ValCrs(Val2EkAj, ValmElAi)}

...

ValnEkAj {ValCrs(ValnEkAj, Val1ElAi)} {ValCrs(ValnEkAj, ValmElAi)}