Soutenance mémoire
Modèles de description du processus de développement
MARVEL [9][10] est un exemple d’approche déclarative, fondée sur des règles de production avec chaînage avant et arrière. Les enchaînements sont décrits sous la forme de précondition, action, effets, la précondition pouvant porter sur les services (sur le résultat d’un service par exemple) ou sur les données (sur la modification de la valeur d’une donnée par exemple). Les règles sont de diverses catégories qui expriment chacune une certaine sémantique. MARVEL exploite cette sémantique pour augmenter la coopération entre les développeurs, en autorisant un plus haut degré de partage des données. Dans ARCADIA [71][114], une approche déclarative est également fournie au travers du langage APPL/A qui permet de spécifier des enchaînements de services au travers de règles de type ECA(9). La partie événement porte sur les modifications des données. APPL/A, qui est un sur−ensemble du langage ADA, permet également de décrire des enchaînements d’activités sous la forme d’un programme ADA. Le projet SPADE [8] adopte une approche impérative basée sur les réseaux de Pétri de haut niveau (10). Un langage (nommé SLANG) permet de spécifier comment les services sont enchaînés et quelles sont les données communiquées entre les services. Les transitions du réseau de Pétri permettent d’activer des services automatiquement ou manuellement et le marquage des places s’effectue en fonction des résultats des services activés. L’état d’avancement du processus de développement est donné par ce marquage. Le langage permet aussi d’exprimer certains aspects de gestion de projet, en associant des contraintes de temps aux transitions. Dans MELMAC [38], les réseaux de Pétri sont également utilisés mais ils servent à décrire l’enchaînement des activités et non pas l’enchaînement des services. La description d’une activité en termes des services qui la composent est réalisée sous la forme d’un programme. Enfin, on trouve des approches multi−paradigmes, combinant approche déclarative et impérative [24][63]. Par exemple dans [63], les réseaux de Pétri de haut niveau sont utilisés pour décrire les enchaînements d’activité, le détail des activités étant spécifié au niveau des transitions en termes de services et de règles de production. Ces règles ne sont pas globales comme dans MARVEL car leur activation est attachée aux transitions.Dans [24], les réseaux de Pétri sont également utilisés pour décrire les enchaînements d’activités. Le lien entre une activité et les services est exprimé par le concept d’espace de travail (WorkContext) dans lequel sont spécifiés quels sont les services que le développeur, en fonction de son rôle, est autorisé à activer et sur quelles données.
Intégration des données et du contrôle
Outre la gestion du stockage des données, l’intégration des données vise à permettre aux outils de partager des données, alors que l’intégration du contrôle a pour objet de permettre aux outils de partager des informations de coordination. Les outils ont−ils besoin des deux formes d’intégration ? Certains ont opté pour un environnement uniquement basé sur l’intégration des données, au travers d’une base de données commune. C’est le cas de l’AD/Cycle d’IBM. D’autres ont choisi les fonctions offertes par l’intégration du contrôle comme seul moyen de communication entre outils, ces derniers disposant de leur propre base de données [46]. La tendance actuelle semble toutefois préconiser une approche combinant intégration des données et du contrôle .Nous pensons également que les deux formes d’intégration sont nécessaires, car elles répondent à des besoins distincts. Le partage de données entre outils paraît indispensable dans un environnement de taille groupe, dans lequel les développeurs partagent fortement les données qu’ils produisent. Le partage d’informations de contrôle vient en complément du partage de données, car il permet aux outils d’agir de manière cohérente même si leurs actions n’ont aucun effet sur les données. C’est par exemple le cas pour la terminaison d’une session de travail : la fermeture du gestionnaire de la session provoque la fermeture de tous les outils qui s’exécutent dans la session. En résumé, l’intégration des données permet d’assurer une cohérence donnée−donnée, alors que l’intégration du contrôle permet d’assurer une cohérence outil−outil.
Intégration du processus de développement
La différence essentielle entre les fonctions fournies par l’intégration du processus de développement et celles fournies par l’intégration des données et du contrôle est que la première, de notre point de vue, doit manipuler des concepts tels que les rôles, les échéances, les activités de développement. Le concept d’activité de développement n’est néanmoins pas indépendant des données et des services. Au niveau le plus bas, il exprime une série d’actions portant sur les données et les services (déclenchements automatiques de services suivant l’état des données ou d’après les services précédemment activés). Nous pensons que cette dépendance ne remet pas en question l’utilité des fonctions fournies par les deux autres axes d’intégration. En effet, on veut pouvoir exprimer des automatisations indépendantes de tout processus de développement, permettant de maintenir la cohérence des données ou de coordonner des services. Aussi, l’intégration du processus doit permettre d’exprimer les liens entre les activités et les données et services en s’appuyant sur les fonctions fournies par ces deux autres axes (et non en fournissant ces fonctions). Un problème subsiste néanmoins : celui de fournir un moyen qui permette de distinguer, au niveau des données et des services, l’expression des automatisations qui relèvent de propriétés intrinsèques aux données et aux services, de celles qui relèvent du processus de développement.
L’évolution des composants actifs de l’environnement
L’évolution des composants actifs dénote :
a) l’évolution des outils actifs : des activations et désactivations d’outils peuvent prendre place à tout moment, au gré des développeurs,
b) l’évolution des coordinations actives (2): les coordinations actives sont celles qui sont susceptibles de se produire à l’instant courant. Elles évoluent non seulement par l’évolution des outils actifs, mais également par le fait que le comportement d’un outil actif vis−à−vis de ses coordinations est susceptible d’évoluer dynamiquement. Par exemple, les coordinations dans lesquelles un éditeur est susceptible d’intervenir durant son exécution peuvent changer lorsque celui−ci change de rôle (passe par exemple d’un rôle d’édition à un rôle de visualisation pour un metteur au point). Un compilateur peut, à certains moments, accepter de participer à des coordinations en offrant la méthode compiler comme réaction, et à d’autres moment ne pas accepter d’y participer en raison d’une surcharge de travail. Enfin, on peut vouloir permettre aux développeurs de configurer dynamiquement des automatisations du type (quand un programme est sauvé dans la base, compiler le programme). Cette configuration dynamique entraîne une évolution dynamique des coordinations actives.
Expression de l’ensemble des coordinations (C)
Les critères requis proviennent du besoin d’évolution des composants de l’environnement. Le modèle doit permettre d’exprimer les coordinations de manière explicite, en dehors des programmes exécutables des agents. Ceci facilite la compréhension des coordinations et leur maintenance. Il doit en outre permettre de modulariser l’expression des coordinations. Le grain d’évolution de l’environnement étant l’agent, nous pensons qu’une modularité prenant ce grain comme unité de décomposition et non la coordination, est adéquate. Cette modularité doit être telle que, lors de l’ajout (resp. du retrait) d’un agent A dans l’environnement, seule l’expression des coordinations de A soit à définir ou à modifier pour coordonner (resp. « dé−coordonner ») A avec les autres agents de l’environnement. L’évolution des coordinations actives agit également au niveau agent. En particulier, on peut considérer qu’un agent, durant son exécution, passe par différents états de coordination car son comportement vis−à−vis des coordinations dans lesquelles il est susceptible d’intervenir peut varier dynamiquement. Le modèle doit permettre de décrire explicitement ces différents états.
Les moyens qui permettent de désigner un événement local ou une réaction locale
Les critères requis proviennent de l’indépendance entre agents, de l’évolution des composants et de l’évolution des composants actifs. Les agents ayant été développés indépendamment les uns des autres, ils peuvent utiliser des noms d’événements (resp. de réactions) différents bien que sémantiquement équivalents. L’équivalence sémantique signifie ici que l’un peut remplacer l’autre une coordination. Si deux agents fournissent des événements ou des réactions sémantiquement équivalents, on doit pouvoir remplacer l’un par l’autre sans modifier les agents de l’environnement ni l’expression de leurs coordinations. De même, dynamiquement,un agent actif doit pouvoir remplacer un autre agent actif sémantiquement équivalent. De ce fait, il est utile que le modèle permette de désigner les événements et les réactions intervenant dans une coordination sans avoir à connaître leurs définitions locales (noms et paramètres), par exemple par des définitions globales qui représentent leur sémantique
|
Table des matières
Introduction
.1 Le contexte
.2 Le sujet
.3 Le cadre du travail
.4 L’organisation de la thèse
Chapitre I Environnements de développement intégrés
I.1 Environnements de développement intégrés
I.1.1 Environnements de développement
I.1.2 Objectifs des environnements de développement intégrés
I.1.3 Contraintes des environnements de développement intégrés
I.1.4 En résumé
I.2 Intégration des données
I.2.1 Objectifs
I.2.2 Problèmes
I.2.3 Approches
I.2.3.1 Approches basées sur un système de gestion de fichiers
I.2.3.2 Approches basées sur un modèle relationnel
I.2.3.3 Approches basées sur un modèle Entité−Relation−Attributs
I.2.3.4 Approches basées sur un modèle orienté−objet
I.2.4 Discussion
I.3 Intégration du contrôle
I.3.1 Objectifs
I.3.2 Problèmes
I.3.3 Approches
I.3.3.1 Qu’est ce qu’un Bus de messages ?
I.3.3.2 Field
I.3.3.3 Softbench
I.3.3.4 Koala
I.3.3.5 DEC FUSE EnCASE
I.3.4 Discussion
I.4 Intégration du processus de développement
I.4.1 Objectifs
I.4.2 Problèmes
I.4.3 Approches
I.4.3.1 Critères de comparaison
I.4.3.2 Modèles de description du processus de développement
I.4.4 Discussion
I.5 Discussion générale
Chapitre II Intégration du contrôle : position du problème
II.1 Définition d’une coordination
II.2 Caractérisation du contexte
II.3 Modèles de coordination
II.3.1 Fonction d’un modèle de coordination
II.3.2 Critères requis pour l’intégration du contrôle
II.3.2.1 Expression des ensembles des événements (E) et des réactions (R)
II.3.2.2 Expression de l’ensemble des coordinations (C)
II.3.2.3 Désignation des événements et réactions intervenant dans les coordinations
II.3.2.4 Ensembles des types (T) et des modes (M) de coordination
II.3.2.5 Récapitulatif
II.3.3 Comparaison de différents modèles de coordination
II.3.3.1 Modèle basé sur l’appel de méthode
II.3.3.2 Modèle basé sur l’événement
II.3.3.3 Modèle mixte
II.3.3.4 Conclusion
II.4 Interopérabilité des agents
II.4.1 Fonction d’un mécanisme d’interopérabilité
II.4.2 Fonctions requises pour l’intégration du contrôle
II.5 Conclusion
Chapitre III Proposition d’un modèle et d’un langage de description de l’intégration du contrôle
III.1 Introduction
III.1.1 Cadre de travail
III.1.2 Objectifs et principes adoptés pour l’intégration du contrôle
III.2 Description Indra de la coordination des outils
III.2.1 Description de l’interface de coordination d’un outil
III.2.2 Description des états de coordination d’un outil
III.2.2.1 Déclarations de variables dans un état de coordination
III.2.2.2 Définitions des coordinations dans un état de coordination
III.2.2.3 Types et modes de coordinations
III.2.3 Description de l’état d’activation d’un outil
III.2.4 Modèle d’exécution
III.2.4.1 Priorités
III.2.4.2 Synchronisation
III.2.4.3 Ordonnancement
III.2.4.4 Interblocages
III.3 Désignation des outils
III.3.1 Objectifs et principes
III.3.2 Définition du schéma d’organisation des outils
III.3.3 Désignation des outils
III.3.4 Instanciation du schéma d’une organisation
III.3.5 Destruction d’un schéma d’organisation instancié
III.3.6 Utilisation des relations
III.3.6.1 Création et destruction de relations
III.3.6.2 Transmission de relations
III.4 Conclusion
Chapitre IV Le langage Indra : une illustration par l’exemple
IV.1 Etat initial de l’environnement
IV.1.1 Définition de l’Arbre Schématisé
IV.1.2 Description des outils
IV.1.3 État de l’Arbre Instancié Effectif
IV.2 Le scénario
IV.3 Conclusion
Chapitre V Un environnement d’exécution pour le langage Indra
V.1 Architecture logicielle générale
V.1.1 Introduction
V.1.2 Hypothèses
V.1.3 Objectifs et principes
V.1.4 Architecture logicielle générale
V.2 Système support
V.2.1 Le modèle d’objets de Guide
V.2.2 Le modèle d’exécution de Guide
V.3 Fonctions de coordination fournies aux outils
V.4 Partie compilée
V.5 Machine d’exécution
V.5.1 Frontal de coordination
V.5.1.1 Fonctions offertes
V.5.1.2 Fonctionnement général
V.5.2 Service de communication
V.5.2.1 Fonctions offertes
V.5.2.2 Propriétés assurées
V.5.2.3 Architecture générale à objets
V.5.2.4 Communications entre les objets et gestion de la dynamicité des clients vis à vis de leurs acceptations
V.5.2.5 Transmission d’une coordination
V.5.2.6 Gestion des relations
V.5.2.7 Ordonnancement assuré
V.6 Conclusion
Chapitre VI Evaluation
VI.1 Etat des travaux
VI.2 Le langage Indra et son modèle
VI.2.1 Satisfaction des objectifs fixés
VI.2.2 Expérimentation
VI.2.2.1 Expression explicite et modulaire des coordinations ……… 118
VI.2.2.2 Expression explicite des coordinations et de leur évolution dynamique
VI.2.2.3 Désignation des outils
VI.3 L’environnement d’exécution du langage Indra
VI.3.1 Satisfaction des objectifs fixés
VI.3.2 Performances d’exécution
VI.3.2.1 Coordinations intra−session
VI.3.2.2 Coordinations inter−session
Conclusion
.1 Rappel du cadre et des objectifs du travail
.2 Travail réalisé
.3 Rappel des principes adoptés et des résultats obtenus
.3.1 Le modèle mis en œuvre par le langage Indra
.3.2 L’environnement d’exécution du langage Indra
.4 Les solutions existantes
.5 Perspectives
Télécharger le rapport complet
