Structures de données et algorithmes
Chapitre 1 Techniques de programmation
1ièrepartie : Qualité des logiciels
1.1 Les facettes de la qualité du logiciel
1.1.1 Facteurs internes et externes
Objectifs : Avoir des programmes rapides, fiables, ergonomiques, lisibles, modulaires et structurés Ces objectifs appartiennent à deux catégories
Facteurs externes Facteurs internes
Efficacité Modularité
Facilité d’adaptation
Les facteurs externes dépendent des facteurs internes!
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
3
1.1 Les facettes de la qualité du logiciel
1.1.2 Facteurs externes de qualité
l
Validité
C’est l’aptitude d’un produit logiciel à réaliser exactement les tâches définies par sa spécification.
l
Robustesse
C’est l’aptitude d’un logiciel à fonctionner même dans des conditions anormales.
Robustesse
Spécification
Validité figure 1 - Validité et robustesse
1.1 Les facettes de la qualité du logiciel
1.1.2 Facteurs externes de qualité
l
Extensibilité
C’est la facilité d’adaptation d’un logiciel aux changements de spécifications.
l
Réutilisabilité
C’est l’aptitude d’un logiciel à être réutilisé en tout ou en partie pour des nouvelles applications.
l
Compatibilité
C’est l’aptitude des logiciels à pouvoir être combinés les uns avec les autres.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
5
1.1.2 Facteurs externes de qualité
l
Efficacité
C’est la bonne utilisation des ressources du matériel informatique.
l
Portabilité
C’est la facilité avec laquelle un produit logiciel peut être adapté à différents environnements matériels et logiciels.
l
Vérifiabilité
C’est la facilité de préparation des procédures de recettes et de certification
(notamment des tests et procédures de déverminage).
1.1 Les facettes de la qualité du logiciel
1.1.2 Facteurs externes de qualité
l
Intégrité
C’est l’aptitude d’un logiciel à protéger ses différents composants contre les accès ou des modifications non autorisées.
l
Facilité d’utilisation
C’est la facilité avec laquelle les utilisateurs d’un logiciel peuvent apprendre comment :
- l’utiliser
- le faire fonctionner - préparer les données - interpréter les résultats
- et aussi comment réparer les effets en cas d’erreur.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
7
1.1 Les facettes de la qualité du logiciel
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
Spécification
Conception
Verification
Programmation Tests
Rafinement Production
Maintenance
Documentation
figure 2 - Cycle de vie d’un logiciel
1.1 Les facettes de la qualité du logiciel
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
l
Spécification
C’est la phase où il faut définir toutes les tâches que le logiciel doit effectuées. C’est ici qu’il faut identifier tousles aspects du problème.
l
Conception
C’est la phase où il faut concevoir tous les aspects techniques du logiciel, autant au niveau des structures de données, des
algorithmes, de l’interface usager, des périphériques, de la documentation, etc.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
9
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
l
Vérification
Après la conception, il est important de s’assurer que toutes les spécifications ont été respectée lors de la conception. Elles doivent être vérifiées et validées (comme les entrées/sorties des différents éléments du programme par exemple).
l
Programmation
C’est l’écriture du code. C’est ici qu’il faut traduire les algorithmes en pseudo-code vers un langage approprié.
1.1 Les facettes de la qualité du logiciel
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
l
Tests
Cette étape sert à identifier et corriger le plus d’erreurs possibles.
Tous les types d’erreurs doivent être vérifiés (les entrés/sorties, fonctionnement général, robustesse, interface usager, etc.) l
Raffinement
C’est la phase d’amélioration du logiciel.
Voici 2 exemples typiques d’amélioration :
Parfois, certaines simplifications sont faites lors de la conception et nécessitent quelques ajustements.
De plus, l’usage préliminaire du logiciel lors de la phase de test permet de déceler des manques ou des parties peu performantes par rapport aux spécifications initiales.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
11
1.1 Les facettes de la qualité du logiciel
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
l
Production
C’est la production, la distribution et l’implantation du logiciel.
l
Maintenance
La maintenance d’un logiciels n’est pas comme l’entretient d’un objet qui s’use, c’est plutôt l’amélioration continue du produit. Les systèmes changent et les spécifications changent au fil du temps.
Ainsi, il importe de maintenir le logiciel toujours fidèles aux spécifications même si ces dernières sont changeantes. De plus, les usagers trouveront immanquablement des problèmes que la phase de tests n’avait pas permis d’identifier.
1.1 Les facettes de la qualité du logiciel
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
l
On estime que 70% du coût d’un logiciel est consacré à la maintenance. La qualité d’un logiciel ne peut-être satisfaite si elle néglige cet aspect.
l
La documentation est réalisée soit pendant le
développement du système, soit jamais!
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
13
1.1.3 Le cycle de vie d’un logiciel et sa maintenance
Autres: 3,4%
Amélioration d’efficacité: 4%
Documentation: 5,5%
Modifications du matériel: 6,2%
Corrections d’erreurs de routine: 9%
Corrections d’erreurs en urgence: 12,4%
Modifications de formats de données: 17,4%
Modifications dans les exigences des utilisateurs: 41,8%
figure 3 - Répartition des tâches pour la maintenance
1.1 Les facettes de la qualité du logiciel
1.1.4 Les qualités essentielles d’un logiciel
Deux sous-groupes de solutions apparaissent
l
Réutilisabilité, extensibilité et compatibilité
Exigent des techniques architecturales qui produisent des programmes souples et décentralisés, composés de modules cohérents connectés par des interfaces bien définies
l
Validité et robustesse
Favorisées par des techniques qui permettent le développement systématique de logiciels grâce à la spécification précise des besoins et des contraintes
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
15
1.2 La modularité
l
Modulaire ≡ Structuré ≡ Convivial
l
La programmation modulaire est définie comme la construction de programme par assemblage d’éléments de petite taille (des sous-programmes)
l
Pour un soucis d’extensibilité et de réutilisabilité les modules doivent être autonomes, cohérents et organisés en architectures robustes
1.2 La modularité
1.2.1 Critères pour une méthode modulaire
l
Décomposabilité modulaire
Une méthode de conception répond au critère de la
décomposabilité modulaire si elle aide à décomposer un nouveau problème en plusieurs sous-problèmes dont la solution peut être recherchée séparément.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
17
1.2.1 Critères pour une méthode modulaire
l
Composabilité modulaire
Une méthode répond au critère de composabilité modulaire si elle favorise la production d’éléments de logiciels qui peuvent être combinés librement les uns avec les autres pour produire de nouveaux systèmes.
figure 5 - Composabilité modulaire
1.2 La modularité
1.2.1 Critères pour une méthode modulaire
l
Compréhensibilité modulaire
Une méthode favorise la compréhensibilité modulaire si elle aide à produire des modules dont chacun peut être compris isolément.
L’analyse d’un élément ne doit consulter que quelques voisins au plus.
figure 6 - Compréhensibilité modulaire
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
19
1.2 La modularité
1.2.1 Critères pour une méthode modulaire
l
Continuité modulaire
Une méthode de conception répond au critère de continuité modulaire si une petite modification de la spécification du problème n’amène à modifier qu’un seul module ou peu de modules.
1.2 La modularité
1.2.1 Critères pour une méthode modulaire
l
Protection modulaire
Une méthode répond au critère de protection modulaire si elle conduit à des architectures dans lesquelles l’effet d’une condition anormale, se produisant à l’exécution d’un module, reste localisé à ce module, tout au moins ne se propage qu’à quelques modules voisins.
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
21
1.2.2 Principes de modularité
l
Unités modulaire linguistique
Les modules doivent correspondre aux unités syntaxiques des langages.
l
Peu d’interfaces
Tout module doit communiquer avec d’autres, mais aussi peu que possible.
figure 8 - Type de structures d’interconnection de modules
(a) (b) (c)
1.2 La modularité
1.2.2 Principes de modularité
l
Petites interfaces (couplage faible)
Si deux modules communiquent, ils doivent échanger aussi peu d’informations que possible.
l
Interfaces explicites
Chaque fois que deux modules communiquent, la communication doit être claire.
figure 9 - Communication inter modules
GPA665 - Automne 2002 © Mohamed Cheriet, ing., Ph. D.
23
1.2 La modularité
1.2.2 Principes de modularité
l
Masquage de l’information
Toute information concernant un module doit être privée, sauf si elle est explicitement déclarée publique.
figure 10 - Masquage d’informations
1.2 La modularité
1.2.2 Principes de modularité
l
Le principe d’ouverture-fermeture
Une bonne technique de décomposition modulaire doit satisfaire un critère supplémentaire: elle doit fournir des modules qui soient à la fois ouverts et fermés.
Un module sera dit :
– ouvert s’il est encore disponible pour des extensions
– fermé s’il est prêt à être utilisé dans d’autres modules
