Génie Logiciel : Conception

COURS IGL
Cours 7 :
COURS 7 Conception

CONCEPTION

Mostefai Mohammed Amine – m_mostefai@esi.dz
Batata Sofiane – s_batata@esi.dz 1

Cours 7 – Conception OBJECTIFS DU COURS

Objectifs du cours

 Présenter l’activité de conception
 Faire le lien entre la conception haut niveau et la

Cours IGL, Copyright © 2011, ESI
conception bas niveau
 Présenter les classes, les interfaces et les composants de
conception
 Souligner la différence entre les diagrammes
comportementaux d’analyse et de conception
 Découvrir les principes d’une bonne conception

2

INTRODUCTION
Section 2 : AU GÉNIE
Section 1 : LOGICIEL
Diagramme de
Introduction Cours 7
composants Conception

Section 3 : Section 4 :
Styles Diagramme de
architecturaux déploiement
3


COURS IGL

Cours N° 7
Conception
Section 1 : Introduction

4


SECTION 1 -
Cours 7 – Conception INTRODUCTION

Définition

 Le modèle d’analyse définit les fonctionnalités (le quoi)
du système à développer

 La conception s’intéresse à comment ces fonctionnalités
seront implémentées
 La conception se base sur le modèle de besoins et le
modèle d’analyse
 Les solutions proposées par la conception repose sur le
domaine métier et le domaine technique

5

SECTION 1 -

Domaine métier et domaine technique

 Le domaine métier concerne les actions relatives au
métier du logiciel

 Le domaine technique inclut les actions techniques à
utiliser par la conception (base de données, techniques
de persistance,…etc.)
 Par exemple, un logiciel de facturation. La validation de
facturation fait partie du domaine métier. La bibliothèque
permettant l’enregistrement des données dans une BDD
fait partie du domaine technique.

6

SECTION 1 -

Produits de la conception

La conception produit les éléments suivants :
 Composants (sous-systèmes)

 Classes
 Interfaces
 Diagrammes comportementaux
 Diagrammes de déploiement

7

SECTION 1 -

Conception et analyse

Elément Analyse Conception

Sous- - Composants définissant la
systèmes composition du système

Classes La classe d’analyse représentent Les classes de conception sont
des concepts métier. Niveau bas plus détaillées et précises. Elles
de détail (signature de préparent le terrain aux
méthodes, types, …etc.) développeur pour
l’implémentation. En plus des
concepts métier, elles
contiennent les classes du
domaine technique.
8

SECTION 1 -


Elément Analyse Conception

Interface - Représente une « façade » du
système indépendante de
l’implémentation

Diagrammes Impliques les instances de Implique toutes les classes,
comportementaux classes d’analyse, orientés orientées technique
métier

Diagrammes de - Structure et architecture du
composants et système
déploiement

9

SECTION 1 -


 Un élément de l’analyse peut être relatif à 0,1 ou
plusieurs éléments de conception

 Cette relation est modélisée en UML avec une dépendance
avec le stéréotype « trace »

10

SECTION 1 -


 Un paquet d’analyse peut se traduire en un ou plusieurs
sous-systèmes (ou 0)

Paquet d'analyse
Sous-Système
0..* «trace» 0..*

11

SECTION 1 -


 Une classe d’analyse peut se traduire en plusieurs
interfaces et classes

Classe de
conception

«trace» 0..*

Classe d'analyse
0..*

«interface»
«trace»
Interface

12

SECTION 1 -

Processus

 La conception passe par deux étapes : la conception
architecturale et la conception détaillée

Conception Conception
architecturale détaillée

13

SECTION 1 -

Processus

 Activité assurée par les architectes
 La conception architecturale concerne une vision

descriptive des éléments de la conception : sous -
systèmes (composants), classes et interfaces
 La conception détaillée a pour but de donner les détails
précis des éléments produits dans la conception
architecturale et préparer au mieux l’implémentation

14

SECTION 1 -

Caractéristiques d’une bonne conception

 Répond avec précision aux besoins : la conception doit
permettre de fournir une solution technique répondant
aux attentes du client. Ne pas faire plus que ce qu’attend

le client.
 Séparation des fonctionnalités SoC (Separation of
Concerns) : Une bonne conception engendre un haut
niveau de modularité où chaque module a des
fonctionnalités précises et indépendantes. De tels
systèmes sont plus simples et plus faciles à maintenir

15

SECTION 1 -

Caractéristiques d’une bonne conception

 Simplicité : Quand plusieurs solutions s’offrent pour la
résolution du même problème, choisir la plus simple.
Plus une conception est simple, plus il est facile de la

comprendre et de la maintenir.
 Facilité de maintenance : Une bonne conception permet
d’isoler rapidement les erreurs et des les réparer
efficacement

16

COURS IGL

Cours N° 7
Section 1 : Introduction, Conception

débat (05 mns)

17


COURS IGL

Cours N° 7
Section 2 : Les classes de Conception

conception

18


SECTION 2 – CLASSES
Cours 7 – Conception DE CONCEPTION

Classe de conception

 La classe est l’élément principal de la conception
orientée objet

 La conception architecturale produit des classes et des
interfaces sont trop aller dans le détail
 La conception détaillée finalise le contenu des classes et
des interfaces (classes détaillées)
 Une classe détaillée est le commencement de l’opération
d’implémentation (codage)

19


Classe de conception

Spécifications

formelles
Classes
d'analyse
Expression de Analyse
besoins Conception
architecturale
Diagrammes
comportementaux

Diagrammes de Interfaces et
CU classes
Sous-systèmes

Interfaces et
classes Conception
détaillées détaillée

20


Provenance des classes de conception

 Les classes de conception peuvent provenir de deux
domaines : le domaine métier et le domaine technique

 Les classes du domaine métier sont une évolution des
classes d’analyse
 Les classes du domaine technique font partie des
bibliothèques ou frameworks faisant partie de la
solution technique (bibliothèques, GUI, …), par exemple
(Spring, Hibernate, Nhibernate, …)

21


Caractéristiques d’une classe de conception

 Une classe d’analyse définit un aperçu de la classe sans
s’occuper des détails techniques

 La classe de conception (domaine métier) est une
évolution de la classe d’analyse en tenant en compte tous
les détails (visibilité, paramètres, ..)
 La classe de conception contient la liste complète des
attributs et des opérations que devrait avoir la classe

22


Analyse vers Conception : Exemple

Analysis::Employe

- nom
- prenom Employe
- dateNaissance
# nom: string
- echelon
# prenom: string
+ promouvoir() : void - dateNaissance: DateTime
+ calculPrime() : void «trace» - echelon: short

+ promouvoir(short) : void
+ calculPrime(int) : double
+ getNom() : string
+ setNom(string) : void
+ getPrenom() : string
+ setPrenom(string) : void
+ getDateNaissance() : DateTime
+ setDateNaissance(DateTime) : void
+ getEchelon() : short
+ setEchelon(short) : void

23


Qu’est-ce qu’une bonne classe de
conceptio n ?

 Une bonne classe de conception est caractérisée par :
 Complétude : la classe doit fournir tout ce que l’on

attend d’elle
 Suffisance : la classe doit fournir ce qu’on attend d’elle
et pas plus
 Primitivité : Une classe ne doit pas fournir une multitude
de façons de réaliser le même but

24


Qu’est-ce qu’une bonne classe de
conceptio n ?

 Haute cohésion : une classe doit avoir un objectif
sémantique unique. Les opérations et les attributs de
cette classe doivent être relatifs à cet objectif.

 Faible couplage : la classe doit être liée au minimum de
classes possibles

25


L’Héritage

L’héritage est un excellent moyen de définir des relations
entre les classes mais les développeurs ont tendance à en
abuser. L’héritage a les inconvénients suivants :

 L’héritage impose un très grand couplage entre la classe
parent et la classe enfant
 L’encapsulation est très faible entre les classes
appartenant à la même hiérarchie
 La hiérarchie est inflexible, elle ne peut pas changer
pendant l’exécution
 Une bonne conception doit bien définir les relations de
hiérarchie

26


Héritage versus agrégation

Soit un site d’annonce, le site est composé d’annonces de
ventes, d’achat ou d’échange.

Annonce

Achat Vente Echange

Problème : si on veut transformer une annonce d’échange
en vente ?
27


Héritage versus agrégation

Annonce
Categorie

0..* 1

CategorieAchat CategorieVente CategorieEchange

28


Agrégation et composition

 Pour les classes du domaine métier, les associations entre
les classes d’analyse peuvent évoluer en agrégations et
compositions

 Une agrégation représente une relation faible entre des
objets
 Une composition représente une relation forte entre des
objets

29


Agrégation

 Une agrégation est une relation entre une classe
d’ensemble et des parts

 La classe d’ensemble contrôle les parts
 La part expose ses service à la classe d’ensemble
 La part peut ne pas être au courant de son appartenance
à une classe d’ensemble
 Une part peut exister en dehors de la classe d’ensemble
 Une part peut faire partie de plusieurs classes
d’ensemble

30


Agrégation

Ordinateur Périphérique

0..1 0..*

31


Composition

 La composition est similaire à l’agrégation sauf que la
composition est sémantiquement plus forte

 Une part ne peut pas exister en dehors de la classe
d’ensemble
 Une part ne peut appartenir qu’à une seule classe
d’ensemble
 La destruction de la classe d’ensemble conduit à la
destruction de ses parts

32


Composition

Rapport Annotation

1 0..*

1 1

1 1

Entête Pied

33

COURS IGL

Cours N° 7
Section 2 : Classes de Conception

conception (débat, 05 Mns)

34


COURS IGL

Cours N° 7
Section 3 : Interfaces et Conception

Composants

35


SECTION 3 –
Cours 7 – Conception I N T E R FA C E S E T
COMPOSANTS

Introduction

 La conception passe par diviser un système en sous-
systèmes représentés par des composants

 L’interaction et la médiation entre ces sous -systèmes se
fait en utilisant les interfaces

36

SECTION 3 –
COMPOSANTS

Qu’est-ce qu’une interface ?

 Une interface est un ensemble d’opérations liées
sémantiquement qui permettent de séparer la
spécification de l’implémentation

 Une interface ne contient pas d’implémentation. Les
classes se chargent d’effectuer cette implémentation. Ce
lien s’appelle réalisation.
 Les interfaces sont supportées par Java et C#. En C++ le
concept d’interface équivaut à une classe abstraite.
 Par convention, les interfaces commencent par I et
utilisent un objectif (par exemple, IComparable)

37

SECTION 3 –
COMPOSANTS

Interface fournie et interface requise

 Une interface fournie représente les fonctionnalités
assurées par une classe ou par un sous-système

 Une interface requise représente les fonctionnalités
nécessaires à une classe
 L’assemblage de deux composants sur la base d’une
interface fournie / requise est appelé contrat

38

SECTION 3 –
COMPOSANTS

Exemple

Le système de gestion d’un hélicoptère est composé de
deux sous-système, un sous-système de pilotage et un
système de tir.

L’hélicoptère peut avoir à bord plusieurs équipements, des
équipements de tir ou des équipements de navigation (par
exemple radar).
Quel que soit l’équipement de tir monté, quand le pilote
appuie sur le bouton rouge, il déclenche le tir de
l’ équipement monté quelle que soit sa nature (mitraillette,
antichar).

39

SECTION 3 –
COMPOSANTS

1 ère solution

EquipementMilitaire

AntiChar Mitraillette Radar
+ tirer() : void + tirer() : void

40

SECTION 3 –
COMPOSANTS

1 ère solution

Conceptuellement, la 1 ère solution n’est pas bonne. On doit
redéfinir la méthode « tirer » partout et pour placer un
matériel de tir, on peut mettre un « radar » à la place ce qui

est sémantiquement faux.

41

SECTION 3 –
COMPOSANTS

2 ème solution

EquipementMilitaire

EquipementDeTir Radar

+ tirer() : void

Mitraillette
AntiChar

42

SECTION 3 –
COMPOSANTS

2 ème solution

La 2 ème solution est meilleure que la 1 ère . Supposons qu’on
veuille monter sur l’hélicoptère un équipement anti -
incendie. Le matériel peut être activé avec le même bouton.

Problème 1 : le matériel anti-incendie n’est pas un
équipement matériel sémantiquement.
Problème 2 : une nouvelle classe AntiIncendie si elle
descend de EquipementDeTir, aura une forte dépendance.
Par exemple, elle pourra accéder à un code secret.

43

SECTION 3 –
COMPOSANTS

3 ème solution

«interface»
IEquipementDeTir
EquipementMilitaire + tirer() : void

Radar

Mitraillette AntiIncendie
AntiChar
+ tirer() : void + tirer() : void
+ tirer() : void

44

SECTION 3 –
COMPOSANTS

3 ème solution

La 3 ème solution résout les problèmes précédent en ajout
un très grand degré d’abstraction.

En plus elle facilite la conception du système global, le
sous-système de pilotage a pour interface requise
« IEquipementDeTir » et le sous-système de tir a cette
interface comme interface fournie.

45

SECTION 3 –
COMPOSANTS

3 ème solution

Le système est composé de plusieurs sous -systèmes

«subsystem»
MitrailletteComp
IEquipementDeTir
Mitraillette

«subsystem» «subsystem»
Pilotage IEquipementDeTir IEquipementDeTir AntiCharComp

AntiChar

IEquipementDeTir «subsystem»
AntiIncendieComp

AntiIncendie

46

SECTION 3 –
COMPOSANTS

3 ème solution

L’assemblage permet de lier deux sous -systèmes

«subsystem» «subsystem»
Pilotage IEquipementDeTir IEquipementDeTir AntiCharComp

AntiChar

47

SECTION 3 –
COMPOSANTS

Trouver les interfaces

 Examiner chaque association, vérifier si une association doit
être figée ou flexible
 Examiner les opérations ayant un lien sémantique et voir s’il

est bénéfique de les factoriser en une interface
 Trouver les opérations qui se trouvent dans plusieurs classes
et dont l’héritage ne convient pas pour les faire lier
 Trouver les classes qui jouent le même rôle dans le système.
Ce rôle peut être factorisé en une interface.
 Réfléchir en terme d’extensibilité, plus on utilise les
interfaces, plus on est extensible
 Identifier les interconnexions entre les composants et les
sous-systèmes

48

SECTION 3 –
COMPOSANTS

Concevoir avec les interfaces

 Le patron de conception « Façade » permet de montrer
d’un sous-système que la partie intéressante à utiliser

 L’interface est un élément parfait pour implémenter la
façade
 En plus, l’interface facilite la conception du système sous
forme de couches

49

SECTION 3 –
COMPOSANTS

Exemple

 Soit un système de gestion de documents composé de
trois module : persistance, métier et GUI

 La partie persistance permet d’enregistrer un document.
Ce module enregistre le document dans plus entrepôts.
Pour récupérer un document, le module cherche la
version la plus récente dans les entrepôts et la renvoie.
 La partie métier concerne les opérations sur les
documents telles que la modification ou l’annotation.
 La partie GUI concerne l’affichage des information.

50

SECTION 3 –
COMPOSANTS

Exemple

 Le patron de conception « Façade » permet de cacher
tous les détails inutiles à l’extérieur. Quel que soit le
mécanisme de persistance, on doit être capable de

sauvegarder un document ou de trouver un document.

51

SECTION 3 –
COMPOSANTS

Exemple

«interface» «interface»
IDocumentPersistance IGestionDocuments
+ trouverDocument(id :string) : Document + trouverDocument(id :string) : Document
+ savegarderDocument(doc :Document) : void + sauvegarderDocument(doc :Document) : void
+ modifierDocument(doc :Document) : void
+ annoterDocument(doc :Document) : void

52

SECTION 3 –
COMPOSANTS

Exemple

«subsystem»
GUI

IGestionDocuments

IGestionDocuments

«subsystem»
Metier

IDocumentPersistance

IDocumentPersistance

«subsystem»
Persistance

53

SECTION 3 –
COMPOSANTS

Avantages et inconvénients des interfaces

 L’interface permet de réduire les dépendances au
maximum et par conséquent, réduire le couplage

 L’interface règle certains problèmes que l’héritage ne
règle pas
 Plus on essaye de rendre l’architecture flexible, plus elle
est complexe

54

COURS IGL

Cours N° 7
Section 3 : Interfaces et Conception
Composants, débat (10
mns)

55


COURS IGL

Cours N° 7
Section 4 : Les diagrammes Conception
comportementaux de
conception

56


SECTION 4 – LES
DIAGRAMMES
Cours 7 – Conception C O M P O R T E M E N TA U X D E
CONCEPTION

Introduction

 Pour modéliser certains aspects dynamiques, la
conception utilise les mêmes diagrammes que l’analyse
(voir cour 5)

 La différences entre les deux est que les diagrammes de
conception ont 1) plus d’éléments (classes métier +
technique) et 2) adressent éventuellement un aspect
technique métier (par exemple séquencement de
processus, traitement parallèle,…etc)
 Parmi les livrables de la conception, figurent aussi des
diagrammes comportementaux quand c’est nécessaire

57

COURS IGL

Cours N° 7
Section 4 : Les diagrammes Conception
comportementaux de
conception, débat (05 mns)

58


COURS IGL

Cours N° 7
Section 5 : Principes de Conception

conception

59


SECTION 5 –
Cours 7 – Conception PRINCIPES DE
CONCEPTION

Principes

DIP (The
SRP (Single
Isoler les parties Dependency

Responsibility
changeantes Inversion
Principle)
Principle)

LSP (LiskPov
OCP (Open Closed DRY (Don’t
Substitution
Principle) Repeat Yourself)
Principle)

ISP (Interface
Segregation
Principle)

60

SECTION 5 –
CONCEPTION

Isoler les parties changeantes

 Essayer de changer les parties changeantes dans d’autres
classes

 Par exemple, dans la classe Alarme, la méthode « Régler »
est figée mais « Sonner » dépend du type d’alarme. Cette
méthode est aussi appelée à évoluer si d’autres types
sont créés
Alarme
- heureAlarme: DateTime

+ regler(DateTime) : void
+ sonner() : void

61

SECTION 5 –
CONCEPTION

Isoler les parties changeantes

 La conception ci-dessous permet d’isoler les
changements et en prévoir d’autres

Alarme
ModeleAlarme
- heureAlarme: DateTime
+ sonner() : void
0..* 1
+ regler(DateTime) : void

AlarmeRecurrente
AlarmeSimple
+ sonner() : void
+ sonner() : void

62

SECTION 5 –
CONCEPTION

SRP

 Single Responsibility Principle = Principe de
fonctionnalité unique

 Une classe doit avoir une raison unique de changer
 Une classe ne doit pas faire « trop » de choses

63

SECTION 5 –
CONCEPTION

SRP- Exemple

 La classe MediaPlayer ne respecte pas le SRP car le
changement de l’algorithme d’audio ou de vidéo
affecteraient la classe

MediaPlayer

+ playAudio(file :string) : void
+ playVideo(file :string) : void

64

SECTION 5 –
CONCEPTION

SRP- Exemple

 Un premier pas consiste à isoler la vidéo et l’audio

AudioPlayer

1
MediaPlayer
1

1
VideoPlayer
1

65

SECTION 5 –
CONCEPTION

DIP

 Dependency Inversion Principle = Principe d’inversion de
dépandance

 Les modules de haut niveau ne doivent pas dépendre des
modules de bas niveau. Les deux doivent dépendre
d’abstraction
 Les abstraction ne doivent pas dépendre des détails,
c’est les détails qui doivent dépendre des abstractions

66

SECTION 5 –
CONCEPTION

DIP - Exemple

 La classe AudioPlayer dépend de MP3Player. La
conception ne respecte pas DI Chaque changement de
l’algorithme MP3 va impacter AudioPlayer

AudioPlayer
AudioFormatPlayer
+ play(string) : void
1

1

MP3Player


67

SECTION 5 –
CONCEPTION

DIP - Exemple

 La classe AudioPlayer doit dépendre de l’abstraction au
lieu de l’implémentation

68

SECTION 5 –
CONCEPTION

DIP - Exemple

 La classe AudioPlayer dépend de MP3Player. La
conception ne respecte pas DI Chaque changement de
l’algorithme MP3 va impacter AudioPlayer

AudioPlayer AudioFormatPlayer

+ play(string) : void 1 1 + play(string) : void

MP3Player


69

SECTION 5 –
CONCEPTION

OCP

 OCP : Open-Closed Principle (Principe Ouvert-Fermé)
 Une classe doit être ouverte à l’extension et fermée à la

modification
 Trouver les comportements appelés à évoluer et les
transformer en abstraction

70

SECTION 5 –
CONCEPTION

OCP - Exemple

 La classe AudioPlayer pour lire des fichiers audio, utilise
la classe File qui renvoie les données sous format
d’octets (getData).

 La classe AudioPlayer ne respecte pas OCP car elle se
restreint au données provenant de fichiers. Si on veut lire
des données depuis internet, FTP ou depuis le streaming,
il faut changer la classe (ouverte à la modification)

71

SECTION 5 –
CONCEPTION

OCP - Exemple

AudioPlayer File

+ play(stream :File) : void + getData() : byte[]

72

SECTION 5 –
CONCEPTION

OCP - Exemple

 La solution est de dépendre d’abstractions. Même si on ajoute un
nouveau type de flux (par exemple MemoryFile), on ne change rien

«interface»
AudioPlayer IStream StreamingFile
+ play(stream :IStream) : void + getData() : byte[]
+ getData() : byte[]

File InternetFile FTPFile
+ getData() : byte[] + getData() : byte[] + getData() : byte[]

73

SECTION 5 –
CONCEPTION

DRY

 DRY – Don’t Repeat Yourself
 Pour des raisons diverses, il y a des duplications dans le

code
 Chaque ligne de code peut être source de bugs, la
duplication augmente ce risque
 Une bonne conception minimise les duplications
 Il y a des duplications plus faciles à éviter et à détecter
que d’autres

74

SECTION 5 –
CONCEPTION

LSP – Liskov Substitution Principle

 L’héritage est une solution à OCP mais comment réguler
l’héritage ?

 Principe : Les sous-types doivent être des substituts pour
leur ancêtres

75

SECTION 5 –
CONCEPTION

LSP – Exemple

AESProv ider «interface»

IEncryptionProv ider
+ EncryptString(string) : void + EncryptString(string) : void

MD5Prov ider

+ EncryptString(string) : void

76

SECTION 5 –
CONCEPTION

LSP – Problème

 AES permet de restituer le mot de passe, mais est -ce que
MD5 le permet
«interface»

AESProv ider
IEncryptionProv ider
+ DecryptString(string) : void + DecryptString(string) : void
+ EncryptString(string) : void + EncryptString(string) : void

MD5Prov ider

+ DecryptString(string) : void
+ EncryptString(string) : void

Passw ordRecov ery

77

SECTION 5 –
CONCEPTION

LSP – Remèdes

 Eviter une vision isolatrice des entités
 Avoir une vision plus globale et plus anticipative

78

SECTION 5 –
CONCEPTION

ISP – Interface Segregation Principle

 Les clients ne doivent pas être forcées à dépendre de
méthodes qu’elles n’utilisent pas

79

SECTION 5 –
CONCEPTION

ISP – Problème

 ERP n’utilise pas SendMail et MailClient n’utilise pas
CheckPassword

80

SECTION 5 –
CONCEPTION

ISP – Solution

81

COURS IGL

Cours N° 7
Section 5 : Principes de Conception

conception, débat 05 mns

82


Cours 6 – Introduction aux BIBLIOGRAPHIE
architectures de logiciels

Bibliographie

 UML2 and the Unified Process, Second Edition, Addison
Wesley 2005

 Software Development and Professional Practice, John
Dooley, APress, 2010

83

Génie Logiciel : Conception

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Génie Logiciel : Conception

Ähnlich wie Génie Logiciel : Conception (20)

Mehr von Mohammed Amine Mostefai

Mehr von Mohammed Amine Mostefai (20)

Génie Logiciel : Conception