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

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

1


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

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

2


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

3


I / Introduction gnraleLa 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 DlaiCependant, 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.

4


II / La conception systmeII-1 / Notion de systmeUn 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 systmeUn 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 / ModlesUn 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.

5


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


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

7


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.

8


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 systmeLa 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 systmeEn 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 prototypageQuand 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 fonctionsEtat 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 rduiteApprofondissement

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 PetriLes 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 objetLapproche 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 . 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 logicielIII 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 logicielQuelque 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 vieLe 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.

Faisabilitvalidation

Analyse des besoinsvalidation correction

Conceptionvrification

correction

Conception dtaillevrification

correction

Codagetest unitaire

correction

Intgrationtest dacceptation

correction

Installationtest systme

correction

Version actuelle du modle en cascade

Exploitation et maintenance38


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 logicielLogiciel 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 besoinsCette 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 logicielIII-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

12 4

3

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 Etat2E1/A4 E1/A1

1E2/A2,A3

2E3/A3 E2

3

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 lutilisat

Cours Génie Logiciel 1

Documents

Transcript of Cours Génie Logiciel 1