CSI1502 Principes fondamentaux en conception des logiciels Chapter 10: Introduction au Génie Logiciel

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

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» Utilisation Développement Maintenance

Au sujet de la Maintenance 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

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

Développement et Effort au Maintient Développement Maintenance Développement 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érification et documentation

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

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

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

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.

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

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

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

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

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

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

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

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

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

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é

Développement de logiciel large: Une approche de. développement 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

Modèle de développement évolutionnaire Établir les besoins Concept architectural É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

Cycle d`amélioration: #1 Etablir 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

Cycle d`amélioration: #2 Identifier 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

Cycle d`amélioration: #3 Identifier 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

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

Cycle d`amélioration: #4-6 conception détaillé, implémentation Cycle d`amélioration: #4-6 conception 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

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é

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

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

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?

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

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

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

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

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

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

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