International audienceAujourd'hui les outils IDM ont atteint un bon niveau de maturité et sont de plus en plus adoptés dans le cadre d'applications complexes et critiques. Toutefois, des questions liées à la sûreté des systèmes qui en découlent restent encore ouvertes. Pour répondre à ces questions, nous proposons de ramener l'IDM dans le monde rigoureux des méthodes formelles. Nos principaux objectifs sont : (1) garantir la cohérence des correspondances entre méta-modèles au moyen d'un outil de preuve, en l'occurrence le prouveur de l'atelier B ; (2) être capable de certifier qu'une transformation de modèles préserve la sémantique des modèles source et cible ; et (3) utiliser des outils d'animation de spécifications pour simuler le comportement des différents modèles mis en jeu dans un cadre IDM

Idani, Akram

Ledru, Yves

Schobbens, Pierre-Yves

Hal - Université Grenoble Alpes

Approche formelle pour une Inge´nierie des Mode`les suˆreAkram Idani, Yves Ledru, Pierre-Yves SchobbensTo cite this version:Akram Idani, Yves Ledru, Pierre-Yves Schobbens. Approche formelle pour une Inge´nierie desMode`les suˆre. Atelier LMO/SafeModel, 2009, Nancy, 2009. <hal-00953591>HAL Id: hal-00953591https://hal.inria.fr/hal-00953591Submitted on 28 Feb 2014HAL is a multi-disciplinary open accessarchive for the deposit and dissemination of sci-entific research documents, whether they are pub-lished or not. The documents may come fromteaching and research institutions in France orabroad, or from public or private research centers.L’archive ouverte pluridisciplinaire HAL, estdestine´e au de´poˆt et a` la diffusion de documentsscientifiques de niveau recherche, publie´s ou non,e´manant des e´tablissements d’enseignement et derecherche franc¸ais ou e´trangers, des laboratoirespublics ou prive´s.Approche formelle pour une ingénieriedes modèles sûre 1Akram Idani∗, Yves Ledru∗, Pierre-Yves Schobbens∗∗∗ Laboratoire d’Informatique de Grenoble681 rue de la Passerelle − BP 7238402 Saint Martin d’Hères Cedex{Akram.Idani, Yves.Ledru}@imag.fr∗∗ Université de Namur, Faculté d’Informatique21 Rue Grandgagnagepys@info.fundp.ac.beRésumé. Aujourd’hui les outils IDM ont atteint un bon niveau de maturité etsont de plus en plus adoptés dans le cadre d’applications complexes et critiques.Toutefois, des questions liées à la sûreté des systèmes qui en découlent res-tent encore ouvertes. Pour répondre à ces questions, nous proposons de ramenerl’IDM dans le monde rigoureux des méthodes formelles. Nos principaux objec-tifs sont : (1) garantir la cohérence des correspondances entre méta-modèles aumoyen d’un outil de preuve, en l’occurrence le prouveur de l’atelier B ; (2) êtrecapable de certifier qu’une transformation de modèles préserve la sémantiquedes modèles source et cible ; et (3) utiliser des outils d’animation de spécifica-tions pour simuler le comportement des différents modèles mis en jeu dans uncadre IDM.1 IntroductionL’Ingénierie Dirigée par les Modèles (ou IDM) est une démarche de développement quiconçoit l’intégralité du cycle de développement du logiciel comme un processus de produc-tion, de raffinement itératif et d’intégration de modèles. Plus précisément elle fait la différence,entre modèles indépendants (PIM pour Platform Independent Model) et modèles dépendantsdes plate-formes d’exécution (PSM pour Platform Specific Model). Sur cette base le processusde développement est vu comme étant une transformation progressive d’un modèle PIM, quispécifie la solution d’un système indépendamment des technologies de programmation, versun modèle PSM qui décrit comment cette solution peut être implémentée dans une technolo-gie particulière. En ce sens, l’IDM met en œuvre des “règles” pour définir la cohérence entreles différents modèles utilisés ainsi que la manière de les transformer (ou de les composer)au cours du développement. Les environnements qui supportent cette approche (ATL (Jouault1. Ce travail est financé par le projet SELKIS : A development method of secure health care networks informationsystems : from requirements engineering to implementation− (ANR-08-SEGI-018).Approche formelle pour une IDM sûreet al., 2008) par exemple) nécessitent une description des modèles manipulés par des méta-modèles ; ce qui permet de spécifier les règles de transformation PIM/PSM par des correspon-dances d’un méta-modèle source vers un méta-modèle cible. Les efforts de l’OMG (ObjectManagement Group) dans ce contexte ont donné lieu aux standards MOF (Meta-Object Faci-lity) pour la description des méta-modèles, et QVT pour la spécification des projections entreméta-modèles.Aujourd’hui, bien qu’on constate un grand savoir-faire méthodologique de l’IDM, desquestions liées à la sûreté/fiabilité des systèmes qui en découlent sont encore ouvertes. Eneffet, bien que les environnements IDM existants permettent de spécifier des méta-modèles, ilsne permettent pas de prouver la correction des règles de transformation. Ce n’est donc qu’aprèsl’exécution de la transformation qu’il devient possible de vérifier si le modèle PSM produit estconforme à son méta-modèle. Ceci est dû au fait que pour démontrer qu’une règle de transfor-mation préserve la sémantique des modèles source et cible avant son exécution, des langagesde modélisation, clairement définis avec une sémantique précise, doivent être utilisés. Ce quin’est pas le cas aujourd’hui du standard QVT car il se base en grande partie sur des notationsqui n’offrent pas des outils de preuve.Dans ce contexte, nous proposons de ramener l’IDM dans un monde plus rigoureux, fondésur la méthode formelle B. Nous ciblons par là un double objectif :1. Effectuer des vérifications automatisées avant la transformation PIM/PSM, et ce aumoyen du prouveur de l’atelier B. Ceci permettra de certifier qu’une transformation estcorrecte.2. Utiliser un animateur supportant la méthode B (ProB (Leuschel et Butler, 2003), BZ-TT(Legeard et al., 2002),. . .) pour exécuter la (les) transformation(s). Ceci permettra degénérer automatiquement le modèle cible.2 Validation de transformations de modèlesLa notion de transformation de modèles constitue l’élément central de l’IDM. En effet,cette notion porte sur l’automatisation d’opérations critiques pendant le cycle de développe-ment telles que la génération de code. L’automatisation de ces opérations permet d’augmenterla réutilisation du cœur de métier d’un système à un autre, ce qui entraîne des économies enterme d’effort et de temps. Toutefois, dans le cadre d’applications critiques où sûreté et sécu-rité sont fondamentales, il est primordial d’éviter de produire des transformations de modèleserronées. Par conséquent, l’utilisation des techniques classiques de test et de preuve, devientincontournable pour certifier qu’une transformation de modèles est valide.2.1 Approche basée sur la preuveDans l’objectif d’aider à la validation de transformations de modèles en IDM nous pro-posons une technique de preuve, qui se veut complémentaire aux techniques de test (Brottieret al., 2006). Nous nous inspirons pour ce faire des nombreux travaux de couplage des lan-gages B et UML (Laleau et Polack, 2002; Snook et Butler, 2006). Ces travaux ont cherchéà préciser la sémantique d’UML, à compléter ce langage par des annotations formelles pouraugmenter son pouvoir d’expression, et à traduire les spécifications semi-formelles en B pourprofiter des outils de preuve et d’animation de la méthode B. La figure 1 montre comment notreA. Idani et al.approche se situe dans un contexte IDM classique. Les méta-modèles du PIM et du PSM nesont autres que des diagrammes de classes (spécifiés par le MOF). Il est donc aisé de réutiliserles approches existantes de génération de spécifications B à partir de diagrammes de classesUML en vue de traduire ces méta-modèles en B. Le constat des travaux de couplage de UMLet B nous permet de délimiter le sous-ensemble des constructions engendrées par le MOF surlesquelles ces travaux peuvent être appliqués.				  		    of PIM of PSMFIG. 1 – Usage de méthodes formelles pour l’IDMLes spécifications B résultantes peuvent être raffinées par la prise en compte, sous formed’invariants, de contraintes de sûreté. Par exemple, si on cherche à générer du code Java sûr àpartir d’un modèle objet en entrée, on pourrait être amené à interdire l’utilisation de l’héritagemultiple. Une telle contrainte peut être exprimée en OCL sur les constructions du méta-modèleobjet. Cependant, les outils de preuve de contraintes OCL sont peu nombreux (Brucker etWolff, 2008), et nécessitent la traduction d’OCL dans des logiques mathématiques. Il est doncopportun de pouvoir exprimer ces contraintes invariantes dans la spécification B. L’avantage enest de pouvoir profiter pleinement de l’environnement de preuve de B. Pour ce faire, il existedeux stratégies : (1) explorer les travaux de traduction d’OCL en B (Marcano-Kamenoff etLevy, 2001) ; ou (2) exprimer les contraintes de sûreté par des annotations B au niveau desméta-modèles du PIM et du PSM. Dans le cadre de nos travaux actuels, nous explorons cettedeuxième stratégie.2.2 Bénéfices du modèle formelLe modèle formel issu du méta-modèle du PIM peut être utilisé pour vérifier si le PIM estconforme à son méta-modèle et respecte ses contraintes de sûreté. Il suffit pour cela de générerdes opérateurs de construction d’instances de méta-modèles. La figure 2 donne un exempled’opération de construction permettant d’instancier une portion d’un méta-modèle objet.Quant aux règles de transformation, elles sont injectées dans la spécification formellevia des opérations B. Les opérations Rule1 et Rule2 présentées dans la figure 3 sont desexemples de règles de production de tables relationnelles à partir d’un modèle objet. La règle1 indique qu’une table, spécifiée en B par « Relation ∈ Class ∪ Association », est pro-duite pour chaque classe et pour chaque association disposant d’une multiplicité “0..*”. Larègle 2 permet de générer les attributs de ces tables. Ces attributs correspondent à la relationApproche formelle pour une IDM sûrerelation_attribute définie comme suit : relation_attribute ∈ Relation ↔ (UMLAttribute ∪AssociationEnd).build source model =BEGIN|| Class := {University, Professor}|| UMLAttribute := {name, address}|| AssociationEnd := {teacher, employer}|| ClassifierStFeature := {(name 7→ Professor), (address 7→ University)}|| Association := {teaching}|| multiplicity1 := {(teacher 7→ zero),(employer 7→ zero)}|| multiplicity2 := {(teacher 7→ star),(employer 7→ star)}|| ClassifierAssocEnd := {(teacher 7→ Professor), (employer 7→ University)}|| AssociationAssocEnd := {(teacher 7→ teaching), (employer 7→ teaching)}ENDFIG. 2 – Instanciation du méta-modèle sourceRule1 =PRE Relation = ∅ THENRelation := Class ∪ {aa | aa ∈ Association∧ multiplicity1[AssociationAssocEnd −1 [{aa}]] = {zero}∧ multiplicity2[AssociationAssocEnd −1 [{aa}]] = {star}}END;Rule2 =ˆPRE relation attribute = ∅ THENrelation attribute := {cc, at | cc ∈ Relation ∧ at ∈ UMLAttribute ∪ AssociationEnd ∧((at 7→ cc) ∈ ClassifierStFeature ∨ (at 7→ cc) ∈ AssociationAssocEnd )}ENDFIG. 3 – Règles de transformation exprimées en B.L’utilisation d’un animateur B, tel que ProB, pour animer la séquence :build_source_model; Rule1; Rule2;transforme le diagramme de classes de la figure 2 telle que : Relation = {University, Professor,teaching}, et relation_attribute = {(Professor 7→ name), (University 7→ address), (teaching7→ teacher), (teaching 7→ employer)}. Les autres règles de transformation d’un modèle objeten un modèle relationnel (e.g. génération des clés primaires et étrangères, etc) peuvent êtreexprimées de manière similaire.La preuve de correction des règles de transformation permet de montrer, d’une part, qu’enpartant d’un PIM valide, une transformation produit un PSM conforme à son méta-modèle etrespectant les contraintes de sûreté de ce dernier ; et d’autre part, le respect des invariants deliaison des méta-modèles du PIM et du PSM. Par exemple, l’invariant de liaison ci-dessous,contraint l’ensemble des associations traduisibles en tables relationnelles. Il indique que seulesles associations dont les multiplicités, sur les deux extrémités, sont égales à “0..*” ou “1..*”peuvent donner lieu à des tables dans le modèle relationnel. Le prouveur de l’atelier B permetainsi de vérifier que la règle Rule1 satisfait cette contrainte.∀ rr · (rr ∈ Relation ∧ rr ∈ Association ⇒multiplicity1[AssociationAssocEnd−1 [{rr}]] ⊆ {zero, one}∧ multiplicity2[AssociationAssocEnd−1 [{rr}]] = {star})A. Idani et al.3 PerspectivesUne grande majorité des travaux autour de l’IDM s’orientent vers les langages et tech-niques pour le développement de transformations de modèles mais, parmi ces travaux, très peus’intéressent aux problèmes de la validation/certification. Les techniques de test et de preuve,dans leur dualité, permettent d’aider à cette validation. Cet article présente les premiers pasd’une IDM fondée sur la preuve et l’animation, et ce en explorant une approche dite interpré-tée (Facon et Laleau, 1995) ou deep encoding. Ce travail sera étendu dans les mois prochainsen tenant compte des points suivants :– Approfondir l’identification des constructions des méta-modèles traduisibles en B endéfinissant les correspondances entre le MOF et le langage B.– Adapter les règles de transformation de UML vers B proposées dans la “littérature” à uncontexte orienté IDM.– Étudier les liens entre opérations B et règles initialement exprimées en QVT.Par ailleurs, nous songeons à mener des études sur la génération automatique de modèlesd’entrée pour simuler de façon pertinente les transformations au moyen d’animateurs B. Eneffet, dans le cas où les preuves formelles sont très complexes, l’identification de modèlesd’entrée pertinents peut aider à la validation des transformations. Des outils comme BZ-TT(Legeard et al., 2002) peuvent servir pour générer automatiquement ces modèles d’entrée àpartir de la spécification B.RéférencesBrottier, E., F. Fleurey, J. Steel, B. Baudry, et Y. L. Traon (2006). Metamodel-based testgeneration for model transformations : an algorithm and a tool. In ISSRE, pp. 85–94. IEEEComputer Society.Brucker, A. D. et B. Wolff (2008). HOL-OCL : A Formal Proof Environment for UML/OCL.In J. L. Fiadeiro et P. Inverardi (Eds.), FASE, Volume 4961 of LNCS, pp. 97–100. Springer.Facon, P. et R. Laleau (1995). Des spécifications informelles aux spécifications formelles :compilation ou interprétation ? In Actes du 13ème congrès INFORSID.Jouault, F., F. Allilaire, J. Bézivin, et I. Kurtev (2008). ATL : A model transformation tool.Science of Computer Programming 72(1-2), 31–39.Laleau, R. et F. Polack (2002). Coming and going from uml to b : A proposal to supporttraceability in rigorous is development. In 2nd International Conference of B and Z Users,Volume 2272 of LNCS, pp. 517–534. Springer.Legeard, B., F. Peureux, et M. Utting (2002). Automated boundary testing from Z and B. InFME’02, Formal Methods Europe, Volume 2391 of LNCS. Springer-Verlag.Leuschel, M. et M. Butler (2003). ProB : A Model Checker for B. In FME 2003 : FormalMethods Europe, Volume 2805 of LNCS, pp. 855–874. Springer-Verlag.Marcano-Kamenoff, R. et N. Levy (2001). Transformation d’annotations OCL en expressionsB. In Approches Formelles dans l’Assistance au Développement de Logiciels.Snook, C. et M. Butler (2006). UML-B : Formal modeling and design aided by UML. ACMTransactions on Software Engineering and Methodology (TOSEM) 15(1), 92–122.

Approche formelle pour une Ingénierie des Modèles sûre

Abstract

Similar works

Full text

Available Versions

Hal - Université Grenoble Alpes