Dans cette section nous présentons le langage de Modélisation UML. Ce langage a été utilisé pour créer des modèles de tests dans l’objectif de générer des cas de tests [Hui07].
Le langage de modélisation unifiée UML est défini comme étant un langage graphique de modélisation à base de pictogrammes utilisé pour visualiser la conception d’un tème. Il est largement utilisé durant le processus de conception et spécification des sys-tèmes. C’est le résultat de la fusion de trois langages de modélisation objet, à savoir Booch [Boo93], OOSE [Jac92] et OMT [RBP+90]. L’UML est devenu maintenant un standard adopté par le groupe de gestion objet OMG. La version 2.0 de UML est adoptée par l’OMG en 2005. En 2017, l’OMG a validé la dernière version de UML qui est le UML 2.5.1. Au cours des dernières années, le UML a réussi à s’imposer dans le domaine de modélisation objet et est devenu le standard le plus utilisé dans ce domaine.
On peut utiliser l’UML pour la spécification, la modification, la visualisation et la construc-tion de tous les documents nécessaires aboutissant à de meilleurs développements d’un logiciel orienté objet. Plusieurs éléments peuvent être modélisés en utilisant UML comme :
— Les activités des objets ou les activités dans le logiciel — Les utilisateurs du logiciel (Acteurs)
— Les processus
— Les schémas de base de données — Les différents composants logiciels — La réutilisation des composants
La version actuelle, UML 2.5, propose quatorze types de diagrammes. Ces diagrammes sont répartis en six diagrammes structurels et huit diagrammes comportementaux. Ces diagrammes sont complémentaires et sont hiérarchiquement dépendants.
2.6.1 Les diagrammes UML
Comme déjà présenté, les quatorze diagrammes proposés par l’UML sont groupés en deux catégories :
— Structurels ou Statiques
— Comportementaux ou Dynamiques
FIGURE2.14 – Les diagrammes UML
La catégorie « diagrammes structurels » comporte six diagrammes : — Diagramme de classes
— Diagramme d’objets
— Diagramme de composants — Diagramme de déploiement
— Diagramme de paquetages
— Diagramme de structures composites
La catégorie « diagrammes comportementaux » comporte huit diagrammes :
— Diagramme d’activité
— Diagramme des cas d’utilisation — Diagramme d’états-transitions
— Diagramme d’interaction
— Diagramme de séquences
— Diagramme global d’interaction
— Diagramme de communication
— Diagramme de temps
Dans ce travail, nous présentons uniquement le diagramme de cas d’utilisation et le diagramme de séquences.
2.6.1.1 Le diagramme de cas d’utilisation
Le diagramme de cas d’utilisation UML est utilisé pour montrer le comportement fonctionnel global d’un logiciel. Il permet de montrer les différents services offerts par le système et les interactions faites entre les utilisateurs et le système. Les utilisateurs, appe-lés les acteurs (utilisateurs humains ou machines), interagissent avec des unités discrètes dans le système qui s’appellent cas d’utilisation. Un acteur est représenté graphiquement en utilisant un pictogramme humanoïde ayant comme sous-titre le nom de l’acteur. Par contre, une simple ellipse contenant un nom est utilisée pour représenter un cas d’utili-sation. L’interaction entre un acteur et un cas d’utilisation est représentée graphiquement par une ligne. La figure2.15représente un exemple d’un diagramme de cas d’utilisation.
FIGURE2.15 – Diagramme de cas d’utilisation
On peut distinguer plusieurs rôles d’un acteur qui peut intervenir dans plusieurs si-tuations comme l’initiateur d’un cas, le rôle d’un serveur, récepteur d’information ou fa-cilitateur d’un autre acteur.
Plusieurs types de relations peuvent être définis entre deux cas d’utilisations ou entre deux acteurs. Les relations entre deux cas d’utilisation sont :
— Relation d’inclusion : On dit qu’un cas A inclut un cas B si le comportement décrit par A inclut le comportement du B. On dit que A dépend de B.
— Relation d’extension : On dit qu’un cas d’utilisation A étend un autre cas d’utilisa-tion B si A peut être appelé quand B est exécuté.
— Généralisation : Un cas d’utilisation A est une généralisation d’un cas d’utilisation B si B est un cas particulier de A.
Une seule relation peut être définies entre deux acteurs. C’est la relation de générali-sation. Un acteur A est une généralisation d’un acteur B si l’acteur B peut faire toutes les interactions que A fait en plus d’autres qui sont spécifiques à B.
2.6.1.2 Les diagrammes de séquences
Un diagramme de séquences est une représentation graphique des interactions entre les acteurs et les composants du système. Dans ce diagramme, l’ordre chronologique des interactions est montré. Le diagramme de séquences (cf.2.16) montre les interactions entre les objets dans un scénario décrit dans le diagramme de cas d’utilisation. Les acteurs principaux sont montrés à gauche du diagramme au contraire des acteurs secondaires qui prennent place à droite de la figure. Le temps est représenté dans ce diagramme par un trait (ou rectangle) vertical afin de visualiser l’enchaînement des messages, la naissance ou la disparition des objets. Les messages (ou actions) transitant entre les acteurs et les objets peuvent être de plusieurs types.
La dimension verticale du diagramme représente le temps, permettant de visualiser l’enchaînement des messages (actions) avec le temps, et de spécifier la naissance et la mort d’objets. Les périodes d’activité des objets sont symbolisées par des rectangles, et ces objets dialoguent à l’aide de messages.
Plusieurs types de messages (actions) peuvent transiter entre les acteurs et les objets.
— Message simple : Sans spécification particulière d’envoi et de réception.
— Message avec durée de vie : L’expéditeur du message attend une réponse du récep-teur. Si durant un certain délai de temps rien n’est reçu, l’expéditeur reprend ses activités.
— Message synchrone : L’expéditeur du message est bloqué jusqu’au la réception d’un signal indiquant la prise en compte du message par le destinataire.
— Message asynchrone : L’expéditeur envoie le message et continue son activité peu importe que le message soit pris en compte par le destinataire ou non.
— Message dérobant : Le message reçu par un destinataire est mis dans une file d’at-tente de traitement
Pour représenter des cas plus complexes, on peut utiliser ce qu’on appelle des frag-ments dans les diagrammes pour préciser des opérandes d’un ensemble de messages. Neufs fragments existent, à savoir :
FIGURE2.16 – Diagramme de séquences
— alt : Fragment multiple alternatifs qui est l’analogue du « si alors sinon »
— opt : Fragment optionnel l’analogue du « si »
— par : Fragment parallèle pour afficher les traitements concurrents
— loop : Fragment qui s’exécute plusieurs fois
— region : Section critique (un seul processus à la fois)
— neg : Une interaction non valable
— break : Représente des scénarios d’exception
— ref : Référence une interaction dans un autre diagramme
— sd : Fragment du diagramme de séquences en entier