REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE Ministère de l'enseignement supérieur et de la recherche scientifique
Université Mentouri de Constantine Faculté des sciences de l'ingénieur
Département d'Informatique
Numéro d’ordre : 199/ Mag/ 2010 Numéro de série : 004/ inf / 2010
Mémoire en vue de l’obtention du diplôme Magistère en informatique Option : Système distribué
Présenté par :
Abderrezak Samira
Soutenue le 13 / Juin / 2010 Devant le jury :
Président
:Pr. N. Zarour
Professeur à l’université Mentouri ConstantineRapporteur: Dr. R. Maamri
Maître de conférence à l’université Mentouri ConstantineExaminateur : Dr. A. Chaoui
Maître de conférence à l’université Mentouri ConstantineExaminateur : Dr. S. Merniz
Maître de conférence à l’université Mentouri ConstantineAtelier de génie logiciel à base d’agents
Remerciements
Mr Ramdane MAAMRI, Maître de Conférence à l’université de Constantine, a pris la responsabilité de diriger ce travail dans ses moments délicats ; qu’il trouve ici l’expression de ma profonde gratitude et reconnaissance pour son soutien constant, ses encouragements continus, sa patience et sa qualité humaine qu'il m'a manifesté durant la réalisation de ce mémoire.
Le sujet de ce travail a été proposé par le professeur Zaidi SAHNOUN de l’université de Constantine, sa réalisation a été initiée avec lui ; Je lui adresse tous mes remerciements pour ces précieux conseils et ces bonnes orientations.
Je remercie vivement Mr Nacereddine ZAROUR, Professeur à l’université de Constantine, pour l’honneur qu’il m'a fait en acceptant de présider de jury de ce mémoire.
Je remercie vivement Mr Allaoua CHAOUI, Maître de Conférence à l'Université de Constantine, et Mr Salah MERNIZ, Maître de conférence à l’Université de Constantine, de m'avoir fait l’honneur d’accepter de participer au jury de ce mémoire pour le juger.
Je souhaite adresser mes vifs remerciements à mon mari pour son aide, son soutien et sa patience. Je remercie tous ceux qui m'ont aidé dans la réalisation de ce travail et j’exprime particulièrement toute ma profonde reconnaissance à Naouel Ouafek et Mme Imen Bousbough pour leur soutien et leur aide.
Je tiens à remercier infiniment mes parents pour leurs encouragements et leur soutien aux moments de joie et de détresse.
Je remercie enfin tous les membres de ma famille chacun par son nom.
A Hidaya, Yahya
et Oussama
Résumé
Les ateliers de génie logiciel ont un rôle essentiel dans l’amélioration de la productivité et la qualité des logiciels. Leur objectif majeur est d’automatiser au maximum le processus de développement du logiciel. La réalisation de cet objectif implique une assistance dans les différentes phases du cycle de vie du logiciel.
Une assistance intelligente active au processus de développement du logiciel peut améliorer significativement le rendement des outils en leurs donnant plus de souplesse et de flexibilité. Ce travail donne une approche basée sur l’utilisation d’un Système Multi Agents pour aider le développeur dans la réalisation de ses logiciels par la modélisation UML, en lui fournissant une assistance au développement du processus logiciel. Le processus utilisé est le Rational Unified Process.
Mots Clés
Atelier de génie logiciel, Assistance intelligente, RUP, Système multi agent.
Abstract
CASE tools have a critical role in improving productivity and software quality. Their major goal is to automate the process of software development to the maximum. Achieving this objective involves assistance in the different phases of the software lifecycle. Active intelligent assistance for the conduct of the software process can significantly improve the performance of the tools in their giving more flexibility and supplest. This work gives an approach based on the use of a system Multi Agents to assist the developer in the achievement of its software with the UML modelling, by providing assistance to the way of working throughout the process. The process used is the rational Unified Process.
Key words
ﺺﺨﻠﻣ
تﺎﯿﺠﻣﺮﺒﻟا ةدﻮﺟ و ﻲﺳﺪﻨﮭﻟا ﻞﻤﻌﻟا ﺔﯿﺟﺎﺘﻧإ ﻦﯿﺴﺤﺗ ﻲﻓ ﻢﺳﺎﺣ رود ﺎﮭﻟ تﺎﯿﺠﻣﺮﺒﻟا ﺔﺳﺪﻨھ تﺎﺷرو
.
ﻲﺴﯿﺋﺮﻟا ﺎﮭﻓﺪھ
ﺪﺣ ﺪﻌﺑأ ﻰﻟإ ﺔﯿﻟآ تﺎﯿﺠﻣﺮﺒﻟا ﺮﯾﻮﻄﺗ ﺔﯿﻠﻤﻋ ﻞﻌﺟ ﻮھ
.
ﻞﺣاﺮﻣ ﻒﻠﺘﺨﻣ ﻲﻓ ةﺪﻋﺎﺴﻤﻟا ﻢﯾﺪﻘﺗ ﺐﻠﻄﺘﯾ فﺪﮭﻟا اﺪھ ﻖﯿﻘﺤﺗ
ا هﺪھ ﻞﻌﺟ ﻦﻜﻤﯾ و تﺎﯿﺠﻣﺮﺒﻠﻟ ﺔﻠﻣﺎﻜﻟا ةﺎﯿﺤﻟا ةرود
ﺔﻧوﺮﻣ ﺎﮭﺋﺎﻄﻋﺈﺑ ﺔﻟﺎﻌﻓ و ﺔﯿﻛذ تﺎﺷرﻮﻟا ءادأ ءﺎﻨﺛأ ةﺪﻋﺎﺴﻤﻟ
ﺮﺒﻛأ
.
مﺎﻈﻧ لﺎﻤﻌﺘﺳإ ﻰﻠﻋ ﺪﻤﺘﻌﺗ ﺔﯿﺠﮭﻨﻣ لوﺎﻨﺘﯾ ﺚﺤﺒﻟا اﺬھ
ﻣ
ﻞﺣاﺮﻣ ﻲﻓ ﺔﯿﻟﻵا ﺞﻣاﺮﺒﻟا يرﻮﻄﻣ ةﺪﻋﺎﺴﻤﻟ ءﻼﻛﻮﻟا دﺪﻌﺘ
.RUP
ﻮھ ﻚﻟد ﻖﯿﻘﺤﺗ ﻞﺟأ ﻦﻣ ﻞﻤﻌﺘﺴﻤﻟا
ﺞﮭﻨﻤﻟا
.
UML
ﺔﺟﺬﻤﻨﻟا لﺎﻤﻌﺘﺳﺈﺑ ﻢﮭﺠﻣاﺮﺑ
زﺎﺠﻧإ
ﺔﯿﺣﺎﺘﻔﻣ تﺎﻤﻠﻛ
RUP
ﺞﮭﻨﻤﻟا
,
ءﻼﻛﻮﻟا دﺪﻌﺘﻣ مﺎﻈﻧ
,
ﺔﯿﻛﺬﻟا ةﺪﻋﺎﺴﻤﻟا
,
تﺎﯿﺠﻣﺮﺒﻟا ﺔﺳﺪﻨھ ﻞﻤﻋ تﺎﺷرو
Sommaire
INTRODUCTION GENERALE ... 1
CHAPITRE 1 ... 4
LES ATELIERS DE GENIE LOGICIEL ... 4
1. INTRODUCTION ... 4
2. LE GÉNIE LOGICIEL ... 4
3. LE PROCESSUS LOGICIEL ... 5
3.1. Le rôle du processus de développement ... 5
3.2. Les différentes activités du processus logiciel ... 6
3.3. Modèles de Cycle de vie ... 6
3.3.1. Modèle en cascade ... 7
3.3.2. Modèle en V ... 7
3.3.3. Modèle en spirale ... 8
3.3.4. Modèle par incrément ... 8
3.3.5. Modèle itératif et incrémental ... 9
4. NÉCESSITÉ D’UN ENVIRONNEMENT DE PRODUCTION DE LOGICIEL ... 10
5. ATELIERS DE GÉNIE LOGICIEL OU OUTILS CASE : ... 10
5.1. L'origine de “CASE” ... 10
5.2. Définitions ... 10
5.3. Objectifs et Avantages des ateliers CASE ... 11
5.4. Constituants d'un atelier de génie logiciel ... 12
5.4.2. Les méthodes... 13
5.4.3. Les outils ... 13
5.5. Intégration des outils CASE ... 14
5.5.1. Intégration par l’interface : ... 15
5.5.2. Intégration par les données : ... 15
5.5.3. Intégration par le contrôle ... 16
5.5.4. L’intégration des procédés ... 16
5.6. Les différents types d'AGL ... 17
5.6.1. Outils CASE à base de l’étendue de leur support ... 18
5.6.2. Outils CASE à base de cycle de vie ... 19
5.6.2.1. Outils CASE orientés conception (Upper CASE Tools) ... 19
5.6.2.2. Outils CASE orientés réalisation (Lower CASE Tools) ... 20
6. COMPARAISON DE QUELQUES AGL EXISTANT ... 21
6.1. ArgoUml... 21
6.2. IBM Rational XDE ... 21
6.3. Visible Analyst ... 21
6.4. Enterprise Architect v5.0” by Sparx Systems ... 22
6.5. Rational Rose ... 22 6.6. NATURE ... 23 6.7. CPCE ... 24 6.9. Le Projet ARGO ... 24 6.10. Le projet ALF (1987 - 1992) ... 24 6.11. WayPointer ... 24 6.12. OOExpertProcessModel ... 25
6.13. UCDA (Use Case Driven Assistant) ... 25
7. CONCLUSION ... 27 CHAPITRE 2 ... 28 L’APPROCHE AGENTS ... 28 1. INTRODUCTION ... 28 2. CARACTÉRISTIQUES D’UN AGENT ... 30 3. ARCHITECTURES D’UN AGENT ... 31 3.1. Agent réactif ... 31
3.1.1. Agent à réflexes simples ... 32
3.1.2. Agent conservant une trace du monde ... 32
3.2. Agents délibératifs ... 33
3.2.1. Agent ayant des buts ... 33
3.2.2. Agent utilisant une fonction d’utilité ... 34
3.2.3. Agent BDI (Belief, Desire, Intentions) ... 35
3.3. Agent hybride ... 36
4. TYPOLOGIE D'AGENTS ... 37
4.1. Les agents collaboratifs ... 37
4.2. Les agents d'interface ... 38
4.3. Les agents mobiles ... 38
4.4. Les agents d'information ... 39
4.5. Les agents logiciels réactifs ... 39
4.6. Les agents hybrides ... 40
5. SYSTÈME MULTI-AGENTS ... 40
5.1. Définition ... 40
5.2. Utilité des systèmes multi agents ... 41
5.3. L’interaction ... 42
5.3.1. Composantes des interactions ... 43
5.3.1.1. Compatibilité des buts ... 43
5.3.1.2. Disponibilité des ressources ... 43
5.3.1.3. Capacités des agents par rapport aux tâches ... 43
5.4. La coopération... 44
5.4.1. Les méthodes de coopération ... 44
5.4.1.1. Le regroupement et la multiplication ... 44
5.4.1.2. La spécialisation ... 44
5.4.1.3. La collaboration par partage de tâches et de ressources ... 45
5.4.1.4. La coordination d’actions ... 45
5.4.1.5. La résolution de conflit par arbitrage et négociation ... 45
5.5. Communication dans les SMA ... 46
5.5.1. Communication par partage d’information ... 46
5.5.2. Communication par envoi de message ... 47
5.5.3. Les actes de langage ... 48
5.5.4. Les conversations ... 48
5.5.5. Langage de Communication Agent (LCA) ... 49
5.5.6. KQML ... 49
6. DOMAINES D’APPLICATION DES AGENTS ... 50
7. CONCLUSION ... 51
CHAPITRE 3 : ... 52
CONCEPTION SMA D’UN ATELIER ... 52
DE GENIE LOGICIEL ... 52
2. CHOIX DU RUP ... 53
3. PRÉSENTATION DU RUP(RATIONAL UNIFIED PROCESS) ... 53
3.1. Modèle d'un processus RUP ... 53
3.1.1. Les rôles ... 54
3.1.2. Les activités ... 54
3.1.3. Les artefacts (Work products) ... 54
3.1.4. Les workflows ... 55
3.1.5. Les disciplines ... 55
3.1.6 . Des éléments additionnels du processus ... 56
3.2. Le cycle de vie du RUP ... 56
4. L’ASSISTANCE AU PROCESSUS LOGICIEL ... 57
5. L’APPROCHE PROPOSEE... 58
5.1. L'identification de buts et le diagramme d’hiérarchie de buts ... 59
5.2. Les cas d’utilisation ... 60
5.3. Le diagramme de séquence ... 61
5.4. Les rôles du système ... 62
5.5. Le modèle d’ontologie ... 64
5.5.1. SPEM ... 66
5.5.1.1. Le méta modèle SPEM ... 66
5.5.1.2. SPEM comme profil UML ... 66
5.5.2. Ontologie de domaine ... 67
5.5.2.1. Les concepts ... 67
5.5.2.2. Relation entre concepts et diagramme des relations binaires ... 70
5.5.3. Ontologie de tâches ... 71
5.5.3.1. Conceptualisation... 71
5.5.3.1.1. L’expression de besoins ... 71
a. Groupes d’activités (Workflow details) ... 71
b. Activités... 72 5.5.3.1.2. L’analyse et la conception ... 73 a. Groupes d’activités... 73 b. Activités... 74 5.5.3.1.3. L’implémentation ... 75 a. Groupe d’activités ... 75 b. Activités... 75 5.5.3.2. Formalisation ... 76
5.5.3.3. Représentation des relations entre concepts ... 77
5.5.3.4. La relation Rôle-Activité-Artefact ... 79
5.6. Les agents du système ... 81
5.7. Les classes d’agents ... 82
5.8. Le diagramme de classes ... 82
5.9. Structure Interne des agents ... 83
5.9.1. L’agent Superviseur ... 83
a. Le module de connaissance ... 84
b. Le module de raisonnement ... 84
c. Le module d’action ... 84
5.9.2. Les agents_Rôle ... 86
a. Une base de connaissance ... 86
b. Un module raisonnement ... 86
c. Un module Action ... 87
5.9.3. Les agents Activité... 87
a. Un module connaissance ... 87
b. Un module raisonnement ... 87
c. Un module Action ... 88
6. EXEMPLE D’UN OUTIL CASE UTILISANT LA METHODE OMCP ... 93
6.1. Le comportement de quelques agents du système ... 96
6.1.1. L’Agent Analyste Système ... 96
6.1.2. Le comportement de l’agent Spécificateur des cas d’utilisation ... 97
6.1.3. Le comportement de l’agent Analyste des cas d’utilisation ... 98
7. CONCLUSION ... 99
CHAPITRE 4 ... 100
DESCRIPTION DU FONCTIONNEMENT ... 100
DE L’OUTIL D’ASSISTANCE A LA MODELISATION ... 100
1. INTRODUCTION ... 100
2. L’ONTOLOGIE ... 100
3. QUELQUES SCÉNARIOS POSSIBLES DE FONCTIONNEMENT ... 102
a. Scénario de fonctionnement du système ... 102
b. Scénario de fonctionnement par demande de réalisation des artefacts ... 104
c. Scénario de fonctionnement par demande d’adoption d’un rôle ... 105
CONCLUSION GENERALE ET PERSPECTIVES ... 106
GLOSSAIRE ... 108
Liste des figures
Figure 1 : Modèle en V du cycle de vie ... 7
Figure 2 : Le modèle de la spirale de BOEHM [6] ... 8
Figure 3 : Le modèle itératif et incrémental ... 9
Figure 4 : Modèle d’architecture d’AGL (ECMA) [15] ... 12
Figure 5 : Intégration des outils CASE ... 17
Figure 6 : Structure de l’AGL Rational Rose [37] ... 20
Figure 7 : Caractérisation des agents ... 31
Figure 8 : Schéma d’un agent à réflexes simples ... 32
Figure 9 : Schéma d’un agent conservant une trace du monde ... 33
Figure 10 : Schéma d’un agent ayant des buts [65]. ... 34
Figure 11 : Schéma d’un agent basé sur l’utilité ... 35
Figure 12 : Diagramme d’une architecture BDI ... 35
Figure 13 : Architectures d’agents en couches [75]... 37
Figure 14 : Communication par partage d’information ... 47
Figure 15 : Communication par envoi de message ... 47
Figure 16 : La Boite Noire du RUP ... 54
Figure 17 : Exemples Rôle, activités, et artefact ... 55
Figure 18 : Le cycle de vie du RUP... 57
Figure 19 : Diagramme d’hiérarchie de buts ... 60
Figure 20 : Diagramme de cas d’utilisation ... 61
Figure 21 : Le diagramme de séquence ... 62
Figure 22 : Le diagramme de rôle de l’agent Superviseur ... 63
Figure 23 : Le diagramme de rôle de l’agent Rôle ... 63
Figure 24 : Le diagramme de rôle de l’agent Superviseur ... 63
Figure 25 : Le diagramme de rôle ... 64
Figure 26 : Les éléments essentiels du SPEM et leurs relations [102] ... 66
Figure 27 : Correspondance entre SPEM et les éléments du méta modèle d’UML [103] ... 67
Figure 28 : Diagramme des relations binaires ... 70
Figure 29 : Modèle de relation entre les tâches dans RUP ... 76
Figure 30 : Diagramme d’activités pour les groupes d’activités de l’expression de besoin ... 77
Figure 31 : Diagramme d’activités pour les groupes d’activités de l’implémentation ... 78
Figure 32 : La hiérarchie des classes d’agents... 82
Figure 33 : Diagramme de classes ... 83
Figure 34 : Structure interne de l’agent Superviseur ... 86
Figure 35 : Structure interne de l’agent Activité ... 88
Figure 36 : Interaction entre les agents rôle ... 88
Figure 37 : Architecture proposée ... 91
Figure 38 : Liste des artefacts [55] ... 93
Figure 39 : L’interaction entre les agents Rôle ... 94
Figure 40 : Structure interne de l’agent responsable de la méthode TrouverActeur dont l’agent Analyste Système est responsable ... 96
Figure 41 : Le comportement de l’agent TrouverActeur ... 97
Figure 42 : Le comportement de l’agent Spécificateur pour un cas d’utilisation ... 97
Figure 43 : Le comportement de l’agent Analyste de cas d’utilisation ... 98
Figure 44 : Une partie du code OWL de l’ontologie de domaine de RUP ... 101
Figure 45 : Une partie du code OWL de l’ontologie de tâche de RUP ... 102
Liste des tables
Tableau 1 : Tâches de développement dans la classification de Forte et McCully ... 14
Tableau 2 : Classes des outils CASE [28] ... 19
Tableau 3 : Comparaison de quelques outils CASE ... 23
Tableau 4 : Relation Rôle-Activité-Artefacts ... 81
Tableau 5 : Croyances, Objectifs et Plans de l’agent Superviseur ... 85
Tableau 6 : Croyances, Objectifs et Plans de chaque agent de type Rôle ... 87
Tableau 7 : Les agents rôle et activité de l’Analyse et la conception ... 91
Tableau 8 : La collaboration entre les agents rôle ... 95
Introduction générale
Alors que le matériel informatique a fait des progrès très rapides, le logiciel, l'autre ingrédient de l'informatique, traverse toujours une crise qui dure depuis la fin des années 60 du siècle passé. Cette crise peut se percevoir à travers des symptômes tels que : le coût de développement d'un logiciel qui est généralement très élevé avec un délai de livraison rarement respecté ; la qualité du produit livré ne satisfait pas souvent les besoins de l’utilisateur ; la maintenance du logiciel est difficile, coûteuse et souvent à l'origine de nouvelles erreurs …etc. La raison de fond de la crise du logiciel réside dans le fait qu'il est beaucoup plus difficile de créer des logiciels que le suggère notre intuition. Comme les solutions informatiques sont essentiellement constituées de composants immatériels on sous-estime facilement leur complexité. Déjà la taille des programmes montre que cette complexité est souvent bien réelle: un million de lignes pour un logiciel de commande et de navigation d'un avion moderne, le décuple pour une station orbitale.
Pour maîtriser la complexité des systèmes logiciels, il convient de procéder selon une démarche bien définie, de se baser sur des principes et méthodes, et d'utiliser des outils performants. Pour réaliser un produit, il faut suivre un procédé qui décrit la suite des actions et opérations à entreprendre pour le développement et la maintenance du logiciel. Les actions et opérations utilisent des méthodes, techniques et outils. Pour évaluer un procédé, ou un produit, on effectue des mesures. Un procédé répond donc aux questions: qui doit faire le travail? Que faut-il faire? Comment faut-il faire le travail? Quand faut-il le faire? Et à quel niveau de détail faut-il faire le travail? Il s'agit d'un processus variable (selon le type d'application) et complexe, composé de différentes phases interdépendantes. Afin de tenter de résoudre la crise du logiciel, ce processus a fait l'objet de différentes modélisations. Historiquement, le premier modèle de développement proposé est celui dit ``de la cascade'', au début des années 70. Ce modèle a été assez largement mis en œuvre, mais on s'est rapidement aperçu qu'il n'est pas toujours approprié. Sa vision simpliste du processus sous-estime le coût des retours en arrière dans le cycle de vie. Ainsi, plusieurs alternatives au modèle de la cascade ont été proposées, basées notamment sur le prototypage et l'assemblage de composants réutilisables.
A partir des années 90 à nos jours, les ateliers de génie logiciel (AGL) sont apparus comme un moyen plus efficace pour apporter une solution réelle à certains problèmes du génie logiciel et contribuent nettement à l'amélioration de la productivité et de la qualité du logiciel, notamment en faisant le suivi des différentes phases du processus logiciel et en offrant un cadre cohérent et uniforme de production.
Un AGL ou atelier CASE (Computer Aided Software Engineering) est un logiciel permettant lui-même de produire des logiciels de manière industrielle assistée par
logiciel et se base sur des méthodologies pour formaliser le processus logiciel et chacune des phases internes qui le composent. L’application des méthodologies de développement est donc nécessaire pour garantir la qualité des logiciels produits.
De nombreuses méthodologies ont été développées durant les deux dernières décennies, mais, les méthodologies les plus complètes présentent elles mêmes une complexité certaine due au nombre élevé d’artefacts exigés aux règles de la méthodologie et à leurs processus généralement compliqués à mettre en œuvre. Il ne fait plus de doute que le développeur a toujours besoin de plus d’assistance face à la complexité grandissante des problèmes à résoudre ou à celle des méthodologies de développement utilisées dans les différents projets.
Les ateliers CASE existant proposent une assistance à la façon de modéliser mais peu d’entre eux s’intéressent au déroulement des activités du processus. Ce déroulement est essentiellement guidé par une longue série de documents fournis par les auteurs de la méthodologie. Les développeurs ont donc besoin d’une assistance intelligente au processus logiciel qui consiste à lier les outils avec les connaissances pour leurs permettre de participer activement à la réalisation du logiciel. Les outils doivent se comporter comme des participants actifs au développement du logiciel, plus ou moins autonomes et peuvent prendre de l’initiative.
Pour répondre à cette problématique, nous allons introduire le concept d’agent où un AGL sera considérée comme un ensemble d’agents servant à guider le développeur. Ces agents ayant divers rôles, différentes connaissances et compétences. Ils ne travaillent pas de manière isolée ni séquentielle, et ont besoin de communiquer, de coordonner leurs actions et, de manière plus large, de coopérer pour mener à bien le développement de logiciels. Dans ce travail, nous proposons un système multi-agents qui assiste l’utilisateur pendant le développement de son logiciel en utilisant la méthodologie RUP connue par ses « best practices ». L’outil sera considéré comme un système multi agents, où les agents collaborent ensemble par communication pour atteindre l’objectif commun, qui est la réalisation du logiciel. Chaque agent a donc son objectif local et l’objectif global. La collaboration se fait selon le processus logiciel itératif RUP. Les agents utilisent la connaissance sur toutes les entités du logiciel (outils à invoquer, méthodes à appliquer,…etc) pour assister activement le développeur.
Pour atteindre notre objectif, nous avons besoin de décrire une base d’ontologies qui contient deux ontologies, de domaines et de tâches. Une ontologie de domaine, représente la description du domaine, c’est à dire les concepts clés de RUP utilisés par les agents du système. Et une ontologie de tâches qui décrit quoi réaliser et comment le réaliser. Elle décrit les tâches du processus générique RUP, et leur enchaînement logique suivant le processus RUP.
Les agents vont simuler le travail d’un AGL, ils disposent chacun des règles et des connaissances qui vont aider l’agent à assister intelligemment le développeur. C'est-à-dire, guider le développeur, lui donner des recommandations, et même prendre des initiatives. Ainsi, les agents interagissent entre eux en collaborant par communication suivant le processus afin de réaliser la modélisation de logiciel.
Plan de Travail
Ce mémoire est composé en quatre chapitres, les deux premiers chapitres fixent le contexte de notre travail et les deux derniers constituent la proposition et quelques scénarios de fonctionnement de l’approche proposée. Nous les détaillerons comme suit :
Chapitre 1 : Présente quelques concepts de base liés au génie logiciel, aux modèles de processus logiciel et aux ateliers de génie logiciel, en citant l’état de l’art de quelques approches de développement des ateliers de génie logiciel et l’assistance au processus logiciel. Ensuite, une analyse de l’état de l’art est faite, et elle a permis d’introduire la problématique et de motiver la contribution.
Chapitre 2 : Est consacré à l’étude des systèmes multi agents, en mettant l’accent sur le concept d’agent et ses mécanismes essentiels. Les cinq problématiques des agents : L’interaction, la coopération, la communication, la négociation et la coordination sont discutés, ainsi que quelques domaines d’application.
Chapitre 3 : Dans ce chapitre, nous avons proposé une solution multi-agents à l’assistance à la modélisation. Nous avons commencé par introduire une présentation brève de RUP. Nous donnons ensuite une analyse du problème à résoudre en suivant la méthodologie MASE qui servira à définir une conception de la solution. La conception d’une ontologie de domaine était nécessaire pour définir les concepts de RUP et les relations entre eux et une ontologie de tâches pour définir les tâches et les liens entre eux et ainsi définir un vocabulaire commun entre les agents. L’analyse est terminée par donner une architecture finale du système.
Chapitre 4 : Afin d’éclaircir l’idée du travail réalisé, quelques scénarios de réalisation sont décrites ainsi que le code OWL des deux ontologies de domaine et de tâche ont été donnés. Finalement, nous terminons le mémoire par un bilan du travail effectué et nous donnons quelques perspectives et les extensions possibles du travail proposé.
Chapitre 1
Les ateliers de génie logiciel
1.
Introduction
Au cours des trois dernières décennies, les outils d'ingénierie logicielle assistée par ordinateur ont émergé comme l'une des innovations les plus importantes dans le développement de logiciels pour gérer la complexité des projets de développement logiciel. L’efficacité de ces outils, généralement appelés outils « CASE », apparaît nettement dans l’augmentation de la vitesse avec laquelle le logiciel est développé, l'amélioration de la qualité du système développé [1] et la réduction des coûts de développement de logiciel. En plus, les outils CASE offrent aux développeurs du logiciel/système une plateforme uniforme pour présenter l’information et la connaissance d’une manière compacte pour faciliter la communication[2] [3] [4]. Les outils CASE sont donc apparus pour soulager les développeurs des activités d'ingénierie logicielle trop ordinaires en leur laissant plus de temps pour se concentrer sur les tâches non triviale, exigeant plus de perspicacité et de créativité.
En effet, les outils CASE aident activement à produire et maintenir des logiciels complexes. Ils appliquent des méthodologies de développement de logiciels pour garantir un minimum de qualité des logiciels produits. Pour répondre à ces recommandations, de nombreuses méthodologies ont été développées depuis les années 80 du siècle passé. Cependant, les méthodologies les plus complètes présentent elles mêmes une complexité certaine due au nombre élevé d’artefacts exigés, aux règles de la méthodologie et à leurs processus plutôt compliqués à mettre en œuvre. Il ne reste plus de doute que le développeur a besoin aujourd’hui de plus d’assistance qu’avant pour faire face à la complexité grandissante des problèmes à résoudre et des méthodologies de développement utilisées dans les différents projets.
Pour cette raison, nous commençons par introduire dans ce premier chapitre un état de l’art global concernant les ateliers CASE appelés aussi ateliers de génie logiciel (AGL) terminé par une analyse comparative entre quelques AGL existant dans la littérature, dans le but de donner une motivation à la problématique proposée.
2. Le génie logiciel
Le terme génie logiciel a été introduit à la fin des années 60. Depuis, cette discipline n’a pas cessé d’évoluer. Son objectif est de développer des outils et des méthodes de production assistée par ordinateur afin de garantir la qualité et la productivité des logiciels.
Le génie logiciel, définit par Patrick Jaulent [5], est l’ensemble des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et son suivi.
La discipline du génie logiciel (GL) représente un ensemble de méthodes, techniques et outils pour la production et la maintenance des systèmes d'information. En d'autres termes, le génie logiciel est l'art de spécifier, concevoir, réaliser et faire évoluer avec des moyens et dans des délais raisonnables; des programmes, des documentations et des procédures de qualité pour résoudre certains problèmes à l’aide d’un système informatique.
Le génie logiciel ne concerne pas seulement la réalisation de produits, mais surtout la façon la plus efficiente de les produire. Pour qu’un logiciel soit bon; il doit être, en plus de ses fonctionnalités requises : maintenable, fiable, efficace et doit offrir une interface utilisateur appropriée [6].
Et si le génie logiciel est l'art de produire de bons logiciels, il est nécessaire de fixer les critères de qualité d'un logiciel. On peut séparer ces qualités en deux catégories qui sont rapportées à son utilisation et à sa maintenance [7].
• Les qualités du logiciel pendant son utilisation qui sont : La fiabilité (correction et robustesse), l’adéquation aux besoins, l’ergonomie (simplicité, rapidité d'emploi, personnalisation), l’efficacité, la convivialité, le faible coût et respect des délais…etc.
• les qualités du logiciel lors de sa maintenance: un logiciel doit pouvoir être maintenu pour le corriger, l'améliorer, l'adapter aux changements de son environnement, ...etc. Pour cela, il doit être flexible (utilisation du paramétrage, de la généricité, de l'héritage), portable (éviter l'assembleur et les langages trop confidentiels), structuré (utilisation de modules ou de classes, de procédures ou de fonctions) avec une indépendance maximum entre les structures (utilisation de l'abstraction) et doit être, bien sûr, documenté.
Ces différentes qualités ne sont pas toujours compatibles ni même réalisables et il est nécessaire de trouver des compromis. Dans tous les cas, les objectifs de qualité doivent être définis pour chaque logiciel et la qualité du logiciel doit être contrôlée par rapport à ces objectifs.
3. Le processus logiciel
3.1. Le rôle du processus de développemen
t
Un processus de développement logiciel définit le qui, le quoi, le quand et le comment du développement de logiciels. L'importance des processus logiciels est directement liée à l'observation, communément acceptée, que la qualité du produit est un résultat de la qualité du processus [8]. Ainsi, le processus logiciel est intéressant dans le développement
- Chaque membre de l’équipe de développement comprend quel est son rôle dans le développement du produit.
- Les développeurs comprennent mieux leur participation dans le développement et leur contribution par rapport aux autres développeurs.
- Les dirigeants et responsables comprennent mieux l’avancement du travail de chacun grâce aux différents modèles produits.
- Le processus permet de mesurer lors de la phase de lancement les risques liés au projet et de mesurer à chaque itération les écarts entre ce qui est prévu et la réalité.
3.2. Les différentes activités du processus logiciel
La notion de cycle de vie de logiciel modélise l'enchaînement de différentes activités du processus technique de développement du logiciel [10].
Les étapes suivantes permettent de décrire, en général, le cycle de développement du logiciel : • Analyse des besoins (Expression des besoins du produit).
• Spécification globale (Conception préliminaire). • Conception architecturale et détaillée.
• Programmation (Implémentation ou phase de codage). • Gestion de Configuration et Intégration.
• Validation et Vérification. • Maintenance et Assistance.
Et le problème qui se pose ici est : comment rendre la réalisation de ces étapes plus facile? Comment assurer la cohérence entre les différentes activités ? La réponse à ces questions appartient au domaine des ateliers de génie logiciel.
3.3. Modèles de Cycle de vie
Tous les modèles de cycle de vie ne sont pas les mêmes, mais l'idée est toujours la même: le logiciel est développé en phases discrètes, chacune ayant un résultat défini et un critère de terminaison défini, et chaque phase est achevée avant que ne commence la suivante. Le modèle classique de cycle de vie comprend les phases suivantes: analyse, conception, implémentation, test, et éventuellement phase d'installation. D'autres noms sont parfois donnés à ces phases et un découpage plus fin est souvent utile.
Chaque phase a des entrées et des sorties, qui sont généralement des documents et parfois des produits. Toute sortie d'une phase servira d'entrée à une phase ultérieure, souvent celle qui suit immédiatement, mais pas toujours. Certaines activités déployées pendant une phase lui sont donc spécifiques et d'autres sont destinées à préparer les phases qui suivent.
3.3.1. Modèle en cascade
Dans ce modèle le principe est très simple. Chaque phase du modèle ne se termine que par la production de certains documents ou logiciels. Les résultats d’une phase sont obtenus sur la base des interactions entre ses étapes, ils sont soumis à une revue approfondie et on ne passe à la phase suivante que lorsqu'ils sont jugés satisfaisants. Le modèle original ne comportait pas la possibilité de retour en arrière. Celle-ci a été rajoutée ultérieurement sur la base qu'une étape ne remet en cause que l'étape précédente, cependant, il s’est avéré que ce retour reste insuffisant dans la pratique.
3.3.2. Modèle en V
Dérivé du modèle de la cascade, le modèle en V du cycle de développement (fig. 1) montre non seulement l'enchaînement des phases successives, mais aussi les relations logiques entre phases plus éloignées. Ce modèle décrit un enchaînement purement séquentiel des différentes activités, en mettant toutefois en évidence la correspondance entre activités amont (analyse, conception) et aval (intégration, validation).
Figure 1 : Modèle en V du cycle de vie
L'application stricte du modèle en phases prescrit qu'on complète entièrement une phase avant de passer à la suivante. Dans la pratique, il arrive cependant qu'au cours d'une phase on découvre des erreurs commises dans une phase antérieure ou même l'absence d'éléments essentiels qui auraient dû être fournis par une phase antérieure. Il peut donc être nécessaire de revenir sur une phase précédente. Si tel est le cas, il faut parcourir à nouveau toutes les phases à partir de la phase révisée pour répercuter partout les modifications.
3.3.3. Modèle en spirale
Proposé par B. Boehm en 1988 [6], ce modèle est beaucoup plus général que les précédents. Il met l'accent sur l'activité d'analyse des risques : chaque cycle de la spirale se déroule en quatre phases :
• Détermination, à partir des résultats des cycles précédents ou de l'analyse préliminaire des besoins, des objectifs du cycle avec les alternatives et les contraintes possibles pour atteindre ces objectifs.
• Analyse des risques, évaluation des alternatives avec proposition d’un maquettage éventuel.
• Développement et vérification de la solution retenue en utilisant un modèle classique (en Cascade ou en V).
• Revue des résultats et vérification du cycle suivant.
L'analyse préliminaire est affinée au cours des premiers cycles. Le modèle utilise des maquettes exploratoires pour guider la phase de conception du cycle suivant. Le dernier cycle se termine par un processus de développement classique.
Figure 2 : Le modèle de la spirale de BOEHM [6]
3.3.4. Modèle par incrément
Dans les modèles précédents un logiciel est décomposé en composants développés séparément et intégrés à la fin du processus.
Dans les modèles par incrément, un seul ensemble de composants est développé à la fois : des incréments viennent s'intégrer à un noyau de logiciel développé au préalable. Chaque incrément est développé selon l'un des modèles précédents.
• Chaque développement est moins complexe.
• les intégrations sont progressives.
• il est ainsi possible de livrer et de mettre en service chaque incrément.
• il permet un meilleur lissage du temps et de l'effort de développement grâce à la possibilité de recouvrement (parallélisation) des différentes phases.
Les risques de ce type de modèle sont les suivants :
• Remettre en cause les incréments précédents ou dans le cas pire, le noyau.
• Ne pas pouvoir intégrer de nouveaux incréments.
Les noyaux, les incréments ainsi que leurs interactions doivent donc être spécifiés globalement, au début du projet. Les incréments doivent être indépendants fonctionnellement et sur le plan du calendrier du développement, le plus que possible.
3.3.5. Modèle itératif et incrémental
Dans un cycle de vie itératif et incrémental, le système est développé en une série d’itérations jusqu’au système final.
Chaque itération englobe une ou plusieurs phases de processus : modélisation métier, besoins, analyse, conception, implémentation, tests et déploiement. Au début du cycle, les développeurs se gardent de croire que tous les besoins sont connus mais on s’attend à des changements à toutes les phases.
Ce type de cycle a pour objet d’atténuer les risques. Les risques techniques sont évalués et classés par priorité très tôt et sont revus à chaque itération de développement. Ils sont définis de sorte que le développement réussi d’une itération élimine les risques qui lui étaient attachés (voir figure 3). Les versions sont planifiées pour assurer le traitement prioritaire des risques les plus importants. Ceux-ci sont ainsi identifiés et traités précocement, ce qui se traduit par un coût moindre [11].
4. Nécessité d’un environnement de production de logiciel
L’objectif de cet environnement est de définir un cadre de production dans lequel le logiciel ne serait plus conçu de façon artisanale mais bien de manière industrielle. La fabrication du logiciel doit être de plus en plus automatisée ainsi que de nombreux outils d’aide à la réalisation d’une tâche particulière du cycle de vie du logiciel ou spécifique à un domaine existant, tels que les outils d’aide à l’analyse, à la conception …etc. En plus, d’autres outils non liés spécifiquement à une phase de projet, comme les outils de gestion de projet ou d’aide à la documentation et à la validation, doivent être aussi automatisés.
5. Ateliers de Génie Logiciel ou Outils CASE :
5.1. L'origine de “CASE”
Le terme CASE « Computer Aided Software Engineering » a été d'abord appliqué à des outils qui fournissent un support pour les phases d’analyse et de conception du cycle de développement logiciel et la plupart des premiers outils étaient destinés à automatiser les méthodes structurées qui étaient disponibles.
La vision actuelle de CASE est celui d'un ensemble d'outils interdépendants qui prennent en charge tous les aspects du processus de développement logiciel. Elle inclue des outils qui prennent en charge des phases spécifiques du cycle de vie telles que les outils d’analyse et de conception, outils de génération de code, outils de test et les outils qui fournissent des fonctionnalités durant le cycle de vie tels que les outils de gestion de projet, de gestion de configuration et de documentation. [12]
5.2. Définitions
Le terme Atelier de Génie Logiciel (AGL) ou atelier CASE (Computer Aided Software Engineering) a été introduit au cours des années 80, pour désigner un logiciel aidant à la réalisation de logiciels. Il s'agit donc d'un système utilisé pour le développement logiciel
assisté par ordinateur. Un AGL intègre des outils adaptés aux différentes phases de la production d'un logiciel et facilite la communication et la coordination entre ces différentes phases. Il est basé sur des méthodologies qui formalisent le processus logiciel et chacune des phases internes qui le composent. Donc, Un rôle important d'un AGL dans le développement de logiciels est de servir comme un compagnon de méthodologie en fournissant un support à la méthodologie.
Une autre définition donnée par R. J. Noran [13] et qui fait ressortir l’aspect modélisation est : “Un AGL est un ensemble intégré d’outils qui permet aux développeurs de logiciel de
documenter et modéliser un système d’information dès la spécification initiale des besoins jusqu’au projet et son implantation; en passant par l’application de tests de cohérence, complétude et conformité aux spécifications proposées”.
Il faut noter ici que les AGLs sont seulement des aides et ne permettent pas de donner une solution totale à touts les problèmes de développement du logiciel. Ils sont des outils de gestion pour le développement de logiciel [14]. Un apport essentiel de l’AGL est de permettre de documenter automatiquement un logiciel et maintenir en permanence cette documentation à jour tout au long de sa conception.
5.3. Objectifs et Avantages des ateliers CASE
Le développement des logiciels complexes fiables et efficaces demande l’effort et la collaboration de beaucoup de gens spécialistes et peut prendre des années pour l’accomplir. Des petites erreurs dans la logique des programmes peuvent avoir des conséquences énormes pour le développeur. Et ainsi les outils CASE ont été développés dans le but d'aider les développeurs dans la production de systèmes logiciels et de produits de haute qualité.
L’objectif principal des AGL est l’automatisation maximale de tout le processus ou d’une partie du processus de développement du logiciel. Cet objectif, limité par la réalité du terrain, demande d’impliquer une assistance aux différentes phases du cycle de vie du logiciel.
Les outils CASE constituent un moyen indispensable pour résoudre les problèmes du développement d'application et de l’entretien des logiciels. Ils changent de manière significative le temps pris par chaque phase et la distribution du coût dans le cycle de vie de logiciel. Les concepteurs du logiciel s’intéressent plus sur l'analyse et la conception. Une grande partie du code peut être générée automatiquement avec le développement des spécifications détaillées. Ces améliorations rendues possibles par l'utilisation des outils CASE montrent des réductions importantes et très bénéfiques en coûts de développement et de maintenance.
La puissance des outils CASE se situe dans leur répertoire central qui contient des descriptions de tous les composants centraux du système. Ces descriptions sont employées à toutes les étapes du cycle : la création des concepts d'entrée-sortie, la génération automatique de code …etc. Les tâches suivantes continuent à s'ajouter pour construire ce répertoire de sorte que dans la conclusion du projet il contient une description complète du système entier. C'est un dispositif puissant qui n'était pas faisable avant l'introduction des outils CASE.
En résumé, les outils CASE servent pour :
1 - Améliorer la qualité du processus en: _ Augmentant la productivité des équipes. _ Favorisant la standardisation de la production. _ Accroissant la prédictibilité des développements. _ Améliorant la visibilité des projets.
_ Aidant à appliquer les plans et les normes d’assurance qualité,
_ Permettant de mener à bien des projets complexes et importants en volume et en taille d’équipe,
_ Améliorant le travail coopératif,
_ Obtenant et mesurant un niveau de qualité défini. Fondamentalement, les outils CASE:
• aident le développeur à créer les principaux modèles d'un système d’information.
• vérifient que les modèles sont complets et compatibles avec d'autres modèles.
• permettent de générer le code à partir des modèles.
5.4.
Constituants d'un atelier de génie logiciel
Un atelier efficace doit être constitué d’un ensemble cohérent de méthodes, une base de données (Repository) qui gère l’ensemble des objets crée au cours de chacune des étapes de production, un ensemble d’outils nécessaire au développement du logiciel et un ensemble intégré de mécanismes d’interface entre chacune des phases du cycle de vie. Cependant, le doublet (méthodes, outils) est considéré comme l'ensemble des ressources nécessaires à tout AGL. La figure 4 présente le modèle standard d’un AGL proposé par ECMA.
Figure 4 : Modèle d’architecture d’AGL (ECMA)[15]
5.4.1. Le référentiel
Le cœur d'un système CASE bien conçu est un référentiel (Repository,dépôt)[16], qui est utilisé comme une base de connaissances pour stocker des informations sur l'organisation, sa structure, les modèles d'entreprise, les fonctions, les procédures, les modèles de données …etc. Le sens représenté par leurs fenêtres de détail et de diagrammes est stocké dans le référentiel. Le référentiel accumule constamment les informations relatives à la planification, l'analyse, la conception, la construction et la maintenance des systèmes.
Il stocke des informations sur le système, dont des modèles des descriptions et de références servant à lier les modèles ensembles. L'outil CASE permet de vérifier les modèles pour assurer qu'ils sont complets et suivent les bonnes règles de conceptualisation. Il peut aussi confronter un modèle à un autre pour attester leur cohérence. Si l'on pense à tout le temps qu'un analyste consacre à créer, vérifier et réviser des modèles, puis à certifier qu'ils s'emboîtent tous, l'utilité des outils CASE est indéniable. Si l'information est stockée dans un référentiel, l'équipe de développement peut l'utiliser de diverses manières. Chaque fois qu'un membre de l'équipe ajoute de l'information, elle devient disponible pour tous.
5.4.2. Les méthodes
Un AGL est basé sur des méthodologies pour formaliser le processus logiciel et chacune des phases qui le composent. Il peut supporter des méthodes structurées, des méthodologies orientées objet ou les deux. La recherche actuelle sur l'évaluation des outils
CASE se concentre plus sur les méthodes orientées objet. On distingue quatre types de méthodes:
• Méthodes de planification stratégique du développement des systèmes applicatifs ;
• Méthodes de développement ; c’est à dire de spécification, conception, réalisation, installation et maintenance des systèmes logiciels ;
• Méthodes de conduite de projet ;
• Méthodes d’assurance de la qualité.
5.4.3. Les outils
Un AGL intègre des outils adaptés aux différentes phases de la production d'un logiciel, et facilite la communication et la coordination entre ces différentes phases. Ce sont des différents outils d'aide au développement de logiciels.
Forte, G. et McCully, K. (1991) [17] proposent une taxonomie d’outils CASE à deux niveaux. Le premier classifie les outils CASE par domaines comme les domaines d'application visés par l'outil, les tâches soutenues dans la méthode et les notations de cycle de vie de développement, la plateforme de matériel, les logiciels d'exploitation, les bases de données et les sous-ensembles de traitement transactionnel soutenus par l'outil …etc. Le deuxième niveau spécifie les attributs de chaque domaine en deux classes (Outils horizontaux et Outils verticaux) suivant les tâches de développement de la figure.
Outils horizontaux : interviennent durant la totalité du processus logiciel (Service pour l’ensemble du cycle de vie), exemples : Éditeurs de texte, Gestion de projet, Gestion du dictionnaire de données, Administration et droits d’accès, Gestion des configurations, Documentation, Service de communication.
Outils verticaux : Ces différents outils interviennent lors d'une ou plusieurs phases du cycle de vie du logiciel : Spécification, Conception, Génération de code, IDE,
Compilateurs, Génération d'interfaces homme-machine, Génération de tests, Validation, Prototypage, Maintenance.
Le tableau 2 suivant présente la classification de Forte et McCully.
Tableau 1 : Tâches de développement dans la classification de Forte et McCully
5.5. Intégration des outils CASE
L'objectif de l'intégration (Figure 5) est de faire une collection d’outils qui fonctionne comme un seul outil avec les caractéristiques : Une interface utilisateur commune assurant une transition sans heurt entre les outils ; transfert sémantique de données de sorte que les données produites par un outil sont utilisables par un autre outil ; navigation simple entre les outils avec une exécution d’outil contrôlée de façon uniforme et les fonctions, qui suivent un processus prédéfini, sont de sorte que la fonction d’un outil suit ou précède directement la fonction d’un autre outil. [18]
Le modèle de référence de l’ECMA (European Computer Manufacturers Association)
[15] pour les environnements assistés (CASE, Computer Assisted Environments) qui se veut un cadre conceptuel et fonctionnel pour décrire et comparer les systèmes, identifie huit dimensions pour l’intégration : la base d’objets, l’intégration par les données, les outils, la gestion des tâches, les messages ou communication entre les outils, l’interface
utilisateur, la sécurité, et l’administration et la configuration de la plateforme support de l’environnement.
Chaque dimension est analysée selon une perspective conceptuelle, un point de vue externe (vision de l’utilisateur) et une perspective interne (point de vue du système). Pour chaque dimension, le modèle définit des règles, des opérations, la variété de types de données requises, ainsi que les relations entre les dimensions.
En effet, il existe plusieurs modèles d’intégration, parmi elle le modèle conceptuel d’AGL proposé par Wasserman [19] qui propose les quatre dimensions essentielles suivantes :
5.5.1. Intégration par l’interface :
C’est la manière d’utiliser un AGL. L’objectif majeur de l’intégration par l’interface est d’améliorer les performances et l’efficacité d’utilisation d’un AGL par ses utilisateurs. L’intégration par l’interface est supportée par des systèmes de gestion de fenêtre.
On dit qu’un AGL est bien intégré par rapport à cet axe lorsqu’un utilisateur qui a déjà appris à utiliser un outil d’AGL dépense un minimum d’énergie pour apprendre à utiliser un autre outil. Les outils qui composent l’AGL doivent donc utiliser le même paradigme d’interaction.
5.5.2. Intégration par les données :
Concerne le contrôle de l’utilisation des données par les outils qui composent l’AGL. Les données d'un projet dans l'ensemble sont réparties sur les outils étant adoptés. L’intégration d’outils essai de concevoir un environnement de développement intégré qui offre l'accès uniforme aux données des différents outils et les maintient conformés.
Toute l’information manipulée par l’environnement doit être gérée comme un tout cohérent. Les mécanismes qui rendent possible l’intégration des données prennent en compte la représentation, la conversion et le stockage des données.
Par rapport à cet axe d’intégration, Thomas et Nedjmeh [20] ont identifié les propriétés d’intégration suivantes:
Inter-operabilité : Le but est de minimiser les conversions de données entre deux outils qui coopèrent.
Non-redondance : Le but est de stocker le minimum d’objets qui peuvent être dérivés de manière automatique ou de limiter le plus possible la duplication des données.
Cohérence : Pour expliquer ce critère, supposons que nous avons deux outils A et B manipulant respectivement les objets OA et OB liés sémantiquement. Un AGL satisfait ce critère, lorsque l’outil A informe des actions effectuées sur OA et des effets provoqués afin que l’outil B puisse appliquer correctement des contraintes sur OB.
Échange de données : On cherche à diminuer le travail nécessaire à la transformation des données échangées entre les outils, que celles ci soient persistantes ou non.
Synchronisation par les données : Lorsque les outils sont capables de s’échanger des informations à propos des modifications de valeurs effectuées sur des objets partagés. Dans le domaine de l’intégration par les données, PCTE+ [15] est considéré comme un standard d’intégration des données au niveau européen adopté par ECMA.
5.5.3. Intégration par le contrôle
Afin de supporter des combinaisons harmonieuses de fonctions, les outils composant un AGL doivent partager et échanger des services.
L’outil fournissant les services ne doit pas être directement concerné par le fait que d’autres outils utilisent ses services. Afin de rendre possible le partage de services entre les outils, un AGL doit être intégré par le contrôle, donc fournir des mécanismes pour permettre la communication entre les outils. En général, l’intégration par le contrôle est supportée par des gestionnaires de messages, qui fournissent essentiellement trois types de communication : outil - outil, outil - service et service - service.
Il y’a beaucoup des AGL qui sont basé sur l’intégration de contrôle, le premier parmi eux est le système SoftBench [21] qui est une version commerciale et révisée de l’AGL nommé FIELD [22] considéré comme un des premiers AGL basé sur l’intégration par le contrôle. FIELD est bâti sur un serveur de communication, qui permet le partage d’informations par des échanges de messages. Dans le but d’améliorer le processus de contrôle, FOREST [23]
a perfectionné le serveur de messages de FIELD en y introduisant un mécanisme basé sur des règles de sélection. L’utilisation de telles règles rend possible la description du décodage des messages échangés entre les outils.
Le mécanisme de déclenchement (“trigger”) a été également utilisé pour contrôler le partage et l’échange des services des outils dans un AGL, comme par exemple, les AGL : Adèle 2 [24] et Alf [25]. D’autres systèmes, comme par exemple Oikos [26], utilisent la technique dite des tableaux noirs (“blackboard”) dérivé du domaine de l’intelligence artificielle pour contrôler l’échange de messages entre les outils.
Une autre stratégie qui a été utilisé est celle de wrapping, elle a été utilisée par Valetto et Kaiser [27] pour l’incorporation des outils CASE dans un environnement centré processus, nommé Oz.
5.5.4. L’intégration des procédés
C’est la possibilité de modéliser, à priori, la façon dont devrait se dérouler un développement et de contrôler l’exécution du modèle. Cette dimension d'intégration mesure le degré auquel les outils participent dans le processus de logiciel global et commun.
Par ailleurs, il est à noter que ces dimensions ne sont pas isolées l’une de l’autre. L’intégration par le contrôle peut nécessiter des services de la dimension donnée dans la mesure où, par exemple, la structure d’un message reçu par un outil ne se conforme pas à celle admise par l’outil. D’autre part, les mécanismes associés à l’intégration des procédés font recours à la fois à la dimension contrôle (par exemple, pour activer simplement un outil) et à la dimension données.
Figure 5 : Intégration des outils CASE
5.6. Les différents types d'AGL
Les AGL peuvent être classés selon plusieurs aspects tels que :
• La richesse du support : ensemble d'outils, outils intégrés, aide à la démarche.
• Le type de problèmes : logiciels embarqués, temps réel, "business applications", applications métiers …
• Gestion des ressources du projet : les considérations managériales des ressources mises en œuvre dans le projet sont elles prises en compte? (Planification, ordonnancement, …).
• Phase du cycle de développement prises en compte: conception et/ou développement.
Nous citerons ici les classifications les plus connues.
5.6.1. Outils CASE à base de l’étendue de leur support
Alfonso Fuggetta [28] classifie les produits CASE (Table 2) suivant l’étendue de leur support. Ils partitionnent les outils CASE en trois catégories : Outils, Ateliers (Workbenches) et Environnements.
La première catégorie supporte des tâches spécifiques dans le processus de développement du logiciel.
La deuxième catégorie «Workbenches » supporte une ou plusieurs activités par application. Cette catégorie est partitionnée en huit classes de Workbenches qui sont :
1. La planification et la modélisation du métier 2. L’analyse et la conception
3. Le développement de l’interface utilisateur 4. La programmation
5. La vérification et la validation
6. La maintenance et l’ingénierie inversée (reverse engineering) 7. La gestion de configuration
8. La gestion de projet
Tableau 2 : Classes des outils CASE [28]
La troisième catégorie, Environments, supporte tout ou au moins une partie substantielle du processus du logiciel avec une collection d'outils et des Workbenches. Cette catégorie est divisée en cinq classes : les Toolkits, les environnements centrés-Langage, les environnements intégrés, les environnements de quatrième génération et les environnements centrés-Processus.
Les outils peuvent être donc des produits autonomes ou des composants des ateliers et des environnements.
5.6.2. Outils CASE à base de cycle de vie
Cette dimension permet de classer les outils CASE sur la base des activités qu'elles prennent en charge dans le cycle de vie des systèmes d'informations. Ils peuvent être classés comme outils CASE Upper ou Lower.
5.6.2.1. Outils CASE orientés conception (Upper CASE Tools)
Ces ateliers visent surtout l’assistance des phases initiales du processus de développement de logiciel. Ils intègrent généralement : Des outils pour l'édition de diagrammes (avec vérification syntaxique), des dictionnaires de données, des outils pour l'édition de rapports, des générateurs de (squelettes de) code, des outils pour le prototypage,... Ils supportent les langages de diagrammes traditionnels comme Diagrammes ER, Diagrammes de flots de données, Cartes structurées, Arbres de décision, Tables de décision, …etc. Ils sont fortement basé sur des paradigmes (Orienté Objet), des méthodes de conception et les formalismes associés (ex : RUP/UML, Merise/E-R, ...), et proposent des outils d'éditions graphiques de ces formalismes. Ils proposent aussi une assistance pour la génération de documentation. Ils peuvent proposer un outil de prototypage (génération automatique partielle de code) et éventuellement de reverse
engineering (création de représentations graphique dans un formalisme donné à partir de code source existant). Voici quelques AGL Orientés Conception :
• PowerDesigner [30] de Sybase [31], basés sur Merise et UML (spécialisé dans le développement de système d’information).
• Oracle Designer [32] d'Oracle Corporation.
• Rational Suite AnalystStudio [33], Rational Rose [34] (Présenté dans la figure 6), basés sur UML et supporte la méthodologie Rational Rose Unified Process [35].
• Objecteering [36] de SoftTeam, basé sur UML.
Figure 6 : Structure de l’AGL Rational Rose [37]
5.6.2.2. Outils CASE orientés réalisation (Lower CASE Tools)
Ceux sont les outils qui se concentrent plus sur les dernières activités de cycle de vie du logiciel et donc prendre en charge des activités telles que la conception physique, débogage, construction, tests, intégration de composants logiciels, maintenance, les activités de réingénierie et de reverse engineering. On peut les classifier selon le niveau d'assistance en:
• Outils de développement : éditeur, compilateur, debugger, profiler, gestion de version, multi-utilisateurs.
• Environnements de Développement Intégré : idem mais regroupés au sein d'une seule interface et intégrés entre eux. Ex : Turbo C++.
• Environnement de Développement Rapide : idem avec facilité d'automatisation de certaines tâches de programmation (e.g. interfaces graphiques). Ex : Visual x,
JBuilder, Sun One, ...
• Atelier de Génie Logiciel : idem avec support étendu aux autres phases du cycle de développement du logiciel (spécification, conception, déploiement …). Ex:
WinDev
Parmi les AGL Orientés Réalisation on peut citer :
- Windev [38] de PCSoft qui est un atelier de génie logiciel édité par la société française PC SOFT et conçu pour développer rapidement des applications, principalement orientées
données. C’est un outil RAD plus avancé car il permet à partir d'une analyse Merise ou UML de produire un applicatif final et opérationnel. WinDev peut générer des applications en Java le long avec des applications standard ou des applications pour
Plateforme de .NET. Il supporte le paradigme procédural aussi bien que le paradigme de programmation orientée objet.
- PowerBuilder [39] de Sybase (PowerSoft) utilise une approche orienté objet et conçu pour les applications orientées données.
- Oracle Developer [40] de Oracle Corporation conçu pour les applications orientées données.
- SafeBuild [41] de TNI-Valiosys, basé sur UML destiné au développement d’applications
temps-réel.
- Rational Suite Development Studio [42] de Rational Software, basé sur UML et aux applications OO.
6. Comparaison de quelques AGL existant 6.1. ArgoUml
ArgoUML [43] est un projet Open Source fondé par Jason Robbins à l’Université de Californie en Irvinie. ArgoUML offre un guide dans le workflow d’un processus qui n’a pas encore été défini ou plutôt qui manque de standard. Il s’apparente également à un outil CASE UML avec une surcouche assistance essentiellement axée sur les critiques dans
la manière de modéliser. Il offre les critiques de conception (Design Critics), inclue étroitement l’assistance intelligente intégrée qui apporte sur les erreurs de conception, incomplètes fournies de la conception, ou de l'incompatibilité de l'interface. En outre, ils sont ciblés pour suggérer d'autres conceptions ; par exemple en raison de problèmes dans la génération du code à partir de la conception ; ou offrir des conseils heuristiques ; par exemple un collègue qui a signalé un problème. Il vise à long terme une assistance complète au développeur pendant le processus de développement.
Poseidon for UML reprend et étend les concepts de ArgoUML, c’est la version commerciale d’ArgoUML.
6.2. IBM Rational XDE
IBM Rational XDE [44] est une famille de produits Rational Rose, qui fournit l’essentiel de la modélisation UML dont la plupart de ses produits offre une assistance au processus RUP. Rose XDE Modeler et Rose Data Modeler par exemple ne supportent pas une configuration RUP. Rose XDE Modeler offre des capacités spéciales pour assister la modélisation. En outre, Rational PurifyPlus, Rational Rose XDE Developer Plus, offrent un ensemble d'outils d'analyse d'exécution qui détectent les erreurs de mémoire, mettre en évidence les performances des applications goulot et identifient le code non testé. Ces fonctionnalités permettent de trouver des problèmes dans le code et de les corriger avant leur surface dans l'environnement du client.
6.3. Visible Analyst
Visible Analyst [45] est un AGL développé par Visible. Il supporte deux méthodes, Structurée et orientée objet. Il intègre les stratégies de la planification, modélisation des
