Validation de conceptions UML de logiciels embarqués : emprunts aux approches formelles

Download Report

Transcript Validation de conceptions UML de logiciels embarqués : emprunts aux approches formelles

Validation de conceptions UML de
logiciels embarqués :
emprunts aux approches formelles
Alain Le Guennec
Jean-Marc Jézéquel
Action Triskell
[email protected] -- http://www.irisa.fr/triskell
UML : l’évolution en cours
• Popularité croissante dans l’industrie
– Support du développement OO pour A&D
– Standard OMG, grand choix d’outils
• Interopérabilité à terme, via le format XMI
• Efforts soutenus de formalisation
– Groupes pUML et « Action-Semantics »
• Convergence des formalismes SDL et UML
– SDL’2000, « profile » UML-RT
L’approche Triskell
• Construction fiable et efficace
d’applications « télécom » par composants
• Permettre l’utilisation de techniques
formelles avec UML
– Model checker basé sur la logique XTL
– Simulation interactive ou intensive
– Génération de tests (outil TGV)
• Si tu ne vas pas à Lagardère…
Dans les objectifs de Triskell
• Donner une (famille de) sémantique à UML
– préciser l’existant
– agir au sein de l ’OMG sur le futur :
• Action Semantics, UML-RT
• Adapter des techniques formelles existantes
– Identifier les problèmes spécifiques à UML
• Prouver la faisabilité avec un prototype
– UMLAUT
Intégration de la validation
dans un cycle de vie OO
Schéma d’utilisation
Validation Results
Simulation
Problem
Model Checking
Validation code
UML Analysis Model
UML Design Model
Validation Framework
UMLAUT/Simulator
Implementation
Test Cases
Test Results
TGV Graph API
Test purpose
Le simulateur UMLAUT
• Compilation de la spécification
– Objectif : « tisser » entre eux les différents aspects
sémantiques d’un modèle UML en les projetant
sur le sous-ensemble {statique + AS}
• Stockage et comparaison d’états
– Etat local pour chaque objet
– Topologie du réseau d’objets
– Autorise la création dynamique d’objets
Cohérence entre diagrammes :
Implémentation d’une opération
ma(b)
a:A
b:B
c:C
H
b:B
ma
mb()
return c
mc()
This association has a parameter as one of its association-end.
But how exactly does the association-end relate to
the corresponding formal parameter of the represented operation?
Is it just by name matching, or is a meta-association missing somewhere?
c:C
call to mc()
1:mb()
b:B
a:A
2:return c
This ObjectFlowState stands for the formal parameter
'b' of the represented operation.
The "parameter" meta-association of this
ObjectFlowState hence points to the parameter 'b'.
call to mb()
<<parameter>>
This ObjectFlowState is the result of the call to mb().
Hence its "parameter" meta-association points to
the 'result' parameter of the mb operation.
It subsequently serves as the target for the call to mc().
H
3:mc()
c:C
c
This association is a consequence of
the dataflow coming as a result of the call to mb().
But what kind of association is this?
It is neither <<global>>, <<parameter>> nor <<local>>.
Is it derived from the other two associations?
ma(b:B) / (b->mb())->mc();
A in S1
A in S2
Sémantique des diagrammes d’état
• La notion de classe-état permet
d’intégrer la notion d’état au typage
• L’effet d’une transition associe
des actions aux opérations
Sémantique dynamique (1)
• Sémantique de la concurrence : entrelacements
– fondée sur les Labelled Transition Systems
• Evolutions du système -> transitions du LTS
• Evolutions dues aux actions exécutées
– spontanément par les objets actifs dans le système
– en réponse aux stimuli provenant de
l’environnement
Sémantique dynamique (2)
• Evolutions du système spécifiées à l’aide d’un
langage d’actions
– pas encore de standard (« Action Semantics » WG)
– remplacé par des fragments de programmes
• nécessite des hypothèses sur l’atomicité
– ceci permet de transposer sans les analyser
les fragments de code représentant des actions
directement depuis le domaine syntaxique vers le
domaine sémantique
Vérification de propriétés
• Cas des assertions OCL classiques
– Les pré et post-conditions des routines
ainsi que les invariants de classes
sont compilés en transitions spéciales
• Cas des propriétés exprimées à l’aide
d’une logique temporelle
– XTL est trop éloignée de UML/OCL
– Les propositions portant sur les états
devraient pouvoir être écrites en OCL
Génération de tests
• Repose sur le produit synchrone entre la
spécification et un automate objectif de test
– Un objectif de test permet de construire des cas de
test en guidant l’exploration de la spécification selon
certains critères
• Objectifs et cas de test sont représentés en UML
par des collaborations / interactions
• Limitation : données traitées par énumération...
Objectifs de test
• D’un Use-Case UML au IO/LTS pour TGV
Cas de test
UMLAUT
Simulateur
TGV
UMLAUT
Editeur d’objectifs
La boîte à outils UMLAUT
Semi-automatic or manual
UML/AS
UML metamodel
Commercial tool
Commercial tool
GUI (Applet)
Outil...
commercial
1 *
XMI /
MDL
Impl. Tests
Idle
start
stop
Contracts
Active
Application of
transformation
rules
UMLAUT
Protocol
*
Validation framework
Java/Eiffel/C(++)
1
Validation engines
www.irisa.fr/UMLAUT
Travaux de recherche
• Conception par aspects, patterns & frameworks
– UMLAUT=weaver UML, ASL, UMLAUT en UML
• Composant Contractualisable
– Générés par UMLAUT pour e.g. EJB, CCM, .NET
• Composants auto-testables & analyse mutations
– process, qualification des tests, mesures de fiabilité
• Synthèse de tests à partir d’UML
– combinant analyse statique (données) et dynamique
Informations et contacts
• Action Triskell
– http://www.irisa.fr/triskell
• Outil UMLAUT
– http://www.irisa.fr/UMLAUT
– Fonctionnalités :
•
•
•
•
Validation et génération de tests
Transformations de modèles UML
Interpréteur/Compilateur OCL/AS (niveaux modèle et méta)
Modélisation et utilisation de design patterns