Construction incrémentale

Construction incrémentale
LGI2P Construction Incrémentale de Spécifications de Systèmes Critiques intégrant des Procédures de Vérification Présenté par: Jury Président: Rapporteurs: Examinateurs: Directeur de thèse: Encadrants: Hong-Viet Luong ABC - UPS Yves LE TRAON – IRISA – Telecom Bretagne Guy LEDUC – RUN – Université de Liège Rolan GROZ – LIG - INPG Christian PERCEBOIS – IRIT – UPS Anne-Lise COURBIS – LGI2P – EMA Thomas LAMBOLAIS – LGI2P – EMA Je tiens à remercier à messieurs Yves le Traon et Guy Leduc d’avoir d’accepter de rapporter ma thèse. Merci au jury d’accepter de participer à la soutenance de ma thèse. Merci au publique d’assister cette séance. J’ai le plaisir de vous présenter mes travaux de thèse intitulée « Construction Incrémentale de Spécifications de Systèmes Critiques intégrant des Procédures de Vérification » Construction incrémentale

Plan Introduction État de l’art Raffinement des machines d’états UML Relations de raffinement et d’implantation Contributions Implantation des relations de conformité Transformation des machines d’états en LTS Formalisation d’un cadre de construction incrémentale Raffinement d’architecture Conclusion Mon plan d’exposé comprends 4 parties. Premièrement, je vous présente l’introduction en donnant qqs définitions de base. Ensuite, c’est l’état de l’art de ma thèse. Dans cette partie vous présente en détail Construction incrémentale

Introduction Contexte: Aide à la conception de systèmes. Modélisation UML Méthodes Formelles Systèmes critiques,réactifs Cette thèse porte sur l'aide à la construction de machines d'états UML de systèmes critiques et réactifs avec les supports des méthodes formelles. Les méthodes formelles contribuent essentiellement à l'amélioration des critères de fiabilité, de disponibilité, de sécurité-innocuité et d'intégrité. Elles visent à limiter les défauts de spécification et de conception, en apportant à la fois des techniques visant à construire de manière correcte a priori, et des techniques de vérification pour analyser des failles a posteriori. Construction incrémentale

Introduction Contexte Systèmes critiques: si une défaillance peut conduire à des conséquences inacceptables en termes humains, économiques et environnementaux. Patriot: système de missile sol-air le cas d'échec du système missile sol-air Patriot à Dharan, en Arabe saoudite pendant la guerre du Golfe. Le missile Patriot n'a pas réussi à suivre et intercepter à un missile Scud irakien. L'interception échouée de Dharan avait été provoquée par une erreur de logiciel dans son système de coordination. Il s'avère que la cause était une erreur de calcul du temps depuis le démarrage de l'ordinateur en raison d'erreurs arithmétiques. Cette erreur entraine une dérivée un tiers de seconde qui correspond à une distance d’erreur 600m. Vingt huit soldats sont tués à cause de cette erreur. Une erreur de logiciel => 28 morts Construction incrémentale

Introduction Contexte Systèmes réactifs: un système réactif doit réagir à un environnement qui ne peut pas l'attendre, à la différence d'un système interactif qui communique de façon permanente avec son environnement chacun évoluant à sa propre vitesse Notre intérêt ne se limite pas à la conception de systèmes critiques et s'étend à une définition plus large de systèmes qualifiés de réactifs. Construction incrémentale

Introduction UML langage de modélisation visuelle unifié machine d’états UML Rumbaugh OMT Machine d’états UML Le langage UML est devenu un standard de fait en industrie. UML a été standardisé pour fusionner différents langages visuels de modélisation: la méthode Booch, OMT, les statecharts de Harel. Il a été conçu dans l'objectif d'être le plus général possible et se veut extensible afin de prendre en charge des contextes non prévus. La définition syntaxique et sémantique de ce langage est continûment développée. UML est largement reconnu et utilisé pour des applications variées telles que la modélisation, la documentation, la génération de code et le test. Les machines d'états d'UML ont été documentées dans la première version d'UML. Une machine d'états UML est présentée comme un diagramme d'états-transitions organisé hiérarchiquement permettant de modéliser des états composites, des états concurrents, des activités et des historiques, etc. Jacobson OOSE Booch Méthode de Booch Harel Machines d’états Construction incrémentale

Introduction Constat: difficulté de construction des machines d’états Manque de supports d'analyse, d'exploitation ou de vérification des modèles UML et des machines d’états Sémantique des machines d'états UML n'est pas suffisamment documentée et reste ambiguë Faiblesses du langage: manque de modularité, généricité Pas de méthodologie de construction des machines d’états À l'heure actuelle, les machines d'états UML sont difficiles à construire. Plusieurs raisons expliquent cette difficulté: il existe peu de méthodes d'aide à la construction des machines d'états UML, ce qui a pour conséquence qu'il existe peu d'outils commerciaux d'évaluation, de vérification et de génération de code à partir de machines d'états UML. la sémantique des machines d'états n'est pas suffisamment documentée et reste ambiguë. De plus, les machines d'états ne sont pas modulaires: on ne dispose pas d'opérateur de construction modulaire comme il en existe dans les langages de programmation ou de processus. Bien que les machines d'états soient un sous-ensemble du langage UML dont l'un des objectifs est d'être un support du concept orienté objet, elles ne possèdent pas réellement les principales caractéristiques attendues des objets telles que l'héritage, la généricité ou l'encapsulation. Construction incrémentale

Introduction Approche: Aide à la construction de machines d'états UML par une approche incrémentale. étapes progressives par ajout de détails et de comportements (approches descendantes et ascendantes) évaluations des modèles possibilité d’obtenir des versions intermédiaires exploitables S0 s1 Sn I1 I0 In Spécification, Abstraite, partielle complète détaillée vérification implantation construction, extension Cahier des charges En s'inspirant des démarches de raffinement classique mais aussi de pratiques industrielles telles que le prototypage, nous proposons une démarche plus pragmatique, que nous qualifions de démarche incrémentale. À la différence du raffinement en B, la démarche incrémentale part d'une spécification partielle dans laquelle seules quelques fonctionnalités (supposées essentielles) sont prises en compte, constituant ainsi un noyau initial. Le développement consiste à mener conjointement le développement des spécifications successives avec celui des modèles des implantations. Chaque implantation doit être conforme à sa spécification et également à la spécification de l'étape précédente. Les spécifications intermédiaires obtenues à chaque étape décrivent de nouvelles fonctionnalités ou comportements mais elles ne doivent pas dégrader les spécifications des étapes précédentes. Construction incrémentale

Introduction Notre approche: évaluer les modèles par comparaison. Cadre mono langage, sans expliciter les propriétés à vérifier Travail antérieur [Gou07] : la pertinence des relations de conformité dans un cadre incrémental est établie, mais mise en œuvre complexe Objectifs: Réalisations de ces relations ? Définir un cadre de construction incrémentale Nous ciblons notre étude sur la détection d'erreurs d'interaction telles que les inter-blocages et le refus. Dans un premier temps, nous considérons le problème de l'aide à la construction de machines d'états dans le cadre de l'élaboration d'un composant unique en interaction avec son environnement. Un travail antérieur a étudié des méthodes de vérification et de validation de ces modèles. Ce travail a posé les bases d'une démarche de \emph{construction incrémentale} de machines d'états UML. Il a mis en évidence la pertinence de l'utilisation de relations de conformité, préalablement définies pour le test, pour assurer la cohérence des modèles obtenus à différentes étapes des processus de construction. Ce travail reste une contribution théorique et aucune mise en oeuvre pratique n'a été proposée. L'objet de notre travail est de proposer des définitions plus précises de raffinement incrémental et d'en réaliser une mise en oeuvre. Construction incrémentale

Plan Introduction État de l’art Raffinement Machines d’états UML Contributions Implantation des relations de conformité Transformation des machines d’états en LTS Formalisation d’un cadre de construction incrémentale Raffinement d’architecture Conclusion Construction incrémentale

État de l’art Raffinement et vérification des machines d’états UML Il existe des travaux de vérification de la cohérence intra-modèles, inter-modèles[SMSJ03] Il existe des travaux de vérification a posteriori (Model checking) [LLM99,KM02] Mais pas de travaux relatifs à la construction incrémentale ni au raffinement. Pour la cohérence inter-modèles, plusieurs auteurs abordent la cohérence entre les diagrammes de séquence et les machines d'états. Van der straeten s'intéresse à la préservation de cohérence des modèles comportementaux (diagramme de séquences et machine d'états de protocole) dans le cadre de la restructuration de modèles (refactoring). La cohérence inter-modèles est fondée sur la préservation des traces de deux modèles. Dans un autre article de Van Der Straeten, les auteurs transforment les diagrammes de classes, les diagrammes de séquence et les machines d'états dans la logique de description pour vérifier la cohérence entre les différentes versions de ces diagrammes. La plupart des travaux de vérification des machines d'états sont basés sur les techniques de model checking. Lilius et Paltor ont proposé un cadre pour formaliser la sémantique opérationnelle d'une machine d'états UML et l'utiliser comme base de génération de code, de simulation et d'outils de vérification. Construction incrémentale

État de l’art Raffinement Notion informelle: Passage de l’abstrait au concret => ajout de détails + réduction de l’indéterminisme. Préserver les propriétés de l’abstraction Notion formelle Le raffinement est un moyen de construire de manière progressive des programmes corrects. Le raffinement est vu comme le passage de la spécification (ce que fait le logiciel) au programme (comment fait le logiciel) tout en préservant la correction des propriétés validées par rapport aux spécifications intermédiaires. Préserver les propriétés de l’abstraction sans expliciter les propriétés à vérifier Toute implantation du modèle raffiné est également une implantation de modèle abstrait q r a f p ) ( j i m g Construction incrémentale

État de l’art Raffinement: Toute implantation du modèle raffiné est également une implantation de modèle abstrait (Boiten, Leduc…) Méthode B Affaiblir les préconditions, renforce les postconditions Retirer de l’indéterminise dans les opérations. Ajouter de nouveaux détails, événements Préservation de l’invariant abstrait Algèbres de processus (CSP, CCS…) Raffinement en sémantique de traces (réduction de traces) Raffinement en sémantique d’échecs stable(réduction de l’indéterminisme) Raffinement en sémantique d’échecs divergence Construction incrémentale

État de l’art Déterminisme Définition: « si l'on effectue la même expérience deux fois sur un système déterminé, en commençant à chaque fois dans son état initial, alors nous nous attendons à obtenir le même résultat, ou comportement, à chaque fois » [Mil89] Importance de l’indéterminisme dans l’aide à la conception: Indéterminisme est un mécanisme d’abstration un système est déterministe si à tout instant, son comportement est entièrement déterminé par les événements qu'il perçoit ou qu'il a perçu en interaction avec son environnement. Construction incrémentale

État de l’art Relations d’implantation Spécification est une description de haut niveau du comportement souhaité d'un système Implantation est considérée valide si elle satisfait un ensemble de propriétés définies telles que la réduction des blocages, la réduction de l'indéterminisme Relation de conformité Construction incrémentale

État de l’art LTS quadruplet P: ensemble non vide d'états (ou processus) A: ensemble de noms d'actions relation de transitions p: état initial h P ; A ! p i P = { p,p1,p2,p3 } A = {a,b,c} p p1 p2 p3 a b c ! Les LTS sont des descriptions d'automates simples et abstraites, ne précisant ni si les actions sont en entrée ou en sortie (il n'y a pas de distinction entre événements et actions), ni dans quelles circonstances une action est préférable à une autre (il n'y a pas de garde), ni combien de temps leur exécution demande ou après combien de temps leur exécution sera déclenchée. Certaines actions peuvent-être des synchronisations du processus avec son environnement, ou la réception d'un signal transmis par l'environnement. Ces actions ne peuvent se produire que si l'environnement coopère. p 2 P Construction incrémentale

État de l’art Relations de conformité Ensemble de refus Ensemble d’acceptance R e f ( p ; ) = d X j 9 2 P a t r : 6 8 A c 1 ( p ; ) = d e f X j 9 2 a t r : O u " g R e f ( p ; ) = a b g ? c p p1 p2 p3 a b c τ A c 1 ( p ; ) = f g a ? b Construction incrémentale

État de l’art Relations de conformité Extension Réduction q c o n f p s i 8 2 T r ( ) : R e ; q c o n f p s i 8 2 T r ( ) : A 1 ; q e x t p s i T r ( ) c o n f q r e d p s i T ( ) t c o n f p τ b q r a c o n f c o n f b p1 p2 a r1 r2 a c r e d e x t q1 p3 p4 6 c o n f Construction incrémentale

Plan Introduction État de l’art Raffinement vs construction incrémentale Machines d’états UML Contributions Implantation des relations de conformité Transformation des machines d’états en LTS Formalisation d’un cadre de construction incrémentale Raffinement d’architecture Conclusion Construction incrémentale

Implantation des relations de conformité
Graphes d’acceptance déterministe obtenu par la déterminisation du LTS p chaque état du graphe contient deux informations: l’ensemble d’états correspondants l’ensemble d’acceptance après la même trace du LTS p A ( p ) = d e f h T ; L ! t i t : a c = f g s e p 1 b ; d 2 5 ? 3 4 6 p p1 p2 p3 b a c p4 p5 d p6 τ t t1 t2 t4 a b c d t3 Un graphe d'acceptance associé au LTS $p$ est un graphe déterministe obtenu à partir de $p$, où les noeuds sont étiquetés par leur ensemble d'acceptance. Rappelons que nous avons donné deux définitions de l'ensemble d'acceptance (cf. définitions~\refshowpage{AccDef1} et~\refshowpage{AccDef2}), la différence étant que la deuxième définition ne tient compte que des états stables. Pour l'analyse de conformité, on ne peut se restreindre à l'étude seule des états stables. Construction incrémentale

Théorème: Soient p,q deux LTS et leur graphe d’acceptance: . A ( p ) = h T ; L ! t i q U u S o i t = f h ; u j : a c g q r e d p , t % u q e x t p , - u Le théorème suivant permet de ramener le calcul des relations d'extension et de réduction à des simulations sur des graphes d'acceptance. La vérification de la relation d’extension (ou de réduction) est vérifiée par deux étapes: la simulation entre des graphes d’acceptance doit être vérifiée. Si elle est vérifiée, on vérifiiera l’inclusion d’ensemble d’acceptance entre les pair d’états simulés. Construction incrémentale

Soient p et q deux LTS, et leur graphe d'acceptance le graphe fusionné des graphes d'acceptance Algorithme de fusion est réalisable et linéaire A ( p ) = h T ; L ! t i A ( q ) = h U ; L ! u i M e r g ( A p ) ; q = h V L ! t u i M e r g ( p ; q ) = L'opération $\Merge$ a quelques propriétés intéressantes: -Commutativité -Le graphe fusionné est toujours la plus petite extension commune cyclique des graphes initiaux M e r g ( p ; q ) x t M e r g ( p ; q ) x t Construction incrémentale

Théorème: Soient p et q deux LTS Corollaire: Soient p et q deux LTS q c o n f p , r e d M g ( ; ) : q c o n f p , M e r g ( A ) ; % : Construction incrémentale

Évaluation de la complexité La déterminisation est PSPACE-complet La vérification de simulation est linéaire La fusion des graphes d’acceptance est linéaire Amélioration de la performance La minimisation observationnelle des LTS, nous permet d’avoir un temps de calcul raisonable le problème de la construction du graphe d'acceptance est un problème de déterminisation d'automates. Ce problème est PSPACE-complet avec une complexité temporelle qui est en général exponentielle tandis que les autres fonctions de l'algorithme de $\conf$ sont polynomiales On peut s'attendre à ce que la minimisation conduise à des LTS dont le nombre de n\oe uds ne pose pas de problème. A titre d'illustration, nous avons fait une minimisation de LTS pour lesquels le calcul de conformité ne pouvait se faire. Construction incrémentale

Comparaison de performance
Sans minimisation Avec minimisation Nb d’états Nb de transitions (s) 1318 3962 6,078 152 449 0,125 1924 5830 11,434 225 679 0,391 10617 33696 379 48 130 0,016 23887 77644 1522 93 266 0,047 130047 434156 66265 413 128 0,922 214975 720844 - 657 2069 2,625 Construction incrémentale

Formalisation d’un cadre de construction incrémentale
Relation de raffinement – confrestr Proposition [Led92] Soient p,q deux LTS, q confrestr p ssi q r a f p ) ( j i m g q c o n f p 8 2 T r ( p ) q , o n a L R e f ; . Construction incrémentale

Exemple de raffinement
b c τ p4 q q1 r r1 r2 6 o n f e d x t p p1 p2 a d τ p3 q q1 q3 b c o n f 6 r e x t r1 r2 r3 r4 Construction incrémentale

Implantation de la relation confrestr
Théorème: Soient p,q deux LTS, t,u leur graphe d'acceptance et v le graphe d'acceptance fusionné Soient p et q deux LTS, la relation red* est définie: M e r g ( t ; u ) = h V L ! v i . q c o n f r e s t p , v % u 8 v 2 ( V u ) ; p T : s t a e = o L'interprétation de ce théorème est la suivante: après avoir calculé la relation de conformité des LTS $q$ et $p$ par l'analyse de leur graphe d'acceptance respectif $u$ et $t$, si la relation de conformité est vérifiée, nous identifions l'ensemble des états $\Psi^{v}_{2}(u)$ du graphe fusionné $v$ simulant les états du graphe $u$. Ensuite, nous considérons le complément relatif de cet ensemble d'états avec l'ensemble d'états du graphe d'acceptance fusionné ($V -\Psi^{v}_{2}(u)$). Ceci permet d'identifier les états correspondant de $v$ dans le LTS $t$ par la fonction $\mc{T}(v')$. Puis, nous vérifions tous les états dans le LTS origine $p$ qui sont dans l'ensemble d'états associés $(\mc{T}(v')).states$. Si ces états sont tous des états finaux ($p'=stop$), la relation de conformité restrictive entre $q$ et $p$ est vérifiée. q r e d p = f c o n s t \ Construction incrémentale

Plan Introduction État de l’art Raffinement vs construction incrémentale Machines d’états UML Contributions Implantation des relations de conformité Analyse des machines d’états UML Formalisation d’un cadre de construction incrémentale Raffinement d’architecture Conclusion Construction incrémentale

Analyse des machines d’états UML
Transformation des machines d’états en LTS Association d’une sémantique LTS aux concepts UML Méthodes et signaux des interfaces fournies ne sont pas masquées. Signaux des interfaces requises du modèle de référence et du modèle à analyser ainsi que les méthodes privées sont masqués Construction incrémentale

Transformation des machines d’états en LTS
event1/action1 event1 action1 event1 1 event1 2 when(c)/a after delay/a when(c) after delay at time 4 i a i /action1 i action1 3 5 at time/a S’il n’y a pas de « else » i a i Ø [g]/a 6 [g] i e 7 e[g] 8 S’il n’y a pas de « else » 9 i e a noeud de composition noeud d’entrée ou sortie e [g]/a Construction incrémentale

Exploitation des relations de conformité
Cadre d’analyse ext… ? Transformation UML -> LTS Construction des graphes d’acceptance SM2 Ag(LTS1) LTS1 Ag(LTS2) Vérification des relations de conformité OK LTS2 Échec & traces conf,ext, red…. ? Analyse & correction LTS2* ) SM1 SM2* / accept stop τ h S3 S6 S7 c S4 La vérification des relations d'extension et de conformité entre deux machines d'états repose sur trois étapes - leur transformation en LTS; - la construction automatique des graphes d'acceptance associés aux LTS; - la vérification de la relation d'extension entre les graphes d'acceptance basée sur une relation de simulation et l'inclusion des ensembles d'acceptance. Construction incrémentale

Étude de cas Machine d’états de Phone Machine d’états de PhoneSpec do / listenNetwork Idle Waiting do / wait ConnectionRequest do / ring Ringing do / checkNetwork Connected Busy/Error pickUp hangUp dial [conn==busy] / busy [else] / error when(called) / call when(disconnected) [conn==ack] commIn / commOut do / listenNetwork Idle Waiting pickUp Connection Request do / checkNumber Checking WaitingConnection dial [con==err] / error conRefIn / busy Busy/Error conRec / conRefOut hangUp / disconReq do / checkNetwork Connected conAckIn conRec / call do / ring Ringing disconRec pickUp / conAckOut [else] / conReq commIn / commOut « conf ? » L'étude de cas porte sur la modélisation d'un téléphone en trois étapes: \item Modélisation de la spécification d'un téléphone simple $\mit{PhoneSpec}$, \item Modélisation d'une implantation $\mit{Phone}$, \item Modélisation de la spécification d'un téléphone à double appel $\mit{DoubleCallSpec}$. Construction incrémentale

Phone est-il conforme à PhoneSpec? 1ère étape : construction des LTS
LTS de PhoneSpec LTS de Phone conf ? Construction incrémentale

La relation de simulation et l’inclusion des ensembles
Phone est-il conforme à PhoneSpec? 2e étape : construction & fusion des graphes d’acceptance Graphe d’acceptance de PhoneSpec Graphe d’acceptance de Phone x0 x1 x2 x3 c o m I n p i k U h a g d l 4 5 1 6 2 3 c o m I n p i k U h a g d l n Graphe d’acceptance de la fusion 4 5 1 6 2 3 p i c k U h a n g o m I d l La relation de simulation et l’inclusion des ensembles sont vérifiées CONFORMITÉ DÉMONTRÉE Construction incrémentale

La relation de simulation et l’inclusion des ensembles
Phone est-il conforme à PhoneSpec? 3e étape : Calcul d’une relation de simulation des graphes d’acceptance Graphe d’acceptance de Phone Graphe d’acceptance de la fusion y4 y0 y5 y1 y6 y2 y3 c o m I n p i k U h a g d l w4 w0 w5 w1 w6 w2 w3 p i c k U h a n g o m I d l La relation de simulation et l’inclusion des ensembles sont vérifiées CONFORMITÉ DÉMONTRÉE Construction incrémentale

DoubleCall est-il une extension de PhoneSpec ?
Machine d’états de DoubleCall Machine d’états de PhoneSpec do / listenNetwork Idle Waiting do / wait Connection Request do / ring Ringing do / checkNetwork Connected Busy/Error pickUp hangUp dial [conn==busy] / busy [else] / error when(called) / call when(disconnected) [conn==ack] commIn / commOut do / beep Beeping Connected2 accept stop do / listenNetwork Idle Waiting do / wait ConnectionRequest do / ring Ringing do / checkNetwork Connected Busy/Error pickUp hangUp dial [conn==busy] / busy [else] / error when(called) / call when(disconnected) [conn==ack] commIn / commOut Raffinement ? Construction incrémentale

DoubleCall est-il une extension de PhoneSpec ?
LTS de DoubleCall LTS de PhoneSpec z4 z0 z5 z1 z6 z2 z3 h a n g U p i c k e t o m I s d l 1 2 3 c o m I n p i k U h a g d l Raffinement ? NON l’inclusion des ensembles d’acceptance n’est pas vérifiée Ensembles d’acceptance après les traces pickUp,commIn ou pickUp,dial,c  {{stop, accept}, {stop, accept, commIn, hangUp}, {hangUp}} {{commIn, hangUp},{hangUp}} Construction incrémentale

Correction de la machine d’états DoubleCall
Nouvelle version Ancienne version do / listenNetwork Idle Waiting do / wait Connection Request do / ring Ringing do / checkNetwork Connected Busy/Error pickUp hangUp dial [conn==busy] / busy [else] / error when(called) / call when(disconnected) [conn==ack] commIn / commOut do / beep Beeping Connected2 accept stop Construction incrémentale

Distinction de deux axes de développémént: L’axe horizontal est lié à l'ajout de nouvelles fonctionnalités en vue d'enrichir des spécifications successives L'axe vertical représente les niveaux d'abstraction du plus abstrait au plus concret. Stratégies de raffinement Stratégie h-v (horizontal-vertical) Stratégie v-h (vertical-horizontal) Stratégie mixte :consiste à développer de façon itérative des raffinements horizontaux et verticaux Construction incrémentale

S0,m S1,m Si,0 Si,2 Si,m Sn,0 Sn,1 Sn,2 Sn,m S0,m-1 Si,j Sn,j Stratégie « v-h » Stratégie « h-v » imp0 imp1 rv0 rh0 rh1 rhj rhm-1 rv1 imp rvi impi,j si,j si,j+1 si+1,j si+1,j+1 rhj v-h h-v Construction incrémentale

Exigences locales pour des relations de raffinement chaque relation de raffinement local est également une relation d'implantation chaque relation de raffinement local est une relation de raffinement Raffinement horizontal est l’extension de traces Raffinement vertical est réduction de traces r v i h j = m p ; Le développement horizontal est le fait de définir des incréments de fonctionnalité dans les modèles successifs. Ceci correspond à l'extension conforme des traces. Pour le développement vertical, le raffinement consiste à ajouter des détails dans les modèles successifs du système pour obtenir un modèle concret proche d'un modèle d'implantation. L'ajout de détails est un remplacement d'une action par d'autres pouvant être nouvelles actions. Lorsqu'on compare deux modèles consécutifs, on va masquer ces actions. Le raffinement vertical est donc une réduction de traces. Construction incrémentale

Exigences globales pour des relations de raffinement
Équivalence de stratégies Proposition r v h = i m p r v i + 1 = e t h j 8 ; < n m p Construction incrémentale

Mise en œuvre des relations de raffinement
A partir des conditions locales et globales des relations, nous pouvons identifier pour chaque relation de raffinement horizontal global, les combinaisons locales possibles ainsi que les relations de raffinement vertical garantissant l'équivalence de stratégies. Construction incrémentale

Exemple Ready MoneyBack DrinkDelivery when(exhausted) when (exhausted) do / wait do / giveChange do / giveDrink drink [!money] OutOfStock cancel Choose coins [enough] coins [!enough] [money] Machine Réaliste do / giveGoods GoodsDelivery coins [m>=t] cookies Machine Choix Multiple coins Machine Indéterministe do / shutdown Maintenance getOpCode Machine avec Maintenance Nous illustrons sur un simple exemple une stratégie de développement mixte La première machine est \textsf{Machine Indéterministe}. Cette machine contient les deux fonctions principales (livraison de boissons et d'annulation/remboursement). La machine est exhaustive: elle offre l'annulation du service ou la distribution de boissons. En outre, il est nécessaire de payer pour obtenir une boisson, au moins un, mais il n'est pas déterminé le montant exigé. La deuxième machine Machine avec Maintenance est une extension de la machine Machine Indéterministe, offrant aussi la possibilité d'arrêter la machine quand elle est dans son état initial pour faire une maintenance. La relation $\ext$ vérifiant entre ces deux machines assure que la Machine avec Maintenance peut encore être utilisé exactement comme Machine Indéterministe. La troisième machine Machine Réaliste est un raffinement vertical (dans ce cas une réduction) de Machine avec Maintenance. Tout d'abord, l'indéterminisme est réduit: les gardes de l'événement coins sont ajoutées. Deuxièmement, elle peut rendre la monnaie, après avoir livré la boisson. Troisièmement, la fonction de maintenance est supprimée. Cette dernière réduction est possible car après l'événement \textsf{getOpcode} aucun autre n'est possible. La dernière machine (\textsf{Machine Choix Multiple}) est une extension de la \textsf{Machine Réaliste}. Elle offre une seconde option de livraison. Là encore, elle peut être utilisée exactement comme le \textsf{Machine Réaliste}. Construction incrémentale

Exemple red* ext MachineAvecMaintenance MachineRéaliste MachineChoixMultiple MachineIndéterministe ct La figure présente également les liens pour des machines qui auraient être construites en suivant d'autres stratégies. Elle montre que nous aurions pu utiliser la relation $\ct$ à certaines étapes de raffinement verticale, à condition que nous l'utilisions aussi pour tous les autres raffinements verticaux de même niveau. Construction incrémentale

Raffinement d’architecture
Motivations Bénéficier de composants réutilisables Facilité de la maintenance du système Problématique calculer le comportement d'un assemblage de composants dont les comportements sont spécifiés par des ME? garantir qu'un assemblage est conforme à une spécification exprimée par une ME comparer des assemblages ayant même structure ou de structures différentes même structure : en remplaçant un composant par un autre composant ou un assemblage conforme structures différentes : en ajoutant ou enlevant des composants Construction incrémentale

Étude de cas JobShop Idle JobReceipt /outp(job) inp(job)/ :A0 Busy
SingleJob SM do/ perform(job) Busy <<Interface>> JobReceipt inp(job) outp(job) JobDeposit -perform(job) SingleJob JobReceipt :SingleJob :A0 JobDeposit « delegate » modéliser une ligne de production simple. Nous supposons que deux personnes (appelées \textit{Jobber}) partagent l'utilisation d'un ou plusieurs outils (\textit{Tool}), pour fabriquer des objets à partir de composants simples. Construction incrémentale

Étude de cas JobShop /outp(job) inp(job) Jobber SM do / perform(job)
Idle Jobber SM do / perform(job) Busy inp(job) /tool.get(); Ready /out(job) /tool.use() exit / tool.put() BusyWithTool SingleJob -perform(job) Jobber -put() -get() -use() <<Interface>> UseTool « ext » JobShop get() Idle Tool SM put() use() Busy <<Interface>> UseTool -put() -get() -use() Tool Construction incrémentale

Analyse architecturale Sémantique: deux vues architecturales: Vue externe: les signaux de communication inter-composants sont masqués. Vue interne: aucun signal de communication inter-composants n'est masqué. opérateur de parallélisme sans synchronisation ||| pour composer des LTS associés à des composants qui ne sont pas en interaction. opérateur |[I]| de synchronisation sur l'interface I La vue externe est une vision boîte noire de l'architecture dans laquelle les signaux de communication inter-composants sont masqués. Nous utiliserons l'opérateur LOTOS $\mit{hide}$ pour masquer les signaux. Construction incrémentale

Étude de cas Architectures JobReceipt :Jobber :A1 JobDeposit :Tool UseTool « delegate » JobReceipt :Jobber :A2 JobDeposit :Tool UseTool « delegate » ext Construction incrémentale

Étude de cas Nouveau Jobber JobReceipt :Jobber :A2 JobDeposit :Tool UseTool « delegate » JobReceipt inp(job) Idle Jobber* SM do / perform(job) Busy inp(job) /tool.get(); Ready /outp(job) use() BusyWithTool EndTask /tool.put() Jobber -perform(job) Jobber* « ext » :A3 « delegate » UseTool ext :Jobber* :Jobber :Tool :Tool « delegate » JobDeposit Construction incrémentale

Bilan A 2 = h i d e ( I D [ T ) n J j ] A 3 = h i d e ( I D [ T ) n J j ] J c e x t ) A 3 2 Construction incrémentale

Conclusion Résultats Implantation des relations de conformité Proposition de la transformation des machines d’états en LTS Formalisation du cadre de construction incrémentale Établir un cadre de raffinement d’architecture Limites Complexité théorique => Interprétation des résultats Construction incrémentale

Conclusion Perspectives Réduction de la complexité (algorithme de raffinement de partitions [PT92] Prise en compte d’autres informations Types de données, OCL, entrées/sorties Définition la conformité intégrant la notion de séquence interdite Nouvelles conditions assurant la conformité d’architectures Identifier les fonctionnalités essentielles Rendre la flexibilité de la démarche incrémentale Couplage avec d’autres modèles comportementaux Définition des patrons de conception Abc xyz Construction incrémentale

Bibliographies Construction incrémentale

Merci pour votre attention
Construction incrémentale

État de l’art (1) Méthodes formelles Cahier des charges Réalisation construction validation de la réalisation réelle Modèle de la spécification S réalisation R Vérification (R||E) satisfait-il S? Idée souhaits Environnement Modèle de l’envrironnement E client Validation du modèle Informel Formel Vérification de la cohérence interne Construction incrémentale

État de l’art (1) Raffinement en B S0 s1 Sn abstraite, globale concrète construction raffinement Cahier des charges Construction incrémentale

État de l’art (1) Développement incrémental S0 s1 Sn I1 I0 In Abstraite, partielle complète détaillée vérification implantation construction, extension Cahier des charges Construction incrémentale

Graphes d’acceptance est un ensemble de noms d’états est un ensemble de transitions de est l'état initial Pour chaque état et Pour tout pour tout pour tout il existe un unique A ( p ) = d e f h T ; L ! t i T ! T T L . t 2 T t : s a e 2 P t : a c 2 L t : a c = f X j O u ( q ; " ) ^ 2 s e g t : s a e = f p g " ; t 1 2 T , X 2 t 1 : a c , x 2 X , t 2 T t 1 x ! T 2 a v e c : s = ( [ D ; ) " Construction incrémentale

État de l’art Ensemble d’acceptance [Hen85] Convergence s'il n'y a pas séquence infinie telle que et si et implique A c 2 ( p ; ) = d e f S j ^ 6 ! g h p i p # p ! p i ! + 1 p p1 p2 p3 a b c τ p # a : p # p a ) p # . Construction incrémentale

État de l’art Préordre Must [Hen85] p @ m u s t q i 8 2 A : # ) ( ^ c ; q p p1 p2 p3 b a c a p @ m u s t q q1 b c q3 q2 Construction incrémentale

Construction incrémentale

Présentations similaires

Présentation au sujet: "Construction incrémentale"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back

Entrer

S'autoriser via un réseau social:

Construction incrémentale

Présentations similaires

Présentation au sujet: "Construction incrémentale"— Transcription de la présentation:

Présentations similaires

Notre projet

Feed-back