GL2023Chap6 Conception

CHAP 6 :
CONCEPTION
Activités
Principes
Types abstraits de données
GI 21 Meriem Zaoui - Génie Logiciel - Chap 6 2
Activité de conception : Introduction

• La conception est une activité difficile et critique. Elle vise à répondre
au « COMMENT ? »
• C’est aussi une activité de création. Il n’existe pas de recette toute faite.
• L’aptitude à réaliser de bonnes conceptions dépend de l’intuition et se

développe par la pratique…
• Mais la Conception = ensemble de principes généraux, de méthodes et

de stratégies dont l’application pratique dépend du domaine, des
contraintes et des qualités recherchées (performance, robustesse, etc.)
• Une bonne conception (ou design) contribue à la qualité du logiciel

• fiabilité,
• correction,
• évolutivité, etc.
La conception
• Objectif : Transformer progressivement la spécification d’analyse
en une description structurée d’un système fiable et évolutif.
• Pour réaliser ce but principal, il faudra définir la structure du

système par un ensemble de modules :
• identifier les modules qui composent le système
• identifier les relations entre les modules
• décrire chacun des modules
La conception
Processus en n Implémentation
étapes: chaque étape n
étape raffine et Conception bas niveau La décomposition
décompose (en étape 2 se poursuit jusqu’à
sous-modules) ce qu’on obtienne
Conception haut niveau
les modules étape 1 des modules
définis à l’étape Conception globale suffisamment
précédente. (architecture) simples pour être
directement
Besoins implémentés.
La conception
• La conception d'un logiciel peut être divisée en plusieurs étapes :
• Étudier et comprendre le problème. On doit examiner le problème sous

différents points de vue, car ces derniers donnent différents éclairages
quant aux besoins de la conception.
• Identifier les principales caractéristiques d'au moins une solution possible
(parmi plusieurs). Le choix de la solution dépend :
• de l'expérience du concepteur (choisir une solution qui lui est familière et
bien comprise).
• de la disponibilité de composants réutilisables, et de la simplicité des
solutions qui en découleront.
• Décrire toutes les abstractions utilisées dans la solution (description
formelle mais aussi informelle).
• On répète ce processus de résolution de problème pour chacune

des abstractions identifiées lors de la conception initiale.
La conception
• Conception = Activité intellectuelle
• créativité
• expérience
• Tâches : Décomposition, Élaboration et Choix d'alternatives
• Activité supportée par :

• Les principes du génie logiciel
• Des méthodes, des formalismes et des outils
• Principes essentiels :
• Modularité
• Abstraction
• Masquage
Types de conception : Activités

Conceptions = 2 sous activités
• Conception architecturale: Activité destinée à définir la structure

globale de l’architecture en termes de modules et de relations inter-
modules.
• choix fondamentaux d'architecture logicielle
• en lien éventuel avec l'architecture matérielle
• Conception détaillée: Activité destinée à décrire en détails le contenu

des modules individuels (en appliquant, entre autres, le principe de
masquage d’information).
• Ces deux sous-activités sont menées

• soit l’une à la suite de l’autre, soit en parallèle (selon les besoins)
• en suivant un certain ensemble de principes de conception…
Activités de conception
Conception architecturale (conception de haut niveau, conception
globale/générale)
• Elle produit la structure et l’organisation générale du système à concevoir
• Première étape qui consiste à définir les fonctions des éléments d'un
système et leurs relations fonctionnelles.
• Elle contient la description des éléments principaux, les relations entre eux,
les contraintes à respecter, les motifs et la logique de cette décomposition.
Conception architecturale
• La conception de l’architecture du système global : identifie les sous-
systèmes qui composeront le système global
• Une spécification abstraite des sous-systèmes : établit une description
des services supportés par chaque sous-système
• La conception de l’interface : décrit l’interface de chaque sous-système
avec les autres
Activités de conception
Conception détaillée
• Consiste à détailler les résultats de l’analyse fonctionnelle, jusqu'à un
niveau suffisant (algorithmes) 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.
Conception détaillée
• La conception des composants, architectures des sous-systèmes :
découpe les sous-systèmes en plusieurs composants
• La conception des structures des données : conçoit et spécifie en détail
les structures de données
• La conception des algorithmes : conçoit et spécifie en détail les
algorithmes pour réaliser les différents services
Principes d’une conception
Deux QUALITÉS logicielles importantes sont en jeu :
• Évolutivité: => anticipation du changement. Si le logiciel

est difficile à changer, les autres qualités sont directement
compromises ( fiabilité, performance, etc.)
• Réutilisabilité: on veut minimiser les coûts et rentabiliser

les efforts de développement.
Principes d’une conception

Evolutivité et réutilisabilité sont assurés par une bonne
décomposition en modules (i.e. un bon design) qui devra favoriser
• L’abstraction
• Le raffinement
• La modularité
• Le masquage d’information
• + adaptation aux changements
Principe : 1- Abstraction
Principe selon lequel on représente un problème (une donnée, une
procédure, une entité, etc.) en éliminant les aspects les moins
pertinents pour ne considérer que ceux qui sont essentiels pour
servir les buts recherchés.
• Permet de maîtriser la complexité d’un problème.
• Permet de se dégager de certains détails pour se concentrer sur ceux qui
sont pertinents.
• Exemple : Les formules mathématiques utilisées pour décrire un

circuit électrique. Les types abstraits de données
Principe : 2- Raffinement
Elaborer une description étape par étape depuis une description très
abstraite jusqu’à son implémentation (dans un langage de
programmation).
A chaque étape, une ou plusieurs parties d’une description sont redéfinies
en donnant de plus en plus de détails.
• Chaque étape de raffinement implique un choix de conception. (Il est
important de garder une trace des solutions alternatives.)
• Le raffinement se termine lorsque la description est totalement
exprimée dans un langage de programmation.
• NB : Les principes d’abstraction et de raffinement sont

complémentaires.
• L’abstraction permet d’omettre les détails d’implémentation.
• Le raffinement permet de rajouter et préciser ces détails…
Principe : 3- Modularité
Décomposition en modules séparés, clairement identifiés, aux
interfaces bien définies, pouvant être traités ou modifiés
individuellement.
La modularité permet de mieux gérer la complexité des systèmes et
facilite leur maintenance
La modularité vise 3 importants objectifs:
• Faciliter la compréhension et la maintenance du système en le
divisant en parties.
• Permettre la décomposition d’un système complexe (diviser pour
régner, approche descendante)
• Permettre la composition d’un système à partir de modules déjà
existants (assemblage de composants, approche ascendante).
Différentes notions de modules

Module logique
• élément du découpage logique de la solution du problème
Module de compilation/chargement
• bloc de code pouvant être compilé/chargé séparément
• ex. : fichier C (types, variables, fonctions), classe Java (champs, méthodes),
script shell (variables, fonctions)
Module du langage de programmation

• bloc de code nommé pouvant être utilisé (appelé, ...)
• ex. : fonction, classe, fichier d'inclusion C (.h), ...
• Exemple : En UML un module = classe, paquetage, composant,

cas d’utilisation, etc.
Qualité de la Modularité
Les modules sont caractérisés par deux propriétés

importantes:
la cohésion (propriété propre à un module)
et le couplage (propriété entre modules).
30 nœuds, 66 arêtes → 2,2 arêtes par nœud

Qualité de la Modularité
Objectif : forte cohésion et faible couplage
intra-module : 5 à 7 nœuds ; 2 arêtes / nœud

inter-module : 5 modules ; 1,2 arêtes / module
Cohésion
• Un module est hautement cohésif si tous ses éléments sont

fortement liés.
• Les éléments d’un module (procédures, déclarations, instructions,
etc.) sont groupés ensemble dans le même module pour une
raison logique et non par hasard.
• Ces éléments coopèrent pour atteindre un objectif commun i.e.
la fonctionnalité du module.
• On définit 7 niveaux de cohésion (Constantine et Yourdon 1979)
Types de cohésion
Aléatoire: Les fonctions du module n’ont F1 F1: Réparer la voiture

F2 F2: Acheter un vêtement
rien à voir les unes avec les autres. Elles
F3: Étudier un cours
sont réunies par pure commodité. F3
Logique: Fonctions réunies autour d’un F1 F1: Voyager en voiture

thème commun... F2 F2: Voyager en avion
F3: Voyager en bus
F3
Temporelle: Fonctions réunies ensemble
car leurs moments d’exécution sont
reliés dans le temps… F1 [T] Au coucher…
F2 [T+X] F1: Fermer la TV
F2: Se brosser les dents
F3 [T+2X]
F3: Fermer les lumières
Types de cohésion (suite)
Procédurale: Fonctions réunies parce

qu’elles doivent être exécutées dans un F1 F1: Préparer la dinde
ordre donné. (flot de contrôle passe F2 F2: Préparer les légumes
d’une fonction à une autre, boucle, F3 F3: Mettre la table
conditionnelle.…)
Communicationnelle: Fonctions réunies F1 F1: Trouver titre d’un livre
car elle produisent ou opère sur le même F2 F2: Trouver prix d’un livre
type de données. F3 F3: Trouver auteur d’un livre
Séquentielle: Fonctions réunies car les

F1 F1: Remplir les trous
sorties de l’une servent d’entrées pour F2: Sabler la voiture
l’autre… (flot de données…) F2
F3: Donner une première
F3 couche de peinture
GI 21 Mme Zaoui - Génie Logiciel - Chap 6 21
Types de cohésion (suite)

Fonctionnelle: Toutes les fonctions qui sont réunies contribuent à l’exécution d’une
même et unique tâche.
Le module contient toutes les fonctions nécessaires pour la réalisation de la tâche.
Le module réalise une seule et unique tâche.
Repeindre une voiture
F1 F1: Laver la voiture

F2 F2: Remplir les trous
F3 F3: Sabler la voiture
F4: Donner une première
F4 couche de peinture
F5 F5: Donner une couche
finale de peinture
+ On peut définir une classe supplémentaire de cohésion pour la conception Objet

Cohésion d'objet . Chaque opération offre une fonctionnalité basée sur la
modification, l'inspection ou l'utilisation des attributs de l'objet.
Cohésion
Cohésion
=
Facilité de maintenance
Cohésion
forte
COHÉSION
Plus facile à maintenir • Fonctionnelle

FONCTIONS S’APPLIQUENT À • Séquentielle
DES DONNÉES COMMUNES • Communicationnelle
Plus difficile à maintenir • Procédurale

FONCTIONS CONCERNENT LE • Temporelle
TRAITEMENT DE DONNÉES • Logique
ÉVENTUELLEMENT DISPERSEES… • Aléatoire Cohésion
Changement d’une fonction dans un faible
module peut avoir des répercussions
dans plusieurs modules qui traitent le
même type de données…
Couplage
• Mesure l’interdépendance de deux modules
• Ex. un module A appelle une fonction offerte par un module B.
• Si deux modules dépendent beaucoup l’un de l’autre, ils sont

fortement couplés.
• Si deux modules sont fortement couplés, il sera difficile de les
analyser, modifier, tester et réutiliser de façon séparée
GI 21 ▪ Meriem Zaoui - Génie Logiciel - Chap 6 24
Types de couplage
▪ De contenu: Il y a couplage de contenu si un module fait référence
et/ou modifie une partie du code de l’autre (i.e. intervient dans sa
partie qui devrait être cachée (implémentation)).
Couplage de contenu: m1 modifie des données ou des instructions à
l'intérieur de m2
▪ Global: Il y a couplage global si deux modules réfèrent à un même

ensemble de données.
Couplage par variables globales communes : m1 et m2 accèdent à la
même donnée globale
▪ De contrôle: Il y a couplage de contrôle si un module contrôle la

logique d’un autre module via des paramètres de contrôle ou des
flags.
Couplage de contrôle : m1 passe un paramètre à m2 qui influence le flot

de contrôle de m2
Types de couplage
• 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.
Couplage de structure de données : m1 , m2 acceptent les mêmes

structures de données comme paramètre
▪ De données: Il y a couplage de données si un module passe des

données par argument à un autre module.
Couplage de données : m1 , m2 communiquent par paramètres
▪ Pas de couplage : indépendant

Couplage
Couplage
Types de couplage
Couplage fort
• de contenu
Couplage dangereux et • global
difficile à comprendre • de contrôle
• de structures de
Couplage discipliné
données
traditionnel
• de données
• absence de
couplage Couplage faible
Forte cohésion + Faible couplage

• Avantage des systèmes à forte cohésion et à couplage
faible
• Il est possible de remplacer un composant/module

quelconque par un composant équivalent avec peu ou pas
de changement dans les autres parties du système.
• Pendant le processus de conception d’un système à faible

couplage, le concepteur a la possibilité de changer d'avis/de
solution en ce qui concerne un composant sans provoquer
des conséquences graves pour le reste du logiciel.
Modularité : règles à respecter
✓Conception d’unités modulaires du langage

✓Contrôle des tailles
✓Minimisation des interfaces
✓Simplification des interfaces
✓Interfaces explicites (clairement définie)
✓Masquage de l'information
Unités modulaires du langage

Principe
• Module = unité syntaxique du langage
• Bloc de code nommé pouvant être utilisé (appelé, ...)
• Ce qui produit des modules compilables séparément
➔ Prise en compte partielle du langage dès la conception
Exemple
• classes Java, C++ ; fichier C
Contre-exemple
• sous-programmes non compilables séparément
Contrôles des tailles

Principe
• Un module ne doit être
• ni trop gros (sinon le découper en sous-modules)
• ni trop petit (sinon ça ne mérite pas d'être un module)
Exemple
• Trop gros : un unique module pour une API graphique
• API (Application Programming Interface)
• Trop petit : un module pour remettre un tableau à zéro
Contre-exemple
• modules naturellement gros : lecture/écriture d'image
Minimisation des interfaces

Principe
• Tout module doit communiquer avec aussi peu d'autres modules
que possible
• S'il y a N modules, le nombre d'interconnexions doit être plus
proche de N-1 que de N(N-1)/2
Simplification des interfaces

Principe
• Les modules doivent échanger aussi peu de données que possible
• Exemples
• faible nombre d'arguments des fonctions/méthodes
• transmission de pointeurs restreinte
• Contre-exemple
• variables globales
Principe : 4- Masquage de l’information

(encapsulation)
Principe qui stipule que les modules doivent cacher (aux autres
modules) les choix de conception qui les caractérisent.
- Les informations (données et procédures) d’un module qui ne
sont pas utiles aux autres modules devraient être inaccessibles.
- Les communications entre modules n’impliquent qu’un échange
d’informations nécessaires. Le principe d’abstraction permet de
définir ces informations essentielles.
- Facilite la maintenance et les modifications apportées aux
modules… → Modifications invisibles aux autres modules…
Masquage de l’information
Principe
• Toute information d'un module est privée, sauf son
interface explicite
Exemples
• en C : n'est visible à l'extérieur d'un fichier que ce qui est déclaré «
extern » (variables, fonctions)
➔ Ceci assure le critère de continuité

• Le contenu d'un module peut changer sans que les
autres modules doivent être modifiés
Modularisation/Masquage : Interface et
implémentation
Partie publique d’un module
• Interface : Vitrine décrivant l’ensemble des ressources
(opérations, attributs et autres informations pertinentes) rendues
accessibles aux modules clients.
• La visibilité des éléments de l’interface peut être contrôlée en utilisant les
mécanismes « public », « private », « protected ».
• Pour faire la conception d’un module M, on n’a besoin que des interfaces
des autres modules que M pourra utiliser.
Partie secrète d’un module

• Implémentation : Façon dont les ressources sont concrètement
représentées et réalisées dans le module.
+ Adaptation aux changements

• But: obtenir une conception flexible qui puisse bien
s’accommoder des modifications futures….
• Principe selon lequel les choix de conception sont réalisés en

anticipant les modifications qui pourraient être apportées au
logiciel et en étant attentif à l’évolution possible ou attendue du
logiciel.
• Une structure mal adaptée aux changements peu devenir très

difficile à maintenir…
➔ CONCEVOIR POUR CHANGER

Adaptation aux changements

Changements éventuels qui peuvent être pris en compte lors
de la conception:
▪ Changement d’algorithme.
▪ Changement d’algorithme de tri…
▪ Changement de structure de données pour représenter une

même information.
▪ Remplacement d’une liste par un arbre…
▪ Changement de l’environnement social.

▪ La formule du calcul des taxes a changé, changement de devises monétaire

▪ Changements dus au processus de développement
Si la nature du processus de développement est itérative et/ou
incrémentale.
• De nouvelles parties pourront venir s’ajouter et devront s’ajuster aux
anciennes (développement incrémental)
• Des parties raffinées pourront venir remplacer certaines anciennes parties
moins détaillées. (développement itératif)
▪ Changement de la machine abstraite sous-jacente.

▪ Changement de compilateur, changement de système d’exploitation.
▪ Changement d’un périphérique.

Changements
(perfectionnements) du
système imposés par les Maintenance perfective
nouvelles exigences du
client ou utilisateur
Changements
(adaptations) imposés
par la modification de Maintenance adaptative
l’environnement
matériel, social, etc.
Cours GL/ Meriem ZAOUI - La conception 40
La conception – Démarches
Il existe différentes manières pour classer les démarches de conception, dont :
• Distinction composition/décomposition :
• Méthodes ascendantes qui consistent à construire un logiciel par
composition à partir de modules existants (ou a commencer par les
modules de niveaux inférieurs puis passer à ceux de niveau plus élevé),
• Méthodes descendantes qui décomposent récursivement le système jusqu'à
arriver à des modules programmables « simplement » ;
• Distinction fonctionnelle/orientée objet.

• Stratégie fonctionnelle (dirigée par le traitement) : système vu comme un
ensemble d'unités en interaction, ayant chacune une fonction clairement
définie.
• Stratégie orientée objet : système vu comme un ensemble d'objets inter-
agissants. Chaque objet dispose d'un ensemble d'attributs décrivant son
état et l'état du système est décrit par l'état de l'ensemble.
Stratégies de conception
Stratégie Stratégie
descendante ascendante
(top-down) Conception (buttom-up)
« décomposition architecturale « décider de

en composants l’information à
gérables » encapsuler et
regrouper
Conception des interfaces
progressivement
en modules de
plus haut niveau»
Conception détaillée des

composants
Parfois les 2 stratégies sont utilisées dans une même conception

Stratégies de conception descendantes

Avantages
• Processus simple qui permet de maîtriser la complexité de gros
systèmes en le découpant en sous-problèmes.
• Met en évidence le degré de couplage et permet de le contrôler assez
tôt dans le processus de conception.
• Offre une définition claire et facile à comprendre: idéale pour documenter une
conception.
Inconvénients
• Les sous-problèmes ont tendance à être analysés séparément.
• Réutilisation des composants peu exploitée (le partitionnement
précoce des problèmes empêche de voir les solutions communes)
• La conception des données et le masquage de l’information sont moins
bien réalisés
Stratégies de conception ascendantes

Avantages
• Favorise le masquage de l’information: encapsulation de l’information
dans un module (pour lequel on crée une interface) qui peut à son tour
être utilisé par un module de plus haut niveau…
• Favorise la réutilisabilité.
Inconvénients
• Pas facile de savoir quelle information il faut précisément encapsuler
(une approche descendante est parfois nécessaire…)
• La représentation de la conception n’est pas toujours simple et facile à
comprendre
• De plus on n’a aucune de garantie de :
• l'existence d'un véritable besoin de réutilisation
• la convergence vers une solution du problème
Stratégies de conception : Méthodologie

possible
Stratégie mixte (« yo-yo »)
1. Garder l'esprit de l'analyse descendante

• concevoir les abstractions de haut niveau
• affiner jusqu'à une conception suffisamment détaillée
2. Mais appliquer des heuristiques

• s'appuyer sur le modèle conceptuel
• découper en modules de même niveau d'abstraction
• veiller à respecter tous les principes de modularité
3. Si de la réutilisabilité est recherchée

• combiner avec un peu d'approche ascendante
NB : Les données d’abord

Important :
• Le plus souvent, il vaut mieux organiser un système autour des

données plutôt qu'autour des fonctions
• Importance du lien avec le modèle conceptuel

• objets, attributs, opérations pour les manipuler
• Programmation orientée objet (OO) => Méthodologie Orientée

Objet
Abstraction des types

• En génie logiciel, un type abstrait est une spécification d’un
ensemble de données et de l’ensemble des opérations qu’elles
peuvent effectuer.
• On qualifie d’abstrait ce type de données car il correspond à un

cahier des charges qu’une structure de données doit ensuite
implémenter.
Abstraction des types
• L’abstraction des données => Type abstrait de données ou

TAD(effet boîte noire)
• C'est la description d'une structure de données par la liste des
opérations qui lui sont applicables et par les propriétés abstraites
de ces opérations au lieu d'une description de sa représentation
physique en mémoire
• Un type abstrait est un type utilisateur, un type de données
défini par le programmeur pouvant être manipulé de la même
façon que les types prédéfinis.

• Les types abstraits sont des représentations des données (au sens
large) indépendantes de la réalisation et du codage.
• Pour la partie réalisation, à chaque type abstrait donné, on
associera un type concret (choisi parmi les différentes variantes
possibles), qui sera ensuite codé en un type du langage.
• TAD Pile => implémentation contigüe, chainée, etc.
• La relation (type abstrait/concret) devra être analysée finement

afin de choisir au mieux le type concret en fonction du type
abstrait considéré, selon des critères liés à :
• la simplicité d’utilisation,
• le temps de calcul,
• l’espace mémoire requis.
Définition d’un type abstrait de données

• On associe à un TAD 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.
Un type abstrait est défini par :

• un nom
• un ensemble de constructeurs (constantes ou fonctions) qui
permettent de produire des données de ce type à partir d’autres
données
• des opérations qui permettent de manipuler les données de ce
type abstrait.
Liste des opérations

Les opérations des types abstraits (autres que les constructeurs)
peuvent être regroupées en 3 catégories :
• Opérations d’accès : permettent d’accéder aux composants
internes des données du type abstrait
• Opérations de test : permettent de tester les caractéristiques des
données
• Autres opérations : on considère ici généralement, différentes
opérations de base (souvent utilisées) et qu’on souhaite rendre
plus efficaces en les optimisant pour le type concret choisi.
Exemple : Type Sac


Intérêt
• On peut modifier le contenu d'une implémentation sans changer
ses utilisations (via l'interface)
• On peut remplacer une implémentation par une autre (par ex.

plus efficace, suivant le contexte)
☛ = notion très importante en génie logiciel
• NB : Pour les utilisateurs du type abstrait, toutes les

manipulations des données du type abstrait doivent se faire au
travers de l’interface du type abstrait.
La conception détaillée ?
• La conception des composants ou modules formant l’architecture
d’un système.
• De moins en moins abstrait, pour s’approcher d’une conception
de plus en plus détaillée, prête à être codée dans un langage de
programmation.
• On peut soit décrire la conception détaillée des composants
directement dans un langage de programmation ou utiliser une
notation intermédiaire (de plus haut niveau qu’un langage de
programmation) qui peut facilement être traduite en code
source.
• Ces notations intermédiaires peuvent être
• graphiques (flowchart, organigramme)
• textuelles (pseudocode).
La conception détaillée : flow chart

Documents de conception
Le document doit comprendre les éléments suivants:
✓Sommaire du travail de conception: objectifs à atteindre en regard de
la spécification d’analyse.
✓Description de la conception des bases de données: structure,
système de fichiers, structure des données.
✓Description de la conception architecturale: explication de la façon
dont la structure générale du système a été dérivée depuis la
spécification d’analyse.
✓Description de la conception des interfaces usagers. Prototype peut
être fourni.
✓Description détaillée des composants: description des fonctions et
procédures. Description en langue naturelle et/ou en intégrant une
notation structurée.
✓Annexe: description d’algorithmes, procédures alternatives, notices,
etc.
Conclusion
• Conception
• séparation des problèmes / décomposition modulaire
• Méthodologie
• globalement descendante, parfois ascendante
• Principes de modularité à respecter

• Découpage logique ; taille équilibrée ; masquage de l'information ; interface
minimale, simple et explicite
• Organiser le système autour des données

• Notion de type abstrait
• UML : notations normalisées, vues différentes

Cycle de vie et UML

Définition des besoins
• diagramme de cas d'utilisation
Analyse des besoins

• diagrammes d'état, d'activité
Conception
• diagrammes d'état, d'activité
• diagrammes de classe, d'objet, de package
• diagrammes de séquence, de collaboration
• diagrammes de déploiement

GL2023Chap6 Conception

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

GL2023Chap6 Conception

Transféré par

Droits d'auteur :

Formats disponibles

CHAP 6 :

Activité de conception : Introduction

• L’aptitude à réaliser de bonnes conceptions dépend de l’intuition et se

• Mais la Conception = ensemble de principes généraux, de méthodes et

• Une bonne conception (ou design) contribue à la qualité du logiciel

• Pour réaliser ce but principal, il faudra définir la structure du

• Étudier et comprendre le problème. On doit examiner le problème sous

• On répète ce processus de résolution de problème pour chacune

• Tâches : Décomposition, Élaboration et Choix d'alternatives

• Activité supportée par :

Types de conception : Activités

• Conception architecturale: Activité destinée à définir la structure

• Conception détaillée: Activité destinée à décrire en détails le contenu

• Ces deux sous-activités sont menées

Principes d’une conception

Deux QUALITÉS logicielles importantes sont en jeu :

• Évolutivité: => anticipation du changement. Si le logiciel

• Réutilisabilité: on veut minimiser les coûts et rentabiliser

Principes d’une conception

• Exemple : Les formules mathématiques utilisées pour décrire un

• NB : Les principes d’abstraction et de raffinement sont

Différentes notions de modules

Module du langage de programmation

• Exemple : En UML un module = classe, paquetage, composant,

Les modules sont caractérisés par deux propriétés

30 nœuds, 66 arêtes → 2,2 arêtes par nœud

intra-module : 5 à 7 nœuds ; 2 arêtes / nœud

• Un module est hautement cohésif si tous ses éléments sont

Aléatoire: Les fonctions du module n’ont F1 F1: Réparer la voiture

Logique: Fonctions réunies autour d’un F1 F1: Voyager en voiture

Types de cohésion (suite)

Procédurale: Fonctions réunies parce

Séquentielle: Fonctions réunies car les

Types de cohésion (suite)

Repeindre une voiture

F1 F1: Laver la voiture

+ On peut définir une classe supplémentaire de cohésion pour la conception Objet

Plus facile à maintenir • Fonctionnelle

Plus difficile à maintenir • Procédurale

• Si deux modules dépendent beaucoup l’un de l’autre, ils sont

▪ Global: Il y a couplage global si deux modules réfèrent à un même

▪ De contrôle: Il y a couplage de contrôle si un module contrôle la

Couplage de contrôle : m1 passe un paramètre à m2 qui influence le flot

• De structures de données: Il y a couplage de structures de données si

Couplage de structure de données : m1 , m2 acceptent les mêmes

▪ De données: Il y a couplage de données si un module passe des

Couplage de données : m1 , m2 communiquent par paramètres

▪ Pas de couplage : indépendant

Forte cohésion + Faible couplage

• Il est possible de remplacer un composant/module

• Pendant le processus de conception d’un système à faible

Modularité : règles à respecter

✓Conception d’unités modulaires du langage

Unités modulaires du langage

Contrôles des tailles

Minimisation des interfaces

Simplification des interfaces

Principe : 4- Masquage de l’information

➔ Ceci assure le critère de continuité

Partie secrète d’un module

+ Adaptation aux changements

• Principe selon lequel les choix de conception sont réalisés en

• Une structure mal adaptée aux changements peu devenir très

➔ CONCEVOIR POUR CHANGER