tude des Reprsentations Haut-Niveau en Ingnierie Systme et de leur Aptitude Supporter des Vrifications Formelles

Charlotte Seidner Mai 2006

Table des matires

Sigles et acronymes Introduction 1 Les diagrammes FFBD et leurs drivs 1.1 Introduction : reprsentations graphiques en ingnierie systme 1.2 Diagrammes FFBD . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 Syntaxe et smantique . . . . . . . . . . . . . . . . . . . 1.2.3 Utilisations et limites . . . . . . . . . . . . . . . . . . . . 1.3 Diagrammes EFFBD . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.2 Syntaxe et smantique . . . . . . . . . . . . . . . . . . . 1.3.3 Outils logiciels . . . . . . . . . . . . . . . . . . . . . . . 1.4 Vers une traduction des EFFBD en rseaux de Petri . . . . . . 1.4.1 Dnition et smantique des rseaux de Petri . . . . . . 1.4.2 Utilisation des RdP pour reprsenter les FFBD . . . . . 1.4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 5 7 9 9 9 9 9 13 14 14 14 15 16 16 16 18 19 19 19 20 23 24 25 25 25 27 27 28 29 29 30 31 31 32

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

2 Les langages de modlisation UML et SysML 2.1 Le langage UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Historique principales caractristiques dUML 1.x . . . . . 2.1.2 Description des diagrammes dUML 1.x . . . . . . . . . . . 2.1.3 Limites dUML 1.x, description et smantique dUML 2.0 . 2.1.4 Quelques limites dUML 2.0 . . . . . . . . . . . . . . . . . . 2.2 Le langage SysML . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Description des diagrammes de SysML . . . . . . . . . . . . 2.3 Vrications formelles sur les langages UML et SysML . . . . . . . 2.3.1 Utilisation dun prol UML rseaux de Petri : UML/PNO 2.3.2 Autres travaux . . . . . . . . . . . . . . . . . . . . . . . . . 3 Le langage de description darchitecture 3.1 Introduction . . . . . . . . . . . . . . . . 3.2 Le langage AADL . . . . . . . . . . . . . 3.2.1 Composants AADL . . . . . . . . 3.2.2 lments dinterface (features) . 3.2.3 Proprits (properties) . . . . . . 3 AADL . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

TABLE DES MATIRES

3.3 3.4

OSATE, un outil AADL . . . Le modle derreur dAADL . 3.4.1 Introduction . . . . . . 3.4.2 Dmarche dvaluation

. . . . . . . . . de la

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . abilit avec AADL

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

33 33 33 34 37 37 37 38 38 38 39 40 41 43

4 La mthode danalyse et de conception Sagace 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Historique . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Dmarche de modlisation . . . . . . . . . . . . . 4.2 Les lments de modlisation de Sagace . . . . . . . . . 4.2.1 Matrice des neuf points de vue . . . . . . . . . . 4.2.2 Le langage Sagace . . . . . . . . . . . . . . . . . 4.3 Exemple de mise en uvre : modlisation dun lave-linge 4.4 Conclusions sur la mthode Sagace . . . . . . . . . . . . Conclusion

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

Sigles et acronymes
AADL CEA FFBD EFFBD GSNP IEEE IC/IR INCOSE INSTN LL MEI OMG OSATE RdP SADT SAE TOPCASED SysML UML XMI XML Architecture Analysis & Design Language Commissariat lnergie Atomique Functional Flow Block Diagram Enhanced Functional Flow Block Diagram Generalized Stochastic Petri Nets Institute of Electrical and Electronic Engineering informations de commande/rsultat INternational COnference on System Engineering Institut National des Sciences et Techniques Nuclaires logique linaire matriaux nergie information Object Management Group Open Source AADL Tool Environment rseau de Petri Structured Analysis & Design Technique Society of Automotive Engineers Toolkit in OPen-source for Critical Application & SystEms Development Systems Modeling Language Unied Modeling Language XML Metadata Interchange eXtensible Markup Language

Introduction
Les tches assignes lingnieur systme sont multiples et varies : conception et ralisation du systme, bien sr, mais aussi estimation des cots de dveloppement et dexploitation, prvention des risques humains ou conomiques, matrise de la maintenance et des volutions, etc. [Mei98, INC04] Depuis la n des annes 1960, le processus dingnierie systme a fait lobjet de plusieurs normes : citons en particulier la norme MIL-STD-499, standard militaire dvelopp par le Department of Defense amricain [DoD69], et la norme civile correspondante, lIEEE1220 [IEE94]. Celle-ci prsente lingnierie systme comme un ensemble de trois processus danalyse itratifs, chacun tant suivi dune phase de vrication ( a-t-on contruit un bon systme ? ) et de validation ( le systme que lon a construit est-il le bon ? ), comme prsent gure 1.

Fig. 1 Le processus dingnierie systme selon la norme IEEE-1220 Ces phases sont tout fait primordiales pour assurer la satisfaction des direntes exigences et contraintes du projet, et en particulier la sret de fonctionnement du systme concevoir. De nombreuses mthodes existent actuellement pour eectuer ces tapes, dont 7

les mthodes formelles et tout particulirement lapproche par model-checking. Celle-ci permet en particulier de tester des proprits de sret ( quelque chose de mauvais narrivera jamais ), de vivacit ( quelque chose de bon nira forcment par se produire ) et dquit ( quelque chose de bon pourra se produire une innit de fois ). Cependant, ces techniques sont souvent complexes, non intuitives et ncessitent gnralement une part importante de formation pour tre utilises au mieux de leur puissance [Rug05]. Cest pourquoi elles sont gnralement peu intgres dans les environnements de dveloppement darchitectures, en particulier dans le domaine de lingnierie systme. Le but de cette synthse bibliographique est ainsi de se familiariser avec les principales reprsentations de haut-niveau employes en ingnierie des systmes et des logiciels, pour ensuite valuer leur aptitude se prter des vrications formelles. Cela nous permettra, lors du stage pratique du Master de Recherche, dtudier et de mettre en uvre lintgration la reprsentation de systme ainsi choisie un outil de vrication formelle. Devant la grande varit de formalismes existants, nous avons choisi de nous limiter aux diagrammes FFBD (Functional Flow Block Diagram) et leurs drivs (chapitre 1), aux langages UML (Unied Modeling Language) et SysML (Systems Modeling Language, chapitre 2) et au langage AADL (Architecture Analysis and Design Language, chapitre 3). Nous donnons enn un aperu de la mthode danalyse et de conception systmique Sagace, dveloppe au CEA (chapitre 4).

Chapitre 1

Les diagrammes FFBD et leurs drivs

1.1 Introduction : reprsentations graphiques en ingnierie systme

Pour dcrire les structures fonctionnelles et les ux de donnes dun systme, les ingnieurs chargs de sa conception ont souvent recours des reprsentations graphiques relativement simples. Le choix dune reprsentation peut galement savrer crucial lorsquil sagit de communiquer ou dchanger ecacement des modles avec dautres quipes de conception. De nombreuses reprsentations ont t dveloppes depuis plus dun demi-sicle ; nous ne traiterons ici que de la famille des Functional Flow Block Diagrams (FFBD), les diagrammes gurants parmi les plus utiliss en ingnierie systme [Lon95, OKK97, KSR+ 98].

1.2
1.2.1

Diagrammes FFBD
Historique

Les diagrammes FFBD ont t dvelopps vers la n des annes 1950 par la socit TRW Corp. Le but de ces diagrammes tait de fournir une aide la description du comportement de missiles balistiques, trop complexe pour tre dcrit rigoureusement sous forme textuelle. Ces diagrammes de comportement (behavior diagrams) ont par la suite fait lobjet dune norme, avec le standard militaire amricain MIL-STD-499 [DoD69]. Bien quorant un formalisme assez ancien, les FFBD sont encore couramment employs et ont fait lobjet de nombreuses publications dans le domaine de lingnierie systme. Cependant, il nexiste pas, notre connaissance, de dnition formalise de ces diagrammes, et relativement peu darticles ont t publis sur cette mthode de description du comportement fonctionnel des systmes [Her04].

1.2.2

Syntaxe et smantique

Les diagrammes FFBD, dont un exemple est donn gure 1.1, reprsentent les fonctions excutes par le systme et lordre dans lequel lexcution doit avoir lieu. Les fonctions sont reprsentes par des rectangles, portant le nom de la fonction et un numro dordre 9

10

CHAPITRE 1. LES DIAGRAMMES FFBD ET LEURS DRIVS

hirarchique ; lordre dexcution est dtermin par les direntes structures de contrle dcrites plus bas, souvent repres par des nuds de rfrence symboliss par des cercles.

Fig. 1.1 Exemple de diagramme FFBD [Lon95]

Squences et hirarchie Le diagramme se lit de la gauche vers la droite : deux fonctions devant sexcuter en squence sont relies par une che allant de la fonction amont vers la fonction aval. Celle-ci ne peut sexcuter avant la terminaison de la fonction prcdente. An de limiter la taille des diagrammes, ou de ne faire apparatre que les lments pertinents pour un niveau de dtail donn, il est possible de recourir lencapsulation des fonctions. La reprsentation des fonctions-mres varie selon les auteurs, il peut sagir de rectangles ouverts (cf. gure 1.2) ou dun carr noir dans le coin suprieur gauche du rectangle de la fonction.

Fig. 1.2 Modlisation de la hirarchie et des squences dans un diagramme FFBD [OKK97]

Branches parallles (AND) La structure des branches parallles, illustre gure 1.3, comprend : un premier nud de rfrence AND ; n branches (n 2) issues de ce nud et comportant un nombre quelconque de fonctions ou dautres structures de contrle ; un second nud AND o se rejoignent toutes les branches partant du premier nud. La premire fonction de chaque branche est excute immdiatement aprs lentre dans la structure, en parallle des autres branches. La sortie de la structure se fait par une convergence en et : toutes les branches doivent avoir termin leur excution avant de pouvoir sortir de la structure et passer le contrle la fonction ou structure suivante. Les nuds and sont ainsi des points de synchronisation.

1.2. DIAGRAMMES FFBD

11

Fig. 1.3 Structure parallle (AND) Terminaison force (kill branch) Il est possible de forcer la terminaison dune ou plusieurs branches parallles en attachant le modicateur kill une branche quelconque dune structure parallle. La terminaison de la dernire fonction de la branche ainsi marque force les autres branches de la structure se terminer, quel que soit leur tat. Le contrle passe alors llment suivant la convergence en et . Slection de branche (OR) De construction similaire la structure en parallle, la slection de branche comprend les lments suivants : un premier nud OR gurant une divergence en ou ; n branches (n 2) issues de ce nud et comportant un nombre quelconque de fonctions ou dautres structures de contrle ; un second nud OR eectuant la convergence en ou des branches partant du premier nud. Chaque branche est aecte dune probabilit de choix. La slection est celle dun ou exclusif : une seule branche sur les n est excute, en fonction des probabilits des branches de la structure. Par dfaut, toutes les branches sont quiprobables. Fonctions sorties multiples (multi-exit function) Cette structure, illustre gure 1.4, permet de choisir une branche parmi n (n 2), en fonction dune probabilit, comme ci-dessus, ou en fonction dun critre de n dexcution (completion criterion). Les branches sont situes en sortie de la fonction ; elles possdent un nombre quelconque de fonctions ou de structures de contrle et se rejoignent toutes sur un nud OR, sauf celles connectes un nud de terminaison (exit node), dcrit plus bas.

Fig. 1.4 Fonction sorties multiples Le choix de la branche excuter, lorsquil nest pas fonction dune probabilit, est

12

CHAPITRE 1. LES DIAGRAMMES FFBD ET LEURS DRIVS

dtermin par un critre valu lors de lexcution de la fonction sorties multiples (par dfaut, toutes les branches sont quiprobables).

Nud de terminaison (EXIT) Ce nud est utilis en conjonction avec les fonctions sorties multiples et les dcompositions hirarchiques. Lorsque le contrle parvient un nud de terminaison, il force la sortie du niveau hirarchique courant et transfre le contrle la fonction du niveau hirarchique immdiatement suprieur. Plus prcisment, le nud de terminaison tablit une correspondance (mapping) entre chaque branche de sortie dune fonction sorties multiples et la terminaison de sa dcomposition en sous-fonctions : il doit ainsi y avoir autant de nud de terminaison que de branches de sortie dans la fonction-mre. Chaque nud mentionne le critre de terminaison correspondant la branche auquel il se rapporte.

Fig. 1.5 Nud de terminaison Ainsi, lorsque lexcution parvient un nud de terminaison, elle quitte la dcomposition et se poursuit sur la branche correspondante dans la fonction-mre (voir gure 1.5).

Boucle (LP) et sortie de boucle (Loop Exit) Une structure de boucle comprend deux nuds LP encadrant une branche comprenant un nombre quelconque de fonctions et de structures de contrle, ainsi quune boucle de retour. La boucle comprend gnralement une structure de sortie de boucle (LE), qui transfre lexcution llment situ aprs la boucle (cf.gure 1.6). Faute de quoi, la boucle est excute indniment.

1.2. DIAGRAMMES FFBD

13

Fig. 1.6 Boucle et sortie de boucle Itration (IT) La structure ditrations est similaire celle de la boucle, vue ci-dessus. Elle comprend deux nuds IT encadrant une branche comprenant des fonctions et des structures de contrle en nombre quelconque, ainsi quune boucle de retour spciant le nombre ditrations eectuer. Rplication (RP) La rplication permet lactivation parallle et indpendante de n instances dune mme fonction. La structure comporte deux nuds RP encadrant une ou plusieurs fonctions, ainsi quune branche de contrle, charge de linitialisation et de la terminaison des fonctions rpliques (voir gure 1.7). La sortie de la structure seectue lorsque toutes les instances de la rplication sont termines.

Fig. 1.7 Structure de rplication

1.2.3

Utilisations et limites

Les FFBD orent un outil appropri lorsquil sagit deectuer une premire analyse du systme, sans chercher modliser les dirents ux de donnes. Il est en eet important de noter que les diagrammes FFBD ne grent aucunement les informations concernant les changes de donnes entre les fonctions et ne capturent pas les ux dentres/sorties des fonctions. Ainsi, en ne reprsentant pas les interactions entre les fonctions, les FFBD ne sont pas directement excutables et norent quune vue partielle du systme.

14

CHAPITRE 1. LES DIAGRAMMES FFBD ET LEURS DRIVS

1.3
1.3.1

Diagrammes EFFBD
Historique

Plusieurs diagrammes ont t dvelopps vers la n des annes 1970 an dintgrer aux diagrammes FFBD une surcouche grant les ux de donnes entre les fonctions. Les travaux dAlford ont donns lieu aux diagrammes de comportement ou Behavior Diagrams [Alf76, Alf92], ceux de Long ont conduit aux diagrammes EFFBD ou Enhanced FFBD [Lon95]. Ces deux types de diagrammes sont sensiblement identiques, la dirence majeure tant le sens de lecture des diagrammes (de haut en bas pour les diagrammes de comportement et de gauche droite pour les EFFBD).

1.3.2

Syntaxe et smantique

Les EFFBD gardent la mme smantique et les mmes structures de contrle que les diagrammes FFBD. Ils reprsentent en outre les ux de donnes, qui sont notes par des rectangles arrondis et relies aux fonctions mettrices et rceptrices par des ches. Les diagrammes EFFBD permettent de distinguer deux types de donnes, dcrits ci-dessous.

Fig. 1.8 Exemple de diagramme EFFBD

Donnes simples (non-triggering data ou data store) Ces donnes sont reprsentes sur fond gris ; des ches simples les relient dune part la fonction mettrice et dautre part la (ou aux) fonction(s) de destination (cf. gure 1.8). Elles reprsentent des donnes non causales : leur prsence ne dclenche pas lexcution des fonctions les recevant. De plus, on suppose quune donne de ce type est toujours prsente pour tre traite par la fonction qui la reoit, do leur nom de data store.

1.3. DIAGRAMMES EFFBD

15

Triggers (triggering data) Les triggers sont des donnes dont la prsence commande le dclenchement dune fonction valide (enabled) par le ux de contrle. Ils sont reprsents sur fond vert ; les ches qui relient fonctions mettrices et rceptrices sont doubles (cf. gure 1.8). Les triggers sont ainsi des entits qui cumulent les aspects de contrle et de donnes. Pour tre excute, une fonction doit dabord tre valide par la terminaison des fonctions la prcdant dans la structure de contrle puis dclenche par larrive des triggers quelle reoit. La littrature ne donne pas de prcisions ce sujet, mais il semblerait que les occurences des triggers soient mmorises ; ainsi, lorsquune fonction est nouvellement valide, cela neace pas la liste des triggers ventuellement en attente.

1.3.3

Outils logiciels

Latelier logiciel CORE Workstation, dvelopp depuis 1992 par Vitech Corp., implmente les diagrammes FFBD et EFFBD, ainsi que dautres reprsentations usuelles en ingnierie systme, comme les diagrammes N2 (spciant les interfaces fonctionnelles). Il permet de mettre en uvre quasiment toutes les constructions dnies plus haut, lexception notable des rplications. De plus, il est possible de prciser quelques paramtres supplmentaires permettant dobtenir un modle excutable. En particulier, le modle dnit les lments suivants [Vit00] : dure dexcution dune fonction (valeur dterministe ou stochastique) ; dnition de ressources (cres, consommes ou mobilises par les fonctions) ; dnition dun timeout (dure maximale entre la validation dune fonction par le contrle et le dclenchement par ses triggers) au bout duquel la fonction est dsactive et le contrle transfr llment suivant. Par ailleurs, le logiciel comprend un module de vrication dynamique, COREsim. Celui-ci permet la simulation du systme dcrit par son diagramme EFFBD et les paramtres indiqus ci-dessus. Il est possible dexcuter le diagramme sur un scnario prdni, pour une dure xe par lutilisateur et en mode continu ou pas--pas. Les rsultats sont donns sous la forme de chiers denregistrement (logs) et de chronogrammes, dont un exemple est propos gure 1.9. Les direntes couleurs permettent de visualiser les tats des fonctions en jeu (active, en attente dun trigger ou de ressources, inactive...). Le chronogramme reprsente galement ltat des ressources au cours de la simulation.

Fig. 1.9 Exemple de chronogramme obtenu avec COREsim

16

CHAPITRE 1. LES DIAGRAMMES FFBD ET LEURS DRIVS

1.4

Vers une traduction des EFFBD en rseaux de Petri

Quelques auteurs ont esquiss une traduction des diagrammes FFBD et EFFBD vers les rseaux de Petri (RdP) [Her04] ou les automates dtats nis [OKK97] mais aucun, notre connaissance, na formalis ces traductions. Nous prsentons ici les travaux et rsultats exposs dans [Her04], qui donnent une dnition simplie des rseaux de Petri ainsi quune premire bauche de traduction des FFBD vers les RdP.

1.4.1

Dnition et smantique des rseaux de Petri

La dnition est celle prsente dans [Her04] : Dnition 1 Un rseau de Petri est un 6-uplet P N = (P, T, i, o, W, M ) o : P est un ensemble ni non vide de places, reprsentant les tats potentiels du systme ; T est un ensemble ni non vide de transitions, reprsentant les vnements potentiels du systme ; i est lensemble des arcs dentre, reprsentant les pr-conditions sur les vnements ; o est lensemble des arcs de sortie, reprsentant les post-conditions sur les vnements (i o = ) ; W N|io| donne les poids (entiers) de chaque arc ; M est la fonction de marquage donnant la distribution des jetons dans les places. Le dplacement des jetons dans le rseau se fait par franchissement ou tir des transitions ; une transition ne peut tre tire quaprs avoir t sensibilise. Une transition t est sensibilise si et seulement si il existe au moins W (p, t) jetons dans chaque place p relie cette transition par un arc dentre. Le tir de la transition suit alors les rgles smantiques suivantes : 1. seule une transition sensibilise peut tre tire ; 2. W (pi , t) jetons sont retirs de chaque place dentre pi et W (po , t) jetons sont dposs dans chaque place de sortie po ; 3. le tir dune transition est suppos instantan.

1.4.2

Utilisation des RdP pour reprsenter les FFBD

Un RdP permet de traduire la causalit entre les fonctions du systme en associant chaque fonction f une place p telle que la fonction f est active lorsquun jeton est prsent dans la place p. Par contre, une place p ne correspond pas forcment une fonction du systme. Les rgles de tir dune transition dnies plus haut sont augmentes des deux points suivants : 4. une transition t ne peut tre tire tant quune fonction fi associe une de ses places dentre pi est active (i.e. la fonction doit tre termine avant de pouvoir tirer la transition) ; 5. une transition t pour laquelle le nombre de jetons dans chaque place dentre pi est suprieur au poids de larc dentre correspondant et aucune fonction associe ses places dentre nest active doit immdiatement tre tire.

1.4. VERS UNE TRADUCTION DES EFFBD EN RSEAUX DE PETRI

17

Dans un modle FFBD, une fonction est considre comme acheve lorsquaucune fonction dans sa dcomposition nest active. Dans le cas des RdP, cela se traduit par un marquage o tous les jetons sont concentrs dans une place p nayant pas de transition de sortie et qui nest associe aucune fonction du systme. titre dexemple, nous illustrons ce mcanisme par le diagramme FFBD de la gure 1.10 et sa traduction associe gure 1.11. Les places correspondant des fonctions du diagramme FFBD portent la mme tiquette ; les places auxiliaires , permettant de modliser les direntes structures de contrle, ont leur tiquette prcde dun A. Ainsi, la synchronisation de la convergence en et est ralise grce aux places A1 et A2. De mme, la rplication est modlise par les places 1.6, 1.7, A.4 et A.5 ; le poids des arcs reliant T6 1.6 dune part et A.5 T14 dautre part permettent de dnir lactivation en parallle de N instances de la fonction 1.6.

Fig. 1.10 Exemple de diagramme FFBD

Fig. 1.11 Traduction en rseau de Petri du diagramme de la gure 1.10 Cependant, plusieurs structures de contrle ne peuvent tre dnies laide des RdP. Il est en particulier impossible de distinguer des itrations bases sur des valeurs xes ( vraies itrations ) et sur lvaluation dune condition (boucles et sorties de boucle). De mme, il nest pas possible de forcer la terminaison de branches parallles, comme avec lannotation kill des FFBD.

18

CHAPITRE 1. LES DIAGRAMMES FFBD ET LEURS DRIVS

1.4.3

Conclusion

Il convient de prciser que [Her04] ne donne pas de rgle prcise de traduction des diagrammes FFBD vers les RdP. De plus, les quelques points limitants de lutilisation des RdP mentionns plus haut devraient tre contourns par une tude plus approfondie des modles FFBD. Par ailleurs, si cette traduction nore pas de support pour prendre en compte les ux de donnes introduits dans les EFFBD, ce point ne devrait pas tre limitant. En eet, nous avons indiqu plus haut que les donnes de type triggers peuvent tre vues comme des lments de contrle, au mme titre que les structures de contrle mises en uvre dans les FFBD. Cette dimension devrait ainsi tre facilement intgrable au RdP. En dautres termes, il parat intressant dintgrer aux EFFBD des aspects temporels (tels que les dures dexcution des fonctions) et la cration et la gestion de ressources, pour ensuite en proposer une traduction vers un formalisme qui en permettrait la vrication temporelle.

Chapitre 2

Les langages de modlisation UML et SysML

Comme expos dans le chapitre prcdent, les diagrammes EFFBD ont t dvelopps pour modliser laspect fonctionnel dun systme. En revanche, ils ne permettent pas den capturer les aspects structurels, tels que larchitecture physique. Cest en particulier pour prendre en compte ces points de vue quont t crs les langages UML (Unied Modeling Langage) en ingnierie logicielle puis SysML (Systems Modeling Langage) en ingnierie systme.

2.1
2.1.1

Le langage UML
Historique principales caractristiques dUML 1.x

Les techniques orientes objet (OO) se sont dveloppes partir des annes 1980 an de runir dans le mme concept dobjet les aspects fonctionnels et les ux de donnes constitutifs des systmes modliser. De nombreux langages et mthodes OO ont alors t crs ; la fusion de trois dentre eux (Booch, OMT et OOSE) a conduit la cration du langage UML. La version 1.1 a fait par ailleurs lobjet dune norme de lOMG (Object Management Group). Plusieurs versions ont depuis vu le jour, dont UML 1.4 (2002) et UML 1.5 (2003). Selon lOMG, UML est un langage graphique multi-domaine de visualisation, spcication, construction et documentation de produits dun systme fortement orient logiciel mais aussi dautres systmes non logiciels . UML ore un moyen standardis de dcrire un systme en phase de conception, en incluant des vues plus conceptuelles (comme les fonctions du systme) et des vues plus concrtes, telles que des instructions en langage de programmation, des schmas de bases de donnes ou des composants logiciels rutilisables. Le langage manipule de nombreux lments, dcrits dans le mta-modle 1 dUML et dont un extrait est donn gure 2.1. On retiendra principalement les classes, dont les objets sont des instances, les attributs, les lments du comportements, etc. organiss dans des diagrammes. UML est un langage but universel , mais il est vident quil ne peut couvrir toutes les situations rencontres dans un domaine dapplication quelconque. Des mcanismes dextension sont ainsi dnis pour appliquer UML des problmatiques spciques, tout en
1

i.e. la modlisation de ce langage de modlisation

19

20

CHAPITRE 2. LES LANGAGES DE MODLISATION UML ET SYSML

Fig. 2.1 Extrait du mtamodle dUML 1.3 restant dans un cadre normalis. Il sagit en particulier des strotypes et des contraintes. Les premiers, qui forment des mta-classes dUML, tendent son vocabulaire alors que les contraintes permettent lutilisateur dajouter ou de modier la smantique des lments du modle.

2.1.2

Description des diagrammes dUML 1.x

UML permet donc de visualiser un systme ; plus prcisment, il a t conu comme un langage de modlisation visuel plutt quun langage de programmation visuel. Il sarticule autour de neuf diagrammes ; on distingue gnralement les vues structurelles (structure diagrams), plutt statiques, des vues comportementales (behavior diagrams), plutt dynamiques, comme illustr sur la gure 2.2. Nous donnons ici un rapide aperu de chaque diagramme, en illustrant par un exemple ceux qui sont le plus mis en uvre.

Fig. 2.2 Hirarchie des diagrammes UML 1.x

2.1. LE LANGAGE UML

21

Diagrammes de structure Diagramme de classe Il reprsente les classes, les interfaces, les collaborations et leurs relations (cf. gure 2.3). Cest lun des diagrammes les plus utiliss, car il donne une vue synthtique et statique des lments mis en jeu dans le modle du systme.

Fig. 2.3 Diagramme de classe

Diagramme dobjet Il dcrit un ensemble dobjet et leurs relations entre eux ; tout comme le diagramme de classe, il donne une vue statique des processus mais les illustre sur les instances concrtes des classes. Diagramme de composants Le diagramme de composants dcrit lorganisation des composants et leurs interactions travers des interfaces bien dnies ; ce diagramme permet de reprsenter limplmentation statique du systme. Diagramme de dploiement Il reprsente la disposition physique du systme, et en particulier le dploiement de la couche logicielle sur la couche matrielle, comme illustr gure 2.4.

Fig. 2.4 Diagramme de dploiement

22

CHAPITRE 2. LES LANGAGES DE MODLISATION UML ET SYSML

Diagrammes de comportement Diagramme de cas dutilisation (Use Case diagram) Ce diagramme modlise les interactions entre le systme et ses utilisateurs ou, plus gnralement, son environnement. Il dnit les comportements, les exigences et les contraintes sous la forme de scnarii (cf. gure 2.5).

Fig. 2.5 Diagramme de cas dutilisation

Diagramme dactivit Il montre les ux dactivits du systme et peut prendre en compte des comportements parallles, ce qui permet de dcrire des comportements o des objets collaborent travers plusieurs cas dutilisation (cf. gure 2.6). Ce diagramme est largement inspir des EFFBD, prsents au chapitre prcdent [Boc03].

Fig. 2.6 Diagramme dactivit

Diagramme dtats-transitions (Statecharts diagram) Ce diagramme dcrit le comportement de systmes ractifs en mettant en vidence les squences dvnements auxquels peut ragir un objet, ainsi que les comportements induits. Diagramme de squence Ce diagramme dinteraction dcrit la collaboration entre les lments du modle sur un scnario, dans un perspective temporelle : il reprsente les squences de messages changs entre les objets sur une ligne chronologique (cf. gure 2.7).

2.1. LE LANGAGE UML

23

Fig. 2.7 Diagramme de squence Diagramme de collaboration Ce second diagramme dinteraction met laccent sur les ux de donnes changes par les objets, en reprsentant les objets, leurs relations et les ux de messages. La smantique des dirents diagrammes est dcrite de faon essentiellement textuelle et non formelle. De plus, les diagrammes sont rarement tous employs en mme temps : ainsi, les problmatiques danalyse des exigences (requirement analysis) sont gnralement modlises laide des quatre diagrammes de cas dutilisation, de classe, dactivit et dtats-transitions. La conception de systme fait quant elle appel aux diagrammes de classe, de squence, de composants, dtats-transitions et de dploiement.

2.1.3

Limites dUML 1.x, description et smantique dUML 2.0

Les principaux reproches faits au langage UML sont le nombre jug trop important de diagrammes, la dicult matriser tous les aspects modliser et labsence de smantique rigoureuse. De plus, certains diagrammes semblent encore insusants pour intgrer des aspects de modlisation pourtant ncessaires la description du modle. titre dexemple, le diagramme de dploiement ne permet pas de modliser les systmes hirarchiss au del dun certain niveau de dtail [HTM04]. De mme, les diagrammes de cas dutilisation sourent de quelques insusances : impossibilit de dcrire les exigences comportementales, les performances, les interruptions de squence mises par lutilisateur, ou les rplications, pourtant au cur du fonctionnement de nombreux systmes distribus [ST05, Ski02]. Enn, UML 1.x ne permet pas le dveloppement des systmes bas sur les composants (Component-based development) ni la spcication de composants ou darchitectures pour des applications temps-rel [ST05]. Cest an de surmonter certaines de ces limites et de satisfaire dautres besoins exprims par la communaut des utilisateurs dUML qu t dveloppe en 2004 la version 2.0 du langage de modlisation. Les principales amliorations sont les suivantes : intgration du dveloppement bas sur les composants avec la modication du diagramme des classes et la cration de diagrammes de package et de structure composite (dcrits plus bas) ; dcomposition hirarchique de la structure et du comportement ; dveloppement de larchitecture par niveaux pour une implmentation incrmentale ecace.

24

CHAPITRE 2. LES LANGAGES DE MODLISATION UML ET SYSML

Cinq diagrammes ont t ajouts et la plupart des diagrammes dj existants ont t modis, comme indiqu sur la gure 2.8 2 .

Fig. 2.8 Modications des diagrammes UML 2.0 par rapport ULM 1.5 [ST05] Le diagramme des packages groupe les lments du modle dans des units englobant une ou plusieurs classes et montre leurs interactions. Le diagramme de structure composite montre quant lui les dtails, constructions et relations lintrieur du systme en dcomposant hirarchiquement les objets. Le diagramme dtats-transitions protocole (Protocole State Machine diagram), souvent intgr au diagramme dtats-transitions dont il drive, se focalise sur le protocole des oprations, sans dcrire le comportement de lobjet. Le diagramme gnral dinteraction (Interaction Overview diagram) opre une synthse des diagrammes dactivit et de squence ; il met laccent sur les vnements plutt que sur les actions. Enn, le diagramme de timing dcrit les changements dtat dun objet dans une priode donne, en mettant en vidence les contraintes temporelles ; il mentionne galement les messages modiant ltat de lobjet.

2.1.4

Quelques limites dUML 2.0

Outre le nombre trs lev de diagrammes, le langage soure encore de limitations, tout spcialement pour un emploi dans les problmatiques dingnierie systme. En premier lieu, il existe des incohrences de syntaxe et de smantique entre les diagrammes, en particulier entre les diagrammes de classe et de composants. Dune manire gnrale, cette smantique est dailleurs mal dnie et non formalise. En outre, UML ne peut encore dcrire compltement et de faon satisfaisante les exigences et les activits. Enn, les diagrammes de cas dutilisation sont mal intgrs aux autres diagrammes [ST05]. Par ailleurs, il existe de nombreux outils implmentant UML 2.0, comme Rhapsody (I-Logix), ARTiSANs Real-Time Studio (Artisan Software Tools) ou le plug-in UML2.0 dEclipse (Eclipse Project, IBM). Cependant, ces outils sont souvent incomplets ou, linverse, intgrent des diagrammes non standardiss. Dune manire gnrale, les lacunes smantiques du langage rendent variables limplmentation et linterprtation des dirents diagrammes dun outil lautre.
2

noter une erreur sur la gure : les diagrammes de package et de composants ont t inverss

2.2. LE LANGAGE SYSML

25

2.2
2.2.1

Le langage SysML
Historique

Plusieurs techniques ou mthodes ont t conues pour adapter le langage UML aux contraintes et applications de lingnierie systme (en particulier pour intgrer lanalyse des exigences) et contourner les limitations voques plus haut. Certains concepteurs ont choisi dutiliser des prols UML , i.e. de dnir et demployer des strotypes spciques leurs besoins. Cependant, les rsultats semblent peu satisfaisants, dautant que lutilisation de prols nest pas standardise. Dautres concepteurs ont choisi dutiliser deux outils dirents, un pour modliser les concepts propres lingnierie systme (tel DOORS de Telelogic) et un autre pour dvelopper le modle UML. Cette approche pose en particulier le problme de la cohrence entre les deux modles ainsi dnis. LOMG a ainsi lanc en mars 2003 un appel propositions (Request for Proposal) pour construire une version dUML adapte lingnierie systme. Le cahier des charges prcise que le langage doit permettre lanalyse, la spcication, la conception et la vrication de systmes complexes an damliorer la qualit des sytmes et la capacit changer des informations dingnierie systme entre les outils, tout en rduisant la distance smantique entre les disciplines dingnierie systme et logicielle [OMG03]. Une seule proposition technique a t dpose : il sagit du langage SysML (Systems Modeling Langage), cr par le consortium SysML (dont la socit Artisan Software Tools). La spcication a dj fait lobjet de plusieurs versions (0.9 en janvier 2005, 1.0a dans une version provisoire en avril 2006).

2.2.2

Description des diagrammes de SysML

La plupart des diagrammes dUML 2.0 sont rutiliss, certains avec des modications. Les diagrammes de communication, de dploiement, dobjets et dtats-transitions protocole ne sont pas explicitement employs. Enn, SysML introduit deux nouveaux diagrammes, le diagramme des exigences et le diagramme dquations paramtriques [HTM04, Boc05, Sys05]. Diagramme des exigences (Requirement diagram) Lintroduction de ce diagramme part de la constatation que tout projet dingnierie systme dbute par le cahier des charges et lanalyse des exigences. Usuellement, ces exigences sont exprimes dans un langage naturel, et leur intgration au modle est souvent dicile. Avec SysML, il est possible de reprsenter ces exigences dans un diagramme spcique, dont une illustration est donne gure 2.9. Elles peuvent tre organises dans des packages, drives en sous-exigences, dployes sur des lments spciques du modle, relies un script de test qui les vriront, etc. Les exigences complexes peuvent tre modlises au moyen de strotypes, pour modliser en particulier des contraintes oprationnelles, fonctionnelles, physiques, dinterface, de contrle, de performance, etc. Elles peuvent galement tre reprsentes sous forme darbre, an den dgager la hirarchie. Le diagramme des exigences ne se veut pas un remplaant des outils externes de vrication des exigences mais plutt une interface entre ces outils et les modles UML pour

26

CHAPITRE 2. LES LANGAGES DE MODLISATION UML ET SYSML

Fig. 2.9 Diagramme des exigences dun vhicule [HTM04] assurer la traabilit des exigences dans le modle. Diagramme dquations paramtriques (parametric diagram) Ce diagramme est typiquement employ pour modliser les proprits des lments du systme et les relations entre elles, sous un formalisme mathmatique. Le modle paramtrique peut comporter des quations direntielles, des expressions logiques telles que {when Y = 7 or X < 1} ou des contraintes du type {Y < X + 3}, exprimes dans un langage spcique ou dans un langage de programmation.

Fig. 2.10 Diagramme dquations paramtriques dun projectile balistique [HTM04] Un exemple est donne gure 2.10 ; ce diagramme permet de modliser des proprits utilises par la suite en analyse de performance, abilit, scurit, cot, etc.

2.3. VRIFICATIONS FORMELLES SUR LES LANGAGES UML ET SYSML

27

Modication des diagrammes dactivit et intgration des EFFBD De nombreux ajouts ont t faits au diagramme dactivit dUML 2.0, en particulier le traitement du ux de contrle comme ux de donnes, ce qui en augmente les applications. Ainsi, le ux de contrle peut non seulement dclencher les actions (comme en UML 2.0) mais galement les suspendre, les stopper ; il est de plus possible de dclarer des actions comme non interruptibles. Enn, un strotype EFFBD a t dni an de rapprocher les diagrammes dactivit et les EFFBD. En eet, sous certaines contraintes 3 , les diagrammes dactivit peuvent tre traduits en EFFBD. Cependant, cette partie est encore en cours de normalisation.

2.3
2.3.1

Vrications formelles sur les langages UML et SysML

Utilisation dun prol UML rseaux de Petri : UML/PNO

Lapproche UMPL/PNO 4 a t labore an de proposer un support smantique prcis aux diagrammes dynamiques dUML, de manire mettre en uvre ecacement ce langage pour lutiliser dans des spcications de systmes temps-rel. lorigine conue comme une mthode de dveloppement des systmes embarqus, elle a pu trouver des applications dans laide la conception, la validation et la vrication ou lvaluation de performances [PB02]. Lapproche est base sur UML, pour la description graphique des modles, et les objets rseaux de Petri [Del03]. Elle consiste dcrire certains aspects comportementaux des objets (tels que les spcications ou les contraintes temporelles) laide des RdP. Enn, lvaluation des performances temporelles telles que les temps dexcution ou les temps de rponse se fait sur les RdP au moyen de la logique linaire (LL) de Girard [Gir87]. Le choix de cette logique pour tudier la vrication des contraintes temporelles est principalement motive par le fait que lexploration des RdP temporels sappuyait au moment de la conception de la mthode sur le graphe dtats quivalents [BD91], conduisant lexplosion combinatoire du nombre dtats.

Fig. 2.11 Exemple de diagramme de squence avec UML/PNO La mthode consiste tablir un diagramme de contexte prsentant le systme et son environnement, puis dcrire textuellement chaque entit formant cet environnement ainsi que la nature de son interaction avec le systme. chaque sous-ensemble stimuli/rponse
par exemple, toutes les branches divergentes (forks) du diagramme dactivit doivent avoir une branche convergente (join) correspondante 4 Petri Net Object
3

28

CHAPITRE 2. LES LANGAGES DE MODLISATION UML ET SYSML

correspondent alors des contraintes temporelles, modlises par des diagrammes de squence an de faciliter le dialogue avec lutilisateur (cf. gure 2.11). Enn, les RdP temporels correspondants aux dirents objets sont dnis et fusionns, ce qui permet ensuite lanalyse par la LL. Celle-ci fournit en particulier les valeurs symboliques des dures dexcution des classes de scnarii dexcution. Cette mthode permet ainsi dobtenir des rsultats intressants en terme de vrication, mais reste complexe mettre en uvre, dautant quelle sappuie sur la technique de la LL, encore jeune. De plus, elle ne permet pas par exemple de prendre en compte directement les problmes de synchronisation dhorloge ou lindterminisme d des conits.

2.3.2

Autres travaux

De nombreux autres travaux rcents se sont intresss ces problmatiques de vrications et de validations formalises sur UML et les langages drivs ; citons en particulier [OGO04] et [ADHS06]. Le premier article dcrit la mthode employe pour valider des modles (dnis sur dialecte UML permettant dexprimer des contraintes temporelles) grce un outil dvelopp au laboratoire Verimag et sappuyant sur des automates temporiss. Dans le second article, les auteurs proposent une dmarche base sur des mthodes formelles comme le model-checking pour la vrication et la validation de modles dingnierie systme ou logicielle, dcrits au moyen dUML 2.0 ou de SysML. Par ailleurs, il convient de noter que la version prliminaire de la spcication SysML 1.0 mentionne que les les problmatiques de vrication et de validation (non encore traites dans la version 0.9) sont partiellement gres et quelles devraient tre totalement implmentes partir de la version 2.0.

Chapitre 3

Le langage de description darchitecture AADL

Le langage UML, prsent au chapitre prcdent, ore un outil de modlisation relativement puissant et universel, ce qui en fait un langage rpandu en modlisation et conception de logiciels ou mme de systmes matriels. Il illustre tout fait le paradigme mergent de la conception oriente modle (model-driven design). Cependant, limprcision de sa smantique, la complexit de mise en uvre de ses nombreux diagrammes et son incapacit prendre compltement en compte les aspects dynamiques dun systme ou exprimer ses exigences en font un outil incomplet. Cest pour pallier une partie de ces insusances qua t cr rcemment le langage de description darchitecture AADL (Architecture Analysis and Design Langage).

3.1

Introduction

Le point de dpart dAADL est MetaH, un langage de description darchitecture dvelopp par Honeywell Technology Laboratories en 1991. AADL est un standard international, prpar par la division Avionics Systems de la SAE (Society of Automotive Engineers), en rponse au cahier des charges dni par le document SAE ARD 5292, Requirements for the Avionics Architecture Description Language. Ce standard repose sur un langage extensible de conception et danalyse darchitectures de systmes embarqus temps-rel ; il comporte cinq aspects principaux : le langage AADL proprement dit, aussi bien graphique que textuel, permettant par sa smantique prcise de modliser les architectures logicielles des systmes embarqus ainsi que leurs plateformes matrielles dexcution ; un format dchange bas sur XMI/XML pour linteroprabilit et la communication des modles entre les dirents outils et les applications maison ; des prols UML 1.4 et UML 2.0 qui permettent de grer les aspects temps-rel, absents dUML ; une annexe de modle derreur (Error Model Annex) pour la modlisation des dfaillances et lanalyse de risque ; une annexe dnissant la conformit avec les langages Ada95 et C ainsi que les interfaces avec les programmes applicatifs. Le langage AADL a fait lobjet dune norme publie en novembre 2004 [SAE04] ; les autres lments mentionns ci-dessus sont en cours danalyse ou de publication. La version 29

30

CHAPITRE 3. LE LANGAGE DE DESCRIPTION DARCHITECTURE AADL

2.0 est prvue pour le printemps 2006. Les principales fonctionnalits dAADL sont : reprsentation de systmes embarqus par une architecture de systmes oriente composants ; modlisation de linteraction entre composants sous forme de ux, dappels de service et daccs partags ; modlisation de lexcution des tches et de la communication au moyen dune smantique temporelle prcise ; reprsentation des modes oprationnels et des congurations de tolrance aux fautes. Les champs dapplication viss sont assez varis, ils concernent majoritairement les domaines de lembarqu temps-rel comme lavionique, llectronique automobile ou la robotique. Comme nonc plus haut, AADL est un langage de conception et danalyse : il dcrit non seulement les architectures logicielle et matrielle dun systme mais galement son comportement dynamique et plusieurs aspects lis aux performances et la criticit (comme les contraintes temporelles, lordonnanabilit, la scurit etc.). Enn, si AADL na pas t dni autour dun outil logiciel particulier, il est prcis dans la norme que les logiciels candidats doivent proposer un module de gnration automatique de code source partir des modles AADL, pour en permetttre lexcution.

3.2

Le langage AADL

Une spcication AADL est une suite de dclarations AADL globales et de dclarations AADL. Les premires, donnant une vue gnrale du systme, comprennent les spcications de packages (classication des dclarations) et les dclarations densembles de proprits (property set declarations). Les secondes dnissent les lments suivants : types de composants, permettant la spcication dinterfaces en terme dlments dinterface (features), de spcications de ux (ow) et de proprits ; implmentations des composants, spciant la structure interne en terme de : sous-composants ; connexions entre les lments dinterface des sous-composants ; ux traversant une squence de sous-composants ; modes reprsentant les tats oprationnels ; proprits ; types de groupes de ports ; bibliothques dannexes. Notre propos nest pas de donner une liste exhaustive des lments disponibles dAADL et de leur smantique. Nous donnons ainsi dans la suite de cette partie une brve description des principaux composants, lments dinterface et proprits, sans en donner systmatiquement leur reprsentation graphique. En ce qui concerne la smantique temporelle et discrte des modles AADL, elle est dnie de faon prcise laide dune notation proche des automates hybrides hirarchiques. Elle inclut ainsi la notation des automates dtats nis hirarchiques, des variables relles pour reprsenter le temps ou des paramtres variant temporellement, des gardes sur les transitions et des invariants sur les tats, pour expliciter les conditions de changement dtat. Ces dirents aspects sont illustrs gure 3.1.

3.2. LE LANGAGE AADL

31

Fig. 3.1 Smantique temporelle et discrte dAADL : exemple de notations

3.2.1

Composants AADL

Les composants sont au cur de la description AADL ; comme mentionn plus haut, ils sont dnis par leur interface (dnition des types de composants) et leur implmentation 1 . Il existe plusieurs catgories de composants (cf. gure 3.2) : logiciels (software components) : threads, donnes, processus (espace mmoire pour lexcution des threads), groupe de threads, sous-programmes ; matriels (execution platform component) : processeurs (micro-processeurs et ordonnanceurs), mmoires, bus, appareils (devices, composants dont on ne connat pas la structure interne, tel un capteur) ; mixtes : systmes

Fig. 3.2 Classication des composants AADL [Til05] Les composants sont hirarchis, composs, interconnects et extensibles. Un exemple de dclaration de composant est donn gure 3.3.

3.2.2

lments dinterface (features)

Les lments dinterface permettent de spcier la manire dont un composant va sinterfacer avec les autres. Il existe quatre catgories dlments : les ports ; les accs un sous-composant ; les sous-programmes ; les paramtres.
1

noter quil est possible pour un mme composant davoir plusieurs implmentations

32

CHAPITRE 3. LE LANGAGE DE DESCRIPTION DARCHITECTURE AADL

Fig. 3.3 Dclaration de composant AADL Les ports reprsentent une interface de communication pour changer des donnes ou des vnements entre composants. Ils peuvent tre entrants (in), sortants (out) ou bidirectionnels (in out). Ils peuvent galement faire transiter des donnes (data port), des vnements (event port) ou lensemble des deux (event data port). Laccs un sous-composant est employ lorsquun composant requiert (requires) ou quil fournit (provides) un accs un sous-composant (par exemple un processeur et un bus). On peut ainsi exprimer lobligation de brancher un composant avec un autre pour obtenir un systme cohrent. Un sous-programme reprsente quant lui un point dentre dexcution du code source qui opre sur un composant-donne (data subprogram) ou un point dentre pour un appel de procdure distance (server subprogram). Un paramtre reprsente alors un argument de sous-programme.

Fig. 3.4 Dclaration dlments dinterface en AADL

3.2.3

Proprits (properties)

Les proprits fournissent une information sur un composant, un lment dinterface, une connexion, un mode ou un appel de sous-programme. Elles sont dnies par un nom, un type et une valeur. Le type dune proprit peut tre un boolen, un entier, un rel, une chane de caractres, une plage de valeurs, une catgorie dlment, etc. Le standard prvoit un ensemble de proprits de base (cf. gure 3.5), mais il est possible de dnir de nouvelles proprits dans des ensembles de proprits (property sets).

3.3. OSATE, UN OUTIL AADL

33

Fig. 3.5 Exemple de proprits prdnies

3.3

OSATE, un outil AADL

OSATE (Open Source AADL Tool Environment) est un environnement logiciel constitu dun ensemble de plug-ins Eclipse. Il est dvelopp par le Software Engineering Institute (SEI), sous licence Common Public Licence partir dun mta-modle dAADL, lui-mme cr partir du plug-in EMF (Eclipse Modeling Framework) dEclipse. Il sagit dun outil en constant dveloppement, rgulirement mis jour ; la version actuelle est la 1.2.4, excutable avec Eclipse 3.1. La prochaine version devrait utiliser Eclipse 3.2 ; elle prvoit un dveloppement conjoint avec loutil TOPCASED, dont le dveloppement a t initi en 2005 par Airbus France [VFR+ 06]. OSATE ore une interface oriente utilisateur pour la manipulation des modles AADL. Il est pour linstant possible de grer ces modles sous leur forme textuelle ou au format XML ; la description graphique nest pas encore disponible. Les fonctionnalits principales sont les suivantes : un diteur textuel sensible la syntaxe (i.e. mise en valeur des expressions syntaxiques et aide contextuelle par pop-up) ; un diteur et visualiseur XML ; un parseur et vricateur smantique des modles textuels, la conversion vers le format XML et lintgration des rapports derreur ldition textuelle ; un dparseur AADL pour la conversion XML vers texte ; une gestion automatique des mises jour et modications entre les vues textuelles et XML ; une gestion du dveloppement par quipe laide dune interface de contrle de version. Plusieurs plug-ins danalyse et de traitement des modles sont par ailleurs inclus dans le logiciel. Il est par exemple possible de traduire les modles AADL au format MetaH, danalyser des proprits telles que les allocations de ressources ou de dterminer des temps de latence dans un modle, etc. Outre une aide en ligne assez complte, le logiciel propose plusieurs exemples de systmes, en particulier un modle issu de lavionique et dont un aperu est donn gure 3.6.

3.4
3.4.1

Le modle derreur dAADL

Introduction

Comme mentionn au dbut de ce chapitre, le standard SAE AADL prvoit une annexe de dnition des modles derreur, an de prendre en compte des lments tels que la tolrance aux fautes ou lanalyse de risque. Ce document est en cours de standardisation ; il doit tre publi dans la prochaine version de la norme.

34

CHAPITRE 3. LE LANGAGE DE DESCRIPTION DARCHITECTURE AADL

Fig. 3.6 Exemple de modlisation sous OSATE Ce modle derreur doit permettre lanalyse qualitative et quantitative des paramtres de abilit. Pour cela, il dnit un sous-langage organis autour de bibliothques qui permettent de dclarer les modles derreur. Plus prcisment, lannexe prvoit que lon puisse gnrer des modles de abilit classiques tels que les chanes de Markov ou les arbres de dfaillance. Par ailleurs, lannexe ne mentionne pas la possiblit de gnrer des RdP temporels ou stochastiques.

3.4.2

Dmarche dvaluation de la abilit avec AADL

Quelques auteurs se sont dj intresss aux problmatiques de vrication sur des modles dnis avec AADL ; nous prsentons dans cette partie une synthse des travaux prsents dans [Rug05]. La mthode propose est organise autour de quatre tapes principales, illustres gure 3.7 : modlisation de larchitecture avec AADL ; modlisation du comportement du systme en prsence de fautes ; construction dun modle formel analytique GSPN (cf. plus bas) de abilit ; traitement du modle GSPN par validation syntaxique et smantique puis valuation des mesures de abilit, laide doutils ddis. La mthode se base en particulier sur les RdP stochastiques gnraliss (Generalized Stochastic Petri Nets, GSPN), introduits par [Mol82], o les transitions peuvent soit tre franchies instantanment, soit avec une dure suivant une loi probabiliste. Ces GSPN permettent dans un premier temps une vrication structurelle du systme, ce qui facilite ensuite la gnration de chanes de Markov plus complexes, sur lesquelles sont menes les

3.4. LE MODLE DERREUR DAADL

35

Fig. 3.7 Mthodologie gnrale tudes de abilit. Les deux tapes centrales sont illustres sur un exemple simple, pour lequel deux composants logiciels sont en communication, lun tant compltement dpendant de lautre (en particulier, il tombe en panne si celui dont il dpend tombe en panne), comme illustr gure 3.8.

Fig. 3.8 Architecture AADL du systme

Modlisation du comportement en prsence de fautes Il sagit dune dmarche itrative : on modlise dabord le comportement de chaque composant en prsence derreurs (internes) et les vnements qui permettent la rparation . On modlise ensuite les dpendances entre les composants, ce qui permet dintgrer pour chacun son comportement face aux dfaillances dautres composants.

Fig. 3.9 Modle derreur

36

CHAPITRE 3. LE LANGAGE DE DESCRIPTION DARCHITECTURE AADL

Concrtement, un modle derreur est spci au moyen dun error model type et dun ou plusieurs error model implementations (cf. gure 3.9). Le premier dclare les tats derreur, les vnements et les propagations ; le second dnit les transitions entre les tats derreur et les caractristiques stochastiques des vnements causant les erreurs. Construction dun modle GSPN Il est obtenu partir du modle derreur par application de rgles de transformation, en suivant une dmarche incrmentale. Ainsi, les tats derreur et les transitions dclenches par les vnements derreur deviennent respectivement les places et les transitions du rseau de Petri. Les transitions dclenches par la propagation derreurs sont ensuite intgres au rseau global, comme illustr gure 3.10. Il convient de noter que cette transformation peut rapidement devenir complexe ds que plusieurs composants sont mis en jeu.

Fig. 3.10 Modle GSPN rsultant Lavantage principal de cette mthode est quelle permet dutiliser des outils dj existants pour lanalyse des GSPN. Elle cherche de plus allger la tche dvaluation des mesures de abilit en cachant la complexit des modles analytiques. Les rsultats semblent prometteurs ; cependant, lutilisation dune telle mthode prsuppose une bonne connaissance dAADL, langage encore jeune et incomplet, ce qui pose (comme avec UML et SysML) le problme de la formation des concepteurs des systmes vrier.

Chapitre 4

La mthode danalyse et de conception Sagace

Les trois grandes familles de descriptions prsentes dans les chapitres prcdents proposent des outils de modlisation des systmes, aussi bien issus de problmatiques de lingnierie systme que du monde purement logiciel ou de linformatique embarque temps-rel. Cependant, elles norent pas proprement parler de mthodologie de conception, permettant davoir une vue synthtique du systme. Cest pourquoi nous avons choisi de prsenter dans ce chaptire la mthode Sagace, qui ore aussi bien une mthodologie que des outils de description des architectures de systmes.

4.1
4.1.1

Introduction
Historique

Conue lorigine pour aider la modlisation du rle de loprateur dans la conduite de processus complexes, comme la gestion de racteurs neutrons rapides, la mthode Sagace a t dveloppe partir de 1993 par Jean-Michel Penalva, au Laboratoire dIntelligence Articielle de Marcoule du CEA [Pen94, Pen97]. Cette mthode de modlisation systmique sinspire des travaux de Jean-Louis Le Moigne et de La thorie du systme gnral [Moi77]. Elle sarticule autour de trois grands principes : une dmarche de modlisation ; une reprsentation par points de vue (la matrice des neuf points de vue) ; un langage graphique de modlisation. Si cette mthode a fait lobjet de relativement peu de publications, elle a nanmoins t depuis 1997 au cur de nombreux projets industriels importants [Pen06] : CEA : conception et analyse dinstallations de retraitement ; EDF : capitalisation des connaissances sur des systmes de conduite ; SNCF : tude dun systme de transport combin ; Arospatiale (EADS) : analyse de processus de conception davion. Nous donnons ici un aperu de la mthode, illustre ensuite par lexemple de la modlisation dun lave-linge domestique, inspir de [Mei98]. 37

38

CHAPITRE 4. LA MTHODE DANALYSE ET DE CONCEPTION SAGACE

4.1.2

Dmarche de modlisation

La dmarche Sagace consiste tudier le systme en plusieurs tapes, ltude devant tre mene de faon itrative, an daboutir une modlisation complte du systme. Les direntes tapes mettent en avant les lments suivants : contexte : problmatique et systme englobant (environnement) ; projet : nalit, mission, objectifs (concrets), enjeux ; tude : acteurs (parties prenantes ou stakeholders), moyens, dlais, documentation ; produit : description du produit, justications des choix ; tude systme : recadrage du systme dans son environnement, contraintes satisfaire. Une fois ces lments clairement identis, on peut ensuite projeter le systme ainsi dcrit dans la matrice des neuf points de vue, dcrite ci-dessous.

4.2
4.2.1

Les lments de modlisation de Sagace

Matrice des neuf points de vue

La matrice Sagace combine la description du systme selon trois visions avec une description selon direntes perspectives temporelles. Les trois visions, qui correspondent aux lignes de la matrice, sont les suivantes : vision fonctionnelle (praxologique) : ce que fait le systme par rapport son environnement ; vision organique (ontologique) : ce quest le systme ; vision oprationnelle (tlologique) : ce que dcide le systme pour remplir la mission. Les perspectives temporelles, correspondant aux colonnes de la matrice, sont gnralement au nombre de trois 1 ; elles traduisent les principales proprits mises en jeu et les caractristiques attendues pour chaque domaine : perspective achronique : action performances (actions rexes) ; perspective synchronique : fonctionnement stabilit (tactiques) ; perspective diachronique : transformation intgrit (stratgies).

Fig. 4.1 Matrice Sagace [Mei98]

la 3e colonne peut-tre ddouble, voire triple pour reprsenter des volutions divers horizons temporels [Mei98]
1

4.2. LES LMENTS DE MODLISATION DE SAGACE

39

On obtient alors la matrice reprsente gure 4.1. Il est possible de regrouper les lments selon trois niveaux de reprsentation : fonction (1) : activits imposes par les missions ; structure (2, 4 et 5) : traduction de limbrication entre les lments du systme et ses activits ; comportement (3, 6, 7, 8 et 9) : transitions entre les tats fonctionnels, structurels ou stratgiques, couples des dcisions dajustement, dadaptation et danticipation. chaque case correspond un ou plusieurs diagrammes, dnis laide du langage prsent ci-dessous.

4.2.2

Le langage Sagace

Le langage idographique de Sagace sarticule autour de trois objets, les processeurs (rectangles), les ux ou les relations (ches) et les observateurs (ellipses, non reprsents ici). Ces objets sont mis en uvre sur trois types de diagrammes : diagramme de transition : il marque les ux de Matriaux / nergie / Information (MEI), voir gure 4.2 gauche ; diagramme dinteraction : il traduit les relations vnements/conditions (cf. gure 4.2 droite) ; diagramme de couplage : il traduit les inuences entre les lments du systme (ce diagramme tant peu utilis, nous ne le reprsentons pas ici).

Fig. 4.2 Diagrammes de transition (gauche) et dinteraction (droite) Les diagrammes ont une syntaxe unique, inspire de la mthode de modlisation fonctionnelle SADT 2 : dans le cas des diagrammes de transition, les ux entrant arrivent gauche des processeurs, les ux sortant partent de la droite et les ux de contrle arrivent sur le dessus des processeurs. Les diagrammes dinteraction reprsentent les transitions entre les processus, une transition tant conditionne par des informations de rsultat (IR) et par des informations de commande (IC). En sortie de la transition sont indiques les conditions de dmarrage du processus aval. La smantique, quant elle, est spcique chaque case. Par exemple, les processus reprsentent des fonctions, des activits ou des modes dans la vision fonctionnelle (premire ligne de la matrice), des organes dans la vision organique et des tches dcisionnelles en vision dcisionnelle.
2

Structured Analysis & Design Technique

40

CHAPITRE 4. LA MTHODE DANALYSE ET DE CONCEPTION SAGACE

4.3

Exemple de mise en uvre : modlisation dun lave-linge

Nous avons volontairement simpli cet exemple an de ne prsenter que la matrice des neuf points de vue et trois illustrations des diagrammes Sagace. Ltude mene selon la dmarche prsente dans ce chapitre fait apparatre en particulier les points suivants : nalit : la machine doit assister lutilisateur dans le lavage du linge domestique ; missions : la machine doit proposer les fonctionnalits de remplissage, vidange, chauffage, etc. ; limites du systme : le tri, le chargement et le dchargement sont la charge de lutilisateur ; ux entrants (reprsents gauche de la matrice) : linge sale, eau propre, dtergents, nergie ; ux sortants ( droite de la matrice) : linge propre, eau use ; exigences strictes (contraintes, au-dessus) : intgrit du linge, scurit de lutilisateur ; exigences souples (attentes, au-dessous) : propret du linge, faible consommation dnergie, etc.

Fig. 4.3 Matrice Sagace dun lave-linge domestique

Fig. 4.4 Diagramme de transition du processus Lanalyse conduit la matrice prsente gure 4.3. Les diagrammes de transition et dinteraction de la case 2 sont dtaills gures 4.4 et 4.5.

4.4. CONCLUSIONS SUR LA MTHODE SAGACE

41

Fig. 4.5 Diagramme dinteraction du processus

4.4

Conclusions sur la mthode Sagace

Conue comme un moyen danalyse, de conception et de partage des connaissances pour les quipes dingnierie systme, la mthode Sagace est galement un moyen danalyse et dinvestigation des situations complexes pour les quipes dexploitation. Elle permet de rduire non pas la complexit dun systme mais celle de sa reprsentation. En particulier, elle permet de rdiger des cahiers des charges, de conduire des analyses fonctionnelles, de supporter des analyses de sret de fonctionnement et de mener des tudes statistiques et prospectives [DCG+ 00]. Sa matrice systmographique et la dmarche de modlisation aident identier, classer et partager les points de vue, alors que le langage dploy dans les dirents diagrammes permet de les explorer de faon quasi exhaustive. En contrepartie, la mthode semble assez lourde mettre en uvre. Nanmoins, elle peut sappliquer des systmes complexes quils soient techniques (ateliers de production), organisationnels (systme dinformation) ou stratgiques (systme dcisionnel). Par ailleurs, un outil logiciel a t dvelopp au CEA et lINSTN 3 pour la saisie des dirents diagrammes et de la matrice Sagace. Cependant, il ne semble pas que les modles obtenus soient excutables. Dautre part, le logiciel nest plus maintenu. Une formalisation de la mthode, mene par Claude Feliot (Alstom Transport) est en cours dtude. Elle sappuie sur les mthodes de transformation de prdicats et lenvironnement Coq, dvelopp lINRIA. Les proprits vries sont typiques du model-checking, voques en introduction (sret, vivacit, quit). Pour linstant, seul un outil informatique de reprsentation graphique a t dvelopp. Enn, la formalisation ne permet pas encore de prendre en compte des proprits temporelles sur les fonctions : seule les informations de squence entre les fonctions peuvent tre obtenues, mais il nest pas possible de modliser les dures dexcution des fonctions, par exemple.
3

Institut National des Sciences et Techniques Nuclaires

42

CHAPITRE 4. LA MTHODE DANALYSE ET DE CONCEPTION SAGACE

Conclusion
Nous avons prsent dans cette synthse bibliographique plusieurs langages ou mthodes de description darchitecture de systmes, utiliss en ingnierie des systmes ou en conception logicielle. Nous avons galement voqu la capacit de chacune de ces descriptions se prter des vrications formelles. Il ressort de cette tude que les diagrammes EFFBD prsentent de nombreux avantages tre utiliss dans ces problmatiques de description darchitectures. En eet, il sagit dune reprsentation trs usite en ingnierie systme, facile mettre en uvre, interprter et excuter. Si ces diagrammes ne capturent pas la structure physique du systme, ils en donnent nanmoins la vue fonctionnelle, tout en reprsentant les ux de donnes. Cependant, cet outil, bien que mature, na pas fait lobjet de dnition formelle, ce qui devrait rendre moins immdiate une traduction des ns de vrication vers des formalismes tels que les rseaux de Petri (classiques ou temporels). Par ailleurs, nous avons pu voir dans le chapitre 2 que les langages de modlisation UML et SysML (plus adapt aux problmatiques dingnierie systme) permettent certes de dcrire dirents aspects du comportement et de la structure du systme, mais ne sont pas vritablement satisfaisants. Ainsi, UML, dont la smantique reste souvent imprcise, nore pas de modlisation de toutes les structures rencontres en ingnierie systme, comme les rplications. Le recours des prols spciques est certes possible, mais ceux-ci sourent gnralement dun manque de cohrence et doutils logiciels adapts. Le langage SysML, dont la smantique ptit des mmes dciences que celle dUML, nous parat quant lui trop peu mature pour tre employ dans un outil industriel. Le langage AADL, pour sa part, nous semble trs prometteur pour orir une description able et rigoureuse des systmes vrier. Cependant, la mise en uvre de ce langage nous parat peu immdiate matriser. De plus, du fait de sa jeunesse , les outils utilisant ce langage sont encore pour la plupart au stade du dveloppement et nimplmentent pas tous les lments spcis dans la norme AADL. Enn, nous avons choisi de prsenter dans cette synthse la mthode Sagace dveloppe par Penalva. Il sagit en eet dun langage permettant de dcrire larchitecture fonctionnelle dun systme complexe, au mme titre que les diagrammes EFFBD ou les diagrammes de squence dUML. Au del de cet aspect, il sagit galement dune mthode de conception puissante, cependant handicape par sa complexit et sa richesse, et dont la visibilit est fortement rduite par le nombre limit de publications parues sur cette mthode.

43

Plusieurs objectifs pour le stage dapplication du Master de Recherche se sont ainsi dgags de cette tude : il sagira en particulier de produire une dnition formelle des diagrammes EFFBD (auquels on aura ajout les aspects temporels et la gestion des ressources) puis une traduction vers les rseaux de Petri temporels, qui en permettront la vrication formelle. Cette traduction devra en particulier respecter certaines proprits dquivalence, dont la bisimulation [SLRM06]. Lintgration de ces formalismes devra galement tre guide par un souci dencapsulation de la complexit, au sein dune bote noire prservant la facilit de lecture et de comprhension des EFFBD.

44

Bibliographie
[ADHS06] L. Alawneh, M. Debbabi, F. Hassane, and A. Soeanu. On the verication and validation of UML structural and behavioral diagrams. In Advances in Computer Science and Technology, 2006. [Alf76] M. Alford. A requirements engineering methodology for real-time processing requirements. In ICSE 76 : Proceedings of the 2nd International Conference on Software Engineering. IEEE Computer Society Press, 1976. M. Alford. Strengthening the systems/software interface for real-time systems. In Proceedings of the 2nd International Symposium of the National Council on Systems Engineering, 1992. B. Berthomieu and M. Diaz. Modeling and verication of time dependent systems using time Petri nets. IEEE Transactions on Software Engineering, 17 : 259273, 1991. C. Bock. UML 2 activity model support for Systems Engineering functional ow diagram. Systems Engineering, 6 : 249265, 2003. C. Bock. Systems engineering in the product lifecycle. International journal of product development, 2 : 123137, 2005.

[Alf92]

[BD91]

[Boc03] [Boc05]

[DCG+ 00] R. Dieng, O. Corby, A. Giboin, J. Golebiowska, N. Matta, and M. Ribire. Mthodes et outils pour la gestion des connaissances. Dunod, 2000. [Del03] J. Delatour. Contribution la spcication des systmes temps rel : lapproche UML/PNO. PhD thesis, Laboratoire dAnalyse et dArchitecture des Systmes (LAAS) Universit Paul Sabatier, 2003. US DoD. MIL-STD-499 : Engineering management, 1969. J.-Y. Girard. Linear Logic. Theoritical Computer Science, 50 : 1102, 1987. E. Herzog. An approach to Systems Engineering tools data representation and exchange. Linkpings Universitet, 2004. M. Hause, F. Thom, and A. Moore. The System Modelling Language (SysML). In 14th International Symposium of the INCOSE, 2004. IEEE. IEEE-1220 : Application & management of systems engineering process, 1994. INCOSE Technical Board. Systems Engineering handbook : a what to guide for all SE practitioners (version 2a). INCOSE, juin 2004.

[DoD69] [Gir87] [Her04] [HTM04] [IEE94] [INC04]

[KSR+ 98] A. Knutilla, C. Schleno, S. Ray, S. Polyak, A. Tate, S. Cheah, and R. Anderson. Process specication language : an analysis of existing representations. Technical report, National Institute of Standards and Technology, Manufacturing Engineering Laboratory, 1998. 45

46

BIBLIOGRAPHIE

[Lon95]

J. Long. Relationships between common graphical representations in System Engineering. In 5th International Symposium of the INCOSE, 1995. Mise jour juillet 2002 . J.-P. Meinadier. Ingnierie et intgration des systmes. Coll. tudes et logiciels informatiques. Herms, 1998. J.-L. Le Moigne. La thorie du systme gnral. Presses Universitaires de France, 1977. M.K. Molloy. Performance analysis using Stochastic Petri Nets. IEEE Transaction on Computers, 31 : 913-917, 1982. Iulian Ober, S. Graf, and Ileana Ober. Validation of UML models via a mapping to communicating extended timed automata. Lecture Notes in Computer Science, pages 127145, 2004. D. Oliver, T. Kelliher, and J. Keegan Jr. Engineering complex systems with models and objects. McGraw-Hill, 1997.
TM for

[Mei98] [Moi77] [Mol82] [OGO04]

[OKK97]

[OMG03] Object Management Group. UML Proposal, mars 2003. [PB02]

Systems Engineering Request For

M. Paludetto and A. Benzina. UML et rseaux de Petri : tude de cas et valuations temporelles. Journal Europen des Systmes Automatiss, 36 : 11551178, 2002. J.-M. Penalva. Sagace, la modlisation des systmes dont la matrise est complexe. In 2nd International Conference on Integrated Logistic and Concurrent Engineering. ILCE94, 1994. J.-M. Penalva. La modlisation par les systmes en situation complexe. Thse dUniversit, Paris XI-Orsay, 1997. J.-M. Penalva. La mthode Sagace. In cours dApproche Systme, cole Centrale Nantes, 2006. A.-E. Rugina. System dependability evaluation using AADL (Architecture Analysis and Design Language). In Rencontres Jeunes Chercheurs en Informatique Temps-Rel (RJCITR), septembre 2005. SAE Aerospace. Architecture Analysis & Design Language (AADL) SAE AS 5506, novembre 2004. http://www.aadl.info. J.F. Skipper. Assessing the suitability of UML for capturing and communicating systems engineering design models. Technical report, Vitech Corp., 2002.

[Pen94]

[Pen97] [Pen06] [Rug05]

[SAE04] [Ski02]

[SLRM06] C. Seidner, J.-P. Lerat, O. H. Roux, and M. Magnin. Vrication dynamique et formelle dun systme dcrit par son architecture fonctionnelle laide de rseaux de Petri temporels (TPN) : promesses et perspectives. In 4e confrence annuelle dingnierie systme (AFIS), mai 2006. [ST05] J. Shi and M. Trngren. An overview of UML2 and brief assessment from the viewpoint of embedded control systems development. Technical report, Mecatronics Lab, Dpt. of Machine Design, Royal Institute of Technology (KTH, Stockholm, 2005. SysML Partners. Systems Modeling Language (SysML) specication, version 1.0 alpha, novembre 2005. http://www.sysml.org.

[Sys05]

BIBLIOGRAPHIE

47

[Til05]

J.-F. Tilman. Prsentation dAADL. In Confrence de la Socit de llectricit, de llectronique et des Technologies de lInformation et de la Communication, avril 2005.

[VFR+ 06] F. Vernadat, P. Farail, A. Rossignol, C. Percebois, R. Vingerhoeds, and J.-P. Talpin. Le projet TOPCASED : a Toolkit in Open source for Critical Application & SystEm Development. In 4e confrence annuelle dingnierie systme (AFIS), mai 2006. [Vit00] Vitech Corp. COREsim User Guide, release 3.0, 2000. http://www.vtcorp. com/.