D´ emarche : formalisation des besoins utilisateurs

Notre m´ethode d’analyse des besoins des acteurs du SID repose sur trois prin-cipales tˆaches qui sont la collecte des besoins, la formalisation des besoins et la confrontation des besoins. La figure4.3pr´esente l’ordonnancement s´equentiel de ces derni`eres.

La tˆache de formalisation des besoins bien que reposant sur le mˆeme mod`ele n’est pas commune `a tous les trois groupes car les besoins sont exprim´esvia des mod`eles diff´erents par les d´ecideurs et par acteurs syst`emes. Elle est commune uniquement aux groupes tactique et strat´egique.

La formalisation des besoins correspond `a la repr´esentationvia le diagramme d´ e-cisionnel. Pour passer des tableaux crois´es et du graphe de propri´et´es au diagramme d´ecisionnel d’un groupe de d´ecideurs, nous proposons un processus automatique de structuration des donn´ees et des traitements bas´e sur trois types de r`egles :

– les r`egles de transformation : elles permettent de d´efinir les diagrammes d´ eci-sionnels `a partir des tableaux crois´es,

– les r`egles syntaxiques : elles permettent de v´erifier que les diagrammes d´ e-cisionnels d´eriv´es sont coh´erents par rapport `a la d´efinition d’un diagramme d´ecisionnel,

– les r`egles de fusion : elles permettent de fusionner deux diagrammes d´ ecision-nels d’un mˆeme groupe d’acteurs ou de groupes d’acteurs diff´erents.

Le concepteur applique d’abord les r`egles de transformation des tableaux crois´es en diagrammes d´ecisionnels, puis les r`egles syntaxiques et enfin les r`egles de fusion.

La d´efinition de ces r`egles suppose que la s´emantique est fiable.

Pour chaque tableau crois´e type, il applique les r`egles de transformation relatives aux donn´ees, puis celles relatives aux traitements.

– R`egles de transformation de l’environnement du projet Ex : – Information EI :

– EI1: un diagramme d´ecisionnel est associ´e `a tout tableau crois´e type, – EI2 : tout tableau crois´e sp´ecifiant les besoins utilisateurs doit avoir une

structure proche de celle du tableau crois´e type(cf. tableau 4.1). Dans le cas contraire, il est transform´e en un tableau `a deux dimensions qui sont la dimension «Temps » et une des dimensions principales du domaine d’application li´e. Cette derni`ere est positionn´ee `a la valeur «All». – R`egles de transformation du fait Sx :

– Information SI :

– SI1 : une classe-fait avec le st´er´eotype << Fait >> est associ´ee `a tout fait,

– SI2: un attribut est associ´e `a toute mesure.

– Traitements SP :

– SP1 : une op´eration est d´efinie pour chaque traitement (applicable `a ce groupe en fonction du tableau 4.8) dont les propri´et´es associ´ees sont an-not´ees dans le graphe de propri´et´es,

– SP2 : une op´eration d’attribut est associ´ee `a toute mesure qui poss`ede des arguments diff´erents de ceux de la classe pour un traitement donn´e, – SP3: les concepts d’informativit´e sont associ´es aux attributs de la

classe-fait en fonction des traitements d´eclar´es.

– R`egles de transformation des dimensions Ai : – Information AI :

– AI1 : une classe-dimension avec le st´er´eotype << Dimension >> est as-soci´ee `a toute dimension,

– AI2: un attribut «Id» est associ´e `a chaque classe-dimension, – AI3: un attribut est associ´e `a tout param`etre,

– Traitements AP :

– AP1 : une op´eration est d´efinie pour chaque traitement (applicable `a ce groupe en fonction du tableau 4.8) dont les propri´et´es associ´ees sont annot´ees dans le graphe de propri´et´es,

– AP2: une op´eration d’attribut est associ´ee `a tout param`etre qui poss`ede des arguments diff´erents pour un traitement donn´e. La classe-dimension

«Temps» n’est g´en´eralement pas rafraˆıchie,

– AP3: les concepts d’informativit´e sont associ´es aux attributs de la classe-dimension en fonction des traitements d´eclar´es,

Puis, les r`egles syntaxiques sont appliqu´ees : – Information SDI :

– SDI1: une classe-dimension ne peut pas ˆetre reli´ee une autre classe-dimension, – SDI2 : une classe-fait ne peut pas ˆetre reli´ee `a une autre classe-fait,

– SDI3: `a toute mesure est associ´ee le concept d’informativit´e et le traitement d’historisation sur l’exercice pr´ec´edent pour l’analyse des tendances,

– SDI4: `a tout param`etre est associ´e le concept d’informativit´e d’historisation et le traitement sur l’exercice pr´ec´edent pour l’analyse des tendances.

– Traitements SDP :

– SDP1: si le concept d’informativit´e porte sur tous les attributs de la classe et avec les mˆemes param`etres alors l’op´eration li´ee est sp´ecifi´ee au niveau de la classe,

– SDP2 : si une des mesures du fait de l’analyse poss`ede les concepts d’in-formativit´e li´ee `a l’historisation «h» ou `a l’archivage «a» alors toutes les dimensions li´ees doivent poss´eder aussi cette propri´et´e. De plus, la p´eriode et la condition de l’op´eration associ´ee doivent ˆetre au moins ´egales `a celles de la mesure,

– SDP3 : l’op´eration «Rafraˆıchir()» ne doit pas ˆetre appliqu´ee `a la dimen-sion temps car elle est initialis´ee pour assurer tout le cycle de vie du SID.

A partir de ces diagrammes d´ecisionnels, le concepteur d´ecisionnel applique les r`egles de fusion afin de simplifier la confrontation des besoins en manipulant le moins de diagrammes possible, soit un diagramme par groupe d’acteurs, il convient de les fusionner `a l’aide des r`egles associ´ees. Le diagramme d´ecisionnel obtenu (´etoile ou constellation) varie suivant les possibilit´es de mise en commun des classes-dimensions et des classes-faits, autrement dit suivant la logique de l’organisation.

– FUS : regrouper les diagrammes d´ecisionnels ayant les mˆemes classes-faits et des classes-dimensions en commun,

– FUS1 : fusionner les classes-dimensions partag´ees par ajout des attributs et des op´erations,

– FUS2 : fusionner les classes-faits par ajout des attributs et des op´erations, – FUS3 : ajouter les classes-dimensions propres `a chaque diagramme.

– FDS : regrouper les diagrammes d´ecisionnels ayant des classes-faits diff´erentes et des classes-dimensions en commun,

– FDS1 : fusionner les classes-dimensions par ajout des attributs et des op´ e-rations.

– FDR : regrouper les classes-dimensions qui ont des attributs en commun, – FDR1: pour les classes-dimensions de noms diff´erents ayant peu d’attributs

en commun, d´efinir les relations de d´ependance fonctionnelle entre les attri-buts des classes-dimensions et les attriattri-buts communs. Puis, il faut supprimer les attributs communs des classes-dimensions dont les attributs communs et les attributs de ces classes-dimensions ne d´efinissent pas des relations de d´ependance fonctionnelle directes. Enfin, il faut d´efinir les relations de d´ e-pendance fonctionnelle entre ces classes-dimensions,

– FDR2 : les classes-dimensions de noms diff´erents mais, dont les attributs sont identiques `a l’identifiant pr`es sont fusionn´es,

– FRD3 : d´efinir des n relations «En Fonction » entre la classe-fait et la classe-dimension r´esultant de la fusion de n classes-dimensions,

– FRD4 : d´efinir n rˆoles diff´erents exprimant la s´emantique du lien entre la classe-fait et cette classe-dimension.

– FRC : fusion des liens entre classes multidimensionnelles,

– FRC1 : reporter les liens entre les diff´erents classes multidimensionnelles,

– FRC2 : pour la coh´erence des donn´ees, une classe-dimension ne peut pas ˆ

etre cible d’une relation de d´ependance fonctionnelle et participer `a des liens d’association avec des classes-faits qui sont li´es `a la classe-dimension qui est source de la relation de d´ependance fonctionnelle. Le lien de d´ependance fonctionnelle est conserv´e et les liens d’association avec les classes-faits sont supprim´es.

Il y a toujours au moins un ´el´ement en commun, en l’occurrence la dimension Temps. La confrontation des besoins prend toujours en param`etre deux diagrammes.