sémantique fUML pour la vérification de procédés
3.2 Formalisation de UML AD et fUML
3.3.1 Propriétés de flux de contrôle
(1.1) Possibilité de complétion. Cette propriété est exprimée en vérifiant que, finalement, au moins un noeud de type activityF inal sera exécuté :
F ( fl
vœV lab(activityF inal)
(token(v)))
(1.2) Complétion propre. Cette propriété est exprimée en vérifiant que, globalement, dès qu’un noeud de type activityF inal est exécuté, cela implique qu’il n’y a pas d’autre noeud de type
actionen cours d’exécution.
G ( fl
vœV lab(activityF inal)
(token(v)) =∆ fi
vÕœV lab(action)
(¬token(vÕ)))
(1.3) Transitions mortes. Vérifier que le procédé ne contient pas d’activité morte correspond à une propriété d’accessibilité. En effet, il est nécessaire de répondre à la question : “existe-t-il une exécution telle que actionA est exécutée”. Pour répondre à cette question, la propriété est exprimée de manière à vérifier que actionA n’est jamais exécutée. Ainsi, dans ce cas-là, un contre-exemple prouve la possibilité d’exécuter cette action, et montre que la transition n’est pas morte :
’v œ V lab(action), G (¬token(v))
3.3.2 Propriétés de flux de données
(2.1) Données manquantes. Cette propriété peut être vérifiée en s’assurant que quand un noeud a des offres sur ses flux de contrôle entrants, il aura finalement des offres sur ses pins d’entrées :
G ( fi
vœV lab(action)
(pNode(v) =∆ F (pAction(v)))
(2.1) Données redondantes. Cette propriété peut être vérifiée en s’assurant que quand le procédé se termine, toutes les offres sur le flux de données doivent avoir été consommées :
G ( fl vœV lab(activityF inal) (token(v)) =∆ fi eœE,lab(target(e))œObject (¬token(e)))
3.3.3 Propriétés de Ressources
(3.1) Ressource manquante. Cette propriété peut être vérifiée en s’assurant que quand une action est prête pour être exécutée, ses ressources sont disponibles (ou avec une capacité suffisante) :
G ( fi
vœ V lab(action),
rœ Resource·
rœ Use(v)
(enabledStart(v) =∆
(3.1) Utilisation inefficace des ressources.
– Cette propriété peut être vérifiée en s’assurant que chaque ressource affectée au procédé est toujours utilisée au moins une fois :
’r œ Resource, F ( fl
vœV Lab(action),rœUse(v)
(token(v)))
– Une version plus précise de cette propriété peut être définie en s’assurant que la capacité maximale d’utilisation de la ressource finit toujours par être atteinte :
’r œ Resource, F (|{v œ {parallel} | r œ Use(v)}| = Capacity(r))
3.3.4 Propriétés de temps
(4.1) Durée du procédé. Soit t œ N la valeur représentant le nombre maximal d’unités de temps pour effectuer le procédé. Pour vérifier que le procédé termine toujours avant t correspond à :
F ( fl
vœV lab(activityF inal)
(token(v)) · (gc < t))
(4.2) Contrainte de début/fin d’activité. Soit t œ N la valeur représentant un nombre maximal d’unités de temps.
– Pour vérifier que l’action “a” commence toujours avant t unité de temps correspond à : G (start(a) =∆ (gc < t)))
– Pour vérifier que l’action “a” commence toujours après t unité de temps correspond à : G (start(a) =∆ (gc > t)))
– Pour vérifier que l’action “a” termine toujours avant t unité de temps correspond à : G (end(a) =∆ (gc < t)))
– Pour vérifier que l’action “a” termine toujours après t unité de temps correspond à : G (end(a) =∆ (gc > t)))
(4.3) Contrainte relative de début/fin d’activité. Pour définir ces propriétés, nous utilisons le domaine infini des entiers, qui en font des formules (P)LTL non standard. Le problème provient d’une des limitations de la (P)LTL : il n’est pas possible de comparer les propositions atomiques de plusieurs états à la fois. Ainsi, la comparaison de deux états donnés (ex. comparer l’horloge globale de deux états différents) est impossible. Une solution possible pour pallier cette limitation consiste à augmenter la définition de l’état (State) avec l’information nécessaire pour comparer les états. Par exemple, stocker dans chaque état un ensemble contenant chacun des noeuds déjà exécutés ainsi que l’horloge globale à ce moment-là. Par souci de lisibilité, nous allons garder l’écriture avec les données infinies. Soit t œ N la valeur représentant un nombre maximal d’unité de temps.
– Pour vérifier que l’action “a” commence toujours avant t unité de temps après que l’action “b” se soit exécutée correspond à :
– Pour vérifier que l’action “a” commence toujours après t unité de temps après que l’action “b” se soit exécutée correspond à :
’i œ N, G (end(b) · (i = gc) =∆ F (start(a) · (gc > i + t)))
– Pour vérifier que l’action “a” termine toujours avant t unité de temps après que l’action “b” se soit exécutée correspond à :
’i œ N, G (start(b) · (i = gc) =∆ F (end(a) · (gc < i + t)))
– Pour vérifier que l’action “a” termine toujours après t unité de temps après que l’action “b” se soit exécutée correspond à :
’i œ N, G (start(b) · (i = gc) =∆ F (end(a) · (gc > i + t)))
3.3.5 Propriétés métiers
Cette section présente la formalisation de l’ensemble des propriétés métiers du tableau2.1de la section2.2.2par rapport au modèle formel présenté précédemment.
Existence Permet d’exprimer des cardinalités concernant le nombre d’exécutions des noeuds : – existence(a) est la propriété qui spécifie que le noeud a œ V est exécuté au moins 1 fois :
F (token(a))
– existence_2(a) est la propriété qui spécifie que le noeud a œ V est exécuté au moins 2 fois :
F (token(a) · X (existence(a)))
– existence_3(a) est la propriété qui spécifie que le noeud a œ V est exécuté au moins 3 fois :
F (token(a) · X (existence_2(a)))
– existence_N(a) est la propriété qui spécifie que le noeud a œ V est exécuté au moins N fois :
F (token(a) · X (existence_N-1(a)))
– abscence(a) est la propriété qui spécifie que le noeud a œ V est exécuté 0 fois : G (¬token(a))
– abscence_2(a) est la propriété qui spécifie que le noeud a œ V est exécuté au plus 1 fois : ¬existence_2(a)
– abscence_3(a) est la propriété qui spécifie que le noeud a œ V est exécuté au plus 2 fois : ¬existence_3(a)
– abscence_N(a) est la propriété qui spécifie que le noeud a œ V est exécuté au plus N fois :
¬existence_N+1(a)
– range_N_M(a) est la propriété qui spécifie que le noeud a œ V est exécuté entre N et M fois :
existence_N(a) · absence_M(a)
Relation Permet d’exprimer des contraintes sur l’ordre d’exécution des noeuds :
– relation_before(a, b) est la propriété qui spécifie que a œ V est toujours exécuté avant
bœ V :
G (token(b) =∆ F≠1(token(a)))
– relation_after(a, b) est la propriété qui spécifie que a œ V est toujours exécuté après
bœ V :
G (token(b) =∆ F (token(a)))
– relation_par(a, b) est la propriété qui spécifie que a œ V est toujours exécuté en même temps que b œ V :
G (token(a) =∆ F (token(a) · token(b)))
– relation_excl(a, b) est la propriété qui spécifie que a œ V est toujours exécuté en exclusion de b œ V :
G (token(a) =∆ ¬token(b))
– relation_between(a, b, c) est la propriété qui spécifie que a œ V est toujours exécuté entre b œ V et c œ V :
G (token(a) =∆ F≠1 (tokens(b)) · F (token(c)))
ExistenceData Permet d’exprimer des contraintes sur la présence ou non de données :
– existence_data(d) est la propriété qui spécifie que la donnée d œ V lab(outPin) est disponible à la fin de l’exécution :
F (data(d))
RelationData Permet d’exprimer des contraintes sur l’ordre de création des données :
– relation_data_before(da, db) est la propriété qui spécifie que la donnée da œ
V lab(outP in) est disponible avant la donnée db œ V lab(outPin) : G ((data(db)) =∆ F≠1 ((data(da))))
– relation_data_after(da, db) est la propriété qui spécifie que la donnée da œ V lab(outPin) est disponible après la donnée db œ V lab(outPin) :
– relation_data_par(da, db) est la propriété qui spécifie que la donnée da œ V lab(outPin) est disponible en même temps que la donnée db œ V lab(outPin) :
G ((data(da)) =∆ F ((data(da)) · (data(db))))
– relation_data_excl(da, db) est la propriété qui spécifie que la donnée da œ V lab(outPin) est disponible en exclusion de la donnée db œ V lab(outPin) :
G ((data(da)) =∆ ¬(data(db)))
RelationDataActivity Permet d’exprimer des contraintes sur l’ordre de création des données par rapport à des actions :
– relation_data_act_before(d, a) est la propriété qui spécifie que la donnée d œ
V lab(outP in) est disponible avant l’exécution de l’action a œ V lab(action) : G (token(a) =∆ F≠1 (data(d)))
– relation_data_act_after(d, a) est la propriété qui spécifie que la donnée d œ
V lab(outP in) est disponible après l’exécution de l’action a œ V lab(action) : G (token(a) =∆ F (data(d)))
– relation_data_act_during(d, a) est la propriété qui spécifie que d œ V lab(outPin) est disponible pendant l’exécution de l’action a œ V lab(action) :
G (token(a) =∆ F (token(a) · data(d)))
– relation_data_act_excl(d, a) est la propriété qui spécifie que d œ V lab(outPin) est disponible en exclusion de l’exécution de l’action a œ V lab(action) :
G (data(d) =∆ ¬token(a))
– relation_data_act_between(d, a, b) est la propriété qui spécifie que d œ V lab(outPin) est disponible entre l’exécution de l’action a œ V lab(action) et b œ V lab(action) :
G (data(d) =∆ F≠1 (token(a)) · F (token(b)))
ExistenceTimeActivity Permet d’exprimer des contraintes de temps réel par rapport à l’exécution des noeuds :
– time_activity_before(a, t) est la propriété qui spécifie que a œ V lab(action) est exécuté avant t œ N unité de temps :
G (token(a) =∆ gc < t)
– time_activity_after(a, t) est la propriété qui spécifie que a œ V lab(action) est executé après t œ N unité de temps :
G (token(a) =∆ gc > t)
– time_activity_between(a, t1, t2) est la propriété qui spécifie que l’action a œ V lab(action) doit être executé entre t1 œ N et t2 œ N unité de temps :
ExistenceTimeData Permet d’exprimer des contraintes de temps réel par rapport à la disponibilité des données :
– time_data_before(d, t) est la propriété qui spécifie que la donnée d œ V lab(outPin) doit être disponible avant t œ N unité de temps :
G (data(d) =∆ gc < t)
– time_data_after(d, t) est la propriété qui spécifie que la donnée d œ V lab(outPin) doit être disponible après t œ N unité de temps :
G (data(d) =∆ gc > t)
– time_data_between(d, t1, t2) est la propriété qui spécifie que la donnée d œ V lab(outPin) doit être disponible entre t1 œ N et t2 œ N unité de temps :
G (data(a) =∆ gc > t1 · gc < t2)
ExistenceTimeResource Permet d’exprimer des contraintes de temps réel par rapport à l’utilisa-tion des ressources :
– time_resource_before(r, t) est la propriété qui spécifie que la ressource r œ Resource doit être utilisée avant t œ N unité de temps :
G ( fi
aœV lab(action)
(token(a) · r œ Use(a) =∆ gc < t))
– time_resource_after(r, t) est la propriété qui spécifie que la ressource r œ Resource doit être utilisé après t œ N unité de temps :
G ( fi
aœV lab(action)
(token(a) · r œ Use(a) =∆ gc > t))
– time_resource_between(r, t1, t2) est la propriété qui spécifie que la resource r œ
Resourcedoit être utilisé entre t1 œ N et t2 œ N unité de temps :
G ( fi
aœV lab(action)
(token(a) · r œ Use(a) =∆ gc > t1 · gc < t2))
Comme expliqué dans la section 2.2.2 page 26, il est possible de définir des variations de cet ensemble de propriétés pour vérifier différents cas plus spécifiques. Par exemple, vérifier que l’activité A est toujours exécutée directement après l’activité B (sans possibilité d’exécuter d’autre activité entre ces deux exécutions) n’est pour le moment pas exprimable à partir de l’ensemble défini ci-dessus. Seule la contrainte spécifiant que A finira forcément par être exécuté dans le futur après B (relation_after(B, A)) l’est. Par souci de simplicité d’utilisation, nous nous restreignons à ces propriétés basiques et essentielles, plûtot que de définir toutes les variations possibles. Proposer des centaines de propriétés métiers différents dont chacune d’entre elles est seulement une légère variation de la propriété précédente détruirait notre but concernant la simplicité d’utilisation de notre libraire.
Ainsi, nous définissons nos propriétés métiers par :
1. Un ensemble de propriétés basiques exprimées en PLTL, tel que la librairie proposée précédemment, et
Ainsi, la combinaison de ces propriétés basiques avec les opérateurs de logiques classiques permet d’exprimer un grand éventail de propriétés.
Example 3. La propriété “l’activité A doit être exécutée avant B et C” peut être exprimée telle
que : “relation_before(A, B) · relation_before(A, C)”.
Il est important de noter que l’utilisation directe de la libraire (c’est-à-dire sans composer les propriétés “basiques” avec des connecteurs de la logique classique) permet déjà de couvrir la grande majorité des cas nécessaires.
3.4 Conclusion
Ce chapitre propose une formalisation en utilisant la FOL de la nouvelle spécification fUML, dans le contexte de la vérification de procédé basé sur UML AD. La formalisation est capable de gérer le flux de contrôle, de données, les ressources, et les contraintes temporelles du procédé de manière unifiée. Un grand nombre de propriétés sur toutes les différentes perspectives du procédé ont été formalisées en utilisant la PLTL. Ainsi, il est possible de vérifier des propriétés impliquant toutes les dimensions du procédé. L’ensemble de ces propriétés permet de garantir la validité d’un procédé basé sur UML AD.
Une fois la formalisation établie et l’ensemble des propriétés défini, la prochaine étape consiste à choisir un langage d’implémentation. Alloy [177] a été choisi dans ce but. Le prochain chapitre présente Alloy4PV, notre implémentation de la formalisation présentée dans ce chapitre.