Cours Projet de Conception OO - Mouna AYARI

Cours: Projet de Conception Oriente
Objet
Licence Fondamentale en Informatique
Niveau: 3me anne 1er semestre
Institut Suprieur dInformatique et de Mathmatiques de Monastir
Anne universitaire: 2012 - 2013
Mouna AYARI
mouna.ayari@gmail.com
Remarque: Ce document doit tre complt par les notes de cours !

1
Objectifs du cours
Aider les tudiants bien assimiler les principes
fondamentaux de lanalyse et de la conception oriente

objet
Acqurir les comptences ncessaires de modlisation
dun logiciel
g
objet
j laide de la notation UML et traduire
le modle dans un langage Objet
Dvelopper les comptences des tudiants crer des
logiciels bien conus, robustes et rutilisables
Bien assimiler la dmarche de la mthodologie
processus unifi
f et ses drivs
Introduire la conception architecturale, la notion de
composantt ett les
l patrons
t
de
d conception
ti
Plan du cours
Chapitre
Ch it 1:
1 Rappels
R
l sur lles ffondements
d
t d
de b
base d
de
la conception oriente objet dun projet

Chapitre 2: Mthodologies de COO processus
unifi
C
Chapitre
ap t e 3
3: Co
Conception
cept o a
architecturale
c tectu a e
Bibliographie
Pascal Roques,
q
, "les Cahiers du Programmeur
g
UML2
Modliser une application web",Edition EYROLLES,

4me dition, 2008
Pascal Roques, "UML2 par la pratique Etudes de cas et
exercices corrigs",
g
Edition EYROLLES, 5me dition,
2006
Antonio Goncalves
Goncalves, "les
les Cahiers du Programmeur Java
EE5",Edition EYROLLES, Mai 2007
Chapitre 1
Rappels sur les fondements de base de la
conception oriente
objet dun projet
Mouna AYARI

5
Plan du chapitre
Etude pralable de projet

Analyse du systme et spcification des exigences
du projet
Fondements de base de la conception oriente
objet
Modlisation des relations entre les classes
R
Rappel
l sur lles di
diagrammes d
de modlisation
dli ti UML
Chapitre 1
Rappels sur les fondements de base de la conception oriente objet ddun
un projet
1.1. Etude pralable de projet

Mouna AYARI

7
Avant projet
Avant-projet
Ltape davant-projet
j reprsente
ltape initiale de tout projet. Elle est appele galement tape d

tude pralable du projet
Phase dinception du projet
l'ensemble des tapes prparatoires ncessaires au lancement du
projet
Lancer le projet
Ide du projet
Etude pralable du
projet
Abandonner le
projet
p
Avant projet
Avant-projet
Avant-projet
p j
Il s'agit de dfinir prcisment ce que sera le projet afin
d'aboutir la mise au point de documents contractuels (faisant

lieu d'un contrat) permettant d'engager la matrise d'uvre
(responsables de gestion et suivi projet) et la matrise
d'ouvrage
d
ouvrage (responsables des activits techniques du projet)
dans le lancement du projet
Cette p
phase formalise donc la dcision de commencer le
projet.
Etude pralable du projet

Ltude pralable dun projet
j intervient avant la phase
dexpression des besoins

La plupart des projets ncessitent un stade initial au cours
d
duquel
l il ffautt rpondre
d certaines
t i
questions
ti
Quelle est la vision (objectif et contexte) du projet et quelle est
10
son opportunit?
pp
Le projet est-i-il ralisable?
Faut-il construire et/ou acheter ?
Quelle est lestimation grossire du cot: doit-on envisager des
dizaines de milliers, des centaines de milliers ou des millions de
dinars?
Faut-il poursuivre jusqu la ralisation du projet ou renoncer?

A ltape davant-projet
j ou tude pralable du projet,
j il faut
tudier quelques peu les besoins. Mais, cette tape na pas

pour but de dfinir tous les besoins et laborer un plan de
projet
Lide est deffectuer le minimum dinvestigations pour
formuler une opinion
p
rationnelle et jjustifiable de la finalit et
faisabilit du projet et du nouveau systme potentiel associ
Lobjectif de cette phase est de
dcider sil est raisonnable dinvestir dans une tude plus
approfondie (lobjectif de la phase dlaboration du projet)

tablir une vision initiale comme des objectifs du projet
projet, de
dterminer si celui-ci est faisable (tenant compte des ressources
disponibles)
tudier
t di le
l contexte
t t du
d projet
j t ett tablir
t bli ses motivations
ti ti
11

Ltude pralable permet donc d'identifier les conditions de
dveloppement de ces activits :

tude des marchs des produits et services,
Viabilit
Vi bilit ttechnico-conomique
h i
i
d
du projet,
j t
Comptences disponibles/requises,
Outils et moyens
y
de financement de l'activit,,
Impact social
...
12

Etude de march et de lexistant
Ltude pralable consiste principalement recenser
lexistant c'est--dire les solutions informatiques dj mises
en uvre dans lentreprise et recenser les besoins
notamment en termes de fonctionnalits nouvelles.
Elle comprend galement ltude
l tude des applications similaires
sur le march
Elle peut tre loccasion dune tude de rentabilit du
projet.
L'tude pralable identifie les contraintes budgtaires, les
contraintes d'environnement et les contraintes juridiques
juridiques.
13

Remarques
q
La phase dtude pralable est relativement courte. Elle ne
dpasse pas gnralement quelques semaines
Dans
D
de
d nombreux
b
projets
j t sii cette
tt phase
h
d
dpasse une
semaine, cest un signe que son objectif na pas t bien
compris. Il sagit de dcider si le projet mrite une tude
srieuse ou non
Si la dcision de raliser le projet a t dj prise et si sa
faisabilit est vidente
vidente, la phase dtude
d tude pralable sera
particulirement brve
La phase dtude pralable peut inclure un certain volume de
programmation destine crer des prototypes (interfaces
utilisateur) afin dexpliquer et mieux illustrer un certain nombre
de besoins
14
Chapitre 1
un projet
1.2. Analyse du systme et

spcification des exigences du projet
Niveau: 3me anne 3me semestre
Mouna AYARI

15
16
Spcification des besoins/exigences

Dmarche
17
Modle de cas d
dutilisation
utilisation
Dmarche
identifier les acteurs,
identifier
id tifi lles cas d
dutilisation,
tili ti
structurer les cas dutilisation en packages,
ajouter les relations entre cas dutilisation,
finaliser un ou plusieurs diagramme(s) de cas
dutilisation par paquetage (package)
18
Modle de cas d
dutilisation
utilisation
19
Spcification dun
d un cas d
dutilisation
utilisation
Cas dutilisation
Acteur principal
[[Acteurs secondaires]]
Objectifs
Prconditions
Post-conditions
Scnario nominal
Alternatives
Exigences supplmentaires
20
Spcification dun
d un cas d
dutilisation
utilisation
Prconditions
dfinissent ce qui doit tre vrai en amont du cas
dutilisation pour que celui-ci puisse dmarrer

Certaines prconditions triviales nont pas besoin
dtre mentionnes (exp. Le systme doit tre
aliment
li
au courant l
lectrique)
i
)
Post-conditions
Dfinissent ce qui doit tre vrai lorsque le cas
dutilisation se termine avec succs, quil sagisse dun

scnario
i nominal
i l ou d
dun scnario
i alternatif
lt
tif
21
Relations entre cas d

dutilisation
utilisation
Relation dinclusion formalise p
par le mot-cl include
Le cas dutilisation de base en incorpore explicitement un
autre, de faon obligatoire
Relation dextension, formalise par le mot-cl
extend
Le cas dutilisation de base en incorpore implicitement un
autre, de faon optionnelle
R
Relation
l ti d
de gnralisation/spcialisation
li ti / i li ti
Les cas dutilisation descendants hritent de la description
de leur parent commun.
commun Chacun dentre
d entre eux peut
nanmoins comprendre des interactions spcifiques
supplmentaires
22
Chapitre 1
un projet
1.3. Fondements de base de la COO

Mouna AYARI

23
Fondements de base de la COO

Introduction
Rappel sur lapproche oriente objet
Principes de loriente objets
24
Introduction
Approche
pp
fonctionnelle:
La modlisation est ralise partir de fonctions que doit
raliser le systme
Approche oriente objet :
On identifie les objets manipuls par le systme
systme, avec leurs
tats et leurs comportements

L
Lide
ide est connue depuis 1976
Programmation oriente objet : 1980, version industrielle de
SmallTalk
Langages de programmation : Ada, C++, Java
25
Introduction
26
Introduction
Possder un marteau ne fait pas de vous un architecte!
Connatre un langage de programmation oriente objet est-il
suffisant pour matriser la conception et le dveloppement orients

objet?
Evidemment non, connatre un langage orient objet (par exemple
java) est ncessaire mais nest pas suffisant pour crer un systme
objets. Il faut savoir PENSER en objets !
UML ett lla pense

objet
bj t
UML: Unified Modeling Langage
Cest:
Une notation, un langage de modlisation objet
Une description complte, volutive, publique
Un standard
standard, utilis par des AGL (Atelier de Gnie Logiciel)
Ce nest pas :
Une mthodologie danalyse ou de conception oriente objet
27
Introduction
Trs Important!
p
Cest inutile
d
dapprendre
apprendre un langage de programmation oriente objet
dapprendre UML ou un outil de gnie logiciel
Si vous ntes
n tes pas en mesure de
laborer une excellente conception oriente objet
Amliorer une conception
p
existante
La comptence
p
de p
penser et concevoir en objet
j
est la plus importante et la plus difficile acqurir
28
Introduction
Analyse
versus
Lanalyse met laccent sur une investigation
du problme et des besoins plutt que sur la

recherche dune solution
Analyse:
Quest ce quon dsire dvelopper?
Quelles sont les fonctions du systme?
Spcifier le bon systme construire
Le terme analyse est vaste:

Analyse des besoins (spcification des
besoins)
Analyse oriente objet (spcification et
investigation des objets du systme)
29
Conception
La conception:
sous-entend llaboration dune solution
conceptuelle
p
rpondant
p
besoins pplutt qque la
mise en uvre de cette solution
Exclut souvent les dtails de bas niveau
Description
p
dun schma conceptuel
p
dobjets
j
logiciel et de base de donnes
La conception se rsume au terme: bien
construire un systme
Conception:
Conception oriente objet/composant
Conception de la base de donnes
Conception graphique
Rappel sur llapproche

approche oriente objet
Approche oriente objets
j
Privilgier une approche architecturale pour implmenter des
solutions des problmes plutt quune approche fonctionnelle

visant rsoudre un problme pos
Notion dObjet
Dfinition
Dfi iti
Un objet dfinit une reprsentation dune entit atomique relle
ou virtuelle,
virtuelle dans le but de le piloter ou de le simuler
simuler. Les objets
encapsulent une partie des connaissances du monde dans
lequel ils voluent.
Un objet associe donnes et traitements en ne laissant visible
que linterface de lobjet, cest dire les traitements que lon

peut faire dessus
30
Rappel sur lapproche

l approche oriente objet
Objet
Obj t = Id
Identit
tit + Et
Etatt + C
Comportement
t
t
LIdentit : En plus de son tat un objet possde une identit qui
permet de le distinguer de manire non ambigu

indpendamment de son Etat.
Ltat : regroupement des valeurs instantanes de tous les
attributs dun objet

Le comportement : regroupe toutes les comptences dun objet
(mthodes) et dcrit les actions et les ractions de cet objet
Objet
Un objet possde un tat et ragit selon un comportement
Ltat volue au cours du temps, en fonction du comportement
Les objets changes des messages
31

Notion de classe
La classe dcrit le domaine de dfinition dun ensemble
dobjets : Cest un modle qui dfinit les donnes et les

traitements communs une collection dobjets similaires
Chaque objet appartient une classe
Classe : regroupement d objets de mme type.
Lobjet
j est une instance de sa classe
Terminologie oriente objet

Les traitements sont appels mthodes de lobjet
l objet
Les donnes sont appeles variables, donnes membres,
attributs ou proprits
Les
L objets
bj t iinformatiques
f
ti
sontt construits
t it partir
ti de
d lla
classe par un processus appel instanciation
Tout objet est instance dune Classe
32

Objets
Ahmed, Ibrahim, Nesrine; universit de Monastir, universit de Sousse,
universit de Tunis 2
Classe : regroupement d objets
objets de mme type.
type
Personne
Universit
Objet
Ahmed : Personne
25 ans
Ahmed Ben Foulen
40 rue
ue dee laa Libert,
be t, Monastir
o ast
33
Classe
Personne
Age : int
Nom, Adresse : stringg
SePrsenter()
renvoie Nom
Vieillir()
()
ChangerNom()
Age = Age+1

Les qualificatifs de classe (porte)
Publique :
Les fonctions de toutes les classes peuvent accder aux
donnes ou aux mthodes d'une classe dfinie avec le
niveau de visibilit public. Il s'agit du plus bas niveau de
protection des donnes
donnes.
Protge :
L
Laccs
accs aux donnes est rserv aux fonctions des classes
hritires, c'est--dire par les fonctions membres de la
classe ainsi que des classes drives.
34
Prive :
L'accs aux donnes est limit aux mthodes de la classe
elle-mme
elle
mme. Il s'agit
s agit du niveau de protection des donnes le
plus lev.

Les qualificatifs dattribut
Publique : Un attribut publique pourra tre accd (lu et
modifi)) p
par tout le monde.
Protge : Un attribut protg pourra tre accd (lu et
modifi) par les classes filles.

Prive : Un attribut prive pourra tre accd (lu et
modifi) par les mthodes et seulement les mthodes de

sa classe.
35

Les qualificatifs de mthode
Publique : Une mthode publique pourra tre
utilise p
par tout le monde.
Protge : Une mthode protge pourra tre
utilise ou redfinie par les classes hritires

hritires.
Prive : Une mthode prive pourra tre utilise par
les mthodes et seulement les mthodes de sa

classe.
36
Principes de lloriente
oriente objet
Objets
j
:
E
Encapsulation
l ti
:
37
Units de base organises en classes et partageant des

traits communs (attribut ou procdures).
Entits du monde rel, des concepts de lapplication ou du
domaine trait.
Les structures de donnes et les dtails de
llimplmentation
implmentation sont cachs aux autres objets du
systme.
La seule faon daccder
d accder ltat
l tat dun
d un objet est de lui
envoyer un message qui va dclencher lexcution de
lune de ses mthodes.
Principes de loriente
l oriente objet
Encapsulation
p
Loccultation des dtails de ralisation
Par dfaut les valeurs des attributs dun
d un objets sont
encapsules dans lobjet et ne peuvent pas tre manipules

directement par un autre objet
Des
D rgles
l d
de visibilit
i ibili prcisent
i
lla notion
i d
dencapsulation
l i
assouplissement du degr dencapsulation et de protection au
profit de certaines classes bien p
p
particulires ((exp:
p classes
mres/filles, classes amies en C++)
intrt : rduire le temps daccs aux attributs
Trois niveaux dencapsulation
priv (-): attribut non vu de lextrieur de lobjet

protg (#): attribut vu par des classes drives
38
public (+): attribut visible pour toutes les classes
l oriente objet -Encapsulation
Encapsulation
Personne
Age : int
Nom, Adresse : string
Regroupement des attributs
et des mthodes
Modularit :
protge les donnes d une
SePrsenter()
Vieillir()
ChangerNom()
utilisation errone
cache les dtails des
mthodes
Evolutivit, fiabilit
39
l oriente objet - Hritage
Abstraction
Il s'agit d'un processus qui consiste identifier les
caractristiques intressantes d'une entit, en vue d'une
utilisation prcise.
prcise
L'abstraction dsigne aussi le rsultat de ce processus,
c'est--dire l'ensemble des caractristiques essentielles
d'
d'une
entit,
tit retenues
t
par un observateur.
b
t
Hritage :
Chaque instance dune classe possde ses
caractristiques (attributs+mthodes), mais aussi celles
d
dune
ventuelle
t ll super classe
l
((classe
l
mre).
)
Permet de dcrire un type de lien qui unit les diffrents
objets.
j
40
l oriente objet - Hritage
Relation entre classes
Oiseaux est un cas particulier de Animaux
Animaux gnralise Oiseaux
La classe fille
hrite les attributs et les comportements
peut avoir des attributs et des mthodes nouvelles
peut avoir un comportement modifi
Animaux
Reptiles
p
41
Oiseaux
l oriente objet
Modularit :
Partition du programme qui cre des frontires bien
dfinies (et documentes) lintrieur du programme

dans lobjectif
l objectif den
d en rduire la complexit
complexit.
Polymorphisme :
Possibilit de recourir la mme expression pour
dnoter diffrentes oprations.

p
Lhritage est une forme particulire de
polymorphisme caractristique des systmes orients
objet.
objet
42
Principes de lloriente
oriente objet - Polymorphisme
Exemple
p
Tout animal peut se dplacer
Il le fait diffremment sil sagit dun oiseau ou dun serpent
Animaux
SeDeplacer()
Reptiles
43
SeDeplacer()
{
en volant
}
Serpents
SeDeplacer()
{
en glissant
}
Exercice dapplication
d application
Quelles sont les caractristiques dune personne?
Quelles sont les comportements gnriques dune
p
personne?
Pouvez vous donnez des exemples dinstances dune
personne?
Donnez des exemples de sous classes
classes.
44
Solution de lexercice
l exercice dapplication
d application
45
Solution de llexercice
exercice dapplication
d application (suite)
46
l oriente objet
Trouver les bons objets
Mthode de dsagrgation / agrgation :
Dsagrger un module : {modules}
Agrger un {modules} : un module
Dsagrgation dun module :
On part dun tout que lon clate en plusieurs parties. Chaque
partie
ti fformantt son ttour un ttout,
t estt susceptible
tibl dtre
dt nouveau
clate en parties plus petites.
Il est difficile dexprimer en dcomposition logicielle ce quest une
partie.
ti
En conception on fait lhypothse que le systme est un tout et
quil est compos de parties cohrentes sparables.
47
l oriente objet
Trouver les bons objets
La dcomposition est base sur les entits du domaine
du problme.
La dsagrgation est trs diffrente de la dcomposition
fonctionnelle car une fonctionnalit nest pas une entit

du domaine du problme.
La granularit de la taille des entits dpend du niveau
dabstraction.
48
l oriente objet
Quelques rgles dcriture dun module
Un module reprsente un concept et tout le concept.
Ne pas regrouper dans un module des oprations
qui nont pas de raison dtre ensemble

Pour concrtiser une ide le choix du nom du
module est un lment puissant dexpression

(patron de conception Design Patterns ).
Phase simpliste : Le choix des mthodes
correspond aux verbes.

49
Chapitre 1
un projet
1.4. Modlisation des relations entre les

classes
Mouna AYARI

50

Exemple de modlisation d
dune
une classe
Bonne pratique de manipulation des attributs
51

Association
Dpendance
p
Agrgation/composition
Hritage
H it
Ralisation dinterface
52
Association entre classes

Notion dassociation
Une association est une relation entre deux classes
association binaire
association
i ti n-aire
i
Elle dcrit les connexions structurelles entre leurs
instances
Multiplicit dune association
Exemple Interprtation
1..1 ou 1Un et un seul
0..1
zro ou un seul
0..*
0 * ou * zro
plusieurs
l i
3..4
trois quatre
4
quatre et seulement quatre
53
Modlisation d
dune
une association
Une association simple
p entre deux classes reprsente
p
une relation structurelle entre ppairs,
cest dire entre deux classes de mme niveau conceptuel.
Aucune des deux nest plus importante que lautre.
54
Modlisation d
dune
une association
Niveau dimplmentation
Lassociation se manifeste par la prsence de deux
attributs dans chacune des classes en relation

Cest la manire dont une association est gnralement
g
implmente dans un langage objet quelconque
Terminaison dassociation
(Une terminaison dassociation
d association est une extrmit de lassociation
l association. Une association binaire en
possde deux, une association n-aire en possde n)
Un attribut peut tre considr comme une association
55
dgnre dans laquelle une terminaison dassociation est

dt
dtenue
par un classeur
l
((gnralement
l
t une classe).
l
)
Le classeur dtenant cette terminaison dassociation devrait
thoriquement se trouver lautre extrmit, non modlise, de
l association.
lassociation
Un attribut est une terminaison dun cas particulier dassociation
Les terminaisons dassociations et les attributs sont deux
lments conceptuellement trs proches que lon
l on regroupe sous
le terme de proprit
Modlisation d
dune
une association
56
Association n
n-aires
aires
Une association nn-aire
aire lie plus de deux classes
Si un cours doit pouvoir exister indpendamment dun lien entre un enseignant et un groupe, il
faut utiliser le modle de droite
57
Dpendance entre classes

Une dpendance est une relation unidirectionnelle
exprimant une dpendance smantique entre des

lments du modle
modle.
Elle est reprsente par un trait discontinu orient
On utilise souvent une dpendance quand une classe en utilise
une autre comme argument dans la signature dune opration
Un lment A dpend d'un

d un lment B,
B lorsque A utilise
des services de B
Tout changement dans B peut avoir des rpercussions sur A
58
Modlisation dune
d une dpendance
Reprsentation
p
UML
Un trait discontinu partant de la classe dpendante et pointant vers
la classe proposant les services sollicits, se terminant par une

pointe de flche ouverte (c'est ce qui la distingue de la relation de
ralisation)
Un contrat dispose d'un service d'impression (mthode
impression), qui utilise une mthode (print), dont la spcification est

dclare par l'interface (ou notamment la classe) Printer.
59
Modlisation dune
d une dpendance
Exemple
p dimplmentation
p
classContrat{
...
publicvoid impression(){
Printerimprimante=PrinterFactory.getInstance();
...
imprimante.print(client.getName());
...}
}
}
le lien entre un objet "contrat" et une "imprimante" est
momentan. Il ne dure que le temps d'excution de la mthode

impression
L'imprimante n'a pas lieu d'tre un attribut de la classe Contrat, et
de ce fait, ce n'est pas une association, mais une simple

dpendance
60
Agrgation entre classes

Une relation dagrgation
g g
permet de modliser une relation tout/partie o une classe
constitue un lment plus grand (tout) compos dlments
plus petit (partie
reprsente une relation dinclusion structurelle ou
comportementale dun
d un lment dans un ensemble)
nentrane pas de contrainte sur la dure de vie des parties
par rapport au tout
Multiplicit
1 .. 1
1 .. n
1 .. *
0 .. *
61
Modlisation dune
d une relation dagrgation
d agrgation
Reprsentation
p
UML
Graphiquement, on ajoute un losange vide () du ct
de lagrgat
Exemple
62
Relation de composition
Relation de composition
p
La composition est galement appele agrgation
composite
Elle dcrit une contenance structurelle entre instances de
classes
La destruction de lobjet
l objet composite implique la destruction
de ses composants
Une instance de la partie appartient toujours au plus une
instance de llment composite

La multiplicit
p
du ct composite
p
ne doit p
pas tre suprieure
p
1
(i.e. 1 ou 0..1)
63
Modlisation dune
d une relation de composition
Reprsentation
p
UML
Graphiquement, on ajoute un losange plein () du
ct de lagrgat
Exemple
64
Modlisation de agrgation/composition
Exemple
p
65
Hritage
Relation dhritage
d hritage ou de gnralisation
dcrit une relation entre une classe gnrale (classe de base ou
classe parent) et une classe spcialise (sous-classe)
La classe spcialise (fille) est intgralement cohrente avec la
classe de base, mais comporte des informations
supplmentaires (attributs, oprations, associations)
Remarque
En modlisation UML, la relation dhritage nest pas propre
aux classes. Elle sapplique dautre lments du langage
comme les paquetages, les acteurs ou les cas dutilisation.
66
Hritage entre classes

Proprits principales de lhritage entre les classes:
La classe fille possde toutes les caractristiques des ses
classes parents.
Une classe fille peut ne pas accder aux caractristiques
prives de sa classe mre sauf si les attributs de cette
dernire sont dclars comme protected
U classe
Une
l
enfant
f t peutt redfinir
dfi i ((mme
signature)
i
t ) une ou
plusieurs mthodes de la classe parent.
Toutes les associations de la classe p
parent sappliquent
pp q
aux
classes drives.
Une classe peut avoir plusieurs parents, on parle alors
dhritage
d
hritage multiple.
multiple
Le langage C++ est un des langages objet permettant son
implmentation effective
Le langage Java ne permet pas lhritage
l hritage multiple
67
Modlisation dune
d une relation dhritage
d hritage
Reprsentation
p
UML
Le symbole utilis pour la relation dhritage ou de gnralisation
est une flche avec un trait plein dont la pointe est un triangle
ferm dsignant le cas le plus gnral
gnral.
68
Interface
Une interface
est une entit dont toutes ses mthodes sont, par dfinition, abstraites
regroupe un ensemble de proprits et doprations assurant un
service cohrent
Ralisation dune interface
Une interface doit tre ralise (implmente) par au moins une classe
(elle peut notamment tre ralise par plusieurs classes
Une classe peut raliser plusieurs interfaces
Reprsentation
R
t ti UML
Graphiquement, cela est reprsent par un trait discontinu termin par une
flche triangulaire
Notation simplife :
Une interface peut tre reprsente par un petit cercle avec le nom de
l'interface plac juste en dessous. Le cercle peut tre attach une ou
plusieurs
l i
classes
l
d'i
d'implmentation.
l
t ti
69
Modlisation de la ralisation dune

d une interface
Exemple
70
Notation simplifie
Exemples
71
Exemples
Relation de ralisation
(implmentation)
La classe enseignant ralise
linterface
72
Relation de
dpendance
Exercice d
dapplication
application 1
Dgager le diagramme de classes en reprsentation UML mettant en relief les
relations significatives entre classes dcrites par l'extrait

l extrait de code java suivant
73
d application 1
74
Exercice d
dapplication
application 2
Etant donn le diagramme de classes suivant, dterminer la squelette du
code java correspondant
75
d application 2
public interface Observer {
public
bli void
id update(Observable
d t (Ob
bl obj);
bj)
}
public class UIGraphe implements Observer {
...
public void update(Observable o) {
...
}
...
}
public class Bilan extends Observable {
...
void setChange() {
}
...
}
76
public class Observable {

...
vector observateurs;
public void notify()

p
y() {
...
}
public void addObserver(Observer o) {
obser ate rs add(o)
observateurs.add(o);
}
Chapitre 1
un projet
1.5. Rappel sur les diagrammes de

modlisation UML
Mouna AYARI

77
Rappel sur la modlisation UML

Vocabulaire UML (Rappel)
( pp )
78
Rappel sur la modlisation UML

UML: Unified Modeling
g Langage
g g
C
Cest:
est:
Une notation, un langage de modlisation objet
Une description complte
complte, volutive,
volutive publique
Un standard, utilis par des AGL
Ce nest pas :
Une mthodologie
79
Diagrammes UML
Diagramme UML
Diagramme structurel
Vue statique
80
Diagramme comportemental
Vue dynamique
Diagrammes UML
81
Diagrammes UML
Liens entre les diagrammes
g
82
Chapitre 2 Mthodologies de COO

processus unifi
Mouna AYARI

83
Plan du chapitre
84
Introduction
P
Processus
unifi:
ifi Unified
U ifi d P
Process (UP)
Rational Unified Process (RUP)
2TUP (Two Track Unified Process)
Introduction
Pourquoi une mthodologie / processus?
Le Processus Unifi
Itration
Les itrations peuvent tre regroupes en 4 phases
Phases (cration, laboration, construction, transition)
Activits
Chaque itration consiste enchaner 5 activits :
Besoins
B
i
Analyse
Conception
Implmentation
Tests
85
Pourquoi une mthodologie / Processus?

Les techniques (diagrammes dUML)
d UML) de
dveloppement de systme doivent tre organises

si elles doivent fonctionner ensemble
UML mme ne contient rien qui aide prendre cette
dcision
86
Pourquoi
q
une mthodologie
g / Processus?
L'organisation des tches n'est pas contenue dans les
techniques
Elle doit tre dcrite un plus haut niveau d'abstraction
Mthode ou processus d'un projet est la manire
p
particulire
avec laquelle
q
les tches dans ce p
projet
j sont
organises
La mthodologie est encore plus abstraite : un mta-
processus qui peut tre appliqu de nombreux projets

87
Processus Mthode ou Mthodologie?

Processus,
Souvent mlang, comme s'il s'agissait de la mme
chose, mais ces termes diffrent rellement

Mthode/Processus = description pas--pas des tapes
impliques dans l'accomplissement d'une tche

particulire
Elle ne peut tre la mme pour deux projets diffrents, la
mthode est spcifique un projet
projet.
Mthodologie = ensemble de principes gnraux qui
guident le choix d'une

d une mthode adapte une tche ou
projet spcifique
88
Pourquoi utiliser une mthodologie / Processus?

De nombreux avantages sont avancs
Aide produire un produit de meilleure qualit
Logiciel
L
i i l mieux
i
d
document
t
Plus acceptable par l'utilisateur
Plus facile maintenir/entretenir
Logiciel plus homogne
Aide assurer que les spcifications des utilisateurs
sont suivies
Aide le manager du projet contrler le projet
Rduit les cots de dveloppement
Encourage la communication entre les personnes
89
UML n
n'est
est qu
qu'un
un langage
Bien quissu dune concertation visant produire le
p
processus
Unifi,, UML n'est q
qu'un langage
g g de modlisation
et non une mthodologie part entire.
UML dfinit des notations utiles dans toutes les tapes du
dveloppement d'un logiciel, de l'analyse des besoins la

livraison de celui-ci, mais il ne propose aucune dmarche
spcifique pour mener ce dveloppement terme.
En ce sens, UML peut a priori tre utilis dans le cadre de
l'utilisation de toute mthode de dveloppements (par

objets).
90
Chapitre 2
Mthodologies de COO processus unifi
2.1. Processus Unifi

Unified Process (UP)
Mouna AYARI

91
Processus Unifi (UP)

UP est un processus de type adaptatif, il est
Itratif et incrmental
Guid par les besoins (exigences) des utilisateurs
Centr sur larchitecture
Pilot par les risques
On le reprsente
p
selon laxe statique
q et dynamique
y
q
des processus de dveloppement.
92
Phases et itrations
UP comporte les quatre phases suivantes:
Pr tude: dfinition du cadre du projet
laboration:
tablissement dun plan de projet et dune architecture

solide
Construction: dveloppement
pp
du systme
y
Transition: livraison du systme aux utilisateurs finaux
Il existe un certain nombre ditrations

lintrieur

de chaque phase.
Une itration reprsente un cycle de dveloppement logiciel complet
((analyse
y des besoins version excutable))
93
Cycle
y de vie
94
Phases
Pr tude : On dfinit le cadre du systme et on dlimite la
porte du projet
projet. Ce cadre comprend:
Les critres de russite
La mise en vidence des risques
Les
L estimations
ti ti
d
des ressources ncessaires
i
Un plan de phase qui contient un planning des principaux jalons
Un prototype excutable validant le concept
laboration
laboration: consiste
95
Analyser le domaine du problme
tablir
une architecture solide
Dvelopper le plan du projet
liminer les lments risques
q
p
pour le p
projet
j
Phases
Construction
Construction: On dveloppe un produit complet et prt
transiter vers les utilisateurs, de manire itrative et

incrmentale
Transition
Transition: au cours de cette phase on dploie le logiciel pour
les utilisateurs, on rajuste le systme en corrigeant les

ventuels bugs ou on achve certains fonctionnalits qui
avaient t remises plus tard
96
Workflows et processus
97
Modlisation mtier
dcrit la structure et la dynamique de lentreprise
Exigences
dcrit la mthode base sur les cas dutilisation pour

saisir et organiser les exigences
Analyse et
conception
dcrit les diffrentes vues dune architecture
Implmentation
prend en compte le dveloppement logiciel, les tests

unitaires et lintgration
Tests
dcrit les cas de test, les procdures et les mtriques

de recherche derreur
Dploiement
couvre la configuration du systme livrer
Gestion de
configuration
Contrle les modification et maintient les artefacts

dun projet
Gestion de projet
Dcrit diffrents stratgies de travail avec un

processus itratif
Environnement
Couvre linfrastructure ncessaire demande pour

dvelopper
pp un systme
y
Workflows et artefacts
Workflows
Expression des besoins
Spcifications
Artefacts
Vision du projet
Modle des cas dutilisation
Spcifications supplmentaires
Glossaire
Analyse
Conception
Modle du domaine
Modle de conception
Architecture logicielle
Modle de donnes
Implmentation
Tests
98
Modle dimplmentation
Modle de tests
D l i
Dploiement
t
M dl d
Modle
de dploiement
d l i
t
Gestion de projets
Plan de dveloppement
Environnement
Cas de dveloppement
UP est Itratif et incrmental

Le dveloppement dun logiciel ncessite quon le dcoupe
en plusieurs petits projets.

Chaque projet reprsente une itration qui donne lieu un
incrment.
Une itration dsigne la succession des activits de dveloppement
p
aux stades de dveloppement
pp
du p
produit
un incrment correspond
99
UP est pilot par les uses cases

Pour servir les attentes des utilisateurs, On centre le processus de
dveloppement sur leurs besoins
besoins.
On fait apparatre ces besoins laide de la technique des cas
d ili i :
dutilisation
en capturant les besoins fonctionnels dun systme

y
en orientant le travail de chaque itration
vont guider le processus travers lutilisation des diffrents

modles UML qui reprsentent le systme.
100
Cahier des charges
Analyss par
Conus par
Raliss par
Structurs par
Tests par
Diagramme des
Di
d
Uses Case
101
Dploys par
Modle du domaine
Modle de
conception
Modle
dimplmentation
Modle
darchitecture
Modle de tests
Modle de
dploiement
UP est centr sur llarchitecture

architecture
larchitecture doit prvoir la ralisation de tous les uses case et
doit voluer avec eux.

Elle le fait en tenant compte de facteurs tels que:
102
La plateforme dexcution
Matriel, systme, BD, rseau,etc.

Les composants rutilisables
Librairies, caisse outils, composants du commerce, etc.

Les considrations de dploiement et les besoins non
f
fonctionnels
ti
l
La performance, la fiabilit, la robustesse, etc.
UP est pilot par les risques

Un risque est un vnement redout dont
loccurrence est p
plus ou moins p
prvisible.
Le pilotage par les risques cest:
Analyser
y
les risques
q
p
potentiels au p
plus tt
Hirarchiser les risques
Associer un ensemble de uses case chaque risque
Dclencher les itrations selon la criticit des uses cases
quelles regroupent
UP propose une gestion

ti d
des risques.
i
C
Ce quii
constitue une avance significative.
103
Adaptations de UP
UP est un p
processus g
gnrique
q de dveloppement.
pp
Il doit tre adapte au contexte du projet, de

lquipe et de lorganisation concerne.
Il existe donc des adaptations dUP
d UP dont les plus
connues sont:
104
Le Rational Unified Process (RUP)

(
)
LeXtreme Programming (XP)
Le Two Tracks Unified Process (2TUP)
Chapitre 2
2.2. Processus Unifi

Rational Unified Process (RUP)
Mouna AYARI

105
Processus Unifi ou Unified Software Development

Process (USDP)
Process
Processus du domaine public pour le
dveloppement
pp
Orient-Objet
j de logiciel
g
Maintenant largement surpass par le Processus
Unifi
U
ifi R
Rational
ti
l ((similaires
i il i
d
dans lleurs aspects
t
principaux)
106
Processus Unifi - RUP

Le Processus Unifi est :
guid par les use
use-cases,
cases,
centr sur l'architecture,
itratif et incrmental
incrmental.
107
Processus Unifi -RUP

RUP
L itrations
Les
it ti
peuventt tre
t regroupes
en 4 phases
h
:
cration (objectifs du projet, et cots),
laboration
l b ti (b
(besoins),
i )
construction (obtention du produit quasi finalis),
transition
t
iti ((mise
i au point
i t ett livraison).
li i
)
Profil dun projet typique montrant les tailles relatives des quatre phases
108
Processus Unifi - RUP

Chaque
Ch
it ti consiste
itration
i t enchaner
h
5 activits
ti it
principales :
Besoins,
Besoins
Analyse,
Conception,
p
,
Implmentation,
Tests.
Diffrentes activits plus spcifiques peuvent s'enchaner
dans chacune de ces 5 activits principales

principales. Elles sont
effectues par diffrents travailleurs.
109
Organisation en phases, itrations et

activits
Activits
principales
Phases
Cration
laboration
Construction
It. 1
Transition
Besoins
Analyse
Conception
Implmentation
Tests
It. 2
Itrations
Rpartition du travail en phases, itrations et activits principales
110
It. n-1
It. n
Organisation en phases, itrations et

activits
Activits
principales
Phases
Cration
laboration
Construction
It. 1
Transition
Besoins
Analyse
Conception
Implmentation
Tests
It. 2
Itrations
111
It. n-1
It. n
Activits de ll'analyse
analyse des besoins
L
L'analyse
analyse des besoins regroupe les activits
suivantes :
tablir une bauche du modle des use-cases,
use cases
assigner des priorits aux use-cases,
dtailler chaque use-case,
prototyper l'interface utilisateur,
structurer le modle des use-cases.
112
Enchanement des activits de l'analyse

des besoins
Analyste
systme
Architecte
Spcificateur
de use-case
Concepteur
dinterface
113
Structurer modle
u-c.
baucher
modle u-c.
Assigner priorits u-c.
Dtailler
Dt
ill
use-case
Prototyper
interface

des besoins
Analyste
systme
Architecte
Spcificateur
p
de use-case
Concepteur
dinterface
114
Structurer modle
u-c.
baucher
modle u-c.
Dtailler
use-case
Prototyper
interface
bauche du modle des use

use-cases
cases
L'analyste
L'
l t systme
t
estt responsable
bl d
de cette
tt
activit.
A partir notamment de la liste des fonctionnalits,
elle consiste :
115
identifier les acteurs

acteurs,
identifier les use-cases,
dcrire brivement chaque use
use-case
case,
fournir un diagramme global de use-cases,
laborer un glossaire.
g
Enchanement des activits de l'analyse des

besoins
Analyste
systme
y
Architecte
Spcificateur
de use-case
Concepteur
ddinterface
interface
116
Structurer modle
u-c.
baucher
modle u-c.
Dtailler
use-case
Prototyper
interface
Priorit des use

use-cases
cases
Cette activit fait suite l'bauche du modle des
use-cases.
L
L'architecte
architecte tablit un ordre de priorit pour la
ralisation (conception, implmentation, ) des

use-cases dans
d
lles it
itrations
ti
ultrieures.
lt i
117

besoins
Analyste
systme
y
Architecte
Spcificateur
de use-case
Concepteur
ddinterface
interface
118
Structurer modle
u-c.
baucher
modle u-c.
Dtailler
use-case
Prototyper
interface
Description dtaille des use

use-cases
cases
Cette activit fait suite l'tablissement des priorits
sur les use-cases.

Un responsable est nomm pour la description
dtaille de chaque use-case, il doit :
dtailler
d ill lla d
description
i i sommaire
i ffournie
i par l'l'analyste
l
systme, par des descriptions textuelles, des

diagrammes de squence ou de collaboration, un
diagramme d'tat;
rechercher les droulements anormaux et
exceptionnels
ti
l possibles
ibl ett lles d
dcrire.
i
119

des besoins
Analyste
systme
y
Architecte
Spcificateur
de use-case
Concepteur
ddinterface
interface
120
Structurer modle
u-c.
baucher
modle u-c.
Dtailler
use-case
Prototyper
interface
Prototypage de ll'interface
interface utilisateur
Cette activit fait suite la description dtaille des
use-cases.
Le concepteur dinterface fournit :
une conception logique de l'interface utilisateur
(indpendante de la manire dont elle peut tre

implmente),
des croquis de "pages-crans" en accord avec cette
conception logique.
121

besoins
Analyste
systme
Architecte
Spcificateur
de use-case
Concepteur
dinterface
122
Structurer modle
u-c.
baucher
modle u-c.
Dtailler
Dt
ill
use-case
Prototyper
interface
Structurer le modle des use

use-cases
cases
Cette
C tt activit
ti it fait
f it suite
it la
l description
d
i ti dtaille
dt ill d
des
use-cases.
L'analyste
y
systme
y
amliore le modle des use-
cases, notamment en identifiant :

des descriptions
p
similaires (g
(gnralisation),
),
des descriptions communes (inclusion),
des descriptions optionnelles (extension).
123
Organisation en phases,
phases itrations et activits
Activits
principales
Phases
Cration
laboration
Construction
It. 1
Transition
Besoins
Analyse
Conception
Implmentation
Tests
It. 2
Itrations
124
It. n-1
It. n
Activits de l'analyse
l analyse
L
L'analyse
analyse regroupe les activits suivantes :
analyse architecturale,
analyse de use-case,
analyse de classe,
analyse de paquetage.
125
Enchanement des activits de ll'analyse

analyse
Architecte
Ingnieur
de use-case
Ingnieur de
composants
126
Analyse
architecturale
Analyse de
use-case
Analyse
de classe
Analyse de
paquetage

analyse
Architecte
Ingnieur
de use-case
IIngnieur
i de
d
composants
127
Analyse
architecturale
Analyse de
use-case
Analyse
de classe
Analyse de
paquetage
Analyse architecturale
Cette activit est sous la responsabilit
p
de
l'architecte.
A partir du modle des use-cases,
use cases elle consiste
fournir :
une bauche des classes d'analyse
d analyse manifestes
manifestes,
une bauche des paquetages d'analyse (en 2 couches:
spcifique et gnrale aux applications)

applications),
une premire description de l'architecture (exigences).
128

analyse
Architecte
Ingnieur
de use-case
Ingnieur de
composants
129
Analyse
architecturale
Analyse de
use-case
Analyse
de classe
Analyse de
paquetage
Analyse de use
use-case
case
Cette activit fait suite l'analyse
l analyse architecturale
architecturale, elle
est effectue par un ingnieur de use-case.

Cela consiste identifier les classes d'analyse et les
interactions ncessaires la ralisation d'un usecase.
case
De nouvelles classes d'analyse peuvent tre
identifies, ou bien on peut donner de nouveaux

lments de dfinition de classes dj identifies.
Les interactions p
peuvent tre dcrites p
par des
diagrammes de description dynamique.
130

analyse
Architecte
Ingnieur
de use-case
Ingnieur de
composants
131
Analyse
architecturale
Analyse de
use-case
Analyse
de classe
Analyse de
paquetage
Analyse de classes
Cette
C tt activit
ti it succde
d aux analyses
l
d
de use-cases,
elle est effectue par un ingnieur de composants.

Elle
Ell consiste
i
:
identifier les responsabilits d'une classe partir de la
synthse
th d
des diff
diffrents
t rles
l qu'elle
' ll jjoue d
dans lles usecases (oprations),
identifier les attributs et les relations entre classes
(associations, gnralisation),
formuler ventuellement des exigences sur la
conception (taille des attributs, ).
132

analyse
Architecte
Ingnieur
de use-case
Ingnieur de
composants
133
Analyse
architecturale
Analyse de
use-case
Analyse
de classe
Analyse de
paquetage
Analyse de paquetages
Cette activit fait suite l'analyse
l analyse des classes
classes,
toutes deux sont effectues par un ingnieur de

composants.
composants
Cela consiste amliorer la rpartition des classes
d'analyse
d
analyse en paquetages,
paquetages bauches pendant
l'analyse architecturale. Il faut :
garantir la cohsion des paquetages
paquetages,
dcrire les dpendances entre paquetages et chercher
les diminuer.
134
Activits
principales
Phases
Cration
laboration
Construction
It. 1
Transition
Besoins
Analyse
Conception
Implmentation
Tests
It. 2
Itrations
135
It. n-1
It. n
Activits de la conception
La conception regroupe les activits suivantes :
conception architecturale,
conception de classe,
conception de use-case,
conception de sous-systme.
136
Enchanement des activits de conception
Architecte
Conception
architecturale
Ingnieur
de use-case
Ingnieur de
composants
137
Conception
de use-case
Conception
de classe
Conception de
sous-sytme
Architecte
Conception
architecturale
Ingnieur
de use-case
Ingnieur de
composants
138
Conception
de use-case
Conception
de classe
Conception de
sous-sytme
Conception architecturale
L'architecte assume la responsabilit de cette activit.
partir notamment du modle des use-cases,
use-cases du
modle d'analyse et de la premire description de

l'architecture issue de l'analyse,
y
il doit en particulier
produire :
une bauche des sous-systmes et de leur interface (4
couches)
couches),
une bauche des classes et mcanismes de conception,
une bauche du modle de dploiement (nuds et
configurations rseau).
139
Architecture en 4 couches
spcifique
lapplication
Dpend
dancess
gnrale aux applications
middleware
logiciel systme
140
Architecte
Conception
architecturale
Ingnieur
de use-case
Ingnieur de
composants
141
Conception
de use-case
Conception
de classe
Conception de
sous-sytme
Conception de classes
Cette activit fait suite la conception
p
architecturale,, elle
est effectue par les ingnieurs de composants.

Cette activit consiste :
dcrire prcisment les oprations et les attributs des
classes de conception,
dcrire les relations auxquelles elle prend part,
dcrire ses tats imposs
p
((diagramme
g
d'tats),
)
expliciter ses mthodes (qui ralisent les oprations)
et la ralisation correcte de ses interfaces,,

exprimer les exigences sur son implmentation.
142
Architecte
Conception
architecturale
Ingnieur
de use-case
Ingnieur de
composants
143
Conception
de use-case
Conception
de classe
Conception de
sous-sytme
Conception de use
use-case
case
Cette activit fait suite la conception architecturale et la
conception des classes de conception, elle est effectue par

les ingnieurs de use
use-case.
case.
Cette activit consiste :
reconnatre les classes de conception prenant part la
ralisation d'un use-case, de nouvelles classes de conception

peuvent tre ventuellement identifies,,
p
dcrire les interactions entre classes en termes de messages,
d
dfinir les
es e
exigences
ge ces su
sur les
es op
oprations
at o s et l'implmentation,
p e tat o ,
contrler et enrichir la description des sous-systmes et de leur
interface.
144
Architecte
Conception
architecturale
Ingnieur
de use-case
Ingnieur de
composants
145
Conception
de use-case
Conception
de classe
Conception de
sous-sytme
Conception de sous
sous-systmes
systmes
Cette activit fait suite la conception des classes et
des use
use-cases,
cases, elle est effectue par les ingnieurs de
composants.
Cette activit consiste finaliser la description des
sous-systmes et de leur interface, c'est--dire :
actualiser les dpendances
p
entre sous-systmes
y
((et les
minimiser),
actualiser leur interface,
actualiser le contenu des sous-systmes.
146
Activits
principales
Phases
Cration
laboration
Construction
It. 1
Transition
Besoins
Analyse
Conception
Implmentation
Tests
It. 2
Itrations
147
It. n-1
It. n
Rsum: UP (Processus unifi)

Enracin dans:
La mthode de Booch ((bonne p
pour la conception
p
et
l'implmentation)
OMT (bonne pour l'analyse)
Objectory
Obj
(b
(bonne
pour l'i
l'ingnierie
i i d
des b
besoins
i et
l'architecture du systme)
UP a rassembl ces mthodes
Aussi volumineux et complexe : temps
d'apprentissage long, ou bien l'adapter au besoin

148
Chapitre 2
2.3 Mthodologie 2: Processus en Y:

2TUP (Two Track Unified Process)
Mouna AYARI

149
Dfinition
2TUP est un processus UP apportant une rponse aux
contraintes de changement continuel des systmes

dinformation:
d
information: fonctionnel et technique
2 Track: p
processus suivant deux chemins
Fonctionnel
Architecture Technique
Contraintes
fonctionnelles
150
SI
Contraintes
techniques
q
Exemples
Une entreprise modifie son catalogue de produit en imposant
de nouvelles rgles de tarification volution fonctionnelle.
Cette mme entreprise dcide de rendre accessible son
catalogue via le WEB volution technique.
Cette entreprise dcide finalement de fusionner son
catalogue avec une autre entreprise du mme secteur

volution fonctionnelles et techniques
techniques.
151
Processus en Y
La ralisation du systme consiste fusionner les rsultats des deux
l ti
volutions
fonctionnelle
f
ti
ll ett technique:
t h i
ce quii conduit
d it un processus d
de
dveloppement en forme de Y
152
Processus en Y
Contraintes
fonctionnelles
Branche
fonctionnelle
Capture
C
t
d
des b
besoins
i
fonctionnels
Capture
C
t
d
des b
besoins
i
techniques
Analyse
Conception gnrique
Conception prliminaire
Conception dtaille
Codage et tests
Recette
153
Contraintes
techniques
Branche
technique
prototype
Processus en Y
La branche gauche (fonctionnelle) du Y
Capture
p
des besoins fonctionnels
Produit un modle des besoins focalise sur le mtier des
utilisateurs
Qualifie
Q lifi au plus
l tt lle risque
i
d
de produire
d i un systme
t
inadapt
Permet la matrise duvre de consolider les
spcifications et de vrifier la cohrence
Lanalyse
Prcise ce que lon va raliser en termes mtier
Le rsultat de lanalyse ne dpend daucune technologie
particulire
154
Processus en Y
La branche droite (architecture technique) du Y
Capture des besoins techniques
Recense toutes les contraintes et les choix dimensionnant la
conception
Identifie les outils et les matriels ainsi que les contraintes dintgration
avec lexistant
l existant
La conception gnrique
Dfinit les composants ncessaires llaboration de larchitecture
technique
Construit le squelette du systme et limine les risques au niveau
technique
A pour objectif duniformiser
d uniformiser et de rutiliser les mmes mcanismes
pour la plupart des systmes
Est indpendante des aspects fonctionnels
155
Processus en Y
La branche du milieu
La conception prliminaire
Intgre le modle danalyse dans larchitecture technique
Trace
T
la
l cartographie
t
hi d
des composants
t d
du systme
t
dvelopper
La conception
p
dtaille
tudie comment raliser chaque composant
Codage
Produit les composants et teste au fur et mesure les
units de code ralises
Recette
Valide les fonctions du systme dvelopp
156
Processus en Y
Les branches du Y p
produisent des modles
rutilisables
La branche gauche capitalise la connaissance du mtier de
lentreprise: les fonctions du systme dinformation sont

indpendantes des solutions techniques utilises.
La branche droite capitalise le savoir faire technique: les
techniques
q
utilises p
peuvent tre ralises
indpendamment du besoin fonctionnel
157
Chapitre 3 Conception architecturale

Mouna AYARI

158
Conception architecturale
Objectifs
Dcrire le fonctionnement et les caractristiques dun style
159
architectural
Justifier le choix dune architecture pour la ralisation dun
logiciel, en tenant compte de ses exigences fonctionnelles
et non fonctionnelles
Dfinir ce quest un composant
Expliquer le contenu dcrit par un diagramme de
paquetages, de composants et de dploiement (UML)
Dcrire le modle dune architecture avec la notation UML
Plan du chapitre
Introduction
Modlisation UML dune conception architecturale
Elments architecturaux
Styles architecturaux
Choix dune architecture
Architecture MVC
Architecture multi-couches
Architecture n-niveaux
Dvelopper un modle architectural
160
Introduction
Quest-ce
Q t
quune
architecture
hit t
llogicielle
i i ll ?
Larchitecture dun logiciel est la structure des
structures (modules) dun systme

Elle inclut
Les composants logiciels
Les proprits externes visibles de ces composants
Les relations entre ces composants
Cf. [Bass, Clements, and Kazman (1998) ]
161
Introduction
Contrairement aux spcifications produites par
lanalyse fonctionnelle
le modle d'architecture ne dcrit pas ce que doit
raliser un systme informatique mais plutt comment

il doit tre conu de manire rpondre aux
spcifications.
L
Lanalyse
analyse fonctionnelle dcrit le quoi faire alors que
larchitecture dcrit le comment le faire
162
Introduction
Qu
Quest
est que la description dune
d une architecture
logicielle ?
La dfinition de larchitecture
l architecture logicielle consiste :
Dcrire lorganisation gnrale dun systme et sa
dcomposition en sous-systmes ou composants
Dterminer les interfaces entre les sous-systmes
Dcrire les interactions et le flot de contrle entre les soussystmes
y
Dcrire galement les composants utiliss pour implanter les
fonctionnalits des sous-systmes
Les proprits
L
it d
de ces composants
t
Leur contenu (e.g., classes, autres composants)
Les machines ou dispositifs matriels sur lesquels ces modules
seront dploys
163
Introduction
Pourquoi
q
dvelopper
pp une architecture logicielle
g
?
Pour permettre tous de mieux comprendre le
systme
Pour permettre aux dveloppeurs de travailler sur des
parties individuelles du systme en isolation
Pour prparer les extensions du systme
Pour faciliter la rutilisation et la rutilisabilit
164
Introduction
Utilit dune architecture logicielle
g
[[Garlan 2000]]
Comprhension : facilite la comprhension des grands systmes
complexes en donnant une vue de haut-niveau de leur structure
et de leurs contraintes.
contraintes Les motivation des choix de conception
sont ainsi mis en vidence
Rutilisation : favorise lidentification des lments rutilisables,
parties de conception, composants, caractristiques, fonctions ou
donnes communes
Co
Construction
st uct o : fournit
ou t u
un p
plan
a de haut-niveau
aut
eau du d
dveloppement
e oppe e t
et de lintgration des modules en mettant en vidence les
composants, les interactions et les dpendances
165
Introduction
Utilit dune architecture logicielle
g
[[Garlan 2000]]
volution : met en vidence les points o un systme peut tre
modifi et tendu. La sparation composant/connecteur facilite

une implmentation du type plug-and-play
Analyse : offre une base pour lanalyse plus approfondie de la
conception du logiciel
logiciel, analyse de la cohrence
cohrence, test de
conformit, analyse des dpendances
Gest
Gestion
o : co
contribue
t bue la
a gest
gestion
o g
gnrale
a e du p
projet
ojet en
e permettant
pe etta t
aux diffrentes personnes impliques de voir comment les

diffrents morceaux du casse-tte seront agencs. Lidentification
des dpendance entre composants permet didentifier
d identifier o les
dlais peuvent survenir et leur impact sur la planification gnrale
166
Modlisation
od sat o UML
U
dune
d
u e architecture
a c tectu e dun
d u systme
syst e
Vues (structurelles) dune
d une architecture logicielle
Vue logique. Description logique du systme
dcompos
p
en sous-systmes
y
((modules + interface))
UML : diagramme de paquetages
Vue dimplmentation. Description de limplmentation
(physique) du systme logiciel en termes de

composants et de connecteurs
UML : diagramme de composants
Vue de dploiement. Description de lintgration et de
la distribution de la partie logicielle sur la partie

matrielle
UML: diagramme combin de composants et de dploiement
167
Rappel : vues d
dun
un systme
Diagramme de
composants
p
Diagramme
de classes
Diagramme
combin de
dploiement/
composants
Diagramme de
packages
Vue structurelle
(modle statique)
Vue des cas dutilisation
d utilisation
(modle fonctionnel des exigences)
Diagramme de
squence
Vue du comportement et des interactions

(modle dynamique)
interaction
Diagramme
dtats
168
comportement
Diagramme de
cas dutilisation
comportement
Diagramme de
communication
i ti
interaction
Diagramme
dactivits
d
activits
comportement
Modlisation
od sat o U
UML ddune
u e architecture
a c tectu e dun
d u systme
syst e
Diagramme de paquetages
169
Modlisation
od sat o U
UML ddune
u e architecture
a c tectu e dun
d u systme
syst e
Diagramme de composants
170
Modlisation
od sat o U
UML ddune
u e architecture
a c tectu e dun
d u systme
syst e
Diagramme combin de dploiement/composants
171
lments architecturaux
Composant
compA
Encapsule un traitement et/ou des donnes

Encapsule un sous-ensemble de fonctionnalits et/ou de
donnes du systme
y
Restreint laccs ce sous-ensemble au moyen dune
interface dfinie explicitement

Possde des dpendances explicitement dfinies pour
exprimer les contraintes requises par son contexte

dexcution ou sa ralisation
172
C
Composant
C
Composant
t
Unit autonome faisant partie dun systme ou dun sous-systme
quii encapsule
l un comportement
t
t (i
(i.e., iimplmentation)
l
t ti ) ett quii offre
ff
une ou plusieurs interfaces publiques
Partie constituante dun
d un systme qui peut tre remplace ou/et
rutilise
lment dimplmentation
p
((un sous-systme,
y
, un fichier excutable,,
une classe dimplmentation (i.e., non abstraite, etc.) muni

dinterface(s)
Chaque composant est le reprsentant dune ou plusieurs classes
qui implmentent un service lintrieur du systme
173
Composant
Granularit : Un composant peut reprsenter quelque chose
d aussi fin qu
daussi
quun
un objet, comme il peut reprsenter un soussous
systme complexe
Diffrence entre composant et instance de composant
Composant : vue de haut niveau dun lment logiciel qui
compose le systme (~classe)

Instance de composant: le composant effectivement utilis (~objet)
Exemples de composants:
Binaire excutable ( executable ), bibliotheque
dynamique/statique (librairy ), un fichier interprter

(file)
(file)
174
Composant
p
Unit autonome servant de bloc de construction pour le systme
Les composants implmentent typiquement des services
spcifiques
ifi
llapplication
li ti
La manifestation concrte dun composant est appel artfact
(instance du composant dploye sur le matriel)
Nimporte quel type de code sur nimporte quel support numrique
Code source, fichiers binaires, scripts, fichiers excutables, bases de
donnes, applications, etc.
manifestation
Order
175
Order.jar
Interface de composant
Permet un composant dexposer les moyens
utiliser pour communiquer avec lui

Types dinterfaces
Interface offerte : dfinit la faon de demander laccs
l accs un
service offert par le composant
Interface requise : dfinit le type de services (aide) requis par le
composant
Une interface est attache un port du composant
Port = point de communication du composant
Plusieurs interfaces peuvent tre attaches un mme port
176
Composants
p
et interfaces - Notation
EntreCmdes
Personne
C
Commande
d
interface requise
composant
Commande
<<provided interfaces>>
EntreCmdes
PaiementComptes
<<required interface>>
Person
177
PaiementComptes
interfaces offertes
Dpendances entre composants
Dpendance = relation entre deux composants
Types de dpendances
Un composant peut dpendre dun autre composant qui lui
f
fournit
it un service
i ou une iinformation
f
ti
Un composant peut dpendre dune classe qui implmente une
partie de son comportement. Dpendance de ralisation

Un composant peut dpendre dun artefact (code source,
fichier .jar, etc.) qui limplante concrtement. Dpendance de

manifestation
if t ti
178
composant
port
connecteur
Comp_A
interface
requise
q
interface
fournie
Comp_B
realisation
dpendance
Classe C
Classe_C
configuration
Deux ou plusieurs composants interagissent via un connecteur

Chaque lment architectural possde une structure et/ou
comportement pouvant tre dcrit par un modle UML appropri

179
Connecteur
Dans les systmes complexes, les interactions peuvent constituer
un enjeu encore plus important que les fonctionnalits des
composants individuels
Dfinition : lment architectural qui dfinit le type dinteractions
entre les composants et les rgles gouvernant ces interactions
Un connecteur relie les ports de deux ou plusieurs composants
Un connecteur dcrit un mcanisme de connection indpendant
de lapplication
l application
Reprsente un concept abstrait, paramtrable et indpendant des
composants spcifiques quil relie

Les
L attributs
tt ib t du
d connecteurs
t
dcrivent
d i
t ses proprits
it
comportementales
Exemple: sa capacit, le temps de latence, le type dinteraction
(binaire/n-aire, asymtrique/symtrique, dtails du protocole), etc.

180
Connecteur
Un connecteur peut avoir un ou plusieurs rles
Communication :rle le plus frquent
Coordination
C di ti : contrle
t l d
du calcul,
l l d
de lla ttransmission
i i d
des d
donnes,
etc.
t
Orthogonal aux autres rles

Conversion : permet linteraction entre composants dvelopps
i d
indpendamment
d
td
dans d
des llangages diff
diffrents
t par exemple
l
Facilitation : permet linteraction entre composants conus pour
interragir ensemble. Synchronisation, accs contrles aux donnes
partages, etc.
Selon le(s) rles quil doit remplir et le type de communication
souhaite entre deux composants,

p
, choix dun type
yp
Procedure call (comm + coord) , Data access (comm + conv), Event,
Stream, Linkage, Distributor, Arbitrator, Adaptor (conv)
181
Composants et relations notation
Une flche de dpendance permet de mettre en
relation des composant
p
via les interfaces requises
q
et
fournies
RechercheClient
Systme de
commande
RechercheClient
Repositoire
Clients
(3) dpendance
((1)) composant
p
AccsProduit
AccsProduit
182
(2) interface
Systme
di
dinventaire
t i
Composants
p
et relations notation
rservations
Planificateur
rservations
Gestionnaire
dhoraires
accsBD
mise jour
GUI
accsBD
mise jour
Runions_BD
183
Un style architectural
un patron dcrivant une architecture logicielle
permettant de rsoudre un p
p
problme p
particulier
Dfinit
Un ensemble de composants et de connecteurs (et leur type)
Les rgles de configuration des composants et connecteurs
(topologie)
Une spcification du comportement du patron
Des exemples de systmes construits selon ce patron
Constitue un modle prouv

p
et enrichi p
par
lexprience de plusieurs dveloppeurs

Comprhensibilit, maintenance, volution, rutilisation,
performance documentation
performance,
documentation, etc
etc.
184
Choix dune
d une architecture
Dpend des exigences fonctionnelles et non
fonctionnelles du logiciel
Choix favorisant la stabilit : lajout de nouveaux
lments sera facile et ne ncessitera en gnral que

des ajustements mineurs larchitecture
Influenc par certains modles connus de
dcomposition en composants (styles architecturaux)

g , orient objet)
j )
et de mode dinteractions ((e.g.,
185
Architecture Modle
Modle-Vue-Contrleur
Vue Contrleur (MVC)
Sparer
p
la couche interface utilisateur des autres p
parties
du systme (car les interfaces utilisateurs sont beaucoup

plus susceptibles de changer que la base de
connaissances
i
d
du systme)
t )
Compos de trois types de composants
Modle
M dl : rassemble
bl d
des d
donnes
d
du d
domaine,
i
d
des
connaissances du systme. Contient les classes dont les

instances doivent tre vues et manipules
Vue : utilis pour prsenter/afficher les donnes du modle dans
linterface utilisateur
Contrleur : contient les fonctionnalits ncessaires pour grer et
contrler les interactions de lutilisateur avec la vue et le modle
186
Architecture Modle
Modle-Vue-Contrleur
Vue Contrleur
Exp.
p Gnre le
code html pour le
browser
Vus par
les acteurs
View
Consulter ltat
(i.e. les donnes)
Exp. Interprte les

Exp
transmissions http
post du
browser
crer et
mettre jour
notifier changements
Modle
Contrleur
modifier
Exp.
p Le sous-systme
y
grant linformation.
187
Reoit les
vnements
des acteurs
Architecture Modle
Modle-Vue-Contrleur
Vue Contrleur
Modle : noyau de lapplication
Enregistre les vues et les contrleurs qui en dpendent
Notifie les composants dpendants des modifications aux donnes
Vue : interface (graphique) de lapplication

l application
Cre et initialise ses contrleurs
Affiche les informations destines aux utilisateurs
Implante les procdure de mise jour ncessaires pour demeurer
cohrente
Consulte les donnes du modle
Contrleur : partie de lapplication qui prend les dcisions
Accepte les vnement correspondant aux entres de lutilisateur
Traduit
T d it un
vnements
t (1) en d
demande
d d
de service
i adresse
d
au modle
dl
ou bien (2) en demande daffichage adresse la vue

Implmente les procdures indirectes de mise jour des vues si
ncessaire
i
188
Architecture Modle
Modle-Vue-Contrleur
Vue Contrleur
Avantages : appropri pour les
systmes interactifs,
particulirement ceux impliquant
plusieurs vues du mme modle
p
de donnes. Peut tre utilis
pour faciliter la maintenance de
la cohrence entre les donnes
distribues
Inconvnient : goulot
Dun p
point de vue conception
p
Diviser pour rgner : les composants
dt
dtranglement
l
t possible
ibl
189
peuvent tre conus indpendamment

Cohsion : meilleure cohsion qque si les
couches vue et contrle taient dans
linterface utilisateur.
Couplage : le nombre de canaux de
communication entre les 3 composants
est minimal
Rutilisabilit : la vue et le contrle
peuvent tre conus partir de
composants dj existants
Flexibilit : il est facile de changer
linterface utilisateur
Testabilit : il est possible de tester
lapplication indpendamment de
linterface

Diagramme de composants MVC
190
Architecture multi
multi-couches
couches
Composants : chaque composant ralise un service
Une couche offre un service (serveur) aux couches externes (client)
Service cr indpendamment du logiciel ou spcifiquement
Met profit la notion dabstraction
d abstraction, les couches externes sont plus
abstraites (haut niveau) que les couches internes
Connecteurs : dpendent
p
du p
protocole dinteraction souhait
entre couches
Systme ferm : une couche na accs quaux couches adjacentes.
Les connecteurs ne relient que les couches adjacentes

Systme ouvert : toutes les couches ont accs toutes les autres.
Les connecteurs peuvent relier deux couches quelconques
Exemples : souvent utilis pour les systmes implmentant
des protocoles de communication (TCP/IP)

191
Architecture multi
multi-couches
couches
Application
programs
Interface
utilisateur
Screen display
facilities
Logique
applicative
Accs au
systme
y
dexploitation
192
User account
management
g
Communication
rseau
File
e syste
system
Accs la
base de donnes
Kernel
(handling processes
and swapping
Architecture multi
multi-couches
couches
Dun point de vue conception
Rutilisation : on peut souvent rutiliser des
Diviser pour rgner : les couches
193
peuvent tre conues sparment

Cohsion : si elles sont bien conues,
l couches
les
h prsenter
t une cohsion
h i
par couche
Couplage : des couches infrieures
bien conues ne devraient rien savoir
propos des couches suprieures et
les seules connexions autorises
entre couches se font via les API
Abstraction : on na pas connatre
les dtails dimplmentation des
couches infrieures
R tili bilit : les
Rutilisabilit
l couches
h
infrieures peuvent tre conues de
faon offrir des solutions gnriques
rutilisables
couches
h dveloppes
d l par dautres
d
et quii
proposent le service requis
Flexibilit : il est facile dajouter de
nouveaux services construits sur les services
de plus bas niveau
Anticipation du changement : en isolant les
composants
p
dans des couches distinctes, le
systme devient rsistant
Portabilit : tous les services relatifs la
portabilit peuvent tre isols
Testabilit : les couches peuvent tre testes
indpendamment
Conception dfensive : les API des couches
constituent
i
des
d endroits
d i stratgiques
i
pour
insrer des assertions de vrification
Architecture n
n-niveaux
niveaux
Pour les systmes
y
distribus
Comparable une architecture par couches dont les couches
seraient distribues !
N.b.
N b Larchitecture multi
multi-couche
couche est gnralement utilise pour dcrire
la structure interne (non distribue) dun composant qui peut lui-mme

appartenir une architecture (distribue) n-partie
Par
P abus
b d
de llangage, lla notion
ti d
de ti
tier a pris
i lle sens d
de couche
h
distribue
Composants
p
: chaque
q niveaux est reprsent
p
p
par un composant
p
qui joue le rle de client et/ou de serveur
Connecteurs : relient un client un serveur. Connexion
asymtrique Doit supporter les communication distantes (e
asymtrique.
(e.g.,
g
requtes RPC, HTTP, TCP/IP)
Exemples
Client-serveur, Trois niveaux, Quatre niveaux
194
Architecture n
n-niveaux
niveaux
Architecture 2-niveaux (client-serveur ou client lourd)
Client
requte de service
Serveur
Architecture 3-niveaux (client lger)
Navigateur
Web
requte
d service
de
i
Logique
applicative
requte
d service
de
i
de B.D.
Serveurs
de
base de donnes
Architecture 4-niveaux
Client
195
Prsentation
(partie web)
Logique
Applicative
(calculs,
business)
Bases de
donnes
Architecture n
n-niveaux
niveaux
Architecture client-serveur
client serveur
Exemple typique : un systme dinformations utilisant
une base de donnes centrale. ((cas spcial
p
de
larchitecture avec rfrentiel)
Clients : reoivent les donnes de lutilisateur, initient les
ttransactions,
ti
etc.
t
Serveur : excute les transactions, assure lintgrit des
donnes
Architecture pair--pair = une gnralisation de
larchitecture client-serveur
Les composants peuvent tous la fois tre client et serveur
Conception plus difficile: flot de contrle plus complexe d la
possibilit de deadlocks
196
Architecture n
n-niveaux
niveaux
3 niveaux
Organisation en trois couches
Couche interface: Compos
p
dobjets
j
interfaces ((boundary
y
objects) pour interagir avec lutilisateur (fentres, formulaires,

pages Web, etc.)
Couche logique applicative : Comporte tous les objets de
contrle et dentits ncessaire pour faire les traitements, la
vrification des rgles et les notifications requises par
l application
lapplication
Couche de stockage : ralise le stockage, la rcupration et la
recherche des objets persistants
Avantage sur larchitecture client-serveur

Permet le dveloppement et la modification de diffrentes
i t f
interfaces
utilisateurs
tili t
pour lla mme
llogique
i
applicative
li ti
197
Architecture n
n-niveaux
niveaux
Architecture 3-parties
p
Rseau
Client X
Serveur d
S
de
B.D. Unix
Base de
donnes
corporative
March de
donnes
Client Windows
198
Serveur
Windows NT
Logique
applicative
Serveur de
B.D. Unix
Dpt de
donnes
Architecture n
n-niveaux
niveaux
noter que la tendance veut que la
Interface
gestionnaire
Gestion
des dossiers
Base de
donnes clients
199
partie cliente soit

De plus en plus mince, i.e., le client ne
fait quafficher un contenu HTML

La logique applicative est alors
responsable de crer les pages Web
afficher par le client
Il faut dissocier logique applicative et
prsentation des donnes
Architecture n
n-niveaux
niveaux
Architecture dont la couche logique applicative est dcompose
en
Couche Prsentation ((JSP,, servlets))
Prsentation du contenu statique: Contenu HTML ou XML affich par le
client
Prsentation du contenu dynamique : contenu organis et cr
d
dynamiquement
i
t par lle serveur web
b ((pour ensuite
it t
tre affich
ffi h en HTML/XML
par le client)
Couche Logique applicative (calculs purs) : ralise le cur des
traitements de lapplication
l application
Avantage sur larchitecture 3-niveaux
Permet de supporter un grand nombre de formats de prsentation
diffrents (propres chaque client)

client), tout en rutilisant certains des
objets de prsentation entre les clients. Rduction des redondances
Bien adapte pour les applications Web devant supporter plusieurs
types
yp de clients
200
Architecture n
n-niveaux
niveaux
Java Server Pages

- Partie
P ti cliente
li t
- Partie serveur
Clients
Serveur
Interface
Web
build
<<build>>
<<submit>>
submit
Interface
employ
de la banque
201
Prsentation
Serveur
<<build>>
Interface
ATM
Serveur de base
de donnes
Accs base de
donnes
do
es co
comptes
ptes cclients
e ts
<<submit>>
Gestion
oprations bancaires
<<build>>
<<submit>>
Architecture n
n-niveaux
niveaux
Dun point de vue conception
Diviser pour rgner : de faon
vidente, client et serveur

peuvent tre dveloppes
sparment
Cohsion : le serveur peut offrir
des services cohsifs au client

Couplage : un seul canal de
communication existe souvent

entre client et serveur
Rutilisation : il est possible de
ttrouver une bibliothque

bibli th
d
de
composants, interfaces, etc.
pour construire les systmes
Flexibilit : il est assez facile
202
dajouter de nouveaux clients et

serveurs
Portabilit : on peut dvelopper
de nouveaux clients pour de

nouvelles plateformes sans
devoir porter le serveur
Testabilit : on peut tester le
client et le serveur
indpendamment
Conception dfensive : on peut
introduire des oprations de

vrification dans le code traitant
les messages reus de part et
dautre

Commencer par faire une esquisse de larchitecture
En se basant sur les principaux requis des cas dutilisation ;
dcomposition en sous-systmes
Dterminer les p
principaux
p
composants
p
requis
q
Slectionner un style architectural
Raffiner larchitecture
Identifier
f les principales interactions entre les composants et les
interfaces requises
Dcider comment chaque donne et chaque fonctionnalit sera
distribue parmi les diffrents composants
Dterminer si on peut rutiliser un cadriciel existant (rutilisation) ou si
on peut en construire un (rutilisabilit)
Considrer chacun des cas dutilisation et ajuster larchitecture pour
quil soit ralisable

Dtailler larchitecture et la faire voluer
203

Commencer par faire une esquisse de larchitecture
En se basant sur les principaux requis des cas dutilisation ;
dcomposition en sous-systmes
Dterminer les p
principaux
p
composants
p
requis
q
Slectionner un style architectural
Raffiner larchitecture
Identifier
f les principales interactions entre les composants et les
interfaces requises
Dcider comment chaque donne et chaque fonctionnalit sera
distribue parmi les diffrents composants
Dterminer si on peut rutiliser un cadriciel existant (rutilisation) ou si
on peut en construire un (rutilisabilit).
Considrer chacun des cas dutilisation et ajuster larchitecture pour
quil soit ralisable

Dtailler larchitecture et la faire voluer
204

Dcrire larchitecture
l architecture avec UML
Tous les diagrammes UML peuvent tre utiles pour
d i lles diff
dcrire
diffrents
t aspects
t d
du modle
dl architectural
hit t l
Trois des diagrammes UML sont particulirement utile
pour dcrire
d i une architecture
hit t
logicielle
l i i ll
Diagramme de packages
Diagramme de dploiement
205

Diagramme
g
de p
packages
g
Paquetage = Collection dlments de modlisation UML (e.g.,
classes, use cases, etc.) groups ensemble car lis logiquement
Il ffautt essayer d
de maximiser
i i
lla cohsion
h i au sein
i d
des paquetages
t
(lments lis) et minimiser le couplage entre eux
Dpendance : un paquetage est dpendant dun
d un autre
sil lutilise
Si l Ch t
SimpleChat
Client
206
<<import>>
Common
OCSF
Client
Server

Offre une vue de haut niveau de larchitecture du
systme
y
Utilis pour dcrire le systme dun point de vue
implmentation
Permet de dcrire les composants dun systme et les
interactions entre ceux-ci
Illustre comment grouper concrtement et
physiquement les lments (objets, interfaces, etc.) du
systme au sein de modules quon
qu on appelle
composants
207

Les composants et le principe de sparation des
proccupations
La sparation des proccupation est le principe qui assure
llintgrit
intgrit fonctionnelle dun
d un composant
Chaque composant ralise une, et seulement une, fonction au
sein du systme, mais peut nanmoins exposer plusieurs
mthodes Typiquement
mthodes.
Typiquement, chaque composant est dfini par une
interface qui constitue son seul moyen dinteragir avec les
autres composants
L
Lutilisation
utilisation dune
d une interface pour communiquer avec les autres
composants du systme facilite la maintenance puisquon peut
alors en changer limplmentation sans affecter les autres
composants (induit un couplage plus faible du composant avec
le reste du systme)
Les classes dun composant devrait tre vues comme un
patron cohsif qui implmente la fonctionnalit du composant
208

Construction dun
d un diagramme de composants
Diviser pour rgner
Cohsion
C h i fforte
t
Faible couplage
Abstraction
Ab t ti
Rutilisabilit
Rutilisation
Etc.
209

Exemple d
dun
un diagramme de composants
210

Cours Projet de Conception OO - Mouna AYARI

Uploaded by

Document Information

Original Title

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 Projet de Conception OO - Mouna AYARI

Uploaded by

Copyright:

Available Formats

Cours: Projet de Conception Oriente

Remarque: Ce document doit tre complt par les notes de cours !

fondamentaux de lanalyse et de la conception oriente

la conception oriente objet dun projet

Modliser une application web",Edition EYROLLES,

EE5",Edition EYROLLES, Mai 2007

Remarque: Ce document doit tre complt par les notes de cours !

Etude pralable de projet

1.1. Etude pralable de projet

Remarque: Ce document doit tre complt par les notes de cours !

ltape initiale de tout projet. Elle est appele galement tape d

d'aboutir la mise au point de documents contractuels (faisant

Etude pralable du projet

dexpression des besoins

Etude pralable du projet

tudier quelques peu les besoins. Mais, cette tape na pas

approfondie (lobjectif de la phase dlaboration du projet)

Etude pralable du projet

dveloppement de ces activits :

Etude pralable du projet

Etude pralable du projet

1.2. Analyse du systme et

Remarque: Ce document doit tre complt par les notes de cours !

Spcification des besoins/exigences

dutilisation par paquetage (package)

dutilisation pour que celui-ci puisse dmarrer

dutilisation se termine avec succs, quil sagisse dun

Relations entre cas d

autre, de faon obligatoire

Relation dextension, formalise par le mot-cl

autre, de faon optionnelle

1.3. Fondements de base de la COO

Remarque: Ce document doit tre complt par les notes de cours !

Fondements de base de la COO

tats et leurs comportements

suffisant pour matriser la conception et le dveloppement orients

UML ett lla pense

est la plus importante et la plus difficile acqurir

Lanalyse met laccent sur une investigation

du problme et des besoins plutt que sur la

Le terme analyse est vaste:

Rappel sur llapproche

solutions des problmes plutt quune approche fonctionnelle

que linterface de lobjet, cest dire les traitements que lon

Rappel sur lapproche

permet de le distinguer de manire non ambigu

attributs dun objet

(mthodes) et dcrit les actions et les ractions de cet objet

Rappel sur lapproche

dobjets : Cest un modle qui dfinit les donnes et les

Terminologie oriente objet

Rappel sur lapproche

Rappel sur lapproche

Rappel sur lapproche

modifi) par les classes filles.

modifi) par les mthodes et seulement les mthodes de

Rappel sur lapproche

utilise ou redfinie par les classes hritires

les mthodes et seulement les mthodes de sa

Units de base organises en classes et partageant des

encapsules dans lobjet et ne peuvent pas tre manipules

priv (-): attribut non vu de lextrieur de lobjet

public (+): attribut visible pour toutes les classes