M22- GENIE LOGICIEL ET CONCEPTION

ORIENTEE OBJETS (UML)

Lotfi NAJDI
Année Universitaire 2022 / 2023
Génie Informatique
FPT Taroudant
Introduction UML
Modèle

• Représentation simplifiée de la réalité

• Représentation abstraite d'une entité (phénomène, processus, système, etc.) du monde réel :

• Modéliser pour mieux le comprendre

• Modéliser pour mieux le construire comme en ingénierie.

• Modéliser pour communiquer.

• Un modèle peut être exprimé par des mathématiques, des mots ou des représentations
visuelles.

• Un modèle peut être exprimé à divers niveaux de précision (abstraction).

Pourquoi la modélisation en GL?

• La modélisation permet de spécifier et de concevoir des applications logicielles avant le codage.

• La modélisation est une partie essentielle des projets logiciels de grande envergure, et elle est

également utile aux projets de taille moyenne et même petite :

• Un modèle a un rôle analogue dans le développement de logiciels à celui des plans et autres schémas (

cartes du site, élévations, modèles physiques) dans la construction d'un immeuble.

• S'assurer que les fonctionnalités sont complètes et claires, que les besoins des utilisateurs seront

satisfaits et que la conception du programme répond aux exigences d'évolutivité, de robustesse, de

sécurité, d'extensibilité ..etc.

• Les changements en phase d’implémentation et codage sont plus coûteux et difficiles à gérer.
Pourquoi la modélisation en GL?

La modélisation constitue un moyen essentiel pour la conception et la vérification du système à construire par rapport

aux exigences avant que votre équipe ne commence à coder.

• Visualiser le système comme il est ou comme il devrait l'être.

• Valider le modèle vis à vis des clients

• Spécifier les structures de données et le comportement du système.

• Fournir un guide pour la construction du système.

• Documenter le système et les décisions prises.

UML (Unified Modeling Language )

UML helps you specify, visualize, and document models of software systems, including

their structure and design, in a way that meets all of these requirements. (You can use UML

for business modeling and modeling of other non-software systems too.) Using any one

of the large number of UML-based tools on the market, you can analyze your future

application's requirements and design a solution that meets them, representing the results

using UML 2.0's thirteen standard diagram types.

what-is-uml
UML

• Le langage de modélisation unifié (UML) constitue un moyen privilégié pour communiquer et

partager les éléments de la conception orientée objet.

• UML n'est pas une méthode de conception !

• UML ne présente aucune démarche.

• UML propose un ensemble de notations et de diagrammes pour que chacun ait à sa

disposition les éléments nécessaires à la conception d'une application

• En tant que spécialiste en développement , vous devez au moins être capable de comprendre

un diagramme UML
UML

Outils propriétaires :

• IBM Rational Rose

• StarUML
• Sybase PowerDesigner
• Visual Paradigm

Outils open sources:

• Modelio
• PlantUML
• Eclipse Papyrus
• ArgoUML
• UMLet
UML en mode sketch

• Les croquis sont des diagrammes simples non formels utilisés pour :
• communiquer des idées

• explorer des alternatives

• concevoir de manière collaborative.

• Ils se concentrent généralement sur un aspect du système et ne sont pas destinés à en

montrer tous les détails.

• les diagrammes UML sont utiliser à haut niveau d'abstraction

• Ces diagrammes sont produit avec un tableau blanc whiteboard au lieu des outils
modélisation sophistiqué.
UML en mode blueprint

• Le but des blueprints est de décrire un système de manière détaillée.

• En ingénierie directe (forward engineering) , les diagrammes doivent être assez détaillé
afin qu’un programmeur puisse coder le système :
• Analyse et spécification produit des modèles permettant de mieux comprendre le problème

• Conception produit des modèles pour mieux construire le système.

• Les diagrammes sont détaillés de manière progressive pour éviter toute sorte de confusion pour les
programmeurs.

• Des squelettes de programmes peuvent être générés à partir des modèles construits .

• En ingénierie inverse (reverse engineering) , les diagrammes peuvent être reconstruits à

partir du code afin de décrire les détails d'un système , de mieux le comprendre et de
fournir une représentation du code sous forme graphique.
UML

UML propose plusieurs notations graphiques, notamment :

• Diagramme de cas d’utilisation

• Diagramme de classes

• Diagramme de séquences

• Diagramme d’états

• Diagramme d’activités

• Diagrammes de composants..etc..

Certains de ces modèles sont utiles pour modéliser les exigences, d'autres sont axés sur la

conception et le déploiement.
Cas d'utilisation
Diagrammes de cas d’utilisation
Cas d’utilisation

• Un cas d'utilisation (use case) représente un ensemble de séquences d’actions (scénarios) qui

sont réalisées par le système et qui produisent un résultat observable intéressant pour un

acteur particulier (objectif de l’utilisateur).

• Un cas d’utilisation décrit une interaction avec l’application par un utilisateur dans une

certaine intention. Autrement dit, un service de bout en bout ou une fonctionnalité

significative vu de l’extérieur.

• Permet de décrire et spécifier ce que le futur système devra faire, sans spécifier le comment.
Cas d’utilisation

Un modèle de cas d'utilisation UML décrit et formalise les relations entre le système logiciel à
réaliser et le monde extérieur.

Cette description se place du point de vue externe sans entrer dans les structures internes du
logiciel :

• Préciser les frontières du système (périmètre) .

• Identifier les acteurs qui interagissent avec le système.

• Identifier les interactions mises en œuvre dans la réalisation des besoins métiers.
Acteur

• Un acteur représente un rôle joué par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement avec le système étudié.

• Un acteur peut consulter et/ou modifier directement l’état du système, en émettant et/ou
en recevant des messages susceptibles d’être porteurs de données.

• Le service est rendu pour un seul acteur (acteur principal), qui est souvent la source du
déclenchement du cas d'utilisation.

• Les autres acteurs qui interagissent avec le cas d'utilisation sont des acteurs secondaires.
Ils participent aux scénarios, mais ne sont pas les bénéficiaires du service.
Identification des acteurs

Les acteurs candidats sont systématiquement :

• les utilisateurs humains directs :

• Utilisateur finaux

• Autres profils possibles comme l’administrateur, l'opérateur de maintenance, etc.

• les autres systèmes connexes qui interagissent aussi directement avec le système étudié
Représentation des acteurs

• En UML un acteur est représenté par l’icône ” stick man” avec le nom de l'acteur sous le
l’icône.

• On peut également représenter un acteur sous la forme rectangulaire, avec le mot-clé

«actor», ou bien un rectangulaire avec l’icône ” stick man”

• Généralement on recommande d’utiliser la forme graphique du ” stick man” pour les

acteurs humains et une représentation rectangulaire pour les systèmes connexes .
Identification des cas d’utilisations

• L'ensemble des cas d’utilisation doit permettre de décrire complètement les exigences
fonctionnelles du système.

• Chaque cas d’utilisation correspond à une fonction métier du système, selon le point de vue
d'un de ses acteurs.

• Pour chaque acteur, il convient de :

• Recenser de façon textuelle toutes les interactions entre les acteurs et le système.

• A partir du cahier des charges, identifier et spécifier les services fonctionnels attendus du système.

• Nommez les cas d’utilisation par un verbe à l'infinitif suivi d'un complément, du point de vue de l'acteur

(et non pas du point de vue du système).

Représentation et description des cas d’utilisation

• Diagramme de cas d'utilisation (reliant les acteurs et les cas d'utilisation)

• Description textuelle détaillée des scénarios représentés par les cas d'utilisation

• Diagrammes complémentaires comme le diagramme de séquence pour décrire la chronologie

des échanges de messages entre les acteurs et le système

Diagramme de cas d’utilisation

• Ce diagramme UML décrit les interactions entre les acteurs et l’application représentée
• comme un ensemble de cas.

• Le diagramme de cas d'utilisation est un schéma qui montre les cas d'utilisation (ovales)
reliés par des associations (lignes) à leurs acteurs (icône du « stick man », ou représentation
graphique équivalente).

Le système
 Diagramme de cas d’utilisation

Nom du système

Le rectangle représente
la périmètre c.-à-d. la
Acteur limite du système

Association
Relation entre cas d’utilisation

Dans un diagramme de cas, les cas peuvent éventuellement être liés par des relations

stéréotypées :

• La relation d’inclusion, notée A <<include>> B , signifie que le cas A inclut

obligatoirement le cas B.

• La relation d’extension, notée A <<extend>> B (étend), signifie que le cas A est une

extension optionnelle du cas B à un certain point de son exécution.

Relation entre cas d’utilisation

L'inclusion peut être employée lorsque :

• Plusieurs cas d'utilisation comportent des enchaînements de séquences identiques. Un

nouveau cas d'utilisation qui déclare cette partie commune est utilisé par référence par les
cas d'utilisation et factorise cette partie.

 Les cas d'utilisation de niveau supérieur peuvent appeler des cas d'utilisation de niveau
inférieur. Un exemple typique est un cas d'utilisation Résumé qui inclut un cas d'utilisation
Objectif général pour l'utilisateur.

 Un autre exemple typique est un cas d'utilisation User Goal qui inclut un cas d'utilisation
de sous-fonction réutilisable, comme "Log On".
Relation entre cas d’utilisation

Cas d'utilisation principal Inclus le cas d'utilisation

<<include>> Vérifier le solde du
Payer en ligne
compte

Relation d’inclusion : Cas d’utilisation Vérifier le solde déclenché au cours du scénario de Payer en ligne

Cas d'utilisation principal Etend le cas d’utilisation

<<extends>> Modifier la carte de
Payer en ligne crédit

Relation d’extension : Payer en ligne peut appeler Modifier la carte de crédit sous certaines
conditions. Autrement dit Cas d'utilisation Modifier la carte de crédit peut être déclenché au cours du
scénario de Payer en ligne.
Relation entre cas d’utilisation

On peut également avoir une relation de généralisation/spécialisation:

• Déposer de l'argent est un cas d'utilisation généralisé .

• Déposer Chèque représente une manière spécifique de réaliser l’interaction définie par le cas
d’utilisation Déposer de l'argent .

Déposer de l'argent

Guichetier

Déposer du
Déposer Chèque
numéraires
 Relation de généralisation / spécialisation entre Acteur

La relation de généralisation entre acteurs permet de simplifier le dessin, puisqu’il n’est plus
nécessaire de répéter certaines interactions.

Commander

Client

Rechercher des produits

Consommer les points de

fidélité

Client Abonné

Le client abonnée , peut faire tout ce que fait le client plus ses interactions propres avec le système.
Exercice 1

On souhaite mettre en ouvre un site de vente en ligne spécialisé dans la vente de produits de tiroir. Le
site peut être visité par une personne anonyme(internaute) qui peut consulter le catalogue produit,
ajouter un produit au panier, gérer son panier. Un client ,personne ayant créé un compte, doit se
connecter au système, afin de pouvoir passer une commande en ligne. La validation de la commande
nécessite le paiement du montant de la commande soit par carte de crédit soit par PayPal et la sélection
de l’adresse de livraison pour avoir le total à payer. le client peut faire le suivi de sa commande et
consulter les commandes antécédentes. Le site est géré par un administrateur qui doit gérer les
utilisateurs et également gérer le catalogue de produits en ajoutant, modifiant ou supprimant des
produits. Bien évidemment toutes ces opérations nécessitent une authentification préalable.

1. Identifier les acteurs et les fonctionnalités du système .

2. Proposer un diagramme de cas d’utilisation pour ce système .

Organisation des cas d'utilisation

• Lorsqu'il y en a plus que quelques-uns, l'organisation des cas d'utilisation devient

impérative.

• UML propose le concept de paquetage pour organiser les éléments de modélisation, qui
peuvent également être utilisés pour les cas d'utilisation.

• Il existe plusieurs façons d'organiser les cas d'utilisation :

• Par acteur primaire

• Par cas d'utilisation globale

• Par domaine d'activité

Exercice
Exercice
Etude de cas (Guichet Automatique de Banque )

Cette étude de cas concerne un système simplifié de Guichet Automatique de Banque (GAB).

Le GAB offre les services suivants :

• Distribution d'argent à tout porteur de carte de crédit, via un lecteur de carte et un distributeur de billets.

• 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.

Notez que toutes les transactions sont sécurisées.

1. Identifiez les acteurs et les cas d'utilisation

2. Tracez un diagramme de cas d'utilisation

Identification des acteurs du GAB

Quelles sont les entités externes qui interagissent directement avec le GAB ?
• Premier acteur évident « Porteur de carte». Il pourra uniquement utiliser le GAB pour retirer de l'argent
avec sa carte.

• La phrase 2 identifie des services supplémentaires qui ne sont proposés qu’aux clients de la banque
porteurs d’une carte de crédit de cette dernière. Deuxième acteur, appelé « Client banque ».

• La phrase 3 nous incite à prendre en compte le fait que toutes les transactions sont sécurisées. Il existe
donc d'autres entités externes qui jouent le rôle de Système d'autorisation et avec lesquelles le GAB
communique directement.

• Le Système d'autorisation global Carte Bancaire, pour les transactions de retrait ;

• le Système d'information de la banque, pour autoriser toutes les transactions effectuées par un client
avec sa carte bancaire, mais également pour accéder au solde des comptes.
Identification des cas d'utilisation

• Reprenons un à un les cinq acteurs et listons les différentes façons qu'ils ont d'utiliser le GAB :

• Porteur de carte : Retirer de l'argent.

• Client banque :

• Retirer de l'argent .

• Consulter le solde de son compte courant.

• Déposer de l'argent (du numéraire ou des chèques).

• Système d'autorisation (Sys. Auto.) : Néant.

• Système d'information (SI) banque : Néant.

Diagramme cas d’utilisation
Diagrammes de cas d'utilisation

• Donne aperçu générale des fonctionnalités du système

• Moyen de modélisation et de communication simple , concis et intuitif

• Représenter les cas d'utilisation sous forme de diagramme en notation UML n'est pas
suffisant pour l'équipe de développement.

• Les cas d'utilisation peuvent être accompagné d'une description détaillée expliquant l'objectif
du cas et les scénarios associés :

• Description textuelle détaillé

• Représentation graphique des échanges entre les acteurs et le système

Description textuelle des cas d'utilisation

Cas d’utilisation: Nom cas d'utilisation

Identifiant

Description

Acteurs

Pré-conditions

Post-conditions

Scénario principal

Scénarios alternatifs

Scénarios d'erreur
Description textuelle des cas d'utilisation

• Les pré-conditions décrivent :

• Les conditions qui doivent être vérifiées pour le déclenchement des scénarios du cas d’utilisation.

• dans quel état doit être le système (l'application) avant que ce cas d'utilisation puisse être
déclenché.

• Exemple de pré-conditions pour le cas d’utilisation « retirer argent » :

• le distributeur contient un nombre minimal de billets disponibles.

• Pas de rechargement de billets est en cours d'exécution.

• Les post-conditions décrivent :

• les conditions vérifiées après l'arrêt des scénarios (sauf en cas d'erreur ou de traitement
exceptionnels).

• l'état du système à l'issue des différents scénarios.

• Exemple de post-conditions pour le cas d’utilisation « retirer argent » :

• Le distributeur est disponible pour toute autre opération.

Description textuelle des cas d'utilisation

• Les états décrits par les pré ou post-conditions doivent être des états que l'utilisateur peut

observer.

• Scénario d'événements entre l'acteur et le système.

• Scénario nominal : se déroule quand il n'y a pas d'erreur.

• Scénarios alternatifs : représentent des variantes du scénario nominal

• Scénarios d'exception : décrivent les cas d'erreurs.

Description textuelle des cas d'utilisation
Cas d'utilisation: Acheter avec carte de crédit

Acteurs: Client

Pré-conditions:
1. Le panier comporte un certain un article ou plus
2. L'utilisateur sélectionne la carte de crédit comme méthode de paiement

Post-conditions:
1. Le client reçoit un message de confirmation de l'achat
2. Le système envoie par mail le reçu de paiement

Scénario principal
1. Le système calcule le montant de la facture
2. Le système affiche la facture à l'utilisateur
3. L'utilisateur indique les détails de sa carte de crédit
4. Le système enregistre les détails de la carte de crédit
5. Le système informe l'utilisateur du succès de l'opération.
Etude de cas
Système de gestion de bibliothèque

La bibliothèque de l'Université a été créée pour satisfaire les besoins des étudiants et des enseignants
des différents départements en matière de documentation. Le système de gestion de bibliothèque a été
développé à la fin des années 90. Durant toutes ces années, aucune amélioration majeure n'a été
apportée au système pour répondre aux nouveaux besoins, tels que la possibilité d'emprunter et de
rendre des livres à l'aide d'un scanner à code-barres, la réservation de livres, la mise à jour du profil des
usagers, la recherche avancée des livres, le téléchargement des livres électroniques et le prolongement
des prêts et l’ajout et de suppression des notices de livres.

En plus de ces problèmes fonctionnels, le système a été construit avec des technologies anciennes, ce
qui le rend peu performant et non évolutif.

Ces différents problèmes freinent le désir des étudiants la volonté des étudiants de profiter des services
de la bibliothèque ce qui a posé l'université a initié un projet de refonte du système de gestion de
bibliothèque .
Etude de cas
Système de gestion de bibliothèque
Acteurs

• Étudiant : étudiant de l'université

• Enseignant : enseignant de l'université

• Usager : Une personne qui bénéficie des services de la bibliothèque.

• Bibliothécaire : Un employé du service de la bibliothèque de l'université

Etude de cas
Système de gestion de bibliothèque
Acteurs

• Emprunter des livres

• Retourner des livres

• Réserver un livre

• Mettre à jour le profil de l'usager

• Rechercher des livres

• Télécharger des livres électroniques

• Prolonger un emprunt

• Ajouter une notice d’un livre

• Supprimer une notice d’un livre

Etude de cas
Système de gestion de bibliothèque
Élaboration du diagramme de cas d'utilisation
Etude de cas
Système de gestion de bibliothèque
Détail cas d’utilisation

Cas d’utilisation « Emprunter livres «

Pré-conditions :

L'usager de la bibliothèque possède un abonnement actif

La fiche du livre figure dans la base de données

Post-conditions :

L'enregistrement de l'emprunt de livres est créé

Etude de cas
Système de gestion de bibliothèque
Détail cas d’utilisation

Cas d’utilisation « Emprunter livres »

Scénario nominale:
1. Le bibliothécaire scanne le code-barres de la carte d'identité de l'usager.
2. Le système affiche les détails de l'usager
3. Pour chaque livre à emprunter
3.1 L'usager clique sur "Créer une fiche d'emprunt".
3.2 le SYSTÈME demande : "Veuillez scanner le code-barres à l'arrière du livre".
3.3 L'usager scanne le code-barres au dos du livre.
3.4 Le système affiche une nouvelle ligne de la fiche d'emprunt
3.5 L'usager clique sur Enregistrer
Etude de cas
Système de gestion de bibliothèque
Détail cas d’utilisation

Cas d’utilisation « Emprunter livres »

Scénarios d'exception

2.a Usager non inscrit pour l’année en cours

Système : "Impossible d'emprunter des livres quand la situation administrative n’est

pas régularisée ".

3.2.a Dépassement de 3 livres empruntés

Système : "Cet usager a 3 livres non retournés. Impossible d’emprunter d'autres".
Description textuelle des cas d’utilisation

Un cas d’utilisation peut être représenté sous format textuelle organisé en plusieurs
sections. La fiche de description textuelle d'un cas d’utilisation n’est pas normalisée par UML
et peut être réalisée à différents niveaux de détail au fil de l’analyse.

• Une forme simplifiée qu'est réduite au scénario principal, résumé en une phrase ou un
court paragraphe.

• Une forme intermédiaire qui inclut en plus un résumé des scénarios alternatifs.

• Une forme détaillée, produite juste avant la conception, comprend classiquement les
sections suivantes :
• Sommaire d'identification

• Description détaillée des scénarios : Scénario nominal, scénarios alternatifs, scénarios d’erreurs,
préconditions et postconditions.
Exemple Cas d'utilisation : Transfert d'argent

Préconditions :
• L'utilisateur doit être connecté à son compte bancaire
• L'utilisateur doit avoir suffisamment de fonds sur son compte pour effectuer le transfert.

Post-conditions :
• Le montant spécifié sera déduit du compte de l'utilisateur.
• Le montant spécifié sera crédité sur le compte du destinataire.

Scénario nominale:
• L'utilisateur sélectionne l'option "Transfert de fonds" dans le menu de son compte.
• L'utilisateur saisit les informations sur le compte du destinataire
• L'utilisateur saisit le montant à transférer
• L'utilisateur confirme les informations relatives au transfert et lance le transfert.
• Le système vérifie que l'utilisateur dispose de suffisamment de fonds et traite le transfert.
• Le système affiche un message de confirmation indiquant que le transfert a réussi.
Comment analyser les cas d’utilisations ?

• Pour détailler la dynamique du cas d'utilisation, la procédure la plus évidente consiste à

recenser de façon textuelle toutes les interactions entre les acteurs et le système.

• Le cas d'utilisation doit avoir un début et une fin clairement identifiés.

• Il faut également préciser les variantes possibles, telles que le cas nominal, les différents

cas alternatifs et d'erreur, tout en essayant d'ordonner séquentiellement les descriptions,

afin d'améliorer leur lisibilité.