Genie Logiciel

download Genie Logiciel

of 202

description

Un cours sur Génie logiciel en extrait

Transcript of Genie Logiciel

  • Ecole dIngnieurs de lEtat de Vaud - 15 septembre 2006Eric LefranoisGnie Logiciel

  • ELS - 7 dcembre 2006 - Entete.fm

  • Gnie logiciel - i -

    Contenu

    1 EN PRLIMINAIRE 11.1 LES OBJECTIFS DU COURS 1

    1.2 PRINCIPALES RFRENCES BIBLIOGRAPHIQUES 2

    2 LA PROBLMATIQUE 5Les petits logiciels 6Les gros logiciels 7Quelques dfinitions cls 8

    2.1 LA CRISE DU LOGICIEL DES ANNES 70 9Panique bord du bateau logiciel 10Car le logiciel est une tche complexe.. 10Car lvolution est trop rapide.. 11Car au del des mythes, la ralit.. 11Naissance du gnie logiciel 13Dfinition du gnie logiciel 142.2 LES QUALITS REQUISES DUN LOGICIEL 14Qualits externes significatives 15

    Correction 15Fiabilit 15Robustesse 15Performance 15Ergonomie 15

    Qualits internes significatives 16Qualits du processus de dveloppement 16

    2.3 AUTOPSIE DE QUELQUES CATASTROPHES 171962: La perte de Mariner I (1) 17Mars Climate Orbiter ($125M) 17Autres checs retentissants 18

    3 MODLISATION 193.1 LA MODLISATION DUN SYSTME INFORMATIQUE 20

    3.2 DE LIMPORTANCE DE LA MODLISATION 21Les systmes orients donnes 21Les systmes orients traitements 21

  • Gnie logiciel - ii -

    Les systmes orients comportement 21Les principales approches 22

    Approche traditionnelle 22Approche Base de donnes 22Approche oriente objet 23

    Petit historique des modles utiliss 23Systmes orients donnes 23Systmes orients traitements 24Systmes orients comportement 24Modlisation Oriente Objet 24

    4 CYCLES DE VIE ET MTHODE UP 254.1 LES DIFFRENTES PHASES DU CYCLE DE VIE: ANALYSE ET CONCEPTION 26

    4.2 LE CYCLE DE VIE EN CASCADE (WATERFALL) 28

    4.3 LE CYCLE EN V ET LE MODLE EN SPIRALE 30

    4.4 LE MODLE INCRMENTAL ITRATIF 31

    4.5 MISE EN OEUVRE: LA MTHODE UP (PROCESSUS UNIFI) 33

    4.6 APPROCHE ORIENTE OBJET 33Analyse oriente objet 33Conception oriente objet 33Un exemple: le jeu de ds 34Dfinition des cas dutilisation 34Modlisation du domaine 35Dfinition des diagrammes dinteraction 35Dfinition des diagrammes de classe de conception 36

    Quelques mots sur UML 36

    4.7 CYCLE DE VIE DE LA MTHODE UP 38Initialisation (Inception) 39Elaboration 39Construction 39Transition 40

    Terminologie UP: disciplines, activits & artefacts 40Disciplines et phases UP 40

    5 PHASE DINITIALISATION 435.1 LES PRODUITS GNRS PAR LA PHASE DINITIALISATION 44

    5.2 A VITER PENDANT LA PHASE DINITIALISATION 46

    6 PHASE DLABORATION ET ANALYSE DES BESOINS 47Besoins fonctionnels et non-fonctionnels 49Les difficults rencontres lors de la spcification 51Quelques techniques utilises lors de la spcification 52Spcification formelle et informelle 52Spcification semi-formelle et UML 53

    7 MODLE DES CAS DUTILISATION 55

    7.1 SA PLACE DANS LA MTHODE UP 56

    Un dveloppement guid par les cas dutilisation 56Quand doit-on rdiger des cas dutilisation? 56

  • Gnie logiciel - iii -

    7.2 QUELQUES DFINITIONS PRALABLES 57Acteur 57Scnario 57Un cas dutilisation 57Un diagramme de cas dutilisation 58

    7.3 DESCRIPTION DUN CAS DUTILISATION 59La philosophie de la bote noire 59Rdaction dun cas dutilisation: quel niveau de dtail? 59Description dtaille dun cas dutilisation 60

    La prface 61La liste des parties prenantes et des intrts 61Prconditions et postconditions 61Le scnario principal (succs) 62Extensions: les scnarios alternatifs 62Spcifications particulires 63

    Prsentation: la variante Rebecca Wirfs-Brock 64

    7.4 DFINIR LE MODLE DES CAS DUTILISATION, DMARCHE GNRALE 65En prliminaire: quest-ce quun bon cas dutilisation? 66

    Cas dutilisation de base et sous-cas dutilisation 66La stratgie de lanalyste 67

    La dmarche 69Dlimiter les frontires du systme dvelopper 70

    Un diagramme de contexte 70Reprsentation des acteurs dans un diagramme de cas dutilisation 71

    Identifier les acteurs principaux et les acteurs auxiliaires 72Les acteurs principaux 73Les acteurs auxiliaires (ou acteurs secondaires) 73Les acteurs externes 73

    Identifier les cas dutilisation 74

    7.5 UML: RELATIONS ENTRE CAS DUTILISATION 74Relation include 74Relation genralise 76

    Reprsentation dun SOIT-SOIT 76En dehors du SOIT-SOIT 76La spcialisation sapplique galement aux acteurs ! 77Relation extends 79

    7.6 QUELQUES RECOMMANDATIONS 82Rdaction des tapes 82Oublier les interfaces utilisateurs 83

    7.7 LE NIVEAU DE DTAIL 84

    7.8 QUAND EST-CE QUE LON A TERMIN ? 85

    7.9 COMPLMENTS DE SPCIFICATIONS 85Le Glossaire (Glossary) 85La Vision (Vision) 85Les spcifications supplmentaires 85

    7.10 ANNEXE: PRSENTATION DTAILLE DU CAS DUTILISATION VENTE 868 MODLISATION DE DOMAINE 93La modlisation du monde rel 94Quen est-il des mondes irrels? 94Le Modle du domaine et la mthode UP 94

  • Gnie logiciel - iv -

    Le Modle du Domaine et UML 94

    8.1 CARACTRISTIQUES ESSENTIELLES DE LA MODLISATION DE DOMAINE 95Le modle du domaine est une abstraction 96Le modle du domaine est une reprsentations visuelle du monde rel 96

    8.2 CONSEILS 96

    8.3 HEURISTIQUE: COMMENT IDENTIFIER LES CLASSES CONCEPTUELLES 99Analyse linguistique 99Patterns danalyse 100Lexprience.. 100

    8.4 HEURISTIQUE: LISTE DES ASSOCIATIONS COURANTES 101

    8.5 ETUDE DE CAS, LE SYSTME POS 101

    9 XP & LES MTHODES AGILES 1039.1 UN PETIT HISTORIQUE 103

    9.2 QUELQUES PRINCIPES FONDAMENTAUX DU SOFTWARE MANIFESTO DE 2001105

    Individuals and interaction over processes and tools 105Working software over comprehensive documentation 106Responding to change over following a plan 106

    9.3 MTHODES AGILES: PRINCIPES CLEF 107

    9.4 SUR QUELS TYPES DE PROJETS UTILISER UNE MTHODE AGILE? 108

    9.5 UP EST-ELLE AGILE? 109Principes & fondements de UP en comparaison avec XP 110

    UP est pilot par les cas dutilisation 110Itratif et incrmental 111UP est centr sur larchitecture 111

    9.6 XP (EXTREME PROGRAMMING) 111

    9.7 VALEURS DE XP 113La communication pour une meilleure visibilit 113La simplicit comme garantie de productivit 113Le feedback pour rduire le risque 114Le courage de prendre les bonnes dcisions 114

    9.8 LES PRATIQUES ESSENTIELLES DE XP 114Les 12 pratiques de XP 115

    P1: Dveloppement pilot par les tests 115Tests de recette (tests fonctionnels) 115Tests de recette et spcifications XP 116Tests unitaires 116Rfrences 116P2: Le Planning game - Planification itrative 117User stories (scnarios) 118Stricte rpartition des tches 118Un jeu en 3 phases 119Stand-up meetings 120

    Vlocit, contrle de lefficacit et suivi du projet 120P3: Client sur le site 121P4: Programmation en binme 121P5: Intgration continue 122

  • Gnie logiciel - v -

    P6: Refactoring: remaniement de code 122P7: Courtes itrations de livraison 124P8: Conception simple 124P9: Utiliser la mtaphore 125P10: Responsabilit collective du code 125P11: Conventions de codage 125P12:Rythme durable: assurer le bien-tre des dveloppeurs 125

    9.9 XP: ORGANISATION DE LQUIPE DE DVELOPPEMENT 126Responsabilits des rles XP 126Le programmeur 127Droits du programmeur XP 127Le client 128Droits du client 128Le testeur 128Le tracker 129Le manager 129Le coach 129Combinaison des rles XP 130

    9.10 QUELQUES MTHODES AGILES 130

    9.11 RFRENCES SUR XP 130

    10 ANNEXE 1 - DIAGRAMMES DE CLASSES - UML 2.0 13110.1 OBJETS, ATTRIBUTS & CLASSES 131

    Reprsentation graphique 132Nom de la classe 133

    Attributs 133Visibilit de lattribut 133Le type dun attribut 133La proprit dun attribut 134La valeur par dfaut 134

    Oprations 135Visibilit dune opration 135Liste des paramtres 135Requtes et modificateurs 136Accesseurs et mutateurs 136La proprit dune opration 136

    10.2 CONCEPT D'ASSOCIATION 136Reprsentation graphique 137Rle des objets 137Multiplicit d'une association 138Convention pour le nom d'une association 139

    Navigabilit des associations 139Proprits des associations 141

    Classes dassociation 142Arit d'une association 142Associations ternaires 143

    Multiplicit des associations ternaires au sens Merise et UML 144Les relations ternaires sont rarement utilises 147

    Agrgations et compositions 149

    Retour sur la notion dattribut 150Retour sur la notion dassociation 150Les associations simples 150Les associations de type composition 151

  • Gnie logiciel - vi -

    Les agrgations 152Hirarchie Attribut > Composition > Agrgation > Association simple 153

    10.3 GNRALISATION - SPCIALISATION 154Reprsentation symbolique de la relation GEN-SPEC 155Un petit rappel: les notions de type 156La spcialisation et son principe, types et soustypes 156La rgle de substitution 157GEN-SPEC et hritage 158Reprsentation des classes abstraites 158

    10.4 LES CONTRAINTES 159

    11 ANNEXE 2 - DIAGRAMMES DACTIVITS 16111.1 NOTATION DE BASE 162

    11.2 PARTITION - COULOIRS DACTIVITS 164

    11.3 SIGNAUX 167

    12 ANNEXE 3 - DIAGRAMMES DE SQUENCE 16912.1 NOTATION DE BASE POUR DCRIRE UN SCNARIO 170

    12.2 OBJETS ACTIFS ET OBJETS PASSIFS 172

    12.3 OBJETS TEMPORAIRES 173

    12.4 MESSAGES SYNCHRONES ET ASYNCHRONES 174

    12.5 CONDITIONS ET ITRATIONS 176

    13 ANNEXE 4 - MVC & MODLE OBSERVATEUR 17913.1 EN PRLIMINAIRE: LES MODLES DE CONCEPTION 179

    13.2 LE MODLE MVC 180Le M comme Modle 183Le V comme Vue 183Couplage Vue-Modle: Le modle Observateur 185

    Le principe de sparation Modle-Vue 185Principe du modle Observateur 186Diagramme de classes 188Linterface Observateur 188La classe Observable 189Diagramme de squence 189

    C comme contrleur 189

    13.3 LE MODLE OBSERVATEUR 190API Java et le modle Observateur 190

    API Observer 191API Observable 191

    Le modles des listeners 192

    13.4 MVC ET LE PATTERN COUCHES 192

  • Support de cours - 1 - En prliminaire1 En prliminaireELS - 7 December 2006

    1.1 LES OBJECTIFS DU COURS

    Les objectifs du cours sont principalement les suivants:

    Acqurir la capacit de crer des logiciels correctement conus, robustes et main-tenables en utilisant des technologies objets avec des langages tels que C#, Java, C++, etc.

    Introduire ltudiant lanalyse et la conception objet, en basant le discours sur la notation UML, les modles de conception (patterns) et le processus unifi (UP- Unified Process). Laccent sera plac sur lapprentissage des concepts fonda-mentaux. Cela va donc bien au del dun simple apprentissage du langage UML, qui nest aprs tout quune simple notation.

    En particulier:

    Du point de vue de analyse: acqurir les connaissances permettant de mener bien ltape danalyse des besoins avec la spcification des cas dutilisation.

    Du point de vue de conception: connatre et savoir appliquer des modles de con-ception (design patterns) qui aideront tablir quelles responsabilits confier

  • Support de cours - 2 - En prliminairetel ou tel objet, tablir de quelle manire les objets vont intragir.

    Du point de vue de mthode: introduire ltudiant une mthode, une marche suivre, pouvant tre mise en oeuvre par une quipe de dveloppeurs dans le cadre de la ralisation dun logiciel. Il sagira notamment de la mthode dite processus unifi (UP - Unified Process), larchtype de la dmarche incrmentale itrative.Bien que cette mthode ne soit pas la panace et soit bien loin dtre reconnue comme la mthode, - dautres approches seront prsentes comme les mtho-des dites agiles dont la plus fameuse: XP (eXtrme Programming) -, elle cons-titue une rfrence et un cadre intressant pour introduire les concepts fondamentaux qui - une fois matriss - peuvent tre appliqus dans dautres dmarches.

    Remarquons que le fait dtre pass matre dans la manipulation dun marteau ne fait pas de nous un bon architecte: la connaissance et la pratique dun langage de pro-grammation ne suffit pas..

    En bref, les objectifs du cours peuvent tre rsums comme suit:

    appliquer des principes et des modles de conception pour crer de meilleures conceptions objet

    mener bien un certain nombre dactivits fondamentales comme lanalyse et la conception, dans le cadre dune dmarche base sur le processus unifi, pris titre dexemple.

    mettre en oeuvre les diagrammes de modlisation les plus courants en utilisant la notation UML

    1.2 PRINCIPALES RFRENCES BIBLIOGRAPHIQUESCe cours sappuie sur des ouvrages consacrs au Gnie Logiciel ou encore UML.

    Citons la source principale pour laquelle nous exprimons toute notre reconnaissance

    Craig Larman Applying UML and patterns - Second edition - Prentice Hall 2002 2nd Edition - Une version franaise existe depuis peu.

    Mais aussi:

    R. Martin; Agile Software Development, Principles, Patterns, and Practices. Prentice Hall 2002

    A. Cockburn; Writing Effective Use Cases. Addison Wesley, 2000 (ISBN: 0-201-70225-8).

    M. Fowler and K. Scott; UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison Wesley 2002, 2nd Edition.

    I. Jacobson, G. Booch, and J. Rumbaugh; Unified Software Development Pro-ELS - 7 December 2006

  • Support de cours - 3 - En prliminairecess. Addison Wesley 1999

    Ce cours sappuie galement sur dautres cours donnes dans diverses coles ding-nieurs:

    Cours Gnie Logiciel - Pierre Melier - HES-EIVD. Cours Gnie Logiciel - Michel Vinckenbosch - HES-EIG Cours Gnie Logiciel - Ecole Polytechnique de MontrealELS - 7 December 2006

  • Support de cours - 4 - En prliminaireELS - 7 December 2006

  • Support de cours - 5 - La problmatique2 La problmatiqueQuelques devinettes..ELS - 7 December 2006

    , Pour vous mettre sur la voie, voici une premire srie de devinettes. Y a-t-il une diffrence entre:

    Construire une cabane au fond du jardin; Construire le btiment de lEIVD?

    Quel projet cote le plus cher?

    Quel projet est le plus long raliser?

    Quel projet ncessite le plus de personnes pour sa ralisation?

    Dans quel projet la phase de construction est-elle proportionnellement la plus lon-gue (par rapport la dure complte du projet)?

  • Support de cours - 6 - La problmatiqueUne deuxime srie..

    Le btiment de lEIVD a t construit aux environs de 1975. cette poque, il corres-pondait aux besoins de lcole.

    Peut-on dire que ce btiment correspond encore nos besoins daujourdhui?

    Le btiment nest pas modulaire;

    Les normes de lpoque ne conviennent plus.

    La taille des btiments a une grande importance sur leur ralisation.Est-ce la mme chose en informatique?

    Cette petite introduction nous a permis de mettre en vidence limportance consi-drable que peut prendre la taille mme du logiciel dvelopper. Aussi, nous allons exa-miner de plus prs ce qui distingue un petit logiciel dun gros logiciel..

    Les petits logiciels

    Le cahier des charges est petit, facile comprendre et mme parfois transmis ora-lement.

    La conception du programme se fait souvent mentalement sans documentation.

    Le cot du logiciel est faible ou ngligeable.

    Le choix des technologies (systme dexploitation, environnement de dveloppe-ment, choix des machines, etc. ) est opr par le dveloppeur.

    Le dveloppement est ralis personne et dure peu de temps, parfois quelques semaines, au plus quelques mois, dailleurs aucune estimation pralable du temps de dveloppement nest faite le cas chant.

    Le logiciel est rarement document, son usage est facile.

    Le logiciel sera dploy une ou deux fois, par le dveloppeur lui-mme.

    La maintenance du logiciel cesse de facto lorsque le dveloppeur cesse de le sup-porter (dpart de la socit, changement daffectation, etc.). Cela entrane souvent la mort du logiciel.

    Toutes les conditions pour le succs du dveloppement sont donc runies!ELS - 7 December 2006

  • Support de cours - 7 - La problmatique Les gros logiciels

    Le cahier des charges est volumineux. Il est mme parfois: difficile comprendre; mal crit, le client na pas une ide trs claire du rsultat final, il y manque

    beaucoup dinformations; crit par des personnes qui ne connaissent pas grand chose linformati-

    que.

    En gnral les dveloppeurs ne connaissent pas ou peu le mtier o sapplique le logiciel.

    La conception du programme est un vrai casse-tte, pleine dembches, cause des incertitudes sur le cahier des charges et de la taille du programme raliser.

    Le cot du logiciel est norme.

    Le choix des technologies est prilleux: il faut tenir compte des besoins du client; la dure de vie des technologies doit tre plus grande que la dure de vie du

    logiciel; le choix des technologies peut entraner des dbats passionns, source de

    conflits.

    Le dveloppement se fait par une quipe, parfois assez grande, il peut durer des annes.

    Une estimation pralable du temps de dveloppement est importante pour pouvoir estimer les cots du logiciel.

    Lquipe de dveloppement devrait pouvoir respecter les dlais de dveloppe-ments estims, cest un dfi.

    Le logiciel doit tre parfaitement document. Cette documentation doit tre livre en mme temps que le logiciel, il faut donc dvelopper simultanment le logiciel et sa documentation.

    Le logiciel nest pas dploy par lquipe de dveloppement: il est peut-tre livr sur CD et diffus en grand nombre; il est peut-tre livr trs petite chelle, mais son installation est compli-

    que. Des personnes spcialement formes sont charges du dploiement.

    La maintenance du logiciel est gre par un contrat, renouvel souvent danne en anne. Le logiciel doit survivre lquipe de dveloppement

    / Toutes les conditions pour lchec du dveloppement sont runies.ELS - 7 December 2006

  • Support de cours - 8 - La problmatique, Posez-vous seulement la question.Dans quelle catgorie vous situez-vous lorsque vous dveloppez un projet informatique:

    dans le cadre scolaire?

    dans le cadre professionnel?

    " Maintenant, un petit exercice..Combien cote une ligne de code, sachant que:

    un bon dveloppeur cote Frs 200000.- par anne son entreprise tout frais com-pris;

    il code en moyenne 20 lignes par jour;

    il est absent en moyenne 1/5 du temps (vacances, arme, maladie, etc.);

    il y a environ 250 jours ouvrables par anne;

    Quelques dfinitions clsVoici quelques dfinitions cls du gnie logiciel, sur lesquelles nous reviendrons, mais quil est ncessaire dapprhender dors et dj afin de lire plus aisment ce qui va suivre dans le cadre de cette introduction sur le gnie logiciel.

    SpcificationActivit consistant dcrire formellement ou semi-formellement le fonctionne-ment dun systme. On doit rpondre aux questions: que doit faire le systme?, pourquoi?

    ConceptionActivit consistant rflchir, modliser et dcider comment le systme va tre implment. On doit rpondre la question: comment raliser le systme?

    ImplmentationActivit consistant coder le systme

    TestActivit consistant excuter le systme ou ses parties pour vrifier quil fonc-tionne correctement ou pour dcouvrir ses anomalies

    MaintenanceLe logiciel est en service chez le client. Cette activit comprend la correction derreurs dtectes par le client, mais aussi et surtout lajout de nouvelles fonc-tionnalits ou encore ladaptation, la modification de fonctionnalits existentes.ELS - 7 December 2006

  • Support de cours - 9 - La problmatique2.1 LA CRISE DU LOGICIEL DES ANNES 70Avec laccroissement de la complexit des logiciels (notamment de leur taille), le dve-loppement ne suit pas: il faudra 10 ans pour dvelopper l OS 360 des IBM 360

    Figure 1: Rapport du Congrs Amricain en 1979 sur 487 projets

    Figure 2: Un rapport amricain de 1994 - Standish Group International

    Les projets analyss ont tous utilis le modle en cascade (waterfall) que lon pr-sentera un peu plus loin dans le cours.

    53% des projets ont dpass le budget prvu initialement de 200% !

    Environ $81 milliards dpenss pour des projets abandonns aux USA en 1995

    Sources: US Gov. Accounting Report, (in B. Cox, OO Prog.)

    29%

    19%

    2% 3%

    47%

    Livr mais pas utilis

    Abandonn oureprisPay mais paslivrUtilis aprs correction

    Utilis tel que livr

    Sources: US Gov. Accounting Report, (in B. Cox, OO Prog.)

    29%

    19%

    2% 3%

    47%

    Livr mais pas utilis

    Abandonn oureprisPay mais paslivrUtilis aprs correction

    Utilis tel que livr

    Projet non termin

    30%

    Projet termin70% ELS - 7 December 2006

  • Support de cours - 10 - La problmatique Panique bord du bateau logiciel

    les logiciels raliss ne correspondent souvent pas aux besoins des utilisateurs;

    les logiciels contiennent trop d'erreurs (qualit du logiciel insuffisante);

    les cots du dveloppement sont rarement prvisibles et sont gnralement prohi-bitifs;

    la maintenance des logiciels est une tche complexe et coteuse;

    les dlais de ralisation sont gnralement dpasss;

    les logiciels sont rarement portables;

    les changements de besoin du client sont difficiles intgrer dans le dveloppe-ment;

    la performance du systme est souvent inacceptable;

    le systme est difficilement rutilisable pour de futurs dveloppements (ce qui permettrait de rpartir les cots de dveloppement sur plusieurs projets)

    Et pourquoi donc ?

    Car le logiciel est une tche complexe..Reconnaissons tout dabord que a nest pas une tche facile..

    Une quantit de facteurs influent de manire ngative.

    Taille et complexit du systme informatiser.

    Complexit attache l'environnement du systme.

    Complexit de communication entre les futurs utilisateurs (diversit des points de vue)

    Complexit de communication entre les futurs utilisateurs d'une part et les dve-loppeurs d'autre part (vocabulaire technique et non-technique)ELS - 7 December 2006

  • Support de cours - 11 - La problmatique Car lvolution est trop rapide..

    Figure 3: Evolution du matriel et du logiciel

    Figure 4: Evolution des langages et des outils

    Car au del des mythes, la ralit..

    Les mythes du ct usager

    Un nonc gnral des objectifs est suffisant. On verra pour les dtails plus tard !

    Traitement par lots

    Distribution limite

    Logiciel personnalis

    Multi-utilisateurs

    Temps-rel

    Bases de donnes

    Systmes distribus

    Systmes embarqus

    Le cot du matriel baisse

    Les usagers deviennentexigents

    Systmes personnels

    Orient-Objet

    Systmes experts

    Rseaux neuronnaux

    Calcul parallle

    Internet

    1950 1960 1970 1980 1990

    1re poque

    2me poque

    3me poque

    4me poque

    Epoque hroque

    0/1 (code machine)Assembleur

    Premiers langagesvolus aveccompilateurs

    Fortran, Cobol

    Puis structurs C, Pascal, Modula-2 Ada

    Langages orients objet

    Smalltalk, C++Java

    Outils CASE pour ledveloppement intgr

    Normes de conceptionUML, CORBA

    Frameworks dedveloppementWEB (Struts, Cocoon, EJB, ..)Persistance (Hibernatus)

    1960 1970 1980 1990 2000

    1re gnration

    2me gnration

    3me gnration

    4me gnrationELS - 7 December 2006

  • Support de cours - 12 - La problmatique/ La ralit: Une dfinition insuffisante des besoins des usagers est une cause majeure de production dun logiciel de mauvaise qualit

    Les besoins du projet changent, mais on incorporera les modifications facilement parce que le logiciel est flexible !

    / La ralit: Les cots pour un changement du logiciel augmentent de manire dra-matique dans les dernires phases du dveloppement.

    Figure 5: Le cot du changement

    Les mythes du ct dveloppeur

    Une fois que le programme est crit et quil fonctionne, le travail du dveloppeur est termin !

    / La ralit: 50% 70% de leffort consacr un programme se produit aprs la livraison lusager.

    / Tant quun programme ne fonctionne pas, il ny a pas moyen den mesurer la qua-lit !

    La ralit: les revues de logiciel peuvent tre plus efficaces pour dtecter les erreurs que les jeux de tests.

    Dfinition Dveloppement Maintenance

    1X

    1.5 - 6X

    60 - 100X

    CotELS - 7 December 2006

  • Support de cours - 13 - La problmatique Le succs dun projet tient essentiellement de la livraison dun programme fonc-tionnel !

    / La ralit: Une configuration logicielle inclut toute la documentation, des don-nes dentre pour les tests, etc

    Les mythes du ct gestionnaire

    Lentreprise possde des normes, le logiciel dvelopp devrait tre satisfaisant !/ La ralit: les standards sont-ils utiliss, appropris et complets?

    Les ordinateurs et les outils logiciels que lentreprise possde sont suffisants/ La ralit: il faut plus que des outils pour raliser du logiciel de qualit. Il faut aussi une bonne pratique.

    Si le projet prend du retard, il suffira dajouter quelques programmeurs./ La ralit: Le dveloppement du logiciel nest pas une activit mcanique. Ajou-ter des programmeurs peut empirer la situation

    Naissance du gnie logiciel

    7 au 11 octobre 1968, confrence Garmish-Partenkirchen (sponsorise par lOTAN)Le terme de software engineering est utilis pour la premire fois par les pro-fesseurs Bauer et Bolliet, dans un rapport de la confrence scientifique.

    La traduction franaise gnie logiciel est plus tardive.

    Le langage Ada est une consquence directe de cette crise. Cest la rponse de Dpartement de la Dfense amricaine ce problme.

    Puis arrivent les premires mthodes: VDM (Vienna Development Method) date du dbut des annes 70, le langage Z (Spcification formelle - Abrial) date de 1978.ELS - 7 December 2006

  • Support de cours - 14 - La problmatique Dfinition du gnie logiciel

    Dfinition 1: Le gnie logiciel

    Discipline dingnierie concerne par le problme pratique du dveloppement de grands systmes logiciels.Sommerville Ian Le gnie logiciel, Addison-Wesley France, 1992

    Cette premire dfinition met en avant la problmatique lie la taille du projet. La deuxime est un peu plus prcise quant aux objectifs de cette discipline.

    Dfinition 2: Le gnie logiciel

    Discipline pour spcifier, construire, distribuer et maintenir des logiciels, en assurant:

    la qualit (fiables, adapts, conviviaux, volutifs)

    des cots contrls

    des dlais garantis

    2.2 LES QUALITS REQUISES DUN LOGICIELLa crise des annes 70 nous, telle que nous lavons dcrite, nous permet de prciser dans ses grandes lignes les objectifs du gnie logiciel (reprise de la deuxime dfinition du g-nie logiciel).

    Dfinition 3: OBJECTIFS DU GNIE LOGICIEL

    Donner les moyens ncessaires lquipe de dveloppement pour que le systme ralis:

    respecte les cots et les dlais de dveloppement;

    soit un produit de qualit.

    Dans cette dfinition, le mot-cl qualit - mot magique -, mrite lui seul tout un dveloppement..

    On peut aborder le critre qualit selon 3 points de vue: la qualit externe (point de vue de lutilisateur) la qualit interne (point de vue du dveloppement)ELS - 7 December 2006

  • Support de cours - 15 - La problmatique la qualit du processus de dveloppement

    Remarquons demble quil y a une grande interdpendance entre ces trois points de vue.

    2.2.1 Qualits externes significativesLa correction, la fiabilit et la robustesse sadressent laspect fonctionnel du logiciel fourni au client.

    CorrectionUn logiciel correct satisfait sa spcification (fonction attendue) de manire absolue.

    FiabilitLa fiabilit est une notion relative lide que sen fait lutilisateur mme du logiciel.

    La fiabilit mesure le degr de confiance que lon peut avoir dans le fonctionnement du logiciel. Il marche aujourdhui, marchera-til demain ? Peut-on compter sur ce produit ?

    RobustesseLa robustesse dnote une aptitude fonctionner correctement sous des conditions anor-males, comme par exemple:

    Dans les cas non spcifis par l'analyse des besoins:

    Ressource non disponible fichier non-existant , etc. Valeur inattendue, p.ex: division par zro, date= 29/2/2002

    A loccasion de pannes du rseau ou de machines

    serveur ne rpond pas , etc.

    Le systme doit alors pouvoir sadapter et continuer de fonctionner.

    Performance

    Qualit lie lalgorithmique (complexit polynomiale, exponentielle) .

    Evaluation par mesure, analyse et simulation.

    Ergonomie

    Qualit lie la facilit dutilisation.ELS - 7 December 2006

  • Support de cours - 16 - La problmatique Se rattache principalement linterface utilisateur mais dpend aussi de la perfor-mance et de la correction.

    2.2.2 Qualits internes significatives

    Maintenabilit (~60% du cot) maintenance corrective: pour liminer les erreurs maintenance adaptative: changement dans lenvironnement maintenance perfective: changement pour amliorer ses qualits

    RparabilitFacilit avec laquelle le logiciel peut s'adapter des corrections.Ncessite une bonne structure modulaire avec de bons interfaces, un langage ad-quat.

    EvolutivitFacilit avec laquelle le logiciel peut s'adapter des changements de spcifica-tion.

    RutilisationA priori ou posteriori.Lide tant de dvelopper une tagre de composants.

    PortabilitLe produit est indpendant du genre denvironnement

    InteroprabilitCapacit intragir avec dautres systmes; qualit rare pour le logiciel mais cou-rante dans dautres domaines; qualit vise par les dmarches de normalisation

    2.2.3 Qualits du processus de dveloppement

    Productivit et rutilisation

    Respect des dlais

    Echange dinformationsBonne documentation, accessible tousELS - 7 December 2006

  • Support de cours - 17 - La problmatique2.3 AUTOPSIE DE QUELQUES CATASTROPHES

    1962: La perte de Mariner I (1)

    Pour quelques lignes de FORTRAN:

    DO 5 K = 1. 3T(K) = W0Z = 1.0/(X**2)*B1**2+3.0977E-4*B0**2D(K) = 3.076E-2*2.0*(1.0/X*B0*B1+3.0977E-4*

    *(B0**2-X*B0*B1))/ZE(K) = H**2*93.2943*W0/SIN(W0)*ZH = D(K)-E(K)

    5 CONTINUE

    La premire ligne est fausse, elle aurait d scrire

    DO 5 K = 1, 3 Boucle avec K variant de 1 3

    Au lieu de cela, le compilateur FORTRAN a compris

    DO 5K = 1.3 Boucle parcourue 1 fois avec K valant 1.3 Ainsi, la perte de Mariner est due une erreur de programmation lmentaire.

    Cette erreur a mis en vidence la faiblesse de la syntaxe du langage FORTRAN

    Trop grande proximit entre laffectation est linstruction de boucle; Difficult de lecture du programme.

    Le code fautif navait pas t test correctement.

    Mars Climate Orbiter ($125M)Le 23 septembre 1999 11h27, la NASA perd tout contact avec la sonde spatiale Mars Climate Orbiter. La sonde sest dsintgre dans latmosphre de Mars en essayant de se mettre en orbite une hauteur de 53 km au lieu des 193 km qui taient planifis.

    Lorigine de la panne est une erreur parfaitement stupide:

    Lockheed Martin Astronautics a utilis les mesures anglo-saxonnes;

    Jet Propulsion Laboratory a utilis le systme mtrique;

    Personne na converti les donnes changes (1 livre = 4.48 Newton).

    Erreur dans les processus de validation de la NASARapport de la NASA (2000)

    Lerreur de navigation na pas t dtecte par la simulation informatique de la ELS - 7 December 2006

  • Support de cours - 18 - La problmatiquepropulsion.

    Lquipe oprationnelle de navigation ntait pas assez informe de la manire dont la sonde tait oriente dans lespace.

    Une dernire mise feu des moteurs avant larrive de la sonde pour rorienter la sonde a t envisage, mais pas ralise pour diverses raisons.

    Le processus de validation des tches interconnectes ntait pas assez robuste cause dun changement de stratgie de la NASA dans sa manire de raliser les nouveaux projets.

    Certains canaux dinformation entre groupes dingnieurs taient trop informels.

    La petite quipe des missions de navigation tait surcharge de demandes et na pu tre value temps par un groupe dexperts.

    Le personnel ntait pas assez entran remplir les formulaires formels dano-malies.

    Le processus de vrification et de validation des interfaces techniques entre les groupes tait inadquat.

    Autres checs retentissants

    En 1972, lors d'une exprience mtorologique en France, 72 ballons contenant des instruments de mesure furent dtruits cause d'un dfaut dans le logiciel.

    En 1981, le premier lancement de la navette spatiale a t retard de deux jours cause d'un problme logiciel. La navette a d'ailleurs t lance sans que l'on ait localis exactement le problme (mais les symptmes taient bien dlimits).

    Le dveloppement du compilateur PL1 de Control Data n'a jamais abouti.

    L'explosion de la fuse Ariane 5, le 4 juin 1996, qui a cot un demi milliard de dollars (non assur!), est due une faute logicielle d'un composant dont le fonc-tionnement n'tait pas indispensable durant le vol.ELS - 7 December 2006

  • Gnie logiciel - 19 - Modlisation3 ModlisationLe dveloppement de logiciels est une entreprise complexe. Notre mmoire court terme tant fortement limite, nous prouvons le besoin naturel de modliser pour simplifier et ELS - 7 December 2006

    augmenter ainsi artificiellement notre capacit intellectuelle rsoudre les problmes.

    Dfinition 4: les modles

    Les modles sont des abstractions de la ralit. Ce sont des reprsentations de la ralit qui nen gardent que lessentiel, jetant le superflu qui ne fait quencombrer lesprit.

    Un modle est une synthse (ne garde que lessentiel); il sera donc souvent volon-tairement simplifi;

    Un modle a toujours un objectif prcis, celui de montrer un aspect particulier dun problme donn. Plusieurs modles sont donc ncessaires pour reprsenter la totalit du systme.

    Indirectement, la mise en oeuvre de modles prsente encore de nombreux avantages non dnus dintrt:

    Un modle est un outil de communicationOutil de communication entre analystes, entre analystes et concepteurs, etc., un modle peut galement tre utilis pour communiquer avec les utilisateurs du sys-

  • Gnie logiciel - 20 - Modlisationtme (les clients), sous rserve que ces derniers soient des clients avertis et sus-ceptibles de le comprendre: un prototype est souvent plus indiqu.

    * Soulignons quun modle, pour tre un outil valable de communication, doit alors sappuyer sur une smantique indpendante du temps et des personnes. En dautres ter-mes, il doit sagir dun modle normalis (comme peut ltre UML).

    Un modle est un outil de documentation

    La ralisation dun modle obissant une norme de type UML gnre par la mme occasion une documentation structure, et ceci automatiquement, sans aucun effort (Ouf!).

    Cette documentation sera utilise pendant la maintenance du systme, voire pen-dant la phase de test.

    3.1 LA MODLISATION DUN SYSTME INFORMATIQUEUn seul modle ne suffira pas pour dcrire tout un systme informatique. Un systme peut tre apprhend suivant diffrents points de vue et notamment:

    le point de vue des donnes et de leur structuration, le point de vue des traitements et le point de vue dynamique.

    Diffrentes approches sont donc ncessaires pour assurer la bonne comprhension dun systme. Le langage UML, par exemple [Voir paragraphe - Quelques mots sur UML - page 36], prvoit ainsi plusieurs types de modles qui permettent chacun dclairer ou tout du moins de mettre laccent sur un certain aspect du systme.

    Fondamentalement, on peut citer trois grands types de modles:

    1. Le modle fonctionnelQui indique les traitement accomplis.P.E: diagrammes de flux de donnes, diagrammes dactivits (UML)

    2. Le modle comportementalQui indique quand et quelle occasion ces traitements sont accomplis.P.E: diagrammes dtats et de transition (UML)

    3. Le modle des donnesQui indique ce sur quoi ces traitements agissent.P.E: diagrammes de classes (UML), diagrammes ER (Entit-Relation)ELS - 7 December 2006

  • Gnie logiciel - 21 - Modlisation3.2 DE LIMPORTANCE DE LA MODLISATIONSi lapproche Objet nous semble aujourdhui naturelle, il nen a pas toujours t ainsi. Un petit retour en arrire peut tre instructif plus dun titre.

    Dun point de vue historique, remarquons que lon distingue en gnral 3 types de syst-mes, suivant quils sapparentent plutt aux donnes, aux traitements ou encore la ges-tion des vnements.

    Les systmes orients donnesCes systmes sappuient sur des structures dinformation complexes et fortement dpen-dantes.

    Il peut sagir par exemple de la base de donnes du services des eaux de la ville de Lau-sanne, du service de rservation dune compagnie daviation, etc.

    Les systmes orients traitementsCes derniers reposent essentiellement sur la mise en oeuvre de traitements complexes.

    Le dveloppement de tels systmes est une entreprise dlicate en raison de la complexit des algorithmes mis en jeu. Par contre ils ne prsentent pas vraiment de difficult du stricte point de vue du Gnie Logiciel.

    Preuve en est quils sont souvent loeuvre de scientifiques dont le background informati-que a t dans bien des cas appris sur le tas - ce qui nenlve rien la qualit du pro-duit -.

    Citons titre dexemple les logiciels de traitement de signal, de simulation discrte (files dattente), lintelligence artificielle, etc.

    Les systmes orients comportementCes systmes ragissent principalement aux vnements externes auxquels il doivent ap-porter une rponse adquate tenant compte de ltat interne du systmes.

    Citons par exemple:

    les systmes embarqus,

    les automates tats finis,

    les interfaces Homme-Machine, etc.

    Ainsi, historiquement, le monde informatique sest quelque peu cloisonn pour donner naissance diffrentes approches.ELS - 7 December 2006

  • Gnie logiciel - 22 - Modlisation3.2.1 Les principales approchesA lorigine, deux approches se sont dveloppes en parallle, adaptes chacune au monde informatique qui leur avait donn naissance. Il sagit de lapproche dite traditionnelle ou encore procdurale et de lapproche des bases de donnes.

    Quelque part, on peut considrer que lapproche objet a rconcili les deux mondes.

    Approche traditionnelleSappuie sur deux principes fondamentaux:

    les donnes font partie de l'application; il existe un lien trs troit entre les donnes et les applications.

    Quand on veut changer les donnes, il faut aussi changer les applications (et vice versa).

    Lapproche est essentiellement top-down (dcomposition fonctionnelle) et sappuie sur les langages procduraux comme Pascal ou issus de Pascal.

    Approche Base de donnesDans le monde des bases de donnes, on sappuie galement sur deux principes:

    Avoir la possibilit de modifier la structure des donnes sans changer les pro-grammes de l'application.

    Avoir la possibilit de modifier les programmes de l'application sans changer la structure des donnes.

    Dans ce contetxe, l'indpendance des donnes est donc un facteur primordial!

    Ds que l'importance de l'indpendance des donnes a t reconnue, on a t amen faire beaucoup plus attention la conception des donnes (d'o lapproche modlisation par les donnes).

    Systme de gestion de

    base de donnes

    Base de donnesFacturation

    Administration du systme

    Service l aclientleELS - 7 December 2006

  • Gnie logiciel - 23 - Modlisation Approche oriente objetCette approche est venue du besoin de:

    Construire des modles plus proches du monde rel. Rutiliser des fragments de logiciels.

    Elle sappuie sur la nouvelle gnration de langages qui apparaissent la fin des annes 1970 qui permettent l'encapsulation des donnes et des traitements dans un objet: ADA (1979), Simula et Smalltalk (1980) puis C++.

    Selon cette approche, un objet peut tre caractris par trois attributs: donnes, fonc-tions et comportement. Ca nest donc pas incompatible avec les deux approches prsen-tes plus haut, et tous les modles utiliss dans ces dernires sont utilisables en objet (et sont dailleurs utiliss partiellement).

    Mais a n'est pas une approche top-down - ni linverse dailleurs! -.

    Le top-down est un bon moyen de reprsenter des choses que l'on matrise bien. .. Mais le top-down n'est pas un bon moyen pour dvelopper, concevoir ou dcouvrir.

    Voici quelques applications susceptibles de bnficier de ces techniques:

    Domaine des grands logiciels Tlcommunications Contrle de processus industriels Traitements rpartis Systmes temps rel ( venir..)

    3.2.2 Petit historique des modles utilissLe modle tait trs attach au type de systme dvelopper.

    Systmes orients donnes

    Diagrammes Entits-Relations (ER) - Chen, Palmer, Mac Donald (1976-78) Pour lanalyse Approche plat Focalise sur les proprits statiques des donnes

    Formes Normales (FN) - Codd Pour la conception Conception focalise sur la non redondance des informationsELS - 7 December 2006

  • Gnie logiciel - 24 - Modlisation Systmes orients traitements

    Diagrammes de Flux de Donnes (DFD) - De Marco, Yourdon (1982-83) Pour lanalyse Approche top-down Focalise sur les aspects fonctionnels

    Diagrammes de Structure - Myers, Constantine, Yourdon (1974) Pour la conception Approche top-down Focalise sur les modules Sappuie sur les Diagrammes de Flux de Donnes (DFD)

    Systmes orients comportementConcernant les systmes orients comportement, la conception tait trs fortement dpen-dante du langage et des outils utiliss.

    Diagrammes de Flux de Contrle (DFC) - Ward-Mellor, Hatley-Pirbai (1985, 87)Une analyse focalise sur l'aspect comportemental

    Modlisation Oriente Objet

    Technique de Modlisation Objets (OMT) - Rumbaugh (1992)

    Analyse et Conception Oriente Objets (OOAD) - Booch( 1980-93)

    Diagrammes Entits-Actions (JSD Entity-Actions) - Jackson (1983)

    Analyse Oriente Objets et Conception Oriente Objets (OOA/OOD) - Shlaer-Mel-lor (1987-91)

    Analyse Oriente Objets et Conception Oriente Objets (OOA/OOD) - Coad-You-don (1991)

    Classe & Relation - Desfray (1993)

    UML (1997 - version 1)

    UP (2001)ELS - 7 December 2006

  • Gnie logiciel - 25 - Cycles de vie et mthode UP4 Cycles de vie et mthode UPELS - 7 December 2006

    Comme nous lavons mentionn dans les prliminaires du cours, nous nous atta-cherons dcrire une mthode de dveloppement particulire, base sur la technologie Ob jet et sur UML, qui porte le nom de mthode UP (comme Unified Process). Cette mthode dcrit essentiellement la marche suivre loccasion de la ralisation dun logi-ciel. De manire plus gnrale, plutt que de parler de marche suivre, on parle plutt de cycle de vi, un concept qui donne le nom de ce chapitre.

    La mthode UP nest pas unique en son genre, mais elle a toutefois le mrite de bien poser certains concepts cl. Nous aurons galement loccasion de prsenter une autre mthode concurrente mais qui sen rapproche: leXtrme Programming, qui sappuie galement sur la modlisation objet.

    A la base de la mthode UP, un concept cl: le dveloppement itratif, une appro-che qui dcoupe le dveloppement en une srie de mini-projets que lon appelle itrations.

    Dfinition 5: Itration

    Chaque itration aboutit un systme excutable et test.

  • Gnie logiciel - 26 - Cycles de vie et mthode UP Chaque itration comprend sa propre phase danalyse des besoins, de conception, dimplmentation et de test.

    Figure 6: Dveloppement incrmental itratif

    Du point de vue strictement historique, le concept mme de dveloppement itratif incr-mental est laboutissement dun concept qui portait lorigine le nom de processus en spirale (spiral development) ou encore processus volutif (evolutionary process).

    A titre dexemple, mi-chemin du dveloppement dun projet, une itration de deux semaines pourrait se dcomposer ainsi:

    le lundi consacr la clarification et la distribution des tches dans le groupe, pendant quune personne effectue le reverse-enginnering de litration prcdente (gnration de diagrammes UML)

    le mardi consacr la conception de diagrammes UML grossiers, conus et dessi-ns au tableau en travaillant en binme et enregistrs au moyen dune camra numrique, lcriture de fragments de pseudo-code, etc.

    les 8 derniers jours consacrs limplmentation et le test dunits et dintgra-tion dans le systme, mais aussi dautres activits comme par exemple des dmonstrations aux diffrents partenaires ou encore la planification des prochai-nes itrations.

    Le modle du dveloppement itratif incrmental prsente de nombreux avantages. Pour les apprcier leur juste valeur, nous allons revenir en arrire en prsentant la notion de cycle de vie et les diffrents modles sur lesquels le gnie logiciel sest appuy depuis les annes 70.

    4.1 LES DIFFRENTES PHASES DU CYCLE DE VIE: ANALYSE ET

    Conception

    Analyse des besoins

    Implmentation& test

    Intgration& test du systme

    Systmeexcutable

    Conception

    Analyse des besoins

    Implmentation& test

    Intgration& test du systme

    Systmeexcutable

    Itration i-1 Itration i

    Conception

    Analyse des besoins

    Implmentation& test

    Intgration& test du systme

    Systmeexcutable

    Itration i+1ELS - 7 December 2006

  • Gnie logiciel - 27 - Cycles de vie et mthode UPCONCEPTION

    Dfinition 6: Cycle de vie

    Le cycle de vie du logiciel modlise lenchanement des diffrentes activits du processus technique de dveloppement du logiciel. Tous les modles diffrencient 3 grandes activi-ts qui vont, selon le modle, intragir diffremment. Ce sont:

    1. Lanalyse: comprendre le problme, les besoins2. La conception: trouver une architecture pour rsoudre le problme3. La ralisation: mettre en oeuvre, fabriquer

    Ces 3 activits ne sont pas la caractristique des dveloppements informatiques. Par exemple, pour fabriquer un modle mcanique du systme solaire il faut:

    1. analyser le problme en observant que les plantes suivent des orbites;2. concevoir en inventant un mcanisme qui dplace des sphres sur de telles orbites;3. puis raliser lassemblage des sphres, ressorts et engrenages.

    Toute mthode - et en particulier la mthode UP - propose une dmarche et des notations pour aborder ces problmes.

    La dmarche (le cycle de vie) dcrit quelles tapes lmentaires doivent tre suivies, quelles questions doivent tre souleves et quel moment, quels sont les objets qui doivent tre mis en vidence, etc.

    La notation permet de prsenter et formaliser des objets solution aux informaticiens et aux clients; il est donc souhaitable - voire indispensable- quune notation soit compr-hensible par des non-spcialistes.

    Analyse et conceptionRevenons encore un peu sur lanalyse et la conception..

    Dfinition 7: Analyse: le QUOI

    Lanalyse est une activit qui sattache en premier lieu mener une investigation sur le problme et les besoins, plutt qu rechercher une solution.En gros, il sagit de rpondre la question: Quest-ce quon dsire et comment ce sera utilis?Le terme analyse est un peu flou. On lui prfre souvent les termes analyse des besoins ou encore analyse des objets (recherche mene sur les objets du domaine).ELS - 7 December 2006

  • Gnie logiciel - 28 - Cycles de vie et mthode UPDfinition 8: Conception: le COMMENT

    La conception est une activit qui sattache en premier lieu dfinir une solution con-ceptuelle susceptible de rpondre aux besoins issus de lanalyse plutt qu dfinir une implmentation du problme.Notamment, il sagira par exemple de dfinir le schma conceptuel de la base de donnes et larchitecture des classes (au moyen dun diagramme UML).Encore une fois, le terme conception manque de prcision. On lui prfrera souvent conception objet ou encore conception de la base de donnes.

    En rsumDo the right thing (analysis), and do the thing right (conception)

    4.2 LE CYCLE DE VIE EN CASCADE (WATERFALL)Ce modle est similaire ce qui ce fait en architecture et construction des btiments, il est d Royce (1970).

    Chaque tape du processus de dveloppement doit tre termine une date prcise avant que la suivante ne puisse dbuter. En principe, chaque tape doit tre contrle et vaide avant de passer ltape suivante.

    Des remous.. On admet toutefois - le dveloppeur nest quun tre humain avec beaucoup de faiblesses ELS - 7 December 2006

  • Gnie logiciel - 29 - Cycles de vie et mthode UP-, que la ralisation dune tape oblige les dveloppeurs revenir sur ltape prcdente pour y apporter des corrections, ce qui peut provoquer certains remous.

    Chaque tape produit un rsultat: il peut sagir dune documentation, de formulaires, et bien entendu de bouts de programme.

    Figure 7: Le cycle de vie en cascade

    Ce modle a le mrite dtre trs simple. Les dveloppeurs se sont inspirs des autres domaines de lingnierie; il fallait bien commencer par quelque chose de connu..

    Les avantages Il prsente un dveloppement trs linaire bien que des retours en arrire soient prvus lorsque des erreurs ou des manques sont dtects.

    Il permet de planifier aisment le dveloppement.Par contre/ Ce modle permet difficilement de grer les changements en cours de projets.

    En effet, de tels changements impliquent des retours en arrire qui peuvent aller parfois jusqu revoir la phase de spcification. Un erreur cotera dautant plus cher quelle sera dcouverte tardivement.

    Spcification: document le plus formalis possible

    Architecture du systme& Conception dtaille: modules et interactions

    Code du logiciel (1re version)

    1re version livrable

    Livraison et installation

    Mises jour ultrieuresELS - 7 December 2006

  • Gnie logiciel - 30 - Cycles de vie et mthode UPMais surtout/ Dans ce modle, la phase danalyse des besoins a une importance primordiale! Lapproche est monumentale, il faut laborer des plans complets avant de commencer construire. Ainsi, le client ne voit le systme ralis qu la fin pour se rendre compte un peu tard que le produit ne correspondait pas ses besoins..

    4.3 LE CYCLE EN V ET LE MODLE EN SPIRALE

    Figure 8: Le diagramme en V

    Sans entrer dans les dtails, le cycle en V puis le modle en spirale correspondent des volutions du modle en cascade.

    Le cycle en V introduit les notions de dcoupage modulaire et de validation - que lon distingue trs nettement de la notion de vrification -.

    Dfinition 9: Validation et Vrification (Boehm 76)

    Validation: Am I building the right system?

    Vrification: Am I building the system right?

    En 1988, K. Boehm propose une amlioration du modle en cascade, dans laquelle la gestion des risques fait partie du modle, en cherchant minimiser les risques encourus et en les analysant rgulirement. Il sagit du modle en spirale.

    Spcification

    Codage Vrification

    Intgration

    ValidationBesoins

    Spec.

    Arch.

    Code DocDoc

    ActivitActivit

    Mod.

    Soft

    Pro.

    ConceptionConceptionELS - 7 December 2006

  • Gnie logiciel - 31 - Cycles de vie et mthode UPDfinition 10: Gestion des risques

    Par gestion des risques, on entend placer la priorit sur lanalyse et le dveloppement des lments dont le dveloppement prsente des risques importants, comme par exemple:

    le client nest pas trs au clair avec sa demande, lquipe na pas dexprience sur ce type de dveloppement, la technologie utiliser est inconnue et peut rserver de mauvaises surprises, etc.

    Le modle en spirale implique frquemment le client/utilisateur. Il reprsente le dve-loppement comme une succession de cycles en cascade, o, chaque itration le systme est analys, conu, ralis et test un peu plus qu litration prcdente.

    Figure 9: Le cycle en spirale

    / Mais, tout comme avec le modle Waterfall et le modle en V, le client ne voit le systme ralis qu la fin!

    4.4 LE MODLE INCRMENTAL ITRATIFCe modle, prsent en dbut de chapitre, constitue laboutissement du modle en spirale.

    Il est aujourdhui utilis par les mthodes dites agiles ou semi-agiles: UP (Unified Process);ELS - 7 December 2006

  • Gnie logiciel - 32 - Cycles de vie et mthode UP XP (Extreme Programming).

    Figure 10: Le modle incrmental itratif

    A la diffrence du modle en spirale

    Chaque incrment donne lieu un produit fini, excutable, test et intgr.

    On cherche garder chaque incrment taille humaine, en limitant le temps de ralisation et en limitant le nombre de fonctionnalits implmentes.

    Les avantages par rapport au modle en spirale

    Le client peut valider en tout temps le systme, il peut influencer son dveloppe-ment dans le bon sens.

    Le systme correspond mieux aux besoins du client.

    Exprience souhaite..

    * Au dpart, il faut tablit une vision de haut niveau qui permet destimer les cots et les temps de dveloppement, cette opration demande beaucoup dexprience.

    Le dveloppement en cascade est-il enterr? Si lquippe de dveloppement bnficie dune grande exprience dans le

    domaine et si le travail ne prsente par ailleurs aucun risque (comme par exemple si le client sait trs bien ce quil veut), le modle itratif incrmental demande plus de travail que le modle en cascade. Cest ainsi que pour des raisons deffica-cit, il est encore possible de partir sur un modle en cascade.

    Notons par ailleurs quil faut encore souvent convaincre le client que ce modle de dveloppement est meilleur que le modle en cascade.

    Planification initialeVision

    Planification

    Spcification Conc

    eptio

    n

    Implm

    entation

    Test

    valuat

    ion

    DploiementELS - 7 December 2006

  • Gnie logiciel - 33 - Cycles de vie et mthode UP4.5 MISE EN OEUVRE: LA MTHODE UP (PROCESSUS UNIFI)UP sappuie essentiellement sur deux principes: un dveloppement incrmental itratif et lutilisation de technologies objet, que ce soit pour lanalyse, la conception et la program-mation.

    Voici quelques unes des caractristiques remarquables de cette mthode, qui tiennent essentiellement au dveloppement itratif:

    Prise en compte quasi immdiate des lments risques. Implication permanente des utilisateurs (valuation, test) en utilisant la pratique

    des demandes de changement. Mise en oeuvre dune architecture centrale ds les premires itrations. Technologie Objet et modlisation graphique (UML). Contrle de qualit permanent: tests prcoces et frquents.

    4.6 APPROCHE ORIENTE OBJETRappelons que cette approche est venue du besoin de construire des modles plus pro-ches du monde rel et de la notion de rutilisation ([Voir paragraphe - Les principales approches - page 22]).Nous dirons ici quelques mots au sujet de lanalyse et de la conception, vues sous langle de lapproche objet.

    Analyse oriente objetLanalyse oriente objet met laccent sur la recherche et la description des objets ou de con-cepts qui appartiennent au domaine du problme.

    Comme par exemple Livre et Client dans un systme de gestion dune bibliothque.

    Figure 11: Modlisation relation Livre-Client

    Conception oriente objetLa conception oriente objet met laccent sur la recherche et la dfinition des objets logiciels(tels quils seront implments) et sur la manire dont ces derniers vont collaborer.

    Par exemple, lobjet logiciel Emprunt aura lattribut dateEmprunt et la mthode prolonger.

    LivreTitreNbExemplaires

    ClientNomAdresse

    emprunt par0..*0..*

    dateELS - 7 December 2006

  • Gnie logiciel - 34 - Cycles de vie et mthode UPFigure 12: Modlisation conceptuelle Livre-Emprunt-Client

    Un exemple: le jeu de ds

    Le jeu est le suivant: les ds sont rouls. Si le total fait 7 on a gagn, sinon on a perdu !

    Pour illustrer le processus de cration dun logiciel, nous allons dcomposer le dvelop-pement en 4 tapes, les deux premires appartenant une activit danalyse, et les deux dernires une activit de conception:

    Dfinition des cas dutilisationLa dfinition des cas dutilisation intervient pendant lanalyse des besoins.

    Livretitre: String nbExemplaires: int

    Clientnom: Stringadresse: Address

    Empruntdate: Date0..* 0..*

    11

    class Client { private String nom; private String adresse;

    public String getNom() {return "";}}

    getNom(): String

    prolonger()

    Dfinition desdiagrammes de

    classes

    Dfinition desdiagrammesd'interaction

    Modlisation dudomaine

    Dnitiondes casd'utilisationELS - 7 December 2006

  • Gnie logiciel - 35 - Cycles de vie et mthode UPCette activit ne sappuie pas sur des constructions orientes objet. Elle dcrit plutt le systme en termes de fonctionnalits, et plus exactement en termes de processus de trai-tements. Un cas dutilisation est une espce de scnario, crit sous forme textuelle, qui prsente la squence des diffrentes actions qui seront menes pour accomplir une cer-taine fonctionnalit.

    Notre exemple est rduit un cas dutilisation: Lancement des ds:1. Le joueur lance les ds.2. Si le total est gal sept, il a gagn. Dans les autres cas, il a perdu.

    Modlisation du domaineDans la perspective dune classification par objets, la description du domaine implique lidentification des concepts, des attributs et des associations notables qui appartiennent au monde rel modliser.

    Cette identification pourra sexprimer sous la forme dun modle du domaine, compos de diagrammes sappuyant sur le concept des diagrammes de classes et dinteraction.

    * Le modle du domaine nest pas une description dobjets logiciels, mais une reprsentation des concepts appartenant au domaine du monde rel.

    Figure 13: Modlisation du domaine (diagramme partiel)

    Dfinition des diagrammes dinteractionUn programme objet est compos dobjets logiciels qui accomplissent leur tche en col-laborant par le biais denvois de messages.

    Les diagrammes dinteraction, utiliss dans lanalyse comme dans la conception illus-trent les collaborations entre objets.

    Player

    name

    DiceGame

    Die

    faceValueRolls

    Plays

    Includes

    2

    2

    1

    1

    1

    1ELS - 7 December 2006

  • Gnie logiciel - 36 - Cycles de vie et mthode UPDans le cadre de la conception, les flux de messages qui circulent entre les objets logi-ciels correspondent explicitement des invocations de mthodes.

    Le diagramme dinteraction prsent dans la figure suivante illustre la mise en oeuvre conceptuelle du cas dutilisation Lancement des ds.

    Figure 14: Diagramme des interactions

    Remarquons que ce type de diagramme reprsente une vue dynamique des collabora-tions entre objets.

    Dfinition des diagrammes de classe de conceptionContrairement au modle du domaine, le diagramme des classes reprsente des classes lo-gicielles, et non plus des concepts du mode rel informatiser. Ainsi, on remarquera que le joueur a disparu dans le diagramme de classes.

    Contrairement aussi au diagramme dinteraction, on reprsente ici non plus une vue dynamique du systme mais une vue statique.

    Figure 15: Le diagramme de classes (partiel)

    4.6.1 Quelques mots sur UMLUML comme Unified Modeling Language (Langage de modlisation unifi)UML a t normalis en 1997 par lOMG - Object Management Group.

    :DiceGame

    play()

    die1 : Die

    fv1 := getFaceValue()

    die2 : Die

    roll()

    roll()

    fv2 := getFaceValue()

    2

    Die

    faceValue : int

    getFaceValue() : introll()

    DiceGame

    die1 : Diedie2 : Die

    play()

    1ELS - 7 December 2006

  • Gnie logiciel - 37 - Cycles de vie et mthode UPDfinition 11: UML - Dfinition de lOMG

    UML est un langage essentiellement graphique, concu pour spcifier, prsenter, construire et documenter les diffrents lments (artifacts) que comportent les systmes logiciels.

    Il ne sagit pas dun langage formel rigoureux. Notamment UML na pas t prvu au dpart pour aboutir une gnration de code automatique. De ce ct, certains efforts sont accomplis aujourdhui autour du projet MDA (Model Driven Architecture), qui sappuie sur UML.

    Il ne sagit pas non plus dune mthode: UML ne dcrit aucun processu de dveloppement. UML est un simple outil graphique de modlisation. La mthode qui sy rattache verra le jour sous le nom UP (Unified Method).

    La puissance dUML permet de lutiliser pour tout ce qui a trait la modlisation mtier et de manire plus gnrale pour la modlisation de systmes non logiciels.

    Petite histoire en bref..Diffrentes mthodes de modlisation base sur les objets ont t dveloppes durant les annes 80. Il y en avait plus de 50 au dbut des annes 90. Chacune avait des avantages et des inconvnients, aucune ne faisait lunanimit. Parmi les trois plus populaires, on pouvait trouver :

    1. la mthode de Grady Booch, appele parfois OOD2. OMT de James Rumbaugh,3. OOSE et Objectory de Ivar Jacobson.

    Le groupe des 3 amigos, tel quon le dsigne aujourdhui tait compos de 3 notorits du monde du dveloppement orient Objet. Chacune des mthodes tait reconnue au niveau international et prouve dans la pratique.

    Plutt que dassister une guerre de tranches, les choses se sont droules trs diff-remment. Booch qui travaillait alors pour le compte de lentreprise Rational Software demanda Rumbaugh de le rejoindre, ce que fit ce dernier en 1994. En1995, Rational rachte Objectory, lentreprise de Ivar Jacobson.

    Cette offensive savamment orchestre prend de cours lindustrie qui se voit oblige bon gr mal gr et par la force des chose de participer cet effort. Un premier jet est mis disposition sur lInternet, puis soumis lapprobation de lOMG (Object Management Group).

    Plus tard, lobjectif a t rajust pour dvelopper un langage de modlisation plutt quune mthode, ce qui nous a apport UML.ELS - 7 December 2006

  • Gnie logiciel - 38 - Cycles de vie et mthode UPFigure 16: Evolution dUML

    4.7 CYCLE DE VIE DE LA MTHODE UPAu sein de la mthode UP, le projet est dcoup en 4 phases majeures, qui elles-mmes se dcoupent en itrations courtes et de dure fixe.

    Figure 17: Les 4 phases de UP

    Dure fixe des itrationsDure fixe ne veut pas dire que toutes les itrations ont la mme dure, - comme pour-rait dailleurs le faire croire la figure -, mais plutt que les itrations ont une dure fixe lors dune planification, et que la dure dune itration ne peut en aucun cas tre modi-fie en cours ditration.

    itration

    laboration construction transitionInitialisationELS - 7 December 2006

  • Gnie logiciel - 39 - Cycles de vie et mthode UPEt ceci mme si lon a pris du retard et que les objectifs mmes de litration ne pourront tre respects. Dans ce dernier cas la planification globale est revue au dbut de litra-tion suivante.

    Initialisation (Inception)Comprhension de la finalit du projet, tude de faisabilit, estimations globales et inves-tigations ncessaires pour dcider de la poursuite ou non du projet.

    * Cette phase nest pas consacre lanalyse des besoins. Certes, on y opre de lanalyse, mais de manire minimaliste! Le but tant de dcider ou non de poursuivre le projet.

    Elaboration

    Dveloppement dune vision plus labore des finalits du projet (objectifs et fonctionnalits).

    Identification de la plupart des besoins et des frontires relles du problme (notamment: rdaction des Cas dutilisation et Modlisation de domaine).

    Elaboration destimations plus ralistes (cot, planification globale). Implmentation de larchitecture centrale du systme. Rsolution des lments prsentant des risques levs. Planification des itrations de la phase de construction

    * Cette phase se focalise essentiellement sur lanalyse des besoins. Notons toute-fois que cette dernire ne sera pas forcment termine. Elle pourra tre affine, dtaille loccasion des itrations de la phase de construction.

    Notons encore que cette phase contient dj une certaine part de ralisation: implmenta-tion de larchitecture centrale notamment, et ventuellement ralisation dlments ris-ques.

    ConstructionDveloppement itratif des diffrents lments du systme, en commenant par les l-ments prsentant les plus grands risques.

    Chaque itration gnre un sous-ensemble excutable et stable du produit final.

    Cette phase comprend aussi bien de lanalyse (spcifications dtailles), que de la con-ception que du codage et du test.ELS - 7 December 2006

  • Gnie logiciel - 40 - Cycles de vie et mthode UP TransitionBta tests et dploiement. Livraison finale en fin de phase de Transition.

    4.7.1 Terminologie UP: disciplines, activits & artefactsLa mthode UP dcrit les diffrentes activits menes dans le cadre dun dveloppement.

    Voici quelques exemples dactivits:

    dessiner un diagramme de classes; dfinir un cas dutilisation; etc.

    Une activit est opre au sein dune itration, sa dure ne dpassera pas les frontires de litration dans laquelle elle prend sa place.

    Dfinition 12: Discipline UP

    Chacune des activits sinscrit dans un cadre plus large, - qui donne sa raison dtre ladite activit -, que lon appelle discipline.

    Au contraire des activits, les disciplines stalent sur plusieurs itrations, voire plusieurs phases.

    Voici quelques exemples de disciplines:

    spcification (analyse des besoins); conception; implmentation; tests; installation; etc.

    Une discipline est donc un ensemble dactivits et de produits qui lui sont lis (diagram-mes, code, graphiques, glossaire, plan de tests, etc.).

    Ces produits sont souvent appels artefacts, un terme gnrique dsignant nimporte quel produit du travail.

    4.7.2 Disciplines et phases UPEn gnral, toute itration comprend un certain nombre dactivits qui se rpartissent dans la plupart des disciplines.ELS - 7 December 2006

  • Gnie logiciel - 41 - Cycles de vie et mthode UPDans les premiers temps, laccent est port sur les disciplines danalyse et de conception. Puis, au fur et mesure de lavance du projet, on note un glissement vers limplmenta-tion, le test, etc.

    Les figurent qui suivent donnent une ide de la charge de travail consacre chaque dis-cipline selon les phases de dveloppement du projet.

    * Attention! Ces figures sont prsentes titre dillustration. Il sagit simplement dexemples. Mme si, en gnral, on retrouve les mmes disciplines dun projet lautre, la charge de travail qui leur est consacre sera chaque fois diffrente.

    Figure 18: Charge de travail relative

    Disciplines

    Modlisation mtier

    Spcification

    Conception

    Implmentation

    etc.

    initialisation laboration construction

    transi-tion

    ...ELS - 7 December 2006

  • Gnie logiciel - 42 - Cycles de vie et mthode UPFigure 19: Une itration recouvre la plupart des disciplines

    La discipline Environnement sattache faire des choix au niveau des outils et instal-ler ces derniers.

    Dans le cadre du cours de Gnie logiciel, on sintressera principalement aux dis-ciplines de Modlisation mtier, de Spcification et de Conception. Les disciplines lies au test, la gestion de configuration et la gestion de projet seront toutefois abordes.

    Itrations

    Disciplines

    Modlisation mtier

    Spcification (besoins)

    Conception

    Implmentation

    Test

    Dploiement

    Gestion des changements et des configurations

    Gestion du projet

    Environnement

    Itration de 4 semaines (exemple) ELS - 7 December 2006

  • Gnie logiciel - 43 - Phase dinitialisation5 Phase dinitialisationELS - 7 December 2006

    Si daventure votre quipe de dveloppement se voit soumettre un nouveau pro-jet, point trop de hte..

    Une tude prliminaire que lon dsigne par phase dinitialisation (inception phase) - et qui peut aboutir dans bien des cas un refus du projet -, doit tre mene par vos soins. En cas dacceptation, vous pourrez alors vous plonger dans la deuxime phase - selon le pro-cessus UP - dite dlaboration.

    Revenons maintenant cette phase dinitialisation en prsentant quelques unes des ques-tions auxquelles vous devrez rpondre:

    Quels sont les objectifs de ce projet? (pour quoi faire, dlimitation des frontires) Quels en sont les enjeux commerciaux pour lentreprise? (Y-a-t-il des perspecti-

    ves ultrieures de dveloppement?) Le projet est-il faisable? Doit-on vraiment le dvelopper le projet ou au contraire acheter, voire adapter, un

    produit du march? Que cotera grossirement son dveloppement? Les futurs utilisateurs du systme ont-ils une ide claire de ce quils dsirent et

    saccordent-ils entre eux?

  • Gnie logiciel - 44 - Phase dinitialisationEt, pour conclure, la principale question:

    Doit-on ou non accepter ce projet?

    En gros, il sagit de dcider si cela vaut ou non la peine dinvestir dans une tude plus approfondie. Bien quil ne sagisse en aucun cas dune analyse exhaustive, il peut sav-rer ncessaire de se lancer dans une investigation grossire des besoins du systme que vous seriez amener dvelopper.

    Dans la plupart des cas, la dure de cette phase est relativement courte: une, voire quel-ques semaines suffisent. Elle peut tre trs brve si votre quipe de dveloppement a dj ralis un projet du mme type en sappuyant sur sa propre exprience.

    Pour rsumer les objectifs de la phase dinitialisation:

    Dfinition 13: Phase dinitialisation

    Une activit qui consiste dfinir:

    les objectifs du projet implications pour lentreprise, enjeux commerciaux lampleur du projet (dure, cot) et sa faisabilit

    Et enfin.. de dcider de la suite apporter au projet

    5.1 LES PRODUITS GNRS PAR LA PHASE DINITIALISATIONLes diffrentes activits menes dans le cadre de cette phase dinitialisation vont gnrer un certain nombre de documents et de produits dont la liste, non exhaustive, est prsente ci-dessous.

    Rappelons que ces diffrents produits portent galement le nom gnrique darte-fact.

    * Notons demble que bon nombre des artefacts gnrs par la phase dinitialisa-tion ne constituent que des bauches. Ils seront complts ultrieurement dans le cadre des itrations futures. Cest le cas notamment de la modlisation des cas dutilisation qui devrait se contenter de prsenter les noms des acteurs et des principaux cas dutilisation: seuls 10% 20% des cas dutilisation devraient tre dcrits en dtail, au grand maximum.

    Objectifs du projet Description des buts du projet avec la liste des fonctionnalits.

    Implications pour lentreprise, enjeux commerciauxBnfices et contraintes pour lentreprise ( court, moyen et long terme); avenir du projet (perspectives dvolution, dure de vie).ELS - 7 December 2006

  • Gnie logiciel - 45 - Phase dinitialisationIdentification des contraintes organisationnelles (dlais, budget, personnel et matriel).

    Dbuts de spcificationSe reporter au chapitre se rattachant la phase dlaboration. La mise en oeuvre des spcifications (analysse des besoins) sopre essentielle-ment pendant la phase dite phase dlaboration, qui fait suite la phase dini-tialisation. Les dveloppeurs sont amens bien souvent commencer cette analyse ds la phase dinitialisation, afin de pouvoir se faire une image un peu plus raliste de lampleur du projet dvelopper.

    GlossaireTerminologie utilise dans le domaine dapplication du projet.Le glossaire comprend galement ce que lon appelle parfois le dictionnaire des donnes, qui rassemble les spcifications relatives aux diffrentes informations comme les rgles de validation, les valeurs acceptables, etc.

    A titre dillustration, voici un exemple dentres au sein dun dictionnaire de don-nes: la dfinition dun numro de tlphone

    :Nom: Numro_TlphoneSynonyme:Composition: Indicatif+No_AppelNotes:::Nom: IndicatifSynonyme:Composition: 2{Chiffre}3Notes:::Nom: No_AppelSynonyme:Composition: 3{Chiffre}8Notes:::Nom: ChiffreSynonyme:Composition: [0|1|2|3|4|5|6|7|8|9]Notes::

    Risques encourus et plan de gestion des risquesDescription des risques encourus par le dveloppement, tant au niveau commer-ELS - 7 December 2006

  • Gnie logiciel - 46 - Phase dinitialisationcial, technique, ressources (matriel et humain) que de la planification (respect des dlais). Enumration des diffrentes solutions imagines pour y rpondre ou pour minimiser le problme.

    Elaboration de prototypesIci, il faudra coder! Le but tant de vrifier le cas chant la faisabilit du projet ou den clarifier les objectifs.

    Planification de la phase dlaborationEn cas dacceptation du projet, la phase dinitialisation sera suivie par la phase dite dlaboration. Il sagit donc de dcrire les activits mener pendant la future phase dlaboration.

    5.2 A VITER PENDANT LA PHASE DINITIALISATION dy consacrer trop de temps (quelques semaines au maximum);

    dimaginer que les diffrentes planifications et estimations labores pendant cette phase sont dignes de confiance;

    de commencer y concevoir larchitecture du systme;

    domettre la dfinition des acteurs et des cas dutilisation;

    de dcrire ces derniers en dtail (10% maximum, histoire de se faire un aperu de lampleur du projet).ELS - 7 December 2006

  • Gnie logiciel - 47 - Phase dlaboration et analyse des besoins6 Phase dlaboration et analyse des besoinsELS - 7 December 2006

    La phase dite dlaboration constitue la deuxime phase de la mthode UP. Elle fait suite la phase dite dinitalisation.

    Commenons par un petit rappel sur les principales activits menes par les dve-loppeurs dans le courant de cette phase.

    Dveloppement dune vision plus labore des finalits du projet (objectifs et fonctionnalits).

    Identification de la plupart des besoins et des frontires relles du problme (notamment: rdaction des Cas dutilisation et Modlisation de domaine).

    Elaboration destimations plus ralistes (cot, planification globale). Implmentation de larchitecture centrale du systme (codage) Rsolution des lments prsentant des risques levs. Planification des itrations de la phase de construction

    * Cette phase se focalise essentiellement sur lanalyse des besoins. Cette der-nire pourra tre affine, dtaille loccasion des itrations de la phase de construction.

  • Gnie logiciel - 48 - Phase dlaboration et analyse des besoinsNotons encore que cette phase contient dj une certaine part de ralisation: implmenta-tion de larchitecture centrale notamment, et ventuellement ralisation dlments ris-ques.

    Analyse des besoins (spcification)Lanalyse des besoins, une activit commence pendant la phase dinitialisation et com-plte plus tard pendant la phase dite dlaboration - selon la mthode UP -, est sans doute lactivit la plus sensible et la plus dterminante quant la russite du projet.

    Dfinition 14: Analyse des besoins

    Une activit qui consiste :

    spcifier et rassembler les besoins auxquels devra rpondre le projet, enregistrer ces besoins (documents, modles, etc.), dans une forme accessible et comprhensible dune part par les futurs utilisateurs

    du systme et dautre part par les membres composant lquipe de dveloppe-ment.

    Dfinition 15: Spcification et cahier des charges

    Le terme spcification, ou encore spcification des besoins, analyse des besoins, est souvent utilis pour dnoter la mme activit, celle danalyse des besoins, dont le produit est un document que lon nomme frquemment spcifications ou encore cahier des charges.

    Ltude mene par Standish en 1994 permet de sentir toute limportance de cette activit.ELS - 7 December 2006

  • Gnie logiciel - 49 - Phase dlaboration et analyse des besoinsFigure 20: Les facteurs contribuant lchec dun projet

    La qualit de la spcification aura une grande influence sur le choix de larchitecture du systme, sur le choix du matriel et des outils informatiques.

    , Notons quune des rponses possibles pour rpondre cette problmatique est celle qui consiste mener cette activit de manire trs approfondie et de la stabiliser avant de passer aux activits suivantes (conception et implmentation). Ctait la vision du modle en cascade (Waterfall) dont on connat toutes les dboires. La solution prco-nise actuellement consiste plutt accepter les changements et les prendre en compte dans un modle itratif.

    Besoins fonctionnels et non-fonctionnelsLanalyse des besoins est en fait un terme assez vague qui requiert quelques prcisions.

    Dfinition 16: Classification des besoins

    En gnral, on distingue les besoins fonctionnels des autres besoins dits non-fonc-tionnels qui rassemblent diffrentes spcifications.

    Besoins fonctionnelsCes derniers recueillent les diffrentes fonctions - traitements, oprations, services - of-fertes par le systme dvelopper pour satisfaire les besoins du client.

    Y sont dcrits galement le format des informations, les valeurs autorises pour les entres et le comportement du systme en cas de:

    valeurs illgales, pannes, ou de problmes divers.

    Besoins non-fonctionnelsLes besoins non-fonctionnels dcrivent les conditions et contraintes devant tre respec-

    7%12% 12%

    13%6%

    50%

    Inadquation des informations reues des

    utilisateurs

    Spcifications incompltes

    Modification dans les spcifications

    Incapacits techniques

    Incapacits de gestion

    AutresELS - 7 December 2006

  • Gnie logiciel - 50 - Phase dlaboration et analyse des besoinstes par le systme pour accomplir les besoins fonctionnels.

    Principalement:

    Contraintes dutilisation (IHM)Facteurs humains, documentation et aide.

    FiabilitFrquence de pannes tolre, restauration du systme.

    PerformanceTemps de rponse, capacits de traitement, utilisation des ressources.

    PortabilitContraintes de portabilit, dadaptation, de configuration, internationalisation (langues)

    Scurit

    De manire auxiliaire:

    Contraintes dimplmentationLimitations quant aux ressources, contraintes sur le systme dexploitation, sur les langages, sur les outils, sur le matriel, etc.

    Contraintes dinterfaage Interfaage avec dautres systmes existants ou venir.

    Contraintes oprationnellesGestion du systme et paramtrage.

    Mode de livraison du produit (packaging)

    Contraintes juridiques et/ou thiquesLicences, privatisation des informations, dangers pour la sant, etc.

    Dans le cadre des diffrents documents produits par la phase dinitialisation (c.f. le para-graphe prcdent [Voir paragraphe - Les produits gnrs par la phase dinitialisation - page 52]), notons que les besoins sont dcrits:

    dans les Objectifs du projet (liste des fonctionnalits)

    dans la Modlisation des cas dutilisationD Besoins fonctionnels et non-fonctionnels

    dans les Spcifications complmentairesD Besoins non-fonctionnels

    dans le GlossaireD Besoins fonctionnels (dictionnaire des donnes)ELS - 7 December 2006

  • Gnie logiciel - 51 - Phase dlaboration et analyse des besoinsExemple 1: Un correcteur dorthographe

    Voici quelques spcifications extraites dune analyse de besoins pour un correcteur dor-thographe.

    " Parmi ces diffrentes propositions, lesquelles appartiennent la catgorie besoins fonctionnels, lesquelles la catgorie besoins non-fonctionnels, et dans ce dernier cas, quelle sous-catgorie? Quelles remarques critiques peut-on formuler?

    1. Lorsqu'un mot non identifi est rencontr dans le texte, l'utilisateur doit avoir le choix entre remplacer le mot par un mot de substitution, insrer le mot dans le dic-tionnaire, rechercher des mots similaires dans le dictionnaire afin d'en dterminer l'orthographe correcte, ou sortir du programme.

    2. Toute la ligne contenant l'ventuel mot mal crit doit tre affiche au terminal.3. L'utilisateur doit avoir la possibilit d'afficher les mots du dictionnaire qui dbu-

    tent par une chane de caractres.4. Le programme ne doit pas s'arrter lorsque le dictionnaire est plein.5. Chaque fois que c'est possible, les donnes entres par l'utilisateur doivent tre v-

    rifies, et en cas d'erreur, le programme affichera un message appropri.6. Le dictionnaire doit tre capable de contenir au moins 40 '000 mots. Des techni-

    ques de compression sont acceptables.7. Le logiciel doit tre capable de traiter 250 mots la minute.8. Un mot est une chane d'un ou plusieurs caractres dlimites par des caractres ne

    faisant pas partie d'un mot. Les caractres qui font partie d'un mot sont les lettres majuscules et minuscules (sans distinction entre elles) et les apostrophes.

    9. Les mthodes internes de tri et de recherches ne sont pas critiques dans la dfini-tion du systme. Les mthodes doivent tre efficaces du point de vue du temps de calcul et utiliser un minimum de mmoire.

    10.Le dictionnaire ne doit pas dpasser la taille de 400 ' 000 octets.11.Les mots jusqu' au moins 13 caractres doivent tre analyss pour vrifier s'ils

    sont crits correctement. Les mots plus longs doivent pouvoir tre affichs au ter-minal, afin de permettre l'utilisateur d'en vrifier l'criture.

    12.Les commandes du programme doivent tre prsentes sous forme de menu clair et concis.

    Les difficults rencontres lors de la spcification

    comprhension du domaine dapplication; trouver et identifier les bonnes personnes interviewer (utilisateurs); notons ici

    que le client nest pas forcment lutilisateur final du systme. leur poser des questions pertinentes; relever les contradictions dans les besoins noncs par les utilisateurs, des diff-

    rences de terminologie, etc. identifier les frontires du systme dvelopper;ELS - 7 December 2006

  • Gnie logiciel - 52 - Phase dlaboration et analyse des besoins produire une documentaion prcise, concise et claire pour tout le monde (utilisa-teurs comme dveloppeurs).

    communiquer avec le client: son langage nest pas le mme que le langage de linformaticien;

    faire valider la spcification par le client, tout en acceptant de futures modifica-tions du cahier des charges.

    Quelques techniques utilises lors de la spcification

    interviews, questionnaires, observation; analyse de documents existants; jeux de rle; prototypage.

    Spcification formelle et informelleDans certains domaines, par exemple en lectronique, le niveau de formalisme de spci-fication pour dcrire des microprocesseurs a pu tre pouss trs loin, on parle alors de sp-cification formelle (Z, Estelle, etc.).

    Les avantages de telles mthodes sont les techniques de preuve et la gnration automatique de codes.

    / Les dsavantages sont principalement le formalisme, proche des mathmatiques ou de la logique, qui force le client bien matriser ce formalisme, et dautre part la diffi-cult matriser le niveau de dtail et les changements.

    Exemple 2: la ligne Mteor du mtro parisien

    ObjectifVrifier la vitesse du mtro en fonction de valeurs fournies par des capteurs. Il y a essentiellement trois phases excutes rgulirement sans interruption:

    acquisition des valeurs laide des capteurs; calcul de dcision; envoi de commandes

    EnjeuLe programme doit fonctionner sans erreurs cause des risques sur la vie que cela entrane.

    MthodeSpcification formelle laide du langage B:Dcrire ce que doit faire le systme en terme de contrle de vitesse, laide dun langage de description dtats du systme.ELS - 7 December 2006

  • Gnie logiciel - 53 - Phase dlaboration et analyse des besoins DmarcheGnration du code (quelque milliers de lignes) permettant de prouver que le sys-tme se comporte tel que spcifi.

    RemarqueLe problme pos se dcrit particulirement bien laide dtats et de transitions, ce nest hlas pas le cas de beaucoup de problmes.

    Langage BExemple de recherche dans un tableau

    Spcification semi-formelle et UMLPour dautres domaines, il vaut mieux utiliser des mthodes de spcification semi-formel-le, bases sur la langue naturelle et des diagrammes.La spcification oriente objets, base sur UML en est une. Le langage est suffisamment prcis pour tre comprhensible par le client.ELS - 7 December 2006

  • Gnie logiciel - 54 - Phase dlaboration et analyse des besoinsELS - 7 December 2006

  • Gnie logiciel - 55 - Modle des cas dutilisation7 Modle des cas dutilisationELS - 7 December 2006

    Le modle des cas dutilisation est reconnu aujourdhui comme un excellent moyen pour comprendre et dcrire les besoins.

    ObjectifRaconter la manire dont on va utiliser le systme, - du point de vue du client (de luti-lisateur) -, pour atteindre les diffrents objectifs.

    Finalit: identifier et enregistrer les besoins fonctionnels du systme.

    HistoriqueLe modle a t introduit en 1986 par Ivar Jacobson (un des trois amigos).

    Trs vite reconnu comme un des moyens les plus simples et efficaces pour dcrire les besoins fonctionnels.

    Voir aussi louvrage dAllistair Cockburn Rdiger des cas dutilisation efficaces, une contribution trs importante au modle de cas dutilisation.

  • Gnie logiciel - 56 - Modle des cas dutilisation7.1 SA PLACE DANS LA MTHODE UPDu point de vue de la mthode UP, ce modle fait partie de la discipline dite de Spcifi-cation (requirements). Ce modle sadresse la description des fonctionnalits du systme et de son environnement.

    Cest donc pendant la phase dlaboration que le dveloppeur sera amen rdiger des cas dutilisation, en commenant par la dfinition dun diagramme de contexte (pour dfinir comme on le verra les frontires du systme). Le raffinement de certains cas dutilisation sera parfois relgu la phase de construction, loccasion de telle ou telle itration.

    Un dveloppement guid par les cas dutilisation

    Dfinition 17: Un dveloppement guid par les cas dutilisation

    Les cas dutilisation constituent un lment essentiel de la mthode UP pour laquelle on peut dire que le dveloppement est pilot par les cas dutilisation.

    Voici quelques points cls retenir:

    Les besoinsLa rdaction des cas dutilisation permet de capturer la majeure partie des spcifi-cations (des besoins). Pour le reste, se rfrer aux spcifications complmentaires [Voir paragraphe - Complments de spcifications - page 85].

    La planification et le partage du travailLes cas dutilisation constituent une base de rfrence pour tablir la planifica-tion des futures itrations de la phase de construction.En effet, le travail de dveloppement accomplir dans une itration consiste le plus gnralement implmenter un cas dutilisation au complet ou un scnario particulier dun cas dutilisation. Au sein dune mme itration, diffrents cas dutilisation peuvent tre implments simultanment par des quipes diffrentes.

    Manuels dutilisationCes derniers sorganisent essentiellement autour des cas dutilisation.

    Quand doit-on rdiger des cas dutilisation?Dans le cadre de la mthode UP, la rdaction des cas dutilisation est une activit faisant partie de la discipline dite de Spcification.

    En rgle gnrale, la rdaction des cas dutilisation commence pendant la phase dini-tialisation, une phase pendant laquelle on se contente dordinaire dtablir la liste des acteurs et la liste des cas dutilisation en les dcrivant de manire trs succincte.

    La rdaction proprement parler se droule pendant la phase dlaboration. Cela ser-vira de base pour la planification des itrations de la phase de construction.ELS - 7 December 2006

  • Gnie logiciel - 57 - Modle des cas dutilisationElle se poursuit parfois pendant la phase de construction (rdaction de dtails).

    7.2 QUELQUES DFINITIONS PRALABLES

    ActeurUn acteur est une entit - extrieure au systme - qui manifeste un certain comportement vis vis du systme. Il peut sagir:

    Dune personnePar la suite, on parlera alors plutt de rle car une mme personne physique peut jouer plusieurs rles. Chacun de ces rles donnera lieu un acteur diffrent. Par exemple, la mme personne physique peut jouer la fois le rle dadministra-teur systme et dutilisateur.

    Dun systme (extrieur au systme analyser)

    ScnarioUn scnario est une suite dactions et dinteractions entre les acteurs et le systme ana-lyser.

    Un scnario raconte une histoire possible se droulant entre un acteur et le systme. La mise en oeuvre dune fonctionnalit spcifique prsente toujours plusieurs scnarios possibles. Par exemple, loccasion du traitement dune vente, il est possible que la tran-saction russisse (un scnario possible), ou alors quelle choue si la carte de crdit du client est chue (un autre scnario possible).

    Un cas dutilisation

    Dfinition 18: Cas dutilisation

    Un cas dutilisation est un ensemble de scnarios dcrivant la faon - par un acteur - duti-liser le systme pour atteindre un certain objectif.

    Il peut sagir de scnarios dchecs ou de succs: en gnral il sagira dun scnario de succs (le scnario principal) et de quelques scnarios dchec.

    A titre dillustration: Traiter une vente (systme POS)ELS - 7 December 2006

  • Gnie logiciel - 58 - Modle des cas dutilisation Un diagramme de cas dutilisationLe langage UML a prvu une reprsentation graphique des cas dutilisation sous la forme de diagrammes dits Diagrammes de cas dutilisation.

    Figure 21: Un diagramme de cas dutilisation

    Comme on le verra par la suite, les cas dutilisation sont dcrits sous forme textuelle. Ces diagrammes peuvent tre prsents titr