Vous êtes sur la page 1sur 43

ISTA HAY RYAD 2011/2012

ANALYSE ET CONCEPTION ORIENTEE OBJET

Dfinir les besoins pour une solution logicielle

Ralis par : BOUROUS Imane

Dterminer les exigences fonctionnelles


En ingnierie, et plus particulirement dans les

procdures d'appel d'offres publiques et prives, les exigences sont l'expression d'un besoin document sur ce qu'un produit ou un service particuliers devraient tre ou faire. Elles sont le plus souvent utilises dans un sens formel dans l'ingnierie des systmes et dans l'ingnierie logicielle.

La phase exigence
La phase de dveloppement des exigences peut avoir t prcde par une tude de faisabilit, ou une phase d'analyse conceptuelle du projet. La phase d'exigences peut tre dcompose en : Mettre jour les exigences: rassembler les exigences des parties prenantes; Analyser : vrifier la cohrence et l'exhaustivit ; Dfinir: crire les exigences sous une forme aisment comprhensible pour les utilisateurs et les dveloppeurs ; Spcifier: crer une interaction initiale entre les exigences et la conception.

Exigences produit & exigences de processus


Les projets sont soumis trois sortes d'exigences : Les exigences mtier qui dcrivent le quoi dans les termes du

mtier. Elles dcrivent ce qui doit tre fourni ou ralis pour produire de la valeur. Les exigences produit qui dcrivent le produit ou le systme un haut niveau. Elles rpondent aux exigences mtier et sont couramment formules comme les fonctionnalits que le systme doit raliser. On les appelle galement exigences fonctionnelles ou spcifications fonctionnelles. Les exigences de processus qui dcrivent le comment. Ces exigences prescrivent les processus que l'on doit suivre et les contraintes auxquelles on doit se conformer pour la ralisation du systme. Dans ce cas, on trouve par exemple des exigences de scurit, d'assurance qualit, ou de management.

Processus de dveloppement des exigences


Rdaction des exigences Les exigences doivent tre crites de telle manire qu'elles orientent la cration et la modification d'un systme selon les rgles mtier (ou rgles de gestion) appropries au contexte et au domaine et dans lequel le systme doit tre utilis. Les systmes doivent normalement se conformer au domaine d'activit dans lequel ils sont exploits.

Processus de dveloppement des exigences


Analyse des exigences
Les exigences sont sujettes des problmes d'ambigut,

d'imperfections, et d'incohrence. Des techniques telles qu'une inspection de logiciel rigoureuse ont t prsentes pour aider traiter de tels problmes. Lorsque les ambiguts, les imperfections, et les incohrences sont rsolues dans la phase d'exigences, l'ordre de grandeur du cot de correction est moins lev que lorsque ces mmes problmes se retrouvent dans des tapes ultrieures de dveloppement du produit. L'analyse des exigences s'efforce de rsoudre ces problmes.

Les intervenants dun projet informatique


Plusieurs intervenants participent lanalyse, la conception

et le dveloppement dun projet informatique, parmi lesquels : Le client: Le client est lorganisme auquel est destin le projet, cest celui le donneur dordre et le payeur de la prestation. Le client peut tre une entreprise qui fait appel une SSII pour raliser le projet ou le service de lentreprise qui fait appel la direction informatique Le prestataire Le prestataire est lorganisme qui ralise le projet. Le prestataire peut tre une entreprise externe spcialise (SSII) ou le service informatique de lentreprise.

La Matrise duvre
La Matrise duvre est la responsabilit de lexcution

du projet. Elle reprsente le prestataire tout au long du projet. La Matrise duvre est le garant du respect des engagements pris notamment sur les dlais et les contenues des fournitures. Il assure le pilotage technique du projet, la gestion de lquipe de production laffectation des tches et la mise en uvre des dispositions dassurance qualit.

La matrise douvrage
La matrise douvrage assure la conformit du projet vis--vis de la demande du client. Elle reprsente le client tout au long du projet, elle a pour rle de : Veiller au respect des objectifs gnreux du projet Assurer la conduite gnrale dur projet Grer les enveloppes financires Valider les documents relatifs au projet ainsi que les maquettes ventuellement, prparer et excuter les tests de rception des applications Prononcer les recettes Cest au sein de la matrise douvrage que lon trouve les experts mtier et les groupes de validation Lorsquil existe un service dorganisation dans lentreprise, celle-ci frquemment charg de la matrise douvrage, dfaut elle peut reprsenter les utilisateurs auprs de celle-ci.

Le directeur du projet ou chef de projet


Le Directeur ou chef de projet est le responsable de la mise en

uvre du projet dans le cadre du cahier des charges tabli. Il est charg dtudier les besoins des utilisateurs, de dfinir des solutions adaptes et aprs validation de les mettre en uvre avec les outils informatiques retenus. Il sappuie sur le Groupe de Pilotage et travaille en troite collaboration avec le responsable utilisateur. Il dirigera lquipe affecte au projet. Il veillera au respect des dlais, la qualit du travail et ltablissement des critres de rception du projet. Il a pour rle dassurer la coordination de lensemble des acteurs du projet On dsigne gnralement le matre duvre comme directeur du projet, parfois le matre douvrage.

Le responsable qualit
Le responsable qualit est choisi en commun accord entre le matrise doeuvre et la matrise douvrage .Il a le rle de : Dfinir les dispositions dassurance qualit formalises dans le plan dassurance qualit. Veiller la mise en application de ces dispositions. Dfinir les actions correctives si les dispositions ne sont appliques. Vrifier et rendre compte de la mise en application de ces actions.

Les utilisateurs
Les utilisateurs sont les destinataires finaux du projet. Ils participent au projet sous la responsabilit du matrise douvrage. Le rle des utilisateurs est important en particulier au niveau de : Lexpression des besoins. Les tests de recette. La mise en service du projet.

Les fournisseurs
Un certain nombre dlment indispensable lexcution du projet peuvent tre obtenu auprs des fournisseurs autre que le prestataire. Ces fournisseurs peuvent fournir des matriels, logiciels, des ressources humaines et des services. Il est recommand de dfinir : Les relations contractuelles avec les fournisseurs Lentit qui porte la responsabilit le choix du fournisseur Lentit qui porte la responsabilit du contrle de lexcution du contrat Les dispositions financires associes

La modlisation du systme

Introduction la modlisation
Pour modliser un systme informatique on se sert

dun langage de modlisation. Comme cest souvent le cas en informatique plusieurs choix apparaissent sur le march. Lun deux sest cependant nettement dmarqu depuis les annes 90 : il sagit de UML (Unified Modeling Language) n de la fusion de trois mthodologies de modlisation. UML se dfinit comme un langage de modlisation graphique et textuel destin comprendre et dcrire des besoins, spcifier et documenter des systmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.

UML

UML unifie la fois les notations et les concepts

orients objet. Il ne sagit pas dune simple notation, mais les concepts transmis par un diagramme ont une smantique prcise et sont porteurs de sens au mme titre que les mots dun langage. UML a une dimension symbolique et ouvre une nouvelle voie dchange de visions systmiques prcises. Ce langage est certes issu du dveloppement logiciel mais pourrait tre appliqu toute science fonde sur la description dun systme. Dans limmdiat, UML intresse fortement les spcialistes de lingnierie systme.

Introduction
UML ?
UML = Langage de modlisation

A quoi sert? Dfinir un modle logique sur lequel se fond le projet Types de diagrammes en UML? - Statique ( ce que le systme est) - Dynamique (comment le systme volue) - Fonctionnel (ce que le systme fait)

10/08/2012

17

Introduction
Statique (ce que le systme EST)
diagramme de classes diagramme dobjets diagramme de composants diagramme de dploiement

Dynamique (comment le systme EVOLUE)


diagramme de squence
diagramme de collaboration diagramme dtats-transitions diagramme dactivits

Fonctionnel (ce que le systme FAIT)


diagramme de cas dutilisation

diagramme de collaboration

Plan

Dfinition Diagramme de cas dutilisation


Dfinition Intrt

Elments de base
Acteurs du systme Cas dutilisation

Relations entre lments de base


Entre Cas dutilisation Entre Cas dutilisation et acteurs Entre acteurs
10/08/2012 19

Dfinition Diagramme de cas dutilisation


Expression du comportement du systme (actions et ractions), selon le point de vue de lutilisateur Dcrit le systme et les relations entre le systme et lenvironnement Intrts:
Permettent de dlimiter les frontires du systme Constituent un moyen dexprimer les besoins dun systme Utiliss par les utilisateurs finaux pour exprimer leurs attentes

et leurs besoins Permettent dimpliquer les utilisateurs ds les premiers stades du dveloppement Constituent une base pour les tests fonctionnels
10/08/2012 20

Dfinition Diagramme de cas dutilisation


Cas d'utilisation (principes)
Ce que le systme doit faire (comportement souhait)

Mais pas comment raliser ce

comportement
Pas de dtails de programmation, mise en uvre, etc. Indpendant de la ralisation

Un outil pour communiquer


Utilisateur final / expert du domaine <---> concepteur / dveloppeur
10/08/2012 21

Diagramme de cas dutilisation


Ouvrir la porte Include Dfoncer la porte Policier fermer la porte

Propritaire

10/08/2012

22

Diagramme de cas dutilisation

10/08/2012

23

lments de base
Acteurs du systme
Un acteur reprsente un rle jou par une entit

externe (utilisateur humain, dispositif matriel ou autre systme) qui interagit directement avec le systme tudi.
Un

acteur peut consulter et/ou

modifier

directement ltat du systme, en mettant et/ou en recevant des messages susceptibles dtre porteurs de donnes.
10/08/2012 24

lments de base
Acteurs du systme
Quels sont les utilisateurs qui ont besoins du

systme pour raliser le travail ? Quels sont les utilisateurs qui vont effectuer les fonctions principales du systme ? Quels sont les utilisateurs qui vont excuter les fonctions principales du systme (maintenance et administration) ? Est-ce que le systme interagit avec du matriel ou d'autres logiciels ?
10/08/2012 25

lments de base
Acteurs du systme
Exemple distributeur

10/08/2012

26

lments de base
Cas dutilisation (use case)
Un cas dutilisation (use case) reprsente un ensemble de

squences dactions qui sont ralises par le systme et qui

produisent un rsultat observable intressant pour un


acteur particulier.
Un cas dutilisation modlise un service rendu par le

systme. Il exprime les interactions acteurs/systme et apporte une valeur ajoute notable lacteur concern.
10/08/2012 27

lments de base
Cas dutilisation (use case)

Identification des use cases :


Quelles sont les fonctions demandes par

l'acteur du systme? Le systme mmorise t-il de l'information? Quel acteur crera, lira ou mettra jour l'information ? Le systme doit il informer un acteur extrieur que son tat interne a chang? Y a t-il des vnements externes que le systme doit connatre? Quel acteur informe le systme de ces vnements?
10/08/2012 28

lments de base
Cas dutilisation (use case)
Nom Priorit Descriptio n

Les uses cases peuvent tre structurs.


Acteurs Les uses cases Descriptio peuvent tre organiss en paquetages n des dclencheu besoins rs (packages). Use

case Informati L'ensemble desons sur cases dcrit les objectifs (le but) du use Acteurs lutilisatio secondair n du cas systme. es dutilisati
on Postconditions Scnarii Prconditions

10/08/2012

29

Exercice dapplication
France Tlcom dsire disposer dune plateforme

dachat en ligne ou les clients peuvent consulter ou/et commander les produits qui sont disponibles sur un catalogue. Les administrateurs de FT sont responsables de la mise jour des produits et du traitement des commandes effectus par les clients.

10/08/2012

30

Corrig
Identification des acteurs :

- Administrateur - Client Identification des cas dutilisations : - Consulter le catalogue - Commander un produit - Mettre jour le catalogue - Traiter une commande

10/08/2012

31

Corrig

Commander un produit

Consulter le catalogue

Mettre jour le catalogue

Client

Traiter la commande

Administrateur

10/08/2012

32

Corrig
Description textuelle du cas dutilisation Nom du cas dutilisation : Mettre jour le catalogue Acteurs dclencheurs : Administrateur. Contexte de dclenchement: l'acteur slectionne la mise jour dun catalogue. Pr-conditions : lacteur sest connect au systme et choisit un catalogue Description du UC : permet l'acteur de grer un catalogue savoir : lajout, la modification et la suppression du catalogue. Post-conditions : le catalogue est mise jour. Scnario nominal : 1. Connexion au systme ; 2. Slection dun catalogue 3. Mise jour du catalogue.
10/08/2012 33

Relations entre lments de base


Entre Cas dutilisation
Include
Gnralisation ou spcialisation

Extends

Relations entre use case

10/08/2012

34

Relations entre lments de base


Entre Cas dutilisation
Gnralisation:

Les cas dutilisation descendants hritent de la

description de leur parent commun. Chacun dentre eux peut nanmoins comprendre des interactions spcifiques supplmentaires.
10/08/2012 35

Relations entre lments de base


Entre Cas dutilisation
Include :

Le cas dutilisation contient un autre cas dutilisation

10/08/2012

36

Relations entre lments de base


Entre Cas dutilisation
Extends :

Le cas dutilisation tend (prcise) les objectifs (le

comportement) dun autre cas dutilisation. On dit quun cas dutilisation X tend un cas dutilisation Y lorsque le cas dutilisation X peut tre appel au cours de lexcution du cas dutilisation Y.
10/08/2012 37

Relations entre lments de base


Entre Cas dutilisation et acteurs
Relation dassociation

Une relation dassociation est chemin de communication entre un acteur et un cas dutilisation et est reprsent par un trait continu

10/08/2012

38

Relations entre lments de base


Entre Cas dutilisation et acteurs
Multiplicit: Lorsquun acteur peut interagir plusieurs fois

avec un cas dutilisation, il est possible dajouter une multiplicit sur lassociation du ct du cas dutilisation; Acteur principal: Le cas dutilisation rend service cet acteur. Acteur secondaire : est sollicit pour des informations complmentaires.

10/08/2012

39

Relations entre lments de base


Entre Cas dutilisation et acteurs
La Gnralisation : un acteur A est une gnralisation

dun acteur B si lacteur A peut tre substitu par lacteur B. Dans ce cas, tous les cas dutilisation accessibles A le sont aussi B, mais linverse nest pas vrai.

10/08/2012

40

Remarques
Concernant les relations dans les cas dutilisation
Il est important de noter que lutilisation des relations nest

pas primordiale dans la rdaction des cas dutilisation et donc dans lexpression du besoin.
Ces relations peuvent tre utiles dans certains cas mais une

trop forte focalisation sur leur usage conduit souvent une perte de temps ou un usage fauss, pour une valeur ajoute, au final, relativement faible.

Remarques
Concernant les cas dutilisation

les diagrammes de cas dutilisation ne peuvent tre qualifis de modlisation proprement parler. Dailleurs, de nombreux lments descriptifs sont en langage naturel. De plus, ils ne correspondent pas exactement une approche objet. En effet, capturer les besoins, les dcouvrir, les rfuter, les consolider, etc., correspond plus une analyse fonctionnelle classique.

Conclusion
L'objectif poursuivi par les cas d'utilisation est de

permettre de dcrire, dans des documents lisibles par tous, la finalit des interactions du systme et de ses utilisateurs. Ils ne doivent pas chercher l'exhaustivit, mais clarifier, filtrer et organiser les besoins !
Aprs avoir rdig les cas dutilisation, il faut identifier

des objets, des classes, des donnes et des traitements qui vont permettre au systme de supporter ces cas dutilisation.