CSI1502 Principes fondamentaux en conception des logiciels

Objectifs du cours:
Génie logiciel
CSI1502
Principes fondamentaux en
conception des logiciels
„
„
Chapter 10:
Introduction au 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
2
Au sujet de la
Maintenance
Cycle de vie logiciel
„
Le cycle de vie d`un logiciel inclue l`utilisation et la
maintenance
Développement
„
Utilisation
„
„
Maintenance
„
„
Une version du logiciel qui est mis à la disposition
d`un utilisateur est dénommé «release»
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
3
Développement vs.
Maintenance
4
Développement et
Effort au Maintient
Développement
Développement
Développement
Utilisation et
Maintenance
En exemple:
Le bug de l`an 2000
Maintenance
Maintenance
Une petite augmentation du temps de développement peut
Réduire l`effort nécessaire à la maintenance Æ
Passez plus de temps à la conception, vé
vérification et documentation
5
6
1
Développer du logiciel de haute
qualité:
Modèles de conception de logiciel
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
„
„
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
7
8
L`approche écrire-et-modifier
Le modèle «Waterfall»
„
„
Écrire le
programme
Modifier le
programme
„
„
9
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.
10
Développement itératif:
Le modèle «Waterfall»
avec «backtracking»
Le modèle «Waterfall»
„
Établir
les besoins
Créer un
concept
„
Implémenter
le concept
Vérifier le
système
„
11
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
12
2
Processus du développement
itératif:
Important:
Vérification itérative
„
Établir
les besoins
Créer un
concept
Implémenter
le concept
Vérifier le
système
„
„
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
13
14
Techniques de Vérification:
Créer des cas test
Techniques de Vérification:
Revue
„
Un concept ou un implémentation peut-être évaluée
durant une revue
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
„
„
„
L`objectif d`une revue est de identifier les problèmes et
non de les résoudre
„
„
Il n`est pas possible de vérifier tous les cas possible
„
15
16
Techniques de Vérification:
Vérification de Boîte Noire
„
„
„
Techniques de Vérification:
Vérification de Boîte Blanche
Vérification Boîte Noire dé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
17
„
„
„
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
18
3
Prototypes jetables vs.
Prototypes évolutionnaires
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
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
Modèle de
développement évolutionnaire
Établir
les besoins
„
„
Concept
architectural
Établir la
portée
Vérification
d`unité et
intégration
Vérification
de Système
Identifier les
classes & objet
Identifier les
relations
Implémentation
Concept
détaillée
21
22
Cycle d`amélioration: #1
Etablir la portée
„
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é
19
Développement de logiciel large:
Une approche de
développement évolutionnaire
„
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
Cycle d`amélioration: #2
Identifier les classes & objets
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
„
23
„
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
24
4
Cycle d`amélioration: #3
Identifier les relations
„
„
„
Cycle d`amélioration: #3(cont.)
l`héritage
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 obje
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
25
associées
„
„
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
26
Cycle d`amélioration: #4-6
conception détaillé, implémentation
et vérification
„
„
„
Spécification du code
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
l`interaction entre les membres du système
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é
27
28
Spécification du code:
Un Exemple (AlarmClock class)
Spécification du code:
Un Exemple (AlarmClock class)
Méthodes mise à jour
public void advanceTenMinutes()
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
pré condition
minutes < 50
change
minutes
post condition
La valeur de minutes est 10 unités plus grande que avant
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
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
29
30
5
Obtenir les besoins:
Le projet PaintBox
„
Le projet PaintBox :
Besoins
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?
„
„
„
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
31
32
Le projet PaintBox :
Étapes initiales de raffinement
„
„
„
„
„
„
Le projet PaintBox :
l`interface usager de base
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
File Edit
Select
Line
Oval
Rect
Color
Drawing Area
33
34
Le projet PaintBox:
Raffinement restant
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
35
„
„
L`implémentation au complet peut être téléchargé du site
web du livre
Voir section 10.4 du livre
36
6
Obtenir les besoins de
l`usager
„
„
Sommaire:
Chapitre 10
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!!!
37
„
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
38
7