Les Langages de Description d`Architectures

MASTER 2 RECHERCHE SLCP - MODULE RTM, 2005
1
Les Langages de Description d’Architectures
Benoı̂t Combemale† , Étudiant et Sylvain Rougemaille‡ , Étudiant
Abstract—This synthesis realise an overview of the architecture description language purpose. The first part of this
synthesis present the architectural description context.
Mots clés—Architecture logicielle, Description, ADL,
Fonctionalités.
I. Introduction
D
ANS de nombreux domaines la description architecturale d’un système (logiciel ou non) est apparue
indispensable pour modéliser de plus haut niveau un
système et ainsi ne pas se fixer à une architecture bien
définie. C’est pourquoi un certain nombre de langages
permettant cette description sont apparus et offre à ce
jour un certain nombre de fonctionnalités.
Cette synthèse, réalisée dans le cadre du Master
Recherche SLCP, réalise une courte étude sur la description d’architectures ainsi que sur les différents langages
permettant cette description (ADL1 ). Cette étude ce base
pour cela sur des articles scientifiques. Nous définirons
tout d’abord le concept de description d’architecture[1]
afin dans souligner par la suite les applications diverses
dans l’ingénierie du logiciel. Nous terminerons enfin par
une description fonctionnelle des ADL existant à ce jour
et des outils les supportant en fonction de leurs différentes
spécificités [1], [2].
II. Les Descriptions d’Architecture
l’image du bâtiment, un architecte dans le domaine de
A l’ingénierie du logiciel ne réalise pas l’architecture pro-
prement dite mais une représentation de cette architecture.
Celle-ci a pour objectif d’enregistrer l’ensemble des informations architecturales sous une forme permettant par la
suite son utilisation et sa réutilisation (au cours de future
description).
L’intérêt d’une description architecturale peut prendre
différentes formes et entraı̂ne donc la communauté scientifique à faire de nombreuses réflexions sur :
◦ La définition des exigences et des caractéristiques d’un
ADL.
◦ La mise au point d’un grand nombre de langage apportant chacun ses spécificités,
◦ L’utilisation de notations existantes (e.g. UML) pour
le domaine de la description architecturale,
◦ La catégorisation et la comparaison des différents
ADL,
IEEE prend également part à ces travaux avec la mise
en place d’une fondation pour le développement de ce
† Étudiant en Master Recherche. laboratoire GRIMM (Toulouse)
Email: [email protected] .
‡ Étudiant en Master Recherche. Laboratoire IRIT (Toulouse)
Email: [email protected] .
1 Architecture Description Language
domaine et la publication des pratiques recommandées
pour les description d’architectures2 .
La notion de “représentation” architecturale passe par la
mise au point de convention nécessitant la normalisation
de langages tels que nous les définissons dans la partie
suivante.
III. Les Langages de Description
d’Architectures
U
N grand nombre de langages de description
d’architecture sont récemment nés au sein de la
communauté scientifique et apportent chacun leurs
spécificités fonctionnelles.
Un ADL est un langage qui permet la modélisation d’une
architecture conceptuelle d’un système logiciel. Il fourni
une syntaxe concrète et une structure générique (framework) conceptuelle pour caractériser les architectures. Le
“framework” conceptuel englobe généralement la théorie
sémantique sous-jacente à l’ADL.
Les ADL sont généralement orientés vers la mise en
exergue des constituants majeurs de la structure afin
d’en montrer leurs interconnections. Dans le domaine
particulier des architectures logicielles, on trouve les
notions de composants, de connecteurs et de configuration
(i.e. topologie)[2]:
◦ Composants :
Un composant est un élément
élémentaire d’une architecture (élément de calcul ou
de stockage d’information). Il requiert ses propres
données et/ou son propre espace d’exécution qu’il
peut partager avec d’autres composants.
Un composant est généralement décrit par son
interface, les types, la sémantique, les contraintes et
les évolutions.
◦ Connecteurs :
Les connecteurs permettent de
représenter les interactions entre les différents composants ainsi que les règles auxquelles sont assujetties
ces interactions.
A la différence des composants, un connecteur n’est
pas une unité de compilation dans l’implémentation
du système.
Les connecteurs sont généralement décrits par leur
interface, les types, la sémantique, les contraintes et
les évolutions.
◦ Configuration : La configuration architecturale, ou
topologie, est un graphe de composants et de con2 Cf. http://standards.ieee.org/reading/ieee/std public/description/
se/1471–2000 desc.html
2
MASTER 2 RECHERCHE SLCP - MODULE RTM, 2005
necteurs décrivant la structure de l’architecture.
Celle-ci doit spécifier l’architecture de manière suffisament compréhensible. Elle doit également permettre
la composition des différents éléments de l’architecture
tout en respectant l’hétérogénéité. A l’instar des composants et connecteurs il est capital de pouvoir définir
des contraintes sur la configuration.
A. Différences entre les ADL et les autres langages
Afin de clarifier la définition d’un ADL, il est important
d’en montrer les différences avec les autres notations qui,
bien que similaire, ne sont pas considérées comme des
ADL.
L’ensemble des langages peut être partagé en 3
catégories[2] :
◦ Les langages à configuration implicite où les informations sur la topologie sont distribuées au travers les
descriptions des différents composants et connecteurs,
◦ Les langages à configuration “in-line” qui modélisent
les configurations explicitement, mais spécifient les interconnections entre composants ainsi que leurs protocoles, “in-line”.
◦ Les langages à configuration explicite où les informations sur la topologie ce distinguent des informations
sur les composants et les connecteurs.
L’exigence d’un modèle de configuration explicite distingue les ADL des autres langages de conception de haut
niveau[2].
D’autre part, un ADL englobe une théorie sémantique
formelle dont la spécification peut s’appuyer sur les réseaux
de pétrie, les diagrammes d’état, les machines abstraites,
le formalisme algébrique, etc.[2].
B. Fonctionnalité des ADL
Les ADL peuvent être utilisés dans de nombreux
domaines et leurs fonctionalités sont très diverses[1] :
◦ Analyser à partir de plusieurs points de vue :
Cette méthode d’analyse, utilisée intensément dans
l’ensemble des domaines de l’ingénierie du logiciel, permet de gérer la complexité en séparant les
différents aspects de la représentation.
Bien que la notion de points de vue multiples soit
généralement évoquée dans les méthodes industrielles, beaucoup d’ADL ne supportent pas ce
concept comme, par exemple, UMLpeut le supporter.
◦ Délimiter le problème :
Afin de prendre des décisions architecturales avec
le client, un architecte doit généralement estimer
différent choix de conception en fonction de leurs
implications. Ces choix de conception sont toutefois limités par certaines exigences indépendant du
problème. Les ADL permettent donc de délimiter
le problème en fixant les variables architecturales
indépendantes du problème en question. Par exemple,
il est intéressant de fixer :
- les décisions prises par le client (“exigences”)
- les décisions fixées par l’environnement (hors de
contrôle de l’architecte mais influence fortement le
résultat)
- les décisions prises par l’architecte en réponse aux exigences du client et de l’influence de l’environnement.
Ces décisions doivent être enregistrées de manière à
conserver une bonne traçabilité du projet.
◦ Exprimer les choix architecturaux et leurs niveaux de
liberté :
Le travail d’un architecte s’articule généralement
autour de nombreuses caractéristiques du système
en question. Ces caractéristiques peuvent être structurelles, de style, d’interactions, etc.
Un architecte a généralement besoin d’exprimer ces
caractéristiques au moyen d’un arbre représentant
les degrés d’intention, en relation avec les futures
activités de conception. L’architecte doit donc décrire
les engagements (choix fixés par l’architecte), les obligations (bas niveau de décision donné au concepteur)
et les choix libre de décision pour le concepteur.
L’approche “MIL-SPEC”, par exemple, reprend ces
concepts avec les notion de will, shall et may.
◦ Définir les contraintes architecturales :
Bien que les composants et les connecteurs soient
des constructeurs généralement acceptés dans les
architectures logicielles, un consensus est récemment
né sur l’expression de leurs définitions et de leurs
contraintes.
Dans les ADL, les contraintes sont généralement
modélisées sous la forme de prédicat sur une entité
d’intérêt (par ex.
EcrireEnAda(ceServeur) qui
exprime une contrainte possible sur le composant
ceServeur ).
Ces contraintes architecturales sont généralement
caractérisées par un nom, un type, une expression et
un ensemble d’éléments sources et cibles.
◦ Indépendance par rapport à l’implémentation :
De nombreux ADL possèdent un modèle d’exécution
implicite. Il est pourtant important de conserver
une liberté de choix d’implémentation et de pouvoir
retarder ce choix au maximum dans le cycle de vie
d’un produit. Les ADL doivent donc s’appuyer sur un
modèle d’exécution plus abstrait et plus générique qui
permettrait une plus grande indépendance vis-à-vis
de la plateforme d’exécution.
◦ Quantifier :
Les quantifications de la logique de premier ordre
(∀, ∃) ainsi que les autres types de quantification
(comme la décision) augmentent l’expressivité d’un
langage et sont utile dans de nombreux cas. Ces
pourquoi certains ADL reprennent ces notions de
quantification dans leur syntaxe et leur sémantique.
Benoı̂t Combemale & Sylvain Rougemaille: LES ADL
Les quantificateur ∀ et ∃ ce retrouvent par exemple
dans le langage Acme sous les notions de “multiple”
et “optional”.
◦ Créer des patrons d’architecture :
De nombreux travaux actuels dans la conception logicielle et les architectures sont centrés sur l’articulation
de patrons et de styles. Pour permettre leurs supports, les ADL doivent être suffisamment modulaire
afin de permettre l’expression d’entité individuelle.
Les ADL courant le permette pour les composants
mais pas pour les connecteurs et les contraintes.
Enfin, de récents travaux ont permis l’interactivité entre
les différents ADL. On citera par exemple ACME, présenté
comme une architecture d’échange de langage en rendant
possible l’interaction et la coopération de différents ADL.
IV. Les outils support d’un ADL
L
ES ADL sont généralement supportés par un ou
plusieurs outils permettant une manipulation aisée
du langage. Ces outils, en plus de supporter l’ensemble
des fonctionnalités du langage, offrent certaines fonctionnalités supplémentaires[2] :
◦ Gestion des erreurs :
Chaque outil propose une gestion des erreurs de
manière proactive (tache permanente vérifiant
les erreurs pouvant survenir au moment de la conception) ou réactive (détection des erreurs existantes).
◦ Intéraction de différentes vues :
La plupart des outils proposent les deux vues basiques
d’une architecture : textuelle et graphique. La gestion
de vues supplémentaires est beaucoup plus rare.
◦ Analyse de la description architecturale :
A partir du modèle sémantique de l’ADL, chaque
outil propose la vérification d’un certain nombre de
propriétés et le contrôle du respect des contraintes.
◦ Raffinage d’architecture :
Le raffinage architectural trouve son importance à
travers l’utilisation des styles et la manipulation de
différents niveaux de détails. Les outils supportant
cette fonctionnalité sont toutefois rares.
◦ Génération de code :
L’ultime objectif de la conception d’un logiciel est de
fournir une application exécutable. C’est pourquoi,
un grand nombre d’outil support d’un ADL (mais pas
tous) permettent la génération de code C++, Java,
Ada, etc.
3
V. Préssentation d’ADL représentatifs :
A. Présentation d’ADL existants :
◦ ACME :
Le projet ACME3 , commencé en 1995, a pour
principal but de fournir un langage commun permettant l’échange de descriptions architecturales
entre plusieurs outils de conception d’architecture.
Il s’agit d’un langage de description d’architecture
logicielle fournissant une base conceptuelle abstraite
et suffisamment générale pour permettre la description de nouveaux outils et notations. Il fournit
un outil de conception graphique (ACMEStudio),
une bibliothèque (ACMElib) fournissant une infrastructure complète de manipulation de descriptions
d’architecture et un outil de génération de documentions HTML (ACMEweb).
◦ Rapide :
Rapide[3], développé par David Luckham à Stanford,
est un langage de simulation d’objets concurrents
basé sur les événements et qui s’appuie sur le principe
de posets4 . Il permet la description et la simulation
du comportement de systèmes à objets répartis.
Cette simulation est représentée par un ensemble
d’événements (posets) ordonnés par rapport au temps
et en respectant la causalité inter-événement.
◦ AADL :
AADL5 [4] est un langage d’analyse et de conception d’architecture basé sur l’ADL MetaH qui fut
développé dans les années 90 pour la description
d’architecture de systèmes embarqués avioniques. Il
est donc orienté vers la specification de système embarqués temps-réel mais pas uniquement avioniques.
C’est un langage textuel permettant de manipuler les
flots de contrôles et de données et de décrire les aspects non-fonctionnels importants liés à ces systèmes
(exigences temporelles, fautes, propriétés de sûreté et
de certification,etc.).
B. Utilisation d’UML comme ADL :
La description architecturale d’un système peut ce faire
à partir de langages spécifiques (ADL) mais également à
partir de notations génériques existantes. Ainsi un certain
nombre de travaux [5], [4] s’orientent sur l’utilisation de la
syntaxe et du vocabulaire d’UML pour la conception non
seulement des applications, mais aussi des architectures
matérielles. Il s’agit donc d’utiliser UML comme un ADL.
En effet la notation UML, depuis sa nouvelle version
2.0[6], introduit la notion de composant et de diagramme
structurel facilitant la modélisation d’architecture. UML2
considère également les notions de description matérielle
et de mapping.
3
4
5
Cf. http://www-2.cs.cmu.edu/~acme/
Partialy Ordered Set of Events
Architecture Analysis & Design Language
4
MASTER 2 RECHERCHE SLCP - MODULE RTM, 2005
L’approche de l’INRIA[5] vise à spécialiser un sousensemble d’UML au travers d’un profil générique
permettant la définition de règles syntaxiques et d’une
sémantique. L’application et l’architecture matérielle
sont alors décrits par deux metamodèles au sein desquels
les concepts sont similaires. Ceci afin de pouvoir simplifier leurs compréhensions et permettre l’unification
de ces deux méta-modèles. Cette unification ce fait au
sein d’un troisième méta-modèle, appellé méta-modèle
d’associations, exprimant les associations entre les
composants fonctionnels du modèle applicatif et les
composants matériels (abstraction d’élément matériel
physique) du modèle d’architecture. Cette approche peut
donc être formalisé comme sur la figure 1.
Fig. 1. Approche en Y
Comme présenté ci-dessus, AADL est dans sa version
actuelle un langage textuel. Des travaux sont en cours
pour en définir une version graphique basée sur UML[4].
VI. Conclusion
L’étape de description architecturale est de plus en
plus fréquente dans la phase de conception d’un logiciel.
Elle offre au concepteur un niveau d’abstraction plus
élevé en lui permettant de ne pas prendre en compte les
détails de l’architecture. Seuls des concepts architecturaux
complètent la conception et permettent ainsi de la rendre
totalement générique par rapport à une architecture
particulière. Les travaux de conception pourrons alors
être réutilisés ou instantiés sur différentes plateformes.
Pour cela de nombreux travaux de Recherche ont aboutis
sur la création de langages de description d’architecture.
Ces langages sont spécifiques à un domaine particulier ou
transversaux dans l’activité de description architecturale.
Ils peuvent également ce baser sur une syntaxe bien
particulière ou sur des standards génériques comme UML.
Pour améliorer la manipulation de ces langages, ils sont
générallement fournis avec un outils qui apporte une
certaine productivité dans l’étape de description architecturale.
References
[1] R. Hilliard and T. Rice, “Expressiveness in architecture description languages,” 2000.
[2] N. Medvidovic and R. N. Taylor, “A framework for classifying and comparing architecture description languages,”
in Proceedings of the Sixth European Software Engineering
Conference (ESEC/FSE 97), M. Jazayeri and H. Schauer,
Eds. Springer–Verlag, 1997, pp. 60–76. [Online]. Available:
http://citeseer.ist.psu.edu/medvidovic97framework.html
[3] C. S. L. S. university, “Guide to the rapide 1.0 - language
reference manuals,” Tech. Rep., July 1997. [Online]. Available:
http://pavg.stanford.edu/rapide/
[4] A. Ingénierie, “Aadl,” Tech. Rep. [Online]. Available: http:
//www.axlog.fr/R d/aadl/presentation fr.html
[5] A. Cuccuru, P. Marquet, and J.-L. Dekeyser, “Uml2 as an
adl - hierarchical hardware modeling,” Tech. Rep., Apr. 2004.
[Online]. Available: http://www.inria.fr/rrrt/rr-5166.html
[6] O. M. Group, “Uml 2.0 specification,” Tech. Rep. [Online]. Available: http://www.omg.org/technology/documents/
modeling spec catalog.htm#UML