Modélisation des systèmes temps-réel répartis embarqués pour la ...

Modélisation des systèmes temps-réel répartis embarqués
aspects, notamment le choix du langage à utiliser (pour DSA et RMI, par exemple) ou la façon
d’organiser l’application (RPC, CORBA). Les approches de plus haut niveau telles que Fractal
permettent dans une certaine mesure de faire abstraction de l’exécutif utilisé, mais elles guident
néanmoins la conception de l’application [Hnětykna, 2005] – qui sera une application conçue en
appliquant l’approche Fractal.
Contrairement à des solutions comme RMI ou DSA, les approches orientées composant reposent
sur l’utilisation d’un langage pour décrire les applications comme un assemblage d’éléments
éventuellement recomposables. Bien que ce ne soit pas le cas dans les méthodes que nous
avons décrites, ces composants pourraient transporter, en plus de la description des interactions
qu’ils prennent en charge, des caractéristiques non fonctionnelles telles que des temps d’exécution.
Ces approches mettent en lumière l’intérêt de décrire les applications comme un assemblage
d’éléments ; une telle démarche de modélisation permet de confronter la construction des applications
à des spécifications plus ou moins formelles, ce qui peut faciliter l’analyse de leur structure
et de leur exécution.
Les activités de l’OMG, outre CORBA, ont conduit à définir le langage UML (Unified Modeling
Language) afin de faciliter la description des applications. UML était initialement conçu
pour décrire l’organisation de programmes orientés objet ; il a été généralisé, de façon à permettre
la description des différents aspects d’une application – tout en conservant l’approche objet dans
une large mesure. UML sert de langage support à un processus de conception d’application appelé
MDA (Model Driven Architecture). Nous donnons ici un aperçu des principes de MDA.
II-4.1 Présentation d’UML
Dans sa version 2.0, UML définit un ensemble de treize syntaxes, chacune correspondant à un
type de diagramme : diagramme de classes, de paquetages, de structures composites, de composants,
de déploiement, de cas d’utilisation, d’états, d’activités et d’interactions. Ces diagrammes
définissent des notations standard permettant de décrire tous les aspects de l’application à modéliser
– tant architecturaux que comportementaux. Dans le cadre de ce chapitre, nous nous intéressons
essentiellement aux diagrammes architecturaux.
Les diagrammes de classe sont les plus connus. Ils permettent de décrire l’organisation des
éléments de l’application, et sont largement inspirés des structures que l’on retrouve dans les langages
de programmation orientée objet. Les diagrammes de paquetages permettent d’organiser les
classes en sous-ensembles logiques, et ainsi de structurer les éléments applicatifs. Les diagrammes
d’objets décrivent les instances des classes. Ils permettent donc de figurer l’état de l’application à
un instant donné.
Les diagrammes de composants se situent à un niveau supérieur : ils permettent de représenter
l’architecture comme un ensemble d’éléments proposant des interfaces qu’il est possible de
connecter. Un composant peut ainsi requérir une connexion avec un autre élément fournissant une
interface adéquate ; cette notion est absente des diagrammes de classes.
Les diagrammes de structures composites permettent de décrire les relations entre les différentes
entités qui ont pu par exemple être définies dans les diagrammes de composants. Les
diagrammes de structures composites permettent donc typiquement de représenter les connecteurs
et les interfaces (c’est-à-dire les ports) ; ils permettent de décrire comment les différentes entités
architecturales interagissent.
Les diagrammes de déploiement permettent de décrire la façon dont les éléments de l’application
doivent être installés. Ils permettent notamment de représenter les éléments matériels sur
lesquels les éléments applicatifs vont s’exécuter.
18 c○ 2007 Thomas Vergnaud