THÈSE de doctorat de l École des Mines de Paris Spécialité : Informatique temps-réel, Robotique, Automatique. Jean-Ferdinand SUSINI
|
|
- Jeanne Ève Bénard
- il y a 8 ans
- Total affichages :
Transcription
1 École des Mines de Paris Centre de Mathématiques Appliquées Sophia-Antipolis THÈSE de doctorat de l École des Mines de Paris Spécialité : Informatique temps-réel, Robotique, Automatique présentée par Jean-Ferdinand SUSINI L Approche Réactive au dessus de Java : sémantique et implémentation des SugarCubes et de Junior Soutenue le 11 septembre 2001 devant le jury composé de : Président : Rapporteurs : Directeur : Examinateurs : Gérard BERRY Florence MARANINCHI Gilles MULLER Frédéric BOUSSINOT Laurent HAZARD Jean-Bernard STEFANI
2
3 à mes parents Remerciements : En premier lieu, je voudrais exprimer ma reconnaissance à Florence MARANINCHI et Gilles MULLER qui ont accepté d être rapporteurs de ma thèse. Je tiens également à exprimer toute ma gratitude à Gérard BERRY qui m a fait l honneur de présider le jury. Je remercie particulièrement Laurent HAZARD d avoir accepté de participer au jury. Les quelques années de collaboration que nous avons eu ont été très enrichissantes pour moi. Qu il me soit également permis ici et à travers lui de remercier France Telecom R&D pour son soutient à ces travaux de recherche. Je remercie également Jean-Bernard STEFANI qui m a fait l honneur de faire partie du jury. A tout seigneur, tout honneur, je tiens tout spécialement à remercier mon chef, Frédéric BOUSSINOT, qui m a accepté comme disciple de l Approche Réactive. Au cours de ces quelques cinq années passées à ses côtés, j ai pu apprécier sa bonne humeur, son étonnante disponibilité (je crois que je connais aussi bien son bureau que le mien), sa grande patience, sa gentillesse et l humour omniprésent qu il nous prodigue. Inutile de préciser que le petit étudiant en physique que j étais a beaucoup appris à son contact sur cette discipline particulière qu est l informatique. Qu il me soit permis également de remercier ici tout particulièrement Valérie ROY qui, par ses précieux conseils, m a aidé à me réorienter et à atterrir au CMA, il y a quelques années après des études de physique. Merci aussi pour le travail énorme qu elle a effectué dans la relecture minutieuse de mon manuscrit. Je n oublie pas non plus les personnes qui constituent et ont constitué le CMA durant ces dernières années, ainsi que les membres du projet MEIJE et maintenant ceux du projet MIMOSA, auxquels j adresse une pensée émue et reconnaissante. Les nombreuses discussions et présentations que nous avons eu m ont permis, jour après jour, de me sentir un peu plus à l aise dans cette discipline d adoption et parfois m ont permis également de me remémorer de lointaines notions de physique. Merci pour leur accueil et l ambiance de travail agréable qu ils instaurent. Je salue les étudiants et compagnons de jeu ;-) que j ai côtoyé durant ces années : Raul ACOSTA-BERMEJO, Sebastien BOISGERAULT, Michel BOURDELLES, Yannis BRES, Christian BRUNETTE, Silvano DAL-ZILIO, Nicolas GOMEZ, Loic HENRY-GREARD, Karima MACHANE, Fabrice PEIX, Dimitru POTOP-BUTUCARU, Xavier THIRIOUX, Horia TOMA, Eric VECCHIE, Pascal ZIMMER... He oui, en presque 6 ans j ai eu la chance de connaitre pas mal de monde. Je ne remercie pas M. ALZHEIMER pour tous les gens que j aurais involontairement oubliés de citer ici. J adresse une pensée toute particulière aux différentes personnes qui ont partagé leur bureau avec moi pendant ces années. La bataille pour l utilisation de la clim fut rude ;-). Enfin, je remercie également : Catherine JUNCKER de l INRIA, Dominique MICOLLIER de l École des Mines, pour leur aide et leur efficacité dans l organisation matérielle de la soutenance.
4
5 Table de matières Chapitre 1 Introduction Modularité et parallélisme L Approche Synchrone L Approche Réactive Les formalismes réactifs Systèmes réactifs en Java Structure du document Chapitre 2 Les SugarCubes v Mécanisme d exécution : instructions et machines Instructions Machines d exécution Les principales primitives Nothing et Stop Les actions atomiques L opérateur de séquence Parallélisme Les boucles Contrôle de micro-étapes La programmation événementielle Les événements Les configurations événementielles Génération d événements Attente sur une configuration événementielle Préemption Contrôle d exécution par un événement Déclaration locale d événement Exemple d utilisation des SugarCubes Limitations L interface des SugarCubes avec Java Interface utilisateur Efficacité et Sémantique Chapitre 3 Extensions des SugarCubes Les Cubes Communication entre Cubes Extension dynamique et gel de comportement Nouvelles primitives Lien entre programme réactif et objet Java Mécanismes de notifications Communication par événements valués...53
6 ii Table des matières Extension dynamique et gel d instruction La primitive Cube L'interface de programmation utilisateur Les interfaces de base de programmation L exécution des programmes Programmation des effets de bords Java Exemple Conclusion...71 Chapitre 4 Implémentation Machine, environnement et instructions Instructions Environnement d exécution Link et variables locales L interface Link Gestion des Links par l environnement d exécution La classe LinkImpl Déclarations de variables locales Opérations atomiques Événements valués, Callback-Listener Modifications de la classe Event Génération d événements valués Callback-Listeners Shell L interface Shell La classe ShellImpl L instruction AddToShell Freezable La classe Freezable L instruction Freeze Gestion des requêtes de gel d instruction par l environnement Les Cubes La classe Cube L instruction Destroy Les Machine Réactives Conclusion Chapitre 5 Junior Motivations Définition Sémantique Les règles SOS Syntaxe Définition de l environnement d exécution Primitives de base Les primitives événementielles Contexte d exécution Efficacité REPLACE Implémentations REWRITE REPLACE Simple Conclusion...127
7 Tables des matières iii Chapitre 6 Storm Parallélisme et grand nombre d événements Définition de Storm Algorithme et sémantique Un nouveau statut d exécution : WAIT Le parallélisme Les précurseurs Formalisation des précurseurs Implémentations Implémentation directe des règles de sémantique : Formal Storm Implémentation à base de files d attente : Storm Conclusion Chapitre 7 Expérimentations Les Scripts Réactifs Génération de programmes SugarCubes à la volée Interprète d actions externes Les différentes formes du langage des Scripts Réactifs Les Icobjs Notion d Icobjs La programmation par Icobjs Implémentation et applications Les systèmes distribués Les systèmes synchronisés Les algorithmes de détection de fin d instant Deux infrastructures de communication distribuée Analyse du système Migration de code Mécanisme de migration Expérience Conclusion Chapitre 8 Conclusion et perspectives Réalisations Perspectives Bibliographie 189
8 iv Table des matières
9 Chapitre 1 Introduction L augmentation de la masse et de la diversité des informations à traiter par les systèmes informatiques actuels, en particulier dès qu il s agit de systèmes de communication, a considérablement alourdi leur développement. De par leur taille importante, la simple maintenance de ces systèmes au jour le jour, devient une tâche critique mobilisant bien souvent des équipes entièrement dédiées. La généralisation d Internet et des autres systèmes de communication aggrave encore cette situation. L adaptation aux nouvelles technologies et la prise en compte des nouveaux types de contenus nécessitent une longue planification et les transformations d un système déjà existant ne sont pas toujours évidentes alors que son environnement évolue de plus en plus vite. Si la quantité d information dont l Internet ne manque pas de nous inonder a suscité le développement d applications nouvelles, la complexité grandissante de ces systèmes oblige naturellement à se tourner vers des solutions modulaires et réutilisables capables d en faciliter la conception et la maintenance. Plutôt que de développer une application monolithique spécialisée, les techniques de programmation se sont rapidement tournées vers des paradigmes modulaires, offrant une plus grande réutilisabilité et une maintenance aisée. La montée en puissance, à pas soutenu, des ressources matérielles a d ailleurs grandement contribué à cela. La conception modulaire des systèmes consiste à les découper, de manière rationnelle, en sous-modules fonctionnels fournissant un certain nombre de services qui sont utilisés par les autres composants pour atteindre le but global de l application. Dans un tel système, chaque module s acquitte d une tâche précise en interagissant avec les autres. Cette approche modulaire permet d abstraire les différentes fonctionnalités au sein d une application et les interactions entre modules au niveau d un ensemble de services sans subir d interférences avec les moyens mis en œuvre par le module pour fournir ces services. Ainsi on dégage différents niveaux de granularité pour analyser le système, chaque niveau étant un à un plus simple à appréhender. Une caractéristique de cette approche modulaire est son aspect fractal dans le sens où le principe de la découpe d un système en modules peut être appliqué à l un de ces modules et inversement un système informatique peut lui-même être vu comme un module d un système applicatif plus complexe. De très nombreux travaux ont été réalisés afin de développer des modèles de programmation plus modulaires, capables de prendre en compte les différentes contraintes en termes de facilité de conception et de maintenance des systèmes, ainsi qu en termes de réutilisation des développements. Ces recherches aboutissent, de nos jours, au succès croissant des modèles objets dans les développements des systèmes informatiques. L importance industrielle des développements en C++ et le succès fulgurant du langage Java illustrent bien cette reconnaissance des modèles de programmation objet. Nous revenons sur langage Java plus loin dans cette introduction. Mais pour le moment, intéressons nous a un aspect plus méconnu offrant des gains de modularité très importants : le parallélisme. 1.1 Modularité et parallélisme La plupart des programmes informatiques appliquent des traitements à des données qui leur sont
10 2 Chapitre 1 : Introduction passées au début de leur exécution. Lorsque ces programmes terminent, ceux-ci génèrent alors les résultats des traitements qu ils ont appliqués. Cette approche, que l on qualifiera de classique, des systèmes informatiques se retrouve également au niveau des solutions utilisées pour mettre en œuvre la modularité. Ainsi une procédure, une fonction, une méthode d un objet est un programme qui accepte au début de son exécution des données (les paramètres) et génère en sortie des résultats (les retours). Cependant, avec l importance grandissante des systèmes de communication, le besoin de prendre en compte l expression du parallélisme et de la concurrence au sein d un programme potentiellement distribué oblige à envisager d autres paradigmes. Ainsi, de nombreuses recherches ont été menées afin de prendre en compte les aspects parallèles et concurrents des systèmes dans les techniques de programmation. Mais souvent, ces résultats ont été cantonnés aux seuls systèmes d exploitations et peu de langages ont réussi à imposer l expression du parallélisme comme un outil garant d une plus grande modularité et d une plus grande réutilisabilité des développements. Si le parallélisme et la concurrence sont considérés comme des points importants de la conception d un système, leur utilisation vise principalement à tirer profit des aspects distribués des ressources informatiques ou à permettre de renforcer l indépendance de tâches particulières au sein d un même système. De nos jours, le modèle le plus connu (et probablement le plus utilisé) d expression du parallélisme et de la concurrence reste le modèle des threads, hérité des architectures de systèmes d exploitations. Ce modèle, qui repose sur des notions de moniteurs d exécution, de sections critiques et autres verrous, s avère cependant complexe à utiliser et n incite pas vraiment à user pleinement des capacités modulaires du parallélisme. En 1985, D. Harel et A. Pnueli [HP] ont proposé un nouveau paradigme : les systèmes réactifs. Il s agit de systèmes qui ne sont pas censés terminer pour produire des résultats contrairement à ceux de l approche classiques présentée précédemment. Ces systèmes réagissent de façon continue, à toute modification de leur environnement, en influant en retour sur ce même environnement. Ce sont donc des programmes cycliques qui entretiennent une interaction étroite et continue avec leur environnement. Les systèmes réactifs se conçoivent naturellement dans un cadre concurrent ou parallèle. Chaque composant, s exécutant en parallèle, réagit à une perturbation de son environnement d exécution en produisant à son tour une modification de l environnement qui fera réagir d autres composants. Le développement des formalismes synchrones s inscrit dans cette optique. 1.2 L Approche Synchrone Dans le cadre de l Approche Synchrone, on passe d une interaction continue du système avec son environnement à une interaction discrète (discrétisation temporelle). L introduction d une horloge globale servant à échantillonner l environnement et de couples d activation/réaction permettent de réaliser cette transition vers un monde discret. À chaque activation, un système réagit, aussi rapidement que possible, à toute modification de son environnement (les entrées ou inputs) et engendre à son tour une modification de l environnement (les sorties ou outputs). Dans un tel système, une implémentation mettant en œuvre du parallélisme est privilégiée, du fait de la possibilité de réagir immédiatement à plusieurs modifications simultanées de l environnement du système. Dans ce cas, tous les composants parallèles du système sont exécutés au cours d une réaction, de sorte que tous peuvent réagir à toutes les modifications survenues dans l environnement. A ce niveau, deux types de systèmes peuvent être envisagés : le rythme est donné par l environnement et le système réagit instantanément à toute modification. Dans ce cas, on reste très proche du modèle théorique continu des systèmes réactifs. Lorsqu un élément de l environnement subit une transition, le système réagit instantanément. On peut avoir des rythmes de réaction différents (des horloges différentes) en fonction des éléments de l environnement considérés. le rythme est défini par le système. L horloge du système défini l échantillon de l environnement sur lequel le système va réagir. Le rythme doit être suffisamment soutenu pour que toutes les modifications de l environnement puissent être prise en compte. C est ce second cas que nous allons considérer dans ce document.
11 Chapitre 1 : Introduction 3 L Approche Synchrone repose sur une hypothèse fondamentale selon laquelle la durée logique des réactions est nulle (on dit qu une réaction est atomique). En d autre termes, le système réagit suffisamment vite par rapport aux modifications de l environnement de manière à ne pas perdre d événements. Dans ce cas, les sorties d un système synchrone sont émises simultanément aux entrées. Cela a pour conséquence que l environnement d un système est parfaitement déterminé et stable lors d une réaction, puisque de façon instantanée les entrées et les sorties sont connues et constituent l échantillon de l environnement. Dans la suite de ce document, nous appelons environnement l échantillon (la photographie instantanée) de ce dernier correspondant à une réaction. Les formalismes synchrones que nous considérons ici proposent différents langages permettant d exprimer dans un programme les réactions d un système à une succession d activations dans des échantillons successifs de l environnement. Mais ils doivent également s assurer que le programme ainsi exprimé satisfasse l atomicité des réactions. En particulier, il faut s assurer de l absence d incohérence dans ce qui est produit par les différentes branches parallèles d un système et que celles-ci aient bien toutes la même vision de l environnement. En effet, la puissance expressive des langages synchrones est souvent trop grande et permet d écrire des systèmes incohérents. Cette contrainte supplémentaire impose en général une analyse statique des programmes en vue de rejeter les programmes non conformes. En outre, les sorties d un système doivent être définies de manière unique en fonction des entrées à chaque réaction car les formalismes synchrones sont déterministes. L analyse statique des programmes devra en conséquence rejeter un programme pouvant conduire à plusieurs séquences de sorties différentes pour une même configuration d entrée. Or, en pratique, cette analyse ne peut-être effectuée que par approximations, ce qui conduit à rejeter des programmes qui auraient pu être admis en effectuant d autres choix d analyse. De ce fait il devient important de fixer les choix d analyse qui vont être mis en œuvre car ceux-ci ont un impact direct sur la puissance expressive du langage au final. P1 P2 P3 Fig. 1 : P1, P2 et P3 sont trois composants s exécutant en parallèle de manière atomique. Les entrées et les sorties sont synchrones. On distingue deux grandes catégories de formalismes réactifs/synchrones : Les formalismes orientés flots de données. Dans ce type de formalisme, l environnement d exécution du programme est représenté par des flots de données. Un flot de donnée est une suite temporelle de valeurs. Un flot peut être vu comme un canal de communication qui, à chaque réaction successive, présente une nouvelle valeur. Le programme réactif qui traite alors ces données est constitué d un ensemble d équations qui calculent les valeurs des flots de sortie à partir de flots d entrée. Ces équations sont évaluées en parallèles et constituent donc les composants parallèles du système. Dans ce type de formalismes, le style déclaratif est naturellement privilégié. Les principaux langages basés sur ces principes sont les langages Lustre[HCRR], Signal[GGBM], Lucid Synchrone[CP] etc. Les formalismes orientés contrôle d exécution. Dans ce type de formalisme l accent est mis sur le contrôle d exécution et plus précisément sur l ordonnancement et le contrôle des tâches à
12 4 Chapitre 1 : Introduction exécuter par le programme. L environnement d exécution est constitué d un ensemble d événements ou de signaux qui sont utilisés pour contrôler l exécution d un programme. La caractéristique la plus importante d un signal ou d un événement est sa présence ou son absence dans l environnement d exécution. En général, un programme réactif dans ce type de formalisme est une description dans un style impératif des réactions des différents composants parallèles à la présence ou à l absence d événements/signaux. Le principal langage basé sur ces principes est le langage Esterel[BG] En fonction du type de formalismes choisis, l hypothèse d atomicité pose des problèmes différents au moment de l analyse statique des programmes. Dans le cadre des formalismes orientés flots de données, l analyse statique d un système doit vérifier qu à chaque instant, il existe au moins une façon d ordonner les équations décrivant le système. Ainsi, la résolution du système d équations devient possible. Elle doit également conduire à une solution unique des sorties en fonction des entrées. Une autre conséquence de cette analyse statique préalable est que le programme s exécutera en mémoire bornée (cette dernière propriété est souvent prise comme caractéristique d un système réactif). En d autres termes, cela signifie qu on a la certitude que les flots de données ne s accumulent pas en mémoire dans un goulot d étranglement du programme en attente d un traitement. Si l on considère des programmes écrits en flot de données sous la forme de réseaux de processus s exécutant en parallèle et communiquant entre eux par des files d attente, ces files d attente sont de taille bornée et la taille maximale des files d attente peut-être statiquement déterminée. Dans le cadre des formalismes orientés contrôle, l analyse statique doit s assurer à chaque instant que les signaux de sortie sont définis de façon unique (solution déterministe) à partir des signaux d entrée. En particulier, cela signifie qu il faut s assurer que si un signal est considéré comme étant absent, cette hypothèse est unanimement partagée par toutes les instructions mises en jeu au cours de la réaction. Les problèmes que l on rencontre au cours de cette analyse sont appelés cycles de causalités [Be1]. Ils surviennent lorsque, par exemple, un programme faisant l hypothèse de l absence d un signal émet instantanément celui-ci, infirmant ainsi l hypothèse faite au cours de la réaction. Un certain nombre de formalismes graphiques (principalement orientés contrôle) ont également été proposés pour faciliter l implémentation des systèmes synchrones : Les StateCharts [Ha], créés par D. Harel permettent la spécification graphique de systèmes réactifs. Argos [Mar], développé par F. Maraninchi reprend les principes des StateCharts en proposant une sémantique strictement définie. L extension aux formalismes synchrones orientés flots de données et en particulier à Lustre est également couverte par ce formalisme. Les SyncCharts [An], développés par C. André, s inspire des travaux de D. Harel dans le cadre de formalismes synchrones orientés contrôle et produisent du code Esterel. Les formalismes synchrones s intéressent principalement à des systèmes statiques, bien définis (dans lesquels le nombre de composants parallèles est défini à la compilation), sur lesquels il est possible d appliquer des raisonnements formels en vue de prouver certaines propriétés. Dans ce document, nous nous intéressons aux formalismes orientés contrôle dans la mouvance du langage Esterel. 1.3 L Approche Réactive L Approche Réactive que nous allons considérer dans ce document est définie par F. Boussinot dans l ouvrage La programmation réactive [Bo1]. Cette approche dérive de l Approche Synchrone et regroupe un ensemble de formalismes permettant d implémenter des systèmes réactifs. Elle a pour caractéristique de pouvoir évoluer dynamiquement, en cours d exécution, en modifiant le nombre de composants parallèles. Dans ces conditions, la souplesse obtenue, grâce au caractère dynamique des systèmes ainsi construits, se paye par une perte d expressivité (plus ou moins dommageable en fonction du type de systèmes considérés) et l impossibilité d établir des preuves sur les aspects dynamiques. L Approche Réactive poursuit les objectifs suivants : fournir un ensemble de primitives permettant l expression simple et puissante du parallélisme au
13 Chapitre 1 : Introduction 5 niveau d un langage de programmation ; permettre l expression de systèmes dynamiquement reconfigurables en cours d évolution. Ceci est en effet plus adapté dans le cadre de langages de programmation généralistes, en particulier lorsqu on s intéresse à des systèmes distribués ; fournir un modèle déterministe de programmation du parallélisme, formellement spécifié, dont les résultats soient reproductibles indépendamment des implémentations et des plates-formes d utilisation ; fournir des mécanismes simples et puissants de communication et de synchronisation entre les différents composants parallèles d un système ; exhiber le caractère modulaire de la programmation parallèle en insistant sur la réutilisabilité des composants parallèles développés, en particulier, par combinaison parallèle de ces composants ; fournir un modèle de programmation du parallélisme cohérent avec un modèle de programmation à base d objets. Instants de durée non nulle Sur le modèle de l Approche Synchrone, l Approche Réactive introduit une notion d horloge globale dans les différents formalismes qu elle recouvre. Cette horloge découpe l exécution d un programme en une succession d instants logiques (réactions). À chaque activation, un programme réactif exécute une réaction dont la durée est celle de l instant : tous les composants parallèles constituant le programme évoluent au même rythme. Le temps est considéré comme un temps logique (par opposition aux systèmes appelés temps réels). La principale différence entre l Approche Réactive et l Approche Synchrone réside fondamentalement dans sa manière de gérer l évolution de l environnement d exécution du système. L Approche Synchrone fait l hypothèse d atomicité des instants. L Approche Réactive s en distingue essentiellement par un affaiblissement de cette contrainte fondamentale : aucune hypothèse particulière n est faite sur la durée d une réaction. En particulier, cela signifie qu un instant a une durée, on peut donc parler d évolution au cours d un instant. L introduction d une durée des instants a également une autre conséquence : il devient possible de découper l exécution d un instant de réaction du système en un ensemble de micro-étapes. Ainsi, l exécution d une réaction peut prendre des formes différentes, comme par exemple des enchaînements de phases successives bien définies ou bien des oscillations amorties jusqu à atteindre un état stable définissant la fin d'instant. En d autres termes, un programme dans l Approche Réactive converge vers la fin d instant en calculant un point fixe caractérisant l état stable du programme. Par contre, les perturbations de l environnement sont atomiques c'est-à-dire qu aucune action concurrente ne peut venir contrarier une modification de l environnement par le système. Ainsi, l environnement d un système est toujours présenté dans un état cohérent. L Approche Réactive propose un certain nombre de primitives qui permettent de contrôler, avec une granularité fine, l exécution d un programme, en s appuyant sur cette notion de micro-étapes. Ces primitives permettent en particulier de définir plus précisément les stratégies d exécution au cours d un instant. Elles contribuent à renforcer le caractère déterministe de l exécution parallèle d un ensemble de composants en permettant d analyser également dans certains cas l ordonnancement des effets de bords. Cependant, ces micro-étapes ne doivent pas être confondues avec la notion d instant. En effet, les événements et le parallélisme synchrone restent des notions définies par rapport aux instants (que l on appelle aussi parfois des macro-étapes). Une micro-étape ne peut donc pas revendiquer les mêmes propriétés qu un instant. En particulier, au cours d une micro-étape, l environnement d exécution peut évoluer; il ne sera donc pas vu forcément à l identique par l ensemble des composants parallèles. La vision cohérente de l environnement partagée par tous les composants d un système est une notion définie au regard des instants d exécution et non des micro-étapes. Parallélisme Comme pour l Approche Synchrone, la notion d instant fournit un moyen de définir une sémantique claire du parallélisme : chaque composant en parallèle exécute un bout de son programme au cours d un instant. Mais, le fait que ces instants aient une durée permet d appréhender le problème sous une forme différente : la fin d un instant est effective lorsque tous les composants parallèles du système ont terminé
14 6 Chapitre 1 : Introduction leur exécution pour l instant courant. Ainsi, tous les composants se synchronisent à chaque fin d instant. Instant 1 Instant 2 Instant 3 Instant 4 Instant 5 P1 P2 P3 Fig. 2 : Exécution parallèle des composants P1, P2 et P3. Événements La notion d instant logique permet de définir un puissant moyen de communication entre les composants parallèles d un système réactif : la communication par diffusion instantanée de signaux ou d événements (l Approche Réactive utilise en général le terme d événement). Ce type particulier de communication a été introduit par le langage Esterel[Be2] et présente les propriétés suivantes : instantanéité : un événement est un message échangé entre composants parallèles. Cet événement est en fait un élément de l environnement d exécution du système réactif dont la durée de vie (présence dans l environnement) est celle d un instant. Il s agit d une donnée non persistante entre instants dont l état sera redéfini à chaque nouvel instant. diffusion : cet événement est vu à l identique par l ensemble des composants s exécutant en parallèle dans le système à l instant de sa génération. Autrement dit, pour le même instant, deux composants parallèles ne peuvent avoir deux informations différentes sur le même événement; c est-à-dire que l on ne peut avoir un composant qui voit un événement présent, tandis qu un autre le voit absent au cours du même instant. Instant Fig. 3 : Diffusion instantanée d événements. Ce mécanisme de communication à deux conséquences particulièrement intéressantes : mémoire bornée (pas de gestion de file d attente). L état d un événement n est conservé que durant un instant. À l instant suivant le même événement aura un nouvel état qui ne sera pas directement déduit de l état précédent. Il n y a pas de mémoire de l état d un événement d un instant sur l autre (tout au moins en termes d événement purs; c est à dire lorsque l on ne s intéresse qu à la présence ou à l absence de l événement). modularité (pas de références sur l émetteur ou le récepteur). Deux composants n ont pas besoin
15 Chapitre 1 : Introduction 7 de se connaître a priori pour pouvoir communiquer entre eux dès qu ils se retrouvent exécutés en parallèle dans le même système. Ils communiquent à travers l environnement d exécution qu ils partagent. Cependant à la différence des variables globales, les règles d accès à cet environnement sont définies par rapport à la notion d instant. La notion d événement diffusé instantanément permet également de donner une sémantique claire aux notions de simultanéité et d absence d événements. En effet, la simultanéité de deux événements dans un cadre asynchrone est difficile à définir. Dans un cadre synchrone, deux événements sont simultanés, s ils sont présents dans l environnement dans le même instant. De même, l absence d un événement est clairement définie par rapport à la notion d instant : un événement est absent au cours d un instant s il n est pas produit au cours de celui-ci. Cas de la réaction à l absence Nous avons vu qu afin de maintenir la cohérence du système, tous les composants doivent avoir la même information sur l état d un événement au cours d un instant. Si l événement est généré au cours d un instant, il doit être considéré présent tout au long de l instant par tous les composants du système qui se réfèrent à cet événement au cours de leur exécution. Dans ces conditions, l Approche Réactive, interdit toute hypothèse sur l absence d un événement au cours d un instant. C est une des différences fondamentales de l Approche Réactive avec l Approche Synchrone. Au début d un instant, le statut d un événement est inconnu ou présent (s il est généré par l extérieur, comme une entrée du système). On ne sait qu un événement était absent qu à la fin d un instant car il ne peut plus être émis. La réaction à l absence d un événement est donc naturellement reportée à l instant d après. Au cours d un instant, aucun composant ne peut faire l hypothèse de l absence d un événement pour poursuivre son exécution immédiatement ; on autorise donc la réaction instantanée à la présence mais pas à l absence d un événement. Sans cette restriction, une hypothèse d absence pourrait en effet se voir infirmer par une génération ultérieure de l événement au cours de l instant, ce qui violerait la propriété de diffusion des événements. Ainsi, par cette simple restriction sémantique, on élimine les problèmes de causalité rencontrés dans les formalismes synchrones. Il devient alors possible de composer un système réactif complexe constitué de la mise en parallèle de modules élémentaires sans risque de soulever un problème de causalité. Cette combinaison parallèle de composants constitue un gain important en termes de modularité. Dynamisme La notion d instant global de durée non nulle de l Approche Réactive présente également l avantage de dégager naturellement des moments privilégiés où l exécution d un système a atteint un état stable : la fin d instant. Cela permet de concevoir des mécanismes : permettant l ajout dynamique de nouveaux composants parallèles entre deux instants. Cet ajout dynamique ne pose aucun problème puisque les programmes, de par les restrictions sémantiques des formalismes de l Approche Réactive, ne peuvent générer des problèmes de causalité. La composition parallèle est donc toujours possible. permettant de retirer dynamiquement des composants en train de s exécuter dans un système lorsqu ils sont parvenus dans un état stable (fin d instant). Cela permet d implémenter des systèmes de codes mobiles : le composant retiré est suspendu et son exécution peut être reprise ultérieurement sur un autre site. Il est aussi possible d implémenter des systèmes persistants par exemple pour de la tolérance aux pannes : un programme peut être copié sur un support de stockage à la fin d un instant pour être repris ultérieurement en cas de panne. Un système réactif peut ainsi être reconfiguré dynamiquement sans aucun problème entre deux réactions consécutives par ajout ou retrait de composants parallèles en cours d exécution. Cette caractéristique dynamique est une particularité de l Approche Réactive qui la rend adaptée à la programmation des systèmes présentant par nature un fort caractère dynamique, tels que les systèmes
16 8 Chapitre 1 : Introduction distribués, les systèmes à base d agents ou les interfaces graphiques. L Approche Synchrone est souvent perçue comme un ensemble de formalismes axés sur la modélisation et la validation de systèmes statiques, en particulier dans le domaine du hardware. De par ces différences avec l Approche Synchrone, l Approche Réactive met l accent sur la programmation des systèmes informatiques en particulier si ceux-ci présentent un fort caractère parallèle et dynamique. 1.4 Les formalismes réactifs L Approche Réactive, élaborée par F. Boussinot, est issue de travaux menés autour du Synchrone et principalement du langage Esterel. Les premiers formalismes engendrés par cette approche ont été initialement construits aux dessus de langages procéduraux tels que C et Tcl-Tk [Ou]. En particulier, le langage Reactive-C proposé comme une extension réactive du langage C, a servi, à l image d un assembleur bas niveau, à implémenter d autres formalismes réactifs de plus haut niveau. Les principaux formalismes qui ont été développés dans ce cadre sont les suivants : Reactive-C[Bo2]. Ce langage ajoute un ensemble de primitives réactive, au langage C. Toute la puissance de C est disponible, pour coder les réactions. De ce fait, la récursion et la création dynamique de nouveaux composants sont autorisées, afin de ne pas limiter la puissance expressive de C. Reactive-C se présente comme un préprocesseur générant du C. Cependant, la communication entre composants réactifs parallèles reste de très bas niveau en utilisant des variables globales. Cette communication n est donc pas vraiment définie par rapport à la notion d instant. Reactive-C est donc une sorte d assembleur réactif permettant d implémenter des mécanismes d exécution d instant. Le langage SL[BS]. Il s agit d un langage synchrone très proche d Esterel dans lequel la restriction fondamentale, pour éviter les problèmes de causalité, consiste à interdire la réaction instantanée à l absence de signaux. Comme en Esterel, la création dynamique est interdite en SL et il n y a pas de possibilité de programmation de micro-étapes de réaction. Les Objets Réactifs[DB]. Il s agit d avantage ici d un modèle de programmation, visant à intégrer les concepts de la programmation objet avec les principes de l Approche Réactive. Le modèle ROM[LB] propose de considérer un type particulier d objets, dérivé du modèle des acteurs. Chaque méthode d un objet est un programme réactif qui s exécute pour la durée d un instant à chaque fois qu elle est invoquée. Toute les méthodes réactives d un objet qui sont invoquées au cours d un instant sont activées en parallèle dans le système à l instant de leur invocation. Une méthode ne peut être invoquée au plus qu une seule fois par instant. L invocation correspond à un envoi de message instantané (l exécution a lieu dans le même instant que l invocation) et n est pas bloquante (on attend pas que la méthode invoquée soit exécutée pour poursuivre l exécution). La communication est une communication point à point entre deux objets. Un retour notifie le refus (par exemple si une invocation a déjà été faite pour l instant courant) ou l acceptation de la requête. Le caractère dynamique de l Approche Réactive permet à ce modèle d utiliser les principes de la programmation basée objet, dans laquelle un objet peut être cloné et de nouvelles méthodes peuvent dynamiquement lui être ajoutées. Les Objets Réactifs Distribués[BDS]. Il s agit d une variante du modèle ROM, dans laquelle on considère des systèmes distribués, formés d îlots synchrones communiquant entre eux de manière asynchrone. Dans chaque îlot synchrone, les objets s exécutent conformément au modèle ROM standard. Lorsque deux objets présents sur deux îlots synchrones différents communiquent entre eux, l invocation d une méthode devient un message asynchrone véhiculé à travers le réseau. Ces messages d invocation restent non bloquants puisque aucune confirmation de la prise en compte ou non du message n est délivrée en retour. Les Scripts Réactifs[BH]. Ils apportent toute la souplesse et le dynamisme d un langage interprété à l Approche Réactive. Les programmes exécutés en parallèle par l interprète sont ajoutés
17 Chapitre 1 : Introduction 9 dynamiquement en cours d exécution. Une implémentation sous la forme d un interprète de commandes à la UNIX a été réalisée. On identifie dans ce cas la réaction de l interprète à l entrée d une nouvelle commande de l utilisateur à la notion d instant des systèmes réactifs. Le langage des Scripts Réactifs ne définit que les primitives réactives responsables du contrôle et de l ordonnancement du programme. La gestion des données et les traitements à leur appliquer sont délégués à un langage tiers. La première implémentation des Scripts Réactifs a été réalisée en Reactive-C et utilise le langage Tcl-Tk comme langage tiers de traitement des données. En outre, les Scripts Réactifs mettent à profit la notion d état stable atteint à la fin d un instant afin de définir un mécanisme particulier de gel de programme dans un état cohérent. Un programme gelé peut être récupéré sous la forme d une chaîne de caractères qui peut être utilisée pour implémenter des mécanismes de persistance ou de migration à travers le réseau. Les Icobjs[Bo3]. Les Icobjs et en particulier la programmation graphique par Icobjs constituent un formalisme particulier, permettant d exprimer graphiquement la programmation par combinaison de comportements élémentaires. Cependant, la programmation par Icobjs n est pas un simple habillage graphique des primitives réactives. Elle met l accent sur la notion de combinaison de comportements. Cette programmation extrêmement dynamique offre à l utilisateur inexpérimenté la possibilité de programmer de manière intuitive ses propres systèmes en utilisant des primitives aussi puissantes que les notions de parallélisme, séquence, préemption, diffusion etc. Les programmes sont dynamiquement construits et reconfigurés par les interactions de l utilisateur avec l interface graphique. Ce modèle de programmation graphique a été initialement développé au-dessus des Scripts Réactifs, offrant ainsi une sémantique très précise à chaque action graphique. 1.5 Systèmes réactifs en Java Les langages de programmation à objets se sont imposés dans le développement des systèmes informatiques, en proposant une découpe en modules d un programme guidée par la structure des données que ce dernier doit manipuler. Par contre, peu de langages à objets se sont véritablement intéressés au problème de l expression de la concurrence et du parallélisme (exception faite des modèles à acteurs). En général, un langage à objets ne permet pas de décrire les notions d activités concurrentes et plus généralement de ressources d exécution des programmes. Les travaux présentés dans ce document ont pour but de proposer une extension réactive au modèle objet de Java afin d exprimer les problèmes de concurrence par des primitives de programmation dont la sémantique est présentée formellement. L application de ces techniques dans un cadre distribué est également envisagé. Concurrence et langage à objets En fait, le besoin d intégrer dans les modèles objets les notions de parallélisme et de concurrence a grandi avec la prolifération des systèmes distribués et plus particulièrement de l Internet. Dans ce nouvel environnement, les plates-formes de programmation d objets distribués à travers le réseau ont mis en évidence la nécessité de spécifier les accès concurrents aux ressources et de prendre en compte le parallélisme physique des exécutions. Dans ces conditions la concurrence n est pas vraiment perçue comme un outil de modularité mais plutôt comme un fait inévitable qu il faut obligatoirement prendre en considération. C est pourquoi nombre propositions de plates-formes d objets répartis se sont tournées vers des techniques issues des systèmes d exploitation. En effet le domaine des systèmes d exploitation a très tôt été confronté au problème de la concurrence d accès aux ressources d exécution et au parallélisme (par exemple, dans le traitement des interruptions matérielles ou sur les architectures parallèles) à travers les notions de processus et autres tâches. Le modèle couramment retenu dans les systèmes distribués est le modèle des threads qui permet d abstraire le parallélisme physique asynchrone et permet donc une extension naturelle à diverses architectures parallèles. Le développement récent du langage Java [GJS], souvent présenté comme l un des premiers langages de programmation orienté objet, largement répandu, capable de prendre en considération les problèmes de
18 10 Chapitre 1 : Introduction concurrence directement au niveau du langage, illustre bien ces besoins nouveaux. Cependant, le modèle de concurrence proposé en Java reste basé sur un modèle de threads et reproduit en cela les solutions mises en œuvre dans la plupart des DPE (Distributed Processing Environement). Si le modèle des threads semble bien adapté à la prise en compte du parallélisme physique des systèmes distribués ou multiprocesseurs, il ne constitue pas un cadre de programmation idéal pour l expression de très nombreuses activités concurrentes modulaires et fortement communicantes. Différentes propositions ont vu le jour afin d étendre ce langage avec différents modèles d expression de la concurrence et le rendre ainsi plus compatible avec la programmation modulaire à objets. Parmi ces différentes propositions, on remarquera l existence de quelques formalismes visant à étendre Java pour la programmation de systèmes réactifs : JavaTriveni [CJJLP] est un ensemble de classes Java pour exprimer la concurrence en s appuyant sur un modèle mélangeant les threads et un système de communication par événements. Ce framework orienté objet fournit des opérateurs de préemption et de contrôle d exécution inspirés de l Approche Synchrone. Pour fonctionner, le calcul de processus Triveni repose sur une hypothèse selon laquelle il y a équité pour l exécution de chaque branche parallèle. Cette assertion n est pas nécessaire dans un cadre totalement synchrone puisque par définition tous les composants parallèles sont naturellement exécutés de manière équitable. Reactive Java [PPLS] est un formalisme implémenté par un ensemble de classes Java, permettant la description de modules parallèles et leurs interconnections. Ce formalisme propose également des primitives permettant de communiquer de façon synchrone ou asynchrone entre composants. Chaque module est implémenté par un thread et un thread supplémentaire est utilisé pour implémenter la préemption. Ce thread de contrôle attend l événement de préemption puis interrompt le thread du module qu il contrôle. Ce thread particulier doit posséder une priorité supérieure à celle du thread contrôlé. Cependant, ce système repose sur certains mécanismes de Java qui ne sont plus désormais supportés par le langage. Jester [AF] est une extension réactive au dessus de Java dont l objectif est de faciliter le développement de systèmes embarqués. Il s agit en fait d un compilateur Esterel implémenté au dessus de Java. Des constructions syntaxiques du langage Esterel sont donc introduites dans ce langage afin de décrire des modules implémentant le comportement concurrent d un système. Un programme Java standard peut être directement passé au compilateur Java (on dit que ce programme est non-réactif ou indifférent). Si par contre le programme contient des constructions Esterel, le compilateur Jester va générer un programme Java implémentant le programme Esterel (implémentant l interface Reactive). C est dans ce cadre que nous proposons d étudier l implémentation de l Approche Réactive au dessus de Java. Approche Réactive en Java Le langage Java nous offre l opportunité d étudier la pertinence de l Approche Réactive dans un cadre orienté objet et distribué. En effet, l Approche Réactive peut être vue comme une alternative intéressante au modèle des threads pour l expression de la concurrence au niveau d un langage de programmation. L Approche Réactive se focalise sur l expression de l ordonnancement et du contrôle des opérations dans un système réactif. La plupart des formalismes et des modèles de programmation réactifs que nous avons brièvement décrits dans la section précédente ne s intéressent pas vraiment aux problèmes des traitements des données manipulées par un programme. En fait, ces traitements sont en général délégués à un langage tiers. Cela est bien illustré dans les cas du langage des Scripts Réactifs (qui délègue les traitements de données au langage Tcl-Tk) ou du langage SL (qui délègue les traitements des données au langage C), par l utilisation de constructions syntaxiques particulières (blocs entre accolades) indiquant des traitements de tâches atomiques à déléguer au langage tiers. Dans ces conditions, l utilisation d un langage tiers impératif ayant recours à des variables globales ne pose pas de grandes difficultés. Mais il n en va pas de même dès lors qu il s agit d interagir avec un langage orienté objet. En effet, l exécution d une tâche atomique va alors nécessiter la définition d un contexte particulier d exécution définissant l objet sur lequel à lieu un traitement atomique. Un langage à
19 Chapitre 1 : Introduction 11 objets découpe en effet les données à traiter en objets qui constituent le contexte d exécution d une méthode. Un traitement atomique est alors défini par une méthode particulière pour laquelle il faudra définir l objet sur lequel elle s applique. Il devient donc important d introduire dans les formalismes réactifs des constructions particulières permettant de définir une relation étroite entre le langage réactif et les objets gérés par le langage tiers. Dans ce documents, nous proposons un certain nombre d extensions réactives permettant de faciliter l interfaçage entre les formalismes réactifs et les objets du langage Java. Ainsi, nous proposons un ensemble de formalismes permettant d étendre le langage Java afin d exprimer dans un programme la concurrence et la communication entre activités parallèles sans recourir aux threads. Atouts du langage Java Java possède un ensemble de caractéristiques attrayantes dans le cadre de nos recherches : Java possède un modèle objet simple et facile à appréhender (héritage simple, tout est classe et objet ). Le nombre de notions à intégrer est restreint ce qui en fait un langage bien adapté au prototypage. Java possède une API très riche permettant un développement rapide en se concentrant sur l essentiel. Ses nombreuses facilités d accès au réseau (Socket, RMI, ) en font une cible particulièrement adaptée à nos besoins pour l étude de l Approche Réactive dans un cadre distribué. Nous avons employé RMI[RMI] dans l implémentation des Machines Réactives Distribuées présentées au chapitre 7 et la sérialisation des objets Java est utilisée dans des expériences de migration de code (cf. chapitre 7). Java offre en standard des mécanismes d introspection permettant d implémenter des interprètes de codes que nous utilisons dans l implémentation des Scripts Réactifs décrite au chapitre 7. Java est un langage à bytecode qui en fait un langage particulièrement portable et ce quelques soient les plates-formes considérées. Les développements peuvent être mis immédiatement à la disposition de la communauté scientifique sans avoir à se soucier des plates-formes d utilisation. Enfin, Java permet de créer rapidement de petites applications (Applets) directement accessibles à travers un navigateur Web, ce qui permet de proposer rapidement une illustration de nos différents travaux. En particulier nous mettons à profit cette capacité pour proposer sur le site Web du projet Reactive Programming un ensemble d Applets illustrant la programmation par Icobjs que nous décrivons dans le chapitre 7 de ce document. 1.6 Structure du document Le chapitre 2 présente une première implémentation de l'approche Réactive au-dessus de Java : les SugarCubes v1. Cet ensemble de classes Java est présenté en insistant en particulier sur l'implémentation originale de ce langage basé sur des objets jouant le rôle d instructions exécutées par des objets jouant le rôle de machines virtuelles d'exécution. L algorithme d exécution des instructions réactives est discuté. Les principaux opérateurs servant à exprimer l ordonnancement des tâches (séquence, parallélisme, boucles ) sont présentés, donnant un aperçu des capacités expressives de ce langage/framework. Puis nous décrivons les aspects événementiels de la programmation réactive en définissant la notion d événements diffusés instantanément et en présentant leur implémentation. Nous présentons ensuite les principales primitives permettant d exprimer les aspects contrôle d exécution, influencées par les événements présents dans l environnement d exécution. Nous illustrons alors l utilisation des SugarCubes par un exemple complet que nous analysons. Enfin, une discussion sur les limitations de cette première implémentation met en évidence les carences des SugarCubes en termes : d interfaçage avec le langage objet chargé de traiter les données; d interface de programmation et d indépendance entre l écriture des programmes SugarCubes et l implémentation des primitives du langage; d efficacité des algorithmes d exécution des instructions et de sémantique des primitives de l Approche Réactive.
20 12 Chapitre 1 : Introduction Le chapitre 3 présente les améliorations proposées par la nouvelle version des SugarCubes (v3). En particulier, nous présentons les nouveautés en termes d interfaçage avec le langage Java et la manière par laquelle le modèle objet a été introduit dans la programmation réactive en SugarCubes. Un nouveau modèle d objets réactifs appelés Cubes est exposé. Pour simplifier la présentation des cubes, cet objet complexe est découpé en fonctions élémentaires introduites dans le langage sous la forme de nouvelles primitives que nous détaillons. Le modèle des cubes présenté dans ce chapitre sera défini par rapport à ces fonctionnalités élémentaires. Une instruction appelée Link est introduite afin d associer un objet Java standard par défaut à un programme réactif. Cet objet Java sera alors aisément accessible directement au niveau d un traitement atomique des données en Java. Un nouveau mécanisme de communication entre objets réactifs, basé sur la diffusion instantanée d événements valués est proposé : les Callback/Listener permettent d interfacer directement les événements valués avec des traitements de données atomiques exprimés en Java. L ajout dynamique de nouveaux composants en parallèle dans le système en cours d exécution est décrit. Un nouveau type d instruction appelé Shell mettant en œuvre ce type de mécanisme est présenté. Enfin les possibilités offertes par cette nouvelle mouture pour la programmation de systèmes distribués, mettant en œuvre en particulier des mécanismes de migration de code sont décrites. L introduction d une instruction particulière permettant le gel de programme à la fin d un instant est proposée ainsi qu un ensemble de mécanismes utiles pour permettre au code migrant de se lier dynamiquement à son environnement. Nous présentons également l interface utilisateur des SugarCubes. Nous exposons dans un premier temps les motivations de cette nouvelle structure du framework. Puis nous donnons une description approfondie de cet ensemble restreint de classes et d interfaces qui permet d isoler les aspects de construction et d exécution des programmes, des aspects d implémentation des SugarCubes. Nous proposons une vision plus précise et plus technique des nouvelles possibilités expressives des SugarCubes v3. Enfin nous illustrons cette nouvelle interface de programmation par quelques exemples. Pour conclure cette première partie sur les SugarCubes, dans le chapitre 4, nous présentons les grandes lignes de l implémentation de cette nouvelle version en insistant plus particulièrement sur les nouveaux mécanismes et les nouvelles instructions mises en œuvre. L implémentation du nouvel algorithme d exécution des instructions, appelé Storm, n est pas présentée ici mais dans le chapitre 6. Les mécanismes inter-instants introduits pour implémenter le gel des instructions ou l ajout dynamique de nouvelles instructions sont exposés. L implémentation de l instruction Link est décrite ainsi que les mécanismes de notification aux objets Java. Puis nous présentons l implémentation des événements valués et en particulier l implémentation des Callbacks/Listeners. Les mécanismes permettant de rendre compte du défilement des instants implémentés par la possibilité d enregistrer des services inter-instants sont décrits. L implémentation des primitives permettant de programmer l ajout dynamique en cours d exécution de nouvelles instructions en parallèle (Shells) est présentée. Puis nous présentons les mécanismes implémentant en SugarCubes v3 les opérations de gel d instruction. Enfin, l implémentation des cubes à partir des instructions présentées dans les sections précédentes est discutée. Dans le chapitre 5, nous nous intéressons à la formalisation d un noyau des principales primitives de l Approche Réactive à travers la définition d un nouveau formalisme appelé Junior. Nous présentons les motivations à l origine de ce travail en insistant plus particulièrement sur les aspects de formalisation du réactif ainsi que sur la volonté de définir des implémentations capables de traiter un grand nombre de composants s exécutant en parallèle à chaque instant et communiquant entre eux par un grand nombre d événements. Nous précisons certains choix qui ont été retenus pour définir ce noyau, principalement inspiré par la première version des SugarCubes. La définition de Junior vient ensuite ainsi que la présentation des principaux opérateurs. Sur les bases de cette définition, deux systèmes de règles de sémantiques opérationnelle sont proposés afin de spécifier formellement ces opérateurs. Le premier système de règles de réécriture, baptisé REWRITE, constitue un noyau de référence. Tandis que le système REPLACE propose une première tentative permettant de formaliser des optimisations de l algorithme d exécution des instructions réactives. Nous présentons enfin les implémentations qui ont été réalisées directement déduites des systèmes de règles. Nous présentons, également, une implémentation particulièrement efficace en terme d objets exécutés en parallèle et du nombre d événements mis en jeu, appelée Simple.
SugarCubes. Jean-Ferdinand Susini Maître de Conférences, CNAM Chaire systèmes enfouis et embarqués. Paris, le 9 janvier, 2009
SugarCubes Jean-Ferdinand Susini Maître de Conférences, CNAM Chaire systèmes enfouis et embarqués Paris, le 9 janvier, 2009 Plan 2 Les SugarCubes au dessus de J2ME Quelques résultats expérimentaux Les
Plus en détailÉvaluation et implémentation des langages
Évaluation et implémentation des langages Les langages de programmation et le processus de programmation Critères de conception et d évaluation des langages de programmation Les fondations de l implémentation
Plus en détailConception des systèmes répartis
Conception des systèmes répartis Principes et concepts Gérard Padiou Département Informatique et Mathématiques appliquées ENSEEIHT Octobre 2012 Gérard Padiou Conception des systèmes répartis 1 / 37 plan
Plus en détailRejo Langage d Objets Réactifs et d Agents
THESE présentée et soutenue publiquement par Raúl Acosta-Bermejo pour obtenir le grade de DOCTEUR de l École des Mines de Paris Spécialité : Informatique temps-réel, Robotique, Automatique Rejo Langage
Plus en détailLes diagrammes de modélisation
L approche Orientée Objet et UML 1 Plan du cours Introduction au Génie Logiciel L approche Orientée Objet et Notation UML Les diagrammes de modélisation Relations entre les différents diagrammes De l analyse
Plus en détailIntroduction aux systèmes temps réel. Iulian Ober IRIT ober@iut-blagnac.fr
Introduction aux systèmes temps réel Iulian Ober IRIT ober@iut-blagnac.fr Définition Systèmes dont la correction ne dépend pas seulement des valeurs des résultats produits mais également des délais dans
Plus en détailLes Architectures Orientées Services (SOA)
Les Architectures Orientées Services (SOA) Ulrich Duvent Guillaume Ansel Université du Littoral Côte d Opale 50, Rue Ferdinand Buisson BP 699 62228 Calais Cedex Téléphone (33) 03.21.46.36.92 Télécopie
Plus en détailJulien MATHEVET Alexandre BOISSY GSID 4. Rapport RE09. Load Balancing et migration
Julien MATHEVET Alexandre BOISSY GSID 4 Rapport Load Balancing et migration Printemps 2001 SOMMAIRE INTRODUCTION... 3 SYNTHESE CONCERNANT LE LOAD BALANCING ET LA MIGRATION... 4 POURQUOI FAIRE DU LOAD BALANCING?...
Plus en détailBien architecturer une application REST
Olivier Gutknecht Bien architecturer une application REST Avec la contribution de Jean Zundel Ce livre traite exactement du sujet suivant : comment faire pour que les services web et les programmes qui
Plus en détailChapitre VI- La validation de la composition.
Chapitre VI- La validation de la composition. Objectifs du chapitre : Expliquer les conséquences de l utilisation de règles de typage souples dans SEP. Présenter le mécanisme de validation des connexions
Plus en détailbasée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML
basée sur le cours de Bertrand Legal, maître de conférences à l ENSEIRB www.enseirb.fr/~legal Olivier Augereau Formation UML http://olivier-augereau.com Sommaire Introduction I) Les bases II) Les diagrammes
Plus en détailNom de l application
Ministère de l Enseignement Supérieur et de la Recherche Scientifique Direction Générale des Etudes Technologiques Institut Supérieur des Etudes Technologiques de Gafsa Département Technologies de l Informatique
Plus en détailInformatique industrielle A7-19571 Systèmes temps-réel J.F.Peyre. Partie I : Introduction
Informatique industrielle A7-19571 Systèmes temps-réel J.F.Peyre Partie I : Introduction Plan de la première partie Quelques définitions Caractéristiques communes des applications temps-réel Exemples d
Plus en détailDéveloppement d un interpréteur OCL pour une machine virtuelle UML.
ObjeXion Software Prototyping made easy SA au capital de 500 000 F Siret 421 565 565 00015 APE 722Z Téléphone : 03 89 35 70 75 Télécopie : 03 89 35 70 76 L embarcadère 5, rue Gutemberg 68 800 Vieux-Thann,
Plus en détailMessagerie asynchrone et Services Web
Article Messagerie asynchrone et Services Web 1 / 10 Messagerie asynchrone et Services Web SOAP, WSDL SONT DES STANDARDS EMERGEANT DES SERVICES WEB, LES IMPLEMENTATIONS DE CEUX-CI SONT ENCORE EN COURS
Plus en détailOrganisation de dispositifs pour tous les apprenants : la question de l'évaluation inclusive
Organisation de dispositifs pour tous les apprenants : la question de l'évaluation inclusive Transcription et traduction de la communication de Verity DONNELLY colloque Éducation inclusive, la question
Plus en détailIntroduction à l informatique temps réel Pierre-Yves Duval (cppm)
Introduction à l informatique temps réel Pierre-Yves Duval (cppm) Ecole d informatique temps réel - La Londes les Maures 7-11 Octobre 2002 -Définition et problématique - Illustration par des exemples -Automatisme:
Plus en détailEléments de spécification des systèmes temps réel Pierre-Yves Duval (cppm)
Eléments de spécification des systèmes temps réel Pierre-Yves Duval (cppm) Ecole d informatique temps réel - La Londes les Maures 7-11 Octobre 2002 - Evénements et architectures - Spécifications de performances
Plus en détailLes indices à surplus constant
Les indices à surplus constant Une tentative de généralisation des indices à utilité constante On cherche ici en s inspirant des indices à utilité constante à définir un indice de prix de référence adapté
Plus en détailVérifier la qualité de vos applications logicielle de manière continue
IBM Software Group Vérifier la qualité de vos applications logicielle de manière continue Arnaud Bouzy Kamel Moulaoui 2004 IBM Corporation Agenda Analyse de code Test Fonctionnel Test de Performance Questions
Plus en détailGrandes lignes ASTRÉE. Logiciels critiques. Outils de certification classiques. Inspection manuelle. Definition. Test
Grandes lignes Analyseur Statique de logiciels Temps RÉel Embarqués École Polytechnique École Normale Supérieure Mercredi 18 juillet 2005 1 Présentation d 2 Cadre théorique de l interprétation abstraite
Plus en détailChapitre I Notions de base et outils de travail
Chapitre I Notions de base et outils de travail Objectifs Connaître les principes fondateurs et l historique du langage Java S informer des principales caractéristiques du langage Java Connaître l environnement
Plus en détailVIII- Circuits séquentiels. Mémoires
1 VIII- Circuits séquentiels. Mémoires Maintenant le temps va intervenir. Nous avions déjà indiqué que la traversée d une porte ne se faisait pas instantanément et qu il fallait en tenir compte, notamment
Plus en détailPG208, Projet n 3 : Serveur HTTP évolué
PG208, Projet n 3 : Serveur HTTP évolué Bertrand LE GAL, Serge BOUTER et Clément VUCHENER Filière électronique 2 eme année - Année universitaire 2011-2012 1 Introduction 1.1 Objectif du projet L objectif
Plus en détailTraduction des Langages : Le Compilateur Micro Java
BARABZAN Jean-René OUAHAB Karim TUCITO David 2A IMA Traduction des Langages : Le Compilateur Micro Java µ Page 1 Introduction Le but de ce projet est d écrire en JAVA un compilateur Micro-Java générant
Plus en détailÉléments de programmation et introduction à Java
Éléments de programmation et introduction à Java Jean-Baptiste Vioix (jean-baptiste.vioix@iut-dijon.u-bourgogne.fr) IUT de Dijon-Auxerre - LE2I http://jb.vioix.free.fr 1-20 Les différents langages informatiques
Plus en détailPrise en compte des ressources dans les composants logiciels parallèles
Prise en compte des ressources dans les composants logiciels parallèles Aperçus de l action RASC et du projet Concerto F. Guidec Frederic.Guidec@univ-ubs.fr Action RASC Plan de cet exposé Contexte Motivations
Plus en détailInstitut Supérieure Aux Etudes Technologiques De Nabeul. Département Informatique
Institut Supérieure Aux Etudes Technologiques De Nabeul Département Informatique Support de Programmation Java Préparé par Mlle Imene Sghaier 2006-2007 Chapitre 1 Introduction au langage de programmation
Plus en détailCours 1 : La compilation
/38 Interprétation des programmes Cours 1 : La compilation Yann Régis-Gianas yrg@pps.univ-paris-diderot.fr PPS - Université Denis Diderot Paris 7 2/38 Qu est-ce que la compilation? Vous avez tous déjà
Plus en détailCours de Génie Logiciel
Cours de Génie Logiciel Sciences-U Lyon Diagrammes UML (2) http://www.rzo.free.fr Pierre PARREND 1 Avril 2005 Sommaire Les Diagrammes UML Diagrammes de Collaboration Diagrammes d'etats-transitions Diagrammes
Plus en détailLe Collège de France crée une chaire pérenne d Informatique, Algorithmes, machines et langages, et nomme le Pr Gérard BERRY titulaire
Communiquédepresse Mars2013 LeCollègedeFrancecréeunechairepérenned Informatique, Algorithmes,machinesetlangages, etnommeleprgérardberrytitulaire Leçoninauguralele28mars2013 2009avait marquéunpas importantdans
Plus en détailRapport d'analyse des besoins
Projet ANR 2011 - BR4CP (Business Recommendation for Configurable products) Rapport d'analyse des besoins Janvier 2013 Rapport IRIT/RR--2013-17 FR Redacteur : 0. Lhomme Introduction...4 La configuration
Plus en détailORDONNANCEMENT CONJOINT DE TÂCHES ET DE MESSAGES DANS LES RÉSEAUX TEMPS RÉELS 4. QUELQUES EXEMPLES DU DYNAMISME ACTUEL DU TEMPS RÉEL
i LE TEMPS RÉEL 1. PRÉSENTATION DU TEMPS RÉEL 1.1. APPLICATIONS TEMPS RÉEL 1.2. CONTRAINTES DE TEMPS RÉEL 2. STRUCTURES D'ACCUEIL POUR LE TEMPS RÉEL 2.1. EXÉCUTIFS TEMPS RÉEL 2.2. RÉSEAUX LOCAUX TEMPS
Plus en détailREALISATION d'un. ORDONNANCEUR à ECHEANCES
REALISATION d'un ORDONNANCEUR à ECHEANCES I- PRÉSENTATION... 3 II. DESCRIPTION DU NOYAU ORIGINEL... 4 II.1- ARCHITECTURE... 4 II.2 - SERVICES... 4 III. IMPLÉMENTATION DE L'ORDONNANCEUR À ÉCHÉANCES... 6
Plus en détailRTDS G3. Emmanuel Gaudin emmanuel.gaudin@pragmadev.com
RTDS G3 Emmanuel Gaudin emmanuel.gaudin@pragmadev.com PragmaDev Dédiée au développement d un AGL pour le développement des applications temps réel et embarquées. Réseau de partenaires: Formations, Service,
Plus en détailPlan du cours. Autres modèles pour les applications réparties Introduction. Mode de travail. Introduction
Plan du cours Autres modèles pour les applications réparties Introduction Riveill@unice.fr http://rangiroa.polytech.unice.fr Notre terrain de jeu : les systèmes répartis Un rappel : le modèle dominant
Plus en détailMachines virtuelles Cours 1 : Introduction
Machines virtuelles Cours 1 : Introduction Pierre Letouzey 1 pierre.letouzey@inria.fr PPS - Université Denis Diderot Paris 7 janvier 2012 1. Merci à Y. Régis-Gianas pour les transparents Qu est-ce qu une
Plus en détailPlateforme STAR CLM. Gestion intégrée des réseaux multilingues d entreprise
Plateforme STAR CLM Gestion intégrée des réseaux multilingues d entreprise Groupe STAR Your single-source partner for corporate product communication Chaque plan de vol est unique... Chaque vol est un
Plus en détailPatrons de Conception (Design Patterns)
Patrons de Conception (Design Patterns) Introduction 1 Motivation Il est difficile de développer des logiciels efficaces, robustes, extensibles et réutilisables Il est essentiel de comprendre les techniques
Plus en détailDémarches d urbanisation : réorganiser le Système d Information en structurant ses fonctions dans des blocs fonctionnels communicants.
Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 4 5
Plus en détailBusiness Process Execution Language
Business Process Execution Language Rapport du projet de systèmes distribués d information Markus Lindström 6 mai 2009 Motivation personnelle Le sujet que j ai retenu et présenté dans le cadre du cours
Plus en détailINF 1250 INTRODUCTION AUX BASES DE DONNÉES. Guide d étude
INF 1250 INTRODUCTION AUX BASES DE DONNÉES Guide d étude Sous la direction de Olga Mariño Télé-université Montréal (Québec) 2011 INF 1250 Introduction aux bases de données 2 INTRODUCTION Le Guide d étude
Plus en détailProcessus d Informatisation
Processus d Informatisation Cheminement de la naissance d un projet jusqu à son terme, deux grandes étapes : Recherche ou étude de faisabilité (en amont) L utilisateur a une idée (plus ou moins) floue
Plus en détailIV- Comment fonctionne un ordinateur?
1 IV- Comment fonctionne un ordinateur? L ordinateur est une alliance du hardware (le matériel) et du software (les logiciels). Jusqu à présent, nous avons surtout vu l aspect «matériel», avec les interactions
Plus en détailD une part, elles ne peuvent faire table rase de la richesse contenue dans leur système d information.
PACBASE «Interrogez le passé, il répondra présent.». Le Module e-business Les entreprises doivent aujourd hui relever un triple défi. D une part, elles ne peuvent faire table rase de la richesse contenue
Plus en détailIntroduction au temps réel
Introduction au temps réel Laurent.Pautet@enst.fr Version 2.0 Définition d un système temps réel Un système temps réel se compose d'un ou plusieurs sous-systèmes devant répondre en un temps fini et spécifié
Plus en détailCORBA. (Common Request Broker Architecture)
CORBA (Common Request Broker Architecture) Projet MIAGe Toulouse Groupe 2 1 CORBA, introduction (1/4) Les systèmes répartis permettent de créer des applications basées sur des composants auto-gérables,
Plus en détailArchitecture d'entreprise : Guide Pratique de l'architecture Logique
Guides Pratiques Objecteering Architecture d'entreprise : Guide Pratique de l'architecture Logique Auteur : Version : 1.0 Copyright : Softeam Equipe Conseil Softeam Supervisée par Philippe Desfray Softeam
Plus en détailIBM Tivoli Monitoring, version 6.1
Superviser et administrer à partir d une unique console l ensemble de vos ressources, plates-formes et applications. IBM Tivoli Monitoring, version 6.1 Points forts! Surveillez de façon proactive les éléments
Plus en détailCours 1 : Qu est-ce que la programmation?
1/65 Introduction à la programmation Cours 1 : Qu est-ce que la programmation? Yann Régis-Gianas yrg@pps.univ-paris-diderot.fr Université Paris Diderot Paris 7 2/65 1. Sortez un appareil qui peut se rendre
Plus en détailComment gérer toutes mes tâches logicielles d automatisation dans un seul environnement?
Comment gérer toutes mes tâches logicielles d automatisation dans un seul environnement? Avec Totally Integrated Automation Portal : un seul environnement de développement intégré pour toutes vos tâches
Plus en détailProgrammation parallèle et distribuée
ppd/mpassing p. 1/43 Programmation parallèle et distribuée Communications par messages Philippe MARQUET Philippe.Marquet@lifl.fr Laboratoire d informatique fondamentale de Lille Université des sciences
Plus en détailMaster CCI. Compétences Complémentaires en Informatique. Livret de l étudiant
Master CCI Compétences Complémentaires en Informatique Livret de l étudiant 2014 2015 Master CCI Le Master CCI (Compétences Complémentaires en Informatique) permet à des étudiants de niveau M1 ou M2 dans
Plus en détailHaka : un langage orienté réseaux et sécurité
Haka : un langage orienté réseaux et sécurité Kevin Denis, Paul Fariello, Pierre Sylvain Desse et Mehdi Talbi kdenis@arkoon.net pfariello@arkoon.net psdesse@arkoon.net mtalbi@arkoon.net Arkoon Network
Plus en détailLES OUTILS DU TRAVAIL COLLABORATIF
LES OUTILS DU TRAVAIL COLLABORATIF Lorraine L expression «travail collaboratif» peut se définir comme «l utilisation de ressources informatiques dans le contexte d un projet réalisé par les membres d un
Plus en détailCRÉER UN COURS EN LIGNE
Anne DELABY CRÉER UN COURS EN LIGNE Deuxième édition, 2006, 2008 ISBN : 978-2-212-54153-3 2 Que recouvre le concept d interactivité? Dans une perspective de cours en ligne, une activité interactive est
Plus en détailNFP111 Systèmes et Applications Réparties
NFP111 Systèmes et Applications Réparties 1 de 34 NFP111 Systèmes et Applications Réparties Cours 7 - CORBA/Partie 1 Claude Duvallet Université du Havre UFR Sciences et Techniques 25 rue Philippe Lebon
Plus en détailCloud Computing et SaaS
Cloud Computing et SaaS On a vu fleurir ces derniers temps un grands nombre de sigles. L un des premiers est SaaS, Software as a Service, sur lequel nous aurons l occasion de revenir. Mais il y en a beaucoup
Plus en détailLes plates-formes informatiques intégrées, des builds d infrastructure pour les datacenters de demain
Livre blanc Les plates-formes informatiques intégrées, des builds d infrastructure pour les datacenters de demain Par Mark Bowker, analyste senior, et Perry Laberis, associé de recherche senior Mars 2013
Plus en détailApprendre la Programmation Orientée Objet avec le langage Java (avec exercices pratiques et corrigés)
Introduction à la POO 1. Histoire de la POO 9 2. Historique du 12 La conception orientée objet 1. Approche procédurale et décomposition fonctionnelle 13 2. La transition vers l'approche objet 14 3. Les
Plus en détailGPC Computer Science
CYCLE ISMIN P2015 GPC Computer Science P LALEVÉE lalevee@emse.fr @p_lalevee A3.01 0442616715 C YUGMA yugma@emse.fr A3.01 0442616715 01/09/2014 Présentation GPC CS - Ph. Lalevée - C Yugma 1 Scolarité Site
Plus en détailQuels outils pour prévoir?
modeledition SA Quels outils pour prévoir? Les modèles de prévisions sont des outils irremplaçables pour la prise de décision. Pour cela les entreprises ont le choix entre Excel et les outils classiques
Plus en détailCours Programmation Système
Cours Programmation Système Filière SMI Semestre S6 El Mostafa DAOUDI Département de Mathématiques et d Informatique, Faculté des Sciences Université Mohammed Premier Oujda m.daoudi@fso.ump.ma Février
Plus en détailLe scoring est-il la nouvelle révolution du microcrédit?
Retour au sommaire Le scoring est-il la nouvelle révolution du microcrédit? BIM n 32-01 octobre 2002 Frédéric DE SOUSA-SANTOS Le BIM de cette semaine se propose de vous présenter un ouvrage de Mark Schreiner
Plus en détailUrbanisation des Systèmes d Information Architecture d Entreprise. 04 Architecture du SI : identifier et décrire les services, structurer le SI
Plan du chapitre Master Informatique et Systèmes Urbanisation des Systèmes d Information Architecture d Entreprise 04 Architecture du SI : identifier et décrire les services, structurer le SI 1 2 3 1.1
Plus en détailCours Bases de données
Informations sur le cours Cours Bases de données 9 (10) séances de 3h Polycopié (Cours + TD/TP) 3 année (MISI) Antoine Cornuéjols www.lri.fr/~antoine antoine.cornuejols@agroparistech.fr Transparents Disponibles
Plus en détailINTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES
INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES Les contenus de ce document sont la propriété exclusive de la société REVER. Ils ne sont transmis qu à titre d information et
Plus en détailMEAD : temps réel et tolérance aux pannes pour CORBA
MEAD : un intergiciel temps-réel et tolérant aux pannes pour CORBA Master 2 Informatique Recherche Université de Marne-la-Vallée Vendredi 3 mars 2006 Plan 1 Introduction 2 Solutions existantes 3 Concilier
Plus en détailRebol, un langage «différent»
02 Rebol (1) Chap 01 Page 13 Mardi, 18. septembre 2001 6:06 18 1 Rebol, un langage «différent» «Il est temps de faire quelque chose de différent.» Cette phrase de Carl Sassenrath, le concepteur de Rebol,
Plus en détailEfficace et ciblée : La surveillance des signaux de télévision numérique (2)
Efficace et ciblée : La surveillance des signaux de télévision numérique (2) La première partie de cet article publié dans le numéro 192 décrit la méthode utilisée pour déterminer les points de surveillance
Plus en détailWEA Un Gérant d'objets Persistants pour des environnements distribués
Thèse de Doctorat de l'université P & M Curie WEA Un Gérant d'objets Persistants pour des environnements distribués Didier Donsez Université Pierre et Marie Curie Paris VI Laboratoire de Méthodologie et
Plus en détailSemarchy Convergence for Data Integration La Plate-Forme d Intégration pour le MDM Évolutionnaire
FICHE PRODUIT Semarchy Convergence for Data Integration La Plate-Forme d Intégration pour le MDM Évolutionnaire BENEFICES Des projets réussis dans les délais et les budgets La bonne donnée disponible au
Plus en détailExclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011
Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr Université de Provence 9 février 2011 Arnaud Labourel (Université de Provence) Exclusion Mutuelle 9 février 2011 1 / 53 Contexte Epistémologique
Plus en détailTélé-Procédure de Gestion d Incidents : Spécifications et Prototype.
Télé-Procédure de Gestion d Incidents : Spécifications et Prototype. By Sébastien Pinel Performed at Laboratory LIG Equipe IIHM Université Joseph Fourrier Grenoble In partial fulfillment of the requirements
Plus en détailLe test automatisé des applications web modernes
Le test automatisé des applications web modernes Résumé : Aujourd hui, les applications Web sont développées au moyen de différentes technologies AJAX et Web 2.0. Des outils nouveaux et puissants offrent
Plus en détailProgrammation d'agents intelligents Vers une refonte des fils de raisonnement. Stage de fin d'études Master IAD 2006
vendredi 8 septembre 2006 Programmation d'agents intelligents Vers une refonte des fils de raisonnement Stage de fin d'études Master IAD 2006 Benjamin DEVEZE Responsable : M. Patrick TAILLIBERT Plan Plan
Plus en détailObjectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui
Formation PARTIE 1 : ARCHITECTURE APPLICATIVE DUREE : 5 h Objectif : Passer de l analyse métier et fonctionnelle à la définition des applications qui automatisent les fonctions Définir une architecture
Plus en détailLe logiciel de gestion intégré conçu pour les Promoteurs Immobilier
Le logiciel de gestion intégré conçu pour les Promoteurs Immobilier Solution globale et intégrée qui couvre l'ensemble des principaux aspects de la gestion des projets immobiliers. Depuis l'étude d'une
Plus en détailLES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1
LES NOUVEAUTES DE COST AND PROFITABILITY MANAGEMENT 8.1 SAS Cost and Profitability Management, également appelé CPM (ou C&P), est le nouveau nom de la solution SAS Activity-Based Management. Cette version
Plus en détailQu'est-ce que le BPM?
Qu'est-ce que le BPM? Le BPM (Business Process Management) n'est pas seulement une technologie mais, dans les grandes lignes, une discipline de gestion d'entreprise qui s'occupe des procédures contribuant
Plus en détailConsolidation de stockage
(Information sur la technologie Sto-2003-2) Wolfgang K. Bauer Spécialiste stockage Centre de compétence transtec AG Waldhörnlestraße 18 D-72072 Tübingen Allemagne TABLE DES MATIÈRES 1 RÉSUMÉ...3 2 INTRODUCTION...4
Plus en détailSciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION
Sciences de Gestion Spécialité : SYSTÈMES D INFORMATION DE GESTION Classe de terminale de la série Sciences et Technologie du Management et de la Gestion Préambule Présentation Les technologies de l information
Plus en détailET 24 : Modèle de comportement d un système Boucles de programmation avec Labview.
ET 24 : Modèle de comportement d un système Boucles de programmation avec Labview. Sciences et Technologies de l Industrie et du Développement Durable Formation des enseignants parcours : ET24 Modèle de
Plus en détailQuel logiciel DE CRM choisir pour votre force de vente terrain?
Quel logiciel DE CRM choisir pour votre force de vente terrain? plusieurs études démontrent que les projets CRM sont des échecs dans 40 à 80% des cas. Les principales causes d échec sont : Le rejet par
Plus en détailNovembre 2013. Regard sur service desk
Novembre 2013 Regard sur service desk édito «reprenez le contrôle grâce à votre service desk!» Les attentes autour du service desk ont bien évolué. Fort de la riche expérience acquise dans l accompagnement
Plus en détailLa dernière base de données de Teradata franchit le cap du big data grâce à sa technologie avancée
Communiqué de presse Charles-Yves Baudet Twitter: Les clients de Teradata Teradata Corporation peuvent dan.conway@teradata.com tirer parti de plusieurs + 33 1 64 86 76 14 + 33 (0) 1 55 21 01 48/49 systèmes,
Plus en détailAnnexe : La Programmation Informatique
GLOSSAIRE Table des matières La Programmation...2 Les langages de programmation...2 Java...2 La programmation orientée objet...2 Classe et Objet...3 API et Bibliothèque Logicielle...3 Environnement de
Plus en détailISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité
NORME INTERNATIONALE ISO/CEI 19770-1 Deuxième édition 2012-06-15 Technologies de l information Gestion des actifs logiciels Partie 1: Procédés et évaluation progressive de la conformité Information technology
Plus en détailManuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2
éducalgo Manuel d utilisation 26 juin 2011 Table des matières 1 Tâche à effectuer : écrire un algorithme 2 2 Comment écrire un algorithme? 3 2.1 Avec quoi écrit-on? Avec les boutons d écriture........
Plus en détailFAMILLE EMC VPLEX. Disponibilité continue et mobilité des données dans et entre les datacenters AVANTAGES
FAMILLE EMC VPLEX Disponibilité continue et mobilité des données dans et entre les datacenters DISPONIBLITÉ CONTINUE ET MOBILITÉ DES DONNÉES DES APPLICATIONS CRITIQUES L infrastructure de stockage évolue
Plus en détailProjet Active Object
Projet Active Object TAO Livrable de conception et validation Romain GAIDIER Enseignant : M. Noël PLOUZEAU, ISTIC / IRISA Pierre-François LEFRANC Master 2 Informatique parcours MIAGE Méthodes Informatiques
Plus en détailPROBLEMES D'ORDONNANCEMENT AVEC RESSOURCES
Leçon 11 PROBLEMES D'ORDONNANCEMENT AVEC RESSOURCES Dans cette leçon, nous retrouvons le problème d ordonnancement déjà vu mais en ajoutant la prise en compte de contraintes portant sur les ressources.
Plus en détailRédiger et administrer un questionnaire
Rédiger et administrer un questionnaire Ce document constitue une adaptation, en traduction libre, de deux brochures distinctes : l une produite par l American Statistical Association (Designing a Questionnaire),
Plus en détailScrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013
Scrum Le guide pratique de la méthode agile la plus populaire 3 e édition Claude Aubry 320 pages Dunod, 2013 Illustration de couverture : Clément Pinçon Dunod, Paris, 2014 ISBN 978-2-10-071038-6 Préface
Plus en détailCours de Java. Sciences-U Lyon. Java - Introduction Java - Fondamentaux Java Avancé. http://www.rzo.free.fr
Cours de Java Sciences-U Lyon Java - Introduction Java - Fondamentaux Java Avancé http://www.rzo.free.fr Pierre PARREND 1 Octobre 2004 Sommaire Java Introduction Java Fondamentaux Histoire de Java Machine
Plus en détailJ2SE Threads, 1ère partie Principe Cycle de vie Création Synchronisation
J2SE Threads, 1ère partie Principe Cycle de vie Création Synchronisation Cycle Ingénierie 2e année SIGL Dernière mise à jour : 19/10/2006 Christophe Porteneuve Threads Principes Cycle de vie Création java.lang.thread
Plus en détailCommission du marché intérieur et de la protection du consommateur DOCUMENT DE TRAVAIL
PARLEMENT EUROPÉEN 2009-2014 Commission du marché intérieur et de la protection du consommateur 3.3.2010 DOCUMENT DE TRAVAIL sur la proposition de directive relative aux droits des consommateurs - COM(2008)614/3-2008/0196(COD)
Plus en détailOrdonnancement temps réel
Ordonnancement temps réel Laurent.Pautet@enst.fr Version 1.5 Problématique de l ordonnancement temps réel En fonctionnement normal, respecter les contraintes temporelles spécifiées par toutes les tâches
Plus en détailSolution A La Gestion Des Objets Java Pour Des Systèmes Embarqués
International Journal of Engineering Research and Development e-issn: 2278-067X, p-issn: 2278-800X, www.ijerd.com Volume 7, Issue 5 (June 2013), PP.99-103 Solution A La Gestion Des Objets Java Pour Des
Plus en détailEntraînement, consolidation, structuration... Que mettre derrière ces expressions?
Entraînement, consolidation, structuration... Que mettre derrière ces expressions? Il est clair que la finalité principale d une démarche d investigation est de faire acquérir des connaissances aux élèves.
Plus en détail