Table des matières
Le langage UML est un langage de modélisation utilisé dans plusieurs domaines y compris l’informatique précisément dans la POO (Programmation Orientée Objet). En tant que étudiant informaticien développeur il est primordial de maitriser ce langage pour mieux effectuer une approche concrète et claire des applications à développer. C’est dans cette logique que cette formation sur UML a été effectuée. La version étudiée dans ce document est UML 2.0.
Ainsi la réalisation de ce document a pour but de consolider, d’approfondir les différentes notions acquises lors de la formation. Pour mieux aborder la suite nous allons d’abord définir un certain nombre de concepts.
Définitions :
• POO (Programmation Orientée Objet) : La programmation orienté objet c’est pensé en terme d'ensemble d’objets reliés abstraits inter-opérant entre eux, pour en faire une application. Cette programmation a pour objectif de rendre utilisable les objets ou entités réutilisables, sans oublié la séparation des données et du traitement sur ces données. L
• UML (Unified Modeling Language) : C’est un langage de modélisation graphique qui permet de représenter et de communiquer les divers aspects d’un système d’information.
Aux graphiques sont bien sûr associés des textes qui expliquent leur contenu. Donc c’est un métalangage car il fournit les éléments permettant de construire le modèle qui, lui, sera le langage de l’application.
Ce langage est dans sa version UML 2.0 qui comporte 13 diagrammes par rapport à la version UML 1.0 qui ne compte que 9 diagrammes.
Les treize diagrammes d’UML 2.0 sont :
Ø Diagramme d’activité
Ø Diagramme de classes
Ø Diagramme de cas d’utilisation
Ø Diagramme de communication
Ø Diagramme de composants
Ø Diagramme de déploiement
Ø Diagramme d’états-transitions
Ø Diagramme global d’interaction
Ø Diagramme d’objets
Ø Diagramme des packages
Ø Diagramme de temps
Ø Diagramme de structure composite
Ø Diagramme de séquence
Tous ces diagrammes ne sont pas utilisé en même temps lors d’une modélisation puisque chaque diagramme à un rôle bien spécifique et selon le besoin.
D’ailleurs nous allons étudier que trois parmi ces quatre diagrammes, qui sont :
Ø Diagramme de cas d’utilisation
Ø Diagramme de séquence
Ø Diagramme d’état-transition
Ø Diagramme de classes
Ces diagrammes seront détaillés dans les chapitres qui suivent.
Le diagramme de cas d’utilisation comme sont nom l’indique présente les différents cas d’utilisation, c’à dire les fonctionnalités de l’application ou du système nécessaires aux utilisateurs.
C’est le premier diagramme du modèle UML, celui où s’assure la relation entre l’utilisateur et les objets que le système ou l’application met en œuvre.
L’élaboration de celui-ci nécessite des entretiens avec les utilisateurs.
Les objectifs de ce diagramme sont tout à fait évidents :
ü Présenter de manière claire et simple le cahier de charge d’un système
ü Recueillir, analyser et organiser les besoins d’un système
ü Répertorier les comportements d’un système
ü Découper de manière simple les fonctionnalités d’un système.
Ce diagramme comporte plusieurs éléments qui sont :
Un acteur est l’idéalisation d’un rôle joué par une personne, un système externe ou un dispositif matériel qui interagit avec le système. Ainsi nous avons des acteurs principaux qui sont les principaux utilisateurs, et des acteurs secondaires ce qui par exemple ferons marcher le système exemple l’administrateur etc. Le statu d’un acteur va dépendre des fonctionnalités du système utilisés par celui-ci.
Il se représente par un petit bonhomme (figure 1) avec son nom (exemple son rôle) inscrit en dessous.
Client
Figure 1 : Exemple de représentation d’un acteur
Il est également possible de représenter un acteur sous la forme d’un classeur (figure 2) stéréotypé.
<<acteur>>
Client
Figure 2 : Exemple de représentation d’un acteur sous forme de classeur
Le stéréotype : Un stéréotype est une annotation s’appliquant sur un élément de modèle, exemple le stéréotype <<acteur>> au niveau du classeur .Précisons que le stéréotype n’est pas propre au diagramme de cas d’utilisation mais est une annotation générale utilisable dans tous les diagrammes UML.
Un cas d’utilisation est une unité représentant une fonctionnalité visible de l’extérieur, réalisant un service de bout en bout, avec un déclenchement, un déroulement et une fin, pour l’acteur qui l’initie. Un cas d’utilisation modélise donc un service rendu par le système, sans imposer le mode de réalisation de ce service. Il est représenté par une ellipse (figure 3) contenant le nom du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un stéréotype.
Figure 3 : Exemple de représentation d’un cas d’utilisation
Figure 4: Diagramme de cas d’utilisation modélisant une borne d’accès à une banque.
Comme le montre la figure 4, la frontière du système est représentée par un cadre. Le nom du système figure à l’intérieur du cadre, en haut. Les acteurs sont à l’extérieur et les cas d’utilisation à l’intérieur.
Figure 5: Exemple de relation entre cas d’utilisation et les acteurs.
Acteurs principaux et secondaires:
Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à cet acteur.
Les autres acteurs sont alors qualifiés de secondaires. Un cas d’utilisation a au plus un acteur principal. Un acteur principal obtient un résultat observable du système tandis qu’un acteur secondaire est sollicité pour des informations complémentaires.
En général, l’acteur principal initie le cas d’utilisation par ses sollicitations. Le stéréotype << primary >> vient orner l’association reliant un cas d’utilisation à son acteur principal, le stéréotype << secondary >> est utilisé pour les acteurs secondaires.
Cas d’utilisation interne:
Lorsqu’un cas d’utilisation n’est relié à aucun acteur, c’est cas d’utilisation interne.
Types et représentations
Figure 6 : Exemple de diagramme avec des relations entre les cas d’utilisations
Il existe principalement deux types de relations :
? les dépendances stéréotypées, qui sont explicitées par un stéréotype (les plus utilisés sont l’inclusion et l’extension), ? et la généralisation/spécialisation.
Une dépendance se représente par une flèche avec un trait pointillé (figure 6). Si le cas A inclut ou étend le cas B, la flèche est dirigée de A vers B.
Le symbole utilisé pour la généralisation est une flèche avec un trait plein dont la pointe est un triangle fermé désignant le cas le plus général (figure 6).
Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas d’utilisation qui serait commune à d’autres cas d’utilisation (voir le cas S’authentifier de la figure 6).
La relation d’extension est probablement la plus utile car elle a une sémantique qui a un sens du point de vue métier au contraire des deux autres qui sont plus des artifices d’informaticiens.
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> (figure 6).
L’extension peut intervenir à un point précis du cas étendu. Ce point s’appelle le point d’extension. Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique point d’extension, et est éventuellement associé à une contrainte indiquant le moment où l’extension intervient. Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d’une note. La figure 6 présente l’exemple d’une banque où la vérification du solde du compte n’intervient que si la demande de retrait dépasse 20 euros.
Un cas A est une généralisation d’un cas B si B est un cas particulier de A. Dans la figure 6, la consultation d’un compte via Internet est un cas particulier de la consultation. Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.
Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait plein dont la pointe est un triangle fermé désignant l’acteur le plus général (on a déjà vu ça avec les relations entre cas d’utilisation).
Par exemple, la figure 7 montre que le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut gérer le stock. Par contre, le préposé aux commandes ne peut pas gérer le stock.
Figure 7 : Exemple de relation de généralisation entre les acteurs
Nous allons mettre en pratique les différentes notions acquises concernant les diagrammes de cas d’utilisation, dans l’étude de cas suivant :
Etude de cas 1 : Un site e-commerce
Le commerce électronique dans cette étude de cas, concerne le processus d’achat/vente de livres sur Internet. La société BookStore est spécialisée dans la vente de livres de tout type (science, littérature, Art, etc…) et sur tout support (livre papier, numérique, DVD, etc..). BookStore reçoit ses commandes par fax et les chèques par courrier puis envoie le bon de commande au client. Une fois le chèque encaissé par la banque partenaire BookBank, elle utilise la société de transport BookEx pour acheminer les livres vers leurs clients. La société BookStore possède un système « Gestion des stocks » qui met à jour les données concernant le prix et l’état du stock des livres du catalogue. Ce système est automatiquement chargé dans la base de données de façon périodique.
Après l’analyse effectuée nous avons tiré le diagramme de cas d’utilisation.
Celui-ci présente les différents éléments suivant suivant :
Les cas d’utilisation :
Ø S’inscrire
Ø S’authentifier
Ø Rechercher des ouvrages
Ø Gérer le panier
Ø Commander le livre
Ø Payer
Ø Gérer les clients
Ø Maintenance catalogue
Ø Maintenance du site
Les Acteurs :
Principaux acteurs sont : Visiteur, Internaute, Client.
Acteurs secondaire : Administrateur du site, Système de gestion de stock, BookBank.
Figure 8 : Diagramme de cas d’utilisation
Le diagramme de séquence représente la succession chronologique des opérations réalisées par un acteur. Il indique les objets que l’acteur va manipuler et les opérations qui font passer d’un objet à l’autre.
Elle a comme objectifs de présenter :
ü les objets manipulés par les acteurs
ü la durée de vie d’un objet
ü ordre chronologique d’enchainement des objets d’un système ü les opérations effectuées sur les objets par les acteurs
Une ligne de vie se représente par un rectangle, auquel est accrochée une ligne verticale pointillée, contenant une étiquette dont la syntaxe est :
[<nom_du_rôle>] : [<Nom_du_type>]
Au moins un des deux noms doit être spécifié dans l’étiquette, les deux points (:) sont, quand à eux, obligatoire.
Un message définit une communication particulière entre des lignes de vie. Plusieurs types de messages existent, les plus communs sont :
• l’envoi d’un signal
• l’invocation d’une opération
• la création ou la destruction d’une instance.
Graphiquement, un message asynchrone se représente par une flèche en traits pleins et à l’extrémité ouverte partant de la ligne de vie d’un objet expéditeur et allant vers celle de l’objet cible (figure 9).
Figure 10: Représentation d’un message synchrone
Graphiquement, un message synchrone se représente par une flèche en traits pleins et à l’extrémité pleine partant de la ligne de vie d’un objet expéditeur et allant vers celle de l’objet cible (figure10). Ce message peut être suivi d’une réponse qui se représente par une flèche en pointillé (figure 10).
Figure 11: Représentation d’un message de création et destruction d’instance.
La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de vie (figure 11).
La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de l’objet (figure 11). La destruction d’un objet n’est pas nécessairement consécutive à la réception d’un message.
Figure 12: Les différents évènements correspondant à un message asynchrone.
UML permet de séparer clairement l’envoi du message, sa réception, ainsi que le début de l’exécution de la réaction et sa fin (figure 12).
Figure 13: Syntaxe des messages et des réponses.
Dans la plupart des cas, la réception d’un message est suivie de l’exécution d’une méthode d’une classe. Cette méthode peut recevoir des arguments et la syntaxe des messages permet de transmettre ces arguments.
La syntaxe de réponse à un message est la suivante :
[<attribut> = ] message [ : <valeur_de_retour>] où message représente le message d’envoi.
La figure 13 montre un exemple d’exécution d’une méthode avec une réponse.
Un message complet est tel que les événements d’envoi et de réception sont connus. Un message perdu est tel que l’événement d’envoi est connu, mais pas l’événement de réception. Il se représente par une flèche qui pointe sur une petite boule noire (figure 14).
Un message trouvé est tel que l’événement de réception est connu, mais pas l’événement d’émission. Une flèche partant d’une petite boule noire représente un message trouvé (figure 14).
Un fragment combiné représente des articulations d’interactions. Il est défini par un opérateur et des opérandes. L’opérateur défini la signification du fragment combiné. Il existe 12 d’opérateurs définis dans la notation UML 2.0.
Il est représenté dans un rectangle dont le coin supérieur gauche contient un pentagone. Dans le pentagone figure le type de la combinaison, appelé opérateur d’interaction. Les opérandes d’un opérateur d’interaction sont séparés par une ligne pointillée. Les conditions de choix des opérandes sont données par des expressions booléennes entre crochets ([ ]).
La liste suivante regroupe les opérateurs d’interaction par fonctions :
• les opérateurs de choix et de boucle : alternative, option, break et loop ;
• les opérateurs contrôlant l’envoi en parallèle de messages : parallel et critical region ;
• les opérateurs contrôlant l’envoi de messages : ignore, consider, assertion et negative ;
• les opérateurs fixant l’ordre d’envoi des messages : weak sequencing , strict sequencing.
Nous allons présenter que celle vue lors de cette formation.
Figure 15: Représentation d’un choix dans un diagramme de séquence illustrant le découvrement d’une case au jeu du démineur.
L’opérateur option, ou opt, comporte une opérande et une condition de garde associée. Le sous-fragment s’exécute si la condition de garde est vraie et ne s’exécute pas dans le cas contraire.
Un fragment combiné de type loop possède un sous-fragment et spécifie un compte minimum et maximum (boucle) ainsi qu’une condition de garde.
La syntaxe de la boucle est la suivante :
loop[ '('<minInt> [ ',' <maxInt> ] ')' ]
La condition de garde est placée entre crochets sur la ligne de vie. La boucle est répétée au moins minInt fois avant qu’une éventuelle condition de garde booléenne ne soit testée. Tant que la condition est vraie, la boucle continue, au plus maxInt fois. Cette syntaxe peut être remplacée par une indication intelligible comme sur la figure 15.
Il est possible de faire référence à un autre diagramme de séquence, dans la définition d’un autre diagramme de séquence.
Graphiquement, une utilisation apparaît dans un diagramme de séquence sous forme de rectangle avec le tag ref (pour référence). On place dans le rectangle le nom du diagramme référencée (figure 16).
Figure 16: Représentation de l’appel d’un diagramme de séquence dans un autre
Nous allons donner des exemples de diagramme de séquence, pour l’étude de cas
1 du chapitre 1.
Ainsi chaque diagramme de séquence est lié à un cas d’utilisation du diagramme de cas d’utilisation.
Voici quelques principaux diagrammes de séquence:
Figure 17: Diagramme de sequence du cas S’inscrire
Figure 18: Diagramme de séquence du cas S’authentifier
Figure 19: Diagramme de séquence du cas gérer panier
Figure 20: Diagramme de séquence du cas rechercher ouvrage
Figure 21: Diagramme de séquence du cas payer ouvrage
ü Décrire les changements d'états d'un objet ou d'un composant
ü Séquences d’actions et états traités par une instance
ü Une vision complète et non ambiguë de l’ensemble descomportements du système
• Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des attributs d'un objet.
• Une transition représente le passage instantané d'un état vers un autre.
• Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui conditionne la transition.
• Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui la déclenche.
Etat simple :
Etat initial :
Etat final :
Figure 22:Exemple diagramme d’état-transition
Il permet de fournir une représentation abstraite des objets du système qui vont interagir ensemble pour réaliser les cas d’utilisation.
Le diagramme de classes est considéré comme le plus important de la modélisation orientée objet, il est le seul obligatoire lors d’une telle modélisation.
ü Modéliser les concepts du domaine d’application
ü Identifier la structure des classes du système
ü Identifier les propriétés, et les méthodes de chaque
ü Représenter les relations entre les classes
Les éléments de ce diagramme sont les classes et les relations entre ces classes.
Une classe est la description formelle d’un ensemble d’objets ayant une sémantique et des caractéristiques communes.
Les classes sont les modules de base de la programmation orientée objet.
La section supérieure est le nom de la classe.
La section centrale définit les propriétés de la classe.
La section du bas énumère les méthodes de la classe.
Figure 23: Exemple de classe
Association :
Une association est une relation générique entre deux classes. Elle est modélisée par une ligne (figure) reliant les deux classes. Cette ligne peut être qualifiée avec le type de relation, et peut également comporter des règles de multiplicité (par exemple un à un, un à plusieurs, plusieurs à plusieurs) pour la relation.
| Personne | 0..* | Adresses | |
| 1 |
Figure 24: Exemple d’association
Si une classe ne peut pas exister par elle-même, mais doit être un membre d'une autre
classe, alors elle possède une relation de composition avec la classe contenant. Une relation de composition est indiquée par une ligne avec un "losange" (figure) rempli.
Figure 25: Exemple de relation de composition
Les agrégations indiquent une relation de contenant-contenu. Elle décrite par une relation "possède".
Une relation d'agrégation est représentée par une ligne avec un "losange" creux.
Figure 26: Exemple de relation d’agrégation
Une relation de généralisation est l'équivalent d'une relation d'héritage en terme orientés objet (relation "est-un "). Une relation de généralisation est indiquée par une flèche creuse se dirigeant vers la classe "Parent ".
Figure 27: Exemple de relation de généralisation (héritage)
paramètre d'une de ces fonctions, elle "dépend" ainsi de cette classe. Une relation de dépendance est représentée par une flèche pointillée.
Figure 28: Exemple de relation de dépendance
Par exemple, le diagramme de la figure montre que la classe Confrontation utilise la classe Stratégie car la classe Confrontation possède une méthode confronter dont deux paramètre sont du type Stratégie. Si la classe Stratégie, notamment son interface, change, alors des modifications devront également être apportées à la classe Confrontation.
Nous allons donner le diagramme de classe, pour l’étude de cas 1 du chapitre 1.
Les différentes méthodes n’on pas été présenter dans ce diagramme pour éviter de surcharger celui-ci.
Figure 29: Diagramme de class
Cette étude nous a permis de se familiariser et s'initier au langage UML. Ainsi nous avons acquis différentes notions concernant les diagrammes de cas d’utilisation, de séquence, d’état-transition et de classe. Personnellement cette étude m’a été bénéfique et pour une bonne maitrise des différentes notions acquises, il est nécessaire de faire beaucoup d’étude de cas pratique. Cette étude a suscité en moi une curiosité d’aller comprendre les autres diagrammes que nous n’avons pas abordé à augmenté. En somme ce langage propose plusieurs types de diagramme qui ne sont pas tous utilisé lors de la conception d’une application. Ce qui nous oblige à bien choisir le type de diagramme qui va mieux expliquer notre application.
