15/11/2017

Chapitre 4 La Conception

Cours « Génie Logiciel 1 » Niveau II2

AU: 2017/2018

PLAN

 Introduction  Présentation de la conception  Principes de la conception  Qualités d’une bonne conception  Conception architecturale

 Définitions  Choix d’une architecture  Styles architecturaux

C o u r s « G L - A C O O » E N S I

INTRODUCTION

D E L’ A N A LY S E À L A C O N C E P T I O N

Analyse Quoi-Faire ?

1 .I NT RODUCT I ON

Conception Comment-Faire ?

 Difficulté de la conception:

 La conception ne se contente pas d’identifier le

problème mais doit lui apporter une solution valide.

 Processus créatif

 Activité itérative/incrémentale qui transforme

progressivement les besoins vers un produit final.

 Étape cruciale du développement logiciel: pont entre l’analyse des besoins et l’implémentation.

C o u r s « G L - A C O O » E N S I

15/11/2017

D E L A C O N C E P T I O N À L’ I M P L É M E N TAT I O N

1 .I NT RODUCT I ON

 L’implémentation est la mise en œuvre des choix issus de la

conception.

 L’implémentation doit pouvoir répondre aux contraintes de

réalisation sans mettre en cause les choix de conception.

C O N C E P T I O N V S I M P L É M E N TAT I O N - E X E M P L E T Y P I Q U E

1 . I NT RODU CT I O N

 On introduit, lors de l’implémentation, une optimisation

qui brise une abstraction issue de la conception. Ceci témoigne d’une mauvaise conception : une spécification non fonctionnelle concernant l’efficacité n’a pas été prise en compte.

Ceci témoigne d’une mauvaise implémentation : les choix de

conception doivent toujours être respectés par l’implémentation.

C o u r s « G L - A C O O » E N S I

15/11/2017

PRÉSENTATION DE LA CONCEPTION

DÉFINITIONS

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 La conception est un processus de résolution de problèmes

dont l’objectif est d’identifier la meilleure façon:  d’implémenter les besoins fonctionnels d’un système...  tout en respectant les contraintes imposées par les besoins non

fonctionnels...

 et en adhérant à des principes de base menant à un logiciel de qualité.

 La conception propose une solution au problème spécifié

lors de l’analyse :  architecture de l’application (architecture logicielle et architecture

physique),

 description détaillée des modules, des interfaces utilisateurs, des

données.

C o u r s « G L - A C O O » E N S I

DÉFINITIONS

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 Activité Intellectuelle

 Créativité  Expérience.

 Pas de recettes toutes faites.

 mais il existe des méthodes (principes & bonnes pratiques)

pouvant être de bons conseils

 Résultat de la phase de conception = conception ou «

design ».

 Une bonne conception contribue à la qualité du logiciel:

fiabilité, correction, évolutivité, etc.

LA CONCEPTION = SÉRIE DE DÉCISIONS

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 Lors de la résolution d’un problème, tout concepteur fera

face à une série de problèmes: 1. Ce sont des sous-problèmes devant être résolus. 2. Chacun de ces problèmes peut être solutionné de différentes

façons

=> Ce sont des options de conception.

3. Le concepteur doit donc prendre des décisions de conception afin de résoudre chacun de ces sous-problèmes en tenant compte:

 des exigences  du design courant  de la technologie disponible  des principes de bon design  de l’expérience passée

Il faudra être en mesure de toujours choisir la meilleure alternative.

C o u r s « G L - A C O O » E N S I

15/11/2017

LA CONCEPTION = SÉRIE DE DÉCISIONS

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 L’espace engendré par l’ensemble des solutions possibles

pour un design s’appelle l’espace de design  Par exemple:

fat-client

thin-client

separate user interface layer for client

no separate user interface layer for client

client-server

monolithic

programmmed in Java

programmed in Visual Basic

programmed in C++

ÉTAPES DE LA CONCEPTION

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 La conception passe par deux étapes:

C o u r s « G L - A C O O » E N S I

ÉTAPES DE LA CONCEPTION

 Conception architecturale

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 =conception de haut niveau= conception globale  Première étape qui consiste à définir les fonctions des éléments d'un

système et leurs relations fonctionnelles.

 Objectif: Structuration et organisation générale du système à concevoir

 Contient la description des éléments principaux du système, les

relations entre eux, les contraintes à respecter, les motifs et la logique de cette décomposition.

 La division du système en sous-systèmes et composantes

 Comment ceux-ci seront interconnectées.  Comment vont-ils interagir.  Leurs interfaces.  Qu’est ce qu’ils contiennent (Conception des modules)

 SD, opérations et associations.

C o u r s « G L - A C O O » E N S I

ÉTAPES DE LA CONCEPTION

 Conception détaillée

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 =conception de bas niveau  Étape qui consiste à détailler les résultats de l’analyse fonctionnelle,

jusqu'à un niveau suffisant pour en permettre finalement le codage dans un langage de programmation choisi.

 Définition d’un design logiciel respectant le plan de la conception

architecturale.

 Objectif: détailler les éléments produits dans la conception architecturale

et préparer au mieux l’implémentation:  description précise de chaque module  algorithmes mis en œuvre  traitements effectués en cas d'erreur  Conception des données  Conception des algorithmes:  Étude de leur efficacité.  Conception de protocoles:

 Les messages et règles utilisés dans la conversation.

C o u r s « G L - A C O O » E N S I

15/11/2017

ÉTAPES DE LA CONCEPTION

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

But: Décomposition et raffinement progressif du système en

modules de plus en plus détaillés.

C o u r s « G L - A C O O » E N S I

PROCESSUS DE CONCEPTION

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

Plusieurs étapes :

 Conception de l’architecture  Conception de l’interface  Conception des composants

 Structures de données  Algorithmes

Interface

Système

15/11/2017

PROCESSUS DE CONCEPTION

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

Spécification des besoins

Conception de l’architecture

Conception de l’interface

Conception du composant

Architecture

Spécification Interface

Struct. Don

Algo.

Spécification S. D. & Algo.

C o u r s « G L - A C O O » E N S I

L’ACTIVITÉ DE CONCEPTION

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

Spécifications des besoins

Principes fondamentaux du Génie Logiciel

CONCEPTION

Modélisation des données

Architecture du système

Interface Utilisateur

Composants (modules)

Étape décisive pour :  la fiabilité  l'efficacité  la maintenabilité  la réutilisabilité

C o u r s « G L - A C O O » E N S I

15/11/2017

PRINCIPALES ACTIVITÉS

2 . P R É S E N TAT I O N D E L A C O N C E P T I O N

 la conception des structures des données

conçoit et spécifie en détail les structures de données

 La conception de l’architecture du système : définir les s/systèmes - identifie les sous-systèmes qui composeront le système global - établit une description des services supportés par chaque sous- système

 la conception de l’interface : identifier et documenter les

interactions entre s/systèmes.

 la conception des composants : services offerts

- découpe les sous-systèmes en plusieurs composants - conçoit et spécifie en détail les algorithmes pour réaliser les différents services

C o u r s « G L - A C O O » E N S I

PRINCIPES DE CONCEPTION

15/11/2017

PRINCIPES DE BASE

3 .P RI NCI P ES DE LA CONCEP T I ON

La conception ne doit pas réinventer la roue

 Le temps est précieux  exploiter des solutions existantes

La conception doit être uniforme et intégrable

 - Règles de style et de format préalablement définies pour toute l’équipe

- Définition minutieuse des interfaces entre les composants

La conception doit avoir une structure facilitant

l’évolution  - Traçabilité entre les besoins et les éléments de la conception - Application des principes du génie logiciel (modularité,

abstraction, etc.)

PRINCIPES DE BASE

3 .P RI NCI P ES DE LA CONCEP T I ON

La conception n’est pas le codage et vice versa

 Distinguer les niveaux d’abstraction conceptuel/code source

La conception doit miser sur la qualité  Divers concepts et mesures sont disponibles

La conception doit être revue pour minimiser les erreurs

sémantiques  Faire attention aux omissions, ambiguïtés et inconsistances

C o u r s « G L - A C O O » E N S I

15/11/2017

QUELQUES PRINCIPES DE CONCEPTION

3 .P RI NCI P ES DE LA CONCEP T I ON

1. Modularité 2. Abstraction 3. Encapsulation 4. Anticipation des changements 5. Réutilisabilité 6. Réutilisation 7. Forte cohésion 8. Faible couplage

Qualités logicielles en jeu

MODULARITÉ

3 .P RI NCI P ES DE LA CONCEP T I ON

 Objectif: déterminer la structure modulaire du système à

développer

unité de conception

• unité de codage et tests • unité d'intégration et d'archivage • unité de réutilisation • unité de maintenance

 Répondre aux questions:  Quels sont les modules ?  Quelles relations lient les modules entre eux ?

C o u r s « G L - A C O O » E N S I

15/11/2017

MODULARITÉ

3 .P RI NCI P ES DE LA CONCEP T I ON

 principe : séparer le système en composants logiques

 modules

 avantages :

 réduction de complexité

 les modules peuvent être

 conçus et construits séparément  réutilisés

 système modifié en changeant un nombre limité de modules

MODULE: DÉFINITION

3 .P RI NCI P ES DE LA CONCEP T I ON

 Un module est un composant d’une application, contenant des définitions de données et/ou de types de données et/ou de fonctions et constituant un tout cohérent.  Par exemple des méthodes, des classes, des paquetages sont des modules

en Java.

 On peut définir un module comme un fournisseur de

ressources ou/et de services.

 Quand on décompose un système en modules il faut décrire

précisément les relations entre ces modules.  Quels sont les modules ? (fonction, procédure, Classe, paquet,

composant : JavaBean, EJB, ActiveX, COM, DCOM, …)

 Quelles relations lient les modules entre eux ?

C o u r s « G L - A C O O » E N S I

15/11/2017

MODULARITÉ

3 .P RI NCI P ES DE LA CONCEP T I ON

 Relations entre modules : Deux types de relations sont

utiles pour décrire la structure d’un système  Relation « UTILISE »: On dit que Mi UTILISE Mj si Mi requiert la présence de Mj car Mj lui fournit des ressources ou des services.  Exemple : Appel de procédure  UML: association, liens de dépendance…

 Relation « CONTIENT »: On dit que Mi CONTIENT Mk si Mi est réalisé en assemblant un ou plusieurs modules dont le module Mk  Exemple : regroupement en paquetages UML  Déclaration d’une classe à l’intérieur d’une autre classe  UML: regroupement en paquetages  (aussi agrégation/composition)

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « UTILISE »

On dit que Mi UTILISE Mj si Mi requiert la présence de Mj car Mj lui fournit des ressources ou des services. La relation UTILISE doit idéalement être une hiérarchie. Pourquoi est-ce préférable ?

 Facilite la compréhension de la structure (par niveau d’abstraction)  Facilite le test unitaire…  Autrement: on peut se retrouver avec un système qui ne marche pas

jusqu’à ce que tout marche (Parnas)

C o u r s « G L - A C O O » E N S I

15/11/2017

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « UTILISE »

 Relation définie statiquement i.e. indépendamment de

toute exécution du logiciel.

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « UTILISE »

C o u r s « G L - A C O O » E N S I

15/11/2017

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « UTILISE »

 On doit trouver une solution de compromis raisonnable qui

offre un couplage faible.

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « UTILISE » On recommande une relation « UTILISE » qui présente une silhouette profonde… A éviter: râteau !

C o u r s « G L - A C O O » E N S I

15/11/2017

MODULARISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

Relation « Contient »

 On dit que Mi CONTIENT M k si Mi est réalisé en

assemblant un ou plusieurs modules dont le module M k

 Exemple: inclusion de packages et de classes en Java

MODULARITÉ

3 .P RI NCI P ES DE LA CONCEP T I ON

 Identifier les modules en assurant:  forte cohésion à l'intérieur du module  faible couplage entre les modules

C o u r s « G L - A C O O » E N S I

15/11/2017

ABSTRACTION

3 .P RI NCI P ES DE LA CONCEP T I ON

 Maintenir le niveau d’abstraction aussi élevé que

possible

 La complexité d’un design est réduite lorsqu’un maximum

de détails se trouve masqué  Une abstraction de qualité utilise toujours le principe de

masquage de l’information

 Une abstraction permet de saisir l’essence d’un système sans avoir

à en connaître les détails de son implémentation

ABSTRACTION - EXEMPLE

3 .P RI NCI P ES DE LA CONCEP T I ON

 En orientée objet, les classes sont des abstractions de données contenant des abstractions de procédures  Attribuer une visibilité privée aux variables permet d’accroître la

qualité de l’abstraction.

 Réduire le nombre de méthodes publiques accroît la qualité de

l’abstraction

 Une meilleure abstraction est obtenue en définissant des

méthodes ayant peu de paramètres

 La création de super-classes et d’interfaces accroît

considérablement la qualité de l’abstraction.

C o u r s « G L - A C O O » E N S I

ENCAPSULATION

3 .P RI NCI P ES DE LA CONCEP T I ON

 Associer à un composant une vue externe et une vue

interne.  Vue externe : c'est l'interface, elle définit ce que le composant doit

faire.

 Vue interne: c'est l'implémentation, elle définit comment il le fait.

 Exemple : PILE  initialiser,  empiler,  dépiler.

ANTICIPATION DES CHANGEMENTS

3 .P RI NCI P ES DE LA CONCEP T I ON

 Un des principaux soucis de l’activité de conception:

développer un design qui facilite l’ajustement du système aux changements:  Perfectionnement du système imposé par les nouvelles exigences

du client.

 Adaptations imposés par la modification de l’environnement

matériel, social, etc.

 Importante qualité logicielle en jeu: maintenabilité

C o u r s « G L - A C O O » E N S I

15/11/2017

«CONCEVOIR POUR CHANGER»

3 .P RI NCI P ES DE LA CONCEP T I ON

Types de changements

Sources de vrais changements

C o u r s « G L - A C O O » E N S I

«CONCEVOIR POUR CHANGER»

3 .P RI NCI P ES DE LA CONCEP T I ON

Pourquoi? Quelques conséquences indésirables

 Un design, même « merveilleux », peut se révéler

extrêmement difficile et coûteux à adapter.  Conséquence: nécessité de refaire un tout nouveau design pour

intégrer un changement apparemment mineur…

 En essayant d’accommoder l’architecture aux changements, le concepteur risque de briser l’élégante structure initiale du design.  Conséquence: application de plus en plus difficile à maintenir et

inspirant peu confiance (fiabilité compromise ?)

15/11/2017

«CONCEVOIR POUR CHANGER»

3 .P RI NCI P ES DE LA CONCEP T I ON

Types de changements

 Changement d’algorithme.  Changement de représentation des données.  Changement au niveau des périphériques.  Changement de l’environnement social.  Changements dus au processus de développement.

ANTICIPATION DES CHANGEMENTS

3 .P RI NCI P ES DE LA CONCEP T I ON

 Réduire le couplage et accroître la cohésion  Créer des abstractions  Ne pas introduire de constante numérique ad hoc (pas de

hard-coding)

 Permettre un maximum d’options

 Ne pas restreindre inutilement les options

 Utiliser du code réutilisable et rendre le code réutilisable

C o u r s « G L - A C O O » E N S I

15/11/2017

RÉUTILISABILITÉ

3 .P RI NCI P ES DE LA CONCEP T I ON

 Accroître la réutilisabilité autant que possible  Concevoir le design de façon à ce que les différents aspects

du système soient utilisables dans différents contextes  Généraliser le design autant que possible  Simplifier le design autant que possible  Ajouter des options aux différents modules

RÉUTILISATION

3 .P RI NCI P ES DE LA CONCEP T I ON

 Réutiliser autant de composantes que possible  La réutilisation est le principe complémentaire au principe

de réutilisabilité  Réutiliser les designs existants permet de tirer profit de l’effort

investi par les concepteurs de composantes réutilisables

C o u r s « G L - A C O O » E N S I

UN CERCLE VICIEUX S’INSTALLE

 Les développeurs de logiciels ne conçoivent pas de

composantes réutilisables, il n’y a donc rien à réutiliser.

 Pour résoudre ce problème, il faut reconnaître que:

 Ce cercle vicieux a un coût  Investir dans la réutilisabilité est important  S’assurer de la qualité des composantes réutilisables

produites est essentiel

De cette façon, les réutilisateurs potentiels auront confiance en ce produit La qualité globale du logiciel est celle de sa composante la plus faible

 Le développement de logiciel réutilisable mène souvent,

en fait, à une simplification du logiciel

DÉVELOPPEMENT POUR ET PAR LA RÉUTILISATION

 Le développement par la réutilisation logicielle impose un

cycle de production-réutilisation perpétuel et une architecture logicielle normalisée.

 Une réutilisation bien orchestrée nécessite la création et le maintien

d'une bibliothèque logicielle et un changement de focus;

 créer une application revient à créer les composants de bibliothèque

nécessaires puis à construire l'application à l'aide de ces composants.  Une telle bibliothèque, facilitant le développement d'application est un

framework (cadriciel) d'entreprise et son architecture, ainsi que sa documentation sont les pierres angulaires de la réutilisation logicielle en entreprise.

 L'architecte doit

 explorer la bibliothèque pour trouver les composants logiciels

appropriés

 puis créer les composants manquants, les documenter et les intégrer à

la bibliothèque.

 Dans une grande entreprise, ce rôle est rempli par UN

responsable du développement harmonieux de la bibliothèque et de la conservation de l'intégrité de son architecture. (l'architecte en chef )

C o u r s « G L - A C O O » E N S I

15/11/2017

DÉVELOPPEMENT PAR LA RÉUTILISATION

 Aucun logiciel de grande taille n’est développé depuis zéro

aujourd’hui

 Utilisation de

 « Bouts de code »  Structures + fonctions / Classes + méthodes  Bibliothèques  Cadriciels: cadre d’application (fraweworks)

BIBLIOTHÈQUES

 « Bibliothèque [library] logicielle est un ensemble de

fonctions utilitaires, regroupées et mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire »

 Plutôt que de coder une procédure courante dans chaque

programme en ayant besoin, on rassemble ces procédures dans des bibliothèques.

 Si un programme a une fonction à remplir et que celle-ci se trouve

en bibliothèque, il l'utilisera directement.

 Les bibliothèques logicielles se distinguent des exécutables dans

la mesure où elles ne représentent pas une application

 Exemples

 La bibliothèque de classes Java  La STL de C++

C o u r s « G L - A C O O » E N S I

15/11/2017

BIBLIOTHÈQUES

 L'organisation classique des bibliothèques se fait par découpage thématique des fonctions, suivant les services qu'elles rendent:  Bibliothèques de bas niveau ou bibliothèques système : elles

fournissent des services d'interface avec le système d'exploitation, avec les périphériques, ou fournissent des outils génériques :  bibliothèques d'entrées/sorties : fonctions de lecture et d'écriture de fichiers, de périphériques d'entrée/sortie comme le clavier, l'écran, etc.

 gestion de structures de données système

 Bibliothèques de haut niveau, aussi appelées bibliothèques métier, elles interagissent avec celles de bas niveau : les fonctions qu'elles contiennent sont propres à une activité spécifique:  boîtes à outils graphiques : ensemble de fonctions permettant de gérer, d'animer et d'afficher des objets graphiques complexes  Exemple : OpenGL

 bibliothèques d'opérateurs de traitement d'image : ensemble de

fonctions destinées à structurer l'information dans une image à des fins d'analyse,

 gestion de structures de données utilisateur.

BIBLIOTHÈQUES

Les bibliothèques offrent une interface de

programmation (API: Application Programming Interface), permettant aux programmeurs de choisir les fonctions.  Les API se présentent comme une liste des

noms des fonctions ou/et classes disponibles, avec une documentation sur les paramètres à leur fournir et sur les résultats retournés.

C o u r s « G L - A C O O » E N S I

CADRE D’APPLICATIONS: CADRICIEL

 « Un cadriciel [framework] est un espace de travail modulaire. C'est un ensemble de bibliothèques, d'outils et de conventions permettant le développement de programmes. »

 C’est un logiciel

réutilisable qui propose une

solution

générique à un problème généralisable.  Il fournit les services que requièrent différentes applications.  Un cadriciel fournit un contexte où les composants sont réutilisés.

 C’est une application logicielle partielle  intégrant les connaissances d'un domaine,  dotée d'une architecture logicielle et d'un cœur (code) générique  dédiée a la réalisation de nouvelles applications du domaine visé, par

paramétrage et extension

 Un framework fournit:

 un ensemble de fonctions facilitant la création de tout ou d'une partie

d'un système logiciel

 un guide architectural en divisant le domaine visé en modules.

BIBLIOTHÈQUES VS CADRICIELS

 Une bibliothèque est limitée à l'ensemble des fonctions du système, par contre un cadriciel peut être employé par extension pour inclure également l'architecture logicielle préconisée pour cette bibliothèque (eg. organisation en couches, utilisation du modèle MVC, etc),

 Exemples

 Jdom est une librairie permettant de parser des fichiers XML.

Son API contient des fonctions de lecture des noeuds, d'insertion de noeuds dans l'arbre XML, d'ajout d'attributs aux balises...

 Struts est un Framework qui permet de coder toute la partie graphique d'une application, par un ensemble de librairies (gestion des taglibs, des fichiers ressources pour les messages ou la gestion des langues, gestion du mapping entre les adresses et les pages, gestion des formulaires et des Beans, etc.)

C o u r s « G L - A C O O » E N S I

15/11/2017

BIBLIOTHÈQUES VS CADRICIELS

 Une bibliothèque s'utilise, un Framework s‘étend ou se

paramètre

 Avec une bibliothèque, le code d'une nouvelle application

invoque le code de la bibliothèque

 Le code d'un Framework appelle le code de la nouvelle

application: I n ve r s i o n de c o n t r ô l e (é ga l e me n t di t « p r i n c i p e de Ho l l ywo o d » : l e c o de du Fr a me wo r k (p r é e x i s t a n t ) i n vo qu e (c a l l b a c k ) l e s p a r t i e s de c o de r e p r é s e n t a n t l a n o u ve l l e a p p l i c a t i o n e n u n c e r t a i n n o mb r e s d' e n dr o i t s p r é dé fi n i s n o mme s (p o i n t s d' e x t e n s i o n s o u p o i n t s de p a r a mé t r a ge s o u (h i s t o r i qu e me n t ) « Ho t s p o t »

CADRE D’APPLICATIONS: CADRICIEL

 On trouve différents types de cadriciels :

 Cadriciel d'infrastructure système : pour développer des systèmes

d'exploitation, des interfaces graphiques, des outils de communication.  Exemple : Framework .Net, Eclipse, NetBeans, Struts

 Cadriciel d'intégration intergicielle (middleware) : pour fédérer

des applications hétérogènes. Pour mettre à dispositions différentes technologies sous la forme d'une interface unique.  Exemple : Ampoliros avec ses interfaces RPC, SOAP, XML

 Cadriciel orientés Système de gestion de contenu

 Exemple: Joomla, itsEasy, WMaker

C o u r s « G L - A C O O » E N S I

CADRE D’APPLICATION ORIENTÉ OBJET

 Conformément au paradigme orienté objet, un cadre d’application sera composé d’un ensemble de classes.  Le API est alors l’ensemble de toutes les méthodes publiques de

ces classes.

 Quelques-unes de ces classes seront abstraites

TYPES DE CADRES D’APPLICATIONS

 Un cadre horizontal fournit des services généraux qu’un

grand nombre d’applications peuvent utiliser

 Un cadre vertical est beaucoup plus complet, seules

demeurent quelques ouvertures qui doivent être définies afin de s’adapter à une application spécifique

Application

Services offered by the framework

Application

Horizontal framework

Vertical framework

Code to be provided to adapt the framework to the needs of the application

C o u r s « G L - A C O O » E N S I

15/11/2017

QUALITÉS D’UN BON DESIGN

3 .P RI NCI P ES DE LA CONCEP T I ON

Une bonne conception devrait favoriser l’indépendance des modules

Pour évaluer l’indépendance des modules, on se base généralement sur les concepts suivants:  Le couplage  La cohésion

Concepts qui peuvent d’ailleurs s’influencer l’un et l’autre

CARACTÉRISTIQUES D’UN BON DESIGN

3 .P RI NCI P ES DE LA CONCEP T I ON

Un bon design =

une bonne décomposition en modules qui favorise:  une forte cohésion: les éléments ne sont pas réunis dans un même module par hasard: ils forment un tout dans le but de réaliser une tâche commune.

 un faible couplage: les modules sont relativement

indépendants, ne dépendent pas trop des éléments définis dans d’autres modules.

C o u r s « G L - A C O O » E N S I

15/11/2017

FAIBLE COUPLAGE

2 .P RI NCI P ES DE LA CONCEP T I ON

 Couplage: mesure de l’interdépendance entre deux

modules.

 Un ensemble de modules est faiblement couplé si les liens de dépendance (cf. interactions induisant une relation «UTILISE») entre les modules sont peu nombreux.

 Un faible couplage est précurseur…

 D’un bon découpage du système: les éléments qui

dépendent les uns des autres ne sont pas « éparpillés » à travers les modules du système.

 D’une facilité de maintenance: une modification dans un

module affecte éventuellement un nombre restreint d’autres modules. Nombre de révisions réduites…

COUP LAG E - I LLUST R AT I O N

2 .P RI NCI P ES DE LA CONCEP T I ON

C o u r s « G L - A C O O » E N S I

15/11/2017

TYPES DE COUPLAGE- APPROCHE PROCÉDURALE

2 .P RI NCI P ES DE LA CONCEP T I ON

C o u r s « G L - A C O O » E N S I

TYPES DE COUPLAGE- APPROCHE PROCÉDURALE

2 .P RI NCI P ES DE LA CONCEP T I ON

 De contenu: les modules échangent de l'information en lisant et écrivant directement dans leurs espaces de données (variables) respectifs. Lorsqu’une composante modifie déloyalement les données internes d’une autre composante de façon furtive, secrète…

 Commun (global) : les modules échangent de l'information

via un ensemble de données (variables) commun.

15/11/2017

TYPES DE COUPLAGE- APPROCHE PROCÉDURALE

2 .P RI NCI P ES DE LA CONCEP T I ON

 De contrôle: un module passe un « flag » à l’autre qui s’en

sert à des fins de contrôle d’exécution.

 Exemple:

 De structures de données: Il y a couplage de structures de données si un module passe une structure de données par argument à un autre module. Le module appelé n’a pas besoin de tous les éléments contenus dans la structure de données.

 De données: Il y a couplage de données si un module passe des données par argument à un autre module. Le module appelé utilise toutes les données passées en arguments.

COUPLAGE DE CONTRÔLE

3 .P RI NCI P ES DE LA CONCEP T I ON

 Lorsqu’une procédure en appel une autre en utilisant une

variable de contrôle ou une commande contrôlant l’exécution de la procédure appelée

 Afin d’effectuer un changement, il faut modifier à la fois l’appelé et

l’appelant

 L’utilisation d’une opération polymorphique constitue la meilleure

façon d’éviter le couplage de contrôle

 Une autre façon de réduire ce type de couplage consiste à avoir

recours à un tableau de correspondance (look-up) 

Chaque commande est alors associée à une méthode qui sera appelée lorsque cette commande est lancée

C o u r s « G L - A C O O » E N S I

15/11/2017

COUPLAGE DE DONNÉES

3 .P RI NCI P ES DE LA CONCEP T I ON

 Lorsque les types des arguments sont des données simples

 Plus il y a d’arguments, plus ce couplage est fort



Les méthodes invocantes doivent fournir tous ces arguments  Il faut réduire ce type de couplage en évitant d’utiliser des

arguments non-nécessaires

 Il y a souvent un compromis à faire en couplage de données et

couplage d’estampillage 

i.e. réduire l’un accroît l’autre

COU PLA GE DE S TRU CTU RES DE DONNÉES ( D’ES TA M PILLA GE)

3 .P RI NCI P ES DE LA CONCEP T I ON

 Lorsqu’une classe est déclarée dans la liste des arguments

d’une méthode  Une classe en utilise donc une autre

 Afin de réutiliser une classe, il faut aussi utiliser l’autre

 Pour réduire ce type de couplage

 Utiliser une interface  Transmettre que des variables simples

C o u r s « G L - A C O O » E N S I

EXEM PLE DE COU PLA GE DE S TRU CTU RES DE DONNÉES ( D’ES TA M PILLA GE)

3 .P RI NCI P ES DE LA CONCEP T I ON

public void sendEmail(Employee e, String text) {...} ...

Pour réduire ce type de couplage : Ne transmettre que des variables simples

En utilisant des données simples:

public void sendEmail(String name, String email, String text) {...} ...

COUPLAGE EN ORIENTÉ OBJET

2 .P RI NCI P ES DE LA CONCEP T I ON

 En orienté objet les modules se traduisent en méthodes ou en classes. Les méthodes peuvent être couplées par invocation d'une autre méthode ou par le partage des variables avec d’autres méthodes. De la même manière, une classe est couplée à une autre classe s’il y a une relation entre elles.

 Une

catégorisation

la programmation orientée objet, notamment au niveau de la classe, a été faite [Eder et, al., 1995].

applicable

couplage

 Dans cette catégorisation on distingue trois types de

couplage:  Couplage entre composants  Couplage d’héritage  Couplage d’interaction

15/11/2017

C o u r s « G L - A C O O » E N S I

COUPLAGE EN ORIENTÉ OBJET

 Couplage entre composants : lorsqu'une classe utilise en

tant qu'attribut, une autre classe.

C o u r s « G L - A C O O » E N S I

 Couplage d'héritage : si une des deux classes est

directement ou indirectement une sous-classe de l'autre.

15/11/2017

COUPLAGE EN ORIENTÉ OBJET

2 .P RI NCI P ES DE LA CONCEP T I ON

 Couplage d’interaction: Lorsqu'une classe invoque une ou plusieurs méthodes de l'autre. Les types de couplage appliqués aux systèmes procéduraux sont utilisés pour détailler ce type de couplage.

 Couplage de Données : deux classes présentent un couplage de données, si elles échangent des données seulement en paramètres. Ce type de couplage est le plus recommandé dans les systèmes orientés objet.

 Couplage de structures de données : deux classes présentent un tel couplage, si deux de leurs méthodes respectives se passent comme paramètre une structure de données entière alors qu'une partie de cette structure aurait suffi.

 Couplage de Contrôle : une classe communique avec une méthode d'une autre classe à travers le passage de paramètres qui servent à des fins de contrôle d’exécution.

 Couplage Commun : il signifie que plusieurs méthodes partagent un même

ensemble de données.

 Couplage de Contenu : c'est le pire des couplages. Il signifie qu'une méthode

accède directement à l'implantation d'une méthode appartenant à une autre classe ou à ses variables d’instances.

EXEMPLE DE COUPLAGE DE CONTENU

3 .P RI NCI P ES DE LA CONCEP T I ON

public class Line {

public Point start, end; ...

}

public class Arch {

public Line baseline; ... void slant(int newY) {

Point theEnd = baseline.end; theEnd. Location.X=X; theEnd. Location.Y=Y1;

}

Le fait d’encapsuler les données réduit considérablement le couplage

Elles sont déclarées private Avec des méthodes get et set

C o u r s « G L - A C O O » E N S I

15/11/2017

EXEMPLE DE COUPLAGE DE CONTENU

3 .P RI NCI P ES DE LA CONCEP T I ON

public class Line {

private Point start, end; ... public Point getStart() { return start; } public Point getEnd() { return end; }

}

public class Arch {

private Line baseline; ... void slant(int newY) {

Point theEnd = baseline.getEnd(); theEnd.setLocation(theEnd.getX(),newY);

}

EXERCICE

3 .P RI NCI P ES DE LA CONCEP T I ON

 Dans un logiciel de gestion de vente, nous avons les trois classes

suivantes :

Facture : contient un ensemble de produits facturés et est associée à un

paiement,

Paiement : décrit un paiement, un paiement est associé à une facture. Client : effectue les commandes et elle est associée à la classe facture.  On ajoute une méthode payer() à la classe Client. On étudie le couplage

dans les deux cas suivants : 1.

La méthode payer() crée une instance de Paiement et l'assigne à l'objet Facture. La méthode payer() délègue l'action à la classe Facture qui crée une instance de Paiement et l'assigne.

 Quel est le meilleur cas ?

 Le couplage est plus faible dans le deuxième car la méthode payer() de la classe Client n'a pas besoin de savoir qu'il existe une classe Paiement, c'est à dire qu'elle ne dépend pas de l'existence ou non de cette classe

15/11/2017

C o u r s « G L - A C O O » E N S I

15/11/2017

FORTE COHÉSION

2 .P RI NCI P ES DE LA CONCEP T I ON

 Cohésion= Mesure de la force des relations qui unissent

les éléments fonctionnels à l’intérieur d’un module.

 Un module est fortement cohésif si tous les éléments sont

destinés et sont essentiels à la réalisation d’une tâche commune unique.

 Une forte cohésion est précurseur

 D’un bon découpage du système: les éléments qui ont rapport les

uns avec les autres se retrouvent dans un même module.

 D’une facilité de maintenance: les éléments destinés à une même

tâche sont regroupés et on peut facilement les retrouver.

 D’un faible couplage: les éléments inter-dépendants se trouvant

dans le même module, les dépendances inter-modules sont moindres.

TYPES DE COHÉ