FACULTE DES SCIENCES DEPARTEMENT INFORMATIQUE …La présente thèse s ˇinscrit dans le cadre d ˇune problématique plus large qui fait l ˇobjet d ˇun projet de recherche intitulé

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE MINISTERE DE L'ENSEIGNEMENT SUPERIEUR

ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSITE D'ORAN, ES-SENIA

FACULTE DES SCIENCES DEPARTEMENT INFORMATIQUE

MEMOIRE

Présenté par

Mr ABED BAHTOU Bouazza

Pour obtenir

LE DIPLOME DE MAGISTER

Spécialité : C.A.O / I.A.O

Intitulé:

Soutenu le : 20/02/2008 à la salle de conférences de la faculté des Sciences.

Devant les membres du jury:

Président Mr H. HAFFAF Professeur, Université d'Oran Es-Sénia Encadreur Mr M.K RAHMOUNI Professeur, Université d'Oran Es-Sénia Examinateur Mr A. TEMAR Professeur, Institut de Télécommunication d'Oran (ITO) Examinateur Mr M.K. ABDI Maître Conférence, Université d'Oran Es-Sénia Examinateur Mr K. BOUAZZA Docteur, Chargé de cours, Université d'Oran Es-Sénia

L’APPROCHE BOND-GRAPH ET LA MODELISATION DES SYSTEMES D’INFORMATION : NOUVELLE APPROCHE

ORIENTEE COMMUNICATION

http://www.pdfcomplete.com/cms/hppl/tabid/108/Default.aspx?r=q8b3uige22


REMERCIEMENTS Cette thèse est le fruit de beaucoup d’années d’efforts et de persévérances. Elle n’aurait

certainement jamais vu le jour si je n’avais pas bénéficié des conseils avisés, du soutien,

des discussions enrichissantes et de l’aide continue d’un grand nombre de personnes.

Toute ma reconnaissance s’adresse à mon directeur de recherche, Monsieur M.K Rahmouni, qui

grâce à son encadrement, ses précieux conseils, sa disponibilité et ses encouragements, j’ai pu

mener à bien ce modeste travail. Qu’il trouve l’expression de ma profonde gratitude pour son

soutien constant.

Je remercie tout particulièrement Monsieur H. Haffaf, Professeur à l’université Es-Senia d’Oran de

m’avoir fait l’honneur de présider le jury. Malgré ses multiples occupations, il est toujours prêt à

rendre service aux préoccupations scientifiques de l’institut.

Je tiens à exprimer mes sincères remerciements à Monsieur A. Temar, Professeur à l’Institut de

Télécommunication d’Oran (ITO), pour l’intérêt manifeste qu’il a accordé au sujet et pour avoir

accepter de juger ce travail.

Je suis très honoré que Monsieur K. Bouazza, docteur chargé de cours à l’université Es-Senia

d’Oran, ait accepté de juger ce travail.

Je remercie vivement Monsieur M.K Abdi, maître de conférence à l’université Es-Senia d’Oran,

pour avoir accepter de juger ce travail en me faisant l’honneur d’être membre de ce jury.

Enfin, je remercie également tous mes collègues de l’institut d’informatique de l’université Es-

Sénia d’Oran, en particulier l’équipe de Systèmes d’information. Je ne voudrais pas terminer sans

mentionner l’apport de ma mère et ma petite famille qui je réserve bien évidemment d’autres

formes de remerciements.

Que tous ceux de loin ou de prés qui ont collaboré à la progression de ce travail trouvent ici

l’expression de ma profonde reconnaissance.

ABED BAHTOU Bouazza


RESUME

Actuellement beaucoup de systèmes sont caractérisés comme étant des systèmes d’information modélisant différentes organisations. Pour de tels systèmes beaucoup de modèles ont été proposés, mais malheureusement aucun d’eux n’a apporté toutes les exigences pour la spécification de tels systèmes telles que : intégration des données et traitements, sémantique claire et précise, pouvoir de validation et vérification avant toute implémentation, etc. ... . Dans cette thèse, nous montrons que les bond-graphs qui représentent à l’heure actuelle la méthologie de modélisation la plus élaborée en ce qui concerne les systèmes physiques et dynamiques, peuvent être adaptés pour la spécification des systèmes d’information. Cela demande en premier lieu un travail de traduction des concepts Bond-Graphs en leurs correspondants dans les systèmes d’information. En effet, en basant sur le concept d’objet, la méthode Bond-Graph n’est en sorte qu’une extension des méthodes Orientées-objets, avec cependant un certain nombre de différences. Tout d’abord les objets Bonds-Graph sont typés et possèdent un rôle évolutif, ensuite la communication entre les objet ne se fait plus par envoi de messages (communication bilatérale) mais par envoi d’information qui peut prendre ses deux formes duales : le type donnée ou le type traitement (communication à travers le réseau). De ces points, on peut remarqué que le schéma conceptuel dans les Bonds-Graph est plus riche que celle dans l’orientées-objet . Pour cette raison, on a consacré une grande partie de ce rapport à présenter les principaux concepts des méthodologies Orientées-Objet.

MOTS-CLES Conception, Simulation, Interaction, Bonds-Graph, Spécification, Systèmes, Effort, Flux, Dualité, Jonction, Communication. ABSTRACT Many current systems are characterised as information systems that model different organisations. Many models have been proposed for this kind of systems, but unfortunatily none of them has satisfied the specification of this category of systems : integration of data and methods, precise semantics, requirements validation power and verification prior to implementation, etc ... In this thesis, we will prove that Bonds graphs which currently represent the most advanced modelling method for physical and dynamical systems can be adapted for the specification of information systems. The first step will be the traduction of the concepts bonds graphs into the corresponding concepts in information systems. In effect, The bond-graphs method is an extension of oriented-object method with somme diffrences. However, first of all the bond graphs objects are typed and pasess an evolutive role, next the communication (interactions) between the objects is not achieved by the sending messages but by the sending of information which can take two dual forms : the Data Type or the Treatement Type. KEY WORDS Design, Simulation, Interaction, Bonds Graphs, Specification, Systemes, Effort, Flow, Duality, Junction, Communication.


Sommaire

SOMMAIRE

Pages INTRODUCTION GENERALE ………………………………………………… 1

CHAPITRE I

LES SYSTEMES D’INFORMATION : ETAT DE L’ART ET PROBLEMATIQUES I.1 INTRODUCTION …………………………………………………………… 4 I.2 ETAT DE L’ART ……………………………………………………………. 5 I.2.1 Les systèmes d’information et leur modélisation ……………………………... 5 I.2.2 La méthode de conception …………………..………………………………… 7 I.2.2.1 Les Modèles …………………..………………………………………… 8 I.2.2.2 Les Langages …………………..……………………………………….. 8 I.2.2.3 Les Démarches ……………..…………………………………………… 9 I.2.2.4 Les Outils ………………..……………………………………………… 9 I.2.3 Les différentes Classes de Méthodes de Modélisation...…………………….…… 10 I.2.3.1 La classe des méthodes cartésiennes...……………………………………. 10 I.2.3.2 La classe des méthodes systémiques .……………………………………. 11 I.2.3.3 La classe des méthodes orientées-objet .…………………………………. 12 I.3 PROBLEMATIQUE ……………………………………………………………12 I.4 CONCLUSION …………………………………………………………………13

CHAPITRE II

LES METHODES ORIENTEES-OBJETS : MODELES UMLS II.1 INTRODUCTION …………………………………………………………… 14 II.2 MODELES UML …………………………………………………………… 14 II.2.1 Diagramme de cas d’utilisation (vue fonctionnelle)……..………………..… 15 II.2.1.1 Les cas d’utilisation ..………………..……..……………………….. 15 II.2.1.2 Liens entre cas d’utilisation : « include » et « extend ».……….……. 16 II.2.2 Diagramme de classes (vue structurelle) ……………………………………. 18 II.2.2.1 Spécification des digrammes de classes………..……………………... 19 II.2.3 Diagramme de séquence (vue fonctionnelle) ………………………………….23


Sommaire II.2.4 Diagramme d’états (vue dynamique) …………………………………………. 24 II.3 CONCLUSION ……………………………………………………………… 25

CHAPITRE III

BOND-GRAPHS ET SYSTEMES PHYSIQUES III.1 INTRODUCTION …………………………………………………………… 27 III.2 PRESENTATION DU LANGAGE BOND-GRAPH………………..……… 27 III.2.1 Définitions ….………………………………………….……..……………… 27 III.2.2 Représentation des transferts de puissance…..………………………………. 28 III.2.3 Variables mises en jeu ……………….……………………………………… 28 III.2.3.1 Variables de puissances (variables conjuguées)……………………. 28 III.2.3.2 Variables d’énergie (variables généralisées).……………………….. 30 III.2.4 Les éléments Bond-graph….………….……………………………………… 30 III.2.4.1 Des éléments actifs (les sources) …………………………….. 30 III.2.4.2 Des éléments passifs …………………………………………. 31 III.2.4.3 Des éléments de jonctions ……………….…………………… 31 III.3 NOTION DE CAUSALITE …………………………………………..……… 33 III.4 CONCLUSION ……………………………………………………………… 36

CHAPITRE IV

BOND-GRAPHS ET LES LANGAGES DE SIMULATION O.O IV.1. INTROUCTION ……………………………………………………………. 37 IV.2. PRESENTATION DU LANGAGE MODELICA…………………………... 37 IV.2.1 Modélica et l’orienté-objet …………………………………………………. 38 IV.2.2 Modèles mathématiques orientés-objet …………………………………….. 38 IV.2.3 Vue d’ensemble de modélica ………………………………………………. 39 IV.2.3.1 Exemple de modélisation d’un circuit électrique ………………… 39 IV.2.3.2 Librairie de classes ……………………………………………….. 40 IV.2.3.3 Classe Connector ….……………………………………………… 41 IV.2.3.4 Classes virtuelles (Partielles) …………………………………….. 41 IV.2.3.5 Modélisation acausale ……………………………………………. 41 IV.2.3.6 Héritage, paramètres et constantes ……………………………….. 42


Sommaire IV.2.3.7 Le temps et les modèles dynamiques ……………………………... 42 IV.2.3.8 Fonctions …………………………………………………………. 43 IV.2.3.9 Notions de sous-typages dans Modélica …………………………. 43 IV.3. BOND-GRAPHS ET MODELICA …………………………………………. 43 IV.4 CONCLUSION ………………………………………………………………. 47

CHAPITRE V

BOND-GRAPHS ET LES SYSTEMES D’INFORMATION : B.G.S.I V.1. INTROUCTION …………………………………………………………….. 48 V.2. PRINCIPES ET CONCEPTS ……………………………………………….. 48 V.2.1 Principes ……………………………………………………………………… 48 V.2.2 Concepts ……………………………………………………………………… 49 V.2.3 Structures objets Bond-graphs ..……………………………………………… 52 V.2.3.1 Structures des variables duales (effort et flux) …….………………… 52 V.2.3.2 Structures des élements …………………….…….………………….. 52 V.2.3.2.1 Objet de dissipation d’information …….…………………… 53 V.2.3.2.2 Objet de transformation TF ……..…….……………………. 53 V.2.3.2.3 Objet Gyrateur GY ……………..…….…………………….. 54 V.2.3.2.4 Elément C ………………….…..…….…………………….. 55 V.2.3.2.5 Elément I ………………….…..…….……………………… 55 V.2.3.3 Structures de jonction .…………………….…….…………………… 55 V.2.3.3.1 Jonction 0 (parallèle) ……………….………………………. 55 V.2.3.3.2 Jonction 1 (série) ……..……..…….…………………………56 V.3. DEFINITION DU MODELE BOND-GRAPH ……………………………… 58 V.3.1 Démarche……………………………………………………………………… 58 V.3.2 Définition du diagramme de classe …………………………………………… 58 V.4. EXMEPLE D’APPLICATION ……….……………………………………… 60 V.5. AVANTAGES ET LIMITES ..…….…………………………………………. 65 V.6. TABLEAU COMPARATIF ENTRE UML ET BGSI ………….……………. 66 V.7 CONCLUSION ………………………………………………………………. 68


Sommaire CONCLUSION GENERALE ET PERSPECTIVES ……………………………… 69 BIBLIOGRAPHIE ………………….……………………………………………… 71


Introduction Générale 1 SECTION A : CONTEXTE DE L’ETUDE La conception des systèmes d’information est un problème qui se pose lors de

toute tentative de création d’une entité abstraite devant décrire la structure ou le

fonctionnement d’une certaine partie du monde réel qui nous entoure.

La prise de conscience générale de l’importance de la modélisation d’un système

d’information (SI) en tant qu’élément stratégique dans la vie de l’entreprise, a

provoqué l’apparition d’un grand nombre de méthodologies de conception de SI dans

une optique de rationalisation [Ghom 95].

Il est largement reconnu que la conception des systèmes d’information est une

activité de modélisation qui a comme but d’extraire la sémantique du système étudié,

de représenter ses invariants dans un langage formel spécialisé, qui autorisera ensuite

son étude abstraite et peut-être, en cas d’exécutabilité du modèle, sa simulation

[HUE 89].

La plupart des méthodologies actuelles ont permis tant bien que mal de résoudre

partiellement les problèmes de modélisation et de représentation des différents

systèmes. L’analyse des méthodologies de conception traditionnelles montre qu’elles

ont tendance à emprunter des approches spécifiques et à mettre l’accent sur des aspects

différents. Les méthodologies centrées sur la spécification des fonctions du SI sont

considérées comme ayant une approche orientée-traitements.

Les méthodologies dérivées des techniques des bases de données privilégient une

approche orientée-données. Une troisième perspective s’est donc développée :

l’approche orientée-dynamique [OLL & al.90]. L’essence de l’aspect dynamique d’un

système d’information est ainsi décrite afin de tenir compte de l’effet feed-back du

système sur l’évolution temporelle des constituants. Le premier objectif, qui est de

prendre en compte la dynamique dans les systèmes d’information, doit tenir compte

non seulement de l’aspect traitement par la compréhension des flux de données,


Introduction Générale 2 opérations, évènements, etc. mais aussi de l’aspect évolutif du système dans sa

globalité qui subit un changement d’activité ou même de structure comme

conséquence d’une réorganisation. Le deuxième objectif consiste justement à déduire

l’évolution future du système à partir des fonctionnalités qui incombent à chacun afin

d’éviter des cheminements pouvant aboutir à des catastrophes d’une part, et choisir la

meilleure politique décisionnelle d’autre part [Haff 94].

La présente thèse s’inscrit dans le cadre d’une problématique plus large qui fait

l’objet d’un projet de recherche intitulé ¨L’approche Bond-graph et la modélisation des

systèmes d’information : nouvelle approche orientée-communication ¨. L’objectif

principal recherché est l'application la méthodologie Bond-Graph (qui représente à

l'heure actuelle la méthodologie de modélisation la plus élaborée en ce qui concerne

les systèmes physiques et dynamiques), à la spécification des systèmes d'information.

Nous ne prétendons pas proposer une méthode universelle permettant de modéliser

tout ce qui peut se modéliser, mais surtout de développer une nouvelle vision du

monde réel ou abstrait qui nous entoure, en nous appuyant sur une méthode simple et

puissante pour l’analyse et la conception des systèmes d’information. Dans la section

B, nous présentons le plan de la thèse avec le résumé de chacun des chapitres.

SECTION B : PLAN DE LA THESE La thèse s’articule autour de cinq chapitres. Tous les chapitres peuvent se lire

indépendamment les uns des autres. Une certaine redondance a été nécessaire dans

certains chapitres afin de garantir cette indépendance.

Chapitre 1 : dans ce chapitre, nous présentons un état de l’art sur les méthodes de

modélisation et de conception des systèmes d’information afin de situer notre

contribution. Ensuite, nous décrivons notre problématique ainsi que la démarche

adoptée.


Introduction Générale 3 Chapitre 2 : ce chapitre étudie en détail les principaux concepts et caractéristiques du

langage de modélisation orienté-objet UML, qui est le résultat de la synthèse de

plusieurs méthodes orientées-objet.

Chapitre 3 : ce chapitre est consacré à l’introduction des différents concepts et des

définitions de base du langage Bond-graph pour la modélisation des systèmes

physiques (les symboles graphiques associés au transfert de puissance et à la définition

des variables généralisées mises en jeu).

Chapitre 4 : ce chapitre est consacré à la présentation de l’utilisation de la

méthodologie Bond-graph pour les systèmes physiques dans les langages de

simulation orientés-objet. On peut citer principalement le langage de simulation

Modélica qui nous a beaucoup aidé dans l’adaptation du modèle bond-graph pour les

systèmes d’information.

Chapitre 5 : Dans ce dernier chapitre nous présentons notre point de vue concernant

l’adaptation du langage Bond-graph à la modélisation des systèmes d’information, et

ce en répondant essentiellement à deux questions importantes :

- La première consiste à trouver des significations aux concepts Bond-graph dans les

systèmes d’informations, c.à.d définir des structures pour les objets Bond-graph.

- La deuxième consiste à définir les classes des objets bond-graph (définition du

modèle Bond-graph).

Ensuite, nous avons procédé à une comparaison entre cette nouvelle méthode et les

modèles UML. Pour finir, nous avons proposé un exemple d’application qui consiste à

modéliser le système de gestion d’impression à l’aide du langage Bond-graph.

Nous terminons avec une conclusion générale où nous citons les perspectives

futures et les extensions possibles de notre travail.


Chapitre I Systèmes d’information état de l’art et problématique 4 I.1. Introduction : Les entreprises et les organisations connaissent, depuis longtemps la place

déterminante de l’information et son rôle critique dans leur fonctionnement. Elles lui

ont consacré, de manière plus ou moins explicite, à la fois leur attention et des

investissements croissants pour maîtriser sa gestion.

A vrai dire, à mesure que les technologies informatiques et télématiques se

diversifient et se diffusent au delà de l’information, c’est principalement le système

d’information (SI) qui devient, pour les organisations, la préoccupation dominante.

La conception des systèmes d’information est un problème qui naît lors de toute

tentative de création d’une entité abstraite devant décrire la structure ou le

fonctionnement d’une certaine partie du monde réel qui nous entoure. Longtemps

négligée, cette branche importante du domaine du traitement automatique de

l’information se voit aujourd’hui incapable d’apporter des solutions standard, pratiques

et sûres aux différents problèmes de modélisation et de conception. Entre autres, nous

ne sommes pas encore en mesure de faire baisser les coûts de développement des

logiciels, alors que les prix du hardware ont considérablement baissé depuis une

décennie [Khiat 94].

La plupart des méthodologies actuelles ont permis, tant bien que mal, de résoudre


systèmes. Les systèmes d’information ont longtemps fait partie du domaine de la

littérature dans l’esprit de beaucoup de chercheurs, et cela à cause du manque cruel de

formalisme [Ghom & Aoum 92].

Dans la suite de ce chapitre, nous passerons en revue les différentes méthodes de

spécification et conception afin de bien les distinguer, d’enrichir notre synthèse,

d’éclaircir notre problématique et de souligner notre contribution.

Chapitre I Systèmes d’information état de l’art et problématique 5 I.2. Etat de l’Art : I.2.1 Les systèmes d’information et leur modélisation : L’information est considérée aujourd’hui comme une des très importantes

ressources d’une organisation et son poids relatif a tendance à augmenter. Les

informations mises à la disposition de chacun dans le cadre de ses activités sont

souvent indispensables.

Une représentation schématique des organisations est montrée dans la figure 1 :

empruntée à Le Moigne [Lem77], elle présente l’organisation sous la forme de la

composition de trois systèmes : le système opérant, le système d’information et le

système de décision. Le système d’information est couplé au système opérant et au

système de décision [Ghom 96].

Figure.1

Il n’y a pas de définition exhaustive et simple de la notion de système

d’information d’une organisation. Les définitions rencontrées sont multiples et

diffèrent d’une école à une autre, et d’un auteur à l’autre. Ceci est peut être dû à l’âge

relativement jeune de cette notion et à la multitude d’approches avec lesquelles on

peut l’aborder. Nous citons ci-dessous quelques définitions [Loukil 96] :

Système décisionnel

Système d’information

Système opérant

Chapitre I Systèmes d’information état de l’art et problématique 6 Définition 1 : ¨ Un système d’information est un ensemble de procédures organisées

dont l’exécution fournit des informations pour la prise de décisions

et/ou le contrôle de l’organisation. Une information est une entité

tangible ou non tangible qui réduit l’incertitude sur un état ou un

évènement ¨

Définition 2 : ¨ Un système d’information est un ensemble formé de collections de

données, de règles et de procédures pour l’acquisition, la

mémorisation, la transformation, la recherche, la communication et

la restitution des renseignements ¨.

Définition 3 : ¨ La discipline des systèmes d’information fournit un cadre analytique

et la méthodologie d’analyse, de conception, d’implémentation et de

gestion de systèmes d’information/de décision complexes. Un système

d’information est défini comme une collection de personnes,

d’ordinateurs, de logiciels, de programmes informatiques, de fichiers

de données, de systèmes de communication, de modèles de décision,

de procédures et pratiques organisationnelles, structurés et assemblés

pour assurer une qualité de données, la transmission, le traitement et

le stockage selon un critère de performance donné pour aider à la

prise de décision. Un système d’information intègre l’analyse des

systèmes, les statistiques, la gestion, la science de gestion, la

comptabilité, l’économie, les finances, le marketing, la production et

la technologie de traitement de l’information et des communications

pour accomplir ces tâches ¨.

Nous remarquons qu’une définition succincte et concise des systèmes

d’information pose certaines difficultés. Ces définitions présentent néanmoins des

points communs :

• Un SI est une entité et une composition,

• Le facteur humain est principal dans tout SI.

Chapitre I Systèmes d’information état de l’art et problématique 7

Quant aux buts des systèmes d’information, on peut dire qu’un SI a pour objectifs

de rassembler, traiter, manipuler et fournir les informations nécessaires de certaines

activités de gestion d’une organisation. Bryce le définit comme un ensemble d’affaires

qui accomplit les buts organisationnels (Ensemble des relations logiques) [Loukil 96].

I.2.2 La méthode de conception : La conception est la tâche la plus créative mais aussi la plus difficile. De

nombreuses difficultés découlent directement ou indirectement de la nature du travail

de conception, du nombre et de la variété des problèmes qu’il faut réunir pour les

résoudre. Il faut réduire à la fois les délais et les coûts de développement, garantir la

pertinence et l’efficacité des systèmes élaborés, faciliter la maintenance et prolonger

leur durée de vie.

La méthode de conception est nécessaire et utile pour [Abed & Abd 92]:

* Formuler le problème informationnel qui est posé et en maîtriser la résolution.

* Construire des SI pertinents, complets, cohérents, fiables, flexibles et adaptatifs.

* Maîtriser le problème informationnel à résoudre.

* Permettre d’évaluer le système à tout moment de son cycle de vie.

* Substituer à la construction trop individuelle des SI une conception concertée

basée sur une coopération efficace entre concepteurs, informaticiens et

gestionnaires utilisateurs.

* Sortir la construction des SI de l’empirisme actuel fondé sur les solutions

intuitives et mettre l’accent sur les problèmes cruciaux, en proposant des outils

pour les traiter.

* Avancer de façon rigoureuse dans l’élaboration de la solution en hiérarchisant les

problèmes.

* Permettre la communication entre les participants de l’équipe de conception.

* Maîtriser et réduire les coûts et les délais, accroître la productivité et la qualité des

activités de développements.

Chapitre I Systèmes d’information état de l’art et problématique 8 On peut distinguer quatre composantes essentielles indissociables et

complémentaires des méthodes de modélisation des SI [ROL86] :

I.2.2.1 Des Modèles :

Un modèle est un ensemble de concepts et de règles pour les utiliser, destiné soit

à expliquer et construire la représentation des phénomènes organisationnels, soit à

expliquer et représenter les éléments qui composent le SI et leurs relations.

Il y a des modèles qui traitent l’aspect statique, d’autres qui décrivent l’aspect

dynamique et d’autres qui traitent l’aspect comportemental.

I.2.2.2 Des Langages :

Un langage est un ensemble de constructions qui permettent de décrire

formellement les spécifications du SI élaborées aux différents stades du processus de

conception, en s’appuyant éventuellement sur un/des modèles de la méthode. La

plupart des méthodologies de conception ont recours à plusieurs formalismes pour

représenter le produit de la conception. Il existe deux sortes de langages :

* Les langages graphiques (informels) :

Ces langages utilisent un support graphique pour décrire un SI, par exemple : le

modèle Entité-Association (EA) dans Merise [TAR 91], le diagramme de spécification

de système (SSD) dans JSD [JAC 83], le Data Flow dans SADT [ROS 77], etc.

* Les langages formels :

Les langages formels ont un excellent pouvoir d’expression et sont bien adaptés

pour faire des inférences sur les spécifications. Cependant, ils sont difficiles à

apprendre, à comprendre et à utiliser [OLL & al 90], [HAB 95].

Chapitre I Systèmes d’information état de l’art et problématique 9 I.2.2.3 Des Démarches :

La démarche est le processus opératoire grâce auquel s’effectue le travail de

modélisation, de description, d’évaluation et de réalisation du SI. En général, toute

démarche de conception adopte un des paradigmes suivant [FLO 90] :

- le Paradigme cartésien

- le Paradigme systémique

- le Paradigme orienté-objet

Ces trois paradigmes seront vus en détail dans les sections suivantes.

I.2.2.4 Les Outils [Abdi95]:

Les outils peuvent être des outils manuels ou logiciels supportant la démarche de

conception. On peut classer les outils en quatre grandes catégories :

I.2.2.4.1 Les Outils Manuels :

Ces outils sont basés sur les modèles sémantiques tels que Entité-association de

Chen [CHE 76], et offrent des concepts simples et quelques règles de structuration et

de vérification permettant de choisir une représentation cohérente et adéquate.

I.2.2.4.2 Les Outils Algorithmiques :

Ces outils sont développés autour du modèle relationnel et consistent en un

ensemble d’algorithmes permettant, à partir d’un ensemble d’attributs et de contraintes

de déduire un schéma relationnel normalisé. On distingue généralement deux types

d’algorithmes : les algorithmes dits de synthèse [BEE & BER 79], et les algorithmes

dits de décomposition [COD 72], [FAG 77].

I.2.2.4.3 Les Outils Interactifs :

Ces outils facilitent l’utilisation des outils manuels et certains font appel à des

techniques de CAO, ou à des langages de spécification. D’autres ne sont que des

éditeurs graphiques de modèles formels ou des dictionnaires de données qu’on peut

manipuler avec un langage interactif. Comme exemple de ces outils, citons GIOTTO

Chapitre I Systèmes d’information état de l’art et problématique 10 [TAM & al 83], GDBDA [CHA & LOC 83], Précise PC-IAST [WAL 88], RIDL

[TRO & al 88].

I.2.2.4.4 Les Outils Intelligents (Approche Système Expert) :

Ce sont des outils utilisant les techniques de l’intelligence artificielle (IA),

comme les systèmes experts. Leur objectif est d’assister le concepteur dans

l’élaboration d’un schéma conceptuel cohérent de son application. Comme exemple de

ces outils, nous avons :

SECSI (Système Expert en Conception des Systèmes d’Information) [BOU86],

qui permet le passage des modèles de données traditionnels au modèle

relationnel.

OICSI (Outil Intelligent en Conception des systèmes d’Information), [PRO89] &

[KOU 90], qui permet d’assister l’utilisateur dans la conception d’un SI à

l’aide de la méthode REMORA [ROL & 87].

OIDSIOO (Outil Intelligent de Développement de SI Orienté-Objet) qui propose una

assistance pour la conception et la validation d’un SI à l’aide de la méthode O*

[ALI & al95].

I.2.3 Les différentes Classes de Méthodes de Modélisation :

De l’évolution chronologique des méthodes de spécification et de conception des

SI, on peut dégager trois grandes classes : la classe des méthodes cartésiennes, la

classe des méthodes systémiques et celles des méthodes orientées-objet.

I.2.3.1 La classe des méthodes cartésiennes : Les méthodes cartésiennes mettent l’accent sur la démarche de conception, c'est-

à-dire sur la ligne de conduite et de déroulement du processus de conception. La

démarche de conception qu’elles préconisent est inspirée de la méthode cartésienne

Chapitre I Systèmes d’information état de l’art et problématique 11 qu’on peut résumer ainsi : pour étudier un phénomène, on le divise en éléments

simples, on étudie chacun de ces éléments et on réunit à nouveau ces derniers dans une

synthèse.

Les méthodes cartésiennes sont axées sur la décomposition du processus de

conception en phases, elles-mêmes décomposées en étapes, ces dernières organisées

éventuellement en sous-étapes. Elles utilisent une approche de conception

fonctionnelle [ROL 90]. Comme exemples de ces méthodes, on peut citer S.A.D.T

[ROS 85], ISAC [LUN 82], PSL/PAS [TEL 77], etc.

Les méthodes cartésiennes souffrent de lacunes, parmi lesquelles on peut citer

[OLR 90] :

- l’absence de travaux théoriques susceptibles de fournir des fondements

solides aux concepts et techniques de décomposition descendante.

- l’impossibilité de prendre en compte le temps, la synchronisation et le

parallélisme des processus.

- des insuffisances dans la modélisation des données.

- la difficulté de l’évaluation de la cohérence, de la complétude et de la

qualité d’une solution.

I.2.3.2 La classe des méthodes systémiques : Contrairement aux démarches cartésiennes, les démarches systémiques sont

orientées données, et se basent sur la théorie des systèmes [LEM 84]. Le SI est vu

comme un ¨ modèle ¨ (dans le sens d’image abstraite) de la réalité organisationnelle

qui apporte aux acteurs et décideurs la connaissance dont ils ont besoin pour agir et

décider.

Les premiers modèles conceptuels sont de type relationnel [COD 70] : ils

représentent les données par des tableaux ou relations. Les modèles sémantiques sont

venus combler les insuffisances du modèle relationnel. D’autres modèles plus récents

introduisent au niveau du schéma conceptuel les aspects dynamiques du système réel.

Chapitre I Systèmes d’information état de l’art et problématique 12 Parmi les méthodes qui présentent un modèle dynamique, on peut citer : CIAM [BUB

& al 82], DADES [OLI 82], IDA [BOD83], REMORA [ROL & al 87], etc.

I.2.3.3 La classe des méthodes orientées-objet : Les approches orientées-objet, développées à l’origine pour les langages de

programmation, ont largement dépassé depuis le strict cadre de la programmation pour

aborder le domaine des bases de données. Dans ces approches, les propriétés

structurelles et comportementales des objets de l’application doivent à la fois être

modélisées mais aussi intégrées. Les concepts utilisés dans ces approches sont ceux

d’objet et de classe, d’agrégation et de généralisation, d’encapsulation, etc.

L’émergence de ces concepts dans les premières phases de développement des

systèmes a donné naissance à un certain nombre d’approches spécifiques avec une

multiplicité d’idées [HEND 90]. Parmi les méthodes orientées-objet, on peut citer

CaodD&Yourdon [COA 91], Booch [BOO91], Hood [DEL 93] & [HEI 90), etc.

I.3. Problématique : La plupart des méthodologies actuelles ont permis tant bien que mal de résoudre


systèmes. Cependant, il est difficile de trouver une méthode qui prenne en compte les

aspects fondamentaux (Données, Traitement et Comportement) dans la modélisation

des S.I.

Un système est en général vu comme un ensemble de composants en interaction.

La dynamique dans les systèmes d’information doit tenir compte non seulement de

l’aspect traitement par la compréhension du flux de données, des opérations, des

évènements, mais aussi de l’aspect évolutif du système dans sa globalité qui reflète un

changement d’activité ou même de structure comme conséquence d’une

réorganisation. En deuxième lieu, il faut justement déduire l’évolution future du

système à partir des fonctionnalités qui incombent à chacun afin d’éviter des

Chapitre I Systèmes d’information état de l’art et problématique 13 cheminements aboutissant à des catastrophes d’une part, et choisir la meilleure

politique décisionnelle d’autre part [Haff 96].

Le but de ce travail consiste à adapter pour la conception des SI une nouvelle

approche, les Bond-Graphs, déjà utilisée dans la modélisation des systèmes physiques,

tout en bénéficiant des méthodes actuelles utilisées dans la modélisation des systèmes

d’information. Le point fort de cette méthode est son formalisme qui, par sa nature

graphique de type réseau, est plus proche d'une expression naturelle du système, de ses

constituants et de leurs interactions. La communication entre les objets est le point

fort de la méthode. Elle est accomplie à l'aide d’une structure dite de « jonction », ce

qui n’est pas le cas pour l'approche orientée-objet.

L’objectif principal de ce travail n’est pas de créer une méthode idéale, mais de

montrer la faisabilité de l’adaptation d’une méthode d’un environnement à un autre

tout à fait différent (du domaine physique au domaine informationnel), tout en

illustrant cela par un exemple concret (la modélisation d’un système d’impression).

II.4. Conclusion : Après ce tour d’horizon sur les systèmes d’information et les composantes des

méthodes de modélisation des SI, nous avons expliqué les différentes approches de

modélisation des S.I. Par la suite, nous avons essayé de décrire notre problématique en

explicitant notre préoccupation et en précisant les objectifs de notre travail. Vu que la

nouvelle approche possède une représentation qui ressemble à celle des méthodes

orientées-objet, nous présentons dans le chapitre suivant les principaux concepts des

modèles orientés-objet UML.

Chapitre II Les Méthodes Orientées Objets (Modèles UMLs) 14

II.1. Introduction : L’utilisation des approches orientées-objet s’impose chaque jour davantage et

devient une voie incontournable, particulièrement dans le domaine des systèmes

d’information (SI). Le paradigme objet est apparu avec les outils qui mettent en œuvre

les mécanismes objet (classe, héritage, etc.). En effet, les concepts de développement

orientés-objet ont vu le jour à partir des langages de programmation tels que Simula

Smaltalk, C++, JAVA, etc., d’une part, et dans les systèmes de gestion de bases de

données (SGBD) tels que ORIN Gestone, IRIS et O2, d’autre part.

On va présenter dans ce chapitre les principaux concepts et caractéristiques du

langage de modélisation orienté-objet UML qui est issu de la synthèse de plusieurs

méthodes orientées-objet.

II.2. MODELES UML :

Le langage de modélisation unifié UML standardisé par l'OMG (Object

Management Group) est le résultat de la fusion de plusieurs méthodes orientées-objet :

il est principalement issu des travaux de Grady Booch, James Rumbaugh et Ivar

Jacobson (voir Fig. 1), et est devenu la référence en terme de modélisation objet. Il

prend en charge l’aspect statique et dynamique d’un système à l’aide de ses différents

diagrammes. Son but est de spécifier, visualiser, construire, et documenter les

systèmes informatiques dans les systèmes complexes. Pour cela, il définit neuf

diagrammes qui sont subdivisés en vues statiques (qui représentent "physiquement" le

système à modéliser au moyen de diagrammes d'objets, de classes, de cas d'utilisation,

de composants et de déploiement), et des vues dynamiques (qui montrent le

fonctionnement du système au moyen de diagrammes de séquence, de collaboration,

d'états-transitions et d'activités). Le diagramme de classes est le modèle de base pour

l’implémentation d’un logiciel du moment qu’il peut directement être traduit dans les

différents langages de programmation tels que Java ou C++. Le modèle objet qui

constitue les briques du logiciel peut être directement déduit à partir du modèle de


classes. De plus, il existe plusieurs ateliers de génie logiciel (Rational Rose, Visio,

Describe, etc. qui prennent en charge les diagrammes de classes UML et génèrent

ensuite le code (header) des classes orientées-objet. Chaque classe UML possède un

ensemble d’attributs (états) et un ensemble de méthodes (comportement) [Boubker

05], [Frank 04].

II.2.1. Diagramme de Cas d’utilisation (vue Fonctionnelle) :

II.2.1.1. Les cas d’utilisation :

Le diagramme de cas d’utilisation constitue l’apport d’Ivar Jacobson à UML

[Oliv 04].


Un cas d’utilisation (use case) modélise une interaction entre le système

Informatique à développer et un utilisateur ou acteur interagissant avec le système.

Plus précisément, un cas d’utilisation décrit une séquence d’actions réalisées par le

système qui produit un résultat observable pour un acteur.

Il existe en général deux types de description des use cases :

– une description textuelle de chaque cas ;

– le diagramme des cas, qui constitue une synthèse de l’ensemble des cas

Il n’existe pas de norme établie pour la description textuelle des cas. On y trouve

généralement pour chaque cas son nom, un bref résumé de son déroulement, le

contexte dans lequel il s’applique, les acteurs qu’il met en jeu, puis une description

détaillée faisant apparaître le déroulement nominal de toutes les interactions, les cas

nécessitant des traitements d’exception, les effets du déroulement sur l’ensemble du

système, etc.

II.2.1.2 Liens entre cas d’utilisation : « include » et « extend » Il est parfois intéressant d’utiliser des liens entre cas (sans passer par un acteur),

UML en fournit deux types : la relation utilise (include) et la relation étend (extend).

- Utilisation de cas : La relation utilise (include) est employée quand deux cas

d’utilisation ont en commun une même fonctionnalité et que l’on souhaite


factoriser celle-ci en créant un sous-cas, ou cas intermédiaire, afin de marquer les

différences d’utilisation.

- Extension de cas (extend) : schématiquement, nous dirons qu’il y a extension

d’un cas d’utilisation quand un cas est globalement similaire à un autre, tout en

effectuant un peu plus de travail (voire un travail plus spécifique). Cette notion – à

utiliser avec discernement – permet d’identifier des cas particuliers (comme des

procédures à suivre en cas d’incident) dès le début ou lorsque l’attitude face à un

utilisateur spécifique du système doit être spécialisée ou adaptée. Il s’agit grosso

modo d’une variation du cas d’utilisation normal.

Par exemple, dans le cas d’un distributeur automatique de billets dans une

banque, les utilisateurs du distributeur qui sont clients de la banque peuvent effectuer

des opérations qui ne sont pas accessibles à l’utilisateur normal (par exemple, la

consultation du solde). On dira que le cas « service au client de la banque » étend le

cas « service à l’utilisateur ». Mais on peut dire aussi que les deux types de clients


peuvent effectuer des retraits, si bien que les cas « service au client de la banque » et

« service à l’utilisateur » utilisent tous les deux le cas « retrait d’espèces ». On

représente cet exemple sur la figure 3.

II.2.2. Le diagramme de classes (vue structurelle) : Un diagramme de classes décrit le type des objets ou données du système ainsi

que les différentes formes de relations statiques qui les relient entre eux. On distingue

classiquement deux types principaux de relations entre objets :

– les associations, bien connues des vieux modèles entité/association utilisés

dans la conception des bases de données depuis les années 70 ;

– les sous-types, particulièrement en vogue en conception orientée-objet, puisqu’ils

s’expriment très bien à l’aide de l’héritage en programmation.

La figure 4 présente un exemple de diagramme de classes très simple, tel qu’on

pourrait en rencontrer en analyse. On voit qu’un simple coup d’oeil suffit à se faire une

première idée des entités modélisées et de leurs relations.


II.2.2.1 Spécification des diagrammes de classes : Avant de passer aux diagrammes d’analyse il faut donc introduire les concepts

UML fondamentaux pour la modélisation du domaine, à savoir les classes, les

associations et les attributs.

Afin d’aboutir au modèle du domaine nous devons :

1 Identifier les classes.

2 Identifier les associations entre classes.

3 Identifier les attributs.

4 Définir la structuration en packages.

UML définit quatre types de relations entre éléments [Oliv C 03]:

A) Relation structurelle (ou association) :

Une relation structurelle décrit un ensemble de liens. Un lien est une connexion

entre objets.

Exemple : Un contrat concerne un client.

class Contrat {

Client bénéficiaire;

...

}

Le bénéficiaire est une des caractéristiques d'un contrat : la relation est

structurelle. Cette relation est représentée par un trait plein, pouvant être orienté. La

multiplicité est notée du côté du rôle cible de l'association. Elle spécifie le nombre

d'instances pouvant être associées (liées) avec une seule instance source de la relation.

Dans la phrase un contrat concerne un client, contrat est la source et client est la


destination.

Une multiplicité est exprimée soit par un couple de valeur (N,M) soit par une

seule valeur lorsque N et M sont égaux.

B) Relation de spécialisation/généralisation :

- Relation d'héritage, dans laquelle les objets de l'élément spécialisé (classe

enfant) peuvent remplacer les objets de l'élément général (classe parent).

Exemple : Un client professionnel est une sorte de client.

Class ClientProfessionnel extends Client {

...

}

Notation UML : Un trait plein, orienté de la classe spécialisée (enfant) vers son

modèle (parent) et se terminant par une flèche fermée.

Attention : ceci n'est vrai que si un client professionnel se comporte comme un

client.


C) Relation réalisation:

- Relation dans laquelle une interface définit un contrat garanti par une classe

d'implémentation.

Exemple : Le formulaire SaisirClient est un écouteur d'événements.

Class SaisirClient extends JFrame implements ActionListener

{

...

public void actionPerformed(ActionEvent e)

{

// faire quelque chose

}

}

La fenêtre SaisirClient réalise le contrat définit par l'interface ActionListener.

Notation UML : Un trait discontinu partant de la classe d'implémentation et

allant vers l'interface, se terminant par une pointe de flèche fermée, la même utilisée

par la spécialisation/généralisation.

Notation simplifiée : Une interface peut être représentée par un petit cercle avec

le nom de l'interface placé juste en dessous. Le cercle peut être attaché à une ou


plusieurs classes d'implémentation.

D) Relation de dépendance:

- Relation entre éléments du modèle ne nécessitant pas forcément un lien entre

objets. Lorsque cette relation est réalisée par des liens entre objets, ces derniers sont

limités dans le temps, contrairement à d'autres relations plus structurelles (cas d'une

association - voir ci-dessus).

Un élément A dépend d'un élément B, lorsque A utilise des services de B.

De ce fait, tout changement dans B peut avoir des répercussions sur A.

Exemple : Un contrat dispose d'un service d'impression (méthode impression), qui

utilise une méthode (print), dont la spécification est déclarée par l'interface Printer.

Class Contrat

{

...

public void impression()

{

Printer imprimante = PrinterFactory.getInstance();

...

imprimante.print(client.getName());

...

}

}


On remarquera que le lien entre un objet "contrat" et une "imprimante" est

momentané, il ne dure que le temps d'exécution de la méthode impression. En d'autres

termes, l'imprimante n'a pas lieu d'être un attribut de la classe Contrat, et de ce fait, ce

n'est pas une association, mais une simple dépendance.

Notation UML : Un trait discontinu partant de la classe dépendante et pointant

vers la classe proposant les services sollicités, se terminant par une pointe de flèche

ouverte (c'est ce qui la distingue de la relation de réalisation).

II.2.3. Diagramme de séquence (vue fonctionnelle) :

Les diagrammes de séquence mettent en valeur les échanges de messages

(déclencheurs d’événements) entre acteurs et objets (ou entre objets et objets) de

manière chronologique, l’évolution du temps se lisant de haut en bas.

Chaque colonne correspond à un objet (décrit dans le diagramme des classes),

ou éventuellement à un acteur, introduit dans le diagramme des cas d’utilisation. La

ligne de vie de l’objet représente la durée de son interaction avec les autres objets du

diagramme.

Un diagramme de séquence est un moyen semi-formel de capturer le

comportement de tous les objets et acteurs impliqués dans un cas d’utilisation.


On peut indiquer un type de message particulier : les retours de fonction qui, bien

entendu, ne concernent aucun message mais signifient la fin de l’appel de l’objet

appelé. Ils permettent d’indiquer la libération de l’objet appelant (ou de l’acteur). Un

emploi abusif des retours de fonction peut alourdir considérablement le diagramme,

aussi un usage parcimonieux est-il conseillé. On peut faire apparaître de nombreuses

informations de contrôle le long de la ligne de vie d’un objet (Voir Fig.5).

FIG.5 Un diagramme de séquence (ici, il s’agit d’un diagramme de séquence d’analyse)

II.2.4. Diagramme d’états (vue dynamique) :

Les diagrammes d’états décrivent tous les états possibles d’un objet (vu comme

une machine à états). Ils indiquent en quoi ces changements d’états sont induits par des

évènements. Les modèles orientés-objet s’appuient la plupart du temps sur les

Statecharts de David Harel [Har87]. C’est aussi le cas d’UML.


On distingue deux types d’information sur un diagramme d’états (voire Fig.6) :

– des états, comme l’état initial, l’état final, ou les états courants.

– des transitions, induisant un changement d’état, c’est-à-dire le passage d’un

état à un autre.

FIG.6 Le diagramme d’états d’un citoyen

Une transition est en général étiquetée par un label selon la syntaxe :

< NomÉvénement> [<Garde (ou contrainte)>] / <NomAction> II.3. Conclusion : Nous avons présenté dans ce chapitre les principaux concepts et caractéristiques

du langage de modélisation orienté-objet UML qui est la synthèse de plusieurs

méthodes orientées-objet. UML est principalement issu des travaux de Grady Booch,

James Rumbaugh et Ivar Jacobson. Le modèle UML n’est pas une méthode, mais un

langage. Il peut donc être utilisé sans remettre en cause les procédés habituels de

conception de l’entreprise et, en particulier, les méthodes plus anciennes telles que

OMT (Object Modelling Technique, J.Rumbaugh) qui sont tout à fait utilisables. Il


facilite la communication entre clients et concepteurs, ainsi qu’entre équipes de

concepteurs. Il a été conçu pour couvrir tous les aspects de l’analyse et de la

conception d’un logiciel, en favorisant une démarche souple fondée sur les interactions

entre les différentes vues que l’on peut avoir d’une application. En introduisant les

modèles UML (qui restent des notations semi-formelles), l’objectif majeur de ce

mémoire est de bénéficier de leurs caractéristiques dans l’adaptation du langage bond-

graph à la spécification des systèmes d’information.

Chapitre III Bond-Graphs et Systèmes Physiques 27

III.1.Introduction : L’outil Bond-graph (ou graphe de liaison), défini par [PAYTER 1961], formalisé

par [KARNOPP, ROSENBERGER, 1975,1983], [BREEDVELD, 1984], se situe

comme intermédiaire entre le système physique et les modèles mathématiques qui lui

sont associés (matrice de transfert dans le cas linéaire, équations d’état différentielles

d’ordre 2).

Dans ce chapitre nous présentons de façon assez succincte les définitions de base

du langage bond-graph (les symboles graphiques associés au transfert de puissance et à

la définition des variables généralisées mises en jeu).

III.2.Présentation du langage bond-graph :

III.2.1.Définitions :

* Le langage bond-graph est une représentation graphique d’un système intégrant

tous ses constituants technologiques. Il décrit de manière unifiée les éléments et sous-

systèmes et traite les interactions physiques fonctionnelles et comportementales en

terme de flux d’énergie porté des liens (BONDS) entre les PORTS (limites de chaque

sous-système). C’est un support commun pour la compréhension et la maîtrise du

comportement des systèmes (physique qualitative, comportement dynamique, loi de

commande, etc.). [THO 75] [BRE 85].

* Le langage bond-graph est un langage graphique de représentation des systèmes

physiques qui fait partie de la classe des représentations de type réseau, la notion du

bond-graph est une étape d’abstraction supplémentaire du graphe linéaire par laquelle

l’unification des représentations physiques a été achevée. Elle a de plus l’avantage de

permettre la représentation aisée et explicite des relations physiques mutuelles de

certaines relations topologiques non représentables par un graphe linéaire. [BRE 85].


III.2.2.Représentation des transferts de puissance : La modélisation bond-graph suppose qu’il est possible de séparer et de localiser

les propriétés des objets physiques et donc de décrire ces objets comme un système de

propriétés élémentaires reliées entre elles, le système physique est alors représenté par

des éléments multi-ports (nœuds), interconnectés par des liens. De plus, la séparation

des propriétés d’un objet physique est basée sur la notion d’énergie entre les éléments

multi-ports composant un système fermé. On postule non seulement la conservation

d’énergie, mais une hypothèse plus forte qui est la continuité de puissance [GEB 77].

Cela signifie que l’on considère que la conservation d’énergie est assurée par un flux

d’énergie entre éléments. Ce flux d’énergie est représenté par les liens de puissance

connectant les éléments entre eux (voir Fig.1).

Sous-Sys 1 ports Bonds Sous-sys 2 Sous-Sys 3 Fig. 1

III.2.3.Les variables mises en jeu :

III.2.3.1.Les variables de puissance (Variables Conjuguées):

Dans le cas général, tout lien de puissance porte deux variables duales appelées

effort et flux. La puissance portée par le bond est alors le produit de ces deux

variables.

e P = e x f f Le sens de la demi-flèche indique le sens conventionnel de l’échange d’énergie.


Ce postulat est appelé le postulat de puissance qui est vérifié à posteriori dans

tous les domaines de la physique (Voir tableau 1).

Variables Généralisées

EFFORT e

FLUX f

MOMENT p

DEPLACEMENT q

Translation

Force F N

Vitesse V m/s

Impulsion p Ns

Déplacement X m

Rotation

Couple C Nm

Vitesse angulaire ω Rad/s

Impulsion angul. h Nms

Angle θ Rad

Hydraulique

Pression totale P N/m2

Débit volumique Qv m3/s

Impulsion de pres Γ Ns/m2

Volume V m3

Acoustique

Pression P N/m2

Vitesse volumique Qv m3/s

Impulsion Γ Ns/m2

Volume V m3

Electrique

Tension U V

Courant I A

Flux φ V/s

Charge q C

Thermodynamique

Température T K

Flux d’entropie fs W/K

Entropie S J/K

Magnétique

Force magnét. λ A

Dérivée du flux φ Wb/s

Flux magnétique φ Wb

Chimique

Potentiel chimiq. µ J/mol

Flux molaire N’ mol/s

Masse molaire N mol

Tableau 1


III.2.3.2.Les variables d’énergie (Variables généralisées):

Les variables généralisées sont introduites pour décrire l’état du système et sont

définies par :

* Le déplacement généralisé : q = f dt

* L’impulsion généralisée : p = e dt

Remarque : Si l’une des variables conjuguées est négligeable, le bond devient

dégénéré [KAR et ROS 79] et est représenté par la flèche pleine.

e

f

III.2.4.Les Eléments Bond-graph :

Le bond-graph est constitué d’un ensemble d’éléments et de jonctions reliées

entre eux par des branches qui sont :

III.2.4.1. Des Eléments Actifs (les Sources) :

Ces éléments fournissent de la puissance au système, ils sont dits actifs. On

distingue deux types de source :

- Les sources d’effort Se,

- Les sources de flux Sf.

L’orientation de la demi-flèche est fixée et supposée toujours sortant de la source.

Se Sf


III.2.4.2. Des Eléments Passifs :

Ce sont des éléments dissipateurs de puissance.

A. L’élément R : l’élément R est utilisé pour modéliser tout phénomène liant

l’effort au flux [BRE85]. Il est caractérisé par la loi générique : ΦR (e, f) = 0.

Dans le cas linéaire : e (t)=R f (t).

B. L’élément C : l’élément C est utilisé pour modéliser tout phénomène liant

l’effort au déplacement [KAR 69]. Il est caractérisé par la loi générique :

ΦC (e,q) = 0.

e C : C1 e = (1/C1) f dt f

C. Elément I : l’élément I est utilisé pour modéliser tout phénomène liant l’effort

au moment [KAR 69]. Il est caractérisé par la loi générique :

ΦI (p, f) = 0.

e I: I1 f = (1/I1) e dt f

C’est l’élément dual de C.

III.2.4.3.des Eléments de Jonction :

Les éléments (0, 1, TF, GY) servent à coupler les éléments R, C, I, et composent

la structure de jonction du modèle correspondant à l’architecture du système étudié, ils

sont conservatifs de puissance.

A. La Jonction 0 (Jonction Parallèle) :

La jonction 0 sert à associer les éléments soumis au même effort [ORT 73]. Elle

est caractérisée par les équations :


R e1 = e2 = ... = en

R C 0 C ∑ αi fi = 0 , αi = ± 1

B. La Jonction 1 (Jonction Série) :

La jonction 1 sert à associer les éléments soumis au même flux [ORT 73]. Elle

est duale de la jonction 0 et est caractérisée par les équations :

R R f1 = f2 = ... = fn C 1 C ∑ αi ei = 0 , αi = ± 1 Remarque : - Le but de connecter les éléments par les jonctions est de construire des

systèmes complexes en composant des éléments simples.

- Les bonds qui lient une jonction à un élément sont dits externes, et ceux

qui joignent deux jonctions sont appelés internes.

C. Le Transformateur TF :

L’élément TF est un élément 2-ports. Il représente un couplage inter-domaines

(ex : mécanique rotationnelle/translationnelle), ses équations sont :

e1 e2 e1 = m e2 TF f1 m f2 f2 = m f1 Si m n’est pas constant, on parle de transformateur modulé noté MTF.


D. Le Gyrateur GY :

L’élément GY est un élément 2-ports. Il représente les phénomènes de couplage

entre les différents domaines de la physique (ex : moteur électrique : passage du

domaine électrique au mécanique), ses équations constitutives sont :

e1 e2 e1 = r f2 GY f1 r f2 e2 = r f1

III.3.Notion de Causalité :

Le langage bond graph (BG) est remarquable par la simplicité de ses concepts de

base et son applicabilité à de très nombreux domaines industriels. Il est fondé sur le

transfert d'énergie entre éléments, symbolisé par un lien de puissance

dans lequel e représente la variable effort du domaine étudié (F : la force en

dynamique de translation, U : la tension en électrotechnique, T ; la température en

thermodynamique, etc.) et f la variable flux de ce même domaine (respectivement V :

vitesse, I : intensité électrique, dS/dt : flux d'entropie, etc.). La puissance transférée est

alors le produit entre les variables effort et flux : P = e ´ f.

La dernière équation ci-dessus montre que, pour une puissance donnée, si la

variable effort est imposée, alors la variable flux est automatiquement déterminée et

réciproquement. Pour chaque lien BG, si l'information sur l'effort est imposée par

l'élément à l'une des extrémités du lien, alors l'information sur le flux doit venir de

l'autre extrémité du lien et vice-versa. Ce dernier point fait apparaître la notion de

causalité [Nev 94].

Supposons qu’on ait deux systèmes couplés A et B, tels que A transmet à B la

puissance P=e x f, nous avons deux situations possibles :


- A applique à B un effort e, qui réagit en envoyant à A un flux f ;

- A applique à B un flux f, qui réagit en envoyant à A un effort e.

Pour prendre en considération ces relations de cause à effet et les représenter sur

le modèle bond-graph, nous introduisons le trait causal qui indique le sens dans lequel

l’effort est connu.

f f

A B ou A B

e e

III.3.1.Restriction de Causalité :

L’assignation de la causalité ne peut se faire de façon arbitraire mais doit suivre

les contraintes suivantes appelés restrictions de causalité.

III.3.1.1.Les Causalités obligatoires :

Elles apparaissent sur les sources.

S et SF

e f

III.3.1.2. Les Causalités sur les éléments R, C, I :

A. L’élément R : Dans le cas linéaire, deux situations tout à fait équivalentes

peuvent se présenter :

f f

R ou R

e e


B. Les éléments C et I : on préfère la causalité intégrale qui correspond à des

équations Constitutives Intégrales

C e = (1/C) f dt I f = (1/C) e dt III.3.1.3. Les Jonctions :

A. La Jonction 0 : Dans la jonction 0, on a un seul trait causal à l’intérieur de la

Jonction.

B. La Jonction 1 : Dans la jonction 1, on a un seul trait causal à l’extérieur de la

Jonction.

C. Le Transformateur TF :

Nous avons deux possibilités. Les relations caractéristiques d’un TF

s’écrivent, si e2 et f1 sont connus, sous la forme :

e1 = m e2 e2 on a TF f2 = m f1 f1 m

ou, si e1 et f2 sont connus : e2 = (1/m) e1 f2 on a TF f1 = (1/m) f2 e1 m

D. Le Gyrateur GY :

Comme pour le cas du transformateur, nous avons deux possibilités. Les

relations caractéristiques d’un GY s’écrivent, si f1 et f2 sont connus, sous la

forme :


e1 = r f2 on a GY e2 = r f1 f1 r f2

ou, si e1 et e2 sont connus : f2 = (1/r) e1 on a GY f1 = (1/r) e2 e1 r e2

Ici, on a la règle suivante : « pas de trait causal ou 2 traits causaux près du GY » III.4. Conclusion:

Le modèle bond-graph d’un système physique dynamique se situe comme

intermédiaire entre le schéma physique et les modèles mathématiques associés

(équation d’état, fonction de transfert ou matrice de transfert). Il présente un double

intérêt : la structure physique ainsi que la nature des sous-systèmes et les éléments ne

sont pas perdues, de plus tout changement dans le modèle s’opère indépendamment

des autres parties, ce qui stimule la maîtrise de la complexité du processus de

modélisation.

Le langage des bond-gaphs permet de plus de bien mettre en évidence le

phénomène de causalité. Il s'agit d'un formalisme simple à appréhender, efficace à

mettre en oeuvre. On peut déduire directement les équations d'état et les schémas

blocs.

La Modélisation par Bond-graphs peut se faire de façon hiérarchique et se prête bien

alors à une conception orientée-objet du point de vue représentation. Le chapitre suivant

présente le modèle bond-graph dans un langage de simulation orienté-objet appelé Modélica.

Chapitre IV Bond-Graphs et Les langages de simulation O.O 37

IV.1. Introduction : Un modèle est une représentation abstraite et cohérente d'un système. La

simulation est la reproduction du comportement dynamique d’un système basé sur un

modèle pour obtenir des résultats qui peuvent être appliqués [Rouane 98].

Les techniques de modélisation et de simulation d’un système dynamique ont

évolué depuis l’apparition des premiers calculateurs numériques. Les premiers

simulateurs étaient analogiques. Leur fonction de base était de modéliser un système

dynamique sur la base d’un ensemble d’équations différentielles ordinaires (ODEs).

La modélisation d’un système physique complexe peut être accomplie à travers sa

décomposition en sous-systèmes élémentaires reliés entre eux. Le domaine électrique

est un exemple de cela où les fils relient les composants électriques. Cette nouvelle

approche exige l’application un nouveau paradigme. Les techniques orientées-objet

ont été introduites pour jouer ce rôle. Parmi ces modèles orientés-objet on peut citer

principalement le langage de simulation Modélica qui nous a aidé dans l’adaptation du

modèle bond-graph aux systèmes d’informations.

IV.2. Le Langage Modélica : Modélica est un langage de modélisation et de simulation orienté-objet pour les

systèmes physiques créé en 1997 par un groupe de chercheurs. Son principal objectif

est de définir un langage moderne et uniforme capable de regrouper plusieurs

domaines des systèmes physiques (circuits électriques, hydraulique, etc.) et de

supporter différents formalismes comme par exemple ODEs, DEAs, les Automates

d’Etats Finis, les Bond-graphs, les Evénements Discrets, les Réseaux de Pétri, etc.

Modélica est construit sur un modèle d’équations mathématiques acausal et de

constructeurs orientés-objet dont le but est de développer une librairie pour l’échange

de modèles [F.Cel&Ang 05], [F.Cel&Gre 03], [Mar 06]. Parmi ses caractéristiques les

plus importantes, on peut citer :

1 - la possession d’un modèle acausal basé sur les équations différentielles et

algébriques,


2 – la capacité de modélisation de systèmes hétérogènes, i.e. la possibilité de

combiner dans le même modèle d’application les systèmes électriques, mécaniques,

thermodynamiques, hydrauliques, etc.

3- l’utilisation des concepts de l’orienté-objet comme le type, la classe,

l’encapsulation et l’héritage.

Une classe dans Modélica contient des variables (i.e instances d’autres classes),

des équations et des définitions locales. Une fonction (méthode) est vue comme une

classe sans équation mais incluant une section algorithme [Mod 00], [Ska&Sor 05],

[Jan F 99], [Pet F.&Vad 98].

La possibilité de modélisation de systèmes hétérogènes est le point fort de la

méthode, il est basé sur la notion de connecteurs qui représentent les interfaces (ports)

entre les objets.

Dans cette section, nous présentons le langage Modélica en nous basant sur les

structures des concepts de classes et les systèmes de types, et en introduisant des

exemples tirés des systèmes électriques.

IV.2.1 Modélica et l’orienté-objet : Les langages orientés-objet traditionnels comme C++, Java et Simula supportent

la programmation des opérations sur l’état. L’état d’un programme inclut des valeurs

de variables et des données d’objets. Les objets changent d’une façon dynamique.

L’approche Modélica est différente, elle souligne un modèle mathématique structuré et

utilise les avantages de l’approche orientée-objet.

IV.2.2 Modèle mathématique orienté-objet : Le modèle mathématique orienté-objet est défini comme suit: - Un objet est une collection de variables, d’équations, de fonctions et d’autres

définitions reliées à une abstraction commune et pouvant partager un état. De


telles opérations sont souvent appelées méthodes. L’état est représenté par des

instances de variables.

- Les classes sont des templates pour la création des objets et des sous-classes.

- L’héritage permet de réutiliser les équations, les fonctions, les définitions d’une

classe lorsqu’on définit de nouveaux objets et de nouvelles classes.

IV.2.3 Vue d’ensemble de Modélica:

Les programmes Modélica sont construits à partir de classes. Contrairement aux

langages orientés-objet traditionnels, Modélica définit le comportement à travers les

équations et non les méthodes. Les équations peuvent être écrites d’une façon

explicite comme a=b ou héritées des autres classes. Elles peuvent être aussi

spécifiées par la structure Connect. La structure Connect(v1,v2) sert à coupler deux

variables v1 et v2 appelées connectors et qui appartiennent à deux objets reliés entre

eux.

Dans les sections suivantes, on va présenter les principales bases syntaxiques et

sémantiques du langage Modélica, tels que les Connecteurs, l’Encapsulation

d’équations, l’Héritage et les Déclarations des Paramètres et des Constantes.

IV.2.3.1 Modèle Modélica d’un circuit électrique : Soit le circuit suivant ( Fig.01) :

Fig. 01 Le modèle Modélica équivalent est défini par la description suivante :


class circuit Resistor R1(R=10); Capacitor C(C=0.01); Resistor R2(R=100); Inductor L(L=0.1); VsourceAC AC; Ground G; equation connect (AC.p, R1.p); // Wire 1 connect (R1.n, C.p); // Wire 2 connect (C.n, AC.n); // Wire 3 connect (R1.p, R2.p); // Wire 4 connect (R2.n, L.p); // Wire 5 connect (L.n, C.n); // Wire 6 connect (AC.n, G.p); // Wire 7 end circuit; Dans le modèle précèdent, on peut voir facilement les différents composants du

système ainsi que les différentes connections. Les connecteurs spécifient les

interactions entre les composants. Les variables déclarées dans la classe peuvent être

publiques ou privées.

IV.2.3.2 Librairie de Classes: Dans cette section, on va expliquer comment on définit les classes dans Modélica.

Dans Modélica, un Connector doit contenir le maximum de données pour décrire

une interaction. Dans les composants électriques, nous avons besoin des variables

Voltage et Current (courant) pour définir les interactions dans un fil électrique. Les

types sont déclarés comme suit :

Class Voltage = Real ; Class Current = Real ; Le type Real peut être un type prédéfini ou un ensemble d’attributs défini par

défaut par exemple :

Class Voltage = Real (unit=”V”, min=-220.0, max=220.0);


IV.2.3.3 Classes Connector : La classe Connector est définie comme suit: Connector Pin Voltage v; flow Current i; end Pin; La structure Connect(Pin1,Pin2) où Pin1 et Pin2 sont deux points de la classe Pin,

implique deux équations :

Pin1.v = Pin2.v Pin1.i + Pin2.i = 0 IV.2.3.4 Classes Virtuelles (Partielles) : On définit la classe partielle comme suit (voir Fig.2) : Partial class TwoPin "Superclass of elements with two electric pins" Pin p, n; Voltage v; Current i; equation v = p.v - n.v; 0 = p.i + n.i; i = p.i; end TwoPin;

VI.2.3.5 Modélisation Acausale : La modélisation acausale est basée sur des équations et non sur l’affectation

d’instructions. Les équations n’indiquent pas les variables qui sont en entrée et celles

qui sont en sortie, tandis que dans les instructions d’affectation les variables du côté


gauche sont toujours des sorties (résultats) et les variables du côté droit sont toujours

des entrées. Ainsi, la causalité des modèles basés sur les équations est non spécifiée

mais fixée seulement quand les systèmes d’équations est résolu. Ceci s’appelle la

modélisation acausale [Mod 00].

II.2.3.6 Héritage, paramètres et constantes : Pour définir un modèle pour une résistance, on utilise Twopin et une définition

appellée parameter pour la résistance et la loi d’Ohm pour définir le comportement :

class Resistor "Ideal electrical resistor" extends TwoPin; parameter Real R(unit="Ohm") "Resistance"; equation R*i = v; end Resistor; Le mot clé parameter spécifie que la variable est constante pendant l’exécution

de la simulation mais qu’elle peut changer de valeurs entre les exécutions. Parameter

est utilisé pour changer le comportement d’un modèle.

Une constante dans Modélica ne change jamais.

Le mot clé extends indique la classe parent. Toutes les variables, équations,

connecteurs sont héritées de la classe parent. Modélica peut supporter l’héritage

multiple.

VI.2.3.7 Temps et Modèles dynamiques : Les systèmes dynamiques sont des modèles où le comportement évolue en

fonction du temps. La classe source de tension peut être définie comme :

class VsourceAC "Sin-wave voltage source" extends TwoPin; parameter Voltage VA = 220 "Amplitude"; parameter Real f(unit="Hz") = 50 "Frequency"; constant Real PI=3.141592653589793; equation v = VA*sin(2*PI*f*time); end VsourceAC;


IV.2.3.8 Fonctions : Modélica possède une classe spéciale appelée function qui possède des variables

publiques en entrées et en sorties, et une section d’algorithme sans équations. Son but

est de compléter les modèles acausaux.

IV.2.3.9 Notion de sous-types dans Modélica : Une classe A est un sous-type d’une classe B si la classe A contient toutes les

variables publiques déclarées dans la classe B, et si les types de ces variables sont des

sous-types des variables correspondants dans B. Par exemple, la classe TempResitor

est un sous-type de Resistor.

class TempResistor extends TwoPin parameter Real R, RT, Tref ; Real T; equation v=i*(R+RT*(T-Tref)); end TempResistor IV.3. Bond-Graph et Modélica : Nous présentons dans cette section l’implémentation d’une librairie du modèle

Bond-Graph dans le langage Modélica qui, comme on l’a vu précédemment, a pour

objectif principal de faciliter l’échange de modèles, des librairies et des spécifications

de simulations. Le modèle Bond-Graph utilise des concepts et des notions

indépendantes du domaine des systèmes physiques à modéliser, où les processus

physiques sont directement représentés par des sommets dans un graphe orienté, et les

arcs représentent un échange idéal d’énergie entre deux sommets.

VI.3.1 Librairie de Bond-Graph dans Modélica : Le nombre d’éléments de base de bond-graph est limité et peut être énuméré. De

plus, il y a plusieurs propriétés des bonds qui doivent faire l’objet d’une attention

particulière lorsqu’on écrit la librairie du modèle Bond-graph dans le langage

Modélica [Jan F 99], [Pet F.&Vad 98], [Jan F 97]:


1- Les bonds connectent les ports des sous-modèles point à point.

2- Les bonds portent deux variables duales (signaux) appelées l’effort et le flux. Le

produit de ces deux variables est la puissance échangée.

3- Les variables d’un port du coté gauche du bond sont égales aux variables du port

du coté droit. Ceci implique deux équations (voir Fig. A1).

p1.effort = p2.effort P1.flux = p2.flux Fig. A1 : Un bond connecte deux ports (p1 et p2) des différents sous-modèles et leurs équations. Un port Bond-graph est défini comme suit : Connector BondPort "Bond Graph power port" Real e "Effort variable"; Real f "Flow variable"; equation ASSERT(Cardinality(This)==1, "Power ports have only one edge connected to"); end BondPort; Chaque Bond possède une orientation de puissance. Les éléments passifs (R, I,C)

possèdent une direction de puissance dirigée vers l’intérieur, tandis que les éléments

actifs (Sources) ont une direction de puissance dirigée vers l’extérieur. Donc un

attribut est utilisé pour spécifier ces restrictions :

partial model OnePortPassive "One port passive bond graph element" BondPort p "Generic power port p"; equation ASSERT(Direction(p)==1, "Power direction towards element for passivity"); end OnePortPassive; Un Bond est composé de deux signaux de directions opposées. La direction du

signal est appelée la causalité qui est utilisée seulement pour générer une structure de

calcul. Cette causalité demande à faire des restrictions des formes d’attributs au niveau

des ports.

Les éléments de stockage, particulièrement appelés aussi les éléments

énergétiques, imposent une causalité particulière au niveau de leurs ports. Les


équations générées sont soient ODE’s soient DAE’s. Dans ce cas la variable d’état

utilisé la conservation de quantité qui représente une quantité spécifique dans chaque

domaine physique.

partial model OnePortEnergetic "One port storage element, being passive" extends OnePortPassive; Real state "Conserved quantity"; end OnePortEnergetic; L’élément de stockage C décrit ci-dessous : model C "Bond Graph C element, storage of q-type conserved quantity" extends OnePortEnergetic; parameter Real c "Capacitance"; equation der(state) = p.f; p.e = state / c; end C; La condition initiale de la variable d’état peut être spécifiée comme un attribut

appartenant à cette variable d’état.

L’élément de stockage I est le dual de C (l’état est l’intégrale de la variable

d’effort).

L’élément R dans sa forme linéaire n’impose aucune restriction de causalité,

puisque sa relation constitutive est algébrique et peut facilement être inversée.

model R "Bond Graph resistor" extends OnePortPassive; parameter Real R "Resistance "; equation p.e = R * p.f; end R; Pour décrire les structures de connections, on définit des jonctions spéciales

appelées Jontion 0 (même effort) et Jontion 1 (même flux). La jonction 1 dans

Modélica est définie comme suit :


model J1 "Bond graph One junction" parameter Integer N "# power ports"; BondPort P[N] "extendable port"; equation // Efforts sum up to 0, taking signs from the power bond directions Direction(P)' * P.e = 0; // Flows are all equal p.f[1] = p.f[2:N]; end J1; Noter que X' signifie la transposée de X. La jonction 0 est la forme duale de la Jonction 1. De la même manière, on peut définir les autres éléments de base (TF-

transformateur, GY-gyrateur). De plus, les résistances, les sources, transformateurs et

gyrateurs peuvent avoir des paramètres non constants. La valeur des ces paramètres

peut être introduite à travers l’interface comme un signal entrant. Les éléments non

linéaires peuvent être aussi définis en réutilisant ce qui a été déjà utilisé dans le cas

linéaire [Jan F 97]. Seulement les équations doivent être adaptées. On déclare aussi de

nouvelles variables et paramètres. Un exemple de transformateur modulé est défini

comme suit :

model MTF "Bond graph modulated transformer element" extends TwoPortPassive; input Real Modu "Modulation=e1/e2"; equation PowIn.e = Modu * PowOut.e; PowOut.f = Modu * PowIn.f; end MTF;

L’élément MTF est une spécialisation du modèle partial TwoPortPassive dans

lequel deux ports sont déclarés (Powin et PowOut).


IV.4. Conclusion : Nous avons présenté dans ce chapitre les différents concepts du langage de

modélisation et de simulation orienté-objet Modélica qui est capable de grouper

plusieurs domaines des systèmes physiques. De plus, ce modèle a pu définir une

bibliothèque pour le langage Bond-graph. Cette dernière nous a beaucoup aidé pour

l’adaptation du langage bond-graph aux systèmes d’informations, qui est décrite dans

le chapitre suivant.

Chapitre V Bond-Graphs et les Systèmes d’Information (B.G.S.I) 48

V.1.Introduction : Après avoir présenté dans le chapitre précédent une méthode de définition d’une

librairie du modèle Bond-Graph dans le langage de simulation orienté-objet Modélica,

nous allons maintenant montrer et de la même manière comment on peut définir les

classes du langage Bond-graph dans les systèmes d’informations.

Dans ce chapitre, on va essentiellement répondre à deux questions :

- La première question consiste à trouver des significations aux concepts Bond-

graphs dans les systèmes d’informations, c.à.d donner une sémantique aux

objets Bonds-graph.

- La deuxième question consiste à définir les classes des objets bond-graphs

(définition du modèle Bond-graph).

V.2.Principes et Concepts :

V.2.1.Principes :

Pour pouvoir adapter le langage Bond-graph dans la modélisation des systèmes

d’informations, nous posons deux principes :

u Principe 1 : L’information est une forme d’énergie dont les manifestations duales sont les données et les traitements (Effort=Traitements, flux=Données). u Principe 2 : L’échange d’information dans un système est assuré par un flux afin d’assurer la conservation totale d’information (système fermé).

Dans les systèmes physiques la puissance est définie comme le produit de deux

variables duales l’effort et le flux. La signification de ce postulat dans les systèmes

d’informations est simplement que tout traitement peut générer des données en sortie



qui seront utilisées par la suite pour d’autres traitements et vice-versa (action-réaction).

Dans ce cas on peut représenter l’information par le couple (Effort, Flux).

V.2.2.Concepts : L’architecture générale d’un système modélisé par les Bond-Graphs doit répondre à une

catégorisation des objets du système selon leur rôle. On peut distinguer (Voir Fig. V.1) :

- des objets source

- des objets de stockage (et de restitution complète ou partielle)

- des objets de dissipation (filtrage des informations)

- des objets de transformations

- des détecteurs ou puits

- des objets jonction qui garantissent la communication.

Sources

Stockage Structure Transformateur

I, C, R de Jonction TF

GY

Détecteurs ou puits

Fig. V.1

D’après la figure V.1, on peut remarquer les points suivants :

A/ Le modèle Bond-Graph peut représenter tous les différents types d’objets d’un

système (chaque objet possède un rôle) et qui sont classifiés en topologie objet comme

Actifs /Passifs.

Un objet actif est un objet qui contient sa propre tâche de contrôle, il est autonome,

c'est-à-dire qu'il a la capacité d'agir sans l'intermédiaire d'opérations externes (déclenchées par



l’environnement ou par d'autres objets) venant l'activer. L’objet actif n’a pas besoin

d’attendre un message, il réagit de lui-même à son environnement.

Les SGBDOO actifs existants définissent différemment la notion d’évènement. Le seul

point commun concerne l’origine d’un évènement. Un évènement peut être déclenché soit

suite à une modification de la base de données (BD), soit par l’horloge système, soit par une

application externe à la BD (interface utilisateur, application couplée à la BD). L’origine

« modification de la BD » englobe tous les objets de la base. Ainsi, un objet peut être sensible

à sa propre modification. Nous dirons que l’évènement peut alors être externe à l’objet ou lui

être interne.

L’activité d’un objet modélise un comportement interne ou externe (Fig. V.2). Lorsqu’un

objet actif détecte un évènement, il doit réagir. Cette réaction le concerne souvent lui-même:

exécution de ses propres méthodes. Mais l’objet peut aussi stimuler le comportement d’autres

objets, par l’intermédiaire du mécanisme d’envoi de messages ou en déclenchant

explicitement d’autres évènements. Ce qui permet de modéliser un comportement

inter- objets.

Dans les SGBDOO Actifs étudiés, l’activité des objets est modélisée soit par des triggers,

soit par des règles ECA [Fet&Berg 95].



Un Objet passif, au contraire ne fait que réagir à des demandes explicites qu'il reçoit.

Dans un environnement multitâche, cette typologie objet actif/objet passif peut être

raffinée :

* Un objet séquentiel est un objet passif tel que un seul objet peut agir sur lui à

un instant donné;

* Un objet bloquant est un objet passif tel qui plusieurs objets sont susceptibles

d’agir sur lui en même temps;

* Un objet concurrent est un objet actif qui contient plusieurs tâches de contrôle.

Un objet actif est un objet capable de réagir à des événements autres que les messages

qui lui sont destinés.

B/ La communication est le point fort de la méthode, les objets Bond-Graph ne

communiquent pas directement mais à travers des objets de type jonction. Elle diffère

de celle des modèles Orientés-objets basée sur le principe d’envoi de messages qui est

relativement pauvre (communication bilatérale, i.e on ne peut pas maîtriser une

opération complexe qui affecte l’état de plusieurs objets).

C/ La méthode BOND-GRAPH aboutit à un fonctionnement cohérent et tient compte de

l'aspect temps. Deux modèles sont induits :

* Le modèle statique qui décrit les objets et leurs propriétés structurelles.

* Le modèle dynamique qui décrit le comportement du système par intégration d'objets

d’opérations et d'évènements.

Les aspects syntaxique et sémantique de l'objet sont inclus dans la classe : * structure : - identificateur - état - attributs - contraintes * méthode : - participants (classes) - paramètres - pré-conditions - actions - post-conditions



Les éléments de stockage I, C, R apparaissent comme une base de données classique qui

peut être modélisée par n’importe quel modèle. Dans notre travail, on a choisi les types

abstraits de données.

V.2.3.Structures :

V.2.3.1 Structures des variables duales (Effort et flux) :

- Effort : D’après le principe 1, on a considéré que l’effort représente les traitements

(appel des méthodes). Dans les méthodes orientées-objet l’exécution des

méthodes se fait par l’envoi de messages. Un message est représenté sous la

forme suivante :

- un receveur r (un objet),

- une méthode m,

- des arguments éventuels a1, a2, …, an.

Dans nôtre cas, on peut considérer l’effort comme un message complexe

(composé de plusieurs messages) et qui a la forme suivante :

-un ensemble de receveurs r1, r2, …, rn. (des objets),

- des méthodes m1, m2,.., mn ,

- pour chaque méthode mi des arguments éventuels ai1, ai2, …, ain.

- Flux : La structure des données est composée de deux parties :

- Données représentées par des structures,

- Etat (Retour : Booléen).

V.2.3.2 Structures des éléments :

* La source d'effort représente les sources de traitements notées SE.

* La source de flux représente les sources de données notées SF.

Ces deux objets représentent les objets actifs du système.



V.2.3.2.1 Objet de dissipation d’information R (Filtre) :

A la sortie de cet élément les informations sont filtrées, on peut formaliser ceci par :

R (d1, d2,...., dn) = d'1,...,d'n où d'i inclue di, di et d'i sont respectivement les domaines

d'entrées et de sortie de chaque donnée.

Remarques :

- On utilise généralement ces objets dans les cas où on a besoin d’une partie de données.

- Si on a une inclusion stricte, on parle alors de filtrage ou de restriction.

- Si certains domaines d'i sont vides et les autres égaux aux domaines d'entrée, on parle

alors de projection.

En résultat : e = R (f) correspond à la sélection d'un opérateur d'après des données

d'entrées. Si R est un opérateur linéaire, on peut l'utiliser pour la logique combinatoire

ej = α1d1 + ... + αndn : ceci correspond par exemple à ce qui est connu en systèmes

d'information sous le nom de tables de décision. Inversement on peut avoir di = R (e1,..., en)

où les ei sont ordonnés.

V.2.3.2.2 Objet de Transformation TF :

Cet objet représente l'aspect calcul c-a-d procédure et algorithmes. Il est schématisé

par :

d t

======/ TF ======/ et il est caractérisé formellement par:

e f

(d1,...,dn) ----> (t1,...,tm)

(e1,...,ek) ----> (f1,...,fl)

ti = TFdi(d1,...,dn) i= 1,...,m

fj = TFej(e1,...,ek) j= 1,..., l



TFd est l'ensemble des formules qui spécifient les opérations entrées/sorties.

TFe est l'ensemble des règles de gestion qui prennent la forme d'un système de

production : ces règles modélisent la réaction aux évènements [Haf 93].

V.2.3.2.3 Objet Gyrateur GY : Dans les systèmes physiques, Le Gyrateur représente les phénomènes de couplage entre

les différents domaines de la physique, par exemple : passage du domaine électrique au

domaine mécanique.

e1 e2 ¦ e1=rf2

======/ GY ======/ ¦ e2=rf1

f1 f2

On peut avoir deux formes :

1 / ¦ e1=rf2 ici on f1 et f2 comme données pour GY

¦ e2=rf1

2 / ¦ f2 = (1/r) e1

¦ f1 = (1/r) e2 ici on a e1 et e2 comme données pour GY

Dans les systèmes d'informations, on a remarqué que l'objet Gyrateur permet de créer

une interface entre deux systèmes d'information différents. De plus, l’échange d’informations

se fait d’une façon spontanée et simultanée.

Remarque :

D’après l’équation du gyrateur GY, on peut remarquer que le gyrateur

possède des règles qui permettent de transformer des flux de données en traitements. Il joue

le rôle d’un traducteur.

Exemple :

Par exemple, le gyrateur permet de faire une interface entre le service

Comptabilité et le service paie, ou le service comptabilité et le service commercial.

Le Microprocesseur peut jouer le rôle de gyrateur.



V.2.3.2.4 Elément C : noté ===/ C

C'est l’objet d'accumulation d'information que l'on peut utiliser par la suite lors d'un

stockage. Il représente les trois aspects :

- Création - Suppression et modification (mise à jour) - Consultation. V.2.3.2.5 Elément I : noté ===/ I C'est l'élément dual de C, il représente l'évolution d'un objet dans le temps notamment

l'acquisition de nouveaux rôles.

V.2.3.3 Structure de Jonction : On rappelle qu'en théorie des BOND-GRAPHs, les objets communiquent par des liens

de puissance (bonds) qui portent les variables d’effort et de flux; cependant si l'une des

variables est négligeable le bond devient un signal.

Les jonctions vont jouer le rôle de relais ou de catalyseur d'information. On distingue

deux types de jonctions :

V.2.3.3.1 Jonction 0 (Parallèle) : Elle est caractérisée par son équation :

∑ αifi = 0 e1= e2 = .... = en

Si on exprime f1 en fonction des autres variables, ceci signifie que les objets 2,3,...,n

vont exécuter l'opération dictée par "1" qui recevra une données des autres objets; on

modélise ainsi un aspect important du parallélisme celui de la coopération.

- L'objet peut attendre (mode synchrone) la donnée f1 ou continuer son traitement

(asynchrone).

- L'objet auquel le message n’est pas destiné n'exécute pas l'opération (ne fait rien).

Donc la jonction 0 possède deux rôles :

* Elle diffuse les messages

* Elle reçoit les données envoyées par les autres opérations.



Elle possède comme structure interne les files d’attentes.

V.2.3.3.2 Jonction 1 (Série) : Elle est appelée jonction de données commune caractérisée par l'équation :

∑ αiei = 0 f2= f1, f3 =f1 , f4 = f1

Ici, on est obligatoirement en mode synchrone, l'objet doit attendre la fin de l'exécution

des autres processus. De plus, si le nombre de copies de la donnée est inférieur au nombre

d'objets présents dans la jonction, on est dans le cas d'un partage de ressources. On représente

ainsi le deuxième aspect qui est celui de la concurrence.

On remarque aussi que la fin de l’exécution de l’opération e1 dépend de la terminaison

des autres opérations.

La jonction 1 possède aussi les files d’attentes comme structure interne.

Remarques :

- Les files d’attentes utilisées dans la jonction 0 sont différentes que celles utilisées dans

la jonction 1.

Il y a théoriquement 8 types de files supportés :

* CBQ :Class Based Queue : sch_cbq

* CSZ : Clark-Shenker-Zhang :sch_csz

* TBF : Token Buckett Flow: sch_tbf

* FIFO : First In First Out : sch_fifo

* Priority : sch_prio

* TEQL : Traffic Equalizer : sch_tql

* SFQ : Stochastic Fair Queuing : sch_sfq

* RED : Random Early Detection : sch_red

* GRED : Generalized RED : donné en appliquant le patch ds-3.patch.gz



* DS_MARK : sch_dsmark Diffserv Marker

- Le nombre, les tailles et les types des files d’attentes représentent les paramètres des

jonctions 0 et 1.

- On peut aussi utiliser les objets Thread comme structure des objets jonctions.

Le comportement d'un BGSI est du type automatique, il est décrit par les relations

d'entrées/sorties (fonction de transfert en automatique); les objets ont aussi un état, ils

vérifient le principe d'encapsulation qui interdit la modification directe de leur état et assure

leur intégrité. Ce sont justement les caractéristiques de cet état dont on peut simuler

l'évolution dans le temps.

CAS PARTICULIER :

Le bond peut insister sur une seule variable seulement et est alors représenté par

une simple flèche : ---->

* On peut ainsi représenter les trois phénomènes connus en programmation :

1) La Séquence : objet1 ----> objet2

2) Le Choix : On peut l'écrire formellement : op =∑ αiopi

Dans ce cas, un seul αi vaut 1 et tous les autres sont égaux à zéro.

3) Itération : elle est identique à la représentation du choix sauf qu'il faut remplacer

'fixer ai' par 'cond' où cond serait la condition du tant que, avec

precondition : cond =vrai;

α1 = 1 αi = 0 quel que soit i±1 et à chaque itération

αi = 0

αi +1 = 1 i = 1,…,n-1

Ce qui veut dire que, tant que cond est vérifiée, exécuter la suite des opérations

op1,....,opn par les objets OB1,....,OBn

D'après l'équation caractéristique, on peut définir l'objet jonction 1 comme un objet qui

sert à synchroniser les efforts.



V.3. Définition du Modèle Bond-Graph :

V. 3.1. Démarche :

Dans les systèmes physiques la construction du modèle bond-graph est facile, elle suit

une méthode bien déterminée (par exemple dans les systèmes électriques, pour les éléments

qui sont en série alors on crée une jonction 1), par contre dans les systèmes d’information la

procédure devient assez compliquée. La théorie des bond-graphs pour les systèmes

d’information stipule une démarche descendante qui consiste à localiser les rôles des objets,

puis ascendante pour la construction du modèle conceptuel. La démarche que nous

préconisons est la suivante :

a - Premièrement, identifier tous les objets du système à modéliser,

b - Deuxièmement, spécifier chaque objet, c-à-d définir sa partie statique et sa partie

dynamique,

c - Troisièmement, donner à chaque objet du système un rôle,

d - Quatrièmement, identifier et classifier tous les évènements du système à modéliser

(décomposer les opérations complexes en opérations élémentaires).

e - Cinquièmement, trouver les relations de communications qui existent entre les

objets pour chaque niveau de décomposition, c-à-d trouver les jonctions qui existent

en commun.

f - si on a un système complexe alors il faut en définir les frontières.

V. 3.2. Définition du diagramme de classes : En se basant sur la section précédente bond-graph et le langage de simulation orienté-

objet modélica, on peut facilement remarquer deux choses :

La première est que le langage bond-graph n’est en sorte qu’une extension des méthodes

orientées-objets avec cependant un certain nombre de différences. Tout d’abord les objets sont

typés et possèdent un rôle évolutif, ensuite la communication entre eux ne se fait plus par

envoi de messages mais par un envoi d’informations qui peut prendre les deux formes duales :

le type donnée et le type traitement (effort–flux).

La deuxième est qu’on peut facilement déduire les classes du langage bond-graph dans

les systèmes d’informations (voire Fig. B1) où on peut considérer un objet bond-graph



comme un objet composé de plusieurs composants (Components). Ces composants peuvent

être des objets source (source d’effort SE et source de flux SF), des objets de stockages (C,I),

des objets de dissipation, des objets de transformation (transformateur TF, gyrateur GY) ou

des objets de jonction (jonction 0 et jonction 1). Dans ce cas on a une relation de composition

et une relation de spécialisation.

En se basant sur la notion de ports (interface), on peut aussi définir une autre hiérarchie

de classes (interface Bondport, interface OnePortPassive, interface TwoPortPassive, interface

OnePortEnergetic, etc. (voire Fig.B2)). Chaque classe est une spécialisation d’une autre classe

et peut avoir ses propres paramètres.



Le langage bond-graph permet l’héritage simple, mais à travers la notion des ports

(interfaces), on peut avoir une utilisation multiple comme dans le cas du langage JAVA.

V.4. Exemple d’application : V.4.1. Service d’impression dans un réseau : L’exemple traité dans cette partie est tiré du projet de réalisation d’un système

d’impression intégré dans ESUP-Portail de l’IFSIC de l’université de Rennes. Le système

d’impression est composé d’un serveur d’impression et une d’une application web (Voir Fig

4.1). Il s’appuie sur une base de données et un annuaire LDAP.



- Les clients : Les clients sont supposés très hétérogènes : • Des clients Unix (Linux, Solaris, …) ; • Des clients Windows (XP, 2000, NT, Me, 9x, …).

Pour accéder au service d’impression, les clients doivent être capables d’adresser une file d’attente de type LPD Unix, proposée par le serveur d’impression.

- Les groupes d’impression : Les imprimantes sont regroupées. Un groupe est défini par :

• Un identifiant • Un libellé, utilisé pour expliciter le groupe. • Le fait que l’on trace ou non :

o L’évaluation des ACEs d’impression ; o L’évaluation des règles de comptage ; o L’évaluation des règles de traçage ; o L’évaluation des règles d’attribution automatique des crédits.

- Les imprimantes : Une imprimante est définie par :

• Son identifiant • Son adresse IP ou son FQDN. • Son nom, utilisé pour expliciter l’imprimante. • Le groupe auquel appartient l’imprimante.



• Le fait qu’elle soit capable de compter le nombre de pages des impressions ou non. Si l’imprimante en est capable, les traces des impressions sur l’imprimante seront comptabilisées du nombre de pages imprimées.

- Les utilisateurs : Un utilisateur est défini par :

• Son identifiant • Son crédit d’impression, pour chaque groupe.

- Le serveur d’impression : Le serveur d’impression offre pour chaque imprimante cible une file d’impression de type LPD Unix, qui peut être utilisée par les clients du réseau :

• Sous Unix, avec un client traditionnel (client LPR basé sur un fichier printcap) ; • Sous Windows, en utilisant le service d’impression Unix fourni par MicroSoft.

Le serveur d’impression reçoit les travaux d’impression, et effectue pour chacun d’eux les opérations suivantes :

• Contrôle d’accès à l’imprimante cible ; • Envoi des données à l’imprimante et comptage du nombre de pages imprimées

(optionnel) ; • Traçage de l’impression ; • Diminution du crédit de l’utilisateur (optionnel).

- Le contrôle d’accès aux imprimantes : L'accès aux imprimantes via le système d'impression peut être restreint à :

• certains utilisateurs, par filtrage sur l'annuaire LDAP ; • certains clients, par filtrage sur les adresses IP ou le FQDN ; • certaines dates, semaines, et plages horaires.

Le contrôle d’accès est exprimé à l’aide d’ACLs (Access Control Lists), stockées dans la base de données, et gérées grâce à l’application web. Le serveur détermine, pour chaque travail d’impression, s’il doit être autorisé ou refusé en fonction de :

• L’imprimante cible ; • L’uid de l’utilisateur ; • Le client d’origine (la machine depuis laquelle l’utilisateur a émis le travail

d’impression) ; • La date et l’heure du travail d’impression.

- Le comptage des impressions Une des fonctionnalités majeures du système d’impression est la possibilité de gérer des crédits d’impression par utilisateur. Des règles de comptage déterminent si une impression doit être conditionnée par la disponibilité des crédits de l’utilisateur en fonction :



• De l’imprimante cible ; • Du client d’origine du travail d’impression ; • De l’uid de l’utilisateur.

- L’attribution automatique de crédits d’impression Afin de ne pas devoir entrer les crédits des utilisateurs pour chaque utilisateur et chaque groupe, le système d’impression est muni de règles d’attribution automatique de crédits. De cette manière, l’introduction d’un nouvel utilisateur ne nécessite aucune intervention.

- Traçage des impressions Les impressions des utilisateurs sont tracées dans la base de données, et sont ainsi consultables ultérieurement à l’aide de l’application web. Pour chaque travail d’impression, le serveur trace :

• L’imprimante cible ; • L’utilisateur ; • Le client ; • Le nom et la taille du travail d’impression ; • Le fait que l’impression a été autorisée ou non ; • Si l’impression a été refusée, la raison du refus ; • Si l’impression a été acceptée, le nombre de pages de l’impression (si l’imprimante

sait compter le nombre de pages imprimées), ainsi que le crédit de l’utilisateur avant et après l’impression ;

• La date et l’heure d’impression.

- L’application web L’application web est accessible à tous les utilisateurs, après authentification auprès du serveur CAS. Elle leur permet :

• De connaître leurs crédits d'impression ; • De consulter leurs traces d'impression ; • Eventuellement de consulter la liste des imprimantes auxquelles ils ont accès.

Des utilisateurs, locaux à l'application, ont des droits privilégiés :

• Les administrateurs de l’application. • Les gestionnaires de groupe, dont le rôle est d’administrer un ou plusieurs groupes.

Le schéma équivalent du système d’impression dans le langage bond-graph est défini comme suit (Fig. B1) :



Nb : On peut remarquer que c’est le serveur d’impression qui prend en charge la gestion

des objets jonctions dans le modèle bond-graph équivalent.

Lorsqu’un client veut imprimer, il transmet les données (f1) à la jonction 1 (1) qui est une

file d’attente et qui joue le rôle d’un planificateur. Ce dernier transmet à son tour ces données

à un système de filtrage (R : Filtre).

Le processus de filtrage fonctionne en recevant des données pré-formatées avec six

arguments : le nom de la file d’impression ou du filtre (d’impression), l’identifiant de la tâche

demandant l’impression du document, le nom d’utilisateur, le nom du processus, le nombre de

copies à imprimer, les options d’impression, le nom du fichier à imprimer (bien qu’il ne soit

pas nécessaire s’il a été redirigé depuis l’entrée standard). Il détermine ensuite le type de

données qui ont été envoyées et le type de filtre (traitement e2) associé grâce à la base de

données MIME (Multipurpose Internet Mail Extensions).

Le planificateur (1), après avoir reçu un signal (e3) de la part du module transformateur

TF (2), lui transmet les données afin qu’elles soient être converties en trames reconnues par les

imprimantes.

Le module Transformateur TF (2), après transformation, transmet les données à une autre

jonction 1 (3) qui est la file d’attente finale avant que le document ne soit imprimé. Avant

d’envoyer les données vers l’imprimante, le système demande des renseignements concernant



l’utilisateur propriétaire du document (utilisateur autorisé à imprimer non) en lançant le

message (e7) qui lance à son tour une même requête (e8=e9) qui sera stockée dans une file

d’attente temporaire de la jonction 0 (4) et reçoit l’information (f7) qui est la somme de

l’information donnée par la base BD (f9) et l’information donnée par l’annuaire LADP (f8).

Pour les utilisateurs qui veulent :

• Connaître leurs crédits d'impression ; • Consulter leurs traces d'impression ; • Eventuellement consulter la liste des imprimantes auxquelles ils ont accès.

A partir de l’application Web qui se représente comme une source de flux (SF), se fait la

transmission de la requête sous forme de données (f13) à une jonction 1 (6) (file d’attente) qui,

à son tour, les transmet à un serveur Web qui traite les types de données en utilisant les bases

de données MIME et définit le code de traitement approprié en sortie.

L’objet gyrateur GY (5) est utilisé ici pour la conversion entre les différents protocoles de

communication d’internet. Il ressemble beaucoup à l’objet SOAP ((Simple Object Access

Protocol).

V.5. Avantages et limites :

V.5.1. Avantages : F Un bon Contrôle au niveau des points d’accès aux objets : * La méthode prévoit les objets de contrôle dès la phase de conception. * Le contrôle se fait à plusieurs niveaux. * Le rôle des objets est bien défini. F Une bonne communication (Interactions, Synchronisation) à travers le réseau et non plus une communication bilatérale. F Schéma Conceptuel plus riche (Objets : SF, SE, C, I, R, 0, 1, GY, TF) F Dans un même schéma, on peut représenter les deux sortes de flux : * Flux de données. * Flux de traitements.



F Le schéma logique est tiré directement à partir du schéma conceptuel. F L’implémentation est modulaire. F La méthode peut étudier des systèmes hétérogènes et définir les frontières entre les systèmes à partir des objets GY et TF. F La méthode BGSI possède un formalisme --> c’est une méthode formelle. V.5.2. Limites : F L’inexistence d’une méthode (ensemble de règles) pour l’affectation des rôles aux objets. F Le manque d’outils de validation (?) --> Le seul outil disponible est la simulation. F Le manque d’algorithmes d’optimisation du modèle conceptuel. F Les applications pratiques conduisent souvent à des réseaux de taille trop importante rendant leur interprétation impossible pour un observateur. V.6. Tableau comparatif entre les méthodes O.O (UML) et BGSI : Comme il a été vu dans la section concernant la méthode UML, les classes

d’analyse peuvent être réparties en trois catégories :

1- Les objets interfaces : ils représentent l’interface entre l’acteur et le système. Des

exemples classiques en sont les écrans de saisie, ou dans le cas d’applications Web,

des pages Web complètes.

2- Les objets entités : ce sont des objets décrits dans les cas d’utilisation (mais qui sont

pérennes, les utilisateurs, les documents, les groupes, les données, etc. d’une base de

données sont des objets entités.

3- Les objets contrôle : ils représentent les processus, c’est-à-dire les activités système

assez significatives pour être nommées, telles que le calcul du nombre d’utilisateurs,

les vérifications, les suppressions, les mises à jours, etc. Les objets contrôle

dirigent les activités des objets entité et interface.



De plus les associations entre objets obéissent aux règles ci-dessous :

1- Les acteurs n’interagissent qu’avec des objets d’interface. 2- Les objets entité n’interagissent qu’avec des objets contrôle.

3- Les objets contrôle interagissent avec tous les objets, y compris des interfaces d’objets contrôle.

On peut remarquer les points suivants :

- Les objets d’interface dans UML ne sont rien d’autre que les ports dans le langage bond-graph.

- Les objets contrôle sont représentés par les objets jonction 0, jonction 1, TF et GY.

Le tableau suivant illustre une brève comparaison entres les méthodes O.O et le langage bond-graph.

Concepts & Propriétés

L’approche BGSI L’approche O.O

Communications

A travers les jonctions (communication à travers un réseau )

Par envoi de messages (communication bilatérale)

Objets et méthodes

Oui Oui

Encapsulation

Oui Oui

Classes et types

Oui Oui

Héritage

Héritage d’utilisation des méthodes et des attributs

Héritage des méthodes et des attributs

Surcharge sémantique

Oui Oui

Objets Complexes

Oui Oui

Identité d’objet

Oui Oui

Modularité

Oui Oui



V.7. CONCLUSION : Ce chapitre montre que les bond-graphs qui sont un outil puissant pour la modélisation

des systèmes physiques peuvent être aussi adaptés pour la modélisation des schémas généraux

de bases de données où l’avantage est de répondre aux préoccupations dynamiques de la

communication ainsi que de la maîtrise du processus de modélisation qui se fait sur la base de

la simulation. De plus la définition de la structure de classes dans ce langage pour les

systèmes d’information peut être facilement générée en se basant sur des langages de

modélisation et de simulation orientés-objet dans les systèmes physiques comme dans le cas

du langage modélica.


Conclusion Générale et Perspectives 69

Comme nous l’avons déjà précisé, cette thèse fait partie du projet ¨ L’approche Bond-

graph et la modélisation des systèmes d’information : nouvelle approche orientée

communication ¨. L’objectif principal recherché est de présenter l'intérêt d'essayer d'appliquer

la méthodologie Bond-Graph, qui représente à l'heure actuelle la méthodologie de

modélisation la plus élaborée en ce qui concerne les systèmes physiques et dynamiques, à la

spécification des systèmes d'information.

Cette nouvelle théorie appliquée aux systèmes d'information va permettre non seulement

le comportement dynamique des objets pris individuellement mais aussi et surtout un

comportement dynamique d'ensemble ce qui faciliter sa simulation.

La communication entre les objets est le point fort de la méthode. En effet elle diffère de

l'orienté-objet, et se fait à l'aide de la structure de jonction.

L'approche BOND-GRAPH peut être utilisée avec d'autres méthodes de modélisation

pour modéliser l’aspect dynamique des systèmes.

Enfin, nous pouvons dire que notre travail est loin d’être complètement achevé. De ce

fait, plusieurs extensions et perspectives futures restent à envisager. Les plus importantes

d’entre elles peuvent être résumées ainsi :

F Elever un peu le degré d’abstraction (étude théorique) en s’intéressant aux résultats

intéressants des Bond-Graphs dans les systèmes physiques et dynamiques, par exemple

* La notion de contrôlabilité et d’observabilité,

* L’étude de la causalité,

* la définition de l’état d’un système, etc.

F Définir les règles de passage du flux de données en traitements et vice-versa qui se

trouvent dans l’objet gyrateur GY.

F Modéliser des bases de données et de faire une étude comparative avec les autres méthodes de modélisation (l’approche O.O, la méthode JSD, les réseaux de Petri, etc.).


Conclusion Générale et Perspectives 70

F Générer une spécification exécutable à partir d’une spécification graphique. F Définir un langage formel pour la modélisation des protocoles de communications. F Concevoir et modéliser des systèmes d’exploitation multi-tâches (système LAN). Remarque : F Ces axes de recherches cités précédemment peuvent être traités de façon parallèle ou en série.

Finalement, on peut dire que l'évolution de la théorie des BOND-GRAPH dans les

systèmes d'information peut prendre la même allure que celle des réseaux de pétri (des

réseaux ordinaires, réseaux à prédicats, réseaux colorés etc.).

Nous tenons enfin à signaler les difficultés que nous avons rencontrées pour

travailler dans cet axe de recherche, à commencer par l’absence quasi-totale de

références qui traitent le sujet de cette thèse.


Bibliographie 71

BIBLIOGRAPHIE SUR LES BOND-GRAPHS [Abdel&Slim 92]: M. Abdelfettah et B. Slimane ¨Construction d’un interpreteur Bond-Graph pour la génération d’un système équationnel ¨.Memoire, université Oran Sénia, 1992. [Abed 96] : Abed Bahtou B. "Modélisation des Systèmes d'Information à l’aide des Bond-Graphs", 1st Regional Seminar on Information Systems, 12-13 March 1996, University of Oran Es-Sénia, Oran (Algeria). [Abed&Rah&Haf 97]: Abed bahtou B. , Rahmouni M.K. , Haffaf H. “Modelling Dynamics In Information Systems By Using The Bond-Graphs Approach: A New Communication Oriented Approach” Séminaire international, Mai 1997, Computer Science and Information Systems Dept. Philadelphia University, Amman, Jordan. [Bou& BD 93]: T. Boualem & S. Abdelhamid Ëtude des propriétés structurelles d’un système dynamique (Approche par Bond-Graph ¨. Memoire, université Oran Es-Sénia, 1993. [F.Cel&Ang 05]: François E. Cellier & Àngela Nebot ¨The Modelica Bond Graph Library¨, proceedings of the 4th International Modelica Conference, Hamburg March 7-8 2005, Gerhard Schmitz (editor) [F.Cel&Gre 03]: François E.Cellier & Jurgen Greifeneder Broenink ¨ Object-oriented modelling of convective flows using the dymola thermo-bond graph Library¨ Proc ICBGM 03,Orlando, FL, January 2003. [Haf 93] : Hafid Haffaf Öutil Bond-Graph pour la modélisation des systèmes physiques et Dynamique : nouvelle approche pour les systèmes d’information ¨. Thèse de magister, Juin 1993. [Haf 96] : Hafid Haffaf ¨Le concept d’état dans un B.G.S.I ¨. 1st regional seminar sur les Systèmes d’information ,̈ EX-IAP, université d’oran (es-sénia) , Mars 1996. [Jan F 97] : Jan F. Broenink ¨Bond-Graph Modeling In Modelica ¨ European Simulation Sumposium 1997.

Bibliographie 72

[Jan F 99]: Jan F. Broenink Öbject-oriented modelling with bond graphs and Modelica ¨ Simulation Series,Vol 31,No1,pp163-168,IBSN 1-56555-155-9, San Francisco, Janvier 1999. [Pet F.&Vad 98]: Peter Fritzson & Vadim Engelson ¨ Modelica - A Unified Object-Oriented Language for System Modeling and Simulation¨ E. Jul (Ed.): ECOOP’98, LNCS 1445, pp. 67-90, 1998. c Springer-Verlag Heidelberg Berlin 1998. [Mar 06 ]: Mariana C. D’Abreu ¨ MCD++ - an extension to N-CD++ for continuous systems simulation using Modelica¨ , 2006. [Mar&Hild 02]: Martin Otter & Hilding Elmqvist ¨Modelica - Language, Libraries, Tools, and Conferences¨ Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR), Oberpfaffenhofen, Germany and Dynasim AB, Lund, Sweden, Avril 2002. [Mar&Gab 03]: Mariana C. D’Abreu & Gabriel A. Wainer ¨Models For Continuous And Hybrid System Simulation¨ Proceedings of the 2003 Winter Simulation Conference. [Ska&Sor 05]: Skander Turki & Thierry Soriano ¨ A SysML Extension for Bond Graphs Support ¨ 2005. [Nev 94 ]: Neville Hogan ¨ Integrated Modeling of Physical System Dynamics ¨ 1994. [Mod 00]: Modelica Association ¨ModelicaTM - A Unified Object-Oriented Language for Physical Systems Modeling ¨ Language Specification Version 1.4,Decembre 2000

Bibliographie 73

BIBLIOGRAPHIE SUR LES MODELES UML [Acc 02]: Projet Accord ¨Formalisation UML du modèle abstrait d’assemblage de composants¨ Novembre 2002.

[Boub 05] : Boubker Sbihi ¨Vers une implémentation d’un Système d’Enseignement à Distance basé sur le filtrage ¨., juillet 2005. [Des 04] : Philippe Desfray ¨Réussir la modélisation UML des phases amont techniques de pré- modélisation : un pont vers le modèle ¨,Softeam 2004. [Franck 04] : Franck chauvel ¨Génération de code à partir de modèles UML ¨. DEA d’informatique Rennes, juin 2004. [Greg 04 ]: GregoryLoichot ¨ Concepts et langages orientés objets ¨ notes de cours mars 2004. [Oliv 04] : Olivier Sigaud Ïntroduction à la modélisation orientée-objets avec UML ¨. support du cours « Génie logiciel et programmation orientée-objet » de l’ENSTA, 2004. [Oliv C 03] : Olivier Capuozzo ¨http://www.compuserve /UML - Les quatre types de relations.htm¨ Résumé 04-avril 2003. [Phil 04] : Philippe Desfray ¨Réussir la modélisation UML des phases amont ¨. © Softeam 2004

Bibliographie 74

BIBLIOGRAPHIE GENERALE [Abdi 95] : Abdi Mustapha Kamel Öutil d’aide à la spécification et conception des systèmes d’information¨. Thèse de magister, Avril 1995. [Abed&Abd 92]: Abed B. Bouazza & Abdelaziz Aek ¨Conception et réalisation d’une base données orientée types abstraits de données ¨. Mémoire d’Ingénieur , Octobre 92. [Bee&Ber 77] : C. Beeri & P.A Berstein ¨Computational problems related to the design of normal form relation shcemas ¨. ACM Transactions on database systems, march 1979. [BOU86] : M. Bouzeghoub ¨SECI : Un système Expert en conception de systèmes d’information, Modélisation conceptuelle de schéma de bases de données ¨. Thèse de Doctorat d’université PARIS VI, 1986. [Cod 72] : E.F Codd ¨Further normalization of the database relational model ¨. In Database Systems, Rustin et. , Prentice Hall Englewood Cliffs 1972. [Che 76] : P.S. Chen ¨The entity relationship model : Towards a unified view of data ¨. ACM Transactions on database systems, Vol 1, N°1, 1976. [CHA&LOC 83] : E.F Chan & F.H. Lochovsky Ä graphical database design aid using th E/R Model ¨. In proc. Of Int. Conf. on ERA, Chen (ed), North Holland 1983. [Fag 77] : R. Fagin ¨Multivalued dependencies and a new normal form for relational databases ¨. ACM Transaction o ndatabase systems, vol 2 , Nb 3 , September 1977. [Fet&Berg 95] : Fethi bounaas & Pierre Bergues ¨L’activité : un outil pour une évolution déclarative ¨. Ingénierie des Systèmes d’information vol.3-n°2-3/1995, Inforsid 1995. [Flo 90] : A. Flory & C. Rolland ¨Nouvelles perspectives des systèmes d’information ¨. Sélection d’articles. Editions Eyrolles, Paris 1990. [Ghom 96] : Ghomari abdelghani ¨Modélisation et Mise en œuvre de la dynamique des systèmes d’information à l’aide des réseaux de petri ¨. Thèse de magister, Mars 1996.

Bibliographie 75

[Ghom&Aoum 96] : Ghomari A. & Aoumeur ¨Modélisation des systèmes d’informationdistribué en utilisant les Réseaux de petri de haut niveau ¨. 1st regional seminar sur les Systèmes d’information¨, EX-IAP, université d’oran (es-senia) , Mars 1996. [Hab 95] : Henri Habrias ¨Les spécifications formelles pour les systèmes d’information, quoi ? pourquoi ?comment ? ¨. Ingénierie des Systèmes d’information vol.3-n°2-3/1995, Inforsid 1995. [Haf 94] : Hafid Haffaf ¨Pourquoi une vue systémique des systèmes d’information ? ¨. Rapport technique 02/94 ¨ Journées Systèmes d’information ,̈ EX-IAP, université d’oran (es-sénia) , décembre 1994. [Jac 83] : M. Jackson ¨Jackson system development ¨. New York Prentice Hall, 1983. [Kha 05]: Oualid KHAYATI ¨Modèles formels et outils génériques pour la gestion et la recherche de composants¨ Thèse de Doctorat spécialité « système d’information », institut Polytechnique de Grenoble, décembre 2005. [Khiat 94] : Abdelouahab Khiat Ëvaluation des systèmes d’information ¨. Rapport technique 02/94 ¨ Journées Systèmes d’information¨, EX-IAP, université d’oran (es-sénia) , décembre 1994. [KOU 90] : B. Kouninef ¨Les explications dans les systèmes OICSI¨. Thèse de Doctorat d’université PARIS VI, 1990. [Loukil 96] : Lakhdar Loukil ¨Perception des problèmes de flux dans les systèmes d’information ¨. Thèse de magister, Mars 1996. [Oll&al 90] : T.W. Olle & J. Hagelstein, C. Rolland ¨Méthodologies pour les systèmes d’informations – Guide de référence et d’évaluation ¨, Afcet, IFIP , Dunod informatique, Paris 1990. [PRO 89] : C. Proix ÖICSI : un outil d’aide à la spécification des systèmes d’information, Spécification et réalisation ¨. Thèse de Doctorat d’l’université, PARIS VI, Décembre 1989.

Bibliographie 76

[Rol 86] : C.ROLLAND Ïntroduction à la conception des systèmes d’information et panorama des Méthodes disponibles ¨. Génie logiciel, Agence de l’informatique, N°4, Avril 1986. [Ros 77] : D.T Ross & K.L Schoam ¨Structured analysis for requirement definition¨. IEEE trans. on software engineering, 1977. [Rouane 98] : Mohamed Amine Rouane hacène ¨Conception d’un environnement de programmation multi paradigmes : application à la simulation à base de connaissances ¨. Thèse de magister, université d’Oran Es-Sénia, Mars 1998. [TAM&al 83] : R. Tamassia & C. Batini & M. Talamo Än algorithm for automatique layout of E/R diagrams ¨. In proc. Of E/R approach to software engineering, Davis and al (ed), Elsevier sce, North Holland, 1983 [Tar 91] : H. Tardieu & A.Rochelfeld, R.Colleti ¨La méthode MERISE : Principes et outils ¨. Edition d’organisation, Paris, 2ème édition, 1991. [TRO&al 88] : O. De Troyer & R.Meersman & P. Verlinden ¨RIDL on the CRIS case: AWorkbench for NIAM ¨. Elservier Science Publisher B.V (North Holland). Copyright IFIP, 1988. [WAL 88] : M. Walfard ¨PRECISE* PC-LAST : Un outil Associé à la méthode NIAM ¨. Actes Des 2ème journées LIANA sur la ¨ Pratique des méthodes et outils logiciels d’aide à la conception des systèmes d’information ¨, Nantes, Septembre 1988.

Documents

FACULTE DES SCIENCES DEPARTEMENT INFORMATIQUE …La présente thèse s ˇinscrit dans le cadre d ˇune problématique plus large qui fait l ˇobjet d ˇun projet de recherche intitulé