Vous êtes sur la page 1sur 138

Universit Hassan II Casablanca

Ecole Nationale Suprieure dlectricit


Et de Mcanique
CED : Sciences de lingnieur

THESE
En vue de lobtention du

DOCTORAT
Formation Doctorale : Gnie Informatique

Prsente Par : HILAL Imane

Conception et Intgration des Exigences de la Sret de


Fonctionnement Dans les Systmes Dcisionnels

Prsente le 16 Janvier 2016, 10h, devant le Jury :

Pr. Mounir RIFI EST, Casablanca Prsident

Pr. Abdelkrim HAQIQ FST, Settat Rapporteur

Pr. Elhoussaine ZIYATI EST, Casablanca Rapporteur

Pr. Hicham Behja ENSEM, Casablanca Examinateur

Pr. Mohammed Sadik ENSEM, Casablanca Rapporteur

Pr. Hicham Belhadaoui EST, Casablanca Co-directeur de thse

Pr. Mohammed Ouzzif EST, Casablanca Directeur de thse

1
2
Remerciement

Cette thse est le fruit de longues annes de travail effectues au sein du Laboratoire RITM et
en collaboration avec un corps professorale comptent, pour ce, je remercie beaucoup tout le
corps administratif de lEST, plus particulirement Mr le directeur de lEST Pr. Rifi Mounir
qui est galement le responsable du laboratoire RITM pour son aptitude lcoute et pour sa
bienveillance.

Jadresse un grand remerciement aux rapporteurs : Pr. Haqiq Abdelkrim, Pr. Ziyati
Houssaine, et Pr. Sadik Mohammed et monsieur lexaminateur Pr Hicham Behja pour
avoir accept dtre membres du jury.

Je tiens remercier particulirement mon directeur de thse Pr. Ouzzif Mohammed pour
tous ses conseils et son soutien tout au long de ma thse ainsi que pour sa disponibilit et sa
prcieuse relecture pendant la rdaction de ce manuscrit.

Je remercie tous ceux avec qui jai eu des discussions scientifiques trs fructueuses pendant
ma thse, en particulier mon co-Encadrant Pr Belhadaoui Hicham, pour ses conseils son
suivi et Pr. Filali Hilali Reda pour ses relectures de mes papiers et du prsent rapport qui
mont t de grande utilit.

Je tiens exprimer ma reconnaissance et ma profonde gratitude Pr. AFIFI Nadia, pour son
accompagnement, ses comptences, sa gentillesse, et ses corrections.

3
4
Ddicace

A ceux qui ont sacrifi une grande part de leur vie pour ce travail : A ma chre mre et cher pre.
A ceux qui mont soutenu jusqu la fin : mes chres Surs Asmae et safae, et mon cher Mari.
A celle qui a puis son temps, nergie et effort : A ma chre Madame Afifi Nadia
A ceux qui ont t la cause de laboutissement de ce travail : A mes collgues et amies

Veuillez mexcuser car jamais je ne pourrais vous rembourser une telle dette.
Jespre que ce modeste travail soit la hauteur de vos attentes et lampleur de vos sacrifices.

A mon petit trsor Israa ce mmoire test ddi !

5
Rsum

Dans de nombreux domaines tels que la mdecine, lE-commerce ou le militaire, les systmes
dcisionnels occupent une place prpondrante voir critique dans la prennit des entreprises.
Afin de pouvoir faire confiance ces systmes, leur dveloppement doit rpondre des
exigences de sret de fonctionnement. Ces dernires doivent tre prises en compte durant
tout le cycle de dveloppement. Des solutions concrtes sont labores chaque jour pour
parvenir cet objectif. Elles sont bases sur la recherche et limplmentation de nouvelles
approches de dveloppement qui intgrent des concepts de sret de fonctionnement et
guident les dveloppeurs durant chaque tape ncessaire dans la production dun systme
digne de confiance.

Nos travaux de recherche sinscrivent dans une dmarche dingnierie des exigences. Ils
consistent mettre en place une mthodologie permettant dintgrer les exigences non
fonctionnelles de sret de fonctionnement ds les premires tapes du projet dcisionnel.
Dans ce sens, nous nous sommes appuys sur une Architecture dirige par les modles
(MDA : Model Driven Architecture) afin de modliser les exigences de la sret de
fonctionnement, savoir la fiabilit, la disponibilit, la maintenabilit et la scurit dune
manire itrative et du plus haut niveau dabstraction jusqu limplmentation. Ainsi, notre
approche sintresse dans un premier lieu dtecter les conflits ventuels entre les diffrentes
exigences de la sret de fonctionnement. Et dans un second lieu, dassurer leur raffinement
et leur mise en uvre en les intgrant aux exigences fonctionnelles en se basant sur les
concepts de la modlisation Oriente Aspect. Finalement, notre approche est concrtise par
une tude de cas qui la met en pratique et dmontre son applicabilit et ses intrts.

Mots cls : Systme dcisionnel, Sret de fonctionnement, Architecture dirige par les
modles, modlisation et programmation oriente aspect.

6
Abstract

In many domains such as medicine, E-commerce and the military, decision support systems
become more and more important; in some cases they are critical. To rely on these systems,
their development should be constrained by dependability requirements. Indeed, it is
necessary to demonstrate that these high level requirements are taken into account throughout
the entire systems life cycle and that concrete solutions are employed to achieve their
implementation. Such constraints make the development of decision-making systems complex
and difficult. To simplify this process, new approaches are requested in order to incorporate
concepts of dependability and to guide developers in each of the steps to ensure a trusted
application.

Thus, our proposition is part of the engineering process modeling that provides a
methodology in order to take into account non-functional requirements such as dependability
in the early stages of decision-making project. In this sense, we have based on the model-
driven architecture (MDA) to model the dependabilitys attributes which are reliability,
availability, maintainability and security in an iterative way, starting from the highest level of
abstraction to implementation. The proposed approach aims first at detecting possible
conflicts between the different dependabilitys attributes, and secondly it aims at ensuring
their integration with functional requirements just before implementation which is based on
the concepts of Aspect Oriented Software Development (AOSD). Finally, our approach is
illustrated by a case study that demonstrates its applicability and interests.

Key words: Decision Support System, Dependability, Model Driven Architecture, Aspect
Oriented Modeling and Programming.

7
Acronymes
AOP: Aspect Oriented Programming
AOSD: Aspect Oriented Software Development
ATL: Atlas Transformation Language
BPMN : Business Process Model and Notation
CIM: Computation Independent Model
CMMI: Capability Maturity Model Integration
CWM: Commun Warehouse Metamodel
DBMS : Data Base Management System
DS: Data Sources, Sources de Donnes
DW: Data Warehouse
DWEB: Data Warehouse Engineering Benchmark
ED: Entrept de Donnes
ETL: Extraction Transformation Loading
FT: Fault Tolerance
IDM: Ingnierie Dirige par les Modles
IE: Ingnierie des Exigences
MDA: Model Driven Architecture, Architecture Dirige par les Modles
NFR: Non Functional Requirement, Exigences Non Fonctionnelles.
NHS: National Health Services
OLAP: On Line Analysis Processing.
OLTP: On Line Transaction Processing.
OMG: Object Management Group
OO: Oriented Object
OR: Outils de Restitution
OWL: Ontology Web Language
PIM: Platform Independent Model
PSM: Platform Specific Model
QoS: Quality of Service
QVT : Query View Transformation
ROLAP : Relational On Line Analytical Processing
SD: Systmes Dcisionnels

8
SI: Systme dInformation
SdF: Sret de Fonctionnement
SIG: Softgoal Interdependency Graph
UCCD: Urgent Care Clinical Dashboard
UML: Unified Modeling, Language

9
Table des matires

Introduction Gnrale ............................................................................................................. 16


Chapitre 1 : Ingnierie des Exigences de la Sret de Fonctionnement des Systmes
Dcisionnels ............................................................................................................................. 19
1.1 Introduction ........................................................................................................................ 20

1.2 Systmes Dcisionnels (SD) ............................................................................................... 20


1.2.1. Fondement thorique des SD : De linformatisation la dcision ............................................... 20

1.2.2. Mission et finalit .......................................................................................................................... 22

1.2.3. Architecture standard .................................................................................................................... 24

1.2.4. Cycle de vie dun projet dcisionnel ............................................................................................. 25

1.2.5. Problmatiques des SD ................................................................................................................. 27

1.2.5.1 Au niveau des Sources de Donnes ..................................................................................... 28

1.2.5.2 Au niveau du processus Extraction Transformation Loading (ETL) .................................. 29

1.2.5.3 Au niveau de lEntrept de donnes (ED) ........................................................................... 29

1.2.5.4 Au niveau des outils de restitution (OR) .............................................................................. 30

1.3 Sret de Fonctionnement (SdF) ...................................................................................... 30


1.3.1 Dfinition des concepts de base ................................................................................................... 30

1.3.1.1. Attributs ............................................................................................................................... 30

1.3.1.2. Entraves ............................................................................................................................... 31

1.3.1.3. Moyens ................................................................................................................................ 31

1.3.2 Mthodes danalyse de la SdF logicielle ....................................................................................... 33

1.3.3 Exigences de la SdF ...................................................................................................................... 33

1.4 Ingnierie des Exigences de la SdF des SD ...................................................................... 34


1.4.1 Ingnierie des exigences des Systmes ......................................................................................... 34

1.4.1.1. Ingnierie des systmes ....................................................................................................... 34

1.4.1.2. Ingnierie des Exigences (IE) .............................................................................................. 35

1.4.1.3. Ingnierie des Exigences de la SdF ..................................................................................... 36

1.4.2 Dans le contexte des Systmes Dcisionnels ................................................................................ 37

1.4.2.1 Ingnierie des SD et leurs exigences .................................................................................. 37

10
1.4.2.2 Ingnierie des exigences de la SdF des SD .......................................................................... 37

1.5 Ingnierie Dirige par les Modles (IDM) ....................................................................... 38


1.5.1 Principes et intrts ....................................................................................................................... 38

1.5.2 Architecture Dirige par les Modles (MDA) ............................................................................... 39

1.6 Synthse .............................................................................................................................. 41

Chapitre 2 : Etude de lEtat de lart ....................................................................................... 44


2.1 Introduction ........................................................................................................................ 45

2.2 Etat de lart des Systmes Dcisionnels............................................................................ 45


2.2.1 Sources de Donnes ...................................................................................................................... 45

2.2.2 Extraction Transformation Loading .............................................................................................. 46

2.2.3 Entrepts de Donnes (ED) ........................................................................................................... 47

2.2.4 Outils de Restitution ...................................................................................................................... 48

2.2.5 Comparatif des travaux traitant les couches des SD ...................................................................... 49

2.3 Sret de Fonctionnement des Systmes Dcisionnels .................................................... 50


2.3.1 Disponibilit et fiabilit ................................................................................................................. 51

2.3.1.1 Techniques d'optimisation des requtes ............................................................................... 51

2.3.1.2 Optimisation de lETL ......................................................................................................... 52

2.3.2 Maintenabilit ............................................................................................................................... 52

2.3.2.1 Maintenance par mise jour du modle .............................................................................. 53

2.3.2.2 Maintenance par modlisation temporelle ........................................................................... 53

2.3.3 Scurit .......................................................................................................................................... 54

2.3.4 Comparatif des travaux des attributs de sret de fonctionnement ............................................... 55

2.4 Approches de lIngnierie des exigences des Systmes Dcisionnels ............................. 56


2.4.1 Approche base sur les Ontologies et notion du contexte ............................................................. 56

2.4.2 La mthode Computer Aided Data Warehouse Engineering......................................................... 56

2.4.3 Approche base des patrons ......................................................................................................... 57

2.4.4 Approches base du modle de buts ............................................................................................. 58

2.4.5 Approche pour la dfinition et la gestion des SD (DWARF) ........................................................ 58

2.4.6 Comparatif des travaux dans le domaine des exigences des SD ................................................... 59

2.5 Approches Diriges par les modles dans le contexte des SD ........................................ 60
2.5.1 Mta modlisation ......................................................................................................................... 60

2.5.2 Approches spcifiques larchitecture MDA ............................................................................... 61

2.5.3 Comparatif des approches diriges par les modles dans le cas des SD ....................................... 63

11
2.6 Synthse des travaux et positionnement de notre contribution ..................................... 64

Chapitre 3 : Thorie de lApproche Propose ........................................................................ 69


3.1 Introduction ........................................................................................................................ 70

3.2 Les Modles de lapproche MDA ..................................................................................... 70


3.2.1 Modle Indpendant de la plateforme: CIM (Computation Independent Model) ......................... 72

3.2.2 Modle danalyse et de conception abstraite : PIM (Platform Independent Model) ..................... 72

3.2.3 Modle du code ou de la conception concrte : PSM (Platform Specific Model) ......................... 73

3.2.4 Transformation .............................................................................................................................. 74

3.3 Prsentation de la mthode propose ............................................................................... 74


3.3.1 Dtails du mcanisme de lapproche propose.............................................................................. 74

3.3.2 Niveau des Exigences................................................................................................................... 76

3.3.3 Niveau Indpendant de la Programmation .................................................................................... 76

3.3.3.1 Prsentation et intrt du NFR Framework.......................................................................... 77

3.3.3.2 Mcanismes du NFR Framework ........................................................................................ 77

3.3.4 Niveau Indpendant de la Plateforme ............................................................................................ 79

3.3.4.1 Profil QoS-FT ..................................................................................................................... 79

3.3.5 Transformations du CIM au PIM .................................................................................................. 80

3.3.5.1 Atlas Transformation Langage (ATL) ................................................................................. 80

3.3.5.2 Mcanisme de lATL ........................................................................................................... 81

3.3.6 Niveau Spcifique la Plateforme ................................................................................................ 81

3.3.6.1 Modlisation Oriente Aspect ............................................................................................. 82

3.3.6.2 Intrt et mcanismes de lOrient Aspect: ......................................................................... 82

3.4 Synthse .............................................................................................................................. 83

Chapitre 4 : Mise en uvre .................................................................................................... 85


4.1 Introduction ........................................................................................................................ 86

4.2 Niveau des Exigences ......................................................................................................... 86


4.2.1 Source de Donnes (DS) ............................................................................................................... 86

4.2.2 Extraction, Transformation, Loading (ETL) ................................................................................. 86

4.2.3 Entrept de Donnes (DW) ........................................................................................................... 87

4.2.4 Outils de Restitution (OR) ............................................................................................................. 88

4.3 Niveau Indpendant de la Programmation (CIM) .......................................................... 90


4.3.1 CIM de la disponibilit et de la fiabilit ........................................................................................ 90

4.3.2 CIM de la maintenabilit ............................................................................................................... 91

12
4.3.3 CIM de la scurit ......................................................................................................................... 91

4.3.4 CIM intgrale de la SdF ................................................................................................................ 92

4.4 Niveau Indpendant de la Plateforme .............................................................................. 93


4.4.1 PIM de la disponibilit et de la fiabilit ........................................................................................ 94

4.4.2 PIM de la maintenabilit ............................................................................................................... 94

4.4.3 PIM de la scurit .......................................................................................................................... 95

4.4.4 PIM Intgral de la SdF .................................................................................................................. 95

4.5 Transformations du CIM au PIM .................................................................................... 97

4.6 Niveau Spcifique la Plateforme .................................................................................... 99

4.7 Etude de Cas : Systme Dcisionnel pour Tableaux de Bord des Soins dUrgence
Cliniques ........................................................................................................................................ 101
4.7.1 Objectifs ...................................................................................................................................... 101

4.7.2 Mthodologie .............................................................................................................................. 101

4.7.3 Cahier des Charges ...................................................................................................................... 102

4.7.3.1 Exigences fonctionnelles .......................................................................................................... 102

4.7.3.2 Exigences non fonctionnelles.................................................................................................... 105

4.7.4 Mise en oeuvre et validation ....................................................................................................... 108

4.7.4.1 Implmentation du Niveau des Exigences ......................................................................... 108

4.7.4.2 Implmentation du Niveau Indpendant de la Programmation .......................................... 108

4.7.4.3 Implmentation du Niveau Indpendant de la Plateforme ................................................. 111

4.7.4.4 Implmentation du niveau spcifique la plateforme ....................................................... 113

4.7.4.5 Implmentation et rsultats des tests .................................................................................. 115

4.8 Synthse ............................................................................................................................ 117

Conclusion et perspectives .................................................................................................... 120


5.1. Bilan des travaux raliss ................................................................................................ 121

5.2. Synthse des contributions .............................................................................................. 122

5.3. Perspectives ...................................................................................................................... 124

Bibliographie et Webographie .............................................................................................. 125


Annexe A: DWEB (Data Warehouse Engineering Benchmark) ........................................ 135

13
Liste des Figures

Figure 1: Position des SD dans l'Organisation ......................................................................... 22


Figure 2: Architecture classique dun SD ................................................................................ 24

Figure 3: Cycle de vie standard d'un projet dcisionnel........................................................... 25


Figure 4: Enqute sur les raisons de renouvlement des SD.................................................... 27

Figure 5: Chute de la performance cause par le volume croissant de donnes ...................... 28


Figure 6: Attributs, entraves et moyens de la sret de fonctionnement ................................. 32

Figure 7: Bases de lIngnierie Dirige par les Modles ......................................................... 39


Figure 8: Description du mta modle du MDA[118] ............................................................. 70

Figure 9: Processus de dveloppement selon lapproche MDA............................................... 71


Figure 10: Dmarche de lApproche Propose ........................................................................ 75

Figure 11: Mthodologie de l'Approche................................................................................... 76


Figure 12: Exemple dun SIG .................................................................................................. 78

Figure 13: Syntaxe abstraite des rgles de transformation extraite du Mtamodel ATL[131] 81
Figure 14: Mcanisme des transformations ATL ..................................................................... 81

Figure 15: Elaboration des PSM pour chaque couche ............................................................. 82


Figure 16: tissages des aspects de SdF ..................................................................................... 83

Figure 17: CIM de la disponibilit et de la fiabilit ................................................................. 90


Figure 18: CIM de la maintenabilit ........................................................................................ 91

Figure 19: CIM de la scurit ................................................................................................... 92


Figure 20: CIM intgrale de la SdF pour la dtection des interactions .................................... 93

Figure 21: PIM de la disponibilit et de la fiabilit.................................................................. 94


Figure 22: PIM de la maintenabilit ......................................................................................... 95

Figure 23: PIM de la scurit ................................................................................................... 96


Figure 24: PIM Intgral de la SdF ............................................................................................ 96

14
Figure 25: Transformation ATL du CIM NFR au PIM QoS .................................................. 97

Figure 26: MetaModel du NFR Framework ............................................................................ 97


Figure 27: Spcialisation du NFR Framework ......................................................................... 98

Figure 28: Elaboration des PSM partir du PIM Intgral ....................................................... 99


Figure 29: PSM SdF pour la couche DW .............................................................................. 100

Figure 30: tissage des aspects de SdF avec la partie fonctionnelle ........................................ 100
Figure 31: Modle conceptuel des services technologiques .................................................. 103

Figure 32: Flux Conceptuel de Donne.................................................................................. 105


Figure 33: CIM de disponibilit et fiabilit de lUCCD ........................................................ 109

Figure 34: CIM de Maintenabilit de l'UCCD ....................................................................... 109


Figure 35: CIM de la scurit de l'UCCD .............................................................................. 110

Figure 36: Extrait du CIM Intgral simplifi ......................................................................... 110


Figure 37: PIM Fiabilit et Disponibilit ............................................................................... 111

Figure 38: PIM de la Maintenabilit ...................................................................................... 112


Figure 39: PIM de la Scurit de lUCCD ............................................................................. 112

Figure 40: PIM intgral des SdF propre la couche DW du system UCCD ......................... 113
Figure 41: PSM logique du DW de l'UCCD reprsent par Diagramme de Composant....... 114

Figure 42: PSM architectural du DW de l'UCCD par Diagramme de Dploiement .............. 114
Figure 43: Temps de rponse du DW1 aux diffrentes charges de requtes ......................... 116

Figure 44: Temps de rponse du DW10 aux diffrentes charges de requtes ....................... 116
Figure 45: Temps de rponse de la charge de 20 requtes aux diffrents volumes de DW ... 117

Figure 46: Temps de rponse de la charge de 100 requtes aux diffrents volumes de DW . 117
Figure 47: Interface de connexion et de chargement du DW ................................................. 135

Figure 48: Cration des tables DW ........................................................................................ 137


Figure 49: message de fin de chargement d'un DW en prcisant sa dure en ms .................. 138

Figure 50: Exemple d'excusion de la charge de 100 requtes sur le DW de 22Mo ............. 138

15
Introduction Gnrale
Contexte et Motivation
Les systmes informatiques dcisionnels (SD) sont aujourdhui lun des instruments daide
la dcision qui se sont de plus en plus imposs surtout pendant et aprs la priode de la crise
conomique. Cette dernire a stimul le march des outils daide la dcision grce la
demande croissante des entreprises pour des outils danalyse, de restitution et de
consolidation. Le but escompt est dassurer leur prennit dans un contexte hautement
concurrentiel et incertain.
Le SD, en Anglais rfrenc par DDS (Decision Support System), est dfinit comme tant un
systme qui apporte un appui et une aide la dcision. Cette dernire est une activit plutt
humaine dans le sens o elle est entame par des acteurs humains suite un processus
complexe compos, entre autres, dexpriences cumules, de risques prvus et dinteractions
et ractions avec lenvironnement.

Ainsi, la mission du SD n'a jamais t d'automatiser la dcision, mais plutt d'automatiser la


recherche et la prsentation des informations utiles la prise de dcision. Son objectif
principal est de combler la faiblesse des Systmes dInformations (SI) classiques fournir des
informations transversales et selon diffrents axes danalyse[1]. Cette faiblesse rside dans
leur vocation transactionnelle et pointue qui alourdie et rend difficile la consolidation et la
restitution des donnes [2]. En effet, ces dernires sont organises dun point de vue
oprationnel, et sont ainsi parpilles de point de vue analytique.
Le rle crucial du SD dans la prise de dcision impose un niveau de confiance assez lev [3]
afin de garantir sa sret de fonctionnement et donc pouvoir se fier aux informations quil
dlivre. Dans ce sens, la mise en place dun SD repose, dans un premier temps, sur les
exigences fonctionnelles de ses utilisateurs gnralement non suffisantes pour la russite du
projet. En effet dautres facteurs linfluencent, tels que : (i) le temps de rponse des requtes
complexes danalyse et la disponibilit du systme, (ii) la fiabilit des donnes et du processus
traitant, (iii) lvolution des besoins et leur maintenance et (vi) lassurance de rgles de
scurit et dintgrit. La prise en compte de ces facteurs ds les premires tapes de projet de
SD tout en considrant leurs influences et leurs interactions, permettra dy attribuer une
confiance meilleure et dassurer sa sret de fonctionnement.
Dun autre ct, les tudes de sret de fonctionnement permettent de traiter plusieurs aspects
non fonctionnels des systmes, savoir : la disponibilit, la fiabilit, la maintenabilit et la
scurit. Elles constituent ainsi un pralable indispensable la conception dun systme voulu

16
confiant pour comprendre et identifier les risques de sret des systmes. Ensuite elles
permettent de confronter et comparer les diffrentes solutions possibles afin de justifier, de
faon rationnelle et dmontre, les choix doptimisation de larchitecture proposer.

Problmatique et contribution

Actuellement, dans le contexte acadmique des systmes dcisionnels, les aspects de sret de
fonctionnement ont t dj traits mais dune manire isole et gnralement lors des phases
dimplmentation physique du systme. Plusieurs problmes vont en dcouler:

1. Les exigences de sret de fonctionnement exprimes lors des premires phases ne


sont pas traites progressivement comme dans le cas des exigences fonctionnelles, ce
qui dgrade considrablement leur traabilit depuis lexpression des besoins jusqu
limplmentation.
2. Les aspects de sret de fonctionnement interagissent ensemble soit en accord ou en
conflit dintrt et donc leur traitement doit prendre en compte cette interaction.
3. A notre connaissance, aucune approche nest disponible pour spcifier, dune faon
normalise et unifie, le traitement des aspects de sret de fonctionnement pour
justifier les choix conceptuels, architecturaux et dimplmentation ds les premires
phases du projet dcisionnel.

Enonce ainsi, la problmatique de la SdF des systmes dcisionnels se traduit par la


recherche dune mthodologie fonde et rigoureuse permettant daccompagner le projet
dcisionnel tout au long de son cycle de vie. Pour faire face cette problmatique, la thse
prsente dans ce document propose une approche de gnie logiciel qui nous permettra de
traiter les aspects de sret de fonctionnement en tenant compte de leurs interactions. Notre
objectif est de guider la construction des systmes dcisionnels selon les exigences de sret
de fonctionnement, en sappuyant sur deux principaux paradigmes : lingnierie dirige par
les modles (en particulier, larchitecture dirige par les modles MDA) et le dveloppement
logiciel orient aspect.

Ainsi, la MDA nous a permis dabord, de traiter les aspects de sret de fonctionnement en
les sparant de toute plate-forme technique, puis de les raffiner progressivement du plus haut
niveau dabstraction jusqu limplmentation du code. Ce paradigme prconise lutilisation
des modles comme entit de production au lieu de leur aspect contemplatif usuel. Dans ce
sens, la MDA prconise lutilisation de trois modles, savoir : (i) CIM (Computation
Independent Model) qui reprsente les besoins exprims indpendamment de tout systme
informatique, (ii) PIM (Platform Independent Model) qui reprsente les besoins mais
indpendamment de toute plateforme technique et enfin (iii) PSM (Platform Specific Model)
qui reprsente les besoins mais cette fois ci spcifiques une plateforme donne.

17
Dun autre ct, le dveloppement logiciel orient aspect va nous offrir tous les mcanismes
ncessaires et suffisants pour intgrer les aspects de sret de fonctionnement -modliss
suivant la dmarche MDA- dans le systme en les tissant avec les parties fonctionnelles.

Organisation de la thse
Dans ce sens, les travaux raliss dans le cadre de notre proposition sont prsents dans les
quatre chapitres de ce mmoire :
Le premier chapitre introduit et dtaille toute la terminologie utilise dans ce mmoire.
Lobjectif est tout dabord deffectuer un cadrage du domaine de la thse et de linscrire dans
son propre contexte scientifique et acadmique en prcisant ses frontires

Le deuxime chapitre prsente une analyse bibliographique des diffrentes approches


intersectes notre axe de recherche en dgageant leurs points forts et leurs points faibles.
Cette analyse va nous permettre de traiter la problmatique nonce et de justifier sa mise en
tude.

Le troisime chapitre expose les bases thoriques de lapproche propose pour traiter la
problmatique tudie. Le quatrime chapitre va permettre de prouver lapproche propose
par une mise en uvre pratique et ensuite par une dmonstration dun cas dtude. Cela
permettra de valider les propos thoriques de lapproche.

Pour conclure, nous allons prsenter une synthse des travaux effectus en montrant leurs
objectifs. Puis nous allons proposer quelques perspectives qui reprsentent la continuit de
nos travaux de recherches.

18
Chapitre 1 : Ingnierie des Exigences de la
Sret de Fonctionnement des Systmes
Dcisionnels

Comprendre cest avant tout unifier. Vouloir, cest susciter les paradoxes
Albert Camus.

19
1.1 Introduction
Dans ce chapitre, nous allons introduire le concept des systmes dcisionnels en mettant
laccent sur les problmes gnraux qui leur sont inhrents. Puis nous allons dtailler
spcifiquement ceux en relation avec la sret de fonctionnement. Dans cette perspective, ce
chapitre est structur suivant quatre sections. La premire section est rserve lintroduction
des systmes dcisionnels en les comparant avec les systmes transactionnels, et en
dfinissant ses notions cls qui seront utilises tout au long de ce rapport. La deuxime
section dfinit la sret de fonctionnement : ses attributs, ses moyens et ses entraves. La
troisime section traite lingnierie des exigences en dtaillant ceux qui concernent la sret
de fonctionnement dans le contexte des systmes dcisionnels. Enfin, la dernire section
prsente lapproche sur laquelle se base notre contribution.

1.2 Systmes Dcisionnels (SD)


Cette section prsente un historique et une confrontation des systmes dcisionnels avec les
systmes transactionnels. En plus, elle introduit les notions cls qui seront utilises tout au
long du mmoire.

1.2.1. Fondement thorique des SD : De linformatisation la dcision


Linformatisation des entreprises a dabord commenc par les applications ddies pour
automatiser la gestion des systmes de production. Ainsi, toutes les applications permettaient
la saisie et le traitement des donnes dune part, et la production en sortie de rsultats sous
forme de documents oprationnels non utilisables du ct du systme du pilotage dautre part.

Ces systmes de production dbordaient de donnes qui peuvent servir de base pour des
analyses trs utiles la prise de dcision. Cependant, ces systmes taient dvelopps pour
grer des transactions lmentaires quotidiennes. Ils taient optimiss conformment cette
finalit. Par consquent, ils taient loin de pouvoir rpondre la grande volumtrie de
donnes, et la complexit des traitements relatifs activits danalyse. Do le besoin doutils
et de systmes qui permettent de contourner cette limitation [1].

En effet, la finalit des systmes oprationnels est de traiter de nombreuses requtes simples
mais de manire rapide. Son centre de gravit est particulirement celui dune opration, alors
que les applications daide la dcision sintressent des ensembles doprations sur des
priodes de temps importantes et donc nont pas les mmes contraintes de temps de rponses
[2]. La prsence des applications de production et daide la dcision sur un mme support
informatique sest avre trs conflictuelle dans le sens de consommation de ressource. En
effet, les applications daide la dcision sont par dfinition trs consommatrices de
ressources et perturbent le temps de rponse des autres applications partageant avec elles le
mme support informatique.

20
Cette situation a donn naissance aux premiers infocentres (fin des annes 70) [3] qui se sont
contents dans un premier lieu de dupliquer les donnes des applications de production dans
un environnement spar et ddi lanalyse. Ces infocentres mensuellement aliments, ont
apport lpoque une pousse norme aux entreprises en matire danalyse de suivi et de
management des activits. Toutefois, ces outils taient limits au traitement des donnes
rcentes et volatiles, et ne permettaient pas aux utilisateurs de travailler sur les historiques ou
de faire des prvisions.

Au fil du temps, les infocentres se sont avrs de plus en plus incapables de rpondre aux
besoins croissants des entreprises. Ces derniers exigeaient des outils plus performants pour
accrotre leur ractivit et anticiper les changements. Et grce lapparition de nouvelles
technologies, les infocentres ont t vite dpasss laissant la place aux EIS [4] (Executive
Information System) partir des annes 1990. Ces derniers taient limits aux outils de
tableaux de bord. Peu aprs, les systmes dcisionnels, appels aussi systmes daide la
dcision, ont vu le jour et sont considrs depuis comme tant le lieu de stockage des gros
volumes de donnes devant tre analyses.

Les deux fondateurs de la thorie des systmes dcisionnels Kimball et Inmon dfinissent les
systmes dcisionnels comme tant un regroupement de donnes orientes sujets, intgres,
dpendantes du temps, non volatiles, ayant pour but daider les gestionnaires dans leurs prises
de dcision [5],et une copie des donnes transactionnelles organises spcialement pour
linterrogation et lanalyse [6].
Avec le temps, la maturit des SD a merg des dfinitions plus labores. Une dfinition
exemplaire est celle de Jark [7] qui le caractrise selon son architecture il contient plusieurs
couches de donnes dans lesquelles les donnes dune couche sont drives partir dune
couche infrieure. Les sources de donnes forment la couche la plus basse et sont appeles
des bases transactionnelles . Celle de [8] qui le dfinit comme un systme qui ralise la
collecte, la transformation des donnes brutes issues de sources de donnes et le stockage
dans dautres espaces ainsi que la caractrisation des donnes rsumes en vue de faciliter le
processus de prise de dcision .
Les dfinitions prcdentes soulignent le fait que la manipulation des donnes est le centre
dintrt des systmes dcisionnels. En effet, la prise de dcision dans une organisation
suscite un appui en termes dinformation et connaissance. Cet appui ne peut provenir que de
lanalyse du flux de donnes brutes manipul par le systme oprant ou/et des sources
externes.
Le schma de la figure 1 permet de prciser avec exactitude la position du SD dans une
organisation. Il a t largement inspir du courant de la pense systmique (1970) [9] qui
est considr parmi les premiers fondateurs de la notion de SI.

21
Sys
Dcisions, Orientation, de pilotage

Donnes, Information de
Stratgies
Systme dcisionnel

Production
Systme d'information

Systme Oprant

Figure 1: Position des SD dans l'Organisation

Ainsi, l'organisation est un systme compos de quatre sous-systmes, savoir:


1. Le Systme Oprant : instrument de production qui incarne le mtier ou la spcialit de
lorganisation.
2. Le Systme d'Information : support informationnel du Systme Oprant; il salimente des
donnes brutes du Systme Oprant et permet lautomatisation de ce dernier.
3. Le Systme Dcisionnel : traite les donnes brutes issues du SI pour en extraire des
informations utiles au systme de pilotage.
4. Le Systme de Pilotage : dtermine le comportement et lorientation stratgique et
politique de l'organisation en se basant sur le flux informationnel remont du Systme
Oprant.

1.2.2. Mission et finalit


Lvolution trs rapide des technologies de linformation et de la communication ainsi que
limplmentation directe de linformatique dans la plupart des champs disciplinaires produit
toujours plus de donnes, et multiplie les sources dinformations. Ces sources sont disparates,
fortement volutives et distribues. Il en rsulte que la prise de dcision stratgique ou
politique est de plus en plus complexe car elle dpend dune multitude de paramtres
prendre en compte. En plus elle impose une prise de dcision rapide dans un contexte
hautement concurrentiel. Et justement les systmes dcisionnels permettent travers la
collecte et lhomognisation des donnes, de dgager et danalyser les indicateurs les plus
pertinents. Ces derniers vont tre utiliss pour faciliter la prise de dcision et le pilotage de
lentreprise en maitrisant la signification et le devenir des informations prsentes [10].

De plus, par lorganisation multidimensionnelle des donnes et laccs transparent aux


diffrentes sources de donnes htrognes, le SD tend vers une manipulation intuitive des

22
donnes par les dcideurs. Autrement dit, il a pour objectif daugmenter lautonomie des
dcideurs pour la ralisation de leurs analyses.
Cette autonomie couple aux donnes labores du SD, favorisent une ractivit efficace et
une augmentation de la capacit de lorganisation sadapter aux ventuels changements de
contextes. Dans cette perspective, les besoins des utilisateurs des systmes dcisionnels
peuvent tre regroups selon quatre grands axes : le suivi, le contrle, lanalyse et la
simulation [11].

Le suivi : se base sur les fonctionnalits de reporting permettant de produire de faon


rapide des tableaux de donnes incorporant des calculs plus ou moins simples (ex.
production dtat de vente journalire).
Le contrle : sappuie sur llaboration de tableaux de bords frquence rgulire en
regroupant des donnes htrognes cohrentes (ex. les rapports des ventes
trimestriels).
Lanalyse : se base essentiellement sur les fonctionnalits OLAP (On Line Analysis
Process) [12] pour tablir des analyses multidimensionnelles de la donne, voire mme
de pousser lanalyse en utilisant les techniques et algorithmes avancs de la fouille de
donne (ex. lanalyse des causes expliquant la chute inattendue du chiffre daffaires
dun produit).
La simulation : appele aussi What If Analysis permet de se projeter dans le futur en
injectant des paramtres dentre dans des modles spciaux la simulation (ex.
llaboration budgtaire).

Pour rpondre aux besoins de ses utilisateurs, le systme dcisionnel doit assurer cinq
fonctions essentielles: [10]

La collecte des donnes brutes partir de leurs environnements d'origine moyennant des
fonctions plus ou moins complexes de dtection et de filtrage. Car un excdent de
donnes, un dfaut de fiabilit ou un trop mauvais rapport signal/bruit sont plus
pnalisants que l'absence de donnes.
L'intgration des donnes qui permet de les regrouper en un ensemble technique,
logique et smantique homogne malgr leurs sources htrognes.
La diffusion ou la distribution d'informations labores partir des donnes dans des
contextes appropris aux besoins des individus ou des groupes dutilisateurs.
La prsentation, qui dtermine les conditions de mise disposition de l'information (ex.
contrle d'accs, personnalisation, ergonomie, etc.);
L'administration qui gre le dictionnaire de donnes et le processus d'alimentation de
bout en bout, car mme le SD qui est un outil de pilotage, doit tre pilot aussi.

23
1.2.3. Architecture standard
Sur le plan pratique, le SD est compos de plusieurs couches diffrentes qui lui permettent
dassurer ses fonctions. Le schma de la figure 2 reprsente larchitecture conventionnelle
dun SD [13].

Figure 2: Architecture classique dun SD

Les donnes sont extraites grce aux processus ETL (Extraction, Transformation,
Chargement). Cette couche permet de nettoyer et dintgrer les donnes provenant des sources
htrognes pour les consolider dans leur dpt central, appel entrept de donnes [12].

Par ailleurs, en raison de la complexit des analyses supportes par le SD, il est souvent
associ un autre concept qui est celui des systmes OLAP. Plusieurs dfinitions sont
prsentes. La plus connue est celle nonce dans le rapport technique de rfrence de Codd
[14]. Elle met en avant la reprsentation multidimensionnelle des donnes et le caractre
rapide et partag des analyses de donnes. Lauteur du rapport dfinit 18 rgles appeles
FASMI (Fast Analysis of Shared Multidimensional). Ces dernires correspondent aux
fonctionnalits que doit assurer un systme OLAP.
Dun autre ct, le SD a comme interface des flux dentre, les systmes oprants qui sont
gnralement des systmes OLTP (On Line Transaction Processing). Une comparaison entre
les deux systmes permet de dgager les caractristiques intrinsques [15] des SD et leur
distinction par rapport aux systmes transactionnels. Le tableau suivant rsume ces
diffrences.

24
Systme OLAP (Systme
Systme OLTP (Systme oprant)
Dcisionnel )
Systmes htrognes Application quotidienne
Entrs
Donne brute, non intgre Donne dtaille
Insertion ou lecture seule, la
Tous les types de transactions
modification est interdite
Transaction longue constitue requte Transaction courte constitue de
Traitement
complexe requtes simples
Grand volume de donnes orientes
Donnes orientes application
sujet
Peu dUtilisateurs : dcideur, analyste. Beaucoup dutilisateurs
Sorties Analyses multidimensionnelle et
Rapports prdfinis quotidiens
historiques
Plusieurs couches Une couche gnralement
Maintenance frquente offline Maintenance moins frquente
Architecture
Disponibilit tolrable Disponibilit critique
Fiabilit et scurit critique Fiabilit et scurit exige
Tableau 1: Comparaison entre systme OLAP et OLTP

1.2.4. Cycle de vie dun projet dcisionnel


La particularit des SD dtaille dans les sections prcdentes exige un cycle de vie diffrent
des cycles de vie conventionnels. Le schma prsent sur la figure 3 permet de le dtailler
[16].

Figure 3: Cycle de vie standard d'un projet dcisionnel

25
a. La planification est ralise interactivement avec la dfinition des besoins. Elle
comprend la dfinition de la porte, de lidentification, de lestimation et de
laffectation des tches.
b. La gestion du projet assure la coordination des activits du projet. Elle comprend donc
le suivi de lavancement et de ltat du projet, le suivi des problmes, le contrle des
changements (ex. porte du projet) et le dveloppement du plan de communication.
c. La dfinition des besoins est une phase critique ncessaire la russite dun projet. En
effet, elle se concentre sur les utilisateurs et non sur les donnes afin didentifier les
besoins les plus prioritaires et identifier les processus daffaires.
d. La modlisation des donnes se base sur le document de description des besoins pour
raliser le modle multidimensionnel, en identifiant des faits et leur granularit; les
dimensions et leur hirarchie; et les stratgies: de dnormalisation, de gestion des
changements, etc.
e. La conception physique utilise le modle de donnes afin de prciser les dtails du
schma relationnel (ex. cls, types, contraintes, etc.), les scnarios doptimisation de
la performance (ex. indexes, partitionnement, agrgation, etc.), et la gestion de la
scurit.
f. La conception de larchitecture technique dfinit la vision densemble de la solution et
lintgration des technologies du projet; en se concentrant sur les besoins et non sur les
aspects techniques. Elle doit tenir compte de lenvironnement technique actuel et des
directions stratgiques prvues. Dans ce sens, elle commence par lidentification des
besoins techniques, la cration du plan darchitecture pour enfin pouvoir faire la
slection et linstallation des produits en se basant sur le plan darchitecture des
produits: DBMS, ETL, reporting, analyse multidimensionnelle, forage de donnes, etc.
g. La phase de la conception et du dveloppement du systme ETL reprsente environ
70% des efforts et risques du projet. Elle doit considrer le nombre et le type des
sources de donnes et les outils disponibles. Cette opration se fait moyennant une
identification et une analyse des sources de donnes, et en dveloppant des mthodes
dextraction, de nettoyage et de consolidation des donnes (code maison ou outils
commerciaux) ainsi que des mthodes dinsertion de donnes et de validation de leur
qualit.
h. La conception et le dveloppement des applications de BI se font en parallle avec la
modlisation des donnes et la conception du plan darchitecture. Leur objectif est de
raliser la modlisation des tableaux de bord, des rapports, des indices de performance
(KPI) adapts aux utilisateurs, la dfinition des modles de prdiction, classification et
clustering, la configuration des outils et des mtadonnes, limplmentation du portail
de navigation et la validation des applications.
i. Le dploiement: constitue le point de convergence des activits de dveloppement qui
sintresse la formation des utilisateurs et la gestion des mcanismes de suivi

26
derreurs. Il permet de fournir la documentation complte aprs la validation de
donnes et outils.
j. La maintenance et la croissance: assurent le fonctionnement optimal du systme et
prvoit lajout de nouvelles fonctionnalits. Ces dernires comprennent le suivi de
lutilisation et rglages de performance (tuning), la sauvegarde et la rcupration des
donnes, le support aux utilisateurs et la prparation de nouveaux cycles de
dveloppement.

1.2.5. Problmatiques des SD


Le systme dinformation dcisionnel a t dvelopp dans lintention dhomogniser des
sources de donnes brutes et htrognes afin den extraire des informations pour des fins
danalyse, de suivi et de simulation. Son rle crucial dans la prise de dcision exige un degr
de confiance assez lev afin de pouvoir se fier aux informations quil dlivre.

La mise en place dun systme dcisionnel russi doit dans un premier lieu reposer sur les
exigences fonctionnelles de ses utilisateurs. Mais ces dernires ne sont gnralement pas
suffisantes pour la russite du projet. La figure 4 reprsente le rsultat dune enqute ralise
en 2009 par TDW Institut auprs dune centaine dutilisateurs des systmes dcisionnels [17].
Ils devaient rpondre la question suivante pourquoi penserez-vous renouveler votre
systme dcisionnel ?

Figure 4: Enqute sur les raisons de renouvlement des SD

27
Les rsultats de cette enqute mettent laccent sur le caractre non fonctionnel du systme qui
influence directement son succs auprs de ses utilisateurs. En effet, la motivation de la mise
en place des systmes dcisionnels dans la plupart des cas ne rside pas seulement dans sa
finalit de fournir une information utile la dcision, mais galement de tous les autres
besoins non fonctionnels ngligs ou mal formuls au dbut du projet. Daprs lenqute,
plusieurs obstacles et problmes sont exposs, et peuvent tre synthtiss selon les quatre
catgories suivantes :
La performance du systme qui est en gnral pnalise par la complexit des requtes
excutes, et par lalimentation continuelle du systme et de la quantit de donnes
importante (voir figure 5).
Lvolutivit du systme du point de vue mtier. En effet, les stratgies et les
orientations des organisations peuvent changer, or ces dernires sont lune des bases
de construction des SD.
La scalabilit du systme dcisionnel qui doit grer de plus en plus de flux de donnes
et de requtes nouvelles et complexes.
Les choix techniques et technologiques qui deviennent inadquats et ne supportent pas
le caractre volutif du systme.

Performance

Data Growth

Figure 5: Chute de la performance cause par le volume croissant de donnes

Pour mieux cerner les problmes communs rencontrs par tous les acteurs du systme
dcisionnel, nous proposons de les lister par couche dans la section suivante.

1.2.5.1 Au niveau des Sources de Donnes


Lalimentation du systme dcisionnel seffectue partir de plusieurs sources de donnes. Ces
sources peuvent se prsenter sous diffrentes formes : structures, semi structures ou non
structures. Il peut sagir de fichiers "plats" (ex. fichiers CSV avec sparateurs, fichiers XML,
fichiers ASCII, etc.) mais aussi de systmes de bases de donnes (ex. MySQL, PostgreSQL,
SQLServer, ORACLE, etc.), du contenu web ou des applications de veille technologique. Ces

28
sources de donnes sont donc en gnral htrognes et alimentent le systme dcisionnel par
de grands volumes de donnes dont la qualit est discuter. Les problmes de qualit des
donnes stockes sarticulent en particulier autour des erreurs sur les donnes, de doublons,
dincohrences et de valeurs manquantes, incompltes, incertaines, obsoltes, aberrantes ou
peu fiables. Les consquences de la non-qualit des donnes (ou de leur qualit mdiocre) sur
les prises de dcision et les cots financiers quelle engendre sont considrables. Selon un
rapport du TDWI [18], elles sont de lordre de 611 milliards de dollars par an pour lconomie
amricaine. Ce problme saccentue encore plus avec la multiplication des sources
dinformation disponibles et laccroissement des volumes de donnes potentiellement
accessibles.

1.2.5.2 Au niveau du processus Extraction Transformation Loading (ETL)


Le nettoyage de donnes par transformation ou ETL : Extraction- Transformation-Loading
(en franais, Extraction Transformation et Chargement) fait partie du processus
damlioration de la qualit des donnes dans les systmes dcisionnels. Il consiste choisir
et appliquer des transformations sur des jeux de donnes pour rsoudre les diffrents
problmes de formats et dincohrences, dintgrits au sein dune mme source ou entre
plusieurs sources de donnes consolider.
Dun autre ct, cette phase critique est responsable de lalimentation de lentrept de
donnes et de son rafraichissement. Divers problmes peuvent se manifester. Ils sont relatifs
plusieurs aspects : qualit et fiabilit des donnes manipules, leur type et leur degr
dhtrognit, le nombre des sources, les types de transformations effectues et de la
frquence de rafraichissement de lentrept de donnes [19].
De ce fait, et pour alimenter lentrept de donnes par des donnes fiables tout en tenant
compte des recouvrements, il est impratif de rsoudre ces problmes ce niveau de
larchitecture.

1.2.5.3 Au niveau de lEntrept de donnes (ED)


LED est conu pour traiter une masse colossale dinformations, enregistrer des millions
dinteractions quotidiennes, et raliser des segmentations pertinentes partir de donnes
factuelles.
Les problmes des entrepts de donnes sarticulent gnralement autour des donnes et des
techniques de leur maintenance et optimisation. Tout dabord, la premire difficult relever
dans leur conception, consiste leur dfinir un schma. Contrairement aux systmes OLTP,
les donnes peuvent tre reprsentes selon un schma en toile, en flocon ou en constellation
en fonction des besoins danalyse et de la complexit des relations entre la table de Fait et les
dimensions danalyse. Ensuite, vient le problme de la volumtrie des donnes [20]. Ce

29
dernier est caus par le nombre denregistrements effectus, ce qui en dcoule le besoin des
structures doptimisation savoir les vues, le partitionnement, les indexes, etc.
Dun autre ct, lentrept de donnes nest pas isol car il interagit avec lETL en entre et
avec les systmes de restitution en sortie. Il est donc influenc par eux en terme de priodicit
des chargements de donne fournis par lETL et par le nombre, la frquence et la complexit
des requtes demandes de la part des outils de restitution. Enfin tout comme les systmes de
bases de donnes, lensemble des problmes daccs et de la scurit dune manire gnrale
doivent tre pris en compte.

1.2.5.4 Au niveau des outils de restitution (OR)


Le premier problme invoqu lors de la phase de restitution est la diversit de ses outils. En
effet, ces outils peuvent avoir plusieurs formes :

Simples rapports permettant deffectuer des requtes Ad hoc ou paramtrables.


Tableaux de bord reprsentant ltat dvolution des paramtres et indices manant de
lentrept de donnes.

Cubes OLAP permettant de naviguer dans les donnes suivant des axes danalyse en
variant leur niveau de granularit.

Outils avancs de fouille de donne (Data Mining) permettant dextraire des


informations pousses en appliquant des techniques avances danalyse.

Cette diversit engendre plusieurs problmes en relation avec la complexit des requtes, la
volumtrie des donnes manipules, le type de transformation ralise, les contraintes du
support (la mmoire centrale, le rseau et le CPU, etc.) [21].
Pour conclure, la mise en place dun systme dinformation dcisionnel de qualit nest donc
pas simple et engendre des cots et des efforts non ngligeables. Ainsi, sa conception doit
impliquer une analyse rigoureuse et approfondie des besoins mtiers mais galement tout
lment qui assure sa sret de fonctionnement afin de pouvoir y attribuer le niveau de
confiance ncessaire et suffisant pour accomplir son rle.

1.3 Sret de Fonctionnement (SdF)

1.3.1 Dfinition des concepts de base


La sret de fonctionnement (note SdF) est dfinie comme la proprit dun systme
permettant ses utilisateurs de placer une confiance justifie dans le service quil leur dlivre
[22].

1.3.1.1. Attributs
La SdF peut tre tudie selon des proprits diffrentes mais complmentaires [23]:

30
La Disponibilit : (En anglais Availability) signifie le fait d'tre prt l'utilisation.
La Fiabilit : (En anglais Reliability) signifie la continuit de service.
La Scurit-innocuit : (En anglais Safety) signifie la non-occurrence de consquences
catastrophiques.
La Confidentialit : (En anglais Confidentiality) signifie la non-occurrence de
divulgations non-autorises de l'information.
L'Intgrit : (En anglais Integrity) signifie la non-occurrence d'altrations
inappropries du systme.
La Maintenabilit : (En anglais Maintainability) signifie laptitude aux rparations et
aux volutions.

L'association de la confidentialit, de l'intgrit et de la disponibilit, vis--vis des actions


autorises, conduit la scurit [22] (En anglais Security).

1.3.1.2. Entraves
Les entraves la sret de fonctionnement sont les fautes, les erreurs et les dfaillances [24].
Une dfaillance survient lorsque le service dlivr neffectue plus la fonction laquelle il est
destin. Une erreur est la partie de ltat du systme qui est susceptible dentraner une
dfaillance. La cause adjuge ou suppose dune erreur est une faute.
Les fautes et leurs sources sont extrmement diverses. On peut les classer selon cinq points de
vue : leur cause phnomnologique (fautes physiques ou fautes dues lhomme), leur nature
(fautes accidentelles, fautes intentionnelles avec ou sans volont de nuire), leur phase de
cration ou doccurrence (fautes de dveloppement, fautes oprationnelles), leur situation par
rapport aux frontires du systme (fautes internes, fautes externes), et leur persistance (fautes
permanentes, fautes temporaires). La considration simultane de diffrents points de vue
conduit la notion de fautes combines. Par exemple : les fautes de conception sont des fautes
de dveloppement accidentelles ou intentionnelles sans volont de nuire. Les intrusions sont
des fautes oprationnelles externes intentionnellement nuisibles. La distinction entre les
diffrentes classes de fautes permet didentifier des moyens appropris pour se prmunir
contre ces fautes.

1.3.1.3. Moyens
On distingue gnralement quatre classes de moyens pour la sret de fonctionnement [24]:
Prvention des fautes : comment empcher l'occurrence ou l'introduction de fautes.
Tolrance aux fautes : comment fournir un service de accomplir la fonction du
systme en dpit des fautes.
Elimination des fautes : comment rduire la prsence (nombre, svrit) des fautes.
Prvision des fautes : comment estimer la prsence, la cration et les consquences des
fautes.

31
La prvention de fautes relve de lingnierie gnrale des systmes. Elle concerne le choix
et la mise en uvre dun ensemble de processus visant matriser la conception, la ralisation
et la validation du systme, et assurer le bon fonctionnement du systme durant son cycle de
vie. La tolrance aux fautes vise doter le systme de mcanismes pour le traitement
derreurs (liminer les erreurs avant quune dfaillance survienne) et le traitement de fautes
(viter quune ou plusieurs fautes ne soient actives de nouveau). Llimination des fautes
consiste vrifier si le systme satisfait les proprits requises. Dans le cas contraire, il faut
identifier les fautes et les corriger. Enfin, la prvision des fautes est conduite en effectuant des
valuations du comportement du systme par rapport loccurrence des fautes et leur
activation. La figure 6 synthtise les attributs, les moyens et les entraves de la sret de
fonctionnement.

Pour rsumer, les attributs de la sret de fonctionnement (disponibilit, fiabilit, scurit-


innocuit, confidentialit, intgrit et maintenabilit) correspondent aux proprits du systme
lies la sret de fonctionnement. Ils permettent dapprcier la qualit du systme vis--vis
des services dlivrs. Les entraves la sret de fonctionnement (fautes, erreurs et
dfaillances) sont des circonstances indsirables qui causent ou rsultent de la non-sret de
fonctionnement du systme. Pour combattre ces entraves et atteindre les niveaux souhaits des
attributs, les moyens de la sret de fonctionnement vont tre sollicits: la prvention des
fautes, la tolrance aux fautes, llimination des fautes et la prvision des fautes.

Gnralement, la sret de fonctionnement fait lobjet dune validation par un organisme


extrieur et indpendant de la structure qui a dvelopp le systme, surtout lorsque des vies
humaines sont en jeux. Dans certains secteurs dactivit (comme dans laronautique par
exemple), il est question de certification, qui est un contrle de qualit bas sur des normes.

Figure 6: Attributs, entraves et moyens de la sret de fonctionnement

32
1.3.2 Mthodes danalyse de la SdF logicielle
Les mthodes danalyse de la SdF se focalisent sur lanalyse et lvaluation des failles dun
logiciel et de prfrence au dbut de son cycle de dveloppement. Dans ce sens il est
ncessaire de considrer la SdF comme un processus itratif qui doit tre initi depuis la phase
de ltude de faisabilit. Ce processus va saffiner durant les tapes de la phase danalyse et
conception, et au fur et mesure de lavancement du processus, la SdF sera intgre au
logiciel durant limplmentation. Ainsi, il existe quatre approches diffrentes pour analyser la
SdF logicielle [26]:
Par les normes : approche qui se base sur les qualifications des entreprises de
dveloppement (ex : CMMI) ou des spcifications du produit logiciel selon le domaine
ou le mtier.
Par les spcifications : se base sur lutilisation de langages, outils ou mthodes
permettant de construire lexhaustivit et la consistance des spcifications (ex.
mthodes formelles et semi-formelles, UML, etc.)
Par les moyens : se base sur des outils tels que latelier de dveloppement, ou des
rgles (ex. Misra).
Par lanalyse : se base sur la ralisation dtudes localisant et mesurant les risques (ex.
A.E.E.L)
Le mcanisme des mthodes de sret de fonctionnement consiste analyser les dfaillances
du systme, de ses sous-systmes et de ses composants pour dterminer leurs causes et
estimer leurs consquences sur le service rendu par le systme. Ces analyses peuvent tre
qualitatives ou quantitatives. Elles se conforment lune des deux approches suivantes :

Lapproche inductive : correspond un raisonnement du particulier vers le gnral, o


lon recherche les effets dune dfaillance sur le systme ou son environnement.
Lapproche dductive : correspond un raisonnement du gnral vers le particulier, o
lon recherche les causes possibles dune dfaillance.

1.3.3 Exigences de la SdF


Lexigence reprsente gnralement une expression des besoins formule de la part du client
ou de toutes autres parties prenantes pour le systme dvelopper. Elle transforme un besoin
en fonctionnalit (exigence fonctionnelle) ou en qualit (exigence non-fonctionnelle) que doit
satisfaire le produit en cours de conception. Concernant les exigences non fonctionnelles,
celles-ci peuvent reprsenter [25]:

des contraintes globales de qualit de service.


des aptitudes du systme.
des contraintes oprationnelles (conformit des normes dutilisation).
des contraintes de conception (rutilisation dexistant).

33
Lintrt principal dinscrire les besoins en exigences rside dans lambigut qui survient
souvent dans cette phase et qui sera rsolue travers leurs formulations dun ct. De lautre
ct, la finalit sera un support de communication entre les diffrentes parties prenantes du
projet amliorant ainsi la collaboration et la traabilit.
Dans le cas de la sret de fonctionnement, celle-ci se focalise sur les quatre attributs dj
cits : la fiabilit, la disponibilit, la maintenabilit et la scurit qui sont des proprits non
fonctionnelles du systme, mais avant leur implmentation, elles sont aussi des exigences de
sa qualit de service.
La particularit des exigences de SdF concerne la dfinition des vnements redouts et leur
hirarchisation en fonction de leur criticit. Ainsi, une dfinition prcisant des vnements
redouts permet de spcifier sans ambigut les priorits vises et les objectifs donns en
termes de Disponibilit, de Fiabilit, de Maintenabilit et de Scurit. Elle reflte la stratgie
et le niveau de matrise des risques dans le cadre du projet. En mme temps elle permet
dattribuer une certaine confiance justifie au systme dvelopper.
Enfin, il faut noter que cette dfinition des vnements redouts ne peut garantir le gain
estim sans tre inscrite dans le cadre dune dmarche dingnierie qui va assurer sa
normalisation et standardisation. Dans ce sens, la section suivante sert inscrire ltude des
exigences de la sret de fonctionnement des systmes dcisionnels dans un contexte
dingnierie.

1.4 Ingnierie des Exigences de la SdF des SD

1.4.1 Ingnierie des exigences des Systmes

1.4.1.1. Ingnierie des systmes


LAFIS (Association Franaise dIngnierie Systme) qui est compose des entreprises et
industriels comme Airbus, Alcatel, Renault, PSA Peugeot Citron, France Tlcom, EDF,
RATP, et dautres, dfinit lIngnierie Systme comme tant [27] :
Une dmarche mthodologique gnrale qui englobe lensemble des activits adquates
pour concevoir, faire voluer et vrifier un systme apportant une solution conomique et
performante aux besoins dun client tout en satisfaisant lensemble des parties prenantes .

LIngnierie Systme est le domaine qui permet au concepteur de guider son dveloppement
de la meilleure manire possible. En fait, les objectifs principaux de cette science sont
lorigine des problmes affronts qui sont souvent de mme nature :
besoins insuffisamment exprims.
spcifications imprcises ou incompltes.
solutions non justifies ou non valides.
une formation des utilisateurs insuffisante.

34
des ressources et comptences mal planifies.

Autrement dit, lIngnierie Systme est une approche mthodologique qui a t dveloppe
pour permettre aux concepteurs daboutir une solution quilibre selon le meilleur des cots
et des dlais. Elle rpond au mieux aux besoins des diffrentes entits concernes par
lutilisation du systme.
Dans un autre volet, Lorsque lon traite de lIngnierie Systme, il est incontournable de
considrer le cycle de dveloppement du systme et son cycle de vie. En effet, la
mthodologie suivie en impliquant lingnierie systme affecte le cycle de dveloppement du
systme depuis lexpression des besoins jusquau dploiement. Pour ensuite le suivre et le
contrler durant son cycle de vie depuis son exploitation, maintenance jusqu son retrait de
service.

1.4.1.2. Ingnierie des Exigences (IE)


Lingnierie des exigences est une partie trs importante de lingnierie systme. Elle traite
toutes les activits lies aux exigences telles que leur dfinition, leur traabilit, leur
modification, leur gestion en terme de maturit, etc. Lune des dfinitions les plus claires de
lingnierie des exigences est propose par [28]:

Lingnierie des exigences est la branche du gnie logiciel qui concerne les buts rels, les
fonctions et les contraintes dun systme logiciel. Elle concerne aussi la relation que ces
facteurs entretiennent avec les spcifications prcises du comportement logiciel, et avec leur
volution dans le temps et travers les familles de logiciels.

Selon cette dfinition, lingnierie des exigences est le processus de dcouverte de cet objectif
en identifiant, analysant et documentant les parties prenantes et leurs besoins. Les exigences
sont donc lexpression dun besoin document sur ce quun systme ou un logiciel devrait tre
ou faire. Les parties prenantes quant elles dsignent des personnes, des organisations ou des
systmes ayant une interaction directe ou indirecte avec les exigences.
Grer les exigences [29] dans un projet est une activit fondamentale son bon droulement.
En effet, un nombre important de documents peut tre produit lors de la conception dun
systme. Sans lingnierie des exigences, il serait quasiment impossible de garantir la
cohrence et la qualit ncessaire au succs du projet. Effectivement, des tudes statistiques
[30] ont montr que les exigences interviennent pour environ 40% du succs ou de lchec
dun projet, do leur importance vis--vis de notre proccupation. Ainsi, lingnierie des
exigences permet de [25]:

Collecter les exigences.


Faciliter leur expression.
Dtecter les incohrences entres elles.
Les valider.

35
Grer leur priorit (les hirarchiser).
Grer les changements dexigences.
Grer la qualit.
Faire le lien avec le reste du projet et/ou avec le contexte.
Et encore assurer leur traabilit.

Lingnierie des exigences doit aussi veiller ce que chaque exigence soit correctement
dcline, alloue, suivie, satisfaite, vrifie et justifie. Nous saisissons bien limportance de
lingnierie des exigences dans un projet, pour sa russite, et donc pour garantir que le
systme conu rpondra bien aux besoins exprims. Tout cart vis--vis du respect des
exigences pourra tre lorigine dun fonctionnement non-souhait.

1.4.1.3. Ingnierie des Exigences de la SdF


Dans un autre niveau, lingnierie des exigences impose une distinction importante entre les
exigences fonctionnelles et les exigences non-fonctionnelles, notes NFRs (Non-Functional
Requirements en anglais) [31]. Les exigences fonctionnelles se rfrent aux services que le
futur systme doit fournir tandis que les NFRs se limitent la manire dont ces services
doivent tre fournis. Mais, il faut soulever que lanalyse des NFRs nest pas toujours vidente
puisque gnralement il est difficile de les exprimer dune faon objective et mesurable,
comme le souligne [32]. Dautant plus que, les NFRs sont connues pour leur caractre
conflictuel. Par exemple, lutilisation dun double mot de passe augmente la scurit des
donnes, mais elle a des impacts ngatifs sur les performances du systme (ralentir le
systme) et lutilisabilit.
Ainsi, les NFRs touchent beaucoup daspects tels que la performance, les contraintes de
conception, les attributs de qualit, et par consquent la sret de fonctionnement. Cest dans
ce cadre que lingnierie des exigences de la SdF a merg rcemment grce la mont en
complexit des systmes. Cette mont a stimul la naissance de plusieurs mthodologies
dingnierie systme afin de se concentrer sur la prise en compte de leurs sret depuis le
dbut du processus de conception. Plusieurs de ces mthodologies se sont bases sur des
modles pour dtecter et corriger tt les fautes de conception (lorsque les cots de
modification sont encore faibles).
Lide est centre sur lanalyse des risques dans le processus de conception, au lieu dtre
considre comme une activit spare. Ces mthodologies ont facilit la traabilit des
exigences, la vrification des diffrentes proprits du systme (dont la fiabilit), et enfin la
rduction des cots dune modification et dune r-analyse du systme.

36
1.4.2 Dans le contexte des Systmes Dcisionnels

1.4.2.1 Ingnierie des SD et leurs exigences


Comparativement lingnierie des systmes et lingnierie des exigences, qui sont des
disciplines dj bien tablies avec des mthodes, des techniques et des outils reconnus dans la
recherche et lindustrie, lingnierie des SD est une discipline nouvelle [15]. Elle n'offre pas
encore des approches reconnues et standards. Les premires proccupations de lingnierie
des SD ont concern le niveau technique du SD comme il a t montr dans [15].
Ainsi, les approches existantes sont tablies pour dcrire le choix des sources de donnes qui
alimentent le systme, les processus ETL, ou bien l'architecture et la modlisation des
entrepts de donnes et/ou des Data Mart mtier.

Ceci peut tre expliqu par la particularit de sa mise en place. Car, quand un projet
dcisionnel est lanc, et ses exigences sont exprimes, plusieurs problmes et enjeux internes
et externes (qui sont dj cit dans la section 1.2.5) peuvent provoquer lchec de sa mise en
place si elles ne sont pas prises au srieux le plus tt possible.

Dun autre ct, les exigences du SD peuvent tre de quatre types: les exigences stratgiques
relies la stratgie de lorganisation, les exigences tactiques relies une perspective, les
exigences oprationnalisables relies linformation recherche et les exigences systme
relies au systme concevoir. Ces quatre types dexigences sont rpertoris en deux niveaux
: le niveau intentionnel et le niveau oprationnel selon [15].

1.4.2.2 Ingnierie des exigences de la SdF des SD


En tenant compte du rle crucial quil joue dans la prise de dcision, le SD doit justifier un
certain niveau de sret de fonctionnement suffisant pour pouvoir lui faire confiance.
Cependant, nous avons dmontr dans les sections prcdentes (cf. partie 1.2), que les SD
souffrent de problmes qui sont souvent lis leur sret de fonctionnement. Les exigences
de SdF sont implicites, et difficiles recueillir auprs de ses utilisateurs qui sont souvent non
informaticiens (Dcideurs, Auditeurs, Analystes, etc.). De ce fait, ils sont ngligs dans la
plupart des cas jusqu la mise en place du systme.
Dun autre ct, les tudes de sret de fonctionnement permettent de traiter plusieurs
exigences non fonctionnelles en constituant un pralable la conception de tout systme selon
le niveau de tolrance acceptable et exig pour sa sret de fonctionnement. Elles permettent
de comprendre, didentifier et dhirarchiser les risques pour optimiser larchitecture des
systmes et comparer les diffrentes solutions afin de justifier les choix retenus de faon
rationnelle et dmontre.
Cette situation prouve la ncessit de la dfinition dune approche qui permet dintgrer les
exigences de SdF au SD depuis les premires tapes de son cycle de dveloppement. Son

37
objectif est den tenir compte le plutt possible afin de rsoudre leurs interactions mutuelles et
dassurer la conception et la ralisation dun systme raliste et ralisable sur des bases
mthodologiques solides.

1.5 Ingnierie Dirige par les Modles (IDM)

1.5.1 Principes et intrts


Lors du dveloppement dun systme, de nombreux domaines dexpertise peuvent travailler
ensemble, cooprer et collaborer en vue dobtenir une solution satisfaisante. Lingnierie
systme a pour rle de faire cohabiter toutes ces disciplines en les intgrant au sein dun
mme ensemble de processus. La tche nest pas vidente, surtout lorsquil sagit de faire
communiquer tous les acteurs.
Pour cela, il semble ncessaire de sappuyer sur un langage commun. Le moyen le plus sr et
contenant le moins dambigits et de divergences de comprhension reste sans aucun doute
lutilisation et le partage de modles [33]. Le concept de modle reste en fait indissolublement
li celui de systme. Du fait de la complexit du systme matrialise par leur htrognit
et leur pluridisciplinarit, lesprit humain napprhende la complexit quen la modlisant. En
effet, comprendre ou concevoir ne revient qu crer des modles mentaux. Agir ou raliser
nest rien dautre que de se conformer aux modles que lon a construits.

Cest dans ce sens que nous avons choisi de procder par lapproche dirige par les modles
(IDM) afin de guider la mise en place dun SD et en tenant compte de aspects de sret de
fonctionnement. En effet, lingnierie dirige par les modles prconise lutilisation des
modles comme entit centrale. Cette approche a contribu en une monte en puissance des
modles qui ont pass de leur stade contemplatif (visuel et documentaire) un stade plus
productif qui envisage lutilisation des modles au cur du cycle de dveloppement de ces
systmes [34].
Avec cette approche, le code final excutable nest plus considr comme llment central
dans le processus de dveloppement mais comme un lment naturellement important qui
rsulte dune transformation de modles. Dans [35], cette transformation de modles est
dfinie comme la gnration dun ou de plusieurs modles cibles partir dun ou de plusieurs
modles sources.

Dans lIDM, un modle peut tre dfini simplement comme une reprsentation ou une
abstraction dune partie dun systme. Par analogie avec le monde de la programmation, un
programme excutable reprsente le systme alors que le code source de ce programme
reprsente le modle. De cette premire dfinition dcoule une nouvelle relation appele
represents reliant le modle et le systme modlis [35].
En poursuivant lanalogie avec le monde de la programmation, un programme est crit ou est
exprim dans un langage de programmation. Un modle est crit ou est exprim dans un

38
langage de modlisation. Dans le contexte de lIDM, la dfinition dun langage de
modlisation a pris la forme dun modle, appel mtamodle [36]: On dit aussi que le
mtamodle reprsente ou modlise le langage. Il rsulte de cette deuxime dfinition une
nouvelle relation appele conforms-to qui lie le modle et son mtamodle. A titre
dexemple, le mtamodle dUML offre des concepts permettant de dcrire les diffrents
modles (diagramme de classes, diagramme de cas dutilisation, etc.) dun systme.
Toujours par analogie avec le monde de la programmation, on dira quun langage de
programmation respecte la grammaire BNF. Il rsulte de cette dfinition une troisime
relation, galement appele conforms-to, qui relie le mtamodle son mta- mtamodle.
Le mta-mtamodle est un langage dexpression de mtamodles (par exemple le mta-
mtamodle de MOF [37]). La Figure 7 ci-aprs rsume ces notions de base dans lIDM.

Figure 7: Bases de lIngnierie Dirige par les Modles

L'IDM a pour principal objectif de relever un certain nombre de dfis du gnie logiciel
(qualit, productivit, sret, sparation des proccupations, cot, etc.) en suivant une
approche base de modles dite gnrative. En focalisant le raisonnement sur les modles,
lIDM permet de travailler un niveau dabstraction suprieur et de vrifier sur une maquette
numrique (ensemble de modles qui traitent divers aspects dun systme) un ensemble de
proprits que lon devait vrifier auparavant sur le systme final [38]. Le plus important des
avantages du travail sur maquette numrique au lieu du traditionnel code logiciel, se rsume
dans le fait de fournir un rfrentiel central permettant plusieurs acteurs de s'intresser aux
diffrents aspects du systme (scurit, performance, consommation, etc.).

1.5.2 Architecture Dirige par les Modles (MDA)


La naissance du MDA a t motive par la complexification des systmes d'information et des
forts cots de migration technologique. L'OMG [39] (Object Management Group) propose

39
ainsi de monter le niveau d'abstraction pour s'affranchir des contraintes technologiques. Ses
intrts se rsument dans les points suivants [40][34] :
a. Sparation entre logique mtier et technologie

L'histoire des systmes d'information a connu de nombreuses volutions que ce soit au niveau
des langages de programmation (procduraux et fonctionnels, vnementiels, orients objet,
services web, etc.), des middlewares (propritaires, CORBA, DCOM/COM+, RMI, etc.) ou
des mthodes de conception (SADT, Merise, les mthodes Orientes Objet, etc.). De plus, la
diversit des solutions pour rsoudre un mme problme ne cesse daugmenter.
Dans ce contexte, les chefs d'entreprise ne veulent plus investir dans un middleware dont la
prennit est courte. Avec CORBA, l'OMG pensait fournir une norme suffisamment puissante
et ouverte pour rpondre tous les besoins. Le consortium pensait que CORBA deviendrait
ainsi le middleware standard universel l'instar d'UML comme formalisme de modlisation.
Cependant des architectures diffrentes se succdrent, obligeant les entreprises former
leurs ingnieurs et remettre jour leurs applications. Toutefois, lors d'une migration d'une
infrastructure vers une nouvelle technologie, la logique mtier de l'application reste la mme
et gnralement change trs peu. Il est donc vident de tenter de diffrencier l'architecture
technique dpendant de la technologie utilise de celle de la logique mtier. L'intrt est de
favoriser l'volutivit, la rduction de cot et l'interoprabilit.
Pour aller dans ce sens, les grandes compagnies informatiques ont ressenti le besoin de
standardiser les diffrentes tentatives. Elles ont donc logiquement charg le consortium de
l'OMG de la mission de dfinir une norme indpendante d'un middleware particulier.
b. Abandon de la concurrence des middlewares

La nouvelle orientation de l'OMG, le MDA, a t rendue publique en novembre 2000. Il s'agit


d'un constat ralis douze ans aprs la cration de l'OMG. La recherche de l'interoprabilit
entre systmes d'information ne peut tre atteinte uniquement grce la standardisation des
infrastructures de middleware, mais par une approche beaucoup plus globale o la notion de
modle devient essentielle et centrale [5].
Pour rsum, l'OMG dclare que la guerre des middlewares est termine. Des acteurs divers
proposent des middlewares htrognes auxquels ils sont attachs. Par consquent, il ne
servirait rien d'essayer d'imposer un ultime middleware.

Cette analyse de la situation n'est pas nouvelle puisque l'OMG avait dfini des ponts pour
passer de CORBA vers d'autres plates-formes. Toutefois, selon ce groupe, cette solution ne
pouvait reprsenter un objectif raliste de long terme, ni tre la base d'une stratgie [6].

40
c. Monte en abstraction

La stratgie de la MDA se dmarque des anciens standards en se positionnant clairement un


niveau d'abstraction suprieur et en mettant le projecteur non plus sur les approches objets
mais sur les approches modles de composants [7]. Le but est de favoriser l'laboration de
modles de plus haut niveau d'abstraction et des approches de transformation vers les plates-
formes techniques. Ceci signifie qu'il sera possible de dfinir un modle mtier totalement
indpendant des plates-formes techniques et de gnrer du code spcifique la plate-forme
d'implmentation.
Linitiative MDA repose sur un changement de paradigme important dans le domaine du
gnie logiciel. La rapidit de cette volution s'explique par trois facteurs au moins. Le premier
facteur est la ncessit de dcoupler les lments du logique mtier, qui sont souvent stables,
de la logique des supports technologiques informatiques considrs volutives dans le temps.
Cette volution logicielle de caractre non conjoncturel, inluctable et perptuel ne va pas se
ralentir. Toutefois, elle ne doit pas pnaliser la capitalisation logicielle du savoir et du savoir-
faire de l'entreprise.

Le deuxime facteur concerne la relative incapacit de la technologie oriente objet tenir ses
promesses. La complexit croissante des dploiements logiciels bass sur les formes
modernes de composants comme les EJB est contraire aux espoirs de simplification
conceptuelle des promesses de la technologie. Le recours des expdients technologiques
(cas d'utilisation, patterns de conception, programmation oriente aspect, etc.) ne fait que
renforcer le constat que la technologie oriente objet n'est pas le remde miracle du gnie
logiciel [8].
Le troisime facteur est l'urgence de stopper l'empilement des technologies. Les systmes
d'information sont parfois composs d'une mosaque htrogne de technologies, pour
lesquelles il est ncessaire de conserver des comptences associes pour des raisons de
maintenance. Cette situation s'tend au fur et mesure que les systmes s'agrandissent.

La parade cette accumulation de surcouches technologiques consiste remplacer les


approches interprtatives par des approches transformationnelles capables de gnrer des
systmes plus lgers, moins gourmands en ressources et plus finement adapts aux besoins
rels des applications. L'approche interprtative reconnat que les individus ont un rle trs
actif dans la construction des systmes informatiques alors que l'approche transformationnelle
rduit leur rle grce une automatisation de la construction.

1.6 Synthse
Ce chapitre a t structur de manire pouvoir prsenter une dfinition dtaille et
suffisamment profonde de toute la terminologie utilise dans ce mmoire. Laccent a t
surtout mis sur les trois thmatiques cls constituant son titre.

41
Ainsi, dans un premier temps, nous avons abord les SD, en dfinissant leurs fondements
thoriques, leurs missions et finalits afin daccentuer leur importance et utilit pour la prise
de dcision. Ensuite nous nous sommes penchs sur les aspects techniques du SD en
prsentant son architecture standard et en dfinissant les dtails techniques de chacune de ses
couches dans toute la chane dcisionnelle. Enfin nous avons essay de rassembler les
problmatiques et les faiblesses dont souffrent les SD gnralement, pour ensuite les
dcortiquer par couche. Ce cheminement nous a permis de dmontrer que la mise en place
dun SD en respectant seulement ses exigences fonctionnelles risque de le transformer en un
systme obsolte. Ce constat provient du fait que le SD doit justifier un certain niveau de
confiance suffisant pour la prise de dcision. Or cette confiance nest assure que si sa sret
de fonctionnement est mise en avant plan lors de sa conception et mise en uvre.

Dans cette perspective, nous avons entam la dfinition de la sret de fonctionnement en


prcisant ses trois concepts de base, savoir: les attributs, les entraves et les moyens. Les
attributs correspondent aux proprits du systme qui influencent directement sa sret de
fonctionnement et affectent sa qualit. Les entraves reprsentent les manifestations (causes ou
rsultats) de ces attributs, alors que les moyens reprsentent lensemble des techniques
utilises pour atteindre les niveaux exigs en termes de ses attributs et entraves. Toutefois la
SdF est une discipline qui puise ces origines des domaines aronautique, automobile, etc.
Donc, nous avons d prsenter un rsum des mthodes connues qui concernent lanalyse de
la SdF logicielle pour enfin dfinir le terme exigence et prciser exactement son sens pour de
la SdF.

ce stade du chapitre nous avons essay de tisser les deux concepts, SD et SdF, dans un
cadre mthodologique et formel. Ceci nous a impos dintroduire toute la terminologie qui
dcompose lunivers de lingnierie propres aux exigences de sret de fonctionnement des
systmes dcisionnels. Ainsi, nous avons suivi une dmarche descendante en passant de la
dfinition de lingnierie des systmes, des exigences (plus particulirement des exigences de
La SdF), celle de lingnierie des SD pour pouvoir dlimiter le cadre et le contexte de notre
problmatique de recherche et de dfinir ainsi sa porte.
Enfin, le chapitre se termine par une prsentation de lapproche sur laquelle nous nous somme
bass dans nos travaux de recherches. Donc nous avons prsent lintrt de lIngnierie
Dirige par les Modles (IDM) ainsi que son utilit. Nous avons dmontr encore une fois
quen se basant sur cette approche, nous avons obtenu un environnent fertile de normes et
standards (MDA, MOF, QVT, etc.). Ces derniers nous ont servis pour lever le verrou de notre
problmatique qui se rsume intgrer les aspects de la SdF dans un SD ds les premires
tapes de son cycle de dvelopemment tout en tenant compte de leurs intrractions.
Le chapitre suivant prsente un tat de lart du contexte de notre thse. Ainsi, il aborde les
travaux de recherche concernant le systme dcisionnel en les dtaillants par couche. Ensuite,

42
il dveloppe les travaux qui ont trait les attributs de la SdF des SD et les diffrentes
mthodes existantes de lingnierie dexigence. Enfin, nous avons prsent les approches
diriges par les modles dans le contexte des systmes dcisionnels.

43
Chapitre 2 : Etude de lEtat de lart

Il faut avoir lesprit lavenir et le pass dans les actes.


Talleyrand

44
2.1 Introduction
Lobjectif de ce chapitre est de prsenter un tat de lart du contexte de nos travaux de
recherche. Dans cette perspective le chapitre est structur suivant cinq sections. La premire
partie tale lensemble des travaux qui traitent chaque couche du systme dcisionnel. Ensuite
la deuxime expose les travaux qui concernent les attributs de sret de fonctionnement des
systmes dcisionnels, la troisime relate les mthodes dingnierie des exigences dans le
contexte des systmes dcisionnels et la dernire expose les approches diriges par les
modles concernant les systmes dcisionnels. Enfin, chaque section se termine par un
rcapitulatif et confrontation des travaux prsents permettant de synthtiser les travaux
abords de les discuter pour pouvoir positionner nos travaux de recherche et accentuer la
problmatique nonce au premier chapitre.

2.2 Etat de lart des Systmes Dcisionnels

2.2.1 Sources de Donnes


Selon [41], l'intgration des sources de donnes est parmi les aspects les plus importants d'un
systme dcisionnel. Lorsque des donnes passent de l'environnement oprationnel ax sur
l'application transactionnelle (OLTP : On line Transaction Processing) lentrept de
donnes, les incohrences et les redondances ventuelles devraient tre rsolues, de sorte que
l'entrept est en mesure de fournir une vision intgre et rconcilier des donnes.
Il existe deux approches de base pour le problme de l'intgration de donnes, appels
procdurales et dclaratives [42]. Dans l'approche procdurale, les donnes sont intgres de
manire ad-hoc par rapport un ensemble de besoins d'information prdfinis, sans avoir
recours une notion explicite de schma intgr de donnes. Dans l'approche dclarative,
l'objectif est de modliser les donnes provenant des sources au moyen d'un langage adapt, et
de construire une reprsentation unifie pour tre utilise lors de l'interrogation du systme
d'information global [42].
Dans une autre perspective, les approches de conception de lentrept sont gnralement
classes en deux catgories [43][44]: les approches bases sur les sources de donnes qui
permettent de concevoir le DW partir d'une analyse dtaille des sources de donnes. Dans
ce cas les besoins des utilisateurs impactent sur la conception en permettant au concepteur de
slectionner les donnes qui sont pertinentes pour la prise de dcision et par la dtermination
de leur structuration selon un modle multidimensionnel [45]. Lautre catgorie est
reprsente par les approches diriges par les exigences. Ainsi, la conception se base sur la
dtermination des besoins d'information des utilisateurs finaux, et donc la mise en
correspondance de ces exigences avec les sources de donnes disponibles est tudie
uniquement a posteriori [46]

45
D'autres auteurs, comme [47] utilisent une sorte de mixture de ces deux approches, et
considrent la fois les deux catgories (c'est dire les sources des donnes et les exigences
de l'utilisateur) en mme temps.

Enfin, une approche est propose dans [48] qui repose sur la dfinition d'un ensemble de
modles de conception (Design Patterns), de telle sorte quune fois le modle requis est
trouve, il doit simplement tre adapt aux exigences relatives aux sources de donnes et
besoins utilisateurs.

2.2.2 Extraction Transformation Loading


Nous prsentons dans cette section les principaux travaux portant sur ltude de la phase de
conception ETL.
Les auteurs de [49] proposent de dfinir le processus ETL, en modlisant le flux de donnes
comme une composition dactivits dfinissant ainsi un scnario ETL. Les scenarii sont
regroups par un graphe darchitecture, o les activits ETL et les sources de donnes sont
reprsentes par des nuds lis par quatre diffrentes types de relations (instance-de, partie-
de, relation de rgulateur et relation de fournisseur). Toutefois, les auteurs ont dvelopp leur
approche uniquement sur les bases de donnes relationnelles. Dun autre ct, les auteurs ont
propos dans un autre travail [50] une mthodologie de modlisation conceptuelle du
processus ETL base sur la modlisation conceptuel des activits du processus ETL. Le
modle facilite la dfinition des correspondances entre les sources de donne et lED ainsi
que les transformations pour le chargement des donnes.
Les travaux prsents dans [51], explicitent le passage dun modle conceptuel dcrivant le
processus ETL vers un modle logique ETL (conu selon lapproche prsente dans [49])
suivant une approche semi-automatique. Cette dernire est structure autour des phases
suivantes: (1) le raffinement du modle conceptuel ETL pour llimination des ambigits
existantes et lidentification des sources candidates ; (2) la correspondance des concepts et
attributs du modle conceptuel avec les structures de donnes et les attributs du modle
logique; (3) lapplication dun algorithme de mise en correspondance entre les
transformations du modle conceptuel et les activits du modle logique ETL tout en
prcisant lordre dexcution des activits; (4) lenrichissement du modle logique par
lintroduction des contraintes imposes sur les donnes; (5) lassurance de la cohrence de
lordre des activits ETL; et enfin (6) la gnration du schma reprsentant les squences des
activits ETL qui reprsente le schma logique ETL.
Des chercheurs proposent dans [52] une approche pour automatiser le processus de
conception ETL. Leur approche est base sur une ontologie OWL (Ontology Web Language)
et les annotations smantiques. Ces derniers permettent de spcifier dune manire formelle et
explicite la smantique des schmas sources et cible de lED. Lapproche se droule selon les
phases suivantes : (1) la construction dun vocabulaire commun du domaine dapplication

46
travers la lecture des modles conceptuels des sources et de lED; (2) la proposition dune
mthode dannotation des sources de donnes et de lED base sur le vocabulaire construit
(elle permet dtablir des mappings entre les schmas relationnels et les concepts du
vocabulaire dfini); (3) la proposition dun algorithme de gnration dune ontologie
dapplication dcrivant le domaine dapplication et les mappings entre cette ontologie et les
schmas des sources et de lED; (4) la proposition dun algorithme didentification des
transformations ETL.

Dautre chercheurs proposent dans [53] une approche pour dfinir la meilleure configuration
dimplmentation physique dun workflow ETL. Lapproche prend la reprsentation logique
du processus ETL et un modle de cot en entre. Ensuite, elle dfinit un algorithme
permettant la traduction de la reprsentation logique du Workflow ETL vers son modle
physique. Cet algorithme utilise une bibliothque de modles rutilisables (Template) pour les
activits ETL logiques et physiques. Ainsi, les modles (ou Templates) logiques matrialisent
les activits logiques, et les modles (ou Templates) physiques matrialisent les activits
physiques. Enfin, une mise en correspondance permet de lier les modles logiques et
physiques.

2.2.3 Entrepts de Donnes (ED)


Nous prsentons dans cette section les principaux travaux proposant des mthodes de
conception du schma de lED, couvrant une ou plusieurs des phases suivantes : dfinition des
besoins, modlisation conceptuelle, modlisation logique et modlisation physique.
Les auteurs proposent dans [54] une mthode de conception d un modle dun ED partir
des schmas E/A dcrivant les sources de donnes. Le modle conceptuel final est appel
Dimensional Fact model (modle DF). Il est constitu dun ensemble de schmas sous forme
dun arbre dont la racine est le fait et les feuilles sont les dimensions. La mthode a t
ractualise et dtaille dans [55] selon six tapes : (1) analyser des sources de donnes pour
permettre la gnration du schma conceptuel les dcrivant. (2) collecter et analyser les
besoins des utilisateurs. (3) construire le schma conceptuel multidimensionnel (modle DF).
Ce modle est gnr dans un premier temps par la dfinition des faits alors que les entits et
relations ayant subi le plus de modifications et de mises jour sont considres comme des
candidats potentiels. Ensuite, larbre des attributs de chaque fait est construit. Celui-ci a
comme racine lidentifiant du fait et comme nuds ses attributs. (4) traduire chaque fait et
chaque dimension identifis en une table relationnelle pour la dfinition du modle logique de
lED. (5) Traduire le modle logique au niveau physique en fournissant des directives pour
limplmenter dans un outil de type ROLAP, et pour dfinir quelques structures
doptimisation comme les index, etc. (6) enfin, estimer une charge de requtes de lED dans le
but dvaluer le schma conceptuel multidimensionnel obtenue.

47
Des travaux proposent dans [56] de dfinir le schma conceptuel multidimensionnel en se
basant sur lanalyse des besoins selon une approche oriente agent qui utilise le Framework
i*. Ce Framework introduit les notions dagent et de but dans les diffrentes phases de
dveloppement dun systme. Ainsi, il permet didentifier les utilisateurs du systme et les
modliser en acteurs sociaux en explicitant leurs dpendances vis--vis des buts et des tches
effectuer, et des ressources utiliser. Cette approche peut sarrter sans la considration des
sources de donnes. Toutefois, lapproche mixte ou hybride est envisageable en ralisant une
mise en correspondance entre les concepts multidimensionnels du schma conceptuel et les
entits des schmas des sources. Cette mise en correspondance est ralise par le concepteur
manuellement par lassociation de chaque fait, dimension ou mesure du schma conceptuel
une table ou un attribut dans les sources. Alors que les hirarchies de dimensions sont
construites en prcisant les dpendances fonctionnelles entre les diffrents attributs ou
relations.

Les auteurs de [57] ont prsent une mthode oriente sources afin de dfinir le schma
logique final de lED partir des schmas E/A des sources de donnes dune manire
automatique. Leurs mthode se base sur les tapes suivantes : (1) les associations ternaires des
schmas E/A des sources sont transformes en des associations binaires; (2) les faits sont
extraits partir des entits qui ont le nombre dassociations un plusieurs suprieur une
valeur seuil; (3) les dimensions du fait sont construit base des entits lies aux entits faits
par des relations un plusieurs. Enfin, les auteurs se sont bass sur lontologie terminologique
Wordnet afin didentifier les hirarchies de dimensions.

Le travaux de [58] se sont bass sur une ontologie dcrite en langage OWL (Ontology Web
Language) pour proposer une mthode semi-automatique de conception multidimensionnelle
dun ED. Cette mthode tudie les multiplicits entre les concepts de lontologie pour dfinir
les faits et dimensions du schma de lED. Ainsi, un concept de lontologie est un fait
potentiel sil est li un grand nombre de dimensions et de mesures. Alors quun concept de
lontologie est une dimension potentielle sil est rattach un fait par une relation un
plusieurs. Lavantage de cette identification est la possibilit de la raliser de manire
automatique.

Des auteurs ont propos dans [59] de concevoir un ED semi-structur, qui stocke les
ressources du web, les ontologies de domaines et les annotations smantiques utilisant ces
ontologies. Ces annotations sont fournies grce un Framework permettant danalyser les
donnes fournies par le web smantique sous forme de mta donnes xml ou Rdf.

2.2.4 Outils de Restitution


Les outils de restitutions sont tous les outils danalyse des donnes stockes dans les
entrepts. Ces outils sont trs varis. Elles dpendent des besoins des utilisateurs et font appel
des techniques diffrentes :

48
Le Reporting avec la construction de tableaux de bord, dindicateurs, de graphiques.

La navigation multidimensionnelle dans les donnes avec la technologie OLAP.


La fouille dans les donnes laide des mthodes de Data Mining.

En terme de restitution multidimensionnelle, les premiers travaux ont tendu les oprateurs de
lalgbre relationnelle [60], il sagit au dbut dune transcription SQL des oprations de
restitution. Toutefois, lalgbre relationnelle se rvle inadaptable pour la manipulation de
structures multidimensionnelles. Et de nombreux travaux ont propos des oprateurs et des
oprations pour spcifier et manipuler les donnes [61][62][63].
Dans [64], un langage algbrique de manipulation a t propos pour complter ces
propositions. En plus, les travaux prsents dans [65] sont considrs comme un dbut de
formalisation de langage de manipulation multidimensionnel appliqu la spcification
danalyse de donnes complexes
Malgr labsence de standard, il existe un accord gnral sur un noyau doprateurs de
manipulation. Ainsi, la plupart des propositions offrent un support partiel pour les catgories
doprations suivantes: oprations de forage (roll-up et drill-down), oprations de slection,
(slice, dice), oprations de rotation (rotation de dimension, de fait ou drill-across, rotation de
hirarchie), oprations de modifications du sujet danalyse, oprations de modifications dune
dimension (push, pull), oprations dordonnancements, et les oprateurs binaires (union,
diffrence et intersection).

Certains travaux ont aussi propos la notion de jointure (join) inspire de la jointure
relationnelle, mais dun intrt limit dans un environnement multidimensionnel. Il est
intressant de noter que les oprateurs binaires sont des oprateurs ncessitant de trs fortes
contraintes. Par exemple, lunion entre deux structures multidimensionnelles ncessite une
compatibilit presque complte des deux structures [64].

2.2.5 Comparatif des travaux traitant les couches des SD


Le tableau ci-dessous permet dlaborer un bilan des contributions cites ci-dessus, afin de
procder une tude comparative les synthtisant. Le symbole (++) reprsente linfluence
positive directe, (+) reprsente linfluence positive indirecte, (-) reprsente la neutralit et (--)
influence ngative indirecte.

Couches SD Sources Entrept Outils de


ETL
Propositions Donnes de Donne Restitution

[42] Procdural/Dclarative ++ - + -

[45,47] Ax sur les Sources ++ - + -

49
[46,47] Ax par les exigences ++ - + -

[48] Design patterns ++ - + -

[49] scnario ETL - ++ - -

[50] Modlisation Conceptuelle ETL - ++ - -

[51] Du conceptuel au logique ETL - ++ - -

[52] Ontologie pour automatiser - ++ - -

[53] Workflow + Template - ++ - -

[54, 55] Dimensionnel Fact Model - - ++ -

[56] Framework i* + - ++ -

[57] Automatisation de [45] + - ++ -

[58, 59] Ontologie et annotation - - ++ -

[60] Extension Algbre Relationnel - - - ++

[61, 62, 63] Oprateurs - - - ++

[64] Langage Algbrique - - - ++

[65] formalisation de 64 - - - ++

Quasiment aucune proposition noffre un support complet pour toute la chaine dcisionnelle,
la plupart sont axs sur une ou deux couches au maximum sans tenir compte que chaque
couche se base sur les services dlivrs par la couche prcdente pour accomplir sa fonction
dans le systme dcisionnel. Cest dans cette perspective que nous avons propos de traiter le
systme dans son intgralit tout en prservant la particularit de chacune de ses couches.

2.3 Sret de Fonctionnement des Systmes Dcisionnels


Dans cette partie nous nous intressons aux diffrentes mthodes et techniques existantes qui
visent amliorer chacune des attributs de la sret de fonctionnement. En tenant compte des
dfinitions prcdentes de la disponibilit et de fiabilit, les deux soulignent la prvention des
arrts du systme dcisionnels et sont donc proches les uns des autres qu'ils ne le sont aux
autres attributs de la sret de fonctionnement. Par consquent, la fiabilit et la disponibilit
peuvent tre regroups, et collectivement dfini comme la prvention ou la minimisation des
interruptions de service [22]. Quant la maintenabilit et la scurit, elles seront traites
indpendamment.

50
2.3.1 Disponibilit et fiabilit
Les travaux visant amliorer la disponibilit et la fiabilit des systmes dcisionnels se sont
intresss la rduction du temps de rponse par la proposition de mthodes et techniques
doptimisation des requtes et de la phase de lETL.

2.3.1.1 Techniques d'optimisation des requtes


Beaucoup de techniques d'optimisation des requtes existent dans la littrature pour satisfaire
la demande de la disponibilit extrme des donnes des systmes dcisionnels [66]. La plupart
de ces techniques sont issues de systmes traditionnels de bases de donnes relationnelles.

Vues matrialises : Les vues matrialises sont utilises en gnrale pour stocker des
donnes agrges afin de rduire la surcharge associe des jointures coteuses ou des
agrgations pour un ensemble important de requte. Lobjectif derrire l'utilisation des vues
dans les systmes dcisionnels est d'acclrer le traitement des requtes sur de grandes
quantits de donnes. En vue dun traitement efficace de ces requtes, un ensemble de vues
troitement lies des requtes est matrialis au data warehouse [67]. Toutefois, Deux
problmes majeurs sont lis la matrialisation des vues: leurs maintenance et leurs slection
[68]. En plus, il nest pas possible de matrialiser toutes les vues cause de la contrainte sur
les ressources comme l'espace disque, temps de calcul, ou les cots de maintenance[69].
Techniques d'indexation : L'indexation cre des structures qui offrent un accs rapide aux
donnes pertinentes. La taille de la structure de l'index devrait tre gre afin de bnficier de
ses avantages en parcourant les tables. Les stratgies d'indexation traditionnelles utilises dans
les systmes de bases de donnes ne sont pas aussi efficaces dans les environnements du data
Warehouse vu le volume des donnes charges et la complexit des requtes de restitution
[70]. Un certain nombre de stratgies d'indexation ont t proposes pour le Data warehouse
[71]: l'index liste de valeurs, lindex de projection, lindex bitmap, lindex peu tranch,
lindex de donnes, lindex de jointure, et l'index toile de jointure, etc. Toutefois, le
problme qui simpose assez souvent est celui de la slection de lindex adquat[72].
Partitionnement des donnes : Le processus de partitionnement des donnes dcompose de
grandes tables (tables de faits, des vues matrialises) en des petites tables en appliquant les
oprateurs de slection. Par consquent, le partitionnement offre des amliorations
significatives en matire de disponibilit, de l'administration, et les performances de balayage
de table [73]. Plusieurs types de techniques de partitionnement sont proposs pour
dcomposer une table: verticale, horizontale, mixte et gntique. La fragmentation verticale et
horizontale, permettent de fragmenter les tables selon des partitions qui se composent
respectivement d'un ensemble de colonnes, de lignes de la table d'origine [74][75]. La
fragmentation mixte [76] permet de les fragmenter la fois verticalement et horizontalement,
alors que la fragmentation gntique propose lutilisation des algorithmes gntiques pour
assurer la fragmentation la plus adapte aux besoins des requtes [77].

51
Traitement parallle : En partageant les donnes du schma OLAP (schma en toile ou
schma en flocon de neige) entre un ensemble de processeurs, les requtes OLAP peuvent tre
excutes en parallle, et peuvent ainsi atteindre une acclration linaire ce qui amliore
significativement le temps de rponse des requtes[78]. Par consquent, le partitionnement
des donnes et le traitement en parallle sont deux techniques complmentaires pour parvenir
la rduction du cot du traitement des requtes dans les environnements data warehouse
[73].

2.3.1.2 Optimisation de lETL


La phase ETL du systme dcisionnel est la partie la plus susceptible de consommer de
ressources et tre la cause de larrt du systme ou au moins de son indisponibilit. Ainsi deux
orientations scientifiques sont apparues pour amliorer la fiabilit et la disponibilit de cette
phase savoir les concepts du Workflow appliqus lETL et les techniques du temps quasi-
rel (ou temps rel)
Ltude prsente dans [79] se focalise sur l'optimisation logique du processus ETL, en le
modlisant comme un problme de recherche dtat-espace. Ainsi elle considre chaque
workflow ETL comme un tat tout en fabriquant l'espace d'tat travers un ensemble de
transitions d'tat correctes [80]. En outre, ltude [79] fournit des algorithmes de minimisation
du cot d'excution du flux de travail de lETL.
En revanche, le travail labor dans [81] introduit les concepts du temps rel appliquer pour
avoir un ETL temps rel (ou au moins sen approcher). Lobjectif est de permettre aux
utilisateurs finaux daccder des donnes parfaitement nettoyes, intgres, et rconcilis
tout en tant aussi frais que possible, et en mme temps, sans compromettre la disponibilit ou
le dbit des sources ou de l'entrept de donnes [82].

2.3.2 Maintenabilit
Dans un premier temps, on doit faire la distinction entre deux concepts, savoir : la
maintenabilit et la maintenance[83]:
Maintenabilit: c'est la capacit d'un lment dtre maintenue. Cette capacit dcoule de
l'ensemble des caractristiques de conception qui favorisent la capacit de service.
Maintenance: est une srie d'actions caractre appropri (ex. contenu, la qualit, etc.)
afin de restaurer ou de conserver un lment dans un tat oprationnel.
Toutefois, ces deux concepts peuvent tre confondus car il est difficile de procder la
maintenance d'un systme alors quil nest pas maintenable, et vice versa. Donc la possibilit
de la maintenance et son degr donne un certain niveau de maintenabilit au systme [83].
Dans le contexte des systmes dcisionnels, la plupart des travaux se sont focaliss surtout sur
la maintenance du point de vue volution du systme. Cet volution est gnralement cause

52
par lvolution des besoins et exigences des utilisateurs dun ct et des donnes de
lenvironnement dun autre ct.

2.3.2.1 Maintenance par mise jour du modle


Technique SCD: Kimball a propos dans [84] la technique Slowly Changing Dimensions
ou dimensions changeantes volution lente. Cette technique propose trois types de
solution pour grer la maintenance des dimensions changeantes. La premire solution
consiste craser lenregistrement avec la nouvelle valeur ce qui va engendrer la perte de
lhistorique. La deuxime solution consiste crer un enregistrement supplmentaire qui
correspond alors une description unique valide pendant une priode donne. La troisime
solution est de crer un champ conservant lancienne valeur de lattribut dans le mme
enregistrement. Cependant des limitations existent pour cette solution [85], si par exemple il y
a une succession de changements prendre en compte.
Oprations dvolution : ces techniques se basent sur un modle formel pour la mise jour
des dimensions et de leur hirarchie, en proposant plusieurs oprateurs. Ces derniers
rpondent non seulement une volution des instances des dimensions, mais galement une
volution structurelle des dimensions, telle que lajout dun niveau de granularit en fin de
hirarchie [86]. En plus, ces techniques sintressent aussi leffet de ces mises jour sur les
vues matrialises (les cubes) en proposant des algorithmes pour raliser leur maintenance de
faon efficace. Non seulement ces techniques ont facilit lvolution au niveau des
dimensions, mais galement lvolution des faits. Et ceci grce une algbre comprenant
quatorze oprations dvolution qui peuvent tre combines pour raliser des oprations
dvolution complexes [87]. Enfin plusieurs extensions de ces travaux proposent la
propagation de ces changements du niveau conceptuel vers le niveau logique [88].

2.3.2.2 Maintenance par modlisation temporelle


Cette maintenance soppose celle des travaux sur la mise jour de modle vis--vis de la
traabilit des volutions subies par celui-ci. Pour assurer cette traabilit, des extensions
temporelles sont ncessaires pour enrichir le modle.

Gestion temporalit des instances: Cette technique permet de grer la temporalit des
instances de dimensions [89]. Pour cela, un schma en toile temporel est propos pour
reprsenter le fait que les informations dans un entrept de donnes sont valables sur une
dure donne. Il sagit donc de reprsenter les donnes en temps consistant. Le principe est
domettre la dimension temps qui permet habituellement lhistorisation des donnes et
dajouter une tiquette temporelle au niveau de chacune des instances des tables de dimension
et des faits de lentrept.
Gestion de la temporalit des liens dagrgation : les travaux prsents dans [90] suggrent la
gestion de la temporalit des liens dagrgation. Il sagit de pouvoir grer des dimensions

53
temporelles pour lesquelles les hirarchies ne sont pas fixes au niveau des instances. Ainsi le
chemin dagrgation dfini pour une instance le long dune hirarchie peut voluer au cours
du temps. Pour interroger ce modle, les auteurs proposent un langage de requtes nomm
TOLAP.
La gestion des versions constitue une voie de recherche trs explore actuellement. Cela
consiste grer diffrentes versions du modle de lentrept, chaque version tant valide
pendant une dure donne. Le modle propos par [91] introduit des fonctions de mise en
correspondance qui permettent la conversion entre des versions de structures. Ces fonctions
sont bases sur la connaissance des volutions opres. Les auteurs de [92] proposent une
approche qui permet lutilisateur dobtenir des analyses en fonction de ses besoins de
comparaisons des donnes. En effet, le modle propos permet de choisir dans quelle version
analyser les donnes. Diffrents travaux se sont ensuite focaliss sur le versioning qui permet
de rpondre des what-if analysis, en crant des versions alternatives, en plus des versions
temporelles, pour simuler des changements de la ralit et sur la possibilit de raliser des
analyses en prenant en compte diffrentes versions [93].

2.3.3 Scurit
Le Data warehouse est la banque dinformations sensible de tout organisme. Cest pour cette
raison que plusieurs solutions ont surgies pour scuriser ses donnes selon diffrents niveaux
savoir le niveau logique, physique et conceptuel [94][95]. Dans cette partie, nous allons
cerner les diffrentes mthodes existantes
Les donnes de filtrage et de cryptage des donnes [96] propose un Framework de filtrage des
donnes avant leur stockage dans le Data warehouse. Le filtre est utilis pour crypter les
donnes collectes ensuite les stocker aprs cryptage dans le data warehouse. Cette technique
augmente le cot des donnes en termes de temps de rponse et des dlais dattente. En plus,
elle ne fait que protger contre les accs malveillants non autorises de donnes, mais nagit
pas sur l'intgrit des donnes et n'offrent pas de scurit au niveau utilisateur (problme des
droits et leurs limites).

Une approche hybride de scurit : les auteurs de [97] ont propos un Framework de scurit
amlior pour les systmes Data warehouse. Il consiste filtrer et crypter les donnes
recueillies auprs de sources. Ainsi, la filtration rduit la redondance des donnes et permet
d'liminer les donnes redondantes ce qui amliore le temps de rponse. Dun autre ct, au
niveau de lutilisateur ils ont introduit un autre filtre plusieurs point daccs du systme en
appliquant un code dauthentification pour amliorer les mcanismes du contrle daccs et
pour scuriser le systme des accs non autoriss aux donnes prives ou confidentielles.
Une architecture scurise des SD a t le centre des travaux des auteurs dans [98] qui ont
propos le dveloppement des systmes qui se basent en gnrale sur des machines de qualit
infrieure excutant des outils open sources noffrant pas des capacits de scurit suffisantes

54
pour protger des donnes critiques. Larchitecture propose sintresse lutilisation du
cryptage des donnes pour garantir la confidentialit, lapplication des techniques de signature
sur les donnes pour amliorer lintgrit et authenticit des donnes et dtecter les
modifications vicieuses de donnes. Et enfin elle assure la disponibilit par les techniques de
rplication des donnes.

2.3.4 Comparatif des travaux des attributs de sret de fonctionnement


Le tableau ci-dessous permet dlaborer un bilan des contributions traitant les aspects de
sret de fonctionnement, dans lobjectif de les comparer et les synthtiser.

Attributs de SdF Fiabilit et


Maintenabilit Scurit
Propositions disponibilit

[67- 69 ] Vue Matrialise ++ -- -

[70-72] Indexation ++ - -

[73-77] Partitionnement ++ -- -

[78] Paralllisme ++ - -

[79] Optimisation ETL ++ + -

[80] Modlisation Workflow ++ + -

[81] ETL Temps rel ++ - -

[84] SCD - ++ -

[86, 87, 88] Opration dvolution - ++ -

[89] Temporalit dinstance - ++ -

[90] Temporalit des liens dagrgation - ++ -

[91,92 ,93] gestion des versions - ++ -

[96] Filtrage et cryptage -- - ++

[97] Filtrage et redondance - + ++

[98] minimisation des cots ++ ++ ++

La plupart des travaux confronts se sont concentrs sur un aspect de sret de


fonctionnement en ngligeant son impact sur les autres aspects. Seuls les travaux dans [98]
ont propos une mthode qui permet damliorer lensemble la fois, cependant leur
approche nintervient quau niveau de limplmentation. Etape o la plupart des choix
techniques ont t dj effectus, sans la prise en compte des exigences des utilisateurs en

55
termes de sret de fonctionnement durant des phases danalyse et conception. Par
consquent, le systme final peut assurer un certain niveau de sret de fonctionnement, mais
pas forcement celui exig par ces utilisateurs. Notre objectif est de concevoir les aspects de
sret de fonctionnement en parallle avec les besoins fonctionnels et ensuite les intgrer afin
dassurer une traabilit des exigences des utilisateurs durant toutes les tapes du projet
dcisionnel.

2.4 Approches de lIngnierie des exigences des Systmes Dcisionnels

Lors de ltape danalyse des exigences, orientant la russite dun projet dcisionnel, plusieurs
problmes peuvent tre rencontrs savoir: la mauvaise collecte dinformation,
lincomprhension et lincompltude des besoins, la multitude des profils des utilisateurs et de
leurs contextes. Ces difficults peuvent influencer ngativement le processus danalyse des
besoins dcisionnels, et par consquent, les exigences collectes sont souvent vagues et non
mesurables. Ainsi lutilisation des mthodologies qui puisent leurs sources de lingnierie des
exigences savre efficace pour remdier ces difficults. Les sections suivantes prsentent
les approches les plus rfrences.

2.4.1 Approche base sur les Ontologies et notion du contexte


Dans [99], les auteurs ont propos un processus de formalisation des besoins mtier dun SD.
Lobjectif de leurs travaux est dapporter une proposition dune solution mthodologique pour
lanalyse des besoins dun SD. Il sagit doffrir une mthode efficace permettant danalyser
les besoins mtier collects afin dtablir le schma en toile. Leurs mthode propose un
guide de traitement et de formalisation des besoins mtier, collects sous forme de buts, afin
den extraire systmatiquement les faits et les dimensions. Elle consiste galement fournir
des modles dassociation entre les buts stratgiques et les buts tactiques et entre les buts
tactiques et les buts informationnels en se basant sur la notion de contextes dans les SD et en
proposant une mthodologie de conception base des ontologies.

2.4.2 La mthode Computer Aided Data Warehouse Engineering


Llment centrale des travaux dans [15] est la proposition dune dmarche intentionnelle
dIngnierie des exigences adapte aux SD. Cette mthode comporte des modles de produits
et un processus qui guide la dcouverte des exigences et la conception du SD en donnant une
considration particulire aux diffrents types de dcideurs et leurs exigences dcisionnelles
afin daboutir au SID qui rpond leurs exigences.
La mthode baptise sous le nom CADWE (Computer Aided Data Warehouse Engineering)
se base sur les diffrentes sources pour faire ressortir les exigences du SD: les buts
stratgiques de lorganisation, les objectifs stratgiques et tactiques des dcideurs, les donnes
des SI oprationnels existants ainsi quune base de composants rutilisables intentionnels et
oprationnels.

56
Le processus de la mthode CADWE propose de suivre quatre phases: (1) identifier les buts
stratgiques, (2) exprimer les objectifs, (3) dcouvrir les exigences informationnelles et (4)
dfinir le schma multidimensionnel. Pour atteindre son objectif, CADWE sest inspir des
concepts du Business Motivation Model (BMM) propos par lOMG en dfinissant quatre
boucles qui montrent un mcanisme fins/moyens. La mthode se base sur quatre mtamodles
: le mtamodle de la CARTE, le mtamodle des intentions, le mtamodle de la structure
organisationnelle et le modle linguistique dintentions.

Les livrables gnrs par chacune des boucles utilisent les quatre derniers mtamodles afin
de fournir les produits suivants : la Liste des Buts Stratgiques (LBS), les cartes des objectifs
qui se dclinent en Carte des Objectifs Stratgiques (COS) et Carte des Objectifs Tactiques
(COT), la Liste des Exigences Informationnelles (LEI) et les schmas multiDIMensionnels
(DIM).
En se basant sur plusieurs ressources, le processus prend en considration les diffrents types
dexigences, rattaches un SD et permet de gnrer ainsi lensemble des schmas
multidimensionnels qui permettent limplantation du SD le plus adapt aux exigences
recenses [46].

2.4.3 Approche base des patrons

Dans [8], lauteur a propos une mthode qui prend en compte les spcificits du SD ainsi que
celles des besoins de ces acteurs. La mthode permet danalyser laspect statique et laspect
dynamique du SD dfinis partir de structures spcifiant les besoins en le reprsentant via un
modle proche de la vision multidimensionnelle des donnes par les utilisateurs. A partir de
cette formalisation, elle permet de guider, suivant un processus automatique, le choix de
larchitecture du SD adapte un projet. Cette architecture repose sur plusieurs types de
modules dcisionnels dont certains sont multidimensionnels. Elle a propos ainsi un modle
multidimensionnel gnralis partir des propositions existantes, visant rpondre ce
manque de modle standard.
Dans un second temps, un catalogue de patrons est propos ce qui capitalise cette mthode de
dveloppement. Ce catalogue favorise la rutilisation systmatique de la mthode. Dune part,
la formalisation du contexte dun patron facilite sa recherche car les conditions dans
lesquelles il est utilisable et celles dans lesquelles il requiert un autre patron sont
formellement spcifies. Dautre part, la gestion intgre de la documentation dans sa
reprsentation contribue amliorer la fiabilit des systmes dvelopps.
Enfin, pour faciliter le dveloppement rapide de SD par rutilisation de leurs patrons, les
auteurs ont dvelopp un outil, appel eBIPAD (Electronic Business Intelligence Patterns for
Analysis and Design), de gestion de ces patrons avec des fonctionnalits dorganisation et de

57
rutilisation. Cet outil est ddi aux administrateurs des patrons et aux concepteurs
dcisionnels.

2.4.4 Approches base du modle de buts


Les auteurs de [100] collectent les exigences sous forme de buts et de dcisions. Ils
dfinissent un but comme un concept passif et la dcision comme un concept actif tel quun
processus. Ils utilisent un modle de buts propritaire GDI (goal-decisional information) pour
les reprsenter. Ils voquent des processus lis au contexte dcisionnel qui sont sous-jacents
aux stratgies pour atteindre les buts.
Alors que les travaux dans [101] proposent une mthode de conception mixte permettant la
dfinition du schma de lED. Un premier ensemble de schmas multidimensionnels est
driv partir des buts organisationnels, en adaptant lapproche Goal/Question/Metric
(GQM). GQM est une approche permettant de fournir des mtriques pour mesurer des
programmes. Cette approche a t adapte pour identifier les buts dune organisation et les
analyser afin den extraire des informations pertinentes. Les buts sont dabord collects
travers les interviews avec les utilisateurs et structurs selon un format dtaillant chaque but.
Quelques directives gnrales sont fournies afin de gnrer des schmas multidimensionnels
partir de lensemble de buts.

Un deuxime ensemble de schmas multidimensionnels (sous forme de graphes) sont drivs


automatiquement partir de schmas E/A des BD sources. Un algorithme est dfini qui
identifie les faits comme les entits ayant des attributs numriques. Ces entits reprsentent
les nuds centraux du graphe. Les dimensions sont les entits lies aux entits Fait par une
relation un un ou une relation un plusieurs. Un algorithme est fourni afin de traduire
chaque graphe en un schma en flocon de neige. Une dernire tape consiste intgrer les
deux ensembles de schmas multidimensionnels (les schmas obtenus partir des buts et les
schmas obtenus partir des sources) en un schma unifi. Ce mapping est effectu
manuellement par le concepteur et ncessite la mise en correspondance de lensemble des
schmas un rfrent terminologique unique (un dictionnaire par exemple). Les deux
ensembles de schmas sont compars un un. Les schmas sont intgrs sils possdent la
mme entit de fait.

2.4.5 Approche pour la dfinition et la gestion des SD (DWARF)


Les travaux dans [102] adaptent les techniques traditionnelles dingnierie des exigences afin
de proposer une approche mthodologique pour la dfinition et la gestion des SD. Dans cette
perspective, ils ont propos DWARF (The Data WArehouse Requirements deFinition
technique), un Framework interactif orient phase coupl dun ensemble de Templates,
procdure et techniques pour guider les dveloppeurs durant le cycle dingnierie des
exigences des SD. Ainsi DWARF est structur selon quatre phases principales :

58
1. Phase de planification de la gestion des exigences: se base sur des lignes directives dfinis
en termes de rgles du mtier, des procdures et processus pour clarifier les aspects des
exigences en termes de multidimensionnalit (granularit, sommabilit, etc.), dintgration
des sources et enfin des objectifs du projet.
2. Phase de spcification des exigences: prescrit une approche cyclique pour lacquisition, la
reprsentation et lvaluation des exigences afin de produire progressivement les
spcifications systme selon les sous processus suivants: elicitation des exigences (par des
interviews, des prototypes, en tenant en compte les NFR, etc.), analyse et ngociation des
exigences, documentation des exigences et enfin conformit des exigences.

3. Phase de validation des exigences: corrige tous les problmes de comprhension ou de


conception afin que le produit final soit conforme tous les exigences des parties prenantes
(utilisateurs, dirigeant, analystes, etc.) en termes de ses aspects fonctionnels, non-
fonctionnels et multidimensionnels. Durant cette phase lorganisation des sessions de
rvision et du prototypage ont prouv leurs efficacits dtecter, remdier et enlever les
failles du futur SD cible.

4. Phase de contrle des exigences: traite la traabilit des exigences ainsi que la gestion du
changement au niveau des exigences et au niveau de larchitecture. Dans ce sens, cette
phase propose lutilisation de la matrice de traabilit pour traiter linfluence du
changement sur les exigences existantes afin de contrler la performance de la
maintenance et prserver la scurit indispensable du SD.
Enfin nous devons souligner que cette approche a t lextension de leurs travaux prsentes
dans [103] qui sollicitent une attention particulire aux exigences non fonctionnelles
recenses pour des SD. Leur contribution propose une extension du NFR (Non Functional
Requirements) Framework et une classification dtaille des exigences non-fonctionnelles
qui doivent tre abordes dans le dveloppement du projet SD.

2.4.6 Comparatif des travaux dans le domaine des exigences des SD


Le tableau ci-dessous permet dlaborer un bilan des travaux cits auparavant, afin de
procder une tude comparative les synthtisant.
La plupart des approches dingnierie dexigence se sont penches sur les besoins
fonctionnels afin de fournir un cadre mthodologique standard pour le dveloppement des
systmes dcisionnels. Toutefois la plupart ont nglig les besoins non fonctionnels qui jouent
un rle important lors de la mise en uvre du fonctionnel. Seuls les travaux [102, 103] les ont
abords. Car ils ont explicit le traitement des besoins non fonctionnels dune manire
gnrale en les intgrant au cycle de dveloppement du projet dcisionnel. Toutefois aucun
travail na trait dune manire intgrale, la particularit des exigences de sret de
fonctionnement qui sont considres souvent comme des besoins non fonctionnels.

59
Type dexigences
Fonctionnelle Non-Fonctionnelle
Propositions

[99] Ontologie et notion de contexte ++ -

[15,46] CADWE ++ -

[8] Patrons ++ -

[100,101] Modle de but ++ -

[102, 103] DWARF ++ +

2.5 Approches Diriges par les modles dans le contexte des SD

2.5.1 Mta modlisation


Les travaux des auteurs de [104] se sont concentrs sur la formalisation du processus
d'laboration d'ED historiss (avec une dimension temporelle) depuis sa conception jusqu'
son implantation physique. Ils se sont bass sur l'Ingnierie Dirige par les Modles (IDM)
qui permet de formaliser et d'automatiser ce processus; Tout en en rduisant les cots de
dveloppement et en amliorant la qualit du logiciel. Leur contributions [104][105] se
rsument en deux points :

i. Formaliser et automatiser le processus de dveloppement d'un ED en proposant une


approche dirige par les modles qui inclut un ensemble de mtamodles (conceptuel,
logique et physique) une extension du langage OCL et un ensemble de rgles de
transformation d'un modle et de la gnration du code de cration et de chargement
de l'entrept.
ii. Formaliser et automatiser le processus de rduction de donnes historises en
proposant une approche dirige par les modles qui fournit un ensemble de
mtamodles (conceptuel, logique et physique) dcrivant les donnes rduites, un
ensemble d'oprations de rduction, et un ensemble de rgles de transformation
permettant d'implanter ces oprations au niveau physique.

Les auteurs de [106] proposent une extension de leur prcdente contribution [107], et
dfinissent un Framework de conception logique des activits ETL. Le Framework se base sur
un mtamodle dcrivant une activit ETL. Le mtamodle est conu de manire gnrique
pour capturer plusieurs types dactivits ETL. Il peut tre instanci pour reprsenter un
workflow dactivits ETL relatives un domaine prcis. Les activits ETL (transformations,
filtrage, etc.) sont formellement dcrites en utilisant un langage LDL (Logical Data
Language) qui est une variante du langage Datalog. Le code dexcution de chaque activit
est dcrit par une dclaration LDL. Les activits dfinies dune manire abstraite au niveau de

60
la couche logique, sont matrialises et excutes par des modules logiciels spcifiques dans
la couche physique. Lapproche ETL est mise en uvre par un outil ARKTOS II [49].
Enfin les auteurs de [108] ont propos une approche multicouche pour la spcification des
aspects et leurs intgration au niveau de la conception logique de larchitecture des SD. Leur
approche se base sur le paradigme orient aspect afin de produire multiples vues des aspects
transversaux composes par les aspects architecturaux. Et finalement ils ont prouv leur
proposition par une mise en uvre au niveau de la conception de larchitecture dun entrept
de donnes en reprsentant les mtadonnes sous forme de vues et daspect transversal.

2.5.2 Approches spcifiques larchitecture MDA


Les travaux prsents dans [109] proposent une approche qui vise laborer le modle
conceptuel de l'entrept en se basant sur les modles conceptuels sources et les besoins des
dcideurs. La mthode est base sur trois tapes. La premire analyse le schma
Entit/Association de la source et applique un ensemble de rgles de transformation dfini
entre le mtamodle Entit/Association et le mtamodle OLAP. La seconde phase permet de
collecter les besoins des dcideurs et de les dcrire sous forme d'un modle de buts. La
dernire tape permet la confrontation du modle des buts et du modle des sources pour
aboutir au modle multidimensionnel final.
Les auteurs des travaux [110] prsentent une approche qui vise formaliser la dtection de
faits partir de sources de donnes relationnelles. L'approche est base sur des heuristiques
issues d'un ensemble de cas rels. D'abord, les tables de la BD source sont identifies.
Ensuite, le concepteur dtermine les lments de cette BD pouvant tre considrs comme
faits. Enfin, il dfinit l'ensemble des dimensions et des mesures pour chaque fait du modle.
Les travaux prcdents utilisent le langage QVT pour formaliser la correspondance entre les
lments sources et cibles de l'ED.
D'autres approches permettent de modliser diffrents niveaux d'abstraction de l'entrept. Les
auteurs de [111] proposent une dmarche mixte pour l'laboration et l'implantation de
schmas multidimensionnels d'ED dans un cadre IDM. Cette approche dfinit les modles et
les transformations comme suit :
Au niveau du CIM, les auteurs dfinissent un CIM multidimensionnel dcrivant les
besoins dcisionnels grce un modle de buts. Ce modle dfinit les besoins trois
niveaux: besoins stratgiques , besoins dcisionnels et besoins informationnels. Une
fois les besoins informationnels dfinis, les lments du schma multidimensionnel (faits
et dimensions) peuvent tre dtermins. Afin de modliser ces besoins, les auteurs
proposent un profil UML qui permet d'adapter les lments du modle i* [112] au
domaine de l'ED. En fournissant ainsi les mcanismes pour reprsenter les diffrents
acteurs de l'ED ainsi que leurs dpendances et de lautre ct de structurer les objectifs
atteindre.

61
Au niveau du PIM, les auteurs dfinissent un PIM dit initial driv partir du CIM suite
une srie de transformation QVT. Ce PIM est par la suite confront au modle source
pour gnrer un PIM hybride multidimensionnel initial. Dans ce sens et afin de dcrire ce
modle, les auteurs proposent un profil UML multidimensionnel. Ce profil dfinit
principalement les concepts de faits et de dimensions.
Au niveau du PSM, les auteurs utilisent le CWM (Common Warehouse MetaModel)
comme mtamodle du PSM. Ils prsentent une instance du schma ROLAP qui est
gnr en appliquant un ensemble de rgles QVT, o les faits et les dimensions sont
transforms en tables.

Dans [113], les auteurs proposent une approche qui dfinit le modle conceptuel (PIM) sous
forme d'un diagramme d'activits UML tel que prsent dans [114]. A partir de ce modle,
l'objectif est de gnrer le modle logique (PSM) de manire automatique.
Ainsi au niveau du PIM, les auteurs proposent de concevoir les processus ETL comme un
ensemble d'activits dcrivant le comportement d'un processus. Un diagramme d'activits
ETL comporte en entre une table source, une liste des oprations excuter et une sortie
montrant une table cible de l'entrept. Les actions d'un diagramme reprsentent les oprations
d'agrgation, de conversion, de filtrage et de jointure. Les auteurs dfinissent les activits
suivantes: activit d'agrgation, activit de conversion, activit de filtrage, activit de jointure.
Au niveau PSM, les auteurs proposent d'utiliser la plateforme Oracle pour l'alimentation de
l'ED. L'ensemble des activits, y compris les actions d'extraction partir de la source et les
oprations de transformations, sont traduites en lments du mtamodle de cette plateforme.

Et enfin, pour mettre en uvre les transformations de modles (du PIM vers le PSM), les
auteurs prsentent le mtamodle des diagrammes d'activits UML et le mtamodle du PSM
dcrivant les concepts de la plateforme Oracle. Le diagramme d'activits dfini au niveau PIM
est transform au niveau PSM en appliquant un ensemble de rgles QVT.

Les travaux prsents dans [115] et [116] proposent une approche qui vise couvrir le cycle
de dveloppement des processus ETL et qui permet la gnration semi-automatique du code.
L'approche dfinit un modle (PIM) dans lequel les auteurs utilisent le BPMN. Ce modle est
par la suite transform pour gnrer le code.

Les auteurs se sont bass sur Le BPMN. Celui-ci est une norme de l'OMG qui permet de
modliser le droulement des processus d'une entreprise dans un Workflow. Cette norme
dcrit les processus en termes d'activits reprsentant le travail accompli par un processus.
Une activit est dcompose en tches. Lorsque les activits sont combines, elles forment un
sous-processus. Les auteurs dfinissent principalement trois types de tches dcrivant
l'extraction (l'entre qui reprsente la base de donnes et les fichiers sources), la
transformation (jointure, filtrage, etc.) et le chargement (la base de donnes en sortie). Les
tches ETL sont les suivantes : tche de drivation, tche de jointure, tche de conversion de
type, tche de filtrage, tche dagrgation.

62
Au niveau PIM, le mtamodle propos est structur en un ensemble de paquetages. Le
paquetage racine dfinit l'ensemble des processus d'alimentation de l'ED partir des sources.
Le deuxime paquetage dcrit les donnes tout au long du processus, en allant des sources
vers l'entrept. Il comporte les diffrentes tches de jointure, de filtrage, de conversion, etc.
Un vnement est dfini afin de personnaliser les exceptions leves par une tche. Les tches
qui partagent les mmes caractristiques constituent un sous-processus. Le paquetage source
dcrit l'ensemble des sources utilises pour alimenter l'ED. Les auteurs dfinissent galement
un mtamodle de vrification de la cohrence grce au langage OCL.
Au niveau du code, les auteurs proposent d'implanter les processus ETL en utilisant la
plateforme Oracle. Pour ce faire, ils dfinissent une grammaire qui dcrit les tches du niveau
PIM. Cette grammaire est par la suite utilise pour gnrer le code de manire semi-
automatique.
Enfin ct transformation, les auteurs dfinissent un ensemble de Template spcifiant des
transformations de modle vers du texte. Les rgles de correspondance sont tablies entre les
lments du mtamodle PIM et la grammaire. Chaque Template contient une partie du code
qui correspond un concept du mtamodle source.
Dans [117], les auteurs ont propos de prciser les mesures de scurit et d'audit ds les
premiers stades de la conception et de les faire respecter tout au long du cycle de vie en
sappuyant sur le cadre standard pour le dveloppement de logiciels, le Model Driven
Architecture (MDA). Leur proposition permet de dfinir des transformations formelles, entre
les modles indpendant de la plateforme (PIM) et spcifiques la plate-forme (PSM). Pour
cela ils ont dfinis deux mtamodles pour reprsenter les mesures de scurit et d'audit aux
niveaux conceptuel et logique. Ensuite, ils ont dfinis les transformations entre ces modles
pour obtenir la traabilit des rgles de scurit ds les premires tapes du dveloppement
des SD.

2.5.3 Comparatif des approches diriges par les modles dans le cas des SD
Le tableau ci-dessous permet dlaborer un bilan des contributions cites ci-dessus, afin de
procder une tude comparative les synthtisant.
La plupart des approches bases sur lIDM ont trait la conception, lautomatisation des
entrepts de donnes ou de lETL sans tenir compte des contraintes non fonctionnelles. Seuls
les travaux prsents dans [117] se sont concentrs sur llaboration dun systme dcisionnel
scuris depuis sa conception jusqu sa mise en uvre. Toutefois la scurit nest pas le seul
aspect pour garantir la sret de fonctionnement. Ainsi, nous nous sommes largement inspirs
des travaux prsents afin de proposer une approche dirige par les modles pour lingnierie
des exigences de sret de fonctionnement dans le contexte des systmes dcisionnels.

63
Approche Dirige par les
modles
Mta Modle CIM, PIM,
modlisation PSM
Propositions

[104, 105] Automatisation du ++ -


Dveloppement de l'ED + Rduction Donne

[106,107] Conception Logique des activits ++ -


de lETL

[108] Intgration des Aspects au niveau ++ -


Logique

[109] Modle conceptuel partir des sources -


des besoins des dcideurs

[110] Dtection automatise des faits - ++

[111, 112] Modlisation des diffrents - ++


niveaux des besoins

[113,114] Diagramme dactivit ETL - ++

[115, 116] workflow de lETL par BPMN - ++

[117] Scurit et audit - ++

2.6 Synthse des travaux et positionnement de notre contribution


Les travaux prsents dans ce chapitre se dclinent selon les quatre axes qui dlimitent notre
sujet de recherche savoir : les systmes dcisionnels, la sret de fonctionnement,
lingnierie des exigences et enfin lingnierie dirige par les modles.
Dans un premier temps, nous avons prsent les travaux de recherche qui traitent les systmes
dcisionnels. Ceux-ci se sont concentrs sur les principales couches des SD: les sources de
donnes, lETL et lentrept de donnes. Ainsi au niveau des sources de donnes,
lintgration reprsente la problmatique la plus traite dans la littrature. Plusieurs approches
(procdurales, dclaratives ou mixtes) ont propos de remdier cette problmatique, mais
gnralement celle-ci a t traite dans une perspective plus vaste afin de faciliter la
conception de lentrept de donnes et tenir compte des exigences des utilisateurs finaux.

Au niveau de lETL, les objectifs des travaux sont centrs sur la modlisation des flux de
donnes, lautomatisation du passage des modles conceptuels au modle logique en utilisant
le concept de lontologie, les annotations smantiques ou bien le principe du Workflow.
Enfin, la couche entrept de donnes a bnfici de la plus grande part des travaux de
recherche puisquelle est le centre de la chane dcisionnelle. Ainsi plusieurs mthodes ont

64
propos dautomatiser sa conception en se basant sur les schmas des sources de donnes,
lanalyse des besoins via le Framework i*, lontologie dcrite en langage OWL et les
annotations smantiques utilisant ces ontologies.

Les travaux de recherche cits dans la premire section du chapitre montrent que les systmes
dcisionnels nont pas encore atteint leurs maturits et quil y a beaucoup de synergies et de
contributions afin dautomatiser leurs conception et mise en uvre en tenant compte de leur
particularit. Cette particularit rside dans le caractre changeant des exigences et des
besoins de ces utilisateurs finaux et des liens de dpendance forte du systme avec les sources
ainsi que leur rle important pour la prise de dcision, or cette dernire doit prendre en
considration plusieurs paramtres (le contexte, les moyens, la stratgie, etc.) souvent
dynamiques.

La deuxime partie du chapitre dveloppe les travaux qui ont trait les aspects de sret de
fonctionnement des SD: la disponibilit, la fiabilit, la maintenabilit et la scurit.

Ainsi, concernant la disponibilit et la fiabilit des SD, les travaux de recherche se sont
intresss la rduction du temps de rponse par la proposition des mthodes et techniques
doptimisation des entrepts de donnes telles que les vues matrialises, les diffrents type
dindexation (l'index liste de valeurs, lindex de projection, lindex bitmap, lindex peu
tranch, lindex de donnes, lindex de jointure, et l'index toile de jointure) le
partitionnement des donnes (horizontal, vertical, mixte et gntique), et le traitement
parallle qui permet de partager les donnes entre un ensemble de processeurs. Au niveau de
lETL, les travaux ont surtout dvelopp les techniques du temps rel et quasi rel pour
amliorer sa disponibilit et fiabilit.
Quant la maintenabilit, deux grandes familles ont vis lamlioration de la maintenabilit
des entrepts de donnes: (i) les techniques de la mise jour du modle qui permettent de
grer la maintenance des dimensions changeantes par la technique SCD (Slowly Changing
Dimensions), ou par les oprateurs dvolution qui se basent sur toute une algbre afin
dassurer une volution des instances des dimensions, voir une volution structurelle des
dimensions telle que lajout dun niveau de granularit ; (ii) maintenance par modlisation
temporelle qui impose une traabilit des volutions subies par le modle en lenrichissant par
des extensions temporelles afin de grer les instances, les liens dagrgation et le versioning
qui rpond aux analyses de type What-if Analysis.

Enfin, le critre de la scurit est souvent critique pour les systmes dcisionnels vu quils
consolident les donnes et les informations cruciales orientes pour la prise de dcision. Ainsi
la scurit est un axe important de recherche, et beaucoup de travaux se sont intresss
combler cette faille par proposer des techniques de filtrage des donnes recueillis auprs des
sources et de les crypter en plus de lintroduction dautres filtres supplmentaires plusieurs
point daccs du systme en appliquant un code dauthentification. Ces techniques ont pour

65
objectif damliorer les mcanismes du contrle daccs et de scuriser le systme des accs
non autoriss aux donnes prives ou confidentielles. Dautres travaux se sont intresss aussi
aux techniques de signature pour amliorer lintgrit et lauthenticit des donnes et dtecter
les modifications vicieuses. Et enfin assure la disponibilit par la technique de rplication des
donnes.

L'tude des approches existantes montre que les aspects de SdF ont t largement traits et
plusieurs mthodes et techniques ont merg pour amliorer chacun des attributs. Toutefois,
cette tude nous a permis de soulever les trois remarques suivantes:
i. Les tudes ont trait sparment les impacts individuels de chacun des aspects, sans
penser rvler linteraction entre eux, ni trouver leurs combinaisons optimales.
ii. Les aspects de sret de fonctionnement sont considrs comme des besoins
secondaires, puisquils ne sont voqus qu ltape dimplmentation du systme ce
qui rend difficile leur mise en uvre.
iii. La traabilit des attributs de la SdF depuis lexpression des besoins jusqu
limplmentation physique du systme est complexe car le dveloppement de ces
attributs nest pas suivi lors des phases du projet.

Daprs ces dernires remarques nous nous sommes penchs, la troisime partie de ce
chapitre, sur ltude les travaux qui ont trait les exigences des systmes dcisionnels afin de
trouver une mthodologie ou une approche qui permet de remdier aux problmatiques de la
SdF souleves.
Ainsi, les plupart des travaux autour des exigences des SD ont essay de proposer des
mthodologies globales afin de guider les concepteurs et les dveloppeurs lors de la mise en
place du projet dcisionnels. Leur objectif commun est de formaliser le processus pour livrer
un SD cibl qui rpond au maximum aux exigences de ces utilisateurs finaux. Ainsi pour
atteindre cet objectif, des travaux ont exploit le concept bien connu des ontologies et du
contexte pour concevoir un guide qui facilite la formalisation et le traitement des besoins
mtiers sous forme de but et dassocier les buts stratgiques, les buts tactiques et les buts
informationnels. Dun autre ct, la mthode CADWE sintresse lextraction de lensemble
des exigences de diffrentes sources suivant des processus qui permettent la fin de gnrer
les schmas multidimensionnels. Cette mthode dfinit des tapes suivre pour livrer un
systme qui respecte toutes les exigences extraites. Dautres travaux ont propos un modle
standard pour guider lautomatisation du choix architectural adapt au SD, ensuite ils ont
fourni un catalogue de patrons qui capitalise leur mthode de dveloppement et qui favorise
sa rutilisation systmatique. Dautres travaux ont utilis les modles pour collecter les
exigences sous formes de buts en adoptant diffrentes approches, telles que : GDI (goal
decisional information) et le GQM (Goal Question Metric) afin didentifier, de dfinir,
dextraire et danalyser les buts dune organisation et ses informations utiles au projet du SD.

66
Cependant, il est ncessaire de signaler que toutes les mthodes et techniques cites jusqu
maintenant concernant la sret de fonctionnement, se sont focalises sur le traitement des
exigences fonctionnelles-mtiers du SD en mettant en arrire-plan les exigences non
fonctionnelles y compris celles de SdF. Les causes rsident souvent dans la considration de
ce type dexigences comme des besoins techniques, et ne sont voqus ainsi qu la phase
dimplmentation du systme. A notre connaissance seule la mthode DWARF leur a
consacr une attention particulire. Cette mthode repose sur lutilisation dun Framework
interactif oriente phase coupl dun ensemble de Templates, procdures et techniques pour
guider les dveloppeurs durant le cycle dingnierie des exigences des SD. Durant ses
principales tapes DWARF a labor des catalogues propres aux exigences non
fonctionnelles dans le contexte des SD en se basant sur le NFR Framework. Ainsi, leurs
travaux nous ont t une base solide de commencement pour traiter les aspects de SdF des SD
et nous ont ainsi largement inspir durant les dbuts de nos travaux de recherche. Cest pour
cela que nous allons aborder quelques un de leurs aspects techniques durant le troisime
chapitre de ce mmoire.

Enfin la dernire partie de ce chapitre est consacre aux travaux qui se sont intresss
lingnierie dirige par les modles dans le contexte des systmes dcisionnels. Lobjectif
centrale de leurs contributions est daligner le dveloppement des SD lIDM et de formaliser
ainsi ce processus en se basant sur des standards. Nous avons dclin les approches selon
deux grandes familles: celles qui se basent sur lutilisation de la mta-modlisation et celles
spcifiques au standard MDA.

Ainsi, la premire famille de travaux sest intresse la formalisation et lautomatisation du


processus d'laboration d'ED en proposant un ensemble de mtamodles (conceptuel, logique
et physique), une extension du langage OCL, et un ensemble de transformations. Ces travaux
ont surtout attaqu la problmatique dlaboration des mtadonnes, et ils ont propos ainsi
un mtamodle dintgration pour la gestion des mtadonnes dans un ED en se basant sur le
diagramme de classe dUML ou en utilisant des vues multicouches comme des aspects
transversales. Toutefois lED nest pas la seule couche concerne par la mta-modlisation,
car les travaux ont permis de dfinir un Framework de conception logique des activits ETL
se basant sur un mtamodle conu pour capturer plusieurs types dactivits ETL et qui peut
tre instanci pour reprsenter un Workflow dactivits.

Dun autre ct, les travaux qui se sont intress la MDA ont surtout trait la couche ED en
partant des modles conceptuels sources et des besoins des dcideurs ou par la dtection de
faits partir de sources de donnes relationnelles. Lapproche centrale dans cette famille est
celle propos dans [111] qui consiste en une dmarche mixte pour l'laboration des modles
PIM et PSM ainsi que les transformations pour lensemble des couches du SD. Dautres
travaux ont propos une manire automatique pour gnrer le PSM partir du PIM alors que

67
dautres ont vis couvrir le cycle de dveloppement des processus ETL et faciliter la
gnration semi-automatique du code en se basant sur le BPMN.
Par lanalyse de ces travaux nous redmontrons encore que les exigences non fonctionnelles
ont t souvent ngliges car la plupart des travaux se concentrent sur le fonctionnement du
SD alors les expriences montrent que capturer des exigences non fonctionnelles sans les
intgrer au modle conceptuel peut conduire un systme dfaillant. A notre connaissance,
seul les travaux prsents dans [117] se sont intresss laspect de la scurit en proposant
de prciser les mesures de scurit et d'audit ds les premiers stades de la conception et de les
faire respecter tout au long du cycle de vie en sappuyant sur le standard MDA, ce qui leur a
permis de dfinir des transformations entre modles base du langage QVT.
En se basant sur ltat de lart prcdant, nous avons pu dmontrer que dans le contexte du
DW, les attributs de la SdF ont t trait dune manire individuelle sans tenir compte de leur
intgration. La seule mthodologie dingnierie des exigences qui les a abords ne les a pas
pris en charge depuis les dbuts de cycle de vie. En plus, malgr lintrt de lIDM pour les
SD, le seul aspect qui a t dvelopp jusqu aujourdhui est la scurit.

Dans ce contexte, notre contribution sinscrit dans lobjectif de fournir une approche
dingnierie des exigences qui permet de tenir compte des aspects de la sret de
fonctionnement ainsi que leurs interactions depuis les premires tapes du projet dcisionnel
en utilisant le standard MDA.

68
Chapitre 3 : Thorie de lApproche
Propose

C'est la thorie qui dcide de ce que nous pouvons observer.


Albert Einstein

69
3.1 Introduction
Lobjectif de ce chapitre est de dtailler thoriquement notre contribution qui vise intgrer
les aspects de SdF aux SD selon une approche dirige par les modles. Ainsi, nous allons
prsenter les notions de base de notre contribution avant de la dtailler. Dans ce sens, nous
allons prsenter lapproche MDA ainsi que son intrt et son rle. Ensuite nous allons dfinir
les mtamodles utiliss pour la concrtiser chaque tape ainsi que les outils de
transformations permettant de transiter dun niveau dabstraction un autre. Enfin, nous
terminerons le chapitre par la prsentation de la modlisation oriente aspect qui constitue
lune des bases de notre proposition.

3.2 Les Modles de lapproche MDA


La MDA est standard de lOMG qui ne dfinit pas une architecture middleware nouvelle,
mais qui offre une reprsentation de l'architecture abstraite et indpendante de la plate-forme
technique. De lautre ct, elle assure et maintient le lien avec une multitude de services
mtiers. La figure 8, prsente une description du mtamodle du MDA [118].

Figure 8: Description du mta modle du MDA[118]

Les modles CIM, PIM, PSM, reprsentent respectivement le modle des exigences, le
modle indpendant de la plate-forme et le modle spcifique la plate-forme technique. Le
PIM, le PSM et les techniques de mappage sont bass sur des mtamodle reprsent de
prfrence avec les standards dfinis par l'OMG [39] (UML : Unified Modeling Language,
MOF : MetaModel Object Facilities, CWM : Commun Warehouse MetaModel, et XMI :
XML Metadata Interchange).

L'objectif du MDA est la cration d'une reprsentation UML de la logique mtier en vue de
lassocier des caractristiques techniques ensuite. Des outils devraient permettre de gnrer
des composants en fonction de l'architecture choisie (EJB : Enterprise JavaBean, CORBA,

70
Dot NET ou Services Web). Un travail de finalisation sera ncessaire pour affiner le modle
obtenu en fonction des objectifs attendus [119].
La migration d'une application d'une infrastructure une autre consiste ainsi solliciter du
MDA, de la logique mtier et une gnration du modle spcifique la nouvelle infrastructure
cible. L'automatisation de la gnration devra permettre de rduire la dure et les cots de
migration. De plus, un diteur pourra envisager plus facilement d'diter un logiciel pour les
plates-formes techniques supportes par le MDA [34].

Figure 9: Processus de dveloppement selon lapproche MDA

La figure 9 donne une vue gnrale de lapproche MDA. Nous constatons que son processus
de dveloppement commence par llaboration dun ou de plusieurs modles dexigences
(CIM). Elle se poursuit par llaboration des modles danalyse et de conception abstraite de
lapplication (PIM). Ceux-ci doivent en thorie tre partiellement gnrs partir des CIM
afin que des liens de traabilit soient tablis.
Pour raliser concrtement lapplication, il faut ensuite construire des modles spcifiques
aux plates-formes dexcution. Ces modles sont obtenus par une transformation des PIM en
y ajoutant les informations techniques relatives aux plates-formes. Les PSM nont pas pour
vocation dtre prennes. Leur principale fonction est de faciliter la gnration de code. Cette
activit (cest dire La gnration de code partir des modles PSM ) nest dailleurs pas

71
rellement considre par MDA. Celle-ci sapparente plutt une traduction des PSM dans
un formalisme textuel.

3.2.1 Modle Indpendant de la plateforme: CIM (Computation Independent


Model)
La premire tape lors de la construction dune nouvelle application est de spcifier les
exigences du client. Bien que trs en amont, cette tape doit fortement bnficier des modles.
Lobjectif est de crer un modle dexigences de la future application. Un tel modle doit
reprsenter lapplication dans son environnement afin de dfinir quels sont les services offerts
par lapplication et quelles sont les autres entits avec lesquelles elle interagit.
La cration dun modle dexigences est dune importance capitale. Cela permet dexprimer
clairement les liens de traabilit avec les modles qui seront construits dans les autres phases
du cycle de dveloppement de lapplication. Un lien durable est ainsi cr entre les besoins du
client et les diffrents modles danalyse et de conception.
Les modles dexigences peuvent tre considrs comme tant des lments contractuels,
destins servir de rfrence lorsquon voudra sassurer quune application est conforme aux
demandes du client. Ainsi, Il est important de noter quun modle dexigences ne contient pas
dinformation sur la ralisation de lapplication ni sur les traitements. Cest pourquoi, dans le
vocabulaire MDA, les modles dexigences sont appels des CIM (Computation Independent
Model), littralement modle indpendant de la programmation . Avec UML, un modle
dexigences peut se rsumer un diagramme de cas dutilisation. Ces derniers contiennent en
effet les fonctionnalits fournies par lapplication (cas dutilisation) ainsi que les diffrentes
entits qui interagissent avec elle (acteurs) sans apporter dinformation sur le fonctionnement
de lapplication.

Dans une optique plus large, un modle dexigences est considr comme une entit
complexe, constitue entre autres dun glossaire, de dfinitions des processus mtier, des
exigences et des cas dutilisation ainsi que dune vue systmique de lapplication. Si la MDA
nmet aucune prconisation quant llaboration des modles dexigences, des travaux sont
en cours pour ajouter UML les concepts ncessaires pour couvrir cette phase. Ainsi, le rle
des modles dexigences dans une approche MDA est de fournir les premiers modles
prennes[118].

3.2.2 Modle danalyse et de conception abstraite : PIM (Platform Independent


Model)
Une fois le modle dexigences ralis, le travail danalyse et de conception peut commencer.
Dans lapproche MDA, cette phase utilise elle aussi un modle. Lanalyse et la conception
sont depuis plus de trente ans les tapes o la modlisation est la plus prsente, dabord avec
les mthodes Merise et Coad/Yourdon puis avec les mthodes objet Schlear et Mellor, OMT,

72
OOSE et Booch. Ces mthodes proposent leurs propres modles. Aujourdhui, le langage
UML sest impos comme la rfrence pour raliser tous les modles danalyse et de
conception.

Cette tape consiste structurer lapplication en modules et sous-modules. Lapplication des


patrons de conception, ou Design Patterns, du GoF (Gang of Four) fait partie de cette tape de
conception. Par contre, lapplication de patrons techniques, propres certaines plates-formes,
correspond une autre tape. Nous ne considrons donc ici que la conception abstraite, cest-
-dire celle qui est ralisable sans aucune connaissance des techniques dimplmentation.
La MDA considre que les modles danalyse et de conception doivent tre indpendants de
toute plate-forme dimplmentation, quelle soit J2EE, .Net, PHP, etc. En nintgrant les
dtails dimplmentation que trs tard dans le cycle de dveloppement, ce qui permet ainsi de
maximiser la sparation des proccupations entre la logique de lapplication et les techniques
dimplmentation.

Prcisons que la MDA ne fait que prconiser lutilisation dUML et quelle nexclut pas
lutilisation des autres langages. De plus, MDA ne donne aucune indication quant au nombre
de modles laborer ni la mthode utiliser pour laborer ces PIM. Quels que soient le
langage utilis, le rle des modles danalyse et de conception est dtre prennes et de faire
le lien entre le modle dexigences et le code de lapplication.
Ces modles doivent par ailleurs tre productifs puisquils constituent le socle de tout le
processus de gnration de code dfini par MDA. La productivit des PIM signifie quils
doivent tre suffisamment prcis et contenir suffisamment dinformation pour quune
gnration automatique de code soit envisageable [118].

3.2.3 Modle du code ou de la conception concrte : PSM (Platform Specific


Model)
Une fois les modles danalyse et de conception raliss, le travail de gnration de code peut
commencer. Cette phase, la plus dlicate du MDA, doit aussi utiliser des modles. Elle inclut
lapplication des patrons de conception techniques. La MDA considre que le code dune
application peut tre facilement obtenu partir des modles de code. La diffrence principale
entre un modle de code et un modle danalyse ou de conception rside dans le fait que le
modle de code est li une plate-forme dexcution. Dans le vocabulaire MDA, ces modles
de code sont appels des PSM (Platform Specific Model).

Les modles de code servent essentiellement faciliter la gnration de code partir dun
modle danalyse et de conception. Ils contiennent toutes les informations ncessaires
lexploitation dune plate-forme dexcution, comme les informations permettant de
manipuler les systmes de fichiers ou les systmes dauthentification.

73
Il est parfois difficile de diffrencier le code des applications des modles de code. Pour
MDA, le code dune application se rsume une suite de lignes textuelles, comme un fichier
Java, alors quun modle de code est plutt une reprsentation structure incluant, par
exemple, les concepts de boucle, condition, instruction, composant, vnement, etc. La
gnration de code partir dun modle de code est donc une opration assez triviale.

Pour laborer des modles de code, MDA propose, entre autres, lutilisation de profils UML.
Un profil UML est une adaptation du langage UML un domaine particulier. Par exemple, le
profil UML pour EJB est une adaptation dUML au domaine des EJB. Grce ce profil, il est
possible dlaborer des modles de code pour le dveloppement dEJB selon [118].

3.2.4 Transformation
Nous venons de passer en revue les trois types de modles les plus importants pour MDA qui
sont les CIM, PIM et PSM. Nous avons aussi vu quil tait important de bien tablir les liens
de traabilit entre ces modles. En fait, MDA tablit ces liens automatiquement grce
lexcution de transformations des modles.

Les transformations de modles prconises par MDA sont essentiellement les


transformations CIM vers PIM et PIM vers PSM. La gnration de code partir des PSM
nest quant elle pas considre comme une transformation de modle part entire. La
MDA envisage aussi les transformations inverses : du code vers PSM, du PSM vers PIM et
enfin du PIM vers CIM [38].
Toutefois il est signaler que les transformations de modles sont trs importantes dans la
MDA. Car, ce sont elles qui portent lintelligence du processus mthodologique de
construction dapplication. Elles sont stratgiques et font partie du savoir-faire de lentreprise
ou de lorganisation qui les excute, car elles dtiennent les rgles de qualit de
dveloppement dapplications. Conscient de cela, MDA prconise de modliser les
transformations de modles elles-mmes.

3.3 Prsentation de la mthode propose

3.3.1 Dtails du mcanisme de lapproche propose


Notre proposition a pour objectif de fournir une dmarche de conception des SD, en tenant
compte des contraintes de SdF, ds les premires phases de modlisation. Vu que ces
dernires varient selon le domaine dutilisation du SD, nous proposons une approche
gnrique aligne au standard MDA permettant de les intgrer dune manire raffine et
incrmentale. Et bien sr selon les diffrents niveaux dabstraction pour sassurer de leur
traabilit, et de vrifier leur intgrit tout en tenant compte de leurs interaction. La figure ci-
dessous reprsente explicitement larchitecture de notre contribution.

74
Figure 10: Dmarche de lApproche Propose

Notre dmarche englobe lensemble du projet dcisionnel. Toutefois, le SDW tant lui-mme
un systme htrogne, cause des plateformes qui le composent (DS, ETL, DW, outils
danalyse nous avons donc adapt la stratgie Diviser pour conqurir . Elle consiste dune
part traiter chaque couche en prservant ses propres caractristiques, et dautre part de traiter
ses exigences de SdF en tenant compte des couches environnantes.

Ainsi, nous proposons de partitionner larchitecture standard des SDW selon 4 couches: les
DS, lETL, le DW et les outils danalyse. Ensuite, nous prconisons de mener une tude
qualitative pour lister lensemble des exigences influenant les aspects de SdF pour chaque
couche afin de les modliser dune part. Ensuite, nous proposons de les intgrer et traiter leurs
interactions en respectant les niveaux dabstraction du standard MDA [120]. Pour mettre en
uvre notre approche nous avons suivi les tapes dtailles de la figure 11 :

75
Figure 11: Mthodologie de l'Approche

3.3.2 Niveau des Exigences


Cette partie est consacre ltude qualitative de chacun des aspects de la SdF dans les quatre
couches du SD. Nous avons donc isol chacune de ces couches. Ensuite, nous nous sommes
appuys sur le fait que la disponibilit et la fiabilit sont trs rapproches (cf. chapitre 1 et 2),
et elles seront donc regroupes dans la suite de notre approche. Nous proposerons dans ce qui
suit, dnumrer de manire exhaustive lensemble des exigences qui influencent la SdF
positivement ou ngativement.

3.3.3 Niveau Indpendant de la Programmation


La cration des modles CIM ce niveau permet dexprimer clairement les exigences de SdF
afin dassurer une traabilit avec les modles qui seront construits dans les autres phases du
cycle de dveloppement du SD.

76
Pour ce faire nous avons choisis dutiliser le NFR (Non Functional Requirement ) Framework
[121] qui fournit un profil UML appel le profil SoftGoal. Ce Framework est jug le plus
adquat selon [122] pour modliser les exigences de SdF ainsi que leur interaction.

3.3.3.1 Prsentation et intrt du NFR Framework


Lide principale du NFR Framework se concentre sur la modlisation et lanalyse des
exigences non-fonctionnelles, afin quelles soient prises en considration par lanalyste avant
mme les exigences fonctionnelles. La mthode consiste systmatiquement modliser et
raffiner les NFRs et tudier les interdpendances (les influences, les priorits). Pour cela, le
NFR Framework se base sur les softgoals qui sont diviss en trois types [123]:

les softgoals NFR: reprsentent les NFRs prendre en considration.


les softgoals doprationnalisation: modlisent les techniques permettant de satisfaire
les softgoals NFR.
les claims softgoals : permettent lanalyste de justifier ses choix pour le raffinement
de softgoals, les priorits entre softgoals, etc.

Les softgoals peuvent tre raffins en utilisant le raffinement ET/OU. Les interdpendances
entre les softgoals peuvent gnralement tre captures avec des contributions positives (+) ou
ngatives (-). Tous ces concepts sont reprsents graphiquement grce au graphe
dinterdpendance des softgoals SIG (Softgoal Interdependency Graph). Le NFR Framework
offre une dmarche qui sappuie sur les activits suivantes [124] :
la capture des softgoals NFR.
le raffinement des softgoals NFR.
lidentification des softgoals doprationnalisation pour satisfaire les softgoals
NFR.
ltude des ambiguts, des compromis, des priorits et des interdpendances entre
les NFRs.
lanalyse des diffrentes alternatives doprationnalisation pour dterminer leur
impact sur les NFRs de haut niveau. Lanalyste slectionne enfin lalternative qui
rpond le mieux aux NFRs de haut niveau.
Lensemble des softgoals doprationnalisation pour lalternative slectionne
peut tre alors implment dans le futur logiciel.

3.3.3.2 Mcanismes du NFR Framework


Afin de faciliter la tche de lanalyste tout au long de cette dmarche, le NFR Framework
fournit un ensemble de catalogues stockant les connaissances de conception. Ces catalogues
sont de trois types [125] :
Les catalogues des types NFR qui incluent des concepts sur des types particuliers des NFR,
tels que la performance, la scurit, etc.

77
Les catalogues des mthodes qui encodent les connaissances aidant dans le raffinement des
softgoals et dans loprationnalisation.
Les catalogues des rgles de corrlation qui stockent les connaissances aidant dtecter les
interdpendances implicites entre les softgoals. Par exemple, le catalogue permet dinclure le
fait que lindexation contribue positivement au temps de rponse.

En se basant sur ces catalogues nous proposons dlaborer les CIM de chacun des attributs de
SdF qui seront traits autant que SoftGoal. Pour les dcomposer, les affiner et traiter leur
interaction. Le schma de la figure 12 reprsente un exemple de lutilisation du NFR
Framework labor par shung et al. dans [126].

Figure 12: Exemple dun SIG

La nomenclature utilise pour reprsenter un SIG est la suivante :

Les nuages lgers dans un SIG indiquent un softgoal. Ce dernier a la nomenclature


suivante: Type [Rubrique1, Rubrique2, ..., Rubriquen], o Type est un aspect non-
fonctionnel (par exemple la scurit), et la rubrique est un sujet du systme cible auquel
est associ le softgoal (par exemple comptes bancaires). Les rubriques peuvent encore
tre dcomposes en attributs, reprsents par le symbole . suite la description du
sujet (ex. compte.balance).

Les nuages sombres indiquent un softgoal de conception, savoir : (i) une technique de
conception, (ii) une opration, (iii) une contrainte, (iv) autre composant architectural.

Les lignes entre les nuages sombres et lgers indiquent le degr avec lequel le softgoal
de conception (correspondant au nuage sombre) satisfait le NFR (reprsent par le

78
nuage lger). La satisfaction peut se prsenter selon quatre niveaux: fortement positive
(++), positive (+), ngatif (-), fortement ngative (--).

Les criticits dun softgoal sont reprsentes par le symbole "!".

Un arc simple reprsente la relation logique AND entre diffrents softgoals provenant
d'un softgoal. Par contre, un arc double signifie une relation logique OR entre les sous-
softgoals.

Enfin, une procdure interactive dtiquetage est utilise pour tiqueter les nuages des
softgoals NFR base sur le degr de satisfaction et de leurs criticits. Ainsi le symbole
V reprsente une contribution positive de ce softgoal dans le SIG alors que le symbole
X reprsente une contribution ngative.

3.3.4 Niveau Indpendant de la Plateforme


Dans cette partie, nous proposons dlaborer les modles indpendants de la plateforme
(PIM). Ainsi, ce stade le NFR Framework nest plus appropri car nous devons avoir des
modles dun autre niveau dabstraction. Dans ce sens, nous proposons dutiliser le profil
QoS-FT (Quality of Service Fault tolerance) [127]. Il permet la modlisation des aspects de
la qualit de service et de la tolrance aux fautes des systmes, pour des fins d'analyse et de
conception.

Ce profil se base sur la construction de modles pouvant tre employs pour faire des
prvisions quantitatives concernant les caractristiques de QoS. Ces modles facilitent
galement la communication entre les dveloppeurs d'une faon standardise. Ils permettent
aussi l'interoprabilit entre les divers outils danalyse et de conception [128].

3.3.4.1 Profil QoS-FT


Pour assurer la consistance lors de la modlisation des diverses qualits de service, le profil
QOS-FT permet de dfinir un cadre standard ou un modle de rfrence dans le contexte
UML qui inclut [127]:

La catgorisation gnrale des diffrents genres de QoS y compris les spcifications de


QoS dfinies lors de la conception. Cette catgorisation distingue plusieurs
caractristiques :
Caractristiques relatives au temps (dlai, fracheur).

Caractristiques en rapport avec limportance (priorit, prcdence).


Caractristiques en rapport avec la capacit (dbit, capacit).

Caractristiques en rapport avec lintgrit (exactitude).


Caractristiques en rapport avec la scurit.

79
Caractristiques de disponibilit et de fiabilit.

Lidentification des lments conceptuels de base impliqus dans la QoS et leurs


rapports mutuels. Ceci implique la capacit d'associer des caractristiques de la QoS
aux lments du modle (spcification). Un modle gnrique pour
l'approvisionnement de la QoS (modle de contrle) est associer aux cas d'utilisation
(modle d'utilisation).
Une catgorisation gnrale des diffrents types de fautes.

Une identification des lments conceptuels de base impliqus dans la tolrance aux
fautes et leurs rapports mutuels. Ceci implique (i) la capacit d'associer des
caractristiques de tolrance aux fautes aux lments du modle (spcification), (ii) un
modle gnrique des intervenants dans des activits relatives aux tolrances aux
fautes et des cas d'utilisation (modle d'utilisation), et (iii) un modle gnrique
reprsentant la faon dont les mcanismes de tolrance aux fautes sont grs (modle
de contrle).

3.3.5 Transformations du CIM au PIM


Selon les travaux cits dans [38], trois approches de transformation de modles sont
reconnues :

Approche par programmation: base sur les langages de programmation en gnral


orients objet pour dcrire les transformations.
Approche par Template : base sur des canevas pour les modles cibles. La
transformation consiste remplacer les paramtres du canevas cibles par les valeurs
du modle source.
Approche par modlisation : qui permet de modliser les transformations pour les
rendre plus productifs. Le standard MOF 2.0 QVT(Query / Views / Transformation) a
t propos par lOMG [129] pour dfinir le mta modle des transformations. Dans
cette approche les transformations se font selon des rgles qui dcrivent la
correspondance entre les entits du modle source et destination. Cette transformation
est prise en charge par plusieurs langages de transformation dont lATL (Atlas
Transformation Language) [130]. Nous avons choisis ce langage pour dfinir nos
transformations.

3.3.5.1 Atlas Transformation Langage (ATL)


ATL a t conu pour raliser des transformations dun ou plusieurs modles sources vers un
ou plusieurs modles cibles dans le cadre de lapproche MDA. ATL est un langage hybride
car il permet lexpression des rgles de transformations dclaratives et impratives la fois
[131]. Sa syntaxe abstraite a t dfinie par un modle MOF [37] prsent dans la figure 13. Il
possde galement une syntaxe textuelle concrte.

80
Figure 13: Syntaxe abstraite des rgles de transformation extraite du Mtamodel ATL[131]

3.3.5.2 Mcanisme de lATL


Une transformation ATL permet de transformer un modle source en modle cible en se
basant sur les lments dfinis dans les mtamodles impliqus (voir figure 14). Elle est
dcrite par un ensemble de rgles de transformation. ATL permet de naviguer dans les
modles en utilisant des requtes sous forme dexpression OCL (Object Constraint Language)
[132]. Les rgles de transformation sont appliques en cherchant dans le modle source les
lments qui respectent leur pattern source pour les transformer en des lments du modle
cible.

MOF

Source ATL Target


MetaModel MetaModel

SourceM2TargetM.atl
Source Model Target Model

Figure 14: Mcanisme des transformations ATL

3.3.6 Niveau Spcifique la Plateforme


A ce niveau les dtails de limplmentation technique doivent tre inclus pour laborer les
PSM. Cependant, nous avons vu dans le premier chapitre que les SD sont constitus de
couches htrognes : DS, ETL, DW, et outils de restitutions. Cette htrognit rend
complexe la ralisation du PSM des aspects de la SdF pour tout le systme. Ce qui impose
une ralisation de plusieurs PSM pour chacune des couches, comme le montre la figure 15.
Il faut souligner que ces modles doivent tre incorpors aux modles reprsentant les
exigences fonctionnelles. Do lintrt de la modlisation oriente aspect qui offre des
mcanismes de tissage de ces aspects transverses aux fonctionnalits du systme au niveau
modle.

81
Figure 15: Elaboration des PSM pour chaque couche

3.3.6.1 Modlisation Oriente Aspect


L'approche AOM (Aspect Oriented Modeling) est dfinit dans les travaux [133], [134]. Elle
reprend les principes dfinis par AspectJ [135] (langage de programmation orient aspect)
afin de proposer un moyen de modliser et de mieux apprhender les programmes orients
aspects. L'approche AOM repose directement sur les concepts d'AspectJ [129], il y a donc une
distinction entre les aspects et la base qui sont vus comme des modles. Alors la dfinition
dun aspect comporte deux entits : le modle de la proccupation transverse (Advice), et des
patrons de modle permettant de capturer les points dapplication de laspect (point de
coupure Pointcuts). Quant la gnration du modle global (exprimant lensemble des
proccupations), elle repose sur la composition du modle de base avec le modle daspect.
Cette composition (gnralement appele tissage daspect) met en uvre deux oprations : la
dtection des point de jonctions o laspect doit tre appliqu, et le remplacement des
fragments identifis par la nouvelle structure dfinie dans ladvice.

3.3.6.2 Intrt et mcanismes de lOrient Aspect:


Notre approche repose sur la sparation des proccupations fonctionnels et des aspects SdF.
Toutefois, lintgration de ces deux lments au niveau du code rend la mise en uvre du
systme dlicate et sa maintenance difficile.
Pour pallier ce problme, nous proposons dutiliser la technique oriente aspect pour tisser les
aspects de SdF sur le modle fonctionnel. Ainsi, nous proposons dlaborer les PSM des

82
aspects de SdF et ensuite les tisser avec les PSM fonctionnels afin davoir un PSM complet
qui peut tre instinctivement transform en code. La figure 16 explique ces propos.

Figure 16: tissages des aspects de SdF

Le processus de tissage se fait la phase de conception, ce qui offre plus de flexibilit et


indpendance vis vis du langage de programmation. Donnant ainsi plus de libert dans le
choix du langage dimplmentation.

Dun autre ct parmi les avantages du dveloppement orient aspect, la qualit du code est
amlior. Il est ainsi plus facile de comprendre les aspects et les modules de base et de
changer des proccupations. De plus, le couplage entre les modules grant des aspects
techniques peut tre rduit de faon importante, et chaque module est maintenue
indpendamment des autres ce qui offre une meilleure rutilisation : tout module peut tre
rutilis sans se proccuper de son environnement, chaque module implmente une
fonctionnalit prcise, des nouvelles fonctionnalits pourront tre implmentes dans de
nouveaux modules qui interagissent avec le systme travers des aspects.

3.4 Synthse
Ce chapitre permet de prsenter une vue panoramique sur lensemble des tapes de notre
approche pour traiter les exigences de SdF des systmes dcisionnels. Dans un premier lieu,
nous avons prsent lapproche MDA qui constitue la base de nos travaux. Le choix de ce
standard a man du besoin dun cadre mthodologique standardis et formel pour y inscrire

83
notre approche. Ce besoin a t le fruit de ltude de ltat de lart (cf chapitre 2) qui a soulev
la problmatique de labsence des mthodes qui permettent la prise en compte des exigences
de SdF ds les premires tapes du projet du SD.

La MDA est une des propositions de lOMG pour concrtiser le concept de lIDM. Ce
concept est une tentative pour dpasser les limitations de lapproche oriente objet dun ct
et celui de CORBA dun autre ct en proposant une remont en abstraction et une
concentration sur les modles comme unit productifs au lieu de leurs fonction contemplative
ou expressive. La MDA concrtise les concepts de lIDM en prconisant lutilisation des
modles CIM, PIM et PSM et en facilitant le passage dun niveau dabstraction un niveau
infrieur par lutilisation des transformations de modles.

En salignant au cadre mthodologique offert par la MDA, notre mthode propose chaque
niveau dabstraction lutilisation du mtamodle le plus adquat pour modliser les exigences
de SdF des SD et tenir compte de leurs particularits. Ainsi au niveau des exigences, nous
proposons lutilisation du profil SIG pour exprimer des modles CIM. En effet, le NFR
Framework a prouv son efficacit modliser les premires exigences non fonctionnelles -
qui incluent ceux de SdF- et les raffiner tout en permettant le traitement de leurs interactions
et conflits ventuelles. Au niveau suivant, nous proposons dutiliser le profil QoS-FT afin de
modliser les PSM. Ce dernier est un standard de lOMG pour modliser les exigences et les
proprits en termes de qualit de service et de la tolrance aux fautes qui est lune des
moyens pour assurer la SdF (Voir 3me section du 1er chapitre). Enfin, au niveau de la
conception concrte qui est le niveau le plus proche du code, nous avons opt pour
lutilisation des diagrammes de Composant de Dploiement dUML, ce qui nous a permis de
constituer des modles de bas niveau afin de pouvoir concrtiser notre approche.

Le chapitre suivant dtaille davantage la mise en uvre de ces mtamodles pour raliser les
modles de chaque tape, et enfin termine par une tude de cas qui prouve la faisabilit ainsi
que le bnfice de notre approche

84
Chapitre 4 : Mise en uvre

Mettez toutes les leons des jeunes gens en action plutt qu'en discours.
Jean-Jacques Rousseau

85
4.1 Introduction
Ce chapitre met en uvre les concepts prsents prcdemment. Pour ce faire, nous allons
dtailler la ralisation de chaque tape en laborant les modles des attributs de SdF (CIM,
PIM, PSM). Ainsi que les transformations ncessaires pour pouvoir aboutir au code. Notre
proposition sera illustre par un cas dtudes issue du domine de la sant publique afin de
dmontrer son intrt.

4.2 Niveau des Exigences


A ce niveau, les exigences de la SdF doivent tre spares des exigences fonctionnelles du SD
afin de les tudier et pouvoir les mettre en avant. Pour mettre en uvre notre approche ce
niveau nous avons dcompos le SD selon ses 4 couches afin de trouver les paramtres qui
influencent directement les aspects de SdF. Nous nous somme bass sur ltat de lart afin
dnumrer dune manire non exhaustive ces paramtres par couche (DS, ETL, DW, OR).
On propose dans ce qui suit un catalogue des paramtres de SdF communs. Ce catalogue peut
tre mis jour en fonction de la nature et du type du projet dcisionnel dun ct, et du niveau
de priorit et de criticit des exigences de SdF dun autre ct.

4.2.1 Source de Donnes (DS)


Disponibilit et fiabilit:<Structuration, Volumtrie, Optimisation, Qualit donne, Support,
Rplication > tel que :
Structuration <structur, semi structur, non structur>
Volumtrie <frquence transaction, nombre enregistrement>
Optimisation <index, fragmentation, vue, paralllisme>
Qualit donne<redondante, manquante, incomplte, errone>
Support<disque dur, communication>
Maintenabilit:<Documentation, Structuration, Optimisation, Support> tel que :
Documentation <schma, mtadonne>
Structuration <structur, semi structur, non structur>
Optimisation < fragmentation, indexation, vue>
Support<disque dur, maintenance chaud, maintenance froid>
Scurit:<Gestion utilisateur, Donne, Support> tel que :
Gestion utilisateur <authentification, droits, quotas, audit, hirarchie >
Donne <intgrit, authenticit, compltude, verrouillage>
Support< pare-feu, cryptage, rplication>

4.2.2 Extraction, Transformation, Loading (ETL)


Disponibilit et fiabilit:<Qualit donne, Nettoyage, Complexit, Priodicit, Support>tel que

86
Qualit Donne <redondante, manquante, incomplte, errone>
Priodicit <batch, temps rel, cycle rafrachissement>
Nettoyage <consolidation, formatage, restructuration, normalisation, limination
doublon, limination valeurs aberrante, limination valeurs manquante>
Complexit < volume donne, rgles calcul, nombre source donnes>
Support<RAM, stockage temporaire, communication>
Maintenabilit:<Mtadonne, Modularit, Complexit, Restauration > tel que :
Mtadonne <source, destination, oprations nettoyage, rgles gestion, contraintes>
Modularit < interdpendance transformations, dcomposition sous-systmes>
Complexit < rgles calcul, nombre source>
Restauration< gestion recouvrements, gestion exceptions>
Scurit:<Gestion Intrusion, Audit, Restauration> tel que :
Gestion Intrusion <pare-feu, cryptage, codification, contrle daccs>
Audit <donne, transformation>
Restauration< gestion recouvrements, gestion exceptions>

4.2.3 Entrept de Donnes (DW)


Disponibilit et fiabilit:<Schma, Volumtrie, Complexit, Rplication, Optimisation,
Support, Priodicit chargement> tel que :
Schma <toile, flocon, constellation>
Complexit <nbre fait, nbre dimension, nbre hirarchie>
Volumtrie <nbre Enregistrement, frquence daccs, granularit>
Optimisation < vue, fragmentation, indexes, paralllisme>
Support <disque dur, communication>
Maintenabilit:<Documentation, Architecture, Complexit, Optimisation, Support> tel que :
Documentation<mtadonne, schma, dimension>
Architecture<centralise, distribue, consolidation DM>
Complexit <dpendance dimensions, granularit>
Optimisation < fragmentation, indexation, vue, paralllisme>
Support<disque dur, maintenance chaud, maintenance froid>
Scurit:<Gestion utilisateur, gestion donne, support> tel que :
Gestion utilisateur<authentification, droits, quotas, audit, hirarchie>
Gestion donne < intgrit, authenticit, compltude, verrouillage,>
Support <pare-feu, cryptage, rplication >

87
4.2.4 Outils de Restitution (OR)
Disponibilit et fiabilit:<Type, Volumtrie, Complexit, Support> tel que :
Type <requte Ad hoc, requte paramtrable, tableau de bord, cube OLAP, Data
Mining>
Volumtrie<volume de donne>
Complexit <nbre axes, transformation, granularit>
Support <RAM, Communication>
Maintenabilit:<Type, Documentation, Modularit, Complexit> tel que :
Type <requte Ad hoc, requte paramtrable, tableau de bord, cube OLAP, Mining>
Documentions < mtadonne, requtes, indicateurs, rgles de calcul >
Modularit < interdpendance, paralllisme>
Complexit <nbre axes, transformation, granularit>
Scurit:<Gestion utilisateur, Gestion Donne, Support> tel que :
Gestion utilisateur<authentification, droits, quotas, audit, hirarchie>
Gestion donne< intgrit, validit, confidentialit>
Support <pare-feu, cryptage>

88
Phase Du SD Disponibilit et fiabilit Maintenabilit Scurit

Structuration<structur, semi structur, non structur> Documentation<schma, mtadonne>


Volumtrie<frquence transaction, Nbre Enregistrement> Structuration<structur, semi structur, non Gestion utilisateur <authentification, droits,
Source Optimisation<indexe, fragmentation, vue, paralllisme> structur> quotas, audit, hirarchie >
Qualit donne<redondante, manquante, incomplte, errone> Optimisation< fragmentation, indexation, Gestion Donne<intgrit, authenticit,
Donne compltude, verrouillage>
Support<Disque dur , communication> vue>
support< pare-feu, cryptage, rplication >
Rplication Support<Disque dur, chaud, froid>

Mtadonne<Source, Destination, Oprations


de Nettoyage, rgles gestion, contraintes>
Qualit Donne<redondante, manquante, incomplte, errone>
Modularit< Interdpendance des Gestion intrusion <pare-feu, cryptage,
Nettoyage<consolidation, Formatage, Restructuration,
transformation , 38 sous systmes: Analyse, Codification, Contrle daccs>
ETL Normalisation, limination: doublon, Aberrante, manquante>
Nettoyage , validation de la conformit de Audit<Donne, transformation>
Priodicit<batch, temps rel, cycle rafrachissement>
donnes,> Restauration< Gestion des recouvrements,
complexit<Volume donne, rgles calcul, nombre source>
Complexit< rgles calcul, nombre source> Gestion des exceptions>
Support<RAM, stockage temporaire (ODS, SA), Communication>
Restauration< Gestion des recouvrements,
Gestion des exceptions>

Documentation<Mtadonne, schma,
Schma<toile, flocon, constellation> dimension>
Volumtrie<Nbre Enregistrement, frquence daccs, granularit> Architecture<Centralise, distribue, Gestion utilisateur<authentification, droits,
Complexit<nbr table de fait, nbr dimension, nbr hirarchie> consolidation DM> quotas, audit, hirarchie>
DW Rplication Complexit<dpendance des dimensions, Gestion de Donne < intgrit, authenticit ,
Priodicit de chargement granularit> compltude, verrouillage,>
Optimisation< vue, partitionnement, indexes, paralllisme> Optimisation< fragmentation, indexation, Support<pare-feu, cryptage, rplication >
Support<Disque dur , communication> vue, paralllisme>
Support<Disque dur, chaud, froid>
Type<requte Ad hoc, requte paramtrable, tableau de bord, cube Type<requte Ad hoc, requte paramtrable,
OLAP, Data Mining..> tableau de bord, cube OLAP, Data Mining..> Gestion utilisateur<authentification, droits,
Outils de Volumtrie<Volume de donne> Documentions< Mtadonne, requtes, quotas, audit, hirarchie, >
Complexit<nbr axes, transformation, granularit, > indicateurs, rgles de calcul > Gestion de Donne< intgrit , validit,
restitution
Support<RAM, Communication> Modularit<interdpendance, paralllisme > confidentialit, >
Complexit<nbr_axes, transformation, Support<pare-feu, cryptage, >
granularit, >
Tableau 2: Les paramtres de sret de fonctionnement des systmes dcisionnels par couche et par attribut
Le tableau prcdant rcapitule les paramtres Que nous venons de dcrire en distinguant
entre les paramtres qui amliorent les attributs de SdF (en vert), et ceux qui reprsentent des
contraintes (en rouge) dont il faut tenir compte lors de la ralisation du SD.

4.3 Niveau Indpendant de la Programmation (CIM)


Nous avons propos prcdemment dutiliser le NFR Framework pour faciliter llaboration
des modles ce niveau dabstraction. Dans les sections suivantes nous allons laborer les
SIG (Soft Goal Interdependency Graph) de chaque attribut de la SdF en exploitant les
paramtres dtaills au niveau des exigences.

4.3.1 CIM de la disponibilit et de la fiabilit


Selon le catalogue de [126], [103] la disponibilit peut tre dcompose en fiabilit et
distributivit. Pour raffiner ces softgoals, nous avons intgr les paramtres retenues du
niveau des exigences. Ainsi pour amliorer la fiabilit on peut utiliser les techniques
doptimisation dtailles dans le chapitre 2, et prendre en considration la complexit du SD
(voir figure 17). Cette dernire dpend de la priodicit du chargement du systme, du volume
et de la qualit des donnes.

Figure 17: CIM de la disponibilit et de la fiabilit

Quant la distributivit, elle peut tre amliore en utilisant les techniques de rplication
et/ou en tenant compte des contraintes des supports utiliss par le SD. Ces derniers peuvent
tre rsolus grce lapplication des techniques de fragmentation et de paralllisme cit
auparavant dans le chapitre 2.

90
4.3.2 CIM de la maintenabilit
Malheureusement, les travaux prsents dans[103] nont pas trait la maintenabilit des SD, et
donc nous avons d proposer notre propre catalogue pour laffiner base des catalogues
quils ont propos et de notre tude de ltat de lart.

Figure 18: CIM de la maintenabilit

Ainsi pour assurer la maintenabilit des SD, nous proposons de dvelopper 4 aspects
savoir : la modularit, loptimisation, la documentation et tenir compte des contraintes de
support comme est schmatis dans la figure 18.
La modularit amliore la maintenabilit mais, il faut y avoir un certain niveau
dinterdpendance entre les modules du SD pour faciliter leur maintenabilit. En plus il faut
penser la documentation du systme du point de vue sources de donnes, transformations et
mtadonne. Dun autre ct, les techniques doptimisation telle que le paralllisme offrent
plus de maintenabilit au SD, toutefois il faut tenir compte de la complexit dj affin dans
la figure 17. Enfin, les contraintes de maintenabilit des supports doivent tre prises en
comptes en leurs appliquant les techniques adquates qui augmentent leurs maintenabilits.

4.3.3 CIM de la scurit


Le catalogue reprsent par la figure 19 dcompose la scurit selon 3 aspects : la
disponibilit, lintgrit et la confidentialit. La disponibilit a t dj traite dans la figure
17. Lintgrit dpend du support et du niveau dintgrit des donne manipul par le SD qui
peut tre amlior en utilisant les techniques de nettoyage, mais qui peut tre influenc par les
intrusions qui nuisent aussi la confidentialit. Cette dernire peut tre amliore en intgrant

91
les techniques de gestion des utilisateurs. La figure 19 schmatise lensemble des paramtres
qui influent directement et indirectement la scurit des SD.

Figure 19: CIM de la scurit

4.3.4 CIM intgrale de la SdF


Parmi les objectifs phares de notre sujet de recherche est le traitement des interactions des
attributs de la SdF. Ainsi, les modliser nest pas suffisant pour dtecter ces interactions et
rsoudre leurs conflits. Par ailleurs, le choix de lutilisation du NFR Framework t fait
surtout grce sa possibilit de dtecter les conflits entre les diffrents softgoals et leurs
oprationnalisations.

Dans ce sens nous proposons dintgrer les 3 CIM labors prcdemment et conservant les
paramtres en commun des attributs de la SdF afin de pouvoir dtecter leurs conflits et ne
retenir quune combinaison optimale qui assurera la SdF du systme selon le niveau exig par
ses utilisateurs. A ce niveau et comme nous avons dj prcis dans la mthodologie dtaille
dans la figure 11, si les conflits nont pas pu tre rsolue, il faut penser retourner ltape
prcdente afin de redtailler les exigences avec lutilisateur.

La figure 20 illustre un extrait du CIM intgrale qui rassemble les attributs de la SdF, et
souligne les paramtres en interaction positive ou conflictuelle. Dans cet exemple la
distributivit amliore la disponibilit mais diminue les degrs de confidentialit et

92
dintgrit. Et donc si la distributivit est exige par lutilisateur, il faut trouver soit un
quivalent ou prciser la cause de son limination.

Figure 20: CIM intgrale de la SdF pour la dtection des interactions

4.4 Niveau Indpendant de la Plateforme


Selon notre approche, nous proposons lutilisation du profil QoS-FT que nous avons dtaill
dans le chapitre prcdant. Toutefois nous tenons souligner que ce profil est trs gnral car
il traite lensemble des aspects de la qualit de service et de la tolrance aux fautes pour tout
type de systme. Or ce qui nous concerne cest les aspects de sret de fonctionnement dans
le contexte du SD. Ds lors, nous proposons de se limiter aux strotypes suivants :
QoSStatement pour distinguer laspect de la SdF, QoSConstraint pour prciser que le
paramtre est une contrainte qui doit tre prise en compte lors de llaboration du systme et
QoSparameter pour prciser que cest un paramtre sur lequel on peut agir pour amliorer
les aspects ou leur combinaison. Enfin nous avons utilis deux types dassociation :
QoSrelation et lhritage.

93
4.4.1 PIM de la disponibilit et de la fiabilit

Figure 21: PIM de la disponibilit et de la fiabilit

Le PIM de la disponibilit et de la fiabilit (figure 21) reprend les paramtres dj traits mais
cette fois ci selon une perspective plus informatise, cest--dire, plus affine mais sans entrer
dans les dtails de la plateforme. Dans ce sens nous avons prcis que le volume de donnes
peut dpendre du volume des donnes des sources de donnes ou de lentrept. En plus, nous
avons dtaill les techniques doptimisation en citant les vues, la fragmentation et les indexes,
et nous avons spcifi que la complexit du systme est cause par la complexit du DW, du
ETL et des outils de restitution. Enfin nous avons numr lensemble des types utiliss tels
que le type de structure des donnes sources, le type du nettoyage, le type de schma de
lentrept de donnes, le type de la qualit de donne, le type de priodicit, le type de
fragmentation et des outils de restitution, et enfin le type du stockage temporaire.

4.4.2 PIM de la maintenabilit


De mme le PIM de la maintenabilit illustr sur la figure 22 reprend le CIM de la
maintenabilit en lui ajoutant plus de dtails sans entrer dans les spcifications dune
plateforme donne. Ainsi nous avons prcis les attributs des mtadonnes pour assurer une
bonne documentation, en plus nous avons dtaill les techniques de restauration et de
modularisation qui seront amliores par le paralllisme.

94
Toutefois nous soulignons que plusieurs paramtres dj cits pour la fiabilit et la
disponibilit sont repris pour la maintenabilit ce qui redmontre que les aspects de SdF sont
en interaction et quune bonne combinaison des paramtres implmenter peut fournir un
niveau de SdF optimal.

Figure 22: PIM de la maintenabilit

4.4.3 PIM de la scurit


De mme pour la scurit, nous avons intgr les techniques qui influencent la scurit
positivement ou ngativement indpendamment des dtails dune plateforme prcise (voir
figure 23). Ainsi nous avons cit des techniques de gestion des utilisateurs telles que les
permissions, les audits, lauthentification, les quotas et les hirarchies. Et nous avons aussi
prcis les techniques de la gestion des donnes qui sarticulent autour de la confidentialit,
lintgrit, lauthenticit, la compltude et le verrouillage. Et enfin, nous avons cit les
techniques permettant de scuriser le support comme la rplication, restauration et le pare-feu.

4.4.4 PIM Intgral de la SdF


Aprs llaboration de PIM des diffrents aspects de SdF, nous proposons de les intgrer dans
un seul PIM qui va permettre de confronter lensemble des paramtres et techniques pour
ensuite essayer de retenir ceux qui amliorent au maximum les attributs de SdF dans leur
globalit en fournissant un optimum qui doit bien entendu respecter le niveau exig par

95
lutilisateur final du systme. La figure 24 est un extrait du PIM intgral fait surgir la
fragmentation comme technique qui influence directement ou indirectement lensemble des
aspects de SdF.

Figure 23: PIM de la scurit

Figure 24: PIM Intgral de la SdF

96
4.5 Transformations du CIM au PIM
Ainsi pour raliser les transformations du CIM en PIM dans notre approche, nous avons dfini
les transformations ATL entre les mtamodles NFR et QoS-FT comme le montre la figure
25. La dite transformation doit tre exprime sous la forme dexpressions OCL qui est la base
des transformations ATL.

MOF

NFR Framework ATL QoS FT Profil


Profil

CIM2PIM.atl
CIM PIM

Figure 25: Transformation ATL du CIM NFR au PIM QoS

Le profil QoS FT est dj prsent dans le chapitre prcdent. Alors que le profil SIG du
NFR Framework est celui de la figure suivante:

Figure 26: MetaModel du NFR Framework

Or nous avons remarqu que les strotypes NFRSoftgoal et des OperationalizingSG dans
notre contexte peuvent reprsenter plusieurs notions du Dfinies par le profile QoS-FT. Ainsi
pour faciliter la spcification de la transformation entre les deux profils, nous proposons
dtendre le profil SIG prsent dans la figure 26 en prcisant les diffrents types que peuvent
prendre le softgoal et lOperationalizingSG. La figure suivante schmatise cette
spcialisation.

97
Figure 27: Spcialisation du NFR Framework

Ainsi, un aspect peut tre un softgoal seulement contrairement aux paramtres et contraintes
qui peuvent tre soit des NFRSoftgoal ou OperationalizingSIG. Dans lautre sens, les
strotypes NFRSoftgoal et OperationalizingSG peuvent reprsenter dans notre contexte soit
un aspect de la sret de fonctionnement, soit un paramtre ou une contrainte sur ce dernier.
Cette spcialisation a permis plus de flexibilit du NFR Framework et plus de facilit pour
llaboration des rgles de transformation qui sont dtailles dans le listing suivant :

1. module QosModel
2. create QosModel: UML2 from NFRModel: UML2, QosProfile: UML2, NFRProfile: UML2;
3. helper def: QoSCharacteristic : UML2!Stereotype = OclUndefined;
4. helper def: QoSConstraint : UML2!Stereotype = OclUndefined;
5. helper def: QoSParameter : UML2!Stereotype = OclUndefined;
6. helper def: rootQos : UML2!Package = OclUndefined;
7. rule SG2Class{
8. from sg: UML2!Class (sg.belongsToSIG() && sg.hasStereotype('Softgoal'))
9. to cl: UML2!Class()
10. do{ if(sg.hasStereotype('Aspect'){
1. cl.applyStreotype(thisModule.QoSCharacteristic )
ii. }else{ if(sg.hasStereotype('Constraint'){
1. cl.cl.applyStreotype(thisModule.QoSConstraint)}
2. else{
3. cl.cl.applyStreotype(thisModule.QoSParameter)}
iii. } thisModule.rootQos.packagedElement<- cl;
11. }}
12. rule operationalizingSG2QoS{
13. from os: UML2!Class (os.belongsToSIG() && os.hasStereotype('operationalizingSG'))
14. to cl: UML2!Class()
15. do{ if(os.hasStereotype('Constraint'){
1. cl.applyStreotype(thisModule.QoSConstraint)}
ii. if(os.hasStereotype('Parameter'){
1. cl.cl.applyStreotype(thisModule.QoSParameter)}
16. thisModule.rootQos.packagedElement<-cl; }} 98
4.6 Niveau Spcifique la Plateforme
Le niveau spcifique la plateforme exige lintgration de la plateforme dans les modles.
Toutefois les modles PIM, rsultantes du niveau prcdant, ont t labors indpendamment
des plateformes et en intgrant les diffrentes couches (DS, ETL, DW, OR). Lobjectif est de
tenir compte des interactions entre les diffrents aspects de SdF du SD en entier et non pas
dune couche ou dune plateforme spcifique.
On va raliser les PSM de ce niveau selon deux tapes. La premire consiste raliser des
PSM spcifiques chaque couche du SD. Ensuite, on va raliser pour chaque couche des
PSM spcifiques la plateforme dimplmentation (Oracle, Business Object, Pentaho etc.).
La figue suivante schmatise notre proposition ce niveau.

Figure 28: Elaboration des PSM partir du PIM Intgral

Pour laborer le PSM on va driver partir du PIM, les aspects propres chaque couche dans
une premire phase. Ensuite, on va tisser ce dernier avec le PSM modlisant les exigences
fonctionnelles. Ainsi on va obtenir un PSM dployable sur un environnement dexcution. Le
principe de tissage offert pat lAOM va permettre llaboration des modles PSM intgrales
contenant la fois la logique mtier avec ces exigences de SdF. Ces derniers peuvent tre
modliss par des diagrammes de dploiement pour faciliter leur mise en uvre. La figure 29
prsente le PSM driv relatif la couche DW.

99
Figure 29: PSM SdF pour la couche DW

En se basant sur les travaux de [137][133] [138] qui ont propos des extensions de UML pour
la modlisation oriente aspects, nous proposons une reprsentation des paramtres et
contraintes des aspects de la SdF ainsi que le tissage sous forme de composants strotyps.
Selon [139], les diagrammes de dploiement et de composant sont les mieux adapts pour
expliciter la modularisation prconise de lAOSD. La figure 30 reprsente un exemple de
tissage du PSM des aspects de SdF du DW avec les exigences fonctionnelles reprsentes par
un schma DW standard contenant une table de fait avec lensemble de ses dimensions.

Figure 30: tissage des aspects de SdF avec la partie fonctionnelle

100
4.7 Etude de Cas : Systme Dcisionnel pour Tableaux de Bord des Soins
dUrgence Cliniques

4.7.1 Objectifs
Cette section a pour objectif de prsenter le cas dtude que nous avons choisis afin
d'exprimenter notre contribution prsente dans ce chapitre et le chapitre prcdent.
Lobjectif du cas dtude est de montrer que notre approche permet dassurer la prise en
compte des aspects de sret de fonctionnement depuis les premires tapes du SD selon leurs
criticit et en traitant leur interaction. Ainsi le systme la fin du cycle de dveloppement doit
intgrer ces aspects sur mesure et dois aussi justifier chaque tape les choix retenues et les
dcisions prises concernant les aspects de SdF. Ainsi ltape finale, le systme doit intgrer
la meilleure combinaison optimale qui permettra dassurer le niveau de confiance exig par
ses utilisateurs finaux selon leurs propres priorits.

4.7.2 Mthodologie
Afin de concrtiser notre approche par ltude de cas, nous allons tout dabord fournir une
prsentation gnral du systme cible. Lobjectif ce stade prliminaire est de dcliner ses
exigences fonctionnelles et non fonctionnelles. Pour ensuite entamer lapplication de notre
mthodologie selon ces niveaux dabstraction.

Ainsi, Dans le niveau des exigences nous allons driver les exigences de SdF partir des
besoins non fonctionnels. Ensuite nous allons analyser les besoins de SdF toute couche
confondue, pour laborer les CIM de chaque aspect de SdF et ensuite de les confronter. Cette
confrontation se fera dans un CIM intgrale qui permettra de dduire les choix qui seront
retenus pour le niveau suivant selon leurs criticits et priorits. Dans le niveau indpendant
de la plateforme, nous allons dtailler les aspects retenus afin de raliser les PIM de chaque
aspect et de les r-confronter afin de dduire les choix retenus pour ltape suivante. Dans le
dernier niveau, nous allons prendre lexemple de la couche DW afin proposer une
implmentation possible de la combinaison optimale rsultante des tapes prcdentes en
ralisant son tissage avec un schma fonctionnel du DW. De Ce tissage va rsulter un modle
dployable sur la plateforme finale.
Enfin, nous allons raliser le systme final intgrant la combinaison optimale dans une
plateforme technique. Et pour justifier que notre systme intgre les aspects de SdF
modliss, nous allons prparer des scnarii dattaque afin dinjecter et dinsrer des erreurs
et des fautes dans notre systme finale pour dclencher son dysfonctionnement. Lobjectif est
de tester sa raction et ractivit dun ct et de mesurer le niveau de sret de
fonctionnement quil assure de lautre ct.

101
4.7.3 Cahier des Charges
Cette tude est extraite du cahier des charges de Tableaux de Bord des Soins dUrgence
Cliniques sur le site web de NHS1. National Health Service (NHS) est le systme de la sant
publique du Royaume-Uni. Cette organisation fournit le fondamental des soins depuis la
mdecine gnrale aux salles d'urgence des hpitaux, les soins longs durs aux soins
dentaires. NHS a dclench l'initiative de Tableaux de Bord de soins d'urgence clinique dont
les principaux objectifs sont:

Mettre en uvre les tableaux de bord de soins d'urgence clinique la disposition de


toute la communaut de sant travers l'Angleterre en commenant par 12 sites
pilotes;

Crer une bote outils pour standardiser les tableaux de bord des soins d'urgence y
compris les normes, l'architecture logique, des flux de donnes bibliothque, la
documentation de conception dtaille, des objets de gestion de projet et de mises
jour du rfrentiel des mtriques.
Le but du cahier des charges est de fournir des conseils techniques pour mettre en place un
tableau de bord de soins d'urgence clinique pour toute la communaut de sant local et pour
les membres de projets techniques qui devront dterminer la solution finale.

Plus d'informations sur le projet peuvent tre trouves sur les pages de Networks.nhs2 : Pour
un souci de simplicit nous allons rfrencer le cas dtude par UCCD qui dsigne Urgent
Cares Clinical Dashboard.
Dans ce qui suit, nous allons prsenter intgralement les exigences fonctionnelles et non
fonctionnelles tel quelles sont exprimes dans le cahier des charges (sauf modifications
imposes pour avoir une traduction correcte):

4.7.3.1 Exigences fonctionnelles


La Modle conceptuel des Services technologiques ci-dessous donne un aperu des services
fonctionnels que la solution technologique Tableau de Bord devrait offrir. Ce Modle est
subdivis en trois couches: Chanes, Services dApplication et Infrastructure et scurit.

1
Version de Date 20/2/2011 tlchargeable par le lien suivant : http://www.networks.nhs.uk/nhs-networks/qipp-
urgent-care-gp-dashboard/documents/test-1
2
http://www.networks.nhs.uk/nhs-networks/qipp-urgent-care-gp-dashboard/urgent-care-clinical-dashboard-
implementation-guide.

102
Figure 31: Modle conceptuel des services technologiques

a) Les canaux : identifient les diffrents itinraires travers lesquels les informations du
tableau de bord peuvent tre reues:

Interface utilisateur : fournir un accs via l'application de bureau comme un navigateur


Web.

Affichage Grand Echelle : offrir la possibilit d'afficher des tableaux de bord sur
grands crans dans des endroits cliniques pour la consommation publique ou clinique.

Portail : offrir la possibilit d'exposer les composants de tableau de bord via un portail
existant.

Extraction de donnes : fournir un mcanisme par lequel les donnes peuvent tre
exportes sur une base programme pour formats standards tels que CSV ou XML.

Alertes : fournissent un mcanisme de notification des mises jour, alertes, erreurs,


etc.

b) Services dApplication : Identifient les fonctionnalits cls qui seront soutenues par
l'application du tableau de bord:

Extract, Transform & Load (ETL): fourniture de fonctionnalits pour permettre de:
Extraire des donnes des systmes sources dans un format dfini,

103
Transformation des donnes extraites dans les formats requis pour l'utilisation par
le tableau de bord (entrept de donnes et d'affichage du tableau de bord), et
Charger des donnes dans l'entrept de donnes du tableau de bord ou Dashboard
Affichage clinique.
Dashboard Prsentation : fourniture d'une couche d'affichage qui permet aux donnes
du tableau de bord (mtriques) dtre prsentes dans une varit de formes (textes,
graphiques, etc.) destines la consommation par une varit d'utilisateurs (cliniciens,
le public, etc.)
Reporting & Analyse : fourniture d'une fonctionnalit qui permet d'analyser les
paramtres plus en dtail (analyse) et la cration de rapports spcialiss rsumant cette
analyse.

Service anonymisation - fourniture d'une fonctionnalit qui permet l'limination ou


obscurcissement de patients sensibles ou des donnes cliniques pour sassurer que
seuls les cliniciens autoriss ont accs.
Intgration Service donnes - fourniture d'un service qui permet aux processus
d'extraction de donnes, de transformation et de charge automatiss dtre excutes
selon les besoins. Cela inclut les spcifications de flux d'information d'interoprabilit
et les normes de chargement.
Gestion des donnes - fourniture d'un service qui permet aux donnes cliniques dtre
crs, mises jour, supprimes, structures et rsumes selon les besoins.
Gestion des Meta donnes - fourniture d'un service pour grer et fournir l'accs
l'information sur les donnes, par exemple la provenance des donnes et quel journal
des transformations ont t effectues son sujet.

La saisie manuelle de donnes - la fourniture d'une fonctionnalit qui permet aux


donnes d'tre incorpors dans le tableau de bord grce des processus manuels, par
exemple le tlchargement d'un fichier de donnes correctement format dune
manire manuelle.

Outils de dveloppement - la fourniture d'outils de dveloppement pour permettre au


tableau de bord dtre modifi tel que requis par ses utilisateurs.

c) Infrastructure et Scurit - identifier les services sous-jacents qui favorisent le support de


la fonctionnalit de tableau de bord dfini par:

Stockage de donnes : fourniture d'un service de stockage de donnes dans lequel les
donnes ncessaires pour le tableau de bord (fichiers, base de donnes, etc) peuvent
tre stockes et soient accessibles par l'application et ses utilisateurs.

104
Serveurs : fourniture de serveurs pour les donnes d'une application dans le format
souhait et selon le niveau requis en termes de fiabilit, rsilience, performance, etc.
Scurit de l'information : la fourniture de mcanismes qui peuvent tre utiliss pour
scuriser l'accs aux donnes et sassurer que seuls les cliniciens autoriss peuvent
accder aux donnes du tableau de bord.

Directory Services : fourniture d'une assistance pour l'utilisation des identits des
utilisateurs et profils d'accs (rles et groupes).

Services rseau : fourniture de services pour grer une connectivit scurise aux
serveurs de tableau de bord par les utilisateurs.

Identification & gestion dAccs : fourniture du service de la gestion de l'accs aux


tableaux de bord travers un mcanisme de contrle d'accs bas sur les rles lis aux
utilisateurs identifis.
Le Flux Conceptuel dInformation figure dans le schma suivant :

Figure 32: Flux Conceptuel de Donne

4.7.3.2 Exigences non fonctionnelles


En plus des exigences fonctionnelles, les exigences non fonctionnelles de la solution doivent
galement tre prises en considration. Lapproche utilise par NHS se base sur le Modle de
la qualit des logiciels (QUINT2) Extension de lISO 9126 pour laborer la liste des
Exigences de SdF couvrant les caractristiques suivantes :

a) Fonctionnalit : examiner les fonctions des systmes et de leurs proprits spcifies:


Aptitude
Prcision

105
Interoprabilit

Conformit
Traabilit

b) Fiabilit : la capacit du systme maintenir son niveau de performance dans des


conditions dtermines pour une priode dtermine:

Maturit
Tolrance aux pannes

La capacit dtre recouvrable


Disponibilit

Laptitude dtre dgradable


c) Ergonomie : envisager l'effort ncessaire pour l'utilisation, et l'valuation individuelle d'un
tel effort, par un ensemble dclare ou implicite des utilisateurs:
la capacit de Comprhension

la capacit dApprentissage
Efficacit oprationnelle

Explicitation
La capacit dtre personnalisable

Attractivit
Clart

Utilit
Convivialit

d) Efficacit : examiner la relation entre le niveau de performance du logiciel et la quantit


de ressources utilises, les conditions sobres:

comportement de Temps
Comportement des ressources

e) Maintenabilit : envisager l'effort ncessaire pour apporter des modifications spcifiques:


Analysabilit

La capacit dtre Changeable


Stabilit

testabilit

106
La capacit dtre Grable

rutilisation
f) Portabilit - considrer la capacit du logiciel tre transfr d'un environnement un
autre:
Adaptabilit

Capacit de dploiement
conformit

la capacit de Remplacement.
Les exigences non fonctionnelles listes ci-dessus devraient galement tre traites et
intgres conjointement avec les exigences spcifiques de scurit et de l'Infrastructure
suivantes :

G) la scurit :
L'exigence d'un certain niveau de dtail autour de la scurit daccs, la fois au tableau de
bord et aux donnes cliniques utilises dans la solution, savre trs important d'un point de
vue de la confidentialit de la clinique et du patient. Ainsi, les lments suivants doivent tre
considrs comme faisant partie intgrante de la solution:
L'utilisation de HTTPS pour crypter tous les transferts de donnes entre les serveurs
de tableau de bord et les applications clientes.
L'utilisation de mcanismes de transport scuriss pour les transferts de donnes
organisationnelles transversales requises par la solution de tableau de bord.
L'utilisation du cryptage pour protger les donnes sur rseau.

Options d'authentification de l'utilisateur:

Typiquement authentification des utilisateurs est effectue via Active Directory


Domain mais cela pourrait crer des problmes pour tous les utilisateurs hors de
domaine par exemple les utilisateurs de Primary Care Trusts et GP etc.

authentification base NHS Smartcard pourrait tre dploy pour les utilisateurs
hors de domaine, mais des infrastructures et des logiciels supplmentaires sont
envisager. Si les cartes puce ne sont pas utiliss dautres mcanisme
d'authentification doit tre considr.

Gouvernance de l'information doit tre considre lorsque les donnes sont partages
entre les organisations et doit mettre en vidence la ncessit d'accords de partage de
l'information.

107
4.7.4 Mise en oeuvre et validation
Plusieurs scnarios de mise en uvre ont t proposs par NHS en se basant sur les systmes
existants des cliniques. Nous nallons pas taler les scnarios proposs mais plutt nous allons
directement choisir le scnario qui suppose que le Systme Dcisionnel nexiste pas davance
et donc pour raliser les Tableaux de bord, il est ncessaire dlaborer un ETL, un entrept de
donne partir duquel les Tableaux de bord vont charger leurs donnes.

4.7.4.1 Implmentation du Niveau des Exigences


Au Niveau des Exigences, nous proposons de driver les exigences de SdF partir des
exigences non fonctionnelles prsentes dans le cahier des charges. Le tableau ci-dessous
prsente la matrice de correspondance des paramtres de sret de fonctionnement du systme
UCCD par couche et par attribut. Cette matrice reprsente la base pour llaboration des
diffrents modles de notre approche.
Couches Sources ETL Entrept Outils de
Aspects Donne de Donne Restitution
Tolrance aux Pannes
Disponibilit et Recouvrabilit
Fiabilit Dgradabilit
Disponibilit
Maturit
Analysabilit
Stabilit
Changeabilit
Maintenabilit Testabilit
Grabilit
Rutilisabilit
Cryptage
Scurisation de Transport
Scurit Authentification
Confidentialit

4.7.4.2 Implmentation du Niveau Indpendant de la Programmation


Cette tape permettra de modliser les exigences lies chaque aspect de SdF au premier
niveau dabstraction. En exploitant la matrice de correspondance nous avons labor les
modles CIM de disponibilit et fiabilit (figure 33); de la maintenabilit (figure 34) et de la
scurit (figure 35). Ces CIM ont t labor par NFR Framework comme prconis par la
mise en uvre de notre approche.

108
Figure 33: CIM de disponibilit et fiabilit de lUCCD

Figure 34: CIM de Maintenabilit de l'UCCD

109
Figure 35: CIM de la scurit de l'UCCD

Nous allons intgrer les CIM de lUCCD dans un seul CIM intgrale pour tudier les
interactions entre les diffrents paramtres des aspects de SdF. La figure 36 prsente un
extrait du CIM intgral qui met en exergue certaines interactions conflictuelles.

Figure 36: Extrait du CIM Intgral simplifi

110
Cette figure montre que le <<cryptage>> des donnes amliore l<<intgrit>> et la
<<confidentialit>> indispensables pour assurer la <<scurit>>. Toutefois les techniques de
<<cryptage>> augmentent la <<complexit>> [140]. Cette dernire affecte directement la
<<modularit>> et donc nuit la maintenabilit dun ct. Dun autre ct, la complexit
rend la distributivit difficile appliquer et diminue ainsi la fiabilit du systme, ce qui
affecte automatiquement sa disponibilit.
Si on prend lhypothse que le systme dcisionnel UCCD sera un systme qui sera sollicit
dans 90% en interne de la clinique, la mise en uvre du cryptage comme exige par NHS
dans son cahier de charge peut nuire la disponibilit et fiabilit du systme [140]. Ainsi,
grce ltude des interactions nous proposons de nutiliser le cryptage que sur les donnes
qui seront transmises lextrieur de la clinique. Ce choix permettra de ne pas pnaliser la
maintenabilit, la disponibilit et la fiabilit du systme UCCD, toute en assurant un niveau
de scurit satisfaisant.

4.7.4.3 Implmentation du Niveau Indpendant de la Plateforme


Ce niveau est moins abstrait que son prcdent, car nous allons dtailler davantage les
aspects de SdF. Pour cela, nous allons les enrichir sans faire intervenir les caractristiques
dune plateforme quelconque. Ainsi, les modles seront portables et ralisables quel que soit
la plateforme technique dimplmentation. Les figures 37, 38 et 39 reprsentent
respectivement les PIM de disponibilit & fiabilit, de maintenabilit et de scurit, alors que
la figure 40 prsente un extrait de leur PIM intgral.

Figure 37: PIM Fiabilit et Disponibilit

111
Figure 38: PIM de la Maintenabilit

Figure 39: PIM de la Scurit de lUCCD

112
Figure 40: PIM intgral des SdF propre la couche DW du system UCCD

4.7.4.4 Implmentation du niveau spcifique la plateforme


A ce niveau nous proposons llaboration des diagrammes de composant et de dploiement.
Pour cela nous allons mettre en valeur le tissage des aspects avec la partie fonctionnelle au
niveau modlisation juste avant leur mise en uvre. Nous allons appliquer ces concepts la
couche DW afin de mettre en vidence lintgration des aspects de SdF raffin depuis la
premire tape de notre approche.

Le diagramme de composant de la figure 41 reprsente PSM du deuxime niveau. Ainsi


lensemble des aspects seront tiss avec le DW fonctionnel suivant une dmarche Oriente
Aspect. Le schma du DW a t ralis en se basant sur les exemples de tableau de bord
fournis par NHS.

Le diagramme de dploiement de la figure 42 explicite les choix darchitecture technique qui


ont dcoul des compromis faits partir des phases prcdentes. Ce diagramme est
complmentaire au diagramme de composant pour laborer un PSM intgral de la couche
Data warehouse.

Nous prcisons que le NHS a dj propos un ensemble de scnarios darchitecture technique


dans leur cahier des charges. A base de ces derniers, nous avons labor le modle ci-dessus
en tenant comptes des contraintes causes par linteraction des aspects de SdF trait par notre
mthodologie.

113
Figure 41: PSM logique du DW de l'UCCD reprsent par Diagramme de Composant

Figure 42: PSM architectural du DW de l'UCCD par Diagramme de Dploiement

Du point de vue disponibilit et fiabilit, nous proposons de raliser une rplication des
donnes du DW en utilisant deux serveurs indpendants. Cette dernire va assurer la
continuit du service de lUCCD dans le cas dune panne du DW principal. Le serveur
dapplication va switcher les requtes des clients vers le serveur de rplication une fois la

114
passivit du serveur principal est dtecte. La fiabilit du systme est ainsi garantie. Dans le
cas des priodes de surcharge du serveur principal cest--dire le temps de rponse aux
requtes commence sapprocher au seuil inacceptable, le serveur dapplication peut rpartir
la charge des requtes en fonction de leur urgence et criticit (exemple une requte qui est
envoy depuis une salle dopration ou dune ambulance est plus critique que celle qui
provient dune salle de consultation).
Enfin, le serveur secondaire est, en principe ddi aux requtes non urgentes de recherche et
de dveloppement qui peuvent bloquer le serveur principal, sauf dans le cas des priodes de
surcharge du serveur principal ou il doit rpondre aux requtes des clients.

Du point de vue maintenabilit, le faible couplage entre composant logiciel grce la


conception oriente objet augmente considrablement la maintenabilit du systme. En plus
grce au mcanisme de duplication physique des serveurs du DW, et leur sparation du
serveur dapplication on peut effectuer des oprations de maintenance sans que la rponse du
systme soit affecte.
Du point de vue scurit, malgr que le NHS insiste dans un document spciale [141] sur le
cryptage des donnes pour assurer leurs confidentialits, notre approche a pu dmontrer, par
rsolutions des conflits et des interactions des aspects de SdF, que le cryptage des donnes
dans le rseau local dans ce cas dtude nuira directement la disponibilit des donnes
surtout lors des priodes de surcharge (voir section suivante). Toutefois pour assurer un
niveau suffisant de scurit, nous proposons dutiliser LDAP (Active Directory pour
Windows, Open LDAP pour Linux) pour assurer une gestion centralise des utilisateurs
appuye par une stratgie dauthentification base sur des certificats de scurit, ainsi les
clients ne peuvent accder aux donnes que sils sont identifis par le serveur LDAP et sur
des machines qui ont des certificats de scurit agres que par ladministrateur systme.

4.7.4.5 Implmentation et rsultats des tests


Pour mesurer limpact du cryptage exig par NHS sur la disponibilit des donnes nous avons
utilis DWeb qui est un Benchmark permettant de mesurer le temps de rponse dune charge
de requtes (workload) paramtrable. Ainsi, en variant le nombre de requtes, leurs types et le
volume de donnes du Data warehouse, nous pouvons constater que le temps de rponse peut
devenir trs insatisfaisant voir critiques dans des cas particuliers.
Lexprimentation suivante a t ralise sur un PC de 4Go de RAM et de processeur Intel
Core i5 de 2,60GHz excutant Windows 7 et contenant le SGBD Oracle 10g install ddi au
Data warehousing.

Toutes les mesures des figures 43, 44, 45, 45 ont t ralises toute abstraction faite aux
contraintes de performance des supports et infrastructures Rseau. Ainsi, dans un premier lieu
nous avons procd par fixer le volume du DW et changer la charge des requtes de 20 100

115
requtes en lappliquant au plus petit entrept de donne DW1 dont la capacit est de 22 Mo
au plus grand qui est le DW10 contenant 2Go de donne.

12000
DW1 SIZE= 22MO
10000
response time (ms)

8000

6000

4000

2000

0
20 query 40 query 60 query 80 query 100 query
Without Encryption 2589 3680 4523 5635 7748
with Encryption 3100 4000 5800 7940 10900

Figure 43: Temps de rponse du DW1 aux diffrentes charges de requtes

14000 DW10 SIZE =2Go


12000

10000

8000

6000

4000

2000

0
20 query 40 query 60 query 80 query 100 query
Without Encryption 4200 4800 5500 6300 8748
with Encryption 5100 5700 6800 7940 12900

Figure 44: Temps de rponse du DW10 aux diffrentes charges de requtes

Les figures 43 et 44 montrent que plus le DW est volumineux plus le cryptage affecte le
temps de rponse en fonction du nombre des requtes constituant la charge excuter.

116
6000
workload : 20 queries
5000

4000

3000

2000

1000

0
DW1 DW2 DW3 DW4 DW5 DW6 DW7 DW8 DW9 DW10
Without Encryption 2589 2700 2980 3280 3500 3680 3710 3820 4010 4200
with Encryption 3100 3300 3700 4100 4300 4500 4550 4690 4900 5100

Figure 45: Temps de rponse de la charge de 20 requtes aux diffrents volumes de DW

14000
Workload : 100 queries
12000

10000

8000

6000

4000

2000

0
DW1 DW2 DW3 DW4 DW5 DW6 DW7 DW8 DW9 DW10
Without Encryption 4200 4600 5000 5400 5800 6200 6600 7000 7400 8748
with Encryption 5100 5900 6700 7500 8300 9100 9900 10700 11500 12900

Figure 46: Temps de rponse de la charge de 100 requtes aux diffrents volumes de DW

Les figures 45 et 46 prouvent que le temps de rponse des requtes augmente en fonction des
requtes constituant la charge. Ainsi plus la charge des requtes augmentent plus le cryptage
affecte svrement le temps de rponse. Ce constat savre critique dans le cas des soins
urgents ou la vie du patient peut tre mise en danger.

4.8 Synthse
Ce chapitre offre une vision globale sur la mise en uvre de notre proposition dirige par les
modles afin de traiter les aspects de SdF dans le contexte des SD. Ainsi nous avons suivis les

117
tapes de notre mthode propose depuis le premier niveau dabstraction jusqu la mise en
uvre. Pour enfin lvaluer par une tude de cas afin de montrer son applicabilit dun ct,
et dexpliciter le traitement des interactions des aspects de SdF dun autre ct.

Au Niveau des Exigences : nous nous sommes bass sur ltat de lart dtaill au
deuxime chapitre, afin de lister les paramtres influenant les aspects de SdF pour
chaque couche du SD. Ces paramtres ont t retenus pour tre modlis dans le niveau
suivant.
Au Niveau Indpendant de la Programmation : nous avons raffin les paramtres
retenues en ralisant des modles CIM pour chaque aspect sans voquer les dtails de la
programmation. Ainsi chaque CIM est compos de tous les paramtres indpendamment
de la couche do il provient. Cette consolidation nous a permis de rsoudre les
interactions des paramtres pour chaque aspect avant de traiter leurs interactions avec les
autres aspects. Cette dernire a t mise en uvre par la composition des CIM en un CIM
intgral. A ce niveau de lapproche nous avons prconis lutilisation du NFR Framework
qui offre des mcanismes de raffinement et de traitement des interactions lors de
llaboration du SIG : Softgoal Interdependency Graph.
Au niveau Indpendant de la Plateforme : Le rsultat de la confrontation des paramtres
fournis par le niveau prcdent est exploit dans ce niveau afin dlaborer les PIM de
chaque aspects. Ainsi, la mme procdure est ritre afin de raffiner les paramtres
retenus et les rintgrer pour les confronter dans un PIM intgrale afin de traiter leur
interaction. Nous avons propos ce niveau lutilisation du profil QoS-FT qui est une
extension dUML pour modliser la qualit de service et la tolrance aux fautes. Ce profil
nous a fournis des mcanismes utiles pour mieux concrtis les paramtres rsultants des
niveaux prcdents abstraits.
Transformation : Pour concrtiser le passage du niveau CIM au niveau PIM indpendant
de la plateforme, nous avons mis en uvre des rgles de transformations qui se basent sur
le langage ATL. Ces rgles de transformations sappuie sur les mtas modles NFR
Framework et QoS-FT Profil pour assurer la traabilit des exigences qui passent dun
niveau lautre. Pour faciliter cette transformation nous avons utilis le mcanisme
dextension dUML afin dtendre le mta modle NFR pour mieux correspondre au mta
modle du profil QoS-FT.
Au niveau spcifique la plateforme : les dtails de la plateforme dimplmentation
doivent apparaitre. Pour concrtiser les modles de ce niveau, nous nous sommes heurts
deux difficults : la premire rside dans le caractre multicouche du SD car les modles
PIM se concentrent sur les aspects alors que limplmentation sintresse surtout la
couche et la technologie cible. La deuxime difficult rside dans le caractre
complmentaire des aspects de SdF, car ces aspects ne peuvent pas tre implment quen
lincorporant aux aspects fonctionnels du systme en question. Pour surmonter ces

118
difficults nous avons propos de ralis le PSM selon deux tapes : la premire tape se
concentre extraire des PIM les paramtres propres chaque couche pour les rassembler
dans des PSM par couche. Cette procdure va permettre de faciliter limplmentation par
couche et ensuite par plateforme. Alors que la deuxime tape propose lutilisation de la
modlisation oriente aspect afin de tisser les aspects de SdF avec les aspects fonctionnels
pour pouvoir les implmenter. A cette tape nous avons propos lutilisation les
diagrammes dUML tel que le diagramme de Package, de Composant et de Dploiement
ainsi que lextension UML pour le Dveloppement Logiciel Orient Aspect. Ces
diagrammes riches nous ont permis de donner des points de vue diffrents et
complmentaires pour modliser les PSM et rsoudre les difficults rencontres ce
niveau.
Evaluation : pour valuer notre proposition, nous lavons appliqu tape par tape sur un
cas dtude. Ce dernier a t extrait du cahier des charges fournis par le service national de
sant du Royaume Unis (NHS) pour la mise en uvre de tableau de bord de soins
d'urgence clinique. La particularit de ce cas dtude est limportance de la prise en
considration des aspects de SdF ds les premires tapes du projet surtout la disponibilit
et la scurit dun ct. De lautre ct, la ncessit du traitement des interactions des
aspects pour avoir une traabilit et une justification des choix architecturaux retenues.
Ces derniers reprsentent la combinaison optimale des aspects de SdF qui peut tre
implmente. Ainsi nous avons labor les CIM de chaque aspect en raffinant sur les
exigences de SDF extrait des exigences non fonctionnels abstraits cites par le cahier des
charges. Ensuite nous avons compos les CIM des aspects de SdF en un CIM intgral afin
de rsoudre leurs conflits et interaction ce niveau. Ensuite nous avons labor les PIM
de chaque aspect en se basant sur les rsultats de consolidation de ltape prcdente, et
nous les avons confronts pour ressortir leur combinaison optimale. Enfin nous avons
labor le PSM de la couche Data warehouse comme exemple pour le tisser avec un
schma fonctionnel grce au mcanisme de la modlisation Oriente Aspect. Enfin nous
avons utilis le Benchmark DWEB afin de le gain et lapport de notre mthode pour
intgrer et rsoudre les problmes dinteraction entre les besoins de sret de
fonctionnement.

119
Conclusion et perspectives

L'homme le plus parfait est celui qui sait en chaque chose considrer la fin.
Citation de Hsiode ; Les travaux et les jours - VIIIe s. av. J.-C.

120
5.1. Bilan des travaux raliss
Les travaux dvelopps dans ce mmoire sinscrivent dans le cadre de lintgration des
aspects de SdF depuis les premires tapes de llaboration du SD, tout en garantissant la
prise en compte de leurs interactions et conflits mutuels. Ltat de lart expos dans le
deuxime chapitre, a dmontr que les aspects non fonctionnels ont t largement traits mais
dune manire individuelle sans tenir compte de leurs interactions. En plus, dans la majorit
des cas, ils nont t abords quaux phases de modlisation physique ou dimplmentation,
phase o lensemble des choix architecturaux ont t dj effectus.

Ainsi, il nous est apparu ncessaire de proposer une approche globale dintgration des
aspects de SdF dans le processus de conception du SD. Dans ce sens, cette thse propose une
approche aligne au standard MDA de lOMG. Notre approche prconise lutilisation des
modles durant les niveaux dabstraction ce qui assure la traabilit des exigences de SdF
ainsi que leur prise en compte ds les phases prcoces du processus du dveloppement du SD.
En plus, la modlisation des aspects de SdF nous a permis de traiter leurs interactions
chaque niveau, pour avoir la fin la combinaison optimale la plus proche des exigences de
Sdf de dpart en fonction de la criticit et priorit de chacune dans le SD final.

Notre proposition est une approche descendante de plus niveau dabstraction qui correspond
au niveau du recueil des exigences fonctionnelles et non fonctionnelles jusqu
limplmentation en passant par les niveaux suivants :
Niveau des exigences : qui permet de lister lensemble des exigences non
fonctionnelles du systme pour ensuite en extraire ceux propres la SdF.
Niveau indpendant de linformatisation : qui permet de modliser les exigences
recueillis du niveau prcdent en les raffinant en paramtre et dtectant leurs conflits
avant leurs informatisations. A ce niveau, nous prconisons lutilisation du NFR
Framework afin dlaborer le CIM de chaque aspect de SdF.
Niveau indpendant de la plateforme : qui permet de modliser les paramtres retenus
de ltape prcdente en le raffinant encore plus pour chaque aspect et en les
rintgrant afin de dtecter leurs conflits mutuels et les rsoudre au niveau modle. A
ce niveau, nous prconisant lutilisation profil QoS-FT pour laborer les PIM de
chaque aspect.
Niveau spcifique la plateforme : qui permet dextraire des modles rsultants du
niveau prcdent pour constituer des modles spcifique pour chaque couche du SD.
ensuite pour faciliter leurs mises en uvre, ces modles vont tre tisss aux modles
fonctionnels afin de construire des modles intgrales prtes au dploiement et
implmentation.

121
Pour valuer lapplicabilit de notre mthode ainsi que son impact sur le SD cible, nous avons
utilis un cas dtude issu du monde de la sant. Ce cas sintresse llaboration dun
systme de Tableaux de bord pour les soins durgence ce qui sous-entend linteraction entre la
disponibilit et la scurit. Dans cette tude de cas nous avons trait chacun des aspects de
SdF et nous avons trait leur interaction chaque niveau en facilitant une traabilit des choix
retenues et leurs justifications. Et Enfin nous avons obtenu le system le plus proche des
exigences de SdF exprimes au dbut du cycle du dveloppement en lui intgrant leur
combinaison la plus optimale.
Il est important de souligner que la mise en uvre de notre approche nest quun scnario
parmi dautre. Ainsi dans chacun des niveaux, le choix est laiss au concepteur pour utiliser le
mtamodle ou le profil quil juge plus utile dans son cas en fonction de sa comptence et du
contexte dutilisation (Par exemple le profil MARTE est plus appropri pour les Systmes
temps rels etc.)

Pour conclure, nos travaux ont permis dtablir les premires briques vers la construction du
pont entre le domaine de la SdF et celui des SD. Ces briques quilibrent le compromis entre
linteraction des attributs de SdF et la particularit des SD.

5.2. Synthse des contributions


Notre proposition a pass par plusieurs tapes de validation scientifique qui la mis sous les
loupes des chercheurs du domaine afin de la corriger ou de proposer dventuels chemins de
concrtisation. Dans cette section, nous allons taler les diffrentes publications et
communications qui ont permis de dvelopper et faire avancer nos travaux de recherche pour
rpondre la problmatique cible.

1. Evaluation et Amlioration de la Fiabilit et de la Disponibilit des Systmes


Dcisionnels est une communication prsente la confrence Internationale Wotic
en 2011 Casablanca. Dans cet article, nous avons dcompos le SD selon ses quatre
couches : DS, ETL, DW, OR. Ensuite nous avons valu pour chaque couche les
problmes de fiabilit et disponibilit ainsi que les techniques existantes pour les
amliorer. Et nous avons dcouvert que lamlioration de disponibilit et la fiabilit
peut nuire la maintenabilit et la scurit. Ainsi, cet article nous a permis de
pouvoir formuler et justifier le fondement de notre problmatique qui consiste au
traitement des interactions des aspects de SdF dans le contexte des SD.
2. Adaptation des concepts de la sret de fonctionnement aux Systmes Dcisionnels
est une communication prsente au Workshop de Fouille de Donne FDO en 2012
Mekns. Dans cet article, nous avons redfinit les concepts de sret de
fonctionnement dans le contexte des SD, ensuite nous avons dress un tat de lart des
mthodes existantes pour amliorer chaque aspect et enfin nous avons ralis une

122
tude comparative afin dterminer limpact de chacune des techniques sur les autres
aspects de Sdf.
3. Toward a New Approach for Modeling Dependability of Data Warehouse System
est une publication au journal index (IJCSIS) International Journal of Computer
Science and Information Security Vol. 11, No. 6, ISSN: 1947-5500 en juin 2013. Cette
publication prsente notre approche globale qui se base sur le standard MDA afin de
prendre en compte la Sdf ds les premires tapes du dveloppement du SD et le
traitement des interactions entre ses aspects. Dans cet article, nous avons labor les
CIM et les PIM en prsentant respectivement le NFR Framework et le profil QoS-FT.

4. Transformation Rules according to MDA Approach for a Dependable Data


Warehouse System est une publication au journal index (IJARCSSE) International
Journal of Advanced Research in Computer Science and Software Engineering pp. 1-
6, Volume 3 issue 11 Novembre 2013 ISSN: 2277 128X. Cette publication
sintresse au mcanisme du passage dun niveau un autre en utilisant le principe des
transformations des modles. Ainsi une extension du meta modle NFR a t
propose pour faciliter la transformation du profil NFR au profil QoS-FT, et qui a t
crite par le langage ATL. Cet article a comme principal objectif de dmontrer la
traabilit des exigences dun niveau un autre.
5. Aspect-Oriented Method for Dependable Data Warehouse Systems based on MDA
Approach est une communication prsente la 4me IEEE Confrence
Internationale en Multimedia et Systmes (ICMCS) Marrakech le 14-16 Avril 2014.
Cet article prsente lintgration de la conception Oriente Aspect pour intgrer les
aspects de SdF aux SD au niveau conception, en proposant une solution pour
modliser les PSM.
6. Architecture Dirige Par Les Modles Pour Lintgration Des Exigences de La
Sret De Fonctionnement Aux Systmes Dcisionnels est une communication au
workshop des Technologies de lInformation et Modlisation Casablanca 31mai 2014,
qui prsente dune manire gnrale lintgralit de notre approche globale ainsi que
sa mise en uvre.

7. Dependable Decision Support System in Healthcare Context A Case Study of


Urgent Clinical Care Dashboard , est une communication prsente lInternational
Symposium on Ubiquitous Networking (UNET 2015), Casablanca September 08-10,
2015
8. An MDA Approach to Consider Dependability Requirements in Data Warehouse
System Development , est une communication prsente la conference
internationale sur les Avances des Systmes Dcisionnels (ASD 15), 10 11 et 12
septembre, 2015, Tanger, Morocco.

123
9. Considering Dependability Requirements in the Context of Decision Support
Systems: A Case Study of Urgent Clinical Care Dashboard est une communication
prsente au 12th ACS/IEEE International Conference on Computer Systems and
Applications (AICCSA 2015) le 17-20 November 2015, au Marrakech, Morocco.
IEEE Catalog Number: CFP15283-USB ISBN Number: 978-1-5090-0477-5

5.3. Perspectives
En termes des travaux exposs dans ce mmoire, nous affirmons quil y a plusieurs points
explorer ouvrant de nouveaux horizons pour de futurs sujets de recherche. Dans ce sens, nous
proposons dans le court terme de construire une base ontologique afin dunifier et dexpliciter
le sens exact des exigences non fonctionnelles de SdF et de prciser leurs liens et leurs
relations.

Ensuite, nous proposons dautomatiser notre approche en dveloppant des modules de


transformation de PIM en PSM et du PSM en code. Cette automatisation pourra seffectuer
via la dfinition des transformations de composition pour assurer lintgration pour chaque
niveau. Cette dernire sera plus intuitive avec lutilisation dun Add-in ou une extension
intgre un outil CASE (Computer-aided software engineering) qui permet de supporter la
modlisation de notre approche.
Dun autre ct, il sera intressant de raliser un benchmark de sret de Fonctionnement. Ce
dernier va permettre dinjecter des erreurs aux systmes dcisionnels et calculer les mtriques
propres aux aspects de SdF comme le MTTF, MTBR, etc. En plus, ce Benchmark va pouvoir
mieux valuer la SdF.
Dans le moyen terme, nous proposons de dmontrer la traabilit des exigences de SdF durant
les tapes de notre approche ainsi que sa portabilit et rutilisation. Et de penser dintgrer la
scalabilit comme paramtre qui influence directement la SdF des SD. En plus nous pensons
que llaboration dun profil UML propre la SdF va faciliter considrablement la mise en
uvre de notre approche.

Enfin, Dans le long terme, notre approche peut tre gnralise pour sappliquer sur nimporte
quel type de Systmes dinformation. Et linteraction vise par notre approche peut tre
rsolue par lutilisation des quations multi-objectifs issue du domaine de la programmation
linaire ou encore lapplication des principes de la thorie des jeux pour trouver la
combinaison optimale des attributs de SDF.

124
Bibliographie et Webographie

[1] L. Gaillard, M. De Lavalle, and J. Fauc, Les Systmes Dcisionnels, 1999.


[2] J. Lebraty, Les systmes Decisionnels, International Encyclopdie de linformatique
et des systmes dinformation. Vuibert, pp. 13381349, 2006.
[3] D. Mollard, Dcisionnel, Performance, Qualit, La Lettre dADELI, pp. 512, 2007.
[4] W. Inmon, Building the data warehouse, Third Edition, John Wiley & Sons, Inc., 2002.
[5] W. H. Inmon, The data warehouse and data mining, Communications of the ACM,
vol. 39, no. 11. pp. 4950, 1996.
[6] Ralph Kimball, The Data Warehouse Lifecycle Toolkit. 1998.
[7] P. Vassiliadis, C. Quix, Y. Vassiliou, and M. Jarke, Data warehouse process
management, Inf. Syst. J., vol. 26, no. 3, pp. 205236, 2001.
[8] E. Annoni lments mthodologiques pour le dveloppement des systmes
dcisionnels dans un contexte de rutilisation, thse soutenue Toulouse en 2007.
[9] C. Brard, Le processus de dcision dans les systmes complexes une analyse dune
intervention systmique, , 2009.
[10] A. F. Nodesway, Les fondamentaux du projet dcisionnel, 2009.
[11] A. Fernandez, Les nouveaux tableaux de bord des managers: le projet dcisionnel
dans sa totalit. Paris: Ed. dOrganisation, 2011.
[12] S. R. Gardner, Building the data warehouse, Communications of the ACM, vol. 41.
pp. 5260, 1998.
[13] R. Kimball, The Data Warehouse Toolkit The Complete Guide to Dimensional
Modeling. Wiley Second Edition 2002
[14] E. Codd, S. Codd, and C. Salley, Providing OLAP to User-Analysts: An IT Mandate,
1993.
[15] I. Gam El Golli, Ingnierie des exigences pour les systmes dinformation
dcisionnels: concepts, modles et processus - la mthode CADWE, Universit
Panthon-Sorbonne - Paris I, 2008.
[16] R. Kimball and V. Campillo, Concevoir et dployer un data warehouse. Paris Eyrolles,
2000.
[17] P. Russom, Next generation Data Warehouse Pl atforms Table of Contents, 2009.
[18] W. W. Eckerson, Data Quality And The Bottom Line Achieving Business Success
through a Commitment to High Quality Data, 2002.
[19] Dataflux A SAS Company, Data Integration: Moving Beyond ETL, 2010.
[20] Top Five Reasons Data Warehouse Projects Fail, 2008. [Online]. Available:
https://tmvilla.wordpress.com/2008/02/16/top-five-reasons-data-warehouse-projects-
fail/.

125
[21] C. Saran, Data warehouse and business intelligence projects fail to meet companies
requirements, http://www.computerweekly.com/, 2011. [Online]. Available:
http://www.computerweekly.com/news/1280095964/Data-warehouse-and-business-
intelligence-projects-fail-to-meet-companies-requirements.
[22] A. Avizienis, J. Laprie, and B. Randell, Fundamental concepts of dependability.
LAAS-CNRS, Technical Report N01145, Apr. 2001 2001.
[23] A. Aviienis, J. C. Laprie, B. Randell, and C. Landwehr, Basic concepts and
taxonomy of dependable and secure computing, IEEE Trans. Dependable Secur.
Comput., vol. 1, no. 1, pp. 1133, 2004.
[24] J. Laprie, Dependability of Computer Systems: from Concepts to Limits, in In
FTCS-25, the 25th IEEE International Symposium on Fault-Tolerant Computing-
Special Issue, 1995.
[25] GUILLERM Romaric, Intgartion de la Surtet de Fonctionnement dans les Processus
dIngnierie Systme, lUniversit Toulouse III Paul Sabatier, 2011.
[26] M2OS, Fiches mthodes, 2011.
[27] AFIS organisation, Ingnierie Systme, 2012. [Online]. Available:
http://www.afis.fr/nm-
is/Pages/Ing%C3%A9nierieSyst%C3%A8me/Ing%C3%A9nierie
Syst%C3%A8me.aspx.
[28] P. Zave, Classification of Research Efforts in Requirements Engineering, ACM
Comput. Surv, vol. 29, no. 4, pp. 315321, 1997.
[29] J. Buren and D. Cook, Experiences in the Adoption of Requirements Engineering
Technologies, 1998.
[30] I. Sommerville and P. Sawyer, Requirements Engineering: A Good Practice Guide, 1st
editio. John Wiley & Sons, Inc., 1997.
[31] M. Glinz, Quality requirements and their role in successful products, in Proceedings
15th IEEE International Requirements Engineering Conference, RE 2007, 2007, p. 21.
[32] B. Nuseibeh and S. Easterbrook, Requirements engineering: a roadmap, in ICSE 00
Proceedings of the Conference on The Future of Software Engineering, 2000, pp. 35
46.
[33] J.-A. Estefan, Survey of Model-Based Systems Engineering, in Model- Based
Engineering (MBSE) Methodologie.2013, p47.
[34] X. Blanc and O. Salvatori, MDA en action: Ingnierie logicielle guide par les
modles. Eyrolles edition 2011.
[35] J. Bzivin, Language engineering for model driven software development, in
Dagstuhl seminar, 2005.
[36] B. Combemale, Approche de mtamodlisation pour la simulation et la vrification de
modle -- Application lingnierie des procds, IRIT & ENSEEIHT, 2008.
[37] OMG, MOF. [Online]. Available: http://www.omg.org/mof/.

126
[38] S. Diaw, R. Lbath, and B. Coulette, Etat de lart sur le dveloppement logiciel bas
sur les transformations de modles, Numro spcial ISI - Ingnierie Dirige par les
Modles, vol. 29:45, p. 2, 2010.
[39] OMG, OMG, 2014. [Online]. Available: http://www.omg.org/. [Accessed: 20-Apr-
2001].
[40] OMG, MDA. [Online]. Available: http://www.omg.org/mda/.
[41] F. Bentayeb, O. Boussaid, N. Harbi, N. Kabachi, and S. Loudcher, Les entrepts de
donnes pour les nuls. . . ou pas!, in 2me Atelier aIde la Dcision tous les Etages
(EGC/AIDE 13), 2013.
[42] D. Calvanese, G. De Giacomo, and M. Lenzerini, Data integration in data
warehousing, Int. J. Coop. Inf. Syst., vol. 10, no. 03, pp. 237271, 2001.
[43] M. Golfarelli, From User Requirements to Conceptual Design in Data Warehouse
Design, in Data Warehousing Design and Advanced Engineering Applications:
Methods for Complex Construction, L. Bellatreche, Ed. IGI Global, 2009, pp. 118.
[44] S. Rizzi, A. Abell, J. Lechtenbrger, and J. Trujillo, Research in data warehouse
modeling and design, Proc. 9th ACM Int. Work. Data Warehous. Ol. - Dol. 06, p. 3,
2006.
[45] D. J. Power, Understanding data-driven decision support systems, Inf. Syst. Manag.,
vol. 25, no. 2, pp. 149154, 2008.
[46] I. Gam and C. Salinesi, A requirement-driven approach for designing data
warehouses, Requir. Eng. Found. Softw. Qual., 2006.
[47] J.-N. Mazn, J. Trujillo, and J. Lechtenbrger, Reconciling requirement-driven data
warehouses with data sources via multidimensional normal forms, Data Knowl. Eng.,
vol. 63, no. 3, pp. 725751, 2007.
[48] D. Batra, Conceptual data modeling patterns: Representation and validation, J.
Database Manag., vol. 16, no. 2, 2008.
[49] P. Vassiliadis, A. Simitsis, P. Georgantas, M. Terrovitis, and S. Skiadopoulos, A
generic and customizable framework for the design of ETL scenarios, Inf. Syst., vol.
30, no. 7, pp. 492525, 2005.
[50] P. Vassiliadis and A. Simitsis, Extraction, transformation, and loading, in
Encyclopedia of Database Systems, Springer, 2009, pp. 10951101.
[51] A. Simitsis and P. Vassiliadis, A method for the mapping of conceptual designs to
logical blueprints for ETL processes, Decis. Support Syst., vol. 45, no. 1, pp. 2240,
2008.
[52] D. Skoutas and A. Simitsis, Ontology-based conceptual design of ETL processes for
both structured and semi-structured data, Int. J. Semant. Web Inf. Syst., vol. 3, no. 4,
pp. 124, 2007.

127
[53] V. Tziovara, P. Vassiliadis, and A. Simitsis, Deciding the physical implementation of
ETL workflows, in Proceedings of the ACM tenth international workshop on Data
warehousing and OLAP, 2007, pp. 4956.
[54] M. Golfarelli and S. Rizzi, Data warehouse design: Modern principles and
methodologies. McGraw-Hill, Inc., 2009.
[55] M. Golfarelli, Data warehouse life-cycle and design, in Encyclopedia of Database
Systems, Springer, 2009, pp. 658664.
[56] P. Giorgini, S. Rizzi, and M. Garzetti, Goal-oriented requirement analysis for data
warehouse design, in Proceedings of the 8th ACM international workshop on Data
warehousing and OLAP, 2005, pp. 4756.
[57] I. Y. Song, R. Khare, and B. Dai, SAMSTAR: a semi-automated lexical method for
generating star schemas from an entity-relationship diagram, in Proceedings of the
ACM tenth international workshop on Data warehousing and OLAP, 2007, pp. 916.
[58] O. Romero and A. Abell, A framework for multidimensional design of data
warehouses from ontologies, Data Knowl. Eng., vol. 69, no. 11, pp. 11381157, 2010.
[59] V. Nebot and R. Berlanga, Building data warehouses with semantic web data, Decis.
Support Syst., vol. 52, no. 4, pp. 853868, 2012.
[60] R. Agrawal, A. Gupta, and S. Sarawagi, Modeling Multidimensional Databases, in
13th Intl. Conf. on Data Engineering (ICDE), IEEE Computer Society, 1997, pp. 232
243.
[61] A. Abell, J. Samos, and F. Saltor, Implementing operations to navigate semantic star
schemas, in 6th ACM Intl. Workshop on Data Warehousing and OLAP (DOLAP),
ACM Press, 2003, pp. 5662.
[62] T. S. Bach Pedersen, C. Jensen, and C. E. Dyreson, A foundation for capturing and
querying complex multidimensional data, in Information Systems (IS), vol.26(5), pp.
383423.
[63] E. Franconi and A. Kamble, The GMD Data Model and Algebra for Multidimensional
Information, in 16th Intl. Conf. on Advanced Information Systems Engineering
(CAiSE), LNCS 3084, 2004, pp. 446462.
[64] F. Ravat, O. Teste, R. Tournier, and G. Zurfluh, Algebraic and graphic languages for
OLAP manipulations, Intl. J. Data Warehous. Min. (IJDWM), Idea Gr. Publ., 2007.
[65] M. Riadh Ben, Couplage de lanalyse en ligne et de la fouille de donnes pour
lexploration, lagrgation et lexplication des donnes complexes, Universit
Lumire Lyon 2 (France).
[66] E. Lau and S. Madden, An integrated approach to recovery and high availability in an
updatable, distributed data warehouse, in Proceedings of the 32nd international
conference on Very large data bases, 2006, pp. 703714.

128
[67] M.-C. Hung, M.-L. Huang, D.-L. Yang, and N.-L. Hsueh, Efficient approaches for
materialized views selection in a data warehouse, Inf. Sci. (Ny)., vol. 177, no. 6, pp.
13331348, 2007.
[68] I. Mami and Z. Bellahsene, A survey of view selection methods, ACM SIGMOD
Rec., vol. 41, no. 1, pp. 2029, 2012.
[69] B. Ashadevi and R. Balasubramanian, Optimized cost effective approach for selection
of materialized views in data warehousing, J. Comput. Sci. Technol., vol. 9, 2009.
[70] S. Azefack, K. Aouiche, and J. Darmont, Dynamic index selection in data
warehouses, in Innovations in Information Technology, 2007. IIT07. 4th
International Conference on, 2007, pp. 15.
[71] S. Vanichayobon and L. Gruenwald, Indexing techniques for data warehouses
queries, Univ. Oklahoma, Sch. Comput. Sci. Tech. Rep., 1999.
[72] L. Bellatreche, R. Missaoui, H. Necir, and H. Drias, Selection and pruning algorithms
for bitmap index selection problem using data mining, in Data Warehousing and
Knowledge Discovery, Springer, 2007, pp. 221230.
[73] L. Bellatreche and S. Benkrid, A joint design approach of partitioning and allocation
in parallel data warehouses. Springer, 2009.
[74] A. Dimovski, G. Velinov, and D. Sahpaski, Horizontal partitioning by predicate
abstraction and its application to data warehouse design, in Advances in Databases
and Information Systems, 2010, pp. 164175.
[75] L. Bellatreche and K. Boukhalfa, An evolutionary approach to schema partitioning
selection in a data warehouse, in Data Warehousing and Knowledge Discovery,
Springer, 2005, pp. 115125.
[76] E. Ziyati, Optimisation de requtes OLAP en entrepts de donnes: Approche base
sur la fragmentation gntique, thse soutenue l'Universit Mohammed V-Agdal,
Facult des Sciences, Rabat, 2010.
[77] Z. Elhoussaine, D. Aboutajdine, and A. EL QADI, Algorithms for data warehouse
design to enhance decision-making, WSEAS Trans. Comput. Res., vol. 3, no. 3, pp.
111120, 2008.
[78] S. Wu, F. Li, S. Mehrotra, and B. C. Ooi, Query optimization for massively parallel
data processing, in Proceedings of the 2nd ACM Symposium on Cloud Computing,
2011, p. 12.
[79] T. K. Sellis and A. Simitsis, Etl workflows: From formal specification to
optimization, in Advances in Databases and Information Systems, 2007, pp. 111.
[80] A. Simitsis, P. Vassiliadis, and T. Sellis, State-space optimization of ETL workflows,
Knowl. Data Eng. IEEE Trans., vol. 17, no. 10, pp. 14041419, 2005.
[81] T. Jrg and S. Dessloch, Near real-time data warehousing using state-of-the-art ETL
tools, in Enabling Real-Time Business Intelligence, Springer, 2010, pp. 100117.

129
[82] L. Golab, T. Johnson, and V. Shkapenyuk, Scheduling updates in a real-time stream
warehouse, in Data Engineering, 2009. ICDE09. IEEE 25th International
Conference on, 2009, pp. 12071210.
[83] P. CHAPOUILLE, Maintenabilit. Maintenance, Enjeux Tech. la Maint., vol. base
docum, no. ref. article : t4305, p. 800, Dec. 2009.
[84] R. Kimball and M. Ross, The Kimball Group Reader: Relentlessly Practical Tools for
Data Warehousing and Business Intelligence. John Wiley & Sons, 2010.
[85] T. M. Nguyen, A. M. Tjoa, J. Nemec, and M. Windisch, An approach towards an
event-fed solution for slowly changing dimensions in data warehouses with a detailed
case study, Data Knowl. Eng., vol. 63, no. 1, pp. 2643, 2007.
[86] O. Rakotoarivelo and F. Bentayeb, Evolution de schma par classification
automatique pour les entrepts de donnes., in EDA, 2007, pp. 99112.
[87] H. Jain and A. Gosain, A comprehensive study of view maintenance approaches in
data warehousing evolution, ACM SIGSOFT Softw. Eng. Notes, vol. 37, no. 5, pp. 1
8, 2012.
[88] W. Oueslati and J.Akaichi, A Survey on Data Warehouse Evolution, proceeding des
ASD p. 14, Dec. 2010.
[89] E. Malinowski and E. Zimnyi, A conceptual solution for representing time in data
warehouse dimensions, in Proceedings of the 3rd Asia-Pacific conference on
Conceptual modelling-Volume 53, 2006, pp. 4554.
[90] M. Hsan, I. Zouari, F. Ghozzi, and R. Bouaziz, Extension of OLAP Operators to the
Multiversion Data Warehouse context, in International Arab Conference on
Information Technology (ACIT), 2010.
[91] J. Eder and K. Wiggisser, Data Warehouse Maintenance, Evolution and Versioning,
in Encyclopedia of Database Systems, Springer, 2009, pp. 664669.
[92] D. Solodovnikova and L. Niedrite, Evolution-oriented user-centric data warehouse,
in Information Systems Development, Springer, 2011, pp. 721734.
[93] G. Papastefanatos, P. Vassiliadis, A. Simitsis, and Y. Vassiliou, What-if analysis for
data warehouse evolution, in Data Warehousing and Knowledge Discovery, Springer,
2007, pp. 2333.
[94] C. Blanco, E. Fernndez-Medina, J. Trujillo, and M. Piattini, Data Warehouse
Security, in Encyclopedia of Database Systems, Springer, 2009, pp. 675679.
[95] S. Saroop and M. Kumar, Comparative Analysis of Data warehouse Design
Approaches from Security Perspectives, Int. J. Comput. trends Technol., 2011.
[96] A. Rosenthal and E. Sciore, View security as the basis for data warehouse security.
in DMDW, 2000, p. 8.
[97] S. Ahmad and R. Ahmad, An improved security framework for data warehouse: a
hybrid approach, in Information Technology (ITSim), 2010 International Symposium
in, 2010, vol. 3, pp. 15861590.

130
[98] M. Vieir, J. Vieir, and H. Madeir, Towards Data Security in Affordable Data
Warehouses, in 7th European Dependable Computing Conference (EDCC-7),
Kaunas, 2008, pp. 79.
[99] S. AZIZA and K. LAILA, Engineering of the Decisional Information System by the
reuse of patterns of patterns, INFOSID 2013.
[100] N. Prakash and A. Gosain, An approach to engineering the requirements of data
warehouses, Requir. Eng., vol. 13, no. 1, pp. 4972, 2008.
[101] L. Niedrite, D. Solodovnikova, M. Treimanis, and A. Niedritis, Goal-driven design of
a data warehouse-based business process analysis system, in Proceedings of the 6th
Conference on 6th WSEAS Int. Conf. on Artificial Intelligence, Knowledge Engineering
and Data Bases, 2007, pp. 243249.
[102] F. R. S. Paim and J. F. B. de Castro, DWARF: an approach for requirements
definition and management of data warehouse systems, in Proc. 11th IEEE Int. Conf.
Requirements Engineering, 2003, pp. 7584.
[103] F. Rilston, S. Paim, and J. F. B. Castro, Enhancing Data Warehouse Design with the
NFR Framework, in Proc. 5th Workshop on Requirements Engineering (WER2002).,
2002.
[104] F. Atigui, F. Ravat, O. Teste, and G. Zurfluh, Modlisation conjointe des donnes et
des processus pour limplantation de schmas dentrepts, J. Decis. Syst., vol. 21, no.
1, pp. 2749, 2012.
[105] F. Atigui, Approche dirige par les modles pour limplantation et la rduction
dentrepts de donnes,thse soutenue l'universit de Toulouse en 2013.
[106] A. Simitsis, Mapping conceptual to logical models for ETL processes, in
Proceedings of the 8th ACM international workshop on Data warehousing and OLAP,
2005, pp. 6776.
[107] A. Simitsis, P. Vassiliadis, M. Terrovitis, and S. Skiadopoulos, Graph-based modeling
of ETL activities with multi-level transformations and updates, in Data Warehousing
and Knowledge Discovery, Springer, 2005, pp. 4352.
[108] M. Pantoquilho and A. Moreira, Aspect-Oriented Logical Architecture Design A
Layered Perspective Applied to Data Warehousing Aspect-Oriented Architecture, in
Desarrollo de Software Orientado a Aspectos (DSOA2004), 2004.
[109] L. Zepeda, M. Celma, and R. Zatarain, A mixed approach for data warehouse
conceptual design with MDA, in Computational Science and Its ApplicationsICCSA
2008, Springer, 2008, pp. 12041217.
[110] A. Carm, J.-N. Mazn, and S. Rizzi, A model-driven heuristic approach for detecting
multidimensional facts in relational data sources, in Data Warehousing and
Knowledge Discovery, Springer, 2010, pp. 1324.
[111] J.-N. Mazn and J. Trujillo, An MDA approach for the development of data
warehouses, Decis. Support Syst., vol. 45, no. 1, pp. 4158, Apr. 2008.

131
[112] E. S. K. Yu, Towards modelling and reasoning support for early-phase requirements
engineering, in Requirements Engineering, 1997., Proceedings of the Third IEEE
International Symposium on, 1997, pp. 226235.
[113] L. Muoz, J.-N. Mazn, and J. Trujillo, Automatic generation of ETL processes from
conceptual models, in Proceedings of the ACM twelfth international workshop on
Data warehousing and OLAP, 2009, pp. 3340.
[114] L. Muoz, J.-N. Mazn, J. Pardillo, and J. Trujillo, Modelling ETL processes of data
warehouses with UML activity diagrams, in On the Move to Meaningful Internet
Systems: OTM 2008 Workshops, 2008, pp. 4453.
[115] Z. El Akkaoui, E. Zimnyi, J.-N. Mazn, and J. Trujillo, A model-driven framework
for ETL process development, in Proceedings of the ACM 14th international
workshop on Data Warehousing and OLAP, 2011, pp. 4552.
[116] Z. El Akkaoui, J.-N. Mazn, A. Vaisman, and E. Zimnyi, BPMN-based conceptual
modeling of ETL processes. Springer, 2012.
[117] E. Soler, V. Stefanov, and J. Mazn, Towards comprehensive requirement analysis for
data warehouses: Considering security requirements, Proc. 3rd Int. Conf. Availability,
Reliab. Secur., pp. 104111., 2008.
[118] X. Moghrabi, Lapproche model-driven architecture, crdible pour dvelopper un
progiciel de gestion intgr, Mmoire de DEA, Ecole des mines dAlbi, [en ligne ],
2003, 63 p., Disponible sur :http://noce.univ-
lille1.fr/cms/uploaddocs/Rapport_de_Stage_DEA_Informatique_ver_8.pdf.
[119] A. G. Kleppe, J. Warmer, and W. Bast, MDA Explained: The Model Driven
Architecture: Practice and Promise, vol. 32, no. 1. Addison-Wesley Longman
Publishing Co., 2003.
[120] I. Hilal, N. Afifi, R. F. Hilali, and M. Ouzzif, Toward a New Approach for Modeling
Dependability of Data Warehouse System, Int. J. Comput. Sci. Inform. Secur., vol. 11,
no. 6, pp. 4754, Nov. 2013.
[121] L. Chung and J. C. S. do Prado Leite, On non-functional requirements in software
engineering, in Conceptual modeling: Foundations and applications, Springer, 2009,
pp. 363379.
[122] A. Matoussi and R. Laleau, A Survey of Non-Functional Requirements in Software
Development Process, Dep. dInformatique Univ. Paris, vol. 12, 2008.
[123] S. Supakkul and L. Chung, A UML profile for goal-oriented and use case-driven
representation of NFRs and FRs, in Software Engineering Research, Management and
Applications, 2005. Third ACIS International Conference on, 2005, pp. 112119.
[124] S. Supakkul and L. Chung, Integrating FRs and NFRs: A use case and goal driven
approach, NFR framework, vol. 6, p. 7, 2005.

132
[125] B. Paech and D. Kerkow, Non-functional requirements engineering-quality is
essential, in 10th International Workshop on Requirments Engineering Foundation for
Software Quality, 2004.
[126] L. Chung and J. C. S. do P. Leite, On non-functional requirements in software
engineering, in Conceptual Modeling: Foundations and Applications, vol. 5600, A. T.
Borgida, V. K. Chaudhri, P. Giorgini, and E. S. Yu, Eds. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2009, pp. 363379.
[127] J. Aagedal, M. A. de Miguel, E. Fafournoux, M. S. Lund, and K. Stolen, UML profile
for modeling quality of service and fault tolerance characteristics and mechanisms,
TR 2004-06-01, OMG, 2004.
[128] J. . Aagedal, Quality of service support in development of distributed systems. PhD
thesis, University of Oslo, 2001. 2001.
[129] I. Kurtev, State of the art of QVT: A model transformation language standard, in
Applications of graph transformations with industrial relevance, Springer, 2008, pp.
377393.
[130] F. Jouault, F. Allilaire, J. Bzivin, I. Kurtev, and P. Valduriez, ATL: a QVT-like
transformation language, in Companion to the 21st ACM SIGPLAN symposium on
Object-oriented programming systems, languages, and applications, 2006, pp. 719
720.
[131] F. Jouault and I. Kurtev, Transforming models with ATL, in satellite events at the
MoDELS 2005 Conference, 2006, pp. 128138.
[132] J. Cabot and E. Teniente, Transformation techniques for OCL constraints, Sci.
Comput. Program., vol. 68, no. 3, pp. 179195, 2007.
[133] D. Wampler, Aspect-oriented design principles: Lessons from object-oriented design,
in Proc. 6th Int. Conf. on Aspect-Oriented Software Developement, 2007.
[134] S. Raut, A LITERATURE SURVE ON DATA WAREHOUSE SECURITY
ASPECTS, Int. J. Eng. Sci. Technol., vol. 3, pp. 3438, 2011.
[135] R. Laddad, Aspectj in action: enterprise AOP with spring applications. Manning
Publications Co., 2009.
[136] I. Krechetov and B. Tekinerdogan, Towards an integrated aspect-oriented modeling
approach for software architecture design, in 8th Workshop on Aspect-Oriented
Modelling (AOM.06), AOSD., 2006.
[137] J. Kienzle, W. Al Abed, and J. Klein, Aspect-oriented multi-view modeling, in
Proceedings of the 8th ACM international conference on Aspect-oriented software
development, 2009, pp. 8798.
[138] I. Krechetov, B. Tekinerdogan, A. Garcia, C. Chavez, and U. Kulesza, Towards an
integrated aspect-oriented modeling approach for software architecture design, in 8th
Workshop on Aspect-Oriented Modelling (AOM. 06), AOSD, 2006, vol. 6.

133
[139] A. Schauerhuber, W. Schwinger, E. Kapsammer, W. Retschitzegger, and M. Wimmer,
A survey on aspect-oriented modeling approaches, Technical report, Faculty of
Informatics, Vienna. 2007.

[140] B. Waters, Ciphertext-policy attribute-based encryption: An expressive, efficient, and


provably secure realization, in Public Key CryptographyPKC 2011, Springer, 2011,
pp. 5370.

134
Annexe A: DWEB (Data Warehouse Engineering Benchmark)
A.1 Prsentation de loutil dimplmentation : DWEB/ Oracle DW
DWEB : Data Warehouse Engineering Benchmark est un logiciel portable crit en Java. Il
permet en premier lieu dvaluer limpact de diffrents choix architecturaux ou de techniques
doptimisation sur les performances dun Entrept de donne.

Lobjectif de DWEB est de pouvoir modliser les grands types de schmas


multidimensionnels qui sont populaires dans les environnements ROLAP (Relational OLAP),
savoir les schmas en toile, en flocon de neige (avec des dimensions hirarchiques) et en
constellation (avec des tables de faits multiples et des dimensions partages). Pour cela, un
mtamodle dentrept de donnes est utilis ce qui permet dinstancier ces diffrents
schmas. ce mta modle peut par ailleurs tre vu lui-mme comme une instance du CWM
(Common Warehouse Metamodel) le mta modle standard de lOMG.
La gnration dentrept est totalement configurable, laide dun ensemble complet de
paramtres dits de bas niveau qui permettent de spcifier finement les caractristiques de
chaque table de faits, niveau hirarchique de dimension, etc. comme le montre la figure ci-
dessous.

Figure 47: Interface de connexion et de chargement du DW

135
Cependant, comme ce paramtrage trs fin peut savrer fastidieux et compliqu matriser
pour des schmas mme de taille moyenne. Un ensemble limit et plus grable de paramtres
de haut niveau est aussi fournis ce qui permet de calculer lensemble complet des paramtres
de bas niveau (ce sont des valeurs moyennes des paramtres de bas niveau). Les paramtres
de haut niveau incluent, par exemple, le nombre moyen de tables de faits, la densit moyenne
des faits, le nombre moyen de dimensions par table de faits, le nombre moyen de niveaux
hirarchiques dans les dimensions, etc.

A.2. Modle de charge


Le modle de charge de DWEB reprsente deux classes de requtes diffrentes : des requtes
purement dcisionnelles, qui comprennent les oprations OLAP classiques telles que la
construction de cube, le forage vers le haut ou vers le bas (roll-up ou drill-down,
respectivement) et la projection/slection (slice and dice) ; et des requtes dites dextraction
qui effectuent des jointures sur les tables de lentrept. Ce modle de charge permet de
gnrer des requtes la norme SQL-99, en fonction dun ensemble de paramtres tels que le
nombre total de requtes dans la charge, la proportion respective de requtes dcisionnelles et
de requtes dextraction, le nombre dattributs et de restriction dans une requte, etc.

A.3 Processus dETL


Puisque DWEB est un logiciel indpendant qui gnre des donnes et des charges, les mises
jour ralises par lETL sont effectues directement dans la base de donnes pour conserver
une certaine simplicit dusage loutil et minimiser la gestion de fichiers externes. Ces mises
jour pourraient cependant tre enregistres dans des fichiers avant dtre appliques pour
simuler lextraction. Ainsi, les transformations sont simules en consommant du temps
processeur (cest la tactique adopte par le clbre banc dessai TPC-DS). Dans DWEB, le
temps de traitement des tests divers effectus lors des procdures dinsertion et de
modification de donnes est quivalent ces transformations simules.

Dautre part, le chargement des donnes dans lentrept est effectu selon quatre cas
dutilisation en concevant les stratgies de rafrachissement correspondantes pour chacune :
insertions dans les tables de faits ; insertions dans les dimensions ; modifications dans les
tables de faits ; modifications dans les dimensions. Comme les donnes sont le plus souvent
historises dans un entrept, le cas des suppressions nest pas pris en charge. Ce modle
dETL est galement paramtr, avec le taux de rafrachissement global, les taux de
rafrachissement respectifs des tables de faits et des dimensions et la proportion dinsertions et
de modifications.

A.4 Protocole dexcution


Le protocole dexcution de DWEB est en fait une variante de celui de TPC-DS, qui est lui-
mme classique pour un banc dessais. Il est subdivis en deux parties : un test de chargement

136
qui consiste alimenter lentrept en donnes ; un test de performance qui value la rponse
du systme. Ce dernier est galement subdivis en deux tapes : une excution froid pendant
laquelle la charge est applique une fois sur lentrept test ; des excutions chaud rpliques
un certain nombre (paramtre) de fois et qui incluent chacune un rafrachissement de
lentrept et une excution de la charge.

Lunique mesure de performance retenue dans DWEB est actuellement le temps de rponse. Il
est calcul sparment pour les rafrachissements et les excutions de la charge de requtes,
de manire ce que chaque temps de rponse atomique puisse tre affich et/ou rutilis dans
une mesure de performance composite.

Les temps de rponses totaux, moyens, minimum et maximum, ainsi que les carts types, sont
galement calculs automatiquement.

A.5 Scnario dutilisation de DWEB


a. Interface de connexion

Linterface graphique principale de DWEB est reprsente dans la Figure ci-dessous. Elle est
divise en trois sections/panneaux : Database connection, qui permet la connexion tout tout
Systme de Gestion de Bases de Donnes Relationnel (SGBDR) via JDBC (Java Data Base
Connectivity) ; Action, qui permet de fixer la valeur des paramtres et de lancer les tests.

Figure 48: Cration des tables DW

137
Figure 49: message de fin de chargement d'un DW en prcisant sa dure en ms

b. Gnration de la charge (workload)

DWEB permet dans un premier temps de fixer les paramtres de la charge puis de
sauvegarder les requtes qui la composent dans un fichier externe de manire ce quelle
puisse tre rutilise dans des expriences ultrieures.
c. Test de performance
DWEB permet de fixer les paramtres du processus dETL et du protocole De son excution.
Le temps de rponse de chaque rafrachissement et excution de la charge est affich dans la
fentre de rsultats, et simultanment sauvegard dans un fichier CSV (Comma-Separated

Values) qui peut ensuite tre trait laide dun tableur ou de toute autre application
danalyse.

Figure 50: Exemple d'excution dune charge constitue de 100 requtes sur le DW de 22Mo

138