Validation de conceptions UML de logiciels embarqués : emprunts aux approches formelles
Download ReportTranscript 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