Analyse et conception
oriente objet
FORMATRICE : [Link]
Objectifs du module
Dfinir
les besoins en ce qui a trait au
dveloppement orient objet d'une application
Raliser les diffrents diagrammes d'analyse et de
conception de l'application
Exploiter un outil de modlisation pour reprsenter
les diffrents diagrammes raliss
Plan
Dmarche danalyse et conception oriente
objet
Dfinition des besoins
Analyse
Conception
Outils de modlisation
Dmarche danalyse OO
Objectifs globaux:
Analyser et concevoir une application objet
Avoir une application qui puisse vivre et qui enrichisse
la base de savoir-faire de lentreprise (dveloppement
de nouveaux applicatifs en sappuyant sur des objets
mtiers dj dvelopps)
La rutilisabilit est un des soucis principaux pour
pouvoir rduire le cot des logiciels et augmenter la
puissance de dveloppement des programmeurs (viter
le gaspillage)
Dmarche danalyse OO
UML?
Pas une mthode, ni un outil particulier
UML est un Langage de Modlisation Unifi
Langage
: support de communication, avec une
grammaire comme tout langage, il permet :
de communiquer, de se faire comprendre
de rflchir et dvelopper sa pense
Modlisation : description dun systme et abstraction
Unifi : normalis par l OMG (Object Management
Group)
Dmarche danalyse OO
A quoi a sert?
Communication
Se faire comprendre dutilisateurs non-informaticiens
Progresser et se mettre daccord ensemble
Dialoguer au sein de lquipe projet
Laisser une trace pour le futur
Rflexion
: modlisation du systme
Sapplique en particulier aux systmes informatiques et
aux dveloppements orients objets
Oriente la dmarche danalyse et conception
Dmarche danalyse OO
Avantages dUML:
Un
langage clair
Rutilisation de concepts existants
Certains schmas accessibles des non informaticiens
Un schma parle plus quun long texte...
Une
utilisation simple
Une
modlisation plus complte que Merise et
objet
Donnes + relations + actions + squences +
interactions
Dmarche danalyse OO
tapes suivre:
Lister lensemble des exigences du client issues du
cahier des charges, ou issu dune dmarche pralable de
collecte dinformation
Dfinir les cas dutilisation et construire le diagramme
de uses cases
Faire un diagramme de squence par scnario
correspondant au systme dvelopper (boite noire)
Faire un diagramme de classe par use case: le
diagramme de classe final sera la superposition de ces
diagrammes de classe
Dmarche danalyse OO
Raliser un contrat pour chaque opration du systme,
sous forme dun diagramme de squence bote blanche
o les objets changent des messages
Raliser, partir des diagrammes de classe et des
contrats, les diagrammes de collaboration dobjets
Construire en parallle les diagrammes dtat des
objets les plus complexes, ainsi nous dtecterons des
mthodes internes ces objets
Dfinir enfin le diagramme de classe de conception
(remettre en cause le diagramme de classe prtabli)
Dmarche danalyse OO
Processus simplifi:
Plan
Dmarche danalyse et conception oriente
objet
Dfinition des besoins
Analyse
Conception
Outils de modlisation
Dfinition des besoins
La dfinition des besoins dmarre avec le dbut du
projet : collecte des informations pour dfinir le
besoin du client
Bien souvent, la matrise douvrage et les utilisateurs
ne sont pas des informaticiens : il leur faut donc un
moyen simple dexprimer leurs besoins
Cest prcisment le rle des diagrammes de cas
dutilisation qui permettent de recueillir,
danalyser et dorganiser les besoins, et de recenser
les grandes fonctionnalits du systme
Dfinition des besoins
Uses Cases
lments des uses cases:
Acteur: cest une entit externe qui interagit avec un
systme
Personne
Logiciel
Matriel
.
Un acteur reprsente un rle jou par un utilisateur qui
interagit avec le systme
La mme personne physique peut jouer le rle de
plusieurs acteurs (vendeur, client)
Plusieurs personnes peuvent jouer le mme rle, et
donc agir comme le mme acteur (tous les clients)
Dfinition des besoins
Uses Cases
Cas dutilisation: reprsente le dialogue entre lacteur
et le systme de manire abstraite
Les cas dutilisation permettent de dcrire les
fonctionnalits attendues du systme de point de vue
des acteurs, mais attention car fonctionnalits se
transforme souvent en fonctions
Nom du cas
Dfinition des besoins
Uses Cases
Dtermination des Cas dutilisation
Quelles sont les tches de lacteur ?
Quelles informations lacteur doit-il crer, sauvegarder,
modifier, dtruire ou simplement lire?
Lacteur devra-t-il informer le systme de changements
externes?
Le systme devra-t-il informer lacteur de conditions
internes au systme
Dfinition des besoins
Uses Cases
Dfinition des besoins
Uses Cases
Un cas dutilisation est donc compos des lments
suivants :
Un nom : Utiliser un verbe linfinitif
Une description rsume permettant de comprendre
lintention principale du cas dutilisation
Des acteurs dclencheurs : ceux qui sont lorigine
du cas dutilisation
Des acteurs secondaires : ceux qui ne font que
participer la ralisation du cas dutilisation
Dfinition des besoins
Uses Cases
Des pr-conditions qui dcrivent dans quel tat doit
tre le systme (lapplication) avant que ce cas
dutilisation puisse tre dclench
Des post-conditions succs qui dcrivent ltat du
systme lissue des diffrents scnarii
Des informations sur lutilisation du cas
dutilisation comme : le nombre de personnes
excutant ce cas dutilisation dans une journe
La priorit qui permet de dfinir
dveloppement des diffrents use-case
lordre
de
Dfinition des besoins
Uses Cases
Relations entre cas et utilisateurs
Relation dassociation: chemin de communication
entre un acteur et un cas dutilisation est reprsent par
un trait continu
Systme de gestion commerciale
Grer achats
commercial
Dfinition des besoins
Uses Cases
Relations entre acteurs
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
Dfinition des besoins
Uses Cases
Relations entre cas dutilisation
Inclusion: Le comportement de B est obligatoire pour
raliser le comportement de A
A
<<include>>
Dfinition des besoins
Uses Cases
Extension: Le comportement de A est optionnel et ne
se dclenche que par une condition dans le
comportement de B
A
<<extends>>
Dfinition des besoins
Uses Cases
Gnralisation/spcialisation : Le comportement
de C et B hrite du comportement de A et spcialise le
comportement de A
Exercice
Uses Cases
Dans un magasin, le processus de vente est le
suivant :
Le client entre, passe dans les rayons, demande
ventuellement des renseignements ou procde
des essais, prend des articles (si le stock est
suffisant), passe la caisse o il rgle ses achats
(avec tout moyen de paiement accept). Il peut
ventuellement bnficier dune rduction.
Travail Faire :
Modliser cette situation par un diagramme de
cas dutilisation
Dfinition des besoins
TD n 1
Dfinition des besoins
Diagramme de contexte
Diagramme de contexte statique
Permet de dcrire les acteurs du systme
Spcifie le nombre dinstances dacteurs relies au
systme un moment donn
Ce diagramme est un diagramme de classe UML ne
faisant intervenir que les acteurs et le systme
Dfinition des besoins
Diagramme de contexte
Diagramme de contexte statique
Dfinition des besoins
Diagramme de contexte
Diagramme de contexte dynamique
Reprsente de faon synthtique les messages entre
le systme et les acteurs identifis en utilisant les
rgles suivantes:
Le systme est lobjet principal
Il est entour dacteurs
Des liens relient le systme aux acteurs : sur chaque
lien sont montrs les messages en entre et en
sortie du systme
Dfinition des besoins
Diagramme de contexte
Diagramme de contexte dynamique
Exercice
Diagramme de contexte
Modliser
la situation du magasin du prt
porter par un diagramme de contexte -statique
puis dynamique-
(Le client entre, passe dans les rayons, demande
ventuellement des renseignements ou procde
des essais, prend des articles (si le stock est
suffisant), passe la caisse o il rgle ses achats
(avec tout moyen de paiement accept). Il peut
ventuellement bnficier dune rduction)
Plan
Dmarche danalyse et conception oriente
objet
Dfinition des besoins
Analyse
Conception
Outils de modlisation
