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