Exemples de contraintes transform´ees

La contrainte introduite dans la section 7.3.7 repr´esente le r´esultat de la transformation d’une contrainte ´ecrite dans le profil ACL pour xAcme vers le profil standard. Celle-ci est donn´ee dans le listing ci-dessous.

c o n t e x t SystemeContr ol eA cc e s : ComponentInstance i n v : SystemeContr o le Ac ce s . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e . i n t e r f a c e I n s t a n c e −>f o r A l l ( i : I n t e r f a c e I n s t a n c e | ( i . d i r e c t i o n = # i n ) or ( i . d i r e c t i o n = # o u t ) ) and SystemeContr o le Ac ce s . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e −>f o r A l l ( con : C o n n e c t o r I n s t a n c e |

( con . i n t e r f a c e I n s t a n c e −>s i z e ( ) = 2 ) and ( ( con . i n t e r f a c e I n s t a n c e . d i r e c t i o n = # i n ) or ( con . i n t e r f a c e I n s t a n c e . d i r e c t i o n = # o u t ) ) ) and SystemeContro le Ac c es . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e −>f o r A l l ( con : C o n n e c t o r I n s t a n c e | con . i n t e r f a c e I n s t a n c e −>f o r A l l ( iCon : I n t e r f a c e I n s t a n c e | SystemeContr o le Ac ce s . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e

−>e x i s t s ( com : ComponentInstance | com . i n t e r f a c e I n s t a n c e

−>e x i s t s ( iCom : I n t e r f a c e I n s t a n c e | ( iCon i n SystemeContro le A cc e s . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . l i n k I n s t a n c e . p o i n t . a n c h o r O n I n t e r f a c e ) and ( ( iCom . d i r e c t i o n = # i n ) and ( iCon . d i r e c t i o n = # o u t ) ) or ( ( iCom . d i r e c t i o n = # o u t ) and ( iCon . d i r e c t i o n = # i n ) ) ) ) ) ) and SystemeContro le Ac c es . s u b A r c h i t e c t u r e . i s C o n n e c t e d ( ) and SystemeContro le Ac c es . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o n n e c t o r I n s t a n c e −>s i z e ( ) = SystemeContro le A cc e s . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e−>s i z e ( ) − 1 and SystemeContro le Ac c es . s u b A r c h i t e c t u r e . a r c h I n s t a n c e . c o m p o n e n t I n s t a n c e −>f o r A l l ( comp : ComponentInstance | ( comp . i n t e r f a c e I n s t a n c e −>s i z e ( ) = 2 ) and ( comp . i n t e r f a c e I n s t a n c e −>e x i s t s ( i : I n t e r f a c e I n s t a n c e | i . d i r e c t i o n = # i n ) ) and ( comp . i n t e r f a c e I n s t a n c e −>e x i s t s ( i : I n t e r f a c e I n s t a n c e | i . d i r e c t i o n = # o u t ) ) )

Dans l’un de ces invariants, on utilise l’op´eration isConnected(). Cette op´eration est as- soci´ee dans ce profil au type SubArchitecture. Ce type a la mˆeme s´emantique que le type Configuration dans le profil standard ACL.

Les concepts de cette contrainte, qui sont transform´es vers le profil standard ArchMM, sont r´esum´es dans le tableau 7.1

Cette mˆeme contrainte s’´ecrit dans le profil ACL pour CCM de la mani`ere suivante :

c o n t e x t SystemeContr o le Ac ce s : ComponentAssembly i n v : SystemeCon tro le Ac c es . c o n n e c t i o n . p o r t

−>f o r A l l ( p : P o r t | ( p . provided −>s i z e ( ) = 1 ) or ( p . used−>s i z e ( ) = 1 ) )

and

SystemeCon tro le Ac c es . c o n n e c t i o n −>f o r A l l ( con : Connection | ( con . p o r t . provided −>s i z e ( ) = 1 )

and ( con . p o r t . used−>s i z e ( ) = 1 ) ) and

SystemeCon tro le Ac c es . i s C o n n e c t e d ( ) and

SystemeCon tro le Ac c es . c o n n e c t i o n −>s i z e ( )

−>s i z e ( ) − 1 and

SystemeContr o le Ac ce s . c o n n e c t i o n . p o r t . component −>a s S e t ( ) −>f o r A l l ( com : Component |

com . p o r t −>s i z e ( ) = 2

and com . p o r t −>e x i s t s ( p : P o r t | p . provided −>s i z e ( ) = 1 ) and com . p o r t −>e x i s t s ( p : P o r t | p . used−>s i z e ( ) = 1 )

Dans le tableau 7.2 sont identifi´es les concepts de cette contrainte ´ecrite dans le profil ACL pour CCM et qui sont transform´es vers le profil standard d’ACL.

Lors de la transformation, les patrons de navigation sont d’abord recherch´es dans la contrainte source, pour appliquer les r`egles de transformation correspondantes. Si un patron correspond, la portion de la contrainte est transform´ee par son ´equivalent dans le profil standard. Si aucun patron n’est trouv´e, les relations entre abstractions sont recherch´ees. Dans ce cas, si une rela- tion est trouv´ee, elle est remplac´ee par ce qui lui est associ´ee dans le profil standard. Si aucune relation ne correspond, lors de l’analyse, la recherche des abstractions commence. Chaque abs- traction trouv´ee est remplac´ee par le concept qui lui correspond dans ArchMM. Si aucun de ces cas n’est trouv´e dans la contrainte source, aucune r`egle n’est appliqu´ee et l’unit´e syntaxique de la contrainte reste inchang´ee. C’est le cas, par exemple, de l’identificateur du composant

Nature du concept Concepts profil xAcme Concepts profil standard

Abstractions architecturales ComponentInstance CompositeComponent

InterfaceInstance Port

ConnectorInstance Connector

SubArchitecture Configuration

in (component) Input

out (component) Output

in (connector) Source

out (connector) Sink

Relations entre abstractions componentInstance.interfaceInstance component.port connectorInstance.interfaceInstance connector.role interfaceInstance.direction (component) port.kind interfaceInstance.direction (connector) role.kind

Patrons de navigation componentInstance.subArchitecture component.subComponent .archInstance.componentInstance

componentInstance.subArchitecture component.configuration.binding .archInstance.connectorInstance .role.connector

componentInstance.subArchitecture compositeComponent.configuration .archInstance.linkInstance .binding.port− >union(compositeComponent .point.anchorOnInterface .configuration.binding.role)

TAB. 7.1 – Projection de concepts entre le profil xAcme et le profil standard

Nature du concept Concepts profil CCM Concepts profil standard

Abstractions architecturales ComponentAssembly CompositeComponent

Relations entre abstractions port.provided port.kind=’Input’

port.used port.kind=’Output’

componentAssembly.connection.port compositeComponent.subComponent.port

Patrons de navigation componentAssembly.connection compositeComponent.configuration .binding.role.connector

componentAssembly.connection compositeComponent.subComponent .port.component

(SystemeControleAcces), ou les op´erations de collections comme asSet() ou size().

Vous remarquez que certaines des r`egles mentionn´ees ci-dessus sont ambigu¨es. Elles ont la mˆeme condition d’application, comme interfaceInstance.direction dans le tableau 7.1. Ce qui distingue ces deux r`egles est leur contexte. Dans cet exemple, le contexte de la premi`ere r`egle est component et la seconde connector. Comme pr´ecis´e pr´ec´edemment, lors de la s´erialisation de l’arbre syntaxique des contraintes, des informations de types sont stock´ees. Ces informations concernent le contexte de l’unit´e syntaxique en question. Selon la valeur de cette information (component ou connector, dans l’exemple), la r`egle de transformation `a appliquer est choisie.

Certaines v´erifications de type sont faites pour les op´erations de collections, lors de la transformation. Si une op´eration de collection est retrouv´ee et que celle-ci ne correspond pas au type de l’unit´e syntaxique g´en´er´ee `a laquelle elle s’applique, cette op´eration est remplac´ee par son ´equivalent ou supprim´ee. Par exemple, si on g´en`ere `a partir d’un multi-ensemble (BAG) de composants un ensemble simple (SET), et que l’op´eration `a transformer est asSet(), celle-ci est remplac´ee par une unit´e syntaxique vide. En effet, le rˆole de cette op´eration est de transformer un multi-ensemble en un ensemble simple. Cette op´eration n’a donc aucun sens lorsqu’elle est appliqu´ee `a un ensemble simple.

Dans cette approche, il est int´eressant de recourir `a des techniques de simplification des contraintes [56, 21]. En effet, les contraintes, g´en´er´ees apr`es transformation vers le profil standard, contiennent parfois beaucoup de redondance (qui n’influent pas la s´emantique de la contrainte). Des contraintes, dans ce cas, plus simples (et s´emantiquement ´equivalentes) peuvent remplacer ces derni`eres. Il est ´evident que les techniques de simplification des contraintes sont utilis´ees pour une meilleure compr´ehension de celles-ci. Ici, la simplification vise simple- ment `a obtenir une ´evaluation optimale (avec un temps d’ex´ecution minimal) des contraintes.

La m´ethode de transformation de contraintes propos´ee ci-dessus ne constitue pas la solu- tion optimale pour une transformation haut niveau de contraintes architecturales. En effet, les ´etapes coˆuteuses de compilation, de s´erialisation et de d´es´erialisation ne constituent que des ´etapes suppl´ementaires qui ajoutent un coˆut au d´eveloppement et `a l’ex´ecution de l’´evaluation des d´ecisions architecturales. En plus, XSLT est un langage bas niveau d´edi´e uniquement `a la transformation de documents semi-structur´es. Il est plus judicieux de formaliser les projections, entre les diff´erents profils et le profil standard, `a l’aide d’un langage de r`egles ou un langage haut niveau d´edi´e `a la transformation de mod`eles [51].