UML : un modèle d’interaction pour les systèmes de réalité augmentée

Les modèles d’Interaction Homme-Machine (IHM) sont principalement de deux sortes : les modèles d’interaction et les modèles d’architecture logicielles.

Les modèles d’interaction en IHM sont nombreux (chapitre II). Ils assument plus ou moins explicitement l’utilisation des périphériques classiques de type WIMP (Windows, Icon, Menus and Pointing devices). Dés que l’on considère des interfaces d’une autre nature comme pour celles des systèmes de RA, ces modèles montrent leur limitation à décrire complètement l’interface car certaines parties ne sont pas prises en compte tel que tous les aspects liés aux objets et outils réels.

Les modèles ASUR et IRVO sont deux modèles conçus pour des systèmes de RA. Cependant, ces modèles présentent des limites et ce sont ces limitations qui nous ont poussé à proposer un modèle basé sur les notations UML. En effet, UML est désormais un standard dans le domaine de la conception logicielle des systèmes interactifs. De plus, le développement d’un système de RA nécessite l’étude de l’interaction mais aussi celle des fonctionnalités qui seront proposées par le système.

Pour établir une configuration logicielle de la plate-forme ARMIA nous avons utilisé deux types de diagrammes qui nous semblent les plus adéquats, les plus représentatifs et qui répondent bien au différentes contraintes. A cet effet, nous avons opté pour le diagramme des classes et le diagramme des composants.

III.3.1.1 Diagramme de classes

Le diagramme de classes exprime la structure statique du système. L’intérêt du diagramme de classes est de modéliser les entités du système d’information. Dans ce cas, les informations sont structurées, c’est-à-dire qu’elles sont regroupées dans des classes. Le diagramme met en évidence d’éventuelles relations entre ces classes.

Le diagramme de classes comporte 6 concepts : - classe - attribut - identifiant - relation - opération - généralisation / spécialisation.

III.3.1.2 Notions utilisés dans le diagramme des classes a. Notion de classe

Une classe est une description abstraite (condensée) d’un ensemble d’objets du domaine de l’application : elle définit leur structure, leur comportement et leurs relations.

Les classes sont représentées par des rectangles compartimentés (exemple ci-dessous):

- le 1er compartiment représente le nom de la classe

- le 2ème compartiment représente les attributs de la classe - le 3ème compartiment représente les opérations de la classe

b. Notion de relation

S’il existe des liens entre objets, cela se traduit nécessairement par des relations qui existent entre leurs classes respectives. Les liens entre les objets doivent être considérés comme des instances de relations entre classes.

Il existe plusieurs types de relations entre classes : - l’association

- la généralisation/spécialisation

Une association est une relation entre deux classes (association binaire) ou plus (association n-aire), qui décrit les connexions structurelle entre leurs instances. Une association n-aire possède n rôles qui sont les points terminaux de l’association ou terminaisons (Figure 3.4.).

Personne Entreprise

1

1..* 1

1..*

Figure 3. 4. Exemple d’une association binaire

c. Multiplicité ou cardinalité

La multiplicité associée à une terminaison d’association, d’agrégation ou de composition déclare le nombre d’objets susceptibles d’occuper la position définie par la terminaison d’association. Voici quelques exemples de multiplicité : Un et un seul : 1 Zéro ou un : 0..1 De M à N (entiers naturels) : M..N De zéro à plusieurs : 0..* De 1 à plusieurs : 1..* d. Agrégation

Dans UML, l’agrégation n’est pas un type de relation mais une variante de l’association. Une agrégation représente une association non symétrique dans laquelle une des extrémités joue un rôle prédominant par rapport à l’autre extrémité. NOM CLASSE Attribut_1 : int Attribut_2 : int Attribut_3 : int Operation_1 () :void Operation_2 () :void

Une agrégation est une association qui représente une relation d’inclusion structurelle ou comportementale d’un élément dans un ensemble. Graphiquement, on ajoute un losange vide du côté de l’agrégat (Figure 3.5). Contrairement à une association simple, l’agrégation est transitive. L’exemple de la figure 3.5 montre que l’on veut gérer une classification de véhicules. Chaque véhicule est classifié selon son type.

Type Vehicule

0..*

1..1 0..*

1..1

Figure 3. 5. Exemple de relation d’agrégation

III.3.1.3 Diagramme des composants

Un composant est un élément physique qui représente une partie implémentée d’un système. Il peut être du code (source, binaire ou exécutable), un script, un fichier de commandes, un fichier de données, une table, etc. Il peut réaliser un ensemble d’interfaces qui définissent alors le comportement offert à d’autres composants.

En outre, chaque composant peut posséder des attributs et des opérations. Un composant est éventuellement connecté à d’autres (via des dépendances ou des compositions).

Dans un cas général, un composant est représenté par un rectangle principal avec sur son côté gauche deux petits rectangles. Le nom du composant est placé dans le rectangle principal (Figure 3.6).

contexte

Figure 3. 6. Représentation d’un composant

Un composant est défini comme une sous-classe de Classificateur. Il peut ainsi avoir des attributs, des opérations et participer à des relations (association, généralisation, dépendance).

UML définit 5 stéréotypes aux composants : - « « document » » : un document quelconque ;

- « « exécutable » » : un programme qui peut s’exécuter ;

- « « fichier » » : un document contenant un code source ou des données ; - « « bibliothèque » » : une bibliothèque statique ou dynamique ;

- « « table » » : une table de base de données relationnelle.

La communication inter-composants

Les divers composants d’un système doivent être sujet à composition avec d’autres composants. Ceci se fait par le biais d’un mécanisme de communication. Les liens qui peuvent exister entre les composants

s’appellent alors connections. Suivant le système de composants, nous pouvons avoir plusieurs types de liens. A titre d’exemple, nous citons

– Les appels de procédure, – Les évènements,

– Les flux de données.

Nous avons exposé précédemment deux types de diagrammes pour établir une représentation logicielle de notre plate-forme.