Construction incrémentale de modèles comportementaux UML

Construction incrémentale de modèles comportementaux UML Olivier Gout, Thomas Lambolais LGI2P École des Mines d Alès {Olivier.Gout,Thomas.Lambolais}@ema.fr Résumé Le but de cet article consiste à mettre en œuvre des techniques de construction incrémentale de machines d états UML. Nous nous basons sur l utilisation des relations de conformité établies sur les systèmes de transitions étiquetées. La difficulté consiste à rendre ces relations applicables dans le cadre des diagrammes d états. Notre approche est d envisager une évaluation continue du respect de la relation de conformité lors de la construction, en procédant par induction sur les étapes élémentaires de construction. Cette technique est ici illustrée sur une étude de cas. Les points d extension et de raffinement concernent d une part l ajout de nouvelles fonctionnalités, le détail des fonctionnalités existantes et d autre part la réduction des points d indéterminisme. Mots clés : spécification, UML, construction incrémentale, conformité, machines d états. 1 Introduction Dans le cadre du développement rigoureux de systèmes, les démarches de développement incrémental des modèles sont naturelles et pertinentes. En effet, elles s apparentent au développement progressif de programmes qui enchaîne évaluations et corrections, autorisant une détection des problèmes de conception très tôt dans le cycle de développement. Mais ces démarches sont actuellement difficiles à mener avec UML [11], par manque de solutions d évaluation des différents diagrammes. Dans le domaine du génie logiciel, UML a tendance à s imposer comme langage fédérateur de modélisation. Son utilité première est de constituer un standard pour l analyse et la conception de systèmes, en proposant plusieurs «vues» de celui-ci. Dans ce contexte orienté objet, la modélisation du comportement des objets est la partie qui retient notre attention. En UML le comportement des objets est modélisé notamment par les diagrammes d états/transitions. Ces diagrammes d états, dérivés des Statecharts de Harel [5], sont des outils de modélisation puissants mais dont malheureusement la sémantique reste imprécise. En raison de cela, peu d outils permettent réellement de concevoir et manipuler des modèles d états, par exemple en offrant des techniques de simulation, d exécution ou de transformation. Cependant des besoins croissants d utilisation des machines d états existent, en particulier suite à l émergence de l approche MDA [9] ou de l utilisation d UML pour des systèmes temps réel [12]. De la même façon, la nécessité de disposer d outils d évaluation et de vérification pour les diagrammes d états fait émerger des modules de génération de test [1, 6]. Ceux-ci sont encore à l état de prototypes et quoi qu il en soit sont inadaptés à une démarche incrémentale. Les dernières propositions de l OMG pour UML 2.0 [10] laissent néanmoins augurer de meilleures possibilités de traitements formels pour certaines machines d états. Construction incrémentale. Parmi toutes les démarches de construction de modèles, la démarche incrémentale nous semble la plus intuitive et souvent la plus efficace. La problématique sous-jacente, dans un objectif d évaluation et de validation des modèles, est de vérifier que les incréments sont conservatifs. On entend par «conservatif» le fait que les incréments préservent les propriétés initiales du modèle.

M2 M1 + I M2 M2 conserve t il les propriétés de M1? FIG. 1 Problématique de la construction incrémentale conservative Cela permet de pratiquer un développement rigoureux des modèles. L objectif de notre travail est de proposer les premiers éléments pour supporter cette démarche, c est-à-dire les outils d évaluation et de comparaison des modèles. Cette problématique s inspire des travaux existants dans le domaine des algèbres de processus [8], de la génération de test, et du modèle Proplane [14] : la relation de conformité sur les modèles comportementaux issue du test de validation a déjà été étudiée en tant que technique de construction incrémentale de processus. Elle peut être un bon point de départ à la mise en place d une technique d évaluation des modèles UML, en particulier les diagrammes d états UML utilisés pour la modélisation du comportement. Dans cet article est présentée une première technique d évaluation des machines d états dans un cadre incrémental. Dans une première partie nous précisons la notion de machine d états en UML, puis nous définissons le cadre formel nécessaire à la mise en place de notre technique d évaluation basée sur la relation de conformité. Dans une seconde partie, nous utilisons cette technique dans le cadre d une étude de cas illustrant ce que peut apporter une vérification incrémentale de cette relation. 2 Machines d états UML 2.1 Description Nous appelons diagramme d états une représentation graphique associée à une machine d états. Les diagrammes d états sont utilisés pour modéliser le comportement des objets, c est-à-dire que pour chaque type d objet, chaque classe, on peut définir une machine d états correspondante. Ces diagrammes sont fortement inspirés des Statecharts introduits par David Harel [4], leur norme est définie dans [11]. États. Le comportement de l objet est décrit à l aide d états qui sont les configurations de l objet, une configuration étant déterminée par les valeurs prises par les attributs de l objet. Les états permettent également de signifier le parallélisme d une configuration grâce à une structure hiérarchique et peuvent également expliciter un certain nombre d actions et d activités effectuées lors du passage dans l état. Il y a trois types d actions possibles en fonction du moment où elles doivent être exécutées. Ces types d actions sont désignés par les expressions entry, exit et on(e) où e est un événement (voir notation sur la figure 2). L état peut également avoir une activité principale, elle est désignée par l expression do. L activité de type do peut être interrompue lorsqu un événement déclenchant une transition s est produit. Les actions entry sont exécutées lorsque l on entre dans l état. Les actions de type on(e) sont exécutées lorsque e s est produit, il s agit en fait d une transition interne sur l état n entraînant pas l exécution des actions entry et exit. Les actions exit sont exécutées lorsque l on doit sortir de l état, i.e lorsqu une transition est déclenchée. Il est donc intéressant de noter que les actions de type exit sont exécutées après l arrivée de l événement qui déclenche la transition. 2

Etat 1 entry/ action1 exit/arction2 on événement1/ action3 do/ activité1 FIG. 2 Actions dans un état Transitions. Les transitions entre états sont de la forme : Ø Ø ½ Ú Ò Ñ ÒØ ÓÒ Ø ÓÒ Ø ÓÒ Ø Ø¾ Les événements peuvent être de quatre types : CallEvent, SignalEvent, ChangeEvent, et TimeEvent. Le type CallEvent correspond à une requête d invocation de méthode. Cette requête peut avoir été émise depuis l environnement comme depuis l objet lui-même. SignalEvent est le type d événement qui résulte de la réception par l objet d un signal émis par l environnement. Le type ChangeEvent est utilisé pour modéliser les événements générés lorsque la valeur d un ou plusieurs attributs a changé. Le type TimeEvent désigne les événements correspondant à l écoulement d un laps de temps spécifié en paramètre. Il est intéressant de noter, pour la suite de notre étude, que parmi ces quatre types d événements seuls les CallEvent et les SignalEvent peuvent correspondre à des stimuli de l environnement. Par ailleurs, ces événements doivent être en accord avec l interface de la classe de l objet spécifiée dans le diagramme de classes : pour chaque CallEvent doit correspondre une méthode et pour chaque SignalEvent doit correspondre un signal auquel l objet est abonné. La condition spécifiée dans la transitions doit être évaluée à vrai pour que la transition soit déclenchée. L évaluation de cette condition n a aucun effet de bord. Activités et actions. La nature des actions dans les états comme sur les transitions est très diverse. Il peut s agir d une seule ou d une séquence d actions qui correspondent à la déclaration d une opération exécutable (pas nécessairement un appel de méthode). La spécificité est que quelque soit la nature de cette action elle est atomique. C est la principale différence avec les activités qui elles peuvent être interrompues. Les activités peuvent être par ailleurs modélisées par des sous-systèmes ou des diagrammes d activités. 2.2 Conformité entre machines d états : définitions Nous considérons des machines d états UML éventuellement hiérarchiques, non parallèles. La présentation officielle des machines d états UML donnée dans [11, 3] expose une grande richesse de possibilités de modélisation. Il ne s agit cependant pas d une sémantique formelle et de multiples imprécisions subsistent. La définition initiale des StateCharts [5] et une formulation de leur sémantique [4] sont plus précises et rigoureuses, bien qu elles aussi critiquées pour d autres raisons [2]. Mais les machines d états orientées objet UML différent assez profondément des StateCharts, et l interprétation initiale de Harel ne convient pas pour nos travaux, en particulier si l on souhaite associer des machines d états au comportement des objets d une classe, ou simplement si l on cherche à respecter aussi près que possible la définition [11]. Plusieurs propositions de définitions de sémantiques pour les machines d états UML ont été formulées [13, 7]. Actuellement, ces sémantiques se placent dans un cadre restreint, en faisant plusieurs hypothèses par rapport à [11]. 3

Notre objectif est de définir une relation de conformité entre machines d états UML, destinée à être utilisée pour conforter des étapes de construction incrémentale. Dans le cadre du test de conformité, plusieurs relations de conformité ont été proposées [15, 17, 16]. Celles-ci ont été définies sur des systèmes de transitions étiquetées, ou LTS (Labelled Transition Systems). Cependant ces relations ne sont pas utilisables directement, la sémantique des machines d états UML ne pouvant se projeter directement sur des LTS. Plusieurs travaux ont consisté à adapter les techniques de génération de tests de conformité de Tretmans aux machines d états, et ce faisant, à définir des relations de conformité adaptées à UML [7, 13]. Il faut noter que de tels travaux s appuient sur des hypothèses fortes concernant l interprétation des machines d états, chose actuellement incontournable si l on désire manipuler formellement des diagrammes d états UML. Par exemple, [13] ne considère pas le parallélisme, et [7] exclut des mécanismes tels que l historique, les actions ou activités dans les états, ainsi que plusieurs types d événements. Les résultats obtenus sont difficilement utilisables dans un autre contexte que celui de la génération de tests. Nous nous basons sur les relations initiales de Tretmans et donnons une adaptation au cas des machines d états. Nous distinguons deux relations de conformité, nommées «Ó»(event conformance) et «Ó»(action conformance). La relation Ó reprend le principe de la relation ÓÒ définie par Tretmans[15] sur les LTS, basée sur la notion de refus ; alors que la relation Ó s inspire des relations ÓÓÒ et ÓÓ sur les IOTS (Input Output Transition Systems) [17, 16]. Informellement, si ËÅ et ËÅ ¼ sont deux machines d états : «ËÅ ¼ Ó ËÅ» si après toute exécution partielle observable de ËÅ, ËÅ peut refuser tout événement que ËÅ ¼ peut refuser. Les notions de «pouvoir refuser» et «devoir accepter» se basent sur l indéterminisme possible des machines, leur permettant d arriver dans différents états après une même exécution. La notion d exécution partielle observable correspond à celle de «trace» couramment définie dans les LTS, que nous définirons plus précisément ci-dessous. «ËÅ ¼ Ó ËÅ» si après toute exécution partielle d événements observables de ËÅ, les actions observables de ËÅ ¼ sont des actions observables de ËÅ. 2.2.1 Observation de machines d états Nous donnons une interprétation sémantique non hiérarchique des machines d états sur des systèmes de transitions de la manière suivante. Définition 2.1 (Interprétation d une machine d états) Une machine d états ËÅ s interprète comme un quadruplet Ë Ë Ä où : Ë est un ensemble de noms d états, Ë est l ensemble des états initiaux ; Ä est un ensemble d étiquettes Ä Ä Ä,où Ä est un ensemble d étiquettes observables Ä Ú Ó Ø Ó µ Ú Ó Ø Ó composées soit d événements observables Ú Ó, soit d actions observables Ø Ó les deux ; Ä est un ensemble d étiquettes internes soit Ä Ú ÒØ Ø ÒØ µ Ú ÒØ Ø ÒØ composées soit d événements internes de Ú ÒØ, soit d actions internes de Ø ÒØ, soit les deux ; Ë Ä Ëest un ensemble de transitions. Si È «Éµ ¾, on note È «É. 4

Nous appelons «interprétation» d une machine d états la construction du système de transitions qui résulte de ses exécutions. Les exécutions peuvent être observables ou non, selon qu elles comportent des étiquettes observables ou internes. Notons que les étiquettes de transitions sont composées uniquement d événements et d actions, et non de gardes. En effet, lors de l exécution, les transitions franchies ont nécessairement la valeur vraie. Par ailleurs, l évaluation des gardes dépend des attributs et des méthodes de l objet, ce que l on exclut d évaluer dynamiquement ici. Événements et actions observables. Une machine d états est en général associée à une classe, pour décrire le comportement de toute instance possible de cette classe. La notion d observation que nous utilisons ici correspond aux interactions possibles entre n importe quelle instance de la classe et son environnement. Soit Ó un objet instance d une classe associée à une machine d états ËÅ. Soit C Óµ le contexte de Ó, c est-à-dire l ensemble des objets de l environnement de Ó pouvant communiquer avec Ó. Les interactions observables de Ó sont : les événements observables reçus par Ó : les appels de méthodes invoquées sur Ó en provenance de C Óµ ; les signaux émis de C Óµ auxquels Ó est abonné ; les actions observables réalisées par Ó : les appels de méthodes invoquées par Ó sur l un des objets de C Óµ ; les signaux émis par Ó ; les méthodes réalisées par Ó déclarées comme observables, c est-à-dire que l utilisateur explicite le fait que cette méthode réalisera une des interactions observables ci-dessus ; Autrement dit, dans la définition de la classe, le spécifieur déclare l ensemble des méthodes observables, à la manière des déclarations public, private et protected. Les événements change event et time event sont indifféremment considérés comme non observables. Les actions observables, lorsqu il s agit de méthodes, devront être explicitement mentionnées dans le diagramme de classes, pour la classe à laquelle se rapporte une machine d états. Une exécution de la machine d états donne lieu à une suite de transitions, ou chemin. Que la machine soit déterministe ou non, une seule transition est franchie à chaque étape. Définition 2.2 (Chemin, exécution, trace) Un chemin est une suite d étiquettes de transitions Ð ½ Ð ¾ Ð Ò,oùÐ ¾ Ä. Par extension, on note ¼ s il existe ½ Ò ½ ¾Ëtels que н Ð ¾ Ð Ò ½ Ð ½ ¾ Ò ¾ Ò Ò ½ ¼ Une exécution (partielle) est un chemin s exécutant sur un état initial. Une exécution complète est une exécution partielle qu on ne peut pas compléter. Une trace «½ «Ò est une exécution observable, c est-à-dire une exécution partielle formée uniquement d étiquettes observables «¾ ½ Ò ¾ Ä. La notion de transition observable classique des LTS s étend à celle des machines d états de la manière suivante. Définition 2.3 (Transition observable) Soient «Ó ¾ Ä une étiquette observable et Ó un chemin observable. Soient, ¼ deux états de Ë. Nous notons : «Ó µ ¼, s il existe «¾ Ä, «½ ¾ Ä, «¾ ¾ Ä, ½ et ¾ ¾Ë, tels que où «½ ½ «¾ «¾ ¼ 5

soit «Ó Ú Ó Ø Ó, auquel cas ««Ó, soit «Ó Ø Ó, auquel cas «Ú ÒØ Ø Ó avec Ú ÒØ ¾ Ú ÒØ, soit «Ó Ú Ó, auquel cas «Ú Ó Ø ÒØ, avec Ø ÒØ ¾ Ø ÒØ. Ó µ ¼ «Ó «½ Ó ¾ µ ½ µ «Ó Ò µ ¼ où Ó «Ó ½ «Ó Ò est un chemin observable, «Ó ¾ Ä La relation µ s étend simplement des états aux machines d états ËÅ Ë Ë Ä,en notant ËÅ µ «s il existe ¾Ë tel que µ. «Enfin, nous définissons l ensemble des traces, traces d événements et ensemble d actions observables (ou encore sorties) après un chemin observable de la manière suivante. Définition 2.4 (Traces, Traces d événements, Sorties observables) Soient ËÅ une machine d états et ¾ ÚÌÖ ËÅ µ une trace d événements. ÌÖ ËÅ µ est l ensemble des traces ; ÚÌÖ ËÅ µ est l ensemble traces d événements et Ç Ø ËÅ µ est l ensemble des actions observables après la trace d événements ; Ö ËÅ µ est l ensemble de refus définis comme suit : ÌÖ ËÅ µ ¾ Ä ËÅ µ ÚÌÖ ËÅ µ ¾ Ú Ó ËÅ µ Ç Ø ËÅ µ Ø ¾ Ø Ó ËÅ ¼ Ú Ø µ avec ¼ Ú Ö ËÅ µ Ú ¾ Ú Ó ËÅ ¼ ËÅ µ ËÅ ¼ Ú µ La notion de refus dans un état correspond aux événements pour lesquels l évolution du système n est pas explicitement précisée. Ce sont les événements qui ne font absolument pas évoluer le système à ce moment précis. Au sens strict des machines d états, il n y a pas de refus : tout comme les IOTS, dans tout état, la réponse du système est spécifiée pour tout événement. Mais lorsque cette réponse correspond à ignorer un événement donné, nous parlons ici de refus. 2.2.2 Relations de conformité Ces ensembles de traces d événements, d actions et de refus, nous conduisent à définir des relations de préordre et de conformité, de manière similaire à celles déjà définies sur les LTS et IOTS. Définition 2.5 (Préordres de traces) Soient ËÅ et ËÅ ¼ deux machines d états ËÅ ¼ Ú EVT ËÅ si, ÚÌÖ ËÅ ¼ µ ÚÌÖ Ëŵ ËÅ ¼ Ú T ËÅ si, ÌÖ ËÅ ¼ µ ÌÖ Ëŵ Définition 2.6 (Conformité d événements) Soient ËÅ et ËÅ ¼ deux machines d états ËÅ ¼ Ó ËÅ si, pout tout ¾ ÚÌÖ ËÅ µ Ö ËÅ ¼ µ Ö ËÅ µ Définition 2.7 (Conformité d actions) Soient ËÅ et ËÅ ¼ deux machines d états ËÅ ¼ Ó ËÅ si, pour tout ¾ ÚÌÖ ËÅ µ Ç Ø ËÅ ¼ µ Ú ACT Ç Ø ËÅ µ 6

Où l inclusion d ensembles d actions se définit comme suit : Ú ACT si, ¾ ¾ tel que ACT Une action en «contient» une autre, ce que l on note ACT, si l action est réalisée dans l action. Cette définition reste informelle, à ce stade il est par conséquent impossible de vérifier automatiquement l inclusion d actions. L évaluation de la conformité se fait de manière interactive avec l utilisateur. L abandon des actions et activités dans les machines d états de protocole dans UML2 [10] nous amènera à proposer une autre définition que celle de la conformité d action. En particulier, il faudra définir plus précisément la notion de conformité déjà évoquée dans UML 2.0, basée sur le renforcement des pré-conditions et la satisfaction des post-condtions. Notons que notre objectif n est pas de chercher à vérifier globalement les relations de conformité, sur deux machines d états données indépendamment l une de l autre. À l inverse des travaux sur le test boîte noire de conformité, nous ne cherchons pas non plus à produire des séquences de tests. Ces relations visent à servir de support à une démarche de construction incrémentale, où la vérification de leur satisfaction peut elle-même se réaliser de manière incrémentale. 3 Étude cas : contrôleur de performances sportives Nous présentons dans cette partie un exemple de développement incrémental par raffinement des modèles comportementaux. Nous nous efforcerons à chaque d étape de dresser le bilan des opérations effectuées en accord avec les relations de conformité définies dans la section 2.2.2. Le cas d étude choisi est celui d un contrôleur de performances embarqué, Sport Performance Embedded Controller : ËÈ. 3.1 Description du SPEC Ce contrôleur, destiné aux cyclistes, se présente sous la forme d un boîtier, type montre, avec un écran et un ou plusieurs boutons. Il doit permettre, grâce à des capteurs, de s informer de divers paramètres lors d un effort sportif. Dans une utilisation avancée, ce contrôleur fonctionne également comme une boîte noire, en stockant toutes les informations pertinentes, de manière à autoriser une analyse ultérieure. Architecture. Ce contrôleur est muni de différents capteurs (vitesse, fréquence cardiaque,...) qui transmettent par signaux les informations à une unité de calcul (UC) (cf. figure 3). L UC est gérée par l intermédiaire d une interface (boutons, écran,...) et stocke les données persistantes dans une mémoire indépendante. Fonctionnement. Le ËÈ doit pouvoir fonctionner selon quatre modes distincts. Dans le mode basique, leëè doit afficher les valeurs lissées des données envoyées par les capteurs. Ce mode doit permettre également l enregistrement ponctuel des données dans la mémoire à la demande de l utilisateur. Un second mode, dit évolué ou expert, est identique au mode basique mais doit en plus enregistrer de manière automatique les données à intervalles réguliers rapprochés. Les deux derniers modes correspondent aux modes de veille et de consultation des données. Les changements de mode se font par l intermédiaire de l interface, et il n y a aucun changement automatique de mode. 3.2 Construction Nous détaillons dans cette partie les phases du développement des modèles comportementaux. Nous visons à décrire par les machines d états, les vues externes et abstraites des intéractions du contrôleur avec son environnement en écartant les détails d implantation. Au préalable, pour décrire 7

Signaux CAPTEURS Capteurs de vitesse Capteurs de fréquence cardiaque Capteurs de puissance... UC Retour et affichage Sauvegarde des données calculées Actions externes MEMOIRE mémoire globale des paramètres base de donnéesdes exercices temps intermédiaires courants... INTERFACE écran LCD boutons connexion infra rouge son... FIG. 3 Structure du ËÈ l environnement, nous donnons un diagramme des classes principales du système (figure 4). Le but de ce diagramme n est pas d être complet ni détaillé, il s agit d identifier le contexte de la classe UC dont nous allons étudier le comportement. Il faut noter que l élaboration de ce diagramme n est pas totalement disjointe de l élaboration des machines d états, le développement des machines d état permettant d identifier d éventuels problèmes ou carences dans les diagrammes de classe. UC <<signal>> sensor <<send>> Capteur 0..n - data - interlapdata - compute() - switch(arg1: int) - computeinterlap() Interface display() Mémoire - process() - updatevalues() - init() save() + start() + stop() + lap() + changemode() sensor C_Cardio C_Vitesse C_Freq InfraRouge Bouton Ecran FIG. 4 Diagramme de classes 8

La classe UC. Pour cette étude de cas nous nous intéressons au comportement de la classe modélisant l unité de calcul : UC. Parmi les quatre modes énoncés, nous ne modélisons le comportement de l UC que pour trois d entre-eux : veille, mode basique et mode évolué. Nous allons procéder par étapes successives. L évolution entre étapes peut être : un «raffinement» dans le cas où des détails sont explicités, mais aucune fonctionnalité nouvelle, qui ne serait pas décrite de manière abstraite avant, n est ajoutée ; une extension dans le cas où de nouveaux comportements sont ajoutés (des événements observables nouveaux sont considérés et les actions impliquées sont explicités) ; une réduction lorsqu un indéterminisme est résolu. Pour chaque étape, nous précisons les événements, actions et activités observables et internes, nous donnons la machine d états obtenue, puis nous donnons les valeurs des ensembles de traces d événements de manière à évaluer la conformité. Étape 1. (FIG. 5) Cette première étape décrit une vue d ensemble de l unité de calcul. Celle-ci répond aux événements déclenchés par les appels de méthodes observables start(), stop() provenant de l utilisateur et les signaux provenant des capteurs. Nous regroupons tous les signaux dans un signal générique sensor, la réactivité étant semblable pour tous les signaux. L action effectuée lors de la réception de sensor est décrite ici de façon très large dans l état Active par l appel à la méthode monitor(). L action memory.save() désigne la façon pour l UC de sauvegarder les données enregistrées dans le mode Active. Ce fonctionnement de base est celui auquel nous voulons rester conforme pour chaque étape. Par la suite, on raffine essentiellement l état Active. Idle start() stop() / memory.save() Active on sensor/ monitor() FIG. 5 ËÈ ¼ Observable Événements start(), stop(), sensor Actions memory.save(), monitor() Activités Interne Bilan : ÚÌÖ ËÈ ¼ µ ÈÖ Ü Ø ÖØ µ Ò ÓÖ ØÓÔ µµ µ Ç Ø ËÈ ¼ Ø ÖØ µµ Ç Ø ËÈ ¼ Ø ÖØ µ Ò ÓÖµ ÑÓÒ ØÓÖ µ Ç Ø ËÈ ¼ Ø ÖØ µ Ò ÓÖ ØÓÔ µµ Ñ ÑÓÖÝ Ú µ où ÈÖ Ü µ, ¾ Ú Ó désigne l ensemble des préfixes de la trace. Étape 2. (FIG. 6) Dans cette seconde étape, le raffinement consiste à détailler l action monitor() en deux (sous-)actions. L une de ces actions est celle qui correspond à l ordre d affichage des données à l interface : interface.display(data). La seconde action process() englobe tout le comportement interne concernant le calcul des données. On a donc fait le choix de dissocier les actions observables, des actions internes. Une action init() est également ajoutée pour assurer une entrée dans Active avec des valeurs cohérentes. Observable Interne Événements start(), stop(), sensor Actions memory.save(), interface.display(), init() process() Activités 9

Idle start() / init() stop() / save() Active on sensor/ process(); interface.display(data); FIG. 6 ËÈ ½ Bilan : ÚÌÖ ËÈ ½ µ ÚÌÖ ËÈ ¼ µ ÈÖ Ü Ø ÖØ µ Ò ÓÖ ØÓÔ µµ µ Ç Ø ËÈ ½ Ø ÖØ µµ Ç Ø ËÈ ½ Ø ÖØ µ Ò ÓÖµ ÒØ Ö ÔÐ Ý Ø µ Ç Ø ËÈ ½ Ø ÖØ µ Ò ÓÖ ØÓÔ µµ Ñ ÑÓÖÝ Ú µ ËÈ ½ Ó ËÈ ¼ ËÈ ½ Ó ËÈ ¼ puisque ÒØ Ö Ð Ý µ ACT ÑÓÒ ØÓÖ µ Étape 3. (FIG. 7) Dans cette étape il s agit encore de raffiner l état Active et plus particulièrement l action process(). En effet, il faut modéliser le fait que les valeurs des données sont lissées avant d être affichées. La solution pour effectuer le lissage est de calculer les données sur une moyenne de cinq signaux. Pour faire cela, on raffine l action process() en introduisant deux sous-états à Active. L action compute() correspond au calcul de lissage, l action updatevalues() à la mise à jour des données avant l envoi vers l interface. L affichage des valeurs se fait donc une fois toutes les 5 occurrences de sensor. Idle start() / init() stop()/memory.save() Active Update entry/ updatevalues() exit/ interface.display(data) when(nb=5) sensor/nb=0 Smoothing entry/ compute() sensor[nb<5]/nb++ FIG. 7 ËÈ ¾ Observable Interne Événements start(), stop(), sensor when(nb=5) Actions memory.save(), interface.display() updatevalues(), init(), compute(), nb=0, nb++ Activités Bilan : ÚÌÖ ËÈ ¾ µ ÚÌÖ ËÈ ½ µ ÈÖ Ü Ø ÖØ µ Ò ÓÖ ØÓÔ µµ µ. En effet le nouvel état Smoothing ne fait intervenir aucun nouvel événement observable (l événement when(nb=5) est interne). De plus ËÈ ¾ est déterministe, on a donc ËÈ ¾ Ó ËÈ ½. 10

Ç Ø ËÈ ¾ Ø ÖØ µµ Ç Ø ËÈ ¾ Ø ÖØ µ Ò ÓÖ Ü µ ÒØ Ö ÔÐ Ý Ø µ où Ü Ò ½ Ò ¾ ÁÆ Ç Ø ËÈ ¾ Ø ÖØ µ Ò ÓÖ Ý µ, où Ò ½ Ý Ò Ò ¾ ÁÆ Ç Ø ËÈ ¾ Ø ÖØ µ Ò ÓÖ ØÓÔ µµ Ñ ÑÓÖÝ Ú µ D où ËÈ ¾ Ó ËÈ ½. Étape 4. (FIG. 8) Dans cette étape, nous introduisons la fonctionnalité de sauvegarde des données à la demande. Ce comportement est tout à fait nouveau par rapport au précédent, il ne s agira donc pas d un raffinement mais d une extension du modèle précédent. La solution choisie pour modéliser cette fonctionnalité est d effectuer cette sauvegarde dans un autre état accessible par l événement lap(). Les données y sont calculées en entrée, elle sont ensuite sauvegardées puis affichées. Le retour dans l état Active se fait dans le dernier sous-état actif lorsque que lap() s est produit. Cette dernière particularité est notée par le H entouré. Après cette étape, nous choisissons de terminer la modélisation du comportement correspondant au mode basique. Idle start() / init() stop()/memory.save() lap() Active Update entry/ updatevalues() exit/ interface.display(data) InterLapComputing entry/ computeinterlap() do/ memory.save() exit/ interface.display(interlapdata) when(nb=5) Smoothing sensor/nb=0 entry/ compute() H sensor[nb<5]/nb++ FIG. 8 ËÈ Observable Interne Événements start(), stop(), sensor, lap() when(nb=5), CompletionEvent Actions memory.save(), interface.display() updatevalues(), init(), compute(), nb=0, nb++ Activités computeinterlap() Bilan : Le comportement de ËÈ est identique à celui de ËÈ ¾ sur les traces de ËÈ ¾.En particulier : les événements refusés par ËÈ lors de l exécution des traces de ËÈ ¾ sont identiques à ceux de ËÈ ¾. D où ËÈ Ó ËÈ ¾, les actions observables de ËÈ lors de l exécution des traces de ËÈ ¾ sont identiques à celles de ËÈ ¾. D où ËÈ Ó ËÈ ¾. Remarques : Bien que ËÈ soit une extension de ËÈ ¾ et non un pur raffinement, la conformité est préservée, 11

l influence de l état historique sur les traces est assez intéressante. En effet lorsqu un comportement est étendu, l extension des traces qui en découle donne lieu à des insertions de séquences d événements. Pour cet exemple la séquence d événements observables qui sera insérée est : Ð Ô Ð Ô µ. On a donc : ÚÌÖ ËÈ µ ÈÖ Ü Ø ÖØ µ Ð Ô Ò ÓÖµ Ð Ô ØÓÔ µµ µ. Étape 5. (FIG. 9) Cette dernière étape consiste à modéliser le mode évolué. Il s agit là encore d une extension. Il faut modéliser le changement de mode ainsi que les actions à effectuer en mode évolué. Pour faire cela, on introduit une nouvelle transition pour changer le mode, déclenchée par l appel à changemode(). La sauvegarde continue du mode évolué est en fait effectuée toutes les cinq secondes, ce comportement est modélisé à l aide d un TimeEvent et d un nouvel état : Record. Initialement, l état Active est en mode basique,de sorte que les sauvegardes automatiques sont désactivées. changemode()/switch(mode) Idle start() / init() stop()/memory.save() lap() Active Update entry/ updatevalues() exit/ interface.display(data) InterLapComputing entry/ computeinterlap() do/ memory.save() exit/ interface.display(interlapdata) when(nb=5) Smoothing sensor/nb=0 entry/ compute() Record H sensor[nb<5]/nb++ do/ memory.save() after(5s)[mode==expert] FIG. 9 ËÈ Observable Interne Événements start(), stop(), sensor, lap(), changemode() when(nb=5), CompletionEvent, after(5s) Actions memory.save(), interface.display(), updatevalues(), com- switch() pute(), nb=0, nb++ Activités computeinterlap(), memory.save() Bilan : La garde [mode==expert] n est valide qu après l événement changemode() et l action interne switch(mode). C est un point qui n est pas explicité dans le diagramme d états, mais que nous devons prendre en compte dans son interprétation. Par conséquent, sur les traces de ËÈ, ËÈ présente les mêmes ensemble de refus et les mêmes ensembles d actions observables que ËÈ. On peut ainsi vérifier que : ËÈ Ó ËÈ, ËÈ Ó ËÈ. 12

3.3 Bilan général Cet exemple de développement incrémental illustre l utilisation des relations de conformité comme technique de vérification des modèles. À chaque étape de l exemple, ces relations ont été vérifiées assurant ainsi une forme de crédibilité du modèle final par rapport au modèle initial. Malgré une apparente simplicité dans les diagrammes obtenus, les modèles n étant pas très détaillés, il apparait que la construction de machines d états est une opération délicate : la solution choisie pour conserver les modèles clairs a consisté à élaguer une partie des fonctionnalités et abstraire plusieurs détails réels. Grâce à la fonctionnalité d historique des machines d états, nous avons pu étendre les comportements tout en préservant la conformité. Il apparaît que ces relations sont assez flexibles pour supporter différents types d incréments : qu il s agisse de raffinements ou d extensions. Il faut cependant, dans certains cas comme à l étape 5, soumettre le modèle à interprétation pour assurer les relations. 4 Conclusion Cet article présente un premier cadre pour la construction incrémentale de machines d états UML séquentielles. Des relations de préordre et de conformité sont définies, de manière à pouvoir décider si une machine d états, dans une étape de construction donnée, «conserve» les propriétés de l étape de construction précédente. Ces relations sont définies sur la base de travaux sur le test de conformité étudiés en particulier pour des systèmes de transitions étiquetées. Nous proposons deux relations utilisées conjointement : une pour vérifier que la machine permet toujours de répondre aux stimuli externes qu elle acceptait à l étape précédente ; une seconde pour vérifier que les sorties qu elle produit après ces stimuli externes sont «en accord» avec ceux de l étape précédente. Sur un exemple simplifié, nous illustrons cette approche en cinq étapes. Chacune des spécifications proposées est construite en respectant ces relations de conformité. Cependant ces relations ne sont pas définies sur des machines d états parallèles. Un premier objectif sera donc de les adapter pour en prendre en compte le parallélisme. D autre part, les relations définies étant relativement permissives, il apparaît que pour les satisfaire, le développement doit être soigné. En effet, elles conviennent bien pour mesurer la conformité entre deux raffinements successifs. Elles sont toutefois plus délicates à utiliser dans les cas d extension : les points d extension devront concerner l ajout ou l insertion de nouveaux événements ; mais s il s agit d ajouts d actions observables, celles-ci doivent pouvoir être analysées comme des «sous-actions» d actions observables à l étape précédente. L appréciation de l inclusion d une action dans une autre est laissée à la charge de l utilisateur. Pour approfondir ce point et chercher à définir une notion d inclusion entre actions, et en particulier entre méthodes, il faudrait s appuyer sur la récente proposition de l OMG de langage d action (ASL Action Specification Language). Dans les diagrammes d états que nous développons, les actions sont juste nommées, et non spécifiées. La prise en compte d ASL pourrait constituer une perspective. À plus court terme, plutôt que de chercher à expliciter la définition des actions dans les machines d états, nous nous attachons aux premières étapes de développement (analyse et spécification, et non conception et réalisation) où les actions sont décrites de manière abstraite. La définition de «machines d états de protocole» dans UML 2.0 nous semble ainsi prometteuse, permettant d attacher une spécification abstraite du comportement à une interface. Savoir si ensuite une classe implante cette interface pourra se faire en comparant les machines d états correspondantes, en utilisant et affinant les relations de conformité présentées ici. Références [1] Tiziana Allegrini. Code generation starting from statecharts specified in UML. ArgoUML white paper, 2002. http://argouml.tigris.org. [2] Charles André. Representation and analysis of reactive behaviors: A synchronous approach. In Computational Engineering in Systems Applications (CESA), pages 19 29, Lille (F), July 1996. IEEE-SMC. [3] Grady Booch, James Rumbaugh, and Ivar Jacobson. The UML User Guide. Object Technology Series. Addison-Wesley, 1999. [4] D. Harel, A. Pnueli, J. Schmidt, and R. Sherman. On the formal semantics of statecharts. In 2nd IEEE Symp. on Logic in Computer Science, Ithaca, NY, pages 54 64, 1987. [5] David Harel. Statecharts: A visual formalism for complex systems. Science of Computer Programming, 8(3):231 274, June 1986. 13

[6] Thierry Jéron, Jean-Marc Jézéquel, and Alain Le Guennec. Validation and test generation for objectoriented distributed software. In Andy Evans, Stuart Kent, and Bran Selic, editors, IEEE Proc. Parallel and Distributed Software Engineering, PDSE 98, Kyoto, Japan, April 1998. [7] Diego Latella and Mieke Massink. On testing and conformance relations for UML statechart diagrams behaviours. In Proceedings of the international symposium on Software testing and analysis, pages 144 153, 2002. [8] Guy J. Leduc. A framework based on implementation relations for implementing LOTOS specifications. Computer Networks and ISDN Systems, 25(1):23 41, August 1992. [9] S. J. Mellor and M. J. Balcer. Executable UML: A Foundation for Model-Driven Architecture. Object Technology Series. Addison-Wesley, 2002. [10] OMG. UML 2.0 Superstructure Specification. OMG Final Adopted Specification ptc/03-08-02, August 2003. [11] OMG. Unified Modeling Language Specification. OMG formal/03-03-01, March 2003. [12] Ran Rinat. A Framework-Based Approach to Real-Time Development with UML. I-Logix white paper, June 2000. [13] Dirk Seifert, Steffen Helke, and Thomas Santen. Conformance testing for statecharts. Forschungsberichte der Fakultät IV 2003-1. ISSN 1436-9915, Technical University of Berlin, 2003. [14] Jeanine Souquières. Aides au développement de spécifications. Thèse d état, Janvier 1993. Université de Nancy 1. [15] J. Tretmans. A Formal Approach to Conformance Testing. PhD thesis, University of Twente, Enschede, The Netherland, 1992. [16] J. Tretmans and A. Belinfante. Automatic testing with formal methods. In EuroSTAR 99: Ø European Int. Conference on Software Testing, Analysis & Review, Barcelona, Spain, November 8 12, 1999. EuroStar Conferences, Galway, Irelan. [17] Jan Tretmans. Repetitive Quiescence in Implementation and Testing (Extended Abstract). In A. Wolisz, I. Schieferdecker, and A. Rennoch, editors, Formale Beschreibungstechniken für verteilte Systeme, number Nr. 315 in GMD-Studien, pages 23 37, St. Augu, 1997. GI/ITG-Fachgespräch, GMD. 14