Vous êtes sur la page 1sur 33

Modélisation orientée objet

UML

Le Langage de Modélisation objet Unifié


Les modèles UML

 Un modèle est une abstraction de la réalité.


 Un modèle est une vue subjective mais
pertinente de la réalité.
 Un modèle caractérise :
 Un niveau métier du domaine d’application :
connexion avec le vocabulaire du domaine.
 Différentes vues du modèle objet final.
Vues de modélisation
Fonctionnel
Diagramme de Use Cases
(Diagramme d’activités)
(Diagramme de séquence)
3 axes de
modélisation

Statique Dynamique Diagramme d’états


Diagramme de Classes (Diagramme d’activités)
(Diagramme d’objets)
(Diagramme de séquence)
Diagramme de composants
Diagramme de
(diagramme de déploiement communication.
Cas d'utilisation (use cases)

 Les fonctions du systèmes sont représentées


au travers des cas d’utilisation.
 Interaction entre le système et l’extérieur.
 Définissent les limites du système et les relations
entre le système est l’environnement.
 Décrivent le comportement du système du point
de vue d’un utilisateur, les acteurs.
 La structuration de la démarche s’effectue par
rapport aux interactions d’une seule catégorie
d’utilisateurs à la fois.
Principes et définitions de base

 Définitions :
 Diagramme de communication, flux
d’événements, ou de données entre des entités
externes et le système à concevoir.
 Les use cases permettent de structurer les
besoins des utilisateurs et les objectifs
correspondants d'un système.
 Ils permettent de classer les acteurs et structurer
les objectifs du système.
Les acteurs

 Rôle joué par une entité externe en


interaction avec le système étudié.
 Identification:
 Utilisateurs humains directs.
 Les autres systèmes connexes.
 Représentation :
<<actor>>
SI banque

Client
Cas d’utilisation
 Use Case :
 Ensemble de séquences, d’actions réalisées par le
système et qui produisent un résultat intéressant pour un
acteur particulier.
 Identification :
 Fonction métier du système selon le point de vue d’un de
ses acteurs.
 Chercher le service fonctionnel du système en réponse à
une action.
 Recenser les interactions entre les acteurs du système.
Cas d’utilisation

 Représentation :
<<actor>>
Acteur non
Humain
Cas d’utilisation 1

Acteur humain 1

Cas d’utilisation 2
Acteur humain 2
Exercice : Le GAB

 Services offerts par le GAB :


 Distribution d’argent à tout porteur de carte de
crédit, va un lecteur de carte et 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.
Toutes les transactions sont sécurisées.
Il faut parfois recharger le distributeur!
Exercice : Le GAB

 Identifier les acteurs ;

 Identifier les cas d’utilisations ;

 Construire le diagramme des cas


d’utilisations.
Correction Secondaire <<actor>>
Sys Auto

Secondaire
<<actor>>
SI Banque
Affinement des cas d’utilisation

 Détailler et organiser les cas d’utilisation :


 En ajoutant des relations d’inclusion et/ou
d’extension.
 En regroupant en « packages » pour définir des
blocs fonctionnel de plus haut niveau.
Relation d’inclusion
Relation d’extension
Structuration des cas d’utilisation en
packages

 Plusieurs stratégies possibles :


 Regroupement par acteur;
 Regroupement par domaine fonctionnel…
Opérations non
client
Service support

<<actor>>
Sys Auto S’authentifier

<<actor>>
SI Banque

Opérations client

Maintenance
Acteur primaire (principal)
ou secondaire
 Tous les acteurs n’utilisent pas forcément le
système.
 Acteur principal : celui pour qui le cas d’utilisation
produit un résultat observable.
 Acteur secondaire : participe au cas d’utilisation,

sollicité pour des informations complémentaires.


Informe ou consulte le système lors de l’exécution
du cas d’utilisation.
Exercice : modélisation d’un
magasin
 Le client entre dans le magasin, passe dans les
rayons, demande éventuellement des
renseignements ou procède à des essais, prend des
articles (ou les réserve si le stock est insuffisant),
passe à la caisse ou il règle ses achats. Il peut
bénéficier d’une réduction ou d’un avoir. Il peut
régler en liquide, par chèque (pour un montant
supérieur à 15 euros, ou par carte pour un montant
supérieur à 13 euros). Aucune référence n’est
attribué au client, même si des renseignements sont
conservés en cas de réclamation. Une livraison est
possible pour les achats encombrants.
Diagramme de séquence

 Montrent des interactions entre objets selon


un point de vue temporel.
 Pas de présentation explicite du contexte des
objets.
 Dans la vue fonctionnelle sert à documenter
les cas d’utilisation.
 Description des interactions entre objets sans
détails de synchronisation.
Diagramme de séquence

 Représentation :
Ligne
appelant appelant
téléphonique
décroche

tonalité

numérotation

indication de sonnerie sonnerie

décroche

Les Flèches correspondent à des évènements dans le domaine d’application


Pas de distinction entre flots de données et flots de contrôle.
Diagramme de séquence…
…en application

 Réalisez un diagramme de séquence qui


décrit le scénario du cas d’utilisation « Retirer
de l’argent ».
Diagramme d’activités
 UML permet de représenter graphiquement le
comportement d'une méthode ou le déroulement
d'un cas d’utilisation, à l'aide de diagrammes
d'activités.
 Une activité représente une exécution d'un
mécanisme, un déroulement d'étapes séquentielles.
 Le passage d'une activité vers une autre est
matérialisé par une transition.
 Les transitions sont déclenchées par la fin d'une
activité et provoquent le début immédiat d'une autre
(elles sont automatiques).
Diagramme d’activités

 Représentation :
transition
Activité 1 Activité 2

Demander
addition

garde
[Prix < somme disponible] [else]

Régler note Faire


vaisselle
Diagramme d’activités

 Synchronisation
 Synchronise des transitions : « barre de
synchronisation »
 Ouvre et de ferme des branches parallèles au
sein d'un flot d'exécution.
 Les transitions qui partent d'une barre ont lieu en
même temps.
 Franchissement d’une barre après réalisation de
toutes les transitions.
Diagramme d’activités

 Synchronisation :
Appuyer Appuyer
touche ctrl touche v

Coller texte
Diagramme d’activités…
…en action

 Réalisez un diagramme d’activités qui décrit


le cas d’utilisation « retirer de l’argent avec
une carte ».
Diagramme d’états transitions
 Visualise des automates déterministes.
 On ne représente pas les automates des
objets qui ne changent pas (ou peu) d’état.
 Un objet est à tout moment dans un état
donné.
 Un objet passe d’un état à un autre par les
transitions.
 Les transitions sont déclenchées par un
évènement.
Diagramme d’états transitions
 Représentation :
Etude d’une caisse enregistreuse
 Un système simplifié de caisse enregistreuse de supermarché :
 Un client arrive à la caisse avec des articles à payer
 Le caissier enregistre le numéro d’identification de chaque article, ainsi que la
quantité si elle est supérieure à un.
 La caisse affiche le prix de chaque article et son libellé.
 Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
 La caisse affiche le total des achats.
 Le client choisit son mode de paiement :
 Liquide : le caissier encaisse l’argent reçu, la caisse indique la monnaie à rendre
au client.
 Chèque : le caissier vérifie la solvabilité du client en transmettant une requête à un
centre d’autorisation via la caisse.
 Carte de crédit : un terminal bancaire fait partie de la caisse. Il transmet une
demande d’autorisation en fonction du type de carte.
 La caisse enregistre la vente et imprime le ticket
 Le caissier donne le ticket de caisse au client.
 Après saisie article le client peut présenter des coupons de réduction.
 Lorsque le paiement est termine, la caisse transmet les informations sur le
nombre d’articles vendus au système de gestion des stocks.
 Tous les matins, le responsable du magasin initialise les caisses pour la journée.
Etude d’une caisse enregistreuse
 Identifiez les acteurs et les cas d’utilisation.
 Elaborez un diagramme des cas d’utilisation.
 Réalisez un diagramme de séquence
décrivant le scénario du cas d’utilisation «
Traiter passage en caisse ».
 Montrez par un diagramme d’états la
succession des opérations pour le cas
d’utilisation « Traiter passage en caisse ».
Correction

<<actor>> <<actor>>
Centre autorisation chèques Centre autorisation cartes
Quelques conseils…
 Identification des acteurs :
 Utilisateurs humains directs (admin, opérateur…);

 Les systèmes connexes interagissant avec le

système étudié.
 Acteurs « logiques » au profit des acteurs physiques:
 L’acteur est celui qui bénéficie de l’utilisation su

système.
 Permet de s’affranchir des technologies d’interfaces.

 Utilisez le plus souvent possibles les relations


d’inclusions et d’extensions.
Quelques conseils…
 Les relations entre cas d’utilisation :
 Inclusion : évite de devoir décrire plusieurs fois le même

enchaînement;
 Extension : Permet de séparer un comportement complexe

optionnel ou rare du comportement obligatoire;


 Généralisation / Spécialisation : formalise des variations

importantes sur le même cas d’utilisation.


 Complétez la description des cas d’utilisation par un ou plusieurs
diagramme «dynamique » d’UML.
 Pour la dynamique des cas d’utilisation => diagramme d’activités.

 Ou un diagramme d’états pour les cas d’utilisation très interactifs.

 Pour décrire le scénario nominal, utilisez un diagramme de

séquence.

Vous aimerez peut-être aussi