Vers une formalisation du métamodèle de composants Ugatze

Vers une formalisation du métamodèle de composants Ugatze Mourad Kmimech I,III, Mohamed Tahar Bhiri II, Philippe Aniorté I, Abdelmajid Ben Hamadou III I LIUPPA, IUT de Bayonne - Département Informatique Mourad.kmimech@iutbayonne.univ-pau.fr, Philippe.Aniorte@iutbayonne.univ-pau.fr II Faculté des Sciences de Sfax, Tahar_bhiri@yahoo.fr III LARIM, Abdelmajid.benhamadou@isimsf.rnu.tn RÉSUMÉ. Le métamodèle Ugatze -élaboré dans notre équipe de recherche- permet la modélisation et l intégration a posteriori de composants. Les concepts fondamentaux du métamodèle Ugatze sont composant, interaction et graphe d interactions (ou architecture logicielle). Dans cet article nous préconisons une formalisation du métamodèle Ugatze par le biais d un langage appelé UgatzeADL. A terme, le langage UgatzeADL devrait faciliter la transformation de modèles selon l approche MDA. En effet, le typage statique et la sémantique formelle exprimée par des assertions apportés par le langage UgatzeADL au métamodèle Ugatze favorisent des transformations semi-automatiques des PIM décrits en UgatzeADL vers des PSM décrits en EJB ou CCM par exemple. De plus, le langage UgatzeADL devrait favoriser la vérification formelle des propriétés standard et spécifiques des architectures logicielles décrites dans ce langage. Après avoir présenté le métamodèle Ugatze et justifié une approche de formalisation de ce métamodèle, cet article propose une formalisation du concept composant d Ugatze accompagnée par des exemples d illustration. ABSTARCT. The Ugatze metamodel - elaborate in our team of research - allows the modelling and the integration a posteriori of components. The fundamental concepts of the Ugatze metamodel are component, interaction and interactions graph (or software architecture). In this article we recommend a formalisation of the Ugatze metamodel by the slant of a language named UgatzeADL. To term, the UgatzeADL language should facilitate the transformation of models according to the MDA approach. Indeed, the static typage and the formal semantics expressed by assertions brought by the UgatzeADL language in the Ugatze metamodel encourage semi-automatic transformations of the PIM described in UgatzeADL toward PSM described for example in EJB or CCM. Besides, the UgatzeADL language should encourage the formal verification of the standard properties and specific software architectures described in this language. After having presented the Ugatze metamodel and justified an approach of formalisation of this metamodel, this article proposes a formalisation of the Ugatze concept component accompanied by illustration examples. MOTS-CLÉS : Métamodèle Ugatze, Formalisation, Transformation de modèles et Vérification. KEYWORDS : Ugatze metamodel, Formal, Transformation of models and Verification.

1. Introduction Le métamodèle Ugatze [Aniorté, 2004] [Seyler, 2004] -élaboré dans notre équipe de recherche- permet la modélisation et l intégration a posteriori de composants. Les concepts fondamentaux du métamodèle Ugatze sont composant, interaction et graphe d interactions (ou architecture logicielle). Dans cet article nous préconisons une formalisation du métamodèle Ugatze par le biais d un langage appelé UgatzeADL. A terme, le langage UgatzeADL devrait faciliter la transformation de modèles selon l approche MDA [Bézivin, 2002a] [Bézivin, 2002b] [OMG, 2003b]. En effet, le typage statique et la sémantique formelle exprimée par des assertions [Meyer, 1991] [Meyer, 1992] apportés par le langage UgatzeADL au métamodèle Ugatze favorisent des transformations semiautomatiques des PIM décrits en UgatzeADL vers des PSM décrits en EJB ou CCM par exemple. De plus, le langage UgatzeADL devrait favoriser la vérification formelle des propriétés standard et spécifiques des architectures logicielles [ACCORD, 2002] [Shaw, 1996] décrites dans ce langage. Après avoir présenté le métamodèle Ugatze et justifié une approche de formalisation de ce métamodèle, cet article propose une formalisation du concept composant d Ugatze accompagnée par des exemples d illustration. 2. Le métamodèle Ugatze Au cours de ces dernières années, l équipe a développé et expérimenté (dans le cadre du projet européen ASIMIL [ASIMIL, 2002] un (méta)modèle de composants dénommé Ugatze, adapté à la réutilisation de composants logiciels autonomes, hétérogènes et distribués [Aniorté, 2004] [Seyler, 2004]. Les composants logiciels visés par le métamodèle Ugatze ne sont pas forcément conçus pour être réutilisés a priori : c est la réutilisation a posteriori. Le métamodèle Ugatze est spécifié et utilisé à l aide des standards de modélisation et de métamodélisation : UML, OCL, MOF et MDA. Dans la suite, nous allons présenter les trois concepts fondamentaux du métamodèle Ugatze à savoir composant, interaction et graphe d interactions. 2.1 Les composants Ugatze Un composant Ugatze est doté de plusieurs points d interactions permettant à un composant d interagir avec son environnement. Le métamodèle Ugatze propose essentiellement deux ensembles de points d interactions : les points d information et les points de contrôle. 2.1.1 Les points d information Le métamodèle Ugatze propose les points d information suivants :

les points d entrée des données : Input Information Point (IIP), ce sont des points d interaction sur lesquels les composants récupèrent le flux de données unidirectionnel les points de sortie de données : Output Information Point (OIP), jouent un rôle symétrique en transférant le flot unidirectionnel de données vers l extérieur du composant les points d opérations offertes : Provided Information Operation Point (PIOP). Elles reçoivent et répondent à des requêtes les points d opérations requises : Used Information Operation Point (UIOP). Elles déterminent les services requis pour l exécution d un composant Ugatze. 2.1.2 Les points de contrôle Ugatze propose un ensemble de points de contrôle qui permettent à un composant de synchroniser un autre composant ou d être synchronisé, à l aide d un message ou d un événement. Ces points d interaction sont appelés les SEP (Signal Emission Point) et les SRP (Signal Reception Point). Ugatze inclut aussi la possibilité d accéder dans la partie contrôle des composants à ces opérations de cycle de vie (création, recherche, activation voir mobilité ), et ce par l intermédiaire des points d opération : Provided Controle Operation Point (PCOP) pour les opérations de contrôle offertes, Used Controle Operation Point (UCOP) pour les opérations de contrôle requises. 2.2 Les interactions Ugatze Les interactions Ugatze permettent une intégration conceptuelle de composants autonomes. Une interaction Ugatze connecte un certain nombre (au minimum 2) de points d interaction installés sur des composants Ugatze. Deux types d interaction sont proposés par Ugatze : Interaction directe Interaction ad hoc. Une interaction directe désigne une connexion directe entre deux (et seulement deux) points d interactions. Par exemple une connexion IIP-OIP est considérée comme interaction directe de même une connexion PIOP-UIOP est considérée comme interaction directe. Ceci est également vrai pour les connexions SEP-SRP et PCOP-UCOP. Une interaction ad hoc permet une interopérabilité fonctionnelle entre les composants hétérogènes issus des divers environnements de production. Ces interactions ad hoc concernent aussi bien la partie donnée que contrôle d un composant Ugatze. Une interaction ad hoc peut toucher à plusieurs (>=2) points d interaction. De plus, dans le métamodèle Ugatze, une interaction ad hoc encapsule souvent un traitement plus ou moins compliqué. Enfin le métamodèle Ugatze propose des interactions prédéfinies telles que : boite à lettres, ressource partageable et multicast.

2.3 Le graphe d interactions Une architecture logicielle d une application distribuée décrite en Ugatze est considérée comme un graphe biparti appelé graphe d interactions comportant deux types de sommets : composant et interaction. Les composants et les interactions sont reliés par des arcs. Le graphe d interactions décrit les aspects statiques d une application Ugatze. Vu sous cet angle, il est similaire au diagramme de classes UML1.x ou au diagramme de composants UML2.0 [OMG, 2003b]. 3. Une approche de formalisation d Ugatze : UgatzeADL Une formalisation Ugatze par le biais d un langage appelé UgatzeADL peut être justifiée par deux arguments majeurs. Le premier touche à l Ingénierie Dirigée par les Modèles (IDM) [Blanc, 2005]. Le second touche à la vérification des architectures logicielles [shaw, 1996]. Dans la suite de ce paragraphe nous allons cerner notre approche de formalisation du métamodèle Ugatze par rapport à ces deux arguments. 3.1 Le langage UgatzeADL et IDM L IDM est une nouvelle approche du génie logiciel. Elle considère les modèles comme des entités de première classe. L IDM permet de traiter plusieurs types de modèles : CIM (Computation Independent Model), PIM (Platform Independent Model) et PSM (Platform specifie Model). Plusieurs opérations applicables sur les modèles sont plus ou moins définies. Parmi ces opération nous citons : stockage, visualisation, échange et transformation. Celle-ci peut être appliquée au même type ou à des types différents de modèles tel que : PIM-PIM, PIM-PSM, PSM-PIM. L IDM est basée sur des standards de modélisation et de métamodélisation : UML, MOF, OCL, MDA. Grâce au concept graphe d interactions (voir 2.3), le métamodèle Ugatze permet de décrire les PIM des applications distribuées à base des composants autonomes et hétérogènes. Mais le graphe d interactions Ugatze comporte des éléments non typés comme les points d information et les points de contrôle (OIP, IIP, PIOP, UIOP, SEP, SRP, PCOP et UCOP voir 2.1) liés aux composants Ugatze. De plus, les opérations offertes (PCOP, PIOP) par les composants Ugatze ne sont spécifiées. En outre les interactions ad hoc peuvent être sujettes à plusieurs interprétations. Dans une optique de transformation semiautomatique des PIM construits avec Ugatze vers des PIM moins abstrait ou vers des PSM modélisant des plateformes comme EJB, CORBA, FRACTAL, DotNeT, une formalisation Ugatze s impose. Ainsi le langage UgatzeADL souhaité doit offrir des possibilités liées au typage statique (pour détecter les erreurs de typage le plus tôt possible) et à la spécification formelle (par exemple une approche basée sur la conception par contrats [Meyer, 1992] des services offerts et requis par les composants et par les interactions notamment les interactions ad hoc. Ceci favorise

la transformation progressive d un service bien spécifié d un niveau abstrait, vers un niveau moins abstrait ou encore vers un niveau concret. 3.2 Le langage UgatzeADL et la vérification des architectures logicielles Des propriétés standard doivent être vérifiées sur toute description architecturale décrite en Ugatze. Dans l état actuel d avancement de notre recherche, nous avons identifié les trois propriétés standard : Propriété 1 : vérification de compatibilité des connexions des points d entrée de données. Cette propriété concerne les interactions directes entre les interactions IIP et OIP. Une telle propriété peut être vérifiée d une façon statique par un vérificateur de types qui équipe le langage UgatzeADL. Propriété 2 : vérification de comptabilité des connexions des points de signaux. Cette propriété concerne les interactions directes entre les points d interactions SEP et SRP. Une telle propriété peut être également vérifiée par un vérificateur de types équipant le langage UgatzeADL. Propriété 3 : vérification de comptabilité des connexions des points d opération. Cette propriété concerne les interactions directes entre les points d interactions PIOP-UIOP et PCOP-UCOP. Nous avons opté pour une sémantique formelle basée sur les assertions (préconditions et postconditions) pour décrire la spécification des opérations des composants Ugatze. La propriété 3 peut être vérifiée comme suit : la signature de l opération offerte, comportant le nombre des paramètres, types de paramètres et le mode de communication (in, out, et in out), doit être compatible à celle de l opération requise. Ceci peut être confié au vérificateur de types du langage UgatzeADL. la sémantique de l opération offerte comportant une précondition et une postcondition doit être identique à celle de l opération requise. Nous comptons utiliser la théorie des ROBDD (Reduced Ordered Binary Decision Diagrams) [Bryant, 1986], [Bryant, 1992] pour vérifier la sémantique de deux opérations. Les ROBDD permettent le calcul symbolique sur les fonctions booléennes et par conséquent sur les préconditions ou les postconditions. 4. Un aperçu sur le langage UgatzeADL Dans ce paragraphe, nous donnons un aperçu sur les possibilités offertes par le langage UgatzeADL liées aux types de données, sous-programmes et à la construction syntaxique component permettant de formaliser le concept composant Ugatze (voir 2.1).

4.1 Les types prédéfinis et les constructeurs de types UgatzeADL Le langage UgatzeADL offre des possibilités de typage de données comparables aux langages de programmation fortement typés comme Ada [Le Verrand, 1982]. En effet, le langage UgatzeADL supporte les types prédéfinis traditionnels (INTEGER, FLOAT, CHARACTER, BOOLEAN, STRING), les constructeurs de types simples (énuméré et type intervalle) et les constructeurs de types composés (array et record). Les types supportés par le langage UgatzeADL permettent de typer les points d entrée de données (IIP), les points de sortie de données (OIP) et les points d opération (PIOP et UIOP) des composants Ugatze (voir 2.1) 4.2 Les sous-programmes UgatzeADL Pour pouvoir formaliser les opérations des composants Ugatze et des interactions ad hoc, le langage UgatzeADL propose le concept sous-programme doté de deux parties : syntaxique et sémantique. La partie syntaxique est similaire à celle du concept sous-programme Ada : distinction nette entre function et procedure, transmission logique des paramètre (in, out, in out) et tous les paramètres formels d une fonction UgatzeADL sont de nature logique in. Quant à la partie sémantique, le langage UgatzeADL propose des assertions externes : précondition (require) et postcondition (ensure). Sachant qu une assertion est une expression de type booléen. Le langage UgatzeADL supporte les opérateurs logiques et relationnels classiques. De plus, il propose une entité prédéfinie appelée Result permettant de mieux spécifier une fonction UgatzeADL, un peu d une façon similaire, à l entité Result du langage Eiffel [Meyer, 1991]. 4.3 La construction syntaxique component Un composant Ugatze est un composant réutilisable et adaptable pour différentes applications en fonction de l utilisation des points d interaction des composants disponibles dans l infrastructure de réutilisation. Le langage UgatzeADL propose une construction appelée component (voir figure 1) permettant de regrouper tous les aspects relatifs (donnée, contrôle) à un composant Ugatze. Dans la suite, nous nous contentons de présenter l aspect donnée. Un composant UgatzeADL comporte une séquence de sections permettant respectivement de déclarer des constantes, des types, points d entrée de données, points de sortie de données, points d opérations offertes et points d opérations requises et invariant. La figure 2 donne un composant appelé tri permettant de recevoir un tableau non trié (t_non_trie) et d envoyer le même tableau trié (t_trie). La figure 3 spécifie en UgatzeADL un composant appelé compte offrant des services permettant de manipuler un compte bancaire. Ces services sont considérés

comme des sous-programmes UgatzeADL dotés des préconditions, postconditions et un invariant. Component identificateur is const --déclaration des constantes type -- déclaration des types de données IIP -- points d entrée de données OIP --points de sortie de données PIOP -- points d opérations offertes UIOP -- points d opérations requises invariant --invariant éventuel du composant end identificateur ; Figure 1. Construction syntaxique d un component de UgatzeADL

Component tri is const n=100 ; type index=1..n ; tableau=array [index] of float; IIP t_non_trie : tableau; OIP t_trie : tableau; end tri ; Figure2. Composant tri en UgatzeADL Component compte is IIP solde_minimum : float ; OIP solde : float ; PIOP procedure verser (somme : in float) ; require somme>0 ; ensure solde =old solde+ somme; procedure retirer (somme : in float) ; require somme>0 ; solde-somme>= solde_minimum ; ensure solde =old solde - somme; invariant solde>= solde_minimum ; end compte; Figure3. Composant Compte en UgatzeADL

5. Conclusion Dans cet article, nous avons préconisé une approche de formalisation du métamodèle Ugatze par le biais d un langage appelé UgatzeADL. Le langage UgatzeADL respecte aussi bien les exigences provenant de l DIM (Ingénierie Dirigée par les Modèles) que les exigences provenant de la vérification formelle des propriétés sur les architectures logicielles. De plus, nous avons donné un aperçu sur le langage UgatzeADL: possibilités liées aux types de données, aux sousprogrammes (syntaxe et sémantique) et à la construction Component. Quant aux perspectives de ce travail, nous comptons poursuivre la définition de notre langage UgatzeADL pour intégrer les autres concepts du métamodèle Ugatze, concevoir et réaliser l environnement UgatzeADL. 6. Bibliographie [ACCORD, 2002] «Projet ACCORD: Etat de l art sur les Langages de Description d Architecture (ADL)», 2002. http:// www.infres.enst.fr.projet/accord/ [ASIMIL, 2002] ASIMIL European Project, Presentation of the ASIMIL Project, http://www.cordis.lu/ist/projects/99-11286.htm [Aniorté, 2004] Aniorté P., «Vers des systèmes distribués et hétérogènes : Une approche basée composants guidée par les modèles», Habilitation à Diriger des Recherches, Université de Pau et des Pays de l Adour, 21 octobre 2004. [ASIMIL, 2002] ASIMIL European Project, Presentation of the ASIMIL Project, http://www.cordis.lu/ist/projects/99-11286.htm. [Blanc, 2005] Blanc X., MDA en action, Ingénierie logicielle guidée par les modèles, Eyrolles 2005. [Bézivin, 2002a] Bézivin J., Blanc X, Promesses et interrogations de l approche MDA, Dévelopeur Référence-Septembre 2002. http://www.devreference.net/. [Bézivin, 2002b] Bézivin J., Blanc X, MDA : Vers un important changement de paradigme en génie logiciel, Dévelopeur Référence-Juillet 2002, http://www.devreference.net/. [Bryant, 1986], Bryant R.E, «Graph-based algorithms for boolean function manipulation», IEEE Transactions on computers, C-35: 677-691, 1986. [Bryant, 1992] Bryant R.E, «Symbolic Boolean Manipulation with Ordered Binary Decision Diagrams», IEEE Transactions an comuters»,acm Computing Surveys, 1992. [Le Verrand, 1982] Le Verrand D., Le langage Ada, Dunod Informatique, 1982. [Meyer, 1991] Meyer B., Conception et Programmation par Objets, InterEditions, 1991. [Meyer, 1992] Meyer B (1992). «Applying Gesign by Contract» IEEE Computer, vol, 25, pp 40-51. [OMG, 2003a] MDA Guide, version 1.0, http://www.omg.org, Juin 2003.

[OMG, 2003b] Object Management Group. UML2.0 Superstructure Specification: Final Adopted Specification. http://www.omg.org/docs/ptc /03-08-02.pdf (August 2003). [Seyler 2004] Seyler F., «Ugatze : métamodélisation pour la réutilisation de composants hétérogènes distribués», Thèse de l Université de Pau et des Pays de l Adour, 16 décembre 2004. [Shaw, 1996] Shaw M., Garlan D., «Software Architecture : Perspective on an Emerging Discipline», Prentice Hall, 1996.