Nous avons imaginé un outil d’édition de diagrammes UML destiné aux enseignants et aux étudiants. Dans le cadre d’un projet, il est fréquent que l’enseignant et l’étudiant exposent et confrontent leurs idées sur un diagramme UML, à l’aide d’un papier et d’un crayon. Ceci a pour inconvénient de les obliger à faire des photocopies en fin de travail, afin d’avoir chacun une version du document. Ils doivent, de plus, mettre au propre leurs brouillons en faisant une saisie sur un éditeur UML. Nous voulons montrer aux enseignants l’intérêt d’utiliser un outil implanté sur une tablette graphique. Les utilisateurs retrouveraient la facilité du papier ou du tableau sans ses inconvénients, tout en conservant les avantages de l’outil informatique.

$

L’application propose une interface permettant de dessiner des diagrammes de classes et de séquence. Ce logiciel dispose d’une reconnaissance de forme (pour les éléments graphiques) et d’une reconnaissance de l’écriture manuscrite.

Nous avons appelé cet outil UML Blackboard pour faire référence au tableau que l’on trouve dans les salles de classe et qui permet d’écrire, de dessiner, de faire des schémas, de travailler en collaboration enseignants / étudiants, de dispenser des cours, …

Utilisations du logiciel :

Présentation de cours :

Le professeur dispose d’une tablette graphique qu’il peut relier au vidéo projecteur de

la salle dans laquelle il présente son cours (via une connexion sans fil Wifi).

Grâce à sa tablette, il peut projeter son cours (sous forme de diapositives Powerpoint), et dessiner des diagrammes UML, en utilisant UML Blackboard, pour illustrer ses propos par des exemples concrets.

Travail collaboratif, travaux pratiques :

Le professeur et les étudiants disposent chacun d’une tablette graphique équipée du logiciel UML Blackboard. Toutes les tablettes sont reliées entre elles par un réseau sans fil. Etudiants et enseignants peuvent travailler en collaboration sur des diagrammes UML lors de séances de travaux pratiques ou de projet.

Travail mobile :

Une tablette graphique, équipée du logiciel UML Blackboard, permet d’emporter ses modèles UML n’importe où afin de pouvoir les exploiter à n’importe quel endroit : chez soi, chez un client, à l’école, dans une entreprise, pour une conférence, pour une présentation, etc.

1.1. Dessin d’un diagramme de classes

1.1.1. Présentation

L’interface de l’application est composée des éléments suivants :

Des onglets permettant de sélectionner le diagramme actif à l’intérieur du modèle ouvert : ici l’utilisateur a sélectionné le diagramme de classes « Téléphone » ;
Une zone (à gauche, en bleu clair) qui affiche les éléments du modèle : ici on peut voir que deux classes ‘Téléphone portable’ et ‘Téléphone fixe’ ont été définies dans le modèle, mais elles ne sont pas représentées graphiquement sur le diagramme courant ;
Une zone de dessin (vide pour l’instant) à l’intérieur de laquelle l’utilisateur va pouvoir dessiner des symboles UML ;
Une toolbar de symboles, en bas à droite de l’écran, qui permet d’effectuer des opérations :

Réduction / agrandissement (zoom) du diagramme courant ou des éléments sélectionnés sur celui-ci,
Recherche et affichage automatique des éléments associés (dépendances, héritages) à l’objet sélectionné,
Annulation de la dernière action (undo), permet notamment d’annuler la dernière reconnaissance de forme effectuée par le logiciel.

Figure 1 : interface de l’éditeur de diagramme de classes

1.1.2. Premier essai de dessin sur un diagramme de classes

Le diagramme de classes sélectionné dans le modèle est celui dont le nom apparaît dans le premier onglet.

Le logiciel est capable d’effectuer une reconnaissance de forme, cela signifie qu’il transforme les formes dessinées par l’utilisateur en symboles UML, en fonction du type de diagramme sur lequel celui-ci effectue son dessin.

Dans le cas suivant, le logiciel n’a pas reconnu la forme dessinée, il ne peut pas l’interpréter en symbole UML de diagramme de classes. Il affiche en conséquence un point d’interrogation pour signaler l’anomalie, il efface ensuite la forme et propose à l’utilisateur de recommencer son dessin. Dans tous les cas d’incompréhension, le point d’interrogation est affiché.

Figure 2 : premier essai de dessin sur un diagramme de classes

Figure 3 : échec de la reconnaissance de forme par le logiciel

1.1.3. Dessin de nouvelles classes sur le diagramme

Pour représenter une classe, l’utilisateur doit dessiner un carré ou un rectangle avec le stylet. Le logiciel analyse la forme et crée automatiquement une nouvelle classe (‘NewClass’) dans le modèle (cette classe apparaît dans la zone en bleu clair). Le logiciel remplace ensuite le dessin de l’utilisateur par une représentation graphique UML « propre » de la nouvelle classe dans le diagramme.

Figure 4 : dessin d’un carré dans un diagramme de classes

Figure 5 : reconnaissance du carré comme étant

une nouvelle classe dans le diagramme

Pour donner un nom à la classe créée, l’utilisateur doit pointer avec le stylet sur le compartiment graphique qui affiche le nom de celle-ci. Il écrit ensuite le nom de la classe dans la zone de saisie de texte qui apparaît. Il termine par un point, indiquant au logiciel, qu’il a fini d’écrire. L’écriture manuscrite est convertie automatiquement en texte et le nom de la classe apparaît au bon endroit, dans la représentation graphique de la classe et dans le modèle (zone de gauche en bleu clair).

Figure 6 : reconnaissance d’écriture et modification

du nom de la classe ‘NewClass’ en ‘Personne’

La même démarche est suivie pour créer une deuxième classe que l’on appelle ‘Téléphone’.

Figure 7 : dessin d’une deuxième classe dans le diagramme

Figure 8 : reconnaissance d’écriture et modification

du nom de la classe ‘NewClass’ en ‘Téléphone’

1.1.4. Dessin d’une association entre deux classes

L’utilisateur peut associer les deux classes précédemment créées. Pour cela, il dessine un trait entre ces deux classes, ce trait est automatiquement reconnu comme étant une association entre classes.

Figure 9 : dessin d’une association entre deux classes.

L’utilisateur peut définir les cardinalités de l’association en les écrivant :

Figure 10 : écriture des cardinalités de l’association

1.1.5. Définition d’attributs de classes

Pour définir un attribut dans une classe, l’utilisateur doit cliquer sur le compartiment qui affiche les attributs (situé en dessous du nom de la classe). Il écrit le nom de l’attribut ainsi que son type dans la zone de texte qui apparaît et termine par un point. Le nom de l’attribut est automatiquement reconnu.

Figure 11 : écriture d’un attribut ‘nom’ de type ‘String’ dans la classe ‘Personne’

Figure 12 : reconnaissance de l’attribut

1.1.6. Définition de méthodes de classes

Pour définir une méthode dans une classe, l’utilisateur doit cliquer dans le compartiment qui contient et affiche les méthodes de la classe. Il écrit ensuite le nom de la méthode dans la zone de texte qui apparaît et termine par un point.

Dans l’exemple suivant, on crée une méthode ‘décrocher( )’ dans la classe ‘Téléphone’.

Figure 13 : écriture d’un nom de méthode dans la classe ‘Téléphone’

Figure 14 : reconnaissance d’écriture d’un nom de méthode dans la classe ‘Téléphone’

De la même manière, on définit une deuxième méthode dans la classe ‘Téléphone’, la méthode ‘raccrocher( )’.

1.1.7. Dessin d’une hiérarchie de classes

A présent, l’utilisateur veut créer une représentation graphique de la classe ‘Téléphone portable’ dans le diagramme de classes courant. Cette classe existe déjà dans le modèle, elle a probablement été définie dans un autre diagramme de classes de ce modèle.

Pour cela, il sélectionne la classe en l’entourant puis écrit un ‘+’ dans le diagramme à l’endroit où il désire faire figurer cette classe.

Figure 15 : ajout d’une classe existante dans le diagramme de classe courant

L’étape suivante consiste à créer un lien d’héritage entre les classes ‘Téléphone portable’ et ‘Téléphone’. Pour cela, l’utilisateur dessine une flèche entre les deux classes. Cette flèche est interprétée sans ambiguïté comme une relation d’héritage par le logiciel.

Figure 16 : dessin d’une relation d’héritage entre classes

Figure 17 : reconnaissance d’une relation d’héritage entre classes

A présent, l’utilisateur va utiliser une autre méthode pour créer une représentation graphique de la classe ‘Téléphone fixe’ dans le diagramme de classes courant. Cette classe existe déjà dans le modèle.

Pour cela, il sélectionne la classe en l’entourant puis dessine une flèche vers l’endroit où il veut faire figurer cette classe (c’est l’équivalent d’un glisser/déplacer ou d’un copier/coller).

Figure 18 : ajout d’une classe existante

dans le diagramme de classe courant (2^ème méthode)

Figure 19 : reconnaissance de l’ajout de la classe dans le diagramme

L’étape suivante consiste à créer un lien d’héritage entre les classes ‘Téléphone fixe’ et ‘Téléphone’. Pour cela, l’utilisateur dessine une flèche entre les deux classes.

Figure 20 : reconnaissance d’une relation d’héritage entre classes

1.1.8. Définition de rôles pour les classes

Il est possible de définir des rôles pour les classes, rôles qui seront exploités dans les diagrammes de collaboration et de séquence.

Pour cela, l’utilisateur pointe avec le stylet sur le nom de la classe, la fenêtre de saisie de texte apparaît. L’exemple suivant montre la définition des rôles ‘/appelant’ et ‘/appelé’ sur la classe ‘Personne’. Le logiciel interprète sans ambiguïté cette saisie comme des rôles car ceux-ci sont préfixés du caractère ‘/’ qui, en notation UML, identifie un rôle. Les deux rôles sont séparés par une virgule et la phrase se termine par un point.

Figure 21 : définition de rôles pour la classe ‘Personne’

1.1.9. Suppression d’élements de modélisation

L’utilisateur a la possibilité d’effacer une classe, ou tout autre élément de modélisation, qu’il a défini par erreur. Pour cela, il procède de la même manière que sur du papier, c’est à dire il barre, il dessine une croix ou il rature, l’élément qu’il veut supprimer.

L’écran suivant montre comment supprimer une représentation graphique de la classe ‘NewClass’ dans le diagramme de classes courant, sans la supprimer du modèle où elle subsiste.

Figure 22 : suppression de la classe ‘NewClass’ du diagramme courant

L’écran suivant montre comment supprimer la classe ‘NewClass’ du modèle.

Figure 23 : suppression de la classe ‘NewClass’ du modèle

L’écran suivant montre que la classe ‘NewClass’ n’existe plus, ni dans le diagramme de classes courant, ni dans le modèle :

Figure 24 : aspect du diagramme de classes à la fin de la manipulation

1.2. Dessin d’un diagramme de séquence

1.2.1. Présentation

L’utilisateur a sélectionné le troisième onglet qui correspond au diagramme de séquence ‘Appel’. On veut modéliser une séquence d’appel téléphonique.

Ce diagramme est vide mais on dispose déjà des éléments du modèle qui ont été définis dans ses autres diagrammes (ils apparaissent sur la partie gauche dans la zone bleue).

Figure 25 : interface de l’éditeur de diagrammes de séquence

1.2.2. Instanciation d’objets sur le diagramme de séquence

Les objets représentés sur un diagramme de séquence sont des instances de classes ou des instances de rôles de classes.

Nous allons créer quatre objets. Le premier objet que nous voulons créer sur le diagramme correspond à une instance de la classe ‘Personne’ ayant un rôle d’appelant.

Pour réaliser cela, l’utilisateur entoure le rôle qu’il veut représenter et dessine ensuite une forme carré sur le diagramme. Sur un diagramme de séquence, un carré ou un rectangle sont transformés en objet (et non en classe comme c’est le cas sur un diagramme de classes).

Le logiciel crée un instance anonyme de la classe ‘Personne’ jouant le rôle d’appelant.

Figure 26 : création d’une instance de la classe ‘Personne’ jouant le rôle d’appelant

Ensuite, l’utilisateur veut créer un deuxième objet instance anonyme et sans rôle de la classe ‘Téléphone’. Il procède de la manière suivante en écrivant le nom de la classe à l’intérieur de l’objet :

Figure 27 : création d’une 2^ème instance anonyme, sans rôle,

et non encore associée à une classe

Figure 28 : l’objet est une instance anonyme, sans rôle, de la classe ‘Téléphone’

Création du 3^ème objet par instanciation de la classe ‘Téléphone’ (instance anonyme). Cette fois-ci, l’utilisateur entoure la classe qu’il veut instancier et dessine une flèche pur indiquer la position de l’objet à créer :

Figure 29 : création d’une 3ème instance anonyme, sans rôle, de la classe ‘Téléphone’

On utilise l’une de ces méthodes pour créer un 4^ème objet, instance de la classe ‘Personne’ et jouant le rôle d’appelé.

1.2.3. Dessin des echanges de messages entre objets

L’utilisateur veut modéliser un message envoyé par la personne appelante qui invoque l’opération ‘décrocher( )’ sur le téléphone de l’appelant. Il dessine un trait entre les deux premières instances des classes ‘Personne /appelant’ et ‘Téléphone’ représentées sur le diagramme de séquence.

Figure 30 : dessin d’un trait représentant l’envoi d’un message entre objets

Le logiciel transforme automatiquement le trait en un message anonyme :

Figure 31 : création d’un message anonyme entre deux objets

L’utilisateur veut associer le message à l’appel de la méthode ‘décrocher( )’. Pour cela, il écrit le nom de la méthode après avoir pointé le message à l’aide du stylet.

Le logiciel peut également afficher la liste des méthodes définies sur la classe destinataire du message, afin de permettre à l’utilisateur d’en sélectionner une.

Figure 32 : association d’une message avec une invocation de méthode

Figure 33 : association d’une message avec une invocation de méthode

L’utilisateur procède de la même manière pour dessiner un deuxième envoi de message entre les mêmes instances. Cette fois-ci la méthode invoquée ‘numéroter( )’ n’existe pas encore dans la classe destinataire. Elle va donc être rajoutée à la définition de cette classe dans le modèle, dans le diagramme courant ainsi que dans tous les diagrammes qui affichent cette classe.

Figure 34 : création d’un 2^ème message entre deux objets

1.2.4. Ecriture d’un nom d’objet

L’utilisateur veut donner un nom à la première instance de la classe ‘Téléphone’ et l’appeler ‘monTéléphone’. Il pointe l’objet avec le stylet afin de faire apparaître la fenêtre de reconnaissance d’écriture puis il écrit le nom qu’il veut donner à l’objet. Il procèderait de même pour changer le nom d’un objet.

Figure 35 : définition d’un nom pour un objet

Figure 36 : reconnaissance d’un nom pour un objet

1.2.5. Rédaction d’une note et association à un objet

En pointant sur le diagramme, en dehors de tout objet, le logiciel fait apparaître la fenêtre de reconnaissance d’écriture sans l’associer à un objet particulier. Le logiciel sait que ce qui va être saisi doit être considéré comme une note UML. L’utilisateur écrit sa note et termine sa phrase par un point.

Figure 37 : écriture d’une note non associée à un objet

A présent, l’utilisateur veut associer cette note « flottante » à un objet du diagramme. Pour cela, il trace un trait entre la note et l’objet cible. Le logiciel créée un lien entre la note et l’objet.

Figure 38 : dessin d’un lien entre la note créée et l’objet ‘monTéléphone’

Figure 39 : aspect du diagramme de séquence à la fin de la manipulation

2. Evaluation du prototype

Nous avons décidé de faire une évaluation guidée de la maquette, de type « magicien d’Oz », par deux professeurs, connaissant la notation et les outils UML : Mme Blay et Mme Michel. L’enseignant suit les indications qu’on lui donne avec le stylet. La personne qui fait la démonstration agit, avec la souris, de façon à faire croire à l’utilisateur que son action a été prise en compte automatiquement par le logiciel et on observe ses réactions.

2.1. Résultats de l’evaluation guidée

Les – de l’outil :

Il n’est pas possible, en dessinant la classe, d’écrire le nom de la classe directement dedans. Ceci crée un ralentissement dans l’action.

Commentaire du groupe : Dans un souci de distinguer la reconnaissance de formes de celle de l’écriture manuscrite, nous avons décidé de faire dessiner dans un premier temps la classe et ensuite de faire cliquer sur la classe pour faire apparaître une zone de texte, où l’utilisateur peut écrire le nom de la classe. Tout nom écrit ailleurs que dans cette zone de texte ne sera pas considéré comme un nom de classe. Il en est de même pour les noms des attributs et des méthodes. Ceci est lié à des contraintes techniques, l’outil doit pouvoir déterminer quand il doit effectuer de la reconnaissance de forme et quand il doit faire de la reconnaissance d’écriture.

Il manque une barre d’outil avec un bouton permettant d’annuler la dernière modification. Au cas où, l’utilisateur voudrait revenir en arrière, quand ce qui s’est passé n’est pas exactement ce qu’il voulait.

Commentaire du groupe : Cette remarque a été prise en compte dans la nouvelle version du prototype qui est présentée dans ce document, un bouton a été rajouté.

Pour récupérer une classe existante, dans la colonne de gauche, il serait intéressant d’entourer celle-ci et de la déplacer avec le stylet pour la mettre où l’on veut. Jusqu’à maintenant, l’utilisateur devait entourer la classe désirée et dessiner un ‘+’ là où il veut la placer.

Commentaire du groupe : Effectivement, on peut imaginer et proposer différents moyens pour réaliser une tâche. L’utilisateur aurait alors la possibilité de choisir le moyen qu’il préfère. En allant plus loin, le logiciel pourrait apprendre et mémoriser les comportements de chaque utilisateur de manière à s’adapter à chacun d’eux.

Lors de la définition d’une relation d’héritage, il est plus naturel de dessiner le trait et le triangle en même temps, plutôt que de tracer d’abord le trait, attendre qu’il soit reconnu par le logiciel et ensuite dessiner le triangle pour spécialiser la relation

Commentaire du groupe : C’est une remarque intéressante. Nous envisagerons éventuellement de mettre une temporisation pour que l’utilisateur ait le temps de dessiner directement la flèche et que celle-ci soit ensuite reconnue par le logiciel. Cette remarque a été prise en compte dans le prototype présenté dans ce document.

Les + de l’outil :

L’écriture à l’aide du stylet est naturelle, confortable et intuitive. L’utilisateur retrouve la facilité du papier sans ses inconvénients.
Lors de la suppression d’une classe, il est naturel de faire une croix sur sa classe, au niveau du diagramme et une croix sur son nom dans la colonne de gauche, présentant toutes les classes disponibles dans le modèle.
Lors de la définition des propriétés d’une classe, il est intéressant qu’il y ait une fenêtre qui s’ouvre pour écrire les attributs et les méthodes.
Le fait que l’interface soit homogène est important. A chaque fois que l’utilisateur veut nommer une classe, ses attributs et ses méthodes, il le fait toujours de la même façon.

3. Conclusion

Cette phase de test du prototype est intéressante, dans la mesure où elle nous permet de voir si le produit correspond aux attentes de l’utilisateur et s’il présente un bon compromis souplesse (i.e. le prochain but souhaité par l’utilisateur est directement atteignable naturellement) / robustesse (i.e. toute action non gérée par le logiciel est interdite).

Les remarques des utilisateurs permettent d’avoir un avis extérieur et critique sur les points positifs et négatifs de l’outil, d’avoir un autre angle de vision sur l’utilisation du produit présenté. Cela nous permet de l’améliorer et de proposer des perspectives d’évolutions.

Les perspectives d’évolution de la tablette :

Un des enseignants nous a proposé des perspectives d’évolution de la tablette.

Il serait intéressant de rajouter la possibilité de faire du brouillon sur la maquette, où la gestion de l’évolution du diagramme UML, qui au lieu d’être faite sur du papier, se fera directement sur la tablette.

Il serait intéressant que l’outil développé puisse être réutilisé. C’est à dire, l’utilisateur peut récupérer un élément d’un diagramme existant, le déplacer sur l’écran et voir tous les éléments qui lui sont associés. Il peut ainsi récupérer uniquement ce qui l’intéresse et l’intégrer dans son diagramme (notion de point de vue, proposer différents points de vues des modèles).

Dans le cadre d’un travail collaboratif, imaginons le cas où un enseignant explique un diagramme UML, à un étudiant. Au lieu de travailler avec un papier et un crayon, ils utilisent chacun leur tablette. Ils partagent le document. Ils peuvent l’annoter, faire des schémas, annuler une modification et le sauvegarder. Ainsi chacun a une version finale du document. Ce qui les évite de faire des photocopies. Des étudiants peuvent en faire de même, lors séances de travaux pratiques.