Composants et modèles pour l’ingénierie des systèmes d’information

Texte intégral

(1)UNIVERSITÉ MOHAMMED V – AGDAL FACULTÉ DES SCIENCES Rabat. N° d’ordre : 2331. THÈSE DE DOCTORAT D’ETAT Présentée par Mounia FREDJ Discipline : Informatique Spécialité : Systèmes d’Information. COMPOSANTS ET MODELES POUR L'INGENIERIE DES SYSTEMES D'INFORMATION. Soutenue le : 24 Mars 2007 Devant le jury. Président : E.H. Bouyakhf. Professeur - Faculté des Sciences - Rabat. Examinateurs : B. Bounabat K. El Himdi J.P. Giraudin A. Mouradi N. Naja S. Slaoui. Professeur - ENSIAS - Rabat Professeur - Faculté des Sciences - Rabat Professeur – LIG-IMAG - Grenoble Professeur – ENSIAS - Rabat Professeur – INPT – Rabat Professeur - Faculté des Sciences - Rabat. Faculté des Sciences, 4 Avenue Ibn Battouta B.P. 1014 RP, Rabat – Maroc Tel +212 (0) 37 77 18 34/35/38, Fax : +212 (0) 37 77 42 61, http://www.fsr.ac.ma.

(2) A ma grandgrand-mère, mère, Mi Aïni Aïni.

(3) Remerciements Ce travail de thèse d’Etat a nécessité non seulement un investissement personnel important, mais aussi le concours et le soutien de très nombreuses personnes. Ce travail n’aurait sans doute pas vu le jour sans le soutien et l’apport moral ou scientifique de nombreuses personnes. Ce travail a fait l’objet d’une co-direction du Professeur Khalid El Himdi de la Faculté des Sciences de Rabat, et du Professeur Abdelhak Mouradi de l’ENSIAS de Rabat. Mes premiers remerciements vont aux membres du jury qui m’ont fait l’honneur de participer à ma soutenance de thèse. Je souhaite mentionner M. ElHoussine Bouyakhf pour avoir accepté de présider ma soutenance de thèse et mes deux rapporteurs M. Bouchaïb Bounabat et Jean-Pierre Giraudin qui m’ont fait le grand honneur de bien vouloir évaluer ma thèse à travers ce document. Je remercie également M. Najib Naja et M. Saïd Slaoui pour avoir bien voulu faire partie du jury de ma thèse et accepter d’examiner mon travail. Je tiens ici à remercier celles et ceux qui ont contribué à ma réussite scientifique et professionnelle : M. Khalid El Himdi d’avoir accepté de m’encadrer et de m’inscrire en 1995. Sans lui, je n’aurais pu poursuivre ma recherche dans le cadre du doctorat d’Etat. Qu’il trouve ici l’expression de ma profonde reconnaissance. M. Abdelhak Mouradi d’avoir bien voulu co-encadrer cette thèse. Je le remercie pour sa gentillesse et ses encouragements, notamment pendant les périodes de doute. Je tiens également à remercier : toute l’équipe Sigma de Grenoble, et en particulier, Dominique Rieu, Agnès Front, avec qui j’ai travaillé pendant les premières années de mes travaux de recherche ; Jean-Pierre Giraudin qui m'a accordé son soutien durant les différentes phases de cette recherche, je le remercie chaleureusement pour ses conseils, son aide et sa gentillesse; mes collègues de l’équipe SIR de l’EMI, en particulier Dalila Chiadmi et Ounsa Roudiès que je remercie pour leur disponibilité et les nombreuses discussions professionnelles et scientifiques que nous avons eues ; sans oublier bien sûr tous mes collègues de l’ENSIAS, et en particulier ceux du département GL, pour leurs encouragements sans relâche. Tous les étudiants de DESA et doctorants avec qui j’ai travaillé, qui nous poussent à avancer..

(4) Enfin, j’ai une reconnaissance particulière pour les personnes et les établissements avec lesquels j’ai collaboré dans le cadre de projets de recherche. Je citerai notamment le projet STIC-GL pour l’opportunité de co-encadrement avec les professeurs J. Bézivin et A. Kriouile -qu’ils trouvent ici l’expression de ma reconnaissance, le projet Medforist pour l’expérience très riche de participer à un projet européen de grande ampleur, et enfin le projet ICRAC de l’université Mohammed V - Souissi qui a permis d’assurer une partie du financement de cette recherche. Je ne peux oublier de remercier aussi tous les membres du personnel administratif et technique de l’ENSIAS, en particulier Mme Chahi, ainsi que l’équipe (ancienne et actuelle) du Centre de Calcul, qui m’a ôté bien des épines "techniques" du pied… Certains encouragements m'ont été particulièrement précieux pour mener à terme ce travail. Je pense ici à ma famille et mes amis qui m'ont soutenue tout au long de ce travail. L'intérêt qu'ils ont manifesté pour ma recherche a constitué pour moi un surcroît de motivation. Un merci particulier à toute ma famille : mes parents qui m’ont épaulé sans relâche ; Latifa et Jalil, pour votre présence et votre soutien ; Judith et Tahar pour m’épauler dans les moments difficiles ; Lili, Salma et Mamoun qui ont toujours été présents quand j’ai eu besoin d’eux, et tous les autres…. petits et grands, que je ne peux citer ici, tant la liste est longue. Un grand merci également à tous mes amis du Maroc, de France, du Canada, …: Sandrine et Lio, Acham et Iluna pour m’avoir soutenu sans relâche ;Yasmina, Nadia C., Nadia B., Noura, Amina, Najah, Itimad, Malak, Ghislaine, Dalila, Jawad, Loubna, Souad, Zoubida, Ismaïl, Ounsa, Michel, Marie-Paule, Yvette, Fouzia, Biya, José, Shirrah, Ilham, Bouchra, Safia, Jamal, Karim, Laïla, Janane, Rachid, Claire, Houria, qui m’ont accordé de leur temps, et ont su m’encourager et me manifester leur confiance. Leur amitié et leur générosité m’ont été d’un soutien précieux. A tous ceux que je n’ai pas cités, mais que je n’oublie pas pour autant. Qu’ils reçoivent par ces quelques lignes toute ma reconnaissance. Et pour finir, ma petite Kenza, mon rayon de soleil, qui m’a donné la force de mener à bout ce travail..

(5) Résumé Le domaine de la conception des systèmes d’information est un secteur très demandeur en techniques et méthodes nouvelles visant à permettre de réduire le temps de conception des systèmes d’information, d’en améliorer la qualité et d’en faciliter la maintenance. Face à ce constat, l’objectif de cette thèse est de s’appuyer sur les techniques de réutilisation des composants (en particulier des patrons), et de transformation de modèles pour l’ingénierie des systèmes d’information. Quatre résultats essentiels ont été produits à l’issue de ce travail de recherche : la proposition d’un (a) formalisme P-Sigma de représentation de patrons, adapté au patrons produit et patrons processus, facilitant la gestion, la recherche et la réutilisation de patrons ; des systèmes de patrons spécifiques visant des domaines particuliers tels que (b) l’ingénierie des besoins et la (c) conception de portail e-gov ; (d) une démarche concrète permettant d’atteindre un modèle spécifique à une plateforme (PSM) à partir d’un modèle qui en est indépendant (PIM). Ce dernier résultat permet de réutiliser un même modèle « métier » pour différentes plateformes ou technologies, et répond ainsi à l’approche MDA, où l’OMG préconise la séparation du savoir-faire métier de son implémentation sur une plateforme technologique donnée.. MOTS-CLEFS. Ingénierie des systèmes d’information, réutilisation, composants réutilisables, patterns, ingénierie dirigée par les modèles, MDA..

(6) Abstract The domain of information systems design needs a lot of new technologies and methods that aim at reducing the time of systems design, improving the quality of the information systems developed and facilitating the maintenance of it. To deal with these needs, the objective of this thesis is to be based on the techniques of components reuse (in particular the patterns) and on models transformation for information systems engineering. We produced four significant results during our research works : the proposal of (a) a formalism P-Sigma of patterns representation, adapted to product patterns and process patterns, facilitating management, the search and the reuse of patterns ; specific systems of patterns aiming particular fields such as (b) requirements engineering and (c) the design of egov portal ; (d) a concrete approach relying on a Y shaped development cycle, allowing to obtain a platform specific model (PSM) starting from a model which is independent of the platform (PIM). This last result makes it possible to reuse the same business model for various platforms or technologies, and give then an answer to the MDA approach, which the initial goal was to separate the business functionality of an information system from the implementation of that functionality on a specific technological platform. Such advances enable new design approach based on reuse of existing and experienced components. This approach must allow decreasing the period of design of information systems, improving their quality and making their management easier.. KEYWORDS. Information systems engineering, reuse, reusable components, patterns, Model Driven Engineering, MDA..

(7) Table des Matières INTRODUCTION GENERALE ......................................................................................................................... 1 PROBLEMATIQUE ................................................................................................................................................. 1 CONTRIBUTIONS DE LA THESE.............................................................................................................................. 3 ORGANISATION DE LA THESE ............................................................................................................................... 5 1.. INGENIERIE DES SYSTEMES D’INFORMATION............................................................................... 8 1.1. INTRODUCTION AUX SI ............................................................................................................................ 8 1.1.1. L'ingénierie des SI comme une ingénierie de produits.................................................................. 11 1.1.2. De l'ingénierie des produits à l'ingénierie des processus ............................................................. 15 1.1.3. De l'ingénierie des processus à l'ingénierie des méthodes............................................................ 16 1.2. LA REUTILISATION DANS L’INGENIERIE DES SI ...................................................................................... 18 1.2.1. Ingénierie des composants réutilisables........................................................................................ 18 1.2.2. Ingénierie des systèmes par réutilisation des composants ............................................................ 22 1.3. SYNTHESE .............................................................................................................................................. 24. 2.. APPROCHE PAR COMPOSANTS .......................................................................................................... 28 2.1. INTRODUCTION ...................................................................................................................................... 28 2.1.1. Un peu d’histoire........................................................................................................................... 29 2.1.2. De l’approche orientée Objet à l’approche Composant ............................................................... 30 2.1.3. Concept général de composant ..................................................................................................... 32 2.1.3.1. 2.1.3.2. 2.1.3.3. 2.1.3.4.. Définition du concept de composant ......................................................................................................... 32 Différents types de composants : critères de classification........................................................................ 35 Composant Conceptuel versus Composant Logiciel.................................................................................. 38 Représentation d’un composant................................................................................................................. 39. 2.1.4. Synthèse......................................................................................................................................... 40 2.2. LES PATRONS D’INGENIERIE ................................................................................................................... 41 2.2.1. Définitions & caractéristiques ...................................................................................................... 41 2.2.2. Usage & utilité des patrons........................................................................................................... 42 2.2.3. Classification des patrons ............................................................................................................. 44 2.2.3.1. 2.2.3.2.. 2.2.4. 2.2.5. 2.2.5.1. 2.2.5.2.. Les patrons processus ................................................................................................................................ 44 Les patrons produit .................................................................................................................................... 45. Représentation des patrons ........................................................................................................... 50 Organisation des patrons : les systèmes de patrons...................................................................... 51 Systèmes de patrons................................................................................................................................... 51 Les relations inter-patrons ......................................................................................................................... 53. 2.2.6. Synthèse......................................................................................................................................... 56 2.3. LES COMPOSANTS METIER ...................................................................................................................... 56 2.3.1. Définitions ..................................................................................................................................... 57 2.3.2. Vers un choix de concepts : Composant métier versus Objet métier............................................. 58 2.3.3. Utilité des composants métier ....................................................................................................... 58 2.3.4. Classification des Composants Métier .......................................................................................... 59 2.3.5. Représentation d’un composant métier ......................................................................................... 61 2.3.6. Organisation des composants métier : les relations inter-composants......................................... 62 2.3.7. Synthèse......................................................................................................................................... 64 2.4. LES FRAMEWORKS ................................................................................................................................. 64 2.4.1. Définitions ..................................................................................................................................... 65 2.4.2. Usage & utilité des frameworks .................................................................................................... 68 2.4.3. Classification des frameworks....................................................................................................... 68 2.4.4. Synthèse......................................................................................................................................... 69 2.5. BILAN .................................................................................................................................................... 70 3.. APPROCHE PAR PATRONS ................................................................................................................... 74 3.1. INTRODUCTION ...................................................................................................................................... 74 3.2. PATRONS POUR L’INGENIERIE DES BESOINS ........................................................................................... 74 3.2.1. Patrons et Ingénierie des besoins.................................................................................................. 75.

(8) 3.2.2. Le langage de patrons Diagnostic d'une Organisation................................................................. 77 3.2.3. Conclusion .................................................................................................................................... 86 3.3. PATRONS POUR LA CONCEPTION D’UN PORTAIL E-GOV .......................................................................... 87 3.3.1. Introduction au e-gov.................................................................................................................... 88 3.3.2. Résultat de l’étude de quelques solutions e-gouvernement ........................................................... 90 3.3.3. Besoins d’une solution e-gov......................................................................................................... 90 3.3.3.1. 3.3.3.2.. 3.3.4. 3.3.4.1. 3.3.4.2. 3.3.4.3. 3.3.4.4.. Besoins génériques .................................................................................................................................... 90 Besoins spécifiques ................................................................................................................................... 93. Système de patterns pour l’e-gouvernement.................................................................................. 96 Le pattern Conception du portail ............................................................................................................... 97 Le pattern Création du contenu.................................................................................................................. 97 Le pattern Gestion du contenu du portail................................................................................................... 98 Le pattern Publication du contenu du portail ............................................................................................. 98. 3.4. PROPOSITION D’UN FORMALISME DE PATRONS : P-SIGMA ................................................................... 101 3.4.1. Diversité des patrons et de leurs formalismes............................................................................. 104 3.4.1.1. Critères de comparaison des composants ................................................................................................ 104 3.4.1.2. Diversité des patrons ............................................................................................................................... 106 3.4.1.3. Diversité des formalismes de patrons ...................................................................................................... 107 a. Un formalisme pour la représentation des patrons produit........................................................................... 107 b. Un formalisme pour la représentation des patrons processus....................................................................... 108 3.4.1.4. Bilan ........................................................................................................................................................ 109. 3.4.2. 3.4.2.1. a. b. c. 3.4.2.2. a. b. c. d.. Formalisme P-Sigma................................................................................................................... 110 Objectifs du formalisme P-Sigma............................................................................................................ 110 Uniformisation de la représentation des patrons produit et processus.......................................................... 110 Meilleure formalisation de l’interface de sélection des patrons ................................................................... 111 Organisation des catalogues de patrons ....................................................................................................... 111 Le formalisme P-Sigma ........................................................................................................................... 111 Structure générale de P-Sigma ..................................................................................................................... 111 La partie Interface ........................................................................................................................................ 112 La partie Réalisation .................................................................................................................................... 114 La partie Relation......................................................................................................................................... 116. 3.4.3. Conclusion .................................................................................................................................. 120 3.5. CONCLUSION ET PERSPECTIVES ............................................................................................................ 121 4.. MODELES ET META-MODELES ........................................................................................................ 124 4.1. INTRODUCTION .................................................................................................................................... 124 4.1.1. Principes de base de l’IDM......................................................................................................... 125 4.1.1.1. 4.1.1.2. 4.1.1.3. 4.1.1.4.. Modèles et RepresentedBy (µ) ................................................................................................................ 125 Métamodèles et ConformsTo (χ)............................................................................................................. 126 Notion d’espace technologique................................................................................................................ 128 La transformation de modèles ................................................................................................................. 129. 4.1.2. Un peu d’histoire......................................................................................................................... 131 4.1.3. Synthèse....................................................................................................................................... 134 4.2. L’APPROCHE MDA .............................................................................................................................. 135 4.2.1. Définition MDA ........................................................................................................................... 135 4.2.2. Organisation 3+1 du MDA ......................................................................................................... 136 4.2.3. La classification de modèles dans MDA : CIM, PIM et PSM ..................................................... 138 4.2.4. La transformation de modèles dans MDA................................................................................... 141 4.2.5. Mise en œuvre de MDA ............................................................................................................... 142 4.3. CONCLUSION........................................................................................................................................ 144 5.. TRANSFORMATION DE MODELES .................................................................................................. 146 5.1. CARACTERISTIQUES DES TRANSFORMATIONS DE MODELES ................................................................. 147 5.1.1. Règles de Transformation ........................................................................................................... 148 5.1.2. Stratégie d’application des règles............................................................................................... 149 5.1.3. Enchaînement des règles............................................................................................................. 150 5.1.4. Organisation des règles .............................................................................................................. 151 5.1.5. Relation Source-Cible ................................................................................................................. 151 5.1.6. Directionnalité ............................................................................................................................ 152 5.1.7. Traçabilité ................................................................................................................................... 152 5.2. DIFFERENTES APPROCHES DE TRANSFORMATION DES MODELES .......................................................... 153.

(9) 5.2.1. 5.2.1.1. 5.2.1.2. 5.2.1.3. 5.2.1.4. 5.2.1.5.. 5.2.2. 5.2.2.1. 5.2.2.2. 5.2.2.3.. 5.2.3. 5.2.3.1. 5.2.3.2. 5.2.3.3.. Catégories d’approches proposées par l’OMG .......................................................................... 153 L’approche marquage .............................................................................................................................. 154 L’approche transformation de métamodèles............................................................................................ 155 L’approche transformation de modèles ................................................................................................... 155 L’approche application de patterns.......................................................................................................... 156 L’approche fusion de modèles................................................................................................................. 157. Catégories d’approches proposées par Czarnecki et Helsen...................................................... 158 Approches Modèle-à-modèle................................................................................................................... 158 Approches hybrides ................................................................................................................................. 161 Autres approches modèle-à-modèle......................................................................................................... 162. Catégories d’approches proposées par Blanc ............................................................................ 162 L’approche par programmation ............................................................................................................... 163 L’approche par template .......................................................................................................................... 163 L’approche par modélisation ................................................................................................................... 164. 5.2.4. Conclusion .................................................................................................................................. 167 5.3. PROPOSITION D’UNE APPROCHE DE TRANSFORMATION POUR MDA..................................................... 169 5.3.1. Introduction................................................................................................................................. 169 5.3.2. Modélisation des plateformes technologiques............................................................................. 171 5.3.3. Un méta-modèle pour les décisions............................................................................................. 173 5.4. CONCLUSION........................................................................................................................................ 178 CONCLUSION GENERALE .......................................................................................................................... 181 BIBLIOGRAPHIE............................................................................................................................................ 185 ANNEXES ......................................................................................................................................................... 209 ANNEXE A : L’OUTIL DDA.............................................................................................................................. 211 ANNEXE B : PROJETS DE RECHERCHE & DEVELOPPEMENT ............................................................................... 219 ANNEXE C : RESPONSABILITES SCIENTIFIQUES ................................................................................................ 227.

(10) Liste des figures Figure 1.1 - Ingénierie d'un système d'information (Source : [Rolland, 93])....................................................... 10 Figure 1.2 - Processus de développement des SI .................................................................................................. 11 Figure 1.3 - De l'ingénierie des produits à l'ingénierie des méthodes ................................................................... 18 Figure 2.1- Un système orienté objet .................................................................................................................... 30 Figure 2.2 - De l’approche objet à l’approche composant .................................................................................... 32 Figure 2.3 - Utilisation des composants par rapport à leur spécificité .................................................................. 34 Figure 2.4 - Vue générale d’un composant ........................................................................................................... 39 Figure 2.5 - Exemple de patron processus ............................................................................................................ 45 Figure 2.6 - Le patron "Rôle" de P. Coad [Coad, 92] ........................................................................................... 47 Figure 2.7- Exemple de patron de conception....................................................................................................... 48 Figure 2.8 - Exemple de patron d’architecture...................................................................................................... 49 Figure 2.9 - Organisation des systèmes de patrons ............................................................................................... 52 Figure 2.10 - Composant métier versus Objet métier............................................................................................ 58 Figure 3.1 Etude de l'existant ................................................................................................................................ 77 Figure 3.2 Rôle des patrons................................................................................................................................... 78 Figure 3.3- Modèle du patron Elément_Contexte ................................................................................................. 83 Figure 3.4 - Modèles des patrons Objectif et Besoin ............................................................................................ 84 Figure 3.5 - Système de patterns pour un portail e-gov ........................................................................................ 96 Figure 3.6 - Le pattern Conception du portail et ses patterns liés ........................................................................ 97 Figure 3.7 - Le pattern Création du contenu du portail et ses patterns liés ........................................................... 97 Figure 3.8 - Le pattern gestion du contenu d’un portail e-gouvernement et ses patterns liés ............................... 98 Figure 3.9 - Le pattern Publication du contenu d’un portail e-gouvernement et ses patterns liés......................... 98 Figure 3.10 : Patron « Revue Technique » [Ambler, 98] .................................................................................... 106 Figure 3.11: Structure générale du formalisme P-Sigma .................................................................................... 112 Figure 4.1 Relation µ entre modèle et système (Source [AS CNRS, 05]) ......................................................... 126 Figure 4.2 - Transformation exogène (Source [Bezivin, 02b]) ........................................................................... 130 Figure 4.3. Notions de base en technologie des objets (Source [Bézivin,04b]) .................................................. 132 Figure 4.4. Notions de base en IDM ................................................................................................................... 132 Figure 4.5 Interprétation de la pile de modélisation multi-niveaux de l’OMG (Source [Bézivin, 04b]) ............ 137 Figure 4.6. La transformation de modèles basée sur les métamodèles (Source [Bézivin, 04b]) ......................... 142 Figure 4.7 Différentes opérations sur les modèles dans le MDA........................................................................ 144 Figure 5.1 Caractéristiques d’une transformation de modèles [Czarnecki, 03] .................................................. 147 Figure 5.2 Caractéristiques des règles de transformation [Czarnecki, 06] ......................................................... 148 Figure 5.3 Caractéristiques de l’enchaînement des règles [Czarnecki, 06] ........................................................ 150 Figure 5.4 Caractéristiques de l’organisation des règles [Czarnecki, 06] ........................................................... 151 Figure 5.5 Caractéristiques de la relation Source-Cible [Czarnecki, 06] ............................................................ 151 Figure 5.6 Caractéristiques de la directionnalité [Czarnecki, 06] ....................................................................... 152 Figure 5.7 Caractéristiques du mécanisme de traçabilité [Czarnecki, 06] ......................................................... 153 Figure 5.8 Marquage d’un modèle (source [OMG, 03a]) ................................................................................... 154 Figure 5.9 Transformation de méta-modèles (source [OMG, 03a])................................................................... 155 Figure 5.10 Transformation de modèles (source [OMG, 03a])........................................................................... 156 Figure 5.11 Deux façons pour l’application de patterns (source [OMG, 03a]) ................................................... 157 Figure 5.12 Fusion de modèles (source [OMG, 03a])........................................................................................ 157 Figure 5.13 Exemple d’un template pour les tables de schémas de bases de données (source [Blanc, 05]) ....... 164 Figure 5.14 Approche par modélisation (source [Blanc, 05]) ............................................................................ 165 Figure 5.15 Vue simplifiée du méta-modèle MOF2.0 QVT .............................................................................. 165 Figure 5.16 Un exemple de transformation de l’approche par modélisation (source [Blanc, 05])...................... 167 Figure 5.17- (a). Le pattern MDA. (b). Le cycle en Y........................................................................................ 169 Figure 5.18 Proposition de métamodèle .Net ...................................................................................................... 174 Figure 5.19 Méta-modèle DDM.......................................................................................................................... 177.

(11) Liste des tableaux Tableau 3-1- Formalisme de patron retenu ........................................................................................................... 76 Tableau 3-2 - Patron Diagnostic ........................................................................................................................... 82 Tableau 3-3 - Synthèse de comparaison des solutions e-gouvernement ............................................................... 90 Tableau 3-4 - Critères de comparaison des composants réutilisables ................................................................. 105 Tableau 3-5 - Partie Interface d’un patron avec P-Sigma ................................................................................... 113 Tableau 3-6 - Partie Réalisation d’un patron avec P-Sigma................................................................................ 114 Tableau 3-7- Partie Relation d’un patron avec P-Sigma ..................................................................................... 117 Tableau 4-1 - Niveaux de systèmes de tranformations ....................................................................................... 130.

(12) Liste des abréviations CIM. Computation Independent Model. CM. Composant Métier. DDA. Design Decision Assistant. IB. Ingénierie des Besoins. IDM. Ingénierie Dirigée par les Modèles. MDA. Model Driven Architecture. MOF. Meta Object Facility. OMG. Object Management Group. PDM. Platform Description Model. PIM. Platform Independent Model. PSM. Platform Specific Model. SI. Système d'Information. UML. Unified Modeling Language.

(13)

(14) Introduction : contexte et problématique. INTRODUCTION GENERALE Traditionnellement, l’ingénierie des systèmes s’organise par la mise en place, dans le cadre d’une méthode (MERISE, OMT, RUP, …) d’une succession de modèles (Entité-Association, Objet, Réseau de Pétri, graphes d’états, modèle de flux, etc.) afin de favoriser un continuum de la définition des besoins des clients jusqu’au système développé et exploité. Cette approche conduit à analyser, concevoir et implanter des systèmes spécifiques. La complexité croissante des systèmes d’information et leur évolution de plus en plus rapide ont motivé un intérêt accru pour les modèles et méthodes de réutilisation. Ces dernières années, une nouvelle approche basée sur la réutilisation de composants, initialement cantonnée dans les étapes d’implantation, s’est imposée de plus en plus dans les étapes en amont (expression des besoins, analyse, conception). La définition de cette nouvelle approche de développement basée sur la réutilisation conduit à faire émerger une grande variété de composants appelés patrons (patterns), objets métier (business objects), canevas (ou frameworks), COTS (Commercial Off-The-Shelf), etc. Ces composants se différencient par leur granularité, par leur niveau d’abstraction ou encore par la nature de la connaissance qu’ils permettent de réutiliser. D’une manière générale, la réutilisation lors du développement des systèmes orientés objet vise trois objectifs : diminuer les coûts de développement et de maintenance, réduire les délais et améliorer la qualité du logiciel. La réutilisation systématique appliquée lors des différentes étapes du développement logiciel (expression des besoins, analyse, conception, implantation) a un enjeu supplémentaire, celui d’une meilleure traçabilité des transformations des objets au sein du processus de développement.. Problématique Cette thèse s'inscrit dans le cadre d’une démarche de réutilisation pour l’ingénierie des systèmes. Les travaux de recherche dans ce domaine sont très importants et variés. La réutilisation constitue une problématique à part entière, tant dans l’ingénierie des logiciels que dans l’ingénierie des modèles. Elle permet l’élaboration d’un système à partir d’entités existantes : objets, composants ou modèles. Elle s’applique aux systèmes dans la totalité de leur cycle de vie, de leur développement à leur exploitation. Les systèmes d’information ne dérogent pas à ce constat et requièrent toujours plus de réutilisation.. 1.

(15) Introduction : contexte et problématique. Pour notre part, nous nous sommes intéressés, dans un premier temps, à la thématique des composants, et particulièrement aux patterns. En effet, ce paradigme apparaît particulièrement adapté à la réutilisation, que ce soit au niveau de la conception de systèmes, leur maintenance ou leur évolution. Ainsi, l'accent sera mis sur la technologie des patrons pour capitaliser et réutiliser des produits et des fragments de processus de développement. De manière générale, un patron décrit un problème fréquemment rencontré dans un domaine donné ainsi qu'une solution générale et consensuelle pour le résoudre. Dans le domaine de l'ingénierie des méthodes, les patrons peuvent être utilisés pour capitaliser des fragments de processus. Par exemple, un patron peut être utilisé pour décrire comment identifier des composants métiers lors d'une analyse de domaine. Nous avons abordé le thème de la réutilisation via les patrons d’un point de vue théorique et d’un point de vue pratique. Le premier a pour enjeu d’affiner et de formaliser la représentation des patrons. En effet, les patrons existants à l’heure actuelle sont de plus en plus nombreux et de plus en plus variés. Les bibliothèques de patrons offrent des patrons produits ou des patrons processus de portée et de couverture variées (patrons d’analyse, de conception ou d’implantation, patrons généraux, de domaine ou d’entreprise). De telles bibliothèques, bien que complémentaires, peuvent difficilement être combinées lors du développement des applications. Une des principales raisons est qu’il n’existe pas aujourd’hui un formalisme commun de représentation des patrons. Si jusqu’alors le fait qu’un système de patrons soit représenté dans un formalisme de patrons particulier n’était pas très gênant, il était nécessaire de disposer d’un formalisme commun à tous les types de patrons. Le formalisme proposé est destiné à pallier certaines insuffisances des formalismes de patrons existants dédiés à l’ingénierie des SI. Du point de vue pratique, nous nous sommes intéressés à développer des patrons spécifiques pour des domaines particuliers tels que l’ingénierie des besoins et la conception de portails e-gov. Parallèlement à cette recherche, nous avons abordé l’approche de la réutilisation sous l’angle de l’ingénierie dirigée par les modèles, et en particulier l’approche MDA. L’idée était de pouvoir là aussi, faire de la réutilisation, mais cette fois-ci dans le cadre de la technologie MDA : comment réutiliser un même modèle « métier » pour différentes plateformes ou technologies. Nous considérons que la problématique de processus de transformation PIM-. 2.

(16) Introduction : contexte et problématique. PSM dans le contexte de MDA a comme objectif principal la réutilisation, en s’appuyant cette fois-ci sur des techniques de transformation de modèles. En effet, dans sa vision MDA, l’OMG insiste clairement sur la séparation du savoir-faire métier, de son implémentation sur une plateforme technologique donnée. Cependant elle ne présente aucune démarche concrète pour atteindre cet objectif. La question pour nous était de proposer une approche permettant d’atteindre un modèle spécifique à une plateforme – un PSM – à partir d’un modèle qui en est indépendant – un PIM.. Contributions de la thèse Nos travaux. permettent d’aboutir à différentes contributions dans l’ingénierie des. systèmes d’information : -. 1) d’une part, une contribution centrée patrons, et formalisée par un ensemble de composants orientés “processus” (c’est-à-dire de savoir-faire) combinés à des composants orientés “produit” (c’est-à-dire de savoir) réutilisables dans de nombreuses applications. Nous pensons que la définition cohérente et uniformisée de ces deux types de composants, ainsi que leur usage au sein de processus d’ingénierie "par" et "pour" la réutilisation guidés à l'aide d'un environnement adapté à des raisonnements semi-automatisés, constituent des avancées technologiques nécessaires pour permettre l’usage généralisé des bibliothèques de composants, rationaliser les démarches d’ingénierie et les industrialiser. Le résultat est une bibliothèque de patrons en Ingénierie des Besoins, une bibliothèque de patrons processus pour la conception d’un portail e-gov, et d’un point de vue théorique, la proposition d’un formalisme P-Sigma pour les patrons.. •. Des bibliothèques de patrons dans différents domaines :. Au niveau de l’étape d’ingénierie des besoins ([Fredj, 99], [Roudiès, 99], [Roudiès, 01]) : nous avons identifié certains phénomènes récurrents en ingénierie des besoins et avons proposé des solutions à leur modélisation sous forme de patrons. Le système de patrons proposé permet, d’une part, de guider l'expression des besoins et de justifier les besoins définis et, d’autre part, de faciliter la réutilisation des composants mis en évidence dans l'ingénierie des besoins.. 3.

(17) Introduction : contexte et problématique. Au niveau de la conception de portail e-gov : ([Ouchetto, 04] [Ouchetto, 05a], [Ouchetto, 05b], [Ouchetto, 05c], [Ouchetto, 06b]). L’objectif de ce travail a été de cerner et de distinguer les besoins génériques des besoins spécifiques d’une architecture e-gouvernement. La détermination de ces besoins a été basée sur une étude comparative de quelques architectures internationales, qui a permis de proposer des patterns processus pour assister le développement d’une architecture e-Maroc. •. La formalisation des patrons : avec le formalisme P-Sigma ([Conte, 01a], [Conte, 02a]).. Les principaux objectifs du formalisme P-Sigma proposé sont d’exprimer une sémantique commune à la majorité des formalismes proposés dans la littérature, d’uniformiser l’expression des patrons produits et des patrons processus,. d’expliciter l’interface de. sélection des patrons, et de permettre une meilleure organisation des bibliothèques de patrons. Ce formalisme P-Sigma a fait l’objet d’une instanciation et de deux expériences d’utilisation industrielles qui ont été évaluées. Un outil des gestion et d’application de patrons AGAP ([Conte, 02b]) permet d’offrir un environnement de définition et d’utilisation des patrons, qui fait la distinction entre formalismes de patrons et systèmes de patrons. AGAP s’adresse non seulement aux ingénieurs d’application, mais permet également aux ingénieurs de patrons de définir des systèmes de patrons dans le but d’améliorer le niveau de réutilisabilité.. -. 2) d’autre part, une contribution centrée modèles, en offrant une démarche de transformation pour MDA, associée à un outil DDA ([Bézivin, 02e], [Belangour, 03], [Belangour, 05], [Belangour, 06a], [Belangour, 07]).. •. Approche de transformation pour MDA et outil DDA. Dans ce contexte, une démarche a été proposée, s’appuyant sur le cycle en Y qui constitue l’axe de base du processus de développement logiciel 2TUP par Pascal Roques [Roques, 04]. Le savoir-faire métier, capitalisé par le PIM, constitue la branche gauche du cycle en Y tandis que la branche droite représente la plateforme technologique visée par le PIM et qui est représentée par un modèle de description de la plateforme : un PDM. Nous pensons que le modèle PDM est le maillon manquant à la transformation d’un PIM vers PSM. La jonction des deux branches est réalisée à travers le tissage automatique des modèles PIM et PDM. Pour ce faire, un modèle explicite appelé modèle de décisions de conception ou Design Decision. 4.

(18) Introduction : contexte et problématique. Model (DDM) a été défini. Grâce à ce modèle, le tronc du cycle en Y est construit pour aboutir au PSM final.. Organisation de la thèse. Notre introduction a défini le cadre de réflexion dans lequel se situe ce travail de thèse. Elle a présenté la problématique abordée dans notre travail de thèse, ainsi que les contributions dans le domaine de la réutilisation de l'ingénierie des SI et de l’ingénierie des modèles. La suite de ce document est constituée de 5 chapitres : Le chapitre 1 introduit les concepts fondamentaux des systèmes d'information sur lesquels s’appuie notre travail et montre l’intérêt de la problématique de la réutilisation dans les SI.. Le chapitre 2 aborde l’approche de développement de systèmes d’information basée sur la réutilisation des composants : il présente ainsi les composants les plus représentatifs de cette tendance. Le chapitre 3 s’intéresse en particulier à l’approche par patrons (patterns). Un patron constitue une base de savoir et de savoir-faire pour résoudre un problème récurrent dans un domaine donné. Ce chapitre présente les différents travaux réalisés, fondés sur une démarche à base de patrons : proposition d’un formalisme pour les patrons, d’un langage de patrons pour l’ingénierie des besoins, et de patrons processus pour la conception de portails egov. Le chapitre 4 porte sur les modèles et métamodèles dans le contexte de l’ingénierie des modèles. Il recouvre également la démarche MDA préconisée par l’OMG. Le chapitre 5 traite de la problématique de la transformation de modèles. Après un tour d’horizon des différentes approches existantes, il expose une proposition d’approche pour MDA. La conclusion de ce mémoire reprend les grandes lignes de cette étude et notre contribution. Elle montre également les diverses prolongations et perspectives possibles de ce travail.. 5.

(19) Introduction : contexte et problématique. 6.

(20) CHAPITRE 1 INGENIERIE DES SYSTEMES D’INFORMATION. 7.

(21) Chapitre I – Ingénierie des Systèmes d’information. 1. INGENIERIE DES SYSTEMES D’INFORMATION Avant de présenter la réutilisation dans l’ingénierie des Systèmes d’Information (SI), qui constitue le cœur de notre problématique de recherche, nous souhaitons introduire les concepts fondamentaux des systèmes d'information, permettant ainsi de situer le domaine de nos travaux (section 1.1). La deuxième section du chapitre développe les concepts clés de la réutilisation par composants dans les SI (section 1.2).. 1.1.. Introduction aux SI. La notion de système d’information a été très largement commentée et a fait l’objet de nombreuses définitions ne recouvrant pas forcément des concepts équivalents [Pantazis, 96]. Deux orientations principales peuvent être décelées : la première considère le SI comme appartenant à une certaine catégorie de système informatique. La seconde, qui découle de l'approche systémique [Le Moigne, 90], considère que le SI est étroitement lié à un système plus vaste, ce dernier correspondant généralement à l'entreprise [Collongues, 89]. La définition apportée par Mylopoulos ([Mylopoulos, 95], cité dans [Pantazis, 96], est représentative de la première orientation : “Information systems are computer-based systems which facilitate the storage, retrieval and management of large amounts of information”. Cette définition, qui se rapporte spécifiquement à ce que nous appellerons un SI informatisé, paraît trop restrictive, et va à l’encontre du postulat de l'approche systémique qui présente le SI comme une composante d'un système plus vaste. La définition donnée par O'Brien cité dans [Pantazis, 96]), va dans cette direction puisqu'il définit un SI comme « [...] un ensemble de personnes, de procédures et de ressources qui recueillent de l'information, la transforment et la distribuent au sein d'une organisation ». Il manque toutefois dans cette dernière définition une référence à la finalité du SI que nous trouvons dans la définition proposée par C. Rolland [Rolland, 86] : « Un système d'information est un artefact, un objet artificiel greffé sur un objet naturel qui peut être une organisation. Il est conçu pour mémoriser un ensemble d'images de l'objet réel à différents moments de sa vie ; ces images doivent être accessibles par les partenaires de 8.

(22) Chapitre I – Ingénierie des systèmes d’information. l'organisation qui s'en servent pour décider des actions à entreprendre dans les meilleures conditions. Un système d'information est, en quelque sorte, une extension de la mémoire humaine qui amplifie le pouvoir de mémorisation des acteurs de l'organisation et facilite leur prise de décision. » L'approche systémique [Rolland, 86] permet de positionner précisément le rôle du SI. Elle postule que ce dernier est constitué de trois sous-systèmes qui échangent des informations entre eux : •. le système opérant incarne le comportement du système complexe [Le Moigne, 90] et est à l'origine de l'activité et de la dynamique de ce dernier. Il exécute les tâches demandées par le système de pilotage et est affecté par les décisions de celui-ci.. •. le système de pilotage définit les objectifs du système, prend les décisions et transmet ses instructions au système opérant.. •. le système d’information assure le lien entre le système opérant et le système de pilotage. Le SI enregistre sous forme symbolique les opérations du système opérant (le comportement du système complexe), les mémorise et les met à disposition du système de décision. Ce dernier, après avoir élaboré ses décisions d'action, les fait enregistrer et mémoriser par le SI, en les transmettant "pour action" [Le Moigne, 90]. Ce même auteur affirme que ce modèle à trois niveaux (opération - information - décision) permet en tout temps d'entreprendre la modélisation d'un système complexe. De plus, il ne faut pas oublier que tout système complexe est en interaction constante avec son environnement, qui est défini comme "l'ensemble des éléments n'appartenant pas au système, et dont l'état est susceptible d'affecter ou d'être affecté par le système" [Le Moigne, 84].. Les quelques paragraphes qui précèdent nous permettent de mettre en évidence que le système d'information a pour mission d'emmagasiner de l'information et de la rediffuser, sous une forme permettant son utilisation « pour exécution » par le système opérant ou pour permettre la décision et le pilotage par le système de pilotage. Matheron [Matheron, 91], en se référent au SI d'une entreprise, précise que "le système d'information d'une entreprise est [...] un système dont les flux entrants et sortants sont exclusivement constitués d'information". Il devient dès lors évident qu'à partir du moment où ces flux deviennent nombreux et compliqués (ce qui est le cas des systèmes complexes), l'informatique peut apporter son soutien. L'ingénierie des Systèmes d'information est quant à elle définie par D. Avison [Avison, 97] comme le processus par lequel les analystes du système, les ingénieurs informaticiens, les. 9.

(23) Chapitre I – Ingénierie des Systèmes d’information. programmeurs et les utilisateurs finaux construisent les systèmes d'information. Elle peut être présentée comme un processus par lequel les besoins du SI sont transformés en une solution logicielle fiable. L'ingénierie des SI est également connue sous le nom de processus de développement de SI. C. Rolland [Rolland, 93] présente l'ingénierie des SI sous la forme de deux processus complémentaires (cf. Figure 1.1) : L'ingénierie des besoins qui consiste à acquérir et représenter les connaissances dont les utilisateurs ont besoin. Ceci se traduit par l'élaboration d'un Schéma Conceptuel du SI. L'ingénierie des systèmes qui consiste à implanter le schéma conceptuel du SI sur un système technologique en utilisant les technologies d'information. Ce système facilite la gestion des connaissances dont les utilisateurs ont besoin. C'est le schéma conceptuel du SI qui articule la transformation des besoins en une solution logicielle. Ingénierie des Besoins Besoins des utilisateurs. validation. Acquisition et représentation des connaissances. Schéma Conceptuel du SI Conception logique. Vérification. Système Technologique. Ingénierie des Systèmes. Figure 1.1 - Ingénierie d'un système d'information (Source : [Rolland, 93]) Le processus de développement d'un SI comprend différentes étapes ou activités que l'on peut résumer en : l'analyse, la conception et l'implantation (cf. Figure 1.2). La phase d'analyse part d'un problème du monde réel et dresse une représentation du domaine du problème. Cette représentation est le point de départ de la phase de conception qui aboutit à une représentation du domaine de la solution. Enfin, la phase d'implantation traduit le domaine de la solution dans un système technologique [Front, 97].. 10.

(24) Chapitre I – Ingénierie des systèmes d’information. Problème du monde réel. Analyse Représentation du domaine du problème Conception Représentation du domaine de la solution. Implantation Solution dans un système technologique. Figure 1.2 - Processus de développement des SI Depuis le début des années 1960, l’ingénierie des systèmes d’information a constamment évolué proposant des méthodes facilitant la conception des logiciels. C. Rolland [Rolland, 05] a montré que la complexité des systèmes d’information et la diversité croissante des domaines d’application des TIC rendent incontournable l’emploi d’une méthode. Pour l’auteur, « Une méthode d’ingénierie de SI est un guide pour le développement du système d’information. Ce guide apporte, d’une part, un ensemble de modèles qui sont des moules de représentation du produit SI selon différentes perspectives et à différents niveaux d’abstraction, et d’autre part, une ou plusieurs démarches, c’est-à-dire des façons de procéder pour aboutir à un produit de qualité ». Un des grands enjeux des méthodes d’ingénierie est aujourd’hui de fournir des démarches et des modèles permettant le développement des systèmes dans un continuum de transformations [Rieu, 99c]. 1.1.1. L'ingénierie des SI comme une ingénierie de produits Initialement, l'ingénierie des SI se déroulait sans aucune méthodologie explicite [Avison, 97]. L'accent était mis sur la programmation et peu d'intérêt était porté à la bonne formulation des besoins utilisateurs. Les SI conçus étaient par conséquence dans la plupart des cas inadaptés aux besoins, et les programmeurs passaient la majorité de leur temps à corriger et à adapter l'application déjà en milieu opérationnel. Par ailleurs, la gestion du projet de développement était rendue difficile à cause de la difficulté d'estimation des délais de développement (livraison, tests, etc.) qui étaient souvent trop grands. Cette situation est devenue critique avec l'expansion de l'utilisation des systèmes informatisés. Un besoin pour des méthodologies organisant le développement des SI s'est fait ressentir.. 11.

(25) Chapitre I – Ingénierie des Systèmes d’information. L'ingénierie des SI se fait désormais selon des méthodes. Le terme méthode vient du grec methodos qui signifie «moyen d’investigation». Harmsen [Harmsen, 97] cité dans [Rolland, 05] détermine ce que sont ces moyens d’investigation : «une collection de procédures, de techniques, de descriptions de produit et d’outils pour le support effectif, efficace et consistant du processus d’ingénierie d’un SI ». D’autres définitions de la notion de méthode ont été proposées dans [Avison, 97], [Rumbaugh, 95], [Tessier, 95] [Rolland, 05] et la plupart d'entre elles convergent vers l'idée qu'une méthode est une manière de faire suivant certains principes et toujours avec un certain ordre. Cette acception est synthétisée par Booch [Booch, 91] qui définit une méthode comme « un processus rigoureux permettant de générer un ensemble de modèles qui décrit divers aspects d’un logiciel en cours de construction en utilisant une certaine notation bien définie». En d’autres termes, une méthode traite les deux aspects de l’ingénierie, le produit et le processus, et comporte deux éléments : un ou plusieurs modèles de produit1 et un ou plusieurs modèles de processus. C. Rolland [Rolland, 88] structure la méthode en définissant quatre composants indissociables et complémentaires de cette notion: •. des modèles : un modèle est une ensemble de concepts et de règles pour les utiliser, destiné soit à expliquer et construire la représentation des phénomènes organisationnels, soit à expliquer et représenter les éléments qui composent le SI et leurs relations. Une méthode constitue ainsi un modèle d'emploi des modèles;. •. des langages : un langage est un ensemble de constructions qui permettent de décrire formellement les spécifications du SI élaborées aux différents stades du processus de conception en s'appuyant éventuellement sur les modèles de la méthode;. •. une démarche : la démarche est le processus opératoire grâce auquel s'effectue le travail de modélisation, de description, de réalisation du SI;. •. des outils ou techniques : ils peuvent concerner les trois composantes ci-dessus, et ont pour objectif d'aider leur mise en œuvre.. D. Rieu [Rieu, 99c] définit par ailleurs une méthode d'analyse et de conception de SI comme : •. un ensemble de modèles (formalismes) permettant de représenter les systèmes sous différents aspects (statique, dynamique, fonctionnel) et à différents niveaux d'abstraction. 1 Par produit est désigné le produit de l'activité d'ingénierie, c'est le SI à développer. En effet, il est usuel de distinguer la notion de "produit" de celle de "processus" dans de nombreux domaines d'ingénierie et notamment l'ingénierie des SI. T.W. Olle [Olle, 88] décrit le produit comme "le résultat à atteindre" et le processus comme "le chemin qu'il faut parcourir pour atteindre le résultat".. 12.

(26) Chapitre I – Ingénierie des systèmes d’information. (expression des besoins, analyse, conception). Ces modèles sont en fait des modèles de produits, c'est à dire des formalismes permettant de décrire le SI à développer (par exemple le modèle entité/Association d'un système d'information bancaire). •. une (des) démarche(s) ou processus permettant de guider les activités de développement. C'est une succession d'étapes permettant en particulier de passer d'une modélisation du système à une autre. Ces démarches sont souvent soit trop imprécises (termes floues) soit trop rigides (constituées d'une longue succession d'étapes et donc inadaptées aux petites applications).. De nombreuses méthodes2 ont été mises au point depuis plusieurs années et il est très difficile d'être exhaustif lorsqu'il s'agit de recenser les méthodes existantes. A ce sujet, J. Martin [Martin, 85] parle de "jungle des méthodes". Le nombre d'ouvrages qui traitent des méthodes est donc considérable. Nous présentons succinctement les principales caractéristiques des méthodes proposées en s'inspirant de la typologie présentée par C. Tessier [Tessier, 95]. En se basant sur le type d'approche, quatre classes de méthodes sont distinguées: •. les méthodes d'analyse qui datent du début des années 1960. Elles sont nées de la préoccupation des informaticiens à standardiser le métier de développeur d'application et à offrir une approche industrielle d'informatisation. Ces méthodes se sont particulièrement intéressées à la réalisation des systèmes et ensuite à leur conception. Elles adoptent deux approches principales3 : -. une approche analytique, ou par les données, qui recense l'information à fournir en sortie du système et remonte aux entrées comme la méthode MINOS,. -. une approche synthétique, ou par les fonctions, qui est axée sur les traitements et recherche les informations d'entrée qui sont nécessaires pour en déduire les résultats comme la méthode CORIG.. •. les méthodes cartésiennes des années 1970 comme SADT (Structured Analysis and Design Technique) ou JSD (Jackson System Development). Ces méthodes se caractérisent par une approche fonctionnelle qui met en œuvre des concepts et des techniques de décomposition hiérarchique, s'appliquant sur les processus et les flux de données (ou flux d'information) et préconise une analyse et une conception du SI à partir de la définition de fonctions. Le processus d'analyse et de conception débute par l'identification d'une fonction globale de gestion. Le traitement de l'information répond aux règles de. 2 Notons que certains auteurs utilisent le terme de méthodologie à la place de méthode. C. Tessier [Tessier, 95] précise. qu'une méthodologie se rapporte à l'étude des méthodes et qu'une méthode désigne à l'origine un ensemble de démarches qui suit l'esprit pour découvrir et démontrer la vérité dans les sciences. 3 cf. [Tessier, 95] p. 82.. 13.

(27) Chapitre I – Ingénierie des Systèmes d’information. procédures de gestion pour produire des sorties. La démarche de travail est descendante, autrement appelée "top-down". Toute fonction est décomposée en sous-fonctions, et ainsi de suite, par raffinements successifs, jusqu'à ce que les ensembles élémentaires soient intelligibles. Cela donne une représentation en arbre : les fonctions globalement perçues sont éclatées en processus spécifiques. Les relations entre ces derniers sont également recherchées. Ces méthodes ont été influencées par la programmation modulaire. •. les méthodes systémiques des années 1980 comme MERISE (Méthode d'Etude et de Réalisation Informatique pour les Systèmes d'Entreprise), AXIAL (Analyse et Conception de Systèmes d'Informatisation Assistées par Logiciels), REMORA, IA-NIAM (Nijesseb's Informations Analysis Method), IDA (Interactive Design Approach) : ces méthodes préconisent une approche conceptuelle globale du SI. Elles adoptent un processus de modélisation par niveaux d'abstraction successifs. Historiquement, les premières propositions ont essentiellement concerné la modélisation des données. Ainsi se sont développées plusieurs techniques de modélisation : relationnelle, entité-association, binaire, sémantique. A leur suite, des formalismes pour les traitements et les communications ont été élaborés. Les méthodes systémiques proposent soit des modèles bien séparés (étude statique puis dynamique), soit des modèles qui synthétisent les deux aspects. A ce sujet, certaines techniques de modélisation associent la représentation de la structure du système d'information et celle de son comportement.. •. les méthodes objet des années 1990 : ces méthodes sont une conséquence de l'importance croissante des langages de programmation orientés objet de type C++ ou SmallTalk. Les méthodes objet permettent des spécifications détaillées des éléments d'un SI en introduisant la notion d'objet regroupant structures de données et traitements [Chabre, 97]. Elles proposent des spécifications globales d'un SI par l'intermédiaire de spécifications statiques et dynamiques. Certaines méthodes proposées sont réellement nées des concepts orientés objet comme OOA (Object Oriented Analysis), OOD (Object Oriented Design), OMT (Object Modeling Technique ) et OOSE (Object Oriented Software Engineering) [Jacobson, 92], d'autres méthodes ont été étendues pour prendre en compte ces concepts comme MERISE/2 et OOM (Orientation Objet dans Merise). Les méthodes objet étant de plus en plus nombreuses (plus de soixante-dix méthodes4), des tentatives d'unification ont été effectuées. En particulier, le langage UML (Unified Modeling Language) né de l'unification des méthodes objet initiée par G. Booch (méthode Booch), J. Rumbaugh (méthode OMT) et I. Jacobson (méthode OOSE). En réponse à l'appel d'offre de l'OMG (Object Management Group) sur la standardisation des langages de modélisation objet, UML1.0 [OMG, 97] a été adopté comme standard de modélisation objet en novembre 1997. Notons qu'un consensus est établi sur le fait qu'UML n'est pas une méthode mais un. 4 Cette donnée est prise de [Kettani, 98] p.14.. 14.