Cours Uml - Partie 1

UML Analyse et conception orientes objets
2A - Anne acadmique : 2009 - 2010 Rdig par Abdelhadi AIT ADDI Matre de confrence Dpartement Info IUT A Tl : 04 74 47 21 46 Mobile : 06 64 98 77 59 Mail : addi@e-businesspartners.fr
UML Unified Modeling Language

1. Prsentation du cours 2. Identification des acteurs et cas d'utilisation 3. Description des cas d'utilisation 4. Diagrammes dynamiques pour les cas d'utilisation 5. Relations entre cas d'utilisation 6. Complments la modlisation des besoins 7. Rappels sur les concepts objets 8. L'analyse oriente objet 9. Les diagrammes de classes participantes 10.L'architecture logique
Prsentation du cours
Vue d'ensemble
Besoins Analyse Conception Codage Test
Espace du problme = analyse
Espace de la solution = modlisation
Objectifs
Appliquer une dmarche d'analyse itrative pilote par les cas d'utilisation Matriser les concepts et la notation UML pour l'analyse Dfinir les besoins avec les cas d'utilisation
Objectifs
Construire des diagrammes de classes d'analyse Construire des diagrammes de squence d'analyse Construire des diagrammes d'tats pour les classes d'analyse
Ce qu'est et n'est pas UML UML = Langage de modlisation

graphiques textes standard
UML Mthode
Dfinition d'UML
UML est un langage de modlisation pour :

Comprendre et dcrire les besoins Spcifier des systmes, simples ou complexes Concevoir et construire des solutions Documenter (textes et graphiques) un systme Communiquer entre les membres de l'quipe projet
Dfinition d'UML
UML est un langage usage gnral, quelque soit :
Le type de systme logiciel, matriel, organisation, etc. Le domaine mtier gestion, ingnierie, finance, etc. Le processus de dveloppement cascade, itratif, RAD, etc.
UML est un standard OMG
UML est un langage public et standardis
L'Object Management Group (OMG) a retenu UML comme le langage de modlisation objet standard, pour la spcification et la conception L'OMG est dsormais responsable de ses volutions Site officiel : www.omg.org
Le processus de dveloppement
QUI fait QUOI, QUAND et COMMENT ? Il existe une grande varit adapter en fonction :
Du projet : Modification de l'existant ? Petit projet ? Temps rel ? Des gens : Expertise ? Exprience ?
Ce cours s'appuie sur un processus appel Processus Unifi ( vous de piocher :)
Points-cls : Expression des besoins
Des besoins mal spcifis peuvent conduire des systmes :

Inutilisables, Inutiles
Parmi les symptmes les plus frquents sur les projets informatiques ayant chou :

L'incapacit traiter des exigences volutives La mauvaise comprhension des besoins des utilisateurs finaux.
Points-cls : analyse
Si l'analyse du systme est saute ou nglige
Le manque de connaissances mtiers peut provoquer des erreurs ou des dtails importants Vous allez rsoudre le mauvais problme !
Quelle est votre exprience avec l'analyse (avant la conception) ?
Rsum ; Rflexion
UML Notation standardise pour la ralisation de modles. Processus Enchainement des tapes et gestion du dveloppement. Expression des besoins et analyse sont des activits indispensables avant la conception et le codage.
Introduction aux processus unifis (UP)

Objectifs
Dcrire les concepts fondamentaux des processus de dveloppement unifis Positionner l'expression des besoins et l'analyse dans ce type de processus Comprendre l'intrt d'UML dans ce cadre.

Histoire et motifs
Le processus unifi (UP) est rapidement devenu le standard de fait du processus de dveloppement du logiciel industriel Nous sommes un moment particulier dans l'histoire des mthodes de dveloppement logiciel.

Pourquoi une telle acceptation ?
UP combine la plupart des meilleurs pratiques modernes UP vient de ceux qui sont perus comme les meilleurs experts

Grady Booch, Ivar Jacobson, Jim Rumbaugh, Philippe Kruchten

Pourquoi une telle acceptation ?
UP est cohrent et bien document :

Livres, Outils.
UP est flexible :
On peut ajouter/enlever des lments

Inconvnients du cycle en cascade
Suppose que nous pouvons dfinir tous les besoins ds le dbut du projet. Combat le changement par un effort d'avoir bon ds le dpart, plutt que de considrer la gestion du changement comme activit de base du processus.

Inconvnients du cycle en cascade (suite)
Est focalis sur les documents et les runions Retarde la rsolution des risques (ex : intgration) Amne des conflits entre les diffrentes parties :
Manque de clart dans la dfinition des exigences

UP les ides cls
Dveloppement itratif Centr sur l'architecture Pilot par les risques Gestion des exigences

UP les phases
Inception :
tudes de faisabilit du projet (Macro estimation des besoins) Dfinir la vision du produit et business case

UP les phases
laboration

Construire l'architecture de base et dfinir la plupart des besoins Exigences dtailles Prototype dtaill Dtail des uses cases Diagrammes de classes, squence, ...

UP les phases
Construction
Construire les fonctionnalits au dessus de l'architecture de base et prparer en vue de dploiement.
Transition
Tester une version beta et dployer.

Identification des acteurs et cas d'utilisation

Objectifs
Identifier les acteurs d'un systme Identifier les cas d'utilisation d'un systme Construire le diagramme de cas d'utilisation
Pr-requis : cahier des charges !
Positionnement de la phase
Au dmarrage d'un projet (ou d'une itration)
Le cahier des charges est souvent insuffisant Les besoins et les contraintes sont parfois mal exprims

Positionnement de la phase
Les objectifs de l'analyse des besoins :
De complter et /ou de reformuler le cahier des charges De dterminer les frontires du systme D'aider au dimensionnement du projet.

Porte et contenu du modle des besoins
Les diagrammes UML permettent :
De dterminer les frontires du systme De reprsenter les interactions utilisateurs / systme De structurer les besoins fonctionnels en ensembles cohrents.

Le niveau de dtail obtenu permet :
De comprendre le fonctionnement du systme en vue boite noire De dmarrer l'activit d'analyse.

Des reprsentations complmentaires doivent parfois tres ajouts :
Liste dtaille des fonctions du systme Maquette d'crans

Participants au modle des besoins
Le modle des besoins est sous la responsabilit des :

Experts mtiers (75%) Analystes (25%)

Les experts mtier sont les fournisseurs d'information
Ont l'expertise du domaine, sont les garants du bienfond du modle Ont la responsabilit de la description textuelle des cas d'utilisation

Les analystes ont pour rle de modliser les informations fournies par les experts mtier avec les concepts et les diagrammes UML appropris :
Doivent poser des questions aux experts mtier pour complter et formaliser l'expression de besoin (diagrammes dynamiques, etc).

Le contexte du systme
Le contexte reprsente l'environnement du systme :

Qui utilise le systme ? Quelles sont les interactions Utilisateurs / Systme ? Quels services le systme doit-il fournir ?

Dfinition : acteur
Un acteur est une entit externe au systme :

Qui attend un ou plusieurs services du systme A qui le systme fournit une interface d'accs Qui interagit avec le systme par l'envoi / rception des messages C'est une personne ou un autre systme informatique

Dfinition : acteur
Les acteurs sont dcrits par une abstraction ne retenant que :

Le rle qu'ils jouent vis vis du systme Leurs relations avec les cas d'utilisation.

Exemple : la station de travail
Un grand nombre de personnes physiques peuvent se connecter la station, mais il n'y a que deux rles potentiels vis vis du systme : utilisateur et administrateur.

Une mme personne physique peut se connecter successivement comme utilisateur puis comme administrateur. Plusieurs personnes physiques diffrentes peuvent se connecter en tant qu'utilisateur.

Un acteur peut jouer diffrents rles selon le le cas d'utilisation ou la fonctionnalit qu'il demande au systme.

Modlisation des acteurs
Une classe d'acteur est un type particulier :
actor est un mot-cl d'UML
Deux reprsentations graphiques :

Utilisez le stick man pour les acteurs humains Utilisez le rectangle avec le mot-cl pour les autres.

Dfinition : Cas d'utilisation
Un cas d'utilisation modlise un service rendu par le systme :

Il exprime les interactions acteur / systme Il apporte une valeur ajoute notable aux acteurs concerns Il correspond une intention complte dans l'utilisation du systme par les acteurs concerns. La faon dont le systme ralise les services est masque
Dfinition : Cas d'utilisation
Le droulement d'un cas d'utilisation est contrl par les acteurs :
Un acteur dmarre le cas d'utilisation par un vnement dclencheur Plusieurs acteurs peuvent participer au mme cas d'utilisation

Des acteurs secondaires peuvent tre sollicits L'acteur principal est le bnficiaire du cas d'utilisation
Diagramme de cas d'utilisation

Acteurs Formule 1
Conduire Ravitailler Envoyer information
Frontire du systme
Pilote actor systme de tlmsure
Mcanicien
Rparer Association
Cas d'utilisation
Acteurs et cas d'utilisation

Acteurs : mcanicien, pilote, systme de tlmaintenance. Cas d'utilisation : Ravitailler
Le cas d'utilisation commence lorsque le mcanicien ouvre le bouchon du rservoir. Le mcanicien connecte l'embout du tuyau Le systme de tlmesure est inform du dbut de ravitaillement Le mcanicien ouvre la vanne et remplit le rservoir de carburant. Pendant que le rservoir se remplit, la jauge indique le niveau de carburant au pilote. Lorsque le rservoir est plein, le mcanicien referme la vanne et retire l'embout du tuyau. Le systme est inform de la fin du ravitaillement
Le cas d'utilisation se termine lorsque le mcanicien referme le rservoir.
Acteurs et cas d'utilisation

Dans un cas d'utilisation, on a :
Pr-condition : exemple

Voiture arrte Station pompe oprationnelle
Ce qui est important dans un UC :

L'vnement qui dclenche le dbut du UC L'vnement qui indique la fin du UC

Comment identifier les acteurs ?
Rechercher les entits externes qui communiquent avec le systme : Oprateurs humains Autres systmes connects
liminer les moyens d'interface au profit des vrais acteurs

Comment identifier les cas d'utilisation ?
Pour chaque acteur identifi :

Rechercher les diffrentes faons dont il utilise le systme Rechercher dans le cahier des charges les services attendus du systme
Pour chaque cas d'utilisation :
Contrler qu'il fournit une valeur ajoute notable aux acteurs Contrler qu'un vnement externe en dclenche l'excution

Comment identifier les cas d'utilisation ?
Uniformiser le niveau d'abstraction des cas d'utilisation
Un cas d'utilisation doit reprsenter une tche mtier pour les acteurs Un cas d'utilisation n'est pas une fonction atomique :
...ensemble de squences d'actions...
Exercice
Le guichet Automatique de Banque (GAB) offre les services suivants :
Distribution d'argent tout porteur de carte de crdit (visa ou carte de la banque) Consultation de solde de compte, dpt en numraire et dpt de chque pour les client de la banque porteur d'une carte de crdit de la banque. Toutes les transactions sont scurises (autorisation) Il est parfois ncessaire de recharger le distributeur...
N'oubliez pas !

Exercice

Identifiez les acteurs du GAB Trouvez des noms de rle vocateurs Dcrivez chaque rle en une phrase Trouvez des noms de cas d'utilisation vocateurs du service rendu Spcifiez le ou les acteurs lis chaque cas d'utilisation Dcrivez la valeur ajoute en quelques phrases.
Identifiez les cas d'utilisation du GAB
Regroupement en packages
La structuration du modle des besoins consiste regrouper les cas d'utilisation en packages Package = mcanisme gnral pour regrouper des lments UML et structurer les modles Il peut contenir :
Des lments UML : cas d'utilisation, classes, composants, etc. Des diagrammes

Plusieurs critres de regroupement sont possibles : Par domaine d'expertise mtier Par acteurs concerns Par incrment raliser
Exemple du GAB Retrait Visa Porteur de CB Visa Maintenance Oprateur de maintenance Packages

Description des cas d'utilisation

Objectifs :
Savoir dcrire la description textuelle dtaille d'un cas d'utilisation Apprhender la taille d'un cas d'utilisation Distinguer cas d'utilisation essentiels et rels
Un cas d'utilisation contient potentiellement plusieurs scnarios
Un scnario correspond l'excution d'un ou plusieurs enchanements joignant le dbut du cas d'utilisation une fin normale ou non. Les enchanement parcourus lors d'un scnario sont slectionns par :

Les messages envoys par les acteurs L'tat et les actions du systme.

Pour un cas d'utilisation = n scnariis Dbut Fin normal Exception
Enchanements = squence d'actions

Description textuelle
La fiche de description textuelle n'est pas normalise en UML Nous prconisons pour notre part la structuration suivante :
Sommaire d'identification (obligatoire) inclut titre, rsum, version, responsable, acteur,... Description des enchanements (obligatoire) dcrit les enchanement nominaux, alternatifs, les exceptions mais aussi les pr-conditions et les post-conditions

Contraintes IHM (optionnel)
Ajoute les contraintes d'interface homme-machine : ce qu'il est ncessaire de montrer, en jonction avec les oprations que l'utilisateur peut dclencher...
Contraintes non-fonctionnelles (optionnel)
Ajoute les informations suivantes : frquence, volumtrie, disponibilit, fiabilit, intgrit, confidentialit, performance, concurrence, etc.

Titre : commence par un verbe Rsum : une ou plusieurs phrases dcrivant le cas d'utilisation Acteurs : l'acteur dclenchant et les acteurs participants Pr-conditions : Conditions d'environnement. Ce qui doit tre vrai au niveau du systme pour que le cas d'utilisation puisse dmarrer Description des enchanements : le cas d'utilisation commence lorsque l'acteur X envoie le message Y au systme [.....] Squences d'intractions

Post-conditions : Ce qui a chang dans le systme de faon visible la fin normale du cas d'utilisation. Autre sections : pour spcifier des contraintes ou des exigences non-fonctionnelles.

Description des enchanements
Un cas d'utilisation spcifie plusieurs enchanements d'vnements Un enchanement nominal Des enchanements alternatif(s) Des enchanements d'exception

Description des enchanements
Lorsqu'un enchanement nominal ou alternatif est excut, les post-conditions sont atteintes Lorsqu'un enchanement d'exception est excut, les postconditions ne sont pas atteintes

Que faut-il dcrire ?
Insister sur les vnements entre les acteurs et le systme sans dcomposer le traitement effectu l'intrieur du systme Donner la priorit aux choses que les acteurs peuvent percevoir (vue boite noire du systme)

Que faut-il dcrire ?
Toute discussion sur le traitement interne ou sur les dcisions de conception est possible mais devrait tre faite en en mesurant les consquence Ne pas insister sur les interactions entre acteurs

Niveaux d'abstraction
ESSENTIEL L'essence du processus. Point de vue analyse. Dcrit le processus indpendamment (relativement) de l'environnement matriel ou logiciel. REEL Processus concret. Point de vue conception. Dcrit le processus en terme de solution : crans utilisateur, saisie de donnes, etc.

Comparaison essentiel / rel
ESSENTIEL Le bibliothcaire enregistre le numro d'identification. REEL Le bibliothcaire utilise le lecteur de code barre pour scanner le numro d'identification qui est transmis l'ordinateur.

Comparaison essentiel / rel
ESSENTIEL Le dtenteur d'un compte s'identifie auprs d'un distributeur de billets de banque. REEL Le dtenteur d'un compte insre sa carte dans le lecteur de carte du distributeur de billets. Il lui est demand d'entrer son code personnel (voir cran 4), ce qu'il fait l'aide d'un clavier numrique.

Exercice
Dcrivez la partie obligatoire du cas d'utilisation : Retirez de l'argent (avec carte visa) Utilisez le type essentiel

Rsum; rflexion
Cas d'utilisation
Ce sont des descriptions narratives dont le plan-type n'est pas standardis Un cas d'utilisation contient potentiellement plusieurs scnarios Il est utile de distinguer les niveaux essentiel et rel Voyez vous comment utiliser les cas d'utilisation dans votre travail ?
Rflexion

Diagrammes dynamiques pour les cas d'utilisation

Objectifs
Savoir crer des diagrammes de squence de niveau systme Utiliser les diagrammes d'activit pour la description de cas d'utilisation complexes

Pourquoi choisir plus de formalisation ?
L'objectif des cas d'utilisation est favoriser le dialogue avec les utilisateurs La description textuelle peut devenir complexe, ambigu, difficile matriser

Pourquoi choisir plus de formalisation ?
Une description graphique peut apporter une vision plus synthtique :
condition de prsenter et d'expliquer les diagrammes au cours de runions avec les utilisateurs Si l'on se limite dcrire le systme avec une vision boite noire Si l'on garde toujours la lisibilit comme objectif prioritaire

Diagrammes dynamiques intressants
Diagramme d'activits Texte Cas d'utilisation
activit activit activit
Diagramme de collaboration Scnario systme
Diagramme d'tats
tat tat
tat

Diagrammes dynamiques intressants
On fait un diagramme d'activit par scnario ou par cas d'utilisation On fait un diagramme de squence par scnario Le diagramme de collaboration reprsente l'espace Le diagramme de squence reprsente le temps Le diagramme d'tat permet de dtecter les tats alatoires

Diagramme de squence
Le diagramme de squence systme illustre la succession temporelle des vnements du systme causs par des messages venant des acteurs Il peut tre utilis en considrant le systme comme une bote noire, et en montrant les interactions avec les acteurs, dans le cadre d'un scnario d'un cas d'utilisation particulier

Acteur principal gauche Acteurs secondaires ventuels droite du systme
Il est en gnral trs bien accept par les experts mtier
Reprsentation graphique
c:client
de l'agence y : GAB Introduction carte Demande code Code (valeur)
Axe du temps

Si accord : Systme d'autorisation VISA
Demande montant Montant (somme) Mise disposition billets Billets rcuprs
Demande autorisation (carte) Accord (numro autorisation)
Diagramme de squence systme
Nommez les messages venant des acteurs avec des termes de niveau utilisateur, non en terme technologique
Idem distinction essentiel / rel
Assurez la cohrence entre la description textuelle du cas d'utilisation et le diagramme de squence systme
Diagramme de squence systme

c:client
1. le client introduit sa carte Visa dans le lecteur de cartes du GAB 2. Le GAB demande au client de saisir son code d'identification

de l'agence y : GAB Introduction carte Demande code
Reprsentation graphique enrichie

c:client
de l'agence y : GAB Introduction carte Demande code
Axe du temps

Voir E1 : Carte invalide : Systme d'autorisation VISA
Vrification carte Code (valeur)
Vrification code Demande autorisation (carte) Accord (numro autorisation)
Diagramme d'activit
Un diagramme d'activit reprsente les tapes d'une procdure C'est un graphe orient d'activits et de transition
Les transitions sont franchies lors de la fin des activits Des tapes peuvent tre ralises en parallle ou en squence
Reprsentation graphique du diagramme d'activit
Quel type de description choisir ?
Pour reprsenter les cas d'utilisation
La description textuelle est prioritaire
Comprise par les utilisateurs, mais sujette des interprtations Compris par les utilisateurs
Le diagramme d'activit modlise bien un droulement procdural
Le diagramme d'tat modlise mieux un droulement vnementiel
Plus complexe comprendre pour les utilisateurs
Quel type de description choisir ?
Pour reprsenter scnarios
Le diagramme de squence systme est idal
lisible par les utilisateurs Trs visuel
Rsum ; rflexion
La description textuelle des cas d'utilisation peut tre complte par des diagrammes dynamiques, principalement :
Des diagrammes de squence de niveau systme pour les scnarios les plus intressants Un diagramme d'activit par cas d'utilisation

Relations entre cas d'utilisation

Objectifs
Savoir relier les cas d'utilisation les uns aux autres avec des relations

D'inclusion include D'extension extend Et de gnralisation-spcialisation

Pourquoi relier les cas d'utilisation ?
Les cas d'utilisation peuvent tre organiss et relis afin de factoriser et simplifier leurs description textuelle ou graphique UML dfinit trois type de relations standardises entre cas d'utilisation :

Une dpendance d'inclusion Une dpendance d'extension Une relation de gnralisation / spcialisation

Inclusion
Le cas de base en incorpore explicitement un autre, un endroit spcifi dans ses enchanements. Le cas d'utilisation inclus n'est jamais excut seul, mais seulement en tant que partie d'un cas d'utilisation de base plus vaste. On utilise cette relation pour viter de dcrire plusieurs fois le mme enchanement en factorisant le comportement commun dans un cas d'utilisation part.

Inclusion : exemple
Pour tous les cas d'utilisation, l'acteur principal doit tre authentifi. Le processus d'authentification implique un flot d'vnements entre l'acteur et le systme : saisie d'un login, puis d'un mot de passe, avec les diffrents cas d'erreur possibles.
Dposer de l'argent
include include
Retirer de l'argent
Cas d'utilisation de base : source Cas d'utilisation inclus : cible
Authentification client
include
Consulter solde

Extension
Le cas de base en incorpore implicitement un autre, un endroit spcifi indirectement dans celui qui tend. Le cas de base peut fonctionner seul, mais peut aussi tre complt par un autre, sous certaines conditions, et uniquement certains points particuliers de son flot d'vnements appels points d'extension. On utilise principalement cette relation pour sparer le comportement optionnel (les variantes) du comportement obligatoire. Attention au sens des flches de dpendances include / extend !

Extension : exemple
Dans le cas d'utilisation Retirer de l'argent, le client peut avoir envie de consulter son solde avant de choisir le montant de retrait. Il peut galement se connecter sur le GAB uniquement pour consulter son solde.
Retirer de l'argent
extend (Vrification montant)
Consulter solde
Point d'extension : Vrification montant.

Gnralisation / spcialisation
Les cas d'utilisation peuvent tre hirarchiss par gnralisation
Les cas d'utilisation descendants hritent de la smantique des parents Les descendants peuvent ajouter ou modifier les interactions hrites
On utilise cette relation pour formaliser des variations importantes sur le mme cas d'utilisation

Gnralisation / spcialisation : exemple
Dposer de l'argent
Cas d'utilisation parent Abstrait en italique
Dposer du numraire
is a (Vrification montant)
Dposer des chques
Cas d'utilisation concret

Classification des acteurs
Les acteurs aussi peuvent tre hirarchiss par gnralisation

L'acteur parent dfini un rle commun Les descendants hritent des associations avec les cas d'utilisation
Identification
Acteur parent : abstrait en italique Rle gnral
Acteurs descendants (concret) Rle A Rle B
Cas d'utilisation X

Rsum ; rflexion
Les trois relations possibles entre cas d'utilisation sont :

Dpendance d'inclusion include Dpendance d'extension extend Gnralisation-spcialisation Quel intrt ? Quels risques voyez-vous ?
Rflexion



Cours Uml - Partie 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cours Uml - Partie 1

Uploaded by

Copyright:

Available Formats

UML Analyse et conception orientes objets

UML Unified Modeling Language

Espace du problme = analyse

Espace de la solution = modlisation

graphiques textes standard

UML est un langage de modlisation pour :

UML est un langage usage gnral, quelque soit :

UML est un langage public et standardis

Ce cours s'appuie sur un processus appel Processus Unifi ( vous de piocher :)

Des besoins mal spcifis peuvent conduire des systmes :

Si l'analyse du systme est saute ou nglige

Quelle est votre exprience avec l'analyse (avant la conception) ?

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Grady Booch, Ivar Jacobson, Jim Rumbaugh, Philippe Kruchten

Introduction aux processus unifis (UP)

UP est cohrent et bien document :

On peut ajouter/enlever des lments

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Manque de clart dans la dfinition des exigences

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Introduction aux processus unifis (UP)

Construire les fonctionnalits au dessus de l'architecture de base et prparer en vue de dploiement.

Tester une version beta et dployer.

UML Unified Modeling Language

Identification des acteurs et cas d'utilisation

Pr-requis : cahier des charges !

Identification des acteurs et cas d'utilisation

Au dmarrage d'un projet (ou d'une itration)

Identification des acteurs et cas d'utilisation

Les objectifs de l'analyse des besoins :

Identification des acteurs et cas d'utilisation

Les diagrammes UML permettent :

Identification des acteurs et cas d'utilisation

Le niveau de dtail obtenu permet :

De comprendre le fonctionnement du systme en vue boite noire De dmarrer l'activit d'analyse.

Identification des acteurs et cas d'utilisation

Des reprsentations complmentaires doivent parfois tres ajouts :

Liste dtaille des fonctions du systme Maquette d'crans

Identification des acteurs et cas d'utilisation

Le modle des besoins est sous la responsabilit des :

Experts mtiers (75%) Analystes (25%)

Identification des acteurs et cas d'utilisation

Les experts mtier sont les fournisseurs d'information

Identification des acteurs et cas d'utilisation

Identification des acteurs et cas d'utilisation

Le contexte reprsente l'environnement du systme :

Identification des acteurs et cas d'utilisation

Un acteur est une entit externe au systme :

Identification des acteurs et cas d'utilisation

Les acteurs sont dcrits par une abstraction ne retenant que :

Identification des acteurs et cas d'utilisation

Identification des acteurs et cas d'utilisation

Identification des acteurs et cas d'utilisation

Identification des acteurs et cas d'utilisation

Une classe d'acteur est un type particulier :

actor est un mot-cl d'UML

Deux reprsentations graphiques :

Identification des acteurs et cas d'utilisation

Un cas d'utilisation modlise un service rendu par le systme :