Cours gratuits » Cours informatique » Cours programmation » Cours UML » Cours UML avec exemple PDF

Cours UML avec exemple PDF


Télécharger



★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Support de formation UML avec exemple d'application

...

2. Types de visualisation dans UML

2.1. Visualisation « Use Cases »

Les cas d’utilisation (Use cases) décrivent la fonctionnalité d’un système. Ces diagrammes s’adressent aux clients, concepteurs, responsables  du développement, responsables des tests

Un Use Case décrit un point fonctionnel du système et le fonctionnement global du système est décrit par l’ensemble des Use Cases  

>

2.1.1. Use Cases dans UML

Les use cases sont représentés par une ellipse dans laquelle est inscrit le nom du Use Case

Ils sont généralement connectés à un acteur avec une association  

2.1.2. Liens entre Use Cases

« extends » signifie qu’un Use Case est une spécialisation d’un autre Use Case plus général. L’Use Case plus spécifique n’inclut pas nécessairement tout le comportement du Use Case qu’il spécialise

« uses » signifie qu’un Use Case utilise intégralement la fonctionnalité du Use Case plus général en plus de lui ajouter des fonctionnalités additionnelles

2.1.3. Description d’un Use Case

Un use case est décrit par :

Ses Objectifs

Le Flot des messages entre l’acteur et le Use Case

Le Flot secondaire des messages entre l’acteur et le Use Case

Les Condition de fin pour le Use Case et information retournée à l ’acteur lors qu’il se termine

2.1.4. Qu’est-ce qu’un bon Use Case

Un bon Use Case représente une fonctionnalité du système qui est complète du début jusqu’à la fin. Il doit normalement apporter quelque chose de valable à un acteur (i.e. un résultat tangible à une de ses commandes ou à une de ses actions sur le système).

Il n’y a pas de consensus sur la « grosseur » que devrait prendre un Use Case en termes de fonctionnalité.

2.2. Visualisation « Logique »

Il existe deux types visualisation logique : Visualisation statique et Visualisation dynamique

La visualisation statique est décrite par les diagrammes de classes et d’objets.

La visualisation dynamique est décrite par les diagrammes d’états, séquentiels (de séquence), de collaboration et d’activité

2.2.1Vision statique

2.2.1.1. Diagrammes de classes

Classes et objets :

Une classe sert à décrire de manière générique une catégorie d’objets participant aux actions du système

Un objet est relié à une classe de la même manière qu’une variable est associée à un type de données dans un langage de programmation procédural

Les fondements de la programmation orientée objet sont les classes, les objets, et les relations entre eux.

Ces classes, objets, et relations sont représentés par des diagrammes en langage UML

Le diagramme de classes est un modèle statique du système qui décrit le système en termes de ses classes et des relations entre celles-ci. Il sert de base aux autres diagrammes où d’autres facettes du système sont décrites (tels les diagrammes d ’états des objets ou les diagrammes de collaboration qui sont des diagrammes dynamiques)

Recherche des classes

La recherche des classes est une étape de création.

Pour trouver les classes pertinentes à un problème, il faut se poser les questions suivantes:

– Est-ce qu’une information doit être analysée ou stockée?

– Est-ce que le système interagit avec d’autres systèmes?

– Existe-t-il des patrons, des librairies, ou des composantes réutilisables dans le système?

– Le système doit-il manipuler des périphériques (devices)?

– Quels rôles les acteurs jouent-ils?

– Le système possède-t-il des pièces structurales (parts)?

Types classiques de classes

Entity: servent à modéliser des catégories d’objets qui ont une durée de vie importante dans le système (i.e. elles sont des parties intégrantes du système)

Boundary: servent à faciliter la communication des classes Entity avec l’extérieur du système (soit un autre système, avec l’utilisateur ou encore avec un périphérique)

Control: servent à coordonner les échanges de messages entre les autres classes pour réaliser un Use case

Représentation des classes en UML

Une classe est représentée par un rectangle divisé en trois compartiments:

– le compartiment du nom

– le compartiment des attributs

– le compartiment des méthodes (opérations)

La syntaxe dans les différents compartiments est indépendante des langages de programmation

  1. Compartiment de nom

             Il contient le nom de la classe.

             Il est centré dans le compartiment.

             Il est imprimé en caractères gras.

             Le nom ne doit pas être ambigu et doit être tiré du domaine propre au problème.

  1. Compartiment des attributs

Les attributs servent à décrire les caractéristiques des objets appartenant à la classe (i.e. décrivent l’état de l ’objet)

Chaque attribut possède:

             Un type (primitif ou défini par l’usager)

             Un niveau de visibilité (public (+), protected (#) ou private (-))

             Une valeur par défaut

Optionnellement, on peut aussi indiquer qu’un attribut possède une portée s’appliquant à la classe (class scope) ou une chaîne de propriétés indiquant les valeurs que peut prendre l’attribut.

Exemples de classe avec attributs

  1. Compartiment des opérations

Les opérations permettent de manipuler les attributs et d’effectuer d’autres actions. Elles sont appelées pour des instances (objets) de la classe.

             La signature des opérations comprend:

             un type de retour

             un nom

             0 ou plus paramètres (ayant chacun un type, un nom et possiblement une valeur par défaut)

             une visibilité (private(-), protected(#), public(+))

Les opérations constituent l’interface de la classe avec le monde extérieur

Exemple de classe avec opérations

Spécification de l’opération

Une méthode (opération) est spécifiée par :

             les Pré-conditions: doivent être vérifiées avant que l’algorithme ne s’exécute

             les Post-conditions: doivent être vraies une fois l’opération complétée

             l’Algorithme: effet que l’opération a sur l’objet

Relations entre les classes

Un diagramme de classes montre les classes d’un système mais également les relations entre celles-ci.

On compte quatre principales catégories de relations entre classes :

–les associations

–les généralisations (héritage)

–les dépendances

–les raffinements

Les associations de classes

Il existe plusieurs types d’associations:

             normale

             récursive

             agrégation par référence

             agrégation par composition

  1. Association normale

Une association normale est une connexion entre classes.

-              Elle possède un nom.

-              Elle est généralement navigable de manière bidirectionnelle (dans ce cas elle a un nom dans les deux sens si nécessaire)

-              Elle a une multiplicité

-              Elle peut être dotée de rôles

  1. Association récursive

Une classe peut être connectée à elle-même via une association récursive. Elle représente une connexion sémantique entre des objets mais avec la différence que ceux-ci appartiennent à la même classe

  1. Agrégation par référence

Elle indique une relation tout-partie. Elle se représente par une ligne avec un losange du côté       « tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une seule extrémité.

Une agrégation par référence possède des rôles, multiplicité, …etc., comme une association normale.

  1. Agrégation par composition

Elle indique une relation tout-partie avec inclusion « physique ». Elle se représente par une ligne avec un losange plein du côté « tout » de l’agrégation. Ce losange ne peut apparaîtra qu’à une seule extrémité.

Une agrégation par composition possède des rôles, multiplicité, …etc., comme une association normale

Les généralisations de classes

Une généralisation est une relation entre une classe générale et une classe plus spécifique.

La classe spécifique est appelée sous-classe et la classe générale est appelée super-classe.

La sous-classe hérite des attributs et opérations de la super-classe (en fonction de la visibilité de la généralisation) une sous-classe peut être la super-classe d’une autre classe dans ce que l’on appelle une hiérarchie

Représentation des généralisations

On représente les généralisations par une flèche allant de la classe spécifique à la classe générale.

Lorsqu’une classe spécifique hérite de plusieurs super-classes, on parlera d’héritage multiple

Les Interfaces

Les interfaces sont des classes contenant seulement des opérations sans implantation.

Une classe peut implanter une interface.

Le symbole d’implantation est une flèche pointillée allant de la classe vers l ’interface

Ici, la classe A implante les interfaces Storable et Runnable et B utilise ces implantations

2.2.1.2. Les Packages

Pour les systèmes comprenant plusieurs classes, il convient de regrouper celles-ci en entités logiques, les packages

Un package est un ensemble de packages et de classes reliés sémantiquement entre eux.

Chaque package est muni d’une interface (ses classes public) qui lui permet de communiquer sa fonctionnalité aux autres packages qui peuvent l’importer

Un package est représenté par un dossier (folder).

Les Packages ont eux aussi un niveau de visibilité est des relations qui sont ici: la dépendance, le raffinement, et la généralisation

2.2.1.3. Les Templates

UML supporte les templates (aussi appelés « parameterized classes ») qui sont symbolisés par un symbole de classe avec un ajout identifiant le fait que le template doit être « instancié » avant de pouvoir créer des objets de la classe correspondant au template  

2.2.1.4. Qualités d’un modèle statique

Un bon modèle statique doit répondre aux questions suivantes :

Le modèle peut-il être communiqué aux autres membres de l’équipe de même qu’au client ?

Le modèle a-t-il une utilité pour décrire le système?

Le modèle embrasse-t-il les caractères essentiels du système (permet-il entre autres de bien répéter les use-cases?

Les noms des classes du modèle reflètent-ils les noms des éléments du système (i.e. les noms sont-ils pertinents)?

Des modèles différents de la même chose sont-ils intégrés et coordonnés entre eux?

Les modèles sont-ils simples (même pour les systèmes complexes)?

2.2.2. Visualisation « Dynamique »

La modélisation dynamique sert à montrer comment les objets d’un système collaborent pour réaliser une fonctionnalité du système. Elle montre comment les objets s’échangent des messages (i.e. comment un objet, le client, invoque une opération sur un autre objet, le serveur). Ces échanges sont appelés interactions.

Les interactions sont montrées via trois principaux diagrammes: séquence, collaboration, activité.

Un autre diagramme, le diagramme d’état décrit le comportement d’un objet mais cette fois-ci pris isolément.

Diagramme d’états: décrit les états que peut prendre un objet durant son cycle d’existence et le comportement de ces états de même que les événements qui provoquent un changement d’état de l’objet

Diagramme séquentiel : montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le temps.

Diagramme de collaboration: montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le l’espace. Par espace on entend ici les relations (liens) entre les objets dans le système.

Diagramme d’activité: montre comment les objets interagissent et communiquent entre eux pour accomplir une tâche du système. La variable indépendante est ici le travail accompli par les objets.

Interactions entre les objets (messages)

En programmation orientée objet, les interactions entre les objets sont modélisées comme des messages envoyés d’un objet à un autre. Ces messages sont simplement des appels d’opérations d’un objet par un autre avec le contrôle qui revient à l’objet appelant avec une valeur de retour

  1. synchrone: l’objet appelant transmet le message et attend la réponse (i.e. la valeur de retour de l’opération appelée) avant de poursuivre son activité;
  2. asynchrone: l’objet appelant transmet le message et n’attend pas la réponse (i.e. la valeur de retour de l’opération appelée) avant de poursuivre son activité. Cela implique par exemple que les objets peuvent s’exécuter sur des threads différents.
  3. simple: message dont on ne spécifie pas la nature exacte (synchrone ou asynchrone);
  4. synchrone avec retour immédiat: cas spécial de message synchrone pour lequel l’attente de la réponse du serveur est négligeable.

2.2.2.1. Les diagrammes de séquence

Ils illustrent comment les objets interagissent entre eux. Ils se concentrent sur la séquence des messages envoyés entre les objets (c’est-à-dire comment et quand les messages sont envoyés et reçus entre les objets)

Ils possèdent deux axes: l’axe vertical montre le temps tandis que l’axe horizontal montre l’ensemble des objets en interaction dans un scénario ou une scène spécifique d’un scénario.

Les diagrammes de séquence peuvent être utilisés sous deux formes:

– forme générique: elle décrit tous les déroulements possibles d’un scénario et peut contenir des branchements, des conditions, et des boucles.

– forme d’instanciation: elle décrit le comportement du système pour un aspect spécifique d’un scénario et ne peut donc contenir aucun branchement et aucune condition ou boucle.

Les messages dans les diagrammes séquentiels

Ils représentent une communication entre objets véhiculant une information avec l’anticipation qu’une action sera entreprise.

La réception d’un message est généralement appelée événement.

Les messages ...

Quand un objet reçoit un message, on dit qu’il entre dans sa phase d’activation. Un objet dans cette phase peut:

– exécuter son propre code

– attendre les résultats retournés par un autre objet à qui il a envoyé un message

L’activation d’un objet est représentée par un rectangle étroit sur la ligne de vie de l’objet

Les messages les plus communs qu’un objet peut recevoir sont :

  • l’envoi d’un signal ;
  • l’invocation d’une opération ;
  • la création ou la destruction d’une instance.

L’envoi d’un signal déclenche une réaction chez le récepteur, de façon asynchrone et sans réponse : l’émetteur du signal ne reste pas bloqué le temps que le signal parvienne au récepteur et il ne sait pas quand, ni même si le message sera traité par le destinataire.

Plus encore que l’envoi d’un signal, l’invocation d’une opération est le type de message le plus utilisé en programmation objet. Si, par exemple, une classe C possède une opération op, l’invocation se fait par c.op(), où c est une instance de la classe C.

Notation

Un message synchrone se représente par une flèche à l’extrémité pleine qui pointe sur le destinataire du message. Ce message peut être suivi d’une réponse qui se représente par une flèche en pointillé.

Un message asynchrone se représente par une flèche à l’extrémité ouverte.

La création d’un objet est matérialisée par une flèche qui pointe sur le sommet d’une ligne de vie.

La destruction d’un objet est matérialisée par une croix qui marque la fin de la ligne de vie de l’objet.

Règles de cohérence (well-formedness rules)

– Chaque objet dans le diagramme de séquence doit être instance d'une classe dans le diagramme de classe

– Chaque message dans le diagramme de séquence doit correspondre à une opération dans le diagramme de classe

– ...

SYNTAXE DES MESSAGES

La syntaxe des messages est :

<nomDuSignalOuDeOpération> [’(’ [<argument>’,’ … ’)’]

où la syntaxe des arguments est la suivante :

[ <nomDeParamètre> ’=’ ] <valeur de l’argument>

Par défaut, les paramètres transmis ne peuvent pas être modifiés par le récepteur (les arguments sont « en entrée »). Pour indiquer que des paramètres peuvent être modifiés (argument « en sortie » ou « en entrée/sortie »), il faut écrire :

<nomDuParamètreEnSortie> [’:’ <valeur de l’argument> ]

Exemple

Appeler( "Capitaine Hadock", 54214110 )

afficher( x, y )

initialiser( x = 100 ) est un message dont l’argument en entrée reçoit la valeur 100.

f( x :12 ) est un message avec un argument en entrée/sortie x qui prend initialement la valeur 12.

La syntaxe de réponse à un message est la suivante :

[<attribut> ’=’] message [’:’ <valeur de retour> ] où message représente le message d’envoi.

Exemple

nombreLivres = chercher( "Tintin" ) : 42

CONTRAINTES SUR LES LIGNES DE VIE

Une contrainte est indiquée sur une ligne de vie par un texte entre accolades.

Une contrainte peut aussi être contenue dans une note attachée à l’occurrence de l’événement sur lequel elle agit.

Une contrainte est évaluée au cours de l’exécution de l’interaction. Si la condition de la contrainte n’est pas vérifiée, les occurrences d’événement qui suivent cette contrainte sont considérées comme invalides, alors qu’une contrainte qui se vérifie rend valides les événements à suivre.

FRAGMENTS D’INTERACTION COMBINÉS

Un fragment combiné se représente de la même façon qu’une interaction : par 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

l’opérateur d’interaction alt indique que le fragment est un choix. Les deux options de choix sont appelées « opérandes de l’opérateur alt ».

Opérateur Loop

La syntaxe d’une boucle est la suivante :

loop [’(’ <minint> [’,’ <maxint> ] ’)’ ]

où la boucle est répétée au moins minint fois avant qu’une éventuelle condition booléenne ne soit testée (la condition est placée entre crochets sur la ligne de vie) ; tant que la condition est vraie, la boucle continue, au plus maxint fois (minint est un entier supérieur ou égal à 0, maxint est un entier supérieur ou égal à minit).

loop( valeur ) est équivalent à loop( valeur, valeur ).

loop est équivalent à loop( 0, * ), où * signifie « illimité »

Opérateur par

L’opérateur par permet d’envoyer des messages en parallèle. Ses opérandes se déroulent en parallèle.

Opérateur ignore et consider

Les opérateurs ignore et consider permettent de focaliser l’attention du modélisateur sur une partie des messages qui peuvent être envoyés durant une interaction. Quand de nombreux messages sont possibles, certains sont importants, d’autres moins.

L’opérateur ignore définit l’ensemble des messages à ignorer, tandis que l’opérateur consider définit l’ensemble de ceux qu’il faut prendre en compte.  

La syntaxe de l’opérateur ignore est :

ignore { listeDesNomsDesMessagesÀIgnorer }

La syntaxe de l’opérateur consider est :

consider { listeDesNomsDesMessagesÀConsidérer }

Dans les listes, les messages sont séparés par des virgules.

Opérateur strict sequencing

L’opérateur strict sequencing impose que ses opérandes se déroulent dans l’ordre strict de leur présentation, c’est-à-dire de haut en bas.

DÉCOMPOSITION D’UNE LIGNE DE VIE

Une décomposition est référencée dans le rectangle en tête de ligne de vie, sous le label ref.

À la figure 3.26, la ligne de vie PointDAccès est décomposée en deux lignes p1 et p2.

Cette notation est une autre manière de décomposer une ligne de vie dans un diagramme d’interaction.

Une porte est un point de connexion qui permet de relier un même message représenté par des flèches différentes dans plusieurs fragments d’interaction.

Exercice

Le programme suivant, écrit en pseudo-code, permet de calculer le factoriel d’un nombre n :

int factoriel( int n ){

if( n == 0 ) return 1;

return n * factoriel( n-1) ;

}

où n 0 et factoriel( 0 ) = 1.

Représentez le programme précédent sur un diagramme de séquence.


1066