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

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»

UtilisationDéveloppement

Maintenance

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

Utilisation etMaintenance

Développement

En exemple:Le bug de l`an 2000

6

Développement et Effort au Maintient

Développement Maintenance

Développement Maintenance

Une petite augmentation du temps de développement peutUne petite augmentation du temps de développement peutRéduire l`effort nécessaire à la maintenance Réduire l`effort nécessaire à la maintenance

Passez plus de temps à la conception, vérification et documentationPassez 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

L`approche écrire-et-modifier

Écrire leprogramme

Modifier leprogramme

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

Le modèle «Waterfall»

Établir les besoins

Créer un concept

Implémenter le concept

Vérifier le système

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

Processus du développement itératif:

Établir les besoins

Créer un concept

Implémenter le concept

Vérifier le système

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

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

Modèle dedéveloppement évolutionnaire

Établir les besoins

Concept architectura

l

Établir la portée

Vérification d`unité et intégration

Implémentation

Vérification de Système

Identifier les classes & objet

Identifier les relations

Concept détaillée

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

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

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)InvariantL`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 à jourpublic void advanceOneHour()

pré conditionhour < 12changehourpost conditionLa valeur de hour est unité plus grande que avant

30

Spécification du code:Un Exemple (AlarmClock class)Méthodes mise à jourpublic void advanceTenMinutes()

pré conditionminutes < 50changeminutespost conditionLa 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 OvalLine 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