Vous êtes sur la page 1sur 210

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
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 !


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


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 !


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?

Etude pralable du projet


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

Etude pralable du projet


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 pralable du projet


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

Etude pralable du projet


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
Rappels sur les fondements de base de la conception oriente objet ddun
un projet

1.2. Analyse du systme et


spcification des exigences du projet
Licence Fondamentale en Informatique
Niveau: 3me anne 3me 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 !


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
Rappels sur les fondements de base de la conception oriente objet ddun
un projet

1.3. Fondements de base de la COO


Licence Fondamentale en Informatique
Niveau: 3me anne 3me 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 !


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

Rappel sur lapproche


l approche oriente objet
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

Rappel sur lapproche


l approche oriente objet
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

Rappel sur lapproche


l approche oriente objet
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.

Rappel sur lapproche


l approche oriente objet
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

Rappel sur lapproche


l approche oriente objet
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

Principes de loriente
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

Principes de loriente
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

Principes de loriente
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

Principes de loriente
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

Principes de loriente
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

Principes de loriente
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

Principes de loriente
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
Rappels sur les fondements de base de la conception oriente objet ddun
un projet

1.4. Modlisation des relations entre les


classes
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 !


50

Modlisation des relations entre les classes


Exemple de modlisation d
dune
une classe

Bonne pratique de manipulation des attributs

51

Modlisation des relations entre les classes


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

Solution de lexercice
l exercice dapplication
d application 1

74

Exercice d
dapplication
application 2
Etant donn le diagramme de classes suivant, dterminer la squelette du

code java correspondant

75

Solution de lexercice
l exercice dapplication
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
Rappels sur les fondements de base de la conception oriente objet ddun
un projet

1.5. Rappel sur les diagrammes de


modlisation UML
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 !


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
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 !


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)
Licence Fondamentale en Informatique
Niveau: 3me anne 3me 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 !


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
Mthodologies de COO processus unifi

2.2. Processus Unifi


Rational Unified Process (RUP)
Licence Fondamentale en Informatique
Niveau: 3me anne 3me 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 !


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
Rpartition du travail en phases, itrations et activits principales
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

Enchanement des activits de l'analyse


des besoins
Analyste
systme

Architecte

Spcificateur
p
de use-case

Concepteur
dinterface
114

Structurer modle
u-c.

baucher
modle u-c.

Assigner priorits 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.

Assigner priorits 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

Enchanement des activits de l'analyse des


besoins

Analyste
systme
y

Architecte

Spcificateur
de use-case

Concepteur
ddinterface
interface
118

Structurer modle
u-c.

baucher
modle u-c.

Assigner priorits 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

Enchanement des activits de l'analyse


des besoins
Analyste
systme
y

Architecte

Spcificateur
de use-case

Concepteur
ddinterface
interface
120

Structurer modle
u-c.

baucher
modle u-c.

Assigner priorits 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

Enchanement des activits de l'analyse des


besoins
Analyste
systme

Architecte

Spcificateur
de use-case

Concepteur
dinterface
122

Structurer modle
u-c.

baucher
modle u-c.

Assigner priorits 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
Rpartition du travail en phases, itrations et activits principales
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

Enchanement des activits de ll'analyse


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

Enchanement des activits de ll'analyse


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

Enchanement des activits de ll'analyse


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

Enchanement des activits de ll'analyse


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

Organisation en phases,
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
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

Enchanement des activits de conception

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

Enchanement des activits de conception

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

Enchanement des activits de conception

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

Enchanement des activits de conception

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

Organisation en phases,
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
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
Mthodologies de COO processus unifi

2.3 Mthodologie 2: Processus en Y:


2TUP (Two Track Unified Process)
Licence Fondamentale en Informatique
Niveau: 3me anne 3me 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 !


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


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 !


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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
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

lments architecturaux
Composants
p
et relations notation

rservations

Planificateur
rservations

Gestionnaire
dhoraires

accsBD
mise jour

GUI

accsBD

mise jour

Runions_BD
183

Styles architecturaux
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

Styles architecturaux
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

Dvelopper un modle architectural


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
Architecture 3-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
Architecture 3-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 4-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

Architecture 4-niveaux
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

Dvelopper un modle architectural


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

Dvelopper un modle architectural


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

Dvelopper un modle architectural


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 composants
Diagramme de dploiement

205

Dvelopper un modle architectural


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

Dvelopper un modle architectural


Diagramme de composants
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

Dvelopper un modle architectural


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

Dvelopper un modle architectural


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

Dvelopper un modle architectural


Exemple d
dun
un diagramme de composants

210