GÉNIE LOGICIEL

1 Séance 3
Durée : 3h
 TECHNIQUES DE SPÉCIFICATION

Alouane S.
2 M.A en Informatique
INTRODUCTION

3
INTRODUCTION

4
INTRODUCTION

5
 INTRODUCTION
Enjeu  faire le BON système, celui dont on a besoin.
Si on ne sait pas (exprimer) ce que l’on veut que le système fasse, il
ne le fera pas.

Le produit de la phase de définition/spécification des besoins est le

cahier des charges du logiciel. Le cahier des charges constituera
le contrat entre le client et le développeur du logiciel (le maître
d ’ouvrage et le maître d’œuvre). Selon la taille du projet, le
cahier des charges peut consister en quelques pages ou s'étendre
sur plusieurs volumes

Lors de l'écriture du cahier des charges, il est recommandé de

séparer les spécifications fonctionnelles des spécifications non-
6
fonctionnelles.
 SPÉCIFICATIONS FONCTIONNELLES

Les spécifications fonctionnelles décrivent les fonctions (ou les

opérations, ou encore les transformations) que le logiciel doit
réaliser.

Chaque fonction sera décrite en détail, en spécifiant ses entrées et

ses sorties.

Spécifier le comportement du logiciel en cas de problèmes avec le

matériel (par exemple, panne de périphérique, panne du
processeur qui peut avoir des conséquences sur la cohérence
d'informations stockées sur un fichier, etc.).

Toutes ces spécifications ne doivent décrire que le comportement

externe du logiciel.
7
 SPÉCIFICATIONS NON-FONCTIONNELLES
Les spécifications non-fonctionnelles sont toutes les spécifications qui
n'expriment pas une fonction du logiciel.

Expriment des contraintes et sont de deux types:

 Les contraintes d'interface. Ce sont les contraintes imposées par
l'environnement logiciel (par exemple: le programme doit s'exécuter
sur tel système d'exploitation), par l'environnement matériel (par
exemple: le programme doit utiliser les caractéristiques de tel
terminal) ou par l'environnement humain (par exemple: les
commandes mises à disposition doivent satisfaire telle ou telle
contrainte);
 Les contraintes de performance. Il s'agit par exemple de contraintes
de mémoire (mémoire principale ou disque), de temps de réponse,
des contraintes de sécurité, etc. 8
 QUALITÉS
Un bon cahier des charges peut être caractérisé par les 7 qualificatifs suivants
[IEEE 830]:
 non ambigu
 complet
 vérifiable
 consistant
 modifiable
 traçable
 utilisable durant la maintenance.

non ambigu :grande précision dans l'utilisation des termes introduits (si
possible définir les termes dans un glossaire faisant partie du cahier des
charges);
complet : ne pas oublier de préciser le comportement d'un logiciel lors
d'événements non désirés (panne du matériel, erreur dans les données
introduites par l'utilisateur, etc.). Ce n'est pas au programmeur d'inventer lors
de l'implémentation ce que devra faire le programme dans de telles
9
situations;
 QUALITÉS

vérifiable : Une spécification non vérifiable est par exemple: "le logiciel
doit être facile à utiliser";

consistant : Un cahier des charges n'est pas consistant si deux

spécifications sont contradictoires. Le problème devient sensible à partir
d'une certaine taille du cahier des charges;

modifiable : Les spécifications peuvent changer soit durant le

développement du logiciel, soit durant la phase de maintenance. Ces
modifications doivent pouvoir être reportées facilement dans le cahier
des charges;
10
 QUALITÉS

traçable : Le traçage est la possibilité d'avoir des références croisées

entre les spécifications de plusieurs versions du cahier des charges.
Le traçage arrière consiste à pouvoir, à partir d'une spécification,
retrouver la spécification dont elle découle (dans la version
précédente du cahier des charges). Le traçage avant consiste, à
partir d'une spécification, à trouver les spécifications auxquelles
elle a donné naissance (dans la version suivante);

utilisable durant la maintenance : Le cahier des charges devrait

tenter de prévoir certaines évolutions du logiciel.

11
FORMULATION DES SPÉCIFICATIONS
 Formulation des spécifications
 Les spécifications s'énoncent habituellement en langue naturelle, dans des paragraphes numérotés (ce qui permet d'y faire référence). La langue naturelle présente bien entendu des risques d'ambiguïté et ne permet pas de faire des
vérifications de consistance. Ces risques ne sont toutefois pas trop graves dans le cas d'un projet modeste. Remarquons également que dans le cas d'un développement dans un domaine neuf, il est souvent impossible d'énoncer les
spécifications (qui sont inévitablement imprécises) autrement qu'en langue naturelle.
 Voici à titre d'exemple, quelques spécifications tirées du cahier des charges pour l'environnement de programmation de Ada (cahier des charges baptisé STONEMAN);
 4.C.1 Une interface virtuelle, indépendante de toute machine hôte, doit être fournie pour communiquer avec l'APSE (Ada Programming Support Environment).
 4.C.2 L'interface virtuelle doit être basée sur des concepts simples, évidents à comprendre et à utiliser, et peu nombreux.
 ...
 4.C.8 Toutes les communications entre l'utilisateur et l'APSE doivent pouvoir s'exprimer en utilisant le jeu de caractères standard de Ada.
 Ces spécifications appellent les remarques suivantes [Sommerville 82, p 16]:
 la spécification 4.C.1 est une spécification fonctionnelle. Elle décrit de manière imprécise (la portabilité est souvent difficile à exprimer de façon formelle) une fonction, à savoir une interface virtuelle, qui doit être fournie par le logiciel;
 la spécification 4.C.8 est une spécification non-fonctionnelle;
 la spécification 4.C.2 est une spécification non vérifiable (cf. section 2.1), difficile à classer (fonctionnelle, non-fonctionnelle ?), qui n'apporte pas grand chose;
 les spécifications fonctionnelles et non-fonctionnelles ne sont pas clairement séparées.
 Suivent quelques spécifications fonctionnelles et non-fonctionnelles pour le programme de vérification de fautes de frappe [Wiener 84, p 20]:
 Spécifications fonctionnelles
 1. Lorsqu'un mot non identifié est rencontré dans le texte, l'utilisateur doit avoir le choix entre remplacer le mot par un mot de substitution, insérer le mot dans le dictionnaire, rechercher des mots similaires dans le dictionnaire afin d'en
déterminer l'orthographe correcte, ou sortir du programme.
 2. Toute la ligne contenant l'éventuel mot mal écrit doit être affichée au terminal.
 3. L'utilisateur doit avoir la possibilité d'afficher les mots du dictionnaire qui débutent par une chaîne de caractères indiquée.
 ...
 6. Le programme ne doit pas s'arrêter lorsque le dictionnaire est plein.
 ...
 10. Chaque fois que c'est possible, les données entrées par l'utilisateur doivent être vérifiées, et en cas d'erreur, le programme affichera un message approprié.
 Spécifications non-fonctionnelles
 11. Le dictionnaire doit être capable de contenir au moins 40'000 mots. Des techniques de compression sont acceptables.
 12. Le logiciel doit être capable de traiter 250 mots à la minute.
 13. Un mot est une chaîne d'un ou plusieurs caractères délimités par des caractères ne faisant pas partie d'un mot. Les caractères qui font partie d'un mot sont les lettres majuscules et minuscules (sans distinction entre elles) et les
apostrophes.
 14. Les méthodes internes de tri et de recherches ne sont pas critiques dans la définition du système. Les méthodes doivent être efficaces du point de vue du temps de calcul et utiliser un minimum de mémoire.
 ...
 16. Le dictionnaire doit pouvoir être contenu sur une disquette de 5 1/4 pouces double-face, d'une capacité de 400'000 octets.
 17. Les mots jusqu'à au moins 13 caractères doivent être analysés pour vérifier s'ils sont écrits correctement. Les mots plus longs doivent pouvoir être affichés au terminal, afin de permettre à l'utilisateur d'en vérifier l'écriture.
 ...
 20. Les commandes du programme doivent être présentées sous forme de menu clair et concis. Ces spécifications appellent également quelques remarques.
 la spécification no. 10 est vague. Une information plus précise peut toute fois éventuellement être trouvée dans le manuel de l'utilisateur préliminaire joint au cahier des charges;
 la remarque concernant la compression du dictionnaire (spécification no. 11 ) ne semble pas à sa place: la décision de compression doit être un choix d'implémentation;
 la première partie de la spécification no. 14 n'est pas claire: la deuxième partie n'est pas vérifiable;



les adjectifs "clair" et "concis" de la spécification no. 20 en font une spécification non vérifiable;
la spécification no. 11 apporte-t-elle vraiment quelque chose par rapport à la spécification no. 16 ? Que faire si une disquette de 400'000 octets est pleine, alors que le dictionnaire contient moins de 40'000 mots ?
12
TYPES DE SPÉCIFICATIONS

1. Langage naturel

2. Présentations formatées

3. Techniques graphiques ou semi-formelles

4. Spécifications formelles

13
 LANGAGE NATUREL (1)

a. Énoncés informels:

Description en langage naturel pouvant respecter des plans types

(standardisés ou propres à une entreprise ou à un projet).

Risque (surtout dans le cas de systèmes de logiciels complexes) :

 de non cohérence,
 d'ambiguïté,
 de non complétudes,
 de difficulté d'organisation,
 de redondance d'informations.

C'est la raison pour laquelle différents outils ont été développés

permettant de résoudre tout ou partie de ces problèmes
mentionnés. 14
 LANGAGE NATUREL (2)
b. Énoncés structurés

 Beaucoup de spécifications reposant sur l'utilisation

contrôlée du langage naturel et sur l'utilisation de
formulaires standards de spécification, ont été
développées

 Une approche de la spécification basée sur l'emploi de

formulaires peut être organisée autour des objets
manipulés par le système, des fonctions qu'il remplit ou
encore des événements qu'il traite.

 La structure du formulaire variera en fonction des

techniques de structuration des besoins adoptées.
15
Formulaire de spécification

16

…….ambiguïté?
 2. PRÉSENTATIONS FORMATÉES

a. Dictionnaire de données ou glossaire :

 spécification de l'ensemble des données utilisées en analyse et en
conception. Définition des termes, sigles, codes, symboles,
synonymes et alias. Peut contenir des infos sur les spécifications des
données, les fichiers qui les contiennent et les processus qui les
utilisent.

b. Table de décision :
 Une table de décision est une représentation tabulaire de tous les
cas des valeurs d'entrée d'un processus et des valeurs de sortie
correspondant à chacune de ces combinaisons.

c. Table états-transitions :
 Elle est composée de lignes représentant les différents états du
système et, pour chaque état, en colonnes, les événements qui
provoquent des transitions d'un état à un autre, les actions à 17
effectuer et l'état suivant pour chaque transition.
 TECHNIQUES GRAPHIQUES OU SEMI-FORMELLES
Représentation graphique formelle accompagnée de textes informels (semi)
exemples:

a. Modèle entité-association :
les objets du domaine (entités) sont identifié par des attributs et sont
reliés par des liens dont on peut préciser les limites du nombre
(associations) d'occurences (cardianlité).

18
 Techniques graphiques ou semi-formelles

b. Diagrammes états-transitions :
Ils permettent de matérialiser graphiquement l'incidence des
événements sur les différents états du système en indiquant les
actions à effectuer.

19
 TECHNIQUES FORMELLES

 Techniques semi-formelles laissent une part à l'interprétation

≠ les techniques formelles permettent de spécifier formellement
le comportement complet d'un système informatique.

 Reposent sur des bases mathématiques.

 But : éliminer les ambiguïté, mal-entendus et les mauvaises

interprétations.

20
 Techniques formelles

Les méthodes et les langages de la spécification formelle possèdent trois

éléments:

 Une syntaxe : la notation utilisée dans la représentation de la

spécification.

 Une sémantique : la définition de la signification de la syntaxe

utilisée (non ambiguë)

 Un ensemble de relations : la définition des règles qui indiquent

les propriétés des objets mathématiques de la spécification.

 Spécification algébrique
21
 Spécification algébrique

 Spécification des Types de Données Abstraits (ADT) ou classes

d’objets;
 Spécification des interfaces des sous-systèmes (modules).

 Style utilisé :
Nom de la spécification (paramètre générique)

Sorte <nom>
Importe <liste de noms de spécification>

Description informelle en langage naturel sur la sorte et ses opérations

Signature d’opérations et les types de paramètres définis sur la sorte

Axiomes mathématiques définissant les opérations sur la sorte

22
 Spécification algébrique

 Sorte : une entité où un ensemble de paramètre et

d’opérations sont définies.
 Signature d’opération : définie la syntaxe de l’ADT.
 Axiomes : définie la sémantique des opérations( sens)

Elaboration d’une spécification algébrique:

1. Définir une interface pour l’ADT;
2. Définir l’ensemble d’opérations de L’ADT;
3. Définir de manière informelle chacune des opérations;
4. Définir la syntaxe de chaque opération et ses paramètres;
5. Définir la sémantique de chaque opération a l’aide
d’axiomes mathématiques.

23
 SPÉCIFICATION D’UNE LISTE GÉNÉRIQUE

 Nom de la spécification : LISTE

 Nom de la sorte : Liste

 La liste est une collection d’un autre type de données ( on introduit

des choses dans la liste)

 Le paramètre générique : elem ( on introduit des elem dans la liste)

24
 SPÉCIFICATION D’UNE LISTE GÉNÉRIQUE

Opérations sur la sorte:

 Création d’une instance de la liste; retourne une liste vide.

 Création d’une instance de la liste à partir d’une liste et d’un élément;

retourne une liste non vide.

 Création d’une instance de la liste avec les éléments 2,3,..n d’une autre
liste; retourne une liste non vide.

 L’obtention du premier élément de la liste; retourne un élément de la

liste.

 Obtention de la longueur de la liste; besoin d’un type de donnée

25
(grandeur de la liste)
 Spécification d’une liste générique

Format d’écriture de ces opérations:

 Créer liste
constructeurs
 Construire( liste, elem) liste
 Reste (liste) liste
 Tête(liste) elem
 Longueur(liste) entier

26
 Spécification d’une liste générique
 Définir la sémantique des opérations par des axiomes.

 Écrire un axiome pour chaque opération en utilisant

chaque constructeur primitif. (primitif : constructeur ne
pouvant être défini par d’autres constructeurs)

 Constructeur créer est primitif

 Constructeur construire est primitif
 Constructeur reste est non primitif
 Tête et longueur forment le reste des opérations de la
liste
 6 axiomes (2 const primitifs et 3 opérations) 27
 Spécification d’une liste générique

Axiomes de liste :

 Tête (créer) = non-défini ( premier élément d’une liste

vide. non-défini est une valeur particulière de type elem.)

 Tête (construire (L,V)) = V if L = créer else tête(L)

 On peut construire une liste à partie d’une liste vide et d’un
élément
 On peut construire une liste à partie d’une liste non vide et d’un
élément, dans ce cas l’élément est placé à la fin de la nouvelle liste.
  tête peut retourner soit V soit tête (L) puisque si L est vide, le
seul élément de L est V.

28
 Spécification d’une liste générique

 Longueur (créer) = 0
 Longueur (construire (L,V)) = longueur(L)+1 
récursive

 Reste (créer) = créer (une liste crée à partir d’une

liste vide est liste vide)
 Reste (construire (L,V)) = créer if L=créer else
construire(reste(L),V)  récurcive

29
 Spécification d’une liste générique
LISTE (elem)
Sorte liste On doit importer la spécification entier pour l’opération longueur
Importe entier
Définie une liste générique . Les éléments sont ajoutés à la fin de la liste. Les éléments
sont retirés au début de la liste. Le constructeur créer permet de créer une liste vide. Le
constructeur construire permet la création d’une liste par une autre. Reste permet de
créer une liste à partir des éléments (différents du premier) d’une autre liste. Les autres
opérations manipulent les autres caractéristiques d’une liste.
Créer liste
Construire( liste, elem) liste
Reste (liste) liste
Tête(liste) elem
Longueur(liste) entier

Tête (créer) = non-défini

Tête (construire (L,V)) = V if L = créer else tête(L)
Longueur (créer) = 0
Longueur (construire (L,V)) = longueur(L)+1
Reste (créer) = créer (une liste crée à partir d’une liste vide est liste vide)
Reste (construire (L,V)) = créer if L=créer else construire(reste(L),V) 30
 Application

 Créer une nouvelle sorte LISTE2.

 LISTE2 a la même spécification et est dotée de deux opérations

supplémentaires:

 Ajouter consiste à ajouter un élément en tête de liste et retourner une

liste contenant l’élément ajouté.

 Est-membre indique l’appartenance d’un élément dans une liste.

31
 Application
LISTE2(elem)
Sorte liste2
Importe entier, bool
Définie une liste générique . Les éléments sont ajoutés à la fin de la liste. Les éléments sont
retirés au début de la liste. Le const créer permet de créer une liste vide. Le const construire
permet la création d’une liste par une autre. Le const Reste permet de créer une liste à partir
des éléments (différents du premier) d’une autre liste. Le constAjouter consiste à ajouter un
élément en tête de liste et retourner une liste contenant l’élément ajouté.
Les autres opérations manipulent les autres caractéristiques d’une liste.

Créer liste
Construire( liste, elem) liste
……….
Ajouter (liste2, elem) liste2
Est-membre (liste2, elem) bool

………..
Ajouter (créer,V)= construire (créer,V)
……….
32