ARTO : un modèle d'objet adaptable pour la qualité de...
130
N° d’ordre 02 ISAL 0069 Année 2002 Thèse ARTO : un modèle d’objet adaptable pour la qualité de service Présentée devant L’institut national des sciences appliquées de Lyon Pour obtenir Le grade de docteur Formation doctorale : Informatique et Systèmes Coopératifs pour l’Entreprise École doctorale : École doctorale Informatique et Information pour la Société Par José-Lino CONTRERAS (Ingénieur) Soutenue le 6 décembre 2002 devant la Commission d’examen Jury MM. Directeur Jean Louis SOURROUILLE, Professeur Rapporteur Charles ANDRE, Professeur Rapporteur Laurence DUCHIEN, Professeur Mario PALUDETTO, MC HDR 1
Transcript of ARTO : un modèle d'objet adaptable pour la qualité de...
N° d’ordre 02 ISAL 0069 Année 2002
Thèse
ARTO : un modèle d’objet adaptable pour la qualité de service
Présentée devant L’institut national des sciences appliquées de Lyon
Pour obtenir
Le grade de docteur
Formation doctorale : Informatique et Systèmes Coopératifs pour l’Entreprise École doctorale : École doctorale Informatique et Information pour la Société
Par
José-Lino CONTRERAS (Ingénieur)
Soutenue le 6 décembre 2002 devant la Commission d’examen
Jury MM.
Directeur Jean Louis SOURROUILLE, Professeur Rapporteur Charles ANDRE, Professeur Rapporteur Laurence DUCHIEN, Professeur Mario PALUDETTO, MC HDR
1
ARTO : un modèle d’objet adaptable pour la qualité de service
Résumé
Le contexte d’exécution des applications est devenu plus versatile et moins prédictible en raison de la complexité croissante des systèmes informatiques modernes (multiprocessus, systèmes distribués, etc.). Cette situation complique le développement et le fonctionnement des applications dans les domaines sensibles aux propriétés dynamiques des systèmes, tels que le temps réel et le multimédia. Une connaissance partielle du contexte d’exécution n'est pas suffisante pour la construction de ces applications, et il est de plus en plus difficile d’obtenir cette connaissance par la voie analytique. D’un autre coté, les approches heuristiques apportent des solutions non optimales et rendent inévitable l’incertitude sur le comportement des applications pour les aspects non fonctionnels tels que le temps et la précision des réponses.
Les objets ARTO réduisent l'effet des changements inattendus du contexte d’exécution en adaptant dynamiquement leur comportement. Ils décident comment agir en fonction de critères propres et du contexte afin de faire au mieux pour satisfaire les services demandés. Les contraintes temporelles sont traitées comme faisant partie des propriétés qui définissent la Qualité de Service et sont le principal critère de décision pour l'adaptation des objets ARTO. Des fautes temporelles peuvent intervenir, mais la solution est destinée à des systèmes temps réel tolérant des défaillances sporadiques. Mots-Clés: qualité de service – approche objet – adaptabilité – temps réel – architectures à méta niveaux ARTO : an adaptable object model for quality of service Abstract
Application execution contexts have became more versatile and less predictable due to the increasing complexity of modern computer systems (multi process, distributed systems, etc.). This situation makes more difficult the development and execution of applications affected by dynamic properties of systems, such as real time and multimedia. A partial knowledge of the execution context is not enough to build such applications and the required knowledge is more and more difficult to obtain by analytical approaches. On the other side, heuristics approaches give non optimal solutions and make uncertain non functional aspects such as timing and precision of replies. ARTO objects decrease the effect of unexpected execution context variations by dynamically adapting their behavior. They base their decisions on their own criteria and on execution context in order to satisfy the requested services. Time constraints are treated as part of the Quality of Service properties and are the main criteria for the object’s adaptation. As temporal faults may happen the solution is oriented to real time systems accepting sporadic faults. Keywords: quality of service – objet orientation – adaptability – real time – meta-level architectures
2
Remerciements
Je voudrais remercier premièrement à la France, un
pays que m’a donné l’opportunité de connaître et
vivre sous un concept de société humanitaire et
solidaire, un pays qui grâce à son peuple peut être
encore un phare pour une humanité qui tombe dans
l’obscurité. Deuxièmement, je voudrais remercier à
l’INSA de Lyon, au Département d’Informatique et au
laboratoire L3i, pour m’avoir accueilli pendant des
années dans un cadre humain chaleureux et amical.
Troisièmement je veux remercier à Jean-Louis pour
son soutien permanent sans lequel ce travail ne serait
pas arrivé au but.
Lyon, novembre 2002
3
1 INTRODUCTION........................................................................................................................................ 8
2 PROBLEME A RESOUDRE, BESOINS................................................................................................. 11
2.1 TRAITEMENT DES ASPECTS NON FONCTIONNELS....................................................................................... 11
2.2 PREDICTIBILITE ET CONTEXTE D'EXECUTION ............................................................................................ 13
2.3 LE PROBLEME A RESOUDRE....................................................................................................................... 14
2.3.1 Approche Statique ........................................................................................................................... 14 2.3.2 Approche Dynamique...................................................................................................................... 15
2.4 DOMAINE D'APPLICATION ENVISAGE ........................................................................................................ 16
2.5 BESOINS.................................................................................................................................................... 16
3 QOS ............................................................................................................................................................. 18
3.1 INTRODUCTION ......................................................................................................................................... 18
3.2 NOTION DE QOS ....................................................................................................................................... 18
3.3 PROPRIETES DE LA QOS............................................................................................................................ 19
3.4 CONCEPTS ET TERMINOLOGIE ................................................................................................................... 20
3.4.1 Le service dans la QoS. ................................................................................................................... 20 3.4.2 Caractéristiques de la QoS. ............................................................................................................ 20 3.4.3 Besoins de QoS et paramètres de QoS. ........................................................................................... 21 3.4.4 Contrats de QoS .............................................................................................................................. 21 3.4.5 Gestion de QoS et Politiques de gestion de QoS............................................................................. 21 3.4.6 Fonctions de Gestion de QoS et Mécanismes de QoS. .................................................................... 22 3.4.7 Catégories de QoS........................................................................................................................... 22
3.5 GESTION DE LA QOS................................................................................................................................. 22
3.5.1 Gestion Intrusive et non-Intrusive................................................................................................... 23 3.5.2 Couches de gestion de la QoS ......................................................................................................... 24 3.5.3 Phases ............................................................................................................................................. 25
3.6 EVALUATION/OPTIMISATION DE LA QOS.................................................................................................. 31
3.6.1 Fonctions d'utilité............................................................................................................................ 31 3.6.2 Critères de QoS............................................................................................................................... 32 3.6.3 Dimensions Multiples...................................................................................................................... 34 3.6.4 Optimisation de la QoS ................................................................................................................... 36 3.6.5 Optimisation hors ligne................................................................................................................... 36 3.6.6 Optimisation en ligne ...................................................................................................................... 37
4 SYSTEMES TEMPS REEL...................................................................................................................... 38
4.1 LE FACTEUR TEMPS................................................................................................................................... 38
4.2 LES CONTRAINTES TEMPORELLES ............................................................................................................. 39
4.3 LA VALEUR DU SERVICE EN FONCTION DU TEMPS ..................................................................................... 39
4.4 LA DATE D'ECHEANCE............................................................................................................................... 40
4.5 L'ORDONNANCEMENT............................................................................................................................... 40
4.6 APPROCHES STATIQUE ET DYNAMIQUE .................................................................................................... 40
4.7 TYPES D'ORDONNANCEMENT .................................................................................................................... 42
4
4.8 LE SUPPORT POUR LE TEMPS REEL ............................................................................................................ 42
TECHNOLOGIES DE BASE........................................................................................................................ 44
5 OBJET ACTIF ........................................................................................................................................... 44
5.1 OBJET ACTIF ET PROCESSUS ...................................................................................................................... 44
5.1.1 Objet Actif ....................................................................................................................................... 44 5.1.2 Envois de messages ......................................................................................................................... 45 5.1.3 Programmation des processus. ....................................................................................................... 46 5.1.4 Composants de l'objet actif ............................................................................................................. 47 5.1.5 Nombre de threads .......................................................................................................................... 49 5.1.6 Création des threads ....................................................................................................................... 49 5.1.7 Concurrence.................................................................................................................................... 50
5.2 CONTROLE DES OBJETS ACTIFS ................................................................................................................. 50
5.2.1 Contrôle de la concurrence............................................................................................................. 50 5.2.2 Contrôle intra-objet ........................................................................................................................ 51 5.2.3 Contrôle inter objet ......................................................................................................................... 51 5.2.4 Contraintes d’état............................................................................................................................ 51 5.2.5 Communication entre objets............................................................................................................ 52 5.2.6 Synchronisation des appels ............................................................................................................. 52
5.3 BENEFICE DU MODELE D’OBJET ACTIF ...................................................................................................... 53
5.4 MODELES D'OBJET ACTIF POUR LE TEMPS REEL. ...................................................................................... 54
5.4.1 ACCORD......................................................................................................................................... 54 5.4.1.1 L'état de l'objet ............................................................................................................................................ 56
5.4.1.2 Communication entre objets........................................................................................................................ 57
5.4.1.3 Contrôle de concurrence.............................................................................................................................. 57
5.4.1.4 Ordonnancement ......................................................................................................................................... 57
5.4.2 DRO ................................................................................................................................................ 58 5.4.2.1 Traitement de messages............................................................................................................................... 59
5.4.2.2 Communication entre objets........................................................................................................................ 59
5.4.2.3 Le protocole de communication .................................................................................................................. 60
5.4.2.4 Meilleur effort et souffrance minimale........................................................................................................ 60
5.4.2.5 Objets du Meta niveau................................................................................................................................. 61
5.4.3 ROOM et UML for Real-Time......................................................................................................... 62 5.4.3.1 Objets Actifs de ROOM.............................................................................................................................. 62
5.4.3.2 Communication en ROOM ......................................................................................................................... 62
5.4.3.3 Modèles ROOM .......................................................................................................................................... 63
5.4.3.4 Modélisation du comportement................................................................................................................... 64
6 ARCHITECTURES REFLECHIES A META NIVEAUX .................................................................... 67
6.1 ARCHITECTURES REFLECHIES................................................................................................................... 67
6.1.1 La réification................................................................................................................................... 68 6.1.2 Connexion causale .......................................................................................................................... 69 6.1.3 Types de réflexion ........................................................................................................................... 69
6.2 ARCHITECTURES A META NIVEAUX........................................................................................................... 70
6.3 ARCHITECTURES A META-NIVEAUX ORIENTEES OBJET.............................................................................. 70
6.4 REFLEXION ET ORIENTATION OBJET......................................................................................................... 71
6.4.1 Modèles de réflexion ....................................................................................................................... 73 6.4.2 Protocoles à méta-objet (Meta Objects Protocols, MOP) .............................................................. 75
5
6.5 EXEMPLES D'ARCHITECTURES REFLECHIES .............................................................................................. 75
6.5.1 Open C++....................................................................................................................................... 75 6.5.1.1 Systèmes distribués dans Open C++ : la Communauté d'Objets ................................................................. 77
6.5.2 ABCL/R ........................................................................................................................................... 78 6.5.3 ABCL/R2 ......................................................................................................................................... 80
7 ARCHITECTURE DE ARTO .................................................................................................................. 83
7.1 NIVEAU DE BASE : LES OBJETS .................................................................................................................. 83
7.2 NIVEAU META : LES META-OBJETS............................................................................................................ 83
7.3 RELATION OBJET - META-OBJET .............................................................................................................. 84
7.4 REIFICATION............................................................................................................................................. 84
7.5 REFLEXION ............................................................................................................................................... 85
7.6 MODELE D'EXECUTION ............................................................................................................................. 85
7.6.1 Les Objets de base........................................................................................................................... 86 7.6.2 Les méta-objets (MOs) .................................................................................................................... 86 7.6.3 L'objet Applicatif ............................................................................................................................. 87 7.6.4 Messages ......................................................................................................................................... 87 7.6.5 Les modes de l'application .............................................................................................................. 87
8 REALISATION.......................................................................................................................................... 89
8.1 NIVEAU DE LA GESTION ............................................................................................................................ 89
8.2 QOS GEREE PAR LES META-OBJETS .......................................................................................................... 89
8.2.1 Connaissances du MO..................................................................................................................... 90 8.2.1.1 Connaissances sur l'Objet............................................................................................................................ 90
8.2.1.2 Connaissance sur le contexte l’exécution .................................................................................................... 91
8.2.1.3 Informations propres ................................................................................................................................... 91
8.2.1.4 Informations collectives .............................................................................................................................. 91
8.3 CONTROLE DU COMPORTEMENT DE L'OBJET ............................................................................................. 91
8.3.1 Actions de gestion : sélection de message et de méthode................................................................ 92 8.4 CRITERE PRINCIPAL DE QOS ..................................................................................................................... 92
8.4.1 Contrainte temporelle ..................................................................................................................... 92 8.5 TRAITEMENT DES MESSAGES : DECISIONS A DEUX NIVEAUX..................................................................... 92
8.5.1 Messages ......................................................................................................................................... 93 8.5.1.1 Importance .................................................................................................................................................. 93
8.5.1.2 Paramètres ................................................................................................................................................... 94
8.5.1.3 Etapes d'un message .................................................................................................................................... 94
Traitement local ........................................................................................................................................... 96 8.5.2.1 Disponibilité des threads ............................................................................................................................. 97
8.5.2.2 Réservation de threads................................................................................................................................. 97
8.5.2.3 Ensemble des méthodes associé à un message ............................................................................................ 97
8.5.2.4 Traitement des messages urgents ................................................................................................................ 99
8.5.2.5 Validité du message .................................................................................................................................... 99
8.5.2.6 Compatibilité avec les méthodes en cours d’exécution ............................................................................... 99
8.5.2.7 Décision locale ............................................................................................................................................ 99
8.5.3 Traitement global .......................................................................................................................... 100
6
8.5.3.1 Optimisation de la QoS ............................................................................................................................. 101
8.5.3.2 Une solution par la voie heuristique .......................................................................................................... 101
8.5.3.3 Planification des exécutions ...................................................................................................................... 102
8.5.3.4 Ordonnancement EDF............................................................................................................................... 102
8.5.3.5 Ordonnancement sur la base des WCETs.................................................................................................. 102
8.5.3.6 Ordonnancement avec la méthode la plus rapide ...................................................................................... 102
8.5.3.7 En cas de surcharge : privilégier les messages les plus importants ........................................................... 102
8.5.3.8 Exécution de la méthode la plus longe possible ........................................................................................ 103
8.5.3.9 Allocation de la CPU................................................................................................................................. 105
8.6 CONTRATS .............................................................................................................................................. 105
8.6.1 Accords implicites ......................................................................................................................... 105 8.6.2 Négociations explicites.................................................................................................................. 106
8.6.2.1 Réception de messages.............................................................................................................................. 106
8.6.2.2 Messages garantis...................................................................................................................................... 106
8.6.2.3 Demande d'information ............................................................................................................................. 106
8.7 TECHNIQUES POUR L'ADAPTABILITE ....................................................................................................... 106
8.7.1 Traitement selon le mode .............................................................................................................. 106 8.7.2 Polymorphisme.............................................................................................................................. 107 8.7.3 Exécutions spéciales...................................................................................................................... 107
8.7.3.1 Task pair.................................................................................................................................................... 107
8.7.3.2 Exécution de type N/M.............................................................................................................................. 108
8.7.4 Autres mécanismes ........................................................................................................................ 109 8.7.4.1 Délégation ................................................................................................................................................. 109
8.7.4.2 Actions avant et après................................................................................................................................ 110
8.7.4.3 Réservation de temps de CPU ................................................................................................................... 110
9 PROCESSUS DE DEVELOPPEMENT................................................................................................. 111
9.1 VISION GENERALE DU PROCESSUS DE DEVELOPPEMENT ......................................................................... 111
9.2 MODELISATION AVEC UML.................................................................................................................... 112
10 RESULTATS............................................................................................................................................ 115
10.1 EFFET DU NOMBRE DE THREADS ............................................................................................................. 116
10.2 RESERVATION DE THREAD ...................................................................................................................... 117
10.3 EFFET DE LA POLITIQUE LOCALE............................................................................................................ 117
10.4 POLITIQUE LOCALE ET IMPORTANCE DES MESSAGES ............................................................................. 118
10.5 POLYMORPHISME.................................................................................................................................... 119
10.6 POLYMORPHISME ET POLITIQUE LOCALE ................................................................................................ 120
10.7 POLYMORPHISME ET IMPORTANCE DES MESSAGES ................................................................................. 121
11 CONCLUSIONS....................................................................................................................................... 122
12 BIBLIOGRAPHIE................................................................................................................................... 127
13 COMMUNICATIONS : .......................................................................................................................... 130
7
1 Introduction
La puissance et la complexité des systèmes informatiques ont augmenté notablement dans les
dernières années, que ce soit en termes de matériel ou de logiciel. Les systèmes d’exploitation
multiprocesseurs, les réseaux d’ordinateurs, les nouveaux outils informatiques, etc., ont modifié le
scénario dans lequel s'inscrivent les applications. En conséquence, les contextes dans lesquels les
applications s'exécutent sont devenus plus dynamiques, plus variables et moins prévisibles. Cette
situation importe peu si l'utilisateur se satisfait d'outils informatiques plus puissants et moins chers.
Cependant, elle complique fortement le développement et le fonctionnement des applications dans des
domaines tels que les systèmes temps réel et le multimédia, où les propriétés dynamiques des systèmes
jouent un rôle essentiel. Dans des applications de ce type, la connaissance et la prédiction du
comportement du système sont importantes sinon indispensables, comme dans le cas des systèmes
temps réel dur. De nombreux systèmes ne requièrent qu'une connaissance partielle du contexte
d'exécution pour que la construction d'applications soit faisable. Pour les autres, il est de plus en plus
difficile d'obtenir une connaissance suffisante par la voie analytique. D'un autre coté, les solutions
apportées par les approches heuristiques ne sont pas optimales et rendent inévitable l'incertitude sur le
comportement des applications pendant leur exécution. Il faut préciser que cette situation n'affecte pas
les aspects fonctionnels des applications, lesquels peuvent être assurés par des techniques et
mécanismes au niveau langage de programmation et système d'exploitation. Ces sont plutôt les aspects
non fonctionnels qui sont affectés par la dynamique des systèmes, comme par exemple le facteur
temps, la précision des réponses ou la périodicité des exécutions. Bien que les fonctionnalités des
applications soient assurées, leur qualité en termes non fonctionnels est difficile à préciser.
Ce travail propose une approche pour faire face à cette situation. D'une façon très générale,
l'idée principale est introduire des mécanismes d'adaptation dans les applications afin de flexibiliser
leur comportement et réduire ainsi les effets nocifs de variations imprévues dans leur contexte
d'exécution. En considérant que la prédiction totale des événements affectant le système n'est pas
possible, la solution n'est pas adaptée aux systèmes qui requièrent une certitude totale sur le
fonctionnement. Elle est plutôt orientée vers des systèmes qui tolèrent un certain degré de défaillance
sur des aspects non fonctionnels, et qui peuvent accepter des dégradations sporadiques de leurs
performances (en cas extrême, des arrêts et redémarrages) sans que leur intégrité soit affectée. C’est le
cas de systèmes tels que les systèmes multimédias, des systèmes de contrôle de train, d’ascenseur ou
d’une ligne de production qui peuvent s'arrêter sans risque vital (mais pas sans conséquences) à tout
moment. Ce n'est pas approprié, par exemple, pour un système de pilotage d’avion dont un arrêt de
fonctionnement en plein vol n'est pas envisageable!
Un domaine d’application particulier envisagé pour l’utilisation de cette approche est celui des
systèmes temps réel mous. Ils ont des besoins non fonctionnels liés aux temps et acceptent une
8
certaine flexibilité sur le respect des contraintes. L'idée est que les systèmes soient conçus pour
respecter les contraintes dans des situations normales. Mais dans des conditionnes inusuelles, telles
que surcharge ou défaillance, toutes les contraintes ne sont pas garanties. Cependant, le système
continuera à fonctionner dans un mode dégradé et les services les plus importants ou critiques
continueront à être satisfaits. En utilisant l'approche proposée, il est attendu une augmentation de la
sûreté de fonctionnement des systèmes car ils continueront à fonctionner même sous des conditions
défavorables et non prévues.
Pour le traitement des aspects temporels, l'approche choisie est de les considérer comme
faisant partie des critères de qualité de service (QoS) des applications. De façon générale, les objets
clients demandent la réalisation de services et expriment leurs besoins non fonctionnels en spécifiant
des contraintes de différentes natures parmi lesquelles figurent les contraintes temporelles. Ces besoins
sont traduits par des demandes de QoS aux objets serveurs. Plusieurs critères de QoS peuvent
apparaître dans l'expression des besoins des clients comme la précision ou qualité d'un résultat, mais le
critère temporel reste le principal. Les objets serveurs reçoivent des requêtes pour des services qu'ils
exécutent avec la meilleure QoS possible en fonction des possibilités déterminées par leur contexte
d'exécution.
Comme il est peu utile de fixer les niveaux de QoS avant exécution, l'approche proposée se
base sur une prise de décision dynamique pour gérer la QoS. En considérant leur état particulier et leur
contexte d’exécution au moment d'exécuter les requêtes, les serveurs décident de la manière de
répondre en termes de QoS. Pour augmenter la flexibilité et les possibilités d’une réponse appropriée,
les objets sont munis de plusieurs opérations fonctionnellement équivalentes pour rendre des services.
Ils choisissent celle qui satisfait au mieux la QoS demandée en fonction des circonstances actuelles.
De cette façon, les objets adaptent leur comportement selon la QoS demandée et le contexte
d’exécution.
Finalement, l'approche proposée débouche sur la définition d'un modèle d'objet autonome
adaptable. Un facteur important pour la conception de ce modèle a été la préservation de qualités
logicielles reconnues, ce qui s'est traduit par le respect des principes de l’approche objet. Pour
augmenter les propriétés comme la réutilisation, la portabilité et l'extensibilité, les aspects orthogonaux
de l'application (traitement séquentiel, contrôle de concurrence, directives d'implémentation, etc.) sont
décrits dans un mode déclaratif et de façon aussi indépendante que possible. Une séparation des
aspects liés au problème utilisateur de tous les autres aspects est souhaitable. Pour cela l’architecture
conçue pour l’objet permet cette séparation des aspects propres au domaine du problème de ceux
appartenant au contexte d’exécution.
Ce document est organisé en 10 chapitres. Le chapitre 2 présente les problèmes et besoins à
résoudre. Dans le chapitre 3, la problématique de la Qualité de Service est présentée. Le chapitre 4
décrit les objets pour et en rapport avec le temps réel. Le chapitre 5 étudie les objets actifs, leur lien
avec les processus et les problèmes de concurrence. Le chapitre 6 est consacré aux architectures
9
réfléchies. L’architecture proposée pour l’objet actif adaptable est décrite dans le chapitre 7. La mise
en œuvre, la description et la réalisation son décrits dans les chapitres 8 et 9. Finalement, le chapitre
10 présente les résultats obtenus.
10
2 Problème à résoudre, besoins
En général, les applications informatiques sont construites à partir de spécifications
fonctionnelles et non fonctionnelles imposées par les utilisateurs pour lesquelles elles sont conçues.
Dans certains cas, la satisfaction des besoins non fonctionnels peut conditionner fortement la
satisfaction des utilisateurs. Par exemple, dans une application multimédia, lorsqu'un service
périodique de transmission d'images est demandé, la satisfaction de l'utilisateur ne dépend pas
seulement de l'arrivée des images au destinataire mais aussi de leur régularité. Dans certains domaines
d'application tels que les systèmes temps réel dur, dont les contraintes temporelles doivent être
absolument respectées, ces aspects non fonctionnels jouent un rôle critique.
Plusieurs types de contraintes non fonctionnelles sont possibles, comme l'utilisation d'un
langage de programmation ou d'un système d'exploitation particulier, la précision des résultats des
calculs, le délai de transmission des données, etc. Ce travail ne concerne que les contraintes liées à
l'exécution des services.
2.1 Traitement des aspects non fonctionnels
Une approche possible pour traiter ces aspects non fonctionnels est de les considérer comme
des facteurs qui déterminent la qualité de service (QoS) des applications. De cette façon, les
contraintes non fonctionnelles des services demandés sont traduites en des besoins de QoS à satisfaire
par les fournisseurs de services. Une relation à respecter pour que les applications soient toujours
satisfaisantes est que la qualité de service fournie ( QoSF ) soit plus grande ou égale à la qualité de
service demandée ( QoSD ):
QoSD ≤ QoSF (1)
Il faut noter que, en général, pour un service quelconque la QoSD et la QoSF peuvent varier
pendant l'exécution (Fig. 2.1).
QoS D
QoS F
temps Fig. 2.1 La QoS fournie est toujours plus grande que la QoS demandée.
11
Des fautes de QoS apparaissent lorsque la relation (1) n'est pas respectée (zones pour
lesquelles QoSF < QoSD dans la Fig. 2.2).
Un d
relation (1)
prévues car
fournie ne p
fini. Des an
pourra offri
être vérifiée
Mêm
sont pas pri
fournie soit
Q
Fig
QoSD
QoSF
temps
zones dontQoSF < QoSD
Fig. 2.2. La QoS n'est pas toujours satisfaite.
Des problèmes difficile à résoudre par les développeurs est de savoir avant réalisation si la
sera ou non satisfaite. D'un côté la QoSD peut être connue pour toutes les situations
elle est spécifiée par les clients à partir de leurs besoins. Par contre, la QoS réellement
eut être qu'estimée, et elle ne sera connue qu'au moment où le service sera effectivement
alyses aident à déterminer si le niveau de QoS prévu (QoSP), c'est à dire que l'application
r pendant l'exécution, sera supérieur à la QoS demandée. La relation (2) ci-dessous doit
:
QoSD ≤ QoSP (2)
e si les analyses montrent que la relation (2) sera satisfaite, comme tous les facteurs ne
s en compte, il est toujours possible en théorie que pendant l'exécution la QoS réellement
inférieure à la QoS demandée. (voir Figure 2.3).
oS D
oS F
temps
oS P
.2.3. La QoS P est plus grande que la QoS D, mais la QoS F ne l'est pas toujours.
12
La QoS souhaitée pour un service peut aussi être exprimée sous forme d'intervalle de valeurs.
Dans ce cas, la QoS fournie doit se trouver dans l'intervalle pour satisfaire la requête (Figure 2.4).
QoS Dmin
QoS F
QoS P
QoS Dmax
Fig. 2.4. La QoS D définie comme un intervalle de valeurs.
Quels que soient les besoins de QoS, l'idée principale est qu'ils soient toujours satisfaits.
2.2 Prédictibilité et contexte d'exécution
Il faut noter que l'analyse statique de l'exécution d'un système peut être très difficile voire
impossible à réaliser en raison de la complexité des éléments impliqués. Par exemple dans les
systèmes muti-processeurs, les conséquences des interruptions ou de l'activité du système
d'exploitation sur le comportement des applications sont difficiles à déterminer. Aussi difficile à
prédire est le comportement des applications dans les environnements distribués dont les temps de
communication et de latence ne sont pas toujours connus.
Toute application s'exécute dans un contexte particulier déterminé par les systèmes matériels
et logiciels avec lesquels elle interagit ou partage des ressources : le système d'exploitation et ses
services (gestion des processus, gestion de la mémoire, etc.), les processeurs et le matériel en général,
les services de communication, les autres applications en exécution, etc. C'est dans ce contexte que les
applications trouvent les ressources dont elles ont besoin pour leur exécution. Si les ressources
souhaitées sont disponibles lorsque l'application les requiert, les services auront une qualité
satisfaisante. Dans le cas contraire, la qualité maximale attendue risque de ne pas être fournie. En
conséquence, le contexte d'exécution est un facteur déterminant de la qualité de service que les
applications fournissent. Du point de vue du développeur, un contexte d'exécution optimal serait un
contexte analysable a priori, avec des comportements prédictibles et mesurables, et qui pourrait
toujours fournir les ressources requises par les applications. Bien que les caractéristiques de ressources
matérielles telles que la taille de la mémoire vive ou la vitesse du processeur soient connues, les
quantités réellement disponibles au moment où les applications les demandent ne sont pas toujours
prédictibles. En conséquence les relations (1) et (2) sont difficiles à assurer.
13
2.3 Le problème à résoudre
Le problème principal à résoudre dans ce travail est de concevoir un modèle objet permettant
de gérer la QoS afin de satisfaire les besoins non fonctionnels des services face à des variations
dynamiques et imprévisibles du contexte d'exécution des applications. En général, deux approches
sont utilisées pour la gestion de la QoS. D'un côté l'approche statique dans laquelle l'application est
construite pour assurer a priori la satisfaction des besoins QoS, et d'un autre côté l'approche
dynamique dans laquelle les niveaux de QoS à fournir sont décidés pendant l’exécution. Dans ce
dernier cas la satisfaction de la QoS demandée n'est pas garantie.
2.3.1 Approche Statique
Dans l’approche statique, toutes les valeurs et actions affectant la QoS sont décidées dans la
phase de développement et le code les incorpore de manière implicite. Pour déterminer les niveaux de
QoS avant exécution, l'approche statique se base sur la prédiction du comportement des supports
matériel et logiciel sur lesquels les applications seront exécutées et nécessite la connaissance totale des
événements affectant le système et le contexte d'exécution. Ces informations et celles des besoins de
QoS sont prises en compte par les développeurs pour construire des applications capables de fournir la
QoS souhaitée. Des analyses exhaustives détermineront si les niveaux de QoS souhaités par les clients
seront ou non satisfait.
Les applications dérivées de cette approche sont fortement déterminées par les résultats des
analyses, et tous les niveaux de QoS sont définis et fixés dans le programme. Une fois que
l'application est lancée, aucune considération additionnelle sur la QoS n'est faite. Si la conception et
construction de l'application sont correctes, les besoins de QoS seront satisfaits tant que le contexte
d'exécution agit comme prévu.
Un des principaux désavantages de cette approche est que chaque modification de l'application
ou du contexte d'exécution requiert de nouvelles analyses concernant tout le processus de
développement. Comme les aspects QoS sont inclus dans le code (d'une façon non explicite), toute
modification doit être soigneusement étudiée.
Cependant il faut noter que cette approche est le choix obligatoire lorsque le système
n’accepte aucune défaillance et son principal avantage est la prédictibilité de la solution qu'elle
produit.
Il est possible de rendre le contexte d'exécution prédictible. Il faut pour cela avoir des
systèmes matériels et informatiques dont la disponibilité des ressources et l'affectation est totalement
prédictible. C'est le cas, par exemple, des systèmes faits sur mesure dont tous les éléments sont conçus
et construits pour satisfaire les besoins en QoS des applications. Evidemment, le coût de telles
solutions est important.
14
2.3.2 Approche Dynamique
Dans l'approche dynamique les décisions relatives à la gestion de la QoS sont prises pendant
l'exécution. Comme la QoS à fournir n'est pas connue auparavant, elle n'est pas figée dans le
programme et elle est décidée dynamiquement. Les applications doivent être munies de mécanismes
pour déterminer la QoS à fournir en considérant les besoins des clients, les capacités de service, et le
contexte d'exécution.
Un avantage important de cette approche est qu'elle est moins dépendante d'une connaissance
détaillée du système sur lequel l'application sera exécutée. S'il faut des analyses, elles ne sont pas aussi
exigeantes que dans l'approche statique. Un autre avantage est que les applications ne sont pas
construites pour une situation particulière et elles peuvent être adaptées facilement à de nouvelles
situations.
Cette approche est appropriée dans les cas où la prédiction des événements et du
comportement du système n’est pas possible. Elle est particulièrement appropriée pour les applications
présentant des degrés de liberté dans la façon de rendre un service et une tolérance vis à vis de la
qualité de service effectivement obtenue. Les effets négatifs des situations imprévues peuvent être
surmontés ou au moins réduits par une gestion adéquate de la QoS.
Finalement, il faut considérer la possibilité d'améliorer la QoS de base en augmentant les
ressources matérielles (une plus grande disponibilité de cycles de processeur, de bande passante de
communication, de mémoire vive, etc.). Cette possibilité peut être guidée par l'expérimentation, la
simulation ou par des analyses statiques. Cependant il restera toujours l'incertitude sur les effets des
Aspect Statique Dynamique Connaissance du
système et du contexte
d'exécution
totale
basique
Contenu du code de l'application
Code pour la satisfaction fonctionnelle (aspects QoS implicites)
Code pour la satisfaction fonctionnelle +
code pour le traitement de la QoS Satisfaction de la QoS à l'exécution
L'exécution de services satisfait totalement la QoS
(garanti par des analyses)
Décisions en ligne pour : a) la satisfaction de la QoS minimale, et b)
pour fournir la meilleure QoS en fonction du contexte d'exécution
Portabilité, réutilisation
Très limitée. Chaque contexte demande des nouvelles analyses et conceptions.
Potentiellement haute. Des changements de contexte demandent des analyses pour
assurer la QoS minimale seulement.
Séparation des aspects
Aspects QoS non visibles. Ils sont implicites dans le code.
Séparation claire entre les aspects fonctionnels et de QoS.
Analyse temporelle
Exhaustive, toutes les situations doivent être analysées.
Basique, seulement les situations critiques doivent être assurées.
Table 2.1. Comparaison entre les approches Statique et Dynamique.
15
aléas qui peuvent affecter négativement la QoS pendant l'exécution.
La Table 2.1 montre une comparaison entre les approches statique et dynamique.
2.4 Domaine d'application envisagé
Le domaine d'application envisagé dans ce travail est celui des systèmes temps réel
comportant des activités critiques1 et non critiques. C'est un domaine mixte entre le temps réel "mou"
et "dur". Du côté dur, les activités critiques devront garantir la satisfaction de leur QoS. Tandis que du
côté mou, la flexibilité dont on dispose pour respecter les contraintes des activités non critiques
permettra de décider de la QoS à fournir. Elle sera satisfaite au mieux dans la mesure des possibilités
au moment de l'exécution des services.
L'aspect temporel exprimé dans les requêtes des clients sera traité comme des besoins de QoS.
C'est le critère le plus important et il guidera la prise de décision pendant l'exécution.
2.5 Besoins
En considérant le problème à résoudre, le domaine d'application envisagé et le contexte
informatique de ce travail, il est souhaitable que la solution ait certaines propriétés. Les besoins pour la
solution sont les suivants :
• Premièrement pour la gestion de la QoS il faut une approche dynamique car c'est la seule
approche possible lorsque les contextes d'exécution sont imprédictibles. De plus, elle permet
une dégradation contrôlée de la QoS dans les situations difficiles. La connaissance complète
du comportement du contexte requise par l'analyse statique est pratiquement impossible à
obtenir dans de nombreux systèmes. Comme les niveaux de QoS à fournir sont figés dans le
code l'analyse statique ne peut faire face à des situations imprévues ou tirer parti des
possibilités qui se présentent pendant l'exécution pour fournir la meilleure QoS possible.
• Séparation des traitements. Il est souhaitable que le traitement des aspects fonctionnels du
problème de l'utilisateur soit séparé du traitement des aspects non fonctionnels. Les
mécanismes introduits pour la gestion de la QoS ne doivent pas interférer ni se mélanger
avec ceux du problème de l'utilisateur. Ainsi la modification d'aspects non fonctionnels
n'interfèrera pas avec les aspects fonctionnels.
• Etant donné le domaine d'application envisagé, l'aspect principal à considérer parmi les
contraintes non fonctionnelles est l'aspect temporel des requêtes. Le critère principal de QoS
est la réduction des fautes temporelles. Cependant, d'autres critères sont aussi prévus, tels
que l'importance des requêtes et la précision des réponses. Tout autre critère de QoS doit
pouvoir être ajouté au modèle.
1 Activités critiques: activités dont les contraintes doivent être absolument respectées.
16
• Réactivité. Les requêtes pour des services critiques doivent être traitées en priorité par les
serveurs. Ils doivent pouvoir exécuter un service critique arrivant à n'importe quel moment.
• Les qualités logicielles de l'approche objet telles que l'encapsulation ou l'indépendance des
objets doivent être respectées. Pour préserver l'indépendance des objets la messagerie doit
être transparente et indépendante de leur localisation. C'est particulièrement nécessaire pour
les applications distribuées dont la localisation des destinataires est généralement inconnue.
• Pour des raisons de portabilité il est souhaitable que les mécanismes de gestion de QoS
soient indépendants du contexte d'exécution.
17
3 QoS
Ce chapitre présente les concepts et la terminologie de la QoS qui serviront de cadre
conceptuel pour le traitement de la QoS dans le modèle envisagé. Bien que le sujet ait été traité depuis
longtemps déjà, les systèmes distribués, le multimédia et les réseaux de communication, pour ne citer
qu'eux, ont créé de nouveaux contextes pour l’exécution des applications. Le fait que la QoS soit un
aspect important dans ce nouveau contexte a motivé de nombreux groupes de recherche à concevoir de
nouvelles approches. En particulier des organisations internationales impliquées dans la définition de
modèles ou cadres de référence (standard) ont fait des propositions générales intéressantes.
3.1 Introduction
L'intérêt pour la QoS a engendré une grande activité de recherche ces dernières années.
Plusieurs approches et architectures ont été proposées pour résoudre les problèmes liés à la QoS. Elles
se centrent généralement sur une des couches logicielles intervenant dans la réalisation de services
[Campbell96]. Cependant depuis quelques années des organisations internationales travaillent à
l'élaboration de standards pour faciliter le traitement de la QoS. C'est le cas du travail conjoint de
ISO/IEC et ITU2 pour la proposition d'un modèle de référence pour systèmes distribués ouverts
[ISO93]. Dans le document décrivant les "fondations", la QoS est définie brièvement comme "un
ensemble de besoins de qualité dans le comportement collectif d'un ou plusieurs objets" [ISO95].
Ultérieurement le groupe démarrait l’élaboration d’un cadre général comportant des concepts,
terminologies et définitions de QoS [ISO97] afin de fournir une base commune orientant le
développement et l'amélioration de standards qui spécifient ou référencent la QoS. Bien que l'objectif
initial ait été de clarifier la description de la QoS pour le modèle de l'interconnexion des systèmes
ouverts OSI [ISO94], le cadre a été conçu sans lien avec une architecture particulière, permettant ainsi
son application dans les autres domaines des technologies de l'information.
3.2 Notion de QoS
En termes généraux la QoS est une propriété relative et arbitraire associée à la réalisation d'un
service. C'est à celui qui demande le service, le client, de définir les aspects qui déterminent la qualité
du service. C'est au fournisseur du service, généralement appelé le serveur, de trouver les moyens pour
satisfaire les besoins de QoS des clients. Bien que la QoS ait plusieurs significations, généralement
elle caractérise les aspects non fonctionnels de la réalisation de services. La sécurité, la précision, la
régularité, la ponctualité, la fiabilité, la disponibilité, etc. sont des exemples de propriétés qui peuvent
faire partie de la qualité des services.
2 ISO : International Organisation for Standardization; IEC : International Electrotechnical Commission; ITU : International Telecommunication Union; ITU-T : ITU Telecommunication Standardization Sector
18
La figure 3.1 illustre une relation seulement fonctionnelle entre client et serveur. Les besoins
du client sont satisfaits par l'exécution des services demandés (requête) au serveur.
Dans la figure 3.2 les besoins du client incluent les besoins de QoS. La satisfaction du client
ne dépend pas seulement de la réalisation du service mais aussi de la façon dont il est rendu. Dans une
telle situation le serveur doit prendre en compte les besoins de QoS du client. Par exemple, si le client
demande un service dans un délai quelconque, pour que le besoin de QoS soit satisfait le serveur doit
fournir le service dans le délai souhaité.
client: serveur:
requête
réponse
besoins fonctionnels
exécution de services
Figure 3.1. Relation client serveur limitée à l'aspect fonctionnel.
client: serveur:
requête
réponse + QoS
besoins fonctionnels et de QoS
exécution de serviceavec prise en comptedes besoins QoS
Figure 3.2. Besoins fonctionnels et de QoS dans la relation client serveur.
3.3 Propriétés de la QoS
Même si la QoS est une notion relative et arbitraire, elle a des propriétés importantes à savoir :
• Elle est due à ce que les clients s'intéressent aux aspects non fonctionnels associés à la
fourniture de services.
• Elle peut être garantie dans certaines périodes du cycle de vie d'un système (par exemple
pendant charge normale).
19
• Elle est négociable. La QoS associée à certaines fonctions d'un système est sujette à
modifications.
• Elle peut être composée. Les composants d'un système apportent les propriétés de QoS qui
concourent à produire la QoS du système auquel ils appartiennent.
3.4 Concepts et terminologie
Les concepts et définitions utilisés sont résumés ci dessous. La plupart d'entre eux sont adaptés
des documents sur la QoS de ISO/IEC et ITU.
3.4.1 Le service dans la QoS.
Dans le cadre de la QoS, le terme service doit être considéré dans un sens très général. Un
service a pour origine la requête qu'un client fait à un serveur pour demander la réalisation d'une
action. La réalisation de l'action fournit le service. Quelques exemples de services : la réservation de
ressources, l'exécution d'un code, une recherche d'information, la communication de données.
3.4.2 Caractéristiques de la QoS.
"Les caractéristiques de QoS représentent un aspect de la QoS d'un système, service ou
ressource, qui peut être quantifié et qui est défini indépendamment de la façon dont il est représenté ou
contrôlé" [ISO97]. Les caractéristiques de QoS servent à modéliser le comportement réel des aspects
qu'elles caractérisent. Exemples de caractéristiques : le délai de la transmission de données, la
précision d'une réponse, la confidentialité d'un service, la disponibilité d'une ressource.
Définition des caractéristiques. Toute caractéristique doit être définie avec précision afin de la
quantifier sans ambiguïté. Par exemple, la caractéristique délai peut être définie comme :
délai : "le temps écoulé (T2 - T1) entre deux événements E1 et E2, qui arrivent respectivement aux
temps T1 et T2 ".
Quantification des caractéristiques. La quantification des caractéristiques aussi doit être bien précisée.
Par exemple, pour le délai défini ci-dessus, la quantification peut être définie comme :
"une unité de temps quelconque telle que minute, seconde, milliseconde, etc., faisant référence à
une origine de temps connue"
Il faut noter que les valeurs des caractéristiques de QoS ne sont pas restreintes aux nombres.
Elles peuvent aussi être des vecteurs, matrices, noms d'états, etc.
20
3.4.3 Besoins de QoS et paramètres de QoS.
Les besoins des clients doivent être exprimés en besoins de QoS. Ils servent de guide aux
fonctions de gestion de la QoS, et peuvent affecter une ou plusieurs instances d'interaction entre client
et serveur. Les besoins de QoS peuvent être liés à une ou plusieurs caractéristiques de QoS. Par
exemple, lorsqu'un client demande un service avec un délai inférieur à 2 secondes, et une précision
minimale de 12 bits, le besoin de QoS est lié à deux caractéristiques : délai et précision.
Communication des besoins de QoS.
Les besoins de QoS connus par le serveur peuvent être des paramètres transmis dans les
requêtes ou être issus du contexte de QoS. Lorsqu'un serveur a besoin du service d'un autre serveur
pour réaliser un service, il doit lui transmettre les besoins de QoS. L'enchaînement des requêtes peut
concerner plusieurs niveaux nécessitant chacun des transformations de besoins de QoS. Un exemple
de cette situation est la négociation de QoS qui se déroule à travers les niveaux du modèle OSI pour
établir une connexion entre nœuds [ISO94]. A chaque niveau les besoins de QoS sont traduits en
besoins de QoS adaptés au niveau suivant.
Les paramètres de QoS sont des valeurs qui transmettent des besoins de QoS et qui sont
passés de client à serveur. Plusieurs types de paramètres sont possibles : une valeur désirée (précision
de 12 bits), un niveau maximal ou minimal (délai maximal de 2 secondes), un seuil (attente maximum
de 10 secondes), un intervalle, une liste de valeurs, etc.
Les besoins de QoS peuvent aussi être exprimés dans un contexte de QoS. Cela signifie que le
serveur dispose des informations concernant la QoS à fournir. Par exemple, elles peuvent être inclues
comme des règles de traitement ou dérivées des modes opératoires du système. L'avantage dans ce cas
est la réduction des interactions entre clients et serveurs puisque les paramètres ne sont pas échangés.
3.4.4 Contrats de QoS
Les contrats de QoS sont des accords sur la QoS établis entre client et serveur. Ils définissent
entre autres, les niveaux de QoS à fournir, les actions à effectuer en cas d'événement particulier, les
consignes pour le traitement des requêtes, la validité ou durée des accords, les responsabilités du client
et du serveur, la façon de modifier ou suspendre un accord, etc. Pendant la validité des accords le
client et le serveur doivent faire tous leurs efforts pour les respecter.
3.4.5 Gestion de QoS et Politiques de gestion de QoS
La Gestion de QoS est un terme général qui désigne l'ensemble des activités réalisées par un
système afin de surveiller, contrôler et administrer la QoS. Les règles qui déterminent les
caractéristiques et fonctions de QoS à utiliser pour un service définissent une politique de QoS. Les
activités de Gestion de QoS sont guidées par les besoins de QoS, le contexte du système et les
21
politiques de QoS en vigueur pour les activités. La gestion de la QoS est réalisée conformément aux
politiques de QoS du système.
3.4.6 Fonctions de Gestion de QoS et Mécanismes de QoS.
Les fonctions de gestion de QoS sont toutes les fonctions conçues pour aider à la satisfaction
des besoins de QoS. Normalement elles sont composées d'un ou plusieurs mécanismes de QoS réalisés
par une ou plusieurs entités. Parmi les activités supportées par les fonctions de gestion on trouve :
• L'établissement de la QoS pour un ensemble de caractéristiques de QoS
• La surveillance des valeurs de QoS fournies
• Le maintien de la QoS fournie le plus proche possible de la QoS attendue.
• Le contrôle des cibles de QoS
• Les requêtes d’informations sur la QoS
• Les alertes résultant d'événements relatifs à la QoS
Les mécanismes de QoS sont des actions bien précises qui servent de support aux fonctions de
gestion. C'est à travers eux que la gestion de la QoS se concrétise.
3.4.7 Catégories de QoS
Les besoins et caractéristiques de QoS peuvent être groupés en catégories de QoS lorsqu'ils
ont des similitudes. Ces catégories représentent un ensemble particulier de besoins de QoS imposés
par les particularités des applications. Par exemple, dans un système sensible au temps, les
caractéristiques de type temporel (date d’échéance, délai, périodicité, etc.) constitueront une catégorie.
Plusieurs catégories de QoS peuvent coexister dans un système. Par exemple lorsque les aspects
sécurité, temps, fiabilité font partie des besoins de QoS.
3.5 Gestion de la QoS
La QoS dépend de facteurs matériels et logiciels affectant l'exécution des services. Comme
elle ne peut pas être modifiée directement, c'est par des actions sur un ou plusieurs de ces facteurs
qu'elle peut être gérée, parmi lesquels :
• Les propriétés et quantités de ressources affectées au fournisseur de services
• Le comportement des couches informatiques de base qui supportent l'exécution (système
d'exploitation, système de communication, etc.)
• La charge du système
• Le comportement du serveur vis à vis du traitement des requêtes.
22
Les actions de gestion modifient le mode opératoire du système afin d'obtenir la QoS
souhaitée. L'affectation de ressources, le contrôle d'admission de nouveaux clients, la sélection des
requêtes à exécuter, la sélection d'une méthode pour le service à fournir, etc. sont des exemples
d’actions par lesquelles la QoS peut être gérée.
La gestion est présente dans tout le cycle de vie de la réalisation d'un service. Elle agit
différemment selon l'étape dans laquelle elle s'effectue. En général trois étapes sont identifiées :
• Avant de démarrer le service. Des activités de prédiction sont requises pour prévoir les
mécanismes les plus appropriés pour la gestion de QoS.
• Au moment de démarrer le service. Lorsque des négociations entre client et serveur sont
nécessaires pour établir les accords relatifs à la QoS.
• Pendant la réalisation du service. Pour contrôler le respect des accords de QoS face à des
changements de conditions d'exécution. Tant les besoins de QoS des clients que l'offre de
QoS des serveurs ou le contexte d'exécution peuvent changer sans préavis.
3.5.1 Gestion Intrusive et non-Intrusive
La gestion est dite non-intrusive lorsque l'application ne participe pas à la gestion de la QoS.
Les fonctions de gestion se situent en dehors l'application, dans le support logiciel / matériel
d'exécution, par exemple dans le système d'exploitation. Un avantage de cette approche est que
l'application n'est pas modifiée pour des raisons de QoS, et la séparation entre la solution fonctionnelle
et les traitements liés à la QoS est claire. Un autre avantage est que les mécanismes de gestion peuvent
traiter les besoins QoS de plusieurs applications, ce qui est particulièrement nécessaire pour la bonne
utilisation des ressources partagées.
La gestion de type intrusive est celle dans laquelle l'application participe à la gestion de la
QoS. L'avantage principal est une plus grande flexibilité de gestion permettant des fonctions et
politiques de gestion spécifiques à chaque application. Cependant la mise en œuvre est plus lourde et
un problème important intervient si les applications décident indépendamment de l'utilisation de
ressources partagées. Il est nécessaire d'avoir un système de gestion centralisé pour décider de
l'utilisation des ressources partagées en considérant les décisions sur la QoS prises par chaque
application. Dans cette approche la QoS est gérée par l'environnement et l'application. La figure 3.3
suivante illustre ces deux types de gestion.
23
Il f
façon optim
et appropri
solution acc
3.5.2 Co
Les
logicielles
plupart des
Grosso mo
QoS peut s
le Système
Il f
couche. El
plusieurs sy
logiciel inte
Un
(Real Time
interactifs.
couchehaute
intermédia
basse
Support d'exécution(logiciel et matériel)
GestionQoS
Apl 1 Apl 2
Support d'exécution(logiciel et matériel)
GestionQoS
Apl 1 Apl 2G. QoS G. QoS
(a) (b) Figure 3.3. Gestion type non-intrusive (a), et intrusive (b).
aut noter que seule l’application connaît ses besoins et elle est la seule capable d’utiliser de
ale les ressources qui lui sont affectées. La possibilité de gérer la QoS de façon spécifique
ée aux besoins particuliers de chaque application fait que la gestion intrusive est la seule
eptable pour le domaine d'application envisagé.
uches de gestion de la QoS
mécanismes de gestion de la QoS peuvent agir à différents niveaux parmi les couches
situées entre les ressources matérielles (couche basse) et l'application (couche haute). La
travaux de recherche proposent des solutions de gestion centrées sur un endroit précis.
do, et d'une façon arbitraire, on peut identifier trois couches dans lesquelles la gestion de la
e dérouler : haute, intermédiaire et basse. La table 3.2 montrer le rapport des couches avec
d’Exploitation et des exemples de types de gestion pour chacune d’elles.
aut cependant noter que la gestion de la QoS n'est pas nécessairement restreinte à une seule
le peut agir en plusieurs points parmi des couches du système. Il est aussi possible que
stèmes de gestion co-existent. Par exemple, lorsque la gestion de la QoS est réalisée par un
rmédiaire en même temps que la gestion menée par le système d'exploitation.
exemple de gestion en couche basse est le protocole de transport de bout en bout RTP
Transport Protocol) [RTP96] pour des applications temps réel, telles que l'audio et la vidéo
RTP opère au-dessus des services UDP (User Datagram Protocol du model TCP/IP) et ne
Endroit Type de gestion Au-dessus du Système d'Exploitation. Au niveau de l’application, au niveau du
gestionnaire de QoS, etc. ire Au niveau du Système d'Exploitation. Gestion de processus (threads), CPU,
mémoire, timers, etc. Au-dessous du Système d'Exploitation. Gestion de bande passante, de
communication de données, du stockage, de l’affichage, des ports, etc.
Figure 3.2. Couches pour la gestion de la QoS.
24
s'intéresse pas à la réservation de ressources ni ne garantit la QoS pour les services temps réel. Le
protocole qui utilise RTP permet un contrôle minimal sur l'envoi et la qualité des données. Il permet
entre autres de mesurer la QoS de la communication de données, de transporter les informations des
participants d'une session et de contrôler l'utilisation des ressources réseau.
Dans la couche intermédiaire c'est le système d'exploitation qui traditionnellement gère
l'utilisation des ressources et par conséquent la QoS. Mais les versions commerciales courantes n’ont
pas de mécanismes très élaborés spécifiques pour la gestion de la QoS. Du côté de la recherche, de
nombreux groupes travaillent à la conception de systèmes d'exploitation avec des mécanismes
spécifiques pour gérer la QoS. Certains d'entre eux s'orientent vers les applications multimédia
[Leslie97], d'autres vers la communications de données [Miller96], et d'autres encore vers des
applications temps réel [Blair94].
Une approche pour la gestion dans la couche haute parmi les plus explorées par les groupes de
recherche est celle où une couche logicielle intermédiaire (middleware) se charge de la gestion de la
QoS. Elle reçoit les demandes de QoS provenant des applications et prend des décisions qui sont
ensuite traduites par des requêtes au système d'exploitation. Un exemple de cette approche est le
Dynamic QoS Manager (DQM) [Brand98]. Dans DQM chaque application doit déclarer ses modes
opératoires et le bénéfice global qu'ils apportent au système en fonction des ressources utilisées. Avec
cette information, DQM détermine l’affectation des ressources et le mode dans lequel chaque
application doit opérer afin d'optimiser le bénéfice global. Le modèle bénéfice versus ressources
utilisé par DQM est une version dérivée des "QoS Levels" [Tokuda93].
Une autre idée pour la gestion à haut niveau est d’inclure des mécanismes de gestion de QoS
dans chaque application pour qu’elles-mêmes puissent gérer leur QoS de manière indépendante.
L'avantage principal est la possibilité que chacune ait ses propres critères de décision les plus
appropriés à ses besoins.. Au niveau des applications la gestion peut être de type centralisé ou
distribué dans les composants. Cependant il ne faut pas oublier que l'utilisation optimale de ressources
partagées demande une politique centralisée et une instance de gestion globale à toutes les applications
doit être mise en œuvre.
Ce dernier cas de gestion offre une plus grande flexibilité en raison de sa granularité plus fine.
Elle est aussi la seule solution praticable si les composants de l’application ont des besoins particuliers
de gestion de la QoS.
3.5.3 Phases
Les activités nécessaires pour la gestion de la QoS sont effectuées dans différents instants du
cycle de vie d’un service. En général les phases ou états par lesquels passe la gestion sont la
prédiction, l'établissement et la phase opératoire.
25
Phase de Prédiction
Le but de la phase de prédiction est l’acquisition de connaissances afin de déterminer les
conditions et possibilités du système concernant la QoS. Des informations sur le matériel, telles que la
vitesse du processeur, la quantité de mémoire vive disponible ou les durées des services de base
(système d'exploitation et communication), etc. doivent être connues. Si les valeurs disponibles sont
approximatives, elles pourront être précisées pendant l’exécution.
Phase d'établissement
Dans cette phase, un accord est trouvé entre client et serveur pour le niveau de QoS qui sera
fourni. Cet accord est le résultat de négociations mais il peut être re-négocié si les conditions
d'exécution changent. Par exemple lorsqu'un nouveau client ou serveur entre en scène.
• Types d’accords
Les accords dépendent principalement des besoins du client, des caractéristiques de QoS
concernées, des possibilités de service des serveurs et des politiques de QoS en vigueur. Une
sémantique précise est nécessaire pour que les parties puissent interpréter d’une façon correcte les
informations qu’elles se communiquent.
• Niveau des accords
Différents niveaux d'accords sont possibles en fonction du compromis sur la garantie de la
QoS. Trois niveaux sont proposés dans [ISO97] :
• Meilleur effort (best effort) : c’est le niveau d’accord le plus faible. Les serveurs font au
mieux pour satisfaire les besoins de QoS. Aucune garantie n'est donnée sur la QoS fournie.
• Obligatoire (compulsory) : dans ce niveau d’accord le service est suspendu si le serveur ne
peut pas fournir la QoS accordée. La QoS accordée n'est pas assurée.
• Garantie (guaranteed) : c’est le niveau d’accord le plus haut et la satisfaction de la QoS
demandée est assurée. Un service n’est pas accepté si le niveau de QoS ne peut être
maintenu.
Dans la phase d'établissement sont aussi définies les actions à réaliser lorsque le niveau de
QoS atteint une certaine valeur préétablie. Par exemple envoyer un signal au client ou au serveur,
enregistrer la valeur pour l'historique, etc.
Phase opératoire
L’objectif principal de la phase opératoire est de maintenir la QoS accordée pendant la phase
d’établissement. Les principales activités de cette phase sont :
26
• L'observation de la QoS. Il est nécessaire de connaître la QoS fournie pour savoir si les
accords en vigueur sont respectés ou non.
• Le maintien de la QoS. Des actions correctives sont nécessaires afin de maintenir le niveau
de QoS au niveau accordé.
• Demande d'informations sur la QoS entre clients et serveurs.
• Contrôle du client. S'assurer que le client n'utilise pas plus de ressources que celles qui lui
ont été affectées.
Mécanismes de correction
Un aspect important pour le maintien de la QoS dans la phase opératoire est la façon dont
s'effectuent les actions correctives. Deux approches sont présentées dans [ISO97] :
Correction interne. Elle est réalisée à l'intérieur du serveur par une boucle de rétro contrôle qui, à partir
des mesures de la performance interne, ajuste la QoS fournie en modifiant les paramètres de
fonctionnement. Les opérations à réaliser sont :
a) calculer la performance du système (PS) nécessaire pour fournir la QoS souhaitée
b) mesurer la performance actuelle
c) évaluer la différence entre la performance nécessaire et la performance mesurée
d) faire les corrections appropriées pour arriver à la performance nécessaire.
La valeur des paramètres affectant la QoS doit être fixée de façon à produire la QoS souhaitée.
Un processus traduit l'expression des besoins de QoS en valeurs pour les paramètres du système (type
et quantité de ressources, mode opératoire, bande passante, politique de traitement des requêtes, etc.).
Une fois que les valeurs sont calculées, elles sont comparées aux valeurs actuelles issues de
l'observation du système. La différence induit des actions correctives qui agiront sur la performance et
par conséquent sur la QoS (voir Figure 3.4).
27
Correction externe. Les
la performance requise e
calculée à partir des diff
a) mesurer la va
b) traduire en va
c) calculer la dif
d) agir sur les pa
A partir des me
est calculée. La différe
correction sur des param
telle que la QoS fournie
dans la figure Fig. 3.5.
QoSfournie
QoSsouhaitée
QoS
PS
PerformanceActuelle
PerformanceNécessaire
Actions deCorrection
Fourniseur de services
Fig. 3.4. Mécanisme de correction interne
mécanismes de contrôle sont situés à l'extérieur du serveur. La différence entre
t la performance actuelle, qui sert à déterminer les actions correctives, est
érences de QoS. Les opérations sont :
leur des performances relatives au service
leurs de QoS
férence entre QoS souhaitée et mesurée
ramètres du serveur liés à la QoS
sures de la performance actuelle du système, la valeur de QoS correspondante
nce entre QoS souhaitée et QoS calculée est ensuite traduite en actions de
ètres du système. Ces corrections ramèneront le système à une performance
sera égale à la souhaitée. Le mode d'action de la correction externe est illustré
28
QoSfournie
QoSsouhaitée
QoS
PS
PerformanceActuelle
Actions deCorrection
QoS
PS
Fourniseur de services
QoS
QoS fournie(calculée)
Fig. 3.5. Mécanismes de correction externe.
Pour illustrer la manière dont agissent les mécanismes de correction interne et externe,
prenons l'exemple suivant. Supposons que le délai d'un service dépend de la quantité de CPU affectée
au système par période (1, 2 ou 3 milisecondes) et de la période elle-même, comme le montrent les
courbes de la figure 3.6. (voir aussi figure 3.7)
2
4
65
Figure 3 .
Lorsque le client so
48 ms maximum, pour 2 ms
48 ms
2 ms
Figure 3.7. Périod
période [ms]
délai
20 40 60
00
00
00 00
48
2 ms/p3 ms/p
1 ms/p
.6. Délai en fonction de l'utilisation de CPU par période
uhaite le service dans un délai maximal de 400 ms, la période doit être de
de temps d’utilisation de CPU par période (voir figure 3.7).
48 ms 48 ms 48 ms 48 msTemps de CPU
e et utilisation de la CPU pour un délai de service de 400 ms.
29
Correction interne. Le délai maximal de 400 ms est traduit en une valeur de 48 ms pour la
période (figure 3.6). Cette valeur est comparée avec la période actuelle mesurée. Supposons que cette
période soit de 60 ms, alors il faudra une réduction de 12 ms à la période actuelle. Le processus de
correction interne est illustré dans la figure 3.8.
période ≤ 48 ms
période actuelle = 60 ms
période = - 12 ms
QoS = délai ≤ 400 ms
QoS
p
Figure 3.8. Valeurs impliquées dans la correction interne.
Correction externe. La période actuelle mesurée de 60 ms correspond à un délai de 500 ms
(QoS fournie). La comparaison de cette valeur avec le délai maximal souhaité de 400 ms (QoS
souhaitée) montre une différence de 100 ms, à réduire. En appliquant cette valeur à la courbe de
performance versus QoS (inverse de la courbe de la figure 3.6 ) la valeur dont il faut réduire la période
est de 12 ms. Le processus de correction externe est illustré dans la figure 3.9.
période = - 12 ms
période actuelle = 60 ms
QoS = - 100 msQoS = délai ≤ 400 ms
QoS
p
QoS
p
QoS = délai = 500 ms
Figure 3.9. Valeurs impliquées dans la correction externe.
Note : le délai souhaité de 400 ms peut aussi être atteint en conservant la période actuelle de 60 ms et
en passant le temps d’exécution par période de 2 ms à 3 ms (voir figure 3.6).
Dans le cas de la correction externe, l'entité chargée de la correction doit connaître les rapports
entre la QoS fournie et l'utilisation des ressources du fournisseur du service. Ces informations sont
spécifiques à chaque serveur ou contexte d'exécution et doivent être mises à jour chaque fois qu'elles
30
changent. Dans la correction interne par contre, c'est le même fournisseur du service qui s'en charge et
pour cela il utilise ses propres informations. Aucune information externe ou d'une autre entité ne lui
est nécessaire. Si le serveur change, cela ne met pas en difficulté le mécanisme de correction, car le
nouveau serveur contient les informations nécessaires. Par l'indépendance et la flexibilité qu'elle offre,
la voie de correction interne est l'approche la plus appropriée pour ce travail.
3.6 Evaluation/Optimisation de la QoS
L'évaluation de la QoS est nécessaire pour connaître la QoS fournie par un système. Elle est
aussi nécessaire dans le processus de gestion pour décider des actions correctives. Avant qu'elle puisse
être évaluée, quelques questions de base doivent être clarifiées. Quelles valeurs peut prendre la QoS ?
Comment se traduisent les mesures résultant de l'exécution de services en valeurs de QoS? Quel
rapport existe-il entre le degré de satisfaction des besoins de QoS et la valeur de la QoS? Les travaux
sur le sujet ne sont pas toujours très clairs. D'abord parce que chaque client s'intéresse de façon
particulière à des propriétés spécifiques de la réalisation des services. Ensuite parce que la valeur que
chaque client donne à la qualité est arbitraire et subjective. Ces questions doivent être clarifiées par la
définition de critères sur lesquels baser le calcul de la QoS.
3.6.1 Fonctions d'utilité
Les fonctions d'utilité décrivent le bénéfice que l'exécution d'un service apporte au client, en
fonction d'une caractéristique de QoS. Par exemple, si le besoin de QoS d’une requête est un délai
maximal de 2 secondes, le bénéfice associé à la fourniture du service en fonction du délai peut être
défini comme :
Note : dans le domaine du temps réel, la date limite à laquelle le client désire que le service
soit fourni est appelée "date d’échéance", ou deadline en anglais (DL).
Utilité = U(délai) = V1, lorsque délai est inférieur ou égal à 2 secondes
V2, lorsque délai est plus grand que 2 secondes
DL
V1
délai
utilité
V2
Graphiquement :
L'expression de l'utilité peut prendre des formes très variées. La table 3.3 suivante montre
quelques exemples.
31
Caractéristique Besoin Utilité Version graphique
délai
délai ≤ DL
V1 si délai ≤ DL1
V2 si DL1 < délai ≤ DL2
0 si délai > DL2
délai
délai ≤ DL2
a) V1 si délai ≤ DL1
b) V1- (délai - DL1)*(V1-V2)/(DL2-DL1),
si DL1< délai < DL2
c) V2 si délai ≥ DL2
précision
(nombre de bits)
8 ≤ précision ≤ 16
0 si précision < 8 bits
1 si précision = 8 bits
2 si précision = 12 bits
4 si précision ≥ 16 bits
DL2
V1
délai
utilité
V2
DL1
uti
4
210
Table 3.3. Exemples de fonctions de val
Les valeurs d'utilité peuvent être considérées directement
particulier lorsque l’évaluation est faite pour une seule requête. P
l'exécution de plusieurs requêtes ils faut des critères définissant la m
d'utilité dans l'évaluation de la QoS.
3.6.2 Critères de QoS
Les critères de QoS définissent la manière d'évaluer la QoS
les exécutions de services, les caractéristiques de QoS et la valeur de
Il est possible de définir plusieurs critères de QoS pour cha
pour la caractéristique délai, les valeurs : délai moyen, écart entre l
pourcentage de fois où le délai satisfait une contrainte, etc. sont des c
En plus, chaque critère permet plusieurs choix de calcul de la
du besoin de QoS "délai maximal de 2 secondes", dont la caractérist
N derniers services exécutés, les critères de QoS peuvent être, par exe
a) critère qui considère la valeur du délai moyen, dm = Σ délai / N po
QoS
2Possibilités de calcul :
• QoS = 2 - dm
32
utilité
DL1 DL2
V1
V2délai
lité
précision8 12 16
eurs
comme les valeurs de QoS, en
our évaluer la QoS résultant de
anière de composer les fonctions
. Ils établissent des rapports entre
QoS correspondante.
que caractéristique. Par exemple,
e délai maximal et le minimal, le
ritères possibles.
QoS. Prenons par exemple le cas
ique est délai. En considérant les
mple :
ur le calcul de la QoS :
dm2
QoS
1
• QoS = 1 / dm
excellente si dm < 0,5 secondes bonne si 0,5 ≤ dm ≤ 1,5 secondes normale si 1,5 ≤ dm ≤ 2,0 secondes mauvaise si dm > 2,0 secondes
• QoS =
b) critère qui considère le degré de respect de la contrainte "délai maxi
de la QoS. Possibilités de calcul :
1• QoS = % de respect de la contrainte
= x / N
x = nombre de fois où délai ≤ 2, pour les N derniers services.
Q
• QoS = Qmax * sin (90*x/N)
Les valeurs obtenues en appliquant les critères peuvent être
valeurs de QoS, par exemple la valeur x/N calculée selon le critère
peut être considérée comme la valeur de la QoS pour les N requêtes.
Ces valeurs de QoS peuvent aussi être produites par des f
exemples de la figure 3.10.
10
k
QoS
x / N 10
Qmax
QoS
x / N 10
Qmax
QoS
Figure 3.10. QoS en fonction des valeurs produites à partir
33
dm2
1
1
/2
dm
2,0
1,5
0,5
0,0excellente
bonne
normale
mauvaise
QoS
mum 2 secondes" pour le calcul
QoS
1
00%
x/N 0
xN
max
QoS
prises directement comme des
"% de respect de la contrainte",
onctions comme l'illustrent les
x / N 10
Qmax
QoS
x / N
des valeurs de "x / N"
3.6.3 Dimensions Multiples
Plusieurs dimensions peuvent apparaître dans les besoins de QoS. Pour chacune d'elles
plusieurs critères d'évaluation sont possibles. Il faudra définir comment les valeurs produites par
chaque critère seront prises en compte pour l’évaluation de la QoS.
Considérons le cas où les besoins de QoS incluent deux caractéristiques, date de la fourniture
du service et précision, avec les fonctions d'utilités de la figure 3.11.
DE temps
Utilité
(a)
V
Pmin précision
Utilité
(b)
Pmax
V1
V2
DE= date d’échéance Pmin, Pmax = Précision minimale et maximale.
Figure 3.11. Utilité en fonction de (a) date de service fourni, et (b) précision de la réponse.
Premier critère.
Supposons que le critère de QoS pour la caractéristique date soit « le % de respect de la date
d'échéance » :
• Premier critère : C1(date) = x / N
Les valeurs produites par ce critère sont des valeurs réelles dans l'intervalle [0..1]. Pour obtenir
les valeurs de la QoS prenons une fonction du type : QoS1
1 0 x/N
k
• QoS1 = k * Valeur du critère = k * C1(date).
Deuxième critère.
Pour la caractéristique précision supposons que le critère soit « la précision moyenne
fournie », calculée de la façon suivante :
34
• Deuxième critère : C2(précision) = Σ Pi / N
avec :
Pi = ((précisioni - Pmin)/(Pmax - Pmin))
N = nombre de requêtes considérées
La valeur de Pm se situe dans [0..1]. Une fonction doit être définie pour obtenir les valeurs de
la QoS selon le critère C2. Supposons que la fonction corresponde à :
QoS2
Qmax
QoS2 = Qmax/5 si C2(précision) entre 0 et 0.3 Qmax/2 si C2(précision) entre 0.3 et 0.7 Qmax si C2(précision) entre 0.7 et 1
Qmax/2
Qmax/5
1 0 Pm0,3 0,7
QoS résultante.
Avec les deux critères définis pour l'évaluation de la QoS, la valeur totale de la QoS résulte de la
composition des valeurs apportées par chacun d'eux. Elle peut être composée via une opération
quelconque si QoS1 et QoS2 sont indépendantes. Par exemple : QoS = QoS1 + QoS2
La figure 3.12 montre graphiquement le résultat.
10
k
QoS1
x/N 10
Qmax
QoS2
Pm
Qmax/2
Qmax/5
0,3 0,7
10
Qmax
QoS
Pm
Qmax/2
Qmax/5
0,3 0,7
1x/N
k + Qmax
Figure 3.12. QoS = QoS + QoS
35
1 2
Lorsque QoS1 et QoS2 sont dépendantes il est nécessaire de définir une fonction F pour
calculer la valeur de la QoS totale :
QoS = F (QoS1 , QoS2 )
3.6.4 Optimisation de la QoS
L'objectif de l'optimisation de la QoS est de trouver un point de fonctionnement du système
qui maximise la QoS globale fournie en respectant les contraintes. Bien que dans la plupart des cas
cela se traduise par la recherche d'une affectation de ressources appropriée, plusieurs autres facteurs
influant la QoS peuvent être pris en compte. Par exemple avec une affectation de ressources donnée, la
QoS peut aussi être modifiée en fixant le nombre de clients ou le nombre de requêtes par client ou le
mode opératoire de l'application (lorsqu'elle a plusieurs modes opératoires valides chacun fournissant
un niveau de QoS différent), etc. En plus, lorsque le client accepte différents niveaux de QoS pour une
requête, cela permet aux mécanismes de gestion de choisir la meilleure manière de rendre le service en
fonction des possibilités du système.
Le problème général d'optimisation de la QoS est NP-difficile [Lee98] : la seule possibilité de
trouver une solution optimale est l'énumération de toutes les solutions possibles, ce qui en pratique est
irréalisable. Parmi les approches possibles on peut citer les algorithmes d'approximation qui
s'exécutent en temps polynomial, et les techniques heuristiques qui, si elles ne garantissent pas une
solution optimale, produisent une bonne solution en temps raisonnable [Lee98].
Plusieurs travaux de recherche proposent des méthodes applicables à diverses situations. Une
grande partie d'entre eux utilise des modèles de bénéfice en fonction des ressources pour caractériser
l'exécution des services avec divers niveaux de ressources. C'est le cas des "Time Value Functions"
(TVF) de [Locke86]. Elles expriment le bénéfice de la production d'un résultat en fonction du moment
auquel il est fourni. Une affectation optimale des ressources (processeur) est trouvée en considérant les
TVF de tous les services à exécuter. Un autre exemple est le modèle analytique d'affectation de
ressources pour la gestion de la QoS, Q-RAM, proposé dans [Rajku97]. Le modèle distingue plusieurs
catégories de QoS parmi les besoins de QoS (temps, sécurité, codage, qualité des données, etc.).
Chaque application doit déclarer la quantité minimum de ressources dont elle a besoin pour
fonctionner et une fonction qui précise l'utilité ajoutée selon les ressources utilisées. A partir de ces
informations l'objectif de Q-RAM est de trouver une affectation de ressources qui maximise l'utilité
totale du système en assurant la satisfaction des besoins minimaux de QoS des applications.
3.6.5 Optimisation hors ligne
L'optimisation hors ligne, ou statique, s'effectue avant que le système entre en fonctionnement.
Des analyses visent à trouver une configuration d’exécution du système (affectation de ressources,
36
mode des applications, etc.) qui optimise la QoS à fournir. Pour qu'une telle optimisation soit faisable,
il est nécessaire que tous les événements affectant le système, le comportement des applications et
l'utilisation des ressources soient connus.
Toutes les techniques d'optimisation sont faisables dans cette approche. Une fois qu'une
configuration satisfaisante est trouvée, elle est inclue dans le code de l'application et aucune autre
activité d'optimisation n'est réalisée pendant l'exécution.
Comme l’approche statique requiert la connaissance complète des événements affectant le
système, elle est mieux appropriée aux systèmes avec activités de type périodique dont les
caractéristiques telles que la durée et la période sont connues. Dans de telles conditions il est possible
d'identifier des patrons réguliers d'exécution qui serviront à trouver une affectation de ressources
optimale.
3.6.6 Optimisation en ligne
L'optimisation en ligne s'effectue pendant que le système est en exécution. Une fois une
solution trouvée et appliquée, le système produit la plus grande QoS possible. Une nouvelle
optimisation doit s’effectuer chaque fois que les conditions affectant la QoS changent. Evidement,
l'ampleur des calculs peut demander des temps importants et rendre ce type d’optimisation
impraticable. C'est particulièrement critique dans les systèmes soumis à des contraintes de temps. Les
approches utilisant des heuristiques sont des alternatives à considérer car elles peuvent donner une
solution dans un temps acceptable. Même si les solutions qu’elles produisent ne sont pas optimales, ce
n'est pas trop grave, car la nature imprédictible des systèmes fait qu'une solution obtenue pour une
situation quelconque, est une solution passagère qui n'est plus optimale lorsque de nouvelles
conditions d’exécution arrivent.
Etant donné la nature dynamique et imprédictible du domaine d'application vers lequel
s'oriente ce travail, l'approche d'optimisation la plus adéquate est la prise de décision en ligne. Même
si l'optimisation exacte est irréalisable en pratique, les principes sur lesquels elle se fonde sont utiles.
37
4 Systèmes Temps Réel
Dans ce chapitre sont présentés les concepts et caractéristiques généraux des systèmes temps
réel, le domaine d'utilisation du modèle ARTO. La principale caractéristique des systèmes temps réels
est que l'exécution des activités est soumise à des contraintes temporelles. L'approche choisie pour le
traitement des contraintes temporelles dans ARTO est de les considérer comme des besoins de QoS.
Même si d’autres besoins non fonctionnels peuvent être présents dans les requêtes, l'idée est que les
principaux critères dans la gestion de la QoS soient ceux qui dérivent des contraintes temporelles.
Il faut noter que ce travail n'est pas orienté vers les langages objets temps réel, mais vers les
modèles et architectures objet supportés par des environnements de développement.
4.1 Le facteur temps
Dans les applications temps réel les contraintes temporelles, telles que date d’échéance,
généralement dérivées des procédés physiques avec lesquels elles maintiennent une forte interaction
(surveillance, contrôle, conduite, etc.). En plus de satisfaire les besoins fonctionnels du système, un
des principaux objectifs des applications temps réel est le respect des contraintes temporelles des
services qu'elles fournissent. Bien que traditionnellement les systèmes temps réel aient été classés en
deux catégories (temps réel dur et temps réel mou3), un grand nombre de situations existe en raison de
la grande variété des systèmes physiques et des contraintes qu'ils imposent.
D'un côté certains systèmes, très exigeants sur le respect des contraintes temporelles,
demandent que toutes les contraintes soient toujours respectées. Ce sont des systèmes
traditionnellement appelés systèmes temps réel dur dont les défaillances peuvent entraîner des
conséquences catastrophiques (système de pilotage d'avion, de contrôle de missiles, de contrôle
d'usines nucléaires, etc.).
D'un autre côté, certains systèmes moins exigeants sont capables d'accepter des fautes
temporelles sans être considérés comme défaillants. Ce sont les systèmes traditionnellement appelés
systèmes temps réel mou. Bien que l'idéal soit le respect de toutes les contraintes, leur objectif est
plutôt d’arriver à la meilleure satisfaction possible des contraintes. Cet objectif est souvent exprimé en
fonction de mesures telles que le retard moyen, la valeur de la qualité ou le nombre de fautes.
Finalement il reste les systèmes dont l’activité n’est pas soumise à des contraintes temporelles
et qui n'appartiennent pas à la catégorie des systèmes temps réel.
Il faut noter néanmoins que, en général, les systèmes contiennent des activités de tous types :
temps réel dur, temps réel mou, et des activités sans contraintes temporelles. En plus, les activités
peuvent changer de type selon les situations par lesquelles passe le système. Par exemple, l'activité
3 Un point de vue plus récent n'utilise pas cette classification et considère seulement l'existence d'applications soumises à des contraintes temporelles, dont le temps réel dur est un cas particulier [Jensen85].
38
"mesure de l'altitude d'un avion" peut être de type mou pendant le vol de croisière et devenir de type
dur pendant l'atterrissage.
Bien que traditionnellement l’aspect temporel ait été une caractéristique des systèmes classés
"temps réel" seulement, actuellement il est de plus en plus pris en compte dans les applications
informatiques en général. Sans être considéré comme un facteur critique comme dans les systèmes
temps réel durs, l'aspect temporel est plutôt considéré comme un facteur lié à la qualité des
applications. Cette tendance est encore plus forte par la multiplication des réseaux de communication
et des systèmes distribués, dont des applications telles que le multimédia, la téléconférence, la bourse,
etc., sont sensibles au temps de réponse.
4.2 Les contraintes temporelles
Les besoins des clients relatifs au temps de réalisation des fonctions demandées sont traduits
par des contraintes temporelles sur l’exécution de ces fonctions. Bien que d’autres contraintes puissent
être aussi présentes dans les requêtes (précision, confidentialité, etc.), le respect des contraintes
temporelles est le principal souci des systèmes temps réel. Par exemple, si un client demande un délai
maximal de D secondes pour l'arrivée des paquets dans un service de transport de données, la
contrainte temporelle "ne pas dépasser un délai maximal de D secondes" devient une obligation du
fournisseur du service.
4.3 La valeur du service en fonction du temps
Du point de vue des clients, les applications sont plus ou moins performantes selon leur degré
de satisfaction des contraintes. Par exemple, dans le cas du temps réel dur, si une réponse arrive après
la date attendue elle n'a aucune valeur pour le client. Par contre dans le cas du temps réel mou, il est
possible qu'elle soit encore utile après la date d'échéance. Une technique pour décrire le rapport entre
la valeur d'un service et la date à laquelle il est rendu, est celle des fonctions temps valeur ou Time
Value Functions, TVF [Locke86]. La Figure 4.1 illustre trois exemples de TVF. Dans (a) le service
apporte une utilité de valeur "V" jusqu'au "Temps critique". Après cette date, l'utilité du service vaut
zéro. Dans (b), l'utilité jusqu'à la date "Temps critique" est "V". Au-delà de cette date l'utilité descend
linéairement pour arriver à zéro dans le temps "t0". Dans (c) l'utilité apportée par l'exécution du service
vaut "V" si la date d'exécution se situe entre les dates "Temps critique1" et "Temps critique2". Elle vaut
zéro en déhors de cettes dates.
39
(a)
tempsTempscritique
V
(b)
tempsTempscritique
(c)
tempsTemps critique2Tempscritique1
V V
Utilité Utilité Utilité
t0
Figure. 4.1. Exemples de Time Value Functions.
Les TVF ont été utilisées pour construire un plan d'exécution de requêtes qui maximise le
bénéfice total apporté par leur exécution [Jensen85].
4.4 La date d'échéance
Une des contraintes temporelles les plus représentatives des applications temps réel est la date
d'échéance4. Le client fait une requête et spécifie une date maximale pour sa réalisation. Le service est
correct s'il est fourni avant la date d'échéance. Dans le cas contraire, deux situations sont possibles.
Lorsque l'exécution n'a aucune valeur pour le client après la date d'échéance, il s'agit d'une échéance
dure (hard deadline). Néanmoins si après la date d'échéance l'exécution apporte encore un bénéfice au
client, il s'agit d'une échéance molle (soft deadline). Les figures 4.1 (a) et (b) illustrent ces deux types
d'échéances.
En général les systèmes temps réel contiennent les deux types de contrainte.
4.5 L'ordonnancement
Un facteur critique pour les applications temps réel est l'ordre d'exécution des activités. Outre
les contraintes temporelles à considérer, le problème de planification devient plus complexe lorsque
plusieurs processus s'exécutent concurremment en utilisant des ressources communes (CPU, mémoire,
canaux de communications, etc.). C'est en raison de la nature concurrentielle des systèmes physiques
que les applications doivent traiter des événements en parallèle.
L'ordonnancement de tâches a été toujours un sujet de recherche très actif dans le domaine des
applications temps réel et de nombreuses solutions ont été proposées [Stankovic95] [Liu73].
4.6 Approches Statique et Dynamique
Par rapport à la façon de construire le planning des tâches, il existe deux grandes
classifications : l'ordonnancement statique et l'ordonnancement dynamique.
4 "deadline" en anglais.
40
L'ordonnancement statique (hors ligne)
Dans l'ordonnancement statique le planning est construit hors ligne avant l'exécution de
l’application en analysant les activités et événements du système dans toutes les situations possibles.
Toute la dynamique du système doit être connue à l'avance. Pour que l'analyse soit possible il est
nécessaire de disposer de toutes les valeurs affectant le planning, telles que le temps d'exécution des
tâches, la date à laquelle elles seront exécutées, les ressources qu'elles utiliseront, etc. Une fois qu'un
plan est défini, il ne change pas pendant toute l'exécution. Ce type d'ordonnancement est destiné aux
systèmes temps réel durs, en particulier aux systèmes avec des tâches périodiques.
L'ordonnancement dynamique (en ligne)
Dans l'ordonnancement dynamique le planning d'exécution des tâches se fait pendant que se
déroule l'exécution de l'application. Normalement il est construit chaque fois qu’arrive un événement
qui affecte le planning (arrivée de message, fin d'une exécution, faute temporelle, etc.). Ce type
d'ordonnancement est approprié pour les systèmes dont il est impossible de prédire la dynamique et
l'arrivée des événements.
Il faut noter qu’en raison du temps que peut prendre la construction du planning,
l'ordonnancement dynamique peut être inadéquat pour certaines applications temps réel, en particulier
lorsqu'une solution optimale est souhaitée (problème NP complet). Cependant via des solutions
heuristiques ne prenant pas un temps trop important, l'ordonnancement dynamique est utilisable en
pratique.
En plus, il faut noter que lorsque le système est surchargé et que des fautes temporelles sont
inévitables, les solutions optimales n'ont pas beaucoup de sens. Il vaut mieux des solutions vite
trouvées permettant une dégradation contrôlée du système.
Selon l’information sur les activités à exécuter dont l'ordonnanceur dispose, certains types
d'algorithmes d’ordonnancement sont plus appropriés que d’autres :
• Sans information. Il n'y a pas de moyen pour différencier les activités, donc un ordonnancement de
type "round-robin" ou aléatoire peut être utilisé.
• Importance relative des activités. Ordonnancement selon importance; cet algorithme va choisir
l'activité avec la plus haute importance.
• Date d'échéance et temps d'exécution des activités. Un ordonnancement fondé sur l’échéance
(l'activité avec la date d'échéance la plus proche est choisie) ou sur la laxité (l'activité avec la plus
petite laxité est choisie) est optimal dans ce cas.
• Fonctions de temps et valeur (TVF). Des algorithmes plus complexes peuvent être utilisés, tel que
l'ordonnancement avec "meilleur effort" (best-effort scheduling [Locke86]).
41
4.7 Types d'ordonnancement
Comme la prédictibilité est un des aspects prépondérants des systèmes temps réels, des
analyses sont nécessaires pour vérifier si le planning des tâches est adéquat. Plusieurs types
d'ordonnancement sont possibles selon que : a) le système fait ou non une analyse d'ordonnançabilité,
b) l'analyse est statique ou dynamique, et c) l'analyse produit ou non un planning selon lequel les
tâches seront exécutées. A partir de ces possibilités, différentes approches algorithmiques pour
l'ordonnancement sont identifiées [Ramamritham94] :
• statique conduite par table (static table-driven) : une analyse statique d'ordonnançabilité est
réalisée et le résultat est utilisé pendant l'exécution pour décider de l'exécution des tâches.
• statique conduite par priorités, avec préemption (static priority-driven preemptive) : une analyse
d'ordonnançabilité est réalisée mais nul plan n’est construit. La tâche avec la plus grande priorité
est exécutée d'abord.
• dynamique basée sur un plan (dynamic planning-based) : l'analyse d'ordonnançabilité est faite
pendant l'exécution. Une tâche qui arrive est acceptée dans le plan si son exécution est possible.
Le plan est construit au fur et à mesure que les tâches arrivent.
• dynamique meilleur effort (dynamic best-effort) : le système ne fait pas d’analyse, mais il fait des
efforts pour que les contraintes temporelles soient respectées. Aucune garantie n’est fournie et les
tâches peuvent être tuées pendant leurs exécutions.
Bien que ces quatre approches aient été mentionnées séparément, dans la pratique une ou
plusieurs d'entre elles peuvent apparaître dans des solutions d'ordonnancement particulières.
4.8 Le support pour le temps réel
Dans les systèmes d'exploitation c'est normalement le composant appelé "ordonnanceur"5 qui
se charge de planifier l'exécution des tâches selon une politique particulière (FIFO, "round robin",
selon la priorité des processus, etc.). Vu les particularités des applications temps réel, les
ordonnanceurs des systèmes d'exploitation courants ne sont pas adaptés car ils ne prennent pas en
compte les contraintes temporelles dans leur politique d'ordonnancement. En plus, la prédictibilité
temporelle de leurs mécanismes de base (service d'interruptions, création de threads, récupération de
mémoire, etc.) est basse [Jones98] [Ramamritham98].
Plusieurs solutions ont été proposées pour surmonter le problème. D'un côté il existe des
systèmes d'exploitation dont les noyaux ont été spécifiquement conçus pour l'exécution d'applications
temps réel. Certains ont été construits pour des contextes matériels et applicatifs spécifiques, donc très
efficaces mais avec très peu de portabilité. D'un autre coté, il y a ceux de propos général plus ouverts.
5 Scheduler en anglais.
42
Dans cette approche les propriétés de performance et de prédictibilité sont obtenues en éliminant les
fonctionnalités "superflues" et en optimisant le code. Les objectifs à attendre sont de réduire la taille
du code, de réduire le temps de changement de contexte de tâche (contex switch), de répondre
rapidement aux interruptions, etc. Quelques exemples de noyaux temps réel commerciaux sont QNX,
PDOS, pSOS, VCOS, VRTX32, et VxWorks. Dans le même esprit mais dans le secteur de la
recherche on trouve aussi entre autres les systèmes Alpha [Clark92], Spring6 [Stankovic89], Real-
Time Mach [Tokuda90].
Dans une autre approche, les systèmes d'exploitation à caractère général sont étendus en
modifiant quelques parties ou en ajoutant certaines fonctionnalités, afin d'offrir aux applications un
environnement d'exécution supportant le temps réel. Généralement les versions de systèmes
d'exploitation "temps-réel" résultantes sont moins rapides et moins prédictibles que celles
spécifiquement conçues pour le temps réel. Cependant les plus grandes fonctionnalités et les
environnements de développement plus puissants qu'elles supportent font d'elles des solutions très
attractives. Quelques exemples de systèmes basés sur ce type de solution sont RT-UNIX [Furht91],
RTX [Carpenter97], RT-Linux [Yodaiken97]. Un étude sur cette approche et les différentes techniques
utilisées est faite dans [Furht93].
Enfin, il y a les approches dont les services d'ordonnancement des systèmes d'exploitation sont
utilisés tels qu'ils sont, sans les modifier. L'ordre d'exécution des tâches est contrôlé par un programme
au niveau de l'application à travers la gestion des paramètres des tâches qui s'exécutent [Lin98]
[Jones98]. Le principal avantage de cette approche est la flexibilité qu'elle offre au développeur car,
comme la construction du planning se fait au niveau de l'application, il peut fabriquer la politique
d'ordonnancement convenant à ses besoins. Néanmoins la conception et la construction d'un
ordonnanceur peut demander un effort supplémentaire considérable. D'un autre côté la solution peut
avoir des performances faibles et peu prédictibles, car elles dépendent fortement des propriétés
temporelles des mécanismes de base du système d'exploitation, du matériel concerné, et de leurs
interactions. Quelques résultats intéressants obtenus selon cette approche sont présentés dans
[Jones98]et [Ramamritham98].
Il faut noter que pour les systèmes temps réel dur, l'objectif principal de l'ordonnanceur est de
produire un plan d'exécution de tâches capable d'assurer le respect absolu des contraintes. Le problème
est difficile à résoudre car la solution requiert la prédiction de tous les événements affectant le système
et le comportement du contexte supportant l'exécution. Dans le cas du temps réel mou, du fait que les
contraintes temporelles peuvent être violées, l'objectif de l'ordonnancement n'est pas la satisfaction
totale des contraintes. Il est souvent exprimé en d'autres termes tels que minimiser le délai moyen,
maximiser le bénéfice apporté par les exécutions, minimiser le nombre de fautes temporelles, etc.
6 Dans Spring un co-processeur contenant le code de l'ordonnanceur fut spécifiquement construit afin d'accélérer son exécution et de l'exécuter en parallèle avec le processeur central [Burleson93].
43
TECHNOLOGIES DE BASE
Les chapitres 5 et 6 présentent les concepts et propriétés des technologies sur lesquelles se
base la conception du modèle ARTO. D'un coté l'orientation objet fournit les moyens logiciels pour la
formulation et la réalisation du modèle. Les propriétés importantes de l'orientation objet telles que la
modularité, l'indépendance, sont enrichies par la concurrence, l'envoi de messages et les processus
légers des objets actifs. D'un autre coté, les architectures à méta niveaux dérivant des systèmes
réfléchis sont un bon point de départ pour la conception et réalisation des mécanismes d'adaptation et
de gestion de QoS indépendamment des solutions fonctionnelles appartenant au domaine du problème
utilisateur.
5 Objet Actif
Dans ce chapitre sont présentés les concepts et caractéristiques du modèle objet actif qui
seront utiles pour la compréhension et formulation du modèle ARTO. En considérant que l'intérêt est
la conception d'un modèle objet pour développer des applications à un haut niveau d'expression, il ne
doit pas dépendre d'un langage particulier de programmation, mais des propriétés des langages telles
que le support pour l’exécution asynchrone sont nécessaires.
5.1 Objet actif et processus
5.1.1 Objet Actif
Les objets actifs sont le produit de l'intégration de la programmation par objets et de la
programmation concurrente7 qui a eu lieu dans les années 80. D’un côté l'orientation objet offrait une
approche de modélisation de systèmes dont la concurrence était une caractéristique naturelle. D’un
autre côté la concurrence s’exprimait par la possibilité d’exécuter plusieurs processus légers dans les
applications8. Dans ce scénario et de manière générale, deux voies de réalisation de la concurrence
étaient explorées dans l’approche objet : une réalisée par des processus indépendants des objets et
l’autre avec des processus attachés aux objets.
Dans le premier cas, la concurrence est le résultat de l'exécution parallèle des opérations des
objets, dans des processus qui leur sont externes. Les processus n’ont aucun autre rapport avec les
objets. Dans le deuxième cas la concurrence se produit lorsque chaque processus attaché à un objet,
exécute le code de son objet. Cette union de processus et objets est connue comme "objet actif", un
objet avec ses propres capacités d’exécution.
Afin de réduire la dépendance entre objets et d'augmenter la modularité du modèle, le choix
effectué dans ce projet est que seul le processus attaché à l’objet exécute les méthodes de l’objet.
7 Programmation concurrente : exécution simultanée de plusieurs processus.
44
Les objets “ passifs ” classiques sont des unités logiques normalement formées par des
attributs et méthodes, sans aucune liaison avec un processus particulier. Leurs opérations sont
exécutées par des processus qui leur sont extérieurs.
Dans la Figure 5.1 sont représentés un objet passif (a) et un objet actif (b) tels qu'ils sont vus
dans ce projet. On peut constater que, en plus des attributs et des méthodes, l’objet actif contient un
processus.
(a) (b)
méthodes
Processuslié àl’objet
attributs
Figure 5.1. Objet Passif (a) et Actif (b)
Par rapport à l'exécution des méthodes, la figure 5.2 montre la différence entre un objet passif
(a) et un objet actif (b). Dans (a), le code de la méthode est exécuté par un processus externe à l’objet.
En (b) le processus attaché à l’objet actif exécute la méthode.
ProcessuslocalMessageProcessus
externe
(a) (b)
Figure 5.2 Exécution de méthode dans un objet passif (a), et actif (b).
5.1.2 Envois de messages
Les objets d'une application interagissent pour fournir les fonctionnalités attendues. Cette
interaction est une propriété naturelle des systèmes qui se réalise par les messages qu'ils s'échangent,
normalement pour demander un service. Par exemple, dans un ascenseur la pression d'un bouton
d’appel peut demander l'ouverture de la porte. Les objets "bouton" et "porte" sont liés d'une certaine
façon par des appels de l'un et les services de l'autre. C'est à travers des requêtes pour des services que
les objets coopèrent.
8 Les processus légers sont communément connus comme "fils d'exécution" ou "threads".
45
Dans les objets actifs les appels de méthodes ne sont pas directs mais passent par des envois de
messages. C'est une caractéristique importante qui permet une plus grande indépendance entre les
objets et augmente la concurrence. Lorsque l'appel est asynchrone, c’est le processus de l’objet serveur
qui exécute la méthode appelée, permettant au processus appelant de continuer l’exécution de son
code.
La Figure 5.3 montre des processus indépendants exécutant les méthodes des objets passifs.
Lorsqu'une méthode fait un appel à une autre, c’est le thread qui exécute la méthode appelante qui
exécute aussi la méthode appelée. L’exécution de la méthode qui fait l’appel ne peut continuer que
quand l’exécution de la méthode appelée est finie. Dans ce cas, les appels sont synchrones et
séquentiels.
Appel de méthode
Figure 5.3. Concurrence et appel de méthode dans des objets passifs
Dans le cas des objets actifs, illustré dans la Figure 5.4, l'envoi de message se traduit dans
l'objet par des appels de méthodes. Une fois le message reçu par le destinataire le processus local se
charge de son exécution. En cas d'appel asynchrone la méthode appelante peut continuer son
exécution.
Message
Figure 5.4. Concurrence et appel de méthode dans des objets actifs.
5.1.3 Programmation des processus.
Dans le modèle d'objet actif proposé, le processus lié à un objet actif est créé au moment de la
création de l'objet et lui reste attaché pendant toute son existence. Ce processus est habituellement
appelé le "contrôleur" et le code qu'il exécute est appelé le "code de contrôle" de l'objet actif. Il peut
être accessible ou non par les programmeurs. Il
46
Processus inaccessible aux programmeurs.
Les processus inaccessibles aux programmeurs sont comme une tâche de fond des objets. Ils
exécutent normalement un code d'initialisation au moment de la création de l’objet puis restent en
attente des messages envoyés par les autres objets. Le support du système d’exploitation se charge
d’activer le processus quand les messages arrivent et ces derniers sont généralement exécutés dans
l’ordre d’arrivée. Le programmeur ne peut pas intervenir sur l’activité du processus et des problèmes
liés à la concurrence peuvent se présenter. Par exemple l'exécution d'une méthode qui n’est pas
autorisée dans un état particulier de l'objet : dans un objet "pile" la méthode "dépiler" n’est pas
autorisée si la "pile" est vide. Dans une telle situation et selon la notion particulière de message
adoptée, l'appel est perdu ou une erreur est signalée. Une alternative est d'ajouter un code de contrôle
aux objets appelants pour qu'ils s'informent sur l'objet destinataire avant de faire les appels
(programmation par contrat de B. Meyer). Malheureusement cette solution, en plus d’augmenter la
dépendance entre objets et de compliquer le code, n’élimine pas totalement le problème : deux objets
clients appelant la méthode "dépiler" d’un même objet serveur peuvent trouver que la "pile" n'est pas
vide et faire l’appel, mais s’il ne reste qu'un élément dans la pile, l’un d'eux aura des problèmes
(conflit d'accès).
Processus programmable
Lorsque le processus lié à un objet peut être programmé, le modèle d'objet actif acquiert une
puissance remarquable. En plus d’un code d’initialisation, les programmeurs peuvent ajouter des
fonctionnalités aux processus pour résoudre les problèmes de concurrence, de synchronisation, d'état,
etc. En général, le programmeur peut ajouter une grande flexibilité aux objets, particulièrement pour le
traitement des messages.
Le problème mentionné précédemment, peut trouver une solution par la voie de la
programmation du contrôleur. Les messages qui arrivent peuvent être analysés par le contrôleur avant
de lancer toute exécution, ce qui assure une exécution sans problème.
5.1.4 Composants de l'objet actif
Le modèle d’objet actif de base contient le processus auquel il est attaché dès sa création.
Cependant pour augmenter les possibilités de programmation, des éléments additionnels sont souvent
présents. Un de ces composants est une file d’entrée où sont déposés les messages qui arrivent. Grâce
à elle, un message qui n’est pas exécutable au moment où il arrive peut rester dans la file et être
exécuté plus tard. La file d’entrée permet aussi à l’objet appelant de déposer son message et de
continuer son exécution, même si le contrôleur de l’objet destinataire est occupé.
En général lorsque le processus de l'objet actif peut être programmé, les modèles d’objet actif
possèdent comme composants de base un ou plusieurs processus légers, une ou plusieurs files de
messages et un code de contrôle.
47
• Threads : l’objet actif est attaché à un processus ou thread9. Pour augmenter ses capacités
d’exécution, il est aussi possible que l’objet puisse avoir plusieurs threads. Un d’entre eux peut
être destiné aux fonctions de contrôle et les autres à l’exécution de méthodes. Le nombre de
threads et la façon dont les méthodes s'exécutent induisent des différences importantes de
comportement entre les objets actifs.
• File d'entrée : pour recevoir les messages et pouvoir les traiter adéquatement, les objets actifs ont
une file d'entrée où les messages sont déposés par les clients.
• Code de contrôle : pour agir et décider face aux événements tels que l'arrivée d'un message, les
objets actifs doivent posséder un code de contrôle qui s'exécute dans un thread de l'objet. Le
contrôleur est responsable de toute l'activité de l'objet, principalement du traitement des messages.
La Figure 5.5 illustre le cas d'un objet actif avec une file d’entrée, un thread de contrôle et plusieurs
threads additionnels, ainsi que les attributs et méthodes.
File de messages
Threadcontrôleur
threads
attributs
méthodes
Figure 5.5. Composants de base des Objet Actifs
Le modèle d’objet actif choisi, est celui illustré dans la Figure 5.5. Les applications sont
composées uniquement d'objets actifs. Tout objet passif est inclus dans un objet actif, et tout objet actif
peut contenir un ou plusieurs objets passifs (Voir Figure 5.6).
OP
OA
OA OA
OPOP
Application
Figure 5.6. Application composée d’Objets Actifs seulement.
9 Thread désigne un "processus léger" qui contient toutes les données relatives à l'exécution d'un code et qui normalement appartient à un processus. Tous les threads partagent avec leur processus parent le même espace d'adressage.
48
5.1.5 Nombre de threads
La plupart des objets actifs ont un seul processus destiné au contrôle et à l’exécution des
méthodes. Cependant, du moment qu'il est possible de programmer le processus, cela permet
d’attacher plusieurs threads aux objets. Le nombre de threads a une incidence importante sur le
fonctionnement des objets actifs. Avec un seul thread, l'objet ne peut exécuter qu'une méthode à la fois
et le contrôle n’est pas disponible pendant toute l'exécution de la méthode. Le thread ne reprend son
activité de contrôle que quand la méthode est finie. Cette situation n'est pas adaptée pour des
applications qui demandent des réactions et décisions rapides de l'objet. Pendant l'exécution d'une
méthode, l'objet ne peut pas réagir lorsqu’un message plus urgent arrive. Ce message reste dans la file
jusqu'à la fin de la méthode en cours. Cette situation présente aussi un danger de blocage de l'objet si
la méthode en exécution attend une ressource ou une réponse d’un autre objet, ou si elle se trouve dans
une boucle infinie. En plus, si les threads de tous les objets sont bloqués en attente d'événements, les
appels non traités restent en attente et le temps processeur est sous utilisé.
Une solution à ces problèmes est d'avoir plusieurs threads dans chaque objet actif, ce qui est
de plus intéressant par la souplesse d'exécution apportée. Dans les objets, un des threads peut être
dédié en permanence à l'exécution du code du contrôleur, et les autres à l'exécution des méthodes. De
cette manière, le contrôleur peut toujours réagir aux événements tels que l'arrivée d'un nouveau
message ou le blocage d'une méthode. En contrepartie de nouveaux problèmes surgissent en particulier
la nécessité du contrôle de la concurrence à l'intérieur des objets.
Il y a une ressemblance entre le Système d'Exploitation qui contrôle les processus et les
applications, et l'objet actif qui contrôle ses processus légers et ses méthodes. Le contrôleur des objets
actifs peut être considéré comme un petit système d'exploitation à l'intérieur de l'objet qui se charge de
contrôler son activité.
Note : un nombre trop grand de threads n’est pas souhaitable car dans les systèmes
d’exploitation multithread le temps consommé par la commutation entre threads est important.
5.1.6 Création des threads
Dans un modèle d’objet actif avec plusieurs threads, la création des threads pourrait se faire au
fur et à mesure qu’ils sont nécessaires, c'est à dire, à chaque fois qu’un message est prêt pour
l'exécution. Il faut noter que la création et destruction de thread prend un temps non négligeable et,
généralement non connu ni contrôlé avec précision. Cet aspect est particulièrement important si la
prédiction du temps est fondamentale. Une façon classique de réduire l'incertitude relative au temps
pendant l'exécution est de faire la création de tous les composants de l'application, y compris les
threads des objets, dès le début de l'exécution. Le comportement de l'objet ne deviendra prédictif
qu'après la fin de cette création.
49
Pour les besoins de prédictibilité de ce projet, le choix qui plus convient est d'avoir plusieurs
threads par objet qui tous sont créés au moment de la création de l'objet. De toute façon il est toujours
possible considérer la création de nouveaux threads pendant l’exécution, si nécessaire.
5.1.7 Concurrence
Lorsque chaque objet exécute ses opérations une par une, on parle d’objets séquentiels et la
seule concurrence possible se produit entre objets (concurrence inter-objet, voir Figure 5.7 a). Lorsqu'à
l'intérieur des objets plusieurs exécutions simultanées sont possibles, il s’agit de concurrence intra-
objet et deux types sont identifiés. Dans le premier type, appelé objets quasi-concurrents, deux ou
plusieurs méthodes partagent un même thread d’exécution et s'exécutent en commutant le thread d'une
méthode à l'autre (voir l'objet (b1) de la Figure 5.7). Dans le deuxième type, appelé simplement objets
concurrents, plusieurs méthodes peuvent s'exécuter simultanément, avec un thread d'exécution propre
pour chacune d'elles. L'objet (b2) de la figure 5.7, illustre ce type d'objet.
Objets séquentiels
(a) concurrence inter objets (b) concurrence intra objets
Objet quasi concurrent Objet concurrent
(b1) (b2)
Figure 5.7. Types de Concurrence et d’objets.
Note : il faut considérer que dans un système informatique mono processeur, la concurrence
est toujours virtuelle. Le processeur n'exécute qu'un seul thread à la fois, mais les services du système
d'exploitation permettent l'avancement de l'exécution de plusieurs threads.
5.2 Contrôle des objets actifs
5.2.1 Contrôle de la concurrence
La concurrence d'exécution de méthodes à l'intérieur des objets offre plusieurs avantages.
D'abord elle donne du modèle objet une vision plus proche de la façon d'agir des objets du monde réel.
D'un autre côté elle permet d'augmenter l'utilisation des ressources (processeur). Néanmoins, un
contrôle est nécessaire pour assurer l'intégrité des objets et de l'application. Par exemple, il faut un
contrôle pour l'accès aux données partagées, afin d'éviter les possibles incohérences dues aux
interférences entre les exécutions.
50
5.2.2 Contrôle intra-objet
Comme les demandes de service des clients sont les événements à l’origine de l’exécution des
méthodes, le contrôle de la concurrence par les objets clients est possible à l'extérieur de l'objet
concerné. Deux types de contrôle intra-objet ont été identifiés : un contrôle externe et un autre interne.
Par rapport aux langages de programmation, deux possibilités de contrôle de concurrence ont été
identifiées [Guerraoui95] : si l'utilisateur peut programmer le contrôle intra objet entièrement il est
explicite, sinon il est implicite.
Lorsque les clients doivent se synchroniser avant de faire un appel à une méthode, il s'agit d'un
contrôle explicite externe (Figure 5.8 (a)). Si le contrôle est programmé à l’intérieur de l'objet serveur,
alors il s'agit d'un contrôle explicite interne (Figure 5.8 (b)).
synchronisation
Objets clients
Objet serveur
synchronisation
Objets clients
Objet serveur(a) contrôle externe (b) contrôle interne
Figure 5.8. Contrôle explicite externe et interne.
En considérant que par principe chaque objet est responsable de l’intégrité de ses données et
qu’elles ne sont modifiées que par les méthodes de l’objet, le contrôle qui convient le mieux est le
contrôle à l’intérieur de l’objet. En plus, un contrôle par les clients augmente la dépendance entre
objets car il faut pour cela qu'ils se connaissent. Le modèle retenu pour ce projet est un contrôle de la
concurrence intra-objet interne et explicite effectué par le contrôleur.
5.2.3 Contrôle inter objet
Un contrôle de la compatibilité entre méthodes d'objets différents ne semble pas nécessaire vu
que les objets ne partagent pas de données. En plus, comme toute interaction entre objets est faite par
envoi de message, si deux objets veulent accéder à une donnée commune chacun envoie un message à
l’objet qui contient la donnée et contrôle son accès.
5.2.4 Contraintes d’état
Lorsqu’un objet a des états, un contrôle est nécessaire afin d’assurer à tout moment son
intégrité. Le contrôleur doit assurer que les contraintes liées aux états sont toujours respectées. Pour
cela il faut une représentation des états, ainsi qu'une manière de calculer le nouvel état à chaque fois
51
qu’une transition pouvant modifier l’état est exécutée. Aussi, il est nécessaire de connaître la relation
entre messages et états, puisque le contrôleur doit choisir les messages de la file d’entrée en fonction
de leur validité dans l’état courant. Par exemple, si l'état courant d'un objet “ pile ” est “ vide ”, les
messages se traduisant par un appel à la méthode “ get ” ne doivent pas être choisis.
Un problème à prendre en compte dans le contrôle des états est celui de l'exécution
concurrente de deux ou plusieurs méthodes. Le nouvel état doit être calculé quand toutes les méthodes
pouvant modifier l’état sont terminées. Même si pendant l'exécution les méthodes modifient des
variables qui définissent l’état donc en fait l'état, le nouvel état courant ne sera déterminé et visible
qu'à la fin de la dernière méthode pouvant modifier l'état. Evidement, ce cas est très particulier et il ne
faut l'utiliser qu'avec précaution s'il n'y a pas d'interférences possibles entre les méthodes.
Le choix retenu est de tester la validité de l'exécution des méthodes, avant de les lancer. Deux
types de test sont prévus : le test de validité dans l'état courant de l'objet, et le test de compatibilité
avec les méthodes en cours d'exécution.
5.2.5 Communication entre objets
Il a été déjà mentionné que l'interaction entre objets actifs est réalisée par l'envoi de messages,
lesquels normalement portent une demande de réalisation d'un service. Le destinataire décide de la
manière de réaliser le service demandé, ce qui normalement se concrétise par l'exécution d'une ou
plusieurs méthodes de l'objet.
Un message reçu peut être accepté ou non par le serveur. Etre accepté signifie que le message
sera traité. S'il n'est pas accepté, plusieurs alternatives existent :
a) le client peut être averti d'une erreur,
b) le message peut rester dans la file d'entrée jusqu'à ce qu'il soit accepté,
c) ou simplement le message peut être ignoré et éliminé par le serveur.
Les raisons pour lesquelles un message n’est pas accepté sont diverses. Par exemple, quand
l'état de l'objet n'autorise pas le message ou si le message n'est pas compatible avec les messages en
cours d'exécution. Aussi, lorsque les threads de l’objet sont tous occupés, un message qui arrive ne
peut pas être exécuté.
5.2.6 Synchronisation des appels
Lorsqu'une méthode a besoin d’un résultat ou d'une réponse provenant d’une autre méthode, il
est nécessaire d'avoir un mécanisme de synchronisation. Deux principaux types de relation peuvent se
distinguer dans une communication entre objets, selon le type de synchronisation établi. La
synchronisation est dite de type synchrone ou asynchrone, selon que l'objet client attend ou non la fin
de l'exécution du service demandé pour continuer l'exécution de son propre code. Dans le modèle
52
d'objets séquentiels, le mode de communication est synchrone seulement, parce que le code de la
méthode appelée est exécuté par le même thread que celui qui exécute la méthode d'appel. Cette
dernière s'interrompt pendant l’exécution de la méthode appelée. Par contre, le modèle d'objet actif
permet une communication asynchrone dans laquelle l’exécution d’une méthode ne s’arrête pas quand
elle fait une requête. Une fois qu'elle a envoyé le message au destinataire, elle peut continuer son
exécution. En cas de besoin d’une réponse provenant d'une méthode appelée, la méthode appelante se
mettra en attente seulement si, au moment de l’utiliser, la réponse n’est pas encore prête. Si le langage
de programmation se charge du contrôle, aucun code supplémentaire est nécessaire pour la
synchronisation. Dans le cas contraire, le programmeur doit introduire le code de contrôle à l’endroit
approprié.
La figure 5.9 montre les deux types de communication synchrone et asynchrone. Dans le
premier cas, figure 5.9 (a), l’exécution du code de la méthode appelante continue seulement quand la
méthode appelée a fini.
invocation
réponse
attente
Objetclient Objetserveur
(a) synchrone
continuation
(b) synchrone sur démande
invocation
réponse
attente
Objetclient Objetserveur
continuation
Figure 5.9. Communication synchrone et synchrone avec attente par nécessité
Pour les buts de ce projet la préférence est à une communication de type asynchrone. Toute
synchronisation nécessaire sera introduite juste avant l'utilisation de la réponse (attente par nécessité,
[Caromel89]).
5.3 Bénéfice du modèle d’objet actif
Les objets actifs apportent des bénéfices au développement des applications orientées objet,
provenant particulièrement de l’augmentation de l'indépendance, de la modularité, et des possibilités
d'exécution en parallèle. Cela permet, entre autres, une meilleure modélisation des objets du monde
réel car la concurrence d'activités est une de ses caractéristiques naturelles, une meilleure utilisation
des ressources de calcul (si un processus attend, un autre peut continuer son exécution), une meilleure
capacité pour gérer la complexité des systèmes (en raison d'une plus grande modularité et de
l'indépendance). Par contre, un contrôle plus exigeant est nécessaire pour maintenir l'intégrité des
objets, particulièrement l'accès concurrent aux données et l'acceptation de messages selon l'état.
Les objets actifs sont une extension au modèle objet classique. Ils sont liés à un processus dès
sa création, ce qui leur donne des capacités d’exécution propres. Ils ont besoin d'un code de contrôle
pour décider de leurs activités, pour la sélection et le traitement des messages, pour assurer l’intégrité
des données et pour assurer le respect des contraintes (concurrence, état, etc.).
53
Les communications entre objets se réalisent par l'envoi de messages. Chaque objet doit avoir
une file d’entrée pour les messages reçus en provenance des objets clients.
Dans une application fondée sur des objets actifs, il existe une concurrence d’exécution de
méthodes d'objets différents (inter-objet). Quand l'objet a plusieurs threads, il est aussi possible d'avoir
une concurrence des méthodes à l'intérieur d’un même objet (intra-objet). Ce dernier cas demande un
contrôle sur l’accès simultané aux données.
Les communications entre objets peuvent être de types synchrones ou asynchrones. Une
variante de type synchrone est la continuation de l'exécution de la méthode appelante jusqu’au
moment où la réponse attendue de la méthode appelée soit utilisée.
Pour les objets à états, un contrôle est nécessaire pour vérifier la validité des messages en
fonction de l’état courant.
Les caractéristiques principales retenues pour le modèle d’objet actif de ce projet peuvent se
résumer ainsi :
• Une application est composée d'objets actifs seulement. Tout objet passif est inclus dans un
objet actif, et tout objet actif peut contenir un ou plusieurs objets passifs.
• Les objets actifs peuvent contenir plusieurs threads d’exécution, tous créés au moment de la
création de l’objet.
• L'exécution des méthodes est faite dans les threads de l’objet seulement.
• La sélection des messages est faite par le contrôleur et selon des critères définis par le
serveur.
• Le contrôle des contraintes est fait à l’intérieur de l’objet par le code du contrôleur.
L'intégrité des données est assurée par le contrôle de compatibilité entre méthodes. Pour les
objets à états, un contrôle de validité de messages selon l’état courant de l’objet est effectué.
• La communication entre objets se fait par messages de type asynchrone. En cas de
synchronisation, il sera introduit une attente juste avant que la réponse attendue soit utilisée.
5.4 Modèles d'Objet Actif pour le temps réel.
Trois modèles objet temps réel qui présentent des caractéristiques intéressantes relatives à ce
travail sont maintenant décrits.
5.4.1 ACCORD
Le projet ACCORD [Terrier96] fournit un atelier orienté objet pour le développement
d'applications temps réel. ACCORD offre deux fonctions principales :
a) la modélisation du comportement temps-réel, et
b) la génération automatique de code.
54
Le modèle objet d'ACCORD est TOM, un modèle objet pour le temps réel (real Time Object
Model). TOM est une extension du modèle d'objet actif avec les éléments suivants :
a) Une interface qui spécifie les messages acceptés par un objet.
b) Une boite à lettres où les messages reçus attendent leur traitement.
c) Un mécanisme de contrôle de concurrence local, qui assure la cohérence des attributs
internes de l'objet.
Le model TOM a les propriétés suivantes:
a) Les contraintes de concurrence intra-objet seulement sont traitées.
b) Les contraintes temporelles sont définies par l'objet appelant et ajoutées à chaque message.
c) La communication par messages peut être asynchrone et synchrone.
d) Les contraintes entre objets ne sont pas considérées.
e) Chaque message est exécuté dans son propre thread lequel est créé dynamiquement pour
chaque message.
f) Des boites de réception de réponse sont créées lors de l'envoi de message si les méthodes
appelantes attendent une réponse.
L'architecture générale d'une application ACCORD consiste en :
a) un ensemble d'objets temps réel
b) un ensemble d'objets passifs (utilisés par les objets temps réel)
c) un contrôleur global (ajouté à chaque application) chargé de la gestion des ressources.
Chaque objet possède un contrôleur local (localControler) qui s'exécute dans un thread
indépendant, et qui se charge de :
a) la gestion de la boite à messages
b) la création et destruction des threads pour l'exécution de messages
c) la gestion des contraintes de concurrence.
Un objet temps-réel peut être vu comme un serveur de tâches communiquant avec les autres
objets par l'envoi de messages, et gérant les contraintes attachées à leurs traitements.
Le Noyau ACCORD a été construit pour fournir un support opérationnel aux applications. Il
permet entre autres :
55
a) la communication et synchronisations entre objets
b) le contrôle d'accès interne aux données (contrôle de concurrence interne des objets)
c) le transfert de messages entre objets distants, et
d) l'ordonnancement global des exécutions des messages
Au niveau de chaque objet temps-réel, le Noyau ACCORD fournit les réalisations génériques
des éléments tels que :
a) la boîte à lettres contenant les messages reçus et leurs contraintes
b) le contrôle de l'état de l'objet et le contrôle de concurrence entre ses méthodes
c) la gestion et l'ordonnancement dynamique du traitement de messages
ACCORD s'est d'abord fondé sur la méthode Class-Relation [Desfray94, Desfray96] pour la
modélisation d'une application mais il utilise UML dans ses dernières versions. Il utilise trois
modèles : structurel, opérationnel et dynamique. La modélisation est résumée dans les étapes
suivantes :
a) L'utilisateur définit le modèle structurel de l'application en spécifiant les classes et leurs
relations. Puis, les classes associées à des objets temps-réel sont sélectionnées.
b) par le modèle opérationnel l'utilisateur spécifie les conditions d'utilisation des objets. Par
exemple, il définit les invariants de classe, les conditions avant et après exécution des
méthodes, et l'automate de la classe. Cette dernière établit la relation entre les méthodes et les
états de l'objet où elles sont autorisées.
c) Finalement, la spécification du lancement de tâches et ses contraintes temps réels se fait à
l'aide du modèle dynamique, par les automates de déclenchement de la méthode Classe-
Relation étendus au temps-réel. D'un autre côté, l'automate de contrôle définit le traitement des
messages reçus par l'objet et son comportement une fois que le message a été traité.
5.4.1.1 L'état de l'objet
Dans ACCORD l'état de l'objet est défini comme un n-uplet composé des valeurs des attributs
de l'objet. Un état particulier est visible de l'extérieur seulement lorsque nulle méthode pouvant le
modifier est en exécution. Cette notion d'état permet de définir le comportement des objets en
spécifiant les méthodes interdites en fonction des états de l'objet, ce qui définit les contraintes d'état.
ACCORD ne permet pas l'exécution simultanée de deux méthodes pouvant modifier l'état.
Cependant les méthodes qui s'exécutent simultanément peuvent avoir accès aux même attributs de
l'objet, ce qui oblige à prendre en compte des contraintes de concurrence.
56
Pour le contrôle des contraintes d'état et de concurrence, deux contrôleurs ont été conçus : un
pour la gestion des états et l'autre pour le contrôle de la concurrence.
5.4.1.2 Communication entre objets
La communication entre objets est faite par envoi de messages asynchrones. Cependant,
lorsqu'une réponse est attendue par l'objet client, il envoie le nom d'une boîte où le serveur doit
déposer la réponse. La boîte à réponse est créée par l'objet client lorsqu'il envoie un message et qu'une
réponse est attendue. Le client continue son exécution jusqu'à ce qu'il ait besoin de la réponse. Si elle
est déjà prête, le client la prend et continue son exécution, sinon il l'attend. Ce type de synchronisation
est appelé "envoi de message synchrone retardé" (Delayed Synchronous Message Passing) ou "attente
par nécessité" [Caromel89]. D'autres schémas de synchronisation sont aussi possibles, par exemple
lorsque le client a besoin de connaître le début ou la fin d'une exécution.
5.4.1.3 Contrôle de concurrence
Dans ACCORD les objets contrôlent l'accès concurrent aux attributs par leurs méthodes. Les
contraintes de concurrence sont définies dans les classes des objets en précisant si une méthode accède
à un attribut et dans quel mode (pour lire ou pour écrire). De cette manière les objets temps réel sont
perçus comme un ensemble de ressources (attributs) partagées par les méthodes.
5.4.1.4 Ordonnancement
L'ordonnancement d'ACCORD est de type dynamique sans connaissance a priori du temps de
traitement des messages ni de leur date d'arrivée. C'est le contrôleur global qui choisit le prochain
message à exécuter, parmi tous les messages de l'application que les contrôleurs locaux ont choisi pour
exécution. Le contrôleur analyse les contraintes de temps des messages et choisit celui avec la date
d'échéance la plus proche (ordonnancement EDF).
Par sa part, le contrôleur local analyse le message reçu et si son exécution est permise
(contraintes d'état et de concurrence), il informe le contrôleur global sur les contraintes temporelles du
message et lui demande de l'ordonnancer. Lorsque le contrôleur global décide l'exécution du message,
il le communique au contrôleur local, lequel attache un thread au message et démarre son exécution.
Pour les tâches périodiques, le contrôleur local demande périodiquement leur exécution au
contrôleur global, selon les contraintes de période portées dans les messages.
57
La figure 5.10 montre les principaux composants du modèle objet d'ACCORD, et comment ils
sont reliés pour l'exécution de messages.
Contraintes de concurrence
Contrôleur local
attributsmethA()
methB()
Boite à lettre
Exécution et fin planning
management
Contrôleur global
Thread2
Thread3 Thread1
methC()
Objet temps réel
mess 123
mess 3
mess 2
mess 1
methC()
Autresobjetstempsréel
Figure 5.10. Objet temps réel et Contrôleur global d’ACCORD.
Dans le cas où un message ne peut être traité dans l'état courant, l'objet doit décider de : a)
laisser le message en attente, b) rejeter le message immédiatement, ou c) abandonner le message avec
renvoi éventuel de valeurs par défaut.
ACCORD effectue un ordonnancement basé sur l'algorithme EDF avec propagation
dynamique des échéances. La répartition des objets temps-réel dans plusieurs espaces d'adressage est
mise en œuvre par des objets "proxy" qui définissent une image virtuelle des objets distants utilisés par
les objets de l'espace d'adressage courant.
5.4.2 DRO
DRO (Distributed Real-Time Object) [Takashio92] est un modèle d'objet actif étendu pour les
applications temps réel dans des systèmes distribués. Sa réalisation se base sur une architecture à meta
niveaux, où les méta-objets sont explicitement séparés des objets du niveau de base. Les méta-objets
offrent un environnement d'exécution aux objets de base et définissent la sémantique de l'exécution.
En modifiant les définitions dans les méta-objets, il est possible changer la sémantique du traitement
des objets de base. Les objets actifs de DRO ont un seul thread.
Un des objectifs importants dans la conception de DRO fut l'introduction des propriétés
meilleur effort (best effort) et souffrance minimale (least suffering) dans le comportement des objets.
L'intérêt pour cette idée vient du fait que dans les systèmes distribués : a) il est impossible de supposer
l'existence d'une horloge globale, b) le temps pris par les communications ne peut être borné, et c) il
est difficile connaître le temps alloué au traitement dans le serveur. D'un autre coté, les notifications
58
envoyées par un serveur au client, telles que "refusé" ou "avorté", n'arrivent pas nécessairement à
temps, en plus elles peuvent ne jamais arriver, ce qui provoque des fautes temporelles. Les dégâts sont
pires lorsque plusieurs appels sont enchaînés.
Le principe du meilleur effort consiste en une politique d'ordonnancement des tâches dans
laquelle le serveur et le client font au mieux pour que le service demandé soit réalisé dans le temps
disponible. Cela demande au client et au serveur de coopérer pour que les échéances des services
soient respectées.
La souffrance minimale signifie que le client fait au mieux pour maintenir ses opérations et
minimiser les conséquences négatives lorsqu'un service demandé n'aboutit pas. Pour cela, le client doit
être muni d'un mécanisme pour détecter les erreurs temporelles selon son propre critère de jugement.
5.4.2.1 Traitement de messages
Le traitement des messages est fait par le contrôleur dans chaque objet. Il analyse la queue de
messages reçus et construit un ensemble des méthodes permises dans l'état courant. Puis il choisit un
message et démarre son exécution dans le thread de l'objet. Quand l'exécution est finie, le serveur
répète l'opération pour exécuter un autre message.
Dans DRO le comportement générique des objets est modélisé comme une machine à états
finis, appelée automate abstrait d'objet (abstract object automaton), qui change d'état selon les
résultats d'exécution des messages. Les trois séquences d'actions possibles, suivies du traitement des
messages, sont :
a) reçu - accepté - refusé (received-accepted-rejected)
b) reçu - accepté - exécuté - avorté (received-accepted-executed-aborted)
c) reçu - accepté - exécuté - terminé (received-accepted-executed-commited)
• Reçu signifie que le message du client est dans la queue de messages du serveur.
• Accepté signifie que le serveur a lancé l'exécution de la méthode correspondant au message.
• Refusé est la situation où le serveur considère impossible la réalisation du service dans le temps
requis, ou que l'échéance est arrivée pendant que le message était dans la queue.
• Terminé signifie que l'exécution de la méthode a fini normalement.
• Avorté signifie que la date de deadline est arrivée pendant l'exécution de la méthode.
5.4.2.2 Communication entre objets
Les messages entre objets incluent des contraintes de temps. Dans une requête, les clients
expriment des services alternatifs à exécuter selon le temps disponible dans le serveur. Par exemple,
59
pour un service avec 3 méthodes alternatives, m1, m2 et m3, de temps d'exécutions t1, t2 et t3, le client
fait un appel en spécifiant :
"Si la requête est acceptée, alors si Tr>t1, alors exécute m1 ; sinon si Tr>t2, alors exécute m2 ;
sinon si Tr>t3, alors exécute m3 ; finalement si Tr<t3, alors refuse cette requête"
Tr est le temps disponible pour l'exécution dans le serveur.
Ce type d'appel est appelé invocation polymorphe en temps (time polymorphic invocation)
[Takashio93], et est défini comme:
"AnObjet {T1:<opr1>; …; Tn :<oprn>} (T1 > T2 > … > Tn)"
Avec Ti (i=1, ..., n) sont les contraintes de temps spécifiés par le client pour chaque opération
(méthode) opri
Avec l'information temporelle portée par le message, le serveur choisit la première méthode de
la liste pour laquelle la contrainte de temps peut être satisfaite. Comme normalement la qualité du
résultat d'une méthode est meilleure si la durée est plus grande, la plus grande qualité possible sera
fournie.
Dans le serveur, les méthodes sont caractérisées par leurs temps d'exécution au pire (WCET),
et sont appelées méthodes avec contrainte de temps. Le temps WCET est utilisé pour décider si une
méthode peut être finie ou pas dans le temps disponible. Une routine d'exception est spécifiée pour
chaque méthode avec contraintes de temps qui est déclenchée en cas ou le temps WCET n'est pas
respecté.
5.4.2.3 Le protocole de communication
L'utilisateur construit un protocole de communication fondé sur les primitives envoie/reçoit
(send/receive) de l'envoi de messages asynchrone. Le protocole est défini par un diagramme d'états et
transitions, où les états correspondent aux abstractions des conditions d'exécutions, et où les actions
sont les messages primitifs d'échange. Ces derniers sont les événements qui s'échangent dans la
communication entre deux objets et les accusés de réception correspondants.
5.4.2.4 Meilleur effort et souffrance minimale.
La coopération entre objets que se concrétise par les invocations polymorphes en temps et par
les méthodes avec contraintes de temps, permet au modèle DRO de satisfaire la propriété de meilleur
effort (best effort). La propriété de souffrance minimale (least suffering) est obtenue par le fait que le
60
client connaît la contrainte de temps la plus grande (T1) dans la requête et peut réagir si la réponse
attendue n'arrive pas à temps.
5.4.2.5 Objets du Meta niveau
Le modèle DRO sépare les objets du meta niveau des objets du niveau de base. Les objets du
meta niveau offrent un contexte d'exécution pour les objets de base et définissent la sémantique de
l'exécution. Les meta objets gèrent les ensembles de méthodes permis et le contrôle du protocole (en
incluant la gestion des contraintes de temps). Pour cela, DRO introduit deux meta objets : le
AbstractStateMeta, qui se charge des ensembles de méthodes permises, et le ProtocolMeta qui définit
et contrôle les protocoles (ASMeta et PMeta respectivement, dans la figure 5.11).
Objet de Base
PWPMeta
Niveau Objet
Niveau Meta
PMeta
Objet de Base
PW
ASMeta
Niveau Objet
Niveau Meta
(a) Client DRO (b) Serveur DRO
Figure 5.11. Structure des objets DRO
La figure 5.11, montre les objets du modèle DRO, et ses relations :
a) L'Objet de Base. C'est un objet actif, avec thread d'exécution, attributs locaux et méthodes. Cet
objet exécute la méthode correspondant au message accepté pour exécution. Cette exécution et les
communications entre objets sont contrôlées par les méta-objets. L'Objet de Base demande à
Pmeta un appel de service ou une réception de réponse (droInvoke(), droReceive()).
b) L'objet ProtocolMeta (PMeta). C'est le méta-objet qui donne la sémantique aux communications
entre objets. Il crée un objet ProtocolWorker (PW) pour chaque message qu'il envoie. Dans le
ProtocolMeta, un objet de base est représenté par son état d'exécution.
c) L'objet AbstractStateMeta (ASMeta). C'est le méta-objet qui gère la queue de messages et
l'ensemble des méthodes permises en se fondant sur l'automate de l'objet (abstract object
automaton). Il contrôle aussi l'activation des objets PW créés par Pmeta pour chaque message
reçu. Dans l'ASMeta l'objet de base est représenté par son acceptation de message et son exécution.
61
d) L'objet Protocol Worker (PW), est un objet du niveau meta, créée par le méta-objet ProtocolMeta
chaque fois que l'objet fait une requête. Il se charge du contrôle du protocole de la requête et prend
en compte ses contraintes temporelles. Quand PW reçoit une réponse, il la passe à l'Objet de Base
(droReply(), droAck(), droAborted(), droTimeout()). Du coté du serveur, les PW sont créés pour
chaque message reçu, et ils prennent en compte leurs contraintes temporelles.
5.4.3 ROOM et UML for Real-Time.
ROOM (Real-Time Objet Oriented Modeling) est une méthodologie orientée objet développée
par ObjectTime Limited au début des années 90 pour le développement de systèmes temps réel
[Selic92]. ROOM utilise un langage visuel de modélisation avec une sémantique formelle qui permet
la spécification, la visualisation, la documentation et l'automatisation de la construction de systèmes
temps réel, pilotés par événements et potentiellement distribués. Les éléments de base du langage
ROOM sont les acteurs, les ports et les connecteurs (en anglais : actor, port et connectors
respectivement). Les modèles ROOM sont construits avec ces trois éléments plus la description des
comportements des acteurs et leurs interconnexions.
5.4.3.1 Objets Actifs de ROOM
Le principal élément structurel de ROOM est l'acteur, un objet actif responsable d'une
fonction spécifique du système modélisé et qui peut opérer en parallèle avec les autres acteurs. Ils
communiquent à travers des objets d'interface appelés ports qui servent d'intermédiaires entre les
acteurs et leur environnement. De cette manière les acteurs sont indépendants de leur environnement,
permettant l'utilisation d'une même spécification d'acteur dans différents contextes. Les composants de
base de ROOM sont illustrés dans la Figure 5.12.
message
message ports
Acteur Figure 5.12. Acteur, ports et messages dans ROOM.
5.4.3.2 Communication en ROOM
Les acteurs communiquent par envoi de messages synchrones ou asynchrones. Les messages
sont des objets qui sont communiqués entre acteurs à travers les ports. Un événement est signalé
lorsqu'un message arrive à un objet.
62
La collaboration entre acteurs doit respecter une séquence ordonnée de requêtes et réponses
appelée protocole. Dans un protocole, chaque message consiste en un signal nommé (named signal) et
optionnellement un objet passif (donnée) qui spécifie une ou plusieurs valeurs de paramètres. Chaque
port est un objet qui représente une interface particulière de l'acteur. Les ports sont réalisés comme des
instances de la classe protocole (protocol class), ce qui permet l'utilisation d'une même spécification
de protocole par plusieurs acteurs.
5.4.3.3 Modèles ROOM
Lorsque les acteurs implémentent des fonctionnalités complexes, ils peuvent être décomposés
en fonction d'autres acteurs, chacun responsable d'un sous-ensemble de la fonctionnalité totale. Pour
cela ROOM fournit trois mécanismes de composition appelés binding, layer connection et
containment.
• Binding : sert à modéliser un canal de communication connectant deux ports. Seulement les ports
avec protocoles qui se correspondent peuvent être liés.
• Layer connection : ce sont des relations directes entre acteurs qui ont une relation de dépendance
asymétrique. Par exemple dans une relation client/serveur, le client ne fonctionne pas sans le
serveur, tandis que le serveur fonctionne indépendamment du client. La liaison entre niveaux
(layers) se fait dans des points précis appelés points d'accès au service (service access points,
SAP) du côté client, et points de fourniture de services (service provision points, SPP) du côté des
serveurs. Comme les ports, les SAPs et les SPPs sont des instances de classes de protocole.
• Containment : c'est le mécanisme par lequel les acteurs sont décomposés et exprimés par des
acteurs plus élémentaires.
La figure 5.13 illustre un système informatique composé de 4 acteurs : ordinateur, imprimante,
modem et souris. Ils sont interconnectés à travers des "bindings". Les ports que les bindings
connectent, (parallèle et LPT1, COMX et serial), opèrent avec protocoles compatibles.
ordinateurimprimante
souris
modem
COM1
COM2
LPT1
serial
serial
parallèle
Figure 5.13. Connections entre acteurs.
63
La figure 5.14 montre l'acteur "ordinateur" décomposé en deux acteurs : "Carte Mère" et
"Carte IDE" connectés comme indiqué pour fournir les fonctionnalités de "ordinateur". La
décomposition peut continuer ensuite en détaillant les composants de "Carte Mère" et "Carte IDE".
La configuration des layer connections et des bindings qui lient les acteurs définit l'ensemble
complet des communications et des relations possibles entre les acteurs d'un système. Cet aspect de
l'architecture identifie explicitement tous les liens de causalité potentielle entre les acteurs.
Le niveau le plus bas de décomposition est appelé machine virtuelle ROOM (ROOM virtual
machine). Il est implémenté par la couche virtuelle du système d'exécution de ObjectTime (ObjecTime
run-time system). La machine virtuelle ROOM fournit des services de communication, de temps avec
des alarmes (timers), de création de threads avec modification de leur priorité.
Carte IDE
COM1
COM2LPT1LPT1
COM1
COM2
Carte mère
BUSs
BUSc
ordinateur
Figure 5.14. Composition d'un acteur.
5.4.3.4 Modélisation du comportement
Pour la modélisation du comportement des acteurs ROOM utilise une variante des machines à
états finis hiérarchiques [Harel87] appelée ROOMcharts. Un événement est déclenché par l'arrivée
d'un message à un port d'un acteur. Selon l'état actuel de l'acteur, le type de signal porté par le
message, et le port par lequel il arrive, l'événement déclenche une transition.
Le traitement des événements est de type exécution totale (run-to-completion10) donc les
messages sont exécutés sans préemption. Cette politique d'exécution oblige les autres messages à
attendre dans une queue pendant qu'un message est en exécution.
Un avantage de cette approche est qu'il n'est pas nécessaire d'avoir des mécanismes de
contrôle de concurrence interne pour le traitement des événements, ce qui simplifie la spécification du
comportement. Par contre, un problème important est l'impossibilité de traiter un message qui arrive
plus tard mais qui doit être exécuté avant celui qui est en cours d'exécution. Ce type de situation
pourrait être évité avec un traitement de message préemptif.
10 Run-to-completion, exécution sans préemption. Un message doit finir son exécution avant que l'exécution du prochain message commence.
64
Dans les ROOMcharts, un état peut être lui-même composé d'une machine à états, ce qui
permet plusieurs niveaux d'abstraction.
La séquence de programme (Detail Level) associée à chaque transition spécifie les actions à
réaliser pendant la transition, telles que l'envoi de messages ou une liste d'instructions.
UML for Real-Time
"UML for Real-Time" (UML-RT) est `la version UML [OMG97] de ROOM dont elle
conserve les concepts.
Les principaux composants de UML-RT sont la Capsule, le Port et le Connector. Ces sont des
stéréotypes11 UML spécifiquement définis pour supporter ROOM.
La Capsule UML correspond à l'acteur de ROOM. Comme dans les acteurs, les capsules sont
des objets actifs qui interagissent avec leur environnement à travers un ou plusieurs ports (Voir figure
5.15 ). La composition structurelle des Capsules est décrite par des diagrammes de collaboration UML
[OMG97].
C
Comme le po
Capsule et son enviro
mécanismes permettan
un rôle particulier. Ell
à l'interface d'une autr
Les connecteu
identifient la relation c
Les fonctions
associées. Des capsule
permettant ainsi la mo
11 Stéréotype est un des modélisation en étendan
apsule
Sous-Capsule
Connecteur
Ports
C1 C2
C3
A
Figure 5.15. Eléments de l'UML for Real-Time.
rt de ROOM, le port UML-RT est un objet qui sert d'intermédiaire entre une
nnement et qui implémente un protocole spécifique. Les ports fournissent des
t aux Capsules d'exporter de multiple interfaces différentes, chacune dédiée à
es fournissent aussi des mécanismes pour connecter une interface d'une Capsule
e.
rs capturent les relations de communication entre les ports des Capsules. Ils
ausale entre capsules connectées directement.
des capsules sont réalisées par des machines à état auxquelles elles sont
s peuvent être construites par la combinaison de sous-capsules qui collaborent,
délisation de structures plus complexes (Voir figure 5.15).
mécanismes d'extension du langage UML qui permet définir des nouveaux éléments de t la sémantique du metamodèle.
65
Le principal avantage de UML-RT est la possibilité d'utiliser le formalisme du langage UML
pour la modélisation de systèmes. De nombreux fournisseurs de logiciels offrent des outils de
développement fondés sur UML. Ces environnements facilitent la conception et le test des systèmes.
66
6 Architectures Réfléchies à Meta niveaux
Cette section présente les concepts de base de la "réflexion" et des architectures à méta
niveaux. L'architecture d'ARTO est inspirée des idées présentées ci-dessous. D'un côté l'idée d'adapter
le comportement face à l'imprévu à travers un acte de réflexion, et d'un autre côté la séparation claire
apportée par les architectures à méta niveaux permettant de séparer les aspects liés au domaine du
problème de l'utilisateur des aspects liés au contexte d'exécution (concurrence, sécurité, qualité de
service, etc.). Ces deux idées sont des parties importantes dans la conception de l'architecture d'ARTO.
6.1 Architectures Réfléchies
En termes généraux, la réflexion est le processus par lequel un système raisonne et agit sur lui-
même. Dans les systèmes informatiques conventionnels les opérations sont réalisées sur des données
qui représentent des entités existant à l'extérieur du système. Par contre, dans un système réfléchi les
données qui représentent les propres aspects structurels et de calcul du système sont aussi accessibles
et il peut agir sur ces représentations.
Dans le domaine de l'informatique la réflexion est un sujet intéressant par la possibilité qu'elle
offre pour la construction d'applications flexibles et auto modifiables. Par exemple, pendant son
exécution un programme pourrait modifier les mécanismes internes du langage avec lequel il est écrit
afin de gagner en performance. Evidement, ces actions doivent être soigneusement conçues et
réalisées car elles peuvent avoir des conséquences inattendues. Pour que la réflexion soit possible, les
langages doivent permettre l'observation et la modification de leurs aspects implicites tels que la
syntaxe et la sémantique. La figure 6.1 illustre un programme conventionnel (a) et réfléchi (b). Le
programme conventionnel peut seulement agir sur les données représentant les entités du domaine de
l'utilisateur. La réalisation des mécanismes du langage ne lui est pas accessible. Par contre, un
programme réfléchi peut aussi agir sur la réalisations des mécanismes du langage. Le langage contient
des instructions permettant l'accès aux mécanismes internes.
Les systèmes réfléchis dans l'informatique ont été étudiés à partir des travaux de Brian Smith
et ses expériences avec les langages 2-Lisp et 3-Lisp [Smith84]. Postérieurement une forte activité de
recherche a permis d'appliquer la réflexion dans plusieurs domaines, tels que la programmation
flexible [Kiczales91], la programmation concurrente [Matsuoka91], les systèmes distribués [Chiba93],
l'approche objet [Maes87], les systèmes temps réel mous [Honda92], la tolérance aux fautes [Fabre96],
les systèmes d'exploitation [Yokote92] [Stankovic91].
67
Les sections suivantes présentent des concepts et éléments de base des architectures réfléchies.
6.1.1 La réification
La réification est un des processus clés de la réflexion. C'est grâce à elle qu'un aspect
implicite, non exprimé et non accessible d'un programme ou langage, est mis en avant et exprimé de
façon manipulable par le programme. L'aspect réifié est représenté dans le même langage que le
programme (structure de données, procédures, etc.) afin d'être manipulé comme des données
courantes.
réification
réflexion
mécanismeimplicite original
mécanismeimplicite modifié
niveau des mécanismesimplicites du langage
niveau programme modification
Figure 6.2. Réification et réflexion d'un aspect du langage.
Réalisations desmécanismes du
langage.
Entités du domainedu problème de
l'utilisateur
Opérations sur lesdonnées duprogramme
Opérations sur lesréalisations desmécanismes du
langage
(a) (b)
Données duprogramme
représentant lesentités externes
Figure 6.1. Illustration d'un programme conventionnel (a) et d'un réfléchi (b).
68
La réification est vue souvent comme l'acte complémentaire de la réflexion12. Dans la figure
6.2 un aspect du système devient accessible et modifiable grâce à la réification. Les instructions au
niveau programme modifient l'aspect réifié et par la réflexion l'aspect modifié entre en vigueur dans le
langage.
6.1.2 Connexion causale
Une des propriétés qui doit toujours exister dans les systèmes réfléchis est la "connexion
causale" entre la représentation des aspects réifiés et les aspects qu'elles réifient. Un système est dit
connecté de façon causale (causally connected) à son domaine si les structures internes et le domaine
qu'elles représentent sont liés de telle façon que si un de deux change l'autre est modifié en
concordance. Exprimé autrement, le système doit toujours maintenir la cohérence entre la
représentation et les aspects qu'elle représente [Maes87].
6.1.3 Types de réflexion
Les mécanismes de réflexion ont été classés en deux types principaux selon l'aspect qu'ils
considèrent : la réflexion structurelle et la réflexion comportementale (ou computationelle)
[Malenfant96].
Réflexion structurelle.
La réflexion structurelle est la capacité d'un langage à permettre la réification complète du
programme et des données abstraites qu'il utilise. Elle permet de réifier et manipuler le code.
Potentiellement tout langage interprété a la possibilité de réaliser ce type de réflexion. C'est le cas des
langages comme lisp et smalltalk, parmi d’autres. Dans l'orientation objet, beaucoup de langages sont
compilés et n'ont pas de représentation du code pendant l'exécution. La réflexion structurelle est alors
difficile. Néanmoins les langages orientés objet dont les classes sont de véritables objets facilitent la
réflexion structurelle.
Réflexion comportementale.
Dans la réflexion comportementale, le langage permet la réification complète de sa propre
sémantique et aussi des données qu'il utilise pour exécuter le programme. Ce type de réflexion
manipule le comportement du système de calcul. La manipulation est réalisée en deux phases :
recherche de méthode (method look-up) et exécution du traitement du message (message application).
Dans la première phase, lorsque l'entité de base envoie un message (par exemple, un appel de
méthode) la meta-entité l'intercepte et cherche le traitement au niveau méta à exécuter pour ce
12 Bien que le terme "réflexion" soit utilisé pour représenter la propriété d'un système capable d'agir sur lui- même, il sert aussi à nommer l'acte d'agir sur soi même.
69
message. Le flux d'exécution se déplace du niveau de base au niveau méta. Dans la deuxième phase
l'entité méta exécute le message et rend le résultat à son entité de base. Le flux d'exécution se déplace
du niveau méta au niveau de base. Des exemples de ce type de réflexion sont OpenC++ [Chiba93] et
Smalltalk80 [Foote89].
6.2 Architectures à méta niveaux
Dans cette architecture, les systèmes sont composés de deux ou plusieurs niveaux : un niveau
base et un ou plusieurs niveaux méta. Le niveau base est destiné à résoudre les problèmes concernant
l'utilisateur. Il offre des mécanismes de programmation avec lesquels une solution (programme) est
construite. D'un autre coté, le niveau méta contient la réalisation des mécanismes du niveau de base.
Lorsque ces réalisations sont accessibles au programme, ce dernier peut agir sur elles et modifier ainsi
la sémantique des mécanismes13. A niveau méta il est possible résoudre des problèmes qui ne sont pas
directement liés au problème de l'utilisateur, comme la sécurité de fonctionnement, la synchronisation,
l’ordonnancement, la concurrence, etc. Il faut aussi noter que dans une architecture à plusieurs
niveaux, un niveau méta peut être le niveau de base pour un autre niveau méta (méta-méta niveau). La
figure 6.3 illustre la relation entre les éléments de chaque niveau dans ce type d'architecture.
Niveau base
Niveau meta
Niveau meta meta
Solution au problèmede l'utilisateur
Réalisation des méca-nismes du niveau base
Réalisation des méca-nismes du niveau meta
metaobjets
Figure 6.3. Architecture à Méta niveaux.
6.3 Architectures à méta-niveaux orientées objet.
Dans une architecture fondée sur l'approche objet, les composants de tous les niveaux sont des
objets. Ceux qui représentent et réalisent les aspects structurels et de calcul des objets de base, sont
appelés méta-objets. Les aspects structurels décrivent la manière dont sont construits et liés les objets
ou groupes d'objets dans le niveau de base. Les aspects de calcul décrivent comme les méta-objets
13 Cette possibilité à donné lieu à un important domaine de l'informatique connu comme les systèmes ouverts ou open systems [Kiszales92].
70
représentent et réalisent les traitements des objets de base. Dans la figure 6.3 les méta-objets sont
indiqués dans les niveaux méta et méta-méta.
La relation entre les méta-objets et les objets qu'ils représentent peut être un à un ou plusieurs
à un (voir figure 6.4 ). Néanmoins les méta-objets doivent être uniques pour un objet de base, c'est à
dire, ils ne sont pas partagés. Lorsque la relation est plusieurs à un chaque méta-objet peut se charger
d'un aspect particulier de l'objet [McAffer95].
Les critères que les méta-objets doivent satisfaire, et qui les distinguent des autres objets du
niveau méta, sont [Matsuoka91] :
MO MO MO
O
MO
O
(a) (b) Figure 6.4. Relations (a) un à un, et (b) plusieurs à un, entre objets et méta-objets.
a) L'identification des méta-objets. Un objet de base doit identifier ses méta-objets d'une façon
intrinsèque (unique et directe).
b) L'unicité de la dénotation du méta-objet. Les méta-objets doivent être capables d'identifier
l'objet de base qu'ils dénotent d'une façon intrinsèque.
c) La connexion causale. Un objet de base et ses méta-objets doivent être connectés de façon
causale. A tout moment la représentation que le méta-objet a de l'objet, doit correspondre à
l'objet, et vice-versa (voir section 6.1.2 ci-dessus).
d) Le contrôle des traitements. Les méta-objets doivent contrôler dynamiquement les traitements
de l'objet qu'ils dénotent ou représentent.
6.4 Réflexion et Orientation Objet
Bien que la réflexion ait été déjà étudiée et explorée dans différents types de langages
(procéduraux, basé logique et basé règles) ce fut le langage 3-KRS [Maes87] une des premières
réalisations des systèmes réfléchis dans l'approche objet. Le principal mérite de 3-KRS était de
71
montrer la puissance des architectures à méta-objets pour réaliser la réflexion. Il à réussi à prouver
quelques propriétés importantes des architectures réfléchies orientées objet :
• séparation claire entre le niveau objet et le niveau réflexion. Chaque objet est lié à un méta-objet et
vice-versa. Les structures contenues dans un objet représentent seulement des informations
concernant l'entité du domaine représenté par l'objet. Par contre, le méta-objet contient les
structures concernant à toute l'information réfléchie de son objet (voir figure 6.5 )
• représentation uniforme. Toutes les entités dans 3-KRS sont des objets : instances, classes, slots,
méthodes, méta-objets, messages, etc. Par conséquent tout aspect du langage peut être réfléchi.
• auto-représentation complète. Les méta-objets contiennent toute l'information qui existe sur les
objets dans 3-KRS. L'interprète du langage est explicite et totalement contenu dans un ensemble
de meta-objets primitives du langage.
• cohérence de l’auto-représentation. Le système complet est construit en utilisant la même
représentation. L'interprète explicite inclus dans les méta-objets est utilisé pour implémenter le
système. Lorsqu'une opération doit être faite sur un objet c'est son méta-objet qui effectue
l'opération. Pour éviter un appel infini aux méta-objets 3-KRS a un interprète implicite qui réalise
le comportement par défaut.
• l'auto représentation peut être modifiée pendant l'exécution. L'auto représentation du système est
explicite, c'est à dire qu'elle est constituée d'objets. Le programme peut la modifier et affectant
ainsi le comportement du système
La figure 6.5
"#5689" contient tou
"John". Comme toutes
la "méthode d'impress
l'imprimante.
<Meta-Object - #5689>
<Object -"John">
Méthode de création Méthode de traitement des messages
Méthode d'héritage
Méthode d'impression
Meta RéférantNom
Meta
Figure 6.5. Un objet et son meta-objet dans 3-KRS [Maes87].
montre le rapport entre un objet et son méta-objet dans 3-KRS. Le méta-objet
tes les informations concernant la réalisation et le comportement de l'objet
ces informations sont explicites, le programme peut les modifier. Par exemple,
ion" peut être modifiée pendant l'exécution lorsqu'un problème est détecté sur
72
6.4.1 Modèles de réflexion
Dans les langages orientés objet, deux grandes approches ont été identifiées pour réaliser la
réflexion : l'approche à base de méta-objet, et l'approche fondée sur la réification de la communication
[Ferber89].
L'approche à base de méta-objet consiste à établir une connexion entre un objet de base et un
ou plusieurs objets de niveau méta. Deux modèles sont dérivés de cette approche : le modèle méta-
classes et méta-objets.
Modèle méta-classes.
Dans le modèle méta-classes, toute entité est une instance d'une classe. Tant les objets que les
classes sont des instances de classes. Les classes des instances de classes sont aussi appelées
métaclasses [Cointe88]. Dans ce modèle les classes sont les méta-objets, car elles contiennent une
description de la structure et du comportement de ses instances. Lorsqu'un aspect d'une classe est
modifié, ses instances modifient leur structure et leur comportement en conséquence. Dans la figure
6.6 "Classe" est le méta-objet de l'objet, Métaclasse est le méta-objet de Classe, Métamétaclasse est le
méta-objet de Métaclasse, etc.
est instance de
Metametaclasse
Metaclasse
Classe
object
est instance de
est instance de
Figure 6.6. Modèle de réflexion meta-classes.
Il faut noter que ce modèle de réflexion est seulement réalisable dans les langages orienté
objet "purs", tels que Smalltalk-80 [Goldberg83] et CLOS [Bobrow88], dont les classes sont des
objets. Le fait que toutes les instances d'une classe partagent la même définition structurelle et
comportementale peut être un désavantage de ce modèle. Une modification dans une classe affecte
toutes ses instances, ce qui empêche une modification de comportement individuelle.
73
Modèle méta-objets.
Dans ce modèle, les méta-objets sont des objets (instances) d'une classe spécifique
(MetaObject) ou d'une de ses descendantes. La réflexion se produit lorsque les méta-objets
interceptent les messages envoyés à leurs objets. Ils traitent les messages avant de les passer aux
objets. Dans cette approche chaque méta-objet peut être connecté à un ou plusieurs objets, et chaque
objet peut se lier avec plusieurs méta-objets pendant son cycle de vie (un seul à la fois). Normalement
la liaison objet méta-objet est faite par une variable dont la valeur peut être facilement modifiée.
Néanmoins, dans la plupart des réalisations la connexion se limite à un objet et un méta-objet
seulement. Des exemples de ce type de modèle sont OpenC++ [Chiba93] et ABCL-R [Masuhara92].
Le principal avantage de ce modèle est la facilité qu'il offre pour spécialiser le comportement
au niveau méta. Il suffit de créer une nouvelle classe de méta-objet à partir d'une classe déjà existante
et de la spécialiser. Le principal désavantage est que le méta-objet connaît le message seulement
lorsque son objet l'a reçu, sans connaître l'expéditeur du message et ne pouvant pas agir en fonction de
son identité.
Modèle fondé sur la réification de la communication.
Cette approche est fondée sur la réification des interactions entre les entités de base. Un des
modèles dans cette approche est le model de réification de messages [Ferber89].
Dans ce modèle les appels de méthode sont réifiés en entités de niveau méta appelées
messages. Les messages réifient les actions qui doivent être faites par les entités de base. Le type d'un
message définit le comportement de niveau méta à réaliser par le message. Ce dernier existe seulement
pendant la durée de l'action qu'il représente. Lorsque l'opération au niveau méta est finie, le message
est détruit. Dans ce modèle les messages n'ont aucun lien avec les entités qui les créent et donc ils ne
peuvent pas accéder à leurs informations. Comme ils sont détruits après la fin de leurs opérations, il
n'est pas non plus possible de maintenir des informations entre messages. Un dernier désavantage de
ce modèle est qu'à chaque appel les messages sont créés et postérieurement détruits, ce qui peut être
indésirable dans des applications dont la prédictibilité temporelle est importante. La figure 6.7 illustre
ce modèle.
Classe dumessage
Instance de
Instance de
messageobjet
Selector:Arguments:Receptor:
messageClasse de
l'objet
Figure 6.7. Modèle fondé sur la réification des messages.
74
6.4.2 Protocoles à méta-objet (Meta Objects Protocols, MOP)
Les protocoles à méta-objets (meta-object protocols, MOP), étaient définis comme des
interfaces spéciales des langages de programmation donnant à l'utilisateur la possibilité de modifier
leur réalisation et leur comportement [Kiczales91]. Traditionnellement, les langages sont supposés
avoir une sémantique bien définie et fixe. Les développeurs doivent utiliser leurs abstractions comme
des boîtes noires et construire les applications au-dessus d'elles. Il est aussi attendu qu'un langage soit
rigide et immuable pour mieux supporter des réalisations portables, des compilateurs efficaces, etc.
Par contre, le protocole à méta-objet est fondé sur une idée différente : le langage doit être ouvert et
flexible afin de permettre aux utilisateurs de l’adapter à leurs besoins. Cette adaptation serait aussi
possible dynamiquement pendant l'exécution. Un des avantages des protocoles à méta-objets, est que
l'implémentation du langage est conçue comme un programme orienté objet, permettant ainsi
l'utilisation d'une même technique tant pour résoudre le problème de l'utilisateur que pour les actions
d'adaptation du langage.
La figure 6.8, illustre les idées de langage "fermé" et "ouvert". Dans un langage fermé les
programmes sont restreints au modèle objet offert par le langage, lequel peut ou non satisfaire
pleinement les besoins de l'application. Par contre, dans un langage ouvert les implémentations du
langage peuvent être adaptées depuis l'application.
Langage deprogrammation
Boîte Noire(fermé)
Interface duLangage
Niveau de programmationde l'application
Langage deprogrammationBoîte Blanche
(ouvert)
Interface duLangage
Niveau de programmationde l'application
Interface d'accès àl'implémentationdu langage
(a) (b) Figure 6.8. Langage fermé (a), et langage ouvert (b)
6.5 Exemples d'Architectures réfléchies
Quelques exemples de réalisations d'architectures réfléchies orientées objet sont décrits
maintenant. Ils illustrent certaines idées intéressantes pour la conception d'ARTO.
6.5.1 Open C++
Open C++ [Chiba93] est une extension du langage C++ (préprocesseur) qui réalise un modèle
de réflexion basée méta-objet et offre à l'utilisateur deux niveaux d'abstraction :
75
• le niveau de base, dédié à la programmation traditionnelle en C++, et
• le niveau méta, qui permet de redéfinir certains aspects du modèle de programmation de C++.
Open C++ permet aux programmeurs d’associer une classe de l'application (niveau de base)
avec une classe de méta-objet (niveau méta) et de faire la connexion pour qu'une instance particulière
de la classe de l'application soit réfléchie (soit contrôlée par un méta-objet de la classe méta-objet
correspondante). Tous les méta-objets de Open C++, sont des objets des classes dérivant de la classe
MetaObj (Voir figure 6.9).
Dans Open C++ un objet de base contrôlé par un méta-objet, est appelé un objet réfléchi
(reflective object). La déclaration d'un objet réfléchi en Open C++ prend la forme d'une annotation de
C++. Par exemple la déclaration :
//MOP reflect class X : M;
MetaObj
Classe du metaobjet
metaobjet
Classe de l'objet
objet1 1
Instance de Instance de
Figure 6.9. Classes de l'objet et du méta-objet en Open C++.
signifie que tout objet de la class refl_X est un objet réfléchi qui sera contrôlé par un méta-objet de la
class M.
Les méta-objets contrôlent leurs objets réfléchis en interceptant les appels de méthodes reçus
par leurs objets. Cependant, pour qu'une méthode soit contrôlée par le méta-objet elle doit être
déclarée explicitement comme une méthode reflect en plaçant la directive "//MOP reflect :" avant sa
définition. Dans l'exemple suivant "func()" est déclarée comme une méthode réfléchie.
Class X { Public X(); //MOP reflect : int func(int); private : int p; };
76
La figure 6.10 illustre le mécanisme de contrôle de Open C++. Lorsqu'une méthode réfléchie
est appelée au niveau de base, l'appel est intercepté et traité au niveau méta par la méthode
Meta_MethodCall. Normalement Meta_MethodCall appelle la méthode invoquée du niveau de base,
mais elle peut aussi réaliser d’autres actions avant et/ou après l'appel. Au moyen de ce mécanisme les
métaobjets redéfinissent la sémantique des appels de méthodes.
L'exécution des méthodes du méta-objet est atomique, c’est à dire, elles s'exécutent
complètement sans être interrompues.
int func(){ . .}
Base-level
Ojbect (refl_X)
void Meta_MethodCall(){printf(….);Meta_HandleMethodCall();
}
metaobject (VerboseMetaObj)
Meta-level
Call
Return
Figure 6.10. Protocole à Méta-objet de Open C++.
6.5.1.1 Systèmes distribués dans Open C++ : la Communauté d'Objets
Open C++ ne supporte pas des applications distribuées. Cependant une plate-forme appelée
Communauté d'Objets (Objects Community) fut proposée pour la réalisation de systèmes distribués,
comme un cadre opérant au dessus de Open C++ [Chiba93]. La principale fonctionnalité de la
Communauté d'Objets est la gestion d'un groupe d'objets distribués sur des machines différentes.
Chaque objet appartient à un processus possédant son propre espace d'adressage et qui communique
avec les autres processus à travers un réseau. Voir Figure 6.11.
metaobjet
objet
communication
Niveau meta
Niveau base
Processus
Processus
Processus
Communauté d'Objets
Figure 6.11. Une Communauté d’Objets en Open C++.
77
La Communauté d'Objets est réalisée par une bibliothèque de classes de méta-objets qui offre
aux programmeurs les fonctionnalités typiques pour des applications distribuées, et qu'ils peuvent
adapter selon leurs propres besoins. Toutes ces fonctionnalités supplémentaires sont réalisées au
niveau méta. Le programme au niveau de base n'est pas concerné, excepté pour l'extension des appels
de méthode vers le niveau méta.
Les principales capacités des méta-objets dans la communauté d'objets sont :
a) Contrôle de concurrence. Les méta-objets contrôlent la concurrence interne de leurs objets. Ils
peuvent ignorer ou retarder l'exécution d'une méthode jusqu'à ce qu'une condition soit satisfaite.
Les méta-objets peuvent aussi exécuter concurremment plusieurs méthodes de leurs objets.
b) Communication. Les méta-objets communiquent avec d’autres méta-objets d'une même
communauté par des appels de méthodes distantes (remote method call) et par diffusion de
message.
Pour ajouter des capacités de contrôle de concurrence et de communication, une nouvelle
classe, OcCoreMetaObj, descendant de MetaObj à été définie au niveau méta. Toutes les classes qui
réalisent des fonctionnalités de la Communauté d'Objets, héritent de OcCoreMetaObj. Elle définit des
méthodes pour manipuler une communauté d'objets, pour les communications entre objets, pour le
contrôle de la concurrence, etc. Elles réalisent entre autres, les fonctionnalités de : données distribuées
partagées, transactions, appels à méthodes distantes, identificateurs d'objets distants [Chiba93].
Un des aspects intéressants d'Open C++ est qu'il introduit et réalise des mécanismes de
réflexion, particulièrement la réification des appels de méthodes, au niveau du programme. Il n'existe
pas de notion de langage ouvert ou fermé car tout se passe au niveau du programme et les mécanismes
internes du langage ne sont pas concernés. Un des principaux désavantages est le coût en performance
de la solution parce que l'interception de message et le passage du niveau base au méta-niveau est
lourd. Cependant, l'expressivité obtenue justifie le coût de la solution, spécialement pour le cas des
systèmes distribués dont les temps de communication sont importants.
6.5.2 ABCL/R
ABCL/R est un langage de programmation orienté objet concurrent qui possède une
architecture réfléchie fondée sur les méta-objets [Watanabe88]. Il a été développé dans le Département
des Sciences de l'Information de l'Université de Tokio, avec l'intention d'appliquer la réflexion dans le
domaine de la programmation concurrente orientée objet (Object-Oriented Concurrent Programming ,
OOCP). Dans le projet, trois architectures de systèmes réfléchis étaient étudiées, différenciées par la
façon dont les objets de base se lient aux objets des niveaux méta :
– Architecture individuelle : les objets de base possèdent un ou plusieurs méta-objets qui pilotent
leur exécution. L'objet est l'unité du niveau base qui a une connexion causale avec le niveau méta.
78
– Architecture de groupe : dans cette architecture le comportement collectif d'un groupe d'objets
est représenté par des actions coordonnées d'un groupe d'objets du niveau méta, qui constituent un
metagroup. Le group entier d'objets est l'unité du niveau base, qui a une connexion causale avec le
niveau méta (avec un meta-group). Il n'y a pas des relations particulières entre un objet du niveau
base et tel méta-objet du niveau méta.
– Architecture hybride de groupe : cette architecture est une combinaison des architectures
individuelle et de groupe. Chaque objet a un ou plusieurs méta-objets comme dans l'architecture
individuelle, mais les actions coordonnées d'un groupe d'objets sont contrôlées par un metagroup
du niveau méta. Dans cette architecture, un objet individuel et un groupe d'objets ont des
connexions causales avec le niveau méta.
L'architecture de ABCL/R est de type individuelle donc chaque objet X est lié a un méta-objet
↑X. Les aspects structuraux de l'objet (un ensemble de variables d'état, un ensemble de méthodes, un
évaluateur local, et une queue de messages) sont représentés comme des variables d'état du méta-objet.
Ses aspects traitement (arrivée, réception et acceptation de messages, et exécution de méthode) sont
représentés dans ↑X par de méthodes.
La figure 6.12, illustre la structure des objets et méta-objets en ABCL/R. La réflexion est
réalisée par l'envoi de messages d'un objet à son méta-objet. Ainsi l'objet peut s'informer sur lui-même
ou se modifier à travers des actions de son méta-objet. De la même manière, le méta-objet peut
envoyer des messages à son objet.
Une propriété des architectures réfléchies de type individuel qui les différencie est la relation
d'identité entre un objet et son méta-objet. Deux situations sont possibles selon que le méta-objet a ou
no une identité séparée de l'objet qu'il dénote :
Meta-metaobjet ↑↑X
Xobjet
↑Y:metaobjet de Y
metaobjet ↑X
Y
↑↑Y
Message M
[:message M R S
Variables d'étatet méthodesreprésentant
l'objet Y
Figure 6.12. Structure et communication en objets ABCL/R
79
a) Identité unifiée : lorsqu'il n'y a pas de séparation d'identité entre l'objet et son méta-objet. Il existe
un seul objet qui peut être vu comme l'objet de base, comme son méta-objet, ou son méta-méta-
objet, etc. L'objet réalise toutes les fonctionnalités.
b) Identité séparée : lorsque le méta-objet a sa propre identité, séparée de celle de l'objet qu'il
dénote.
L'identité des objets ABCL/R est de type unifié. Cependant, l'avantage d'une identité séparée
du méta-objet est la possibilité de changer dynamiquement le méta-objet pour modifier le
comportement de l'objet. Par contre, un des désavantages du modèle d'identité séparée, affectant
particulièrement la concurrence, est le coût de la communication nécessaire pour maintenir la
connexion causale entre l'objet et le méta-objet.
6.5.3 ABCL/R2
ABCL/R2 est un langage avec une architecture hybride, incorporant les propriétés des
architectures basées individuelles et de groupe. Chaque objet a son propre méta-objet comme en
ABCL/R, mais il appartient aussi à un groupe d'objets, qui est contrôlé par un groupe de méta-objets.
La motivation principale pour une architecture hybride est la bonne gestion des ressources partagées.
Dans les systèmes concurrents les ressources telles que processeur, communications, stockage,
dispositifs d'entrée et sortie, etc., sont distribuées et limitées. Cela demande une forte coordination
pour leur gestion et requiert l'existence simultanée des abstractions suivantes au niveau méta :
a) groupes d'objets au niveau méta qui représentent le traitement global,
b) identité des objets au niveau méta pour le contrôle d'objets individuels, et
c) abstraction appropriée des ressources partagées.
Les objets ABCL/R2 appartiennent toujours à un groupe d'objets partageant des ressources. Il
existe alors deux types de tours de réflexion14 : individuelle pour chaque objet, et de méta-groupes
pour chaque groupe.
La tour individuelle de méta-objets, détermine la structure de l'objet et ses méthodes. Par
exemple, une opération réfléchie qui sert à modifier une méthode de l'objet est située dans le domaine
de sa tour de réflexion individuelle.
La tour de groupe et de métagroupes détermine le comportement du groupe de base, en
incluant le traitement des méthodes des objets du groupe. Donc, les opérations qui affectent tous les
membres du groupe, comme l'ordonnancement, sont du domaine de la tour de groupe. La structure et
le traitement d'un groupe esontst définis dans le méta niveau par les objets appelés objets de noyau de
80
groupe (group kernel objects). Le groupe gère les ressources partagées du groupe par la coordination
entre les méta-objets des objets membres du groupe et les objets du noyau de groupe.
x
↑x
↑↑x
y
↑y
metagen GMgr Eval
G: un groupe
↑G: metagroupe de G
Objets nonréifiés
Tour deréflexionde x
↑↑y
Tour deréflexion dugroupe G
Figure 6.13. Architecture réfléchie hybride de ABCL/R2
La figure 6.13, illustre l'architecture réfléchie hybride de ABCL/R2. Les objets metagen
(metaobject generator), GMgr (group manager) et Eval (evaluator) sont les objets du noyau du
groupe standard. Ils se chargent de la gestion de groupe et leurs principales fonctions sont :
a) Gestionnaire de groupe GMgr : c'est l'objet qui représente et gère le groupe. L'identité du groupe
est celle du manager de groupe, et tous les messages envoyés au groupe arrivent à son manager.
Un nouvel objet appartient au groupe de l'objet qui l'a créé, sauf si un groupe différent est explicité
au moment de la création.
b) Générateur de méta-objet metagen : c'est le méta-objet chargé de la création d'un méta-objet pour
l'objet qui vient d'être créé. Le méta-objet Evaluator envoie un message à metagen avec toutes les
informations nécessaires pour la création du méta-objet. Ce dernier contient : une queue de
messages, un ensemble de méthodes, un ensemble de variables d'état, des références à Evaluateur
et au manager de group, et le mode d'exécution. La réception d'un message M par un objet de
base, correspond à la réception d'un message [:message M R S] par son méta-objet. Le méta-objet
place le message M dans la queue de son objet de base. Le méta-objet cherche une méthode qui
corresponde au premier message de la queue et s'il la trouve, il envoie un message à Evaluateur
pour que ce dernier l'exécute.
c) Evaluateur Eval (evaluator) : Eval est la ressource de calcul partagée par les objets de base
membres d'un groupe. Sa principale fonction est l'évaluation des messages des objets du groupe. Il
interagit avec des autres objets du noyau de groupe et méta-objets pour la gestion du groupe. Il se
charge, par exemple, de l'ordonnancement.
14 Tour de réflexion : le group formé par l'objet - le metaobjet - le metametaobjet - etc. connectés de façon
81
Les principales propriétés du modèle ABCL/R2 peuvent être résumées par :
a) groupes d'objets hétérogènes,
b) méta groupes et tours de réflexion individuelles et de groupe,
c) objets sans réification individuelle. Les ressources partagées ont des représentations au niveau
méta et sont partagées par les objets de base d'un groupe.
causale.
82
7 Architecture de ARTO
L'architecture des objets ARTO est une architecture réfléchie à méta niveaux avec deux
niveaux15. Son objectif principal est de faciliter la réalisation des mécanismes de gestion de la QoS en
séparant la solution du problème de l'utilisateur du traitement de la QoS. En général tout aspect non
fonctionnel est traité au niveau méta. Voir figure 7.1.
L'approche adoptée pour affronter la gestion de la QoS est l’adaptation des objets aux
variations du contexte d'exécution. La façon de répondre aux requêtes est décidée dynamiquement au
niveau méta. L'adaptabilité est possible principalement grâce au fait que les objets offrent plusieurs
méthodes pour fournir un même service. Le comportement des objets est décidé à niveau méta en
fonction des besoins de QoS et du contexte. Ainsi les objets non seulement peuvent fournir la QoS
attendue, mais aussi la plus grande QoS possible selon le contexte.
Un avantage important de l'architecture est que la solution au problème de l'utilisateur est
indépendante du contexte d'exécution, ce qui lui donne un haut degré de portabilité.
Niveau Méta :traitements des aspectsnon fonctionnels.
QoSComportement
contexte
Niveau Base : solution auproblème de l'utilisateur.
Interactionentre niveaux
Fig. 7.1. Niveaux Base et Méta dans une architecture réfléchie à méta niveaux.
7.1 Niveau de base : les objets
Le niveau base contient les objets qui à travers les méthodes qu'ils apportent et leurs
interactions, réalisent les fonctions nécessaires pour donner solution au problème de l'utilisateur.
7.2 Niveau méta : les méta-objets
A niveau méta, les méta-objets se chargent des aspects non fonctionnels de l'application. Entre
autres, ils prennent en charge la gestion de la QoS et la gestion de la concurrence. Une des fonctions
importantes des méta-objets est le contrôle du comportement des objets de base.
15 Plusieurs niveaux sont possibles, mais deux niveaux semblent être suffisent pour les besoins des objets ARTO.
83
7.3 Relation Objet - Méta-objet
Dans ARTO chaque objet est associé à un seul méta-objet et vice versa. Leur relation s'établit
au niveau des instances, cela veut dire qu’une instance d'objet est liée à une instance de méta-objet.
Cette relation entre instances offre une grande flexibilité car elle permet un contrôle de comportement
spécifique à chaque objet. De cette façon les objets issus d'une même classe peuvent être contrôlés par
des méta-objets provenant de classes différentes.
La figure 7.2 illustre un exemple de la relation entre classes dans ARTO. La classe d’objets de
base ClasseO_2 est une classe descendant de ClasseO_1. Un objet de la ClasseO_1 est associé avec un
méta-objet de classe ClasseMO_b. Un objet de la classe ClasseO_2, peut avoir un méta-objet de classe
ClasseMO_c ou ClasseMO_e. Enfin, un méta-objet de la classe ClasseMO_c a un méta-objet de la
classe ClasseMO_d.
La figure 7.3 donne un exemple d'instances d'objets et méta-objets et leurs relations.
Supposons que les objets O1' et O1'' sont des instances de la classe ClasseO_1 de la figure 7.2. Alors
ils ont chacun un méta-objet instance de ClasseMO_b. D'un autre coté, si les objets O2' et O2'' sont
deux instances de ClasseO_2 ils peuvent avoir des méta-objets de classe ClasseMO_c ou de
ClasseMO_e.
ClasseO_1
ClasseO_2
ClasseMO_c
ClasseMO_e
ClasseMO_dClasseMO_b
ClasseMO_a
hérite
meta
Figure 7.2. Relation entre classes d'objets et classes de metaobjets.
MOb'
O1'
MOc
O2'
MOe
O2''
Niveau meta
Niveau base
(metaobjets)
(objets)
MOb''
O1''
Figure 7.3. Rapport un-un entre méta-objets et objets dans ARTO.
7.4 Réification
Pour que les méta-objets puissent effectuer leurs activités, le flux de l'exécution doit passer au
niveau méta. Dans ARTO ce passage est réalisé à plusieurs reprises. Il se produit principalement par la
84
réification de messages, c'est à dire que les messages sont transformés en objets et envoyés aux méta-
objets. Cette technique est similaire à celle mentionnée dans la section 6.4.1 et à celle de
OpenC++[Chiba93]. Ce mécanisme simple offre une grande puissance car il permet aux méta-objets
de prendre le contrôle et de décider de la manière de réaliser les services. En plus, des options sont
offertes avec des actions à exécuter avant et après la réalisation du service.
Dans ARTO la réification de messages agit de la façon suivante. Lorsque l'objet "O1" envoit
un message à l'objet "O2" (pour appeler la méthode "m", par exemple), la requête est traduite par un
appel au service de livraison de messages "send" du méta-objet "MO1" (voir Figure 7.4).
L'activité passe au niveau méta lorsque l'exécution d'un message se termine et le contrôle
revient au méta-objet responsable de l'exécution du message. Les autres fonctions réifiées dans ARTO
sont la création et destruction d’objets.
En comparaison à la réification de messages de OpenC++ [Chiba93], un avantage de la
réification de messages de ARTO est que l'objet est totalement encapsulé par son méta-objet ce qui
augmente son indépendance et en conséquence la modularité et la portabilité de l'application.
O1 O2
O2.m(p)
MO1 MO2
MO1.send(MO2,m,p,...)
Figure 7.4. Réification de messages dans ARTO.
7.5 Réflexion
La réflexion est l'acte complémentaire de la réification. C'est par la réflexion que les décisions
prises au niveau méta sont concrétisées au niveau de base. Dans ARTO le flux de l'exécution revient
au niveau base après que le méta-objet a fini son activité qui normalement est suivie de l'exécution
d'une méthode d'objet.
7.6 Modèle d'exécution
Le modèle d'exécution de ARTO est fondé sur deux types d'objets : un objet actif pour le
méta-objet et un objet passif pour l'objet de base. Les deux objets sont étroitement liés et constituent
l’unité fonctionnelle de base pour construire une application. Un objet ARTO spécial appelé objet
applicatif constitue la racine de l’application et est chargé de sa mise en route.
85
7.6.1 Les Objets de base
Sauf pour leurs liaisons vers les méta-objets, les objets de base sont des objets passifs normaux
qui contiennent les méthodes qui réalisent les fonctions de l’application. Libérée de tout problème non
fonctionnel, la solution au problème utilisateur s’écrit comme une solution séquentielle normale.
Parmi les propriétés importantes des objets qui déterminent leur comportement, on peut citer :
• Les méthodes qu'ils offrent pour chaque service, et leurs caractéristiques.
• Les états, avec la description des transitions et messages permis dans chaque état
• La dépendance entre objets par les états
7.6.2 Les méta-objets (MOs)
Les méta-objets ARTO sont des objets actifs chargés principalement de contrôler le
comportement des objets de base. Ils contiennent des connaissances sur leur objet, sur le contexte et
les critères et règles qui guident leurs décisions.
Les composants les plus importants des méta-objets ARTO :
• Un thread principal appelé le contrôleur, qui effectue toute l'activité du méta-objet. Sa
fonction principale est de décider du comportement de l'objet de base.
• Plusieurs threads destinés à l'exécution de méthodes. Ils sont gérés par le contrôleur et
peuvent être exécutés concurremment. Le nombre de threads est particulier à chaque
objet.
• Une queue de messages. Les messages qui arrivent son placés dans une queue dont ils
sont ensuite analysés par le contrôleur. La taille de la queue est particulière à chaque
objet.
La figure 7.5 illustre les principaux éléments qui composent l'objet ARTO.
En plus des éléments déjà mentionnés, les MOs contiennent des variables où sont stockées les
informations qu'ils utilisent, et des méthodes qu'ils exécutent.
Qld
ueue poura réceptione messages
Thread de contrôle(contrôleur)
Threads pourl'exécution deméthodes
Objetpassif
ObjetARTO
méta-objet
Figure 7.5. Principaux composants de l'objet actif ARTO.
86
7.6.3 L'objet Applicatif
L'objet Applicatif est un objet ARTO spécial qui représente l'application et qui est responsable
principalement de la création et du démarrage des objets initiaux que la composent. Il se charge de
fonctionnalités importantes concernant toute l'application. Il est aussi responsable des données
publiques de caractère global qui sont utilisées par les méta-objets.
7.6.4 Messages
Dans ARTO les messages sont le seul moyen de communication entre objets. Entre autres, ils
portent les demandes de services et les besoins de QoS des clients. Au moment où le serveur reçoit un
message, le contrôleur décide son traitement. Bien que la plupart du temps il s'agisse de l'exécution
d'une méthode de l'objet pour satisfaire le service, plusieurs actions sont possibles en fonction du
service demandé, des propriétés du message, du mode de l'application, de l'état de l'objet, du contexte,
des politiques en vigueur, etc. Les propriétés importantes des messages sont décrites plus loin.
La communication de messages est gérée par les méta-objets. Ils reçoivent les messages réifiés
provenant de leurs objets de base et les transmettent aux destinataires. Plusieurs options sont possibles
pour le destinataire du message car le méta-objet peut décider de l'envoyer à un destinataire différent,
à plusieurs destinataires, ou même de ne pas l'envoyer du tout. Toutes ces options sont décidées par le
méta-objet sans l'intervention de son objet.
Le méta-objet client dépose le message dans la queue du méta-objet destinataire et ce dernier
procède à son traitement. Plusieurs options sont aussi possibles du côté du serveur. Le méta-objet peut
décider d'exécuter une méthode de l'objet ou une autre action. Si une réponse est attendue par le client,
elle prend le chemin inverse. La figure 7.6 illustre le parcours d'un message.
O1 O2
MO1 MO2
MO1.send(MO2, m, p,...)
Figure 7.6. Communication de messages dans ARTO.
7.6.5 Les modes de l'application
Les modes de l'application sont des sortes d'états globaux qui servent à représenter les
différentes situations par lesquelles passe le système pendant son exécution. Par exemple, dans un
système de pilotage d'avion, on peut imaginer les modes à_terre, décollage, vol_normal,
87
vol_turbulent, vol_automatique, vol_manuel, urgence, atterrissage, etc. En plus, dans chaque mode le
système peut passer par des sous modes.
Les modes ont des effets importants sur le comportement des objets, spécifiquement sur leur
façon de traiter les messages. Par exemple, dans le mode à_terre un service de mesure d'altitude peut
être de basse importance ou simplement ne pas être fourni. Cependant, le même service au moment de
l'atterrissage est un service très important qui doit sûrement être garanti. Ainsi chaque situation peut
requérir des traitements différents pour un même service en fonction des besoins particuliers du
système.
L'information sur les modes et leurs effets sur le traitement des messages est une partie
importante de la définition du comportement des objets. Ces informations sont utilisées par les méta-
objets dans le traitement des messages.
88
8 Réalisation
La réalisation de la solution concerne principalement la conception et la mise en œuvre des
mécanismes pour la gestion de la QoS. Dans ARTO les méta-objets gèrent la QoS à travers
l'adaptation dynamique du comportement des objets face aux variations du contexte. Suite aux
demandes de services, ils décident comment les réaliser en fonction des besoins de QoS, de leurs
propres capacités et des propriétés du contexte d'exécution. Les décisions sont faites au niveau méta
par les méta-objets et réalisées au niveau de base par les objets.
8.1 Niveau de la gestion
Dans le modèle ARTO la gestion de la QoS est située au niveau de la couche de l'application.
Bien que des systèmes de gestion de QoS puissent exister à des niveaux logiciels intermédiaires ou
même du Système d'Exploitation, ARTO ne requiert aucun service additionnel de gestion de QoS.
Il faut préciser que la granularité de la gestion est haute parce qu'à l'intérieur de l'application la
gestion agit au niveau des objets. Voir figure 8.1.
Application Objets ARTO
Gestionnaire intermédiaire
Système d'exploitation
Couche de bas niveau
QoS gérée par les objets
Matériel
Figure 8.1. Gestion de QoS au niveau de l'application dans ARTO.
8.2 QoS gérée par les Méta-objets
Dans ARTO, chaque méta-objet décide de façon indépendante de la QoS fournie par son objet
de base. Cette approche offre une grande flexibilité au modèle parce qu'elle permet d’ajuster la gestion
aux caractéristiques particulières de chacun. Cependant cette politique introduit un problème important
lors du partage de ressources. Des décisions indépendantes conduisent à une utilisation inefficace des
ressources, ce qui a des conséquences négatives sur la QoS. Pour surmonter ce problème une gestion
de type centralisé a été ajoutée au modèle. Il s'agit de la planification de l'utilisation du processeur, la
principale ressource partagée. Elle est réalisée au niveau méta et permet aux méta-objets de gérer le
temps de CPU en fonction des objectifs globaux de l'application. En plus, cette gestion ajoute un point
additionnel de décision pour le contrôle de la QoS.
89
8.2.1 Connaissances du MO
Pour effectuer leur activité les méta-objets utilisent des informations provenant de différentes
sources. Elles concernent les propriétés de leurs objets, du contexte d'exécution, de l'application elle-
même et d'autres objets. Cette information est une partie des connaissances des méta-objets et est
stockée et mise à jour dynamiquement.
8.2.1.1 Connaissances sur l'Objet
Les caractéristiques des objets dépendent des particularités de chacun mais elles peuvent être
aussi affectées par le contexte dans lequel l’application se déroule. Les informations que le méta-objet
maintient sont en particulier :
• Relation entre Mode, messages et méthodes.
Chaque mode de l'application demande différents traitements de messages qui se concrétisent
normalement par l’exécution d’une méthode. Le méta-objet contient une table où sont stockées des
listes de méthodes pour chaque message dans chaque mode. A partir du mode et du message, il trouve
immédiatement l'ensemble des méthodes qui fournissent le service du message dans le mode. Une liste
vide signifie que le message n'est pas exécutable dans le mode.
• Propriétés des Méthodes
Le méta-objet contient des informations concernant les propriétés de chaque méthode. Il les
utilise afin de choisir la méthode la plus adaptée au service demandé et au contexte. Parmi les
propriétés importantes dans le domaine d'intérêt on peut citer les durées d'exécution et la précision des
résultats.
• Relation entre messages et états de l’objet
Lorsque le comportement d’un objet est défini par une machine à états, les messages doivent
être exécutés dans les états où ils sont permis seulement. Les méta objets connaissent les méthodes
autorisées dans chaque état lorsque les objets ont des états.
• Dépendance d'état entre objets
Les objets dépendant de l'état d'un autre objet doivent être informés de l'état actuel de l'objet
dont ils dépendent. Dans ARTO la communication des états est prise en charge par les méta-objets. Ils
doivent connaître les dépendances entre les objets qu'ils contrôlent afin de communiquer les états.
Cette information et les services de communication d'état correspondants font partie de la
connaissance des méta-objets.
• Compatibilité entre méthodes
L'exécution concurrente de méthodes à l'intérieur de l'objet est contrôlée par les méta-objets.
Le méta-objet stocke les relations de compatibilité entre méthodes car deux méthodes incompatibles
ne doivent pas être exécutées en même temps.
90
8.2.1.2 Connaissance sur le contexte l’exécution
Le comportement dynamique des applications dépend fortement des propriétés du matériel
informatique et du support logiciel dans lequel elles s'exécutent. Quelques données du matériel tels
que le type et la vitesse de la CPU, la taille de la mémoire, la résolution de la vidéo, peuvent être
connues sans grande difficulté. Du coté système d'exploitation, les aspects tels que la politique
d'exécution des processus, la gestion des timers, le traitement des interruptions influent sur l'aspect
temporel des exécutions. Une connaissance complète et précise du contexte, particulièrement les
caractéristiques dynamiques, est pratiquement impossible à obtenir en raison de l'énorme complexité
des systèmes et de la difficulté à obtenir des informations détaillées concernant son fonctionnement.
Cependant une connaissance au moins élémentaire du contexte matériel et logiciel de base est
nécessaire.
Au début de l'application l'objet applicatif exécute des procédures pour connaître quelques
paramètres liés au support matériel et logiciel dans lesquels l’application se déroule.
8.2.1.3 Informations propres
Le méta-objet connaît aussi les caractéristiques de ses propres activités. Cette connaissance est
importante car l'utilisation des ressources par le méta-objet affecte leur disponibilité et doit être prise
en compte au moment des analyses. Le méta-objet garde des informations concernant les durées de ses
activités d'analyse. Il exécute des mesures au lancement de l'application pour connaître ces valeurs.
8.2.1.4 Informations collectives
Les méta-objets ont besoin d'informations concernant les autres méta-objets et les ressources
partagées. Par exemple, le méta-objet doit savoir quels sont les objets capables de fournir un service.
Pour des applications dans un environnement distribué les informations collectives doivent
inclure aussi des données sur des objets distants.
8.3 Contrôle du comportement de l'objet
Les méta-objets appliquent des politiques locales pour contrôler le comportement des objets
spécialement pour décider du traitement des messages. Par exemple un objet peut choisir les messages
à exécuter selon leur date d’arrivée ou selon leur importance.
Les comportements sont aussi déterminés par les caractéristiques de fonctionnement propres à
chaque objet. Par exemple, lorsqu'un objet a des états, l'exécution des messages est restreinte aux états
dans lesquels ils sont permis.
En général plusieurs facteurs affectent le comportement définitif de l’objet et sont pris en
compte par le méta-objet au moment de décider.
91
8.3.1 Actions de gestion : sélection de message et de méthode
La gestion de la QoS agit principalement sur deux aspects du traitement des messages : dans le
choix d'une action pour chacun d'eux lorsque le contrôleur analyse les messages, et dans la sélection
de la méthode qui fournira le service, au démarrage de l'exécution.
Plusieurs actions sont possibles pour les messages dans la queue, mais l'exécution du service
demandé est l'objectif principal. La sélection du prochain message à exécuter est une décision qui
dépend principalement de la politique locale de l'objet. D’autres facteurs tels que le mode de
l'application, l'état de l'objet, les propriétés des messages, le contexte, etc. sont aussi pris en compte
par le contrôleur.
La méthode à exécuter pour un message est choisie parmi les méthodes disponibles pour le
service demandé. Elles sont définies dans une table du méta-objet et celles qui satisfont les besoins de
QoS de la requête sont candidates. Cependant celle d'entre elles qui sera effectivement exécutée est
décidé au dernier moment, juste avant de lancer l'exécution. Ce choix permet au méta-objets une
adaptation plus fine au contexte.
8.4 Critère principal de QoS
Pour le domaine du temps réel mou la "réduction des fautes temporelles" a été choisie comme
le critère principal de QoS des objets ARTO. Il faut noter que pour le modèle tous les événements
affectant le système ne sont pas connus à l'avance, et que des fautes temporelles se produiront en
situation de surcharge. Des actions sont prévues dans la conception des objets ARTO pour contrôler la
dégradation qui en résulte.
8.4.1 Contrainte temporelle
Parmi les contraintes temporelles possibles, la date d'échéance des services a été choisie dans
ARTO pour guider les décisions de QoS. Elle a été choisie car elle est une des plus représentative des
contraintes des systèmes temps réel.
Dans le cas où un message est contraint par une date de disponibilité16, le client retient la
requête jusqu'à sa date de disponibilité. De cette façon, tout message qui arrive peut être exécuté
immédiatement.
8.5 Traitement des messages : décisions à deux niveaux
Dans ARTO les décisions sur le traitement de messages sont effectuées dans deux étapes. La
première est réalisée par chaque contrôleur à l'intérieur des objets et concerne principalement les
décisions sur les messages dans la queue. La deuxième étape se situe au niveau global et agit sur tous
les messages de tous les objets choisis pour exécution. Cette activité globale est réalisée par les
16 Date de disponibilité : date à partir de laquelle le message peut être exécuté.
92
contrôleurs locaux lors d’événements comme le choix d'un message pour exécution ou la fin de la
réalisation d'un service. Les contrôleurs exécutent le même code appelé ordonnanceur lequel est
destiné principalement à planifier l'utilisation de la CPU.
La figure 8.2 illustre les deux niveaux de décisions. Au niveau local chaque objet décide
indépendamment sur le traitement des messages dans sa queue. Au niveau global, l’ordonnanceur gère
l'utilisation de la CPU17.
Décisions locales :traitement desmessages, sélectionde méthodes.
Décisions globales :gestion de tâches.
Couches de support :gestion de processus,du matériel, etc. Système d'exploitation
Ordonnanceur
Figure 8.2. Décisions à deux niveaux.
8.5.1 Messages
Dans ARTO les messages portent les demandes de services et les besoins de QoS des clients.
Au moment où le serveur reçoit un message, le contrôleur décide son traitement. Bien que la plupart
du temps il s'agisse de l'exécution d'une méthode de l'objet pour satisfaire le service, plusieurs actions
sont possibles en fonction du service demandé, des propriétés du message, du mode de l'application,
de l'état de l'objet, du contexte, des politiques en vigueur, etc. Les propriétés importantes des messages
sont décrites dans la suite.
8.5.1.1 Importance
L'importance est un attribut des messages ARTO qui caractérise la valeur relative que
l'exécution du message a pour le système. Cette distinction entre messages sert au contrôleur à faire
des choix par exemple comme politique locale de sélection de messages ou en situation de surcharge.
Cinq valeurs d'importance ont été définies, de la plus haute à la plus base : urgent, garantie, haute,
normal et basse.
• Urgent : ce sont les messages de plus haute importance qui sont normalement envoyés
dans des situations critiques. Ils ont la plus haute priorité d'exécution.
17 Une interaction avec le système d'exploitation est nécessaire afin que les décisions de l'ordonnanceur soient réalisées comme souhaité.
93
• Garanti : ce sont les messages pour lesquels l'exécution est garantie par le serveur. Le
seul cas où la garantie pourrait être brisée, est par l'exécution d'un message urgent.
• Haute : ce sont les messages avec une importance haute.
• Normal : type de message d'importance normale.
• Basse : réservé aux messages sans contraintes de temps.
8.5.1.2 Paramètres
Les paramètres des messages portent les informations nécessaires pour réaliser la fonction
demandée et aussi celles qui définissent les besoins de QoS de la requête. Parmi ces derniers se
trouvent :
• L'importance
• La date d'échéance
• La qualité souhaitée (précision, ...)
• La périodicité des messages périodiques
• Des actions liées aux événements (par exemple, lorsque l'exécution n'aboutit pas)
• Le type d'exécution accepté
8.5.1.3 Etapes d'un message
A partir du moment où le message arrive au serveur il passe par deux étapes principales :
attente et planification.
a) Attente : étape dans laquelle un message reste dans la queue car le contrôleur ne l'a pas
encore choisi pour exécution. Les raisons par lesquelles le message doit attendre sont très
variées, parmi lesquelles :
• En attente d'un thread libre : si tous les threads de l'objet sont occupés
• Non exécutable dans le mode actuel : si le message n'a pas de méthodes définies pour
son exécution dans le mode actuel de l'application
• Non exécutable dans l'état actuel : si le message n'est pas permis dans l'état actuel de
l'objet
• En attente de ressource : si les ressources requises pour l'exécution du message ne sont
pas disponibles.
• Non compatible avec les méthodes en cours : lorsqu'il existe des conflits entre les
méthodes qui fournissent le service et celles déjà planifiées.
b) Planifié : étape dans laquelle le message a été choisi et planifié pour exécution. Le message
a passé les analyses du contrôleur et il peut être exécuté. Dans cette étape les messages
peuvent passer par différentes situations :
94
• En attente : si le message est dans le planning, mais son exécution n'a pas encore
démarré.
• Enlevé du planning : si le message a été enlevé du planning pour planifier un message
plus important. Il est déposé dans une queue de messages "enlevés du planning".
• En exécution : si l'exécution d'une méthode associée au message a commencé.
• En attente de retour asynchrone : lorsque la méthode attend l’arrivée d’une réponse.
Le message est refusé si le contrôleur trouve que les conditions actuelles de l'objet et du
contexte ne permettent pas de satisfaire la requête telle que spécifiée par le client. Ce dernier est averti
et doit décider quoi faire avec le message.
Dans tous les cas l'arrivée de la date d'échéance déclenchera une faute temporelle sur le
message correspondant. C'est le client qui doit décider du destin du message.
Si la date d'échéance arrive lorsque le message est en exécution, le client peut décider de
continuer ou de l'arrêter. Dans ce dernier cas, un problème important à résoudre est la récupération des
ressources allouées au message. L'exécution peut continuer si elle ne met pas en danger l'exécution des
prochaines tâches du planning.
Après que le message a été traité par le serveur sa situation peut être :
• Fini sans faute : lorsque l'exécution du message se termine sans faute temporelle
• Date d'échéance dépassée : lorsque la date d'échéance arrive avant que l'exécution du
message soit terminée. L'ordonnanceur peut continuer l'exécution seulement si elle ne met
pas en danger les messages suivants du planning.
La figure 8.3 décrit les états par lesquels un message peut passer. Pour des raisons de clarté
seulement quelques événements sont affichés. Lorsque le message arrive au serveur il est dans l'état
"en attente dans la queue". Ensuite s'il est choisi localement, il est "enlevé de la queue" et peut passer
à "faute" s'il est refusé ou "planifié" s'il est accepté dans le planning. Lorsque le message est dans la
queue sans être planifié et que sa date d'échéance arrive, une faute temporelle se produit et le message
est enlevé de la queue.
Dans le planning le message attend son tour d'exécution. Si pendant l'attente une situation de
surcharge est détectée, l'ordonnanceur peut enlever le message du planning pour loger un message plus
important. Le message passe à l'état "enlevé du planning". Dans cet état il risque de ne pas être
exécuté. Si jamais le temps libre du planning le permet, l'ordonnanceur peut réinsérer le message dans
le planning. Il peut aussi décider de démarrer son exécution à partir de l'état "enlevé du planning" si sa
date d'échéance est la plus proche et le temps libre du planning le permet.
Lorsque l'ordonnanceur démarre l'exécution d'un message il passe à l'état "en exécution".
Pendant l'exécution le message peut changer d'état entre "en exécution" et "en attente, déjà démarré"
95
Planifié
En attentedans laqueue
Enexécution
Enlevédu
Planning
refusé
En attente,déjà
démarré
datedépassée
Fini
Datedépassée
datedépassée
datedépassée
datedépassée
Récupérationde ressources
faute
Datedépassée
Enlevé dela queue
Fini,interrompu
Fini,dépassement
choisilocalement
accepté dans leplanning
Figure 8.3. Etats des messages.
plusieurs fois soit parce qu'un message avec date d'échéance plus proche est démarré ou parce qu'il
doit attendre un événement particulier. Lorsque sa date d'échéance arrive le message peut passer à
l'état "récupération de ressources" ou continuer en "en exécution" ou "en attente, déjà démarré".
Lorsque l'exécution du message se termine sans dépasser la date d'échéance, il passe à l'état "fini".
Tous les messages qui ont passé par l'état "planifié" peuvent être arrêtés suit à l'arrivée des dates
d'échéances. Ils passent à l'état "récupération de ressources".
Si le client décide continuer l'exécution après la date d'échéance dépassée, le message reste en
exécution, mais avec une importance basse, pour ne pas mettre en danger les messages du planning.
Lorsque son exécution finie, il passera à l'état "Fini, dépassement".
8.5.2 Traitement local
L'objectif principal du traitement local est de choisir le message à planifier. Lorsqu’un
message arrive ou un service se termine, le contrôleur commence une analyse de la queue. Tous les
messages passent par l’analyse et à la fin il reste ceux qui sont susceptibles d’être exécutés. Le
96
contrôleur applique un critère de décision particulier pour choisir un des messages. Bien que les
critères et mécanismes de décision locaux soient particuliers à chaque objet, le processus général de
l'analyse est similaire pour tous.
8.5.2.1 Disponibilité des threads
La première condition à vérifier par le contrôleur est l'existence d’un thread libre. Si tous les
threads sont occupés les messages doivent attendre. Cette situation de blocage peut provoquer des
fautes temporelles, ce qui peut être critique s’il s’agit d’un message urgent. Pour alléger le problème
une idée est d'augmenter le nombre de threads par objet. Cette solution réduit le risque de blocage de
messages par manque de threads mais elle ne l’élimine pas totalement18. Son principal désavantage est
que trop de threads par objet peuvent avoir un effet négatif sur les performances de l'application19.
8.5.2.2 Réservation de threads
L'absence de threads libres pour exécuter les services est un problème grave si c'est un
message urgent qui doit attendre. Une solution basée dans la réservation de threads a été conçue pour
les objets ARTO. Il s'agit de réserver un ou plusieurs threads de l'objet pour l'utilisation exclusive des
messages urgents. Les threads réservés sont seulement affectés aux messages urgents dans le cas où
les threads normaux sont tous pris. Néanmoins la solution définitive au problème n'est pas garantie car
le nombre de threads réservés peut devenir insuffisant. Un désavantage à noter est que les threads
réservés sont des ressources inutilisées si aucun message urgent ne les utilise.
La quantité de threads à réserver est un paramètre qui peut être défini pour chaque objet et qui
peut être modifié dynamiquement par le méta-objet. Ainsi le nombre de threads de réservation peut
être une quantité variable qui dépend des besoins de l'application. Par exemple, il peut être lié au mode
de l'application de telle façon que dans un mode M1 le nombre de threads de réservation soit une
quantité X et dans un mode M2 une quantité Y.
8.5.2.3 Ensemble des méthodes associé à un message
Une table du méta-objet contient une liste de méthodes pour chaque message et pour chaque
mode de l’application. Au début de l’analyse d’un message, le contrôleur construit un ensemble de
méthodes avec toutes les méthodes trouvées dans la table pour le message dans le mode actuel de
l’application, et celles que le méta-objet lui-même peut apporter. Les méthodes sont toutes
susceptibles de fournir le service mais avec des propriétés différentes (durée, précision, etc.). Au fur et
à mesure que l’analyse progresse quelques méthodes peuvent être éliminées de l’ensemble. Si à la fin
de l’analyse il reste au moins une méthode dans l’ensemble, alors le message est candidat à être
planifié.
18 Le nombre de threads peut toujours être insuffisant. 19 Le temps destiné à la gestion des threads peut être important en raison des changements de contexte.
97
8.5.2.3.1 Satisfaction des contraintes
Les méthodes sélectionnées doivent satisfaire les besoins spécifiés dans la requête. Par
exemple lorsqu'elle spécifie le besoin d'une réponse avec une précision située entre les valeurs
minimales et maximales Pmin et Pmax, la réponse des méthodes choisies doit avoir une précision
située entre ces deux valeurs.
Il faut noter que chaque contrainte ajoute des exigences additionnelles à la sélection et que
plus il y a de contraintes, plus leur satisfaction devient difficile.
8.5.2.3.2 Durée des méthodes
La durée des méthodes est un facteur important qui détermine si le service peut être exécuté ou
non dans le temps libre du processeur. Les contrôleurs peuvent vérifier les durées pour décider si une
méthode est à inclure ou non dans l'ensemble des méthodes. Cependant ils ne refusent pas une
méthode parce que sa durée d'exécution est trop grande. D'abord parce que les durées sont des valeurs
au pire cas20. Les durées réelles seront plus petites à l'exécution. En plus, comme le planning est
construit avec un critère pessimiste pour assurer l'exécution des méthodes au pire des cas, le temps
libre croît normalement à chaque fin d'exécution parce que, en général, tout le temps affecté n'est pas
utilisé. Ainsi, la durée d'une méthode n'est pas un critère pour l'inclusion dans l'ensemble des
méthodes. La décision finale par rapport aux durées est une décision au niveau global prise par
l'ordonnanceur. Néanmoins pour qu'un message soit planifié, il doit avoir au moins une méthode qui
loge dans le planning.
8.5.2.3.3 Méthodes de l'objet
La capacité d'adaptation d'un objet est enrichie fortement par la variété de méthodes qu'il
apporte pour les services qu'il fournit. Dans les objets ARTO la principale expression de cette capacité
est la présence de plusieurs méthodes pour un même service, chacune avec des propriétés de QoS
différentes. Par exemple, un objet peut avoir 3 méthodes pour rendre un même service mais chacune
avec des précisions différentes. Elles peuvent aussi différer sur d'autres propriétés telles que les
ressources utilisées, leurs compatibilités, la qualité de leur réponse, leur durée, etc. Cette propriété
d'offrir plusieurs méthodes de durées différentes pour un même service est appelée time polymorphism
dans DRO [Takashio92].
8.5.2.3.4 Méthodes du méta-objet
Le méta-objet aussi offre des méthodes pour répondre aux requêtes. Par exemple, il peut
calculer une valeur à partir d'une projection sur des valeurs historiques ou encore définir une valeur
par défaut comme réponse à une requête.
20 WCET
98
Ce type de réponse peut être contraint par des spécifications des clients. Par exemple ils
peuvent limiter le nombre de valeurs consécutives calculées de cette façon.
8.5.2.4 Traitement des messages urgents
Les messages urgents sont traités avec une haute priorité. Ils sont immédiatement exécutés dès
qu’ils sont planifiés. Le contrôleur arrête tout message non urgent en exécution et démarre l’exécution
de l’urgent. S’il se trouve qu’un message urgent est déjà en exécution alors celui qui arrive sera
exécuté immédiatement si sa date d'échéance est la plus proche, sinon il doit attendre son tour.
8.5.2.5 Validité du message
Les messages sont bloqués lorsqu'ils n'ont pas de méthodes exécutables dans le mode actuel de
l'application ou dans l'état actuel de l'objet.
Mode de l'application
Pour qu'un message soit exécutable au moins une méthode doit être définie pour le message
dans le mode en cours. Les messages non exécutables restent dans la queue.
Etat de l'objet
Pour les objets associés à des états, le contrôleur vérifie la validité des méthodes dans l'état
actuel. Les messages sans méthodes valides dans l'état ne sont pas exécutables et restent dans la queue.
8.5.2.6 Compatibilité avec les méthodes en cours d’exécution
Le contrôleur analyse la compatibilité des méthodes associées aux messages avec les
méthodes déjà en exécution. Il élimine celles qui ont des problèmes de compatibilité les empêchant de
s’exécuter en même temps.
Comme résultat de l'analyse des messages dans la queue, ne resteront que ceux contenant des
méthodes capables d'être exécutées sans problème.
8.5.2.7 Décision locale
Le contrôleur applique une politique locale particulière pour sélectionner le message qui sera
planifié. Parmi les politiques possibles on peut citer :
• FIFO : le message le plus ancien est choisi.
• Importance : le message avec la plus grande importance est choisi.
• Date d'échéance : le message avec la date d'échéance la plus proche est choisi.
• Durée la plus petite : le message avec la méthode de plus courte durée, est choisi
Toute autre politique de choix est possible et peut être inclue dans le méta-objet. En plus, elles
peuvent être changées dynamiquement en fonction des besoins des objets. A certains moments un
99
méta-objet peut appliquer une politique P1 et à un autre une autre P2. La politique en vigueur peut
aussi être choisie par exemple en fonction du mode de l'application ou de l'état de l'objet.
Le traitement local peut être visualisé comme une série de "filtres" par lesquels passent les
méthodes associées aux messages. Seulement ceux qui finissent avec au moins une méthode qui
satisfait tous les filtres, sont candidats pour être planifiés. La figure 8.4 montre un schéma du
traitement local visualisé comme un filtrage. L'exemple montre l'analyse du message messagei.
Initialement l'ensemble de méthodes associé au messagei contient 6 méthodes (m1 à m6) capables de
fournir le service. Elles passent par des filtres successifs et quelques-unes sont éliminées. A la fin du
filtrage, deux méthodes, m1 et m5, restent dans l'ensemble, alors messagei peut être exécuté. Après que
tous les messages ont été ainsi traités, le contrôleur choisit l'un d'entre eux et le transfère à
l'ordonnanceur pour le planifier.
Ensemble initialde méthodes
pour messagei
Filtre de validitédans l'état de
l'objet
Filtre de compa-tibilité avecméthodes en
cours d'exécution
Autres filtres
Ensemble finalde méthodes
pour messagei
m4
m1 m2
m3 m5
m6
m4
m1 m2
m5
m4
m1
m5
m1
m5
messagei
messagei
messagei
messagei
Messagescandidats pourêtre planifiés
Figure 8.4. Traitement local vu comme un filtrage.
8.5.3 Traitement global
La deuxième étape du traitement des messages s'effectue au niveau global et concerne des
décisions sur tous les messages choisis par les méta-objets pour exécution. L'objectif principal de cette
étape est de maintenir un plan d'utilisation du processeur pour minimiser le nombre de fautes
100
temporelles. Un autre objectif des décisions globales est d'augmenter la QoS fournie en fonction du
contexte.
Avant de continuer la description du traitement global, il est nécessaire de faire une brève
réflexion concernant l'optimisation de la QoS dans le cadre du modèle ARTO, afin de mieux
comprendre les choix faits pour le traitement global.
8.5.3.1 Optimisation de la QoS
L'optimisation de la QoS dans le contexte de la gestion dynamique est un problème difficile à
résoudre. D'abord parce que l'information complète concernant les événements et la charge du système
n'est pas disponible à l'avance. Les messages arrivent sans préavis, changent la situation, et rendent
obsolète l'optimisation existante. Ensuite parce que les calculs sont faits sur la base des valeurs des
durées d'exécution de méthodes au pire cas. Les durées réelles seront connues à la fin d'exécution
seulement et peuvent demander une nouvelle optimisation. Enfin parce que le temps processeur
qu'utilise un algorithme d'optimisation peut être inacceptable, spécialement dans des conditions de
surcharge où des décisions rapides sont requises.
8.5.3.2 Une solution par la voie heuristique
Une solution de type heuristique est plus faisable pour le domaine d’application du modèle
ARTO. Bien qu'elle n'assure pas un résultat optimal elle peut donner de bonnes solutions dans des
temps raisonnables. Dans ARTO, l'heuristique qui a été conçue pour guider les décisions globales
prend en compte l'objectif principal de réduire le nombre de fautes temporelles et aussi d'augmenter la
QoS fournie. Le problème n'a pas de solution simple. D'un côté l'exécution de méthodes de courtes
durées pour chaque message favorise la réduction des fautes car cela permet d'exécuter plus de
messages. Néanmoins du côté de la QoS, ces méthodes ne fournissent pas la meilleure qualité21 et les
méthodes de plus longue durée sont souhaitables. Sous un autre aspect, la surcharge complique la
situation car elle provoque des fautes temporelles et brise toute prédictibilité.
La solution heuristique adoptée pour les objets ARTO considère ces aspects et applique les
critères suivants :
• Réduction des fautes : c'est l'objectif principal établi pour le modèle ARTO. Il est le
critère principal qui guide le traitement global des messages.
• Fournir la meilleure qualité : en fonction du contexte au moment de démarrer
l'exécution, la méthode avec la plus grande qualité est choisie.
• Prendre en compte l'importance des messages : face aux surcharges le contrôleur
favorise l'exécution des messages les plus importants.
21 Normalement une méthode de plus grande durée fournit un plus grande qualité.
101
La solution est décrite dans les points suivants.
8.5.3.3 Planification des exécutions
L'utilisation de la CPU est gérée par les méta-objets. Ils appliquent tous les mêmes critères
pour construire et mettre à jour un planning d'exécution des messages. En plus de la bonne utilisation
de la CPU la planification permet vérifier le respect des dates d'échéance et de détecter le plus tôt
possible les situations de surcharge. La planification concerne seulement les messages que les méta-
objets ont choisi pour exécution. Si le message est accepté, une tâche est créée pour chaque message
en l'associant à un thread qui exécutera la méthode correspondante22.
8.5.3.4 Ordonnancement EDF
L'algorithme pour la planification de tâches dans ARTO se base sur le principe "la date
d'échéance la plus proche d'abord". Cet algorithme connu comme Earliest Deadline First ou EDF
[Liu73], à été choisi car il produit un planning optimal en cas de charge normale (lorsque le temps de
CPU disponible est plus grand ou égal au temps requis par toutes les tâches à exécuter). Il est aussi
simple et rapide. Cependant, un désavantage important est qu'il n'est pas optimal en cas de surcharge
et ne peut pas prédire quelles tâches auront des fautes. L'ordonnancement EDF dans ARTO inclut des
décisions pour affronter les surcharges.
8.5.3.5 Ordonnancement sur la base des WCETs
Les durées d'exécution des méthodes sont utilisées pour construire le planning d'utilisation de
la CPU. Ces durées ne sont pas nécessairement toujours les mêmes d'exécution en exécution, car elles
sont fortement dépendantes du contexte. Afin d'assurer qu'une tâche planifiée sera finie dans le temps
alloué, le temps d'exécution utilisé dans le planning est celui "du pire cas" ou WCET, qui correspond à
la plus grande durée constatée dans l'exécution de la méthode dans le contexte.
8.5.3.6 Ordonnancement avec la méthode la plus rapide
Lorsque plusieurs méthodes peuvent exécuter un même service, l'algorithme utilise la méthode
la plus rapide pour planifier le message. Ce choix réduit le nombre de fautes car il permet d'inclure un
plus grand nombre de messages dans le planning. Si la méthode loge le message est planifié. Dans le
cas contraire, une surcharge du planning est détectée et une faute temporelle peut se produire. La
situation est analysée par le contrôleur qui prend une décision.
8.5.3.7 En cas de surcharge : privilégier les messages les plus importants
L'ordonnanceur détecte une situation de surcharge lorsqu'il ne peut pas loger une tâche dans le
planning. Cette situation ne veut pas dire qu'une "vraie" surcharge du système s'est produite ou a été
22 Un thread planifié pour exécuter une méthode est appelée tâche.
102
détectée, car c'est un problème de planning seulement. De toute façon pour assurer l'exécution des
tâches planifiées, l’ordonnanceur construit le planning sous une approche pessimiste. Face à la
détection de surcharge, le choix des objets ARTO est de privilégier l'exécution des messages les plus
importants. Les contrôleurs enlèvent du planning les messages les moins importants pour libérer du
temps pour planifier les plus importants. Par cette approche, les applications ont une dégradation
contrôlée des services de type gracieux (graceful degradation) qui consiste en la réduction des services
des messages moins importants afin d'exécuter les plus importants.
Il faut préciser que ce choix peut avoir des résultats négatifs sur l'objectif de réduction du
nombre de fautes, car il se peut que plusieurs messages moins importants soient enlevés du planning
pour loger un message important. Néanmoins une analyse complète permettant une décision optimale
sur ce point est trop coûteuse en temps.
8.5.3.8 Exécution de la méthode la plus longe possible
Au moment de démarrer l'exécution d'une tâche, l'ordonnanceur choisit la méthode de plus
grande durée qui loge dans le temps disponible. Ce choix est possible parce que le planning est
construit avec les durées WCET des méthodes. Dans un cas normal, les durées d'exécution réelles sont
inférieures à WCET ce qui libère du temps qui peut être alloué à l'exécution du prochain message.
Il faut noter que les tâches enlevées du planning peuvent être exécutées au cas où le temps
libéré par les tâches exécutées le permet. A chaque fin d'exécution le contrôleur observe la queue de
tâches non planifiées et décide en conséquence. Si le temps disponible le permet et la date d'échéance
de la tâche enlevée est la plus proche alors elle est démarrée.
La figure 8.5 illustre un exemple d'insertion d'une nouvelle tâche dans le planning. Deux cas
sont montrés : l'insertion d'une tâche qui loge et l'insertion d'une qui ne loge pas. Le traitement est fait
au moment tA (temps d'analyse) par le contrôleur responsable de l'exécution du message. Dans 1), le
planning est composé par les tâches A, B, C, D, E, F et G avec des dates d'échéances dans le même
ordre. La date d'échéance (DLN) de la nouvelle tâche N se situe entre les dates d'échéances des tâches
E et F. Alors la tâche N doit être planifiée avant F et après E. Le temps de CPU disponible pour
l'exécution de N, tl, se trouve avant la tâche F. Il correspond à tl = t1+t2+t3. Comme WCETN <= tl, N
peut être planifiée. Pour insérer la tâche N dans l'ordre correct les dates du planning des tâches C, D et
E doivent changer. Le nouveau planning est montré en 2).
103
A B C D E F G
DLN
Nt1 t2 t3
A B C D E F GNt1
t2'
AB BH CN DG EN FL GNNH
t1 t2
DLM
MH
BH CN DG
EN
FL GNNH
t1'DLM
MH
Taches A et E enlevéesdu planning
tA
tA
tA
tA
1)
2)
3)
4)
AB
'
Figure 8.5. Exemple d'ordonnancement dans ARTO.
Dans 3) c'est la tâche M qui doit être planifiée. Elle a une date d'échéance DLM et le contrôleur
trouve que sa place se situe entre les tâches E et N. Le temps disponible de CPU pour son exécution
est tl' = t1 + t2, lequel est plus petit que WCETM, la durée de M. Le contrôleur détecte alors une
situation de surcharge du planning et fait une analyse basée sur l'importance des tâches. Il analyse les
tâches dont les dates d'échéance se trouvent avant celle de M et dont les importances sont plus basses
que celle de M. L'importance de M est H (high), alors les tâches d'importance B (basse) et N (normale)
sont candidates à sortir du planning, à savoir les tâches A, C et E avec importances respectives B, N et
N (voir figure 8.5). Le contrôleur considère d'abord les tâches d'importance basse. Si le temps qu'elles
libèrent ne suffit pas, le contrôleur continue avec les tâches d'importance normale. Si le temps libéré
par les tâches d'importance basse et normale ne suffit pas, alors la nouvelle tâche n'est pas planifiée.
Dans l'exemple illustré la nouvelle tâche est planifiée car les tâches A et E libèrent un temps suffisant.
Il est évident que la solution heuristique choisie n'assure pas des résultats optimaux pour les
objectifs de réduction de fautes et de maximisation de la qualité fournie. Le fait de privilégier la
planification d'un message important pourrait conduire à la faute de deux ou plus messages moins
importants. C'est le cas de l'insertion de la tâche M de l'exemple de la figure 8.5. D'un autre coté la
maximisation de la qualité d'une réponse par le choix de la méthode de plus longe durée réduit la
chance de planification de messages futurs. En plus, elle peut empêcher l'augmentation de la qualité
des prochains messages.
104
Cependant, le choix a été fait en raison de sa simplicité et rapidité de décision. De toute façon
la solution peut être enrichie.
8.5.3.9 Allocation de la CPU
Un mécanisme d'allocation de la CPU aux threads doit être mis en place. Il dépend fortement
de la façon dont le système d'exploitation gère les processus. Par exemple, pour Windows NT, le
modèle ARTO contrôle l'exécution des threads par une gestion dynamique de priorités23.
8.6 Contrats
L'approche pour traiter les contrats dans ARTO vise la réduction du temps des négociations.
La plupart des accords sont de type implicite, cela veut dire qu'ils sont établis comme politiques
globales de traitement de messages et sont connus par tous les objets. L'avantage de cette approche est
que les négociations ne sont pas nécessaires et l'interaction entre clients et serveurs est réduite. Le cas
des messages garantis est le seul contrat fait par négociation.
8.6.1 Accords implicites
La politique globale de traitement des messages a été conçue pour guider le comportement des
objets afin de fournir la meilleure QoS face à différentes situations. Elle représente les accords
implicites acceptés par les objets.
• Indépendance des serveurs. Le serveur est responsable de l'exécution des services.
Chacun décide indépendamment de la façon d'exécuter les messages qu'il reçoit.
• Critère de QoS. Le critère principal de QoS est la réduction des fautes temporelles. La
date d'échéance des requêtes est la seule contrainte temporelle à prendre en compte.
• Ordre d'exécution. L'ordre d'exécution des messages planifiés se base sur le principe
"la date d'échéance la plus proche d'abord" ou EDF. Cet ordre est brisé seulement
lorsqu'un message urgent arrive et en cas d'attente.
• Messages urgents. Les messages urgents sont planifiés pour exécution immédiate.
Lorsque plusieurs messages urgents sont présents, ils sont exécutés selon la politique
EDF.
• Situation de surcharge. Les messages moins importants sont enlevés du planning pour
faire place aux plus importants. Si la place ainsi libérée ne suffit pas, alors le message
n'est pas planifié.
• Assurance de la QoS minimale. Les services demandés seront fournis au moins avec la
QoS minimale demandée. Une QoS meilleure pourra être fournie selon les conditions au
moment de démarrer l'exécution du service.
23 Dans Windows NT l'ordre d'exécution des threads est déterminé par un système de priorités.
105
• Construction du planning. Le planning d'utilisation de la CPU est construit sur la base
des durées WCET des méthodes. Pour chaque message l'ordonnanceur planifie
l'exécution de la méthode de plus petite durée parmi celles qui fournissent le service.
• Choix de la méthode à exécuter. Au moment de démarrer l'exécution d'un message
l'ordonnanceur choisit la méthode de plus grande durée qui loge dans le temps disponible
de CPU.
8.6.2 Négociations explicites
Les contrats explicites sont des accords issus des négociations entre clients et serveurs. Dans
ARTO elles sont peu nombreuses afin d'éviter des interactions et réduire le temps de CPU qu'elles
utilisent. En fait le seul cas de contrat est celui des messages garantis, mais d'autres interactions sont
aussi identifiées comme des négociations.
8.6.2.1 Réception de messages
Les clients sont avertis si les besoins de QoS des messages ne peuvent pas être satisfaits par le
serveur. Le client décide s'il modifie les contraintes, annule la requête ou laisse le message tel qu'il est.
8.6.2.2 Messages garantis
Pour les messages garantis le serveur répond au client s'il garantit ou non son exécution. La
réponse est "immédiate" si son exécution ne met pas en danger de faute un message urgent ou garanti
en cours d’exécution. Sinon, le client doit attendre (il peut décider du temps maximum qu'il veut
attendre). Si la réponse est positive le message est planifié et le temps CPU pour son exécution est
alloué. Si la réponse est négative le message ne peut être traité que comme un message normal, et le
client doit décider.
8.6.2.3 Demande d'information
Les informations que les méta-objets stockent peuvent être consultées par les clients. Par
exemple un client peut demander l'état de l'objet ou si un service peut être fourni avant une certaine
date.
8.7 Techniques pour l'adaptabilité
L'adaptabilité des objets ARTO s'effectue par le choix du traitement des messages. Leur
comportement s'exprime par la façon dont ils réagissent aux demandes de service.
8.7.1 Traitement selon le mode
La première forme d'adaptabilité qu'on trouve dans ARTO est liée aux modes de l'application.
A chaque message les objets associent des actions différentes en fonction du mode. Il se peut que dans
106
un mode M1 un message ait 5 méthodes fournissant le service, dans un mode M2 il ne soit pas
exécutable, et dans un autre mode M3 son exécution soit optionnelle.
L'idée principale de l'adaptation des réponses selon le mode est que l'application puisse
satisfaire aux mieux les besoins du système dans les différentes situations par lesquelles il passe.
Chaque situation a des particularités qui demandent des comportements différents.
8.7.2 Polymorphisme
Une autre forme d'adaptabilité dans ARTO est celle du polymorphisme : plusieurs méthodes
peuvent satisfaire la requête mais avec des propriétés différentes. Pour la réduction des fautes
temporelles, l'existence de méthodes de différentes durées est très utile car cela permet de choisir la
méthode en fonction du temps processeur disponible. Evidement, la qualité fournie est différente selon
la méthode exécutée.
8.7.3 Exécutions spéciales
En plus des méthodes fournies par l'objet, le méta-objet peut mettre en œuvre des mécanismes
d'adaptation à travers le contrôle de l'exécution.
8.7.3.1 Task pair
Les exécutions Task Pair [Streinch95] ont été spécialement conçues pour respecter les
contraintes temporelles des requêtes. Dans ce type d'exécution deux méthodes sont définies : une
méthode principale et une méthode d'urgence. La méthode principale fournit le service demandé et
normalement sa durée au pire cas n'est pas connue ou elle est très grande par rapport à la valeur
moyenne. Une durée appelée optimiste est utilisée pour planifier sont exécution. D'un autre côté la
méthode d'urgence est une méthode spéciale, d'une durée WCET connue et petite, et qui est planifiée
pour être exécutée seulement si la méthode principale ne se termine pas avant la date de début de
l'urgente. Dans le cas où cette situation se produit, la méthode principale est arrêtée et la méthode
d'urgence démarrée. Cette dernière se charge principalement de laisser l'application dans un état
valide. Par contre, si la méthode normale aboutit, la méthode d'urgence est enlevée du planning sans
être exécutée.
Ce type d'exécution est recommandé pour les cas où la durée de la méthode normale n'est pas
connue ou lorsqu'il existe une grande différence entre ses durées optimiste et maximale. Pour sa
réalisation l'ordonnanceur planifie deux tâches : une avec la méthode normale et l'autre avec la
méthode urgente. Les deux tâches doivent loger dans le planning. La méthode d’urgence est planifiée
avec une importance "garantie" et avec la date d'échéance du message, DLM. La méthode normale est
planifiée avec la durée OCETN24
et avec une date d'échéance correspondant à la date d'échéance du
24 OCET : Optimist Case Exécution Time, ou Durée d'Exécution optimiste. C'est la durée d'exécution optimiste connue de la méthode normale. Elle doit être plus petite que WCET.
107
message moins la durée de la méthode d'urgence, DLM U
M U
- WCET . Si la méthode normale finit avant sa
date d'échéance alors son contrôleur annule l'exécution de la méthode d'urgence. En cas contraire, il
arrête l'exécution de la méthode normale (à la date DL - WCET ) et démarre l'exécution de la
méthode d’urgence. La Figure 8.6 (a) illustre la planification des deux tâches d'une exécution Task
Pair. La Figure 8.6 (b) montre la situation avec d'autres tâches présentes dans le planning.
DLM
DLM-WCETU
mUmN
(a)
DLM
DLM-WCETU
mUmN
(b) Figure 8.6. Planification d'exécution Task Pair.
8.7.3.2 Exécution de type N/M
Le type d'exécution N/M se base sur la possibilité d'exécuter ou non un message, selon une
contrainte spécifiée de type "N fois sur M". Par exemple, si la contrainte dit que le message doit être
exécuté au minimum 2 fois sur 3, le contrôleur a le choix de ne pas l'exécuter une fois sur 3. Il faut
noter que M correspond aux "dernières M fois". Alors, pour décider l'exécution du cas M+1, le
contrôleur doit évaluer ce qui s'est passé dans les derniers M-1 cas.
Ce type d'exécution peut être exprimé de plusieurs façons. Voici quelques exemples :
• Exécuter au minimum N fois sur M
Condition à vérifier : Si dans les derniers M-1 cas le message a été exécuté N fois ou plus,
alors la prochaine exécution peut être omise. Sinon, elle est obligatoire.
• Omettre au maximum N fois sur M
Condition à vérifier : Si dans les derniers M-1 cas l'exécution a été omise N fois, alors la
prochaine exécution est obligatoire.
• Omettre au maximum N fois sur M, avec au maximum X omissions consécutives
Condition à vérifier : Si dans les dernières X fois l'exécution a été omise X fois, alors la
prochaine exécution est obligatoire,
Sinon, si dans les derniers M-1 cas l'exécution a été omise N fois, alors la prochaine exécution
est obligatoire,
Sinon l'exécution suivante peut être omise.
108
Gestion des exécutions type N/M
Les contrôleurs ARTO gèrent ce type d'exécution par l'insertion d'une méthode nulle25 dans
l'ensemble des méthodes. Le contrôleur insère la méthode nulle lorsqu'il trouve que l'exécution peut
être omise. Postérieurement au moment de démarrer l'exécution l'ordonnanceur choisira la méthode de
plus grande durée qui loge dans le temps disponible de CPU. Il choisit la méthode nulle si une vraie
méthode ne loge pas.
En revanche lorsque la contrainte peut être brisée la méthode nulle n'est pas incluse dans
l'ensemble de méthodes et le message est planifié avec une importance garantie pour s'assurer qu'une
vraie méthode sera exécutée.
La figure 8.7 illustre l'utilisation de la méthode nulle pour gérer les exécutions de type "N fois
sur M". Dans le processus de construction de l'ensemble de méthodes pour le message à exécuter, le
contrôleur ajoute la méthode nulle si la contrainte associée à l'exécution "N fois sur M" n'est pas en
danger. Par contre, si elle est en danger, l'ensemble ne contient pas la méthode nulle.
8.7.4 Autres
8.7.4.1 Déléga
Dans un
objets qui s'exéc
lorsqu'un contrôl
Contrainte endanger?O ui N on
Planifier le messageΦ
Construire l'ensemblede méthodes
Ajouter méthodenulle
Figure 8.7. Insertion de la méthode nulle "Φ" dans l'ensemble de
méthodes pour gérer les exécutions de type "N fois sur M".
mécanismes
tion
environnement distribué les objets peuvent demander l'exécution de messages à des
utent sur des machines différentes. La délégation est un mécanisme par lequel,
eur conclut qu'un message ne peut être exécuté dans l'objet, il peut le déléguer à un
109
objet distant qui peut fournir le service. C'est une option qui peut être utile dans des situations de
surcharge ou lorsque les ressources nécessaires pour exécuter un message ne sont pas disponibles
localement.
La délégation peut être aussi une option de politique locale. Par exemple un objet peut avoir la
politique de délégation de tous les messages de basse importance vers un objet distant.
Pour que la délégation soit réalisable, il faut un mécanisme de communication distante qui
permette de trouver les objets destinataires. L'utilisation des objets "proxys" et des services de
localisation d'objets dans des systèmes distribués tels que Corba ou DCOM, peuvent être utilisés. Afin
que les objets puissent maintenir un contrôle sur leurs décisions de délégation de messages, une
connaissance concernant l'environnement distribué est nécessaire, en particulier les données associées
aux communications.
8.7.4.2 Actions avant et après
Le méta-objet peut exécuter des activités avant et après l’exécution d’un service. Par exemple,
il peut exécuter une méthode qui enregistre certains données, au moment où un message est choisi
pour exécution. De la même façon, il peut enregistrer des données après la fin de l’exécution d’un
message.
8.7.4.3 Réservation de temps de CPU
Les objets peuvent demander à l’ordonnanceur la réservation d’une quantité de ressources de
calcul, c’est à dire, une quantité de temps de CPU. Cette réservation peut être exprimée sous forme de
pourcentage sur un temps donné. Si la réservation est acceptée, l’ordonnanceur tient le compte du
temps CPU utilisé par l’objet pendant le temps de mesure. Ce décompte peut être programmé comme
l’exécution d’une méthode après exécution des messages des objets concernés. Lorsque le temps
processeur manque, l’ordonnanceur prendre en compte la quantité utilisée par les objets pour décider
de l’affectation du temps dans le planning. Si l’objet a utilisé plus de temps que celui qui lui a été
affecté, ses messages ne seront pas privilégiés. Par exemple, la méthode la plus petite sera choisie au
démarrage de l’exécution afin de réduire son pourcentage d’utilisation. Aussi, s’il faut décider entre
deux messages d’importance égale provenant d’objets différents, l’ordonnanceur privilégie le message
de l’objet qui a utilisé moins que son temps réservé de CPU.
25 Une méthode nulle est une méthode de durée 0 et qui ne fait rien.
110
9 Processus de développement
La construction d'applications avec les objets ARTO comprend deux domaines. D'un coté la
conception de la solution fonctionnelle au problème utilisateur et d'un autre coté la conception des
mécanismes de gestion de la QoS. L’idée pour le développement est de séparer clairement des deux
domaines. L'utilisateur doit se concentrer principalement sur les objets fournissant la solution au
niveau de base. Les méta-objets sont préfabriqués et la principale tâche de l'utilisateur est de leur
fournir les données particulières relatives à leurs objets de base.
9.1 Vision générale du processus de développement
Pour la construction d'applications orientées objets le langage de modélisation UML [OMG97]
est devenu un langage standard. Il permet de développer des solutions à travers des modèles
conceptuels exprimés par un symbolisme graphique. Pour UML il existe de nombreux logiciels de
développement (ROSE de Rational, Rapsody de I-Logix) qui interagissent avec d'autres outils de
développement et qui facilitent la génération de code. Le principe de base est d'utiliser des outils de
plus haut niveau possible afin de faciliter le développement. Des modules additionnels pour des
fonctions spécifiques peuvent être ajoutés si nécessaire. La figure 9.1 montre les principaux éléments
de l'environnement de développement envisagé. Au centre se trouve un AGL pour la construction des
modèles UML de la solution. Le code spécifique des objets (C++) est développé en utilisant un outil
de programmation. Une interaction entre l'AGL et l'outil de programmation permet maintenir une
relation cohérente entre le modèle et le fichier cible.
Toutes les classes de méta-objets sont préfabriquées et disponibles dans une bibliothèque. Le
développeur doit associer une classe de méta-objet à chaque classe d'objet et fournir aux méta-objets
les informations relatives à l'objet. Pour introduire cette information, un ensemble de fenêtres
Outil deprogrammation
(objets)
Fichier cible(C++)
AGL(UML)
BDAGL
Editeurs et outilsFenêtres sur le métaobjet
Etats
Compatibilités
ModesMessagesméthodes
Validationtemporelle
Autres ...
Bibliothèquecible
Figure 9.1. Schéma de l'environnement de développement.
111
spécifiques à chaque type d'information ou de propriété de l'objet a été conçu : états, compatibilités,
modes/messages, messages/méthodes, etc.
Enfin les interactions entre les différents outils de développement (AGL, Outils de
programmation et Editeurs des méta-objets) doivent être les plus automatiques et simples possible à
utiliser. Un environnement composé de Visual Studio comme outil de programmation et Rose pour
UML avec un "add-in" pour les décorations UML à été testé pour vérifier les idées.
9.2 Modélisation avec UML
La modélisation avec UML comporte la spécification de classes et relations dans différents
types de diagrammes. En particulier la structure du modèle est décrite par le diagramme de classes
(class diagram).
A chaque classe d'objet l'utilisateur doit associer une classe de méta-objet. Les méta-objets
ARTO sont fournis dans une bibliothèque accessible depuis l'AGL. Toutes les classes de méta-objet
ARTO descendent de la classe CRootMetaObject. Les méta-objets basiques disponibles dans ARTO
sont : CRootMetaObject, CMiniMetaObject, CMetaObject et CMetaStateDependent. La figure 9.3
montre la relation d'héritage entre les classes de méta-objets.
Classe_1
Classe_2 Classe_3
Figure 9.2. Diagramme de classes.
Figure 9.3. Cla .
CRootMetaObject
CMiniMetaObject
CMetaObject
CMetaStateDependent
sses des métaobjets dans ARTO
112
Chacune des classes apporte des fonctionnalités au modèle.
• CRootMetaObject : est la classe racine des méta-objets. Elle contient l'identifiant de
l'objet.
• CMiniMetaObject : c'est la classe qui contient tous les composants des méta-objets : les
threads, la queue de messages, l'espace pour les messages envoyés, etc. Elle contient
aussi l'ordonnanceur et la politique de décision locale
• CMetaObject : descendant de CMiniMetaObject, elle contient les mécanismes pour le
filtrage. Dans cette classe sont introduits l'analyse des messages, les tests de
compatibilité, la validité dans le mode et dans l'état, etc. Beaucoup des propriétés des
méta-objets se trouvent dans cette classe.
• CMetaStateDependent : classe descendant de CMetaObject qui contient les services de
communication entre objets dépendants par les états.
Toute autre classe peut être introduite par l'utilisateur comme descendante d'une des classes de
base d'ARTO. Sauf cas particulier, il faut une classe de méta-objet par classe d'objet pour que le méta-
objet puisse stocker toutes les informations spécifiques.
Lorsque l'utilisateur établit une relation entre une classe d'objet et une classe de méta-objet, il
doit fournir les informations relatives à l'objet au méta-objet. Dans l'environnement AGL l'utilisateur
peut y accéder via des fenêtres spécialisées à cet effet. Ces fenêtres lui permettent d'entrer et d'éditer
Classe_1
Classe_2 Classe_3
CMetaObjet
CMetaObject_CCMetaObject_BCMetaObject_A
Figure 9.4. Relation entre classes d'objets et de métaobjets.
113
les informations qui formeront la base de connaissance du méta-objet. Les durées des méthodes, les
rapports entre mode de l'application messages et méthodes, les compatibilités entre méthodes, etc. sont
introduites directement dans l'environnement de développement. Toutes ces informations sont ajoutées
et sauvegardées avec le modèle. La figure 9.4 montre 3 classes d'objets chacune associée à une classe
de méta-objet. Ces dernières sont toutes descendantes de la classe CMetaObject.
Dans l'environnement pour le développement des applications ARTO, des fenêtres
spécialisées pour chaque type d'information permettent à l'utilisateur d'inclure dans les méta-objets des
données concernant à l'objet et le contexte. Le diagramme d'états est saisi en UML. La figure 9.5
illustre cette idée.
Classe_1
CMetaObjet_A
Etat/méthodes
Modes/messages/méthodes
Compatibilitéentre
méthodes
Politiques
Fenêtres dans l'AGLpour l'édition de la base
de connaissances dumétaobjet
Contexte
Figure 9.5. Fenêtres pour l'édition de la Base de Connaissances des métaobjets.
114
10 Résultats
Le modèle a été validé par des expériences réalisées avec un prototype qui réalise les
principales fonctionnalités des objets ARTO. L'objectif principal des expériences était de connaître les
effets des différents paramètres et politiques de prise de décision sur la QoS résultante. Les valeurs
mesurées sont le nombre de fautes temporelles et la qualité des services.
Le prototype est un programme écrit en langage C++ dont les classes des méta-objets des
objets sont définies à partir des classes des méta-objets ARTO de base. Une fenêtre d’interaction
permet à l’utilisateur le paramétrage et l’exécution des expériences. D’abord elle permet la création
d’un objet principal qui se charge de créer des objets de test. C’est à travers l’objet principal que
l’utilisateur modifie les paramètres d'exécution (nombre de messages envoyés aux objets, la
distribution des importances parmi les messages, la politique locale, la durée de l’exécution, etc.).
D'autres paramètres tels que le nombre de threads, la durée des méthodes, la longueur de la queue, le
nombre de méthodes par message, etc. doivent être modifiés dans le programme.
Pour tester l’effet du polymorphisme, pour chaque message sont définies trois méthodes avec
des durées WCET de 25, 150 et 400 µs. Leur durée effective est une valeur aléatoire uniformément
distribuée entre WCET/2 et WCET. Les dates d’échéances sont fixées à "now" + 5*WCET +
Uniforme(0..5000 µs) 26.
Les messages qui arrivent sont engendrés par l’objet principal qui les envoie aux objets de test
à raison de X messages chacun. Les dates des envois sont séparées par un temps aléatoire
uniformément distribué entre 3000 et 6000 µs. Le nombre minimum et maximum de X, la quantité de
messages à envoyer, sont fixés par l’utilisateur. Le programme exécute les expériences en
incrémentant X à partir de sa valeur minimale, afin de faire varier la charge. Les messages sont
effectivement envoyés par l’objet principal au moment du premier top d’horloge27 qui arrive après la
date d’envoi calculée aléatoirement (entre 3000 et 6000 µs). Comme la queue est rarement vide
lorsque le système est chargé, en général la loi d’arrivée des messages a peu d’importance.
Les durées d'exécution sont fixées par l’utilisateur à travers une option de la fenêtre
d’interaction du programme. La plupart des expériences étaient réalisées avec une durée de 2000
millisecondes, ce qui produit autour de 400 envois de messages pour chaque valeur de X. Dans toutes
les expériences, les valeurs minimales et maximales de X étaient 6 et 15 respectivement. Le nombre
approximatif de messages envoyés aux objets était 7200 pour X=6 et 18000 pour X=15.
Les résultats donnent les pourcentages de fautes temporelles (tâches ayant dépassé leur
échéance) en fonction de la charge pour différentes configurations (nombre de threads, politiques
locales, etc.). La charge varie entre 50 et 130 % et correspond au rapport entre la durée effective des
26 "now" représente la date actuelle. Uniforme(x..y) est une valeur aléatoire uniformément distribuée entre les valeurs x et y. 27 Le "top d’horloge" est fixé par programme pour se produire toutes les milisecondes.
115
messages soumis et le temps de CPU disponible. Les résultats montrent aussi les variations de qualité
fournie en fonction de la charge.
10.1 Effet du nombre de threads
Le nombre de threads par objet a un effet important sur le fonctionnement des objets ARTO.
Bien que de nombreux auteurs aient négligé la concurrence intra objet pour ne pas compliquer leur
modèle, la disponibilité de plusieurs threads par objet a un effet favorable dans la réduction des fautes,
spécialement pour les messages urgents. Son influence est spécialement importante dans des situations
où un message arrive avec une date d'échéance plus proche que celle des messages en exécution. Celui
qui arrive risque d'avoir une faute si aucun thread n'est disponible avant qu’il ne soit trop tard pour
démarrer son exécution. Le risque diminue avec un nombre plus grand de threads dans l'objet. Le
graphique de la figure 10.1 montre l’effet du nombre de threads sur les fautes moyennes. Par l’effet du
temps de changement de thread on observe que le nombre de fautes moyennes augment légèrement si
le nombre de threads augmente entre 1 et 4. A partir de 5 à 6 threads par objet les résultats ne changent
pas significativement. Les expériences ont été faites avec une méthode par message et une politique
locale basée sur l’importance (le message plus important est traité d'abord).
Lorsque le nombre de threads augmente, le problème du manque de threads diminue et tous
les messages qui arrivent peuvent passer au traitement global s'ils n'ont pas d'autres empêchements.
Lorsque le système devient plus chargé des messages peuvent être refusés. En raison de la politique
globale qui privilégie l'exécution de messages plus importants en cas de surcharge, les messages
refusés seront plutôt ceux d'importance basse, ce qui ne se voit pas sur ce graphique.
Fautes selon Nombre de Threads
0
5
10
15
20
25
30
70 75 80 85 90 95 100 105 110 115 120
Charge %
Faut
es %
1th 2th
3th 4th
5th 6th
7th 8th
10th 15th
Figure 10.1. Fautes en fonction du nombre de threads.
116
10.2 Réservation de thread
La réservation de thread a été conçue pour assurer la disponibilité de threads aux messages
urgents. Les threads réservés ne peuvent être utilisés que par les messages urgents et lorsque tous les
autres threads sont occupés.
La figure 10.2 montre les courbes des fautes sans et avec réservation. L’exécution sans
réservation à été faite avec deux threads par objet. Avec réservation, un thread est réservé pour les
messages urgents. Dans les expériences le pourcentage de messages urgents a été augmenté à 40% afin
de mieux visualiser les résultats. L'effet de la réservation d’un thread pour les messages urgents est
clair car il leur assure le passage immédiat à l'exécution. Cependant pour les autres messages les fautes
augmentent avec cette politique car ils ont un thread de moins et les threads qui restent sont partagés
avec les messages urgents.
Fautes sans et avec réservation de thread
0
5
10
15
20
25
30
35
40
45
50
60 70 80 90 100 110 120 130 140
charge
Nom
bre
de fa
utes
Urgent, sans réservation
Urgent, avec réservation
Autres, Sans reservation
Autres, avec réservation
Figure 10.2. Fautes avec et sans réservation de thread.
10.3 Effet de la Politique Locale
Les graphes de la figure 10.3 montrent l’effet des politiques locales sur les fautes pour 3
différents cas de nombre de threads par objet. Les politiques locales testées sont : FIFO, le message le
plus important d’abord, et EDF. Lorsque le nombre de threads est minimum (un thread par objet) la
politique qui produit le moins de fautes est EDF, mais la qualité moyenne est aussi la plus basse
(Figure 10.3a). Cependant, au fur et à mesure que le nombre de threads augmente les politiques locales
ont des résultats plus proches. Avec un grand nombre de threads (10 threads dans la Figure 10.3c) le
système devient pratiquement indépendant des politiques en termes de fautes et de qualité fournie.
117
1 thread
0
20
40
60
80
100
70 80 90 100 110 120 130 140Charge %
Qua
lité,
Fau
tes
%
Qua,+imp
Qua,FIFO
Qua,EDF
Fautes,+imp
Fautes,FIFO
Fautes,EDF
5 threads
0
20
40
60
80
100
70 80 90 100 110 120 130 140
Charge %
Qua
lité,
Fau
tes
% Qua,+imp
Qua,FIFO
Qua,EDF
Fautes,+imp
Fautes,FIFO
Fautes,EDF
(a) (b)
10 threads
0
20
40
60
80
100
70 80 90 100 110 120 130 140
Charge %
Qua
lité,
Fau
tes
%
Qua,+imp
Qua,FIFO
Qua,EDF
Fautes,+imp
Fautes,FIFO
Fautes,EDF
(c)
Figure 10.3. Qualité et Fautes en fonction des politiques, 1 (a), 5 (b) et 10 (c) threads par objet.
10.4 Politique Locale et Importance des Messages
Les effets des politiques locales sur les fautes selon le type de message (Urgent, Haute et
Normale) sont montrés dans les courbes de la figure 10.4. Pour toutes les politiques locales les
messages urgents ont le moindres de fautes. Le meilleur résultât (moins de fautes) se produit avec une
politique locale dont les messages sont choisis selon le plus important d’abord. La politique FIFO est
la que produit la plus grande quantité de fautes pour tous les types de messages.
118
Fautes selon politique et type de message(5 threads par objet)
0
10
20
30
40
50
60
70 80 90 100 110 120
Charge %
Faut
es
FIFO,Urgent
FIFO,Haute
FIFO, Normal
+imp,Urgent
+imp, Haute
+imp, Normale
EDF, Urgent
EDF, Haute
EDF, Normale
Figure 10.4. Effet de la Politique Locale selon importance des messages.
10.5 Polymorphisme.
Le polymorphisme est une des techniques importantes d’adaptation dans ARTO. Le fait
d’avoir plusieurs méthodes pour rendre le service donne à l'ordonnanceur la possibilité de choisir celle
qui s'adapte le mieux aux conditions de charge du système. Les exécutions ont été faites avec un, deux
et trois méthodes par message, de durées WCET, WCET/2 et WCET/8. La valeur de WCET utilisée
est de 400 µs et pour chaque méthode la durée réelle d’exécution est une valeur tirée au hasard entre
WCET/2 et WCET.
Le polymorphisme a deux effets principaux sur les résultats d'exécution. D'abord il a un effet
sur la qualité fournie car elle dépend de la méthode exécutée. Au fur et à mesure que la charge
augmente les méthodes de plus petite durée sont choisies et la qualité moyenne fournie diminue. Par
contre lorsque le temps de CPU disponible le permet les méthodes de plus grande durée sont exécutées
ce qui produit une plus grande qualité. Le graphe de la figure 10.5(a) montre la dégradation de la
qualité en fonction de la charge. Avec les paramètres d'exécution choisis les courbes ne montrent pas
une grande différence entre les résultats de 2 et 3 méthodes par message.
Un autre effet du polymorphisme s’observe sur le nombre de fautes en fonction de la charge.
Lorsqu'une seule méthode existe pour fournir le service les objets n'ont pas de choix. Si la charge ne
permet pas l’exécution de la méthode ils auront une faute. Cependant, lorsque plusieurs méthodes
existent avec des durées et qualités plus petites, le nombre de fautes peut être diminué pour un même
119
Qualité vs nombre de méthodes par message(5 threads)
70,0
75,0
80,0
85,0
90,0
95,0
100,0
70 80 90 100 110 120 130 140Charge
Qua
lité Qua,1meth
Qua,2meth
Qua,3ùeth
Fautes vs nombre de méthodes par message(5 threads)
0
5
10
15
20
25
30
35
40
45
50
70 80 90 100 110 120 130 140Charge
% d
e Fa
utes
Fautes,1meth
Fautes,2meth
Fautes,3meth
(a) (b)
Figure 10.5. Fautes et Qualité en fonction du nombre de méthodes par message.
niveau de charge. Les méthodes de plus petite durée seront exécutées pour éviter des fautes. Le graphe
de la Figure 10.5 (b) montre les courbes des fautes pour une, deux et trois méthodes par message.
10.6 Polymorphisme et politique locale
Pour une, deux ou trois méthodes par message la politique locale qui produit le minimum de
fautes est toujours EDF. Ce résultat était prévu car la politique globale elle aussi choisit le prochain
message à exécuter selon EDF et toute autre politique locale sera moins adaptée. Comme déjà vu, le
polymorphisme diminue le nombre de fautes pour un même niveau de charge, mais aussi la qualité
Fautes selon politique local et nombre de méthodes(2 threads)
0
5
10
15
20
25
30
35
40
70 80 90 100 110 120 130
Charge
% d
e Fa
utes
+imp, 1meth
FIFO, 1meth
EDF, 1meth
+imp, 2meth
FIFO, 2 meth
EDF, 2meth
+imp, 3meth
FIFO, 3meth
EDF, 3meth
Qualité selon politique local et nombre de méthodes(2 threads)
70,0
75,0
80,0
85,0
90,0
95,0
100,0
70 80 90 100 110 120 130Charge
% d
e Q
ualit
é
+imp, 1meth
FIFO, 1meth
EDF, 1meth
+imp, 2meth
FIFO, 2 meth
EDF, 2meth
+imp, 3meth
FIFO, 3meth
EDF, 3meth
(a) (b)
Figure 10.6. Fautes et Qualité selon la Politique locale et le nombre de méthodes.
120
fournie. La figure 10.6 contient les courbes des Fautes (a) et de Qualité (b) pour les différentes
politiques locales et nombre de méthodes par message.
10.7 Polymorphisme et importance des messages
La figure 10.7 montre l’effet du polymorphisme sur les messages selon leur importance. Les
messages plus importants ont toujours moins de fautes ce qui est dû à l’effet de la politique globale.
Cependant l’écart entre le nombre de fautes des messages plus importants (urgents) et moins
importants (normaux) diminue avec l'augmentation des méthodes par message.
Fautes; 1 méthode par message
0
2
4
6
8
10
12
14
16
18
20
70 80 90 100 110 120 130Charge %
Faut
es %
H, 1 méthode
N, 1 méthode
U, 1 méthode
Fautes; 2 méthodes par message
0
2
4
6
8
10
12
14
16
18
20
70 80 90 100 110 120 130
Charge %
Faut
es %
H, 2 méthodes
N, 2 méthodes
U, 2 méthodes
(a) (b)
Fautes; 3 méthodes par message
0
2
4
6
8
10
12
14
16
18
20
70 80 90 100 110 120 130Charge %
Faut
es %
H, 3 méthodes
N, 3 méthodes
U, 3 méthodes
(c)
Figure 10.7. Effet du polymorphisme dans les fautes selon l'importance des messages.
121
11 Conclusions
Dans des contextes d’exécution de plus en plus changeants et imprédictibles les solutions
logicielles traditionnelles semblent ne pas être les plus appropriées. En général elles se basent sur des
analyses statiques qui dépendent fortement de la connaissance du contexte d’exécution et des
événements affectant le système. Cette connaissance est aujourd’hui pratiquement impossible à
obtenir en raison de la complexité croissante des outils informatiques courants (matériels et logiciels).
En plus, les réseaux de communications et les systèmes distribués qu’ils supportent introduisent des
paramètres qui augmentent l’incertitude. Cette situation pose des problèmes si les applications ont des
besoins non fonctionnels qui dépendent du contexte. La qualité des services normalement liée aux
aspects non fonctionnels (précision, temps, périodicité, etc.) devient alors une propriété importante à
maîtriser. Dans les contextes d’exécution modernes, les applications rigides ont du mal à réussir car
elles agissent toujours de la même façon quel que soit le contexte. Dans ce sens une certaine flexibilité
est désirable pour faire face à un contexte trop dynamique. Le modèle proposé dans ce travail suit une
approche dans laquelle le contexte est pris en compte par l’application, et des décisions sont prises
dynamiquement pendant l’exécution afin de maximiser la qualité de service fournie. Il faut noter
cependant que la « maximisation » de la qualité est restreinte seulement au moment des prises de
décision car une maximisation de la qualité basée sur l’optimisation globale est impossible lorsque les
événements futurs ne sont pas connus. En plus le temps qu’une telle optimisation pourrait prendre peut
être prohibitif.
Etant donné le domaine d’application du modèle, le temps réel mou sans connaissance a priori
des événements, le modèle d’exécution a une importance fondamentale. Dans ce type d’applications la
réactivité des objets devient une obligation que le modèle d’objet actif choisi permet. En plus, dans
ARTO elle est augmentée par la possibilité d’avoir plusieurs threads par objet, ce qui s'est montré être
un très bon choix pour la réduction de fautes temporelles28. D’un autre coté l’inclusion des aspects
temporels dans les critères de qualité de service est une approche avantageuse car les autres aspects
non fonctionnels sont traités selon les mêmes principes, ce qui facilite les traitements.
Un des aspects importants dans la conception des objets ARTO était le respect au maximum
des propriétés de l’approche objet. Des principes tels que l’autonomie, la modularité et l'encapsulation,
ont guidé les décisions de conception. Par exemple les objets ARTO sont capables de décider eux-
mêmes leur comportement de façon indépendante, selon leur politique propre. D’un autre coté la
réutilisation, la portabilité, parmi autres, sont facilitées par l’architecture à méta niveaux. Elle permet
une claire séparation des domaines en isolant la solution au problème utilisateur de tous les aspects
non fonctionnels dépendants du contexte. La connaissance que le méta objet a du contexte et des
caractéristiques de l’objet qu’il contrôle (services, états, contraintes, etc.) garantit le meilleur choix de
comportement vis à vis de la dynamique du système.
122
Cependant pour l’utilisation contrôlée des ressources partagées, une gestion centralisée qui
agit au niveau global a été mise en œuvre. Ainsi la principale ressource utilisée par les objets, la CPU,
est gérée par l’ordonnanceur, un traitement global commun qui décide de l’exécution des tâches
lancées par les objets selon un critère EDF29. Ce critère assure le respect des dates d’échéance des
tâches en charge normale30. En cas de surcharge l’ordonnanceur privilégie l’exécution des tâches plus
importantes, contrôlant ainsi la dégradation. Dans le cas extrême seulement les tâches critiques sont
exécutées. Evidemment, la surcharge est une situation indésirable qui peut produire des dommages
dans le système car l’exécution des services avant leur date d’échéance n’est pas assurée. De toute
façon le méta objet est aussi muni de mécanismes d’adaptation qui sont utiles dans des situations de
surcharge tels que l’exécution de type « n fois sur m », réalisée via l’utilisation de méthodes nulles.
Quelles que soient les techniques appliquées par les objets, les situations de surcharge doivent être des
cas exceptionnels et pas la norme, sinon d'autres mesures devraient être considérées. Par exemple,
augmenter la puissance du matériel ou utiliser des systèmes d’exploitation adaptés.
Il faut noter cependant que les possibilités de fournir une bonne qualité de service dépendent
fortement de la richesse de méthodes que les objets apportent pour la réalisation des services. Une plus
grande variété donnerat aux méta objets plus de chances de prendre e une meilleuresdécisions
Un des aspects d’une grand importance et qui affecte directement la bonne performance du
modèle est que les propriétés temporelle des systèmes d’exploitation commerciaux de propos général
sont difficiles à maîtriser, spécialement lorsque la documentation nécessaire n’est pas accessible. De
nombreuses études ont montré que les services liés au temps dans de ce type de systèmes, tels que les
timers ou horloges, sont très peu fiables et que de solutions plus sophistiquées utilisant des services de
très bas niveau (matériel) sont nécessaires pour obtenir une meilleure précision. Sans doute que des
systèmes d’exploitation spécialement conçus pour des applications temps réel sont plus précis et
prédictibles pour les aspects temporels, mais dans ce travail le choix a été d’utiliser des systèmes
commerciaux normaux et de profiter des outils de développement existants. Aussi l’idée était de ne
pas attacher la solution à des systèmes peu accessibles.
En relation avec la construction d’applications ARTO, l’utilisation de langages de type 4GL
même dans une étape encore précoce a permis de vérifier que le choix était correct. Ces outils de
développement offrent aux concepteurs une grande puissance d’expression que facilite la construction
de systèmes complexes, leur documentation, la portabilité, la maintenance, etc. En particulier l'outil
ROSE offre en plus la possibilité d’ajouter des modules plug-ins permettant, par exemple la génération
automatique de code. ROSE permet aussi d'associer de nouvelles fonctionnalités aux événements tels
que le « click » d’un bouton de la souris. Les classes des méta objets sont des descendantes de classes
de base prise dans une bibliothèque. A partir d'informations supplémentaires introduites comme la
28 La réduction de fautes temporelles était le critère de qualité le plus important. 29 EDF, Earliest Deadline First, la tâche avec la date d’échéance la plus proche est exécutée d’abord. 30 Il faut noter que la date d’échéance est la seule contrainte temporelle présente dans le modèle.
123
durée des méthodes, la compatibilité de méthodes ou la taille de la file d'attente des messages, le code
des méta objets d'une application est engendré automatiquement. Ce type de capacités ouvre une
grande gamme de possibilités qui facilitent énormément la construction d’applications.
Les résultats des expériences avec le prototype montrent que les mécanismes d’adaptation des
objets ARTO leurs permettent effectivement faire face aux changements de contexte d’exécution.
D’un coté les politiques au niveau local leurs permettent de prendre des décisions adéquates pour le
traitement des messages en fonction de critères propres. D’un autre coté le traitement global assure la
bonne utilisation des ressources partagées et ainsi une meilleure qualité de service. Les résultats
permettent d'apprécier la façon dont les différents paramètres affectent le comportement des objets.
Effet du nombre de threads par objet
Le nombre de threads par objet affecte principalement le nombre de fautes. Un seul thread par
objet est trop limité car, s’il est occupé, tout message qui arrive doit attendre la libération du thread
pour avoir la chance d’être exécuté. C’est pour cela que plusieurs threads par objet réduit le nombre de
fautes. Cependant les exécutions ont montré qu’à partir d’un nombre particulier de threads les résultats
sont pareils et qu’une valeur entre trois et cinq semble être suffisante (Figure 10.1).
Effet de la politique locale
La politique locale qui produit le plus petit nombre de fautes est celle qui choisit les messages
selon EDF. C’est un résultat prévu car au niveau global les messages sont exécutés aussi selon EDF.
Les autres critères locaux produisent un nombre de fautes plus grand. Il faut noter que l’effet de la
politique locale est dépendant du nombre de threads par objet. Au fur et à mesure que le nombre de
threads croît le système devient indépendant des politiques locales car tous les messages ont la chance
de passer au traitement global sans attendre dans la queue (Figure 10.3).
Effet de la réservation de threads
La réservation de thread est une bonne technique pour réduire le risque de fautes des messages
urgents. Néanmoins elle peut augmenter les fautes des autres messages et un nombre plus grand de
threads peut être nécessaire pour réduire ce problème.
Effet du polymorphisme
Le polymorphisme est la technique qui donne aux objets ARTO leur grande capacité
d’adaptation. Lorsque plusieurs méthodes sont offertes pour un service, le traitement global peut
choisir la méthode la plus adéquate selon le contexte. La réduction des fautes est effective lorsqu'il y a
plusieurs méthodes par message. Choisir une méthode plus rapide diminue les fautes, mais la QoS
fournie diminue aussi. Cependant le contrôleur global choisit la méthode de plus grande qualité
capable d’être exécutée dans le contexte, ce qui assure la meilleure utilisation des ressources.
Effet de l’importance des messages.
L’importance des messages est prise en compte dans deux situations. Au niveau local lorsque
la politique de choix de message est fondée sur l’importance, et au niveau global lorsqu'un message ne
loge pas dans le planning. Dans la figure 10.4 on peut voir que les messages les plus importants
124
(Urgents) ont le minimum de fautes (presque zéro) lorsque la politique locale est basée sur
l’importance. C’est la conséquence du double effet de choisir le plus important d’abord au niveau
global et de privilégier les messages les plus importants en cas de surcharge. De toute façon pour les
autres politiques locales on observe aussi que les messages plus importants ont moins de fautes que les
moins importants, ce qui montre l’effet de la politique globale en cas de surcharge.
Travaux futurs envisagés
Plusieurs travaux peuvent être dérivés à partir du modèle ARTO tel qu’il est aujourd’hui. Des
travaux sont possibles pour compléter des idées déjà présentées dans ce document, pour ajouter des
nouvelles idées ou pour ouvrir des nouveaux domaines d’application.
Parmi les mécanismes d’adaptation au niveau méta qui peuvent être réalisés :
• L’exécution de type « task-pair »
• L’exécution de type « n fois sur m »
• Les réponses calculées à partir de l’historique (valeur moyenne des dernières N valeurs,
valeur estimée, etc.)
Il est aussi possible d'ajouter des mécanismes pour négocier l’utilisation de ressources :
• la réservation de temps CPU par les objets
• l’allocation de temps CPU basée sur un pourcentage d'utilisation maximum par quantum de temps.
Il faut des mécanismes de contrôle pour garantir le respect de ce type d’accords.
Des exécutions avant et après
Le méta objet peut exécuter des méthodes avant et après la réalisation des services. Bien que
cette capacité soit déjà inclue dans le prototype ARTO, elle n’a pas été essayée. Elle serait utile par
exemple, pour la sauvegarde des valeurs historiques à utiliser dans des réponses calculées par le méta
objet.
Appels enchaînés
Un sujet difficile à traiter mais qu’il est nécessaire de résoudre est le calcul de temps et la
propagation de contraintes liées aux appels enchaînés. C’est un problème complexe dont la discussion
a déjà commencé mais aucune solution n’a été encore envisagée.
Environnement de développement
En relation à l’environnement de développement, de nombreuses possibilités sont ouvertes.
D’abord la génération automatique de code peut être exploitée au maximum, permettant aux
programmeurs se concentrer dans la conception des solutions au plus haut niveau possible.
Ensuite des analyses peuvent être ajoutées dans des modèles exprimés avec ROSE. Par
exemple, des analyses temporelles des appels.
125
Un autre travail au niveau du cadre de développement est l’expression et l'analyse des besoins
de qualité de service. Des idées ont été déjà initiées pour l’expression des contraintes dans le style
UML [6].
Systèmes distribués
Les systèmes distribués offrent des possibilités intéressantes pour la mise en œuvre des objets
ARTO. D’abord la délégation de message peut être vraiment exploitée dans un environnement
distribué. Cependant plusieurs difficultés doivent être prises en compte, en particulier la localisation
des objets et tous les aspects associés (délais, identification, disponibilité du réseau, etc.).
Le problème de propagation de contraintes est un problème encore plus difficile dans des
environnements distribués, car en plus des temps de communication variables, les temps d’exécution
de méthodes distantes ne sont pas connus localement. La conséquence est que le planning local est
difficile à maîtriser.
Dans le contexte des systèmes distribués il faut sans doute analyser l’utilité que peuvent
apporter les logiciels de gestion d’objets tels que CORBA et DCOM. En plus des travaux ont été déjà
effectués afin d’ajouter à ce type de systèmes des services permettant la construction d’applications
temps réel distribuées.
126
12 Bibliographie [Blair94] BLAIR G., PAPATHOMAS M., COULSON G. et al. Supporting real-time multimedia behaviour in
open distributed systems: an approach based on synchronous languages. In : ACM Press. Proc. of the second ACM international conference on Multimedia, 1994, San Francisco, USA. New York, NY, USA, 1994, pp. 299-306.
[Brand 98] BRAND S. , NUTT G., BERK T. et al. A dynamic quality of service middleware agent for mediating application resource usage. In : IEEE Computer Society. Proc. of the 19th IEEE Real-time systems symposium, RTSS, december 1998, Madrid, Spain. Washington, DC, USA, 2001, pp. 307-317.
[Bobrow88] BOBROW D., DeMICHEL L., GABRIEL R. et al. Common Lisp object system specification., SIGPLAN Notices, September 1988, vol. 23, n° special issue.
[Burleson 93] BURLESON W., KO J., NIEHAUS D. et al. The Spring scheduling co-processor: a scheduling accelerator. In : Proc. of the International Conference on Computer Design, October 1993, Cambridge, MA, USA, pp. 140-144.
[Campbell 96] CAMPBELL A., AURRECOECHA C., HAUW L. A Survey of QoS architectures. ACM/Sjpringer Verlag Multimedia Systems Journal, Special Issue on QoS Architecture, 1998, vol. 6, n° 3, pp. 167-178.
[Caromel89] CAROMEL D. Service Asynchrony and wait-by-necessity. Journal of object oriented programming, 1989, vol. 2, n° 4, pp. 12-22.
[Carpenter97] CARPENTER B., ROMAN M., VASILATOS N. et al. The RTX real-time subsystem for Windows NT. In : Proc. of the USENIX Windows NT Workshop, (date) 1997, Seattle, Washington, USA, p 33-.
[Chiba93] CHIBA S., MASUDA T. Designing an extensible distributed language with a Meta-Level architecture. In : Proc. of The European Conference on Object Oriented Programming, ECOOP93, july 1993, Kaiserslautern, Germany, pp. 482-501.
[Chiba95] CHIBA S. A metaobject protocol for C++. In : ACM. Proc. of the 10th Annual Conference OOPSLA'95, October 1995, Austin, TX, USA, Vol. 30, pp. 285-299.
[Clark 92] CLARK R.K., JENSEN E.D., REYNOLDS F.D. An architectural overview of the Alpha real-time distributed kernel. In : Proc. of the USENIX Workshop on Microkernel and Other Kernel Architectures, April 1992, Seattle, USA,pp. 127-146.
[Cointe88] COINTE P. A tutorial introduction to metaclass architectures as provided by Class oriented languages. In : Proc. of the International Conference on Fifth Generation Computer Systems, FGCS’88, nov. 1988, Tokyo, Japan, vol.2, pp. 592-608.
[Desfray94] DESFRAY P. Object engineering - the fourth dimension. Paris, France : Addison-Wesley, Masson Editeur, 1994, 230 p.
[Desfray96] DESFRAY P. Modélisation par objets: la fin de la programmation. Paris : Masson, 1996, 360 p. [Fabre96] FABRE J.-C. Systèmes sûrs de fonctionnement : tolérance aux fautes par protocole à méta-objets.
L’objet, 1997, vol. 3, n° 1, pp. 9-28. [Ferber89] FERBER J. Computational reflection in Class based object oriented languages. In : Proc. of
OOPSLA'89, October 1989, New Orleans, LA, USA, pp. 317-326. [Foote89] FOOTE B., JOHNSON R.E. Reflective facilities in SmallTalk80. In : Proc. of OOPSLA'89, october
1989, New Orleans, LA, USA, pp. 327-335. [Furht91] FURHT B., GROSTICK D. et al. Real-time UNIX systems : design and application guide. Boston :
Kluwer Academic Publishers, 1991, 316 p. [Furht93] FURHT B. Real-Time computer systems : current and future trends. In : Proc. of the First IEEE
Workshop on Real-Time Applications, May 1993, New York, USA, pp. 1-6. [Guerraoui95] GUERRAOUI R. Les langages concurrents à objets. Technique et Sciences Informatiques, 1995,
vol. 14, n° 8, pp. 945-973. [Goldberg83] GOLDBERG A., ROBSON D. Smalltalk-80 : the langage and its implementation. Massachusetts,
USA : Addison Wesley Reading, 2nd édition, 1989, 585 p. [Harel87] HAREL D. StateCharts : a visual formalism for complex systems. Science of Computer Programming,
1987, vol. 8, pp. 231-274. [Honda92] HONDA Y., TOKORO M. Soft real-time programming through reflection. In : Proc. of IMSA
Workshop’92, Reflection and Meta-level Architecture, nov. 1992, Tokyo, Japan, pp. 12-23. [ISO93] ISO. The Reference Model of Open Distributed Processing (RM-ODP), ITU-T Recommendations
X.901 to X.904 | ISO/IEC 10746. Genève, ISO, 1984, 40 p. [ISO94] ISO. ITU-T Recommendation X.200 | ISO/IEC 7498-1 : Information technology - Open Systems
Interconnection - Basic Reference Model : The Basic Model. Genève, ISO, 1994, 59 p.
127
[ISO95] ISO. ITU-T Recommendation X.902 | ISO/IEC 10746-2 : Information technology - Open Distribution Processing - Reference model: Foundations. Genève, ISO, 1996, 20 p.
[ISO97] ISO. ITU-T Recommendation X.641 | ISO/IEC 13236 : Information technology - Quality of Service - Framework. Genève, ISO, 1998, 48 p.
[Jensen85] JENSEN E.D., LOCKE C.D., TOKUDA H. A time-value driven scheduling model for real-time operating systems. In : IEEE. Proc. of the Symposium on Real-Time Systems, November 1985, San Diego, CA, USA, pp. 112-122.
[Jones98] JONES M.B., REGEHR J. Problems you’re having may not be the problems you think you’re having : results from a latency study of windows NT. In : Proc. of the 5th IEEE Real-Time Technology and Applications Symposium – RTAS’99, june 1999, Vancouver, BC, CA, pp. 287-292.
[Kiczales91] KICZALES G. The Art of MOP. MIT Press, 1991, 335 p. [Kiczales92] KICZALES G. Towards a new model of abstraction in software engineering. In : Proc. of the
International Workshop on Object Orientation in Operating Systems, octobre 1992, Palo Alto, CA, USA, pp. 127-128.
[Lee98] LEE C., SIEWIOREK D. An approach for quality of service management. CMU-CS-98-165. Pittsburgh, PA, USA : School of Computer Sciences, Carnegie Mellon University, 1998, 30 p.
[Leslie97] LESLIE I., McAULEY D., BLACK, R. et al. The design and implementation of an operating system to support multimedia distributed applications. IEEE Journal on Selected Areas in Communications, 1996, vol. 14, n° 7, pp. 1280-1296.
[Lin98] LIN C., CHU H., NAHRSTEDT K. A soft real-time scheduling server on the Windows NT. In : Proc. of the 2nd USENIX Windows NT Symposium, August 3-5 1998, Berkeley, CA, USA, pp. 149-156.
[Liu73] LIU C.L., LAYLAND J.W. Scheduling algorithms for multiprogramming in a hard real-time environnement. Journal of the association for computing machinery, 2000, Vol. 20, N° 1, pp. 46-61.
[Locke86] LOCKE C.D. Best-Effort decision making for real-time scheduling. Ph.D. Thesis. Pittsburgh, PA, USA : Carnegie-Mellon University, 1986.
[Maes87] MAES P. Concepts and experiments in computational reflection. In : Proc. of the OOPSLA’87, 1987, Orlando, FL, USA, pp. 147-155.
[Malenfant96] MALENFANT J., JACQUES M., DEMERS F.N. A tutorial on behavioral reflection and its implementation. In : Actes de la première conférence internationale, Reflection'96, avril 1996, San Francisco, CA, USA, pp. 1-20.
[Masuhara92] MASUHARA H., MATSUOKA S., WATANABE T. et al. Object-Oriented concurrent reflective languages can be implemented efficently. In : Proc. of OOPSLA'92, October 1992, Vancouver, BC, CA, pp. 127-144.
[Matsuoka91] MATSUOKA S., WATANABE T., ICHISUGI Y. et al. Object-Oriented concurrent reflective architectures. In : Proc. of the ECOOP Workshop on Object-Based Concurrent Computing, July 1991, Geneva, Switzerland, pp. 211-226.
[McAffer] McAFFER J. Meta-Level programming with CodA. In : Proc. of the 9th European Conference on Object-Oriented Programming, ECOOP'95, august 1995, Aarhus, Denmark, p 190-214.
[Meyer92] MEYER B. Applying design by contrat. IEEE Computer, 1992, vol. 25, n° 10, pp. 40-51. [Miller 96] MILLER F., LAM H-M., MEI X., et al. Practical Experience with a smoothing algorithm for video
streaming. In : Proc. of the 7th International Workshop on Network and Operating System Support for Digital Audio and Video, may 1997, St. Louis, MO, USA, pp. 207-213.
[OMG97] OBJECT MANAGEMENT GROUP. Unified Modeling Language v. 1.1. OMG document ad/97-08-11 [en ligne]. August 1997. Disponible sur : http://www.omg.org/uml/ (consulté le 26.04.2001).
[Rajku 97] RAJKUMAR R., LEE C., LEHOCZKY J.P. et al. A QoS-based resource allocation model. In : Proc. of the IEEE Real-Time Systems Symposium, December 1997, San Francisco, CA, USA, p 298-.
[Ramamritham94] RAMAMRITHAM K., STANKOVIC J. Scheduling algorithms and operating systems support for real-time systems. Proceedings of the IEEE, 1994, vol. 82, n° 1, pp. 55-67.
[Ramamritham98] RAMAMRITHAM K., SHEN C., GONZALEZ O. et al. Using Windows NT for real-time applications : experimental observations and recommendations. In : Proc. of the Fourth IEEE Real-Time Technonogy and Applications Symposium, june 1998, Denver, CO, USA.
[RFC2205] NETWORK WORKING GROUP. Resource ReSerVation Protocol, Version 1 Functional Specification. Request for Comments: 2205, Category: Standards Track, Internet RFC/STD/FYI/BCP [en ligne]. Disponible sur : http://www.faqs.org/rfcs/rfc2205.html (consulté le 19.02.2002).
[RTP96] KLEIN R. The realtime transport protocol. Technical Report, Northwest Alliance for Computational Science and Engineering, 1996.
[RTX] Venturcom, Inc. Real Time Extensions (RTX) [en ligne]. Disponible sur http://www.vci.com (consulté le 12.06.2001).
128
[Selic92] SELIC B., GULLEKSON G., McGEE J. et al. ROOM : an object-oriented methodology for developing real-time systems. In : Proc. of the Fith International Workshop on Computer-Aided Software Engineering, July 6-10, 1992, Montreal, Quebec, Canada, pp. 230-240.
[Smith84] SMITH B.C. Reflection and semantics in Lisp. In : Proc. of the Symposium on Principles of Programming Languages, january 1984, Salt Lake City, UT, USA, pp. 23-35.
[Stankovic89] STANKOVIC J.A., RAMAMRITHAM K. The Spring Kernel: a new paradigm for real-time operating systems. ACM operating systems review, 1989, vol. 23, n° 3, pp. 54-71.
[Stankovic91] STANKOVIC J.A. The Spring architecture. In : Proc. of EUROMICRO ’90 Workshop on Real Time, june 1990, Horsholm, Denmark, pp. 104-113.
[Stankovic95] STANKOVIC J.A., SPURI M., DI NATALE M. et al. Implications of Classical Scheduling Results For Real-Time Systems. IEEE Computer, 1995, vol 28, n° 6, pp. 16-25.
[Streinch95] STREINCH H. Task pair scheduling : an approach for dynamic real-time systems. Journal of Mini and Microcumputers, 1995, vol 17, n° 2, pp. 77-83.
[Takashio92] KAZUNORI T. TOKORO M. DROL: an object-oriented programming language for distributed real-time systems. In : Proc. of the OOPSLA'92, oct. 1992, Vancouver, BC, Canada, pp. 276-294.
[Takashio93] TAKASHIO K., TOKORO M. Time polymorphic invocation : a real-time communication model for distributed systems. In : Proc. of the First Workshop on Parallel and Distributed Real-Time Systems, April 1993, Los Angeles, CA, USA.
[Terrier96] TERRIER F. A Real Time Object Model. In : Proc. of the TOOLS Europe’96 conference, feb. 1996, Paris, France, pp. 127-141.
[Tokuda90] TOKUDA H., NAKAJIMA T., RAO T. Real-Time Mach: toward a predictable real-time system. In : Proc. of USENIX Mach Workshop, oct. 1990, Berkeley, CA, USA, pp. 73-82.
[Tokuda93] TOKUDA H., KITAYAMA T. Dynamic QoS control based on real-time threads. Lectures Notes in Computer Science, 1994, n° 846, pp. 114-.
[Watanabe88] WATANABE T., YONEZAWA A. Reflection in an object-oriented concurrent language. In : Proc. of OOPSLA'88, Sept. 1988, San Diego, CA, USA, pp. 306-315.
[Yodaiken97] YODAIKEN V., BARABANOV M. A real-time Linux. In : Proc. of the Linux Applications Development and Deployment Conference, USELINUX, January 1997, Anaheim, CA, USA.
[Yokote92] YOKOTE Y. The Apertos reflective operating system : the concept and its implementation. In : Proc. of the Conference on Object-Oriented Programming Systems, Languages, and Applications – OOPSLA ’92, oct. 1992, Vancouver, BC, Canada, pp. 414-434.
129
13 Communications personnelles [1] CONTRERAS J. et SOURROUILLE J.-L. Adaptive Active Object. In : Workshop Reader of ECOOP'98
Workshop on Reflective Object-Oriented Programming and Systems, july 1998, Brussels, Belgium. Springer Verlag LNCS, vol 1543.
[2] CONTRERAS J. et SOURROUILLE J.-L. A Reflective Architecture for Real-Time. In : Proc. of the 7th Electrotechnical and Computer Science Conference, ERK'98, Sept. 1998, Portorôz, Slovenie, Vol. A, pp. 33-36.
[3] CONTRERAS J.L. et SOURROUILLE J.L.. EDF Improvements for Faults Reduction. In : Proc. of the IEEE International Symposium on Industrial Electronics, ISIE'99. July 99, Bled, Slovenie, Vol 1, pp. 75-78.
[4] BABAU J.Ph., COLNARIC M., CONTRERAS J.L., et al. Execution Model for Real-Time Server Object. In : Proc. of the IEEE International Symposium on Industrial Electronics, ISIE'99, July 1999, Bled, Slovenie, Vol 1, pp. 70-74.
[5] CONTRERAS J.l. et SOURROUILLE J.-L. A Scheduling Strategy to Preserve Object Autonomy. In : Preprints of the 25th IFAC Workshop on Real-Time Programming, WRTP’2000, Palma, Spain, May 2000, pp. 153-159.
[6] CONTRERAS J. L., SOURROUILLE J.-L. A Framework for QoS Management. In : Proc. of TOOLS’39. July 2001, Santa Barbara, CA, USA, pp. 183-193.
[7] SOURROUILLE J.-L. et CONTRERAS J.L. Objets Autonomes Adaptables. Journées Systèmes à composants adaptables et extensibles, Grenoble, 2002. [en ligne]. Disponible sur http://arcad.essi.fr/2002-10-composants/papiers_recus/long06-sourrouille.pdf (consulté le 4.11.2002).
130
