Vous êtes sur la page 1sur 98

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

Prsentation du cours
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

Prsentation du cours
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

Prsentation du cours
Ce qu'est et n'est pas UML UML = Langage de modlisation

graphiques textes standard

UML Mthode

Prsentation du cours
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

Prsentation du cours
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.

Prsentation du cours
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

Prsentation du cours
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 :)

Prsentation du cours
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.

Prsentation du cours
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) ?

Prsentation du cours
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.

Introduction aux processus unifis (UP)


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.

Introduction aux processus unifis (UP)


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

Introduction aux processus unifis (UP)


Pourquoi une telle acceptation ?

UP est cohrent et bien document :


Livres, Outils.

UP est flexible :

On peut ajouter/enlever des lments

Introduction aux processus unifis (UP)


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.

Introduction aux processus unifis (UP)


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

Introduction aux processus unifis (UP)


UP les ides cls

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

Introduction aux processus unifis (UP)


UP les phases

Inception :

tudes de faisabilit du projet (Macro estimation des besoins) Dfinir la vision du produit et business case

Introduction aux processus unifis (UP)


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

Introduction aux processus unifis (UP)


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.

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

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

Identification des acteurs et cas d'utilisation

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

Identification des acteurs et cas d'utilisation


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.

Identification des acteurs et cas d'utilisation


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.

Identification des acteurs et cas d'utilisation


Porte et contenu du modle des besoins

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


Porte et contenu du modle des besoins

Des reprsentations complmentaires doivent parfois tres ajouts :

Liste dtaille des fonctions du systme Maquette d'crans

Identification des acteurs et cas d'utilisation


Participants au modle des besoins

Le modle des besoins est sous la responsabilit des :


Experts mtiers (75%) Analystes (25%)

Identification des acteurs et cas d'utilisation


Participants au modle des besoins

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

Identification des acteurs et cas d'utilisation


Participants au modle des besoins

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

Identification des acteurs et cas d'utilisation


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 ?

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et cas d'utilisation


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.

Identification des acteurs et 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.

Identification des acteurs et cas d'utilisation


Exemple : la station de travail

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

Identification des acteurs et cas d'utilisation


Exemple : la station de travail

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

Identification des acteurs et cas d'utilisation


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.

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et 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

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et cas d'utilisation

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

Identification des acteurs et cas d'utilisation


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

Identification des acteurs et cas d'utilisation

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

Regroupement en packages

Identification des acteurs et cas d'utilisation


Plusieurs critres de regroupement sont possibles : Par domaine d'expertise mtier Par acteurs concerns Par incrment raliser

Regroupement en packages

Identification des acteurs et cas d'utilisation

Exemple du GAB Retrait Visa Porteur de CB Visa Maintenance Oprateur de maintenance Packages

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

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

Description des cas d'utilisation

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.

Description des cas d'utilisation


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

Enchanements = squence d'actions

Description des cas d'utilisation


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

Description des cas d'utilisation


Description textuelle

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.

Description des cas d'utilisation


Description textuelle

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

Description des cas d'utilisation


Description textuelle

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 cas d'utilisation


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 cas d'utilisation


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

Description des cas d'utilisation


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)

Description des cas d'utilisation


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

Description des cas d'utilisation


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.

Description des cas d'utilisation


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.

Description des cas d'utilisation


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.

Description des cas d'utilisation


Exercice

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

Description des cas d'utilisation


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

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

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

Diagrammes dynamiques pour les cas d'utilisation


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

Diagrammes dynamiques pour les cas d'utilisation


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 pour les cas d'utilisation


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 pour les cas d'utilisation


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

Diagrammes dynamiques pour les cas d'utilisation


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

Diagrammes dynamiques pour les cas d'utilisation


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

Diagrammes dynamiques pour les cas d'utilisation

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

Diagrammes dynamiques pour les cas d'utilisation


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

Diagrammes dynamiques pour les cas d'utilisation


Voir E1 : Carte invalide : Systme d'autorisation VISA

Vrification carte Code (valeur)

Vrification code Demande autorisation (carte) Accord (numro autorisation)

Diagramme d'activit

Diagrammes dynamiques pour les cas d'utilisation

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

Diagrammes dynamiques pour les cas d'utilisation

Quel type de description choisir ?

Diagrammes dynamiques pour les cas d'utilisation

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 ?

Diagrammes dynamiques pour les cas d'utilisation

Pour reprsenter scnarios

Le diagramme de squence systme est idal

lisible par les utilisateurs Trs visuel

Rsum ; rflexion

Diagrammes dynamiques pour les cas d'utilisation

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

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

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

Relations entre cas d'utilisation


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

Relations entre cas d'utilisation


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.

Relations entre cas d'utilisation


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

Relations entre cas d'utilisation


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 !

Relations entre cas d'utilisation


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.

Relations entre cas d'utilisation


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

Relations entre 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

Relations entre cas d'utilisation


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

Relations entre cas d'utilisation


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

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