IFT2251 : Génie logiciel

Julie Vachon, Hiver 2006 IFT2251 : Génie logiciel Chapitre 5. Conception Section 3. Principes et qualités Conception : principes et qualités 1. L activité de conception 2. Principes de conception 3. Concevoir pour changer 4. Interface et implémentation 5. Gérer les anomalies 6. Stratégies de conception 7. Couplage Cohésion Chap.5, Sect.3, p.2 Copyrights Julie Vachon, 2006 5.3.1. L activité de conception La conception est processus de résolution de problème (activité créative!) dont l objectif est de trouver et de décrire une façon: d implémenter les besoins fonctionnels du système tout en respectant les contraintes imposées par les besoins non fonctionnels (incluant le budget) et tout en adhérant aux principes généraux de qualité logicielle. L activité de conception Le concepteur doit faire face à une série de questions de conception et donc faire des choix: Chacune constitue un sous-problème du problème générale qu est la conception du système. Le concepteur doit faire un choix de conception pour résoudre chaque question: Ce processus implique de choisir la meilleure option parmi celles identifiées. Ce choix repose sur la connaissance que le concepteur possède au sujet des besoins, de l état courant de la conception, de la technologie disponible, des principes et meilleures pratiques du G.L., des expériences de succès antérieures. Chap.5, Sect.3, p.3 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.4 Copyrights Julie Vachon, 2006

L activité de conception Différents aspects de la conception L activité de conception Objectifs généraux visés par une bonne conception Conception architecturale Division du système en sous-systèmes et composants Conception détaillée Réalisation des cas d utilisation Conception des classes Conception des algorithmes Mais aussi: Conception des interfaces Conception des protocoles de communication Augmenter les profits en réduisant les coûts et en augmentant les revenus S assurer de répondre aux besoins spécifiés Accélérer le développement Maximiser la qualité du logiciel et en particulier: Utilisabilité Efficacité Fiabilité Facilité de maintenance Réutilisabilité Chap.5, Sect.3, p.5 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.6 Copyrights Julie Vachon, 2006 L activité de conception La qualité d un logiciel dépend principalement de sa conception Une bonne conception = 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 pour réaliser une tâche Un faible couplage : les modules sont relativement indépendants, ils ne dépendent pas trop des éléments d autres modules L abstraction et le masquage d information 5.3.2 Principes de conception Voici 11 principes à observer pour développer la meilleure conception possible 1. Diviser pour régner Il est plus difficile de confronter un gros problème d un seul coup que d y faire face en le gérant les petites parties individuelles 2. Augmenter la cohésion là où c est possible. --- cf. 5.3.7 Un système est cohésif s il garde ensemble les choses qui sont liées entre elles, et s il élimine les autres choses. Différents types de cohésion: fonctionnelle, par couches, communicationnelle, etc. 3. Réduire le couplage là où c est possible --- cf. 5.3.7 Il y a couplage lorsqu il existe de interdépendances entre les modules. Différents type de couplage: de contenu, commun, de contrôle, etc. Chap.5, Sect.3, p.7 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.8 Copyrights Julie Vachon, 2006

Principes de conception 4. Maintenir un niveau d abstraction élevé Veiller à ce que la conception cache les détails et remet à plus tard leur considération, afin de réduire la complexité 5. Augmenter la réutilisabilité là où c est possible. Concevoir des solutions générales qui puissent être réutilisées par la suite. 6. Réutiliser les designs existants 7. Faire une conception flexible --- cf. 5.3.3 Il est important d anticiper les changements et de proposer une conception qui puisse ultérieurement les suivre. 8. Anticiper l obsolescence --- cf. 5.3.3 Anticiper les changements technologiques, de façon à ce que les applications développées ne soient pas tributaires de ces derniers. 9. Envisager la portabilité --- cf. 5.3.3 10. Proposer une conception qui puisse être testée facilement 11. Adopter une stratégie de conception défensive Ne pas faire d hypothèse sur la façon dont les autres utiliseront le composant développer Assurer la robustesse du composant 5.3.3. Concevoir pour changer Analyse Besoins fonctionnels et non fonctionnels actuels et ceux à venir (?) Conception Un des principaux soucis de l activité de conception Faire une conception qui facilite l adaptation du logiciel aux changements Pendant la conception Importante qualité logicielle en jeu : évolubilité Principe mis en pratique : anticipation du changement Chap.5, Sect.3, p.9 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.10 Copyrights Julie Vachon, 2006 Concevoir pour changer Pourquoi? Quelques raisons de penser aux changements futurs Dans tous les cas, même les plus simples!, les besoins vont changer, même si aviez très très bien fait l analyse des besoins Plutôt que de se plaindre des besoins qui changent, il faut adapter l activité de conception pour prendre en compte les changements plus facilement Shalloway et Trott, 2001 Un logiciel qui ne change plus est un logiciel qui va bientôt disparaître Concevoir pour changer Pourquoi? Quelques conséquences indésirables Une conception, même «merveilleuse», peut se révéler extrêmement difficile et coûteuse à changer Nécessité de refaire une toute nouvelle conception pour intégrer un changement apparemment mineur En essayant d accommoder l architecture aux changements (au lieu de les y intégrer), le concepteur risque de briser l élégante structure initiale Application de plus en plus difficile à maintenir et inspirant peu confiance (fiabilité compromise?) Chap.5, Sect.3, p.11 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.12 Copyrights Julie Vachon, 2006

Concevoir pour changer Types de changements Concevoir pour changer Types de changements Sources de vrais changements Changements (perfectionnements) du logiciel imposés par les nouvelles exigences du client ou de l utilisateur Changements (adaptations) imposés par la modification de l environnement matériel, social, etc. Maintenance perfective Maintenance adaptative Chap.5, Sect.3, p.13 Copyrights Julie Vachon, 2006 Changement d algorithme Changement de la représentation des données Changement au niveau de la machine abstraite sous-jacente Changement au niveau des périphériques Changement de l environnement social Changements dus au processus de développement Chap.5, Sect.3, p.14 Copyrights Julie Vachon, 2006 5.3.4. Interface et implémentation C7 C8 C9 C2 C3 C4 C1 «contient» C5 C6 Raffinement de la conception : on décide que C2 est composé de C7, C8, C9 Qu advient-il de la relation C2 «utilise» C5? On doit savoir ce que C2 utilisait de C5 et ce que C5 rendait effectivement disponible On doit définir ce que C7, C8, C9 utilisent de C5 Comment préciser la façon dont un module en utilise un autre? Interface de module C2 C5 «utilise» C7? C5 C9 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 des mécanismes (ex. «public», «private», «protected») Pour faire la conception d un module M, on a besoin uniquement des interfaces des autres modules que M pourra utiliser Partie privée d un module Implémentation : façon dont les ressources sont concrètement représentées et réalisées dans le module Application du principe de séparation des préoccupations Décider quoi offrir? (Analyse et conception) Décider comment le réaliser? (Conception et implémentation) Chap.5, Sect.3, p.15 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.16 Copyrights Julie Vachon, 2006

Interface et implémentation Masquage d information Les clients d un module n ont accès qu à l information disponible dans son interface et satisfaisant aux contraintes de visibilité Avantages de cette approche? Facilité de compréhension, maintenance Défi? Déterminer ce qu on doit rendre accessible, ce qu on doit cacher pour un couplage faible et une cohésion forte Chap.5, Sect.3, p.17 Copyrights Julie Vachon, 2006 Interface et implémentation Les interfaces doivent contenir Seulement l info nécessaire L interface doit révéler le moins d information possible Toute l info nécessaire L interface doit donner suffisamment d information aux autres modules pour qu ils puissent utiliser les services offertes Pour favoriser l évolubilité du système Offrir une interface abstraite Cacher les détails de bas niveau (algorithme, représentation des données, etc.) Chap.5, Sect.3, p.18 Copyrights Julie Vachon, 2006 5.3.5. Gérer les anomalies Conception défensive Gérer les anomalies Conception défensive Malgré la rigueur du développement, impossible d avoir une confiance inconditionnelle dans le logiciel développé On doit développer des logiciels robustes, i.e., qui ont un comportement raisonnable même dans les circonstances imprévues État d un module qui ne peut offrir le service tel qu attendu et spécifié par son interface = État anormal Il faut pouvoir anticiper ces état anormaux, les gérer et les tolérer au mieux État d un module qui ne peut offrir le service tel qu attendu et spécifié par son interface = État anormal Causes possibles de la défaillance d un module Service invoqué avec des paramètres inadéquats Le module utilise un service défaillant exporté par un autre module Circonstances imprévisibles (débordement, etc.) Etc. Chap.5, Sect.3, p.19 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.20 Copyrights Julie Vachon, 2006

Gérer les anomalies Conception défensive 5.3.6 Stratégies de conception Stratégie descendante Un module serveur (i.e., offrant le service) Soit s exécute correctement et offre le service spécifié Soit entre dans un état anormal Le module serveur signale l anomalie en levant une exception auprès du module client Serveur termine son exécution Client notifié de l anomalie, se charge de gérer l exception adéquatement en activant un gestionnaire d exception Les exception qu un module serveur peut lever doivent être indiquées dans son interface Avantages Vue d ensemble du problème et de ce qu on désire réaliser Facilite la compréhension des problèmes et de leur décomposition «diviser pour régner» Recommandé pour documenter la conception Inconvénients Les sous-problèmes sont analysés de façon isolée Principes de généralisation et masquage d information non mis à profit Ne favorise pas la réutilisation Chap.5, Sect.3, p.21 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.22 Copyrights Julie Vachon, 2006 Stratégies de conception Stratégie ascendante Stratégies de conception Stratégie mixte («yo-yo») Avantages Permet d identifier ce qu il y a de commun entre les modules et permet d appliquer les principes de masquage d information et de généralisation Favorise la réutilisation Inconvénients Pas de vue d ensemble, quoi mettre dans les sous-modules? Risque de consacrer beaucoup d efforts à réaliser un module qui ne sera pas utilisé Conception = Activité créative qui nécessite du jugement Un bon concepteur applique une stratégie mixte Décomposition : on commence par une stratégie descendante pour identifier les sous-modules Synthèse : on fait la synthèse des sous-modules en termes d une hiérarchie de modules réutilisables construits en appliquant les principes de généralisation et de masquage d information Chap.5, Sect.3, p.23 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.24 Copyrights Julie Vachon, 2006

Stratégies de conception De la conception vers l implémentation Après validation de la conception Respect des propriétés fonctionnelles et non fonctionnelles l implémentation Stratégie descendante : tous les modules qui utilise le module M sont implémenté avant que M ne le soit M est temporairement simulé par un module «souche» (stub) Stratégie ascendante : tous les modules utilisés par un module M sont implémentés et testés avant que M soit implémenté M est temporairement simulé par un pilote module (module driver) Stratégie mixte : stratégie encouragée 5.3.7 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 Ces concepts peuvent d ailleurs s influencer l un et l autre. Chap.5, Sect.3, p.25 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.26 Copyrights Julie Vachon, 2006 Couplage Mesure de l interdépendance entre deux modules Un ensemble de modules est faiblement couplé si les liens de dépendances (cf. interactions induisant une relation «utilise») entre les modules sont peu nombreux Un faible couplage est précurseur D un bon découpage du logiciel : les éléments qui dépendent les uns des autres ne sont pas «éparpillés» à travers les modules D une facilité de maintenance : une modification dans un module affecte éventuellement un nombre restreint d autres modules, nombre de révisions réduites Chap.5, Sect.3, p.27 Copyrights Julie Vachon, 2006 Logiciel non couplé Peu vraissemblable Logiciel fortement couplé Couplage Logiciel faiblement couplé Interaction d utilisation Appel de méthode / procédure Utilisation d une variable Etc. Chap.5, Sect.3, p.28 Copyrights Julie Vachon, 2006

Couplage Types de couplage Types de couplage COUPLAGE de contenu commun de contrôle d estampillage de données d appel de routines d utilisation de type d importation externe Couplage fort Couplage faible Chap.5, Sect.3, p.29 Copyrights Julie Vachon, 2006 Couplage dangereux et difficile à comprendre Contenu Global Contrôle COUPLAGE Couplage fort d estampillage Couplage discipliné de données traditionnel d appel de routines d utilisation de type d importation Couplage faible externe Chap.5, Sect.3, p.30 Copyrights Julie Vachon, 2006 Types de couplage Cohésion Consulter les transparents de Laganière et Lethbridge pour une description de chacun des types de couplage. 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 ses é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 logiciel : 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 ont 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 Chap.5, Sect.3, p.31 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.32 Copyrights Julie Vachon, 2006

Types de cohésion Types de cohésion COHÉSION Cohésion forte Consulter les transparents de Laganière et Lethbridge pour une description de chacun des types de cohésion. Fonctionnelle Par couche Communicationnelle Séquentielle Procédurale Temporelle Utilitaire Aléatoire Cohésion faible Chap.5, Sect.3, p.33 Copyrights Julie Vachon, 2006 Chap.5, Sect.3, p.34 Copyrights Julie Vachon, 2006 Types de cohésion - Exemples Types de cohésion - Exemples Aléatoire : les fonctions du module n ont rien à voir les unes avec les autres, réunies par pure commodité : Réparer la voiture : Faire un gâteau : Étudier IFT2251 Procédurale : fonctions réunies parce qu elles doivent être exécutées dans un ordre donné (le flot de contrôle) : Préparer la dinde : Préparer les légumes : Mettre la table Logique : fonctions réunies autour d un thème commun Temporelle : fonctions réunies ensemble car leurs moments d exécution sont reliés dans le temps Chap.5, Sect.3, p.35 Copyrights Julie Vachon, 2006 [T] [T+X] [T+2X] : Voyager en voiture : Voyager en avion : Voyager en train Au coucher : Fermer la TV : Se brosser les dents : Fermer les lumières Communicationnelle : fonctions réunies car elle produisent ou opère sur le même type de données Séquentielle : fonctions réunies car les sorties de l une servent d entrées à l autre (flot de données) Chap.5, Sect.3, p.36 Copyrights Julie Vachon, 2006 : Trouver titre d un livre : Trouver prix d un livre : Trouver auteur d un livre : Remplir les trous : Sabler la voiture : Donner une première couche de peinture

Types de cohésion - exemples Fonctionnelle : toutes les fonctions réunies contribuent à l exécution d une même et unique tâche Le module contient toutes et seulement les fonctions nécessaire pour la réalisation de la tâche, le module réalise une seule et unique tâche Repeindre une voiture : Laver la voiture : Remplir les trous : Sabler la voiture F4 F4: Donner une première F5 couche de peinture F5: Donner une couche finale de peinture Chap.5, Sect.3, p.37 Copyrights Julie Vachon, 2006 Types de cohésion Facilité de maintenance Plus facile à maintenir Les fonctions s appliquent à des données communes Plus difficile à maintenir Les fonctions concernent le traitement de données disparates, le changement d une fonction dans un module peut avoir des répercussions dans plusieurs modules qui traitent le même type de données COHÉSION Fonctionnelle Par couches Séquentielle Communicationnelle Procédurale Temporelle Logique Aléatoire Cohésion forte Cohésion faible Chap.5, Sect.3, p.38 Copyrights Julie Vachon, 2006 Tâches à réaliser pendant la conception Concevoir et intégrer le réseau Mise en œuvre de la communication entre les processus distribués qui collaborent Concevoir l architecture des applications «Qui» fera «quoi» et «où»? Concevoir les interfaces utilisateurs du logiciel Concevoir et intégrer les bases de données Décrire les détails de la conception Spécifier ces détails puis les prototyper Concevoir et intégrer les contrôles du logiciel Mise en œuvre de tous les aspects liés au contrôle, à la correction, à la sécurité, à la tolérance aux fautes, à la protection des données, etc. Chap.5, Sect.3, p.39 Copyrights Julie Vachon, 2006