Conception orienté objet (UML)

Etude de cas
Pr. HIBBI Fatima-Zohra
Plan de cours

 Diagramme de cas d’utilisation

 Description textuelle

 Diagramme de classes

 Diagramme d’activité

 Diagramme de séquence
Modèle

 Un modèle est une représentation abstraite de la réalité, d'une entité (processus, système,
etc.) du monde réel en vue de le décrire, de l'expliquer ou de le prévoir.
UML

UML signifie « Unified Modeling Language » ou Langage de modélisation unifié en français. C’est un langage
de modélisation qui permet de représenter graphiquement les besoins des utilisateurs. On utilise pour cela des
diagrammes.

Les concepteurs orientent leurs modélisations selon trois axes sur lesquels ils répartissent les diagrammes :

• L’axe fonctionnel qui est utilisé pour décrire ce que fait le système à réaliser: Diagramme de Use Cases;

• L’axe structurel et statique qui est relatif à la structure du système: Diagramme de classes;

• L’axe dynamique qui est relatif à la construction des fonctionnalités du système: Diagramme de séquence.
Langages de modélisation

Des langages à différents niveaux de formalisation :

 Langages formels (Z,B,VDM) : le plus souvent mathématiques, au grand pouvoir

d'expression et permettant des preuves formelles sur les spécifications ;

 Langages semi-formels (MERISE, UML...) : le plus souvent graphiques, au pouvoir

d'expression moindre mais plus faciles d'emploi.
Diagramme de cas d’utilisation

Un cas d'utilisation est un service rendu à l'utilisateur, il implique des séries

d'actions plus élémentaires.

Use case

Un acteurs est une entité extérieure au système modélisé, et qui interagit

directement avec lui.
 Éléments de modélisation des cas
d'utilisation

Il existe 4 catégories d’acteurs :

 les acteurs principaux : les personnes qui utilisent les fonctions principales du système
 les acteurs secondaires : les personnes qui effectuent des tâches administratives ou de
maintenance.
 le matériel externe : les dispositifs matériels incontournables qui font partie du domaine de
l’application et qui doivent être utilisés.
 les autres systèmes : les systèmes avec lesquels le système doit interagir.
Acteur et cas d’utilisation
Relations entre cas d'utilisation en acteurs

Les acteurs impliqués dans un cas d'utilisation lui sont liés par une association. Un acteur
peut utiliser plusieurs fois le même cas d'utilisation.
Relations entre cas d'utilisation en acteurs

• Inclusion: le cas A inclut le cas B (B est une partie obligatoire de A).

• Extension: le cas B étend(ajout) le cas A (B est une partie optionnelle A).

• Généralisation: le cas A est une généralisation du cas B (Best une sorte de A).
Relations entre cas d'utilisation en acteurs
 Exercice d’application N°1:

Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque (GAB).
Le GAB offre les services suivants :
1. Distribution d’argent à tout Porteur de carte de crédit, via un lecteur de carte et un distributeur de billets.
2. Consultation de solde de compte, dépôt en numéraire et dépôt de chèques pour les clients porteurs d’une carte de crédit de la
banque adossée au GAB.
3. Toutes les transactions sont sécurisées.
4. Il est parfois nécessaire de recharger le distributeur, etc.
L’objectif de cette étude de cas
• identifier les acteurs ;
• identifier les cas d’utilisations ;
• construire un diagramme de cas d’utilisation ;
 Elaborez le diagramme de cas d’utilisation
Exercice d’application N°2:

Dans un établissement scolaire, on désire gérer la réservation des salles de cours.

Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la
salle ou du matériel).
Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et étudiants).
Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut
être consulté que par les enseignants.
Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif
horaire pour l’ensemble de la formation.

 Elaborez le diagramme de cas d’utilisation

Exercice d’application N°3:

Dans un magasin, un commerçant dispose d’un système de gestion de son stock d’articles, dont les
fonctionnalités sont les suivantes :
• Edition de la fiche d’un fournisseur
• Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur est automatiquement
éditée. Si le fournisseur n’existe pas, on peut alors le créer)
• Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer l’inventaire, d’effacer
un article ou d’éditer la fiche d’un article).

 Elaborez le diagramme de cas d’utilisation

 Exercice d’application N°4:

Nous nous intéressons à un système simplifié de gestion de projets au sein d'une société de services
(développement, étude, …).
Les utilisateurs de l'application (directeur, chefs de projet) auront la possibilité de consulter et mettre à jour les
informations aux quelles ils auront accès. Ces informations peuvent concerner un projet en cours ou clôturé ;
Cette application doit permettre :
Au directeur de:
- Modifier le montant d’un projet et le chef du projet.
- Faire des recherches de projets et avoir toutes les informations.
Au chef de projet de:
- Réalise et modifier les projets qu'il dirige.
 Elaborez le diagramme de cas d’utilisation
 Description textuelle des cas d’utilisation

Une description textuelle se compose de trois parties :

Partie 1 : Identification.
Partie 2 : Description des scénarios.
Partie 3 : Exigence non fonctionnelle
  Titre : Nom du cas d’utilisation
Partie I:
 Résumé : description du cas d’utilisation.

Identification  Acteurs : descriptions des acteurs

principaux et secondaires.

 Version : Numéro de la version.

  Les pré-conditions : État du système avant que le cas d’utilisation puisse être
déclenché (l’établissement de connexion).

 Les Scénarios : Il y a plusieurs types de scénarios :

Partie II:
- Le scénario nominal qui correspond à un déroulement normale d’un cas
d’utilisation.

Description des scénarios. - Les scénarios alternatifs qui sont des variantes du scénario normale (code
erroné, ..).

- Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une erreur
(carte non valide).

 Les post-conditions : Elles décrivent l’état du système après l’issue de chaque

scénario (ex: enregistrement des transactions en cas de succès, etc)
Partie III:
 La partie 3 permet de préciser des spécifications non

Exigence non fonctionnelle. fonctionnelles (fréquence, fiabilité, type d’interface homme-

.machine...) (ex: cryptage du code)..

 Exemple de description textuelle :
Le cas d‘utilisation ‘Retirer de l’argent’ du GAB.

Partie 1 : Description.

 Titre : Retirer de l’argent.

 Résumé : Ce cas d’utilisation permet aux possesseurs de carte bancaire de retirer de l’argent.

 - Acteur principale : Un porteur de carte bancaire.

- Acteurs secondaires : Le Système d’Information de la banque et le Système d’Autorisation

Globale Carte Bancaire.

 Version : 1.0
 Exemple de description textuelle :
Le cas d‘utilisation ‘Retirer de l’argent’ du DAB.
Partie 2 : Description des scénarios.
 Pré-conditions :
- Le GAB contient des billets.
- Les connexions avec le Système d’Autorisation et le Système d’information de la banque sont opérationnelles.
 Scénario nominale :
1) Le GAB demande le code de la carte au Porteur de carte.
2) Le Porteur de carte saisit son code.
3) Le GAB demande une autorisation au Système Globale d’autorisation.
4) Le Système d’Autorisation globale donne son accord et indique le crédit hebdomadaire.
5) Le GAB demande le montant désiré au Porteur de carte.
6) Le Porteur de carte saisit le montant.
7) Le GAB vérifie si le montant demandé est inférieur ou égale au crédit hebdomadaire.
8) Le GAB rend la carte et demande au Porteur de carte de la retirer.
9) Le GAB demande au Porteur de carte s’il désire un ticket.
10) Le Porteur de carte accepte le ticket.
11) Le GAB délivre le ticket et les billets en cas d’acceptation.
 Exemple de description textuelle :
Le cas d‘utilisation ‘Retirer de l’argent’ du DAB.
 Scénario alternatifs :

Scénario alternatif SA1: Le code est erroné pour la première ou la deuxième fois.

SA1 commence au point 2 du scénario nominale.

Le GAB indique que le code est erroné.

Le GAB enregistre l’échec.

Scénario alternatif SA2: Le montant demandé est trop élevé.

SA2 commence au point 5 du scénario nominale.

Le GAB affiche le montant max et demande au Porteur de carte de ressaisir un montant.

 Exemple de description textuelle :
Le cas d‘utilisation ‘Retirer de l’argent’ du DAB.
 Scénario d’exception:

Scénario d’exception SE1: Carte non valide

SE1 commence au point 2 du scénario nominal.

Le GAB Indique que la carte n’est pas valide restitue la carte et met fin au cas.

Post-conditions:

Les détails de la transaction doivent être enregistrés (montant, numéro carte, date…) aussi bien

en cas de succès que d’échec.

 Exemple de description textuelle :
Le cas d‘utilisation ‘Retirer de l’argent’ du DAB.

Partie 3 : Exigences non fonctionnelles

La saisie du code confidentiel ne doit pas faire apparaître le code à l’écran.

Le compte du client ne doit pas être débité tant que le billets n’ont pas été distribués.