Cours Génie Logiciel 1

Universit de Batna Dpartement dInformatique Module : Gnie logiciel (GL1) ( 3me anne Ingnieur ) Enseignante : Mme S.S.
. Bendib Anne scolaire : 2007 / 2008

-----------------------------------------------------------------------------------------------------------------------------------------------------------
Universit de Batna Facult des sciences de lingnieur Dpartement dinformatique Module : Gnie logiciel ( 3me anne Ingnieur ) Responsable : Mme S.S.Bendib
Introduction
La complexit des systmes informatiques ne cesse de crotre et les exigences lgard de la qualit logicielle sont de plus en plus grandes. Il est aujourdhui essentiel que le dveloppement logiciel puisse tre soutenu par des mcanismes pertinents de planification, danalyse, de conception et de vrification, ce qui permet llaboration de systmes fiables, performants et facilement modifiables.
Objectifs du cours
Le cours GL1 est une introduction au gnie logiciel. Il vise donner ltudiant une bonne connaissance du cycle de vie du logiciel et linitier au processus de dveloppement des logiciels ainsi quaux mthodes et outils utiliss pour dvelopper des logiciels de qualit. Le cours est constitu de trois parties : Une introduction talant la problmatique et expliquant ce qui ft appele la crise du logiciel. Tout logiciel tant une partie intgrante dun systme plus grand, la deuxime partie concerne, de ce fait, la notion de systme ainsi que le cycle de vie de celui-ci. Enfin, la troisime partie est consacre au cycle de vie dun logiciel ainsi qu quelques modles de dveloppement.
NB : Ce support de cours tant une introduction au gnie logiciel, ltudiant doit, de ce fait, le complter par dautres lectures et ce afin dapprofondir ses connaissances concernant chaque partie du programme.
Universit de Batna Dpartement dInformatique Module : Gnie logiciel (GL1) ( 3me anne Ingnieur ) Enseignante : Mme S.S. Bendib Anne scolaire : 2007 / 2008
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Module : Gnie logiciel ( 3me anne Ingnieur ) Responsable : Mme S.S.Bendib
Plan
I/ Introduction gnrale II/ La conception systme II-1/ Notion de systme II-2/ Dynamique des systmes II-3/ Caractristiques des systmes II-4/ modles II-5/ Cycle de vie dun systme II-6/ Conception statique dun systme II-6-1/ Spcification technique des besoins II-6-2/ Mthodes pour la conception statique dun systme II-6-2-1/ La mthode SADT (Structured Analysis and Design Technique) II-6-2-2/ Le modle Entit/Association II-7/ Conception dynamique dun systme II-7-1/ Le prototypage II-7-2/ Les rseaux de Petri II-7-3/ Lapproche oriente objet III/ Cycle de vie dun logiciel III-1/ Introduction III-2/ Qualits exiges dun logiciel III-3/ Activits principales du processus de dveloppement dun logiciel III-4/ Modles de cycle de vie III-4-1/ Le modle en cascade III-4-2/ Le modle par prototypage III-4-3/ Le modle en V III-4-4/ Le modle en spirale III-4-5/ Le modle par incrment III-5/ Dtails des phases du processus de dveloppement dun logiciel III-5-1/ Analyse des besoins III-5-2/ Spcification III-5-2-1/ Spcification de logiciel III-5-2-2/ Mthodes de spcification III-5-2-2-1/ Lanalyse structure III-5-2-2-2/ Lanalyse structure Temps Rel ( SART ) III-5-2-2-3/ Les spcifications formelles III-5-3/ Conception de logiciel III-5-2-1/ Concepts de structuration III-5-2-1-1/ La modularit
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5-2-1-2/ Labstraction III-5-2-1-3/ La hirarchie III-5-3-2/ Approches de conception III-5-3-2-1/ La conception fonctionnelle III-5-3-2-2/ La conception oriente objet III-5-4/ Implmentation et langages de programmation III-5-4-1/ Processus de dveloppement dun programme III-5-4-2/ Les langages de programmation III-5-4-2-1/ Taxonomie de base III-5-4-2-2/ Niveaux de langages III-5-4-2-3/ Classification selon le code excut III-5-4-2-4/ Langages orients objet III-5-4-2-5/ Polymorphisme et liaison dynamique III-5-5/ Tests de logiciel III-5-5-1/ Types de test III-5-5-2/ Mthodes de test III-5-5-3-1/ Mthodes de tests statiques III-5-5-3-2/ Mthodes de tests dynamiques III-5-5-3/ Spcification de test III-5-5-4/ Cycle de dveloppement de test III-5-6/ Maintenance de logiciel III-5-6-1/ Types de maintenance III-5-6-2/ Processus de la maintenance III-5-6-3/ Facteurs influenant le cot de la maintenance III-5-7/ Documentation III-5-6-1/ Types de documents III-5-6-2/ Gestion de la documentation III-5-6-3/ Quelques exemples standards de documents III-6/ Rpartition gnrales des efforts III-7/ Portabilit de logiciel
-----------------------------------------------------------------------------------------------------------------------------------------------------------
I / Introduction gnrale
La non qualit des systmes informatiques a des consquences qui peuvent tre graves, voire dsastreuses, citons quelques consquences de bogues : Refus illgaux de prestations sociales des ayants droits. Cause : le cahier des charges navait pas prvu tous les cas. Mission Vnus : passage 5000 000 km de la plante au lieu des 5000 km prvus. Cause : remplacement dune virgule par un point. Perte de satellites dans les annes 70. Cause : +I au lieu de +1 dans une boucle du programme source Fortran. Hpital : Dcs de patients. Cause : erreur dans les programmes de monitoring. Premier lancement dAriane V : elle explose en vol. Cause : logiciel de plate-forme inertielle tel quel dAriane IV sans nouvelle validation. Le logiciel a jug linclinaison dAriane V non conforme au plan de tir ( dAriane IV ) et a lanc lordre de destruction. En fait, tout tait normal ! Etc. On considre que la prise de conscience dune crise du logiciel date de la fin des annes 1960. Cette prise de conscience eut lieu Garmisch ( Allemagne ) en 1968 lors de la confrence internationale sur la conception de logiciels. Lide tait damliorer la qualit des logiciels et ce en adoptant des mthodes de dveloppement et en les respectant. De ce fait, est ne une discipline appele Gnie Logiciel.
Quest ce que le Gnie Logiciel ?

Le gnie logiciel est lensemble des activits de conception et de mise en oeuvre des procdures tendant rationaliser la production du logiciel et son suivi. Autrement dit : LE GL se proccupe des procds de fabrication des logiciels en sassurant que les quatre critres suivants soient respects : - le logiciel proposera les fonctionnalits dsires et rpondra aux besoins des utilisateurs - le logiciel sera de qualit - les cots resteront dans les limites prvues initialement - les dlais de livraison ne seront pas dpasss.
rgles du CQFD = Cot Qualit Fonctionnalit Dlai

Cependant, tout logiciel fait partie ou est inclus dans un systme quil faut dabord tudier avant de dcider sur les parties automatiser ( logiciel ). Par consquent, il serait ncessaire daborder la notion de systme ensuite celle du logiciel et de son cycle de vie.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II / La conception systme
II-1 / Notion de systme
Un systme est un ensemble dlments en interaction dynamique organiss en fonction dun but. Un systme peut tre abstrait ou concret, naturel ou artificiel. On parle ainsi du systme solaire, du systme de scurit sociale, dun systme informatiqueetc. Les systmes sont souvent imbriqus, un systme contient dautres systmes, appels des sous systmes, et lui mme est contenu dans un systme plus grand qui constitue son environnement.
II-2 / Dynamique des systmes

* Un systme reoit des donnes dentre dautres systmes ou de lenvironnement. * Les entres subissent des modifications ( transformations ). * Les transformations produisent des sorties quabsorbent dautres systmes ou lenvironnement .
information produit nergie Entres
information
systme
produit nergie Sorties
Tout systme effectue des changements sur les entres ( nergie, matire ou information ) quil reoit , ceci caractrise sa fonction et son dynamisme.
II-3 / Caractristiques dun systme

Un systme est caractris par : Sa structure : les lments qui le composent. Son volution : les tats successifs par lesquels il passe. Les fonctions : ce quil sait faire.
II-4 / Modles
Un modle est une reprsentation dun systme, il permet de comprendre et de grer le comportement dun systme. Lutilisation de modles prend une part de plus en plus importante dans les projets technologiques mens par les ingnieurs, que ce soit pour la dfinition de systmes, leur conception ou leur ralisation.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
A un mme systme, peuvent correspondre plusieurs modles, selon lobjectif de ltude, le systme de reprsentation, etc. Modle1
Systme
Modle2
ModleN Le concept de systme nous aide observer la ralit en la considrant comme tant forme densembles dynamiques en relation les uns avec les autres. Quand on applique le concept de systme la dfinition et la ralisation des problmes, on parle alors dapproche systmique.
II-5 / Cycle de vie dun systme

Le cycle de vie dun systme est constitu dun ensemble dtapes : 1 Orientation faisabilit des besoins Il sagit de rdiger un cahier des charges relatif aux besoins du client en matire de matriels, de logiciels et de personnel. 2 Conception prliminaire Elle comporte deux aspects, lun fonctionnel et lautre organisationnel. Laspect fonctionnel concerne la description des services que le systme devra fournir ( quoi ). Quant laspect organisationnel, lintrt est port sur comment ces services vont tre raliss. 3 Conception dtaille IL sagit daffiner ( dtailler ) les aspects fonctionnel et organisationnel du systme . ------------------------------------------------------------------------------------------------------------------
4 Dveloppement du logiciel du systme

Cest une tape qui consiste construire ( selon un cycle de vie normalis ), les composants logiciels du systme en se basant sur les documents fonctionnel et organisationnel des tapes prcdentes . -----------------------------------------------------------------------------------------------------------------5 Intgration matriel / logiciel Une fois les composants construits et tests, cette tape se charge de produire un systme en intgrant matriel et logiciel. Ensuite, ce mme systme doit tre test et certifi conformment au dossier de dfinition dintgration dfini dans les tapes prcdentes.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
6 Validation du systme Cette phase a lieu sur le site, son objectif est de dmontrer au client que le systme dvelopp rpond effectivement aux besoins exprims dans le cahier des charges fonctionnel ( rsultat de la conception prliminaire ) et aux spcifications techniques des besoins. 7 Maintenance du systme Cest une tape qui ncessite une collaboration entre le concepteur du systme et lutilisateur. Pour quun systme reste oprationnel, il est ncessaire de lamliorer, de ladapter et de le corriger.
II-6 / Conception statique dun systme

Afin que la conception dun systme soit complte, il est ncessaire de prendre en compte deux aspects : * Un aspect statique qui se charge de traiter les activits et les donnes. * Un aspect dynamique qui sintresse aux tats du systme ( c'est--dire lvolution du systme dans le temps ). Cependant, avant dentamer la conception statique dun systme, il est ncessaire dlaborer une spcification technique des besoins partir du cahier des charges. La STB ( spcification technique des besoins ) dcrit avec prcision les besoins du systme dvelopper.
II-6-1 / Spcification technique des besoins ( STB )

Les besoins sont dcrits en quelques points : II-6-1-1 / Introduction : On y dcrit : - Ce quon attend du systme - La justification conomique motivant la ralisation dun tel systme. II-6-1-2 / Environnement du systme Il sagit de dcrire lenvironnement du systme que lon doit dvelopper en termes dentits, dvnements, de conditions et dobservations dfinis dans le cahier des charges. II-6-1-3 / Description gnrale des fonctionnalits On dcrit les fonctions du systme ( services offerts ) ainsi que les objets pertinents manipuls pas le systme. Dans ce cas, la description reste un niveau abstrait, les dtails sont relgus la phase de conception. II-6-1-4 / Exigences oprationnelles II-6-1-4-1/ Contraintes dexploitation : ce sont des contraintes dpendantes de lenvironnement, on y voque par exemple : - les problmes de sauvegarde et de reprise ; - les problmes de scurit (ya t-il des informations qui doivent tre protges ? );
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-6-1-4-2 / Modes de fonctionnement : Cest la description des diffrents modes de fonctionnement. Deux cas sont pris en compte : Le mode nominal ( ou normal ) : on doit indiquer les squences possibles ( elles pourraient ne pas toutes apparatre dans la vie du systme ). Le mode dgrad : dans ce cas, il faudra expliquer si effectivement il peut y avoir des incidents qui laisseront le systme assurer un minimum de fonctionnalits ou au contraire si on met le systme dans un tat tel quil ny aura aucun danger pour lenvironnement. II-6-1-4-3 / Capacits : Les capacits y sont dcrites dont : - le nombre maximum de terminaux ; - le nombre maximum de transactions ; II-6-1-4-4 / performances : Il sagit de lister les contraintes en temps et en espace, satisfaire telles que : - le temps de rponse souhait ; - la frquence moyenne dacquisition de mesures ; - la frquence maximale II-6-1-4-5 / Contrlabilit : Il sagit de dcrire des spcifications particulires ( lies au contrle) permettant de suivre lexcution dun traitement. II-6-1-4-6 / Scurit : consiste prciser le niveau de confidentialit du systme (exemple: mots de passe pour le contrle daccs ). II-6-1-4-7/ Intgrit : le systme ne doit en aucun cas modifier/dtruire de faon intempestive les donnes quil manipule. Il sagit donc de prciser les protections contre les dconnexions, les pertes dinformations..etc. II-6-1-4-8/ Maintenabilit: ce sont des contraintes lies aux procdures de maintenance. Autrement dit, si le systme doit subir des volutions prvues, cest ce niveau quil faudra le mentionner. II-6-1-5 / Exigences techniques Cette rubrique comprend des clauses techniques dont : logiciels imposs ; algorithmes imposs ; interfaces avec le matriel : Il sagit de dcrire : - le matriel informatique et le matriel non informatique ; - le protocole de communication et le raccordement ; - le type de liaison ( srie, parallle, synchrone, asynchrone ). - interfaces avec dautres logiciels : Il sagit de dcrire les procdures de soumission de travaux distance ( rseaux ) et les procdures dchange de messages.
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-6-1-6 / Description des fonctions On identifie les fonctions, chacune delle est dfinie par un nom. Le rle de chaque fonction est prcis, ainsi que les contraintes oprationnelles. II-6-1-7 / Description des objets On identifie les objets et pour chacun deux, on dcrit : Le nom, les attributs, la valeur de chaque attribut, la classe et les contraintes sur les attributs. II-6-1-8 / Conformits aux standards : consiste prciser les rfrences aux standards. II-6-1-9 / Facteurs de qualit : il sagit de faire rfrence un plan de qualit logiciel. II-6-1-10 / Glossaire : un lexique est tabli expliquant : - les termes techniques ; - les abrviations ; - les symboles dans le document STB. II-6-1-11 / Rfrences : toutes les rfrences techniques sur le projet sont fournies.
II-6-2 / Mthodes pour la conception statique dun systme

La conception statique dun systme vise dfinir une structure qui montre les diffrents composants du systme raliser. Or, la structure dun systme ne se dfinit pas dune faon alatoire mais il existe un certain nombre de mthodes qui permettent de le faire, la mthode SADT en est une. II-6-2-1 / La mthode SADT ( Structured Analysis and Design Technique ) SADT est une technique danalyse fonctionnelle et de conception de systme dinformation. SADT : * est une mthode qui dintresse aux fonctions que le systme doit fournir ( le quoi ) sans se proccuper de la manire dont ces fonctions seront ralises. * permet danalyser un systme dune manire : - hirarchique : la dcomposition se fait pas niveaux ; - descendante : dbute par un niveau gnral pour aller vers des niveaux plus dtaills ; - modulaire : dcomposition en un ensemble de modules ( un module peut regrouper plusieurs fonctions ). * utilise une reprsentation graphique pour laborer des modles. * est une mthode de travail en groupe : un projet est trait par plusieurs personnes qui communiquent entre elles par crit pour corriger dventuelles erreurs et finaliser le projet. Pour tudier un systme, la mthode SADT consiste le reprsenter par un modle. Les lments essentiels dun tel modle sont : 1/ Le diagramme dactivit ( Lactigramme ) Un actigramme reprsente une fonction du systme en tude. Il est compos dune bote ( sous forme rectangulaire ), reprsentant une activit du systme et de quatre liens ( sous forme de flches ). 9
-----------------------------------------------------------------------------------------------------------------------------------------------------------
donnes de contrle .. donnes dentre : nom de lactivit .. mcanismes ou support de lactivit * Les donnes dentre sont des donnes prises par lactivit et transformes en donnes de sortie. * Les donnes de sortie sont des donnes produites par lactivit. * Les donnes de contrle sont des donnes qui influent sur le processus de transformation dentres en sorties. Les donnes de contrle ne sont pas modifies par lactivit. * Les mcanismes de lactivit sont les moyens utiliss pour raliser lactivit ( personnel, matriel, logiciel ). Lorsqu une activit ( fonction ) est dclenche, elle prend des donnes en entre quelle transforme en donnes de sortie, en fonction de donnes de contrle et en utilisant un ensemble de mcanismes. Remarque : Les flches - dentre - de contrle - de sortie sont appeles flches dinterface : donnes de sortie
Les flches de mcanisme sont appeles flches de support.
Exemple : Modlisons lactivit reproduire copies par un actigramme. nombre de copies copie originale
format des photocopies
Reproduire copies photocopieuse
10
-----------------------------------------------------------------------------------------------------------------------------------------------------------
2/ Le diagramme de donnes ( datagramme ) Un datagramme reprsente des donnes cres par une activit gnratrice ( en entre ) et consommes par une activit utilisatrice ( en sortie ) sous le contrle dactivit de contrle et moyennant un support. activits de contrle . activit gnratrice nom de la donne support de donnes * La flche dentre reprsente une activit qui cre la donne. * La flche de sortie reprsente une activit qui utilise la donne. * La flche de contrle reprsente une activit qui a une influence sur le droulement dune activit dentre ( cration de la donne ) ou dune activit de sortie ( utilisation de la donne ). * Les mcanismes expriment le support de stockage ( physique ou logique ) de la donne. Exemple : Modlisons la donne nombre par un datagramme. slectionner le type dopration saisir Nombre afficher activit utilisatrice
registre de la calculatrice Remarques : * Une flche vhicule une classe de donnes ( ou dactivits ) et non pas une seule donne ou activit . * Quand il existe une rciprocit dans les interfaces entre deux botes, on peut remplacer les deux flches par une flche double sens. Si linformation nest pas la mme dans les deux sens, alors on utilise une double tiquette avec ses deux parties spares par une barre. * Une flche peut former une boucle pour indiquer la mise jour dune donne. * Les flches dun diagramme SADT, datagramme ou actigramme, reprsentent les contraintes de liaison entre les botes. * Les flches ne dsignent pas les squencements comme dans un organigramme, elles montrent tout simplement ce dont la bote a besoin pour remplir son rle. * La sortie dune bote peut devenir lentre ou le contrle dune ou de plusieurs autres botes.
11
-----------------------------------------------------------------------------------------------------------------------------------------------------------
3 / Les textes explicatifs : Ce sont des commentaires qui accompagnent les diagrammes pour reprsenter les faits que lauteur juge pertinents. 4 / liste hirarchique et numrotation des diagrammes. Les noeuds dun modle SADT suivent une numrotation prcise : Le premier nud reprsente le systme global, il a le numro A0 pour un actigramme et le numro D-0 pour un datagramme. Lactivit mre (A-0) est dcompose en un ensemble de botes A1, A2,..quon appelle le diagramme A0. Chaque bote Ai du diagramme A0 peut tre dcompose en Ai1, Ai2, Ai3 etc. Ce raisonnement est galement adopt pour un datagramme. 5/ Le glossaire : Le glossaire contient un ensemble de labels courts et prcis pour les flches et les botes. Il permet dclaircir les diagrammes. 6/ Les conditions dactivation : Dans le cas des actigrammes, les conditions dactivation permettent de spcifier dans quelles circonstances une bote sera active et ce quelle produira.
Cycle auteur / lecteur La mthode SADT tant un travail de groupe, un change de rsultats entre les membres du groupe, est ncessaire. Ceci est dfini comme tant le cycle auteur/lecteur . Lunit dinformation utilise dans le cycle A/L est Le KIT. Celui-ci est un ensemble de diagrammes avec des informations telles que les textes, le glossaire, les quations dactivation.
Les principales tapes du cycle A/L sont les suivantes : 1/ Envoi dun KIT de lauteur vers le lecteur. 2/ Lecture du KIT par le lecteur, criture des commentaires sur la copie des diagrammes et renvoi du KIT lauteur. 3/ Rponse de lauteur par crit sur la copie du diagramme : Si daccord Alors en tenir compte dans les nouvelles versions des diagrammes Sinon se justifier 4/ Lecture des rponses par le lecteur Si lecteur satisfait Alors classer le KIT dans le fichier des modles Sinon se runir pour en discuter Remarque: Un diagramme peut subir trois quatre tests pour tre valid.
12
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-6-2-2 / le modle Entit / Association Le modle Entit/Association ( E/A ) date de 1976 ( P.Chen p) et est toujours trs utilis, notamment dans la conception des bases de donnes relationnelles. Dans cette approche de modlisation, un systme est considr comme un ensemble dentits lies par des liens appels associations. Les concepts essentiels de lapproche sont : 1/ Proprit : Une proprit est une donne lmentaire ayant un sens et pouvant tre utilise dune manire autonome. Dans dautres modles, on parle de caractristique ou encore dattribut. Le rle des proprits est de dcrire des entits et des associations. Exemple : nom tudiant , nom fichier , anne inscription .. Les valeurs prises par les proprits sont appeles occurrences. Proprit Nom ENS Occurrences -
2/ Entit : Une entit peut tre concrte ou abstraite. Elle a une existence propre et une importance dans le systme. Exemple : Employ, service, tudiant . Une entit possde un ensemble de proprits. Une occurrence de lentit est compose dun ensemble constitu dune occurrence de chacune de ses proprits. Entit Enseignant proprits Nom Ens Grade : occurrences de lentit . . Lidentifiant est une proprit particulire dune entit. Les valeurs prises par lidentifiant sont diffrentes, autrement dit, deux occurrences distinctes de lentit ne peuvent avoir la mme valeur pour la proprit identifiant, ( identique la notion de cl utilise dans le modle relationnel ). On reprsente une entit et ses occurrences comme suit :
13
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Enseignant ENS # NOM ENS ENS ENS occurrences
3/ Association : Lassociation exprime un lien smantique qui relie un ensemble dentits. Une association na pas didentifiant propre, elle est identifie par la concatnation des identifiants des entits relies. Exemple : ETU est affect GROUPE
* Lensemble des entits intervenant dans une association est appele sa collection. * Les traits reliant une association aux entits sont appels pattes. * Le nombre de pattes dfinit la dimension ou lordre de lassociation. * Il peut exister plusieurs associations entre les mmes entits. 4 / Cardinalit : La cardinalit est dfinie comme un couple de valeurs reprsentant le nombre de fois minimum ( 0 ou 1 ) et le nombre de fois maximum ( 1 ou n ) quune occurrence de lentit peut intervenir dans les occurrences de lassociation. Exemple : ETU (1,1) est affect ( 1 , 40 ) Groupe
Un tudiant ( une occurrence ETU ) est affect au minimum un groupe et au maximum un groupe . Un groupe ( une occurrence groupe ) contient au minimum 1 tudiant et au maximum 40 tudiants . En utilisant ces concepts, le modle E/A permet de modliser un systme comme un ensemble dentits ayant des proprits et pouvant tre relies par des associations.
14
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-7 / Conception dynamique dun systme

En plus de laspect statique et afin de complter la conception dun systme, il est ncessaire de traiter galement laspect dynamique. Dans ce cas, lintrt est port sur le comportement du systme. Il existe diffrentes mthodes permettant dapprhender laspect dynamique dun systme, nous en citerons:
II-7-1 / Le prototypage
Quand on envisage de concevoir un nouveau systme, particulirement complexe et que la description de son futur fonctionnement est assez difficile, on adopte une technique dite de prototypage. Il sagit de dvelopper un prototype du systme partir dune description trs gnrale des besoins, ce qui permet de : - mettre en vidence les incomprhensions dveloppeur/utilisateur ; - dcouvrir les contradictions ; - servir de base lcriture de spcifications compltes. II- 1-1-1 / Prototype rapide ou maquette Un prototype rapide est utilis en amont du cycle de dveloppement, ce qui permet de valider des spcifications par exprimentation :
Analyse prliminaire des besoins
Analyse et slection de nouvelles fonctions

Etat non satisfaisant
Construction du prototype Evaluation exprimentation Expression claire des besoins rels
Etat satisfaisant
Spcifications dfinitives
15
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-1-1-2 / Prototype exprimental Il est utilis au niveau de la conception afin de valider des options de conception. Exemple : prototype dun analyseur syntaxique avec une grammaire rduite
Approfondissement
Spcification initiale Slection dune caractristique
Construction du prototype Evaluation Confirmation ou affinement des specs
NB : Ce prototype est en gnral jet aprs dveloppement, il peut aussi tre gard, on parle alors de Prototype volutif. II-1-1-3 / Prototype volutif La premire version du prototype est lembryon du produit final, on itre jusquau produit final. Exemple : Dveloppement dun systme expert Spcification de base Conception et ralisation
Mise en uvre et utilisation
Evaluation
Correction et amlioration
Nouvelle version
Version finale
16
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Un prototype peut tre ralis de deux manires : 1- En utilisant un langage : - Impratif : Perl, Shell, Java ; - Fonctionnel : ML, Lisp, Sheme ; - Dclaratif : Prolog ; - Spcifique un domaine : Exemple : programmation ractive : ESTEREL, SIGNAL, LUSTRE Exemple : modlisation de processus : SIMULA, QNAP2 2- Par assemblage de composants rutilisables Dans cette approche, il sagit de crer un prototype en assemblant (avec des mcanismes dassemblage) des composants logiciels rutilisables.
Ensemble de composants rutilisables
Spcification du systme
S-ensemble de composants rutilisables
Systme dassemblage de composants
Prototype excutable
Lassemblage de composants rutilisables
17
-----------------------------------------------------------------------------------------------------------------------------------------------------------
II-7-2 / Les rseaux de Petri

Les rseaux de Petri constituent un moyen formel de modlisation de systmes. Un rseau de Petri ( RdP ) est un graphe biparti compos de places et de transitions connectes par des arcs orients.
Df :
Un RdP marqu est dfini par le quintupl : Q = < P , T , Pr , Post , Mo > tel que : P : est un ensemble fini de places ; T : est un ensemble fini de transitions ; PT : ; Pr : P X T N est appele application dincidence avant ; Post : P X T N est appele application dincidence arrire ; Mo : P N est appel marquage initial ; N : est lensemble des entiers positifs ou nuls.
II 7-2-1/ Proprits des rseaux de petri II-7-2-1-1 / Notations et dfinitions Marquage dun RdP Le marquage dun RdP un instant donn est un vecteur colonne dont la valeur de la iime composante est le nombre de marques ( jetons ) dans la place Pi cet instant. Exemple de RdP : T1 2 P1 P2 2 P3 M= 0 2 0 T3
T2 T4 * Une place correspond une variable dtat du systme devant tre modlis. * Une transition correspond une action qui va entraner lvolution des variables dtat du systme. * Un arc relie soit une place une transition, soit une transition une place jamais une place une place ou une transition une transition.
18
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Evolution dun RdP Lvolution dun RdP correspond lvolution de son marquage au cours du temps : cela se traduit par un dplacement de marques ( jetons ), ce qui sinterprte comme la consommation / production de ressources dclenche par des actions. * Le marquage du rseau change quand une transition est franchie. * Une transition qui peut tre franchie est dite sensibilise ( franchissable ), ce qui veut dire que les conditions de son dclenchement sont satisfaites. * Une transition est sensibilise si chacune de ses places dentre contient un nombre dtermin de jetons.
T1
T1
Transition sensibilise *** Le franchissement dune transition consiste :
Transition non sensibilise
- retirer des jetons ( leurs nombres sont dtermins par les arcs entrant dans la transition ) des places en entre de la transition ; - ajouter des jetons chacune des places en sortie ( nombres dtermins par les arcs sortant de la transition ).
T1
T1
Avant le franchissement de T1 Aprs le franchissement de T1
* Une transition sans places dentre est dite transition source, elle est toujours sensibilise. * Une transition sans places de sortie est dite transition puits. * Le marquage, un moment donn, dfinit ltat du RdP et donc celui du systme dcrit par ce mme RdP.
19
-----------------------------------------------------------------------------------------------------------------------------------------------------------
* Lvolution de ltat correspond donc une volution du marquage, ce qui se traduit par le franchissement de transitions. Exemple : Etat initial P1 T1 P2 T2 2 T1 2
Aprs franchissement de T1
P1
P2
T2 2 T1 Aprs franchissement de T1 P1 T2 2 2 2
P2
Aprs franchissement de T2
P1
T1 P2 T2 2 2
Notation matricielle A un RdP sont associes deux matrices Pr et Post dont le nombre de lignes est gal au nombre de places et le nombre de colonnes est gal au nombre de transitions. Pr = Post = Wij + Wij avec Wij = Pr ( Pi, Tj ) + avec Wij = Post ( Pi,Tj )
20
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Squence de franchissement T1 T2 Si M M1 et M1 T1.T2 pour M et on note M M2
M2, on dit que la squence T1T2 est franchissable / S = T1T2 ( S : squence de franchissement ).
Vecteur caractristique Soit S le vecteur dont les composantes S (T) sont le nombre doccurrences des transitions dans une squence de franchissement. Ce vecteur est appel vecteur caractristique de S , sa dimension est gale au nombre de transitions du RdP considr. 2 Exemple : Soit S = T1T1T2, S (T)= 1 Les volutions du marquage dun RdP sont donnes par lquation : Si on pose : M = M Pr . S + Post . S Post Pr = C alors M = M+C S Equation fondamentale dun RdP
Ensemble des marquages accessibles Lensemble des marquages accessibles A (R ; M) dun RdP marqu est lensemble des marquages que lon peut atteindre partir dun marquage initial par une squence de franchissement. A( R ; M ) = Mi , S / M S Mi
NB: On note A( R; M ) ou *M. Ces marquages peuvent tre reprsents par un graphe o : La racine reprsente M0. Les noeuds restants sont des marquages tels que Mi et Mj sont relis par un arc sil existe une transition T franchissable permettant de passer de lun lautre des marquages. Les arcs du graphe sont tiquets par les transitions correspondantes. II-7-2-1-2 / Quelques proprits des RdPs Un RdP peut tre dcrit par un ensemble de proprits telles que la vivacit, le blocage, la bornitudeetc, ce qui permet de mieux cerner le systme dcrit par ce RdP.
21
-----------------------------------------------------------------------------------------------------------------------------------------------------------
- Rseau de Petri born Une place Pi est borne pour un marquage initial M0 si pour tout marquage accessible de M0, le nombres de jetons dans Pi reste born. Elle est dite K-borne si le nombre de jetons dans Pi est toujours infrieur ou gal k. Un RdP est (k) born si toutes ses places sont (k) bornes. - Vivacit et blocage Lvolution du marquage dun RdP se fait par franchissement de transitions. Lorsquau cours de son volution, certaines transitions ne sont jamais franchies, cela indique que lvnement associ la transition ne se produit pas et que le marquage dune partie du RdP nvolue pas. Il y a donc un problme au niveau de la conception du systme. Def : Une transition Tj est vivante pour un marquage initial M0 si pour tout marquage accessible Mk, il existe une squence de franchissement partir de Mk contenant Tj : Mk * M0, S, Mk / S > et S = Tj Si une transition Tj est vivante alors, tout instant, on sait que Tj peut tre franchie dans le futur. Dans le cas dun RdP modlisant un systme fonctionnant en permanence, si une transition nest pas vivante et si une fonction du systme est associe au franchissement de cette transition, cela veut dire qu partir dun certain instant, cette fonction ne sera plus disponible dans le futur, ce qui peut traduire une erreur ou une panne. Def : Un RdP marqu est vivant pour un marquage initial M0 si toutes ses transitions sont vivantes pour ce marquage initial. Def : Un blocage ( ou tat puits ) est un marquage pour lequel aucune transition nest valide. Un RdP marqu est dit sans blocage pour un marquage initial M0 si aucun marquage accessible nest un blocage. II-7-2-1-3/ Structures fondamentales pour la modlisation des systmes Les RdPs permettent de modliser un certain nombre de comportements importants dans les systmes. a- Paralllisme Le paralllisme reprsente plusieurs processus qui voluent simultanment au sein dun mme systme. On peut provoquer le dpart simultan de lvolution de deux processus laide dune transition ayant plusieurs places de sortie.
22
-----------------------------------------------------------------------------------------------------------------------------------------------------------
P1 T1
P2
P3
Le franchissement de la transitionT1 met une marque dans la place P2 ( ce qui marque le dclenchement du processus 1 ) et une marque dans la place P3 ( ce qui marque le dclenchement du processus 2 ). Il est ensuite possible de synchroniser lachvement des deux processus.
P22
P23 T12 P24
La place P22 correspond la fin du processus 1 et la place P23 la fin du processus 2. Le RdP voluera par franchissement de la transition T12. Pour cela, il est ncessaire que les places P22 et P23 contiennent chacune au moins un jeton, c'est--dire que les processus 1 et 2 soient termins.
23
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Le RdP total est reprsent comme suit :
P1 T1
P2
P3
P22
P23 T12 P24
b- Synchronisation b-1- Mutuelle La synchronisation mutuelle ou rendez-vous permet de synchroniser les oprations de deux processus.
P12 T7 P13 Processus1
P6
P7 Procesus2
24
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Le franchissement de la transition T7 ne peut se faire que si la place P12 du processus 1 et la place P6 du processus 2 contiennent chacune au moins une marque. Si ce nest pas le cas, par exemple, la place P12 ne contient pas de marque, le processus P2 est bloqu sur la place P6 : il attend que lvolution du processus 1 soit telle quau moins une marque apparaisse dans la place P12. b-2- Smaphore Les oprations du processus 2 ne peuvent se poursuivre que si le processus 1 a atteint un certain niveau dans la suite de ses oprations. Par contre, lavancement des oprations du processus 1 ne dpend pas de lavancement des oprations du processus 2.
P13 T17 P14 Processus 1 P0
P6 T7 P7 T8 Processus 2
Le processus P2 ne peut franchir la transition T8 que si la place P0 contient au moins une marque. Une marque est ajoute la place P0 lorsque lvolution du processus P1 amne le franchissement de la transition T17. Lvolution du processus P2 va donc dpendre de lvolution du processus P1. c- Partage de ressources Cette structure modlise le fait quau sein du mme systme plusieurs processus partagent une mme ressource.
P12 T17 P13 T18 Processus 1 P0
P6 T7 P7 T8 Processus 2
25
-----------------------------------------------------------------------------------------------------------------------------------------------------------
La marque dans la place P0 reprsente une ressource mise en commun entre le processus 1 et le processus 2. Le franchissement de la transition T17 lors de lvolution du processus entrane la consommation de la marque prsente dans la place P0. La ressource que constitue cette marque nest alors plus disponible pour lvolution du processus 2 puisque le franchissement de la transition T7 nest plus possible. Lors de lvolution du processus P1, lorsque la transition T18 est franchie, une marque est alors redonne la place P0 : la ressource redevient alors disponible pour lvolution des deux processus. d- Capacit limite P3 T3 P5 P4 T4
Pour que la transition T3 soit franchissable, il est ncessaire que la place P5 contienne des marques. Dans lexemple, le marquage de P5 ne permet que deux franchissements successifs de T3. La transition sera nouveau franchissable si le franchissement de la transition T4 permet de mettre des marques dans la place P5. Au total, la place P4 ne pourra pas contenir plus de 3 marques. Cette partie de RdP peut modliser un stock de capacit totale gale 3 : do le nom capacit limite. Le marquage de P5 indique le nombre demplacements libres dans le stock, le marquage de P4 le nombre demplacements occups. Le franchissement de la transition T3 sinterprte alors comme la mise dun lment dans le stock ; le franchissement de la transition T4 comme le retrait dun lment du stock. II-7-2-1-4/ Modlisation structure Lors de la construction du modle RdP dun systme dune grande complexit, il est ncessaire de procder par des tapes. Deux approches sont ainsi possibles : Approche par raffinements successifs Dans une premire tape, le systme est dcrit par un RdP simplifi. Les transitions sont alors associes des actions/vnements complexes qui seront, dans une seconde tape, remplaces par des RdPs les dcrivant.
26
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Approche par compositions de RdPs Un systme complexe peut tre dcompos en sous-systmes. Chaque sous systme est alors modlis par un RdP. Le RdP du systme complet est alors obtenu en assemblant les RdPs des diffrents sous systmes. Lassemblage peut se faire selon deux approches ; 1- par fusion des places communes aux diffrents RdPs ; 2- par fusion de transitions communes aux diffrents RdPs : cela traduit par exemple que les sous systmes voluent sous loccurrence des mmes vnements.
II-7-3 / Lapproche oriente objet

Lapproche oriente objet considre un systme ( logiciel ) comme un ensemble dobjets dissocis dfinis par des proprits. Une proprit est soit un attribut ou une opration. Un attribut est une entit lmentaire (donne) de la description de ltat de lobjet. Une opration est une entit lmentaire de la description du comportement de lobjet. Un objet comprend donc la fois une structure de donnes (sous forme dun ensemble dattributs) et un ensemble doprations qui expriment son comportement. Un objet est caractris par - un identificateur (nom de lobjet) ; - un tat (sous forme dun ensemble dattributs) ; - un comportement (un ensemble doprations). Les objets doivent dans la mesure du possible reposer sur les entits du monde rel et des concepts de lapplication ou du domaine concerns. II-7-3-1 / Concepts de base de lA.O.O Lapproche oriente objet se base sur un ensemble de concepts : Identit Le principe de lidentit stipule quun objet est une entit discrte et distincte. Un objet se distingue mme des autres objets ayant les mmes caractristiques : deux vhicules de la mme marque, de la mme srie et ayant exactement les mmes options sont deux objets distincts. Un objet peut tre concret tel un fichier, un vhicule donn ou conceptuel tel une politique dordonnancement ou les performances du vhicule. La dfinition dobjet sappuie largement sur les principes dabstraction et dencapsulation. Labstraction Labstraction consiste identifier les caractristiques intressantes dune entit en vue dune utilisation prcise. Cela signifie que lon se concentre sur ce quest un objet et ce quil fait en mettant laccent sur ses proprits essentielles inhrentes au domaine dapplication, tout en ignorant les dtails dimplmentation. Les abstractions doivent tre compltes, cest dire renfermer toutes les proprits essentielles de la chose dcrite.
27
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Lencapsulation Lencapsulation signifie que les donnes ainsi que les mthodes permettant de les manipuler, sont contenues dans un mme emballage (objet) et que laccs aux donnes associes cet objet ne peut pas se faire directement, la seule faon de le faire est de lui envoyer un message qui dclenche lexcution de lune de ses mthodes. Mthodes et Messages Les changements dtat dun objet sont effectus au moyen dactions lmentaires sur les valeurs des attributs de ce mme objet. Ces actions lmentaires sont regroupes en un ensemble de mthodes. Ces dernires sont actives par des messages et peuvent elles-mmes en activer dautres. Les messages constituent le moyen de communication entre objets. Ceci garantit que les changements intervenant dans les structures de donnes encapsules dans les objets ne propagent pas leurs effets dautres parties du systme. Exemple : La rserve des billets 5 : sortir des billets 3 : retirer de l argent Le distributeur 2 : lire N compte 4 :dbiter La carte de X Le compte de X
1 : retirer
La banque
Classification La classification signifie le regroupement dobjets de mme nature (mme description dtat, mme comportement) dans une classe. Ainsi, une classe est un modle, un moule qui permet dinstancier plusieurs objets. Chaque objet est une instance de la classe.
28
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Compte Classe numro solde dcouvert Consulter Crditer Dbiter
Le compte de X numro= 4200 solde= 5000 dcouvert= -500 ----------Consulter Crditer Dbiter objets ou instances de la classe
Le compte de Y numro= 8003 solde= 1000 dcouvert= -200 Consulter Crditer Dbiter
Hritage Lhritage permet un partage hirarchique des proprits (attributs et oprations). Une sousclasse peut hriter des proprits dune classe dite super-classe. Gnralement, une superclasse dfinit les grands traits dune abstraction, une sous-classe hrite de cette dfinition tout en laffinant de deux faons possibles : - en ajoutant des attributs ; - en ajoutant des mthodes ou en redfinissant des mthodes dj dfinies dans la superclasse . Lorsquune classe hrite dune seule super-classe, on dit que lhritage est simple. On parle dhritage multiple quand il y a deux ou plusieurs super-classes pour une mme sous-classe. Exemple dhritage simple : Personne
Homme
Femme
29
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Exemple dhritage multiple : Appareil
Chauffage
Appareil lectrique
Poele Mazout
Chauffage lectrique
Four micro-ondes
Lhritage peut tre tabli de deux manires : Gnralisation : qui consiste regrouper les aspects communs dans une super-classe ( approche de bas en haut ). Spcialisation : qui sobtient par laffinement de classes en sous-classes ( approche de haut en bas ). Gnricit La gnricit consiste dfinir des classes paramtrables en fonction dun type. Supposons une classe gnrique List pouvant contenir des lments de type arbitraire <T>. On peut dclarer des listes spcifiques par lintermdiaire dune drivation. Par exemple : List < Integer > // une liste dentiers List < Char > // une liste de caractres Agrgation Une agrgation est une forme de relation binaire qui spcifie une relation dinclusion entre une partie et une autre. Une relation dagrgation est transitive et antisymtrique. Les parties peuvent ou non exister indpendamment de lagrgation ou peuvent apparatre dans diffrentes agrgations. Exemple : Socit Division Service
Une socit est une agrgation de divisions, qui sont leur tour des agrgations de services. Une socit est donc indirectement une agrgation de services.
30
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Composition Une composition est une forme forte dagrgation, elle a plus de smantique et correspond un confinement physique et des notions dappartenance. Un objet compos est lui-mme compos dun ensemble dobjets qui nont de sens qu lintrieur de la composition. Polymorphisme Le polymorphisme permet une sous-classe doutrepasser limplmentation dune mthode hrite dune super-classe. Il consiste , tout en gardant le mme nom pour une mthode hrite, associer un code spcifique ( tenant compte des proprits locales de la classe ) qui vient ainsi se substituer celui de la mthode hrite. Lorsque la mthode est appele, lutilisateur ( humain ou un autre objet ) na pas besoin de connatre quelle est limplmentation prcise slectionner puisque le systme se charge de slectionner le code qui est appropri pour la classe en question. Surcharge : consiste changer limplmentation dune proprit hrite. Une opration redfinie peut prendre diffrentes implmentations en fonction du type dobjet auquel elle sapplique. Lopration est dite polymorphe. Exemple : Figure Surface ( )
Cercle Surface ( )
Polygone Surface ( )
Lopration Surface a t redfinie dans les classes Cercle et Polygone pour prendre en compte les attributs propres de chaque forme gomtrique.
II-7-3-2 / Le gnie logiciel orient objet Lapproche oriente objet ( A.O.O ) considre le logiciel comme une collection dobjets dissocis et identifis, dfinis par des proprits. La fonctionnalit du logiciel merge alors de linteraction entre les diffrents objets qui le constituent. La conception oriente objet ( C.O.O ) est la mthode qui conduit des architectures logicielles fondes sur les objets du systme, plutt que sur la fonction quil est sens raliser. Notons par ailleurs que les mthodes dun objet sont des fonctions. Lorsque la programmation par objets prend de limportance au dbut des annes 1990, la ncessit dune mthode qui lui soit adapte devient vidente. Plus de cinquante mthodes apparaissent entre 1990 et 1995 ( FUSION, HOOD, OMT, OOA, OOD, OOM, OOSE..), mais aucune ne parvient simposer. 31
-----------------------------------------------------------------------------------------------------------------------------------------------------------
En 1994, le consensus se fait autour de trois mthodes : * OMT de James Rumbaugh ( General Electric ) : fournit une reprsentation graphique des diffrents aspects dun systme ; * OOD de Grady Booch, dfinie par le department of Defense : introduit le concept de paquetage ( package ) ; * OOSE dIvar Jacobson ( Ericson ) fonde lanalyse sur la description des besoins des utilisateurs ( cas dutilisation ou Use Cases ). Chaque mthode ayant ses avantages, un accord ft trouv pour dfinir une mthode commune qui fdrerait leurs apports respectifs, UML est ne de cet effort de convergence. UML, comme son nom lindique, na pas lambition dtre exactement une mthode , cest plutt un langage. Prsentation brve : UML est un langage graphique qui permet de reprsenter les diffrents aspects dun systme dinformation. Aux graphiques sont associs des textes qui expliquent leurs contenus. UML 2.0 comporte treize types de diagrammes reprsentant autant de vues distinctes pour reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands groupes : 1 2 Diagrammes structurels ou diagrammes statiques ( UML structure ) Diagramme de classes ( Class diagram ) Diagramme dobjets ( Object diagram ) Diagramme de composants ( Component diagram ) Diagramme de dploiement ( Deployment diagram ) Diagramme de paquetage ( Package diagram ) Diagramme de structure composite ( Composite structure diagram ) Diagrammes comportementaux ou diagrammes dynamiques ( UML Behaviour ) Diagramme de cas dutilisation ( Use Case diagram ) Diagramme dactivits ( Activity diagram ) Diagramme dtats-transitions ( State machine diagram ) Diagrammes dinteraction ( Interaction diagram ) - Diagramme de squence ( Sequence diagram ) - Diagramme de communication ( communication diagram ) - Diagramme global dinteraction ( Interaction overview diagram ) - diagramme de temps ( Timing diagram ) Ces diagrammes dune utilit variable selon les cas, ne sont pas ncessairement tous produits loccasion dune modlisation. Diagramme de cas dutilisation Le diagramme de cas dutilisation reprsente la structure des grandes fonctionnalits ncessaires aux utilisateurs du systme. Cest le premier diagramme du modle UML, celui o sassure la relation entre lUT et les objets que le systme met en uvre. 32
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Diagramme de classes Le diagramme de classes est gnralement considr comme le plus important dans un dveloppement orient objet. Il reprsente larchitecture conceptuelle du systme : il dcrit les classes que le systme utilise ainsi que leurs liens. Diagramme dobjets Le diagramme dobjets permet dclaircir un diagramme de classes en lillustrant par des exemples. Il est, par exemple, utilis pour vrifier ladquation dun diagramme de classes diffrents cas possibles. Diagramme dtats-transitions Le diagramme dtats-transitions reprsente la faon dont volue ( cycle de vie ) les objets appartenant une mme classe. La modlisation du cycle de vie est essentielle pour reprsenter et mettre en forme la dynamique du systme. Diagramme dactivits Le diagramme dactivits montre lenchanement des activits qui concourent au processus. Diagramme de squence et de communication Le diagramme de squence reprsente la succession chronologique des oprations ralises par un acteur. Il indique les objets que lacteur va manipuler et les oprations qui font passer dun objet lautre. On peut reprsenter les mmes oprations par un diagramme de communication, graphe dont les nuds sont des objets et les arcs ( numrots selon la chronologie ) les changes entre les objets. En fait, diagramme de squence et diagramme de communication sont deux vues diffrentes mais logiquement quivalentes ( on peut construire lune partir de lautre ) dune mme chronologie. Ce sont des diagrammes dinteraction. *** UML nimpose pas de mthode de travail particulire, il peut tre intgr nimporte quel processus de dveloppement logiciel de manire transparente. Son indpendance par rapport aux langages de programmation, aux domaines dapplication et aux processus, en font un langage universel.
33
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III / Cycle de vie dun logiciel

III 1 / Introduction :
Le dveloppement de logiciels a longtemps souffert dun certain nombre de problmes tels que : La qualit moyenne, souvent mdiocre, des logiciels produits. Le nom respect des dlais prvus pour le dveloppement de logiciels satisfaisant leurs cahiers des charges. Linvisibilit du logiciel, ce qui veut dire quon saperoit souvent que le logiciel dvelopp ne correspond pas la demande ( on ne peut lobserver quen lutilisant ( trop tard ! )). Le but du gnie logiciel est justement de remdier ces problmes, mais avant cela, dfinissons ce quest un logiciel.
Quest ce quun logiciel ? Le logiciel est lensemble des programmes, procds et rgles, et ventuellement de la documentation, relatifs au fonctionnement dun ensemble de traitement de linformation. (arrt du 22 dc 1981 ) . Autrement dit, un logiciel est un ensemble de programmes informatiques ( du code ) mais galement un certain nombre de documents se rapportant ces programmes et ncessaires leur installation, utilisation, dveloppement et maintenance : spcification, schmas conceptuels, jeux de tests, mode demploi etc. Notons que lobjectif de la documentation est de permettre la transmission dinformation, rendre visible le produit logiciel tout au long du cycle de vie. La documentation est produite au fur et mesure du dveloppement du projet. III 2 / Qualits exiges dun logiciel :
Si le gnie logiciel est lart de produire de bons logiciels, il est donc ncessaire de fixer les critres de qualit dun logiciel. La validit : Cest laptitude dun produit logiciel remplir exactement ses fonctions, dfinies par le cahier des charges et les spcifications. La fiabilit (ou robustesse) : Cest laptitude dun produit logiciel fonctionner dans des conditions anormales ( quelque soit lentre par exemple ). Lextensibilit : Cest la facilit avec laquelle un logiciel se prte une modification ou une extension des fonctions qui lui sont demandes. La rutilisabilit: Cest laptitude dun logiciel tre rutilis, en tout ou en partie, dans de nouvelles applications.
34
-----------------------------------------------------------------------------------------------------------------------------------------------------------
La compatibilit : Cest la facilit avec laquelle un logiciel peut tre combin avec dautres logiciels. Lefficacit : On dit dun logiciel quil est efficace sil utilise les ressources dune manire optimale. La portabilit : Cest la facilit avec laquelle un logiciel peut tre transfr sous diffrents environnements matriels et logiciels ( produit indpendant du genre denvironnement ) . Lintgrit : Cest laptitude dun logiciel protger son code et ses donnes contre des accs non autoriss. La facilit demploi : Elle est lie la facilit dapprentissage, dutilisation, dinterprtation des erreurs et de rattrapage en cas derreur dutilisation., on parle dinterface ergonomique. La maintenabilit : Elle correspond au degr de facilit de la maintenance dun produit logiciel.
III-3 / Activits principales du processus de dveloppement dun logiciel

Quelque soit lapproche adopte pour dvelopper un logiciel, on y retrouve un certain nombre dactivits de base : III-3-1 / Lanalyse des besoins Il sagit dtudier : - Le domaine dapplication - Ltat actuel de lenvironnement du futur logiciel afin de dterminer les ressources disponibles et requises, les contraintes dactivation et de performance.etc. But : viter de dvelopper un logiciel non adquat. Rsultat : Un ensemble de documents dcrivant : - Les aspects importants de lenvironnement du futur systme ainsi que son rle et son utilisation. ( le cahier des charges ). - possibilit de produire un manuel dutilisation prliminaire. Le rsultat de cette phase est obtenue grce un dialogue avec les utilisateurs et les spcialistes du domaine ( pas ncessairement des informaticiens ). III-3-2 / La spcification globale ( fonctionnelle ) du logiciel En se basant sur les besoins noncs par le client et sur des considrations techniques et de faisabilit informatique, cette tape consiste dfinir ce que le logiciel doit faire ( le quoi ). But : tablir une premire description du futur systme. Rsultats : - Un document qui contient les spcifications du logiciel. - Eventuellement, une premire version du manuel de rfrence ainsi que des complments au manuel dutilisation.
35
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-3-3 / La conception architecturale Il sagit, une fois les spcifications labores, de dfinir une solution en identifiant larchitecture du logiciel. La conception architecturale ( prliminaire ou globale ) consiste donc identifier les diffrents composants du logiciel. Pour chacun des composants, on prcise les interfaces et les fonctions. Rsultat : - Une description de larchitecture du logiciel. III-3-4 / La conception dtaille Cette phase consiste dcrire pour chaque composant, les donnes manipules ( reprsentation) et la manire dont les fonctions du composant sont ralises ( les algorithmes ). En plus, des tests unitaires sont dfinis pour sassurer que les composants raliss sont bien conformes leurs descriptions. Rsultat : pour chaque composant, le rsultat consiste en : - Un dossier de conception dtaille. - Un dossier de tests unitaires. - Un dossier de dfinition dintgration logiciel. NB : la frontire entre la spcification et la conception est souvent floue car il nest pas raisonnable de spcifier un systme indpendamment de toute considration de faisabilit. III-3-5 / La programmation ( le codage ) Cette tape correspond au codage des donnes et des algorithmes agissant sur ces donnes, dans un langage de programmation. III-4-6 / Les tests unitaires du logiciel Il sagit dexcuter pour chaque composant logiciel, les jeux dessais dfinis dans le dossier des tests unitaires. Les rsultats des tests sont enregistrs dans des documents. III-4-7 / Lintgration et les tests dintgration Il sagit dassembler les parties dun logiciel pour obtenir un systme excutable. Cela se fait par niveaux successifs en respectant le plan dintgration du logiciel ( dfini dans ltape de la conception dtaille ). La phase dintgration ressemble une construction o chaque brique de base du logiciel est associe sa voisine pour former une entit elle-mme associe sa voisineetc jusqu aboutir la construction toute entire. En plus, les jeux dessais dfinis prcdemment sont excuts. III-4-8 / La validation du logiciel : La validation a pour but de rpondre la question : a t-on dcrit le bon systme, celui qui rpond lattente de lutilisateur ? Elle consiste donc montrer que le logiciel dvelopp rpond exactement aux besoins exprims pas le dossier du logiciel. Le moyen de le faire est dinspecter des spcifications, linspection tant une lecture critique dun document ( spcification, conception, code, plan dintgrationetc ), ou par le biais du prototypage rapide.
36
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-4-9 / La vrification La vrification a pour but de rpondre la question : Le dveloppement, est-il correct par rapport la spcification globale ? Elle consiste donc sassurer que les descriptions successives du logiciel, et en finalit, le logiciel lui-mme, satisfont la spcification globale. Le moyen de le faire est dinspecter des spcifications et des programmes ainsi que la preuve et le test. Preuve ? La preuve porte sur une spcification dtaille on un programme et permet de prouver que celle-ci satisfait bien la spcification de dpart. Test ? Le test consiste rechercher des erreurs dans une spcification ou dans un programme. Cette recherche peut se faire par : ou examen ou analyse du texte ( test statique ) des excutions sur un sous ensemble fini de donnes possibles ( test dynamique ). NB : Le test est toujours utilis alors que la preuve est rserve aux systmes critiques. III-4-10 / Le maquetage ( prototypage rapide ) : Quand les besoins ne sont pas prcis, lactivit de validation devient difficile, pour cela, on adopte la solution du maquetage, il sagit de : - dvelopper un programme qui est une bauche du futur logiciel ( il nen a pas les performances ni toutes les fonctionnalits dun produit fini ). - Le soumettre des scnarios en liaison avec les futurs utilisateurs afin de prciser leurs besoins. Remarque : Le maquetage peut aussi intervenir lors dune tape de conception : des choix diffrents peuvent tre expriments et compars au moyen de maquettes ( dans ce cas, on parle de prototypage exprimental ). III-4-11 / La gestion des configurations La gestion des configurations permet de matriser lvolution et les mises jour du logiciel tout au long du processus de dveloppement : identifier ce qui compose le dveloppement (matriel et logiciels ( donc documents compris ) ) ; suivre lvolution de ces composants ( versions ) ; assurer la cohrence entre les diffrents composants. Remarque : Lactivit dintgration utilise la gestion des configurations pour assembler des versions cohrentes de chaque composant. Il existe un certain nombre doutils de gestion de version et de configuration tels que :SSCS, RCS, CVS ).
37
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III 4 / Modles de cycle de vie

Le processus de dveloppement de logiciel dsigne lensemble des activits ncessaires au dveloppement et la maintenance dun logiciel. Il sagit dun processus variable ( selon le type dapplication ) et complexe, compos de diffrentes phases interdpendantes. Ce processus consiste tablir une suite de descriptions de plus en plus prcises et de plus en plus proches dun programme excutable et de sa documentation. Notons, cependant, que le processus de dveloppement de logiciel est itratif : certaines tapes dclenchent la rvision du rsultat des tapes prcdentes. Il existe plusieurs approches ( modles ) de dveloppement de logiciels, nous en citerons les suivantes : III-4-1 / Le modle en cascade ( Watterfall model ) Ce modle de dveloppement est constitu dun ensemble dtapes, chacune delle se terminant une date prcise par la production de certains documents logiciels. On ne passe ltape suivante que si les rsultats de ltape en cours sont jugs satisfaisants.
Faisabilit
validation
Analyse des besoins

validation correction
Conception
vrification
correction
Conception dtaille
vrification
correction
Codage
test unitaire
correction
Intgration
test dacceptation
correction
Installation
test systme
correction
Version actuelle du modle en cascade
Exploitation et maintenance
38
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Notons que le modle original ne comportait pas de possibilit de retour en arrire, ce qui a t rajout par la suite. 1- Etudier la faisabilit du projet. 2- Dfinir : - Les services - Les contraintes - Les buts
du logiciel.
3- et 4- Reprsenter les diffrentes fonctions ( ensemble de composants ). 5- Implmenter les composants ( + tests unitaires ). 6- Intgrer les diffrents programmes en un ensemble complet ( + tests dintgration et tests dacceptation ). 7- Installer le logiciel (+ test systme ). 8- Exploiter ( mettre en uvre ) le logiciel et le maintenir. Avantages : + Il y a du test aprs chaque phase (on vrifie les spcifications, la conception ). Inconvnients : - Le modle repose lourdement sur la capacit dresser les besoins ds le dbut, ce qui nest pas une tche facile ; - Les problmes dans la spcification sont souvent dtects tardivement, au moment des tests, voire au moment de la livraison du logiciel lutilisateur ; - Le procd peut prendre beaucoup de temps avant que la premire version qui tourne ne soit produite. *** Ce modle est seulement applicable pour les projets qui sont bien compris et matriss. III-4-2 / Le modle par prototypage Le prototypage est galement considr comme un modle de dveloppement de logiciels. Il sagit dcrire une premire spcification et de raliser un sous-ensemble du produit logiciel final. Ce sous ensemble est alors de plus en plus raffin et valu jusqu obtenir le produit final. Spcification schmatique Ralisation du prototype Utilisation du logiciel
Logiciel adquat
oui Acceptation du logiciel
non Livraison du logiciel Remarque : Lvaluation du prototype consiste lutiliser et vrifier son adquation au logiciel dsir.
39
-----------------------------------------------------------------------------------------------------------------------------------------------------------
*** Ce modle de dveloppement est utilis lorsque les besoins ne sont pas clairs. III-4-3 /Le modle en V : Le principe de ce modle est quavec toute dcomposition, doit tre dcrite la composition et que toute description dun composant est accompagne de tests qui permettent de sassurer quil correspond sa description ( vrification + validation ). Analyse des besoins Installation et test systme
Spcification * dossier de spcif du log * Manuel ( Inst /Ut ) Conception Architecturale
Test dacceptation du logiciel
Intgration et * dossier test dintgration des tests dacceptation
* dossier de conception gnrale * dossier provisoire de tests dintgration Conception dtaille Tests unitaires * listage des composants tests * dossier des tests dintgration
* dossier de conception dtaille * dossier provisoire de tests unitaires Programmation
* listage du code * dossier des tests unitaires
Notons que dans ce modle, les premires tapes du dveloppement prparent les dernires tapes. La premire branche correspond un modle en cascade classique mais avec des sorties correspondant des descriptions de plus en plus raffines, accompagnes de dfinitions de tests sur ces mmes descriptions. Avec les jeux de tests prpars dans la premire branche, les tapes de la deuxime branche peuvent tre mieux prpares et planifies.
40
-----------------------------------------------------------------------------------------------------------------------------------------------------------
La flche en gras signifie quune partie des rsultats de ltape de dpart est directement utilise par celle darrive. Par exemple, lissue de la conception architecturale, le protocole dintgration et les jeux de test d intgration doivent tre compltement dcrits. La seconde branche correspond des tests effectifs effectus sur des composants raliss. Lintgration est ensuite ralise jusqu' lobtention du systme logiciel final. Avantages : + Eviter dnoncer une proprit quil est impossible de vrifier objectivement une fois le logiciel ralis. + Permet une meilleure anticipation ; + Evite les retours en arrire. Inconvnients : - Les cots provoqus par lchec dun test sont proportionnels au temps coul jusqualors. *** Ce modle est le plus utilis particulirement pour les systmes embarqus. III-4-4 / Le modle en spirale Le modle en spirale (propos en 1988) insiste particulirement sur lanalyse des risques tels que les exigences dmesures par rapport la technologie, la rutilisation de composants, calendriers et budgets irralistes, la dfaillance du personnel .etc. 1 Analyse des risques 2 Planification
Prototypage Analyser Concevoir Coder Revoir et superviser 4 Faites le 3
Une version moderne du modle en spirale de Boehm Chaque cycle se droule en quatre phases : 1/ Enqute et examen de la situation existante (objectifs, alternatives, contraintes) dans lentreprise, en prenant soin de bien prendre en compte les systmes existants. La situation doit tre mesure de faon pouvoir valuer les risques existants.
41
-----------------------------------------------------------------------------------------------------------------------------------------------------------
2/ Si le poids des risques positifs est plus important, la phase suivante consiste alors tablir (planifier) ce qui doit tre fait. Il peut y avoir une tape de prototypage pour ventuellement choisir entre plusieurs solutions. 3/ La ralisation de la solution ncessite la mise en uvre dun mini processus en cascade. 4/ La situation est ensuite rvalue pour dterminer si un dveloppement supplmentaire est ncessaire, auquel cas il faudrait planifier la prochaine tape. Avantage : + Rduit les risques sil est bien appliqu. Inconvnient : - Augmente considrablement les risques si le contrle faiblit. *** Ce modle est utilis pour des projets innovants, risques, et dont les enjeux sont importants. III-4-5 / Le modle par incrment Ce modle prend en compte le fait quun logiciel peut tre construit tape par tape. Le logiciel est spcifi et conu dans son ensemble. La ralisation se fait par incrments de fonctionnalits. Chaque incrment est intgr lensemble des prcdents ( le processus de dveloppement de chaque incrment ( composant ) est un processus classique ) et chaque tape, le produit est test exploit et maintenu dans son ensemble. Avantages : + Dans ce modle, les intgrations sont progressives et il peut y avoir des livraisons et des mises en service aprs chaque intgration dincrment ; + En consquence, le modle permet de faire accepter progressivement un logiciel par les utilisateurs plutt que de faire un changement brutal des habitudes. Inconvnients : - La possibilit de remise en cause du noyau et des incrments prcdents. De mme, la possibilit de ne pas pouvoir intgrer dautres incrments, do il est ncessaire de dfinir les incrments, le plus indpendant possible, au dbut du projet et ce de faon globale. Exemple : Un scheduler ( ordonnanceur ) ou un gestionnaire de fichiers peuvent constituer des incrments dun systme dexploitation.
42
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5 / Dtails des diffrentes phases du processus de dveloppement dun logiciel III-5-1 / Analyse des besoins
Cette tape permet dtablir les fonctionnalits que le systme doit fournir et les contraintes auxquelles il sera soumis. Les exigences fonctionnelles : les services (fonctions) attendus. non fonctionnelles : les contraintes ( performance, portabilit) ainsi que les standards utiliss. Le rsultat de cette phase est obtenue grce un dialogue avec les utilisateurs et les spcialistes du domaine ( pas ncessairement des informaticiens ). Il en rsulte un cahier des charges qui servira de base pour valider la conception et supporter la maintenance. Il est essentiel que le cahier des charges soit bien structur et organis de faon ce quil puisse voluer facilement. En plus, les besoins exprims ne doivent pas tre conflictuels. Gnralement, un cahier des charges comprend, entre autres, ce qui suit : Introduction : comprend : - la raison dtre dun tel logiciel ; - un rsum du logiciel. Besoins fonctionnels : dcrit les services offerts lutilisateur. Besoins non fonctionnels : dcrit les contraintes oprationnelles imposes au logiciel. Exemple : Le temps de rponse de toute commande ne doit pas dpasser N secondes. Besoins en bases de donnes: existantes ou crer. Evolution du systme : dcrit principalement les changements prvus du fait de lvolution du matriel ainsi que des besoins des utilisateurs. Glossaire : dcrit les termes techniques utiliss. NB : On parle de spcification des besoins quand les dfinitions sont plus prcises. Pour ce faire, on utilise des techniques semi-formelles telles que les diagrammes de classes, les diagrammes de cas dutilisationetc.
III-5-2 / Spcification du logiciel

III-5-2-1 / Spcifier un logiciel La spcification dun logiciel est la partie du processus de conception dans laquelle on sexprime un haut niveau dabstraction. La spcification est la construction dune reprsentation informatique abstraite dun ensemble dexigences de lutilisateur . Les spcifications peuvent tre en langage naturel, mais lambigut de celui-ci constitue un problme srieux. Notons quune spcification doit tre claire et prcise, ce qui a ncessit llaboration dun certain nombre de mthodes.
43
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5-2-2 / Mthodes de spcifications III-5-2-2-1 / Lanalyse structure Lanalyse structure, mthode cre par Edward Yourdon et Tom Demarco en 1978-79, est une approche fonctionnelle de spcification de logiciels. Elle est descendante par raffinements successifs des traitements ( processus ). Elle utilise des outils graphiques et / ou textuels. 1- Les diagrammes de contextes de donnes ( DCDs ) Lobjectif est dexposer le but principal du systme et didentifier les entits extrieures avec lesquelles il doit communiquer. Le diagramme est compos de : - un processus unique ; - terminaisons ; - donnes dentre / sortie du systme. Entit extrieure1 Entit extrieure2
Entre1
Entre2
Sortie1
Processus unique
2- Les diagrammes de flots de donnes ( DFDs ) Un DFD est un rseau dinterconnexion de fonctions ( processus ) relies par les donnes qui circulent. Un DFD montre comment chaque processus transforme ses entres successives ( flots de donnes entrants ) en sorties correspondantes ( flots de donnes sortants ). Les DFDs contiennent galement les stockages de donnes ( dpt , fichier , .) qui sont des regroupements de donnes utilisables par tout processus.
44
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Traitement principal
1
2 4
Raffinements successifs des traitements Les derniers niveaux non dcomposs, sont attachs des spcifications qui expriment des traitements lmentaires. Les composants du diagramme sont : : Unit de travail ralisant une transformation de donnes dentre en donnes de sortie . : Vecteur nomm reliant deux traitements et sur lequel circule un ensemble de donnes de mme nature . ou : Unit de stockage ( BDS , fichier .) : source ou destination des donnes (entit externe , personne ou priphrique).
Exemple: Le processus Evaluation permet de prendre en compte des critres obtenus partir du flux entrant des critres de slection pour valuer une proposition range dans la zone de stockage Proposition par rapport un projet rang dans la zone de stockage Projet. La note attribue ( flux sortant Note) est range dans la zone de stockage Proposition .
45
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Proposition Saisie Proposition soc service Note Critres de Slection Evaluation Projet Refus Lettre de refus Lettre dacceptation
Acceptation
3- Le dictionnaire de donnes ( DD ) Le DD , cr et interprt en mme temps que le DFD contient la description de toutes les donnes prsentes dans le systme. Symbole signification = + max rptition, suite de (au moins, au plus ). min * : : * commentaire : : est compos de squence
Exemple : Fichier tudiant : 14 Nom : 1
enregistrement tudiant
caractres alphabtiques
canal : * numro du bit du bus du microprocesseur * 4- les diagrammes de structures de donnes ( DSDs ) Ce sont des diagrammes hirarchiss montrant les relations structurels des composants dun systme. Autrement dit, ils permettent de dcrire larchitecture ( relation structurelle des
46
-----------------------------------------------------------------------------------------------------------------------------------------------------------
composants ) dun systme , comme une hirarchie de composants et la prsentant sous forme dune structure arborescente, lire de gauche droite. Exemple : N tl indicatif numro N tl = ind + num 5- Spcification de processus ( PSPEC ) Si un niveau donn , un processus de transformation est jug simple , on lui associe une fiche de spcification appele PSPEC qui donne les grandes lignes de lalgorithme de traitement appliqu par le processus pour transformer les flots de donne en entre ,en flots de donnes en sortie. Dans le cas contraire, il sagit dun processus complexe et il doit faire lobjet dun autre niveau de dcomposition. Pour une PSPE, un ensemble doutils de spcification peut tre utilis tels que : les algorithmes abstraits ; les tables de dcisions ; les diagrammes de Michael Jackson. . . En utilisant les lments prcdents, il est possible de donner un schma gnral du futur systme. Cependant, pour traiter les contraintes de temps et de synchronisation il existe dautres mthodes dont lanalyse structure temps rel. III-5-2-2-2 / Lanalyse structure temps rel La mthode SA-RT ( Structured Analysis Real Time ) introduit des CFDs ( diagrammes de flot de contrle ) et des spcifications de contrle qui permettent de reprsenter les informations qui activent ou dsactivent les processus ( traitements ) reprsents dans les DFDs. La mthode SA-RT introduit galement des contraintes de temps. 1- Diagramme de contexte de contrle Lobjectif est de reprsenter les vnements contrlant lactivation du systme. Le diagramme est compos de : - un processus unique ; - terminaisons ; - contrles.
47
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Entit extrieure1
Entit extrieure2
Contrle Processus unique
2- Diagramme de flot de contrle Le diagramme modlise les changes de flots de contrle des processus, il est compos de : - Processus ; - Stockages de donnes et de contrle ; - Processus de contrle ; - Flots de contrle ( signaux ). contrle5 Processus 1 sotckage1 Contrle1 contrle2 stockage2 Processus 2 contrle4 contrle3 Processus 3
3- Spcification de contrle ( CSPEC ) Elle permet dexpliquer la logique de fonctionnement du systme. Ses entres sont des flots de contrle et la sortie est lactivation ou la dsactivation de processus. Pour une CSPEC, un ensemble doutils peuvent tre utiliss tels que : les diagrammes Etat-Transition ( STD ); la table Etat-Transition ( STT ); la matrice Etat-Evnement. . .
48
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Exemple : tat-transition Etat courant Etat1 Etat2 Evnement Evnement2 Evnement1 Evnement3 Etat3 Evnement1 Evnement2 Action Action2 Action3 Action1 Action3 Action4 Etat suivant Etat2 Etat1 Etat3 Etat1 Etat2
E1/A4 E1/A1
1
E2/A2,A3
2
E3/A3 E2
3- Contraintes de temps Elles permettent de spcifier les temps de rponse. Pour ce faire, un tableau est utilis. Exemple du distributeur automatique : Entre Objet Evnement Insr Sortie Fausses pices Evnement Ejectes Temps de rponse 2s max
Les mthodes graphiques ( semi-formelles ) sont particulirement claires. En revanche, il est difficile, voire impossible de vrifier la cohrence et la compltude des spcifications. Afin dy remdier, on a recours des mthodes de spcification dites formelles . III-5-2-2-3 / Les spcifications formelles Une spcification est dite formelle si : * Elle est crite en suivant une syntaxe bien dfinie comme celle dun langage de programmation. * La syntaxe est accompagne dune smantique rigoureuse qui dfinit des modles mathmatiques reprsentant les ralisations acceptables de chaque spcification syntaxiquement correcte. * La syntaxe et la smantique sont accompagnes de rgles de dduction qui permettent de dmontrer les proprits dune spcification.
49
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Les spcifications formelles prsentent les avantages suivants : * Fournir un document formel qui exprime le problme de lutilisateur ( clart ). * Permettre des vrifications formelles ( preuves ). * Etudier mathmatiquement deux spcifications de faon ce que, par exemple, on puisse tablir ou non leur quivalence. * Faciliter lcriture ultrieure des programmes vu quil existe des outils automatiques de passage de spcifications formelles des programmes. * Faciliter la maintenance ultrieure des programmes, grce une documentation de rfrence prcise et rigoureuse. Les mthodes formelles peuvent tre classes selon lapproche mathmatique qui leur sert de base. J. Wing considre quil y a deux grandes classes de mthodes formelles : 1- Les mthodes orientes modle 2- Les mthodes orientes proprits 1- Orientes modle : On dfinit le comportement dun systme en construisant un modle du systme en termes de structures mathmatiques telles que les tuples, les relations, les ensembles, les suites. Dans le domaine des programmes squentiels on trouve les langages VDM et Z, la mthode B . Dans le domaine des systmes concurrents et distribus, on trouve les rseaux de Petri, CCS de Milner, CSP de Hoare . 2- Orientes proprits : On dfinit le comportement du systme de manire indirecte en tablissant un ensemble de proprits, habituellement sous forme daxiomes que le systme doit satisfaire. On en considre deux catgories : * Axiomatiques ( Logiques ) Dans ce cas, un systme est reprsent par un ensemble de fonctions, chacune delles tant spcifie en utilisant des pr-conditions et des post-conditions qui sont tous deux des prdicats. Une pr-condition spcifie les valeurs en entre de la fonction, tandis quune post- condition spcifie les valeurs en sortie. Les pr-conditions et les post-conditions sont des prdicats qui peuvent tre quantifies et dont les valeurs sont les paramtres de la fonction spcifie. Exemple de spcification Soit la fonction log-bin ( x : entier ) qui donne le logarithme dun entier naturel x. La description informelle de cette fonction est la suivante : Soit un nombre entier naturel, on cherche y tel que 2y = x La description formelle ou axiomatique correspondante est : Fonction log-bin ( x : entier ) return entier ; Pr : x 1 ; Post : 2 log-bin (x) x et x < 2 log -bin ( x+1) Erreur : log-bin ( x ) = - 1
50
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Elle exprime que pour tous les entiers plus grands ou gaux un, le logarithme binaire est bien la solution de lquation 2y = x , ou , dans le cas o x nest pas puissance de deux , il est le plus grand nombre qui soit une approximation de cette quation. Cette spcification traite le cas o la pr-condition nest pas satisfaite : elle indique lerreur en retournant une valeur ngative ( - 1 ). * Les spcifications algbriques Les spcifications algbriques utilisent la notion dalgbre pour dfinir en mme temps des donnes et leur dynamique. Une algbre est dfinie par un ensemble dlments et des oprations appliquer sur les lments de cet ensemble. Une spcification algbrique se compose de quatre parties : 1 / Une partie introduction dfinissant le genre ( ou la sorte ) de lentit que lon spcifie et donnant le nom de toutes les spcifications ncessaires cette mme spcification. 2 / Une seconde partie dcrit de manire informelle les oprations dfinies sur ce genre dentit. 3 / Une partie appele signature donnant les noms de ces oprations ainsi que le genre des paramtres ( interface syntaxique de la structure de donnes ). 4 / La partie axiomes dcrit la smantique abstraite de la structure de donnes ( spcifier les relations entre les oprations ). Il existe un certain nombre de langages de spcification algbrique, citons par exemple CLEAR, OBJ, OBJECT ONE etc. Exemple : Une spcification algbrique de Tableau. Genre : tableau Importations : ENTIER Cette spcification dfinit un tableau comme tant une collection dlments du type gnrique Elem. Un tableau a une borne infrieure et une borne suprieure ( que lon obtient par les oprations Premier et Dernier ). On peut accder individuellement aux lments par un index numrique. Lopration Crer a pour paramtres les bornes du tableau crer dont elle initialise les lments indfini. Lopration Affecter permet daffecter une valeur un lment donn du tableau. Lopration Eval permet dvaluer la valeur dun lment donn du tableau. On vrifie que lindex de cet lment est compris entre les bornes du tableau. Crer ( Entier , Entier ) Tableau Affecter ( Tableau , Entier , Elem ) Tableau Premier ( Tableau ) Entier Dernier ( Tableau ) Entier Eval ( Tableau , entier ) Elem Premier ( crer (x y) ) Premier ( affecter ( T, n , v ) ) Dernier ( crer ( x , y ) ) Dernier ( Affecter ( T, n ,v ) ) x Premier ( T ) y Dernier (T) 51
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Eval ( crer ( x , y ) , n ) indfini Eval ( affecter ( t, n, v ), m ) Si m < Premier (T) ou m > Dernier (T) alors indfini sinon si m = n alors v sinon Eval ( T, m) Les mthodes formelles permettent dobtenir une trs forte assurance de labsence de bogue dans les logiciels, cest dire des niveaux dvaluation dassurance levs. Cependant, elles sont gnralement coteuses en ressources ( humaines et matrielles ) et actuellement rserves aux logiciels les plus critiques.
III-5-3 / Conception du logiciel

La phase de conception est la phase la plus cruciale du processus de dveloppement dun logiciel. Concevoir un logiciel est un processus itratif qui demande du savoir faire ainsi que de la perspicacit. Ainsi, Une conception finale est gnralement obtenue par un processus itratif partir de conceptions prliminaires. Il est important de veiller ce que les constituants du produit soient aussi indpendants que possible de manire faciliter la fois le dveloppement parallle et la maintenance future. Un rsultat est tout aussi important ( rsultat de la conception architecturale ) est le choix dune architecture logicielle. Exemples darchitectures logicielles Architecture Appel et Retour : un programme principal dans lequel des sous programmes sont appels- RPC si les programmes sont distribus sur un rseau. Architecture oriente objet : les donnes sont encapsules dans des composants, oprations pour les manipuler- communications par messages. Architecture client /serveur : rpartition sur plusieurs ordinateurs, certains jouent les fournisseurs de services, dautres sont les clients qui utilisent les services offerts. Les transactions sont ralises distance. . . etc. III-5-3-1 / Concepts de structuration La conception se base sur un ensemble de concepts de structuration : III-5-3-1-1 / La modularit : Cela signifie que le systme est dcompos en un ensemble de constituants ( composants ). Deux principales caractristiques influent sur la modularit : a/ La cohsion : La cohsion dun composant permet de mesurer la qualit de sa structuration. De faon idale, un composant est compos dides logiquement lies sans faire rfrence aux ides des autres composants. La cohsion est une caractristique dsirable car elle signifie que chaque unit ne reprsente quune partie de la rsolution du problme.
52
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Constantine et Yourdon identifient, en 1979, sept niveaux de cohsion prsents ci- aprs, du plus fort au plus faible. la cohsion fonctionnelle Dans ce cas, tous les lments du composant contribuent atteindre un seul objectif ( si un lment est supprim, lobjectif ne sera pas atteint ). La cohsion squentielle Dans ce type de cohsion, la sortie dun lment est utilise en entre dun autre ( dans ce cas, lordre des actions est important ). Exemple: Saisir,Traiter, Imprimer La cohsion de communication Lorsque tous les lments dun composant se rfrent aux mmes paramtres dentre / sortie ( E / S ) , on dit que la cohsion est de communication. Exemple: Chercher le nom et prnom dun tudiant Chercher la date dinscription dun tudiant La cohsion procdurale Dans ce cas, les lments dun composant constituent une seule squence de contrle. La cohsion temporelle On parle de cohsion temporelle quand dans un mme composant sont regroups tous les lments activs au mme moment, par exemple, linitialisation dun programme ou encore en fin dexcution. La cohsion logique Tous les lments dun composant effectuent des oprations semblables comme, par exemple, le traitement derreurs. La cohsion par concidence Dans ce cas, il ny a pas de relation entre les lments du composant. Lorsque la mthode est fonctionnelle ( le composant est une fonction ), il est vident que lunit de plus grande cohsion est la fonction. Toutefois, les systmes orients objet se caractrisent eux aussi par un haut degr de cohsion. En effet, lun des principaux avantages de cette approche provient du fait que les objets qui constituent le systme sont naturellement cohsifs. b/ Le couplage : Le couplage est relatif la cohsion, il indique la force dinterconnexion des diffrents composants dun systme. Les systmes fortement coupls ont des interconnexions fortes, avec des units de programmes dpendant les unes des autres. En rgle gnrale, les composants sont fortement coupls lorsquils utilisent des variables partages ou lorsquils changent des informations de contrle. 53
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Il existe plusieurs types de couplages ( du plus faible ( meilleur ) au plus fort ( pire ). Le couplage de donnes : Quand il y a un passage de donnes atomiques entre module appelant et module appel. 1/ appel P1 2/ rsultats Le couplage de contrle Quand un module transmet un autre module une information destine contrler sa logique interne. Exemple: P1 1/ MAJ compte bancaire ancien solde montant retrait 2/ nouveau solde Editer compte P2 P2
En se basant sur les donnes envoyes par P1, P2 suivra le chemin dexcution appropri. Le couplage par donnes communes. Quand deux modules se rfrent un mme bloc de donnes. III-5-3-1-2 / Labstraction Labstraction est un autre concept de structuration tout aussi important que la modularit. Cela consiste faire abstraction des dtails des diffrents composants. III-5-3-1-3 / La hirarchie Il sagit de dcomposer un systme en composants tout en tablissant une relation oriente entre ces derniers, ce qui permet dtablir les rgles de communication entre les diffrents composants. III-5-3-2 / Approches de conception La conception peut tre aborde selon deux approches, fonctionnelle ou oriente objet : III-5-3-2-1 / La conception fonctionnelle Les mthodes fonctionnelles ( galement qualifies de mthodes structurelles ) mettent en vidence les fonctions assurer et proposent une conception hirarchique descendante et modulaire. La dcomposition se poursuit jusqu arriver des composants matrisables.
54
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Programme principal Donnes
Sous-fonction1
Sous-fonction2
Sous-fonction3
Sous-ft 1.1
Sous-ft 1.2
Sous-ft 2.1
Sous-ft 2.2
__
Lapproche fonctionnelle dissocie le problme de la reprsentation des donnes, du problme du traitement de ces donnes. Laccs des donnes peut tre direct ( cest parfois le cas quand les donnes sont regroupes dans une base de donnes ), ou peut tre ralis par le passage de paramtre depuis le programme principal. *** Notion de module ( rappel ) Un module est une unit regroupant un ensemble de fonctions. Dans un module, on distingue deux parties : 1 une interface ( publique ) : visible aux autres modules pouvant utiliser le module en question, elle comprend : - Lidentification du module ; - Les modules imports ( utiliss ) par ce mme module ; - Les oprations et les donnes externes exportables. 2 Un corps priv : reprsente la ralisation des fonctions. Le corps priv est cach et invisible aux autres modules. L interface du module constitue en quelque sorte le contrat que le module sengage respecter. Tandis que le corps du module sert remplir ce contrat.
55
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Exemple :
Pgm source code objet
Analyse units Analyse arbre Analyse Pgm Gnration lexicale lexicalessyntaxique syntaxique smantique analys du code Construction de la table des symboles table des symboles Ecrire message
message derreur
symboles
Vue fonctionnelle simplifie dun compilateur

III-5-3-2-2 / La conception oriente objet ( C.O.O) Plutt que de concevoir un logiciel comme tant un ensemble de fonctions, la conception O.O considre ce dernier comme un ensemble dobjets en interaction. Les caractristiques essentielles de la conception O.O se rsument comme suit : * Dans beaucoup de systmes, il existe une correspondance claire entre les entits du monde rel et les objets. * Les objets communiquent par messages plutt quen partageant des variables do un couplage rduit. * Les objets sont des entits indpendantes encapsules, ce qui implique la possibilit de modifier la reprsentation sans faire rfrence dautres objets du systme do une maintenance plus facile. * La possibilit de rutiliser des objets. * La possibilit dune excution en parallle. Exemple : Contrairement au cas prcdent ( cas du compilateur ), lintrt est port sur les objets manipuls par le compilateur. Programme principal
Parcourir
Units lexicales
Mettre symboles
Table des symboles
Prendre symboles
grammaire
Message derreur
Vrifier Construire
Arbre Syntaxique
gnrer le code
code objet
Vue 0.0 dun compilateur
56
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Dun point de vue conceptuel, les objets communiquent en changeant des messages. En pratique, la communication entre objets est ralise par lappel, depuis un objet, dune procdure associe un autre objet. Le rapprochement entre le concept de module et dobjet peut tre le suivant : Dans un module, on essaie de regrouper des fonctions, procdures et donnes qui ont quelque chose de commun. Dans un objet, on regroupe des mthodes et des attributs qui ont en commun lobjet lui-mme.
III-5-4 / Implmentation et langages de programmation

Cette activit consiste passer de la conception dtaille un ensemble de programmes ou de composants logiciels. Elle est la mieux outille et matrise. Conception + Ressources Implmentation
III-5-4-1 / Processus de dveloppement dun programme Le processus de dveloppement dun programme partir dun travail de conception peut tre abord de deux manires : Dune manire descendante : Dans ce cas, on ralise les niveaux infrieurs par des bauches qui simulent leurs comportements dune manire simplifie. La ralisation se fait alors par niveau. Dune manire ascendante : Il sagit de commencer par la ralisation des blocs de base, la construction de blocs plus complexes partir des premiers et ainsi de suite jusqu' atteindre le niveau suprieur de la hirarchie du systme. III-5-4-2 / Les langages de programmation Il existe un grand nombre de langages de programmation. Ils peuvent tre classs de diffrentes manires. III-5-4-2-1 / Taxonomie de base Langages impratifs Un programme est une suite dinstructions ( ventuellement parallles ). Laction de base dans la programmation imprative est laffectation, cest dire la modification de la valeur associe une variable du programme. Ce type de programmation est le plus pratiqu, cest le plus proche du fonctionnement de la machine dexcution, o une mmoire change dtat. Exemples : C, C++, ADA, PASCAL, BASICetc. Langages fonctionnels Un programme est une composition de fonctions. Dans la programmation fonctionnelle ( ou applicative ), laction de base est le calcul du rsultat dune fonction pour des valeurs de ses arguments. Ces langages de programmation ont t trs utiliss en intelligence artificielle ( IA), mais on leur prfre maintenant la programmation logique ou la programmation par objets .
57
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Par ailleurs, ces langages sont peu utiliss pour le GL, sans doute parce quils ne sont pas trs efficaces et quils noffrent pas de vritable modularit. Exemples : LISP, CAML, SMLetc. Langages logiques Un programme est un ensemble de faits et de rgles dinfrence. La programmation logique consiste noncer les proprits dun systme de rsolution programme plutt qu dcrire les oprations effectuer comme dans le cas de la programmation imprative. Elle permet de sparer clairement les trois parties dun logiciel : - les connaissances sur le domaine dapplication ; - la formulation du problme rsoudre ; - le mcanisme de rsolution, gnral et indpendant des deux autres parties bien quoprant sur elles. Le but dun programme logique est de permettre la rsolution dune expression logique ou dune conjonction de telles expressions. Par rsolution, on entend la recherche des valeurs des variables qui rendent lexpression vraie ( les solutions ). Exemples : PROLOG, MERCURY Langages orients objet Un programme est un ensemble dobjets qui interagissent par des appels des mthodes. La programmation consiste donc dfinir des classes qui permettent, lexcution, de crer justement des instances ( ou objets ). Exemples : Simula ( lanctre de ces langages ), Smalltalk et toutes ses variantes. - Perl ( impratif interprt ) - Objective Caml ( fonctionnel interprt ) - Eiffel ( impratif compil ) - Java ( impratif semi-interprt ) --III-5-4-2-2/ Niveaux de langages Assembleur / langage machine Langages intermdiaires , exemple : C ( la structure de limplantation doit encore tre connue ) Langages volus exemple : ADA, EIFFEL, PERL ( la structure interne est compltement masque ) Langages de quatrime gnration ( L4G )
III-5-4-2-3 / Classification selon le code excut Langages interprts - le code excut est le source du programme ; - chaque instruction est dabord traduite puis excute ; - lexcution est lente. Exemple : Perl
58
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Langages compils - le code excut est une version en langage machine du programme ; - le source est traduit une fois pour toute ; - lexcution est rapide, mais une recompilation est ncessaire chaque modification. Exemple : C Langages semi-interprts - Le code excut est une traduction en un pseudo-assembleur du source. Exemple : Java
III-5-4-2-5 / Polymorphisme et liaison dynamique Un langage autorise du polymorphisme sil permet une expression davoir plusieurs types. Cela signifie quil est possible de transmettre un paramtre un sous-programme qui dterminera, lexcution, le traitement adquat en fonction du type du paramtre transmis. On parlera ici de liaison dynamique. III-5-5 / Test de logiciels Le test est un processus manuel ou automatique, qui vise tablir quun systme vrifie les proprits exiges par sa spcification, ou dtecter des diffrences entre les rsultats engendrs par le systme et ceux qui sont attendus par la spcification. Le test vise mettre en vidence les erreurs dun logiciel ; Le test na pas pour objectif de corriger les erreurs ; Le test na pas pour objectif de prouver la correction dun programme. Gnralement 40% du budget global est consacr leffort de test. III-5-5-1 / Types de test Il existe plusieurs types de tests : Test unitaire : consiste vrifier chaque composant indpendamment des autres. On distingue : Test fonctionnel : examine les contraintes lies aux spcifications et valuent les ractions du logiciel certaines entres, sans rentrer lintrieur des modules. Test structurel : examine la structure de chaque module via le graphe de flot de contrle ; le code du programme est test par partie ( on parle de portions ) et on nommera, la fin de cette srie de tests, couverture lensemble des portions de code qui auront t testes. NB : Dans ce cas, un graphe de contrle contient : - des nuds : blocs dinstructions en squence, sans saut. - des arcs : sauts dans le flot de contrle. Test de sous-systme : Les composants pouvant communiquer les uns avec les autres, il sagit donc de vrifier les interfaces entre composants. Test dintgration : le fonctionnement de lensemble est vrifi. Test dacceptation : Il sagit de tester le systme avec des donnes relles.
59
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Test de non-rgression : ralis pendant la maintenance afin de vrifier quil ny a pas eu de dgradation des fonctions par rapport la version prcdente.
III-5-5-2 / Mthodes de tests On peut distinguer deux mthodes de test : III-5-5-2-1 / Mthodes de tests statiques Ces mthodes consistent en lanalyse textuelle du code du logiciel afin dy dtecter des erreurs, sans excution du programme. - Revue ou inspection : consiste en lexamen dtaill dune spcification, dune conception ou dune implmentation par une personne ou un groupe de personnes, afin de dceler des fautes, des violations de normes de dveloppement ou dautres problmes. - Analyse du graphe de contrle : Le graphe de contrle est gnralement driv de lorganigramme du programme, il sagit donc danalyser le graphe de contrle du programme, ce qui peut rvler des erreurs ( exemples : sauts anormaux, code inutilis ). Avantages : + mthodes efficaces et peu coteuses ; + 60 95% des erreurs sont dtectes lors de contrles statiques. Inconvnients : - mthodes ne permettant pas de valider le comportement dun programme au cours de son excution ; - lors dune modification du programme, il est souvent difficile de rutiliser les tests prcdents pour valider la nouvelle version. - les mthodes de tests statiques ne sont pas suffisantes. III-5-5-2-2 / Mthodes de tests dynamiques Les mthodes de tests dynamiques consistent en lexcution du programme valider laide dun jeu de tests. Elles visent dtecter des erreurs en confrontant les rsultats obtenus par lexcution du programme ceux attendus par la spcification de lapplication. Comment choisir le jeu de tests ? * Mthodes alatoires : Le jeu de tests est slectionn au hasard sur le domaine des entres du programme. Linconvnient est que ces mthodes ne garantissent pas une bonne couverture de lensemble des entres du programme. En particulier, elles peuvent ne pas prendre en compte certains cas limites ou exceptionnels. * Mthodes structurelles ( Bote blanche ) : Le critre de slection du jeu de tests repose sur le code du programme. Le jeu de tests est choisi donc de manire remplir certaines exigences : - couverture de toutes les instructions ; - couverture de tous les chemins excutables ; - couverture de toutes les conditions. NB : Afin daugmenter la qualit dun test de couverture, on peut slectionner plusieurs tests par sous-domaine laide dune loi de distribution, on parle alors de mthode statistique structurelle .
60
-----------------------------------------------------------------------------------------------------------------------------------------------------------
* Mthodes fonctionnelles ( Bote noire ) : Ces mthodes visent valider les fonctionnalits dun programme. Les jeux de tests sont drivs de la spcification du programme. - Si la spcification est informelle alors un ensemble de tests est slectionn manuellement pour chaque fonctionnalit dcrite. - Si la spcification est semi-formelle alors la slection du jeu de tests est guide par la modlisation. - Si la spcification est formelle alors une slection automatique du jeu de tests est envisageable. Comment dcider du succs ou de lchec dun jeu de tests ? Une fois un jeu de tests slectionn, il est utilis lors de lexcution du programme valider ; Il reste alors interprter les rsultats obtenus au cours de cette excution, on parle dun : succs dun jeu de tests ( jeu de tests positif ) si chaque test du jeu est positif ; chec dun jeu de tests ( jeu de tests ngatif ) si au moins un test du jeu est ngatif. Quand estime t-on que le programme na plus besoin dtre test ? Un programme na plus besoin dtre test lorsque : lefficacit du jeu de tests slectionn est conforme certains critres de qualits ; le jeu de tests est positif. III-5-5-2-3 / Spcification de tests La spcification dun test comprend : Une spcification des entres; Une spcification des fonctions du systme qui seront testes. Une spcification des sorties qui sont attendues. Les tests peuvent tre dvelopps ( spcifis ) paralllement la conception.
61
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5-5-2-4 / Cycle de dveloppement de test Objectif du test
Spcification programme
Spcification du test Scnario de test Rsultat attendu
Chargement du pgm et de son environnement
Excution du test
Comparaison de Rsultats correct incorrect
Archivage du test +rsultats
Analyse de rsultats
Modification Biblio dans le test dans le pgm Gestion de configurations
62
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Quelques outils de tests : TAO, PathCrawler, GATel, FAUST,Junit, SIMPROC, Conformiq...etc.
III-5-6 / Maintenance des logiciels

La maintenance est une activit qui dbute la livraison du logiciel et sachve la fin de son exploitation. Par consquent, tant quil est exploit, un logiciel doit tre maintenu. III-5-6-1 / Types de maintenance Il existe plusieurs types de maintenance : La maintenance corrective : Elle consiste corriger les anomalies ou erreurs de traitement. La maintenance adaptative : Elle consiste adapter le logiciel de nouvelles conditions dexploitation ( matriel, fournitures logicielles, outil ). Ceci peut ncessiter la restructuration de certaines parties du code sans pour autant changer les spcifications ( et donc darchitecture ). La maintenance volutive : Elle consiste maintenir les fonctionnalits antrieures tout en ajoutant de nouvelles fonctionnalits qui modifient profondment larchitecture. Dans ce cas , un changement est opr au niveau des spcifications fonctionnelles du logiciel.
NB : Lorsque les modifications reprsentent une partie notable du dveloppement, on les

considre comme une refonte sortant du cadre de la maintenance, traite comme un projet logiciel normal.
18% 65% 17%
Maintenance corrective Maintenance adaptative Maintenance volutive
Rpartition de leffort de maintenance
63
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5-6-2/ Processus de la maintenance Si un changement est dsir, une analyse est ralise dans le but destimer limpact du changement. Ensuite, le type de maintenance ncessaire est choisi pour procder des implmentations et aboutir donc une nouvelle version.
changement demand
analyse dimpact
planification modification
implmentation changements
dition dune nouvelle version
volutive
adaptative
corrective
III-5-6-3 / Facteurs influenant le cot de la maintenance Le cot de la maintenance est plus ou moins influenc par un certain nombre de facteurs, citons : * Lge du logiciel * Limportance de la modification * La stabilit de lquipe * La qualit de la documentation technique * Le document de la maintenance III-5-7 / Documentation III-5-7-1 / Types de documents Il existe un certain nombre de documents qui accompagnent un projet : Documents de pilotage de projet : prcisent le droulement du projet ( phases, dures, intervenants ). Documents dtude et de dveloppement : expliquent les problmes, les solutions choisies, les choix effectus. Documents dassurance qualit : caractrisent les critres de qualit ainsi que les mesures de qualits. Document dexploitation et de maintenance : dtaillent linstallation du logiciel, lorigine des problmes. Documents contractuels : servent tablir les points daccord entre client et fournisseur.
64
-----------------------------------------------------------------------------------------------------------------------------------------------------------
III-5-7-2 / Gestion de la documentation Une bonne gestion de la documentation repose sur quelques principes : utiliser des documents standardiss ; donner tout document ; - un type - un nom une date de dernire modification un numro de version sur chaque document, prciser de plus : - son lieu de rangement les participants sa rdaction III-5-7-3 / Quelques exemples standards de documents Dictionnaire : liens entre termes et concepts ; Dossier de traabilit : liens entre les diffrents documents, le code ; Dossier de test : que tester, comment ; . .
III-6 / Rpartitions gnrales des efforts :

Les pourcentages de leffort total de dveloppement dun logiciel sont estims comme suit: programmation : 10 20% spcification et conception : environ 40% validation et vrification : de lordre de 40%
III-7 / Portabilit des logiciels

La portabilit dsigne pour un programme informatique sa capacit fonctionner plus ou moins facilement dans diffrents environnements dexcution. Les diffrences peuvent porter sur lenvironnement matriel ( processeur ) comme sur lenvironnement logiciel ( systme dexploitation ) ou alors sur une combinaison des deux. Laction de modifier un programme pour quil puisse sexcuter sur un autre environnement est appele portage . Environnement dexcution : La notion denvironnement dsigne lensemble ( physique ou logique ) qui excutera les instructions du programme. Cet environnement peut avoir plusieurs aspects suivant le langage de programmation utilis ou le type du programme. Ainsi, lenvironnement dexcution est : le systme dexploitation pour les langages compils ; linterprteur pour les langages interprts ; la machine virtuelle pour les langages qui peuvent tre pseudo-compils comme Java ; le navigateur pour les applications Web ; larchitecture matrielle pou les systmes dexploitation. La portabilit reste un problme ouvert et la solution actuelle est probablement la standardisation.
65
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Le gnie logiciel orient agent (AOSE : Agent Oriented Software Engineering)

Le domaine des systmes multi-agents concerne ltude et la conception de systmes composs dun ensemble dentits autonomes ( les agents ) en interaction entre elles et leur environnement et devant raliser collectivement une tche commune. Il propose des thories, des technologies et des mthodes qui concernent, entre autres, lingnierie des systmes informatiques complexes, dcentraliss et ouverts. Ces dernires annes, le Gnie Logiciel Orient Agent ( GLOA ) est devenu un axe de recherche trs actif. En effet, des mthodologies de dveloppement de systmes selon une approche multi-agents ont t proposes, citons : ADELFE, INGENIAS, MASA, GAIAetc. En gnie logiciel orient agent, de nouveaux concepts sont pris en compte tels que le rle, lorganisation, lauto-organisation et lmergence. ..
66
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Bibliographie
1/ Grady Booch : Object Oriented Analysis and Design with Applications, Deuxime Edition, Benjamin / Cummings, Menlo Park ( Calif. ), 1994. 2/ G.W. Brams, Rseaux de Petri : Thorie et pratique, Editions Masson, Paris, 1983. 3/ M.C. Gaudel et al. : Prcis du gnie logiciel, Editions Masson,1996. 4/ D.J. Hatley : Stratgies de spcification des systmes temps rels ( SA-RT ), Editions Masson, 1991. 5/ M. Lissandre : Matriser SADT, Editions A. ColIN, ISBN N 2-200-42022-6, 1990. 6/ John D.Mc Gregor et David A. Sybres: Object Oriented Software Development: Engineering Software for Reuse, Van Nostrand Reinhold, New York, 1992. 7/ B.Meyer: Conception et Programmation Oriente Objet, Eyrolles, 2000. 8/ P.A.Mulla : Modlisation objet avec UML, Eyrolles, 2000. 9/ Rumbaugh, Blaha et al. : Object Oriented Modelling and Design, Prentice Hall, International, 1991. 10/ A. Strohmeier, D. Buchs: Gnie logiciel: principes, mthodes et techniques, collection : informatique,1996.
67
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Le module GL1 est complt par des exposs dont les thmes sont proposs par la responsable du module et qui seront exposs par des tudiants. Concernant lanne 2007/2008, les thmes proposs sont les suivants : AGL (Ateliers de Gnie Logiciel ) Un AGL est un ensemble doutils logiciels structurs au sein dune mme interface permettant le dveloppement et le dbogage de logiciels. Ce sont donc des programmes informatiques permettant eux mmes de produire des programmes de manire industrielle. Exemple prsenter : Eclipse Mthodes agiles Les mthodes de dveloppement dites mthodes agiles ( Agile Modeling ) visent rduire le cycle de vie du logiciel ( donc acclrer son dveloppement ) en dveloppant une version minimale, puis intgrant les fonctionnalits par un processus itratif bas sur une coute client et des tests tout au long du cycle de dveloppement. Exemple prsenter : XP ( eXtreme Programming ) Patrons de conception En Gnie logiciel, un patron de conception ( Design Pattern ) est un concept destin rsoudre les problmes rcurrents suivant le paradigme objet. Les patrons de conception dcrivent des solutions standards pour rpondre des problmes darchitecture et de conception de logiciels. Leur apport essentiel est donc la rutilisation . PU ( Processus unifi ) Le processus unifi PU ( Unified Process ) est un processus de dveloppement logiciel, cest dire quil regroupe les activits mener pour transformer les besoins dun utilisateur en systme logiciel ( Jacobson, Booch, Rumbaugh 1999 ). PU est ainsi une mthode de prise en charge du cycle de vie dun logiciel et donc du dveloppement, pour les logiciels orients objet .Cest le fruit des meilleures pratiques de lingnierie logicielle. PU est pilot par les cas dutilisation ( eux-mmes guids par les risques), centr sur larchitecture, itratif et incrmental.
68
-----------------------------------------------------------------------------------------------------------------------------------------------------------
RUP ( Processus unifi de Rational ) RUP est lune des plus clbres implmentations de la mthode PU, permettant de donner un cadre au dveloppement logiciel, rpondant aux exigences fondamentales prconises par les crateurs dUML. Rappelons que UML ne prend pas en charge le cycle de vie du logiciel, la diversit des projets a conduit lmergence dun ensemble de mthodes diffrentes : RUP, XUP, AUP. . AUML ( Agent Unified Modeling Language ) AUML est une extension dUML avec des facilits permettant de dcrire les agents. AUML sert donc la modlisation oriente agent.
69

Cours Génie Logiciel 1

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Cours Génie Logiciel 1

Încărcat de

Drepturi de autor:

Formate disponibile

Universit de Batna Dpartement dInformatique Module : Gnie logiciel (GL1) ( 3me anne Ingnieur ) Enseignante : Mme S.S.

. Bendib Anne scolaire : 2007 / 2008

Module : Gnie logiciel ( 3me anne Ingnieur ) Responsable : Mme S.S.Bendib

Quest ce que le Gnie Logiciel ?

rgles du CQFD = Cot Qualit Fonctionnalit Dlai

II-2 / Dynamique des systmes

information produit nergie Entres

produit nergie Sorties

II-3 / Caractristiques dun systme

II-5 / Cycle de vie dun systme

4 Dveloppement du logiciel du systme

II-6 / Conception statique dun systme

II-6-1 / Spcification technique des besoins ( STB )

II-6-2 / Mthodes pour la conception statique dun systme

Les flches de mcanisme sont appeles flches de support.

format des photocopies

Reproduire copies photocopieuse

Enseignant ENS # NOM ENS ENS ENS occurrences

II-7 / Conception dynamique dun systme

Analyse prliminaire des besoins

Analyse et slection de nouvelles fonctions

Construction du prototype Evaluation exprimentation Expression claire des besoins rels

Spcification initiale Slection dune caractristique

Construction du prototype Evaluation Confirmation ou affinement des specs

Mise en uvre et utilisation

Ensemble de composants rutilisables

S-ensemble de composants rutilisables

Systme dassemblage de composants

Lassemblage de composants rutilisables

II-7-2 / Les rseaux de Petri

Transition sensibilise *** Le franchissement dune transition consiste :

Transition non sensibilise

Avant le franchissement de T1 Aprs le franchissement de T1

Squence de franchissement T1 T2 Si M M1 et M1 T1.T2 pour M et on note M M2

P23 T12 P24

Le RdP total est reprsent comme suit :

P23 T12 P24

P12 T7 P13 Processus1

P13 T17 P14 Processus 1 P0

P12 T17 P13 T18 Processus 1 P0

II-7-3 / Lapproche oriente objet

Compte Classe numro solde dcouvert Consulter Crditer Dbiter

Exemple dhritage multiple : Appareil

III / Cycle de vie dun logiciel

III-3 / Activits principales du processus de dveloppement dun logiciel

III 4 / Modles de cycle de vie

Analyse des besoins

Version actuelle du modle en cascade

oui Acceptation du logiciel

Spcification * dossier de spcif du log * Manuel ( Inst /Ut ) Conception Architecturale

Test dacceptation du logiciel

Intgration et * dossier test dintgration des tests dacceptation

* dossier de conception dtaille * dossier provisoire de tests unitaires Programmation

* listage du code * dossier des tests unitaires

Prototypage Analyser Concevoir Coder Revoir et superviser 4 Faites le 3

III-5-2 / Spcification du logiciel

Exemple : Fichier tudiant : 14 Nom : 1

Contrle Processus unique

III-5-3 / Conception du logiciel

Programme principal Donnes

Vue fonctionnelle simplifie dun compilateur

Table des symboles

Vue 0.0 dun compilateur

III-5-4 / Implmentation et langages de programmation