%&LaTeX
% Flux.tex

\documentclass{artflux}
\usepackage[T1]{fontenc}		% N{\'e}cessaire avec french si le moteur n'est pas MlTeX
\usepackage{french}					% Tout ce qu'il faut pour le fran\c{c}ais...
\usepackage{graphics}				% Pour nos figures EPS

% Quelques commandes pour notre article
\newcommand\button[1]{\fbox{\textsc{\footnotesize #1}}}
\newcommand\cplusplus{C\raisebox{.3ex}{\footnotesize ++}}
\newcommand\occplusplus{\textsc{occ\raisebox{.2ex}{\footnotesize ++}}}

% A para{\^\i}tre dans Flux num{\'e}ro 314
\fluxnum{314}

\title{Objets et Programmation Synchrone}

\authorpict{Fr{\'e}d{\'e}ric Boulanger}{Fred.eps}
\authorpict{Guy Vidal-Naquet}{Guy.eps}

% On peut aussi utiliser la ligne suivante si l'on n'a pas de photo :
% \author{Fr{\'e}d{\'e}ric Boulanger\and Guy Vidal-Naquet}

% Le r{\'e}sum{\'e} :
\abstract{%
L'approche objet apporte la facilit{\'e} de structuration, d'abstraction, 
de r{\'e}utilisation et d'{\'e}volution.  L'approche r{\'e}active synchrone permet 
la description formellement rigoureuse des syst{\`e}mes r{\'e}actifs (e.g.  
syst{\`e}mes de contr{\^o}le-commande) , ce qui autorise des preuves de 
correction logique.

Cet article propose une combinaison de ces deux approches et introduit 
la notion d'{\em objet synchrone}.  Divers probl{\`e}mes relatifs aux 
objets et au synchronisme sont mis en {\'e}vidence.  Un environnement 
complet de d{\'e}veloppement, en cours de r{\'e}alisation, est pr{\'e}sent{\'e}.  Il 
dispose de compilateurs, de simulateurs et d'interfaces vers des 
syst{\`e}mes de preuves formelles.  Cette plate-forme devrait contribuer {\`a} 
l'am{\'e}lioration de la qualit{\'e} des logiciels, en particulier dans le 
domaine du temps r{\'e}el.%
}

% L'article proprement dit :
\begin{document}
\sloppy
\maketitle

\section*{Introduction}
La notion {\em d'objet} est un bon paradigme pour la programmation des 
{\em syst{\`e}mes complexes}.  L'un des principaux bienfaits de l'approche 
par objets est l'am{\'e}lioration de l'architecture des programmes.  
Celle-ci est obtenue d'abord par une d{\'e}composition modulaire 
rigoureuse reposant sur les entit{\'e}s r{\'e}elles manipul{\'e}es par 
l'application (les objets); puis, pour chacune de ces entit{\'e}s, par la 
s{\'e}paration entre leur interface (abstraite) d'{\em utilisation} et les 
d{\'e}tails de leur {\em impl{\'e}mentation}.  Des m{\'e}canismes puissants comme 
la composition, l'h{\'e}ritage, le polymorphisme permettent de prendre 
avantage de cette s{\'e}paration et de doter le syst{\`e}me de propri{\'e}t{\'e}s 
d'extensibilit{\'e} et de r{\'e}utilisabilit{\'e}, favorisant son {\'e}volution et sa 
maintenance.

Jusqu'{\`a} pr{\'e}sent, la programmation par objets a {\'e}t{\'e} surtout appliqu{\'e}e 
aux {\em syst{\`e}mes transformationnels}, c'est-{\`a}-dire {\`a} des syst{\`e}mes qui 
effectuent leurs traitements {\`a} un rythme choisi par eux-m{\^e}mes.  {\`A} 
l'oppos{\'e}, il existe des syst{\`e}mes dits {\em r{\'e}actifs} 
qui sont en relation permanente avec leur environnement et dont le 
rythme d'{\'e}volution est impos{\'e} par l'ext{\'e}rieur.  De nombreux syst{\`e}mes 
r{\'e}actifs sont {\'e}galement des syst{\`e}mes {\em temps-r{\'e}el} : leurs 
r{\'e}actions sont contraintes temporellement.

La {\em programmation synchrone} a {\'e}t{\'e} introduite pour 
r{\'e}pondre aux exigences de la programmation r{\'e}active.  Les langages 
synchrones ont des s{\'e}mantiques math{\'e}matiques simples et rigoureuses.  
Il a donc {\'e}t{\'e} possible de d{\'e}velopper des compilateurs s{\^u}rs et 
efficaces.  De plus la {\em correction logique} des programmes peut 
{\^e}tre {\'e}tablie formellement.  Toutefois, les langages synchrones sont 
essentiellement d{\'e}di{\'e}s au contr{\^o}le.  Ils s'appuient sur des langages 
classiques pour la manipulation des donn{\'e}es, et n{\'e}cessitent une {\em 
machine d'ex{\'e}cution} pour ex{\'e}cuter le code 
produit par leur compilateur.

Les recherches pr{\'e}sent{\'e}es ont pour but de {\em combiner approches 
synchrones et approches par objets}, afin de pouvoir programmer des 
{\em syst{\`e}mes complexes} o{\`u} interviennent des aspects r{\'e}actifs et 
transformationnels (par exemple, la production et la distribution 
d'{\'e}nergie).

\section*{Caract{\'e}ristiques des \\ approches par objets}
\label{sec:objets}
L'approche par objets permet de consid{\'e}rer le syst{\`e}me {\`a} d{\'e}velopper 
comme une collection d'objets discrets qui coop{\`e}rent.  Ces objets sont 
des abstractions de sous-syst{\`e}mes qui int{\`e}grent {\'e}tats (donn{\'e}es) et 
op{\'e}rations sur ces donn{\'e}es.  Les donn{\'e}es sont {\em encapsul{\'e}es}, 
c'est-{\`a}-dire qu'on ne peut y acc{\'e}der directement, mais seulement par 
l'interm{\'e}diaire des op{\'e}rations --- on dit aussi {\em m{\'e}thodes} --- de 
l'objet.  Ainsi, chaque objet est-il responsable de ses propres 
donn{\'e}es, et par l{\`a} m{\^e}me, de son propre {\'e}tat et de son propre 
comportement.  La liste des m{\'e}thodes fournit l'interface d'{\em 
utilisation} de l'objet, seule information que les autres objets ont 
besoin de conna{\^\i}tre.

Dans les m{\'e}thodologies d'analyse et de conception par objets ({\em 
e.g.} OMT) apparaissent trois mod{\`e}les diff{\'e}rents :
\begin{enumerate}
\item le {\em mod{\`e}le objet} proprement dit, souvent appel{\'e} {\'e}galement 
{\em mod{\`e}le de classes}, qui d{\'e}crit les objets du syst{\`e}me, leur 
interface d'utilisation, et les relations (statiques) qui existent 
entre eux;
\item un {\em mod{\`e}le dynamique} qui pr{\'e}cise d'une part les interactions
entre les objets, d'autre part le comportement (r{\'e}actif) de chaque objet
individuel;
\item un {\em mod{\`e}le fonctionnel} qui traite des transformations de
donn{\'e}es.
\end{enumerate}

Un des attraits majeurs de l'approche objet est son pouvoir 
d'abstraction : elle permet d'exprimer {\em ce qui} change dans un 
syst{\`e}me sans n{\'e}cessairement pr{\'e}ciser {\em comment} s'effectuent ces 
changements.  L'ajout ou le retrait d'objets est relativement facile {\`a} 
prendre en compte.  De m{\^e}me la modification locale d'un objet est 
ais{\'e}e si cette modification ne met en cause ni l'interface publique de 
l'objet, ni ses relations avec les autres objets.  Ainsi 
l'incr{\'e}mentalit{\'e} du d{\'e}veloppement (ajout d'objets), la r{\'e}utilisabilit{\'e} 
(des objets) et leur maintenabilit{\'e} (modifications locales) peuvent 
elles {\^e}tre renforc{\'e}es.


\section*{Les objets synchrones}
L'approche synchrone des syst{\`e}mes r{\'e}actifs est similaire {\`a} l'approche 
objet pour les syst{\`e}mes transformationnels en ce qu'elle permet de 
d{\'e}crire des syst{\`e}mes complexes en combinant une multitude de 
comportement temporels simples.

Les interactions complexes qui existent entre sous-syst{\`e}mes parall{\`e}les 
communicants sont repr{\'e}sent{\'e}es par des diffusions instantan{\'e}es de 
signaux (abstraction des communications).  La composition synchrone 
peut {\^e}tre d{\'e}finie de fa\c{c}on rigoureuse et poss{\`e}de des propri{\'e}t{\'e}s 
remarquables comme le caract{\`e}re d{\'e}terministe de la composition 
parall{\`e}le.

Une application peut faire appel {\`a} des {\'e}l{\'e}ments transformationnels et 
{\`a} des {\'e}l{\'e}ments r{\'e}actifs synchrones (e.g.  r{\'e}gulation et supervision de 
cette r{\'e}gulation).  L'approche objets permet d'int{\'e}grer les {\'e}l{\'e}ments 
de ces deux domaines {\em en encapsulant le code synchrone dans des 
objets}.  Les modules synchrones se pr{\^e}tent bien {\`a} cette encapsulation 
car ils ne communiquent avec l'ext{\'e}rieur que par leurs signaux et se 
pr{\'e}sentent donc comme des bo{\^\i}tes noires.  Il est alors possible de 
combiner approche objet et approche synchrone.

\subsection*{Classes synchrones}
La premi{\`e}re {\'e}tape est donc de transformer un module synchrone en 
une classe, que nous dirons synchrone. Les instances de cette classe 
ont le m{\^e}me comportement r{\'e}actif que le module synchrone 
d'origine.  Toutes les classes synchrones d{\'e}rivent d'une classe 
abstraite\footnote{Une classe abstraite est une classe dont certaines 
m{\'e}thodes ne sont pas d{\'e}finies.  Une telle classe ne peut donc pas
{\^e}tre instanci{\'e}e.  Elle d{\'e}finit les propri{\'e}t{\'e}s communes {\`a} 
toutes les classes qui d{\'e}rivent d'elle.} nomm{\'e}e 
\texttt{Synchronous}, qui d{\'e}finit le protocole minimal de tout objet 
synchrone.  Ce protocole commun permet de d{\'e}finir une machine 
d'ex{\'e}cution synchrone qui {\em conserve la s{\'e}mantique synchrone des 
modules} dans le langage {\`a} objets.

Les objets synchrones peuvent ainsi {\^e}tre interconnect{\'e}s et communiquer 
de mani{\`e}re synchrone entre eux.  Le comportement d'un tel r{\'e}seau 
d'objets est identique {\`a} celui d'un programme synchrone compos{\'e} des 
modules correspondants.  Ceci permet de constituer des biblioth{\`e}ques 
de classes synchrones et d'obtenir une certaine forme de 
r{\'e}utilisabilit{\'e} du code synchrone.  Cette compilation s{\'e}par{\'e}e est 
toutefois limit{\'e}e par la r{\'e}solution des probl{\`e}me de causalit{\'e} qui 
n{\'e}cessite la connaissance de la s{\'e}mantique des modules et oblige donc 
{\`a} << ouvrir les bo{\^\i}tes noires >>.

\section*{Communications \\ entre objets}
\label{sec:comm}
Les objets classiques communiquent simplement par messages (ou 
activation de m{\'e}thodes).  Les objets synchrones peuvent communiquer 
par signaux.  Il convient de d{\'e}finir des protocoles nouveaux pour les 
communications non seulement entre objets synchrones, mais {\'e}galement 
entre objets synchrones et autres objets.

\subsection*{Communication synchrone \\ et horloges}
La communication synchrone entre objets implique que {\em ces objets 
partagent une m{\^e}me notion d'instant}.  La machine d'ex{\'e}cution dispose 
pour cela d'une classe \texttt{Clock}.  Il est possible d'utiliser 
plusieurs instances de cette classe (horloges) dans un m{\^e}me programme 
pour traiter des {\'e}v{\'e}nements survenant {\`a} des {\'e}chelles de temps 
diff{\'e}rentes.  Chaque horloge calcule un ordonnancement des objets 
qu'elle g{\`e}re en fonction de leurs interconnexions, et les fait r{\'e}agir 
{\`a} chaque instant dans un ordre qui satisfait leurs d{\'e}pendances.

Les connexions entre objets se font point {\`a} point gr{\^a}ce {\`a} la m{\'e}thode 
de connexion dont sont dot{\'e}s les signaux d'entr{\'e}es.  Ceci permet 
d'utiliser les m{\'e}canismes de v{\'e}rification de types de \cplusplus\ pour 
assurer qu'un signal d'entr{\'e}e ne peut {\^e}tre connect{\'e} qu'{\`a} un signal de 
sortie de m{\^e}me type.

\subsection*{Communications \\ asynchrones}
Pour que les objets synchrones puissent communiquer avec des objets 
classiques, ou avec des objets synchrones situ{\'e}s sur une autre 
horloge, un m{\'e}canisme de communication asynchrone est indispensable.
Les communications vers l'ext{\'e}rieur de l'horloge ne posent pas de 
probl{\`e}me puisqu'il est possible de consulter la valeur des signaux 
de sortie d'un objet synchrone sans le perturber. Par contre, les 
communications de l'ext{\'e}rieur vers un objet de l'horloge 
n{\'e}cessitent {\em une phase de synchronisation} : il faut construire un 
{\'e}v{\'e}nement synchrone {\`a} partir d'un ou de plusieurs 
{\'e}v{\'e}nements asynchrones.

Imaginons par exemple que pour d{\'e}clencher l'enregistrement sur un 
magn{\'e}tophone, il faille appuyer simultan{\'e}ment sur les touches 
\button{Record} et \button{Play}.  Le contr{\^o}leur de la platine est 
donc sensible aux {\'e}v{\'e}nements \{\button{Play}\} et \{\button{Record}, 
\button{Play}\}, mais pas {\`a} l'{\'e}v{\'e}nement \{\button{Record}\} qui ne 
doit jamais se produire.  Dans notre application, l'enfoncement d'un 
bouton de la platine est un {\'e}v{\'e}nement asynchrone puisqu'il est 
d{\'e}clench{\'e} dans le monde physique.  Il faut transformer ces {\'e}v{\'e}nements 
asynchrones en {\'e}v{\'e}nements synchrones pour le contr{\^o}leur.  Ainsi, 
l'arriv{\'e}e de l'{\'e}v{\'e}nement asynchrone \button{Record} ne g{\'e}n{\'e}rera pas 
d'{\'e}v{\'e}nement synchrone.  L'arriv{\'e}e successive de \button{Record} et de 
\button{Play} g{\'e}n{\'e}rera l'{\'e}v{\'e}nement synchrone \{\button{Record}, 
\button{Play}\}.  L'{\'e}v{\'e}nement asynchrone \button{Play} peut poser un 
probl{\`e}me : s'agit-il d'une demande de lecture ou d'une demande 
d'enregistrement dont l'{\'e}v{\'e}nement \button{Record} n'est pas encore 
arriv{\'e}?  Une solution est d'attendre un certain temps avant de g{\'e}n{\'e}rer 
l'{\'e}v{\'e}nement synchrone.  Si l'{\'e}v{\'e}nement \button{Record} survient 
pendant ce laps de temps, on g{\'e}n{\'e}rera \{\button{Record}, 
\button{Play}\}, sinon, on g{\'e}n{\'e}rera \{\button{Play}\}.  Ce probl{\`e}me 
est semblable {\`a} celui de la d{\'e}tection du double-clic dans les 
interfaces graphiques.

La transformation d'{\'e}v{\'e}nements asynchrones en {\'e}v{\'e}nements synchrones 
est une t{\^a}che non triviale qui est confi{\'e}e {\`a} des {\em objets 
d'interface}.  Ces objets synchrones sont 
sensibles {\`a} des {\'e}v{\'e}nements asynchrones gr{\^a}ce {\`a} certaines de leurs 
m{\'e}thodes, et produisent des {\'e}v{\'e}nements synchrones pour les autres 
objets de l'horloge.  Ils peuvent {\^e}tre {\'e}crits en \cplusplus\ ou dans 
un langage synchrone.  Dans ce dernier cas, aucune hypoth{\`e}se ne doit 
{\^e}tre faite sur la simultan{\'e}it{\'e} des entr{\'e}es puisque cette notion n'a 
pas de sens pour des {\'e}v{\'e}nements asynchrones.

\subsection*{Dynamicit{\'e}}
Nous avons vu que les objets synchrones peuvent {\^e}tre connect{\'e}s entre 
eux et communiquer de mani{\`e}re synchrone sous le contr{\^o}le d'une 
horloge.  Pour un tel groupe d'objets, il est toujours possible 
d'{\'e}crire un programme {\'e}quivalent dans un langage synchrone et 
d'utiliser des outils de preuve pour v{\'e}rifier certaines propri{\'e}t{\'e}s.  
L'approche objet apporte en outre la r{\'e}utilisabilit{\'e} et la souplesse 
d'int{\'e}gration.

Une fois qu'un module est traduit en une classe \cplusplus, rien 
n'interdit de cr{\'e}er ou de d{\'e}truire dynamiquement des instances de 
cette classe au cours de l'ex{\'e}cution du programme.  Ceci impose de 
pouvoir changer dynamiquement les connexions entre objets synchrones 
de fa\c{c}on {\`a} pouvoir communiquer avec les nouveaux objets, ou de 
rediriger les communications avec des objets qui n'existent plus.

On passe alors {\`a} l'ordre sup{\'e}rieur puisqu'un {\'e}v{\'e}nement ne d{\'e}clenche 
plus uniquement la r{\'e}action d'un objet, mais peut aussi d{\'e}clencher une 
<< r{\'e}action d'horloge >>, c'est-{\`a}-dire une modification du programme 
synchrone {\'e}quivalent au groupe d'objets.

La dynamicit{\'e} a l'inconv{\'e}nient de supprimer l'existence d'un programme 
synchrone {\'e}quivalent {\`a} une horloge.  Il n'est donc plus possible 
d'utiliser les outils de preuve classiques pour v{\'e}rifier des 
propri{\'e}t{\'e}s.  Mais elle permet d'exprimer des comportements qui ne 
peuvent pas {\^e}tre {\'e}crits dans un langage synchrone tout en b{\'e}n{\'e}ficiant 
des avantages de l'approche synchrone pour d{\'e}crire les constituants et 
le contr{\^o}le de la dynamicit{\'e}.

La dynamicit{\'e} peut {\^e}tre utilis{\'e}e dans des syst{\`e}mes o{\`u} le 
nombre d'objets n'est pas connu a priori.
En effet, la solution 
classique qui consiste {\`a} d{\'e}clarer autant d'objets qu'il peut y en 
avoir au maximum consomme inutilement des ressources, ce qui peut 
amener le syst{\`e}me {\`a} ne pas pouvoir traiter une situation alors 
qu'une meilleure utilisation du CPU ou de la m{\'e}moire permettrait de 
la traiter.

\begin{figure}
	\centerline{\resizebox{\columnwidth}{!}{\includegraphics{DynaObj.eps}}}
	\caption{Reconfiguration : dynamicit{\'e} des objets}
	\protect\label{fig:dynaobj}
\end{figure}

\begin{figure}
	\centerline{\resizebox{\columnwidth}{!}{\includegraphics{DynaComm.eps}}}
	\caption{Reconfiguration : dynamicit{\'e} des communications}
	\protect\label{fig:dynacomm}
\end{figure}

Une autre utilisation de la dynamicit{\'e} est la reconfiguration du 
syst{\`e}me pour assurer une qualit{\'e} de service minimale.  Lorsque 
certaines conditions sont d{\'e}tect{\'e}es, le syst{\`e}me change de 
configuration soit en modifiant uniquement les connexions entre 
objets, le temps de reconfiguration est alors tr{\`e}s court, soit en 
rempla\c{c}ant certains objets, ce qui est plus co{\^u}teux en temps, 
mais requiert moins de m{\'e}moire.

Par exemple, sur la figure \ref{fig:dynaobj}, un syst{\`e}me de 
contr{\^o}le se reconfigure en rempla\c{c}ant un module de r{\'e}gulation 
par un module de r{\'e}gulation en conditions critiques lorsque certaines 
conditions de temp{\'e}rature et de pression sont d{\'e}tect{\'e}es. Sur la 
figure \ref{fig:dynacomm}, les deux modules de r{\'e}gulation existent 
en permanence, et la reconfiguration se fait en modifiant uniquement 
les connexions.

La condition d{\'e}clenchante d'une reconfiguration peut {\^e}tre par exemple 
la d{\'e}tection d'un dysfonctionnement (application {\`a} la s{\^u}ret{\'e} de 
fonctionnement), ou la violation de l'hypoth{\`e}se synchrone (le temps de 
r{\'e}action des objets n'est plus n{\'e}gligeable devant la p{\'e}riode des 
{\'e}v{\'e}nements), auquel cas, on remplacera les objets les plus lents par 
des objets assurant un service d{\'e}grad{\'e} similaire plus rapide.

\subsection*{Transformations de graphes}
\label{subsec:transgraph}
Une application purement synchrone et mono-horloge peut {\^e}tre d{\'e}crite 
par un graphe orient{\'e} dont les sommets sont les objets synchrones et 
dont les ar{\^e}tes repr{\'e}sentent les connexions entre les signaux des 
objets.  On peut modifier formellement ce graphe pour obtenir une 
nouvelle application synchrone.  De telles transformations ont {\'e}t{\'e} 
{\'e}tudi{\'e}es pour dissocier le d{\'e}veloppement d'une application et la prise 
en compte de contraintes de s{\^u}ret{\'e} de fonctionnement : {\`a} partir du 
graphe de l'application initiale, on applique des transformations 
(n-plication d'un objet, ajout de voteurs, de d{\'e}tecteurs 
d'incoh{\'e}rences etc.) pour obtenir le graphe de l'application int{\'e}grant 
les contraintes de s{\^u}ret{\'e} de fonctionnement.  Un langage de 
configuration permet d'exprimer les transformations du graphe, et il 
est possible de constituer des biblioth{\`e}ques de transformations 
usuelles (par exemple, le remplacement d'un objet par trois 
exemplaires de cet objet avec des voteurs sur les sorties).  Une 
application peut ainsi {\^e}tre adapt{\'e}e {\`a} diff{\'e}rents environnements en lui 
appliquant les fichiers de configuration correspondants.
De telles transformations ont {\'e}t{\'e} {\'e}tudi{\'e}es dans le cadre d'un contrat 
avec la DGA.

\section*{Environnement \\ de d{\'e}veloppement} 
Pour mettre en {\oe}uvre la programmation synchrone par objets, nous 
d{\'e}veloppons un environnement de programmation. Cet environnement 
int{\`e}gre diff{\'e}rents logiciels d{\'e}di{\'e}s aux approches synchrones : 
compilateurs,  simulateurs,  g{\'e}n{\'e}rateurs
de code et outils de preuves.

\vspace{\baselineskip}
Les comportements r{\'e}actifs peuvent {\^e}tre indiff{\'e}remment exprim{\'e}s
par des langages synchrones (\textsc{Lustre} ou \textsc{Esterel}) ou des
formalismes graphiques (\textsc{Argos}).  Ils sont compil{\'e}s en code
interm{\'e}diaire commun \textsc{oc}  par leurs compilateurs respectifs.

La transformation d'un module synchrone en classe \cplusplus\ est 
r{\'e}alis{\'e}e automatiquement {\`a} partir de son code oc  gr{\^a}ce {\`a} 
notre outil \occplusplus, qui peut aussi g{\'e}n{\'e}rer un fichier de 
description du module (interface, fichiers source...) en \textsc{mdl}. 
\textsc{mdl} est un langage de description et de d{\'e}finition de modules 
synchrones qui permet de cr{\'e}er de nouveaux modules par assemblage 
de modules existants. L'outil associ{\'e}, \textsc{mdlc} (\textsc{mdl} 
Compiler), produit une classe \cplusplus\ synchrone {\`a} partir de sa 
description en \textsc{mdl}.

\textsc{Mdl} permet aussi de d{\'e}finir de nouveaux modules par h{\'e}ritage. 
La classe \cplusplus\ produite est alors une classe d{\'e}riv{\'e}e de la classe 
correspondant au module de base.

Le langage de configuration du \S\ref{subsec:transgraph} est une 
extension de \textsc{mdl}.

La machine d'ex{\'e}cution synchrone se pr{\'e}sente sous la forme d'une 
biblioth{\`e}que de classes, \textsf{libSync}, qui fournit tout 
l'environnement n{\'e}cessaire aux classes synchrones produites par 
\occplusplus\ ou \textsc{mdlc}.

\vspace{\baselineskip}
Les comportements r{\'e}actifs peuvent {\^e}tre test{\'e}s {\`a} l'aide de simulateurs 
{\`a} interface graphique bas{\'e}s sur {\sc Tcl/Tk} et construits 
automatiquement par \textsc{mdlc} {\`a} partir des fichiers de 
description.

\vspace{\baselineskip}
Nos outils s'appuyant sur le format commun \textsc{oc}, ils 
s'interfacent ais{\'e}ment avec les outils de preuves r{\'e}alis{\'e}s pour les 
langages synchrones.


\section*{Conclusion}
La combinaison des approches par objets et des mod{\`e}les de syst{\`e}mes 
r{\'e}actifs est une voie qui semble prometteuse.

Son premier avantage est certainement le << confort >> de mod{\'e}lisation 
des syst{\`e}mes complexes.  La vue par objets s'appuie sur des m{\'e}thodes 
largement utilis{\'e}es du type OMT et la description du comportement 
b{\'e}n{\'e}ficie de la s{\'e}mantique rigoureuse du mod{\`e}le synchrone.

La cha{\^\i}ne de d{\'e}veloppement quasiment compl{\`e}te dont nous disposons pour 
cette approche permet de b{\'e}n{\'e}ficier de ce confort pour 
l'impl{\'e}mentation, le langage cible {\'e}tant \cplusplus.

La plateforme de conception et de simulation \textsc{Ptolemy}, 
d{\'e}velopp{\'e}e {\`a} l'Universit{\'e} de Californie {\`a} Berkeley, permet d'utiliser 
conjointement plusieurs formalismes. Nous travaillons actuellement {\`a} 
son utilisation pour d{\'e}velopper notre approche.

\end{document}