Département d’Informatique
Réalisé par :WARME Moumouni
Etudiant en Master I
Filière : Master Qualité Logiciel Année Universitaire 2010-2011
Document sur la formation
Du langage UML
Table des matières
Introduction ... 4
Chapitre 1 : Le diagramme de cas d’utilisation ... 5
1. Définition : ... 5
2. Les objectifs : ... 5
3. Les éléments du diagramme de cas d’utilisation ... 6
a. Acteur ... 6
b. Cas d’utilisation ... 6
c. Représentation d’un diagramme de cas d’utilisation ... 7
4. Relations dans les diagrammes de cas d’utilisation ... 7
a. Relations entre acteurs et cas d’utilisation ... 7
b. Relations entre cas d’utilisations ... 8
c. Relations entre acteurs ... 10
5. Exemple d’application ... 11
Chapitre 2 : Le diagramme de séquence ... 13
1. Définition : ... 13
2. Les objectifs : ... 13
3. Les éléments du diagramme de séquences ... 13
a. Représentation des lignes de vie ... 13
b. Représentation des messages ... 13
c. Fragments d’interaction combinés ... 16
d. Utilisation d’interaction (interaction use) ... 18
4. Exemple d’application ... 19
Chapitre 3: Le diagramme d’état-transition ... 22
1. Définition : ... 22
2. Les objectifs : ... 22
1. Définitions : ... 22
2. Représentation: ... 22
Chapitre 4: Le diagramme de classes ... 24
1. Définition ... 24
2. Les objectifs : ... 24
3. Les éléments du diagramme de classe ... 24
a. Les Classes ... 24
b. Les Relations ... 25
4. Exemple d’application ... 26
Introduction
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èmed’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.
Chapitre 1 : Le diagramme de cas d’utilisation
1. Définition :
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.
2. Les objectifs :
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
3. Les éléments du diagramme de cas d’utilisation
Ce diagramme comporte plusieurs éléments qui sont :a. Acteur
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.
Cl i ent
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é.
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.
b. Cas d’utilisation
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 <<acteur>>
Client
<<Stéréotype>> Nom du cas
c. Représentation d’un diagramme de 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.
4. Relations dans les diagrammes de cas d’utilisation
a. Relations entre acteurs et cas d’utilisationRelation d’association : c’est un chemin de communication entre un acteur et un cas
d’utilisation qui est représenté par un trait continu (figure 5).
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. b. Relations entre cas d’utilisations
Types et représentations
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).
Relation d’inclusion
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B : le cas A dépend de B. Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A. Cette dépendance est symbolisée par le stéréotype << include >> (figure 6). Par exemple, l’accès aux informations d’un compte bancaire inclut
nécessairement une phase d’authentification avec un identifiant et un mot de passe (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).
Relation d’extension
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.
Relation de généralisation
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.
c. Relations entre acteurs
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une généralisation d’un acteur B (spécialisation) si l’acteur A peut être substitué par l’acteur B. Dans ce cas, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai. Ceci ressemble au concept d’héritage en POO.
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.
5. Exemple d’application
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.
Actuellement, La société BookStore souhaite réaliser un site e-commerce pour gérer seulement la vente de ses livres en ligne, gérer son catalogue de livre et sa base de données de clients. L’objectif fondamental du futur site BookStore est de permettre aux internautes de rechercher des ouvrages par thème, auteur, mot-clé, etc., de se constituer un panier virtuel, puis de pouvoir les commander et les payer directement sur le Web.
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.
Chapitre 2 : Le diagramme de séquence
1. Définition :
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.
2. Les objectifs :
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
3. Les éléments du diagramme de séquences
a. Représentation des lignes de vieUne 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.
b. Représentation des messages
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
Messages asynchrones
Figure 9: Représentation d’un message asynchrone
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).
Messages synchrones
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).
Messages de création et destruction d’instance
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.
Événements et messages
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).
Syntaxe des messages et des réponses
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.
Message perdu et trouvé
Figure 14: Représentation d’un message perdu et d’un message trouvé.
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).
c. Fragments d’interaction combinés
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.
Opérateur alt
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 alternative, ou alt, est un opérateur conditionnel possédant plusieurs opérandes (figure 15). C’est un peu l’équivalent d’une exécution à choix multiple.
Opérateurs opt
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.
Opérateur loop
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 :
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.
d. Utilisation d’interaction (interaction use)
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).
4. Exemple d’application
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:
Chapitre 3: Le diagramme d’état-transition
1. Définition :
Un diagramme d’états-transitions est un graphe qui représente un automate à
états finis, c’est-à-dire une machine dont le comportement des sorties ne dépend
pas seulement de l’état de ses entrées, mais aussi d’un historique des sollicitations passées.
2. Les objectifs :
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
3. Les éléments du diagramme de séquences
1. Définitions : 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. 2. Représentation: Etat simple : Etat initial : Etat final :
Chapitre 4: Le diagramme de classes
1. Définition
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.
2. Les objectifs :
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
3. Les éléments du diagramme de classe
Les éléments de ce diagramme sont les classes et les relations entre ces classes. a. Les 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.
Une classe est représentée en utilisant un rectangle divisé (figure) en trois sections : 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.
b. Les Relations
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.
Figure 24: Exemple d’association
Composition
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
Agrégation
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
Généralisation
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 ".
1 0..* Personne Adresses 1 0..4 Voiture Roue 1..* 1..1 Bibliothèque Livre
Figure 27: Exemple de relation de généralisation (héritage)
Dépendance
Quand une classe utilise une autre classe, par exemple comme membre ou comme 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.
4. Exemple d’application
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.
Annimal
Vache Chat
0..1 0..* 0..1 0..* 0..1 0..* 1..* 1..* 1..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* 0..1 0..* Client -Nom Prenom login password email : String : String : String : String : String Adresse - adresse : String Ouvrage -ISBN titre prix date edition : int : String : float : Date Editeur -Nom Pays : String : String Commande -NumCmde dateCmde montantCmde dateLivraison : int : Date : double : Date Panier - total : float Auteur -Nom Prenom : String : String Ligne -Quantite montant : int : float Theme - libelle : String Carte bancaire
Figure 29: Diagramme de class
Conclusion
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.
