Modélisation d’Environnements Dynamiques

Etudiante : Rafife NHEILI Encadrant : Nicolas LUMINEAU Master2 Recherche 2009/2010

Laboratoire LIRIS Résumé. Face à l’usage de plus en plus fréquent de capteurs et à la démocratisation des terminaux mobiles, l’échange de données dans les environnements dynamiques est un problème d’actualité. Ainsi, de nombreuses applications émergeantes fonctionnent non seulement grâce à un accès à des données stockées dans un SGBD, mais aussi à des flux de données via des services. Le développement de telles applications nécessite une modélisation adaptée des données. Un modèle de données relationnel a été déjà défini avec la notion de relation dynamique étendue (eXtended Dynamic Relation, ou XD-Relation) pour représenter les sources de données. Dans ce travail de recherche, nous proposons un modèle d’Entité/Association étendu pour les environnements dynamiques nommé «schéma XD_E/R » qui intègre les nouvelles représentations adaptées aux environnements dynamiques. De plus nous avons défini les règles de transformation au modèle XD_Relationnel. Nous validons notre approche en illustrant un scenario qui contient non seulement des données « classique » stockées dans un SGBD, mais aussi des flux de données provenant de capteurs, et services mobiles qui fournissent des données.

Mots clés: Modèle conceptuel, environnements dynamique, Entité/association étendue. Abstract. Given the increasing use of common sensors and the democratization of mobile terminals, the exchange of data in dynamic environments is an ongoing issue. Thus, many emerging applications operate not only through access to data stored in a DBMS, but also the flow of data through services. The development of such applications requires a suitable modeling data. A relational data model has already been defined with the notion of relationship dynamic range (eXtended Dynamic Relationship, Relationship or XD) to represent data sources. In this research, we propose an extended model entity / relationship to dynamic environments named "schema XD_E / R" that incorporates new representations adapted to dynamic environments. In addition, we have defined the transformation rules to model XD_Relationnel. We validate our approach by illustrating a scenario that contains not only "classic" data stored in a DBMS, but also the flow of data from sensors, and mobile services that provide data. Key words: Model conceptual, dynamic environments, extended Entity/relationship

2   

REMERCIEMENTS

Avant de commencer ce rapport de stage je tiens à remercier particulièrement mon encadrant de stage M.Nicolas LUMINEAU qui m’a formé et accompagné tout au long de cette expérience avec beaucoup de patience et de pédagogie.

Aussi, je remercie, M.Yann GRIPAY pour ses nombreuses explications du système SOcQ et M.Jean-Marc PETIT le responsable de l’équipe base de donnée du LIRIS.

 

 

 

 

 

 

 

 

3 

 

Table de matières

1  Introduction .............................................................................................. 4 

2  Etat de l’art ............................................................................................... 5 

2.1  Gestion de données en environnement dynamique : ...................... 5 

2.2  Le Framework SoCQ : ........................................................................ 6 

2.3  Les Modèles conceptuels .................................................................. 9 

2.3.1  Modélisation de sources statiques : ......................................... 9 

a)  Le schéma Entité/Association : ..................................................... 9 

b)  MERISE ........................................................................................ 10 

c)  Modélisation orientée objet ....................................................... 11 

d)  Le schéma de flux ........................................................................ 11 

2.3.2  Modélisation de sources dynamiques : .................................. 13 

a)  Le schéma E/A étendu aux objets dynamiques .......................... 13 

b)  La méthode REMORA .................................................................. 13 

3  Proposition .............................................................................................. 14 

3.1  Définitions des composants : .......................................................... 15 

3.2  Règles de Passage de XD_E/A à XD_Relationnel : .......................... 21 

3.3  Optimisation : ................................................................................. 26 

3.4  La répartition : ................................................................................ 27 

4  Conclusion ............................................................................................... 27 

 

 

 

4   

 

 

1 Introduction

Les environnements dynamiques s’avère devenir de plus en plus incontournable dans le paysage des applications actuellement développées. Ceci vient du fait que les ordinateurs personnels, les terminaux mobiles et les capteurs sont largement répandus et occupent maintenant une place importante afin de permettre l’échange et le traitement des données. Nous observons également que la notion d’environnements dynamiques est fortement liée à la notion d’environnements pervasifs[4] où la technologie fait partie de la vie quotidienne et réagit selon le contexte pour faciliter la vie et rendre un monde plus facile[4]. Ce contexte de services et terminaux mobiles posent de nouveaux problèmes par rapport à l’échange des données car il s’agit maintenant de manipuler non seulement des données « classique » stockées dans un SGBD, mais aussi des flux de données provenant de capteurs, et services mobiles qui fournissent des données.

Le projet SoCQ [1] propose une solution pour étendre le modèle relationnel pour construire des environnements dynamiques selon le modèle de données relationnel. L’extension nécessaire du modèle relationnel a permis de définir la notion de relation dynamique étendue (eXtended Dynamic Relation, ou XD-Relation) pour représenter les sources de données. La conception d'un schéma correct est essentielle pour le développement d'une application viable. Dans la mesure où la base de données est le fondement de tout le système, une erreur pendant sa conception est difficilement récupérable par la suite. Pour cette raison, il est intéressant d’avoir un modèle qui contient les notions propres aux environnements dynamiques. « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau)

Dans ce projet, nous proposons un modèle d’Entité/Association étendu pour les environnements dynamiques nommé «schéma XD_E/R » intégrant de nouvelles représentations adaptées au contexte « eXtended Dynamic Relation, ou XD-Relation ». Il est important d’avoir un telle modèle pour pouvoir rendre le système compréhensible et facilité le travail des développeurs d’applications en environnement dynamique. Nous avons choisi d’étendre le schéma Entité/Association qui est simple à comprendre, visuel car constitué de représentations graphiques et expressif. il est suffisamment puissant a se transformer en modèles relationnelles. Nous avons choisi d’évaluer ce modèle adaptés aux données relationnelles afin d’y intégrer les notions liées aux environnements dynamiques en ayant cependant le souci de garder une représentation simple et intuitive.

5 

 

 La suite de ce rapport est organisée de la manière suivante. Dans la section 2, l’état de l’art se focalise sur les notions liées aux relations dynamiques étendues, et ensuite fait un tour d’horizon sur les principaux modèles conceptuels existants. La section 3 porte sur la proposition du modèle XD_E/R en définissant ces différents composants. La section 4 présente les règles de transformation permettant de passer de notre schéma XD_E/R au modèle XD_Relationnel. Enfin, la section 5 conclut et permet de donner quelques perspectives.

2 Etat de l’art

2.1 Gestion de données en environnement dynamique : 

L’évolution technologique permet de disposer de nouveaux terminaux plus mobiles (iPhone), objets communiquant constituant ce qu’on appelle des environnements dynamiques [4].Ces nouvelles technologies qui répondent à de nouveaux besoins, ouvrent des perspectives intéressantes dans le domaine du partage de données. Pour certaines applications, ces terminaux partagent des données d’une manière différente par exemple ; à travers des flux de données provenant de capteurs (on parle alors de données continues) ou bien provenant de services mobiles qui peuvent apparaître ou disparaitre à tout moment. Tous ces services et ces sources de données peuvent potentiellement communiquer ensemble en échangeant des données. Les environnements dynamiques reposent sur des données stockées dans des SGBD Relationnels centralisés ou répartis. Ces données sont issues des communications entre terminaux ou issues de capteurs (caméra, sonde thermique…). Ces capteurs génèrent des données en continue (au fur et à mesure de leur arrivée). On parle alors de schéma infini pour stocker ces flux de données [2]. L’accès des données peut se faire directement au niveau applicatif (dans un contexte homogène) ou via des services [5]. Les principales caractéristiques des environnements dynamiques sont leur évolutivité et leur mobilité. Des systèmes dynamiques sont évolutives car des ressources sont disponibles à certains moments, elles peuvent également apparaître ou disparaître à tout moment [12].Cependant, ce comportement ne doit pas altérer le fonctionnement du système, pour garantir sa robustesse. Par exemple, la disparition (par défaillance ou non) ou l’apparition d’un capteur doit être gérer de manière transparente pour l’application [12].

En plus de leur capacité à fournir ou non, un service et les terminaux peuvent se déplacer, ils peuvent changer éventuellement leur environnement proche (autres sources accessibles). Ce comportement ne doit pas non plus altérer le fonctionnement

6   

du système. Alors l’application doit savoir à chaque moment quels sont les services disponibles.

La conception d’applications dans des environnements dynamiques a besoin de prendre en compte cette évolutivité et la mobilité de l’environnement. D’un point de vue « données », ces comportements ne sont pas considérés dans les Modèle Conceptuel de Données (MCD). La conséquence est qu’il est difficile d’avoir une vision globale de l’application (code et données). Il serait donc intéressant d’avoir une compréhension claire des données et des flux de données ainsi que de leurs origines SGBD et services. Pour cela, on souhaite étendre le modèle conceptuel du schéma Entité/Association pour l’adapter aux environnements dynamiques. Malgré de nombreuses propositions, une compréhension claire des interactions entre les sources de données et de flux de données manque toujours, ce qui constitue un frein majeur pour la définition déclarative des applications dynamiques. Pour réaliser notre proposition, nous nous sommes basés sur le projet SoCQ[1] que nous présentons dans la section suivante.

2.2 Le Framework SoCQ : 

Le projet SoCQ [1] a pour objectif de proposer un Framework permettant de faciliter le développement d'applications dans un environnement dynamique. En adoptant une approche inspirée des bases de données, ce Framework donne une représentation homogène des sources de données hétérogènes de l'environnement. Ces sources de données, qui peuvent être des relations dynamiques, des flux de données ou des services, sont représentées sous forme de tables relationnelles. » Pour illustrer le fonctionnement de SoCQ, on considère un scénario simple de surveillance de températures dans différentes zones. Ce scénario implique les ressources suivantes : des capteurs de température qui fournissent un flux de valeurs de température relevées dans différents lieux, et un service d'envoi de messages instantanés. La traduction de ce scénario pour SoCQ se compose de deux éléments : la description des ressources (catalogue) et la description de l'application (requête). Le catalogue est un ensemble de tables, qui correspondent à des relations (RELATION) ou des flux (STREAM). La description des ressources de ce scénario dans un langage de description de données est la suivante :

CREATE STREAM Temperature (Area CHAR, Temperature REAL) CREATE RELATION Employee (Name STRING (20), Address STRING (50), Messenger SERVICE, Message STRING (20) VIRTUAL, Sent CHAR VIRTUAL) CREATE RELATION Surveillance (Area CHAR, Manager STRING (20), Threshold REAL, Alert Message STRING (20))

7 

 

On remarque un style similaire aux « create table » en SQL classique. Néanmoins, deux notions nouvelles apparaissent : - Les « STREAM » : L’objet ‘Température’ représente le flux de températures provenant des différents capteurs répartis dans l'environnement. Il contient les localisations des capteurs (Area) et les valeurs des températures (Temperature). Contrairement à une relation, les tables de type flux ne stockent pas les données. - Les attributs « VIRTUAL » et « SERVICE » : L’objet ‘Employee’ est une table relationnelle contenant des attributs virtuels. Ces attributs n'auront de valeur attribuée qu'au cours du traitement de la requête. Elle contient les noms des employés (Name), leurs adresses de messagerie (Address), l'identifiant du service de messagerie à utiliser (Messenger), qui est un attribut de type service, et deux attributs virtuels correspondant au message à envoyer (Message) et à la confirmation de l'envoi du message (Sent). Surveillance est une table relationnelle classique dont chaque occurrence décrit une localisation à surveiller (Area), le nom du responsable de la zone (Manager), le seuil de température (Threshold) et le message d'alerte à envoyer (AlertMessage). Dans ce scénario, on souhaite envoyer un message au responsable d'une zone lorsque la température dans celle-ci dépasse un certain seuil. La requête SoCQ permettant de répondre à ce besoin est la suivante :

SELECT Area, Manager, Threshold, Temperature, Sent FROM Temperature T, Surveillance S, Employee E WHERE S.Manager = E.Name AND S.Area = T.Area AND S.Threshold < T.Temperature AND E.Message = S.AlertMessage

SoCQ compare en continu les températures, arrivant sur le flux, avec les seuils enregistrés dans la relation Surveillance. Si les valeurs sont supérieures aux seuils, SoCQ fait appel au service de messagerie pour envoyer le message correspondant. Par ce langage déclaratif de haut niveau, SoCQ permet de faciliter le développement d’applications dynamiques. Regardons de plus prés des X_Relations et des XD_Relations :

1. X-Relation (Extended Relation)

La liste des mails des contacts est modélisée par un schéma de relation étendu «Contact» avec les attributs suivants:

Schema (Contact) = {name, address, text, messenger, sent}, RealSchema (Contact) = {name, address, messenger}, virtualSchema(Contact) = {text, sent}.

8   

«Messenger» est un attribut qui indique à la référence d’un service. ‘text’ et ‘sent’ sont deux attributs virtuels qui indiquent le texte qui va être envoyé et le résultat de l’envoi (vrai ou faux).Il est associé avec un binding pattern (sendMessage,messenger) ou chaque binding pattern spécifie un prototype et un attribut du schéma réel représentant une référence de service. «Contacts» est un XD-Relation, illustré dans Table1, ou ‘*’ indique l’absence de la valeur des attributs virtuels:

Table 1. La XD- Relation de Contacts

RELATION contacts ( name STRING, address STRING, messenger SERVICE, text STRING VIRTUAL, sent BOOLEAN VIRTUAL ) USING BINDING PATTERNS ( sendMessage[messenger] ( address, text ) : ( sent ) );

Les binding patterns sont le lien entre les références de services, les attributs virtuels et les prototypes de fonctionnalité. Un binding pattern est associé à un schéma étendu et définit quel prototype (d’invocation ou d’abonnement) utiliser sur les services pour récupérer des valeurs pour un ou plusieurs attributs virtuels. Il spécifie également quel attribut réel représente les références de services. Les schémas d’entrée et de sortie du prototype indiquent quels sont les attributs de la relation à utiliser comme paramètres d’entrée et de sortie. Les paramètres d’entrée peuvent être des attributs réels ou virtuels, alors que les paramètres de sortie doivent être des attributs virtuels. Un binding pattern prend les caractéristiques du prototype qu’il utilise : il est soit un binding pattern d’invocation, soit un binding pattern d’abonnement. Les binding patterns représentent un moyen potentiel de fournir des valeurs à des attributs virtuels qui peuvent être utilisés par les requêtes pour interagir avec les services.

2. XD-Relation (eXtended Dynamic Relation)

Un schéma de relation dynamique étendue’ XD-Relation’ est un schéma de relation étendue ’X-Relation’ associé à un prédicat infinie(R) qui est Boolean qui est vrai si R

9 

 

est un schéma de relation dynamique étendue infinie, c’est-à-dire représentant un flux de données étendu, et faux si R est un schéma de relation dynamique étendue finie. Alors dans une application d’environnement dynamique toutes les sources de données sont représentables sous forme de XD-relations ou on doit définir les attributs réels, les attributs virtuels, les binding patterns associé au schéma et enfin définir si ce schéma est fini ou infini.

2.3 Les Modèles conceptuels 

Cette section se focalise sur les principaux modèles conceptuels existants. Un modèle conceptuel a pour objectif de faciliter l’interprétation de la sémantique des données et permettre la spécification du résultat de la modélisation à un haut niveau d’abstraction. Notre projet est de construire un modèle pour les environnements dynamiques. Pour cela, nous sommes parti du model Entité/Association (E/A) [9] qui est utilisé universellement pour la conception de bases de données.

2.3.1 Modélisation de sources statiques : 

a) Le schéma Entité/Association :

Un schéma Entité/Association (ou, Entity/Relationship Diagram) permet de représenter la structure logique des bases de données [10].

Un schéma E/A se construit à partir des composants suivants:

1. L’entité (Entity) est un objet qui peut être distinctement identifié : une personne, une compagnie…

2. Association (Relationship) est une mise en relation de deux ou plusieurs entités dans laquelle chacune d’elles joue un rôle spécifique.

3. Les entités et les associations sont caractérisées par des propriétés.

4. La cardinalité spécifie les restrictions sur le nombre d’instances d’une entité pouvant être liée avec une instance d’une autre entité.

Le modèle Entité-association fournit des techniques de représentation sous forme de diagramme d’un schéma conceptuel qui est illustrée à la figure 1.

10   

Fig.1 : exemple d’entités (personne, voiture) et de relations (possède).

Dans ce cas, nous avons deux entités voiture et personne où chacune a ses attributs dont un entre aux est la clé primaire. Entre ces deux entités il y a une relation de possession exprimé par l’association ‘possède’ qui a deux attributs aussi. Sur l’association se met les cardinalités « Chaque personne possède zéro/plusieurs voiture(s), et chaque voiture est possédée par 1/plusieurs personne(s) »

Les contraintes dans un E/A : Il y a des contraintes d’intégrité (CI) obligatoires : identification, cardinalité, attribut obligatoire ou facultatif. (1) Contrainte d’identification: Toute entité ou association doit avoir un identifiant,

il permet de repérer de manière univoque chaque occurrence de ce type. (2) Contrainte de cardinalité(ou de connectivité): elle définit le nombre minimum

et le nombre maximum de participations de chaque occurrence d’entité à une association.

(3) Attribut obligatoire ou facultatif: Un attribut facultatif prend la valeur inexistante s’il n’a pas de sens pour une occurrence d’entité donnée, inconnue si sa valeur n’est pas connue à une date d’observation donnée. Exemple : nom de jeune fille –> cet attribut ne prend une valeur que pour les personnes mariées de sexe féminin.

b) MERISE

La méthode Merise [18] (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise) est une méthode d'analyse, de conception et de réalisation de systèmes d'informations informatisés. Cette méthode a 4 niveaux: i) niveau conceptuel fixe les choix des informations et traitements à manipuler dans le système d’information, il se base surtout sur le modèle E/A, ii) niveau organisationnel pour réaliser les fonctions de l' entreprise décrites dans le premier niveau, iii) niveau logique, qui définit des moyens informatiques à disposition des utilisateurs afin d'effectuer les opérations organisées et iiii) niveau physique représente le résultat informatique.

11 

 

c) Modélisation orientée objet

L’ODMG (Object Data Management Group) [7] définit un langage de définition de l'objet (ODL) comme une syntaxe pour le modèle objet. ODL peut être utilisé pour définir un schéma d'application, le schéma peut ensuite être traduit en des déclarations dans le langage de programmation désiré. C’est le langage standard, ayant une représentation graphique pour spécifier la structure de bases de données orientées objet. Ce modèle a des caractéristiques différentes du E /A: i) La clé primaire est optionnelle, ii) Les méthodes sont associées dans son schéma et iii) Les attributs peuvent être non-atomique (type de structures, collection, array…..)

d) Le schéma de flux

Les Data stream (flux de données) sont des données arrivant sous forme de flux continu et par conséquent non disponibles par accès aléatoire sur disque ou en mémoire [2].Leurs différences avec les bases de données c’est que ce sont des données qui arrivent ‘en ligne’ (en continue) sans de contrôle de l’ordre d’arrivée ni au sein d’un flux ni entre plusieurs flux. La taille des données non bornée et lorsqu’un élément du flux a été traité, il est jeté ou archivé. Data Flow Diagram (DFD) [6] : Les diagrammes de flux de données (DFD) démontrent des relations entre les différentes composantes d'un programme ou système. DFD est une technique importante pour la modélisation des informations de haut niveau d'un système en montrant comment les données d'entrée sont transformées à des résultats de sortie à travers une séquence de transformations fonctionnelles. DFD se compose de quatre éléments principaux: les entités, les processus, les data stores, et des flux de données. Définition des composantes du DFD : DFD se compose de quatre éléments de base qui illustrent comment les flux de données dans un système

12   

Entité : Une entité est la source ou la destination des données. Processus : Le processus est la manipulation ou le travail qui transforme les données, comme effectuer des calculs. En d'autres termes, un processus reçoit des entrées et génère des sorties. Data Store : Un data store est l’endroit où un processus stocke des données, pour une récupération ultérieure par le même ou un autre processus. Les fichiers et les tables sont considérés comme des data store. Flux  de  données : Le flux de données est la circulation des données entre l'entité, le processus, et le data store. Le flux de données dans un DFD est nommé pour décrire la nature des données utilisées. Le flux de données est représenté par une flèche, où cette dernière est annotée avec le nom des données.

Fig.2 : Les quatre composants de DFD

Student et Faculty sont les sources et la destination des informations (les entités), respectivement. Register 1, Exam 2, and Graduate 3 sont les processus dans le système. Par exemple, Graduate 3 obtient les informations Academic Record de la part de Student Record, fait des opérations et obtient les informations Degree/Transcript qui envoie à Student. Student Record est le data store(Fig.3).

Fig.3 : Un exemple DFD pour représenter les composants

13 

 

 

2.3.2 Modélisation de sources dynamiques : 

Ces approches suggèrent d’intégrer dans un même schéma conceptuel la modélisation de la structure et celle du comportement du futur système d’information. Les méthodes REMORA[11], ACM-PCM [14], RML [15], SDM [13], RUBRIC [16] sont des exemples de cette classe. Ces méthodes ont un cadre commun de modélisation des objets: les objets varient dans le temps, ils changent d’état, une ou plusieurs fois successivement. Les objets ont à la fois des propriétés de structure et des propriétés de comportement. La dynamique exprime quand et comment les objets changent d’état.

a) Le schéma E/A étendu aux objets dynamiques

Des recherches sont effectuées surs les environnements dynamiques comme [3] avec l’objectif de :

• Modéliser efficacement des applications complexes dans lesquels les situations peuvent changées.

• Un système de base de données doit pouvoir supporter le changement structurel et comportemental pour les objets individuels ou groupe d’objets et cela durant l’exécution de l’application.

L’approche proposée repose sur le mécanisme de rôle comme une extension des bases de données orientées objet pour soutenir les changements comportementales imprévus pour les objets qui pourrait atteindre de nombreux types en avoir une identité d'un objet unique.

Les opérations possibles consistent alors à i) modifier la hiérarchie des classes en ajoutant et en supprimant des classes de rôle ii) migrer des objets de classes existantes à des classes de rôle nouvelles et iii) modifier la définition du type d'une classe de rôle par l'ajout d'attributs et de nouvelles méthodes.

b) La méthode REMORA

Remora [11] a adopté un modèle sémantique qui permet la représentation des aspects statiques et dynamiques dans le même temps dans le monde réel. Dans Remora les changements d’état d’objets résultent de l’exécution d’opérations.

14   

Fig.4 : Les concepts du modèle sont les suivants: Objet, Événement et l’opération.

On remarque qu’on a trois éléments associés le premier est l’objet qui est un élément concret ou abstrait de l'organisation qui peut être détaillée ou spécifié, comme client, produit, service, fournisseur..Le deuxième est l’opération qui est une action qui peut être exécutée à un moment donné dans l'organisation et qui modifie l'état d'un ou plusieurs objets. Et le troisième est l’événement qui peut avoir lieu à un moment donné et la constatation du changement d'état d'un ou plusieurs objets au moyen d'opérations d'exécution.

3 Proposition 

Le modèle de donnée de l’environnement dynamique (cf section 2.2) a plusieurs éléments dont il doit représenter : Le modèle relationnel à deux parties « schéma réel » qui a des attributs réel et « schéma virtuel » qui a des attributs virtuel. Il est aussi associer avec un ensemble fini de binding patterns. En plus pour chaque schéma on doit définir si le schéma est infinie ou pas, c’est-à-dire représentant un flux de données étendu ou si c’est un schéma de relation dynamique étendue finie. Tous ces nouveaux caractères doivent être représentés dans notre modèle XD_E/R avec de nouvelles formes graphiques.

Dans cette section, nous présentons notre modèle XD_E/R en définissant ses composants et leurs propriétés adaptés à la modélisation d’environnements dynamiques. Ensuite, nous présentons les règles de transformation permettant le passage au modèle XD_Relationnel. Pour bien illustrer on va partir d’un scenario. Pour illustrer notre proposition tout au long des définitions, nous considérons un scénario applicatif dans lequel nous avons un bâtiment constitué de plusieurs pièces où chaque pièce contient des capteurs de température et de fumée, ces pièces sont surveiller à distance par des personnes. Les capteurs sont reliés à des messageries qui envoient un message au surveillant de la pièce quand une alerte est déclenchée en cas de fumée ou si la température dépasse le seuil donné. Dès qu’un surveillant reçoit le message (pour faire une correspondance de méthode) une camera prend la photo de

15 

la pièce. surveiller

3.1 Dé

Dans ce pexemple

Les entité

-entité (n

Ex : L’en

-entité se

Une entiprototypedonnées corresponobligatoir

Ex : L’entempératu«NotifyTpar ces pr

Dans notren entitécapteurs d

Nous considér l’entrée alors

éfinitions de

paragraphe ondu scenario et

és :

ormal) : ident

ntité Pièce qui

rvice

té service rees de fonctioncorrespondannd à une entre que chaque

ntité CapteurTure qui i

Temperature »rototypes il la

re scénario leés services avde fumée, les

érons en plus s chaque perso

es composan

n va définir cht enfin illustre

tique à la défin

représente les

eprésente unennalités, c’est

nt à des protottité regroupa

e entité service

Thermique estimplémente .Alors quand

ance d’abord la

es services quivec leur idencapteurs de p

 

à l’entrer un onne qui a le d

nts : 

haque composaer tous le sché

nition du sché

s identifiant d

e entité de l’t-à-dire qui fotypes d’invoc

ant des donnée doive avoir u

t une entité sela méthode le système a

a requête de d

i fournissent dntifient sont : ersonnes, les

capteur de pedroit d’accès a

ant individuelma du scenari

éma E/A (cf se

de toute les piè

environnemenournit des mécation ou d’abées fournies un identifiant.

ervice qui rep« GetTemp

a besoin des idécouverte de

des informatioLes capteur

messageries e

ersonnes qui pa un badge.

llement en doio.

ection.2.3.1)

èces qu’on va

nt qui impléméthodes ou debonnement. C

par un servi.

présente les caerature » et informations rservices.

ons qui seronts de tempéra

et les cameras

permet de

onnant un

observer.

mente des es flux de ette entité ice. C’est

apteurs de le flux

retournées

t exprimer atures, les .

16   

Nous remnon au mdécouver

En effet,disparaitrdisponibldisponibl

Un opéraUn tel ol’environdésirées. Dans notr

Les assoc

-Associat

Ex : Chaqpersonne

- Associa

Ils associfournies. service. Lpour récudonnées a

La méthol’exécutiosont soit v

Pour expdes sortie

marquons que modèle n’apprte de service.

, dans l’envre a tous mles à chaque les pour tout le

ateur représenopérateur per

nnement pour

re schéma ce

ciations :

tion (normale)

que personne .

ation Méthode

ient une entitéNous imposo

Les associatioupérer les dona récupérées.

ode a certaineon de la méthvirtuels soit ré

rimer ses attres.

certaines propparaissent pas

ironnement dmoments, alor

instant .Aloes entités serv

ntant la décourmet de manen extraire un

sont les entité

) : identique à

a un badge se

e:

é service avecons que l’assons méthode qnnées. L’entit

ement des atthode (attributéels.

ributs l’orien

priétés des ses sur le sché

dynamique, lrs le systèmors le systèmvice [1].

uverte dynaminipuler l’ensen sous-ensemb

és services qui

à la définition

eulement et ch

c une entité nsociation ait lqui exprime uté normale qu

tributs de sorts virtuel) et p

tation de flèc

ervices liées à éma, en parti

les services pe doit savoi

me fait une d

que de servicemble des seble de service

i ont ce caract

du schéma E/

haque badge ap

normal qui coe nom du pro

un prototype dui est associée

rtie qui n’aurpeut avoir de

ches indique s

leur fonctioniculier le pro

peuvent appair quels servdécouverte de

ces est donc nervices dispoes qui font les

tère dynamiqu

/A (cf section.

ppartient a un

ontient ses infototype exécud’invocation (e avec elle co

ont de valeurs attributs d’e

si ils sont des

nnement et cessus de

araitre ou vices sont e services

nécessaire. onibles de fonctions

ue.

. 2.3.1)

ne

formations uté par ce (ponctuel) ontient les

r qu’après entrée qui

entrés ou

17 

Les attribsorties exvaleur qu

La sortie ou plusieu

Ex :

• T

Le Capteuet cela av

• L

Le Capteet cela av

Les attribl’associatd’entrée pun label cl’associat

Ex : Aprèpièce. Leattributs s

buts de sortiesxprime que ceu’après l’exécu

du prototypeurs attributs.

Tous les attrib

ur thermique vec sont protot

La clé primair

eur de personnvec sont protot

buts d’entrés : tion exprime qpeuvent être ncontenant l’atttion.

ès que la perso service Camesuivant :

: La flèche ors informationsution du proto

e est la clé pri

buts de l’entité

fourni la temptype « GetTem

re de l’entité e

ne fourni l’idtype « GetLas

La flèche orieque ces informn’importe queltribut d’entrée

onne reçoit le era est associe

 

rientée de l’ass sont les outp

otype.

imaire de l’en

é sont fournis

pérature de sa mperature »

est fournie par

dentifiant du bstID »

entée de l’entimations sont lels attributs de e doit être asso

message d’ale au prototype

ssociation versputs du prototy

ntité qui les co

par le service

pièce avec la

r le service :

badge de la de

ité contenant les entrées du pn’importe qu

ocié à la flèch

erte une camee « TakePhoto

s l’entité conteype qui auron

ontient qui pe

e :

date de captu

ernière person

les entrées verprototype. Leselles entités, p

he orientée ver

era prend la pho »qui a en ent

enant les nt une

eut être un

urassions

nne arrivée

rs s attributs pour cela rs

hoto de la trée les

18   

Send : la prototype

@mail : lattribut d

-Associat

Ils associfournies. ce service

Les flux s’abonnerd’un capt

Alors l’ade donnéAlors dainstant ta Exemple Les deuxrécupératcapteur « notifyT« GetTem

confirmatione « SendMessa

l’adresse maie l’association

tion Flux (Stre

ient une entitéNous imposo

e.

de données r au service pteur)

ssociation flues. ns le cas d’uant que dure c

de comparaisx prototypes tion d’une valrécupère au

Temperature » mperature ».

n que le messaage » qui aura

l de la personn dispose entr

eam)

é service avecons encore qu

représentent pour les obte

ux représente u

un abonnemencet abonnemen

son entre les pdu schéma a

leur de tempéru fur et a

et peut l’a

age est bien rea une valeur q

nne qui survere les personne

c une entité nue l’association

des données nir (par exem

un prototype

nt, des donnént.

prototypes Méassociés aux rature et abon mesure ladonnée a u

eçu. Send est u’après l’exéc

eille la pièce des et les messa

normal qui con a le nom du

infinies auxqmple, un flux

d’abonnemen

ées peuvent ê

thode et les prservices capt

nnement à un fa températurun moment d

un attribut decution de ce d

détectée. @mageries.

ontient ses infu prototype ex

quels il est pode températu

nt, représenta

être produits

rototypes Fluxteur de tempflux de tempére part l’abdonné par la

e sortie du dernier.

mail est un

formations xécuté par

ossible de ure venant

ant un flux

à chaque

x : pératures : érature. Le bonnement a méthode

19 

On a deuservice :

• T

Ex : Le capturass« NotifyT

• L

Ex : Le Cfur et a m

Les attrib

Attributs

Ex : Les Personne

ux cas différe

Tous les attrib

Capteur thersions au fur Temperature »

La clé primair

Capteur de pemesure « GetID

buts :

normal : iden

attributs Nom

ents selon les

buts de l’entité

rmique fournet a mesur

»

re de l’entité e

rsonne fournDBadge »

ntique à la défi

m et @mail no

 

s attributs de

é sont fournis

ni la tempérare et cela a

est fournie par

ni l’identifiant

finition du sch

ous donne des

l’entité norm

par le service

ature de sa pavec sont pr

r le service :

t du badge de

éma E/A (cf s

s informations

male associée

e :

pièce avec larototype d’ab

s personnes a

section.2.3.1)

s nécessaire s

à l’entité

a date de bonnement

arrivées au

sur l’entité

20   

Attributs

Comme un/des attsont les c

Ex : La « GetIDB

Attributs

Comme attribut(s)

Ex :Send

Après avXD_E/R

de sortie :

c’est expliqutribut(s) en so

clés primaires

clé primaire Badge »

d’entrées :

c’est expliqu) d’entrées qu

et @mail son

voir définir tdu système :

er pour les aortie qui va avdes entités no

IDBadge et

er pour les aui sont indique

nt les attribut d

ous les comp

associations mvoir une valeurormal associée

la sortie de

associations mer sue la flèche

d’entrée du pr

posants on p

méthode et flur après leurs ees aux entités

es deux proto

méthode les pe entrante dan

rototype « Tak

peut maintena

ux les prototexécution. C’eservice

otypes « GetL

prototypes ons le service.

kePhoto »

ant illustrer l

types ont est attribut

LastID »et

ont un/des

le schéma

21 

 

3.2 Règles de Passage de XD_E/A à XD_Relationnel : 

Passage du schéma Entité/Association au Relation [8] :

Afin de définir les règles du passage de XD_E/R a XD_Relationnel nous allons faire un rappel du passage d’un schéma Entité/Association à un Schéma Relationnel

Règle 1 : Toute entité du schéma entité-association est traduite en une relation (table) dont la clé primaire et les attributs proviennent de l'entité. Et Toute classe d’association est transformée en relation. Règle 2 : Traduction des associations qui ont une cardinalité égale à 0,1 ou 1,1 pour une entité E est traduite par une clé étrangère ajoutée à la relation R, traduction de E. Cette clef étrangère est la clef primaire de l'entité associée. Règle 3: Traduction des associations de type N à N une association dont toutes les cardinalités maximum sont égales à n est traduite en une relation (table) dont la clé primaire est constituée de l'ensemble des identifiants des entités qui y participent.

-

RVUN)S -s

-

22   

Les règleen plus d

Règl

-L’association

• Ll

• L• L

c

Ex :

RELATION VIRTUAL,daUSING BINDNotifyTemp) STREAM Pré

- La méthodesorties de la m

Règl

- L’associatio

• Ll

• L• L

c• L

v

es du passage de nouvelles rè

le 1 :

n est un flux:

L’entité servicl’entité associL’entité qui coLe prototype ces attributs d

Capteurthate Time VDING PATTEperature

élèvementT

e de l’associaméthode sont d

le 2:

n est une méth

L’entité servicl’entité associL’entité qui coLe prototype ces attributs dLes inputs du vers l’associa

de XD_E/R a ègles :

ce aura sa clé iée seront des ontient les infest associé au

de sortie sont l

hermique VIRTUAL )ERN ( [IdCapte

Temp (Val

ation est un Bdes attributs V

hode:

ce aura sa clé iée seront des ontient les infest associé au

de sortie sont lprototype sontion

XD_Relation

primaire de tyattributs virtu

formations esu service est nola clé primaire

( IdCapte

ur ] () :

eur REAL,

BINDING PAVIRTUEL a ce

primaire de tyattributs virtu

formations esu service est nola clé primairent les attributs

nnel contient l

ype SERVICEuels st traduite en Sommer au nome de l’entité no

ur SERVIC

(Valeur,

Date TIME

ATTERN a l’eette entité SER

ype SERVICEuels st traduite en Rommer au nome de l’entité nos indiqués sur

es règles préc

E et la clé prim

STREAM. m de l’associaormal.

E , Valeu

date )

)

entité SERVIRVICE.

E et la clé prim

RELATION. m de l’associaormal. les flèches or

cédentes et

maire de

ation et

ur REAL

ICE et les

maire de

ation et

ientées

RBUG)R

RVUS)RVUT)RR

R R

23 

Ex : proto

RELATION Boolean VUSING BINDGetFumée ) RELATION

Ex : proto

RELATION MVIRTUAL,senUSING BINDISendMessage) RELATION CVIRTUAL, PhUSING BINDITakePhoto ) Relation PeRelation Co

RELATION M

RELATION R

otype avec de

DetecteutVIRTUAL) DING PATTE[IdDetect

Fumée (Fu

otype avec de

Messenger (nd Boolean ING PATTERNe [IdMesse

Camera ( Idhoto Image ING PATTERN[IdCamera]

ersonne(Nomontact (Nom

Message (te

Result(Send

s attributs de

tFumée (

ERN ( teur] ()

umée Bool

s attributs de

( IdMessenVIRTUAL)

N ( enger] (te

dCamera SEVIRTUAL,D

N ( ] (send,@m

m String) m String,

ext String

d Boolean,

 

sorties

IdDetecte

: (Fumée)

ean)

sorties et d’en

ger SERVIC

xt,@mail)

RVICE,@maiate Time V

ail) : (ph

IdMessenge

,@mail Str

date Time)

ur SERVIC

ntrées

E,@mail St

: (send,da

l String,sVIRTUAL)

oto,date)

r SERVICE,

ing)

E , Fumée

ring, text

te)

end Boolea

@mail Stri

t String

an

ng)

R

-

L

E

RR

-

E

RVUG) RR

24   

RELATION P

Règl

- L’associatio

L’association

Ex :

RELATION PeRELATION P

Règl

- L’associatio

• L’assconst

Ex :

RELATION DVIRTUAL) USING BINDIGetFumée [)

RELATION PRELATION Ré

Photo(Photo

le 3:

n est une relat

est traduite p

ersonne( NoPièce(IdPiè

le 4:

n est une relat

sociation est ttituée de l'ens

DetecteutFu

ING PATTERN[IdDetecteu

Pièce( IdPiécupèreFumé

o Image,Da

tion normale q

ar une clé étr

om STRING,èce INTEGE

tion normale q

traduite en unesemble des ide

umée ( IdD

N ( ur] () : (

ièce INTEGé (IdDetec

te Time)

qui a une card

rangère ajouté

@mail STRR,superfic

qui a une card

e nouvelle relaentifiants des e

etecteur S

Fumée)

ER, superfteur SERVI

dinalité égale à

e à l’autre ent

RING, IdPièie REAL)

dinalité égale à

ation dont la centités qui y p

ERVICE , F

icie REAL)CE, IdPièc

à 1 to many:

tité.

ce INTEGER

à many to man

clé primaire esparticipent.

Fumée Boole

e INTEGER)

R)

ny:

st

ean

25 

 

En appliquant ces règles sur notre schéma XD_E/R on obtient les relations suivantes :

RELATION Personne(

Nom STRING

IdPièce INTEGER

IDBadge INTEGER

) RELATION Pièce( IdPièce INTEGER superficie REAL ) RELATION Capteurthermique ( IdCapteur SERVICE IdPièce INTEGER Valeur REAL VIRTUAL Date Time VIRTUAL )USING BINDING PATTERN ( GetTemperature[IdCapteur ] () : (Valeur,date ) NotifyTemperature [IdCapteur ] () : (Valeur,date ) ) STREAM PrélèvementTemp( Valeur REAL Date TIME ) RELATION DetecteurFumée ( IdDetecteur SERVICE Fumée BOOLEAN VIRTUAL )USING BINDING PATTERN ( Get Fumée [IdDetecteur ] (): (Fumée ) ) RELATION Fumée ( Fumée BOOLEAN ) RELATION RécupèreFumée( IdDetecteur SERVICE IdPièce INTEGER ) STREAM Badge( IDBadge INTEGER DateCreation TIME)

RELATION Capteurthermique ( IdCapteurP SERVICE IDBadge INTEGER VIRTUAL )USING BINDING PATTERN ( GetLastID[IdCapteurP] () : (IDBadge) GetIDBadge [IdCapteurP] () : (IDBadge) ) RELATION Messenger ( IdMessenger SERVICE @mail String text String VIRTUAL send Boolean VIRTUAL ) USING BINDING PATTERN ( SendMessage [IdMessenger] (text,@mail) : (send,date) ) RELATION Camera ( IdCamera SERVICE @mail String send Boolean VIRTUAL Photo Image VIRTUAL Date Time VIRTUAL ) USING BINDING PATTERN ( TakePhoto [IdCamera] (send,@mail) : (photo,date) ) Relation Contact ( Nom String IdMessenger SERVICE @mail String ) RELATION Message ( text String @mail String ) RELATION Result( Send Boolean date Time ) RELATION Photo( Photo Image Date Time )

RVUG)RR

26   

3.3 O

Après le relation c(on peut dces tables

Ex : Aprè

RELATION DVIRTUAL ) USING BINDIGet Fumée ) RELATION FRELATION Ré

L’attribut« Fumée l’optimisa

En applisuivantes

RELATIOFumée ) RelatioNom StrIdMesse@mail S

RELATIOtext St@mail S)

ptimisation 

passage et acontient que ddire aussi les s pour ne pas a

ès l’applicatio

DetecteurFu

ING PATTERN[IdDetecte

Fumée (FuméécupèreFumé

t fumée est le», en plus la ration on suppr

iquant l’optims :

ON Fumée (BOOLEAN

on Contact ring enger SERVIString

ON Messagetring String

: 

afin d’avoir des attributs quattributs qui savoir la répéti

on des règles o

umée (IdDe

N ( eur ] ():

ée BOOLEANée(IdDetec

e même attribrelation « Fumrime la relatio

misation sur

(

(

ICE

e (

de bonne tabui sont des attrsont des outpuition des valeu

on a eu ces tro

tecteur SE

(Fumée )

) teur SERVI

but dans les mée »n’as pason « Fumée ».

toutes les r

RELASenddate) RELAPhotDate)

ble on fait l’oributs virtuelsuts de bindingurs d’attributs

ois tables :

RVICE, Fum

CE,IdPièce

deux relations d’autre attrib

relations on

ATION Resud Boolean e Time

ATION Photto Image e Time

optimisation qs dans des XDg patterns) on dans deux tab

mée BOOLEA

INTEGER)

ns « Detecteurbuts alors en a

supprime les

ult(

to(

quand une D_Relation n supprime bles.

AN

rfumée »et appliquant

relations

27 

 

3.4 La répartition : 

Les XD_Relations et les tables relationnelles peuvent être reparties physiquement sur plusieurs sites connectés par un réseau. Pour faciliter le déploiement d'application il est intéressant de faire apparaître cette répartition sur le schéma XD-E/R en regroupant les entités et associations selon leur destination. Il est cependant important de ne pas séparer le service des informations qu’il fournit.

Par exemple dans notre scénario, il y a plusieurs services et chacun est responsable de capturer un type d’informations alors on ne peut pas séparer le service et ses informations.

4 Conclusion 

Dans ce projet nous avons proposé un schémaEntité/Association étendu pour les environnements dynamiques nommé «schéma XD_E/R » qui intègre les nouvelles représentations adaptées au contexte « eXtended Dynamic Relation, ou XD-Relation ». Pour cela, XD_E/R est basé sur le modèle E/A et en plus prend quelques priorités d’autre modèle comme DFD où il montre la direction des données et des modèles orientés objet où les méthodes sont associées dans son schéma. Nous avons défini de nouveaux composants (entité service qui représente les services de l’environnement, association flux qui représente les prototypes d’abonnement pour

28   

les services qui fournissent des flux de données, association méthode qui représente les méthodes d’invocation fait par les services). Nous avons également définit le mode de représentation des entrées et des sorties des prototypes dans notre modèle. Comme la finalité d’un modèle conceptuel est l’implantation concrète des sources de données et des flux de données, nous avons défini les règles de transformation permettant le passage de notre schéma XD_E/R à la définition implantable des XD_Relation. En perspective de ce travail, il serait intéressant d’un point de vue pratique, d’enrichir un atelier de modélisation relationnel (par exemple ERmodeler [17]) de nos composant ainsi que des règles de transformation afin d’automatiser le processus. D’un point de vue théorique, il serait intéressant de s’intéresser à la modélisation des contraintes d’intégrité.

References

[1]  Yann  GRIPAY:  A  Declarative  approach  for  pervasive  environments:  model  and implementation, thèse en 2009

[2] Brian Babcock, Shivnath Babu, Mayur Datar, Rajeev Motwani, JenniferWidom : Models and Issues  in Data Stream Systems, Proceedings of the 21st ACM Symposium on Principles of Database Systems, 2002. 

[3]M.P. Papazoglou, B.J. Kramer: A database model for object dynamics, Springer‐Verlag New York, 1997 

[4]  D.  Saha,  A.  Mukherjee:  Pervasive  Computing:  A  Paradigm  for  the  21st  Century.  IEEE Computer Society, 2003  

[5] Anthony HOCK‐KOON, Mourad OUSSALAH : Composition Dynamique de Services dans  les Environnements d'Intelligence Ambiante , COSMAL‐Participation , 2009 

[6]Document technique, Understanding Data Flow Diagrams Donald (Donn) S. Le Vie, Jr. 

[7] R. G. G. Cattell :Object Databases and Standards, Springer Berlin / Heidelberg,1995 

[8] Georges GARDARIN, livres CONCEPTION DES BASES DE DONNÉES, Groupe Eyrolles , 2003  [9]Peter  PIN‐Shan  CHEN  ,The  Entity‐Relationship  Model‐Toward  a  Unfied  View  of  Data, Association for Computing Machinery, 1976.  [10] André Flory et Colette Rolland :LA CONCEPTION DES SYSTÈMES D’INFORMATION : ÉTAT  DE  L’ART  ET  NOUVELLES  PERSPECTIVES,  Nouvelles  perspectives  des  systèmes  d’information,  sélection  d’articles  du  congrès  90  de  l’Association  informatique  des organisations et systèmes d’information et de décision, Paris, 1990  [11]  Stig  C  Holmberg  (Ed):The  REMORA  Methodology  for  Information  System  Design disponible à l’adresse : http://systeminformatik.se/isd/sumREMORA.pdf 

29 

 

 [12]  Yann  Gripay,  Frédérique  Laforest,  Jean‐Marc  Petit,  Liya  Zeng:  Management  of  Data Sources and Services in Pervasive Environments, ACM,2008  [13]Michael Hammer,Dennis McLeod: Database Description with SDM: A Semantic Databases model,1981.  [14] Brodie, M.L., Silva, E.: Active and Passive Component Modelling : ACM/PCM in Olle (1982)  [15] Borgiba, A., Greenspan, S., Mylopoulos, J.: Knowledge Representation as the Basis for Requirements Specifications, IEEE Computer, 1985  [16] Van Assche, F., et al: RUBRIC, Esprit Project 928, Final Report, 1989 

[17] http://ermodeller.tigris.org/ 

[18] Michel DIVINÉ, PARLEZ‐VOUS MERISE ?, livre ,1989