Université Hassan II – Casablanca Casablanca
Ecole Nationale Supérieure d’Électricité Et de Mécanique CED : Sciences de l’ingénieur
THESE En vue de l‟obtention du
DOCTORAT Formation Doctorale : Génie Informatique
Présentée Par : HILAL Imane
Conception et Intégration des Exigences de la Sûreté de Fonctionnement Dans les Systèmes Décisionnels
Présentée le 16 Janvier 2016, à 10h, devant le Jury :
Pr. Mounir RIFI
EST, Casablanca
Président
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 thèse
Pr. Mohammed Ouzzif
EST, Casablanca
Directeur de thèse
1
2
Remerciement Cette thèse est le fruit de longues années de travail effectuées au sein du Laboratoire RITM et en collaboration avec un corps professorale compétent, pour ce, je remercie beaucoup tout le corps administratif de l‟EST l‟EST,, plus particulièrement Mr le directeur de l‟EST Pr. Rifi Mounir RITM pour son aptitude à l‟écoute et pour sa qui est également le responsable du laboratoire RITM pour bienveillance.
rapporteurs : Pr. Haqiq Abdelkrim, Pr. Ziyati Houssaine, et Pr. Sadik Mohammed et monsieur l‟examinateur Pr Hicham Behja pour J‟adresse un grand remerciement aux avoir accepté d‟être membres du jury.
Je tiens à remercier particulièrement mon directeur de thèse Pr. Ouzzif Mohammed pour tous ses conseils et son soutien tout au long de ma thèse ainsi que pour sa disponibilité disponibilité et sa précieuse relecture relecture pendant la rédaction rédaction de ce manuscrit. Je remercie tous ceux avec qui j‟ai eu des discussions scientifiques très fructueuses pendant
ma thèse, 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 présent rapport qui m‟ont été de grande utilité.
Je tiens à exprimer ma reconnaissance et ma profonde gratitude à Pr. AFIFI Nadia, pour son accompagnement, accompagnement, ses compétences, sa gentillesse, et ses corrections.
3
4
Dédicace
A ceux qui ont sacrifié une grande part de leur vie pour ce travail : A ma chère mère et cher père. A ceux qui m’ont soutenu jusqu’à la fin : mes chères Sœurs Asmae et safae, et mon cher Mari.
A celle qui a épuisé son temps, énergie et effort : A ma chère Madame Afifi Nadia A ceux qui ont été la cause de l’abou tissement de ce travail : A mes collègues et amies
Veuillez m’excuser car j amais je ne pourrais vous rembourser une telle dette.
J ’espère que ce modeste travail soit à la hauteur de vos attentes et à l’ampleur de vos sacrifices.
A mon petit trésor Israa … ce mémoire t’est dédié !
5
Résumé Dans de nombreux domaines tels que la médecine, l‟E -commerce ou le militaire, les
systèmes décisionnels occupent une place prépondérante voir critique dans la pérennité des entreprises. Afin de pouvoir faire confiance à ces systèmes, leur développement doit répondre à des exigences de sûreté de fonctionnement. Ces dernières doivent être prises en compte durant tout le cycle de développement. Des solutions concrètes sont élaborées chaque jour pour parvenir à cet objectif. Elles sont basées sur la recherche et l‟implémentation de nouvelles approches de développement qui intègrent des concepts de sûreté de fonctionnement et guident les développeurs durant chaque étape nécessaire dans la production d‟un système
digne de confiance. Nos travaux de recherche s‟inscrivent dans une démarche d‟ingénierie des exigences. Ils consistent à mettre en place une méthodologie permettant d‟intégrer les exigences non
fonctionnelles de sûreté de fonctionnement dès les premières étapes du projet décisionnel. Dans ce sens, nous nous sommes appuyés sur une Architecture dirigée par les modèles (MDA : Model Driven Architecture) afin de modéliser les exigences de la sûreté de fonctionnement, à savoir la fiabilité, la disponibilité, la maintenabilité et la sécurité d‟une manière itérative et du plus haut niveau d‟abstraction jusqu‟à l‟implémentation. Ainsi, notre approche s‟intéresse dans un premier lieu à détecter les conflits éventuels entre les différentes exigences de la sûreté de fonctionnement. Et dans un second lieu, d‟assurer l eur raffinement et leur mise en œuvre en les intégrant aux exigences fonctionnelles en se basant sur les
concepts de la modélisation Orientée Aspect. Finalement, notre approche est concrétisée par une étude de cas qui la met en pratique et démontre son applicabilité et ses intérêts.
Mots clés : Système
décisionnel, Sûreté de fonctionnement, Architecture dirigée par les modèles, modélisation et programmation orientée 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 system‟s 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 modeldriven architecture (MDA) to model the dependability ‟s 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 dependability‟s 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 Données DW: Data Warehouse DWEB: Data Warehouse Engineering Benchmark ED: Entrepôt de Données ETL: Extraction Transformation Loading FT: Fault Tolerance IDM: Ingénierie Dirigée par les Modèles IE: Ingénierie des Exigences MDA: Model Driven Architecture, Architecture Dirigée par les Modèles 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: Systèmes Décisionnels 8
SI: Système d‟Information SdF: Sûreté de Fonctionnement SIG: Softgoal Interdependency Graph UCCD: Urgent Care Clinical Dashboard UML: Unified Modeling, Language
9
Table des matières I ntr odu cti on Gé né r ale ............................................................................................................. 16 Ch api tr e 1 : I ngé nierie des Exigences de l a Sûretéde F oncti onnement des Systè mes Dé cision nels ............................................................................................................................. 19 1.1
Introduction ........................................................................................................................ 20
1.2
Systèmes Décisionnels (SD) ............................................................................................... 20
1.2.1.
Fondement théorique des SD : De l‟informatisation à la décision ............................................... 20
1.2.2.
Mission et finalité .......................................................................................................................... 22
1.2.3.
Architecture standard .................................................................................................................... 24
1.2.4.
Cycle de vie d‟un projet décisionnel ............................................................................................. 25
1.2.5.
Problématiques des SD ................................................................................................................. 27
1.2.5.1
Au niveau des Sources de Données ..................................................................................... 28
1.2.5.2
Au niveau du processus Extraction Transformation Loading (ETL) .................................. 29
1.2.5.3
Au niveau de l‟Entrepôt de données (ED) ........................................................................... 29
1.2.5.4
Au niveau des outils de restitution (OR) .............................................................................. 30
1.3
Sûreté de Fonctionnement (SdF) ...................................................................................... 30
1.3.1
Définition 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
Méthodes d‟analyse de la SdF logicielle ....................................................................................... 33
1.3.3
Exigences de la SdF ...................................................................................................................... 33
1.4
Ingénierie des Exigences de la SdF des SD ...................................................................... 34
1.4.1
Ingénierie des exigences des Systèmes ......................................................................................... 34
1.4.1.1.
Ingénierie des systèmes ....................................................................................................... 34
1.4.1.2.
Ingénierie des Exigences (IE) .............................................................................................. 35
1.4.1.3.
Ingénierie des Exigences de la SdF ..................................................................................... 36
1.4.2
Dans le contexte des Systèmes Décisionnels ................................................................................ 37
1.4.2.1
Ingénierie des SD et leurs exigences .................................................................................. 37
10
1.4.2.2 1.5
Ingénierie des exigences de la SdF des SD .......................................................................... 37
Ingénierie Dirigée par les Modèles (IDM) ....................................................................... 38
1.5.1
Principes et intérêts ....................................................................................................................... 38
1.5.2
Architecture Dirigée par les Modèles (MDA) ............................................................................... 39
1.6
Synthèse .............................................................................................................................. 41
Chapitr e 2 : Etude de l’Etat de l’art ....................................................................................... 44 2.1
Introduction ........................................................................................................................ 45
2.2
Etat de l’art des Systèmes Décisionnels ............................................................................ 45
2.2.1
Sources de Données ...................................................................................................................... 45
2.2.2
Extraction Transformation Loading .............................................................................................. 46
2.2.3
Entrepôts de Données (ED) ........................................................................................................... 47
2.2.4
Outils de Restitution ...................................................................................................................... 48
2.2.5
Comparatif des travaux traitant les couches des SD ...................................................................... 49
2.3
Sûreté de Fonctionnement des Systèmes Décisionnels .................................................... 50
2.3.1
Disponibilité et fiabilité ................................................................................................................. 51
2.3.1.1
Techniques d'optimisation des requêtes ............................................................................... 51
2.3.1.2
Optimisation de l‟ETL ......................................................................................................... 52
2.3.2
Maintenabilité ............................................................................................................................... 52
2.3.2.1
Maintenance par mise à jour du modèle ............................................................................ .. 53
2.3.2.2
Maintenance par modélisation temporelle ........................................................................... 53
2.3.3
Sécurité.......................................................................................................................................... 54
2.3.4
Comparatif des travaux des attributs de sûreté de fonctionnement ............................................... 55
2.4
Approches de l’Ingénierie des exigences des Systèmes Décisionnels ............................. 56
2.4.1
Approche basée sur les Ontologies et notion du contexte ............................................................. 56
2.4.2
La méthode Computer Aided Data Warehouse Engineering......................................................... 56
2.4.3
Approche à base des patrons ......................................................................................................... 57
2.4.4
Approches à base du modèle de buts ............................................................................................. 58
2.4.5
Approche pour la définition et la gestion des SD (DWARF) ........................................................ 58
2.4.6
Comparatif des travaux dans le domaine des exigences des SD ................................................... 59
2.5
Approches Dirigées par les modèles dans le contexte des SD ........................................ 60
2.5.1
Méta modélisation ......................................................................................................................... 60
2.5.2
Approches spécifiques à l‟architecture MDA ...............................................................................
2.5.3
Comparatif des approches dirigées par les modèles dans le cas des SD ....................................... 63
61
11
2.6
Synthèse des travaux et positionnement de notre contribution ..................................... 64
Chapitr e 3 : Théorie de l’Approche Proposée ........................................................................ 69 3.1
Introduction ........................................................................................................................ 70
3.2
Les Modèles de l’approche MDA ..................................................................................... 70
3.2.1
Modèle Indépendant de la plateforme: CIM (Computation Independent Model) ......................... 72
3.2.2
Modèle d‟analyse et de conception abstraite : PIM (Platform Independent Model) ..................... 72
3.2.3
Modèle du code ou de la conception concrète : PSM (Platform Specific Model) ......................... 73
3.2.4
Transformation .............................................................................................................................. 74
3.3
Présentation de la méthode proposée ............................................................................... 74
3.3.1
Détails du mécanisme de l‟approche proposée .............................................................................. 74
3.3.2
Niveau des Exigences................................................................................................................... 76
3.3.3
Niveau Indépendant de la Programmation .................................................................................... 76
3.3.3.1
Présentation et intérêt du NFR Framework.......................................................................... 77
3.3.3.2
Mécanismes du NFR Framework ........................................................................................ 77
3.3.4
Niveau Indépendant de la Plateforme............................................................................................ 79
3.3.4.1 3.3.5
Profil QoS-FT ..................................................................................................................... 79
Transformations du CIM au PIM .................................................................................................. 80
3.3.5.1
Atlas Transformation Langage (ATL) ................................................................................. 80
3.3.5.2
Mécanisme de l‟ATL ........................................................................................................... 81
3.3.6
Niveau Spécifique à la Plateforme ................................................................................................ 81
3.3.6.1
Modélisation Orientée Aspect ............................................................................................. 82
3.3.6.2
Intérêt et mécanismes de l‟Orienté Aspect: ......................................................................... 82
3.4
Synthèse .............................................................................................................................. 83
Chapitr e 4 : Mise en Œuvre .................................................................................................... 85 4.1
Introduction ........................................................................................................................ 86
4.2
Niveau des Exigences ......................................................................................................... 86
4.2.1
Source de Données (DS) ............................................................................................................... 86
4.2.2
Extraction, Transformation, Loading (ETL) ................................................................................. 86
4.2.3
Entrepôt de Données (DW) ........................................................................................................... 87
4.2.4
Outils de Restitution (OR) ............................................................................................................. 88
4.3
Niveau Indépendant 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 sécurité ......................................................................................................................... 91
4.3.4
CIM intégrale de la SdF ................................................................................................................ 92
4.4
Niveau Indépendant 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 sécurité.......................................................................................................................... 95
4.4.4
PIM Intégral de la SdF .................................................................................................................. 95
4.5
Transformations du CIM au PIM .................................................................................... 97
4.6
Niveau Spécifique à la Plateforme .................................................................................... 99
4.7
Etude de Cas :
Système Décisionnel pour Tableaux de Bord des Soins d’Urgence
Cliniques ........................................................................................................................................ 101
4.7.1
Objectifs ...................................................................................................................................... 101
4.7.2
Méthodologie .............................................................................................................................. 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
4.8
Mise en oeuvre et validation ....................................................................................................... 108
4.7.4.1
Implémentation du Niveau des Exigences ......................................................................... 108
4.7.4.2
Implémentation du Niveau Indépendant de la Programmation .......................................... 108
4.7.4.3
Implémentation du Niveau Indépendant de la Plateforme ................................................. 111
4.7.4.4
Implémentation du niveau spécifique à la plateforme ....................................................... 113
4.7.4.5
Implémentation et résultats des tests.................................................................................. 115
Synthèse ............................................................................................................................ 117
Conclusion et perspecti ves .................................................................................................... 120 5.1.
Bilan des travaux réalisés ................................................................................................ 121
5.2.
Synthèse des contributions .............................................................................................. 122
5.3.
Perspectives ...................................................................................................................... 124
Bibliogr aphie et Webogr aphie .............................................................................................. 125 An nexe A: DW EB (D ata War ehou se En gin eer ing Benchmar k) ........................................ 135
13
Liste des Figures Figure 1: Position des SD dans l'Organisation ......................................................................... 22 Figure 2: Architecture classique d‟un SD ................................................................................ 24
Figure 3: Cycle de vie standard d'un projet décisionnel........................................................... 25 Figure 4: Enquête sur les raisons de renouvèlement des SD .................................................... 27 Figure 5: Chute de la performance causée par le volume croissant de données ...................... 28 Figure 6: Attributs, entraves et moyens de la sûreté de fonctionnement ................................. 32 Figure 7: Bases de l‟Ingénierie Dirigée par les Modèles ......................................................... 39
Figure 8: Description du méta modèle du MDA[118] ............................................................. 70 Figure 9: Processus de développement selon l‟approche MDA ............................................... 71 Figure 10: Démarche de l‟Approche Proposée ........................................................................ 75
Figure 11: Méthodologie de l'Approche................................................................................... 76 Figure 12: Exemple d‟un SIG
.................................................................................................. 78
Figure 13: Syntaxe abstraite des règles de transformation extraite du Métamodel ATL[131] 81 Figure 14: Mécanisme 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 sécurité ................................................................................................... 92 Figure 20: CIM intégrale de la SdF pour la détection 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 sécurité ................................................................................................... 96 Figure 24: PIM Intégral 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: Spécialisation du NFR Framework......................................................................... 98 Figure 28: Elaboration des PSM à partir du PIM Intégral ....................................................... 99 Figure 29: PSM SdF pour la couche DW .............................................................................. 100 Figure 30: tissage des aspects de SdF avec la partie fonctionnelle ........................................ 100 Figure 31: Modèle conceptuel des services technologiques .................................................. 103 Figure 32: Flux Conceptuel de Donnée .................................................................................. 105 Figure 33: CIM de disponibilité et fiabilité de l‟UCCD
........................................................ 109
Figure 34: CIM de Maintenabilité de l'UCCD ....................................................................... 109 Figure 35: CIM de la sécurité de l'UCCD .............................................................................. 110 Figure 36: Extrait du CIM Intégral simplifié ......................................................................... 110 Figure 37: PIM Fiabilité et Disponibilité ............................................................................... 111 Figure 38: PIM de la Maintenabilité ...................................................................................... 112 Figure 39: PIM de la Sécurité de l‟UCCD ............................................................................. 112
Figure 40: PIM intégral des SdF propre à la couche DW du system UCCD ......................... 113 Figure 41: PSM logique du DW de l'UCCD représenté par Diagramme de Composant....... 114 Figure 42: PSM architectural du DW de l'UCCD par Diagramme de Déploiement .............. 114 Figure 43: Temps de réponse du DW1 aux différentes charges de requêtes ......................... 116 Figure 44: Temps de réponse du DW10 aux différentes charges de requêtes ....................... 116 Figure 45: Temps de réponse de la charge de 20 requêtes aux différents volumes de DW ... 117 Figure 46: Temps de réponse de la charge de 100 requêtes aux différents volumes de DW . 117 Figure 47: Interface de connexion et de chargement du DW ................................................. 135 Figure 48: Création des tables DW ........................................................................................ 137 Figure 49: message de fin de chargement d'un DW en précisant sa durée en ms .................. 138 Figure 50: Exemple d'exécusion de la charge de 100 requêtes sur le DW de 22Mo ............. 138
15
Introduction Générale Contexte et Motivation Les systèmes informatiques d écisionnels (SD) sont aujourd‟hui l‟un des instruments d‟ai de à la décision qui se sont de plus en plus imposés surtout pendant et après la période de la crise économique. Cette dernière a stimulé le marché des outils d‟aide à la décision grâce à la demande croissante des entreprises pour des outils d‟analyse, de restitution et de consolidation. Le but escompté est d‟assurer leur pérennité
dans un contexte hautement
concurrentiel et incertain. Le SD, en Anglais référencé par DDS (Decision Support System), est définit comme étant un système qui apporte un appui et une aide à la décision. Cette dernière est une activité plutôt humaine dans le sens où elle est entamée par des acteurs humains suite à un processus complexe composé, entre autres, d‟expériences cumulées, de risques prévus et d‟interactions et réactions avec l‟environnement.
Ainsi, la mission du SD n'a jamais été d'automatiser la décision, mais plutôt d'automatiser la recherche et la présentation des informations utiles à la prise de décision. Son objectif principal est de combler la faiblesse des Systèmes d‟Informations (SI) classiques à fournir des informations transversales et selon différents axes d ‟analyse[1]. Cette faiblesse réside dans leur vocation transactionnelle et pointue qui alourdie et rend difficile la consolidation et la restitution des données [2]. En effet, ces dernières sont organisées d‟un point de vue opérationnel, et sont ainsi éparpillées de point de vue analytique. Le rôle crucial du SD dans la prise de décision impose un niveau de confiance assez élevé [3] afin de garantir sa sûreté de fonctionnement et donc pouvoir se fier aux informations qu‟il délivre. Dans ce sens, la mise en place d‟un SD repose, dans un premier temps, sur les exigences fonctionnelles de ses utilisateurs généralement non suffisantes pour la réussite du projet. En effet d‟autres facteurs l‟influencent, tels que : (i) le temps de réponse des requêtes complexes d‟analyse et la disponibilité du système, (ii) la fiabilité des données et du processus traitant, (iii) l‟évolution des besoins et leur maintenance et (vi) l‟assurance de règles de sécurité et d‟intégrité. La prise en compte de ces facteurs dès les premièr es étapes de projet de
SD tout en considérant leurs influences et leurs interactions, permettra d‟y attribuer une confiance meilleure et d‟assurer sa sûreté de fonctionnement. D‟un autre côté, les études de sûreté de fonctionnement permettent de traiter
plusieurs aspects non fonctionnels des systèmes, à savoir : la disponibilité, la fiabilité, la maintenabilité et la sécurité. Elles constituent ainsi un préalable indispensable à la conception d‟un système voulu
16
confiant pour comprendre et identifier les risques de sûreté des systèmes. Ensuite elles permettent de confronter et comparer les différentes solutions possibles afin de justifier, de façon rationnelle et démontrée, les choix d‟optimisation de l‟ architecture à proposer.
Problématique et contribution
Actuellement, dans le contexte académique des systèmes décisionnels, les aspects de sûreté de fonctionnement ont été déjà traités mais d‟une manière isolée et généralement lors des phases d‟implémentation physique du système. Plusieurs problèmes vont en découler: 1. Les exigences de sûreté de fonctionnement exprimées lors des premières phases ne sont pas traitées progressivement comme dans le cas des exigences fonctionnelles, ce qui dégrade considérablement leur traçabilité depuis l‟expression des besoins jusqu‟à l‟implémentation.
2. Les aspects de sûreté de fonctionnement interagissent ensemble soit en accord ou en conflit d‟intérêt et donc leur traitement doit prendre en compte cette interaction. 3. A notre connaissance, a ucune approche n‟est disponible pour spécifier , d‟une façon normalisée et unifiée, le traitement des aspects de sûreté de fonctionnement pour justifier les choix conceptuels, architecturaux et d‟implémentation dès les premières phases du projet décisionnel. Enoncée ainsi, la problématique de la SdF des systèmes décisionnels se traduit par la recherche d‟une méthodologie fondée et rigoureuse permettant d‟accompagner le projet décisionnel tout au long de son cycle de vie. Pour faire face à cette problématique, la thèse présentée dans ce document propose une approche de génie logiciel qui nous permettra de traiter les aspects de sûreté de fonctionnement en tenant compte de leurs interactions. Notre objectif est de guider la construction des systèmes décisionnels selon les exigences de sûreté de fonctionnement, en s‟appuyant sur deux principaux paradigmes : l ‟ingénierie dirigée par les modèles (en particulier , l‟architecture dirigée par les modèles MDA) et le développement logiciel orienté aspect. Ainsi, la MDA nous a permis d‟abord, de traiter les aspects de sûreté de fonctionnement en les séparant de toute plate-forme technique, puis de les raffiner progressivement du plus haut niveau d‟abstraction jusqu‟à l‟implémentation du code. Ce paradigme préconise l‟utilisation
des modèles comme entité de production au lieu de leur aspect contemplatif usuel. Dans ce sens, la MDA préconise l‟utilisation de trois modèles, à savoir : (i) CIM (Computation Independent Model) qui représente les besoins exprimés indépendamment de tout système informatique, (ii) PIM (Platform Independent Model) qui représente les besoins mais indépendamment de toute plateforme technique et enfin (iii) PSM (Platform Specific Model) qui représente les besoins mais cette fois ci spécifiques à une plateforme donnée.
17
D‟un autre côté, le développement logiciel orienté aspect va nous offrir tous les mécanismes nécessaires et suffisants pour intégrer les aspects de sûreté de fonctionnement -modélisés suivant la démarche MDA- dans le système en les tissant avec les parties fonctionnelles.
Organisation de la thèse Dans ce sens, les travaux réalisés dans le cadre de notre proposition sont présentés dans les quatre chapitres de ce mémoire : Le premier chapitre introduit et détaille toute la terminologie utilisée dans ce mémoire. L‟objectif est tout d‟abord d‟effectuer un cadrage du domaine de la thèse et de l‟inscrire dans son propre contexte scientifique et académique en précisant ses frontières Le deuxième chapitre présente une analyse bibliographique des différentes approches intersectées à notre axe de recherche en dégageant leurs points forts et leurs points faibles. Cette analyse va nous permettre de traiter la problématique énoncée et de justifier sa mise en étude. Le troisième chapitre expose les bases théoriques de l‟approche proposée pour traiter la problématique étudiée. Le quatrième chapitre va permettre de prouver l‟approche pr oposée par une mise en œuvre pratique et ensuite par une démonstration d‟un cas d‟étude. Cela permettra de valider les propos théoriques de l‟approche. Pour conclure, nous allons présenter une synthèse des travaux effectués en montrant leurs objectifs. Puis nous allons proposer quelques perspectives qui représentent la continuité de nos travaux de recherches.
18
Chapitre 1 : Ingénierie des Exigences de la Sûreté de Fonctionnement des Systèmes Décisionnels
« Comprendre c’est avant tout unifier. Vouloir, c’est susciter les paradoxes »
Albert Camus.
19
1.1
Introduction
Dans ce chapitre, nous allons introduire le concept des systèmes décisionnels en mettant l‟accent sur les problèmes généraux qui leur sont inhérents. Puis nous allons détailler spécifiquement ceux en relation avec la sûreté de fonctionnement. Dans cette perspective, ce chapitre est structuré suivant quatre sections. La première section est réservée à l‟introduction des systèmes décisionnels en les comparant avec les systèmes transactionnels, et en définissant ses notions clés qui seront utilisées tout au long de ce rapport. La deuxième section définit la sûreté de fonctionnement : ses attributs, ses moyens et ses entraves. La troisième section traite l‟ingénierie des exigences en détaillant ceux qui concernent la sûreté de fonctionnement dans le contexte des systèmes décisionnels. Enfin, la dernière section présente l‟approche sur laquelle se base notre contribution.
1.2
Systèmes Décisionnels (SD)
Cette section présente un historique et une confrontation des systèmes décisionnels avec les systèmes transactionnels. En plus, elle introduit les notions clés qui seront utilisées tout au long du mémoire. 1.2.1.
Fondement théorique des SD :
De l’informatisation à la décision
L‟informatisation des entreprises a d‟abord commenc é
par les applications dédiées pour automatiser la gestion des systèmes de production. Ainsi, toutes les applications permettaient la saisie et le traitement des données d‟une part, et la production en sortie de résultats sous forme de documents opérationnels non utilisables du côté du système du pilotage d‟autre part. Ces systèmes de production débordaient de données qui peuvent servir de base pour des analyses très utiles à la prise de décision. Cependant, ces systèmes étaient développés pour gérer des transactions élémentaires quotidiennes. Ils étaient optimisés conformément à cette finalité. Par conséquent, ils étaient loin de pouvoir répondre à la grande volumétrie de données, et à la complexité des traitements relatifs activités d‟analyse. D‟où le besoin d‟outils et de systèmes qui permettent de contourner cette limitation [1]. En effet, la finalité des systèmes opérationnels est de traiter de nombreuses requêtes simples mais de manière rapide. S on centre de gravité est particulièrement celui d‟une opération, alors que les applications d‟aide à la décision s‟intéressent à des ensembles d‟opérations sur des périodes de temps importantes et donc n‟ont pas les mêmes contraintes de temps de réponses
[2]. La présence des applications de production et d‟aide à la décision sur un même support informatique s‟est avérée très conflictuelle dans le sens de consommation de ressource. En effet, les applications d‟aide à la décision sont par définition très consommatrices de ressources et perturbent le temps de réponse des autres applications partageant avec elles le même support informatique. 20
Cette situation a donné naissance aux premiers infocentres (fin des années 70) [3] qui se sont contentés dans un premier lieu de dupliquer les données des applications de production dans un environnement séparé et dédié à l‟analyse. Ces infocentres mensuellement alimentés, ont apporté à l‟époque une poussée énorme aux entreprises en matière d‟analyse de suivi et de management des activités. Toutefois, ces outils étaient limités au traitement des données récentes et volatiles, et ne permettaient pas aux utilisateurs de travailler sur les historiques ou de faire des prévisions. Au fil du temps, les infocentres se sont avérés de plus en plus incapables de répondre aux besoins croissants des entreprises. Ces derniers exigeaient des outils plus performants pour accroître leur réactivité et anticiper les changements. Et grâce à l‟apparition de nouvelles technologies, les infocentres ont été vite dépassés laissant la place aux EIS [4] (Executive Information System) à partir des années 1990. Ces derniers étaient limités aux outils de tableaux de bord. Peu après, les systèmes décisionnels, appelés aussi systèmes d‟aide à la décision, ont vu le jour et sont considérés depuis comme étant le lieu de stockage des gros volumes de données devant être analysées. Les deux fondateurs de la théorie des systèmes décisionnels Kimball et Inmon définissent les systèmes décisionnels comme étant « un regroupement de données orientées sujets, intégrées, dépendantes du temps, non volatiles, ayant pour but d‟aider les gestionnaires dans leurs pris es de décision » [5],et « une copie des données transactionnelles organisées spécialement pour l‟interrogation et l‟analyse » [6]. Avec le temps, la maturité des SD a émergé des définitions plus élaborées. Une définition exemplaire est celle de Jark [7] qui le caractérise selon son architecture « il contient plusieurs couches de données dans lesquelles les données d‟une couche sont dérivées à partir d‟une
couche inférieure. Les sources de données forment la couche la plus basse et sont appelées des bases transactionnelles ». Celle de [8] qui le définit comme « un système qui réalise la collecte, la transformation des données brutes issues de sources de données et le stockage dans d‟autres espaces ainsi que la caractérisation des données résumées en vue de faciliter le
processus de prise de décision ». Les définitions précédentes soulignent le fait que la manipulation des données est le centre d‟intérêt des systèmes décisionnels. En effet, la prise de décision dans une organisation suscite un appui en termes d‟information et connaissance . Cet appui ne peut provenir que de l‟analyse du flux de données brutes manipulé par le système opérant ou/et des sources externes. Le schéma de la figure 1 permet de préciser avec exactitude la position du SD dans une organisation. Il a été largement inspiré du courant de « la pensée systémique (1970) » [9] qui est considéré parmi les premiers fondateurs de la notion de SI.
21
, n o i t a t n s e e i i g r é O t , a r s t n S o i s i c é D
Sys de pilotage D o n n é e P s,
Système décisionnel r o
In d u fo c r ti m o
Système d'information
n a ti o n d e
Système Opérant
Figure 1: Position des SD dans l'Organisation
Ainsi, l'organisation est un système composé de quatre sous-systèmes, à savoir: 1. Le Système Opérant : instrument de production qui incarne le métier ou la spécialité de l‟organisation. 2. Le Système d'Information : support informationnel du Système Opérant; il s‟alimente des données brutes du Système Opérant et permet l‟automatisation de ce dernier. 3. Le Système Décisionnel : traite les données brutes issues du SI pour en extraire des informations utiles au système de pilotage. 4. Le Système de Pilotage : détermine le comportement et l‟orientation stratégique et politique de l'organisation en se basant sur le flux informationnel remonté du Système Opérant. 1.2.2.
Mission et finalité
L‟évolution très rapide des technologies de l‟information et de la communication ainsi que l‟implémentation directe de l‟informatique dans la plupart des champs disciplinaires produit toujours plus de données, et multiplie les sources d‟informations. Ces sources sont disparates,
fortement évolutives et distribuées. Il en résulte que la prise de décision stratégique ou politique est de plus en plus complexe car elle dépend d‟une multitude de param ètres à prendre en compte. En plus elle impose une prise de décision rapide dans un contexte hautement concurrentiel. Et justement les systèmes décisionnels permettent à travers la collecte et l‟homogénéisation des données, de dégager et d‟analyser les indicateurs les plus
pertinents. Ces derniers vont être utilisés pour faciliter la prise de décision et le pilotage de l‟entreprise en maitrisant la signification et le devenir des informations présentes [10]. De plus, par l‟organisation multidimensionnelle des données et l‟accès transparent aux différentes sources de données hétérogènes, le SD tend vers une manipulation intuitive des
22
données par les décideurs. Autrement dit, il a pour objectif d‟augmenter l‟autonomie des
décideurs pour la réalisation de leurs analyses. Cette autonomie couplée aux données élaborées du SD, favorisent une réactivité efficace et une augmentation de la capacité de l‟organisation à s‟adapter aux éventuels changements de
contextes. Dans cette perspective, les besoins des utilisateurs des systèmes décisionnels peuvent être regroupés selon quatre grands axes : le suivi, le contrôle, l‟a nalyse et la simulation [11]. Le suivi : se base sur les fonctionnalités de reporting permettant de produire de façon rapide des tableaux de données incorporant des calculs plus ou moins simples (ex. production d‟état de vente journalière). Le contrôle : s‟appuie sur l‟élaboration de tableaux de bords à fréquence régulière en regroupant des données hétérogènes cohérentes (ex. les rapports des ventes trimestriels). L‟analyse : se base essentiellement sur les fonctionnalités OLAP (On Line Analysis Process) [12] pour établir des analyses multidimensionnelles de la donnée, voire même
de pousser l‟analyse en utilisant les techniques et algorithmes avancés de la fouille de
donnée (ex. l‟analyse des causes expliquant la chute inattendue du c hiffre d‟affaires d‟un produit ). La simulation : appelée aussi « What If Analysis» permet de se projeter dans le futur en injectant des paramètres d‟entrée dans des modèles spéciaux à la simulation (ex. l‟élaboration budgétaire). Pour répondre aux besoins de ses utilisateurs, le système décisionnel doit assurer cinq fonctions essentielles: [10] La collecte des données brutes à partir de leurs environnements d'origine moyennant des fonctions plus ou moins complexes de détection et de filtrage. Car un excédent de données, un défaut de fiabilité ou un trop mauvais rapport signal/bruit sont plus pénalisants que l'absence de données. L'intégration des données qui permet de les regrouper en un ensemble technique, logique et sémantique homogène malgré leurs sources hétérogènes. La diffusion ou la distribution d'informations élaborées à partir des données dans des contextes appropriés aux besoins des individus ou des groupes d‟utilisateurs. La présentation, qui détermine les conditions de mise à disposition de l'information (ex. contrôle d'accès, personnalisation, ergonomie, etc.); L'administration qui gère le dictionnaire de données et le processus d'alimentation de bout en bout, car même 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 différentes qui lui permettent d‟assurer ses fonctions. Le schéma de la figure 2 représente l‟architecture conventionnelle d‟un SD [13].
Figure 2:
Architecture classique d’un SD
Les données sont extraites grâce aux processus ETL (Extraction, Transformation, Chargement). Cette couche permet de nettoyer et d‟intégrer les données provenant des sources hétérogènes pour les consolider dans leur dépôt central, appelé entrepôt de données [12]. Par ailleurs, en raison de la complexité des analyses supportées par le SD, il est souvent associé à un autre concept qui est celui des systèmes OLAP. Plusieurs définitions sont présentées. La plus connue est celle énoncée dans le rapport technique de référence de Codd [14]. Elle met en avant la représentation multidimensionnelle des données et le caractère rapide et partagé des analyses de données. L‟auteur du rapport définit 18 règles appelées FASMI (Fast Analysis of Shared Multidimensional). Ces dernières correspondent aux fonctionnalités que doit assurer un système OLAP. D‟un autre côté, le SD a comme interface des flux d‟entrée, les systèmes opérants qui sont
généralement des systèmes OLTP (On Line Transaction Processing). Une comparaison entre les deux systèmes permet de dégager les caractéristiques intrinsèques [15] des SD et leur distinction par rapport aux systèmes transactionnels. Le tableau suivant résume ces différences.
24
Système OLAP Décisionnel ) Entrés
Système OLTP (Système opérant)
Systèmes hétérogènes
Application quotidienne
Donnée brute, non intégrée
Donnée détaillée
Insertion ou lecture modification est interdite Traitement
(Système
seule,
la
Tous les types de transactions
Transaction longue constituée requête Transaction courte constituée de complexe requêtes simples Grand volume de données orientées Données orientées application sujet
Sorties
Architecture
Peu d‟Utilisateur s : décideur, analyste.
Beaucoup d‟utilisateur s
Analyses multidimensionnelle historiques
Rapports prédéfinis quotidiens
et
Plusieurs couches
Une couche généralement
Maintenance fréquente offline
Maintenance moins fréquente
Disponibilité tolérable
Disponibilité critique
Fiabilité et sécurité critique
Fiabilité et sécurité exigée
Tableau 1: Comparaison entre système OLAP et OLTP 1.2.4.
Cycle de vie d’un
projet décisionnel
La particularité des SD détaillée dans les sections précédentes exige un cycle de vie différent des cycles de vie conventionnels. Le schéma présenté sur la figure 3 permet de le détailler [16].
Figure 3: Cycle de vie standard d'un projet décisionnel
25
a. La planification est réalisée interactivement avec la définition des besoins. Elle comprend la définition de la portée, de l‟identification, de l‟estimation et de l‟affectation des tâches. b. La gestion du projet assure la coordination des activités du projet. Elle comprend donc le suivi de l‟avancement et de l‟état du projet, le suivi des problèmes, le contrôle des changements (ex. portée du projet) et le développement du plan de communication. c. La définition des besoins est une phase critique nécessaire à la réussite d‟un projet. En effet, elle se concentre sur les utilisateurs et non sur les données afin d‟identifier les besoins les plus prioritaires et identifier les processus d‟affaires.
d. La modélisation des données se base sur le document de description des besoins pour
réaliser le modèle multidimensionnel, en identifiant des faits et leur granularité; les dimensions et leur hiérarchie; et les stratégies: de dénormalisation, de gestion des changements, etc. e. La conception physique utilise le modèle de données afin de préciser les détails du schéma relationnel (ex. clés, types, contraintes, etc.), les scénarios d‟optimisation de la performance (ex. indexes, partitionnement, agrégation, etc.), et la gestion de la sécurité. f. La conception de l‟architecture technique définit la vis ion d‟ensemble de la solution et l‟intégration des technologies du projet; en se concentrant sur les besoins et non sur les aspects techniques. E lle doit tenir compte de l‟environnement technique actuel et des directions stratégiques prévues. Dans ce sens, elle commence par l‟identification des besoins techniques, la création du plan d‟architecture pour enfin pouvoir faire la
sélection et l‟installation des produits en se basant sur le plan d‟architecture des produits: DBMS, ETL, reporting, analyse multidimensionnelle, forage de données, etc. g. La phase de la conception et du développement du système ETL représente environ 70% des efforts et risques du projet. Elle doit considérer le nombre et le type des sources de données et les outils disponibles. Cette opération se fait moyennant une identification et une analyse des sources de données, et en développant des méthodes d‟extraction, de nettoyage et de consolidation des données (code maison ou outils commerciaux) ainsi que des méthodes d‟insertion de donnée s et de validation de leur qualité. h. La conception et le développement des applications de BI se font en parallèle avec la modélisation des données et la co nception du plan d‟architecture. Leur objectif est de réaliser la modélisation des tableaux de bord, des rapports, des indices de performance (KPI) adaptés aux utilisateurs, la définition des modèles de prédiction, classification et clustering, la configuration des outils et des métadonnées, l‟implémentation du portail de navigation et la validation des applications. i. Le déploiement: constitue le point de convergence des activités de développement qui s‟intéresse à la formation des utilisateurs et la gestion des mécanismes de suivi 26
d‟erreurs. Il permet
de fournir la documentation complète après la validation de
données et outils. j. La maintenance et la croissance: assurent le fonctionnement optimal du système et prévoit l‟ajout de nouvelles fonctionnalités. Ces dernières comprennent le suivi de l‟utilisation et réglages de performance (tuning), la sauvegarde et la récupération des données, le support aux utilisateurs et la préparation de nouveaux cycles de développement. 1.2.5.
Problématiques des SD
Le système d‟information décisionnel a été développé dans l‟intention d‟homogénéiser des sources de données br utes et hétérogènes afin d‟en extraire des informations pour des fins d‟analyse, de suivi et de simulation. Son rôle crucial dans la prise de décision exige un degré de confiance assez élevé afin de pouvoir se fier aux informations qu‟il délivre.
La mise en place d‟un système décisionnel réussi doit dans un premier lieu reposer sur les exigences fonctionnelles de ses utilisateurs. Mais ces dernières ne sont généralement pas suffisantes pour la réussite du projet. La figure 4 représente le résultat d‟une enquête réalisée en 2009 par TDW Institut auprès d‟une centaine d‟utilisateurs des systèmes décisionnels [17]. Ils devaient répondre à la question suivante « pourquoi penserez-vous à renouveler votre système décisionnel ? »
Figure 4: Enquête sur les raisons de renouvèlement des SD
27
Les résultats de cette enquête mettent l‟accent sur le caractère non fonctionnel du système qui
influence directement son succès auprès de ses utilisateurs. En effet, la motivation de la mise en place des systèmes décisionnels dans la plupart des cas ne réside pas seulement dans sa finalité de fournir une information utile à la décision, mais également de tous les autres besoins non fonctionnels négligés ou mal formulés au début du projet. D‟après l‟enquête , plusieurs obstacles et problèmes sont exposés, et peuvent être synthétisés selon les quatre catégories suivantes : La performance du système qui est en général pénalisée par la complexité des requêtes exécutées, et par l‟alimentation continuelle du système et de la quantité de données importante (voir figure 5). L‟évolutivité du système du point de vue métier. En effet, les stratégies et les orientations des organisations peuvent changer, or ces dernières sont l‟une des bases de construction des SD. La scalabilité du système décisionnel qui doit gérer de plus en plus de flux de données et de requêtes nouvelles et complexes. Les choix techniques et technologiques qui deviennent inadéquats et ne supportent pas le caractère évolutif du système.
Performance
Data Growth
Figure 5: Chute de la performance causée par le volume croissant de données
Pour mieux cerner les problèmes communs rencontrés par tous les acteurs du système décisionnel, nous proposons de les lister par couche dans la section suivante. 1.2.5.1 Au niveau des Sources de Donné es L‟alimentation du système décisionnel s‟effectue à partir de plusieurs sources de données. Ces
sources peuvent se présenter sous différentes formes : structurées, semi structurées ou non structurées. Il peut s‟agir de fichiers "plats" (ex. fichiers CSV avec séparateurs, fichiers XML, fichiers ASCII, etc.) mais aussi de systèmes de bases de données (ex. MySQL, PostgreSQL, SQLServer, ORACLE, etc.), du contenu web ou des applications de veille technologique. Ces 28
sources de données sont donc en général hétérogènes et alimentent le système décisionnel par de grands volumes de données dont la qualité est à discuter. Les problèmes de qualité des données stockées s‟articulent en particulier autour des erreurs sur les données, de doublons, d‟incohérences et de valeurs manquantes, incomplètes, incertaines, obsolètes, aberrantes ou
peu fiables. Les conséquences de la non-qualité des données (ou de leur qualité médiocre) sur les prises de décision et les coûts financiers qu‟elle engendre sont considérables. Selon un rapport du TDWI [18] , elles sont de l‟ordre de 611 milliards de dollars par an pour l‟économie américaine. Ce problème s‟accentue encore plus avec la multiplication des sources d‟information disponibles et l‟accroissement des volumes de données potentiellement
accessibles. 1.2.5.2 Au n iveau du processus Extr action Tr ansfor mation L oadin g (ETL )
Le nettoyage de données par transformation ou ETL : Extraction- Transformation-Loading ( en français, Extraction Transformation et Chargement) fait partie du processus d‟amélioration de la qualité des données dans les systèmes décisionnels. Il consiste à choisir et à appliquer des transformations sur des jeux de données pour résoudre les différents problèmes de formats et d‟incohérences, d‟intégrités au sein d‟une même source ou entre
plusieurs sources de données à consolider. D‟un autre
côté, cette phase critique est responsable de l‟alimentation de l‟entrepôt de données et de son rafraichissement. Divers problèmes peuvent se manifester. Ils sont relatifs à plusieurs aspects : qualité et fiabilité des données manipulées, leur type et leur degré d‟hétérogénéité, le nombre des sources, les types de transformations effectuées et de la fréquence de rafraichissement de l‟entrepôt de données [19]. De ce fait, et pour alimenter l‟entrepôt de données par des données fiables tout en tenant compte des recouvrements, il est impératif de résoudre ces problèmes à ce niveau de l‟architecture. 1.2.5.3 es (ED) Au niveau de l’ E ntr epôt de don né L‟ED est conçu pour traiter une masse colossale d‟informations, enregistrer des millions d‟interactions quotidiennes, et réaliser
des segmentations pertinentes à partir de données
factuelles. Les problèmes des entrepôts de données s‟articulent généralement autour des données et des techniques de leur maintenance et optimisation. Tout d‟abord, la première difficulté à relever dans leur conception, consiste à leur définir un schéma. Contrairement aux systèmes OLTP, les données peuvent être représentées selon un schéma en étoile, en flocon ou en constellation en fonction des besoins d‟analyse et de la complexité des relations entre la table de Fait et les
dimensions d‟analyse. Ensuite, vient le problème de la volumétrie des données [20]. Ce
29
dernier est causé par le n ombre d‟enregistrements effectués, ce qui en découle le besoin des structures d‟optimisation à savoir les vue s, le partitionnement, les indexes, etc. D‟un autre côté, l‟ entrepôt
de données n‟est pas isolé car il interagit avec l‟ETL en entrée et avec les systèmes de restitution en sortie. Il est donc influencé par eux en terme de périodicité des chargements de donnée fournis par l‟ETL et par le nombre, la fréquence et la complexité
des requêtes demandées de la part des outils de restitution. Enfin tout comme les systèmes de bases de données, l‟ensemble des problèmes d‟accès et de la sécurité d‟une manière générale doivent être pris en compte. 1.2.5.4 Au ni veau des outi ls de r estituti on (OR)
Le premier problème invoqué lors de la phase de restitution est la diversité de ses outils. En effet, ces outils peuvent avoir plusieurs formes : Simples rapports permettant d‟effectuer des requêtes Ad hoc ou paramétrables. Tableaux de bord représentant l‟état d‟évolution des paramètres et indices émanant de
l‟entrepôt de données. Cubes OLAP permettant de naviguer dans les données suivant des axes d‟analyse en
variant leur niveau de granularité. Outils avancés de fouille de donnée (Data Mining) permettant d‟extraire des
informations poussées en appliquant des techniques avancées d‟analyse. Cette diversité engendre plusieurs problèmes en relation avec la complexité des requêtes, la volumétrie des données manipulées, le type de transformation réalisée, les contraintes du support (la mémoire centrale, le réseau et le CPU, etc.) [21]. Pour conclure, la mise en place d‟un système d‟information décisionnel de qualité n‟est donc pas simple et engendre des coûts et des efforts non négligeables. Ainsi, sa conception doit impliquer une analyse rigoureuse et approfondie des besoins métiers mais également tout élément qui assure sa sûreté de fonctionnement afin de pouvoir y attribuer le niveau de confiance nécessaire et suffisant pour accomplir son rôle. 1.3
Sûreté de Fonctionnement (SdF) 1.3.1
Définition des concepts de base
La sûreté de fonctionnement (notée SdF) est définie comme la propriété d‟un système permettant à ses utilisateurs de placer une confiance justifiée dans le service qu‟il leur délivre
[22]. 1.3.1.1.
Attributs
La SdF peut être étudiée selon des propriétés différentes mais complémentaires [23]: 30
La Disponibilité : (En anglais Availability) signifie le fait d'être prêt à l'utilisation. La Fiabilité : (En anglais Reliability) signifie la continuité de service. La Sécurité-innocuité : (En anglais Safety) signifie la non-occurrence de conséquences catastrophiques. La Confidentialité : (En anglais Confidentiality) signifie la non-occurrence de divulgations non-autorisées de l'information. L'Intégrité : (En anglais Integrity) signifie la non-occurrence d'altérations inappropriées du système. La Maintenabilité : (En anglais Maintainability) signifie l ‟aptitude aux réparations et aux évolutions.
L'association de la confidentialité, de l'intégrité et de la disponibilité, vis-à-vis des actions autorisées, conduit à la sécurité [22] (En anglais Security). 1.3.1.2.
Entraves
Les entraves à la sûreté de fonctionnement sont les fautes, les erreurs et les défaillances [24]. Une défaillance survient lorsque le service délivré n‟effectue plus la fonction à laquelle il est destiné. Une erreur est la partie de l‟état du système qui est susceptible d‟entraîner une défaillance. La cause adjugée ou supposée d‟une erreur est une faute. Les fautes et leurs sources sont extrêmement diverses. On peut les classer selon cinq points de vue : leur cause phénoménologique (fautes physiques ou fautes dues à l‟homme), leur nature (fautes accidentelles, fautes intentionnelles avec ou sans volonté de nuire), leur phase de création ou d‟occurrence (fautes de développement, fautes opérationnelles), leur situation par rapport aux frontières du système (fautes internes, fautes externes), et leur persistance (fautes permanentes, fautes temporaires). La considération simultanée de différents points de vue conduit à la notion de fautes combinées. Par exemple : les fautes de conception sont des fautes de développement accidentelles ou intentionnelles sans volonté de nuire. Les intrusions sont des fautes opérationnelles externes intentionnellement nuisibles. La distinction entre les différentes classes de fautes permet d‟identifier des moyens appropriés pour se prémunir contre ces fautes. 1.3.1.3.
Moyens
On distingue généralement quatre classes de moyens pour la sûreté de fonctionnement [24]:
Prévention des fautes : comment empêcher l'occurrence ou l'introduction de fautes. Tolérance aux fautes : comment fournir un service de accomplir la fonction du système en dépit des fautes. Elimination des fautes : comment réduire la présence (nombre, sévérité) des fautes. Prévision des fautes : comment estimer la présence, la création et les conséquences des fautes. 31
La prévention de fautes relève de l‟ingénierie “générale” des systèmes. Elle concerne le choix et la mise en œuvre d‟un ensemble de processus visant à maîtriser la conception, la réalisation
et la validation du système, et à assurer le bon fonctionnement du système durant son cycle de vie. La tolérance aux fautes vise à doter le système de mécanismes pour le traitement d‟erreurs (éliminer les erreurs avant qu‟une défaillance survienne) et le traitement de fautes (éviter qu‟une ou plusieurs fautes ne soient activées de nouveau). L‟élimination des fautes consiste à vérifier si le système satisfait les propriétés requises. Dans le cas contraire, il faut identifier les fautes et les corriger. Enfin, la prévision des fautes est conduite en effectuant des évaluations du comportement du système par rapport à l‟occurrence des fautes et à leur activation. La figure 6 synthétise les attributs, les moyens et les entraves de la sûreté de fonctionnement. Pour résumer, les attributs de la sûreté de fonctionnement (disponibilité, fiabilité, sécuritéinnocuité, confidentialité, intégrité et maintenabilité) correspondent aux propriétés du s ystème liées à la sûreté de fonctionnement. Ils permettent d‟apprécier la qualité du système vis-à-vis des services délivrés. Les entraves à la sûreté de fonctionnement (fautes, erreurs et défaillances) sont des circonstances indésirables qui causent ou résultent de la non-sûreté de fonctionnement du système. Pour combattre ces entraves et atteindre les niveaux souhaités des attributs, les moyens de la sûreté de fonctionnement vont être sollicités: la prévention des fautes, la tolérance aux fautes, l‟élimination des fautes et la prévision des fautes. Généralement, la sûreté de fonctionnement fait l‟objet d‟une validation par un organisme extérieur et indépendant de la structure qui a développé le système, surtout lorsque des vies humaines sont en jeux . Dans certains secteurs d‟activité (comme dans l‟aéronautique par exemple), il est question de certification, qui est un contrôle de qualité basé sur des normes.
Figure 6: Attributs, entraves et moyens de la sûreté de fonctionnement
32
1.3.2
Méthodes d’analyse de la SdF logicielle
la SdF se focalisent sur l‟analyse et l‟évaluation des failles d‟un logiciel et de préférence au début de son cycle de développement. Dans ce sens il est nécessaire de considérer la SdF comme un processus itératif qui doit être initié depuis la phase de l‟étude de faisabilité. Ce processus va s‟affiner durant les étapes de la phase d‟analyse et conception, et au fur et à mesure de l‟avance ment du processus, la SdF sera intégrée au logiciel durant l‟implémentation. Ainsi, il existe quatre approches différentes pour analyser la SdF logicielle [26]: Les méthodes d‟analyse de
Par les normes : approche qui se base sur les qualifications des entreprises de développement (ex : CMMI) ou des spécifications du produit logiciel selon le domaine ou le métier. Par les spécifications : se base sur l‟utilisation de l angages, outils ou méthodes permettant de construire l‟exhaustivité et la consistance des spécifications (ex. méthodes formelles et semi-formelles, UML, etc.) Par les moyens : se base sur des outils tels que l‟atelier de développement, ou des règles (ex. Misra). Par l‟analyse : se base sur la réalisation d‟études localisant et mesurant les risques (ex. A.E.E.L) Le mécanisme des méthodes de sûreté de fonctionnement consiste à analyser les défaillances du système, de ses sous-systèmes et de ses composants pour déterminer leurs causes et estimer leurs conséquences sur le service rendu par le système. Ces analyses peuvent être qualitatives ou quantitatives. E lles se conforment à l‟une des deux approches suivantes :
L‟approche inductive : correspond à un
raisonnement du particulier vers le général, où
l‟on recherche les effets d‟une défaillance sur le système ou son environnement.
L‟approche déductive : correspond à un raisonnement du général vers le particulier, où l‟on recherche les causes possibles d‟une défaillance. 1.3.3
Exigences de la SdF
une expression des besoins formulée de la part du client ou de toutes autres parties prenantes pour le système à développer. 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 représenter [25]: L‟exigence représente généralement
des contraintes globales de qualité de service. des aptitudes du système. des contraintes opérationnelles (conform ité à des normes d‟utilisation). des contraintes de conception (réutilisation d‟existant).
33
L‟intérêt principal d‟inscrire les
besoins en exigences réside dans l‟ambiguïté qui survient souvent dans cette phase et qui sera résolue à travers le urs formulations d‟un côté. De l‟autre côté, la finalité sera un support de communication entre les différentes parties prenantes du projet améliorant ainsi la collaboration et la traçabilité. Dans le cas de la sûreté de fonctionnement, celle-ci se focalise sur les quatre attributs déjà cités : la fiabilité, la disponibilité, la maintenabilité et la sécurité qui sont des propriétés non fonctionnelles du système, mais avant leur implémentation, elles sont aussi des exigences de sa qualité de service. La particularité des exigences de SdF concerne la définition des événements redoutés et leur hiérarchisation en fonction de leur criticité. Ainsi, une définition précisant des événements redoutés permet de spécifier sans ambiguïté les priorités visées et les objectifs donnés en termes de Disponibilité, de Fiabilité, de Maintenabilité et de Sécurité. Elle reflète la stratégie et le niveau de maîtrise des risques dans le cadre du projet. En même temps elle permet d‟attribuer une certaine confiance justifiée au système à développer.
Enfin, il faut noter que cette définition des événements redoutés ne peut garantir le gain estimé sans être inscrite dans le cadre d‟une démarche d‟ingénierie qui va assurer sa
normalisation et standardisation. Dans ce sens, la section suivante sert à inscrire l‟étude des exigences de la sûreté de fonctionnement des systèmes décisionnels dans un contexte d‟ingénierie.
1.4
Ingénierie des Exigences de la SdF des SD 1.4.1
Ingénierie des exigences des Systèmes
1.4.1.1.
I ngé nier ie des systè mes
L‟AFIS (Association Française d‟Ingénierie Système) qui est composée des entreprises et industriels comme Airbus, Alcatel, Renault, PSA Peugeot Citroën, France Télécom, EDF, RATP, et d‟autres, définit l‟Ingénierie Système comme étant [27] : « Une démarche méthodologique générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et vérifier un système apportant une solution économique et performante aux besoins d’un client tout en satisfaisant l’ensemble des parties prenantes ». L‟Ingénierie Système est le domaine qui permet au concepteur
de guider son développement de la meilleure manière possible. En fait, les objectifs principaux de cette science sont à l‟origine des problèmes affrontés qui sont souvent de même nature :
besoins insuffisamment exprimés. spécifications imprécises ou incomplètes. solutions non justifiées ou non validées. une formation des utilisateurs insuffisante. 34
des ressources et compétences mal planifiées.
Autrement dit, l‟Ingénierie Système est une approche méthod ologique
qui a été développée pour permettre aux concepteurs d‟aboutir à une solution équilibrée selon le meilleur des coûts et des délais. Elle répond au mieux aux besoins des différentes entités concernées par l‟utilisation du système. Dans un autre volet, Lorsque l‟on traite de l‟Ingénierie Système, il est incontournable de
considérer le cycle de développement du système et son cycle de vie. En effet, la méthodologie suivie en impliquant l‟ingénierie système affecte le cycle de développement du
le suivre et le contrôler durant son cycle de vie depuis s on exploitation, maintenance jusqu‟à son retrait de service. système depuis l‟expression des besoins jusqu‟au déploiement. Pour ensuite
1.4.1.2.
I ngé nieri e des Exi gences (I E)
une partie très importante de l‟ingénierie système. Elle traite toutes les activités liées aux exigences telles que leur définition, leur traçabilité, leur modification, leur gestion en terme de maturité, etc. L‟une des définitions les plus claires de l‟ingénierie des exigences est proposée par [28]: L‟ingénierie des exigences est
« L’ingénierie de s exigences est la branche du génie logiciel qui concerne les buts réels, les fonctions et les contraintes d’un système logiciel. Elle concerne aussi la relation que ces facteurs entretiennent avec les spécifications précises du comportement logiciel, et avec leur évolution dans le temps et à travers les familles de logiciels.» Selon cette définition, l‟ingénierie des exigences est le processus de découverte de cet objectif
en identifiant, analysant et documentant les parties prenantes et leurs besoins. Les exigences sont donc l‟expression d‟un besoin documenté sur ce qu‟un système ou un logiciel devrait être
ou faire. Les parties prenantes quant à elles désignent des personnes, des organisations ou des systèmes ayant une interaction directe ou indirecte avec les exigences. Gérer les exigences [29] dans un projet est une activité fondamentale à son bon déroulement. En effet, un nombre important de documents peut être produit lors de la conception d‟un système. Sans l‟ingénierie des exigences, il serait quasiment impossible de garantir la
cohérence et la qualité nécessaire au succès du projet. Effectivement, des études statistiques [30] ont montré que les exigences interviennent pour environ 40% du succès ou de l‟échec d‟un projet, d‟où leur importance vis -à-vis de notre préoccupation. Ainsi, l‟ingé nierie des exigences permet de [25]: Collecter les exigences. Faciliter leur expression. Détecter les incohérences entres elles. Les valider.
35
Gérer leur priorité (les hiérarchiser). Gérer les changements d‟exigences. Gérer la qualité. Faire le lien avec le reste du projet et/ou avec le contexte. Et encore assurer leur traçabilité.
L‟ingénierie des exigences doit aussi veiller à ce que chaque exigence soit correctement
déclinée, allouée, suivie, satisfaite , vérifiée et justifiée. Nous saisissons bien l‟import ance de l‟ingénierie des exigences dans un projet, pour sa réussite, et donc pour garantir que le
système conçu répondra bien aux besoins exprimés. Tout écart vis-à-vis du respect des exigences pourra être à l‟origine d‟un fonctionnement non -souhaité. 1.4.1.3.
I ngé nierie des Exigences de la SdF
Dans un autre niveau, l‟ingénierie des exigences impose une distinction importante entre les
exigences fonctionnelles et les exigences non-fonctionnelles, notées NFRs ( Non-Functional Requirements en anglais) [31]. Les exigences fonctionnelles se réfèrent aux services que le futur système doit fournir tandis que les NFRs se limitent à la manière dont ces services doivent être fournis. Mais, il faut soulever que l‟analyse des NFRs n‟est pas toujours évidente puisque généralement il est difficile de les exprimer d‟une façon objective et mesurable, comme le souligne [32] . D‟autant plus que, les NFRs sont connues pour leur caractère conflictuel. Par exemple, l‟utilisation d‟un double mot de passe augmente la sécurité des
données, mais elle a des impacts négatifs sur les performances du système (ralentir le système) et l‟utilisabilité. Ainsi, les NFRs touchent beaucoup d‟aspects tels que la performance, les contraintes de
conception, les attributs de qualité, et par conséquent la sûreté de fonctionnement. C‟est dans ce cadre que l‟ingénierie des exigences de la SdF a émergé récemment grâce à la monté en complexité des systèmes. Cette monté a stimulé la naissance de plusieurs méthodologies d‟ingénierie système afin de se concentrer sur la prise en compte de leurs sûreté depuis le début du processus de conception. Plusieurs de ces méthodologies se sont basées sur des modèles pour détecter et corriger tôt les fautes de conception (lorsque les coûts de modification sont encore faibles). L‟idée est centrée sur l‟analyse des risques dans le processus de conception, au lieu d‟être
considérée comme une activité séparée. Ces méthodologies ont facilité la traçabilité des exigences, la vérification des différentes propriétés du système (dont la fiabilité), et enfin la réduction des coûts d‟une modification et d‟une ré -analyse du système.
36
1.4.2
Dans le contexte des Systèmes Décisionnels
1.4.2.1
I ngé nierie des SD et leurs exi gences
à l‟ingénierie des exigences, qui sont des disciplines déjà bien établies avec des méthodes, des techniques et des outils reconnus dans la recherche et l‟industrie, l‟ingénierie des SD est une discipline nouvelle [15]. Elle n'offre pas encore des approches reconnues et standards. Les premières préoccupations de l‟ingénierie des SD ont concerné le niveau technique du SD comme il a été montré dans [15]. Comparativement à l‟ingénierie des systèmes et
Ainsi, les approches existantes sont établies pour décrire le choix des sources de données qui alimentent le système, les processus ETL, ou bien l'architecture et la modélisation des entrepôts de données et/ou des Data Mart métier. Ceci peut être expliqué par la particularité de sa mise en place. Car, quand un projet décisionnel est lancé, et ses exigences sont exprimées, plusieurs problèmes et enjeux internes et externes (qui sont déjà cité dans la section 1.2.5) peuvent provoquer l‟échec de sa mise en place si elles ne sont pas prises au sérieux le plus tôt possible. D‟un autre côté, les exigences du SD peuvent être de quatre types: les exigences stratégiques reliées à la stratégie de l‟organisation, les exigences tactiques reliées à une perspective, les
exigences opérationnalisables reliées à l‟information recherchée et les exigences système reliées au système à concevoir. Ces quatr e types d‟exigences sont répertoriés en deux niveaux : le niveau intentionnel et le niveau opérationnel selon [15]. 1.4.2.2
I ngé nierie des exi gences de la SdF des SD
En tenant compte du rôle crucial qu‟il joue dans la prise de décision, le SD doit justifier
un certain niveau de sûreté de fonctionnement suffisant pour pouvoir lui faire confiance. Cependant, nous avons démontré dans les sections précédentes (cf. partie 1.2), que les SD souffrent de problèmes qui sont souvent liés à leur sûreté de fonctionnement. Les exigences de SdF sont implicites, et difficiles à recueillir auprès de ses utilisateurs qui sont souvent non informaticiens (Décideurs, Auditeurs, Analystes, etc.). De ce fait, ils sont négligés dans la plupart des cas jusqu‟à la mise en place du système. les études de sûreté de fonctionnement permettent de traiter plusieurs exigences non fonctionnelles en constituant un préalable à la conception de tout système selon le niveau de tolérance acceptable et exigé pour sa sûreté de fonctionnement. Elles permettent D‟un autre côté,
de comprendre, d‟identifier et d‟hiérarchiser les risques pour optimiser l‟architecture des
systèmes et comparer les différentes solutions afin de justifier les choix retenus de façon rationnelle et démontrée. Cette situation prouve la nécessité de la définition d‟une approche qui permet d‟intégrer les exigences de SdF au SD depuis les premières étapes de son cycle de développement. Son
37
objectif est d‟en tenir compte le plutôt possible afin de résoudre leurs interactions mutuelles et d‟assurer la conception et la réalisation d‟un système réaliste et réalisable sur des bases méthodologiques méthodologiques solides. 1.5 Ingénierie Dirigée par les Modèles (IDM) 1.5.1
Principes et intérêts
Lors du développement d‟un système, de nombreux domaines d‟expertise peuvent
travailler
ensemble, coopérer et collaborer en vue d‟obtenir une solution satisfaisante. L‟ingénierie
système a pour rôle de faire cohabiter toutes ces disciplines en les intégrant au sein d‟un même ensemble de processus. La tâche n‟est pas évidente, surtout lorsqu‟il s‟agit de faire
communiquer tous les acteurs. Le moyen le plus sûr et contenant le moins d‟ambigüités et de divergences de compréhension reste sans aucun doute l‟utilisation et le partage de modèles [33]. Le concept de modèle reste en fait indissolublement lié à celui de système. Du fait de la complexité du système matérialisée par leur hétérogénéité Pour cela, il semble nécessaire de s‟appuyer sur un langage commun.
et leur pluridisciplinarité, l‟esprit humain n‟appréhende la complexité qu‟en la modélisant. En effet, comprendre ou concevoir ne revient qu‟à créer des modèles mentaux. Agir ou réaliser n‟est rien d‟autre que de se conformer aux modèles que l‟on a construits. C‟est dans ce sens q ue
l ‟approche dirigée par les le s modèles nous avons choisi de procéder par l‟approche (IDM) afin de guider la mise en place d‟un SD et en tenant compte de aspects de sûreté de fonctionnement. En effet, l‟ingénierie dirigée par les modèles préconise l‟utilisation des modèles comme entité centrale. Cette approche a contribué en une montée en puissance des modèles qui ont passé de leur stade contemplatif (visuel et documentaire) à un stade plus productif qui envisage l‟utilisation des modèles au cœur du cycle de développement de ces systèmes [34]. Avec cette approche, le code final exécutable n‟est plus considéré comme l‟élément central Ŕ qui dans le processus de développement mais comme un élément Ŕ naturellement naturellement important Ŕ qui résulte d‟une transformation de modèles. Dans [35], cette transformation de modèles est définie comme la génération d‟un ou de plusieurs modèles cibles à partir d‟un ou de plusieurs modèles sources. Dans l‟IDM, un modèle peut être défini simplement comme une représentation ou une
le monde de la programmation, un programme exécutable représente le système alors que le code source de ce programme représente le modèle. De cette première définition découle une nouvelle relation appelée « represents » reliant le modèle et le système s ystème modélisé [35]. abstraction d‟une partie d‟un système. Par analogie avec
En poursuivant l‟analogie avec le monde de la programmation, un programme est écrit
ou est exprimé dans un langage de programmation. Un modèle est écrit ou est exprimé dans un 38
langage de modélisation. Dans le contexte de l‟IDM, la définition d‟un langage de modélisation a pris la forme d‟un modèle, appelé métamodèle [36]:
On dit aussi que le métamodèle représente ou modélise le langage. Il résulte de cette deuxième définition une nouvelle relation appelée “conforms-to“ qui lie le modèle et son métamodèle. A titre d‟exemple, le métamodèle d‟UML offre des concepts permettant de décrire les différents modèles (diagramme de classes, diagramme de cas d‟utilisation, etc.) d‟un système.
Toujours par analogie avec le monde de la progra mmation, on dira qu‟un langage de programmation respecte la grammaire BNF. Il résulte de cette définition une troisième relation, également appelée “conforms-to“, qui relie le métamodèle à son méta- métamodèle. Le méta-métamodèle est un langage d‟expression de métamodèles (par exemple le métamétamodèle de MOF [37]). La Figure 7 ci- après résume ces notions de base dans l‟IDM.
Figure 7: Bases de l’Ingénierie D irigée par les Modèles
L'IDM a pour principal objectif de relever un certain nombre de défis du génie logiciel (qualité, productivité, sûreté, séparation des préoccupations, coût, etc.) en suivant une approche à base de modèles dite générative. En focalisant le raisonnement sur les modèles, l‟IDM permet de travailler à un niveau d‟abstraction supérieur et de vérifier sur un e maquette numérique (ensemble de modèles qui traitent divers aspects d‟un système) un ensemble de propriétés que l‟on devait vérifier auparavant sur le système final [38]. Le plus important des
avantages du travail sur maquette numérique au lieu du traditionnel code logiciel, se résume dans le fait de fournir un référentiel central permettant à plusieurs acteurs de s'intéresser aux différents aspects du système (sécurité, performance, consommation, etc.). 1.5.2
Architecture Dirigée par les Modèles (MDA)
La naissance du MDA a été motivée par la complexification des systèmes systèmes d'information et des forts coûts 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 intérêts se résument dans les points suivants [40][34] : a. Séparation entre logique métier et technologie
L'histoire des systèmes d'information a connu de nombreuses évolutions que ce soit au niveau des langages de programmation (procéduraux et fonctionnels, événementiels, orientés objet, services web, etc.), des middlewares (propriétaires, CORBA, DCOM/COM+, RMI, etc.) ou des méthodes de conception (SADT, Merise, les méthodes Orientées Objet, etc.). De plus, la diversité des solutions pour résoudre un même problème ne cesse d‟augmenter . Dans ce contexte, les chefs d'entreprise ne veulent plus investir dans un middleware dont la pérennité est courte. courte. Avec CORBA, l'OMG pensait fournir une norme suffisamment puissante et ouverte pour répondre à tous les besoins. Le consortium pensait que CORBA deviendrait ainsi le middleware standard universel à l'instar d'UML comme formalisme de modélisation. Cependant des architectures différentes se succédèrent, obligeant les entreprises à former leurs ingénieurs et à remettre à jour leurs applications. Toutefois, lors d'une migration d'une infrastructure vers une nouvelle technologie, la logique métier de l'application reste la même et généralement change très peu. Il est donc évident de tenter de différencier l'architecture technique dépendant de la technologie utilisée de celle de la logique métier. L'intérêt est de favoriser l'évolutivité, la réduction de coût et l'interopérabilité. Pour aller dans ce sens, les grandes compagnies informatiques ont ressenti le besoin de standardiser les différentes tentatives. Elles ont donc logiquement chargé le consortium de l'OMG de la mission de définir une norme indépendante 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 réalisé douze ans après la création de l'OMG. La recherche de l'interopérabilité entre systèmes d'information ne peut être atteinte uniquement grâce à la standardisation des infrastructures de middleware, mais par une approche beaucoup plus globale où la notion de modèle devient essentielle et centrale [5]. Pour résumé, l'OMG déclare que la guerre des middlewares est terminée. Des acteurs divers proposent des middlewares hétérogènes auxquels ils sont attachés. Par conséquent, conséquent, il ne servirait à rien d'essayer d'imposer un ultime ult ime middleware. Cette analyse de la situation n'est pas nouvelle puisque l'OMG avait défini des ponts pour passer de CORBA vers d'autres plates-formes. Toutefois, selon ce groupe, cette solution ne pouvait représenter représenter un objectif réaliste de long terme, ni être à la base d'une stratégie stratégie [6].
40
c.
Montée en abstraction
La stratégie de la MDA se démarque des anciens standards en se positionnant clairement à un niveau d'abstraction supérieur et en mettant le projecteur non plus sur les approches à objets mais sur les approches à modèles de composants [7]. Le but est de favoriser l'élaboration de modèles de plus haut niveau d'abstraction et des approches de transformation vers les platesformes techniques. Ceci signifie qu'il sera possible de définir un modèle métier totalement indépendant des plates-formes techniques et de générer du code spécifique à la plate-forme d'implémentation. L‟initiative MDA
repose sur un changement de paradigme important dans le domaine du génie logiciel. La rapidité de cette évolution s'explique par trois facteurs au moins. Le premier facteur est la nécessité de découpler les éléments du logique métier, qui sont souvent stables, de la logique des supports technologiques informatiques considérés évolutives dans le temps. Cette évolution logicielle de caractère non conjoncturel, inéluctable et perpétuel ne va pas se ralentir. Toutefois, elle ne doit pas pénaliser la capitalisation logicielle du savoir et du savoirfaire de l'entreprise. Le deuxième facteur concerne la relative incapacité de la technologie orientée objet à tenir ses promesses. La complexité croissante des déploiements logiciels basés sur les formes modernes de composants comme les EJB est contraire aux espoirs de simplification conceptuelle des promesses de la technologie. Le recours à des expédients technologiques (cas d'utilisation, patterns de conception, programmation orientée aspect, etc.) ne fait que renforcer le constat que la technologie orientée objet n'est pas le remède miracle du génie logiciel [8]. Le troisième facteur est l'urgence de stopper l'empilement des technologies. Les systèmes d'information sont parfois composés d'une mosaïque hétérogène de technologies, pour lesquelles il est nécessaire de conserver des compétences associées pour des raisons de maintenance. Cette situation s'étend au fur et à mesure que les systèmes s'agrandissent. La parade à cette accumulation de surcouches technologiques consiste à remplacer les approches interprétatives par des approches transformationnelles capables de générer des systèmes plus légers, moins gourmands en ressources et plus finement adaptés aux besoins réels des applications. L'approche interprétative reconnaît que les individus ont un rôle très actif dans la construction des systèmes informatiques alors que l'approche transformationnelle réduit leur rôle grâce à une automatisation de la construction. 1.6 Synthèse
Ce chapitre a été structuré de manière à pouvoir présenter une définition détaillée et suffisamment profonde de toute la terminologie utilisée dans ce mémoire. L‟accent a été surtout mis sur les trois thématiques clés constituant son titre. 41
Ainsi, dans un premier temps, nous avons abordé les SD, en définissant leurs fondements théoriques, leurs missions et finalités afin d‟accentuer leur importance et utilité pour la prise de décision. Ensuite nous nous sommes penchés sur les aspects techniques du SD en présentant son architecture standard et en définissant les détails techniques de chacune de ses couches dans toute la chaîne décisionnelle. Enfin nous avons essayé de rassembler les problématiques et les faiblesses dont souffrent les SD généralement, pour ensuite les décortiquer par couche. Ce cheminement nous a permis de démontrer que la mise en place d‟un SD en respectant seulement ses exigences fonctionnelles risque de le transformer en un système obsolète. Ce constat provient du fait que le SD doit justifier un certain niveau de confiance suffisant pour la prise de décision. O r cette confiance n‟est assurée que si sa sûreté de fonctionnement est mise en avant plan lors de sa conception et mise en œuvre. Dans cette perspective, nous avons entamé la définition de la sûreté de fonctionnement en précisant ses trois concepts de base, à savoir: les attributs, les entraves et les moyens. Les attributs correspondent aux propriétés du système qui influencent directement sa sûreté de fonctionnement et affectent sa qualité. Les entraves représentent les manifestations (causes ou résultats) de ces attributs, alors que les moyens représentent l‟ensemble des techniques utilisées pour atteindre les niveaux exigés en termes de ses attributs et entraves. Toutefois la SdF est une discipline qui puise ces origines des domaines aéronautique, automobile, etc. Donc, nous avons dû présenter un résumé des méthodes connues qui concernent l‟analyse de la SdF logicielle pour enfin définir le terme exigence et préciser 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 méthodologique et formel. Ceci nous a imposé d‟introduire toute la terminologie qui décompose l‟univers de l‟ingénierie propres aux exigences de sûreté de fonctionnement des systèmes décisionnels. Ainsi, nous avons suivi une démarche descendante en passant de la définition de l‟ingénierie des systèmes, des exigences (plus particulièrement des exigences de La SdF), à celle de l‟ingénierie des SD pour pouvoir délimiter le c adre et le contexte de notre problématique de recherche et de définir ainsi sa portée. Enfin, le chapitre se termine par une présentation de l‟approche sur laquelle nous nous somme basés dans nos travaux de recherches. Donc nous avons présenté l‟intérêt de l‟ Ingénierie Dirigée par les Modèles (IDM) ainsi que son utilité. Nous avons démontré encore une fois qu‟en 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 problématique qui se résume à intégrer les aspects de la SdF dans un SD dès les premières étapes de son cycle de dévelopemment tout en tenant compte de leurs intérractions. Le chapitre suivant présente un état de l‟art du contexte de notre thèse. Ainsi, il aborde les travaux de recherche concernant le système décisionnel en les détaillants par couche. Ensuite,
42
il développe les travaux qui ont traité les attributs de la SdF des SD et les différentes méthodes existantes de l‟ingénierie d‟exigence. Enfin, nous avons présenté les approches dirigées par les modèles dans le contexte des systèmes décisionnels.
43
Chapitre 2 : Etude de l‟Etat de l‟art
« Il faut avoir à l’esprit l’avenir et le passé dans les actes. »
Talleyrand
44
2.1
Introduction
L‟objectif de ce chapitre est de présenter un état de l‟art du contexte de nos travaux de
recherche. Dans cette perspective le chapitre est structuré suivant cinq sections. La première partie étale l‟ensemble des travaux qui traitent chaque couche du système décisionnel. Ensuite la deuxième expose les travaux qui concernent les attributs de sûreté de fonctionnement des systèmes décisionnels, la troisième relate les méthodes d‟ingénierie des exigences dans le contexte des systèmes décisionnels et la dernière expose les approches dirigées par les modèles concernant les systèmes décisionnels. Enfin, chaque section se termine par un récapitulatif et confrontation des travaux présentés permettant de synthétiser les travaux abordés de les discuter pour pouvoir positionner nos travaux de recherche et accentuer la problématique énoncée au premier chapitre. 2.2
Etat de l’art des Systèmes D écisionnels 2.2.1
Sources de Données
Selon [41], l'intégration des sources de données est parmi les aspects les plus importants d'un système décisionnel. Lorsque des données passent de l'environnement opérationnel axé sur l'application transactionnelle (OLTP : On line Transaction Processing) à l‟entrepôt de données, les incohérences et les redondances éventuelles devraient être résolues, de sorte que l'entrepôt est en mesure de fournir une vision intégrée et réconcilier des données. Il existe deux approches de base pour le problème de l'intégration de données, appelés procédurales et déclaratives [42]. Dans l'approche procédurale, les données sont intégrées de manière ad-hoc par rapport à un ensemble de besoins d'information prédéfinis, sans avoir recours à une notion explicite de schéma intégré de données. Dans l'approche déclarative, l'objectif est de modéliser les données provenant des sources au moyen d'un langage adapté, et de construire une représentation unifiée pour être utilisée lors de l'interrogation du système d'information global [42]. Dans une autre perspective, les approches de conception de l‟entrepôt sont généralement classées en deux catégories [43][44]: les approches basées sur les sources de données qui permettent de concevoir le DW à partir d'une analyse détaillée des sources de données. Dans ce cas les besoins des utilisateurs impactent sur la conception en permettant au concepteur de sélectionner les données qui sont pertinentes pour la prise de décision et par la détermination de leur structuration selon un modèle multidimensionnel [45]. L‟autre catégorie est représentée par les approches dirigées par les exigences. Ainsi, la conception se base sur la détermination des besoins d'information des utilisateurs finaux, et donc la mise en correspondance de ces exigences avec les sources de données disponibles est étudiée uniquement a posteriori [46]
45
D'autres auteurs, comme [47] utilisent une sorte de mixture de ces deux approches, et considèrent à la fois les deux catégories (c'est à dire les sources des données et les exigences de l'utilisateur) en même temps. Enfin, une approche est proposée dans [48] qui repose sur la définition d'un ensemble de modèles de conception (Design Patterns) , de telle sorte qu‟une fois le modèle requis est trouvée, il doit simplement être adapté aux exigences relatives aux sources de données et besoins utilisateurs. 2.2.2
Extraction Transformation Loading
Nous présentons dans cette section les principaux travaux portant sur l‟étude
de la phase de
conception ETL. Les auteurs de [49] proposent de définir le processus ETL, en modélisant le flux de données comme une composition d‟activités définissant ainsi un scénario ETL. Les scenarii sont regroupés par un graphe d‟architecture , où les activités ETL et les sources de données sont représentées par des nœuds liés par quatre différentes types de relations (instance-de, partiede, relation de régulateur et relation de fournisseur). Toutefois, les auteurs ont développé leur approche uniquement sur les bases de données relationnelles. D‟un autre côté, les auteurs ont proposé dans un autre travail [50] une méthodologie de modélisation conceptuelle du processus ETL basée sur la modélisation conceptuel des activités du processus ETL. Le modèle facilite la définition des correspondances entre les sources de donnée et l‟ED ainsi que les transformations pour le chargement des données. Les travaux présentés dans [51], explicitent le passage d‟un modèle concep tuel décrivant le processus ETL vers un modèle logique ETL (conçu selon l‟approche présenté e dans [49]) suivant une approche semi-automatique. Cette dernière est structurée autour des phases suivantes: (1) le raffinement du modèle conceptuel ETL pour l‟élimination des ambigüités existantes et l‟identification des sources candidates ; (2) la correspondance des concepts et attributs du modèle conceptuel avec les structures de données et les attributs du modèle logique; (3) l‟application d‟un algorithme de mise en correspondance entre les transformations du modèle conceptuel et les activités du modèle logique ETL tout en précisant l‟ordre d‟exécution des activités; (4) l‟enrichissement du modèle logique par l‟introduction des contraintes imposées sur les données; (5) l‟assurance de la cohérence de l‟ordre des activités ETL; et enfin (6) la génération du schéma représentant les séquences des activités ETL qui représente le schéma logique ETL. Des chercheurs proposent dans [52] une approche pour automatiser le processus de conception ETL. Leur approche est basée sur une ontologie OWL (Ontology Web Language) et les annotations sémantiques. Ces derniers permettent de spécifier d‟une manière formelle et explicite la sémantique des s chémas sources et cible de l‟ED. L‟approche se déroule selon les phases suivantes : (1) la construction d‟un vocabulaire commun du domaine d‟application à 46
travers la lecture des modèles conceptuels des sources et de l‟ED; (2) l a proposition d‟une méthode d‟annotation des sources de données et de l‟E D basée sur le vocabulaire construit (elle permet d‟établir des mappings entre les schémas relationnels et les concepts du vocabulaire défini); (3) l a proposition d‟un algorithme de génération d‟une ontologie d‟application décrivant le domaine d‟application et les mappings entre cette ontologie et les schémas des sources et de l‟ED; (4) la proposition d‟un algorithme d‟identification des transformations ETL. D‟autre chercheurs proposent dans
[53] une approche pour définir la meilleure configuration d‟implémentation physique d‟un workflow ETL. L‟ approche prend la représentation logique du processus ETL et un modèle de coût en entrée. Ensuite, elle définit un algorithme permettant la traduction de la représentation logique du Workflow ETL vers son modèle physique. Cet algorithme utilise une bibliothèque de modèles réutilisables (Template) pour les activités ETL logiques et physiques. Ainsi, les modèles (ou Templates) logiques matérialisent les activités logiques, et les modèles (ou Templates) physiques matérialisent les activités physiques. Enfin, une mise en correspondance permet de lier les modèles logiques et physiques. 2.2.3
Entrepôts de Données (ED)
Nous présentons dans cette section les principaux travaux proposant des méthodes de conception du schéma de l‟ED, couvrant une ou plusieurs des phases suivantes : définition des besoins, modélisation conceptuelle, modélisation logique et modélisation physique. Les auteurs proposent dans [54] une méthode de conception d‟ un modèle d‟un ED à partir des schémas E/A décrivant les sources de données. Le modèle conceptuel final est appelé Dimensional Fact model (modèle DF). I l est constitué d‟un ensemble de schémas sous forme d‟un arbre dont la racine est le fait et les feuilles sont les dimensions. La méthode a été réactualisée et détaillée dans [55] selon six étapes : (1) analyser des sources de données pour permettre la génération du schéma conceptuel les décrivant. (2) collecter et analyser les besoins des utilisateurs. (3) construire le schéma conceptuel multidimensionnel (modèle DF). Ce modèle est généré dans un premier temps par la définition des faits alors que les entités et relations ayant subi le plus de modifications et de mises à jour sont considérées comme des candidats potentiels. Ensuite, l‟arbre des attributs de chaque fait est construit. Celui-ci a comme racine l‟identifiant du fait et comme nœuds ses attributs. (4) traduire chaque fait et chaque dimension identifiés en une table relationnelle pour la définition du modèle logique de l‟ED. (5) Traduire le modèle logique au niveau physique en fournissant des directives pour l‟implémenter dans un outil de type ROLAP, et pour définir quelques structures d‟optimisation comme les index , etc. (6) enfin, estimer une charge de requêtes de l‟ED dans le but d‟évaluer le schéma conceptuel multidimensionnel obtenue.
47
Des travaux proposent dans [56] de définir le schéma conceptuel multidimensionnel en se basant sur l‟analyse des besoins selon une approche orientée agent qui utilise le Framework i*. Ce Framework introduit les notions d‟agent et de but dans les différentes phases de développement d‟un système. Ainsi, il permet d‟identifier les utilisateurs du système et les modéliser en acteurs sociaux en explicitant leurs dépendances vis-à-vis des buts et des tâches à effectuer, et des ressources à utiliser. Cette approche peut s‟arrêter sans la considération des sources de données. Toutefois, l‟approche mixte ou hybride est envisageable en réalisant une mise en correspondance entre les concepts multidimensionnels du schéma conceptuel et les entités des schémas des sources. Cette mise en correspondance est réalisée par le concepteur manuellement par l‟association de chaque fait, dimension ou mesure du schéma conceptuel à une table ou à un attribut dans les sources. Alors que les hiérarchies de dimensions sont construites en précisant les dépendances fonctionnelles entre les différents attributs ou relations. Les auteurs de [57] ont présenté une méthode orientée sources afin de définir le schéma logique final de l‟ED à partir des schémas E/A des sour ces de données d‟une manière automatique. Leurs méthode se base sur les étapes suivantes : (1) les associations ternaires des schémas E/A des sources sont transformées en des associations binaires; (2) les faits sont extraits à partir des entités qui ont le nombre d‟associations ‟un à plusieurs‟ supérieur à une valeur seuil; (3) les dimensions du fait sont construit à base des entités liées aux entités faits par des relations un à plusieurs. Enfin, les auteurs se sont basés sur l‟ontologie terminologique Wordnet afin d‟identifier les hiérarchies de dimensions. Le travaux de [58] se sont basés sur une ontologie décrite en langage OWL (Ontology Web Language) pour proposer une méthode semi-automatique de conception multidimensionnelle d‟un ED. Cette méthode étudie les multiplicités entre les concepts de l‟onto logie pour définir les faits et dimensions du schéma de l‟ED. Ainsi, un concept de l‟ontologie est un fait potentiel s‟il est lié à un grand nombre de dimensions et de mesures. Alors qu‟un concept de l‟ontologie est une dimension potentielle s‟il est rattaché à un fait par une relation un à plusieurs. L‟avantage de cette identification est la possibilité de la réaliser de manière 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 sémantiques utilisant ces ontologies. Ces annotations sont fournies grâce un Framework pe rmettant d‟analyser les données fournies par le web sémantique sous forme de méta données xml ou Rdf. 2.2.4
Outils de Restitution
Les outils de restitutions sont tous les outils d‟analyse des données stockées dans les
entrepôts. Ces outils sont très variés. Elles dépendent des besoins des utilisateurs et font appel à des techniques différentes : 48
Ŕ Le Reporting avec la
construction de tableaux de bord , d‟indicateurs, de graphiques.
Ŕ La navigation multidimensionnelle dans les données avec la technologie OLAP. Ŕ La fouille dans les données à l‟aide des méthodes de Data Mining.
En terme de restitution multidimensionnelle, les premiers travaux ont étendu les opérateurs de l‟algèbre relationnelle [60], il s‟agit au début d‟une transcription SQL des opérations de restitution. Toutefois, l‟algèbr e relationnelle se révèle inadaptable pour la manipulation de structures multidimensionnelles. Et de nombreux travaux ont proposé des opérateurs et des opérations pour spécifier et manipuler les données [61][62][63]. Dans [64], un langage algébrique de manipulation a été proposé pour compléter ces propositions. En plus, les travaux présentés dans [65] sont considérés comme un début de formalisation de langage de manipulation multidimensionnel appliqué à la spécification d‟analyse de données complexes accord général sur un noyau d‟opérateurs de manipulation. Ainsi, la plupart des propositions offrent un support partiel pour les catégories d‟opérations suivantes: o pérations de forage (roll-up et drill-down), opérations de sélection, (slice, dice), opérations de rotation (rotation de dimension, de fait ou drill-across, rotation de hiérarchie), o pérations de modifications du sujet d‟analyse, opérations de modifications d‟une dimension (push, pull), o pérations d‟ordonnancements, et les opérateurs binaires (union, différence et intersection). Malgré l‟absence de standard, il existe un
Certains travaux ont aussi proposé la notion de jointure (join) inspirée de la jointure relationnelle, mais d‟un intérêt limité dans un environnement multidimensionnel. Il est
intéressant de noter que les opérateurs binaires sont des opérateurs nécessitant de très fortes contraintes. Par exemple, l‟union entre deux structures multidimensionnelles nécessite une
compatibilité presque complète des deux structures [64]. 2.2.5
Comparatif des travaux traitant les couches des SD
Le tableau ci-dessous permet d‟élaborer un bilan des contributions citées ci-dessus, afin de procéder à une étude comparative les synthétisant. Le symbole (++) représente l‟influence positive directe, (+) représente l‟influence positive indirecte, (-) représente la neutralité et (--) influence négative indirecte. Couches SD Propositions
Sources Données
ETL
Entrepôt
Outils de
de Donnée
Restitution
[42] Procédural/Déclarative
++
-
+
-
[45,47] Axé sur les Sources
++
-
+
-
49
[46,47] Axé par les exigences
++
-
+
-
[48] Design patterns
++
-
+
-
[49] scénario ETL
-
++
-
-
[50] Modélisation 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 Algèbre Relationnel
-
-
-
++
[61, 62, 63] Opérateurs
-
-
-
++
[64] Langage Algébrique
-
-
-
++
[65] formalisation de 64
-
-
-
++
Quasiment aucune proposition n‟offr e un support complet pour toute la chaine décisionnelle, la plupart sont axés sur une ou deux couches au maximum sans tenir compte que chaque couche se base sur les services délivrés par la couche précédente pour accomplir sa fonction dans le système décisionnel. C‟est dans cette perspective que nous avons proposé de traiter le système dans son intégralité tout en préservant la particularité de chacune de ses couches. 2.3
Sûreté de Fonctionnement des Systèmes Décisionnels
Dans cette partie nous nous intéressons aux différentes méthodes et techniques existantes qui visent à améliorer chacune des attributs de la sûreté de fonctionnement. En tenant compte des définitions précédentes de la disponibilité et de fiabilité, les deux soulignent la prévention des arrêts du système décisionnels et sont donc proches les uns des autres qu'ils ne le sont aux autres attributs de la sûreté de fonctionnement. Par conséquent, la fiabilité et la disponibilité peuvent être regroupés, et collectivement défini comme la prévention ou la minimisation des interruptions de service [22]. Quant à la maintenabilité et la sécurité, elles seront traitées indépendamment.
50
2.3.1
Disponibilité et fiabilité
Les travaux visant à améliorer la disponibilité et la fiabilité des systèmes décisionnels se sont intéressés à la réduction du temps de réponse par la proposition de méthodes et techniques d‟optimisation des requêtes et de la phase de l‟ETL.
2.3.1.1
Techn iques d' opti mi sati on des requêtes
Beaucoup de techniques d'optimisation des requêtes existent dans la littérature pour satisfaire la demande de la disponibilité extrême des données des systèmes décisionnels [66]. La plupart de ces techniques sont issues de systèmes traditionnels de bases de données relationnelles. Vues matérialisées : Les vues matérialisées sont utilisées en générale pour stocker des données agrégées afin de réduire la surcharge associée à des jointures coûteuses ou des agrégations pour un ensemble important de requête . L‟objectif derrière l'utilisation des vues dans les systèmes décisionnels est d'accélérer le traitement des requêtes sur de grandes quantités de données. En vue d‟un traitement efficace de ces requêtes, u n ensemble de vues étroitement liées à des requêtes est matérialisé au data warehouse [67]. Toutefois, Deux problèmes majeurs sont liés à la matérialisation des vues: leurs maintenance et leurs sélection [68]. En plus, il n‟est pa s possible de matérialiser toutes les vues à cause de la contrainte sur les ressources comme l'espace disque, temps de calcul, ou les coûts de maintenance[69]. Techniques d'indexation : L'indexation crée des structures qui offrent un accès rapide aux données pertinentes. La taille de la structure de l'index devrait être gérée afin de bénéficier de ses avantages en parcourant les tables. Les stratégies d'indexation traditionnelles utilisées dans les systèmes de bases de données ne sont pas aussi efficaces dans les environnements du data Warehouse vu le volume des données chargées et la complexité des requêtes de restitution [70]. Un certain nombre de stratégies d'indexation ont été proposées pour le Data warehouse [71]: l'index liste de valeurs, l‟index de projection, l‟index bitmap, l‟index peu tranché, l‟index de données, l‟index de jointure , et l'index étoile de jointure, etc. Toutefois, le problème qui s‟impose assez souvent est celui de la sélection de l‟index adéquat[72]. Partitionnement des données : Le processus de partitionnement des données décompose de grandes tables (tables de faits, des vues matérialisées) en des petites tables en appliquant les opérateurs de sélection. Par conséquent, le partitionnement offre des améliorations significatives en matière de disponibilité, de l'administration, et les performances de balayage de table [73]. Plusieurs types de techniques de partitionnement sont proposés pour décomposer une table: verticale, horizontale, mixte et génétique. 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 génétique propose l‟utilisation des algorithmes génétiques pour
assurer la fragmentation la plus adaptée aux besoins des requêtes [77]. 51
Traitement parallèle : En partageant les données du schéma OLAP (schéma en étoile ou schéma en flocon de neige) entre un ensemble de processeurs, les requêtes OLAP peuvent être exécutées en parallèle, et peuvent ainsi atteindre une accélération linéaire ce qui améliore significativement le temps de réponse des requêtes[78]. Par conséquent, le partitionnement des données et le traitement en parallèle sont deux techniques complémentaires pour parvenir à la réduction du coût du traitement des requêtes dans les environnements data warehouse [73]. 2.3.1.2
Optimisation de l’ETL
La phase ETL du système décisionnel est la partie la plus susceptible de consommer de ressources et être la cause de l‟arrêt du système ou au moins de son indisponibilité. Ainsi deux
orientations scientifiques sont apparues pour améliorer la fiabilité et la disponibilité de cette phase à savoir les concepts du W orkflow appliqués à l‟ETL et les techniques du temps quasi réel (ou temps réel) L‟étude présentée
dans [79] se focalise sur l'optimisation logique du processus ETL, en le modélisant comme un problème de recherche d‟état -espace. Ainsi elle considère chaque workflow ETL comme un état tout en fabriquant l'espace d'état à travers un ensemble de transitions d'état correctes [80] . En outre, l‟étude [79] fournit des algorithmes de minimisation du coût d'exécution du flux de travail de l‟ETL.
En revanche, le travail élaboré dans [81] introduit les concepts du temps réel à appliquer pour avoir un ETL temps réel (ou au moins s ‟en approcher). L‟objectif est de permettre aux utilisateurs finaux d‟accéder à des données parfaitement nettoyées, intégrées, et réconc iliés tout en étant aussi frais que possible, et en même temps, sans compromettre la disponibilité ou le débit des sources ou de l'entrepôt de données [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 élément d‟être maintenue. Cette capacité découle de l'ensemble des caractéristiques de conception qui favorisent la capacité de service. Maintenance: est une série d'actions à caractère approprié (ex. contenu, la qualité, etc.) afin de restaurer ou de conserver un élément dans un état opérationnel. Toutefois, ces deux concepts peuvent être confondus car il est difficile de procéder à la maintenance d'un système alors qu‟il n‟est pas maintenable, et vice ve rsa. Donc la possibilité de la maintenance et son degré donne un certain niveau de maintenabilité au système [83]. Dans le contexte des systèmes décisionnels, la plupart des travaux se sont focalisés surtout sur la maintenance du point de vue évolution du système. Cet évolution est généralement causée
52
par l‟évolution des besoins et exigences des utilisateurs d‟un côté et des données de l‟environnement d‟un autre côté.
2.3.2.1
M aintenance par mi se àjour du m odè le
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 gérer la maintenance des dimensions changeantes. La première solution consiste à écraser l‟enregistrement avec la nouvelle valeur ce qui va engendrer la perte de l‟historique. La deuxième solution consiste à créer un enregistrement supplémentaire qui
correspond alors à une description unique valide pendant une période donnée. La troisième solution est de créer un cha mp conservant l‟ancienne valeur de l‟attribut dans le même enregistrement. Cependant des limitations existent pour cette solution [85], si par exemple il y a une succession de changements à prendre en compte. ces techniques se basent sur un modèle formel pour la mise à jour des dimensions et de leur hiérarchie, en proposant plusieurs opérateurs. Ces derniers répondent non seulement à une évolution des instances des dimensions, mais également à une Opérations d‟évolution :
évolution structurelle des dimensions, telle que l‟ajout d‟un niveau de granularité en fin de
hiérarchie [86]. En plus, ces techniques s‟intéressent aussi à l‟effet de ces mises à jour sur les vues matérialisées (les cubes) en proposant des algorithmes pour réaliser leur maintenance de façon efficace. Non seulement ces techniques ont facilité l‟évolution au niveau des dimensions, mais également l‟évolution des faits. Et ceci grâce à une algèbre comprenant quatorze opérations d‟évolution qui peuvent être combinées pour réaliser des opérations d‟évolution 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
M aintenance par modé lisati on tempor ell e
Cette maintenance s‟oppose à celle des travaux sur la mise à jou r
de modèle vis-à-vis de la traçabilité des évolutions subies par celui-ci. Pour assurer cette traçabilité, des extensions temporelles sont nécessaires pour enrichir le modèle. Gestion temporalité des instances: Cette technique permet de gérer la temporalité des instances de dimensions [89]. Pour cela, un schéma en étoile temporel est proposé pour représenter le fait que les informations dans un entrepôt de données sont valables sur une durée donnée. Il s‟agit donc de représenter les données en «temps consistant». Le principe est d‟omettre la dimension temps qui permet habituellement l‟historisation des données et d‟ajouter une étiquette temporelle au niveau de
chacune des instances des tables de dimension
et des faits de l‟entrepôt. Gestion de la temporalité des liens d‟agrégation : les travaux présentés dans [90]
suggèrent la
gestion de la temporalité des liens d‟agrégation. Il s‟agit de pouvoir gérer des dimensions
53
temporelles pour lesquelles les hiérarchies ne sont pas fixes au niveau des instances. Ainsi le chemin d‟agrégation défini pour une instance le long d‟une hiérarchie peut évoluer au cours
du temps. Pour interroger ce modèle, les auteurs proposent un langage de requêtes nommé TOLAP. La gestion des versions constitue une voie de recherche très explorée actuellement. Cela consiste à gérer différentes versions du modèle de l‟entrepôt, chaque version étant valide
pendant une durée donnée. Le modèle proposé par [91] introduit des fonctions de mise en correspondance qui permettent la conversion entre des versions de structures. Ces fonctions sont basées sur la connaissance des évolutions opérées. Les auteurs de [92] proposent une appr oche qui permet à l‟utilisateur d‟obtenir des analyses en fonction de ses besoins de comparaisons des données. En effet, le modèle proposé permet de choisir dans quelle version analyser les données. Différents travaux se sont ensuite focalisés sur le versioning qui permet de répondre à des «what-if analysis», en créant des versions alternatives, en plus des versions temporelles, pour simuler des changements de la réalité et sur la possibilité de réaliser des analyses en prenant en compte différentes versions [93]. 2.3.3
Sécurité
Le Data warehouse est la banque d‟informations sensible de tout organisme. C‟est pour cette raison que plusieurs solutions ont surgies pour sécuriser ses données selon différents niveaux à savoir le niveau logique, physique et conceptuel [94][95]. Dans cette partie, nous allons cerner les différentes méthodes existantes Les données de filtrage et de cryptage des données [96] propose un Framework de filtrage des données avant leur stockage dans le Data warehouse. Le filtre est utilisé pour crypter les données collectées ensuite les stocker après cryptage dans le data warehouse. Cette technique augmente le coût des données en termes de temps de réponse et des délais d‟attente. En plus , elle ne fait que protéger contre les accès malveillants non autorisées de données, mais n‟agit pas sur l'intégrité des données et n'offrent pas de sécurité au niveau utilisateur (problème des droits et leurs limites). Une approche hybride de sécurité : les auteurs de [97] ont proposé un Framework de sécurité amélioré pour les systèmes Data warehouse. Il consiste à filtrer et crypter les données recueillies auprès de sources. Ainsi, la filtration réduit la redondance des données et permet d'éliminer les données redondantes ce qui améliore le temps de réponse. D‟un autre côté, au niveau de l‟utilisateur ils ont introduit un autre filtre à plusieurs point d‟accès du système en appliquant un code d‟authentification pour améliorer les mécanismes du contrôle d‟accès et
pour sécuriser le système des accès non autorisés aux données privées ou confidentielles. Une architecture sécurisée des SD a été le centre des travaux des auteurs dans [98] qui ont proposé le développement des systèmes qui se basent en générale sur des machines de qualité inférieure exécutant des outils open sources n‟offrant pas des capacités de sécurité suffisantes
54
pour protéger des données critiq ues. L‟architecture proposée s‟intéresse à l‟utilisation du cryptage des données pour garantir la confidentialité, l ‟application des techniques de signature sur les données pour améliorer l‟intégrité et authenticité des données et détecter le s
modifications vicieuses de données. Et enfin elle assure la disponibilité par les techniques de réplication des données. 2.3.4
Comparatif des travaux des attributs de sûreté de fonctionnement
Le tableau ci- dessous permet d‟élaborer un bilan des contributions t raitant les aspects de sûreté de fonctionnement, dans l‟objectif de les comparer et les synthétiser. Attributs de SdF Propositions
Fiabilité et disponibilité
Maintenabilité
Sécurité
[67- 69 ] Vue Matérialisée
++
--
-
[70-72] Indexation
++
-
-
[73-77] Partitionnement
++
--
-
[78] Parallélisme
++
-
-
[79] Optimisation ETL
++
+
-
[80] Modélisation Workflow
++
+
-
[81] ETL Temps réel
++
-
-
[84] SCD
-
++
-
[86, 87, 88] Opération d’évolution
-
++
-
[89] Temporalité d’instance
-
++
-
[90] Temporalité des liens d’agrégation
-
++
-
[91,92 ,93] gestion des versions
-
++
-
[96] Filtrage et cryptage
--
-
++
[97] Filtrage et redondance
-
+
++
[98] minimisation des coûts
++
++
++
La plupart des travaux confrontés se sont concentrés sur un aspect de sûreté de fonctionnement en négligeant son impact sur les autres aspects. Seuls les travaux dans [98] ont pr oposé une méthode qui permet d‟ améliorer l‟ensemble à la fois, cependant leur approche n‟intervient qu‟au niveau de l‟implémentation. Etape où la plupart des choix techniques ont été déjà effectués, sans la prise en compte des exigences des utilisateurs en
55
termes de sûreté de fonctionnement durant des phases d‟analyse et conception. Par
conséquent, le système final peut assurer un certain niveau de sûreté de fonctionnement, mais pas forcement celui exigé par ces utilisateurs. Notre objectif est de concevoir les aspects de sûreté de fonctionnement en parallèle avec les besoins fonctionnels et ensuite les intégrer afin d‟assurer une traçabilité des exigences des utilisateurs durant toutes les étapes du projet décisionnel.
Approches de l’ Ingénierie des exigences des Systèmes Décisionnels
2.4
Lors de l‟étape d‟analyse des exigences, orientant la réussite d‟un projet décisionnel, plusieurs
problèmes peuvent être rencontrés à savoir: la mauvaise collecte d‟information, l‟incompréhension et l‟incomplétude des besoins, la multitude des profils des utilisateurs et de leurs contextes. Ces difficultés peuvent influencer négativement le processus d‟analyse des
besoins décisionnels, et par conséquent, les exigences collectées sont souvent vagues et non mesurables. Ainsi l‟utilisation des méthodologies qui puisent leurs sources de l‟ingénierie des exigences s‟avère efficace pour remédier à ces difficultés. Les sections suivantes présentent les approches les plus référencées. 2.4.1
Approche basée sur les Ontologies et notion du contexte
Dans [99], les auteurs ont proposé un processus de formalisation des besoins métier d‟un SD. L‟objectif de leurs travaux est d‟apporter une proposition d‟une solution méthodologique pour l‟analyse des besoins d‟un SD. Il s‟agit d‟offrir une méthode efficace permettant d‟analyser les besoins métier collectés afin d‟établir le schéma en étoile. Leurs méthode propose un guide de traitement et de formalisation des besoins métier, collectés sous forme de buts, afin d‟en extraire systématiquement les faits et les dimensions. Elle consiste également à fournir des modèles d‟association entre les buts stratégiques 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 méthodologie de conception à base des ontologies. 2.4.2
La méthode Computer Aided Data Warehouse Engineering
centrale des travaux dans [15] est la proposition d‟ une démarche intentionnelle d‟Ingénierie des exigences adaptée aux SD. Cette méthode comporte des modèles de produits et un processus qui guide la découverte des exigences et la conception du SD en donnant une considération particulière aux différents types de décideurs et leurs exigences décisionnelles afin d‟aboutir au SID qui répond à leurs exigences. L‟élément
La méthode baptisée sous le nom CADWE ( Computer Aided Data Warehouse Engineering) se base sur les différentes sources pour faire ressortir les exigences du SD: les buts stratégiques de l‟organisation, les objectifs stratégiques et tactiques des décideurs, les données des SI opérationnels existants ainsi qu‟une base de composants réutilisables intentionnels et opérationnels. 56
Le processus de la méthode CADWE propose de suivre quatre phases: (1) identifier les buts stratégiques, (2) exprimer les objectifs, (3) découvrir les exigences informationnelles et (4) définir le schéma multidimensionnel. Pour atteindre son objectif, CADWE s‟est inspiré des concepts du Business Motivation Model (BMM) proposé par l‟OMG en définissant quat re boucles qui montrent un mécanisme fins/moyens. La méthode se base sur quatre métamodèles : le métamodèle de la CARTE, le métamodèle des intentions, le métamodèle de la structure organisationnelle et le modèle linguistique d‟intentions.
Les livrables générés par chacune des boucles utilisent les quatre derniers métamodèles afin de fournir les produits suivants : la Liste des Buts Stratégiques (LBS), les cartes des objectifs qui se déclinent en Carte des Objectifs Stratégiques (COS) et Carte des Objectifs Tactiques (COT), la Liste des Exigences Informationnelles (LEI) et les schémas multiDIMensionnels (DIM). En se basant sur plusieurs ressources, le processus prend en considération les différents types d‟exigences, rattachées à un SD et permet de générer ainsi l‟ensemble des schémas multidimensionnels qui permettent l‟implantation du SD le plus adapté aux exigences recensées [46]. 2.4.3
Approche à base des patrons
Dans [8], l‟auteur a proposé une méthode qui prend en compte les spécificités du SD ainsi que celles des besoins de ces acteurs. La méthode permet d‟analyser l‟aspect statique et l‟aspect dynamique du SD définis à partir de structures spécifiant les besoins en le représentant via un modèle proche de la vision multidimensionnelle des données par les utilisateurs. A partir de cette formalisation, elle permet de guider, suivant un processus automatique, le choix de l‟architecture du SD adaptée à un projet. Cette architecture repose sur plusieurs types de modules décisionnels dont certains sont multidimensionnels. Elle a proposé ainsi un modèle multidimensionnel généralisé à partir des propositions existantes, visant à répondre à ce manque de modèle standard. Dans un second temps, un catalogue de patrons est proposé ce qui capitalise cette méthode de développement. Ce catalogue favorise la réutilisation systématique de la méthode. D ‟une part, la formalisation du contexte d‟un patron facilite sa recherche car les conditions dans lesquelles il est utilisable et celles dans lesquelles il requiert un autre patron sont formellement spécifiées. D ‟autre part, la gestion intégrée de la documentation dans sa représentation contribue à améliorer la fiabilité des systèmes développés. Enfin, pour faciliter le développement rapide de SD par réutilisation de leurs patrons, les auteurs ont développé un outil, appelé eBIPAD (Electronic Business Intelligence Patterns for Analysis and Design), de gestion de ces patrons av ec des fonctionnalités d‟organisation et de
57
réutilisation. Cet outil est dédié aux administrateurs des patrons et aux concepteurs décisionnels. 2.4.4
Approches à base du modèle de buts
Les auteurs de [100] collectent les exigences sous forme de buts et de décisions. Ils définissent un but comme un concept passif et la décision comme un concept actif tel qu‟un processus. Ils utilisent un modèle de buts propriétaire GDI (goal-decisional information) pour les représenter. Ils évoquent des processus liés au contexte décisionnel qui sont sous-jacents aux stratégies pour atteindre les buts. Alors que les travaux dans [101] proposent une méthode de conception mixte permettant la définition du schéma de l‟ED. Un premier ensemble de schémas multidimensionnels est dérivé à partir des buts organisationnels, en adaptant l‟approche Goal/Question/Metric
(GQM). GQM est une approche permettant de fournir des métriques pour mesurer des programmes. Cette approche a été adaptée pour identifier les buts d‟une organisation et les analyser afin d‟en extraire des informations pertinentes. Les buts sont d‟abord collectés à
travers les interviews avec les utilisateurs et structurés selon un format détaillant chaque but. Quelques directives générales sont fournies afin de générer des schémas multidimensionnels à partir de l‟ensemble de buts.
Un deuxième ensemble de schémas multidimensionnels (sous forme de graphes) sont dérivés automatiquement à partir de schémas E/A des BD sources. Un algorithme est défini qui identifie les faits comme les entités ayant des attributs numériques. Ces entités représentent les nœuds centraux du graphe. Les dimensions sont les entités liées aux entités Fait par une relation “un à un“ ou une relation “un à plusieurs“. Un algorithme est fourni afin de traduire chaque graphe en un schéma en flocon de neige. Une dernière étape consiste à intégrer les deux ensembles de schémas multidimensionnels (les schémas obtenus à partir des buts et les schémas obtenus à partir des sources) en un schéma unifié. Ce mapping est effectué manuellement par le concepteur et nécessite la mise en correspondance de l‟ensemble des schémas à un référent terminologique unique (un dictionnaire par exemple). Les deux ensembles de schémas sont comparés un à un. Les schémas sont intégrés s‟ils possèdent la même entité de fait. 2.4.5
Approche pour la définition et la gestion des SD (DWARF)
Les travaux dans [102] adaptent les techniques traditionnelles d‟ingénierie des exigences afin de proposer une approche méthodologique pour la définition et la gestion des SD. Dans cette perspective, ils ont proposé DWARF (The Data WArehouse Requirements deFinition technique), un Framework interactif orienté phase couplé d‟un ensemble de Templates, procédure et techniques pour guider les développeurs durant le cycle d‟ingénierie 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 définis en termes de règles du métier, des procédures et processus pour clarifier les aspects des exigences en termes de multidimensionnalité (granularité, sommabilité, etc.), d‟intégration des sources et enfin des objectifs du projet. 2. Phase de spécification des exigences: prescrit une approche cyclique pour l‟acquisition, la représentation et l‟évaluation des exigences afin de produire progressivement les spécifications système selon les sous processus suivants: elicitation des exigences (par des interviews, des prototypes, en tenant en compte les NFR, etc.), analyse et négociation des exigences, documentation des exigences et enfin conformité des exigences. 3. Phase de validation des exigences: corrige tous les problèmes de compréhension 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, nonfonctionnels et multidimensionnels. Durant cette phase l‟organisation des sessions de
révision et du prototypage ont prouvé leurs efficacités à détecter, remédier et enlever les failles du futur SD cible. 4. Phase de contrôle des exigences: traite la traçabilité des exigences ainsi que la gestion du changement au niveau des exigences et au niveau de l‟architecture. Dans ce sens , cette phase propose l‟utilisation de la matrice de traçabilité pour traiter l‟influence du
changement sur les exigences existantes afin de contrôler la performance de la maintenance et préserver la sécurité indispensable du SD. Enfin nous devons souligner que cette approche a été l‟extension de leurs travaux présentées dans [103] qui sollicitent une attention particulière aux exigences non fonctionnelles recensées pour des SD. Leur contribution propose une extension du NFR (Non Functional Requirements) Framework et une classification détaillée des exigences non-fonctionnelles qui doivent être abordées dans le développement du projet SD. 2.4.6
Comparatif des travaux dans le domaine des exigences des SD
Le tableau ci-dessous permet d‟élaborer un bilan des travaux cités auparavant, afin de procéder à une étude comparative les synthétisant. La plupart des approches d‟ingénierie d‟exigence se sont penchées sur les besoins fonctionnels afin de fournir un cadre méthodologique standard pour le développement des systèmes décisionnels. Toutefois la plupart ont négligé les besoins non fonctionnels qui jouent un rôle important lors de la mise en œuvre du fonctionnel. Seuls les travaux [102, 103] les ont abordés. Car ils ont explicité le traitement des besoins non fonctionnels d‟une manière générale en les intégrant au cycle de développement du projet décisionnel. Toutefois aucun travail n‟a traité d‟une manière intégrale, la particularité des exigences de sûreté de fonctionnement qui sont considérées souvent comme des besoins non fonctionnels.
59
Type d’exigences Fonctionnelle
Non-Fonctionnelle
Propositions
[99] Ontologie et notion de contexte
++
-
[15,46] CADWE
++
-
[8] Patrons
++
-
[100,101] Modèle de but
++
-
[102, 103] DWARF
++
+
2.5
Approches Dirigées par les modèles dans le contexte des SD 2.5.1
Méta modélisation
Les travaux des auteurs de [104] se sont concentrés sur la formalisation du processus d'élaboration d'ED historisés (avec une dimension temporelle) depuis sa conception jusqu' à son implantation physique. Ils se sont basés sur l'Ingénierie Dirigée par les Modèles (IDM) qui permet de formaliser et d'automatiser ce processus; Tout en en réduisant les coûts de développement et en améliorant la qualité du logiciel. Leur contributions [104][105] se résument en deux points : i.
Formaliser et automatiser le processus de développement d'un ED en proposant une approche dirigée par les modèles qui inclut un ensemble de métamodèles (conceptuel, logique et physique) une extension du langage OCL et un ensemble de règles de transformation d'un modèle et de la génération du code de création et de chargement de l'entrepôt.
ii.
Formaliser et automatiser le processus de réduction de données historisées en proposant une approche dirigée par les modèles qui fournit un ensemble de métamodèles (conceptuel, logique et physique) décrivant les données réduites, un ensemble d'opérations de réduction, et un ensemble de règles de transformation permettant d'implanter ces opérations au niveau physique.
Les auteurs de [106] proposent une extension de leur précédente contribution [107], et définissent un Framework de conception logique des activités ETL. Le Framework se base sur un métamodèle décrivant une activité ETL. Le métamodèle est conçu de manière générique pour capturer plusieurs types d‟activités ETL. Il peut être instancié pour représenter un workflow d‟activités ETL relatives à un domaine précis. Les activités ETL (transformations,
filtrage, etc.) sont formellement décrites en utilisant un langage LDL (Logical Data Language) qui est une variante du langage Datalog. Le code d‟exécution de chaque activité est décrit par une déclaration LDL. Les activités définies d‟une manière abstraite au niveau de
60
la couche logique, sont matérialisées et exécutées par des modules logiciels spécifiques dans la couche physique. L‟approche ETL est mise en œuvre par un outil ARKTOS II [49]. Enfin les auteurs de [108] ont proposé une approche multicouche pour la spécification des aspects et leurs intégration au niveau de la conception logique de l‟architecture des SD . Leur approche se base sur le paradigme orienté aspect afin de produire multiples vues des aspects transversaux composées par les aspects architecturaux. Et finalement ils ont prouvé leur proposition par une mise en œuvre au niveau de la conception de l‟architecture d‟un entrepôt de données en représentant les métadonnées sous forme de vues et d‟aspect transversal. 2.5.2
Approches spécifiques à l’architecture MDA
Les travaux présentés dans [109] proposent une approche qui vise à élaborer le modèle conceptuel de l'entrepôt en se basant sur les modèles conceptuels sources et les besoins des décideurs. La méthode est basée sur trois étapes. La première analyse le schéma Entité/Association de la source et applique un ensemble de règles de transformation défini entre le métamodèle Entité/Association et le métamodèle OLAP. La seconde phase permet de collecter les besoins des décideurs et de les décrire sous forme d'un modèle de buts. La dernière étape permet la confrontation du modèle des buts et du modèle des sources pour aboutir au modèle multidimensionnel final. Les auteurs des travaux [110] présentent une approche qui vise à formaliser la détection de faits à partir de sources de données relationnelles. L'approche est basée sur des heuristiques issues d'un ensemble de cas réels. D'abord, les tables de la BD source sont identifiées. Ensuite, le concepteur détermine les éléments de cette BD pouvant être considérés comme faits. Enfin, il définit l'ensemble des dimensions et des mesures pour chaque fait du modèle. Les travaux précédents utilisent le langage QVT pour formaliser la correspondance entre les éléments sources et cibles de l'ED. D'autres approches permettent de modéliser différents niveaux d'abstraction de l'entrepôt. Les auteurs de [111] proposent une démarche mixte pour l'élaboration et l'implantation de schémas multidimensionnels d'ED dans un cadre IDM. Cette approche définit les modèles et les transformations comme suit :
Au niveau du CIM, les auteurs définissent un „CIM multidimensionnel‟ décrivant les besoins décisionnels grâce à un modèle de buts. Ce modèle définit les besoins à trois niveaux: „ besoins stratégiques‟ , „ besoins décisionnels‟ et „ besoins informationnels‟. Une fois les besoins informationnels définis, les éléments du schéma multidimensionnel (faits et dimensions) peuvent être déterminés. Afin de modéliser ces besoins, les auteurs proposent un profil UML qui permet d'adapter les éléments du modèle i* [112] au domaine de l'ED. En fournissant ainsi les mécanismes pour représenter les différents acteurs de l'ED ainsi que leurs dé pendances et de l‟autre côté de structurer les objectifs à atteindre.
61
Au niveau du PIM, les auteurs définissent un PIM dit initial dérivé à partir du CIM suite à une série de transformation QVT. Ce PIM est par la suite confronté au modèle source pour générer un PIM hybride multidimensionnel initial. Dans ce sens et afin de décrire ce modèle, les auteurs proposent un profil UML multidimensionnel. Ce profil définit principalement les concepts de faits et de dimensions. Au niveau du PSM, les auteurs utilisent le CWM (Common Warehouse MetaModel) comme métamodèle du PSM. Ils présentent une instance du schéma ROLAP qui est généré en appliquant un ensemble de règles QVT, où les faits et les dimensions sont transformés en tables.
Dans [113], les auteurs proposent une approche qui définit le modèle conceptuel (PIM) sous forme d'un diagramme d'activités UML tel que présenté dans [114]. A partir de ce modèle, l'objectif est de générer le modèle logique (PSM) de manière automatique. Ainsi au niveau du PIM, les auteurs proposent de concevoir les processus ETL comme un ensemble d'activités décrivant le comportement d'un processus. Un diagramme d'activités ETL comporte en entrée une table source, une liste des opérations à exécuter et une sortie montrant une table cible de l'entrepôt. Les actions d'un diagramme représentent les opérations d'agrégation, de conversion, de filtrage et de jointure. Les auteurs définissent les activités suivantes: activité d'agrégation, 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 activités, y compris les actions d'extraction à partir de la source et les opérations de transformations, sont traduites en éléments du métamodèle de cette plateforme. Et enfin, pour mettre en œuvre les transformations de modèles (du PIM vers le PSM), les auteurs présentent le métamodèle des diagrammes d'activités UML et le métamodèle du PSM décrivant les concepts de la plateforme Oracle. Le diagramme d'activités défini au niveau PIM est transformé au niveau PSM en appliquant un ensemble de règles QVT. Les travaux présentés dans [115] et [116] proposent une approche qui vise à couvrir le cycle de développement des processus ETL et qui permet la génération semi-automatique du code. L'approche définit un modèle (PIM) dans lequel les auteurs utilisent le BPMN. Ce modèle est par la suite transformé pour générer le code. Les auteurs se sont basés sur Le BPMN. Celui-ci est une norme de l'OMG qui permet de modéliser le déroulement des processus d'une entreprise dans un Workflow. Cette norme décrit les processus en termes d'activités représentant le travail accompli par un processus. Une activité est décomposée en tâches. Lorsque les activités sont combinées, elles forment un sous-processus. Les auteurs définissent principalement trois types de tâches décrivant l'extraction (l'entrée qui représente la base de données et les fichiers sources), la transformation (jointure, filtrage, etc.) et le chargement (la base de données en sortie). Les tâches ETL sont les suivantes : tâche de dérivation, tâche de jointure, tâche de conversion de type, tâche de filtrage, t âche d‟agrégation. 62
Au niveau PIM, le métamodèle proposé est structuré en un ensemble de paquetages. Le paquetage racine définit l'ensemble des processus d'alimentation de l'ED à partir des sources. Le deuxième paquetage décrit les données tout au long du processus, en allant des sources vers l'entrepôt. Il comporte les différentes tâches de jointure, de filtrage, de conversion, etc. Un événement est défini afin de personnaliser les exceptions levées par une tâche. Les tâches qui partagent les mêmes caractéristiques constituent un sous-processus. Le paquetage source décrit l'ensemble des sources utilisées pour alimenter l'ED. Les auteurs définissent également un métamodèle de vérification de la cohérence grâce au langage OCL. Au niveau du code, les auteurs proposent d'implanter les processus ETL en utilisant la plateforme Oracle. Pour ce faire, ils définissent une grammaire qui décrit les tâches du niveau PIM. Cette grammaire est par la suite utilisée pour générer le code de manière semiautomatique. Enfin côté transformation, les auteurs définissent un ensemble de « Template » spécifiant des transformations de modèle vers du texte. Les règles de correspondance sont établies entre les éléments du métamodèle PIM et la grammaire. Chaque Template contient une partie du code qui correspond à un concept du métamodèle source. Dans [117], les auteurs ont proposé de préciser les mesures de sécur ité et d'audit dès les premiers stades de la conception et de les faire respecter tout au long du cycle de vie en s‟appuyant sur le cadre standard pour le développement de logiciels, le Model Driven Architecture (MDA). Leur proposition permet de définir des transformations formelles, entre les modèles indépendant de la plateforme (PIM) et spécifiques à la plate-forme (PSM). Pour cela ils ont définis deux métamodèles pour représenter les mesures de sécurité et d'audit aux niveaux conceptuel et logique. Ensuite, ils ont définis les transformations entre ces modèles pour obtenir la traçabilité des règles de sécurité dès les premières étapes du développement des SD. 2.5.3
Comparatif des approches dirigées par les modèles dans le cas des SD
Le tableau ci-dessous permet d‟élaborer un bilan des contributions citées ci-dessus, afin de procéder à une étude comparative les synthétisant. La plupart des approches basées sur l‟IDM ont traité la conception, l‟automatisation des
entrepôts de données ou de l‟ETL sans tenir compte des contraintes non fonctionnelles. Seuls les travaux présentés dans [117] se sont concentrés sur l‟élaboration d‟un système décisionnel sécurisé depuis sa conception jusqu‟à sa mise en œuvre. Toutefois la sécurité n‟est pas le seul
aspect pour garantir la sûreté de fonctionnement. Ainsi, nous nous sommes largement inspirés des travaux présentés afin de proposer une approche dirigée par les modèles pour l‟‟ingénierie des exigences de sûreté de fonctionnement dans le contexte des systèmes décisionnels.
63
Approche Dirigée par les modèles Propositions
[104, 105] Automatisation du
Méta
Modèle CIM, PIM,
modélisation
PSM
++
-
++
-
++
-
Développement de l'ED + Réduction Donnée [106,107] Conception Logique des activités
de l’ETL [108] Intégration des Aspects au niveau Logique
-
[109] Modèle conceptuel à partir des sources des besoins des décideurs [110] Détection automatisée des faits
-
++
[111, 112] Modélisation des différents
-
++
[113,114] Diagramme d’activité ETL
-
++
[115, 116] workflow de l’ETL par BPMN
-
++
[117] Sécurité et audit
-
++
niveaux des besoins
2.6
Synthèse des travaux et positionnement de notre contribution
Les travaux présentés dans ce chapitre se déclinent selon les quatre axes qui délimitent notre sujet de recherche à savoir : les systèmes décisionnels, la sûreté de fonctionnement, l‟ingénierie des exigences et enfin l‟ingénierie dirigée par les modèles. Dans un premier temps, nous avons présenté les travaux de recherche qui traitent les systèmes décisionnels. Ceux-ci se sont concentrés sur les principales couches des SD: les sources de données, l‟ETL et l‟entrepôt de d onnées. Ainsi au niveau des sources de données, l‟intégration représente la problématique la plus traité e dans la littérature. Plusieurs approches (procédurales, déclaratives ou mixtes) ont proposé de remédier à cette problématique, mais généralement celle-ci a été traitée dans une perspective plus vaste afin de faciliter la conception de l‟entrepôt de données et tenir compte des exigences des utilisateurs finaux. Au niveau de l‟ETL, les objectifs des travaux sont centrés sur la modélisation des flux de données, l‟automatisation du passage des modèles conceptuels au modèle logique en utilisant le concept de l‟ontologie, les annotations séma ntiques ou bien le principe du Workflow. Enfin, la couche entrepôt de données a bénéficié de la plus grande part des travaux de recherche puisqu‟elle est le centre de la chaîne décisionnelle. Ainsi plusieurs méthodes ont
64
proposé d‟automatiser sa conception en se
basant sur les schémas des sources de données, l‟analyse des besoins via le Framework i*, l‟ontologie décrite en langage OWL et les annotations sémantiques utilisant ces ontologies. Les travaux de recherche cités dans la première section du chapitre montrent que les systèmes décisionnels n‟ont pas encore atteint leurs maturités et qu‟il y a beaucoup de synergies et de contributions afin d‟automatiser leurs conception et mise en œuvre en tenant compte de leur
particularité. Cette particularité réside dans le caractère changeant des exigences et des besoins de ces utilisateurs finaux et des liens de dépendance forte du système avec les sources ainsi que leur rôle important pour la prise de décision, or cette dernière doit prendre en considération plusieurs paramètres (le contexte, les moyens, la stratégie, etc.) souvent dynamiques. La deuxième partie du chapitre développe les travaux qui ont traité les aspects de sûreté de fonctionnement des SD: la disponibilité, la fiabilité, la maintenabilité et la sécurité. Ainsi, concernant la disponibilité et la fiabilité des SD, les travaux de recherche se sont intéressés à la réduction du temps de réponse par la proposition des méthodes et techniques d‟optimisation des entrepôts de données telles que les vues matérialisées, les différents type d‟indexation (l'index liste de valeurs, l‟index de projection, l‟index bitmap, l‟index peu tranché, l‟index de données, l‟index de jointure, et l'index étoile de jointure ) le partitionnement des données (horizontal, vertical, mixte et génétique), et le traitement parallèle qui permet de partager les données entre un ensemble de processeurs. Au niveau de l‟ETL, les travaux ont surtout développé les techniques du temps réel et quasi réel pour améliorer sa disponibilité et fiabilité. Quant à la maintenabilité, deux grandes familles ont visé l‟amélioration de la maintenabilité des entrepôts de données: (i) les techniques de la mise à jour du modèle qui permettent de gérer la maintenance des dimensions changeantes par la technique SCD (Slowly Changing Dimensions), ou par les opérateurs d‟évolution qui se basent sur toute une algèbre afin d‟assurer une évolution des instances des dimensions, voir une évolution structurelle des dimensions telle que l‟ajout d‟un niveau de granularité ;
(ii) maintenance par modélisation
temporelle qui impose une traçabilité des évolutions subies par le modèle en l‟enrichissant par des extensions temporelles afin de gérer les instances, les liens d‟agrégation et le
versioning
qui répond aux analyses de type „What -if Analysis‟.
Enfin, le critère de la sécurité est souvent critique pour les systèmes décisionnels vu qu‟ils consolident les données et les informations cruciales orientées pour la prise de décision. Ainsi la sécurité est un axe important de recherche, et beaucoup de travaux se sont intéressés à combler cette faille par proposer des techniques de filtrage des données recueillis auprès des sources et de les crypter en plus de l‟introduction d‟autres filtres supplémentaires à plusieurs point d‟accès du système en appliquant un code d‟authentification. Ces techniques ont pour
65
objectif d‟améliorer les mécanismes du contrôle d‟accès et de sécuriser le système des accès non autorisés aux données privées ou confidentielles. D‟autres travaux se sont intéressés aussi
aux techniques de sig nature pour améliorer l‟intégrité et l‟authenticité des données et détecter les modifications vicieuses. Et enfin assure la disponibilité par la technique de réplication des données. L'étude des approches existantes montre que les aspects de SdF ont été largement traités et plusieurs méthodes et techniques ont émergé pour améliorer chacun des attributs. Toutefois, cette étude nous a permis de soulever les trois remarques suivantes: i.
Les études ont traité séparément les impacts individuels de chacun des aspects, sans penser à révéler l‟interaction entre eux, ni à trouver leurs combinaisons optimales.
ii.
Les aspects de sûreté de fonctionnement sont considérés comme des besoins secondaires, puisqu‟ils ne sont évoqués qu‟à l‟étape d‟implémentation du système ce qui rend difficile leur mise en œuvre.
iii.
La traçabilité des attributs de la SdF depuis l‟expression des besoins jusqu‟à l‟implémentation physique du système est complexe car le développement de ces attributs n‟est pas suivi lors des phases du projet.
D‟après
ces dernières remarques nous nous sommes penchés, à la troisième partie de ce chapitre, sur l‟étude les travaux qui ont traité les exigences des systèmes décisionnels afin de trouver une méthodologie ou une approche qui permet de remédier aux problématiques de la SdF soulevées. Ainsi, les plupart des travaux autour des exigences des SD ont essayé de proposer des méthodologies globales afin de guider les concepteurs et les développeurs lors de la mise en place du projet décisionnels. Leur objectif commun est de formaliser le processus pour livrer un SD ciblé qui répond 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 métiers sous forme de but et d‟associer les buts stratégiques, les buts tactiques et les buts informationnels. D‟un autre côté , la méthode CADWE s‟intéresse à l‟extraction de l‟ensemble des exigences de différentes sources suivant des processus qui permettent à la fin de générer les schémas multidimensionnels. Cette méthode définit des étapes à suivre pour livrer un système qui respecte toutes les exigences extraites. D‟autres travaux ont pro posé un modèle standard pour guider l‟automa tisation du choix architectural adapté au SD, ensuite ils ont fourni un catalogue de patrons qui capitalise leur méthode de développement et qui favorise sa réutilisation systématique. D‟autres travaux ont utilisé les modèles pour collecter les exigences sous formes de buts en adoptant différentes approches, telles que : GDI (goal decisional information) et le GQM (Goal Question Metric) afin d‟identifier, de définir, d‟extraire et d‟analyser les buts d‟une organis ation et ses informations utiles au projet du SD.
66
Cependant, il est nécessaire de signaler que toutes les méthodes et techniques citées jusqu‟à maintenant concernant la sûreté de fonctionnement, se sont focalisées sur le traitement des exigences fonctionnelles-métiers du SD en mettant en arrière-plan les exigences non fonctionnelles y compris celles de SdF. Les causes résident souvent dans la considération de ce type d‟exigences comme des besoins techniques, et ne sont évoqués ainsi qu‟à la phase d‟implémentation du système. A notre connaissance seule la méthode DWARF leur a consacré une attention particulière. Cette méthode repose sur l‟utilisation d‟ un
Framework interactif orientée phase couplé d‟un ensemble de Templates, procédure s et techniques pour guider les développeurs durant le cycle d‟ingénierie 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 débuts de nos travaux de recherche. C ‟est pour cela que nous allons aborder quelques un de leurs aspects techniques durant le troisième chapitre de ce mémoire. Enfin la dernière partie de ce chapitre est consacrée aux travaux qui se sont intéressés à l‟ingénierie dirigée par les modèles dans le contexte des systèmes décisionnels. L‟objectif centrale de leurs contributi ons est d‟aligner le développement des SD à l‟IDM et de formaliser ainsi ce processus en se basant sur des standards. Nous avons décliné les approches selon deux grandes familles: celles qui se basent sur l‟utilisation de la méta-modélisation et celles spécifiques au standard MDA. Ainsi, la première famille de travaux s‟est intéressée à la formalisation et l‟automatisation du
processus d'élaboration d'ED en proposant un ensemble de métamodèles (conceptuel, logique et physique), une extension du langage OCL, et un ensemble de transformations. Ces travaux ont surtout attaqué la problématique d ‟élaboration des métadonnées, et ils ont proposé ainsi un métamodèle d‟intégration pour la gestion des métadonnées dans un ED en se basant sur le diagramme de classe d‟UML ou en utilisant des vues multicouches comme des aspects transversales. Toutefois l‟ED n‟est pas la se ule couche concernée par la méta-modélisation, car les travaux ont permis de définir un Framework de conception logique des activités ETL se basant sur un métamodèle conçu pour capturer plusieurs types d‟activités ETL et qui peut être instancié pour représenter un Workflow d‟activités. D‟un autre côté, les travaux qui se sont intéressé à la MDA ont surtout traité la couche ED en partant des modèles conceptuels sources et des besoins des décideurs ou par la détection de faits à partir de sources de données relationnelles. L‟approche centrale dans cette famil le est celle proposé dans [111] qui consiste en une démarche mixte pour l'élaboration des modèles PIM et PSM ainsi que les transformations pour l‟ensemble des couches du SD. D‟autres
travaux ont proposé une manière automatique pour générer le PSM à partir du PIM alors que
67
d‟autres ont visé à couvrir le cycle de développement des processus ETL et faciliter la
génération semi-automatique du code en se basant sur le BPMN. Par l‟analyse
de ces travaux nous redémontrons encore que les exigences non fonctionnelles ont été souvent négligées car la plupart des travaux se concentrent sur le fonctionnement du SD alors les expériences montrent que capturer des exigences non fonctionnelles sans les intégrer au modèle conceptuel peut conduire à un système défaillant. A notre connaissance, seul les travaux présentés dans [117] se sont intéressés à l‟aspect de la sécurité en proposant de préciser les mesures de sécurité et d'audit dès les premiers stades de la conception et de les faire respecter tout au long du cycle de vie en s‟appuyant sur le standard MDA, ce qui leur a permis de définir des transformations entre modèles à base du langage QVT. En se basant sur l‟état de l‟art précédant,
nous avons pu démontrer que dans le contexte du
DW, les attributs de la SdF ont été traité d‟une manière individuelle sans tenir compte de leur intégration. La seule méthodologie d‟ingénierie des exigences qui les a abordés ne les a pas pris en charge depuis les débuts de cycle de vie. En plus, malgré l‟intérêt de l‟IDM pour les SD, le seul aspect qui a été développé jusqu‟à aujourd‟hui est la sécurité. Dans ce contexte, notre contribution s‟inscrit dans l‟objectif de fournir une approche d‟ingénierie des exigences qui permet de tenir compte des aspec ts de la sûreté de fonctionnement ainsi que leurs interactions depuis les premières étapes du projet décisionnel en utilisant le standard MDA.
68
Chapitre 3 : Théorie de l‟Approche Proposée
« C'est la théorie qui décide de ce que nous pouvons observer. » Albert Einstein
69
3.1
Introduction
L‟objectif de ce chapitre est
de détailler théoriquement notre contribution qui vise à intégrer les aspects de SdF aux SD selon une approche dirigée par les modèles. Ainsi, nous allons présenter les notions de base de notre contribution avant de la détailler. Dans ce sens, nous allons présenter l‟approche MDA ainsi que son intérêt et son rôle. Ensuite nous allons définir les métamodèles utilisés pour la concrétiser à chaque étape ainsi que les outils de transformations permettant de transiter d‟un niveau d‟abstraction à un autre. Enfin, nous terminerons le chapitre par la présentation de la modélisation orientée aspect qui constitue l‟une des bases de notre proposition. 3.2
Les Modèles de l’approche MDA
La MDA est standard de l‟OMG qui ne définit pas une architecture middleware nouvelle, mais qui offre une représentation de l'architecture abstraite et indépendante de la plate-forme technique. De l‟autre côté, elle assure et maintient le lien avec une multitude de services métiers. La figure 8, présente une description du métamodèle du MDA [118].
Figure 8: Description du méta modèle du MDA [118]
Les modèles CIM, PIM, PSM, représentent respectivement le modèle des exigences, le modèle indépendant de la plate-forme et le modèle spécifique à la plate-forme technique. Le PIM, le PSM et les techniques de mappage sont basés sur des métamodèle représenté de préférence avec les standards définis 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 création d'une représentation UML de la logique métier en vue de l‟associer à des caractéristiques techniques ensuite. Des outils devraient permettre de générer des composants en fonction de l'architecture choisie (EJB : Enterprise JavaBean, CORBA,
70
Dot NET ou Services Web). Un travail de finalisation sera nécessaire pour affiner le modèle 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 métier et une génération du modèle spécifique à la nouvelle infrastructure cible. L'automatisation de la génération devra permettre de réduire la durée et les coûts de migration. De plus, un éditeur pourra envisager plus facilement d'éditer un logiciel pour les plates-formes techniques supportées par le MDA [34].
Figure 9: Processus de développement selon l’ approche MDA
La figure 9 donne une vue générale de l‟approche MDA. Nous constatons que son processus de développement commence par l‟élaboration d‟un ou de plusieurs modèles d‟exigences (CIM). Elle se poursuit par l‟élaboration des modèles d‟analyse et de conception abstraite de l‟application (PIM). Ceux-ci
doivent en théorie être partiellement générés à partir des CIM afin que des liens de traçabilité soient établis. Pour réaliser concrètement l‟application, il faut ensuite construire des modèles spécifiques
aux plates-formes d‟exécution. Ces modèles sont obtenus par une transformation des PIM en y ajoutant les informations techniques relatives aux plates- formes. Les PSM n‟ont pas pour vocation d‟être pérennes. Leur principale fonction est de faciliter la génération de code. Cette activité (c‟est à dire La génération de code à partir des modèles PSM ) n‟est d‟ailleurs pas 71
réellement considérée par MDA. Celle- ci s‟apparente plutôt à une traduction des PSM dans un formalisme textuel. 3.2.1
Modèle Indépendant de la plateforme: CIM (Computation Independent Model)
La première étape lors de la construction d‟une nouvelle application est de spécifier les exigences du client. Bien que très en amont, cette étape doit fortement bénéficier des modèles. L‟objectif est de créer un modèle d‟exigences de la future application. Un tel modèle doit représenter l‟application dans son environnement afin de définir quels sont les services offerts par l‟application et quelles sont les autres entités avec lesquelles elle interagit.
La c réation d‟un modèle d‟exigences est d‟une importance capitale. Cela permet d‟exprimer clairement les liens de traçabilité avec les modèles qui seront construits dans les autres phases du cycle de développement de l‟application. Un lien durable est ainsi créé entre les besoins du client et les différents modèles d‟analyse et de conception.
étant des éléments contractuels, destinés à servir de référence lorsqu‟on voudra s‟assurer qu‟une application est conforme aux demandes du client. Ainsi, Il est important de noter qu‟un modèle d‟exigences ne contient pas Les modèles d‟exigences peuvent être considérés comme
d‟information sur la réalisation de l‟application ni sur les traitements. C‟est pourquoi, dans le vocabulaire MDA, les modèles d‟exigences sont appel és des CIM (Computation Independent
Model), littéralement « modèle indépendant de la programmation ». Avec UML, un modèle d‟exigences peut se résumer à un diagramme de cas d‟utilisation. Ces derniers contiennent en effet les fonctionnalités fournies par l‟application (cas d‟utilisation) ainsi que les différentes entités qui interagissent avec elle (acteurs) sans apporter d‟information sur le fonctionnement de l‟application. Dans une optique plus large, un modèle d‟exigences est considéré comme une entité
complexe, constituée entre autres d‟un glossaire, de définitions des processus métier, des exigences et des cas d‟utilisation ainsi que d‟une vue systémique de l‟application. Si la MDA n‟émet aucune préconisation quant à l‟élaboration des modèles d‟exigences , des travaux sont en cours pour ajouter à UML les concepts nécessaires pour couvrir cette phase. Ainsi, le rôle des modèles d‟exigences dans une approche MDA est d e fournir les premiers modèles pérennes[118]. 3.2.2
Modèle d’analyse et de conception abstraite : PIM (Platform Independent Model)
Une fois le modèle d‟exigences réalisé, le travail d‟analyse et de conception peut commencer. Dans l‟approche MDA, cette phase utilise elle aussi un modèle. L‟analyse et la conception
sont depuis plus de trente ans les étapes où la modélisation est la plus présente, d‟abord avec les méthodes Merise et Coad/Yourdon puis avec les méthodes objet Schlear et Mellor, OMT, 72
OOSE et Booch. Ces méthodes proposent leurs propres modèles. Aujourd‟hui, le langage UML s‟est imposé comme la référence pour réaliser tous les modèles d‟analyse et de
conception. Cette étape consiste à structurer l‟application en modules et sous-modules. L‟application des patrons de conception, ou Design Patterns, du GoF (Gang of Four) fait partie de cette étape de conception. Par contre, l‟appl ication de patrons techniques, propres à certaines plates-formes, correspond à une autre étape. Nous ne considérons donc ici que la conception abstraite, c‟est à-dire celle qui est réalisable sans aucune connaissance des techniques d‟implémentation. La MDA considère que les modèles d‟analyse et de conception doivent être indépendants de toute plate-forme d‟implémentation, qu‟elle soit J2EE, .Net, PHP, etc. En n‟intégrant les détails d‟implémentation que très tard dans le cycle de développement, ce qui permet ainsi de maximiser la séparation des préoccupations entre la logique de l‟application et les techniques d‟implémentation.
Précisons que la MDA ne fait que précon iser l‟utilisation d‟UML et qu‟e lle n‟exclut pas l‟utilisation des autres langages. De plus, MDA ne donne aucune indication quant au nombre de modèles à élaborer ni à la méthode à utiliser pour élaborer ces PIM. Quels que soient le langage utilisé, le rôle des modèles d‟analyse et de conception est d‟être pérennes et de faire le lien entre le mod èle d‟exigences et le code de l‟application. Ces modèles doivent par ailleurs être productifs puisqu‟ils constituent le socle de tout le processus de génération de code défini par MDA. La productivité des PIM signifie qu‟ils
doivent être suffisamment préci s et contenir suffisamment d‟information pour qu‟une génération automatique de code soit envisageable [118]. 3.2.3
Modèle du code ou de la conception concrète : PSM (Platform Specific Model)
Une fois les modèles d‟analyse et de conception réalisés, le travail de génération de code peut
commencer. Cette phase, la plus délicate du MDA, doit aussi utiliser des modèles. Elle inclut l‟application des patrons de conception techniques. La MDA considère que le code d‟une application peut être facilement obtenu à partir des modèles de code. La différence principale entre un modèle de code et un modèle d‟analyse ou de conception réside dans le fait que le
modèle de code est lié à une plate- forme d‟exécution. Dans le vocabulaire MDA, ces modèles de code sont appelés des PSM (Platform Specific Model). Les modèles de code servent essentiellement à faciliter la génération de code à partir d‟un modèle d‟analyse et de conception. Ils contiennent toutes les informations nécessaires à l‟exploitation d‟une plate-forme d‟exécution, comm e
les informations permettant de
manipuler les systèmes de fichiers ou les systèmes d‟authentification.
73
Il est parfois difficile de différencier le code des applications des modèles de code. Pour MDA, le code d‟une application se résume à une suite de lign es textuelles, comme un fichier Java, alors qu‟un modèle de code est plutôt une représentation structurée incluant, par
exemple, les concepts de boucle, condition, instruction, composant, événement, etc. La génération de code à partir d‟un modèle de code e st donc une opération assez triviale. Pour élaborer des modèles de code, MDA propose, entre autres, l‟utilisation de profils UML.
Un profil UML est une adaptation du langage UML à un domaine particulier. Par exemple, le profil UML pour EJB est une adaptati on d‟UML au domaine des EJB. Grâce à ce profil, il est possible d‟élaborer des modèles de code pour le développement d‟EJB selon [118]. 3.2.4
Transformation
Nous venons de passer en revue les trois types de modèles les plus importants pour MDA qui sont les CIM, PIM et PSM. Nous avons aussi vu qu‟il était important de bien établir les liens
de traçabilité entre ces modèles. En fait, MDA établit ces liens automatiquement grâce à l‟exécution de transformations des modèles.
Les transformations de modèles préconisées par MDA sont essentiellement les transformations CIM vers PIM et PIM vers PSM. La génération de code à partir des PSM n‟est quant à elle pas considérée comme une transformation de modèle à part entière. 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 modèles sont très importantes dans la MDA. Car, ce sont elles qui porten t l‟intelligence du processus méthodologique de construction d‟application. Elles sont stratégiques et font partie du savoir -faire de l‟entreprise ou de l‟organisation qui les exécute, car elles détiennent les règles de qualité de développement d‟applications.
Conscient de cela, MDA préconise de modéliser les transformations de modèles elles-mêmes. 3.3
Présentation de la méthode proposée 3.3.1
Détails du mécanisme de l’approche proposée
Notre proposition a pour objectif de fournir une démarche de conception des SD, en tenant compte des contraintes de SdF, dès les premières phases de modélisation. Vu que ces dernières varient selon le domaine d‟utilisation du SD , nous proposons une approche générique alignée au standard MDA permettant de les intégrer d‟une manière raffinée et incrémentale. Et bien sûr selon les di fférents niveaux d‟abstraction pour s‟assurer de leur traçabilité, et de vérifier leur intégrité tout en tenant compte de leurs interaction. La figure cidessous représente explicitement l‟architecture de notre contribution.
74
Figure 10: Démarche de l’ Approche Proposée
Notre démarche englobe l‟ensemble du projet décisionnel. Toutefois, le SDW étant lui-même
un système hétérogène, à cause des plateformes qui le composent (DS, ETL, DW, outils d‟analyse nous avons donc adapté la stratégie « Diviser pour conquérir ». Elle co nsiste d‟une part à traiter chaque couche en préservant ses propres caractéristiques, et d‟autre part de traiter ses exigences de SdF en tenant compte des couches environnantes. Ainsi, nous proposons de partitionner l‟architecture standard des SDW selon 4 couches: les DS, l‟ETL, le DW et les outils d‟analyse. Ensuite , nous préconisons de mener une étude qualitative pour lister l‟ensemble des exigences influençant les aspects de SdF pour chaque couche afin de les modéliser d‟une part. Ensuite, nous proposons de les intégrer et traiter leurs interactions en respectant les niveaux d‟abstraction du standard MDA [120]. Pour mettre en œuvre notre approche nous avons suivi les étapes détaillées de la figure 11 :
75
Figure 11: Méthodologie de l'Approche
3.3.2
Niveau des Exigences
Cette partie est consacrée à l‟étude 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 appuyés sur le fait que la disponibilité et la fiabilité sont très rapprochées (cf. chapitre 1 et 2), et elles seront donc regroupées dans la suite de notre approche. Nous proposerons dans ce qui suit, d‟énumérer de manière exhaustive l‟ensemble des exigences qui influencent la SdF positivement ou négativement. 3.3.3
Niveau Indépendant de la Programmation
La création des modèles CIM à ce niveau permet d‟exprimer clairement les exigences de SdF afin d‟assurer une traçabilité avec les modèles qui seront construits dans les autres phases du cycle de développement du SD.
76
Pour ce faire nous avons choisis d‟utiliser le NFR (Non Functional Requirement ) Framework [121] qui fournit un profil UML appelé le profil SoftGoal. Ce Framework est jugé le plus adéquat selon [122] pour modéliser les exigences de SdF ainsi que leur interaction. 3.3.3.1
Pr é sentati on et i nté rêt du NF R F ramewor k
L‟idée principale du NFR
Framework se concentre sur la modélisation et l‟analyse des exigences non-fonctionnelles, afin qu‟elles soient prises en considération par l‟analyste avant même les exigences fonctionnelles. La méthode consiste à systématiquement modéliser et raffiner les NFRs et à étudier les interdépendances (les influences, les priorités). Pour cela, le NFR Framework se base sur les « softgoals » qui sont divisés en trois types [123]: les softgoals NFR: représentent les NFRs à prendre en considération. les softgoals d‟opérationnalisation: modélisent les techniques permettant de satisfaire les softgoals NFR. les claims softgoals : permettent à l‟analyste de justifier ses choix pour le raffinement de softgoals, les priorités entre softgoals, etc.
Les softgoals peuvent être raffinés en utilisant le raffinement ET/OU. Les interdépendances entre les softgoals peuvent généralement être capturées avec des contributions positives (+) ou négatives (-). Tous ces concepts sont représentés graphiquement grâce au graphe d‟interdépendance des softgoals SIG (Softgoal Interdependency Graph). Le NFR Framework offre une démarche qui s‟appuie sur les activités suivantes [124] :
la capture des softgoals NFR. le raffinement des softgoals NFR.
l‟identification des softgoals d‟opérationnalisation pou r
satisfaire les softgoals
NFR.
l‟étude des ambiguïtés, des compromis, des priorités et des interdépendances entre
les NFRs.
l‟analyse des différentes alternatives d‟opérationnalisation pour
déterminer leur
impact sur les NFRs de hau t niveau. L‟analyste sélectionne enfin l‟alternative qui répond le mieux aux NFRs de haut niveau. L‟ensemble des softgoals d‟opérationnalisation pour l‟alternative sélectionnée peut être alors implémenté dans le futur logiciel. 3.3.3.2
Mé cani smes du NF R F ramewor k
démarche, le NFR Framework fournit un ensemble de catalogues stockant les connaissances de conception. Ces catalogues sont de trois types [125] : Afin de faciliter la tâche de l‟analyste tout au long de cette
Ŕ Les catalogues des types NFR qui incluent des concepts sur des types particuliers des NFR,
tels que la performance, la sécurité, etc. 77
Ŕ Les catalogues des méthodes qui encodent les connaissances aidant dans le raffinement des
softgoals et dans l‟opérationnalisation. Ŕ Les catalogues des règles de corrélation qui stockent les connaissances aidant à détecter les
interdépendances implicites entre les softgoals. Par exemple, le catalogue permet d‟inclure le fait que l‟indexation contribue positivement au temps de réponse. En se basant sur ces catalogues nous proposons d‟élaborer les CIM de chacun des attributs de
SdF qui seront traités autant que SoftGoal. Pour les décomposer, les affiner et traiter leur interaction. Le schéma de la figure 12 représente un exemple de l‟utilisation du NFR Framework élaboré par shung et al. dans [126].
Figure 12: Exemple d’un SIG
La nomenclature utilisée pour représenter un SIG est la suivante :
Les nuages légers dans un SIG indiquent un softgoal. Ce dernier a la nomenclature suivante: Type [Rubrique1, Rubrique2, ..., Rubriquen], où Type est un aspect nonfonctionnel (par exemple la sécurité), et la rubrique est un sujet du système cible auquel est associé le softgoal (par exemple comptes bancaires). Les rubriques peuvent encore être décomposées en attributs, représentés 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 opération, (iii) une contrainte, (iv) autre composant architectural. Les lignes entre les nuages sombres et légers indiquent le degré avec lequel le softgoal de conception (correspondant au nuage sombre) satisfait le NFR (représenté par le
78
nuage léger). La satisfaction peut se présenter selon quatre niveaux: fortement positive (++), positive (+), négatif (-), fortement négative (--).
Les criticités d‟un softgoal sont représentées par le symbole "!". Un arc simple représente la relation logique AND entre différents softgoals provenant d'un softgoal. Par contre, un arc double signifie une relation logique OR entre les soussoftgoals. nuages des softgoals NFR basée sur le degré de satisfaction et de leurs criticités. Ainsi le symbole V représente une contribution positive de ce softgoal dans le SIG alors que le symbole X représente une contribution négative. Enfin, une procédure interactive d‟étiquetage est utilisée pour étiqueter les
3.3.4
Niveau Indépendant de la Plateforme
Dans cette partie, n ous proposons d‟élaborer les modèles indépendants de la plateforme (PIM). Ainsi, à ce stade le NFR Framework n‟est plus approprié car nous devons avoir des modèles d‟un autre niveau d‟abstraction. Dans ce sens, nous proposons d‟utiliser le profil QoS-FT (Quality of Service Ŕ Fault tolerance) [127]. Il permet la modélisation des aspects de la qualité de service et de la tolérance aux fautes des systèmes, pour des fins d'analyse et de conception. Ce profil se base sur la construction de modèles pouvant être employés pour faire des prévisions quantitatives concernant les caractéristiques de QoS. Ces modèles facilitent également la communication entre les développeurs d'une façon standardisée. Ils permettent aussi l'interopérabilité entre les divers outils d‟analyse et de conception [128]. 3.3.4.1
Profil QoS-F T
Pour assurer la consistance lors de la modélisation des diverses qualités de service, le profil QOS-FT permet de définir un cadre standard ou un modèle de référence dans le contexte UML qui inclut [127]:
La catégorisation générale des différents genres de QoS y compris les spécifications de QoS définies lors de la conception. Cette catégorisation distingue plusieurs caractéristiques :
Caractéristiques relatives au temps (délai, fraîcheur).
Caractéristiques en rapport avec l‟importance (priorité, précédence).
Caractéristiques en rapport avec la capacité (débit, capacité).
Caractéristiques en rapport avec l‟intégrité (exactitude).
Caractéristiques en rapport avec la sécurité.
79
Caractéristiques de disponibilité et de fiabilité.
L‟identification des éléments conceptuels de base impliqués dans la QoS et leurs
rapports mutuels. Ceci implique la capacité d'associer des caractéristiques de la QoS aux éléments du modèle (spécification). Un modèle générique pour l'approvisionnement de la QoS (modèle de contrôle) est à associer aux cas d'utilisation (modèle d'utilisation).
Une catégorisation générale des différents types de fautes.
Une identification des éléments conceptuels de base impliqués dans la tolérance aux fautes et leurs rapports mutuels. Ceci implique (i) la capacité d'associer des caractéristiques de tolérance aux fautes aux éléments du modèle (spécification), (ii) un modèle générique des intervenants dans des activités relatives aux tolérances aux fautes et des cas d'utilisation (modèle d'utilisation), et (iii) un modèle générique représentant la façon dont les mécanismes de tolérance aux fautes sont gérés (modèle de contrôle). 3.3.5
Transformations du CIM au PIM
Selon les travaux cités dans [38], trois approches de transformation de modèles sont reconnues :
Approche par programmation: basée sur les langages de programmation en général orientés objet pour décrire les transformations. Approche par Template : basée sur des canevas pour les modèles cibles. La transformation consiste à remplacer les paramètres du canevas cibles par les valeurs du modèle source. Approche par modélisation : qui permet de modéliser les transformations pour les rendre plus productifs. Le standard MOF 2.0 QVT( Query / Views / Transformation) a été proposé par l‟OMG [129] pour définir le méta modèle des transformations. Dans cette approche les transformations se font selon des règles qui décrivent la correspondance entre les entités du modèle source et destination. Cette transformation est prise en charge par plusieurs langages de transformation dont l‟ATL (Atlas Transformation Language) [130]. Nous avons choisis ce langage pour définir nos transformations. 3.3.5.1
Atl as Tr ansfor mation Lan gage (ATL )
ATL a été conçu pour réaliser des transformations d‟un ou plusieurs modèles sources vers un ou plusieurs modèles cibles dans le cadre de l‟approche MDA. ATL est un langage hybride car il permet l‟expression des règles de transformations déclaratives et impératives à la fois [131]. Sa syntaxe abstraite a été définie par un modèle MOF [37] présenté dans la figure 13. Il possède également une syntaxe textuelle concrète. 80
Figure 13: Syntaxe abstraite des règles de transformation extraite du Métamodel ATL [131]
3.3.5.2
Mécanisme de l’ATL
Une transformation ATL permet de transformer un modèle source en modèle cible en se basant sur les éléments définis dans les métamodèles impliqués (voir figure 14). Elle est décrite par un ensemble de règles de transformation. ATL permet de naviguer dans les modèles en utilisant des requêtes sous forme d‟expression OCL (Object Constraint Language)
[132]. Les règles de transformation sont appliquées en cherchant dans le modèle source les éléments qui respectent leur pattern source pour les transformer en des éléments du modèle cible. MOF
Source
ATL
Target
SourceM2Tar etM.atl Source Model
Tar et Model
Figure 14: Mécanisme des transformations ATL
3.3.6
Niveau Spécifique à la Plateforme
A ce niveau les détails de l‟implémentation technique doivent être in clus
pour élaborer les PSM. Cependant, nous avons vu dans le premier chapitre que les SD sont constitués de couches hétérogènes : DS, ETL, DW, et outils de restitutions. Cette hétérogénéité rend complexe la réalisation du PSM des aspects de la SdF pour tout le système. Ce qui impose une réalisation de plusieurs PSM pour chacune des couches, comme le montre la figure 15. Il faut souligner que ces modèles doivent être incorporés aux modèles représentant les exigences fonctionnelles. D‟où l‟intérêt de la modélisation orientée a spect qui offre des mécanismes de tissage de ces aspects transverses aux fonctionnalités du système au niveau modèle.
81
Figure 15: Elaboration des PSM pour chaque couche
3.3.6.1
M odé lisation Or ienté e Aspect
L'approche AOM (Aspect Oriented Modeling) est définit dans les travaux [133], [134]. Elle reprend les principes définis par AspectJ [135] (langage de programmation orienté aspect) afin de proposer un moyen de modéliser et de mieux appréhender les programmes orientés 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 modèles. Alors la définition d‟un aspect comporte deux entités : le modèle de la préoccupation transverse (Advice), et des patrons de modèle permettant de capturer les points d‟application de l‟aspect (point de
coupure Pointcuts). Quant à la génération du modèle global (exprimant l‟ensemble des préoccupations), elle repose sur la composition du modèle de base avec le modèle d‟aspect. Cette composition (généralement appelée tissage d‟aspect) met en œuvre deux opérations : la
détection des p oint de jonctions où l‟aspect doit être appliqué, et le remplacement des fragments identifiés par la nouvelle structure définie dans l‟advice.
3.3.6.2
I nté rêt et mé canismes de l’Or i enté Aspect:
Notre approche repose sur la séparation des préoccupations fonctionnels et des aspects SdF. Toutefois, l‟intégration de ces deux éléments au niveau du code rend la mise en œuvre du système délicate et sa maintenance difficile. Pour pallier ce problème, nous proposons d‟utiliser la technique orientée aspect pour tisser les aspects de SdF sur le modèle fonctionnel. Ainsi, nous proposons d‟élaborer les PSM des
82
aspects de SdF et ensuite les tisser avec les PSM fonctionnels afin d‟avoir 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 indépendance vis à vis du langage de programmation. Donnant ainsi plus de liberté dans le choix du langage d‟implémentation. D‟un autre côté parmi les avantages du développement o rienté
aspect, la qualité du code est amélioré. Il est ainsi plus facile de comprendre les aspects et les modules de base et de changer des préoccupations. De plus, le couplage entre les modules gérant des aspects techniques peut être réduit de façon importante, et chaque module est maintenue indépendamment des autres ce qui offre une meilleure réutilisation : tout module peut être réutilisé sans se préoccuper de son environnement, chaque module implémente une fonctionnalité précise, des nouvelles fonctionnalités pourront être implémentées dans de nouveaux modules qui interagissent avec le système à travers des aspects. 3.4
Synthèse
de notre approche pour traiter les exigences de SdF des systèmes décisionnels. Dans un premier lieu, nous avons présenté l‟approche MDA qui constitue la base de nos travaux. Le choix de ce Ce chapitre permet de présenter une vue panoramique sur l‟ensemble des étapes
standard a émané du besoin d‟un cadre méthodologique standardisé et formel pour y inscrire
83
notre approche. Ce besoin a été le fruit de l‟étude de l‟état de l‟art (cf chapitre 2) qui a soulevé la problématique de l‟absence des méthodes qui permettent la prise en compte des exigences de SdF dès les premières étapes du projet du SD. La MDA est une des propositions de l‟OMG pour concrétiser le concept de l‟IDM. Ce concept est une tentative pour dépasser les limitations de l‟approche orientée objet d‟un côté et celui de CORBA d‟un autre côté en proposant une remonté en abstraction et une concentration sur les modèles comme unité productifs au lieu de leurs fonction contemplative ou expressive. La MDA concrétise les concepts de l‟IDM en préconisant l‟utilisation des modèles CIM, PIM et PSM et en facilitant le pass age d‟un niveau d‟abstraction à un niveau inférieur par l‟utilisation des transformations de modèles. En s‟alignant au cadre méthodologique offert par la MDA, notre méthode propose à chaque niveau d‟abstraction l‟utilisation du métamodèle le plus adéquat pour modéliser les exigences de SdF des SD et tenir compte de leurs particularités. Ainsi au niveau des exigences, nous proposons l‟utilisation du profil SIG pour exprimer des modèles CIM. En effet, le NFR Framework a prouvé son efficacité à modéliser les premières 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 pro posons d‟utiliser le p rofil QoS-FT afin de modéliser les PSM. Ce dernier est un standard de l‟OMG pour modéliser les exigences et les propriétés en termes de qualité de service et de la tolérance aux fautes qui est l‟une des moyens pour assurer la SdF (Voir 3 ème section du 1 er chapitre). Enfin, au niveau de la conception concrète qui est le niveau le plus proche du code, nous avons opté pour l‟utilisation des diagrammes de Composant de Déploiement d‟UML, ce qui nous a permis de constituer des modèles de bas niveau afin de pouvoir concrétiser notre approche. de ces métamodèles pour réaliser les modèles de chaque étape, et enfin termine par une étude de cas qui prouve la faisabilité ainsi que le bénéfice de notre approche Le chapitre suivant détaille d‟avantage la mise en œuvre
84
Chapitre 4 : Mise en Œuvre
« Mettez toutes les leçons des jeunes gens en action plutôt qu'en discours. » Jean-Jacques Rousseau
85
4.1 Introduction
concepts présentés précédemment. Pour ce faire, nous allons détailler la réalisation de chaque étape en élaborant les modèles des attributs de SdF (CIM, PIM, PSM). Ainsi que les transformations nécessaires pour pouvoir aboutir au code. Notre proposition sera illustrée par un cas d‟études issue du domine de la santé publique afin de démontrer son intérêt. Ce chapitre met en œuvre les
4.2 Niveau des Exigences
A ce niveau, les exigences de la SdF doivent être séparées 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 décomposé le SD selon ses 4 couches afin de trouver les paramètres qui influencent directement les aspects de SdF. Nous nous somme basés sur l‟état de l‟art afin d‟énumérer d‟une manière non exhaustive ces paramètres par couche (DS, ETL, DW, OR). On propose dans ce qui suit un catalogue des paramètres de SdF communs. Ce catalogue peut être mis à jour en fonction de la nature et du type du projet décisionnel d‟un côté , et du niveau de priorité et de criticité des exigences de SdF d‟un autre côté. 4.2.1
Source de Données (DS)
Disponibilité et fiabilité:
Volumétrie, Optimisation, Qualité donnée, Support,
Réplication > tel que : Structuration
Volumétrie
Optimisation
Qualité donnée
Support
Maintenabilité: tel que :
Documentation
Structuration
Optimisation < fragmentation, indexation, vue>
Support
Sécurité: tel que :
Gestion utilisateur
Donnée
Support< pare-feu, cryptage, réplication>
4.2.2
Extraction, Transformation, Loading (ETL)
Disponibilité et fiabilité:tel que
86
Qualité Donnée
Périodicité
Nettoyage Complexité < volume donnée, règles calcul, nombre source données>
Support Maintenabilité: tel que :
Métadonnée
Modularité < interdépendance transformations, décomposition sous-systèmes>
Complexité < règles calcul, nombre source>
Restauration< gestion recouvrements, gestion exceptions>
Sécurité: tel que :
Gestion Intrusion
Audit
Restauration< gestion recouvrements, gestion exceptions>
4.2.3
Entrepôt de Données (DW)
Disponibilité et fiabilité:
Volumétrie, Complexité, Réplication, Optimisation, Support, Périodicité chargement> tel que :
Schéma <étoile, flocon, constellation>
Complexité
Volumétrie
Optimisation < vue, fragmentation, indexes, parallélisme>
Support
Maintenabilité: tel que
Documentation
Architecture
Complexité
Optimisation < fragmentation, indexation, vue, parallélisme>
Support
:
Sécurité: tel que :
Gestion utilisateur
Gestion donnée < intégrité, authenticité, complétude, verrouillage,>
Support 87
4.2.4
Outils de Restitution (OR)
Disponibilité et fiabilité: tel que :
Type
Volumétrie
Complexité
Support
Maintenabilité: tel que :
Type
Documentions < métadonnée, requêtes, indicateurs, règles de calcul >
Modularité < interdépendance, parallélisme>
Complexité
Sécurité: tel que :
Gestion utilisateur
Gestion donnée< intégrité, validité, confidentialité>
Support
88
Phase Du SD Disponibilité et fiabilité
Source Donnée
Maintenabilité
Sécurité
semi structuré, non structuré> Documentation transaction, Nbre Enregistrement> Structuration fragmentation, vue, parallélisme> structuré> Optimisation Optimisation< fragmentation, indexation, complétude, verrouillage> Support vue> support< pare-feu, cryptage, réplication …> Support Réplication Métadonnée
ETL
DW
Destination, Opérations de Nettoyage, règles gestion, contraintes> Qualité Donnée Interdépendance des Gestion intrusion Normalisation, élimination: doublon, Aberrante, manquante> Nettoyage , validation de la conformité de Audit temps réel, cycle rafraîchissement> Périodicité Restauration< Gestion des recouvrements, complexité Complexité< règles calcul, nombre source> Gestion des exceptions> Support Restauration< Gestion des recouvrements, Gestion des exceptions> Documentation dimension> Schéma<étoile, Volumétrie Architecture consolidation Réplication Complexité
indexes,
schéma,
distribuée, Gestion utilisateur quotas, audit, hiérarchie> dimensions, Gestion de Donnée < intégrité, authenticité , complétude, verrouillage,> chargement granularité> parallélisme> Optimisation< fragmentation, indexation, Support vue, parallélisme> Support
Type
Ad hoc, requête paramétrable, tableau de bord, cube Typetableau de bord, cube OLAP, Data Mining..>Gestion utilisateur Documentions< Métadonnée, requêtes, quotas, audit, hiérarchie, > Outils de Volumétrieindicateurs, règles de calcul > Gestion de Donnée < intégrité , validité, Complexité Support Modularité confidentialité, transformation, Support Complexité OLAP,
Tableau 2: Les paramètres de sûreté de fonctionnement des systèmes décisionnels par couche et par attribut
Le tableau précédant récapitule les paramètres Que nous venons de décrire en distinguant entre les paramètres qui améliorent les attributs de SdF (en vert), et ceux qui représentent des contraintes (en rouge) dont il faut tenir compte lors de la réalisation du SD. 4.3 Niveau Indépendant de la Programmation (CIM)
Nous avons proposé précédemment d‟utiliser le NFR Framework pour faciliter l‟élaboration des modèles à ce niveau d‟abstraction. Dans les sections suivantes nous allons élaborer les SIG (Soft Goal Interdependency Graph) de chaque attribut de la SdF en exploitant les paramètres détaillés 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 décomposée en fiabilité et distributivité. Pour raffiner ces softgoals, nous avons intégré les paramètres retenues du niveau des exigences. Ainsi pour améliorer la fiabilité on peut utiliser les techniques d‟optimisation détaillées dans le chapitre 2, et prendre en considération la complexité du SD (voir figure 17). Cette dernière dépend de la périodicité du chargement du système, du volume et de la qualité des données.
Figure 17: CIM de la disponibilité et de la fiabilité
Quant à la distributivité, elle peut être améliorée en utilisant les techniques de réplication et/ou en tenant compte des contraintes des supports utilisés par le SD. Ces derniers peuvent être résolus grâce à l‟application des techniques de fragmentation et de parallélisme cité auparavant dans le chapitre 2. 90
4.3.2
CIM de la maintenabilité
Malheureusement, les travaux présentés dans[103] n‟ont pas traité la maintenabilité des SD, et donc nous avons dû proposer notre propre catalogue pour l‟affiner à base des catalogues qu‟ils ont proposé et de notre étude de l‟état de l‟art .
Figure 18: CIM de la maintenabilité
Ainsi pour assurer la maintenabilité des SD, nous proposons de développer 4 aspects à savoir : la modularité, l‟optimisation, la documentation et tenir com pte des contraintes de support comme est schématisé dans la figure 18. La modularité améliore la maintenabilité mais, il faut y avoir un certain niveau d‟interdépendance entre les modules du SD pour faciliter leur maintenabilité. En plus il faut penser à la documentation du système du point de vue sources de données, transformations et métadonnée. D‟un autre côté, les techniques d‟optimisation telle que le parallélisme offrent plus de maintenabilité au SD, toutefois il faut tenir compte de la complexité déjà affiné dans la figure 17. Enfin, les contraintes de maintenabilité des supports doivent être prises en comptes en leurs appliquant les techniques adéquates qui augmentent leurs maintenabilités. 4.3.3
CIM de la sécurité
Le catalogue représenté par la figure 19 décompose la sécurité selon 3 aspects : la disponibilité, l‟intégrité et la confidentialité. La disponibilité a été déjà traitée dans la figure 17. L‟intégrité dépend du support et du niveau d‟intégrité des donnée manipulé par le SD qui peut être amélioré en utilisant les techniques de nettoyage, mais qui peut être influencé par les intrusions qui nuisent aussi à la confidentialité. Cette dernière peut être améliorée en intégrant
91
les techniques de gestion des utilisateurs. La figure 19 schématise l‟ensemble des paramètres qui influent directement et indirectement la sécurité des SD.
Figure 19: CIM de la sécurité
4.3.4
CIM intégrale de la SdF
Parmi les objectifs phares de notre sujet de recherche est le traitement des interactions des attributs de la SdF. Ainsi, les modéliser n‟est pas suffisant pour détecter ces interactions et résoudre leurs conflits. Par ailleurs, le choix de l‟utilisation du NFR Framework été fait surtout grâce à sa possibilité de détecter les conflits entre les différents softgoals et leurs opérationnalisations. Dans ce sens nous proposons d‟intégrer les 3 CIM élaborés précédemment et conservant les
paramètres en commun des attributs de la SdF afin de pouvoir détecter leurs conflits et ne retenir qu‟une combinaison optimale qui assurera la SdF du système selon le niveau exigé par ses utilisateurs. A ce niveau et comme nous avons déjà précisé dans la méthodologie détaillée dans la figure 11 , si les conflits n‟ont pas pu être résolue, il faut penser à retourner à l‟étape précédente afin de redétailler les exigences avec l‟utilisateur. La figure 20 illustre un extrait du CIM intégrale qui rassemble les attributs de la SdF, et souligne les paramètres en interaction positive ou conflictuelle. Dans cet exemple la distributivité améliore la disponibilité mais diminue les degrés de confidentialité et
92
d‟intégrité. Et donc si la distributivité est exigé e par l‟utilisateur ,
il faut trouver soit un
équivalent ou préciser la cause de son élimination.
Figure 20: CIM intégrale de la SdF pour la détection des interactions
4.4 Niveau Indépendant de la Plateforme
Selon notre approche, nous prop osons l‟utilisation du profil QoS-FT que nous avons détaillé dans le chapitre précédant. Toutefois nous tenons à souligner que ce profil est très général car il traite l‟ensemble des aspects de la qualité de service et de la tolérance aux fautes pour tout type de système. Or ce qui nous concerne c‟est les aspects de sûreté de fonctionnement dans le contexte du SD. Dès lors, nous proposons de se limiter aux stéréotypes suivants : “QoSStatement“ pour distinguer l‟aspect de la SdF, “QoSConstraint“ pour préciser que le paramètre e st une contrainte qui doit être prise en compte lors de l‟élaboration du système et “QoSparameter “ pour préciser que c‟est un paramètre sur lequel on peut agir pour améliorer les aspects ou leur combinaison. Enfin nous avons utilisé deux types d‟associatio n : “QoSrelation“ et l‟héritage.
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 paramètres déjà traités mais cette fois ci selon une perspective plus informatisée, c‟est-à-dire, plus affinée mais sans entrer dans les détails de la plateforme. Dans ce sens nous avons précisé que le volume de données peut dépendre du volume des données des sources de données ou de l‟entrepôt. En plus, nous avons détaillé les techniques d‟optimisation en citant les vues, la fragmentation et les indexes,
et nous avons spécifié que la complexité du système est causée par la complexité du DW, du ETL et des outils de restitution. E nfin nous avons énuméré l‟ensemble des types utilisé s tels que le type de structure des données sources, le type du nettoyage, le type de schéma de l‟entrepôt de données, le type de la qualité de donnée, le type de périodicité, le type de fragmentation et des outils de restitution, et enfin le type du stockage temporaire. 4.4.2
PIM de la maintenabilité
De même le PIM de la maintenabilité illustré sur la figure 22 reprend le CIM de la maintenabilité en lui ajoutant plus de détails sans entrer dans les spécificatio ns d‟une plateforme donnée. Ainsi nous avons précisé les attributs des métadonnées pour assurer une bonne documentation, en plus nous avons détaillé les techniques de restauration et de modularisation qui seront améliorées par le parallélisme. 94
Toutefois nous soulignons que plusieurs paramètres déjà cités pour la fiabilité et la disponibilité sont repris pour la maintenabilité ce qui redémontre que les aspects de SdF sont en interaction et qu‟une bonne combinaison des paramètres à implémenter peut fournir un niveau de SdF optimal.
Figure 22: PIM de la maintenabilité
4.4.3
PIM de la sécurité
De même pour la sécurité, nous avons intégré les techniques qui influencent la sécurité positivement ou négativement indépendamment des détails d‟une plateforme précise (voir figure 23). Ainsi nous avons cité des techniques de gestion des utilisateurs telles que les permissions, les audits, l‟authentification, les quotas et les hiérarchies. Et nous avons aussi
précisé les techniques de la gestion des données qui s‟articulent autour de la confidentialité, l‟intégrité, l‟authenticité, la com plétude et le verrouillage. Et enfin, nous avons cité les techniques permettant de sécuriser le support comme la réplication, restauration et le pare-feu. 4.4.4
PIM Intégral de la SdF
Après l‟élaboration de PIM des différents aspects de SdF, nous proposons de les intégrer dans un seul PIM qui va permettre de confronter l‟ensemble des paramètres et techniques pour
ensuite essayer de retenir ceux qui améliorent au maximum les attributs de SdF dans leur globalité en fournissant un optimum qui doit bien entendu respecter le niveau exigé par 95
l‟utilisateur final du système. La figure 24 est un extrait du PIM intégral fait surgir la
fragmentation comme technique qui influence dire ctement ou indirectement l‟ensemble des aspects de SdF.
Figure 23: PIM de la sécurité
Figure 24: PIM Intégral de la SdF
96
4.5 Transformations du CIM au PIM
Ainsi pour réaliser les transformations du CIM en PIM dans notre approche, nous avons défini les transformations ATL entre les métamodèles NFR et QoS-FT comme le montre la figure 25. La dite transformation doit être exprimée sous la forme d‟expressions OCL qui est la base des transformations ATL. MOF
NFR Framework Profil
ATL
QoS FT Profil
CIM2PIM.atl CIM
PIM
Figure 25: Transformation ATL du CIM NFR au PIM QoS
Le profil QoS FT est déjà présenté dans le chapitre précédent. 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 stéréotypes NFRSoftgoal et des OperationalizingSG dans notre contexte peuvent représenter plusieurs notions du Définies par le profile QoS-FT. Ainsi pour faciliter la spécification de la transformation entre les deux profils, nous proposons d‟étendre le profil SIG présenté dans la figure 26 en précisant les différents types que peuvent prendre le softgoal
et
l‟OperationalizingSG.
La figure
suivante
schématise
cette
spécialisation. 97
Figure 27: Spécialisation du NFR Framework
Ainsi, un aspect peut être un softgoal seulement contrairement aux paramètres et contraintes qui peuvent être soit des NFRSoftgoal ou OperationalizingSIG. Dans l‟autre sens , les stéréotypes NFRSoftgoal et OperationalizingSG peuvent représenter dans notre contexte soit un aspect de la sûreté de fonctionnement, soit un paramètre ou une contrainte sur ce dernier. Cette spécialisation a permis plus de flexibilité du NFR Framework et plus de facilité pour l‟élaboration des règles de transformation qui sont déta illées 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. ii.
iii.
}else{
cl.applyStreotype(thisModule.QoSCharacteristic ) if(sg.hasStereotype('Constraint'){
1.
cl.cl.applyStreotype(thisModule.QoSConstraint)}
2.
else{
3.
cl.cl.applyStreotype(thisModule.QoSParameter)}
} 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. ii.
if(os.hasStereotype('Parameter'){ 1.
16.
cl.applyStreotype(thisModule.QoSConstraint)} cl.cl.applyStreotype(thisModule.QoSParameter)}
thisModule.rootQos.packagedElement<-cl; }}
98
4.6 Niveau Spécifique à la Plateforme
Le niveau spécifique à la plateforme exige l‟intégration de la plateforme dans les modèles. Toutefois les modèles PIM, résultantes du niveau précédant, ont été élaborés indépendamment des plateformes et en intégrant les différentes couches (DS, ETL, DW, OR) . L‟objectif est de tenir compte des interactions entre les différents aspects de SdF du SD en entier et non pas d‟une couche ou d‟une plateforme spécifique. On va réaliser les PSM de ce niveau selon deux étapes. La première consiste à réaliser des PSM spécifiques à chaque couche du SD. Ensuite, on va réaliser pour chaque couche des PSM spécifiques à la plateforme d‟implémentation (Oracle, Business Object, Pentaho etc.). La figue suivante schématise notre proposition à ce niveau.
Figure 28: Elaboration des PSM à partir du PIM Intégral
Pour élaborer le PSM on va dériver à partir du PIM, les aspects propres à chaque couche dans une première phase. Ensuite, on va tisser ce dernier avec le PSM modélisant les exigences fonctionnelles. Ainsi on va obtenir un PSM déployable sur un environnement d‟exécution. Le principe de tissage offert pat l‟AOM va permettre l‟élaboration des modèles PSM intégrales contenant à la fois la logique métier avec ces exigences de SdF. Ces derniers peuvent être modélisés par des diagrammes de déploiement pour faciliter leur mise en œuvre. La figure 29 présente le PSM dérivé 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 modélisation orientée aspects, nous proposons une représentation des paramètres et contraintes des aspects de la SdF ainsi que le tissage sous forme de composants stéréotypés. Selon [139], les diagrammes de déploiement et de composant sont les mieux adaptés pour expliciter la modularisation préconisée de l‟AOSD. La figure 30 représente un exemple de tissage du PSM des aspects de SdF du DW avec les exigences fonctionnelles représentées par un schéma DW standard contenant une table de fait avec l‟ensemble de ses dimensions.
Figure 30: tissage des aspects de SdF avec la partie fonctionnelle
100
4.7 Etude de Cas : Système Décisionnel pour Tableaux de Bord des Soins
d’Urgence Cliniques 4.7.1
Objectifs
Cette section a pour objectif de présenter le cas d‟étude que nous avons choisis afin
d'expérimenter notre contribution présentée dans ce chapitre et le chapitre précédent. L‟objectif du cas d‟étude est de montrer que notre approche permet d‟assurer la prise en
compte des aspects de sûreté de fonctionnement depuis les premières étapes du SD selon leurs criticité et en traitant leur interaction. Ainsi le système à la fin du cycle de développement doit intégrer ces aspects sur mesure et dois aussi justifier à chaque étape les choix retenues et les décisions prises concernant les aspects de SdF. A insi à l‟étape finale, le système doit intégrer la meilleure combinaison optimale qui permettra d‟assurer le niveau de confiance exigé par ses utilisateurs finaux selon leurs propres priorités. 4.7.2
Méthodologie
Afin de concrétiser notre approche par l‟étude de cas, nous allon s tout d‟abord fournir une présentation général du système cible. L‟objectif à ce stade préliminaire est de décliner ses exigences fonctionnelles et non fo nctionnelles. Pour ensuite entamer l‟application de notre méthodologie selon ces niveaux d‟abstraction.
Ainsi, Dans le niveau des exigences nous allons dériver 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 intégrale qui permettra de déduire les choix qui seront retenus pour le niveau suivant selon leurs criticités et priorités. Dans le niveau indépendant de la plateforme, nous allons détailler les aspects retenus afin de réaliser les PIM de chaque aspect et de les ré- confronter afin de déduire les choix retenus pour l‟étape suivante. Dans le dernier niveau, nous allons prendre l‟exemple de la couche DW afin proposer une implémentation possible de la combinaison optimale résultante des étapes précédentes en réalisant son tissage avec un schéma fonctionnel du DW. De Ce tissage va résulter un modèle déployable sur la plateforme finale. Enfin, nous allons réaliser le système final intégrant la combinaison optimale dans une plateforme technique. Et pour justifier que notre système intègre les aspects de SdF modélisés, nous allons préparer des scénarii d‟attaque afin d‟injecter et d‟insérer des erreurs et des fautes dans notre système finale pour d éclencher son dysfonctionnement. L‟objectif est de tester sa réaction et réactivité d‟un côté et de mesurer le niveau de sûreté de fonctionnement qu‟il assure de l‟autr e côté.
101
4.7.3
Cahier des Charges
Cette étude est extraite du cahier des charges de Tableaux de Bord des Soins d‟Urgence Cliniques sur le site web de NHS1. National Health Service (NHS) est le système de la santé publique du Royaume-Uni. Cette organisation fournit le fondamental des soins depuis la médecine générale aux salles d'urgence des hôpitaux, les soins longs durés aux soins dentaires. NHS a déclenché 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 commençant par 12 sites pilotes;
Créer une boîte à outils pour standardiser les tableaux de bord des soins d'urgence y compris les normes, l'architecture logique, des flux de données bibliothèque, la documentation de conception détaillée, des objets de gestion de projet et de mises à jour du référentiel des métriques.
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 déterminer la solution finale. Plus d'informations sur le projet peuvent être trouvées sur les pages de Networks.nhs2 : Pour un souci de simplicité nous allons référencer le cas d‟étude par UCCD qui désigne Urgent Cares Clinical Dashboard. Dans ce qui suit, nous allons présenter intégralement les exigences fonctionnelles et non fonctionnelles tel qu‟elles sont exprimées dans le cahier des charges (sauf modifications imposées pour avoir une traduction correcte): 4.7.3.1 Ex igences foncti onn elles
La Modèle conceptuel des Services technologiques ci-dessous donne un aperçu des services fonctionnels que la solution technologique Tableau de Bord devrait offrir. Ce Modèle est subdivisé en trois couches: Chaînes, Services d‟Application et Infrastructure et sécurité.
1
Version de Date 20/2/2011 téléchargeable par le lien suivant : http://www.networks.nhs.uk/nhs-networks/qippurgent-care-gp-dashboard/documents/test-1 2
http://www.networks.nhs.uk/nhs-networks/qipp-urgent-care-gp-dashboard/urgent-care-clinical-dashboardimplementation-guide.
102
Figure 31: Modèle conceptuel des services technologiques
a) Les canaux : identifient les différents itinéraires à travers lesquels les informations du tableau de bord peuvent être reçues:
Interface utilisateur : fournir un accès 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 données : fournir un mécanisme par lequel les données peuvent être exportées sur une base programmée pour formats standards tels que CSV ou XML.
Alertes : fournissent un mécanisme de notification des mises à jour, alertes, erreurs, etc.
b) Services d‟Application : Identifient les fonctionnalités clés qui seront soutenues par l'application du tableau de bord:
Extract, Transform & Load (ETL): fourniture de fonctionnalités pour permettre de: •
Extraire des données des systèmes sources dans un format défini,
103
•
Transformation des données extraites dans les formats requis pour l'utilisation par le tableau de bord (entrepôt de données et d'affichage du tableau de bord), et
•
Charger des données dans l'entrepôt de données du tableau de bord ou Dashboard Affichage clinique.
Dashboard Présentation : fourniture d'une couche d'affichage qui permet aux données du tableau de bord (métriques) d‟être présentées dans une variété de formes (textes, graphiques, etc.) destinées à la consommation par une variété d'utilisateurs (cliniciens, le public, etc.)
Reporting & Analyse : fourniture d'une fonctionnalité qui permet d'analyser les paramètres plus en détail (analyse) et la création de rapports spécialisés résumant cette analyse.
Service anonymisation - fourniture d'une fonctionnalité qui permet l'élimination ou obscurcissement de patients sensibles ou des données cliniques pour s‟ assurer que seuls les cliniciens autorisés ont accès.
Intégration Service données - fourniture d'un service qui permet aux processus d'extraction de données, de transformation et de charge automatisés d‟être exécutées selon les besoins. Cela inclut les spécifications de flux d'information d'interopérabilité et les normes de chargement.
Gestion des données - fourniture d'un service qui permet aux données cliniques d‟être créés, mises à jour, supprimées, structurées et résumées selon les besoins.
Gestion des Meta données - fourniture d'un service pour gérer et fournir l'accès à l'information sur les données, par exemple la provenance des données et quel journal des transformations ont été effectuées à son sujet.
La saisie manuelle de données - la fourniture d'une fonctionnalité qui permet aux données d'être incorporés dans le tableau de bord grâce à des processus manuels, par exemple le téléchargement d'un fichier de données correctement formaté d‟une manière manuelle.
Outils de développement - la fourniture d'outils de développement pour permettre au tableau de bord d‟être modifié tel que requis par ses utilisateurs.
c) Infrastructure et Sécurité - identifier les services sous-jacents qui favorisent le support de la fonctionnalité de tableau de bord défini par:
Stockage de données : fourniture d'un service de stockage de données dans lequel les données nécessaires pour le tableau de bord (fichiers, base de données, etc) peuvent être stockées et soient accessibles par l'application et ses utilisateurs.
104
Serveurs : fourniture de serveurs pour les données d'une application dans le format souhaité et selon le niveau requis en termes de fiabilité, résilience, performance, etc.
Sécurité de l'information : la fourniture de mécanismes qui peuvent être utilisés pour sécuriser l'accès aux données et s‟assurer que seuls les cliniciens autorisés peuvent accéder aux données du tableau de bord.
Directory Services : fourniture d'une assistance pour l'utilisation des identités des utilisateurs et profils d'accès (rôles et groupes).
Services réseau : fourniture de services pour gérer une connectivité sécurisée aux serveurs de tableau de bord par les utilisateurs.
Identification & gestion d‟Accès : fourniture du service de la gestion de l'accès aux tableaux de bord à travers un mécanisme de contrôle d'accès basé sur les rôles liés aux utilisateurs identifiés.
Le Flux Conceptuel d‟Information figure dans le schéma suivant :
Figure 32: Flux Conceptuel de Donnée
4.7.3.2 Exigences non fon ctionn ell es
En plus des exigences fonctionnelles, les exigences non fonctionnelles de la solution doivent également être prises en considération. L‟approche utilisée par NHS se base sur le Modèle de la qualité des logiciels (QUINT2) Extension de l‟ ISO 9126 pour élaborer la liste des Exigences de SdF couvrant les caractéristiques suivantes : a) Fonctionnalité : examiner les fonctions des systèmes et de leurs propriétés spécifiées:
Aptitude
Précision 105
Interopérabilité
Conformité
Traçabilité
b) Fiabilité : la capacité du système à maintenir son niveau de performance dans des conditions déterminées pour une période déterminée:
Maturité
Tolérance aux pannes
La capacité d‟être recouvrable
Disponibilité
L‟aptitude d‟être dégradable
c) Ergonomie : envisager l'effort nécessaire pour l'utilisation, et l'évaluation individuelle d'un tel effort, par un ensemble déclarée ou implicite des utilisateurs:
la capacité de Compréhension
la capacité d‟Apprentissage
Efficacité opérationnelle
Explicitation
La capacité d‟être personnalisable
Attractivité
Clarté
Utilité
Convivialité
d) Efficacité : examiner la relation entre le niveau de performance du logiciel et la quantité de ressources utilisées, les conditions sobres:
comportement de Temps
Comportement des ressources
e) Maintenabilité : envisager l'effort nécessaire pour apporter des modifications spécifiques:
Analysabilité
La capacité d‟être Changeable
Stabilité
testabilité 106
La capacité d‟être Gérable
réutilisation
f) Portabilité - considérer la capacité du logiciel à être transféré d'un environnement à un autre:
Adaptabilité
Capacité de déploiement
conformité
la capacité de Remplacement.
Les exigences non fonctionnelles listées ci-dessus devraient également être traitées et intégrées conjointement avec les exigences spécifiques de sécurité et de l'Infrastructure suivantes : G) la sécurité : L'exigence d'un certain niveau de détail autour de la sécurité d‟accès, à la fois au tableau de bord et aux données cliniques utilisées dans la solution , s‟avère très important d'un point de vue de la confidentialité de la clinique et du patient. Ainsi, les éléments suivants doivent être considérés comme faisant partie intégrante de la solution:
L'utilisation de HTTPS pour crypter tous les transferts de données entre les serveurs de tableau de bord et les applications clientes.
L'utilisation de mécanismes de transport sécurisés pour les transferts de données organisationnelles transversales requises par la solution de tableau de bord.
L'utilisation du cryptage pour protéger les données sur réseau.
Options d'authentification de l'utilisateur:
Typiquement authentification des utilisateurs est effectuée via Active Directory Domain mais cela pourrait créer des problèmes pour tous les utilisateurs hors de domaine par exemple les utilisateurs de Primary Care Trusts et GP etc. authentification basée NHS Smartcard pourrait être déployé pour les utilisateurs hors de domaine, mais des infrastructures et des logiciels supplémentaires sont à envisager. Si les cartes à puce ne sont pas utilisés d‟autres mécanisme d'authentification doit être considéré.
Gouvernance de l'information doit être considérée lorsque les données sont partagées entre les organisations et doit mettre en évidence la nécessité d'accords de partage de l'information.
107
4.7.4
Mise en oeuvre et validation
Plusieurs scénarios de mise en œuvre ont été proposés par NHS en se basant sur les systèmes existants des cliniques. Nous n‟allons pas étaler les scénarios proposés mais plutôt nous allons directement choisir le scénario qui suppose que le Système Décisionnel n‟existe pas d‟avance et donc pour réaliser les Tableaux de bord, il est nécessaire d‟élaborer un ETL, un entrepôt de
donnée à partir duquel les Tableaux de bord vont charger leurs données. 4.7.4.1 I mpl é mentati on du Niveau des Exi gences
Au Niveau des Exigences, nous proposons de dériver les exigences de SdF à partir des exigences non fonctionnelles présentées dans le cahier des charges. Le tableau ci-dessous présente la matrice de correspondance des paramètres de sûreté de fonctionnement du système UCCD par couche et par attribut. Cette matrice représente la base pour l‟élaboration des différents modèles de notre approche. Couches Aspects
Sources Donnée
ETL
Entrepôt de Donnée
Outils de Restitution
Tolérance aux Pannes Disponibilité et Fiabilité
Recouvrabilité Dégradabilité Disponibilité Maturité Analysabilité Stabilité
Maintenabilité
Changeabilité Testabilité Gérabilité Réutilisabilité Cryptage
Sécurité
Sécurisation de Transport Authentification Confidentialité
4.7.4.2 I mpl é mentati on du N iveau I ndé pendant de la Pr ogr ammati on
Cette étape permettra de modéliser les exigences liées à chaque aspect de SdF au premier niveau d‟abstraction. En exploitant la matrice de correspondance nous avons élaboré les modèles CIM de disponibilité et fiabilité (figure 33); de la maintenabilité (figure 34) et de la sécurité (figure 35). Ces CIM ont été élaboré par NFR Framework comme préconisé par la mise en œuvre de notre approche . 108
Figure 33: CIM de disponibilité et fiabilité de l’UCCD
Figure 34: CIM de Maintenabilité de l'UCCD
109
Figure 35: CIM de la sécurité de l'UCCD
Nous allons intégrer les CIM de l‟UCCD dans un seul CIM intégrale pour étudier les interactions entre les différents paramètres des aspects de SdF. La figure 36 présente un extrait du CIM intégral qui met en exergue certaines interactions conflictuelles.
Figure 36: Extrait du CIM Intégral simplifié
110
Cette figure montre que le <> des données améliore l‟<> et la <> indispensables pour assurer la <>. Toutefois les techniques de <> augmentent la <> [140]. Cette dernière affecte directement la <> et donc nuit à la maintenabilité d‟un côté. D‟un autre côté, la complexité rend la distributivité difficile à appliquer et diminue ainsi la fiabilité du système, ce qui affecte automatiquement sa disponibilité. Si on prend l‟hypothèse que
le système décisionnel UCCD sera un système qui sera sollicité dans 90% en interne de la clinique, la mise en œuvre du cryptage comme exigée par NHS dans son cahier de charge peut nuire à la disponibilité et fiabilité du système [140]. Ainsi, grâce à l‟étude des interactions nous proposons de n‟utiliser le cryptage que sur les données qui seront transmises à l‟extérieur de la clinique. Ce choix permettra de ne pas pénaliser la maintenabilité, la disponibilité et la fiabilité du système UCCD, toute en assurant un niveau de sécurité satisfaisant. 4.7.4.3 I mpl é mentati on du Niveau I ndé pendan t de la Pl ateforme
Ce niveau est moins abstrait que son précédent, car nous allons détailler d‟avantage les aspects de SdF. Pour cela, nous allons les enrichir sans faire intervenir les caractéristiques d‟une plateforme quelconque. Ainsi, les modèles seront portables et réalisables quel que soit la plateforme technique d‟implémentation. Les figures 37, 38 et 39 représentent respectivement les PIM de disponibilité & fiabilité, de maintenabilité et de sécurité, alors que la figure 40 présente un extrait de leur PIM intégral.
Figure 37: PIM Fiabilité et Disponibilité
111
Figure 38: PIM de la Maintenabilité
Figure 39: PIM de la Sécurité de l’UCCD
112
Figure 40: PIM intégral des SdF propre à la couche DW du system UCCD
4.7.4.4 I mpl é mentation du niveau spé cifique àla pl atefor me
A ce niveau nous proposons l‟élaboration des diagrammes de composant et de déploiement. Pour cela nous allons mettre en valeur le tissage des aspects avec la partie fonctionnelle au niveau modélisation juste avant leur mise en œuvre. Nous allons appliquer ces concepts à la
couche DW afin de mettre en évidence l‟intégration des aspects de SdF raffiné depuis la première étape de notre approche. Le diagramme de composant de la figure 41 représente PSM du deuxième niveau. Ainsi l‟ensemble des aspects ser ont tissé avec le DW fonctionnel suivant une démarche Orientée Aspect. Le schéma du DW a été réalisé en se basant sur les exemples de tableau de bord fournis par NHS. Le diagramme de déploiement de la figure 42 explicite les choix d‟architecture technique qui
ont découlé des compromis faits à partir des phases précédentes. Ce diagramme est complémentaire au diagramme de composant pour élaborer un PSM intégral de la couche Data warehouse. Nous précisons que le NHS a déjà proposé un ensemble de scénarios d‟architecture technique dans leur cahier des charges. A base de ces derniers, nous avons élaboré le modèle ci-dessus en tenant comptes des contraintes causées par l‟interaction des aspects de SdF traité par notre
méthodologie.
113
Figure 41: PSM logique du DW de l'UCCD représenté par Diagramme de Composant
Figure 42: PSM architectural du DW de l'UCCD par Diagramme de Déploiement
Du point de vue disponibilité et fiabilité, nous proposons de réaliser une réplication des données du DW en utilisant deux serveurs indépendants. Cette dernière va assurer la continuité du service de l‟UCCD dans le cas d‟une panne du DW principal. Le serveur d‟application va switcher les requêtes des clients vers le serveur de réplication une fois la
114
passivité du serveur principal est détectée. La fiabilité du système est ainsi garantie. Dans le cas des périodes de surcharge du serveur principal c‟est-à-dire le temps de réponse aux requêtes commence à s‟approcher au seuil inacceptable, le serveur d‟application peut répartir
la charge des requêtes en fonction de leur urgence et criticité (exemple une requête qui est envoyé depuis une salle d‟opération ou d‟une ambulance est plus critique que celle qui provient d‟une salle de consultation). Enfin, le serveur secondaire est, en principe dédié aux requêtes non urgentes de recherche et de développement qui peuvent bloquer le serveur principal, sauf dans le cas des périodes de surcharge du serveur principal ou il doit répondre aux requêtes des clients. Du point de vue maintenabilité, le faible couplage entre composant logiciel grâce à la conception orientée objet augmente considérablement la maintenabilité du système. En plus grâce au mécanisme de duplication physique des serveurs du DW, et leur séparation du serveur d‟application on peut effectuer des opérations de maintenance sans que la réponse du système soit affectée. Du point de vue sécurité, malgré que le NHS insiste dans un document spéciale [141] sur le cryptage des données pour assurer leurs confidentialités, notre approche a pu démontrer, par résolutions des conflits et des interactions des aspects de SdF, que le cryptage des données dans le réseau local dans ce cas d‟étude nuira directement à la disponibilité des données surtout lors des périodes de surcharge (voir section suivante). Toutefois pour assurer un niveau suffisant de sécurité, nous proposons d‟utiliser LDAP (Active Directory pour Windows, Open LDAP pour Linu x…) pour assurer une gestion centralisée des utilisateurs appuyée par une stratégie d‟authentification basée sur des certificats de sécurité, ainsi les clients ne peuvent accéder aux données que s‟ils sont identifiés par le serveur LDAP et sur des machines qui ont des certificats de sécurité agrées que par l‟administrateur système. 4.7.4.5 I mpl é mentation et r é sul tats des tests
Pour mesur er l‟impact du cryptage exigé par NHS sur la disponibilité des données nous avons utilisé DWeb qui est un Benchmark permettant de mesurer le temps de réponse d‟une charge de requêtes (workload) paramétrable. Ainsi, en variant le nombre de requêtes, leurs types et le volume de données du Data warehouse, nous pouvons constater que le temps de réponse peut devenir très insatisfaisant voir critiques dans des cas particuliers. L‟expérimentation suivante a été réalisée sur un PC de 4Go de RAM et de processeur Int el
Core i5 de 2,60GHz exécutant Windows 7 et contenant le SGBD Oracle 10g installé dédié au Data warehousing. Toutes les mesures des figures 43, 44, 45, 45 ont été réalisées toute abstraction faite aux contraintes de performance des supports et infrastructures Réseau. Ainsi, dans un premier lieu nous avons procédé par fixer le volume du DW et changer la charge des requêtes de 20 à 100
115
requêtes en l‟appliquant au plus petit entrepôt de donnée DW1 dont la capacité est de 22 Mo au plus grand qui est le DW10 contenant 2Go de donnée. 12000
DW1 SIZE= 22MO 10000 ) s m ( e m i t e s n o p s e r
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 réponse du DW1 aux différentes charges de requêtes
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 réponse du DW10 aux différentes charges de requêtes
Les figures 43 et 44 montrent que plus le DW est volumineux plus le cryptage affecte le temps de réponse en fonction du nombre des requêtes constituant la charge à exécuter.
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
3300
3700
4100
4300
4500
4550
4690
4900
5100
3100
Figure 45: Temps de réponse de la charge de 20 requêtes aux différents 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
5900
6700
7500
8300
9100
9900 10700 11500 12900
5100
Figure 46: Temps de réponse de la charge de 100 requêtes aux différents volumes de DW
Les figures 45 et 46 prouvent que le temps de réponse des requêtes augmente en fonction des requêtes constituant la charge. Ainsi plus la charge des requêtes augmentent plus le cryptage affecte sévèrement le temps de réponse. Ce constat s‟avère critique dans le cas des soins urgents ou la vie du patient peut être mise en danger. 4.8 Synthèse
Ce chapitre offre une vision globale sur la mise en œuvre de notre proposition dirigée par les modèles afin de traiter les aspects de SdF dans le contexte des SD. Ainsi nous avons suivis les 117
étapes de notre méthode proposée depuis le premier niveau d‟abstraction jusqu‟à la mise en œuvre. Pour enfin l‟évaluer par une étude de cas afin de montrer son applicabilité d‟un côté, et d‟expliciter le traitement des interactions des aspects de SdF d‟un autre côté.
détaillé au deuxième chapitre, afin de lister les paramètres influençant les aspects de SdF pour chaque couche du SD. Ces paramètres ont été retenus pour être modélisé dans le niveau suivant. Au Niveau Indépendant de la Programmation : nous avons raffiné les paramètres retenues en réalisant des modèles CIM pour chaque aspect sans évoquer les détails de la programmation. Ainsi chaque CIM est composé de tous les paramètres indépendamment de la couche d‟où il provient. Cette consolidation nous a permis de résoudre les interactions des paramètres pour chaque aspect avant de traiter leurs interactions avec les Au Niveau des Exigences : nous nous sommes basés sur l‟état de l‟art
autres aspects. Cette dernière a été mise en œuvre par la composition des CIM en un CIM intégral. A ce niveau de l‟approche nous avons préconisé l‟utilisation du NFR Framework
qui offre des mécanismes de raffinement et de traitement des interactions lors de l‟élaboration du SIG : Softgoal Interdependency Graph. Au niveau Indépendant de la Plateforme : Le résultat de la confrontation des paramètres fournis par le niveau précédent est exploité dans ce niveau afin d‟élaborer les PIM de chaque aspects. Ainsi, la même procédure est réitérée afin de raffiner les paramètres retenus et les réintégrer pour les confronter dans un PIM intégrale afin de traiter leur interaction. Nous avons proposé à ce niveau l‟utilisation du profil QoS -FT qui est une extension d‟UML pour modéliser la qualité de service et la tolérance au x fautes. Ce profil nous a fournis des mécanismes utiles pour mieux concrétisé les paramètres résultants des niveaux précédents abstraits . Transformation : Pour concrétiser le passage du niveau CIM au niveau PIM indépendant de la plateforme, nous avons mis en œuvre des règles de transformations qui se basent sur le langage ATL. Ces règles de transformations s‟appuie sur les métas modèles NFR Framework et QoS-FT Profil pour assurer la traçabilité des exigences qui passent d‟un niveau à l‟autre. Pour faciliter cette transformation nous avons utilisé le mécanisme d‟extension d‟UML afin d‟étendre le méta modèle NFR pour mieux correspondre au méta
modèle du profil QoS-FT.
Au niveau spécifique à la plateforme : les détails de la plateforme d‟implémentation
doivent apparaitre. Pour concrétiser les modèles de ce niveau, nous nous sommes heurtés à deux difficultés : la première réside dans le caractère multicouche du SD car les modèles PIM se concentrent sur les aspects alors que l‟implémentation s‟intéresse surtout à la
couche et la technologie cible. La deuxième difficulté réside dans le caractère complémentaire des aspects de SdF, car ces aspects ne peuvent pas être implémenté qu‟en l‟incorporant aux aspects fonctionnels du système en question. Pour surmonter ces
118
difficultés nous avons proposé de réalisé le PSM selon deux étapes : la première étape se concentre à extraire des PIM les paramètres propres à chaque couche pour les rassembler dans des PSM par couche. Cette procédure va permettre de faciliter l‟implémentation par
couche et ensuite par plateforme. Alors que la deuxième étape pr opose l‟utilisation de la modélisation orientée aspect afin de tisser les aspects de SdF avec les aspects fonctionnels pour pouvoir les implémenter. A cette étape nous avons proposé l‟utilisation les diagrammes d‟UML tel que le diagramme de Package, de Composant et de Déploiement ainsi que l‟extension UML pour le Développement Logiciel Orienté Aspect. Ces diagrammes riches nous ont permis de donner des points de vue différents et complémentaires pour modéliser les PSM et résoudre les difficultés rencontrées à ce niveau.
Evaluation : pour évaluer notre proposition, nous l‟avons appliqué étape par étape sur un
cas d‟étude. Ce dernier a été extrait
du cahier des charges fournis par le service national de santé du Royaume U nis (NHS) pour la mise en œuvre de tableau de bord de soins d'urgence clinique. La particularité de ce cas d‟étude est l‟importance de la prise en considération des aspects de SdF dès les premières étapes du projet surtout la disponibilité et la sécurité d‟un côté. De l‟autre côté, la néces sité du traitement des interactions des aspects pour avoir une traçabilité et une justification des choix architecturaux retenues. Ces derniers représentent la combinaison optimale des aspects de SdF qui peut être implémentée. Ainsi nous avons élaboré les CIM de chaque aspect en raffinant sur les exigences de SDF extrait des exigences non fonctionnels abstraits citées par le cahier des charges. Ensuite nous avons composé les CIM des aspects de SdF en un CIM intégral afin de résoudre leurs conflits et interaction à ce niveau. Ensuite nous avons élaboré les PIM de chaque aspect en se basant sur les résultats de consolidation de l‟étape précédente, et
nous les avons confrontés pour ressortir leur combinaison optimale. Enfin nous avons élaboré le PSM de la couche Data warehouse comme exemple pour le tisser avec un schéma fonctionnel grâce au mécanisme de la modélisation Orientée Aspect. Enfin nous avons utilisé le Benchmark DWEB afin de le gain et l‟apport de notre méthode pour intégrer et résoudre les problème s d‟interaction entre les besoins de sûreté de fonctionnement.
119
Conclusion Conclusion et perspectives perspectives
L'homme le plus parfait est celui qui sait en chaque chose considérer la fin. Citation de Hésiode ; Les travaux et les jours - VIIIe s. av. J.-C.
120
5.1. Bilan des travaux réalisés Les travaux développés dans ce mémoire s‟inscrivent dans le cadre de l‟ intégration
des
aspects de SdF depuis les premières étapes de l‟élaboration du SD, tout en garantissant la prise en compte de leurs interactions et conflits mutuels. L‟état de l‟art exposé dans le deuxième chapitre, a démontré que les aspects non fonctionnels f onctionnels ont été largement traités mais d‟une manière individuelle sans tenir compte de leurs interactions. En plus, d ans la majorité des cas, ils n‟ont été abordés qu‟aux phases de modélisation physique ou d‟implémentation, phase où l‟ensemble des choix architecturaux ont été déjà effectués. Ainsi, il nous est apparu nécessaire de proposer une app roche globale d‟intégration des aspects de SdF dans le processus de conception du SD. Dans ce sens, cette thèse propose une approche alignée au standard MDA de l‟OMG. Notre approche préconise l‟utilisation des modèles durant les niveaux d‟abstraction ce qui assure la traçabilité des exigences de SdF
ainsi que leur prise en compte dès les phases précoces du processus du développement du SD. En plus, la modélisation 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 départ en fonction de la criticité et priorité priori té de chacune dans le SD final. Notre proposition est une approche descendante de plus niveau d‟abstraction qui correspond au niveau du recueil des exigences fonctionnelles et non fonctionnelles jusqu‟à l‟implémentation en passant par les niveaux suivants :
Niveau des exigences : qui permet de lister l‟ensemble des exigences non fonctionnelles du système pour ensuite en extraire ceux propres à la SdF. : qui permet de modéliser les exigences exigences recueillis du niveau précédent en les raffinant en paramètre et détectant leurs conflits avant leurs informatisations. A ce niveau, nous préconisons l‟utilisation du NFR
Niveau indépendant de l‟informatisation
Framework afin d‟élaborer le CIM de chaque aspect de SdF.
Niveau indépendant de la plateforme : qui permet de modéliser les paramètres retenus de l‟étape précédente en le raffinant encore plus pour chaque aspect et en les réintégrant afin de détecter leurs conflits mutuels et les résoudre au niveau modèle. A ce niveau, nous préconisant l‟utilisation profil QoS-FT pour élaborer les PIM de chaque aspect.
Niveau spécifique à la plateforme : qui permet d‟extraire des modèles résultants du niveau précédent pour constituer des modèles spécifique pour chaque couche du SD. ensuite pour faciliter leurs mises en œuvre, ces modèles vont être tissés aux modèles fonctionnels afin de construire des modèles intégrales prêtes au déploiement et implémentation.
121
Pour évaluer l‟applicabilité de notre méthode ainsi que son impact sur le SD cible, nous avons utilisé un cas d‟étude issu du monde de la santé. Ce cas s‟intéresse à l‟élaboration d‟un système de Tableaux de bord pour les soins d‟urgence ce qui sous -entend l‟interaction entre la disponibilité et la sécurité. Dans cette étude de cas nous avons traité chacun des aspects de SdF et nous avons traité leur interaction à chaque niveau en facilitant une traçabilité des choix retenues et leurs justifications. Et Enfin nous avons obtenu le system le plus proche des exigences de SdF exprimées au début du cycle du développement en lui intégrant leur combinaison la plus optimale. Il est important de souligner que la mise en œuvre de notre approche n‟est qu‟un scénario parmi d‟autre. Ainsi dans chacun des niveaux, le choix est laissé au concepteur pour utiliser le
métamodèle ou le profil qu‟il juge plus utile dans son cas en fonction de sa compétence et du contexte d‟utilisation (Par exemple le profil MARTE est plus approprié pour les Systèmes
temps réels etc.) Pour conclure, nos travaux ont permis d‟établir les premières briques vers la construction du pont entre le domaine de la SdF et celui des SD. Ces briques équilibrent le compromis entre l‟interaction des attributs de SdF et la particularité des SD.
5.2. Synthèse des contributions Notre proposition a passé pas sé par plusieurs étapes ét apes de validation scientifique scientifi que qui l‟a mis sous s ous les
loupes des chercheurs du domaine afin d e la corriger ou de proposer d‟ éventuels chemins de concrétisation. Dans cette section, nous allons étaler les différentes publications et communications qui ont permis de développer et faire avancer nos travaux de recherche pour répondre à la problématique ciblée. 1.
« Evaluation et Amélioration de la Fiabilité et de la Disponibilité des Systèmes Décisionnels » est une communication présentée à la conférence Internationale Wotic en 2011 à Casablanca. Dans cet article, nous avons décomposé le SD selon ses quatre couches : DS, ETL, DW, OR. Ensuite nous avons évalué pour chaque couche les problèmes de fiabilité et disponibilité ainsi que les techniques existantes pour les améliorer. Et nous avons découvert que l‟amélioration de disponibilité et la fiabilité peut nuire à la maintenabilité et à la sécurité. Ainsi, cet article nous a permis de pouvoir formuler et justifier le fondement de notre problématique qui consiste au traitement des interactions des aspects de SdF dans le contexte des SD.
2.
« Adaptation des concepts de la sûreté de fonctionnement aux Systèmes Décisionnels » est une communication présentée au Workshop de Fouille de Donnée FDO en 2012 à Meknès. Dans cet article, nous avons redéfinit les concepts de sûreté de fonctionnement dans le contexte des SD, ensuite nous avons dressé un état de l‟art des méthodes existantes pour améliorer chaque aspect et enfin nous avons réalisé une
122
étude comparative afin déterminer l‟impact 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 présente notre approche globale qui se base sur le standard MDA afin de prendre en compte la Sdf dès les premières étapes du développement développement du SD et le traitement des interactions entre ses aspects. Dans cet article, nous avons élaboré les CIM et les PIM en présentant 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. 16, Volume 3 issue 11 Novembre 2013 ISSN: 2277 128X. Cette publication s‟intéresse au mécanisme du passage d‟un niveau à un autre en utilisant le principe des
transformations des modèles. modèles. Ainsi une extension du meta modèle NFR a été proposée 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 démontrer la traçabilité des exigences d‟un niveau à un autre . 5.
«Aspect-Oriented Method for Dependable Data Warehouse Systems based on MDA Approach » est une communication présentée à la 4ème IEEE Conférence Internationale en Multimedia et Systèmes (ICMCS) à Marrakech le 14-16 Avril 2014. Cet article présente l‟intégration de la conception Orientée Aspect pour intégrer les aspects de SdF aux SD au niveau conception, en proposant une solution pour modéliser les PSM.
6.
«Architecture Dirigée Par Les Modèles Pour L‟intégration Des Exigences de La Sûreté De Fonctionnement Aux Systèmes Décisionnels » est une communication au workshop des Technologies de l‟Information et Modélisation Casablanca 31mai 2014 , qui présente d‟une manière générale l‟intégralité 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 présentée à l‟International 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 présentée à la conference internationale sur les Avancées des Systèmes Décisionnels Décisionnels ( ASD 15), 10 Ŕ 11 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 présentée 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 exposés dans ce mémoire, nous affirmons qu‟il 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 d‟unifier et d‟expliciter le sens exact des exigences non fonctionnelles de SdF et de préciser leurs liens et leurs relations. Ensuite, nous prop osons d‟automatiser notre approche en développant des modules de transformation de PIM en PSM et du PSM en code . Cette automatisation pourra s‟effectuer via la définition des transformations de composition pour assurer l‟ intégration pour chaque niveau. Cette dernière sera plus intuitive avec l‟utilisation d‟un Add-in ou une extension intégrée à un outil CASE (Computer-aided software engineering) qui permet de supporter la modélisation de notre approche. D‟un autre côté, il sera intéressant de réaliser un benchmark de sûreté de Fonctionnement. Ce
dernier va permettre d‟injecter des erreurs aux systèmes décisionnels et calculer les métriques 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 démontrer la traçabilité des exigences de SdF durant les étapes de notre approche ainsi que sa portabilité et réutilisation. Et de penser d‟intégrer la scalabilité comme paramètre qui influence directement la SdF des SD. En plus nous pensons que l‟élaboration d‟un profil UML propre à la SdF va facil iter considérablement la mise en œuvre de notre approche.
Enfin, Dans le long terme, notre approche peut être généralisée pour s‟appliquer sur n‟importe quel type de Systèm es d‟information. Et l‟interaction visée par notre approche peut être résolue par l‟utilisation des équations multi -objectifs issue du domaine de la programmation linéaire ou encore l‟application des principes de la théorie des jeux pour trouver la combinaison optimale des attributs de SDF.
124
Bibliographie et Webographie
[1] [2]
L. Gaillard, M. De Lavallée, and J. Fauc, “Les S ystèmes Décisionnels,” 1999. J. Lebraty, “Les systèmes Decisionnels,” International Encyclopédie de l’informatique et des systèmes d’information. Vuibert, pp. 1338 Ŕ 1349, 2006.
[3] [4] [5] [6] [7] [8] [9]
D. Mollard, “Décisionnel, Performance, Qualité,” La Lettre d’ADELI , pp. 5 Ŕ 12, 2007.
W. Inmon, Building the data warehouse, Third Edition, John Wiley & Sons, Inc., 2002. W. H. Inmon, “The data warehouse and data mining,” Communications of the ACM , vol. 39, no. 11. pp. 49 Ŕ 50, 1996. Ralph Kimball, The Data Warehouse Lifecycle Toolkit . 1998. P. Vassiliadis, C. Quix, Y. Vassiliou, and M. Jarke, “Data w arehouse process management,” Inf. Syst. J., vol. 26, no. 3, pp. 205 Ŕ 236, 2001. E. Annoni “éléments méthodologiques pour le développement des systèmes décisionnels dans un contexte de réutilisation,” thèse soutenue à Toulouse en 2007. C. Bérard, “Le processus de décision dans les systèmes complexes une analyse d‟une
intervention systèmique,” , 2009. [10] A. F. Nodesway, “Les fondamentaux du projet décisionnel,” 2009. [11] A. Fernandez, Les nouveaux tableaux de bord des managers : le projet décisionnel dans sa totalité. Paris: Ed. d‟Organisation, 2011. [12] S. R. Gardner, “Building the data warehouse,” Communications of the ACM , vol. 41. pp. 52 Ŕ 60, 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, “Ingénierie des exigences pour les systèmes d‟information décisionnels : concepts, modèles et processus - la méthode CADWE,” Universit é Panthon-Sorbonne - Paris I, 2008. [16] R. Kimball and V. Campillo, Concevoir et déployer 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-projectsfail/.
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-businessintelligence-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. Avižienis, 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. 11 Ŕ 33, 2004.
[24] J. Laprie, “Dependability of Computer Systems : from Concepts to Limits,” in In FTCS-25, the 25th IEEE International Symposium on Fault-Tolerant ComputingSpecial Issue, 1995.
[25] GUILLERM Romaric, “Intégartion de la Surteté de Fonctionnement dans les Processus d‟Ingénierie Système,” l‟Université Toulouse III Ŕ Paul Sabatier, 2011. [26] M2OS, “Fiches méthodes,” 2011. [27] AFIS organisation, “Ingénierie Système,” 2012. [Online]. Available: http://www.afis.fr/nmis/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. 315 Ŕ 321, 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: Ingénierie logicielle guidée par les modèles. Eyrolles edition 2011. [35] J. Bézivin, “Language engineering for model driven software development,” in Dagstuhl seminar , 2005. [36] B. Combemale, “Approche de métamodélisation pour la simulation et la vérification de modèle -- Application à l‟ingénierie des procédés,” IRIT & ENSEEIHT, 2008. [37] OMG, “MOF.” [Online]. Available: http://www.omg.org/mof/.
126
[38] S. Diaw, R. Lbath, and B. Coulette, “Etat de l‟art sur le développement logiciel basé sur les transformations de modèles,” Numéro spécial ISI - Ingénierie Dirigée par les Modèles, vol. 29:4 Ŕ 5, p. 2, 2010.
[39] OMG, “OMG,” 2014. [Online]. Available: http://www.omg.org/. [Accessed: 20 -Apr2001]. [40] OMG, “MDA.” [Online]. Available: http://www.omg.org/mda/. [41] F. Bentayeb, O. Boussaid, N. Harbi, N. Kabachi, and S. Loudcher, “Les e ntrepôts de données pour les nuls. . . ou pas !,” in 2ème Atelier aIde à la Décision à 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. 237 Ŕ 271, 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. 1 Ŕ 18.
[44] S. Rizzi, A. Abelló, J. Lechtenbörger, 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. 149 Ŕ 154, 2008. [46] I. Gam and C. Salinesi, “A requirement -driven approach for designing data warehouses,” Requir. Eng. Found. Softw. Qual. , 2006. [47] J.- N. Mazón, J. Trujillo, and J. Lechtenbörger, “Reconciling re quirement-driven data warehouses with data sources via multidimensional normal forms,” Data Knowl. Eng. , vol. 63, no. 3, pp. 725 Ŕ 751, 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. 492 Ŕ 525, 2005. [50] P. Vassiliadis and A. Simitsis, “Extraction, transformation, and loading,” in Encyclopedia of Database Systems , Springer, 2009, pp. 1095 Ŕ 1101. [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. 22 Ŕ 40, 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. 1 Ŕ 24, 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. 49 Ŕ 56.
[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. 658 Ŕ 664. [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. 47 Ŕ 56.
[57] I. Y. Song, R. Khare, and B. Dai, “SAMSTAR: a semi -automated lexical method for generating star schemas from an entity-relationsh ip diagram,” in Proceedings of the ACM tenth international workshop on Data warehousing and OLAP , 2007, pp. 9 Ŕ 16. [58] O. Romero and A. Abelló, “A framework for multidimensional design of data warehouses from ontologies,” Data Knowl. Eng., vol. 69, no. 11, pp. 1138 Ŕ 1157, 2010. [59] V. Nebot and R. Berlanga, “Building data warehouses with semantic web data,” Decis. Support Syst., vol. 52, no. 4, pp. 853 Ŕ 868, 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. 56 Ŕ 62.
[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. 383 Ŕ 423. [63] E. Franconi and A. Kamble, “The GMD Data Model and Al gebra for Multidimensional Information,” in 16th Intl. Conf. on Advanced Information Systems Engineering (CAiSE), LNCS 3084, 2004, pp. 446 Ŕ 462.
[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 l‟analyse en ligne et de la fouille de données pour l‟exploration, l‟agrégation et l‟explication des données complexes,” Université
Lumière 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. 703 Ŕ 714.
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. 1333 Ŕ 1348, 2007. [68] I. Mami and Z. Bellahsene, “A survey of view selection methods,” ACM SIGMOD Rec., vol. 41, no. 1, pp. 20 Ŕ 29, 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. IIT’07.
4th
International Conference on, 2007, pp. 1 Ŕ 5.
[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. 221 Ŕ 230.
[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 warehous e design,” in Advances in Databases and Information Systems , 2010, pp. 164 Ŕ 175. [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. 115 Ŕ 125. [76] E. Ziyati, “Optimisation de requêtes OLAP en entrepôts de données: Approche basée sur la fragmentation génétique,” thèse 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. 111 Ŕ 120, 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. 1 Ŕ 11. [80] A. Simitsis, P. Vassiliadis, and T. Sellis, “State-space optimization of ETL workflows,” Knowl. Data Eng. IEEE Trans. , vol. 17, no. 10, pp. 1404 Ŕ 1419, 2005. [81] T. Jörg and S. Dessloch, “Near real -time data warehousing using state-of-the-art ETL tools,” in Enabling Real-Time Business Intelligence, Springer, 2010, pp. 100 Ŕ 117.
129
[82] L. Golab, T. Johnson, and V. Shkapenyuk, “Scheduling updates in a real -time stream warehouse,” in Data Engineering, 2009. ICDE’09. IEEE 25th International Conference on, 2009, pp. 1207 Ŕ 1210.
[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. 26 Ŕ 43, 2007. [86] O. Rakotoarivelo and F. Bentayeb, “Evolution de schéma par classification automatique pour les entrepôts de données.,” in EDA, 2007, pp. 99 Ŕ 112. [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. Zimányi, “A conceptual solution for r epresenting time in data warehouse dimensions,” in Proceedings of the 3rd Asia-Pacific conference on Conceptual modelling-Volume 53 , 2006, pp. 45 Ŕ 54.
[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. 664 Ŕ 669. [92] D. Solodovnikova and L. Niedrite, “Evolution -oriented user-centric data warehouse,” in Information Systems Development , Springer, 2011, pp. 721 Ŕ 734. [93] G. Papastefanatos, P. Vassiliadis, A. Simitsis, and Y. Vassiliou, “What -if analysis for data warehouse evol ution,” in Data Warehousing and Knowledge Discovery , Springer, 2007, pp. 23 Ŕ 33. [94] C. Blanco, E. Fernández-Medina, J. Trujillo, and M. Piattini, “Data Warehouse Security,” in Encyclopedia of Database Systems, Springer, 2009, pp. 675 Ŕ 679. [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. 1586 Ŕ 1590.
130
[98] M. Vieir, J. Vieir, and H. Madeir, “Towards Data Security i n Affordable Data Warehouses,” in 7th European Dependable Computing Conference (EDCC-7), Kaunas, 2008, pp. 7 Ŕ 9.
[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. 49 Ŕ 72, 2008. [101] L. Niedrite, D. Solodovnikova, M. Treimanis, and A. Niedritis, “Goal -driven design of a data warehouse-based bu siness process analysis system,” in Proceedings of the 6th Conference on 6th WSEAS Int. Conf. on Artificial Intelligence, Knowledge Engineering and Data Bases , 2007, pp. 243 Ŕ 249.
[102] F. R. S. Paim and J. F. B. de Castro, “DWARF: an approach for requireme nts definition and management of data warehouse systems,” in Proc. 11th IEEE Int. Conf. Requirements Engineering , 2003, pp. 75 Ŕ 84.
[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, “Modélisation conjointe des données et des processus pour l‟implantation de schémas d‟entrepôts,” J. Decis. Syst., vol. 21, no. 1, pp. 27 Ŕ 49, 2012. [105] F. Atigui, “Approche dirigée par les modèles pour l‟implantation et la réduction d‟entrepôts de données,”thèse 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. 67 Ŕ 76. [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. 43 Ŕ 52. [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 (DSOA’2004), 2004. [109] L. Zepeda, M. Celma, and R. Zatarain, “A mixed approach for data warehouse conceptual design with MDA,” in Computational Science and Its Applications – ICCSA 2008 , Springer, 2008, pp. 1204 Ŕ 1217.
[110] A. Carmè, J.-N. Mazón, 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. 13 Ŕ 24.
[111] J.- N. Mazón and J. Trujillo, “An MDA approach for the development of data warehouses,” Decis. Support Syst., vol. 45, no. 1, pp. 41 Ŕ 58, 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. 226 Ŕ 235.
[113] L. Muñoz, J.- N. Mazón, 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. 33 Ŕ 40.
[114] L. Muñoz, J.- N. Mazón, 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. 44 Ŕ 53.
[115] Z. El Akkaoui, E. Zimànyi, J.-N. Mazón, 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. 45 Ŕ 52.
[116] Z. El Akkaoui, J.-N. Mazón, A. Vaisman, and E. Zimányi, BPMN-based conceptual modeling of ETL processes . Springer, 2012. [117] E. Soler, V. Stefanov, and J. Mazón, “Towards comprehensive requirement analysis for data warehouses: Considering security requirements,” Proc. 3rd Int. Conf. Availability, Reliab. Secur., pp. 104 – 111., 2008. [118] X. Moghrabi , “L’approche model -driven architecture, crédible pour développer un progiciel de gestion intégré,” Mémoire de DEA, Ecole des mines d’Albi, [en ligne ], 2003, 63 p., Disponible sur :http://noce.univlille1.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. 47 Ŕ 54, 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. 363 Ŕ 379. [122] A. Matoussi and R. Laleau, “A Survey of Non -Functional Requirements in Software Development Process,” Dep. d’Informatique 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. 112 Ŕ 119.
[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. 363 Ŕ 379. [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 transform ations with industrial relevance, Springer, 2008, pp. 377 Ŕ 393. [130] F. Jouault, F. Allilaire, J. Bézivin, 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. 128 Ŕ 138. [132] J. Cabot and E. Teniente, “Transformation techniques for OCL constraints,” Sci. Comput. Program. , vol. 68, no. 3, pp. 179 Ŕ 195, 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. 34 Ŕ 38, 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. 87 Ŕ 98.
[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 asp ect-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 Cryptography – PKC 2011 , Springer, 2011, pp. 53 Ŕ 70.
134
Annexe A: DWEB (Data Warehouse Engineering Benchmark) A.1 Présentation de l’outil
d’implémentation : DWEB/ Oracle DW
DWEB : Data Warehouse Engineering Benchmark est un logiciel portable écrit en Java. Il permet en premier lieu d‟évaluer l‟impact de différents choix architecturaux ou de techniques d‟optimisation sur les performances d‟un
Entrepôt de donnée.
L‟objectif
de DWEB est de pouvoir modéliser les grands types de schémas multidimensionnels qui sont populaires dans les environnements ROLAP (Relational OLAP), à savoir les schémas en étoile, en flocon de neige (avec des dimensions hiérarchiques) et en constellation (avec des tables de faits multiples et des dimensions partagées). Pour cela, un métamodèle d‟entrepôt de données est utilisé ce qui permet d‟instancier ces différents schémas. ce méta modèle peut par ailleurs être vu lui-même comme une instance du CWM (Common Warehouse Metamodel) le méta modèle stan dard de l‟OMG. La génération d‟entrepôt est totalement configurable, à l‟aide d‟un ensemble complet de
paramètres dits de bas niveau qui permettent de spécifier finement les caractéristiques de chaque table de faits, niveau hiérarchique de dimension, etc. comme le montre la figure cidessous.
Figure 47: Interface de connexion et de chargement du DW
135
Cependant, comme ce paramétrage très fin peut s‟avérer fastidieux et compliqué à maîtriser pour des schémas même de taille moyenne. Un ensemble limité et plus gérable de paramètres de haut niveau est aussi fournis ce qui permet de calculer l‟ensemble complet des paramètres de bas niveau (ce sont des valeurs moyennes des paramètres de bas niveau). Les paramètres 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 hiérarchiques dans les dimensions, etc. A.2. Modèle de charge
Le modèle de charge de DWEB représente deux classes de requêtes différentes : des requêtes purement décisionnelles, qui comprennent les opérations 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/sélection (slice and dice) ; et des requêtes dites d‟extraction qui effectuent des jointures sur les tables de l‟entrepôt. Ce modèle de charge permet de générer des requêtes à la norme SQL-99, en fonction d‟un ensemble de paramètres tels que le nombre total de requêtes dans la charge, la proportion respective de requêtes décisionnelles et de requêtes d‟extraction, le nombre d‟attributs et de restriction dans une requête, etc. A.3 Processus d’ETL
Puisque DWEB est un logiciel indépendant qui génère des données et des charges, les mises à jour réalisées par l‟ETL sont effectuées directement dans la base de données pour conserver une certaine simplicité d‟usage à l‟outil et minimiser la gestion de fichiers externes. Ces mises à jour pourraient cependant être enregistrées dans des fichiers avant d‟être appliquées pour simuler l‟extraction. Ainsi, les transformations sont simulées en consommant du temps processeur (c‟est la tactique adoptée par le célèbre banc d‟essai TPC-DS). Dans DWEB, le temps de traitement des tests divers effectués lors des procédures d‟insertion et de modification de données est équivalent à ces transformations simulées. D‟autre part, le
chargement des données dans l‟entrepôt est effectué selon quatre cas d‟utilisation en concevant les stratégies de rafraîchissement 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 données sont le plus souvent historisées dans un entrepôt, le cas des suppressions n‟est pas pris en charge. Ce modèle d‟ETL est également paramétré, avec le taux de rafraîchissement global, les taux de rafraîchissement respectifs des tables de faits et des dimensions et la proportion d‟ insertions et de modifications. A.4 Protocole d’exécution Le protocole d‟exécution de DWEB est en fait une
variante de celui de TPC-DS, qui est luimême classique pour un banc d‟essais. Il est subdivisé en deux parties : un test de chargement
136
qui consiste à alimenter l‟entrepôt en données ; un test de performance qui évalue la réponse du système. Ce dernier est également subdivisé en deux étapes : une exécution à froid pendant laquelle la charge est appliquée une fois sur l‟entrepôt test ; des exécutions à chaud répliquées un certain nombre (paramètre) de fois et qui incluent chacune un rafraîchissement de l‟entrepôt et une exécution de la charge. L‟unique mesure de performance retenue dans DWEB est actuellement le temps de réponse. Il
est calculé séparément pour les rafraîchissements et les exécutions de la charge de requêtes, de manière à ce que chaque temps de réponse atomique puisse être affiché et/ou réutilisé dans une mesure de performance composite. Les temps de réponses totaux, moyens, minimum et maximum, ainsi que les écarts types, sont également calculés automatiquement. A.5 Scénario d’utilisation de DWEB
a. Interface de connexion L‟interface graphique principale de DWEB est représentée dans la Figure ci-dessous. Elle est
divisée en trois sections/panneaux : Database connection, qui permet la connexion tout à tout Système de Gestion de Bases de Données Relationnel (SGBDR) via JDBC (Java Data Base Connectivity) ; Action, qui permet de fixer la valeur des paramètres et de lancer les tests.
Figure 48: Création des tables DW
137
