Le document traite de la conception en génie logiciel, en soulignant son rôle crucial dans le cycle de vie du développement logiciel et son influence sur la qualité du produit final. Il aborde les principes de modularité, la décomposition des problèmes, et l'utilisation de méthodes orientées objet et de diagrammes UML pour formaliser la conception. Enfin, il souligne l'importance d'une bonne architecture pour éviter des coûts récurrents liés à des erreurs de conception.

1. Génie Logiciel
CONCEPTION

2. Position dans le cycle de vie
 Contexte :
 étant donnée une spécification
(ce que doit faire le produit)
 Phase de conception :
 architecture du produit
(comment il est structuré pour faire ce qu'il doit faire)
→ document de conception globale / détaillée
(si cycle de vie en V : + plan d'intégration)
 Phase suivante : codage

3. Cycle de vie :modèle en V (rappel)

4. Deux niveaux de détail
 Conception globale (ou préliminaire)
 choix fondamentaux d'architecture logicielle
 en lien éventuel avec l'architecture matérielle
 Conception détaillée
 description précise de chaque module
 algorithmes mis en œuvre
 traitements effectués en cas d'erreur

5. Conception détaillée
 Souvent escamotée
 petite taille des modules
→ description précise des algorithmes pas nécessaire
☛ Pas traitée dans ce cours

6. Objectifs de la conception
 Séparation les problèmes
 permet d'appréhender un problème complexe
 Décomposition modulaire du logiciel
 permet le développement en parallèle (test y compris)
 facilite la maintenance (corrective ou évolutive)
 documentation et isolation des comportements
 localisation des modifications
 facilite la réutilisation

7. Importance de la conception
 Influence considérable sur la réalisation du logiciel
 en particulier sur la qualité
 Réponse au besoin spécifique du client
@@Erreur dans la conception (mauvaise architecture)
→ Impacts sur le budget et le temps de réalisation
→ surcoûts récurrents pour palier les défauts

8. Facteurs de qualité
de la conception / architecture
 Robustesse
 aptitude à fonctionner dans des conditions anormales
 Extensibilité
 aptitude à s'adapter aux changements de spécification
 Réutilisabilité
 aptitude à resservir dans de nouvelles applications
 Compatibilité
 aptitude à être combinée avec d'autres logiciels
 Efficacité
 bonne utilisation des ressources
 Portabilité
 facilité d'adaptation à différents environnements
 Vérifiabilité
 facilité à être vérifiée

9. Facteurs de qualité
de la conception / architecture
 Sécurité
 Intégrité : aptitude à protéger ses composants (y compris ses données) contre
des modifications non autorisées
 Confidentialité : aptitude à masquer des informations privées (à des agents non
autorisés)
 Correction
 degré de conformité par rapport aux spécifications.
 …

10. Quelques chiffres
 Bonne conception → facilité de maintenance
 Une analyse des coûts de maintenance fait ressortir les chiffres suivants :
 42% dans les exigences des utilisateurs
 18% modification du format des données
 13% correction d'erreurs en urgence
 9% correction d'erreurs de routine
 6% modification de matériel
 5% documentation
 4% amélioration de l'efficacité
 3% autres

11. Facilité de maintenance
 Coût de maintenance principal = modification de spécification et format
de données(60%)
→ Pouvoir effectuer les modifications de manière aussi simple que possible
→ Permettre et exploiter la traçabilité des spécifications
☛ Un outil méthodologique : la modularité

12. Plusieurs notions de module
 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), ...

13. Critères de modularité
(comment analyser la modularité)
 Décomposabilité modulaire
 Composabilité modulaire
 Compréhensibilité modulaire
 Continuité modulaire
 Protection modulaire
☛Pas toujours facile à satisfaire( contre exemple)
→ être pragmatique, faire au mieux

14. Décomposabilité modulaire
(critère de modularité)
 Définition
 Le module découpe un problème complexe en problèmes plus petits, solubles
isolément
(décomposition souvent récursive)
 Exemple
 modules issus d'une conception descendante
 Contre-exemple
 module d'initialisation globale

15. Composabilité modulaire
(critère de modularité)
 Définition
 Les modules peuvent facilement être utilisés et combinés, éventuellement dans
des contextes différents de ceux pour lesquels ils ont été initialement
développés
 Exemple
 bibliothèque de sous-programmes

16. Protection modulaire
(critère de modularité)
 Définition
 Si une condition anormale se produit pendant l'exécution du module, elle reste
localisée au module (ou à quelques modules voisins)
 Exemple
 validation des données d'entrées au plus tôt
 Contre-exemple
 exceptions inter-modules (lieu de traitement d'erreur séparé du lieu de
production de l'erreur)

17. Principes de modularité
(règles à respecter)
 Contrôle des tailles
 Découpage logique
 Minimisation des interfaces
 Simplification des interfaces
 Interfaces explicites
 Masquage de l’information
☛ Pas toujours facile à satisfaire (∃ contre-exemples)
→ être pragmatique

18. Simplification des interfaces
(principe de modularité à respecter)
 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
 Critères
 continuité, protection

19. Masquage de l'information
(principe de modularité à respecter)
 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)
 Critères
 continuité (le contenu d'un module peut changer sans que les autres modules
doivent être modifiés)

20. Méthodes de conception
orientée objet
 Méthode de Booch (1986) :
 définir le problème
 développer une stratégie informelle de résolution
 identifier les objets et leurs attributs
 identifier les opérations sur ces objets
 établir les interfaces pour ces opérations
 implémenter les objets
 éventuellement répéter le processus récursivement

21. Remarques sur la phase de
conception
 Analyse des besoins et conception sont étroitement mêlées
 point de départ : formulation du problème
 élaboration/formulation d'une solution
 structuration logicielle de cette solution
 C'est le cas également avec UML (→)

22. UML
 Langage de modélisation
 UML = Unified Modeling Language
 notations normalisées
 Pour la résolution de problèmes orientée objet
 Mais c'est une notation, pas une méthode !

23. Modèle
 Modèle = abstraction du problème sous-jacent
 objets qui interagissent par envoi de messages
 attributs des objets (valeurs → état de l'objet)
 opérations/comportements des objets
 objets de mêmes type = instances d'une classe

24. (Principaux) diagrammes UML
 diagrammes d'objets
 diagrammes de classes
 diagrammes de cas d'utilisation
 diagrammes de composants
 diagrammes de déploiement
 diagrammes de séquence
 diagrammes de collaboration
 diagrammes d'états-transitions
 diagrammes d'activités

25. Diagramme de cas d'utilisation

26. Diagramme de cas d'utilisation

27. Diagramme de cas d'utilisation
 Expression de besoins/exigences [angl. requirements]
 nouveau cas d'utilisation → nouvelles exigences
 Communication aisée avec le client
 simplicité de notation
 Génération de tests
 ensemble de scénarios → ensemble de cas de test

28. Diagramme de classe
 Aperçu du système
 classes et relations entre elles
 Vue statique
 existence d'interactions mais pas d'information sur le comportement effectif

29. Diagramme de classe
 commande client pour une vente au détail

30. Diagramme de package
 Package = collection d'éléments reliés logiquement

31. UML et cycle de vie
 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

32. À retenir
 Conception
 séparation des problèmes / décomposition modulaire
 Méthodologie
 globalement descendante, parfois montante.
 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

33. Fin
MERCI