Vous êtes sur la page 1sur 17

1 LE GENIE LOGICIEL 1

Software Engineering

1. INTRODUCTION

1) GENERALITES Historique

Réu n i o n du comité scientifique de l'Organisat ion du Traité de l 'Atlant i que Nord (à Garmich, RF A 1968)

avec que l ques - u n s des pl u s g r an d s spécialistes mond i aux de la progra m mat i on. les ca u ses de ce q ue l' on commençait à appeler la crise du l ogiciel .

Les symptômes de la crise

- Problème d'Adéquation:

L'objectif est d' ét u dier

aux besoins des

les systèmes informatisés ne correspondent pas souvent

utilisateurs.

 

- Problème

de Fiabilité : les systèmes tombent sou v ent en panne.

-

Problème

de Modifiabilité : la maintenance est souvent complexe et coûteuse . Il était diffic i le d'adapter

les logiciels pour prendre en co n sidération l'évolution des environnements et des besoins des utilisateurs.

- Coût et délai : b u d gets

matér i el: 5 00 / 0 - 50% en 1965, 70 0 / 0 - 30% en 1 975 , 800 / 0 - 20% en 19 8 5 . Les coûts rés u ltent généralement des

frais d e main t enance qui découlent de la q u alité déficiente du logiciel a u moment de sa livraison ou après son évolution.

dépassés, pro j ets en retard. Le coût du logiciel est deven u supérieur à celui du

- Interface utilisateur inappropriée.

Enfin les causes sont nombreuse s et parmi les plus importantes: le caractère rudimentaire des méthodes et outi l s utilisés dans le développement de l ogicie l s .

M o ralité

Fa i re d e l a pro d uction

de logiciel

u ne discipli n e

d 'i ngénie u r

à part entière ,

avec une

so l ide base

scie n tifique

l e tit r e : génie l og i ciel .

Défmiti o n du Génie l og i c iel

Ensemble de méthodes, techni q ues et outils nécessaires à la production de logiciels de qualité. =: } Plus précisément, le génie logiciel vise à satisfaire:

( comme d ans les autres d isc ipl ines tel l es q ue le génie civi l o u l e génie chimique

etc

- Les utilisateurs : en produisant des logiciels adaptés aux besoins. - Les gestionnaires : en réduisant le coût de pro d uction et de maintenance.

- Les chefs de projet

raisonnab l e.

: en ren d ant les l ogicie l s productifs dans un délai

). D'où

C o mment y p arvenir

~ Amélio r er la démarche de déve l oppement: Appliquer et faites appliquer les méthodes d'analyse ,

de conception (SADT, JACKSON , RaaD , M E RlSE ,

) , dans le développement de logiciels .

~ Améliorer les langages : On peut programmer mal dans un bon langage , et assez bien dans un mauvais , Mais il est plus facile de bien programmer avec un bon langage . Il est important de

connaître l es nouveaux concepts des langages modernes (modularité , abstraction, généricité ,

héritage

) même si l'on ne peut pas toujours les emp l oyer en pratique .

~ Utiliser des outils d 'ai d e a u déve l oppement:

Les env ir o nn ements de programmation: éditeur syntaxique, o u ti l s d e tests,

1 / G L : ln t r o + cyc le de v ie

A . KO U K A M

Les ateliers de génie logiciel: outils d'aide au spécification , gestionnaire de configuration , gestionnaire de projets ,

~ D écomposer le déve l oppement en p l usieurs étapes: Suivre le cycle de vie du log i ciel (c ' est la

suite du cours

) .

2) LE CYCLE DE VIE DU LOGICIEL Qu'appelle t'on logiciel? -

L'organisation internationale de normalisation (ISO) a défini en 1981 le logiciel (software) comme une création intellectuelle rassemblant:

~ des programmes permettant de faire fonctionner un ordinateur et de l'utiliser pour résoudre des problèmes,

~ l a documentation servant à concevoir, réaliser, utiliser et modifier ces programmes .

Cycle de vie du logiciel

Il défmit l'ensemble

des étapes qui composent le processus de développement et d'utilisation du logiciel .

Modèle du cycle de vie

Modélisation conventionnelle de la succession d'étapes qui préside à la mise en oeuvre d'un produit logiciel . Il s'agit de décrire et de représenter les étapes du cycle de vie et leurs relations . Ainsi plusieurs modèles ont été proposés: la cascade (Waterfall model) , cycle en V , modèle en spiral, Ces modèles partagent pratiquement les mêmes étapes mais diffèrent sur la mnière des les organiser, d ' integrer les

autres facteurs du développement (les risques, l es utilisateurs,

Nous présentons ci - dessous le modèle en V . Les étapes seront décrites dans le paragraphe suivant.

)

BE SO I N S REEL S

\

\

\

/

/

V ALI D AT ION

III

T ESTS

D ' INT E G RA T IO N

/ 1/

T E S T S U N I TA I RE S

G

G

SP ECI F I C ATION

\\

\

••

C O NC EP TION GENE RA LE

G

\\\

CONCEPTIO N D E TAIL L EE

••

\R~:/

\ '----------' /

En correspondance de chaque étape de la construction est associé une phase de contrôle de conformité. Par e x emple: spécification < ---- -- -- ------ -- > v alidation.

Pourquoi de tels modèles?

U n modèle est une référence pour les personnes impliquées dans le dé v eloppement d'un logiciel . En effet ,

un modèle:

- Permet de représenter le processus de développement de manière graphique et physique ,

- Donne une structure autour de laquelle les activités d ' assurance qualité peuvent être construites de manière utile et disciplinée ,

- Fournit un repère pour les acteurs d ' un projet logiciel

II. LES ETAPES DU CYCLE DE VIE

Dans cette partie, nous préciso n s les objectifs de chaque étape du c yc le de vie.

1 . L'ETUDE PREALABLE

1 . 1 Définition BUTS:

- Préciser l'objet du s ystème: Comprendre les besoins et les enjeux ,

- Dialoguer avec les di f f é r e nts t y pes d'utilisateurs

- Esquisser des solutions

- Estimer les coûts et d é lais

- Préparer un dossier en v ue de dé c ision Peut se faire avec l'assistance d'une société de conseil ou d'ingénierie

RESULTATS:

- Décision de développement .

- 1ère version du contrat de développement, 1ère estimation du coût de développement.

- Cahier des charges, Mode de fonctionnement grossier du système.

- Plan général du projet . MOYENS:

- Plan d'entretien avec le client (techniques d'entretien) .

- Certaines méthodes MERISE, AXIAL

- Revue pour valider et approuver les propositions e x hibées.

1 . 2 Cahier des charges

- Résultat des études préalables menées , directement ou indirectement par le maître d'ouvrage.

- Bases de l'appel d'offre ou de la consultation.

- Doit donner tous les él é ments nécessaires pour permettre au maî tre d'oeuvre d'élaborer et chiffrer des solutions .

- Doi t rester strictement au niveau de l'e x pression du besoin et des exigences fon c tionnelles , sans imposer le choix de conception:

- permettre aux soumissionnaires de faire dans leur contexte la meilleure offre

- bénéficier de leurs éventuelles solutions i nno v antes .

1 . 3. Organisation du cahier des charges

- Les clauses techniques

- > Fonctionnalités du logicie l à réa l iser : exprime le besoin de l 'utilisateur en décrivant de manière complète et non ambiguë les fonctionnalités du logiciel à réaliser .

3 / GL: In t r o + cy c le de v ie

A . KO U KAM

-> Contraintes à pren dr e en compte.

- Les clauses de qualité

Obligations du fo u rnisseur en ass u rance & contrôle qualité pendant le d éro u lement du projet.

- Les ela uses généra l es

D ispositions: juridiques, financi è res , commerciales auxquelles la proposition du fournisseur

devra se confo r mer

2. LA SPECIFICATION

BUTS: Définir le "quoi" -> Obte n ir une description précise et sans ambiguïté du système logiciel - Support pour la validation -> D é f mir l a po r tée et l es objec t ifs du projet de man i è r e p r écise.

(Req u irements p h ase, analysis phase)

- Pour le Produit logiciel , déf i nir: les performarces requises, les fonctions du logiciel, l es objets du monde réel m a nipulés, l es interfaces d u l ogiciel avec so n environnement, l esent r ées et so r ties.

- Pour le Pro j e t , définir: les ressources, les con t raintes d e réalisation.

RESULTATS :

Manuel d' utilisation , D ocument d e spécification (spécification dé t ail l ée des besoins) . Plan détaillé du reste du projet , Raffmage de l'estimation des coûts.

MOYENS :

Méthodes, outils, langages de spécification Exemple: SADr , SREM, OOA Revues de spécification. Techniques d e p l anification.

Qu a lités d'une Spé c ifi c ati o n

1. Fi d é l ité : reflète c orrectemen t le besoin

2. Complétu d e: couvre complètement et exc l usivement l'ensemble des besoins

3. Cohérence (non contradiction) : les compromis doivent être mis en évidence

4 . Lisi b il i té : ser t de vecteur de comm un icati on

5 . Indépendance: par r apport aux choix d' i mplémentation

3 . LA C O NCEPTI O N GE N ERALE (Preliminary d esign or architectu ral des i gn)

BUTS: Décrire l'architectu r e d u logicie l

- O b tenir une décomposition d u système en un ense mb le d e modu les

- O b teni r une description précise d u rôle de chaque module.

- Vérifier l a faisabilité et la traceabilité ve r s les spécification : trace ( l ien) entre les fonctions du systèm e et l es mo d u l es l ogicie l s .

RESULTATS -> Docu ment de conce p t i on: description de la str u cture mo d u l aire d u système - Définiti on des mo dule s et d es i nt e r faces. I l faut conserver une trace entre l es fonc t ions du système et le ou les modules intro d uits.

- > Mise à jour du man u el d 'uti l isation

M O YENS -> Méthodes , langages, outi l s de conception: RIPO, STRUCTURED DESIG , JACKSON, ROOD.

- > Revues de conception.

4. LA CONCEPTION DETAILLEE ( Detailed design)

BUTS:

Obtenir une description détaillée des Modules , des traitements et des structures de données permettant un coda g e immédiat. RESULTATS:

Dossier de conception détaillée. Planification des t ests unitair e s. Mise à jour: DS, M U MOYENS:

"Pseudo-codes", outils (PDL). Langages de programmation ? Revues de conception. NOTE: Conception Detaillée = Programmation Abstraite.

5. LE CODAGE

BUTS:

Obtenir les programmes : traduire la concep t ion détaillée dans un langage de programmation en respectant les standards d éf inis. RESULTATS:

Programmes. Documentation technique. MOYENS:

Langag es de programmation . E diteur s syntaxiques , Re v ue s de codes ("inspections") .

6. LES TESTS UNITAIRES (U nit t e s t phas e )

BUTS:

Tester chaque module séparément: exécuter le corps du module et comparer son comportement à un comportement de référence. Il faut élaborer un jeu de données de tests pour chaque module. (attention le test n'est pas une preu v e ) . RESULTATS:

Résultats des tests (+ rapport d'erreur) . MOYENS: Anal y seurs statiques , tests dynamiques , outils de test.

7. INTEGRATION ( Integration phase)

BUTS:

Recomposer le logiciel en modules à partir de ses composants . V érification des fonctionnalités et des performances du s y stème complet. Vérification du respect des normes de pro g rammation. Vérification de la documentation. RESULTATS:

S ys tème logiciel intégr é .

Documentations internes et e x ternes.

MOYENS:

Utilisation de jeu x de te s t s . Outils d ' é v aluation de per fo rmances.

8. VAL I DATION

B U T:

Tester le logiciel dans des condition s représentatives de son utilisation opérationn e lle . Valider le logiciel par rapport à la s pécification des besoins

RESULTATS:

Documents de v alidation . PV d e quali f ic at i o n , rapp o r t qu a lité- f iab i lité Programme certi f i é et i n s t a ll é.

MOYENS:

Ut ili s ation de jeu x de t ests. Con t r ô le qu al it é

9. EXPLOITATION ET MAINTENANCE

Cette phase ne fait pas p a rtie du proj e t proprement dit, mais à l'issue d'un dé ve loppement, il

s

'a v ère toujours que de s mod if ications d o i v ent ê tre appor tées au p roduit:

1C orrection d'err e ur s dé c elées au cour s de l 'ex ploit a tion , 1M o dification du logiciel pour s a t isfaire de nouv e au x be s oins , 1Optimisation de certaines foncti o n s .

III. AUTRES MODELES DU CYCLE DE VIE

1. Modèle par prototypage ( PROTOTYPING )

o

Principe:

Produire r a pidement un e r é ali sat i o n p a r ti e l le du sy stème avant de dé f inir l a sp é cif icat i o n complète des be s oins

.

Les u t ili s ateurs é pr o u v ent de s di f ficu l té s à ima gi ner l 'utili s ation du sys t è m e à partir d es

s

pé c i f i cati ons se ule s

U n e fonction telle qu' e lle e s t décr it e dan s une s pé cif icati on r is qu e d ' ap p araître so u s un nou v eau jou r lorsqu'on l'utilise r a réellement e n conjonction a v ec d'autres fonctionnalités .

.

o

Objectifs :

 

Aider le c lient et les utili s a t eurs à dé fi nir de m a nière cla i re et preci se expérimentant le protot y pe : Cas des s y stèmes complexes, nouveaux

les be s oin s en

o

Approches:

- Pr o tot y pe é vo lutif: Le protot y pe e s t conçu pour évo luer vers le sys t è m e f i n a l .

Sp eci ncanon

R éa li s ation du

E val u ation du

p a rti el l e

~

pro t ot y p e

~

p r oto t y pe

~

Acc e ptation du sy s tèm e

1

- Prototype "jetable " : Le protot y pe est abandonné une fois que l'anal y se et la spécification des besoins sont terminées.

o

E tapes:

- Etabli r les objectifs du prototype , par exemple :

 

- le prototype concer n e p r incipalement l'interface utilisateur .

- ou la validation dès besoi n s fonctionnels.

 

- ou la faisabi l ité du système .

- Dé v elopper une analyse préliminaire pour produire une spécification partiel l e des besoins

- ne choisir que les besoins les plus importants ,

 

- négliger les problèmes du traitement des erreurs , de fiabilité et de qualité.

- Réal iser le protot y pe

 

-

suivre le cycle de vie en mini m isant l es efforts :

documentation simplifiée (pas de document de conception , pas de plan , de test

) ;

utiliser des langages inte r prétés et i nteractifs: LISP , APL, Langage de spécification exécutable

-

Faire expérimenter le prototype par les utilisateurs et compléter l'ana l yse des besoins : évaluation du prototype. - Produire la spécification finale

-

-

Développer le système

o

A v antages

- L'expérimentation du prototype permet aux cli ents / utilisateurs de mie u x comprendre leurs besoins: une bonne base pour le dia l ogue clients + utilisateurs / Analyste.

- L e protot y pe peut aider à mont r er la faisabilité et l ' util ité de l ' application (surtout po u r les dirigeants de l ' entreprise) .

- Possibilité de réutiliser l ' expérience acquise par le déve l oppeur du prototy pe dans l es autres phases du développement .

- Le prototype sert de base po u r spécifier l e système [mal.

o Quelques difficultés

- Manque d ' expérience en matière de planification et d'estimation de coût d'un projet de prototypage.

- Le coût du prototypage peut représenter une fraction importante d u coût total système! (c'est ce qu'on dit !)

du

2 . Modèle transformationnel

Pa rt ant d'une spécification formelle (exprimée dans un l angage fondée sur une théorie b i e n définie) , i l s'agit d ' appliquer un certain nombre de règles de transformati on correcte pour dériver un programme exéc ut able . Le prog r amme est d onc conforme à la spécification initia l e. Ce modè l e reste encore très peu utilisé car i l nécessite des connaissances sur les l angages formels et pose aussi le pro b lème de l ' é l aboration de règ l es de transformation correctes.

3. Modèle de la spirale

Il s'agit d ' une approche hautement itérative du déve l oppement . Au lieu de représenter les phases du cycle chronologi q ue séquentiellement , ce modèle représente l e cycle de vie comme une spirale. On commence par une phase de planification (au centre de la fig u re) pour recueil l ir assez

d

' information en v ue de développ e r le premier prototy pe. Pour chaqu e prototy pe , le processus de

d

é veloppement suit un chem i n s éque n tiel: analyse, co nception , la r éalisatio n, les tes ts ,

l

' int égra tion au x compo s an ts e x i stant s du p r o t ot y p e et la pl anificat ion du pr ot ot y pe s ui v a n t.

. Encore quelques définitions :

Co nstructi on 3 ème pr o to ty pe

Construction 1'" prototype

Pl a nifier la 1ère ité r ation

Méthodologie: f ourn i t d e s lig n es dir ect ri ces p o u r l a r é alisa t i on d e ch a cu ne d es activités du cyc l e de v ie , dont de s mod è l es, out i l s et techn i que s s p é c if iq ue s.

Modèle: est un e repré s entation d ' un aspect quelconque de la réalité ou d ' un système . Il s ' agit

d ' une représ e ntati o n a b s traite pou v ant ê tr e utilisée p o ur étudier un a s pec t d ' un s ys tèm e donn é. P a r

e x emp l e , un mod è le d e donnée d ' un s ys t è me repr és en t e unique m en t les d on née s du s y s t ème s e t

leurs r e l a tion s. Il n e repr ésente pa s l e co mp o r t em en t du sys t è m e n i l es trait e m en t s qu 'il réalis e . C e s

d e u x a s pect s peu v ent êt re représ ent és par d ' autr e s modè les .

Outils: support logiciel permettant d ' aider à créer et e x ploiter les modèles et composantes nécessaires au développement de logiciels. Par e x emple , l e s éditeur s graphiques permettant de cr é er de s modèles objet s, des modèles de traitement, ou des g énérate ur s de cod e s.

Les modèles de cycle de vie

~ Le modèle de développement par

prototypage :

• Consiste à explorer rapidement et à moindre frais les fonctions, l'architecture et la convivialité d'un logiciel.

• Efficace dans les projets où les besoins sont mal définis.

• L'intérêt réside dans sa capacité à clarifier et à compléter les spécifications et à déterminer les caractéristiques souhaitées.

~ Possibilité d'essayer les Interface homme/machine

;-

A . kouk a m , Professeur des Universités à l 'U1 BM

ANALYSE ET SPECI F ICATION DES BESO I NS 1ère Etape du c y cle de vie

1 . DEFINITION C'est le processus visant à établir quelles fonctionnal i tés le s y stème doit fournir et les contrai ntes au x quell es il sera soumis. R e p o ndr e au quoi et non au comment?

2. OBJEC T I F S

1 Comprendre la nature

1 Fournir un document compréh e nsible par le c lient et les concepteurs du s y stème: Le fondement du

contrat

! Dé f ini r l a base pour l a v alidation d e s éta pe s ultér i e ur es. La va l i dation ut i l is e la s péc i fi cation c o m me

e x acte du pr o blèm e . Par l'anal y ste et par le client

ba s e p o ur rép o ndre à la que s t i on prin c i pa le suivante : A t'on conçu ce qui a été demandé? 1 P récis er l es co n t raint e s d e r éa li sati o n .

1 Pr e ndre d es d éci s i o n: Développer? Acheter? Louer? Sous -traiter?

1 R é duire les c oû ts d e d é veloppement du s ys t è m e.

U ne spécifica tion ri g oureuse d e s besoin s p e rmet d'évit e r les oublis p o u v ant appar aît r e t a r d i ve m e nt

d

a ns le c yc l e d e vie. En e ff et de tels o ublis n écess ite nt d es r eto u rs e n arr ière, c e qu i a u g m ente les coûts

d

e d é v el o pp e m e nt : Ev iter l ' oubli, le s allers re t our s da ns le c y cle de vie

3. L E S ET A PES

1 Anal y se des besoins (Requirem e nt Analy sis) : R asse mbler t o ut es l es inf o rm a t ion s n écess aires à

la c ompréhen s ion du problème

: Spé c if i e r de m a n i ère c l aire et p r éc i s e l e

1 Spécification des besoins (Require m ent Sp e c i fication)

r és ult a t de l 'an a l y s e en u t il isan t d es m éthod es d e mo d éli sat i on (voire é t ape de s p écification) . No u s all ons d 'ab o r d pr éc is er ce que n o u s qu a lifions d e b esoins en l es c l assons e n de u x catégo r ies.

E n s u i t e, n ous d on n o n s qu e lqu es é l é m en t s p e rm etta nt d ' a b o rd er l 'analyse pu i s l a s p écif ica tion .

Les él é m e nts c lés de l ' analyse e s t d e la spéc i fi ca tion s ont d o nc l e s b es oins que l ' o n peut c l as ser e n

d e u x catégo ri es :

» Besoins fonc t ionnels (e x igences fonctionnelles) : les servi ce s qu e l ' u til is ateur a t t end d u

s ystè m e . Il s'ag i t de s ac t ivités qu e l e systè me d oi t exéc u ter . D ans p re m ier tem ps, ces be soins peu ve n t être e x prim és en lang a g e nature l acco mp ag né é ven tu e lle m en t d e di agra m m es gr a ph i ques .

E x emple: le système de di s tribution automatique de billets de banque (DAB).

1 Le s ys tème d o it vérifi e r l a v alidi té de l a car t e.

1 Le sys t è me d oi t m e tt re à j ou r le c o mpte du c l ien t a p rès u n ret rait o u un d é p ôt . » Besoins non fonctionnels ( spécifications techniques)

L es c on traint es s ou s le squelle s le systè me d o i t r es ter o p érationn e l et l es s t a ndard s a u x qu e l s i l

doit se conformer . Par exe mple :

1 Les b e soins en performance

E x emple: l e _s y st è me doit r é p on dr e à un c lie n t au b o u t d e 2 se co nd es a p rè s l ' inser t i on d e la

carte .

1 L es co n t raint es de d éve l o pp eme n t ( pr ocess u s d e d éve l o ppeme nt )

E xem pl e : l e systè m e d o i t ê tr e i mp lan té s u r un e mac hi n e s upp o r tan t l e sys t è me d 'ex pl oi t ation

UN I X .

1

h

A . koukam, Professeur de s Unive rs it é s à l ' UTBM

4. ANALYSE DES BESOINS Acteurs : regroupent tous les intervenants qui constituent la source d ' information pour l'élaboration des besoins. Un intervenant peut appartenir à l'une des 4 catégories suivantes : 1) les utilisateurs qui vont exploiter le système et utiliser ses fonctionnalités 2) les clients qui investissent dans le développement du système et qui en sont propriétaires 3) le personnel technique qui est responsable du bon fonctionnement du système dans l ' environnement de l'organisation 4) éventuellement les entités extérieures , tels les clients de l'organisation. La première tâche de l'analyste est d'identifier chacun des types d'intervenants concernés par le système à construire. Procédé:

1 Séries de questions posées aux intervenants (clients, utilisateurs,

1 Eventuellement, les documents foumis par le client

1 Analyse de la tâche, généralement quand il s'agit d'automatiser une activité manuelle.

1 Création de modèles pour représenter et communiquer les besoins. Par exemple, la modélisation des besoins fonctionnels par des cas d'utilisation (UML) et des données par une première ébauche d'un diagramme de classes . Problèmes rencontrés: divers et en particulier:

1 Comment organiser et structurer les informations obtenues?

1 Comment résoudre les contradictions pouvant exister entre les différents interlocuteurs? Eléments de solution:

1 Utiliser les méthodes d'analyse: SA, SADT , Merise, OOA (UML)

1 Qualités de l'analyste en matière de communication 1 Appliquer les trois principes suivants :

)

1 Décomposition: Appréhender le problème en le décomposant en plusieurs parties. Cas d'un système d'exploitation: difficulté d'appréhender tout le système dans sa globalité. = > Le décrire à travers ces composants :

- système de gestion de f ichiers

- système de gestion de la mémoire

-système de gestion de processus. Après la décomposition, on peut étudier chaque partie séparément. 1 Abstraction: Appréhender le problème à un bon niveau d'abstraction. Eviter les détails. Par exemple , pour le système de gestion des fichiers d'un système d'exploitation, décrire les

fonctions de haut niveau sans se sorcier dans un premier temps de l'organisation des fichiers en mémoire secondaire :

- création et destruction de fichier

- ouverture et fermeture de fichier

- gestion des répertoires

- interface utilisateur

1 Proj ection : Etudier le système à partir de plusieurs points de vue.

Cas d'un système d'exploitation . Analyser selon:

- le point de vue de l'utilisateur

- le point de vue du programmeur

- le point de vue de l'administrateur

Pour chaque point de vue , identifier les besoin s qui lui sont associés.

5- Spécification des besoins Il s'agit de décrire de manière précise et à travers des modèles les besoins du système : rendre plus formalisés les résultats de l'étape d'analyse . Le document qui en résulte est le document de

spécification.

.

2

A . ko u kam , P r of e sseur d es Uni v ersi t és à ] ' U fBM

Caractéristiqu e s d'un bon document de spécifica tion .

~ Doi t spéci f i e r uniquement l e comp or tement e x t er ne du sy stème et l es rép o nses au x é v éneme nts

n o n d ésir abl es.

~ D o i t spé cifi e r l e s cont r ai nt es d e r éal i sation.

~ Doit êt re facile à mettr e à j o ur .

~ D o it c o ntenir d es indi ca ti o n s c oncer n an t l es é t a p es ulté ri e u res .

~ D o it s erv ir d' o u ti l de référ en c e p ou r l a validation et l a m a inte n ance .

~ D o i t êt re c o mpl et e t c o hé rent . Les principau x composants d ' une spécification

P e u v e n t ê t r e c la ssé s en 3 ca t égor ie s : les be soi n s fo n c t ionnel s, l es b esoins no n f o nctionne l s et les interfaces exter n es. Nous allo n s les d écrire sé p arément .

5.1 Les besoins fonctionnels

D éf in i tion : L es se r v i ces o u l es f o n ctionna li tés q u e l 'utilisateur atten d d u système. P our cha q ue service :

- les d o nn ées n écessaires à l'exéc u t i on du serv i ce

- l es r é sult a ts qu ' il pr o dui t

- un e d e scrip t i on g én é r a le d e s on r ô l e

- le traitement d es e r r eu r s

L' ex p r ession d es b eso ins f o n c ti o nn e l s peut prend re plu si eu r s fo rm es se l on la m éth o de et l e lan gage de

s p éc ifi cat ion c h oisis et l e nivea u d e d é t ai l à attein dre. Nous a llons exp l orer l es diffé r entes formes

d'expressio n poss i b l es tout e n soulignant leurs avantages e t l eurs i n convénients. Il s'agit ici d ' une

pr ésent atio n sy n thé tiq u e : n ou s co n sac r eron s u ne b on n e par tie d es cours s ui vants à l ' étude d étai l lée d es

d

e u x d ernières mé t h o d es e t l a n gage s de spé cifica tion ( mét h o de s s emi - for m e l s trè s u til isée s: U ML ,

S

A, SA DI et métho d es formelles : s péci fi cat i ons algé b ri q ues, l angage Z et B ) . L e s deux premiers

l

a n gages q ue nous présenton s ci - d esso u s ( l angage naturel, langage st r ucturé) so n t s i mp l es à

co mprendre e t co n s t i tu e nt deu x m oyens d ' ex pr ess i o n s p ouva n t ê t re u t ili sés p o ur d oc u ment e r l es

s p éc ifi cati o n s const r uit e à l 'a id e d e mé t ho d e s for m ell e o u s emi- f or m e lles.

Mé thode s e t Langage s d ' e x p r e ssi on d es be s oins fonc t i o nn e l s

5 . 1 . 1 . Sp é cific a tion en Langa g e nature l

D ans ce cas, l es fo n ct i ons (o u serv i ces) du système sont défmies en util isant l e l angage natu r el

éve n t u e ll e m e nt e n i ntr o d ui s a nt d es sch émas et d es tab l ea u x .

E xe mple

é l e ct ro n i qu e)

F onction: « Fo u rnir un ticket »

- Fo u r nir un e preu ve d'a c h a t a u c l ien t

- Fo urnir une preu ve d e l a tran s a c t io n (cas p aie m e nt acce pt é)

Fonc t ion: « Co m m un iqu er avec le systè m e d e p a i e m ent»

de qu e lq u e s f on c ti o n s du s y stème IP E

( d éve l o pp ement d ' un t er min a l d e pa i e m e nt

-

p ermettre a u TPE d e d ialoguer avec l e système de p a i eme n t par carte.

l

Ava nt ages de ce m o de d ' e xpressi o n:

-

plus ex p ressif.

-

co mpr é hen si bl e à l a f oi s p a r l es c l ients et l es d évelo pp eu r s.

1 Inc o n v énien ts :

- beso in s f orct ionnel s i mpré c is à cause d e l ' amb iguité i n hé r ente au l angage natu r el.

- mé l a n ge d es b esoins fonctionne l s et non fonctionnels .

- l a s p éci f i cat io n est be a u co up tr op f l exi bl e : l e ris q ue d 'expr i mer d es b esoins voisins d a n s des termes tota l e m e nt d i ffé re n ts.

3

A . ko u kam , Pr o fe s seu r d es U ni vers i tés à l ' u m M

- les beso i ns ne sont pas cloisonnés : les c o n sé que n ces d'un ch a n g eme nt ne peu v ent être évaluées qu ' après un e x amen de chaque b esoin, e t non d'u n gr o u pe de besoin s v oisins .

5 . 1 . 2. Spé c ification en Langage structuré

U t i lisation contrôl é e du lan g a g e naturel et de formulair e s sta ndards de spéci f ica tio n . Les formulaire s

peu ve nt ê tre structurés autour :

- des objets manipulés par le s y stème.

- des fonctions qu ' il remplit ( ce mode de structurat i on est le plus utilisé lorsqu'on se ba s e sur un langage structu r é) .

- des évènements q u'il doit traiter .

Exem p le :

Fonction:

V éri f ier validité

c ar te

Description :

Cette fonction v ér i fie qu e la c a rte introduite par un utilisateur

provient d 'une banque reconnu e, qu'elle e s t à j o ur , et

a i nsi qu e des détai l s sur les d at e s e t les m o nt a nt s de s préc é den ts retr a its .

Entrées: identification d e l a banq ue, num é r o de c om pte, date d'expiration , d a te e t na t ure de la

d e rni è re transaction .

Sorties : Etat de la c a rte = ( OK , in va lide ) Besoins : Li s te de s ba n qu es, f or ma t du c o mp t e , d a t e du j o ur Pré - condition : carte i nt r o dui te e t b a nde m ag n éti q u e lu e Post - condition : Id e nt i fi ca t i on d e la banqu e d a n s la liste des b a nques et N u mér o de c om pte a u b on for m a t et date d'e x pir at ion > = d ate d ' aujourd ' hui et Etat d e l a c a rte = OK ou (si l'u n de c es tests e s t r au x) E t a t de la ca rt e = in va l i d e

qu'el l e contient des i n f o rmati o ns appropri é es

Cette sp é cification utilise l es pr é et p ost co nd itio n s p o u r d é c r i r e l e r ô le d e la f o nc t io n . L es o bje ts

utili s é s (Liste des b a nque s,

spéci f ication n'int r oduit pa s d'in fo rmati o n sur le séquencement dans la d é finition des pr é e t post conditions .

1 Avantages de ce mode d'e x pression :

- évite u n cert ain nom b re de p r o blèmes de structurations.

- peut ê tre supporté par d es outils .

1 Inconvénients: d emeure le probl è me de l ' ambi g uïté dû à l 'utilisation en partie du lan g ag e naturel .

) doi v ent êt re dé f inis da ns un d i ctio n naire de données . N o t o n s que cette

5.1 . 3. Spé c ifications semi - formelles

) , ces spéc i fications so nt e x p r imées

d a ns des langages g ra p hiqu es. E lles son t tr ès co ura mmen t util isé e s e t b énéf i c ient d ' en v ir o nnement s

log iciels d ' aide à la spé ci f i ca ti o n . No us c o n sa c r erons un e bonne p a rtie du c ou r s à c es m éth o des . A t i tre

d ' exempl e, v oici une s pé c ifica t i o n ex pr i m é e en SAD T ( S t ructured Anal ysi s a n d D e si g n Te c hniques ) .

Généralement associées à d e s m é th o d o logies (S A, SAD T, UM L ,

L i r e

carte

Le c te u r

c

i e c a rt . e

Cart e i l lisible

Vé r ifi er

va l idi t . é

Car t e n o n vali d e

Cod

 

Mettre àjo ur

 

l

e co mpte

Montant

4

A . koukam , Pr ofe s se ur des U n ive r si t é s à l ' u mM

SADT est une mé t hode qui anal y se un sy s tèmes en mettant l ' accent sur l es foncti o ns qu'il d o it ré a liser.

Chaque f o nction peut ê tre d é c o mp osé e en plusie u r s autre s fo n ct i o ns ( d écom p o s it i o n fo n ctionnel le d 'un

s y stème). Un rectangle (appelé actigramm e) repr ésente un e foncti o n du s y st è me . L e s flè c hes entrantes

(re spectivement sortantes) représe n t ent les d o nnées (respe c t iv em e nt

d e s s ous d e la f o nctiorm a lité « Lire carte» pr é c i s e le supp o rt p hys ique né cessai r e à l ' e xé cuti o n

le s résultat s).

La flèche

en de ce tt e

o nct i on .

f

5.1 . 4 . Spécifications formelles

se sont des spécifications e x primée s dans de s la n gage s possédant une sém a ntique formelle per m ettant

de raisormer sur la spécif i cation pour faire des preu v es d e pr o priét é s . Proche d e s mathématique s, ces

l a n g a g es s ont g énéral e ment

s yst èmes formels . Nous d o rmon s ci - de s sou s un des types abstraits de dormées .

o u l es

fondés s ur la l og iqu e du prem ie r ord re, l a th éo r i e de s en s embles

ex emple de tels l a nga ges: l a s pé c ificat io n al g éb r ique

E xe mple: Spécification a l g ébrique du t y pe P i l e

t y pe P i le (ELT )

opératio n s: décrit l' inte r f a ce du ty pe en do nn ant s e s opé r a tio n s e t l eu r s inte rfa ces creer : - - - > Pile , cha que opé r ation est définie par s o n domai n e de départ et so n d o m a i ne d'a r r i v ée

empil e r

: Pile

* ELT - -- > Pile

depi l er

: Pile

--- > Pile

v ide

s

om m e t

: Pile - - - > Bo o l é en

: Pile -- - > E LT

Axiomes: d écri ve n t l es pr o pri é t és d es o p ér a t i ons ou serv i ces pr oposés.

d e piler ( créerO) = cr é e rt )

d e p i ler ( empiler ( p , e » = P vide (cr é er) = vrai

v ide ( e mpil e r ( p , e» = fau x

sommet ( empiler (p , e ) = e

sommet (créerO) = indéfini fin type

A v an t ages :

- spécifica tion précise e t s an s ambi g uïté

- po ss ibil i té d e faire d es preu v e s de comp lé tude et d e c o n s i st an c e

- peut être trait é e de manière aut o matique gr â ce à des outi l s

- p os sibilité d'avoir des spécification s exécutables

I n con vé nie n ts :

- nécessite un grand effort de formation

- non compréhensible g énéralem e nt pa r les clients

Conclusion sur les méthodes de spécification :

Nous venons d'ex aminer les différentes cla s s e s de m é thodes e t d ' e x pressi o n

a l o rs l a qu e lle c hoisir ?

I l n ' y a pas de réponse uniqu e et valable p o ur t ous les sy s t ème s . Disons que dans la prat i que et p o ur d e

de s s p é cifi c ati o n s . Mais

n

o mbreu x systèmes , on utili s e les m é th o des s e mi-form e ll e s

qu e l ' on d o cum e nt e

à l 'a id e du la nga g e

n

at u rel et du l a n gag e st r uc t uré (vo us f e r e z l ' ex péri e n ce

à tr av e rs le proj et q ue vo u s al lez r éa li ser ). B i e n

q

u' elles s o i e nt trè s peu util isées , l e s mé t h o des f o rm e ll es ont mon t ré d a n s l ' indu st rie

leur e f fic a c i t é

dans la spécifi cation de c ertains sy stème s critiques (une parme peut pro v oquer une c a ta s trophe ). G râ c e

à l a p oss ibili té

m é th o d es c o n s titu e nt un pa s v ers l a ce r t ificat io n f o rm e ll e d e logi ciel s .

d e pr o u v er

form e ll e m e n t le s pr o pri étés d ' un systè m e

a vant s a mi s e e n œ u vre , ces

5

A . k o u kam , P r ofe s s e ur d es Univ e r s i t és à l 'UT BM

5.2 Les be s o in s n o n fon c tionnels Ils constituent l es buts opérationnels liés à l'environnement au matériel et aux logiciels de

l ' organisation. I l s d écrivent aussi l es restrictions ou les contraintes qui pèsent sur le s y stème et en

particulie r sur ses services. On peut les su b di v i ser en plusieurs pa r ties que nous pré s entons c i- desso u s . Besoi n s e n perf o rm a nces

- Tem p s d e r é p o n se exigé un e r e q uête par exemp le)

- Tai ll e d es inf or m ations m a nipu lées e t esp ace mémo ir e nécessa i re

- R estr i ctio ns su r l a re p résentatio n des do n nées

- Nom b re m oy en d e t r ansactions pa r sec onde

- No m b r e de t e rmi na u x co nn ectés a u systè me

Vo i c i un t a bl e au d e m ét r iq u e qui r ésume e t d o nn e d ' a u tres é l é men ts liés a u x p er f or m ances.

Propriété

Vi t esse

Métrique Nom b re de t r an sactions par seconde Temps de réponse à l 'utilisateur / à u n événement Temps de raf r aîchissement de l ' écran K octets, nombre de puces de RAM

Taille

Facil i té d 'utilisation Durée de f o rmation , nombre d ' écran d ' aides

F i abilité

Temps mo y en entre deu x pannes , probabilité d e n o n d isp o nibilité , Tau x d'apparition des pannes

Temps de redémarra g e après une panne,

P ou r centage d 'événements ca u sant des pannes ,

Proba b i lité de cor r up tion d e données su r une faute Pourcentage d 'i n st r ucti o ns dépendant de l a cib l e

R obustesse

Port a b ilité

Les c on tr ain t e s de c o ncep t ion

ex prim e n t l es c o n tr a in te s s u r le p rocessu s d e d éve l op p eme n t

- ut i li sa tion d e m ét h o d es stand ar ds

- l a n gage de p r o gra mm ation

- systè me d 'exp l o it ation

- matériel s

- str u ct u r e d e l a d ocu m entat i o n (format d e ra p ports)

Exemple d e cont r a i nte d e concept i o n:

"Le process u s d e d éveloppement d u système et les documents devront être conformes à la norme D EF- STAN 00- 65 "

5

.3 L e s in t e rf ace s e xt e rn es

e

x priment l e s relations entre l e s y stème et :

-

Les u tilisa t eurs d u système: l e s messages d 'erreurs ( clarté , l ongueu r ), la d escription des formes et

éditio n s su r pa pi er et

écra n s

-

Le matérie l : l orsque le système à dé v elopper i ntera g it a v ec un s y stème m a tériel , il f a ut d écrire

l

' interface en tr e l es d eux

-

Le l ogic i e l : li a i son avec une b ase de d on n ées, des b ib l iothè qu es mathématiq u e s, gra p hiques, les

p

rocé dures d 'éch a n ge de messages .

6

A. koukam, Prof es seur d es Univer s it és à l' U TBM

6. Structure d'un document de spécification Sommaire: plan du document

 

1

- Introduction

: :

·

Buts et destinataires du document

 

-

Défmir en quelques lignes s ' il s ' agit de d év elopper ou d ' améliorer un système

- La manière dont le s y stème s ' insère dans les objectifs comm e rciaux et straté giqu e s d e l'organisme commanditaire.

 

·

Définitions - Abréviations

 

-

Les termes techniques utilisés

-

Les abréviations

 

·

Présentation générale du document ( comment il est organisé)

2

- Description générale

·

Environnement ou contexte du système

Décrit les relations du système avec d'autres systèmes et les principales interfaces avec ceux-ci.

- Donner un diagramme , faisant apparaître le système et les acteurs avec lesquels , il interagit . Le

système est vu comme un grand cas d'utilisation. (d; ~ cQ

r'T I N

4t. (

.0 r i \ . u . k . ')

- Commenter en langage naturel, les acteurs et leurs interaction a v ec le s y stème .

· Modèle conceptuel

.

/

,

}

6 J fL

Une description de haut niveau des principales f o nc t i o ns du système , les relation s entre elles et l e s entités qui interviennent à ce niveau .

· Caractéristiques des utilisateurs

Identifie les différ e nts t y pe s d'utilisateur du système e n , pr é cis ant leurs car a ctéristiques.

- Expérience et connaiss ances dans l ' utilisation d e s s y stèmes informatique s.

- U tilisateurs réguliers ou occasionnels

· Les contraintes principales de développement

Précisent l e s procédures, les normes et les standards à utiliser dans le dé v elo ppement .

· Hypothèses de travail

Décrivent tous les facteurs susceptibles de remettre en cause tout ou une partie de la réalisation des spécifications ainsi que d'éventuelles solutions de repli.

3 - Besoins fonctionnels

,·l

-c

/

. ~ - Décrire les cas d'utilisation du système, en les regroupant par acteur, ou par grande fonctionnalité.

-Commenter les cas d'utilisation en utilisant des formulaires tels que:

;- nom du cas d'utilisation

· Description (Rôle, présentation générale)

· les acteurs concernés

· Les entrées et leurs provenances

· Le traitement

· Les sorties (messages d'erreurs éventuellement)

4- Spécification des structures de données Donner un modèle décri v ant les entités du systèmes et leurs relations. (ce chapitre comprend une section par entité )

-

Nom de l'entité

-

But et essence

-

Eventuellement les relations avec les autres entit é s , leur s cardinalités

5

- Spécifications des interfaces externes

·

Interface matériel/logiciel

- Configuration minimale et optimale sur laquelle le systè me peut s'éxécuter

- Les caractéristiques des interfaces entre le système et l e s dispositifs particuliers :

- Capteurs, actionneurs, périphériques (lecteur de chèques, de code à barres,

- Protocole d'échange (réseau local,

)

.)

7

A. koukam, Professeur des Universités à !'UTBM

- L e t y p e d e l iaiso n (séri e , p aral l èle,

)

. I nterface l ogic i el ll ogicie l

Pour chaque logici e l util i s é e x plicitem e nt

biblio thèq ue de fo nct i o ns m at hém a tiqu es, ser v i c es du syst ème d'exp l oita t io n , i l fa ut préc i ser : le nom , son nu mé r o de version, - sa provenance, le b ut de son utilisation , et d é fi n ir l 'interface, é v ent u ellement en renvoyant à une a nnexe o u u n a u tre d ocument .

par e xe mple

s ys tèm e de ge s t i o n d e ba ses de d o nn ées,

. I n t erf ace H ommellogici e l

- S pécificati on

- Sp écif icat ion de s m e nu s, d es m essages d ' erreur

- D é fmit i o n d 'un m an u el d ' utili sa t eu r ( p rél i minaire)

evoir cours p récé d ent)

des ~ f or rne s d e s éd i t io ns sur papi ers et s u r é cr ans

6- L es b es oin s en p e rformance

- N omb r e ma x imum d e t e rminau x

- Nombr e ma xi mum

- No mb re de fic h i er s et l e ur s tail l es

- Te mp s de répo n se souhaité

- L es con t r a i n tes liées à l ' environneme n t (temps réel)

d e tr a n sac ti ons s imu lta n ées

7 - L es contraintes d e dé ve loppem e nt

( Vo ir c o ur s p ré c é d e nt)

- F i a bilit é et t o l ér an ce a u x fau te s

- Le compo r tement d u système d ans d es situations anormales ( l e s e x ceptions crit i ques)

- Séc u rité

· Re s tr ict i on s u r l ' ut i l i s at io n d e ce rt a in es comm an des

· C o n trô l e d e s ac c ès a u x don nées

· Uti l is a tio n d e mot de passe

- Ut i l i satio n de stan d ards en ce q ui concerne les méthodes, ou t ils et lan g ages de d év el o ppement .

8

- R é f é r e nc es

D

écrit :

 

-

les r éfé r e n ces b i b liogra phi q u es

-

l es sources d'obtention des d ocumen ts

Il faut donner l es références de tous l es d ocuments utilisés dans l 'élaboration de la s p écificati o n .

9 - In d ex

- Ind ex alph a b é ti~u e ,

- Ind ex

d e s f oncti o ns /

10 - A n n e xes

.

Ii

- l { l · h~C

J

m

û-

~

~ .vW40~aJ;:€J1v.:>

- D es c riptio n rap id e des méthodes u t i lisées

- D es cripti o n

par agra phes p récéd e n t s .

r a pide d es sys t è me s

, out ils e xternes a u systèm e et q u i sont uti lisés d ans l es

7. Biblio gr aphie -1. S o mmer vi lle. " Sof tw are E n gi neer i n g", 3r d ed n. W okin gh am : Add iso n-W e sl ey, 19 8 9

. j Sa tzin ge r , R . B. Jac kso n , S. B urd . "A n a l yse et conc ept io n des syst èmes d ' i n fo rm at i o n ", E dit i o ns

R yno ld G o ul et, 200 2.

-1. Jaco b son , G . B ooc h , J . Ru m b a u gh , "T h e Unif i ed Software D evelo p ementPro c ess" , A ddiso n- Wes l ey, 199 9 .

- A . Ko uk a m. " Soft w ar e E n g in eeri n g", C ou rse In t r o duc t i o n to S oftware E n g i neeri n g , U ni ve r s it y of

Qa t ar, Doh a, 2 002 .

r:

8