Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
MOF : Meta Object Facility
MOF pour (Meta-Object Facility) [106] est un ensemble d’interfaces permettant de definir´ la syntaxe et la semantique´ d’un langage de modelisation´. Il a et´e´ cre´e´ par l’OMG afin de definir´ des m eta´-modeles` et leurs modeles` correspondants [10].
Il fait partie des standards definis´ par l’OMG et il peut etreˆ vu comme un sous-ensemble d’UML. Le MOF et l’UML constituent le cœur de l’approche MDA car ces deux standards permettent de creer´ des modeles` technologiquement neutres. Le MOF specifie´ la structure et la syntaxe de tous les meta´-modeles` comme UML, CWM (Common Warehouse Meta-model) et SPEM (Software Process Engineering Meta-model). Ils ont le memeˆ forma-lisme. Le MOF specifie´ aussi des m ecanismes´ d’interoperabilit´e´ entre ces meta´-modeles`. Il est donc possible de les comparer et de les relier. Graceˆ a` ces mecanismes´ d’echanges,´ le MOF peut faire cohabiter plusieurs meta´-modeles` differents´ [10].
MOF 2.0 a et´e´ developp´e´ en prenant en compte la nouvelle infrastructure d’UML 2.0, permettant ainsi a` UML 2.0 d’etreˆ utilise´ afin de repr esenter´ des meta´-modeles` de MOF 2.0. MOF 2.0 introduit une importante nouveaute,´ c’est la norme de QVT (Query View Transformation) qui est un langage de requetesˆ et de transformation de modeles`. Le QVT est le resultat´ d’un effort de normalisation des mecanismes,´ des techniques et des notations necessaires´ a` la transformation de modeles` sources en modeles` cibles. L’objectif du QVT est de definir´ et d’ etablir´ une maniere` standard pour interroger les modeles` du MOF, pour creer´ des vues et pour definir´ les transformations de mod eles` [98].
UML : Unified Modeling Language
Depuis que le groupe OMG a adopte´ le langage de modelisation´ unifi e´ en 1997, UML (Unified Modeling Language) s’est rapidement etabli´ comme etant´ le standard pour la modelisation´ des systemes` logiciels [48]. UML a et´e´ conc¸u pour unifier diff erentes´ nota-tions graphiques de modelisation,´ etreˆ le plus gen´eral´ possible et etreˆ extensible afin de prendre en charge des contextes non prevus´. La premiere` version d’UML a et´e´ publiee´ en 1997 par l’OMG. Depuis, UML est devenu la ref´erence´ pour la conception de logiciels. La specification´ d’UML d efinit´ une notation graphique pour visualiser, sp ecifier´ et construire des applications orientees´ objets [109]. La version 2.0 [126, 116, 19, 48] vise a` faire entrer ce langage dans une nouvelle ere` de sorte que les modeles` UML soient au centre de MDA. Cela revient a` rendre les modeles` UML stables et productifs et a` leur permettre de prendre en compte les plateformes d’execution´. UML 2.0 a introduit de nouvelles constructions qui le rendent plus adapte´ au developpement´ a` base de composants et a` la specification´ des descriptions architectu-rales.
La notation UML est decrite´ sous forme d’un ensemble de diagrammes. La premiere` gen´eration´ d’UML (UML 1.x), definit´ neuf diagrammes pour la sp ecification´ des ap-plications. Dans UML 2.0, quatre nouveaux diagrammes ont et´e´ ajoutes´ : il s’agit des diagrammes de structure composite (Composite structure diagrams), les diagrammes de paquetages (Packages diagrams), les diagrammes de vue d’ensemble d’interaction (In-teraction overview diagrams) et les diagrammes de synchronisation (Timing diagrams) [101, 48]. Les diagrammes UML sont regroupes´ dans deux classes principales [144] :
– Les diagrammes statiques : regroupent les diagrammes de classes, les diagrammes d’objets, les diagrammes de structure composite, les diagrammes de composants, les diagrammes de deploiement,´ et les diagrammes de paquetages.
– Les diagrammes dynamiques : regroupent les diagrammes de sequence,´ les dia-grammes de communication (nouvelle appellation des diagrammes de collaboration d’UML 1.x), les diagrammes d’activites,´ les machines a` etats,´ les diagrammes de vue d’ensemble d’interaction, et les diagrammes de synchronisation.
UML est conc¸u pour prendre en charge une grande variet´e´ de contextes. Cependant, memeˆ avec cette intention d’etreˆ gen´eral,´ UML ne peut pas couvrir tous les contextes et offre ainsi un mecanisme´ d’extensibilite´ base´ sur les profils. Un profil permet la personnali-sation d’UML pour prendre en charge des domaines specifiques´ qui ne peuvent pas etreˆ represent´es´ avec UML dans son etat´ original. L’approche MDA preconise´ fortement l’uti-lisation d’UML pour l’elaboration´ de PIMs et de la plupart des PSMs. Les specificit´ es´ de chaque plateforme peuvent etreˆ modelis´ees´ avec un profil.
En fait, nous pouvons definir´ pour chaque syst eme` un profil qui regroupe les el´ements´ necessaires´ a` ses caracteristiques´ [107].
Profil UML
Un profil UML est une adaptation du langage UML a` un domaine particulier [20, 82]. Il est constitue´ de ster´eotypes,´ de contraintes et de valeurs marquees´ [102]. Un ster´eotype´ definit´ une sous-classe d’un ou de plusieurs el´ements´ du meta´-modele` UML. Cette sous classe a la memeˆ structure que ses el´ements´ de base, mais le ster´eotype´ specifie´ des contraintes et des propriet´es´ supplementaires´. Les contraintes peuvent etreˆ specifi´ ees´ non formelle-ment, mais l’utilisation d’OCL (Object Constraint Language) est pref´erable´ pour creer´ les contraintes de fac¸on formelle et standardisee´.
MDA propose l’utilisation de profils UML. L’OMG a standardis e´ certains profils. Nous citons dans ce qui suit quelques uns :
– Le profil EDOC (Enterprise Distributed Object Computing) vise a` faciliter le developpement´ de modeles` d’entreprises, de systemes` ou d’organisations en utilisant une approche de collaboration recursive´ utilisable a` differents´ niveaux de granularite´ et pour differents´ degres´ de couplages. La gestion de l’ingenierie´ des processus metier´ est supportee´ par l’assemblage de services en visant la stabilite´ de l’architecture globale dans le cas de modifications locales [67].
– Le profil EAI (Enterprise Application Integration) simplifie l’int egration´ d’applications en normalisant les echanges´ et la traduction des meta´-donnees´.
– Le profil CORBA (Common Object Request Broker Architecture) permet de representer´ a` l’aide d’UML le modele` de composants CORBA.
– Le profil mod elisation´ temps reel´ (Schedulability Performance and Time) pour modeliser´ des applications en temps reels´.
– Le profil Test permet la sp ecification´ de tests pour les aspects structurels (statiques) ainsi que pour les aspects comportementaux (dynamiques) des modeles` UML.
– Le profil QoS (Quality of Service) repr esente´ la qualite´ de service et de tolerance´ aux erreurs. – Le profil SPEM (Software Process Engineering Metamodel) est d efini´ a` la fois comme un profil UML et comme un m eta´-modele` MOF. SPEM definit´ les fac¸ons d’utiliser UML dans les projets logiciels et permet la creation´ de modeles` de processus (pour les PIM exclusivement).
OCL : Object Constraint Language
En utilisant uniquement UML, il n’est pas possible d’exprimer toutes les contraintes sou-haitees´. Fort de ce constat, l’OMG a defini´ formellement le langage textuel de contraintes OCL, qui permet de definir´ n’importe quelle contrainte sur des mod eles` UML [20] : le langage OCL (Object Constraint Language) qui est un langage d’expression permettant de decrire´ des contraintes sur des modeles`. Une contrainte est une restriction sur une ou plusieurs valeurs d’un modele` non representable´ en UML.
Une contrainte OCL est une expression dont l’evaluation´ doit retourner vrai ou faux. L’evaluation´ d’une contrainte permet de savoir si la contrainte est respectee´ ou non. OCL donne des descriptions precises´ et non ambigues¨ du comportement du logiciel en completant´ les diagrammes. Il definit´ des pr e´-conditions, des post-conditions et des in-variants pour une operation´. Il permet aussi la definition´ des expressions de navigation et des expressions booleennes´. C’est un langage de haut niveau d’abstraction, parfaite-ment integr´e´ a` UML, qui permet de trouver des erreurs beaucoup plus totˆ dans le cycle de vie de l’application. Cette verification´ d’erreurs est rendue possible gr aceˆ a` la simu-lation du comportement du modele` [108, 12, 110, 6] en utilisant des outils tels que USE (UML-based Specification Environment) [55] et Octopus (OCL Tool for Precise UML Specifications) [44].
XMI : Xml Metadata Interchange
XMI est le langage d’echange´ entre le monde des modeles` et le monde XML (eXten-sible Markup Language). C’est le format d’echange´ standard entre les outils compatibles MDA. XMI decrit´ comment utiliser les balises XML pour representer´ un modele` UML en XML. Cette representation´ facilite les echanges´ de donnees´ entre les differents´ outils ou plateformes de modelisation´. En effet, XMI definit´ des r egles` permettant de construire des DTD (Document Type Definition) et des sch emas´ XML a` partir de meta´-modeles,` et inversement. Ainsi, il est possible d’encoder un meta´-modele` dans un document XML, mais aussi, a` partir d’un document XML il est possible de reconstruire des meta´-modeles`. XMI a l’avantage de regrouper les meta´-donnees´ et les instances dans un memeˆ document ce qui permet a` une application de comprendre les instances graceˆ a` leurs meta´-donnees´. Ceci facilite les echanges´ entre applications et certains outils pourront automatiser ces echanges´ en utilisant un moteur de transformation du type XSLT (Extensible Stylesheet Language Transformation) [20].
Architecture logicielle
L’architecture logicielle, comme le montre la figure 1.2, se d efinit´ comme une specification´ abstraite d’un syst eme` en termes de composants logiciels ou modules qui le constituent, des interactions entre ces composants (connecteurs) et d’un ensemble de regles` qui gouvernent cette interaction [21, 38, 50, 64, 87]. Les composants encapsulent typiquement l’information ou la fonctionnalite´. Tandis que les connecteurs assurent la communication entre les composants. Cette architecture possede,` gen´eralement,´ un en-semble de propriet´es´ d’ordre topologique ou fonctionnelle qu’elle doit respecter tout au long de son evolution´.
Composant
La notion de composant logiciel est introduite comme une suite a` la notion d’objet. Le composant offre une meilleure structuration de l’application et permet de construire un systeme` par assemblage de briques el´ementaires´ en favorisant la reutilisation´ de ces briques [132].
La notion de composant a pris de nombreuses formes dans les differentes´ approches de l’architecture logicielle [135]. La definition´ suivante, globalement accept ee,´ illustre bien ces propriet´es´ : “ Un composant est une unite´ de calcul ou de stockage. Il peut etreˆ primitif ou compose´. On parle dans ce dernier cas de composite. Sa taille peut aller de la fonction mathematique´ a` une application complete`. Deux parties definissent´ un composant. Une premiere` partie, dite externe, comprend la description des interfaces fournies et requises par le composant. Elle definit´ les interactions du composant avec son environnement. La seconde partie correspond a` son contenu et permet la description du fonctionnement interne du composant” [105].
En effet, le terme “composant logiciel” est utilis e´ depuis la phase de conception jusqu’a` la phase d’execution´ d’une application, il prend donc plusieurs formes. Dans ce document, nous parlerons de type de composant et instance de composant.
– Type de composant : un type de composant est la definition´ abstraite d’une entit e´ logi-cielle. Nous utilisons le type de composant pour la description du style architectural.
– Instance de composant : une instance de composant est au memeˆ titre qu’une instance d’objet, une entite´ existante et s’executant´ dans un systeme`. Elle est caracteris´ee´ par une ref´erence´ unique, un type de composant et une implantation de ce type. Nous utilisons l’instance de composant pour la description des operations´ de reconfiguration.
Connecteur
Le connecteur (appele´ connexion selon notre terminologie) correspond a` un el´ement´ d’ar-chitecture qui modelise´ les interactions entre deux ou plusieurs composants en definissant´ les regles` qui gouvernent ces interactions [30, 105].
Port
Un composant interagit avec son environnement par l’intermediaire´ de points d’interac-tions appeles´ ports. Les ports (et par consequent´ les interfaces) peuvent etreˆ fournis ou requis. Un port represente´ un point d’acces` a` certains services du composant [30]. Le comportement interne du composant ne doit etreˆ ni visible, ni accessible autrement que par ses ports.
Interface
C’est le point de communication qui permet d’interagir avec l’environnement. On la re-trouve donc associee´ aux composants et aux connecteurs. Elle specifie´ des ports dans le cas des composants et des rolesˆ dans le cas des connexions. [105].
Pour un composant, il existe deux types d’interfaces :
– Les interfaces fournies decrivent´ les services proposes´ par le composant (figure 1.3).
– Les interfaces requises decrivent´ les services que les autres composants doivent fournir pour le bon fonctionnement du composant dans un environnement particulier (figure 1.3).
Style “pipes and filters”
Dans ce style, comme le montre la figure 1.6, un composant rec¸oit un ensemble de donn ees´ en entree´ et produit un ensemble de donnees´ en sortie. Le composant, appele´ filtre , lit continuellement les entrees´ sur lesquelles il execute´ un traitement ou une sorte de “fil-trage” pour produire les sorties [51]. Les sp ecifications´ des filtres peuvent contraindre les entrees´ et les sorties. Un connecteur, quant a` lui, est appele´ pipe puisqu’il represente´ une sorte de conduite qui permet de vehiculer´ les sorties d’un filtre vers les entr ees´ d’un autre. Le style “pipes and filters” exige que les filtres soient des entit es´ independantes´ et qu’ils ne connaissent pas l’identite´ des autres filtres. De plus, la validit e´ d’un systeme` conforme a` ce style ne doit pas dependre´ de l’ordre dans lequel les filtres ex ecutent´ leur traitement.
Avantages des styles architecturaux
L’utilisation des styles architecturaux a un certain nombre d’avantages significatifs. D’abord, elle favorise la reutilisation´ de la conception. En effet, des applications modelis´ees´ selon un style et des propriet´es´ architecturales bien definies´ peuvent etreˆ reappliqu´ees´ a` des nouvelles applications. Elle facilite, pour les autres, la comprehension´ de l’organisation de l’architecture de l’application si les structures conventionnelles sont bien appliquees´ et utilisees´. Par exemple, concevoir une application selon le style Client-Serveur peut donner une idee´ claire sur le type de composants utilises´ et les interactions entre les differents´ composants. Finalement, l’utilisation des styles architecturaux peut mener a` la reutilisation´ significative du code : souvent les aspects invariants d’un style architectural se pretendent´ a` des implementations´ partagees´.
Architecture dynamique
Les architectures logicielles, comme nous l’avons present´e´ prec´edemment,´ peuvent etreˆ decrites´ comme etant´ un ensemble de composants et de connecteurs dans un cadre com-mun. Toutefois, cette approche est une approche statique. En effet, la structure du systeme,` une fois son architecture definie,´ n’ evolue´ pas dans le temps. Ce type d’architecture com-mence a` perdre de l’ampleur et ceder´ la place au concept d’architecture dynamique suite a` de nombreuses raisons detaill´ees´ plus tard. Dans la suite, nous presentons´ une definition´ et quelques motivations qui sont derriere` la naissance de ce concept.
Definition´ et motivation de la dynamique des architectures
Depuis quelques annees,´ la dynamique des architectures est devenue une activite´ qui com-mence a` prendre de l’ampleur. Les architectures des systemes` logiciels tendent a` devenir de plus en plus dynamiques. En effet, durant son cycle de vie, ce type d’applications peut etreˆ amene´ a` evoluer´ de differentes´ manieres` : evolution´ de l’architecture, ajout de fonctions, remplacements de certains composants par de nouveaux developp´es´ selon de nouvelles technologies de programmation ou de communication, etc.
Raison derriere` la dynamique des architectures
La dynamique des architectures peut etreˆ realis´ee´ pour differentes´ raisons. Ces raisons peuvent etreˆ classees´ en quatre categories´ [70] :
– Dynamique correctionnelle : dans certains cas, on remarque que l’application en cours d’execution´ ne se comporte pas correctement comme prevu´. La solution est d’identifier le composant de l’application qui pose probl eme` et le remplacer par une nouvelle version supposee´ correcte. Cette nouvelle version fournit la memeˆ fonctionnalite´ que l’ancienne, elle se contente simplement de corriger ses defauts´.
– Dynamique adaptative : memeˆ si l’application s’execute´ correctement, parfois l’en-vironnement d’execution,´ comme le systeme` d’exploitation, les composants materiels´ ou d’autres applications ou donnees´ dont elle depend,´ changent. L’architecture doit donc s’adapter et evoluer´ soit en ajoutant des nouveaux composants/connexions soit en remplac¸ant des composants/connexions par d’autres.
– Dynamique evolutive´ : au moment du developpement´ de l’application, certaines fonctionnalites´ ne sont pas prises en compte. Avec l’evolution´ des besoins de l’utilisa-teur, l’application doit etreˆ etendue´ avec de nouvelles fonctionnalites´. Cette extension peut etreˆ realis´ee´ en ajoutant un ou plusieurs composants/connexions pour assurer les nouvelles fonctionnalites´ ou memeˆ en gardant la memeˆ architecture de l’application et etendre´ simplement les composants existants.
– Dynamique perfective : l’objectif de ce type d’adaptation est d’ameliorer´ les perfor-mances du systeme`. A titre d’exemple, on se rend compte que l’implementation´ d’un composant n’est pas optimisee´. On decide´ alors de remplacer l’implementation´ du composant en question. Un autre exemple peut etreˆ celui d’un composant qui rec¸oit beaucoup de requetesˆ et qui n’arrive pas a` les satisfaire. Pour eviter´ la degradation´ des performances de l’application, on diminue la charge de ce composant en installant un autre qui lui partage sa tacheˆ.
Le souci majeur des techniques de conception des systemes` logiciels est donc de pouvoir s’adapter a` ces variations et de supporter la dynamicite´. Ces variations sont de differents´ types [112].
Types d’architectures dynamiques
Pour soutenir le developpement´ des architectures dynamiques, plusieurs chercheurs se sont concentres´ sur le developpement´ d’approches et de formalismes fournissant des systemes` d’architecture dynamique.
Suite a` ces recherches, differents´ types de dynamiques sont apparus. Parmi ces types nous trouvons :
– Dynamique d’implementation´ : ce type de dynamique permet de modifier la mise en œuvre d’un composant, c’est- a`-dire la maniere` avec laquelle un composant a et´e´ developp´e´ (le code du composant) sans changer ni les interfaces ni les connexions. Ce type de changement permet de faire evoluer´ un composant d’une version a` une autre (voir figure 1.7).
– Dynamique d’interfaces : comme nous l’avons detaill´e´ prec´edemment,´ un composant fournit ses services a` travers des interfaces. La dynamique d’interfaces consiste a` mo-difier les services fournis par un composant au biais de ses interfaces. Ceci, se traduit soit par la modification de l’ensemble des services fournis soit par la modification de la signature d’un service (voir figure 1.8).
– Dynamique de geom´etrie´ : elle est appelee´ aussi dynamique de localisation ou encore de migration. La dynamique de geom´etrie´ modifie la distribution g eographique´ d’une application. En effet, ce type de dynamique altere` uniquement l’emplacement des com-posants. Ainsi, un composant peut changer de localisation en migrant d’un site vers un autre. Comme le montre la figure 1.9, le composant C4 est d eplac´e´ du site 2 vers le site 3.
– Dynamique de structure : elle modifie la topologie de l’application. C’est- a`-dire dans ce type de dynamique on s’interesse´ uniquement au changement de la structure de l’application en termes de composants et de connexions. Cette dynamique se realise´ a` l’aide de quatre operations´ de base [140] : ajout d’un composant, suppression d’un composant, ajout d’une connexion et suppression d’une connexion. Comme le montre la figure 1.10, La connexion T1 est redirig ee´ vers le composant S1.
|
Table des matières
1 Architectures logicielles
1.1 MDA : Model Driven Architecture
1.1.1 Architecture `a quatre niveaux
1.1.2 MOF : Meta Object Facility
1.1.3 UML : Unified Modeling Language
1.1.4 Profil UML
1.1.5 OCL : Object Constraint Language
1.1.6 XMI : Xml Metadata Interchange
1.2 Architecture logicielle
1.2.1 Composant
1.2.2 Connecteur
1.2.3 Port
1.2.4 Interface
1.2.5 Configuration
1.3 Style architectural
1.3.1 Style “client-serveur”
1.3.2 Style “publier-souscrire”
1.3.3 Style “pipes and filters”
1.3.4 Avantages des styles architecturaux
1.4 Architecture dynamique
1.4.1 D´efinition et motivation de la dynamique des architectures
1.4.2 Raison derri`ere la dynamique des architectures
1.4.3 Types d’architectures dynamiques
1.5 Conclusion
2 Description des architectures logicielles : E´ tat de l’art
2.1 Langages de description d’architecture (ADL)
2.1.1 Darwin
2.1.1.1 Aspect dynamique et comportemental
2.1.1.2 Style architectural
2.1.2 Rapide
2.1.2.1 Aspect dynamique et comportemental
2.1.2.2 Style architectural
viii TABLE DES MATIE`RES
2.1.3 Wright
2.1.3.1 Aspect dynamique et comportemental
2.1.3.2 Style architectural
2.1.4 ¼-Space
2.1.4.1 Aspect dynamique et comportemental
2.1.4.2 Style architectural
2.1.5 Conclusion
2.2 Langage UML
2.2.1 UML et l’architecture logicielle
2.2.2 UML en tant que langage pour la description des architectures
2.2.3 Conclusion
2.3 Techniques formelles
2.3.1 Techniques bas´ees sur les graphes
2.3.2 Conclusion
2.4 Multi-Formalismes
2.4.1 Z et la transformation de graphe
2.4.2 UML et les techniques formelles
2.4.3 Conclusion
2.5 Synth`ese
2.6 Pr´esentation des m´ethodes agiles
2.6.1 UP – Unified Process
2.6.2 RUP – Rational Unified Process
2.6.3 2TUP – 2 Tracks Unified Process
2.6.4 MDA : Model Driven Architecture
2.7 Conclusion
3 Profil UML pour d´ecrire la dynamique des architectures logicielles
3.1 Style architectural
3.1.1 M´eta-mod`ele
3.1.2 Mod`ele
3.2 Op´eration de reconfiguration
3.2.1 M´eta-mod`ele
3.2.2 Mod`ele
3.3 Protocole de reconfiguration
3.3.1 M´eta-mod`ele
3.3.2 Mod`ele
3.4 Illustration
3.4.1 Mod´elisation du style architectural
3.4.2 Mod´elisation des op´erations de reconfiguration
3.4.2.1 Insertion d’un service d’´ev´enement
3.4.2.2 Insertion d’un patient
3.4.2.3 Insertion d’une infirmi`ere
3.4.2.4 Transfert d’un patient
3.4.2.5 Transfert d’une infirmi`ere
3.4.3 Mod´elisation du protocole de reconfiguration
3.5 Conclusion
4 Approche de Validation
4.1 Intra-Validation
4.1.1 R`egles pour le style architectural
4.1.2 R`egles pour l’op´eration de reconfiguration
4.1.3 R`egles pour le protocole de reconfiguration
4.1.4 Validation
4.2 Inter-Validation
4.2.1 Style architectural vers operation de reconfiguration
4.2.2 Operation de reconfiguration vers protocole de reconfiguration
4.3 Conclusion
5 Approche de V´erification
5.1 Transformation vers Z
5.1.1 Transformation de la partie graphique vers Z
5.1.1.1 Style architectural
5.1.1.2 Op´eration de reconfiguration
5.1.2 Transformation des contraintes OCL vers Z
5.1.2.1 Grammaire OCL−
5.1.2.2 Grammaire Z−
5.1.2.3 Grammaire de la passerelle
5.1.2.4 Exemple de transformation
5.2 V´erification
5.2.1 Consistance
5.2.2 Pr´eservation du style architectural
5.3 Conclusion
6 D´emarche de mod´elisation
6.1 Description de la d´emarche X
6.1.1 Branche style architectural
6.1.2 Branche op´eration de reconfiguration
6.1.3 Branche protocole de reconfiguration
6.1.4 Branche fonctionnelle
6.2 Caract´eristiques de la d´emarche X
6.2.1 X produit des mod`eles r´eutilisables
6.2.2 D´emarche it´erative
6.2.3 D´emarche incr´ementale
6.2.4 D´emarche de mod´elisation `a base d’UML
6.2.5 D´emarche centr´ee sur l’architecture
6.2.6 D´emarche orient´ee vers les composants
6.3 Environnement de mod´elisation
6.3.1 Mod´elisation
6.3.2 Validation
6.3.3 Transformation vers Z
6.4 Conclusion
Conclusion
Bilan des contributions
Perspectives
Publications de l’auteur
Bibliographie
Télécharger le rapport complet
