• Aucun résultat trouvé

Deuxi` eme partie

6.4 Identification Rule Language (IRL)

de la litt´erature. L’id´ee derri`ere ce langage n’est pas de cr´eer un nouveau langage de contrainte tel que OCL, mais de cr´eer un langage pivot avec lequel les utilisateurs finaux (par exemple, chercheurs universitaires et analystes) peuvent d´efinir facilement et avec pr´ecision les hypoth`eses sans devoir maˆıtriser OCL ou le langage de conception cible. Le r´ef´erentiel d’analyse qui utilise IRL pour exprimer ses r`egles sera donc g´en´erique.

6.4 Identification Rule Language (IRL)

Le mod`ele le plus simple permettant de d´efinir des hypoth`eses est la logique propositionnelle. Par exemple, “le syst`eme a une architecture monoprocesseur” est une proposition. Cependant, la logique propositionnelle pr´esente certaines limites. L’une des principales limites est qu’il est impossible de parler de propri´et´es qui s’appliquent `a des cat´egories de sujets. Par exemple, “il existe au moins n tˆaches dont le temps de r´eponse est inf´erieur `a l’´ech´eance” est une hypoth`ese qui ne peut pas ˆetre exprim´ee `a l’aide de la logique propositionnelle. Ainsi, l’expressivit´e de la logique des pr´edicats est n´ecessaire dans notre situation. La diff´erence principale est que la logique des pr´edicats, contrairement `a la logique des propositions, contient des quantificateurs (existentiel, universel, ...) et permet de travailler avec des variables. Pour les raisons mentionn´ees ci-dessus, on s’est inspir´e du paradigme de la logique des pr´edicats pour formaliser notre langage de d´efinition des r`egles d’identification.

On rappelle que l’objectif de notre travail n’est pas de proposer une autre impl´ementation de la logique du premier ordre (comme OCL ou la logique de description (Description Logic - DL [Baa02]) qui est utilis´ee principalement dans les domaines de l’ing´enierie bas´ee sur la connaissance et les ontologies), mais un langage contrˆol´e et expressif se focalisant ainsi sur un domaine sp´ecifique. IRL ´etant un langage d´edi´e, on pr´esente ci-apr`es sa syntaxe abstraite (m´ eta-mod`ele). La figure 6.11 montre un extrait du m´eta-mod`ele IRL (exprim´e en Ecore [Ecl]) o`u les classes de couleur grise sont des classes abstraites. Le m´eta-mod`ele contient deux parties. La premi`ere partie (voir la partie A de la figure 6.11) d´ecrit la structure des pr´edicats qui est fixe, tandis que la seconde partie (voir la partie B de la figure 6.11) est ´evolutive et d´edi´ee aux concepts temps r´eel utilis´es pour les pr´edicats.

6.4.1 Syntaxe abstraite

6.4.1.1 Structure du pr´edicat (logique du premier ordre)

L’´el´ement central de la premi`ere partie du langage IRL est la classe Expression (voir la figure 6.11) dont les instances repr´esentent les pr´edicats en r´ealit´e. Chaque instance de la classe Expression se compose d’un ensemble de variables (instances de la classe Variable) et d’une proposition (instance de la classe Proposition).

Chaque variable (instance de la classe Variable) est caract´eris´ee par un quantificateur (exist ou forAll qui sont repr´esent´es par les ´enum´erations ExistentialQuantifier et UniversalQuan-tifier) et un nom. Une variable peut ˆetre soit naturelle (instance de la classe NaturalInteger), soit r´eelle (instance de la classe Real) ou appartient `a un ensemble restrictif des ´el´ements d´efini par l’utilisateur (instance de la classe UserDefinedDomain).

Chaque proposition a un op´erateur principal. Un op´erateur peut ˆetre une fonction personna-lis´ee en tant qu’instance de la classe BinaryFunction ou UnaryFunction. Sinon, l’op´erateur est une instance de la classe BasicArithmeticOperator (par exemple : addition, soustraction,...). Selon le type de la fonction utilis´ee, une proposition comporte un ou plusieurs op´erandes (ins-tance de la classe Operand). Un op´erande peut ˆetre une instance des classes suivantes : Constant, PropertyValue, Proposition ou Accessor. Chaque instance de la classe Accessor peut faire r´ef´erence `a un ´el´ement instance de la classe abstraite ReferenceableElement. Concr`etement, l’´el´ement r´ef´eren¸cable peut ˆetre une variable (instance de la classe Variable), un primitif (ins-tance de la classe PredefinedSet) ou un ensemble d´efini par l’utilisateur (instance de la classe

F igure 6. 11 Ex tr ai t du m ´e ta-mo d `el e d e p r´ed ic at : (A) : st ru ct u re de pr ´e di cat (B ) : Con ce pt s de dom ai ne te mp s r´ee l

6.4. IDENTIFICATION RULE LANGUAGE (IRL)

UserDefinedDomain).

6.4.1.2 Dictionnaire de concepts

Alors que notre objectif est d’obtenir un langage pivot ind´ependant de tous les langages de conception, nous avons choisi de s´eparer le m´eta-mod`ele en deux partie. Cela permettra d’assurer l’´evolution des concepts utilis´es dans les syst`emes temps r´eel. Dans cette perspective, contrairement aux autres langages de mod´elisation standard, qui sont des mod`eles prescriptifs, nous avons opt´e `a ce que la deuxi`eme partie du m´eta-mod`ele IRL soit descriptive [Hes06]. Par cons´equent, nous avons con¸cu la deuxi`eme partie comme un dictionnaire de concepts des syst`emes temps r´eel en nous inspirant de la notion de l’ontologie. Notons qu’`a notre connaissance, il n’existe aucune ontologie consensuelle du domaine de syst`eme temps r´eel. Actuellement, notre proposition d’ontologie contient plus de 90 concepts class´es en trois cat´egories. (i) Cat´egorie ComponentType qui contient la plupart des entit´es utilis´ees dans les syst`eme temps r´eel. (ii) Cat´egorie PropertyType qui regroupe les propri´et´es courantes des syst`eme temps r´eel, utilis´ees pour la validation temporelle. (iii) La valeur de chaque ´el´ement de la cat´egorie PropertyType peut ˆetre une valeur litt´erale ou un ´el´ement du groupe PropertyValue.

La partie (B) de la figure 6.11 repr´esente une transposition de notre ontologie dans le m´eta-mod`ele IRL. Il faut noter que toutes les classes sont li´ees par des relations d’h´eritage `

a leurs classes principales abstraites correspondantes. Cette structure permettra d’´etendre le m´eta-mod`ele en ajoutant de nouvelles classes sans impacter les instances existantes. En d’autres termes, l’´evolution de la partie (B) ne devrait pas avoir d’impact sur les hypoth`eses ayant d´ej`a ´

et´e exprim´ees en IRL avant son ´evolution.

6.4.2 Syntaxe concr`ete

Notre syntaxe concr`ete est textuelle et proche de la langue naturelle. Cette syntaxe qui sert `

a instancier IRL est d´evelopp´ee grˆace `a l’outil Xtext [EB10]. Le listing 6.1 pr´esente un extrait de la grammaire de la syntaxe concr`ete textuelle.

IdentificationRuleRepository returns IdentificationRuleRepository: {IdentificationRuleRepository}

’ IdentificationRuleRepository ’ ’{’

( allRules+=Rule ( allRules+=Rule)∗ )?

( allConstraints +=Constraint ( allConstraints+=Constraint)∗ )?

’}’;

Rule returns Rule:

’Rule’name=EString’{’

(’ description ’ ’ : ’ description=EString’;’)?

(’ references ’ ’ : ’ references +=EString (’,’ references +=EString)∗’;’)?

’content’ ’ : ’ content=Expression’;’ ’}’;

Constraint returns Constraint:’Constraint’name=EString’:’relation=Relation’; ’; Relation returns Relation: Requires | Conflicts |Equivalent;

Expression returns Expression: {Expression}

(userDefinedDomains+=UserDefinedDomain ( ”,” userDefinedDomains+=UserDefinedDomain)∗’;’)? (ownedVariables+=Variable ( ”|” ownedVariables+=Variable)∗’|’)? proposition=BooleanProposition; Variable returns Variable:

{Variable}

(( quantifier =Quantifier)? name=EString’in’

(defaultDomain=PredefinedSet|containingDomain=[UserDefinedDomain|EString]) |(( quantifier =Quantifier)? name=EString’:’componentType = ComponentType));

BooleanProposition returns Proposition : {Proposition} unaryFunction=Not’(’operand=BooleanProposition’)’ |’ ( ’leftOperand=BooleanProposition arithmeticOperator=(And|Or|Implies) rightOperand=BooleanProposition’)’ |leftOperand=NonBooleanProposition

arithmeticOperator=(Is|Diff|Eq|Geq|Gt|Lt|Leq) rightOperand= NonBooleanProposition |binaryFunction = (TypeOf | GetProperty | PropertyExist)

’(’leftOperand=VariableAccessor’,’rightOperand=PropertyType’)’

|binaryFunction = (Member | Is Bound To | Is Direct Subcomponent Of | Is Subcomponent Of)

’(’leftOperand=VariableAccessor’,’rightOperand=VariableAccessor’)’; NonBooleanProposition returns Proposition :

{Proposition}

(unaryFunction=(Source|Destination|Owner)’(’operand=(VariableAccessor)’)’

|unaryFunction=Cardinal’(’operand=(UserDefinedSetAccessor)’)’

|binaryFunction=BinaryFunction’(’leftOperand=VariableAccessor’,’rightOperand=PropertyType’)’

|operand=(Constant|Accessor|Property)

|leftOperand=NonBoolOperand arithmeticOperator=(Add|Subtract|Multiply|Divide) rightOperand=NonBoolOperand);

NonBoolOperand returns Proposition: {Proposition}

(unaryFunction=(Source|Destination|Owner)’(’operand=(VariableAccessor)’)’

|unaryFunction=Cardinal’(’operand=(UserDefinedSetAccessor)’)’

|binaryFunction=BinaryFunction’(’leftOperand=VariableAccessor’,’rightOperand=PropertyType’)’

|operand=(Constant|Accessor|Property)); ComponentType returns ComponentType:

Connection| Bus | Memory | Switch | Task |Process | Router | Processor | MutualExclusionResource | CommunicationResource | Port | System |Scheduler;

Listing 6.1 – Extrait de la syntaxe concr`ete en Xtext

Le listing 6.2 pr´esente un exemple d’une r`egle d’identification exprim´ee en IRL.

forAll t : Task | TypeOf(t,Periodicity) is Periodic ;

Listing 6.2 – Une r`egle d’identification exprim´ee en IRL

L’hypoth`ese exprim´ee dans le listing 6.2 signifie que “toutes les tˆaches du syst`eme sont p´eriodique”. La r`egle contient une variable caract´eris´ee par un quantificateur forAll, un nom est t et elle est un ´el´ement de l’ensemble de Task. La proposition est une instance de la classe BooleanProposition, elle se compose d’un op´erateur principal (i.e., is) et deux arguments. Le premier argument a une instance de fonction binaire : TypeOf avec deux op´erandes (i.e., t et le type de propri´et´e Periodicity, le deuxi`eme argument est le type de la propri´et´e Periodic. Cette r`egle d’identification est alors beaucoup plus facile `a lire par rapport `a son expression en OCL avec les concepts de MoSaRT (voir le listing 6.3).

SbTimeTrigger.allInstances()−>forAll(t:SbTimeTrigger|t.rtpPeriodicity

.oclIsTypeOf(MoSaRT::RealTimeProperties::RtpTypes::RtpPeriodicType))