FR2919938A1

FR2919938A1 - Procede de realisation d'un modele de processus de developpement logiciel et systeme

Info

Publication number: FR2919938A1
Application number: FR0705718A
Authority: FR
Inventors: Angel Garcia
Original assignee: Individual
Current assignee: Individual
Priority date: 2007-08-06
Filing date: 2007-08-06
Publication date: 2009-02-13

Abstract

L'invention concerne un procédé de réalisation d'un modèle de processus de développement logiciel et système selon lequel on construit un méta-modèle semi formel de modélisation de processus de développement logiciel basé sur un langage graphique et semi formel, puis, à partir du méta-modèle, un modèle semi formel de processus de développement logiciel et système. Selon l'invention, on transforme le méta-modèle et le modèle semi formels en un méta- modèle et un modèle formels basés sur un langage mathématique apte à permettre une vérification par une démarche mathématique probatoire, puis on procède successivement à trois niveaux de vérification : deux premiers niveaux effectués chacun en utilisant la démarche mathématique probatoire de vérification formelle et consistant en un premier niveau de vérification adapté pour contrôler la conformité du méta-modèle, et un deuxième niveau de vérification adapté pour contrôler la conformité du modèle relativement au méta-modèle, et, enfin, un troisième niveau de vérification adapté pour contrôler le respect des règles spécifiques au modèle.

Description

Procédé de réalisation d'un modèle de processus de développement logiciel

et système.

L'invention concerne un procédé de réalisation d'un modèle de 5 processus de développement logiciel et système. Un modèle de processus de développement logiciel et système est adapté pour permettre d'exprimer, dans un langage de modélisation, les spécifications d'un système, de façon à décrire entièrement un procédé de construction de ce système et à définir ses contraintes. De tels modèles sont 10 nécessaires pour aborder des systèmes complexes car ils apportent une abstraction qui permet de mieux comprendre et appréhender la solution. Une fois le système modélisé, il convient, en outre, de s'assurer que le modèle répond bien aux exigences exprimées par les utilisateurs. Il convient également de vérifier que le modèle est cohérent et qu'il répond aux 15 règles ou normes de son métier ou de son domaine d'activité. II convient enfin de s'assurer que le modèle ne comporte pas d'anomalies afin de les éliminer le plus tôt possible dans le cycle de développement. A l'heure actuelle, deux techniques principales sont mises en oeuvre en vue d'effectuer les différentes vérifications précitées. : 20 • la première de ces techniques a pour principe d'effectuer une validation du modèle en simulant, à partir de scénarios pré-établis, le comportement de ce modèle, • la seconde technique a pour principe de réaliser le construction, à partir du modèle, d'un prototype (squelette d'application) à valider 25 par l'utilisateur. Il s'avère toutefois qu'aucune de ces techniques ne permet de garantir de façon absolue le modèle de processus de développement logiciel et système développé. La présente invention vise à combler cette lacune et a pour 30 principal objectif de fournir un procédé de réalisation d'un modèle de processus de développement logiciel et système qui permette de certifier ce modèle.

A cet effet, l'invention concerne un procédé de réalisation d'un modèle de processus de développement logiciel et système comportant des règles, selon lequel : • on construit un méta-modèle semi formel de modélisation de 5 processus de développement logiciel basé sur un langage graphique et semi formel, • on construit, à partir du méta-modèle, un modèle semi formel de processus de développement logiciel et système. Selon l'invention, ce procédé de réalisation consiste à transformer 10 le méta-modèle et le modèle semi formels en un méta- modèle et un modèle formels basés sur un langage mathématique apte à permettre une vérification par une démarche mathématique probatoire, puis à procéder successivement à trois niveaux de vérification : • deux premiers niveaux effectués chacun en utilisant la 15 démarche mathématique probatoire de vérification formelle : • un premier niveau de vérification adapté pour contrôler la conformité du méta-modèle, • et un deuxième niveau de vérification adapté pour contrôler la conformité du modèle relativement au méta-modèle, 20 • et un troisième niveau de vérification adapté pour contrôler le respect des règles spécifiques au modèle. Le procédé selon l'invention consiste donc à effectuer une approche par méta.- modélisation, puis à transformer le méta-modèle et le modèle semi formels en un méta- modèle et un modèle formels exprimés dans un langage 25 mathématique qui permet de garantir par la preuve mathématique la bonne construction du modèle, c'est-à-dire de garantir, sans nécessiter de phase de tests, que les spécifications du système sont respectées et que le modèle ne comporte aucun défaut. A titre de mise en oeuvre avantageux de ce procédé, le langage 30 mathématique et la démarche mathématique probatoire de vérification formelle consistent en la méthode B. Selon un mode de mise en oeuvre avantageux, on transforme également les règles du modèle en un langage mathématique apte à permettre une vérification par une démarche mathématique probatoire, et on met en oeuvre un troisième niveau de vérification consistant à appliquer la dite démarche mathématique probatoire. De plus, lors de la détection d'une erreur durant le troisième 5 niveau de vérification, on déclenche avantageusement une méthode de vérification de type checking adaptée pour permettre de fournir un contre exemple exploitable. D'autres caractéristiques, buts et avantages de l'invention ressortiront de la description détaillée qui suit en référence aux dessins annexés. 10 Sur ces dessins : - la figure 1 est une représentation graphique d'un méta-modèle de référence utilisé selon le procédé de l'invention, - la figure 2 est une représentation graphique d'un modèle semi formel construit à partir du méta-modèle de référence représenté à la figure 1, 15 - et la figure 3 est une représentation graphique des résultats obtenus après les transformations d'un méta-modèle et d'un modèle conformément à l'invention. La description détaillée qui suit vise à illustrer la mise en oeuvre du procédé selon l'invention de réalisation d'un modèle de processus de 20 développement logiciel et système, et cette description détaille successivement les différentes étapes de cette mise en oeuvre, à savoir : 1. construction du méta-modèle, 2. construction du modèle, 3. transformation du méta-modèle : 25 a transformation de type ingénierie des modèles, b transformation vers un langage probatoire, 4. transformation du modèle : a transformation de type ingénierie des modèles, b transformation vers un langage probatoire, 30 5. Vérification du méta-modèle : a application de la méthode B, b garantie du modèle par la dérnonstration des preuves, 6. vérification de la conformité entre modèle et méta-modèle, a application de la méthode B, b garantie du modèle par la démonstration des preuves, 7. Vérification des règles propres au modèle : a spécification des règles dans un langage semi formel, b transformation vers un langage probatoire, c garantie du modèle par la démonstration des preuves.

Il convient de noter que, bien que les étapes du procédé selon l'invention apparaissent ci-dessus listées selon un ordre chronologique, dans la 10 pratique, l'ordonnancement réel est itératif. La première étape vise la construction du méta-modèle de procédé, et l'invention utilise, à cet effet, le standard des méta-modèles, le méta-modèle SPEM (Software Process Engineering Metamodel) défini par l'OMG (Object Management Group). 15 L'objectif de SPEM est de définir un formalisme dédié à la description du processus de développement logiciel. Il propose des structures de modélisation pour décrire un processus de développement logiciel. SPEM est à la fois un méta-modèle MOF (Meta Object Facilities) et un profil UML (Unified Modeling Langage), des correspondances ayant été établies entre ces deux 20 formalismes. SPEM est la synthèse de procédés actuels tel que : IBM Global Service Method, Rational Unified Process, Futjisu SDEM21, Objectory, Fusion, OPEN... L'invention utilise comme méta-modèle de référence le modèle conceptuel SPEM dont un sous-ensemble représentatif est représenté à titre 25 d'exemple à la figure 1 par les éléments de la notation UML. Tel que représenté à la figure 1, ce méta-modèle offre à disposition les éléments : Rôle, Activité et Produit. Les activités peuvent utiliser des produits et en produire. De manière analogue le produit peut avoir une activité en entrée et/ou en sortie. Un rôle peut être responsable de plusieurs produits et 30 réaliser plusieurs activités. En revanche un produit est sous la responsabilité d'un seul rôle et une activité n'est réalisée que par un seul rôle. Le méta-modèle représenté est exploitable dans un format non graphique. A titre d'exemple, l'invention consiste à utiliser le format standard XMI.

La deuxième étape vise la construction du modèle. A titre préliminaire concernant cette construction, il convient de spécifier que la méthode B, de par son aspect formel, s'inscrit dans la mise en oeuvre de processus matures. Pour cette raison, le procédé de développement logiciel proposé par la norme NF ISO/CEI 12119 pour la certification NF Logiciel répond aux exigences. L'intérêt principal est de disposer d'un cadre formalisé et non modifiable pour la réalisation et la démonstration du procédé. Il faut noter, à ce sujet, que le procédé à réaliser est un procédé générique ou modèle de procédé et non un procédé final. En effet l'objectif n'est pas d'établir une démarche de modélisation et de vérification qui devra être reconstruite à chaque nouveau projet mais de disposer d'un procédé générique formel servant à la construction, par instanciation, d'un procédé exécutable. Le procédé de construction d'un modèle conformément à l'invention consiste à : - écrire les spécifications détaillées à partir des spécifications générales, - programmer à partir des spécifications détaillées, - et construire les jeux de tests ou scénarios et jouer ces scénarios. Pour chacune des activités et conformément au SPEM, le rôle et les produits intervenants sont ainsi spécifiés. Le procédé est similaire à un cycle en V. A titre d'illustration, la figure 2 est une représentation graphique du modèle exprimé en SPEM du sous-ensemble représentatif de la figure 1. L'étape suivante vise la transformation du méta-modèle. a/ transformation de type ingénierie des modèles ArgoUML+B. La technique de transformation consiste à passer du méta-modèle SPEM vers un méta-modèle exprimé en B par une machine abstraite. La 30 transformation se fait donc uniquement au niveau 2 de l'architecture MDA. L'outil de modélisation utilisé consiste en l'outil ArgoUML+B développé et utilisé dans le cadre de l'écriture des machines, et permet de passer d'un modèle métier exprimé en SPEM vers un modèle métier exprimé en B qui 25 correspond à une transformation de type PIN vers PIN. Cette transformation reste semi-automatique. b/ Transformation vers un langage probatoire : méthode B. La méthode B permet l'expression de propriétés sous la forme de prédicats du premier ordre et les opérations auxquelles on peut faire appel sont celles de l'arithmétique et de la théorie des ensembles. La théorie des ensembles est représentée, selon l'invention, comme un cadre pour la description des modèles mathématiques. La méthode B regroupe : • un langage de spécification AMN, (Abstract Machine 10 Notation), assorti d'un système de preuves, • et une technique de raffinage, de codage, et les systèmes de preuves correspondants. Comme la méthode Z, la méthode B repose sur la théorie des ensembles et la logique des prédicats du premier ordre. Toutefois, contrairement à 15 la méthode Z, la rnéthode B a une coloration développement dans la façon de spécifier les opérations : on ne les spécifie pas en terme de pré-conditions et de post-conditions, mais au moyen de substitutions généralisées. Ce mécanisme peut s'interpréter comme une extension de l'affectation telle qu'elle existe dans les langages impératifs. Enfin, la méthode B offre une notation homogène pour la 20 spécification et le développement. Suite à cette transformation, le méta-modèle, de niveau 2 dans l'architecture MDA, devient, dans son équivalent mathématique, une machine abstraite. En effet, de la même manière que pour un méta-modèle du MOF, il est intéressant de le construire puis de le vérifier afin de le rendre disponible. 25 L'étape suivante vise la transformation du modèle. a/ transformation de type ingénierie des modèles ArgoUML+B. Cette approche consiste à créer une machine par élément du méta-modèle. Cette architecture se rapproche ainsi de la démarche préconisée 30 par la méthode B à savoir une approche modulaire du projet. L'avantage principal, hormis le caractère réutilisable , est de faciliter la démonstration des preuves. b/ Transformation vers un langage probatoire : méthode B.

Cette transformation repose sur le même principe que la transformation du méta-modèle mais le raffinement de la machine abstraite, donc la spécification du modèle, correspond pour sa part au niveau 1 du MDA. L'invention conduit ainsi à construire une instance du méta- modèle similaire à une construction réalisée avec un modèle UML. En effet, la vérification des obligations de preuve issues du raffinement garantit alors le respect du méta-modèle. La figure 3 illustre le résultat obtenu après les transformations ci-dessus décrites d'un méta-modèle et d'un modèle.

Chaque élément du méta-modèle est spécifié dans une machine abstraite. La machine abstraite Types contient la déclaration des ensembles énumérés, les constantes et les propriétés du projet. Elle est reconnue, SEES , par l'ensemble des machines. La machine abstraite SPEM constituant le méta-modèle B conforme à l'invention, introduit et définit les propriétés. Elle initialise également les variables des ensembles déclarés dans les autres machines. SPEM étend (EXTENDS) l'ensemble des machines du méta-modèle, et est destiné à âtre ensuite raffiné dans SPEM Modèle . Les étapes suivantes de vérification du méta-modèle et de vérification de la conformité entre modèle et méta-modèle consistent : • à appliquer la méthode B sur le méta-modèle formel, et à garantir ce méta-modèle par lé démonstration des preuves réalisée par le prouveur de l'Atelier B , 25 • et à appliquer la méthode B au modèle formel de façon à garantir la conformité du dit modèle et du méta-modèle, et à garantir le modèle par la démonstration des preuves. La dernière étape vise la vérification des règles propres au modèle et consiste, en premier lieu, à spécifier ces règles dans un langage semi formel, le 30 langage OCL (object constraint langage). En effet, les étapes précédentes ont conduit à spécifier des propriétés dans le méta-modèle et permis de vérifier que le modèle respecte bien 20 son méta-modèle. Toutefois, ces vérifications ne suffisent pas pour modéliser un processus car le modèle a lui aussi des propriétés qui lui sont propres. Selon l'invention, le modèle se trouve au niveau du raffinement B : les propriétés de ce modèle sont donc introduites par une clause spécifique (clause INVARIANT ) dans la machine de raffinement SPEM. Idéalement, ces propriétés sont, en outre, définies en OCL dans le modèle SPEM du procédé et correspondent ainsi à une transition d'OCL vers B. Quatre exemples de propriétés sont détaillés ci-dessous : Propriété 1 : Le rôle (au sens SPEM) qui réalise la spécification détaillée doit également réaliser les jeux de tests. Cette activité ne doit pas être laissée à un autre rôle. Pour être plus juste vis à vis de la norme ISO/CEI, cette règle porte sur l'acteur physique, donc sur l'implémentation du modèle. La vérification consiste à s'assurer que le rôle qui réalise la spécification détaillée est bien celui qui réalise les jeux de tests.

Ecriture en français formel : quelque soit rr appartenant à rôle, si rôle est en relation avec EcrireSpecDetaillee alors rr est en relation avec EcrireJeuxTests . Modèle mathématique correspondant : !(rr).(rr:role & (rr 1-> ConstruireJeuxTests): performs => 20 (rr I-> EcrireSpecDetaillee ) : performs) & !(rr).(rr:role & (rr EcrireSpecDetaillee):performs => (rr I-> ConstruireJeuxTests) : performs) Propriété 2 : La spécification générale ne peut être modifiée par 25 un intervenant du système. Une modification fait intervenir un avenant qui n'est pas modélisé dans le système. Ecriture en français formel : il n'existe pas d'activité qui puisse produire un produit SpecGenerale. Modèle mathématique correspondant : 30 not(#(aa).(aa:activity & (aal-> SpecGenerale):produces)) Propriété 3 : Le testeur ne doit pas pouvoir accéder aux spécifications détaillées pour jouer les jeux de tests (Règle arbitraire pour démonstration).

Ecriture en français formel : dans la relation d'utilisation Use , il n'existe pas de couple JouerJeuxTests, SpecDetaillee. Modèle mathématique correspondant : not((JouerJeuxTests 1-> SpecDetaillee):use) Les étapes suivantes concernant les règles ainsi spécifiées dans un langage semi formel consistent à procéder à leur transformation vers un langage probatoire, puis à vérifier ces règles de manière probatoire au niveau du modèle, de façon à garantir le dit modèle par la démonstration des preuves. II 'est à noter que cette vérification peut être réalisée dans le langage OCL, mais elle ne présente pas alors un caractère probatoire et s'avère donc moins rigoureuse. En dernier lieu, lors de la détection d'une erreur durant ce troisième niveau de vérification, on déclenche une méthode de vérification de type checking .15

Claims

REVENDICATIONS

: 1/ Procédé de réalisation et de certification d'un modèle de 5 processus de développement logiciel et système comportant des règles, selon lequel : - dans une première phase dite de construction : • on construit un méta-modèle semi formel de modélisation de processus de développement logiciel basé sur un langage 10 graphique et semi formel, • et on construit, à partir du méta-modèle, un modèle servi formel de processus de développement logiciel et système, le dit procédé étant caractérisé en ce que : - dans une deuxième phase dite de transformation, on transforme 15 le méta-modèle et le modèle semi formels en un méta-modèle et un modèle formels basés sur un langage mathématique apte à permettre une vérification par une démarche mathématique probatoire, - et, dans une troisième phase dite de vérification, on procède successivement à trois niveaux de vérification consistant en : 20 • deux premiers niveaux effectués chacun en utilisant la démarche mathématique probatoire de vérification formelle : • un premier niveau de vérification adapté pour contrôler la conformité du méta-modèle, • et un deuxième niveau de vérification adapté pour 25 contrôler la conformité du modèle relativement au méta-modèle, • et un troisième niveau de vérification adapté pour contrôler le respect des règles spécifiques au modèle.
2/ Procédé de réalisation selon la revendication 1 caractérisé en 30 ce que l'on transforme les règles du modèle en un langage mathématique apte à permettre une vérification par une démarche mathématique probatoire, et en ce que l'on met en oeuvre un troisième niveau de vérification consistant à appliquer la dite démarche mathématique probatoire. 10 103/ Procédé de réalisation selon l'une des revendications 1 ou 2 caractérisé en ce que, lors de la détection d'une erreur durant le troisième niveau de vérification, on déclenche une méthode de vérification de type checking . 4/ Procédé de réalisation selon l'une des revendications 1 à 3 caractérisé en ce que le langage mathématique et la démarche mathématique probatoire de vérification formelle consistent en la méthode B. 5/ Procédé de réalisation selon l'une des revendications 1 à 4 caractérisé en ce que l'on utilise le modèle conceptuel SPEM (Software Process Engineering Metamodel) comme méta-modèle de référence.