Formalisation des propriétés temporelles avec TOCL

Maintenant que nous avons étendu la syntaxe abstraite avec les informations dynamiques, nous pouvons formaliser les propriétés temporelles définies dans la partie 5.2.1 sur la syntaxe abstraite elle-même. Celles-ci devront être vérifiées dans le cadre de la validation dynamique du modèle. Afin de les exprimer direc-tement sur la syntaxe abstraite, nous avons besoin d’un langage qui s’appuie sur les concepts de métamodélisation. Nous présentons dans un premier temps les lan-gages existants. Nous formalisons ensuite les propriétés décrites pourXSPEM avec TOCL (Temporal OCL) [ZG02,ZG03], le langage retenu, et montrons comment il peut s’intégrer à un langage de métamodélisation comme MOF.

Choix du langage pour la spécification des propriétés temporelles

OCL a été introduit par l’OMG afin de spécifier les propriétés structurelles sur des modèles. Il est devenu le langage standard pour exprimer des propriétés structurelles sur les modèles UML. Il existe aussi de nombreux outils permettant de vérifier ces propriétés. Pour la spécification de propriétés temporelles, des travaux plus récents proposent d’étendre la syntaxe et la sémantique usuelle d’OCL pour prendre en compte des opérateurs temporels. Tous ces travaux sont réalisés dans un contexte UML et n’abordent pas la manière dont le système de transition peut être dérivé du modèle.

Dans le cadre de notre état de l’art, nous avons plus particulièrement étudié les travaux de [ZG02,ZG03] qui proposentTOCL, pourTemporal OCL, une ex-tension d’OCL avec les opérateurs de la logique temporelle linéaire. Ils définissent la sémantique à partir d’une sémantique de trace du modèle UML. Ce travail a été

implanté pour l’évaluation de propriétés temporelles sur les traces dans l’outil USE [USE07].

D’autres travaux, comme [Fla03] et [FM03], se sont focalisés sur l’expression de contraintes temps-réel en gardant la syntaxe initiale d’OCL. Ils s’appuient sur des machines à états pour exprimer les contraintes dynamiques du système. Ils proposent de traduire leurs contraintes enClocked-CTL.

Dans [CK02], les auteurs proposent d’exprimer les contraintes temps-réel en utilisant deux nouvelles classes, Time et Events. Un nouveau template OCL est également introduit afin d’y traduire les contraintes usuelles (pre-, post-, inv et action). La sémantique est là aussi définie comme une sémantique de trace.

Dans [DKR00], les auteurs expriment les contraintes OCL non temporelles dans une version orienté-objet de CTL. Ils ont défini formellement l’état d’un mo-dèle UML et sont en mesure de vérifier si une propriété exprimée en OCL peut être vérifiée dans chaque état accessible du système.

Les travaux de [BFS02] introduisent également un nouveautemplateOCL. Ils traduisent les contraintes enOµ(OCL)-calculus, unµ-calcul observationnel dont les expressions sont des expressions OCL. La sémantique deOµ(OCL)-calculus est définie à partir des états de [DKR00]. En utilisant les outils de vérification de modèle (model-checking), les auteurs peuvent vérifier les propriétés sur un terme CCS qui modélise le modèle UML.

Tous ces travaux présentent le moyen d’étendre OCL pour spécifier des contraintes temporelles afin de pouvoir les vérifier ou les simuler plus tard, mais ne présentent pas cette dernière étape. D’autre part, ces différentes approches ont toutes été in-troduites pour UML.

Afin de formaliser les propriétés temporelles définies pourXSPEM, nous avons choisi TOCL (la proposition de P. Ziemann & M. Gogolla) pour deux raisons prin-cipales :

1. La sémantique des expressions temporelles est formellement définie à partir d’une sémantique de trace. Chaque trace est une séquence finie d’états du système, « capturant » le système en cours d’exécution. Même si ce travail a initialement été défini sur des modèles UML, la sémantique de trace peut facilement être généralisée à une séquence d’états arbitraires tout en conser-vant la sémantique initiale des opérateurs temporels.

2. La syntaxe de cette extension d’OCL est particulièrement naturelle. Elle in-troduit aussi bien les opérateurs temporels classiques du futur commenext, existsNext,always,sometimesque les opérateurs duaux pour le passé. Nous nous concentrerons dans la suite de notre travail sur la manipulation des opé-rateurs temporels portant sur les états futurs du système.

Le langage TOCL

Pour un modèleXSPEM, l’état d’un procédé est décrit précisément à partir de l’état de chacune des activités. Nous définissons l’ensemble finiSde ces états. Soit

5.2. DÉFINITION DES INFORMATIONS DYNAMIQUES 89 Al’ensemble des activités (c.-à-d. instance deActivity) du modèle. Soit également Σl’ensemble décrivant l’état du procédé : Σ = A 7→ S. Notons que dans notre étude, l’ensembleA est fixe au cours de l’exécution. Nous ne considérons donc pas la création et la suppression dynamique d’objets (c.-à-d. d’activités, dans notre cas). Nous reviendrons sur cet aspect dans le dernier chapitre.

Une trace ˆσ ∈ Σ^∗ du procédé est une séquence finie maximale des états du procédéhσ0, . . . , σ_ni, où σ_i ∈ Σetσ₀ spécifie l’état initial du procédé. Séman-tiquement, nous avons deux types de transitions. Premièrement, les transitions de passage du temps continu qui sont ici inobservables et qui consistent à incrémenter simultanément toutes les horloges des activités par une quantitédt. Deuxièmement, les transitions basées sur les événements qui changent l’état des activités en cours tel que défini par l’expert dans la figure5.4. Deux états consécutifs d’une exécution sont liés par une combinaison de transition de passage du temps, suivie d’une tran-sition basée sur les événements. Par exemple, considérons une activitéA1. Quand elle est démarrée (événementStartActivity), elle est dans l’état< started, ok,0>.

Son horloge interne va ensuite évoluer en fonction des transitions de passage de temps. Enfin, l’événementFinishActivityfera évoluer l’état de l’activité en fonc-tion de la valeur de l’horloge interne.

Notons que cette sémantique de trace peut facilement être réutilisée pour étendre TOCL par la définition de nouveaux opérateurs. Par exemple, pour faciliter la dé-finition de nos propriétés liées à l’ordonnancement, nous introduisons un nouvel opérateurprecedes. Cet opérateur peut être décrit en utilisant les opérateurs précé-dents :

e₁precedese₂ =always!(e₂)untile₁

Cet opérateur peut formellement être défini par la sémantique de trace suivante :

IJe1precedese₂K(ˆσ, i) =

Les expressions sont évaluées dans un environnement composé d’une séquence ˆ

σd’état, et d’un indice de référenceidans la trace. La sémantique d’une expression eest définie récursivement par la fonctionIJeK: Σ^∗×N→❜♦♦❧❡❛♥.

Les expressions de notre extension de TOCL sont maintenant des expressions OCL sur les éléments d’un modèle utilisant ces opérateurs temporels. Il est donc possible de définir ces expressions à l’aide des noms d’états définis précédemment dans l’ensembleS.

Formalisation en TOCL des propriétés surXSPEM

Nous pouvons maintenant reprendre les propriétés temporelles exprimées pré-cédemment afin de les formaliser en fonction de la syntaxe abstraite complétée par les informations dynamiques. Par exemple, pour les propriétés universelles sui-vantes :

MOF::Core::Basic

Type

Property

constrainedElement 1..*

properties 0..*

OCL::Expression

OclExpression

body 0..1

TOCL

ToclOperator

arguments 1..2 {ordered}

FIGURE5.3: Promotion deTOCLau niveau du MOF

– toute activitéanon optionnelle doit démarrer :

always(✭❛✳st❛t❡ ❂ ♥♦t❙t❛rt❡❞✮ ❛♥❞ ✭♥♦t ❛✳✐s❖♣t✐♦♥❛❧✮

=⇒ sometime✭❛✳st❛t❡ ❂ st❛rt❡❞✮), – toute activitéadémarrée doit s’accomplir :

always(✭❛✳st❛t❡ ❂ st❛rt❡❞✮ =⇒ sometime✭❛✳st❛t❡ ❂ ❝♦♠♣❧❡t❡❞✮), – quand une activitéaest terminée, elle doit rester dans cet état :

✭❛✳st❛t❡ ❂ ✜♥✐s❤❡❞✮ =⇒ always✭❛✳st❛t❡ ❂ ✜♥✐s❤❡❞✮, – . . . .

Pour une propriété existentielle, nous vérifions sa négation. Si l’analyse donne une réponse positive, il n’y a pas de trace qui satisfasse la propriété. Au contraire, si l’analyse donne une réponse négative, la propriété existentielle est vérifiée et le contre-exemple identifié est une des traces qui satisfait la propriété temporelle. Par exemple, nous formalisons le fait qu’une activitéadoit terminer dans l’intervalle de tempstminettmaxde la manière suivante :

alwaysnot(a.time=ok) ≡ always(a.time=tooEarly||a.time=tooLate)

Intégration de TOCL dans une approche de métamodélisation

Nous avons illustré ci-dessus la syntaxe concrète textuelle et la sémantique associée de notre extension de TOCL. Afin de l’intégrer maintenant dans une approche de métamodélisation, et donc de pouvoir définir les propriétés au ni-veau du métamodèle, il est nécessaire de définir sur le langage de nini-veau M3 (p. ex. le MOF [OMG06b]) la syntaxe abstraite d’OCL et de l’extension tempo-relle TOCL. Pour offrir la possibilité d’utiliser TOCL dans la définition de n’im-porte quel DSML, nous partons de la syntaxe abstraite d’OCL définie dans [RG99]

et définissons sa promotion (structurelle) au niveau du MOF (paquetageOCL : :Ex-pressionsur la figure5.3). Nous ajoutons également l’ensemble des opérateurs tem-porels définis dans TOCL et dans l’extension définie ci-dessus (paquetageTOCL sur la figure5.3). TOCL peut ainsi facilement s’implanter, par exemple dans l’en-vironnement Eclipse [Ecl07], comme une extension du projet EMF [EMF07] four-nissant le langage de métamodélisation Ecore [BSE03].

5.3. EXPLICITATION DU COMPORTEMENT DE RÉFÉRENCE 91