Prototype d`outil de modélisation graphique d`ingénierie syst

Sous-projet 1
stratégie de génération de tests sur la base de modèles
environnementaux et de modèles comportementaux
Prototype d’outil de modélisation graphique
d’ingénierie système en utilisant la génération
d’éditeur avec PAPYRUS
Livrable n˚1.1
31 août 2009
VETESS - Livrable n˚1.1
Version
1.0
EVOLUTION DU DOCUMENT
Date
Auteur
Remarques
31/08/2009 LIFC - MIPS
Niveau de Diﬀusion
Diﬀusion
CARACTERISTIQUES
Projet VETESS
Public
2
Prototype d’outil de modélisation graphique SysML
Table des matières
1 Introduction
1.1 Rappel de l’objectif du sous-projet SP1 . . . . . . . . . . . .
1.2 Situation au sein du sous-projet SP1 . . . . . . . . . . . . . .
1.3 Abréviations . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Positionnement dans l’état de l’art
2.1 Introduction au test à partir de modèles . . . . . .
2.2 Langages de modélisation pour le test . . . . . . .
2.2.1 Spéciﬁcation algébrique . . . . . . . . . . .
2.2.2 Algèbre de processus . . . . . . . . . . . . .
2.2.3 Structure de Kripke et logique temporelle .
2.2.4 Modèle de ﬂots de données . . . . . . . . .
2.2.5 Modélisation par contrat . . . . . . . . . . .
2.2.6 Système de transitions étiquetées . . . . . .
2.2.7 Machine à états ﬁnie . . . . . . . . . . . . .
2.2.8 Synthèse . . . . . . . . . . . . . . . . . . . .
2.3 Langage de modélisation pour le projet VETESS .
2.3.1 Les notations UML et SysML . . . . . . . .
2.3.2 Le langage UML4MBT de Test Designer𝑇 𝑀
2.3.3 Le langage SysML4MBT pour VETESS . .
2.4 Bilan et cas d’étude illustratif . . . . . . . . . . . .
3 Diagramme de blocs SysML4MBT
3.1 Les blocs . . . . . . . . . . . . . .
3.2 Les propriétés . . . . . . . . . . . .
3.3 Les opérations . . . . . . . . . . . .
3.4 Les associations . . . . . . . . . . .
3.5 Les signaux . . . . . . . . . . . . .
3.6 Les spéciﬁcations de ﬂux . . . . . .
3.7 Les ports . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
7
8
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
10
11
11
11
12
12
12
13
13
14
14
15
15
16
.
.
.
.
.
.
.
17
17
18
19
19
21
22
22
4 Diagramme interne de blocs SysML4MBT
23
4.1 Les propriétés . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 Les ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3 Les connecteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5 Diagramme d’états-transitions SysML4MBT
5.1 Les états . . . . . . . . . . . . . . . . . . . . .
5.2 Les pseudo-états . . . . . . . . . . . . . . . .
5.2.1 État initial . . . . . . . . . . . . . . .
5.2.2 Point de décision . . . . . . . . . . . .
5.2.3 Barre de fraction et barre de jonction
3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
26
27
27
28
29
VETESS - Livrable n˚1.1
5.3
5.4
5.2.4 État historique et état
Les transitions . . . . . . . .
5.3.1 Déclencheur . . . . . .
5.3.2 Garde . . . . . . . . .
5.3.3 Eﬀet . . . . . . . . . .
Les actions onEntry/onExit .
historique profond
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
6 Diagramme d’exigences SysML4MBT
6.1 Les exigences . . . . . . . . . . . . . .
6.2 La traçabilité des exigences . . . . . .
6.3 Les Packages . . . . . . . . . . . . . .
6.4 Les objectifs de test . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
30
30
30
30
34
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
34
34
35
39
39
7 Modélisation SysML4MBT avec PAPYRUS
8 Récapitulatif du langage SysML4MBT
8.1 Diagramme de blocs . . . . . . . . . . .
8.2 Diagramme interne de blocs . . . . . . .
8.3 Diagramme d’états-transitions . . . . . .
8.4 Diagramme d’exigences . . . . . . . . .
9 Synthèse
.
.
.
.
.
.
.
.
.
.
.
.
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
47
47
48
49
50
51
4
Prototype d’outil de modélisation graphique SysML
Table des ﬁgures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Représentation d’un bloc SysML. . . . . . . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Blocs SysML4MBT. . . . . . . . . . . . . .
Représentation d’une énumération SysML. . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Propriétés des blocs SysML. . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Opérations des blocs SysML4MBT. . . . .
Associations du diagramme de blocs SysML4MBT. . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme de blocs SysML4MBT. . . . .
Signal du diagramme de blocs SysML4MBT. . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Signaux SysML4MBT. . . . . . . . . . . .
Spéciﬁcation de ﬂux du diagramme de blocs SysML4MBT. .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Spéciﬁcation des ﬂux SysML4MBT. . . . .
Propriété du diagramme interne de blocs SysML4MBT. . . .
Types de port de SysML4MBT. . . . . . . . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme interne SysML4MBT (propriétés). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme interne SysML4MBT. . . . . .
États du diagramme d’états SysML4MBT. . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : États du diagramme d’états SysML4MBT.
Point de décision du diagramme d’états SysML4MBT. . . . .
Barres de fraction et de jonction SysML4MBT. . . . . . . . .
État historique SysML4MBT. . . . . . . . . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme d’états SysML4MBT. . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique du controller. . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique HighLight. . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique HeadLight. . . . .
Diagramme d’exigences SysML4MBT. . . . . . . . . . . . . .
𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme d’exigences. . . . . . . . . . . .
Lien satisfy simple SysML4MBT. . . . . . . . . . . . . . . . .
Liens satisfy parallèles SysML4MBT. . . . . . . . . . . . . . .
Liens satisfy multiples SysML4MBT. . . . . . . . . . . . . . .
Équivalence des liens satisfy multiples SysML4MBT. . . . . .
Diagramme d’exigences de l’exemple des feux. . . . . . . . . .
Exemple avancé de diagramme d’exigences SysML4MBT. . .
Diagramme de blocs réalisé avec PAPYRUS . . . . . . . . . .
Enumérations (dans un diagramme de blocs) réalisées avec
PAPYRUS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Signaux et spéciﬁcations de ﬂux (dans un diagramme de blocs)
réalisés avec PAPYRUS . . . . . . . . . . . . . . . . . . . . .
Diagramme interne de blocs réalisé avec PAPYRUS . . . . .
Diagramme états-transitions réalisé avec PAPYRUS . . . . .
Diagramme états-transitions réalisé avec PAPYRUS . . . . .
Diagramme d’exigences réalisé avec PAPYRUS . . . . . . . .
5
17
17
18
18
19
20
20
21
21
22
22
24
25
25
25
26
27
28
29
29
31
32
33
33
34
35
36
36
37
37
38
39
40
41
42
43
44
45
46
VETESS - Livrable n˚1.1
Liste des tableaux
1
2
3
4
5
6
7
SysML4MBT
SysML4MBT
SysML4MBT
SysML4MBT
SysML4MBT
SysML4MBT
SysML4MBT
-
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
Diagramme
de Blocs - Eléments de base. . .
de Blocs - Éléments d’un bloc. .
de Blocs - Types. . . . . . . . .
interne. . . . . . . . . . . . . . .
d’états-transitions - États. . . .
d’états-transitions - Transitions.
d’exigences. . . . . . . . . . . .
6
.
.
.
.
.
.
.
47
48
48
48
49
50
50
Prototype d’outil de modélisation graphique SysML
1
1.1
Introduction
Rappel de l’objectif du sous-projet SP1
Ce sous-projet concerne l’optimisation du nombre de séquences de tests
devant être générés sur des modèles de spéciﬁcation du système sous test.
Le but est de réduire le nombre de séquences tout en garantissant un niveau
optimal de couverture du modèle et des exigences comportementales.
1.2
Situation au sein du sous-projet SP1
Le présent document constitue un livrable du sous-projet 1 et est issu des
travaux eﬀectués au sein de la tâche 1.1. Cette tâche concerne la déﬁnition
des éléments de modélisation SysML pris en compte pour mettre en œuvre
les techniques de génération de tests à partir de modèles développées dans
le cadre du projet VETESS.
Ces éléments de modélisation doivent permettre d’une part de spéciﬁer
le système sous test, et d’autre part de spéciﬁer l’interactivité de ce dernier
avec son environnement.
Finalement, le pouvoir d’expression ainsi déﬁni doit être supporté par les
outils de modélisation du marché, notamment par l’atelier de modélisation
PAPYRUS.
Le présent document est structuré de la façon suivante :
– la section 2 introduit un bref état de l’art et positionne nos travaux
dans les travaux existants,
– les section 3,4,5 et 6 présentent respectivement les éléments du langage
SysML supportés pour spéciﬁer le diagramme de blocs, le diagramme
interne de blocs, le diagramme d’états-transitions et le diagramme
d’exigences.
– la section 7 illustre la capacité à produire un modèle SysML pour le
test avec l’outil de modélisation PAPYRUS,
– ﬁnalement, les sections 8 et 9 présentent respectivement un récapitulatif du langage SysML sélectionné et fournissent une synthèse à ce
document.
7
VETESS - Livrable n˚1.1
1.3
Abréviations
Abréviation
SUT
IUT
MBT
UML
SysML
OCL
FSM
EFSM
Référence
System Under Test = Système sous test
Implementation Under Test = Implémentation sous test
Model Based Testing = Test à partir de modèles
Uniﬁed Modeling Language
System Modeling Language
Object Constraint Language
Finite State Machine = Machine à états ﬁnis ou Automate ﬁni
Extended FSM = Machine à états ﬁnis étendue
8
Prototype d’outil de modélisation graphique SysML
2
Positionnement dans l’état de l’art
Les techniques de génération de test à partir de modèles, plus communément appelées MBT pour Model-Based Testing [UL06], ont connu depuis
plusieurs années un intérêt et un essor considérable. Cette attractivité, de
la part du milieu scientiﬁque comme industriel, s’explique notamment par
la complexité toujours croissante des systèmes informatisés et le besoin récurrent de garantir une qualité de service et de ﬁabilité optimum. En eﬀet,
générer des tests à partir de modèles de spéciﬁcations permet d’assurer un
niveau de conﬁance élevé vis-à-vis du respect des propriétés énoncées dans
le cahier des charges de l’application à tester. Ce type de technique s’avère
en plus être bon marché du fait de son automatisation partielle ou complète
rendue possible par la capacité à raisonner sur les modèles de spéciﬁcation
formelle. Toutefois, malgré des résultats connus et reconnus par les communautés scientiﬁque et industrielle, le domaine est toujours très actif pour
répondre notamment aux nouvelles exigences du marché (normalisation de
plus en plus stricte, augmentation de la qualité de service attendue, volonté
de maı̂triser les coûts,...). Garantir la qualité d’un produit logiciel représente
ainsi encore aujourd’hui un secteur dynamique pour la recherche et l’innovation comme le prouve le nombre important de conférences et de journaux
spécialisés dans cette thématique.
Cette section donne un bref aperçu des langages de modélisation les
plus utilisés pour spéciﬁer le système sous test, et pour ainsi servir de point
d’entrée aux diﬀérentes techniques de test à partir de modèles. Ainsi, après
un rapide rappel des objectifs de la génération de test à partir de modèles,
diﬀérents langages de modélisation utilisés pour modéliser le système sous
test sont présentés. Finalement, une conclusion permet de synthétiser les
éléments présentés et de positionner nos travaux dans ce paysage.
2.1
Introduction au test à partir de modèles
Un test consiste à exécuter un système ou une certaine partie de ce système en lui soumettant un ensemble de stimuli choisis, et d’observer son
comportement pour déterminer si celui-ci est conforme aux spéciﬁcations et
aux exigences initialement déﬁnies dans son cahier des charges. Cette pratique ne permet pas en théorie de s’assurer de l’absence totale de défaut,
mais participe à augmenter le niveau de conﬁance dans le logiciel lorsqu’aucun défaut ne se manifeste, tout en rendant possible la maı̂trise les coûts
de validation : la phase de test peut être interrompue à tout instant sans
remettre en cause les résultats déjà obtenus.
Dans le contexte de génération de tests à partir de modèles, la spéciﬁcation du système sous test constitue le référentiel d’entrée d’une chaı̂ne
9
VETESS - Livrable n˚1.1
automatisée qui permet à la fois de calculer des séquences de stimuli pour
lesquelles le modèle joue le rôle d’oracle en calculant les résultats attendus. Ce modèle peut être réalisé en appliquant une stratégie boı̂te blanche
ou boı̂te noire selon qu’il spéciﬁe, de manière abstraite, respectivement le
code source du système sous test ou uniquement son comportement externe
(en ignorant intentionnellement la façon dont le système sous test est codé).
Un mélange des deux approches donne lieu à l’appellation boı̂te grise. Ces
diﬀérentes stratégies ont leurs forces et leurs faiblesses. Habituellement, elles
coexistent au sein d’un même projet et sont utilisées diﬀéremment à diﬀérents niveaux d’abstraction [MSBT04].
L’approche de génération de tests à partir de modèles, mise en œuvre
dans le cadre du projet VETESS, s’appuie sur un modèle de test spéciﬁé
en appliquant une stratégie de type boı̂te noire. Ce type d’approche permet
de modéliser les stimuli à un niveau d’abstraction élevé, exploitant alors les
spéciﬁcations du comportement prévu du système sous test plutôt que leur
gestion concrète exprimée dans le code source. La stratégie boı̂te noire a ainsi
l’avantage de permettre la génération des tests indépendamment des caractéristiques et des contraintes d’implantation que le code source pourraient
présenter : cette stratégie permet donc un processus structuré et reproductible sans avoir besoin au préalable ni de la connaissance technique d’un
langage ou d’un environnement de programmation spéciﬁque, ni du code
source à tester.
Dans la prochaine section, nous présentons un échantillon de langages
de modélisation qui se prête à la mise en place de procédés de génération
de tests à partir de modèles. Finalement, nous positionnerons les travaux,
menés dans le cadre du projet VETESS, par rapport à ces éléments de la
littérature.
2.2
Langages de modélisation pour le test
Cette section donne une brève vue d’ensemble de diﬀérentes techniques,
et langages de modélisation associés, pour modéliser le système sous test. Elle
mentionne également certains outils automatisant le processus de génération
des tests à partir des modèles correspondants.
Chaque langage de modélisation permet de spéciﬁer un système avec un
pouvoir d’expression et un niveau d’abstraction qui lui sont propres. Ainsi,
les systèmes qui peuvent être modélisés avec ces langages et la nature des
tests générés peuvent diﬀérer d’une catégorie de langage à l’autre.
10
Prototype d’outil de modélisation graphique SysML
2.2.1
Spéciﬁcation algébrique
Les spéciﬁcations algébriques déﬁnissent les objets par les opérations qui
les engendrent ou les utilisent. Une théorie axiomatique complète la spéciﬁcation en donnant les propriétés attendues des objets en termes de comportements attendus. Ainsi, dans ce type de modélisation, une classe ou un
type d’objet est spéciﬁé en termes de rapports entre les opérations déﬁnies
sur ce type, mais rien n’est précisé au sujet de la représentation interne de
ces objets. Le niveau d’abstraction de ce langage est donc élevé.
Les langages OBJ [FGJM95] et Larch [GH93] sont des exemples de spéciﬁcation algébrique.
2.2.2
Algèbre de processus
Dans les algèbres de processus, on diﬀérencie la syntaxe de l’algèbre
(c’est-à-dire le langage utilisé pour décrire le système) de ses propriétés et
de sa sémantique (c’est-à-dire du sens mathématique correspondant a cette
syntaxe). Les algèbres de processus sont employées pour décrire le comportement d’observation des systèmes concurrents en déﬁnissant des modèles de
calcul (vue opérationnelle). Elles sont ainsi adaptées pour modéliser les systèmes répartis dans lesquels les processus parallèles peuvent communiquer
de manière synchrone. Un domaine d’application privilégié pour les algèbres
de processus concerne la spéciﬁcation des protocoles, par exemple, dans le
secteur des télécommunications.
Parmi les langages basés sur des algèbres de processus, on peut citer notamment LOTOS [ISO], CCS [Mil82] et CSP [Hoa78].
2.2.3
Structure de Kripke et logique temporelle
La structure de Kripke déﬁnit un automate à états ﬁnis : il s’agit ﬁnalement d’un graphe orienté dont les nœuds représentent les états accessibles
du système, et dont les arcs représentent les transitions entre ces états. Une
fonction d’étiquetage fait correspondre à chaque état un ensemble de propositions logiques vraies dans cet état. La logique temporelle est traditionnellement utilisée dans ce type de modèle pour spéciﬁer ces propriétés. Ce type de
modèle, représentant le comportement du système, a été initialement utilisé
pour eﬀectuer de la vériﬁcation de propriétés, également spéciﬁées en logique
temporelle, par des techniques de model-checking [CE81, QS82]. Lorsqu’une
propriété donnée est violée par l’automate, il est possible de récupérer la
séquence d’états, et donc de stimuli, qui la met en défaut : on parle alors de
contre-exemple.
Ce type de modèle a été utilisé plus récemment pour générer des tests. La
technique consiste à prendre en entrée un automate décrivant un système et
une propriété logique temporelle pour laquelle on veut générer des tests (i.e.
trouver une séquence de stimuli qui permet d’exercer cette propriété). On
11
VETESS - Livrable n˚1.1
soumet alors la négation de la propriété logique aﬁn de calculer un contreexemple qui constitue le cas de test désiré [CSE96, JM99].
2.2.4
Modèle de ﬂots de données
Les modèles de ﬂots/ﬂux de données (ou Dataﬂow models) décrivent
le système à travers des vecteurs de données qui lui sont soumis et qu’il
émet en réaction. Les systèmes modélisés sont considérés comme des boı̂tes
noires avec des entrées et des sorties régies par une exécution synchrone. Les
langage de ﬂots de données sont bien adaptées pour les systèmes réactifs
synchrone et sont mis en œuvre, le plus souvent, pour modéliser des systèmes critiques de sûreté.
Les langages les plus connus sont ESTEREL [BG92] et LUSTRE [CPHP87].
Ce dernier langage est notamment utilisé par l’environnement de développement SCADE, spécialisé dans la conception de logiciel critique pour l’aéronautique, le ferroviaire et les centrales nucléaires.
2.2.5
Modélisation par contrat
Il existe une vaste gamme de langages s’appuyant sur des techniques
de modélisation par contrat. Un tel modèle explicite de manière formelle les
caractéristiques à satisfaire pour exécuter chaque opération du système (précondition) et ce que l’opération s’engage alors à calculer (postcondition). De
ce fait, ce type de langage donne rarement lieu à des modèles graphiques (automates) mais permet de produire des spéciﬁcations textuelles s’appuyant
sur une notation formelle.
Parmi les langages les plus connus, on peut citer Eiﬀel [Mey97], VDM [Jon90],
Z [Spi92], B [Abr96] et OCL [WK96].
2.2.6
Système de transitions étiquetées
Les systèmes de transitions étiquetées(ou LTS - Labelled Transition Systems) sont souvent liés aux algèbres de processus car ils sont employés pour
décrire la sémantique de l’algèbre de processus. Un système de transition est
généralement déﬁni par un tuple {𝑆, 𝑠0 , Σ, 𝛿 où 𝑆 dénote un ensemble d’états
(potentiellement inﬁni), 𝑠0 est l’état initial, Σ est l’alphabet des étiquettes,
et 𝛿 : 𝑆 × Σ → 𝑆 déﬁnit la relation de transition entre les états.
Des exemples de langage de modélisation s’appuyant sur une telle sémantique sont le Π-calcul [Mil99], LOTOS [ISO], SDL [IT] ou Promela [Hol91,
Hol97].
Ce type de langage peut être étendu avec, par exemple, la déﬁnition d’entrées/sorties : on parle alors de système de transitions étiquetés entrée/sortie
(ou IOLTS - Input/Output Labelled Transition Systems). Inspiré de cette
dernière sémantique, un langage de spéciﬁcation davantage abstrait a été
inventé : il s’agit des systèmes de transitions symboliques entrée/sortie (ou
12
Prototype d’outil de modélisation graphique SysML
IOSTS - Input/Output Symbolic Transition Systems). Ces deux types de
langage se prêtent idéalement à la génération de tests et ont été la base de
nombreux outils dont les plus célèbres sont certainement TGV [FJJV97] et
STG [CJRZ02]. Dans ce contexte, de nombreux travaux ont été menés pour
caractériser les relations de conformité d’une exécution du système sous test
vis-à-vis du modèle de spéciﬁcations : on peut citer par exemple la relation
de conformité IOCO [Tre08].
2.2.7
Machine à états ﬁnie
Une machine à états ﬁnie (ou diagramme à états ﬁni) est déﬁnie par un
automate constitué d’états et de transitions qui relient ces états. L’automate est dit « ﬁni » car il possède un nombre ﬁni d’états distincts, ce qui
le diﬀérencie des systèmes de transition évoqués plus tôt. Le comportement
du diagramme est dirigé par les stimuli reçus : l’automate passe ainsi d’état
en état en fonction des stimuli reçus qui conditionnent l’activation des transitions. Ainsi, on peut voir un tel automate comme un graphe ﬁni orienté
et étiqueté, dont les états sont les sommets et les transitions sont les arêtes
étiquetées.
Les notations basées sur ces structures sont très populaires, dans le secteur
de la recherche comme celui du monde industriel, car leur expressivité limitée les rend particulièrement faciles à traiter automatiquement et, en même
temps, elles sont suﬃsamment expressives pour spéciﬁer tout système discret réactif.
Parmi les langages qui exploitent ce paradigme, on peut notamment citer les
machines d’état ﬁnis (FSM, EFSM) [CK93], les diagrammes d’états (Statechart) [Har98], les diagrammes d’états/transitions UML [RJB04].
2.2.8
Synthèse
Dans cette section, nous avons rapidement présenté les langages de modélisation les plus utilisés aujourd’hui pour mettre en œuvre des techniques
de génération de tests à partir de modèles. Dans le cadre spéciﬁque du projet VETESS, nous nous appuyons sur des spéciﬁcations de machines à états
SysML (héritées des diagrammes états/transitions UML) complétées par
des contrats au moyen du langage de contraintes OCL. La prochaine section
présente de manière plus détaillée ces éléments de modélisation.
13
VETESS - Livrable n˚1.1
2.3
Langage de modélisation pour le projet VETESS
Le projet VETESS a pour objet de générer des tests pour les systèmes
embarqués à partir de modèles spéciﬁés en SysML, dérivé du langage UML.
La chaı̂ne outillée correspondante (capable de raisonner sur de tels modèles)
s’appuie sur le logiciel Test Designer𝑇 𝑀 [BGLP08] (commercialisée par la
société Smartesting [Sma09]) qui permet la génération automatique de tests
à partir de modèles de type UML. Dans les prochaines sous-sections, nous
introduisons les deux notations UML et SysML et explicitons le cadre de
l’approche de modélisation développée au sein du projet VETESS.
2.3.1
Les notations UML et SysML
UML est un langage graphique de modélisation des données et des traitements. Il résulte de la fusion de plusieurs langages de modélisation tels
que OMT (Object Modeling Technique) [RBP+ 90], OOSE (Object Oriented Software Engineering) [Jac92] et la méthode Booch [Boo93]. Au ﬁl des
années, UML a réussi à s’imposer et est à l’heure actuelle le langage de modélisation objet le plus utilisé. Il est standardisé par l’Object Management
Group (OMG) depuis 1997 [RJB99] ; la version 2 d’UML a été adoptée par
ce consortium en 2005 [RJB04].
La notation UML 2 regroupe 13 types de diagrammes qui permettent de
modéliser tout système sous diﬀérentes vues (cas d’utilisation, logique, implémentation, processus et déploiement) [MG03]. Toutefois, chaque secteur
d’activité possède ses propres règles et caractéristiques métier. Par rapport
au formalisme UML standard, la notation UML laisse à chacun la possibilité de personnaliser les éléments de modélisation UML standards pour tenir
compte de la spéciﬁcité de son domaine d’application.
Aﬁn de pouvoir répondre aux nécessités de modélisation dans ces divers
domaines (systèmes embarqués, chimie...), UML propose un mécanisme d’extension de la notation UML. Ces extensions sont basées sur des annotations
qu’on peut poser sur des modèles UML. Les annotations possibles sont déﬁnies dans un proﬁl qui indique quelles sont leurs propriétés et leurs règles
de cohérence. Il est également possible de proposer au sein d’un proﬁl une
nouvelle notation pour un élément annoté.
Ainsi, aﬁn de répondre plus spéciﬁquement aux caractéristiques métiers
des applications de l’ingénierie système, la notation UML s’est dotée d’un
proﬁl dédié nommée SysML. Ce langage dérivé du langage UML est également standardisé par l’OMG.
Tout comme le langage UML, SysML permet la spéciﬁcation, l’analyse,
la conception, la vériﬁcation et la validation de nombreux systèmes. Cependant, SysML est spéciﬁquement dédié au processus et caractéristiques
métiers mis en œuvre pour modéliser les systèmes issus des domaines de l’in-
14
Prototype d’outil de modélisation graphique SysML
génierie automobile, de l’ingénierie acoustique et de l’aéronautique. Concrètement, ce standard reprend 7 des 13 diagrammes d’UML 2.0 (parmi ceux-ci,
trois sont modiﬁés) et comporte deux nouveaux types de diagrammes.
Dans le cadre du projet VETESS, le processus de génération de test à
partir du modèle spéciﬁant le système sous test doit être appliqué à un modèle de type SysML. La chaı̂ne outillée mise en œuvre dans cette objectif
s’appuie sur la solution de génération des tests commercialisée par Smartesting qui s’applique aux modèles de spéciﬁcation de type UML. Dans la
prochaine section, nous introduisons brièvement cette solution et positionnons les travaux eﬀectués dans le cadre du projet VETESS. Ces derniers
travaux seront présentés dans le détail dans la suite de ce document.
2.3.2
Le langage UML4MBT de Test Designer𝑇 𝑀
Le logiciel Test Designer𝑇 𝑀 constitue le support logiciel de la solution
Smartesting permettant de générer des cas de test à partir d’un modèle, spéciﬁant le système sous test, écrit avec un sous-ensemble de la notation UML,
baptisée UML4MBT [Sma09] (UML for Model-Based Testing). Concrètement, un modèle UML4MBT contient :
– un diagramme de classes modélisant la structure statique du système
sous test,
– un diagramme d’objets modélisant les entités manipulées par les cas
de test et l’état de ces entités dans l’état initial du système,
– un diagramme d’états-transitions, annoté de contraintes OCL, spéciﬁant l’aspect dynamique du système sous test.
Sur ce même principe, nous avons déﬁni une restriction sur le langage
SysML aﬁn de pouvoir exprimer les éléments de comportement du cahier des
charges nécessaires et pertinents dans le but de générer des tests à partir de
modèles spéciﬁant le système embarqué sous test. Ce sous-ensemble dédié
de la notation SysML a été baptisé SysML4MBT (SysML for Model-Based
Testing).
2.3.3
Le langage SysML4MBT pour VETESS
La notation SysML4MBT déﬁnit un sous-ensemble du langage SysML,
tel qu’il est normalisé par l’OMG, et constitue le langage d’entrée des techniques de génération de tests mis en œuvre dans le cadre de la chaı̂ne outillée
VETESS.
Pour réaliser de tels modèles SysML4MBT, nous supportons trois types
de diagrammes SysML. Concrètement, un modèle SysML4MBT contient :
– un diagramme de blocs modélisant la structure statique du système
sous test et permet de spéciﬁer son état initial,
15
VETESS - Livrable n˚1.1
– un ou plusieurs diagrammes internes de blocs spéciﬁant les interconnexions entre les diﬀérents blocs introduits le diagramme de blocs
(d’un point de vue boite blanche),
– un ou plusieurs diagrammes d’états-transitions, annotés de contraintes
OCL, spéciﬁant de manière formelle l’aspect dynamique du système
embarqué sous test,
– un diagramme d’exigences permettant d’exprimer les exigences
fonctionnelles du système embarqué sous test et de lier celles-ci avec
les éléments décrits dans les diagrammes précédents.
L’objectif de ce document consiste à déﬁnir de manière exhaustive les
diﬀérents éléments de modélisation que nous supportons au sein du sousensemble SysML4MBT. Pour illustrer le pouvoir d’expression mis en place
dans chacun de ces diagrammes, nous utilisons tout au long de ce document
un exemple illustratif portant sur un système simpliﬁé de l’éclairage avant
des feux de véhicules.
2.4
Bilan et cas d’étude illustratif
Aﬁn d’illustrer le langage SysML4MBT, nous utilisons un exemple de
gestion simpliﬁée de l’éclairage avant des feux de véhicules (feux de croisement et phares) appelé 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠. Dans ce système de gestion, nous
considérons que l’utilisateur peut stimuler le système de deux manières :
– il demande l’allumage/l’extinction des feux de croisement (highlights),
– il demande l’allumage/l’extinction des phares (headlights).
Un commodo permet à l’utilisateur de commander l’allumage et l’extinction des feux. Les feux peuvent ainsi être dans quatre états diﬀérents :
– feux de croisement et phares éteints,
– feux de croisement allumés et phares éteints,
– feux de croisement éteints et phares allumés,
– feux de croisement et phares allumés.
Dans les prochaines parties du document, nous présentons, diagramme
par diagramme, le langage SysML4MBT supporté par les techniques de génération de tests développées dans le cadre du projet VETESS. Ce pouvoir d’expression est tout au long illustré par les diﬀérents diagrammes
SysML4MBT permettant de modéliser les aspects fonctionnels du cahier
des charges de l’exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠.
16
Prototype d’outil de modélisation graphique SysML
3
Diagramme de blocs SysML4MBT
Le diagramme de blocs permet de représenter une vue statique du système, c’est-à-dire sa structure. Il s’agit d’une vision “boite noire” de ce que
l’on modélise.
3.1
Les blocs
Un système se décompose en plusieurs parties ou composantes. Chacune
d’entre elles est modélisée par un bloc. Un bloc est représenté sur la ﬁgure 1.
Il est nécessaire d’avoir un bloc qui représente l’ensemble du système.
Figure 1 – Représentation d’un bloc SysML.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
On découpe notre système aﬁn de modéliser les diﬀérents composants.
On obtient alors 6 blocs qui sont :
– le bloc qui représente le système entier (FontLightingsSystem),
– le bloc qui représente le controleur (Controller),
– le bloc qui représente le feux de croisement gauche (LeftHighLight),
– le bloc qui représente le feux de croisement droit (RightHighLight),
– le bloc qui représente le phare gauche (LeftHeadLight),
– et le bloc qui représente le phare droit(RightHeadLight).
Ces blocs sont représentés sur la ﬁgure 2.
Figure 2 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Blocs SysML4MBT.
17
VETESS - Livrable n˚1.1
3.2
Les propriétés
Chaque bloc peut contenir des propriétés. Il s’agit des valeurs d’état de
chaque partie. Les propriétés sont représentées par un nom, un type et une
valeur par défaut. Cette valeur par défaut représente la valeur d’initialisation du système. Les propriétés représentent, au travers des diﬀérents blocs
auxquels elles sont attachées, les variables d’environnement du système et les
informations stockées dans le système. Les types que l’on prend en compte
dans le cadre du projet VETESS sont les suivants :
– Les booléens.
– Les entiers.
– Les types déﬁnis par les énumérations.
Les énumérations sont des éléments qui déﬁnissent des listes de choix.
Par exemple la ﬁgure 3 représente un nouveau type “TypeEnum” pouvant
prendre la valeur “Valeur1” ou “Valeur2”.
Figure 3 – Représentation d’une énumération SysML.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Dans notre exemple, la seule information à stocker est la position du
commodo pour chacun des types de feux. Ainsi, le bloc “Controller” en
SysML4MBT a deux propriétés intitulées : ControllerHighPosition (pour
les feux de croisement) et ControllerHeadPosition (pour les phares). Chaque
propriété prend une valeur sur deux possibles à savoir ON et OFF. On met
donc en place une énumération qui propose les deux valeurs. La propriété
doit également avoir une valeur par défaut, dans notre cas, initialement, tous
les feux sont éteints (OFF et OFF). La ﬁgure 4 représente ces données avec
le langage SysML4MBT.
Figure 4 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Propriétés des blocs SysML.
18
Prototype d’outil de modélisation graphique SysML
3.3
Les opérations
On peut également attacher à un bloc une ou plusieurs opérations. Une
opération représente une action que peut exécuter ce bloc. La structure est
la suivante :
+NomOpération(Param1 : TypeParam1 , . . .) : TypeRetour
Ce sont les opérations exécutables par le système. Elles sont mises en œuvre
dans le diagramme d’états-transitions. On spéciﬁe toutes les opérations dans
le bloc principal du système sous test.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Dans l’exemple, il y a quatre opérations à représenter : Allumage ou
extinction des feux ou des phares. Ce sont les actions que l’utilisateur va
pouvoir eﬀectuer en actionnant le commodo. Elles sont représentées sur la
ﬁgure 5.
Figure 5 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Opérations des blocs SysML4MBT.
3.4
Les associations
Aﬁn de relier les blocs entre eux, on utilise des associations. Une association doit porter plusieurs informations :
– un nom : permettant de l’identiﬁer,
– deux noms de rôles : permettant d’identiﬁer chacun des acteurs (chacune des extrémités),
– deux multiplicités : une multiplicité sur une extrémité donnée indique,
pour une instance du bloc opposé, le nombre de liens possibles avec
des blocs de l’extrémité concernée.
Une multiplicité est un intervalle entre deux nombres indiquant toutes
les valeurs possibles, le sigle “*” représentant l’inﬁni. Une multiplicité s’écrit
sous la forme : PlusPetitNombre..PlusGrandNombre (exemple : 0..1). Par
convention, la multiplicité “0..*” s’écrit “*” et la multiplicité “n..n” s’écrit
“n” (où n est un entier supérieur à 0).
19
VETESS - Livrable n˚1.1
Il existe plusieurs types de liens. Dans le cadre du projet VETESS, nous
ne prenons en compte que l’association standard et la composition. L’association standard représente un lien quelconque, un simple rapport entre des
éléments. La composition quand à elle, va représenter une imbrication, le fait
qu’un élément se découpe en plusieurs composants. La ﬁgure 6 montre la
représentation graphique d’une association et d’une composition. Sur cette
ﬁgure un bloc A est composé de 4 ou 5 bloc B.
Figure 6 – Associations du diagramme de blocs SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Au niveau du modèle SysML4MBT qui spéciﬁe l’exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠,
se trouve un élément central (FrontLightingsSystem) représentant le système. Cet élément est composé d’un commodo (Controller) et de 4 feux
(feux de croisement gauche, feux de croisement droit, phare gauche et phare
droit). On va ainsi représenter ces liens d’imbrications à l’aide de compositions. La ﬁgure 7 représente la modélisation de ces liens.
Figure 7 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme de blocs SysML4MBT.
20
Prototype d’outil de modélisation graphique SysML
3.5
Les signaux
Un signal représente une transmission de données entre deux objets. Il
se distingue de l’opération car il est asynchrone. De plus, il n’a pas la même
signiﬁcation. Un signal représente un stimulus alors que l’opération représente plus un service proposé par un bloc. On spéciﬁe les signaux dans le
diagramme de blocs mais ils seront vraiment mis en œuvre dans les diagrammes internes et d’états-transitions.
Un signal se représente dans un diagramme de bloc comme sur la ﬁgure 8.
Figure 8 – Signal du diagramme de blocs SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Dans notre exemple SysML4MBT, il faut représenter les envois de signaux qui permettent aux diﬀérents éléments de communiquer. Ainsi, lorsque
le comodo est actionné par l’utilisateur (appel d’une opération), des signaux
sont envoyés du comodo vers les feux de manière à les activer réellement.
Dans notre exemple il y a 4 signaux qui sont :
– Allumage des feux : OnHighLightsSignal
– Extinction des feux : OﬀHighLightsSignal
– Allumage des phares : OnHeadLightsSignal
– Extinction des phares : OﬀHeadLightsSignal
Ces signaux sont représentés sur la ﬁgure 9.
Figure 9 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Signaux SysML4MBT.
21
VETESS - Livrable n˚1.1
3.6
Les spéciﬁcations de ﬂux
Les “spéciﬁcations de ﬂux” sont des interfaces qui regroupent plusieurs
signaux. Ainsi, un élément qui a comme type une “spéciﬁcation de ﬂux” peut
prendre comme valeur n’importe quel signal de la spéciﬁcation en question.
Sur la ﬁgure 10, la spéciﬁcation de ﬂux représente un type qui vaut soit
signal1, soit signal2.
Figure 10 – Spéciﬁcation de ﬂux du diagramme de blocs SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
On a besoin de spéciﬁcations de ﬂux dans notre exemple car il faut regrouper les signaux propres aux feux de croisement et les signaux propres aux
phares. En eﬀet, lorsque le comodo devra envoyer un signal aux phares par
exemple, ce sera soit le signal d’allumage des phares, soit le signal d’extinction des phares. Ainsi, on regroupe ces deux signaux de manière à pouvoir
indiquer que le ﬂux du commodo vers les phares se fera à travers l’un ou
l’autre de ces signaux. Ces deux spéciﬁcations sont représentées sur la ﬁgure
11.
Figure 11 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Spéciﬁcation des ﬂux SysML4MBT.
3.7
Les ports
Les ports précisent les points de communication d’un bloc. On les déﬁnit
au niveau du diagramme de blocs sans les représenter graphiquement. Un
port porte un nom et un type (booléen, entier, énumération, signal ou une
spéciﬁcation de ﬂux).
22
Prototype d’outil de modélisation graphique SysML
Il existe deux types de ports : Le port standard et le port de ﬂux. Un
port standard représente un service proposé par le bloc alors qu’un port de
ﬂux représente un échange de matière, d’énergie ou d’informations. De plus,
au niveau d’un port de ﬂux, on précise le sens de l’échange (in, out ou les
deux).
On utilise deux types de ports de ﬂux :
– Le port de ﬂux atomique (typé par un booléen, un entier, une énumération ou un signal)
– Le port de ﬂux non-atomique (typé par une spéciﬁcation de ﬂux)
On choisira d’utiliser un type de port plutôt que l’autre en fonction du
contexte.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
On précise les ports par lesquels les signaux vont être transmis. Il y a donc
deux ports qui partent depuis le bloc controller (un port vers les phares et un
vers les feux). Il y a ensuite un port (de réception) pour chaque feu/phares.
Il faut ensuite typer ces ports. Pour cela, on utilise les spéciﬁcations de ﬂux
mises en place précédemment. On utilise alors des ports de ﬂux car il s’agit
de la transmission d’un signal (probablement) électrique et dirigé. Les ports
déﬁnis sont les suivants :
– Bloc Controller
– outActionHigh : HighSpec
– outActionHead : HeadSpec
– Bloc LeftHighLight
– inActionLeftHigh : HighSpec
– Bloc RightHighLight
– inActionRightHigh : HighSpec
– Bloc LeftHeadLight
– inActionLeftHead : HeadSpec
– Bloc RightHeadLight
– inActionRightHead : HeadSpec
4
Diagramme interne de blocs SysML4MBT
Aﬁn de préciser la représentation statique du système, on utilise les diagrammes internes de blocs. Ce type de diagramme permet de représenter
l’intérieur du système au niveau des communications et des envois de signaux. Un diagramme interne est attaché à un bloc. Le premier diagramme
interne représenté est celui du bloc principal (soit le bloc représentant le
système). On peut aussi, si nécessaire, représenter l’intérieur des blocs secondaires.
23
VETESS - Livrable n˚1.1
4.1
Les propriétés
Les principaux éléments d’un diagramme interne de blocs sont les propriétés (ﬁgure 12). Une propriété dans le diagramme interne d’un bloc donné
peut représenter :
– une propriété du bloc en question
– un autre bloc qui compose le bloc en question (dans ce cas, par convention, on lui donnera son nom de rôle dans la composition)
Dans ce deuxième cas, on peut représenter des propriétés à l’intérieur de
cette propriété pour représenter un niveau supérieur. Chaque propriété a
également un type qui correspond a l’élément qu’elle représente.
Figure 12 – Propriété du diagramme interne de blocs SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
On considère que dans le cas de la gestion des feux, un seul diagramme
interne est nécessaire. En eﬀet, il n’est pas utile de représenter l’intérieur
du bloc controller ou des blocs des feux/phares. On a dans le diagramme
interne du bloc “FrontLightingsSystem” cinq propriétés :
– une qui représente le controller (commodo)
– deux pour les feux (1 pour le droit (rightHighLight) et 1 pour le gauche
(leftHighLight))
– deux pour les phares (1 pour le droit (rightHeadLight) et 1 pour le
gauche (leftHeadLight))
4.2
Les ports
Dans le diagramme interne de blocs, on représente également les ports
qui sont présents dans le diagramme de blocs. Les ports du bloc dont on
est en train de représenter l’intérieur, sont représentés sur les parois du
diagramme interne. En revanche, les ports des blocs représentés sous forme
de propriétés sont placés sur les parois des propriétés.
La ﬁgure 13 représente les modélisations des ports standards et de ﬂux
(atomique et non-atomique).
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
On représente donc les ports que l’on a mis en place dans le diagramme
de blocs. On obtient la ﬁgure 14.
24
Prototype d’outil de modélisation graphique SysML
Figure 13 – Types de port de SysML4MBT.
Figure 14 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme interne SysML4MBT (propriétés).
4.3
Les connecteurs
Les connecteurs représentent les chemins de communication entre les
éléments. Lorsqu’un connecteur relie deux ports de ﬂux, il représente un
échange (de données ou d’énergie ou de matière. . .) et quand il relie deux
ports standards, il représente l’appel à un service proposé.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Dans cet exemple, le port du controller dédié aux feux de croisement
(outActionHigh) est relié aux ports des feux de croisement et le port dédié
aux phares (outActionHead) est relié aux ports des phares. Le résultat est
présenté sur la ﬁgure 15.
Figure 15 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme interne SysML4MBT.
25
VETESS - Livrable n˚1.1
5
Diagramme d’états-transitions SysML4MBT
Le diagramme d’états transitions représente la vue dynamique du système. On représente un diagramme d’états transitions par sous-bloc. Les
composantes du système (c’est-à-dire les diﬀérents diagrammes d’états transitions) évoluent en parallèle. Au niveau du code OCL contenu dans un
diagramme d’états transitions, le contexte sera le bloc correspondant à ce
diagramme.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Dans notre exemple, il y a cinq parties :
– Le controller
– Le feux de croisement gauche
– Le feux de croisement droit
– Le phare gauche
– Le phare droit
On représente donc cinq diagrammes d’états transitions, un pour chaque
partie.
5.1
Les états
Les types d’états pris en compte sont représentés sur la ﬁgure 16. Il y a :
– État simple : représente un état du système, une conﬁguration des
variables du système ou encore le statut du système.
– Super-état (ou état composite) : il s’agit de regroupements d’états.
– État ﬁnal : c’est un point de sortie du système. Il peut éventuellement
y en avoir plusieurs.
Figure 16 – États du diagramme d’états SysML4MBT.
26
Prototype d’outil de modélisation graphique SysML
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Diagramme d’états-transitions du controller
Pour la vue dynamique du controller, on a 4 états ainsi qu’un état initial.
Ces 4 états sont les états déﬁnis dans l’introduction, à savoir :
– feux de croisement et phares éteints, (NoLight)
– feux de croisement allumés et phares éteints, (HighLightsOnly)
– feux de croisement éteints et phares allumés, (HeadLightsOnly)
– feux de croisement et phares allumés. (AllLights)
Il s’agit des diﬀérents états dans lesquels peut se retrouver le comodo. Ils
sont représentés sur la ﬁgure 17.
Figure 17 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : États du diagramme d’états SysML4MBT.
Diagramme d’états-transitions des feux
Les feux (HighLights) n’ont que deux états possibles : soit ils sont allumés, soit ils sont éteints. Ainsi, dans ces diagrammes-ci, il n’y a que deux
états intitulés :
– onHead
– oﬀHead
Diagramme d’états-transitions des phares
Au niveau des phares (HeadLights), le fonctionnement est le même.
Ainsi, il y a également dans ces diagrammes deux états intitulés :
– onHigh
– oﬀHigh
5.2
Les pseudo-états
Les pseudos-états sont des états temporaires c’est-à-dire que le système
ne sera pas amené à y rester. Il s’agit d’états transitoires. Les pseudos-états
pris en compte sont : l’état initial, le point de décision, la barre de fraction,
la barre de jonction et l’état historique.
5.2.1
État initial
L’état initial est un point d’entrée dans le système. Chaque diagramme
d’états transitions en contient un. Une seule transition doit partir de l’état
initial. Lorsque que l’on est sur un état initial, on traverse directement la
transition pour se retrouver dans un état stable. Chaque état composite doit
27
VETESS - Livrable n˚1.1
également contenir un état initial. Ainsi, lorsque l’on arrivera sur la paroi
d’un état composite, on arrivera dans son état initial. On représente un état
initial à l’aide d’un point noir.
5.2.2
Point de décision
Le point de décision est la modélisation du IF. . .THEN. . .ELSE au niveau
des transitions. Une transition arrive sur un point de décision (ou point de
choix) et plusieurs transitions en repartent. La transition qui arrive sur un
point de choix est une transition quelconque. Par contre les transitions qui
repartent du point de choix ne doivent pas porter de déclencheur (cf. partie
suivante). Chacune d’entre elles doit par contre porter une garde. Il est
également possible de déﬁnir une garde “else” qui sera utilisée si aucune des
autres transitions ne peut être activée. Une fois positionné sur le point de
décision, plusieurs cas sont possibles :
– Une seule garde est respectée : la transition correspondante est exécutée.
– Plusieurs gardes sont respectées : une transition parmi celles correspondantes est exécutée. Le choix se fait de façon arbitraire.
– Aucune garde n’est respectée :
– une transition avec la garde “else” est présente : cette transition est
exécutée.
– il n’y a pas de transition avec la garde “else” : le modèle contient
une erreur.
La représentation se fait comme sur la ﬁgure 18. Sur cet exemple, si on
se trouve dans l’état 1 et que l’événement “Evt()” est appelé, on va alors
passer sur le point de décision. Il y a alors deux cas :
– Si l’expression “guard” est respectée, on exécute l’expression “act” et
on passe dans l’état 2.
– Sinon, on exécute l’expression “actSinon” et on passe dans l’état 3.
Figure 18 – Point de décision du diagramme d’états SysML4MBT.
28
Prototype d’outil de modélisation graphique SysML
5.2.3
Barre de fraction et barre de jonction
Les barres de fraction et de jonction permettent de mettre en place une
parallélisation de transitions. Le fonctionnement est le suivant : une transition arrive sur une barre de fraction et plusieurs transitions en partent.
Les transitions qui partent de cette barre sont des chemins d’exécution qui
se réalisent en parallèle. Chacun de ces chemins évolue à sa manière. Aﬁn
de fusionner tous ces chemins (de manière à interrompre le parallélisme),
on utilise une barre de jonction. Tous les chemins d’exécution (ou simplement quelques uns) pointent sur cette barre, chacun à l’aide d’une transition.
Une seule transition repart de cette barre. Pour que cette transition puisse
s’exécuter, il faut que toutes les transitions qui arrivent sur la barre aient
été franchies. Même si un des chemins arrive sur un état ﬁnal, les autres
continuent leurs exécutions.
La ﬁgure 19 représente un exemple d’utilisation de ces barres. Dans cette
exemple, lorsque la transition “Transition entrée” est exécutée on arrive sur
une barre de fraction. Ainsi, les transitions “1.1” et “2.1” sont exécutées
en même temps. A la ﬁn, pour que la transition “Transition sortie” puisse
s’exécuter, il faut que les transitions “1.2” et “2.2” aient été franchies.
Figure 19 – Barres de fraction et de jonction SysML4MBT.
5.2.4
État historique et état historique profond
L’état historique est un pseudo-état qui se place au sein d’un état composite. Cet état va permettre de retourner immédiatement à l’endroit de
l’état composite duquel on l’a quitté. Sa représentation est un “H” entouré.
Par exemple, sur la ﬁgure 20, on peut emprunter la transition “Tr2” depuis
l’état “State 1” ou depuis l’état “State 2”. Étant donné que la transition
“Tr2” arrive sur l’état historique, si on emprunte la transition “Tr2” depuis
l’état “State 1”, on retourne directement dans l’état “State 1” et sinon, on
retourne directement dans l’état “State 2”.
Figure 20 – État historique SysML4MBT.
29
VETESS - Livrable n˚1.1
L’état historique permet de retourner dans le dernier état visité de son
niveau d’imbrication. Dans le cas d’états composites imbriqués, seul l’état
historique profond permet de retourner dans le dernier état visité quelque
soit son niveau d’imbrication. Sa représentation est un “H*” entouré.
5.3
Les transitions
Les transitions relient les états entre eux. La représentation graphique
est une ﬂèche simple. Dans notre cas, une transition peut :
– relier simplement deux états,
– être réﬂexive (l’état de départ est le même que celui d’arrivée),
– être interne (on ne réalise pas de changement d’état),
– arriver sur un super-état (dans ce cas, on arrive dans l’état initial du
super-état),
– partir d’un super-état (dans ce cas, la transition sera actionnable depuis n’importe quel état du super-état),
mais ne peut pas relier deux états qui ne sont pas dans le même superétat (transition trans-hiérarchique). Graphiquement, une transition ne peut
donc pas traverser la bordure d’un super état. Une transition représente l’intégralité du changement d’état. Une transition contient trois “paramètres”.
5.3.1
Déclencheur
Le déclencheur précise un évènement qui, lorsqu’il se produit, permet
de franchir la transition. Les déclencheurs sont des événements qui peuvent
être des réceptions d’opérations ou des réceptions de signaux. On précise le
port à travers lequel cet événement arrive.
5.3.2
Garde
La garde est une expression booléenne qui, si elle n’est pas respectée,
bien que le déclencheur ait été activé, empêchera l’exécution de la transition.
Cette garde s’écrit en OCL.
5.3.3
Eﬀet
Enﬁn, l’eﬀet d’une transition est une expression OCL [WK96] représentant une post-condition qui sera valide si le déclencheur est activé et que la
garde est respectée. Il est possible d’envoyer un signal au moment de l’eﬀet
de la transition. Pour se faire on utilise le sigle “ˆ ”. Son fonctionnement est
le suivant :
Bloc.Portˆ SignalEnvoyé()
où “Bloc” représente le bloc vers lequel on envoie le signal, “Port” représente
le port du bloc vers lequel on envoie le signal et “SignalEnvoyé” le nom du
signal (déﬁni dans le diagramme de blocs) que l’on envoie.
30
Prototype d’outil de modélisation graphique SysML
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Diagramme d’états-transitions du controller
Au niveau de ce diagramme, ce sont les opérations qui vont servir de déclencheurs (appels d’opérations par l’utilisateur en actionnant le comodo).
Toutes les opérations ne sont pas activables depuis n’importe quel état. Par
exemple, on ne peut pas appeler l’opération SwitchOnHeadLights si on est
dans un état où les phares sont déjà allumés. De chaque état, il y a logiquement deux départs de transitions. En eﬀet, depuis un état donné, soit
on change la situation (allumés ou éteints) des feux de croisement, soit on
change la situation (allumés ou éteints) des phares. La ﬁgure 21 montre le
diagramme d’états-transitions du controller avec les transitions.
Figure 21 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme d’états SysML4MBT.
Ensuite, on ajoute les eﬀets des transitions. Lorsqu’une opération est appelée, il faut réaliser un envoi de signal vers les feux/phares aﬁn que la modiﬁcation soit eﬀective. On ajoute donc dans chaque transition, la nécessité
de l’envoi d’un signal vers les feux/phares correspondants pour eﬀectuer le
changement d’états dans les autres diagrammes d’états transitions. De plus,
une fois la transition franchie, les propriétés du bloc “Controller”auront été
modiﬁées. Le résultat est représenté sur la ﬁgure 22.
31
VETESS - Livrable n˚1.1
Figure 22 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique du controller.
32
Prototype d’outil de modélisation graphique SysML
Diagramme d’états-transitions des feux de croisement
Les feux de croisements n’ont que deux états possibles : éteints ou allumés. Ainsi, il n’y a que deux transitions possibles :
– une pour passer de éteints à allumés,
– une pour passer de allumés à éteints.
Les déclencheurs doivent être en accord avec la structure mise en place
dans les diﬀérents diagrammes. Ainsi, par exemple, le passage de onHigh à
oﬀHigh se fera par la réception du signal oﬀHighLightsSignal à travers le
port inAction(Left/Right)High comme il a été déﬁni dans le diagramme de
bloc.
Le déclencheur de chaque transition est l’événement de réception de signal (dans notre exemple provenant du controller) correspondant. La ﬁgure 23 présente le diagramme d’états-transitions des feux de croisement.
L’aspect est le même pour les feux de croisements droits et gauches. La différence se situe dans le code OCL dans lequel on spéciﬁe le port de réception
du signal.
Figure 23 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique HighLight.
Diagramme d’états-transitions des phares
Le raisonnement pour les phares et le même que pour les feux. Le résultat
est représenté sur la ﬁgure 24.
Figure 24 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Modélisation dynamique HeadLight.
33
VETESS - Livrable n˚1.1
5.4
Les actions onEntry/onExit
Les actions onEntry et onExit sont exprimées par des contraintes OCL
qui sont attachées à un état donné. L’action onEntry (resp. onExit) est exécutée lorsqu’une transition arrive (resp. quitte) l’état donné. Les transitions
internes n’activent pas ces actions à la diﬀérence des transitions réﬂexives.
En eﬀet, une transition réﬂexive quitte l’état puis y revient.
6
6.1
Diagramme d’exigences SysML4MBT
Les exigences
Les exigences présentes dans le cahier des charges se modélisent à l’aide
d’un diagramme d’exigences. Chaque exigence porte un descriptif et un identiﬁant. Il est possible de mettre en place une hiérarchie. En eﬀet, une exigence
peut parfois se découper en plusieurs sous-exigences. Dans ce cas, on utilise
des liens intitulés “containment”. La ﬁgure 25 représente ce lien. La signiﬁcation est, pour cet exemple, que l’exigence 1 est en fait l’union de l’exigence
2 et de l’exigence 3. Ainsi, pour satisfaire l’exigence 1, il faut que les deux
autres soient satisfaites.
Figure 25 – Diagramme d’exigences SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Considérons la seule exigence selon laquelle l’allumage et l’extinction
des phares/feux doit se réaliser réellement si l’opération a été appelée. On
représente donc une exigence qui décrit cette volonté (identiﬁant REQ). On
peut ensuite découper cette exigence en deux sous-exigences :
– que l’allumage des feux/phares se fasse eﬀectivement (id = REQon)
– que l’extinction des feux/phares se fasse eﬀectivement (id = REQoﬀ)
On peut également découper ses exigences en faisant la distinction des
feux et des phares. On obtient le diagramme de la ﬁgure 26.
34
Prototype d’outil de modélisation graphique SysML
Figure 26 – 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠 : Diagramme d’exigences.
6.2
La traçabilité des exigences
Pour indiquer ce qui satisfait une exigence, on peut la relier aux éléments
de modèles suivants :
Diagramme de blocs :
– Bloc
– Signal
– Spéciﬁcation de ﬂux
– Propriété de spéciﬁcation de ﬂux
– Énumération
– Littéral d’énumération
– Propriété d’un bloc
– Port d’un bloc
Diagramme interne de blocs :
– Propriétés
– Ports de propriétés
– Connecteurs
Diagramme d’états-transitions :
– Machine complète
– État
– État composite
– Toutes transitions
– Déclencheur d’une transition
– Garde d’une transition
– Eﬀet d’une transition
35
VETESS - Livrable n˚1.1
Pour indiquer qu’un élément de modèle satisfait une exigence, on utilise le lien “satisfy”. Par exemple, la ﬁgure 27 représente le fait que le bloc
“BLOC” satisfait l’exigence “REQ”.
Figure 27 – Lien satisfy simple SysML4MBT.
Si plusieurs éléments de modèles permettent de satisfaire une exigence
indépendamment les uns des autres, on met en place plusieurs liens satify en
parallèle. Par exemple, la ﬁgure 28 représente le fait que pour que l’exigence
“REQ” soit satisfaite, on a besoin de l’élément “TRANSITION 1” ou alors
de l’élément “TRANSITION 2” . Une seule transition parmis les deux suﬃt
à valider l’exigence REQ.
Figure 28 – Liens satisfy parallèles SysML4MBT.
Si par contre, un ensemble d’éléments coordonnés est nécessaire pour
valider une exigence, c’est à dire que plusieurs éléments sont nécessaires en
même temps, on utilise le lien “Dependency”. On représente un seul lien
satisfy. Ce lien relie l’exigence à un des éléments nécessaire et ce dernier
est relié aux autres éléments. Ainsi, par exemple, sur la ﬁgure 29, pour que
l’exigence “REQ” soit satisfaite, on a besoin de la “TRANSITION 1” et
de la “TRANSITION 2”. Cette représentation est équivalente à celle de la
ﬁgure 30.
36
Prototype d’outil de modélisation graphique SysML
Figure 29 – Liens satisfy multiples SysML4MBT.
Figure 30 – Équivalence des liens satisfy multiples SysML4MBT.
Exemple 𝐹 𝑟𝑜𝑛𝑡𝐿𝑖𝑔ℎ𝑡𝑖𝑛𝑔𝑠
Seules les 8 exigences de plus bas niveau sont reliées aux éléments des
modèles correspondants. Pour OnHighReq par exemple, les éléments qui satisfont l’exigence selon laquelle l’allumage des feux de croisement doit s’effectuer réellement si l’opération a été appelée, sont :
– la réaction du controller à la réception de l’opération d’allumage des
feux (SwitchOnHighLights).
– la réaction du bloc HighLight à la réception du signal envoyé pendant
l’autre transition (OnHighLightsSignal).
Les deux éléments qui satisfont cette exigence sont donc :
– La transition SwitchOnHighLights du diagramme d’états-transitions
du Controller.
– La transition OnHighLightsSignal du diagramme d’états-transitions
des HighLights.
Cependant, les deux éléments sont nécessaires. En eﬀet, c’est l’appel
successif de ces transitions qui valide cette exigence. Il faut donc utiliser les
liens “dependency” vu précedemment. Le raisonnement est le même pour les
autres exigences. La diagramme d’exigences complet est représenté sur la
ﬁgure 31.
37
VETESS - Livrable n˚1.1
Figure 31 – Diagramme d’exigences de l’exemple des feux.
38
Prototype d’outil de modélisation graphique SysML
6.3
Les Packages
Dans certains cas complexes, la présence de dépendances trop nombreuses peut engendrer une incapacité à réaliser un diagramme d’exigences
juste. Prenons l’exemple suivant :
– Exigence 1 : satisfaite par Blocs B1 ET B2
– Exigence 2 : satisfaite par Blocs B1 ET B3
On obtient ainsi le diagramme de la ﬁgure 32. Or, cette représentation
signiﬁe réellement que l’exigence 1 est satisfaite par les blocs B1 ET B2 ET
B3, et que l’exigence 2 est satisfaite par les blocs B1 ET B2 ET B3, ce qui
n’est pas vrai. Ainsi, pour préciser que le lien satisfy en rouge est associé
au lien dependency en vert et que le lien satisfy en bleu est associé au lien
dependency en noir, on utilise des packages. Ainsi, on met en place deux
packages : un qui regroupe le lien rouge et le lien vert et un autre package
qui regroupe le lien bleu avec le lien noir (voir ﬁgure 32).
Figure 32 – Exemple avancé de diagramme d’exigences SysML4MBT.
6.4
Les objectifs de test
Aﬁn de simpliﬁer la manipulation du modèle, il est possible d’utiliser
les balises AIMS. Il s’agit d’annotations placées dans le code OCL aﬁn de
déﬁnir les objectifs de tests et leurs signiﬁcations.
7
Modélisation SysML4MBT avec PAPYRUS
Dans le cadre du projet VETESS, la chaı̂ne outillée développée doit être
supportée par un logiciel de modélisation libre. Cette section présente des
modèles spéciﬁés à l’aide de l’outil de modélisation PAPYRUS [Pap08]. Les
modèles suivants ont ainsi été spéciﬁés avec le logiciel PAPYRUS en utilisant
le sous-ensemble SysML4MBT présenté dans ce document :
– les ﬁgures 33, 34, 35 illustrent la création de diagrammes de blocs,
– la ﬁgure 36 présente un diagramme interne de blocs,
– les ﬁgures 37 et 38 montrent des diagrammes états-transitions,
– enﬁn, la ﬁgure 39 présente un diagramme d’exigences.
39
VETESS - Livrable n˚1.1
Figure 33 – Diagramme de blocs réalisé avec PAPYRUS
40
Figure 34 – Enumérations (dans un diagramme de blocs) réalisées avec PAPYRUS
Prototype d’outil de modélisation graphique SysML
41
VETESS - Livrable n˚1.1
Figure 35 – Signaux et spéciﬁcations de ﬂux (dans un diagramme de blocs) réalisés avec PAPYRUS
42
Figure 36 – Diagramme interne de blocs réalisé avec PAPYRUS
Prototype d’outil de modélisation graphique SysML
43
VETESS - Livrable n˚1.1
Figure 37 – Diagramme états-transitions réalisé avec PAPYRUS
44
Figure 38 – Diagramme états-transitions réalisé avec PAPYRUS
Prototype d’outil de modélisation graphique SysML
45
VETESS - Livrable n˚1.1
Figure 39 – Diagramme d’exigences réalisé avec PAPYRUS
46
Prototype d’outil de modélisation graphique SysML
8
Récapitulatif du langage SysML4MBT
Cette partie dresse la liste des éléments SysML que l’on prend en compte
dans le sous-ensemble SysML4MBT. Chacun des tableaux suivants comporte
4 colonnes :
1. la colonne “Elément” donne les noms des éléments pris en compte dans
SysML4MBT.
2. la colonne “Description” explique brièvement à quoi servent ces éléments.
3. la colonne “UML4MBT” indique si les éléments sont présents dans la
restriction UML utilisée dans Test Designer𝑇 𝑀 (UML4MBT). “Couvert” si l’élément est présent dans UML4MBT ou “Non couvert” dans
le cas contraire. Si l’élément est également présent dans UML4MBT
mais qu’il n’a pas le même nom en UML et en SysML, le nom UML
est indiqué entre parenthèse.
4. la colonne “Page” indique à quelle page de ce document l’élément est
décrit.
8.1
Diagramme de blocs
Le tableau 1 récapitule les éléments du diagramme de blocs pris en
compte dans SysML4MBT. Les éléments internes aux blocs pris en compte
sont détaillés dans le tableau 2 et les types autorisés dans le tableau 3.
Elément
Bloc
Association
standard
Composition
Description
Représente une partie du
système modélisé
Relie les blocs entre eux
UML4MBT
Couvert
(Classe)
Couvert
Page
17
Relie les blocs entre eux avec une
signiﬁcation de composition
Couvert
19
19
Table 1 – SysML4MBT - Diagramme de Blocs - Eléments de base.
47
VETESS - Livrable n˚1.1
Element
Opération
Description
Représente l’action qui peut être
appelée par le bloc qui la contient
Variable qui caractérise
l’instance du bloc
Représente un service proposé
par le bloc
Représente un point de
communication
Propriété
Port
standard
Port de ﬂux
UML4MBT
Couvert
Page
19
Couvert
(attributs)
Non couvert
18
Non couvert
22
22
Table 2 – SysML4MBT - Diagramme de Blocs - Éléments d’un bloc.
Elément
Booléen
Entier
Enumération
Signal
Spéciﬁcation
de ﬂux
Description
Nombre booléen
Nombre entier
Liste de choix
Représente un stimulus
Ensemble de signaux
UML4MBT
Couvert
Couvert
Couvert
Non couvert
Non couvert
Page
18
18
18
21
22
Table 3 – SysML4MBT - Diagramme de Blocs - Types.
8.2
Diagramme interne de blocs
Le tableau 4 résume les éléments pris en compte dans SysML4MBT
au niveau du diagramme interne de blocs. Aucun de ceux-ci ne sont pris
en compte dans UML4MBT étant donné qu’il n’y a pas d’équivalent du
diagramme interne en UML.
Elément
Propriété
(propriété)
Propriété
(bloc)
Port
standard
Port de ﬂux
Connecteur
Description
Elément qui pointe sur la
propriété du bloc représenté
Elément qui pointe sur un bloc
qui compose le bloc représenté
Service proposé par un bloc
UML4MBT
Non couvert
Page
24
Non couvert
24
Non couvert
24
Point d’envoi/réception de
données
Liaison entre les ports
Non couvert
24
Non couvert
25
Table 4 – SysML4MBT - Diagramme interne.
48
Prototype d’outil de modélisation graphique SysML
8.3
Diagramme d’états-transitions
Au niveau de la représentation dynamique, le type de diagramme utilisé en SysML est le même qu’en UML : il s’agit du diagramme d’étatstransitions. Il y a cependant des éléments présents dans SysML4MBT qui
ne sont pas dans UML4MBT. C’est ce que présentent les tableaux 5 (au
niveau des états) et 6 (au niveau des transitions).
Element
Etat initial
Etat ﬁnal
Etat simple
Super-état
Point de
décision
Etat orthogonal
Barre de
fraction/
jonction
Etat
historique
Etat
historique
profond
Description
(Pseudo-état) Point d’entrée
dans le système
Point de sortie du système
Etat du système
Etat qui peut contenir d’autres
états
Pseudo-état représentant un
choix
Le fait que plusieurs états soient
actifs au même moment
Pseudo-état permettant de
représenter une exécution
parallèle
Permet de retourner directement
à l’endroit de l’état composite
d’ou on est parti
Permet de retourner directement
à l’endroit de l’état composite
d’ou on est parti quelque soit son
niveau d’imbrication
UML4MBT
Couvert
Page
27
Couvert
Couvert
Couvert
26
26
26
Couvert
28
Non couvert
26
Non couvert
29
Non couvert
29
Non couvert
29
Table 5 – SysML4MBT - Diagramme d’états-transitions - États.
49
VETESS - Livrable n˚1.1
Elément
Transition
Déclencheur
Port
événement
Garde
Eﬀet
Actions
onEntry
onExit
Envoi de
signal
Description
Lien entre deux états
Appel d’opération qui rend
possible le franchissement de la
transition
Précision du port par lequel
arrive le déclencheur quand
celui-ci est un signal
Expression booléenne qui valide
le passage de la transition
Action réalisée par la transition
Actions s’exécutant lorsqu’une
transition entre dans l’état ou le
quitte
Envoi d’un signal dans l’eﬀet
d’une transition
UML4MBT
Couvert
Couvert
Page
30
30
Non couvert
30
Couvert
30
Couvert
Couvert
30
34
Non couvert
30
Table 6 – SysML4MBT - Diagramme d’états-transitions - Transitions.
8.4
Diagramme d’exigences
Le diagramme d’exigences, tout comme le diagramme interne est un
diagramme qui n’existe pas en UML. Ainsi tous les éléments du diagramme
d’exigences pris en compte en SysML4MBT ne le sont pas en UML4MBT
(tableau 7).
Elément
Exigence
Hiérarchie
(Containment)
Eléments
de modèle
Satisfy
Package
Description
Exigence du cahier des charges
Hiérarchie entre les exigences
UML4MBT
Non couvert
Non couvert
Page
34
34
Liens sur des éléments de
modèles
Lien de satisfaction entre les
éléments de modèles et les
exigences
Permet de regrouper les liens
Non couvert
35
Non couvert
35
Non couvert
39
Table 7 – SysML4MBT - Diagramme d’exigences.
50
Prototype d’outil de modélisation graphique SysML
9
Synthèse
Nous avons déﬁni dans ce document le sous-ensemble SysML (baptisé
SysML4MBT) pris en compte par la chaı̂ne outillée du projet VETESS pour
spéciﬁer les modèles embarqués sous test. Ce sous-ensemble ne remet pas en
cause les concepts de la notation SysML et ne fait qu’identiﬁer un sousensemble de cette notation pertinent dans le contexte de la modélisation
comportementale pour la génération de cas de test fonctionnels.
L’ensemble des éléments de la notation SysML sélectionnés dans le sousensemble SysML4MBT a été illustré à travers un exemple jouet et sa mise
en œuvre a été réalisée avec l’outil de modélisation PAPYRUS.
La déﬁnition du langage SysML4MBT doit maintenant donner lieu à une
phase de formalisation en terme de métamodélisation (cf. livrable L2.1 du
projet) et une phase de développement aﬁn de garantir le traitement automatique de tels modèles par la chaı̂ne outillée (cf. livrable L2.2 du projet).
51
VETESS - Livrable n˚1.1
Références
[Abr96]
J-R. Abrial. The B-BOOK : Assigning Programs to Meanings.
Cambridge University Press, 1996. ISBN 0 521 49619 5.
[BG92]
G. Berry and G. Gonthier. The esterel synchronous programming language : Design, semantics, implementation. Science of
Computer Programming, 19(2) :87–152, November 1992.
[BGLP08] F. Bouquet, C. Grandpierre, B. Legeard, and F. Peureux. A test
generation solution to automate software testing. In Proceedings
of the 3𝑟𝑑 International Workshop on Automation of Software
Test (AST’08), pages 45–48, Leipzig, Germany, May 2008. ACM
Press.
[Boo93]
G. Booch. Object-Oriented Analysis and Design With Applications. Benjamin/Cummings Publishing Company, 2𝑛𝑑 edition,
1993. ISBN 0 80 535340 2.
[CE81]
E.M. Clarke and E.A. Emerson. Design and synthesis of synchronization skeletons using branching-time temporal logic. In
Proceedings of Workshop on Logic of Programs, volume 131 of
LNCS, pages 52–71, Yorktown Heights, NY, USA, May 1981.
Springer Verlag.
[CJRZ02] D. Clarke, T. Jéron, V. Rusu, and E. Zinovieva. STG : a Symbolic
Test Generation Tool. In Proceedings of the ETAPS’02 International Conference on Tools and Algorithms for the Construction
and Analysis of Systems (TACAS’02), volume 2280 of LNCS,
Grenoble, France, April 2002. Springer Verlag.
[CK93]
Kwang-Ting Cheng and A.S. Krishnakumar. Automatic functional test generation using the extended ﬁnite state machine
model. In Proceedings of the 30𝑡ℎ International Design Automation Conference (DAC’93), pages 86–91, Dallas, Texas, USA,
June 1993. ACM Press.
[CPHP87] P. Caspi, D. Pilaud, Halbwachs, and J. A. Plaice. LUSTRE :
a declarative language for real-time programming. In Proceedings of the 14𝑡ℎ Symposium on Principles of programming Languages (POPL’87), pages 178–188, Munich, Germany, January
1987. ACM Press.
[CSE96]
J. Callahan, F. Schneider, and S. Easterbrook. Automated software testing using modelchecking. In Proceedings of the SPIN
International Workshop, Rutgers University, USA, August 1996.
[FGJM95] K. Futatsugi, J.A. Goguen, J.P. Jouannaud, and J. Meseguer.
Principles of OBJ2. In Proceedings of the 12𝑡ℎ Symposium on
Principles of programming Languages (POPL’95), pages 52–66,
New Orleans, USA, January 1995. ACM Press.
52
Prototype d’outil de modélisation graphique SysML
[FJJV97] J-C. Fernandez, C. Jard, T. Jéron, and G. Viho. An Experiment
in Automatic Generation of Test Suites for Protocols with Veriﬁcation Technology. Journal of Science of Computer Programming, 29(1-2) :123–146, 1997. INRIA Technical Report 2923.
[GH93]
J. Guttag and J. Horning. Larch : languages and tools for formal
speciﬁcation. Springer Verlag, 1993. ISBN 0 387 94006 5.
[Har98]
D. Harel. Modeling Reactive Systems With Statecharts. Mac
Graw Hill, 1998. ISBN 0 070 26205 5.
[Hoa78]
C.A.R. Hoare. Communicating sequential processes. Communications of the ACM, 21 :666–677, 1978.
[Hol91]
G. Holzmann. Design and validation of protocols. Prentice-Hall
Software Series, 1991.
[Hol97]
G.J. Holzmann. The model checker SPIN. IEEE Transactions
on Software Engineering, 23(5) :279–295, 1997.
[ISO]
ISO. ISO 8807 : Information processing systems - open systems
interconnection - LOTOS - a formal description technique based
on the temporal ordering of observational behaviour, 1989.
[IT]
ITU-T. ITU-T. Formal description techniques (fdt) - speciﬁcation
and description language (sdl), 2002.
[Jac92]
I. Jacobson. Object Oriented Software Engineering : A Use Case
Driven Approach. Addison-Wesley, 1992. ISBN 0 20 154435 0.
[JM99]
T. Jéron and P. Morel. Test generation derived from modelchecking. In Proceedings of the 11𝑡ℎ International Conference on
Computer Aided Veriﬁcation (CAV’99), volume 1633 of LNCS,
pages 108–121, Trento, Italy, July 1999. Springer Verlag.
[Jon90]
C.B. Jones. Systematic Software Development Using VDM.
Prentice-Hall, 2𝑛𝑑 edition, 1990.
[Mey97]
B. Meyer. Object-Oriented Software Construction. Prentice-Hall
PTR, 2𝑛𝑑 edition, 1997. ISBN 0 13 629155 4.
[MG03]
P-A. Müller and N. Gaertner. Modélisation objet avec UML.
Eyrolles, 2𝑡ℎ edition, 2003. ISBN 2 212 11397 8.
[Mil82]
R. Milner. A Calculus of Communicating Systems. Springer
Verlag, 1982. ISBN 0 387 10235 3.
[Mil99]
R. Milner. Communicating and Mobile Processes : the 𝜋-calculus.
Cambridge University Press, 1999. ISBN 0 521 65869 1.
[MSBT04] G.J. Myers, C. Sandler, T. Badgett, and T.M. Thomas. The Art
of Software Testing. Wiley, 2𝑡ℎ edition, 2004. ISBN 978 0 471
46912 4.
[Pap08]
The Papyrus UML Editor home page. http://www.papyrusuml.
org, 2008.
53
VETESS - Livrable n˚1.1
[QS82]
J-P. Queille and J. Sifakis. Speciﬁcation and veriﬁcation of
concurrent systems in CESAR. In Proceedings of the 5𝑡ℎ International Symposium on Programming, volume 137 of LNCS,
pages 337–351, Torino, Italy, April 1982. Springer Verlag.
[RBP+ 90] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object Modeling Technique. Prentice-Hall, 1990. ISBN 0
13 629841 9.
[RJB99]
J. Rumbaugh, I. Jacobson, and G. Booch. The Uniﬁed Modeling
Language Reference Manual. Addison-Wesley, 1999.
[RJB04]
J. Rumbaugh, I. Jacobson, and G. Booch. The Uniﬁed Modeling
Language Reference Manual. Addison-Wesley, 2𝑡ℎ edition, 2004.
ISBN 0 321 24562 8.
[Sma09]
The Smartesting web site. http://www.smartesting.com, 2009.
[Spi92]
J.M. Spivey. The Z notation : A Reference Manual. PrenticeHall, 2𝑛𝑑 edition, 1992. ISBN 0 13 978529 9.
[Tre08]
J. Tretmans. Model-Based Testing with Labelled Transition Systems. In Formal Methods and Testing, volume 4949 of LNCS,
pages 1–38. Springer Verlag, 2008.
[UL06]
M. Utting and B. Legeard. Practical Model-Based Testing - A
tools approach. Elsevier Science, 2006. ISBN 0 12 372501 1.
[WK96]
J. Warmer and A. Kleppe. The Object Constraint Language :
Precise Modeling with UML. Addison-Wesley, 1996. ISBN 0 201
37940 6.
54
Résumé
Ce document a pour but de déﬁnir l’ensemble des éléments de modélisation SysML pris
en compte pour mettre en œuvre les techniques de génération de tests à partir de modèles
développées dans le cadre du projet VETESS.
Le sous-ensemble de la notation SysML sélectionné, baptisé SysML4MBT, comporte les
quatre diagrammes SysML suivants : le diagramme de blocs, le diagramme interne de blocs,
le diagramme d’états-transitions (annoté de contraintes OCL) et le diagramme d’exigences.
Le pouvoir d’expression mis en place sur chacun de ces diagrammes est explicité et est illustré
à travers un exemple jouet spéciﬁé avec l’outil de modélisation PAPYRUS.
http://lifc.univ-fcomte.fr/vetess/

Prototype d`outil de modélisation graphique d`ingénierie syst

Documents connexes

Produits

Soutien

Prototype d`outil de modélisation graphique d`ingénierie syst

Documents connexes

Ajouter ce document à la (aux) collections

Ajouter ce document à enregistré

Suggérez-nous comment améliorer StudyLib