\documentclass{rapport-suivi-LINA}
\usepackage[T1]{fontenc}
\usepackage[latin1]{inputenc}
\usepackage{charter}% suivant les go?ts, alternatives ? Computer Modern : charter, times, palatino, lmodern, 

\begin{document}






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                           %%
%% IDENTIFICATION                                                            %%
%%                                                                           %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%%%%%%%%%
% sujet %
%%%%%%%%%
\titre{Programmation par Aspects et Composants}
\soustitre{} %% ? << commenter >> autrement

%%%%%%%%%%%%%%%
% financement %
%%%%%%%%%%%%%%%
\bourse{Région,Mines} % MESR, CNRS, INRIA, MINES, CIFRE <entreprise>, etc.

%%%%%%%%%%%%%
% doctorant %
%%%%%%%%%%%%%
\nomdoctorant{Hannousse}
\prenomdoctorant{Abdelhakim}

\courriel{\url{abdel-hakim.hannousse@emn.fr}} % l'inclusion dans une URL est nécessaire pour pouvoir introduire l'arobase
\telephone{02 51 85 85 25} % sur le site de la fac
\telecopie{} % sur le site de la fac

\datenaissance{10/02/1979}

%%%%%%%%%%%%%%%
% encadrement %
%%%%%%%%%%%%%%%
\equipe{Ascola, Coloss}

\nomdirecteur{Südholt} % exactement un directeur de thèse 
\prenomdirecteur{Mario}
\tauxdirecteur{20} 

\nomcoencadrant{Douence} % éventuellement un co-encadrant
\prenomcoencadrant{Rémi}
\tauxcoencadrant{40}


\nomautrecoencadrant{Ardourel} % éventuellement un autre co-encadrant s'il n'y a pas de co-directeur de thèse
\prenomautrecoencadrant{Gilles}
\tauxautrecoencadrant{40}
\equipeautrecoencadrant{Coloss} % si elle est différente de l'équipe d'accueil du directeur


\maketitle

\begin{abstract}
\end{abstract}






%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                           %%
%% ELEMENTS D'APPRECIATION                                                   %%
%%                                                                           %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Éléments d'appréciation factuels et personnels}

\section{Projet professionnel}

\begin{modules}{professionnels} % de préférence, au moins un en première année
	\module{MP5} % Code ED (ou indication de  l'équivalence - ex. : séminaire, école d'été, etc.)
	       {Méthodologie de la recherche} % Intitulé
	\module{MP11}
	       {La recherche et l'entreprise}
\end{modules}

%\begin{enseignements}
%	\enseignement{Algorithmique} % Intitulé court
%	             {TP} % TD, TP, voire CM, PRJ
%	             {22} % volume horaire en éq. TD
%					 {L2} % L1, L2, L3, M1, M2
%	             {Math-Info} % sigle de la formation
%	\enseignement{BD relationnelle}
%	             {TD}
%	             {6}
%	             {M1}
  %              {ALMA}
%	\enseignement{...}
%	             {...}
%	             {0}
%	             {...}
%	             {...}
%\end{enseignements}

\subsection{État qualitatif de la construction du projet professionnel}

Généralement, pas de difficulté rencontrée jusqu'\`{a} maintenant, le seul probl\`{e}me qu'on peut signaler est la difficulté \`{a} rédiger un document en français. Afin de résoudre ce probl\`{e}me je souhaite suivre des cours de français \`{a} partir de l'année prochaine.

\section{Aspects scientifiques}

\begin{modules}{scientifiques} % de préférence, au moins un en première année
	\module{MSS2}
	       {La conception des syst\`{e}mes informatiques embarqués}
	\module{MSS13}
	       {Introduction au calcul parallèle}
\end{modules}

% Pour plus tard...
%
%\subsection{Publications} % incluant rapports internes, de recherche, de contrat, etc., et ? préciser
%
%Auteurs (dans l'ordre) :
%Titre :
%Conférence, revue, rapport, etc. :

\subsection{Participations ? la vie de la recherche}

Il est prévu de participer \`{a} deux écoles d'été pour cette année 2009 :

\begin{itemize}
	\item Ecole des Jeunes Chercheurs en Programmation (EJCP'09) -- Juin 2009 
	\item 4th European Summer School on Aspect-oriented Software Development (AOSD'09) -- Ao\^{u}t 2009
\end{itemize}
Je suis aussi chargé de la gestion des références bibliographiques de l'équipe Ascola.


\subsection{État qualitatif de l'avancement du travail de thèse}

Le travail qui a été fait depuis la date de commencement de la th\`{e}se (01/10/2008) peut \^{e}tre résumé par les points suivants:
\begin{enumerate}
\item Une étude bibliographique a été effectuée (une soixantaine de références).
\item Des interpr\`{e}tes prototypes de langages (impératif, orienté-objet et fonctionnel) ont été développés en Haskell afin de ma\^{i}triser les différents paradigmes et comment les implémenter.   
\item Nous avons commencé la conception d'un mod\`{e}le mélangeant composants et aspects de mani\`{e}re originale. Ce mod\`{e}le est basé sur la théorie des Arrows\cite{arrows1,arrows2}. Un prototype en Haskell sert de base a nos expérimentations.  
\end{enumerate}

Enfin, l'avancement de la th\`{e}se est conforme aux attentes.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                           %%
%% CONTEXTE ET PROBLEMATIQUE                                                 %%
%%                                                                           %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Contexte et problématique}


\section{Contexte}

On assiste actuellement \`{a} deux formes de programmation visant \`{a} améliorer la réutilisation et l'adaptabilité du logiciel au travers d'une meilleure séparation des préoccupations tout au long du développement d'une application : la programmation par composants \cite{componants} et la programmation par aspects \cite{aspects}. 

L'approche composants consiste \`{a} décrire un ensemble de modules réutilisables. Chacun encapsule une ou plusieurs fonctions de base, et l'utilisateur va assembler ces différents modules afin de construire l'architecture globale d'un projet informatique. Ceci facilite le développement des logiciels et permet d'assurer une meilleure lisibilité et une meilleure maintenance. 

L'approche aspects vise \`{a} séparer les préoccupations techniques ou de contr\^{o}le (e.g. synchronisation, persistance, contraintes temps réel, etc.) des préoccupations métier ou fonctionnelles. Elle offre un mécanisme de tissage qui permet de fusionner ces deux types de préoccupations afin de construire le syst\`{e}me global. Ceci permet une meilleure séparation du code fonctionnel du code non fonctionnel et d'assurer une meilleure maintenabilité du syst\`{e}me. 

Ces deux approches sont complémentaires. L'approche composants assure une meilleure modularisation des préoccupations fonctionnelles. L'approche aspects assure une meilleure séparation du code fonctionnel du code non fonctionnel. Un syst\`{e}me complet nécessite ces deux approches. Il s'agit dans les deux approches : aspects et composants, de développer des applications par assemblage, de composants dans le premier cas et d'aspects dans le deuxi\`{e}me cas, avec les m\^{e}mes problématiques (vérifier la correction des assemblages, autoriser les assemblages dynamiques, etc.). Cet assemblage prend toutefois des formes différentes. Il est symétrique dans le cas des composants, chaque composant fournissant explicitement des services en s'appuyant sur des services fournis par d'autres composants. Il est asymétrique dans le cas des aspects, avec la définition d'un programme de base correspondant  \`{a} une structure et un comportement principal, sur lequel viennent se greffer des aspects additionnels traitant des préoccupations non couvertes par le programme de base.

Dans ce contexte, le projet de cette th\`{e}se est de proposer un mod\`{e}le unifié : composants aspects. Ce travail s'effectuera dans le cadre du projet régional Miles. Il correspond au démarrage d'une nouvelle étape dans les travaux communs aux deux équipes (i.e. Coloss et Ascola).

\section{Présentation de la problématique}

Les deux formes d'assemblage utilisées par les deux approches aspects et composants s'av\`{e}rent complémentaires. On peut ainsi avoir envie de structurer un aspect complexe sous la forme d'un assemblage de composants et un composant comme un assemblage d'aspects. Ce dernier point de vue est notamment naturel dans le cadre de l'assemblage de composants comme les Entreprise JavaBeans ou les services web. Le code métier du composant constitue alors le programme de base, complété par des aspects techniques gérant des préoccupations comme la distribution, la sécurité, la persistance, sans référence explicite a ces notions dans le code métier. Cette complémentarité est maintenant reconnue et a conduit \'{a} la définition de cadres de programmation en Java comme JBoss AOP ou Spring. Ce type d'intégration reste toutefois peu expressif et difficile \`{a} ma\^{i}triser.

Il s'agira donc d'étudier, \`{a} partir de l'expérience des équipes Ascola et Coloss dans le domaine des langages d'aspects et des langages de composants, la possibilité d'une intégration plus fine des composants et des aspects sous la forme d'un langage de programmation unifié. Nous nous intéresserons \`{a} la fois \`{a} la définition bien fondée d'un tel langage, \`{a} sa mise en \oe{}uvre et \`{a} son utilisation pratique. Le langage ou l'environnement devront supporter l'expression et la vérification de propriétés. Par exemple on veut pouvoir garantir la conformité des interactions entre deux composants apr\`{e}s l'ajout d'un aspect, ou un invariant sur l'état d'un composant.

%Rappel en termes généraux puis de manière détaillée du sujet de la thèse et plus particulièrement du problème phare sinon ? résoudre du moins ? faire progresser.

%Explication de la nature du verrou ? lever : scientifique et/ou technologique.







%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                           %%
%% ETUDE BIBLIOGRAPHIQUE                                                     %%
%%                                                                           %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{\'Etat de l'art}


\section{Classification de la bibliographie}
Notre étude bibliographique a été divisée en trois parties: 

\paragraph{Etude des mod\`{e}les \`{a} composants:}
Dans cette partie, nous avons étudié différents mod\`{e}les \`{a} composants, en mettant en évidence les différentes caractéristiques des composants que nous avons besoin de considérer dans notre futur mod\`{e}le. Parmi les mod\`{e}les étudiés, on peut citer les syt\`{e}mes :  EJB \cite{EJB}, CORBA \cite{CORBA}, Fractal\cite{Fractal}, SOFA\cite{SOFA2.0, SOFAConnectors, SOFAController}, Kmelia \cite{Kmelia, FKmelia, HBIDL, ProtKmelia}, rCOS\cite{rCOSCM1, rCOSCM2, rCOSTheory}. 

Chaque mod\`{e}le parmi ceux qui ont été étudiés a ses propres particularités. Par exemple l'EJB est un mod\`{e}le \`{a} plat qui ne consid\`{e}re pas l'aspect hiérarchique des composants (i.e. il ne supporte que les composants primitifs et pas les composants composites). Il utilise la technologie de conteneur qui prend en charge l'implémentation des services techniques (e.g. persistance), mais ces services sont tr\`{e}s limités. Fractal est un mod\`{e}le plus complet (e.g. hiérarchique, supporte la reconfiguration dynamique \`{a} travers la membrane associée \`{a} chaque composant, le déploiement, etc.).

Certains mod\`{e}les consid\`{e}rent un composant comme étant un objet qui est accessible uniquement \`{a} travers des interfaces associées \`{a} cet objet, ce qui permet de programmer les composants en utilisant des langages \`{a} objets. D'autre comme FuseJ \cite{FuseJ1, FuseJ2} proposent des langages spécifiques aux composants, malheureusement, ces langage n'ont pas de sémantique formelle.  

Nous avons aussi étudié le projet CoCoME (i.e. Common Component Modelling Example) \cite{CoCoME}. L'objectif de ce projet, qui a été lancé en 2006, est de comparer les différents mod\`{e}les \`{a} composants \`{a} travers une implémentation d'une application de gestion d'un supermarché (i.e. vente de produit, approvisionnement, génération des rapports, collaboration entre les différents magasins, etc.). Une architecture initiale de cette application a été fournie accompagnée par le code source de son implémentation. Chaque équipe a été chargée d'utiliser son propre mod\`{e}le pour spécifier cet exemple avec toutes ses contraintes structurelles, comportementales et temporelles. Différents mod\`{e}les ont été évalués dans ce projet comme : Fractal \cite{FractalCoCoME}, SOFA \cite{SOFACoCoME}, CoIn \cite{CoIn, CoInCoCoME}, GCM \cite{GCMCoCoME}, rCOS \cite{rCOSCoCoME}, Cowch \cite{CowchCoCoME}, JavaA \cite{JavaA, JavaACoCoME}, DisCCOMP \cite{DiSCCOMP, DiSCCOMPCoCoME}. Nous avons remarqué que plusieurs architectures (i.e. vues) ont été considérées pour le m\^{e}me syst\`{e}me. Nous avons aussi découvert que tous les mod\`{e}les \`{a} composants participants \`{a} ce projet ne sont pas suffisant pour modéliser une application concr\`{e}te comme celle de CoCoME. Par example, Fractal et Cowch permettent de spécifier l'architecture de l'application (i.e. les différents composants primitifs et composites et leur interactions) mais ils ne sont pas capables de spécifier des contraintes temps réel ni d'utiliser un mod\`{e}le formel pour vérifier la cohérence de composition et la compatibilité des interactions entre les différents composants dans des architectures. Par contre, le mod\`{e}le CoIn a prouvé la compatibilité des différentes interactions entre les composants et prouvé l'absence d'interblocage dans le syst\`{e}me. Malheureusement, CoIn est un mod\`{e}le abstrait de vérification formelle de composition mais pas un mod\'{e}le \`{a} composant complet.

A la fin de cette partie, nous avons étudié différentes taxonomies proposées pour les approches \`{a} composants. On peut citer comme exemple la taxonomie de  Bunse \cite{tax3} et la taxonomie de Kung-Ku \cite{tax1,tax2}. La taxonomie de Bunse est abstraite et générale, basée sur des crit\`{e}res qualitatifs qui sont plus des crit\`{e}res d'évaluation que des crit\`{e}res de classification (Par example :  la modularité, l'interopérabilité, le domaine d'application, etc.). La taxonomie proposée par Kung-Ku se base sur la possibilité d'assembler ou désassembler les composants \`{a} différentes phases de développement du syst\`{e}me (i.e. phase de conception, phase de stockage des composant dans des repositories, phase de déploiement).   

\paragraph{Etude des mod\`{e}les \`{a} aspects:}
Dans cette partie, comme pour la partie précédente, nous nous somme intéressé aux différentes caractéristiques des aspects que notre mod\`{e}le doit comporter. Différents mod\`{e}les  ont été étudiés. 
%
Le mod\`{e}le de référence AspectJ\cite{aspectj1} introduit deux notions essentielles : les points de coupures spécifiant l'endroit dans le code o\`{u} l'effet de l'aspect va \^{e}tre appliqué, et les advices qui spécifient le comportement de l'aspect. AspectJ propose des points de coupures sophistiqués qui dépendent du flot de contr\^{o}le et donc de l'historique de l'exécution. D'autres mod\`{e}les proposent des points de coupures aussi basés sur l'historique de l'exécution mais pas sur le flot de contr\^{o}le. En particulier, trace-matches \cite{tracematches} et EAOP \cite{DetectAspects, StatfAspects} définissent des séquences de points d'exécution et CEAOP  \cite{conAspect} étend ces séquences dans un contexte concurrent. Dans ces mod\`{e}les, la sémantique des points de coupures et le mécanisme de tissage ont été formellement spécifiés et différents opérateurs de compositions ont été définis.

%Les aspects ayant deux propriétés pertinantes qui doivent \^{e}tre assurer par  toute langage \`{a} aspects comme (EAOP, CEAOP, AspectJ ou autres), ces propriétés sont: des points de coupures Parmi les points de coupures que nous intéresse, c'est le contr\^{o}le flot, avec ce dernier, un aspect serai capable de réagir selon l'historique de l'exécution de syst\^{e}me. Malheureusement, certains mod\^{e}les d'aspects sont incapable d'exprimer cette point de coupure efficacement.

%\paragraph{Etude des mod\`{e}les hybrides:}
La programmation par aspects a été adaptés aux composants logiciels. Les mod\`{e}les que nous avons étudié sont : JASCO \cite{JAsCo}, FuseJ \cite{FuseJ1, FuseJ2}, CaesarJ \cite{CaesarJ} et FAC \cite{CAOP, FAC1, FAC2, unifMod1}. Certains de ces mod\`{e}les sont des extensions par aspects des mod\`{e}les \`{a} composants existants comme FAC (i.e. extension ou Fractal). D'autres comme CaesarJ, FuseJ et JASCo proposent des extensions d'aspects et de composants \`{a} des langages \`{a} objets (i.e. généralement Java). Dans le premier cas (i.e. FAC), un aspect a été considéré comme un composant ordinaire, et le mécanisme de tissage comme une sorte de connexion spéciale entre un composant aspect et un composant ordinaire. Dans le deuxi\`{e}me cas, FuseJ et JASCo proposent un langage d'aspects associé aux composants. Mais ces nouveaux langages n'ont pas de sémantique formelle. Le cas de CaesarJ est différent, une sémantique opérationnelle a été spécifiée pour le langage proposé. Nous avons remarqué, que tous ces mod\`{e}les sont beaucoup plus des mod\`{e}les \`{a} composants que des mod\`{e}les \`{a} aspects. C-\`{a}-d  la majorité des concepts d'aspects ont été négligés dans ces mod\`{e}les (e.g. pas de points de coupures basées sur le flot de contr\^{o}le ou les séquences, pas de compositions des aspects, etc.).  

\paragraph{Etude des Arrows:}
Le mécanisme appelée Arrows \cite{arrows1, arrows2} est un nouveau langage qui a été intégré dans le langage fonctionnel Haskell sous forme d'une librairie. Le syst\`{e}me Arrows permet de définir des calculs primitifs et de les  composer. Il est formellement défini. Il peut donc servir de base formelle pour d'écrire des architectures \`{a} base de composants. Actuellement les arrows sont utilisés pour développer une biblioth\`{e}que graphique pour Haskell appelée Fruit \cite{Fruit}. Dans ce travail, chaque composant graphique a été défini comme étant un arrows. Les opérateurs de composition des arrows ont été utilisés pour construire des composants graphiques complexes. Ce mécanisme a été aussi utilisé pour la composition parall\`{e}le de processus \cite{HPorter, simBot}. Un exemple pratique a été présenté dans ce contexte qui consiste \`{a} modéliser un robot qui utilise son bras pour accéder \`{a} des objets distants. Apr\`{e}s l'analyse de ce nouveau mécanisme qui semble similaire \`{a} celui de composants nous avons commencé \`{a} étudier ce syst\`{e}me en détail.

\section{Mise en perspective}

Notre étude bibliographique nous a permis d'identifier les caractéristiques essentielles des syst\^{e}mes \`{a} composants: 

\begin{enumerate}
\item composants primitifs boites noires,
\item composants composites pour assurer une structure hiérarchique des syst\`{e}mes,
\item structurations multiples d'un m\^{e}me syst\^{e}me.
\end{enumerate}

Les caractéristiques essentielles des syst\`{e}mes \`{a} aspects:
\begin{enumerate}
\item les points de jonctions,
\item les points de coupures,
\item les advices.
\end{enumerate}

Les syst\`{e}mes hybrides à composants et aspects sont généralement des adaptations naïves des langages d'aspects au monde des composants. Par exemple, on perd la notion de points de coupures basés sur le flot de contr\^{o}le mais on ne gagne pas de points de coupures basés sur la notion de communication entre composants.
%Les caractéristiques essentielles des syst\^{e}mes hybrides:
%\begin{enumerate}
%\item adaptation nave des aspects aux composants.
%\item pas de notion de composants dans ????
%\end{enumerate}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%                                                                           %%
%% PERSPECTIVES DU TRAVAIL DE THESE                                          %%
%%                                                                           %%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{Perspectives du travail de thèse}

Une premi\`{e}re piste à explorer concerne la notion de vue. Dans un syst\`{e}me hiérarchique on peut distinguer deux types de composants : les composants primitifs (c.à.d. les boites) et les composants composites (c-à-d. les boites de boites). Un unique syst\`{e}me défini par ses composants primitifs peut \^{e}tre structuré de multiples façons à l'aide de composants composites ou de vues. Par exemple, la figure \ref{fig1} montre deux vues différentes d'une m\^{e}me architecture. Une vue peut \^{e}tre considérée comme un composite représentant une préoccupation ou un domaine dont l'enveloppe est calculée et qui permet d'intercepter les communications d'un groupe de composants à l'aide d'un aspect. Des aspects peuvent être appliqués aux différentes vues. Se posent alors les questions de la cohabitation de plusieurs vues d'un m\^{e}me syst\`{e}me (contr\^{o}le, cohérence, co\^{u}t) et du recalcul des vues lors d'une reconfiguration dynamique du système.

\begin{figure}[htbp]
\begin{center}
\begin{tabular}{|c|c|}
\hline
~&~\\
\includegraphics[width=1.8in, height=0.8in]{Base1.pdf} & \includegraphics[width=1.8in, height=0.8in]{Base2.pdf}\\
(a) Vue de base $v_{1}$ & (b) Vue $v_{2}$ \\
\hline
\end{tabular}
\caption{{\bf Architecture \`{a} composants avec différents vues}}
\label{fig1}
\end{center}
\end{figure}


Notre mod\`{e}le doit supporter formellement la modularité et la hiérarchisation des syst\`{e}mes à composants et utiliser des opérateurs d'assemblage composant-composant et aspect-composant. Il doit aussi supporter les différents concepts pertinents des aspects identifiés dans la section précédente. Pour atteindre cet objectif, notre mod\`{e}le va considérer les composants comme des Arrows. Ces composants sont composés \`{a} l'aide d'opérateurs de composition définis dans Arrows. Un wrapper est une paire de composants before et after qui entoure un composant pour en modifier le comportement. Un système peut \^{e}tre assemblé de différentes mani\`{e}res. Chaque manière est appelée vue. Un wrapper dans une vue autre que la vue de base est appelé aspect. La figure \ref{fig2} représente l'application de deux wrappers sur différentes vues.

\begin{figure}[htbp]
\begin{center}
\begin{tabular}{|c|c|}
\hline
~&~\\
\includegraphics[width=2in, height=1in]{varrows10a.pdf} & \includegraphics[width=2in, height=1in]{varrows10b.pdf}\\
(a) $v_{1}$ wrappé par $w_{1}=(B_{1},A_{1})$& (b) $v_{2}$ wrappé par $w_{2}=(B_{2},A_{2})$\\
\hline
\end{tabular}
\caption{{\bf Deux vues wrappés différemment}}
\label{fig2}
\end{center}
\end{figure}

Un algorithme général de spécification d'un syst\`{e}me complet consiste à :

\begin{enumerate}
\item Définir les composants primitifs.
\item Utiliser les opérateurs d'assemblage pour construire l'architecture désirée (i.e. vue de base).
\item Définir les différents wrappers et les vues sur lesquelles ils s'appliquent.
\item Appliquer les wrappers de base sur la vue de base.
\item Pour chaque autre wrapper:
\begin{enumerate}
\item Transformer la vue de base dans la vue correspondante.
\item Appliquer le wrapper.
\item Appliquer la transformation inverse pour revenir à la vue de base.
\end{enumerate}
\end{enumerate}

La figure \ref{fig3} montre l'intégration des deux wrappers de la figure~\ref{fig2} à la vue de base, où swap est un composant arrows utilisé pour reordonner les fils.

\begin{figure}[htbp]
\begin{center}
\includegraphics[width=5in, height=1.5in]{arrows10.pdf} 
\caption{{\bf Architecture poss\`{e}de un vue $v_{1}$ wrappée par $w_{1}$ sur $v_{1}$ et par $w_{2}$ sur $v_{2}$}}
\label{fig3}
\end{center}
\end{figure}


Nous validerons notre mod\`{e}le sur une application concr\`{e}te et nous étudierons son adaptation à un syst\`{e}me existant comme par exemple Fractal. 

\nocite{*}
\addcontentsline{toc}{charter}{Bibliographie}
\bibliography{References1} % Votre fichier BibTeX de références

\end{document}
