CSI1502%20Principes%20fondamentaux%20en%20conception%20des%20logiciels

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 lutilité 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
Cycle de vie logiciel

• Le cycle de vie dun logiciel inclue
  lutilisation et la maintenance
• Une version du logiciel qui est mis à la
  disposition dun 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 dun programme

5
Développement vs. Maintenance
Développement
Utilisation et Maintenance
En exemple Le bug de lan 2000
6
Développement et Effort au Maintient
Une petite augmentation du temps de développement
peut Réduire leffort 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 lont développé (règle des 3 ans
  en moyenne)
• Les mainteneurs doivent être capable de
  comprendre le programme quils nont pas conçus.
• Lhabilité 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 limplé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
  quelles sont découvertes si elles le sont
• Il ne sagit pas vraiment dun vrai modèle

9
Lapproche é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 limplémentation
• Originalement ce modèle fut proposé de façon
  linéaire sans backtracking
• Ceci est un objectif noble, mais irréaliste.

11
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 soccuper de problème inattendus lors des
  stages finaux du développement

13
Processus du développement itératif
14
ImportantVé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
  dassurer
• Clarté, cohérence et complet
• Une évaluation du concept devrait sassurer que
  chaque besoin à été addressé suffisament

15
Techniques de VérificationRevue

• Un concept ou un implémentation peut-être évaluée
  durant une revue
• Lobjectif dune 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 dentrée
• Actions dutilisateur ou dautres conditions
  initiales
• Données de sortie attendues
• Il nest pas possible de vérifier tous les cas
  possible

17
Techniques de Vérification Vérification de Boîte
Noire

• Vérification Boîte Noire détermine un ensemble
  spécifique de données dentrées et de données de
  sortie attendues
• Une catégorie déquivalence est une collection de
  données dentrées
• En exemple chiffres positifs , 0..99
• Cas test -9, -500, 5, 12, 101, 300
• Deux ensemble dentrée appartienne à la même
  catégorie déquivalence si il y a de raison de
  croire si lun marche que lautre aussi va
  marcher
• Donc la vérification dun des ensemble dentré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
  limplémentation dune 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 dagir 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é dun des besoins
• Une interface dutilisateur
• Cest 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
Modèle de développement évolutionnaire
23
Cycle damélioration 1Etablir la portée

• Nous devons dabord établir la porté du
  raffinement afin de définir la nature spécifique
  du prochain raffinement
• Par exemple
• Linterface usager
• La faisabilité dun 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 lexpérience

24
Cycle damé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 lune de
  lautre
• Considérez de réutiliser les classes existantes

25
Cycle damé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 sutilisent lun lautre pour
  les services quils donnent
• Agrégation, aussi dénommé composition, permets à
  un objet de devenir une partie dun 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 damélioration 3(cont.)lhéritage

• Lhéritage, tel que vu en détail au chapitre 7,
  permet à la création dune 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 damé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
  raffiner le 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 linteraction 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 codeUn Exemple (AlarmClock
class)

• Invariant
• Lobjet Alarmclock
• Garde en mémoire un temps dalarme unique en
  terme de temps et minutes
• Ne peut faire la distinction entre AM et PM
• À des valeurs limité tel que
• 1 lt hour lt 12 et 0 lt minutes lt 59
• Méthodes mise à jour
• public void advanceOneHour()
• pré condition
• hour lt 12
• change
• hour
• post condition
• La valeur de hour est unité plus grande que
  avant

30
Spécification du codeUn Exemple (AlarmClock
class)

• Méthodes mise à jour
• public void advanceTenMinutes()
• pré condition
• minutes lt 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 lensembre invariant et les conditions
  pré/post
• Nous pouvons utiliser la logique formelle pour
  prouver quun 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 dusager graphique avec
  souris
• Permettre à lusager de tracer des lignes,
  cercles, ovales, rectangles et carrées
• Permettre à lusager de changer la couleur de
  dessin
• Permettre à lusager de remplir une forme, tous
  sauf une ligne avec une couleur
• Permettre à lusager de commencer un nouveau
  dessin
• Permettre à lusager de créer des lignes
  multiples

33
Le projet PaintBox Étapes initiales de
raffinement

• Créer linterface usager de base
• Permettre à lusager de dessiner et remplir les
  formes et de changer de couleur
• Permettre à lusager de choisir, bouger et
  modifier les formes
• Permettre à lusager de couper, coller et copier
  les formes
• Permettre à lusager de sauver et charger des
  dessins
• Permettre à lusager de commencer un nouveau
  dessin nimporte quand

34
Le projet PaintBox linterface usager de base
File Edit
Select
Oval
Line
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 linterface dusager 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 PaintBoxRaffinement restant

• Limplémentation au complet peut être téléchargé
  du site web du livre
• Voir section 10.4 du livre

37
Obtenir les besoins de lusager

• Problème de la collection de connaissances
• Il est difficile dextraire des informations
  dhumains
• 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 lexterne ou
  de linterene
• Jugement aléatoire vs ouvert desprit
• Voir lInternet pour les test et pour les
  sceptiques!!!

38
SommaireChapitre 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