LaNgAgE De mOdÉlIsAtIoN (U.M.
L)
TaReK BeN MeNa
3ème année; Ecole Supérieure Privée d’Ingénierie et de Technologie
Informatique
[email protected]
PlAn
§ Introduction à la modélisation
§ Introduction à UML
§ Modélisation avec UML
– Modélisation fonctionnelle
– Modélisation Statique
– Modélisation dynamique
2017/18
TBM
2
MoDéLiSaTiOn dE L’aNaLySe
TaReK
Smart’Com 2K18
[email protected]
DiAgRaMmE De cAs d’uTiLiSaTiOn
2017/18
TBM
4
MoDéLiSaTiOn dEs bEsOiNs
Avant
de
développer
un
système,
il
faut
savoir
précisément
à
QUOI
il
devra
servir,
c-‐à-‐d
à
quels
besoins
il
devra
répondre.
§ Faire une Analyse Fonctionnelle
– recenser l'ensemble des fonctionnalités du système en
examinant les besoins fonctionnels de chaque acteur.
§ Modéliser les besoins c’est :
– Faire l'inventaire des fonctionnalités attendues ;
– Organiser les besoins entre eux, de manière à faire apparaître
des relations (réutilsations possibles, ...).
– Les représenter au moyen de diagrammes de cas d'utilisation.
2017/18
TBM
5
Un eXeMpLe : DiAgRaMmE De cAs d’uTiLiSaTiOn
2017/18
TBM
6
cAs d’uTiLiSaTiOn
§ Cas d'utilisation
– est un service rendu à l'utilisateur, il implique des séries d'actions
plus élémentaires
– décrit par un groupe verbale : verbe à l’infinitif + complément
Un
cas
d'u@lisa@on
est
l'expression
d'un
service
réalisé
de
bout
en
bout
avec
un
déclenchement,
un
déroulement
et
une
fin,
pour
l'acteur
qui
l'ini@e.
– Notation :
Ajouter
un
ar@cle
au
panier
2017/18
TBM
7
AcTeUr
§ Acteur
– est une entité extérieure au système modélisé, et qui interagit
directement avec ce dernier
– Un acteur correspond à un rôle, pas à une personne physique.
• Une même personne peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
• Si plusieurs personnes jouent le même rôle, elles seront représentées par
un seul acteur.
– En plus des rôle utilisateurs, les acteurs peuvent être des :
• périphériques manipulés par le système (imprimantes...) ;
• logiciels déjà disponibles à intégrer dans le projet ;
• systèmes informatiques externes
2017/18
TBM
8
ReLaTiOn eNtRe aCtEuR eT CaS D’uTiLiSaTiOn
– Acteur : un nom représentant un rôle
– Cas d’utilisation : verbe à l’infinitif + complément
§ Les acteurs impliqués dans un cas d'utilisation lui sont liés
par une association.
§ L’acteur peut utiliser plusieurs fois le même cas d'utilisation.
2017/18
TBM
9
ReLaTiOn eNtRe aCtEuR eT CaS D’uTiLiSaTiOn
§ L'acteur est dit principal pour un cas d'utilisation lorsque
l'acteur est à l'initiative des échanges nécessaires pour
réaliser le cas d'utilisation.
§ L’acteur est dit secondaire pour un cas d’utilisation lorsque
l’acteur est sollicité par le système.
– Le plus souvent, les acteurs secondaires sont d'autres systèmes
informatiques
2017/18
TBM
10
ReLaTiOn eNtRe aCtEuRs
§ Une seule relation possible : la généralisation.
– Ce qui signifie qu’un acteur hérite du rôle d’un autre acteur
2017/18
TBM
11
ReLaTiOnS EnTrE CaS D’uTiLiSaTiOn
§ Inclusion: le cas A inclut le cas B (B est une partie
obligatoire de A).
§ Extension: le cas B étend le cas A (B est une partie
optionnelle de A).
§ Généralisation: le cas A est une généralisation du cas du
cas B (B est une sorte de A). A est cas abstrait
2017/18
TBM
12
RéUtIlIsAbIlItÉ AvEc: InClUsIoNs & ExTeNsIoNs
§ Les relations entre cas permettent la réutilisabilité du cas
« s'authentifier » : il sera inutile de développer plusieurs fois
un module d'authentification.
2017/18
TBM
13
DéCoMpOsItIoN AvEc: InClUsIoNs & ExTeNsIoNs
§ Quand un cas est trop complexe (faisant intervenir un trop
grand nombre d'actions), on peut procéder à sa
décomposition en cas plus simples.
2017/18
TBM
14
GéNéRaLiSaTiOn
§ Un virement est une sorte de paiement.
§ La flèche pointe vers l'élément général.
§ Cette relation de généralisation/spécialisation est présente dans
la plupart des diagrammes UML
– se traduit par le concept d'héritage dans les langages orientés objet.
2017/18
TBM
15
MéThOdOlOgIe
1. Identifier les acteurs
– Délimiter les frontières du système
– Identifier les utilisateurs puis les rôles et les autres systèmes qui
interagissent avec le système
2. Recenser les cas d'utilisation (UC)
– se placer du point de vue de chaque acteur déterminer
• comment il se sert du système,
• dans quels cas il l'utilise, et
• à quelles fonctionnalités il doit avoir accès
– I l faut éviter les redondances et limiter le nombre de cas en se
situant au bon niveau d'abstraction (par exemple, ne pas réduire un
cas à une seule action).
– Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il
faut rester au niveau des grandes fonctions du système.
3. Etablir le diagramme des cas d’utilisation
4. Décrire les cas d’utilisation textuellement
2017/18
TBM
16
Un 1eR ExEmPlE: L’iNcOnToUrNaBlE :
GuIcHeT AuToMaTiQuE De bIlLeTs
2017/18
TBM
17
ExErCiCe : GuIcHeT AuToMaTiQuE De bAnQuE
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.
§ N’oubliez pas non plus que :
– Toutes les transactions sont sécurisées
– Il est parfois nécessaire de recharger le distributeur,
IdEnTiFiCaTiOn dEs aCtEuRs
2017/18
TBM
19
IdEnTiFiCaTiOn dEs cAs d’uTiLiSaTiOn
§ Porteur de carte :
– Retirer de l’argent.
§ Client banque :
– Retirer de l’argent (à ne pas oublier !)
– Consulter le solde de son compte courant.
– Déposer du numéraire
– Déposer de l’argent (du numéraire ou des chèques).
§ Opérateur de maintenance :
– Recharger le distributeur.
– Maintenir l’état opérationnel (récupérer les cartes avalées, récupérer les
chèques déposés, remplacer le ruban de papier, etc.).
§ Système d’autorisation (Sys. Auto.) :
– Néant.
§ Système d’information (SI) banque :
– Néant.
2017/18
TBM
20
èRe
1 VeRsIoN
2017/18
TBM
21
SoLuTiOn dÉtAiLlÉe
2017/18
TBM
22
DeScRiPtIoN DeS CaS D’uTiLiSaTiOn
§ Le diagramme de cas d'utilisation décrit les grandes
fonctions d'un système du point de vue des acteurs,
§ mais n'expose pas de façon détaillée le dialogue entre les
acteurs et les cas d'utilisation.
§ Un simple nom (groupe verbale) est tout à fait insuffisant
pour décrire un cas d'utilisation (source d’ambiguïté)
Chaque
cas
d'uClisaCon
doit
être
documenté
pour
qu'il
n'y
ait
aucune
ambiguïté
concernant
son
déroulement
et
ce
qu'il
recouvre
précisément.
2017/18
TBM
23
1/ IdEnTiFiCaTiOn
§ Nom du cas : Utiliser une tournure à l’infinitif.
§ Résumé : Une description résumée permettant de comprendre
l’intention principale du cas d’utilisation.
§ Acteurs principaux : Ceux qui vont réaliser le cas d’utilisation.
§ Acteurs secondaires : Ceux qui ne font que recevoir des
informations à l’issue de la réalisation du cas d’utilisation.
§ Date de création : Date de création du cas d’utilisation.
§ Date de mise à jour : Date de mise à jour du cas d’utilisation.
§ Version : Le numéro de la version.
§ Responsable : Le nom du responsable.
2017/18
TBM
24
2/ DeScRiPtIoN DeS EnChAiNeMeNtS
§ Pré-conditions : Ce qui doit être vérifié avant que le cas
d’utilisation ne commence.
§ Scénario nominal : Description du scénario nominal.
§ Enchainements alternatifs : Description des scénarii
alternatifs qui amènent le scénario nominal à une autre
séquence de traitement et qui se termine de façon normale.
§ Enchainements d’erreur : Description des scénarii
d’exception qui décrivent les cas d’erreurs.
§ Post-conditions : ce qui est vrai après que le cas
d’utilisation se soit déroulé.
2017/18
TBM
25
3/ SpÉcIfIcAtIoN NoN FoNcTiOnNeLlE
§ Besoins d’Interface Homme Machine
– Expression de contraintes liées à l’interface.
– Facteurs humain d’utilisabilité
– (Maquette)
§ Contraintes non fonctionnelles
– Disponibilité, Fiabilité, Performances, Concurrence.
2017/18
TBM
26
Un eXeMpLe : PaYeR PaR CaRtE BaNcAiRe
2017/18
TBM
27
ExEmPlE : DeScRiPtIoN TeXtUeLlE (1/3)
Identification
§ Nom du cas : Payer par CB
§ Objectif : Détailler les étapes permettant à client de payer
par carte bancaire
§ Acteurs :
– Client,
– Banque (secondaire)
§ Date de création : 18/09/18
§ Date de mise à jour : 26/09/18
§ Version : 1.1
§ Responsables : M. Toto
2017/18
TBM
28
ExEmPlE : DeScRiPtIoN TeXtUeLlE (2/3)
Séquencements :
§ Le cas d'utilisation commence lorsqu'un client demande le paiement par
carte bancaire
§ Pré-conditions : Le client a validé sa commande
§ Enchaînement nominal
1. Le client saisit les informations de sa carte bancaire
2. Le système vérifie que le numéro de CB est correct
3. Le système vérifie la carte auprès du système bancaire
4. Le système demande au système bancaire de débiter le client
5. Le système notifie le client du bon déroulement de la transaction
§ Enchaînements alternatifs
– En (2) : si le numéro est incorrect, le client est averti de l'erreur, et invité à
recommencer
– En (3) : si les informations sont erronées, elles sont re-demandées au client
§ Post-conditions :
– La commande est validée
– Le compte de l'entreprise est crédité
è
Cons@tueront
les
futurs
tests
d’accepta@on
2017/18
TBM
29
ExEmPlE : DeScRiPtIoN TeXtUeLlE (3/3)
§ Contraintes liées à l’IHM :
– Toujours demander la validation des opérations bancaires
– Un clavier numérique (pour saisir son code), avec des touches «
validation», « correction » et « annulation ».
– Un écran pour l’affichage des messages.
§ Contraintes non fonctionnelles :
– Fiabilité : les accès doivent être sécurisés
– Confidentialité : les informations concernant le client ne doivent
pas être diviulgués
2017/18
TBM
30
LeS EnChAiNeMeNtS SoNt aPpElÉs ScÉnArIo
§ Un scénario représente
– u ne succession particulière d’enchaînements, s’exécutant du début à la
fin du cas d’utilisation,
– un enchaînement étant l’unité de description de séquences d’actions.
§ Un cas d’utilisation contient en général
n scénario nominal et
– u
– p lusieurs scénarios alternatifs (qui se terminent de façon normale) ou
d’erreur (qui se terminent en échec).
2017/18
TBM
31
AuTrE PrÉsEnTaTiOn dEs sCéNaRiOs [LaRmAn 97]
§ Rappeler vous du GAB
AcCon
coté
Acteur
RéacCons
coté
Système
1-‐
Le
Porteur
de
carte
introduit
sa
carte
2-‐
Le
GAB
vérifie
que
la
carte
introduite
dans
le
lecteur
de
cartes
du
GAB.
est
bien
une
carte
bancaire.
3-‐
Le
GAB
demande
au
Porteur
de
carte
de
saisir
son
code
d’inden@fica@on.
4-‐
Le
Porteur
de
carte
saisit
son
code
d’
5-‐
Le
GAB
compare
le
code
iden@fica@on.
d’iden@fica@on
avec
celui
qui
est
codé
sur
la
puce
de
la
carte.
6-‐
Le
GAB
demande
une
autorisa@on
au
Système
d’autorisa@on.
7-‐
Le
Système
d’autorisa@on
donne
son
8-‐
Le
GAB
demande
au
Porteur
de
carte
accord
et
indique
le
solde
hebdomadaire
de
saisir
le
montant
désiré
du
retrait.
2017/18
TBM
32
MoDéLiSeR LeS ScÉnArIoS
§ Pour documenter les cas d’utilisation, la description textuelle est
indispensable,
– communiquer facilement avec les utilisateurs
– s’entendre sur la terminologie métier employée.
§ Le texte présente des désavantages
– il est difficile de montrer comment les enchaînements se succèdent,
– Difficile de montrer l’intervention des acteurs secondaires.
– la maintenance des évolutions devient souvent fastidieuse.
§ Il est donc recommandé de compléter la description textuelle
par un ou plusieurs diagrammes dynamiques UML.
iagramme d’activité
– D
– Diagramme de séquence (Système)
– UML 2 : « Interaction Overview Diagram »
2017/18
TBM
33
MoDéLiSeR Un sCéNaRiO
§ Diagramme de Séquence § Diagramme d’activité
2017/18
TBM
34
MoDéLiSeR Un sCéNaRiO
2017/18
TBM
35
ExErCiCe – DeScRiPtIoN TeXtUeLlE
GuIcHeT AuToMaTiQuE De bIlLeTs
2017/18
TBM
36
ExErCiCe :
§ Donner la Description
Textuelle de retirer
Argent
2017/18
TBM
37
SoLuTiOn
§ Titre : Retirer de l’argent
Résumé : ce cas d’utilisation permet à un Porteur de carte,
qui n’est pas client de la banque, de retirer de l’argent, si
son crédit hebdomadaire le permet.
§ Acteurs :
– Porteur de carte (principal),
– Système d’autorisation (secondaire).
§ Date de création : 02/03/02
§ Date de mise à jour : 05/05/06
§ Version : 5.0
§ Responsable : Foulen Ben Foulène
2017/18
TBM
38
SoLuTiOn
§ Description des scénarios
§ Pré-conditions
– La caisse du GAB est alimentée (il reste au moins un billet !).
– Aucune carte ne se trouve déjà coincée dans le lecteur.
– La connexion avec le Système d’autorisation est opérationnelle.
§ Scenario nominal
2017/18
TBM
39
SoLuTiOn
2017/18
TBM
40
DiAgRaMmE De sÉqUeNcE
§ Scénario nominal
2017/18
TBM
41
SoLuTiOn
§ Enchainements alternatifs
§ A1 : code d’identification provisoirement erroné
démarre au point 5 du scenario nominal.
– 6. Le GAB indique au Porteur de carte que le code est erroné, pour la première ou
deuxième fois.
– 7. Le GAB enregistre l’échec sur la carte. Le scenario nominal reprend au point 3.
§ A2 : montant demandé supérieur au solde hebdomadaire
démarre au point 10 du scenario nominal.
– 11 Le GAB indique au Porteur de carte que le montant demandé est supérieur au
solde hebdomadaire. Le scenario nominal reprend au point 8.
§ A3 : ticket refusé
démarre au point 11 du scénario nominal.
– 12. Le Porteur de carte refuse le ticket.
– 13. Le GAB rend sa carte au Porteur de carte
– 14. Le Porteur de carte reprend sa carte.
– 15. Le GAB délivre les billets.
– 16. Le Porteur de carte prend les billets.
2017/18
TBM
42
SoLuTiOn
§ E1 : carte non-valide
démarre au point 2 du scénario nominal.
– 3. Le GAB indique au Porteur que la carte n’est pas valide (illisible, périmée,
etc.), la confisque ; le cas d’utilisation se termine en échec.
§ E2 : code d’identification définitivement erroné
démarre au point 5 du scénario nominal.
– Le GAB indique au Porteur de carte que le code est erroné, pour la troisième
fois.
– Le GAB confisque la carte.
– Le Système d’autorisation est informé ; le cas d’utilisation se termine en échec.
§ E3 : retrait non autorisé
démarre au point 6 du scénario nominal.
– Le Système d’autorisation interdit tout retrait.
– Le GAB éjecte la carte ; le cas d’utilisation se termine en échec.
2017/18
TBM
43
MoDéLiSaTiOn pAr uN DiAgRaMmE D’AcTiViTé
AiDeZ MoI À FaIrE Un RrRrApPeL
2017/18
TBM
45
DiAgRaMmE De sÉqUeNcEs SyStÈmE
Analyse Dynamique
2017/18
TBM
46
InTrOdUcTiOn
§ Description dynamique d’un cas d’utilisation
– Pour faciliter la lecture des enchaînements et la maintenance des
évolutions
– Difficile à percevoir à travers le texte
– Difficile aussi de voir quand les acteurs secondaires sont sollicités
§ Diagramme de séquence système
– Exploitent les diagrammes de cas d’utilisation
– Utilisation spécifique, simplifiée pour le point de vue Utilisateur
2017/18
TBM
47
InTrOdUcTiOn
§ Intérêt
– Il représente le déroulement chronologique d’un scénario
– Il sert à documenter les cas d’utilisation
§ Entités
– Les acteurs et le système (Boîte noir)
– Pas de présentation explicite du contexte des objets.
§ Messages
– Echanges d’informations entre entités
– Description des interactions entre objets sans détails de
synchronisation
2017/18
TBM
48
ExEmPlE
Message
Synchrone
Message
Réponse
Ligne
de
vie
2017/18
TBM
49
ExEmPlE : ReTiReR De l’ArGeNt
§ Scénario nominal
2017/18
TBM
50
NoTiOn dE FrAgMeNt
§ Un fragment combiné correspond à un ensemble
d’interactions auquel on applique un opérateur.
§ Il se représente comme un diagramme de séquence avec
indication dans le coin à gauche du nom de l’opérateur.
Opérateur
§ 13 opérateurs ont été définis dans UML dont les
principaux sont :
– alt, opt, loop, par, break, ref
2017/18
TBM
51
L’oPéRaTeUr OpT
§ L’opérateur opt (optional) correspond à une instruction de
test sans alternative (sinon)
– De la forme : SI...ALORS
2017/18
TBM
52
L’oPéRaTeUr AlT
§ Il désigne un choix d’une ou plusieurs alternatives
– SI alors SINON
– Choix Parmi
2017/18
TBM
53
L’oPéRaTeUr LoOp
§ Il permet de décrire un ensemble d'interactions qui
s'exécutent en boucle tant qu’une condition est satisfaite.
2017/18
TBM
54
FrAgMeNt rÉfÉrEnCé
§ Permet de référencer un séquencement précédemment
modélisé
Nom
du
Frame
2017/18
TBM
55
ExEmPlE
2017/18
TBM
56
