Ift 2251 Introduction au Génie Logiciel

Présentation au sujet: "Ift 2251 Introduction au Génie Logiciel"— Transcription de la présentation:

1 Ift 2251 Introduction au Génie Logiciel
Partie 4 Conception Ref. Pressman Ch. 13, 14 et 16 Julie Vachon, DIRO, Université de Montréal, 2001

2 Définitions, principes, et document de conception
4.1 Introduction: Définitions, principes, stratégies et document de conception

3 4.1.1 L’activité de conception Définition et objectifs

4 L’activité de conception Définition
Phase du processus de développement qui transforme progressivement la spécification d’analyse du logiciel en un produit final. Comment réaliser le système, quels mécanismes utiliser? Analyse Conception Étape 1 Conception Étape 2 Implémentation Processus progressif Transformation finale en programme exécutable

5 L’activité de conception
La conception est une activité difficile et critique. C’est aussi une activité de création. Elle vise à répondre au «comment»…. Pas de recette toute faite. 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.) L’aptitude à réaliser de bonnes conceptions dépend de l’intuition et se développe par la pratique…

6 L’activité de conception Objectifs
But: 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. Définir les principes à la base de cette décomposition modulaire (abstraction, raffinement, etc.)

7 L’activité de conception Sous-objectifs
La conception logicielle comporte deux 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. Conception détaillée: Activité destinée à décrire le 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 certains ensemble de principes de conception…

8 4.1.2 Principes de conception

9 Principes de conception
Règles et éléments fondamentaux du génie logiciel qui doivent guider la phase de conception en vue de construire des systèmes fiables et évolutifs: Abstraction Raffinement Modularité Masquage d’informations Évolutivité et adaptation aux changements Généralité Rigueur et formalisme

10 Principes de conception 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 d’une réflexion spécifique. 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. Ex. Les formules mathématiques utilisées pour décrire un circuit électrique. Ex. En Ada, un type de donnée abstrait appelée «client» est utilisé pour représenter les personnes qui sont clientes d’une banque.

11 Principes de conception Raffinement
Processus de conception qui permet d’élaborer 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 prendre notes des critères ayant influencé ce choix et de garder trace des solutions alternatives. Le raffinement se termine lorsque la description est totalement exprimée dans un langage de programmation. 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 révéler ces détails…

12 Principes de conception Modularité
Caractéristique d’un logiciel qui se compose de 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… Concrètement, la modularité vise trois importants objectifs: 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). Faciliter la compréhension et la maintenance du système en le divisant en parties (possibilité de confiner la recherche d’un problème ou l’application d’une modification à une partie bien comprise du système).

13 Principes de conception Modularité - cohésion
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). 1) La 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.

14 Principes de conception Modularité - couplage
2) Le 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, comprendre, modifier, tester et réutiliser de façon séparée

15 Principes de conception Modularité
On désire concevoir des systèmes fortement cohésifs et faiblement couplés. Système fortement cohésif et faiblement couplé Système fortement couplé Expliquer en quoi le système électrique d’une maison représente un bon système modulaire…

16 Principe de conception Modularité
Diviser pour régner… Effort nécessaire proportionnel à la complexité perçue: C(p1) > C(p2) -> E(p1) > E(p2) Par expérience, il semble que: C(p1 +p2) > C(p1) + C(p2). Donc: E(p1 +p2) > E(p1) + E(p2) Conclusion: il vaut mieux diviser pour régner… mais pas trop!

17 Principes de conception Modularité
Pour une conception donnée, quel est le nombre de modules approprié? Coût de développement d’un module Coût du logiciel Coût d’intégration d’un module Nombre optimal de modules Nombre de modules

18 Principes de conception Modularité, contrôle hiérarchique et partitionnement
Les modules sont généralement organisés en hiérarchies représentant la relation de contrôle entre les modules. - Il sont partitionnés horizontalement et verticalement. - On utilise généralement une notation en arbre pour représenter cette hiérarchie. Partitionnement horizontal: généralement utilisé pour séparer les fonctions du système. Ex. la saisies des entrées, la transformation des données et la sortie des données. Partionnement vertical: généralement utilisé pour factoriser le travail. Les modules aux niveaux supérieurs sont des modules de contrôle, alors que les modules au niveaux inférieurs sont les exécutants.

19 favorisent la cohésion et minimise le couplage…
Principes de conception Modularité, contrôle hiérarchique et partitionnement Il faut rechercher des structures qui favorisent la cohésion et minimise le couplage… STRUCTURE EN FORME DE CIGARE fan-out (éventail de sortie) mesure du nombre de modules qui sont directement contrôlés par un module donné. mesure du nombre de modules qui contrôlent un module donné. fan-in (éventail d’entrée)

20 Éviter les structures en galette.
Principes de conception Modularité, contrôle hiérarchique et partitionnement Éviter les structures en galette. Pourquoi???

21 Principes de conception Masquage d’information (encapsulation)
Principe suggérant que les modules cachent (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…

22 Principes de conception Masquage d’information
module • algorithme interface • structures de données • politique d’allocation de ressources clients "secret" Un choix de conception spécifique

23 Principes de conception Évolutivité et adaptation aux changements
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. But: obtenir une conception flexible qui puisse bien s’accommoder des modifications futures…. Bien qu’initialement élégante, une structure mal adaptée aux changements peu devenir fort difficile à maintenir…

24 Principes de conception Évolutivité et adaptation aux changements
Changements éventuels qui peuvent être pris en compte lors de la conception: Changement d’algorithme. Ex. Changement d’algorithme de tri… Changement de structure de données pour représenter une même information. Ex. Remplacement d’une liste par un arbre… Changement de la machine abstraite sous-jacente. Ex. Changement de compilateur, changement de système d’exploitation. 4) Changement d’un périphérique. Changement de l’environnement social. Ex. La formule du calcul des taxes a changé. Ex. Passage à l’euro…

25 Principes de conception Généralité
Lorsqu’on résout un problème, il est important de mettre l’accent sur la recherche d’une solution pour un problème plus général que celui à résoudre et qui se cache sans doute derrière lui. Une solution générale a plus de chance d’être réutilisée. Peut-être existe-elle déjà? Un module général pourra, peut-être, être utilisé à plusieurs niveaux dans l’application. Inconvénient: une solution générale est parfois moins performante qu’une solution spécialisée…

26 Principes de conception Rigueur et formalisme
La rigueur est un complément nécessaire à la créativité dans l’activité de conception logicielle. Formalisme Le summum de la rigueur est le formalisme. Le formalisme est encore plus exigeant que la rigueur puisqu’il demande que le processus de développement soit conduite et évalué par des lois mathématiques. Si on est formel, on est nécessairement rigoureux. Mais si on est rigoureux, on n’est pas nécessairement formel. Ex. On peut décrire un système en langue naturelle de façon rigoureuse. Pour être formel toutefois, on utilisera un langage logique, des modèles mathématiques, etc. Pendant la phase de conception, on pourra utiliser rigueur et formalisme de façon à bénéficier de leurs effets positifs sur la fiabilité, la vérification, la maintenance, la réutilisation, la portabilité et la compréhension des systèmes conçus (… expliquez pourquoi??)

27 4.1.3 Stratégies de conception

28 Stratégies de conception
ascendante (bottom-up) «Décider de l’information à encapsuler et regrouper graduellement en modules de plus haut niveau.» Stratégie descendante (top-down) «Décomposition en composants gérables.» Conception architecturale Conception des interfaces Conception détaillée des composants (modules et données) On peut employer les deux stratégies au cours d’une même conception…

29 Stratégies de conception Approche descendante
Avantages Processus simple. Permet de maîtriser la complexité de gros systèmes 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 en isolation. Réutilisation des composants peu exploitée (le partitionnement précoce des problèmes empêche de voir les solutions communes… Moins grande attention portée à la conception des données et au masquage de l’information.

30 Stratégies de conception Approche ascendante
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éutilisation. 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…

31 Quelques méthodes de conception
Avant l’intra… Années 70-75: développement modulaire, approche par raffinement, programmation structurée. [Dennis, Wirth, Dahl, Diskstra, Hoare, Mills, etc.] Années 75-80: processus de transformation des DFD et des modèles de données dans une définition de conception. [Stevens,Jackson, Warnier, etc.] Après l’intra… Années 90-95: Approches orientées-objet pour dériver les conceptions. [Jacobson et als] Années : Utilisation de pattern de conception pour implémenter les architectures logicielles. [Shaw, Bass, Gamma, Buschmann, Brown, etc.]

32 Document de conception (ou spécification 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.