CSI1502 Principes fondamentaux en conception des logiciels

1. CSI1502Principes fondamentaux en conception des logiciels Chapter 10: Introduction au Génie Logiciel

2. Objectifs du cours: Génie logiciel • La qualité de logiciel est un résultat direct du processus utilisé lors de la création • Comprendre et connaître l`utilité de ce qui suit: • Modèles de conception de logiciel • Les cycles de vie logiciel et leurs implications • Développement linéaire vs. Itératif • Objectifs et techniques des tests • Une approche évolutionnaire au développement OO

3. Développement Utilisation Maintenance Cycle de vie logiciel • Le cycle de vie d`un logiciel inclue l`utilisation et la maintenance • Une version du logiciel qui est mis à la disposition d`un utilisateur est dénommé «release»

4. Au sujet de laMaintenance • La maintenance inclues toutes les modifications sur un programme existant; • Améliorations et • Correction de défaut • Un bon concept et développement facilitent la maintenance • Les efforts de maintenance ont tendance à demander plus de travaille que le développement initial du logiciel • Le But du génie logiciel: • Réduire au maximum le travail nécessaire à la création et le maintien d`un programme

5. Développement vs. Maintenance Développement Utilisation et Maintenance En exemple: Le bug de l`an 2000

6. Développement Maintenance Développement Maintenance Développement et Effort au Maintient Une petite augmentation du temps de développement peut Réduire l`effort nécessaire à la maintenance  Passez plus de temps à la conception, vérification et documentation

7. Développement et Effort au Maintient • Souvent ceux qui maintiennent le logiciel ne sont pas ceux qui l`ont développé («règle» des 3 ans en moyenne) • Les mainteneurs doivent être capable de comprendre le programme qu`ils n`ont pas conçus. • L`habilité de lire et comprendre un programme dépend de: • Comment clairement les besoins initiaux ont été définis • La qualité du concept du programme • La qualité de l`implémentation du programme • La qualité de la documentation du programme

8. Développer du logiciel de haute qualité:Modèles de conception de logiciel • un modèles de conception de logiciel est une approche organisée afin de créer du logiciel de qualité • Trop de programmeurs suivent une approche écrire-et-modifier • Ils écrivent un programme et le modifient jusqu`à ce que il soit fonctionnel, sans égard pour la conception du système • Les erreurs sont adressé au fur et à mesure qu`elles sont découvertes; si elles le sont • Il ne s`agit pas vraiment d`un vrai modèle

9. Modifier le programme Écrire le programme L`approche écrire-et-modifier

10. Le modèle «Waterfall» • Le modèle «Waterfall» fut développé dans les années `70 • Les activités suivantes doivent être adressées spécifiquement durant le développement • Établir clairement et sans ambiguïté les besoins • Créer un concept propre à partir des besoins • Implémenter le concept • Vérifier l`implémentation • Originalement ce modèle fut proposé de façon linéaire sans «backtracking» • Ceci est un objectif noble, mais irréaliste.

11. Établir les besoins Créer un concept Implémenter le concept Vérifier le système Le modèle «Waterfall»

12. Développement itératif: Le modèle «Waterfall» avec «backtracking» • Le développement itératif permet aux développeurs de faire des boucles aux travers des diffèrents stages du développement • Le «Backtracking» ne doit pas être utilisé aléatoirement • Quand utiliser le «Backtracking» ? • Pour s`occuper de problème inattendus lors des stages finaux du développement

13. Implémenter le concept Établir les besoins Vérifier le système Créer un concept Processus du développement itératif:

14. Important:Vérification itérative • Les résultats de chaque stage doivent être prudemment vérifié avant de poursuivre le prochain stage • Avant de commencer la conception, par exemple, les besoins devraient être vérifiés afin d`assurer: • Clarté, cohérence et complet • Une évaluation du concept devrait s`assurer que chaque besoin à été addressé suffisament

15. Techniques de Vérification:Revue • Un concept ou un implémentation peut-être évaluée durant une revue • L`objectif d`une revue est de identifier les problèmes et non de les résoudre

16. Techniques de Vérification: Créer des cas test • En général, le but de la vérification est de trouver des erreurs. • Ceci est souvent dénommé vérification des défauts • Un bon test trouve des problèmes dans un programme • Un cas test inclus • Un ensemble de données d`entrée • Actions d`utilisateur ou d`autres conditions initiales • Données de sortie attendues • Il n`est pas possible de vérifier tous les cas possible

17. Techniques de Vérification: Vérification de Boîte Noire • Vérification Boîte Noiredétermine un ensemble spécifique de données d`entrées et de données de sortie attendues • Une catégorie d`équivalence est une collection de données d`entrées • En exemple: chiffres positifs , 0..99 • Cas test: -9, -500, 5, 12, 101, 300 • Deux ensemble d`entrée appartienne à la même catégorie d`équivalence si il y a de raison de croire si l`un marche que l`autre aussi va marcher • Donc la vérification d`un des ensemble d`entrée vérifies toutes la catégorie d`équivalence

18. Techniques de Vérification: Vérification de Boîte Blanche • Vérification Boîte Blanche aussi dénommé vérification de boîte de ver • Se concentre sur la logique interne, tel que l`implémentation d`une méthode  nous vérifions le code en soi-même • «Statement coverage» garantie que toutes les commandes dans une méthode soient exécutées • «Condition coverage» garantie que toutes exécutions conditionnelles dans une méthodes soient exécutées

19. Prototypes: Utile pour vendre vos idées • Un prototype est un programme crée pour explorer un certain concept • Faire des prototypes est plus que utile, efficace (du point de vu temps, coût) que d`agir sur une assomption qui pourrait se revirer • Usuellement un prototype est crée pour communiquer au un client : • Pour une tâche particulière • La faisabilité d`un des besoins • Une interface d`utilisateur • C`est une façon de valider les besoins

20. Prototypes jetables vs. Prototypes évolutionnaires • Un prototype rapide («hack» en anglais) pour vérifier une idée ou concept est dénommé prototypes jetables • Les prototypes jetables ne sont pas incorporés dans le système final • Car un prototype évolutionnaire est conçu de façon plus prudente, il peut se faire incorporer dans le système final • Les prototypes évolutionnaires offrent un double bénéfice mais à un coût plus élevé

21. Développement de logiciel large: Une approche de développement évolutionnaire • Le développement évolutionnaire divise le procesus de conception en • Concept architectural (haut niveau) – classe primaire et interactions majeures • Concept détaillée – classes spécifiques, méthodes, et algorithmes • Ceci permet de créer des cycles de raffinement • Chaque cycle de raffinement se concentre sur un des aspects du système • Pour chaque cycle de raffinement qui passe, le système évolue

22. Vérification de Système Établir la portée Établir les besoins Concept architectural Vérification d`unité et intégration Identifier les classes & objet Implémentation Identifier les relations Concept détaillée Modèle de développement évolutionnaire

23. Cycle d`amélioration: #1Etablir la portée • Nous devons d`abord établir la porté du raffinement afin de définir la nature spécifique du prochain raffinement • Par exemple: • L`interface usager • La faisabilité d`un besoin particulier • Des classes outils pour le support général du programme • La programmation OO est bien conçue pour cette approche • Choisir le raffinement le plus appropriés est important et demande de l`expérience

24. Cycle d`amélioration: #2Identifier les classes & objets • Identifier les classes et objets qui ont rapport au raffinement courant. Regarder aux noms dans le document des besoins. Catégories candidates incluent : • Objets Physiques (livres, boules, etc…) • Personne (étudiant, professeur, etc…) • Places (salle, aéroport, etc…) • Contenant (liste de transaction, boîte, etc…) • Evénements (vente, rencontre, accident, etc…) • Base de Données (catalogue, etc…) • Les catégories peuvent faire partie l`une de l`autre • Considérez de réutiliser les classes existantes

25. Cycle d`amélioration: #3Identifier les relations • Identifier les relations entre classe • Association générale («utilise») • agrégation («à-un») • héritage (“est-un”) • Les Objets associés s`utilisent l`un l`autre pour les services qu`ils donnent • Agrégation, aussi dénommé composition, permets à un objet de devenir une partie d`un autre • La Cardinalité décrit la relation numérique entre les objets • En exemple une auto à quatre roues qui lui sont associées

26. Cycle d`amélioration: #3(cont.)l`héritage • L`héritage, tel que vu en détail au chapitre 7, permet à la création d`une nouvelle classe abstraite «parent» dont le seul objectif est de • Réunir des données et méthodes communes en une seul place • Utilisez le diagramme de classe UML pour montrer les rélation

27. Cycle d`amélioration: #4-6conception détaillé, implémentation et vérification • Finalement, un cycle de raffinement inclus la conception détaillé, implémentation et la vérification • Tous les membres de chaque classe doivent être définis • Chaque classe doit être implementé • Des «Stubs» sont parfois crées pour permettre de raffinerle code à vérifier • Une vérification unitaire se concentre sur un membre particulier tel que une méthode ou un classe • Une vérification intégration test se concentre sur l`interaction entre les membres du système

28. Spécification du code • Spécification détaillé de conception • Invariant: une collection de faits qui sont vrais • Pré condition/ Post condition • Pré condition : Conditions qui nécessitent que le code exécute correctement • Post conditions: Corrige les changements après que le code ait exécuté

29. Spécification du code:Un Exemple (AlarmClock class) Invariant L`objet Alarmclock • Garde en mémoire un temps d`alarme unique en terme de temps et minutes • Ne peut faire la distinction entre AM et PM • À des valeurs limité tel que: • 1 <= hour <= 12 et 0 <= minutes <= 59 Méthodes mise à jour public void advanceOneHour() pré condition hour < 12 change hour post condition La valeur de hour est unité plus grande que avant

30. Spécification du code:Un Exemple (AlarmClock class) Méthodes mise à jour public void advanceTenMinutes() pré condition minutes < 50 change minutes post condition La valeur de minutes est 10 unités plus grande que avant • Nous pouvons utiliser la logique formelle pour exprimer l`ensembre invariant et les conditions pré/post • Nous pouvons utiliser la logique formelle pour prouver qu`un morceau de code est «vrai» Source: “The object of Jva, David D Riley, Addison-Wesley, 2002

31. Obtenir les besoins: Le projet PaintBox • Tâche (Haut Niveau): • Créer un programme qui permet à un usager de peindre divers formes et tailles sur un écran • Comment peut-on accomplir ceci?

32. Le projet PaintBox :Besoins • Avoir une interface d`usager graphique avec souris • Permettre à l`usager de tracer des lignes, cercles, ovales, rectangles et carrées • Permettre à l`usager de changer la couleur de dessin • Permettre à l`usager de remplir une forme, tous sauf une ligne avec une couleur • Permettre à l`usager de commencer un nouveau dessin • Permettre à l`usager de créer des lignes multiples

33. Le projet PaintBox :Étapes initiales de raffinement • Créer l`interface usager de base • Permettre à l`usager de dessiner et remplir les formes et de changer de couleur • Permettre à l`usager de choisir, bouger et modifier les formes • Permettre à l`usager de couper, coller et copier les formes • Permettre à l`usager de sauver et charger des dessins • Permettre à l`usager de commencer un nouveau dessin n`importe quand

34. Le projet PaintBox : l`interface usager de base File Edit Select Line Oval Rect Color Drawing Area

35. Le projet PaintBox : • Discussions avec le client créent de nouveaux besoins qui sont intégré dans le document de besoin • Ensuite le concept architectural est préparé • Les étapes de raffinement sont déterminé • #1: l`interface d`usager graphique avec souris • #2: dessiner des forme de bases en utilisant des couleurs • #3: couper, copier et coller des formes • #4: choisir, bouger et remplir les formes • #5: modifier les dimensions des formes • #6: sauvegarder et charger les dessin • #7: touche final tel que un écran de présentation

36. Le projet PaintBox:Raffinement restant • L`implémentation au complet peut être téléchargé du site web du livre • Voir section 10.4 du livre

37. Obtenir les besoins de l`usager • Problème de la collection de connaissances: • Il est difficile d`extraire des informations d`humains • Type de personnalité différents: • Niveau de détail, conception, pensée, etc… • Myers Briggs (16 types), entre autres • Traitement de données et informations: concret vs abstrait • Prise de décision: logique et objectif vs relation de valeur et subjectif • Introverti vs extraverti: stimuli de l`externe ou de l`interene • Jugement: aléatoire vs «ouvert d`esprit» • Voir l`Internet pour les test et pour les sceptiques!!!

38. Sommaire:Chapitre 10 • Le Chapitre 10 en résumé: • Modèles de conception de logiciel • Les cycles de vie logiciel et leurs implications • Développement linéaire vs. Itératif • Objectifs et techniques des tests • Une approche évolutionnaire au développement OO