Vrification dune architecture UML2.

0 avec lADL Wright

Mohamed Graiet I, III Mohamed Tahar Bhiri II, Jean-Pierre Giraudin I, Abdelmajid Ben Hamadou III
I

LSR-IMAG, quipe SIGMA, BP 72, 38402 SAINT MARTIN DHERES CEDEX Mohamed.graiet@imag.fr Jean-Pierre.giraudin@imag.fr
II

Facult des Sciences de Sfax, rue soukra, BP 802, 3018 SFAX Tahar_bhiri@yahoo.fr

III

LARIM-Institut Suprieur d'Informatique et du Multimdia de Sfax, rue mharza, 3018 SFAX Abdelmajid.benhamadou@isimsf.rnu.tn

Rsum : UML2.0 offre des nouveaux concepts tels que composant, port, interfaces offertes, interfaces requises, connecteur, structure composite permettant de dcrire une architecture logicielle. Mais UML2.0 ne permet pas ltude formelle de deux critres fondamentaux sur une architecture logicielle qui sont la cohrence et la compltude. Par contre certains ADL comme Wright autorisent une telle tude. Dans cet article, nous prconisons une approche de traduction permettant de transformer une architecture UML2.0 en une architecture Wright afin de raliser des vrifications formelle darchitectures UML2.0. Mots Cls : Architecture logicielle, UML2.0, Wright, Traduction, vrification formelle.

INTRODUCTION

Larchitecture logicielle [Garlan, 1994] est devenue une activit de conception explicite dans le processus de dveloppement. Elle modularise un systme sous forme dune configuration de composants et de connecteurs. Larchitecture logicielle permet didentifier des entits de connexion appeles connecteurs et de dcrire de manire prcise les protocoles de communication entre composants [Allen, 1996] [Allen, 1997a]. Les travaux sur les formalismes de description darchitectures logicielles ont donn naissance plusieurs ADL (Architecture Description Langage) [Medvidovic, 2000]. Chaque ADL sest spcialis dans un thme particulier fournissant des fonctionnalits complmentaires pour la description et lanalyse architecturale [ACCORD, 2002] : Aesop pour les styles architecturaux, le style C2 pour les systmes distribus et volutifs, Darwin pour les systmes denvoi de messages distribus, Rapide concernant la simulation et Wright pour la description comportementale et la vrification formelle des proprits sur une architecture logicielle. Plusieurs

travaux ont essay de dfinir un mta-langage pour profiter des avantages de ces diffrents ADL. Par exemple, ACME [Garlan, 2000] fournit une reprsentation intermdiaire exploitable par les outils architecturaux associs aux diffrents ADL. Pour mettre la disposition des utilisateurs UML et par consquent du monde industriel, des fonctionnalits offertes par les ADL notamment la vrification formelle des architectures logicielles, nous prconisons une approche de transformation permettant la traduction dune architecture logicielle dcrite en UML2.0 [OMG03] en une architecture dcrite en Wright. Le choix de lADL Wright est justifi par ses aptitudes lies la validation formelle des architectures logicielles. Cet article est organis comme suit. Les deux sections 2 et 3 prsentent brivement le cadre de notre travail savoir UML 2.0 et lADL Wright. Ensuite la section 4 propose et justifie des rgles de correspondance supportant le processus de traduction dune architecture UML 2.0 vers une architecture en Wright. Enfin, la section 5 conclut et prsente les perspectives de cette recherche.

ARCHITECTURE LOGICIELLE UML2.0

UML2.0 offre des nouveaux concepts (interfaces offerte et requise, port, structure composite et connecteur) permettant de dfinir larchitecture de lapplication que lon dsire dvelopper. Le mta-modle UML2.0 considre les deux concepts class et component comme des classifieurs. De plus, la mta-classe component est une sous-classe de la mta-classe class. UML2.0 spcifie un composant comme tant une unit modulaire, rutilisable qui interagit avec son environnement par lintermdiaire de points dinteractions appels ports. Les ports sont typs par les

interfaces. Celles-ci contiennent un ensemble doprations et de contraintes OCL2.0 (langage dexpression de contraintes pour UML2.0). Le comportement dune interface est dcrit par un protocole de type machine tats (protocol statemachine). Les interfaces peuvent tre fournies ou requises. De mme, les ports installs sur des composants ou des classes peuvent tre fournis ou requis. Le comportement dun port est issu de la composition des comportements des ces interfaces. Un tel comportement des ports est dcrit laide dun protocole machine tats. Le comportement interne du composant ne doit tre ni visible, ni accessible autrement que par ses ports. Enfin, le composant est vou tre dploy un certain nombre de fois, dans un environnement non connu a priori lors de la conception. Il existe deux types de modlisation de composants dans UML2.0 : le composant atomique (ou basique) et le composant composite (structure composite). La premire catgorie dfinit le composant comme un lment excutable du systme. La deuxime catgorie tend la premire en dfinissant le composant comme un ensemble cohrent des parties appeles parts. Chaque part reprsente une instance dun autre composant. La connexion entre les ports requis et les ports fournis se fait au moyen de connecteurs. Deux types de connecteurs existent : le connecteur de dlgation et le connecteur dassemblage. Le connecteur de dlgation est utilis pour lier un port du composant composite vers un port dun composant situ lintrieur du composant composite : relier par exemple un port requis un autre port requis. Le connecteur dassemblage est utilis pour les liens de construction : relier un port requis un port fourni.

Component Proxy Port s = requete?u Port c = requete!u reponse!r reponse?r s

Computation = s.requete?u c.requete!u s.reponse!r c.reponse?r Computation

LADL WRIGHT

Wright est un langage de spcification darchitecture issu de la thse de Robert J.Allen [Allen, 1997b]. Les principaux concepts offerts par Wright sont : composant, connecteur, configuration et style. Les descriptions des composants contiennent deux parties : Linterface consiste en un ensemble de ports, chacun reprsentant une interaction avec lextrieur laquelle le composant peut participer. La spcification dun port dcrit deux aspects de linterface du composant : le comportement partiel attendu du composant et ce que le composant attend du systme dans lequel il va interagir. Le calcul (ou computation) dcrit ce que le composant fait de point de vue comportemental.

Ce composant possde deux ports : s et c. Le port s reoit les requtes et envoie les rponses un client. Le port c est utilis pour dlguer la requte un autre composant. La partie calcul rend la dlgation explicite (requte reue sur s, envoi dune requte sur c, attente de la rponse, puis envoi de cette rponse sur s). La structure dun connecteur est similaire celle dun composant. Elle consiste en un ensemble de Rles et une Glue : Chaque Rle dcrit les attentes du connecteur dans ses interactions avec les composants. La Glue dcrit comment les Rles travaillent ensemble pour crer cette interaction Les Rles et la Glue sont galement dcrites en CSP. La configuration dcrit comment est agenc le systme. Elle comporte pour cela quatres aspects : les dfinitions des types composants et connecteurs, les instances, les liens et les hrarchies (connecteurs composites et composants composites). Wright permet de dcrire des styles darchitectures qui regroupent une famille darchitectures ayant un ensemble de proprits communes caractrisant cette famille. Pour cela Wright fournit trois aspects pour dfinir un style : les types (composant, connecteur, et interface), les paramtres et les contraintes. Pour exprimer les contraintes, Wright propose une notation base sur la logique de premier ordre. Les connecteurs sont toujours utiliss pour connecter deux ports de deux composants. Plusieurs tests sont effectus pour vrifier la validit de la configuration. Wright utilise la spcification CSP des ports et des rles, pour spcifier entre autres leur compatibilit.

TRADUCTION DE SPECIFICATIONS UML2.0 EN WRIGHT

Ces deux parties sont dcrites en CSP [Hoare, 1985], et fournissent lenchanement des vnements mis ou reus. Un composant proxy peut se dfinir successivement par la description de deux ports et par lexpression de calculs :

Une architecture logicielle de qualit devrait distinguer dune faon explicite les composants fonctionnels des composants de communication [Cariou, 2003]. Dailleurs les ADL comme Wright proposent deux constructions component et connector permettant de modliser respectivement les composants fonctionnels et de communication. Mais le concept de connecteur dUML2.0 nest pas considr comme classifier et ne peut pas modliser un composant de communication. Pour rsoudre ce problme, nous avons opt pour les choix suivants : Un composant fonctionnel est modlis par le concept de composant dUML2.0 dot des ports. Un composant de communication est modlis par le concept de classe dUML2.0 dot des

ports. Une telle classe sera strotype communication avec une contrainte de ports obligatoires. Sachant que les deux concepts dUML2.0 composant et classe ont le mme pouvoir expressif. Mais ils possdent deux icnes diffrentes. Ceci permet de distinguer explicitement les composants fonctionnels et les composants de communication dans une architecture logicielle dcrite en UML2.0. La topologie ou la configuration dune architecture logicielle dcrite en UML2.0 est modlise par un diagramme dinstances comportant des instances de type composant fonctionnel et des instances de type composant de communication. Les liens entre les instances de type composant fonctionnel et les instances de type composant de communication sont modliss par des connecteurs dassemblage dUML2.0. Dans la suite, nous allons proposer des rgles de correspondances entre une architecture logicielle UML2.0 -comportant les lments dcrits prcdementet une spcification Wright. 4.1 Les composants fonctionnels Un composant fonctionnel est modlis par un composant UML2.0. Les points dinteraction dun composant fonctionnel avec son environnement sont modliss par des ports UML2.0. Chaque port est typ par des interfaces offertes ou requises. Le comportement de chaque port est modlis par un protocole machine tats dUML2.0. De mme, le comportement du composant est modlis par un protocole machine tats. La figure 1 donne la rgle de traduction dun composant UML2.0 en son quivalent en Wright.

2 donne la rgle de traduction dune classe UML2.0 vers Wright.

UML2.0
R1 {Protocol} R2 {Protocol}

Wright
Connector X Role R1 = expression CSP issue du protocole associ R1 Role R2 = expression CSP issue du protocole associ R2 Glu = expression CSP issue du protocole associ la classe X

<<invoke> R1

<communicatio n>

<<invoke> R2

<<invoke>
X {Protocol}

Figure 2: Rgle de traduction communication UML2.0 en Wright

dune

classe

Les aspects structuraux dune classe UML2.0 modlisant un composant de communication sont traduits en utilisant les aspects structuraux attachs un connecteur Wright : chaque port UML2.0 est traduit par un rle Wright ayant le mme identificateur. Les aspects comportementaux dune classe UML2.0 sont traduits en Wright sous forme des expressions CSP (voir section 4.4) 4.3 Architecture logicielle Une architecture logicielle en UML2.0 est modlise par un diagramme dinstances. Ces instances sont issues de deux types UML2.0 : component et class. La figure 3 donne les principes de traduction dune architecture logicielle UML2.0 de type client-serveur en configuration Wright.

UML2.0
ClientServeur

Wright
Configuration ClientServeur Composant Client Port EnvoiRequete = expression CSP Computation = expression CSP Composant Serveur Port ReceptionRequete = expression CSP Computation = expression CSP Connector Rpc Role appelant = expression CSP Role appele = expression CSP Glu = expression CSP Instances C : Client CS : Rpc S : Serveur Attachments C. EnvoiRequete as CS. appelant S. ReceptionRequete as CS. Appele end ClientServeur

UML2.0
R1 {Protocol} R2 {Protocol}

Wright
Connector X Role R1 = expression CSP issue du protocole associ R1 Role R2 = expression CSP issue du protocole associ R2 Glu = expression CSP issue du protocole associ la classe X

C : Client

<<invoke> R1

<communication >

<<invoke> R2

EnvoiRequete Appelant CS : Rpc

<<invoke> X {Protocol}

Figure 1: Rgle de traduction dun composant UML2.0 en Wright Les aspects structuraux dun composant UML2.0 sont traduits en Wright en utilisant galement les aspects structuraux attachs un composant Wright : chaque port UML2.0 est traduit par un port Wright ayant le mme identificateur. Les aspects comportementaux dun composant UML2.0 sont traduits en Wright sous forme des expressions CSP (voir section 4.4). 4.2 Les composants de communication Un composant de communication est modlis par une classe UML2.0. Les rles jous par les composants fonctionnels connects au composant de communication sont modliss par des ports UML2.0. Les comportements des rles et du composant sont modliss par des protocoles machines dtats. La figure

Appele ReceptionReq

S : Serveur

Figure 3: Principes de traduction dune architecture UML 2.0 en Wright Expression en CSP-Wright des protocoles machine tats UML2.0 LADL Wright utilise un sous-ensemble de CSP compatible avec le CSP standard [Hoare, 1985] permettant de dcrire les comportement partiels (port et role) et globaux (computation et glu) de deux constructions offertes par Wright savoir component et 4.4

connector. De plus lADL Wright augmente la notation CSP pour faire la diffrence entre un vnement initialis recevant des donnes (vnement avec une barre, suivi dun point dexclamation et dune variable qui reprsente les donnes) et un vnement observ fournissant des donnes (vnement sans barre, suivi dun point dinterrogation et dune variable qui reprsente les donnes). Des travaux lis la consistance des modles UML existent [Engels2001] [Kster, 2004]. Ces travaux prennent comme domaine smantique le langage CSP et loutil de validation FDR [FDR93] [FDR98]. Le travail dcrit dans [Engels2001] propose des rgles permettant de traduire une machine tats UML en CSP. Nous avons adapt ces rgles notre contexte : protocole machine tats UML2.0 et CSP augment par des vnements initialiss et observs. A titre illustratif, la figure 4 donne la description en UML2.0 dun pipe utilis notamment dans les architectures de type Filtre/Pipe [Allent, 1997]. Le port source exige une interface requise appele Ecriture. Tandis que le port Destination offre une interface appele Donnes et exige une interface appele Lecture. La figure 5 donne les deux expressions CSP de Wright Source et Destination issues des protocoles machines dtats UML2.0 associes ces deux ports. Toute transition tiquette par des appels doprations appartenant des interfaces requises est traduite par un vnement initialis en CSP de Wright. De plus, le lien entre opration UML2.0 et vnement Wright est trait selon des correspondances adaptes de [Sanlaville, 1997].

CONCLUSION ET PERSPECTIVES

Pour mettre la disposition des utilisateurs UML les concepts et les mcanismes sous-jacents issus des ADL, nous avons prconis une approche de traduction dUML2.0 vers Wright. Ainsi nous avons propos des rgles permettant de traduire une architecture UML2.0 en une architecture Wright. Ceci ouvre des perspectives lies la vrification formelle des architectures UML2.0. En effet larchitecture Wright issue de larchitecture UML2.0 est traduite en une spcification CSP contenant des processus CSP dcrivant les aspects comportementaux de larchitecture et des assertions exprimant les proprits standard dfinies par Wright. Une telle spcification CSP peut tre analyse par loutil de vrification formelle FDR [FDR98]. A lissue de ce travail exploratoire, des questions se posent que nous valuons actuellement : Wright propose une dizaine de proprits appeles tests permettant de vrifier la cohrence et la compltude dune architecture Wright. Il est important dvaluer la pertinence de chacun de ces tests vis--vis dune architecture en UML2.0. Les contraintes OCL2.0 associes des spcifications UML2.0 sont combiner avec les expressions Wright issues des traductions que nous proposons. Nous utiliserons en particulier le langage des contraintes propres Wright.

Source{protocol} ecrire ( x)

Destination {protocol} x = obtention ( )

fermer () lire( ) finDeDonnees( ) fermer( )

Ces travaux de traduction et de vrification formelle sintgrent dans notre projet plus gnral de combinaison darchitectures selon diffrents points de vue systme dinformation et architecture logicielle compatibles avec une approche MDA [OMG00] [OMG01a] [OMG01b].

<<invoke>>

<<invoke>>

BIBLIOGRAPHIE
<< Interface>> Donnees Message obtention () void finDeDonnees( )

Source

Pipe
Destination

<<use>>

<<use>> <<Interface>> Ecriture void ecrire(Message) void fermer( )

<< Interface>> Lecture void lire ( ) void fermer( )

Figure 4: Description en UML2.0 du connecteur Pipe

Source = ecrire!x Destination = lire finDeDonnees Source fermer (obtention?x Destination fermer )

Figure 5: Expressions CSP associes aux ports Source et Destination du connecteur Pipe

[ACCORD, 2002] Projet ACCORD: Etat de lart sur lesLangages de Desciption dArchitecture (ADL) 2002. http:// www.infres.enst.fr.projet/accord/ [Allen, 1996] Allen R et Garlan D. The wright architectural specification langage. Rapport technique CMU-CS-96-TBD, Carnegie Mellon University, School of Computer Science, Pillsburgh, PA, septembre 1996. [Allen1997a] Allen R et Garlan D. A Formal Basis for Architectural Connection . ACM Transactions on Software Engineering and Methodology, July 1997. [Allen, 1997b] Allen R. A Formal Approch to Software Architecture . Phd Thesis, Carnegie Mellen University, School of Computer Science, May 1997. [Cariou, 2003] Cariou E, Contribution un processus de rification dabstractions de communication . Thse de doctorat, Universit de Rennes1, Juin 2003.

[Engels2001] Engels C, Heckel R and Kster J M Rule-based Specification of Behavior Consistency based on the UML Meta-Model . In M.Gogolla an C.Kobry, editors, proceedings of the 4th International Conference on the Unified Modeling Language (UML 2001), pages 272-287, LNCS 2185, Toronto, Canada, October 2001. [FDR93] Failures Divergence Refinement: User Manual and Tutorial. Formal Systems (Europe) Ltd, Oxford, England, 1.3 edition, August 1993. [FDR98] http://www.formal.demon.co.uk/FDR2.html [Garlan, 2000] Garlan D, Monroe R M and Wile D. Acme: Architectural Description of Component-Based Systems . Eds: Cambridge University Press,2000. [Garlan,1994] Garlan D, and Shaw M. An Introduction to Software Architecture . CMU-CS-94-166, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3890. [Hoare,1985] Hoare C A R. Communicating Sequential Processes . Prentice Hall, Englewood Califfs NJ, 1985. [Medvidovic, 2000] Medvidovic N, and Taylor R N. A classification and comparison framework for software architecture description languages . IEEE Transactions on Software Engineering, 26 (1): 70-93, January 2000. [Kster, 2004] Kster J M. Consistency Management of Object-Oriented Behavioral Models . Faculty of Computer Science, Electrical Engineering, and Mathematics of the University of Paderborn, March 2004. [OMG00] R. Soley, OMG Staff Strategy Group: Model Driven Architecture, www.omg.org, novembre 2000. [OMG01a] OMG, Model Driven Architecture: The Technical Perspectives, www.omg.org, juillet 2001. [OMG01b] Object Management Group. OMG Unified Modeling Language Specification V. 1.4. http://www.omg.org/docs/formal /01-09-67.pdf (September 2001). [OMG03] Object Management Group. UML2.0 Superstructure Specification: Final Adopted Specification. http://www.omg.org/docs/ptc /03-0802.pdf (August 2003). [Sanlaville, 1997] Sanlaville R. Description darchitectures logicielles: utilisation du formalisme Wright pour linterconnexion de machines abstraites B . DEA, LSR, IMAG, Grenoble, 1997.