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

1

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.


2

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


3

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


4

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.


5

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 information produit systme produit nergie nergie Entres 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.


6

A un mme systme, peuvent correspondre plusieurs modles, selon lobjectif de ltude, le systme de reprsentation, etc. Modle1 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.

Systme


7

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 ? );


8

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.


9

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


10

donnes de contrle ..

donnes donnes dentre : nom de lactivit : de sortie

.. 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 sont appeles flches dinterface - de contrle - de sortie Les flches de mcanisme sont appeles flches de support. Exemple : Modlisons lactivit reproduire copies par un actigramme. nombre de copies format copie Reproduire copies des photocopies

originale photocopieuse


11

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 nom de la donne activit gnratrice utilisatrice

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


12

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.


13

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 Occurrences Nom ENS - - 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 proprits occurrences de lentit Enseignant Nom Ens - Grade - : - - - - . . 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 :


14

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 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 ) ( 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.

est affect

est affect


15

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 : Etat non satisfaisant Etat satisfaisant

Analyse prliminaire des besoins

Analyse et slection de nouvelles fonctions

Construction du prototype

Evaluation exprimentation

Expression claire des besoins rels

Spcifications dfinitives


16

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

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 Evaluation Nouvelle version

Spcification initiale

Slection dune caractristique

Construction du prototype

Evaluation

Confirmation ou affinement des specs

Conception et ralisation

Mise en uvre et utilisation

Correction et amlioration

Version finale

Spcification de base


17

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 Spcification rutilisables du systme S-ensemble de composants Systme dassemblage rutilisables de composants Prototype excutable Lassemblage de composants rutilisables


18

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 T3 2 P1 P2 P3 M = 0 2 2 0 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.


19

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 Transition non sensibilise *** Le franchissement dune transition consiste : - 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.


20

* Lvolution de ltat correspond donc une volution du marquage, ce qui se traduit par le franchissement de transitions. Exemple : T1 Etat initial P1 P2 T2 2 2 T1 Aprs franchissement de T1 P1 P2 T2 2 2 T1 Aprs franchissement de T1 P1 P2 T2 2 2 T1 Aprs franchissement de T2 P1 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 = Wij avec Wij = Pr ( Pi, Tj ) + + Post = Wij avec Wij = Post ( Pi,Tj )


21

Squence de franchissement T1 T2 Si M M1 et M1 M2, on dit que la squence T1T2 est franchissable T1.T2 pour M et on note M M2 / 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 :

M = M Pr . S + Post . S Si on pose : 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.


22

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


23

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.


24

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 P6 T7 P13 P7 Processus1 Procesus2


25

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 P6 T17 T7 P0 P7 P14 T8 Processus 1 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 P6 T17 P0 T7 P13 P7 T18 T8 Processus 1 Processus 2


26

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.


27

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.


28

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 : 5 : sortir des billets 1 : retirer 3 : retirer de l argent 2 : lire N compte 4 :dbiter 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.

La rserve des billets

La banque Le distributeur

Le compte de X La carte de X


29

Compte Classe numro solde dcouvert Consulter Crditer Dbiter Le compte de X Le compte de Y numro= 4200 numro= 8003 solde= 5000 solde= 1000 dcouvert= -500 dcouvert= -200 - - - - - - - - - - - Consulter Consulter Crditer objets ou instances Crditer Dbiter de la classe Dbiter Hritage Lhritage permet un partage hirarchique des proprits (attributs et oprations). Une sous-classe 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 super-

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

Femme Homme


30

Exemple dhritage multiple : 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 . 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.

Appareil

Appareil lectrique Chauffage

Four micro-ondes Chauffage lectrique Poele Mazout


31

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 Polygone Surface ( ) 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.


32

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- 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 ) 2- 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.


33

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.


34

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.


35

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.


36

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.


37

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

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

Cours Génie Logiciel 1

Documents

Transcript of Cours Génie Logiciel 1