Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud

Dimension: px
Commencer à balayer dès la page:

Download "Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud"

Transcription

1 Formalisation de propriétés de flux d information avec une logique temporelle du premier ordre pour assurer la sécurité d une infrastructure de Cloud Arnaud Lefray,, Jonathan Rouzaud-Cornabas Université de Lyon - Laboratoire LIP UMR CNRS - ENS de Lyon - INRIA - UCB Lyon 5668 INSA Centre Val de Loire - Université d Orléans, LIFO EA 4022, Bourges, France Résumé L adoption massive du Cloud est principalement freinée par le manque de sécurité. Le concept de sécurité à la demande consiste à proposer et appliquer les objectifs de sécurité du client. Dans ce papier, nous présentons une approche, nommée Information Flow Past Linear Time Logic (IF-PLTL), pour spécifier un large panel de propriétés de sécurité d un système. Nous présentons également comment contrôler les flux d information à partir d évènements de bas niveau. Nous décrivons en détail la syntaxe et la sémantique de IF-PLTL. De plus, cette logique permet de formaliser un large ensemble de politique de sécurité paramétrable par un client. Nous illustrons cette approche avec une politique d isolation basée sur des propriétés de non-interférence. Enfin, nous discutons l extension avec des ensembles dynamique de IF-PLTL pour inclure des cas d usage plus réalistes comme la politique d isolation dynamique des domaines. Mots-clés : Sécurité, Flux d information, Cloud, Système formel, Sémantique. 1. Introduction L adoption massive du modèle Cloud est principalement freinée par le manque de sécurité [16]. Un environnement de Cloud fait face à diverses menaces allant des attaques traditionnelles sur les systèmes d exploitation (SE) (au niveau hyperviseur ou machine virtuelle) ou les réseaux, jusqu aux nouvelles menaces issues des environnements partagés tels que les ressources matérielles partagées au niveau IaaS [5], les ressources (virtuelles) systèmes partagées au niveau PaaS [14], et les ressources applicatives partagées au niveau SaaS. Une politique de sécurité efficace doit prendre en compte tous les niveaux multi-tenants, à savoir, IaaS, PaaS et SaaS. Sécuriser les Clouds est un domaine de recherche très actif dont témoigne les nombreux projets académiques et industriels en cours. Nous pensons qu un concept clé est de délivrer une sécurité à la demande. Un utilisateur doit pouvoir spécifier quel est le comportement sécurisé de son système. Ainsi, nous devons proposer un langage qui permet l expression d objectifs de sécurité spécifiques à un client. Cependant, spécifier ou configurer une politique de sécurité est très souvent complexe et sujet à erreur. Même en tant qu expert de la sécurité, un humain peut toujours effectuer une mauvaise

2 configuration donnant lieu à des failles. Pour cette raison, les politiques de sécurité doivent être appliquées de manière automatique, c est-à-dire où l intervention humaine est réduite à sa stricte nécessité. Par exemple, le comportement souhaité d un système, c est-à-dire ce qu il doit ou ne doit pas faire, ne peut être spécifié que par le client. Par conséquent, après cette première étape de spécification, le système doit adopter un contrôle d accès obligatoire (Mandatory Access Control) où même l utilisateur ayant tous les privilèges (root) ne peut modifier la politique de sécurité. Halpern et al. [10] avancent que des politiques de sécurité décrites dans un langage naturel ont une sémantique ambigüe. En revanche, un langage formel (ou une logique) ont une syntaxe et une sémantique très claires. Dans ce papier, nous proposons une logique adéquate pour un système concurrent, nondéterministe et multi-tenant. Pour être utilisable en pratique, notre système formel doit satisfaire les contraintes suivantes : 1. Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs. 2. Il doit modéliser des systèmes multi-domaines, concurrents et non-déterministes. 3. Il doit être utilisable par des non logiciens tels qu un client IaaS. Lorsque qu ils sont correctement configurés, de nombreux mécanismes de sécurité ont prouvé leur efficacité pratique, par exemple SELinux ou Iptables. Considérant qu une sécurité ne doit pas dépendre d une technologie unique, la formalisation d objectifs de sécurité doit être suffisamment expressive pour être projetée vers la logique interne de ces mécanismes de sécurité. Le papier est organisé comme suit. La section 2 discute des trois contraintes et motive notre travail en examinant les approches de sécurité existantes. La section 3 décrit comment modéliser un système avec des traces de flux d information. La section 4 décrit la syntaxe et la sémantique de notre logique IF-PLTL. La section 5 illustre les propriétés de haut-niveau et étend IF-PLTL avec des annotations pour forcer la dynamicité des ensembles de contextes en montrant son intérêt avec une politique d isolation dynamique des domaines. Enfin, la section 6 conclut avec les perspectives et les questions ouvertes. 2. Motivations Le contrôle de flux d information (IFC) et le contrôle d accès peuvent être vus comme des approches différentes mais potentiellement complémentaires pour assurer la sécurité [11]. En effet, le contrôle d accès spécifie explicitement les permissions d un acteur vis à vis d une action sur une ressource tandis que les flux d informations (IF) sont implicites. Le contrôle de flux d information spécifie explicitement les flux autorisés tandis que les permissions pour réaliser une action particulière sont implicites. Une politique d IF entre deux entités est soit directe, transitive ou intransitive. Supposons une politique autorisant des flux directs d une entité A vers une autre B et également de B vers C. Une politique transitive autorisera un flux direct de A vers C par transitivité. Cependant une politique intransitive refusera un flux direct de A vers C mais permettra un flux de A vers C passant par B. Ces politiques d IF sont difficiles à exprimer [15] mais elles sont essentielles. C est pourquoi, nous devons les inclure dans notre formalisme. Les systèmes d IFC abordent tous types d environnements depuis les systèmes statiques jusqu aux moniteurs de référence (à l exécution). Dans le cas statique, les propriétés d IF sont vérifiées sur un modèle complet du système [8]. Dans le cas dynamique, les propriétés d IF sont

3 vérifiées à l exécution [7]. Dans notre approche, nous proposons un système formel incluant à la fois le cas statique et celui dynamique. A notre connaissance, les travaux les plus proches des nôtres ont été effectués par Basin et al. dans [2]. Leur approache est similaire à la nôtre dans le sens où elle inclut les modalités de temps de la logique temporelle linéaire passée (P-LTL) et elle modélise le comportement d un système avec des (ensembles de) traces. Néanmoins, leur proposition diffère de la nôtre en ne modélisant pas explicitement des flux d information et en définissant un ensemble de relations dépendant du cas d utilisation. Utiliser un IFC dans les Clouds pour assurer des objectifs de sécurité a été mis en avant [1, 16] mais jamais appliqué. L utilisabilité est également un facteur qui doit être pris en compte lorsque l on propose une nouvelle approche de sécurité. En effet, si la description d objectifs de sécurité est trop complexe, alors l approche ne peut être utilisée en pratique. C est pourquoi nous proposons une API de haut-niveau composée de politiques de sécurité généralistes, chaque propriété les composant étant définie formellement. La formalisation présentée dans ce papier est issue du langage PIGA mais revisitée avec plus de formalisme et de généralisation. Le langage PIGA a été utilisé pour implanter des moniteurs de référence dans divers environnements comme PIGA-OS, PIGA-Virt, PIGA-Cluster et PIGA- Dalvik [3, 4]. Aperçu de notre approche Dans cette section, nous avons discuté de la contrainte suivante Il doit modéliser la manière dont l information est échangée, à savoir des flux d information directs, transitifs ou intransitifs et défini le spectre de notre étude aux IFCs systèmes avec analyse statique et monitoring dynamique. La deuxième contrainte Il doit modéliser des systèmes multi-domaines, concurrents et nondéterministes a été motivée principalement par l architecture multi-tenante des Clouds. La dernière contrainte Il doit être utilisable par des non logiciens tels qu un client IaaS est plus intuitive et peut être achevée en proposant une API simple de haut-niveau. Notre objectif est de décider si le comportement d un système, modélisé par des traces, satisfait une politique de sécurité formalisée par des formules logiques. Une trace est une séquence de transitions d états. Un système ne produit par directement des flux d information mais des évènements observables de bas niveau. Ces évènements sont transformés en évènements fonctionnels et finalement en flux d information. Une trace d IF satisfait (ou non) une politique de sécurité, c està-dire un ensemble de formules closes appelé théorie. Enfin, une API adaptée à l utilisateur est proposée via un ensemble de propriétés de haut niveau paramétrables, l exemple de la politique d isolation dynamique des domaines étant donnée dans la section Modélisation d un système : les traces Dans cette section, nous présentons comment construire des traces d IF à partir d évènements de bas niveau. Pour définir la sécurité dans un Cloud IaaS composé de SEs virtuels et physiques, nous devons représenter un système concurrent et non-déterministe. Nous définissons un système primitif comme une boîte noire avec un état interne et une interface acceptant un ensemble d actions. Ainsi, un système est une composition (récursive) de systèmes primitifs (ou systèmes). Toutes entités d un environnement type SE, à savoir les fichiers, processus, bases de données, peuvent être vue comme des systèmes. Chaque machine virtuelle est également un sous-

4 système d un Cloud. Le comportement concurrent d un système peut être modélisé par les traces d exécution générées par ce système [12], où une trace d exécution est une séquence de transitions d états déclenchées par des évènements et vue par un observateur. Nous définissons cet observateur comme une entité passive avec une vue (potentiellement partielle) du système. Supposons un système avec seulement trois entités (a, b, c). a voit une trace partielle composée de tous les évènements partant de ou allant vers lui-même mais il ne peut pas voir les évènements entre b et c. De plus, un évènement de a vers b est à la fois inclus dans les traces de a et de b. Par conséquent, l union de toutes les traces partielles forme une trace complète du système. Les entités étant de types hétérogènes, elles sont identifiées par des contextes, c est-à-dire des références abstraites à des entités ayant un ensemble commun de caractéristiques. Nous supposons l existence d une méthode permettant d attribuer un contexte à toute entité, sachant que deux entités avec le même contexte ont un ensemble commun de caractérisques (comportement, domaine de sécurité, type, etc.). Par la suite, nous notons SC l ensemble de tous les contextes Traces avec évènements observables Le noyau a une vue complète de toutes les traces d un SE. Les appels noyaux, tels que sys_read, sys_write, sys_fork, impliquent une entité source et une entité destination (potentiellement nouvelle dans le cas de sys_fork). Par la suite, nous supposons être capable de capturer le début et la fin de tout appel. À noter qu il est possible d implanter un tel module dans n importe quel noyau [3]. Un évènement observable (Définition 1) est un évènement atomique vu par un observateur. Tous les évènements observables font parti de l ensemble OE (SC EOP SC) où EOP est l ensemble des opérations élémentaires (début_lire, début_écrire, fin_lire,... ). Le triplet (a, eop, b) décrit l opération eop du contexte a vers b. { a, b SC Définition 1 (Évènement observable) oe OE def (a, eop, b) où eop EOP Une trace de bas niveau (Définition 2) produite par le système est un ensemble d évènements observables. La Figure 1a montre un exemple de trace d un système composé de trois entités (a, b, c), une opération de lecture est terminée et une opération d écriture est toujours en cours (pas d évènement de fin). Définition 2 (Trace d évènements observables) T def {oe 1, oe 2,..., oe n } où oe i OE (a) Trace d évènements observables (b) Trace d évènements fonctionnels (c) Trace de flux d information FIGURE 1 Les trois types de traces 3.2. Traces d évènements fonctionnels À partir des évènements de début et de fin, nous pouvons obtenir l évènement fonctionnel correspondant (Définition 3) comprenant l opération fonctionnelle telle que lire, écrire. Une en-

5 tité peut réaliser plusieurs opérations en parallèle. Supposons un contexte a effectuant deux lectures d un contexte b ; par exemple deux entités avec le contexte a lisent un fichier avec le contexte b. Pour associer correctement les évènements de début et de fin, un observateur doit distinguer les deux opérations parallèles de lecture, notamment dans le cas où les sources et les destinations sont identiques. Ainsi, nous supposons deux fonctions est_évènement_début et est_évènement_fin, déterminant respectivement si un évènement observable oe i est le début d une opération fonctionelle op et si un évènement observable oe j est la fin d une opération op commençant avec oe i. Tous les évènements d une trace fonctionnelle (Définition 4) sont dans l ensemble FE (SC FO SC) et toutes les opérations fonctionnelles dans l ensemble FO. Les deux fonctions est_évènement_début et est_évènement_fin sont définies comme suit : est_évènement_début : OE FO {true, false} est_évènement_fin : OE OE {true, false} Définition 3 (Évènement fonctionnel) a, b SC, op FO k [i, j], (a, op, b) k FE def i i, oe i = (a, eop début, b) i est_évènement_début(oe i, op) j j, oe j = (a, eop fin, b) j est_évènement_fin(oe j, oe i ) La notation (a, op, b) k décrit une opération op de a sur b à l instant k. Définition 4 (Trace d évènements fonctionnels) T def {fe 1, fe 2,..., fe n } où fe i FE La Figure 1b illustre le résultat de la projection des évènements observables de la Figure 1a en évènements fonctionnels. Dans cette trace, le premier évènement observable (a, début_lire, b) et le troisième (a, fin_lire, b) sont transformés en un évènement fonctionnel (a, lire, b) ayant lieu à tout instant du début à la fin (inclus) Traces de flux d information Les différents modèles de flux d information diffèrent de part leur expressivité et leurs relations. Cependant, nous pouvons extraire deux relations/opérations communes : La relation propagation vers. Par exemple, une information se propage de a vers b. L opération re-labellisation. Par exemple, une entité labellisée avec a est re-labellisée avec b. Une opération de re-labellisation initiée par une entité est appelé une transition ; par exemple, une entité souhaite transiter du contexte a vers b. Nous considérons trois relations dans nos traces de flux d information : Un flux de a vers b est défini par (a > b). Un anti-flux (l absence de flux) de a vers b est défini par (a b). Une transition de a vers b est définie par (a > t b). Pour transformer des évènements fonctionnels en flux d information, nous introduisons trois fonctions déterminant si une opération fonctionnelle (op FO) est équivalente à une opération lire, écrire ou transiter. est_type_lire, est_type_écrire, est_type_transiter : FO {true, false} Les définitions 5, 6 définissent formellement les deux relations (>, > t ) à partir des fonctions est_type_lire, est_type_écrire, est_type_transiter, la relation étant simplement la négation de >. Tous les évènements d une trace d IF sont inclus dans l ensemble IF.

6 Définition 5 (Relation flux vers) ((b, op, a) est_type_lire(op)) (a > b) IF def op FO ((a, op, b) est_type_écrire(op)) Définition 6 (Relation transition) (a > t b) IF def op FO((a, op, b) est_type_transiter(op)) La Figure 1c illustre le résultat de la projection des évènements fonctionnels de la Figure 1b en flux d information. (a, lire, b) et (c, écrire, b) sont substitués respectivement par (a < b) and (c > b). 4. Propriétés de sécurité : une logique temporelle Un ensemble de traces d exécution d un système est soit généré statiquement à partir d un modèle (sous forme d automate, de réseau de pétri, etc.) soit dynamiquement produit à l exécution. Dans le cas statique, nous obtenons un ensemble de traces (potentiellement) infinies représentant toutes les exécutions possibles vues par un observateur. Dans le cas dynamique, nous obtenons une trace finie par observateur représentant l historique de l exécution courante. Nous présentons dans cette section la syntaxe et sémantique de notre logique temporelle multisortée avec flux d information devant prendre en compte indifféremment les deux cas Logique temporelle multi-sortée avec flux d information Pour modéliser les propriétés de trace, nous utilisons une logique temporelle multi-sortée du premier ordre sur des flux d information. Une logique temporelle définie implicitement l écoulement du temps au cours duquel les formules sont évaluées. Une logique du premier ordre permet l utilisation de quantificateurs pour exprimer des propriétés telles que : Il existe un contexte a depuis lequel un flux est initié. Enfin, une logique multi-sortée, par opposition avec une logique monosorté, permet de définir plusieurs sortes de domaines au lieu d un unique domaine de définition sur lequel les quantificateurs itèrent. La notion de sortes permet de différencier les contextes des domaines sans recourir à une logique du second ordre. Ci-dessous, nous donnons la définition générale d une signature multi-sortée, c est-à-dire les symboles non-logiques (d une logique multi-sortée), puis détaillons la signature concrète de notre logique IF-PLTL. Décrivons tout d abord une signature multi-sortée (Définition 7). Définition 7 (Signature multi-sortée) Une signature multi-sortée est un t-uplet Σ = (S, C, F, P) où : S = {σ 1,..., σ n } où n > 0 et σ i est une sorte. C = {c 1,..., c n } où n 0 et c i est un symbole de constante de sorte σ S. F = {f 1,..., f n } où n 0 et f i est un symbole de fonction d arité m 0 de sortes (σ 1... σ m ) σ où σ i S et σ S. P = {p 1,..., p n } où n 0 et p i est un symbole de prédicat d arité m 0 de sortes (σ 1... σ m ) où σ i S. Les informations de temps peuvent être rendues implicites avec les modalités de PLTL (LTL Passé) [13]. (P-)LTL est un formalisme courant pour exprimer des propriétés de sûreté et de vivacité dans un système concurrent. Clarkson et al. [6] ont démontré qu une propriété de

7 sécurité est une intersection entre une propriété de sûreté et une propriété de vivacité. Alors qu une logique multi-sortée est bien adaptée à la spécification de propriétés d IF, (P-)LTL est bien adapté pour exprimer des propriétés d IF temporelles Syntaxe d IF-PLTL La syntaxe décrit comment construire une formule bien-formée de notre logique. Une formule est dite bien-formée si elle fait partie de notre langage formel. Autrement dit, une formule malformée ne peut être interprétée par notre système. Tout d abord, nous donnons la signature multi-sortée pour des flux d information temporels (Σ IF PLTL ), puis nous décrivons les règles de formation. Σ IF PLTL = (S, C, F, P) avec, {>,,, > t : ctx ctx S = {ctx, dom}, C =, F =, P =, / : ctx domain, / : domain domain} Nous considérons deux sortes ctx et dom pour désigner respectivement des contextes et des domaines (ensembles de contextes). Tout comme pour des traces d IF, les relations d IF (>,, > t ) sont naturellement définies entre contextes. De plus, nous introduisons la relation de flux indirect ( ) sémantiquement différent d un flux direct (>). Ce flux indirect n existe pas dans une trace d IF ; il est inféré à partir d une séquence de flux directs. Par exemple, la trace d IF de la Figure 1c satisfait la propriété c a aux deuxième et troisième instants de part l indirection c > b et b > a. Les relations d appartenance ensembliste (, / ) sont, premièrement, définies entre un contexte et un domaine, mais également entre domaines pour permettre la spécification d ensembles hiérarchiques. Par exemple, supposons un contexte a, un domain Set et un domain SuperSet, nous pouvons définir des relations hiérarchiques avec a Set est vrai, Set SuperSet est vrai et a SuperSet est faux. Ci-dessous, nous détaillons les règles de formations. x σ est une variable de sorte σ. c σ est un symbole de contante de sorte σ. Σ-TERM t ::= x σ c σ f(t 1,..., t n ) où f : σ 1... σ n σ est un symbole de fonction avec Σ-TERM t i de sorte σ i. Σ-ATOM a ::= p(t 1,..., t n ) où p : σ 1... σ n est un symbole de prédicat avec t i Σ-TERM de sorte σ i. Σ-FORMULAE ϕ ::= a ϕ ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 ϕ 1 ϕ 2 σ xϕ(x) σ xϕ(x) X(ϕ) Y(ϕ) ϕ 1 Uϕ 2 ϕ 1 Sϕ 2 où a est un Σ-ATOM et x une variable de sorte σ. Les quatre modalités dérivées sont définies comme suit : Fϕ Uϕ Gϕ F ϕ Pϕ Sϕ Hϕ P ϕ Xϕ (Next) et Yϕ (Previous) sont vrais si ϕ est satisfait respectivement à l instant précédant et à l instant suivant. ϕ 1 Uϕ 2 (Until) est vrai si ϕ 1 est satisfait jusqu à ce que ϕ 2 le soit, ϕ 1 Sϕ 2 (Since) étant l équivalent passé. Nous donnons trois abréviations pour simplifier l expression des formules : ( x y)ϕ(x) ( x)(x y) ϕ(x) ( x y)ϕ(x) ( x)(x y) ϕ(x) (a / s) (a s) Pour simplifier la notation, nous supposerons les sortes comme implicitement définies. Par exemple, dans la formule ( a, b)(a > b), a, b sont de sorte ctx, la relation > n étant définie qu entre deux contextes.

8 Nom Séquent Flux intransitif (a > b) i (b > c) j, i j (a c) j L intérêt de règles de Introduction de l anti-flux (a > b) i (a b) i déduction est de pouvoir réaliser des preuves Implication du flux de transition (a > t b) i (a > b) i Élimination de l anti-flux (a b) i (a > b) i et théorèmes comme Flux de transition transitif (a > t b) i (b > t c) i (a > t c) i prouver l équivalence TABLE 1 Arguments dérivés entre deux formules. Nous disposons de toutes les règles classiques de la logique du premier ordre (Système dit d Hilbert), de PLTL et la Table 1 décrit les arguments pour les quatre relations sur les flux d information (>,, > t, ). La notation simplifiée (a > b) i décrit la relation > entre les variables a, b (de sorte implicite ctx) au moment i Sémantique d IF-PLTL La sémantique décrit comment évaluer une formule arbitraire bien-formée d IF-PLTL. Tout d abord, nous définissons ce qu est une structure multi-sortée du premier ordre (Définition 8) obtenue à chaque moment de l exécution ; il n y a pas de notion de temps dans cette structure. Puis, nous définissons une structure temporelle du premier ordre (Définition 9) interprétant l écoulement du temps. Ensuite, nous donnons la définition de la relation de satisfaction ( =) entre une structure IF-PLTL et une formule IF-PLTL. Enfin, nous illustrons ce qu est une interprétation avec l exemple de la propriété de non-interférence. Une structure multi-sortée du premier ordre M est composée d un domaine D et d une fonction d interprétation I. Le domaine est l ensemble de tous les objets de sortes ctx, dom. La fonction d interprétation définit la signification de tous les symboles pouvant apparaître dans une formule (sans les modalités temporelles). Définition 8 (Structure multi-sortée du premier ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est un t-uplet M = (D, I) avec : 1. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 2. I une fonction d interprétation sur D satisfaisant les propriétés suivantes : (a) Toute sorte σ S est projetée vers un domaine non-vide D σ. (b) Tout symbole de constante c C de sorte σ est projeté vers un élément c I D σ. (c) Tout symbole de fonction f F d arité σ 1... σ n σ est projeté vers une fonction f I : D σ1... D σn D σ. (d) Tout symbole de prédicat p P d arité σ 1... σ n est projeté vers un sous-ensemble p I D σ1... D σn. Une structure temporelle du premier ordre M est composée de l écoulement du temps F, du même domaine D et d une fonction A associant à tout moment de l exécution une structure multi-sortée du premier ordre telle qu introduite précédemment. Définition 9 (Structure temporelle du premier-ordre) Une Σ IF PLTL -structure (ou modèle) temporelle du premier ordre est définie par M = F, D, A avec : 1. F = T, < une ordre linéaire strict représentant l écoulement du temps avec T N. 2. D = σ S D σ un domaine multi-sorté avec D σ un domaine non-vide. σ 1, σ 2 S, D σ1 D σ2 =. 3. A une fonction associant à tout moment k T une structure multi-sortée du premier ordre A(k) = D, I k avec I k l interprétation au moment k.

9 Nous utilisons la notation (M, k) pour désigner une structure multi-sortée du premier ordre au moment k. La relation de satisfaction (ou de vérité) (M, k) = ϕ entre un modèle (structure) M et une formule ϕ au moment k est definie comme suit : (M, k) = (a > b) ssi (a > b) I k (>) (M, k) = (a > t b) ssi (a > t b) I k (> t ) (M, k) = (a s) ssi (a s) I k ( ) (M, k) = (a b) ssi (M, k) = (a > b) (M, j) = (c > b) (M, k) = (a b) ssi i, j, (0 i j k), ctx c et (M, i) = (a > c) (a c) (M, k) = ϕ ssi (M, k) = ϕ (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 et (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ou (M, k) = ϕ 2 (M, k) = ϕ 1 ϕ 2 ssi (M, k) = ϕ 1 ϕ 2 et (M, k) = ϕ 2 ϕ 1 (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour tout x I D σ (M, k) = σ xϕ(x) ssi (M, k) = ϕ[x I /x] pour un x I D σ (M, k) = Xϕ ssi k + 1 < T et (M, k + 1) = ϕ (M, k) = Yϕ ssi 0 < k et (M, k 1) = ϕ (M, i) = ϕ 2 (M, k) = ϕ 1 Uϕ 2 ssi i, (k i < T ), et j, (k j < i), (M, j) = ϕ 1 (M, i) = ϕ 2 (M, k) = ϕ 1 Sϕ 2 ssi i, (0 i k), et j, (i < j k), (M, j) = ϕ 1 Isolation et Non-interférence Un problème majeur dans les Clouds concerne l isolation des tenants. Goguens et Meyers [9] définissent la propriété d isolation à partir de deux propriétés de non-interférence. Les auteurs dénotent par D 1 : D 2 qu un groupe d utilisateurs D 1 n interfère pas avec un groupe d utilisateurs D 2 et l isolation entre D 1 et D 2 est définie comme une non-interférence mutuelle, soit D 1 : D 2 et D 2 : D 1. En terme de flux d information, la propriété de non-interférence D 1 : D 2 signifie que l information ne peut, directement ou indirectement, se propager de D 1 vers D 2, ce qui peut être traduit par u 1 D 1, u 2 D 2, ((u 1 u2) (u 1 > u 2 )). Illustrons maintenant l interprétation avec la propriété FIGURE 2 Scénario d IF avec trois groupes (D 1, D 2, D 3 ) et six entités (a, b, c, d, e, f) de non-interférence. Supposons le scénario représenté par la Figure 2. Cette figure doit être lue comme suit : À l instant 1, l information se propage de a vers b, puis à l instant 2 de f vers e, et ainsi de suite aux instants 3 et 4. À l instant 5, il y a une transition de c vers f signifiant que l entité labellisée avec c souhaite être re-labellisée avec f. La Table 2 détaille pour tout moment k l interprétation de chaque relation (>, > t, ).

10 Instant k Trace (a > b) (f > e) (b > f) (f > d) (c > t f) I k (>) {(a > b)} {(f > e)} {(b > f)} {(f > d)} {(c > f)} I k (> t) {(c > t f)} I k ( ) D 1 = {a, b, c} idem idem idem idem D 2 = {d, e} D 3 = {f} D 1 : D 2 true true true false true TABLE 2 Interprétation et satisfaction de la non-interférence entre D 1 et D 2. Nous avons motivé l utilisation d une logique temporelle multi-sortée avec flux d information et introduit la syntaxe/sémantique de IF-PLTL. De plus, nous avons montré comment spécifier la propriété de non-interférence en IF-PLTL et comment la vérifier sur une trace d IF. 5. Dynamicité : opérateurs sur les ensembles Comme illustré par l exemple de la non-interférence (Figure 2 et Table 2), l interprétation de la relation ensembliste ( ) est identique à tout moment k. De plus, il n y a ni fonction ni relation permettant de changer cette interprétation durant l exécution, c est-à-dire de modifier l appartenance à un ensemble. Ci-après, nous présentons une politique, l isolation des domaines, où des ensembles dynamiques peuvent présenter un intérêt, puis nous détaillons notre proposition basée sur des annotations de formules. Enfin, nous décrivons la politique d isolation dynamique des domaines. En effet, les ensembles dynamiques sont nécessaires pour augmenter la flexibilité des propriétés et ainsi permettre la prise en compte de la dynamicité des systèmes. Supposons une politique d isolation des domaines stricte définie par la propriété 1 où deux entitités (a, b) peuvent échanger des informations si elles sont dans le même domaine (Dom i ). Avec une telle politique, une entité n appartenant à aucun domaine ne peut pas envoyer d information à quiconque. Ainsi, toutes les entités du système doivent être correctement labellisées avec un domaine, ce qui est une tâche complexe et chronophage. Propriété 1 (Isolation des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a, b Dom i )) FIGURE 3 Scénario avec différents départements pour une isolation dynamique des domaines. Considérons le scénario décrit par la Figure 3. Une compagnie externalise ses services dans le Cloud. Cette compagnie est composée de deux départements, R&D et ressources humaines (RH), et chaque département possède des données confidentielles. Le département de R&D possède une base de donnée pour un gestionnaire de projet (données_project). Le département des RH possède toutes les données privées des employés (données_employés). Dû à la branche R&D, la société doit tester des versions d un logiciel (app_nonstable) qui sont donc non sûres et doivent être isolées du reste des services. Par ailleurs, la compagnie teste régulièrement des logiciels externes dans lequels elle n a pas totalement confiance (app_nonfiable). Enfin, la société dispose de plusieurs applications (app1_entreprise, app2_entreprise) pouvant varier

11 au fil du temps (par exemple, ajout d une app3_entreprise). La politique de l entreprise définit qu une application ne peut accéder à la fois aux domaines R&D et RH mais sans connaître a priori quelle application accède à quelles données. L idée est donc de contaminer les applications avec le domaine auquel elles appartiennent selon le premier accès réalisé. Par exemple, si app1_entreprise accède à données_project, elle fera partie du domaine R&D. Notre politique d isolation dynamique des domaines est décomposée en trois propriétés. Supposons DOMs contenant les domaines et les bacs à sable, alors l information peut se propager d un contexte a vers un contexte b si : 1. a, b appartiennent au même ensemble Dom i (de DOMs). Cette contrainte correspond à l isolation statique des domaines (propriété 1). 2. ou a n appartient à aucun ensemble. 3. ou a appartient à Dom i et b n appartient à aucun ensemble, alors b devient membre de Dom i. Nous proposons la syntaxe ϕ[[annotation]] signifiant que Annotation est effectué lorsque ϕ est vrai. Une annotation pour modifier l appartenance à des ensembles serait donc [[S S {x}]], c est-à-dire x devient membre de S. La propriété 2 traduit les trois propriétés précédentes en IF-PLTL. Propriété 2 (Isolation dynamique des domaines) DI(DOMs) ( a, b)g((a > b) ( Dom i DOMs)(a / Dom i )) DDI(DOMs) ( a, b)( Dom i DOMs)G ( ((a > b) (a Dom i ) ( Dom j DOMs)(b / Dom j )) [Dom i Dom ) i {b} ] Ainsi, nous avons contruit une propriété d isolation dynamique des domaines (DDI). Un client IaaS doit donc simplement appeler la fonction DDI avec son paramètre DOMs ; par exemple, DDI({R&D, R&H, Env.Test, Autres}). Nous avons montré les bénéfices de l utilisation d annotations pour étendre notre logique avec des ensembles dynamiques. De plus, les annotations peuvent être utilisées pour spécifier des capacités actives de l observateur (qui n est donc plus passif ) ne se limitant pas à l exemple des ensembles dynamiques. 6. Conclusion Tout d abord, nous avons motivé le besoin d un langage d IFC formel pour des systèmes distribués et montré la différence entre notre approche et les précédentes. Puis, nous avons présenté notre langage formel permettant l expression de propriétés de sécurité avancées contrôlant différents types de flux d information : directs, transitifs et intransitifs. En utilisant ces opérateurs, notre Information Flow Past Linear Time Logic (IF-PLTL) permet l expression de diverses propriétés ou politiques de sécurité telles que la non-interférence. De plus, nous avons montré comment construire une trace d IF à partir des évènement de bas niveau d un système. Pour faciliter l utilisation d IF-PLTL, nous avons proposé une API de haut niveau pouvant être utilisée et paramétrée par des clients IaaS pour exprimer leurs objectifs de sécurité. Enfin, nous avons montré comment étendre IF-PLTL pour prendre en compte la dynamicité des systèmes et proposé une nouvelle politique de sécurité nommée isolation dynamique des domaines. Par la suite, nous proposerons des méthodes pour assurer la composabilité des différentes propriétés. Nous travaillerons également sur le découpage de propriétés IF-PLTL pour un ensemble d observateurs collaboratifs, en particulier des observateurs à différents niveaux du Cloud (IaaS, PaaS, SaaS). Enfin, une étude intéressante serait de déterminer la cohérence (ou non) d une théorie exprimée en IF-PLTL.

12 Bibliographie 1. Bacon (J.), Evans (D.), Eyers (D. M.), Migliavacca (M.), Pietzuch (P.) et Shand (B.). Enforcing End-to-End Application Security in the Cloud (Big Ideas Paper). In Proceedings of the ACM/IFIP/USENIX 11th International Conference on Middleware, Middleware 10, Middleware 10, pp , Berlin, Heidelberg, Springer-Verlag. 2. Basin (D.), Klaedtke (F.) et Müller (S.). Policy monitoring in first-order temporal logic. In : Computer Aided Verification, éd. par Touili (T.), Cook (B.) et Jackson (P.), pp Springer Berlin Heidelberg, janvier Blanc (M.), Bousquet (A.), Briffaut (J.), Clevy (L.), Gros (D.), Lefray (A.), Rouzaud-Cornabas (J.), Toinard (C.) et Venelle (B.). Mandatory access protection within cloud systems. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Briffaut (J.), Peres (M.), Rouzaud Cornabas (J.), Solanki (J.), Toinard (C.) et Venelle (B.). PIGA-OS : Retour sur le Système d Exploitation Vainqueur du Défi Sécurité. In 8ème Conférence Française en Systèmes d Exploitation, St Malo, France, Caron (E.), Desprez (F.) et Rouzaud-Cornabas (J.). Smart resource allocation to improve cloud security. In : Security, Privacy and Trust in Cloud Systems, éd. par Nepal (S.) et Pathan (M.), pp Springer Berlin Heidelberg, Clarkson (M. R.) et Schneider (F. B.). Hyperproperties. J. Comput. Secur., vol. 18, n6, septembre 2010, pp Clemente (P.), Rouzaud-Cornabas (J.) et Toinard (C.). From a generic framework for expressing integrity properties to a dynamic mac enforcement for operating systems. In : Transactions on Computational Science XI, éd. par Gavrilova (M.), Tan (C.) et Moreno (E.), pp Springer Berlin Heidelberg, Dimitrova (R.), Finkbeiner (B.), Kovács (M.), Rabe (M. N.) et Seidl (H.). Model checking information flow in reactive systems. In : Verification, Model Checking, and Abstract Interpretation, éd. par Kuncak (V.) et Rybalchenko (A.), pp Springer Berlin Heidelberg, janvier Goguen (J. A.) et Meseguer (J.). Security policies and security models. In IEEE Symposium on Security and privacy, Halpern (J. Y.) et Weissman (V.). Using first-order logic to reason about policies. ACM Trans. Inf. Syst. Secur., vol. 11, n4, juillet 2008, p. 21 :1 21 : Kafura (D.) et Gracanin (D.). An information flow control meta-model. In Proceedings of the 18th ACM Symposium on Access Control Models and Technologies, SACMAT 13, SACMAT 13, p , New York, NY, USA, ACM. 12. Lamport (L.). Specifying concurrent program modules. ACM Trans. Program. Lang. Syst., vol. 5, n2, avril 1983, p Pnueli (A.). The temporal logic of programs. In the 18th Annual Symposium on Foundations of Computer Science, 1977, pp , Rodero-Merino (L.), M. Vaquero (L.), Caron (E.), Desprez (F.) et Muresan (A.). Building safe paas clouds : a survey on security in multitenant software platforms. Computers & Security, vol. 31, 2012, pp Rushby (J.). Security requirements specifications : How and what. In Symposium on Requirements Engineering for Information Security (SREIS), Sandhu (R.), Boppana (R.), Krishnan (R.), Reich (J.), Wolff (T.) et Zachry (J.). Towards a Discipline of Mission-Aware Cloud Computing. In Proceedings of the 2010 ACM workshop on Cloud computing security workshop, pp , 2010.

Analyse abstraite de missions sous PILOT

Analyse abstraite de missions sous PILOT Analyse abstraite de missions sous PILOT Damien Massé EA 3883, Université de Bretagne Occidentale, Brest damien.masse@univ-brest.fr Résumé Nous étudions la possibilité de réaliser un analyseur par interprétation

Plus en détail

Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS)

Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS) Security Properties for the Application Control within a Linux Kernel (SPACLik aka PIGA-OS) Jérémy Briffaut, Martin Peres, Jonathan Rouzaud-Cornabas, Jigar Solanki, Christian Toinard, Benjamin Venelle

Plus en détail

Protection et amélioration de la sécurité des systèmes d'exploitation

Protection et amélioration de la sécurité des systèmes d'exploitation Protection et amélioration de la sécurité des systèmes d'exploitation Jérémy Briffaut ENSI Bourges LIFO Martin Perès Université de Bordeaux LaBRI Jonathan Rouzaud-Cornabas INRIA Rhône Alpes Jigar Solanki

Plus en détail

et Automates de Büchi

et Automates de Büchi Cours 9: Propriétes ω-régulières et Automates de Büchi Francesco Belardinelli Laboratoire IBISC Remerciements à Alessio Lomuscio et Joost-Pieter Katoen 26 mars 2015 Cours 9 - Vue d Ensemble Motivation

Plus en détail

AVATAR. Un profil SysML temps réel outillé

AVATAR. Un profil SysML temps réel outillé AVATAR Un profil SysML temps réel outillé Ludovic Apvrille, Pierre de Saqui-Sannes ludovic.apvrille@telecom-paristech.fr pdss@isae.fr SysML France, 6 décembre 2010 Agenda De TURTLE à AVATAR Le langage

Plus en détail

Vérification Formelle des Aspects de Cohérence d un Workflow net

Vérification Formelle des Aspects de Cohérence d un Workflow net Vérification Formelle des Aspects de Cohérence d un Workflow net Abdallah Missaoui Ecole Nationale d Ingénieurs de Tunis BP. 37 Le Belvédère, 1002 Tunis, Tunisia abdallah.missaoui@enit.rnu.tn Zohra Sbaï

Plus en détail

UPMC Master informatique 2 STL NI503 Conception de langages Notes I

UPMC Master informatique 2 STL NI503 Conception de langages Notes I UPMC Master informatique 2 STL NI503 Conception de langages Notes I 2012 1 Évaluer Un langage Le langage Logo est composé commandes permettant de diriger le déplacement d un point sur un plan cartésien

Plus en détail

Introduction au model-checking et application à la vérification des protocoles cryptographiques

Introduction au model-checking et application à la vérification des protocoles cryptographiques Introduction au model-checking et application à la vérification des protocoles cryptographiques Prof. John MULLINS École Polytechnique de Montréal Prof. John MULLINS (École Polytechnique) Introduction

Plus en détail

Une extension pour RDF/RDFS utilisant des relations procédurales

Une extension pour RDF/RDFS utilisant des relations procédurales Une extension pour RDF/RDFS utilisant des relations procédurales Jean-François Baget * * INRIA Sophia-Antipolis & LIRMM(CNRS - UM2) LIRMM, 161 rue Ada, 34392 Montpellier Cedex 5 baget@lirmm.fr RÉSUMÉ.

Plus en détail

TP10 Modélisation, simulation et vérification du «Priority Inheritance Protocol» en Kind2

TP10 Modélisation, simulation et vérification du «Priority Inheritance Protocol» en Kind2 École normale supérieure Année 2014-2015 Systèmes et réseaux TP10 Modélisation, simulation et vérification du «Priority Inheritance Protocol» en Kind2 1 Plan En suivant l exemple de Jahier, Halbwachs et

Plus en détail

Service combinators for farming virtual machines

Service combinators for farming virtual machines Master d Informatique Fondamentale École Normale Supérieure de Lyon Sémantique du parallélisme Chantal Keller Service combinators for farming virtual machines K. Bhargavan, A. D. Gordon, I. Narasamdya

Plus en détail

Formula Negator, Outil de négation de formule.

Formula Negator, Outil de négation de formule. Formula Negator, Outil de négation de formule. Aymerick Savary 1,2, Mathieu Lassale 1,2, Jean-Louis Lanet 1 et Marc Frappier 2 1 Université de Limoges 2 Université de Sherbrooke Résumé. Cet article présente

Plus en détail

Vérification des systèmes modulaires

Vérification des systèmes modulaires Vérification des systèmes modulaires F. Ouazar Lounnaci M.Ioualalen M.C.Boukala MOVEP, USTHB, Algérie fouazar@gmail.com mioualalen@usthb.dz mboukala@usthb.dz Résumé La vérification des systèmes par model-checking

Plus en détail

Vérification formelle d un modèle mémoire pour le langage C

Vérification formelle d un modèle mémoire pour le langage C Vérification formelle d un modèle mémoire pour le langage C Projet ANR ARA SSIA CompCert (http://compcert.inria.fr) Sandrine Blazy, Xavier Leroy CEDRIC-ENSIIE et INRIA Rocquencourt CEA-LIST, 18 mars 2008

Plus en détail

Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés

Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés Approche dirigée par les modèles pour la spécification, la vérification formelle et la mise en œuvre des services Web composés Christophe Dumez Laboratoire Systèmes et Transports (SeT) Université de Technologie

Plus en détail

INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3

INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3 UNIVERSITÉ LIBRE DE BRUXELLES (corrected version 20120416) INFO-F-302 Informatique Fondamentale Projet : Logique du Premier Ordre et Utilisation de l Outil Z3 L objectif de ce projet est de modéliser des

Plus en détail

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage

Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Programmation orientée domaine pour les services télécoms: Concepts, DSL et outillage Areski Flissi Gilles Vanwormhoudt LIFL/CNRS (UMR 8022) Institut TELECOM 59655 Villeneuve d Ascq 59655 Villeneuve d

Plus en détail

2 Probabilités conditionnelles. Événements indépendants

2 Probabilités conditionnelles. Événements indépendants 2 Probabilités conditionnelles. Événements indépendants 2.1 Probabilité conditionnelle Soient A et B deux événements tels que P(B) > 0. Soit alors P(A B), la probabilité que A se réalise, B étant réalisé.

Plus en détail

Les limites théoriques de l informatique Les problèmes indécidables

Les limites théoriques de l informatique Les problèmes indécidables Les limites théoriques de l informatique Les problèmes indécidables Samuel Fiorini - Gilles Geeraerts - Jean-François Raskin Université Libre de Bruxelles Académie Royale des Sciences Bruxelles 3/3/2010

Plus en détail

Conception des systèmes répartis

Conception 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étail

Sécurité des logiciels et analyse statique

Sécurité des logiciels et analyse statique Sécurité des logiciels et analyse statique David Pichardie Projet Lande, INRIA Rennes - Bretagne Atlantique Introduction générale à l analyse statique Analyse de programme Objet : déduire mécaniquement

Plus en détail

Évaluation et implémentation des langages

É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étail

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services

Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services 69 Vers une approche Adaptative pour la Découverte et la Composition Dynamique des Services M. Bakhouya, J. Gaber et A. Koukam Laboratoire Systèmes et Transports SeT Université de Technologie de Belfort-Montbéliard

Plus en détail

Support du cours de Probabilités IUT d Orléans, Département d informatique

Support du cours de Probabilités IUT d Orléans, Département d informatique Support du cours de Probabilités IUT d Orléans, Département d informatique Pierre Andreoletti IUT d Orléans Laboratoire MAPMO (Bât. de Mathématiques UFR Sciences) - Bureau 126 email: pierre.andreoletti@univ-orleans.fr

Plus en détail

Une proposition d extension de GML pour un modèle générique d intégration de données spatio-temporelles hétérogènes

Une proposition d extension de GML pour un modèle générique d intégration de données spatio-temporelles hétérogènes 303 Schedae, 2007 Prépublication n 46 Fascicule n 2 Une proposition d extension de GML pour un modèle générique d intégration de données spatio-temporelles hétérogènes Samya Sagar, Mohamed Ben Ahmed Laboratoire

Plus en détail

Cours 1 : La compilation

Cours 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étail

Thème 11 Réseaux de Petri Places-Transitions

Thème 11 Réseaux de Petri Places-Transitions Thème 11 Réseaux de Petri Places-Transitions Contenu du thème 1. Introduction 2. RdP PT 3. Protocoles de communication Références Diaz, Michel (2001) Les Réseaux de Petri Modèles fondamentaux, Hermes Science

Plus en détail

Model checking temporisé

Model checking temporisé Model checking temporisé Béatrice Bérard LAMSADE Université Paris-Dauphine & CNRS berard@lamsade.dauphine.fr ETR 07, 5 septembre 2007 1/44 Nécessité de vérifier des systèmes... 2/44 Nécessité de vérifier

Plus en détail

UNIVERSITÉ D ORLÉANS

UNIVERSITÉ D ORLÉANS UNIVERSITÉ D ORLÉANS ÉCOLE DOCTORALE MATHEMATIQUES, INFORMATIQUE, PHYSIQUE THEORIQUE et INGENIERIE DES SYSTEMES LABORATOIRE D INFORMATIQUE FONDAMENTALE D ORLÉANS THÈSE présentée par : Damien GROS soutenue

Plus en détail

ISO/CEI 19770-1. Technologies de l information Gestion des actifs logiciels. Partie 1: Procédés et évaluation progressive de la conformité

ISO/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étail

Logique et bases de données

Logique et bases de données Logique et bases de données Plan Théorie du premier ordre Hypothèses CWA, unique name, domain closure BD comme interprétation BD comme théorie du 1er ordre BD déductives Signification des différentes formes

Plus en détail

Fondements de l informatique: Examen Durée: 3h

Fondements de l informatique: Examen Durée: 3h École polytechnique X2013 INF412 Fondements de l informatique Fondements de l informatique: Examen Durée: 3h Sujet proposé par Olivier Bournez Version 3 (corrigé) L énoncé comporte 4 parties (sections),

Plus en détail

Conditions : stage indemnisé, aide au logement possible, transport CEA en Ile-de-France gratuit.

Conditions : stage indemnisé, aide au logement possible, transport CEA en Ile-de-France gratuit. Proposition de stage de BAC+4 ou BAC+5 Pro ou Recherche Etude comparative des outils de vérification d'algorithmes parallèles Logiciels (LSL), localisé à Palaiseau (Essonne), développe les outils d'aide

Plus en détail

5SINF200 : Développement de programmes (A. Slissenko) Examen

5SINF200 : Développement de programmes (A. Slissenko) Examen Licence Info Corrigé 5SINF200 : Développement de programmes (A. Slissenko) Examen Le 21 décembre 2006, 13h30 15h30 Utilisation des notes, des livres, des docs, etc. autorisée. Ce corrigé contient des réponses

Plus en détail

Vers l automatisation de la construction de systèmes de médiation pour le commerce électronique

Vers l automatisation de la construction de systèmes de médiation pour le commerce électronique Vers l automatisation de la construction de systèmes de médiation pour le commerce électronique I. Introduction C. Reynaud, G. Giraldo Université Paris-Sud, CNRS UMR 8623, INRIA-Futurs L.R.I., Bâtiment

Plus en détail

Chapitre 3. Définitions récursives et induction structurelle

Chapitre 3. Définitions récursives et induction structurelle Chapitre 3 Définitions récursives et induction structurelle 114 Plan 1. Définitions récursives 2. Induction structurelle 3. Exemples Arbres Naturels Expressions arithmétiques Lectures conseillées : I MCS

Plus en détail

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca

Noureddine Kerzazi noureddine.kerzazi@polymtl.ca Domaine de la modélisation des processus pour le génie logiciel. Noureddine Kerzazi noureddine.kerzazi@polymtl.ca DSL4SPM Domain-Specific-Language for Software Process Modeling Il s agit d un nouveau cadre

Plus en détail

Correction de programmes : Logique de Hoare

Correction de programmes : Logique de Hoare 16 juillet 2009 Logique et informatique Vis-à-vis de l informatique la logique a au moins 2 rôles : 1 Externe et théorique (fondements de l informatique - Électif en S4) : Logique comme méta-informatique

Plus en détail

Partie I : Automates et langages

Partie I : Automates et langages 2 Les calculatrices sont interdites. N.B. : Le candidat attachera la plus grande importance à la clarté, à la précision et à la concision de la rédaction. Si un candidat est amené à repérer ce qui peut

Plus en détail

Fiche de TD-TP no. 4

Fiche de TD-TP no. 4 Master 1 Informatique Programmation Fonctionnelle, p. 1 Fiche de TD-TP no. 4 Exercice 1. Voici trois façons différentes de définir le type Image : type Image = [[ Int ]] data Image = Image [[ Int ]] newtype

Plus en détail

Les indices à surplus constant

Les 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étail

Aperçu général sur la technologie des Workflows

Aperçu général sur la technologie des Workflows Aperçu général sur la technologie des Workflows Zakaria Maamar Groupe Interfonctionnement Section Technologie des systèmes d'information Centre de recherches pour la défense Valcartier 2459 boul. Pie-XI

Plus en détail

Espace de probabilité, indépendance et probabilité conditionnelle

Espace de probabilité, indépendance et probabilité conditionnelle Chapter 2 Espace de probabilité, indépendance et probabilité conditionnelle Sommaire 2.1 Tribu et événements........................................... 15 2.2 Probabilité................................................

Plus en détail

Démonstrations. Chapitre 4. 4.1 Introduction

Démonstrations. Chapitre 4. 4.1 Introduction Chapitre 4 Démonstrations L objectif de ce chapitre est de commencer à aborder la question fondamentale suivante : qu est-ce qu une démonstration? Pour cela, plus précisément, on va se focaliser dans ce

Plus en détail

Nom de l application

Nom 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étail

Exclusion Mutuelle. Arnaud Labourel Courriel : arnaud.labourel@lif.univ-mrs.fr. Université de Provence. 9 février 2011

Exclusion 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étail

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence

Université Paris Diderot Master 1 II. Théorie et pratique de la concurrence Université Paris Diderot Master 1 II Théorie et pratique de la concurrence Partiel du 30 avril 2009 Durée : 1h30. Tous les documents sont autorisés. Le barème est indicatif. Question 1 : Soit le programme

Plus en détail

Comment gagner confiance en C?

Comment gagner confiance en C? CHRONIQUE DOI:10.3166/TSI.26.1195-1200 c 2007 Lavoisier, Paris Comment gagner confiance en C? Le langage C est très utilisé dans l industrie, en particulier pour développer du logiciel embarqué. Un des

Plus en détail

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits

Automatisation de la certification formelle de systèmes critiques par instrumentation d interpréteurs abstraits 1 d Automatisation de la certification formelle de systèmes critiques par instrumentation d sous la direction de Michaël Périn Soutenance de Thèse de Doctorat Université de Grenoble - Laboratoire Verimag

Plus en détail

Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005

Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005 Examen CAR 2 Heures Tout documents autorisés le 17 Novembre 2005 Rappel : Tout méta-modèle ou profil doit être commenté! 1 Question de compréhension du cours barème indicatif : 5 points Q : Lorsque l on

Plus en détail

Projet : Plan Assurance Qualité

Projet : Plan Assurance Qualité Projet : Document : Plan Assurance Qualité 2UP_SPEC_DEV1 VERSION 1.00 Objet Ce document a pour objectif de définir la démarche d analyse et de conception objet ainsi les activités liées. Auteur Eric PAPET

Plus en détail

GÉNIE LOGICIEL (SOFTWARE ENGINEERING)

GÉNIE LOGICIEL (SOFTWARE ENGINEERING) GÉNIE LOGICIEL (SOFTWARE ENGINEERING) 5ÈME PARTIE UML (UNIFIED MODELING LANGUAGE) Faculté des Sciences et Techniques http://labh-curien.univ-st-etienne.fr/~fj/gl Francois.Jacquenet@univ-st-etienne.fr Plan

Plus en détail

TSCPN: Timed Secure Colored Petri Net Modélisation et vérification de la sécurité des informations par des réseaux de Petri colorés temporisés

TSCPN: Timed Secure Colored Petri Net Modélisation et vérification de la sécurité des informations par des réseaux de Petri colorés temporisés TSCPN: Timed Secure Colored Petri Net Modélisation et vérification de la sécurité des informations par des réseaux de Petri colorés temporisés Présenté par : Hind Rakkay Dirigé par : Hanifa Boucheneb École

Plus en détail

Systèmes linéaires. 1. Introduction aux systèmes d équations linéaires. Exo7. 1.1. Exemple : deux droites dans le plan

Systèmes linéaires. 1. Introduction aux systèmes d équations linéaires. Exo7. 1.1. Exemple : deux droites dans le plan Exo7 Systèmes linéaires Vidéo partie 1. Introduction aux systèmes d'équations linéaires Vidéo partie 2. Théorie des systèmes linéaires Vidéo partie 3. Résolution par la méthode du pivot de Gauss 1. Introduction

Plus en détail

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet

Conception et Développement Orientés Objets Cours 1 : Introduction. 2 Les paradigmes de programmation. 3 Les concepts de la programmation objet CNAM UV 19357 Année 2003-2004 David Delahaye David.Delahaye@cnam.fr Conception et Développement Orientés Objets Cours 1 : Introduction 1 Présentation de la valeur Ce cours s adresse à toute personne ayant

Plus en détail

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X

Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Groupe Eyrolles, 2001, 2003, 2004, ISBN : 2-212-11480-X Chapitre 6 Exercices corrigés et conseils méthodologiques Mots-clés Activité continue/finie Transition automatique Contexte statique Événements «after»

Plus en détail

ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif

ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif ALEM: Un Modèle de Référence pour les Applications Web Adaptatif Educatif Mohammed TADLAOUI 1, Azzedine CHIKH 2, Karim Bouamrane 1 1 Université d Oran, Algérie, 2 Université de King Saud, Royaume d'arabie

Plus en détail

Élasticité des applications à base de services Samir Tata, Télécom SudParis UMR Samovar Équipe ACMES

Élasticité des applications à base de services Samir Tata, Télécom SudParis UMR Samovar Équipe ACMES Élasticité des applications à base de services Samir Tata, Télécom SudParis UMR Samovar Équipe ACMES Élasticité : Définitions et Concepts Samir Tata, Télécom SudParis Élasticité Définitions Élasticité

Plus en détail

Cas d étude appliqué à l ingénierie logicielle

Cas d étude appliqué à l ingénierie logicielle ypbl : une méthodologie pédagogique pour la professionnalisation d une formation Cas d étude appliqué à l ingénierie logicielle Ernesto Exposito 1,2, Anne Hernandez 2 1 CNRS ; LAAS ; 7 av. du Colonel Roche,

Plus en détail

Élasticité des applications à base de services dans le Cloud

Élasticité des applications à base de services dans le Cloud 1/40 Élasticité des applications à base de services dans le Cloud Mourad Amziani 12 Tarek Melliti 1 Samir Tata 2 1 IBISC, EA4526, Université d'évry Val-d'Essonne, Évry, France 2 UMR CNRS Samovar, Institut

Plus en détail

IFT2255 : Génie logiciel

IFT2255 : Génie logiciel IFT2255 : Génie logiciel Chapitre 6 - Analyse orientée objets Section 1. Introduction à UML Julie Vachon et Houari Sahraoui 6.1. Introduction à UML 1. Vers une approche orientée objet 2. Introduction ti

Plus en détail

3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes

3. SPÉCIFICATIONS DU LOGICIEL. de l'expression des besoins à la conception. Spécifications fonctionnelles Analyse fonctionnelle et méthodes PLAN CYCLE DE VIE D'UN LOGICIEL EXPRESSION DES BESOINS SPÉCIFICATIONS DU LOGICIEL CONCEPTION DU LOGICIEL LA PROGRAMMATION TESTS ET MISE AU POINT DOCUMENTATION CONCLUSION C.Crochepeyre Génie Logiciel Diapason

Plus en détail

Un cours d introduction à la démarche mathématique. Martine De Vleeschouwer, Suzanne Thiry

Un cours d introduction à la démarche mathématique. Martine De Vleeschouwer, Suzanne Thiry Aide à la transition dans une formation universitaire d un mathématicien en Belgique Un cours d introduction à la démarche mathématique Martine De Vleeschouwer, Suzanne Thiry Université de Namur, Unité

Plus en détail

Résolution générique à la volée de systèmes d équations booléennes et applications

Résolution générique à la volée de systèmes d équations booléennes et applications Résolution générique à la volée de systèmes d équations booléennes et applications Radu Mateescu INRIA Rhône-Alpes / VASY Plan Introduction Systèmes d équations booléennes d alternance 1 Algorithmes de

Plus en détail

Cours de logique pour l informatique

Cours de logique pour l informatique Cours de logique pour l informatique Prof. Jean-François Raskin Département d Informatique Faculté des Sciences Université Libre de Bruxelles Année académique 2007-2008 0-0 Organisation pratique du cours

Plus en détail

Cours de Génie Logiciel

Cours 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étail

Analyse de données symboliques et graphe de connaissances d un agent

Analyse de données symboliques et graphe de connaissances d un agent d un agent Philippe Caillou*, Edwin Diday** *LAMSADE - Université Paris Dauphine Place du maréchal de Lattre de Tassigny 7516 Paris caillou@lamsade.dauphine.fr **CEREMADE - Université Paris Dauphine Place

Plus en détail

Outil SANTE: Détection d erreurs par analyse statique et test structurel des programmes C

Outil SANTE: Détection d erreurs par analyse statique et test structurel des programmes C Outil SANTE: Détection d erreurs par analyse statique et test structurel des programmes C Omar Chebaro LIFC, Université de Franche-Comté, 25030 Besançon France CEA, LIST, Laboratoire Sûreté des Logiciels,

Plus en détail

MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B

MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B MODELISATION ET VERIFICATION DE POLITIQUES DE SECURITE A L AIDE DE LA METHODE B Amal HADDAD 1 ère année de thèse INPG LSR VASCO Directeurs : Mme. Marie Laure POTET M. Yves LEDRU Cadre du travail Problématique

Plus en détail

Logiciel Libre Cours 3 Fondements: Génie Logiciel

Logiciel Libre Cours 3 Fondements: Génie Logiciel Logiciel Libre Cours 3 Fondements: Génie Logiciel Stefano Zacchiroli zack@pps.univ-paris-diderot.fr Laboratoire PPS, Université Paris Diderot 2013 2014 URL http://upsilon.cc/zack/teaching/1314/freesoftware/

Plus en détail

Prise en compte d une politique de sécurité pour le déploiement dans le Cloud

Prise en compte d une politique de sécurité pour le déploiement dans le Cloud Prise en compte d une politique de sécurité pour le déploiement dans le Cloud Rencontres : Calcul intensif et Sciences des données Timothée Ravier Doctorant au LIFO (INSA-CVL) et au LIPN (Paris XIII) Vichy,

Plus en détail

Fondamentaux pour les Mathématiques et l Informatique :

Fondamentaux pour les Mathématiques et l Informatique : Université Bordeaux 1 Licence de Sciences, Technologies, Santé Mathématiques, Informatique, Sciences de la Matière et Ingénierie M1MI1002 Fondamentaux pour les Mathématiques et l Informatique Fondamentaux

Plus en détail

Contexte général de l étude

Contexte général de l étude 1 2 Contexte général de l étude Les entrepôts de données associés à des outils d analyse On Line Analytical Processing (OLAP), représentent une solution effective pour l informatique décisionnelle (Immon,

Plus en détail

Les principaux domaines de l informatique

Les principaux domaines de l informatique Les principaux domaines de l informatique... abordés dans le cadre de ce cours: La Programmation Les Systèmes d Exploitation Les Systèmes d Information La Conception d Interfaces Le Calcul Scientifique

Plus en détail

Épreuve d informatique 2011

Épreuve d informatique 2011 A 2011 INFO. MP ÉCOLE NATIONALE DES PONTS ET CHAUSSÉES, ÉCOLES NATIONALES SUPÉRIEURES DE L AÉRONAUTIQUE ET DE L ESPACE, DE TECHNIQUES AVANCÉES, DES TÉLÉCOMMUNICATIONS, DES MINES DE PARIS, DES MINES DE

Plus en détail

λ-calcul et typage Qu est-ce qu une fonction?

λ-calcul et typage Qu est-ce qu une fonction? λ-calcul et typage Nicolas Barnier, Pascal Brisset ENAC Avril 2009 Nicolas Barnier, Pascal Brisset (ENAC) λ-calcul et typage Avril 2009 1 / 1 Qu est-ce qu une fonction? Classiquement Pas de notation uniforme/standard

Plus en détail

6.1 Une classe simple pour représenter des comptes bancaires

6.1 Une classe simple pour représenter des comptes bancaires Chapitre 6 Héritage Ce chapitre du cours traite de concepts relatifs à la programmation objet (hiérarchie de classe, héritage, extension, masquage) et sera illustré par un exemple de représentation de

Plus en détail

SDN / Open Flow dans le projet de recherche de GEANT (GN3+)

SDN / Open Flow dans le projet de recherche de GEANT (GN3+) SDN / Open Flow dans le projet de recherche de GEANT (GN3+) Xavier Jeannin GIP RENATER 23-25, rue Daviel 75013 PARIS Résumé Dans le cadre du projet GN3+ (avril 2013 Mars 2015), parmi la tâche orientée

Plus en détail

Algorithmique - Techniques fondamentales de programmation Exemples en Python (nombreux exercices corrigés) - BTS, DUT informatique

Algorithmique - Techniques fondamentales de programmation Exemples en Python (nombreux exercices corrigés) - BTS, DUT informatique Introduction à l'algorithmique 1. Les fondements de l informatique 13 1.1 Architecture de Von Neumann 13 1.2 La machine de Turing 17 1.3 Représentation interne des instructions et des données 19 1.3.1

Plus en détail

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique

Customisation Rhapsody et Henri BOULOUET DITV/AEEV/EECH. approche méthodologique Customisation Rhapsody et approche méthodologique Retour d expérience sur l implémentation d un langage et profil UML associé 1 Sommaire Principe d un développement méthodologique Evocation d ISR (Ingénierie

Plus en détail

Sélection de variables groupées avec les forêts aléatoires. Application à l analyse des données fonctionnelles multivariées.

Sélection de variables groupées avec les forêts aléatoires. Application à l analyse des données fonctionnelles multivariées. Sélection de variables groupées avec les forêts aléatoires. Application à l analyse des données fonctionnelles multivariées. Baptiste Gregorutti 12, Bertrand Michel 2 & Philippe Saint Pierre 2 1 Safety

Plus en détail

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1

PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 PRINCIPES et METHODES de SPECIFICATION et de CONCEPTION GLOBALE des SYSTEMES INFORMATISES 10/20/02 1 CYCLE de VIE des SYSTEMES INFORMATISES Expression du besoin Développement du «système» Exploitation

Plus en détail

PIGA-Windows : contrôle des flux d information avancés sur les systèmes d exploitation Windows 7

PIGA-Windows : contrôle des flux d information avancés sur les systèmes d exploitation Windows 7 PIGA-Windows : contrôle des flux d information avancés sur les systèmes d exploitation Windows 7 Mathieu Blanc, Damien Gros, Jérémy Briffaut, Christian Toinard To cite this version: Mathieu Blanc, Damien

Plus en détail

Sémantique des Langages de Programmation

Sémantique des Langages de Programmation Sémantique des Langages de Programmation Introduction Stefano Guerrini stefano.guerrini@univ-paris13.fr LIPN - Institut Galilée, Université Paris Nord 13 Sup Galillée Informatique, 1ère année 2009 2010

Plus en détail

Annexe 6. Notions d ordonnancement.

Annexe 6. Notions d ordonnancement. Annexe 6. Notions d ordonnancement. APP3 Optimisation Combinatoire: problèmes sur-contraints et ordonnancement. Mines-Nantes, option GIPAD, 2011-2012. Sophie.Demassey@mines-nantes.fr Résumé Ce document

Plus en détail

Étude en Coq de sémantiques d obfuscations de programmes

Étude en Coq de sémantiques d obfuscations de programmes Étude en Coq de sémantiques d obfuscations de programmes Alix Trieu Rapport de stage de 1ère année du Magistère Informatique et Télécommunications Stage du 03 Juin au 26 Juillet dans l équipe Celtique

Plus en détail

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr

Le langage UML : Les diagrammes de séquence. Lydie du Bousquet Lydie.du-bousquet@imag.fr Le langage UML : Les diagrammes de séquence Lydie du Bousquet Lydie.du-bousquet@imag.fr 1 Modélisation des interactions Les objets d un système ont un comportement Ils interagissent entre eux Dynamique

Plus en détail

Laboratoire 4 Développement d un système intelligent

Laboratoire 4 Développement d un système intelligent DÉPARTEMENT DE GÉNIE LOGICIEL ET DES TI LOG770 - SYSTÈMES INTELLIGENTS ÉTÉ 2012 Laboratoire 4 Développement d un système intelligent 1 Introduction Ce quatrième et dernier laboratoire porte sur le développement

Plus en détail

Compilation. Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP. Sandrine Blazy (d après le cours de François Pottier)

Compilation. Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP. Sandrine Blazy (d après le cours de François Pottier) Compilation Cours n 3: Architecture du compilateur Sélection d instructions: de PP à UPP Sandrine Blazy (d après le cours de François Pottier) - 2 e année 10 novembre 2008 S.Blazy (ENSIIE) Compilation

Plus en détail

M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016

M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016 M3301-2: Méthodologie de la production de logiciels Modélisation et construction des logiciels (C. Attiogbé) Travaux dirigés/pratiques - 2015/2016 encadrés par Christian Attiogbé, Amine Aouadhi Cahier

Plus en détail

Une méthode d apprentissage pour la composition de services web

Une méthode d apprentissage pour la composition de services web Une méthode d apprentissage pour la composition de services web Soufiene Lajmi * Chirine Ghedira ** Khaled Ghedira * * Laboratoire SOIE (ENSI) University of Manouba, Manouba 2010, Tunisia Soufiene.lajmi@ensi.rnu.tn,

Plus en détail

Vérification par model-checking, extension aux systèmes infinis

Vérification par model-checking, extension aux systèmes infinis Vérification par model-checking, extension aux systèmes infinis Sébastien Bardin LSV - CNRS & ENS de Cachan Des programmes fiables? L informatique se répand très vite dans tous les domaines : téléphones,

Plus en détail

INTENTIONS DIDACTIQUES ET MISE EN ŒUVRE DANS DES APPLICATIONS WEB

INTENTIONS DIDACTIQUES ET MISE EN ŒUVRE DANS DES APPLICATIONS WEB Pierre-André Caron (pa.caron@ed.univ-lille1.fr) Xavier Le Pallec (xavier.le-pallec@univ-lille1.fr) Sébastien Sockeel (sebastien.sockeel@univ-lille1.fr) USTL, Laboratoire Trigone, équipe NOCE, 59655 Villeneuve

Plus en détail

NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS

NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS NORME INTERNATIONALE D AUDIT 700 FONDEMENT DE L OPINION ET RAPPORT D AUDIT SUR DES ETATS FINANCIERS Introduction (Applicable aux audits d états financiers pour les périodes ouvertes à compter du 15 décembre

Plus en détail

1. Les fondements de l informatique 13

1. Les fondements de l informatique 13 Introduction à l'algorithmique 1. Les fondements de l informatique 13 1.1 Architecture de Von Neumann 13 1.2 La machine de Turing 17 1.3 Représentation interne des instructions et des données 19 1.3.1

Plus en détail

Manuel d utilisation 26 juin 2011. 1 Tâche à effectuer : écrire un algorithme 2

Manuel 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étail

Spécification du profil UML d assemblage cible EJB (version 1)

Spécification du profil UML d assemblage cible EJB (version 1) Spécification du profil UML d assemblage cible EJB (version 1) Auteur : Projet ACCORD (Assemblage de composants par contrats en environnement ouvert et réparti) Référence : Livrable 2.2 Date : 31 mai 2002

Plus en détail

WildCAT : un cadre générique pour la construction d'applications sensibles au contexte

WildCAT : un cadre générique pour la construction d'applications sensibles au contexte WildCAT : un cadre générique pour la construction d'applications sensibles au contexte Pierre-Charles David France Télécom, Recherche & Développement Réunion Adapt, Paris 2006-04-06 Plan 1 Introduction

Plus en détail

FSAB 1402 - Suggestions de lecture

FSAB 1402 - Suggestions de lecture FSAB 1402 - Suggestions de lecture 2006 Concepts, techniques and models of computer programming Cours 1 - Intro Chapitre 1 (sections 1.1, 1.2, 1.3, pages 1-3) Introduction aux concepts de base Chapitre

Plus en détail

Plan du cours de Programmation logique

Plan du cours de Programmation logique Plan du cours de Programmation logique 1 Introduction 2 3 Igor Stéphan 1/ 64 La logique comme langage de programmation Un langage de programmation logique est défini par : un langage des données Ω; et

Plus en détail