Université de Montréal

Ingénierie des interfaces usager à l’aide du prototypage et des méthodes formelles

Par Mohammed EL Koutbi

Département d’informatique et de recherche opérationnelle Faculté des arts et des sciences

Thèse présentée à la Faculté des études supérieures en vue de l’obtention du grade de Philosophiæ Doctor (Ph.D.) en informatique

Mars 2000

© Mohammed EL Koutbi, 2000

ii

Résumé

La construction des interfaces usagers graphiques est devenue une partie importante du

génie logiciel. Au cours des dernières années, nous avons vu apparaître de nombreuses

méthodes et outils permettant de réduire la charge de travail des développeurs et des

concepteurs et permettant de produire des interfaces de meilleure qualité. La mise en

œuvre des interfaces graphiques apporte toutefois une complexité nouvelle à la tâche des

concepteurs qui est encore mal maîtrisée. Cette complexité réside dans l’explicitation du

dialogue qui est dirigé par l’utilisateur pour mener parallèlement plusieurs tâches.

Dans ce travail, nous apportons des éléments de réponse aux problèmes de conception

d’interface usager graphique par la proposition d’un cadre méthodologique supporté par

des techniques formelles et des outils de prototypage. Notre intérêt porte particulièrement

sur la conception d’interfaces dans l’approche orientée objet. Ainsi, nous avons basé nos

travaux sur la notation unifiée UML qui émerge comme un consensus des notations

orientées objet et qui supporte bien l’approche scénario.

Nous avons défini un processus itératif pour l’ingénierie des exigences des systèmes

interactifs. Ce processus a été raffiné par deux approches de modélisation. La première

vise l’étude du comportement de tout le système en utilisant les réseaux de Petri à haut

niveau comme formalisme de spécification. La deuxième s’intéresse à l’étude des

comportements individuels des différents objets du système et en particulier des objets

d’interface. Les comportements des objets sont décrits par les Statecharts de la notation

UML. Les deux approches de modélisation utilisent les scénarios pour l’acquisition des

iii

besoins et génèrent un prototype de l’interface usager du système à partir des spécifications

des comportements et des données du système.

Les principaux apports de ce travail, outre le cadre méthodologique lié au processus itératif

proposé et l’analyse comparative des deux approches de modélisation, résident dans : la

proposition de deux nouveaux algorithmes d'intégration des scénarios, la génération des

aspects statique et dynamique de l'interface usager à partir des spécifications du

comportement et des données, et la proposition d'un algorithme de vérification qui vient en

complément aux outils de vérification disponibles pour les Statecharts. Les algorithmes

développés peuvent être insérés dans des outils de modélisation supportant la notation

UML afin d’offrir des environnements de développement rapide pour les interfaces

usagers.

iv

Abstract

The construction of graphical user interfaces has become a significant part of software

engineering. In recent years, many methods and tools reducing the workload of the

developers and enhancing the quality of user interfaces have been suggested. However, the

implementation of user interfaces remains a hard and tedious task. The complexity lies in

the specification of the dialogue which is conducted by the user to carry out concurrently

several tasks.

In this work, we alleviate the task of user interface design by proposing a methodological

framework supported by formal techniques and prototyping tools. We particularly focus on

the user interface design in object-oriented approaches. Thus, we based our work on the

Unified Modeling Language (UML) which emerges as a consensus for object-oriented

methods and which supports well scenario engineering.

We define an iterative process for the requirements engineering of interactive systems.

This process is refined by two modeling approaches. The first aims to study the behavior of

the entire system using high-level Petri nets as formal technique. The second one focuses

on studying the behavior of individual objects and particularly of interface objects. We use

the Statecharts of the UML notation to describe object behavior. The two modeling

approaches use scenarios to describe user needs and generate from behavior and data

specifications a user interface prototype of the system.

The major contributions of this work, in addition to the methodological framework and a

framework for comparing the two modeling approaches, lie in: the proposal of two new

algorithms for scenario integration, the automatic generation of both static and dynamic

v

aspects of the user interface from scenarios and data specifications, and the proposal of an

algorithm for Statechart verification that complements other existing approaches. The

developed algorithms can be inserted in modeling tools supporting the UML notation to

offer better environments for the development of user interfaces.

vi

Table des matières

Résumé_________________________________________________________________ ii

Abstract ________________________________________________________________iv

Table des matières________________________________________________________vi

Table des figures _________________________________________________________xi

Liste des tables__________________________________________________________xiv

Liste des abréviations ____________________________________________________ xv

Introduction_____________________________________________________________ 1

Chapitre 1

Les systèmes interactifs____________________________________________________ 7

1.1. Sciences cognitives et l’interface usager _______________________________________8 1.1.1. Modélisation du processeur humain ________________________________________________9 1.1.2. Règles ergonomiques __________________________________________________________10

1.2. Modèles d’architecture pour l'interface usager ________________________________13 1.2.1. Le modèle de Seeheim _________________________________________________________13 1.2.2. Le modèle de Hudson__________________________________________________________14 1.2.3. Le modèle MVC ______________________________________________________________15 1.2.4. Le modèle PAC ______________________________________________________________16 1.2.5. Le modèle Arch ______________________________________________________________17

1.3. L’interface usager dans les méthodes orientées objet ___________________________18

1.4. Outils pour l’interface usager ______________________________________________21 1.4.1. Classification des outils existants _________________________________________________21 1.4.2. Les outils de prototypage _______________________________________________________23 1.4.3. Génération de l’interface usager__________________________________________________25

1.5. Conclusion ______________________________________________________________27

vii

Chapitre 2

Scénarios et algorithmes d'intégration_______________________________________ 28

2.1. Aspects des scénarios _____________________________________________________29 2.1.1. Forme des scénarios ___________________________________________________________29 2.1.2. Contenu des scénarios _________________________________________________________30 2.1.3. But des scénarios _____________________________________________________________31 2.1.4. Cycle de vie des scénarios ______________________________________________________32

2.2. La notation UML et l’utilisation des scénarios ________________________________33 2.2.1. Diagramme de classes (ClassD) __________________________________________________34 2.2.2. Diagramme d’objets (ObjectD) __________________________________________________34 2.2.3. Diagramme de cas d’utilisation (UseCaseD) ________________________________________34 2.2.4. Diagramme de séquence (SequenceD) _____________________________________________36 2.2.5. Diagramme de collaboration (CollD) ______________________________________________37 2.2.6. Diagramme d’états (StateD) _____________________________________________________39 2.2.7. Diagramme d’activités (ActivityD) _______________________________________________40 2.2.8. Diagramme de composants (ComponentD) _________________________________________40 2.2.9. Diagramme de déploiement (DeploymentD) ________________________________________41 2.2.10. Les aspects de scénarios dans UML ______________________________________________41

2.3. Scénarios et algorithmes d’intégration _______________________________________41 2.3.1. Approche de Hsia et al._________________________________________________________42 2.3.2. Approche de Koskimies et Makinen_______________________________________________43 2.3.3. Approche de Kawashita et al. ____________________________________________________44 2.3.4. Approche de Desharnais et al. ___________________________________________________45 2.3.5. Approche de Somé et al.________________________________________________________46 2.3.6. Approche de Glinz ____________________________________________________________47 2.3.7. Approche de Dano et al. ________________________________________________________48

2.4. Conclusion ______________________________________________________________48

Chapitre 3

Vision système et formalisation des scénarios à l’aide des RdPs __________________ 51

3.1. Réseaux de Petri à haut niveau _____________________________________________53

3.2. Processus d’ingénierie des besoins utilisant les RdPs_________________________56

3.3. Acquisition des besoins _________________________________________________57 3.3.1. Extension des scénarios d’UML pour le support de l’IU _______________________________58 3.3.2. Acquisition des scénarios. ______________________________________________________60

3.4. Spécification du système___________________________________________________62 3.4.1. Spécification des cas d’utilisation ________________________________________________63 3.4.2. Spécification des scénarios______________________________________________________65

3.5. Intégration des scénarios __________________________________________________69 3.5.1. Description de l’algorithme _____________________________________________________69 3.5.2. Implantation de l’algorithme d’intégration dans l’environnement de designCPN ____________71

viii

3.5.3. Problème d’entrelacement entre scénarios __________________________________________74

3.6. Conclusion ______________________________________________________________76

Chapitre 4

Vision objet et formalisation des scénarios à l’aide des Statecharts________________ 78

4.1. Processus d’ingénierie des besoins utilisant les Statecharts____________________78

4.2. Acquisition des besoins _________________________________________________81

4.3. Génération de spécifications partielles_____________________________________86

4.4. Analyse des spécifications partielles_______________________________________87

4.5. Intégration des spécifications partielles____________________________________92 4.5.1. Cohérence des hiérarchies d’états _______________________________________________93 4.5.2. Fusion des états _____________________________________________________________93 4.5.3. Fusion des transitions ________________________________________________________96 4.5.4. Incorporation de variables de contrôle ___________________________________________97

4.6. Conclusion ______________________________________________________________99

Chapitre 5

Génération du prototype de l’interface usager à partir des spécifications comportementales ______________________________________________________ 101

5.1. Algorithme de génération du prototype de l’IU_______________________________102 5.1.1. Algorithme de génération du prototype de l’IU selon l’approche SUIP-PN _______________102 5.1.2. Algorithme de génération du prototype de l’IU selon l’approche SUIP-SC _______________103

5.2. Génération du graphe des transitions_______________________________________105 5.2.1. Génération du graphe des transitions dans SUIP-PN _________________________________105 5.2.2. Génération du graphe des transitions dans SUIP-SC _________________________________106

5.3. Identification des blocs de l’IU ____________________________________________108

5.4. Composition des blocs de l’IU _____________________________________________110

5.5. Génération des frames ___________________________________________________111

5.6. Conclusion _____________________________________________________________114

Chapitre 6

Vérification des propriétés de comportement : cohérence et complétude de scénarios 116

6.1. Vérification dans les RdPs _____________________________________________118 6.1.1. Propriétés des RdPs_________________________________________________________118

ix

6.1.2. Graphe d’accessibilité ou graphe d’occurrence _____________________________________119 6.1.3. Calcul des invariants ________________________________________________________120 6.1.4. Cadre de vérification utilisant les RdPs__________________________________________120

6.2. Vérification dans les Statecharts ________________________________________122 6.2.1. Propriétés des Statecharts ______________________________________________________123 6.2.2. Algorithme de vérification _____________________________________________________124

6.3. Conclusion _____________________________________________________________133

Chapitre 7

Discussion et comparaison des deux approches de modélisation _________________ 134

7.1. La notation unifiée UML _________________________________________________134 7.1.1. UsecaseD __________________________________________________________________134 7.1.2. SequenceD et CollD __________________________________________________________136

7.2. Vision système et vision objet ___________________________________________138 7.2.1. Séquencement des messages au sein d’un scénario_________________________________138 7.2.2. Interaction des messages dans un scénario _______________________________________139 7.2.3. Interaction des messages lors de l’intégration de scénarios __________________________140 7.2.4. Non-déterminisme__________________________________________________________141 7.2.5. Étiquetage des états _________________________________________________________142 7.2.6. Prototype de l’interface usager ________________________________________________143 7.2.7. Comportements non pertinents__________________________________________________145 7.2.8. Récapitulation _____________________________________________________________147

7.3. Réseau de Petri versus Statechart _______________________________________148 7.3.1. Concurrence ______________________________________________________________148 7.3.2. Non-déterminisme__________________________________________________________149 7.3.3. Jetons et scénarios multiples __________________________________________________150 7.3.4. Comportement modal _______________________________________________________150 7.3.5. Support outil ______________________________________________________________151 7.3.6. Récapitulation _____________________________________________________________151

7.4. Génération de l’IU ______________________________________________________152 7.4.1. Génération basée sur les scénarios _____________________________________________152 7.4.2. Critères de composition des blocs d’IU__________________________________________153 7.4.3. Prototypage rapide et évolutif _________________________________________________153 7.4.4. Styles d’IU________________________________________________________________154

7.5. Validation et expériences_______________________________________________155 7.5.1. L’approche SUIP-PN _______________________________________________________155 7.5.2. L’approche SUIP-SC________________________________________________________155

7.6. Conclusion _____________________________________________________________156

x

Chapitre 8

Conclusion____________________________________________________________ 158

8.1. La notation UML _______________________________________________________159

8.2. L’approche scénario _____________________________________________________159

8.3. Génération de l’IU ______________________________________________________160

8.4. Validation des approches et support outil ___________________________________160

8.5. Travaux futurs _________________________________________________________161

Bibliographie__________________________________________________________ 163

Annexe A : Grammaires des diagrammes UML utilisés ________________________ 172

A.1. Diagramme de classes (ClassD) ___________________________________________172

A.2. Diagramme de collaboration (CollD) _______________________________________173

A.3. Statecharts (StateD)_____________________________________________________175

Annexe B : SUIP version Statechart (SUIP-SC)______________________________ 177

B.1. Structure en projets _____________________________________________________177

B.2. Entrées de SUIP-SC _____________________________________________________178

B.3. Environnement d'exécution de SUIP-SC ____________________________________181

B.4. Sorties de SUIP-SC _____________________________________________________182

Annexe C : SUIP version Réseaux de Petri (SUIP-PN) ________________________ 185

C.1. Structure en projets _____________________________________________________186

C.2. Entrées de SUIP-PN_____________________________________________________187

C.3. Environnement d'exécution de Suip-pn_____________________________________187

C.4. Sorties de SUIP-PN _____________________________________________________189

xi

Table des figures

Figure 1: Processus combinant les techniques formelles et les techniques de prototypage.

Figure 2: Modèle du processeur humain selon Cardson.

Figure 3: Modèle de Seeheim [Pfa85].

Figure 4: Modèle de Hudson [Hud87].

Figure 5: Modèle MVC.

Figure 6: Modèle PAC [Cou90].

Figure 7: Modèle Arch [Bas91].

Figure 8: Activités de développement spécifiques aux OOUIs [Col95].

Figure 9: Étapes et activités de la méthode OMT++ [Jaa95].

Figure 10: Composantes d’applications interactives [Mye95].

Figure 11: Types de générations possibles dans une application interactive [Tar93].

Figure 12: Aspects de scénarios [Rol98].

Figure 13 : Exemple d’un UseCaseD.

Figure 14 : Exemple d’un SequenceD.

Figure 15 : Exemple d’un CollD.

Figure 16 : Séquencement des messages du CollD de la Figure 15.

Figure 17 : Exemple de scénario composé dans l’approche de Hsia et al. [Hsi94].

Figure 18 : Exemple de scénario pour un guichet automatique [Som97].

Figure 19 : Opérateurs de composition de scénarios dans l’approche de Glinz[Gli95].

Figure 20 : Liens temporels entre cas d’utilisation [Dan97].

Figure 21 : Problème d’entrelacement entre scénarios.

Figure 22 : Activités du processus d'ingénierie des besoins de l’approche SUIP-PN.

Figure 23 : ClassD du système ATM.

Figure 24 : Diagramme des cas d’utilisation du système ATM.

1

9

13

14

15

16

17

19

20

22

25

29

35

36

37

38

42

46

47

48

49

55

56

59

xii

Figure 25 : Scénarios avec contraintes : (a) scénario IdentReg, (b) scénario IdentErr.

Figure 26 : Scénarios avec widgets : (a) scénario IdentReg, (b) scénario IdentErr.

Figure 27 : RdP généré à partir du UseCaseD de la figure 24.

Figure 28 : Raffinement de la relation uses.

Figure 29 : (a) RdP mis à jour après raffinement de la relation uses (b) RdP adapté à l’outil designCPN.

Figure 30 : (a) Scénario capturant un comportement séquentiel, (b) graphe des messages correspondant, (c) RdP dérivé du graphe des messages.

Figure 31 : (a) Scénario capturant un comportement itératif et concurrent, (b) graphe des messages correspondant, (c) RdP dérivé du graphe des messages.

Figure 32(a) : RdPC correspondant au scénario IdentReg.

Figure 32(b) : RdPC correspondant au scénario IdentErr.

Figure 33: Transformation des scénarios en RdPCs sous le format XML.

Figure 34 : Résultat d’intégration des scénarios Identreg et IdentErr.

Figure 35: Problème d’entrelacement entre les scénarios.

Figure 36 : Activités du processus d’ingénierie des besoins de l’approche SUIP-SC.

Figure 37 : Dérivation des spécifications intégrées à partir des CollDs.

Figure 38 : Description détaillée de la classe GAB du système ATM.

Figure 39 : UseCaseD du système ATM sans tenir compte de la réutilisation.

Figure 40(a) : CollD du scénario retraitReg.

Figure 40(b) : CollD du scénario retraitErr.

Figure 41(a) : CollD du scénario retraitReg.

Figure 41(b) : CollD du scénario retraitErr.

Figure 42(a) : StateD de l’objet GAB généré par l’algorithme CTS à partir du CollD de la figure 41(a).

Figure 42(b) : StateD de l’objet GAB généré par l’algorithme CTS à partir du CollD de la figure 41(b).

Figure 43 : Étiquetage des états par les post-conditions (a) cas un message, (b) cas de deux messages consécutifs.

Figure 44(a) : StateD étiqueté de l’objet GAB dérivé du scénario retraitReg.

Figure 44(b) : StateD étiqueté de l’objet GAB dérivé du scénario retraitErr.

Figure 45 : Vérification de la cohérence des hiérarchies d'états de sd1 et sd2.

60

61

62

63

63

65

65

67

68

70

72

74

77

78

80

81

82

82

83

83

85

85

88

89

90

91

xiii

Figure 46 : Fusion des états : (1) StateD sd1, (2) StateD sd2, (3) StateD résultat sd.

Figure 47 : StateD intégré de l’objet GAB après intégration des scénarios retraitReg et retraitErr.

Figure 48 : Menu généré pour l’objet d’interface GAB du système ATM.

Figure 49 : Menu généré pour l’objet d’interface GAB du système ATM.

Figure 50 : Graphe des transitions GT généré à partir du RdPC modélisant le CU Identification.

Figure 51 : (a) StateD de l’objet obj ; (b) Graphe de transitions généré.

Figure 52 : Graphe GT’ obtenu après masquage des transitons non-interactives du graphe GT de la figure 50.

Figure 53 : Identification des BIUs (a) vue détaillée (b) vue globale (c) composition des BIUs.

Figure 54 : Frames générées à partir du graphe GB’ de la figure 53(c).

Figure 55 : Simulation des frames générées de la figure 54.

Figure 56 : Diagramme d’interaction des cas d’utilisation.

Figure 57 : SequenceD montrant la faiblesse de description de la concurrence et de la synchronisation.

Figure 58 : CollD modélisant une itération avec interruption par message.

Figure 59 : (a) Exemple de SequenceD illustrant l’ordre partiel des messages ; (b) StateD généré à partir du SequenceD pour l’objet O2.

Figure 60 : Interaction non-désirable entre les messages d’un même scénario : (a) Exemple de scénario, (b) Comportement de l’objet O2 dérivé à partir du scénario (a).

Figure 61 : Interaction des messages après intégration de scénarios. (a) : Scénario 1 ; (b) : Scénario 2 ; (c) : Comportement de l’objet O2 ; (d) : Comportement de l’objet O3 ; (e) : Comportement de l’objet O4

Figure 62 : Exemple de scénarios dont le comportement est non-déterministe pour l’objet O2.

Figure 63 : (a) Table des états associée au scénario de la figure 63(b) ; (b) RdPC généré à partir du scénario de la table des états.

Figure 64 : Scénario normal d’utilisation de la pompe.

Figure 65 : Frames générées pour la vision système (a) et pour la vision objet ((b) et (c)).

Figure 66 : Scénarios de prêt pour le système de bibliothèque.

Figure 67 : Comportement de l’objet Document : (a) Statechart dérivé du scenario1, (b) Statechart dérivé du scenario2, (c) Statechart intégré.

92

96

101

102

104

105

107

109

110

111

133

135

135

137

137

138

139

141

142

143

144

145

xiv

Liste des tables

Table 0 : Principales caractéristiques des approches scénarios.

Table 1 : Exemple de table d’états associée au scénario de la figure 31(a).

Table 2 : Table des états scénarios du scénario IdentReg.

Table 3 : Table des états scénarios du scénario IdentErr.

Table 4 : Récapitulation de la comparaison des visions système et objet.

Table 5 : Comparaison des RdPs et Statecharts selon le point de vue IU.

50

66

66

67

147

151

xv

Liste des abréviations

3D 3 Dimensions ActivityD Diagramme d’activités AOO Analyse Orientée Objet ATM Automatic Teller Machine BIU Bloc d’Interface Usager ClassD Diagramme de Classes CollD Diagramme de Collaboration ComponentD Diagramme de composants COO Conception Orientée Objet CTS CollD To StateDs CU Cas d’utilisation DeploymentD Diagramme de déploiement FCAR Fonds pour la formation des Chercheurs et l’Aide à la Recherche au Québec GAB Guichet Automatique Bancaire GB Graphe de Blocs d’interface usager GOMS Goal Operator Method Selection GT Graphe de Transitions GUI Graphical User Interface IU Interface Usager ML Markup Language MOO Méthodes Orientées Objet MVC Model View Controller ObjectD Diagramme d’Objets OCL Object Constraint Language OMT Object Modeling Technique OOSE Object-Oriented Software Engineering OOUI Object-Oriented User Interface PAC Présentation, Abstraction et Contrôle POO Programmation Orientée Objet RdP Réseau de Petri RdPC Réseau de Petri coloré RdPCH Réseau de Petri coloré hiérarchique SequenceD Diagramme de Séquence SGML Standard General Markup Language StateD Diagramme de Statechart ou d’états SUIP-PN Scenario-based User Interface Prototyping, version Petri Net

xvi

SUIP-SC Scenario-based User Interface Prototyping, version Statechart UML Unified Modeling Language UseCaseD Diagramme de cas d’utilisation XML eXtended Markup Language

1

Introduction

Motivation

La construction des Interfaces Usagers (IU) est devenue une partie importante du génie

logiciel. Au cours de ces dernières années, nous avons vu apparaître de nombreuses

méthodes et outils permettant de réduire la charge de travail des développeurs et des

concepteurs et permettant de produire des interfaces de meilleure qualité.

Au début des années 80, le terme IU était quasiment inconnu. On s’intéressait avant tout à

la validité des applications et qu’elles réalisent les traitements qu’on attendait. L’arrivée du

premier Macintosh avec sa boîte à outils (toolbox) a révolutionné le monde informatique.

Cette machine était le premier système commercial à utiliser une interface graphique à

manipulation directe, et avec elle de nouveaux concepts ont vu le jour tels que souris,

dossiers, icônes, etc.

Depuis leur apparition, les interfaces graphiques n’ont pas cessé d’évoluer en apportant

plus de souplesse à l’utilisateur, en réduisant sa charge de travail et en répondant

efficacement à ses besoins. L’acceptation de ces nouvelles interfaces n’est pas uniquement

due à l’avancée technologique de l’informatique que ça soit au niveau matériel ou logiciel,

mais elle revient aussi aux résultats des sciences cognitives qui s’intéressent à l’étude du

comportement humain. Par l’intégration des règles ergonomiques (facilité d’utilisation,

concision, cohérence, flexibilité, etc.), ces interfaces ont mérité l’appréciation de

l’utilisateur. Une autre raison principale de ce succès provient du fait que l’utilisateur est

maître de l’interaction avec l’application pendant toute la session de travail. L’interaction

se caractérise donc par une grande liberté d’action (sur les actions possibles) et un niveau

de contrôle important (contre les actions non autorisées).

2

La mise en œuvre de ce type d’interface apporte toutefois une complexité nouvelle à la

tâche des concepteurs. Cette complexité réside dans l’explicitation du dialogue multi-tâche

qui est dirigé par l’utilisateur pour mener parallèlement plusieurs tâches. Au niveau de la

spécification de l’IU, on sait dessiner des interfaces mais il est souvent difficile de spécifier

leur comportement dynamique du fait de la complexité du dialogue. Les outils formels

seront d’une grande utilité dans la spécification et la vérification du comportement de ces

interfaces avant leur implantation. Ce qui permettra de reduire le temps des tests et

d’ameliorer la qualité du produit.

Ce travail s’insère dans le cadre du projet Forspec qui vise la promotion et l’utilisation des

méthodes formelles dans le développement des systèmes d’information. Le projet s’intitule

‘Ingénierie des systèmes à l’aide des méthodes formelles’. Il porte en sa globalité sur la

spécification des différentes composantes d’un système à savoir : l’IU, les données et les

fonctionnalités. Ce projet est mené conjointement par des chercheurs de l’Université de

Montréal et de l’Université Laval, et il est supporté par une subvention d’équipe du FCAR

(Fonds pour la formation des Chercheurs et l’Aide à la Recherche au Québec).

La spécification de chacune de ces composantes constitue un sous-projet à part; ainsi le

choix de la méthode et du formalisme de spécification à utiliser sont décidés par sous-

projet. Le point commun entre les différents sous-projets se situe au niveau de l’utilisation

de l’approche scénario, approche reconnue et acceptée pour son adéquation dans la phase

de définition des exigences.

Objectifs

Dans ce travail, nous nous intéressons à la composante IU et à ses liens avec les autres

composantes du système. Conceptuellement une IU est vue comme composée de trois

parties (modèle MVC): le modèle (données), la vue (présentation) et le contrôleur

(dialogue). Une spécification complète doit donc tenir compte de ces différents blocs et de

leurs liens respectifs. Dans les travaux existants, la spécification de ces composantes est

généralement faite de manière séparée. La partie contrôle, qui a fait l’objet de beaucoup de

3

travaux, est décrite par des formalismes de description de comportement, la partie

présentation est généralement spécifiée à l’aide d’outils et la partie données à l’aide de

formalismes ou de modèles. En outre, les différents liens qui existent entre ces

composantes ne sont pas tous traités; le lien le plus étudié dans la littérature est celui

concernant la génération de la partie présentation à partir de la spécification des données.

Nous pensons qu’il est plus judicieux de faire cette génération à partir du dialogue et de la

faire compléter par la suite par la spécification des données.

Dans ce travail, nous essayons d’apporter des éléments de réponse aux problèmes de

conception d’IU par la proposition d’un cadre méthodologique supporté par des techniques

formelles et des outils de prototypage. Notre intérêt porte particulièrement sur la

conception d’interfaces dans l’approche orientée objet. Ainsi nous avons basé nos travaux

sur la méthode unifiée (Unified Modeling Language : UML) qui émerge comme un

consensus des méthodes orientées objet et qui supporte bien l’approche scénario.

Les travaux réalisés par les membres du projet Forspec lors du commencement de ce

travail incluaient :

• La formalisation et l’intégration de scénarios [Kaw97] : mémoire de maîtrise dirigé par

les professeurs F.Lustman et G.Babin. Ce travail sera décrit brièvement dans la section

2.3.3 de ce document. Il modélise les scénarios par des automates à états finis.

• La formalisation des scénarios par des relations [Des97] (également décrit dans la

section 2.3.4) qui propose une formulation relationnelle des scénarios.

Ces deux travaux prennent une vision système plutôt que la vision objet et considèrent

uniquement le cas des scénarios séquentiels. Au niveau de l’IU, l’utilisateur peut interagir

avec plusieurs tâches concurrentes. Pour une spécification proche de la réalité des IUs, il

s'avère nécessaire d’étendre les travaux existants dans le projet par l’utilisation d’un

formalisme qui modélise la concurrence.

4

Nous avons retenu les Statecharts et les Réseaux de Petri à haut niveau (RdP) comme

formalismes de spécification pour modéliser le comportement de l’IU d’un système. En

effet ces deux formalismes qui sont largement utilisés, ont fait leur preuve dans le domaine

du génie logiciel. Ils permettent de bien modéliser la concurrence, ils sont munis de

possibilités de structuration réduisant la taille des spécifications (hiérarchie) et ils sont

supportés par des outils commerciaux d’édition, de vérification et de simulation.

La vision objet a été explorée dans le cadre de ce travail dans le but d’étudier son impact

sur le processus d’ingénierie des IUs et dans le but de la comparer avec la vision système

utilisée dans les travaux des autres membres du groupe Forspec. En plus, il est plus naturel

d’utiliser cette vision au sein d’une approche orientée objet [Kos94, UML97].

Comme cadre méthodologique utilisant les techniques formelles et de prototypage, nous

avons proposé un processus itératif (Figure 1) pour le développement des systèmes

interactifs. Ce processus est le résultat de la fusion de deux processus itératifs de

développement : un processus utilisant les techniques formelles (cycle supérieur de la

figure 1) et un processus utilisant les techniques de prototypage (cycle inférieur de la figure

1).

Simulation et vérification

Acquisition des scénariosSpécification des

scénarios

Génération du prototypede l’IU

Évaluation du prototype etvalidation des scénarios

Figure 1: Processus combinant les techniques formelles et les techniques de prototypage.

5

Dans le but de comparer les deux visions système et objet, et les deux formalismes de

spécifications soient les RdPs et les Statecharts, nous avons défini deux approches pour

l’ingénierie des besoins qui raffinent le processus de la figure 1. La première approche

(SUIP-PN) s’oriente vers l’étude du comportement de tout le système en utilisant les RdPs

comme formalisme de spécification, tandis que la deuxième approche (SUIP-SC)

s’intéresse à l’étude du comportement individuel des objets du système. A priori, il n’y a

aucun lien entre les deux visions et les deux formalismes de spécification. On peut toujours

utiliser les RdPs avec la vision objet et les Statecharts avec la vision système. La seule

raison derrière cette affectation est d’avoir avec SUIP-SC une approche complètement

conforme à la notation UML.

Contributions majeures

Outre le cadre méthodologique proposé, les contributions majeures de ce travail résident

dans: la proposition de nouveaux algorithmes pour l'intégration des scénarios, la génération

des aspects statique et dynamique de l'IU à partir des spécifications de comportement et de

données, et la proposition d'un algorithme de vérification qui vient en complément aux

outils de vérification disponibles pour les Statecharts. Les propositions faites dans le cadre

de ce travail ont été validées sur plusieurs exemples. Les algorithmes développés peuvent

être insérés dans des outils de modélisation supportant la notation UML afin d’offrir des

environnements de développement rapide pour les IUs.

Jusqu'à date, les résultats de nos travaux de recherche ont été publiés dans [Elk98, Elk99,

Elk00, Khr99]. L’outil développé pour l’approche SUIP-SC, qui est du domaine public, est

accessible à travers le lien http://www.iro.umontreal.ca/labs/gelo/suip.

Organisation de la thèse

Le reste de ce rapport est organisé en sept chapitres. Le chapitre 1 présente l’état de l’art

sur la conception des applications interactives et plus particulièrement de la composante

IU. Il présente successivement l’apport des sciences cognitives aux applications

6

interactives, les architectures conceptuelles des systèmes interactifs, les méthodes orientées

objet et les outils de support à la conception et au développement de ces systèmes. Le

chapitre 2 traite de l’approche scénario utilisée dans le cadre de ce travail. Il couvre

l’utilisation des scénarios dans le cycle de développement, les scénarios dans la notation

UML, les tentatives de formalisation des scénarios et les algorithmes d’intégration

existants. Le chapitre 3 décrit les étapes de l’approche SUIP-PN modélisant le

comportement global du système (vision système) en spécifiant les scénarios par des RdPs.

Le chapitre 4 présente l’approche SUIP-SC formalisant les comportements des objets par

des Statecharts. Le chapitre 5 décrit l’algorithme de génération de l’IU à partir des

spécifications des données et du comportement. Dans le chapitre 6, nous présentons les

techniques de vérification offertes pour les RdPs et comment nous les avons utilisés dans

l’approche SUIP-PN. Nous discuterons ensuite l’algorithme de vérification développé pour

les Statecharts qui est basé sur la sémantique des pré- et post-conditions. Le chapitre 7

évalue les deux approches de modélisation selon leur vision et leur formalisme de

spécification. Le chapitre 8 résume ce travail et identifie certaines pistes de recherche qui

vont dans le sens de la continuation de ce travail. L’annexe A présente les grammaires des

diagrammes UML utilisées dans ce travail, et les annexes B et C décrivent les

environnements outils supportant les approches SUIP-PN et SUIP-SC.

7

Chapitre 1

Les systèmes interactifs

Ce chapitre donne un aperçu général du domaine des interfaces usagers (Ius). Nous allons

y discuter différents aspects de l’IU d’un système à savoir : les classes de règles

ergonomiques, les modèles d’architecture, les méthodes orientées objet qui considèrent

l’IU comme composante essentielle dans leur cycle de développement et les différents

types d’outils supportant la modélisation et l’implantation des IUs. Cette discussion nous

permettra de positionner et justifier certaines décisions prises dans le cadre de ce travail.

Un système interactif est une application proposant une interface dirigée par l’utilisateur;

l’application ne prédéfinit aucune séquence d’opérations et se contente de répondre aux

requêtes qu’elle reçoit de ses utilisateurs.

Une interface peut être vue comme un dispositif qui sert de limite commune à plusieurs

entités communicantes. Elle doit assurer à la fois la connexion physique entre les entités et

effectuer des opérations de traduction entre les formalismes des parties communicantes.

Dans le cas de l'IU la connexion a lieu entre l'image externe du système et les organes

sensoriaux de l'utilisateur. La réalisation d'une telle interface suppose donc la connaissance

précise du comportement de chacune des entités à relier, ce qui rend cette tâche complexe

et souvent empirique.

Dans les systèmes informatiques traditionnels, on s’intéressait surtout à la réalisation des

fonctions logicielles, et c’était l'utilisateur qui devait fournir l'effort d'adaptation au

système. Cependant si cet effort demandé dépasse les capacités et les motivations de

l'utilisateur, le système réalisé ne sera jamais utilisé, même si sa fonctionnalité et son

8

apparence sont séduisantes. Si les fonctions du système ne sont pas de nature à compléter

les facultés de l'utilisateur et si leur organisation ne répond pas à la structure mentale de

résolution de l’humain, aucun effet de présentation ne pourra masquer ces problèmes de

fond.

Les sciences cognitives proposent des théories pour l’étude du comportement humain.

L’intégration de ces sciences avec l'informatique est d’une grande utilité dans la

conception des IUs.

L’avancée technologique au niveau hardware et software a fait bondir les applications

interactives au premier plan. Actuellement le développement de l’IU prend une grande

place dans le développement des applications informatiques. Certaines évaluations

[Mye95] ont révélé que plus de 50% du temps de développement est consacré à la

réalisation de l'IU, et que plus de 70% du coût d'un produit logiciel s’accumule dans sa

maintenance où la maintenance de l'IU représente la grande part.

La section 1 de ce chapitre décrit les différentes classes de règles ergonomiques qui

découlent des sciences cognitives. La section 2 présente les modèles d’architecture

proposés pour délimiter les parties fonctionnelles d’une IU. La section 3 discute les

différentes méthodes de conception orientées objet qui intègrent l’aspect IU comme

activité principale dans leur cycle de développement. La section 4 présente une

classification des outils existants qui supportent la conception et l’implantation des IUs.

1.1. Sciences cognitives et l’interface usager

L’IU doit son évolution aux développements parallèles et partagés des sciences cognitive

et informatique. Pour les ergonomes et psychologues, l’interaction homme-machine

représente l’ensemble des phénomènes physiques et cognitifs qui interviennent dans la

réalisation d’une tâche par l’humain. Les informaticiens sont plus concernés par l’aspect

technologique de l’interaction et son adéquation avec la perception de l’humain.

9

Les sciences cognitives s'intéressent essentiellement à la modélisation du processeur

humain et à la définition de règles ergonomiques permettant de faciliter les interactions

utilisateurs.

1.1.1. Modélisation du processeur humain

On distingue deux grandes classes de modèles pour représenter le processeur humain: les

modèles théoriques et les modèles appliqués. Les premiers tentent de formaliser les

mécanismes qui régissent l’interaction homme-machine pour expliquer et prédire le

comportement humain. Les modèles appliqués ont pour intérêt l’évaluation prédictive des

performances dans l’interaction et servent de support de comparaison entre plusieurs

conceptions.

Un des premiers modèles théoriques, proposé par Cardson [Car83], représente un individu

comme une machine intelligente munie de trois sous-systèmes : sensoriel, moteur et

cognitif (figure 2).

Figure 2: Modèle du processeur humain selon Cardson.

Le sous-système sensoriel désigne le processeur des entrées. Il est responsable de la

gestion de chaque organe sensoriel (device d’entrée). Le sous-système moteur est

responsable du contrôle des mouvements de l’humain (device de sortie). Enfin, le sous-

système cognitif dispose d’un ensemble de mémoires d’information à court et à long terme

et contrôle le comportement de l’individu en fonction du contenu de ses mémoires. Ce

Sous-système sensorial

Sous-système cognitif

Sous-système moteur

10

dernier sous-système est semblable à un système de production (Reconnaissance

→ Action).

Les modèles appliqués les plus connus dans le monde des IUs sont les modèles GOMS et

Keystroke. GOMS [Car83] (Goal-Operator-Method-Selection) modélise l’activité

cognitive d’une personne pour réaliser une tâche par : des buts, des opérateurs, des

méthodes et des règles de sélection.

Un but désigne un état recherché du système. Un but peut être décomposé en sous-buts, les

feuilles de cette hiérarchie étant des buts élémentaires appelés opérateurs. Il se peut que

pour un but donné, il existe plusieurs alternatives possibles. Ces alternatives sont appelées

des méthodes. Une méthode décrit donc le procédé pour atteindre un but. Des règles de

sélection expriment alors le choix d’une méthode parmi celles possibles sous forme de

conditions.

Le modèle Keystroke [Car83] concerne les aspects syntaxiques et lexicaux de l’IU. Il

suppose qu’il y a toujours une seule alternative pour réaliser un but donné et il s’intéresse

au temps d’accomplissement d’une tâche en se basant sur six opérateurs de base :

K (Keystroking) : frappe de touche au clavier, P (Pointing) : déplacement de la souris vers

une cible, H (Homing) : Rapatriement de la main, D (Drawing) : action de dessiner, M

(Mental activity) : activité mentale pour décider l’action suivante et R (Response time) :

temps de réponse du système. Pour chaque opérateur il existe une estimation moyenne de

temps (TK, TP, TH, TD, TM et TR).

Toute méthode peut être représentée avec ces six opérateurs (la commande "ls" par

exemple : M K[l]K[s]K[retour chariot] = M3K), et on peut donc facilement estimer le

temps qu’elle va prendre.

1.1.2. Règles ergonomiques

La définition de règles ergonomiques vise à améliorer l’utilisabilité des IUs. L’approche

suivie pour construire une base de règles ergonomiques est généralement une approche

11

expérimentale où on émet des hypothèses concernant l’environnement de travail et les

tâches à réaliser, puis on essaie de les valider par des expérimentations pour décider de leur

adéquation.

Les règles ergonomiques doivent prendre en compte les aspects fondamentaux suivants

[Cou90] : la cohérence, la concision et la flexibilité.

1.1.2.1. Règles sur la cohérence

Les règles de cohérence visent l’organisation des étapes de réalisation d’une tâche. Elles

concernent la spécification d’un plan de tâche, son exécution, sa perception et son

interprétation. En général le choix d’une métaphore d’interaction (métaphore bureau par

exemple) améliore énormément la cohérence de l’interaction et le temps d’apprentissage

des utilisateurs. Voici, à titre d’exemple, trois règles sur la cohérence :

• Les sous-tâches partagées doivent être utilisées de la même façon dans les différents

contextes d’appel.

• Il faut choisir une nomenclature précise et pertinente (lexique des termes) et une

notation uniforme dans toutes les fonctionnalités de l’interface (notation préfixée par

exemple : verbe objet). Le fait de donner plus de souplesse et d’accepter plusieurs

notations n’est toujours en faveur de l’utilisateur.

• Les informations doivent être là où l’utilisateur les attend.

1.1.2.2. Règles sur la concision

Les règles de concision ont pour but d’éviter les surcharges d’information en sortie et de

réduire le nombre d’actions en entrée. Pour la réduction du nombre d’actions en entrée,

plusieurs techniques ont été utilisées dans les IUs tels que : les abréviations, les macro-

commandes, le couper-coller, les valeurs par défaut, les fonctions refaire et défaire, etc.

Pour éviter les surcharges d’information en sortie, il faut organiser la complexité visuelle

de l’interface et structurer la présentation des fonctions, des menus et des messages. Voici,

à titre d’exemple, trois règles sur la concision :

12

• La présentation des fonctions doit prendre en compte l’évolution des connaissances de

l’utilisateur et offrir plusieurs modes d’utilisation du système (débutant, assisté et

expert).

• Les menus de l’application doivent être équilibrés, pas trop larges ni trop profonds. Des

observations expérimentales d’applications usuelles ont montré qu’une profondeur de 3

est une limite à ne pas dépasser.

• Les messages doivent être exprimés sous la forme la plus adéquate (forme textuelle ou

icônique) dans le but d’informer l’utilisateur pour le rassurer ou l’aider à corriger ses

erreurs.

1.1.2.3. Règles sur la flexibilité

La flexibilité désigne la faculté d’adaptation de l’IU aux variations de l’environnement et

aux différents types d’utilisateurs. Cette adaptation peut être soit manuelle soit

automatique.

• Une adaptation automatique repose sur une modélisation dynamique de l’utilisateur

(modèle de l’usager). Le système, lors de l’interaction avec l’usager, peut déterminer le

niveau de ce dernier, et on parle alors d’interfaces intelligentes.

• Une adaptation manuelle correspond à une personnalisation de l’interface par

l’utilisateur pour des besoins de présentation et d’interaction. L’IU doit donc permettre

une représentation multiple du même concept.

Notons que Coutaz ne mentionne pas de règles de flexibilité explicites [Cou90].

Les règles ergonomiques contribuent à améliorer l’utilisation de l’IU et à limiter les erreurs

qui peuvent se produire lors de l’interaction homme-machine. Ces règles ont été prises en

considération dans notre approche de génération du prototype de l’IU à partir des

spécifications qui sera décrite dans le chapitre 5.

13

1.2. Modèles d’architecture pour l'interface usager

C'est après l'invention de la souris en 1964 et l'apparition du graphisme et du multi-

fenêtrage en 1969 que la recherche dans le domaine des IUs s'est lancée. En 1983, la ville

de Seeheim a accueilli un workshop sur le rôle, le modèle, la structure et la construction

des systèmes de gestion des interfaces usagers (User Interface Management Systèmes :

UIMS). Lors de ce workshop les intervenants ont défini un modèle d’architecture pour les

IUs qui porte d'ailleurs le nom de la ville : modèle de Seeheim (figure 3). Par après, ce

modèle a servi de base pour la naissance de nouveaux modèles plus élaborés et influencés

par le paradigme orienté objet tels que les modèles MVC, PAC et Arch.

Les premiers modèles étaient des modèles conceptuels qui avaient pour but l'identification

des différentes parties d'une application interactive, les modèles les plus récents se sont

dirigés plus vers l'implantation. Dans ce qui suit, nous présenterons cinq modèles

d’architecture pour les applications interactives. Tous ces modèles ont eu un impact

important dans le domaine des IUs.

1.2.1. Le modèle de Seeheim

Ce modèle [Pfa85] est l’un des premiers à proposer un découpage fonctionnel de l'IU. Il

décompose une application interactive en quatre modules : le noyau applicatif, le module

de l'interface de l'application, le contrôle de dialogue et la présentation. Ces composants

sont structurés en couches (figure 3) :

Figure 3: Modèle de Seeheim [Pfa85].

• Le module noyau applicatif regroupe l'ensemble des fonctions que réalise l'application

(coté non interactif).

Noyau applicatif

Module de l’interface de l’application

Contrôle de dialogue

Présentation

14

• Le module de l’interface de l'application relie le contrôle de dialogue au noyau

applicatif par l'invocation des fonctionnalités offertes par l'application.

• Le module contrôle de dialogue gère le dialogue entre l'utilisateur et le système. C’est

lui qui décide de l’accès ou du refus des interactions de l'utilisateur.

• Le module présentation représente la partie de l'application directement liée aux

périphériques d’entrées/sorties. Il gère l'affichage à l’écran et les périphériques d’entrée

(clavier, souris, etc.), et il est responsable de l'apparence de l'interface.

Cette architecture a été longuement critiquée du fait de sa structure en couches, de la

centralisation du contrôle et de la passivité de son noyau applicatif.

Le modèle de Seeheim définit clairement les rôles des quatre modules d'une application

interactive au niveau conceptuel. Malheureusement, son implantation présente des

difficultés puisque les rôles des modules de l’interface (le module de l’interface avec

l’application, contrôle de dialogue et présentation) ne sont pas suffisamment explicités

[Cou90].

1.2.2. Le modèle de Hudson

Ce modèle [Hud87] est une alternative à celui de Seeheim. Il ne comporte que trois

modules (figure 4) :

Figure 4: Modèle de Hudson [Hud87].

• Les outils de l'application ne sont pas passifs comme dans le modèle de Seeheim. Ils

peuvent émettre et recevoir des requêtes ce qui permet un contrôle mixte par l'interface

et par les outils de l'application.

Outils de l’application

Objets actifs Présentation

15

• Les objets actifs jouent le rôle du contrôleur de dialogue. Ils sont définis comme des

types abstraits comportant une structure de données et un ensemble de procédures

définissant leur comportement.

• Le module présentation se charge toujours de la représentation externe de l'application,

mais effectue aussi une partie du contrôle de dialogue.

1.2.3. Le modèle MVC

Le modèle MVC (Model View Controlor) [Gol84] est composé d'un triplet de composants

autonomes qui communiquent entre eux (figure 5) :

Figure 5: Modèle MVC.

• Le modèle est la structure de données que l'on veut représenter à l’écran et qui est

composée d'un certain nombre d’objets.

• La vue est la représentation externe du modèle. C'est par elle que l'utilisateur perçoit les

objets du système et que le modèle reflète ses changements. Dans une application, à un

même modèle peuvent correspondre plusieurs vues.

• Le contrôleur régule les interactions entre la vue et le modèle. Il est chargé de gérer les

actions de l'utilisateur sur la vue, et il informe le modèle des changements faits sur

celle-ci. Le modèle modifie son état et informe la vue du nouvel aspect qu'elle doit

prendre.

Le modèle MVC se prête bien à des applications orientées objet. Il a été utilisé pour la

première fois dans l'environnement de programmation de Smalltalk.

Contrôleur

Vue

Modèle

16

Une variante de MVC, le modèle document-view, combine la vue et le contrôleur dans un

seul composant (view). Il a été utilisé dans plusieurs cadres d’application tels que MFC

[Kru95] et ET++ [Wei95].

1.2.4. Le modèle PAC

L'architecture PAC (Présentation, Abstraction et Contrôle) proposée par Coutaz [Cou90] se

base sur une hiérarchie d'objets pour la modélisation des applications interactives. La

présentation gère les entrées/sorties, l'abstraction contient les informations sur l'application

(données et traitements), et le contrôle gère la cohérence entre l'abstraction et la

présentation. La racine de cette hiérarchie est un objet PAC représentant toute l'application.

Cet objet peut être décomposé en sous-objets PAC qui peuvent à leur tour être décomposés

jusqu'à l'obtention d'objets élémentaires (figure 6).

Un objet PAC intermédiaire a pour présentation la juxtaposition de la présentation de tous

les objets du niveau immédiatement inférieur. Les objets PAC sont stimulés par des

événements qui sont destinés à l'ensemble des objets de la hiérarchie.

Figure 6: Modèle PAC [Cou90].

Présentation Abstraction

Contrôle

P A C

P A C

P A C

P A C

17

Le modèle PAC se distingue du modèle MVC par la définition récursive des systèmes

interactifs. Cependant la hiérarchie d’agents PAC peut causer un ralentissement du système

à cause des échanges de messages entre les différents contrôleurs de l’architecture.

1.2.5. Le modèle Arch

Le modèle Arch [Bas91] est une extension du modèle de Seeheim. Il éclate les modules

présentation et contrôle pour tenir compte des considérations d’implantation en se basant

sur une boîte à outils (figure 7). Il comprend les cinq composant suivants :

Figure 7: Modèle Arch [Bas91].

• Le composant spécifique au domaine implémente les fonctionnalités indépendamment

des interactions de l’utilisateur. C’est une restriction du noyau applicatif du modèle de

Seeheim, puisqu’une primitive de ce composant ne peut faire appel à une interaction.

• Le composant adaptateur au domaine joue le rôle d’intermédiaire ente le contrôleur de

dialogue et le composant spécifique du domaine. Il implémente les tâches relatives au

domaine qui sont nécessaires à l’interaction de l’utilisateur.

Contrôleur de dialogue

Composant adaptateur au domaine

Composant spécifique

au domaine

Composant de présentation

Composant d’interaction

avec le toolkit

Objets du domaine

Opérations et structures de données du domaine

Objets de présentation

Objets d’interaction

18

• Le contrôleur de dialogue est l’élément principal du modèle. Il est responsable du

séquencement des tâches et du lien entre les formalismes spécifiques au domaine et à

l’interface. Il joue le même rôle que celui dans le modèle de Seeheim.

• Le composant de présentation est le médiateur entre le contrôleur de dialogue et le

composant d’interaction avec le toolkit. Il offre des objets indépendants du toolkit pour

utilisation dans le contrôleur de dialogue.

• Le composant d’interaction avec le toolkit implémente les interactions physiques avec

l’utilisateur. Il se base sur un ensemble de classes d’objets d’interaction. C’est une

restriction de la présentation du modèle de Seeheim puisqu’il interdit le changement du

niveau d’abstraction des événements et des données.

Nigay [Nig91] a proposé un modèle hybride de PAC et d’Arch, PAC-Amodeus, qui diffère

de Arch par son contrôleur composé d’un ensemble d’agents PAC.

Les modèles Arch et PAC-Amodeus souffrent du même problème que le modèle de

Seeheim soit la structure en couches.

Dans cette section nous avons présenté des modèles d’architecture de l’IU dont certains

sont plus orientés vers l’implantation. Le modèle MVC, identifié comme patron de

conception [Bus96], reste le modèle le plus utilisé au niveau des méthodes orientées objet

et des environnements de développements des systèmes interactifs. Par conséquent, il a été

adopté dans notre projet. Dans le chapitre 5, nous présenterons comment sont obtenus les

différents composants de ce modèle.

1.3. L’interface usager dans les méthodes orientées objet

Pour obtenir des IUs de qualité, on doit tenir compte des capacités et limitations à la fois

des humains et des systèmes informatiques existants, et des connaissances sociales et

organisationnelles de l’environnement de travail de l’utilisateur. Ces facteurs

pluridisciplinaires rendent difficile la tâche de trouver une méthode générale de conception

19

des IUs. Les méthodes existantes favorisent généralement un des facteurs par rapport aux

autres [Avi90, Har90a].

Au niveau des méthodes orientées objet (MOO), on parle plutôt d’interfaces utilisateurs

orientées objet (Object-Oriented User Interface : OOUI) ou d’interfaces graphiques

(Graphical User Interface : GUI). Des extensions ont été apportées aux MOOs pour tenir

compte des IUs. Collins [Col95] a montré les principales activités qu’il faut ajouter aux

MOOs pour supporter les OOUIs (figure 8).

Figure 8: Activités de développement spécifiques aux OOUIs [Col95].

L’analyse orientée objet concerne l’élaboration des modèles de données et de

comportement du système. L’analyse des utilisateurs et des tâches permet de définir les

buts attendus et le profile des utilisateurs futurs du système. La conception du modèle

conceptuel des usagers concerne essentiellement le choix d’une métaphore pour améliorer

l’utlisabilité de l’IU, qui sera par la suite raffinée par la conception de la présentation de

l’IU et la conception du contrôle de l’interaction. L'étape prototypage et évaluation sert à

la validation de l’IU avec l’utilisateur avant son implantation. Le cercle en gris de la figure

8 exprime le caractère itératif du processus de développement.

Analyse orientée objet

Analyse des utilisateurs et des tâches

Conception du modèle conceptuel des usagers

Conception de la présentation de l’IU

Conception du contrôle de l’interaction

Prototypage et évaluation

Implantation

20

OMT++ [Jaa95] est un exemple de MOOs adaptée aux OOUIs. Cette méthode étend la

méthode OMT (Object Modeling Technique) de Rumbaugh [Rum91] par l’ajout d’activités

correspondantes à l’IU au niveau des étapes d’analyse, de conception et de programmation

(figure 9) :

• Au niveau de l’étape d’analyse (AOO), la spécification de l’IU vient s’ajouter aux

activités d’analyse des objets (par la détermination du diagramme des classes) et

d’analyse du comportement (par les diagrammes d’états des classes pertinentes). La

spécification des IUs consiste à établir la liste des tâches que l’utilisateur peut invoquer

et à définir la structure de l’interface en organisant les tâches en une suite de dialogues.

Un diagramme de dialogue (similaire au Statecharts) est utilisé pour exprimer le lien

entre dialogues. En outre OMT++ offre une notation pour décrire les éléments d’un

diagramme de dialogue (widgets).

Figure 9: Étapes et activités de la méthode OMT++ [Jaa95].

• Dans la phase de conception (COO), la conception des objets consiste à concevoir les

classes des vues et les classes des contrôleurs en se basant sur le modèle MVC. Pour un

dialogue on associe un objet vue et un objet contrôleur. La conception du

Analyse des objets Analyse du comportement

Spécification de l’IU

AOO

Conception du comportement

COO Conception des

objets

POO Implantation des classes

21

comportement consiste à ajouter les opérations aux classes données, vues et

contrôleurs.

• L’étape de la programmation objet (POO) a pour but l’implantation de l’ensemble des

classes obtenues lors de l'étape de conception.

Les approches proposées dans ce travail offrent un cadre semblable à celui de OMT++,

mais appliqué à la notation UML.

1.4. Outils pour l’interface usager

Les applications interactives sont généralement complexes et difficiles à implanter, à

déboguer et à modifier. Une étude [Mye95] a montré que 50% du code des applications

correspond à l’IU et 50% du temps du développement est dépensé dans son implantation.

Plus les interfaces sont faciles à utiliser plus elles sont difficiles à implanter. Pour faciliter

la création des IUs et leur implantation, l’utilisation d’outils dans les phases de

développement s’avère nécessaire. C’est ainsi que le développement d’outils pour le

support de l’IU est devenu une activité primordiale dans les domaines de recherche et de

commerce. Une étude a estimé le marché d’outils à 1,2 milliard de $ US pour l’année 1996

[Mye95].

L’utilisation d’outils peut apporter plusieurs avantages parmi lesquels on peut citer :

l’amélioration de la qualité des interfaces, l’uniformité sur plusieurs applications, et la

facilité de création et de maintenance du code correspondant à l’IU.

1.4.1. Classification des outils existants

En général un outil doit aider dans la conception, l’implantation et l’évaluation des IUs. La

figure 10 montre les différents types d’outils qui peuvent supporter le développement des

IUs [Mye95] :

Application

Outils de haut niveau

Boîte à outils

Système de fenêtrage

Système d’exploitation

22

Figure 10: Composantes d’applications interactives [Mye95].

Le système de fenêtrage décharge le concepteur de la gestion et du contrôle des fenêtres

affichées à l’écran. La plupart des systèmes tels que : X (Motif et Openlook), Macintosh et

Microsoft offrent des commandes pour la création, le déplacement, la suppression et le

dimensionnement des fenêtres.

Les boîtes à outils sont des bibliothèques de widgets qui peuvent être appelées à partir de

l’application. Les widgets correspondent à différentes formes d’entrée, ils incluent des

menus, des boutons, des barres de défilement, des zones de saisie, etc. L’utilisation des

boîtes à outils ne peut être faite que par des programmeurs. Elle a pour avantage de créer

des IUs uniformes et de disposer de fonctions standards pour gérer les différents widgets.

Les boîtes à outils sont en général fortement dépendantes du système de fenêtrage sous-

jacent. Cependant certains travaux de recherche et des produits commerciaux (par exemple

l’environnement de programmation de Smalltalk : Visualworks) ont mis à la disposition

des programmeurs des bibliothèques de widgets virtuels qui peuvent être mappés sur

différents types de systèmes de fenêtrage. Plusieurs types de boîtes à outils ont été

développés pour répondre à des besoins spécifiques. Par exemple SUIT [Pau92] qui

comporte une boîte à outils et un constructeur d’interface (interface builder), a été

spécialement conçue pour des besoins d’enseignement et pour la facilité d’apprentissage.

Garnet [Mye90] offre des outils de haut niveau et une boîte à outils pour supporter les

applications graphiques hautement interactives. La boîte à outils Rendez-vous [Hil93] offre

des fonctions pour le contrôle du temps au niveau de l’interface ce qui est très important

pour les applications réparties. Wernecke [Wer94] a développé une boîte à outils de

widgets 3D.

23

Les outils de haut niveau essaient de simplifier d’avantage la création d’IUs. Myers décrit

dans son article [Mye95] les différents styles de spécifications qui peuvent être utilisés : les

outils basés sur des spécifications formelles (langages déclaratifs, à contraintes, à

événements ou visuels et les formalismes états-transitions) et les outils de prototypage (les

constructeurs d’interface et les cadres d’applications).

1.4.2. Les outils de prototypage

Dans le génie logiciel, le prototypage est considéré comme une approche ayant pour but

l’amélioration de la planification et de l’exécution des activités de développement. Il

supporte l’évaluation de la qualité du système dès les premières étapes du développement.

Plusieurs expériences ont illustré l’impact de cette approche dans divers domaines. Gordon

et al. [Gor95] présentent un survol des expériences de prototypage dans trois domaines

d’application : commercial, académique et militaire. Bäumer et al. [Bäu96] comparent les

approches de prototypage qui ont été utilisées dans 9 projets industriels selon le type de

prototype construit (présentation, fonctionnel, etc.) et selon l’outil utilisé.

Dans les paragraphes suivants, on donnera une classification des approches de prototypage,

des types de prototypes et des outils de prototypage qui peuvent être utilisés.

Une classification des approches de prototypage a été décrite par Bischofberger [Bis92],

selon le but attendu du système à développer :

• Prototypage exploratoire : permet aux développeurs de bien acquérir les besoins

utilisateurs et de discuter la faisabilité de plusieurs solutions du même problème. La

réalisation des prototypes est faite conjointement par les développeurs et les

utilisateurs.

• Prototypage expérimental : a pour but la validation expérimentale d’une architecture de

composantes du système ou des idées d’une solution. Ce type de prototype est réalisé

uniquement par des développeurs pour permettre la conception des composantes d’un

système où l’aspect qualité n’est pas primordial.

24

• Prototypage évolutif : dans cette approche le prototype ne sert pas uniquement comme

support de validation avec l’utilisateur dans les premières phases, mais il est utilisé et

amélioré pour aboutir au produit final.

Les prototypes obtenus à travers ces différentes approches peuvent être classifiés comme

suit [Bis92]:

• Prototypes de présentation : mettent surtout en évidence l’aspect visuel de l’IU.

• Prototypes fonctionnels : implantent les parties importantes de l’IU et les

fonctionnalités du système.

• Maquettes (breadboard) : permettent d’investiguer certains aspects techniques du

système (architecture, fonctionnalités projetées, etc.) pour une évaluation des risques.

Ils représentent un bon support de travail pour les développeurs.

• Systèmes pilotes : sont des prototypes plus mûrs et peuvent être directement utilisés

dans la pratique.

Les outils utilisés dans les différentes approches de prototypage pour produire les

différents types de prototypes précités peuvent être classés de la manière suivante [Sze95]:

• Les outils de type hypertexte : peuvent être utilisés pour le développement rapide de

systèmes d’information simples avec des interfaces graphiques composées de fenêtres

liées par des liens hypertextes contrôlés par des scripts associés aux composants d’une

fenêtre (applications web).

• Les constructeurs d’interface (interface builder) : servent à définir des IUs à un haut

niveau d’abstraction, soit sous forme textuelle en utilisant un langage, soit sous forme

graphique en utilisant un éditeur. Ces derniers sont plus intéressants à utiliser dans le

développement des IUs.

• Les outils de 4ème génération : offrent un environnement complet pour le

développement des systèmes d’information. Ils offrent en plus des éditeurs graphiques

pour les modèles de données et l’IU, des générateurs de programmes et de rapports.

25

• Les cadres d’application : sont des librairies de classes qui comportent une conception

abstraite et réutilisable pour les applications interactives. Ils offrent en plus du support

de l’IU, un support pour l’architecture globale de l’application.

1.4.3. Génération de l’interface usager

La génération automatique des applications interactives touche à plusieurs domaines

différents. Elle peut être appliquée soit lors de la conception, soit lors du prototypage,

comme elle peut concerner l’IU ou toute l’application.

Si l’on se reporte aux représentations d’une application interactive (figure 11), on constate

qu’on peut avoir quatre types de générations possibles [Tar93] :

Figure 11: Types de générations possibles dans une application interactive [Tar93].

• La génération de type1 concerne la génération du code à partir d’une maquette d’écran.

L’utilisateur dessine ses fenêtres, menus, etc. par l’intermédiaire d’un éditeur

graphique. Les objets correspondants sont alors créés et traduits en un code particulier.

Ce type de génération est supporté par les constructeurs d’interface.

• La génération de type2 repose sur l’analyse du code (ré-ingénierie). À partir de la

structure de données manipulée dans le programme on peut dériver certains types de

widgets (zone de saisie, boutons radios, etc.), et à partir de la structure de contrôle, on

peut dériver la structure de menus.

Représentation conceptuelle

(RC)

Représentation externe (RE)

Représentation interne (RI)

type1

type2

type3 type4

26

• La génération de type3 permet le passage d’une spécification conceptuelle (données,

traitements et/ou comportements) à la représentation externe en se basant sur la syntaxe

et la sémantique des spécifications.

• La génération de type4 est plus générale que celle de type3, en effet elle concerne toute

l’application et non seulement la partie présentation de l’IU. Le code généré n’est

qu’un squelette qu’il faut compléter pour intégrer l’aspect sémantique de l’application.

Dans ce travail, nous nous intéressons à la génération des aspects statique et dynamique du

prototype de l’IU à partir des spécifications de données et de comportement. Ceci

correspond à des générations de type3 et de type4 de la figure 11. Nous décrivons ci-après

certains travaux proches de nos intérêts et qui sont tous de type3.

Johnson [Joh92] a développé le système ACE pour générer des widgets en fonction de la

sémantique des données manipulées. Pour chaque donnée, ACE propose un ou plusieurs

widgets en fonction du type de la donnée et du critère de choix. Par exemple pour un

critère de type ‘un parmi n’, les widgets proposés seront des boutons radios ou une liste

d’éléments.

Foley [Fol93] propose un outil générant la présentation en se basant sur un ensemble de

règles ergonomiques correspondantes aux données du système.

Janssen [Jan93] a basé la génération de l’IU sur des vues du modèle Entité/Relation (E/R)

du système. Une vue consiste en un sous-ensemble d’entités et de relations du modèle E/R

global intervenant dans l’exécution d’une tâche. Une fenêtre composée d’objets graphiques

liés aux entités et aux relations est associée à chaque vue.

Bodart [Bod94] combine l’analyse des données, l’analyse des tâches et l’analyse des

fonctionnalités du système dans le développement de l’IU. Un graphe d'activité est

construit pour lier les tâches interactives aux données et aux fonctions. Ce graphe sert par

la suite à identifier les unités de présentations de l’IU.

27

Balzert [Bal96] propose une approche pour dériver l’IU à partir du modèle objet en se

basant sur un ensemble de règles. Par exemple : chaque classe du modèle objet donne lieu

à une fenêtre où les attributs de la classe sont transformés en fonction de leur type en zones

de saisie, boutons radios ou toute autre forme d’affichage ou de saisie. Les méthodes sont

transformées en boutons.

Dans cette section, nous avons présenté une classification des outils supportant le

développement et l’implantation des IUs. Nous avons également décrit certains travaux de

génération de l’IU à partir de spécifications conceptuelles. La plupart de ces travaux sont

basés sur une analyse des données ou sur une analyse des tâches combinée à celle des

données. Ils ne permettent de générer que l’aspect statique de l’IU.

1.5. Conclusion

Dans ce chapitre, nous avons présenté les différents aspects d’un système interactif. Dans

les chapitres qui suivent, nous proposons et décrivons un processus d’ingénierie des

besoins basé sur la notation orientée objet UML et qui prend en considération les aspects

de l’IU discutés dans ce chapitre.

Nous investigons le support des activités de développement de l‘IU et la génération des

aspects statique et dynamique de celle-ci à partir des descriptions comportementales sous

la forme de scénarios. Le chapitre qui suit décrit l’importance des scénarios dans le

domaine de l’ingénierie des exigences et les approches existantes d’intégration de

scenarios.

28

Chapitre 2

Scénarios et algorithmes d'intégration

Depuis plusieurs années, les scénarios ne cessent de prendre de plus en plus d’importance

dans le génie logiciel. Ils ont été utilisés dans diverses activités du cycle de développement

des systèmes informatiques depuis l’acquisition des besoins jusqu’aux activités de tests,

en passant par la génération de spécifications et de prototypes [His94, Dan97] et par

l’évaluation de diverses alternatives de conception [Roy95]. C’est dans le domaine de

l’ingénierie des besoins (requirements engineering) que les scénarios ont eu le plus de

succès jusqu'à date. Ils ont été utilisés pour identifier, décrire et raffiner les objectifs et les

fonctionnalités du système [Pot95].

Plusieurs définitions du terme scénario existent dans la littérature. Le dénominateur

commun à ces définitions est qu’un scénario décrit une vue partielle du système. Cette

notion de partialité offre la possibilité d’une description restreinte selon l’intérêt du

descripteur et permet aussi d’avoir plusieurs vues différentes et complémentaires du même

système.

Dans le domaine des IUs, les scénarios sont vus comme une utilisation du système dans un

contexte donné. Un scénario est une suite d’interactions entre l’utilisateur et l’ordinateur

[Car95, Ros99]. Dans les systèmes d’information, les scénarios permettent de donner une

image détaillée des aspects fonctionnels et organisationnels du système et de relier les

besoins utilisateurs aux fonctionnalités du système [Kyn95]. Enfin, dans le domaine du

développement orienté objet, les scénarios sont utilisés pour accompagner toutes les phases

du cycle de développement [Jac92]. Un scénario est défini comme une suite d’interactions

entre les objets du système.

29

Dans ce travail, nous avons adopté la dernière définition du terme scénario qui nous

semble plus générale que la définition utilisée dans le domaine des IUs. Et plus

précisément, nous avons utilisé les scénarios tels que définis par UML augmentés par les

informations de l’IU.

Ce chapitre présente les différents aspects des scénarios (forme, contenu, but et cycle de

vie) ainsi que l’utilisation des scénarios dans la notation UML, et discute les différentes

approches d'intégration des scénarios.

2.1. Aspects des scénarios

Les scénarios ont évolué dans le temps selon plusieurs aspects, et leur interprétation

semble dépendre du contexte d’utilisation et de la façon dont ils étaient acquis ou générés.

Dans un travail de récapitulation, Rolland [Rol98] a proposé un cadre pour la classification

des scénarios selon quatre aspects : la forme, le contenu, le but et le cycle de

développement (figure 12).

Figure 12: Aspects de scénarios [Rol98].

2.1.1. Forme des scénarios

La forme des scénarios concerne essentiellement les opérations d’acquisition, de

spécification et de représentation. Les scénarios sont acquis en utilisant différents médias,

Scénario Contenu Cycle

Forme

But

décrit sous

possède

a pour

a un

30

ils sont décrits et définis d’une manière plus ou moins formelle, et ils sont reproduits ou

représentés selon diverses formes dans des buts de validation ou d’évaluation.

Parmi les médias utilisés pour l’acquisition des scénarios, on trouve : le texte en langage

naturel [Eri95, Car95] ou en langage structuré [Jac92], et l’image au format fixe

(graphiques [Rum91, Gou95]) ou animée (vidéos [Woo94]).

Lors de la description des scénarios, des langages de modélisation (semi-formels) ou des

techniques de spécification formelles peuvent être utilisés. Ces descriptions formelles ou

semi-formelles sont très utiles pour la validation des besoins. Par exemple dans [Jac92],

les scénarios sont décrits en utilisant des diagrammes de séquence; dans UML les scenarios

peuvent etre decrits par des diagrammes de collaboration ou de séquence; dans [Hsi94] les

scénarios sont décrits par des grammaires régulières; dans [Kaw97, Lus97] les scénarios

sont décrits par des automates; dans [Kos94, Gli95, Khr99] les scénarios sont formalisés à

l’aide des Statecharts; dans [Dan97, Elk98, Lee98] les scénarios sont décrits en utilisant

des formalismes dérivés des réseaux de Petri; etc.

Lors de la validation et l’évaluation des besoins, les techniques de simulation, d’animation

et de prototypage sont souvent utilisées [Hey98]. Ainsi les scénarios se trouvent

représentés sous forme de prototypes destinés à l’animation pour la validation des

spécifications ou destinés à la visualisation pour l’évaluation de l’aspect interface usager

du système.

2.1.2. Contenu des scénarios

Le contenu d’un scénario fait référence au type d’informations et de connaissances qui y

sont capturées. En effet, les scénarios peuvent adresser les niveaux organisationnels ou

stratégiques d’un système (scenario in the wide) [Kyn95], comme ils peuvent concerner

des descriptions détaillées de comportement (scenario in the narrow) [Jac96]. Selon Kuuti

[Kuu95], le contenu d’un scénario peut décrire le fonctionnement interne du système en

main, les interactions entre le système et son environnement, et possiblement les aspects

organisationnels du système. Selon la communauté du requirements engineering, les

31

scénarios peuvent décrire les aspects fonctionnels, non-fonctionnels et intentionnels d’un

système [Dar93]. L’aspect fonctionnel concerne la structure, le comportement et les

fonctions du système. L’aspect non-fonctionnel correspond entre autres à des

considérations organisationnelles ou de performance ou de gestion de risques. L’aspect

intentionnel concerne les approches basées sur les buts (goal driven approach) et les

responsabilités (responsability driven approach).

Le contenu des scénarios dépend aussi de la manière dont les scénarios décrivent le

système. On distingue entre les scénarios abstraits et les scénarios concrets. Les scénarios

abstraits font référence de manière abstraite à des objets du système (client, fournisseur,

etc.), tandis que les scénarios concrets utilisent des instances particulières d’objets

(Université de Montréal, Prosys Inc., etc.).

2.1.3. But des scénarios

Pour quels buts sont utilisés les scénarios ? Comme nous l’avons déjà cité dans

l’introduction de ce chapitre, les scénarios ont été utilisés entre autres pour la capture des

besoins utilisateurs [Jac92, Pot94], pour la description des interactions utilisateurs [Nar92,

Car95], et pour l’investigation de nouvelles solutions dans les approches de réingénierie

[Cam92]. Similairement aux approches de prototypage [Bis92], on peut donc dire que les

scénarios sont utilisés pour des buts de description, d’explication ou d’exploration. Les

scénarios de description sont surtout utilisés pour comprendre et décrire les aspects

comportementaux d’un système où les scénarios représentent les points de vue des

utilisateurs externes du système. Les scénarios d’exploration sont utilisés quand plusieurs

solutions sont à explorer et à évaluer dans le but de sélectionner la meilleure. Ce type de

scénario encourage la recherche de nouvelles alternatives et élargit le champ de solutions

pour un problème donné. Les scénarios d’explication enfin servent à défendre une position,

un choix ou un point de vue. Ils sont utilisés pour argumenter l’adéquation ou

l’inadéquation d’une telle ou telle solution. Après utilisation des scénarios d’exploration,

les scénarios d’explication sont utilisés pour argumenter et détailler la solution retenue.

32

2.1.4. Cycle de vie des scénarios

Si on considère les scénarios décrivant un système comme étant des objets du système, on

peut alors parler de scénarios persistants par analogie aux objets persistants. Les scénarios

persistants accompagnent le projet depuis l’analyse des besoins jusqu’à la production de la

documentation [Pot94, Jac92]. Par opposition, on définit les scénarios temporaires comme

ayant servi uniquement au niveau de certaines étapes du cycle du développement. C’est le

cas, par exemple, où les scénarios ont été utilisés uniquement pour l’acquisition des

besoins, ou pour supporter la production de diagrammes d’états des objets du système

[Rum91] ou bien pour la validation des besoins [Hsi94].

Qu’il s’agit de scénarios persistants ou temporaires, un scénario peut être l’objet des

opérations suivantes durant son cycle de vie : capture (création), raffinement, intégration,

extension et suppression.

L’opération de capture concerne la création de nouveaux scénarios soit directement à

travers les utilisateurs du système, soit à partir de scénarios existants (synthèse de

scénarios).

L’opération de raffinement transforme un scénario dans le but de le rendre plus lisible et

plus réutilisable. On peut par exemple utiliser les relations uses et extends (figure 13)

définies par Jacobson [Jac92, Rum99] pour alléger le contenu d’un scénario ou pour

l’étendre avec de nouvelles connaissances et fonctionnalités.

L’opération d’intégration tente de rassembler les vues partielles décrites dans les scénarios

pour obtenir une vue globale du système. Ceci peut être réalisé à l’aide d’algorithmes

d’intégration [Hsi94, Kos94,Des98, Som97, Elk98, Khr99] ou d’opérateurs de composition

[Gli95].

L'opération d’extension consiste à ajouter à un scénario existant de nouvelles

connaissances pour décrire des situations réelles ou souhaitées du système [Kyn95].

L’opération de suppression met fin à la vie d’un scénario après son utilisation.

33

2.2. La notation UML et l’utilisation des scénarios

Les scénarios trouvent leur place dans la plupart des méthodes orientées objet (OMT,

Fusion, OOSE, etc.) pour identifier les objets du système et représenter les exigences

fonctionnelles. Dans la méthode OOSE [Jac92], les scénarios (cas d’utilisation) dirigent

toutes les étapes de la conception orientée objet. Ils sont utilisés comme point de départ

pour la construction de tous les autres modèles de la méthode à savoir le modèle objet, le

modèle d’analyse, le modèle de conception, le modèle d’implantation et le modèle de tests.

Dans ce qui suit, nous allons décrire la notation UML qui se définit comme une notation

standard pour les méthodes orientées objet. UML offre un cadre intéressant pour les

scénarios sur lequel nous avons basé nos travaux de recherche.

La notation UML qui fait partie des standards de l’OMG (Object Managment Group), est

le fruit des efforts d’unification de plusieurs méthodes orientées objet dans le but de

bénéficier de tous les avantages de celles-ci. Dans sa première version [Boo95],

l’unification concernait uniquement les méthodes OMT et Booch. L’ajout de la méthode

OOSE a permis à UML de disposer d’une notation riche couvrant toutes les étapes de

développement.

Les termes scénario et cas d’utilisation ont été utilisés dans plusieurs travaux pour designer

le même concept. Dans UML une distinction entre les deux termes est faite, et des

définitions précises sont données. Un cas d’utilisation (use case) est défini comme une

suite d’interactions avec le système dans le but de réaliser une transaction entière (tâche du

système). Il est généralement décrit par plusieurs scénarios. Ceci permet une acquisition

structurée des scénarios par cas d’utilisation. Un scénario est donc une instance d’un cas

d’utilisation, qui décrit une suite possible d’interactions dans la réalisation d’une tâche du

système.

UML ne définit pas un processus particulier pour le développement d’applications ; elle

offre plutôt une notation unifiée pour décrire les systèmes par l’intermédiaire de modèles

ou diagrammes. La méthode définit neuf types de diagrammes : le diagramme de classes et

34

le diagramme d’objets pour modéliser les données du système ; le diagramme de cas

d’utilisation, le diagramme de séquence, le diagramme de collaboration, le diagramme

d’états et le diagramme d’activités pour l’aspect dynamique ; et les diagrammes de

composants et de deploiement pour decrire l’aspect physique du système. Ces diagrammes

seront expliqués dans ce qui suit, avec une emphase sur ceux qui concernent les scénarios

(diagramme de cas d’utilisation, diagramme de collaboration et diagramme de séquence).

2.2.1. Diagramme de classes (ClassD)

Un ClassD correspond à la vue statique du système. Il permet d’identifier toutes les classes

du système et de spécifier pour chaque classe ses attributs, ses opérations et ses liens avec

les autres classes du système. La figure 23, donnée plus loin, montre le ClassD du système

ATM (Automatic Teller Machine). Les relations entre classes permises par le ClassD

d’UML sont les associations, les agrégations (composition) et les généralisations

(héritage). Le ClassD est sans doute le diagramme central de toute la modélisation objet. Il

est souvent enrichi et complété au fur et à mesure de l’élaboration des autres diagrammes.

2.2.2. Diagramme d’objets (ObjectD)

Un ObjectD représente une vue du ClassD. C’est un prototype des relations structurelles

qui peuvent exister entre un ensemble d’instances de classes.

2.2.3. Diagramme de cas d’utilisation (UseCaseD)

Un UseCaseD montre les différents cas d’utilisation du système et les différents acteurs qui

interagissent avec le système. La figure 24 montre le UseCaseD du systeme ATM. Un cas

d’utilisation décrit une transaction complète faisant interagir les acteurs et les objets du

système. Un acteur est un objet externe du système qui interagit avec ce dernier dans le but

d’obtenir un service offert par le système. Les cas d’utilisation sont représentés au sein du

UseCaseD par des ellipses, et les acteurs sont représentés par des icônes (voir figure 13).

Un cas d’utilisation peut appeler les services d’un autre. UML définit deux relations

permettant la structuration et la réutilisation des cas d’utilisation : utilise (uses) et étend

35

(extends)1. Elles sont représentées par des flèches orientées de l’appelant vers l’appelé

étiquetées par le type de relation (voir figure 13).

Figure 13 : Exemple d’un UseCaseD.

La figure 13 montre un exemple d’un UseCaseD comportant quatre cas d’utilisation (UC1,

UC2, UC3, et UC4) et deux acteurs interagissant avec trois de ces cas d’utilisation (lignes

continues).

La relation utilise (uses) entre deux cas d’utilisation (UC1 uses UC3 dans la figure 13)

signifie que le premier cas d’utilisation (UC1) inclut toujours le comportement du

deuxième cas d'utilisation (UC3).

La relation étend (extends) entre deux cas d’utilisation (UC3 extends UC2 dans la figure 13)

signifie que le deuxième cas d’utilisation (UC2) peut se comporter sous certaines

conditions (point d’extension) comme le premier cas d’utilisation (UC3).

Dans nos travaux de recherche, nous avons considéré uniquement la relation uses. La

relation extends peut être vue comme une relation uses avec une condition sur l’appel.

Un cas d’utilisation est généralement décrit par un ensemble de scénarios. Un scénario est

une exécution (instance) du cas d’utilisation et correspond à une série particulière

d’interactions entre les objets du système. Dans UML, les scénarios peuvent être décrits en

utilisant soit les diagrammes de séquence, soit les diagrammes de collaboration. Les deux

1 La version 1.3 d’UML n’apporte cependant pas de nouveaux concepts pour les cas d’utilisation. La relation uses a été renommée en includes, la relation extends a gardé la même signification que dans la version 1.1. Une nouvelle relation de généralisation (generalisation) a été introduite pour modéliser les relations de spécialisation entre cas d’utilisation.

UC1

UC3 UC2

UC4

<<uses>>

<<extends>>

36

types de diagrammes reposent sur la même sémantique, et il est toujours possible de passer

d’un type de diagramme à l’autre.

2.2.4. Diagramme de séquence (SequenceD)

Un SequenceD permet de montrer le séquencement des messages échangés entre les objets

participant dans un scénario. La figure 25 illustre deux SequenceDs décrivant deux

scénarios du système ATM. Les lignes verticales (figure 14) représentent les objets et les

flèches horizontales représentent les messages échangés. Dans ce type de diagramme, on

s’intéresse à l’ordonnancement des messages en fonction du temps (l’axe du temps croît du

haut vers le bas).

Un SequenceD peut capturer de manière visuelle des comportements conditionnels,

itératifs et concurrents. La figure 14 illustre certains de ces comportements, par exemple,

les messages mes2 et mes3 représentent un comportement conditionnel. Les messages mes4

et mes6 donnent lieu à un comportement concurrent de l’objet Objetn.

37

Figure 14 : Exemple d’un SequenceD.

2.2.5. Diagramme de collaboration (CollD)

Un CollD montre plus la structure des interactions entre les objets et leurs inter-relations

que la dimension temporelle du scénario (la figure 40 montre des exemples de CollDs du

systeme ATM). Le CollD montre à la fois une vue statique et dynamique du système à

travers le scénario qu’il décrit. En effet, un CollD sans interactions n’est rien d’autre

qu’une partie du ClassD ou de l’ObjectD.

À la différence des SequenceDs, un CollD montre la structure des interactions entre les

objets d’un scénario en utilisant des opérateurs tels que la séquentialité, le raffinement,

l’itération et la concurrence. Ces opérateurs sont exprimés par une numérotation qui est

dérivée de la méthode Fusion [Col93] : la séquentialité est représentée par l’incrémentation

de la numérotation (1 :message1, 2 :message2, etc.). Le raffinement est exprimé par la

notation pointée (1 :message1, 1.1 :message11, 1.2 :message12 veut dire que le message1 est

raffiné en message11 et message12). La concurrence est exprimée par des lettres (A, B, etc.

ou a, b, etc.).

Objet Objet Objet mes1

[C1] mes2

mes5

... Objet

[C2] mes3 mes4

mes6

1:msg1 1.1:msg2

1.2:msg6

1.1.A1:msg3

1.1.B1:msg4

1.1.B2:msg5 :Objet1 :Objet4

:Objet3

:Objet2

38

Figure 15 : Exemple d’un CollD.

L’exemple de la figure 15 montre un CollD composé de quatre objets qui interagissent

entre eux en s’échangeant des messages. Dès que l’objet1 reçoit le message msg1, ce dernier

est raffiné par deux messages séquentiels msg2 et msg6. msg2 est à son tour raffiné par deux

groupes de messages concurrents (msg3 et (msg4 ;msg5)). L’ordonnancement des messages

occurrents dans ce CollD est illustré dans la figure 16.

Figure 16 : Séquencement des messages du CollD de la Figure 15.

Le CollD est représenté par un graphe dont les nœuds sont les objets qui participent dans le

scénario et les arcs représentent les relations structurelles entres ces objets (association,

agrégation et généralisation). Les arcs sont étiquetés par un ou plusieurs messages qui

peuvent être échangés dans les deux sens. La structure d’un message respecte la forme

suivante :

[pre-requis] [condition] numero_sequence [iteration] [variable_retour :=]

nom_message([arguments])

• [pre-requis] : est une liste de numéros de séquence séparés par des ‘,’ et terminée par

‘/’. Ces numéros de séquence correspondent à des messages qui doivent avoir été émis

avant le message courant (synchronisation).

msg1 msg2 msg3 msg6

msg4 msg5

39

• [condition] : est une expression logique qui doit être vérifiée pour que le message soit

émis.

• numero_sequence : représente le numéro de séquence du message qui indique l’ordre

du message dans toute l’interaction. Un numéro de séquence est une suite de termes

séparés par un ‘.’ Et terminée par ‘ :’. Chaque terme a la forme suivante : entier |

lettre_maj entier | entier lettre_min. Les lettres majuscules et minuscules sont utilisées

pour modéliser des messages concurrents (A2 présente le message 2 du thread A et 2a

représente le thread a du message 2).

• [iteration] : modélise le fait que le message soit émis plusieurs fois. L’itération est

représentée par : *[clause]. La clause est exprimée en pseudo-code ([i :=1..n] ou

[condition]).

• [variable_retour] : sert à récupérer la valeur de retour du message.

• [arguments] : représente la liste des paramètres du message.

Pour une description complète de la grammaire des CollDs, consultez l’annexe A.2 de ce

document.

2.2.6. Diagramme d’états (StateD)

Un StateD modélise le comportement d’un objet en représentant les états de l’objet et les

transitions entre ces états. La figure 42 montre un exemple de StateD de l’objet GAB du

système ATM. Les événements correspondant aux messages échangés entre les objets dans

un CollD ou dans un SequenceD permettent de franchir des transitions du StateD et de

changer l’état de l’objet. Un StateD est représenté par un Statechart tel que défini par Harel

[Har87].

Dans un Statechart, un état peut être décomposé récursivement en états exclusifs (or-state)

ou concurrents (and-state). Les types d’états supportés par les Statecharts sont donnés ci-

après :

• simple : état qui ne subit aucune décomposition,

40

• or-state : état composite comprenant une liste d’états exclusifs,

• and-state : état composite comprenant plusieurs états concurrents.

Un état simple ou composite peut être décoré par les annotations suivantes :

• Initial : pour indiquer l’état initial du super-état dont il fait partie.

• Final : pour indiquer la fin du super-état dont il fait partie.

• Historique : pour mémoriser les sous-états qui ont été actifs dans un état composite (H).

Les transitions permettent le changement d’états au sein d’un Statechart. Une transition est

étiquetée par un événement, une condition et des actions (event[cond]/actions). Quand

l’événement event surgit et si la condition cond est vraie, le système quitte l’état de départ

de la transition, exécute la liste des actions et entre l’état d’arrivée. Les transitions entre

états de threads différents d’un and-state ne sont pas permises.

Une description détaillée de la syntaxe d’un Statechart est donnée sous forme de

grammaire dans l’annexe A.3.

2.2.7. Diagramme d’activités (ActivityD)

Le diagramme d’activités est un cas particulier du StateD où les transitions sont

automatiquement déclenchées après la fin des actions associées aux états. Un ActivityD

peut être associe à une classe ou à une opération d’une classe. Il est proche du modèle

fonctionnel qui est défini dans la méthode OMT.

2.2.8. Diagramme de composants (ComponentD)

Le diagramme de composants décrit les éléments physiques logiciels (composants) et leurs

relations dans le système en cours de modélisation. Dans ce diagramme, on distingue trois

types de composants : les spécifications (interface de classes), les corps (réalisations de

classes) et les spécifications génériques (classes paramétriques). Un composant peut faire

référence au service d’un autre par le biais d’une relation de dépendance.

41

2.2.9. Diagramme de déploiement (DeploymentD)

Le diagramme de déploiement indique la disposition des éléments physiques matériels qui

composent le système, ainsi que la disposition des différents composants logiciels sur le

matériel du système.

2.2.10. Les aspects de scénarios dans UML

Par rapport au cadre de classification des scénarios présentée dans la section 2.1 de ce

chapitre, UML n’impose aucune contrainte sur les aspects but et contenu des scénarios. En

effet, les scénarios d’UML peuvent être utilisés pour des buts de description, d’explication

et d’exploration. Les connaissances et les informations qui y sont décrites dépendent

uniquement du domaine d’application.

Au niveau de l’aspect forme (section 2.1.1), UML propose une notation semi-formelle

(UseCaseD, SequenceD et CollD), d’une sémantique riche, pour spécifier et structurer les

scénarios d’un système. UML ne supporte pas les opérations de validation et d'évaluation

des scénarios. Les approches SUIP-PN et SUIP-SC supportent ces opérations dans le cadre

de la notation UML.

Les opérations définies dans l’aspect cycle de vie des scénarios (section 2.1.4) sont toutes

supportées par UML à part l'opération d'intégration de scénarios. Les approches SUIP-PN

et SUIP-SC proposent deux nouveaux algorithmes pour l'intégration des scénarios d’UML.

2.3. Scénarios et algorithmes d’intégration

Les scénarios étant des descriptions partielles, le comportement global du système ne peut

être obtenu que par la composition ou l’intégration de l’ensemble des scénarios. Cette

composition peut être soit séquentielle soit concurrente dépendamment du type du système.

La composition séquentielle fournit un comportement global où les scénarios peuvent être

exécutés séquentiellement ou alternativement. Ce type de composition a fait l’objet de

plusieurs travaux de recherches [Hsi94, Kos94, Kaw97, Som97, Des98].

42

La composition concurrente fournit un comportement global où le comportement de

chacun des scénarios peut s’exécuter en concurrence ou en entrelacement avec les autres.

Ce type de composition peut servir pour décrire des tâches indépendantes ou coopérantes

et des sous-systèmes séparés. Peu de travaux ont adressé ce type de composition [Gli95,

Dan97].

Pour pouvoir dériver automatiquement le comportement global du système à partir des

comportements partiels des scénarios, un besoin de formalisation s’impose. Ainsi un

scénario sera représenté par un modèle formel et l’intégration des scénarios sera

équivalente à une augmentation incrémentale de la spécification du système par celles des

scénarios ou à une opération de composition en utilisant des opérateurs.

Dans le reste de cette section, nous allons décrire brièvement certains travaux de

composition de scénarios. Nous présenterons d’abord des approches pour la composition

séquentielle (sections 2.3.1 à 2.3.5) et ensuite deux approches pour la composition

concurrente (sections 2.3.6 et 2.3.7).

2.3.1. Approche de Hsia et al.

Dans leur approche, Hsia et al. [Hsi94] décrivent les scénarios comme un arbre orienté

dont les nœuds représentent les états du système et dont les arcs représentent les

événements qui permettent de passer d’un état à un autre.

La composition séquentielle de deux scénarios revient à faire la fusion (merge) de leurs

arbres correspondants. L’arbre fusionné (figure 17(a)) est transformé en une grammaire

(figure 17(b)) qui sera la base pour la génération de l’automate modélisant le

comportement de tout le système.

Dans leur approche, Hsia et al. voient un scénario comme une trace d’exécution, et leur

intérêt porte plus sur l’analyse que sur l’intégration des scénarios.

43

Figure 17 : Exemple de scénario composé dans l’approche de Hsia et al. [Hsi94].

2.3.2. Approche de Koskimies et Makinen

L’algorithme d’intégration proposé par Koskimies et Makinen [Kos94] permet d’inférer un

automate modélisant le comportement d’un objet du système à partir d’un ensemble de

scénarios. Cette approche est basée sur la méthode OMT où les scénarios sont représentés

sous forme de diagrammes de séquencement de messages semblables aux SequenceDs

d’UML. L’idée derrière cet algorithme est résumée ci-après :

Soit O un objet du système pour lequel on désire synthétiser le comportement, et soit SO=

{sc1, sc2, …, sck} l’ensemble des scénarios dans lesquels l’objet O interagit avec le reste

des objets du système (il se peut qu’un objet ne participe pas dans certains scénarios).

Pour chaque sci de SO, on dérive une trace ti = {(e1,r1), (e2,r2), … (em,rm)} représentant

l’ensemble des couples événements émis (ei) et reçus (ri) par l’objet O. Des événements

‘null’ et ‘default’ ont été introduits pour avoir dans la trace ti des couples de messages sous

la forme (émission, réception). Les messages reçus (ri) par l’objet O permettent de changer

son état, et les messages émis (ei) sont considérés comme des actions exécutées par l’objet.

Les traces des différents scénarios sont ensuite concaténées en une seule trace T, qui sera

introduite comme entrée à l’algorithme de génération d’un automate minimal pouvant

exécuter la trace T. L’algorithme est basé sur la méthode de Bierman [Bie76] qui permet

de synthétiser un programme à partir de ses traces d’exécution. Il prend comme nombre

<S1>

<S0>

evt1

<S2> <S3>

<S4>

evt2 evt3

evt4

(a) (b)

G = (NT,∑ , S, R) où NT = {<S0>, <S1>, <S2>, <S3>, <S4>}, ∑ = {evt1, evt2, evt3,evt4}, S = <S0> étant l'état initial, R = { <S0> → evt1 <S1> <S1> → evt2 <S2> <S1> → evt3 <S3> <S3> → evt1 <S4>}

44

d’états au départ le nombre N d’actions différentes dans la trace T. S’il y a un conflit dans

la construction de l’automate, le nombre N est incrémenté et l’automate est reconstruit de

nouveau.

L’algorithme génère un automate minimal, mais il prend un temps exponentiel à cause du

backtracking. En plus, l’algorithme est sensible à l’ordre de concaténation des traces ti.

2.3.3. Approche de Kawashita et al.

Dans l’approche Kawashita et al. [Kaw97], un scénario est représenté par un automate à

états finis. L’intérêt est porté sur les états du système et non des objets. L’approche

comprend deux étapes soient l’analyse et l’intégration des scénarios.

L’activité d’analyse permet d’extraire d’un scénario toutes les informations pertinentes à

l’intégration : les objets, leurs états et les dépendances entre objets. Les résultats de cette

étape sont données sous forme d’une table qui décrit les états des objets identifiés dans le

scénario, et d’une liste de dépendances entre les états des objets du scénario (Exemple :

l’objet O1 ne peut être dans l’état e1 que si O2 est dans l’état e2) qui découle en général des

règles de gestion du système. Un état potentiel du système est obtenu à partir d’un scénario

par le produit cartésien des ensembles des états des objets du scénario restreint par le

respect de la liste de dépendances entre les objets du scénario. L’automate modélisant les

interactions dans le scénario peut être facilement obtenu.

L’étape d’intégration consiste à incrémenter une spécification initiale scénario par scénario

pour déterminer l’automate décrivant le comportement de tout le système. L’algorithme

comporte trois sous-étapes : la détermination de tous les états système, le lien de ces états

par les transitions identifiées au niveau des scénarios, et l’élimination des états disjoints

(qui ne peuvent être atteints) en faisant une analyse d’accessibilité. L’algorithme identifie

les états communs dans des scénarios distincts et les fusionne sans se soucier de leurs

relations mutuelles. Il est insensible à l’ordre d’intégration des scénarios, et il est

45

exponentiel à cause du produit cartésien des ensembles des états des différents objets du

système.

2.3.4. Approche de Desharnais et al.

Dans l’approche de Desharnais et al. [Des97], un scénario est vu comme une suite

d’événements externes provenant de l’environnement du système, et une suite de réactions

du système à ces événements. À partir d’une description informelle d’un scénario,

l’analyste détermine un ensemble de structures nécessaires à la description formelle :

A : l’ensemble des symboles (alphabet) qui comporte entre autres les objets du

système ;

A+ : une séquence non vide d’éléments de A et A* ≡ A+ ∪ {λ} ou λ est la séquence

vide ;

C : l’ensemble des commandes entrées par l’utilisateur avec C ∩ A = ∅ ;

La liste des relations entre certains éléments de A+.

Formellement un scénario est défini comme un triplet (T, Re, Rs) où T est l’espace des

symboles, Re la relation de l’environnement qui capture les actions de l’environnement sur

le système et Rs la relation du système représentant les réactions de ce dernier. La relation

Re ∪ Rs représente le scénario avec Re ∩ Rs = ∅ .

L’opération d’intégration est faite par la composition des relations correspondantes aux

scénarios :

Soient deux scénarios SM = (TM, ReM, RsM) et SN = (TN, ReN, RsN). Le scénario résultant SP =

(TP, ReP, RsP) est défini par : ReP ≡ (ReM ↑ TP) ∪ (ReN ↑ TP) et Ps ≡ (RsM ↑ TP) Π (RsN ↑

TP) où :

TP est la concaténation de TM et TN ;

Q Π R = (Q ∩ R) ∪ (R ;V ∩ Q) ∪ (Q ;V ∩ R) est l’intersection démoniaque ;

R ↑ T est l’ouverture de R sur T ;

46

Q = {(s,s’) | (s,s’) ∉ Q} est le complement de Q et V = T x T est la relation

universelle ;

Q ; R = {(s,s’) | s” : (s,s”) ∈ Q ∧ (s”,s’) ∈ R} est l’operation de composition.

La relation ReP représente la réunion des entrées dans les deux scénarios, et la relation RsP

exprime le fait que le système se comporte de la même façon pour les parties communes

des deux scénarios et se comporte respectivement comme SM et SN dans les parties propres

à ces scénarios. L’approche ne prend en compte que des scénarios exhibant des

comportements séquentiels.

2.3.5. Approche de Somé et al.

Somé et al. [Som96, Som97] proposent une méthode pour l’ingénierie des exigences basée

sur les scénarios. Leur intérêt porte sur les systèmes à temps réel où le comportement est

régi par des aspects temporels. La nouveauté dans cette approche est l’intégration des

contraintes temporelles dans l’expression des scénarios.

La représentation des scénarios est faite dans un langage semi-formel présentant une

syntaxe constituée de phrases en langage naturel et des opérateurs temporels (WHEN, AT,

BEFORE, AFTER, etc.). Un exemple de cette représentation est donné dans la figure 18.

Figure 18 : Exemple de scénario pour un guichet automatique [Som97].

WHEN display is card_insert_prompt

IF USER insert card THEN ATM display pin_enter_prompt AFTER 5 sec IF USER enter THEN ATM checks id TRANSITION DELAY 60 sec ON EXPIRY ATM ejects card, ATM reinits IF id is invalid AND numbers_attempts becomes greater than 3 THEN ATM retains card, ATM reinits

47

Ainsi un scénario peut être vu comme un ensemble de traces temporisées (opi, τi) où les opi

sont les opérations et τi leur moment d’exécution. L’exécution d’une opération opi entraîne

la suppression de certaines conditions antérieures et l’ajout de nouvelles.

La composition des scénarios proposée est aussi incrémentielle. Elle consiste à déterminer

les états et les transitions d’un automate temporisé [Alu94] capable d’inclure les différentes

traces.

L’algorithme produit un automate non déterministe à cause des transitions automatiques

entre les super- et les sous-états. Il prend un temps exponentiel, et il n’est pas sensible à

l’ordre d’intégration des scénarios.

2.3.6. Approche de Glinz

Glinz [Gli95] représente les scénarios sous forme de Statecharts et propose une intégration

par l’utilisation d’opérateurs tels que : séquence, itération, alternance et concurrence

(figure 19).

Figure 19 : Opérateurs de composition de scénarios dans l’approche de Glinz[Gli95].

Le problème de recouvrement de plusieurs scénarios n’est pas traité dans cette approche.

Glinz le considère comme un travail qui doit être fait par l’analyste avant la composition.

Glinz propose donc une composition des cas d’utilisation, plutôt qu’une composition des

scénarios.

Cond ¬ Cond Cond ¬ Cond • •

sequence alternative iteration concurrence

48

2.3.7. Approche de Dano et al.

Dano et al. [Dan97] proposent une approche basée sur les cas d’utilisation pour produire

une spécification du comportement dynamique du système en réseaux de Petri. Les cas

d’utilisation sont acquis sous forme de tables PUCTs (Partial Use Case Table). Chaque

table représente en ligne la suite des fonctions permettant de réaliser le cas d’utilisation et

en colonne la liste des objets concernés avec deux colonnes supplémentaires : une

correspondante aux pré-conditions de la fonction et l’autre aux hypothèses prises dans

l’exécution de la fonction.

À partir des PUCTs, ils dérivent un ensemble de Réseaux de Petri (RdP) en se basant sur

un ensemble de règles. Le RdP global est obtenu par la composition de ces RdPs par des

liens temporels. Cette approche supporte sept liens temporels entre deux cas d’utilisation

uc1 et uc2 (voir figure 20).

Figure 20 : Liens temporels entre cas d’utilisation [Dan97].

L’aspect concurrence est bien exprimé dans cette approche à travers les relations

temporelles entre les différents cas d’utilisation.

2.4. Conclusion

Au vu des travaux d’intégration décrits dans la section précédente, on peut distinguer deux

visions pour l’analyse du comportement d’un système :

uc1 egal uc2

uc1 avant uc2

uc1 rencontre uc2

uc1 durant uc2

uc1 termine uc2

uc1 commence uc2

uc1 chevauche uc2

49

• Une vision objet où on s’intéresse au comportement d’un objet du système, qui est

dérivé à partir de son comportement dans les scénarios où il interagit avec le reste des

objets.

• Une vision système où on analyse tous les objets d’un scénario pour en déduire un état

scénario ou système, puis on analyse l’impact des interactions sur les états systèmes.

Ces deux visions sont à explorer pour étudier leur impact sur l’aspect interface usager.

Il ressort également des travaux d’intégration précités, deux définitions pour les états d’un

système :

• un état défini par la liste des états des objets manipulés par le système,

• un état défini par le point d’exécution atteint par une succession d’événements.

Nous avons choisi d’utiliser la première définition parce qu’elle donne plus de sémantique

à la définition d’un état. La deuxième nécessite la définition de relations d’équivalence

entre les differentes traces d’exécution.

La majorité des approches utilisent des formalismes basés sur des états/transitions

(automate, automate temporisé, Statecharts et réseaux de Petri) à cause de leur adéquation

à la description des scénarios (suite d’actions / réactions). Cependant la plupart des

approches génèrent une spécification système large qui capture plus que les

comportements décrits dans les scénarios de départ. La figure 21 illustre ce problème.

La spécification résultat sc capture non seulement les deux scénarios sc1 (S1,S2,S3,S4,S5) et

sc2 (S1,S6,S3,S7,S5), mais aussi deux autres scénarios (S1,S2,S3,S7,S5) et (S1,S6,S3,S4,S5). Ce

problème a été résolu dans nos algorithmes d’intégration qui sont décrits dans les chapitres

suivants.

50

Figure 21 : Problème d’entrelacement entre scénarios.

Le tableau donné ci-après (Table 0) résume les principales caractéristiques des approches

discutées dans la section 2.3. ainsi que celles des approches discutées dans les chapitres 3

(SUIP-PN) et 4 (SUIP-SC). Le signe + signifie que l'approche supporte le critère. Le signe

- signifie que le critère n'est pas supporté dans l'approche.

Approche

Critère

Hsia Koskim-

ies

Kawash-

ita

Deshar-

nais

Somé Glinz Dano SUIP-PN SUIP-SC

Séquentielité + + + + + + + + +

Concurrence - - - - - + + + +

Overlapping + + + + + - + + +

Hiérarchie - - - - + - + + +

Interleaving - - - - - - - + +

Vision Système Objet Système Système Système Système Système Systeme Objet

Niveau Scénario Scénario Scénario Scénario Scénario UseCase UseCase UseCase

&Scénario

UseCase

&Scénario

Table 0: Principales caractéristiques des approches scénarios.

S1 S2 S3 S4 S5

S1 S6 S3 S7 S5

S1

S2

S3

S4

S5

S6 S7

sc1

sc2

sc

51

Chapitre 3

Vision système et formalisation des scénarios à l’aide des RdPs

Dans ce chapitre, nous allons présenté l’approche SUIP-PN pour la modélisation des

systèmes interactifs qui utilise les réseaux de Petri à haut niveau comme formalisme de

spécification. Cette approche propose un processus d’ingénierie des exigences permettant

de produire un prototype de l’interface usager du système, ainsi que la spécification du

comportement global du système à partir des scénarios.

Tout processus respectable d’ingénierie des besoins appliqué aux systèmes interactifs

devra produire une spécification du comportement du système pour des besoins de

validation et vérification, et également un prototype de l’interface usager pour une

évaluation avec les utilisateurs finaux. Notre objectif est de supporter toutes les activités de

ce processus par l’utilisation de techniques, d’outils et d’algorithmes afin d’automatiser le

maximum de ces activités.

Vu leur adéquation à l’acquisition des besoins, les scénarios sont utilisés comme moyen de

description du comportement du système. Étant des descriptions partielles, les scénarios

necessitent une opération d’intégration pour produire le comportement global du système.

Pour garder trace des différents scénarios de départ dans la spécification résultante, nous

avons pensé à formaliser chaque scénario par un RdP coloré (couleur distincte attribuée à

chaque scénario du système). Pour des raisons de modularité, nous nous sommes intéressés

séparément aux niveaux cas d’utilisation (CU) et scénario. Nous produisons un premier

52

RdP qui modélise le niveau CU, et plusieurs autres RdPs qui raffinent les CUs du premier

RdP.

Pour la production du prototype de l’IU, nous avons étudié la possibilité de pouvoir le

générer automatiquement à partir de la spécification globale du système. L’opération de

génération, qui est commune aux deux approches de modélisation SUIP-PN et SUIP-SC,

sera décrite en détail dans le chapitre 5.

Dans le but de valider nos idées, nous avons développé un environnement pour supporter

le processus d’ingénierie des besoins (voir annexe C). Dans cet environnement composé

d’algorithmes développés et d’outils, nous avions besoin entre autres d’un outil pour la

manipulation des RdPs (création, simulation et vérification) ayant les spécificités

suivantes :

• Support des couleurs, vu qu’on attribue à chaque scénario une couleur qui le distingue

des autres.

• Support de la hiérarchisation pour pouvoir lier les deux niveaux de modélisation que

nous avons considérés séparément.

• Support d’un éditeur graphique pour l’édition, la simulation et la vérification de

certaines propriétés des RdPs.

• Support de l’échange de données avec d’autres outils ou langage de programmation.

• Disponibilité gratuite.

Après avoir effectué une recherche des différents outils répondant aux critères précités en

se basant sur des classifications existantes [PNT99, Wol99], nous avons retenu l’outil

designCPN [Des99] dont la distribution est gérée par l’Université d’Aarhus au Danemark.

Cet outil supporte essentiellement la théorie des RdPs à haut niveau telle que définie par

Jensen [Jen95]. DesignCPN, qui est actuellement disponible sur des plates-formes MacOS,

Linux et Unix, offre les caractéristiques intéressantes suivantes outre sa gratuité et son

support des aspects couleur et hiérarchie :

53

• Il inclut le langage de marquage standard (ML) pour la définition des couleurs, des

conditions de garde au niveau des transitions et des fonctions de transformation de

jetons au niveau des arcs. ML est fortement typé, et il comprend plusieurs types et

structures de données (liste, ensemble, lot, etc.), ce qui offre plus d’expressivité lors de

la description des RdPs.

• Il offre un simulateur intelligent qui permet de tester automatiquement ou

interactivement des spécifications en RdPs.

• Il supporte un outil d’analyse de la structure des RdPs permettant de vérifier la majorité

des propriétés comportementales d’un modèle. Dans la version actuelle, la vérification

est basée sur la technique du graphe d’accessibilité. Une technique alternative, celle des

invariants, est pour le moment parmi les travaux futurs.

• Il inclut un outil d’évaluation de performance des systèmes. En effet l’outil sert aussi à

modéliser des RdPs temporisés où la composante temps peut être associée soit aux

transitions soit aux arcs sous forme d’une valeur, d’un intervalle ou même d’une

fonction aléatoire.

• Il permet l’échange de documents en offrant la possibilité de sauvegarder les RdPs sous

format SGML (Standard General Markup Language).

Dans le reste de ce chapitre, nous donnerons la définition des RdPs à haut niveau que nous

avons utilisé dans ce travail. Nous présenterons ensuite un aperçu du processus

d’ingénierie des besoins basé sur les RdPs. Enfin, nous détaillerons les différentes étapes

de ce processus.

3.1. Réseaux de Petri à haut niveau

Toute extension aux Réseaux de Petri de base (RdP) définit un RdP à haut niveau. Les

RdPs colorés, à prédicats, temporels, hiérarchiques, stochastiques sont des exemples de

telles extensions. Dans notre cas, cette extension concerne le support de la hiérarchisation

et de l’aspect couleur (différents types de jetons). Jensen [Jen95] propose une formalisation

54

des RdPs colorés hiérarchiques. Ainsi, il considère un RdP coloré (RdPC) non-

hiérarchique comme un tuple RdPC = (∑, P, T, A, N, C, G, E, I) avec :

(i) ∑ est un ensemble fini de types (colour sets).

(ii) P est l’ensemble des places.

(iii) T est l’ensemble des transitions.

(iv) A est l’ensemble des arcs tel que : P ∩ T = P ∩ A = T ∩ A = ∅ .

(v) N est la fonction de nœuds (node function), N : A → PxT ∪ TxP. La fonction N fait le lien entre les éléments de A avec des couples (place, transition) ou (transition, place).

(vi) C est la fonction de couleurs (colour function) qui associe à chaque place une couleur (élément de l’ensemble ∑). C : P → ∑.

(vii) G est la fonction de condition de garde (guard function) qui associe à chaque transition une expression booléenne (de type B={true, false}) telle que : ∀ t∈ T, [Type(G(t)) = B ∧ Type(Var(G(t))) ⊆ ∑].

(viii) E est la fonction des expressions des arcs (arc expression function). Elle détermine pour chaque arc l’expression des jetons qu’il consomme ou qu’il produit dépendamment s’il s’agit d’un arc de P vers T ou de T vers P. ∀ a∈ A, [Type(E(a)) = C(p(a)) ∧ Type(Var(E(a))) ⊆ ∑]. La première partie de cette proposition signifie que le type de l’expression de chaque arc doit être compatible avec la place de départ (cas d’un lien place-transition) ou la place d’arrivée de l’arc (cas d’un lien transition-place). La deuxième indique que toutes les variables utilisées dans l’expression doivent faire partie de l’alphabet du RdPC.

(ix) I est la fonction d’initialisation (initialization function), définissant le marquage initial du RdPC. Elle associe à chaque place les jetons qu’elle contient sous forme d’expression. Le marquage doit être compatible avec la couleur de la place. ∀ p∈ P, [Type(I(p)) = C(p)].

L’aspect hiérarchique améliore la modularité des RdPs spécifiés. Il permet aux analystes

de construire des RdPCs de grande taille par la combinaison d’un nombre de RdPCs de

petite taille. Il est toujours possible de passer d’un RdPC hiérarchique à un RdPC non-

hiérarchique (mise à plat) afin de lui appliquer des algorithmes de vérification existants.

55

Jensen [Jen95] définit un RdPC hiérarchique comme un ensemble de RdPCs (pages) liées

par la substitution des transitions et/ou les places de fusion. La substitution d’une transition

permet de raffiner une transition d’un RdPC par un autre RdPC. Les places de fusion

permettent de spécifier que différentes places sur différentes pages sont identiques.

Formellement un RdPC hiérarchique est défini comme un tuple RdPCH = (S, SN, SA, PN,

PT, PA, FS, FT, PP) où :

(i) S est un ensemble fini de pages (set of pages) tel que : chaque page s∈ S est un RdPC non-hiérarchique (∑s, Ps, Ts, As, Ns, Cs, Gs, Es, Is) et que des pages différentes ont des ensembles disjoints. ∀ s1,s2∈ S : [s1 ≠ s2 ⇒ (Ps1 ∩ Ts1 ∩ As1) ∪ (Ps2 ∩ Ts2 ∩ As2) = ∅ ].

(ii) SN ⊆ T est l’ensemble des transitions substituées (set of substitution nodes), avec T = ∪ Ts pour tout s∈ S.

(iii) SA est la fonction d’assignation des pages (page assignment function), SA : SN → S.

(iv) PN ⊆ P définit un ensemble de ports (port nodes), avec P = ∪ Ps pour tout s∈ S. Cet ensemble représente les places qui sont liées aux transitions substituées (∈ SN).

(v) PT définit le type de port (port type function), PT : PN → {in, out, i/o, general}. Elle associe à chaque place liée à une transition substituée le type de liaison (entrée, sortie, entrée/sortie ou quelconque).

(vi) PA définit la fonction d’assignation des ports (port assignment function) qui permet d’associer les éléments de SN aux éléments de PN.

(vii) FS ⊆ P définit l’ensemble des places de fusion (fusion sets).

(viii) FT définit le type de fusion (fusion type) : fusion globale (dans tout le RdPCH) ou fusion par page (au sein d’une page).

(ix) PP est la page principale (Prime page) qui résume la structure en pages du RdPCH et définit le nombre d’instances de chaque page.

Dans ce travail, nous avons utilisé la substitution des transitions pour raffiner les

comportements des CUs d’un système.

56

3.2. Processus d’ingénierie des besoins utilisant les

RdPs

Le figure 22 présente l’ensemble des activités du processus d’ingénierie des besoins de

l’approche SUIP-PN. Ce processus raffine celui de la figure 1 dont le but est de combiner

dans le même processus les techniques de prototypage et les spécifications formelles.

S e q u e n c e D s

U s e C a s e DS p é c i f ic a t io n

d u s y s tè m e

G é n é r a t io nd u p r o to ty p e

P r o to ty p e d el ’ I U

I n té g r a t io nd e s s c é n a r io s

S y s tè m er é e l

A c q u is i t io nd e s b e s o in s

É v a lu a t io nd u p r o to ty p e

V é r i f ic a t io nd e s R d P s R d P s

R d P sI n té g r é s

C la s s D

Figure 22 : Activités du processus d’ingénierie des besoins de l’approche SUIP-PN.

Dans l’activité d’acquisition des besoins, l’analyse élabore le ClassD pour modéliser

l’aspect statique du système. L’aspect dynamique du système est modélisé par le

UseCaseD et l’ensemble des SequenceDs décrivant les différents CUs du système.

L’activité de spécification du système consiste à dériver un ensemble de RdPs à partir des

diagrammes précédemment acquis (UseCaseD et SequenceDs). Les RdPs qui

correspondent au même CU sont fusionnés dans l’activité d’intégration des scénarios. Les

RdPs intégrés seront les entrées des activités de vérification des RdPs et de génération du

prototype de l’IU. Le prototype généré sera ensuite exécuté et évalué par les utilisateurs

finaux du système dans l’activité d’évaluation du prototype. En cas de détection

d’incohérences ou d’incomplétudes lors des activités de vérification et/ou d’évaluation,

l’analyse apporte les modifications nécessaires aux scénarios acquis.

57

Dans les sections qui suivent, nous détaillerons les activités d’acquisition des besoins

(section 3.3), de spécification du système (section 3.4) et d’intégration des scénarios

(section 3.5). L’activité de génération du prototype de l’IU, qui est commune aux deux

approches SUIP-PN et SUIP-SC, sera décrite dans le chapitre 5. L’activité de vérification

des RdPs sera décrite dans la section 6.1 de ce document. Le système du guichet

automatique bancaire ATM (Automatic Teller Machine) est utilisé comme exemple

d’illustration.

3.3. Acquisition des besoins

Dans cette activité, l’analyste recueille auprès des utilisateurs les informations sur le

système à concevoir, puis il2 élabore dans un premier temps le ClassD pour modéliser

l’aspect statique du système. La figure 23 montre le ClassD du système ATM. Ensuite il

(elle) procède à l’acquisition des scénarios pour modéliser l’aspect dynamique du système.

interagit

utilisecrée

1 *

**

Clientid: Stringnom: Stringaddresse: Stringdate_naissance:String

Transaction

date_op: Datetype: Enumerationmontant: Real

enregistrer()supprimer()

Compte

numero: Stringmot_passe : Stringsolde: Real

verifier()modifier()

GAB

inserer_carte()entrer_pin()selectionner_op()pin_erreur()ejecter_carte()confirmer()

Banque

nom: Stringaddresse :String

appartient 1*

connecter()pin_valid()invalid_pin()

Figure 23 : ClassD du système ATM.

2 Il fait référence au masculin ainsi qu’au féminin.

58

Avant la description de l’opération d’acquisition des besoins, nous présentons dans ce qui

suit les extensions apportées aux scénarios d’UML afin de capturer les informations

spécifiques à l’IU et de faciliter la génération du prototype de celle-ci.

3.3.1. Extension des scénarios d’UML pour le support de l’IU

Nous avons d’abord procédé à la classification des scénarios en fonction de leur type et de

leur fréquence d’utilisation. Nous avons considéré deux types de scénarios : les scénarios

normaux qui arrivent dans des situations normales et les scénarios d’exception qui

décrivent des situations anormales ou des situations d’erreurs. La fréquence d’utilisation

(ou d’exécution) d’un scénario est définie comme un entier entre 1 et 10 assigné par

l’analyste pour indiquer combien de fois le scénario peut avoir lieu. Cette classification est

utilisée lors de la composition des blocs d’interface usager (voir section 5.3).

Les scénarios d’UML décrits sous forme de SequenceDs ou de CollDs capturent les

interactions entre les différents objets du système, et en particulier celles entre les

utilisateurs du système et le reste des objets. Afin de spécifier ce type d’interaction, nous

avons augmenté la description des scénarios (SequenceD ou CollD) par l’ajout des

informations spécifiques à l’IU sous forme de contraintes. Outre les contraintes UML

standards associées aux messages (vote, broadcast) [Rum99], nous avons défini deux

nouvelles contraintes : inputData et outputData associées aux messages interactifs. Un

message interactif est un message depuis ou vers un utilisateur du système.

Si on se réfère au patron MVC (Model View Controller) où une interaction doit être liée

aux éléments du modèle du système (ClassD), nous avons représenté ce lien par un

paramètre qu’on associe à la contrainte. Ce paramètre indique une relation de dépendance

au sens d’UML entre le message en question et les éléments du ClassD. Il peut

correspondre soit à un littéral, soit au nom d’une opération d’une classe, soit à un ou

plusieurs attributs de classe du ClassD.

59

La contrainte inputData indique donc que le message correspond à une entrée

d’information pour le système qui peut être :

• Soit une entrée de données, et le paramètre de la contrainte indiquera l’attribut

concerné par cette entrée. C’est le cas, par exemple, du message

entrer_pin{inputData(Compte.mot_passe)} de la figure 25(a) qui définit une entrée de

donnée liée à l’attribut mot_passe de la classe Compte.

• Soit une action (action d’un bouton ou sélection au sein d’un menu) sur la partie

visuelle (vue) de l’IU, et le paramètre de la contrainte indiquera dans ce cas le nom de

l’opération qui sera déclenchée après l’action. C’est le cas, par exemple, du message

inserer_carte{inputData(GAB.inserer_carte)} de la figure 25(a) qui définit une action

qui déclenchera l’opération inserer_carte de la classe GAB.

La contrainte outputData correspond à une sortie d’information (affichage de données sur

la partie visuelle de l’IU) destinée aux utilisateurs du système. C’est le cas, par exemple,

du message pin_erreur{outputData(« Pin incorrect »)} de la figure 25(b) qui correspond à

l’affichage du libellé à l’écran.

Le type du paramètre de la contrainte sert à déterminer le type de widget qui sera associé à

l’interaction utilisateur. En se basant sur les règles ergonomiques décrites dans [IBM91,

Bod94], nous avons retenu les règles suivantes pour la détermination des types de widget :

1. Un bouton est généré pour une inputData contrainte ayant comme argument une

opération.

2. Un textfield actif est généré pour une inputData contrainte ayant comme argument un

attribut de type entier, réel ou chaîne de caractères.

3. Un groupe de boutons radio est généré pour une inputData contrainte ayant comme

argument un attribut de type énumération et dont la taille est inférieure à 6.

4. Une liste de valeurs est générée pour une inputData contrainte ayant comme argument

un attribut de type énumération et dont la taille est supérieure à 6.

60

5. Une table est générée pour une inputData contrainte ayant comme argument une liste

d’attributs.

6. Les mêmes types de widget mais non activés (saisie inhibée) sont générés pour une

outputData contrainte.

7. Un label est généré pour une outputData contrainte ayant comme argument un littéral.

3.3.2. Acquisition des scénarios.

L’analyste commence par élaborer le UsecaseD qui capture les fonctionnalités du système.

Et pour chaque CU du UseCaseD, il (elle) élabore également les différents SequenceDs

correspondants aux scénarios qui le décrivent.

La figure 24 montre le UseCaseD du système ATM comportant l’acteur Client qui interagit

avec les CUs Identification, Retrait, Dépôt et Balance. Le CU Identification est lié aux

autres CUs par une relation d’utilisation (uses).

Identification

Retrait

Dépôt

Balance

<<uses>>

<<uses>>

<<uses>>Client

Figure 24 : Diagramme des cas d’utilisation du système ATM.

Les figures 25(a) et 25(b) montrent deux SequenceDs modélisant deux scénarios du CU

Identification : IdentReg décrit le scénario correspondant à une identification réussie du

61

client (scénario normal avec une fréquence de 10), et IdentErr (scénario d’exception avec

une fréquence de 5) décrit le cas où le client a entré un numéro d’identification erroné.

Figure 25 : Scénarios avec contraintes : (a) scénario IdentReg, (b) scénario IdentErr.

Si on applique aux scénarios de la figure 25 les règles de génération de widgets à partir des

contraintes (section 3.3.1), on obtient les scénarios de la figure 26 où les messages sont

annotés par le type de widget (voir légende de la figure 26).

:Client

entrer_pin {inpuData(Compte.mot_passe)}

selectionner_op {inputData(Transaction.type)}}

connecter verifier

pin_valid carte_valide

inserer_carte {inputData(GAB.inserer_carte)}

:GAB :Banque :Compte

confirmer {inputData(GAB.traiter_op)}

:Client

pin_erreur {ouputData("Pin incorrect")}

connecter verifier

invalide_pin invalide_carte

:GAB :Banque :Compte

ejecter_carte {inputData(GAB.eject_carte)}

inserer_carte {inputData(GAB.inserer_carte)}

entrer_pin {inpuData(Compte.mot-passe)}

(a)

(b)

62

Figure 26 : Scénarios avec widgets : (a) scénario IdentReg, (b) scénario IdentErr.

3.4. Spécification du système

Cette activité a pour but de construire deux niveaux de RdPs : le premier capturant les

interactions entre les différents CUs du système et le deuxième raffinant et détaillant le

comportement de chaque CU par la spécification de ses propres scénarios. L’opération de

production de spécifications suit les deux étapes suivantes : spécification des cas

d’utilisation et spécification des scénarios.

:Client

entrer_pin {INP}

selectionner_op {RAB}

connecter verifier

pin_valid carte_valide

inserer_carte {BUT}

:GAB :Banque :Compte

confirmer {BUT}

:Client

pin_erreur {LAB}

connecter verifier

invalide_pin invalide_carte

:GAB :Banque :Compte

ejecter_carte {BUT}

inserer_carte {BUT}

entrer_pin {INP}

(a)

(b)

Legende : BUT: Button RAB: Radio Button INP: Input Field TEX: Text Field LAB: Label

63

3.4.1. Spécification des cas d’utilisation

Le premier RdP est directement dérivé du UseCaseD en transformant les CUs en places.

Les transitions menant à ces places sont gardées par les conditions d’initialisation des CUs

par les acteurs. La place début est toujours utilisée pour modéliser l’état initial du système

avant toute exécution des différents CUs. Nous supposons qu’après exécution d’un CU, le

système revient à son état initial. La place début peut contenir plusieurs jetons pour

modéliser des exécutions parallèles de plusieurs CUs et de plusieurs copies du même CU.

La figure 27 montre le RdP dérivé du UseCaseD du système ATM.

Figure 27 : RdP généré à partir du UseCaseD de la figure 24.

Dans un UseCaseD, un CU peut utiliser les services d’un autre par le biais de la relation

uses. Cette relation peut avoir plusieurs significations. Considérons deux CUs Uc1 et Uc2.

La relation Uc1 uses Uc2 peut alors être interprétée de différentes façons. La figure 28(a)

montre le cas général de cette relation. Uc1 peut être vu comme étant décomposé en trois

sous-CUs : Uc11, Uc12 et Uc13. Uc11 correspond à la partie du CU qui précède l’appel de

Uc2, Uc12 est la partie de Uc1 qui est concurremment exécutée avec Uc2, et Uc13

correspond à la partie de Uc1 qui est exécutée après la terminaison de Uc2. Les figures

28(b) à 28(g) illustrent les différents cas particuliers de la figure 28(a) où un ou deux des

sous-CUs de Uc1 sont vides.

début

Enter Exit Enter Exit Enter Exit Enter Exit

Identification Retrait Dépôt Balance

64

Figure 28 : Raffinement de la relation uses.

Une relation de type (g) entre deux CUs Uc1 et Uc2 signifie que Uc2 précède Uc1. Ceci

implique que le Uc1 n’est accessible qu’à travers Uc2. Donc les transitions liant Uc1 à la

place début doivent être déplacées vers la place représentant Uc2. C’est le cas des relations

d’utilisation entre les trois couples de CUs du système ATM : (Dépôt, Identification),

(Retrait, Identification) et (Balance, Identification). Après la prise en considération du type

de relation entre les CUs, le RdP de la figure 27 est alors mis à jour pour obtenir le RdP de

la figure 29(a).

Figure 29 : (a) RdP mis à jour après raffinement de la relation uses (b) RdP adapté à l’outil designCPN.

(a)

(g)

(f)

(d) (c)

(b)

(e)

Uc11 Uc12

Uc2

Uc13 Uc11 Uc2 Uc13

Uc11 Uc12

Uc2

Uc12

Uc2

Uc13

Uc1 Uc2 Uc12

Uc2

(g) Uc2 Uc1

(a) (b)

Dépôt Balance

Enter Exit Enter Exit Enter Exit

Retrait

Enter Exit

début

Identification Identification

début

endIdentify

Retrait Dépôt Balance

65

L’outil designCPN, que nous avons utilisé dans ce travail, ne permet que le raffinement des

transitions. Une adaptation du RdP obtenu après raffinement de la relation uses est alors

nécessaire. Tout triplet Enter → Place → Exit (ellipse en pointillée sur la figure 29(a)) où

Place représente un CU, est substitué par une transition représentant le CU. Des places

intermédiaires telle que la place endIdentify de la figure 29(b) sont insérées en cas de

besoin.

3.4.2. Spécification des scénarios

Dans SUIP-PN, la spécification d’un scénario consiste à transformer le SequenceD qui le

décrit en un RdPC. Cette transformation suit deux étapes : la première détermine la

structure du RdPC, et la deuxième ajoute à cette structure la sémantique nécessaire pour

l’opération d’intégration des scénarios.

La structure du RdPC est automatiquement dérivée à partir du SequenceD. Le

séquencement et la numérotation des messages sont utilisés pour l’obtention d’un graphe

des messages échangés dans le SequenceD. La figure 30(b) illustre l’obtention du graphe

des messages à partir du SequenceD de la figure 30(a) décrivant un scénario séquentiel. De

même la figure 31(b) montre l’application de cette opération au SequenceD de la figure

31(a) capturant un scénario itératif et concurrent. La structure finale du RdPC est ensuite

obtenue à partir du graphe des messages en transformant les messages en transitions du

RdPC et en insérant entre chaque couple de transitions une place vide. Les figures 30(c) et

31(c) sont les résultats de l’application de cette transformation respectivement aux graphes

des messages des figures 30(b) et 31(b).

66

Figure 30 : (a) Scénario capturant un comportement séquentiel, (b) graphe des messages correspondant, (c)

RdP dérivé du graphe des messages.

Figure 31 : (a) Scénario capturant un comportement itératif et concurrent, (b) graphe des messages

correspondant, (c) RdP dérivé du graphe des messages.

L’ajout de sémantique à cette structure est fait par l’analyste en assignant au RdP une

couleur distincte de celles déjà assignées aux autres RdPCs du CU, et en étiquetant les

places vides du RdPC. L’étiquetage du RdPC est basé sur la table des états des objets que

l’analyste construit à partir du SequenceD. Les colonnes de cette table correspondent aux

objets qui figurent dans le SequenceD, et les lignes correspondent aux messages échangés

(voir table 1). L’intersection d’une ligne et d’une colonne correspond à l’état de l’objet de

m1 m2

m3

m4

O1 O2 O3 m1

m2

m1

(a) (c) (b)

m3

m4

m2

m3

m4

m1

m3

m4

m6

m2

m5

m1

m2

m3 m4

m5

m6

(a) (c) (b)

1:m1 2*:m2

2.1A:m3

2.1B.1:m4

2.1B.2:m5 2.2:m6

O1 O2 O3

67

la colonne après l’envoi du message de la ligne. La colonne État scénario de la table

représente l’union des états des différents objets. Si un message figure plus d’une fois sur

la table des états (cas du message m2 de la table 1), cela signifie qu’un comportement

concurrent commence après l’envoi de ce message. La table 1 montre comme exemple la

table d’états associée au RdP de la figure 31(c).

Table 1 : Exemple de table d’états associée au scénario de la figure 31(a).

Les tables 2 et 3 ont été construites à partir des scénarios IdentReg et IdentErr (voir figures

25(a) et 25(b)).

Table 2 : Table des états scénarios du scénario IdentReg.

Objets

Messages

Client GAB Banque Compte État scénario

inserer_carte Présent Carte_dedans void void S1={Présent, Carte_dedans, void, void}

entrer_pin Présent Pin-entré void void S2={Présent, Pin_entré, void, void}

Connecter Présent Pin-entré Connecteé void S3={Présent, Pin_entré, Connecteé, void}

Verifier Présent Pin-entré Connecteé Verifié S4={Présent, Pin_entré, Connecteé, Verifié}

pin_valid Présent Pin-entré Valid_pin Verifié S5={Présent, Pin_entré, Valid_pin, Verifié}

carte_valide Présent Valide_carte Valid_pin Verifié S6={Présent, Vailde_carte, Valid_pin, Verifié}

Selectionner_op Présent Selection Valid_pin Verifié S7={Présent, Selection, Valid_pin, Verifié}

confirmer Présent Confirmation Valid_pin Verifié S8={Présent,Confirmation, Valid_pin, Verifié}

Objets Messages

O1 O2 O3 État scénario

m1 e11 e21 e31 S1={e11,e21,e31} m2 e12a e22a e32a S21={e12a,e22a,e32a} m2 e12b e22b e32b S22={e12b,e22b,e32b} m3 e13 e23 e33 S3={e13,e23,e33} m4 e14 e24 e34 S4={e14,e24,e34} m5 e15 e25 e35 S5={e15,e25,e35} m6 e11 e21 e31 S6={e16,e26,e36}

68

Table 3 : Table des états scénarios du scénario IdentErr.

Les RdPCs correspondants aux scénarios IdentReg et IdentErr sont donnés respectivement

dans la figure 32(a) et la figure 32(b). Les couleurs attribuées sont respectivement rid et

eid. La place B dans les figures 32(a) et 32(b) dénote l’état initial du CU qui devrait être

identique pour tous les scénarios du CU.

Figure 32(a) : RdPC correspondant au scénario IdentReg.

Objets

Messages

Client GAB Banque Compte État scénario

inserer_carte Présent Carte_dedans void void S1={ Présent, Carte_dedans, void, void}

entrer_pin Présent Pin-entré void void S2={ Présent, Pin_ entré, void, void}

connecter Présent Pin-entré Connecteé void S3={ Présent, Pin_ entré, Connected}

verifier Présent Pin-entré Connecteé Verifié S4={ Présent, Pin_ entré, Connected, Verifié}

invalid_pin Présent Pin-entré Invalid_pin Verifié S9={ Présent, Pin_ entré, Invalid_pin, Verifié}

invalide_carte Présent Invalide_carte Invalid_pin Verifié S10={ Présent,Invalid_carte, Invalid_pin, Verifié}

pin_error Présent Invalid_pin Invalid_pin Verifié S11={ Présent, Invalid_pin, Invalid_pin, Verifié}

ejecter_carte Présent Libre Invalid_pin Verifié S12={ Présent, Libre, Invalid_pin, Verifié}

69

Figure 32(b) : RdPC correspondant au scénario IdentErr.

3.5. Intégration des scénarios

Le but de cette activité est de fusionner les comportements des scénarios d’un même CU

pour en produire une spécification modélisant le comportement du CU. Dans cette section,

nous commençons par donner un aperçu de l’algorithme d’intégration, nous décrivons

ensuite son implantation dans l’environnement de designCPN, et nous présentons enfin la

solution apportée au problème d’entrelacement des scénarios.

3.5.1. Description de l’algorithme

L’algorithme proposé permet une intégration incrémentale des spécifications de scénarios.

Considérons deux scénarios Sc1 et Sc2 d’un même CU et les RdPCs correspondents: cpn1

et cpn2. L’algorithme fusionne d’abord les places ayant les mêmes noms dans cpn1 et cpn2.

Les places fusionnées auront comme couleur l’union des couleurs de cpn1 et cpn2. Pour la

fusion des transitions, l’algorithme cherche dans cpn1 et cpn2 les transitions qui ont les

mêmes places d’entrée et de sorties, puis il les fusionne avec un ou logique entre leurs

conditions de garde.

70

L’algorithme qui suit montre comment nous intégrons deux RdPCs cpn1 et cpn2 pour

obtenir un RdPC intégré cpn :

begin cpn1 = <∑1, P1, T1, A1, C1, G1, E1, I1> cpn2 = <∑2, P2, T2, A2, C2, G2, E2, I2> cpn = <∑, P, T, A, Cτ, G, E, I> avec :

∑ = P(∑1 ∪ ∑2), // l’alphabet ∑ est l’ensemble des parties de ∑1 et ∑2 P = P1 ∪ P2, I(B) = 1`(I1(B) ∪ I2(B)) C : P → ∑ telle que :

∀ p ∈ P1 ∩ P2 : C(p) = C1(p) ∪ C2(p), ∀ p ∈ P1 \ (P1 ∩ P2) : C(p) = C1(p), ∀ p ∈ P2 \ (P1 ∩ P2) : C(p) = C2(p). // les places communes à cpn1 cpn2 auront l’union des couleurs, le reste des places // garderont leur couleur initiale. // calcul de T

T = ∅ for each t ∈ T1

calculate • t and t• // • t = {p|(p, t) ∈ A} and t• = {p|(t, p) ∈ A}

if ∃ t’ ∈ T2 • t’ = • t and t’• = t• then // fusionner t et t’ T = T ∪ {t}

T2 = T2 \ {t’} G(t) = G1(t) ∨ G2(t’) delete t’ from A2, G2 et E2 else T = T ∪ {t} G(t) = G1(t)

end for each t ∈ T2 // les transitions restantes dans T2

T = T ∪ {t} G(t) = G2(t)

end

// calcul de A A = A1 ∪ A2

// calcul de E for each a ∈ A having the form (p,t)

Type(E(a)) = Type(C(p)) for each a ∈ A having the form (t,p)

Type(E(a)) = Type(C(p)) ∩ Type(C(• t)) end.

71

3.5.2. Implantation de l’algorithme d’intégration dans l’environnement

de designCPN

L’environnement de designCPN a été utilisé pour la saisie et la vérification du RdP du

niveau CU et des RdPCs du niveau scénario. Une fois les RdPCs correspondants aux

scénarios d’un même CU sont saisis dans designCPN, ils subissent une série de

transformations avant leur intégration. La figure 33 résume ces transformations dont le but

est de produire des RdPCs sous forme de fichiers XML (eXtended Markup Language)

[Gol98].

XML est une norme du W3C (World Wide Web Consortium) pour l’échange de

documents depuis février 1998. Les concepteurs d’XML ont pris les meilleurs de SGML et

profité de l’expérience d’HTML (HyperText Markup Language) pour définir un langage

extensible capable de lire des données et des documents sans avoir recours aux

applications qui les ont produits.

Figure 33 : Transformation des scénarios en RdPCs sous le format XML.

Après que l’analyste édite les RdPs dans designCPN, il (elle) les enregistre sous forme de

fichiers SGML [SGM86]. L’outil SX [Cla99] est ensuite appliqué pour transformer les

designCPN RdPCs (RXML)

SX Tool XJParse RdPCs (SGML)

RdPCs

RdPCs (XML)

SequenceDs

UsecaseD Spécification des CUs

Spécification des scénarios

72

fichiers SGML en un format XML brut (RXML) qui sera analysé et complété par l’outil

XJParse [IBM99] afin de produire des fichiers XML compatibles avec le langage de

programmation Java.

L’algorithme d’intégration implanté en Java prend en entrée deux fichiers XML

correspondants aux scénarios d’un CU, et donne en sortie un fichier XML représentant le

comportement intégré du CU. Le pseudo-code de cet algorithme est décrit ci-après :

IntegrateScenarios(Uci) // fonction qui merge les scénarios d’un CU Uci begin scList = getListOfScenarios(Uci) ; // retourne la liste des scénarios du CU Uci uc_cpn = getXML(scList[0]) ; // getXML(Ls[0]) retourne le fichier XML du // scénario ayant Ls[0] comme nom. // uc_cpn représente le résultat d’intégration i=1 ; while (i < scList.size()) // tant que i est plus petit que la taille de Ls sc_cpn = getXML(scList[i]) ; // retourne le fichier XML du scénario Ls[i] sc_cpn = FixID( uc_cpn, sc_cpn) ; uc_cpn = merge(uc_cpn,sc_cpn) ; i = i + 1 ; end end.

XML identifie chaque élément du RdPC (place, transition, arc, etc.) par un identificateur

unique (ID). Avant d’effectuer l’intégration de deux scénarios, la fonction FixID vérifie

que les fichiers XML correspondants (uc_cpn et sc_cpn) ont des Ids distincts. Dans le cas

contraire la fonction FixID prendra le plus grand ID du premier scénario (uc_cpn) et

l’ajoute à tous les Ids du deuxième (sc_cpn).

La fonction merge(S1,S2) consiste à fusionner deux scénarios d’un même CU. Si on

considère cpn1 de couleur c1 le RdPC correspondant au scénario S1 et cpn2 de couleur c2 le

RdPC correspondant au scénario S2, l’algorithme fusionne d’abord les places ayant les

mêmes noms dans cpn1 et cpn2. Ces places fusionnées auront comme couleur l’union des

couleurs de cpn1 et cpn2 {c1, c2}, que nous avons représentée par une liste de couleurs dans

designCPN. Pour les transitions, l’algorithme cherche dans cpn1 et cpn2 les transitions

ayant les mêmes noms (messages) et ayant les mêmes arcs entrants et sortants. Puis il les

fusionne avec un ou logique entre leurs conditions respectives.

73

uc_cpn = merge(uc_cpn,sc_cpn) begin uc_cpn.addPlaces(sc_cpn) // ajoute dans uc_cpn les places de sc_cpn qui // n’existent pas dans uc_cpn. for each t in sc_cpn.getListof Transitions() t’ = uc_cpn. LookForTrans(t) // cherche une transition t’ dans uc_cpn qui a les // mêmes places d’entrée et de sortie que celles de t // dans sc_cpn. If (t’ does not exist) uc_cpn.addtrans(t) // ajoute t dans uc_cpn endif end uc_cpn.addEdges(sc_cpn) // ajoute dans uc_cpn les arcs de sc_cpn qui // n’existent pas dans uc_cpn. uc_cpn.mergeColors(sc_cpn) // fusionne les couleurs de uc_cpn et sc_cpn uc_cpn.putColorsOnPlaces(sc_cpn) // marque les place du RdPC intégré avec les couleurs // fusionnées.

uc_cpn.putGuardOnTransitions(sc_cpn) // les transitions communes seront gardées par les // couleurs fusionnées. Les autres seront gardées par // leur couleur d’origine. uc_cpn.putVariablesOnEdges(sc_cpn) // met sur les arcs les fonctions de consommation et // de transformation des jetons. end.

L’application de cet algorithme pour intégrer les scénarios IdentReg et IdentErr donne le

RdPC de la figure 34.

Après intégration de tous les scénarios d’un même CU, le fichier XML résultat est

reconverti au format SGML par le biais d’un script Perl (voir annexe C). Le résultat de la

conversion (format SGML) est ensuite réintroduit dans designCPN pour des buts de

visualisation, de simulation et de vérification.

74

Figure 34 : Résultat d’intégration des scénarios IdentReg et IdentErr.

3.5.3. Problème d’entrelacement entre scénarios

Le problème d’entrelacement (interleaving) peut surgir après l’intégration de deux

scénarios. Il est souvent possible que le résultat d’intégration capture en plus des scénarios

de base d’autres scénarios produits par l’entrelacement entre les scénarios d’entrée. La

notion de couleur permet de résoudre ce problème. Lors de son parcours d’une

spécification intégrant plusieurs scénarios, le jeton peut changer de couleurs à plusieurs

reprises (jeton caméléon [Elk98]). Dans la place initiale de chaque CU, le jeton caméléon

aura une couleur composite (comme la couleur de la lumière qui est en réalité une

composition de couleurs monochromatiques) incluant les couleurs de tous les scénarios du

CU. Lors de son parcours du RdPC correspondant au CU, certaines couleurs seront filtrées

(comme si on appliquait un prisme à la lumière blanche pour ne laisser passer que certaines

couleurs).

ac ac ac ac ac ac ac 1`[rid,eid]

I I I I

color u = with rid | eid; color I = list u; var ac: I;

[ac=[rid,eid]] [ac=[rid,eid]] [ac=[rid,eid]] [ac=[rid,eid]]

S3

insert_card{BUT} enter_pin{INP} connect check

B

ac ac ac ac ac ac 1`rid

ac

ac

I I I I I

[ac=[rid]] [ac=[rid]] [ac=[rid]] [ac=[rid,eid]]

confirm{BUT} select_op{RAD} card_ok pin_ok

S8 S7 S6 S5 S4

S1 S2

ac ac ac ac ac ac 1`eid

ac I I I I

[ac=[eid]] [ac=[eid]] [ac=[eid]] [ac=[rid,eid]]

eject_card{BUT} pin_error{LAB} invalid_card invalid_pin

S12 S11 S10 S9

75

La figure 35 montre le résultat d’intégration de deux scénarios S1 (avec sc1 comme

couleur) et S2 (avec sc2 comme couleur) et les annotations qu’il faut ajouter aux RdPCs de

designCPN pour que le problème d’entrelacement soit résolu.

Les transitions communes aux deux scénarios S1 et S2 sont normalement gardées par la

couleur unifiée ([sc1,sc2]), c’est le cas par exemple de la transition t1 de la figure 35. La

transition t4, même étant commune aux deux scénarios, est gardée par la disjonction des

couleurs des deux scénarios ([sc1] or [sc2]) parce qu’elle vient après des transitions qui ne

sont pas communes aux deux scénarios. Les transitions non communes sont gardées par la

couleur du scénario d’où elles proviennent, c’est le cas des transitions t3, t5, t7 et t9. Les

transitions t2 et t6 même étant non communes aux deux scénarios, elles sont gardées par des

couleurs unifiées ([sc1,sc2]) vu qu’elles viennent après une transition commune.

76

Figure 35 : Problème d’entrelacement entre les scénarios.

3.6. Conclusion

Les principales caractéristiques de l’approche SUIP-PN se résument : dans l’extension des

diagrammes d’interaction d’UML (SequenceD et CollD) pour spécifier les interactions

utilisateurs, dans l’algorithme d’intégration des scénarios séquentiels et concurrents, et

dans l’utilisation conjointe d’UML et des RdPs.

(a) (b) (c)

77

Au niveau du support de l’IU par UML, notre approche se distingue de celle de Kovacevic

[Kov99] qui propose l’extension du diagramme d’activité d’UML dans le but de supporter

l’analyse des tâches. Nous pensons qu’il est plus naturel d’étendre les diagrammes

d’interactions pour le support de l’IU.

Au niveau de l’intégration des scénarios utilisant les RdPs, notre approche se distingue de

celle de Dano [Dan97] par la séparation des deux niveaux de modélisation (niveau cas

d’utilisation et niveau scénario) et par l’attribution des couleurs aux scénarios.

L’utilisation conjointe d’UML et des RdPs a fait l’objet de certains travaux visant

l’extension d’UML par les aspects temps réel [Del98], et son utilisation dans l’évaluation

de performances [Poo99].

78

Chapitre 4

Vision objet et formalisation des scénarios à l’aide des Statecharts

Ce chapitre décrit l’approche SUIP-SC qui permet d’obtenir les spécifications des

différents objets d’un système sous forme de Statecharts à partir de scénarios décrits sous

forme de CollDs. SUIP-SC diffère de SUIP-PN par la vision utilisée (vision objet) qui

s’intéresse au comportement individuel de chaque objet, et par le formalisme de

spécification utilisé (Statecharts). Nous avons développé cette approche dans le but de

rester conforme à la notation UML au niveau de la description des scénarios et de la

spécification des objets. L’utilisation des CollDs n’est pas intrinsèque à l’approche SUIP-

SC, on peut toutefois utiliser les SequenceDs pour décrire les scénarios dans SUIP-SC.

Une discussion de ces diagrammes (CollDs et SequenceDs) sera donnée dans la section

7.1.2.

La section 4.1 de ce chapitre donne une vue globale du processus derrière cette approche

de modélisation. Les sections 4.2 à 4.5 décrivent en détail les étapes clés de ce processus.

4.1. Processus d’ingénierie des besoins utilisant les

Statecharts

De même que pour le processus de SUIP-PN (figure 22), notre objectif est de supporter et

d’automatiser les activités (acquisition, spécification, intégration des scénarios,

vérification, et production du prototype de l’IU) du processus de l’ingénierie des besoins

79

tout en restant conforme à la notation UML. La figure 36 donne une vue globale des

activités du processus de SUIP-SC [Khr99].

C o llD s

U s e C a s e DS p é c i f ic a t io n

d e s o b j e t s

G é n é r a t io nd u p r o to ty p e

P r o to ty p e d el ’ I U

I n té g r a t io nd e s s c é n a r io s

S y s tè m er é e l

A c q u is i t io nd e s b e s o in s

É v a lu a t io nd u p r o to ty p e

V é r i f ic a t io nd e s

S ta te c h a r t s

S ta te c h a r t sp a r t ie l s

S ta te c h a r t sI n té g r é s

C la s s D

Figure 36 : Activités du processus d’ingénierie des besoins de l’approche SUIP-SC.

Dans l’activité d’acquisition des besoins, l’analyste élabore le ClassD, le UseCaseD et

l’ensemble des CollDs décrivant les différents CUs du système. L’activité de spécification

des objets consiste à dériver un ensemble de Statecharts partiels des objets du système à

partir des CollDs. Les Statecharts partiels qui correspondent au même objet seront

synthétisés dans l’activité d’intégration des scénarios. Les Statecharts intégrés des objets

seront les entrées des activités de génération du prototype de l’IU et de vérification des

Statecharts. Le prototype généré sera ensuite exécuté et évalué par les utilisateurs finaux

du système dans l’activité d’évaluation du prototype. L’outil développé pour supporter les

activités de SUIP-SC est décrit dans l’annexe B.

Les activités de génération du prototype de l’IU et de vérification des Statecharts seront

décrites respectivement dans le chapitre 5 et la section 6.2. L’activité de spécification des

objets consiste en réalité de deux activités distinctes : la génération des spécifications

partielles des objets et l’analyse des spécifications générées. L’activité de génération des

spécifications partielles consiste à dériver à partir de chaque CollD un ensemble de

80

spécifications partielles modélisant les comportements des objets participant dans le

CollD ; et l’activité d’analyse des spécifications partielles permet d’étiqueter les états des

objets en se basant sur les pré- et post-conditions des messages échangés. La figure 37

présente le lien entre les différentes activités qui seront décrites dans le reste de ce chapitre.

A cq u isitio n d esb eso in s

C o llD s

C la ssDU seC a seD

G én éra tion d essp écifica tio n s p artie lles

S ta teD s

In tégra tion d essp écifica tio n s p artie lles

S ta teD sin tég rés

A n a ly se d essp écifica tio n s p artie lles

S ta teD sé tiq u e tés

Figure 37 : Dérivation des spécifications intégrées à partir des CollDs.

Nous décrirons l’activité d’acquisition des besoins dans la section 4.2, l’activité de

génération des spécifications partielles des objets dans la section 4.3, l’activité d’analyse

des spécifications partielles dans la section 4.4, et l’activité d’intégration des

spécifications partielles dans la section 4.5.

81

4.2. Acquisition des besoins

Dans cette étape, l’analyste commence par élaborer de manière détaillée le ClassD du

système à étudier. En plus de l’identification des différentes relations inter-classes, il (elle)

définit pour chaque classe ses attributs, ses opérations ainsi que les pré- et post-conditions

de chaque opération. Ces conditions (pré et post) seront utilisées lors de l’analyse des

spécifications partielles (section 4.4). La figure 38 donne un exemple de description

détaillée de la classe GAB (Guichet Automatique Bancaire) du système ATM dont le

ClassD a été présenté dans la figure 23.

L’analyste identifie également au niveau de cette étape les objets d’interface du système.

Les objets d’interface sont les objets qui interagissent directement avec les acteurs du

système. Il se peut qu’un système ait plusieurs objets d’interface. Dans le cas du système

ATM, l’objet GAB représente son unique objet d’interface.

L’analyste élabore ensuite le UseCaseD du système. Dans SUIP-SC, nous ne sommes pas

intéressés aux relations éventuelles qui peuvent exister entre les différents CUs du système.

Nous avons supposé que tous les CUs sont des points d’entrée du système. Cette

supposition nous a permis d’étudier l’impact du cas où l’analyste n’a pas identifié une

relation entre les CUs sur le prototype de l’IU généré. La figure 39 montre le UseCaseD du

système ATM sans tenir compte des relations de ré-utilisation, il comprend les trois CUs

Retrait, Dépôt et Balance. Le CU Identification du UseCaseD du système ATM de la

figure 24 se retrouve alors comme partie intégrale des CUs Retrait, Dépôt et Balance de la

figure 39.

82

GAB

cash_disponible: boolean = trueecran: String = “menu”fente_cash: String = “fermée”fente_carte: String = “vide”

inserer_carte(String pin)pre: cash_disponible=true and ecran=”menu” and fente_cash=” fermée” and fente_carte=”vide”post: cash_disponible=true and ecran=”entrer password” and fente_cash=”fermée” and fente_carte=”pleine”

entrer_password()pre: cash_disponible=true and ecran=”entrer password” and fente_cash=”fermée” and fente_carte=”pleine”post: cash_disponible=true and (ecran=”entrer operation” or ecran=”password incorrect”) and fente_cash=”fermée” and fente_carte=”pleine”

enter_operationkind()pre: cash_disponible=true and ecran=”entrer operation” and fente_cash=”fermée” and fente_carte=”pleine”post: cash_disponible=true and (ecran=”depot” or ecran=”retrait”) and fente_cash=”fermée” and fente_carte=”pleine”

entrer_montant()pre: cash_disponible=true and (ecran=”depot” or ecran=”retrait”) and fente_cash=”fermée” and fente_carte=”pleine”post: cash_disponible=true and (ecran=”depot en cours” or ecran=”retrait en cours” or ecran=”fonds insufficient ”) and fente_cash=”fermée” and fente_carte=”pleine”

verifier_cash(mnt: float)pre: cash_disponible=true and ecran=”retrait en cours” and fente_cash=”fermée” and fente_carte=”pleine”post: cash_disponible=true and (ecran=”prendre cash” or ecran=”fonds insufficient”) and (fente_cash=”ouverte” or fente_cash=”fermée”) and fente_carte=”pleine”

prendre_cash()pre: cash_disponible=true and ecran=”prendre cash” and fente_cash=”ouverte” and fente_carte=”pleine”post: cash_disponible=true and ecran=”prendre carte” and fente_cash=”fermée” and fente_carte=”ejecter”

prendre_carte()pre: cash_disponible=true and ecran=”prendre carte” and fente_cash=”fermée” and fente_carte=”ejected”post: cash_disponible=true and ecran=”prendre carte” and fente_cash=”fermée” and fente_carte=”vide”

Figure 38 : Description détaillée de la classe GAB du système ATM.

83

Retrait

Dépôt

Balance

Client

Figure 39 : UseCaseD du système ATM sans tenir compte de la réutilisation.

Finalement, l’analyste élabore pour chaque CU les différents CollDs décrivant les

scénarios du système. Les scénarios correspondants sont classifiés de la même façon que

dans l’approche SUIP-PN par leur type et leur fréquence d’utilisation. Puisque le CU

Identification ne fait plus partie du UseCaseD de la figure 39, nous avons choisi d’illustrer

l’approche SUIP-SC par le CU Retrait. Les figures 40(a) et 40(b) représentent deux CollDs

du ce CU : retraitReg correspondant à un retrait normal (avec une fréquence de 10) et

retraitErr correspondant au cas où le client ne dispose pas d’assez de fonds dans son

compte (avec une fréquence de 4).

Les contraintes inputData et outputData sont utilisées dans les CollDs de façon similaire

que dans les SequenceDs de l’approche SUIP-PN (section 3.3.1). Après application des

règles de génération de widgets à partir des contraintes (section 3.3.1) aux CollDs des

figures 40(a) et 40(b), nous obtenons les CollDs des figures 41(a) et 41(b) où les messages

sont annotés par le type de widget.

84

1: inserer_carte(pin) {inputData(GAB.inserer_carte)} →2: passwd:=entrer_password() {inputData(Compte.password)} →4: [ok=true]: kind:=entrer_operation() {inputData(Transaction.kind)} →5: mnt:=entrer_montant() {inputData(Transaction.amount)} →9: prendre_cash() {inpuData(GAB.prendre_cash) } →10: get_card(){inpuData(GAB.prendre_cash } →

:Transaction :Compte

:Client

3: ok:=verifier_compte(pin, passwd) ↓6: balance:=verifier_balance(mnt) ↓8b[balance>=mnt] modfier_solde(mnt,kind) ↓

8a[balance>=mnt]: creer_transaction(pin, mnt, kind) ↓

7[balance>=mnt ]: ok:=deliver_cash(mnt) {outputData(“Take your Cash”)} →

:GAB

Figure 40(a) : CollD du scénario retraitReg.

1: inserer_carte(pin) {inputData(GAB.inserer_carte)} →2: passwd:=entrer_password() {inputData(Compte.password)} →4: [ok=true]: kind:=entrer_operation() {inputData(Transaction.kind)} →5: mnt:=entrer_montant() {inputData(Transaction.amount)} →8: prendre_carte(){inputData(GAB.prendre_carte} →

:Compte

:Client

3: ok:=verifier_compte(pin, passwd) ↓6: balance:=verifier_balance(mnt) ↓

7[balance<mnt]: ok:=afficher_erreur() {outputData(“fonds insufisant”)} →

:GAB

Figure 40(b) : CollD du scénario retraitErr.

85

1: inserer_carte(pin) {BUT} →2: passwd:=entrer_password() {INP} →4: [ok=true]: kind:=entrer_operation() {RAD} →5: mnt:=entrer_montant() {INP} →9: prendre_cash() {BUT} →10: get_card(){BUT} →

:Transaction :Compte

:Client

3: ok:=verifier_compte(pin, passwd) ↓6: balance:=verifier_balance(mnt) ↓8b[balance>=mnt] modfier_solde(mnt,kind) ↓

8a[balance>=mnt]: creer_transaction(pin, mnt, kind) ↓

7[balance>=mnt ]: ok:=deliver_cash(mnt) {LAB} →

:GAB

Figure 41(a) : CollD du scénario retraitReg.

1: inserer_carte(pin) {BUT} →2: passwd:=entrer_password() {INP} →4: [ok=true]: kind:=entrer_operation() {RAD} →5: mnt:=entrer_montant() {INP} →8: prendre_carte() {BUT} →

:Compte

:Client

3: ok:=verifier_compte(pin, passwd) ↓6: balance:=verifier_balance(mnt) ↓

7[balance<mnt]: ok:=afficher_erreur() {LAB} →

:GAB

Figure 41(b) : CollD du scénario retraitErr.

86

4.3. Génération de spécifications partielles

Dans cette activité, nous appliquons à chaque CollD l’algorithme CTS (CollD To StateDs)

[Sch99] développé au sein de notre laboratoire, qui permet de générer automatiquement

des spécifications partielles (StateDs) des objets qui participent dans un CollD donné. Les

StateDs générés respectent essentiellement le séquencement des messages du CollD.

L’algorithme derrière cette transformation suit les étapes suivantes :

1. Il crée un StateD vide pour chaque objet du CollD ;

2. Il introduit dans chaque StateD les "variables d’états", variables autres que les attributs

de l’objet telles que les paramètres des messages, les variables utilisées dans les

conditions de garde ou les variables de retour des messages ;

3. Il crée les sendEvent (actions) et éventuellement des transitions pour les objets

émetteurs de messages en analysant la forme des messages émis (pré-requis, condition

et/ou itération) ;

4. Il crée des transitions pour les objets récepteurs de messages ;

5. Finalement, il crée un ensemble d’états liés par les transitions crées dans les étapes 3 et

4 en respectant le séquencement des messages dans le CollD.

En appliquant CTS au CollD de la figure 41(a), nous obtenons pour l’objet GAB le StateD

de la figure 42(a). De même la figure 42(b) montre le StateD généré pour le même objet

GAB à partir du CollD de la figure 41(b).

87

GABPasswd: String, ok: boolean, kind: char,mnt, balance: float, num integer

inserer_carte {BUT}entrer_operation [ok=true]{INP}

^kind

entrer_password{INP}

^passwd → ok:=verifier_compte(nip,passwd) entrer_montant ^ mnt

{INP} → balance:=verifier_balance(mnt)

[balance>=mnt]/delivrer_cash

{TEX}

[balance>=mnt]

→ num:=Transaction.create(pin, mnt,kind)

[balance>=mnt]

→ Compte.modifier_solde(mnt,kind)

prendre_cash{BUT}

prendre_carte {BUT}

Figure 42(a) : StateD de l’objet GAB généré par l’algorithme CTS à partir du CollD de la figure 41(a).

GABPasswd: String, ok: boolean, kind: char,mnt, balance: float, num: integer

inserer_carte {BUT}entrer_operation[ ok=true]{INP}

^kind

entrer_password{INP}

^passwd → ok:=verifier_compte(nip, passwd)

entrer_montant ^ mnt{INP} → balance:=verifier_balance(mnt)

[balance<mnt] /afficher_erreur {TEX}

prendre_card {BUT}

Figure 42(b) : StateD de l’objet GAB généré par l’algorithme CTS à partir du CollD de la figure 41(b).

4.4. Analyse des spécifications partielles

Les spécifications partielles générées dans l’étape précédante ne portent pas d’étiquettes

sur les états. L’algorithme d’intégration qui sera décrit dans la section suivante, est basé sur

88

des StateDs à états étiquetés. Pour étiqueter les états de ces StateDs partiels, nous avons

utilisé les pré- et post-conditions des opérations définies dans le ClassD. Les événements

qui permettent le changement d’état au sein du StateD d’un objet sont généralement les

opérations qu’on peut appliquer à l’objet.

Les pré- et post-conditions des opérations d’un objet peuvent être exprimées sous leur

forme canonique disjonctive (voir figure 38). Nous avons utilisé une partie du langage

OCL (Object Constraint Language) [Rum99] faisant partie de la notation UML pour

décrire ces conditions.

OCL est un langage de description de contraintes. Il permet aux analystes et concepteurs

de décrire précisément les éléments du système. Dans UML, une contrainte est une

restriction (condition) qui peut affecter n’importe quel élément des différents diagrammes.

Typiquement, OCL est utilisé pour spécifier les invariants de classes, et pour décrire les

conditions de garde et les pré-/post-conditions des opérations. OCL a été développé par

IBM dans le but d’être simple et facile à utiliser. Comme le langage de spécification Z

[Spi88], il est basé sur la théorie des ensembles et la logique du premier ordre.

Le sous-ensemble du langage OCL qui a été adopté dans l’approche SUIP-SC, et qui fait

partie de la grammaire du ClassD (voir annexe A.1), est décrit ci-après. Soit op une

opération d’un objet O du système et pre(op), post(op) respectivement les pré- et post-

conditions :

Pre(op) := ORexpression Post(op) := ORexpression | IFexpression [(or IFexpression)*] IFexpression := (if ORexpression then ORexpression endif) Orexpression := ANDexpression (or ANDexpression)* ANDexpression := Basicexpression (and Basicexpression)* Basicexpression := Identifier OP value Identifier := attribut | parameter OP := < | <= | = | != | >= | >

89

D’après la grammaire ci-dessus, les pré-conditions sont toujours des ORexpressions et les

post-conditions sont soit des ORexpressions soit des disjonctions de IFexpressions. Pour

uniformiser la définition des post-conditions en tenant compte des pré-conditions, les post-

conditions en forme de ORexpressions sont transformées en IFexpressions. Par

conséquence, si pre(op) = ORexpression1 et post(op) = ORexpression2 alors on peut écrire

post(op) = if ORexpression1 then ORexpression2.

Lors de l’opération d’étiquetage des états, nous partons de l’état initial du StateD à

étiqueter, et nous suivons le séquencement des messages permettant le passage d’un état à

son successeur. Pour chaque message (opération op1 par exemple) du StateD, les étiquettes

de l’état de départ et d’arrivée du message dépendent de la post-condition de l’opération

op1.

La forme générale d’une post-condition post(op1) = (if C11 then D11 endif) or (if C12 then

D12 endif) or … (if C1n then D1n endif) où les C1i et D1i sont des ORexpressions.

L’algorithme commence par étiqueter les états de départ et d’arrivée de op1 avec les

conditions C11 et D11 : C11 comme étiquette de l’état de départ et D11 comme étiquette de

l’état d’arrivée (figure 43 (a)), puis il passe à l’événement suivant (opération op2 avec

post(op2) = (if C21 then D21 endif) or (if C22 then D22 endif) or … (if C2n then D2n endif))

dans le StateD. Comme l’état de départ de l’opération op2 est aussi l’état d’arrivée de op1,

alors D11 doit être cohérente avec C21 (D11 soit plus générale que C21). Sinon l’algorithme

cherche dans post(op2) un terme C2j qui soit cohérent avec D11. Si un tel C2j existe, alors

l’étiquetage sera mis à jour tel qu’indiqué dans la figure 43(b). Si aucun terme C2j n’est

cohérent avec D11, l’algorithme revient à op1 et ré-essaye de nouveau l’étiquetage avec C12

et D12 (backtracking). Et ainsi de suite jusqu’à ce que un étiquetage cohérent soit trouvé. La

cohérence des conditions sera discutée en détail dans la section 6.2.

90

C11op1 D11

C11op1 C2j

op2 D2j

(a)

(b)

Figure 43 : Étiquetage des états par les post-conditions (a) cas un message, (b) cas de deux messages consécutifs.

La fonction récursive labelStates résume en pseudo-code l’algorithme derrière l’opération

d’étiquetage.

boolean labelStates(message msg, int pos) begin fs = msg.getFromState() ; ts = msg.getToState() ; fsl = fs.getLabel(); tsl = ts.gelLabel(); ifexp = msg.getListOfIFexpressions().elementAt(pos); b = false; if (msg.isLast()) if (fsl. IsCoherent(ifexp.getIfpart()) and ifexp.getThenpart().isCoherent(tsl)) fsl = setLabel(ifexp.getIfpart()); return true; else return false; endif else if (fsl.isCoherent(ifexp.getIfpart()) msgn = msg.getNext(); k = findConherent(ifexp, msgn.getistOfIFexpressions()); if (k != -1) fs.setLabel(ifexp.getIfpart()); ts. SetLabel(ifexp.getThenpart()); b = labelStates(msgn, k); if (not b)

fs.setLabel(fsl); ts. SetLabel(tsl); if (pos < msg.getistOfIFexpressions().size()) pos = pos + 1;

b = labelStates(msg, pos); else

91

return false; endif

else return true;

endif else

return false; endif endif endif return b; end. En appliquant cet algorithme aux StateDs non étiquetés des figures 42(a) et 42(b), nous

obtenons les StateDs étiquetés des figures 44(a) et 44(b).

Legend:S0 = cash_disponible=true and ecran=”menu” and fente_cash=”fermée” and fente_carte=”vide”S1 = cash_disponible=true and ecran=”menu” and fente_cash=”fermée” and fente_carte=”pleine”S2 = cash_disponible=true and (ecran=”entrer_operation” or ecran=”Password incrorrect”) and fente_cash=”fermée” andfente_carte=”pleine”S3 = cash_disponible=true and (ecran=”depot” or ecran=”retrait”) and fente_cash=”fermée” and fente_carte=”pleine”S4 = cash_disponible=true and (ecran=”depot en cours” or ecran=”retrait en cours” or ecran=”fonds insuffisent”) and fente_cash=”fermée” and fente_carte=”pleine”S5 = cash_disponible=true and ecran=”prendre cash” and fente_cash=”ouverte” and fente_carte=”pleine” and num=0S6 = cash_disponible=true and ecran=”prendre cash” and fente_cash=”ouverte” and fente_carte=”pleine” and num!=0S7 = cash_disponible=true and ecran=”prendre cash” and fente_cash=”ouverte” and fente_carte=”pleine” andCompte.balance=balanceS8 = cash_disponible=true and ecran=”prendre cash” and fente_cash=”ouverte” and fente_carte=”pleine” andCompte.balance=balance-mntS9 = (S6 or S5) and (S7 or S8)S10 = cash_disponible=true and ecran=”prendre carte” and fente_cash=”fermée” and fente_carte=”pleine”

GABPasswd: String, ok: boolean, kind: char,mnt, balance: float, num: integer

S0

inserer_carte {BUT}

S1

entrer_operation[ ok=true]{INP}

^kindS2 S3

entrer_password{INP}^passwd → ok:=check_account(nip,passwd)

S4

entrer_montant ^ mnt{INP} → balance:=verifier_balance(mnt)

[balance>=mnt]/ delivrer_cash

{TEX}

S5

S7S8

[balance>=mnt]

→ num:=Transaction.creer(pin, mnt,kind)

[balance>=mnt]

→ Compte.modifier_solde(mnt,kind)

S10

prendre_cash{BUT}

prendre_carte {BUT}

S9

S6

Figure 44(a) : StateD étiqueté de l’objet GAB dérivé du scénario retraitReg.

92

GABPasswd: String, ok: boolean, kind: char,mnt: float

S0

inserer_carte {BUT}S1

entrer_operation[ ok=true]{INP}

^kindS2 S3

entrer_password{INP}

^passwd → ok:=verifier_compte(nip, passwd)

S4

enter_amount ^ mnt{INP} → balance:=verifier_balance(mnt)

[balance<mnt] /afficher_erreur {TEX}

S10

prendre_card {BUT}

Figure 44(b) : StateD étiqueté de l’objet GAB dérivé du scénario retraitErr.

4.5. Intégration des spécifications partielles

Dans cette activité, nous nous sommes intéressés à produire une spécification globale pour

chacun des objets du système. Cette spécification est obtenue à partir des spécifications

partielles étiquetées (résultat de l’activité précédente). Pour des besoins de génération du

prototype de l’IU du système, nous procédons d’abord à l’intégration des StateDs partiels

d’un objet découlant des CollDs d’un même CU pour générer des StateDs par objet et par

CU. Puis nous intégrons ces derniers pour obtenir un StateD par objet.

L’algorithme d’intégration est incrémental, c’est-à-dire, il prend les deux premiers StateDs

en entrée pour en produire un StateD intégré qui sera par la suite intégré avec un troisième

StateD et ainsi de suite. L’opération d’intégration de deux StateDs suit les étapes

suivantes : la vérification de la cohérence des hiérarchies d’états des deux StateDs, la

fusion des états, la fusion des transitions et l’incorporation de variables de contrôle. Dans

les deux premières étapes, les transitions ne sont pas traitées et n’apparaîtront pas dans les

figures 45 et 46.

93

4.5.1. Cohérence des hiérarchies d’états

Avant d’effectuer l’intégration, l’algorithme vérifie si les deux StateDs ont des hiérarchies

d’états cohérentes. Si le même état apparaît dans les deux StateDs à des niveaux différents

de hiérarchie, une erreur sera signalée.

Soient sd1 et sd2 (figure 45) deux StateDs à intégrer. Les erreurs suivantes seront signalées

lors de la vérification de la cohérence des hiérarchies de ces deux StateDs :

- L’état d apparaît plus d’une fois à des niveaux différents dans sd2

- L’état e apparaît à des niveaux différents dans les hiérarchies de sd1 et sd2. Il apparaît

comme sous-état de l’état c dans sd1 et comme état dans sd2.

StateD sd1 StateD sd2

ba

e f

g h

c

e

a

d

g d

i j

c

Figure 45 : Vérification de la cohérence des hiérarchies d’états de sd1 et sd2.

L’analyste devra corriger les erreurs signalées avant de continuer l’opération d’intégration.

4.5.2. Fusion des états

Quand les deux StateDs ont des hiérarchies d’états cohérentes, l’algorithme passe à la

fusion des états niveau par niveau depuis les racines des hiérarchies jusqu’aux feuilles. La

fusion des états de chaque niveau des hiérarchies dépend du type des états (AND ou OR) et

des états initiaux.

94

La figure 46 résume l’ensemble des cas possibles lors d’une fusion d’états.

a b

f3

f2

f4

ff1

c2

cc1

e3

e2

e4

ee1

d2

dd1

Objg b

ff6f5

c3

cc1

e5

e6 e7

ee1

dd4d3

Obj

(a) (b)

bObj

e3

e2

e4

ee1 e5

e6 e7

f3

f2

f4

ff1

f6f5

c2

cc1 c3

d2 d4

d

d3

d1

g

a

(c)

Figure 46 : Fusion des états : (a) StateD sd1, (b) StateD sd2, (c) StateD résultat sd.

95

Cas où les deux niveaux3 des StateDs sont de type OR

Si les états initiaux sont différents, alors il y a création d’un and-state comprenant les deux

états initiaux. C’est le cas, par exemple, du niveau Obj qui est de type OR dans les StateDs

sd1 et sd2 de la figure 46, les états initiaux étant différents (a dans sd1 et g dans sd2). Il y a

création donc d’un and-state comprenant les états initiaux a et g tel qu’indiqué dans la

figure 46(c). C’est également le cas du niveau d dans les StateDs sd1 et sd2. Pour le reste

des états dans le même niveau, une opération d’union est effectuée.

Si les états initiaux sont identiques dans le niveau considéré, une opération d’union est

alors effectuée. C’est le cas du niveau c qui a le même état initial c1 dans sd1 et sd2.

Cas où les deux niveaux des StateDs sont de type AND

Pour les threads qui ont le même état initial dans les deux StateDs, une opération d’union

est effectuée entre les états des threads. C’est le cas du niveau e des StateDs sd1 et sd2,

l’état initial du premier thread étant le même dans sd1 et sd2 (e1).

Les threads qui n’ont pas le même état initial sont ajoutés comme des threads après la

fusion. C’est le cas par exemple du deuxième thread du niveau e dans sd2 qui se retrouve

comme troisième thread dans le StateD fusionné sd.

Cas où les deux niveaux des StateDs sont de type différent

Ce cas est traité de manière similaire que le précèdent. Le niveau de type OR peut être vu

comme un niveau de type AND avec un seul thread. C’est le cas, par exemple, du niveau f

qui est de type AND dans sd1 et de type OR dans sd2. Puisque l’état initial de f dans sd2 est

différent de ceux des threads de f dans sd1, un thread est alors ajouté tel qu’indiqué dans le

niveau f de sd.

L’algorithme suivant décrit l’opération de fusion des états (mergeStates) :

mergeStates(StateD sd1, StateD sd2) begin if (sd1.type == ‘OR’ and sd2.type == ‘OR’)

3 Un niveau est défini par rapport à un état. Le niveau Obj dans sd1 de la figure 46 est de type OR, et il contient les sous-états a, b, c, d, e et f, qui définissent à leur tour des niveaux, et ainsi de suite.

96

sd1.listofsubStates = sd1.listofsubStates ∪ sd2.listofsubStates if (sd1.initialState != sd2.initialState) sd1.createANDState(sd1.initialState, sd2.initialState) endif endif if (sd1.type == ‘AND’) threadList1 = sd1.getListofThread()

if (sd2.type == ‘AND’) threadList2 = sd2.getListofThread() else // (sd2.type == ‘OR’) threadList2 = sd2 endif for i=1 to threadList2.size() thread2 = threadList2[i] thread1 = threadList2.lookforthreadwithsameInitialState(thread2) if (thread1 != null) thread1 = thread1 ∪ thread2 else threadList1.addThread(thread2) endif end endif if (sd1.type == ‘basic’ and sd2.type != ‘basic’)

sd1 = sd2 endif

subStateList1 = sd1.getListofsubStates() subStateList2 = sd2.getListofsubStates() for i=1 to subStateList1.size() subState1 = subStateList1[i] subState2 = subStateList2.lookforsubStatewithsameName(subState1) if (subState1 != ‘basic’ or subState2 != ‘basic’) mergeStates(subState2, subState2) endif end end.

4.5.3. Fusion des transitions

Les transitions entre états (état de départ et état d’arrivée) d’un StateD sont représentées

sous la forme événement[condition]/actions. L’algorithme cherche dans les deux StateDs

les transitions qui ont le même triplet (état de départ, état d’arrivée et événement).

97

Soient t1 une transition de sd1 (E[C1]/A1) et t2 une transition de sd2 (E[C2]/A2) qui a le

même triplet (état de départ, état d’arrivée et événement) que t1. Pour la fusion de t1 et t2,

trois cas sont à considérer :

1. Si les transitions t1 et t2 ont des conditions de garde égales (C1 = C2) et des actions

différentes (A1 != A2) alors l’algorithme affiche un message d’erreur indiquant que le

StateD résultant aura un comportement non déterministe.

2. Si les transitions t1 et t2 ont des conditions de garde différentes (C1 != C2) et des actions

identiques (A1 = A2) alors t1 et t2 seront fusionnées en une transition de la forme E[C1

or C2]/A (avec A = A1 = A2).

3. Si les transitions t1 et t2 ont des conditions de garde différentes (C1 != C2) et des actions

différentes (A1 != A2) alors la fusion n’aura pas lieu et les deux transitions vont co-

exister dans le StateD intégré. Un comportement non-déterministe est signalé si les

conditions C1 et C2 ne sont pas disjointes.

L’algorithme vérifie aussi le cas où une même transition (E[C]/A) ayant le même état de

départ mène à des états d’arrivée différents dans les deux StateDs, Un état concurrent

comprenant les deux états d’arrivée est alors créé.

4.5.4. Incorporation de variables de contrôle

Des variables de contrôle sont ajoutées et mises à jour au fur et à mesure de l’intégration

des StateDs. Elles ont pour but de résoudre le problème d’entrelacement entre les scénarios

décrit dans la section 3.5.3 du chapitre précédent. Nous définissons dans le StateD intégré

trois variables de contrôle : scenarioList, dynamicScenarioList et transScenarioList.

La variable scenarioList contient la liste des noms des scénarios qui ont été intégrés

jusqu’à présent dans le StateD intégré. La variable dynamicScenarioList est initialisée à

scenarioList et change de valeur durant l’exécution du StateD intégré. Elle sert à garder à

tout moment la liste des scénarios dont l’exécution est possible. La variable

98

transScenarioList est une liste de listes de noms de scénarios. Elle sert à indiquer pour

chaque transition du StateD la liste des scénarios qu’elle peut exécuter.

Pour chaque transition t = E[C]/A du StateD intégré, nous augmentons la condition de

garde par l’ajout de la condition sc, et la partie action par l’ajout de l’action sa : t = E[C

and sc]/A ;sa où sc = (transScenarioList[t] ∩ dynamicScenarioList != ∅ ) et sa =

(dynamicScenarioList := dynamicScenarioList ∩ transScenarioList[t]). La condition sc

vérifie que la transition t peut être franchie pour le scénario en cours d’exécution. Après

franchissement de la transition t la variable dynamicScenarioList est mise à jour par

l’action sa. Avec l’introduction de sc et sa au niveau du StateD intégré, le problème

d’entrelacement est résolu.

L’application de l’algorithme en sa globalité aux scénarios retraitReg et retraitErr donne

le StateD de la figure 47.

GABPasswd: String, ok: boolean, kind: char, mnt, balance: float, num: integerscenarioList:={retraitReg, retraitErr}dynamicScenarioList:=scenarioListtransScenarioList:=[{retraitReg, retraitErr}, {retraitReg, retraitErr},{retraitReg,retraitErr},{retraitReg, retraitErr},{retraitReg}, {retraitReg},{retraitReg},{retraitReg}, {retraitErr}, {retraitReg, retraitErr}]

S0

T1= inserer_carte{BUT} [sc]/sa

S1

T3= entrer_operation{INP} [ok=true and sc] /sa; ^kindS2 S3

T2= entrer_password{INP} [sc]/sa

^passwd → ok:=verifier_compte(nip, passwd)

S4

T4= enter_montant ^ mnt{INP}[sc]/sa → balance:=verifier_balance(mnt)

T5= delivrer_cash{TEX}

[balance>=mnt andsc]/sa

S5

S7

S6

S8

T6= [sc]/sa

→ num:=Transaction.create(pin, mnt,kind)

T7= [sc]/sa

→ Compte.modifier_solde(mnt,kind)

S10

T8=prendre_cash

{BUT} [sc]/sa

T10= prendre_carte{BUT} [sc]/sa

S

T9= afficher_erreur {TEX}[balance<mnt and sc]/sa

Figure 47 : StateD intégré de l’objet GAB après intégration des scénarios retraitReg et retraitErr.

99

Après franchissement des transitions T1, T2, T3 et T4, la variable dynamicScenarioList reste

toujours égale à la variable scenarioList = {retraitReg, retraitErr}. Si T9 est franchie après

T4, la variable dynamicScenarioList sera mise à jour par l’action sa :

dynamicScenarioList := dynamicScenarioList ∩ transScenarioList[T9] = {retraitReg,

retraitErr} ∩ {retraitErr} = {retraitErr}.

4.6. Conclusion

L’approche SUIP-SC se distingue de SUIP-PN par ses algorithmes d’intégration et

d’étiquetage. En plus de l’aspect concurrent supporté, qui est également supporté dans

SUIP-PN, l’algorithme d’intégration de SUIP-SC supporte l’aspect hiérarchique lors de la

fusion des Statecharts. L’algorithme d’étiquetage de SUIP-SC permet l’automatisation de

l’opération d’étiquetage des états, alors que dans SUIP-PN cette opération exige

l’intervention de l’analyste.

L’approche présentée dans ce chapitre est composée de trois algorithmes : l’algorithme

CTS qui transforme les CollDs en StateDs, l’algorithme d’étiquetage des états, et

l’algorithme d’intégration des scénarios. Soit n le nombre de transitions dans un StateD.

Alors le nombre d’états est toujours inférieur ou égal à n+1. L’algorithme CTS a une

complexité de l’ordre O(n2). L’algorithme d’étiquetage est exponentiel O(kn) où k est le

plus grand nombre des IFexpressions dans les post-conditions des opérations du ClassD.

L’algorithme d’intégration a une complexité de l’ordre O(n2). La complexité exponentielle

de l’algorithme d’étiquetage n’est pas un handicap puisque cet algorithme n’est appliqué

qu’aux StateDs partiels dont le nombre de transitions est relativement réduit.

Les seuls autres travaux d’intégration basés sur les Statecharts sont à notre connaissance

les travaux de Glinz et ceux de Koskimies et Makinen (voir sections 2.3.2 et 2.3.6). Glinz

ne considère en réalité que le niveau cas d’utilisation. Il propose des opérateurs pour la

composition des cas d’utilisation, et le chevauchement entre scénarios n’est pas considéré.

100

Koskimies et Makinen proposent un algorithme d’intégration des scénarios dont la

complexité est exponentielle et qui ne prend pas en compte les aspects de concurrence et

de hiérarchie des Statecharts. En plus, les états du Statechart intégré sont identifiés par les

actions du système, ce qui ne correspond pas à la sémantique donnée aux états dans les

Statecharts.

101

Chapitre 5

Génération du prototype de l’interface usager à partir des spécifications comportementales

La plupart des travaux de génération d’Ius complètes ou de prototypes d’IU sont basés soit

sur les données [Fol93, Jan93, Bal96] soit sur l’analyse des tâches [Bod94, Jan93]. Nous

pensons que la génération devra plutôt être guidée par les aspects comportementaux du

système. En effet l’IU doit refléter toutes les interactions entre le système et ses

utilisateurs. Ces interactions se trouvent généralement décrites en détail lors de la

description du comportement du système.

Nous proposons donc de générer le prototype de l’IU à partir des spécifications du

comportement du système. Cependant, nous utiliserons également la spécification des

données pour déterminer le type de widget (aspect présentation de l’IU) approprié pour une

interaction donnée tel que décrit précédemment dans la section 3.3.1. Nous avons

également défini certaines heuristiques pour déterminer automatiquement des groupements

de widgets en forme de fenêtres (frames). Les aspects modèle et contrôleur du patron MVC

sont représentés respectivement par la spécification de données (ClassD) et la spécification

du comportement (StateD ou RdP selon l’approche utilisée). L’aspect vue est

automatiquement dérivé à partir du modèle et du contrôleur.

Dans la section 5.1, nous donnerons un aperçu de l’algorithme de génération du prototype

de l’IU. Les sections 5.2 à 5.5 décriront en détail les étapes de cet algorithme.

102

5.1. Algorithme de génération du prototype de l’IU

Le but de cet algorithme est de produire un prototype de l’IU qui est conforme aux

spécifications des scénarios décrivant le système. Dans l’approche SUIP-PN, les scénarios

sont spécifiés par des RdPs ; tandis que dans l’approche SUIP-SC, les objets qui

participent dans les scénarios du système sont spécifiés à l’aide des Statecharts. La

différence de la vision et du formalisme de spécification dans les approches SUIP-PN et

SUIP-SC, implique une différence dans les premières phases de l’algorithme de génération

selon l’approche utilisée.

Dans les deux cas, le prototype de l’IU est généré comme une application Java dont le

menu général représente les différents CUs directement accessibles à partir de l’état initial

du système. Le prototype comprend également un certain nombre de frames et des

fonctions de navigation simulant les différentes interactions décrites dans les scénarios

d’entrée du système.

5.1.1. Algorithme de génération du prototype de l’IU selon l’approche

SUIP-PN

Dans l’approche SUIP-PN, l’entrée de l’algorithme de génération du prototype de l’IU est

une spécification sous forme de RdPs qui décrit le comportement de tout le système. Nous

avons utilisé le niveau cas d’utilisation de la spécification pour générer le menu global de

l’application, et le niveau scénario pour générer les frames de chaque CU du système.

L’algorithme suivant illustre cette opération :

soit UC l’ensemble des CUs du système = {uc1, uc2, …, ucn}. begin

for each uc ∈ UC cpn = uc.getCPN() // la fonction getCPN() retourne la spécification intégrée des scénarios de uc. cpn.generatePrototype()

end UC.generateCompletePrototype()

end.

103

La fonction generateCompletePrototype(), appliquée à l’ensemble des cas d’utilisation de

UC, permet de générer le menu liant les différents CUs du système. Seuls les CUs

directement accessibles à partir de la place initiale du système, figurent comme option dans

ce menu. Pour le système ATM, le menu généré (figure 48) comprend uniquement le CU

Identification parce qu’il est le seul CU directement accessible à partir de la place initiale

début du système ATM (voir figure 27).

Figure 48 : Menu généré pour l’objet d’interface GAB du système ATM.

La fonction generatePrototype(), invoquée pour chaque CU du système, permet de générer

un ensemble de frames capturant les interactions dans le CU en question.

5.1.2. Algorithme de génération du prototype de l’IU selon l’approche

SUIP-SC

Dans l’approche SUIP-SC, l’analyste identifie dans l’étape d’acquisition des besoins les

objets d’interface. Pour chaque objet d’interface un prototype de l’IU est généré à partir du

StateD modélisant son comportement. L’algorithme suivant illustre cette génération :

soit IO l’ensemble des objets d’interface du système, et soit UC l’ensemble des CUs du système. begin

for each io ∈ IO for each uc ∈ UC if (io.usedInUC(uc)) sd = io.getStateDforUC(uc)

sd.generatePrototype() endif

end io.generateCompletePrototype()

104

end end. La fonction usedInUC(uc) appliquée à l’objet io vérifie si cet objet participe dans les

scénarios du CU uc. Si oui, la fonction getStateDforUC(uc) est appelée pour retourner le

comportement de l’objet io (Statechart) dans le CU uc. La fonction generatePrototype() est

ensuite invoquée pour générer l’IU pour le CU uc.

La fonction generateCompletePrototype() appliquée à l’objet io permet de lier les Ius des

différents CUs du système à travers un menu. Ce menu comporte comme options les CUs

dans lesquels l’objet io participe. Pour le système ATM, le menu généré pour l’objet

d’interface GAB est donné ci-après (figure 49).

Figure 49 : Menu généré pour l’objet d’interface GAB du système ATM.

La fonction generatePrototype(), qui est presque identique à celle de SUIP-PN, est

composée des opérations suivantes :

• Génération du graphe des transitions à partir de la spécification du comportement du

système sous forme de RdPs dans SUIP-PN ou de StateD dans SUIP-SC ( section 5.2) ;

• Identification des blocs de l’IU à partir du graphe des transitions ( section 5.3) ;

• Composition des blocs de l’IU dans le but de produire des blocs dont l’aspect visuel est

plus intéressant ( section 5.4) ;

• Génération des frames à partir des blocs composés de l’IU ( section 5.5).

Dans ce qui suit nous décrivons avec plus de détail les différentes opérations de la fonction

generatePrototype().

105

5.2. Génération du graphe des transitions

Les opérations de la fonction generatePrototype() sont en réalité communes aux deux

approches à part l’opération de génération du graphe des transitions. Cette opération de

génération se fait à partir des RdPs dans SUIP-PN et à partir des StateDs dans SUIP-SC.

Le résultat est un graphe orienté (GT) dans lequel les nœuds sont les transitions de la

spécification et les arcs indiquent la précédence d’exécution entre les transitions. Deux

transitions consécutives seront alors liées par un arc orienté dans GT.

Formellement un graphe GT est représenté par le triplet (nodeList, edgeList,

initialNodeList). nodeList est l’ensemble des nœuds, edgeList est l’ensemble des arcs de

GT et initialNodeList est l’ensemble des nœuds d’entrée de GT. Un GT peut avoir

plusieurs nœuds initiaux.

5.2.1. Génération du graphe des transitions dans SUIP-PN

La génération du graphe des transitions GT dans SUIP-PN se fait à partir d’un RdPC (cpn)

modélisant le comportement d’un CU. Chaque transition t du RdPC est transformée en un

nœud de GT. Pour chaque place p du RdPC, nous cherchons les transitions entrantes à p

(•p) et sortantes de p (p•). Un arc est alors créé pour tout couple de transitions appartenant

respectivement aux ensembles de transitions •p et p• . L’algorithme suivant décrit cette

opération :

begin // les nœuds de GT sont les transitions du RdPC. nodeList = cpn.getListofTransitions() // les nœuds initiaux sont les transition sortantes de la place Begin (place de début de // chaque CU (Begin• ). initialNodeList = ∅ initialNodeList.add(Begin• ) // les arcs de GT lient les transitions entrantes à une place •p et les transitions sortantes // de la même place p• . edgeList = ∅ pList = cpn.getListofPlaces() for each p ∈ pList

for each ti ∈ p• for each te ∈ •p

106

edgeList.addEdge(te,ti) end end end

end. L’application de cet algorithme au RdPC modélisant le CU Identification (figure 34) donne

le GT de la figure 50. Dans cette figure, l’asterix (*) indique l’état initial du GT, et les

nœuds sont définis comme suit : T1=inserer_carte{BUT}, T2=entrer_pin{INP},

T3=connect, T4=verifier, T5=pin_ok, T6=carte_ok, T7=selectionner_op{RAD},

T8=confirmer{BUT}, T9=invalid_pin, T10=invalide_carte, T11= pin_erreur{LAB}, et

T12=ejecter_carte{BUT}.

Figure 50 : Graphe des transitions GT généré à partir du RdPC modélisant le CU Identification.

5.2.2. Génération du graphe des transitions dans SUIP-SC

L’entrée pour la génération de GT est dans ce cas un StateD (sd). Les transitions du StateD

seront transformées en nœuds du graphe GT. Deux transitions consécutives dans le StateD

seront alors liées par un arc orienté dans GT. L’algorithme suivant décrit comment le

triplet (nodeList, edgeList, initialNodeList) de GT est déterminé à partir du StateD sd :

begin

// la liste des nœuds de GT est égale à la liste des transitions du StateD sd. nodeList = sd.getListofTransitions() // Calcul des nœuds initiaux de GT (initialNodeList). initialNodeList = ∅ isList = sd.getInitialStates() for each s ∈ isList

initialNodeList.add(s.outputTransition()) end

T2 * T1 T3 T5

T6 T7 T8

T9 T10 T11 T12

107

// Calcul des liens entre transitions (arcs de GT). edgeList = ∅ for each ti ∈ nodeList s = sd.fromState(ti)

itList = sd.inputTransitions(s) for te ∈ itList edgeList.addEdge(te,ti)

// cas où s est un état initial if (s.getType() == ‘initialState’)

itList = sd.inputTransitions(sd.super(s)) for te ∈ itList edgeList.addEdge(te,ti) endif

// cas où s est un état composite if (s.getType() == ‘andState’ or s.getType() == ‘orState’)

itList = sd.insideTransitions(s) for te ∈ itList edgeList.addEdge(te,ti)

endif end

end. Pour illustrer d’avantage cet l’algorithme, considérons le StateD de la figure 51(a). L’état

de départ c de la transition t2 est un état initial de l’état composite b. Donc les transitions

qui entrent cet état c sont aussi les transitions qui entrent son super-état b. Pour la transition

t4 l’état de départ est l’état composite b, alors toutes les transitions à l’intérieur de cet état

(insideTransitions(b)={t2,t3}) peuvent normalement précéder l’exécution de t4. Le graphe

généré pour le StateD de la figure 51(a) est celui de la figure 51(b).

Figure 51 : (a) StateD de l’objet obj ; (b) Graphe de transitions généré.

a

f

c

e

d

t1

t2

t3 t5

t4

t6

b obj

(a) (b)

t1

t2

t4 t3

t6

t5

108

5.3. Identification des blocs de l’IU

Avant de procéder à l’identification des blocs d’IU (BIU), une opération de masquage des

transitions non interactives sur GT est effectuée. Une transition interactive (par opposition

à une transition non-interactive) est une transition dont l’événement est porteur

d’information sur l’IU (message interactif). Nous construisons à partir de GT un graphe

GT’ ne comprenant que les transitions interactives. Ce graphe modélise l’enchaînement des

opérations concernant l’IU.

Toutes les transitions non-interactives sont supprimées de la liste des nœuds, de la liste des

arcs et de la liste des nœuds initiaux du graphe GT. Quand une transition t est supprimée de

la liste des nœuds (nodeList), nous supprimons également de la liste des arcs (edgeList)

tous les arcs dont la transition t est le point d’origine ou bien le point cible. En plus, de

nouveaux arcs sont ajoutés afin de lier les prédécesseurs et les successeurs de la transition

supprimée t. Si une transition non-interactive t figure parmi les nœuds initiaux de GT, elle

est supprimée de cette liste et remplacée par la liste de ses successeurs.

L’algorithme suivant décrit cette opération.

Begin

for each t ∈ nodeList if (t.getWidget()==null) nodeList.delete(t)

itList=edgeList.inputEdge(t) otList=edgeList.outputEdge(t) for each ti ∈ itList for each to ∈ otList

edgeList.deleteEdge(ti,t) edgeList.deleteEdge(t,to)

edgeList.addEdge(ti,to) end end

endif end

end.

109

En appliquant cet algorithme sur le graphe GT de la figure 50, nous obtenons le graphe

GT’ de la figure 52.

Figure 52 : Graphe GT’ obtenu après masquage des transitons non-interactives du graphe GT de la figure 50.

Du graphe GT’, nous procédons à l’identification des BIUs en se basant sur le

séquencement des transitions. Un BIU est défini comme une suite consécutive de

transitions du graphe GT’. L’opération de construction des BIUs suit les règles suivantes

pour identifier le début et la fin de chaque BIU :

(Règle 1) Un nœud initial du graphe GT’ définit le début d’un BIU.

(Règle 2) Un nœud de GT’ qui a plusieurs arcs entrants définit le début d’un BIU.

(Règle 3) Le successeur d’un nœud qui a plusieurs arcs sortants définit le début d’un BIU.

(Règle 4) Le prédécesseur d’un nœud qui a plusieurs arcs entrants définit la fin d’un BIU.

(Règle 5) Un nœud qui a plusieurs arcs sortants définit la fin d’un BIU.

(Règle 6) Un nœud qui a un arc sortant vers un nœud initial définit la fin d’un BIU.

(Règle 7) Un nœud qui n’a aucun arc sortant définit la fin d’un BIU.

Le graphe des BIUs (GB) est ensuite construit. Les nœuds de GB sont les BIUs identifiés

par les règles précitées, et les arcs de GB indiquent la succession de ces BIUs.

En appliquant ces règles sur le graphe GT’ de la figure 52, nous obtenons le graphe GB

dont les blocs sont illustrés en pointillées sur la figure 53(a). Les règles 1 et 5 déterminent

le début et la fin du BIU B1 (T1, T2). Les BIUs B2 (T7, T8) et B3 (T11, T12) ont été identifiés

par les règles 3 et 7 (figure 53(b)).

T2 * T1

T7 T8

T11 T12

110

5.4. Composition des blocs de l’IU

Les BIUs générés dans l’étape précédente représentent généralement une partie

typiquement réduite de la fonctionnalité d’un CU. En plus le nombre de widgets dans un

BIU n’est pas suffisant pour une visualisation intéressante. Pour ces raisons, la fonction

generatePrototype() fusionne certains blocs en des BIUs plus intéressants et plus

fonctionnels. Parmi les critères de composition, nous avons retenu le critère

d’appartenance au même scénario et un critère ergonomique. Les BIUs appartenant au

scénario le plus fréquent sont regroupés tant que le critère ergonomique est respecté. Les

règles suivantes résument l’opération de compositions des BIUs :

(Règle 8) Les BIUs consécutifs appartenant aux même scénario sont regroupés (critère

d’appartenance au même scénario).

(Règle 9) L’opération de composition commence avec les scénarios ayant la fréquence la

plus élevée.

(Règle 10) Deux BIUs ne seront groupées que si le nombre total des widgets des deux

BIUs ne dépasse pas 20 (critère ergonomique).

De cette opération résulte un graphe GB’ dont les nœuds sont les BIUs composés. Ce

graphe est obtenu en appliquant à GB les transformations décrites dans l’algorithme

suivant :

soit uc un CU du système begin

scList = uc.OrderedScenarioList() // OrderedScenarioList retourne la liste des scénarios de uc classés par type et ordonnés par leur // fréquence d’utilisation. for each sc ∈ scList

bList = GB.lookforBUI(sc) // lookforBUI cherche les BIUs appartenant au scénario sc.

B = bList[0] i =1 while (i < bList.size())

while (GB.ergo(b,bList[i])) // tant que le critere ergonomique est respecté GB.compose(b,bList[i]) // fusionner les deux BIUs

111

GB.delete(bList[i]) // supprimer le bloc fusionné de GB GB.updateLinks() // mettre à jour les liens entre les BIUs

i = i + 1 end

b = bList[i] i = i + 1

end end

end.

L’application de ces règles au graphe GB de la figure 53(b) a permis de regrouper

ensemble les BIUs B1 et B2 comme indiqué sur la figure 53(c).

Figure 53 : Identification des BIUs (a) vue détaillée (b) vue globale (c) composition des BIUs.

5.5. Génération des frames

Dans cette opération, nous générons pour chaque BIU du graphe GB’ une fenêtre

graphique (frame) qui contient les widgets correspondants aux transitions du BIU. Les arcs

entre les BIUs de GB’ seront transformés en appels de fonctions pour permettre la

simulation du prototype d’IU généré.

Dans ce travail, nous ne nous sommes pas intéressés à l’optimisation de l’aspect visuel des

frames vu que le code généré est compatible avec l’interface builder Visual Café [Sym97].

Nous avons utilisé cet outil uniquement à cause de sa disponibilité dans notre laboratoire,

sinon on peut envisager la génération de code compatible avec d’autres interface builders.

À travers Visual Café, l’analyste peut arranger la disposition des widgets, améliorer leur

T2 * T1

T7 T8

T11 T12

(a)

B1 + B2

B3

(c) (b)

B1

B3

B2

112

aspect visuel, modifier les étiquettes des widgets générés par défaut et même ajouter de

nouveaux widgets au sein de la frame. Les frames générées à partir des BIUs représentent

l’aspect statique du prototype. La figure 54 montre les frames générées à partir du graphe

GB’ de la figure 53(c).

Figure 54 : Frames générées à partir du graphe GB’ de la figure 53(c).

Pour des buts d’évaluation du prototype d’IU généré, nous dérivons également à partir du

graphe des transitions GT la partie dynamique du prototype qui permet d’animer les frames

statiques générées précédemment. L’exécution ou la simulation du prototype revient en fait

à l’exécution symbolique de la spécification de base qui a servi à la construction du

prototype. Tout l’aspect dynamique de la spécification derrière le prototype est capturé

dans les graphes des transitions GT et GT’. L’exécution du prototype revient donc à un

parcours du graphe GT’ où le prototype répond à tous les événements capturés dans GT’ et

ignore les autres.

Afin de mieux supporter la simulation du prototype, nous avons généré automatiquement

avec le prototype de l’IU une fenêtre de simulation (partie inférieure de la figure 55) qui

permet de guider la personne évaluant le prototype. Elle guide l’utilisateur en lui indiquant

les séquences d’interaction possibles à chaque étape de l’exécution du prototype.

113

Puisque l’exécution du prototype revient en fait au parcours du graphe GT’ contenant

uniquement les transitions interactives, il se peut qu’au niveau d’un nœud de GT’ plusieurs

arcs sortants sont possibles. Ces différents chemins représentent les différents scénarios

possibles à ce point d’exécution. Dans certains cas, le choix d’un chemin dépend d’une

réponse du système après consultation de la base d’information de celui-ci. On pouvait

choisir au hasard un parmi les chemins possibles, mais nous avons préféré que la

simulation soit plus dirigée par l’utilisateur et qu’il sélectionne lui-même un chemin

particulier pour pouvoir le tester et l’évaluer. À l’aspect dynamique du système s’ajoute

donc des comportements additionnels pour pouvoir autoriser la simulation par l’utilisateur.

Lorsque le prototype atteint un point où plusieurs chemins (scénarios) dans GT’ sont

possibles, une fenêtre de dialogue (fenêtre de sélection) affiche alors les différents chemins

possibles sous forme de boutons radios (voir partie centrale droite de la figure 55) et

l’utilisateur effectue sa sélection puis continue l’exécution du prototype. Il se peut qu’un

seul ou bien plusieurs des chemins possibles correspondent à un groupe de scénarios, alors

tout le groupe de scénarios sera affiché comme une option du groupe des boutons radios

dans la fenêtre de sélection.

Figure 55 : Simulation des frames générées de la figure 54.

114

Dans la figure 55, la fenêtre de simulation indique que l’utilisateur a sélectionné le CU

Identification et qu’il est invité à cliquer sur le bouton insert_card. Seul le bouton

insert_card est actif au départ, et tout le reste des widgets est désactivé. Les widgets sont

activés au fur et à mesure de l’exécution du prototype. Dès que le bouton insert_card est

cliqué, le textField password et le bouton Confirm sont alors activés. Les messages Enter

password et Click button Confirm sont affichés dans la fenêtre de simulation pour guider

l’utilisateur. Une fois le password est saisi et le bouton Confirm est cliqué, le système

devra normalement effectuer une recherche et une vérification du mot de passe dans la

base de données de la banque. Comme nous ne disposons pas au niveau du prototype des

données réelles du système, le prototype demandera à l’utilisateur de choisir parmi les

deux chemins possibles qui correspondent au cas d’un mot de passe correct (scénario

IdentReg) et au cas d’un mot de passe invalide (scénario IdentErr). La fenêtre de sélection

contenant les deux options est alors affichée. L’utilisateur choisit une des deux options

possibles puis continue la simulation.

5.6. Conclusion

Cette approche de génération du prototype de l’IU se distingue de celle proposée par

Bodart et al. [Bod94] par une génération plus guidée par le comportement du système que

par l’analyse fonctionnelle des tâches. Les aspects statique et dynamique du prototype sont

automatiquement générés, tandis que dans l’approche de Bodart et al. Seul l’aspect statique

de l’IU est généré. Dans l’approche de Schlungbaum et Elwert [Sch96], l’aspect

dynamique de l’IU est manuellement élaboré par l’analyste dans l’étape de la conception

du dialogue.

L’algorithme de génération dépend des valeurs de fréquence attribuées aux scénarios par

l’analyste lors de l’étape d’acquisition des besoins. En variant ces valeurs, nous obtenons

différents prototypes d’UI pour le même système que nous pourrons éventuellement

115

évaluer avec l’utilisateur final. Ceci peut être intéressant dans le cadre d’un prototypage

exploratoire.

L’algorithme de génération de l’IU est polynomial pour les deux approches. Il a une

complexité de l’ordre de O(n3) pour SUIP-PN et de l’ordre de O(n2) pour SUIP-SC où n est

le nombre de transitions dans la spécification.

116

Chapitre 6

Vérification des propriétés de comportement : cohérence et complétude de scénarios De nos jours, les systèmes informatiques modernes imposent des contraintes de sûreté et de

fiabilité très sévères. Le moindre dysfonctionnement du système peut affecter plusieurs

milliers voir plusieurs millions d’utilisateurs dépendamment du système, et provoquer ainsi

une perte énorme aux propriétaires du système. Il est donc crucial de pouvoir garantir le

bon fonctionnement d’un système avant sa mise en service et de valider l’ensemble de ces

comportements par rapport aux services demandés.

Les formalismes de spécification (ou techniques de description formelle) ont été conçus

dans le but de permettre de vérifier formellement certaines propriétés du système à partir

de sa spécification. Une spécification doit être :

• non ambiguë : une seule interprétation est possible,

• complète : comprend toutes les informations nécessaires à la compréhension et

l’analyse du système,

• claire et compréhensible : offre un formalisme lisible dans lequel les descriptions sont

concises et modulaires.

Dans le cycle de vie d’un logiciel, les techniques formelles apparaissent à plusieurs étapes

et de plusieurs manières. Lors de la phase d’analyse et de spécification des besoins, la

rédaction des spécifications du système est réalisée dans un langage rigoureux ne laissant

pas la place aux diverses interprétations. Lorsque cette phase est terminée, nous pouvons

soit vérifier la spécification en recherchant si les propriétés attendues restent vérifiées pour

117

toutes les exécutions possibles, soit valider la spécification par la simulation de son

exécution. Après le développement de l’application, on peut encore procéder à des

vérifications additionnelles en effectuant des tests dirigés par la spécification (séquences de

tests générées à partir de la spécification).

De nombreuses techniques de description ont été développées de façon à répondre aux

exigences énoncées ci-haut. Elles peuvent être classées selon trois catégories : les

techniques basées sur les états/transitions, les techniques basées sur des langages et enfin

les techniques algébriques et logiques. Le choix d’une technique plutôt qu’une autre

dépend du système à étudier.

Les techniques de description basées sur les états/transitions sont les plus adéquates à la

modélisation des actions utilisateurs (transitions) et des réactions du système (états). Dans

le cadre de ce travail, nous avons utilisé les RdPs à haut niveau et les Statecharts, qui font

partie de ces techniques. Ces deux formalismes modélisent bien la concurrence, sont munis

de possibilités de structuration réduisant la taille des spécifications (hiérarchie), et sont

supportés par des outils de vérification et de simulation. En outre, ils sont largement

utilisés, et ils ont fait leur preuve dans le domaine du génie logiciel. Nous allons décrire ci-

après pour chacun des deux formalismes les techniques de vérification les plus utilisées

ainsi que les propriétés qu’on peut vérifier avec.

Dans la section 6.1, nous présenterons les techniques de vérification supportées par les

RdPs en nous basant sur les travaux de Jensen [Jen95]. La section 6.2 présente les

techniques de vérification des Statecharts. Nous présenterons également dans cette section

l’algorithme que nous avons développé pour la vérification de la cohérence et de la

complétude des spécifications de scénarios basées sur les Statecharts. Ce nouvel

algorithme de vérification basé sur la sémantique des pré- et post-conditions et portant sur

les attributs des objets, offre un champ de vérification plus large et prend en compte les

aspects de hiérarchie et de concurrence des spécifications.

118

6.1. Vérification dans les RdPs

Les RdPs ainsi que leurs extensions offrent plusieurs techniques de vérification de

certaines propriétés du système. Les algorithmes existants permettent de vérifier et

d’estimer des propriétés qualitatives et quantitatives d’un système. Les propriétés

qualitatives concernent l’aspect fonctionnel et comportemental du système (vivacité et

sûreté). Les propriétés quantitatives concernent généralement l’évaluation des

performances. On peut catégoriser les techniques de vérification des RdPs en deux grandes

classes :

• Les techniques basées sur le graphe d’accessibilité.

• Les techniques basées sur le calcul des invariants.

La première classe consiste à énumérer en tout ou en partie les marquages accessibles à

partir du marquage initial du RdP. La deuxième classe est plutôt indépendante des

marquages accessibles et vise à identifier les composantes répétitives et conservatives du

RdP.

Avant de donner un aperçu sur chacune des classes de vérification, nous présentons

d’abord les propriétés vérifiables d’un RdP.

6.1.1. Propriétés des RdPs

La vivacité, le caractère borné et la ré-initialisabilté sont les principales propriétés qu’on

peut automatiquement vérifier dans un RdP.

6.1.1.1. Vivacité d’un RdP

Un RdP est vivant si et seulement si toutes ses transitions sont vivantes. Une transition t

d’un RdP ayant M0 comme marquage initial est dite vivante si pour tout marquage M du

RdP atteignable à partir de M0, on peut toujours trouver une séquence franchissable de

transitions dans laquelle la transition t figure. La vivacité d’un RdP dépend de son

marquage initial M0.

119

Un RdP vivant garantit l’absence de blocage et de parties mortes (non atteintes) dans la

structure du réseau. Il garantit aussi qu’on peut toujours atteindre les services du système

modélisés dans le RdP.

6.1.1.2. RdP borné

Un RdP est borné si et seulement si toutes ses places sont bornées. Une place p est bornée

si pour tout marquage M, le nombre de jetons dans la place est inférieur à une constante k :

∀ M, M(p) < k.

Le caractère borné d’un RdP renseigne sur les valeurs limites des ressources demandées

par le système.

6.1.1.3. Ré-initialisabilité

Un RdP est réinitialisable si et seulement si pour tout marquage M, il existe une séquence

de transitions qui permet de revenir au marquage initial M0. Cette propriété renseigne sur

le fonctionnement répétitif, ce qui est pertinent pour la majorité des systèmes interactifs

pratiques.

6.1.2. Graphe d’accessibilité ou graphe d’occurrence

Les techniques basées sur le graphe d’accessibilité ou le graphe d’occurrence consistent à

construire à partir du RdP un graphe dont les nœuds sont les marquages possibles et les

arcs sont les transitions changeant le marquage du RdP. Cette technique risque de générer

des graphes infinis même pour des RdPs de petite taille. En effet pour un petit RdP simple

(cyclique et non-borné), le graphe de marquage généré peut être de taille infinie. Cette

technique souffre donc de l’explosion des états comme inconvénient majeur. Pour pallier à

cet inconvénient, plusieurs techniques ont été proposées soit pour réduire la taille du RdP à

partir duquel le graphe d’occurrence est généré [Hub86], soit pour dériver un graphe de

couverture [Fin93] borné capturant les mêmes propriétés du RdP initial.

120

6.1.3. Calcul des invariants

Les techniques basées sur le calcul des invariants permet d’identifier les composantes

conservatives et répétitives d’un RdP [Nar86]. Le but est de construire des équations qui

restent valides pour tous les marquages accessibles du RdP à partir du marquage initial. On

parle alors de P-invariants et de T-invariants.

Les P-invariants (composantes conservatives) définissent des ensembles de places pour

lesquels le nombre total des jetons reste fixe quelles que soient les transitions franchies.

Pour le calcul systématique des P-invariants, on représente un RdP comme une matrice C =

POST – PRE où PRE et POST sont des matrices représentant les liens place-transition

(PRE) et les liens transition-place (POST). Les lignes des matrices PRE et POST sont les

places du RdP (soit n ce nombre) et les colonnes sont les transitions (soit m ce nombre).

Les P-invariants sont les valeurs propres de la matrice C, soit les solutions de l’équation f T. C = 0. Les vecteurs f T sont des vecteurs lignes de taille (1, n). Le 0 dans l’équation ci-

dessus est en réalité un vecteur colonne de taille (1,m).

Les T-invariants (composantes répétitives) sont les séquences de transitions dont le

marquage final est égal au marquage initial. De même on peut calculer les T-invariants

d’un RdP en se basant sur sa matrice C. Les T-invariants sont des vecteurs s de taille (m, 1)

qui satisfont l’équation C . s = 0. Le 0 de cette équation est un vecteur de taille (n,1).

Notons que les deux classes de techniques présentées précédemment (section 6.1.2 et

section 6.1.3) ne sont pas en compétition, mais sont plutôt complémentaires.

6.1.4. Cadre de vérification utilisant les RdPs

Par analogie aux approches de tests des systèmes procédant par étapes (tests unitaires, tests

d’intégration et tests d’acceptation), nous avons défini une approche de vérification à

quatre étapes : la vérification individuelle des scénarios, la vérification après intégration

des scénarios, la vérification du RdP modélisant les Cus et enfin la vérification de la

121

spécification globale liant la spécification des Cus aux spécifications de leurs scénarios

intégrés. Ce cadre de vérification par étapes permet de mieux diagnostiquer et retracer les

origines des erreurs. Il peut également être utilisé avec tout outil de vérification des RdPs.

Dans l’approche SUIP-PN (chapitre 3), nous avons utilisé designCPN pour la saisie, la

vérification et la simulation des RdPs colorés hiérarchiques. Cet outil supporte la technique

de graphe d’occurrence pour la vérification des propriétés comportementales d’un système.

Pour des RdPCs bornés, l’outil permet de vérifier toutes les propriétés précitées dans la

section 6.1.1. Les RdPCs dérivés des scénarios sont par construction des RdPs bornés et

réinitialisables. Ils sont réinitialisables puisque lors du passage du UseCaseD au premier

niveau de RdP (voir figure 26), nous mettons toujours deux transitions entre les places du

RdP du niveau cas d’utilisation pour garantir le retour à la place initiale. Le caractère borné

est assuré par le fait que les jetons ne sont mis que dans la place initiale (place début) et

qu’au niveau des arcs des RdPCs le nombre de jetons consommés ou produits est égal à 1.

6.1.4.1. Vérification des scénarios avant leur intégration

Après la saisie du RdPC correspondant à un scénario d’un CU donné, on peut procéder à la

vérification de ses propriétés comportementales. Un RdPC dérivé d’un scénario a toujours

une place d’entrée (place B) et plusieurs places de sortie correspondantes à la connexion du

scénario avec la place initiale du système (place début) ou à des connexions aux

spécifications des autres Cus appelés par le scénario. Les places de sortie du scénario sont

alors liées à la place d’entrée du scénario par des transitions de retour. Ces transitions

masquent l’interaction du scénario avec le reste de la spécification du système. Un ou

plusieurs jetons sont ensuite mis dans la place de début B pour pouvoir simuler et vérifier

le RdP du scénario. L’algorithme de vérification peut alors être appliqué à plusieurs

reprises en augmentant le nombre de jetons dans la place initiale du RdPC du scénario pour

vérifier ses propriétés. Un exemple de rapport de vérification généré par designCPN est

donné dans l’annexe C.4.

122

6.1.4.2. Vérification après intégration

Une fois tous les scénarios ont été vérifiés individuellement, nous appliquons l’algorithme

d’intégration. Puisque cet algorithme est incrémental, nous pouvons vérifier le

comportement du résultat après chaque pas d’intégration. Si un problème surgit après la

vérification du scénario intégré, l’analyste saura identifier le scénario dont l’intégration est

à l’origine de l’erreur. Lorsque tous les scénarios d’un CU ont été intégrés avec succès,

nous obtenons alors une spécification valide du CU en question.

6.1.4.3. Vérification du niveau CU

Cette étape vise à s’assurer du bon comportement de l’interaction entre les Cus du système.

Nous procédons à la vérification des propriétés du RdP du niveau CU sans tenir compte du

raffinement des différents Cus par les spécifications de leurs scénarios respectifs. Des

erreurs à ce niveau indiquent que le raffinement des relations uses du UsecaseD doit être

révisé.

6.1.4.4. Vérification globale

Dès que le niveau CU et les spécifications raffinant chaque CU ont été vérifiés, et après

liaison de ces deux niveaux de spécification, nous effectuons une dernière vérification pour

s’assurer de la validité de la spécification globale du système. Normalement après les

étapes précédentes de vérification, il ne devrait pas y avoir des erreurs résiduelles. Les

erreurs détectées à ce niveau sont beaucoup plus difficiles à diagnostiquer.

6.2. Vérification dans les Statecharts

Les techniques de vérification basées sur les Statecharts ne sont pas aussi évoluées que

dans le cas des RdPs. À part STATEMATE [Har90b], très peu d’outils commerciaux ou

académiques proposent des algorithmes de vérification pour les Statecharts. Certains

travaux [Hei96] proposent des algorithmes de vérification basés sur la sémantique des

123

conditions attachées aux transitions des Statecharts. Notre approche de vérification étend

les travaux de Heimdahl et al. [Hei96].

6.2.1. Propriétés des Statecharts

STATEMATE permet la vérification de certaines propriétés des Statecharts telles que

l’accessibilité, le non-déterminisme et l’inter-blocage (deadlock). Le test de ces propriétés

dynamiques est déduit à partir des exécutions de la spécification. En effet STATEMATE

simule l’exécution des Statecharts soit de manière interactive où l’analyste interagit avec la

spécification pour lui communiquer les événements externes de son environnement, soit de

manière programmée (automatique) en utilisant un script SCL (Simulation Control

Language). Le programme SCL remplacera alors l’analyste dans l’interaction avec la

spécification et générera les séquences d’événements dans l’ordre indiqué dans le

programme. Lors de la simulation, STATEMATE maintient une base de données de traces

d’événements et enregistre les séquences de changements sur les états du système (status).

Un status du système représente l’ensemble des états actifs, des activités en cours et les

valeurs courantes des variables et des conditions.

L’accessibilité dans STATEMATE est définie par la recherche des différentes séquences

possibles menant d’un status initial à un status du système où une condition cible est

vérifiée.

Pour certains systèmes, l’exécution de toutes les configurations possibles devient

ingérable. Les concepteurs de STATEMATE préconisent l’utilisation de l’outil

uniquement pour les parties critiques du système.

Les travaux de Leveson et al. [Lev94] et Heimdhal et al. [Hei96] offrent également un

cadre pour la vérification de la cohérence et la complétude au sein des Statecharts.

124

6.2.2. Algorithme de vérification

Dans le cadre de l’approche de modélisation utilisant les Statecharts comme moyen de

formalisation, nous avons développé un algorithme de vérification des propriétés de

cohérence et de complétude d’une spécification. Cet algorithme vient en complément aux

algorithmes de vérification offerts dans STATEMATE.

Dans des approches basées sur des descriptions partielles comme c’est le cas de l’approche

scénario, les propriétés de cohérence et de complétude sont parmi les propriétés les plus

importantes qu’il faut garantir. L’intégration ou la composition des comportements partiels

(plusieurs scénarios) peut engendrer un ensemble d’incohérences et/ou d’incomplétudes au

sein de la spécification.

L’algorithme de vérification proposé s’appuie sur la sémantique donnée aux états. Dans

SUIP-SC, les états sont identifiés et étiquetés par les pré- ou post-conditions des

événements entrants ou sortants de l’état en question comme précédemment décrit dans

dans la section 4.4. L’analyse de ces conditions logiques peut, comme on va le voir dans ce

qui suit, permettre la détection d’incohérences et/ou d’incomplétudes dans les

spécifications.

6.2.2.1. Cadre formel pour la vérification

Dans ce qui suit nous donnerons quelques définitions qui servent de base pour la

formulation des propriétés de vérification. Dans l’approche SUIP-SC (chapitre 4), on s’est

intéressé aux comportements individuels des objets du système.

Soit O un objet ayant (a1, a2, …, an) comme attributs dont on veut étudier le comportement.

Définition 1 : un état s de l’objet O est défini par une condition C(s) portant sur les

attributs de l’objet. On note C(s) par C pour des raisons de simplification.

Les conditions étiquetant les états d’un objet sont des Orexpressions (voir l’algorithme

d’étiquetage à la section 4.4). On peut donc écrire que : C = (c11∧ c12 … ∧ c1n)∨ (c21∧ c22 …

125

∧ c2n) … ∨ (cm1∧ cm2 … ∧ cmn) où les cik sont des Basicexpressions sur les attributs ak de

l’objet O.

Définition 2 : soit ak un attribut, la fonction dom(ak) retourne l’ensemble des valeurs

possibles de l’attribut ak.

Définition 3 : soit C une condition sur un ensemble d’attributs de l’objet O. Eval(cik)

retourne l’ensemble des valeurs de l’attribut ak pour lesquels la condition cik

est vraie. Eval(cik) ⊆ dom(ak). Eval(C) est définie comme une matrice (m,n)

dont les éléments sont les ensembles Eval(cik).

Prenons l’exemple d’un objet ayant (a1, a2) comme attributs de type Integer, et soit la

condition C = (a1=0 ∨ (a1>0∧ a2>0) ∨ a2=0). Nous uniformisons d’abord cette condition par

l’ajout des conditions vraies afin de compléter la matrice d’évaluation. C devient alors =

((a1=0 ∧ a2=dom(a2)) ∨ (a1>0 ∧ a2>0) ∨ ( a1=dom(a1) ∧ a2=0)). La matrice d’évaluation de

C est donc la suivante :

Eval(C) =

Z est l’ensemble des entiers (Integer) et Z+* représente l’ensemble des entiers strictement

positifs.

L’évaluation des conditions sert à des fins de comparaison entre conditions. Avant toute

opération de comparaison, nous pouvons procéder à l’optimisation de la matrice

d’évaluation en se basant sur les propositions sui antes :

Proposi ion 1 : Si ∀ 1 ≤ i,j ≤ m (m nombre de lignes de la matrice Eval(C)), ∀ 1 ≤ k ≤ n

(nombre de colonnes de la matrice et nombre d’attributs de l’objet) on a : Eval(cik) ⊆

Eval(cjk) alors on peut supprimer la ligne i de la matrice d’évaluation.

{0} Z Z+* Z+* Z {0}

126

Preuve : la preuve de cette proposition revient à montrer que :

P = (ci1∧ ci2 … ∧ cin)∨ (cj1∧ cj2 … ∧ cjn) = (cj1∧ cj2 … ∧ cjn) sachant que cik∨ cjk = cjk ∀ 1≤ k≤ n. P = (ci1∧ ci2 … ∧ cin)∨ (cj1∧ cj2 … ∧ cjn) = (cj1∧ cj2 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin) si on repartit cj1, P = ((cj1∨ (ci1∧ ci2 … ∧ cin)) ∧ ((cj2 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin)) P = (((cj1∨ ci1) ∧ (cj1∨ (ci2 … ∧ cin)) ∧ ((cj2 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin)) or (cj1∨ ci1) = cj1, P= ((cj1 ∧ (cj1∨ (ci2 … ∧ cin)) ∧ ((cj2 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin)), puisque a∧ (a∨ b) = a, P = (cj1) ∧ ((cj2 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin)), de même si on repartit cj2, P = (cj1) ∧ (cj2 ) ∧ ((cj3 … ∧ cjn) ∨ (ci1∧ ci2 … ∧ cin)), ainsi de suite jusqu’à ce qu’on obtient P = (cj1) ∧ (cj2 ) … ∧ (cjn) = cj1 ∧ cj2 … ∧ cjn

Proposition 2 : Soient i,j les indices de deux lignes différentes de la matrice d’évaluation

Eval(C). Si le nombre de termes différents dans les lignes i et j est égal à 1, alors on peut

supprimer de la matrice Eval(C) une des lignes i ou j. Soit k l’élément différent dans les

deux lignes i et j. Si on supprime la ligne j alors Eval(cik) = Eval(cik) ∪ Eval(cjk) ∀ 1≤k≤n.

La preuve de cette proposition est triviale, puisque :

P = (ci1∧ ci2 … ∧ cik… ∧ cin)∨ (cj1∧ cj2 … ∧ cik … ∧ cjn) = (cj1∧ cj2 .. ∧ (cik ∨ cjk) … ∧ cjn).

Définition 4 : une condition C raffine D (C est plus restrictive que D) si et seulement si ∀

1 ≤ i ≤ m, ∃ 1 ≤ j ≤ m tel que : ∀ 1 ≤ k ≤ n, Eval(cik) ⊆ Eval(djk).

Définition 5 : une condition C est égale à D si et seulement si C raffine D et D raffine C.

Définition 6 : deux conditions C et D sont disjointes, si et seulement si : ∀ 1 ≤ i,j ≤ m, ∃ 1

≤ k ≤ n | Eval(cik) ∩ Eval(djk) = ∅ .

Définition 7 : deux états s1 et s2 sont égaux si et seulement si leur condition respective C1

et C2 sont égales.

Un état composite de type or est formellement défini par les propriétés 1 et 2 :

Propriété 1 : Soit S un or-state. s1 est un sous-état de s si et seulement si la condition C1

sur s1 est plus restrictive que la condition C sur s.

127

Propriété 2 : Soit s un or-state et s1, s2, …, sk l’ensemble de ses k sous-états, et soient C

et C1, C2, …, Ck leur conditions respectives. Il faut que les conditions Ci et

Cj soient disjointes ∀ 1 ≤ i ,j ≤ k | i≠j, et que la condition (C1 ∨ C2 ∨ … ∨

Ck) raffine C.

Un état composite de type and est formellement défini par les propriétés 3, 4 et 5 :

Propriété 3 : Soit s un état concurrent (and-state) et s1 un sous-état de s, soit C et C1 les

conditions respectives associées à s et s1, alors la condition C est plus

restrictive que C1.

Propriété 4 : soit s un and-state et s1, s2 deux sous-états de s appartenant à des threads

différentes. Soit C la condition associée à s1 et D celle associée à s2, alors :

i) ∀ 1 ≤ i ≤ m, ∀ 1 ≤ k ≤ n, Eval(cik) ≠ dom(ak) ⇒ Eval(dik) = dom(ak)

OR Eval(cik) = Eval(dik).

ii) ∀ 1 ≤ i ≤ m, ∀ 1 ≤ k ≤ n, Eval(dik) ≠ dom(ak) ⇒ Eval(cik) = dom(ai)

OR Eval(cik) = Eval(dik).

Propriété 5 : soit s un and-state avec m threads concurrents (t1, t2, …, tm) où chaque

thread ti est un or-state comprenant un ensemble ki de sous états (si1, si2, …,

siki) alors C(s) associée à l’état s raffine la condition (AND (OR

C(sij))i=1..m,j=1..ki. Si ki = 1, alors le thread ti est un état simple.

Les threads d’un and-state sont généralement indépendants mais ils peuvent communiquer

par l’envoi de messages. Lorsqu’un objet est dans un and-state, ceci implique qu’il peut

être dans n’importe quel état du produit cartésien t1 x t2 x … x tm. Pour que le and-state soit

cohérent il faut que tout couple d’états du produit cartésien ti x tj vérifie la propriété 5.

Lorsqu’un thread effectue un changement sur un attribut ak d’un objet, les conditions sur

cet attribut au niveau des états des autres threads doivent rester cohérentes avec ce

changement. Les changements par les threads doivent donc se faire sur des parties

disjointes de l’ensemble des attributs de l’objet.

128

Une transition t dans un Statechart d’un objet O a généralement la forme suivante : t =

event [cond] / {actions}. Pour qu’il y ait cohérence entre le Statechart de l’objet O et le

ClassD du système, il faut que l’événement et les différentes actions de la transition t

(event et actions) figurent comme des méthodes dans l’objet O. Dans le ClassD, chaque

méthode est décrite par ses pré- et post-conditions exprimées en un sous-ensemble du

langage OCL.

Définition 8 : soit t une transition, t = event[cond]/{actions}. Dans le cas d’une transition

avec événement, pre(t) = pre(event) sinon pre(t) = pre(action1) où action1

est la première action de la liste des actions de la transition t

({actions}={action1, action2, …, actionn}). event et la liste des actions sont

normalement des opérations de l’objet O.

Définition 9 : soit t une transition, t = event[cond]/{actions}. Post(t) = post(actionn) où

actionn est la dernière action de la clause {actions} ou encore post(t) =

post(event) si la clause {actions} est vide.

6.2.2.2. Cohérence des spécifications

Nous présentons dans ce qui suit les règles de vérification de la cohérence (ou

consistance) d’un Statechart en nous basant sur les définitions de la section précédente. La

cohérence peut être d’abord vérifiée dans le ClassD au niveau des méthodes des classes qui

sont décrites par leurs pré- et post-conditions (cohérence statique). Dans le Statechart, la

cohérence est vérifiée au niveau des états et au niveau des transitions (cohérence

dynamique).

Cohérence statique

Dans un ClassD, on peut parler de cohérence de description ou de cohérence de

spécification puisque les pré- et post-conditions des méthodes du modèle sont

formellement décrites en utilisant le langage OCL.

129

Propriété 6 : une condition C est cohérente vis-à-vis d’un objet O si et seulement si ∀ 1 ≤

i ≤m, ak attribut de l’objet O, Eval(cik) ≠ ∅ .

Propriété 7 : une méthode m d’un objet O est cohérente si et seulement si :

i) Les conditions pre(m) et post(m) sont cohérentes avec l’objet O.

ii) Si post(m) est une IFexpression : post(m) = � i=1..n(IF Ci Then Di),

alors la condition (� i=1..nCi) devra être égale à pre(m).

Propriété 8 : un objet O est cohérent si et seulement si toutes ses méthodes sont

cohérentes.

Cohérence dynamique

La cohérence dynamique concerne les spécifications sous forme de Statecharts modélisant

le comportement des objets d’un système. La vérification de cohérence d’un Statechart se

fait selon les étapes suivantes :

1- Cohérence des états

Dans un Statechart, un état peut être soit de type simple, de type or (or-state), ou de type

and (and-state).

Propriété 9 : un état simple d’un objet O étiqueté par une condition C est dit cohérent si

et seulement si la condition C est cohérente avec l’objet O.

Propriété 10 : un or-state s est dit cohérent si et seulement si :

i) tous ses sous-états sont cohérents ;

ii) l’état s vérifie la propriété donnée dans la définition 9.

Propriété 11 : un and-état s est dit cohérent si et seulement si :

i) tous ses sous-états sont cohérents ;

ii) l’état s vérifie les propriétés citées dans les définitions 11 et 12.

130

2- Cohérence des transitions

L’algorithme vérifie en plus de la cohérence de chacune des transitions du Statechart, la

cohérence entre les transitions émanantes d’un même état, et la cohérence entre les

transitions consécutives.

Propriété 12 : une transition t (t = event[cond]/{actions}) émanante d’un état s1 (étiqueté

avec la condition C1) et partante vers un état s2 (étiqueté avec la condition

C2) est cohérente si et seulement si :

i) ∀ 1 ≤ i ≤ m, ∀ ak, Eval(condik) ⊆ Eval(cik) ;

ii) pre(t) raffine C1 ;

iii) post(t) raffine C2 .

Propriété 13 : deux transitions consécutives t1 et t2 sont cohérentes si et seulement si :

pre(t2) raffine post(t1).

Propriété 14 : deux transitions t1 (t1 = event[cond1] / {actions1}) et t2 (t2 = event[cond2] /

{actions2}) ayant le même événement (event) et émanantes du même état s

sont cohérentes si et seulement si :

i) les transitions t1 et t2 sont cohérentes ;

ii) si (cond1 = cond2) alors actions1 = actions2. Il s’agit donc de la même

transition ;

iii) si (cond1 ≠ cond2) alors cond1 et cond2 sont disjointes.

La propriété 14 permet de détecter des comportements non-déterministes dans la

spécification. En effet, si les transitions t1 et t2 vérifient la condition ii) et leurs états de

destination sont différents, alors il s’agit d’un non-déterminisme. De même si les deux

transitions ne vérifient la condition iii), alors ils’agit d’un non-déterminisme.

Propriété 15 : une transition t émanante d’un état composite s (de type and ou or) doit être

cohérente selon la propriété 13 avec toutes les transitions se trouvant à

l’intérieur de l’état s.

131

En effet une transition émanante d’un état composite peut être exécutée après n’importe

quelle transition se trouvant à l’intérieur de l’état composite.

Définition 10 : un Statechart est cohérent si et seulement si tous ses états sont cohérents

(vérifiant les propriétés 9 à 11) et toutes ses transitions sont cohérentes

(vérifiant les propriétés 12 à 15).

6.2.2.3. Complétude des spécifications

Une spécification est complète si elle modélise tous les services attendus par le système.

Heimdahl et al. [Hei96] définissent la complétude, par analogie avec la robustesse d’un

système, comme la qualité d’une spécification à répondre de manière appropriée à toutes

les hypothèses et les violations de l’environnement du système.

On peut aussi définir la complétude d’une spécification d’un objet du système comme étant

son habilité à répondre de manière appropriée à tous les événements qu’il reçoit. La

spécification d’un système est complète si les spécifications de tous ses objets le sont.

Cette condition est nécessaire mais elle n’est pas suffisante. Le fait de tester la complétude

des spécifications des différents objets du système ne garantit pas la complétude de celui-

ci, mais la détection et la résolution des incomplétudes au niveau des spécifications des

objets individuels améliore sans doute la complétude de la spécification du système.

La non-description ou la description partielle de certains services du système au niveau de

l’acquisition des besoins sont les principales sources d’incomplétudes d’une spécification.

Les incomplétudes sont des sources potentielles d’erreurs de cohérence au niveau des

spécifications. Elles peuvent être identifiées par l’analyste en examinant les incohérences

détectées dans les spécifications. Lors de la vérification de la cohérence de la spécification

d’un objet, les incohérences suivantes peuvent potentiellement être dues à des

incomplétudes d spécification :

• L’existence d’états où aucune transition n’est sortante (états bloquants ou états puits).

132

• L’existence d’états or-state pour lesquelles la condition associée n’est pas égale à la

disjonction des conditions associées à leur sous-états.

• L’existence d’états and-state pour lesquelles la condition associée n’est pas égale à la

conjonction des conditions associées à leur threads.

• L’inconsistance entre deux transitions consécutives peut être le résultat de l’oubli d’une

transition entre celles-ci.

• Les transitions émanantes d’un même état s et pour lesquelles la disjonction de leur

pré-conditions n’est pas égal à la condition étiquetant s.

• Les transitions émanantes d’un même état, ayant les mêmes événements et des

conditions de garde différentes. Dans le cas où la disjonction ces conditions ne

formerait pas une tautologie.

La validation du Statechart d’un objet avec le ClassD peut aussi servir à détecter certaines

incomplétudes de spécification :

• Toutes les méthodes d’un objet doivent figurer dans son Statechart comme événements

ou actions. Si une méthode de l’objet dans le ClassD ne figure pas dans son Statechart,

c’est un signe que le Statechart n’est pas complet.

• Les pré- et post-conditions des méthodes doivent être toutes utilisées lors de l’opération

de l’étiquetage. Il faut s’assurer surtout dans le cas où la post-condition d’une méthode

est une suite de IFexpressions que tous les éléments de cette suite ont servi dans

l’étiquetage des états. Si une IFexpression n’a pas été utilisée, ceci implique que la

spécification ne prend pas en considération tous les cas de figures pour l’exécution de

la méthode.

La génération de nouveaux scénarios à partir de ceux existants (design by example

[Kos98]) peut être utilisée pour réduire les incomplétudes des spécifications. Dans notre

approche, nous avons défini des mécanismes pour résoudre le problème d’entrelacement

entre scénarios (sections 3.5.3 et 4.5.3). Si on inhibe ces mécanismes, la spécification

résultante capturera tous les entrelacements possibles entre les scénarios initiaux. Le

133

nombre d’entrelacements est en réalité le nombre des nouveaux scénarios construits. Il

reste donc à valider avec l’utilisateur que les nouveaux scénarios capturent des situations

réelles.

Le prototypage que nous utilisons dans ce travail, peut être considéré comme une

technique informelle pour la détection d’incomplétudes. En effet lors de la validation et

l’évaluation du prototype de l’interface usager (figure 1), l’utilisateur peut se souvenir de

certaines situations qui n’ont pas été décrites lors de l’acquisition des besoins.

6.3. Conclusion

L’algorithme discuté dans la section 6.2 étend les travaux de vérification basées sur les

états/transitions [Hei96, Hey98, Lus97, Som97, Hei98]. Il prend en compte les aspects de

hiérarchie et de concurrence dans les spécifications. Heimdahl et al. [Hei96], dont le travail

est très proche du notre, vérifient la cohérence (consistance) et la complétude d’un

Statechart en se basant sur trois fonctions de compositions (union, sérielle et parallèle). La

fonction d’union (union composition) vérifie la cohérence des transitions ayant le même

état de départ. La composition sérielle (serial composition) vérifie qu’un événement émis

par une transition (partie action d’une transition) est toujours consommé, sinon une

incomplétude est signalée. La composition parallèle (parallel composition) vérifie la

cohérence des transitions dans des états concurrents qui sont tirées par le même événement.

La vérification de la cohérence est plus large dans notre algorithme de vérification. Nous

vérifions la cohérence des états composites (AND et OR), la cohérence entre les transitions

et leurs états de départ et d’arrivée, la cohérence entre les transitions émanantes d’un même

état, et la cohérence entre des transitions consécutives. Notre algorithme est de l’ordre de

O(n2) dans le pire cas, alors que celui de Heimdahl est exponentiel.

134

Chapitre 7

Discussion et comparaison des deux approches de modélisation

Dans ce chapitre, nous comparons les approches de modélisation SUIP-PN et SUIP-SC en

mettant en évidence leur avantages et inconvénients. Nous commençons d’abord par

discuter dans la section 7.1 les diagrammes UML que nous avons utilisés dans ce travail.

Les approches SUIP-PN et SUIP-SC seront ensuite comparées selon les visions et les

formalismes de spécification utilisés dans les sections 7.2 et 7.3. L’algorithme de

génération de l’interface usager sera discuté dans la section 7.4. Nous terminons ce

chapitre par la discussion de la validation et l’expérimentation des approches SUIP-PN et

SUIP-SC.

Nous rappelons que dans SUIP-PN, nous avons utilisé les réseaux de Petri pour spécifier le

comportement de tout le système et que dans SUIP-SC, nous avons utilisé les Statecharts

pour spécifier le comportement des objets du système.

7.1. La notation unifiée UML

À travers ce travail, nous avons utilisé les diagrammes d’UML qui concernent les

premières phases de développement à savoir le ClassD, le UsecaseD, le SequenceD, le

CollD et le StateD.

7.1.1. UsecaseD

Ce diagramme capture les services offerts par le système, les interactions des ses services

avec l’environnement externe du système et même les relations entre ces services. Les

135

interactions entre services du système sont modélisées par les relations uses et extends. Ces

relations ne donnent qu’une vue simplifiée des interactions qui peuvent exister réellement

entre les services d’un système. Dans le cas du système du guichet automatique bancaire

(ATM), les cas d’utilisation (services) sont liés par la relation uses (voir figure 24). Le cas

d’utilisation Identification est utilisé par les trois autres cas d’utilisation : Retrait, Dépôt et

Balance. Avec la relation uses l’interaction entre les quatre services du système n’est pas

précisément définie. En réalité après l’exécution du service d’identification, on peut

exécuter à maintes reprises l’un des trois autres services du système. Ceci peut s’exprimer

comme suit en utilisant les opérateurs d’interaction ( ; : séquentialité, | : choix ou

sélection, * : itération, || : concurrence) : Identification ; (Retrait | Dépôt |

Balance)*.

Une extension du UsecaseD est alors nécessaire pour capturer toutes les interactions

possibles entre les services d’un système. Cette extension peut être faite par l’ajout au

UsecaseD des opérateurs d’interaction qui existent déjà dans les diagrammes d’interaction

(SequenceD et CollD) ou encore par la définition d’un nouveau type de diagramme

(diagramme d’interaction des cas d’utilisation) similaire au CollD et dont les objets sont

les cas d’utilisation du système. Un exemple de cette dernière extension est donné pour le

cas du système ATM dans la figure 56.

Identification

Retrait

Dépôt

Balance

Client

1: activate É

2*:i:=select É

2.1 [i=1] uses É

2.2 [i=2] uses É

2.3 [i=3] uses É

Figure 56 : Diagramme d’interaction des cas d’utilisation.

136

7.1.2. SequenceD et CollD

Dans les approches SUIP-PN et SUIP-SC, nous avons utilisé respectivement les

SequenceDs et les CollDs pour décrire les scénarios du système. Même si les deux types de

diagrammes sont sémantiquement équivalents, chacun d’eux se prête à une meilleure

description de certains aspects des scénarios. Les SequenceDs sont bien adaptés à décrire

l’ordonnancement des messages dans les scénarios. Les CollDs sont plutôt meilleurs dans

la description de la structure de l’interaction dans un scénario. La numérotation des

messages propre aux CollDs permet de décrire des comportements itératifs, conditionnels

et concurrents. Dans les SequenceDs, la structure des interactions est spécifiée de manière

graphique, ce qui rend parfois le diagramme illisible. Il est même parfois difficile

d’identifier une structure d’interaction telle que la concurrence dans un SequenceD.

Le SequenceD de la figure 57 modélise normalement un système distribué où les objets O1

et O2 communiquent entre eux, de même pour les objets O4 et O5 (concurrence). Dès que

l’objet O3 reçoit les messages ma3 et mb3 (synchronisation) il exécute l’action m4. Un

analyste peut interpréter ce SequenceD comme un scénario séquentiel (ma1, mb1, ma2, mb2,

ma3, mb3 et m4). La numérotation des messages devra donc être utilisée dans les

SequenceDs pour mieux décrire les différentes interactions dans les scénarios. L’utilisation

d’une telle numérotation dans les SequenceDs leur fait perdre leur puissance visuelle de

description.

Dans certains cas tel que sur l’exemple de la figure 58, on voudrait avoir un traitement

itératif de n récurrences où l’itération peut être interrompue par la réception d’un message

(m4). L’utilisation de la numérotation dans le CollD (ou le SequenceD) selon UML ne

permet pas de bien décrire cette situation :

137

Figure 57 : SequenceD montrant la faiblesse de description de la concurrence et de la synchronisation.

Figure 58 : CollD modélisant une itération avec interruption par message.

La numérotation du message m4 signifie que ce message vient après n itérations des

messages (m1, m2, m3), mais n’indique pas que le message m4 interrompt cette itération.

Puisque les CollDs capturent à la fois l’aspect statique et l’aspect dynamique, l’échange de

messages entre deux objets du système ne peut se faire que s’il existe un lien de données

entre ces objets. Dans le cas des SequenceDs tout objet peut communiquer avec n’importe

quel autre objet du système.

Vu que les approches SUIP-PN et SUIP-SC sont basées respectivement sur les SequenceD

et les CollDs, elles vont souffrir des mêmes limitations que nous venons de citer

précédemment. La proposition d’extension du UseCaseD rendra sans doute l’approche

SUIP-PN plus expressive.

ma1

ma2

ma3

mb1

mb2

mb3

m4

O1 O2 O3 O4 O5

:O2

:O3 1:*[i=1..n] m1 É

1.1: m2 É 2: m4 É

1.2: m3 Ç

138

7.2. Vision système et vision objet

Dans la vision système, on s’intéresse à décrire globalement le comportement du système.

Dans la vision objet on s’intéresse plutôt à décrire individuellement le comportement des

objets du système. Dans cette section, nous présenterons des situations de modélisation où

l’une ou l’autre des visions est meilleure. Le tableau Table 4 résume les caractéristiques

des deux visions.

Pour des raisons d’homogénéité, nous utilisons partout les SequenceDs pour décrire les

scénarios, même dans le cas de l’approche SUIP-SC.

7.2.1. Séquencement des messages au sein d’un scénario

Comme il a été décrit en détail dans le chapitre 3, le Réseau de Petri coloré dérivé de

chaque scénario capture l’ensemble des messages échangés. L’ordre des messages est donc

respecté dans cette spécification partielle du système (ordre total). Dans le cas de la vision

objet, on se concentre sur l’objet pour lequel on désire dériver le comportement sous forme

de Statechart. On ne considère que les messages entrants à et sortant de cet objet. Le

comportement de chaque objet est donc obtenu par la projection de l’ensemble des

scénarios sur cet objet. L’ordre des messages reste respecté localement par objet mais il se

peut qu’il ne soit plus respecté dans les spécifications de manière globale (ordre partiel).

Soit le SequenceD de la figure 59(a). Le comportement dérivé de l’objet O2 est celui

donné dans la figure 59(b).

Cette spécification peut être comprise comme suit : après réception du message m1, l’objet

O2 envoie les deux messages m2 et m6. Le fait que le message m6 vient après le message

m5 n’est capturée nulle part.

139

Figure 59 : (a) Exemple de SequenceD illustrant l’ordre partiel des messages ; (b) StateD de l’objet O2 généré à partir du scénario (a).

7.2.2. Interaction des messages dans un scénario

La vision par objet peut provoquer des comportements non désirés lors de la simulation de

la spécification d’un objet dans le même scénario. Soit le scénario de la figure 60(a), avec

l’objet O2 émettant et recevant le même message m2.

Figure 60 : Interaction non-désirable entre les messages d’un même scénario : (a) Exemple de scénario, (b) StateD de l’objet O2 dérivé à partir du scénario (a).

D’après la sémantique des Statecharts, l’envoi d’un message signifie sa diffusion à tous les

objets du système, en particulier à l’objet émetteur. Dans la spécification de l’objet O2

(figure 60(b)), la réception du message m1 entraîne l’envoi du message m2. L’objet O2 va

m1

m3

m2

O1 O2 O3

m4

m6

m5

m1/m2;m6

m1

m3 m2

O1 O2 O3

m7 m2

m6

O4

A B C m1/m2 m2/m6

(b)

(a)

(a)

(b)

140

recevoir ce message, puis il exécutera tout de suite la deuxième transition, et il émettra le

message m6. Alors que le message m2 est normalement destiné à l’objet O3.

7.2.3. Interaction des messages lors de l’intégration de scénarios

Dans la vision objet, malgré l’introduction de variables de composition lors de l’intégration

des scénarios, des comportements résiduels non capturés peuvent toujours exister dans la

spécification intégrée. Soient les deux scénarios simples de la figure 61. Le message m2 est

envoyé de O2 vers O3 dans le premier scénario et de O2 vers O4 dans le deuxième scénario.

Figure 61 : Interaction des messages après intégration de scénarios (a) : Scénario 1 ; (b) : Scénario 2 ; (c) : Comportement de l’objet O2 ; (d) : Comportement de l’objet O3 ; (e) : Comportement de l’objet O4

Dans les spécifications résultantes après intégration des deux scénarios, l’objet O2 émet le

message m2 sur la réception du message m1 ou m3. Le message m2 étant diffusé à tous les

objets, il sera exécuté dans les spécifications des objets O3 et O4 alors qu’il devrait

uniquement être exécuté pour un des objets et non pas les deux.

D E m2

(a)

(b)

A

B

C

m1/m2

m3/m2

(c)

(d)

m1 m2

O1 O2 O3 O4

m3 m2

O1 O2 O3 O4

(e)

141

7.2.4. Non-déterminisme

Avec la vision objet certains comportements sont déclarés comme non-déterministes lors

de l’intégration alors qu’ils ne le sont pas. Dans la figure 62 les deux scénarios (a) et (b)

génèrent pour l’objet O2 respectivement les comportements (c) et (d).

Figure 62 : Exemple de scénarios dont le comportement est non-déterministe pour l’objet O2.

Les deux scénarios peuvent modéliser, par exemple, un système client/serveur (O1, O3) qui

communique à travers une passerelle (O2). Le premier scénario modélise le cas où le

serveur demande une information du client (envoi du message m1 de O1 sur la figure

62(a)). La réponse est retournée à travers le message m4. Le deuxième scénario modélise le

cas où le client demande au serveur un service (envoi de m1 de O3 sur la figure 62(b)),

l’objet O2 achemine alors la requête et envoie le message m5 au client pour l’aviser de

l’envoi de sa requête. Pour l’objet O2 il s’agit d’un comportement non-déterministe

m1

m3

m2

O1 O2 O3

m4

a b c m1/m2 m3/m4

(a)

(c)

m1

m3

m2

O1 O2 O3

m4

m5 a b c

m1/m2;m5 m3/m4

(b)

(d)

142

puisque après réception du message m1, l’objet envoie le message m2 dans le premier

scénario et les messages m2 et m5 dans le deuxième scénario. Dans l’algorithme

d’intégration présenté dans la section 4.5.3, si un message a la même condition et des

actions différentes, un non-déterminisme est signalé. Dans la vision système, les deux

scénarios de la figure 62 génèrent des RdP séquentiels où le non-déterminisme n’est pas

signalé.

7.2.5. Étiquetage des états

Dans la vision objet, les spécifications sont dérivées (non étiquetés) en s’appuyant sur la

structure de l’interaction des messages dans les scénarios. Ces spécifications sont ensuite

étiquetées en se basant sur les pré- et post-conditions des messages dans le ClassD du

système. Cette opération se fait de manière automatique par l’utilisation de l’algorithme

décrit dans la section 4.4.

Dans la vision système, les étiquettes des places des RdPs dérivées à partir des scénarios,

sont déduites de l’information mise par l’analyste dans les tables des états associées à ces

scénarios. Il se peut que l’analyste met dans la table des états la même information après

deux messages différents du même scénario. Ceci peut causer la capture de comportements

additionnels non désirables. Prenant le scénario de la figure 62(b), supposons que

l’analyste a associé la table suivante à ce scénario (figure 63).

O1 O2 O3 État scénario

m1 A1 B1 C1 S1={A1,B1,C1} m2 A2 B2 C2 S2={A2,B2,C2} m5 A1 B1 C1 S1={A1,B1,C1} m3 A3 B3 C3 S3={A3,B3,C3}

Figure 63 : (a) Table des états associée au scénario de la figure 62(b) ; (b) RdPC généré à partir du scénario de la table des états.

B

S

m1

S

m2 m5

S

m3

S

m4 (a) (b)

143

Dans le RdPC résultant (figure 63(b)), un cycle non-désirable (m2, m5) est alors créé.

7.2.6. Prototype de l’interface usager

Dans la vision objet, les objets d’interface sont explicitement identifiés par l’analyste lors

de l’acquisition des besoins. Une interface usager est alors générée pour chaque objet

d’interface en appliquant l’algorithme décrit dans le chapitre 5. Dans la vision système,

une seule interface usager est générée pour tout le système. On peut toutefois, générer une

interface usager par acteur du système en regroupant dans cette interface tous les cas

d’utilisation avec lesquels l’acteur interagit. Les deux visions donnent des résultats

similaires pour des systèmes où un seul acteur interagit avec un cas d’utilisation donné.

Dans les applications distribuées ou collaboratives, où plusieurs acteurs participent à la

réalisation d’un service (cas d’utilisation), la vision système ne donne pas des résultats

satisfaisants. En effet l’interface générée pour le cas d’utilisation regroupe les interactions

de tous les acteurs. La vision objet ci-contre donne de meilleurs résultats avec une bonne

identification des objets d’interface.

Le système de gestion d’une station d’essence est un bon exemple pour illustrer cette

problématique. Dans le cas d’utilisation livraison d’essence de ce système, deux acteurs (le

client et l’employé) interagissent et participent à la réalisation de ce service. La figure 64

montre un scénario normal de ce cas d’utilisation.

Dans l’approche SUIP-PN, si on applique l’algorithme de génération de l’interface usager

sur le cas d’utilisation livraison d’essence, on obtient la fenêtre illustrée sur la figure 65(a)

où les interactions du client et de l’employé se retrouvent ensemble dans la même frame.

Dans l’approche SUIP-SC, si l’analyste identifie deux objets d’interface dans ce scénario

(Pompe et TerminalEmployé), une fenêtre par objet sera générée (figure 65(b) et 65(c)).

144

Figure 64 : Scénario normal d’utilisation de la pompe.

Figure 65 : Frames générées pour la vision système (a) et pour la vision objet ((b) et (c)).

appuyer_bouton() {BUT}

Client Pompe TerminalEmployé

initialiser()

signaler() {TEX}

autoriser(){BUT}

Employé

sortir_pistolet() {BUT}

saisir_montant() {INP}

appuyer_detente() {BUT}

remonter_detente() {BUT}

arreter_essence()

remettre_pistolet(

(a)

(b)

* incrementer()

145

7.2.7. Comportements non pertinents

La vision objet génère des comportements intéressants pour les objets de contrôle du

système. Dans certains scénarios, certains objets ne sont sollicités par des interactions

qu’une ou deux fois. Les comportements générés pour ces objets sont triviaux

(comportements non-pertinents). Nous avons remarqué que le comportement intégré (après

intégration des scénarios) pour ces objets peut mener à des résultats insignifiants.

Prenons le cas du système de bibliothèque et plus particulièrement le cas d’utilisation du

prêt de documents. La figure 66 montre deux scénarios de ce cas d’utilisation. Le premier

scénario décrit un prêt normal, alors que le deuxième décrit la situation où le document à

prêter est réservé par la bibliothèque.

:Employee

1: créerPrêt() É 1.1: uid:=entrerUid() {INP} É 1.3[rep=true]*: enregistrerDoc() É 1.3.1: did:=enterDid() {INP} É

:Lecteur

1.2: rep:=chercherLecteur(uid) Ê

1.3.2: rep:=chercherDocument(uid) É 1.3.4[rep=true]: mettreAJour() É

:Pret

:Terminal :Document

1.3.3[rep=true]: afficherInfos() Ê

1.4: enregistrerPret() Ê

146

Figure 66 : Scénarios de prêt pour le système de bibliothèque.

Les comportements de l’objet Document générés à partir des deux scénarios précédents

sont présentés dans la figure 67.

Figure 67 : Comportement de l’objet Document

(a) Statechart dérivé du scenario1 ; (b) Statechart dérivé du scenario2 ; (c) Statechart intégré.

:Employee

1: créerPrêt() É 1.1: uid:=entrerUid() {INP} É 1.3[rep=true]*: traiterDocs() É 1.3.1: did:=enterDid() {INP} É

:Lecteur

1.2: rep:=chercherLecteur(uid) Ê

1.3.2: rep:=chercherDocument(did) É

:Pret

:Terminal :Document

1.3.3[rep=false]: afficherErreur() Ê

1.4: enregistrerPret() Ê

A B mettreAJour()

chercherDocument()

C

chercherDocument()

B

A

C

mettreAJour()

chercherDocument()

(a) (b)

(c)

147

Dans la figure 67, l’état A représente l’état où le document n’est pas en réserve, l’état B

représente le document en prêt et l’état C signifie que le document est réservé. Dans le cas

réel, les états A et C ne sont jamais des états concurrents. L’état concurrent créé par

l’algorithme d’intégration (figure 67(c)) est donc insignifiant.

Le comportement des objets tels que l’objet Document devra être considéré au niveau

global et non au niveau de chaque cas d’utilisation.

7.2.8. Récapitulation

Le tableau suivant (Table 4) résume la discussion des deux visions système et objet. Pour

chaque ligne du tableau (critère), le signe – dans une colonne (vision) signifie que le critère

n’est pas supporté par la vision en question. Le signe + signifie qu’il est bien supporté, et le

signe ++ qu’il est très bien supporté.

Critères Vision système Vision objet

Séquencement des messages au sein d’un scénario

+ -

Interaction des messages dans un scénario + -

Interaction des messages lors de l’intégration de scénarios

+ -

Non-déterminisme

+ -

Étiquetage des états - +

Prototype de l’interface usager + ++

Comportements non pertinents + -

Table 4 : Récapitulation de la comparaison des visions système et objet.

Si on se base sur le nombre de + correspondant à chacune des visions dans le tableau

précédent, nous pourrons conclure que la vision système est plus adaptée à la modélisation

des systèmes interactifs. Cependant, les critères de la table 4 n’ont pas tous le même poids

148

(la même importance) d’un point de vue IU. Les trois derniers critères sont à notre avis les

plus pertinents et spécialement celui du prototype de l’interface usager.

Pour des applications distribuées interactives ou des applications collaboratives, la vision

objet est préférable. Pour des systèmes où un seul acteur acteur interagit avec le système

pour réaliser un service, la vision système est meilleure.

On peut toutefois profiter des avantages des deux visions en abordant la modélisation selon

la vision système. Une fois nous avons obtenu la spécification intégrée du système, on peut

la faire projeter sur les différents objets du système. Sur les specifications d’objets ainsi

obtenues, on peut appliquer l’algorithme de génération du prototype de l’IU selon la vision

objet.

7.3. Réseau de Petri versus Statechart

Dans cette section, on vise la comparaison des deux formalismes de spécification d’un

point de vue interface usager. Une comparaison selon certains critères tels que la

concurrence, la hiérarchie et la préemption peut être trouvée dans l’article de Holvoet et al.

[Hol95], qui est à notre connaissance le seul travail de comparaison dans le domaine. La

Table 5 donne une comparaison des deux formalismes selon le point de vue IU.

7.3.1. Concurrence

Les interfaces usagers dirigées par l’utilisateur ne présentent généralement qu’une

concurrence entrelacée, sauf pour certaines applications spéciales telles que les

applications collaboratives. L’utilisateur peut lancer plusieurs tâches en parallèle, mais il

ne peut interagir au même moment avec plus d’une seule tâche. Au niveau interaction, il

s’agit donc d’une concurrence entrelacée et non d’une concurrence pure, ou d’une

concurrence conceptuelle telle que définie par Palanque [Pal97].

Les RdPs sont connus par leur support de la concurrence pure ; ainsi toutes les transitions

dont les places d’entrée ont le nombre suffisant de jetons peuvent être parallèlement

149

tirables. Dans les Statecharts, la concurrence est modélisée par des états orthogonaux (and-

state) composés de plusieurs threads de contrôle. Chaque thread de contrôle est à son tour

un Statechart. Les transitions entre des états de threads différents ne sont pas permises. Une

communication entre les threads ne peut être faite qu’à travers l’échange de messages. Une

transition sortante de n’importe quel état de n’importe quel thread d’un and-state vers un

autre état du système entraîne la terminaison de toutes les threads de contrôle du and-state.

Malgré ces restrictions qui limitent la concurrence au sein des Statecharts par rapport aux

RdPs, les Statecharts restent suffisants pour modéliser des comportants interactifs

concurrentiels de manière structurée.

Les Statecharts sont donc suffisants pour modéliser la concurrence au sein des Ius, alors

que les RdPs modélisent mieux et de manière naturelle les comportements concurrents.

7.3.2. Non-déterminisme

Dans certaines applications interactives (jeux), le système peut répondre à une interaction

de l’utilisateur par un choix aléatoire d’une configuration possible du système. Dans le cas

où le nombre de configurations possibles est fini, le choix aléatoire implique la présence de

comportements non-déterministes au niveau des spécifications. Les RdPs modélisent bien

ces types de comportements, tandis que les Statecharts ne les supportent pas.

Les Statecharts font partie des formalismes déterministes. Dans SUIP-SC, nous avons évité

le non-déterminisme par la création d’un and-state si le même événement mène à plusieurs

états différents. Le and-state créé représente une sélection multiple de toutes les

configurations possibles et non le choix d’une configuration de façon aléatoire. Ceci ne

résoud donc pas le problème du non-déterminisme. Lors de la vérification de la

spécification d’un objet, l’existence d’un comportement non-déterministe est toujours

signalée à l’analyste.

150

7.3.3. Jetons et scénarios multiples

La notion de jetons distingue les RdPs des Statecharts. En effet, les jetons sont utilisés à la

fois pour contrôler la dynamique des RdPs et pour modéliser les ressources du système. La

modélisation de l’exclusion mutuelle est un exemple où les jetons sont utilisés pour

représenter les ressources partagées du système.

Un Statechart modélisant le comportement d’un objet ne peut simuler que l’exécution d’un

seul scénario à la fois. Avec les RdPs, on peut simuler l’exécution simultanée de plusieurs

scénarios de différents cas d’utilisation, voire même l’exécution de plusieurs scénarios du

même cas d’utilisation. Le nombre de jetons dans la place de départ du système représente

le nombre de scénarios qu’on peut exécuter simultanément.

La simulation simultanée de plusieurs scénarios permet de s’assurer plus de la validité de

la spécification du système. Des erreurs de comportement dues à l’interaction mutuelle des

scénarios peuvent être détectées lors de la simulation.

7.3.4. Comportement modal

Par analogie avec une fenêtre modale, un comportement modal inhibe la concurrence dans

le reste du système. Dans un système multi-fenêtré, une fenêtre modale ne permet à

l’utilisateur que des interactions à l’intérieur de cette fenêtre. Les fenêtres ouvertes autres

que la fenêtre modale doivent rester insensibles aux interactions de l’utilisateur. Un

comportement modal peut être défini pour un scénario ou pour un cas d’utilisation du

système. Un comportement modal d’un cas d’utilisation implique que tous ses scénarios

ont des comportements modaux.

Dans les RdPs, les spécifications capturent des exécutions concurrentes de plusieurs

scénarios, et le comportement modal d’un scénario reste difficile à modéliser. Ceci suppose

l’existence de mécanismes pour geler les jetons dans le reste de la spécification du système

à part la partie du scénario actif. De tels mécanismes ont fait l’objet de propositions

d’extension de RdPs pour supporter la préemption [Hol95]. On pourrait toutefois utiliser

151

des conditions de garde pour modéliser un comportement modal, mais ça nécessiterait

l’ajout de conditions au niveau de toutes les transitions du RdP. Ceci alourdirait

grandement le RdP.

L’état historique des Statecharts permet de bien modéliser des comportements modaux.

Lorsqu’un comportement modal est initié, un événement peut être diffusé à toutes les

threads concurrentes pour entrer leurs états historiques. L’état historique sauvegarde

l’environnement d’exécution de chaque thread. Dès que le comportement modal est

terminé, un deuxième message est diffusé aux threads pour les réactiver de nouveau.

7.3.5. Support outil

À part STATEMATE [Har90b], les Statecharts ne sont supportées que par peu d’outils,

tandis que pour les RdPs le nombre d’outils existants dépasse la centaine (des outils

d’édition, de vérification et de simulation).

En outre les travaux d’extension des RdPs sont nombreux : des RdPs à prédicats, des RdPs

colorés, des RdPs temporisés, des RdPs stochastiques et autres. Lors de l’évolution de

l’approche SUIP-PN pour capturer de nouveaux aspects (aspect temps réel par exemple),

on pourrait bénéficier des outils supportant les extensions de RdPs existantes.

7.3.6. Récapitulation

Le tableau suivant (Table 5) résume les différences entre les deux formalismes de

spécification selon les critères précédemment discutés. Nous pouvons conclure que les

RdPs sont plus adéquats à la modélisation des IUs.

152

Critères RdP Statechart

Concurrence ++ +

Non-déterminisme + -

Jetons et scénarios multiples + -

Comportement modal - +

Support outil ++ +

Table 5 : Comparaison des RdPs et Statecharts selon le point de vue IU.

7.4. Génération de l’IU

L’algorithme de génération de l’interface usager qui est utilisé dans les deux approches de

modélisation, est basé sur le graphe des transitions. Ce graphe est dérivé de la spécification

du système (sous forme RdP) dans le cas de l’approche SUIP-PN ou de la spécification

d’un objet d’interface (sous forme de Statechart) dans l’approche SUIP-SC.

7.4.1. Génération basée sur les scénarios

La plupart des travaux de génération de l’IU partent d’une analyse de données ou d’une

analyse des tâches comme mentionné dans le chapitre 1. Certaines approches [Bod94,

Jan93] combinent une analyse des tâches avec la description des données pour une

génération judicieuse de l’IU. Une génération basée sur la description des tâches et des

données du système ne prend en compte que l’aspect statique de l’IU. L’aspect dynamique

d’une IU ne peut être dérivé qu’à partir d’une description du comportement du système.

Notre approche se distingue des autres par la prise en compte lors de la génération de l’IU

des aspects statique et dynamique de celle-ci. L’IU est ainsi générée à partir de la

spécification du système ou de l’objet d’interface et prend en compte la description des

données dans le ClassD pour la génération des widgets appropriés.

153

7.4.2. Critères de composition des blocs d’IU

Tel que décrit dans le chapitre 5, les blocs d’IU (BIU) sont construits en identifiant dans le

graphe des transitions les blocs séquentiels de messages interactifs (règles 1 à 7 de la

section 5.3).

Dans notre recherche, nous avons d’abord essayé de construire ces BIUs à partir de la

spécification intégrant la description de tous les scénarios de tous les cas d’utilisation du

système. Vu que plusieurs états et transitions sont partagés par les différents cas

d’utilisation, on s’est retrouvé avec un grand nombre de BIUs de petite taille (à un ou deux

widgets). Cette façon de procéder permet d’identifier les composantes réutilisables (BIUs

communs à plusieurs CUs), mais ne donne pas des interfaces intéressantes à visualiser.

Pour réduire le grand nombre de BIUs de petite taille, nous avons choisi de construire les

BIUs par cas d’utilisation.

Les BIUs construits étaient toujours non satisfaisants à la visualisation, et nous avons

procédé encore une fois à leur composition en utilisant le critère d’appartenance au même

scénario (scenario membership) tout en respectant les critères ergonomiques. Lors de

l’opération de composition des BIUs, nous commençons par regrouper les BIUs qui

appartiennent au scénario le plus fréquent du cas d’utilisation.

L’IU générée est donc sensible aux valeurs des fréquences des scénarios. La fréquence

d’un scénario est normalement attribuée par l’analyste en consultation avec l’utilisateur,

elle peut donc être sujette à des erreurs. L’analyste peut changer les fréquences des

scénarios et générer plusieurs prototypes de l’IU qu’il pourra éventuellement évaluer avec

l’utilisateur.

7.4.3. Prototypage rapide et évolutif

L’IU générée à partir des spécifications permet son évaluation dans les premières phases

du cycle de développement. L’évaluation de l’IU pourra entraîner la modification des

spécifications qui ont été à la source de la génération. Ce cycle garantit l’acceptation de

154

l’IU par l’utilisateur et une meilleure utilisabilité de celle-ci. Il s’agit donc d’un

prototypage rapide.

Dans l’opération de validation et d’évaluation, le prototype de l’IU est animé par le

simulateur qui masque les données et les fonctionnalités de l’application. Le prototype peut

évoluer vers l’application finale en remplaçant le simulateur par les données et les

fonctionnalités réelles du système. Dans le cadre d’une approche basée sur la notation

UML, les données peuvent être intégrées à partir du ClassD. Les fonctionnalités peuvent

être dérivées à partir des diagrammes d’activité ou directement implantées par les

développeurs.

Dans nos travaux, le prototype est généré sous forme d’une application Java. La génération

pourrait être faite en d’autres langages et serait de préférence supporté par un interface

builder.

7.4.4. Styles d’IU

L’algorithme de génération de l’IU proposé dans le chapitre 5 s’applique avec succès à des

applications fenêtrées composées de widgets où les interactions sont de haut niveau. Des

interactions de bas niveau telles que les déplacements de la souris et les défilements du

curseur sont laissées à la charge du système de fenêtrage sous-jacent. Les interactions

considérées sont essentiellement des saisies, des affichages, des sélections et des actions

sur boutons.

D’autres styles d’IU prenant en compte des opérations de bas niveau ne sont pas

supportées dans notre approche. Les applications graphiques de dessins ou les éditeurs

graphiques peuvent être spécifiés en utilisant nos approches mais leur Ius ne peuvent être

générées de manière automatique.

155

7.5. Validation et expériences

Tout au long de ce travail, nous avons tenu à valider nos idées et propositions par

l’implantation des différents algorithmes et l’expérimentation des approches sur un

ensemble de systèmes réels. Nous avons expérimenté les approches SUIP-PN et SUIP-SC

sur les systèmes suivants : le système de guichet automatique bancaire (ATM), le système

de bibliothèque et le système de station d’essence. Le temps d’exécution des différents

algorithmes implantés était de l’ordre de quelques secondes, sachant que le nombre de

scénarios varie de cinq à huit scénarios par système.

7.5.1. L’approche SUIP-PN

Tel que décrit dans le chapitre 3 et l’annexe C, l’approche SUIP-PN utilise un ensemble

d’outils existants (designCPN, Sxtool, XML4J et Visual Café) intercalée par l’application

de deux algorithmes développés en Java.

Le premier algorithme lit et intègre les spécifications des scénarios en RdPs sous le format

XML, et produit les spécifications intégrées des cas d’utilisation du système sous le format

XML. Les spécifications des scénarios sous le format XML, entrées de cet algorithme, sont

le résultat de l’utilisation de la séquence d’outils designCPN, Sxtool et XML4J pour

transformer les scénarios dans le format XML.

Le deuxième algorithme prend comme entrée les spécifications intégrées des cas

d’utilisation pour en produire le prototype de l’interface usager du système.

Les deux algorithmes sont polynomiaux. Leurs implantations comptent environ 4000

lignes de code de Java (commentaires inclus).

7.5.2. L’approche SUIP-SC

Dans l’approche SUIP-SC, une suite d’algorithmes est automatiquement appliquée aux

scénarios du système pour produire les spécifications intégrées des différents objets, et

156

ensuite générer les prototypes d’IU des objets d’interface. Cette approche apporte plus de

mécanisation que l’approche SUIP-PN vu que toutes les activités de son processus sont

supportées par des algorithmes que nous avons développés ou qui ont été développés au

sein de notre laboratoire (voir annexe C).

Les entrées de cette approche sont le ClassD décrivant les données, et les CollDs décrivant

les scénarios du système. La série des cinq algorithmes est alors appliquée pour obtenir les

résultats souhaités.

Le premier algorithme transforme les CollDs en spécifications partielles d’objets. Le

deuxième algorithme étiquette les spécifications partielles produites par le premier

algorithme. Le troisième algorithme intègre les spécifications partielles étiquetées du

même objet. Le quatrième algorithme génère à partir de la spécification intégrée de chaque

objet d’interface un prototype visuel de l’IU. Le cinquième algorithme vérifie la cohérence

des spécifications produites. Tous les algorithmes précités sont implantees en Java avec un

total d’environ 4500 lignes de code (commentaires inclus).

Dans les approches SUIP-PN et SUIP-SC, les prototypes d’IU sont générés sous forme de

code Java compatible avec l’interface builder Visual Café [Sym97]. On peut toutefois

simuler les prototypes générés directement sous le langage Java. L’outil Visual Café n’est

utilisé que pour améliorer l’aspect visuel des prototypes par l’ajout de titres et

commentaires dans les frames générées, par une disposition personnalisé des widgets, par

l’ajout de couleurs, etc.

7.6. Conclusion

Dans ce chapitre, nous avons discuté les avantages et les inconvénients de approches

SUIP-PN et SUIP-SC. Il ressort de cette discussion que l’approche SUIP-PN a plus

d’avantages que d’inconvénients par rapport à SUIP-SC. Cependant, dans certains types

157

d’applications telles que les applications collaboratives, l’approche SUIP-SC donne de

meilleurs résultats.

158

Chapitre 8

Conclusion Dans ce travail, nous avons défini un processus itératif pour l’ingénierie des exigences des

systèmes interactifs. Ce processus a été raffiné par deux approches de modélisation. La

première vise l’étude du comportement de tout le système en utilisant les réseaux de Petri à

haut niveau comme formalisme de spécification. La deuxième s’intéresse à l’étude des

comportements individuels des différents objets du système et en particulier des objets

d’interface. Les comportements des objets ont été décrits par les StateDs de la notation

UML.

Les deux approches de modélisation SUIP-PN et SUIP-SC utilisent les scénarios pour

l’acquisition des besoins et génèrent un prototype de l’interface usager du système à partir

des spécifications des comportements et des données du système.

Les principaux apports de ce travail, outre le cadre méthodologique lié au processus itératif

proposé et le cadre comparatif des deux approches SUIP-PN et SUIP-SC, ré ident aux

niveaux : de la notation UML, de l’approche scénario, de la génération de l’IU, et de la

validation des approches et du support outil. Ces différents apports seront décrits dans les

sections qui suivent. La section des travaux futurs termine ce chapitre.

159

8.1. La notation UML

Nous avons proposé une extension de la notation par l’ajout de nouvelles contraintes pour

décrire les interactions des utilisateurs avec le système. Ces contraintes sont associées aux

messages interactifs échangés entre les objets du système (Section 3..3.1).

Nous avons également proposé un raffinement des relations uses entre les cas d’utilisation

d’un système, voir même proposé un nouveau type de diagramme (diagramme

d’interaction des cas d’utilisation) pour mieux capturer les interactions possibles entre les

différents cas d’utilisation du système. Ce diagramme tel que proposé dans la section 7.1.1,

est similaire à un diagramme de collaboration où les objets sont les cas d’utilisation du

système.

8.2. L’approche scénario

Nous avons défini deux façons de passer à partir de descriptions semi-formelles des

scénarios (SequenceD et CollD) vers des spécifications formelles. La première permet le

passage d’un scénario décrit en un diagramme de séquence vers un réseau de Petri

capturant le scénario. La deuxième manière décrit le passage de la description du scénario

en forme de diagramme de collaboration vers les Statecharts des objets participant dans ce

scénario.

Nous avons proposé deux nouveaux algorithmes d’intégration des scénarios dans le but

d’obtenir des spécifications compactes du système et des objets.

Dans le cas du premier algorithme d’intégration (approche SUIP-PN), chaque scénario est

représenté par un RdP coloré. L’opération d’intégration mène à la fusion des états et

transitions, à la définition de couleurs composites et de jetons multi-couleurs. La notion de

jeton caméléon a été introduite pour résoudre le problème d’entrelacement entre les

scénarios. Cet algorithme permet l’integration de scénarios séquentiels et concurrents.

160

Dans le deuxième algorithme d’intégration (approche SUIP-SC), les comportements à

intégrer sont les Statecharts d’un même objet découlant des différents scénarios du

système. Outre l’intégration de scénarios séquentiels et concurents, cet algorithme prend

également en considération l’aspect hiérachique des spécifications.

8.3. Génération de l’IU

L’algorithme proposé, qui a servi dans les deux approches de modélisation, permet de

dériver les aspects statique et dynamique du prototype de l’interface usager à partir des

spécifications de comportement et de données du système. Le prototype généré capture

tous les scénarios acquis du système, et il est muni d’un simulateur permettant la validation

de l’interface usager avec l’utilisateur final dans les premières phases de développement.

Dans cet algorithme, nous avons défini un ensemble de règles de construction des blocs

d’interface usager et un ensemble d’heuristiques pour leur composition afin de produire

des fenêtres intéressantes à visualiser.

8.4. Validation des approches et support outil

Nous avons essayé de supporter toutes les activités des deux approches de modélisation par

des outils existants ou développés.

Dans l’approche utilisant les réseaux de Petri, nous avons combiné l’utilisation d’outils

existants avec des algorithmes que nous avons développés. L’acquisition des besoins et la

dérivation des spécifications sont restées à la charge de l’analyste. Nous avons montré

comment certains outils de vérification existants peuvent s’insérer dans notre approche.

Dans l’approche utilisant les Statecharts, toutes les activités de l’approche ont été

supportées par le développement d’algorithmes. Après une saisie textuelle (vu que les

éditeurs des diagrammes de collaboration existants sur le marché ne supportent pas la

concurrence) des différents diagrammes relevant de l’approche (diagramme des classes et

diagrammes des collaboration), le prototype de l’interfaces usager et les Statecharts

161

intégrés des différents objets du système sont automatiquement générés. Nous avons

également proposé, dans le cadre de cette approche, un algorithme de vérification basé sur

la sémantique des pré- et post-conditions des transitions. Cet algorithme permet de détecter

les incohérences des spécifications avant et après l’intégration des scénarios et

éventuellement indiquer certaines incomplétudes dans les spécifications. L’algorithme

vérifie également la cohérence de comportements concurrents dans les spécifications

résultantes.

Les approches SUIP-PN et SUIP-SC ont été expérimentées sur un ensemble de systèmes

d’information de taille moyenne à savoir : le système de guichet automatique bancaire

(ATM), le système de bibliothèque, le système de station d’essence et un système

d’archivage. Le nombre de scénarios des systèmes expérimentés varie de cinq à huit

scénarios. Les IUs simples générées par les approches correspondent exactement aux

exigences capturées dans les scénarios décrivant les systèmes.

8.5. Travaux futurs

À la lumière de la discussion des deux approches de modélisation dans le chapitre 7,

plusieurs pistes d’amélioration et de continuation de ce travail peuven être prospectées :

• L’étude des différentes formes d’interaction entre les scénarios et les cas d’utilisation

d’un système. Dans ce travail, nous capturons certaines de ces interactions au niveau

des cas d’utilisation, mais nous supposons que les scénarios d’un même cas

d’utilisation sont indépendants. Or, il est possible que les scénarios d’un même cas

d’utilisation ou de cas d’utilisation différents, présentent des contraintes mutuelles

d’exécution (comportement modal par exemple).

• L’amélioration des algorithmes définis dans ce travail. L’algorithme de génération du

prototype de l’interface usager peut être amélioré par la prise en compte d’autres styles

d’interaction. Les algorithmes d’intégration peuvent être améliorés et étendus pour des

systèmes exhibant des contraintes temporelles.

162

• L’étude et la spécification de la traçabilité dans le processus itératif proposé, pour

supporter des retours en sens inverse entre les étapes du processus et maintenir la

cohérence entre toutes les composantes manipulées dans le système (spécifications

semi-formelle, spécifications formelles et le prototype de l’interface usager). Toute

modification dans l’une des composantes doit se refléter automatiquement dans les

autres.

• L’étude de l’utilisabilité du prototype de l’interface usager en se basant sur l’évaluation

de la complexité des spécifications et sur des modèles d’estimation des temps

d’exécution des transitions du système.

163

Bibliographie

[Alu94] Alur R. and Dill D. : A Theory of Timed Automata. Theoretical Computer Science,

Vol.125, pp.183-235 (1994).

[Avi90] Avision D. and Wood-Harper T. : Multiview Methodology. Oxford. Blackwell Scientific Publishers, (1990).

[Bal96] Balzert H. : From OOA to GUIs : The JANUS System. Journal of Object-Oriented Programming, Vol.8, No.9, pp.43-47 (1996).

[Bas91] Bass L., Little R., Pellegrino R., Reed S., Seacord R., Sheppard S. and Szczur M.R. : The Arch Model. User Interface Developers’Workshop (04/1991).

[Bäu96] Bäumer D., Bischofberger W., Lichter H. and Zullighoven H. : User Interface Prototyping – Concepts, Tools And Experience. IEEE Proceedings of ICSE-18, Berlin, Germany, pp.532-541 (03/1996).

[Bie76] Biermann A.W. and Krishnaswamy R. : Constructing Programs from Example Computations. IEEE Transaction on Software Engineering, Vol.2, No.3, pp.141-153 (1976).

[Bis92] Bischofberger W. and Pomberger G. : Prototyping-Oriented Software Development, Concepts and Tools. Springer-verlag (1992).

[Bod94] Bodart F., Hennebert A.-M., Leheureux J.-M., Provot I. and Vanderdonckt J. : A Model-based Approach to Presentation : A Continuum from Task Analysis to Prototype. In Proceedings of the Eurographics Workshop on Design, Specification, Verification of Interactive Systems, Carrara, Italy, Focus on Computer Graphics, Springer-Verlag, Berlin, pp.77-94 (06/1994).

[Boo95] Booch, G. and Rumbaugh, J. : Unified Method For Object-Oriented Development, Documentation Set Version 0.8 (white paper). Rational Software Corporation, Santa Clara, CA (1995).

[Cam92] Campbell R.L. : Categorizing scenarios : A quixotic quest? SIGCHI Bulletin, Vol.24, No.4, pp.16-17 (10/1992).

[Car83] Card S.K., Moran T.P. and Newell A. : The Psychology of Human Computer Interaction. Lawrence Erlbaum Associates (1983).

164

[Car95] Carroll J. M. : The Scenario Perspective on System Development. In Scenario Based Design : Envisioning Work and Technology in System Development. Ed Carroll J. M., pp.1-17, Wiley & Sons (1995).

[Che90] Chekland P. and Scholes J. : Soft-System Methodology in Action. Chichester. John Wiley & Sons (1990).

[Cla99] J. Clark. SX : An SGML System Conforming to International Standard ISO 8879, <http://www.jclark.com/sp/sx.htm>.

[Col94] Coleman D., Arnold P., Bodoff S., Dollin C., Gilchrist H., Hayes F. and Jeremaes P. : Object-Oriented Development : The Fusion Method. Prentice Hall (1994).

[Cou90] Coutaz J. : Interface Homme-Ordinateur, Conception et Réalisation. Dunod Informatique (1990).

[Dan97] Dano B., Briand H. and Barbier F. : An Approach based on the Concept of Use Case to Produce Dynamic Object-Oriented Specifications, In proceeding of the Third IEEE International Symposium on Requirements Engineering, pp.54-64, Annapolis (1997).

[Dar93] Dardenne A., Lamsweerde V. and Fickas S. : Goal-directed Requirements Acquisition. Science of Computer Programming, Vol.20, pp.3-50, Elsevier (1993).

[Del98] Delatour J. and Paludetto M. : UML/PNO, a way to merge UML and Petri net objects for the analysis of rel-time systems. Lecture Notes in Computer Science, Vol.1543, pp.511-514, Springer Verlag (1998).

[Des98] Desharnais J., Khediri R., Frappier M. and Mili A. : Integration of Sequential Scenarios. Transactions on Software Engineering, Vol.24, No.9, pp.695-704 (10/1998).

[Duk93] Duke D.J. and Harrison M.D. : Abstract Interaction Objects. Computer Graphics Forum, Vol.12, No.3, pp.25-36 (1993).

[Eas89] Eason K.D. and Harker S. : An Open Systems Approach to Task Analysis. Internal report, HUSAT Research Centre, Loughborough University of Technology, England (1989).

[Elk98] Elkoutbi M. and Keller R. K. : Modeling Interactive Systems with Hierarchical Colored PetRi Nets, In Proc. of 1998 Adv. Simulation Technologies Conf., pp.432-437, Boston, MA (04/1998).

[Elk99] Elkoutbi M., Khriss I. and Keller R. K. : Generating User Interface Prototypes from Scenarios. In Proceedings of the Fourth IEEE International Symposium on Requirements Engineering (RE’99), pp.150-158, Limerick, Ireland (06/1999).

165

[Elk00] Elkoutbi M. and Keller R. K. : User Interface Prototyping based on UML Scenarios and High-level Petri Nets. In Application and Theory of Petri Nets 2000 (Proc. of 21st Intl. Conf. on ATPN), Springer-Verlag LNCS 1825, pp.166-186, Aarhus, Denmark (06/2000).

[Eri95] Erickson T. : Notes on Design Practice, Stories and Prototypes as Catalysts for Communication. In Scenario Based Design : Envisioning Work and Technology in System Development. Ed. Carroll J.M., pp.37-58, Wiley & Sons (1995).

[Fin93] Finkel A. : The Minimal Coverability Graph for Petri Nets. In G. Rozenberg (ed.): Advances in Petri Nets 1993, Lecture Notes in Computer Science, Springer-Verlag, Vol.674, pp.210-234 (1993).

[Fol93] Foley J.D. and Sukaviriya P. : A Second Generation User Interface Design Environment : The Model and the Runtime Architecture. INTERACT’93 and CHI’93, pp.375-382, Amsterdam (04/1993).

[Fro89] Frohlich D.M. and Luff P. : Some Lessons from an Exercise in Specification. Human-Computer Interaction, vol.4, pp.121-147 (1989).

[Gli95] Glinz M. : An Integrated Formel Model of Scenarios based on Statecharts. In Fifth European Software Engineering Conference, Lecture Notes in Computer Science, Vol.989, pp.254-271, Springer-verlag (1995).

[Gol84] Goldberg A. : Smalltalk-80, The Interactive Programming Environment. Vol.1, Tome 2 : The Language and its Implementation. Addison Wesley (1984).

[Gol98] Goldfarb C.F. and Prescod P. : The eXtended Markup Language (XML) Handbook. Prentice Hall (1998).

[Gor95] Gordon V.S. and Bieman J. : Rapid Prototyping : Lessons Learned. IEEE Software, Vol.12, No.1, pp.85-95 (01/1995).

[Gou95] Gough P.A., Fodemski F.T., Higgins S.A. and Ray S.J. : Scenario – an industrial Case Study and Hypermedia Enhancements. IEEE Second Symposium on Requirements Engineering, pp.10-17 (1995).

[Har87] Harel, D. : Statecharts : A Visual Formalism for Complex Systems. Science of Computer Programming, vol.8, pp.231-274 (1987).

[Har89] Harton H.R. and Hix D. : Toward Empirically Derived Methodologies and Tools for HCI Development. In International Journal of Man-Machine Studies, vol.31, pp.477-494 (1989).

[Har90a] Harton H.R. and Hix D. : Developping Human-Computer Interface Models and

166

Representation Techniques. Software-Practice and Experience, Vol.20, No.5, pp.425-457 (05/1990).

[Har90b] Harel D. , Lachover H., Naamad A., Pnueli A., Politi M., Sherman R., Shtull-Trauring A. and Trakhtenbrot M. : STATEMATE : A Working Environment for The Development of Complex Reactive Systems. Transactions on Software Engineering, Vol.16, No. 4, pp.403-414 (04/1990).

[Hei96] Heimdahl M.P.E. and Leveson N.G. : Completeness and Consistency in Hierarchical State-Based Requirements. IEEE Transactions on Software Engineering, Vol.22, No.6, pp.363-377 (06/1996).

[Hei98] Heitmeyer C., Kirby J., Labaw B. and Bharadwaj R. : SCR* : A Toolset for Specifying and Analyzing Software Requirements, Proc. of the 10th Annual Conference on Computer-Aided Verification, (CAV’98), Vancouver, Canada, pp. 526-531 (1998).

[Hey98] Heymans P. and Dubois E. : Scenario-Based Techniques for Supporting the Elaboration and the Validation of Formal Requirements. Requirements Engineering, Vol.3, No.3/4, pp.202-218 (1998).

[Hil93] Hill R.D., Brinck T., Patterson J.F., Rohall S.L. and Wilner W.T. : The Rendezvous Language and Architecture. Communications of the ACM. Vol.36, No.1, pp.63-67 (01/1993).

[Hix93] Hix D. and Hartson H.R. : Developing User Interfaces : Ensuring Usability Through Product and Process. Wiley J. and Sons (1993).

[Hsi94] Hsia P., Samuel J., Gao J., Kung D., Toyoshima Y. and Chen C : Formal Approach to Scenario Analysis. IEEE Software, Vol.11, No.2, pp. 33-41 (Mar 1994).

[Hol95] Holvoet T. and Verbaeten P. : Petri Charts : an Alternative Technique for Hierarchical Net Construction. In Proceedings of the 1995 IEEE Conference on Systems, Man and Cybernetics (IEEE-SMC’95), Vancouver, Canada, pp.22-25 (1995).

[Hud87] Hudson S.E. : UIMS Support for Direct Manipulation Interfaces. Computer Graphics, Vol. 21, N 2, pp.120-124 (04/1987).

[IBM91] IBM : Systems Application Architecture : Common User Access – Guide to User Interface Design – Advanced Interface Design Reference, IBM (1991).

[IBM99] IBM. XML Parser for Java. In Java Report’s February 1999. <http ://www.alphaworks.ibm.com/formula/xml>.

[ISO88] LOTOS : A Formal Technique based on the Temporal Ordering of Observational

167

Behaviour. Technical Report 8807, ISO Standards Authority (1988).

[Jaa95] Jaaksi A. : Object-Oriented Specification of User Interfaces. Software – Practice & Experience, Vol.25, No.11, pp.1203-1221 (11/1995)

[Jac92] Jacobson I., Christerson M., Jonsson P. and Oevergaard G. : Object-Oriented Software Engineering : A Use Case Driven Approach. Addison Wesley (1992).

[Jac96] Jackson M. : Software Requirements and Specifications. Addison Wesley (1996).

[Jan93] Janssen C., Weisbecker A. and Ziegler J. : Generating User Interfaces from Data Models and Dialogue Net Specifications. IFIP International Conference on Human-Computer Interaction INTERACT’93 and Conference on Human Factors in Computing Systems CHI’93, pp.418-423, Amsterdam (04/1993).

[Jen95] Jensen K. : Coloured Petri Nets, Basic Concepts, Analysis Methods and Pratical Use, Springer (1995).

[Joh92] Johnson J. : Selectors : Going Beyond User-Interface Widgets. Conference on Human Factors in Computing Systems CHI’92, pp. 273-279, Monterey, CA (05/1992).

[Kaw97] Kawashita I. : Spécification Formelle de Systèmes d’Information Interactifs Par La Technique de Scénarios. Master thesis, Université de Montréal (1997).

[Khr99] Khriss I., Elkoutbi M. and Keller R. K. : Automating the synthesis of UML Statechart Diagrams from Multiple Collaboration Diagrams. In J. Bezivin and P. A. Muller, ed., <<UML>>’98 : Beyond the Notation, pp.132-147. Springer LNCS 1618 (1999).

[Kier83] Kieras D. and Polson G. : A Generalised Transition Network Representation for Interactive Systems. In Proceedings of CHI’83, Human factors in computing systems, pp.103-106, (1983).

[Kos94] Koskimies K. and Makinen E. : Automatic Synthesis of State Machines from Trace Diagrams. Software Practice & Experience, Vol.24, No.7, pp.643-658 (1994).

[Kov99] Kovacevic S. : UML and User Interface Modeling. In J. Bezivin and P. A. Muller, ed., <<UML>>’98 : Beyond the Notation, pp.253-266. Springer LNCS 1618 (1999).

[Kru95] Kruchten P.B. : The 4 + 1 View Model Architecture. IEEE Software, Vol.12, No.6, pp.42-50 (1995).

[Kuu95] Kuuti K. : Creating Contexts for Design. In Caroll J.M. editor, Scenario-Based Design : Envisioning Work and Technology in System Development, pp.19-36. John Wiley and Sons (1995).

[Kyn95] Kyng M. : Creating Contexts for Design. In Caroll J.M. editor, Scenario-Based

168

Design : Envisioning Work and Technology in System Development, pp.85-107. John Wiley and Sons (1995).

[Lee98] Lee W.J. and Kwon Y.R. : Integration and Analysis of Use Cases Using Modular Petri Nets in Requirements Engineering. IEEE Transactions on Software Enginering, Vol.25, No.12, pp.1115-1130 (12/1998).

[Lev94] Leveson N., Heimdahl M.P.E., Hildreth H. and Reese J.D. : Requirements specifications for process-control systems. IEEE Transactions on Software Engineering, Vol.20, No.9, pp.684-707 (09/1994).

[Lus97] Lustman F. : A Formal Approach to Scenario Integration. Annals of Software Engineering, Vol. 3, pp.255-272 (09/1997).

[Mor81] Moran T. : The Command Language Grammar, A Representation of the User Interface of Interactive Computer Systems. International Journal of Man-Machine Studies, Vol.15, No.1, pp.3-50 (1981).

[Mye90] Myers B.A., Giuse D.A., Dannenberg R.B., Zanden B.V., Kosbie S., Pervin E., Mickish A. and Marchal P. : Garnet : Comprehensive Support For Graphical, Highly-Interactive User Interfaces. IEEE Computer, Vol.23, No.11, pp.71-85 (11/1990).

[Mye92] Myers B.A. and Rosson M.B. : Survey on User Interface Programming. In Human Factors in Computing Systems, pp. 195-202. Proceedings of Special Interest Group on Computer-Human Interaction SIGCHI’92, Monterey, CA (03/1992).

[Mye95] Myers B.A. : User Interface Software Tools, ACM Transactions on Computer-Human Interaction. Vol.2, No.1, pp. 64-103 (03/1995).

[Nar86] Narahari Y. : On the Invariants of Coloured Petri Nets. In G. Rozenberg (ed.): Advances in Petri Nets 1985, Lecture Notes in Computer Science, Springer-Verlag, Vol.222, pp.330-345 (1986).

[Nar92] Nardi B. A. : The Use of Scenarios in Design”, SIGCHI Bulletin, Vol.24, No.4 (10/1992).

[Nig91] Nigay L. and Coutaz J. : Software Design Rules for Multi-agent Architectures Amodeus. BRA RP2/WP17, (1991).

[Pal97] Palanque P. and Batide R. : Specifications Formelles pour l’Ingenierie des Interfaces Homme-Machine. In Proceedings of IHM’97, Poitiers, France (1997).

[Pat92] Paterno F. and Faconti G. : On the Use of Lotos to Describe Graphical Interaction. HCI’92, pp.155-174 (1992).

[Pau92] Pausch R., Conway M. and Deline A. : Lessons Learned from SUIT, The Simple User

169

Interface Toolkit. ACM Transactions on Information Systems, Vol.10, No.4, pp.320-344 (10/1992).

[Pfa85] Pfaf G. E. : User Interface Management Systems. Eurographics Seminars, Springer-Verlag (1985).

[PNT99] Petri Net Tools Database Quick Overview : http://www.daimi.aau.dk/PetriNets/tools/quick.html (1999).

[Poo99] Pooley R. and King P. : The Unified Modeling Language and Performance Engineering. IEEE Software, Vol.146, pp.2-10 (02/1999)

[Pot94] Potts C., Takahashi K. and Anton A. : Inquiry-Based Requirements Analysis. IEEE Software, Vol. 11, No.2, pp.21-32 (03/1994).

[Pot95] Potts C. : Using Schematic Scenarios To Understand User Needs. In Proceedings of the Symposium on Designing Interactive Systems, Michigan USA, pp.247-256 (08/1995).

[Pre94] Preece J., Rogers Y., Sharp H., Benyon D., Holland S. And Carey T. : Human-Computer Interaction. Addison-Wesley (1994).

[Rol98] Rolland C., Ben Achour C., Cauvet C., Ralyté J., Sutcliffe A., Maiden N.A.M., Jarke M., Haumer P., Dubois P. K., and Heymans P. : A Proposal for a Scenario Classification Framework. In Requirements Engineering Journal, Vol.3, No.1, pp.23-47 (1998).

[Ros99] Rosson M. B. : Integrating Development of Task and Object Models. Communications of the ACM, 42(1), pp. 49-56 (01/1999).

[Rou93] Rouff C. : Specification and Rapid Prototyping of User Interface. PhD Thesis, University of Southern of California (08/1993).

[Roy95] Royer T. : Using Scenario-Based Designs to Review User Interface Changes and Enhancements. In Proceedings of the Symposium on Designing Interactive Systems, Michigan USA, pp.237-246 (08/1995).

[Rum91] Rumbaugh J., Blaha M., Premerlani W., Eddy F. and Lorensen W. : Object-Oriented Modeling and Design. Prentice-Hall Inc. (1991).

[Rum99] Rumbaugh J., Jacobson I., and Booch G., The Unified Modeling Language Reference Manual. Addison Wesley, Inc. (1999).

[Sch96] Schlungbaum S. and Elwert T., Modeling a Netscape-like browser using TADEUS Dialogue Graphs. In Handout of CHI’96 Workshop on Formal Methods in Computer Human Interaction: Comparison, Benefits, Open Questions, Vancouver, pp.19-24

170

(1996).

[Sch00] Schönberger S., Keller R.K. and Khriss I. : Algorithmic Support for Model Transformation in Object-Oriented Software Development. In Theory and Practice of Object Systems (TAPOS). John Wiley and Sons (2000), to appear.

[SGM86] Standard Generalized Markup Language (SGML) : ISO Standard 8879. International Organization for Standardization. Genève, Switzerland (1986).

[Shl92] Shlaer S. and Mellor S.J. : Object Lifecycles, Modeling The Word In States. Yourdon Press (1992).

[Som96] Somé S.S., Dssouli R. and Vaucher J. : Toward an Automation of Requirements Engineering using Scenarios. Journal of Computing and Information. Special issue: ICCI'96, 8th International Conference of Computing and Information, Vol.2, No.1, pp.1110-1132 (1996).

[Som97] Somé S.S. : Dérivation de spécifications à partir de scénarios d’interaction. PhD thesis, Université de Montréal, Canada (07/1997).

[Spi88] Spivey J.M. : The Z Notation : A Reference Manual. Prentice Hall International (1988).

[Sym97] Symantec, Inc. : Visual Café for Java: User Guide. Symantec, Inc. (1997).

[Sze95] Szekely P. : User Interface Prototyping: Tools and Techniques. Software Engineering and Human Computer Interaction: Joint Research Issues, pp.76-92. Springer LNCS 896 (1995).

[Tar93] Tarby J-C. : Gestion automatique du dialogue homme-machine à partir de spécifications conceptuelles. PhD thesis, Université de Toulouse, France (09/1993).

[UML97] Booch G., Rumbaugh J. and Jacobson I: The Unified Modeling Language For Object-Oriented Development, Documentation Set Version 1.0 addendum, Rationale Software Corporation, Santa Clara, CA (1997).

[Van91] Van Zijl L. and Mitton D. : Using Statecharts to design and Specify a Direct Manimpulation Graphical User Interface. In Proceedings of the 6th Southern African Computer Symposium, pp.51-68, (07/1991).

[Was85] Wasserman A.I. : Extending State/Transition Diagrams for the Specification of Human-Computer Interaction. IEEE Transaction on Software Engeneering, Vol.11, No.8, pp.699-713 (08/1985).

[Wei95] Weinand A. and Gamma E. : ET++ a Portable Homogeneous Class Library and Application Framework. In Lewis T. Editor. Object Oriented Application

171

Frameworks, Chapter 7, pp.154-194. John Wiley and Sons (1995).

[Wer94] Wernecke J. : The Inventor Mentor. Addison-Wesley Plublishing Company, Reading, MA (1994).

[Wol99] Wolf G. : Petri Net Tools. http://home.arcor-online.de/wolf.garbe/petrisurv2.html (1999)

[Woo70] Woods W.A. : Transition Network Grammars for Natural Language Analysis. Communication of the ACM, Vol.13, No.10, pp.591-606, (10/1970).

[Woo94] Wood D.P. and Christel M.G. : A Multimedia Approach to Requirements Capture and Modelling. In Proc. of the First International Conference on Requirements Engineering (ICRE'94), pp.53-56, Colorado Springs, CO (04/1994).

172

Annexe A : Grammaires des diagrammes UML utilisés

Cet annexe présente les grammaires des diagrammes UML que nous avons utilisés dans ce

travail (ClassD, CollD et StateD). Les descriptions ne sont pas complètes, on se limite aux

parties pertinentes pour ce travail. Les grammaires sont décrites selon le format EBNF qui

utilise les conventions suivantes :

| : désigne des alternatives (ou),

() : indique les précédences,

[élément] : indique que élément est optionnel,

{élément} : indique que élément peut survenir zéro ou plusieurs fois,

A.1. Diagramme de classes (ClassD)

Un ClassD est défini par un ensemble de classes liées par un ensemble de relations. Une

classe est définie par son nom, un ensemble d’attributs et un ensemble d’opérations. La

grammaire ci-après décrit uniquement la structure des classes. Les relations entre classes

ne sont pas décrites.

ClassD = [classDName] Class = className {attribute} {operation}. attribute = attributeName " (" ("string =" string_litteral ) | ( "integer =" integer_litteral ) | ( "float =" floating_point_litteral ) | ( "char =" character_litteral ) | ( "boolean =" "true" | "false" ) ")". operation = operationName " (" [ parameter

173

{"," parameter } ] ")" [ ":" ("string" | "integer | "float" | "char" | "boolean" ) ] "pre" orExpression "post" ( orExpression | ifExpression {"OR" ifExpression}). parameter = parameterName ":" ( "string" | "integer | "float" | "char" | "boolean" ). ifExpression = "(IF" orExpression "THEN" orExpression "ENDIF)". orExpression = andExpression |( "(" andExpression ("or" andExpression )+ ")"). andExpression = basicExpression | ( "(" basicExpression ("and" basicExpression ")")+ ). basicExpression =

"(" identifier ( ( ( "=" | "<" | ">" "<=" | ">=" ) ( string_literal | character_literal | interger_literal | floating_point_literal ) )

| ("=" ( "true" | "false" ) ). className, attributeName, operationName, parameterName: identifier.

A.2. Diagramme de collaboration (CollD)

Un CollD décrit les interactions au sein d’un scénario. La description commence par la

fréquence du scénario et le message initiant le scénario. La notion de fréquence est une

extension aux diagrammes d’interaction (CollD et SequenceD) pour capturer combien de

fois le scénario a lieu.

CollD = ["frequency=" integer_literal] startMessage {object}. startMessage = message object. object = ["{new}" | "{destroyed}" | "{transient}"] [objectName] [":" packageName] [":" className] {attributeName "=" value}

174

{link}. link = linkedObject [role] [linkType] {message}. role = ["{new}" | "{destroyed}" | "{transient}"] roleName. linkType = "{association}" | "{global}" | "{local}" | "{parameter}" | "{self}". message = controlFlowType [predecessor] [sequenceExpression] [returnValue ":="] messageName ["("[ argument {"," argument} ] ")"] [constraint]. controlFlowType = procedureCall | flatFlow | asynchronousFlow. procedureCall = ➞ . flatFlow = → . asynchronousFlow = →. predecessor = sequenceNumber {"," sequenceNumber } "/". sequenceExpression = sequenceNumber [recurrence] ":". sequenceNumber = integer_literal {("." integer_literal) | character_literal }. recurrence = "*" iteration_clause | condition_caluse. constraint = "{" ( ("inputData(" className "." ( operationName | attributeName ) ")" ) | ("outputData(" ( ( className "." attributeName ) | <string_Literal> ) ")" ) "}". argument = identifier | string_literal | integer_literal |

175

character_literal | "true" | "false". iteration_clause = ( identifier "=" integer_literal ".." integer_literal ) | condition_clause = ifExpression {"OR" ifExpression} | orExpression. ObjectName, className, packageName, className, attributeName, roleName, returnValue, messageName , linkedObject, roleName = identifier. ifExpression et orExpression ont la même définition que dans le ClassD (Annexe

A.1).

A.3. Statecharts (StateD)

Un Statechart est décrit de manière récursive par son nom, son type, l’ensemble de ses

sous-états, l’ensemble de ses transitions et l’ensemble de variables d’états.

StateD = [name] {stateVariableDecl} {node} {transition}. stateVariableDecl = stateVariable ":" [className] ["=" initValue]. node = initialState | regularState | terminalState | merge bar | split bar | orstate | andstate. orstate, andstate = [name] {substate}. substate = StateD. transition = fromNode [event] [guardCondition] {"/" action}

176

{sendClause} ["^" returnValue] toNode. fromNode, toNode = <ref to Node>. event = eventName "(" [parameter {"," parameter}] ")". guardCondition = "[" conditionExpression "]". sendClause = syncIndicator [result ":="] target "." event. syncIndicator = procedureCall | flatFlow | asynchronousFlow. procedureCall = ➞ . flatFlow = → . asynchronousFlow = →. target = className | objectName. action = actionName "(" [ argument { "," argument } ] ")". condition_clause = ifExpression {"OR" ifExpression} | orExpression. stateName, stateVariable, className, objectName, parameter, resutlt, argument = identifier. ifExpression et orExpression ont la définition que dans le ClassD (Annexe A.1).

177

Annexe B : SUIP version Statechart (SUIP-SC) Le logiciel SUIP-SC (Scenario-based User Interface Prototyping version StateChart) a été

développé dans le but de supporter toutes les activités de l’approche SUIP-SC décrite dans

le chapitre 4. Étant compatible avec la notation UML, SUIP-SC permet de lier les modèles

UML au prototype de l’interface usager. SUIP-SC consiste en une suite d’algorithmes :

1. transformation des descriptions semi-formelles des scénarios (CollDs) en spécifications

formelles non étiquetées (StateDs non étiquetés),

2. étiquetage des spécifications générées par le premier algorithme (StateD étiqueté),

3. intégration des spécifications étiquetées par objet (StateD intégrée par objet),

4. génération du prototype de l’IU à partir des spécifications intégrées des objets

d’interface.

Tous les algorithmes implantés ont un temps d’exécution polynomial au pire cas à part

l’algorithme d’étiquetage qui est exponentiel au pire cas.

SUIP-SC est du domaine public, et il est accessible à travers le lien suivant :

http://www.iro.umontreal.ca/labs/gelo/suip

B.1. Structure en projets

Dans l’implantation courante, nous avons associé à chaque système étudié une structure

arborescente en forme de projet (myproject) :

• Le fichier myproject.ClassD contient la description du ClassD du système myproject.

� myproject � myproject.ClassD � StateDs � UIobjects � UseCases

178

C’est un fichier ASCII conforme à la grammaire décrite dans la section 1 de l’annexe

A.

• Le répertoire StateDs contient les Statecharts intégrés des objets du système (*.StateD).

• Le répertoire UIobjects contient les prototypes d’IU générés pour les objets d’interface.

À chaque objet d’interface correspond un répertoire portant son nom et dans lequel

Suip-sc met les programmes Java compatibles avec Visual Café décrivant le prototype

de l’IU.

• Le répertoire UseCases contient entre autres les descriptions textuelles des CollDs

décrivant les scénarios du système. Chaque CollD est représenté par un répertoire

portant le nom du scénario et dans lequel on trouve les fichiers *.CollD et les StateDs

partiels des objets participants dans le scénario.

Pour le système ATM (atmprj), la structure arborescente correspondante est la suivante:

B.2. Entrées de SUIP-SC

Les entrées du programme sont le ClassD du système à étudier et les CollDs décrivant les

scénarios du système. Avant d'exécuter le logiciel SUIP-SC, l’analyste devra donc créer le

fichier myproject.ClassD et le répertoire UseCases qui contient les différents CollDs du

système.

Un exemple de fichier ClassD (ATM.ClassD) tel qu’il devra être saisi par l'analyste est

179

donné ci-apres.

ATM cash_on_hand:boolean=TRUE screen:string="main" cash_slot:string="closed" card_slot:string="empty" insert_card(): string pre: ((cash_on_hand = TRUE) AND (screen = "main") AND (cash_slot = "closed") AND (card_slot = "empty")) post: ((cash_on_hand = TRUE) AND (screen = "enter_password") AND (cash_slot = "closed") AND (card_slot = "fill")) enter_password():string pre: ((cash_on_hand = TRUE) AND (screen = "enter_password") AND (cash_slot = "closed") AND (card_slot = "fill")) post: (((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill"))) enter_kind():char pre: ((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) post: (((cash_on_hand = TRUE) AND (screen = "deposit") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw") AND (cash_slot = "closed") AND (card_slot = "fill"))) enter_amount():char pre: (((cash_on_hand = TRUE) AND (screen = "deposit") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw") AND (cash_slot = "closed") AND (card_slot = "fill"))) post: (((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw_in_progress") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "fill"))) verify_cash_on_hand(mnt:float):boolean pre: ((cash_on_hand = TRUE) AND (screen = "withdraw_in_progress") AND (cash_slot = "closed") AND (card_slot = "fill")) post: (((cash_on_hand = TRUE) AND (screen = "take_cash") AND (cash_slot = "opened") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "ejected"))) get_cash() pre: ((cash_on_hand = TRUE) AND (screen = "take_cash") AND (cash_slot = "opened") AND (card_slot = "fill")) post: ((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected")) get_card() pre: ((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected")) post: ((cash_on_hand = TRUE) AND (screen = "main") AND (cash_slot = "closed") AND (card_slot = "empty")) display_error_message() pre: ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "fill"))

180

post: ((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected")) put_cash() pre: ((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill")) post: ((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected")) display_nip_error() pre: ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill")) post: ((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected")) Transaction date:string="" amount:float=0.0 kind:string="" create_transaction(pin:string, mnt:float, kind:string) pre: (amount = 0.0) post: (amount = 0.0) delete() pre: (date = "") post: (date = "") Account pin:string="" password:string="" balance:float=0.0 check_account(): boolean pre: ((pin = "") AND (password = "")) post: ((pin = "") AND (password = "")) check_balance(): boolean pre: ((pin = "pin") AND (password = "password")) post: ((pin = "pin") AND (password = "password")) update(mnt:float,kind:string) pre: ((pin = "pin2") AND (password = "password2")) post: ((pin = "pin2") AND (password = "password2")) User name:string=""

Un exemple de fichier CollD correspendant au scenario Identreg du système ATM est

donné ci-après :

frequency =10 *:ATM Account asynchronous_flow #1.2:ok:=check_account(pin, passwd) asynchronous_flow #1.6b:update(mnt, kind) Transaction

181

asynchronous_flow #1.6a:create_transaction(nip, mnt, kind) :User ATM asynchronous_flow #1:pin:=insert_card() {inputData(ATM.insert_card)} asynchronous_flow #1.1:passwd:=enter_password() {inputData(Transaction.date)} asynchronous_flow #1.3[(ok = TRUE)]:kind:=enter_kind() {inputData(Transaction.kind)} asynchronous_flow #1.4:mnt:=enter_amount() {inputData(Transaction.amount)} asynchronous_flow #1.5:put_cash() {inputData(ATM.put_cash)} asynchronous_flow #1.7:get_card() {inputData(ATM.get_card)} :Account :Transaction

B.3. Environnement d'exécution de SUIP-SC

L’environnement d'exécution de SUIP-SC devra comprendre:

Le langage Java version 1.1 avec lequel SUIP-SC a été développé

L’interface bulider Visual Café qui sert dans ce travail à visualiser et améliorer le

prototype de l’IU.

Une fois les entrées mises en place, l’analyste pourra lancer le programme SUIP-SC en

tapant la commande suivante:

java Suip-sc myproject [usecasename]

Cette commande (java Suip-sc) a deux paramètres: le premier (myproject) est obligatoire et

indique le nom du projet sur lequel on veut rouler SUIP-SC; le deuxième paramètre

([usecasename]) est optionnel et indique le nom d’un cas d’utilisation donné. En effet

SUIP-SC permet une génération incrémentale du prototype de l’IU. L’analyste peut

générer l’IU pour un cas d’utilisation particulier pour la valider avec l’utilisateur. Quand le

deuxième paramètre est omis, Suip-sc génère le prototype de l’IU pour les cas d’utilisation

du système.

182

B.4. Sorties de SUIP-SC

Dans le cas où SUIP-SC n’aurait pas détecté des incohérences dans les spécifications lors

de l’intégration des scénarios, il génère à la fois les prototypes des objets d’interface du

système (le répertoire UIobjects) et les spécifications intégrées de tous les objets du

système (le répertoire StateDs). Ces spécifications sont générées sous forme textuelle.

Le fichier suivant illustre le StateD intégré de l’objet GAB.

$ATM$ 6 * * * 1LSV ok:= scenarioList:={nipErrorDeposit,regularDeposit} dynamicScenarioList:=scenarioList transScenarioList:=[{nipErrorDeposit,regularDeposit};{nipErrorDeposit,regularDeposit};{nipErrorDeposit};{nipErrorDeposit,regularDeposit};{regularDeposit};{regularDeposit};{regularDeposit};{regularDeposit};{regularDeposit};{regularDeposit}] LSV1 1LSS $((cash_on_hand = TRUE) AND (screen = "main") AND (cash_slot = "closed") AND (card_slot = "empty"))$ 2 * * * $((cash_on_hand = TRUE) AND (screen = "enter_password") AND (cash_slot = "closed") AND (card_slot = "fill"))$ 2 * * * $(((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill")))$ 2 * * * $((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected"))$ 2 * * * $(((cash_on_hand = TRUE) AND (screen = "deposit") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw") AND (cash_slot = "closed") AND (card_slot = "fill")))$ 2 * * * $(((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw_in_progress") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "fill")))$ 2 * * * $SB2$ 4 * * * $MB0$ 5 * * * LSS1 1LT $((cash_on_hand = TRUE) AND (screen = "main") AND (cash_slot = "closed") AND (card_slot = "empty"))$ $((cash_on_hand = TRUE) AND (screen = "enter_password")

183

AND (cash_slot = "closed") AND (card_slot = "fill"))$ #BUT#insert_card()[((sc = TRUE) OR (sc = TRUE))]{/sa}{}^ pin $((cash_on_hand = TRUE) AND (screen = "enter_password") AND (cash_slot = "closed") AND (card_slot = "fill"))$ $(((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill")))$ #INP#enter_password()[((sc = TRUE) OR (sc = TRUE))]{/sa}{$3 ok:=Account.check_account(pin,passwd)}^ passwd $(((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill")))$ $((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected"))$ ()[((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill") AND (ok = FALSE) AND (sc = TRUE))]{/#LAB#display_nip_error()/sa}{} $((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected"))$ $((cash_on_hand = TRUE) AND (screen = "main") AND (cash_slot = "closed") AND (card_slot = "empty"))$ #BUT#get_card()[((sc = TRUE) OR (sc = TRUE))]{/sa}{} $(((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "incorrect_password") AND (cash_slot = "closed") AND (card_slot = "fill")))$ $(((cash_on_hand = TRUE) AND (screen = "deposit") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw") AND (cash_slot = "closed") AND (card_slot = "fill")))$ #INP#enter_kind()[((cash_on_hand = TRUE) AND (screen = "enter_kind") AND (cash_slot = "closed") AND (card_slot = "fill") AND (ok = TRUE) AND (sc = TRUE))]{/sa}{}^ kind $(((cash_on_hand = TRUE) AND (screen = "deposit") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw") AND (cash_slot = "closed") AND (card_slot = "fill")))$ $(((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw_in_progress") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "fill")))$ #INP#enter_amount()[(sc = TRUE)]{/sa}{}^ mnt $(((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "withdraw_in_progress") AND (cash_slot = "closed") AND (card_slot = "fill")) OR ((cash_on_hand = TRUE) AND (screen = "insuffisient_cash") AND (cash_slot = "closed") AND (card_slot = "fill")))$ $SB2$ #BUT#put_cash()[((cash_on_hand = TRUE) AND (screen = "deposit_in_progress") AND (cash_slot = "opened") AND (card_slot = "fill") AND (sc = TRUE))]{/sa}{} $SB2$ $MB0$ ()[(sc = TRUE)]{/sa}{$3 Transaction.create_transaction(nip,mnt,kind)} $SB2$ $MB0$ ()[(sc = TRUE)]{/sa}{$3 Account.update(mnt,kind)} $MB0$ $((cash_on_hand = TRUE) AND (screen = "take_card") AND (cash_slot = "closed") AND (card_slot = "ejected"))$ ()[(sc = TRUE)]{/sa}{} LT1

Les objets d’interface sont normalement identifiés par l’analyste lors de l’acquisition des

besoins. Ils sont marqués par une * dans les fichiers CollDs ; c’est le cas de l’objet GAB

dans le système ATM. SUIP-SC génère pour chaque objet d’interface un répertoire

184

contenant les fichiers Java décrivant le prototype de l’IU. Les fichiers générés pour l’objet

GAB sont :

Pour visualiser le prototype de l’IU dans l’environnement de Visual Café, l’analyste doit :

1. Créer un nouveau projet dans l’environnement de Visual Café

menu File � New project � Empty project

2. Insérer les fichiers générés pour l’objet d’interface dans le projet créé

menu Insert � Files into project

3. Exécuter le projet construit dans Visual Café. L’analyste pourra aussi raffiner les frames générées dans l’interface builder de Visual Café.

menu Project � Execute

185

Annexe C : SUIP version Réseaux de Petri (SUIP-PN)

Le logiciel SUIP-PN a été développé dans le but de valider l’approche SUIP-PN décrite

dans le chapitre 3. Il supporte les principales activités du processus d’ingénierie ; les étapes

d’acquisition des besoins et de transformation des descriptions de scénarios en

spécifications formelles sont laissées à la charge de l’analyste. SUIP-PN consiste en

l’utilisation d’un ensemble d’outils existants (designCPN, SXtool, XML4J et Visual Café)

intercalée par l’application de quelques algorithmes que nous avons développés en Java.

Tel que décrit dans le chapitre 3, après la construction des spécifications des scénarios,

l’analyste applique les opérations suivantes pour produire le prototype de l’interface usager

du système :

1. Utilisation de designCPN pour l’édition et la vérification des RdPCs décrivant les

scénarios du système, puis exportation de ces RdPCs sous le format SGML.

2. Utilisation de l’outil SXtool de Clarck [Cla99] pour transformer les fichiers SGML au

format XML.

3. Utilisation de l’outil XML4J (package Java) pour transformer les fichiers XML en

structures de données Java (structure d’arbre).

4. Application de l’algorithme d’intégration de scénarios sur les structures de données

générées à l’étape 3 et la production de spécifications intégrées sous le format XML.

5. Utilisation d’un script pour transformer les fichiers XML au format SGML de

designCPN.

6. Utilisation de designCPN pour lier les spécifications intégrées et produire la

spécification globale du système, et puis pour procéder à sa vérification.

186

7. Application de l’algorithme de génération du prototype de l’IU à partir des

spécifications intégrées.

Tous les algorithmes implantés ont un temps d’exécution polynomial au pire cas.

C.1. Structure en projets

Similairement à SUIP-SC, nous avons utilisé la notion de projet pour organiser les

entrées/sorties de SUIP-PN. À chaque système correspond un projet portant son nom

(myproject) et ayant la structure arborescente suivante:

• Le répertoire PN contient la spécification globale du système (myproject.cpn)

• Le répertoire UI contient le prototype de l’IU généré pour le système. Il contient un

ensemble de fichiers Java compatibles avec l’interface builder Visual Café et décrivant

les aspects statique et dynamique de l’IU objets d’interface.

• Le répertoire UseCases contient les cas d’utilisation du système. À chaque cas

d’utilisation correspond un sous-repertoire contenant une liste de fichiers décrivant ses

scénarios. Soit uc1 un cas d’utilisation, qui sera représenté par un sous-répertoire uc1

dans le répertoire UseCases. Soit (sc1, sc2, …, scn) la liste des scénarios de uc1. Pour

chaque scénario sci on trouve dans le répertoire uc1 les fichiers: sci.cpn (format

designCPN), sci.sgml, sci.rxml (format après l’application de SXtool) et sci.xml. Le

sous-répertoire uc1 contiendra aussi les fichiers uc1.xml (résultat de l’algorithme

d'intégration), uc1.sgml (obtenu après l’application du script Perl) et uc1.cpn

(designCPN) .

� myproject � PN � UI � UseCases

187

C.2. Entrées de SUIP-PN

Les entrées de SUIP-PN sont les RdPs du niveau cas d’utilisation et du niveau scénario.

L’analyste crée ces spécifications en utilisant designCPN et en sauvegardant les fichiers

correspondants dans le répertoire UseCases.

C.3. Environnement d'exécution de Suip-pn

L’environnement d'exécution de Suip-pn comprend:

1. Le langage Java version 1.1 avec lequel Suip-pn a été développé

2. L’outil designCPN dernière version (4.0)

3. L’outil SX tool de Clarck

4. Le package XML4J d’IBM

5. L’interface builder Visual Café qui sert dans ce travail pour visualiser et améliorer le

prototype de l’IU.

L’algorithme suivant décrit la séquence d'opérations à appliquer dans l'environnement

d'exécution de SUIP-PN:

UC_cpn=UC.Saisir()

// Saisir dans designCPN le RdP correspondant au niveau cas d’utilisation

For uc ∈ UC

For sc ∈ uc.ScenarioList() sc_cpn=sc.Saisir()

// Saisir dans designCPN le RdPC correspondant au scenario sc.

sc_sgml=sc_cpn.EnregistrerSgml()

sc_rxml=sc_sgml.SXtool()

// appliquer l’outil SX de J.Clarck pour générer le fichier

// sc_rxml.

sc_xml=sc_rxml.XJParse()

// transformer le fichier sc_xml en une structure Java (sc_java) à

travers l’utilisation du package XML4J.

sc_java=sc_xml.XML4J()

uc_java=uc_java.Integrer(sc_java)

// l’intégration incrémentale des différents scénarios du même cas

d’utilisation.

188

end

uc_xml=uc_java.EnregistrerXml()

// enregister sous le format xml la specification integree

uc_sgml=uc_xml.XMLtoSGML()

uc_cpn=uc.sgml.Load()

// charger la specification integree dans designCPN

uc_cpn.verifier()

// appliquer les algorithmes de verification de designCPN à la

specification integree.

UC_cpn=UC_cpn.Lier(uc_cpn)

// lier la spécification intégrée de uc avec le RdP du niveau cas

d’utilisation (UC_cpn)

end

UC_cpn.verifier()

// verifier dans designCPN les propriétés de la spécification globale du système

(UC_cpn).

• Les opérations Saisir(), EnregistrerSgml(), Load(), verifier() et lier() se font dans

l’environnement de designCPN.

• L'opération SXtool() consiste à appliquer l’outil de Clarck pour transformer le fichier

sc_sgml issu de designCPN en un format XML “brut” (non conforme avec XML4J).

Pour réaliser cette opération, l’analyste tape la commande suivante dans l'environnent

DOS ou Unix :

sx -E 0 sc.sgml > sc.rxml

• L'opération XJParse() permet de structurer le fichier généré par l’outil SX (sc_rxml) et

d’ajouter certains flags propres au package XML4J. La commande à taper pour réaliser

ce parsing est:

java samples.XJParse.XJParse -d sc.rxml > sc.xml

• L'opération XML4J() est une méthode du package XML4J. Elle permet de récupérer en

Java une structure d’arbre à partir d’un fichier XML. Cette opération et l'opération

d’intégration (Integrer()) sont appelées dans les programmes Java FixID.java et

Unify.java.

189

1. Le premier programme permet de s’assurer que les éléments des structures de

uc_java et sc_java ont des identificateurs uniques. L’ensemble des identificateurs

de uc_java et l’ensemble des identificateurs de sc_java doivent être disjoints. Le

programme cherche dans sc_java les IDs figurant aussi dans uc_java et les

modifie:

Java FixID -d uc_java sc_java > sc_java

2. Le deuxième programme effectue l'opération d'intégration:

Java Unify -d uc_java sc_java > uc_java

• L'opération XMLtoSGML() permet de transformer un fichier XML au format SGML pour

pouvoir le charger dans l’environnement de designCPN. Cette opération correspond à

un script Perl que l’analyste exécute selon la syntaxe suivante:

Perl fixcpn uc_xml > uc_sgml

C.4. Sorties de SUIP-PN

Les sorties de SUIP-PN sont le prototype de l’IU du système et la spécification globale du

système (UC_cpn). Tel que décrit précédemment, le prototype de l’IU est mis dans le

répertoire UI du projet, et la spécification globale est mise dans le répertoire PN du projet.

L’analyste utilise la même procédure que dans Suip-sc pour visualiser le prototype de l ‘IU

dans l’environnement de Visual Café.

Suip-pn produit également comme sortie les rapports de vérification des spécifications

avant et après intégration des scénarios. L’exemple ci-après montre le rapport de

vérification du CU Identification (figure 34) après l’intégration de ses deux scénarios

IdentReg et IdentErr.

Statistics ----------------------------------------- Occurrence Graph Nodes: 13 Arcs: 14 Secs: 0 Status: Full

190

Scc Graph Nodes: 1 Arcs: 0 Secs: 0 Boundedness Properties ----------------------------------------- Best Integers Bounds Upper Lower New'B 1 1 0 New'S10 1 1 0 New'S1 1 1 0 New'S11 1 1 0 New'S12 1 1 0 New'S2 1 1 0 New'S3 1 1 0 New'S4 1 1 0 New'S5 1 1 0 New'S6 1 1 0 New'S7 1 1 0 New'S8 1 1 0 New'S9 1 1 0 Best Upper Multi-set Bounds New'B 1 1`[rid,eid] New'S10 1 1`[eid] New'S1 1 1`[rid,eid] New'S11 1 1`[eid] New'S12 1 1`[eid] New'S2 1 1`[rid,eid] New'S3 1 1`[rid,eid] New'S4 1 1`[rid,eid] New'S5 1 1`[rid] New'S6 1 1`[rid] New'S7 1 1`[rid] New'S8 1 1`[rid] New'S9 1 1`[eid] Best Lower Multi-set Bounds New'B 1 empty New'S10 1 empty New'S1 1 empty New'S11 1 empty New'S12 1 empty New'S2 1 empty New'S3 1 empty New'S4 1 empty New'S5 1 empty New'S6 1 empty New'S7 1 empty New'S8 1 empty

191

New'S9 1 empty Home Properties ----------------------------------------- Home Markings: All Liveness Properties ----------------------------------------- Dead Markings: None Dead Transitions Instances: None Live Transitions Instances: All Fairness Properties ----------------------------------------- New'card_ok 1 Fair New'check 1 Impartial New'confirm 1 Fair New'connect 1 Impartial New'eject_card 1 Fair New'enter_pin 1 Impartial New'insert_card 1 Impartial New'invalid_card 1 Fair New'invalid_pin 1 Just New'pin_error 1 Fair New'pin_ok 1 Just New'r1 1 Fair New'r2 1 Fair New'select_op 1 Fair