Ce cours est une introduction au Génie Logiciel, il présente l'ensemble des concepts de base du domaine logiciel.

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