Les Langages de description d`architectures

Adaptation d'un langage de description d'architecture à
l'expression du comportement ; applications.
Christophe Mareschal
ONERA-Supaéro, LIA
10 avenue Edouard Belin
31055 Toulouse cedex
1
Introduction
Depuis le début des années 90, la communauté de l'ingénierie du logiciel a développé des techniques
centrées sur la description de l'architecture des systèmes [IEEE1471]. Celles ci ont été élaborées à de mutiples
fins : améliorer la compréhension et la conception des systèmes complexes, favoriser leur évolution et leur
réutilisation, procéder à diverses analyses, faciliter la construction et le déploiement, ou encore aider à la gestion
de configuration. Ces techniques se sont concrétisées au travers de langages spécifiques, les ADL's (Architecture
Description Language), et l'outillage associé [MT00].
Plusieurs travaux actuels vont dans le sens de l'unification ou de la standardisation de ce type de langage
pour les rendre plus utilisables. L'aboutissement de ces recherches permettrait de palier les difficultés de
cohérence et de compréhension des modèles dues à la multiplicité et à la spécificité des langages, ou encore de
surmonter les problèmes d'interopérabilité issus de la variété des formats. Un voie s'est ouverte avec le travail
effectué à UCI (University of California, Irvine) qui a élaboré un ADL modulaire et hiérachisé, xADL2.0, isolant
ainsi le fondement générique des ADL's, et laissant la voie ouverte vers la spécialisation par l'extension. Nous
proposons dans cet article d'étendre xADL2.0 à un domaine qu'il ne couvre pas encore, l'expression du
comportement, pour en faire un langage d'analyse.
La démarche nous permet en outre de démontrer la possibilité de construire sur la base d'un ADL
spécialisable, une infrastructure d'outils souple et adaptable où l'analyse côtoie la conception, l'implémentation et
le contrôle de la configuration. L'architecture de cette infrastructure se fonde sur une description unique du
système agissant comme base de données de référence et pouvant être utilisée de multiples manières par des
outils spécialisés. La mise en œuvre de ce modèle d'infrastructure fait appel aux technologies XML déjà
largement mises à profit dans le projet xADL2.0.
Après avoir introduit les ADL's et les techniques XML utilisées, nous présentons xADL2.0. Ce dernier n'a
pas été conçu pour exprimer et analyser le comportement des systèmes, son objectif premier étant la fourniture
d'un support pour la gestion de configurations. Pour la modélisation du comportement, nous avons choisi
d'utiliser AltaRica, un langage qui permet de représenter les systèmes sous forme d'automates à contraintes, pour
l'inclure dans le champ d'expression d'xADL2.0. C'est ce que nous expliquons plus en détail dans la partie
consacrée à l'extension d'xADL2.0 que nous avons développée (que nous appelons xADL2.0*). Nous présentons
pour finir l'applications de nos résultats : l'adaptation des outils, l'interopérabilité xADL2.0* et AltaRica, et une
proposition de modèle générique d'infrastructure d'outils évolutive et adaptable.
2
2.1
Techniques support
ADL
Les ADL's sont une famille de langages élaborés dans les années 90 dans le domaine de l'ingénierie du
logiciel. Ils ont en commun une capacité à décrire l'architecture des systèmes mais diffèrent largement quant à
leurs motivations et leurs formalismes d'écriture. Ils sont en général graphiques et textuels et possèdent des outils
associés. Le tour d'horizon qui suit donne une indication sur la diversité des concepts et des usages couverts par
ce type de langage:
• Aesop (D. Garlan & al, CMU, 1994): Développement d'applications fondé sur la notion de style
architectural. [DG95], [Aesopweb].
• Darwin (J. Magee, Impérial College, 1994): Configuration et instanciation dynamique des systèmes
distribués. [MDEK95], [DarwinRef], [Darwinweb].
• C2 (R. N. Taylor, N Medvidovic, UCI, 1995): Architectures évolutives ou dynamiques, C2 s'appuie sur un
style d'architecture logiciel en couche et des communications par échange de message. [TMAWR95],
[ISRpub], [C2web].
• Rapide (D. C. Luckham, 1995): Modélisation, simulation et analyse du comportement dynamique d'un
système à l'exécution. Rapide se fonde sur le concept de posets (Partial Ordered event Sets). [DL96],
[Rapideweb].
1
•
•
•
•
•
•
UniCon (M. Shaw, CMU, 1995): Construction et vérification d'architectures à partir d'éléments
architecturaux prédéfinis. [SDKRTZ95], [GZ96], [UniConweb].
MetaH (S. Vestal, Honeywell, 1995): Conception, vérification, validation, assemblage et déploiement de
système temps réel critique (Avionique embarquée). [MetaHRef], [MetaHweb].
Wright (R Allen, D Garlan, 1997) Vérification formelle, absence de blocage, Wright décrit formellement le
comportement d'une architecture à l'aide de CSP (Communicating Sequential Process).[RA97],
[Wrightweb].
SADL : Structural Architecture Description Langage (M. Moriconi, SRI, 1997) Raffinement formel
(traçabilité des variantes et des évolutions).[MQRG97], [SADLweb].
Acme (D Garlan, R Monroe, D Wile, CMU, 1997) Interchange, Acme a été conçu comme langage
passerelle pour permettre aux différents ADL's d'intéropérer. Cette vocation l'a conduit à se définir comme
langage d'architecture générique. [GMW97], [Acmeweb].
Olan (L Bellissard, M Riveill, INRIA Rhône Alpes, 1995) Développement, configuration, déploiement et
administration d'applications réparties.[LB97], [Olanweb].
Il n'y a pas de définition officielle de ce qu'est un ADL. La définition admise est qu'un ADL spécifie les
composants d'un système, leurs interfaces, les connecteurs (lieux d'interaction entre les composants), et la
configuration architecturale. A partir de cette définition minimale, chaque ADL possède des caractéristiques de
modélisation propres liés à sa motivation et à son usage [MT00].
Aussi, bien souvent élaborés de façon ad hoc pour répondre à des besoins particuliers, les ADL's n'ont pas
réussi à surmonter les obstacles d'incompatiblilité, de non portabilité, de multiplicité et de complexité, d'absence
1
de standardisation, etc., ce qui leur aurait permis de dépasser le cadre de leur niche d'origine et de s'imposer
comme langages de référence.
Une réponse a été trouvée en intégrant la technologie XML et ses dérivés pour la spécification, la
manipulation et l'utilisation des langages [PSSC98]. C'est ce qui conduit à la respécification de certains ADL's
par les métalangages d'XML (DTD et XML schema), ou à une redéfinition nouvelle générique et hiérarchisée :
•
•
•
•
•
•
Les DTD's
xADL1.0 (R. Khare, 1999) , dérivé de C2 [KGOMT01].
ADML (Open Group, 2000) , dérivé d'Acme [ADMLweb]
xOlan (L Bellissard & al, INRIA Rhône-Alpes, 2001) , dérivé d'Olan
Les schémas
xArch (E Daschofy, D Garlan, A. van der Hoek, B Schmerl, UCI, CMU, 2001) ADL à minima
[xArchweb].
xAcme (B Schmerl , CMU, 2001) extension d'xArch, inspiré d'Acme [BS01], [xAcmeweb]
xADL2.0 (E Dashofy, UCI, 2001) extension d'xArch, hiérarchisé et spécialisé "famille de produit"
[xADLweb]
Signalons également l'effort de standardisation du projet AADL [AADLweb], "Avionic ADL". AADL est
très inspiré de MetaH, et reste orienté système temps réel (critique) embarqué. Si AADL est pour l'heure défini
avec UML Profile, une version XML est prévue2 [FLV03].
2.2
XML
XML est un monde vaste regroupant des langages et des techniques; nous ne présentons ici que l'essentiel
utile dans notre démarche.
• XML Schema: DTD et XML Schema sont les deux métalangages d'XML. Ils permettent de spécifier les
règles syntaxiques que doit respecter à un document, dans notre cas les descriptions d’architecture. Les
schémas sont une alternative aux DTD plus récente et plus puissante. Ils y apportent quelques améliorations
comme l'adhérence à XML, des mécanismes forts de typage et d'héritage, et des mécanismes d'importation
qui permettent de modulariser les définitions en plusieurs schémas.
• XML parser : Les données contenues dans un document écrit au format XML sont lues et analysées par des
analyseurs syntaxiques dont le rôle est de décoder les balises ; ceci permet d'une part de vérifier la syntaxe,
d'autre part d'offrir aux applications clientes l'accès aux données dont elles ont besoin. Les deux types
d’analyseurs syntaxiques de base sont SAX (Simple API for XML ) et DOM API (Document Object Model
API). Ce dernier permet de représenter en mémoire le document sous la forme d'un arbre syntaxique, le
1
A part MetaH conçu par Honeywell, les ADL's proviennent généralement du monde académique.
Par Ed Colbert (USC) dans le cadre d'un projet de développement d'outils autour d'AADL, pour plus de détail voir
http://sunset.usc.edu/classes/cs577a_2003/projects/description/project8.htm
2
2
DOM, sur lequel les applications effectuent navigations et manipulations. Les parseurs vérifient et valident
la conformité syntaxique d'un document avec XML, et avec les définitions syntaxiques qui lui sont associées
dans les DTD's ou les Schémas .
• XSLT, XML Stylesheet Language, Transformation : XSLT permet de spécifier les règles de transformation
qui, appliquées à un document source XML permettent de produire un autre document sous une forme
voulue (conforme à un autre langage XML, ou mis en page en HTML, en PDF, etc.). Ces règles sont
contenues dans un document appelé feuille de style. Les processeurs XSLT permettent d'automatiser la
traduction des descriptions d'un formalisme à un autre.
• XLL (Xlink), XML Linking language (Xlink): XLink est le langage de lien d'XML. Il préserve la simplicité
des mécanismes de liaison de HTML en l'enrichissant (liens multidirectionnels, externes, comportement et
sémantique du lien). xADL2.0 utilise XLink de la façon la plus simple (liens unidirectionnel), ce qui lui
procure un système de pointeur.
• XQL, XML Query Language. XQL, comme son nom l'indique est le "SQL" d'XML. Il permet de concevoir
les requêtes destinées à chercher, filtrer, extraire des éléments de documents XML (des fragments) . Nous ne
l'utilisons pas dans le cas présent mais nous considérons qu'XQL peut représenter une alternative à XSLT.
• XML Data Binding : Ce n'est pas une norme XML mais c'est une pratique qui tend à se développer et qui
permet de rapprocher XML avec les langages orientés objets (en particulier Java), et par conséquent les
documents de leur représentation en mémoire. Le Data Binding consiste à produire du code orienté objet (en
l'occurrence du code Java) à partir des items XML; ceci en dérivant de façon systématique des classes et des
interfaces en correspondance avec le contenu des schémas. La représentation interne du document XML
après le parsing sera constituée d'éléments instances de ces classes et non d'objets XML comme dans le
DOM. En pratique, cela permet de manipuler des objets spécialisés avec des noms de classes, des noms
d'attributs, des constructeurs et des prototypes de méthodes (accesseurs et modifieurs) conformes à la
syntaxe définie dans les schémas. Cette technique peut s'avérer très utile s'il s'agit de développer ou
d'adapter de l'outillage où on manipule des objets d'architecture. Des processeurs permettent d'automatiser la
génération des interfaces et des classes directement dérivées des schémas. Nous verrons par la suite
qu'ArchStudio 3, l'environnement de développement associé à xADL2.0 s'appuie sur cette technique3.
2.2.1
Outils XML
Beaucoup d'outils ont été développés autour d'XML, sous forme d'API, ou d'environnements. Certains sont
gratuits ; on citera:
• Java WSDP (Java Web Service Developer Pack), gratuit, le package de SUN centré autour du
développement web. JWSDP contient JAXP (Java APIs for XML Processing) incluant les parseurs et les
processeurs de transformation, et JAXB (Java Architecture for XML Binding) pour le Data Binding
[JWSDPweb].
• Saxon, développé par M. Kay, un processeur XSLT open-source. La dernière version ajoute un processeur
xQuery. [Saxonweb].
Dans le cadre de développement XML, l'utilisation d'environnements XML commerciaux est souhaitable. Ils
sont plus complets, et bien documentés (guides utilisateur et tutoriels).
• TIBCO Extensibility, commercial avec clé d'évaluation gratuite 30 jours, une suite d'outils XML incluant
éditeurs (TurboXML) et outils de mapping et de tranformation (XMLTransform) [TIBCOweb]
• XMLSpy, MapForce, commercial avec clé d'évaluation gratuite 30 jours, un ensemble complet d'outils
XML. Actuellement c'est la référence en la matière.[Altovaweb]
2.3
xADL2.0 [xADL2.0web], [DHN01], [DH01].
2.3.1
Origine et particularité
xADL2.0 est un ADL développé par UCI (University of California, Irvine) dans le cadre de recherches
autour de la gestion de configuration d'architectures dynamiques et distribuées. Dès l'origine, xADL2.0 a donc
été défini pour être, avec les outils qui le supportent, fortement extensible, flexible et adaptable afin de servir aux
expérimentations au fur et à mesure de l'avancée des recherches.
A cet effet xADL2.0 s'appuie sur XML, plus exactement XML Schema. Il est défini par un ensemble de
schémas XML, chacun supportant une partie du langage. Ainsi construit de façon modulaire, il peut être étendu
par de nouveaux modules sans risque de modification régressive, de plus il est hiérarchisé, ce qui lui laisse la
possibilité d'avoir des extensions spécialisées et de s'adapter à des usages spécifiques. C'est pourquoi, même si à
l'origine il a été élaboré pour l'étude de la gestion et du dynamisme de la configuration, il offre une base solide et
3
Les concepteurs d'ArchStudio 3 ont également développé un générateur automatique de classes et d'interfaces dérivées
appelé Apigen car à cette époque, en 2001, la technique n'était pas encore bien répandue et les outils proposés immatures.
3
stable à une ou plusieurs extensions comme l'expression du comportement et on peut dès lors imaginer l'adapter
à l'analyse des propriétés.
2.3.2
La base générique xArch
A l'origine d'xADL2.0, il y a eu le développement conjoint par UCI et CMU (Carnegie Mellon University)
d'un schéma de base appelé xArch [xArchweb] sur lequel se fonde également xAcme [xAmeweb]. xArch se veut
générique en offrant l'essentiel des éléments de la représentation architecturale. C'est l'ADL a minima. Il inclut
les quatre éléments fondamentaux de l'architecture, composant, connecteur, interface et configuration, offre en
outre un mécanisme de composition hiérarchique et un mécanisme de groupage arbitraire.
xArch est entièrement défini dans un schéma appelé instance.xsd dont voici une image simplifiée
xArch
ArchInstance [0..*]
ComponentInstance [0..*]
InterfaceInstance [0..*]
Direction (in, inout,out) [0..1]
SubArchitecture [0..1]
ArchInstance
InterfaceInstanceMapping [0..*]
outerInterfaceMapping -- pointeur vers une interface du composant père -innerInterfaceMapping -- pointeur vers une interface d'un composant fils -ConnectorInstance [0..*] -- même composition que ComponentInstance -LinkInstance [0..*]
Point [2]
anchorOnInterface -- pointeur vers une interface -Group [0..*]
member -- pointeur vers ce qu'on veut --
Figure 1 : le meta-modèle xArch4
2.3.3
Les extensions xADL2.0
xADL2.0 étend xArch, l'ensemble est à ce jour composé de neuf schémas reliés entre eux par des relations
5
de dépendance .
xArch
Sturcture & Types
Variants
Options
Abstract Implementation
Versions
Stuctural Diffing
BooleanGuard
Java Implementation
Message Rules
Figure 2 : le diagramme des schémas xADL2.0
•
•
•
Les schémas d'xADL2.0 s'articulent autour de trois domaines d'expression (tableau 1) :
La modélisation de l'architecture : Le premier groupe de schémas sert à la modélisation descriptive (xArch)
ou prescriptive (Structure & Types) de l'architecture. La différence entre les deux approches réside dans le
fait que l'une, l'approche prescriptive, concerne la conception et utilise les mécanismes de typage, l'autre,
l'approche descriptive, concerne l'exécution et se fonde sur des instances.
Le mapping avec l'implémentation : Les ADL's ont montré depuis leur début l'intérêt de spécifier le
mapping entre les éléments de la description et leur implémentation. C'est par ce biais que des outils peuvent
instancier et manipuler le système à l'exécution à partir du modèle.
La gestion de la configuration architecturale: Il s'agit d'appliquer les outils de gestion de configuration
traditionnels, comme la spécification des options, des versions et des variantes, aux éléments architecturaux
et à l'architecture elle même.
A noter que la description du comportement ne fait pas partie des préoccupations des auteurs de xADL2.0.
4
La figure 1 représente la syntaxe de façon hiérarchique, l'occurrence des instances de chaque élément est représentée entre
crochet, l'absence de crochet signifie qu'une et une seule instance de l'élément est obligatoire. Les commentaires sont en
italiques.
5
XML schema offre des mécanismes d'import et d'include qui permet à un schéma d'utiliser, voire de dériver des items d'un
autre schéma.
4
Purpose
Architecture
Modeling –
Description
&Prescription
Instanciable
Architecture
Architecture
Configuration
Managment /
Product Family
Archirtecture
Schema
Features Provided
xArch Instance
Java Implementation
Options
Component, connector, interface & link instances; arbitrary groups;
hierarchical construction.
Design-time architectural prescription; architectural structure (Components,
Connectors, Interfaces & links), programming-language style types-andinstances model; hiérachical construction via type.
Abstract placeholder for implementation information for components &
connectors
Java-spécific implementation information for component & connectors
Optionnal components, connectors & links
Variants
Variant component & connector types.
Versions
Version graphs for components, connectors, & interfaces
Structure & Types
Abstract Implementation
Tableau 1 : xADL2.0 schemas and features provided6
Parmi les schémas qui composent xADL2.0, plus utile à la conception qu'à la gestion de la configuration, le
schéma "Structure & Types" fournit un mécanisme de typage/instanciation à l'image des langages de
programmation classiques. Ce schéma permet de distinguer la description des types de la description des
structures et des instances. A priori, l'analyse d'un système ne nécessite pas cette vision "prescriptive" de
l'architecture, toutefois elle pourrait permettre d'associer aux composants typés des modèles de comportements.
xArch : {ArchStructure [0..*], ArchTypes [0..*]}
ArchTypes
ComponentType
Signature [0..*]
Direction (in, inout,out) [0..1]
type [0..*] -- pointeur vers un InterfaceType -SubArchitecture [0..1]
archStructure -- pointeur vers une ArchStructure -SignatureInterfaceMapping [0..*]
outerSignature -- pointeur vers une signature du composant père -innerInterface -- pointeur vers une interface d'un composant fils -ConnectorType [0..*] -- même composition que ComponentType -InterfaceType [0..*]
ArchStructure
Component [0..*]
Interface [0..*]
Direction (in, inout, out) [0..1]
Type [0..*] -- pointeur vers un InterfaceType -Type [0..*] -- pointeur vers un ComponentType -Connector [0..*] -- même composition que Component -Link [0..*] -- idem archInstance: LinkInstance-Group [0..*] -- idem archInstance: Group--
Figure 3 : le modèle Structure & Types
2.3.4
Outils xADL2.0
Trois outils participent à la spécification, la manipulation et l'utilisation d'xADL2.0 [ED01], [DHN02]:
XML Spy
Apigen
ArchStudio 3
Schémas
xADL2.0
xarchlibs
document de
description
d' architecture
?
légende
outils
données
in
out
Figure 4 : la chaîne d'outils autour d'xADL2.0
•
XML Spy (Altova) ou tout autre environnement de développement XML, pour la spécification, l'édition et
la manipulation des schémas.
6
Ce tableau est extrait de l'article de présentation initial d'xADL2.0 et date de 2001 [DTH01], les schémas BooleanGuard,
StructuralDiffing et Message Rules ont été développés après, ils ne présentent que peu d'intérêt dans le cas présent. Pour plus
d'explication, se reporter au site consacré à xADL2.0 [xADLweb].
5
•
Apigen (UCI), un générateur "data-binding" qui permet de dériver automatiquement en classes et interfaces
Java le contenu des schémas xADL2.0. Ces implémentations sont regroupées dans une librairie appelée
xarchlibs. (pour le data binding , se reporter au chapitre consacré à XML)
ArchStudio 3 (UCI), écrit en Java, est un environnement de développement d'architecture qui supporte
xADL2.0. ArchStudio 3 utilise les implémentations Java obtenues par data binding pour construire les
représentations internes en mémoire des descriptions qu'il traite.
•
Cette chaîne d'outils facilite l'adaptation de l'environnement ArchStudio 3 aux évolutions du langage
xADL2.0. Il fournit aussi un cadre d'interropérabilité pour un possible atelier logiciel composé de plusieurs
outils compatibles XML-xADL2.0.
2.3.5
Archstudio 3 et Apigen [ArchStudioweb]
ArchStudio 3, développé par UCI, est un environnement d'édition, de configuration et d'analyse
d'architectures logicielles fondé sur xADL2.0. A noter que ArchStudio 3 est largement ouvert aux
développements extérieurs. Le site web qui lui est consacré permet d'y trouver un grand nombre d'informations
bien détaillées autant à l'intention des utilisateurs que d'éventuels développeurs.
Les fonctionalités d'ArchStudio 3 sont :
•
•
•
•
L'édition de documents de description d'architecture xADL2.0 (Création, lecture, écriture, enregistrement)
La vérification et la validation syntaxique conforme avec xADL2.0.
La sélection de variantes ou de versions.
L'instanciation et le lancement des applications à partir de leur description architecturale et de
l'implémentation de chaque composant ou connecteur.
Un certain nombre d'analyses (en cours de développement, actuellement non documentées).
•
Notons l'interface graphique de l'éditeur, adaptable en fonction de l'évolution du langage. L'IHM de l'éditeur
s'appuie sur une représentation de l'arbre syntaxique de la description (cadre de gauche). approche qui permet
une accessibilité visuelle pratique et rapide, ainsi que le pliage et le dépliage de l'arbre à volonté en fonction de la
zone manipulée. Son adaptation suite au modification des schémas, et qui concerne les menus contextuels et les
cadres de saisies est réalisée automatiquement après recompilation par Apigen de la librairie xarchlibs (figure 4).
description de
l'architecture
menu contextuel
de composition
Champ de saisie des
valeurs d'attributs
Figure 5 : L'éditeur d'ArchStudio 3
Quant à l'ajout de nouvelles fonctionnalités, elle est facilitée d'une part par le data binding (le développeur
maîtrise les objets du modèle représenté en mémoire, il en connaît la composition et l'interface) et par
l'architecture de style C2 [C2web] d'ArchStudio 3 (voir le tour d’horizon sur les ADL’s en début de document).
Sans entrer dans les détails, précisons que le style d'architecture C2 est aussi fait pour favoriser le développement
et l'intégration de nouveaux composants dans une architecture.
2.4
AltaRica [AltaRicaweb]
2.4.1
But du langage
"Le langage AltaRica a été conçu pour spécifier formellement le comportement de systèmes en présence de
fautes et exploiter ces spécifications à l'aide d'outils complémentaires : simulateur symbolique, model-checker,
générateur d'arbre de défaillance" [CS01].
6
2.4.2
Syntaxe et sémantique
[APGR03]
Avec AltaRica, un système est modélisé sous la forme d'automate à contraintes. Le système est décrit de
façon hiérarchique (arborescente) par trois types de nœuds : un sommet (main), des nœuds intermédiaires et des
nœuds feuilles. Sauf s'il n'existe qu'un niveau de hiérarchie, le nœud main est assimilable à un nœud
intermédiaire, il correspond au système. Les nœuds sont décrits comme des automates, des assertions permettent
de contraindre leurs comportements aux seuls cas possibles. Voici l'essentiel du langage :
AltaRica
Node Main
Node Intermédiaire [0..*]
Node Feuille [0..*]
Node (Feuille et intermédiare)
Name -- unique -Flow [0..*] -- variables de flux -Domain -- domaine de valeurs, type -Way -- in, out -State [0..*] -- variables d'états -Domain -- domaine de valeurs, type -Event [0..*] -- événements (constantes symboliques) -Trans [0..*] -- dynamique des états du nœud ---- triplet <garde, évenement, affectation sur les variables d'état> -Assert [0..*] -- contraintes sur les configurations (valeurs des variables) -(Node Intermédiaire uniquement)
Sub [0..*] -- sous-nœuds (=instances de nœuds) de la forme Id.nodeName-Sync [0..*] -- contraintes de simultanéité entre les événements du nœud père et ceux des nœuds fils --
Figure 6 : Le méta-modèle AltaRica
Actuellement AltaRica est en cours de stabilisation, une variante temporisée, TimedAltaRica [CP03],
devrait lui permettre d'étendre son champ d'application à l'évaluation des performances et l'analyse des systèmes
temps réels.
2.4.3
Outils AltaRica
Divers outils traitent les modèles AltaRica et permettent l'édition, la génération et l'analyse d'arbres de
défaillance, de diagrammes de décision, la génération de séquences d'événements, la simulation graphique, le
model checking, l'analyse stochastique, la compilation en modèles de plus bas niveau (Réseau de Petri), la
conversion depuis et vers Lustre, etc. On peut citer :
•
•
•
•
3
3.1
Altatools (LaBRI) : Model-Checker, traducteur depuis et vers Lustre, Simulateur, …
AltaRica DataFlow Toolbox (ARBoost Technologie) : Génération d'arbre de défaillance, simulateur
graphique, analyseur de chaînes de Markov, simulateur stochastique, générateur de séquences, …
CECILIA AltaRica OCAS (DASSAULT, GFI) : Interface de conception graphique, simulateur graphique,
générateurs de modèles (arbres de défaillance, modèles stochastiques), générateur de séquences, …
Les outils Externes : ARALIA (analyse des arbres de défaillance), SMV (model checking), Moca-RP
(réseau de Petri), UPPAAL (vérification de système temps réel), …
Extension d'xADL2.0 au comportement
xAltarica [xAltaricaweb]
Afin de faciliter le mapping avec xADL2.0, et par la suite l'interropérabilité entre les deux langages, une
première étape a consisté à établir la spécification du langage AltaRica par des schémas XML que nous avons
nommés xAltarica. xAltarica profite de la modularité permise par XML Schema. Trois schémas ont été
développés et un importé :
utils.xsd
<<uses>>
alarica.xsd
<<uses>>
.xArch
timedaltarica.xsd
Figure 7 : xAltarica
•
altarica.xsd qui sert à représenter le méta-modèle AltaRica. altarica.xsd inclut Architecture, Component,
Flows, Flow, Events, Event, States, State, Transition, Assert, Composition, Sub, Sync, Configuration, etc.
7
•
•
•
utils.xsd qui rassemble les outils mathématiques comme les expressions logiques et arithmétiques utilisées
par les assertions tels ArithmeticExpression, ArithmeticValue, ComparisonExpression, BooleanExpression,
BooleanValue, Constant, Variable, Value, etc.
timedAltarica.xsd qui étend les termes d’altarica.xsd pour intégrer des attributs temporels.
timedAltarica.xsd est en attente de la version stable de Timed AltaRica.
instance.xsd (schémaq d'xArch) : Nous utilisons également quelques éléments génériques contenus dans le
schéma instance.xsd tels XMLink, Description, Direction et Identifier7.
xAltarica ne change en rien la sémantique d'AltaRica. Seules, quelques modifications d'ordre syntaxique y
ont été apportées. L'une sur le terme "Assert" décomposé en deux termes "Assert" et "Configuration", dans le but
de distinguer configuration topologique et configuration comportementale, une autre par l'ajout d'une clause
"Composition" dont l'intention est d'encapsuler les caractéristiques de composition Sub, Sync et Configuration
des composants composites (nodes main et intermédiaires). Enfin, "Node" prend le nom de "Component".
AltaRica
Node
Name
Flow
State
Event
Trans
Extern
Init
Assert
Sub
Name
: NodeName
Sync
Assert
xAlatrica
Component
Identifier
Flow
State
Event
Trans
Extern
Init
Assert
Composition
Sub
Identifier
#Component
Sync
Configuration
Tableau 2 : d'AltaRica à xAltarica
A noter que xAltarica est un outil qui peut interresser par lui même la communauté des utilisateurs et des
développeurs d'AltaRica, en particulier les outilleurs.
3.2
Comparaison xAltarica, xADL2.0
Le mapping entre xAltarica et xADL2.0 permet de mettre en évidence les ressemblances et les différences
pour finalement déterminer la partie qui manque à xADL2.0 pour exprimer le comportement.
Quelques observations préliminaires :
• Les deux langages possèdent un mécanisme de composition.
• Le typage, explicite dans xADL2.0 (Schéma Structure & Types) est implicite dans AltaRica lors de
l'instanciation des nodes dans les termes "sub" ( Name:NodeName ).
• AltaRica ne définit pas de façon explicite la configuration (les liaisons), cela à été ajouté à xAltarica.
• AltaRica ne définit pas la notion de "connecteur". Cette notion est, soit supportée par des composants, soit
implicitement incluse dans les liaisons qui connectent les flots. Enfin, la synchronisation des évenements
("sync") pourrait aussi être considérée comme un connecteur.
• xADL2.0 ne possède aucun mécanisme de description de comportement des composants.
• xADL2.0 définit les "interfaces" de façon générale, AltaRica distingue les "events" et les "flows"
• xADL2.0 à l'heure actuelle ne considère pas les "interfaces" comme des variables.
Du fait des deux styles de description possibles avec xADL2.0, descriptif (xArch Instance) ou prescriptif
(Structure & Types), il est préférable de procéder aux deux projections d'xAltarica, l'un sur le schéma xArch
(tableau 3), l'autre sur le schéma Structure & Type (tableau 4).
7
Deux raisons ont poussé à ce choix , faciliter le mapping avec xADL2.0 en partageant les mêmes items, et rester compatible
avec Apigen et ArchStudio.
8
xAltarica
AltaricaModel ---------------------------
xArch
xArch
ArchInstance
ComponentInstance
--- Identifier
--- InterfaceInstance
?
------ Direction
--- InterfaceInstance
?
?
?
--- Subarchitecture
ArchInstance
----------- ComponentInstance
?
---------------- Identifier
Component ------------------------------Identifier --------------------------Flow ------------------------------Domain --------------------Direction -----------------Event -----------------------------State ------------------------------Trans -----------------------------Assert ---------------------------Composition ------------------------Sub -----------------------#Component ------Id (instance) ---------------------Configuration
SubLink ------------HiérachicLink -----Sync -----------------------? -------------------------------------------
----------- Link
--- InstanceInterfaceMapping
?
ConnectorInstance
Tableau 3 : xAltarica - xArch
xAltarica
AltaricaModel ------------------------Component ---------------------------Component ---------------------------Identifier ------------------------Flows ---------------------------Domain ------------------Way ---------------------Event ----------------------------State -----------------------------Trans ----------------------------Assert ---------------------------
Structure & Types
xArch
ArchStructure
ComponentType
--- Identifier
--- Signature
------ InterfaceType
------ Direction
--- ? ou Signature
--- ?
--- ?
--- ?
Subarchitecture
#Archstructure
------------ Component
------------------- Identifier
Interface
------------------- #ComponentType
Composition
Sub ---------------------------------Identifier ----------------# Component -------------------Configuration
SubLink -----------------HiérachicLink ----------Sync ---------------------? ----------------------------------------? ----------------------------------------Domain ---------------------------------
---------- Link
--- SignatureInterfaceMapping
?
ConnectorType
Connector
InterfaceType
Tableau 4 : xAltarica - Structure & Types
légende des tableaux 3 et 4
item------- | -----item : correspondance entre item xAltarica et item xADL2.0.
item------- | ----? : absence d’item correspondant.
#item : référence vers item à travers un lien XML.
Le premier tableau fait apparaître une difficulté pour identifier les sous composants (sub), problème qui ne
se pose pas dans le deuxième. Ceci nous a fait préférer le style plus prescriptif du deuxième tableau, d'autant
qu'ainsi, nous conservons le mécanisme de typage d'xADL2.0 qui facilite l'écriture. Sans ce mécanisme, chaque
composant est une instance et doit être décrit entièrement. Remarquons que dans ce cas le comportement d'un
composant est associé à son type.
Le tableau fait apparaître les items à rajouter pour completer xADML2.0, pour l'essentiel il s'agit de :
• La description du comportement interne des composants : Event, State, Trans, Assert
• La syncronisation des événements au niveau des sous architectures. (Sync)
9
3.3
xADL2.0*
Nous avons appelé "xADL2.0*" xADL2.0 étendu à l'expression du comportement. xADL2.0* ajoute les
trois schémas: util.xsd, alatarica.xsd et behavior.xsd à la version d'origine (figure 8) :
xArch
Structure & Types
util.xsd
altarica.xsd
behavior.xsd
Figure 8 : xADL2.0*
utils.xsd, et altarica.xsd sont les schémas d'xAltarica. Utils.xsd permet aux expressions logiques ou
mathématiques d'être écrites non comme des simples strings, mais conformément à leur structure syntaxique
particulière. Ce procédé permet de faire un véritable contrôle syntaxique sur la formulation des expressions. Pour
des raisons de lisibilité et de facilité d'utilisation, l'écriture des expressions par de simples strings reste permise.
L'essentiel de la valeur ajoutée est dans le schéma behavior.xsd. Afin étendre xADL2.0 à l'expression du
comportement certains items du schéma Structure & Types ont été spécialisés par ajout des items propres à
AltaRica spécifiés dans altarica.xsd :
•
•
•
•
•
•
ArchType est spécialisé en ArchTypeBeh par ajout de Déclaration ( Domain, Constant, Extern)
SubArchitecture est spécialisé en SubArchitectureBeh par ajout de Sync.
ComponentType est spécialisé en ComponentTypeBeh par ajout de Behavior, Extern et Domain.
Behavior est composé des éléments States, Events, Trans, Assert et Init
Extern, Flows, Events, States, Trans, Init et Assert proviennent du schéma altarica.xsd.
Domain et Constant sont empruntés à utils.xsd
Figure 9 : la structure de componentTypeBeh
Quelques points restent à éclaircir, notamment sur les connecteurs qui, au niveau syntaxique, se présentent
comme des composants (extension de connectorType par connectorTypeBeh). Le problème se pose lors de la
conversion d'AltaRica vers xADL2.0*, on ne sait pas si un composant AltaRica correspond à un composant ou
un connecteur xADL2.0*, à priori, tout serait composant.
3.4
Applications
3.4.1
Adaptation de la partie édition d'ArchStudio 3
Une première application de l'extension d'xADL2.0 est l'adaptation de facto de la partie édition
d'ArchStudio 3. Cette adaptation s'est effectuée à travers la régénération de la librairie xarchlibs avec Apigen.
Une fois la librairie recompilée, l'IHM de l'application a reflété automatiquement dans les menus contextuels et
les champs de saisie la nouvelle syntaxe. Ceci est illustré par la figure 10 qui donne deux exemples de
modification réflétée par l'IHM : un menu "Behavior" qui permet de composer le comportement du composant et
un champ de saisie pour l'instanciation d'un élément "State".
Notons toutefois quelques limitations concernant Apigen. Ce dernier impose certaines contraintes sur
l'écriture des schémas et il a fallu les formater en conséquence. La conséquence est une perte d'indépendance du
langage à ses outils support. Mais, comme UCI a développé plusieurs API's basées sur les implémentations Java
générées par Apigen, remplacer ce dernier par JAXB, plus standard, obligerait à procéder à leur réécriture (dont
plusieurs des composants d'ArchStudio 3).
10
Figure 10 : adaptation de l'éditeur
3.4.2
Traitements sémantiques
L'extension d'xADL2.0 à l'expression du comportement en fait un langage d'analyse. Pour l'heure, aucune
API orientée traitement sémantique du modèle n'a été développée pour être intégrée à ArchStudio 3. Ceci est
possible et reste à l'étude, la question étant de savoir s'il est préférable :
• de traiter le modèle en interne, dans ce cas développer la ou les API 's nécessaires.(a)
• de générer à travers un convertisseur un modèle bien formaté pour être exploité par les outils AltaRica.(b)
• ou de développer la ou les "feuilles de style" (c) qui permettraient de spécifier et réaliser automatiquement la
transformation de la description xADL2.0* en format AltaRica.
Cela nous permet de concevoir une infrastructure qui offre l'accès à l'ensemble des outils liés à xADL2.0*
et à AltaRica avec un unique document de description. L'infrastructure est adaptable, extensible et peut suivre les
évolutions des langages. La figure suivante indique les composants à développer et à intégrer dans ou hors
ArchStudio 3 pour le traitement sémantique des modèles xADL2.0* (a)(b)(c).
xml Spy
xAltarica
(XML schema )
xADL2.0*
(XML schema )
Apigen
MapForce
xarchlibs*
(c) feuilles de style xADL2.0*
vers xAltarica puis vers
parsing
unparsing
XSLT
ADT*
(a) API's
sémantique
document de
description
d'architecture
xADL2.0*
représentation
Altarica
Outils
Altarica
(b) Convertisseur
légende :
editeur
outils
données mémoire
ArchStudio 3
fichiers
à développer
ADT : Abstract Data Type
* : Etendu au comportement
Figure 11: infrastructure d’outils autour d'xADL* et AltaRica
Enfin, il reste toujours la possibilité de développer entièrement des applications spécialisées compatibles
xADL2.0* tirant partie d'XML, d'XSLT, voire d'xarchlibs. Nous obtenons ainsi une infrastructure souple aux
possibilités multiples mélant les outils xADL2.0 et ceux d'AltaRica.
11
3.4.3
Retour vers AltaRica
En complément de l’extension d’xADL2.0, nous développons les feuilles de style d'xADL2.0* vers
xAltarica puis d'xAltarica vers AltaRica8 afin d’offrir le moyen d’utiliser les outils associés à AltaRica à partir
d’une description xADL2.0*.(Option c du modèle précédent)
3.4.4
Généralisation
Par généralisation de l'infrastructure d'outils xADL2.0*, nous obtenons un modèle d'infrastructure d’outils
souple, adaptable et évolutive de traitement d'architecture. L'architecture de cette infrastructure se fonde sur :
• d'une part, un modèle de description unique conforme à un ADL complet traité de différentes manières en
adéquation avec les besoins utilisateur.
• d'autre part le recours aux technologies XML pour la spécification des langages, le formatage des modèles,
le parsing, la validation syntaxique, la correspondance syntaxique et la transformation des modèles. Ceci
pour faciliter l'évolution de l'infrastructure.
En conséquence l’infrastructure est composée de quatre type de constituants :
• Des fichiers : Schémas XML pour la définition des langages, feuilles de style pour la spécification des
transformations et éventuellement des fichiers de personnalisation des règles de data binding (traduction en
code Java)..
• Des outils XML : Environnements de développement XML pour l’édition de schémas et des feuilles de
style, API’s XML pour le data binding, le parsing et la transformation.
• Des outils de traitement et de manipulation de niveau syntaxique : éditeurs, convertisseurs, navigateurs. Ces
outils sont susceptibles de s’adapter directement aux modifications de syntaxe.
• Des outils de traitements sémantique des modèles, pour le calcul, l’analyse ou la simulation (intégrés ou
externes)
éditeur XML
personalisation
du Data Binding
ADL
(XML schema )
XML Data
Binding (JAXB)
environnement
de développement
d'architecture
Classes &
Interfaces
Dérivées
feuilles de style
ADL to X
parsing
unparsing
légende
outils
XML
fichiers
XML
transformation
(XSLT)
document
de
description
d'architecture
ADT
(ou DOM)
traitements
sémantiques
Correspondances
syntaxiques
(MapForce)
formalismes X
(XML schema )
conversions
représentations
format X
traitements
externes
traitements
syntaxiques
Figure 12 : Modèle d'infrastructure d’outils
4
Conclusion
Nous nous sommes interessé aux ADL's dans le but de disposer de moyens d'analyse de propriétés globales
de comportement pour des systèmes en cours de conception, ceci en se fondant sur la modélisation de leur
architecture. Souvent la rigidité des langages ne leur permet pas de bien s'adapter aux besoins, et
l'incompatibilité entre leur outils support freine l'accès aux traitements variés et multiplie les représentations.
C'est parce qu'il est extensible et indépendant que nous avons choisi xADL2.0. Sa vocation n'étant pas
l'analyse de comportement, il a fallu l'étendre en conséquence. Nous avons pour cela importé dans xADL2.0 la
8
Il s’agit dans ce cas de transformer le document XML en texte.
12
syntaxe et la sémantique d’AltaRica. Certaines caractéristiques d’xADL2.0 ont largement facilité la procédure :
la hiérarchisation du langage et le recours à XML Schema qui permet la modularisation et l’héritage. Nous avons
alors produit le schéma behavior.xsd et importé les schémas d'xAltaRica (altarica.xsd et utils.xsd), ce qui offre à
xADL2.0 la capacité d’ajouter à la description de la configuration architecturale, celle du comportement.
Ensuite, nous nous sommes interessé aux mécanismes d’adaptation des outils xADL2.0. La partie édition
d'ArchStudio 3 s’est adaptée de facto, et nous savons que le développement et l'intégration d'API's dans cet
environnement sont facilités par l'automatisation du data binding et une architecture de style C2 [C2web]. Nous
avons aussi cherché à réaliser l'interopérabilité entre xADL2.0* et AltaRica au moyen d'XSLT, la technique
standardisée de transformation d'XML capable de s'appuyer sur les schémas déjà définis. Nous en avons déduit
la possibilité de construire une infrastructure de logiciels souple réunissant les outils d'xADL2.0 étendu et ceux
d'AltaRica.
Nous proposons ainsi un modèle générique d'infrastructure logicielle souple et adaptable de traitement de
l'architecture fondée sur un ADL spécialisable et le large recours aux outils XML.
5
Bibliographie
[IEEE1471] IEEE Architecture Working Group: "Recommended Practice for Architectural description of
Softwrare-Intensive Systems", IEEE Std 1471-2000, IEEE, 2000.
[DG95]
David Garlan: "An Introduction to the Aesop System", Vesrsion of 11 July 1995.
http://www-2.cs.cmu.edu/Groups/able/aesop/html/aesop-overview.ps
[MDEK95] Jeff Magee, Naranker Dulay, Susan Eisenbach, Jeff Kramer: "Secifying Distributed Software
Architecture" Proc of the 5th European Software Engeneering Conference (ESE'C95) LNC 989,
(Springer-Verlag) page 137-153, 1995.
[DarwinRef] Naranker Dulay: "Darwin Tutorial & Reference"
http://www-dse.doc.ic.ac.uk/dse-papers/darwin/ref-manual.ps.gz
[TMAWR95] Richard N. Taylor, Nenad Medvidovic, Kenneth M. Anderson, E. James Whitehead Jr., Jason E.
Robins: "A Component-and Message-Based Architectural Style for GUI Software" In Proceedings of
the Sevenbteenth International Conference on Software Engineering (ICSE17) page 295-304, Seattle
WA, April 24-28, 1995. http://www.cs.ucsc.edu/~ejw/papers/c2-icse17.pdf
[DL96]
David C. Lukham: "Rapide, A langage Toolset for Simulation of Distributed System By Partial
Ordering of Events" In Proceedings of DIMACS Workshop on Partiel Order Methods in Verification
(POMIV) page 329-358, July 25-26, 1996. http://pavg.stanford.edu/rapide/rapide-pubs.html
[GZ96]
Gregory Zelesnik: "The UniCon langage Reference Manual", Carnegie Mellon University,
Pittsburgh, Pensylvania, 1996
http://www-2.cs.cmu.edu/afs/cs/project/vit/www/unicon/reference-manual/Reference_Manual_1.html
[SDKRTZ95] Mary Shaw, Robert Deline, Daniel Klein, Theodore Ross, David Young, Gregory Zelesnik :
"Abstraction for Software Architecture and Tools to Support Them", IEEE Transaction on Software
Engeneering, 21(4):314-335, April 1995
http://www-2.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/UniCon.html
[MetaHRef]Steve Vestal: "MetaH User's Manual" version 1.27, Honeywell Technologie Center.
http://www.htc.honeywell.com/metah/uguide.pdf
[RA97]
Robert J. Allen: "A Formal Approach to Software Architecture", PhD. Thesis, Carnegie Mellon
University, Technical Report Number: CMU-CS-97-144, May, 1997.
http://www-2.cs.cmu.edu/~able/publications/rallen-thesis/
[MQRG97] Mark Moriconi, Xiaolei Qian, R.A Riemenschneider, Li Gong: "Secure Software Architecture",
Procceeding of the IEEE Symposium on Security and Privacy, page 84-93, Oakland, CA, May 1997.
http://www.sdl.sri.com/papers/s/p/sp97/sp97.ps.gz
[GMW97] David Garlan, Robert Monroe, and Dave Wile: "Acme: An Architecture Description Interchange
Language" In Proceedings of CASCON 97, Toronto, Ontario, November 1997, pp. 169-183.
http://www-2.cs.cmu.edu/~able/publications/acme-cascon97/
[MT00]
Nenad Medvidovic and Richard N. Taylor: "A Classification and Comparison Framework for
Software Architecture Description Languages". IEEE Transactions on Software Engineering, vol.
26, no. 1 (January 2000) http://sunset.usc.edu/~neno/teaching/s99/survey-long.pdf
[FLV03] Peter H Feiler, Bruce Lewis, Steve Vestal: "The SAE Avionics Architecture description Language
(AADL) Standard:A Basis for Model-Based Architecture Driven Embedded Systems Engineering"
(2003). http://www.cse.wustl.edu/~cdgill/RTAS03/published/SAEAADLRTASv1.pdf
[PSSC98] Steeve Pruitt, Doug Stuart, Wonee Sull, T.W. Cook: "The merit of XML as an Architecture
Description Language Meta-Language". Microelectronics and Computer Technology Corporation,
october 1998. http://www.ece.utexas.edu/~perry/prof/wicsa1/final/pruitt.pdf
13
[KGOMT01] Rohit Khare, Michael Guntersdorfer, Peyman Oreizy, Nenad Medvidovic, Richard N. Taylor:
"xADL: Enabling Architecture-Centric Tool Integration With XML". In Proceedings of the 34th
Hawaii International Conference on System Sciences (HICSS-34), Maui, Hawaii, January 3-6, 2001.
http://www.ics.uci.edu/pub/c2/papers/KGOMT-SE.pdf
[BS01]
Bradley Schmerl : “xAcme : CMU Acme Extensions to xArch." (23 March, 2001)
http://www-2.cs.cmu.edu/~acme/pub/xAcme/guide.pdf
[LB97]
Luc Bellissard: "Construction et configuration d'application répartie", thèse Informatique, Systèmes
et Communication, IMAG/INRIA, Grenoble, 1997.
http://publications.imag.fr/publications/theses/annees/1997/Bellissard.Luc/these.dir
[DHN01] Eric M. Dashofy, André van der Hoek, and Richard N. Taylor : "A Highly-Extensible, XML-Based
Architecture Description Language ". In Proceedings of the Working IEEE/IFIP Conference on
Software Architectures (WICSA 2001), Amsterdam, Netherlands.
http://www.ics.uci.edu/~edashofy/papers/wicsa2001.pdf
[DH01]
Eric M. Dashofy and André van der Hoek "Representing Product Family Architectures in an
Extensible Architecture Description Languag". In Proceedings of the International Workshop on
Product Family Engineering (PFE-4), Bilbao, Spain, October 2001.
http://www.ics.uci.edu/~edashofy/papers/pfe2001.pdf
[ED01]
Eric M. Dashofy : "Issues in Generating Data Bindings for an XML Schema-Based Language". In
Proceedings of the Workshop on XML Technologies and Software Engineering (XSE2001),
Toronto, Ontario , Canada. http://www.ics.uci.edu/~edashofy/papers/xse2001.pdf
[DHN02] Eric M. Dashofy, André van der Hoek, and Richard N. Taylor: "An Infrastructure for the Rapid
Development of XML-based Architecture Description Languages". In Proceedings of the 24th
International Conference on Software Engineering (ICSE2002), Orlando,Florida.
http://www.ics.uci.edu/~edashofy/papers/icse2002.pdf
[CS01]
Charles Castel, Christel Seguin: "Modèles formels pour l'évaluation de la sûreté de fonctionnement
des architectures logicielles d'avionique modulaire intégrée". In AFADL: Approches Formelles dans
l'assistance au développement de logiciels, 2001.
http://www.cert.fr/en/dtim/publis/CVSI/2001/AFADL01.pdf
[APGR03] André Arnold, Gérard Point, Alain Griffault, Antoine Rauzy: "AltaRica, Manuel méthodologique",
LaBRI, Université de Bordeaux 1 et CNRS (UMR (5800), 2003.
http://altarica.labri.fr/Doc/
[CP03]
Claire Pagetti: "Une extension temporisée d'AltaRica", In Actes du Congrès Modélisation des
Systèmes réactifs, MSR'03, 2003. http://altarica.labri.fr/Doc/Biblio/Author/PAGETTI-C.html
Sites Web
[SEIADLweb] SEI: "Architecture Description Languages" : http://www.sei.cmu.edu/architecture/adl.html
[Aesopweb]"Aesop, Software Architecture Design Environment Generator", Home Page :
http://www-2.cs.cmu.edu/Groups/able/aesop/aesop_home.html
[Darwinweb] "The Darwin Architecture description Langage", Home Page :
http://www.doc.ic.ac.uk/~igeozg/Project/Darwin/
[C2web] "Chiron-2, A Component and essage Based Architectural Style for GUI Software" (1995)
http://www.ics.uci.edu/~arcadia/C2/c2.html
"The C2 architectural style" : http://www.isr.uci.edu/architecture/c2StyleRules.html
[ISRpub] "Architectural Style Publications": http://www.isr.uci.edu/architecture/publications.html#C2
[Rapideweb] "The Stanford Rapide Project", Home Page: .http://pavg.stanford.edu/rapide/
[UniConweb] "UNICON", Home Page: http://www-2.cs.cmu.edu/People/UniCon/
[MetaHweb] "MetaH Evaluation and support Site":http://www.htc.honeywell.com/metah/
[Wrightweb] "The Wright Architecture Description Language", Home Page.
http://www-2.cs.cmu.edu/afs/cs/project/able/www/wright/index.html
[SADLweb]"Dependable Systems Architectures", SADL Home Page
http://www.sdl.sri.com/programs/dsa/sadl-main.html
[Acmeweb] "The Acme Architectural Description Langage": http://www-2.cs.cmu.edu/~acme/
[Olanweb] "Olan: Un environnement de développement d'applications coopératives" (1995)
http://rangiroa.essi.fr/riveill/recherche/95-olan-francais.html
[ADMLweb] "Architecture Description Markup Language (ADML)"
http://www.opengroup.org/architecture/adml/adml_home.htm
[AADLweb] "The SAE AADL Standard": http://bscw.sei.cmu.edu/pub/bscw.cgi/d74911/index.html
[xADLweb] "xADL2.0", Home Page: http://www.isr.uci.edu/projects/xarchuci/index.html
[xArchweb] "xArch", Home Page : http://www.isr.uci.edu/architecture/xarch/
[xAcmeweb] "xAcme, Acme extensions to xArch": http://www-2.cs.cmu.edu/~acme/pub/xAcme
14
[ArchStudioweb] "ArchStudio 3, An Architecture-based Development Environment", Home Page.
http://www.isr.uci.edu/projects/archstudio
[AltaRicaweb] "AltaRica", Home Page.: http://altarica.labri.fr
[xAltaricaweb] "xAltarica, première ébauche":http://www.cert.fr/francais/deri/mareschal/altarica/xaltarica.html
[JWSDPweb] "Tools, Java Web Services Developer Pack"
http://www.java.sun.com/webservices/webservicespack.html
[Saxonweb] "Saxon, The XSLT and Xquery Processor" http://saxon.sourceforge.net/
[TIBCOweb] "XML Tools" http://www.tibco.com/solutions/products/extensibility/default.jsp?m=d7
[Altovaweb] "Products, XMLSPY 2004" http://www.altova.com/products_ide.html
15