Approche Objet, UML et ses formalismes (II)

Djamal Benslimane

UML et ses formalismes

Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme Diagramme de classes dobjets de cas dutilisation dtats de squences dactivits de collaboration de composants de dploiement

Diagramme de cas dutilisation

1. 2. 3. 4. 5.

6.

Cas dutilisation : Dfinition Les acteurs Les scnarios dun cas dutilisation Relations entre cas dutilisation Construction dun diagramme de cas dutilisation Documentation des cas dutilisation.

Diagramme de cas dutilisation Dfinition

But : spcifications (besoins) fonctionnelles du systme.
intervient

Use Case Systme

un cas = un service (fonctionnalit) Acteur = utilisateur du service Il y a des acteurs principaux et secondaires

Acteur

Permet de dcrire les interactions du systme avec son environnement Expression du Comportement du systme (actions et ractions) selon le point de vue des utilisateurs du systme Dtermination des besoins fonctionnels des utilisateurs cibles.

Diagramme de cas dutilisation Concepts principaux

Acteurs
Ou Nom Acteur <<actor>> Nom Acteur Ou Nom Acteur

Cas dutilisation

Use Case

Relations (entre acteurs, cas dutilisation, acteurs et cas dutilisation)

Diagramme de cas dutilisation Cas dutilisation

Les cas utilisation expriment
les principales tches de chaque acteur, les modifications des donnes du systme, les cas d'anomalies

Pour voir de faon simple :

les diffrents acteurs comment est dlimit le systme les fonctionnalits demandes au systme les rles des diffrents acteurs vis--vis du systme

Descriptions :
Textuelle Sous forme de scnario (diagramme de squence) Sous forme de diagramme de collaboration

Diagramme de cas dutilisation Cas dutilisation

Permettent de reprsenter le comportement d'un systme vu du ct utilisateur Traduit une spcification d'utilisation du systme Reprsente des ensembles de scnarios Trs utile en phases d'analyse des besoins car structure les besoins des utilisateurs finaux Correspond (plus ou moins) une dcomposition fonctionnelle du systme

Diagramme de cas dutilisation Les Acteurs

Les acteurs dfinissent les diffrents rles que les utilisateurs du systme peuvent jouer Un acteur peut tre un humain ou un constituant informatique, un dispositif matriel ou un autre systme : nanmoins cest une entit externe Pas de relation 1-1 entre un acteur et un utilisateur du systme

Identification des acteurs : processus itratif

Diagramme de cas dutilisation Les Acteurs

Les acteurs peuvent tre de trois types :
humains, des utilisateurs du logiciel, logiciels qui manipulent le systmes l'aide d'une API, matriels, robots et automates qui exploitent les donnes du systme ou qui sont pilots par le systme.

Typologie des acteurs :

utilisateurs du systme administrateurs du systme

Diagramme de cas dutilisation Les Acteurs

L'acteur peut consulter ou modifier l'tat du systme : interaction avec le cas dutilisation par envoi de message. En rponse l'action d'un acteur, le systme fournit un service : le cas dutilisation qui correspond la fonctionnalit dsire. Remarques :
Une mme personne (physique) peut correspondre plusieurs acteurs dans le systme. Un mme acteur peut tre jou par plusieurs entits ou individus distincts.

Diagramme de cas dutilisation exemple

Bibliothque
Consulter un catalogue

Rserver un livre Emprunter un livre

navigateur

tudiant
Rendre un livre

Prolonger un prt

M--J un catalogue

bibliothquaire

Diagramme de cas dutilisation exemple

Peut correspondre la source/Destination si la Source/ Destination est llment externe interagissant directement avec le systme. Frontire du systme Limite automatisable

tudiant Dclencheur / Rponse

Emprunter un livre

Le nombre de livres emprunts par cet tudiant doit tre < 3

Diagramme de cas dutilisation Les catgories dActeurs

On distingue : Acteurs principaux : Participant externe interagissant directement avec le systme dans le cadre du service dcrit par un cas dutilisation. Acteurs de support : Participant offrant un service qui contribue la ralisation du cas dutilisation. Acteurs de coulisse : Bnficiaires indirects dun cas dutilisation, sans pour autant en tre un bnficiaire direct ou un contributeur. Ex. Gestionnaire de la bibliothque.

Diagramme de cas dutilisation Les catgories dActeurs

Acteur de support Acteur Principal

Communiquer logiciel Dveloppeur Responsable CFAO

Diagramme de cas dutilisation Choix des Acteurs

Utilisateurs humains : identifier tous les profils possibles (oprateur de maintenance, administrateur) Autres systmes connexes qui intragissent avec le systme : vrifier quils agissent bien directement avec le syst., et pas par leur biais dun acteur dj rpertori ! Vrifier que les acteurs sont bien EXTERIEURS au systme, que ce ne sont pas des composants. Vrifier aussi quil a une autonomie de dcision, a ne doit pas tre un matriel passif

tude de cas : SIVEX

Socit de messagerie : enlvement, transport et livraison de colis 70 agences, 3000 employs et 40 000 colis traits par jour Souhaite un syst. qui permette de :
localiser et connatre ltat des colis en TR suivre les commandes + gestion comptable autoriser les clients suivre lacheminement de leur commande via Internet

Besoins techniques : UML / archi. 3-tiers / Internet / JAVA /SGBDR (cf CdesCh)

Acteurs de SIVEX
Rceptionniste Client
Saisie et annule les cdes client Consulte ses encours via internet, reoit confirmation cde par courriel ou fax

Progiciel de comptabilit Comptable Rpartiteur

Fait le point recouvrements sur

les

cdes,

tablit

factures/avoirs;

Cre les diffrentes missions en fonction cdes et ressources; pare aux incidents

Acteurs de SIVEX (suite)

Chauffeur
Assure les missions; rceptionne/livre les colis; informe de ses arrts le systme

Oprateur de quai
Identifie et pse les colis provenant dun enlvement; pointe le passage des colis en dpart et arrive dagence; inventaires de quai.

Responsable logistique
Dfinit le rseau des agences; stratgie de transport

Administrateur systme
Gre les profils utilisateurs du systme, et mots de passe; archivages

Contexte statique : SIVEX

Responsable Logistique Rceptionniste 0..n 0. .1 0..70 Rpartiteur

0..n

SIVEx

0..70

Clie nt 0..1 0..1 0..n 0..n

Administrateur Systme

Comptable Progiciel de Com pta bil it Chauffeur

Oprateur de Quai

Diagramme de cas dutilisation Relation entre acteurs

Gnralisation
Authentif ication

Utilisateur

Client

Rceptionniste

Compta ble

Rpartiteur

Chauf f eur

Oprateur de Quai

Responsable Logi stique

Administrateur Sy stme

Diagramme de cas dutilisation Identifier les messages

message = communication entre acteur et systme le message transporte de linformation le message est envoy avec lintention de dclencher une activit chez le rcepteur la rception dun message est considre comme un

vnement

se demander quels sont les messages envoys par les acteurs qui dclenchent un comportement attendu, dans le cadre de leur activit pour le syst., se demander quels sont les messages envoys vers chaque acteur

Diagramme de cas dutilisation Les messages

A partir des messages : Construire le diagramme de contexte dynamique, qui ordonne et classe les messages.
Systme au centre, comme une bote noire Acteurs autour Mentionner les messages et le sens de la communication : de lacteur vers le systme ou linverse

Contexte dynamique : SIVEX

: Responsable Logistique : Rceptionniste
c rat ion, modif ication, annulation commande crat io n cli ent
cration, modif ication af fe ctat ion r esso urces

condi ti ons com m ande en-cours

statistiques transport

incident m ission commande traiter tat ressources

: Rpar ti te ur

cration, modif ication mission

c rat ion, modif ication prof il utilisateur

conf irmation commande en-cours

SIVEx
listes colis comm ande tiquette

: Client

rglement

: Administrateur Sy stme

f actures relance

f actures

bordereaux mission
identif ication colis pointage colis dbut/f in inv entaire

: Comptable : Pr...
arrt/dpart tape v nement mission

: Opr ateu r de Quai

: Chauf f eur

Diagramme de cas dutilisation Cas dutilisation : construction

A partir des acteurs identifis dans ltude prliminaire
chercher les intentions (mtier) avec lesquelles il utilise le systme dterminer dans le CdesCh les services fonctionnels attendus

Utiliser les changes de messages identifis dans le contexte dynamique Distinguer lacteur principal des acteurs secondaires

Etude de cas SIVEX

on part du diagr. de contexte dynamique chercher l intention fonctionnelle de chaque acteur dans son intraction avec le systme sinspirer des messages regrouper les intentions en units cohrentes avant les diagrammes de cas dutilisation, on liste les CU candidats avec nom, acteurs, et messages mis et reus par les acteurs donner une 1re description succincte de chaque CU, qui mentionne brivement lintention et les actions correspondantes

Ex. Planification missions

Acteur principal = rpartiteur Intentions
planifier les missions dune agence, permettant la ralisation des commandes en cours

Actions :
crer une nouvelle mission :
regrouper des commandes, affecter des ressources disponibles, tablir un parcours, valuer les dures, le volume ncessaire pour la camionette, etc

modifier ou annuler une mission existante

Ex. Suivi de mission

Acteur principal = chauffeur
Intentions
Informer en temps rel de ltat davancement de la mission en cours

Actions
- Transmettre chaque arrt et dpart dtape - Signaler les vnements de mission
acquittement client, panne, retard, absence client...

Use Case : Gestion des missions

secondaire

Suivi de mission

Rpart it eur

secondaire

Chauffeur

Planificat ion des missions

Planification des missions d'enlvement Planification des missions de livraison

Planification des missions de traction

Diagramme de cas dutilisation Fiche Cas dutilisation

On dcrit les cas dutilisation sous forme textuelle dabord, et ventuellement avec des diagrammes. Structure de description des cas dutilisation qui permet de mieux les exploiter par la suite :
version, responsable) pr-post conditions)

sommaire didentification (titre, but, rsum, acteurs, dates, description des enchanements (nominaux, exceptionnels,
ventt : besoins dIHM

ventt : contraintes non-fonctionnelles (frquence, volumtrie, disponibilit, confidencialit, performances)

 Planification des missions (1/5)

BUT : planification des missions denlvement, de transport ou de livraison, dune agence partir du plan de transport, des commandes assurer quotidiennement et des ressources disponibles. RESUME : cration dune nouvelle mission partir des cdes confirmes, modification et annulation dune mission existante.
ACTEURS : rpartiteur (ppal), chauffeur (sec.) PRE-CONDITIONS :
le rpartiteur est authentifi les commandes planifier sont confirmes

Les Enchanements
Enchanement nominal = fonctionnement normal
ex.: dans le processus dappel tlphonique, fonctionnement nominal = Dcrocher combin, entendre sonnerie attente, composer numro, attendre sonnerie appel, communiquer, raccrocher

Enchanement exceptionnel = fonctionnement anormal, traitement des vnements exceptionnels ex.: dans le processus dappel tlphonique, fonctionnement exceptionnel = Dcrocher combin, pas de
sonnerie dattente, vrifier branchement ligne, (suite)

 Planification des missions (2/5)

Enchanements identifis :
crer une mission en attente affecter des commandes une mission affecter les ressources modifier une mission en attente (dsaffecter une commande, modification des chauffeurs ou vhicule, modification des tapes) valider une mission en attente modifier une mission valide annuler une mission (en attente ou valide) diter les bordereaux de mission

 Planification des missions (3/5)

Les exceptions identifies :
Pour une mission donne, dpassement de tonnage vhicule Chauffeur slectionn non qualifi pour conduire le vhicule choisi pour la mission Tonnage de rserve entamm (chaque agence doit se rser-ver un certain tonnage pour pouvoir rpondre des commandes prioritaires ou de dpannage) Estimation de temps incomplte pour une tape donne donc pour la mission comportant cette tape

 Planification des missions (4/5)

Post-conditions
Tout ce qui est connu lissue du cas

Besoins dIHM

Pour lister les commandes de lagence, le rpartiteur doit pouvoir rpertorier les commandes de lagence par type, poids, site desservi, affecte/non affecte, tarification urgent/non urgent Les commandes non affectes doivent tre de couleur diffrente

 Planification des missions (5/5)

Contraintes non fonctionnelles : temps de rponse
Interface rpartiteur : moins de 2 secondes Concurrence : les validations de mission doivent tre notifies aux lecteurs potentiels par un message davertissement en TR Disponibilit : le systme doit tre accessible au rpartiteurs 6 jours sur 7, aux heures douverture des agences

Autres contraintes :

Diagramme de cas dutilisation

Autre relations entre cas dutilisation

La relation dinclusion : INCLUDE ou use

Appel un endroit explicite dans le scnario ppal du cas dutilisation de base et sinsre dans celui-ci. Est ncessairement excut dans le cadre du cas de base.

On utilise la relation include pour :

Factoriser des sous-fonctions qui sont communes dautres cas dutilisation. Dcomposer en sous-units un cas dutilisation complexe.

Diagramme de cas dutilisation

La relation INCLUDE ou use
include

Autre relations entre cas dutilisation

virement

identification

Exprime que le cas dutilisation source comprend galement le comportement dcrit par le cas dutilisation destinataire (utile pour la factorisation de cas).

Diagramme de cas dutilisation

La relation dextension : EXTEND

Autre relations entre cas dutilisation

Permet dtendre, de faon structure, le comportement dun cas dutilisation de base en utilisant un autre cas dutilisation un point dextension spcifique. Les points dextension sont dfinis lintrieur dun cas dutilisation de base, l o un comportement/traitement particulier est ncessaire. Lorsquon atteint un point dextension, on se branche sur le ou les cas dutilisation traitant ce point dextension. Si plusieurs cas dutilisation extension sont activs par un mme point dextension, lordre de leur excution est non dterministe.

Diagramme de cas dutilisation

Autre relations entre cas dutilisation

extend

Virement par Internet

Virement

Emprunter un livre
Extend point Quota_atteint

extend (quota_atteint)

Refuser le prt

tudiant

Autres relations entre cas

Relation dinclusion include :
La ralisation dun cas de base passe obligatoirement par celle dun cas spcifique inclus (objectif : factorisation)
Ex. : procdure dauthentification

Relation dextension extend :

Cas de base incorpore une extension, un point
dextension prvu (obj.: reprsenter un comportement optionnel)

Ex. : la prise de commande peut conduire la cration dun nouveau client

Exemple
Quelles relations utiliser ?
Entre un cas modification document et un cas vrification droit daccs include Entre un cas dveloppement pages dun site web et un cas dfinition charte extend graphique Entre un cas saisie commande et un cas vrification stock include

Document du Diagramme de cas dutilisation

Diagramme da cas dutilisation est complt par un document textuel semi-structur
Titre But Rsum Acteurs Date + version Pr conditions Enchanements Exceptions Post conditions {IHM}

Les cas dutilisation sont de trs bons moyens de communication

Structuration des cas dutilisation

Structuration par package : regroupement fonctionnel de haut niveau Package en UML = concept commun de regroupement
dlments dun modle de diagrammes de ces lments dautres packages

Contrainte : ensemble cohrent au niveau smantique (expertise mtier)

Techniques de regroupement
Par domaine dexpertise mtier
regroupement le plus intuitif et efficace permet de faciliter la spcilisation des analystes organiser facilement la rpartition des experts

Par acteur
facile si chaque cas est reli UN seul acteur

Par lot de livraison client

dans le cas dun dveloppement incrmental, cest parfois un critre utilis

Regroupement en packages : SIVEX

Gestion client le

Gest ion comptabilit Logis tique

Par domaine dexpertise mtier Ensembles dacteurs fortement lis

Gest ion missions Traitement colis

Services support
g lob al

Risques associs aux Cas

Ne pas rinventer la dcomposition fonctionnelle !
On fait de lanalyse ORIENTEE OBJET !!

Ne pas aller trop loin dans le dtail, on en est la capture des besoins.
Limiter 20 le nombre de ( grands ) CU, rester synthtique

Les Cas dutilisation ne sont pas une fin en soi, leur objectif est de :
dialoguer avec le client, analyser les besoins mtier, dmarrer lanalyse en identifiant les classes candidates.

Autres risques
Ne pas mlanger lIHM et le fonctionnel
on dcrit le mtier des acteurs, indpendamment des choix dinterface qui pourront voluer ex.: prfrer lors dune 1re commande, le rceptionniste enregistre les caractristiques du nouveau client dans le systme : le rceptionniste saisit le nom du client en 8 car. max, en majuscules, puis appuie sur ENTER, puis saisit le prnom en minuscules ou le rceptionniste enregistre par un syst. de reconnaissance vocale les noms, prnom, adresse et code postal du client